SYSTEMS AND TECHNIQUES FOR SMART DEMAND SIDE RESPONSE USING DATA PLANE ARCHITECTURE

A system includes a processor and a non-transitory, computer-readable memory that includes instructions executable by the processor for causing the processor to perform operations. The operations include accessing data communications associated with energy consumption from premises data sources located at a premises. Additionally, the operations include generating a premises data set using the data communications associated with the energy consumption and wrapping the premises data set with a set of permissions using a privacy management operation. Further, the operations include receiving a request from an entity to access the premises data set and determining that the entity is permitted to access the premises data set based on the set of permissions. Moreover, the operations include providing the premises data set to the entity.

TECHNICAL FIELD

Implementations described herein relate to utility provision control and, more particularly, to systems and techniques for smart demand side response using a data plane architecture.

BACKGROUND

Generally, utility meters measure the consumption of a resource, such as electricity, water, or gas. Typically, a utility meter is installed at or near a premises to measure consumption on that premises. A utility meter is typically provided by a service provider, which manages the utility meter as needed to ensure that the utility meter is fully operational and that accurate consumption measurements are taken. In some cases, a utility meter has an integrated radio and thereby participates in a smart metering network. Through the smart metering network, the utility meter may report consumption and other information to a remote, centralized headend system that is in communication with and is responsible for services across a plurality of utility meters.

Demand side response (DSR) is one of many ways to adapt electricity systems, which include utility meters of the smart metering network, to renewable energy and increasing demand as key services such as transport and heating are electrified. DSR may face technical challenges with interoperability for device control in a competitive landscape, establishment of data security that is equivalent to security of a smart metering network, and an ability to cope with increasing quantities of data associated with DSR and system participants wanting to act upon that data. With a large quantity of data, maintaining consumer privacy associated with the data also presents a significant challenge. Further, reusing a smart metering network in a DSR system may present issues relating to scalability, maintenance of an end-to-end security model, a lack of trustless messaging, inability to provide data for certain purposes, inability to provide consumer data history and data, and inability to provide portability to support access to billed electricity at locations remote from a premises associated with a billpayer.

SUMMARY

In one implementation, a system includes a processor and a non-transitory, computer-readable memory that includes instructions executable by the processor for causing the processor to perform operations. The operations include accessing data communications associated with energy consumption from premises data sources located at a premises. Additionally, the operations include generating a premises data set using the data communications associated with the energy consumption and wrapping the premises data set with a set of permissions using a privacy management operation. Further, the operations include receiving a request from an entity to access the premises data set and determining that the entity is permitted to access the premises data set based on the set of permissions. Moreover, the operations include providing the premises data set to the entity.

In another implementation, a non-transitory computer-readable medium may include instructions that are executable by a processor for causing the processor to perform operations. The operations include accessing data communications associated with energy consumption from premises data sources located at a premises. Additionally, the operations include generating a premises data set using the data communication associated with the energy consumption. The operations also include wrapping the premises data set with a set of permissions using a privacy management operation. Further, the operations include receiving a request from an entity to access the premises data set and determining that the entity is permitted to access the premises data set based on the set of permissions. The operations also includes providing the premises data set to the entity.

In yet another implementation, a computer-implemented method includes accessing, at a demand side response data plane, data communications associated with energy consumption from premises data sources located at a premises. The method also includes generating, at the demand side response data plane, a premises data set using the data communication associated with the energy consumption. Additionally, the method includes wrapping, at the demand side response data plane, the premises data set with a set of permissions using a privacy management operation. Further, the method includes receiving, at the demand side response data plane, a request from an entity to access the premises data set and determining, at the demand side response data plane, that the entity is permitted to access the premises data set based on the set of permissions. Moreover, the method includes providing, from the demand side response data plane, the premises data set to the entity.

These illustrative implementations are mentioned not to limit or define the disclosure, but to provide examples to aid understanding of the invention. Additional implementations are discussed in the Detailed Description, and further description is provided there.

DETAILED DESCRIPTION

Several challenges exist in the current implementation of demand side response in electricity systems. Accordingly, a technical architecture that supports a shift to a smart grid will need to scale to support use cases present today and use cases that will be present in the future. In an example, using existing electricity systems, such as a point-to-point architecture, in a demand side response implementation may result in challenges of interoperability, scalability, and security. Given these challenges, a new architecture described herein that reuses, but builds upon, the smart metering network may address the challenges of the existing electricity systems in the demand side response implementation.

The architecture makes use of concepts from telephony networks to separate interoperability concerns and to provide a useful layered conceptual framework for considering demand side response interoperability. In an example, secure control of devices is separated from security and privacy management of data in an energy system control plane and an energy system data plane. The control plane may reuse the smart metering network to provide the benefits of communication reach of the smart metering network, while the data plane may overcome inherent issues of data access. For example, the data access may inherently be slow and cumbersome across a Wide Area Network, and the data may be stored for access in separate data silos such that accessing complete data presents a complex access problem across a wide range of energy industry organizations.

The architecture becomes scalable by gathering a home data set, or a data set associated with an individual premises or a set of premises associated with a billpayer, into a singular unit of data portability in the cloud and wrapping the home data set in a privacy and security management layer. Such an architecture may provide a secure and highly granular privacy model. Further, by enabling a powerful anomaly detection capability in a customer energy management device associated with the premises and creating a new energy management system, trustless security that underpins a smart metering security model can be maintained and enhanced across the smart grid. The energy management system may also provide a mechanism for using the energy system control plane as a demand side response control plane for use with centralized security monitoring and detailed whole network analysis.

