阐述IFC标准的几个基本问题

阐述IFC标准的几个基本问题
阐述IFC标准的几个基本问题

阐述IFC标准的几个基本问题

?发布时间:2010-05-20

?文章来源:https://www.360docs.net/doc/d11181788.html,

?责任编辑:liyaoneng

【中国BIM门户黄锰钢注】这篇文章回答了这几个问题:1. IFC标准是什么? 2. IFC标准是如何制定出来的? 3. IFC标准给建筑行业带来的真正价值在哪里?

4. IFC模型是否该被用作项目信息的“数字字典”?

5. IFC标准会对你的事业产生什么影响?——对IFC标准感兴趣的朋友可以看看。

Facilitating Interoperability in the Building Industry

A Different Approach to Using IFCs

Jim Forester and Ian Howell

What are Industry Foundation Classes (IFCs)?

The International Alliance for Interoperability (IAI) has pioneered an international technical effort by industry leaders in 19 countries to define a single building information framework as one authoritative semantic definition of building elements, their properties, and interrelationships—the IFC model. This effort has resulted in the publication of a rich set of building element definitions designed specifically to facilitate the unambiguous exchange of data between software applications. More important, the IFC model has been endorsed as a standard of the International Organization for Standardization (ISO) for use by industry stakeholders.

(The full IFC model is available for reference on the IAI international Web site. For a more detailed and non-technical explanation of IFCs, we recommend the AECbytes article, “The IFC Building Model: A Look Under the Hood.”)

How Have IFCs Been Defined?

The IAI has, from its inception, relied heavily on use-cases defined and elaborated by industry practitioners. For example, in defining the processes specific to calculating a building’s heating and cooling requirements, engineers provide detailed definitions of all the data that is inherent to this process. In this example, leading industry organizations, such as the American Society of Heating, Refrigeration and Air-Conditioning Engineers in the United States, the Chartered Institution of Building Services Engineers in the United Kingdom, and the Deutsches Institut fur Normung standards organization in Germany, are all consulted for concise, unambiguous, locale-independent definitions that are captured within the IFC model. The resulting data definitions contained in the model consist of things from the very generic (e.g., it’s a fan used to move air in the building) to the very detailed (e.g., the flow characteristics at each point in the distribution system, captured in enough detail to allow for a comprehensive fluid flow simulation and analysis).

Who are these industry experts? Many work for companies that are industry leaders—Hellmuth, Obata + Kassabaum Inc. and Jaros Baum & Bolles in the United States; Obermeyer Planen + Beraten GmbH in Germany; Building Design Partnership in the United Kingdom; Kajima Corporation in Japan; Woods Bagot in Australia; Olof Granlund in Finland; Ingérop in France; Romb?ll in Denmark; and Selvaag in Norway, along with many others. These companies are sponsoring the IAI’s efforts, both financially and by allocating significant resources, to identify and implement improved work processes that can break down the barriers to productivity gains in the delivery of projects for their clients. They expect that their voluntary involvement in the IAI, working closely with fellow industry professionals, data modelers, software developers, and members of academia, can deliver on the promise of interoperability. They provide the rich language of building design, construction, and operation that form the basis for data modelers to codify their practice in the IFC model.

The results of this rigorous and unprecedented collaborative effort have led to an ISO-endorsed building model definition that has been developed to meet the process-specific needs of the users of building data in the architecture, engineering, construction, and owner-operator industries.

The True Value IFCs Bring to Our Industry

One of the greatest contributions of the IFC model is the architectural, engineering, construction, owner-operator (AECO) specific,

non-graphical definitions that have been captured from building industry domain experts. It is our contention that the true value of the IAI’s work is the agreements that have been reached globally on the semantics of a building model (elements, assemblies, relationships, and processes) versus IFCs per se.

In our opinion, the laudable efforts by computer-aided design (CAD) and BIM vendors to support IFCs have thus far focused primarily on architectural graphical elements that require physical coordination within a three-dimensional space. CAD vendors have spent huge amounts of time at great cost to work out the intricacies of this exchange between their respective products, each with its own internal BIM. However, there is currently little benefit to end-users by adding IFC exchange focused on the graphical representations of building elements that they can already exchange today via DWG, DXF, and DWF. In fact, this is actually a disservice to the industry in the sense that the benefits of IFC-model exchange become mired in the evaluation of the fidelity of the graphics elements rather than focusing on the exploitation of the non-graphical data in other processes. A focus instead on the real value associated with capturing and communicating non-graphical properties adds true intelligence to the graphics and accommodates many more AECO processes.

