铁路信号系统中安全关键软件的安全分析方法

林伟欣, 胡源, 李梅

(卡斯柯信号有限公司， 上海 200070)

0 引言

随着铁路信号系统复杂程度和智能化的提高，系统中需要软件实现的能力越来越多，规模和复杂性持续增加，软件在整个系统中的作用也越来越重要，保障软件的安全性成为保证系统安全性的关键环节。软件是逻辑思维的产物，软件错误的本质是设计者思维逻辑的错误。软件的失效主要是系统性失效，难以用定量的方法进行评估，这给软件安全分析带来了难度。同时，软件阶段的设计和实现人员一般是软件需求或者编程方面的专家，而对功能安全方面的知识关注略少，使得安全需求在软件设计和具体实现的落地存在一些不确定性，除了加强人员能力要求外，在软件安全保障过程中，需要有系统性的分析流程来保证软件设计符合其预定的安全目标。

在轨道交通信号系统领域，EN50128标准对铁路控制和保护系统防护软件保证其研发等级(SIL0-SIL4)的方法、技术和软件生命周期进行了系统性描述[1]。该标准明确指出，对于复杂的软件，现阶段诸如故障避免、故障检测和故障容错的方法都不能保证我们在定义和设计软件过程中不出现任何错误。为保证开发的软件达到相应的研发等级，需要有与软件全生命周期相对应的完整的开发流程来避免和减少系统性失效。该流程中，对安全关键软件在各个阶段展开安全分析和验证工作，是发现软件缺陷，保证软件质量，保证系统功能安全的重要手段。EN50128中给出了在软件生命周期内进行安全需求的确定、设计和验证的流程图。

EN50128中推荐的软件开发V模型包括软件需求、架构设计、组件设计、组件实现、单元测试、继承测试、确认测试和软件维护8个阶段，涵盖了软件开发的整个生命周期，各个阶段通过标准化的文档进行信息传递。软件安全保证是流程贯穿在软件开发生命周期的各个阶段中的，是软件开发生命周期的有机组成部分。

本文基于EN50128标准的要求，从软件安全需求的获取和验证、基于软件需求和结构规格说明的软件失效影响分析、对软件安全代码的验证3个方面，给出了安全关键软件的一种安全性保证的途径，可以作为轨道交通领域通信信号和处理系统的铁路控制和防护软件全生命周期安全保证的实用流程。

1 相关研究

随着安全关键领域软件的复杂度和重要性的增加，近年来对软件安全性评价和保障方法的研究也越来越多。文献[2]针对航空机载软件安全性评价的难题，给出59种评价元素将软件每个阶段的关键活动进行量化，在软件整个生命周期采用分类模糊综合评价方法，建立了评价模型，得出软件安全分值，为软件总体质量的评价和软件安全性的改进方向提供支撑。文献[3]针对航空电子机载软件的安全性、完整性和可追溯性要求，提出了在软件生命周期各研发阶段增加具体安全性相关活动提高软件安全性的过程保障方法。文献[4]介绍了安全关键软件中同样的软件安全性分析技术和流程，并对其在CBTC车载子系统中的应用进行了介绍。文献[5]依据面向软件安全需求分析过程建立安全相关信息完整的双向追踪过程，构建软件安全需求分析的过程追踪模型，分析其中的重要实体和关联。文献[6]和文献[7]将形式化方法和建模引入到软件的安全性分析过程中。其中，文献[6]借助OCL表达式对安全相关的约束关系建模，并将其融入到UML模型，进行软件失效模式的识别，以求提供软件安全分析的效率，降低分析工作量。文献[7]将系统理论过程分析(STPA)方法应用到软件安全性验证过程中来，构建带有软件过程模型变量的过程模型，生成软件安全性需求，并采用模型检验技术对软件安全性进行验证，以失败软件潜在危险控制路径，减少对人工分析的依赖。

目前，这些研究大部分集中在航空航天领域安全相关软件生命周期某些环节的安全保障研究，一些量化或者形式化的软件安全保障方法，存在标准确定困难或者全生命周期形式化建模验证的困难。针对铁路信号系统安全关键软件的全流程安全保障研究集中在流程研究，缺乏具体的实现措施，特别是针对软件本身衍生的安全性需求的分析方法较少讨论。本文基于信号系统铁路控制和防护软件的开发V模型，给出了在软件需求、软件架构设计和软件编码阶段实现软件安全分析的要点，可操作性强。

2 软件安全分析流程

对软件而言，需要考虑的是软件在生命周期内如何减少和避免系统性失效。针对轨道交通信号系统中的安全关键软件，本文提出的软件安全分析流程集中在软件需求，软件架构设计和软件代码实现3个阶段，上一阶段的输出作为下一阶段的输入，构成了完整的安全分析流程。

轨旁设备安全控制平台，是我公司开发的2取2安全架构的嵌入式安全平台。使用的软件是基于国产自主高可信嵌入式操作系统开发。其软件开发流程遵循V模型，开发、测试活动和对应的安全活动如图1所示。

2.1 软件需求阶段的安全分析和验证

