新闻资讯

在传统的 IBMS 项目建设中，平台往往已经完成了设备接入、数据采集、告警展示和控制联动，但当系统真正进入跨系统协同、智能分析和自然语言交互阶段时，新的问题就会暴露出来：设备命名不统一、空间关系难追溯、上下游供给链不清晰、控制语义缺乏标准表达。结果就是“数据很多，但系统未必真正理解建筑”。

这正是 Building Ontology（建筑本体论）进入智慧建筑领域的现实意义。对南京古河而言，Building Ontology 不是一个停留在概念层面的学术名词，而是推动古河 IBMS 从“可集成”走向“可理解、可推理、可执行”的关键技术底座。

一、为什么传统 IBMS 需要建筑本体论

传统 IBMS 擅长把楼宇自控、视频监控、门禁、照明、能源、环境监测、停车、运维等子系统接入到统一平台中，但大量项目在深入使用时会遇到三个共性难点。

第一，系统知道“有数据”，却不一定知道“数据代表什么”。同样是温度点位，不同项目中可能使用不同命名方式，不同品牌设备的对象模型也不一致。

第二，系统知道“有设备”，却不一定清楚“设备之间是什么关系”。一个会议室的温度异常，究竟应该看风机盘管、VAV、空调箱还是冷源侧设备，往往仍依赖工程师经验判断。

第三，系统知道“可以控制”，却不一定具备稳定的语义约束能力。没有统一知识模型的情况下，AI 很容易把“开灯”“调低温度”“切换运行模式”理解成表面文本，而不是可审计、可执行的控制语义。

Building Ontology 的价值，就在于把建筑中的空间、设备、测点、系统、供给关系和控制语义，以结构化、形式化的方式沉淀下来，让 IBMS 不只是接入系统，而是逐步具备“理解建筑”的能力。

二、Building Ontology 给古河 IBMS 带来了什么

在古河 IBMS 的技术体系中，建筑本体论首先解决的是语义统一问题。它可以把设备分类、空间拓扑、上下游供给关系、点位属性、命令语义等知识抽象为统一模型，让平台面对不同项目、不同品牌、不同命名习惯时仍然能够保持一致的理解方式。

例如，当用户说“把三楼会议室调到 24 度”时，系统不应只停留在关键词匹配层面，而应能够识别“三楼会议室”对应的空间对象，定位相关末端设备，结合供给关系判断上游设备，再根据命令约束生成可执行控制动作。这种能力的前提，正是 Building Ontology 提供的语义底座。

对于古河 IBMS 而言，本体模型的意义并不局限于 AI 对话。它同样可以服务于设备检索、告警归因、空间联动、运维知识复用、跨项目模型迁移和数字孪生场景中的对象语义绑定，使平台在项目交付后仍具备持续演进能力。

三、南京古河如何把 Building Ontology 落到 IBMS 能力里

南京古河的软件路线不是把本体论单独做成一个孤立工具，而是将其嵌入 IBMS 的整体能力架构中，与物联网接入、数据中台、数字孪生和 AI 引擎协同工作。

在接入层，古河通过 IoServerPlus 等边缘计算与协议接入能力，统一采集 BACnet、Modbus、OPC UA、MQTT、KNX、SNMP、ONVIF 等协议数据，为上层知识建模提供可靠数据基础。

在知识层，古河 AI-Ontology 平台可围绕设备类型、空间结构、供给关系、测点属性和控制命令建立建筑领域知识模型，使楼宇对象不再只是数据表中的记录，而是具备明确语义关系的知识对象。

在智能层，古河 IotClaw 物联网 AI 引擎可以将 Building Ontology 与大语言模型结合起来，让自然语言查询、设备定位、状态感知和控制执行形成更可控的闭环。AI 不是在“猜”建筑，而是在已有知识模型基础上做推理与调用。

在应用层，古河 GH-DTMS/IBMS 平台可将这些能力落实到控制中心、告警中心、能源管理、运维管理、数字孪生、2D/3D 组态、AI 智能中心等模块中，形成从接入、建模、分析到执行的统一平台能力。

图：古河 GH-DTMS / IBMS 平台架构中，AI 智能中心可承载本体建模与知识推理能力

四、从“集成平台”到“知识平台”，古河 IBMS 的价值升级

当 Building Ontology 真正进入 IBMS 体系后，平台价值会发生明显变化。

一是从“看得见”升级到“说得清”。系统不但能展示设备和数据，还能明确说明设备属于什么类型、位于什么空间、由谁供给、与哪些控制命令相关。

二是从“能联动”升级到“可推理”。面对异常温度、异常能耗、异常告警，系统能够沿着空间与系统关系追溯原因，不再完全依赖人工逐层排查。

三是从“可配置”升级到“可复用”。项目经验可以沉淀为知识模型，新项目不必每次都从零开始整理命名规则和对象关系。

四是从“接入 AI”升级到“AI 可落地”。没有 Building Ontology，AI 很容易停留在问答展示层；有了本体知识驱动，AI 才更有可能进入智慧建筑真正的管理与控制环节。

五、为什么这件事更适合南京古河来做

Building Ontology 在智慧建筑领域真正落地，难点并不在于会不会讲 OWL、RDF 或知识图谱，而在于是否长期理解建筑机电系统、楼控逻辑、项目交付方式和运维场景。没有 IBMS 行业经验，本体模型很容易停留在纸面；没有知识模型，IBMS 又很难走向更高层次的智能化。

南京古河长期深耕 IBMS、物联网平台、BIM 运维、数字孪生与 AI 融合场景，既理解工程现场，也具备平台产品化能力。古河将 AI-Ontology、本体建模、IotClaw 引擎、IoServerPlus 接入能力和 GH-DTMS 平台整合到一条技术链路中，目标不是做一个概念展示，而是让智慧建筑平台真正具备可理解、可分析、可执行的能力。

对于业主、集成商和园区运营方来说，这意味着未来的古河 IBMS 不只是一个统一监控平台，更是一个能够持续积累建筑知识、承载 AI 能力、支撑运维优化和智能控制的数字化底座。

六、结语

如果说传统 IBMS 解决的是“把系统连起来”的问题，那么 Building Ontology 解决的就是“让系统真正理解建筑”的问题。二者结合之后，智慧建筑平台才有可能从单纯的数据汇聚中心，进一步演进为知识驱动的智能运行平台。

这也是南京古河推动 IBMS 持续升级的方向：在统一接入、统一监控、统一控制的基础上，引入本体知识、语义推理与 AI 智能能力，让平台不仅能服务今天的集成需求，更能支撑未来的智能决策与业务创新。

如果您正在规划面向未来的智慧园区、智慧楼宇、医院后勤或大型综合体管理平台，古河 IBMS 将不仅帮助您完成系统集成，更能帮助您构建一套面向 AI 时代的建筑知识底座。