For utility customers, distributed photovoltaic (PV) systems provide the means to help defer the need to build additional peak generation, transmission and distribution infrastructure. However, installing a PV system is only one of a number of options available to these customers. Energy efficiency (EE) measures often provide the most cost-effective means for addressing electricity use within a home or business. In addition, a judicious mix of energy efficiency measures not only reduces electricity demand but also helps reduce the size and, therefore, the required capital outlay for PV systems. Unfortunately there are few PV installers that are qualified to provide energy efficiency audits and recommend and install appropriate efficiency measures. In general these services are provided separately leaving customers to make their own decisions about the best mix of EE and PV and usually need to employ separate service firms to implement their choices. Additionally, this separation of services often results in duplicate effort by service providers and creates a market barrier to integrated EE and PV projects.

The California Public Utilities Commission (CPUC) has identified a need to address this critical gap in the ability of the current market to provide combined EE audit/measure implementation and PV installation services for the residential and small commercial sectors. The CPUC has provided a California Solar Initiative (CSI) grant for the research, development and deployment (RD&D) of projects that will help to build a sustainable and self-supporting industry for customer-sited solar in California.

The Integrated Energy Project (IEP) Model team has received grant under the CSI RD&D program to develop and deploy a standard data model for interchange of integrated energy project information between EE and PV service providers.

Approach to Model Specification Development

The IEP Model team has developed a draft of the specification that is intended to be implemented by a number of the team member firms in the deployment stage of our grant funded project. With an aim to create a solid data model and avoid future interoperability problems, the team has gathered a number of experts in various parts of the overall energy project domain to review draft specifications and provide feedback. Given the tight time frame of the CSI RD&D grant, draft specification review cycles will be relatively short. The intent is to incorporate the collective expertise of the industry with individuals focusing on those areas where they perceive the most benefit or have the most experience. The deployment of an integrated energy project model and assessment of its impact on the industry is a key goal in this project. While the development of up-front consensus on the data model would be ideal, the deployment of the model in some form is critical to demonstrating its value in the market. The model specification development will continue in parallel to deployment of initial drafts by the project team.

Document Purpose

The purpose of this document is to provide a high level overview of the design decisions going into the IEP Model specification, general descriptions of the schemas and their organization as well as examples of the IEP XML to support the XML schema documentation.

In the assessment of use-cases for the IEP Model, the team identified many cases that will only involve a portion of the overall data model. To avoid the requirement that implementations incorporate the entire data model, the team separated the IEP Modelinto a multiple schemas that include and reference each other as necessary. This allows for the use of only the appropriate schema or schemas by each particular implementation.

Project

The Project schema consists of all elements utilized to describe the energy project. This schema describes the project using supporting elements. Such elements include Participant, Site, Measure, ScopeOfWork, ExistingLighting, ExisitingHVAC, etc.

Participant

The Participant schema describes any party involved in an energy project. This schema includes the Participant element and other supporting elements. The Participant schema captures an entity’s contact information, role, and any additional specific information. Possible roles may include, but not limited to consumer, service provider, contractor and energy auditor.

Site

The Site element describes the property on which the project is being considered or implemented. It describes ownership and jurisdictional information, as well as physical attributes. It inlcudes elements describing both buildings and grounds. The Site element is particularly useful for capturing site audit data prior to defining specific measures, including relevant data about locations for where proposed energy system equipment can be placed.

Building

The Building schema utilizes many elements to describe all aspects of a building. The Building element and supporting Envelope elements describe the building characteristics. Possible depicted building characteristics include age, building use, number and age of occupants, energy systems, and detailed shell information.

Measure

MeasureType describes an energy improvement recommendation for a project. The recommendations involve modifications to energy systems or building envelopes. A measure consists of a measure action that describes the type of improvement such as the addition, modification, removal or replacement of existing energy equipment e.g. the addition of a PV system, or replacement of an existing HVAC system with a higher efficiency model. The measure also contains the cost and benefit information as estimated by the participant recommending the measure.

Common Schemas

Common: The purpose of this schema is to define a set of types and quantities that are frequently used by other schema and can be referenced in a consistent manner. Each object is a ComplexType that includes a Value attribute and a Units attribute, which refers to an associated enumeration of units of measurement.

CommonElectrical: This schema defines the common attributes used by electrical systems.

CommonSystemProperties: This schema defines the common attributes used by all systems.