In our view, the IFC model offers AECO companies an industry agreed-upon set of definitions with which to describe their project and business processes. Herein lies the real opportunity for achieving major breakthroughs in attacking the runaway costs of inadequate interoperability in our industry. This cost overhead totals in excess of $15 billion annually according to the National Institute of Standards and Technology as quantified in its August 2004 report, Cost Analysis of Inadequate Interoperability in the U.S. Capital Facilities Industry.

Using the IFC Model as a “Data Dictionary” for Project Information Based on our industry research, it is clear that specifically discussing

how industry professionals might directly use IFCs is a meaningless exercise. It is a bit like talking to a car buyer about how the fuel injection system actually works when they are actually interested in the trade off between driving performance and fuel economy. We believe the IAI has been too focused on IFCs as a technology in and of itself, rather than relegating it to its rightful role as an enabler for delivering improved information sharing among the processes practiced daily by architects, engineers, contractors, and building owners.

These industry professionals can readily identify the points of pain associated with their project deliverables and everyday work practices, such as the difficulty in verifying that a client’s space program expectations are being properly met, or their inability to find a piece of information they know already exists somewhere in the overwhelming amount of project data they are managing. Very few of the professionals that we have spoken to, however, are concerned about the specifics of how a particular emerging industry open data standard like IFCs might be exploited to assist them; understanding these technical details are not their concern nor interest. Thus, few industry practitioners are clamoring for IFC-compliant software tools or services despite the potential benefits and cost savings.

In analyzing project and business processes specific to the AECO industry, our research has identified that one of the most often overlooked causes of the lack of interoperability in the AECO industry is the absence of common terms and definitions. Using a consistent “data dictionary” on a project provides a huge opportunity for consistency across sets of documents, re-use of project-related data, and sharing of information between the members of an extended project team.

It is our assessment that IFCs alone, as an information framework, are unlikely to become a singly unifying model used in the building industry: There are too many processes and areas of specialization to be encompassed comprehensively within a single model framework. Rather, when used in conjunction with existing data structures and established data exchange formats, and when combined with the pragmatic capabilities of XML as a ubiquitous communications protocol, IFCs have the potential of becoming

an essential part of an emerging “language” for information sharing in the building industry.

Having a common set of terms and definitions is a prerequisite for interoperability; it is the foundation of any meaningful communication. For it to be optimally useful and allow for improved productivity, it has to be focused specifically on what information is relevant to the needs of the communicating parties. This is where the activities of the IAI will have a significant impact on the AECO industry. By using these standardized definitions of the processes captured in the IFC model, software applications used in the AECO industry have a much greater opportunity for meaningful communication. Furthermore, it offers any application the ability to meaningfully exchange selected project data with other standards initiatives that have found support in specific areas of the AECO industry, such as the civil engineering community’s LandXML initiative and the structural industry’s CIS/2 standard.

This very basic tenet of standardized terminology was a fundamental prerequisite that led to achieving greater levels of automation in the aerospace and manufacturing industries. It has yet, however, to be applied to the heterogeneous AECO industry where the potential benefits might be even greater than in these other industries.

How will IFCs Affect Your Business?

There are several innovators that are already starting to exploit the powerful “data dictionary” concepts found in the IFC model. For example, in Norway the IFC model is being used to unambiguously exchange

non-graphical data between the different spoken languages in the region. The IFC Model Based Operation and Maintenance of Buildings (Ifc-mBomb) project in the United Kingdom relies heavily on the exchange of simple property sets to facilitate the objectives of a procurement-based model. In Singapore, local authorities mine the semantics found in the IFC model to perform building code compliance, checking against local regulations.

We anticipate that more software applications will leverage the contents of the IFC model, particularly from leading vendors who are committed to supporting open data standards. This trend will grow as more building

owners follow the lead of the U.S. General Services Administration's Public Building Service 2004 policy directive calling for submission of IFC-based building model information in all concept design proposals for its future project programs. More discussion on the how building owners will impact the drive to achieve improved interoperability can be found in the AECbytes Viewpoint article, “The Building Owner as a Catalyst for Change in the Construction Industry.”

