CN113474733A

CN113474733A - Energy virtualization layer with virtual grid connections

Info

Publication number: CN113474733A
Application number: CN201980092132.2A
Authority: CN
Inventors: 杰拉德·欧豪拉
Original assignee: Syncells Inc
Current assignee: Syncells Inc
Priority date: 2018-12-13
Filing date: 2019-12-11
Publication date: 2021-10-01
Also published as: WO2020123603A1; EP3894963A4; EP3894963A1

Abstract

The energy virtualization system may include a physical interface gateway, which may include a plurality of common interfaces. The plurality of common interfaces may be coupled to the plurality of energy generation devices, the plurality of energy control devices, and the plurality of energy consumption devices. The system may further include a building network, wherein the plurality of energy generating devices, the plurality of energy control devices, and the plurality of energy consuming devices may communicate via the building network. The system may additionally include a computing device running an energy virtualization layer. The virtualization layer may include a plurality of virtual devices representing a plurality of energy generation devices, a plurality of energy control devices, and a plurality of energy consumption devices. The virtualization layer may also direct energy from the energy generating device to the energy consuming device based on information received from the energy control device.

Description

Energy virtualization layer with virtual grid connections

Cross Reference to Related Applications

This application claims priority from U.S. patent application No.16/219,906 entitled "ENERGY VIRTUALIZATION WITH a unicalsal SMART GATEWAY" filed on 12/13/2018, which is incorporated herein by reference.

Background

In the approximately 95 quart primary energy source produced in the united states, in excess of 58 quarts, is discarded/wasted due to system inefficiencies, as called by the Lawrence Livermore National Laboratory. The main sources of energy (oil, gas, coal, etc.) are usually not consumed directly by the end user. Rather, they are used to generate electricity or power internal combustion engines. Electric energy is an energy source that most people directly contact. It supplies power to mobile devices, televisions, power tools, lighting, and the like. In short, electrical energy can power most end-user applications (from transportation to home/office heating).

Energy and resources are further wasted when they are limited to a single application. The universal battery we know today originated in the 1800 s. Standard AA batteries can be used to power a remote controlled car or flashlight. Although much research has been done recently (mainly to improve energy density), the full potential of batteries is being downgraded to very specific applications such as consumer products, Electric Vehicles (EVs) or grid storage, based on very strict expectations. In addition, due to the inefficient use of resources, similar to the oil industry, new monopolies and united enterprises are being formed for rare earth materials, thereby compromising our energy safety.

Disclosure of Invention

In some embodiments, an energy virtualization system may include a physical interface gateway, which may include a plurality of common interfaces. The plurality of common interfaces may be coupled to the plurality of energy generation devices, the plurality of energy control devices, and the plurality of energy consumption devices. The system may further include a building network, wherein the plurality of energy generating devices, the plurality of energy control devices, and the plurality of energy consuming devices may communicate through the building network. The system may also include a computing device running an energy virtualization layer. The virtualization layer may include a plurality of virtual devices representing the plurality of energy generation devices, the plurality of energy control devices, and the plurality of energy consumption devices. The virtualization layer may also direct energy from the energy generation device to the energy consumption device according to information received from the energy control device.

In some embodiments, a method of operating an energy virtualization system may include receiving a plurality of energy generating devices through a plurality of common interfaces in a physical interface gateway of the energy virtualization system. The method may also include receiving a plurality of energy control devices through a plurality of common interfaces in a physical interface gateway of the energy virtualization system. The method may further include receiving a plurality of energy consuming devices through a plurality of common interfaces in a physical interface gateway of the energy virtualization system. The method may further include communicating between the plurality of energy generation devices, the plurality of energy control devices, and the plurality of energy consumption devices through a building network. The method may further include representing the plurality of energy generating devices, the plurality of energy control devices, and the plurality of energy consuming devices as a plurality of virtual devices running on a virtualization layer on a computing device. The method may further comprise directing energy from the energy generating device to the energy consuming device in accordance with information received by the virtualization layer from the energy control device.

In any embodiment, any of the following features may be included in any combination and are not limiting. The plurality of energy generation devices, the plurality of energy control devices, and the plurality of energy consumption devices may communicate through the building network according to an IP protocol. The energy virtualization system may be installed in a commercial building. The energy virtualization system may be installed in a residential building. The plurality of energy consuming devices may include electric vehicles. The energy virtualization layer may be configured to: the method includes receiving an indication that a new device has been connected to the physical interface gateway, determining whether the new device is authorized, receiving information associated with a profile from the new device, and connecting with the new device according to the profile. The configuration file may include an operating current and an operating voltage for the new device. The operating current and the operating voltage for the new device may be provided by the new device to the energy virtualization system. The operating current and the operating voltage for the new device may be provided to the new device from the energy virtualization system. The plurality of energy consuming devices may include a Heating Ventilation and Air Conditioning (HVAC) system.

Drawings

A further understanding of the nature and advantages of the present invention may be realized by reference to the remaining portions of the specification and the drawings wherein like reference numerals are used throughout the several drawings to refer to similar components. In some instances, a sub-label is associated with a reference numeral to denote one of multiple similar components. Where reference is made to a reference numeral without specification to an existing sub-label, it is intended to refer to all such multiple similar components.

Fig. 1 shows an energy system in a commercial building.

FIG. 2 illustrates an architecture diagram of a smart building virtualization management system, according to some embodiments.

FIG. 3 illustrates a system for authenticating a device according to some embodiments.

Figure 4A illustrates a common interface and adapter for a physical interface gateway, according to some embodiments.

Fig. 4B illustrates devices equipped with a common physical interface, according to some embodiments.

Fig. 5 illustrates a plurality of energy generation devices coupled to a physical interface gateway, in accordance with some embodiments.

Fig. 6 illustrates a plurality of energy consuming devices coupled to a physical interface gateway, in accordance with some embodiments.

FIG. 7 illustrates a plurality of energy source control devices according to some embodiments.

Fig. 8 illustrates a block diagram of a system for storing and managing energy through a smart grid platform, according to some embodiments.

Fig. 9 illustrates a simplified diagram of circuitry that may appear on a smart building virtualization platform for aggregating and providing various forms of energy throughout a system, according to some embodiments.

Fig. 10 illustrates a flow diagram of a method for managing energy usage in a building using a smart grid platform.

Fig. 11 shows a diagram of a virtualized energy infrastructure using intelligent gateways to link together numerous sites, users, virtualized service providers, resources, etc. in a unified system (unified system).

FIG. 12 illustrates how a virtualization layer may be integrated with an existing building management system, according to some embodiments.

Fig. 13 illustrates virtual grid connections according to some embodiments. Virtual grid connections refer to connections that match, correlate, or coordinate energy usage with energy production on a smart grid infrastructure.

FIG. 14 illustrates a simplified computer system according to some embodiments.

Detailed Description

The embodiments described herein provide a system that provides and delivers accessible, flexible, consistent, efficient, economically simpler, and financially viable electrical energy and management (whether stored or delivered directly via a wired or wireless connection) in the form of a super-converged intelligent service platform. From a physical point of view, the system may consist of modular, interchangeable and standardized components called Smart Energy Modules (SEM). These components may include energy storage devices, fuel cells, computing devices, and/or any combination thereof. These SEMs may be used in a variety of platforms and applications, including home and office environments, electric vehicles, electric tools, and the like. The SEM can be managed under a single interface and management system, making the details simple and easy to manage, and modular and easy to upgrade. From a logical perspective, embodiments described herein provide a "Virtualization Layer (VL)" that allows energy consumption, control, and sourcing to be virtualized dynamically, and with inherent security capabilities.

Some embodiments described herein may consist of a physical layer and a virtualization middleware layer (i.e., VL). In the physical layer, energy modules can be designed to simplify and standardize the physical implementation of the energy system, thereby making them easy to install, maintain, use, and exchange across platforms and applications. The VL can interface with a physical layer to aggregate energy resources, determine energy demand and consumption requirements, receive and manage energy control inputs and schedules, and interface with energy consuming devices to provide energy from the energy resources.

Fig. 1 illustrates an energy system in a commercial building, according to some embodiments. A Building Management System (BMS) 102 or Building Automation System (BAS) is a computer-based control System installed in a Building that controls and monitors the mechanical and electrical equipment of the Building, such as ventilation systems, lighting systems, electrical systems, fire protection systems, security systems, and the like. BMS 102 may be comprised of hardware and/or software to interact with information bus 104, such as an ethernet, Building Area Network (BAN), and the like. Prior to the present invention, BMS 102, Building Automation Systems (BAS), and/or Energy Management Systems (EMS) all followed the same basic operating principle, and specifically these systems received user actions (such as requesting more heat through a thermostat) and then facilitated corresponding changes by turning on an air handler or other mechanical System to raise the temperature of the building area in which the thermostat is located. Typically, this is done by BMS 102 as a central console. Prior to the present invention, BMS were hard coded with static devices that could not keep up with the emerging Internet of Things (IoT) paradigm. Energy virtualization abstracts physics from logic, allowing dynamic resource integration, monitoring, and management.

Through the information bus 104, the BMS 102 can communicate with various components of the building system through a plurality of

different gateways

108, 110, 112. These

gateways

108, 110, 112 may use a variety of different serial communication protocols (such as the Lon Talk protocol optimized for control, the Modbus protocol, the BACnet communication protocol specifically for building automation and control networks, etc.). These gateways may receive information from BMS 102 and transmit information to components such as thermostat 116, lighting system 118, HVAC system 120, and the like. In addition to the

gateways

108, 110, 112, the bus controller 114 may also receive commands from the BMS 102 to control components such as a boiler 122. In addition, the system may include various sensors, such as carbon monoxide (CO) sensors 106, that provide information to the BMS 102 through the gateway 112.

