4. VOBC软件架构与分层设计

VOBC（车载控制器）是CBTC系统中直接承担列车超速防护、精确停车、车门/站台门联动和自动驾驶控制的安全关键设备。它的软件不是一堆功能代码的简单堆叠，而是按"安全等级"和"实时性要求"严格分层的结构：底层负责隔离硬件与提供确定性执行环境，中间层把安全逻辑封装成可复用的服务，上层实现具体的驾驶模式与运营功能。理解这套分层，是读懂VOBC代码、定位故障、评估改动影响范围的前提。

一、操作系统与安全中间件：确定性执行与安全封装

VOBC的操作系统通常采用实时操作系统（RTOS），如VxWorks、QNX或经过认证的嵌入式Linux实时补丁版本。选择RTOS的核心原因不是"功能多"，而是可预测的响应时间：列车在120 km/h运行时，每毫秒约前进33 mm，制动指令的延迟必须被限定在确定的上界内。因此操作系统层要提供优先级抢占调度、确定性中断响应、内存分区保护，以及看门狗与任务超时监控。

安全中间件位于操作系统与应用软件之间，承担三类职责。第一是输入输出安全封装：对速度传感器、应答器天线、雷达等输入做合理性检查（如速度跳变超过物理加速度上限即判为无效），对制动、牵引输出做回读校验（输出后读回实际状态，不一致则导向安全侧）。第二是安全通信：与轨旁ZC、联锁的通信采用带时间戳、序列号和CRC的安全协议（如基于EN 50159的安全层），中间件负责超时检测、重复报文丢弃和序列连续性判断。第三是健康管理与故障记录：周期采集CPU负载、任务抖动、内存余量，异常时触发降级并写入非易失故障日志。

一个典型的实现细节是"双通道比较"：安全中间件在2取2或2乘2取2架构下，将同一输入分发给两个独立计算通道，比较两通道输出，只有一致时才允许输出到执行机构。中间件还需提供安全侧默认值——当任一通道失效或比较不一致时，输出立即切换到"制动施加"这一安全状态，而不是保持上一周期值。

二、应用软件分层：从安全逻辑到运营功能

应用软件通常划分为安全应用层与非安全应用层，两者之间通过受控接口通信，且安全层不依赖非安全层的正确性。安全应用层实现与行车安全直接相关的功能：基于位置和线路数据计算紧急制动曲线（EBI）、监督移动授权边界、判定超速并触发制动。这些功能必须满足SIL4要求，代码需经过形式化或半形式化验证，变量需做范围保护，除法需防零除，数组访问需边界检查。

非安全应用层实现驾驶模式切换、自动折返、乘客信息、日志上传等功能。它可以通过接口请求安全层执行动作，但不能绕过安全层的判断。例如ATO请求施加牵引，安全层仍会独立校核当前速度是否低于推荐曲线，若超限则拒绝并施加制动。这种"请求—校核—执行"的接口设计，是分层安全性的关键体现。

层间接口应遵循两条工程规则：一是数据单向依赖，安全层不读取非安全层的内部状态，只接收其经校验的请求；二是接口数据带有效性标志，每个跨层数据附带时间戳和有效位，接收方超时未更新即按无效处理并进入安全侧。实际项目中常用一张接口数据表来管理，例如：

三、故障安全原则在软件中的体现

故障安全（Fail-Safe）在VOBC软件中不是一句口号，而是可落到代码结构的具体约束。第一，安全侧默认：所有输出变量在初始化时置为安全值（制动施加、牵引切除），任何异常路径都导向该值，而不是"保持上次输出"。第二，失效导向安全：检测到比较不一致、通信超时、任务超时、内存校验失败时，软件主动进入降级或紧急制动，而非继续运行。第三，防御性编程：对输入做范围与速率检查，对指针与数组做边界保护，对关键计算做冗余校验（如曲线计算用两种算法交叉验证）。

第四，状态机显式化：驾驶模式、门控状态、制动状态均用显式状态机实现，禁止隐式跳转；每个状态迁移条件必须可枚举、可测试。第五，故障可记录可复现：所有导向安全侧的触发都写入带时间戳的故障日志，包含触发源、输入快照和当前状态，便于事后分析。工程上还应避免"安全逻辑依赖动态内存分配"和"安全任务被低优先级任务长期阻塞"这两类常见隐患。

综上，VOBC软件架构的本质是"用分层隔离风险、用中间件封装安全、用故障安全原则约束每一处异常路径"。操作系统保证确定性，安全中间件保证输入输出可信，应用分层保证安全逻辑不被运营功能侵蚀，三者共同构成车载控制器可认证、可维护、可追责的软件基础。