ifc 和ifs的区别（IFC技术连载9.IFC标准及实例介绍）

IFC ( Industry Foundation C lasses) 标 准是 Building Smart组织制定的建筑工程数据交换标准。这里重点说明一下 IFC标准的几个特性: 首先, IFC标准是公开的, 任何感兴趣的个人和团体都可以下载相关文档阅读; 其次,IFC标准是面向建筑工程领域的, 主要是工业与民用建筑, 也有科研团体在做着向其他领域扩展 IFC的努力, 例如桥梁工程; 最后, IFC是一个数据交换标准, 用于异构系统交换和共享数据。

在工程项目中, 当需要多个软件协同完成任务时, 不同系统之间就会出现数据交换和共享的需求。这时, 工程人员都希望能将工作成果 (这里就是工程数据 ), 从一个软件完整地导入到另外一个软件, 这个过程可能反复出现。如果涉及的软件系统很多, 这将是一个很复杂的技术问题。如果能有一个标准、公开的数据表达和存储方法, 每个软件都能导入、导出这种格式的工程数据, 问题将大大简化, 而 IFC就是这种标准、公开的数据表达和存储方法。

IFC相关问题

( 1)几种常用文件格式不能支持数据交换和共享吗? 还需要额外的标准格式吗？

目前确实有几种常见的文件格式用做建筑工程领域数据交换, 但它们都有这样或那样的明显缺点。例如有的文件格式虽然常用但却不是公开的标准格式 (例如 DWG ), 有的文件仅限于交换几何数据而缺少工程数据属性 (例如 IGES), 有的标准格式技术架构完整但过于庞大, 不适合建筑工程领域(例如 STEP )。综合来看, IFC 标准是当前最佳选择。

( 2) IFC标准应用范围很广吗?

IFC标准源于欧美, 所以在这些地区应用也较多、较深。随着全球很多国家 (特别是亚洲国家 )的广泛参与, IFC标准逐渐在更多地区得到应用和支持。我国科研工作者较早 ( 1998 年 )开始接触和研究 IFC标准, 逐步完成了技术积累, 正在深入探讨如何在我国广泛推广和应用 IFC标准。

( 3)基于 IFC标准的软件开发容易吗?

由于建筑工程项目本身的复杂性, 决定了基于IFC标准的软件开发也并不容易, 这也是编写此系列文章的初衷所在。基于 IFC标准的软件开发是一个整体的技术方案, 涉及到接口开发、集成策略等很多方面的技术问题, 在后续文章中将会逐一涉及。

通过实例介绍 IFC标准

IFC标准的核心技术内容分为两个部分, 一个是工程信息如何描述, 一个是工程信息如何获取。

IFC标准采用 EXPRESS语言描述建筑工程信息, 这里就有工程中的墙、梁、柱、门、窗等工程信息的描述。 IFC标准推荐使用中性文件作为信息获取手段, 交换工程信息。

IFC的信息描述

IFC标准的当前版本 ( IFC2x4)包含800多个实体定义,400 多个类型定义, 所以没有一个好的引导, 将会很快迷失其中而难于理解。

IFC标准整体的信息描述分为四个层次, 从下往上分别为资源层、核心层、共享层、领域层。每个层次又包含若干模块, 相关工程信息集中在一个模块里描述, 例如几何描述模块。在 IFC标准的定义中, 尽量避免下一层引用上一层的定义, 例如资源层的信息描述不会引用领域层的信息描述, 这样避免由于上层的改动影响整体结构。资源层里多是基础信息定义, 例如材料、几何、拓扑等; 核心层定义信息模型的整体框架, 例如工程对象之间的关系、工程对象的位置和几何形状等; 共享层定义跨专业交换的信息, 例如墙、梁、住、门、窗等; 领域层定义各自领域的信息, 例如暖通领域的锅炉、风扇、节气阀等。

下面以梁的信息描述为例, 逐步介绍 IFC标准中工程信息的描述方法, 以及 EXPRESS 语言的特点。如果想进一步了解 EXPRESS语言, 请参考 ISO10303 PART 11英文文本, 或者 GB 16656 第 11 部分中文文本。

在“共享建筑元素”模块能找到如下梁的信息定义:

ENT ITY IfcBeam；

SUBTYPE OF ( IfcBuildingElement);

END_ENT ITY;

