EN50128中文版.doc

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

铁路应用——通信、信号和处理系统——铁路控制和防护系统软件

2007.6
91
序言
本欧洲标准是SC 9XA,即通信，信号传输和处理系统技术委员会（CENELEC TC 9X）制订，铁路电气和电子应用的标准。草案文本作为EN 50128正式提交投票并于2000-11-01获得CENELEC批准。
修改了下列日期
--欧盟各国必须通过认可或发布相同的国家标准来执行本欧洲标准的截止日期 2001 -1 1-01
--与本欧洲标准冲突的国家标准必须被废止的截止日期 2003-1 1-01
本欧洲标准必须与EN50126铁路应用——可靠性，可用性，可维护性和安全性（RAMS）；EN50129铁路应用——信号领域的安全相关电子系统同时阅读。
附件中指定的“规范性的”是本项标准主体的一部分。
附件中指定的“参考性的”只用于获得的信息。
本项标准中，附件A是规范性的而附件B是参考性的。

目录
引言
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输入文档
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输入文档
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——通用系统开发和应用开发之间的关系

引言
本标准是相关标准系列中的一部分。其他标准有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） 自顶向下的设计方法；
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中给出。
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,铁路应用——通信，信号和处理系统
第一部分：封闭传输系统中的安全通信；
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）
与期望的设计相背离，并有可能导致未预料到的系统行为或失效。
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）
负责证实安全相关系统适于工作并符合法令、规章规定的安全性需求的实体。
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 为遵从本欧洲标准，应表明依据规定的软件安全完整性等级每一项需求都已得到满足，因而也满足条款的目标。
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 如没有进一步防范措施，软件安全完整性等级至少等于系统安全完整性等级。然而，如果存在能预防软件模块失效导致系统进入不安全状态的机制，则可以减低模块的软件安全完整性等级。5.2.4 应考虑的风险与下列危险后果有关：
· 失去生命；
· 使人受伤或生病；
· 环境的污染；
· 财产损失或损坏。
5.2.5 风险可被定量化，但不能以同样方式规定软件安全完整性。因此，对于本欧洲标准，软件安全完整性等级被指定为下列五个等级之一：
软件安全完整性等级 软件安全完整性等级描述
4 非常高
3 高
2 中等
1 低
0 非安全性 
5.26 在软件需求规格说明书中应指定软件安全完整性等级(条款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 应在软件质量保证计划中记录上述子条款要求的论证，适当的包括能胜任下列领域工作的证据：
· 适合应用领域的工程；
· 软件工程；
· 计算机系统工程；
· 安全工程；
· 法规框架。
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 根据安全主管机构的意见，评估员可以是供应商组织或客户组织的一员，在这种情况下，评估员应：
Ÿ 由安全主管机构授权；
Ÿ 完全独立于项目梯队；
Ÿ 直接向安全主管机构报告
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确定的各种文参考文献文档之间的关系可以用文档交叉参考表来定义。对于表中文档列的各文档，通过从包含符号“n”的单元格开始水平和垂直地阅读可以发现与创建文档有关的阶段和条款。通过从标记为符号“◆”的单元格开始垂直地阅读可以发现应用文档阶段。条款或文档定义参考的其他参考文献可以在“定义的地方”列中找到。如给出条款，后继条款应被检查，因为它们可能包含进一步信息。还要注意的是：因软件配置管理计划需要的参考文献列在括号内，因为该条款只不过参考EN ISO 9001。
文档对照表
条款
标题
8
9
10
11
12
13
14
15
16
SRS
SA
SDD
SVer
S/HI
SVal
Ass
Q
Ma
阶段
（*）=和其他阶段平行

定义出处
文档

系统输入

t

t
t

系统需求规格说明书
EN50129附件B.2.3
t
t

t
t
t
t

系统安全需求规格说明书
EN50129附件B.2.4
t

t

系统结构描述
EN50129附件B.2.1

系统安全性计划
EN50129、 EN50126
软件计划(*)

t
t
t
t

t
t
n

软件质量保证计划
15.4.3

t
t
n

软件配置管理计划
(15.4.2)

n

t
t

软件验证计划
11.4.1

n

t
t

软件集成测试计划
11.4.5

n
t
t

软件/硬件集成测试计划
12.4.1

n
t

软件确认计划
13.4.3

t

n
软件维护计划
16.4.3

数据准备计划
17.4.2.1

数据测试计划
17.4.2.4
软件需求

n
t
t
t
t
t
t

软件需求规格说明书
8.4.1

应用需求规格说明书
17.4.1.1
n

t
t
t
t

软件测试规格说明书
8.4.13

n

软件需求验证报告
11.4.11
软件设计

n
t
t
t
t
t

软件结构规格说明书
9.4.1

n
t
t
t
t

软件设计规格说明书
10.4.3

n

软件结构和设计验证报告
11.4.12
软件模块
设计

n
t
t
t
t

软件模块设计规格说明书
10.4.3

n
t
t
t
t

软件模块测试规格说明书
10.4..14

n

软件模块验证报告
11.4..13
编码

n
t
t
t
t

软件源代码

n

t
t

软件源代码验证报告
11.4.14
模块测试

n
t

软件模块测试报告
10.4.14
软件集成

n

软件集成测试报告
11.4.15

数据测试报告
17.4.2.4
软件/硬件集成

n

软件/硬件集成测试报告
12.4.8

确认(*)

n

软件确认报告
13.4.10
评估(*)

n

软件评估报告
14.4.9
维护

n
软件修改记录
16.4.9

n
软件维护记录
16.4.8
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 软件需求规格说明书应使用让系统整个生命周期所涉及、负有责任的人员都能理解的表达和描述方法。
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 输入文档
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) 对于软件安全完整性等级0，不需进一步防范措施即可使用商用软件；
ii) 如果商用软件使用于软件完整性等级1或2，则它应被包含在软件确认过程中；
iii) 如果商用软件使用于软件完整性等级3或4，则应采取以下防范措施：
a) 商用软件应进行确认测试;
b) 应进行可能失效的分析；
c) 应确定一个策略来检测商用软件的失效并防护系统免受这些失效影响；
d) 防保护策略应是确认测试的主题；
e) 应有错误日志并对其进行评估；
f) 就实用性而言，应仅使用上商用软件的最简单功能。
9.4.6 如果要将以前开发的软件作为设计的一部分使用，那么应有清楚的标识。并用文件证实。软件结构规格说明书应论证软件在满足软件需求规格说明书和软件安全完整性等级方面的适宜性。必须仔细考虑任何软件的修改对系统剩余部分的影响，以决定是否需要再审查和再评估。应有证据表明没有进行再检验，再确认和再评估的和其他模块的接口规格说明书得到遵循。
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 获得可分析、可测试、可验证和可维护的软件。此阶段还包括模块测试。由于验证和测试在确认过程中起关键作用，所以在设计和开发