同济大学、铁道科学研究院标准所 EN50128：2001

EN 50128 : 2001

铁路应用——通信、信号和处理系统——铁路

控制和防护系统软件

2007.6

1

同济大学、铁道科学研究院标准所 EN50128：2001

序言

本欧洲标准是SC 9XA,即通信，信号传输和处理系统技术委员会（CENELEC TC 9X）制订，铁路电气和电子应用的标准。草案文本作为EN 50128正式提交投票并于2000-11-01获得CENELEC批准。 修改了下列日期

--欧盟各国必须通过认可或发布相同的国家标准来执行本欧洲标准的截止日期 2001 -1 1-01 --与本欧洲标准冲突的国家标准必须被废止的截止日期 2003-1 1-01

本欧洲标准必须与EN50126铁路应用——可靠性，可用性，可维护性和安全性（RAMS）；EN50129铁路应用——信号领域的安全相关电子系统同时阅读。

附件中指定的“规范性的”是本项标准主体的一部分。 附件中指定的“参考性的”只用于获得的信息。 本项标准中，附件A是规范性的而附件B是参考性的。

I

同济大学、铁道科学研究院标准所 EN50128：2001

目录

引言 1. 范围 2. 参考文献 3. 定义 4. 目标和符合 5.

软件安全完整性等级

5．1目标 5．2需求 6.

人员及职责

6．1目标 6．2需求 7.

生命周期和文档

7．1目标 7．2需求 8.

软件需求规格说明

8．1目标 8．2输入文档 8．3输出文档 8．4需求 9.

软件体系结构

9．1目标 9．2输入文档 9．3输出文档 9．4需求

10. 软件设计和实现 10．1目标 10．2输入文档

II

同济大学、铁道科学研究院标准所 EN50128：2001

10．3输出文档 10．4需求

11. 软件验证和测试 11．1目标 11．2输入文档 11．3输出文档 11．4需求

12. 软件/硬件集成 12．1目标 12．2输入文档 12．3输出文档 12．4需求 13. 软件确认 13．1目标 13．2输入文档 13．3输出文档 13．4需求 14. 软件评估 14．1目标 14．2输入文档 14．3输出文档 14．4需求 15. 软件质量保障 15．1目标 15．2输入文档 15．3输出文档 15．4需求 16. 软件维护 16．1目标 16．2输入文档

III

同济大学、铁道科学研究院标准所 EN50128：2001

16．3输出文档 16．4需求

17. 根据应用数据配置的系统 17．1目标 17．2输入文档 17．3输出文档 17．4需求

17．4．1数据准备生命周期 17．4．2数据准备程序和工具 17．4．3软件开发

附件A：技术和措施的选择准则 附件B：技术参考书目 附图

图1——安全相关系统的完整性等级 图2——软件安全性路径图 图3——开发生命周期1 图4——开发生命周期2

图5——独立性与软件完整性等级

图6——通用系统开发和应用开发之间的关系

IV

同济大学、铁道科学研究院标准所 EN50128：2001

引言

本标准是相关标准系列中的一部分。其他标准有EN50126铁路应用——可靠性，可用性，可维护性和安全性（RAMS）；EN50129铁路应用——信号领域的安全相关电子系统。EN50126适用于大范围的系统问题，而EN50129适用于整个铁路控制和防护系统中某单个系统的批准过程。本标准关注于需要使用的方法，以使软件能满足经全面考虑后所分配到的安全完整性要求。

本标准从IEC/TC65第九工作组（WG9）早期工作中得到很多指导。WG9的工作形成了一个安全系统软件通用标准，现在该标准是IEC61508的一部分。WG9工作的特别之处是包含了适用于非安全软件的软件安全完整性0级，以及适用于安全相关和安全苛求软件的软件安全完整性1~4级。本标准也覆盖了所有五个软件安全完整性等级。

国际铁路信号工程师协会（IRSE）的工作也被考虑进来，特别是它关注相同课题的1号技术报告。

本欧洲标准的一个关键概念是软件安全完整性等级。软件失效后果的危险性的越大，软件安全完整性等级也就越高。

本欧洲标准确定了从最低0级到最高4级的5个软件安全完整性等级的技术和措施。其中1~4这四个级别涉及安全相关软件，0级涉及非安全相关软件。对0级进行标准化是为了让非安全相关系统软件向安全相关系统软件进行平滑转变。附表给出了各个软件安全完整性等级和非安全相关等级要求的技术和措施。在这个版本中，1级和2级的技术要求相同，3级和4级的要求相同。本欧洲标准没有给出某一风险应适用于哪个软件安全完整性等级的具体指导意见。这个结论需要考虑许多因素包括应用的特性、其他系统承担的安全性功能范围和社会以及经济因素。

EN 50126 和EN 50129规定了分配给软件的安全性功能。

本欧洲标准规定了满足这些需求的必要措施。这个过程在图1作了说明。 EN50126和EN50129需采用系统性的方法，以： 1） 确定危险、风险和风险准则；

2） 为满足风险准则，确定必要的风险降低；

3） 为实现必要的风险降低，定义一个全面的系统安全性需求规格说明； 4） 选择一个合适的系统体系结构；

5） 规划、监督和控制那些把系统安全性需求规格说明变成安全性能(或安全完整性)已确认的安全相关系统 所必需的技术和管理活动。

在分解需求规格说明形成由安全相关系统和组件组成的设计说明时，需要进一步分配安全完整性等级，并最终形成所需的软件安全完整性等级。

1

同济大学、铁道科学研究院标准所 EN50128：2001

目前，无论是质量保证法(即避错措施)还是软件容错法的应用，都无法保证系统的绝对安全。尚未发现可以证明一个较复杂的安全相关软件中不存在错误的方法，特别是规格说明和设计的错误。

以下规则应用于开发高安全完整性等级软件，但也不仅限于开发高安全完整性等级软件： 1） 自顶向下的设计方法； 2） 模块化；

3） 开发生命周期每一阶段的验证； 4） 验证后的模块和模块库； 5） 清晰的文档； 6） 可审计的文档； 7） 确认测试。

这些规则以及相关的其他规则必须正确应用。对于各个软件安全完整性等级，本标准均规定了说明这一点所需的保证等级。

在得到或形成了系统安全性需求规格说明后，分配给软件的安全性功能和系统安全完整性等级就确定了，图2给出了应用本欧标的功能步骤，如下所示：

1） 定义软件需求规格说明，同时考虑软件体系结构。软件体系结构是为软件和软件安全完整性等级开发基

本安全策略的架构。(条款5、8和9)

2） 根据软件质量保障计划、软件安全完整性等级和软件生命周期来设计、开发和测试软件。(条款10) 3） 在目标硬件上集成软件。(条款12) 4） 确认软件。(条款13)

5） 如果在运行过程中需要软件维护，那么可再适当运用本欧洲标准进行处理。(条款16)

许多活动都是在软件开发过程中交叉进行的，这其中包括验证(条款11)，评估(条款14)和质量保障(条款15)。 给出了应用数据配置的系统的需求(条款17)。 给出了从事软件开发人员能力的需求。(条款7)

本标准没有硬性要求使用特定的软件开发生命周期，但是给出了一个推荐的生命周期及文档集。(条款7，图3和图4)

表格针对5个软件安全完整性等级明确罗列了各种技术和措施。表格在附件A中给出。与表格对照的参考书目提供了更多的信息，给出了每项技术和措施的简明描述。参考书目在附件B中给出。

2

同济大学、铁道科学研究院标准所 EN50128：2001

1 范围

1.1 本欧洲标准详细规定了铁路控制和防护设备用的可编程电子系统开发所需的程序和技术要求。它适用于任何有隐含安全性的领域。这些应用系统的范围涵盖了安全苛求系统,如安全信号，非安全苛求系统,如管理信息系统。这些系统可能通过采用专用多处理器，可编程逻辑控制器，分布式多处理器系统，大规模集中处理器系统或者其它架构来实现。

1.2 本欧洲标准专门应用于软件以及软件和系统之间的相互作用。

1.3 0级以上的软件安全完整性等级用于失效可引起失去生命的后果的系统。然而，从经济或环境因素方面考虑也能采用高级别的安全完整性等级。

1.4 本欧洲标准适用于铁路控制和防护系统开发和实现的所有软件，包括：

应用程序设计； 操作系统； 支持工具； 固件。

应用程序设计包括高级程序设计，低级程序设计和专用程序设计（如：可编程逻辑控制器梯形逻辑）。 1.5 本欧洲标准还涉及了本标准的使用、商用软件和工具。 1.6 本欧洲标准还对应用数据配置的系统提出了要求。

1.7 本欧洲标准并不涉及商务问题，这些问题应为合同的基本部分被提出。但本欧洲标准中的所有条款在任何商务活动中都需被仔细考虑。

1.8 本欧洲标准为避免追溯，主要应用于新的开发。对于现有系统，仅当进行主要修改时才进行全面应用，对于次要修改，只要应用条款16。

2 规范性参考文献

本欧洲标准需与标注日期或未标注日期的参考文献以及其他出版物中条款相结合。这些规范性参考文献将在文中合适的位置被引用，相应的出版物将在下面列出。对于标注日期文献的后续修改或修订，本欧洲标准需通过修改或修订进行结合来应用。对于未标注日期的文献,则应用最新版本(包括修改)。

EN50126，铁路应用——可靠性，可用性，可维持性和安全性（RAMS）的规格和说明； EN50129*，铁路应用——信号领域的安全相关电子系统； EN50159-1,铁路应用——通信，信号和处理系统 第一部分：封闭传输系统中的安全通信；

3

同济大学、铁道科学研究院标准所 EN50128：2001

EN50129-1,铁路应用——通信，信号和处理系统 第二部分：开放传输系统中的安全通信；

EN ISO 9001,质量体系——设计/开发，生产，安装和维护的质量保证模型；

EN ISO 9001-3,质量管理和质量保证标准——第三部分：ISO9001:1994在计算机软件的开发，供应，安装和维护应用的指导。 3 定义

以下定义适用于此欧洲标准.对于未定义的术语,按照优先顺序查阅以下参考文献。 EN ISO 8402，质量管理和质量保证——词汇表；

IEC 60050-191,国际电工词汇第191章：服务可信性和质量； IEEE 610.12, IEEE标准软件工程术语词汇表； ISOIIEC 2382,信息技术词汇表；

