A New Open-Source Protocol for Sharing Information on Proposed Energy Efficiency and Renewable Energy Projects

Transcription

1 A New Open-Source Protocol for Sharing Information on Proposed Energy Efficiency and Renewable Energy Projects Devan Johnson, Jim Kelsey, P.E. kw Engineering ABSTRACT Retrofits are a messy business where information must be passed among stakeholders, and communicating this information can slow projects. The authors propose a new open-source platform for information exchange that will make communication among stakeholders faster and easier. As experienced energy professionals understand, energy projects are an increasingly messy business: information of all types and levels of complexity must be gathered and processed from multiple sources, then seamlessly passed among various stakeholders. The current process of finding, documenting and communicating energy project information between multiple stakeholders delays project completion and may inhibit the full implementation of energy efficiency measures (EEMs). The authors are leading the effort to develop a new opensource platform for information exchange that will improve the speed and reliability of communications among stakeholders of integrated energy projects (IEP) and enhance the effectiveness of those projects. The concept is analogous to the development of HTML as the primary enabler of the Internet economy. HTML became the common platform that allowed for quick and effortless data exchange that then led to the emergence of the e-commerce industry. Similarly, quick, reliable and secure exchange of data for energy efficiency (EE) and renewable energy (RE) projects can minimize green clutter and enable the delivery of significantly more efficient and profitable EE and RE projects. The authors developed the IEP Model under funding from the California Solar Initiative (CSI) Research, Development, and Deployment (RD&D) Program: a new open data model based on an XML framework to share IEP information. The model focuses on the common data shared among stakeholders during the lifetime of a project including historical energy use, affected building and energy systems, customer data, proposed upgrades, energy costs and related products. The IEP XML schema documentation is publicly available for energy software developers to implement interoperability with other tools (kw 2012b). The intended users of tools implementing IEP are utility programs, rating programs (e.g. LEED), ESCOs, contractors, customers, and financing entities. Each of these stakeholders can use the model as a means for faster and more effective sharing and storing of relevant IEP data. The IEP Model development team demonstrated the potential for software integration of the IEP XML schemas though the initial implementation of two existing software tools. Software developers are encouraged to utilize the public data model to develop application programming interfaces, integrate additional software, and contribute to the evolution of the model itself. Through the broader adoption of a common data model by energy software developers the integration of energy software will become much more prevalent and the use of the software much more efficient

2 Need for a Common Format IEP Stakeholders An integrated energy project (IEP) can involve a wide range of stakeholders. Figure 1 provides a map of potential residential stakeholders of an integrated energy project. Typically we imagine an energy project occurring between a consumer and one or more energy service providers. The consumer on the one side may be a residential homeowner, commercial building owner, or property manager. On the other side, there are a wide range of energy service providers that may include contractors, energy auditors, inspectors, engineers, consultants, finance providers, marketers, and salespersons. In addition, there are other entities such as incentive program administrators and energy agencies that have some stake in an IEP. All of these IEP stakeholders have an interest in either providing or receiving information regarding projects. Unfortunately, too often those information exchanges are addressed in isolation. Figure 1. Map of Potential Residential Stakeholders for the Integrated Energy Project Model Source: kw Engineering, Inc The Currently Disjointed Provision of IEP Information The Internet contains copious amounts of information about how to save energy by implementing individual energy efficiency measures (EEMs) in residential, commercial, industrial and institutional facilities. However, there is a lack of cohesive resources for IEP stakeholders that facilitate the process of evaluating and implementing comprehensive energy solutions. This presents a significant market barrier to the identification and adoption of comprehensive retrofit and renewable energy projects. For example, a consumer can easily find information about sizing and installing solar power systems to generate renewable energy. However, a consumer has few available resources

