基于需求建模的功能安全分析方法

袁 捷

（上海电气泰雷兹交通自动化系统有限公司,上海 201206）

0 引言

作为安全苛求系统，基于通信的列车控制系统（CBTC）承担着列车定位、列车防护及联锁控制等关键功能。为了满足系统的安全完整性等级要求，在系统生命周期的多个阶段都需要进行功能安全分析。

安全分析的主要目的是识别系统及子系统危害，提出缓解措施及功能安全证据等[1]。对于安全分析，EN50129 标准[2]推荐且应用较为广泛的方法包括失效模式、影响及危害分析（FMECA）、失效模式及影响分析（FMEA）、危害与可操作性分析（HAZOP）、故障树分析（FTA）等。例如，文献[3]将FMECA 方法应用于城市轨道交通车辆故障分析；文献[4]则对FMECA 方法进行改进并应用于动车组牵引传动系统；文献[5]将FTA方法应用于CBTC 系统数据传输安全分析；文献[6]和文献[7]运用HAZOP 方法分别对城市轨道交通车站的人员防护开关功能和列控系统安全软件黑盒测试进行了分析。随着全自动无人驾驶等技术的不断发展，CBTC 系统的功能自动化程度及复杂度越来越高，加剧了功能安全分析工作的难度。而这些分析方法依赖人工推理演绎，其结果的完整性和准确性受限于分析人员的能力及对系统的熟悉程度。

近年来，基于模型的分析方法逐渐成为研究与应用的热点。文献[8-9]总结了基于模型的分析方法在航空领域的发展与应用；文献[10-13]分别运用不同的建模方法对区域控制器移动授权计算、列控系统ATP 等级转换、列控系统列车追踪、区间占用检查等功能和场景进行了研究。该文探讨一种基于需求建模和仿真进行安全分析的方法。

1 需求建模及安全分析

该文使用达索系统的Stimulus 需求仿真工具，基于需求建模进行功能安全分析，其原理见图1。主要实施步骤如下：

图1 需求建模及安全分析原理

步骤1：在功能设计阶段，根据功能需求建立功能行为模型；

步骤2：将安全需求注入需求模型；

步骤3：通过设定的功能场景或随机场景驱动需求模型；

步骤4：根据模型的输出结果分析安全需求的符合性。

该文选取2 个功能实例进行分析。

（1）车门保持关闭控制，其特点是功能场景复杂。

（2）轨旁控制单元主备切换，其特点是多个子系统关联、变量多、逻辑层级丰富。

2 车门保持关闭控制（应用实例一）

车门保持关闭控制功能是全自动无人驾驶项目中的新增功能，当车门保持关闭命令激活时，车门无法打开；反之，车门可以在车辆静止时手动打开。主要应用场景如下：

（1）列车行驶过程中激活车门保持关闭命令，禁止车门打开。

（2）正常停站时释放站台侧车门的保持关闭命令，允许该侧车门打开。

（3）列车在区间迫停时，根据乘客请求、中央操作员远程控制命令及逃生平台布置等因素判断激活或释放车门保持关闭命令。

（4）系统发生故障时，根据列车运行模式、通信状态等因素判断激活或释放车门保持关闭命令。

该功能的输入变量包括乘客紧急手柄输入状态、列车位置、逃生平台布置、列车运行模式、中央操作员远程控制命令等，输出变量为车门保持关闭控制命令。该功能虽然输出命令单一，但输入变量众多，任何一个变量的变化都可能导致一个新的场景出现，因此所涉及的功能场景非常丰富。

2.1 需求建模

在进行建模前，首先应当划定需求分析边界。车门保持关闭控制功能主要由车载子系统实现，安全分析聚焦于车门保持关闭的控制逻辑，其他相关的列车定位及中央远程命令校验等功能将被简化，仅作为输入变量用于驱动仿真功能实现。

结合需求设计，模型中的需求分为三部分：自动/远程释放区域判断、乘客紧急手柄状态监督、车门保持关闭命令判断。其中，车门保持关闭命令判断又分为自动释放、远程释放、本地释放和故障释放等。需求模型结构见图2。

图2 车门保持关闭控制需求模型结构

2.2 随机仿真及分析

需求建模完成后，将各个需求模块的输入、输出接口相连接，并将安全需求设置为“观察者”模式，建立仿真环境，见图3。仿真运行时，安全需求作为“观察者”独立于功能需求之外，且跟随功能需求状态实时运算。“操作员命令”和“乘客输入”为2 个驱动模型运行的外部输入变量。在该实例中，安全需求设置为“系统未处理或未锁存乘客紧急请求”。

图3 车门保持关闭控制仿真环境

仿真环境搭建完成后进行随机测试。在随机测试中，除有明确定义的变量外，其他未定义的输入变量默认为随机值，且每个周期取值不同。随机测试可以有效提高分析的需求覆盖率，帮助识别需求冲突、需求缺失等错误。

