The present disclosure is generally directed to distributed energy resources (DERs), and more specifically, to a method, system, apparatus, and software program for using a peer-to-peer communication network to aggregate machine data from DERs to form an autonomous, automatic, and fault tolerant DER operational network.
Power grids may benefit from grid services provided by DERs during normal operating conditions as well as natural disasters and system outages. For example, DERs are mostly inverter-based resources and can provide reaction power to support feeder voltage drop when needed. During grid failures, DERs may become the sole energy sources for local communities and can serve as emergency support to customers and healthcare facilities. Machine data from individual DERs can greatly enhance situational awareness for grid operators and enable intelligent controls for DERs to relieve the pressure on utility grids during systemwide failures.
One of the challenges to incorporating massive amount of machine data from DERs for distribution grid operation is the integration cost. Utilities traditionally use dedicated communication channels to monitor and control their electrical circuits. The communication infrastructure typically has dedicated communications to collect field measurements from Remote Terminal Units (RTUs) installed on the feeders and substations. It is very expensive to expand this dedicated communication infrastructure for interconnection with DERs due to limited bandwidths and coverages.
A second challenge to incorporating the machine data from the DERs, is coordinating DER operation and leveraging DER capacities for grid operation and new edge services. Current industry standards, i.e. IEEE 1547, require inverters to trip or cease operation during a grid failure. However, extending inverter operation during grid outage to support local customer needs may greatly benefit grid reliability and resilience. When there are no grid outages, DER can also be deployed for voltage support by providing more reactive powers
A third challenge is the lack of resilience of a current grid design. Distribution circuits may be configured to control energy transfer from a substation to the end customer loads. Most US distribution circuits are radial networks and rely on a substation as the sole energy source. When there is a natural disaster or outage that takes down the utility grid, the downstream customers may run out of power. DERs can bridge the gap and greatly enhance the resilience and flexibility of grids in the face of failures. While current communication infrastructure is serving grid operational needs, adding a peer-to-peer communication network for DER data aggregation may improve grid fault tolerance and avoid a single point of failure.
Example implementations described herein involve an innovative method for using a peer-to-peer communication network to aggregate machine data from DERs to form an autonomous, automatic, and fault tolerant DER operational network. The peer-to-peer communication network may include communication nodes in the cloud, dedicated edge computing devices (e.g., a super, or master, edge node), and privately-owned mobile devices (edge nodes). Elements of the peer-to-peer network may be configured to receive machine data from individual DERs, route data uploading to cloud ports (e.g., a super cloud node), facilitate node-to-node communication and publish commands from cloud ports. Software programs in the cloud may then cleanse, consolidate, and analyze the field data through a co-simulation framework combining a model solver and deep learning analysis.
Aspects of the present disclosure include a method for managing a plurality of DERs at an edge computing device (e.g., a super edge node or master edge node). The method may include receiving, from a cloud node, a data collection protocol. The method may also include transmitting the data collection protocol to each of a plurality of private-device edge nodes (e.g., a privately-owned mobile devices) in a peer-to-peer network and receiving, based on the data collection protocol, data relating to the plurality of DERs from the plurality of private-device edge nodes through the peer-to-peer network. The method may further include transmitting the received data to a cloud-based node (e.g., a cloud system).
Aspects of the present disclosure include a non-transitory computer readable medium, storing instructions for execution by a processor, which can involve instructions for managing a plurality of DERs at an edge computing device (e.g., a super edge node or master edge node). The instructions for managing the plurality of DERs may include instructions for receiving, from a cloud node, a data collection protocol. The instructions for managing the plurality of DERs may include instructions for transmitting the data collection protocol to each of a plurality of private-device edge nodes (e.g., a privately-owned mobile devices) in a peer-to-peer network and instructions for receiving, based on the data collection protocol, data relating to the plurality of DERs from the plurality of private-device edge nodes through the peer-to-peer network. The instructions for managing the plurality of DERs may include instructions for transmitting the received data to a cloud-based node (e.g., a super cloud node).
Aspects of the present disclosure include a system for managing a plurality of DERs at an edge computing device (e.g., a super edge node or master edge node), which can involve means for receiving, from a cloud node, a data collection protocol. The system may also include means for transmitting the data collection protocol to each of a plurality of private-device edge nodes (e.g., a privately-owned mobile devices) in a peer-to-peer network and means for receiving, based on the data collection protocol, data relating to the plurality of DERs from the plurality of private-device edge nodes through the peer-to-peer network. The system may further include means for transmitting the received data to a cloud-based node (e.g., a super cloud node).
Aspects of the present disclosure include an apparatus, which can involve a processor, configured to receive, from a cloud node, a data collection protocol. The processor may also be configured to transmit the data collection protocol to each of a plurality of private-device edge nodes (e.g., a privately-owned mobile devices) in a peer-to-peer network and to receive, based on the data collection protocol, data relating to the plurality of DERs from the plurality of private-device edge nodes through the peer-to-peer network. The processor may further be configured to transmit the received data to a cloud-based node (e.g., a super cloud node).
Aspects of the present disclosure include a method for managing a plurality of DERs at a cloud-based node. The method may further include generating, based on a desired system-level analysis, a data collection protocol for implementation at the plurality of DERs and transmitting, via a peer-to-peer network, the data collection protocol to the DERs via a set of edge nodes, the set of edge nodes comprising at least one master edge node (e.g., a super edge node) and a plurality of private-device edge nodes (e.g., privately-owned mobile devices). The method may also include receiving, based on the data collection protocol, data related to the plurality of DERs from edge nodes in the set of edge nodes. The method may further include generating a system recommendation based on the received data by processing the data with a machine trained network, the machine trained network having been trained with a combination of real-time data and simulation data.
Aspects of the present disclosure include a non-transitory computer readable medium, storing instructions for execution by a processor, which can involve instructions for managing a plurality of DERs at a cloud-based node. The instructions for managing the plurality of DERs may include instructions for generating, based on a desired system-level analysis, a data collection protocol for implementation at the plurality of DERs and instructions for transmitting, via a peer-to-peer network, the data collection protocol to the DERs via a set of edge nodes, the set of edge nodes comprising at least one master edge node (e.g., a super edge node) and a plurality of private-device edge nodes (e.g., privately-owned mobile devices). The instructions for managing the plurality of DERs may also include instructions for receiving, based on the data collection protocol, data related to the plurality of DERs from edge nodes in the set of edge nodes. The instructions for managing the plurality of DERs may further include instructions for generating a system recommendation based on the received data by processing the data with a machine trained network, the machine trained network having been trained with a combination of real-time data and simulation data.
Aspects of the present disclosure include a system for managing a plurality of DERs at a cloud-based node, which can involve means for generating, based on a desired system-level analysis, a data collection protocol for implementation at the plurality of DERs and means for transmitting, via a peer-to-peer network, the data collection protocol to the DERs via a set of edge nodes, the set of edge nodes comprising at least one master edge node (e.g., a super edge node) and a plurality of private-device edge nodes (e.g., privately-owned mobile devices). The system may also include means for receiving, based on the data collection protocol, data related to the plurality of DERs from edge nodes in the set of edge nodes. The system may further include means for generating a system recommendation based on the received data by processing the data with a machine trained network, the machine trained network having been trained with a combination of real-time data and simulation data.
Aspects of the present disclosure include an apparatus, which can involve a processor, configured to generate, based on a desired system-level analysis, a data collection protocol for implementation at the plurality of DERs and to transmit, via a peer-to-peer network, the data collection protocol to the DERs via a set of edge nodes, the set of edge nodes comprising at least one master edge node (e.g., a super edge node) and a plurality of private-device edge nodes (e.g., privately-owned mobile devices). The processor may also be configured to receive, based on the data collection protocol, data related to the plurality of DERs from edge nodes in the set of edge nodes. The processor may further be configured to generate a system recommendation based on the received data by processing the data with a machine trained network, the machine trained network having been trained with a combination of real-time data and simulation data.
Aspects of the present disclosure include a method for managing a plurality of DERs at an edge computing device. The method may include identifying a set of one or more private-device edge nodes capable of receiving data from one or more DERs and transmitting data received from a DER to the edge computing device. The method may also include registering the identified private-device edge nodes for inclusion in a peer-to-peer network and transmitting, to each of the identified private-device edge nodes in a peer-to-peer network, a data collection protocol for the DERs to implement. The method may further include receiving, based on the data collection protocol, data relating to the plurality of DERs from the identified private-device edge nodes through the peer-to-peer network.
Aspects of the present disclosure include a non-transitory computer readable medium, storing instructions for execution by a processor, which can involve instructions for managing a plurality of DERs at an edge computing device. The instructions for managing the plurality of DERs may include instructions for identifying a set of one or more private-device edge nodes capable of receiving data from one or more DERs and instructions for transmitting data received from a DER to the edge computing device. The instructions for managing the plurality of DERs may also include instructions for registering the identified private-device edge nodes for inclusion in a peer-to-peer network and instructions for transmitting, to each of the identified private-device edge nodes in a peer-to-peer network, a data collection protocol for the DERs to implement. The instructions for managing the plurality of DERs may further include instructions for receiving, based on the data collection protocol, data relating to the plurality of DERs from the identified private-device edge nodes through the peer-to-peer network.
Aspects of the present disclosure include a system for managing a plurality of DERs at an edge computing device, which can involve means for identifying a set of one or more private-device edge nodes capable of receiving data from one or more DERs and means for transmitting data received from a DER to the edge computing device. The system may also include means for registering the identified private-device edge nodes for inclusion in a peer-to-peer network and means for transmitting, to each of the identified private-device edge nodes in a peer-to-peer network, a data collection protocol for the DERs to implement. The system may further include means for receiving, based on the data collection protocol, data relating to the plurality of DERs from the identified private-device edge nodes through the peer-to-peer network.
Aspects of the present disclosure include an apparatus for managing a plurality of DERs at an edge computing device, which can involve a processor, configured to identify a set of one or more private-device edge nodes capable of receiving data from one or more DERs and to transmit data received from a DER to the edge computing device. The processor may also be configured to register the identified private-device edge nodes for inclusion in a peer-to-peer network and to transmit, to each of the identified private-device edge nodes in a peer-to-peer network, a data collection protocol for the DERs to implement. The processor may further be configured to receive, based on the data collection protocol, data relating to the plurality of DERs from the identified private-device edge nodes through the peer-to-peer network.
The following detailed description provides details of the figures and example implementations of the present application. Reference numerals and descriptions of redundant elements between figures are omitted for clarity. Terms used throughout the description are provided as examples and are not intended to be limiting. For example, the use of the term “automatic” may involve fully automatic or semi-automatic implementations involving user or administrator control over certain aspects of the implementation, depending on the desired implementation of one of the ordinary skills in the art practicing implementations of the present application. Selection can be conducted by a user through a user interface or other input means, or can be implemented through a desired algorithm. Example implementations as described herein can be utilized either singularly or in combination and the functionality of the example implementations can be implemented through any means according to the desired implementations.
Example implementations described herein involve an innovative method of using a peer-to-peer communication network to aggregate machine data from DERs to form an autonomous, automatic, and fault tolerant DER operational network. The peer-to-peer communication network may include communication nodes in the cloud, dedicated edge computing devices (e.g., a super, or master, edge node), and privately-owned mobile devices (edge nodes). Elements of the peer-to-peer network may be configured to receive machine data from individual DERs, route data uploading to cloud ports (e.g., a super cloud node), facilitate node-to-node communication and publish commands from cloud ports. Software programs in the cloud may then cleanse, consolidate, and analyze the field data through a co-simulation framework combining a model solver and deep learning analysis.
Aspects of the invention described herein may improve two-way communication between massive numbers of DERs (e.g., thousands to hundreds of thousands), especially behind-the-meter DERs, and cloud infrastructure without expensive infrastructure investment. Effective data acquisition from DERs and data preparation for a variety of analytics on the edge and in the cloud may be improved by aspects of the invention. Some aspects of the invention may improve DER operational insights and coordination for grid operation during normal condition and outages and may provide a scalable and fault tolerant system design for improved grid resilience.
The system 200 may also include a communication layer 220. In some aspects, the communication layer 220 may include a peer-to-peer network including the cloud infrastructure (e.g., cloud component 110 of
The system 200, in some aspects, further includes a software service layer 230. In some aspects, the software service layer 230 may include components implemented on (executed by) the devices that make up hardware layer 210. For example, certain components of the software service layer 230 may be implemented on one or more privately-owned mobile devices, one or more super edge nodes, and/or one or more cloud nodes of the hardware layer 210 (and communication layer 220). The software service layer, in some aspects, may provide storage, computing, analytics, and traffic management functions.
System 200 may also include a data layer 240. The data layer may include functions such as transmitting data through the peer-to-peer communication network to the cloud. In some aspects, the data layer may include data that has been joined, cleansed, consolidated, and benchmarked for analysis by an analytics layer 250. The analytics layer 250 may include a co-simulation analytical framework that may be implemented on the cloud. The analytics layer 250 may define a data inventory (e.g., a data collection protocol for implementation at the DERs). The analytics layer 250, in some aspects, may perform quantitative analysis to generate insights and/or recommendation to support users' decision. While the components of system 200 are illustrated as conceptually separate, it is to be understood that the components may overlap in the physical implementation. As described above, the devices of the hardware layer 210 may make up the communication layer 220, may execute the software service layer 230, may provide processing and storage for the data layer 240, and may execute the analytics layer 250.
Privately-owned mobile nodes 326 may include personal smart phones, tablet devices, home hubs, or other electronic devices with communication capabilities, such as cellular, radio, Bluetooth, zigbee, etc. Privately-owned mobile device owners may enable inclusion into the peer-to-peer communication network 320 by installing a mobile application to formally register to become a candidate for inclusion as a node 326 in the peer-to-peer communication network 320. In some aspects, a privately-owned mobile device owner may receive incentives (e.g. credit or awards) based on their contribution to the peer-to-peer communication network 320. Their performance (e.g., contribution), in some aspects, may be measured by data throughput and local storage capacity that may be validated by a super edge node 324. Installing the mobile application, in some aspects, may not allow the mobile device owner to access proprietary information embedded in the data packets. Additionally, the installation of the mobile application may not interfere with normal use of the mobile devices.
Super edge nodes 324, in some aspects, may, or may not, communicate directly with each other. In some aspects, each super edge node 324 may be capable of direct communication with a first set of DERs (e.g., DERs 328a) and indirect communication with a second set of DERs (e.g., DERs 328b). As illustrated in
In some aspects, the nodes (e.g., 324, 326, and 328) of the peer-to-peer communication network 320 may be configured (e.g., by the super edge node and ultimately the cloud software) to route the data via a shortest path to the super cloud node 322. The nodes 324, 326, and 328, in some aspects, may be configured to route the data based on other characteristics of the connections in the peer-to-peer communication network 320 such as bandwidth, latency, reliability of a connection, etc. which may lead to data being transmitted via a longer path. The connection (e.g., a set of routes) between a super cloud node 322 and a super edge node 324, in some aspects, is configured to meet bandwidth (e.g., an optimized bandwidth) and redundancy standards that ensure reliable data exchange. The link between other nodes (e.g., privately-owned mobile devices 326 or DERs 328) and a super cloud node 322 may be dynamically arranged to accommodate a current state of the peer-to-peer communication network. When data arrives at a super cloud node, in some aspects, the data will enter a pipeline of services for cleansing, consolidation, preparation and analysis.
In some aspects, the super edge nodes serve as the core communication hub for each mobile node and may include data storage, edge computing, and traffic management functions. Additionally, each privately-owned mobile device 326 may provide limited local storage capabilities. For example, if a batch data transmission mode is enabled, or if a connection to a super edge node is interrupted, a privately-owned mobile device may store data received from a DER until a transmission time or trigger occurs, at which time the privately-owned mobile device may transmit the stored data. Data transmitted through the peer-to-peer communication network 320 that arrives at a super cloud node 322 may enter a pipeline of services for cleansing, consolidation, preparation, and analysis.
DER 410 may also include a node recruitment component 413. Node recruitment component 413 may identify edge nodes 430 (e.g., privately-owned edge node) or super edge nodes 420 available to transmit data to the cloud. Available edge nodes 430 or super edge nodes 420 may be based on proximity and, for privately-owned devices (e.g., edge nodes 430), whether the device is registered with the peer-to-peer network (e.g., with the super edge node 420). The node recruitment component 413 may provide the identities of the available edge nodes 430 and super edge nodes 420.
The processed data may be provided to a data transmission component 415. The data transmission component 415 may be configured to select at least one edge node (e.g., super edge node 420 or edge node 430) using node selection component 416. In some aspects, if the at least one selected edge node includes a privately-owned edge node, the data transmission component 415 may encrypt the data for transmission to the privately-owned edge node using the data encryption component 417. In some aspects, data is encrypted at the DER for transmission to both super edge nodes 420 and edge nodes 430 for transmission across unsecure networks. Data packets may be encrypted, in some aspects, based on joint credentials defined by DER 410 and edge nodes (e.g., super edge nodes 420 or edge nodes 430). The processed data (e.g., encrypted or unencrypted processed data based on the data protocol) may then be transmitted via edge node interface 419 to the at least one selected edge node (e.g., 420 or 430).
The system architecture illustrated in
Super edge node 420 may include an edge node/DER interface 422. The edge node DER interface 422 may receive DER data directly from DERs 410 or via edge nodes 430 (or other super edge nodes 420). The DER data may be stored in a local storage 423. The local storage 423 may be capable, in some aspects, of storing more data (e.g., two weeks or one month worth of data) than the local storage 433 of an edge node 430. The data received from the DERs 410 may be stored in the local storage 423 and be processed by a data processing component 424. Data processing component 424 may decrypt encrypted DER data and may organize and/or aggregate data received from multiple DERs. For example, a DER 410 may transmit its data via multiple edge nodes and the data processing component 424 may identify and remove the duplicate data before transmitting the data to the cloud 440. The data processing component 424, in some aspects, may aggregate the DER data (i.e., the data received from multiple DERs) to reduce the amount of data transmitted to the cloud 440. For example, the DER data from multiple DERs may be aggregated to indicate available capacity of the DERs in one or more sections of an electrical grid (e.g., based on a current output of the DERs and a current load reported in the DER data). The data may also be organized, e.g., as time-series data before transmitting to the cloud 440.
Super edge node 420 may also include control components such as DER control component 425 and routing control component 426. DER control component 425 may provide control instructions to the DERs 410 that are received from the cloud 440. The control instructions, in some aspects, may include operating mode indications such as a constant voltage operating mode and a constant power operating mode for at least one of an energy production or energy storage function of the DER. In some aspects, the control instructions may indicate a reference value related to a characteristic of at least one DER, e.g., a voltage magnitude, a power factor, or a reactive power operating point for one of an energy production or energy storage function of the DER. Additional control instructions or indications may be provided based on the nature and/or functionality of the DER.
Routing control component 426 may monitor traffic through the peer-to-peer network and determine a route, or routes, for data transmission from each DER in a local peer-to-peer network (e.g., a peer-to-peer network connected to the cloud through the super edge node 420). In some aspects, the routing control component 426 optimizes data paths based on link capacity and other network properties to ensure delivery of the DER data. In some aspects, the optimization includes indicating redundant routes (e.g., via multiple edge nodes) for a particular DER 410 to use to transmit data to the super edge node 420.
The super edge node, in some aspects, may also include mobile device registration component 427. Mobile device registration component 427, in some aspects, may register private-device edge nodes (e.g., privately-owned mobile devices) for inclusion in the peer-to-peer network. In some aspects, this registration is through an interaction with a mobile application (e.g., mobile application 431) on an edge node 430. The registration may include selecting a username and password to set up an account with the system. As the private-device edge nodes (e.g., privately-owned mobile devices) provide connectivity and DER data to the super edge node 420, the mobile device registration component 427 may then validate that the data has been received from the private-device edge node and credit the account associated with the private-device edge node based on the validation of the data being received. In some aspects the validation of the data includes validating the encryption uses an expected key (e.g., that the data can be decrypted) and may include additional validation of the decrypted data. The credits may be assigned based on one or more of an amount of data received from devices (e.g., at least one private-device edge node) associated with an account, a time that the devices associated with the account participate in the peer-to-peer network, and/or the amount of resources dedicated to the mobile application 431 on the devices (e.g., edge nodes 430) associated with the account.
The data processing component 443 may then provide the processed data to one or more additional components for further analysis or storage. For example, the data processing component 443 may transmit processed data to a data storage 447 for long-term storage (e.g., for offline or non-runtime analysis), a deep learning component 445 for processing via a machine-trained network included in the deep learning component 445, and a model solver component 444 that generates simulation data for training the deep learning component 445. In some aspects, the processed DER data may also be provided to a co-simulation module 455 by one or more of the data processing component 443, the deep learning component 445, or the model solver component 444.
The deep learning component 445 may perform a real-time analysis on the received DER data to generate a recommendation for an action for a system manager and/or an updated data protocol. The updated data protocol (e.g., a new data inventory) for future data acquisition may be used to define a dynamic and adaptive data acquisition method. In some aspects, the model solver component 444 may generate simulated data based on a model of the physical system (e.g., the electrical grid including loads, sources, transmission sources, etc.) and the DER data received from the data processing component 443. The simulation data generated by the model solver component 444 may be provided to the deep learning component 445 to be used as (online) training data for a machine-trained network along with the real-time data received from the data processing component 443. Deep learning component 445 may transmit the output of the trained network to at least one of co-simulation module 455 and control component 457. In some aspects, the deep learning component 445 transmits an updated data inventory (e.g., a data protocol) identifying data to request from DERs 410 to the control component 457.
The co-simulation module 455 may receive input from the model solver component 444 and/or the deep learning component 445. The co-simulation module 455 may then perform a data analysis to generate control recommendations, including operational insights, statistical, and mathematical models for decision support. In some aspects, the control recommendation may relate to an operating mode for the DER in a set of operating modes. For example, the set of operating modes may include one of a constant voltage operating mode and a constant power operating mode and the set of operating modes may be associated with one of an energy production or energy storage function of the DER. In some aspects, the recommendation may indicate a reference value related to a characteristic of at least one DER. For example, the reference value related to the characteristic may relate to one or more of a voltage magnitude, a power factor, and a reactive power operating point. As for the set of operation mode recommendations, the reference value may be associated with one of an energy production or energy storage function of the DER. In some aspects, the control recommendation may relate to local power generation and provision by the plurality of DERs. The control recommendations, including operational insights, statistical, and mathematical models may be transmitted to a recommendation component 451 for display to a user.
The recommendation component 451, in some aspects, prepares the recommendation for display to a user via the user interface 453. The display via user interface 453 may include a visual depiction of the state of the system along with relevant statistical data and a set of recommendations based on the DER data. The visual depiction of the state of the system along with relevant statistical data may be presented to a user to inform a decision between a set of recommended actions (or a decision to reject the recommendations). The set of recommendations, in some aspects, may be reviewed by a user, e.g., a grid operator, and inputs to the user interface 453 may then be used to define a finalized control action/command. For example, the input (e.g., from a user or system administrator) to the user interface 453 may include a selection of a recommended action or a selection indicating a different action. The user input and/or the finalized control action/command may then be provided to control component 457.
Control component 457 may then generate a set of control data for implementing the selection received from the user interface 453 (e.g., the finalized control action/command). The control component may also generate an updated data protocol (e.g., may update the type or frequency of the data collected at the DER) for implementation by the DERs based on input from the deep learning component 445. The control data (including the updated data protocol) generated by control component 457 may then be transmitted to each super edge node 420 in a set of super edge nodes. The control data may be transmitted via peer-to-peer interface 441 and cloud interface 421. In some aspects, the connection between the cloud 440 and the super edge node 420 may be a dedicated communication channel. Each super edge node 420 may process the control data at the DER control component 425 and/or the routing control component 426 to generate DER-specific control data (e.g., based on the manufacturer of the DER and the required operational mode or reference value associated with the DER).
The mobile application may further include an encryption validation component 536 that receives encrypted data from the DER and is configured to validate the encryption without being able to decode the DER data. The encryption validation component 536 may provide validated encrypted DER data to a local storage 533 for storage until a transmission time (e.g., based on a request from a super edge node 520, based on the expiration of a timer, or based on a reconnection after an interruption). The amount of resources, e.g., memory/storage resources or processing resources, available to the mobile application may be negotiated with a super edge node 520 and may be controlled locally by resource management component 535. Based on the data transmitted by the edge node 530 and/or the edge node resources (e.g., local storage 533) made available (or allocated) to the mobile application 531, the account associated with the edge node 530 may be credited via credit component 534 that may store account information (e.g., an account identifier, a current balance, etc.).
At 604, the DER may identify available peer-to-peer nodes (e.g., edge nodes). The available edge nodes may be identified by the DER based on their proximity to the DER and their registration with a super edge node. The identification may be based on an announcement/advertisement made by an edge node (e.g., a privately-owned mobile device) or based on a communication from a super edge node. For example, referring to
At 606, the DER may collect data (e.g., DER data) based on the data collection protocol received at 602. In some aspects, the data collection may include a first operation that collects multiple types of data at a particular (e.g., finest) granularity and a second operation that filters (e.g., selects indicated types of data with an indicated granularity) the collected data based on the data collection protocol received at 602. For example, referring to
The DER, at 608, may select an identified node for transmitting data to the cloud. The identified node may be selected from the available nodes identified at 604. The selected nodes may be selected, at 608, based on routing control data received from a super edge node (e.g., directly or via a set of intermediate edge node). In some aspects, the selection of edge nodes is based on advertised characteristics (e.g., bandwidth connection quality, etc.) of the identified available edge node. For example, referring to
At 610, the DER may determine if the selected edge node is a privately-owned mobile device. In some aspects, the determination may be based on information associated with the selected edge node during the identification process. For example, referring to
If the selected edge node is determined, at 610, to be a privately-owned mobile device, the DER may encrypt, at 612, the data collected at 606. For example, referring to
If the DER determines, at 610, that the selected node is not a privately-owned mobile device, the DER may determine, at 614, if an additional node will be selected. If an additional node will be selected, the DER may select, at 608, a node for transmitting data to the cloud and continue the method as described above. In some aspects, an additional node will be selected based on an indication, e.g., from a super edge node, of a number of edge nodes to use to transmit DER data to the super edge node. The super edge node may indicate to select more than one node (e.g., including at least one privately-owned mobile devices), in some aspects, to ensure transmission of the DER to the super edge node and the cloud in the case of a link failure between one of the edge nodes and the peer-to-peer network. For example, referring to
If the DER determines, at 614, that no additional nodes will be selected, the DER may transmit, at 616, the DER data (e.g., encrypted or unencrypted DER data depending on a selected node) to the selected edge node or nodes. The transmission of the DER data may use public networks. The data may be transmitted as data packets in a packet-based network (e.g., the Internet). For example, referring to
At 704, the super edge node may transmit the data collection protocol to each of multiple private-device edge nodes (e.g., privately-owned mobile devices) in a peer-to-peer network. In some aspects, the transmitted data protocol may be a data protocol based on the data protocol received at 702 that has been formatted or generated for a specific DER to which a private-device edge node of the private-device edge nodes connect. As discussed above, the transmitted data collection protocol may indicate a set of data types to collect and a sampling value indicating an amount of data associated with the set of data types to transmit. The super edge node may also transmit the data collection protocol to each of a set of DERs in the peer-to-peer network. For example, referring to
Based on the data collection protocol, the super edge node may receive, at 706, data relating to the multiple DERs from the multiple private-device edge nodes through the peer-to-peer network. The data relating to the multiple DERs may be data encrypted by the DER before transmitting the DER data to a private-device edge node (and eventually the super edge node). The data relating to the multiple DERs may include time series data relating to the data types indicated by the data collection protocol sampled at the rate indicated by the data collection protocol. The super edge node may also receive, data relating to the set of DERs from the set of DERs through the peer-to-peer network. The data received from the set of DERs may be encrypted or unencrypted based on the nature of the connection between a DER and the super edge node (e.g., whether it is secure or unsecure). In some aspects, the super edge node may aggregate the received data from the multiple private-device edge nodes into a first aggregated data set. Aggregating the received data, in some aspects, includes a deduplication operation to remove duplicate data relating to a same DER received from more than one private-device edge node. For example, referring to
Finally, at 708, the super edge node may transmit the received data to a cloud-based node. The data may be transmitted, at 708, via a secure link between the super edge node and the cloud. For example, referring to
At 804, the super edge node may register the identified private-device edge nodes for inclusion in a peer-to-peer network. Registering the identified private-device edge nodes, in some aspects, includes associating the private-device edge nodes with an account (e.g., either an existing account or by creating a new account). In some aspects, the registration also includes verifying that the private-device edge nodes are valid devices for inclusion in the peer-to-peer network. For example, referring to
At 806, the super edge node may transmit, to each of the registered private-device edge nodes in a peer-to-peer network, a data collection protocol for the DERs to implement. In some aspects, the transmitted data protocol may be a data protocol based on a data protocol received from the cloud that has been formatted or generated for a specific DER to which a private-device edge node of the private-device edge nodes connect. The data collection protocol may indicate a set of data types to collect and a sampling value indicating an amount of data associated with the set of data types to transmit. The super edge node may also transmit the data collection protocol to each of a set of DERs in the peer-to-peer network. For example, referring to
Finally, at 808, the super edge node may receive data relating to the multiple DERs from the multiple private-device edge nodes through the peer-to-peer network based on the data collection protocol. The data relating to the multiple DERs may be data encrypted by the DER before transmitting the DER data to a private-device edge node (and eventually the super edge node). The data relating to the multiple DERs may include time series data relating to the data types indicated by the data collection protocol sampled at the rate indicated by the data collection protocol. The super edge node may also receive, data relating to the set of DERs from the set of DERs through the peer-to-peer network. The data received from the set of DERs may be encrypted or unencrypted based on the nature of the connection between a DER and the super edge node (e.g., whether it is secure or unsecure). In some aspects, the super edge node may aggregate the received data from the multiple private-device edge nodes into a first aggregated data set. Aggregating the received data, in some aspects, includes a deduplication operation to remove duplicate data relating to a same DER received from more than one private-device edge node. For example, referring to
At 904, the super edge node may register the identified private-device edge nodes for inclusion in a peer-to-peer network. Registering the identified private-device edge nodes, in some aspects, includes associating the private-device edge nodes with an account (e.g., either an existing account or by creating a new account). In some aspects, the registration also includes verifying that the private-device edge nodes are valid devices for inclusion in the peer-to-peer network. For example, referring to
At 906, the super edge node may receive a data collection protocol from a cloud. The data collection protocol may indicate a set of data types to collect and a sampling value indicating an amount of data associated with the set of data types to transmit. The indicated data types and sampling value may represent less than all data available at the DER (e.g., a subset of the data types of available at the DER and a subset of the data points available at the DER). In some aspects, the data protocol may be based on previously-received DER data that has been processed at the cloud to determine an updated data protocol (e.g., identify additional data that may be useful or identify data that will no longer be collected). For example, referring to
At 908, the super edge node may transmit, to each of the registered private-device edge nodes in a peer-to-peer network, a data collection protocol for the DERs to implement. In some aspects, the transmitted data protocol may be a data protocol based on the data protocol received from the cloud that has been formatted or generated for a specific DER to which a private-device edge node of the private-device edge nodes connect. The super edge node may also transmit the data collection protocol to each of a set of DERs in the peer-to-peer network. For example, referring to
The super edge node may receive, at 910, data relating to the multiple DERs from the multiple private-device edge nodes through the peer-to-peer network based on the data collection protocol. The data relating to the multiple DERs may be data encrypted by the DER before the DER data is transmitted to a private-device edge node (and eventually the super edge node). The data relating to the multiple DERs may include time series data relating to the data types indicated by the data collection protocol sampled at the rate indicated by the data collection protocol. The super edge node may also receive data relating to the set of DERs from the set of DERs through the peer-to-peer network. The data received from the set of DERs may be encrypted or unencrypted based on the nature of the connection between a DER and the super edge node (e.g., whether it is secure or not secure). In some aspects, the super edge node may aggregate the received data from the multiple private-device edge nodes into a first aggregated data set. Aggregating the received data, in some aspects, includes a deduplication operation to remove duplicate data relating to a same DER received from more than one private-device edge node. For example, referring to
At 912, the super edge node may validate that the data has been received from the private-device edge node. In some aspects, validating that the data has been received at 912 also includes validating the data that has been received such that the data received from the private-device edge node is validated if the data is correct (or decodable). In some aspects, validating the data includes validating an encryption used by the DER. For example, referring to
At 914, the super edge node may credit the account associated with the private-device edge node based on the validation of the data being received. The credits may be assigned based on one or more of an amount of data received from the private-device edge node associated with an account, a time that the private-device edge node associated with the account participates in the peer-to-peer network, and/or on the amount of resources dedicated to the mobile application on the private-device edge node associated with the account. For example, referring to
Finally, at 916, the super edge node may transmit the received data to a cloud-based node. The data may be transmitted, at 916, via a secure link between the super edge node and the cloud. For example, referring to
At 1004, the super edge node may register the identified private-device edge nodes for inclusion in a peer-to-peer network. Registering the identified private-device edge nodes, in some aspects, includes associating the private-device edge nodes with an account (e.g., either an existing account or by creating a new account). In some aspects, the registration also includes verifying that the private-device edge nodes are valid devices for inclusion in the peer-to-peer network. For example, referring to
At 1006, the super edge node may receive a data collection protocol from a cloud. The data collection protocol may indicate a set of data types to collect and a sampling value indicating an amount of data associated with the set of data types to transmit. The indicated data types and sampling value may represent less than all data available at the DER (e.g., a subset of the data types of available at the DER and a subset of the data points available at the DER). In some aspects, the data protocol may be based on previously-received DER data that has been processed at the cloud to determine an updated data protocol (e.g., identify additional data that may be useful or identify data that will no longer be collected). For example, referring to
At 1008, the super edge node may transmit, to each of the registered private-device edge nodes in a peer-to-peer network, a data collection protocol for the DERs to implement. In some aspects, the transmitted data protocol may be a data protocol based on the data protocol received from the cloud that has been formatted or generated for a specific DER to which a private-device edge node of the private-device edge nodes connect. The super edge node may also transmit the data collection protocol to each of a set of DERs in the peer-to-peer network. For example, referring to
The super edge node may receive, at 1010, data relating to the multiple DERs from the multiple private-device edge nodes through the peer-to-peer network based on the data collection protocol. The data relating to the multiple DERs may be data encrypted by the DER before the DER data is transmitted to a private-device edge node (and eventually the super edge node). The data relating to the multiple DERs may include time series data relating to the data types indicated by the data collection protocol sampled at the rate indicated by the data collection protocol. The super edge node may also receive data relating to the state of the DERs from which it receives data. In some aspects, the super edge node may aggregate the received data from the multiple private-device edge nodes into a first aggregated data set. Aggregating the received data, in some aspects, includes a deduplication operation to remove duplicate data relating to a same DER received from more than one private-device edge node. For example, referring to
At 1012, the super edge node may diagnose a state of the multiple DERs based on the received data relating to the multiple DERs. Diagnosing the state of the multiple DERs may include diagnosing whether the DERs are active or in a failed state (or in a disconnected state). For example, referring to
At 1014, the super edge node may transmit, to the cloud-based node, data regarding the health of the multiple DERs. Finally, at 1016, the super edge node may transmit the received data to a cloud-based node. The data regarding the health of the multiple DERs and the DER data may be transmitted, at 1016, via a secure link between the super edge node and the cloud. For example, referring to
At 1104, the super edge node may transmit the data collection protocol to each of multiple private-device edge nodes (e.g., privately-owned mobile devices) in a peer-to-peer network. In some aspects, the transmitted data protocol may be a data protocol based on the data protocol received at 1102 that has been formatted or generated for a specific DER to which a private-device edge node of the private-device edge nodes connect. As discussed above, the transmitted data collection protocol may indicate a set of data types to collect and a sampling value indicating an amount of data associated with the set of data types to transmit. The super edge node may also transmit the data collection protocol to each of a set of DERs in the peer-to-peer network. For example, referring to
Based on the data collection protocol, the super edge node may receive, at 1106, data relating to the multiple DERs from the multiple private-device edge nodes through the peer-to-peer network. The data relating to the multiple DERs may be data encrypted by the DER before transmitting the DER data to a private-device edge node (and eventually the super edge node). The data relating to the multiple DERs may include time series data relating to the data types indicated by the data collection protocol sampled at the rate indicated by the data collection protocol. The super edge node may also receive, data relating to the set of DERs from the set of DERs through the peer-to-peer network. The data received from the set of DERs may be encrypted or unencrypted based on the nature of the connection between a DER and the super edge node (e.g., whether it is secure or unsecure). In some aspects, the super edge node may aggregate the received data from the multiple private-device edge nodes into a first aggregated data set. Aggregating the received data, in some aspects, includes a deduplication operation to remove duplicate data relating to a same DER received from more than one private-device edge node. For example, referring to
At 1108, the super edge node may detect a failure state of a connection to the cloud-based node. The failure state may be due to an intermediate link failure (e.g., an intermediate router failure). For example, referring to
Based on detecting the failure state of the connection, the super edge node may store, at 1110, data relating to the multiple DERs received after the failure state is detected. The super edge node may store the received data in a local storage for eventual transmission to the cloud. For example, referring to
At 1112, the super edge node may detect a reestablished connection to the cloud-based node. Finally, at 1114, the super edge node may transmit the received and stored data to the cloud-based node. The data may be transmitted, at 1114, via a reestablished secure link between the super edge node and the cloud. For example, referring to
At 1204, the cloud may transmit, via a peer-to-peer network, the data collection protocol to the DERs via a set of edge nodes. The set of edge nodes may include at least one master (super) edge node and multiple private-device edge nodes. For example, referring to
At 1206, the cloud may receive, based on the data collection protocol, data related to the multiple DERs from edge nodes in the set of edge nodes. The data related to the multiple DERs may include data based on the data collection protocol and data regarding the health of elements of the system (e.g., DERs, nodes of the peer-to-peer network, etc.). For example, referring to
Finally, at 1208, the cloud may generate a system recommendation based on the received data by processing the data with a machine trained network. The machine trained network may have been trained with a combination of real-time data and simulation data. The system recommendation may include a recommendation for control information and an updated data collection protocol based on the analysis of the received DER data. For example, referring to
At 1304, the cloud may transmit, via a peer-to-peer network, the data collection protocol to the DERs via a set of edge nodes. The set of edge nodes may include at least one master (super) edge node and multiple private-device edge nodes. For example, referring to
At 1306, the cloud may receive, based on the data collection protocol, data related to the multiple DERs from edge nodes in the set of edge nodes. The data related to the multiple DERs may include data based on the data collection protocol and data regarding the health of elements of the system (e.g., DERs, nodes of the peer-to-peer network, etc.). For example, referring to
At 1308, the cloud may receive user input relating to a desired system-level analysis. The user input may specify a set of system characteristics that are of interest to a user (e.g., a system administrator). The characteristics, in some aspects, may include power output, current load, or other information. For example, referring to
At 1310, the cloud may generate a system recommendation based on the received data by processing the data with a machine trained network. The machine trained network may have been trained with a combination of real-time data and simulation data. The system recommendation may include a recommendation for control information and an updated data collection protocol based on the analysis of the received DER data. In some aspects, the updated data collection protocol may be based on the user input received at 1308. For example, referring to
At 1312, the cloud may determine that the recommended data collection protocol is different from a previously-generated data collection protocol. The updated data protocol may be generated for future data acquisition to define a dynamic and adaptive data acquisition method. The updated data collection protocol may identify additional data that may be useful or identify data that will no longer be collected. For example, referring to
Finally, at 1314, the cloud may transmit the recommended data collection protocol to the DERs via the set of edge nodes. The data may be transmitted, at 1314, via a secure link between the cloud and the super edge node. For example, referring to
At 1404, the cloud may transmit, via a peer-to-peer network, the data collection protocol to the DERs via a set of edge nodes. The set of edge nodes may include at least one master (super) edge node and multiple private-device edge nodes. For example, referring to
At 1406, the cloud may receive, based on the data collection protocol, data related to the multiple DERs from edge nodes in the set of edge nodes. The data related to the multiple DERs may include data based on the data collection protocol and data regarding the health of elements of the system (e.g., DERs, nodes of the peer-to-peer network, etc.). For example, referring to
At 1408, the cloud may generate a system recommendation based on the received data by processing the data with a machine trained network. The machine trained network may have been trained with a combination of real-time data and simulation data. The system recommendation may include a recommendation for control information and an updated data collection protocol based on the analysis of the received DER data. For example, referring to
At 1410, the cloud may display the set of one or more recommended actions to a user interface. The display may include a visual depiction of the state of the system along with relevant statistical data and a set of recommendations based on the DER data. The visual depiction of the state of the system along with relevant statistical data may be presented to a user to inform a decision in light of a set of recommended actions. For example, referring to
At 1412, the cloud may receive input selecting at least one recommended action in the set of one or more recommended actions. The set of recommendations, in some aspects, may be reviewed by a user, e.g., a grid operator, and the received input may then be used to define a finalized control action/command. For example, the input (e.g., from a user or system administrator) may include a selection of a recommended action or a selection indicating a different action. The user input and/or the finalized control action/command may then be provided to a control component. For example, referring to
At 1414, the cloud may generate, based on the selected at least one recommended action, control data for the multiple DERs. The control message, in some aspects, may indicate an operating mode for the DER in a set of operating modes. The set of operating modes may include a constant voltage operating mode and a constant power operating mode. In some aspects, the control message may indicate a reference value related to a characteristic of the at least one DER. The reference value may be related to one of a voltage magnitude, a power factor, and a reactive power operating point. For example, referring to
Finally, at 1416, the cloud may transmit a control message to the DERs via the set of edge nodes based on the control data. The control message may be transmitted, at 1416, via a secure link between the cloud and the super edge node. For example, referring to
At 1504, the cloud may transmit, via a peer-to-peer network, the data collection protocol to the DERs via a set of edge nodes. The set of edge nodes may include at least one master (super) edge node and multiple private-device edge nodes. For example, referring to
At 1506, the cloud may receive, based on the data collection protocol, data related to the multiple DERs from edge nodes in the set of edge nodes. The data related to the multiple DERs may include data based on the data collection protocol and data regarding the health of elements of the system (e.g., DERs, nodes of the peer-to-peer network, etc.). For example, referring to
At 1508, the cloud may store the received data. The received data may be stored as time series data. The stored data may be stored in the cloud for long-term storage for offline data analysis. For example, referring to
At 1510, the cloud may generate, based on the stored received data, simulation data for training the machine-trained network for processing subsequently-received data related to the multiple DERs. The machine-trained network may be one of a neural network, a convolutional neural network, or other artificial intelligence network as may be appropriate. The simulation data, in some aspects, is generated by a model solver based on physical models of the system and the stored data. In some aspects, the simulation data may be used to train the machine-trained network for processing the current data as well as subsequently-received data. For example, referring to
Finally, at 1512, the cloud may generate a system recommendation based on the received data by processing the data with a machine-trained network. The machine-trained network may have been trained with a combination of real-time data and simulation data, such as the simulation data generated at 1510. The system recommendation may include a recommendation for control information and an updated data collection protocol based on the analysis of the received DER data. For example, referring to
As described above, the system described above may address the challenge of the integration cost of incorporating massive amount of machine data from DERs for distribution grid operation. For example, in some aspects, the system may incorporate privately-owned mobile devices to provide access to local DER data, a set of super (or master) edge nodes for providing a first level of aggregation, and a cloud-based system (e.g., software) for incorporating (e.g., aggregating and analyzing) the massive amount of machine data from the DERs.
Additionally, the system described above may address the challenge of coordinating DER operation and leveraging DER capacities for grid operation and new edge services based on the DER data. For example, the cloud-based system may analyze the massive amount of DER data and provide control messages for controlling the DERs to leverage DER capacities for grid operation. This cloud-based control system may also address a lack of resilience of a current grid design. For example, many distribution circuits are radial networks and rely on a substation as the sole energy source and when there is a natural disaster or outage that takes down the utility grid, the downstream customers may run out of power. The cloud-based control system described above may allow DERs to bridge the gap and greatly enhance the resilience and flexibility of grids in the face of failures. Accordingly, utilizing the peer-to-peer network incorporating privately-owned mobile devices providing DER data to a cloud-based control system may provide fault tolerance and avoid a single point of failure for the electrical grid.
The system described above may further provide affordable field infrastructure to allow two-way communication with scattered DERs, ranging over large scale geographical landscapes and with massive amount of data being produced by behind the meter DERs. The communication between the system infrastructure with DERs describe above may be flexible, future proof, and flexible with no single-point of failure. As described above, data acquisition in the cloud-based control system may be flexible and allow a change of a data schema based on analytical needs. The cloud-based control system may also avoid redundant data been transmitted to the cloud and the on-demand data acquisition may reduce overall data volume and throughput.
Computer device 1605 can be communicatively coupled to input/user interface 1635 and output device/interface 1640. Either one or both of the input/user interface 1635 and output device/interface 1640 can be a wired or wireless interface and can be detachable. Input/user interface 1635 may include any device, component, sensor, or interface, physical or virtual, that can be used to provide input (e.g., buttons, touch-screen interface, keyboard, a pointing/cursor control, microphone, camera, braille, motion sensor, accelerometer, optical reader, and/or the like). Output device/interface 1640 may include a display, television, monitor, printer, speaker, braille, or the like. In some example implementations, input/user interface 1635 and output device/interface 1640 can be embedded with or physically coupled to the computer device 1605. In other example implementations, other computer devices may function as or provide the functions of input/user interface 1635 and output device/interface 1640 for a computer device 1605.
Examples of computer device 1605 may include, but are not limited to, highly mobile devices (e.g., smartphones, devices in vehicles and other machines, devices carried by humans and animals, and the like), mobile devices (e.g., tablets, notebooks, laptops, personal computers, portable televisions, radios, and the like), and devices not designed for mobility (e.g., desktop computers, other computers, information kiosks, televisions with one or more processors embedded therein and/or coupled thereto, radios, and the like).
Computer device 1605 can be communicatively coupled (e.g., via IO interface 1625) to external storage 1645 and network 1650 for communicating with any number of networked components, devices, and systems, including one or more computer devices of the same or different configuration. Computer device 1605 or any connected computer device can be functioning as, providing services of, or referred to as a server, client, thin server, general machine, special-purpose machine, or another label.
IO interface 1625 can include but is not limited to, wired and/or wireless interfaces using any communication or IO protocols or standards (e.g., Ethernet, 1602.11x, Universal System Bus, WiMax, modem, a cellular network protocol, and the like) for communicating information to and/or from at least all the connected components, devices, and network in computing environment 1600. Network 1650 can be any network or combination of networks (e.g., the Internet, local area network, wide area network, a telephonic network, a cellular network, satellite network, and the like).
Computer device 1605 can use and/or communicate using computer-usable or computer readable media, including transitory media and non-transitory media. Transitory media include transmission media (e.g., metal cables, fiber optics), signals, carrier waves, and the like. Non-transitory media include magnetic media (e.g., disks and tapes), optical media (e.g., CD ROM, digital video disks, Blu-ray disks), solid-state media (e.g., RAM, ROM, flash memory, solid-state storage), and other non-volatile storage or memory.
Computer device 1605 can be used to implement techniques, methods, applications, processes, or computer-executable instructions in some example computing environments. Computer-executable instructions can be retrieved from transitory media, and stored on and retrieved from non-transitory media. The executable instructions can originate from one or more of any programming, scripting, and machine languages (e.g., C, C++, C#, Java, Visual Basic, Python, Perl, JavaScript, and others).
Processor(s) 1610 can execute under any operating system (OS) (not shown), in a native or virtual environment. One or more applications can be deployed that include logic unit 1660, application programming interface (API) unit 1665, input unit 1670, output unit 1675, and inter-unit communication mechanism 1695 for the different units to communicate with each other, with the OS, and with other applications (not shown). The described units and elements can be varied in design, function, configuration, or implementation and are not limited to the descriptions provided. Processor(s) 1610 can be in the form of hardware processors such as central processing units (CPUs) or in a combination of hardware and software units.
In some example implementations, when information or an execution instruction is received by API unit 1665, it may be communicated to one or more other units (e.g., logic unit 1660, input unit 1670, output unit 1675). In some instances, logic unit 1660 may be configured to control the information flow among the units and direct the services provided by API unit 1665, the input unit 1670, the output unit 1675, in some example implementations described above. For example, the flow of one or more processes or implementations may be controlled by logic unit 1660 alone or in conjunction with API unit 1665. The input unit 1670 may be configured to obtain input for the calculations described in the example implementations, and the output unit 1675 may be configured to provide an output based on the calculations described in example implementations.
Processor(s) 1610 can be configured to receive, from a cloud node, a data collection protocol. The processor(s) 1610 may also be configured to transmit the data collection protocol to each of a plurality of private-device edge nodes (e.g., a privately-owned mobile devices) in a peer-to-peer network and receive, based on the data collection protocol, data relating to the plurality of DERs from the plurality of private-device edge nodes through the peer-to-peer network. The processor(s) 1610 may further be configured to transmit the received data to a cloud-based node (e.g., a cloud system).
Processor(s) 1610 may, in some aspects, be configured to generate, based on a desired system-level analysis, a data collection protocol for implementation at the plurality of DERs and to transmit, via a peer-to-peer network, the data collection protocol to the DERs via a set of edge nodes, the set of edge nodes including at least one master edge node (e.g., a super edge node) and multiple private-device edge nodes (e.g., privately-owned mobile devices). The processor(s) 1610 may also be configured to receive, based on the data collection protocol, data related to the multiple DERs from edge nodes in the set of edge nodes. The processor(s) 1610 may further be configured to generate a system recommendation based on the received data by processing the data with a machine trained network, the machine trained network having been trained with a combination of real-time data and simulation data.
Processor(s) 1610 may, in some aspects, be configured to identify a set of one or more private-device edge nodes capable of receiving data from one or more DERs and to transmit data received from a DER to the edge computing device. The processor(s) 1610 may also be configured to register the identified private-device edge nodes for inclusion in a peer-to-peer network and to transmit, to each of the identified private-device edge nodes in a peer-to-peer network, a data collection protocol for the DERs to implement. The processor(s) 1610 may further be configured to receive, based on the data collection protocol, data relating to the plurality of DERs from the identified private-device edge nodes through the peer-to-peer network.
Some portions of the detailed description are presented in terms of algorithms and symbolic representations of operations within a computer. These algorithmic descriptions and symbolic representations are the means used by those skilled in the data processing arts to convey the essence of their innovations to others skilled in the art. An algorithm is a series of defined steps leading to a desired end state or result. In example implementations, the steps carried out require physical manipulations of tangible quantities for achieving a tangible result.
Unless specifically stated otherwise, as apparent from the discussion, it is appreciated that throughout the description, discussions utilizing terms such as “processing,” “computing,” “calculating,” “determining,” “displaying,” or the like, can include the actions and processes of a computer system or other information processing device that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system's memories or registers or other information storage, transmission or display devices.
Example implementations may also relate to an apparatus for performing the operations herein. This apparatus may be specially constructed for the required purposes, or it may include one or more general-purpose computers selectively activated or reconfigured by one or more computer programs. Such computer programs may be stored in a computer readable medium, such as a computer readable storage medium or a computer readable signal medium. A computer readable storage medium may involve tangible mediums such as, but not limited to optical disks, magnetic disks, read-only memories, random access memories, solid-state devices, and drives, or any other types of tangible or non-transitory media suitable for storing electronic information. A computer readable signal medium may include mediums such as carrier waves. The algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. Computer programs can involve pure software implementations that involve instructions that perform the operations of the desired implementation.
Various general-purpose systems may be used with programs and modules in accordance with the examples herein, or it may prove convenient to construct a more specialized apparatus to perform desired method steps. In addition, the example implementations are not described with reference to any particular programming language. It will be appreciated that a variety of programming languages may be used to implement the teachings of the example implementations as described herein. The instructions of the programming language(s) may be executed by one or more processing devices, e.g., central processing units (CPUs), processors, or controllers.
As is known in the art, the operations described above can be performed by hardware, software, or some combination of software and hardware. Various aspects of the example implementations may be implemented using circuits and logic devices (hardware), while other aspects may be implemented using instructions stored on a machine-readable medium (software), which if executed by a processor, would cause the processor to perform a method to carry out implementations of the present application. Further, some example implementations of the present application may be performed solely in hardware, whereas other example implementations may be performed solely in software. Moreover, the various functions described can be performed in a single unit, or can be spread across a number of components in any number of ways. When performed by software, the methods may be executed by a processor, such as a general-purpose computer, based on instructions stored on a computer readable medium. If desired, the instructions can be stored on the medium in a compressed and/or encrypted format.
Moreover, other implementations of the present application will be apparent to those skilled in the art from consideration of the specification and practice of the teachings of the present application. Various aspects and/or components of the described example implementations may be used singly or in any combination. It is intended that the specification and example implementations be considered as examples only, with the true scope and spirit of the present application being indicated by the following claims.