Printer Friendly

Common data definitions for HVAC&R industry applications.


During the life-cycle of a building, from concept through design and construction and finally to operation, many software programs are used by various specialists including architects, engineers, construction managers, consultants, commissioning experts, and building operators. These software programs include CAD (computer aided design), HVAC load calculation, energy simulation, energy code compliance, project management, data acquisition, operations, and many others, and usually include a description of the building and its contents, including the HVAC&R and other systems. Unfortunately, perhaps due to the splintered nature of the building industry, these software programs use incompatible data formats so the information about the building and its systems is often re-interpreted and re-entered each time. Building Information Modeling (BIM) is one effort to help solve this problem by adding object-orientation to the traditional CAD design process. Another effort is ASHRAE's Guideline 20 XML Definitions for HVAC&R (ASHRAE 2008a). To aid the development of Guideline 20, ASHRAE Technical Committee 1.5, Computer Applications, developed and managed ASHRAE Research Project 1354-RP, to help create common data definitions for HVAC&R industry applications. This paper describes the results of that project.

This research project was in large part designed to develop a process for systematically elaborating Use Cases for HVAC&R activities to the stage of identifying detailed data requirements for supporting data exchange, and then assessing coverage of these requirements in existing data models. The primary outcome of the project should therefore be viewed as the process described in this paper. The specifics of the data requirements (i.e., Data Groups and Data Elements), and the assessment of their coverage in existing data models, should be viewed as preliminary results of an initial pass through this process. Additional iterations through this process will likely modify and further refine these preliminary results. Lessons learned through performing this project will be incorporated in the Guideline 20 document to support future process iterations.

The Purpose of Guideline 20 is "to establish a common data exchange format for the description of commodity data and HVAC&R information via the standard XML (eXtensible Markup Language) formatting language."

Just a few words but the implications are significant. The phrase "common data exchange format" is a data model for an industry, the focus of the research. The term "establish" implies that the Guideline Project Committee cannot simply create a model that gets put on a shelf and used only rarely. Instead, the Guideline Project Committee will attempt to succeed where other organizations have so far failed, based on an understanding of what the HVAC&R industry wants and needs. The phrase "commodity data and HVAC&R information" apparently limits the guideline to the data and information of mass-produced items but this is not a significant limitation since the construction industry relies on commodity products. The use of the terms "data" and "information" provide a very broad scope that could conceivably include any detail about any HVAC&R item. Clearly, the purpose was crafted to be a broad statement of the ultimate goal, and since the Guideline is destined for continuous maintenance, it is clear that the Guideline Project Committee expects multiple versions, each adding breadth and depth.

More understanding of what Guideline 20 is about can be found in its Scope. "Data types would include catalog definitions in areas such as, but not limited to, chillers, air-handling units, fans, pumps, fittings, controls, as well as analytical or operations, building performance data."

Most of this enumerates some of the "commodity" items from the Purpose with specific examples such as chillers. Including "catalog definitions" states that using this new data exchange format, manufacturers will be able to provide the same information that they put into their catalogs in a format that attaches meaning to data items.

ASHRAE has a long history of providing common definitions for terms used in the HVAC industry. The definitions to date have been provided in the form of written documents such as:

* ASHRAE Terminology of HVAC&R (ASHRAE 1991)

* ASHRAE Handbook Series

* Development of draft Standard 166 Heating, Ventilating, Air-Conditioning and Refrigeration Terminology (ASHRAE 2008b)

* Guidelines and Standards--almost all have a section titled "Definitions"

These sources have fulfilled the need in the industry to allow for effective communication between people. Without them, communication between professionals may have broken down as each party confused terms used by another. In a technical area such as HVAC&R design and operation, specific definitions are crucial so that confusion and errors can be avoided.

With the increased use of email attachments and web based project management systems, the value of defining terms can be brought to the next level. While software has been widely embraced by almost all participants in the design, construction, and operation of buildings, the exchange of data electronically has been restricted to dominant proprietary formats such as CAD drawings, spreadsheets, and word processor textual descriptions. These current common file formats lack any meaning behind a line or a figure or a phrase that another software program could use. By being generic tools, they lack any direct mapping of data to physical phenomena relying instead on the document explaining the data itself. When the next step occurs in the design, construction or operation of the building, even if the person has access to these files, the person is faced with the laborious process of re-interpreting information into the next software application. Reducing errors during the process could save the industry significant money and is often a reason cited for the value of adopting a common building data model. ASHRAE Guideline 20 will create a set of XML definitions for the industry to be adopted into a data model. This is one of the first steps in software-to-software information transfer that does not include the intermediate step of human interpretation. To do this, specific technical definitions need to be crafted.

The working draft of Guideline 20 is focused not on definitions, but on the process of developing definitions. The Utilization section of the draft states:
   Guideline 20 provides information on the development, dissemination,
   and application of standardized XML definitions (schemas) for
   HVAC-related equipment and systems. The ultimate utilization of the
   resulting XML definitions is the automated exchange of data in
   electronic format in support of HVAC-related activities and
   services. A systematic, coordinated development approach is required
   to achieve this goal. To this end, Guideline 20 begins by defining
   the process for developing an XML definition capable of supporting a
   desired HVAC-related activity. In addition, a process is defined for
   coordinating multiple XML definitions in order to minimize conflicts
   between them. Lastly, an annex to Guideline 20 documents the product
   of this process, an evolving set of commonly accepted XML
   definitions that can be implemented in software to support
   interoperable data exchange.

The working draft of Guideline 20 states that an annex will contain the actual definitions and data model. One purpose of the 1354-RP project was to begin the population of such an annex in an organized and thoughtful way such that it can continue to be extended into the future.

The objective of the ASHRAE 1354 research project was described as:
   The objective of this research is to assemble information supporting
   development of interoperability among software applications used at
   all stages of the HVAC&R project life-cycle. Based on comparison and
   analysis of existing data models and the GPC-20P Use Cases, the
   research will identify, characterize, and document:

* Core data items: generally required items defined similarly in multiple data models;

* Extension data items: items suggested by Use Cases but not well represented in existing models;