首先, 定义 IfcBean (梁 ) 是一个 ENT ITY (实体 ), 实体是最小的信息组织单位, 作为信息获取的中性文件就是由若干个实体数据 (也可以称之为实体实例 )组成的。假如一栋楼有 1423根梁, 在中性文件里就会有 1423个 IfcBeam 实例。其次, 通过这个定义知道 IfcBeam 是 IfcBuildingElement的 SUB-TYPE (子类型 ), 反过来说 IfcBuildingElem ent是 I-fcBeam的 SUPERTYPE (超类型 ), 这里应用了面向对象语言的特性) “继承 ”。 IfcBeam 继承了来自 I-fcBuildingE lement的内容 (属性、约束等 ), 按照这种继承机制去追述, 从顶层 IfcRoot一直到 IfcBeam一共形成了 7 层的继承关系, 而 IfcBeam 拥有从自身定义开始一直到 IfcRoot的所有内容。

ENT ITY IfcRoot；

GlobalId : IfcGloba llyUniqueId;

OwnerHistory : IfcOw erHistory;

Name: OPTIONAL IfcLabel；

Description : OPTIONAL IfcText；

ENTITY IfcObjectDefinition;

INVERSE

HasAssignments: SET OF IfcRelAssigns FOR

RelatedObjects;

IsDecomposedBy: SET OF IfcRelDecomposes

FOR R elatingObjec;t

Decomposes: SET [ 0: 1] OF IfcRelDecomposes FOR RelatedObjects;

HasAssociations: SET OF IfcRelAssociates

FOR RelatedObjects;

ENTITY IfcObjec;t

ObjectType : OPT IONAL IfcLabel；

INVERSE

IsDefinedBy: SET OF IfcRelDefines FOR RelatedObjects;

ENTITY IfcProduct；

ObjectPlacemen:t OPTIONAL IfcObjectPlacement；

Representation: OPTIONAL IfcProductRepresentation;

INVERSE

ReferencedBy: SET OF IfcRelAssignsToProduct FOR RelatingProduct；

ENTITY IfcElem ent；

Tag : OPTIONAL IfcIdentifier;

INVERSE

HasStructuralMember: SET OF IfcRelConnectsStructuralElement FOR

RelatingElement；

FillsVoids: SET [ 0: 1 ] OF IfcRelFillsElement FOR RelatedBuildingElement；

ConnectedTo: SET OF IfcRelConnectsElements FOR RelatingElement；

HasCoverings: SET OF IfcRelCoversBldgElements FOR RelatingBuildingElement；

HasProjections: SET OF IfcRelProjectsElement FOR RelatingElement；

ReferencedInStructures: SET OF IfcRelReferencedInSpatialStructure FOR RelatedElements;

HasPorts: SET OF IfcRelConnectsPortToElement FOR RelatedElement；

HasOpenings: SET OF IfcRelVoidsElement

FOR Re latingBuildingElement；

IsConnectionRealization: SET OF IfcRelConnectsWithRealizingElements FOR

RealizingElements;

ProvidesBoundaries: SET OF IfcRelSpaceBoundary FOR R elatedBuildingElement；

ConnectedFrom: SET OF IfcRelConnectsElements FOR RelatedE lement；

CotainedInStructure: SET [ 0: 1] OF IfcRelContainedInSpatia lStructure FOR RelatedE lements;

ENTITY IfcBuildingElement；

ENTITY IfcBeam;

按照面向对象方法, 通用的属性位于继承层次的上层 (这里, 继承树是一棵倒树 ), 而专用属性位于继承层次的下层。 IfcBeam 实体本身没有定义任何专有属性, 而从父类继承了 26个属性。 IfcBeam从 IfcRoot继承了四个属性: GlobalId属性的类型是IfcG loballyUN IQUEId, 是一个 22 位固定长度的字符串, 代表全球唯一码; OwnerHistory 属性的类型是IfcOwnerH istory, 而 IfcOwnerHistory本身是个 ENTITY, 这就是实体定义间的引用; Name属性的定义了增加了一个 OPTIONAL标示, 说明这个属性是可选的, 也就是可空, 反过来看, GlobalId和 OwnerHistory没有类似标示, 说明这两个属性必须赋值, 不能为空; Description属性是可选的字符串。 IfcBeam从 IfcObjectDefinition继承的 HasAssignments属性是集合SET, 用来定义实体间的一对多或多对多关系。

IfcBeam 一共有 26个属性, 其中 18个是反转属性。反转属性是 INVERSE关键字之后定义的属性用于明确定义实体实例之间“双向”的一对多或多对多关系。

