铁路安全信号平台开发中的安全管理实践

1、铁路安全信号平台开发中的安全管理实践摘要：介绍了某铁路安全信号平台开发中符合EN50126系列欧洲标准的安全管理实践工作，论述了符合安全完整性等级4级（SIL4）的安全管理流程。本文首先对EN50126系列标准中有关安全管理工作的相关规定进行综述；然后结合安全信号平台研究开发过程，着重介绍了符合SIL4的安全管理流程和实践方案；最后对安全管理对平台开发的实践意义进行总结。关键词：RAMS 安全管理 安全完整性等级 安全信号平台Abstract: The practical work of safety management in compliance with the EN50126 seri

2、al European Standards during the development of a railway safety signalling platform is proposed. The safety management flow against safety integrity level 4 (SIL4) is also introduced. Firstly, this paper presents a summary on safety management roles in the EN50126 serial European Standards. Secondl

3、y, the SIL4 safety management processes and practices are introduced with the research and development process of the safety signalling platform. Finally, the practical significance of safety management to the platform is summed up.Key words: RAMS, safety management, safety integrity level, safety s

4、ignalling platform随着经济和轨道运输业的飞速发展，特别是高速铁路和高密度城市轨道的建设，世界上包括发达国家和发展中国家在内的许多国家已经越来越认识到铁路产品可靠性，可用性，可维护性和安全性（RAMS）的重要性。因为产品的可靠性，可用性，可维护性和安全性与铁路运营的性能密切相关，失去任何一个性能，将对铁路的正常运营产生严重影响。特别是安全性，它是铁路信号产品的关键特征。本文首先对EN50126系列欧洲标准进行介绍，明确不同标准的相互制约关系和适用范围；然后结合某铁路安全信号平台的研究开发过程，对如何构建符合欧洲标准的安全管理系统进行综述；对项目进展过程中安全管理系统的实际运行和

5、相关经验进行总结，论述如何通过安全管理手段，在相关技术安全手段和质量管理体系的配合下，使产品最终符合SIL4要求。1. EN50126系列欧洲标准为保证产品（系统）的高安全、高可靠性，欧洲电子与电气委员会（CENELEC）制定了专门的标准，给铁路关键应用（特别是信号系统）的产品研发，设计和工程应用提供了高层次的可以借鉴的指导标准。这些标准包括：EN50126：铁路应用可靠性，可用性，可维护性和安全性的规格和证明EN50128：铁路应用通信、信号和处理系统铁路控制和防护系统软件EN50129：铁路应用通信、信号和处理系统信号安全相关的电子系统欧联盟国家已经把这些标准作为铁路信号项目必须遵循的法律

6、法规来对待。并且这些标准已经被国际标准组织（IEC）所接受， 这些标准已经成为国际标准。如IEC62278、IEC62279、IEC62425分别对应于欧标的EN50126、EN50128、EN50129。以上三个标准之间的关系如下图所示1。图 1 主要CENELEC铁路应用标准的关系图其中，EN50126定义了系统可靠性、可用性、可维护性和安全性，并且规定了安全生命周期内各个阶段对RAMS的管理和要求。但是在该标准中未定义RAMS的具体的定量目标。RAMS作为系统服务质量衡量的一个重要特征，是在整个系统安全生命周期内的各个阶段通过设计理念、技术方法而得到的。为了达到规定的RAMS，必须针对前

7、面的RAMS影响因素，在整个系统的生命周期内有效控制RAMS的影响因素，即系统的随机故障和系统故障。EN50126要求在整个安全生命周期进行RAMS管理，针对每个阶段给出应需要完成的RAMS任务，同时给出相关的具体文档和要求2。由于在信号系统中采用计算机技术越来越广泛，由软件来承担安全性需求的比重越来越大，因此软件安全性问题变得更加突出。为此EN50128针对软件的安全保证提出了相关的规范和设计标准。在该标准中，对铁路控制和防护系统的软件进行了安全完善度等级的划分，针对不同的安全要求制订了相应的标准，按不同等级对整个软件开发、检查、评估、检测过程包括对软件需求规格书、测试规格书、软件结构、软件

8、设计开发、软件检验和测试、软硬件集成、软件确认评估、质量保证、生命周期、文档等提出相应的程序与规范的要求2。EN50129定义了为了保证安全相关的铁路信号电子系统所必须满足的条件。这些条件包括：质量管理措施；安全管理措施；功能与技术安全措施以及安全接收与许可。对于安全管理，引入IEC61508提出的安全生命周期概念，就是说对于安全相关系统的安全部分，在设计时按照该步骤进行设计，并且需要进行全程的安全评估和验证，目的是进一步减少和安全相关的人为失误，进而减少系统故障风险2。系统的安全完整性是指在规定的条件下系统于给定时间内满意地实现所要求的安全功能的可能性3。安全相关系统中根据在安全功能上对安全

