随着 20 世纪 90 年代数字数据的出现，建筑行业开始积极转型。计算机技术被引入到设计、管理和施工过程中，从而产生了 CAD（计算机辅助设计系统）、PLM（产品生命周期管理）以及后来的 BIM（建筑信息模型）等概念。
然而，与任何创新一样，它们并不是发展的终点。BIM 等概念已成为建筑业发展史上的一个重要里程碑，但它们迟早会被更好的工具和方法所取代，从而更好地应对未来的挑战。
由于受到 CAD 厂商的影响和自身实施的复杂性的困惑，2002 年出现的 BIM 概念很可能活不过 30 岁生日，就像一颗闪亮的摇滚明星，昙花一现后又迅速陨落。原因很简单：数据专家的需求变化速度比 CAD 供应商更快。
面对缺乏高质量数据的问题，当今建筑行业的专业人士要求实现跨平台互操作性和开放数据访问，以便于分析和处理。数据的缺乏及其复杂性对参与施工过程的每个人都产生了负面影响：设计师、项目经理、现场施工人员以及最终的客户。
如今，客户和投资者收到的集装箱格式并不是一套完整的操作数据，而是需要复杂的几何内核、对数据模式的理解、每年更新的 API 文档和专业的 CAD-BIM 软件才能使用的数据。与此同时，大部分设计数据仍未得到利用。
这种方法已经过时，不再符合当今数字化环境的要求。未来的公司将分为两类：有效利用数据的公司和退出市场的公司。
在本文中，我们将探讨现有的 BIM 框架，包括 CAD (BIM)、IFC 和 USD 格式的使用，以及数据和流程的替代和未来工作方法，并回答当今建筑行业数据专业人员感兴趣的关键问题：
- 什么是 BIM--是市场营销还是建筑业的真正创新
- 为什么 CAD 格式会扼杀互操作性和 BIM 概念？
- 美元与国际金融公司：供应商为何强加新格式？
- 为什么 CAD 供应商提供的新格式 IFC 和 USD 无法解决关键的互操作性问题？
- 为什么 CAD 供应商要放弃文件，从 2023 年开始转向粒度数据？
- 为什么参数化 CAD 格式和 BREP 几何图形对建筑业并不重要
- Strabag 和 Züblin 如何挑战 CAD 供应商及其结果
- 在数据管理中使用语义和本体的不足之处。
- 建筑企业为何反对使用开放数据
- 未来处理建筑项目数据的工具是什么？
非常感谢 Rasso Steinmann、Thomas Liebich、Ulf-Günter Krause、Bernd Müller-Jürries、Simon Dihlas、Michael Maass 以及亲爱的 building-SMART、OSArch 社区和 DataDrivenConstruction 聊天室成员就所提出的问题进行了宝贵的讨论和辩论。
🔗 原创文章：后 BIM 世界。向数据和流程过渡，建筑业是否需要几何内核、语义、格式和互操作性
内容
- BIM 是关于数据和流程的，但为什么要用缩写呢？
- 每个 CAD（BIM）数据用户为十个数据消费者提供服务
- 任何 CAD（BIM）程序都是一个数据编译器，通过几何内核将几何图形可视化。
- CAD、IFC 和几何内核：谁说了算？
- IFC 是 CAD 中的 CAD，依赖于几何内核和 SDK
- 为什么建筑商需要几何图形？当线条变成金钱
- 建筑或从线条到体积的基本计算：面积和体积如何变成数字
- 为什么需要三角形？关于建筑中的细分曲面的全部真相
- Zublin-Strabag 试图让 CAD (BIM) 供应商服从于建筑行业的利益
- 语义学和本体论在建筑业的兴起
- 语义和本体：如何让数据说话？
- 从图到表：分组和筛选中的人工成本
- ISO 和 building-SMART 的阴影：争夺数据格式控制权的战争
- 为什么建筑商和客户需要控制数据？
- 优步化和开放数据是对建筑业的威胁
- BIM、openBIM、BIM Level 3 和 noBIM 是否真的存在，还是营销噱头？
- 下一步是什么？简单的格式和用户友好型工具
- 项目数据流程中出现的 LLM 和 ChatGPT 代替结论
1.BIM 是关于数据和流程的，但为什么要用缩写呢？
随着欧特克公司 2002 年发布 BIM 白皮书，BIM（建筑信息模型）的概念在建筑行业重新兴起，并与机械工程的 BOM（物料清单）概念相辅相成，它起源于创建和处理项目数据的参数化方法。创建和处理设计数据的参数化方法最早是在用于机械工程设计（MCAD）的 Pro/Engineer 系统中实现的。该系统成为许多现代 CAD 解决方案的原型，包括当今建筑行业使用的 CAD 解决方案。
图 1 Revit、Solidworks、Autocad 和白皮书 BIM 产品出现的历史
PTC创始人、MCAD产品Pro/ENGINEER开发者、Revit创始人Leonid Reitz的导师Samuel Heisenberg的名言：
我们的目标是创建一个足够灵活的系统，鼓励工程师轻松考虑不同的设计。而更改设计的成本应尽可能接近于零。当时的传统 CAD/CAM 软件不切实际地将成本低廉的修改限制在设计流程的初始阶段
早在 20 世纪 80 年代末期，人们就开始致力于消除现有 CAD 程序的局限性。主要目的是减少更改设计元素参数所需的人力，并使根据 CAD 程序之外的数据更新模型成为可能。在这种情况下，任务参数化和从数据库自动输入参数以更新 CAD 系统中的模型将发挥关键作用。
在欧特克完成对 Revit 的收购后（Revit 继承了 Pro/ENGINEER 的 BOM 概念），欧特克的两位副总裁编写了一份白皮书，标志着 BIM 概念于 2002 年进入建筑行业。
图 2.2002 年 BIM 白皮书的出现
欧特克在其网站上发布了一份关于 BIM 的白皮书，实际上是在复制 20 世纪 90 年代初使用的 Pro/ENGINEER 产品中有关 BOM（物料清单）概念的营销材料。
BIM 被描述为建筑信息管理，所有更新和更改都在数据库中进行。因此，无论您处理的是示意图、剖面图还是图纸，一切都始终是协调、一致和最新的。
几乎所有用于添加和处理建筑参数的现代概念，如 IFC、BIM、openBIM 和 building-SMART，在创建过程中都得到了 CAD 解决方案提供商的支持和推广。然而，其中许多想法都是从其他行业借鉴或从初创公司获得的。例如，欧特克（ADSK）公司并不是自己创建了 Revit、BIM 概念、AutoCAD Architecture、Navisworks、Civil 3D 和 Advanced Steel，而是从初创公司那里收购了这些解决方案。
同样，building-SMART 也没有创建 IFC 格式或 openBIM® 缩写。IFC 由慕尼黑工业大学从机械工程格式 STEP 改编而来，后来由 HOK 重新命名，创建了 IAI 联盟，而 openBIM 在 2012 年由几家 CAD 供应商首次注册后，直到 2020 年代初才由 building-SMART 重新命名为商标。而 IFC-STEP 格式则是基于 IGES 格式，IGES 于 1979 年由一群 CAD 用户和供应商在 NIST 和美国国防部的支持下创建。BIM 的历史 "地图中展示了开发者与现代概念的想法之间的联系。
图 3.CAD (BIM) 解决方案开发人员主要团队的联系图
作为核心工具和概念的源头，机械工程正逐渐从使用 CAD、CAM 和 PLM 术语转向数字孪生和端到端数据管理流程。设计、制造和运营流程不再从特定工具（PTC、西门子和达索系统等公司提供的工具）的角度来看待，而是通过统一的方法来处理数据和流程。数据管理、流程管理和数据分析的概念正在被越来越多地使用，而不是 BOM、PLM 或 PDM 等专业术语。从软件供应商的狭义缩写到以 "数据 "和 "流程 "为主导的通用概念，这种转变不仅出现在机械工程和其他行业。
与其他行业的用户和开发人员一样，建筑行业的用户和开发人员也将不可避免地摆脱过去 20 年中占主导地位的模糊的软件供应商术语，将注意力集中在数字化的关键方面--"数据 "和 "流程"。
图 4.施工流程和设计与数据和流程密不可分
如果不能自由获取高质量的结构化数据，未来就不可能建立高效的流程并实现自动化。因此，首要任务是发现、组织、统一和整理数据，这将为业务流程的自动化和优化奠定基础。
为了了解当前 CAD-BIM 数据和流程管理概念的复杂性和混乱性，我们将探讨创建填充设计数据的几何体和元信息的基本原理。这将回答为什么过去 30 年来，设计数据的使用、自动化和标准化一直是个难题。
2.每个 CAD（BIM）数据用户为 10 个数据消费者服务
如果说在本世纪初以前，以数字形式存储的数据所占的比例还非常小，而且在其他系统中使用这些数据的问题几乎没有被提出来，那么由于 CAD (BIM)、PLM、ERP、Excel 和基于 SQL 的应用程序的出现，今天的情况已经发生了巨大的变化。消耗数据的系统数量增长了十倍，这给需要接收、处理和传输数据的管理人员和专家带来了真正的危机。
图 5.建筑公司生态系统中的数据和流程整合方案
自 21 世纪初以来，参与维护各种用户界面系统和数据库的办公室员工数量成倍增长，导致数据访问和共享的重要性急剧增加。正如欧特克公司首席执行官在 2002 年指出的那样，在本世纪初，每一位 CAD 工程师都至少有十几位其他专家需要处理 CAD 系统中创建的数据（引用）：
你需要能够管理所有数据（CAD--笔者注），以数字方式存储这些数据，并销售生命周期和流程管理软件，因为每有一位工程师创造出某种东西，就会有十个人需要处理这些数据。
到 2020 年代初，处理 CAD 和 BIM 程序数据的专业人员数量成倍增长，大公司中的专业人员达到数百人，从地理信息系统（GIS）、企业资源规划（ERP）和 CAFM 系统管理员到建筑工地领班。
图 6.每名工程师有数十名专家在 CAD（BIM）程序中创建数据
建筑行业的所有这些用户及其数据管理人员都在努力实现不同程序和平台，特别是数据库和数据格式之间的完全兼容。尽管建筑行业几乎所有的系统和数据库都对工程师和 IT 专业人员开放，但只有计算机辅助设计（BIM）仍然是采用专有格式的封闭式数据库。在过去的 30 年中，这些封闭的项目信息前哨影响了数十个其他部门和数百名专业人员，造成了对有限信息访问的依赖。
真正的跨平台和互操作性面临着一个根本问题，即 CAD 程序的封闭性和复杂的专有几何内核、第三方 SDK 工具以及它们在专有格式中使用的各种数据模式。
图 7.在所有数据库中，只有 CAD（BIM）仍然无法访问
为什么在建筑中需要 CAD（BIM）系统？根据维基百科的定义，其主要任务是帮助设计师根据项目任务的初始参数创建新数据，其中包括设计元素的几何形状和相关元信息：
建筑信息模型（BIM）是一种创建和管理建筑物和其他物体的物理和功能特征的数字表示方法。
大多数 CAD（BIM）系统使用封闭式数据库和专有存储格式来创建和存储这些特征和参数。此外，它们还使用复杂的专有几何内核，提供项目几何的可视化和交互式互动。
3.任何 CAD（BIM）程序都是一个数据编译器，通过几何内核将几何图形可视化。
每个 CAD（BIM）程序要么使用自己的几何内核，要么依赖于第三方专有解决方案，这使得不同平台之间的数据交换变得非常复杂。
任何 CAD（BIM）程序都是使用几何内核显示的几何数据的编译器。
西门子 Parasolid、达索系统 CGM、PTC ProEngineer、ADSK ShapeManager 和 ASCON C3D 等几何内核在市场上占据主导地位。唯一免费的开源几何内核是 OpenCascade 和 GPL 许可证下的 CGAL 库。
图 8.CAD/BIM 系统工作流程架构：从代码库到可视化
在处理简单的几何元素（如直线或平面）时，使用参数绘制几何图形没有任何问题。但是，在处理复杂或复合元素时，情况就会发生变化。即使输入参数相同，不同的几何内核也会因其操作和处理算法的特殊性而产生不同的结果。因此，在不同的 CAD（BIM）产品中，以参数几何形式保存的项目几何实体将以不同的方式显示。
图 9.使用不同的几何核时，不同的输入参数模型会产生不同的结果
对于大多数 CAD 供应商来说，参数几何层面的完全跨平台兼容性仍然无法实现。这是因为系统几何内核中使用的算法缺乏标准化，而这些算法通常不属于 CAD 厂商（更多的是 MCAD 厂商），同时还需要创建开放的交换规范和开发通用的转换器。目前，只有包括 OpenCascade、开放设计联盟和 CADExchanger 在内的少数倡议正在应对这些挑战。从历史上看，转换和统一多格式数据的计划一直受到 CAD 供应商的巨大压力。然而，许多冲突都以诉讼告终，判决结果对供应商不利。
让我们来了解一下为什么在数据处理中需要几何内核，因为数据处理非常复杂，甚至 CAD（BIM）系统开发人员都不得不求助于第三方供应商和开发人员来解决和开发。
4.CAD、IFC 和几何内核：谁说了算？
几何图形的可视化和处理需要几何内核。CAD (BIM) 系统中最常见的几何表示方法之一是边界表示法（BREP 或 B-rep）。
BREP（边界表示法）是一种通过边界参数（曲面、边和顶点）描述物体几何形状的方法。
其他几何表示形式，如 CSG 和扫掠实体，用于 IFC 格式和 CAD 程序的内部容器，在某些任务中也有应用。然而，由于其通用性，BREP 是几何表示的主要形式，并已成为 CAD（BIM）环境中大多数工程和建筑解决方案的标准。
在任何 CAD 程序中，用户在程序界面上点击鼠标选择点或线等操作都会通过几何（数学）内核转换为 BREP，并在程序窗口中显示为成品形状。
但是，由于每个 CAD 厂商都使用自己的几何内核和独特的代码库（通常由数千万行组成），因此在程序之间传输 BREP 参数并不能保证它们在另一个 CAD 系统中得到完全相同的表示。
图 10.使用元素形状的几何核从 BREP 参数中得出的结果
IFC 格式中的 BREP（边界表示法）不是一种基本格式，因为它是参数化描述的，没有使用特定或现有的几何内核。这就造成了在使用不同几何内核的不同软件产品（如 CAD（BIM）程序中使用的 OpenCascade、Shape manager 和 Siemens Polarsolid）中，对同一参数化 IFC 模型的解释不同的情况。
在创建真正的跨平台互操作性的过程中，一个关键因素可能是创建一个通用的几何核心，并将元素的参数绑定在这个核心上。这将确保在任何 CAD（BIM）系统中都能正确理解相同的几何图形。
因此，要么 building-SMART 拥有自己自由开放的几何核心，要么 IFC 格式的同一 BREP 元素在不同的工具和程序中将继续以不同的方式显示。
IFC 本身可以看作是 CAD 中的 CAD 或计算机辅助设计系统的骨架，但 30 年来，IFC 并未正式出现。
5.IFC 是 CAD 中的 CAD，依赖于几何内核和 SDK。
IFC 格式使用不同的几何图形表示方法，如 CSG 和扫掠实体，但 BREP 也已成为以 IFC 格式传输特征几何图形的主要标准，因为这种格式在从 CAD（BIM）程序导出时受到支持，并允许在将 IFC 导入 CAD 程序时对特征进行潜在（仅在试验性产品中实现）编辑。
在大多数情况下，如果 IFC 中的几何体是参数定义的（BREP），那么仅凭 IFC 文件就无法获得项目实体的体积或面积等属性，因为在这种情况下，要处理几何体及其可视化，就需要几何体内核，而几何体内核最初是不存在的。
要在任何程序中支持 IFC，实际上都需要在现有解决方案中创建另一个理想的 IFC CAD，它有自己的几何核心和自己的几何工作逻辑。
图 11.是否有可能统一 CAD 供应商使用的几何内核和 SDK？
虽然 IFC-BREP 格式中的原始元素可能没有问题，但除了不同几何内核引擎的问题外，还有足够多的元素有其自身的特殊性，无法进行正确的映射。2019 年出版的国际《IFC 软件支持参考研究》将详细讨论这一问题。引用：
同样的标准化数据集产生了不一致的结果，很少有可检测到的共同模式，而且在标准支持（IFC--作者注）方面也发现了严重的问题，这可能是由于标准数据模型非常复杂所致。标准本身也有部分责任，因为它们往往对一些细节未加定义，自由度很高，可能会有各种不同的解释。这些标准使得对象的组织和存储非常复杂，不利于有效的普遍理解、独特的实施和一致的数据建模。
对 "某些条款 "的正确理解只有 building-SMART 的付费会员才能获得，而且往往是在幕后讨论中获得。因此，想要获得有关 IFC 某些特性的重要知识的人都会尝试与大公司合作，或者通过自己的研究来获得。摘自对 CAD 程序 Renga 开发人员的采访：
您遇到了一个关于通过 IFC 格式导入和导出数据的问题，并询问其他供应商："为什么要以这种方式在 IFC 文件中传输有关房舍参数化转移的信息？building-SMART 的开放式规范对此没有任何规定"。来自 "更有见识 "的欧洲供应商的回答："是的，没有说，但允许这样做"。
图 10：同一个 IFC 项目在不同的 CAD (BIM) 程序中会产生不同的结果
只有大型开发团队才能实现几何内核中 IFC 参数映射和生成的所有功能。因此，目前 IFC 格式的功能和复杂性主要对 CAD 供应商有利，与微软的 "采用、扩展、摧毁 "战略有很多共同之处，标准的日益复杂实际上为较小的市场参与者制造了障碍。微软的战略是改编开放标准，添加自己的扩展和功能，使用户对其产品产生依赖，然后赶走竞争对手。长期以来，微软一直强加自己的标准（如 Internet Explorer），这减缓了 CSS、HTML5 或独立浏览器等更先进和通用技术的采用。
因此，目前只有大型 CAD 供应商能够投入大量资源，支持所有实体及其与内部几何核心的映射，才能完全实施 IFC 本体。大型供应商也有能力协调他们之间的特征技术细节，而这些技术细节可能连最积极的 building-SMART 参与者都无法获得。
在 IFC 软件支持参考研究中进一步了解使用 IFC 格式的开发团队所面临的挑战
图 12：关于 IFC 格式跨平台性的国际研究
对于希望支持互操作格式开发的小型独立团队和开源项目来说，缺乏自己的几何内核是一个严重的问题。没有几何内核，几乎不可能考虑到与跨平台数据交换相关的所有微妙之处和细微差别。
目前，流行的 openBIM 工具（如 IfcOpenShell、BlenderBIM-Bonsai、IFC.js 和 FreeCAD）底层唯一广泛使用的开源核心是 OpenCascade。然而，它也有其局限性。building-SMART 组织没有影响 OpenCascade (OCC) 开发和许可的直接工具。从历史上看，OCC 开发团队以下诺夫哥罗德为中心，但近年来，一些 OCC 专家已迁往葡萄牙，而团队中更大的剩余部分则专注于开发 OpenCascade (OCC) 项目的一个分支，该分支以中国新的开源几何内核 OGG 为品牌。
我们为什么需要在建筑中使用来之不易的几何图形，我们需要参数化形式的几何图形吗？
6.为什么建筑工人需要几何图形？当线条变成金钱
除可视化外，几何图形还可根据项目实体对象的形状自动计算面积和体积等关键体积特征，对现有的元素参数列表进行补充。这些参数是后续计算、计算和分析的基础，因此起着至关重要的作用。
几何图形的自动计算成为问题参数形式的抽象数据与其物理实现之间的纽带。
几何学历来是工程交流的基础，它提供了计算长度、面积和体积的能力。从最早的纸莎草纸图纸到现代的数字格式，图纸一直是工程师、领班和估算师之间沟通材料和工程量信息的重要工具。千百年来，直到 20 世纪 80 年代，估算人员都是仅凭直观图，使用直尺和量角器作为主要测量工具，手工收集数量和体积数据。
图 13：建筑业务流程中几何数据的主要用途
随着计算机技术的发展，现代 CAD（BIM）工具中的体积建模技术使计算体积特征这一费时费力的手动工作得以完全自动化，从而使您可以自动获取任何元素的体积属性，而无需使用计算器手动计算这些值。
在 CAD 程序中，通过 CAD-BIM 程序的用户界面创建用于计算的几何元素。为了将点和线转换为体积体，需要使用几何内核。几何内核的主要任务是将几何体转换为体积模型，经过近似处理后，自动计算出元素的体积。
图 14：在 CAD（BIM）系统之外实现几何形状可视化的途径
就像几千年前建造金字塔时使用肘尺和立方尺进行测量一样，如今在 CAD 程序中，几何解释的准确性也起着关键作用：项目预算计算的准确性、成本的正确确定以及工程的时间安排，这些都取决于几何解释的准确性，而这些正是任何建筑项目的基础。
精确计算是建筑行业生存的关键因素。在竞争激烈的环境中，获得高质量的工程量数据对于成功实施项目和保持竞争力至关重要。
如果准确的计算在确定项目的资源、材料和时间参数方面起着关键作用，那么了解这些计算的具体方法就非常重要。
7.建筑或从线条到体积的计算基础：面积和体积如何变成数字
在实践中，三角测量法通常用于计算分析定义的几何曲面的面积和体积，或通过 BREP 中的 NURBS 计算，它可将复杂曲面转换为三角形网格。
NURBS（非均匀有理 B-样条曲线）是一种描述曲线和曲面的数学方法，而 BREP 则是一种描述物体完整三维几何形状的结构，包括其边界，可以使用 NURBS 进行定义。
即使曲面是通过分析或 NURBS 方法给出的，它也通常是通过细分曲面近似得到的，因为通过积分或复杂分析方法进行的精确计算因其复杂性和高计算成本而在实践中很少能实现。
细分曲面的本质是将复杂的曲面分解为更简单的元素--三角形或多边形。这种方法用于曲面和体积计算、屏幕可视化、导出为 MESH（"网格"）等格式以及碰撞和碰撞分析系统。在游戏中，细分网格被用来创建逼真的景观，在 CAD/CAE 系统中，细分网格被用来进行计算和可视化。蜜蜂蜂巢就是自然界中细分法的一个例子。
图 15：BREP 和球体的多边形表示法
计算机辅助设计（包括 BIM 系统）中使用的 BREP（NURBS）并不是基本的几何模型。这种方法是作为表示圆和有理花键的便捷工具而创建的。但是，它也有局限性，例如，无法准确描述螺旋线和曲面的正弦曲线。因此，BREP（NURBS）仍然只是一种近似方法，而不是描述几何的基本手段。
相比之下，三角形网格和参数细分的特点是简单、内存使用效率高，并能处理大量数据。这些优势使得计算几何图形时无需复杂昂贵的几何内核和数亿行代码。
图 16.圆柱体和立方体细分示例
在建筑行业中，如何确定体积特征并不重要--是通过内部 CAD 或 IFC 格式的参数模型，还是使用 USD、glTF、DAE 或 OBJ 格式的简化几何表示法。
定义为多边形或 BREPs（NURBS）的几何图形是近似连续形状的方法。正如菲涅尔积分没有精确的解析表达式一样，通过多边形或 NURBS 进行几何离散化始终是一种近似方法，就像三角形 MESH 一样。
多边形 MESH 和参数 BREP 都有各自的优势和局限性，但目标是一致的，即在考虑到用户任务的情况下，高效、方便地描述几何图形。最终，几何模型的准确性不仅取决于其表示方法，还取决于特定任务的要求。
图 17：不同多边形数量的图形的体积特征差异
BREP 格式的参数化几何图形主要在以下情况下是必要的：需要最小的数据量，并且可以使用资源密集型和昂贵的几何图形内核进行处理和显示。最常见的情况是，CAD 程序为此使用 MCAD 供应商的几何内核。
在大多数建筑应用中，对参数几何和复杂几何内核的需求很少，除非 CAD 供应商本身或开发这些工具的几何内核供应商宣传其重要性。
因此，在 CAD (BIM) 程序内部，参数几何体（BREP、RVT、IFC、PLN）仍通过细分过程转换为 MESH 三角形和多边形进行计算。在 CAD (BIM) 环境之外，大多数情况下，三角化的 MESH 几何图形（USD、SVF、glTF、CPIXML、DAE、NWC）也用于可视化、计算和碰撞搜索，因此对参数几何图形的需求更加不明显。
那么，应该选择哪种格式作为数据交换的标准呢？IFC 是合适的交换格式--三角形 IFC-MESH（gLTF、OBJ、DAE、SVF）还是参数化 IFC-BREP（RVT、PLN、DGN）？
8.为什么需要三角形？在建筑中使用三角形
特定的 CAD（BIM）程序不应成为成本计算部门和施工现场使用的交换格式的基础。几何信息应直接以格式呈现，而无需参考几何核心或 CAD 架构。
在建筑行业，在使用设计数据的系统和数据库中，应尽量减少对 CAD 编辑器和几何图形内核的依赖。
CAD 程序中的几何参数可作为流程的一部分，但只能作为输入数据，而不能作为交换格式的基础。这是确保几何描述的通用性和独立性的唯一方法。大多数参数几何图形（包括 BREP 和 NURBS）都会转换为三角形网格（细分），以便计算和可视化。细分之后，得到的仍然是三角形网格。如果最终看不出区别，为什么要把过程复杂化呢？
参数格式不是基本格式，相反，OBJ、STL、gLTF、SVF、CPIXML、USD 和 DAE 等格式仍然是基本格式，因为它们使用简单通用的三角形 MESH 结构。这种结构在计算机图形架构中易于理解且高效，无需额外的几何内核和数千万行代码即可实现可视化或元素计算。
图 18：几何体从参数格式到多边形表示的转换
由于 IFC 解释和几何内核差异的问题，所有 CAD 供应商无一例外都使用逆向工程 SDK 在不同供应商的解决方案之间传输数据，没有人使用复杂的 IFC 或 USD 格式来实现互操作性。
在上周的文章（《变革时代：IFC 已成为过去，为什么欧特克和其他 CAD 供应商愿意放弃 IFC 转而使用 USD 的 14 个关键事实》中，我们讨论了新的 AOUSD 联盟中的 CAD 供应商从 2023 年起提供的 MESH USD 格式：IFC 已成为过去，欧特克和其他 CAD 供应商为何愿意放弃 IFC 而采用 USD 格式的 14 个关键事实）中所讨论的那样，MESH USD 格式有可能成为取代专有格式中参数化几何体的新标准。它还可以作为在 IFC 中描述 BREP 几何图形的一种手段，而 CAD 供应商自己迄今为止尚未做到这一点。
但是，与其使用 CAD 厂商联盟推广的概念，而这些厂商自己并不使用这些概念，不如集中精力了解每种方法在特定情况下的优势，并根据使用情况选择一种或另一种几何图形，这样会更有成效。
要在不同的几何表示法之间做出选择，就必须在精确度、计算效率和特定问题的实际需要之间做出权衡。
图 19：具有不同多边形数量的网格 BREP 球体
CAD 供应商在处理设计数据时强加给建筑行业的复杂性和几何内核的使用可能根本没有必要。带有 MESH 几何图形的 USD 格式对建筑行业来说可能是一个潘多拉魔盒，它为设计人员开辟了 IFC 和 BREP 数据交换的替代方法。事实证明，还有其他更简单、更开放的格式，可以在 CAD（BIM）工程师和其他数十名专家之间提供高质量的交互。
最流行的建筑企业资源规划系统之一--ITWO/MTWO--就是在建筑公司业务流程中有效应用 MESH 几何图形的一个实例。早在 2000 年代中期，这款由施耐德电气和 RIB 软件组成的法德联合公司拥有的产品就展示了 MESH 格式与简化元信息存储方案的应用。ITWO/MTWO 使用专有但可读的 CPIXML 格式，而不是 IFC 和 USD 格式。
iTWO/MTWO ERP 系统开发的幕后推手是建筑公司 Strabag，更具体地说是其位于斯图加特的子公司 Züblin。正是 Züblin 发起了 iTWO 的开发，当时 iTWO 的定位不仅是一个 ERP 系统，还是一个 4D-5D BIM 国际平台--将设计数据与进度计划和估算集成在一起。
9.Zublin-Strabag 试图使 CAD（BIM）供应商服从于建筑业的利益
Züblin-Strabag 是欧洲最大的建筑公司之一，对建筑流程的各个阶段都有深刻理解。2023 年，STRABAG SE 的营业额将达到 176.7 亿欧元。相比之下，包括 ADSK 在内的 CAD 软件公司 2021 年的全球市场总规模约为 185.4 亿美元。
位于斯图加特的 Zublin (Strabag) 和 RIB 软件公司的开发人员能够为基本 CAD 程序创建插件转换器，以 OBJ 格式 CPIXML（类似于 USD）获取几何数据并进行网格划分。因此，除了 CAD 程序本身已获得的数据外，这种三角化几何图形还能在 CAD (BIM) 程序之外，以 ERP 表格形式根据原始 MESH OBJ 几何图形计算出 150 多种不同的体积特征。在以 15 亿欧元的价格将 ITWO 出售给法国施耐德电气公司后，Züblin (Strabag) 专注于为建筑行业的互操作性开发新产品。
图 20：祖布林-斯特拉巴格燕子的历史和 OGG 几何内核的出现
自 2010 年代中期以来，Züblin（Strabag）一直在开发一个名为 SCOPE 的平台，该平台通过 API 连接和逆向工程 SDK 从各种 CAD 程序中获取几何图形，并将其转换为基于 OpenCascade 的中性格式。这样，几何数据就可以用于各种业务案例，而无需与特定的 CAD（BIM）程序绑定。该项目的主要理念是将项目数据管理从 CAD 应用程序中分离出来，确保用户不受特定供应商工具的影响。SCOPE 项目的描述与 Samuel Geisberg（PTC 的创建者和 Revit 项目的导师）的想法不谋而合，后者试图减少 CAD 程序对更改和添加数据过程的影响：
在项目实施的前八个月中，联合体成功地以万维网 RDF 和 OWL 格式制作了第一批完整的组件描述。为此，openCASCADE 几何内核的功能被转换为可寻址的网络结构。SCOPE 的既定目标是创建克服数字化障碍的网络结构。为此，建筑数字孪生的所有组成部分都将独立于软件显示，并可通过网络接口访问。如果成功，这就意味着所有相关公司、专业学科和行业创建建筑孪生体所需的所有数字化活动都可以独立进行，并且仍然可以联网。只要内容是在相同的技术基础上提供的，即单一的服务器结构和单一的数据模式。
图 21：Züblin-Strabag 团队的 SCOPE 语义项目
SCOPE 项目的构想当然很有前景，对行业来说也很有必要，但该项目是在封闭的 Zublin-Strabag 生态系统内实施的，开发人员和管理人员的团队不断变化。这有可能导致建立一个繁琐而低效的系统，并延长项目实现期限。基于 OpenCascade 的 Züblin 项目还面临着 OpenCascade 几何内核本身的技术限制和 CAD 程序不断变化的 API。一个由优秀专家组成的公司能否解决这些问题仍然是个问题。
总之，鉴于开发人员所面临的限制，SCOPE 目前还不能被称为一个完整的解决方案。私营机构为内部使用而开发的产品并非通用工具。
另一方面，计算机辅助设计（CAD）供应商本身也在朝着简化的方向迈进，并希望为建筑行业提供一种新的美元交换格式，这种格式与 CPIXML 格式类似，后者已经涵盖了中欧建筑公司的所有 4D-7D 流程。
因此，建筑行业的公司在未来面临着一个选择：是采用 Züblin 和弗劳恩霍夫研究所提出的方法，还是采用 HOK 和 CAD 供应商通过 building-SMART 或 AOUSD 联盟推广的解决方案。
然而，这两种方法，无论是源自建筑行业还是 CAD 领域，都得出了相同的结论：为了实现高效的数据交换，使用简单的平面元信息存储格式和三角化格式（如 OBJ、CPIXML、DAE、SVF、gLTF 或 USD）存储相同的元素数据是有意义的。
图 22：不同的数据格式包含相同的几何形状和项目元素的元信息
在回顾了几何图形传输和相关复杂性之后，让我们继续讨论 CAD（BIM）格式的第二个组成部分--元信息和元素语义本体，SCOPE 和 building-SMART 团队的官方新闻稿中都提到了这一点。
与 building-SMART 方法类似，Züblin 也在其 SCOPE 平台中应用了数据语义学的概念。这种方法的基础是蒂姆-伯纳斯-李提出的语义网理念。他的目标是创建一种智能语义学，在这种语义学中，数据的结构不仅能被人类理解，也能被机器理解。
10.建筑语义学和本体论的出现
建筑业的标准化和统一化借鉴了 20 世纪 90 年代末语义网概念中引入的语义和本体。这一概念在 building-SMART 中被改编为 IFC 标准。语义学背后的基本理念是，数据不仅要对人类有意义，也要对机器有意义，让它们能够 "理解 "信息，而不仅仅是传输信息。而本体论则为术语及其关系创建了清晰的定义，为所有系统提供了统一的框架。
building-SMART 尝试将这种方法推广到整个建筑行业。在一份有关 IFC5 格式未来的重要文件中，题为 "工业基础类的未来：迈向 IFC 5 "的重要文件中，语义方法被提及 32 次，强调了其对标准进一步发展的重要性：
特别是在语义网领域，人们在改造、模块化和简化 IFC 模式（或本体，根据该领域的典型习语）方面投入了大量精力。首先是对 IFC EXPRESS 模式的直接转换和修改，从而使本体更加成语化（Beetz 等人，2009 年），以及旨在引入模块化的分析（Terkaj 和 Pauwels，2017 年）。
building-SMART 的目标是创建一个描述对象及其关系的单一通用标准。这种方法应适用于整个建筑界，确保数据的统一，并改进不同系统对数据的解释。购买 building-SMART 会员资格不仅能让会员公司有机会加入未来，还能积极影响未来的形成。
图 23：1994 年 building-SMART 国际董事会主席的话
然而，语义和本体的实施并不总是成功的。事实证明，情况要复杂得多。在游戏行业，由于该行业的高动态变化性和创造性，试图通过本体来描述游戏对象和交互的努力遇到了问题。因此，标准数据格式（XML、JSON）和算法被证明更为有效。房地产市场也出现了类似的情况，当地术语的多样性和快速变化使得本体论过于复杂。简单的数据库和 RETS 等标准在数据交换和处理方面表现更佳。
除非绝对必要，否则不应引入新的实体
奥卡姆剃刀
技术上的困难，如标记的复杂性和支持的高劳动强度，以及开发人员的低积极性，阻碍了这一想法在其他行业的发展。RDF（资源描述框架）没有成为大众标准，本体论被证明过于复杂，在经济上也不合理。因此，创建全球语义网的雄心未能实现。一些想法在企业解决方案中得到了调整，但创建单一综合图谱的最初目标并未实现。
图 24 关系数据库与本体数据库的比较关系数据库与本体数据库的比较
本体论和语义技术承诺从数据中创造意义，但在实践中，它们更像是一种统一和标准化机制。从表格到数据图表可以改进搜索并统一数据模型，但并不能使数据对机器更有意义。问题不在于是否应该使用语义技术，而在于它们在哪些方面真正发挥作用。
建筑行业对语义技术和本体的兴趣得到了 building-SMART 计划的支持。然而，是否需要一个完整的形式逻辑并为整个行业创建一个统一的本体论仍然是一个有争议的问题。CYC（"百科全书"）和语义网项目的经验表明，放弃单一通用本体的想法，转而采用仅适用于特定任务、项目或公司的本地微观理论，可能是一种更有成效的方法。
11.语义学和本体论：如何让数据说话？
在 building-SMART 的努力下，语义和本体不仅成为了 CAD 供应商驱动的标准化背后的关键理念，也成为了由 Züblin (Strabag) 倡导的 SCOPE 等项目的基础，其目的是让建筑行业摆脱对 CAD 系统的依赖。
语义技术是对大量异构数据进行统一、标准化和修改，以及实施复杂搜索的技术。然而，语义学与创造新的意义或知识毫无关系--在这方面，语义学技术并不比其他数据存储和处理技术优越。
将关系数据库中的数据表示为一组三元组并不能增加数据本身的意义。用图形代替表格，对于统一数据模型、实施复杂搜索和安全修改业务模型都很有用。但是，这并不能使数据变得更加 "智能"--计算机并不能更好地理解数据的含义。
在存储 "OWL 数据 "时，这些数据使用 RDF 三元组（RDF - 资源描述框架和 OWL - 网络本体语言）存储。
图 25：图数据模型：节点、边和三元组说明构建模块之间的关系
从理论上讲，逻辑推理程序（自动逻辑推理程序）可以根据本体推导出新的语句。例如，如果建筑本体记录了 "地基是墙的支撑 "和 "墙是屋顶的支撑"，那么逻辑推理程序就能自动推断出 "地基是屋顶的支撑"。这种机制确实有助于优化数据分析，因为它消除了明确说明每种依赖关系的需要。不过，这并不是在创造新知识，而只是在自动比较已知事实。
本体中的逻辑链接（如果需要）无需复杂的语义技术即可组织，例如使用关系数据库（SQL）或 CSV 和 XLSX 表格。在列式数据库和格式中，可以添加 "屋顶支撑 "列，并通过编程确保在创建墙体时添加屋顶与地基相连的事实。实现这一点无需使用 RDF、OWL、图形或解析器。
图 26：相同逻辑关系的图形和表格表示模式比较
在 20 世纪 90 年代末，语义网的概念似乎很有前途，也很流行，building-SMART 和 Strabag (Zublin) 决定遵循语义网的概念，这一决定影响了整个建筑行业。然而，矛盾的是，语义网概念最初是为互联网而提出的，即使在其原生环境中也没有得到广泛应用。RDF 和 OWL 就是为互联网而开发的，但在互联网上，这些概念如今几乎没有被使用。原始架构中成熟的语义网从未出现过，而且可能也不会预见到它的出现。
事实证明，创建一个能让计算机理解内容含义的互联网的想法过于复杂，而且不经济。这就是为什么最初支持语义网的企业只放弃了该技术的有用元素，如本体和 SPARQL，并将其用于企业目的，而不是整个互联网。以谷歌趋势为例，如果你看看过去20年的谷歌趋势，就会发现那里可能已经没有什么前景了。
图 27：根据谷歌查询统计数据得出的对语义网主题的兴趣
这就产生了一个逻辑问题：如果可以使用流行的结构化查询（SQL、Pandas、Apache）处理数据，为什么还要在构建中使用三元组、rizoners 和 SPARQL？在企业应用中，SQL 是处理数据库的标准。相反，SPARQL 需要复杂的图结构和专业软件，根据 Google 的趋势，它并不吸引开发人员的兴趣。
图形数据库和分类树在某些情况下可能有用，但在大多数日常任务中，它们的应用并不总是合理的。因此，只有在需要统一不同来源的数据或实现复杂的逻辑结论时，创建知识图谱和使用语义网络技术才有意义。对于日常任务，如建筑数据管理，关系数据库、CSV、SQL 和 Excel 仍然是更简单、更易用和更高效的工具。
12. 从图表到表格：分组和筛选中的人工成本
任何本体论和关系都使用键值对从根本上描述项目元素和实体的参数。唯一的问题是如何以何种形式交流这些键值字典参数。区别不在于存储机制或结构，而在于语义理解的深度以及在概念之间建立有意义联系的能力。表达式标记和 IFC 本体是否是实现这一目标的理想工具，这是一个大问题。
图 28：元素实体的信息以键值形式存储，表现形式各不相同
其他行业也有同样的元素参数、几何形状和类似的本体传输问题。然而，这些行业的专家使用 XML、DB、JSON、CSV、HD5 和 XLSX 等流行格式传输元信息。这就产生了一个合乎逻辑的问题：为什么在建筑行业，我们决定使用早在 70 年代就开发出来的逐行 EXPRESS 标记 IGES-STEP 格式技术来传输元信息？是的，有将数据从 IFC 转换为 JSON、XML、CSV 或 XLSX 的转换器。然而，问题来了--为什么要在 IFC 中使用中间步骤呢？
使用逆向工程 SDK 将 CAD 程序中的数据直接卸载为 JSON、XML 或结构化 CSV/XLSX 格式更为合理，所有 CAD 供应商都无一例外地使用这些格式。在这种情况下，使用 IFC 作为中间步骤就失去了意义。如果图形和表格之间的信息完整性没有区别，那么选择就只剩下数据模式和记录格式的选择了。
数据的形式和模式应符合特定任务的使用情况。
图 29：图形和表格结构包含相同的项目要素信息
语义图格式只简化了新关系的创建，也就是说，它允许在图中添加新的数据类型，而无需对存储结构进行任何更改。
与关系表相比，图形中没有特殊的、额外的数据连接性--将二维数据库数据转换为图形不会增加关系的数量，也不会产生新的信息。
为了将数据纳入业务流程，我们应努力使用那些能帮助我们尽可能快速、轻松地获得结果的工具。
在处理 CAD（BIM）模型和数据库中的数据时，主要任务仍然相同，即从某个组的通用项目数据库中快速分组和过滤，以提取关键信息。这项工作的结果将以表格、图表或文档的形式呈现，以便做出以数据为导向的明智业务决策。
图 29：建筑设计数据的主要用途之一是 QTO 分组和过滤
尽管输入和输出数据相同，但执行这些操作所需的方法和时间会因使用的 CAD（BIM）系统，特别是其中使用的格式、数据模式和概念方法不同而有很大差异。
例如，从项目中获取同一类别（以墙壁类别为例--OST_Walls、IfcWalls）所有类型元素的体量表的任务，因工具而异。在 Revit 图形用户界面中，需要点击 17 次鼠标才能对表格进行分组和检索。使用 Dynamo for Revit 可以自动完成这一过程，但需要在专门的 IronPython IDE 中导入和链接 13 个代码块。为 Revit 编写 Python 脚本需要 40 行代码和 APU 知识，这提供了更大的灵活性，但需要工程师或程序员付出更多的努力。
通过 Solibri 程序界面处理 IFC 文件的劳动强度与 Revit 相似--在这里，要从项目中获取一个包含体积的简单表格，也需要点击 17 次鼠标。如果使用 Python 库 IfcOpenShell 或 JavaScript IFC.js，处理将变得自动化，但这同样需要分别编写约 40 行和 100 多行代码。
此外，CAD（BIM）工具的专有格式和格式的问题在于，一方面，它们为开发自己的自动化生产流程算法提供了便利的环境。但另一方面，这些算法又会与特定的数据格式或解释方式僵化地绑定在一起。结果，自动化失去了其普遍性，开始依赖于格式的特殊性，而不是与实体协同工作，不受技术限制。
图 30：不同的劳动力投入可获得相同的结果
通过对 CAD 项目格式中的数据进行规范化和结构化处理，无需打开 CAD（BIM）程序本身，而是使用逆向工程工具等，我们就可以使用数据分析工具进行分组、过滤和分析。使用数据分析工具，只需一行代码就能完成分组、过滤和处理操作，而在传统的 CAD 系统和 BIM 概念中，数据是以图形的形式表示的，必须通过层次结构和类才能找到元素。因此，需要在用户界面上点击数十次、编写数百行脚本的相同操作，可以通过处理结构化格式的数据更快、更简单地完成。
它是结构化和规范化的数据，使工程师能够在不同类型的数据之间快速高效地移动，无需学习独特的格式模式、接口功能、API 连接和几何内核。
图 31.在图表数据表格中，用户通过应用程序接口或用户界面获取所需数据
对数据进行规范化和结构化处理可提高处理的灵活性，而无需花费大量精力去了解每个使用案例的数据模式。2023 年，欧特克公司也将采用同样的理念，宣布进入一个颗粒化数据的新时代，在这个时代，将不再有文件系统，项目将被分解为最小的元素，数据分析和结构化格式也是如此。
如果 CAD 供应商正在为其客户开发新的数据格式和工作方式，那么谁来负责整个建筑行业的数据格式和流程，谁来参与制定使用标准？
13.ISO 和 building-SMART 的阴影：数据格式控制权争夺战
跨平台 CAD-MCAD 数据的问题最早是由机械工程领域的专家遇到的，他们经常需要使用 STEP 和 IGES 格式（IFC 的思想前身）在 MCAD 产品之间传输信息，而在建筑行业，专家们也在为跨平台几何内核而苦恼。引自 "选择最佳 CAD 文件格式 "一文：
所有 CAD 系统都有一个几何建模内核，它是本地格式的基础，允许您创建和操作几何体。CATIA 使用 Convergence Geometric Modeler (CGM)，Creo 使用 Granite (g)，Siemens NX 和 SOLIDWORKS 使用 Parasolid (x_t) 内核。
几何建模内核在纯几何方面与本地格式完全相同，因为任何 CAD 系统的本地格式都是基于其几何建模内核的。只要将内核用于源程序或最终应用程序，就无法获得比内核格式更好的几何精度。例如，如果您有一个来自 CATIA 的零件，并想在 MasterCam 中打开它，请将其保存为 Parasolid 内核格式，因为 MasterCam 软件应用程序正是基于这种格式。
图 32.封闭（封闭 BIM）和开放（开放 BIM）格式的数据质量
Revit（基于 Pro/Engineer）和 AutoCAD（基于 CADDS 3）等程序，以及包括开源 OpenCascade 在内的大多数现代几何内核，都是从机械工程领域发展而来的。STEP 等数据交换标准（类似于机械工程领域的 IFC）正是在这一行业中诞生的。
总的来说，虽然机械工程师在使用格式时遇到的问题相似，并由此引出了使用几何内核的问题，但在机械工程和建筑行业标准化和推广这些格式的方法却明显不同。
与建筑业不同，国际金融中心的标准是由 building-SMART 制定和推广的，而机械工程的标准则是在国际标准化组织（ISO）的层面上形成的。在国际标准化组织中，标准的制定有所有成员国的平等参与，这使得制定过程具有全球性和独立性。国际标准化组织可被视为 "标准化方面的联合国"，其中央办事处设在日内瓦。
STEP 标准由美国国家标准协会（ANSI）下属的 TC 184 委员会负责制定。其历史可追溯到 1979 年由波音、通用电气、施乐、Computervision 和 Applicon 等一批 CAD 用户和供应商发起的 IGES 项目。该项目得到了美国国家标准与技术研究院（NIST）和美国国防部的支持，开发资金由军工联合体提供，并由军方控制。后来，在 IGES 的基础上创建了 STEP 标准，其分支在 90 年代成为 IFC。与开放式倡议不同，STEP 标准开发的所有关键决策都是在幕后做出的，没有过多的宣传和噪音。
STEP 是一个坦率的北美标准：它的使用并不强加给机械工程师；如果你想使用它，就使用它，如果你不想使用它，也没问题。与此相反，最初于 1994 年为促进 HOK 和 ADSK 的利益而创建的 building-SMART 与 building STEP-IFC 将自己定位为一个全球性倡议，倡导互操作性和面向全球的通用解决方案。
与 building-SMART 不同的是，STEP 的开发人员并不从事销售订阅服务或创建分会和会议室等部门来收集资料，以推广一种没有自己的几何核心和语义本体的参数化格式。
但是，即使尝试将 STEP-IFC 引入建筑行业并建立联盟，也无法克服交换格式造成的混乱。现在的情况是，如果不使用特殊的 SDK，甚至连 CAD 供应商自己都无法在其产品中支持 IFC，我们在《建筑行业开放数据的斗争》一文中对此进行了详细讨论。AUTOLISP、intelliCAD、openDWG、ODA 和 openCASCADE 的历史
14.为什么建筑商和客户需要控制数据？
建筑数据创建是一个不断生成参数并将其转换为可读格式的过程。每个项目实体--墙壁、窗户或地基--都是一个具有一系列属性（如材料、类型、成本、体积和面积）的对象。这些数据需要存储、处理并提供给最终用户。
CAD (BIM) 程序的开发人员努力将用户留在自己的生态系统中，每年都会将越来越多的数据处理转移到云存储合作伙伴亚马逊、微软 Azure 和华为。封闭系统的主要营销优势在于，可以从 CAD (BIM) 解决方案的几何核心向云 MESH 格式传输高质量的几何图形，并能使用昂贵的 SDK 从其他供应商导入/导出第三方格式，进行逆向工程。
但是，为什么普通工程师、物流师、建筑商、工头和估算师需要几何内核和云技术呢？对于大多数施工任务来说，网格格式的精度已经足够，使用复杂的几何图形内核和 SDK 只会使施工过程更加复杂。
图 34.建筑业面临向开放式结构化数据和开放式工具的必然转型
大多数现代图形引擎专门处理三角形网格，而不是 BREP 几何图形。具有讽刺意味的是，所有 CAD 供应商都在持续推广复杂的几何内核，有时甚至不是他们自己的内核，而可视化、模拟和动画却在逐渐转向流行的免费非商业用途工具 - Blender、Unity、虚幻引擎和 Omniverse。
通过放弃数据交换和处理中的参数几何，转而使用 MESH 几何，对 CAD 程序和几何内核的依赖性将大大降低。这将使数据处理更加透明，并加速 OBJ、gLTF、DAE 和 USD 等流行格式的发展。意识到这一趋势，CAD 供应商正努力将用户留在自己的生态系统中。为此，他们推广 "用户友好型 "互操作格式，并将其正式定位为开放格式。但实际上，导出这些格式需要订购 CAD（BIM）程序，而处理这些格式则需要 API 知识和绘制复杂几何内核特征的技能。
在当今的设计和施工领域，数据访问的复杂性导致了项目管理的过度工程化。大中型建筑和设计公司不得不与 CAD（BIM）解决方案提供商保持密切关系，通过 API 和 Forge、ACC 等产品访问数据，或者绕过 CAD 供应商的限制，使用昂贵的 SDK 转换器进行逆向工程。
要访问自己的项目数据，不应该需要特殊的密钥、云端解决方案的订阅费用或以 API 请求形式出现的魔法咒语。
获取信息是一项权利，而不是特权。
蒂姆-伯纳斯-李，万维网发明者
开放数据的获取将为建筑企业打开下一个潘多拉盒子，这将不可避免地导致整个建筑行业的转型。
15.优步化和开放数据对建筑业构成威胁
未来，投资者和建筑融资客户将不可避免地认识到开放数据和历史数据分析的价值。这将为项目进度和成本的自动化计算提供机会，从而更好地控制成本，更快地识别超额成本。举例来说，如果不使用计算机辅助设计（BIM）及其复杂的几何内核，就能根据带有结构化元信息的简单平面 MESH 项目数据自动检查现场的混凝土量，那么高估的情况就会一目了然。
数据的这种开放性和透明度对建筑公司构成了威胁，因为这些公司习惯于从不透明性的流程和混乱的报告中赚钱，投机和隐性成本可能隐藏在复杂而封闭的数据格式和平台背后。因此，建筑公司不太可能有兴趣在其业务流程中全面实施开放数据。如果数据可供客户使用且易于处理，就可以自动检查，从而消除高估工程量和操纵估算的可能性。
失去对数量和成本计算的控制已经改变了其他行业，使客户能够直接实现自己的目标。数字化和数据透明已经改变了许多传统的商业模式，例如优步（Uber）改变了出租车司机，Airbnb 改变了酒店经营者，亚马逊（Amazon）改变了零售商，在这些行业中，直接获取信息和自动支付大大减少了中间商的作用。
图 35.建筑业不久将面临与出租车司机、酒店销售员 10 年前同样的流程
投资者、客户和银行也已经开始要求建筑行业的透明度。开放和不受限制地获取数据的过程不可避免，随着时间的推移，开放数据将成为新的标准。因此，投资者、客户、银行和私募股权基金--这些最终是建筑对象的最终用户--将对开放格式的实施问题提出最高要求。
未来，投资者、客户从想法到建筑成品的过程将类似于自动驾驶旅行--没有建筑公司形式的司机，有望摆脱投机和不确定性。
图 36.建筑业从基于重要专业人员意见（HIPPO）的决策到数据分析的转变：今天和明天
人类所有经济活动中的数据和流程都与建筑业专业人员需要处理的数据和流程无异。开放数据和自动化时代将不可避免地改变建筑业，正如它已经改变了银行业、商业、农业和物流业一样。在这些行业中，中介的作用和传统的经营方式正在让位于自动化和机器人化，没有任何不合理加价和投机的空间。
从长远来看，如今通过制定价格和服务质量标准来主导市场的建筑公司，可能会失去其作为客户与建筑项目之间关键中介的角色。
公开、结构化的数据和流程将为客户和投资者提供准确估算项目成本和进度的依据，从而消除建筑公司对不透明数据和复杂格式进行推测的机会。这对建筑行业来说既是挑战也是机遇，他们需要重新思考自己的角色，适应新的环境，使透明度和效率成为成功的关键因素。那么，BIM 将何去何从呢？
16.BIM、openBIM、BIM Level 3 和 noBIM 是否真的存在，还是营销噱头？
当我们谈到 BIM 时，脑海中会浮现出三维模型、碰撞检测工具和 ACC 中的模型查看器。但如果深入探究，问题就来了：BIM 究竟是什么？它是一套数据、参数和流程，还是仅仅是一句营销口号？要回答这个问题，我们需要超越计算机辅助设计（CAD）供应商所宣传的缩略语和概念，并探究设计信息工作的本质--数据和流程。
建筑业的任何业务流程都不是从使用 CAD（或 BIM）工具开始的。在任何业务流程中，我们首先要形成任务参数，并定义对未来要素的要求：我们要指定一个实体列表、其初始特征和边界值。这通常以表格、数据库或键值对列表（1-2）的几列形式完成。
只有在这些初始参数的基础上，才能在 CAD/BIM 程序中使用 API 自动或手动创建对象 (3-4)，然后再次检查它们是否符合初始要求 (5-6)。这个循环--定义、创建、验证和修正（2-6）--重复进行，直到数据质量达到目标系统--文档、表格或仪表盘--所需的水平（7）。
图 37.建筑业业务流程的流程自动化周期
如果我们将 CAD（BIM）视为一种传输参数的方式，而参数是最初在 CAD 环境之外生成的键和值集（1-2），那么很明显，我们实际上是在使用一个参数数据库（2-3，5-6），该数据库通过各种工具进行补充，并在某一时刻从简单的要求变为带有参数的元素集，在 CAD 程序中通常将其作为一个封闭的数据库进行处理。通过这一定义的棱镜来看待 BIM，我们会发现其原理与数据分析以及 ETL 流程（数据提取、转换和加载）中使用的原理相似。问题来了：如果其他行业没有类似的方法，那么 BIM 的独特性何在？
在过去 20 年中，CAD 供应商将 BIM 定位为不仅仅是一个数据库。从市场营销的角度来看，BIM 是一种参数化工具，能够实现建筑项目设计、建模和生命周期管理过程的自动化。但在现实中，BIM 更像是一种让用户留在供应商平台上的工具，而不是一种管理数据和流程的便捷方法。供应商将高质量的 CAD（BIM）数据有效地隔离在自己的平台之外，将其隐藏在专有的 API、SDK 和几何内核之后。这使得用户无法绕过这些生态系统，独立地提取、分析和交流数据。
如今，建筑行业的大多数数据分析流程与其他行业类似。这些都是典型的 ETL 循环（提取、转换、加载）和数据分析。例如，在银行业，数据被提取、转换成可理解的格式并加载到商业智能平台进行可视化和分析。在建筑业，同样的操作已经并将继续进行--从 CAD（BIM）数据库中提取数据（提取）、规范化和结构化、后续分析、转换（转换）以及上载到其他系统和数据库（加载）。
图 38.数据处理工作流程比较：未进行处理的手动 CAD（BIM）方法和进行数据预处理的自动工作流程
通过完全访问 CAD 数据库和使用逆向工程工具，我们可以获得一组带有属性的平面实体，并将其导出为任何方便的开放格式，其中包含设计元素的几何形状和属性，这与 SCOPE 项目中实施的类似。当 BIM 数据转化为易于分析的格式（表格、数据库、DWH、DL 的结构化表示）时，开发人员就不再依赖于特定的数据模式和封闭的生态系统。这就是未来建筑行业的发展方向--收集数据、分析数据、验证数据，并利用数据分析工具实现流程自动化。
信息是 21 世纪的石油，而分析则是内燃机。
也许 BIM（计算机辅助设计）并不是最终目标，而只是发展的一个阶段。当建筑专业人员意识到他们可以绕过传统的 CAD 工具直接使用数据工作时，"BIM "作为一个术语就会化为信息的洪流。我们将开始谈论细粒度或结构化的建筑项目数据，但它将不再是我们今天所知道的 BIM。
17.下一步是什么？简单的格式和方便用户的工具
发展的主要方向可能是向开放和独立的解决方案过渡，摆脱专有 SDK 和几何引擎的束缚。IFC 格式在没有特殊知识和专业几何引擎的情况下仍然难以使用，与其尝试对其进行 "调整"，不如关注现有的通用格式，因为这些格式已经证明了其有效性：用于几何体的 MESH、OBJ、gLTF、DAE、FBX 或 USD，以及用于元数据和参数的 CSV、JSON、XML、XLSX、SQL、YAML。
建筑业的未来与简单、经济的工具的创造息息相关，就像在 Photoshop 统治二十年后，2010 年代末在二维图形领域出现的工具一样。平面 JPEG、PNG 和 GIF 格式的出现，摆脱了二维编辑器内部引擎的冗余逻辑，开发出了成千上万种兼容的图像处理解决方案。
同样，三维格式和元信息的标准化和简化也将促进许多便捷、独立的建筑项目工作工具的出现。摒弃 "供应商核心 "的复杂逻辑，转而采用通用、开放的格式，将为更灵活、更高效的工作创造条件，并为建筑过程中的所有参与者开放数据访问。
图 39.CAD/BIM 成熟度：从非结构化数据到完全结构化数据和存储库。
在开源社区中，有一些很有前途的项目可以作为开发轻量级几何求解器的范例：有可能在浏览器中运行的 SolveSpace、基于 JavaScript 的 Web-CAD.org，以及各种免费的 CSG 编辑器。需要特别注意的是 Unity 平台，它为创建复杂的工具提供了一个现成的基础，能够自定义渲染并添加必要的功能。在我的 中2021 例子，Unity 基于浏览器的 CAD 程序 NoteCAD 的引擎经过重新设计，配备了自己的几何求解器，尽可能与免费在线 SketchUp 的功能相匹配。最终，这款轻量级的免费开源产品在任何服务器上都能快速运行。
图 40.BimCADOnline 示例：带有自己几何求解器的开源在线解决方案
行业发展的主要原则不应是创建新的格式，而应是有效使用和完善现有的解决方案。重要的是要依靠 OsArch 和 FreeCAD 等国际社区，并支持开发开放式几何内核的团队。
对于需要使用 BREP 几何图形的用户，OCC 和 OGG 等开源几何图形内核可以发挥关键作用。而对于只需使用 MESH 几何图形的任务，CGAL、OpenMesh 和 MeshLib 将是很有前途的解决方案。使用 OpenDesignAliance、CADExchanger 或 HOOPS 等公司提供的逆向工程 SDK 来检索和写入各种 CAD 和 MCAD 格式的数据。创建这些 SDK 的目的是为开发人员提供平等的数据访问权，确保每个人都能以领先的 CAD（BIM）开发人员的水平开发 CAD 和 MCAD 解决方案。
图 41 OpenDWG。该联盟的目标是为所有 CAD 供应商提供公平的竞争环境，无论其与 ADSK 的关系如何
这些工具与 LLM 模型相结合，将大大提高数据创建、转换和输出到目标系统过程的效率。
18.项目数据流程中出现的 LLM 和 ChatGPT
除了开放格式和通用工具的开发，LLaMA、ChatGPT、Gemini 和 Claude 等大型语言模型（LLMs）也正在彻底改变数据处理行业。这些技术从根本上改变了方式处理和分析项目数据的，使参与施工过程的每个人都可以使用这些技术进行处理和自动化。
如果说以前只能通过复杂的应用程序接口（API）和需要特殊编程技能的 SDK 界面来访问信息，那么现在则可以用自然语言与数据进行交互。
几年内，数据访问将不可避免地实现民主化。简单的工程师、管理人员和规划人员只需用普通语言进行查询，就能从结构化格式的项目数据中获取必要的信息。例如，只需在聊天中提出以下要求即可："在表格中按类型显示所有体积超过 10 立方米的墙体"，LLM 将独立地将此查询转换为 SQL 或 Pandas 查询，通过分组将结构化的项目数据转换为所需格式的表格、图形或成品文档。
视频 - 建筑行业的数据争夺战。大数据和 ChatGPT 与 CAD（BIM）的应用
自动化流程本身将大大简化--不再需要研究封闭产品的应用程序接口，也不再需要用 Python、C# 或 JavaScript 编写复杂的脚本来分析或转换参数，现在只需以一组单独的文本命令的形式制定任务即可，这些命令将被折叠到适用于正确编程语言的正确管道或工作流流程中。
图 42.在 LLM 中从编程转向创建查询，以创建管道流程
无需再等待 CAD（BIM）工具供应商的新产品、格式、插件或更新。通过 LLM 聊天机器人，工程师和建筑商将能够使用简单、免费和易于理解的工具独立处理数据。
现代数据分析工具与开放数据格式相结合，将为建筑行业创造一种新的工作模式，在这种模式下，最重要的不是拥有某种软件和了解其应用程序接口，而是能够有效地制定任务参数并快速分析所获得的数据。
代替结论
建筑行业的互操作性和跨平台情况清楚地表明了与不同 CAD（BIM）系统之间的数据传输和使用相关的根本问题。欧特克公司就是一个典型的例子，它积极推广开放的 IFC 格式，但自己却无法确保从自己的产品中正确导出这种格式，而不得不求助于 OpenDesignAlliance 的逆向工程 SDK，该组织最初成立于 1998 年，目的是对抗欧特克公司对数据的垄断。矛盾的是，这种情况迫使所有行业参与者使用类似的 SDK 来提取和调整竞争 CAD 解决方案的数据，使其适用于自己的平台，这实际上破坏了跨平台互操作性的理念，而 IFC 互操作性格式正是为此而创建的。
IFC 格式旨在成为不同 CAD（BIM）系统之间的通用桥梁，但在现实中却成为不同 CAD 平台几何内核之间兼容性问题的指示器，这与最初出现的 STEP 格式类似。尽管 building-SMART 组织积极推广该格式，但主要工作还是集中在几何标准化（这需要统一的几何内核，但目前仍不存在）以及建筑行业语义和本体的统一上。然而，这些努力与语义互联网概念未实现的雄心壮志不谋而合，后者的期望远远超过了现实。
图 43.施工过程中的几何与信息：从复杂的 CAD 和 BIM 系统到用于分析的简化数据
行业的特殊性加剧了这一问题。传统上，建筑行业在掌握新技术方面比其他行业落后 10-20 年，现在有可能重蹈覆辙。如果说在信息技术领域，语义网的失败可以通过新技术（大数据、物联网、机器学习、AR/VR）的出现得到弥补，那么建筑行业就没有这样的理由。
不过，也有个别的替代方法实例。Züblin 公司的 SCOPE 项目展示了如何超越 CAD（BIM）系统的经典逻辑。他们没有试图从属于 IFC 或依赖专有几何内核，而是使用逆向工程 API 和 SDK 从各种 CAD 程序中提取数据，将其转换为基于开源 OpenCascade 内核的 OBJ 或 CPIXML 等中性格式，然后将其应用于建筑和设计公司的数百个业务流程。然而，尽管想法很先进，但这些项目仍然是封闭生态系统的一部分，再现了单一供应商解决方案的逻辑。因此，建筑行业再次陷入了这样一种境地：IFC 等跨平台标准无法完成其使命，而本地倡议只能部分缓解问题。
CAD 供应商很可能再次成功地将有关开放数据访问的讨论转移到 "新 "概念、格式和联盟上，而这些概念、格式和联盟与 BIM 和 openBIM 一样，将主要作为将用户留在专有生态系统中的工具，这将再次阻碍本已无利可图的行业的生产力增长，因为资源将不是用于简化和优化流程，而是用于维持对生态系统的控制和吸引用户使用新概念。
图 44.过去 30 年中，CAD（BIM）技术未能提高建筑业的生产率
本分析报告的目的不是批评现有的方法，而是就主要问题--如何提高建筑行业的生产率以及原则上是否可行--展开讨论。我对 CAD（BIM）解决方案的开发者和 ADSK 公司以及 building-SMART 的参与者和成员深表敬意。不过，也许现在是时候放弃等待供应商软件的新概念，专注于独立开发了。从数据访问问题中解脱出来后，该行业将能够转向使用现代化和用户友好型工具来处理和分析数据。这将使该行业朝着 Samuel Geisberg 早在 20 世纪 80 年代末就指出的方向发展。
传统的 CAD/CAM 软件不切实际地限制了在设计流程的最初阶段进行成本低廉的更改。我们的目标是创建一个足够灵活的系统，鼓励工程师轻松考虑不同的设计。而更改设计的成本应尽可能接近于零。
这是讨论行业转型的开端。只有解决了数据访问问题，我们才能继续探索业务流程并使其自动化。
📈 开放数据和格式将不可避免地成为建筑行业的标准，这只是时间问题。如果我们都能传播有关开放格式、数据库访问工具和逆向工程 SDK 的信息，就能加速这一转变。在这一过程中，你们每个人都可以提供帮助。如果您觉得所读信息有用，请与您的同事分享。
如果您想了解新的更新和文章，请注册 DataDrivenConstruction 网站上的时事通讯，或在 LinkedIn 和 Medium 上订阅。
🔗 LinkedIn：后 BIM 世界。向数据和流程过渡，建筑行业是否需要几何内核、语义、格式和互操作性
👋感谢您的评论和意见！如果有任何事实和资料来源引起您的疑问，或者您想分享自己的观点，请在评论或私人信息中写下您的想法。您的观点、观察和评论对讨论非常重要。我很乐意继续与您对话。
有关这些主题的其他文章：
📰变革时代：IFC 已成为过去或欧特克为何愿意放弃 IFC 换取美元的 14 个关键事实
📰建筑行业开放数据的斗争。AUTOLISP、SDK、intelliCAD、openDWG、ODA、openCASCADE 的历史