In the system of fig. 1, BMS 102 retains full control and remains the central gateway for the various resources in the building system. This is an architecture that is understandable based on the time period the system was originally designed. However, the central gateway has become a fundamental drawback to the way the system operates. Prior to the present invention, the system of fig. 1 was still based on a traditional hub-and-spoke model dating back to the 1950 s. Such models require centralized control and therefore have a single point of failure. The system is also very inflexible, making changes or updates difficult, as the individual devices must be connected back to the central controller 102. To change this, time and money are required to rewire the system. From the building owner's perspective, this creates a monopolized environment in which each future tenant is forced to use only the BMS 102 after installation of the BMS 102, making it extremely unlikely that any single tenant will be motivated to replace the BMS 102 or upgrade any attached system. In addition, it is known that, in the prior art,the safety of the existing BMS system is poor. Existing BMS systems typically do not have built-in security and depend on the security provided through a network or other interface. This security deficiency is due to the design engineer being a building management expert rather than a security expert and the contractor installing the system not being a certified network security professional or network professional. These networks are exposed too often or not sufficiently protected to generate back door programs and have an opportunity to access the systems therein. These restrictions are retail stores

The root cause of the hacking in 2013, which resulted in the theft of over 7000 million people.

Although fig. 1 specifically illustrates a BMS system for commercial facilities, many of the same problems exist for modern smart home automation providers for residential facilities. The only way to provide modularity is to subscribe to market leaders (such as

Or

) This forces consumers to purchase only the products they are part of the brand ecosystem. Partners with brand ecosystems must be "certified," which limits innovation and advancement outside of predetermined specifications.

The embodiments described herein revolutionize the conventional BMS system depicted in fig. 1 by the concept described herein as "energy virtualization". The energy virtualization platform is an improvement over the current technology in that it: (1) an energy platform built on an open standard is created; (2) using a highly scalable, secure, flexible and reliable operating system that uses virtualization technology for cross-platform support; (3) applying virtualization concepts to energy consumption in residential, commercial, automotive, retail spaces, and the like; and (4) lower energy costs for the consumer, lower cost of ownership for energy consuming devices, and lower development costs for new residential/commercial infrastructure.

The overall architecture of the system described herein may be referred to as a "virtualized grid. Virtualized power networks for commercial, residential, and/or industrial facilities may include a hardware/software layer referred to as an energy virtualization layer that provides plug-and-play interfaces for energy providing devices, energy consuming devices, and/or energy control devices. The smart grid provides a stable, localized platform in which new devices can be dynamically and seamlessly installed, upgraded, and removed through an energy virtualization layer.

FIG. 2 illustrates an architecture diagram of a virtualized electrical grid in accordance with some embodiments. The software engine running the virtualized grid is the virtualization layer 202, and the virtualization layer 202 abstracts the traditional physical resources from the control system and user interfaces. The virtualization layer 202 functions as a virtualization middleware layer similar to a hypervisor (hypervisor) to manage virtualized resources. Unlike the conventional BMS 102 shown in fig. 1, the virtualization layer 202 can run on a small computing device and can perform many functions. The virtualization layer 202 may also manage multiple control systems and may support multiple different outputs, inputs, and requests in parallel. As an "open" system, the virtualization layer 202 can receive input from any certified device that is allowed to connect with the virtualization layer 202, as long as the certified device conforms to the virtualized grid framework. The virtualization layer 202 serves as a hypervisor layer, and the dynamic pool of resources traditionally managed by a hypervisor represents energy devices that can be dynamically added/removed from the system. Similar to traditional hardware virtualization, various user interfaces or power control devices may be run on the virtualization layer instead of running various operating systems on the hypervisor. Similarly, a manufacturer may run maintenance or optimization routines on the virtualization layer.

The virtualized electrical network may also include a plurality of devices. These devices may include various sensors (such as the thermostat 116 and the carbon monoxide sensor 106). The thermostat 116 may also be categorized as a control device because the thermostat receives input from a user and generates automation commands based on the difference between a set point temperature and the ambient temperature detected in the enclosure. Typically, the sensor devices provide inputs that characterize the environment (including electrical environments, temperature/humidity/pressure environments), occupancy status, safety system sensors, and the like. The control devices typically provide inputs to the virtualization layer 202 that can be used to manage how the virtualization layer 202 distributes energy to the rest of the virtualized electrical grid.

Another class of devices may include energy consuming devices (such as lighting systems 118, HVAC systems 120, and boilers 122). The energy consuming devices are characterized in that the energy consuming devices receive commands from the virtualization layer 202 and consume energy provided by the virtualization layer 202. Although not explicitly shown in fig. 2, another type of device may include an energy supply device. The energy supply device (or "energy generating device") may comprise a solar panel, a wind turbine, a fuel cell, a battery unit, a connection to a local energy grid, etc. As will be described in more detail below, each of these devices (e.g., energy control devices, energy consumption devices, energy generation devices, etc.) may be coupled to the virtualization layer 202 through a physical interface gateway 204. The boiler 122 may be connected to an IP controller 210.

As will be described in more detail below, the virtualization layer 202 may treat each device as a logical resource. Each logical resource may be associated with a configuration file that includes resource information, such as serial number, product code, licensing information, physical attributes of the actual device, operating parameters, control parameters, and the like. When connecting to the virtualization layer 202, an authentication process may be provided to connect to the virtualization layer 202. In addition, the virtualization layer 202 may periodically poll the various devices to determine the status of the various devices and ensure that the various devices are consistent with the current operating mode. This ensures that no unauthorized devices are intercepted or piggybacked onto the physical connection.

Similar to today's mechanical and electrical environments, each device may include an actuator that takes an electrical input and converts the electrical input into a specific mechanical action (such as opening or opening a damper, igniting a water heater, opening a fan, etc.). Prior to the present invention, this "actuator" was activated at the BMS-specific controller component, where the control wiring from the BMS was connected to the equipment. For example, the BMS will include a dedicated wiring connection to the HVAC system 120 or to the lighting system 118. In the virtualized power network scenario of fig. 2, this proprietary connection may be replaced by a small array of IP interface modules that connect via the Building Area Network (BAN)104 to communicate actions or receive status requests from the virtualization layer 202. Initially, these IP interface modules may be provided for various specific device types to logically conform to a unified interface at the virtualization layer 202 and physically at the physical interface gateway 204. Over time, these IP interface modules can naturally be built into the respective devices, for example by using RJ-45 data connectors, to provide a fast and simple plug and play setup. The physical layer gateway may operate in accordance with the OSI model to manage how network-based devices communicate.

In contrast to the traditional hub and spoke configuration of fig. 1, the smart grid of fig. 2 may utilize a modern mesh network design that supports multiple processes, users, devices, etc., in parallel. In particular, any resource in the system may access any other shared resource in parallel, whether an energy consuming system, an energy providing system or a control system. Thus, a failure in one node or element does not disrupt the entire system. For example, operating the HVAC system 122 to reach a desired temperature in a particular office space does not depend on a single core system providing access and/or control to third parties to effect the temperature change. The virtualized grid eliminates this concept, reducing system specificity and preventing operational bottlenecks or system failures.

The virtualization layer 202 serves as a virtual interconnect for the various resources in the system. The amount of resources can be very large — in large buildings where each lighting device is individually connected, there may be millions of resources. In one example, the first tenant 220-1 may run its preferred BMS service on the smart grid to provide its building automation. This allows integrating the first tenant 220-1 into its headquarters BMS by associating data or the like for cost information. The second tenant 220-2 can run its BMS system either independently or in parallel with the first tenant 220-1. In addition to tenants, an external network 206 (such as the internet or WAN) may provide access for providers 210 to remotely monitor building systems. For example, a supplier may support a building to run maintenance/upgrade routines and/or monitor security systems. In some embodiments, the supplier 210 may provide supply and maintenance to the building itself. For example, the supplier 210 may monitor the lighting system 118 or the HVAC system 120 and generate operating instructions when a particular light bulb or fan coil needs to be replaced. It should be noted that this level of integration from external suppliers to the individual resources in the system is not possible in existing building management systems. In existing solutions, such as lighting controllers, manufacturers need to deploy physical gateways or other interfaces to support their proprietary connectivity requirements. By virtualizing the grid, a manufacturer may only provide lightweight software services that translate the manufacturer's control standards to virtualized controllers.

In addition to remote providers 210, external network 206 may also provide access rights for remote or mobile users 208 so that remote or mobile users 208 may connect to the building virtual grid through their mobile devices. Local access may also be granted to the local user/engineer workstation 212. This may correspond to management workstations and/or individual control devices at various locations throughout the building. For example, a touch screen panel may be provided in each office to provide local control of HVAC temperature, ventilation airflow, lighting, security systems, and the like. A firewall device 214 may also be provided to grant access to less secure devices that may be connected to the system through the BAN 104.

In some embodiments, the advantages inherent within the virtualization layer 202 may be particularly apparent when new resources or physical assets appear to the system. For example, some embodiments may include users with electric vehicles who want to exchange batteries or fuel cells from the vehicle with an energy system in their office building. Previously, it was necessary to know the operating characteristics of the battery or fuel cell when designing the system in order to handle this transfer between the electric vehicle and the building. In these embodiments, the virtualization layer 202 may detect a new fuel cell or battery module inserted into the outlet, query/authenticate the battery module to receive profile information, determine operational characteristics of the battery module or fuel cell from the profile information, and integrate the operation of the battery module or fuel cell into the smart grid. Depending on the energy level of the battery modules or fuel cells, the virtualization layer 202 may classify these battery modules or fuel cells as energy consuming devices or energy providing devices. As an energy consuming device, the smart grid may charge or refuel a battery module or a fuel cell, and as an energy providing device, the virtualization layer 202 may enable the outlet to draw energy from the battery module or the fuel cell for use by other resources throughout the building. The ability to evaluate, authenticate, integrate, report, etc., devices that are dynamically added to or removed from the smart grid ecosystem can be achieved without a priori knowledge of how the devices operate. Essentially, the interfaces are both logically and physically standardized between the various resources in the ecosystem and the virtualization layer 202 and the physical interface gateway 204.

The virtualized power grid abstracts the physical representation of the devices on the system from the logical representation. This allows dynamic resource integration, monitoring and management. The virtualization layer may run virtual devices representing energy devices instead of running virtual machines. In addition, the virtualization layer may run user interfaces or containers to support vendor services or to support utility integration. Another difference between traditional hardware virtualization in the IT world and the energy virtualization layer of the power grid described herein is distribution. Traditional virtualization is performed on a single physical system. Instead, the virtualization layer may be distributed across many different devices, as the system uses an IP network to interconnect these remote devices.