ISOIIEC 9126,信息技术－软件产品评估－质量特性以及其使用指导； 3.1 评估（assessment）

用于确定设计主管机构和确认员所完成的产品是否符合规定的要求和判定产品是否达到预期目的的分析过程。 3.2 评估员（assessor）

受委托执行评估的人员或者代理。 3.3 可用性（availability）

假定所需外部资源均能满足的条件下，产品在规定的条件下，在规定的时刻或在给定的时间间隔内完成要求功能的能力。

3.4 商用软件（COTS software）

市场需求所定义、市场已存在且其目标满足性已得到广大商业用户证明的软件。 3.5 设计主管机构（design authority）

负责提出实现特定需求的设计方案，并监控后期的开发和系统在特定环境下工作的实体。 3.6 设计者（designer）

一个或多个由设计主管机构指派的人员，他们承担需求分析并将特定需求转化成可接受且有相应安全完整性的设计方案。

3.7 元素（element）

被确认为基本单元和基本部件的某产品的一部分。一个元素可以是简单或者复杂的。 3.8 错误（error）

4

同济大学、铁道科学研究院标准所 EN50128：2001

与期望的设计相背离，并有可能导致未预料到的系统行为或失效。 3.9 失效（failure）

与规定的系统行为相背离。失效是系统错误或故障的结果。 3.10 故障（fault）

一种能导致系统错误或失效的不正常情形，故障可以是系统性或随机性的。 3.11 避错（fault avoidance）

在系统设计和构造的过程中使用避免引入故障的设计技术。 3.12 容错（fault tolerance）

在出现有限数量的软硬件故障的情况下，系统能继续提供正确的规定服务的内嵌能力 3.13 固件（firmware）

指令和存储在一个功能独立主存储器（通常是ROM）中的相关数据的有序集合 3.14 通用软件（generic software）

通用软件是只要提供应用相关的数据就可以应用于多种系统装置的软件。 3.15 实现人员（implementer）

由设计主管机构委派、具体实现特定设计的一个或更多人员 3.16 产品（product）

为满足特定需求，收集元素并进行互连以形成一个系统，子系统或者设备。本欧洲标准中，产品可被视为完全由软件或者文档元素构成。 3.17 可编程逻辑控制器(PLC)

具备面向指令存储的用户可编程存储器、能实现轨定功能的固态控制系统。 3.18 可靠性(reliability)

设备在规定的条件下，在规定的时间内执行要求功能的能力。 3.19 需求可追溯性（requirement traceability）

需求可追溯性的目标是确保所有的需求能被证明已得到满足 3.20 风险（risk）

某特定危险事件的频率或概率和后果的组合。 3.21 安全性（safety）

无不可接受的风险等级。

3.22 安全主管机构（safety authority）

5

同济大学、铁道科学研究院标准所 EN50128：2001

负责证实安全相关系统适于工作并符合法令、规章规定的安全性需求的实体。 3.23 安全相关软件（safety-related software）

负有安全责任的软件。 3.24 软件（software）

由程序、过程、规则和系统运行相关的文档组成的智力创造。 3.25 软件生命周期（software life cycle）

从软件构思开始到软件不再可用结束的时期内发生的活动。典型的软件生命周期包括一个需求阶段，开发阶段，测试阶段，集成阶段，安装阶段和一个维护阶段。 3.26 软件可维性（software maintainability）

系统能被修改以纠正故障、改进性能或其它特性，或适应不同环境的能力。 3.27 软件维护（software maintenance）

它是指在软件被最终用户接收后所进行的活动或活动集合,它的目的在于改善,增加或纠正软件的功能。。 3.28 软件安全完整性等级（software safety integrity level）

一组分级数字，它确定了为将残留软件故障降低到一个适当水平所必须采用的技术和措施。 3.29 系统安全完整性等级（system safety integrity level）

表示系统能满足规定安全特性的置信度的数字。 3.30 可追溯性（traceability）

能在开发过程中确定两个或者多个产品之间关系的程度，尤其是那些与其它产品构成前/后代或上/下级关系的。 3.31 确认（validation）

通过测试和分析，表明产品在各个方面符合规定需求的证实行为。 3.32 确认员（validator）

被委派来做确认工作的人或者代理。 3.33 验证（verification）

通过测试和分析，表明系统生命周期的各阶段的输出符合前一阶段的需求的一种决定性行为。 3.34 验证员（verifier）

被委派来做验证工作的人或代理。

4 目标和符合

4.1 在以下每个条款中，将详细地描述其目标和要求。

4.2 为遵从本欧洲标准，应表明依据规定的软件安全完整性等级每一项需求都已得到满足，因而也满足条款的目标。

6

同济大学、铁道科学研究院标准所 EN50128：2001

4.3 如果一个需求附有“在软件安全完整性等级要求的范围内”的词句，则表示可用一定范围内的技术和措施来满足该需求。

4.4 在上述条款适用的地方，应使用本欧洲标准详细给出的表格来帮助选择与软件安全完整性等级相适应的技术和措施。

4.5 如果某一技术或措施在表格中被列为强力推荐，那么不使用该技术的理由应在软件质量保证计划中或软件质量保证计划参考的其他文件中作详细说明并作相应的记录。如果使用了相应表格中被认可的技术，这就不一定要作记录了。

4.6 如果一项不包括在表格中的技术或措施被建议使用，那么应对其有效性及能满足特殊要求和条款整个目标的适用性作论证，并在软件质量保证计划中或软件质量保证计划参考的其他文件中作相应的记录。

4.7 应通过检查本标准所要求的文档、其他客观证据、审计和见证测试来评估是否符合特殊条款的要求和表格中详细列出的各自的技术和措施。

4.8 本欧洲标准需要使用一组技术及它们的正确应用。这些技术是表格中所要求的，并在参考书目中详细列出。 5 软件安全完整性级别

5.1 目标

给软件指定软件安全完整性等级。 5.2 要求

5.2.1 依据EN50126和EN50129，应形成

- 系统需求规格说明书 - 系统安全性需求规格说明书； - 系统结构描述； - 系统安全性计划； 其中包括： · 安全性功能； · 系统配置或体系结构； · 硬件可靠性需求； · 安全完整性需求；

软件安全完整性等级应通过获得EN50126确定的安全完整性等级的一般过程来确定。

5.2.2 应在系统中软件应用的风险水平和系统安全完整性等级的基础上决定需要的软件安全完整性等级。 5.2.3 如没有进一步防范措施，软件安全完整性等级至少等于系统安全完整性等级。然而，如果存在能预防软件模块失效导致系统进入不安全状态的机制，则可以减低模块的软件安全完整性等级。

7

同济大学、铁道科学研究院标准所 EN50128：2001

5.2.4 应考虑的风险与下列危险后果有关：

· 失去生命； · 使人受伤或生病； · 环境的污染； · 财产损失或损坏。

5.2.5 风险可被定量化，但不能以同样方式规定软件安全完整性。因此，对于本欧洲标准，软件安全完整性等级被指定为下列五个等级之一：

软件安全完整性等级 软件安全完整性等级描述

4 非常高 3 高 2 中等 1 低 0 非安全性

5.2.6 在软件需求规格说明书中应指定软件安全完整性等级(条款8)。如果不同的软件组件有不同的软件安全完整性等级，应在软件架构规格说明书中加以规定(条款9)。

6 人员和职责

6.1 目标

保证所有对软件负有责任的人员有能力履行那些职责。 6.2 要求

6.2.1 供应者和/或开发者以及客户最低限度都应执行EN ISO 9001的相关部分，以保持和EN ISO 9000—3一致。 6.2.2 除软件安全完整性等级0以外，安全性过程应在一个适当的安全性组织的控制下完成。该组织遵从EN 50129“安全性管理的证据”条款中“安全性机构”子条款要求。

6.2.3 软件生命周期各阶段（包括管理活动）涉及的所有人员应具有适当的培训、经验和资格。

6.2.4 除软件安全完整性等级0以外，对于特定应用，强力推荐对软件生命周期各阶段（包括管理活动）涉及的所有人员的培训、经验、资格进行证实。

6.2.5 应在软件质量保证计划中记录上述子条款要求的论证，适当的包括能胜任下列领域工作的证据：

· 适合应用领域的工程； · 软件工程； · 计算机系统工程；

8

同济大学、铁道科学研究院标准所 EN50128：2001

· 安全工程； · 法规框架。

6.2.6 指定独立的软件评估员。也可参看6.2.10 和 14.4.1。 6.2.7 应赋予评估人员足够的权威来实现对软件的评估。

6.2.8 软件整个生命周期各个阶段所涉及的各方的独立性要根据软件安全完整性等级调整，保持和图5一致，解释如下：

在各个软件安全完整性等级，评估员应由安全主管机构认可，除6.2.10规定的情况外，都应独立于供应商。 设计者生产者、验证员和确认员可以同属一个公司，但至少要满足以下独立性： ? ?

在软件安全完整性等级0：没有限制；设计者/生产者、验证员和确认员可以是同一人。

在软件安全完整性等级1和2：验证员和确认员可以是同一人，但他们不应又是设计者/生产者。设计者/生产者、验证者和确认者能向项目经理报告。 ?

在软件安全完整性等级3和4：有两种允许的安排：

a) 验证员和确认员可以是同一人，但他们不应又是设计者/生产者。而且他们不应象设计者/生产者一样

向项目经理报告，他们有权力阻止产品的提交。

b) 设计者/生产者、验证员和确认员必须是各不相同的人。设计者/生成者和验证员可以向项目经理报告，

而确认员则不向项目经理报告。确认员有权力阻止产品的提交。

6.2.9 负责各个条款的有关人员如下：

软件需求规格说明书（条款8） 设计者 软件需求测试规格说明书（条款8） 确认员 软件体系结构（条款9） 设计者 软件设计和开发（条款10） 设计者 软件验证和测试（条款11） 验证员 软件/硬件集成（条款12） 设计者 软件确认（条款13） 确认员 软件评估（条款14） 评估员

6.2.10 根据安全主管机构的意见，评估员可以是供应商组织或客户组织的一员，在这种情况下，评估员应：

? ? ?

由安全主管机构授权； 完全独立于项目梯队； 直接向安全主管机构报告

