Patent Publication Number: US-2023162205-A1

Title: System and Method for kWh Harvesting and Carbon Footprint Management Solutions

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
     This application claims benefit to U.S. Provisional Patent Application No. 63/256,682, filed on Oct. 18, 2021. The subject matter of the earlier filed application is hereby incorporated by reference. 
    
    
     COPYRIGHT NOTICE 
     A portion of the disclosure of this patent document contains material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the patent and trademark office patent file or records, but otherwise reserves all copyright rights whatsoever. 
     FIELD OF INVENTION 
     The present disclosure relates generally to a computerized system and method for kWh harvesting and carbon footprint management and reductions. 
     BACKGROUND OF THE INVENTION 
     It is known that reducing carbon dioxide (CO 2 ) emissions is the only way to slow climate change. To address the climate change problem, it is important to address how buildings contribute to carbon emissions. The buildings sector accounts for about 40% of all U. S. primary energy use and associated greenhouse gas (GHG) emissions. Thus, it is essential to reduce energy consumption in buildings in order to meet energy and environmental regulation requirements and to reduce costs to building owners and tenants. 
     All buildings have a carbon footprint. A building&#39;s carbon footprint is defined as the amount of CO 2  it produces during its operations and activities. There are many contributors to a building&#39;s carbon footprint. Of the contributing factors, most building-related carbon emissions come from day-to-day energy use—known as the “operational carbon emissions.” Globally, building operations account for about 28% of emissions annually. The major areas of energy consumption in buildings are heating, ventilation, and air conditioning; lighting; major equipment and appliances with the remaining in miscellaneous areas including electronics. In each case there are opportunities both for improving the performance of system components and improving the way they are controlled as a part of integrated building systems. 
     Opportunities for improved building efficiency and cost savings are enormous. To reduce carbon emissions from buildings, all levels of government, including federal, state, and local, have begun to implement new carbon emission laws and policies. For example, in 2019 New York City passed the Climate Mobilization Act, which is one of the most aggressive and rigorous carbon footprint reduction laws in the US. Local Law 97. The centerpiece of 2019&#39;s Climate Mobilization Act calls for carbon footprint reductions of 40% by 2030 and 80% by 2040, affecting more than 50,000 buildings in NYC. Local Law 97 in NYC forces companies to be comprehensively proactive in reducing their carbon footprint and subsequent contribution to global warming. Not meeting these strict GHG emission standards will result in penalties of $268 per metric ton of CO 2  over the mandated limits. If left unaddressed, the fines could reach hundreds of thousands of dollars per building each year. Other cities have announced plans to follow suit with similar carbon footprint laws. 
     Building owners and operators are asking the questions: How best to mitigate potential greenhouse gas fines? What are the Energy Conservation Measures (ECMs) one should put in place? and What are the lowest hanging fruits for kWh reduction? All keyed on reducing the facility&#39;s carbon footprint. To successfully implement a reliable and efficient carbon footprint management and reduction program, organizations need to methodically address comprehensive energy usage and the changing electric grid. This undertaking requires a “next level of energy management and efficiency” to mobilize significant reductions in facility energy intensity well beyond historical practice. 
     The five most significant challenges to verifiable ambitious carbon footprint management are:
         1. The amount of energy usage must decrease, in most cases, dramatically.   2. Energy efficiency sources and reductions must be diversified.   3. Reliable Measurement and Verification (M&amp;V) for energy reductions must be immediate with honest visibility.   4. Energy efficiency achievements and savings must be integrated into a carbon reduction framework.   5. Energy reductions and changing usage profiles must be part of the evolving electric distribution grid, integrating renewables, distributed energy resources (DERs), and intelligent load management.       

     Corporate carbon footprint goals along with the more rigorous legislated carbon emissions allowances have a momentous impact on building operations. Building owners need new means and methodologies to accurately monitor compliance including:
         a. Real-time verifiable and unimpeachable carbon footprint computations including contributions by the individual system, user, and location.   b. Certifiable facility carbon footprint projections against corporate goals or legislated allowances.   c. Immediate and transparent actionable compliance accounting and direction.       

     SUMMARY OF THE INVENTION 
     The present invention may satisfy one or more of the above-mentioned desirable aspects. Other features and/or aspects may become apparent from the description which follows. The systems, methods and devices of the disclosure each have innovative aspects, no single one of which is indispensable or solely responsible for the desirable attributes disclosed herein. Without limiting the scope of the claims, some of the advantageous features will now be summarized. 
     Systems, methods, apparatus, and software are described herein for managing and reducing carbon footprint of buildings in a way that eliminates or ameliorates some or all of the problems described above. 
     The system, method, and software are configured to mitigate the carbon footprint caused by building operations. To provide building operations energy use optimization, the present invention uses a powerful kilowatt hour (kWh) harvesting and unique carbon footprint monitoring and management software platform. Specifically, the exemplary embodiments provide kWh harvesting that harvests energy from one or more load assets, which consume electrical power such as HVAC&#39;s, air conditioners, baseboard heaters, building lighting systems, other controllable loads or any combinations thereof. 
     As used herein, the term “kWh harvesting” refers to a systematic and continuous management process based on identification and prevention of excess electrical energy consumption expended in the delivery of load assets, for example, an HVAC load asset, and facility operations loads in the built environment. Energy consumption inefficiencies of such major load assets are reduced and optimized without compromising operations and comfort at any given time. Energy harvesting can be harvested from one or more load assets as described below. 
     The system and methods can use network applications and/or software applications to create customized strategies to measure the carbon footprint used by enterprises and to increase building wide savings. 
     The present invention specifically recognizes the infinitely distinctive facility operational modes dictated by occupancy and activities coupled with seasonal and houdly weather variations. This solution proactively and incrementally adjusts equipment operations and inputs/outputs to perform ongoing capture of those kWh being unnecessarily consumed. This enables the present invention to deliver persistent real-time performance optimization by implementing the “kWh harvesting” technique based on long term operating experience and proven technical capabilities. The present invention advances a proactive approach that emphasizes energy consumption identification and building energy use control and mitigation before carbon emission events that adversely affect climate change can occur. 
     The embodiments of the present invention can comprise hardware and software elements. In some embodiments that are implemented in software, all data points can be collected via automated processes, quality controlled and analyzed using Emacx® Systems, Inc. proprietary software, Aciex® Pulse Software Platform© and Aciex® Software Suite©. In various embodiments, the present invention provides a powerful and unique Carbon Footprint Monitoring and Control Software, Aciex® Pulse Software Platform© running on a Supermicro Fanless IoT Gateway to provide building operations with the right tools. In other embodiments, some or all method steps can be performed using any software and/or hardware commercially available products. 
     By engaging the “kWh harvesting technique” disclosed herein, the present invention can consistently deliver verifiable real-time carbon footprint determinations and persistent building performance optimization leading to resultant savings and carbon footprint reductions. The present invention is applicable to the management and control of a building&#39;s carbon footprint that affects both new construction as well as existing buildings. The system, method, and software can be installed to successfully transition existing conventional buildings to high-performance operations, which are now mandated for sustainable buildings of the future. 
     The present invention has consistently demonstrated having robust capabilities to.
         Quantify and assess building GHG (green-house gas) emissions in real-time in accordance to the legal limits, and energy source contribution as well as a specific contributor so that they are immediately visible.   Accomplish full energy use transparency from the building level down to individual meter levels, across billing cycle, year, and variable compliance periods.   Calculate and forecast building year-end carbon footprint and associated penalties or surpluses across any compliance period.   Identify high-energy-consumption meters/tenants/users for targeted monitoring or management directed reductions.   Facilitate targeted kWh and kW reductions or noncompliance gap closure scenarios.   Enable at-will facility carbon emissions reporting and audit requirements.   Improve tracking and performance reporting, which are very necessary for current corporate environmental social policies and publications.       

     Through the use of high efficiency server technology and innovation, the present invention provides end-to-end green computing solutions to the data center, cloud computing, enterprise IT, and high performance computing (HPC). The present invention enables customization to build and deliver application-optimized solutions based upon an enteprise&#39;s requirements. 
     In the following description, certain aspects and embodiments will become evident. It should be understood that the invention, in its broadest sense, could be practiced without having one or more features of these aspects and embodiments. It should also be understood that these aspects are merely exemplary and explanatory and are not restrictive of the invention. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG.  1    is an exemplary system architecture, consistent with the disclosed embodiments. 
         FIG.  2 A  illustrates an exemplary main panel, consistent with the disclosed embodiments. 
         FIG.  2 B  illustrates an exemplary satellite panel, consistent with the disclosed embodiments. 
         FIG.  3 A  illustrates exemplary components of a main panel, consistent with the disclosed embodiments. 
         FIG.  3 B  illustrates exemplary components of a satellite panel, consistent with the disclosed embodiments. 
         FIG.  4 A  is a flowchart of a parameterization process, consistent with the disclosed embodiments. 
         FIGS.  4 B- 4 D  are screenshots of parameters which may be generated by the parameterization process of  FIG.  4 A , consistent with the disclosed embodiments. 
         FIGS.  5 A- 5 L  are screenshots showing example visualizations of meter data, consistent with the disclosed embodiments. 
         FIGS.  6 A- 6 E  are flowcharts of a process for calculating CO 2  emissions limit vs. CO 2  tonnage emissions, consistent with the disclosed embodiments. 
         FIGS.  7 A- 7 M  are screenshots which may be generated by the calculation process of  FIGS.  6 A- 6 E , consistent with the disclosed embodiments. 
         FIGS.  8 A- 9 F  are screenshots showing exemplary topologies of example campus environments, consistent with the disclosed embodiments. 
         FIG.  10    is a flowchart of a process for mitigation measures and strategies, consistent with the disclosed embodiments. 
         FIGS.  11 A- 11 C  are screenshots depicting the mitigation measures and strategies in  FIG.  10   , consistent with the disclosed embodiments. 
         FIGS.  12 A- 12 F  are flowcharts of a kWh harvesting process, consistent with the disclosed embodiments. 
         FIGS.  12 G- 12 L  are screenshots depicting the kWh harvesting process in  FIGS.  12 A- 12 F , consistent with the disclosed embodiments. 
         FIGS.  13 A- 13 J  are screenshots depicting the process of the loads prioritized and organized in groups, consistent with the disclosed embodiments. 
         FIGS.  14 A- 14 D  are screenshots that provide a visual representation of the daily harvested energy as well as of the CO 2  reduction, consistent with the disclosed embodiments. 
         FIGS.  15 A- 15 D  are screenshots of a savings dashboard that present a summary of the harvested energy and the CO 2  reduction, consistent with the disclosed embodiments. 
         FIGS.  16 A- 16 D  are screenshots that illustrate an aggregate summary view of the kWh harvesting operations displayed on a data interface dashboard, consistent with the disclosed embodiments. 
     
    
    
     The skilled artisan will understand that the drawings described below are for illustrative purposes only. The drawings are not intended to limit the scope of the present teachings in any way. 
     DETAILED DESCRIPTION OF THE EMBODIMENT(S) 
     Embodiments of this disclosure encompass systems, methods, and software for proactively and incrementally adjusting equipment operations and inputs/outputs to perform ongoing capture of kilowatt hours (kWhs) being unnecessarily consumed by ongoing recalibration of facility operations all the while maintaining even the strictest environmental quality. The system delivers persistent real-time performance optimization with the implementation of a “kWh harvesting” method and application that provide a long-term, efficient, and cost-effective solution for the reduction of carbon dioxide (CO 2 ) emissions. 
     As mentioned above, the term “kWh harvesting,” as used herein, refers to a systematic and continuous management process based on identification and prevention of excess electrical energy consumption expended in the delivery of load assets, for example, an HVAC load asset, and facility operations loads in the built environment. Energy consumption inefficiencies of such major load assets are reduced and optimized without compromising operations and comfort at any given time. Energy harvesting can be harvested from one or more load assets as described below. 
       FIG.  1    illustrates an exemplary system  100  architecture for implementing embodiments consistent with this invention. These components of the system may  100  be implemented using any suitable combination of hardware, software, and/or firmware. The components may correspond to functional blocks implemented with a set of instructions executed by suitable hardware (e.g., a computer, a server, a group of computers, or one or more computing nodes operating over a network). The components may also correspond to programmable, fixed-function hardware, such as programmable-logic devices, such as PALs, PLAs, CPLDs, orFPGA. The number and arrangement of components in  FIG.  1    is merely provided for illustration. 
     The system  100  with its granular energy consumption tracking capability can be incorporated and seamlessly integrated with any existing Building Management System (BMS)  106 . It should be understood that the BMS  106  as depicted in  FIG.  1    is merely an example and other existing or future BMS may be used in conjunction with the system  100 . The integrated system platform will provide operators the capability to monitor the current carbon footprint posture and project year-end target compliance and goals of commercial buildings, hospitals, universities, and among other facilities. It is noted that buildings and facilities are constructed to have different configurations across the building industry. Thus, the architecture of the system  100  is easily customizable and adaptable to the specifics of each facility for which it is deployed. The system  100  also provides a best-of-class proactive approach to reduce carbon dioxide (CO 2 ) emissions accomplished through ongoing facility performance optimization without sacrificing environmental quality. 
     The system  100  generates these valued emissions reductions by implementing its proprietary optimization technique of “kWh harvesting”. According to the present teachings, kWh harvesting is a sustainability strategy executed by the system to:
         a. Capture the “wasted” usage of kWh of load assets stemming from due universally recognized inherent systems overdesign or overly conservative systems operations.   b. Capitalize on recalibration optimization of operations during non-peak conditions, and ambitiously taking advantage of seasonal and hourly weather variations   c. Optimize energy asset loads that are pointlessly running at 100% capacity 24 hours, 7 days a week   d. Enhance operating efficiencies of energy-consuming load assets with additional controls such as variable frequency drives (VFDs)   e. Taking advantage of load shifting and scheduling       

     As illustrated in  FIG.  1   , the integration of the system into a facility begins with a thoroughly detailed facility evaluation process. A meticulous granular load study is performed. Appreciable electric-consuming load assets  102  that could potentially qualify for the kWh harvesting technique are identified.  FIG.  1    shows examples of load assets  102  (e.g., air handling units (AHUs), pumps, chillers, etc.) that may be used for the kWh harvesting process. It will be readily appreciated that other loads may also be connected to the BMS  106 . All operating parameters of these load assets  102  are codified and documented. 
     These pre-qualified selected load  102  reduction resources are registered into the software platform of the system and assigned to the kWh harvesting protocols. Through a proprietary innovative forward-looking feedback analysis, the software determines at any given time how the load is specifically performing (such as speed, HZ, kW, . . . ) and what load reduction potential is possible as a result of facility real-time environmental coincidental data retrieved from the BMS interface  106 . 
     Once the load assets  102  that qualify for kWh harvesting are identified and selected, the time-stamped sustainable kW reduction from each load  102  is determined and triggered with targeted facility operations acting as the maintained IEQ (Indoor Environmental) reference point. The aggregation of each kW reduction achieved coupled with the associated harvesting period of that reduction will determine the ongoing real-time reduced kWh accumulation being achieved at any instant and cumulative from any point of reference or overall time period. 
     Since one of the primary functions of the kWh Harvesting software is to analyze all the loads  102 , (e.g., AHUs, Pumps, Chillers, etc.), associated with the system  100 , it is essential that the loads  102  are connected to the BMS  106  since all the curtailing commands must pass through the BMS  106  and the feedback status for each load  102  is provided by the BMS  106 . The curtailing command controls the individual loads  102  so as to shift or curtail usage. Thus, all the selected loads  102  selected and triggered for kWh harvesting can be connected to, monitored, and ultimately controlled by the existing facility BMS  106  with the software platform of the present invention acting in a suggested target parameter fully in synchronization with the BMS  106 . 
     In addition, the system  100  reports the energy consumption, in real-time, for each source of energy used by the building where the system is installed. To be able to accurately collect and report the energy resource consumption information, the system  100  must be connected to all the meters  108 , for example, electric, gas, steam and water in the building wherever those meters  108  may be located. The system  100  receives data from the meters  108  and other sensors. 
     The system  100  may interact with other systems that are ancillary to the loads  102 . The system may import information from these ancillary systems, such as LED Lighting Control  110 , which can have their own controllers. Such ancillary systems, participating in the kWh Harvesting strategy, need to also be interfaced with the system  100  so that system  100  can harvest energy from the ancillary system. 
     Industrial panels  112  include the electronic components necessary for implementing the system  100 . Depending on the location of the meters  108 , more than one panel  112  may be required to be installed into the facility to optimize the operation of the system  100 . All the panels  112  are connected together to one main panel which houses an industrial controller  104  ( FIGS.  3 A- 3 B ). The industrial controller  104  is a special purpose computer for controlling the kWh Harvesting process and the components. The various components of the industrial controller  104  can be spatially disturbed about the facility and interconnected to the industrial controller  104 . 
     The industrial controller  104  controls the devices, processes, and other assets of the system  100  via a kWh Harvesting algorithm, which is one of the main components of the system  100 . The industrial controller  104  can execute a control program, which can be used to process input signals read into the controller  104  and to control output signals generated by the industrial controller  104 . 
     In this example, while the meters  108  are hardwired to the panels  112 , the industrial panels  112  and their electronic components, and the BMS  106  are interconnected using the TCP/IP protocol on the building&#39;s internal Ethernet network or on the BMS network  114 . 
     Typically, a computer  116 , such as a Windows™-based computer can be installed on-site at the facility, and connected to the main industrial panel via the same Ethernet network  114 . This on-site computer  116  provides an efficient and convenient way to (re-)configure, manage and monitor the entire system  100 . Although this exemplary implementation discusses a Windows™-based computer, there could be web-based or use of any other acceptable software. 
     In addition, the same software application may be installed on a cloud-based computer  120  for remote management. The cloud-based management computer  120  may also serve as a platform for aggregating and analyzing the data from multiple buildings and facilities. All cloud-based connections can be encrypted and transferred from the internal network to a public internet via the network firewall  122  which regulates inbound and outbound traffic. 
     A web client, such as browsers or applications therein, that may operate on a mobile device  118  may be accessed for monitoring the KPIs (key performance indicators) of the project. The mobile computing device  118  includes a transceiver arranged to (1) send and receive data communications via the BMS network and (2) periodically send operational status data to a remote resource controller (e.g., industrial controller  104 ), the operational status data can include at least one key performance indicator and/or alert message. 
     The remote computing devices may be mobile devices, such as smart phones, table computers, wearable computing devices such as smart watches, or other highly mobile computing devices. The remote computing devices may also include notebook, netbook, desktop, or similar computers located remotely from the facility and communicating with a mobile server via the web client (e.g., a web browser or application running therein). 
     Once the kWh harvesting goal is authorized by facility operations, guided by year-end projections, and the amount to harvest from each load  102  determined, the loads  102  are prioritized and organized in groups. The priority indicates the order in which the loads  102  are activated for kWh harvesting. The lower the priority, the earlier the load will be harvested. The groups are formed with loads  102  to create uniform entities that will provide comparable amounts of kWh that can be harvested. 
     To “assure” the determined kWh harvesting amount necessary for the carbon footprint reduction sought after, each load  102  group has more usage reduction potential available for collecting than required. 
     Each group of loads  102  is on a rotating schedule activated for shedding, for example, for 15 minutes (time adjustable) and then reconnected, for example, for 15 minutes. If there are more than two load groups, each load  102  group is activated less often for kWh harvesting. Each group  102  can be assigned a different time duration for kWh harvesting and reconnection. In general, the more individual loads  102  that are available for kWh harvesting the higher the energy reduction the more load  102  groups can be formed, and consequently each load group, due to the rotation schedule, is less often activated. 
     In summary the unique and smart kWh harvesting controls methodology of the present invention allows for significant kWh reduction without compromising operations or comfort at any given time. 
     The system  100  provides any industry with real-time, next-generation controls strategy for kWh harvesting and carbon footprint management solution. The system  100  fully automates the assessment, compliance, reporting administration, and mitigation capability requirements to meet corporate carbon footprint goals or legislated carbon emission allowances with associated penalties. The system  100  provides deliverables that will meet the challenges of climate change. 
     In use, the system  100  specifically recognizes the infinitely distinctive facility operational modes dictated by occupancy and activities coupled with seasonal and hourly weather variations. The system  100  optimizes operations by responding to inherent systems overdesign, capitalizing on non-peak condition reduction potentials and allowances, and integrated proactive predetermined protocols including selective load reduction rotation. Correcting and capturing these “right sizing” inefficiencies is one of the main principles in delivering high performance sustainable building operations. 
     The system  100  proactively and incrementally adjusts equipment operations and inputs/outputs to perform ongoing capture of the kWhs being unnecessarily consumed by ongoing recalibration of facility operations all the while maintaining even the strictest environmental quality. The system  100  delivers persistent real-time performance optimization with the kWh harvesting technique grounded by long term efficient building operating experience and proven technical capabilities. 
     The facility integration of the system  100  begins with a thorough evaluation process. A meticulous granular load study is performed where all potential load  102  assets that qualify for the kWh Harvesting technique are identified with all operating parameters documented. These pre-qualified selected load  102  assets are keyed into software platform for the kWh harvesting protocol. Through a proprietary sophisticated feed-back analysis the system  100  knows in real-time how the load  102  is specifically performing (speed %, HZ, kW, etc.). 
     Potential load  102  assets can be identified to meet, for example, the following requirements in order to be eligible for kWh-Harvesting:
         Motor Load assets can be on a VFD (Additional VFDs will be added as part of the implementation process).   Resistive Loads, like electric heaters, should be controllable.   Load assets cannot be mission critical (like an Operating Room AHU).   Load assets need to be fully integrated into the BMS.   Load assets needs to meet minimum run times to be viable.       

     To ensure successful selective kWh Harvesting targets and objectives, following exemplary steps can be taken:
         Qualified loads  102  are categorized according to persistent or fixed permanent potential to yield results.   To safeguard seamless operation with negligible impact, load classifications can be alternated based on a preset schedule approved by plant operations.   kWh Harvesting targets and results are continuously monitored and adjusted according to facility conditions and operation mandates. A constant commissioning principle is ingrained in the software platform.       

     In  FIGS.  1 ,  2 A and  2 B , the building management system (BMS)  106  controls one or more devices servicing the building or structure. Such a BMS  106  may be implemented in, for example, office buildings, factories, hospitals, health clubs, movie theaters, restaurants, and residential locations. The illustrative BMS  106  shown may include one or more heating, ventilation, and air conditioning (HVAC) systems, one or more security systems, one or more lighting systems, one or more fire systems, and one or more access control systems. These are just a few examples of systems that may be included or controlled by the BMS  106 . In some cases, the BMS  106  may include more or fewer systems depending on the industry. For example, some buildings may include refrigeration systems or coolers. In some cases, each system may include a client device configured to provide one or more control signals for controlling one or more building control components and/or devices of the BMS  106 . 
     The illustrative BMS  106  shown in the figures include one or more heating, ventilation, and air conditioning (HVAC) systems. For instance, in some cases, the HVAC system may include an HVAC control device used to communicate with and control one or more HVAC devices (individually or collectively) for servicing the HVAC needs of the building or structure. It should be understood that the structure may include fewer than or more than the devices shown. Some illustrative devices may include, but are not limited to a furnace, a heat pump, an electric heat pump, a geothermal heat pump, an electric heating unit, an air conditioning unit, a roof top unit, a humidifier, a dehumidifier, an air exchanger, an air cleaner, a damper, a valve, blowers, fans, motors, and/or the like. The HVAC system may further include a system of ductwork and air vents. The HVAC system may further include one or more sensors or devices configured to measure parameters of the environment to be controlled. The HVAC system may include more than one sensor or device of each type, as needed to control the system. It is contemplated that large buildings, such as, but not limited to an office building, may include a plurality of different sensors in each room or within certain types of rooms. The one or more sensors or devices may include, but ae not limited to, temperatures sensors, humidity sensors, carbon dioxide sensors, pressure sensors, occupancy sensors, proximity sensors, etc. Each of the sensor/devices may be operatively connected to the control device via a corresponding communications port. It is contemplated that the communications port may be wired and/or wireless. When the communications port is wireless, the communications port may include a wireless transceiver, and the control device may include a compatible wireless transceiver. It is contemplated that the wireless transceivers may communicate using a standard and/or a proprietary communication protocol. Suitable standard wireless protocols may include, for example, cellular communication, ZigBee, Bluetooth, WiFi, IrDA, dedicated short range communication (DSRC), EnOcean, or any other suitable wireless protocols, as desired. 
     In the system architecture of  FIG.  1   , the system can include a host device which can be any hardware device that has the capability of permitting access to a network via a user interface, specialized software, network address, protocol stack, or any other means. The host device can function as a server, a client, a local controller, or any other suitable device. The host device can perform various communication and data transfer functions as described herein and can execute one or more application functions. The host device can be any of a variety of computing devices (e.g., computer  116  or remote computer  118 ), such as a server computer, a desktop computer, a handheld computer, a tablet computer, mobile telephone or other mobile device, and the like. The components of the host device may include, but are not limited to, a controller, a system memory, and a bus that couples various system components including the system memory to the controller. 
     The controller may include one or more controllers or processors that execute instructions stored in the system memory. The controller may include a programmable microprocessor. Such a programmable microprocessor may allow a user to modify the control logic of the host device even after it is installed in the field (e.g., firmware update, application update). When provided, the bus may represent one or more of any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of a variety of bus architectures. By way of example, and not limitation, such architectures include Peripheral Component Interconnect (PCI) bus and PCI Express bus. 
     The system memory of the host device can include computer system readable media in the form of volatile memory, such as random access memory (RAM) and/or cache memory. The host device may further include other removable/non-removable, volatile/non-volatile computer system storage media. By way of example only, the storage system can be provided for reading from and writing to a non-removable, non-volatile magnetic media (not shown and typically called a “hard disk drive” (HDD) and Solid State Drive (SSD)). A magnetic disk drive for reading from and writing to a removable, non-volatile magnetic disk (e.g., a “floppy disk,” flash drive, and USB drive), and an optical disk drive for reading from or writing to a removable, non-volatile optical disk such as a CD-ROM, DVD-ROM or other optical media can be provided. In such instances, each can be connected to the bus by one or more data media interfaces. 
     The building system controllers and/or IoT devices may be connected to the host device through any type of connection such as a network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider). In various embodiments, the host device may communicate with one or more devices from the various systems of the building system controllers over the network. Such communication can occur via Input/Output (I/O) interface(s). In some cases, the controller of the host device may be operatively coupled to I/O interface(s) via the bus, and may use the I/O interface to communicate with devices via the building system controllers. 
     In some cases, the control devices and/or the host device may be programmed to communicate over the network with an external web service hosted by one or more external web servers. The control devices and/or the host device may be configured to upload selected data via the network to the external web service where it may be collected, stored, and/or analyzed on the external web server. Additionally, the control devices and/or the host device may be configured to receive and/or download selected data, settings, and/or services sometimes including software updates from the external web service over the network. The data, settings and/or services may be received automatically from the web service, downloaded periodically in accordance with a control algorithm, and/or downloaded in response to a user request. 
     The host device may be a single host device or multiple host devices. The multiple host devices can be configured as a distributed computer system including multiple servers or computing devices that interoperate to perform one or more processes and functionalities associated with the disclosed embodiments. The host devices can include one or more servers or computing devices that can distribute processing and/or memory resources amongst one or more physical and/or virtual machines. As a distributed systems, some or all of the components of the systems can work together over different physical or virtual network devices across a data center or cloud computing environments. 
     The exemplary diagram in  FIG.  1    depicts a plurality of buildings, Building  1 , Building  2 , Building n (collectively, Buildings) each having, for example, one or more HVAC control devices, one or more lighting system control devices, and/or one or more access control system control devices in communication with an external web server. It is contemplated that devices from any number of buildings may be providing information to the external server. In some cases, a few, hundreds, thousands, tens of thousands, or more buildings may be in communication with the external web server(s). The buildings may each have one or more of: an HVAC system, a light system, and/or an access control system, etc., which may be in communication with one another and/or other controller (e.g., host device) configured to operate the systems and devices within the respective building. The control devices from each building may relay performance data, operating parameters, alarm conditions, electricity, gas, water and/or steam usage, etc. to the external server. In some cases, the data may be relayed through a WAN to the external server. In some cases, the external server may be configured to aggregate the data obtained from the individual buildings. 
     As shown in  FIGS.  3 A- 3 B , the device controller, such as WAGO PLC controllers, may be used for providing connections to one or more meters (e.g., electrical, gas, steam, and water, see for example  FIGS.  1 - 2 B, and  5 B- 5 F ) to obtain the data to conduct load asset analysis for performing kWh harvesting, as will be described in more detail herein. Once aggregated, the data can be analyzed for trends, outliers, etc., to make changes and/or recommendations for improving the efficiency of one or more of the buildings. 
       FIG.  2 A  illustrates an example of a main panel  112   a  for use in establishing connections with the components of the system  100 . Implementation of the system  100  within a facility require access to most, preferably all, of the meters  108 . The meters  108  can be, for example, electric, gas, steam, fuel, water, etc. The connections to the meters  108  within the system  100  can be established through components installed in an industrial panel, such as main panel  112   a.    
     Implementation of the system  100  can be performed to modernize an existing facility to monitor its carbon footprint by providing a configuration that does not tamper with the integrity of the facility, including the meters  108  installed in the facility. Because the system  100  does not tamper with the integrity of the meters  108 , a demarcation point is established where the network of system  100  ends and connects with the components or wiring at the facilities&#39; premise. Thus, a DEMARC box  126  is installed to each meter that the system  100  is connected to in order to have access to real-time energy pulse signals. The DEMARC box  126  is then connected via low voltage wiring to components inside the panel ( 112 ). 
     Components inside the main panel  112   a  (which are described below in  FIG.  3 A ), in turn, connect to the BMS  106  using one of communication protocols  124  available in the system  100 . The BMS  106  includes a communication network including software and hardware systems networked to control and monitor various parameters of the facility&#39;s operation. The software program of the BMS  106  is configured to use one or more of a variety of different protocols, such as BACnet, Modbus, DeviceNet, SOAP, XML, ARCnet, LonWorks, and Profibus. These communication networks interface, for example, with room condition monitoring systems, including room pressure monitors, temperature monitors, and humidity monitors, for example. 
     The BMS  106  itself is connected to all the loads  102 , such as AHUs, and transfers all the curtailment commands from the systems  100  to the loads  102  once it has validated those commands. The curtailing command is used to control the individual loads  102  so as to initiate a shift or curtail usage. 
     The components inside the main panel  112   a  can communicate with each other through the internal network  114  whether it is the BMS internal network or the building internal network, such as the campus LAN backbone. In an embodiment where the main panel  112   a  is not connected to the BMS internal network additional device(s) may be required to achieve communication with the BMS  106 . 
     The management computer  116  communicates with the main panel  112   a  usually on the same internal network  114  although it may be located on a separate segment or VLAN requiring additional configuration in the building IT infrastructure such as switches and firewalls. 
     The communication interface may be configured to enable connection to external systems (e.g., an external network). In this manner, data may be retrieved from a remote, external server via the external network in addition to or as an alternative to an internal memory. All external communications, including with remote computers  118  and/or cloud-based computers  120  can be achieved through high-speed internet lines. All the data packets are encrypted to and from these devices and all the connections are controlled by the internal network firewalls  122  and other security measures. 
       FIG.  2 B  illustrates an example of a satellite panel  112   b  for use in establishing connections with the components of the system  100 . Often, a facility may be comprised of multiple building with meters  108  located in each different building, and/or in locations too remote from the main panel  112   a . In such an embodiment, one or several satellite panels  112   b  should be installed and connected to the main panel  112   a  through the facility&#39;s internal network  114 . In this embodiment, a DEMARC box  126  must be installed for each of the meters  108  connected to the satellite panel  112 , as described above. 
       FIG.  3 A  depicts an embodiment of the components that may be installed into an exemplary main panel  112   a . It is understood to a person skilled in the art that the components installed into the main panel  112   a  may differ in numbers and types depending on the BMS ( 106 ) that the system  100  software platform communicates with, the numbers of meters, the protocols used and the number of ethernet connections provided in the system. However, a minimum core number of components will always be present in the main panel  112   a.    
     First, the components may be powered by a 120 VAC power source  142  or any other suitable power source, as desired. A conventional 120 VAC power  142  can be provided to the main panel  112   a  with its power distribution system for all the components present and connected to the uninterruptible power supply UPS  128 . The UPS  128  provides stable power to all the internal components by protecting them against brownouts and power surges. All the components and devices in the main panel  112   a  may use low voltage provided through a low voltage power supply and distribution terminals  140 . 
     In addition to the input power circuitry  142  and the low voltage distribution subsystem  140 , an exemplary main panel  112   a  may include one or more of the following components: 
     1) A WAGO PLC (programmable logic controller) module  138  for digital I/Os. All the meters  108  are connected to the system&#39;s software platform through the WAGO module  138 . The pulses sent by the meters  108  are collected by the WAGO modules  138  and sent to the master controller  104  via an ethernet connection on the internal network  114  for processing. Given that the main panel  112   a  has an ethernet interface, it may be managed and reconfigured remotely should the need arise. 
     2) A master controller  104 . This industrial computer is the brain of the system as it receives all the inputs from the meters  108  through its connection to the WAGO module  138 , processes them using all the algorithms comprising the system software platform and, if necessary, sends corresponding set points commands to the loads  102  by the intermediary of the BMS  106  over the internal network  114 . The master controller  104  in return receives feedback from the loads  102  through the BMS  106 . This process is continuously repeated. 
     3) In various embodiments, a facility is typically configured such that an individual ethernet drop or connection is provided for every device in the main panel  112   a  including a few spares. However, in other embodiments, some facilities only provide one single ethernet connection to the main panel  112   a . In such cases, a small ethernet hub or switch  132  can be added to the main panel  112   a  so that all ethernet based devices in the main panel  112   a  may communicate with the master controller  104  and by extension to other devices such as the BMS  106  and the monitoring computer  116  on the internal network  114 . 
     4) The mode of communication of the system software platform can be, for example, the Modbus protocol which can be used to communicate with the WAGO modules. Since most BMSs  106  use the BACnet protocol, a gateway  134  can be added as a way to communicate with all commercially available BMSs. The gateway  134  enables the system software platform&#39;s Modbus registers to be mapped to BACnet objects so that the system software platform may communicate with the BMS. If the BMS  106  also uses Modbus as its communication protocol then the gateway  134  can be replaced with a Modbus converter to fulfill a similar function. Whether a gateway or a Modbus converter or both are used in a main panel  112   a , they can be accessed and reconfigured remotely through their ethernet interface. 
     5) In some cases, the network infrastructure of the facility is complicated as BACnet is used to connect campuses, not just buildings. When several networks are connected together, a BACnet/IP Broadcast Management Device (BBMD)  136  may be necessary to bridge them so that system software platform may communicate successfully with the BMS  106 . 
     6) Sometimes, glitches may occur in the devices, and it may be necessary to cycle their power (soft reboot). In such a situation, web relays  130  can be a very useful tool to enables a user to perform the soft reboot over an internet connection whether the user is located onsite in the building or off-site. All ethernet based devices inside the main panel  112   a  customarily have their input power connected through the web relay  130  so that they may be remotely and securely accessed. 
       FIG.  3 B  depicts an embodiment of the components that may be installed into an exemplary satellite panel  112   b . In various embodiments, satellite panels  112   b  are used to connect to remotely located meters  108 . They are connected to the main panel  112   a  through the internal network  114 . Since they only collect pulses from the remote meters  108 , they only contain a subset of all the devices in a main panel  112   a . The satellite panels  112   b  can include a 120V power section  142  as well as a low voltage power distribution system  140 . Since the main purpose of a satellite panel  112   b  is to collect pulses from meters  108 , it contains a WAGO module  138  with the required digital I/Os necessary to accommodate all the meters  108  connected. To protect all the components inside the satellite panel, a UPS ( 128 ) is installed in the same way as in the main panel  112   a.    
     As shown in the parameterization flowchart of  FIG.  4 A  and depicted in  FIGS.  5 A- 5 F , the illustrative method begins with an initial set-up that:
         Define Use Group(s) (type of occupancy(s)) as outlined   Determine total Square Footage of Property   Connect all relevant meters, Electrical, Steam, Gas, and Water as shown in  FIGS.  5 D- 5 F .       

     In general, the primary goal of climate change policies enacted in various jurisdictions is decarbonization, the reduction of CO 2  emitted in the atmosphere. To achieve this goal through the implementation of the present invention, all sources of emissions must be accounted for and converted to a common unit, for example, metric tons of CO 2e —CO 2  equivalent, so that all CO 2  emissions may be quantified. 
       FIG.  4 A  is a flowchart of the process implemented by a parameterization algorithm which is used by the system to derive values of the various parameters being used in the process to calculate the CO 2  emission limits of a building.  FIGS.  4 B- 4 D  are screenshots illustrating exemplary parameters that can be monitored, controlled and displayed based on the process performed in  FIG.  4 A  consistent with various embodiments. The parameterization algorithm in step  200 , as described herein, is integral to the implementation of the kWh Harvesting system and method. In step  201 , the algorithm calculates the emission limits of a building based on the types of occupancy or use groups and greenhouse gas (GHG) target factors. In response, as illustrated in  FIGS.  4 B- 4 D , a processor may instruct a user&#39;s device to display a use groups/types of occupancy column  201 C and the associated GHG target factors columns  201 A and  201 B. 
     In calculating the emission limits for a building, there are many factors that affect the total emissions. Indeed, calculating the emission limits of a building as well as the total actual emissions of that same building over time enables building owners and managers to assess the performance of the kWh harvesting strategy as well as other mitigating strategies that may be implemented. The present system collects and maintains data and aggregates the data of these various sets of factors which culminates into the reporting requirements. 
     Thus, the target factors can be time period sensitive. Using the user interface, the user can select a certain time period for the system to calculate the GHG target. For example, the greenhouse gas (GHG) targets can be managed using the methods and systems of the present invention such that they are assessed during specific time periods or during particular time periods based on certain conditions. In the example of  FIGS.  4 B- 4 D , a first GHG Target column  201 A provides a list of numbers representing a list of GHG targets for each load set for the period of 2024 to 2029. A second GHG Target column  201 B) provides a list of numbers representing a list of GHG targets for each load set for the period of 2030 to 2034. 
     While many embodiments in this disclosure relate to the types of occupancy, the target periods and their associated targets that were designed to comply with the law (Local Law 97) voted in New York City, the disclosed embodiments can be easily modified to accommodate other localities and jurisdictions. For example, other localities and jurisdictions may have different time periods, different user groups/types of occupancy and different factors. 
     In step  202 , the system converts all sources of energy to the same unit, (e.g., Metric Tons of CO 2 ), so that the total energy consumption of a building may be calculated and compared to the total emission limits of the same building. 
     In response, the system compiles and lists in the energy source column  202 A all of the exemplary sources of energy (in  FIGS.  4 B- 4 D ) in a table, which can be updated to add additional sources, if necessary. To satisfy reporting requirements, the system can perform both the conversion from the original unit of the source of energy to kBTU, and then from kBTU to Metric Tons of CO2e. The results of the conversions in step  202  can be displayed in conversion unit column  202 B. 
     In step  203 , the system can be used by a user to set up email notifications. The notifications may include the recipient&#39;s information such as displayed in email address column  203 C, and communication method  203 A. Various types of reports and information can be compiled and reported to various recipients by selecting the item(s) in the reporting column  203 B. For example, a management report at the end of the year which summarizes the status of the building with supporting data, can be communicated to one or more recipients. 
     In step  204 , to provide a strong incentive for building owners and managers to comply with the locality or jurisdiction&#39;s law, the system can calculate the yearly penalties that will be assessed when the CO 2  emissions of the building exceeds the calculated limits based upon the use group(s) and square footage of the building. In response, the system displays the penalty amount in the $ penalty/$ on exchange section  204 A. 
     In the example in  FIGS.  4 B- 4 D  of the City of New York, penalties will be assessed at $268 per Metric Tons of CO 2  in excess of the building&#39;s calculated limits. Although the penalty per Metric Tons of CO 2  for the period running from  2030  thru  2034  may be even higher, the example shown uses the same value. 
     In step  204 , the system can be further configured to operate with existing systems and also future systems to set up an exchange for “carbon credits” (displayed in section  204 A in  FIGS.  4 B- 4 D ). The example in section  204 A illustrates the financial benefit that a CO 2  emissions surplus might provide. The trading of carbon credits that can be facilitated through the use of the system enables the practice of buying and selling permits and credits that allow the permit holder to emit carbon dioxide. 
     It is known to one skilled in the art that other localities and jurisdictions may decide to configure their systems to have different schedules, penalty levels and whether an carbon credit exchange will be created. The software of the present invention is flexible enough to accommodate all modifications and changes. 
     In step  205 , in addition to the above conversion factors, the system can also perform the conversion from Site EUI (Energy Use Intensity) to Source EUI and display the resulting conversions in the Site EUI to Source EUI section  205 A to provide a more complete assessment of the energy efficiency of a building similar to the Energy Star program. As defined on the Energy Star web site, the term “site energy” means the amount of heat and electricity consumed by a building as reflected in utility bills. The term “source energy” means the most equitable unit of evaluation for comparing different buildings to each other. Source energy represents the total amount of raw fuel that is required to operate the building. It incorporates all transmission, delivery, and production losses. 
     In step  206 , the system displays, as shown on the screen in  FIGS.  4 B- 4 D , a SAVE button  206 A that allows the user to initiate the system to save all the data entries to a local computer and/or the industrial controller. In addition, an exemplary vertical menu on the left (referenced as  208 ) is depicted to show examples of visual cues for some categories of actions that can be available on each of the submenus. In step  207 , the subprocess ends. 
       FIGS.  5 A- 5 I  are exemplary screenshots showing meter data displayed on a screen to enable a user to visualize—in real-time—all the meters for all the sources of energy for all the utility accounts in the building as wells as their totalized values to provide a visual cue for the readings of the meters. The user can elect to see the resulting comparison in either graphical or numerical data form, can select a number of different meters to compare side-by-side simultaneously, can compare the results over a number of selected years, and can compare the results to either the building average or the industry average.  FIGS.  5 A- 5 C  illustrate exemplary screenshots of an electric meter.  FIGS.  5 D- 5 F  illustrate exemplary screenshots of a gas meter.  FIGS.  5 G- 5 I  illustrate exemplary screenshots of a steam meter. 
     In  FIGS.  5 A- 5 L , the meter data can be displayed on the screen in a graph  301  or through a depiction of a gauge  302 , such as a meter, a pie chart, a progression bar, or any other representation of a percentage of progress that may represent energy usage. In  FIG.  5 A- 5 I , the graphs  301  show all the individual meters for each of the sources of energy utilized in the building. The representation in graph form  301  depict all the meters along with their location, and other particular information such as the meter number if available. The graph  301  enable the users to quickly pinpoint abnormal behavior as well as malfunctioning meters. 
     The total value of all the meters in the account can be shown in a totalizer section  303 . 
     If the building is comprised of more than one utility accounts, an account button  305  can allow the user to switch to another account. 
     In addition, if a specific building also uses gas meters and/or steam meters, a building meter button  304  can be provided for the user to switch between the different types of meters for a specific building. 
       FIGS.  5 J- 5 L  are screenshots of an example summary of all the meters for all the sources of energy for all the utility accounts. The summary data can provide to the user a comprehensive view of a building&#39;s energy instant demand by accounts and energy sources. 
     Following the same format in  FIGS.  5 A- 5 I , totalizer sections  307  by energy sources and by accounts can be provided as well as a totalizer for the campus-wide electric instant demand. Through the use of the data collected at the WAGO module, a demand response submodule can be configured to reduce carbon emissions, optimize resource usage and/or calculate the monetary cost of the resource usage and potential cost reduction such resource usage in response to satisfy the demand of the facility. 
     The demand response submodule can provide a response to input data received from sensor inputs, such as carbon dioxide levels, curtailment signals, temperature, occupancy sensors, humidity levels, air quality sensors, electrical use, thermal measurements, pricing information and the like. The demand response submodule can be configured to communicate with the kWh harvesting algorithm to activate or deactivate building equipment, implement or change control strategies, or change setpoints. 
     The demand response submodule can use models to determine an optimal carbon emission reduction strategy. The demand response submodule can further include a policy definition module component that allows system administrators to define system operating policies to be implemented according to, for example, jurisdictional regulation requirements, such as carbon emission laws and policies. In particular, the policy definition module allows the administrators to create new operating policies, modify already existing operating policies, e.g., modifying, adding, deleting operating rules, delete operating policies, define conditions in which specific operating policies has to be actuated in order to be in compliance with the specific jurisdictional regulation requirements. The system administrators may for example access the policy definition module and perform the above actions remotely, via a web interface, exploiting one of the known web browsers. The policy definition module is capable of translating the operating policies entered by the administrators into a format specific and supported by the desired targets. 
     Referring now to  FIGS.  6 A- 6 E , a flowchart of a process for calculating the emissions limit in metric tons of CO 2  vs. CO 2  tonnage emissions is shown and illustrated in the screenshots of  FIGS.  7 A- 7 M . Once the types of occupancy and their associated square footage are entered, the emissions limit in metric tons of CO 2  is calculated, displayed and aggregated. 
     Each source of energy is collected separately in real-time and the emission tonnage converted to kBTU and then to metric tons of CO 2 . 
     An emissions limit higher than the actual tonnage emissions result in a surplus which may be monetized on a future carbon credit exchange or used for another building in the owner&#39;s portfolio if that building experiences a deficit. 
     An emissions limit lower than the actual tonnage emissions results in a deficit. The relevant area of the summary panel will turn red and show both the calculated CO 2  deficit and its corresponding monetary penalty, for example, at $268 per metric ton of CO 2  in excess. 
     Through these calculations the software enables the user to monitor the actual CO 2  tonnage emissions in real-time year-to-date. It also offers the capability to extrapolate and forecast the CO 2  tonnage emissions for the entire year. 
     The software can use the actual date data or data for a range of dates. 
     Calculations: 
     As illustrated in  FIGS.  7 A- 7 F , the forecasting of the CO 2  tonnage emissions is achieved in several steps: 
     First, a ratio is calculated between the actual data of the current year and the equivalent period for the previous year. This calculation is performed for each source of energy. 
     Second, the software looks at the archives and calculates the energy consumption for the balance of the previous year for each source of energy. 
     Third, the ratio calculated in step 1 is applied to the energy consumption calculated in step 2. This action is performed for each source of energy used. 
     Fourth, the extrapolated energy consumption for the balance of the year is added to the actual data year-to-date to provide an estimated year-end energy consumption. This action is performed for each source of energy used. 
     Finally, the calculated values are converted to metric tons of CO 2  and aggregated together. The resulting totals are compared to the emissions limit as before. 
     Specifically, in  FIG.  6 A  is a flowchart that provides details of the building&#39;s use group can be setup by the user 
     Once all the use groups (i.e., types of occupancy) and associated factors are entered into the system and set for the target locality and jurisdiction. As shown in  FIG.  6 A , in step  340 , the building&#39;s use group can be setup by the user entering the information via a user interface into the Use Groups column  341 A (shown in a screenshot of  FIGS.  7 A- 7 D ) such that the system can track the building&#39;s energy consumption in real-time. 
     In step  341 , for example, by selecting the screen in  FIGS.  7 A- 7 D , the user may enter the types of business or businesses are hosted so that the system may derive the associated use groups. The types of businesses can then be selected from a dropdown menu button. In step  342 , the user may enter the corresponding gross square footage of each of the individual use groups into Square Footage column  342 A. 
     When a use group is selected from the dropdown menu and its associated square footage entered into the system by the user, in step  343 , the software automatically calculates the amount of CO 2  that the business or businesses associated with the use group is or are allowed to emit and enters the calculated results into the GHG Target columns  343 A. 
     In step  344 , if the use group selected has multiple tenants such as a commercial building or a multi-residential building, then the process advances to  FIGS.  7 K- 7 M  and a Show Tenants Detail button  345 A will be displayed on the right part of the screen as a dropdown menu next to the “Utility Electricity” energy source column (which will be discussed in further details with regards to  FIG.  6 E  and Screenshots  FIGS.  7 K- 7 M . 
     Referring back to  FIG.  6 A , in step  346 , if the building hosts businesses in more than one use group, the user can enter all the use groups by selecting each from the dropdown menus and their associated gross square footage indicated in the corresponding entry field  342 A. 
     After all the use groups are selected and their square footage entered into the software, in step  347 , the process saves the selections information to the local computer (management PC) and transferred to the industrial computer. 
     In As previously discussed,  FIGS.  1 ,  2 A and  2 B  explains the importance of connecting to most, preferably, all the energy sources and their associated meters  108 .  FIGS.  7 A- 7 D  provide a detail illustration for the user to observe the results, in real-time, of those connections. 
       FIG.  6 B  is a flowchart that provides details various options available to the user to display the energy consumption by energy sources. In step  350 , the process provides the calculations that enables the user to monitor the actual CO 2  tonnage emissions. In step  351 , data regarding energy usage from all the meters is entered input into a special computer program (SP-747) ( 351 ) running on the master controller in the main industrial panel. This computer program can be configured to be responsible, for example, for keeping track of the various energy sources and for accumulating the results, year-to-date, for extrapolating the year-to-date with forecast reading using last year data, and for extracting last year totals from the archives. 
     In step  352 , using a navigation button the user may select from various screen view options.  FIGS.  7 A- 7 D  show an example of a default view displaying the Year-to-Date energy consumption by energy sources. 
     Once the default view is displayed, the user is presented, for example, with four or five views to select from in step  352  as screen view options  352 A shown in  FIGS.  7 A- 7 D . 
     A. In step  354 : display a summary of last year&#39;s energy consumption by energy sources field  354 A. 
     B. In step  355 : the Default view of the energy consumption year-to-date field  355 A. 
     C. In step  356 : the view extending the year-to-date data with a projection of the energy consumption by energy sources to the end of the year field  356 A. This option will be discussed further with regards to  FIG.  6 C  which explains how the forecast for the remainder of the year will be extrapolated using not only actual data from January 1 st  until the current date but also last year&#39;s data from the current date until the end of the year (step  358 ). 
     D. In step  357 : The user also has the option to compare the year-to-date energy consumption month-by-month with the previous year or any other available year of historical data available as shown in field  357 A. This option in step  359  will be discussed further with regards to  FIG.  6 D  and shown in screenshots  FIGS.  7 E- 7 F  where the data is extracted from a special archive named Daily Year-to-Date, and summarized by months for each of the two years being compared. Once this is done, a delta is calculated, both in absolute values and in percentages, for each of the months; finally, the resulting data is displayed on a special pop-up panel. 
     E. In step  353 : The system can be configured such that this option is only available if one of the use groups selected in  FIG.  6 A  includes Business and/or Multi-Residential. This option allows the user to display the energy consumption at the tenant level. It is particularly relevant to the entire kWh harvesting strategy, as it enables building owners and managers to identify tenants who would be the principal beneficiaries of the strategy. This option will be further discussed in  FIG.  6 E  and displayed in screenshots  FIG.  7 G- 7 H . 
     In step  360 , whenever the user selects the option of step  354 , step  355  or step  356 , the resulting energy consumption of each of the used energy sources is first converted to kBTUs and then to Metric Tons of CO 2 e before being displayed on the screen ( FIGS.  7 A- 7 D ). 
     Finally, in step  361 , the delta between the CO2 emissions limits and the actual CO2e tonnage is recalculated for both periods of reference in the example of the NYC jurisdiction field  361 A. If the result is a deficit for either period, the calculated deficit is multiplied by the proposed penalty per metric ton of CO2e and the result clearly indicated as a penalty. If, however, the delta is a surplus, it is multiplied by the placeholder value to show a potential value on a future Carbon Credit Exchange. 
     One of the many functions that the software provides is the capability to extrapolate the energy consumption for each of the energy sources to the end of the year. 
     This extrapolation calculation is predicated upon having historical data for the prior year for each of the meters that are included and that system is actively monitoring. 
     The system is capable of providing mid-year extrapolation calculations. At the mid-point of the current calendar year and last year&#39;s data is available, is the system can perform the important mid-year extrapolation calculations to determine the current energy consumption of the entire building and extrapolate an end of the year energy consumption. Such granular analysis enables the building manager to enact aggressive countermeasures in advance to mitigate any potential financial liability at the end of the year. This is one of the important features of the kWh Harvesting strategy because it provides an unobtrusive methodology to reduce energy consumption distributed over all the air handling units (AHUs) managed by the system. 
     Granted, in some situations, there may be drastic changes in the topology of the HVAC plant from one year to the next. In such a situation, the system is capable of adapting to such changes. For instance, the building manager most likely will be well aware of those changes and can enter the changed configurations such that the system can adjust the forecast accordingly. Thus, the ability to forecast end-of-year energy consumption by energy sources is important and cannot be discounted. 
     Referring to  FIG.  6 C  is a flowchart that provides details of the process in step  370  which calculates the extrapolation for the remainder of the year based on last year&#39;s data. 
     In step  371 , using, for example, the special computer program SP-747 the system analyzes the year-to-date energy consumption for each of the meters across all sources of energy. 
     In step  372 , last year&#39;s archives which stores the energy consumptions data are read in the computer program and, in response, a total “year-to-date” is calculated for each of the meters for each of the energy sources. In step  373 , a ratio is calculated  373  between last year&#39;s Year-to-Date energy usage and this year&#39;s Year-to-Date energy usage for each of the meters/sources of energy. 
     Next in step  374 , the ratio of step  373  is applied to last year&#39;s data for the balance of the year for each of the meters to generate a forecast for each meter and source of energy. 
     Last, in step  375 , the extrapolated data is added to the year-to-date data for each source of energy to generate a yearly forecast. 
       FIG.  6 D  is a flowchart of the process of comparing energy data month-to-month Having access to the calculation results of the energy consumption of one&#39;s building year-to-date and year-to-date with forecast is important but without context provides only a truncated view of the dynamics of the building. Indeed, years are different due to the weather or other external circumstances such as COVID. The energy consumption of the building may also vary month to month besides year to year. Indeed, a building must be heated in winter and cooled in the summer. Different pieces of machinery are used with different power consumption. 
     In step  380 , a sub-algorithm compares the energy consumption of the building month to month and also with other years for which the monthly data is available. The results may be seen on screenshots  FIGS.  7 E- 7 F . 
     In step  381 , the sub-algorithm relies on special program SP-747 to pull the year-to-date energy usage from all the meters monitored by the system. The energy usage is then summarized by months. 
     In step  382 , the sub-algorithm pulls the complete energy usage and summarizes it by month for the selected year to compare. Initially, year-to-date data of the current year field  382 A will be compared with the previous year&#39;s data field  382 B. 
     Once the data is extracted, in step  383 , the sub-algorithm calculates the month-to-month differences in values and percentages. 
     Finally, in step  384 , all the results are displayed on a pop-up panel along with a graph, as shown in  FIGS.  7 E- 7 F . 
     Thus, the system provides the user then with the capability to compare any years for which historical data stored is in the system. This enables the user to analyze the evolution of the energy consumption month over month and year over year. 
       FIG.  6 E  is a flowchart of a process for determining the energy consumption for multi-tenants. Indeed, while a tenant in a multi-occupancy building may be directly responsible to the utility company for their energy demand and consumption, the building owner is still responsible for the entire envelop, meaning for the overall energy consumption of the entire building. From such a dichotomy in responsibilities, there may arise such a scenario where one or several tenants, residential or business, types are causing the building owner a financial penalty due to their outsized energy consumption. 
     To help building owners mitigate such situations, in step  390 , the algorithm of the present invention can be used to handle as identified in multi-tenancy in business and multi-residential buildings. 
     As previously discussed in  FIG.  6 A , if the use groups/types of occupancy is selected as having multi-tenants in step  344  shown in use group field  344 A, then in response a Show Tenants Detail button  345 A is displayed on the screen of  FIGS.  7 K- 7 M  so that the building owner or manager may track their tenants&#39; CO 2  allocation and actual usage. 
     To enable such a detailed tracking requires very little additional set up as indicated on screenshots  FIGS.  7 I- 7 J  (step  391 ). Each and every utility meter must be set up (step  390 ) in our platform anyway. So, the only additional tenant information section  390 A in  FIGS.  7 K- 7 M  required are as follows: the tenant name, the square footage associated with the tenant, the tenant&#39;s email address for alert notifications and last, whether the meter is associated with a tenant or is part of the building&#39;s common areas. 
     After the tenant information setup is completed, the user can select tenant detail button  345 A to display the screen showing the metrics for all the tenants as shown in  FIGS.  7 G- 7 H . 
     In step  392 , the CO 2  emissions limits are calculated for each of the tenants along with their percentage of contribution to the entire building and displayed in the CO 2  emission limits section  392 A. 
     In step  393 , the energy usage for each meter along with key information is pulled and collated by special program SP-747 for the current billing cycle and year-to-date and displayed in the tenant energy usage section  393 A. In step  394 , the CO 2  usage for the current billing cycle as well as year-to-date is then calculated for each of the tenants along with their percentage of contribution to the entire building and displayed in the current billing cycle section  394 A. 
     In step  395 , the algorithm calculates the CO 2  delta to determine the Metric Tons CO 2 e surplus or deficit for each tenant and displayed in the CO 2  delta section  395 A, populates the pie charts and performs some ancillary statistics. 
     After all the calculations are completed, in step  396 , the pop-up screen is displayed with a ranking based on the tenant usage, for example, of the top 16 tenants, as shown in  FIGS.  7 G- 7 H . The building owner can also look for a particular tenant&#39;s information or rank the list of tenants from an exhaustive list of sort options. 
       FIGS.  8 A- 9 F  depict exemplary topologies of all the equipment and devices that are an integral part of the implemented solution. It is indeed essential for the building managers to understand how all the operate together. The topology also provides comprehensive view on a single screen. In various embodiments, the topology view may differ tremendously from one building to another depending on the complexity of the facility. The system, as well as a user such as a building manager and engineers, may monitor all the meters and pinpoint rapidly any problem that may arise using automated and/or visual cues. Alerts may also be provided by SMS and/or emails to various recipients. 
     The importance of Environmental, Social and Governance (ESG) is rising because the financial performance of many companies is increasingly being linked to corporate sustainability and societal impact. One important ESG target is decarbonization, which refers to reducing emission of greenhouse gases (GHG). Thus, it is becoming of vital importance to ensure that the kWh Harvesting methodology is delivering the promised kWh savings since a loss may or might result in financial penalties. The goal is to shift the burden of carbon emission related damage through monetarization back to those who are responsible for it, and who can reduce or compensate for it. 
     The exemplary topologies in  FIGS.  8 A- 8 E and  9 A- 9 F  provides examples of the layout of the meters, how they communicate with the industrial computers via IOT devices such as WAGO PLCs and how in turn, the industrial computer communicates kWh Harvesting commands to the BMS. The example topologies of  FIGS.  8 A- 8 E and  9 A- 9 F  are not limiting on the embodiments, and any operating systems consistent with the present embodiments can include any number of components not depicted in  FIGS.  8 A- 8 E and  9 A- 9 F . 
       FIG.  10    is a flowchart of a process for mitigation measures and strategies.  FIGS.  11 A- 11 C  are screenshots depicting the mitigation measures and strategies in  FIG.  10   . The system can be configured to decide whether a kWh mitigation is necessary. If mitigation is necessary, the method performs the steps shown in the mitigation measures and strategies flowchart in  FIG.  10    and  FIGS.  11 A- 11 C  to take advantage of the kWh harvesting capabilities. 
     In various embodiments, the kWh Harvesting methodology and associated algorithms provides the user (e.g., a building owner or manager) with not only with a building&#39;s carbon footprint but also with strategies to mitigate their potential environment and financial exposure. 
       FIGS.  11 A- 11 C  are screenshots that illustrate such mitigation strategies. In  FIGS.  11 A- 11 C , the exemplary screenshot shows, on the left-side, the status of the carbon emissions of the building t and, on the right side, potential mitigation measures. In step  400 , the system can implement mitigation measures that not only include the real-time contribution of the kWh Harvesting strategy and its corollary, namely contribution of intelligent Demand Control (iDC) and intelligent Demand Response (iDR), but also incorporates external contributions of mitigations initiated, for example, by the building owner or manager such as a lightning upgrade, the installation of variable speed/frequency drives, etc. 
     In step  401 , activation of a navigation button can enable the building owner or manager to display the status of the building either year-to-date format (in step  355 ) or extrapolated to the end of the year format (in step  356 ) as described on  FIG.  6 B . 
     In step  402 , he status information can be presented divided, for example, in three blocks  402 A,  406 A, and  410 A, namely the CO 2  status, the CO 2  tonnage surplus or deficit expressed in a dollar value, and finally if relevant, the potential value of a surplus on a future carbon credit exchange. 
     In step  403 , the user can enter any mitigation project into the mitigation measures section  403 A that may have been invested in to mitigate the user&#39;s exposure, if any. Several typical types of projects may be preformatted into the system with the possibility for the user to provide their own. In step  404 , if there is a capital investment project, the user can enter the expected kWh contribution into the kWh Contribution column  404 A from the external study. In addition, in step  404 , the user can enter the associated CAPEX$ into CAPEX$ column and the ROI into the ROI column of section  404 A. In step  405 , the program will then automatically calculate the Metric Tons of CO 2 e and associated $Cost reduction associated with that investment and populate the information into Metric Tons of CO 2 e column  405 A. 
     In step  406 , the algorithm applies the total CO2e reduction to the left panel into the Metric Tons of CO 2 e column  406 A and recalculate the building&#39;s exposure, either a surplus or a deficit. 
     In step  407 , the user may enter any number of mitigation measures. In this example, the user may enter up to six mitigation measures. 
     Independently from the mitigation measures provided by outside consultants as aforementioned, in step  408 , the outcome of the kWh Harvesting methodology is summarized as measure  7  and the ancillary contribution of the iDC and iDR as measure  8  and presented in section  408 A. The value of the kWh Harvesting contribution is re-calculated in real-time and annualized. 
     Then, in step  409 , similarly as with the outside mitigation measures, the associated Metric Tons of CO 2 e and $Cost reduction are calculated and entered in section  409 A; their values are reflected in the left panel into the Metric Tons of CO 2 e column  406 A and the surplus or deficit recalculated in step  410  and displayed in section  410 , as well. 
     Finally, if there is a surplus, its value on a future carbon credit exchange will be calculated and displayed. 
       FIGS.  12 A- 12 F  are flowcharts of the process using the software platform, which can be interfaced with the components of the BMS to connect directly to the load assets and hence enable kWh harvesting. 
     A load study or a detailed analysis identifies all the load assets that meet any of the following criteria:
         Capture kWh stemming from inherent system overdesign   Capitalize on recalibration of operations during non-peak conditions   Optimize energy assets that are needlessly running 100% capacity 24 hours for 7 days a week   Enhance efficiencies of energy consuming load assets with additional controls   Load shifting and scheduling possible   Taking advantage of seasonal and hourly weather variations       

     Referring to  FIG.  12 A , a flowchart for establishing the prerequisites for the process for configuring the software platform to interface with the components of the BMS to connect directly to the load assets and hence enable kWh harvesting is shown. The process is shown to include configure the software platform (step  420 ); initial ASHRAE-Quality Load Audit and Study provides data to fully configure the software platform (step  421 ); connection to all meters (step  422 ); monthly targets (step  423 ); dates of billing cycles (step  424 ); $cost/kW and #Cost/kWh (step  425 ); connection to BMS via BACnet/Modbus (step  426 ); set up feedbacks (step  427 ); set up all setpoints (step  428 ); connection to all managed loads (step  429 ); parameterize all loads (step  430 ); parameterize all curtailment points (step  431 ); set the maximum curtailment level for each load (step  432 ); and set up priorities of curtailment ( 433 ). 
     Referring to  FIG.  12 B , a flowchart for performing the setup for the process for configuring the software platform to interface with the components of the BMS to connect directly to the load assets and hence enable kWh harvesting is shown. The process is shown to include set up the software platform for kWh Harvesting (step  440 ); get the maximum load available for Harvesting from the Load Study (step  441 ); select the minimum kW to be harvested as a percentage (step  442 ); select the fraction of the loads to harvest (step  444 ); expressed in the unit in which the feedbacks are received from the BMS (step  445 ); indicate the enrollment in the various Demand Response programs, if relevant (step  446 ); select the loads to enroll the kWh Harvesting strategy (step  447 ); the kW contribution in the kWh Harvesting program is calculated and displayed automatically (step  448 ); for load selection, see attachment screenshots  FIGS.  13 C- 13 D ; organize the loads in groups with similar kW yields (steps  449 ); and for load grouping, see attachment screenshots  FIGS.  13 G- 13 H . 
     Referring to  FIG.  12 C , a flowchart that continues the setup for the process for configuring the software platform to interface with the components of the BMS to connect directly to the load assets and hence enable kWh harvesting is shown. The process is shown to include select the loads to include the kWh Harvesting strategy (step  447 ), get the calculated kW that can be harvested for all the selected loads (step  448 ); group them in groups with similar kW harvesting potential (step  450 ); change the priorities and/or change the size of the groups (step  451 ); able to create coherent groups (step  452 ); determine do the groups&#39; kW yield approximate the minimum kW calculated (step  453 ); set the load groups&#39; duration and overlap time (step  454 ); and curtailment time ( 455 ). 
     Referring to  FIG.  12 D , a flowchart that implements the process for configuring the software platform to interface with the components of the BMS to connect directly to the load assets and hence enable kWh harvesting is shown. The process is shown to include kWh Harvesting (step  460 ); minimum and actual kWh harvesting (step  461 ); activate the kWh Harvesting Strategy (step  480 ); monitor instant demand (step  463 ); determine whether the monthly target has passed (step  464 ); Intelligent Demand Control starts independently from the kWh Harvesting (step  465 ); report iDC curtailments from the kWh Harvesting curtailments (steps  466 ); curtail the first available load with the lowest priority as required by iDC (step  467 ); start iDC curtailment timers associated with the specific load (step  468 ); determine if the Instant Demand is below the monthly target (step  469 ); reset timers as loads are being released (step  470 ); curtail the next available load with the lowest priority as required by iDC (step  471 ); and start curtailment iDC timers associated with the specific load (step  472 ). 
     Referring to  FIG.  12 E , a flowchart that continues the implementation for the process for configuring the software platform to interface with the components of the BMS to connect directly to the load assets and hence enable kWh harvesting is shown. The process is shown to include select the loads to include the kWh Harvesting strategy (step  480 ); minimum and actual kWh harvesting shown in screenshots  FIGS.  13 E- 13 F ; accumulate kWh harvest in a predetermined time interval, e.g., 15 minute intervals) (step  482 ); activate first load group for kWh Harvesting (step  483 ); activate curtailment timers for the load group (step  484 ); monitor the curtailment timers of the active load group (step  485 ); determine whether the current load group&#39;s curtailment timers have reached the cutoff time (step  486 ); keep on harvesting kWh from the current load group (step  487 ); activate the overlap timer (step  488 ); activate the next load group for kWh harvesting (step  489 ); activate curtailment timers for the next load group (step  490 ); determine whether the overlap timer has elapsed (step  491 ); release the loads in the previous load group (step  492 ); and reset the curtailment timers for all the loads in the group. 
     Referring to  FIG.  12 F , a flowchart that performs the measure and verification (M&amp;V) for the process for configuring the software platform to interface with the components of the BMS to connect directly to the load assets and hence enable kWh harvesting is shown. The process is shown to include measures and verification subprocess (step  500 ); for the savings proceed to screenshots  FIGS.  15 A- 15 D  (step  501 ); kW, kWh, $Energy Cost Savings, CO 2  Reduction, Demand Cost Savings are accumulated at the end of the predefined time interval (e.g., 15 minutes) via the computer program (SP-745) running in an independent thread (step  502 ); savings archive files are saved (step  503 ); the graphic engine provides a number of canned graphics and enables the user to design one&#39;s own graph to measure and verify the kWh Harvesting program (step  504 ); see screenshots  FIGS.  14 A- 14 D  (step  505 ); daily curtailed demand with monthly means of curtailed demand (step  506 ); savings by billing periods, year-to-date, and since project inception (step  507 ); daily energy harvested (step  508 ); and all generated graphs allow the user to pull the data behind the graph for detailed analysis. 
     According to the kWh harvesting flowcharts  FIGS.  12 A- 12 E , screenshot  FIGS.  12 G- 12 H  and  FIGS.  13 A- 16 D , once the loads that qualify for kWh Harvesting are identified the sustainable kW reduction from each individual load without compromising operations at any given time is determined. The aggregation of all the kW amounts from each load multiplied by 8,760 (hours in a year) will determine the kWh harvesting amount. (E=∫P∂t [kWh]) 
     Since all the loads are connected to the BMS and software platform is fully integrated into the BMS the reduction typically is achieved via percentage of speed, or Hertz, degree Fahrenheit, or kW (HP). 
     In  FIGS.  13 A- 13 J , once the kWh harvesting goal is set and the amount to harvest from each load determined, the loads are prioritized and organized in groups. The priority indicates the order in which the loads are activated for kWh harvesting. The lower the priority, the earlier the load will be harvested. The groups are formed with loads to create homogeneous entities that will provide comparable amounts of kWh that can be harvested. 
     In order to “guarantee” the determined kWh harvesting amount, each load group has more kW available for harvesting than actually required. That is furthermore of importance should a single load or multiple loads within a load group not be available, or running on a reduced power output level for whatever reason. 
     Each group of loads is on a rotating schedule activated for shedding, for example, for 15 minutes (the time is adjustable) and then reconnected, for example, for 15 minutes. If there are more than two load groups, each load group is activated less often for kWh Harvesting. Each group can be assigned with a different time duration for kWh harvesting and reconnection. For instance, with  3  groups:
         Group 1 (loads with the lowest priority such as a lobby AHU): Harvesting for 30′ every 30′   Group 2 (non-critical loads with higher priorities): Harvesting for 20′ every 40′   Group 3 (critical managed loads with the highest priorities): Harvesting for 10′ every 50′       

     In general, the more individual loads available for kWh harvesting, the higher the total energy reclaimed. Additionally, the more individual loads available, the more load groups can be formed and consequently the less often each load group is activated due to the rotation schedule. 
     As shown in  FIGS.  14 A- 15 D , to guarantee persistent performance and target delivery, the system also provides very robust Measures and Verifications (M&amp;V) capability available in real time and aggregated granular histories. The software platform provides an exhaustive set of data that ensure that the amount of kWh harvested coincides with or exceeds the kWh harvesting goal that was established. That data can be displayed in various graphs and data tables for M&amp;V. 
     Screens and graphs, as depicted in  FIGS.  14 A- 14 D , provide a visual representation of the daily harvested energy as well as of the CO 2  reduction. In  FIGS.  15 A- 15 D , a savings dashboard presents a summary of both the harvested energy and the CO 2  reduction by billing periods, year-to-date and since the inception of the project. 
     The system, method and software encompass both peak load control and kWh harvesting. In various embodiments, these two strategies can be distinct and complementary. 
     While kWh harvesting can be implemented to work in the background affecting loads on a rotating basis and in a very subtle and imperceptible way, peak load control is configured to only take place when the trend of the instant demand exceeds the set monthly target. However, when it takes place, it may affect only some of the loads, based on the aforementioned priorities, or all the loads if the calculated trend warrants it. 
     Peak load control works in conjunction with the kWh harvesting rather than replacing it. While the peak load control is disengaged after the demand surge subsides, the kWh harvesting will continue to operate unhindered. 
       FIGS.  16 A -A 6 D illustrate an aggregate summary view of the kWh harvesting operations which can be displayed on a data interface dashboard in real-time to users. Embodiments of the present disclosure present technological improvements as solutions to proactively and incrementally adjust equipment operations and inputs/outputs to perform the ongoing capture of kilowatt hours (kWhs) being unnecessarily consumed while maintaining the strictest environmental conditions. This tool optimizes operations by responding to inherent systems overdesign and capitalizing on non-peak conditions to identify reduction potentials, the system relies on integrated, proactive protocols, including the rotation of grouped loads identified and retained for kWh reduction. Correcting and capturing these building inefficiencies is one of the main principles in delivering high performance sustainable building operations. With this unique kWh harvesting, technique building operators will be able to achieve persistent real-time performance optimization. 
     In various embodiments, the software is configured to run on an IoT Gateway, such as Supermicro&#39;s Fanless SYS-E100-9 W-IA-E IoTGateway, to provide seamless integration with any existing Building Management System (BMS) on the market. The integrated platform provides operators of commercial buildings, hospitals, universities, and other facilities with the means to monitor their posture regarding any laws or regulations and to take a proactive approach to reduce emissions. Enterprises can comply with the strict greenhouse gas emissions laws and achieve significant cost savings through kWh Harvesting and demand control. The system&#39;s energy management solutions empowers users to intelligently manage their energy consumption, adjusting both the timing and the quantity of their electricity use in real-time, without degrading mission critical operations. 
     The application of the carbon footprint management platform and control software provides ownerships and property managers extraordinary capabilities absolutely necessary when addressing the complexity and financial impacts of mandated carbon footprint allowances whether legislated or corporate social mandate. 
     The system, at a keystroke, delivers these mandatory and crucial high-performance facility deliverables:
         At-Will Recognition of facility or portfolio Carbon Footprint Position   Immediate time-stamped consumption data and associated carbon footprint implications.   Projected Carbon Emissions at Year-End including multi-year historical baseline carbon profiling for facility operations evaluation.   Elimination of current practice labor-intensive data preparation and manual report preparation.   Real-world predictions base on application-proven forward-looking algorithms.   Provide programmed dynamic mitigation strategies.   Illustrate the impact of mitigation strategies formulated or employed.   Allow multi-facility comparison with aggregated performance matrix.   Provide the ability to partition discrete carbon footprint contributors such as processes or tenancies.   Delivers forecasting for anticipated below allowance carbon cap and trade market.   Eliminate the complexity of generating analysis and partitioning for multi-tenant building and penalty allocation for portfolio owners.       

     Technical Advantages
         Prediction Forward Looking Algorithm   Real Time Data   Illustrates impact of mitigation strategies formulated or employed   Allows complex multi-facility comparison with performance matrix   Allows cloud compilation and access   Provides for programmed dynamic mitigation strategies   Transition to capstone of true intelligent EMS   Capitalize on recalibration of operations during non-peak conditions   Optimize energy assets that are needlessly running 100% capacity 24/7   Enhance efficiencies of energy consuming load assets with additional controls   Taking advantage of seasonal and hourly weather variations   16 Controls scheme per building/campus   64 Buildings per campus   Unlimited number of campuses   For example, 400 energy monitoring meters per campus (can be increased with minimal additional programming)   Cloud computing       

     Commercial Advantages
         Eliminates labor-intensive data preparation   Automates definitive and descriptive reports needed for compliance submission   Ability to partition discrete contributors   Forecasting for anticipated carbon cap and trade market   Eliminates complexity of generating LL97 analysis for multi-tenant building and penalty allocation for portfolio owners   Substantial kWh and cost savings (carbon footprint reduction)       

     Key Benefits
         Quantify and assess building GHG emissions relative to legal limits in real time, and by sources of energy   Gain full transparency from the building level down to individual meter levels, across billing cycle, year and compliance periods   Calculate and forecast building penalties or surpluses across compliance periods   Identify high-energy-consumption meters/tenants for targeted reduction   Facilitate noncompliance gap closure scenarios   Enable carbon emissions reporting &amp; audit requirements   Maximize demand response revenue earnings capabilities   Improved risk management   Improved tracking and performance reporting   Reliable and durable industrial grade computer to ensure peak performance for mission critical deployments   Key Features: for example, 8 USB Ports, up to 4 GbE LAN, 3 M.2 Slots, up to64 GB DDR4 2400 MHz SODIMM, and dual displays. These listed features are merely exemplary. The system can have more or less components configured having various configurations depending on the industry.   Management computer, which is configured to manage, monitor and trouble shoot the software platform, can accommodate up to, for example, 8 monitor displays. The management computer can be a physical machine or a resource that resides within a cloud computing network. The one or more resources within various cloud-based services can be a plurality of different virtual machines and/or computing devices that are configured into clusters and/or reside in differing geographic locations.       

     Aspects of this disclosure may be implemented, in some embodiments, through a computer-executable program of instructions, such as program modules, generally referred to as software applications or application programs executed by any of a controller or the controller variations described herein. Software may include, in non-limiting examples, routines, programs, objects, components, and data structures that perform particular tasks or implement particular data types. The software may form an interface to allow a computer to react according to a source of input. The software may also cooperate with other code segments to initiate a variety of tasks in response to data received in conjunction with the source of the received data. The software may be stored on any of a variety of memory media, such as CD-ROM, DVD, magnetic disk (HDD and SSD), flash drive, bubble memory, and semiconductor memory (e.g., various types of USB flash drive). 
     Moreover, aspects of the present disclosure may be practiced with a variety of computer-system and computer-network configurations, including multiprocessor systems, microprocessor-based or programmable-consumer electronics, minicomputers, mainframe computers, and the like. For example, the present invention may be practiced on any Intel-based microprocessor computer system running on a Microsoft 32-bit/64-bit Windows Architecture. In addition, aspects of the present disclosure may be practiced in distributed-computing environments where tasks are performed by resident and remote-processing devices that are linked through a communications network. In a distributed-computing environment, program modules may be located in both local and remote computer-storage media including memory storage devices. Aspects of the present disclosure may therefore be implemented in connection with various hardware, software or a combination thereof, in a computer system or other processing system. 
     Any of the methods described herein may include machine readable instructions for execution by: (a) a processor, (b) a controller, and/or (c) any other suitable processing device. Any algorithm, software, control logic, protocol or method disclosed herein may be embodied as software stored on a tangible medium such as, for example, a flash memory, a CD-ROM, a floppy disk, a hard drive disk (HDD/SSD), a digital video disk (DVD), or other memory devices. The entire algorithm, control logic, protocol, or method, and/or parts thereof, may alternatively be executed by a device other than a controller and/or embodied in firmware or dedicated hardware in an available manner (e.g., implemented by an application specific integrated circuit (ASIC), a programmable logic device (PLD), a field programmable logic device (FPLD), discrete logic, etc.). Further, although specific algorithms are described with reference to flowcharts depicted herein, many other methods for implementing the example machine-readable instructions may alternatively be used. 
     Aspects of the present disclosure have been described in detail with reference to the illustrated embodiments; those skilled in the art will recognize, however, that many modifications may be made thereto without departing from the scope of the present disclosure. The present disclosure is not limited to the precise construction and compositions disclosed herein; any and all modifications, changes, and variations apparent from the foregoing descriptions are within the scope of the disclosure as defined by the appended claims. Moreover, the present concepts expressly include any and all combinations and sub-combinations of the preceding elements and features. 
     While the above detailed description has shown, described, and pointed out novel features as applied to various embodiments, it will be understood that various omissions, substitutions, and changes in the form and details of the devices or algorithms illustrated can be made without departing from the spirit of the disclosure. As will be recognized, certain embodiments described herein can be embodied within a form that does not provide all of the features and benefits set forth herein, as some features can be used or practiced separately from others. All changes that come within the meaning and range of equivalency of the claims are to be embraced within their scope.