FIG. 3 illustrates a system for authenticating a device according to some embodiments. As used herein, the term "authentication" refers to the process of: the method includes receiving an indication that a new device is connected to the smart grid system, sending an inquiry to the new device, receiving information indicating whether the new device is compatible with the virtualized grid system, and receiving a module configuration file that informs the smart grid system how to interact with the new device. In this example, one of the power consuming devices/power generating devices may include a virtual grid chassis 308 and the new device may include a modular battery 310 that is plugged into the smart grid chassis 308. The virtual grid platform 304 may include the network, virtualization layer, and physical interface gateways described above. When the system detects a new device, the virtual grid platform 304 may automatically query, authenticate, and begin operating the new device. In some implementations, the remote user 208 and/or the cloud-based virtual grid hosting service 302 can also initiate the authentication process. In some implementations, virtual grid hosting service 302 may communicate directly with virtual grid platform 304, while in other implementations such communication may be facilitated through external network 306.

Once a new device is detected, it may be determined whether the device is authorized to operate with virtual power grid platform 304 (312). This determination may be made by examining one or more operating characteristics in the module configuration file described below to determine whether the operating characteristics are compatible with virtual power grid platform 304. In some implementations, this determination can be made by reading a serial number or other identifier of the new device and comparing the serial number to a list of compatible devices stored locally on the smart grid platform 304 or remotely at the virtualized grid hosting service 302. Some embodiments may use a cryptographic authentication process whereby a cryptographic key is used to authenticate (in a cryptographic sense) the identity of a new device by providing an authentication digital signature. For example, a public/private key pair may be used on both the virtual grid platform 304 and the new device to authenticate the identity of the new device. If the device is not authorized, virtual grid platform 304 may disable the physical connection between the new device and virtual grid enclosure 308 (320).

If the device is authorized, virtual power grid platform 304 may then determine whether a user account associated with virtual power grid platform 304 may allow the new device to integrate with virtual power grid platform 304. In some implementations, it may be determined whether the user account is reputable in virtual power grid hosting system 302. Some embodiments may use subscription-based services, where the virtual grid platform 304 is provided as an energy as a service (EaaS) platform. Under the EaaS user account, hardware/software for the virtual grid platform 304 may be installed on the building, but ownership of the hardware/software may be owned by the smart grid company. Instead of purchasing the device/software, the user may subscribe to a service that allows the user to reactivate their account on a regular basis, such as every month. The determination as to whether the account allows the addition of a new device may include ensuring that the user account is currently active and reputable. In other embodiments, the smart grid hardware/software may be purchased by a building owner/manager. In this case, the user may establish permissions and controls that determine whether a particular brand of device or type of device is allowed on the network. Thus, even if a device may be authorized, the user account itself may prohibit activation of such devices on the smart grid platform 304. If the user account is not determined to allow connection to the device, then the connection may not be allowed (320) as described above.

If the account is approved for a new device, virtual power grid platform 304 may determine whether the function performed by the device is approved (316). As described below, each device may perform a particular function, such as an HVAC function, a temperature control function, a lighting function, a door lock function, and the like. Some device functions may not be compatible with the building structure and therefore not allowed. For example, a security system controller may be incompatible with a building that does not contain security system sensors. If the functionality is not allowed, the connection with the new device may be interrupted (320), as described above.

In some implementations, virtual power grid platform 304 may request a set of operating parameters and/or characteristics from the new device (318). The operating parameters/characteristics may be stored in module profile 306, and as part of the authentication process, module profile 306 is transmitted from the new device to virtual power grid platform 304. Alternatively or additionally, the new device may send some identification information to virtual power grid platform 304, and virtual power grid platform 304 may look up module configuration file 306 in a local database or online through virtual power grid hosting service 302 to look up module configuration file 306. If parameters are provided and are compatible with the virtual grid platform 304, the device may connect to the virtual grid platform 304 (322).

The operating parameters/characteristics in module configuration file 306 may include a wide variety of information. In the example of fig. 3, module profile 306 includes a device class that classifies the new device as an energy storage device (as opposed to an energy consuming device or an energy controlling device). The module configuration file 306 may also include a serial number and/or other identifying information (such as a manufacturer, product model number, serial number, etc.). The module configuration file 306 may also include digital rights information, such as software licenses or encryption keys that allow the required software to interact with new devices to be downloaded and/or used through the virtual power grid platform 304. In the case of an energy consuming/generating device, the module profile 306 may include electrical operating parameters such as voltage provided/required, current provided/required, battery chemistry, fuel cell type, maximum number of charge cycles, charge cycle history, storage capacity, charge level, maximum number of charge cycles, waveform time characteristics, minimum/maximum error range, operating temperature range, cooling requirements, flowable waste/electrolyte requirements, and the like. The virtual grid platform 304 may need this information in order to properly extract energy from and/or provide energy to the new device. Note that some devices (such as battery 310 in fig. 3) may be categorized as both energy storage devices and/or energy consuming devices. When the battery 310 has sufficient charge, the battery 310 may be used as an energy providing device to provide energy to the virtual power grid platform 304 for use by other energy consuming devices. Alternatively, when the battery 310 does not have sufficient charge (e.g., is below a threshold amount), the battery 310 may be used as an energy consuming device and may be charged by energy received from the virtual power grid platform 304.

In some embodiments, module configuration file 306 provides virtual grid platform 304 with all the information needed to interact with new devices in a plug-and-play manner. This allows new devices to be developed without the need to upgrade the software to the virtualization layer of the virtual grid platform. Instead, the virtualization layer treats each new device as a virtual resource (which is part of a dynamic pool of resources) and relies on the virtual resource to provide the information needed to integrate the virtual resource into the rest of the virtual grid ecosystem. The module configuration file 306 in fig. 3 is specific to the energy storage/provision device. In the case where the new device is an energy consuming device, module profile 306 may include AC/DC current, voltage, and/or waveform requirements to power the device, as well as communication protocols and/or recognized commands that may be provided to/from the new device. The energy control device may have a module profile that includes similar information for powering the energy control device, as well as commands and/or communication protocols that may be transmitted to/from the energy control device.

Figure 4A illustrates a common interface and adapter for a physical interface gateway, according to some embodiments. The module profiles described with respect to FIG. 3 allow the virtualization layer to interact with any device by treating the device as a virtualized resource. The physical interface gateway 204 of the virtual grid platform provides a standardized physical interface for any energy consuming/generating/controlling device that may be physically attached to the virtual grid system. The embodiment of FIG. 4A includes an adapter 412 that may be interposed between the physical interface gateway 204 and the device 410. The physical interface gateway 204 may include a common physical interface 404 that may accommodate virtually any energy consuming/generating/controlling device. The common physical interface 404 may include an AC power connection, a DC power connection, a communication bus interface, and/or one or more digital input/output (I/O) signals. An example of this interface will be described in more detail below with respect to fig. 10. The AC/DC power connection may provide power to the device 410 or draw power from the device 410. Alternatively, Power over Ethernet (PoE) may be used to provide the communications to/from the controller electronics and the Power required to operate these controller electronics. The communication bus interface may send/receive commands to/from the device 410, including state information profile information and function actuation commands. The one or more digital I/O signals may include a reset signal, an enable signal, and other status commands/signals.

When connected with device 410, many devices may not be initially compatible with the virtual grid platform's common physical interface 404. For example, the device 410 may include a proprietary interface 408, the proprietary interface 408 including its own energy input/output, control signals, communication interfaces, and the like. The proprietary interface 408 may or may not be compatible with the common physical interface 404. Thus, the hardware adapter 412 may be physically coupled between the device 410 and the physical interface gateway 204 and function as both a physical adapter and a logical adapter. The adapter 412 may include a first interface 406 that is compatible with the proprietary interface 408 of the device 410. Thus, each particular device 410 that is not inherently compatible with the common physical interface 404 may use its own unique adapter with the first interface 406 that is compatible with that device 410. The adapter 412 may additionally include circuitry to convert signals received from the device 410 into signals compatible with the common physical interface 404. The circuitry may include bus interface/conversion Integrated Circuits (ICs), voltage level shifting circuits, modulation and/or delay circuits, and the like. The first interface 404 may also include a physical connector that mates with a physical interface of the device 410.

Although the adapters 412 of the various devices 410 may include a unique first interface 406, the second interface 402 may be uniform among the various adapters 412. The second interface 402 may comprise an interface that is both physically and logically compatible with the common physical interface 404 of the physical interface gateway 204. Thus, by interposing the adapter 412 between the device 410 and the physical interface gateway 404, the device 410 will appear transparent to the physical interface gateway 204 as if the device had an interface that is inherently compatible with the common physical interface 404. Similarly, the device 410 appears as if the device is connecting with a compatible device using the first interface 406 rather than using the physical interface gateway 204. This allows existing legacy devices to seamlessly integrate to the virtual grid platform and can interface with the virtualization layer without the need to upgrade software/hardware to the device or platform.

Fig. 4B illustrates a device 410 equipped with a common physical interface 402 according to some embodiments. As the common physical interface 404 of the virtual grid system becomes standardized and more widely used, more devices may become inherently equipped with the common physical interface 402 rather than one of many proprietary interfaces. In this case, the adapter may be removed from the connection between the physical interface gateway 204 and the device 410.

Fig. 5 illustrates a plurality of energy generation devices coupled to a physical interface gateway 204, according to some embodiments. Each of the plurality of energy generation devices may be coupled to a unique instance of the common physical interface 404. The particular energy generation apparatus shown in fig. 5 is merely an example and is not intended to be limiting. In some implementations, a power grid 510 that provides commercial power to a building may be coupled to the physical interface gateway 204. The power grid 510 may be connected by a conventional electrical box that is then modified to include a connection to the virtualization layer described above.

In addition to power grid 510, some embodiments may also include local energy generation and/or storage. For example, a residential or commercial building may include solar panels 508 that are dedicated to generating electricity for a particular building. The solar panel 508 may provide power to the physical interface gateway 204. Similarly, some facilities may include other energy producing devices (such as wind turbines 506, hydro generators, etc.). In these cases, excess energy may be provided by these local energy generation devices, such that power grid 510 may also be classified as an energy consuming device. In other words, the power generated and/or stored by the local energy generation device may be used to provide power to the power grid 510. Because the customer may be eligible for discounts, incentives, or payments from the electric utility provider, the virtualization layer may track the amount of energy provided to the electric power grid 510.