3 to assist in defining complementary projects that reduce energy consumption (e.g. EEMs). Such resources include potential measure recommendations, qualified contractor identification, financial incentives availability, contracting and purchasing coordination, managing implementation, and post-project analysis review. The increased difficulty in finding reliable and valuable information for the evaluation, management and implementation of IEP often discourages otherwise interested consumers from pursuing these comprehensive projects. Energy service providers are currently adopting tools to automate their business processes to market, bid, contract, and manage projects in order to increase efficiency, reduce operational costs and increase sales. Software such as Clean Power Finance Tools (CPFT 2012), Home Energy Saver (HES 2012), and ENERGY STAR Portfolio Manager (ESPM 2012) are all gaining adoption and provide useful functionality. Unfortunately, there is a striking lack of a shared standard by which all of these tools and websites (for both consumers and energy service providers) can readily share mutually-beneficial information about customers, buildings, energy use, projects, products and services. The lack of a common data format for integrated energy project information means that data is not easily transferred between software tools. In many cases the project data cannot be transferred at all. The inability to transmit data between tools results in redundant data entry and even redundant efforts across multiple stakeholders, or even within one entity, involved with a single project or customer. As a result, customers must often iterate through multiple focused energy projects as opposed to implementing a comprehensive strategy that integrates related energy projects. Bridging the Gap To fulfill this need of standardizing IEP data manipulation, the authors created IEP XML: a common data format that integrates the building energy assessment and analysis process with the assessment, quoting and implementation of EE and RE projects. The goal of the initiative was to create an open format that enables all IEP stakeholders to easily collect, transmit and store information about integrated energy projects through various software tools utilized within the energy ecosystem. The project was funded by a grant from the California Solar Initiative (CSI) Research Development, Deployment, and Demonstration (RD&D) program (CSIRDD 2012). Initial Scope and Focus of IEP Model The CSI RD&D grant that funded the initial development of the IEP Model targeted lowering barriers to the near-term integration of EE and RE in the residential and small commercial retrofit market. The IEP Model RD&D project consisted of three phases: initial research, development of the data model, and a demonstration deployment of IEP XML in two existing web applications of our other team members. IEP Model Research. The team conducted initial research to identify the business process and software needs of solar installers and energy service providers. The team surveyed existing solar installers and energy service providers to determine any existing pain points in their business processes and what software they used, if any. Additional research investigated existing data models in the energy software space to avoid duplication of effort and support interoperability where sensible. Based on this research, the team identified a range of scenarios in which

4 software might interoperate and created an inventory of the required parameters. The team used this comprehensive inventory of parameters to organize and develop the IEP Model. IEP Data Model Deployment. Upon completion of the first public draft of the IEP Model in February 2011, the team proceeded to implement the first software integration using the IEP model. The initial integration took place in an online project management tool for solar contractors. An energy efficiency audit that provides EEMs to customers purchasing PV systems is a program requirement for participation in the California Solar Initiative Program. Thus, facilitating the delivery of EEM recommendations to consumers was an excellent opportunity to demonstrate IEP model deployment. The goal of this initial deployment was to make the process of recommending energy efficiency retrofits as easy as possible for potential PV system consumers. The purpose of the IEP XML integration with the project management tool was to add value and enhance functionality by providing an energy efficiency audit feature within the tool. In doing so, the desired end result was to encourage increased integration of EE with RE projects. How It Works The IEP Model introduces a common language for project stakeholders. It provides a comprehensive, standardized definition of data elements that comprise an integrated EE+RE project, as well as a channel for stakeholders to communicate about that project. Implementation of this common language in energy software tools can simplify and streamline the IEP process. This will reduce time and costs for energy service providers and consumers, produce better return-on-investment (ROI) for both, and remove a key market barrier for the adoption of integrated EE and RE projects. A Common Language The process of data exchange between software tools is a form of communication. In order to communicate effectively the involved parties first need to share and understand a common language. While there are many languages used for software communication, in the age of the Internet a particular form of programming language called extensible markup language (XML) has emerged as a standard. Over the past decade, software developers in significant number have adopted the use of XML for software interoperability. Most high-level program languages and platforms contain utilities and libraries that integrate and support the XML language form. What is XML? Extensible markup language (XML) is a markup language that defines a set of rules for encoding documents in a format that can be read by both humans and machines. The XML specification is an open standard produced by the World Wide Web Consortium (W3C). Although the design of XML focuses on documents, developers widely use XML to represent arbitrary data structures. As of 2012, there are hundreds of XML-based languages, including Home Performance XML (HPXML 2010) and Green Building XML (GBXML 2012). Most people use XML in their daily work, as XML-based formats are now the default for office-productivity tools, including Microsoft Office, OpenOffice.org, and Apple s iwork