* Conflicting/problem items: items that are addressed inconsistently in existing models; and

* Mappings among existing data models: information supporting translation among existing models.

This information will be presented in tabular and text form for use in the development of Guideline 20P, other standards or guidelines, and software applications.

A secondary objective is to produce a demonstration implementation of automated inter-model data exchange.


The eXtensible Markup Language (XML) is a metaformat that can be used to create almost any file format imaginable. Based on the World Wide Web Consortium (W3C), a group that writes technical standards for the Internet:
   Extensible Markup Language, abbreviated XML, describes a class of
   data objects called XML documents and partially describes the
   behavior of computer programs which process them. XML is an
   application profile or restricted form of SGML, the Standard
   Generalized Markup Language [ISO 8879]. By construction, XML
   documents are conforming SGML documents. XML documents are made up
   of storage units called entities, which contain either parsed or
   unparsed data. Parsed data is made up of characters, some of which
   form character data, and some of which form markup. Markup encodes a
   description of the document's storage layout and logical structure.
   XML provides a mechanism to impose constraints on the storage layout
   and logical structure. (W3C 2004)

It has become the most commonly used format to base other data file formats and data exchange formats on. Literally hundreds of specifications based on XML exist. A few that demonstrate its wide range of appeal are listed below:

* RSS -- RDF Site Summary or Really Simple Syndication

* SVG -- Scalable Vector Graphics

* MathML -- Mathematical Markup Language

* UBL -- Universal Business Language

* ebXML - Electronic Business using eXtensible Markup Language

* LandXML -- For land surveying and development

One of the reasons that it has been so widely adopted, and why this project will benefit from its use is because of its design philosophy involving the following ten points (W3C 2004):

1. XML shall be straightforwardly usable over the Internet.

2. XML shall support a wide variety of applications.

3. XML shall be compatible with SGML.

4. It shall be easy to write programs which process XML documents.

5. The number of optional features in XML is to be kept to the absolute minimum, ideally zero.

6. XML documents should be human-legible and reasonably clear.

7. The XML design should be prepared quickly.

8. The design of XML shall be formal and concise.

9. XML documents shall be easy to create.

10. Terseness in XML markup is of minimal importance.

ASHRAE's decision to use XML as part of a guideline of HVAC&R definitions makes sense since it is technically appropriate and also because the format is being used by so many other industries.

The XML format is a hierarchical format made of elements containing values including other elements. Each element is identified by a tag of the name of the element followed by the value followed by another tag with the name of the element preceded by a slash. Each element can also contain attributes which are a pairing of attribute name and value separated by an equals sign. For XML, unlike HTML, attributes are best left to identification and unit identification purposes only. Other values should be shown as Data Elements. For example:
<chiller id="Chlr-1">
   <capacity units="tons"> 100 </capacity>
   <minimumLeavingTemperature units="F">40</
   minimumLeavingTemperature >

This format is incredibly flexible and allows any structured and many semi-structured types of information to be presented. The key to interoperability is to agree on what each tag name means and the format of the values. That is essentially what the research was about--to describe the tag names and define what they mean. For some Data Elements, the value is limited to one of a list of possible values, such as "absorption" in the example above. Defining these lists (usually called enumerated lists due to their software origin) is also critical.

The XML format is often described as a tree structure due to its hierarchical arrangement of elements. The tree structure is well understood by people and is often employed when complexity needs to be managed (the hierarchy in government, yellow pages, libraries) and it is equally well suited in the software development environment. For software, a hierarchical structure is easy to traverse and to manipulate since each tree is made up of subtrees, which can each be treated as a tree in a recursive algorithm.

Use Cases

According to Writing Effective Use Cases (Cockburn 2000):
   A use case captures a contract between the stakeholders of a system
   about its behavior. The use case describes the system's behavior
   under various conditions as it responds to a request from one of the
   stakeholders, called the primary actor. The primary actor initiates
   an interaction with the system to accomplish some goal. The system
   responds, protecting the interests of all the stakeholders.
   Different sequences of behavior, or scenarios, can unfold, depending
   on the particular requests made and conditions surrounding the
   requests. The use case collects together those different scenarios.

While a Use Case is not a methodology, it is a useful tool for creating requirements documentation for software development, user interface design, communication protocols, and data formats such as ones based on XML. Use Cases are a form of expressing the intent of how users will use a system. By formally stating the participants (actors) and what information flows (transfers) in a textual description, an understanding of what the system needs to accomplish is formed and can be communicated. Another perspective on Use Cases is to form user stories describing how a user would use a system. Use cases often have a semi-formal structure with lists of items or running text in a grouping of fields. Each Use Case has an actor with a goal and other actors that get assigned responsibilities in the process of meeting the goal. Some good descriptions of Use Cases may be found in Writing Effective Use Cases (Cockburn 2000) and in Structuring Use Cases with Goals (Cockburn 1997). A single Use Case usually does not adequately explore the use of a system and instead multiple Use Cases are created. In the case of Guideline 20 where the system is the information flowing during the design, construction and operations of a building, clearly many Use Cases are necessary.


Guideline 20 consists of many sections describing the process of using Use Cases to derive the Data Elements needed for HVAC&R. Four Use Cases were selected for analysis from the draft of Guideline 20:

* ENG-01: Calculate Building Thermal Loads

* ENG-03: Select Equipment

* COM-02: Collect Functional Test Data

* OM-01: Monitor Performance

For each Use Case, a short description is shown in the draft Guideline. For example the following description is from ENG-03: Select Equipment:
   The equipment selection process first requires determination of the
   system configuration and then choosing specific HVAC devices and
   components to perform the functions required in the configuration.

   Design requirements, building size, available budget, regional
   practice, available fuels, designer preference, and owner
   preference are among the factors used in determination of the HVAC
   system type for a given project.

   Once the configuration is known, design loads are used to determine
   the nominal size for system components. Actual components are then
   selected by finding the "best" match from a potentially large set of
   units available on the market. The basic selection rules are simple
   (the component must be "big enough"). However, in general there are
   complex constraints; finding satisfactory components involves
   balancing a number of factors such as cost, physical shape,
   non-optimal capacity, and off-design performance.

   The component selection process could be fully automatic, where
   software driven by designer preferences determines the selected
   unit. Alternatively, a semi-automatic process could be useful, in
   which software identifies several satisfactory candidates and final
   selection is made by designer judgment.

