一种基于“并行计算”的组合安全设计方法

高国梁

（北京全路通信信号研究设计院有限公司，北京 100073）

高国梁，男，硕士毕业于北京交通大学，高级工程师，安全保障中心副主任。主要研究方向包括安全管理和安全技术、城轨列车自动控制技术，曾负责并参与企业安全保障体系建设，参与城市轨道交通CBTC系统开发，负责ATP、联锁等产品开发的安全确认、武广客运专线列控系统的安全管理等。

1 概述

根据欧洲铁路安全标准EN50129：2003的规定，安全产品的评估和认证分为3个层次：通用产品、通用应用和特定应用。一般地，承载信号安全运算业务的安全计算机平台，作为通用产品被开发和评估，其将作为通用应用开发和评估的基础。安全平台的变更，往往会引起对通用应用的较大影响，所以，安全平台的发展策略往往会更谨慎。另外，安全平台是实现安全设计的基石，其设计是安全设计最核心和最复杂的所在，所以安全平台的开发往往会以既有的安全平台为基础，以确保其稳步前进。

另一方面，随着轨道交通信号控制自动化的快速发展，信号系统的安全运算越来越复杂，对安全平台的运算能力提出了越来越高的要求，一些既有成熟的安全平台逐渐不能满足安全运算业务的资源需求，而短时间内也难以开发出可以成熟应用的新安全平台。此情况下，如何在既有的安全平台基础上，利用先进的技术手段，快速发展出高性能、可扩展的安全平台，是一个比较可行的解决之道。本文正是基于这种思想，并结合工作中的实践，提出了一种基于“并行计算”的组合安全设计方法，实现在既有的安全平台基础上，实现高性能的可扩展安全平台，在使既有的安全平台焕发青春的同时，也实现了安全平台的可持续发展。

2 “故障-安全”的实现方法

在发生单个随机故障时，应确保系统/子系统/设备满足规定的容许危险率。当可识别的任何一种单一随机硬件故障发生时，应保证SIL3和SIL4的系统保持安全。被证明其影响可被忽略的故障可以不予考虑。这种故障-安全的机制有几种实现方式。

2.1 组合故障-安全

采用这种技术，每个安全相关功能应至少由两个对象来执行。各对象之间应相互独立，以避免共因失效。只有当必要数量的对象取得一致时，才允许进行非限制行为。应能检测出一个对象中的危险故障并在足够的时间内加以拒绝，以避免第二个对象发生相同故障。

2.2 反应故障-安全

这种技术允许一个安全相关功能由单个对象执行，前提是通过快速的危险故障检测和拒绝来确保它的安全操作(例如通过编码，多路计算和比较，或通过连续的测试)。尽管只由一个对象实施实际的安全相关功能，但检查/测试/检测功能应被看作为第二对象。检查/测试/检测功能应是独立的，以避免共因失效。

2.3 固有故障-安全

这种技术允许一个安全相关功能由单个对象执行，前提是假定对象的所有可信失效模式均为非危险的。固有式故障-安全也可用在组合式和反应式故障-安全系统的某些功能中，例如，用来确保各对象之间的独立性或在检测到一个危险故障时强制关闭的功能。

无论使用哪种技术或其组合，都应使用适当的结构分析方法来证明以确保单个硬件元件的随机失效模式是非危险的。

3 常见的2002安全设计

常见的2002安全平台，往往使用两个完全相同的计算单元，如相同CPU和计算架构等，如图1所示。其中，有部分特性是可选性，取二的两个CPU可能是共同的，也可能是不同的来源。

与安全设计有关的一些设计问题需要考虑。

3.1 异构（diversification）

1）异构应尽可能实现，以确保减缓系统性失效和共因失效。

2）两个CPU的软件代码应使用不同的算法或由不同的软件开发人员来实现。

3）建议通过输入和输出的逻辑状态中采用部分的硬件异构，比如两个通道采用不同的设备引脚输出。

4）另外一种异构的方法是两个通道采用不同的信息结构，例如，一个通道采用串行编码信息，另一个通道采用并行编码信息。

