一种基于RAFT 算法的铁路信号安全平台共识机制研究

赵梦瑶，刘逸明，王龙生*

（1.中国铁道科学研究院通信信号研究所，北京 100000；2.国家铁路智能运输系统工程技术研究中心，北京 100000）

铁路行车安全始终是铁路运输的第一要素。铁路有史以来发生的重大行车安全事故都导致巨大灾难性的后果，并造成具有广泛破坏性的社会影响[1]。铁路信号控制系统是保障行车安全的关键设备，是典型的实现重大生命攸关功能的安全苛求系统。其中铁路信号安全计算机平台作为铁路信号控制系统最基础、最重要的组成部分，是实现不同系统的应用所需要的硬件平台和软件底层平台的设备。

为了提高铁路信号安全平台的安全性和可靠性，安全平台的结构从最初的单套系统升级为双机热备系统，又再次升级为2 取2 冗余结构或基于3 取2 冗余结构，以达到一个性能和成本的平衡；同时“故障-安全”软件设计和功能测试方面技术的提升，使得目前的铁路信号安全计算机平台技术相对稳定。但是，目前铁路安全平台都是集中放置、单站放置的形式，存在造价高、建设周期长等缺点，特别是随着铁路网的高覆盖率，对运输效率和行车安全提出了更高的要求。

因此，本文设计了一种基于RAFT 共识算法的铁路信号安全计算机云平台实现方法[2]，对于铁路沿线上的多个车站，将每个站分立的安全计算机平台替换为中心服务器的方式，再通过光纤与每个站的操作表示界面以及室外控制设备相连，在保障高安全性、高可靠性的前提下，可以有效降低维护量、提高性能和扩展性、缩短施工时间和资源消耗。

1 铁路信号安全平台与共识机制

1.1 铁路信号安全平台

铁路信号安全计算机平台是铁路信号安全相关应用系统所使用的专用安全计算机平台，是适用于实现车站进路控制、行车间隔控制以及超速防护等铁路信号重大安全功能的专用安全计算机平台[3]，例如铁路列控系统的联锁系统、列控中心和无线闭塞中心等。

铁路信号安全计算机平台的核心关键在于：具有较高的实时性要求，具有极高的可靠性和安全性之外，还必须满足“失效-安全”的相关设计原则，同时满足于SIL4 级安全完整性要求[4]。现计算机联锁系统使用较多的为基于2 取2 乘2 冗余结构如图1 所示，或基于3 取2 冗余结构如图2 所示的联锁安全计算机平台。

图1 2 取2 乘2 冗余结构原理

图2 3 取2 冗余结构原理

1.2 功能安全与“故障-安全”设计原则

设计、实现一个铁路信号安全平台，需要重点进行2 个方面的设计和研究。首先是实现该平台基础应用功能的技术方案及其特点，更重要的是针对如何支撑这些技术方案、确保信号系统安全应用的技术措施的研究。

“故障-安全”顾名思义就是系统故障后导向安全的一种设计理念，是铁路信号中最根本的设计原则。随着工业控制技术的发展，一些国内外的电工标准、铁路行业设计标准、可靠性设计方法等技术也被广泛地知晓和应用，特别是IEC61508 中定义、规定的安全完整性要求和EN50129 中“失效-安全”理念和技术，从根本上保障安全平台的可靠性和安全性[5]。IEC61508 研究了安全平台的硬件和软件安全相关功能的安全性必须满足安全完整性要求，能够为平台所承载的安全相关应用软件完成其应用功能提供安全保障；以及进行平台的可靠性、安全性，“失效-安全”的技术措施的相关研究[6]。EN50129 从理念和技术这2 个不同层面构建了完整的“失效-安全”体系，并确立了相当完备的“失效-安全”基本原则；系统地解决了提高信号可编程安全相关系统的“失效-安全”应该怎么样做、应该做到什么程度以及如何衡量的原则性和技术性问题。这些将成为这个安全平台能否成功应用的关键[7]。

1.3 共识机制

安全冗余结构的逻辑平台中，同步表决是保障安全性的首要条件。但是，在云平台架构下，服务器各个节点的运算及数据交互模式将发生巨大变化，单平台的同步和表决机制不再适用，所以引入共识机制算法以实现云平台系统的同步表决。

共识机制是使得各服务器节点在某种协议的保障下对计算结果达成一致。针对于不同的应用场景，共识机制在保证安全性和一致性的基础上，也需要平衡系统的性能效率、扩展性和资源消耗等因素。目前常见的分布式系统一致性算法包括PoW、PoS、DPoS、RPCA、Paxos、RAFT、PBFT 等[8]，各种算法都有优缺点，在某一种应用中可以使用一种算法计算核心部分，并与其他算法相结合。

