行业新闻

您的位置:首页 >> 新闻中心 >> 行业新闻

轨道分享 | 从系统论角度看轨道交通安全分析

2020-07-20|来自: 鉴衡认证|发布:薄云览

引言

随着以全自动无人驾驶的轨道交通自动化控制系统的应用,城轨的运营安全更加体现了“一个大脑”的概念。大家都提及并认同了“系统安全”的概念,但真要到操作的时候,业主、厂家都会遇到一些实际的问题,例如:1)所谓的系统安全分析方法是什么?为什么它就能比既有方案先进,你能不能例子给我证明?2)厂家如何运用和做好安全分析?身为厂家的高管、市场人员,我如何去评价和展示我们产品的安全水平?3)子系统招标是分别实施、不同专业厂家各自为战的,而到使用端的业主又是肯定集成到一个“脑子”下的。那业主又如何运用系统分析方法来保障自己的工程按要求交付运营?笔者希望以此篇作为开题,就上述问题与行业同仁一起探讨。

1.传统安全分析方法的局限性

在轨道交通各类系统的安全评估工作中,风险分析是一个非常重要的环节,确定被评估系统的边界、功能、接口、工作环境,识别系统可能产生的危害,以及危害发生概率和伤害的严重度所构成的风险,以此采用针对性的风险降低措施以保证安全性。传统的风险分析方法有FMECA(失效模式影响和危害性分析),FTA(故障树分析),HAZOP(危害和可操作性分析)等,这些方法在安全系统的风险分析中应用已非常广泛。它们起源于上个世纪五六十年代,分析的基础为组成系统的部件失效,失效模式可识别且失效概率可量化,通过逐项穷举的方法进行分析,为目前安全分析的主要方法。随着系统复杂程度的提高,软件在系统中占有的比重增大,系统之间交互的接口越来越多,传统的风险分析方法应用显得有些吃力:

(1) 耗费了大量的人力和时间成本去对每个部件的失效模式进行分析,寻找各个组件的失效概率,而识别的危害难以覆盖全面,未知的危害还是会发生;

(2) 系统的每个部件并没有故障,而部件构成的整体系统却发生了事故,发现是部件之间的交互出现了问题,需求和场景考虑不全面;

(3) 事故的调查过程中发现,导致事故的原因是一连串多个部件都无法正常工作,这些现象看似是没有关联的,貌似是巧合,未能寻找深层次的原因。

为什么会导致这些困惑呢,使用的方法本身并没有问题,而分析的对象由于系统及所处的环境复杂度增加,导致方法的适用性发生了变化。这需要引入现代系统理论新的分析方法,以系统工程思维重新认识问题。什么是系统工程思维,不了解的同学感觉非常高深,其实它的基本概念并不复杂,经典控制理论中,任何控制系统由以下四部分构成,控制器、传感器、执行器、被控对象,它们形成一个闭环。比如车门控制系统,控制器是门控器,执行器是电磁阀和继电器,传感器是检测车门位置的限位开关,被控对象就是车门本身。系统工程论就是分析这四个对象之间的关系,达到所要求的平衡态。  


对于传统安全分析方法,比如FMECA,分析的出发点是每个部件的失效模式和失效概率,由点及面的分析,聚焦点是部件本身,对于组成系统的部件之间的配合关系不会涉及,在简单系统中使用效果不错,而面对大系统时失效模式难以估计,应用效果不佳。

2.什么是系统论的安全分析

基于系统工程理论的系统理论过程分析方法(STPA, System-Theory Process Analysis)是由MIT的Nancy Leveson教授提出,这种方法侧重于分析组成系统各部件之间的联系和实现安全功能时所满足的约束,认为事故是由于控制中的环节出现了问题,由此发现控制过程中的各个环节之间由于非正常的交互或控制本身出错导致的问题。

STPA安全分析前需要具备两个前提条件:

一是识别场景中的事故和引起事故可能的危害,以及如何对危害进行控制避免事故的发生,也就是安全约束;

二是建立系统的控制结构图,形成安全分析的基础;

这两点前提条件要求分析者要深入系统设计,了解被分析对象的控制逻辑,以及它和其它外部系统之间的关系,做到知己知彼。

在具备以上条件后,STPA安全分析分为两步:

一是识别潜在的危险控制行为,它采用了控制过程中的四类典型引导词以便于分类识别,包括:

  1. 控制器未提供所需的控制行为;

  2. 控制器提供了错误的或不安全的控制行为;

  3. 在错误的时间(过早或过晚)提供控制行为;

  4. 控制行为停止的过早或作用时间过长。

