1. VOBC在CBTC系统中的角色定位

CBTC(基于通信的列车控制)系统是一个以“车—地双向连续通信”为核心的安全相关列车运行控制系统。要理解车载控制器VOBC(Vehicle On-Board Controller)的角色,先要看清整个系统的分层结构:最上层是列车自动监控子系统ATS,负责运行图、进路安排与列车调度;中间层是区域控制器ZC和计算机联锁CI,分别承担移动授权计算与道岔/信号机等轨旁设备的安全联锁;最贴近列车的一层,就是车载控制器VOBC以及地面应答器、无线接入设备等。VOBC不是孤立工作的,它处在“地面决策—车地传输—车载执行”这条链路的末端,同时又是列车实际运行状态的采集源头。

从功能边界看,VOBC承担三类核心职责。第一是定位与测速:通过应答器校正、轮轴速度传感器测速与雷达辅助,确定列车在轨道上的位置和运行方向,并把位置报告周期性地发给ZC。第二是安全防护:接收ZC下发的移动授权(MA),结合线路限速、临时限速、车门状态等条件,生成速度监督曲线,一旦实际速度接近或超过允许速度,就触发制动输出。第三是驾驶控制与接口管理:在ATO模式下输出牵引/制动指令,在人工驾驶模式下提供超速防护,同时管理与车门、牵引制动系统、乘客信息系统等车载设备的接口。需要强调的是,VOBC不负责进路排列和道岔控制,那是CI的职责;VOBC也不直接决定列车运行计划,那是ATS的职责。VOBC的边界可以概括为:对下管列车本体,对上服从地面授权,安全职责聚焦于“不超速、不越授权、不误开车门”。

CBTC系统分层组成与VOBC接口关系 ATS 列车自动监控 运行图 · 进路安排 · 调度 ZC 区域控制器 移动授权MA计算 CI 计算机联锁 道岔 · 信号机 · 进路锁闭 VOBC 车载控制器 定位测速 · 速度监督 · 制动输出 · 接口管理 MA / 限速 进路状态 应答器 / 轮轴传感器 位置校正 · 测速 牵引 / 制动系统 指令执行 · 状态反馈 车门 / PIS 开关门监督 · 信息发布 橙色链路为安全相关授权与状态交互;紫色链路为车载设备接口

接口关系是理解VOBC定位的关键。VOBC与ZC之间通过无线网络交换两类信息:VOBC上报列车位置、速度、运行方向与完整性状态,ZC据此计算并向VOBC下发移动授权和线路限速。这条链路是安全相关的,通信中断时VOBC必须按“失去授权”处理,导向安全侧制动。VOBC与CI之间通常不直接通信,而是通过ZC间接获取进路和信号状态,部分制式下通过应答器或轨旁环线获得点式信息。VOBC与车载设备的接口则包括:从轮轴传感器和雷达获取速度,从应答器天线获取绝对位置校正点,向牵引制动系统输出控制指令并读取其状态反馈,与车门系统交换开关门允许条件。这些接口中,涉及安全输出的部分(如制动指令、开门允许)必须按安全相关接口设计,涉及非安全信息的部分(如PIS报站)可按非安全接口处理。

这就引出安全完整性等级(SIL)的概念。SIL是衡量安全功能在指定条件下将风险降低到可接受水平能力的等级,通常按IEC 61508体系分为SIL1至SIL4,等级越高,对随机硬件失效概率和系统性失效控制的要求越严。在CBTC中,VOBC的速度监督与超速防护、移动授权执行、车门安全联锁等功能通常要求达到SIL4,因为一旦失效可能直接导致列车冲突或脱轨等严重后果;而ATO的舒适性调节、PIS信息发布等非安全功能一般按较低等级或非安全功能处理。工程上判断一个功能属于哪个等级,要看它失效后的后果严重度、暴露频率和可控性,而不是看它“重不重要”。例如“VOBC向ZC报告位置”这一功能,如果位置报告错误会导致ZC给出错误授权,那么它同样属于安全相关功能,需要按相应等级设计。

学习本节时可以用一句话建立整体印象:ATS“定计划”,ZC“发许可”,CI“锁进路”,VOBC“守底线”。VOBC的安全底线就是速度监督、授权执行和车门联锁三条,其余功能都围绕这三条展开。

从开发角度看,明确VOBC的角色定位直接决定了后续工作的边界。做需求分析时,要先把VOBC的功能划分为安全功能与非安全功能,分别对应不同的SIL目标;做接口设计时,要区分安全相关接口与非安全接口,安全接口需要定义失效响应和故障导向安全策略;做测试验证时,安全功能要按对应SIL等级设计覆盖率与故障注入用例。例如在验证超速防护功能时,不能只测“正常减速”,还要注入测速传感器失效、MA突然缩短、制动反馈丢失等故障场景,观察VOBC是否在规定时间内输出制动并保持到安全状态。这些工作都建立在“VOBC是安全执行末端、服从地面授权、守护列车本体”这一定位之上。

需要提醒的是,不同厂商的CBTC制式在VOBC与地面的具体分工上存在差异,例如有的系统把部分速度监督逻辑放在ZC,有的把完整列车完整性检查放在VOBC。因此在实际项目中,功能边界必须以该制式的系统需求规格书和接口控制文件为准,不能把本节的一般性描述直接当作某个具体项目的实现依据。理解角色定位的意义,在于建立“谁负责什么、失效时谁兜底”的判断框架,而不是记住一张固定的功能清单。