基于精确需求定义方法的列车自动保护（ATP）软件开发＊

常 鸣

（卡斯柯信号有限公司，200071，上海／／工程师）

软件开发过程中，需求是用户与产品提供商，或系统分析师与开发团队间的契约，其质量影响着最终产品的开发进度及其质量。一份精确、完整、一致、可追溯的需求规格书，可避免开发人员的理解偏差，极大帮助后续的设计编码以及测试工作；并且，通过细致的需求分析，可以在开发的早期阶段发现潜在问题，及时修复，降低处理问题的代价。

在ATP（列车自动保护）等安全苛求软件的开发中，尤其应强调需求的质量。此类产品开发周期和使用寿命较长，需求变化相对不大，但对于安全和可靠性要求非常高，必须要做到软件的每一步都是可控、可预测和可验证的。

一些传统的需求分析方法，如基于UML（统一建模语言）的用例分析等，在商业软件开发中应用广泛，其特征是比较直观和易于理解；但图形化方法往往缺乏严格的语义定义，且用例描述以自然语言形式，难于精确规范期望软件的行为，容易使开发人员产生歧义。因此，传统方法更适合于非安全软件或者系统级需求的定义，不适于安全苛求软件的需求定义。

应用基于数学符号推理的Z或VDM（维也纳开发方法）等形式化需求建模，以及在此基础上的形式化证明和代码自动生成，是目前最严谨的软件开发方式。法国阿尔斯通的URBALIS城市轨道交通信号产品中的车载ATP软件，采用B方法开发，已在巴黎、米兰、北京、上海等超过50个项目中得到应用。然而，形式化方法的困难在于其数学语言晦涩难懂，且开发流程和工具与当前开发者熟悉的方式不同，需要较长时间的学习才能应用。

在iCC200型车载ATP开发中，使用了一种“基于精确需求定义”的方法，在软件需求层面，采用易于开发人员理解的“伪代码”形式，精确定义每条功能需求，以此消除自然语言描述的模糊性。该方法有以下特点：

（1）针对每个功能点，定义特定的“需求变量”，作为一条需求。该变量可以被其他需求所引用，但只能在本条需求中被修改。

（2）使用类似“伪代码”的语法规则，表示需求变量的产生条件。对于周期更新的变量，体现出时间先后关系。

（3）软件需求自身是完备的。从边界来看，所有的外部输入和输出之间可由一系列需求变量的相互引用关系所链接，组成功能链。

（4）每条“需求变量”都是可观测的。其最终运行结果能在软件维护工具上显示，用于确认其正确性。

（5）每条需求都是可追溯的，通过唯一的标签标记该需求。软件需求来自系统级的分配，而每条需求也要被设计实现所覆盖。

1 需求阶段

根据EN 50128的开发模型，软件需求应当来自系统需求或相应安全分析结果的分配。按照自上而下的设计方法，需求粒度逐渐变细，即系统设计阶段的需求描述较粗，而软件级需求非常精确。

例如系统需求［iTC＿CC－SyRS－0278］，表示车载控制器（CC）在限制人工模式（RM）时应当监控车速是否超过项目可配置的限速值，若超过则应输出紧急制动。系统需求描述如下：

［iTC＿CC－SyRS－0278］

当选择的驾驶模式是RM时，如果列车超过Driving＿mode／Restrictive＿manual／Limit＿speed速度（项目配置的安全参数），CC将触发紧急制动。

＃Category＝Functional

＃Contribution＝SIL4

＃Allocation＝ATP Software

＃ Source ＝ ［iTC－SyAD－0104］，［iTC－CCSSHA－0070］

［End］

在ATP软件需求规格书中，会有多条软件需求追溯上述［iTC＿CC－SyRS－0278］，通过＃Source进行标识。以软件需求［iTC＿CC＿ATP－SwRS－0497］为例，定义需求变量RMoverSpeed作为RM下是否超速的判断标识，需求如下：

［iTC＿CC＿ATP－SwRS－0497］

RMoverSpeed，布尔量，监控列车速度是否超过RM模式的限速值。判断条件如图1所示。

1）当判断结果为TRUE，表示车速超过RM模式限速；

2）当判断结果为FALSE，表示车速未超过RM模式限速。

＃Category＝Functional

＃Contribution＝SIL4

＃Source＝［iTC＿CC－SyRS－0278］，［iTC＿CC＿ATP－SwHA－0121］

［End］

