产品数据模型的背景：数字建筑与增强打印技术带来的成果

随着BIM的出现，AEC应用程序的数量和范围快速拓展，用于设计、制造、建设和建筑营运。交换性的需要只会增加、不会减少。到1980年代中期，几乎所有设计和工程领域的数据交换，都是基于各种固定架构的文档格式，DXF和IGES是众所皆知的例子，它们为2D和3D几何体提供有效的交换格式。然而管线、机械、电气和其他系统的对象模型，在此时被开发，如果要处理复杂对象模型及其几何体、属性和关系的数据交换，任一种固定文档交换格式会变得非常庞大及复杂，以致无法被解读， 欧洲和美国几乎在同一时间出现了这些问题，经过一些交流后，在瑞士日内瓦的国际标准化组织发起了 TC184技术委员会，启动一个小组委员会，制定称为 STEP （STandard for the Exchange of Product Model Data　产 品模型数据交换标准）的标准，编号为ISO-10303，以解决这些问题。他们制定了一套新方法和技术，用以处理高层数据交换的问题。

EXPRESS语言是IS0-STEP的主要产品之一，由Douglas Schenck开发，后来 由 Peter Wilson 补充。EXPRESS 语言已横跨广泛产业范围，成为支持产品建模的重要的机制：机械和电气系统、加工厂、造船、过程计划、家具、有限元素模型及建筑和桥梁。它还包括大量的特征库、几何体、分类、测量和其他等作为产品数据模型的共同基础。支援公制和英制。作为一种机器可读的语言，EXPRESS语言用于计算用途 是良好的，但人类使用却是困难的；因此图形化显示的版本EXPRESS-G被发展出来，并普遍被使用。所有ISO-STEP信息皆属于公开领域。许多软件公司以STEP标准为中心集合起来，提供基于EXPRESS软件的工具包的实施和测试。有些BIM应用程序使用IFC 作为它们的原始数据模型；也就是直接操作（读取和写入）IFC数据。

（1）建筑施工的IS0-STEP

AEC组织最初参加ISO-STEP会议，并且开始一些早期的STEP交换模型。非STEP组织也可以使用STEP技术来发展基于产业的产品数据模型，而这类型的发展则有两种主要的方向。到目前为止，下列相关建筑物的产 品模型已被开发，所有皆基于ISO-STEP技术，并以EXPRESS语言定义：

AP 225—使用具体形状表示的建筑元素：唯一被开发出来且已核准的完整建筑导向的产品数据模型。它处理建筑几何体的交换。

AP 225 在欧洲使用，大部分是在德国，为DXF的替代方法。只有几个CAD 应用程序支持它。

IFC—工业基础类别：一个产业开发的产品数据模型，用于设计和建筑生命周期，由buildingSMART所支持，具有大多数软件公司的广泛支持；它会因各种实施上的不一致性而使其被削弱。之后会有更多关于IFC的讨论。

CIS/2—CimSteel整体标准/第2版：一个产业开发的标准，用以钢结构设计、分析和制作，由美国钢构协会AISC和英国Construction Steel Institute所支持。

AP 241 —AEC设备生命周期支持的原生模型：针对工业设施，并与 IFC功能性重叠；由德国国家委员会（German National Committee）于 2006年提出；目前正在进行新AP的审查。韩国buildingSMART分会也有参与。AP 241的目的是为工厂产品数据模型所订，且他们的组成格式完全和ISO-STEP兼容。

ISO 15926 一个工业自动化系统和整合的STEP标准：处理场生命周期数据的整合，包括石油和天然气生产设施。它解决了整个生命周期，从规划和设计至维护和营运。因为一个处理场是持续要维修的，对象自然是4D。ISO 15926从早期的欧洲共同体 EPISTLE 专案演变而来，并得到 DNV的大力支持。它汇集了各类ISO STEP零件模型，用以2D厂房示意图、厂房实质配置和处理厂的建模。ISO 15926由FIATECH 辖下的公司集团采用，经过改善后，于北美也使用。架构支持立面图 （facades）的概念，类似于模型视图（model views）。ISO 15926仰赖 EXPRESS和其他ISO STEP格式。ISO 15926有7个部分：