9、完整性的定量要求，将安全完整性分级，即安全完整性等级（Safety Integrity Level, SIL）。SIL通常由可定量计算部分（通常与硬件相关，如随机失效）和不可定量计算部分（通常与软件、技术规格、文档和过程等的系统性失效相关）共同组成3。为了获得实现系统指定功能安全完整性等级的信心，对于不可定量计算部分，需要完善的质量管理体系和符合EN50126的安全管理体系来保证。2. 安全管理系统构建安全管理过程的目的是进一步减少安全相关的人为因素在整个产品生命周期中对系统的影响，从而降低安全相关的系统故障残留风险。而使用安全管理过程对于安全完整性等级1到4是强制性的。安全管理过程是由一些阶

10、段和活动组成，将这些阶段和活动联系起来就形成安全生命周期。安全生命周期应与EN50126中定义的系统生命周期相一致，系统生命周期见图 23。系统生命周期可以根据不同开发目的加以适当调整。图 2 系统生命周期示意图考虑到某铁路安全信号平台的特点，本项目主要包括生命周期的1-10阶段。通过对这些生命周期的分析，认为可以将安全生命周期分为下面六个阶段：阶段1系统需求定义：此阶段需要识别操作和维修策略；识别操作和维修环境；识别既有基础设施限制产生的影响；评价以往RAM的经验数据；进行初步RAM分析；制定RAM政策；识别既有基础设施限制对RAM产生的影响；评价以往安全性的经验数据；进行初步风险分析；制定

11、总体的安全性计划；定义风险标准的可容许性并识别既有基础设施限制对安全性的影响。阶段2系统风险分析：此阶段需要进行系统危险和安全性风险的分析；建立风险源日志；识别会导致风险的事件；进行风险源识别以及安全性分析。阶段3系统规范：此阶段进行需求分析，包括根据风险分析结果定义系统安全需求；定义安全接收准则；建立用于控制各个不同生命周期安全任务的安全管理措施。阶段4设计实现：此阶段包括进行系统结构设计，并识别安全相关系统和非安全相关系统；对系统安全需求和安全目标进行分配；定义子系统或模块的安全接收准则；根据项目进展适当更新系统安全计划；深入进行风险源识别以及安全性分析；通过理论分析、会议回顾、测试（软件

12、模块测试、硬件模块测试和集成测试）和验证手段系统或子系统设计与实现能够满足安全需求；对安全管理进行过程控制，管理；准备安全例证。阶段5系统确认：根据子系统测试报告、系统测试报告，以及系统各个阶段的验证报告，确认系统中所采用的风险控制或缓解措施能够符合安全需求，并形成确认报告阶段6系统安全接收：此阶段接受独立的三方对产品进行安全评估。下图使用V形表示法对安全生命周期六个阶段以及不同阶段之间的验证/确认关系进行表示。图 3 安全生命周期不同阶段之间的确认关系安全系统生命周期的设计和确认过程可看成为一个“自顶向下”阶段并伴随一个“自底向上”阶段。为了保证安全管理过程的有效执行，必须建立符合欧标要求的

13、安全组织，由有能力的人员，按照预定的角色要求，对安全活动进行控制。同时，为了符合相应的安全完整性等级，欧标对不同角色之间的独立性存在明确的要求。比如对于SIL3和SIL4，设计人员、验证人员与确认人员必须满足下图所示的独立性1。(a)(b)图 4 满足SIL3或SIL4的角色独立性关系图中，使用点划线区分不同组织，即评估人员与其它人员必须属于不同的组织；使用实线表示不同的人。可以看出，验证与确认人员必须满足与设计人员的独立性。在项目开发实践中，我们采用了符合图 4(a)的安全组织。3. 项目安全管理实践在某铁路安全信号平台的研究开发过程中，为了使产品能够满足SIL4的要求，需要相关技术安全手段

14、并结合安全管理和质量管理手段才能实现。而安全管理过程必须符合一定的流程，安全管理人员必须遵照相关的安全管理规定，对项目安全生命周期中各个阶段进行有效管理。下面对平台开发过程中的安全管理的实践经验进行总结。3.1 安全计划在安全管理过程中，首先要制定安全计划。安全计划不仅包括目标，而且包括实现这个目标需要采取的措施；计划制定之后，要按照计划使用检查表的方式对各个活动进行检查，看是否实现了预期效果并达到了预期目标；通过检查找出问题和原因，并及时进行处理。在安全计划的执行过程中，应该在安全生命周期每个阶段结束后进行安全计划的评审，以确保安全计划得以有效执行。同时在执行过程中，会根据具体执行情况对计划

15、进行修改，而为了保证计划修改的可行性，需要对修改后的安全计划重新进行评审。3.2 系统安全需求规范系统的安全需求规范主要包括安全功能和安全完整性要求，这些内容可以通过风险分析过程得到，并被单独记录在系统安全需求规范中。根据不同的安全完整性等级，所需的安全需求规范内容各不相同。对于某铁路安全信号平台，为使系统安全需求规范制定阶段达到SIL4的要求，应该在流程上注意下面几点：a) 为了明确平台中不同子系统的安全特性，确定后续安全分析对象，应区分安全相关子系统和非安全相关子系统，定义它们之间的接口，并对这些接口进行分析。b) 在项目中，分别对平台、子系统和模块这三个层次提出了相应的安全需求。为了保证