图1 RM超速判断条件

可以看到，基于精确需求定义方法的ATP软件需求完全符合EN 50128在以下方面的要求。

（1）唯一性和一致性：对于需求变量，仅在定义它的需求中描述其设置和判断条件；其他需求中仅可引用该变量，但不能修改，从而避免相同功能在多处描述引起不一致的问题。例如在RMoverSpeed的赋值中引用了RMselectedDrivingMode和TrainMaxSpeed等其他需求变量作为判断条件，但不会修改它们，以此保持需求的唯一性和一致性。

（2）清晰性和精确性：需求中以伪代码形式明确定义了RMoverSpeed的初值，运行中取真假值，以及保持不变（即等于上周期值）的条件。如此避免了自然语言描述的含混不清。此外，通过（k）或（k－1）标识，说明使用的是本周期还是上周期的结果，具有时间准确性。

（3）完备性：一般来说，由多个软件需求形成功能链，共同完成某个系统功能。功能链从软件的输入开始，经过一系列处理，最后到软件的输出。图2所示为RM超速判断的功能链，通过一系列需求变量 如 RMselectedDrivingMode，TrainMaxSpeed，ValidTrainSpeed，TrainStopped等，处理了从软件外部获取的输入信息，作为RMoverSpeed的判断条件；而 RMoverSpeed本身，也被 Emergency－Break需求所引用，作为输出紧急制动的条件之一。所有软件需求形成的功能链，共同实现从外部输入到输出的完整的ATP功能。

（4）可追溯性：iCC200开发中，每条需求和设计均分配有唯一的标签，使用Reqtify工具进行追踪，由独立的人员进行可追溯性验证。精确定义的需求，也便于开发人严格按照需求实现。在发现缺陷后，需提交变更请求（CR）进行问题追踪。如果需求和实现均有误，则必须先修改需求文档，再提交子CR修改相应的设计和代码，避免需求与实现不一致的情况。

图2 RM超速判断功能链

（5）可验证性：验证（Verification）一般是通过分析（或测试）手段，检查本阶段的工作是否在完整性、正确性和一致性方面满足之前阶段的要求。基于精确需求定义的方法，验证人员通过检查如图2所示的功能链，可清晰地判断出ATP软件是否实现了系统需求中期望的功能。

（6）可维护性：在软件需求中所有定义的“需求变量”，均能够在维护诊断工具中记录并回放显示。因此，维护人员可通过检查功能链路上所有相关需求变量的状态，来确认软件功能是否被正确实现；如果发生了问题，也可以据此分析出产生错误的原因。

（7）可测试性：因为每条需求均由“伪代码”定义，故可以方便地进行测试。具体在本文第3节说明。

2 设计编码阶段

应用基于精确需求定义的方法，虽然在需求阶段已明确定义了软件要完成的功能，但并未涉及所有的实现细节。以下方面，要在设计编码阶段细化：

（1）非功能性需求。需求规格书中以图1形式描述的主要是功能性需求，对于非功能性需求要在设计中体现。

（2）算法优化。每条需求均以自身定义的“需求变量”为中心，但对于不同的需求变量可能存在相似的判断条件。在设计时可合并这部分内容，优化算法。

（3）具体硬件的驱动或库函数接口。需求规格书中不涉及此类内容。

（4）抽象数据类型或通用算法实现。需求定义中使用到的抽象数据类型（如链表）或算法（如遍历）等，需设计时细化。

（5）数据结构的定义。

（6）模块执行的先后顺序和调用关系等。需求规格书一般以场景或功能模块为基础进行划分，而在设计时需要转换为实际的进程或者函数模块。

图3是基于精确需求定义方法与传统开发方法的工作流示意图，纵轴和横轴分别表示目标产品期望包括的信息内容和实现细节。图3中实线表示的是基于精确需求定义方法的工作路径，而虚线表示传统方法的工作实现路径。可看到，基于精确需求定义的方法要求在早期的需求分析阶段，就尽可能多的识别出产品所需包括的信息内容，而在设计编码阶段主要是实现技术细节；传统的开发方法，往往是随着开发的深入，逐渐识别出更多的信息内容并加以实现。

图3 基于精确需求定义方法与传统软件开发方法的工作比较