第1部分一介绍，生产设施的工程、建设、营运有关的信息，是由在设施生命周期中各种不同组织所建立、使用和修正。ISO 15926的目的是要促进数据整合，以支持生命周期活动和 生产设施的流程。

第2部分一数据模型。一种原生的4D模型，可以支持所有专业领 域、供应链公司的类型和生命周期阶段和功能需求、实体解决方案、对象类型、对象个体、及活动有关的信息。

第3部分一几何体学与拓扑学，定义，OWL中，为ISO-STEP中的几何体和拓扑的数据库。

第4、5、6部分一参考数据。处理产业设施内使用的术语。

第7部分一分配系统整合的实施方法，定义一种以W3C语意学网络建议（Recommendations for the Semantic Web）为基础的执行架构。

ISO 15926的一个重要部分是其大型的数据库（library），涵盖流体、电机和机械组件。

有多个在功能上是重叠的建筑产品数据模型，皆使用：EXPRESS语言。他们在AEC信息中呈现的样貌各有不同，但在用途取向上却有所重叠。IFC 可以代表建筑几何体，AP225和ISO 15926也可。CIS/2和IFC在钢 铁结构的设计上有重叠。ISO 15926和IFC在管线和机械设备领域上有重叠。这些大量投入的分散人力需要协调。

（2）buildingSMART和IFC

IFC已有悠久历史，1994年后期，Autodesk发起一个产业联盟，建议以 C++层次开发的公司能支持开发整合的应用程序。12家美国公司加入此联盟，最初命名为产业交换性联盟（Industry Alliance for Interoperability）， 1995年9月联盟开放会员给所有感兴趣的成员。1997年改名为国际交换性联盟 IAI （International Alliance for Interoperability），新联盟改组为非营利且由业界主导的国际组织，其目标是要发布以IFC作为中立的AEC产品的数据模型，此模型对应到建筑的生命周期。2005年，IAI因为名称太长太复杂，令人难以理解，在挪威举行的IAI执行委员会会议上，IAI被更名为 buildingSMART。关于IFC历史的详述，请见IAI 网站。到了2009年，buildingSMART全球有13个分会，分布于18个国家，约450 个企业成员。所有分会都可以参与领域委员会（Domain Committees），每个委员会解决 AEC的一个范围。目前领域包括：

AR—Architecture

BS一Building Services

CM—Construction

CM1 —Procurement Logistics

CM2—Temporary Construction

CS—Codes and Standards

ES—Cost Estimating

PM—Project Management

FM—Facility Management

SI—Simulation

ST—Structural Engineering

XM—Cross Domain

透过参与领域委员会，成员就可依他们权益相关的部分对IFC做出贡献。不同的国际分会专注于不同的领域。国际理事会执行委员（International Council Executive Committee）会是国际 buildingSMART的整体领导组织。

（3）IFC介绍

IFC是为了 AEC应用程序间的交换，所发展的一种架构，将用来在AEC 软件间，进行交换的建筑数据定义为一组可扩充，且一致的数据表示法。

IFC依靠ISO-STEP EXPRESS语言及其定义的概念，在EXPRESS语言上只有一些小小的限制。当其他ISO-STEP的努力大都集中于特定工程领域内细部的软件交换时，在建筑产业里认为这会导致零碎的结果及一套不兼容的标准。因此IFC被设计为一种可扩展的框架模型（framework model），其开发者期望它能提供广泛的与较通用的对象和数据定义，其中更详细且更具体任务的模型能被定义，这些模型能支持特定的交换。在这方面，IFC已被设计成解决所有建筑信息，包含整个建筑生命周期的所有信息，从可行性和规划、设计（包括分析和模拟）、建设，到入住使用和建筑营运。