9

同济大学、铁道科学研究院标准所 EN50128：2001 7 生命周期和文档

7.1 目标

7.1.1 将软件开发构造成规定的阶段和活动。

7.1.2 记录贯穿整个软件生命周期的软件所有相关信息。 7.2 要求

7.2.1 选择软件开发的生命周期模型，根据本欧洲标准条款15，它将在软件质量保证计划中加以详细说明。图3和图4 给出了生命周期模型的例子。

7.2.2 质量保证程序应与生命周期活动一起运行，并且使用相同的术语。

7.2.3 某阶段所有要进行的活动应在该阶段开始之前就被定义好。软件生命周期的每阶段都应划分成带有良好定义的输入、输出及其活动的基本任务。

7.2.4 软件质量保证计划应当描述需要哪些验证步骤和报告。 7.2.5 所有文档应结构化，以便能随着设计过程不断扩展。

7.2.6 各个文档应有唯一的参考号，与其他文档应有确定的、记录在案的文档关系，以便进行文档追溯。每个文档对术语、缩写词和简写词应有相同的解释。如果由于历史的原因，这一点达不到，就应给出不同的释义和参考资料。

此外，除商用软件或早期开发的软件外的文档外，各文档应按下列规则书写： a） 应包括或执行所有前期文档的适用条件和需求，使文档具有层次关系； b） 不应与前期文档有抵触；

c） 在各个文档中，每个术语，首字母缩略词或缩写应具有相同的意义； d） 在各个文档中，每一条目或概念应用相同的名称或描述来参考。 7.2.7 所有文档内容应以适合于操作、处理和存储的形式来记录。 7.2.8 根据软件安全完整性等级的要求，应形成文档交叉参考表。

7.2.9 根据开发软件的规模，复杂性和生命周期，需要产生的各类文件数目有所不同。对于规模较小的项目，一些文件可以组合在一起（在这过程中不应丢失需要的细节），而对于大规模项目，必须将所列文档（以层次方式）分成一些更便于管理的子文档。由独立团队或实体形成的文档不能组合成单一文档。

7.2.10 条款7确定的各种文参考文献文档之间的关系可以用文档交叉参考表来定义。对于表中文档列的各文档，通过从包含符号“?”的单元格开始水平和垂直地阅读可以发现与创建文档有关的阶段和条款。通过从标记为符号“◆”的单元格开始垂直地阅读可以发现应用文档阶段。条款或文档定义参考的其他参考文献可以在“定义的地方”列中找到。如给出条款，后继条款应被检查，因为它们可能包含进一步信息。还要注意的是：因软件配置管理计划需要的参考文献列在括号内，因为该条款只不过参考EN ISO 9001。

10

同济大学、铁道科学研究院标准所 EN50128：2001

文档对照表

条款 标题 阶段 （*）=和其他阶段平行 系统输入 ? ? ? 软件计划(*) ? 软件需求 ? ? 软件设计 软件模块 设计 编码 模块测试 软件集成 软件/硬件集成 确认(*) 评估(*) 维护 ? ? ? ? 软件确认报告 软件评估报告 软件修改记录 软件维护记录 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 系统需求规格说明书 系统安全需求规格说明书 系统结构描述 系统安全性计划 软件质量保证计划 软件配置管理计划 软件验证计划 软件集成测试计划 软件/硬件集成测试计划 软件确认计划 软件维护计划 数据准备计划 数据测试计划 软件需求规格说明书 应用需求规格说明书 软件测试规格说明书 软件需求验证报告 软件结构规格说明书 软件设计规格说明书 软件结构和设计验证报告 软件模块设计规格说明书 软件模块测试规格说明书 软件模块验证报告 软件源代码 软件源代码验证报告 软件模块测试报告 软件集成测试报告 数据测试报告 软件/硬件集成测试报告 EN50129附件B.2.3 EN50129附件B.2.4 EN50129附件B.2.1 EN50129、 EN50126 15.4.3 (15.4.2) 11.4.1 11.4.5 12.4.1 13.4.3 16.4.3 17.4.2.1 17.4.2.4 8.4.1 17.4.1.1 8.4.13 11.4.11 9.4.1 10.4.3 11.4.12 10.4.3 10.4..14 11.4..13 11.4.14 10.4.14 11.4.15 17.4.2.4 12.4.8 13.4.10 14.4.9 16.4.9 16.4.8 8 SRS 9 SA 10 SDD 11 SVer 12 S/HI 13 SVal 14 Ass 15 Q 文档 定义出处 16 Ma 11

同济大学、铁道科学研究院标准所 EN50128：2001

8 软件需求规格说明

8.1 目标

8.1.1 描述一个文档，为满足所有系统需求，该文档根据软件安全完整性等级规定了完整的软件需求。它是对每个软件工程师均适用的综合性文档，因此他们不必再从其他文档中了解需求。 8.1.2 用于描述软件需求测试说明书。 8.2 输入文档

1） 系统需求规格说明书。 2） 系统安全性需求规格说明书。 3） 系统体系结构描述。 4） 软件质量保证计划。 8.3 输出文档

1） 软件需求规格说明书。 2） 软件需求测试规格说明书。 8.4 要求

8.4.1 软件需求规格说明书应描述待开发软件的需求特性，而不是开发软件的程序。这些特性应包括（除安全性外均在ISO/IEC 9126中定义） ：

? ? ? ? ? ?

功能性（包括能力和响应时间性能）； 可靠性和可维护性；

安全性（包括安全功能及其相关的软件安全完整性等级）； 效率； 可用性； 可移植性。

软件安全完整性等级源至于条款5，并记录在软件需求规格说明书中。

8.4.2 根据软件安全完整性等级的要求，软件需求规格说明书应以如下方式来描述和够造：

? ?

完整、清楚准确、无二义性、可验证、可测试，可维护和可行的； 可以追溯到8.2涉及的所有文档。

8.4.3 软件需求规格说明书应使用让系统整个生命周期所涉及、负有责任的人员都能理解的表达和描述方法。

12

同济大学、铁道科学研究院标准所 EN50128：2001

8.4.4 无论那里存在或规划一个直接互联，软件需求规格说明书都应明确并用文件证实受控设备内部或外部的与任何其他系统的所有接口，包括和操作员的接口。

8.4.5 软件需求规格说明书应详细描述所有相关的操作方式。

8.4.6 软件需求规格说明书中应详述可编程电子器所有相关的行为方式，尤其是失效行为。 8.4.7 软件需求规格说明书中应明确并用文件证实软硬件之间的任何约束。

8.4.8 软件需求规格说明书应指出软件自检的程度以及软件检测硬件的规定程度。软件自检包括软件自身失效和错误的检测和报告。

8.4.9 软件需求规格说明书应根据系统安全性需求规格说明书的要求包括周期性功能检测需求。

8.4.10 软件需求规格说明书应根据系统安全性需求规格说明书的要求包括使所有安全功能在整个系统运行期内可测试的需求

8.4.11 当要求软件来完成一些功能，特别是完成那些与实现选定系统安全完整性等级有关的功能时，软件需求规格说明书应对其加以清楚的说明。

8.4.12 当要求软件完成非安全功能时，软件需求规格说明书应对其加以清楚的说明。

8.4.13 软件需求测试规格说明书应从软件需求规格说明书开发而来，软件需求测试规格说明书用来验证软件需求规格说明书中所述的功能要求，同时也作为对已完成软件进行测试的描述。 8.4.14 软件需求测试规格说明书应为每个所需功能确定测试用例，包括：

i)

所需的输入信号及其序列和值；

ii) 预期的输出信号及其序列和值； iii) 接受准则，包括性能和各个质量方面。

8.4.15 在安全系统的确认过程中，对需求的可追溯性应作为一个重要内容加以考虑。 应提供方法允许在生命周期所有阶段均能证实这一点。

8.4.16 对于任何不可追溯材料，应表明其对系统的安全性或完整性是没有影响的。

9 软件体系结构

9.1 目标

9.1.1 开发一个软件体系结构，该结构按照选定软件安全完整性等级的要求实现软件需求规格说明书的需求。 9.1.2 评审系统结构对软件的需求。

9.1.3 确定和评估硬件/软件交互作用对安全性的重要性。 9.1.4 如果早先没有定义设计方法，那么选择一种设计方法。 9.2 输入文档

13

同济大学、铁道科学研究院标准所 EN50128：2001

1) 软件需求规格说明书。

2) 系统安全性需求规格说明书。 3) 系统体系结构描述。 4) 软件质量保证计划。 9.3 输出文档

软件体系结构规格说明书。 9.4 要求

9.4.1 应由软件提供者和/或开发者来建立建议性的软件体系结构，并在软件体系结构规格说明书中作详述。 9.4.2 软件体系结构规格说明书应考虑依据选定软件安全完整性等级的要求实现软件需求规格说明书的可行性。 9.4.3 软件体系结构规格说明书应明确、评估和详述所有硬件/软件交互的重要性。就象EN50126和EN50129所要求的，应在系统安全性需求规格说明书中记录硬件和软件交互作用的基础研究。 9.4.4 软件体系结构规格说明书应明确所有软件组件，并为它们明确：

i) ii)

这些组件是否是新的，现存的或私有的；

这些组件以前是否已被确认。如果是，它们的确认条件是什么；

iii) 各组件的软件安全完整性等级。 9.4.5 使用商用软件应满足以下限制条件：

i) ii)

对于软件安全完整性等级0，不需进一步防范措施即可使用商用软件； 如果商用软件使用于软件完整性等级1或2，则它应被包含在软件确认过程中；

iii) 如果商用软件使用于软件完整性等级3或4，则应采取以下防范措施：

a) 商用软件应进行确认测试; b) 应进行可能失效的分析；

c) 应确定一个策略来检测商用软件的失效并防护系统免受这些失效影响； d) 防保护策略应是确认测试的主题； e) 应有错误日志并对其进行评估；

f) 就实用性而言，应仅使用上商用软件的最简单功能。

9.4.6 如果要将以前开发的软件作为设计的一部分使用，那么应有清楚的标识。并用文件证实。软件结构规格说明书应论证软件在满足软件需求规格说明书和软件安全完整性等级方面的适宜性。必须仔细考虑任何软件的修改对系统剩余部分的影响，以决定是否需要再审查和再评估。应有证据表明没有进行再检验，再确认和再评估的和其他模块的接口规格说明书得到遵循。