Some embodiments may include a chassis that allows for insertion of the battery modules 502 and/or fuel cells 504. Like power grid 510, battery module 502 and/or fuel cell 504 may be categorized as both energy producing devices and energy consuming devices depending on whether physical interface gateway 204 provides power and/or fuel to charge battery module 502 and/or fuel cell 504, or whether physical interface gateway 204 receives power from battery module 502 and/or fuel cell 504.

Fig. 6 illustrates a plurality of energy consuming devices coupled to a physical interface gateway 204, according to some embodiments. As described above for the energy generating device of fig. 5, the energy consuming devices may each be coupled to a unique instance of the common physical interface 404. The energy consuming devices may include HVAC systems 120, lighting systems 118, boiler systems 122, water heaters, any number of smart appliances, and the like. Some devices that can be classified as control devices can also be classified as energy consuming devices (such as environmental sensors, security systems, thermostats, etc.).

As described above with respect to fig. 2, the physical interfaces of the various devices may include IP modules that allow direct communication between devices and between devices in a virtualization layer on a BAN in a smart grid platform. The IP controller may be associated with an IP address that allows the device to address other devices using their IP addresses. One such example in FIG. 6 is a boiler plant 122, which boiler plant 122 may communicate via an IP controller 210.

FIG. 7 illustrates a plurality of energy source control devices according to some embodiments. Note that many of the energy control devices shown in fig. 7 may also be suitable as the energy consuming devices. These energy control devices may include a thermostat 116, a safety system 702, a carbon monoxide sensor 106, a hazard detector, a smoke detector, and the like. Further, the control device may include one or more mobile computing devices 704. The mobile computing device 704 may communicate wirelessly with the virtual power grid platform. To facilitate wireless communication, a wireless adapter 706 may be connected to one of the common physical interfaces 404. Alternatively, some embodiments of the physical interface gateway 204 may include a dedicated wireless communication port that is compatible with a general wireless communication standard, such as IEEE 802.11, bluetooth, ZigBee (ZigBee), Thread (Thread), etc.

Fig. 8 illustrates a block diagram of a system for storing and managing energy through a virtual power grid platform 850, according to some embodiments. Virtual grid platform 850 may include connections to multiple devices through physical interface gateway 204. Each of these devices may provide energy to virtual grid platform 850. The virtual grid platform 850 may also include a central energy storage device 806, which central energy storage device 806 may be comprised of ultracapacitors, battery chemistries, battery cells, fuel cells, and the like. The energy received through the physical interface gateway 204 may be managed by the virtualization layer and stored in the central energy device 806. Similarly, when the energy consuming device requires energy from the virtual grid platform 850, the virtualization layer may cause the central energy storage device 806 to provide energy to the requested energy consuming device through the physical interface gateway 204.

As an example, the virtual power grid chassis 308 including one or more battery modules 310 may provide power to the central energy storage device 806. Similarly, other energy generation devices (such as solar panels, wind turbines, hydro generators, geothermal generators, etc.) may also provide energy to be stored in the central energy storage device 806 through the physical interface gateway 204. The power grid 510 may also store and/or receive energy from the central energy storage device based on whether the energy virtualization layer determines: the building no longer requires sufficient surplus energy and may instead provide the surplus energy to the power grid 510. The central energy storage device 806 provides a method of aggregating energy from various sources and distributing the energy to various energy consuming devices in a real-time system.

In fig. 8, energy received from the power grid 510 may be routed through a virtual grid platform 850 before being delivered to various energy consuming devices 804 and/or various energy control devices 802. In some embodiments, the power grid 510 may also be directly connected to the energy consuming devices 804 and/or the energy control devices 802, and the energy consumption of such devices may be managed by a virtualization layer of the virtual grid platform 850. For example, an energy consuming device, such as a television, may be connected to a conventional 110 volt (V) outlet in a user's home. The television may be powered directly from the power grid 510, but the energy usage of the television may be monitored by the virtualization layer through the physical interface gateway 204. This allows the virtualization layer to establish a home energy budget and regulate energy usage by various energy consuming devices 804, even when the virtualization layer is not directly powering such devices.

Fig. 9 illustrates a simplified diagram of circuitry that may appear on a virtual grid platform for aggregating and providing various forms of energy throughout a system, according to some embodiments. The circuit may include a DC receiver circuit 902, the DC receiver circuit 902 receiving DC voltage/current from various sources, such as fuel cells, battery modules, solar panels, and the like. The DC receiver circuit 902 may receive these various DC signals and convert them into a single DC signal to charge the central energy storage device 806. Similarly, the circuit may include an AC rectifier circuit 906, and the AC rectifier circuit 906 may receive and rectify an AC signal from a source such as an electrical power grid. The DC rectifier circuit 906 may combine these regulated DC circuits and provide them to the central energy storage device 806 for storage. Some embodiments may direct the rectified DC signal from the AC rectifier circuit 906 to the DC receiver circuit simply as another DC input to be aggregated.

Control processor 904 may monitor central energy storage device 806 and control various outputs. The energy virtualization layer may operate on the control processor 904. Although a virtual grid platform may include many AC and DC outputs, only one pair of outputs is shown in fig. 9 for clarity. A virtualization layer operating on the control processor 904 may provide signals to the inverter 910 and the multi-tap transformer 908 to provide various AC and DC signals 916, 918, respectively. The control processor may manage the current, voltage, and/or frequency of the respective output signals based on the energy consuming devices coupled to output 916 and/or output 918. Review how the virtualization layer may receive module profiles for individual energy consuming devices. The profile information may include, for example, the DC voltage and current required by the energy consuming device. When connected to outputs 916 and/or 918, the virtualization layer may, for example, shut down inverter 910 and program multi-tap transformer 908 to provide a specified DC voltage and current. As described above, the physical interfaces may also include a communication bus 914, which communication bus 914 is shared among the various devices in the system and is addressed using an IP protocol, or alternatively, which communication bus 914 is dedicated to a particular device connected to that particular interface.

FIG. 10 illustrates a flow chart of a method for managing energy usage in a building using a smart grid platform. The method may include aggregating/storing energy sources from one or more energy generating devices (1002). The method may also include receiving a command to control energy usage (1004). These commands may be received from the energy control device through the virtualization layer as described above. Further, these commands may be generated by the energy virtualization layer itself according to an energy usage plan, budget, or schedule. The method may also include providing energy to one or more energy consuming devices (1006). The energy source may be provided by a standardized physical interface as described above. The method may also include providing commands to one or more energy consuming devices (1008). The commands may be provided to manage the use of the energy consuming devices in receiving energy from the virtual grid platform.

It should be appreciated that the specific steps illustrated in fig. 10 provide a particular method of managing energy usage using a smart grid platform according to various embodiments. Other sequences of steps may also be performed according to alternative embodiments. For example, alternative embodiments of the present invention may perform the steps outlined above in a different order. Moreover, the various steps shown in fig. 10 may include multiple sub-steps that may be performed according to various sequences as appropriate to the individual step. In addition, additional steps may be added or removed depending on the particular application. Weather inputs may be received from external services and used by the virtual power grid to react to conditions or preempt preemption by, for example, preheating/cooling a building. One of ordinary skill in the art would recognize many variations, modifications, and alternatives.

Technical advantages and technical problems that are solved by the above-described energy virtualization layer and virtual grid platform should be apparent in light of the present invention. Virtualization is a concept familiar in the field of computer systems and computer networks, in particular Information Technology (IT). Virtualization of computer resources allows for cloud services, large-scale operating environments, dynamic user experience, and cost-effectiveness. Also, energy virtualization as described herein logically defines all energy elements, including three complex and simple management platforms of generation, storage, consumer usage, etc., which allows for dynamic allocation of energy resources based on demand, availability, usage time, and various other factors. Energy virtualization overcomes many of the challenges currently faced by intelligent home and intelligent building concepts. Energy virtualization also provides a means for users and utilities to plan, customize, and streamline delivery and access to various energy services.

In particular, energy virtualization provides a macro and micro level infrastructure that provides a flexible, scalable energy system. In its simplest form, energy virtualization deploys energy control device to energy consuming device direct communication, e.g., energy virtualization does not require a thermostat to be connected directly to the HVAC management system. Rather, each device, whether it is an energy control device or an energy consuming device, may be coupled to a virtualization layer or "energy management program" that may dynamically receive commands from the control device and provide commands to the energy consuming device as needed. Furthermore, energy sources (such as SEC, traditional power outlets, solar panels, fuel cells, etc.) are just additional inputs to the virtualization layer that can be paired with other devices as needed. This avoids the use of proprietary gateways and single points of failure. In addition, inherent security measures are provided to properly control who and what has access to various resources, as well as their degree of control and interaction. Comprehensive monitoring and recording of events can also be achieved.

For example, energy virtualization does not require a fixed relationship between different layers (e.g., power, control, and consumption). While the problems caused by the fixed relationship approach may not always be apparent in a residential setting, it is becoming the most important problem in a business setting. A Building Management System (BMS) can form monopolies on systems within a commercial building. This forces tenants to adopt these systems for their use, and tenants are often limited in functionality and lack interoperability with available energy management products that the tenants may wish to use. For commercial reasons, conventional BMS vendors are notoriously slow to include new technology when it is released, and they are often reluctant to integrate their existing systems with the new technology. Even if a commercial building management department wanted to purchase a new BMS, this would require a significant capital expenditure to be compatible with the emerging technology. Energy virtualization addresses these and many other problems by allowing "plug and play" capabilities to run BMS in parallel and dynamically add/delete new systems and components as they become available/unusable.

Energy virtualization also improves energy safety. In particular, the energy virtualization systems described herein may create a more secure environment for landlords, tenants, utilities, systems, and other entities operating therewith in the context of the energy virtualization system. For Demand Side Management (DSM) and other control and system Management technologies, in some cases, it may be important to quickly take sustainable energy and better control it. Currently, interoperability between smart homes or BMS is not possible in consumer, residential and business spaces. BMS systems typically provide simple, general management and automation functions. Energy virtualization will allow energy system manufacturers to run optimization and continuous commissioning processes with BMS/BAS systems to ensure that all systems are operating at maximum efficiency.