到了 2010年，IFC发布了的版本约有800个实体 （entity）、358组属性集（property set）和121种数据类型 （datatype）。虽然这些数字显示IFC的复杂性，它们也反映了建筑信息语义的丰富性，满足多个不同系统，反映多个应用程序的需求，从能源分析和成本估计到材料追踪和进度。IFC的概念结构可以从几方面思考。系统架构底部是26组基本的EXPRESS定义，定义基本的可再使用的构造， 如几何体、拓扑结构、材料、测量、行为者、角色、表现法和属性。这些都是所有类型产品通用的，大部分与ISO-STEP共享数据库资源是一致的，具有少量的扩充性。

基础的实体于是被组成来定义AEC中常用的对象，IFC中称为共享对象。这些包括建筑元素，如基本墙体、楼层、结构元素、建筑服务元素、处理元素、管理元素和基本特征。因为IFC被定义为一种可延伸的数据模 型，并且是面向对象，基本实体可以透过子类别详细说明和特殊化，以生成任何数量的子实体。

IFC数据模型的最顶层是特定专业领域的扩充，对于特定用途则需要这些扩充性来处理各种特殊实体。因此有结构元素和结构分析延伸、建筑、电气、冷暖空调和建筑控制元素延伸。

由于IFC分层对象子形态的结构，使用在交换的对象是以巢状的形式，被嵌在一个深度的子实体定义的树状里。所有实体对象、程序对象、行为者和其他基本构造都以相似的方式抽象地表示，例如一道墙的实体就有一个可向下追踪的树形图，树形图的每个阶层引入了不同的墙体属性和关系：分配Global ID和其他用于管理对象的信息，例如建立者之信息和时间；设置墙归于建筑物楼层组成的集合，同时识别墙的组件，包括门窗和任何其他开口；根据墙类型（于树状图较下层定义）提供其属性链接；定义墙的位置及它的形状；此元素与其他者的关系，如墙周围关系，以及墙所分隔的空间；墙上任何开口及选择性填充它们的门或窗户，假如墙为结构体，一个代表墙的结构元素可以与它相关联。

墙可被分类为以下的其中一种类型：

标准：沿其控制线垂直拉伸，具有固定宽度；

多边形：垂直拉伸但具有变形的断面；

剪切：墙不朝垂直方向拉伸；

单元墙：墙由元素组成，如骨架和覆面板；(www.xing528.com)

管道墙：墙体嵌入管道空间；

使用者自定义墙：所有其他类型；

其他未定义的。

其中许多属性和关系是可选的，让执行者可依其在输出时的习惯，排除掉特定信息。并不是所有BIM设计工具都可以建立或表示所有不同类型的墙。

属性由可选用P-sets来携带。它提供了字段的定义： Identifier （识别者）、AcousticRating （吸音评级）、FireRating （防火评 级）、Combustibility （燃烧性）、SurfaceSpreadOfFlame （表 面 火 焰 蔓 延）、ThermalTransmittance （传 热 系 数）、IsExterior（室外）、ExtendToStracture （延伸到结构体）（至以上楼板）、LoadBearing （承重）、Compartmentation （分区）（防火墙）。如果需要，也能支持其他更详细的P-sets。开口、凹槽和框槽、突出元素如壁柱，也被支持，还支持被不规则天花板裁剪的墙壁。

所有IFC模型提供一个共同常见的建筑空间结构的配置和取得建筑元素。它以项目场地-＞ 建筑物-＞建筑楼-＞空间这样的阶层结构组织所有对象信息。每一级别的空间结构是较低级别的聚合体（aggregation），并横跨较低级别的类别的 任何元素。例如楼梯横跨所有建筑物楼层，因此为建筑物聚合的一部分。墙通常界限一个或多个楼高中的两个或多个空间，如果建模在单一楼层，它们通常是建筑物楼层的一部分；如果建模在跨多个楼层，则为建筑物聚合的一部分。

IFC里有很多类型的组成集，P-sets和可支持结构、机械、其他系统元素的特征等。分析模型、加载数据和产品性能参数也可在某些区域表示。因为IFC能表示大范围的建筑设计、工程和生产信息，使AEC产业之信息交换的可能范围也是巨大的。IFC的每一个新版本都增加了涵盖面并解决局限性，以响应使用者和开发人员的需要。当转换为IFC模型时，所有应用程序定义的对象，会有相关的对象类型和相关的几何体、关系、属性来组成。除了组成建筑物的对象，IFC还包括用来表示活动的程序对象，这些活动是指建造一栋建筑、分析几何体（从建筑几何体获取）、分析输入及结果的属性。

几何体（Geometry） ： IFC具有表示广泛几何体的方法，包括拉伸、由封闭联结体积围绕面组合（B-Reps，边界表示法）所定义的实体以及由形状树和联集交集（Union-intersection）运算所定义的形状（形体的加法和减法和/ 或建模实体几何体）。预设情况下，大多数形状被汇出为B-Reps。曲面可是下列各项所定义：拉伸形状（包括那些沿曲线拉伸的）、贝塞尔曲线、现为非均匀有理的B-spline （NURBS）曲面。一部分的形状可被分类为形状特征。这些几乎涵盖所有建设的需要和大多数的设计需求。IFC几何体被设计为支持系统间的简单参数化模型的交换，如墙系统与其他拉伸形体。但并不是所有所需的信息都是可以被交换的，特别是规则和限制，这导致要交换可编辑的参数模型，需要一些编辑。少数转译器已使用参数化的功能，但是他们的能力才刚被研究。多数交换不需要这一级别 的对象行为细节。

关系（Relations）：关系就是将一个对象分类并与另一个对象产生关系。IFC数据模型已处理了在一些BIM设计软件中的物体之间有着大量关联集合时，在转换为IFC后所呈现方式上的问题。有许多IfcRelations的分类别几乎涵盖任何所需的关系。这是一个定义的复杂领域，并且关系结构随着每个IFC的新版本而被改善。偶尔会出现关于使用它们的问题。

属性（Properties） ： IFC重视的属性集都是被共同使用着的属性集，用于定义材料、特定性能类型、环境属性，如风 能、地质，或天气资料。有收集P-sets用于许多类型的建筑对象，如一般的屋顶、墙、窗户玻璃、窗户梁加固物。此外，许多属性与不同材料行为相关联，如隔热材料、燃烧产物、力学性能、燃料、混凝土、钢筋和其他。

有些属性是没有的。测量缺乏容许误差属性；没有任何明确方法来表示不确定性。在此情况下，有可用选项来定义和描述用户定义的属性集。这些必须由使用者的协议进行管理，因为它们尚未被建置于规范中。

其他的属性可以考虑分类，或从一组枚举值（enumerated value）被选择。空间名称并不具标准化，但为许多类型分析所需的，如能源或建筑规范。因此空间名称通常会需要特殊的编辑。IFC缺乏分析和制作所需之多元化结构元素的功能，但CIS/2定义得很完善。这些包括限制、屈曲的假设、焊接类型、规格。机械系统也有类似的功能限制。原数据（metadata） ： IFC设计师随着时间思考虑有关信息的使用，管理信息所需的原数据。在解决信息所有权、追踪更改、控制、批准，IFC是强大的。IFC也有能力定义限制和描述意图的目标。

在建筑细部级别的细节，IFC具有发展良好的建筑物的对象类别。一般情况下，目前它代表制作和生产所需的详细信息是不太完善的。例如它只是部分解决了混凝土中的钢筋、金属焊缝及规范、混凝土混合和完成物定义、窗户墙体系统的制作详细信息。在更详细的IFC产品架构中，这细节的级别可用以来定义单独一部分，如CIS/2。

将这些不同的描述汇集，用以描述某些设计应用程序所代表的信息，或由建筑物应用程序从其他应用程序或储存库接收。当前的限制绝非说是原有的，确是反映使用者目前优先的需求。如果需要额外处理注意到的限制，可以通过定期安排增加的过程来解决。

（4）IFC 使用的标准

随着AEC产业日趋成熟，交换性的问题已从两个BIM应用程序之间的资料交换，移转到支持工作流程所定义的用例。交换性的主要好处不只是交换的自动化（虽然在另一个应用程序复制数据肯定是多余的行为），但更大的好处是改良工作流、消除步骤、改进流程，以便更好地管理精简工作流。

IFC被开发来响应设计师、承包商、建筑产品供货商、制造商、政府官员和其他人的不同需求，既复杂又耗时。在识别特定交换或任务所 需的信息时，其几何体的多种类型、许多属性和关系的类型都是必需的。因此IFC是高度重复的。任务和工作流程信息的需求，已被公认是成功交换的关键。IFC输出和输入的用户接口按钮是完全不够的， 还需要基于IFC架构子集任务相关的交换，例如一个建筑师的结构导出，用于初步的结构分析或幕墙制造商导出详细的信息给建造师，用于制作等级的协调。这种交换称为模型检视，也就是从数据库检视的概念来制图。这一级别的特定性涉及辨识所要支持的交换，然后指定交换需要的IFC模型检视图。

模型检视图是另一个层面的规范，位于IFC架构之上。美国国家建筑科学协会（National Institute of Building Science， NH3S）和 U_S. buildingSMART 组织已着手执行此添加层的规范。类似的组织在其他buildingSMART分会已采取行动。美国国家BIM标准列出发展模型检视图应遵循的过程。

不管是公开的或是专属的交换，模型检视图期望能定义出一个有效的信息交换。这有助于两端的使用者：输出者知道什么是必需的及不要的，接收者知道什么是可以预期的，可立刻地采取行动。建筑师初步设计预制混凝土外墙立面模型应该包括嵌入窗户的详细信息吗？当外墙立面联结对象是由结构或预制工程师所定义，交换需要什么样的几何体？这样的问题在目前是由试验和错误中解决。最重要的是，模型检视图为执行者定义要被执行的信息，以便导出和输入能紧密结合，降低有关假设性的不适配。这些都是模型检视图定义的用途。目前的目标是定义有效的IFC交换，并顺畅和加速工作流程。至此情况下，模型检视图将会扩大其角色。一定会有定义项目交付不同阶段交接规格的需求与机会，例如从设计到施工、从施工到营运。这些会演变成更精细的交换，并成为专案范围定义的一部分。它们将预期会在合约里订定，并指定为交接的里程碑。然后它们需要被定义，以便于应用程序间的直接交换，公开数据架构的交换。重点是，模型检视图可响应建筑采购上非常重要的需求，远远超出IFC的交换性。

在北美，由于业界的利益关系者们受益于IT的进步和软件公司的支援，所以产业导向所定义的工作流程被认为应该是一种驱动力。由 buildingSMART America 开发的 NationalBIMStandard 标识出需求，并概述指定及执行模型检视图的方法。以下介绍 NBIMS过程的概述

第一阶段：规划

第一步是识别并组成一个产业主导的团体，根据模型检视图定义所需的交换。这些团体通常在大型组织之下组成，指明一套他们希望看到被执行的交换，然后以充足的细节说明这些功能，使它们转化为可以被执行的IFC 构造。

BuildingSMART组织采用一套知名的流程建模语言BPMN，用于模型交换中电子商务的规划和执行。BPMN （Business Process Modeling Notation， 业务流程建模标记，www.bpmn.org）提供了明确的方法来描述活动之间的行为和信息流动，称之为过程图（Process Map）。以下解读一个BPMN过程图的准则。在BPMN网站，有一个用于BPMN形状的插件，Visio的替代方案也列在那里。BPMN过程图的水平列和垂直栏被称为泳道（swim lanes），水平行标识参与交换的专业领域（Disciplines），在专业领域之间的水平行为交换行，这些组织和组合专业领域之间的交换。垂直列标识项目阶段。泳道内建立的单元格中，白色的圆角矩形象征活动。适当的类别行和项目阶段列标识交换的环境背景。每个活动有识别名称，联结到一个更延伸的说明。在活动框内，可能有几个符号横跨底部；一个定向的箭头指明可迭代的活动。一个加号方框表示活动是高级说明，由一组分别的以及按层次架构的活动所组成，BPMN提供高级与细节活动之间的超连接。完整BPMN的图像语法可从www.bpmn.org取得。