实际上，基于精确需求定义的方法在需求分析阶段已完成了绝大部分的功能分拆和定义工作，因此开发中所需的设计和编码时间会小于传统方法。图4所示为iCC100（BM）与iCC200两代ATP产品的开发投入比较，二者的规模类似。iCC100（BM）使用传统开发方法，而iCC200使用了基于精确需求定义的方法。可以看到：尽管iCC200的需求阶段投入是iCC100（BM）的一倍，但在设计和编码阶段却节省了三分之一；更重要的是，精确定义的需求有效防止了由于理解偏差而导致的实现错误，显著减少了在测试阶段由于发现问题而返工所需的时间和人力。如图4所示，同样达到出口标准时，iCC200在测试阶段的投入只有iCC100（BM）的一半。

图4 iCC100（BM）与iCC200的开发投入比较

此外，对于安全苛求系统，所有内容均应进行安全分析，若识别为安全需求则必须应用安全技术对潜在的危险进行防护。如果按照传统方法，到了开发的中后期阶段，可能仍会发现新的安全相关项，这必将导致增加或修改既有的安全设计，不但影响开发进度，更有可能引入安全隐患。因此，在开发的前期阶段，应尽可能完整地识别出所有开发内容，这对于安全苛求系统是非常重要的。另一方面，安全苛求系统的需求变化相对较少，但生命周期可长达数十年，这也使得在开发前期阶段投入更多的时间和人力成为可能。

3 测试阶段

软件的单元测试和集成测试，可参照传统方法进行。而基于精确需求定义的方法，对软件产品的确认测试工作非常便利。根据EN 50128定义，确认（Validation）是指通过分析或测试手段，判断最终产品是否满足其需求的定义。从实际经验来看，软件确认测试是评判软件是否达到开发目标的最重要手段。

依据安全软件开发要求，软件确认测试用例应当严格依据软件需求撰写，即需要在用例中明确设定被测需求的前置输入条件和期望输出结果。应用精确需求定义方法，需求变量的期望值及其对应条件已很明确，因此相应测试用例的输入输出结果也可以被精确定义，进一步使得基于脚本的自动化测试成为可能。例如，针对RMoverSpeed的确认测试，可根据图1中的条件，模拟设定TrainMaxSpeed或ValidTrainSpeed等值的状态，通过ATP软件维护工具，观察在不同条件组合下RMoverSpeed是否按照期望变化。

当根据CR发生需求或实现变更后，需进行软件确认测试回归。对于精确需求定义的ATP软件，回归测试涉及的用例范围可依据以下原则进行确定。

（1）直接修改项。例如修改了RMoverSpeed需求（或实现）的判断条件，那么该条需求对应的测试用例必需进行回归。

（2）直接影响项。除“直接修改”外，如果RMoverSpeed所引用的RMselectedDrivingMode或TrainMaxSpeed需求（或实现）发生变更，那么RMoverSpeed对应的测试用例也必须进行回归。

（3）间接影响项。除“直接修改”和“直接影响”外，如果修改了RMoverSpeed所引用的RMselectedDrivingMode或TrainMaxSpeed等需求（或实现），那么诸如EmergencyBreak等引用了RMoverSpeed的需求所对应的测试用例，也应挑选部分进行回归。

4 结语

基于精确需求定义方法开发的iCC200型车载控制器，已经通过了TUV莱茵的第三方安全认证，并在上海张江实训线上完成了中期试验。

基于精确需求定义的开发方式，能够解决需求描述中的精确性和完备性问题，并在系统的可追溯性验证和确认测试中表现出比传统方法更好的效果。虽然本方法要求在前期开发阶段就进行大量细致的需求分析工作，但可有效减少后续设计和实现阶段的技术和安全风险，这对安全苛求系统软件的开发是非常重要。

此外，如果描述精确需求的“伪代码”能遵循或可转化为特定的模型语言，则可作为应用形式化方法建模和证明的基础，并通过自动工具产生最终的软件代码，进一步缩短开发周期，更能提高软件的安全性和可靠性。

［1］CENELEC EN 50128—2011.Railway applications－Communications，signalling and processing systems－Software for railway control and protection systems［S］.

［2］朱雪峰，金芝.关于软件需求中的不一致性管理［J］.软件学报，2005，16（7）：1221.

［3］燕飞.轨道交通列车运行控制系统的形式化建模和模型检验方法研究［D］.北京：北京交通大学，2006.

［4］斯多（Stahl T），沃尔特（Volter M）.模型驱动软件开发：技术、工程与管理［M］.杨华，高猛，译.北京：清华大学出版社，2009.