The increased level of availability and flexibility provided by energy virtualization ensures that assets can be monitored and controlled at all times, even in exceptional situations. The embodiments described herein simplify how different systems, including HVAC systems, electrical systems, emergency systems, fire alarm systems, smart home systems, etc., can be quickly integrated. Each of these systems is "virtualized," becoming another component that runs only on the energy virtualization platform and connects to other devices and energy sources using a standardized approach. For example, the virtualization platform may simplify how emergency services and other third parties may be granted access during an exceptional event. Evolving code and security standards may be downloaded through software patches or electronic upgrades to individual components without requiring a complete system replacement. In addition to energy security, authentication is also becoming increasingly important for energy facilities and transmission systems. The virtualized energy solution described herein is the simplest and most robust way to adapt energy certification to evaluate the identity and interoperability of the various systems connected to the energy virtualization layer.

Energy virtualization allows almost any component to be connected to a smart home system. Energy virtualization abstracts a myriad of internet of things (IoT) sensors and components, thus allowing them to be used freely without having to lock to a single gateway solution. In addition to being able to freely communicate and interoperate with other devices, the virtualization platform described herein is a centralized source of reliable AC and DC power (e.g., 48V DC) and communication interfaces. Thus, the virtualization layer is also actually a large power over ethernet (PoE) source for sensors, controllers, lighting systems, automation systems, intelligent appliances, and the like. The virtualization layer allows cloud services and IoT devices to manage the system locally or via smart devices. The virtualization layer also allows integration of data from third parties (such as real-time pricing models, utilization feedback, time of use, demand response pricing, etc.).

The energy virtualization model may be coupled with a portable energy system including modular battery and/or fuel cell technology as described in detail above. In other examples, the energy virtualization model may be coupled with distributed energy systems, micro/nano grids, personalized service providing systems, and various other systems found in the energy sector. In such examples, energy virtualization provides a toolkit that allows previously static local energy systems to have greater flexibility and extensibility. As energy virtualization becomes more widely used, it enables standardization and modularity between energy systems, which in turn makes compatible devices and systems easier to design, install, manage, and/or expand, and can do so safely. For example, a virtualized energy system may roll back quickly in the event of a failure, malicious attack, code corruption, and the like. Updates and patches may be distributed and/or installed remotely or locally in a secure manner.

In some embodiments, not only does energy virtualization support the delivery of energy to various systems and/or devices, but energy virtualization may also incorporate other value-added services (such as communication channels and systems, security systems, entertainment systems, content delivery, etc.) as part of the ultra-converged energy system economy. Some embodiments may also include a portal that allows access to individual tenants in the energy system without requiring either party to provide administrator access. Third parties granted access to the monitored data, usage trends, etc. may be selectively allowed access. Energy virtualization also has the ability to dynamically manage various resources to effectively respond to various situations and demand scenarios, such as weather disruptions or demand charges.

Some embodiments may be integrated with a cloud service to store historical usage data and shared data. The cloud components may also be used to remotely manage and/or monitor data and energy usage. Some embodiments may also include access to the private cloud so that private data does not need to leave the owner's site. Connection to a cloud or other network infrastructure may include a standardized method of deploying the infrastructure on servers and general IT hardware (as opposed to proprietary systems).

In some embodiments, the various energy virtualization systems may be interconnected by a power/communications grid. Macroscopically, each virtualized system can be viewed as an extensible resource. As systems evolve, new tenants may move into existing energy virtualization systems, migrate between systems, or expand to other sites. The virtualized power grid management server may manage public energy profiles that may be federated across sites to achieve a consistent common policy. As a service provider (or "virtual utility"), virtualization allows extensive resource aggregation and management to increase capacity, minimize impact on the grid, maximize the potential benefits of the grid and customers. This simplifies the method of integrating real-time pricing mechanisms and spreading across large amounts of resources using standardized and scalable techniques. Further, capability changes, new actions, manufacturer upgrades, government requirements, etc. can all be remotely deployed, monitored, and implemented, if necessary.

Energy virtualization simplifies and enables the process of dynamically installing, allocating, or utilizing resources (e.g., from resource generation to storage or otherwise). For a hyper-converged system, energy virtualization may further enable a transition from one form of energy source to another. For example, in an electric vehicle, the same basic infrastructure may integrate and support energy storage modules and adapt to changes in fuel cell modules to gain the advantages that fuel cell modules can provide. Thus, vehicles and other resources are not locked to a fixed energy source, but may be powered by any standard-based virtual resource.

As described above, resources in a smart grid platform may communicate in parallel with each other. Embodiments include the use of IP-based, serial, 2-wire, and/or other conventional means of connecting sensors (temperature, light, CO, etc.), controllers (HVAC actuators, fans, etc.), and/or energy systems (lighting, furnaces, air handlers, etc.). These may be aggregated into the neutral interface gateway. Each energy component and interface can be digitized, classified, and defined in software logic according to its purpose, such that each energy component and interface becomes an icon (block, unit, or resource) that can be dragged into a minimally re-programmed and configured configuration, just like a traditional virtual resource. The common physical interface abstracts the myriad of devices that may be involved from the software and management layers that need to host various users and third parties on a neutral basis. Each resource may have a configuration file that may be created or configured manually or provided by the manufacturer, which may be automatically identified by the virtualization layer upon connection.

The virtual grid platform may include a conventional server storage platform that may run proprietary software to provide an open interface allowing users to interact with BMS, vendor tools, utilities, sensors and other components. The virtual grid platform allows third party systems and controllers to communicate over standardized protocols, such as IP, to provide common access to resources. Rather than deploying workstations and other systems for the products of various vendors, the functionality of the workstations and other systems is aggregated into a common system of the smart grid platform described above.

Some embodiments may use a local 48V DC power supply that may be deployed as a high current DC common backbone (such as the aggregated DC signal in fig. 10) rather than using a high voltage power supply or riser common in most buildings. This may eliminate a series of transformers involved from utility voltages 13+ kV to 480V, 208V, 110V AV to 12V DC, etc. that would normally waste a significant amount of energy, so that these voltages can be consumed by conventional electronics. In contrast, 48V DC has been commonly used in traditional telecommunications to power equipment, and in the past decade, has been used as a means to power IT systems (telephones and the like), and even LED lighting, over ethernet connections. As part of the riser power solution, and to simplify installation, some embodiments may use superconducting materials (such as REBCO) that allow high amperage power risers to be installed in 2 inch insulated conduits. This may also include a small storage tank and oil filler for maintenance purposes.

Although many of the examples described above focus on energy virtualization layers for a single site (such as a home or building), other embodiments are not so limited. Fig. 11 shows a diagram of a virtualized energy infrastructure 1100 that links multiple sites, users, virtualization service providers, resources, etc. together using intelligent gateways in a unified system. The infrastructure 1100 may operate independently of the particular type of user equipment or energy source used. For example, the infrastructure 1100 need not rely on the modular and/or switchable energy unit devices described above, but may be connected to any energy source, such as a solar cell or commercial power grid.

Communication between the various devices in infrastructure 1100 can be facilitated by a variety of different techniques. In some implementations, the user device 1114 can communicate with other elements in the infrastructure 1100. The user device 1114 may include a smartphone, laptop, tablet, workstation, voice-controlled digital assistant, smart watch, and/or any other personal computing device. The user device 1114 need not be co-located with any other device in the infrastructure 1100, but may use various communication techniques to control the device from any location. For example, communication may be facilitated by any wired or wireless protocol, such as an IP protocol. These communications may be spread over an external Network 1108, such as the internet, or over a Wide-Area Network (WAN), Local-Area Network (LAN), or any other Network protocol.

The user device 1114 may provide a virtualization control solution that may be applied to other energy systems. These other energy systems may include multiple sites 1104, 1106, such as buildings, houses, factories, industrial centers, business centers, office buildings, and the like. These other energy systems may also include electric vehicles as well as other stationary and/or mobile applications. In some embodiments, infrastructure 1100 may also include non-energy systems that may benefit from integrated distributed system control. The virtualization infrastructure described in fig. 11 may allow any device to communicate with any system, as compared to a conventional control system or BMS. The traditional control system and the controlled system are controlled in a ratio of 1: 1. For example, thermostats allow a user to alter the temperature in a single zone associated with an HVAC system. In another example, a smart home application allows a user to turn on/off lights in their home or room. However, as can be clearly seen by the arrangement of fig. 11, individual users can access and control any resource within infrastructure 1100 according to their permissions and security requirements.

The virtualization energy concept using a virtualization layer described above for a single site can be applied in many instances of systems, applications, sites, devices, and/or energy. This may allow the user device 1114 to connect to the user's vehicle, the user's home, the user's workplace, or community/city resources through a heterogeneous control environment. The heterogeneous control environment can be used to implement intelligent buildings, intelligent cities, intelligent infrastructure, and the like. For example, by connecting the user devices 1114 to a city traffic system, the infrastructure 1100 can respond to a planned traffic route or a total number of users/drivers, and then adjust traffic light timing to ensure balanced traffic flow. In the same example, facility 1100 may allow for automatic charging, allow access to parking lots of buildings and provide security, and may prepare HVAC systems for user arrival, set up audio/video conferences, and interact with other systems in the environmental system to provision these systems according to user preferences. Virtualization service provider 1112 may include a cloud database 1110, the cloud database 1110 including user preferences, resources, and accounts that may be used to configure the system in anticipation of user arrival. Because user behavior may be aggregated by virtualization service provider 1112, collective user patterns may be analyzed to predict user preferences even if users who explicitly provide these preferences to virtualization service provider 1112 are not available.