These initial efforts represent the beginnings of a sea change in the AECO industry toward the use of richly defined (intelligent) building data and better structured project information, providing the ability to re-use data across different work processes and to share project information more easily between members of the extended project team.

Jim Forester is chief data architect of Newforma, a software development company serving AECO companies. He has been an active member of the Model Support Group and Technical Advisory Group of the International Alliance for Interoperability since its inception. He is a registered mechanical engineer and his professional background includes software development, design content, and consulting services to the AECO industry. Ian Howell is chief executive officer of Newforma. He is an Australian architect, a co-founder and current board member of the International Alliance for Interoperability, and has extensive experience in applied technology in the building industry, both as a director at Autodesk and as vice president of Citadon.

FC标准之IFCXML简介

?发布时间:2010-06-18

?文章来源:互联网

?责任编辑:liyaoneng

XML的概念与特点

随着网络计算机技术和数据集成的发展, XML技术应运而生, XML是一种独立于操作系统以及网络系统的、与平台无关、用来描述任意数据的标识语言。XML具有内容和应用分开、结构化、自描述性、开放型等特性,已经成为在Internet 上数据表示和数据交换的新标准。

XML是Extensible Markup Language的缩写,即可扩展标记语言,它

是由W3C组织原本为定义一种互联网上交换数据的标准。XML源自SGML语言,

它降低了SGML的复杂程度,又保留了它大部分的功能。XML具有众多优点,它

不仅有着HTML语言所欠缺的巨大的伸缩性与灵活性,而且还包括了良好的数据存储格式、灵活的可扩展性、高度结构化、便于网络传输等。

XML主要包括3个元素: DTD (Document Type Declaration,文档类

型声明) 或XML Schema, XSL (eXtensible Stylesheet Language,可扩展样式表语言) 和 Xlink (eXtensible Link Language,可扩展链接语言)。其中,DTD/ Schema 规定了XML 数据文档的逻辑结构,定义了XML 文件中的元素、元素的属性以及元素和元素属性之间的关系,可以用来定义行业数据表示和数据交换标准。XSL是用于规定XML 文档样式的语言,描述了如何显示XML 文档内容, XSL实现了数据内容和数据显示的分离。Xlink扩展了目前Web 上的简单

链接,使得在XML 文档中获得生动的链接效果。

XML并不是标记语言。它只是用来创造标记语言(比如HTML)的元语言。XML能针对特定的应用自定义标记和自己的文档结构,可以指定元素之间的关系。它巧妙地实现了数据定义与数据内容的统一,数据内容与数据表达形式的分离,从而为程序间的数据传递和对于大型复杂的文档的管理,带来了极大的方便。

XML允许各种不同的专业开发与自己的特定领域有关的标记语言。这就使得该领域中的人们可以交换笔记、数据和信息,而不用担心接收端的人是否有特定的软件来创建数据。特定领域的开发人员甚至可以向本领域外的人发送文档,有相当的理由可以认为,至少接受文档的人能够查看文档的内容。

更进一步说,为特别的领域创建标记语言不会产生“臃肿软件”(bloatware)或是对于本专业外的人来说产生不必要的复杂性。对于浏览器开发商来说,都不需要对特定的领域提供特殊的支持,也不需要提供复杂的插件。这一点现在已经实现了。

XML是自描述的。XML在基本水平上使用的是非常简单的数据格式。可以用100%的纯ASCII文本来书写,也可以用几种其他定义好的格式来书写。ASCII 文本是几乎不会“磨损”的。丢失一些字节甚至是相当多的字节,剩下的数据还是可以读取的。

XML所有的特点总的概括如下:XML将数据结构定义、数据内容和数据显示三者独立开来,对数据的表示和操作等具有较高的灵活性;XML 文档的树形结构能很好地描述客观世界对象的层次模型,易于理解,符合面向对象设计思想;XML 是可视化、开放的语言,方便实现信息发布,用户通过浏览器直观查看XML 文档信息;XML 实现网络环境下数据资源的共享,可以通过Web 服务器在网络中方便地实现数据传输;XML 作为一种内容建模和数据交换标准得到了广泛认同,众多厂商都提供了XML支持,如Microsoft SQL Server, ORACLE