14

同济大学、铁道科学研究院标准所 EN50128：2001

9.4.7 在设计过程中尽可能使用已有的、验证过的，按本标准开发的软件模块； 9.4.8 软件体系结构应减少应用的安全性部分；

9.4.9 如果软件由不同软件安全完整性等级的组件构成，那么该软件的所有组件都应按最高软件安全完整性等级的要求处理，除非有表明较高软件安全完整性等级组件和较低软件安全完整性等级组件相互独立的证据。这个证据应记录在软件结构规格说明书中。

9.4.10 软件体系结构规格说明书应明确按软件安全完整性等级要求进行软件开发的策略。软件体系结构规格说明书应按下列方式来表达和构造：

i) ii)

完整、清楚、精确、无二义，可验证、可测试、可维护以及可行； 可追溯到软件需求规格说明书。

9.4.11 软件体系结构规格说明书应证实在避错和容错软件设计策略的选择中所采取的平衡措施是正确的。 9.4.12 软件体系结构规格说明书应证实所选的技术和措施形成了一个集合，该集合满足了基于选定软件安全完整性等级要求的软件需求规格说明书。

10 软件设计和实现

10.1 目标

10.1.1 设计和实现软件需求规格说明书和软件体系结构规格说明书所确定的软件安全完整性的软件。

10.1.2 获得可分析、可测试、可验证和可维护的软件。此阶段还包括模块测试。由于验证和测试在确认过程中起关键作用，所以在设计和开发的整个过程中应特殊考虑验证和测试要求，以确保从一开始就使结果系统及其软件易于测试。

10.1.3 为选定的软件安全完整性等级选择一套覆盖整个软件生命周期的包括语言和编译器的合适工具，它有助于验证、确认、评估和维护。 10.1.4 实施软件集成。 10.2 输入文档

1） 软件需求规格说明书。 2） 软件体系结构规格说明书。 3） 软件质量保证计划。 10.3 输出文档

1） 软件设计规格说明书。 2） 软件模块设计规格说明书。 3） 软件模块测试规格说明书。

15

同济大学、铁道科学研究院标准所 EN50128：2001

4） 软件源代码和支持文档。 5） 软件模块测试报告。 10.4 要求

10.4.1 在设计过程开始之前，应能得到软件需求规格说明和软件体系结构规格说明，但不必已最终定稿。 10.4.2 应使待开发软件的规模和复杂性最小。

10.4.3 软件设计规格说明书应描述基于模块分解的软件设计，每一模块都有软件模块设计规格说明书和软件模块测试规格说明书。

10.4.4 软件设计规格说明书应说明：

1） 追溯到软件体系结构的软件组件和它们的安全完整性等级； 2） 软件组件和环境的接口； 3） 软件组件间的接口； 4） 数据结构； 5） 划分组件需求； 6） 主要算法和顺序； 7） 图表。

10.4.5 软件模块设计规格说明书应说明（每个模块一个软件模块设计规格说明书）

1) 2) 3) 4) 5)

确定追溯到上一层次的所有最底层的组件（现有标准称之为模块）； 它们和环境以及其它带有详细输入和输出要求的模块的细化接口； 它们的安全完整性等级； 细化的算法和数据结构。

每个软件模块规格说明书应是自相容的，允许进行相应模块的编码。

10.4.6 每一软件模块都应是可读的、可理解的和可测试的。

10.4.7 为选定的软件安全完整性等级选择一套包括设计方法、语言和编译器的覆盖整个软件生存周期的合适工具。 10.4.8 只要适用，就应使用自动测试工具和集成开发工具。这里应考虑验证和确认的需求。

10.4.9 根据选定的软件安全完整性等级的要求，所选程序设计语言应具有翻译器/编译器，该翻译器/编译器应具备下述条件之一：

1) 2) 3)

某公认国家/国际标准的确认证书； 一个详述其适合用途的评估报告；

一个进行翻译错误检测的基于冗余签名控制的过程。

16

同济大学、铁道科学研究院标准所 EN50128：2001

10.4.10 所选语言应满足如下要求：

1) 2)

所选语言应具有便于识别编程出错的特性； 所选语言应支持与设计方法相适应的特性。

10.4.11 如果不能满足上述条款，那么在软件体系结构规格说明或软件质量保证计划中应记录对更替语言的论证并详述其适合用途。

10.4.12 开发编码标准，并将其应用于所有软件的开发。编码标准应在软件质量保证计划中予以参考。

10.4.13 编码标准应明确好的编程习惯，禁止非安全语言特性并描述编写源代码文档的程序。每个程序模块至少应在源代码中包括如下指定的信息（非穷举的）：

? 作者；

? 配置历史； ? 简要描述。

推荐用这些信息的标准形式。该标准形式应对所有模块相同的。

10.4.14 软件模块测试：每个模块应有作为模块测试依据的软件模块测试规格说明书。这些测试应表明每个模块实现了预定的功能，软件模块测试规格说明书应定义需要的测试覆盖率。 应形成软件模块测试报告，其中应包括以下特性：

i)

描述测试结果以及每个模块是否满足它的软件模块设计规格说明书的需求；

ii) 描述每个模块的测试覆盖率，以表明所有源代码指令至少执行一次； iii) 应以可审计的形式；

iv) 测试用例和它们的结果应以机器可读的形式记录下来，以利后继分析。测试应是可重 复的，而且如果可

行的话，应自动进行。

检查模块已正确地满足了其测试规格说明书是一个验证活动，参见下一条款。

10.4.15 为符合所需软件安全完整性等级的要求，选定的设计方法应具有能方便以下活动的特性：

i)

摘要、模块化和其他控制复杂度的特性；

ii) 清楚且精确地表达：

a) 功能；

b) 组件间的信息流； c) 顺序和时延信息； d) 并发；

e) 数据结构和特性；

17

同济大学、铁道科学研究院标准所 EN50128：2001

iii) 人的理解； iv) 验证和确认。

10.4.16 选定的设计方法应具有方便软件维护的特性。这类特性应包括模块化、信息隐藏和封装。

10.4.17 软件模块集成应是逐渐将个体的且以前测试过的软件模块组合成一个合成整体(或一些合成子系统)的过程。其目的是在系统集成和测试之前能充分地证明模块接口和装配的软件。

10.4.18 在本标准的上下文中，为与规定的软件安全完整性等级相适应，应特别强调可追溯性：

i)

需求到设计或其他实现需求的对象的可追溯性；

ii) 设计对象到实现对象的可追溯性。

可追溯性过程的输出应是形式化配置管理的主题。

11 软件验证和测试

11.1 目标

按照选定的软件安全完整性等级的要求，测试并评价某一给定阶段的产品，以确保产品和作为该阶段输入的标准的正确性和一致性。 11.2 输入文档

1） 系统需求规格说明书。 2） 系统安全性需求规格说明书。 3） 软件需求规格说明书。 4） 软件需求测试规格说明书。 5） 软件体系结构规格说明书。 6） 软件设计规格说明书。 7） 软件模块设计规格说明书。 8） 软件模块测试规格说明书。 9） 软件源代码和支持文档。 10） 软件质量保证计划。 11） 软件模块测试报告。 11.3 输出文档

1） 软件验证计划。 2） 软件需求验证报告。

18

同济大学、铁道科学研究院标准所 EN50128：2001

3） 软件体系结构和设计验证报告。 4） 软件模块验证报告。 5） 软件源代码验证报告。 6） 软件集成计划。 7） 软件集成测试报告。 11.4 要求

11.4.1 为了对验证活动作正确的指导并提供适当的特殊设计和其它验证需要，应建立软件验证计划。在开发阶段(根据系统的规模)，计划可被分成一系列子文件，而且随着细化的验证需求变得更清晰，可作自然增加。 11.4.2 软件验证计划应用文件说明所有将在阶段验证过程中用的准则、技术和工具。

11.4.3 软件验证计划应描述为确保作为阶段输入的产品和标准的正确性和一致性所要进行的活动。 11.4.4 软件验证计划应致力于：

i)

选择验证策略和技术。为避免对验证和测试活动的评估过分复杂化，应优先考虑选择自身可分析的测试用例和方法等；

ii) 软件测试设备的选择和使用； iii) 验证活动的选择和文档； iv) 对获得的验证结果的评估； v)

可靠性需求的评估；

vi) 测试过程所涉及人员的职责和角色； vii) 要求达到的测试覆盖率。 11.4.5 软件集成测试计划应用文件说明：

i)

测试用例和测试数据；

ii) 实施的测试类型；

iii) 测试环境、工具、配置和程序； iv) 测试完整性判定的测试准则。

11.4.6 每一开发阶段都应表明功能、可靠性、性能和安全性需求得以满足。 11.4.7 验证应根据选定软件安全完整性等级的要求由独立方来执行。

11.4.8 验证之前由设计者进行的、未在文件中予以说明的验证活动不应作为验证的一部分。 11.4.9 每次验证结果应以软件验证计划中规定的或建议的形式来保存，以便审计。

19

同济大学、铁道科学研究院标准所 EN50128：2001

11.4.10 在每次验证活动之后应产生一份说明软件已通过验证或失败原因的验证报告。验证报告应指出：

i)

不符合软件需求规格说明书、软件设计规格说明书或软件模块设计规格说明书的部分；

ii) 不符合软件质量保证计划的部分；

iii) 不适合问题解决的模块、数据、结构和算法； iv) 检测到的错误或缺陷； v)

已验证部分的特性和配置。

11.4.11 软件需求验证：一旦形成了软件需求规格说明书，验证应包括：

i)

软件需求规格说明书在满足系统需求规格说明书、系统安全性需求规格说明书和软件质量保障计划中所规定需求方面的充分性；

ii) 软件需求测试规格说明书作为对软件需求规格说明书的测试的充分性； iii) 软件需求规格说明书内在一致性； iv) 结果记录在软件需求验证报告中。

11.4.12 软件体系结构和设计验证：在形成软件体系结构规格说明书和软件设计规格说明书之后，验证应包括：

i)

软件体系结构规格说明书和软件设计规格说明书满足软件需求规格说明书的充分性；

ii) 软件设计规格说明书与软件需求规格说明书的一致性和完整性的充分性；

iii) 作为测试用例集，软件集成测试计划对软件体系结构规格说明书和软件设计规格说明书的充分性； iv) 软件体系结构和设计规格说明书的内在一致性； 结果应记录在软件体系结构和设计验证报告中。

11.4.13 软件模块验证：在形成各软件模块设计规格说明书后，验证应包括：

i)

软件模块设计规格说明书满足软件设计规格说明书的充分性；

ii) 作为测试用例集，软件模块测试规格说明书对软件模块设计规格说明书的充分性； iii) 将软件设计规格说明分解到软件模块和软件模块设计规格说明书，其中涉及：

— 要求性能的可行性； — 进一步验证的可测试性； — 对于开发和验证团队的可读性； — 允许进一步改进的可维护性。

iv) 软件模块测试报告作为已完成测试的记录在满足软件模块测试规格说明书的充分性。 结果记录在软件模块验证报告中。

20

同济大学、铁道科学研究院标准所 EN50128：2001

11.4.14 软件源代码验证：按照选定软件安全完整性等级的要求应验证软件源代码以确保满足软件模块设计规格说明书和软件质量保证计划。应进行判定编码标准是否正确应用的检查。 结果记录在软件源代码验证报告中。

11.4.15 应按照下列各项形成软件集成测试报告：

i)

软件集成测试报告应表明测试结果以及软件集成测试计划的目标和准则是否被满足，如果有失效，则应记录失效的原因；

ii) 软件集成测试报告的形式应易于审计；

iii) 应记录测试用例及其结果，为便于后继分析其形式最好是机器可读的； iv) 测试应是可重复的，而且如果可行应自动进行； v)

已验证部分的特性和配置。

11.4.16 对于软件/硬件集成，参见下一条款。

12 软件/硬件集成

12.1 目标

12.1.1 证明软件和硬件间相互作用，正确地完成它们预定功能

12.1.2 组合软件与硬件并确保它们的相容性，以满足系统安全性需求规格说明书和预期软件安全完整性等级的需求。

12.2 输入文档

1） 系统需求规格说明书。 2） 系统安全性需求规格说明书。 3） 系统体系结构描述。 4） 软件需求规格说明书。 5） 软件需求测试规格说明书。 6） 软件体系结构规格说明书。 7） 软件设计规格说明书。 8） 软件模块设计规格说明书。 9） 软件模块测试规格说明书。 10） 软件源代码和支持文档。 11） 硬件文档。 12.3 输出文档

21

同济大学、铁道科学研究院标准所 EN50128：2001

1） 软件/硬件集成测试计划。 2） 软件/硬件集成测试报告。 12.4 要求

12.4.1 对于大于零的软件安全完整性等级，应在开发生命周期早期形成软件/硬件集成测试计划，以使集成活动能受到适当的指导，并适当提供特殊的设计或其他集成需求。在开发阶段（依赖于系统规模），计划可以划分成许多子文档，而且随着硬件和软件设计的不断改进以及细化的集成需求越发清晰，计划内容也自然增加。 12.4.2 软件/硬件集成计划应对如下内容作文字说明:

i)

测试用例和测试数据；

ii) 实施的测试类型；

iii) 测试环境，包括工具、支持软件和配置描述； iv) 测试准则，依此来判定测试的完整性。

12.4.3 软件/硬件集成计划应区分可在开发者自己场地进行的活动和需要在用户场地进行的活动。 12.4.4 软件/硬件集成计划应区分以下活动:

i)

将软件融入目标硬件；

ii) 系统集成。

12.4.5 应能在计划可行的第一时间取得软件/硬件集成计划确定的工具和设施。

12.4.6 在软件/硬件集成过程中，对已集成系统的任何修改或变更均应研究影响范围，该研究应确定所有受影响的模块和必要的重验证活动。

12.4.7 记录测试用例及其结果，为了后续分析，最好用机器可读形式记录。 12.4.8 软件/硬件集成测试报告应按以下要求形成：

i)

软件/硬件集成测试报告应表明测试结果以及是否满足软件/硬件集成测试计划的目标和准则。 如果存在失效，则应记录失效原因；

ii) 软件/硬件集成测试报告应以能审计的形式编写；

iii) 记录测试用例及其结果，为了后续分析，最好用机器可读形式记录；

iv) 软件/硬件集成测试报告应有验证者满意于软件/硬件集成测试报告为符合软件/硬件集成测试计划的要

求而作为已完成测试记录的充分性的证据； v)

软件/硬件集成测试报告应用文件来表明所有涉及部分的特性和配置。

22

同济大学、铁道科学研究院标准所 EN50128：2001

13 软件确认

13.1 目标

13.1.1 分析和测试已集成系统，以确保其符合软件需求规格说明书依据安全完整性等级对功能和安全性的特定要求。

13.2 输入文档

1） 系统需求规格说明书。 2） 所有硬件和软件文档。 3） 系统安全性需求规格说明书。 13.3 输出文档

1） 软件确认计划。 2） 软件确认报告。 13.4 要求

13.4.1 分析和测试是主要的确认活动。 13.4.2 可用仿真和建模来补充确认过程。

13.4.3 在适当的文件中形成并详述软件确认计划。

13.4.4 根据软件安全完整性等级的要求，应有独立部门来开发、执行和结果评估软件确认计划。

13.4.5 如果软件安全完整性等级有要求，软件确认计划的范围和内容可与评估人员协商一致。其中应声明测试过程中评估人员应在场。

13.4.6 软件确认计划应概要说明所选确认策略的合理性。根据选定软件安全完整性等级的要求，其中应考虑以下方面：

i)

手工或自动化技术；

ii) 静态或动态技术； iii) 解析或统计技术。

13.4.7 软件确认计划应确定证明以下规格说明书对于实现系统安全性需求规格说明书设定的安全性需求的充分性的必要步骤：

i)

软件需求规格说明书；

ii) 软件体系结构规格说明书； iii) 软件设计规格说明书；

23

同济大学、铁道科学研究院标准所 EN50128：2001

iv) 软件模块设计规格说明书。 确认者应检查验证过程的完整性。

13.4.8 用于确认的度量设备应被适时地校准，用于确认的任何工具、硬件或软件都应表明适合于确认。 13.4.9 应通过模拟正常运行时出现的输入信号、预期事件和需要系统动作的意外条件来执行。 13.4.10 用便于审计的形式，将确认结果记录在软件确认报告中。 13.4.11 硬件/软件集成完成后，应按以下要求形成软件确认报告：

i)

应陈述软件确认计划的目标和准则是否得以满足。如果存在失效，应予以记录；

ii) 应陈述测试结果以及在目标机器上的整个软件是否实现了软件需求规格说明书规定的需求； iii) 应对软件需求规格说明书所列需求的测试覆盖率作出评价； iv) 软件确认报告的形式应能用于审计； v)

为便于后续分析，应以机器可读的形式记录测试用例及其结果；

如果可行，测试应是可重复的，而且应是自动进行的。 13.4.12 软件确认报告应用文件说明以下各部分的特性和配置：

i)

使用的硬件和软件;

ii) 使用的设备； iii) 设备的校准； iv) 使用的仿真模型； v)

发现的差异；

vi) 执行的纠正操作。

13.4.13 应在软件确认报告的某单独一节中清楚地标识已发现的任何差异，包括检测出的错误，并将其附注在交付使用的软件的交付注解中。

13.4.14 应基于软件需求测试规格说明书测试软件，这些测试应表明软件需求规格说明书中的所有需求都被正确地实施。

结果记录在软件确认报告中。

14 软件评估

14.1 目标

评估生存周期过程和其结果使得软件具有规定的软件安全完整性等级并适用于预期应用。 14.2 输入文档

1） 系统安全性需求规格说明书。

24

同济大学、铁道科学研究院标准所 EN50128：2001

2） 所有的软件和硬件文档。 14.3 输出文档

软件评估报告。 14.4 要求

14.4.1 对软件安全完整性等级0：

i)

评估员只需要证实此软件安全完整性等级是合适的；

ii) 供应商和用户可能在投标时同意此软件安全完整性等级。

14.4.2 不必对已有出自另一评估员的软件评估报告的软件作新的评估。但第二位评估员要检查软件具有要求的软件安全完整性等级并且在预期的目标机器上适合预期的应用。

14.4.3 评估员应有权利接触设计和开发过程以及所有与项目有关的文档。 14.4.4 软件评估应由独立于设计团队的评估员来完成。

14.4.5 评估员应评估系统软件符合预期的目的，并对系统安全性需求规格说明书的安全性要求作出正确的响应。 14.4.6 按照选定的软件安全完整性等级的要求，评估员应判定是否选择了合适的方法并将其运用于软件生存周期的各个阶段。

14.4.7 如果软件安全完整性等级有要求，评估员应同意软件确认计划的范围和内容。但协议中应声明测试过程中评估员应在场。

14.4.8 评估员可以要求进行附加的验证和确认工作。

14.4.9 评估员将为每个评审形成一份报告，该报告应细述他的评估结果。

14.4.10 如果按评估员的观点，软件能适合预期的应用，则最终的软件评估报告应声明软件达到了软件安全完整性等级。

14.4.11 若软件不适合预期或未达到要求的软件安全完整性等级，那么评估员应在软件评估报告中仅报告不符合项，不应给出技术解决方案。

15 软件质量保证

15.1 目标

15.1.1 确定、监控所有保证软件达到要求的质量所必须采取的技术和管理活动。为了提供针对系统故障所需的定性防护并确保形成一个审计踪迹以使验证和确认活动能有效地开展，这一点是必须做的。 15.1.2 提供证据来证明以上活动已被完成。 15.2 输入文档

生存周期的每个阶段使用的所有文档。

25

同济大学、铁道科学研究院标准所 EN50128：2001

15.3 输出文档

1)软件质量保证计划。 2)软件配置管理计划。

所有上述计划均在项目开始时制定，并在生存周期过程中修改。 15.4 要求

15.4.1 供应商和/或开发商至少应拥有和使用一个符合EN ISO 9000系列的质量保障系统，以支持本欧洲标准的要求，强力推荐EN ISO 9001认证。

15.4.2 按照EN ISO 9000—3的指导方针，供应商和/或开发商以及客户对于软件开发至少应执行EN ISO 9001的相关部分。