The description, along with a brief list of transfers, was the basis for a table of detailed process steps that was created. In addition, research for each of the Use Cases along with professional experience was used to create the detailed steps. For example, in the ENG-03 Use Case, two of the 22 process steps are shown below as an example:

* Mechanical Engineer reports list of selected components to Architect and Structural Engineer including physical size, weight, and exact location in building.

* Mechanical Engineer reports power requirements and control requirements to Electrical Engineer.

These steps along with others were used to create a table (not included in this paper) with 20 different transfers between the primary actor, usually the mechanical engineer, and other actors such as the architect, owner, structural engineer, electrical engineer, and equipment suppliers. The table format is described in the Guideline 20 draft. Each line of the table describes part of the process by highlighting the transfer of information between parties, called actors in Use Case parlance. The columns of the table include:

* Step -- the step number

* Primary Actor -- the party performing the majority of the task or chiefly responsible

* Actor that is the Source of Data -- the party providing the data

* Actor that is the Destination of Data -- the party receiving the data

* Data Groups -- the information exchanged described at a level of a named group of Data Elements

* Comments -- details that do not fit into other columns

Since the ultimate goal for this process is an identification of Data Groups, the information transferred during each step of the process is most important. All of the details from the process steps do not end up being represented in the detailed transfer table. Those portions of the process steps that were poorly represented in the detailed transfer table were identified. The poorly represented portions often include verbs and modifying phrases that help explain the process steps but are not needed in identifying Data Groups. For the two process steps identified above for ENG-03, the two transfers identified were:

* List of selected components including physical size, weight, and exact location in building

* Power requirements and control requirements

These transfers will serve as the basis for creating Data Groups. The same process of going from a textual description to a list of process steps to a table of data transfers was repeated for each of the four selected Use Cases. For some of the Use Cases, process steps that were not within the scope of the Use Case were included because they identified the source of data used within the Use Case. The lists of actors as well as the Data Groups are useful for elaborating the Use Cases in the Guideline 20 draft. The process steps and detailed transfer table are too large to include in this paper but are available in the final report.

During review of the process, it was clear that each person examining a Use Case is likely to interpret it differently and create different process steps and detailed transfer table entries. This subjectivity is not unexpected and underscores the importance of development of Data Groups in a collaborative environment. Interpretation of a Use Case to create a list of transactions and ultimately Data Groups and Data Elements can vary considerably by individual. The process steps and detailed transfers created during the project were one interpretation that may need further refinement.

These Use Case elaborations are meant to be used for analytical purposes, not as reference definitive examples of how to perform a service or exchange. The purpose was to expose common data groupings that might be used in exchanges from the perspective of a small group of domain experts. The key goal is the documenting of potential standard data groupings, as opposed to standardization of applications that use them.


While the end result of analyzing the Use Cases was an identification of Data Groups, those Data Groups lacked the clarity and specificity needed for being the basis for groups of Data Elements. To further refine and ultimately define the Data Groups was the next stage of the process.

Preliminary Data Group Selection

The first step is to refine the Data Groups identified in the analysis of the Use Cases and see how they match the existing Data Groups identified in the draft of Guideline 20. The draft Guideline includes two lists of Data Groups "Main Use Case Common Data Groupings" and "Common Data Groupings." In addition, neither list matched the terms used in the Use Cases from that draft. The first step was to examine these different lists and make a single unified list of Data Groups that had the following criteria:

* Unique to HVAC&R domain

* Understandable by building professionals

* Not in architectural domain

* Not in business domain

* Non-redundant

* Similar level of detail

* Specific

* Not elements

* Definable

* Non-abstract

* Physical, when possible

* Not defined only as an aggregation of elements

* Not parents to other Data Groups on list

* Mainly consists of Data Elements or non-domain specific Data Groups.

These criteria are subjective and, at times, redundant. If Guideline 20P were to adopt such a list of criteria for Data Group filtering, greater care would need to be applied to make a list that could be more consistently evaluated by anyone. For this research, a single individual consistently applied the list of criteria to filter out Data Group names that were not critical to the project.

It was important to focus on the Data Groups that are within the scope of the HVAC&R domain since many architectural and management items are not unique to that domain. Since the ultimate audiences are those in the building design, support and operation fields, these Data Groups should be readily understood by that audience. The architectural and business domains and the HVAC&R domain have significant overlaps and those areas of overlap are being excluded since they are already well described in other data models. In addition, they are not the prime areas where ASHRAE is uniquely positioned to contribute. Items that do not meet these criteria were either eliminated or replaced by more granular Data Groups. While Data Groups may naturally fall into a hierarchy, creating a hierarchy was not the purpose of the project, so groups that are simply parents of other Data Groups were not included.

For example, the item "Climatic Design Conditions Library" was eliminated because it is simply a collection of "Climatic Design Conditions" which also appeared in the list. Another item, "Occupant Thermal Comfort Conditions for various Space Types" is very similar to "Occupant Thermal Comfort Conditions," so it also was eliminated from further analysis. The analysis joined some Data Groups together and split others into smaller scopes. The names of the Data Groups were refined to reflect the scope of the Data Group but be as succinct as possible. Many Data Groups were eliminated for not being specific to the HVAC&R domain.

As a further example, from the ENG-01 Use Case process listing and transaction table, the Data Group "Building Description: Surface Geometry, Surface Properties (material layers and thermal properties)" was derived. This corresponded to three Data Groups from the Main Use Case Data Groupings of the draft Guideline 20: BuildingDesign.Geometry, BuildingDesign.MaterialProperties, and BuildingDesign. ThermalProperties. These were then described as Surface Geometry, Surface Material Layers, and Surface Material Thermal Properties. Surface Geometry was eliminated from further analysis due to falling within the architecture domain. The remaining two Data Groups roughly corresponded with Material and Construction Type from the Common Data Groupings of draft Guideline 20 and further consideration resulted in the following groups:

