基于双总线的城市轨道交通列车网络主控设备冗余控制设计

张增一 宋 扬 鲁振山

（1.中车大连电力牵引研发中心有限公司，116052，大连；2.动车组和机车牵引与控制国家重点实验室，116052，大连∥第一作者，工程师）

由于列车运行环境复杂多变，TCMS（列车控制与管理系统）在运行过程中需应对气压、温差、空气质量以及电磁环境等多重因素瞬时突变造成的影响。因此，除对设备及通信线路进行更高等级的防护，以及执行更严苛的试验测试标准外，通常采用冗余设计以保证系统安全和稳定地实现其通信管理及控制功能。本文利用在研项目的带高速智能网络系统的某城市轨道交通车辆配置的两种车辆控制总线所搭建的数据交互环境，研究网络主控设备列车中央控制单元（CCU）对于自身及冗余设备运行异常、通信功能异常等状态进行高速判别，并进行准确应对处理的有效实现方法，提出基于双总线的双级热备冗余控制的设计思路，以实现TCMS 运行安全性能的进一步提升。

1 网络主控设备

在研项目带高速智能网络系统的某城市轨道交通车辆，其列车4 节编组结构为：1 节带司机室动车+1 节拖车+1 节带受电弓拖车+1 节带司机室动车。TCMS 采用编组以太网（ECN）和多功能车辆总线（MVB）两种车辆总线拓扑结构。列车各设备均通过两种总线进行数据交互，默认采用高速的ECN 总线作为首选数据信任总线，MVB 为冗余总线，并同时提供相关人机交互接口用于首选控制线设置及切换。

在该项目中，ECN 总线采用TRDP（列车实时数据协议）中的数据协议栈进行实时数据传输。2015年7 月出台机车车辆使用的工业以太网标准IEC 61375-2-3（Edition1.0）［1］，其定义ECN 的4～7 层都将使用专为铁路用途开发的自主协议TRDP，并通过行业团体TCNOpen 以开源的形式公开。TRDP的协议栈在以太网中所处位置如图1 所示［2］。

CCU 作为TCMS 核心部件，负责整车网络管理和车辆运行控制功能。该项目列车装配2 台互为冗余的CCU，其中1 台作为冗余设备（从CCU）处于热备状态，实时检测主CCU 状态，确保在主CCU发生故障时能够迅速接管主CCU 全部功能，以持续保证系统功能安全运行。

图1 TRDP 在ECN 机构中的位置

CCU 的硬件部分采用低功耗嵌入式PC/104 结构的工业计算机104-1645CLDN-（24B）板卡，集成了AMD LX800CPU、256 MB 的DDR、1 个PC/104扩展接口、1 个10/100 Mbit/s 自适应网口、1 个IDE接口、2 个串口、USB2.0 接口等［2］；软件部分主要包括底层系统软件和上层应用软件，前者是后者的操作系统平台，采用基于x86 硬件平台的VxWorks 多任务实时操作系统，进行软件输入输出映射管理、内存管理、任务调度等功能，是本研究中实现双级热备冗余控制的主要研究对象。

2 双级热备冗余控制

所谓双级热备冗余控制，即在配置两种控制总线的列车上通过优化CCU 底层系统软件设计，使CCU 同时实现数据接收总线间的总线级冗余控制，以及主、从CCU 间的设备级冗余控制功能。通过对总线和设备的双级冗余处理，分别对通信总线突发的暂时性通信异常以及设备部件功能性故障进行应对处理，使系统运行得到更高效、全面的保护。

2.1 CCU 的总线级冗余控制

本项目采用MVB 和ECN 双总线数据交互的车辆控制总线配置方式，实现整车设备通信功能。CCU 通过双总线同时向其他设备发送数据，并将由双总线接收的数据分别进行缓存处理，默认优先选择ECN 总线作为数据信任总线，也可通过人机交互界面对数据信任总线进行选择。CCU 实时监视对比两个总线接收的缓存数据，判断总线数据健康状态，并选择处于健康状态的数据作为CCU 逻辑运算输入结果，实现总线级冗余控制。

2.1.1 总线冗余实现方式

在项目设计阶段，为使上层应用软件对设备接收数据的处理不受数据总线选择的影响，开发者会对两种通信接口协议进行统一编制，并分别生成MVB 和TRDP 通信配置文件。