15.4.3 供应商和/或开发商应一个项目接一个项目地准备并用文档说明软件质量保证计划以完成本欧洲标准条款上两条要求，并尽可能以可度量形式表达出来。

15.4.4 软件质量保证计划应有一段文字来规定在整个项目过程中其自身更新的细节：频度、责任、方法。 15.4.5 EN ISO 9000—3和本欧洲标准(包括附件A)的所有章节中要求的活动，操作和文件等均应在软件质量保证计划中规定或参考，并适应特定的开发。EN ISO 9000—3中没有一张列表被认为是彻底的。 除软件安全完整性等级0外，在软件质量保证计划中至少应说明或参考以下条款。

这是为了确保覆盖软件中和选定软件安全完整性等级有关的所有安全性方面。 当前列表不是彻底的： 1)

生存周期模型定义和每个阶段定义，包括： - 活动和基本任务；

- 进入和退出准则；—各阶段的输入和输出； - 各阶段的主要质量活动；

- 对每一活动和基本任务负责的组织部门； 2) 3) 4) 5) 6) 7)

需求追踪能力； 文档结构追踪能力；

与软件开发、验证、确认、运行和维护有关的文档； 系统集成程序； 使用的编码标准； 对早期确认测试的评估；

26

同济大学、铁道科学研究院标准所 EN50128：2001

8)

产品和过程度量(定量测量)的定义。为了实现软件产品度量，应参照ISO/IEC912定义的质量特征和评估方针。

15.4.6 按照EN ISO 9000—3，至少应实行配置管理。

每个软件在发布首个认可版本之前，其文档应受配置管理的控制。在备有证明文件的模块开始测试之前，软件源代码应受配置管理的控制。

配置管理控制不允许对任何部分进行任何未经认可的修改。在储存、转移、传输或复制过程中，应采取预防措施以防止或检测机器可读的代码中出现的错误。

配置管理不应局限于严格的产品开发和维护，它还应覆盖整个生存周期中使用的环境。这一对再现开发和维护活动所必须的扩充应包括汇编、编译、调试器以及所有其它用到的工具。 15.4.7 应检查软件验证计划的充分性和结果。

15.4.8 供应商和/或开发者应建立、用文件描述和维护外部供应商控制的程序，其中包括：

- 确保外部供应商提供的软件满足已有需求的方法。应保证前期开发的软件符合软件安全完整性等级和可信性。新软件应按供应商的软件质量保证计划或与供应商的软件质量保证计划协调一致的外部供应商的特定软件质量保证计划来进行开发和维护。

- 确保提供给软件外部供应商的需求是充分的而完备的。

15.4.9 供应商和或开发者应建立、用文件描述并维护问题报告和纠正行为的程序。这些程序作为质量保障系统的一部分，应实施EN ISO 9001的相关部分，特别至少应覆盖以下几个方面：

- 为了反馈给负责的管理部分，规定问题报告和或纠正行为所需的文档。 - 规定在问题报告中收集到的信息的分析方法，以判断出其原因。 - 规定在开发阶段和软件维护过程中报告、追踪和问题解决应遵循的措施。 - 规定根据与所要求的软件安全完整性等级相对应的等级处理问题的预防行为。 - 规定有关开发和软件维护的特定组织的职责。 - 规定如何实施控制，以确报纠正行为已被采取并有效。 - 规定再测试、再验证、再确认和再评估的需求。

在紧接软件集成之后、正式的软件确认开始之前的软件生存周期中，至少应实施问题报告和纠正行为管理，而且要覆盖软件维护整个阶段。

16 软件维护

16.1 目标

确保软件按要求执行，并在对软件自身作纠正、功能增强和修改时保持软件安全性完善性等级和可信性。

27

同济大学、铁道科学研究院标准所 EN50128：2001

16.2 输入文档

所有文档。 16.3 输出文档

1) 2) 3)

软件维护计划。 软件修改记录。 软件维护记录。

16.4 要求

16.4.1 维护至少应根据EN ISO 9000－3的指导方针进行。 此外，还应该满足以下软件维护的需求。

16.4.2 软件系统中应设计有可维护性，特别是应遵循本欧洲标准的条款10。还应使用ISO/IEC9126，以要求和验证最低水平的可维护性。

16.4.3 应建立软件维护程序，并记录在软件维护计划中。这些程序应包括：

i)

对错误报告、错误日志、维护日志、更改授权和软件/系统配置的控制；

ii) 验证、确认和评估；

iii) 规定认可软件更改的权威机构。

16.4.4 维护活动应根据软件维护计划，以软件质量保障计划中规定的周期进行审计。

16.4.5 维护阶段的技术水平、工具、文档、计划和管理应和系统的初始开发阶段相同。配置管理、更改控制、文档控制和相关组织的独立性也同样如此。

16.4.6 本欧洲标准并不打算进行追溯。所以它主要应用于新的开发，仅当已有系统要进行主要修改时，本标准才能完全应用于已有系统。对于软件安全完整性等级3或4，合同发包方应在开始任何修改工作前，判断维护工作是主要的还是次要以及系统维护方法是否充分的。而对于软件安全完整性等级0、1或2，同样的判断应由供应商来作。 16.4.7 应用“软件质量保障”条款中相关段落规定的类似准则来管理外部供应商控制、问题报告和纠正工作。 16.4.8 每个软件在首次发布前，应建立软件维护记录，并对其进行维护。除了EN ISO 9000-3对于“维护记录和报告”的需求之外，该记录还应包括：

i)

对该软件所有软件修改记录的参照；

ii) 修改结果信息；

iii) 部件的测试用例，包括再确认和回归测试数据； iv) 软件配置历史。

16.4.9 每个维护活动应建立软件修改记录。这个记录应包括：

28

同济大学、铁道科学研究院标准所 EN50128：2001

i)

变更或修改请求；

ii) 维护活动对整个系统影响的分析。包括软件，硬件，人机交互以及环境和可能的交互； iii) 修改或变更的详细规格说明；

iv) 按选定的软件安全完整性等级要求对修改或变更的再确认、回归测试和再评估。再确认的责职可根据软

件安全完整性等级，随项目的不同而不同。修改或变更对再确认过程的影响也可限制在不同的系统等级（仅仅是已变更的模块、所有标识出受影响的模块、整个系统）。因此，软件确认计划应根据软件安全完整性等级说明这两个方面的问题。再确认的独立性程度应与确认时的独立性程度一样。

17 根据应用数据配置的系统

17.1 目标

17.1.1 铁路控制和防护系统的一个显著特征是需要为满足各特定应用的需求设计装置。由应用数据配置的系统允许使用“类型认证”过的通用软件，每个装置的特定需求应被定义成数据（特定应用的数据）。这数据一般采取列表信息形式或采用由通用软件解释的特定应用的语言。

17.1.2 对于安全性关键系统，开发软件以使系统能实现所要求的系统安全完整性等级所需资源的昂贵程度使得采用应用数据配置的系统非常诱人，原因是它允许通用软件的复用。然而由于系统的安全运行可能依赖于数据的正确性，数据开发的程序也必须达到适当的系统安全完整性等级。

17.1.3 以下部分描述了本欧洲标准关于应用数据配置的系统中通用软件的初始开发和各套具体装置数据的后续开发的需求。 17.2 输入文档

1) 2)

软件需求规格说明书。 软件体系结构规格说明书。

17.3 输出文档

1) 2) 3) 4)

应用需求规格说明书。 数据准备计划。 数据测试计划。 数据测试报告。

17.4 要求

17.4.1 数据准备生存周期

图6描述了使用硬件、通用软件和具体应用数据的应用生存周期。生存周期的各阶段如下所述。

29

同济大学、铁道科学研究院标准所 EN50128：2001

17.4.1.1 应用需求规格说明书

对应用的需求加以定义。需求应包括具体装置的特定需求(如站场图、信号位置、速度限制)和应用必须遵守的标准(如信号原则、系统安全完整性等级)。 17.4.1.2 装置整体设计

应对系统体系结构加以定义，计划使用的通用部件的数量和类型也要加以说明。这些包括软件的部件的开发应符合本欧洲标准。需求中指定的功能应分配到各部件，并对各部件的物理位置加以规定。 17.4.1.3 数据准备

数据准备过程应包括形成特定信息(如控制表)、形成数据源代码及其编译、检查、其它验证活动以及应用数据的测试。

17.4.1.4 集成和验收

对有些系统，在现场安装之前应用数据将同通用硬件、软件集成在一起在厂内进行测试。若通过其它方法可获得足够的可信度，可不进行该项测试。随后应进行设备的现场安装，并对新设备进行集成测试。最后系统作为整体运行系统交付使用，并对整个装置进行最后的验收。 17.4.1.5 确认和评估

确认和评估活动应对生存周期各阶段的执行情况进行审计。 17.4.2 数据准备程序和工具

对于应用数据配置的各种新型系统，应开发特定的数据准备程序和工具，以使新系统的装置中应用上一条款中规定的数据准备生存周期。这些程序和工具的开发应和系统的通用软件和硬件一起符合本欧洲标准。验证、确认和评估活动应确保数据准备工具和通用软件相兼容。

17.4.2.1 在应用数据配置的系统的软件设计阶段，应形成一个数据准备计划，以便为数据准备过程定义一个文档结构。这些文档应与上一条款中描述的数据准备生存周期模型有关。计划中应规定为满足要求的系统安全完整性等级而使用的数据准备程序和工具。计划中还应规定进行验证、确认和设计任务的人员之间的独立性的需求。 17.4.2.2 数据准备计划应给数据准备生存周期中使用的硬件或软件工具分配安全完整性等级。该安全完整性等级应来源于要求的系统安全完整性等级和其他人工或自动化的程序检查每个工具输出的程度。

17.4.2.3 数据准备计划应尽可能用应用工程师们熟悉的符号来规定需求和设计，如标准信号计划和控制表。在引入新符号的地方，必须提供必要的用户文档并进行适当的培训。

17.4.2.4 证明数据准备已按计划实施所需的验证、测试、确认和评估报告可标准化成检查表的形式,以便减少为各装置产生文档的工作量。这些信息应包含在数据测试计划中，结果应被记录在数据测试报告中。

30

同济大学、铁道科学研究院标准所 EN50128：2001