* Opaque surface assembly

* Structural component thermal properties

* Insulation thermal properties

* Surface finish thermal properties

* Fenestration assembly

* Glazing thermal properties

* Fenestration framing thermal properties

* Shading device properties

The application of the methodology described was applied to all four of the selected use-cases. A summary of the number of Data Groups from different steps of this analysis is shown in Table 1 below.
Table 1. Data Group Counts from Preliminary Analysis

ID                   ENG-01         ENG-03         COM-02      OM-01

Name of use case   Calculate  Select equipment   Collect      Monitor
                   building                     functional  performance
                    thermal                     test data

# from transfer        25             20             34         16

# shown groups in      9               5              3          2
use case in
Guideline 20

# main/use case        13              6             11         16
unified name

# applicable           14              16            22         17

# resulting            47              80            61         48

# eliminated           11              18            12          8

After this analysis many additional groups were combined due to similarity of coverage. A similar but less detailed analysis of the remaining Use Cases from Guideline 20 was conducted in order to identify additional items. The Data Groups identified by this brief analysis were:

* Design Strategies: e.g., Daylighting, Solar PV, Passive Ventilation, etc.

* Facility Operator Survey

* HVAC Operations Data: Basis of Design

* Physical Building Data: Thermal View Geometry

* Simulation Purpose and Supporting Data: Code Compliance Data

* Simulation Purpose and Supporting Data: Rating System Certification Data

* TAB Reports

* Weather Data: Typical Weather

These Data Groups were included in the remaining analysis.

Initial Scan of Three Data Models

To get a better understanding of the Data Groups found, three existing data models were examined:

* Automating Equipment Information Exchange/capital facilities industry XML, AEX/cfiXML (AEX 2006)

* Green Building XML, gbXML (gbXML 2005)

* Industry Foundation Classes, IFC (IFC 2005)

These data models were each constructed from different perspectives in three independent activities. Overlaps and complementary aspects of these bodies of work were sought. An initial scan of each of the three existing data models was done to get a better understanding of the Data Groups. The gbXML specification was scanned with each promising object traversed in an XML schema editor to examine each element. The AEX/cfiXML data model scanned at the top level for each of the schema files and Data Groups that appeared to be related were examined in detail. The IFC data model was also scanned and objects that looked promising were investigated further. This was only the initial scan and a more thorough scan was performed in later analysis. This initial scan was to gain an understanding of the names of the Data Groups and not the individual Data Elements.

The three existing data models do not appear to have the same scope or purpose. According to one of the data model developers:
   The AEX cfiXML schemas were developed to facilitate the exchange of
   functional and physical information for the design, selection,
   purchase, installation, operation and maintenance of engineered
   equipment, e.g., air handlers, pumps and heat exchangers. The AEX
   schemas do not support the description of buildings, building
   systems, partitions, spaces or zones. (Palmer 2008)

This research project was in large part designed to develop a process for systematically elaborating Use Cases for HVAC&R activities to the stage of identifying detailed data requirements for supporting data exchange, and then assessing coverage of these requirements in existing data models. The primary outcome of this project should therefore be viewed as the process that was developed. The specifics of the data requirements (i.e., Data Groups and DAta Elements) and the assessment of their coverage in existing data models should be viewed as preliminary results of an initial pass through this process. Additional iterations through this process will likely modify and further refine these preliminary results. Lessons learned through performing this project will be incorporated in the Guideline 20 document to support future process iterations.

More overlaps might have been found amongst the data models if a different search approach had been employed including review from experts on each of the data models. The results presented are not necessarily definitive, but are results from an initial study of the models.

Another pass was made for the Data Groups at this point looking at the name for Data Groups used in AEX/cfiXML, IFC and gbXML and comparing it to the Data Group names found previously. In addition, the Data Group names were critically reviewed against the original criteria for Data Group names. An example of this analysis is shown in Table 2, where the old and revised Data Group names are shown along with the reason for the changes. At times the Data Groups were combined with reasons given.
Table 2. Example Analysis of Selected Data Group Names

Old Groups Names        New Group Names           Reason for Change

Site shading            Local shading           Use term local to be
                                                consistent with local
                                                climatic conditions.
                                                  Includes adjacent
                                                buildings, structures,
                                                vegetation and shading
                                                providing topography.
                                                 Also shading may be
                                               adjacent and not on the
                                                    building site.

Site wind         Local climatic conditions     Make more generic to
                                                  cover other local
                                                variations in climate
                                                  compared to normal
                                                reference conditions.
                                                Includes local wind,
                                                  temperature, and

Heating climatic  Climatic design conditions     Combine heating and
design                                          cooling since the Data
conditions                                      Elements for heating
                                                design conditions and
                                              cooling design conditions

Cooling climatic                                Combine with previous
design                                                  group.

Thermal zones           Thermal zones                 No change.

Space use type             Room use           Term "space" is confusing
                                                to those outside the
                                               domain. The word "type"
                                                does not add value and
                                                makes the Data Group
                                                appear to be a single
                                                    Data Element.

Loads algorithm    Thermal load calculation     Combine algorithm and
name                        method            software names and remove
                                                   ambiguity about
                                              structural loads by using
                                                  the term thermal.

Loads software                                  Combine with previous
name                                                    group.

Heating thermal          Thermal load            Combine heating and
load                                           cooling since they have
                                                  Data Elements that
                                                  overlap. Include
                                                oversizing factor as a
                                                Data Element. Could be
                                                applied to the thermal
                                              zone or to an air system.
                                              Word thermal required to
                                                  differentiate from
                                                 structural loading.

Cooling thermal                                 Combine with previous
load                                                    group.

Heating thermal                                 Combine with previous
load oversizing                                         group.

Cooling thermal                                 Combine with previous
load oversizing                                         group.

The analysis approach described was applied to all Data Groups resulting in the Data Group names shown in Table 3 as the final Data Group names used in the project.
Table 3. Resulting 107 Data Groups

Acoustic          Air conditioner              Air handler

Air terminal      Appliance Heat             As-built drawing