FIG. 1is a diagram of an example distributed architecture100for a secure control plane, according to some implementations described herein. The distributed architecture100includes a customer energy manager (CEM)102that collects and compiles data relating to an energy consuming and monitoring devices in a home104. WhileFIG. 1is described with respect to the home104, any other energy consuming premises may also be associated with a CEM that collects data relating to the energy consumption at the premises. In an example, the CEM102collects the data relating to energy consumption of the home104and provides a control infrastructure for components within the home104based on the collected data.

The distributed architecture also includes an interface A106and an interface B108that communicate with the CEM102to provide demand side response to a demand side response service provider (DSRSP)112and an energy smart appliance gateway (ESAG)114. The DSRSP112and the ESAG114may provide communication gateways for the CEM102to obtain data from energy consuming devices within the home104and to control operation of the energy consuming devices within the home104. For example, the DSRSP112, which may be an energy retailer, may provide data to the CEM102regarding energy provided from the DSRSP112to the home104, and the ESAG114may provide more granular data to the CEM102relating to energy consumption of energy smart appliances116, which communicate with the ESAG114within the home104. As used herein, the term energy retailer may refer to an entity that provides an energy user with an option for purchasing energy wholesale. In some examples, the energy retailer may be part of a utility company, while in additional examples, the energy retailer may not be affiliated with the utility company.

Additionally, the CEM102may include a tunneled Open Charge Point Protocol (OCPP)110that communicates across a wide area network (WAN) to support electric vehicle charging. For example, the tunneled OCPP110provides communication between the CEM102and electric vehicle supply equipment (EVSE)118and a mobility service provider (MSP)136. In an example, the MSP136may be a provide mobility products and services to an EV operator, and the MSP136can provide control signals to the EVSE118through the CEM102. The control signals provided by the MSP136to the EVSE118may include an unlock signal that enables the EVSE118to begin charging an electric vehicle120. Upon receiving the unlock signal, the EVSE118may provide power to charge an electric vehicle120at the home104.

The distributed architecture100also includes a data plane122that stores and analyzes data generated at and received from energy consumption data sources the home104. In some examples, the data plane122may be a server that is located remotely from the CEM102and the home104. The data plane122includes a home data set124that may include a copy of the data from each home on an electrical system. The data plane122also includes anomaly detection engines126, frontend APIs128, data analysis engines130, data management engines132, and a flexibility data gateway134to support flexible data storage at the data plane122.

The inclusion of the CEM102may preserve trustless end-to-end encryption of data using a smart metering system with the DSRSP112. Further, a whole-home-focused concept of anomaly detection and mitigation can be implemented. For example, the home data set124associated with the home104and received at the CEM102may result in the CEM102detecting and mitigating anomalies occurring on an electrical system of the home104to avoid events that may result in load shifting that could destabilize the grid. In some examples, anomaly detection may refer to detection of consumption events or patterns that may relate to the load shifting. In additional examples, the anomaly detection may refer to detecting components, such as the CEM102that are not operating properly.

In an example, the data plane122wraps consumer personal data generated by premises data sources at the home104in a security and privacy management service, where the consumers assert ownership of the consumer data and license the consumer data to approved DSR market participants (e.g., an entity that is able to perform a demand side response operation on devices within the home104) and for analytic functionality for value adding services. The consumer personal data may include any data associated with a billpayer that is received from devices within the home104and relevant to energy consumption within the home104. In some examples, the consumer personal data may also include data generated by a metering device125such as through a distribution system operator (DSO)127, which is responsible for distributing and managing energy from a generation source to a final consumer (e.g., the billpayer associated with the home104). Maintaining the home data set124, which the DSR market participants may update to and access, establishes a problem of managing complex permissions. Developments in the field of cryptography, blockchains, smart contracts, and non-fungible tokens (NFTs) may simplify the problem of managing complex permissions.

For example, the data plane122may rely on an Ethereum blockchain to manage the permissions. Ethereum is a highly distributed, shared virtual machine which runs secure scripts and decentralized applications called smart contracts. Ethereum also includes a third-party decentralized filesystem. Similar to other implementations of blockchains, transaction entries in the Ethereum ledger are decentralized, immutable, and secure. For example, each node in the Ethereum network has a copy of the distributed ledger. There is no single point of failure or central authority to compromise. Additionally, once a transaction is entered in the ledger, each node in the network checks the validity of the transaction to arrive at a consensus regarding the transaction validity. If the entry is deemed valid, then the transaction is added to the ledger. There are a number of mechanisms for achieving consensus, such as a “Proof of Authority” mechanism, which enables a very rapid consensus to be achieved. Moreover, entries on a ledger are made up of cryptographic hashes that can be written with a public key. Accordingly, entries on the ledger are secure and not visible if a node is compromised.

The Ethereum Virtual Machine (EVM) is a sandboxed virtual machine that runs in each Ethereum node. Code written to compile to EVM bytecode is referred to as a smart contract and is most commonly written in a “Contract Oriented” programming language like Solidity and compiled to EVM bytecode for execution. In this manner, executed code is completely isolated from the network, filesystem, or any processes of the host computer. Every node in the Ethereum network runs an EVM instance and this enables the nodes to arrive at a consensus for executing the same instructions. This arrangement may enable secure code to be run in a trustless manner that is an enhanced form of trustlessness to the trustlessness existing in the control plane122. For example, the trustlessness of the control plane122involves two participants. In contrast, the EVM trustlessness can involve all participants on the Ethereum network. For the sake of efficiency and minimizing electricity consumption, a chain configuration using Proof of Authority may rely on only a few participants of the Ethereum network to achieve consensus. In this manner, the EVM effectively exists at the Ethereum Network Level as a highly distributed single computer.