16、不同层次的功能需求和安全需求具有可追溯性和一致性，使用了需求管理工具和需求对照表，分别利用自动化的方法和人工方法对需求规格进行检查。c) 在系统需求规格定义过程中，由于涉及到用户、设计者等多方面人员，因此需要一种简单明确、无二义性且容易被大家接受的描述方法对不同群体的意图进行准确表达。半形式化描述语言UML可以很好的表达不同行业、不同背景人员的意图，使用UML可以极大地减少由于信息误读或行业限制造成的沟通困难，较好的完成平台需求规格的定义。d) 风险日志在项目的初期即被建立，在整个项目生命周期中进行了更新和维护。风险日志的内容包括风险源标识、风险源描述、初步分析得到的产生风险源的原因及风险源导

17、致的结果、风险源的风险指数、风险源状态、风险源负责人等内容。e) 在需求规范的编写过程中，始终贯彻SMART（Specific, Measurable, Achievable, Realistic, Testable）原则，即具体的、可测量、可完成、现实的、可测试的。SMART原则的遵循，可以有效提高需求规范的可读性、可追溯性和可实现性。f) 在系统功能需求和安全需求规范定义完成后，为了保证需求规格能够正确、完整的反映各方面的要求，通过会议评审的方式对需求规格进行了检查与审查。3.3 安全组织安全管理系统必须在一个适当的安全组织控制之下，由有能力的人员按照规定的角色来执行。为保证安全组织中各类

18、人员能够有足够能力从事相关的工作，在项目实施过程中，需要在所有安全相关活动中进行重复或定期的培训；同时动态对所有人员进行人员能力的考核与评价，确保所有人员具有较高的技术教育程度或丰富的经验，并对不合格的人员进行特殊培训或更换。安全组织采用如图 4(a)所示的组织形式。如图可知，虽然设计人员与验证/确认人员均处于同一组织，但存在管理上的独立性，即验证/确认人员在管理体制上完全不受设计人员或项目负责人的控制，可以独立进行相应的工作，得出独立的结论，并就安全管理存在的问题直接向上级管理机关反应；评估人员与其他项目相关人员不能任职于同一组织，以进行独立的第三方安全评估。3.4 系统设计与开发这一阶段需

19、要通过采用一种自顶向下、结构化的设计方法实现系统特定的功能与安全需求，并通过对各种设计文档的严格控制和评审，确保设计能够满足功能和安全需求的要求。在平台结构设计过程中，使用自顶而下的分层设计方法，尽量采用模块法设计理念，在保证所有设计均能完全追溯到需求规格的同时，尽量使用完全经过确认的、易于理解的且大小受限制的模块，并确保模块之间的功能隔离。在软件设计以及软硬件集成过程中安全管理的相关内容可以参见文档4。为使平台能够具有较好的抗外部干扰能力，在设计与开发过程中，还需要对诸如EMC、振动等外部干扰进行相关研究和处理。3.5 系统验证与确认在平台安全计划中，还包括了对生命周期各阶段满足前阶段确定的

20、具体安全要求的验证计划，以及对整个系统满足安全需求规格的确认计划。在图 3中，虚线所示的就是设计实现阶段的各种验证活动。下面给出不同安全生命周期的验证活动：a) 系统需求定义阶段：用户、项目主管部门对平台需求与定义文档进行审核。b) 系统风险分析阶段：对平台工作状态和功能的UML状态图和时序图描述进行审核，确认其描述的充足性和准确性；验证对风险源日志，原因分析，结果分析，以及风险分析报告等文档进行验证。c) 系统规范阶段：对平台需求规格书、安全需求规格书、验收规格书等进行了验证。d) 设计实现阶段：首先对平台结构设计进行验证；然后对平台各个子系统中不同软/硬件模块的软/硬件设计方案进行验证；并

21、对涉及到安全需求实现的软/硬设计进行专家评审；接着依据相应层次的设计规格，通过软件单元测试、软件集成测试、硬件模块测试、子系统软/硬件集成测试、系统集成测试等，对系统设计实现进行验证，确保所有功能和性能需求规格均得到有效实现；通过测试和分析验证方法，对每个安全需求的实现进行验证，确保所有安全需求规格得到有效实现；采用FMEA方法，验证硬件的故障模式可以满足系统安全需求。在安全生命周期的第五阶段，即系统确认阶段，根据测试报告、RAM报告及安全验证报告，证实所开发的平台满足原始的用户需求。以上这些验证与确认过程均需要通过相关级别的审批，并产生验证或确认报告。当出现对平台的修改或变更时，相应的验证过程需要重新进行。3.6 安全回顾安全回顾可以在安全生命周期中合适的阶段及项目安全管理者认为必要的时间进行。在平台开发过程中，在每个安全生命周期结束时，均进行了安全回顾。考虑到风险分析阶段在系统设计实现过程中也要不断循环进行，因此对该阶段根据阶段性成果进行了数次安全回顾。安全回顾一般采用安