As-built              Boiler           Building operation training

Building          Certificate of               Chilled beam
performance          readiness

Chiller           Climatic design          Comfort performance

Commissioning      Commissioning               Compressor
plan                  report

Control point     Control system       Control system alarm point

Control system    Control system       Control system sensor point
computed              program

Controller         Cooling tower                 Damper

Data logger        Design intent             Design strategy

Diffuser        Distibution system                 Duct

Economizer       Energy management         Energy performance

Equipment       Equipment full load  Equipment part load performance
airflow             performance

Evaporative      Facility operator                 Fan
cooler                survey

Fan coil unit       Fenestration         Fenestration framing thermal
                      assembly                   properties

Filter            Functional test        Functional test result

Furnace           Gas fill thermal       Glazing thermal properties

Heat                 Heat pump             Heat recovery unit

Heater              Humidifier                 Humidistat

Indoor air        Infiltration air             Instrumentation
quality                 flow

Lighting          Local climatic              Local shading
thermal             conditions

Louvre              Maintenance              Make-up air unit

Mechanical          Mixing box                 Motor drive

Non-occupant      Occupant thermal       Occupant thermal properties
thermal         comfort conditions

Opaque            Opaque surface             Operating cost
material              assembly

Operating         Operations and             Outdoor air flow
Schedule        Maintenance Manual

Performance             Pipe           Pollutant emission performance

Product                 Pump                   Radiant heating

Repair              Replacement                  Room use

Sensor              Sequence of              Shading device

System             System manual                   Tank

Testing,          Thermal capacity               Thermal load
adjusting and

Thermal load      Thermal storage             Thermal zones

Thermostat        Typical weather                 Valve

Valve               Ventilator             Visual performance

Water heater     Water performance

Data Group Definitions

In order to determine which Data Elements may ultimately be part of a Data Group, it is important to understand the meaning behind the Data Group. The approach taken was to define the Data Group by examining existing definitions for the terms used in the Data Group name as well as related terms. This section may be especially relevant to efforts to produce common dictionaries for the HVAC&R industry. These terms were based on the Data Group names, terms used in the Data Elements from the three data models, and common similar terms.

Two general sources of definitions were examined:

* Dictionaries with a focus on the HVAC/R field

* ASHRAE standards

While many specialized dictionaries were found in the general area of architecture and construction, two were specifically on HVAC/R and had recently been updated: ASHRAE Terminology of Heating, Ventilation, Air Conditioning and Refrigeration (ASHRAE 1991) and HVAC/R Terminology - A Quick Reference Guide (Wirtz 2006). When the dictionaries were used, the terms listed were found along with any phrases that began with those words.

ASHRAE standards were examined (ASHRAE 2004a, 2004b, 2004c, 2004d, 2004e, 2007a, 2007b) since they each contain a section defining terms used in the standard. Since these are ASHRAE standards, the definitions may be used in future ASHRAE publications without any copyright restrictions. First, the list of standards and their purposes and scopes were examined on the ASHRAE web site. Those standards that might contain definitions for the Data Group names and related terms were gathered and examined. Table 4 is an example of the definitions found for the Thermal Zones Data Group.
Table 4. Definiitions Related to Thermal Zone

Term                           Definition                     Source

Zone, HVAC         A space or group of spaces within a        Std 90.1
                    building with heating and cooling
               requirements that are sufficiently similar
                    so that desired conditions (e.g.,
                temperature) can be maintained throughout
               using a single sensor (e.g., thermostat or
                           temperature sensor).

Zone (control  Space or group of spaces within a building     ASHRAE
zone)             with heating and cooling requirements     Terminology
                    sufficiently similar that comfort
                 conditions can be maintained by a single
                           controlling device

Zone             A separately controlled heated or cooled     Std 90.2
                     space in a residential building

Thermal block    A collection of one or more HVAC zones       Std 90.1
                grouped together for simulation purposes.
                   Spaces need not be contiguous to be
                 combined within a single thermal block.

Zone           A room or space or group of rooms or spaces    Std 183
                              in a building

Zone            Specific area to be heated or cooled at a     HVAC/R
               specified temperature and controlled by one  Terminology
                thermostat. A space within a house with a
                   distinct pressure compared to other
               pressure zones. Zones within a building may
                     require different indoor design
                temperatures based on their ultimate use.

Zoning           The practice of dividing a building into     HVAC/R
                 small sections for heating and cooling     Terminology
                control. Each section is selected so that
               one thermostat can be used to determine its

By comparing the definitions found as well as an analysis of the scope and intent of the Data Group resulted in definitions for each Data Group. For Thermal Zones the following definition was created:
   a Data Group containing the properties related to a room or a group
   of rooms within a building with heating and cooling requirements
   sufficiently similar that comfort conditions can be maintained by a
   single controlling device


The next step was to re-examine the Data Groups for each of the three existing data models. For gbXML, since the schema is contained in a single file, each element was examined and placed with the appropriate Data Group. These elements contain leaf elements as well as elements serving as groups. In cases where the name of the Data Element was ambiguous, the parent object was examined to determine where it should be included. For IFC, the entire data model was scanned by looking at the alphabetical listing of defined types, enumerations, select types, entities, and property sets. For AEX/cfiXML, the entire schema was scanned object-by-object for each file in the schema. Often entire files did not contain any objects that mapped to the Data Groups.

Interpretation of a Use Case to create a list of transactions and ultimately Data Groups and Data Elements can vary considerably by individual. Also, deciding which Data Groups are within, and outside, the scope of a particular Use Case is critical, but can be controversial due to different interpretations and points of view. More overlaps might have been found amongst the data models if a different search approach had been employed including review from experts on each of the data models. The results presented are not necessarily definitive, but are results from an initial study of the models. An example of the objects found in each of the existing data models for the Data Group Outside Air Flow is shown in Table 5.
Table 5. Corresponding Groups in Existing Data Models for Outside Air

AEX/cflXML           gbXML                      IFC