The smart contracts used on the Ethereum network are “object like” code that runs on the EVM. The smart contracts are tamper proof in that the code cannot be changed. Further, the smart contracts are immutable in that the records cannot be changed. The smart contracts are composable in that one smart contract is able to interact with other smart contracts. Further, the smart contracts are auditable both in the code sense and the transaction sense, and the smart contracts are cryptographically sound.

In an example, a non-fungible token (NFT) may be a cryptographically sound and unique representation of digital assets. The NFT may include an entry in a distributed ledger and a unique token that is cryptographically linked to that entry. Fungibility refers to the uniqueness of the asset. The NFTs may be used to create a digital concept of ownership. In implementation with the Ethereum network, the rules that constrain what can be done with an asset may be mediated by smart contracts. Thus, different NFTs can be mediated by their own system of interacting smart contracts, and more than one NFT may be assigned to an asset. Possession of an NFT can be made to determine what can be done with that asset, and an NFT can represent the permissions an NFT owner has with that asset.

The combination of smart contracts and NFTs may enable an approach to permissioning data and functionality for the home data sets124. Ethereum's combination of an immutable ledger and EVM with trustless execution may enable assignment and management of permissions dynamically. The native functionality of smart contracts within Ethereum may also enable complex certificate hierarchies that can be dynamically created and managed. A hardware security model (HSM) of the ESAG114may operate as a certifying authority with a root certificate. The HSM may validate and add key sets representing individual billpayers, and the individual billpayers in turn can sign certificates in the data plane122that can be used to encrypt data generated at the home104at rest and in flight. Further, a billpayer's identity certificate can be used to sign the certificates used on the Ethereum blockchain for hashing operations. This security approach enables a billpayer to take on the role of data controller.

In recognizing ownership rights of household members other than the billpayer, the ESAG114can relate each identity of the household members to the billpayer, and NFTs can be used to manage collective data rights of the household with the billpayer serving in a nominated decision maker role. Additionally, a concept of a data trust, that is a data set associated with a home, may be sold as part of a home purchase such that a new owner can take advantage of the historical data set that already allows the CEM102to optimize for that home104or other premises.

Implementation of the permissions management provided by the Ethereum network may enable implementation of a form of billpayer controlled licensing. The DSRSPs112, charge point operators (CPOs), and CEMs102can define access requirements and time periods for the billpayer's data and request a license from the billpayer to use the data. Such requests can be provided to the billpayer on an in-home user interface. The permissions management system may also allow for licensing of functionality. Using modern cloud capabilities in serverless functions, flexibility service providers may write their own functions and deploy them directly into the data plane122, as permissioned by the billpayer, to analyze the billpayer's own home data set124.

Further, with so much billpayer control over the use of data, a basic level of permissions may be implemented for the data plane122to function. The basic level of permission may be implemented as a basic license pack the covers a minimum set of permissions a billpayer needs to grant to use the data plane122. The basic level of permission may include a basic functionality in the data plane122required to change energy suppliers at the home104. Additionally, the basic level of permission may also include granting a form of court ordered access to data sets or procedures for handling events like the death of a billpayer. In an example, implementing the licenses as smart contracts may help promote public trust in the system.

FIG. 2is a diagram of an example energy management control system200, according to some implementations described herein. The energy management control system200includes a CEM manager202(i.e., an energy management system) that enables trustless messaging for the CEM102and that also manages higher order security concerns for the whole electrical system associated with the data plane122ofFIG. 1. As illustrated, the CEM manager202can include a one-to-many relationship with the CEM102. That is, an individual CEM manager202may be associated with several CEMs102that are each associated with individual premises. In an example, the CEM manager202monitors and manages commands that are received at the CEM manager202to ensure that, in the event of the CEM102being compromised, the energy management control system200will not allow a mass load shifting event to destabilize the grid. Because the CEM manager202has a view across many CEMs102, anomaly detection (AD) employed in both the CEM102(e.g., of an individual premises) and the CEM manager202(e.g., of several premises) can provide a more robust anomaly detection and mitigation than anomaly detection based on data received from a single premises. The anomaly detection may refer to anomalies associated with both messaging of the CEM102or the CEM manager202and with operating parameters of the grid system. For example, anomaly detection may involve detecting conflicting control signals to energy consumption devices within the home104(e.g., running the heater and the air conditioner at the same time). Further, the anomaly detection may involve detecting grid abnormalities or situations that my result in grid abnormalities. For example, the anomaly detection may involve detecting too many EVs being charged at a particular time, or an continually increasing number of EVs beginning a charge cycle over a period of time. Other anomaly situations may also be detected by analyzing data of energy consumption devices at a premises.

The CEM102may be associated with an individual premises. In other words, the consumer has a single portal through the CEM102to control and communicate with smart grid devices at the premises. The platform nature of the data plane122can enable a ‘plug-in’ capability for manufacturers of energy smart appliances (ESAs) or demand side response service providers (DSRSPs)112and charge point operators (CPOs)204to create enhanced, value-added services that may not be possible without visibility of the whole home data set of the premises104. In an example, the communication between the CPO204, the CEM102, the CEM manager202, and the DSRSP112may all rely on interoperable data of the whole home data set of the premises104for enhanced anomaly detection.