RAFT 算法因其具有复杂度低，易于理解，易于工程应用实现的特点，更适合本文提出的铁路信号安全计算机云平台的工程应用。

2 分布式安全平台架构设计

在现有铁路安全计算机平台的基础上，分布式安全平台主要侧重分布式逻辑运算架构，由现有本地、集中的逻辑运算单元提升为基于共识机制的多个、分布式的逻辑运算平台，实现了更高的可靠性、可用性和可扩展性，具体架构设计如下。

2.1 安全平台架构组成

分布式安全平台主要包含操作表示层、逻辑处理层和执行层3 部分，如图3 所示。其中，操作表示层可以为一个车站、多个车站或调度集中系统（CTC）/列车调度指挥系统（TDCS）中的人机交互计算机，操作人员通过人机交互界面进行指挥车站作业、控制车站信号设备和监控信号设备工作状态等操作。

图3 分布式安全平台架构图

逻辑处理层由多个分布式设置的服务器组成，每个服务器均可作为一个节点加入共识机制算法之中。逻辑处理层接收来自操作表示层的操作指令，通过RAFT 算法计算后多个服务器将产生一条安全命令发出，并且每一个服务器均会同步保存这一次指令的计算过程和结果，最终实现区域内多个车站控制逻辑的分布式计算和控制。

执行层由各个车站的执行电路或系统以及最终被控的室外轨旁信号设备组成，在接收到来自逻辑处理层的动作命令后进行相应动作，同时将本站信号设备的工作状态、报警信息等数据上传至逻辑处理层，实现对站场信号设备最终的安全控制。

2.2 逻辑处理层主要功能

基于共识机制的安全平台中的逻辑处理层是进行逻辑运算、采集驱动处理以及通信数据转换等功能的核心层，主要完成的功能如下。

（1）安全通信以及采集驱动功能。接收来自各个车站或TDCS/CTC 的站场作业操作和控制信号设备操作等信息，同时接收执行层上传的站场内信号设备的工作状态等采集信息；将这些信息进行转义和整合，用于各服务器节点之间的同步和通信以及联锁逻辑的运算；最后将最终生成的安全命令发送至执行层进行驱动输出。

（2）以RAFT 算法为核心的同步机制及自身调度功能。运用RAFT 算法进行各服务器节点之间的同步与运算结果比较，替代了现有安全计算机平台中主从交互采集信息和主从交互运算结果等环节，是本安全平台的主要特点和核心功能。

（3）运行联锁逻辑处理软件。将现有的联锁软件运行于共识机制的安全平台中，根据平台处理后的操作命令以及站场设备的采集状态进行联锁逻辑运算。

3 基于RAFT 算法的平台共识机制计算过程

铁路信号安全平台采用分布式结构后，最关键的问题仍然还是如何保证系统的“故障-安全”特性，即要保持如图4 所示中逻辑处理层中的各节点的一致性，无论哪部分发生故障，只要该层中的大部分节点可以正常工作，则这些节点就具有相同的状态，保持一致，实现安全性冗余的功能。

图4 现有计算机平台和共识机制平台工作流程比较

3.1 基于RAFT 算法的安全平台计算过程

铁路信号安全平台基于RAFT 算法的平台软件计算过程如下。

3.1.1 系统初始化

完成系统硬件功能初始化，逻辑层各服务器选取Leader，其他服务器自动变成Follower[9]。

3.1.2 周期逻辑处理

完成通信后，Leader 完成命令分发给Follower，进行IO 采集、逻辑计算后，Follower 将形成的结果传回Leader，Leader 进行安全比较，形成驱动输出等过程。

3.1.3 逻辑服务器异常处理

（1）Leader 异常处理：逻辑层某服务器成为Leader后，会周期发送心跳包给其他的Follower，如果Follower 超过一定时间没收到心跳包，会触发重新选举Leader 的逻辑；

（2）Follower 异常处理：Leader 发现有Follower 不能正常接收下发的命令或者不能回复状态后，Follower会重启恢复。

3.2 基于RAFT 共识算法的铁路信号联锁系统软件流程

以铁路信号列控系统中的联锁系统为例，详细描述基于RAFT 的平台层软件的实现。如图5 所示，5 个车站配置了5 套操作表示机，对于5 个车站各自的执行层设备，逻辑处理层中有4 个服务器。

图5 RAFT 共识算法流程