pq:FlowVolume  AirChangesPerHour   IfcVolumetricFlo wRateMeasure
                  FlowPerArea         IfcDerivedMeasure Value
                 FlowPerPerson     Pset_AirSideSystemInformation
               NaturalVentHiTemp      Pset_SpaceThermalDesign
               NaturalVentLoTemp     Pset_SpaceThermalPHistory
               NaturalVentOccDep  Pset_ThermalLoadDesignCrit-eria


Gather Data Elements

In order to gather the Data Elements, the existing data models were analyzed but, in this case, the Data Elements and properties were reviewed and not just the Data Group names. The purpose of this deeper examination was to create lists of Data Elements. Each of the three existing data models, gbXML, IFC, and AEX/cfiXML were again carefully examined to develop annotated lists of data items, definitions and requirements. Each previously identified group in the existing models was examined in succession, looking at the contained Data Elements. Relevant Data Elements based on the Data Group definitions were collected into a spreadsheet. These existing model Data Groups were checked off the list and marked as either providing Data Elements or not. After a number of Data Groups were analyzed using this approach it was clear that some specific categories of existing model Data Groups were unlikely to provide additional relevant Data Elements. These less useful existing model Data Group were either redundant to another Data Group in the existing data model, contained only references to another Data Group that was examined, or would be covered while examining other existing model Data Groups. For IFC, the specific categories of existing model Data Groups that were not worth examination included measures, selects, and enumerations. Many times enumerations were part of another Data Element and were included then. For AEX/cfiXML, Data Groups whose names including the terms "library," "list," or "table" were often nearly the same as corresponding groups without that term. The skipping of Data Groups in existing data models due to redundancy or coverage elsewhere in the model were unlikely to add additional Data Elements to the lists being gathered.

Some defined Data Groups were created to avoid duplication. For example, many types of HVAC&R equipment contain heat exchangers. Instead of including all of the heat exchanger elements for each of these types of equipment, a group was defined that generically covered heat exchangers. The specific piece of HVAC&R equipment would simply then reference a heat exchanger group. These Data Groups that could be referenced from other Data Groups are:

* Geometric reference

* Product reference

* Compressor reference

* Heat Exchanger reference

* Damper reference

* Diffuser reference

* Duct reference

* Economizer reference

* Fan reference

* Filter reference

* Pipe reference

* Pump reference

* Sensor reference

* Tank reference

* Valve reference

* Valve actuator reference

Given the magnitude of this task, further refinements to scanning the existing model Data Groups were made to make the process more efficient. Often the same existing model Data Groups were present in many of the defined Data Groups because they were generic Data Groups with broad applicability. Of these, some were found to contain few specific Data Elements that were relevant to the defined Data Group, in these cases, the existing model Data Group was flagged to be avoided during later scanning.

Another technique to reduce the number of existing model Data Groups scanned that did not contain useful elements was to filter the existing model Data Groups on an ongoing basis for those that had previously been found to not contain relevant Data Elements. This ongoing filtering relied on checking the status of how those existing model Data Groups had been useful in finding Data Elements when analyzing previous Data Groups.

These techniques, while sacrificing some completeness, enabled all 107 defined Data Groups to be scanned. Without using these techniques for faster scanning of the existing data models, more Data Elements may have been identified for some defined Data Groups but only a subset of the total number of defined Data Groups would have been analyzed. Overall, this approach of optimizing the scanning of the existing model Data Groups for relevant Data Elements resulted in almost all of the Data Groups with relevant Data Elements being well populated.

Overall, of the 107 defined Data Groups from the four use-cases (and selected groups from the remaining Use Cases) 4350 Data Elements were found. This averaged about 40 Data Elements per defined Data Group although several defined Data Groups had no Data Elements and others had over 100.

The main results spreadsheet included 107 Data Groups, shown one per row, with columns for the name of the Data Group, its definition, and the use-case or use-cases that it was based on. In another tab of the main spreadsheet, each of the 4350 Data Elements were shown one per row and included columns for: element, group, type, core, required, repeatable, low, high, units, list, example, subgroup, definition, definition citation, source, enumeration, notes, and conflict. The definitions for the Data Elements almost all came from the existing data models. Unfortunately, these Data Elements were often poorly defined, often simply a restatement of the same words used to define the Data Element. The interpretation of a Use Case to create a list of transactions and ultimately Data Groups and Data Elements can vary considerably by individual. The Data Elements found are one interpretation that may need further refinement.

Identification of Overlapping Data Elements

After the main results spreadsheet was populated by going through the three existing data models, the next step was to make sure that any overlapping elements between data models are identified. To find the overlapping elements, the first pass depended on keeping the elements found for each Data Group from the three existing data models in mind at once. This proved difficult for groups with large numbers of elements. For small groups with few elements, it was not unusual that most of the elements were drawn from a single existing model.

The second step was to methodically examine the Data Elements by Data Group looking for overlapping elements. To do this the spreadsheet was sorted first by Data Group, next by type (float, string, boolean, etc.), and finally by units (m, C, Pa, etc.). This resulted in groups of Data Elements that shared the same type and units within each Data Group. Since items that would be common across data models would share the same type and units, this puts the items in adjacent rows of the spreadsheet. In many cases this still left dozens of rows to manually compare across but it did make the manual comparison more manageable.

In addition, flags were added to indicate from which of the three existing data models each element was drawn. These flags helped to show when groups of items that shared the same type and unit were from different models. Generally, the search started with the elements from the existing data model with the fewest elements. The logic follows that if all of the elements that are a particular type or unit are from the same original data model, they do not need to be further reviewed since finding common elements between two or three models is the goal. This eliminated many rows from further consideration. Using this approach, when a group of Data Elements from a Data Group share the same type and unit and are from more than one of the original data models, often makes the effort simple by comparing a dozen or fewer lines instead of potentially hundreds.

The disadvantage of this approach is that an item that may be represented by different types of data or different units, such as a reference (a string data type) in one data model and an enumeration in another, will not be found ever to be common. This is acceptable since it is unlikely that such a divergence of how a Data Element is represented could ultimately be translated from one data model to another.

The result of trying to find additional overlapping Data Elements that were consistent between the existing data models was poor. Only 37 Data Elements were the same across all three models as shown in Table 6. In addition, 130 Data Elements were defined in two models.
Table 6. Data Elements Found in all Three Existing Data Models