3.2 两路CPU之间的通信

如果实现了两路CPU之间的通信（C12和/或C21），则应防止引入共因失效。

3.3 定期的诊断测试

当采取了2002结构后仍存在有些失效模式的判断不充分时，需要采取定期的诊断测试技术，一般是增加故障检测电路。该检测电路应在最靠近输出部分或在位于接收端。例如图1中所示，检测电路直接从输出口回检数据，安全切断动作可能发生在上流设备、下游设备或本设备处。在一些情况下，外部接收端可把自己切断到受控的安全状态。

3.4 故障-安全输出机制

故障-安全的输出机制或设备，或者通过“固有失效-安全”设计实现，或者通过对数据叠加安全编码实现（相应的安全编码策略应提供必要的安全保护措施）。

4 扩充安全平台性能

4.1 扩充安全平台性能的需求

随着客专与高铁以及城市轨道交通的快速发展，信号系统越来越复杂，同时为了确保信号系统的安全，各大信号厂商纷纷以欧洲铁路安全标准对信号设备进行升级，并引入了大量的安全算法和安全通信算法，信号设备的安全运算越来越复杂，对安全平台的运算能力提出了越来越高的要求，一些既有成熟的安全平台逐渐不能满足安全运算业务的资源需求，除了对安全算法进行精简以降低其对资源的要求方法外，对既有的安全平台进行升级，提升其性能，以承载越来越复杂的安全运算，逐渐成为一种新的需求。

4.2 扩充安全平台性能的方法

4.2.1 协处理器

当计算机的主处理器容量不足或不具备某一方面计算能力时，通过协处理器的使用，以减轻系统微处理器的特定处理任务。例如，数学协处理器可以控制数字处理；图形协处理器可以处理视频绘制。例如，intelpentium微处理器就包括内置的数学协处理器。包括内置的数学协处理器。

基于该思想，可以对2002结构中的每个CPU增加外置的协处理器计算单元，用于减轻CPU的任务负载。但是，在既有的2002结构已经设计完毕的条件下，对2002结构进行扩充势必对既有的设计造成较大改变，引发安全平台的较大改变，从而对既有的平台和应用形成冲击。

4.2.2 远程过程调用

在IT领域，早在20世纪80年代分布式计算开始发展时，远程过程调用（Remote Procedure Call，RPC）就已经出现。它作为一个计算机通信协议，允许运行于一台计算机的程序调用另一台计算机的子程序，而程序员无需额外为这个交互作用编程。如果涉及的软件采用面向对象编程，那么远程过程调用亦可称作远程调用或远程方法调用，例 ：Java RMI。

RPC采用客户机/服务器模式。请求程序就是一个客户机，而服务提供程序就是一个服务器。首先，客户机调用进程发送一个有进程参数的调用信息到服务进程，然后等待应答信息。在服务器端，进程保持睡眠状态直到调用信息到达为止。当一个调用信息到达，服务器获得进程参数，计算结果，发送答复信息，然后等待下一个调用信息，最后，客户端调用进程接收答复信息，获得进程结果，然后调用执行继续进行。如图2所示。

RPC的理念是使远程过程调用看起来尽可能与本地调用相同，换句话说，RPC的使用是透明的，调用过程并不知道被调用过程运行在另外一个计算机上，反之，被调用过程也不知道调用过程运行在另外一个计算机上。

远程过程调用已经发展成熟，但是如果基于RPC来实现安全平台性能的提高，存在以下几个问题。

1）操作系统内核

RPC平台需要基于比较成熟的操作系统内核的支持，常见的RPC实现，要么构筑于分布式操作系统之上，要么构筑于类似于Java这样的虚拟机平台之上。而信号安全平台往往是基于嵌入式的操作系统甚至是没有操作系统，RPC缺乏实现的基础。

2）RPC协议

为了允许不同的客户端均能访问服务器，许多标准化的RPC系统应运而生。其中大部分采用接口描述语言（Interface Description Language，IDL），方便跨平台的远程过程调用。但是，由于存在各式各样的变体和细节差异，对应地派生了各式远程过程调用协议，而且它们并不互相兼容。

