ASHRAE LO-09-050-2009 Common Data Definitions for HVAC&R Industry Applications《HVAC&R工业用一般数据的定义》.pdf

《ASHRAE LO-09-050-2009 Common Data Definitions for HVAC&R Industry Applications《HVAC&R工业用一般数据的定义》.pdf》由会员分享，可在线阅读，更多相关《ASHRAE LO-09-050-2009 Common Data Definitions for HVAC&R Industry Applications《HVAC&R工业用一般数据的定义》.pdf（14页珍藏版）》请在麦多课文档分享上搜索。

1、2009 ASHRAE 531This paper is based on findings resulting from ASHRAE Research Project RP-1354.ABSTRACT Software is a critical component of the design, construc-tion, and operation of HVACExtension data items: items suggested by Use Cases but not well represented in existing models;Conflicting / prob

2、lem 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 guideli

3、nes, and software applications.A secondary objective is to produce a demonstration implementation of automated inter-model data exchange.XMLThe eXtensible Markup Language (XML) is a meta-format that can be used to create almost any file format imag-inable. Based on the World Wide Web Consortium (W3C

4、), 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

5、Standard Gener-alized 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

6、 which form markup. Markup encodes a description of the documents 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

7、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 Syndica-tionSVG Scalable Vector GraphicsMathML - Mathematical Markup LanguageUBL Universal Business LanguageebXML - Electronic B

8、usiness using eXtensible Markup LanguageLandXML For land surveying and developmentOne 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

9、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

10、 human-legible and reason-ably 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.ASHRAEs decision to use XML as part of a guideline of HVAC finding satisfac

11、-tory 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 auto-matic, where software driven by designer preferences determines the selected unit. Alternatively, a semi-auto-mat

12、ic process could be useful, in which software identi-fies 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 th

13、e 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, w

14、eight, 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 en

15、gineer, and other actors such as the architect, owner, structural engineer, elec-trical 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

16、 actors in Use Case parlance. The columns of the table include: Step the step numberPrimary Actor the party performing the majority of the task or chiefly responsibleActor that is the Source of Data the party providing the dataActor that is the Destination of Data the party receiv-ing the dataData G

17、roups the information exchanged described at a level of a named group of Data ElementsComments details that do not fit into other columnsSince the ultimate goal for this process is an identifica-tion of Data Groups, the information transferred during each ASHRAE Transactions 535step of the process i

18、s 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 modifyi

19、ng 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 buildingPower requirements and con

20、trol requirementsThese transfers will serve as the basis for creating Data Groups. The same process of going from a textual descrip-tion 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 no

21、t 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 incl

22、ude 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

23、the importance of development of Data Groups in a collabor-ative 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 i

24、nterpre-tation 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

25、 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 IDENTIFICATIONWhile the end result of analyzing the Use Cases was an identification of Data Groups, those Data Groups lack

26、ed 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 SelectionThe first step is to refine the Data Groups identified in the analysis of the Use Cases an

27、d 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

28、 step was to examine these different lists and make a single unified list of Data Groups that had the following criteria:Unique to HVAC 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 Editi

29、on 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/.