Element                               Group                    Type

Capacity                             Boiler                    float
postalCode                        Design intent                float
mailBoxNumber                     Design intent               string
mailStopNumber                    Design intent               string
Latitude                          Design intent                float
stateProvince                     Design intent               string
streetName                        Design intent               string
Country                           Design intent               string
County                            Design intent               string
countryCode                       Design intent               string
addressLine                       Design intent               string
addressType                       Design intent               string
buildingHouseNumber               Design intent               string
City                              Design intent               string
Longitude                         Design intent                float
Power                                  Fan                     float
volumetric Flow                        Fan                     float
Density              Fenestration framing thermal properties   float
Conductivity         Fenestration framing thermal properties   float
U-value              Fenestration framing thermal properties   float
R-value              Fenestration framing thermal properties   float
Specific heat        Fenestration framing thermal properties   float
Density                    Gas fill thermal properties         float
Conductivity               Gas fill thermal properties         float
U-value                    Gas fill thermal properties         float
R-value                    Gas fill thermal properties         float
Specific heat              Gas fill thermal properties         float
Density                    Glazing thermal properties          float
Conductivity               Glazing thermal properties          float
U-value                    Glazing thermal properties          float
R-value                    Glazing thermal properties          float
Specific heat              Glazing thermal properties          float
Density                Opaque material thermal properties      float
Conductivity           Opaque material thermal properties      float
R-value                Opaque material thermal properties      float
Specific heat          Opaque material thermal properties      float
Capacity                              Tank                     float


The research examined four use-cases from the draft guideline and resulted in 107 Data Groups with definitions. Analysis of these Data Groups resulted in 4350 Data Elements. The following Data Groups had the most Data Elements with each including more than 70 elements:

* As-built drawing

* Compressor

* Control system

* Controller

* Energy management system

* Energy performance

* Functional test result

* Heat exchanger

* Maintenance schedule

* Operations and Maintenance Manual

* Performance monitoring system

* System manual

* Valve

* Visual performance

Of the 107 Data Groups, the following Data Groups contained no Data Elements when examining the existing models:

* Local climatic conditions

* Comfort performance

* Control System Computed Point

* Design strategy

In addition, the research resulted in the following Data Groups being sparsely populated using the existing models. The following Data Groups had ten or fewer Data Elements and are shown in order of fewest to most Data Elements:

* Room use

* Infiltration air flow

* Control system program

* Equipment full load performance

* Occupant thermal properties

* Local shading

* Humidistat

* Acoustic performance

* Equipment part load performance

* Operating Schedule

* Pollutant emission performance

* Thermal load

Of the 4350 Data Elements, only 37 (1%) Data Elements were the same across all three models. Some of the 37 elements appeared in more than one Data Group. Of these 22 unique Data Elements that appeared in all three existing data models, 14 were not related to building or HVAC&R but focused on addresses or global location.

An additional 130 (3%) Data Elements appeared in only two of three existing data models. The remaining Data Elements appeared to be unique across the existing data models. This appearance is heavily influenced by unclear definitions for many Data Elements in the existing data models. Without good definitions it was nearly impossible to map the intent of a Data Element from one existing model to another Data Element in a different existing data model. For the Data Groups that were defined as part of the project, the definitions ranged from 69 to 354 characters in length including spaces and punctuation. Of the 4350 Data Elements, 1375 (31%) had definitions of 69 characters or more. The definitions selected usually represent the longest of the definitions found in the three existing data models. This indicates that in general two-thirds of the Data Elements probably had inadequate definitions.

In addition: "At the January 2008 ASHRAE meeting, the ASHRAE BIM and Interoperability Committee reviewed the assessments by GPC20 (XML Definitions for HVAC&R) and the Terminology Committee (TC 1.6) of the inconsistencies among the various glossaries used in ASHRAE standards and adopted the recommendation to develop a consistent data dictionary as part of transitioning ASHRAE standards from paper-based products to computer-processable knowledge resources. As ASHRAE proceeds with this initiative, ASHRAE is examining how to deliver computer-processable ASHRAE standards that will be aligned with the data dictionaries of peer organizations for the other sectors of the building industry." (ASHRAE 2008c)

During the course of the research other subjective observations were made that could aid future researchers following a similar approach.

* Domain expertise for a Use Case is an asset to help define a Data Group and elements. Gaining expertise by reviewing publications in a given field is not a substitute for first-hand knowledge.

* Interpretation of a Use Case to create a list of transactions and ultimately Data Groups and Data Elements can vary considerably by individual. Even people having relatively similar backgrounds and expertise can interpret Use Cases very differently. Therefore, to encourage the arrival of consensus on exposed elements to be standardized, as many independent Use Case activities should be engaged in as possible. Attempts to reuse terms discovered in earlier Use Cases should be encouraged, but elaboration of new terms should also be encouraged.

* Creating a Data Group name that captures the scope of the Data Group can be a difficult process. The name must be unique and cover the intended Data Elements but without being overly abstract or general.

* Creating definitions for Data Groups or Data Elements can be challenging since the definition should not use any of the terms used in the name of the Data Group or element. By consulting multiple sources of definitions the intended meaning for the Data Group can be determined.

* Characteristics of a good data model include making it approachable to people using it in the industry and that includes naming Data Groups using familiar names, making the structure simple so that it can be learned quickly without too many abstract concepts, and defining the group and elements with descriptive definitions that use other terms.

* Deciding which Data Groups to focus on can be controversial due to different interpretations and points of view.

* Data groups, especially those describing physical products, often contain a large number of Data Elements that could be defined in separate Data Groups. In order to manage this, Data Groups often need to reference other Data Groups to minimize duplication of Data Elements.

* The ENG-03 Use Case spurred the creation of many equipment Data Groups but they do not cover all types of HVAC equipment possible.

* The use of targeted examples for each identified object can assist in discovering overlapping Data Elements.

* A task not described in this paper but shown in an appendix of the 1354-RP research project final report is Demonstration Data Exchange which was challenged by the differences between the models and poor definitions.