5 A schema defines an XML-based language and is equivalent to grammar for that language. Schemas provide the constraints on the structure and content of the XML document. Several schema systems exist to aid in the definition of XML-based languages. One of these is called XML Schema, also known as XML Schema Definition (XSD), which was published as a W3C recommendation in An XSD can be used to express a set of rules to which an XML document must conform in order to be considered valid according to that schema. Learning to Speak the Language In order for software tools to communicate they must first learn to speak a common language. Typically an organization uses an existing software tool that stores its information in a defined data structure within a database. In the context of an XML-based language, this means that in order for communication between applications, the respective software developers must first map their applications existing data structures to the data structure of the XML-based language. Mapping Application Data to IEP XML. Typical existing applications that would benefit from IEP XML interoperability will contain both unique application data as well as common project data found in the IEP Model. The common IEP project data is what various stakeholders share during the lifecycle of an energy project. Thus, only the common data from an existing application must be mapped to IEP XML. Mapping the common portion of an application s data model to the IEP XML data structure facilitates the generation and consumption of IEP XML documents by an application. This is the first step toward software communication. Establishing Channels for Communication Once a software application learns the common IEP XML language by mapping its common data elements, it is time to establish channels for communication. In the world of software, the development of an application programming interface (API) accomplishes the task of enabling clear communication between different software systems. What is an API? An API is an interface that software components use to communicate with each other. It typically includes specifications for what data is required to execute routines or functions, and the data that will be returned. An API may specify its own data structures, object classes, and variables or reference external data structures that then facilitate communication between two or more different software systems. When used in the context of web applications, an API is typically defined as a set of Hypertext Transfer Protocol (HTTP) request and response messages, along with the structure definition of the messages, which are usually in an XML format. Request and response messages allow data to be transferred from user actions to the target web address. Web APIs allow the combination of multiple services into new applications. For example, the Google Maps API is commonly used to embed custom maps into web pages. Creating Web APIs based on IEP XML. By creating APIs using IEP XML we can develop an entire ecosystem of software applications that can communicate with one another and work

6 together to provide more comprehensive services, exchange IEP data efficiently, minimize errors and eliminate redundancy. Examples of IEP Model Data Exchange During the research phase of the IEP Model project, the team envisioned a number of scenarios in which IEP XML could be used for exchanging data. At the time, the focus was on application-to-application communication. The project s demonstration deployment of IEP XML implemented application-to-application communication between two different web applications. However, through the course of the project a number of other applications of IEP XML emerged. This included organization-to-organization and application-to-organization data exchange. In general, IEP XML documents can facilitate the data exchange scenarios shown in figure 2. They can be used to collect, transmit and store information about integrated energy projects by energy-related organizations and consumers through various software tools. Figure 2. IEP Model Data Exchange Scenarios Source: kw Engineering, Inc Application-to-Application Data Exchange Application Integration Energy service provider web applications can use IEP XML to extend their data analysis capabilities. They may do so by capturing project data in IEP XML and transmitting it to the

7 appropriate analysis tool specific to that project. This benefits the service providers by avoiding the redundancy of developing their own version of an existing tool. In addition, the ability to easily transmit project information allows service providers more choices in vendors. Since the project data may be easily transferred, they may choose products from multiple vendors to integrate with their implementation of the IEP model. Demonstration Deployment Application Integration. For the demonstration IEP XML deployment in the CSI RD&D project we integrated two web applications developed by project team members. One of these tools is an online residential EE survey tool developed by SaveEnergy123 (SE ). The other tool is an online solar project management tool developed by SolarNexus (SN 2012). The objective was to provide the SaveEnergy123 functionality to solar contractors using SolarNexus without requiring them to use a separate application. The IEP Model team modified the SolarNexus tool to allow solar contractors to input information about building energy loads such as lighting, appliances, and HVAC gathered during their site assessment. The solar contractor could then request a list of recommended EEMs. The SolarNexus tool submits a request to SaveEnergy123 consisting of IEP XML describing the building size, vintage, location, its historic energy usage, and existing energy loads. The SaveEnergy123 tool responds with IEP XML containing recommended EEMs, their estimated costs and benefits, and the overall expected impact on annual energy consumption. The solar contractor could filter the EEMs based on knowledge of their customer s facility. Ultimately the solar contractor could provide the EEM recommendations along with their PV proposal. Customers could then use SaveEnergy123 to request contractor quotes for implementing EEM recommendations. SolarNexus developers modified their tool to support the collection of building audit information, which the tool sends to the SaveEnergy123 tool when requesting recommendations. The modifications to SolarNexus included adding new fields to the data model and adding a new user interface. This allowed solar contractors to enter additional information for the development of proposals about building and energy loads that was not previously collected. The SaveEnergy123 programmers developed an API using IEP XML to support requests for energy efficiency recommendations from the SolarNexus tool. The API defines a method of requesting recommendations remotely by sending an HTTP request to a specific web address. The request contains an IEP XML body with prescribed data elements. SaveEnergy123 processes these requests and responds with IEP XML containing a set of recommendations. The API developed for the demonstration deployment not only allows SaveEnergy123 to provide services to the SolarNexus tool, but also enables it to provide services to any third-party application implementing an API based on IEP XML. This expands the usefulness of the SaveEnergy123 tool beyond those that use their web interface and allows tools such as SolarNexus to provide functionality that is not part of their core expertise. Additionally, since both tools have been modified to speak the common language of IEP XML the incremental effort required to integrate additional functionality from other tools is less than the initial effort. Organization-to-Organization Data Exchange Data Aggregation One of the additional uses of IEP XML identified in the course of the project was efficient data aggregation from multiple sources. IEP XML provides organizations with the