图4 展示了一个需求冲突错误示例，该需求冲突由测试中注入的随机变量组合触发。列车故障后恢复正常运行场景与远程/本地请求释放场景叠加，多种释放逻辑产生了不同的车门保持关闭控制命令。即图2 中的“远程释放”需求模块判断需释放（图中“HDC=Enable”）车门保持关闭控制命令，而“故障释放”需求模块判断需施加（图中“HDC=Disable”）车门保持关闭控制命令，由于不同的需求模块控制同一个输出变量，但赋值不同，工具报告需求冲突。对应到实际功能场景，该需求冲突由乘客请求、操作员命令、通信中断及恢复等多种运营场景叠加导致，在常规静态分析或测试中很难被识别。在设计阶段，针对该冲突进行需求修订后该问题得以解决。

图4 需求冲突示例

在多重场景并不完全独立互斥的情况下，可能同时触发矛盾的安全需求，导致出现冲突。对于输入变量众多、场景复杂的功能，传统分析不容易识别此类冲突。借助需求建模，功能需求和输入变量得以模型化，输入变量可以任意、随机取值，大大丰富了分析所覆盖的实际运营场景，有效提高了安全分析的完整性。

3 轨旁控制单元主备切换（应用实例二）

3.1 需求建模

安全功能建模与仿真分析除了利用随机变量组合获得更多的场景覆盖和冲突识别之外，还可以为场景分析提供精确、快速的结果输出，提高安全分析的效率与准确度。

轨旁控制单元主要承担列车位置追踪、进路处理、移动授权、联锁控制等安全关键功能，支持主、备机冗余配置，正常情况下，只有主机对外输出控制指令。同时，主机和备机互相通信，备机时刻保持与主机状态同步。当主机故障时，备机无缝接管控制权，成为新的主机并对外输出控制指令。

轨旁控制单元切换模块的逻辑层级、互动关系非常复杂，涉及控区内多台设备的处理逻辑、数十个接口控制变量、几百条功能需求等。传统分析方式需要人工完成特定场景下的系统反应推演，分析是否符合安全原则，非常有挑战且耗时，而基于模型的分析方法可以有效提高分析准确度与效率。

对于中大型安全功能，可以分层次进行需求建模，实现对安全原则的验证。主要建模步骤如下：

（1）将目标需求划分为几个模块，定义模块之间的接口变量。

（2）根据每个模块的需求及接口变量分别搭建需求模型。

（3）将各模块的需求模型进行组合，并通过定义的接口变量连接，封装成为完整的功能模型。

轨旁控制单元主备切换功能需求模型分为4 个模块：通信接口、对端状态判断、同步状态判断和主备状态判断。完整的需求模型结构见图5。

图5 主备切换需求模型结构

3.2 场景仿真及分析

根据实际的冗余架构，搭建由A 机和B 机组成的仿真环境，模拟主、备机冗余配置。其中，A 机和B 机的需求完全相同，即需求无须重复定义。在该实例中，安全需求定义为A 机和B 机不能同时处于主控状态，即主备切换的安全原则。

通过设定不同变量的初始值及运行状态，可仿真不同场景下的系统切换反应。以单点通信故障情况下的主备切换场景为例，初始变量设置为A 机优先主控，运行7 s 后A 机故障，随后A 机进入“故障消除－故障再次发生”的循环状态。

根据设计，该场景下应当有一台设备处于主控状态，另一台在与主机同步后进入备用状态，当主机故障后，备机立即接管成为主机。仿真结果见图6。系统启动时A机进入主控状态，B 机先进入初始化状态随后进入备用状态；当模拟的故障发生后，A 机退出主控、进入初始化状态，B 机立即接管进入主控状态；之后A 机故障消除进入备用状态，或再次故障进入初始化状态，B 机始终保持主控。该仿真结果符合设计意图，且仿真过程中工具未报错，安全需求始终得到满足。

图6 单点通信故障主备切换场景仿真结果

建模仿真分析的优势之一在于准确且高效。一旦模型建立，工具可以根据分析者的任意输入变量组合快速给出系统反应结果，从而检验需求设计是否符合预期、安全需求是否得到满足，并且场景分析结果及安全需求的符合性由工具自动给出，可以减少分析过程中人为错误的影响。

4 结语

该文通过2 个应用实例介绍了一种需求建模分析方法，通过需求模型的搭建和测试，帮助识别需求冲突、设计意图偏离、安全需求违背等错误。仿真分析可以通过随机的输入变量组合呈现更多场景，大大提高场景覆盖率。同时，通过需求建模将功能设计数学化，基于模型的分析结果可以有效减少人员主观因素影响。对于变量众多、控制逻辑复杂的功能，该分析方法可以对传统分析方法进行有效补充。