二是分析以上四类不安全控制行为在运行场景中可能发生的致因点。这一步最为关键,STPA提供了一个通用的致因模型,如下图所示,它不仅仅考虑部件本身的失效,也考虑了对象的控制算法,被控模型的不正确,与外部系统的关系,以及干扰影响,相比传统方法更为全面。


根据以上模型找到致因后,再对症下药,制定对应的控制措施,后面的过程大家就比较熟悉了。

3.系统论安全分析方法应用举例

通过上面的介绍,可以对系统STPA分析方法有了感性的认识,下面通过一个事故示例进行说明。这里借用去年港铁发生的一起事故报告,根据事后调查报告的结论已非常清晰,这个事故具有典型性,说明了大系统以及软件带来的复杂性,可以为大家提供一些启示。

先来回顾一下2019年港铁撞车事故,以下来源于香港机电工程署2019年7月5日《港铁荃湾线新信号系统测试事故调查报告》:2019年3月18日香港荃湾线新信号系统演练期间,一列非载客列车在经渡线准备进入中环站时,与另一列由中环站开出正驶经该线的列车发生碰撞。事故导致2辆列车损毁严重,部分车厢玻璃破碎,车身扭曲,两名列车司机被送往医院。报告事故原因由于信号系统软件中出现3项软件编程上的执行错误,最终导致2辆列车相撞。


事故过程不多说,感兴趣的人可以查阅官方报告。这里从系统本身入手,采用STPA方法进行分析,在这个场景中,事故为两车车车相撞,车与车之间的冲突区域检查由区域控制器(Zone Controller,简称ZC)进行控制,ZC接收所有列车的实时位置信息和轨旁区段占用信息、道岔状态、信号机状态,计算车与车之间的安全距离,向列车发送行车许可(Move Authority,简称MA)。为了提高系统的可用性,信号系统采用了三套独立的ZC系统构成冗余,两个为热备冗余,另外一个为温备冗余,温备冗余为一个独特设计。系统设计中,温备冗余系统为避免共因故障,部分涉及行车安全的数据如冲突区域数据,为自身生成,并非全部从主用系统中获取。

根据列车控制系统的控制原理,行车许可控制的系统结构图如下:


由于篇幅有限,这里只针对发生撞车事故的一种危害(行车许可冲突)进行分析,采用STPA步骤一的四类引导词进行分类,识别错误的控制行为是否会导致事故发生,如下表所示:


在步骤一中通过四类引导词会提出了系统的安全约束,但这还不够,要结合系统架构图找出违背这些安全约束的致因点,才能通过控制措施消除或控制风险。根据STPA的致因模型,画出行车许可控制的致因模型图,如下:



根据上面的致因场景图,逐项细化和分配安全约束,转换为对系统的安全需求,纳入系统的开发和测试工作中。例如ZC用于MA生成的数据,除了列车发送的数据和轨旁设备状态,还要考虑备用系统在切换过程中由于数据不同步带来的输出不一致影响,这也是此起事故发生的根因。需要说明这里为解释STPA方法,这里对场景做了简化,实际系统的复杂度远高于此,安全分析也要进行大量的工作。

4.总结与展望

熟悉列车控制原理的读者可能会想,这些需求在传统信号系统需求已经全部考虑了,实际价值有限。但通过以上分析过程可以看出,系统论分析方法通过对整个控制过程的分析,能够高效地找到风险致因点,以及识别出安全约束,这相比于传统的FMEA、FTA基于可靠性理论的方法性价比会很高,避免耗费大量精力却收获很少,可谓切中要害。另外,它扎根于系统设计本身,在对于新系统、新技术、以软件为核心的大系统,能够在需求设计阶段就予以考虑,提高安全分析的效率,发挥安全工程师的更大价值,避免陷入繁琐的流程中。

系统论STPA分析在系统工程领域如航空航天、汽车自动驾驶、军工领域均有应用,轨道交通领域中还比较少,EN50126 RAMS标准中的安全分析方法以传统方法为主,随着我国轨道交通自动化水平的提高和全自动运行系统的应用,单个子系统安全向全系统转变,大量新技术应用于安全功能。这要求用户和系统开发方站在全系统的角度,深入理解系统控制结构和相互作用关系,开展系统性的安全分析,寻找子系统之间的安全约束,建立致因模型,制定控制措施,消除和降低事故发生的风险。本篇作为抛砖引玉,后续将结合安全评估中一些场景案例,希望与各位读者探讨。



相关标签: