Common data definitions for HVAC&R industry applications.INTRODUCTION 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. XML 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"> <kind>absorption</kind> <capacity units="tons"> 100 </capacity> <minimumLeavingTemperature units="F">40</ minimumLeavingTemperature > </chiller> 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. ANALYZE USE CASES FOR HVAC&R PROCESSES 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. DATA GROUP IDENTIFICATION 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
loads
# from transfer 25 20 34 16
analysis
# 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
common
# resulting 47 80 61 48
groups
# eliminated 11 18 12 8
groups
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
humidity.
Heating climatic Climatic design conditions Combine heating and
design cooling since the Data
conditions Elements for heating
design conditions and
cooling design conditions
overlap.
Cooling climatic Combine with previous
design group.
conditions
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.
factor
Cooling thermal Combine with previous
load oversizing group.
factor
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
performance
Air terminal Appliance Heat As-built drawing
unit
As-built Boiler Building operation training
specification
Building Certificate of Chilled beam
performance readiness
notice
Chiller Climatic design Comfort performance
conditions
Commissioning Commissioning Compressor
plan report
Control point Control system Control system alarm point
Control system Control system Control system sensor point
computed program
point
Controller Cooling tower Damper
Data logger Design intent Design strategy
Diffuser Distibution system Duct
Economizer Energy management Energy performance
system
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
procedure
Furnace Gas fill thermal Glazing thermal properties
properties
Heat Heat pump Heat recovery unit
exchanger
Heater Humidifier Humidistat
Indoor air Infiltration air Instrumentation
quality flow
performance
Lighting Local climatic Local shading
thermal conditions
properties
Louvre Maintenance Make-up air unit
schedule
Mechanical Mixing box Motor drive
room
Non-occupant Occupant thermal Occupant thermal properties
thermal comfort conditions
requirements
Opaque Opaque surface Operating cost
material assembly
thermal
properties
Operating Operations and Outdoor air flow
Schedule Maintenance Manual
Performance Pipe Pollutant emission performance
monitoring
system
Product Pump Radiant heating
Repair Replacement Room use
Sensor Sequence of Shading device
operation
System System manual Tank
Configuration
Testing, Thermal capacity Thermal load
adjusting and
balancing
Thermal load Thermal storage Thermal zones
calculation
method
Thermostat Typical weather Valve
Valve Ventilator Visual performance
actuator
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
requirement.
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 EXISTING DATA MODEL EXAMINATION 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
Flow
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
OAFlowPerArea
OAFlowPerPerson
Zone
DEVELOP DATA ELEMENT LISTS 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 SUMMARY AND DISCUSSION 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. CONCLUSION 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. REFERENCES AEX. 2006. AEX (Automated Equipment Information Exchange) cfiXML version 2.01 http://www.fiatech.org/projects/idim/aex.htm. 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. http://gpc20.ashraepcs.org/ 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 http://alistair.cockburn.us/crystal/articles/sucwg/structuringucswithgoals.htm 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. http://www.gbxml.org/ Accessed on December 9, 2005. IFC. 2005. Industry Foundation Classes IFC2x Edition 3 Technical Corrigendum 1. http://www.iai-tech.org/ifc/IFC2x3/TC1/html/index.htm 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. http://www.w3.org/TR/2004/REC-xml-20040204/. Jason Glazer, PE Member ASHRAE This paper is based on findings resulting from ASHRAE Research Project RP-1354. Jason Glazer is president of GARD Analytics, Inc., Arlington Heights, IL. |
|
||||||||||||||||||||||
Printer friendly
Cite/link
Email
Feedback
Reader Opinion