除了属性定义外, IfcBeam 定义中还包括 (通过继承 )其他定义: UNIQUE和 WHERE。UN IQUE定义属性的唯一性, 例如 IfcRoot中 / UR1 : G lobalId; 0说明 GlobalId属性值是唯一的。WHERE用来约束属性值, 例如 IfcObject中 / W R1 : S IZEOF( QUERY ( temp < * IsDefinedB y | 'IFCKERNEL.IFCRELDEFINESBYTYPE ' IN TYPEOF ( temp ) ) )< = 1; 0说明为 IfcObject的实例指定类型时最多只能指定一个。

最后, 说明一下梁的位置和几何形状如何表达。在 IfcProduct定义中, 属性 ObjectP lacem ent表示位置 (也可以说是定位 ), 属性 Representation表示外形 (这包括几何形状 ), 由于 IfcBeam是 IfcProduct的子类型 (尽管不是直接子类型 ), 所以 IfcBeam 也有了位置和形状信息。从这个定义可以看出, 所有IfcProduct的子类型都用相同方法定义位置和形状,而建筑工程中应用广泛的墙、梁、柱、门、窗等, 在IFC标准描述中都是 IfcProduct的子类型。

介绍到这里, 可以看出 EXPRESS语言的一些特点。它是一种数据描述语言, 其核心作用是描述数据及其关系, 所以包括了像 UNIQUE和 WHERE这样的语言要素。对比之下, C、C 、Java等是实现语言, 它们包含更多的是计算机指令。这是他们的本质区别。

IFC的信息获取

从技术方法上分, IFC信息获取可以有两种手段, 一种是通过标准格式的文件交换信息, 另一种是通过标准格式的程序接口访问信息。在实际应用中, 第一种方法, 即通过文件交换是主流, 特别是中性文件格式, 目前 XML文件用得还很少。如果想进一步了解中性文件格式, 请参考 ISO 10303 PART21英文文本, 或者 GB 16656 第 21部分中文文本。

中性文件是一种纯文本文件格式, 用普通的文本编辑器就可以查看和编辑。文件以 / ISO-10303-21; 0开头, 以 / END-ISO-10303-21; 0结束, 中间包括两个部分: 一个文件头段和一个数据段。文件头段以 /HEADER; 0开始, 以 / ENDSEC; 0结束, 里面包含了有关中性文件本身的信息, 例如文件描述、使用的 IFC 标准版本等。数据段以 / DATA; 0开始, 以/ ENDSEC; 0结束, 里面包含了要交换的工程信息,要举例的 IfcBeam实例数据就包含在这里。

前文说过, 在 IfcBeam 的定义中一共包含 26个属性, 还有一些 UNIQUE和 WHERE属性约束描述,中性文件规定所有的反转属性和 UN IQUE、WHERE都不在中性文件里面表示, 中性文件只按照定义顺序表达一般属性, 具体的方法如图 2所示。图中将IfcBeam 的 8个一般属性压缩到一起用一个 ENTITY定义表示, 并将其与中性文件中的数据实例对应起来。

从图中不难看出 IfcBeam 定义与中性文件格式之间的对应关系。首先, /# 530是这个实例的实例名, 其他实例要引用这根梁时, 就用这个实例名, 不同 实 例 的 实 例 名 在 中 性 文 件 里 不 重 复。

/IFCBEAM 是实例关键字, 说明后面括号里的属性值是定义一根梁的。属性值之间用逗号隔开, 其出现顺序按照属性定义的顺序排列, IfcBeam 的顶层超类IfcRoo t定义了第一个属性 GlobalId, 其次是 OwnerH istory、Name、Description属性, 再往下是 IfcObjectDefinition定义的属性, 然后一直到 IfcBeam 自身定义的属性。如果某个属性没有赋值, 也就是为空,就用作为占位符, 对应这个例子, 这根梁的 Name、Description、ObjectType等几个属性没有赋值, 用代替。如果这个实例的 G loba lId属性也用代替, 就违反了 IFC 标准的定义, 因为这个属性不是可选的(没有用 OPTIONAL关键字修饰 )。

ObjectPlacement、Representation、OwnerHistory等属性引用了其他的实例, 所以对应位置上用实体名表达。

用集合 Set、列表 List、数组 Array表达的组合类型属性, 在中性文件中一律用括号加上属性列的形式表达。例如# 37实例, 它的第三个属性是个集合,里面包含了对另外两个实例# 36、# 52的引用。

,