MVB 通信配置了CCU 各端口源宿属性、端口号、端口大小及特征周期4 种参数，并根据主、从CCU 通信性质分别进行配置。CCU 底层软件将在启动后的初始化过程中读取MVB 通信配置文件，并依据其中的端口号大小自动排列端口顺序，再结合端口大小计算出各个端口数据的内存偏移地址。底层软件在轮询各端口并读取端口数据后将按照该内存偏移地址将数据依次映射在分配好的内存空间内，完成MVB 数据缓存。

TRDP 通信配置了CCU 数据通信各数据包相关的数据源设备、源设备IP 地址、宿设备IP 地址、数据包ComId、数据包源宿类型、数据量、偏移位置以及特征周期等8 种参数。CCU 底层软件将在启动后的初始化过程中读取TRDP 通信配置文件，并依据文件内各宿类型数据包偏移位置大小自动排列，同时按顺序为每个数据包创建1 个socket（套接字）。底层软件在轮询socket 并读取接收到的数据后，将按数据包规定的内存偏移地址将数据依次映射在分配好的内存空间内，完成TRDP 数据缓存。

由于MVB 和TRDP 均严格规定了数据偏移位置，在两个数据总线通信状态完全正常时，两个数据缓存区内数据内容应一致。而在数据信任总线受到干扰时，CCU 按照当前信任总线确定1 个数据集合单元，并以该数据集合单元为单位，对两个总线数据缓存区内的数据内容进行健康状态对比，以非信任总线中健康的数据集合单元对信任总线中不健康的数据集合单元进行替换处理，实现更高效的数据总线来源切换。数据接收双总线冗余的软件执行逻辑如图2 所示。

本设计中，CCU 按照不同的信任总线确定用于作为数据冗余单位的数据集合单元，各数据集合单元标定在2 个数据缓存区索引数据的内存偏移地址和数据长度。当MVB 总线为信任总线时，CCU 以MVB 通信配置的数据端口作为数据集合单元，并在缓存区内分别对各端口接收的数据进行健康状态判断，对于非健康数据以数据端口对应内存偏移作为索引地址在非信任ECN 总线数据缓存区内进行索引，并进行数据冗余处理；当ECN 总线为信任总线时，CCU 以TRDP 通信配置的各数据包作为数据集合单元，并在缓存区内分别对各数据包对应socket 接收的数据进行健康状态判断，对于非健康数据以数据包对应内存偏移作为索引地址在非信任总线MVB数据缓存区内进行索引，并进行数据冗余处理。

总线级冗余功能嵌入在CCU 底层软件的主应用任务中执行，执行周期为20 ms。

2.1.2 MVB 数据健康状态判断

MVB 为信任总线时以数据端口为数据集合单元进行数据冗余处理。CCU 通过对比每个端口刷新时间与其对应的健康判断时间，进行MVB 端口数据健康判断。在本设计中每个端口健康判断时间与其端口特征周期存在对应关系，具体如表1 所示。

图2 数据接收双总线冗余

表1 MVB 端口特征周期与健康判断时间对应表

各端口健康判断时间以该端口特征周期乘以对应判断系数N 而得出。当端口刷新时间未超过其对应的健康判断时间时，视为该端口数据处于健康状态；反之，则视为该端口数据处于非健康状态，按照该数据集合单元标定的内存偏移地址和端口大小，在TRDP 数据缓存区索引对应数据，并进行数据替换处理完成数据冗余。

2.1.3 ECN 总线数据健康状态判断

ECN 总线为信任总线时以通信配置的各数据包为数据集合单元进行冗余数据处理。在TRDP 通信配置阶段，已经将各子设备向CCU 的数据通信配置在不同的socket 进行接收，通过轮询每个socket实现在同一周期内对全部子设备发送数据进行接收。对于读取出的数据分别进行解析、校验，并将数据向TRDP 数据缓存区进行映射，同时判定该数据集合单元健康状态良好。当读取socket 无数据时，为保证数据接收在同一运行周期内的运行实时性，将进行循环读取socket 动作，直至读取出数据或循环次数超过M 次（本设计中M=10）时停止循环读取动作。当连续5 个任务运行周期读取socket 无数据次数超过M 次时，判定该数据集合单元为非健康状态；将根据该数据集合单元标定的内存偏移地址和数据长度在MVB 数据缓存区内索引对应数据，并进行数据替换处理完成数据冗余。

2.2 CCU 的设备级冗余控制