8 ability to maintain a project history for a single facility or portfolio of facilities. Since an organization may be involved in many different energy related projects in parallel or in series over a period of time, there is a need to track all of these projects in aggregate. If each of the many energy service providers working with an organization could deliver project information in a common format, then it would greatly simplify the tracking of those multiple projects. This allows building managers to quickly and easily communicate to necessary parties any relevant information (e.g. the currently installed equipment and appliance lists). Also, maintaining a list of multiple facilities and their respective energy projects is advantageous to larger firms dealing with a portfolio of facilities that are spread across multiple regions. Utilities can also use IEP XML to aggregate project tracking of multiple energy programs. By aggregating project tracking data, utilities may easily generate program tracking and status reports for all programs. Facility Manager Data Aggregation. The manager of a facility or a portfolio of facilities may utilize multiple energy service providers for such functions as building benchmarking, EEM recommendations, project financing, utility incentive application tracking, project implementation, commissioning, etc. When all of these energy service providers use different tools and formats to communicate, it puts a heavy burden on the facility manager to track all these activities in aggregate and support their successful completion to deliver intended results. If each of the energy service providers supported communication using a standard common format it would greatly alleviate the data-tracking burden on their customers. Incentive Program Data Aggregation. In California there are multiple investor owned utilities (IOUs) administrating incentive programs in their respective service territories. IOUs respective programs are often implemented by different organizations using different tools and processes. Each utility must report program project data to regulating energy agencies (e.g. the California Public Utility Commission: CPUC). The aggregation of project data from all these programs can require a significant amount of time and effort. Process efficiencies can be achieved by adoption of a common format with which to communicate project information from program administrators to regulators. For example, the California IOUs were directed by the CPUC to develop a statewideintegrated energy audit tool (CA-IEAT). The IOUs each selected a different vendor to develop the CA-IEAT for their respective service territories. The CPUC will certainly want to review the activity of each of these tools both individually and in aggregate. However, the initial requirements for the CA-ICEAT did not include a common reporting format. This means that the CPUC will either receive unique reporting from each of the IOUs vendors putting a burden of aggregating the data on the commission, or the utilities will be themselves required to carry the burden and convert reporting received by their respective vendors into a common format for reporting. By having each of the CA-ICEAT vendors implement a common project reporting format such as IEP XML, both the utilities and the commission will reduce their data aggregation burden. Aggregation of Field Collected Data. IEP XML also allows vendors to develop audit data collection tools that may be implemented on mobile devices such as tablets and smartphones. A team of auditors may visit a facility and collect relevant building data simultaneously. The data may be aggregated by a service provider and shared with involved parties. Firms may also