FIG. 3is a diagram of an example demand side response control plane302and the demand side response data plane122, according to some implementations described herein. As discussed above with respect toFIG. 1, the data plane122includes the flexibility data gateway134, which provides an access point for the data received from the control plane302. An orchestration layer304of the data plane122may be a distributed layer that is capable of coordinating a change of supplier to a billpayer and a change of tenancy event of a billpayer. The orchestration layer304may also provide support for push and pull messaging events.

In an example, home data analysis and management environment (HDAME) permissions306provide a mechanism for configuring and storing data and functions permissions. The HDAME permissions306may include smart contracts, NFT functionality, and a distributed ledger that records the smart contracts. In some examples, the smart contracts and NFT functionality may establish permissions for various entities to receive and use data relating to energy consumption of a billpayer. The data relating to the energy consumption may be associated with a premises of the billpayer or with a remote premises visited by the billpayer, such as through an electric vehicle (EV) mobility wallet310that enables roaming use of residential EV chargers. Additionally, the smart contract and NFT functionality of the HDAME permissions306may provide function permissions that enable a sophisticated dynamic approach to managing permissions and user licensing of regulated (e.g., with the energy retailers and entities providing DSR control) and third-party functionality (e.g., with third-parties providing data analysis, academic research, or other services). The transaction ledgers of the HDAME permissions306include a master record of every transaction that occurs on an HDAME308as well as every NFT. The transaction ledger may maintain as a transaction record a pointer to a distributed object store where the home data set124is held.

Further, the data plane122includes one or more HDAMEs308. The HDAMEs308may include the home data set124(or premises data set). The HDAMEs308may also be a permissioned area, as established by the HDAME permissions306, where custom analytic functionality can be provided to deliver services that are directly licensed by the consumer (e.g., a billpayer). In an example, the HDAMEs308may include the anomaly detection engines126, an EV mobility wallet310, data management engines132, data analysis engines130, and access management functionality314.

The HDAMEs308may be deployed as serverless functions that are cryptographically tied to smart contracts in the EVM via NFTs. Each function may be provisioned with appropriate NFTs and interfaces that are secured and tightly permissioned using the PEPKI. Other approaches may also be used, but serverless functions represent a highly efficient approach to delivering functionality at a minimal cost. In an example, an HDAME308can be deployed in a single subnet of a larger network.

The home data set124may be a data set that includes a time series of data (e.g., time-stamped data) from premises data sources such as the ESAs116and the EVSEs118. Additionally, the home data set124may be enriched with smart meter data which may be ingested from the ESAG114via a consumer access device of the smart meter. In an example, the home data set124includes a register of which energy suppliers are associated with each device, and the register may be considered a master record for the supplier information. The energy suppliers of a device may change over time, and the register may be updated as the energy suppliers change. To enable additional functionality in either the anomaly detection engine126, the data management engine132, or the data analysis engine130, the data set may be enriched with information about the weather and local conditions.

The anomaly detection engine126may be used for analysis of the home data set124in response to a query from the CEM102as a part of the trustless message flow of the control plane302. Access to the home data set124may enable the anomaly detection engine126to detect if a message undergoing verification will interact in an unsafe way (e.g., as a detected anomaly) with the current state of a device that is outside of a system actor's (e.g., the DSRSP112, the CEM102, the CEM manager202, the MSP136, the ESAG114, etc.) range of visibility into the home. The anomaly detection engine126can also be established with an agreed set of rules to apply to messages to decide whether a message should be verified through a secure communication mechanism. The anomaly detection engine126may be maintained by a regulated and audited process to ensure reliability.

The EV mobility wallet310may track an expenditure of a billpayer while using third party EVSEs118. Updates between wallets can be made using the orchestration layer304.

The data management engine132may include the basic regulated functionality of the HDAME308including basic data management aggregation and regulated anonymization processes. Regulated functionality may refer to the regulation of data in a manner that respects privacy of a data owner. The regulated anonymization processes may use support in the orchestration layer304to aggregate and move anonymized data securely into other analytic environments while respecting the privacy of the data owner (e.g., the billpayer). The anonymization processes may be useful for academic access or specific analytic needs of the transmission systems operators and distribution systems operators and even relevant government entities. The data management engine132may be maintained by a regulated and audited process.

The data analysis engine130may be the platform functionality of the data plane122. The data analysis engine130can be considered an accompaniment to the concept of the CEM102. The data plane approach to permissions management and secure storage means DSRSPs112, MSPs136, CEMs102, and CEM managers202may each deploy sets of analytic functionality into the HDAME308after requesting a license from the data owner.

The access management functionality314includes a regulated functionality that enables data to be securely accessed and stored. The access management functionality314may be maintained by a regulated and audited process.

For data security, a data plane key infrastructure (DaPKI) may be used to secure access to the data plane122for industry participants, such as the target actors (e.g., controllers of a control plane302such as the DSRSP112, the CEM102, the CEM manager202, the MSP136, the ESAG114, etc.). In an example, a personal energy public key infrastructure (PEPKI), which creates a public key infrastructure (PKI) for every home and individual security digital certificates for each billpayer, may enable the billpayer to control licensing of access to billpayer data through the smart contracts of the HDAME permissions306. This security infrastructure may ensure that the billpayer remains the data owner with control over a boundary of privacy for the home data set124.

