欧洲铁路标准前言(中文版EN50128)

1绪论该欧洲标准应和EN50126——2：“铁路应用——引导运输系统可信性——第二部分：安全性”，以及EN50129：“铁路应用——安全电子铁路控制和防护系统”一起阅读。欧洲标准的关键概念是软件完善度等级。软件完善度等级越高，由软件规格说明或由设计缺陷所引起的系统危险失效和可能性就越小。欧洲标准建立了为软件完善度的5个相应的技术和措施，其中0等级最低，4等级最高。等级1到4标征安全软件，而等级0标征非安全软件。将0等级也包括在其中的目的是为了实现非安全性软件开发和安全软件开发之间的平稳过渡，表中列出了完善度等级所要求的技术和措施。在这一版中，等级1和等级2相同，等级3和等级4所要求的技术相同，对于某一给定的危险哪一软件完善度用于它，欧洲标准没有加以指明。这将取决于多种原因，包括应用特征、其它系统实现安全性功能的限度、以及社会和经济因素。EN50126——2：“铁路应用——引导运输系统可信性——第二部分：安全性”，以及EN50129：“铁路应用——安全电子铁路控制和防护系统”的作用就是详细说明分配给软件的安全性功能以及软件所要求的完善度等级。欧洲标准详细解释了要达到这些要求所必需的措施。EN50126——2：“铁路应用——引导运输系统可信性——第二部分：安全性”和EN50129：“铁路应用——安全电子铁路控制和防护系统”要求将系统化的方法用于：i)确定危险、风险和风险准则；ii)确定为满足风险准则所必须进行的风险缩减；iii)为满足风险准则必需的安全监护定义整个系统的安全性需求规格说明；iv)选择一个合适的系统结构；v)规划、监督和控制那些把系统安全性要求规格说明转换为具有确认的安全性（或安全性完善度）的安全系统所需的技术方面和管理方面的活动。在EN50126——2：“铁路应用——安全电子电路控制和防护系统”中，为满足所要求的风险准则必须进行的风险缩减将被指定为上述五个软件完善度等级之一，并示于图1中。风险率是在对危害事件的后果（或严重程度）和频率进行评估的基础上而获得的。图1也指明了如何将规格说明分解为一个构造安全系统的设计，以及元器件如何实现安全性完善度等级的进一步分配。最后就导出了所要求的软件完善度等级，它同功能要求一起作为本标准所述活动的出发点。从表面上看，一个运行的可靠系统可以被自动地假定为是一个安全系统，但详细分析后表明，必要的时候，仅仅有高可靠性还不足保证安全性。可靠性是面向系统目标、预期作用（服务），以及系统所希望执行的特定任务范围的。可靠性要求研究服务的连续提供能力。安全性研究可能事件的起因、后果，以及导致产生非所希望输出的顺序关系。安全性要求研究如何制作一个不会引发事故的系统。安全性要求将确保系统不会进入危险或不安全的状态，而在该状态，某一事件可能会引发事故。从安全性角度看，系统是否按要求去工作不是十分紧要的，只要它不违背安全性要求就行。从另一方面讲，非常可靠的系统也有可能是不安全的。考虑一个用两台计算机按动态冗余方式构成的故障安全系统。两台计算机的输出相互比较以检测其中之一可能出现的失效。这一失效出现之后……。i)如果要求高安全性，两台计算机都需停机，并且进程也要求被导入一个安全的停止返回状态。由于没有什么办法能确定是哪台计算机出错，所以系统不能提供进一步的服务。即使有很高的概率识别出出错的计算机，但要检测进一步的错误输出没有冗余是不可能做到的。ii)如果要达到很高的可靠性，那么就有可能在出错计算机被识别出来后，让（可能）无故障的计算机在没有任何冗余的情况下连续工作。上例表明在安全性和可能性之间可能进行权衡。实际上，在设计过程中还要考虑其它的一些权衡，同时还要考虑成本对其它系统性能的影响，如可用性、可维护性及保险性。本欧洲标准的范围不包括对这些2权衡的指导。注意：IECTC56WGI中已建议将这一系统性能集合：可靠性、可用性、可维护性、安全性和保险性统一用一个术语来概括“可信性”。软件本身有可靠性，即在给定输入后得到预期结果的能力。而对软件安全性，则有必要统观整个系统，必须要注意软件在特殊运用中的上下联系。如果对一个错误的排序算法不存在引起危险的可能性，那么谈论排序用安全软件是毫无意义的。在现行技术条件下，无论是质量保证方法（所谓预防措施）的应用还是软件冗错方法的应用均不能保证系统的绝对安全性。现有方法无法证明在适当复杂的安全性软件中不存在错误，尤其是规格说明和设计中的错误。开发高完善度软件等级软件的原则包括，但并不局限于以下几点：——自上而下的设计方式；——模块化；——开发生命周期的每一阶段的验证；——验证模块和模块库。……本标准中不同的软件完善度等级要求有不同的保证等级，以使这些原则及其相关的其它原则被正确地运用。1欧洲标准的应用在确定分配给软件的所有安全性功能及决定完善度等级的系统安全性要求规格说明生成之后，这一欧洲标准应用的功能步骤如图2所示，它们是：i)在定义软件要求规格说明的同时考虑软件体系结构。软件体系结构是用于开发软件基本安全策略的。（第9条和第10条）ii)根据软件质量保证方案、软件完善度等级和软件生命周期来设计、开发和测试软件。（第11条）iii)集成软件和目标硬件。（第13条）iv)确认软件。（第14条）v)将被确认软件和软件确认报告移交给系统工程师以便进一步集成进整个系统。（第14条）vi)如果在运行过程中要求维护软件，那么可再适当运用在欧洲标准进行处理。（第17条）许多活动都是同软件开发交叉进行的。其中包括验证（第12条），评估（第15条）和质量保证（第16条）。对从事软件开发人员的能力要求也有相应的要求。（第7条）本标准不硬性要求使用特殊的软件开发生命周期，但是给出了一个推荐的生命周期及相应文档。表格对照五个软件完善度等级系统地排列出各种技术措施。所有表格均放在附件A中。对该表的交叉引证可得一个文献目录，它对每一技术措施均作出了简要描述，并附有进一步参考的信息资源。文献目录在在附件B中。附件A是规范的，附件B供参考用。……2.范围2.1欧洲技术标准指定了用于铁路控制和防护设备的可编程电子系统的开发所需的规程和技术要求。它适用于任何有无安全性隐含项的这样的领域，从非常关键的，如安全性信号，到关键的，如管理信息系统。这些系统可由专用的微处理器，可编程的逻辑控制器。多处理器分布式系统，大规模中央处理机系统以及其它体系结构来实现。2.2欧洲标准可专门应用于软件以及软件和“宽系统”之间的相互作用。2.3软件完善度等级是为了在失效可引起包括失去生命在内的后果的系统中使用。使用较高的软件完3善度完整型等级为好。2.4欧洲标准适用于铁路控制和防护系统开发和实现的所有软件包括：应用程序设计、操作系统、支持工具、固件。应用程序设计包括高级程序设计，低级程序设计和专用目的的程序设计（如：可编程，逻辑控制器梯形逻辑和计算机数控部分的程序设计）。2.5欧洲标准对标准，商用软件和工具提出了建设的使用。2.6欧洲标准还对由应用数据配置的系统提出了要求。2.7欧洲标准并不想涉及商务问题，这些问题应为合同的基本部分被提出。但欧洲标准中的所有条款在任何商务活动中应被仔细考虑。2.8欧洲标准为避免追溯，所以主要应用于新的开发和全面适用于那些主要修改的现存系统。对于软件完善度3或4，在开始变动之前，合同的全面型将决定是否将维护行为考虑为主要的还是次要的。对软件完善度等级0，1，2由供应商来作出相同的决定。对于主要修改，欧洲标准将被全面使用。对于次要修改，欧洲标准仅适用小量部分。3参考文献3.1标准参考文献以参考文献的方式欧洲标准包含了下列标准条款。以出版时的版本号为准。所有标准都可能被被修订，所以以本欧洲标准为基础的合同双方应注意引用了下列标准。可能性，IEC和ISO的成员都保留着目前最新国际标准为记录。EN29001：1987质量统一设计、开发、生产、安装和服务过程中的质量保证模块。EN29000-3：1993质量管理和质量保证标准，第三部分——将EN29001应用于软件开发、销售和维护的指南。EN50126-2：铁路应用——引用运输系统可信型——第二部分：安全性。EN50129：铁路应用——安全电子铁路控制与防护系统。3.2供参考的文献ISO/IEC9126：1991信息技术——软件产品评估——质量特性及其使用方针。IEC50（191）：1990国际电子技术词汇（191章，服务的可信性和质量）4定义本欧洲标准应用如下定义。评估员指由安全性权威机构认定的人员和制定代理。安全性权威机构对设计机构和评估员的工作进行评价。目的是对系统的目标和安全性完善度的适应性进行评估。设计机构负责对安全性需求规格设计结果的说明和监督，在预定环境下的系统的开发和开展工作。设计者由设计机构认定的一个或多个个人，他（们）分析将特定的需求转变为具有所要求的安全性完善度的可接受的设计结果。差错由于系统错误而引起的失效：差错即为易于导致失效的系统状态部分。简单地讲，差错也就是距被认可的需求规格说明书的测量偏差。（与IEV不同）。失效当已交付的服务偏离规格说明的服务时，系统发生了失效，这里规格说明书是一分期望的，已被认可的详细说明。简言之，失效即为系统或软件差错的表现。（与IEV定义不同）故障避让在系统设计和构造过程中为避免故障的引入而使用的设计技术。容错4保障连续正确运行的系统内在能力，即在出现有限个硬件或软件故障时提供的特殊服务。一般软件一般软件，即用于安装特殊数据的软件。执行者由设计机构认定的一个或多个个人，他们将特定的设计转变为物理实体。可维护性在给定条件下保持或恢复到执行需求功能状态的能力。可编程逻辑控制器（PLC）一种固态控制系统，它具有一个存储执行特殊功能代码的用户可编程存储器。可靠性在一定时间内系统在规定条件下执行需求规格说明中所描述功能的可能性。风险频度或概率与特定危害性事件后果的组合。风险的概念通常包括两个元素：危害发生的频度或概率，以及危害性事件的后果。安全性机构负责证明安全性系统能胜任服务并遵守所有法规要求的团体。安全性系统在规定条件下不导致出现人类生命、躯体完整、健康或环境遭受危险的状态的期望值。安全软件证明系统不危及人类生命、躯体完整、健康、大家经济损失、重要设备的环境和控制软件。软件由程序、规程、规则和所有与数据处理的操作有关的文档组成的智力性创造。（参见ISO规则ISO/23821/1；第二版；1984-10-1）注：软件独立于传递媒体。软件生存周期从设想软件开始到软件失效为止的一段时间。典型的软件生存周期包括需求阶段、开发阶段、测试阶段、集成阶段安装阶段和维护阶段。软件完善度等级在规定的时间和条件下，可编程电子系统完成其安全性功能的似然。测试人员由设计机构认定的一个或多个个人。他们指定并执行确保设计的物理实体是正确的，并且是满足所有规定的测试和验收准则所必需的测试。确认确保符合安全性、功能、性能和接口要求的整分软件系统的测试。确认人员由安全人员认定的人或任何生命的代理人，以确保安全系统在开发过程中要求遵守的所有标准和规程已被遵守以及规定的功能和安全性完善度已被满足。验证决定软件生存周期开发过程的每一个阶段的产品是否完成前面阶段指定的所有要求的过程。验证包括测试、检查和审计。验证人员由设计机构认定的一个或多个个人，以确保在每个阶段呈现的系统被较好地设计，被合理构造，没有不可接受的差错或缺陷，符合所有指定的要求和规程，具有可接受的质量和可靠性。5目标一致性55.1在以下每个条款中，将详细地描述其目的和要求。5.2位与欧洲标准一致，必须指出，每一项要求已满足规定的等级，因而他们也满足条款的目标/5.3如果一个要求附有“在软件完善度等级要求的范围内”的词句，则表示可用技术措施来满足条款的目标。5.4在条款5.3适用的地方，应使用本欧洲标准详细给出的表格来帮助选择与软件完善度等级相对应的技术和措施。5.5如果某一技术或措施在表格中被列为优先推荐，那么不使用该技术的理由应在软件质量保证计划或软件体系结构说明书中作详细说明并作相应纪录。5.6如果一项不包括在表格中的技术或措施被建议使用，那么应对其有效期及能满足特