17.4.2.5 所有数据和有关文档应符合本标准第15节中的配置管理需求。配置管理记录要列出用于产生数据以运行的通用软件的版本和数据准备过程中使用的工具的版本。 17.4.3 软件开发

开发应用数据配置的系统中的通用软件应遵循本标准1—16条款的需求。同时还应遵守以下附加的要求。 17.4.3.1 在软件需求规格说明书阶段，应确定每个系统和子系统中哪些功能将使用应用数据。分配给每个子系统的系统安全完整性等级将决定系统所有装置的数据后续开发的应用标准。

17.4.3.2 在软件设计阶段，应确定通用软件和应用数据之间的详细接口，除非这已在生存周期的早期阶段中得以规定，例如，是要求使用现存的面向应用的语言的结果。

17.4.3.3 在软件模块设计阶段，程序源代码和数据之间必须实行严格的分离，即除非对软件和数据之间的已规定接口作了变动，否则可以在不修改另一部分（数据或软件）时就对通用软件或数据进行重新编译和修改。类似地，特定应用数据应和其他数据分开。

17.4.3.4 在软件维护阶段，变更控制程序必须确保只有在确定被修改的软件与原数据相兼容或对数据已作必要的修订后，才能安装修改后的通用软件。

17.4.3.5 在软件验证过程和软件确认阶段，要留意以确保考虑了数据所有的相关组合。 17.4.3.6 如果可行，通用软件应被设计成能检测出损坏的配置数据。

31

同济大学、铁道科学研究院标准所 EN50128：2001

系统安全完整性等级 软件安全完整性等级 安全完整性等级 4- 非常高 4 3 2 1 0 4 3 2 1 0 3- 高 2- 中等 1- 低 0- 无安全要求 需要的风险降低 风险水平： 无防护措施 危险事件频率 危险事件后果 频率增加 后果增加 受控设备

图1 –安全相关系统的完整性等级

32

同济大学、铁道科学研究院标准所 EN50128：2001

获得系统需求规定， 系统安全性要求规定， 系统结构描述和系统安全性方案 明确所有分配给软件的安全性功能 评审所有分配给软件的安全性功能并决定软件安全完整性度等级 形成软件需求规格说明书和软件结构规格说明 按照软件质量保障计划，软件安全完整性等级和软件生命周期来设计，开发和验证/确认软件 实施软件确认并移交给系统工程师 系统运行生命阶段 软件维护

图2 – 软件安全路线图

33

同济大学、铁道科学研究院标准所 EN50128：2001

设计文档 验证 系统需求规格说明书、系统安全性需求规格说明书、系统结构描述、系统安全性计划 系统验证

软件需求测试规软件需求规格说格说明书 明书 软件需求验证

软件结构规格说明 软件结构验证

软件集成计划 软件设计规格说明 软件设计验证

软件模块测试规软件模块设计规格说明 格说明 软件模块验证

软件源代码和支持文件 代码验证

软件模块测试报告 软件集成测试报告 软件/硬件集成测试报告 软件确认

系统集成和测试文档 系统确认

系统安装文档 系统维护文档 图3 – 开发生命周期1

34

阶段

系统开发

软件需求

软件设计

软件模块设计

编码

软件测试

软件/硬件集成 软件确认 系统集成 系统确认阶段

现场支持

同济大学、铁道科学研究院标准所 EN50128：2001

系统开发阶段 系统需求规格说明书 系统安全性要求规格说明书 系统结构描述 系统安全性计划 软件维护阶段 软件维护记录 软件修改记录 软件评估阶段 软件评估报告 软件需求规格说明书阶段 系统需求规格说明书 系统需求测试规格说明书 系统需求验证报告 软件确认阶段 软件确认报告 软件/硬件集成阶段 软件/硬件集成测试报告 软件计划阶段 软件开发计划 软件质量保障计划 软件配置管理计划 软件验证计划 软件集成测试计划 软件/硬件集成测试计划 软件确认计划 软件维护计划 软件结构和设计阶段 软件结构规格说明书 软件设计规格说明书 软件结构和设计验证报告 软件集成阶段 软件集成测试报告 软件模块设计阶段 软件模块设计规格说明书 软件模块测试规格说明书 软件模块验证报告 软件模块测试阶段 软件模块测试报告 编码阶段 软件源代码和支持文档 软件源代码验证报告

图4 – 开发生命周期2

35

同济大学、铁道科学研究院标准所 EN50128：2001

注： ＝ 可以是同一个人 ＝ 可以是同一个公司 DI=设计者/实现者 VER=验证员 VAL＝确认员 ASS?R＝评估员 PRJ MGR=项目经理 图5 – 软件安全完整性等级和独立性比较

36

同济大学、铁道科学研究院标准所 EN50128：2001

通用系统设计和开发 工厂应用工程

系统需求规格 计划制定 说明 验证 验证 系统设计 装置设计 系统确认 和 验证 工厂确认 和 验证 证明 实现 证明 生产 验证 验证 系统集成 装置测试 验证 验证 系统认证 验收和交付使用

图6 – 通用系统开发和应用开发之间的关系

37

同济大学、铁道科学研究院标准所 EN50128：2001

附件A （规范性） 技术和措施的选择标准

本欧洲标准中从7到16的每一条款都有一个相关的条款表格来说明实现符合的方法。其中有低等级表格和扩充条款表格中某个条目的细化表格。例如，条款8表格(表格A.2)中的半形式化方法在细化表格D.7（表格A.18）中得到扩充。本附件的条款表格还参考了参考性的附件B。

每个软件安全完整性等级（SWSIL）（1—4级和非安全相关的0级）都对表格中每项技术或措施有要求。 在本版本中，软件安全完整性等级1和2对于每项技术的要求都是一样的。类似的，安全完整性等级3和4对于每项技术的要求也是一样的。这些要求是：

“M” 表示某个技术须强制使用；

“HR” 表示该技术或方法在该安全完整性等级下是强力推荐。如果该技术或方法没有使用，那么没有使用的

理由需要在“安全质量保障计划”或“安全质量保障计划”参考的其他文档中给出；

“R” 表示该技术或方法在该安全完整性等级下是推荐使用。其低于“HR”的推荐度，并且这些技术可以组

合使用。

“-” 表示该技术或方法既不推荐使用或也不反对使用；

“NR” 表示该技术或方法在当前安全完整性等级下是肯定不推荐的。如果该技术或方法被使用，那么使用的

理由需要在“安全质量保障计划”或“安全质量保障计划”参考的其他文档中给出。

除非表格的附注有其他要求，一个或多个选定的技术或措施及其组合需在“安全质量保障计划”或“安全质量保障计划”参考的其他文档中加以说明。这些附注包括参照的经核准的技术或技术组合。如果这些技术或技术组合被使用，那么评估者需认为它们是有效的并仅需要关心它们是否得到正确应用。如果不同的技术得到使用并被证明合理，则评估者可以认为这是可接受的。

38

同济大学、铁道科学研究院标准所 EN50128：2001

条款表格

表格A.1 – 生命周期（条款7）

文档 软件安全完整软件安全完整软件安全完整软件安全完整软件安全完整性等级0 1.软件计划文档 2.软件需求文档 3.软件设计文档 4.软件模块文档 5.源代码和文档 6.软件测试报告 7.软件和硬件集成测试报告 8.软件确认报告 9.软件评估报告 10.软件维护记录 需求： 符合EN ISO 9000-3蕴涵了对于各种软件安全完整性等级都要形成充足的文档。对于软件安全完整性等级0，设计者应选择适当的文档类型。 表格A.2 – 软件需求规格说明书（条款8）

技术/方法 参考条软件安全目 完整性等级0 1.形式化方法,包括如B.30 - 软件安全完整性等级1 推荐 软件安全完整性等级2 推荐 软件安全软件安全完完整性等整性等级4 级3 强力 推荐 D.7 推荐 推荐 推荐 强力 推荐 3.结构化方法,包括如B.60 推荐 强力 推荐 强力 推荐 强力 推荐 强力 推荐 强力 推荐 强力 推荐 推荐 推荐 - - 推荐 - - 推荐 - 推荐 性等级1 强力推荐 强力推荐 强力推荐 强力推荐 强力推荐 强力推荐 强力推荐 强力推荐 强力推荐 强力推荐 性等级2 强力推荐 强力推荐 强力推荐 强力推荐 强力推荐 强力推荐 强力推荐 强力推荐 强力推荐 强力推荐 性等级3 强力推荐 强力推荐 强力推荐 强力推荐 强力推荐 强力推荐 强力推荐 强力推荐 强力推荐 强力推荐 性等级4 强力推荐 强力推荐 强力推荐 强力推荐 强力推荐 强力推荐 强力推荐 强力推荐 强力推荐 强力推荐 CCS,CSP,HOL,LOTOS,OBJ,时序逻辑VDM,Z和B 2.半形式化方法 JDS,MASCOT,SADT,SDL,SSADM和Yourdon 需求： 1.软件需求规格说明书要求用自然语言和能表示应用的必要的数学符号来描述问题。 2.本表描述了清楚而精确地定义规格说明书的附加需求。应选择表中一些技术来满足使用的软件安全完整性等级。 表格A.3 – 软件体系结构（条款9）

技术/方法 参考条目 软件安全完整软件安全完软件安全完整软件安全完性等级0 1.防御性编程 2.故障检测和诊断 3.纠错码 4.检错码 5.失效断言编程 6.安全袋技术 B.15 B.27 B.20 B.20 B.25 B.54 - - - - - - 整性等级1 推荐 推荐 - 推荐 推荐 推荐 性等级2 推荐 推荐 - 推荐 推荐 推荐 软件安全完整性等级3 整性等级4 强力推荐 强力推荐 - 强力推荐 强力推荐 推荐 强力推荐 强力推荐 - 强力推荐 强力推荐 推荐 39

同济大学、铁道科学研究院标准所 EN50128：2001

7.多版本技术 8.恢复块 9.后向恢复 10.前向恢复 11.重试恢复机制 12.执行路径记忆 13.人工智能-故障纠正 14.软件动态重构 15.软件错误影响分析 16.故障树分析 需求： 1.对于软件安全完整性等级3和4，认可的技术组合如下所示： a）1、7和4、5或12中之一； b）1、4和5； c）1、4和12； d）1、2和4； e）1和4、和15和16之一。 2.除了条目3、9、10、13和14外，应选择表中一些技术以满足软件安全完整性等级1和2的需求。 3.其中一些要点可以在系统层进行定义。 4.纠错码的使用应符合EN 50159-1和EN 50159-2的需求。 表格A.4 – 软件设计和实施（条款10）