The data plane122may interact with the control plane302through the flexibility data gateway134. For example, the DSRSP112, the CEM102, the CEM manager202, the MSP136, the ESAG114, or any other control components of the control plane302may all write message content to the data plane122through the flexibility data gateway134. Further, the components of the control plane302may receive aggregated data from the data plane122. In an example, the aggregated data may be acted upon by the components of the control plane302to control operation of energy consumption devices in a manner that avoids or mitigates anomalies or destabilizing load shifts on the grid.

The flexibility data gateway134, in an example, provides a single access point from the control plane302to the data plane122. Data paths to the data plane122may be encrypted in transport and users may be authenticated. The data that is requested from the data plane122can be encrypted to a target of a valid requester. To enable the encryption, the DaPKI may be established that is separate from the ESAG-based home API. Thus, even if the data plane122is implemented in a public cloud infrastructure, the flexibility data gateway134may still be located within a secure network that is separated from the Internet.

As discussed above with respect toFIG. 1, the Ethereum virtual machine (EVM) may exist in a distributed manner between deployed Ethereum nodes. The data plane orchestration layer304includes a system of smart contracts that manage updates to individual HDAME supplier registers as well as messaging support for push and pull events to and from the flexibility data gateway134. Ethereum may also support a highly secure, distributed file system called interplanetary filesystem (IPFS), which can be used as secure transport for messaging between the HDAMEs308. In an example, the orchestration layer304, being a common distributed component, may make use of certificates provisioned from the DaPKI. Further, change of supplier and change of tenancy processes may include a coordinated series of updates to the HDAME supplier register and confirmations from the losing and gaining suppliers. Both the change of supplier and the change of tenancy processes may be used to manage the movement of permissions and potentially data between the HDAMEs308.

With the data stored only on a meter device, the more parties that need to access data the less scalable a data processing architecture becomes when constrained by bandwidth. The data plane122, which may be stored remote from the metering device, enables fragmentation and distribution of all consumer data into the home data sets124, which may be convenient units of data portability. For example, the data plane122enables encryption of consumer data at rest (e.g., while the data is stored at a memory device of the data plane122) and in flight (e.g., while the data is being transmitted from the data plane122to a target actor); secured, permissioned, licensed, and managed by the consumers' own PEPKI. Further, the data analysis engines130running in the HDAME308may be licensed and permissioned using the same PEPKI of the consumer. Within the perimeter of an individual HDAME308, the PEPKI may be used for all cryptographic operations both within the Ethereum component perimeter and to secure data in flight and at rest.

Although a smart metering system at a premises generates much useful data, accessing the data may be difficult, expensive, and complex. By implementing the HDAME permissions306of the data plane122, accessing data from the premises for innovation or research purposes becomes much more straightforward, and the consumer has full granular privacy control over what data specific parties are able to access from the home data set124. For example, the PEPKI enables a complete home data set124(e.g., of a premises or associated with a billpayer) to be maintained securely in a manner that is able to be licensed and permissioned to specific parties by the billpayer. A billpayer may decide to grant licenses for some kinds of academic research, whereas other types of access for academia or other public benefit may be mandated through the concept of an agreed and regulated basic licensing package, which a billpayer would agree to as a basic condition of participation in the system.

Further, as energy consumption becomes more common in a roaming environment, such as with electric vehicles, portability of the system becomes much more desirable. The architecture of the data plane122may enable portability to roam to other domestic chargers outside of a consumer's premises, and a system of home charging for guests or a series of other possible innovative services may be generated. This may be enabled both by the permissioned functionality in the data plane122and the speed and ease of access of data afforded by the data plane122.

The data plane122may also provide aggregation of home data sets124from different premises. In some examples, each of the home data sets124may be secured, and the billpayers associated with each of the home data sets124may provide permissions for target actors to access the home data sets124. Aggregation may enable grid optimization by orchestrating activities of small distributed energy resources (e.g., solar power, EV charging, wind power, etc.) to allow the system to respond from both a supply side (e.g., power generation) and the demand side (e.g., through demand side response). In an example, accurate and timely telemetry from sensors across transmission lines, distribution lines, and in the home may enable a comprehensive view of activity on the electricity grid. Optimization activities enabled by the data plane122and the control plane302may include optimizing power flows within a distribution network, responding to voltage sags and swells within the distribution network (e.g., anomalies), and local grid load management, where the local network may need reinforcing. The local network may need reinforcing, for example, when a number of electric vehicles commence charging in a particular area.

FIG. 4is a diagram of a flow of data400between devices generating the data at a premises and devices storing the data, according to some implementations described herein. The smart meter devices402may include electricity smart meters (ESME), prepayment meter interface devices (PPMIDs), consumer access devices (CAD), gas smart meters (GSMEs), in-home displays (IHD) for smart meters, standalone auxiliary proportional controllers (SAPCs), or any other devices that operate to provide functionality to smart meters. Smart meter devices402may generate a wealth of useful sensor telemetry that tracks both consumption and a range of power quality indicators at premises associated with the smart metering devices402. The smart metering devices402may also enable remote disconnection of a premises and remote control of compatible devices.