等数据库都增加了XML支持;XML作为一个开放标准,独立于机器平台、提供商及编程语言,利于实现应用程序间的互操作和系统集成。

XML格式的优点总结有以下四点:

●数据是自说明的。每个数字的意义是清楚的,且不会错误地与数字本身相联系。

●XML提供的数据可用广泛的具有XML处理能力的工具加以处理。数据量可以很大,但是数据额外的冗余就允许使用更多的工具来处理它。

●数据可用标准工具加以处理,数据可用标准工具查看。

●用样式单可容易地生成同样数据的不同视图。

XML在应用程序间的可交换性

XML使用的是非专有的格式,不受版权、专利、商业秘密或是其他种类的知识产权的限制。XML的功能是非常强大的,同时对于人类或是计算机程序来说,都容易阅读和编写。因而成为交换语言的首选。

由于XML是非专有的并易于阅读和编写,就使得它成为在不同的应用间交换数据的理想格式。数据可以在程序间来回交换,还可以与银行、经纪事务所和其他机构交换数据。使用XML而不是专有格式,人们就可以利用任何理解XML 的工具来处理数据。还可以为不同的目的使用不同的工具。一个程序用来查看而

另一程序用来编辑。XML使用户不必因为数据已经用专有格式编写好了或是接受数据的人只接受专有格式而限制在一个特定的程序上。

结构化和集成的数据

XML对于大型和复杂的文档是理想的,因为数据是结构化的。这不仅使用户可以指定一个文档中的元素的词汇表,而且还可以指定元素之间的关系。如果向数据库中输入数据,可确保没有漏下的字段。当没有数据输入时还可提供一个缺省值。XML也提供客户端的集成机制,可以根据多种来源集成数据并将其作为一个文档来显示。数据还可以马上进行重新排列。数据的各个部分可以根据用户的操作显示或隐藏。当处理大型的信息仓库,比如关系型数据库时是极为有用的。

XML文档的组成

XML文档包含由XML标记和字符数据组成的文本。它是一个有固定长度的有序字节的集合,并遵守特定的约束。它可能是或者不是一个文件。例如,XML文档可能:

●存储在数据库中

●由CGI程序在内存中瞬间创建的

●由几个相互嵌套的不同文件组合而成

●不存在于自身的文件中

但是如果把一个XML文档看作一个文件也是可以的,只要记住它可能并不是存在于硬盘上的真实文件。XML由称为“实体”的存储单元组成,每个实体包含文本或者二进制数据。文本数据由字符组成,二进制数据用于图片和小程序等类内容。用一个具体的示例说明就是,一个含有标记的原始HTML文件是一个实体而不是文档。一个HTML文件加上所有使用标记嵌入的图片就组成一个文档。

6.9 XML的优势和劣势

XML的优势主要可归结为以下三点:

●目前XML的知识在许多企业和组织里广泛的应用。

●XML的多种开发工具都不昂贵。

●易与浏览器以及其他标准软件集成。

XML的劣势主要体现在如下两点:

●数据转换文件较大

●转换检查的连贯性不是很理想

ifcXML简介

目前处理IFC数据的主要方法有四个,分别是:

(1) Express STEP SPF,包括各种不同的工具包;

(2) Express STEP SDAI ( VB, Java和C++ );

(3) Express-X 以及其他数据库查询和修改语言;

(4) ifcXML,包括各种应用程序和接口。

本文主要介绍使用ifcXML处理IFC数据的方法。IFC 2×2的ifcXML 是2004年1月28日在巴黎的IAI国际会议中被公布的,它是国际标准ISO-10303 part 28的一个实现,这个标准提供了IFC EXPRESS ( ISO 10303 part 1 ) 的XML模式规范,这个从EXPRESS到XML的映射在一个控制转换过程细节的配置文件指导下进行。

IfcXML是从EXPRESS模式派生出来的到XML数据定义(.xsd )的映射,它的数据文件通常用.xml或偶尔用.ifx做后缀,文件的结构通常用XML模式( XSD ) 来定义, XSD作为模式定义语言从IFC定义中自动生成。