As described above, the virtualization infrastructure 1100 provides a unified interface for both the user device 1114 and the sites 1104, 1106. For example, the virtualization infrastructure 1100 may provide a Smart Building App (Smart Building App) to connect/interface with a user's home, office, vehicle, etc. Smart building applications may also be used in temporary locations (such as conference rooms, hotel rooms, in-flight entertainment systems, etc.). By providing a standardized interface for a single application, this prevents so-called "application proliferation" (app scatter) on a user's handset or device, and does not require the site owner to customize the development control application for use by its own building and tenants. In addition, the standardized interface may provide third parties with a consistent, integrated interface to their own applications, which also provides system optimization and debugging routines. For example, developers can still customize graphical components and user experiences on their own applications as needed. However, the control techniques and communication processes below the user interface layer may remain standardized to interface with the virtualization infrastructure 1100. This can leverage the capabilities of the internet of things (IoT) to provide broader access, faster integration, more secure interaction, and a more commercially viable and scalable solution without the need for custom APIs and DLLs.

The interface provided by the virtualization infrastructure may provide a neutral framework for interoperability. Thus, when energy service providers upgrade or change their systems, the control applications on the user devices 1114 need not continuously react, develop, test, and deploy corresponding upgrades in order to maintain compatibility. For example, the building ID may be established through the administrative portion of the neutral interface. The building ID may correspond to a home, office, leisure place, or any other location, such as site 1104. Similarly, a user ID may also be established for the user, and may be used on any user device (such as user device 1114). In infrastructure 1100, other resources may be defined as vehicles, conference rooms, lighting systems, HVAC systems, conference systems, and the like. When each system (of any type) has its own unique ID on the infrastructure 1100, the control device can be connected to any energy consuming device or energy source. In some embodiments, a predefined level of controller automation may be established to allow limited control over hotel policies and other limited remote access. Each user profile may be associated with user credentials, and infrastructure 1100 may enforce security and authentication that enables portability between all endpoints in the system with a unique ID for each user and/or system. For example, a building manager may allow a user to access resources within their site in response to a request from the user by adding the user ID to a white list or database 1102 of allowed users.

As described above, the virtualization layer or middleware layer may support on-site and cloud-based monitoring and management in different hybrid configurations. This may allow site operators or building owners to ensure that their systems are always available. For example, in the event that the external network 1108 is disrupted or the virtualization service provider 1112 is unavailable, the virtualization layer may continue to support the various sites 1104, 1106. Similarly, a cloud-based service (such as virtualization service provider 1112 or other security company) may be provided with an interface for remote monitoring and management, if desired. In some embodiments, the different sites 1104, 1106 may communicate with each other through the virtualization infrastructure 1100, allowing for cross-site interoperability capabilities. For example, a traditional Building Management System (BMS) can move into the cloud and can interact with edge devices on the network rather than just traditional field control devices.

In some implementations, the user device 1114 can include a graphical interface or other form of user input device. However, some user devices may also include third party systems (such as Amazon)

Or Google

) The third party system may be integrated as a plug-in to the infrastructure 1100. Home systems (such as at site 1106) may communicate directly with associated providers using such home assistants via external network 1108. The interface may support a list of trigger words and resources available to the user at a particular site 1106 that facilitate voice control. While existing digital assistants (e.g.,

) Speech recognition is possible, but they typically do not discriminate between different users and their different associated accounts. Existing digital assistants also lack the ability to robustly and securely manage and authenticate multiple users. Thus, existing digital assistants cannot meet the commercial or large-scale requirements of the standardized interface provided by virtualization infrastructure 1100. Rather, the virtualization infrastructure 1100 allows users to use these digital assistants because commands are processed and relayed through the secure framework of the virtualization infrastructure 1100 rather than through the proprietary systems of the individual devices.

As an example of how the virtualization infrastructure may be used in different settings, a user may find himself in a public or semi-public area (such as a hotel, gym, bar, or other location). Users can use their cell phones to access a graphical user interface built on a standardized virtualization interface to control various devices in the area. In particular, users may access an interface on their smart phone to change television channels in a restaurant, adjust the temperature of a living room, and so on. The virtualization infrastructure may include generic intelligent gateways that may allow a user to control a device by simply entering or selecting a site or room identifier. Some embodiments may also require the user to provide an authentication or permission element to access a particular device. Thus, a public location (such as a gym or hotel) can save money and provide greater user control without the need to provide separate television remote controls, temperature controls, light controls, and the like. Rather, users can simply use their phones to control all of these systems in conjunction with the common identification of the respective corresponding devices.

In another example, employees often visit different locations or offices while working or working remotely. When an employee visits a different office, the employee may simply enter a site identifier and a corporate credential to be pre-approved and having a list of other resources available to the conference room or location. The user credentials may be verified to allow access and control of the system whenever the user chooses to work in a new location. For example, in a conference room, the location-aware functionality of user device 1114 will automatically present systems within that range that the employee has been allowed to access. In particular, while in a meeting room, a user may adjust lights in the meeting room, control a projector or a presentation screen, in a Microsoft slide show (Microsoft Windows

) Advance slides through the presentation, control local sound systems, contact other users in a video conference or teleconference, and the like. Control of all of these systems can be automatically provided on the employee's smartphone, since the employee's smartphone location system knows where the employee is located, and automatically generates a user interface for interacting with these systems.

Cloud database 1110 may collect metrics from any of sites 1104, 1106, user devices 1114, or other network endpoints. These metrics may be aggregated for different operating areas, grid substations, etc. These loads may be managed collectively to avoid the need for demand response events in the event of a temporary overload of the grid. For example, using a round robin or other load sharing algorithm to centrally analyze energy loads in a particular area based on client parameters stored in cloud database 1110 or another data store may avoid the need for many large HVAC chiller machines to operate simultaneously.

In some implementations, the user device 1114 can employ location-based services through GPS or other wireless location technology. The location of the user device 1114 may be used to identify resources that are available to the user within a predefined range and that are authorized for control by the user. For example, when a user enters site 1104, user device 1114 may automatically determine the systems at site 1104 that may be controlled by user device 1114 and that the user is authorized to use/control. For example, other sensors and capabilities on the smartphone may be utilized to control systems outside the user's domain. For example, a temperature sensor on the smartphone may communicate with the HVAC system in site 1104 to adjust airflow, temperature, fan speed, and/or other factors to best conform to user preferences.

In addition to resource definitions for users, sites, vehicles, etc. on the infrastructure 1100, the virtualization infrastructure 1100 may also support channels for other data transactions such as payment processing, voice or video communications, Class of Service (CoS), and Quality of Service (QoS), etc. In other words, the virtualization infrastructure may provide an integrated way to connect building, home, and office systems with mobile user systems and other public systems (such as payment systems, public transportation, etc.).

FIG. 12 illustrates how a virtualization layer may be integrated with an existing building management system, according to some embodiments. Virtualization layer 1206 may include software that acts like a traditional hypervisor to manage the various connected systems, platforms, and infrastructure that may be controlled by virtualization layer 1206. In a conventional virtual machine, the hypervisor includes software that runs various virtual machines on the host system. In the traditional server space, the hypervisor provides a virtual operating platform for guest operating systems and manages the operation of these guest systems. Thus, multiple instances of various different operating systems may share virtualized hardware resources that would otherwise need to be dedicated to the respective software in a one-to-one environment.

In some embodiments, the virtualization layer may operate in a manner similar to, but not exactly the same as, such conventional operation of the hypervisor. The software within the virtualization layer 1206 may be referred to herein as a "hypervisor" 1208, however, it will be appreciated that the hypervisor 1208, regardless of managing access to traditional computing resources, manages virtual devices through the virtualization layer that represent actual energy consuming devices, energy providing devices, energy controlling devices as described above.

One advantage of the embodiment shown in fig. 12 is the ability of the legacy BMS 1204 to sit above the virtualization layer 1206 with a hypervisor 1208. In the above described embodiment, the other vendor systems 1210, 1212 are managed by the virtualization layer 1206. This embodiment adds BMS 1204 only as another existing vendor system that can be connected using hypervisor 1208. Thus, the hypervisor 1208 may view the BMS 1204 and other vendor systems 1210, 1212 as virtual appliances.

This embodiment may also include a customization control system 1202 that may be loaded into the virtualization layer 1206 to support the swappable infrastructure described above. The exchangeable infrastructure may comprise energy cells (e.g., battery packs, fuel cells, etc.) and other energy generating devices that can be freely exchanged into and out of the energy infrastructure in a plug and play manner. The control system 1202 may include specialized customizations to handle a replaceable infrastructure (e.g., of energy devices)

Exchangeable infrastructure) commands and interfaces.

Some embodiments may also include a programmable or dynamic policy engine 1214 as part of the virtualization layer 1206 or coupled to the virtualization layer 1206. It should be noted that in some embodiments, hypervisor 1208 may implement the integration of policy engine 1214. The integration of the policy engine 1214 allows a wide range of programmable behaviors that can control the vendor systems 1210, 1212 and/or BMS 1214 through the hypervisor 1208. The policy database 1218 may contain a number of policies that are communicated to the policy engine 1214 on an as-needed basis so that the virtualization layer 1206 may implement different configurations and/or behaviors. The policy engine 1214 may execute the policy 1216 and change the behavior of the hypervisor 1208 in such a way that it interacts with the BMS 1204 and/or the vendor systems 1210, 1212.

For example, the security infrastructure described above may be formed using a particular policy 1216. The policies 1216 may be specific security policies that may be loaded into the policy engine 1214 in response to an event (e.g., an alarm triggered in the BMS 1204), based on time of day (e.g., a higher security policy for nighttime hours), based on input to the control system 1202, and/or any other type of input or stimulus that may be provided to the virtualization layer 1206. In a more general sense, the policy engine 1214 may manage how the hypervisor 1208 reacts any system located above the virtualization layer 1206 to certain events detected by sensors in those systems. The security policies may then cause the virtualization layer 1206 to issue commands to the BMS 1204 and/or other vendor systems 1210, 1212 (e.g., security systems) that implement the various security policies. The security policy may include an automatic door lock, a security sensor being activated, an alarm being activated, a security camera being monitored, a camera lens being provided to a remote location, a fire suppression system being activated, and the like.

