更新说明:2026年9月8日补充Java / Spring Cloud平台分工、数据链路排查和验收方法,保留原发布日期。
古河IBMS系统架构可以分为接入层、数据与模型层、业务应用层、可视化层和运营闭环层。它通过边缘采集和标准接口接入现场系统,再把设备、空间、告警、能耗和工单组织成统一管理平台。
接入层负责对接楼控、安防、视频、门禁、停车、能源、环境、消防接口和第三方业务系统。不同项目会根据现场条件采用网关、API、数据库、消息总线或厂家接口方式接入。
数据与模型层负责设备台账、空间关系、点位模型、实时数据、历史数据、告警规则和权限角色。没有这一层治理,后续驾驶舱、报表、联动和 AI 分析都容易变成孤立展示。
业务应用层包括统一监控、告警中心、能耗管理、设备运维、工单闭环、报表分析、数字孪生和 AI 辅助运维。架构设计的重点,是让这些应用共享同一套对象、数据和权限。
说明:本文用于知识解释和选型参考,具体系统边界、接入协议、联动策略和运维流程应结合项目现场、弱电系统条件、权限审计要求和业主运营目标确认。
古河IBMS的平台业务采用Java / Spring Cloud组织服务,现场采集通过协议驱动或网关提供设备数据。架构图需要进一步落到可追踪的链路:设备身份与物模型管理、实时属性快照、历史查询、规则告警、页面订阅及资源管理各有明确职责。
| 参与方或环节 | 准备内容 | 验收重点 |
|---|---|---|
| 数据进入平台 | 设备标识、属性含义、单位与数据时间 | 核对采集报文和属性映射 |
| 多个应用使用数据 | 实时显示、历史曲线、告警与三维绑定 | 核对同一设备,不让不同页面各自解释点位 |
| 异常与恢复 | 链路状态、服务状态、最后有效数据时间 | 区分采集失败、平台处理异常和页面连接问题 |
例如机房水泵状态异常,应从现场点表追到平台属性,再检查规则与画面,而不是先重启整套系统。容量评估需记录点位规模、更新频率、历史保存与硬件条件。架构原理详见下方技术文章,项目实施顺序仍由接口准备和业务目标决定。
进一步阅读:古河IBMS设备数据与数字孪生协同架构。