欧洲铁路标准前言中文版EN50128.docx
《欧洲铁路标准前言中文版EN50128.docx》由会员分享，可在线阅读，更多相关《欧洲铁路标准前言中文版EN50128.docx（109页珍藏版）》请在冰豆网上搜索。
欧洲铁路标准前言中文版EN50128
绪论
该欧洲标准应和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）如果要达到很高的可靠性，那么就有可能在出错计算机被识别出来后，让（可能）无故障的计算机在没有任何冗余的情况下连续工作。
上例表明在安全性和可能性之间可能进行权衡。
实际上，在设计过程中还要考虑其它的一些权衡，同时还要考虑成本对其它系统性能的影响，如可用性、可维护性及保险性。
本欧洲标准的范围不包括对这些权衡的指导。
注意：
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软件完善度等级是为了在失效可引起包括失去生命在内的后果的系统中使用。
使用较高的软件完善度完整型等级为好。
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定义不同）
故障避让在系统设计和构造过程中为避免故障的引入而使用的设计技术。
容错
保障连续正确运行的系统内在能力，即在出现有限个硬件或软件故障时提供的特殊服务。
一般软件
一般软件，即用于安装特殊数据的软件。
执行者
由设计机构认定的一个或多个个人，他们将特定的设计转变为物理实体。
可维护性
在给定条件下保持或恢复到执行需求功能状态的能力。
可编程逻辑控制器（PLC）
一种固态控制系统，它具有一个存储执行特殊功能代码的用户可编程存储器。
可靠性
在一定时间内系统在规定条件下执行需求规格说明中所描述功能的可能性。
风险
频度或概率与特定危害性事件后果的组合。
风险的概念通常包括两个元素：
危害发生的频度或概率，以及危害性事件的后果。
安全性机构
负责证明安全性系统能胜任服务并遵守所有法规要求的团体。
安全性
系统在规定条件下不导致出现人类生命、躯体完整、健康或环境遭受危险的状态的期望值。
安全软件
证明系统不危及人类生命、躯体完整、健康、大家经济损失、重要设备的环境和控制软件。
软件
由程序、规程、规则和所有与数据处理的操作有关的文档组成的智力性创造。
（参见ISO规则ISO/23821/1；第二版；1984-10-1）
注：
软件独立于传递媒体。
软件生存周期
从设想软件开始到软件失效为止的一段时间。
典型的软件生存周期包括需求阶段、开发阶段、测试阶段、集成阶段安装阶段和维护阶段。
软件完善度等级
在规定的时间和条件下，可编程电子系统完成其安全性功能的似然。
测试人员
由设计机构认定的一个或多个个人。
他们指定并执行确保设计的物理实体是正确的，并且是满足所有规定的测试和验收准则所必需的测试。
确认
确保符合安全性、功能、性能和接口要求的整分软件系统的测试。
确认人员
由安全人员认定的人或任何生命的代理人，以确保安全系统在开发过程中要求遵守的所有标准和规程已被遵守以及规定的功能和安全性完善度已被满足。
验证
决定软件生存周期开发过程的每一个阶段的产品是否完成前面阶段指定的所有要求的过程。
验证包括测试、检查和审计。
验证人员
由设计机构认定的一个或多个个人，以确保在每个阶段呈现的系统被较好地设计，被合理构造，没有不可接受的差错或缺陷，符合所有指定的要求和规程，具有可接受的质量和可靠性。
5目标一致性
5.1在以下每个条款中，将详细地描述其目的和要求。
5.2位与欧洲标准一致，必须指出，每一项要求已满足规定的等级，因而他们也满足条款的目标/
5.3如果一个要求附有“在软件完善度等级要求的范围内”的词句，则表示可用技术措施来满足条款的目标。
5.4在条款5.3适用的地方，应使用本欧洲标准详细给出的表格来帮助选择与软件完善度等级相对应的技术和措施。
5.5如果某一技术或措施在表格中被列为优先推荐，那么不使用该技术的理由应在软件质量保证计划或软件体系结构说明书中作详细说明并作相应纪录。
5.6如果一项不包括在表格中的技术或措施被建议使用，那么应对其有效期及能满足特殊要求和条款整个目标的性能作证明，并在软件质量保证计划或软件体系结构说明书中作相应的纪录。
5.7通过检查本标准所要求的和测试证据所要求的文档来评估是否符合特殊条款的要求和表格中详细列出的他们各自得技术和措施。
5.8本欧洲标准需要使用一组技术及他们的正确应用。
这些技术是表格中所要求的，并在文献目录中详细列出。
但是，本欧洲标准推荐的技术措施并不能保证要求的软件完善度等级能被达到。
6软件完善度等级
6.1.1该条款的目的是给软件分软件完善度等级。
6.2要求
6.2.1应产生一个系统安全性需求规格说明书，其中包括：
安全性功能；
系统的配置或体系结构；
硬件可靠性要求；
安全性完善度要求；
容量和向对应时间性能；
设备和操纵者接口；
任何其它功能及其属性；
系统安全性需求规格说明书的开发应按EN50126的要求来完成。
软件完善度等级应按EN50126的要求来指定。
6.2.2应在与系统中使软件有关的风险等级的基础上决定所要求的软件完善度等级。
6.2.3被考虑的风险是指与下列危后果有关的风险
失去人的生命；
使人受伤；
环境的污染；
财产损失或损坏；
6.2.4风险可被指定为一个定量的可能性或一组定量的可能性，但是不能以同样的方式指定软件的完善度，因此，对于本欧洲标准，软件完善度等级将被指定为下列五个等之一：
软件完善度的软件完善度等级描述：
4极高
3高
2中等
1低
0非安全性
6.2.5在软件需求规格说明书中应指定软件的完善度等级（条款9）
7人员与职责
7.1目标
7.1.1该条款的目标是保证所有对软件负有责任的人员有能力履行那些职责。
7.2要求
7.2.1作为最低限度，供应者或开发者，以及购买者都应执行EN29001的相关部分，这与EN29000-3：
1993中的方针是一致的，两者都是强制性的。
7.2.2除软件完善度等级0以外，安全性过程应当在一个适当的安全性组织的控制下完成。
该组织应依从EN50129“安全管理的依据”条款的“安全性机构”子条款。
以及EN50126——2“安全性过程”条款的“安全性机构”子条款。
7.2.3所有设计、开发、评估、安装、维护或管理软件的人员应具有适当的培训、经验和资格。
7.2.4对于除软件完善度等级0以外的特殊情况应用，极力建议对设计、开发、评估、安装、维护或管理的所有人员的培训、经验、资格进行证明。
7.2.5上面条款中包含证明应被纪录在软件质量保证计划中，并相应地包括能胜任下列领域工作的证据：
i）适合应用领域的工程；
ii）软件工程；
iii）计算机系统工程；
iv）安全性工程；
v）法规框架。
7.2..6指定软件评估员。
7.2.7应赋予评估人员足够的权力来实现对软件的评估。
7.3.8根据图5，无论是开发还是维护，所包含的各部分是独立的。
8生存周期专辑和文档
8.1目标
8.1.1该条款的一个目标是将软件的开发构造成特定的阶段和活动。
8.1.2该条款的另一个目标是纪录贯穿于整个软件生存周期的软件相关的所有信息。
8.2要求
8.2.1选择软件开发的生存周期模型，根据欧洲标准条款16，它将在软件质量保证计划中加以详细说明。
图3和图4示出了生存周期模型的例子。
8.2.2质量保证规程将与生存周期活动一起运行。
8.2.3所有在某一阶段中要被执行的活动应在该阶段开始之前被定义好。
软件生存周期的一阶段应被分为具有非常确定的输入、输出及其基本活动的基本任务。
8.2.4软件质量保证计划应当描述出那些验证步骤和报告是要求的。
8.2.5所有文档应构造能随着设计过程一起不断扩展。
8.2.6每一文档具有一个唯一的参考和一个确定的、与其它文档之间的文档关系，这种文档提供了文档的跟踪能力。
此外，每一个文档应按下列规则书写：
a）应包括或执行所有前续文档的可应用条件和要求，使文档具有层次关系；
b）不能与前续文档有抵触；
c）在每一个文档中，每一个术语，首字母缩略词或缩写应具有相同的意义；
d）在每一个文档中，每一项目或概念应该用相同的名称或描述。
8.2.7所有文档内容应以适合于操作、处理和存储的形式来计录。
8.2.8根据软件完善度等级的要求，应产生下列文档：
阶段文档
系统开发的初始阶段系统需求书
系统安全性需求规格说明书
系统体系结构描述
软件规则软件安全性计划
软件配置
管理计划软件开发计划
软件质量保证计划
软件确认计划
软件验证计划
软件维护计划
软件/硬件集成计划
软件要求软件需求规格说明书
软件需求测试规格说明书
软件需求验证报告
软件设计软件体系结构规格说明书
软件集成计划
软件设计规格说明书
软件设计测试说明书
软件设计验证报告
软件模块设计软件模块设计规格说明书
软件模块测试规格说明书
软件模块验证报告
编码软件源代码和支持文档
软件源代码验证报告
模块测试软件模块测试报告
软件集成软件集成报告
软件/硬件集成软件/硬件集成报告
软件确认软件确认报告
软件评估软件评估报告
软件维护软件维护报告
8.2.9根据开发软件的规模，复杂性和生存周期，要求产生的各类文件数目有所不同。
对于规模较小的项目，一些文件可以组合在一起（在这一过程中应不丢失所有的细节）。
而对于大规模的项目，必须将文档（以分类名排列）分成一些便管理的子文件。
由独立的组成或有全体统一产生的文档不能被组合成一个单一的文档。
９ 软件需求规格说明书
9.1目标
9.1.1该条款的目标是描述一个文件，该文件定义了一整套满足所有系统得软件需求。
它是一个适用于每一个软件工程师的综合性文档。
它便于软件工程师了解任何其它文件中的需求。
9.2输入文档
1）系统需求规格说明书
2）系统安全性需求规格说明书
3）系统体系结构描述
4）软件质量保证计划
9.3输出文档
1）软件需求规格说明书
2）软件需求测试规格说明书
9.4要求
9.4.1在产生软件需求规格说明书时，应考虑如下文档：
——系统需求规格说明书
——系统安全性需求规格说明书
——系统体系结构描述
——软件质量保证计划
9.4.2软件需求规格说明书应能描述出开发软件的需求特性，而不是开发软件的规程。
这些特征应包括：
——功能（包括容量和影响时间性能）
——可靠性（在ISO/IEC9126中定义）
——可维护性
——可用性
——安全性（包括安全性功能及其与软件完善度等级同的关系）
软件完善度等级将派生出条款６中的定义，并纪录在软件需求规格说明书中。
9.4.3根据软件完善度等级的要求，软件要求规格说明书应以如下方式来描述和构造：
清楚，精确、不含糊、可验证，可测试的，可维护的和可行的方式。
9.4.4软件需求规格说明书应使用让整个系统的生存周期中负有责任的人员都能理解的表达和描述方法。
9.4.5软件需求规格说明书应识别和描述出所有任何与其它系统间，以及控制设备的内部或外部间的接口，包括对操作员的接口，以及已存在或计划中的直接连接接口。
9.4.6软件需求规格说明书应详细描述所有相关的操作方式。
9.4.7软件需求规格说明书中应详述可编程电子器件所有相关的行为方式，尤其是失效行为。
9.4.8软件需求规格说明书中应识别并描述出软件和硬件之间的任何约束。
9.4.9软件需求规格说明书中应表示出软件自检的程度以及由软件检测硬件的程度。
软件之间程度包括软件自身失效和差错的检测和报告。
9.4.11软件需求规格说明书所包括的要求在系统需求规格说需要规定的在整个系统运作过程中可测试的所有安全性功能的需求。
9.4.12当要求软件来完成那些与实现所要求的系统完善度等级有关的功能时，软件需求规格说明书应对其加以说明。
9.4.13当要求软件完成非安全性功能时，软件需求规格说明书应对其加以清楚地说明。
9.4.14软件需求测试规格说明书应与软件需求规格说明书同时开发，软件测试规格说明书被用来验证软件需求规格说明书中所描述的功能要求，同时也作为对已完成软件进行测试的描述。
9.4.15对需求的可追溯性，在安全系统得确认过程中应作为一个重要内容加以考虑。
在本标准中，对应特定的软件完善度等级，可追溯性特指：
i）对设计完成需求而进行的其他目标的需求的可追溯性。
ii）对使设计目标实例化的执行目标的设计目标的可追溯性。
需求可追溯性的目标是证实所有的需求已被满足，并已说明没有那些对系统的安全或完善度有影响的不可追溯的材料。
可追溯性过程的输出属于正式配置管理的问题。
10软件体系结构
10.1目标
10.1.1该条款的另一个目标之一是开发一个软件体系结构，它完成与要求的软件完善度等级相对应的软件需求规格说明书的需求。
10.1.2该条款的另一个目标是检查有系统结构安排在软件中的需求。
10.1.3该条款的第三个目标是识别和评估以安全性为目的的硬件/软件协调的有效性。
10.1.4该条款的第四个目标是为完善度测试做准备。
10.2输入文档
1）软件需求规格说明书
2）软件安全性需求规格说明书
3）软件质量保证计划
10.3输出文档
1）软件体系结构规格说明书
2）软件集成计划
10.4要求
10.4.1由软件提供者和/或开发者来建立建议性的软件体系结构，并在软件体系结构规格说明书中作详述。
10.4.2软件体系结构规格说明书应考虑实现以要求的软件完善度等级为前提的软件需求规格说明书的可行性。
10.4.3软件体系结构规格说明书应能识别、评估和评述所有硬件/软件协调的有效性。
10.4.4软件体系结构规格说明书应能识别所有软件的成分，并对这些成分进行识别：
i）这些成分是否是新的，现存的或专用的；
ii）这些成分以前是否已被确认。
如果是，它们的确认条件是什么；
iii）每一成分是否是安全的或是非安全的。
,,,,,
10.4.5使用标准软件应服从以下限制：
i）对于软件完善度等级0，不需要进一步的预防措施即可使用标准软件；
ii）如果标准软件使用于软件完善度等级1或2，则它应经历软件确认过程；
iv）如果标准软件使用于软件完善度等级3或4，则应采取以下预防措施：
a）标准软件应经历软件确认过程；
b）应进行可能性失效分析；
c）应确定一个策略来检测标准软件的失效并保护系统避让这些失效；
d）保护策略应经过确认测试；
e）应评估提供者的差错纪录；
f）就实用性而言，仅使用标准软件的简单功能。
10.4.6如果以前开发的软件将作为设计部分被使用，那么应有清楚的标识。
应产生一个证明软件的适应性已满足软件需求规格说明书和软件完善度等级要求的单独报告。
合适的软件是根据本标准开发的软件。
必须特别注意任何软件变化对系统剩余部分的影响，它将决定是否需要再审查和再评估。
例如，如不再对所有模块进
升级会员 