3）RPC机制

RPC采用客户机/服务器模式，最早的RPC为同步RPC机制，当客户机调用RPC时，处于阻塞状态，需要同步等待服务器计算返回。异步远程过程调用是同步RPC机制的扩展，异步RPC允许发出调用的线程继续执行，并且稍后再获取结果。异步RPC机制避免了调用方的阻塞等待，实现了客户机和服务器系统的并行处理。但是，异步RPC往往需要多线程和回调机制的支持，而既有的安全平台往往是单进程的运算机制，这对RPC协议在安全平台的应用形成很大限制。

因此，既有的远程过程调用协议，虽然从理论上可以支持安全平台性能扩充的需要，但由于其难以在既有的安全平台上直接移植或实现。在实际操作层面困难重重。

4.2.3 专用的并行处理机制

增加新的计算硬件，直接采用RPC机制难以实现既有安全平台的性能扩充，但是，可以借鉴异步RPC的思想，在既有安全平台和增加新的独立计算硬件，构筑专用的RPC，实现并行计算，因为，RPC的底层机理主要内容如下。

1）从调用接口层面，实现对应用的透明。

2）在底层实现上，仍然是采用网络通信方式。

借鉴异步RPC思想，根据既有安全平台性能扩充的需要，提出专用的并行处理结构如图3所示。

在图3中，

1）左侧为既有的2002安全平台示意，右侧为计算资源扩充部分。

2）右侧计算资源扩充部分为两个异构的计算机，可以是通用的PC机或服务器，二者硬件平台、实时操作系统等均为异构方式。

3）运行在异构的扩充计算资源上的安全运算服务软件，应符合EN50128的开发过程、开发技术等要求。

4）左右两侧之间通过通信方式交换数据，通信方式应为高速通信方式，如高速以太网等。

5）左侧某一个时刻，仅有一个CPU对外输出（常见的2002设计）。

6）左侧的每个CPU可以同时收到右侧两个计算结果。

基于图3结构的安全设计原则如下。

1）右侧的通用计算资源为异构方式，防止随机性和系统性失效。

2）运行在通用计算资源上的安全软件为符合EN50128标准的软件，防止系统性失效。

3）左侧通过网络将需要加工计算的数据发送给右侧，通信机制应根据通道失效模式分析，符合EN50129标准的要求，防止通信的随机性失效。

4）右侧将计算结果通过网络返回给左侧，通信机制应同3）。

5）左侧的每个CPU在收到右侧的两份计算结果后，进行取二比较，相同则使用，不同则抛弃。

6）左侧两个CPU在对外输出时，进行取二比较，不同则导向安全侧（2002的基本设计）。

对上述并行计算架构和安全设计原则分析，对安全平台进行性能扩充后，平台实现了以下目标和好处。

1）将复杂、独立的安全运算逻辑运行在通用计算资源之上，实现了并行计算，使既有安全平台不再是安全逻辑计算的瓶颈。

2）既有的安全平台一般均具有网络通信的功能，对安全平台的扩充非常简单，对既有的安全平台影响很小，实现了安全平台的快速平滑升级。

3）最重要的是，在平台扩充后，既有的安全平台充当了“安全与”的角色，即“表决器”的角色，满足“组合故障-安全”的设计，仍然符合故障-安全原则。

4）延伸该扩充思想，可以将绝大多数的安全运算逻辑部署在通用计算资源之上，实现小的安全比较单元，大的计算单元的架构，降低了安全平台的复杂度。

4.3 安全平台专用并行处理机制的应用

DS6-K5B平台是引进的日本京三公司的安全平台，北京全路通信信号研究设计院有限公司的DS6-K5B联锁系统是在我国客专与高铁广泛采用的设备。该平台在与RBC平台通信时，由于平台的主机CPU板（F486）的性能限制，一度采用通信前置机的方式来处理安全通信的运算，即增加了成本，也给系统带来了复杂性。后来，DS6-K5B平台开发了高性能的运算板（ZARM2），联锁系统使用运算板来代替通信前置机，专职处理与RBC的通信数据处理，即提高了性能，又降低了系统复杂性，同时未降低系统的安全性。F486与运算板交互数据的功能结构如图4 所示。

