建筑物联网平台怎么选？与通用IoT平台的区别、六个硬指标与验证方法

一、先判断缺的是哪一层能力

通用IoT平台可以通过网关和行业应用服务建筑场景；建筑物联网平台也需要核对具体接口与项目版本。产品名称不能代替能力证明。已有楼控、能源或集团平台时，应先梳理能够复用的采集与数据服务，再确定需要补齐的层次。

更完整的类别比较见建筑物联网平台与通用IoT平台。本文重点是如何验证候选产品。

二、六项指标怎样转成验收材料

协议清单应由项目设备决定，不必为了凑齐无关协议增加建设范围。现场采集吞吐、内部消息处理吞吐和历史落库吞吐是不同指标，不能用其中一个数代替全部能力。

三、用一台空调机组走通数据链

准备

选一台有代表性的机组，确认温度、运行、故障等点位与单位，准备现场核对方法、网关位置及设备负责人。只读验证可先开展，写值测试单独确认。

正常链路

追踪一个温度值经过采集、属性映射、页面订阅与历史查询的过程。比较来源和时间，不要求所有页面在任意瞬间数值完全相同。

异常链路

在获准条件下模拟通信中断，观察界面是否把旧值标成过期；恢复后分别检查最新值和历史记录。源设备没有保存的数据不能凭空补传。

变更链路

更改显示名称或更换样板设备，核对空间位置、告警规则、历史身份和应用引用，形成可交接的变更记录。

四、如何使用性能资料比较候选方

先约定项目常态、峰值和扩展场景，再按相同条件测试。记录软硬件版本、设备或模拟器、协议与点位类型、变化比例、保存策略、并发用户、持续时间和判定方法。容量余量由增长计划和运行要求确定，不统一套用固定倍数。

公开的历史吞吐与背压实测可以帮助理解测试方法，不能直接换算成任意设备的扫描容量，也不能将某次零丢数结果作为所有场景保证。源端、接收端和存储端最好分别对账，解释积压何时清空。

五、古河平台在项目中的分工

古河BIOT物联网中台侧重设备与数据治理，古河IO数据采集服务器及采集组件承担现场协议通信，古河IBMS与数字孪生平台复用约定的数据服务。平台业务沿用Java / Spring Cloud架构口径，现场驱动、网关与业务服务分层确认。

首次交流可提供一个典型子系统点表、网络图、现有系统接口和一个业务目标。最终交付应包括映射表、接口文档、异常处理说明与维护方法，使后续集成商和运维人员能够复查。

相关产品、方案与公开案例

常见问题FAQ

建筑物联网平台和通用IoT平台怎么比较？

比较具体项目能力：现场协议、空间与设备关系、历史与告警、开放接口及持续维护。通用平台可以通过网关和行业应用服务建筑，不能只凭类别判断适用性。

选型阶段必须准备什么？

准备典型点表、设备与协议清单、网络拓扑、现有平台接口和一个具体业务任务。涉及写值时另行确认授权与现场条件。

一个平台能接多少点位？

需同时说明设备类型、协议、采集周期、变化率、历史保存和并发负载。历史吞吐实测只代表对应环境，项目容量应在约定条件下核对。

已有楼控还需要新建物联网平台吗？

先核对既有楼控与数据接口。若已满足共享与管理需求，可以复用；需要跨系统治理或扩展时，再补所缺能力，不必重复采购整套平台。

怎样减少后续对厂商的依赖？

要求交付可使用的接口文档、配置与映射资料、导出方法和维护工具，并让接收方实际完成一次查询与设备变更。