Because previous systems did not integrate the dynamic policy engine 1214 with the hypervisor 1208 configured to manage the legacy BMS 1204 through the virtualization layer 1206, previous systems did not have the flexibility or dynamic ability to add new systems to the building infrastructure and/or react to commands and stimuli in real-time. For example, a user may log into the virtualization layer 1206 using a handheld device and access a building schedule provided by the provider system 1210. Provider system 1210 may allow a user to schedule a meeting room and upload data for presentation in the meeting room. By monitoring and intercepting the commands, hypervisor 1208 may then issue commands to BMS 1204 to prepare a/V resources, pre-heat or pre-chill conference rooms, adjust lighting and other environmental systems to prepare for conferences, and the like. The hypervisor 1208 can also send commands to another provider system 1212 to order food for the meeting from an external source (e.g., a take-away restaurant), connect to an external video conference of remote participants, post details of the meeting to an email system, and so forth. Each of these behaviors may be dynamically programmed by the policy engine 1214. For example, policy 1216 may include specific instructions for hypervisor 1208 that are responsive to specific commands for scheduling a conference room. Prior to this solution, users needed to schedule meeting rooms in scheduling software in meeting preparation, order food over the internet, request IT to prepare a/V resources, and request building management personnel to prepare the environmental (e.g., heating/cooling) system.

In another example, a system manufacturer may run system-specific, continuously commissioning and monitoring routines with the BMS to facilitate preventative maintenance based on various data inputs from the sensors. For example, an electronic signature from a single piece of electrical equipment within a building may indicate that a particular system (e.g., an HVAC system) is not functioning properly. The hypervisor 1208 can use the policies 1216 to cause the system to shut down or reboot, download additional software updates from a remote server, contact the manufacturer to schedule maintenance access, and the like.

The data received by the hypervisor 1208 may also be used for troubleshooting or tracking power consumption, which informs the billing system of the cost to the tenant's utility. For example, billing policies may be enforced by a policy engine 1214 that monitors energy usage by the various provider systems 1210, 1212 and provides the control system 1202 with a breakdown of energy usage through a hypervisor 1208. The virtualization layer 1206 may remotely interface with a utility billing system to properly divide billing charges between the provider systems 1210, 1212 based on actual consumption measured in real time.

Fig. 13 illustrates virtual grid connections according to some embodiments. Virtual grid connections refer to connections that match, correlate, or coordinate energy usage with energy generation on a smart grid infrastructure. In particular, a user may coordinate the generation of energy at one location and be managed by one set of hardware, while the use of energy at another location is managed by another set of hardware. This allows the user to efficiently match the energy generating device with the energy consuming device on the smart grid. In some cases, the energy generating device may "store" (bank) energy to the smart grid, and the corresponding energy consuming device may use such "stored" energy when needed.

In the example of fig. 13, the virtualization layer in a building may include many different systems, such as vehicle charging stations, battery charging stations, energy module inserts, solar power connections, and the like. Additionally, the consumer's home environment may include a smart grid chassis 308 and/or one or more energy modules 310 that may be used as part of the smart energy home infrastructure to provide power, charge the energy modules 310, and connect to the smart grid.

In one scenario, a user may drive the electric vehicle 302 home at night and charge the battery module 310 used by the electric vehicle 302. Then, when driving to work the next day, the user can plug the battery 310 into a charging station at the office building controlled by the virtualization layer 1206. If there is an energy module 310, energy may be provided to the building through the virtualization layer 1206. When the user returns home with electric vehicle 302 at a later time, they may plug the depleted battery 310 into their smart grid chassis 308 to fully charge. Due to the smart grid connection between the virtualization layer 1206 at the office building and the smart grid chassis 308 in the user's home, the charging and usage of the energy modules 310 can be coordinated. For example, the smart grid may provide energy to the smart grid chassis 308 in an amount equal to the amount of energy used by the virtualization layer 1206 during the day from the energy module 310. This allows the user and/or business to store energy during low cost intervals so that it can be used from the local battery during high energy cost intervals.

In another scenario, users may be dialled to a certain amount of energy usage during the day at their office. If they use a particularly energy-efficient computing device, operate with lights turned off, and/or otherwise conserve energy, these energy amounts may be attributed to the user's personal virtual account, which may be commonly accessed by the office virtualization layer 1206 and the home smart grid enclosure 308 or home virtualization layer. Thus, by saving energy in one location, a user may apply these saved energy in other locations. For example, a user may charge the energy module 310 at home equivalent to the same energy demand as at the office.

In another scenario, a user may remotely monitor and control the smart grid chassis 308 through the virtualization layer 306 of their office building. The virtual grid connection may temporarily connect the smart grid enclosure 308 only as another virtual device to be monitored by the hypervisor 1208. For the user's control device, all these systems may appear to be interconnected as a single energy infrastructure. For example, they may monitor energy usage in their offices through their workstations, through their cars at office charging stations, and through any home appliances that operate in their absence. The monitoring and control HVAC system may display a unified view of the office HVAC system and the home HVAC system such that the home HVAC system appears as one unused zone in a single monitored environment with a dedicated HVAC system.

The policy engine 1214 described above may be used in conjunction with the virtual grid connection in fig. 13. In particular, each user may have their own policy database 1312 that may be used regardless of the user location. Each of the above scenarios for managing energy usage between various locations may be managed by an individual policy determined and submitted by an individual user. For example, a user may not wish to engage in an energy saving program while working. The user may design a policy (e.g., via a series of tables on a Web interface) to opt out of the various programs and limit energy usage between the various locations. On the other hand, the second user may devise a strategy that actively conserves energy usage and coordinates energy savings across locations (e.g., the home environment and office environment described above).

The virtual grid connection also allows the user to very portable energy savings at home. For example, many users have solar panels installed on the roof of their homes. While these energy panels typically charge local batteries and/or provide energy from the home back to the smart grid, this "stored" energy is typically not available outside the user's home. However, using the virtual grid connection implemented in fig. 13, a user may benefit from energy storage and energy generation devices in any location. For example, a user may drive the electric vehicle 1302 to their office building and then charge the battery module 310 of the electric vehicle 302 at the office building. Through the virtual grid connection, the office charging station can use the energy generated by the user's home through their solar panels. Thus, the user can use these saved energy sources at any location.

In addition, the smart grid may enact real-time load balancing and demand response programs that react to the location of the customer when they make their energy account portable. For example, users participating in demand response programs often allow HVAC systems or other energy consuming devices in their homes to enter an energy saving mode during high cost power intervals. However, the virtual grid connection allows the user to also dynamically register other devices in the load balancing and demand response program, regardless of their location. For example, if a user is in their office building, rather than their home, they may allow the demand response program to place their office environment and energy consumption system in an energy saving mode. The savings identified in the office environment may be attributed to the user's home account or may be used to offset the user's increased energy usage in the home environment. This registration may be done automatically through the user's virtual grid account/profile.

The virtual grid connection shown in fig. 13 implements a portable policy for both individual users and individual usage profiles. Machine learning techniques may be used to analyze actual user behavior rather than using device usage as an alternative to evaluating user behavior. Prior to these implementations, user behavior was analyzed by monitoring certain devices, such as HVAC systems, household appliances, and the like. The most detailed information that a utility company can receive is simply the device usage or the overall energy usage in the home. However, because users can now monitor, manage, and control personal usage through these embodiments regardless of their location, this information can be used to generate an overall usage profile for the user. Thus, individuals who live in the same household, work in the same office building, and/or share particular devices may monitor and/or manage their individual usage regardless of the devices they may use or the locations in which they may be located.

In some implementations, the virtual grid connection can be used to convert the saved energy into other monetary representations to pay for goods and services connected by the virtualization layer 1206. For example, the saved energy or energy generated at a home environment (e.g., a solar panel) may generate an energy credit that may be used to pay for energy usage in another environment (e.g., an office environment). Further, these energy credits may be applied to other vendors and/or devices to interact with the virtualization layer. For example, the vending machine may be part of a BMS or other system connected to the virtualization layer 1206. Rather than paying items from the vending machine in cash, the user may apply energy savings credits from their home environment to pay for items from the vending machine. Other goods and/or services that may be purchased or paid for in the shared monetary economy of energy credit may include food services, HVAC usage, online video services, and/or any other goods or services that may be billed or accessed through virtualization layer 1206.

As described above, the various computer systems in the virtual power grid platform (including the computing system running the energy virtualization layer) may include a dedicated server platform. FIG. 14 illustrates a simplified computer system 1400 according to some embodiments. The computer system 1400 shown in fig. 14 may be included in a device such as a portable electronic device, a mobile phone, or other device described herein. FIG. 14 provides a schematic diagram of one embodiment of a computer system 1400, which computer system 1400 may perform some or all of the steps of the methods provided by the various embodiments. It should be noted that fig. 14 is intended to provide only a general illustration of the various components, any or all of which may be suitably utilized. Thus, fig. 14 broadly illustrates how various system elements may be implemented in a relatively separated or relatively more integrated manner.

Computer system 1400 is shown including hardware elements that may be electrically coupled via bus 1405 or may otherwise communicate as appropriate. The hardware elements may include one or more processors 1410, the one or more processors 1410 including, but not limited to: one or more general purpose processors and/or one or more special purpose processors (such as digital signal processing chips, graphics acceleration processors, etc.); one or more input devices 1415, the one or more input devices 1415 may include, but are not limited to, a mouse, a keyboard, a camera, etc.; and one or more output devices 1420, the one or more output devices 1420 can include, but are not limited to, a display device, a printer, and the like.

Computer system 1400 may also include and/or communicate with one or more non-transitory storage devices 1425, which one or more non-transitory storage devices 1425 may include, but are not limited to, local and/or network accessible Memory, and/or may include, but is not limited to, disk drives, arrays of drives, optical storage devices, solid state storage devices (such as Random Access Memory (RAM) and/or Read-Only Memory (ROM)), which may be programmable, flash-updateable, etc. Such storage devices may be configured to implement any suitable data storage, including but not limited to various file systems, database structures, and the like.