软件需求阶段的安全保障工作主要是获取安全相关需求，并对安全需求的可追溯性和完整性进行验证。软件与系统密不可分，软件的安全需求的源头和软件的安全完整性等级是在系统级确定和分配的。软件的安全性需求是对系统级安全需求在软件层级的细化。比如，在安全平台控制系统中，系统需求提到，当软件出现异常时，系统进入安全状态。则软件安全需求细化为当软件出现任务堆栈溢出、任务超时、输入值超范围、返回值超范围时，应进入安全状态模式。这种细化可以由软件需求工程师完成，并由软件安全工程师根据需求标签建立系统安全需求和软件安全相关需求的追踪关系，对系统级安全工程师提出的系统安全需求在软件层级的继承展开可追溯性和完整性验证，确保软件层级的需求规范文档完整、正确地继承了这些安全需求，并将这些安全需求与分配到软件的系统危害关联起来，以便进行危害管理。

图1 安全控制平台所使用的开发过程模型

另一方面，是在软件实现的过程中，由设计方案、软件架构的选取，或者执行决策产生的附加安全性需求。在安全控制平台系统开发中，该系统采用2取2的架构，通过我们的安全分析，应避免共因失效，因此在每个通道的软件需求上有相异性的要求。比如，通道A的CRC采用查表法计算获得，通道B的CRC采用多项式除法获得。同时，在软件需求阶段，可以针对一些关键功能和数据接口定义，采用FMECA方法，结合公司级的软件失效模式库，开展软件失效模式危害影响分析。这类附加的安全需求可能影响系统层级的安全需求，形成软件到系统的需求反馈回路，并形成新的系统安全需求，再向软件层级进行迭代分配。整个需求获取和验证过程如图2所示。

这一阶段的重点是软件安全需求可追溯性和完整性验证，对软件需求的FMECA分析不是必须的，可以由项目安全人员根据项目需要确定分析范围，选择性开展。在对软件安全需求进行验证的过程中，利用公司级的软件失效模式库，可以有效指导我们进行安全关键软件功能模块的确定，对影响较大的功能展开快速有效的影响分析，提高分析效率。

在这一过程中，我们得到了完整的软件安全需求、安全关键功能、安全相关的接口和全局数据定义，作为我们下一阶段安全分析的输入。

图2 软件安全需求的获取

2.2 软件架构设计阶段的安全分析和验证

软件架构描述的是直接构成系统的抽象模块以及各模块之间的通讯，一个传统的软件架构包括与硬件的接口、服务层(包括操作系统和调度器)以及运行在系统上的各个功能模块。软件运行在相应的硬件上(比如CPU、板卡等)，如图3所示。软件的架构模型与系统的硬件架构的选取息息相关，有必要从系统软件运行的物理架构对软件进行解剖，可以得到软件运行在不同硬件上或者同一硬件上不同分区的限制条件和衍生的非功能性安全需求。比如，安全平台的计算单元采用的是二取二结构的板卡，软件运行在不同的CPU上，双通道通过双口RAM接口进行交互，则对其中一些全局变量、接口(组件之间、软件和硬件之间)展开安全分析进行安全分析时，就会产生软件交互需要保证双通道独立性的安全需求(双通道之间交互不采用明文、不使用对方通道的控制信息、设置超时等待机制等等)。在软件实现的过程中，因技术的选取可能有不同于系统的运行模式，对各模式之间转换条件的分析，可以得到因软件本身引入的功能安全需求。而对软件数据流、控制流、时序等逻辑的分析，既可以得到因软件本身引入的功能安全需求，也可以对绝大部分系统分配的安全需求进行验证，保证这些需求在软件架构设计的过程中被正确实现。这一过程其实是系统安全需求在软件级进行细化的过程。比如，在安全平台开发的软件安全分析过程中，通过进行软件本身架构的安全分析，我们发现90%以上的软件安全需求可以和系统级的系统安全需求相对应，形成追溯关系。

在我司安全平台的主控系统软件设计时，软件有初始化、限制模式、更新模式和正常模式；二取二每个通道软件运行依赖于不同的操作系统、使用不同的编译器和编译选项，对于安全关键变量和常量设计保护模式并采取访问控制措施；对执行安全功能的模块采用了最小化设计理念。这一阶段从软件实现逻辑、软件运行模式、软件运行依赖的物理架构和数据定义4个维度对软件展开错误影响分析，对执行安全功能的模块执行逻辑进行验证确认，得到软件相关的安全需求，与继承自系统的安全需求进行对比，保证了系统级安全需求在软件层面的落地。

图3 软件架构

同时，对软件需求的实现和架构设计过程中用到的技术措施要求进行验证。分析过程和方法如图4所示。

图4 软件架构阶段安全分析验证流程

安全架构的验证，主要集中在2个方面：一是采用检查单的形式对各个软件模块在设计的过程中符合EN50128 A.3表格中对应SIL等级的开发技术使用要求进行验证；另一方面，需要基于软件需求阶段整理的安全需求，按照软件安全功能对软件模块的分配对照表，保证那些需要在软件层级进行细化验证的安全需求在软件架构设计的各个模块中被正确、完整实现。

