方案说明
SCENARIO
快速答案
采集网关解决方案是南京古河软件基于IO数据采集服务器IOSERVER的现场数据接入方案：在靠近设备侧完成Modbus、BACnet、OPC UA、SNMP、MQTT、DL/T 645、CJ/T 188等协议适配、边缘缓存、断点续传和点位治理，为IBMS、能源管理、数字孪生和AI智能运维提供稳定一致的数据底座。
建议验收基线：点位采集成功率≥99.5%、网络中断后断点补传完成时间≤5分钟、数据时标与NTP时钟偏差≤5秒、数据服务接口可用率≥99.5%。控制类点位默认关闭，经权限确认、现场测试和结果回采验证后再逐步开放。
采集网关解决方案：把现场设备稳定接入智慧建筑平台
采集网关是智慧建筑、智慧园区、医院后勤、能源管理、数字孪生和AI智能运维的现场数据入口。很多项目在方案阶段容易把它写成“支持多协议采集”的一句话，但真正落地时，问题往往出在更细的地方：现场设备是否能开放协议，点表是否准确，串口和网络是否稳定，采集频率是否合理，数据断点后能否补传，控制点位是否有权限边界，异常数据是否会影响上层报表。采集网关方案的价值，就是把这些容易被忽略的工程细节前置处理，让现场数据能够长期稳定地服务上层平台。
在古河软件的智慧建筑体系中，采集网关通常与IOSERVER、BIOT建筑物联网数据中台和IBMS智慧建筑管理平台配合使用。IOSERVER负责靠近现场的协议接入、边缘缓存、数据转发和通讯监测；BIOT负责设备模型、点位治理、历史数据、告警事件和开放接口；IBMS、BEMS、数字孪生和AI智能运维在此基础上完成监控、分析、联动和运营管理。采集网关不是一个孤立硬件，也不是简单的协议转换器，而是现场数据工程的第一道质量关。
一、适用场景
- 新建智慧建筑项目：在弱电和智能化系统建设阶段，同步规划楼控、配电、能耗、环境、安防、停车、门禁和第三方系统的采集边界。
- 既有建筑改造项目：面对多个厂家、多个年代、多个协议的系统，通过采集网关逐步接入，避免一次性替换存量系统。
- 智慧园区多楼栋项目：在不同楼栋、机房或弱电间部署边缘采集节点，把多楼栋数据统一汇聚到园区平台。
- 医院后勤与实验室项目：优先接入配电、暖通、医气、冷链、净化、环境、纯水、气体和重点设备状态，为后勤连续运行提供数据基础。
- 能源管理项目：接入电表、水表、冷热量表、燃气表和关键设备运行数据，支撑分项计量、异常用能分析和节能复盘。
- 数字孪生和AI运维项目：向上层提供带有空间、设备、点位语义和质量状态的数据，避免三维场景和AI分析建立在不可靠点位上。
二、需要解决的核心问题
采集网关建设不是把所有点位“接进来”就结束，而是要保证这些数据能够被理解、被验证、被追溯、被复用。现场设备的数据来源复杂，既有标准协议，也有厂家私有接口；既有实时控制器，也有周期性表计；既有只读监测点，也有涉及安全的控制点。不同数据的采集频率、存储周期、异常处理和权限边界都不同，如果前期不做治理，后续IBMS页面、能耗报表、数字孪生场景和AI运维都会反复返工。
- 协议复杂：Modbus、BACnet、OPC、SNMP、MQTT、HTTP API、数据库视图、串口设备和厂家SDK同时存在。
- 点表不准：点位名称、单位、倍率、读写属性、寄存器地址、数据类型和采样周期经常与现场实际不一致。
- 网络不稳：地下空间、机房、楼栋之间、弱电井和隔离网络容易出现链路波动，影响连续采集。
- 数据质量不可控：离线、缺失、突变、长时间不变、重复点位、时标错误会影响报表和告警判断。
- 边界不清：哪些点位只读、哪些点位可控、哪些控制动作需要人工确认，必须在实施前定义清楚。
- 运维困难：如果网关自身状态、采集日志、接口失败和数据队列不可见，后期排查会依赖经验。
三、建设目标
- 建立现场设备、第三方系统、协议接口、点位清单、网络链路和数据用途之间的完整关系。
- 通过采集网关完成多协议适配、边缘缓存、断点续传、数据转发、通讯监测和异常上报。
- 通过数据中台完成设备模型、点位命名、空间关系、质量标记、历史存储和接口服务。
- 为IBMS、能源管理、数字孪生、AI智能运维、移动运维和第三方系统提供稳定一致的数据来源。
- 形成可验收、可运维、可扩展的采集体系，让后续新增设备和新增系统可以按规范接入。
四、方案边界
采集网关方案重点解决现场侧和平台侧之间的数据接入与数据质量问题。它不替代IBMS的业务管理能力，也不替代能源管理、数字孪生或AI智能运维的专题应用能力。它的边界应当清晰：现场侧负责协议、通讯、缓存和数据上报；数据中台负责模型、质量、历史和开放接口；业务平台负责监控、告警、联动、报表和工单。边界清楚，项目实施时才不会把所有问题都堆给某一个软件模块。
总体架构
ARCHITECTURE
总体架构
采集网关建设建议采用“现场设备层、边缘采集层、数据治理层、业务应用层、运维安全层”的分层架构。分层的目的不是增加复杂度，而是让每一层职责明确：现场设备负责产生数据，采集网关负责稳定接入，数据中台负责治理与服务，业务平台负责管理与运营，安全运维体系负责权限、审计和持续维护。
1. 现场设备层
现场设备层包括传感器、仪表、控制器、PLC、DDC、楼控主机、能耗表计、UPS、精密空调、冷机、泵房、电梯接口、消防接口、视频平台、门禁停车系统以及各类厂家网关。实施前应逐项确认设备厂家、通讯方式、协议版本、点位数量、读写属性、安装位置和责任方。对于无法直接开放协议的设备，应确认是否可以通过上位机、数据库、转发接口或厂家SDK获取数据。
2. 边缘采集层
边缘采集层以IOSERVER或采集网关为核心，部署在机房、弱电间、楼栋汇聚点或现场网络边界处。它负责协议驱动、轮询采集、事件订阅、数据缓存、断点续传、异常上报和安全转发。边缘采集层应尽量靠近现场设备，减少跨网段、跨楼栋和跨安全域带来的不确定性。对于多楼栋园区，可采用多网关分布式部署，再由数据中台统一汇聚。
3. 数据治理层
数据治理层负责把原始点位整理成可被业务理解的数据对象。一个寄存器值或一个OPC变量本身没有管理意义，必须绑定设备、空间、系统、单位、量程、状态含义和质量状态。BIOT建筑物联网数据中台在这一层维护设备模型、点位字典、历史数据、告警事件、数据质量和开放接口，使同一份数据能够被IBMS、BEMS、数字孪生和AI智能运维共同使用。
4. 业务应用层
业务应用层包括IBMS集中监控、BEMS能源管理、数字孪生、AI智能运维、移动运维、报表中心和第三方业务系统。采集网关不直接承担这些业务逻辑，但数据质量会决定业务应用的上限。比如能耗分析要求计量数据准确且连续，数字孪生要求点位与空间对象绑定，AI运维要求点位语义清楚，IBMS联动要求状态和控制反馈可靠。
5. 运维安全层
运维安全层贯穿整个架构，包括网关运行监测、通讯日志、接口调用记录、账号权限、控制确认、数据备份、版本管理和异常点位维护。采集系统上线后，最常见的问题不是页面缺功能，而是某个设备离线、某个点位倍率错误、某条链路不稳定或某个第三方接口调整。没有运维安全层，采集网关会在项目交付后逐渐变成黑盒。
部署建议
单体建筑可在中心机房部署一台或多台采集网关，按系统划分协议驱动和采集任务。
多楼栋园区建议按楼栋或区域部署边缘网关，本地缓存后统一上传数据中台。
医院与实验室关键系统优先独立接入，控制类点位与监测类点位分权管理。
云边协同现场侧保留采集、缓存和基础告警能力，云端负责统一管理和远程服务。
标准与协议依据
采集网关方案的核心是协议与数据口径。古河网关在工程中常用的协议和规约包括：
- Modbus RTU/TCP：配电、暖通、表计等现场设备最常见的通讯协议。
- BACnet（ISO 16484-5）：楼宇自控系统及DDC控制器的标准协议。
- OPC UA（IEC 62541）：与第三方平台和工业系统交换数据的通用接口。
- MQTT（ISO/IEC 20922）：网关向云端和数据中台转发数据的消息协议。
- SNMP：机房网络设备、UPS和动环监控的管理协议。
- DL/T 645-2007：多功能电能表通讯规约，电力计量接入依据。
- CJ/T 188-2018：水表、热量表等户用计量仪表的数据传输规约。
- HJ 212-2017：涉及环保数据上报场景时的数采仪传输标准。
现场存在私有协议时，应在方案阶段确认厂家是否提供协议文档或SDK，并预留协议开发工作量。
接入与数据治理
DATA GOVERNANCE
接入对象与数据治理
1. 接入对象梳理
采集网关实施的第一步是现场盘点。盘点不是简单统计点位数量，而是要把设备、协议、网络、点表、业务用途和责任方放在同一张接入矩阵里。只有接入矩阵清楚，后续报价、实施、联调、验收和运维才有依据。
- 机电设备：变配电、冷源、热源、空调机组、风机盘管、水泵、给排水、电梯、照明、UPS和机房环境。
- 能源计量：多功能电表、水表、冷热量表、燃气表、蒸汽表、租户分表和设备级计量表。
- 环境监测：温湿度、PM2.5、CO2、VOC、噪声、水浸、气体、压差和实验室专业环境指标。
- 安防与通行：门禁、道闸、停车、访客、视频平台、周界、巡更和广播系统。
- 专业系统：医气、冷链、净化、纯水、危化品柜、管廊气体、排水、通风和机器人巡检接口。
- 第三方平台：既有楼控平台、能源平台、物业工单、资产台账、收费系统和上级监管平台。
2. 协议与接口方式
不同协议的接入方式和风险不同。Modbus适合表计和PLC，但需要核对寄存器地址、数据类型和倍率；BACnet常见于楼控系统，需要确认对象实例、属性和网络路由；OPC适合与工业或楼控上位机集成，需要处理权限和稳定性；SNMP常用于UPS、交换机和机房设备；MQTT和HTTP API适合平台间数据交换；数据库接口则需要明确字段含义、刷新周期和只读权限。
Modbus重点核对寄存器、数据类型、字节序、倍率、轮询周期和串口链路质量。
BACnet重点核对设备实例、对象列表、属性含义、网络路由和订阅方式。
OPC重点核对点位路径、访问权限、服务稳定性、断线重连和数据质量位。
MQTT/API重点核对认证方式、主题或接口字段、调用频率、失败重试和版本管理。
数据库重点核对只读权限、字段口径、刷新周期、时间戳和历史数据范围。
3. 点位治理
点位治理决定采集数据能否长期使用。项目中常见的失败点，是把厂家点表原封不动导入平台，导致点位名称难懂、单位不统一、重复点位混杂、控制点位权限不清。采集网关方案应在接入阶段建立统一点位字典，并与空间、设备、系统和业务用途绑定。
- 点位编码：建议包含项目、楼栋、系统、设备、属性等信息，保证唯一性和可维护性。
- 点位名称：使用运维人员能理解的中文名称，避免只保留厂家缩写或寄存器名称。
- 单位与倍率：电量、电流、温度、压力、流量、能耗等点位必须核对单位和倍率。
- 读写属性：只读监测点、可写控制点、模式点和设定值点必须区分。
- 采样周期：状态、告警、能耗、环境和设备运行点位应按业务用途设置不同频率。
- 质量状态：离线、超时、异常、手动修正、补传数据应有质量标记，避免误用于报表。
4. 设备模型与空间关系
采集数据必须落到设备和空间上。一个“温度值”只有绑定到楼栋、楼层、房间、设备或区域，才能用于告警定位、能耗分析、数字孪生展示和工单派发。建议在数据中台中建立设备模型，把点位归属于具体设备，再把设备归属于空间和责任班组。
5. 数据质量机制
- 在线率监测：持续监测网关、设备、协议连接和点位在线状态。
- 完整率监测：检查采集周期内是否存在缺失、重复、补传失败或异常空值。
- 突变监测：对能耗、温度、压力、液位等连续量设置合理突变规则。
- 长时间不变监测：对应该波动的点位识别卡死或通讯假在线。
- 人工修正记录：如需修正历史数据，应记录修正原因、操作人和修正前后值。
- 数据质量报表：每周或每月输出异常点位、接口失败和整改进度。
业务流程与联动
WORKFLOW
核心建设内容与联动流程
1. 现场勘测与点表核对
采集网关建设应从现场勘测开始。实施人员需要确认设备位置、网络条件、通讯端口、协议开放情况、点表版本和厂家配合窗口。对于串口设备，要检查通讯距离、接线方式、终端电阻和串口服务器配置；对于网络设备，要检查IP规划、VLAN、防火墙、路由和安全隔离要求；对于第三方平台，要确认接口文档、账号权限、测试环境和正式环境。
2. 网关部署与通讯测试
网关部署完成后，不应马上进入大规模点位导入，而应先做小样本连通测试。选取每类协议、每类设备、每个网络区域的代表点位，核对实时值、历史值、状态变化、异常恢复和断线重连。只有样本测试通过，再批量导入点位，能显著降低后期返工。
- 确认网关运行状态、CPU、内存、磁盘、网络和服务自启动。
- 确认每个协议驱动的连接状态、轮询周期、失败重试和日志记录。
- 确认断网、设备离线、平台不可达时的数据缓存和恢复策略。
- 确认网关到BIOT或IBMS的数据上传方式、认证方式和失败处理。
- 确认关键控制点位是否被默认禁用，待权限和流程确认后再开放。
3. 数据上送与平台复用
采集数据上送到数据中台后，应经过模型绑定和质量检查，再开放给上层应用。IBMS需要实时状态和告警，能源管理需要连续计量和倍率准确，数字孪生需要空间位置和设备关系，AI智能运维需要点位语义和历史上下文。不同应用使用同一份数据，但关注点不同，因此数据中台应提供统一接口，而不是让每个业务系统重新接入现场。
4. 异常处理流程
- 设备离线：系统标记离线点位，通知运维人员检查设备电源、通讯线路、协议服务和网关状态。
- 数据突变：系统保留原始值并标记异常，避免直接影响能耗统计和趋势分析。
- 接口失败：记录接口返回、失败时间、重试次数和影响范围，必要时生成维护工单。
- 网关离线：触发平台告警，检查现场网络、电源、进程状态和远程连接。
- 控制失败：记录下发命令、执行反馈、失败原因和人工处理结果。
- 点位变更：通过变更单更新点位字典、模型关系、页面配置和验收记录。
5. 与业务系统的联动
采集网关本身不负责复杂业务流程，但它必须为业务联动提供可靠触发条件和结果反馈。比如设备运行异常进入IBMS告警中心，计量点离线进入能源数据质量报表，环境指标超限联动工单或通知，关键设备控制动作需要回采执行结果。没有回采，联动就无法判断是否真正生效。
IBMS联动设备状态、故障告警、运行模式和控制反馈进入统一监控与告警中心。
能源联动计量数据、倍率、补传和质量标记进入分项统计和异常用能分析。
数字孪生联动点位绑定空间对象，支持三维状态、告警定位和设备面板。
AI运维联动点位语义、历史趋势、告警记录和设备关系作为AI分析上下文。
工单联动网关离线、设备通讯异常、点位质量问题可转为维护任务。
6. 控制安全边界
采集网关可以支持读写点位，但控制能力必须谨慎开放。建议默认先完成只读监测，待点位准确、权限明确、现场测试通过后，再逐步开放控制点位。控制动作应具备权限校验、二次确认、执行日志、结果回采和失败回退。对医院、实验室、管廊、配电、冷热源等关键系统，控制边界应由业主、运维单位和集成商共同确认。
实施路径与角色分工
DELIVERY
实施路径与角色分工
阶段一：现场调研与接入设计
这一阶段要完成系统盘点、设备清单、点表收集、接口方式确认、网络边界确认和实施计划编制。输出成果应包括接入系统矩阵、协议适配清单、网络拓扑、点位样表、风险清单和实施排期。对于厂家接口不明确或点表缺失的系统，应在此阶段形成问题清单，不应等到现场联调时再处理。
阶段二：网关部署与协议联调
根据楼栋、机房、网络区域和系统类型部署采集网关。联调时先做代表点位测试，再进行批量点位导入。每类协议都应记录连接方式、采集周期、失败重试、日志位置和异常处理方法。对跨网段或隔离区接入，应同步完成网络安全确认。
阶段三：点位治理与模型绑定
点位导入后，需要完成命名规范、单位倍率、设备归属、空间归属、告警阈值、质量规则和历史存储配置。这个阶段最容易被压缩，但它决定后续平台能否长期使用。建议由实施人员、业主运维人员和厂家人员共同抽查点位，确认数据与现场实际一致。
阶段四：业务联调与试运行
业务联调包括IBMS页面、能源报表、数字孪生状态、告警中心、工单联动和第三方接口调用。试运行期间应重点观察离线点位、异常点位、接口失败、网关资源、数据延迟和业务页面使用情况。试运行不是走形式，而是发现数据问题和运维问题的关键阶段。
阶段五：验收与运维交接
验收前应准备接入清单、点位字典、网关配置、接口文档、联调记录、异常整改记录、培训资料和运维手册。运维交接不仅交账号和页面，还要交付排障方法：网关离线怎么查、某个协议失败怎么查、点位数值异常怎么查、接口失败怎么查、控制失败怎么查。
角色分工
业主或建设单位确认建设目标、接入范围、系统边界、控制权限、验收标准和长期运维责任。
系统集成商负责现场勘测、网络协调、厂家接口配合、网关部署、联调测试和资料汇总。
软件实施团队负责协议配置、点位治理、模型绑定、接口服务、页面联调和运维培训。
设备厂家提供协议文档、点表、接口账号、SDK、测试支持和现场故障配合。
运维团队参与点位核对、告警规则确认、试运行反馈和后续日常维护。
项目风险与控制措施
- 接口不开放：提前确认厂家协议、SDK、数据库、转发接口或替代采集方案。
- 点表不准确：建立样本点位测试和现场抽查机制，不直接信任旧点表。
- 网络不稳定：关键楼栋或机房采用边缘缓存和断点续传，减少网络波动影响。
- 数据误用：通过质量标记和异常规则避免错误数据进入能耗、报表和AI分析。
- 控制风险：控制类点位默认关闭，经过权限、确认、测试和回采后再开放。
- 运维断档：交付时必须培训排障方法，并提供网关配置、日志位置和问题处理流程。
验收口径与运维指标
ACCEPTANCE
验收口径与运维指标
一、验收内容
- 接入范围验收：核对系统清单、设备清单、协议清单和点位清单，确认与合同和设计范围一致。
- 通讯稳定验收：抽查不同协议、不同楼栋、不同网络区域的连接状态、离线恢复和日志记录。
- 数据准确验收：抽查实时值、单位、倍率、状态含义、历史曲线和现场设备显示是否一致。
- 断点续传验收：模拟网络中断、平台不可达或网关重启，检查缓存和补传结果。
- 质量标记验收：验证离线、缺失、突变、长时间不变和接口失败是否能被识别。
- 接口服务验收：验证IBMS、能源、数字孪生或第三方系统能通过统一接口调用数据。
- 权限审计验收：验证控制点位、账号权限、操作日志、人工确认和执行回采。
- 文档交付验收：检查点位字典、接口文档、网关配置、联调记录、培训记录和运维手册。
二、建议指标
点位在线率统计周期内正常通讯点位占比，需区分设备离线、网关离线和接口失败原因。
数据完整率按采样周期统计应采数据与实际入库数据的完整程度，能源和报表类点位尤其关键。
采集延迟从现场设备变化到平台可见的时间差，不同业务场景可设置不同要求。
断点续传成功率网络或平台中断后，缓存数据恢复上传的成功比例。
异常点位修复周期从异常发现到恢复正常的平均时间，用于评价运维效率。
接口可用率上层系统调用数据服务的成功率和响应稳定性。
三、运维报表
采集网关上线后，建议至少形成周报和月报。周报关注网关在线、协议连接、异常点位、接口失败和整改进度；月报关注数据完整率、点位变更、系统扩容、接口调用、历史数据质量和上层应用使用情况。对于能源、医院、实验室和管廊等关键场景，还应保留专项报表，便于问题追溯和责任界定。
验收指标建议基线
采集层的质量决定上层所有应用的可信度。古河建议采集网关项目按以下基线验收：
- 点位采集成功率 ≥ 99.5%（按日统计，剔除设备本体故障）。
- 网络中断恢复后，断点数据补传完成时间 ≤ 5 分钟。
- 点表核对错误率 ≤ 0.5%，单位、倍率和状态含义逐点确认。
- 数据时标与NTP时钟偏差 ≤ 5 秒。
- 向上层平台的数据服务接口可用率 ≥ 99.5%。
验收抽查应覆盖不同协议、不同楼栋和不同网络区域，避免只测试单一链路。
四、常见问题
- 采集网关和物联网数据中台有什么区别？
- 采集网关部署在现场侧，重点解决协议适配、通讯稳定、边缘缓存和数据转发；物联网数据中台部署在平台侧，重点解决设备模型、点位治理、历史数据、告警事件和开放接口。两者配合才能形成可复用的数据底座。
- 采集网关是否可以直接控制设备？
- 技术上可以支持读写点位，但不建议默认开放控制。控制类点位应经过权限确认、现场测试、二次确认、执行日志和结果回采，关键系统还应设置人工审批和回退措施。
- 为什么采集网关方案要强调点位治理？
- 因为上层平台使用的是带语义的数据，而不是原始寄存器或厂家变量。点位治理能明确设备归属、空间位置、单位、倍率、状态含义和质量状态，直接影响IBMS、能源管理、数字孪生和AI运维的可靠性。
- 既有系统没有标准协议怎么办？
- 可以先评估数据库、厂家SDK、文件交换、HTTP接口、平台转发或只读页面数据等替代方式。若确实无法接入，应在方案中明确边界，避免后续实施阶段产生不可控风险。
五、建设成果与交付判断
一个合格的采集网关项目，最终交付的不只是网关程序和一批点位，而是一套能被运维团队继续维护的数据接入体系。交付后，业主应能够清楚知道每个系统由谁提供接口、每类协议如何排障、每个点位代表什么设备和空间、哪些数据可以进入报表、哪些控制动作需要审批、哪些异常会自动生成维护任务。只有做到这些，采集网关才真正从“项目联调工具”变成“长期运营基础设施”。
因此，验收时建议把成果分为三类：第一类是技术成果，包括网关部署、协议驱动、点位入库、缓存补传和接口服务；第二类是管理成果，包括点位字典、设备模型、权限角色、质量规则和操作日志；第三类是运营成果，包括数据质量报表、异常点位台账、接口巡检机制和后续扩展流程。三类成果同时成立，才能支撑后续IBMS、能源管理、数字孪生和AI运维稳定运行。
相关产品组件
工程案例参考
相关专题与文章
按应用场景查看解决方案
面向不同建设目标，把产品能力、行业场景和工程案例组织在一起，便于业主、集成商和运维团队快速判断方案边界、建设重点和落地路径。
微信咨询