Appliance

This energy system schema contains the Appliance element, which is used to describe appliances and other plug loads (a generic device or system that draws electricity from a wall outlet). Generally, the Appliance element is to be used to represent any energy consuming system that one would like to be included in an energy analysis that is not captured by one of the other four Energy Systems (Lighting, Distribution, HVAC and Water Heating). The Project schema utilizes an element called ExistingAppliance of the ApplianceType to describe the original appliance intended to be changed in a project.

Distribution System

This schema contains the DistributionSystem element and other supporting elements that describe a mechanical system for transporting water or air. This mechanical system includes pipes or ducts, which transport the medium and a prime mover (fan or pump) that drives the medium. This system is commonly instanced by HVACSystem and WaterHeatingSystem, though it may be instanced on its own. For example, if an HVAC system conditions a zone by blowing conditioned air into the zone, it may instance a DistributionSystem, which defines the supply and return ductwork.

HVAC System

This schema contains the HVACSystem element, which describes a heating ventilation and air conditioning (HVAC) system. The HVACSystem element includes a CoolingSystemType and HeatingSystemType named CoolingSystem and HeatingSystem respectively. CoolingSystem and HeatingSystem describe the operation, capacity and energy consumption of the cooling and heating systems.

The HVACSystem element references the ID in DeliverySystem of the distribution system it uses to condition the zone. A distribution system may be defined to describe a pump or fan and piping or ducting if these are desired for the model. This distribution system is one that the HVACSystem uses to condition a zone, not one that serves the HVACSystem (i.e. a heat source or sink for the HVACSystem, such as a condenser water loop or water source for a heat pump). Note that no more than one distribution system may be defined for each HVAC system. Therefore, if a building has a hydronic radiant coil heating system and an air-to-air heat-pump cooling system, two HVAC systems must be defined.

Water Heating System

This schema contains the WaterHeatingSystem element, which describes a boiler or water heater. The end use may be HVAC, domestic hot water or another. The element contains properties to describe the tank volume (zero if none/instantaneous) and insulation, the temperature setpoint (type schedule), solar heater attributes and other typical water heater nameplate and manufacturer specification information. The WaterHeatingSystem element also references a DistributionSystem ID which may be defined to describe a pump and hot water piping.

Lighting System

This schema contains the LightingSystem element, which describes one light fixture or a collection of light fixtures. LightingSystem contains complexTypes to describe the input and output (power) of individual fixtures contained found in SystemProperties, the illuminated area and light level located in LightingZones, the control type found in LightingControlGroup, and the lamps and the ballasts defined in LightingFixture.

PV System

The PVSystem schema contains different types to describe a PV system from basic to complex levels of detail.

The PVSystemBasic type communicates a very basic and generic system description and operational assumptions. It is commonly used for running simple performance simulations or cost estimations. It does not include any specific component specifications.

Additional complex types in PVSystem capture:

Detailed property descriptions of specific module and inverter makes and models used in the design

Description of planes (roof surfaces and or mounting structures) on which arrays can be mounted

A means for describing the wiring connections made between system components

A means for describing the method for interconnecting the AC side of an inverter to the existing utility system (to be included at a later date)

A variety of means for describing shade affecting the system (Shading.xsd)

Ability to spatially define the system's components in 3 dimensional space relative to a defined origin

In general, IEP XML documents will be used to transmit information about integrated energy projects between software tools used by service providers and consumers. While it is expected that there will be a wide variety of data exchange that this model will help facilitate, a number of use cases will actually be implemented and deployed as part of the grant project. The following use cases are expected to be implemented by project team firms SolarNexus and SaveEnergy123 (SE123).

Contractor Receives Bid Request

In this use case, a consumer has a project or projects in mind that they would like to receive bids on. SaveEnergy123(SE123) has collected a proposed project from the consumer and will pass the project information on to SolarNexus(SN) in order to allow the Contractor to use the SolarNexus tools to access the project and provide a bid back to the consumer. This use case focuses on the transfer of data from SE123 to SN. For example a consumer has provided SE123 with consumption and building profile data for their home, including gas and electrical consumption in dollars and Therms and/or kWh. The consumer provides building profile data would include such data as the square footage of the home, it's age, insulation levels and HVAC equipment info. SE123 uses this information to suggest Measures to the Consumer which might include adding Solar PV to their home as well as various Energy Efficiency Measures such as sealing their Envelope.

