BIM模型不必越做越重：KUBUS360用LOIN和四个数据库管理信息

很多 BIM 项目从建模软件开始讨论：墙体怎么画、族怎么建、属性怎么填。KUBUS360 先处理信息需求。团队和业主先确定哪些信息会被检查、统计、交换或用于运营，再决定这些信息何时进入模型。

这家位于德国斯图加特的建筑事务所把这套方法称为 leanBIM。案例项目位于巴登—符腾堡州霍恩洛厄县，由三个木—混凝土混合结构建筑组成。首层安排面向公众的服务和会议空间，上部主要是办公空间。项目使用 Vectorworks Architect。KUBUS360 的建筑师 Bianca Hirner 与 BIM 协调员 Freddy Hartmann 负责推进。

先定义信息，再开始建模。

项目的起点是业主信息需求（EIR）和 BIM 执行计划（BEP）。由于业主此前的 BIM 经验有限，KUBUS360 参与了 EIR 的制定，并根据它建立后续的执行计划。团队还把 BIM 管理者、总协调员和各专业协调员拉到同一个规划工作坊中，先确定工作流和交付方式。

随后，项目通过 LOIN，也就是“信息需求等级”，为每类构件指定 IFC 身份、属性以及属性进入模型的时间。比如防火等级、成本分组或设施管理相关字段，不需要在项目第一天全部填满。它们随着设计发展，在真正需要检查或交付的阶段进入模型。

ISO 7817-1:2024 对 LOIN 的定义也要求项目说明不同阶段的信息范围和粒度。LOIN 把信息交付与当前任务连接起来。

四个数据库，减少信息入口。

KUBUS360 在 Vectorworks Architect 中设置了四个主要数据库。它们分别处理通用 IFC、构件、门窗和设施管理信息。

团队把共享属性集中到这些数据库中。

Vectorworks Data Manager 再将属性映射到模型对象、明细表、可视化结果和 IFC 输出。

这种安排带来一个具体结果：团队更容易找到数据由谁录入、从哪里读取、最后流向哪里。以防火等级为例，属性先进入集中数据库，随后可以被用于数据可视化、表格和 IFC 模型。数据不再散落在各个对象的自定义字段里。

自由建模，保持 IFC 身份。

项目约 95% 的建模工作使用 Vectorworks 的原生工具完成，包括楼板、墙、楼梯、栏杆、结构构件和门。遇到特殊构件时，团队采用基于类的属性分配：构件的 IFC 身份和属性取决于它所属的类，不完全取决于绘制它时使用的工具。

这让几何表达获得了更大的自由度。比如，栏板可以用屋面面板建模，但通过所属类仍然以正确的 IFC 身份和成本分组导出；曲面立面构件可以从实体几何开始，再转成 Auto Hybrid 对象，同时保留标准构件所需的数据。

把数据变成可见的检查结果。

模型信息只有在团队能快速检查时才会进入实际工作流。KUBUS360 使用 Data Visualization 给构件着色，把防火等级等属性直接显示在建筑模型中。检查人员可以在整体视图中发现不一致的位置，再回到表格或对象属性继续处理。

团队还开发了内部工具 Angle Checker。多边形几何会产生大量不规则角度。Angle Checker 通过数据管理器给每个对象写入 true 或 false，让绘制错误的墙体快速显现。检查结果回到模型中，后续协调仍可继续使用。

BIM 信息还可以连接到场地和运营。

ArchDaily 文章还提到 Vectorworks 与 ArcGIS Feature Services 的连接方式。地块、道路和既有场地要素可以从 GIS 数据进入项目。这样可以形成带有地理位置的场地模型。既有树木还可以携带树种和健康状况等信息，再通过数据可视化区分保留、移除或替换对象。

在城市尺度上，带有建筑、景观和基础设施数据的模型也可以回到 GIS 环境，服务于规划、工程和设施管理。对于小型项目，这类整合可能超出当前任务范围；对于需要跨专业决策的项目，场地数据与建筑模型之间的连接会直接影响信息是否能继续使用。

SOURCES。

ArchDaily：BIM 模型的信息需求与 KUBUS360 leanBIM 案例。

Vectorworks：KUBUS360 BIM 流程与 Vectorworks Architect 案例。

ISO 7817-1:2024：BIM 信息需求等级的概念与原则。