为了实现更完备、高效的设备冗余切换功能，本研究根据以往项目中CCU 的故障案例，总结了CCU 运行过程中可能突发的各类设备功能性故障，并对这些故障所期望得到的设备冗余功能应对效果进行统计性研究，最终形成有效的设备级冗余控制方法。CCU 功能性故障类型如表2 所述（冗余控制只应对单设备故障）。对表2 中阐述的各类型故障进行总结，形成主、从CCU 故障判断条件，并以此形成自身及冗余设备故障判断结果，最终对判断结果进行相应的应对处理。主、从CCU 设备级冗余控制功能的实现过程分别如图3、图4 所示。

在上述逻辑判断条件中，MVB 宿端口超时判断及TRDP 数据有效性判断方法，与总线级冗余控制描述的数据健康状态判断方法一致，但设备级冗余控制是针对设备功能性异常进行的，需对全部数据集合单元的健康状态进行判断得出判断结果。为保证逻辑判断时间充足且不影响冗余切换功能的高效性，本设计中将全部MVB 宿端口超时判断时间设置为256 ms，全部TRDP 数据失效判断时间设置为100 ms，即保证设备在300 ms 内完成设备功能性故障状态判断。

主、从CCU 通过单独配置的MVB 内部通信端口和TRDP 单播数据包，实现设备间内部通信。在内部通信数据中，单向包含主或从CCU 设备的MVB 接收功能状态、TRDP 接收功能状态、自身故障判断以及生命信号，利用内部通信中数据信息的传输，使主、从设备双方得到充足的数据依据，了解故障时刻双方状态，并以此做出准确的故障判断及应对动作。本设计中MVB 内部端口特征周期设置为32 ms，TRDP 内部通信周期设置为20 ms。在主CCU 判断自身故障状态后，主动进行TRDP 及MVB 的从状态配置，规避总线上双主故障情况。

表2 CCU 功能性故障分类

图3 主CCU 冗余控制判断逻辑及应对动作

本项目中采用的CCU 设备，TRDP 主从状态切换可以由软件瞬间完成；而MVB 主从状态切换需要主板调度MVB 通信板卡进行主从状态重新配置过程，实测耗时为295 ms。因而，从CCU 在完成主CCU 故障判断后，在不中断应用逻辑运算的前提下，首先进行TRDP 通信主从状态切换，以TRDP通信数据维持系统正常控制及通信管理功能。同时启动MVB 主配置加载任务，待到MVB 加载主配置成功后，再恢复数据总线冗余功能。

图4 从CCU 冗余控制判断逻辑及应对动作

3 实验室的模拟验证测试

双级热备冗余控制通过软件实现后，在实验室搭建网络拓扑测试环境（如图5），对冗余控制功能效果进行模拟验证测试。其中，陪试设备为可编程的通信模拟设备，可模拟项目中全部网络子设备数据发送功能，并可通过在线调试模式控制两种总线的任意数据集合单元数据发送，以此模拟数据异常状态。

图5 验证测试环境的网络拓扑图

总线级冗余功能测试中，通过陪试设备模拟2种总线不同数据集合单元的异常状态，测试结果表明，利用MVB 为信任总线并模拟其故障时，数据总线冗余完成时间与表1 中规定的MVB 端口健康状态判断时间一致，各数据端口可在其对应的健康状态判断时间（最小160 ms，最大1 024 ms）内利用TRDP 数据完成数据冗余；ECN 总线为信任总线并模拟其故障时，冗余完成时间为5 个主任务执行周期，即5×20 ms=100 ms 完成数据冗余。

设备级冗余功能测试中，通过软件模拟与线缆通断操作，对表2 中描述的CCU 故障情况逐一进行模拟。测试结果表明，从CCU 在256 ms 完成对MVB 和TRDP 通信状态的有效性判断，并优先进行TRDP 主从切换保证CCU 控制功能顺利进行，完成切换时间为256 ms。

在调试过程中，主、从CCU 始终运行具备双级热备冗余控制功能的底层系统软件，并在整个静调、动调测试过程中，CCU 控制功能完全正常，说明双级热备冗余控制的软件实现在保证冗余功能的同时，没有对列车网络控制功能造成任何不良影响。

4 结语

一系列验证测试结果表明，双级热备冗余控制功能具备较高的实时性和可靠性，在充分保证网络主控设备对列车的稳定控制功能的同时，有力应对了通信瞬时异常及设备功能性故障对于TCMS 安全运行所造成的风险，对轨道交通车辆的安全运行性能的提升具有较现实的参考意义。