经ifcXML模式( .xsd ) 验证的ifcXML数据不一定和IFC EXPRESS模式( .exp )完全一致。IfcXML描述的是SPF(Step Physical File)的替代,它的文件比SPF文件大得多,是SPF文件的2 –10 倍,如果内容是整个项目模型就更加显著。然而IfcXML的主要目的不是代替整个项目模型,而是覆盖部分的交换、报告、文档、查询等等,这时文件大小只是原来的零头。当处理非常大的文档时,一些XML工具并不是很有效,这时实现很关键。

一个新的ifcXML模式在IFC2×2修订中被使用,在经过严格的测试后,IfcXML2议案已取得了完全的支持,在ifc2×2和下一个版本中被批准。

就目前其他的处理IFC数据三种方法相比,ifcXML是当前运用地最少的。这是由于它文件的容量是SPF文件的2-10倍。然而,ifcXML的主要的主要功能不在于取代整个工程的数据交换而是去负责部分的转换、报告、文档资料和查询工作等等,因为这些文件的容量可以算得上是很小的部分。如果SPF文件的容量已经达到50M,那ifcXML恐怕就无能为力了。关于四种方式的基本比较如上图示。

一些XML的工具在处理大容量文件时显得不那么灵活。关键时候,IFC模型应从服务器或者数据库端被读取。某些数据库支持EXPRESS和XSLT直接执行数据的转换。

IfcXML规范建立在Express规范的基础上并且有着更丰富的拓展。XML

规范映射的定义(.xsd)会丢失一些集成规则,反向关系和导出属性的约束。一些不符合IfcXML规范的数据(.xsd)不能被全部转换为IFC EXPRESS的格式

(.exp)。

XML与IFC的关系

首先,XML是数据转换的语言。很早就有人预言:ifcXML 会在应用软件领域占有一席之地,特别体现在IFC对象模型和以下之间的映射关系:

●记载项目进度表,产品数据表等描述的文件;

●包含定单,数据信息请求,电子商务交流等描述的消息;

●基于XML诸如GIS对象模型领域的沟通。

IfcXML的描述也被看好对部分模型AEC-FM的提取,传输和合并的操作。部分模型对于协同设计操作是非常重要的。一般来说,完整的建筑模型的传递在CAD环境下都是以SPF为格式的。

IfcXML的实现

建立应用系统的ifcXML输入/输出接口的基本步骤为:

●决定哪些数据需要从软件应用系统读出或写入,确定哪些数据需要转换。和用户探讨关于他们需要从应用中转进/转出的数据。

●查看IFC模式,看与哪些实体定义相关。

●理解在应用系统中信息是怎么存储的,从应用存储单元存取信息需要什么编程接口。

●为要转换的数据设计一个应用系统中的数据结构之间的映射表,一列定义存储单元中和需要从应用存储单元中存取信息的函数调用;第二列定义到ifcXML模式中和需要转换的数据项匹配的元素的Xpath。

●·为输入/输出编写使用XML解析器的应用代码,用该编程接口来解析XML实例文件,并按照步骤4中定义的映射表从ifcXML实例文件和应用存储单元中读取或写入信息。

以上的每一个步骤都需要确保所写的应用遵循IFC的实现指南。只要遵循共同的数据传输标准IFC,并通过一个标准的数据接口输入和输出信息,能实现异构系统之间的数据转换和共享。

已有一些应用程序支持ifcXML,比如EPM Express Data Manager、Eurostep Model Server, XML SPY 2005、Archi CAD等等。

IFC是国际建筑业事实上的标准,对IFC的研究不仅有很好的先进性,而且有足够的适应性,可以灵活的满足各地各企业完全不同的信息化建设目标。IfcXML模式是一个工业标准XSD,利用ifcXML实现数据交换和共享是一个有章可循的过程。IfcXML模型不需要目标服务器来配合工作,一些关系数据库应用系统和服务器可以将XSD当作SQL DDL一样直接读取。

建筑分类体系OmniClass与IFCXML之间的映射

?发布时间:2011-01-19

?文章来源:斯坦福大学

?责任编辑:dpp307

In most industries practitioners use more than one terminology classification class or data model structure. For instance, in the AEC industry, there are a few ontologies to describe the semantics of building models, such as the Industry Foundation Classes (IFC), the CIMsteel Integration Standards (CIS/2), and the OmniClass Construction Classification System. For various model rebuilding and data exchange purposes, comparison and mapping between heterogeneous ontologies in the same industry are often inevitable.