In some examples, smart metering devices402from a number of different manufacturers may all operate on the same home area network (HAN). Because the smart metering devices402originate from a number of manufacturers, interoperability between the smart metering devices402that are deployable in a number of combinations may be useful for implementation of the smart metering devices402with the data plane122and the control plane302. As illustrated, any number of controlling applications404may be deployed to control the smart metering devices402. For example, one or more meter data management systems (MDMSs)406or data and communications company (DCC) adaptors408may be implemented to receive data from the smart metering devices402and provide control functionality to the smart metering devices402.

Role based access control (RBAC) may be established to provide authorization to access smart meter data406to a number of parties. In some examples, the RBAC may provide end-to-end encryption, trustless messaging, and user authentication. Due to the security model and the privacy model, the DCC adaptors408of the controlling applications404may operate as a data processor. For example, the interaction of the interoperability of the smart metering devices402combined with the security model and the privacy model ensures that customer data that rests with an energy retailer is only the data that a DCC user role authorizes the retailer to have access to and only for so long as that user is a customer of the retailer. This ensures that the smart meter data sets406are fragmented, siloed, and protected by design and that the use of the smart meter data sets406is regulated in accordance with permissions provided by the customer (e.g., the owner of the smart meter data sets406).

FIG. 5is a diagram of an example of a logical architecture500for demand side response, according to some implementations described herein. The logical architecture500includes three logical components: (1) the demand side response service provider (DSRSP)112; (2) the customer energy manager (CEM)102; and (3) the energy smart appliance (ESA)116. The role of the DSRSP112may be to aggregate ESAs116in dispatchable units (e.g., energy consumed by the ESAs116for a given amount of time) for sale to distribution system operators (DSOs)502(e.g., the DSO127ofFIG. 1) and transmission system operators (TSOs)504(e.g., entities entrusted with transporting energy on a national or regional level using an energy transmission system infrastructure). The DSRSP112may also operate to ‘optimize on behalf of’ distribution and transmission networks. A single home104or premises may have a number of different DSRSPs112providing flexibility services to the home104or premises. This may raise the possibility of contradictory control signals being sent to ESAs116. For example, one DSRSP112may provide an erroneous instruction to engage a heater in the home104and another DSRSP112may provide an instruction to engage the air conditioner in the home104at the same time. This type of collision may be mitigated with the anomaly detection engines126of the data plane122with a view of the whole home data set124, as described above with respect toFIG. 1.

Additionally, the CEM102may also provide optimizing functionality. Given the role of the DSRSP112that optimizes on behalf of the distribution and transmission networks, the CEM102may operate to optimize on behalf of the individual home104or premises. Accordingly, consumer focused role of the CEM102may suggest a supervisory role for the CEM102in relation to the DSRSP112or a charge point operator (CPO). Providing anomaly detection and message verification at the CEM102would enable the DSRSP112or CPO to implement an end-to-end trustless messaging system. To fulfil the role of optimizing on behalf of one home or premises, the CEM102may have an overall view of telemetry from devices in the individual home or premises that are generating data relating to energy consumption.

Further, the ESAs116can be intelligent major appliances, HVACs, inverters connected to batteries, solar cells, or other intelligent appliances within a home or premises. In other words, the ESAs may be distributed energy resources that DSRSPs112aggregate on behalf of the DSOs502and the TSOs504. The ESAs116may be capable of being contacted by the CEM102or the DSRSP112while making no protocol level distinction between which messages can be processed by each. Additionally, the ESAs116may authenticate and encrypt/decrypt messages from CEM102, DSRSPs112, and the CPOs.

In some examples, the CPOs, such as the CPO204ofFIG. 2, may be included in addition to the DSRSPs112, the CEM102, and the ESAs116. The CPOs may be an open charge point protocol (OCPP) compliant, electric vehicle supply equipment (EVSE) controlling application. In an example, the CPOs may be adapted to support end-to-end trustless messaging by creating a similar relationship with the CEM102as the DSRSPs112to enable the benefits of anomaly detection by the CEM102with a view of the whole home data set.

In an example, the EVSE, such as the EVSE118ofFIG. 1, is OCPP compliant with an integrated standalone auxiliary proportional controller (SAPC) for distribution network operator (DNO) load control override. The EVSE may also implement end-to-end security with the CPO. In an example, the EVSEs are capable of being contacted by the CEM102or the CPO while making no protocol level distinction between which messages can be processed by each. Additionally, the EVSEs may authenticate and encrypt/decrypt messages from CEM102, the DSRSPs112, and the CPOs.

The CEM manager202(e.g., an energy management system) may provide a second anomaly detection capability that manages the activity of several of the CEMs102. For example, a CEM102that appears to be malfunctioning or poorly functioning can have its ability to send and verify messages throttled by the CEM manager202. Additionally, the 1 to many relationships between the CEM manager202and the CEMs102may enable management and supervision of the CEMs102. For example, the CEMs102can be grouped by manufacturer and/or geographic location or any other number of logical groupings that enable security and safety oversight. The implementation of the CEM managers202may provide the ability to aggregate data to anticipate risks to homes and premises and to bolster grid stability. For example, the CEM managers202can detect and mitigate anomalies resulting from rapid cycling of high current appliances or new sources of harmonic distortion, such as heat pumps, across a plurality of homes and other premises.