9 continue to process their discrete building information related to their project. At any given time, new data may be collected, processed, organized and shared. A pilot application supporting such field data collection aggregation using IEP XML was developed by the authors. Application-to-Organization Data Exchange Data Portability During the demonstration implementation of the CSI RD&D project, the project team identified the ability for IEP XML to provide data portability between applications even if an API does not integrate the applications. Data portability means that a user of a particular application can save and retain their energy project information to pass on to another organization or application in the future. Saving information locally and offline gives users of online energy service applications confidence and control of their project data. Users are assured that they have their current data even if the service provider goes out of business or suffers a loss of data. SolarNexus Project Export. In the initial phase of implementing IEP XML, the developers of SolarNexus mapped their internal application data to the IEP Model. In order to validate the mapping, the developers implemented an export function from their tool that saved all the data associated with a specific project to an IEP XML file. This file was then reviewed for completeness and validated against the IEP XML schema definitions to ensure that the mapping was successful. While this was initially done as a test to verify the accuracy of the mapping, the team quickly realized that it could be a useful feature for SolarNexus users. The SolarNexus developers added a function to their user interface that allowed their customers to save a project locally in IEP XML format. This provides their users with a sense of security that all the data they enter into the tool can be saved and securely stored locally. It also opens up the potential for their users to import this project data into another tool that supports IEP XML in the future if and when the need arises. Solmetric Software File Format. During the research project, the IEP model team engaged Solmetric to contribute the solar PV portion of the data model. Solmetric develops a PV design tool and a shading analysis tool that are very popular in the solar industry (Solmetric is a recognized industry leader, particularly in shading analysis). Both of these Solmetric tools take advantage of XML as a file format, so much of their XML data structure is already easily incorporated in IEP XML. The result is Solmetric tool files are IEP XML compliant and easily consumed by other applications that understand IEP XML. For example, the Solmetric SunEye shading analysis tool measures solar resource availability. It saves the measured data in an XML file on the user s computer when imported from the SunEye device. The structure of the SunEye s XML file containing the shading analysis results is the same as the structure of shading information in IEP XML. This means any application implementing IEP XML could be modified to import Solmetric SunEye shading data files electronically. This cross-application common data format saves users from manually entering the shading analysis data, thus reducing the possibilities of transcription errors and dramatically speeding up the process and reducing costs

10 Conclusions Software developers are encouraged to integrate additional software using APIs that leverage the IEP XML schemas and contribute lessons learned from those integrations into the further development of the model itself. By using a common data model for multiple software integrations the process of integrating with additional tools will be much simpler than using a separate data model for each integration. The more tools that use the common model the more integration options will exist for those who implement it, which in turn should encourage even broader adoption of the common data model. Current Status The IEP XML specification is publicly available for free use and open to extension by interested parties. The project website hosts the documentation and IEP XSDs (kw 2012a). This website also serves as the hub for stakeholders to comment and contribute to the evolution of the IEP XML specification. The authors published version 1.1 of the IEP XML specification in March This was the third public iteration of the specification and incorporates all of the lessons learned from the demonstration deployment between SolarNexus and SaveEnergy123 in the CSI RD&D project. Each of the research project team members identified additional implementations of IEP XML in their existing or future planned software tools. Further developments to the specification and public iterations will likely result from these efforts. As the original authors of the specification, kw Engineering, Inc. plans to oversee further development of the specification in collaboration with all interested industry stakeholders. In the future, the IEP XML standard may be contributed to a larger standards development organization when the appropriate entity is identified. References [CPFT] Clean Power Finance Tools San Francisco, Calif.: Clean Power Finance. [CSIRDD] California Solar Initiative Research, Development, and Deployment Program Integrated Energy Project Model. Projects/solicitation1-kw-engineering.html.: California Solar Initiative Research, Development, and Deployment Program. [ESPM] ENERGY STAR Portfolio Manager cfm?c=evaluate_performance.bus_portfoliomanager. Washington, D.C.: U.S. Environmental Protection Agency. [GBXML] Green Building XML San Rafael, Calif.: The Open Green Building XML Schema, Inc. [HES] Home Energy Saver pro Berkeley, Calif.: Environmental Energy Technologies Division, Lawrence Berkeley National Laboratory

11 [HPXML] Home Performance XML Malta, N.Y.: Building Performance Institute, Inc. [kw] kw Engineering, Inc. 2012a. Integrated Energy Project Model. Oakland, Calif.: kw Engineering, Inc. [kw] kw Engineering, Inc. 2012b. Integrated Energy Project (IEP) XML Schema Documentation Version IEPXML_v1_1_1.pdf. Oakland, Calif.: kw Engineering, Inc. [SE123] SaveEnergy Auburn, Calif.: SaveEnergy123. [SN] SolarNexus, Inc Berkeley, Calif.: SolarNexus, Inc