2. 地铁综合监控报警数据源与采集

综合监控系统（ISCS）的报警管理，本质上是对多源异构数据的汇聚、解析与再加工。报警不是凭空产生的，它来自BAS、FAS、PSCADA、ATS、CCTV等子系统各自的状态量、模拟量和事件记录。理解每个子系统的数据来源、接口协议和采集方式，是后续报警分级、抑制、联动和数据分析的前提。本节围绕“数据从哪来、怎么接、采集中容易出什么问题”展开。

一、典型子系统的报警数据来源

不同子系统的报警数据在产生机理和数据结构上差异明显，采集时必须区别对待。

BAS（环境与设备监控系统）的报警主要来自现场控制器（PLC/DDC）的I/O点。数字量输入点反映设备故障、手自动状态、过滤器堵塞等开关型报警；模拟量输入点则通过阈值判断产生越限报警，例如车站公共区温度超过28℃、CO₂浓度超过1000ppm、冷水机组回水温度异常等。BAS报警的特点是点位数量大、变化频率中等，且大量报警具有“持续性”特征——故障不消失，报警就一直存在。

FAS（火灾自动报警系统）的报警数据最为关键，包括探测器火警、手动报警按钮动作、消防设备反馈信号、系统故障等。FAS通常通过专用通信接口或干接点方式向ISCS传递信息，火警信号要求高可靠、低延迟。需要特别注意的是，FAS的火警与故障在语义上完全不同，采集时不能混为一谈。

PSCADA（电力监控系统）提供变电所内断路器位置、保护动作、遥测越限、通信中断等报警。保护动作类报警往往成组出现，一次故障可能同时触发多个开关变位和保护信号，采集端需要保留时标以支持后续的因果分析。

ATS（列车自动监控系统）的报警偏向运营事件，如列车晚点、进路排列失败、信号设备故障、列车停站超时等。ATS数据通常通过专用协议或消息队列方式交换，报警带有明确的列车标识和区段信息。

CCTV（闭路电视监控系统）本身产生的“报警”更多是设备级事件：摄像机离线、录像存储故障、视频信号丢失、移动侦测触发等。CCTV报警数量相对少，但对视频链路的完整性依赖强，采集时需关注设备心跳。

二、数据接口协议与采集方式

子系统与ISCS之间的接口协议选择，直接影响采集的实时性、稳定性和开发工作量。工程中常见以下几类：

• Modbus（RTU/TCP）：广泛用于BAS、部分PSCADA设备。以寄存器地址映射数据，采集端按功能码轮询。优点是通用、实现简单；缺点是无标准时标、无事件主动上报，报警只能靠轮询比对发现，且寄存器地址表必须与厂家严格核对。
• OPC（DA/UA）：常见于BAS、PSCADA的上位系统对接。OPC DA基于COM，适合局域网内Windows平台；OPC UA具备跨平台、内置安全与信息模型，逐渐成为新建线路的首选。OPC支持数据变化订阅，能显著降低无效轮询。
• SNMP：多用于CCTV、网络设备、UPS等IT类设备的运行状态采集，通过Trap接收设备主动上报的告警，通过Get轮询关键OID。
• 专用协议/消息接口：FAS、ATS常采用厂家专用协议或基于TCP的消息报文，需按接口协议文档逐条解析报文头、数据域和校验。

采集方式上，可分为轮询与订阅/主动上报两类。轮询实现简单但存在采集周期内的“盲区”，订阅方式实时性好但对通信链路和中间件稳定性要求更高。实际工程中常混合使用：模拟量用轮询，开关量变位和事件用订阅或Trap。

三、实时数据采集架构的关键环节

从图中可以看出，采集并非“连上就能读”，中间有几个必须做扎实的环节。

协议驱动与连接管理：每个子系统对应一个驱动实例，负责建立连接、维持心跳、处理超时与断线重连。工程上要为每个连接设置合理的超时时间和重连退避策略，避免子系统重启时采集端疯狂重连造成雪崩。

数据解析与规范化：把各协议原始数据映射为统一的点标识、工程值和状态码。这一步的核心是点表——点表错一位，报警就张冠李戴。点表必须与厂家提供的地址表逐条核对，并在调试阶段用已知状态验证。

时标与质量戳：每条数据都应携带采集时标和质量标识（GOOD/BAD/STALE）。通信中断时，不能继续沿用旧值当作有效数据，而应标记为BAD或STALE，否则报警分析会得出错误结论。

变位检测与阈值判断：开关量通过前后值比较识别变位，模拟量通过死区和阈值判断越限。为防止信号抖动造成报警刷屏，通常设置防抖时间（如2～3秒内状态稳定才确认）。

四、常见采集问题与排查思路

实际运维中，采集问题往往表现为“报警不准、报警不来、报警太多”三类。下面给出一个可参考的排查要点表，参数为示例性建议值，需结合具体线路调整。

采集是报警管理的地基。只有把数据来源摸清、协议接稳、质量戳和时标做规范，后续的报警分级、抑制、联动和数据分析才有可靠输入。反之，采集层的任何疏漏都会在报警层面被放大，最终影响运营人员的判断。