（1）4 个服务器分别命名为S1、S2、S3、S4，上电完成硬件功能初始化，4 个服务器都成为Candidate。

（2）服务器角色初始化，4 个服务器互相投票，选举Leader，假设S1 成为Leader，那么剩下的S2、S3、S4自动成为Follower，完成初始化。

（3）周期执行开始，车站1 要排列进路，发出进路命令给S1（Leader）。

（4）S1 收到命令后转发给其他所有的Follower（S2、S3、S4）。

（5）每个Follower 收到转发的命令，调用自身的逻辑处理功能模块检查进路开放的条件，采集室外设备的状态，计算进路开放需要操作的道岔。

（6）Follower 计算和采集完成后发回给Leader（S1）。

（7）Leader（S1）一致性检查，Leader（S1）接收到2个服务器发回来的计算结果及采集状态一致时则认为该结果及状态有效，形成最终执行命令。

（8）Leader（S1）将命令发送给执行层的相关设备执行命令操作，将状态返回车站1 显示车站设备和进路的状态。

（9）各服务器无异常时，周期执行（3）-（7）的过程，实现系统的正常运行。

（10）Leader（S1）异常后，进入过程（2），剩下的S2、S3、S4 重新选举新的Leader。

3.3 基于RAFT 的安全平台共识算法的安全性设计

安全平台软件流程描述了平台软件实现的主要流程，但是为了保障算法实现的安全性，还需要设计以下功能确保安全性。

3.3.1 网络和通信保障

RAFT 在非拜占庭错误情况下，包括网络延迟、分区、丢包、冗余和乱序等错误都可以保证正确，不会返回错误结果，这就是安全性保证。实际上就是保证所有成员状态机都以同样的顺序，执行同样的命令。

3.3.2 服务器节点数量和功能

服务器节点数量的增加可以提高系统的容错能力，常规的如果有5 个服务器节点，那么可以允许2 个服务器故障，如果如图5 所示的4 个服务器结构，就只能允许1 个服务器故障；同时，每个服务器应有一个自检程序，用于检查自身故障后保障系统宕机，而非异常计算和输出。

3.3.3 命令时效性

服务器的Leader 只接收当圈周期的命令，避免使用历史命令造成的风险。

3.3.4 同步处理

逻辑服务层中各服务器只有Leader 接收车站的命令，并由Leader 转发给所有的Follower，如果Follower 在计算过程中收到Leader 发送的新命令，会舍弃原来的计算按照最新的命令重新计算，Leader 来调度这些并发请求的顺序，并且保证Leader 与Followers 状态的一致性，这种机制保障了逻辑处理的同步[10]。

3.4 基于RAFT 的分布式信号安全平台的可靠性分析

对于基于RAFT 的分布式信号安全平台而言，其逻辑处理层执行逻辑运算、采集驱动处理以及通信数据转换等功能，也是应用分布式算法提升系统可靠性与安全性的关键。因此，本文着重对平台逻辑处理层的可靠性与安全性进行分析。

对于简单的单系统，其平均故障间隔时间（MTBF）可由下式推出[11]：

式中，RS为系统可靠度，λ 为系统故障率。

由RAFT 算法特性可知，在不考虑共因失效和车站数量造成的业务数据量的情况下，系统内有3 台或以上服务器可以正常工作时，系统处于正常工作状态。假设各服务器的可靠度相同且失效率均服从指数分布，不考虑系统的可维修性，则系统的可靠度与MTBF可以由下式表述：

以前文中的控制5 个车站情况举例，基于RAFT的分布式信号安全平台的平均故障间隔时间为：

而双机热备、3 取2、2 乘2 取2 等冗余结构的平均故障间隔时间分别为：

精确分析系统的可靠性其工作量非常巨大，但是，将各冗余结构框定在一些限定条件下进行比较，亦可做出定性判断。经过比较，本文提出的基于RAFT 的分布式信号安全平台在可靠性方面胜于当前应用的各种冗余结构，能够保障各类信号控制业务的稳定运行。

4 结论

本文设计了一种分布式铁路信号安全计算机云平台架构，并研究了其基于RAFT 算法的共识机制实现方法。对于铁路沿线多车站场景，本文提出的安全计算机云平台能够有效减少系统设备的数量，降低施工的周期，方便扩展，不同车站的相同列控系统或者同一车站的不同功能列控系统都能以软件的形式运行在这一个服务器群中。同时，研究了铁路信号安全平台在RAFT 算法下如何完成同步表决和安全功能的实现，以铁路信号联锁系统为模型，设计了详细的平台软件流程步骤，最后又单独分析了算法和实现中的安全性设计。