The computer system 1400 may also include a communication subsystem 1430, which communication subsystem 1430 may include, but is not limited to, modems, network cards (wireless or wired), infrared communication devices, wireless communication devicesSpare and/or chipset (such as Bluetooth (R))^TM) Devices, 802.11 devices, WiFi devices, WiMax devices, cellular communications facilities, etc.), etc. The communication subsystem 1430 may include one or more input and/or output communication interfaces to allow data to be exchanged with a network (such as the network described below as one example), other computer systems, televisions, and/or any other devices described herein. Depending on the desired functionality and/or other implementation concerns, a portable electronic device or the like may communicate images and/or other information via the communication subsystem 1430. In other implementations, a portable electronic device (e.g., a first electronic device), such as an electronic device that functions as the input device 1415, may be included in the computer system 1400. In some embodiments, the computer system 1400 will also include a working memory 1435, which working memory 1435 may include a RAM or ROM device, as described above.

Computer system 1400 can also include software components, shown as being currently located within working memory 1435, including an operating system 1440, device drivers, executable libraries, and/or other code (such as one or more application programs 1445), which one or more application programs 1445 can include computer programs provided by the various embodiments and/or can be designed to implement the methods and/or configuration systems provided by other embodiments described herein. Merely by way of example, one or more programs described with respect to the methods discussed above (such as those described with respect to fig. 14) may be implemented as code and/or instructions executable by a computer or a processor within a computer; thus, in one aspect, such code and/or instructions may be used to configure and/or adapt a general purpose computer or other device to perform one or more operations in accordance with the described methods.

The set of such instructions and/or code may be stored on a non-transitory computer-readable storage medium, such as the storage device(s) 1425 described above. In some cases, the storage medium may be included within a computer system (such as computer system 1400). In other embodiments, a storage medium (e.g., a removable medium such as an optical disk) may be separate from the computer system and/or provided in an installation package, such that the storage medium can be used to program, configure and/or adapt a general purpose computer having the instructions/code stored thereon. These instructions may take the form of executable code (which may be executed by computer system 1400) and/or may take the form of source code and/or installable code which, when compiled and/or installed on computer system 1400 (e.g., using any of a variety of commonly available compilers, installation programs, compression/decompression utilities, etc.), then takes the form of executable code.

It will be apparent to those skilled in the art that numerous variations may be made in accordance with specific requirements. For example, customized hardware might also be used and/or particular components might be implemented in hardware, software including portable software (such as applets), or both. In addition, connections to other computing devices (such as network input/output devices) may be employed. The computer system itself may be virtualized following the best practices of the IT industry for security and disaster recovery. This ensures that any system failure can be quickly and easily recovered. A container or headless nano-server may be run to take advantage of the main user interface and associated controls facilitated by hosted or centralized services, minimizing exposure by removing redundant functionality or minimizing systems running in the field. Furthermore, these systems may be run in parallel to avoid a single point of failure.

As described above, in an aspect, some embodiments may employ a computer system (such as computer system 1400) to perform methods in accordance with various embodiments of the present technology. According to one set of embodiments, some or all of the procedures of such methods are performed by computer system 1400 in response to processor 1410 executing one or more sequences of one or more instructions, which may be included in operating system 1440 and/or other code (such as application programs 1445 included in working memory 1435). Such instructions may be read into working memory 1435 from another computer-readable medium, such as one or more of storage device(s) 1425. By way of example only, execution of the sequences of instructions contained in the working memory 1435 may cause the processor(s) 1410 to perform one or more procedures of the methods described herein. Additionally or alternatively, some portions of the methods described herein may be performed by dedicated hardware.

In the previous description, for purposes of explanation, numerous specific details were set forth in order to provide a thorough understanding of various embodiments of the invention. It will be apparent, however, to one skilled in the art that embodiments of the invention may be practiced without some of these specific details. In other instances, well-known structures and devices are shown in block diagram form.

The foregoing description provides exemplary embodiments only, and is not intended to limit the scope, applicability, or configuration of the invention. Rather, the foregoing description of the exemplary embodiments will provide those skilled in the art with an enabling description for implementing the exemplary embodiments. It being understood that various changes may be made in the function and arrangement of elements without departing from the spirit and scope of the invention as set forth in the appended claims.

In the previous description, specific details were given to provide a thorough understanding of the embodiments. However, it will be understood by those of ordinary skill in the art that the embodiments may be practiced without these specific details. For example, circuits, systems, networks, processes, and other components may have been shown in block diagram form as a means for not obscuring the embodiments in unnecessary detail. In other instances, well-known circuits, processes, algorithms, structures, and techniques may have been shown without unnecessary detail in order to avoid obscuring the embodiments.

Additionally, it is noted that the various embodiments may have been described as a process which is depicted as a flowchart, a flow diagram, a data flow diagram, a structure diagram, or a block diagram. Although a flowchart may have described the operations as a sequential process, many of the operations can be performed in parallel or concurrently. In addition, the order of the operations may be rearranged. A process may terminate when its operations are completed, but may have additional steps not included in the figures. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. When a procedure corresponds to a function, its termination may correspond to a return of the function to the calling function or the main function.

The term "computer-readable medium" includes, but is not limited to portable or fixed storage devices, optical storage devices, wireless channels and various other mediums capable of storing, containing or carrying instruction(s) and/or data. The code segments or machine executable instructions may represent: a procedure, function, subroutine, program, routine, subroutine, module, software, include, class, or any combination of instructions, data structures, and program statements. A code segment may be coupled to another code segment or a hardware circuit by passing and/or receiving information, data, parameters, or memory contents. Information, parameters, data, and the like may be communicated, forwarded, or transmitted in any suitable manner, including memory sharing, message passing, token passing, network transmission, and the like.

Furthermore, embodiments may be implemented by hardware, software, firmware, middleware, microcode, hardware description languages, or any combination thereof. When implemented in software, firmware, middleware or microcode, the program code or code segments to perform the necessary tasks may be stored in a machine readable medium. The processor(s) may perform the necessary tasks.

In the foregoing specification, various aspects of the present invention have been described with reference to specific embodiments thereof, but those skilled in the art will recognize that the present invention is not limited thereto. Various features and aspects of the present invention described above may be used alone or in combination. Moreover, embodiments may be utilized in any number of environments and applications beyond those described herein without departing from the broader spirit and scope of the specification. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.

Further, for purposes of illustration, the methods are described in a particular order. It should be understood that in alternative embodiments, the methods may be performed in an order different than that described. It will also be appreciated that the above-described methods may be performed by hardware components or may be embodied in sequences of machine-executable instructions, which may be used to cause a machine, such as a general purpose or special purpose processor, or logic circuits programmed with the instructions to perform the methods. These machine-executable instructions may be stored on one or more machine-readable media (such as a CD-ROM or other type of optical disk, floppy disk, ROM, RAM, EPROM, EEPROM, magnetic or optical cards, flash memory, or other type of machine-readable medium suitable for storing electronic instructions). Alternatively, the method may be performed by a combination of hardware and software.

Claims

1. A method of operating a virtual grid connection, the method comprising:

a hypervisor layer operating at a first location, wherein the hypervisor layer is configured to manage a plurality of energy generating devices and a plurality of energy consuming devices located at the first location and a second location;

managing user profiles associated with energy usage across a plurality of locations, wherein the plurality of locations includes the first location of the second location;

detecting an amount of energy usage associated with the user profile from a plurality of energy consuming devices at the first location;

detecting an amount of energy production from a plurality of energy producing devices at the second location and associated with the user profile; and

utilizing the amount of energy generation at the second location to offset the amount of energy usage at the first location such that the user profile is portable across the plurality of locations.

2. The method of claim 1, further comprising: allowing, for the user profile, more energy usage at the first location based on the amount of energy production at the second location.

3. The method of claim 2, wherein the amount of energy generated at the second location is stored to allow for later use of the further energy source at the first location.

4. The method of claim 1, further comprising maintaining a virtual grid connection between the first location and the second location through an energy grid.

5. The method of claim 1, wherein the plurality of energy consuming devices comprises a battery charging station for an electric vehicle.

6. The method of claim 1, wherein the first location comprises an office corresponding to a user within an office building, wherein the office building comprises a Building Management System (BMS), and the hypervisor layer manages a plurality of portable user profiles that can be temporarily associated with energy usage within the office building.

7. The method of claim 6, wherein the first location comprises the user's home.

8. The method of claim 1, wherein the plurality of energy generation devices comprise solar panels.

9. The method of claim 1, wherein the amount of energy generation from the plurality of energy generating devices at the second location is generated by plugging a charged battery module into an outlet to provide power to the second location.

10. The method of claim 9, wherein the amount of energy usage from the plurality of energy consuming devices of the first location is generated by plugging a discharged battery module into an outlet to charge the discharged battery module from power provided by the first location.

11. A virtual power grid system, comprising:

a hypervisor layer at a first location, wherein the hypervisor layer is configured to:

managing a plurality of energy generating devices and a plurality of energy consuming devices located at the first location and the second location;

12. The system of claim 11, wherein the hypervisor layer is further configured to:

comparing the amount of energy usage of the first location to a first allocation of energy associated with the user profile.

13. The system of claim 12, wherein the hypervisor layer is further configured to:

increasing a second allocation of energy associated with the user profile for the second location based on a difference between the amount of energy usage at the first location and the first allocation of energy.

14. The system of claim 11, further comprising a control device configured to display energy usage and energy generation associated with the user profile across the plurality of locations.

15. The system of claim 14, wherein the control device is further configured to show a unified view corresponding to the energy consumption system at each of the plurality of locations.

16. The system of claim 15, wherein the control device is further configured to show the unified view of the HVAC system at the first location and the view of the HVAC system at the second location to appear as a single monitored environment.

17. The system of claim 11, further comprising a policy engine and a plurality of policies associated with the user profile.

18. The system of claim 17, wherein the policy engine is configured to:

when a user is at the first location, managing usage of a plurality of energy generating devices and a plurality of energy consuming devices at the first location using a first policy of the plurality of policies enforced by the policy engine; and

when the user is at the second location, managing usage of a plurality of energy generating devices and a plurality of energy consuming devices at the second location using the first policy of the plurality of policies enforced by the policy engine.

19. The system of claim 17, wherein the policy engine is configured to:

and executing a demand response program at the first position or the second position according to the position of the user.

20. The system of claim 11, wherein the hypervisor layer is further configured to:

generating an energy credit based on an amount of energy production from a plurality of energy producing devices associated with the user profile; and

transferring the energy credit to a third party service provider outside of the virtual power grid system.