The purpose of Guideline 20 (ASHRAE 2008a) is:
   To establish a common data exchange format for the description of
   commodity data and HVAC&R information via the standard XML
   (eXtensible Markup Language) formatting language.

This purpose lays out an enormous challenge. The research project found 4350 Data Elements based on four well analyzed Use Cases yet the Guideline includes twelve Use Cases and additional Use Cases are needed to complete it. In addition, none of the Data Groups described in this research are "complete," meaning that they do not contain all Data Elements expected by a practitioner in that field. Finally, approximately one-third of the definitions from the existing data models are likely to be sufficient for the elements identified during the research project. Overall, the magnitude of the task set by the Guideline 20 purpose is very large. Due to the size of the task, the Guideline Project Committee must remain diligent in focusing their efforts on HVAC&R and de-emphasize generic Data Groups and attributes (such as versioning, appointments, authorizations, notes, and schedule) that other organizations might develop. In addition, the GPC should focus on defining the data needs of the HVAC&R domain and may not want to expend resources on detailed interoperability between data model formats or the exact implementation or representation of the Data Groups and elements within each model.

Detailed results of this work are available in the final report of the 1354-RP research project. The report includes many additional tables of results.


AEX. 2006. AEX (Automated Equipment Information Exchange) cfiXML version 2.01

ASHRAE. 1991. ASHRAE Terminology of Heating, Ventilation, Air Conditioning and Refrigeration Second Edition. Atlanta Georgia: American Society of Heating, Refrigerating and Air-Conditioning Engineers, Inc.

ASHRAE. 2004a. ANSI/ASHRAE Standard 55-2004. Thermal Environmental Conditions for Human Occupancy. Atlanta Georgia: American Society of Heating, Refrigerating and Air-Conditioning Engineers, Inc.

ASHRAE. 2004b. ANSI/ASHRAE Standard 62.1-2004. Ventilation for Acceptable Indoor Air Quality. Atlanta Georgia: American Society of Heating, Refrigerating and Air-Conditioning Engineers, Inc.

ASHRAE. 2004c. ANSI/ASHRAE Standard 62.2-2004. Ventilation and Acceptable Indoor Air Quality in Low-Rise Residential Buildings. Atlanta Georgia: American Society of Heating, Refrigerating and Air-Conditioning Engineers, Inc.

ASHRAE. 2004d. ANSI/ASHRAE/IESNA Standard 90.1-2004 Energy Standard for Buildings Except Low-Rise Residential Buildings. Atlanta Georgia: American Society of Heating, Refrigerating and Air-Conditioning Engineers, Inc.

ASHRAE. 2004e. ANSI/ASHRAE Standard 90.2-2004. Energy-Efficient Design of Low-Rise Residential Buildings. Atlanta Georgia: American Society of Heating, Refrigerating and Air-Conditioning Engineers, Inc.

ASHRAE. 2007a. ANSI/ASHRAE/ACCA Standard 183-2007 Peak Cooling and Heating Load Calculations in Buildings Except Low-Rise Residential Buildings. Atlanta Georgia: American Society of Heating, Refrigerating and Air-Conditioning Engineers, Inc.

ASHRAE. 2007b. ANSI/ASHRAE Standard 135.1-2007. Method of Test for Conformance to BACnet. Atlanta Georgia: American Society of Heating, Refrigerating and Air-Conditioning Engineers, Inc.

ASHRAE. 2008a. ASHRAE Guideline 20P Working Draft 1/ 21/2008, XML Definitions for HVAC&R. Atlanta Georgia: American Society of Heating, Refrigerating and Air-Conditioning Engineers, Inc. Received by email.

ASHRAE. 2008b. Standard 166 Heating, Ventilating, Air-Conditioning and Refrigerating Terminology Working Draft. Atlanta Georgia: American Society of Heating, Refrigerating and Air-Conditioning Engineers, Inc. Received by email.

ASHRAE. 2008c. Draft ASHRAE BIM Guide--An Introduction to Building Information Modeling and Interoperability for the HVAC&R Industry. Atlanta Georgia: American Society of Heating, Refrigerating and Air-Conditioning Engineers, Inc. Received by email.

Cockburn, A. 1997 Structuring Use Cases with Goals. Originally published in Journal of Object-Oriented Programming, in two parts, the Sep-Oct 1997 issue and the Nov-Dec 1997 issue. Also available at accessed December 9, 2005.

Cockburn, A. 2000. Writing Effective Use Cases. Addison-Wesley Professional; 1st edition.

gbXML. 2005. gbXML Green Building XML Schema 0.34. Accessed on December 9, 2005.

IFC. 2005. Industry Foundation Classes IFC2x Edition 3 Technical Corrigendum 1. Accessed on May 8, 2008.

Palmer 2008. Personal communication with Mark Palmer, Project Manager, Automating Equipment Information Exchange, NIST. July 7, 2008.

Wirtz, R. 2006. HVAC/R Terminology - A Quick Reference Guide, Second Edition. Mount Prospect, Illinois: ESCO Press.

W3C. 2004. Extensible Markup Language (XML) 1.0 (Third Edition). W3C--World Wide Web Consortium.

Jason Glazer, PE


This paper is based on findings resulting from ASHRAE Research Project RP-1354.

Jason Glazer is president of GARD Analytics, Inc., Arlington Heights, IL.
COPYRIGHT 2009 American Society of Heating, Refrigerating, and Air-Conditioning Engineers, Inc.
No portion of this article can be reproduced without the express written permission from the copyright holder.
Copyright 2009 Gale, Cengage Learning. All rights reserved.

Article Details
Printer friendly Cite/link Email Feedback
Title Annotation:heating, ventilation, air conditioning and refrigeration
Author:Glazer, Jason
Publication:ASHRAE Transactions
Article Type:Report
Geographic Code:1USA
Date:Jul 1, 2009
Previous Article:Comfort, energy consumption, and economics of a school with energy recovery.
Next Article:Communication performance of BACnet Web Service over the Global Internet.

Terms of use | Privacy policy | Copyright © 2019 Farlex, Inc. | Feedback | For webmasters