FIG. 6is a diagram of an example of data cardinality of an energy management device associated with a premises, according to some implementations described herein. As shown, the premises may include the home104, but other premises may include similar data cardinalities. The data cardinality, which illustrates a number of devices with which each device is able to communicate, depicts challenges for anomaly detection and optimizing functions when consumer data is moved around controlling applications while preserving the high level of security and privacy established for the consumer data. For example, the CEM102may communicate with an individual home104, but the individual home may include a large number of devices (e.g., EVSEs118and ESAs116such as heating, ventilation, and air conditioning (HVAC), cold and wet appliances, battery storage, etc.) that generate data accessible by the CEM102. Further, DSRSPs112, CPOs204, and DSOs502may also all communicate with a number of devices that generate data. This fragmentation may make anomaly detection making use of this information difficult, and the whole home data set concept may enable data portability to simplify data access while meeting security and privacy concerns associated with the system.

In some examples, the CEM102may optimize the devices within the home104using interoperable data from the devices within the home104. Additionally, the DSRSP112and the CPO204may rely on interoperable data from the devices within the home104to provide anomaly detection. The DSO502may not rely on interoperability from the standalone auxiliary proportional controller (SAPC) to operate.

FIG. 7is a diagram of an example of component organizational relationships of an energy management control system700, according to some implementations described herein. In an example, a billpayer702that lives in the home104may subscribe to the CEM102. As discussed above, the CEM102is implemented as a software component that manages and optimizes operations of energy consumption within the home104. The billpayer702may also subscribe to the DSRSP112and the mobility service provider136.

The DSRSP112may function to optimize components of the home104on behalf of distribution and transmission networks. Accordingly, the DSRSP112may request flexibility from the CEM102to aggregate the ESAs116and the EVSEs118associated with the home ESAG114for sale to distribution system operators and transmission system operators. In some examples, the DSRSP112may use the data obtained from aggregating the ESAs116and the EVSEs118to provide flexibility charges and credits to a retailer704. The retailer may use the flexibility charges and credits in addition to meter readings to generate a bill provided to the billpayer702. In some examples, a credit may include an indication that power consumed by the EVSE118at the home104was used to charge the electric vehicle120owned by a separate billpayer. In the example, the separate billpayer may be billed for the that charging operation, and the billpayer702living in the home104will not also be billed. Other credits and charges may also be provided to the retailer704in a similar manner.

Additionally, the mobility service provider136controls or manages the EVSEs118for charging the electric vehicle120. The mobility service provider136may request flexibility from the DSRSP112to control or otherwise manage the EVSEs118. Further, the mobility service provider136may provide a bill to the billpayer702based on the charging operations performed by the EVSEs118.

Because of the complex interactions between controller components (e.g., the CEM102, the mobility service provider136, and the DSRSP112), which would also lead to complex interactions between privacy and security models, a whole home data set, such as the data set124ofFIG. 1, may be generated to simplify these interactions between the controller components. The whole home data set may include all telemetry data generated within the home104and a register of suppliers that are associated with each of the devices generating the telemetry data. In this example, data flows once from a device to a controller before being uploaded into the whole home data set. Interoperability of the devices within the home104can be achieved by managing which entities have permission to access the whole home data set.

Once the whole home data set is generated, the data set associated with one home becomes a unit of storage, management, and reporting. The home data set should be the minimum unit of storage distribution. The data, stored for example in the cloud, can be distributed as widely as enabled by performance requirements. In an example, the home data sets are stored both logically and physically separate from each other to enhance security and, if required, fragmented further while preserving data structure. Additionally, data items included in a home data set may be encrypted at rest and access to the home data set may be permissioned. Further, any reports or analyses of the home data set may be dynamically produced and encrypted to a target of a valid requestor. In using these security and permissions schemes, the billpayer and the devices in the home104are the boundary of privacy and not the home104itself.

In an example, the home data set and its contents are tagged with relevant industry identifiers such as meter point administration numbers (MPANs) and other submeter identifiers. Further, the home data set may also include a register of which energy suppliers are associated with each ESA and EVSE, and the register may provide a system of record for the home data set.

FIG. 8is a flowchart of a process800for performing demand side response with an energy management control system, according to some implementations described herein. At block802, the process800involves obtaining or accessing, validating, and decrypting data communications from home components. In an example, the home components may be any telemetry enabled devices at a premises capable of transmitting data relating to energy consumption at the premises across a communications interface.

At block804, the process800involves generating home data sets based on the data received from the home components. The home data set, which may be stored at the data plane122, may provide a whole home view of the data consumption at the premises. The whole home view may be valuable for analysis and anomaly detection used in optimizing energy consumption in a demand side response system.

At block806, the process800involves wrapping the home data sets with a permissions based on a privacy management operation. The permissions wrapping the home data sets may prevent entities or data targets that have not received the appropriate permissions from a billpayer from accessing the data. The billpayer may generate the permissions for the entities based on the specific entities or based on the functions provided by the entities.

At block808, the process800involves receiving a request for home data sets from an entity, and, at block810, the process800involves determining if the entity has access to the home data set based on the permissions provided by the billpayer. If the entity does have access based on the permissions, then, at block812, the process800involves providing the home data set to the requesting entity. Otherwise, the process800involves denying the entity access to the home data set.

FIG. 9is a diagram of an example Personal Energy Public Key Infrastructure (PEPKI) trust flow900, according to some implementations described herein. The illustrated PEPKI trust flow900includes a trust flow for two billpayers902and904. In an example, the billpayers902and904may be associated with the ESAG114of a premises. In some examples, the billpayer904may a household member other than the billpayer902that is a co-owner of the data transmitted from the premises. An in-home graphical user interface (GUI)906may be used to interact with the billpayers902and904to provide a license management scheme908for the data generated that is associated with the billpayers902and904. For example, the GUI906may provide a mechanism for the billpayers902and904to grant licenses to various entities for use of the data.