The Consumer chooses a couple of these projects such as an insulated roof and a SolarPV installation. The Consumer sends out bid requests to contractors, one of whom is a registered SolarNexus contractor. Once the contractor has accepted a bid request via SE123, the Contractor can request that the Project info be transfered to SN. SE123 would then load up the Project schema with the various components of the Consumers project including a Scope of Work(includes multiple Measures - i.e., SolarPV Measure and Insulated Roof Measure) Building info (including Profile data, Energy Consumption, Roof info, etc.), Participant (Consumer contact info) and Site data. This data would then be passed to the contractor at SN for assessment.

Other related use cases could include the processing of the Contractor registration between SE123 and SN and later SN sending updated proposed Measures to SE123 - i,e, Solar PV and Insulated Roof Proposal.

Contractor Gets Third-party Project Opportunity Analysis

SaveEnergy123 (and other online services) provide online energy auditing tools for the Consumer. The Consumer can use these to compare and contract different measures to be implemented in their home. These same tools can be used by contractors to assess a home owner's energy usage and desired projects and provide feedback through updated and other proposed measures.

For instance a contractor may be proposing a new solar installation and needs to show the customer alternative energy measures in order to obtain federal, state or local rebates for the project. The contractor can provide the Building profile and Energy Consumption information to SE123 in order to obtain an online Energy Audit and potential alternative Measures to present to the Consumer.

Another usage may include collecting additional information about a requested project and providing alternative measures to the Consumer. This may be based on additional information that the contractor may have collected that significantly impacts the energy analysis. This provides Contractors the ability to use the knowledge Consumers may have already obtained to propose the proper solutions for them.

Request/Receive Site Audit

This use case presents the case where a contractor needs to share Project, Building and Consumer(Participant) data with other Contractors(Participant) Here again a project may require a Home Energy Audit in order to obtain the Federal, State or Local rebates. This transfer of information via the IEP XML will allow the Contractor and Auditor to not only save time by not filling out multiple documents with the same information but also remove or reduce the number of errors inherent in data transfer via voice and/or paper.

Lookup and Validate Provider Credentials

Multiple categories of market actors (i.e., potential software and/or website end users) have unmet credential validation related needs that IEP-Model-compliant tools may be able to help to address. This use case describes the automatic validation of participant credentials.

Short Description:

• Just-in-time or scheduled batch process to query a cvXML-compliant Training Standard Provider’s Credential Validation web service and return a structured dataset of individuals, credentials, dates and related data.

Design PV System

This use case provides an example where the Project data is most likely contained in a central database and this data is required in order to properly assess/design a new PVSystem. The IEP XML can be by the design tools to access the data from the database without requiring the Contractor to manually enter the data. This updated analysis data can then be stored in the database and accessed by other applications for cost quotation, financial analysis, etc.

Version	Date	Author	Comments
0.01	11/1/2010	Devan Johnson	Initial Draft of Introduction and Use Cases
0.02	11/3/2010	Devan Johnson	Moved Schema Organization into new Data Model section and included brief descriptions of each schema and diagrams of key elements and links to online schema documentation.
0.03	11/4/2010	Devan Johnson	Incorporate team review comments.
0.1	11/11/2010	Devan Johnson	Add use case descriptions
0.1.1	12/2/2010	Devan Johnson	Added PV Related Schema documentation and Credential Validation use case. Removed table formatting and Oxygen schema images
0.1.2	12/3/2010	Adrian Townsend	Additional documentation on Energy Systems
0.2	1/19/2011	Kris Johnson	Expanded descriptions of High Level and Supporting Schemas and cleaned out links to XML docs
0.3	2/4/2011	Kris Johnson	Updated documentation to reflect the name change from ConduitSegment to DistributionSegment in DistributionSystem, movement of Measure from ScopeOfWork to Project, references to Zone.
0.4	2/28/2011	Kris Johnson	Updated documentation to reflect changes to Site, the name change from DistributionSegment to Segment, general organziation of overall document, section addition for schema project hierachy, and added descriptions for Zone, ElectricalDistributionPanel, PVInverterDefinition, PVModuleDefinition, and Shading schemas.
1.0	10/31/2011	Kris Johnson	Updated documentation to reflect significant development of model. Additional documentation with sample XML codes will be added in future iterations.