从多个方面对软件架构进行安全分析：①对软件运行模式分析，保证软件设计正确性的过程中，可以采用结构化的论证的方法，证明软件的最终的危险状态不可达，说明其符合预期的安全功能要求。采用这种方法，可以仅关注最终对系统输出产生危害的那些条件，极大减少了分析的工作量。②对软件所依赖的硬件的物理架构和使用分配的分析，需要结合2种分析方法：一是从资源视图的角度，分析关键临界资源被哪些进程或者模块调用，安全关键的临界资源有哪些；二是从时序图的角度，分析关键临界资源在何时被什么进程或模块调用，从而得出需要在什么时候对哪些临界资源施加保护和监控措施。③对软件的逻辑和数据定义分析可以采用传统的数据流和控制流分析，检查软件功能的执行次序和依赖性，分析识别遗漏的以及和软件需求规定不一致的功能。④利用模快或者组件之间的数据流图，可以根据变量的用途，确定关键变量(特别是模块间共享的全局变量)，说明对数据的约束，确定数据的来源、处理及目的地。基于这些信息，确认重要数据在使用前后是否进行了检查，确定变量的存储和访问方式，防止变量未经许可的读写。

软件错误影响分析阶段，可能产生一些衍生的安全需求，需要反馈到系统级，由系统级向下分配。同时，有可能产生一些需要在软件代码安全验证阶段进行细化检查的安全相关项。在安全平台软件开发阶段对架构的验证过程中，将自检功能中需要检测的项和在在测试计划中不是采用测试的方法进行验证的项分配到了代码级，需要在最底层进行进一步确认。

另外，对于一些特殊算法的验证，可以采用仿真的方法进行，参见文献[8]。

2.3 编码实现阶段的安全代码走查

代码走查对于发现软件开发过程中的安全缺陷十分有效，在这一阶段，验证代码实现的正确性比进行代码级的安全分析更有意义。安全关键代码走查采用静态分析的方法为主，其检查主要集中在3个方面：

(1) 检查上级分配的安全功能点是被哪个模块的哪个函数实现的，是否正确实现了分配的功能；

(2) 追踪实现功能的函数被哪些模块在什么时间点被调用，分析调用的时间点是否正确，是否存在应该调用该函数而未被调用的情况;

(3) 分析非安全模块与安全模块之间的交互，检查非安全模块对安全模块是否有非预期的影响，非安全模块和安全模块之间的交互是否有足够的防护措施。

安全代码走查的实施可以分为4步，如图5所示。

图5 软件安全代码走查流程图

(1) 根据安全性需求和上一阶段输出的需求进行安全确认项，选取关键模块的代码作为审查对象。

(2) 根据代码编写需要遵循的安全规则和需求描述，验证代码实现的正确性(包括输入验证、错误处理代码、复杂代码和进行验证、监视的代码)，针对安全性问题对安全性相关的代码进行检查；同时，需要在各个模块接口层面验证非安全功能模块是否对安全功能模块有负面的影响。

(3) 根据第二阶段的审查结果，向上追溯检查软件架构的安全问题，并重新确定检查范围，再次展开安全相关代码走查，直到审查的代码达到规定的安全标准。

(4) 对于安全关键软件的编写，EN50128标准还要求遵循相应的编码规范，比如对参数使用前的检查，对指针使用的限制，对前置条件和后置条件的验证等，避免因软件错误的传播导致系统发生危险的失效。这部分检查可以采用单元测试分析自动化工具完成，能极大提高效率，避免漏检。在铁路信号系统行业，一般每个公司会参照标准和行业规范，结合公司实际，制定公司级的编码规范，并开发自动化工具完成规则符合性检查。安全平台软件的规则检查就是采用工具实现的。

3 软件安全保障流程可行性分析

在实际工程应用中，要保证本文设计的软件安全保障流程的落地，需要从2个方面考虑：一是该流程符合EN50128行业标准，确保在软件生命周期内的各项活动到达标准中规定的安全完整性等级的要求，确保设计的软件和相关系统能获得第三方独立评估机构的证书。这是我们设计的软件和系统能够获准上道运行的必要条件。同时，该保障流程需要具有可复制性和高效率。表1给出了EN50128标准中软件保证流程要求和本文的软件安全保障流程的对应关系。

该软件安全保障流程应用到了我司的轨旁安全平台软件开发的过程中，能使安全人员按时完整安全分析、验证和确认各项安全活动，顺利确保了该产品通过第三方独立评估机构的评估，并获得了EN50128 SIL4(安全完整度最高等级)证书。该产品目前已经广泛应用于我国城轨线路中。

4 总结

轨道交通信号系统中的软件安全分析是个系统工程，需要按照EN50128等准的安全要求，从不同的维度、贯穿软件生命开发的各个周期进行分析和验证。本文结合所开发的安全控制平台的软件开发过程提出了软件开发需求、设计和编码阶段的软件安全分析和验证流程，并给出了具体的实现方法，具有较强的可操作性，可以和V模型右边的软件测试确认和质量保障一起构成完整的软件安全保障流程。

表1 软件安全保障流程阶段对照表