1. ISCS系统架构与联动接口全景

地铁综合监控系统（ISCS，Integrated Supervisory Control System）是运营指挥中心与各机电、行车辅助系统之间的“神经中枢”。它并不直接控制列车运行，也不替代各专业子系统自身的控制器，而是通过统一的数据采集、集中监视与联动指挥，把分散在车站、区间、车辆段内的环控、电力、火灾报警、乘客信息、广播、门禁、自动售检票等系统整合到同一操作界面下。理解 ISCS，首先要厘清它在 metro 体系中的定位：ISCS 是面向运营的集成监视与联动指挥层，位于各专业子系统之上、行车调度系统（ATS）之侧，承担“看得全、联得动、管得住”的职责。

一、ISCS 在 metro 中的定位与分层

从控制层级看，地铁自动化系统通常可划分为现场设备层、专业控制层、综合监控层和运营指挥层。现场设备层是传感器、执行器、风机、水泵、开关柜等真实对象；专业控制层是 BAS（环境与设备监控）、PSCADA（电力监控）、FAS（火灾自动报警）等子系统自身的 PLC、控制器与就地工作站；综合监控层即 ISCS，通过接口网关与各专业控制层交换数据；运营指挥层则是 OCC 调度员、车站值班员依据 ISCS 画面与报警进行决策。ISCS 的价值在于打破“专业孤岛”：过去火灾报警在 FAS 盘上、环控在 BAS 工作站上、电力在 PSCADA 上，联动要靠人工电话确认；集成后，一个火警信号可自动触发排烟风机启动、广播切换、闸机释放、PIS 显示疏散信息，形成秒级响应的联动链。

需要明确的是，ISCS 与 ATS 是并列协作关系而非隶属关系。ATS 负责列车运行自动监控与进路排列，ISCS 负责车站机电设备与乘客服务设施，两者通过接口交换列车到发、阻塞、火灾等关键信息，共同支撑“行车—设备—乘客”三位一体的运营指挥。

二、子系统划分与接口对象

按集成深度，ISCS 接入的子系统一般分为两类。深度集成子系统由 ISCS 直接提供操作界面，甚至由 ISCS 工作站替代其就地工作站，典型如 BAS、PSCADA；互联子系统则保留自身独立系统与工作站，仅通过接口向 ISCS 上传状态、接收联动命令，典型如 FAS、PSD（站台门）、AFC、PIS、PA、CCTV、门禁、时钟等。划分依据主要是安全等级、实时性要求与既有系统成熟度：FAS 涉及消防认证，通常保持独立并只做互联；BAS 与 PSCADA 设备量大、联动频繁，适合深度集成。

接口对象可按“谁给谁数据、谁听谁命令”梳理。以火灾联动为例：FAS 向 ISCS 上送火警位置与等级；ISCS 联动引擎据此向 BAS 下发排烟模式命令、向 PSD 下发开门或保持命令、向 PA 下发消防广播、向 AFC 下发闸机释放、向 PIS 下发疏散提示。这里存在明确的数据流方向与命令流方向，接口调试时必须逐条核对点表的方向、类型（模拟量/开关量）、刷新周期与异常默认值。

三、联动场景的分类

联动场景可按触发源与影响范围分类，这是接口设计与调试的主线。火灾类联动是最高优先级场景，涉及排烟、疏散、闸机释放、电梯归位，要求毫秒级到秒级响应，且必须考虑误报与故障降级；行车类联动包括列车到站触发 PIS 到站信息、PA 到站广播、站台门与列车门对位联动；客流与运营类联动包括大客流时 AFC 限流、CCTV 预置位切换、PIS 引导；设备故障类联动如冷水机组故障时自动切换备用机组并推送报警。不同场景对接口实时性、可靠性、人工确认环节的要求差异很大，不能一套逻辑通吃。

四、接口管理总体流程

接口管理贯穿设计、实施、调试、运维全过程，核心是把“谁和谁、传什么、怎么传、传不到怎么办”固化下来。典型流程为：接口识别（依据系统清单与联动场景列出全部接口对）→接口协议确定（明确物理介质、通信协议如 Modbus TCP、IEC 104、OPC、SNMP，以及点表结构）→点表编制与评审（逐点定义点号、名称、方向、数据类型、量程、刷新周期、默认值）→接口开发与联调（先单系统自测，再点对点通信测试，最后场景联动测试）→问题闭环与版本管理（接口变更留痕，点表版本与现场一致）→运维移交（接口台账、故障处置手册）。其中点表是接口管理的“合同”，方向写反、量程错位是联调阶段最常见的返工原因。

五、课程任务地图

本课程后续将沿“架构认知—接口设计—联动实现—调试验证—运维管理”展开：先建立系统分层与子系统清单，再深入点表与协议，随后进入火灾、行车、客流等典型联动场景的逻辑实现，最后落到联调测试用例、故障排查与接口台账维护。学习时应始终带着两个问题：这个接口的数据流向是什么？联动失败时，降级与人工接管路径是否清晰？把这两点想透，ISCS 的集成价值才能真正落地。