The ESAG114may assign a personal energy public key infrastructure (PEPKI) root certificate for each of the billpayers902and904. The billpayers902and904can communicate through a home gateway to generate smart contracts using the PEPKI root certificate that provide data permissions for various entities. In the data plane122, the data licenses may be communicated to the HDAME permissions306, and billpayer HDAME data, function, and ledger master certificates may be provided to an Ethereum management cryptographic operation910.

FIG. 10is a diagram of an example Data Plane Key Infrastructure (DaPKI) trust flow1000, according to some implementations described herein. In an example, hardware security managers (HSMs)1002may be used at the edges of the system by a target actor1004(e.g., as described above with respect toFIG. 3). Within the data plane122, the minimization of the HSMs1002to keep costs down and take advantage of efficiencies inherent in public cloud infrastructures may be beneficial. System actors, such as target actors1004, will rely on keys provisioned to decrypt data. Accordingly, the target actors1004may provide private keys1006,1008, and1010to the data plane122to decrypt data. Using the private keys1006,1008, and1010, the public keys1012,1014, and1016may be generated for use with the Ethereum managed cryptographic operations910. In this manner, the DaPKI trust flow1000enables trustless interaction in the data plane122by the target actors1004.

Processing power from distributed resources throughout the Ethereum network may be used to process the Ethereum managed cryptographic operations910. This power may be referred to as fuel. Ethereum networks may enable distributed Ethereum nodes to contribute fuel to help make the network secure. These nodes can be located at organizations such as industry participants like retailers, DSOs, DSRSPs, etc. and industry bodies such as Elexon and the Electricity Networks Association. ESAG logical devices may also be used as a source of fuel to contribute to the security of the system.

FIG. 11is a flowchart of a process1100for establishing trustless messaging for an energy management system, according to some implementations described herein. At block1102, the process1100involves establishing permissions for home data sets. The permissions may be based on privacy regulations and the information that a billpayer has agreed to license for various purposes. For example, the billpayer may license the home data set to various entities for analysis and anomaly detection. The licenses may be recorded using smart contracts, NFTs, and a ledger of an Ethereum network.

At block1104, the process1100involves generating cryptographic representations of the home data sets based on the established permissions. For example, the home data set or portions of the home data set may be encrypted in a manner that is available for access only by entities with permissions or licenses granted by the billpayer.

At block1106, the process1100involves transmitting the cryptographic representation of the home data set to a target with adequate permissions. The target may be a data analysis engine, a CEM manager, an academic or government entity, or any other target that has been granted permissions by the data owner.

FIG. 12is a block diagram of an example computing device1200, according to some implementations described herein. The computing device1200includes a processor1204(possibly including multiple processors, multiple cores, multiple nodes, or implementing multi-threading, etc.). The computing device1200also includes a memory1208. The memory1208may be system memory (e.g., one or more of cache, SRAM, DRAM, zero capacitor RAM, Twin Transistor RAM, eDRAM, EDO RAM, DDR RAM, EEPROM, NRAM, RRAM, SONO S, PRAM, etc.) or any one or more of the above already described possible realizations of machine-readable media. The computing device1200also includes a bus1203and a network interface1205(e.g., a Fiber Channel interface, an Ethernet interface, an internet small computer system interface, SONET interface, wireless interface, etc.).

Any one of the previously described functionalities may be partially (or entirely) implemented in hardware1210or on the processor1204. For example, the functionality may be implemented with an application specific integrated circuit, in logic implemented in the processor1204, in a co-processor on a peripheral or card, etc. Further, realizations may include fewer or additional components not illustrated inFIG. 12(e.g., video cards, audio cards, additional network interfaces, peripheral devices, etc.). The processor1204and the network interface1205are coupled to the bus1203. Although illustrated as being coupled to the bus1203, the memory1208may be coupled to the processor1204.

A machine-readable signal medium may include propagated data signal with machine-readable program code depicted therein, for example, in baseband or as part of a carrier wave.

Such a propagated signal may take any of a variety of forms, including, but not limited to, electromagnetic, optical, or any suitable combination thereof. A machine-readable signal medium may be any machine-readable medium that is not a machine-readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.

Program code depicted on a machine-readable medium may be transmitted using an appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing. Computer program code for carrying out operations for aspects of the disclosure may be written in any combination of one or more programming languages, including an object oriented programming language such as Java® programming language, C++or the like; a dynamic programming language such as Python; a scripting language such as Perl programming language or PowerShell script language; and conventional procedural programming languages, such as the “C” programming language or similar programming languages. The program code may execute in a distributed manner across multiple machines and may execute on one machine while providing results or accepting input on another machine.

Plural instances may be provided for components, operations or structures described herein as a single instance. Particular operations are illustrated in the context of specific illustrative examples. Other allocations of functionality are envisioned and may fall within the scope of the disclosure. Use of the phrase “at least one of” preceding a list with the conjunction “and” should not be construed as a list of categories with one item from each category, unless specifically stated otherwise. A clause that recites “at least one of A, B, and C” can be infringed with only one of the listed items, multiple of the listed items, and one or more of the items in the list and another item not listed.

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