新扩充的演算板ZARM2中包含两个异构的CPU，一个用ARM11，一个用SH-7780，两个CPU完全独立。F486与ZARM2之间通过共享内存接口。ZARM2上的两个CPU同时收到来自F486的数据，F486上的两个CPU同时收到来自ZARM2上两个独立CPU的运算结果。F486与ZARM2之间的结构完全符合4.2.3中专用并行安全处理架构。

5 基于“云计算”的安全平台扩充构想

对于4.2.3中描述的专用并行处理机制，由于其“专用”的特点，存在以下不足。

1）并行计算的调用没有实现真正类似RPC的机制，应用层仍需进行通信相关的处理。

2）通用计算资源上运行的安全计算，尚无法作为类似“服务”提供的机制工作。

3）通用计算资源的配置是预先固定的，无法灵活配置和扩充。

基于专用并行处理机制，对既有的安全平台进行扩充，能够满足急需的安全平台的资源紧迫要求，但从长远的发展来看，应该对这个专用并用处理机制进行应用使用的简单化、机制的标准化和资源扩充的灵活，从而使安全平台满足未来的计算需要。当今的“云计算”正是通过虚拟化技术，实现了软硬件资源的灵活配置，向客户提供网络计算服务，其思想可以用于解决“明天”的安全平台要求。

云计算是当今信息技术行业的最热门的话题之一，但是云计算并非一个全新的概念，其很多理念涉及网格计算、集群技术、分布式系统技术等比较成熟的技术。如图5所示，云平台屏蔽了底层的软硬件实现细节，并且提供连接服务的标准接口，使所有连接Internet的用户都可以方便地接入云平台使用计算资源。

基于云计算的思想，既有安全平台的扩充需要架构于云之上。既有的安全平台需要通过云调用，使用云计算提供的服务实现安全算法的并行计算，同时为了保持“组合故障-安全”的设计原则，安全平台需要调用云计算环境中异构的两个并行计算，并对返回的两个结果进行取二计算。这种对安全平台的“云扩充”思想，需要解决以下几个大的问题。

1）对既有的安全平台进行改造，增加云调用的支持。

2）为了降低随机性失效，云计算平台部分的基础软硬件资源应保持异构的方式，并需要保证为相同云调用提供异构的计算服务。

3）新的安全运算，需要构建与云计算平台之上，成为云计算平台的网络服务。

由此可见，“云扩充”方式，将对既有的安全平台的软件层带来较大改变，同时扩充部分的云计算平台的异构服务是一个新的课题。因此，基于“云计算”的安全平台，需要进行更深一步的研究。

6 结论

基于理论的分析以及对实践工作的总结，说明对既有安全平台的性能扩充，可以采用平滑、快速的，但仍是高性能的符合安全设计方法的措施，这就是本文提到的“并行处理机制”的扩充方法，该方法可以实现安全平台的可持续发展，使其继续焕发青春。另外，出于对安全平台未来发展的要求展望，本文提出了基于“云计算”的安全平台扩充的可能性，为“明天”的安全平台提出了一个可能的新架构。

[1] EN50129:2003Railway applications —Communication, signallingand processing systems —Safety relatedelectronic systems forsignalling [S].

[2] PD CLC/TR 50506-2:2009Railway applications —Communication, signalling andprocessing systems — Applicationguide for EN 50129 Part 2: Safety assurance[S].

[3] Andrew S. Tanenbaum.分布式计算机系统[M]. 北京：清华大学出版社，2000.

[4] ZARM2开发-RSSP-II协议软件移植设计文件.

[5] 王佳隽，吕智慧，吴杰，等．云计算技术发展分析及其应用探讨[J]，计算机工程与设计，2010,31(20)：4404-4409.