The ontology comparison and mapping problem is commonly performed manually by domain experts, who are familiar with one or more

industry-specific taxonomies. It could be time-consuming, unscalable and inefficient especially if they start from scratch. Automated comparison and mapping based on the ontology structures and the linguistic similarity between concepts are therefore growing in popularity in recent years. This research tries to propose a different approach to achieve ontology mapping by the use of document corpus as a medium for semantic similarity comparison.

Test Case

In the AEC industry nowadays, the urge for Building Information Model (BIM) leads to the establishment of various description and

classification standards to facilitate data exchange. OmniClass and IfcXML by far are two of the most commonly used data models for buildings and constructions. OmniClass, consisting of 15 tables, categorizes elements and concepts in the AEC industry and provides a rich pool of vocabularies practitioners can use in legal documents. It contains a set of object data elements that represent the parts of buildings or processes, and the relevant information about those parts. IfcXML, specialized in modeling CAD models and work process, is frequently used by practitioners to build information-rich product and process models and to act as a data format for interoperability among different software. It is a single XML schema file comprised of concept terms which are highly hierarchically structured and cross-linked. This test case focuses on the mapping between OmniClass and IfcXML.

OmniClass IfcXML

Main Idea and Implementation

With the intuition that related terms should appear in the same paragraphs or sections , concept comparison and matching by co-occurrence is proposed to map different sets of terms in heterogeneous ontologies. The number of co-occurrence of two concepts in the corpus reveals the closeness of the two topics and acts as a means to evaluate the relatedness between them.

Preprocessing

of the two

ontologies,

OmniClass and

IfcXML, is

necessary at

the beginning

stage. The

entity concept

terms of both ontologies are extracted. Unique ID and suffix of the concepts are removed and duplicated concepts are discarded. The entire preprocessed concept terms of OmniClass and IfcXML are latched to each section of the International Building Codes (IBC) XML files. The concept tags, and , are inserted into the corresponding sections which match the concepts in the stemmed form.

In the example showed on the right, the concepts "Concrete" and "Steel Decking" from OmniClass and the concepts "IfcSlab" and "steel" from IfcXML are all matched to the same section 2209.2 of IBC. It implies that they may be potentially related in some aspects. Further confirmation of their relatedness can be deduced by considering their co-occurrence in other sections.

Relatedness Analysis

The number of co-occurred sections of the two concepts and the number of times the two concepts are matched to each of these sections reveal the semantic similarity between the two concepts. Three relatedness analysis measures have been used for concept comparison between OmniClass and IfcXML. They

are cosine similarity measure, Jaccard similarity coefficient, and market basket model. Cosine similarity is a measure of similarity between two vectors of n dimensions by finding the angle between them. Jaccard similarity coefficient is a statistical measure, using set theory, of the extent of overlapping of two vectors in n dimensions compared to union. Market basket model is a probabilistic

data-mining technique to find item-item correlation.

Although in most circumstances related

concepts can be captured by treating each

section as an independent dimension in

concept co-occurrence comparison, some related concepts rarely co-occur in the same sections. Examples are Is-A-related concepts (e.g. "concrete" and "building materials") and concepts that are within the same scope (e.g. "steel" and "concrete"). Corpus hierarchical structure is therefore considered in order to capture those related but not co-occurred concepts. Results

Besides identical concepts such as "curtain walls" from OmniClass and "IfcCurtainWall" from IfcXML, related concepts that cannot be matched by conventional term matching techniques, for instance, "roof decking" from

OmniClass and "IfcSlab" from IfcXML, are captured via this co-occurrence analysis. In the test case, market basket model outperforms other two relatedness analysis approaches in terms of root mean square error (RMSE) as well as F-measure, a combination of precision and recall rate. In fact, the market basket model shows the highest recall rate and a moderately high precision.

Evaluation results of the three measures using RMSE

Evaluation results of the three measures using F-Measure Contributions

This research proposes a new approach to compare and map heterogeneous ontologies, so as to achieve interoperability between data models. It enables information exchange and sharing among project stakeholders. Once the mapping between ontologies is completed, updating and consistency checking of data can also be allowed although the data sources are using different data models.

相关主题
相关文档
最新文档