交换道的折角方块指定信息交换。灰色信息交换为建筑模型交换；白色的是以文字或语音消息表示的报告。灰色的交换是我们主要感兴趣的，它们被称为交换模型（EMs）。

过程图显示几种不同类型的交换。在第一栏显示了建筑师、工程、建筑产品制造（这里为预制制造商）之间的交换。在此情况下，建筑师释出的BIM模型由工程师和预制制造商审查。根据审查的模型，再反馈有意见和建议的信息回去。这些显然都是单向的交换。

设计发展过程中，有建筑师与工程师之间的另一个交换。在这里，用双向交换的方式传递建筑模型。结构工程师可以根据收到的建筑模型给予更改建议，以指示结构如何协助建筑预制。这是一个双向或反复运算的交换。

对于每个EMs，工作团体提供每个交换内容的详细规范。此功能规范必须决定实体类型、其几何体、属性、细化程度、材料或从一个应用程序传递至另一个所需的过程。方案阶段的最终成果是一份报告，称为信息传递手册（IDM），其确定一组交换集，并且从使用者的角度来定义它们的内容。规范受到完整的审查并由该领域的委员会所批准。

第二阶段：设计

标识在IDM中的交换需求，接下来将会建模为一组信息模块，以做为交换的单元，并设定要被写入执行架构中的交换内容，最常见的是IFC、CIS/2或一个XML架构。此工作由信息科技专家进行，他们与第一阶段的领域专家合作。

当早期小组开始开发模型检视图时，发现他们包括了许多重复的模型构造，例如用以几何体、部件和组成物之间的链接、实体零件和这些零件间的分析结果的呈现方式。重复的规范、实施、测试这些构造是浪费时间的，它们应该被定义一次，执行及测试一次，重复使用。构造以这种方式定义称为概念（Concepts），概念是模型检视图方法论的基础部分，它们是依据用户定义的交换模型中层次结构而绘制出来的，可分解为程序可被实现的模块单元。

种类繁多的模型检视图定义其概念定义分享于开放的网站IFC Solutions Factory，它们可供大众查阅，最重要的是可再利用。如果组构合宜，这些概念对小单元架构模块化而言很可能是很重要的，这些小单元可以重复使用在许多模型检视图定义中。

一套结构完善的模板已被开发用于纪录概念（Concepts），并将它们聚集至更高阶的概念，然后成为单一交换的模型检视图。当填好范本，生成的线上文件会成为模型检视图的规范，并成为第二个主要的文件。模型检视图定义是 IDM （Information Delivery Manual）中所定义需求的履行，并且应该对照IDM检查其概念来验证。目前此项验证是手动完成的。设计时间明订编写的程序（implementation bindings），如 何处理所有的属性，提供模型检视图定义的软件编写规范。

第三阶段：建造

第三阶段由软件公司（应参与整个前面阶段）解决模型检视图定义的程序编写问题，执行第二阶段发展的模型检视图定义规范。它是由强化小型 IFC的测试文档而来的，可用于测试转译器能力。它还需要被小型化、容易执行的设计所强化，以绘图或3D模型形式能够于已验证的建模工具内建造，好让它们可以被输出，输出的文档会被评估，决定建模工具是否能根据模型检视图定义规范导出信息。这些输入和输出的测试，需要涵盖 roM中包含的所有个体差异，并规范于模型检视图定义中。

测试的执行分两个阶段进行，通常称模型检视图验证（Validation）。初始测试是基于模型检视图定义中定义的执行概念，称为单元测试（Unit Tests）。因为所有模型检视图定义应该支持各种状况，所以这些都经过输入和输出测试。一旦单元测试成功完成，较大整合测试是必需的。单元测试和整体交换模型测试都需要严谨的方法，使两个应用程序间交换模型的能力是可以被信任的。认证（Certification）是一项正式称呼，也就是模型检视图定义的执行已通过严格测试，并且使用者可以信赖。