技术/方法 参考条目 软件安全完软件安全完软件安全完软件安全完软件安全完整性等级0 整性等级1 整性等级2 整性等级3 整性等级4 1.形式化方法,包括如B.30 - 推荐 推荐 强力推荐 强力推荐 B.17 B.50 B.5 B.32 B.53 B.39 B.1 B.18 B.26 B.28 - - - - - - - - - 推荐 推荐 推荐 不推荐 不推荐 推荐 推荐 不推荐 不推荐 推荐 推荐 推荐 推荐 不推荐 不推荐 推荐 推荐 不推荐 不推荐 推荐 推荐 强力推荐 推荐 不推荐 不推荐 推荐 强力推荐 不推荐 不推荐 强力推荐 强力推荐 强力推荐 推荐 不推荐 不推荐 推荐 强力推荐 不推荐 不推荐 强力推荐 强力推荐 CCS,CSP,HOL,LOTOS,OBJ,时序逻辑,VDM,Z和B 2.半形式化方法 3.结构化方法,包括如D.7 B.60 推荐 推荐 强力推荐 强力推荐 强力推荐 强力推荐 强力推荐 强力推荐 强力推荐 强力推荐 JSD,MASCOT,SADT,SDL,SSADM和Yourdon 4.模块化方法 5.设计和编码标准 6.可分析程序 7.强类型说明的程序语言 8.结构化编程 9.编程语言 10.语言子集 11.已确认的翻译器 12.使用中证明的翻译器 13.可信/已验证的模块库和部件 14.功能和黑箱测试 15.性能测试 D.9 D.1 B.2 B.57 B.61 D.4 B.38 B.7 B.65 B.40 D.3 D.6 强力推荐 强力推荐 强力推荐 推荐 推荐 推荐 - 推荐 强力推荐 推荐 强力推荐 - 强制的 强力推荐 强力推荐 强力推荐 强力推荐 强力推荐 - 强力推荐 强力推荐 推荐 强力推荐 强力推荐 强制的 强力推荐 强力推荐 强力推荐 强力推荐 强力推荐 - 强力推荐 强力推荐 推荐 强力推荐 强力推荐 强制的 强制的 强力推荐 强力推荐 强力推荐 强力推荐 强力推荐 强力推荐 强力推荐 推荐 强制的 强力推荐 强制的 强制的 强力推荐 强力推荐 强力推荐 强力推荐 强力推荐 强力推荐 强力推荐 推荐 强制的 强力推荐 40

同济大学、铁道科学研究院标准所 EN50128：2001

16.接口测试 17.数据记录和分析 18.模糊逻辑 19.面向对象的编程 需求： 1.应根据软件安全完整性等级选择合适的技术集合。 2.在软件安全完整性等级3或4，认可的技术集应包括1、2或3中之一，以及11或12之一。其他技术根据推荐意见处理。

B.37 B.13 B.67 B.68 强力推荐 强力推荐 - - 强力推荐 强力推荐 - 推荐 强力推荐 强力推荐 - 推荐 强力推荐 强力推荐 - 推荐 强力推荐 强力推荐 - 推荐 41

同济大学、铁道科学研究院标准所 EN50128：2001

表格A.5 – 验证和测试（条款11）

技术/方法 参考条软件安全完整软件安全完整软件安全完整软件安全完整软件安全完整目 1.形式化证明 2.概率测试 3.静态分析 4.动态分析和测试 5.度量 6.可追溯性度量 7.软件错误影响分析 需求： 1.对于软件安全完整性等级3或4，认可的技术组合应是： a）1和4； b）3和4；或 c）4、6和7。 2.对于软件安全完整性等级1或2，认可的技术应1或4。

表格A.6 – 软件/硬件集成（条款12）

技术/方法 参考条目 1.功能和黑箱测试 D.3 软件安全完整性等级4 强力推荐 2.性能测试 D.6 - 软件安全完整性等级4 强力推荐 推荐 软件安全完整性等级4 强力推荐 推荐 软件安全完整性等级4 强力推荐 强力推荐 需求： 1.对于软件安全完整性等级0，技术1应是认可的技术。 2.对于软件安全完整性等级1、2、3或4，认可的技术组合应是1和2。

软件安全完整性等级4 强力推荐 强力推荐 B.31 B.47 D.8 D.2 B.42 B.69 B.26 - - - - - - - 性等级0 性等级1 推荐 推荐 强力推荐 强力推荐 推荐 推荐 推荐 性等级2 推荐 推荐 强力推荐 强力推荐 推荐 推荐 推荐 性等级3 强力推荐 强力推荐 强力推荐 强力推荐 推荐 强力推荐 强力推荐 性等级4 强力推荐 强力推荐 强力推荐 强力推荐 推荐 强力推荐 强力推荐 42

同济大学、铁道科学研究院标准所 EN50128：2001

表格A.7 – 软件确认（条款13）

技术/方法 参考条目 软件安全完整性等级0 1.概率测试 B.47 - 软件安全完整性等级1 推荐 软件安全完整性等级2 推荐 强力推荐 强力推荐 软件安全完整性等级3 软件安全完整性等级4 2.性能测试 D.6 - 强力推荐 强力推荐 强制的 强制的 3.功能和黑箱测试 D.3 强力推荐 强力推荐 强力推荐 强制的 强制的 4.建模 D.5 - 推荐 推荐 推荐 推荐 需求: 1.对于软件安全完整性等级1、2、3或4，认可的技术组合应是2和3。

表格A.8 – 需评估的条款

需评估的条款 条款 软件安全完整性等级0 1.软件安全完整性等级 2.人员和职责 3.生存周期和文档 4.软件需求规格说明书 5.软件体系结构 6.设计和开发 7.验证 8.软件/硬件集成 9.软件确认 10.质量保障 11.维护 5 6 7 8 9 10 11 12 13 15 16 强力推荐 - - 推荐 - - - - - - - 软件安全完整性等级1 强力推荐 推荐 强力推荐 强力推荐 推荐 推荐 强力推荐 推荐 强力推荐 强力推荐 强力推荐

软件安全完整性等级2 强力推荐 推荐 强力推荐 强力推荐 推荐 推荐 强力推荐 推荐 强力推荐 强力推荐 强力推荐 软件安全完整性等级3 强力推荐 强力推荐 强力推荐 强力推荐 强力推荐 强力推荐 强力推荐 强力推荐 强力推荐 强力推荐 强力推荐 软件安全完整性等级4 强力推荐 强力推荐 强力推荐 强力推荐 强力推荐 强力推荐 强力推荐 强力推荐 强力推荐 强力推荐 强力推荐 43

同济大学、铁道科学研究院标准所 EN50128：2001

表格A.9 – 软件评估（条款14），评估技术

评估技术 参考条目 软件安全完整性等级0 1.检查列表 B.8 强力推荐 2.静态软件分析 B.14 B.42 D.8 3.动态软件分析 D.2 D.3 4.因果图 5.事件树 6.故障树 B.6 B.23 B.28 推荐 - 推荐 推荐 推荐 推荐 推荐 推荐 推荐 - 推荐 推荐 强力推荐 推荐 推荐 强力推荐 7.软件错误影响分析 B.26 - 推荐 推荐 强力推荐 8.共因失效分析 B.10 - 推荐 推荐 强力推荐 9.马尔可夫模型 10.可靠性方框图 11.交付前现场试验 B.41 B.51 - - - 推荐 推荐 推荐 强力推荐 需求: 1.应选择表中一些技术来满足选用的软件安全完整性等级。

推荐 推荐 强力推荐 推荐 推荐 强力推荐 强力推荐 推荐 推荐 强力推荐 强力推荐 强力推荐 推荐 推荐 强力推荐 推荐 软件安全完整性等级1 强力推荐 强力推荐 软件安全完整性等级2 强力推荐 强力推荐 软件安全完整性等级3 强力推荐 强力推荐 软件安全完整性等级4 强力推荐 强力推荐 44

同济大学、铁道科学研究院标准所 EN50128：2001

表格A.10 – 软件质量保障（条款15）

技术/方法 条款或参考条目 1.EN ISO 9001认证 2.符合EN ISO 9000-3 3.公司质量体系 4.软件配置管理 15 15 15 B.56 软件安全完整性等级0 推荐 强制的 强制的 强制的 强力推荐 强制的 强制的 强制的 强力推荐 强制的 强制的 强制的 强力推荐 强制的 强制的 强制的 强力推荐 强制的 强制的 强制的 软件安全完整性等级1 软件安全完整性等级2 软件安全完整性等级3 软件安全完整性等级4 表格A.11 – 软件维护（条款16）

技术/方法 参考条目 1.后果分析 2.数据记录和分析 B.35 B.13 软件安全完整性等级0 推荐 强力推荐 软件安全完整性等级1 强力推荐 强力推荐 软件安全完整性等级2 强力推荐 强力推荐 软件安全完整性等级3 强制的 强制的 软件安全完整性等级4 强制的 强制的 表格A.12 – 条款10参照的设计和编码标准（D.1）

技术/方法 参考条目 1.存在编码标准 2.编码风格指南 3.无动态对象 4.无动态变量 5.限制使用指针 6.限制使用递归 7.没有无条件跳转 需求: 1.技术3、4和5作为已确认编译器或翻译器的一部分是可以接受的。 2.根据软件安全完整性等级应选择适当的技术集合。

B.16 B.16 B.16 B.16 B.16 B.16 B.16 软件安全完整性等级0 强力推荐 强力推荐 - - - - - 软件安全完整性等级1 强力推荐 强力推荐 推荐 推荐 推荐 推荐 强力推荐 软件安全完整性等级2 强力推荐 强力推荐 推荐 推荐 推荐 推荐 强力推荐 软件安全完整性等级3 强力推荐 强力推荐 强力推荐 强力推荐 推荐 强力推荐 强力推荐 软件安全完整性等级4 强力推荐 强力推荐 强力推荐 强力推荐 推荐 强力推荐 强力推荐 45