最近模型检视图验证和认证的两个提议已由buildingSMART ISG （International Implementation Support Group）建置在网站上，一个是由慕尼黑技术大学（Institute for Advanced Building Informatics， IABI）所托管的全球测试文档服务器（Global Testing Documentation Server，http：//portaLbau.hm.edu/IABI/leistungsprofil/testplattform），它支持概念和完整模型检视图的输入和输出测试，它被期望作为开发人员的验证和认证测试站，但使用者也可以使用。另一个是IFC Solutions Factory的一部分，主要提供输出交换的测试，并有严格的汇出转译器测试。

第四阶段：部署

最后阶段涉及模型检视图定义的部署和领域使用。这应该由指导原则 （Guidelines）来支持，指导原则纪录模型检视图，及使用者如何在特定BIM工具内正确建立组件模型。这让应用程序的用户知道他们需要做什么准备，好让模型携带交换中所需的信息。此阶段还包括发展项目测试模型，此模型可以用于真实测试。编写程序的认证也被要求，虽然谁将负责认证的组织此问题尚未有定论。

当用程序编写这些以工作流程为基础的特定转译器时，它们会被明确纳入查询而来的转译器中。认证后，这些视图会显著地增加IFC交换的健全性，并且消除如当前所需的事先测试和试用交换。

直到2010年4月前，IFC Solutions Factory指定了用以定义模型检视图定义的23项作为，包括结构分析交换、将竣工数据传送给设施营运、基地规划、法规遵从、数量计算等。模型检视图定义的开发和测试一直是项大工程，而我们才刚开始看到这些努力的成果。IFC Solutions Factory一项重要的优点是，新的模型检视图定义可以逐渐增加先前模型检视图定义概念的重复使用，以用于自身的定义。此外，模型检视图定义执行的模块化最终也可能使它变得容易执行。在未来BIM平台软件的选择窗口里，会有数十个模型检视图定义可供选择。

明显地，模型检视图定义将提供一个新的交换能力基准，并逐渐解决交换性的问题。了解模型检视图定义是以特定程序为基础这件事是有益处的，而且假设交换是稳定又可靠的话，还能有进一步的优势；而有些部分还可以自动进行，也就是不需要由用户导出文档的指令，再由另一个使用者和应用程序来导入文档。可以开始探索一种可以自动导出模型检视图定义到另一个应用程序的装置，作为不同的自动化用途（成本估计、规则检查、分析、空间冲突测试），其结果可以被发送回来。模型检视图定义为强化设计这方面尚未被探索的领域开启了一道通往新层次的门。

模型检视图定义也有更广泛的用途，当各种政府组织采用IFC数据模型，用以法规检查和设计审查（目前GSA、新加坡、威斯康星州正在进行），它将对建筑方面和承包商实践上，具有日益强大的冲击。冲击同时也影响使用者和BIM设计工具开发人员。对于合约图说的完成，在传统做法上会对最后产生的图纸严加规范。这些严谨的规范将大幅增加于建筑模型的建立和定义上，以确保携带足够数据用于法规检查、设计审查和各种类型的分析。可靠地定义这种模型的唯一方法是，如模型检视图定义指定它们的需求。公司得透过事先检查的应用程序，谨慎地准备和操作他们的模型，确保项目模型是适当地被建立，并符合预期使用。这包括在必要的对象类别或群组中（墙为墙体、楼梯走道为楼梯），对象有携带所需的属性集。编辑工具必须要改进它们的功能，以允许自定义对象取得需要的类别结构。在GSABIM的使用中，应用程序已经可以进行事先的检查。例如可以进行空间对象是否完全涵盖墙内楼板的检查，标记上所有需要的类别，并且具有定义其名称和预定功能的属性。

IFC是唯一公开的、非专属的开发完善的数据模型，用于现今存在的建筑物和建筑。正在不断开发一系列的延伸，包括地理元素、预制混凝土和管线、风管以及电气元素。事实上它是全球标准，世界各地不同的政府机构正逐渐正式采用。