指导性文件
GUIDANCE NOTES
GD11-2015
中 国 船 级 社
船用软件安全及可靠性评估指南
GUIDELINES FOR SAFETY AND RELIABILITY
ASSESSMENT FOR SHIPBOARD SOFTWARE
2015
目录
1
范围及说明 ....................................................................................................................... 1
2
规范性引用文件 ............................................................................................................... 2
3
术语及缩略语 ................................................................................................................... 2
4
计算机系统分类 ............................................................................................................... 5
5
质量体系的要求 ............................................................................................................... 6
6
系统生命周期 ................................................................................................................... 8
7
软件开发生命周期 ......................................................................................................... 14
8
试验和验证 ..................................................................................................................... 39
附录 1 测试和检验的验证表 ...................................................................................................... 41
附录 2 小型低复杂度计算机系统的评估 .................................................................................. 52
附录 3 计算机系统设计和实现阶段的技术建议 ...................................................................... 54
1 范围及说明
1.1 本指南是对船用计算机系统（以下简称计算机系统，包括可编程电子
系统）中软件的可靠性及安全性评估指南，对船用计算机系统中软件的开发、测
试、认证、生产、维护提出了安全及可靠性的技术要求。本指南也对与软件相关
的硬件制定了一些要求，这些要求需与产品的技术要求结合对待。本节适用安装
于入级船舶上，提供符合入级要求的控制、报警、监测或安全功能的计算机系统，
包括可编程电子系统。
1.2 本指南主要关注在软件开发生命周期，对整体安全生命周期中的一些
环节也有所采用。本指南软件开发模型采用 V 模型，相关模型的演化并未包含在
本指南中。
1.3 考虑到小型简单的计算机系统的直接应用和在复杂系统中对部分功能
实现的应用，本指南定义了小型低复杂度计算机系统，并在附录 2 给出了简化的
评估方法。
1.4 在应用本指南时，可根据制造厂内部文件管理系统编制本指南中提到
的文档，但内容应符合指南中提及的相关内容。
1.5 附加标志
1.5.1 对于建立了系统生命周期的计算机系统，依照《钢质海船入级规范》
等要求通过了系统和硬件的认证，并满足了本指南对软件的技术要求，根据其不
同的系统等级（分类见 4.1 条），可授予下列附加标志：
（1）对于 I 类系统，SLC1；
（2）对于 II 类系统，SLC2；
（1）对于 III 类系统，SLC3。
1.6 本指南包括三个附录。其中：
1.6.1 附录 1 是现场验船师进行船用计算机系统中软件的安全及可靠性评
估时使用的测试和检验的验证表。
1.6.2 附录 2 是小型低复杂度计算机系统的评估方法。
1
1.6.3 附录 3 是计算机系统设计和实现阶段的技术建议。
2 规范性引用文件
2.1 下列参考文件对于指南的应用是不可缺少的。凡是注日期的引用文件，
仅引用版本适用。凡是不注日期的引用文件，其最新版本适用于本指南。
引用文件 表 2.1
1. 中国船级社《钢质海船入级规范》（2012）及其修改通 报
2. SOLAS 公约第 II-1 章第 55 条
3. GD01-2006 中国船级社 电气电子产品型式认可试验指南
4. IACS UR E22 可编程电子系统船上使用和应用
5. IEC 61508-1： 2010 电气/电子/可编程电子安全相关系统的功能安全 第1 部 分：一般要求
6. IEC 61508-2： 2010 电气/电子/可编程电子安全相关系统的功能安全 第 2 部分：电气电子/可编程电子安全相关系统的要求
7. IEC 61508-3： 2010 电气/电子/可编程电子安全相关系统的功能安全 第 3 部分：软件要求
8. IEC 61508-4： 2010 电气/电子/可编程电子安全相关系统的功能安全 第 4 部分：定义和缩略语
9. IEC 61508-5： 2010 电气/电子/可编程电子安全相关系统的功能安全 第 5 部分：确定安全完整性等级的方法示例
10. IEC 61508-6： 2010 电气/电子/可编程电子安全相关系统的功能安全 第 6 部分：应用第 2 部分和第 3 部分的指南
11. IEC 61508-7： 2010 电气/电子/可编程电子安全相关系统的功能安全 第 7 部分：技术和措施概述
12. 12. IEC 60092-504： 2001 船舶电气设备 第 504 部分：专辑 控制和测量仪表
13. 13. IEC 60812-2006 系统可靠性分析技术-故障模式影响分析
14. 14. IEC 61025-2006 故障树分析
15. 15. IEEE 730-2014 软件质量保证计划
16. 16. ISO 9000-3 ISO9001 质量保证标准在计算机软件开发、供应、安 装和维护中的应用指南
17. 17. ISO 17894-2005 船舶和海上技术 计算机应用 海上用可编程电子系统 的开发和使用总则
3 术语及缩略语
3.1 术语
2
3.1.1 软件（software）
包括程序、规程、数据、规则以及相关的数据处理系统操作文档在内的智能
创作。
3.1.2 计算机系统（computer system）
以计算机技术为基础，可以由硬件、软件及其输入和（或）输出单元构成的。
注：这个术语包括以一个或多个中央处理器（CPU）及相关的存储器等为基础的微电
子装置。
3.1.3 系统（system）
根据设计相互作用的一组元素，可能包括相互作用的硬件、软件和人等。
3.1.4 子系统（Subsystem）
子系统是一种模型元素，它具有包（其中可包含其他模型元素）和类（其具
有行为）的语义。子系统的行为由它所包含的类或其他子系统提供。子系统实现
一个或多个接口，这些接口定义子系统可以执行的行为。
3.1.5 模块（Module）
程序、分立部件、封装程序的一个功能集、或一组归并在一起的分立部件。
3.1.6 软件模块（Software module）
由规程和（或）数据说明组成的构造，并能与其它这样的构造相互作用。
3.1.7 安全功能（Safety function）
针对特定的危险事件，为达到或保持 EUC 的安全状态，由计算机系统、其
它技术安全相关系统或外部风险降低设施实现的功能
3.1.8 受控设备（Equipment under control（EUC））
用于制造、加工、运输或其它活动的设备、机器、器械和（或）成套装置。
3
3.1.9 小型低复杂度计算机系统（Small low complexity computer system）
一种计算机系统,其中：已很好确定了每个部件的失效模式；能完全确定在
故障情况下的系统行为。
注：在故障状态下系统行为可用试验和（或）分析的方法确定。
3.1.10 动态测试（Dynamic testing）
用系统的和受控的方式执行软件和（或）操作硬件以证明所要求的行为的存
在以及非要求行为的不存在。
3.1.11 质量计划（Quality plan）
针对特定的软件产品、软件项目所规定的质量措施、资源和活动顺序的文件。
描述相关质量标准并且说明如何满足相应标准的一系列文件。
3.1.12 系统生命周期（System lifecycle）
系统实现过程中所必需的生命活动，这些活动发生在从一项工程的概念阶段
开始，直至所有的计算机系统及其相关停止使用为止的一段时间内。
3.1.13 软件生命周期（Software lifecycle）
从软件开始构思到软件永久停用期间的活动。
注：一个典型的软件生命周期包括需求、开发、测试、集成、安装和修改等阶段。
3.1.14 软件配置管理（Software Configuration Management，SCM）
是一种标识、组织和控制修改的技术。软件配置管理应用于整个软件工程过
程。
3.2 缩略语
3.2.1 ISO：International Organization for Standardization，国际标
准化组织。
4
3.2.2 IEC：International Electrotechnical Commission，国际电工委
员会。
3.2.3 IEEE：Institute of Electrical and Electronics Engineers，电
气电子工程师学会。
3.2.4 FMEA：Failure Mode and Effects Analysis，故障模式影响分析。
3.2.5 FMECA：Failure Mode, Effects and Criticality Analysis，故障
模式及影响分析和危害性分析。
3.2.6 FAT：Factory Acceptance Test，工厂验收试验。
3.2.7 PE：Programmable Electronic，可编程电子。
4 计算机系统分类
4.1 按照故障的影响并考虑系统提供的功能，应参照表 4.1 将计算机系统
分为 3 类，分别是 I、II、III 类。分类过程中，应按最严酷环境进行影响分析。
计算机系统分类 表 4.1
类别 影响 系统功能
I 这些系统的故障不会对人员的安全、船舶的安 全以及环境产生危害 ——监视功能和日常管理功能
II 这些系统的故障最终会对人员的安全、船舶的 安全以及环境产生危害 ——监视和报警功能 ——对保持船舶处于正常运营和起居状况 所必要的控制功能
III 这些系统的故障即刻会对人员的安全、船舶的 安全以及环境产生危害 ——保持船舶推进和操舵的控制功能 ——安全功能
4.2 在表 4.2 中，举例说明了一些计算机系统的分类供制造商参考。
系统分类举例 表 4.2
系统类别 举例
I 维修保养支持系统 日常信息处理
II 监视和报警装置 液柜容量测量设备 辅机控制系统
5
主推进装置遥控系统 探火和灭火系统 舱底水系统 调速器
III 机械保护系统或设备 燃烧器控制系统 内燃机的电子喷油器 推进和操舵控制系统 发电机同步单元
5 质量体系的要求
5.1 质量保证体系
5.1.1 应通过质量保证体系证明制造厂具有一定的产品质量保证能力和质
量管理水平，以及制造厂制定了能确保产品符合本社规范及相关公约的管理制度。
5.1.2 制造厂应建立并实施 ISO9001 或等效标准的质量管理体系并持有有
效证书。按照 ISO9001 的要求，制造厂应对其管理活动、资源提供、软件产品实
现和测量、分析和改进有关的过程进行控制。
5.1.3 II、III 类系统的制造厂还应满足 ISO9000-3 的适用要求。
5.2 软件质量计划
5.2.1 制造厂应制定针对软件开发生命周期的质量计划。
5.2.2 软件质量计划应规范该软件整个生命周期的活动，明确相关程序、
职责和系统文件，包括配置管理。所制定的质量计划可参照 IEEE 730 的要求。
5.2.3 对于 II、III 类系统的软件，质量计划中应包含安全功能要求部分，
应设计具体保证方法，以验证和确认安全功能要求是否得以满足。
5.2.4 在软件开发生命周期阶段中，应制定船用计算机系统的配置管理，
详见 5.6 条。
5.3 生产中质量控制
5.3.1 通过切实可行的质量保证措施、计划和组织，确保产品的质量。
6
5.3.2 制造厂应具有针对产品的质量控制文件，该质量控制文件应准确描
述产品的生产工艺流程，并用文字以及图表清晰描述各工艺流程的质量控制要求；
还应包含明确的控制对象、控制标准、控制方法及检验方法和生产质量保证措施
落实的证明文件。对于安全相关功能的产品，还要求提供通过“试验和模拟”的
证明文件。
5.4 最终的试验报告
5.4.1 制造厂应对产品进行最终测试并提供报告。最终的试验报告是根据
成品试验和试验结果记录生成的报告。
5.5 软件可追溯性
5.5.1 软件可追溯性要求：必须按程序对编程内容和数据的修改以及版本
的变化进行标识并文档化。确保在需要时对软件产品质量形成过程实行可追溯。
通过软件配置管理及软件版本说明等质量保证文件，明确编程内容、数据的修改
以及版本的变化所必须遵循的流程，并确定在文件中记录这些修改或变化。
5.5.2 这些文件至少应保存至软件开发生命周期结束后一年。制造厂应有
明确证据证明该软件确实退役。
5.6 配置管理
5.6.1 配置管理的目的是为了保证当某些可交付项有改变时，几种开发的
可交付项的一致性。一般来讲，配置管理包括硬件配置管理和软件配置管理。
5.6.2 要求：
(1) 在软件开发生命周期阶段中应使用行政和技术控制，以管理软件变
化和保证有关软件安全的规定要求始终能得到满足。
(2) 应确保所有必需的操作已被执行以说明获得了所要求的软件需求。
(3) 应保持精确的和维护计算机系统完整所必需的所有配置项的唯一
识别。配置项至少包括：安全分析和要求；软件规范和设计文档；
软件源代码模块；应用于计算机系统软件组件和软件包的测试计划
和测试结果；所有用于创建、测试或执行计算机系统软件的工具和
开发环境。
7
(4) 应采用变更控制规程来防止非授权的修改，修改请求应文档化；分
析建议修改的影响以批准或拒绝请求；对所有准许修改的细节和授
权应文档化；确保所有软件基线的构成（包括早期基线的重建）。
(5) 应对配置状态、发布状态、所有修改的判断和通过、修改的细节等
信息文档化以便接受审核。
(6) 软件的发布应正式文档化。软件的主要备份和所有有关文档在已发
布软件开发生命周期内应被保存以维护和修改。
6 系统生命周期
6.1 系统生命周期的划分
6.1.1 系统生命周期划分为五个阶段，分别为概念、需求、实现、验证、
运行。每个阶段根据目的范围的不同又做了划分，其关系和要求见下表和图：
A1 概念

B1 需求分析

B2 风险分析
C1 计划编制
C2 软件实现 (软件开发生命周期)
C3 硬件实现
C4 整体安装 和试运行

D1 型式试验
D2 工厂验收试验
D3 船上试验
E1 操作、 维护、修理



E3 停用或处理
图 6.1.1 系统生命周期
8
系统生命周期概述 表 6.1.1
系统生命周期阶 段 目的 要求 输入 输出
图 6.1.1 的方 框号 标题
A 概念
A1 概念 提高对受控设备及其 环境（实际的、法律的 等）的理解水平，以满 足执行其生命周期活 动的需要。 对受控设备及其要 求的控制功能和实 际环境进行全面的 了解；确定可能的 危险源；获取确定 危险的有关信息； 获取当前的安全法 规；考虑相邻近的 受控设备之间相互 作用所产生的危 险；以上所要求的 信息和结果应文档 化。 满足该条要 求所必需的 所有有关信 息 从概念至 整体范围 获取的信 息
B 需求
B1 需求分 析 在新建或修改计算机 系统时描写新系统的 目的、范围、定义和功 能时所要做的所有的 工作。包括： 确定计算机系统的边 界； 规定风险分析的范围。 从概念至整 体范围获取 的信息 计算机系 统要求规 范
B2 风险分 析 （仅针 对安全 相关功 能） 为了保证计算机系统 的安全可靠性，证明对 于单一故障，系统进入 故障安全状态，并且运 行中的系统不会丢失 或降低到不能满足船 级社规定的可接受性 能标准。 应采取适当的方法 进行分析，如： ——故障树分析； ——风险分析； ——FMEA 或 FMECA 分析 计算机系统 要求规范 安全相关 功能要求 规范（含安 全要求分 配的信息 和记录）
C 实现
C1 计划编 制。 在规定规程上和技术 上步骤，证明计算机系 统满足安装、操作和维 拟定计算机系统的 安装、操作和维护 计划，以确保在操 计算机系统 要求规范； 安全相关功 软件质量 计划； 计算机系
9
护要求。 作和维护过程中保 持所要求的功能安 全。 拟定 FAT 试验大纲 和船上试验大纲， 大纲中需包括安全 相关功能试验。 能要求规 范。 统安装、操 作和维护 计划； 型式试验 大纲； FAT 试验大 纲； 船上试验 大纲。
C2 软件实 现 建立符合计算机系统 要求规范和安全相关 功能要求规范的计算 机系统软件。 详见第 7 章软件开 发生命周期。 计算机系统 要求规范 每个计算 机系统满 足计算机 系统要求 规范的证 实。详见第 7 章软件开 发生命周 期。
C3 硬件实 现 建立符合计算机系统 要求规范和安全相关 功能要求规范的计算 机系统硬件。 计算机系统 要求规范。 每个计算 机系统满 足计算机 系统要求 规范的证 实。
C4 整体安 装和试 运行 安装计算机系统； 试运行计算机系统。 计算机系统 安装、操作 和维护计划 已安装就 绪的计算 机系统； 经充分试 运行过的 计算机系 统。
D 验收
D1 型式试 验 确认计算机系统满足 计算机系统要求规范 （包含安全相关功 能）； 确认系统满足 GD01-2006 的要求。 按 GD01-2006 进行 试验。 计算机系统 要求规范； 安全相关功 能要求规 范； 型式试验大 纲。 确认计算 机系统满 足安全相 关功能要 求的证实。 型式试验 报告。
D2 FAT 试验 对计算机系统在工厂 进行测试 FAT 报告应记录① 使用的工具和设 备；②FAT 活动的 计算机系统 要求规范； FAT 试验大 FAT 试验报 告。
10
记录；③实际结果 和预期结果的差异 及处理。 当预期结果和实际 结果出现差异时， 应经分析和评估确 定是继续测试还是 提出变更请求。 纲。
D3 船上试 验 通过船上试验，验证所 有系统互连后，系统执 行预定功能的能力。船 上试验 ，包括完全系统试验和 集成试验。 完全系统试验应验 证在实际硬件部件 及最终应用软件的 条件下，功能可以 正常实现。 集成试验应验证所 有系统集成状态下 的功能可以正常实 现。 计算机系统 要求规范； 船上试验大 纲。 船上试验 报告。
E 运行
E1 操作、维 护、修理 为保持要求的功能安 全，操作、维护和修理 计算机系统。 计算机系统 安装、操作 和维护计划 可持续满 足计算机 系统所需 的功能； 按时间排 序的计算 机系统的 操作修理 和维护文 档。
E2 变更 在变更阶段中及阶段 后保证计算机系统受 控。 变更应返回生命周 期合适阶段，并加 以验证。记录应文 档化。 制造厂应对修改 进行记录。对II、 III系统的软件和 硬件进行的后续 重大修改应提交 给船级社进行批 准。 应提前告知对已 批准系统的修改 和变更方案，并 计算机系统 要求规范 软件质量计 划 相应阶段的 试验大纲 在变更阶 段中及阶 段后，均可 达到计算 机系统要 求的功能 安全； 按时间排 序的计算 机系统的 操作、修理 和维护文 档。
11
进行影响分析， 同时修改应获得 船级社批准。 修改后的软件应 进行变更验证以 证明满足相关计 算机系统要求。 注：重大修改指影 响船舶安全行驶和 /或安全的修改。
E3 停用或 处理 在受控设备的停用及 处理活动中及活动后， 保证计算机系统的功 能安全适应这种情况。 在进行停用或处理 活动之前应进行影 响分析，并制定一 个计划，包括系统 的关闭、系统的拆 除。在计算机系统 使用说明书中提示 对敏感信息的销毁 和处理。 根据功能安 全管理规程 对停用或处 理的请求
6.1.2 在应用本指南时，可根据制造厂内部文件管理系统编制本指南中提
到的文档，但内容应符合指南中提及的相关内容。
6.1.3 下面将对系统生命周期中上表中需补充的内容单独列出。
6.1.4 软件开发生命周期将在第 7 章详述。
6.2 维护阶段的软件安全
6.2.1 目的
在维护阶段达到软件安全的要求。
6.2.2 要求
(1) 程序和数据的修改，以及版本的改变，要被记录并提交我社批准。
(2) 保证软件开发生命周期活动的相应责任部门的规程能胜任其活动，
尤其应满足以下要求：
① 对工作人员进行针对诊断和修复故障以及系统测试的培训；
12
② 操作人员的培训；
③ 对工作人员进行定期再培训。
(3) 与软件开发生命周期的任何活动有关的人员的培训、经验和资格都
应文档化。
(4) 保证危险事故（或产生危险的潜在事故）分析，以及提出使其重复
发生的概率降到最低的建议的规程。
(5) 对操作和维护性能进行分析的规程，尤其是：
① 识别危及功能安全的系统故障的规程，包括用于检测重复性故
障的日常维护所使用的规程；
② 评估需求率和在操作和维护期间的失效率是否和系统设计期间
的假设一致。
(6) 启动对安全相关系统进行修改的规程。
(7) 进行修改所需要的批准规程和主管部门。
(8) 保持潜在危险和安全相关系统信息准确的规程。
(9) 在软件开发生命周期中，计算机系统的配置管理，尤其要对以下各
项进行规定：
① 实现配置控制的规程；
② 用于对一个配置管理项（硬件和软件）的全部要素进行唯一标
识的规程；
③ 防止未授权项进入服务的规程。
(10) 在适当场合的培训条款和应急服务信息
(11) 操作者应建立接收，记录，解决，跟踪问题和修改请求的程序。
问题应按问题处理程序处理。应建立和保持系统操作计划，包括识
13
别配置项，操作规程和预期的维护活动。计划应包括软件迁移和退
休问题。
(12) 系统和/或组件版本的每一个新的升级、发布或修改，操作者应进
行测试。并且，发布操作使用的组件应满足指定的标准。如果发布
部件的接口已被修改，测试应包括集成测试。
(13) 应定期进行配置审核，来验证操作配置的完整性。
6.2.3 输入
(1) 计算机系统使用说明书
(2) 软件质量计划
(3) 风险分析及预防规程
(4) 在适当场合的培训条款和应急服务信息
6.2.4 输出
程序和数据的修改及版本变更的记录
7 软件开发生命周期
7.1 制造厂应制定针对软件开发生命周期的质量计划。应在软件的生命周
期中使用行政和技术手段加以控制，以便于管理软件变化和保证有关软件安全方
面的要求得到满足，证明制造厂存在有效的、能够满足软件开发生命周期的各阶
段的质量控制程序。
7.2 软件质量计划应包含以下内容：
7.2.1 软件开发生命周期应满足第 5.2 条的要求。
7.2.2 在软件开发生命周期阶段中，船用计算机系统的配置管理，特别是
在：
(1) 对于特定的阶段，即将执行正式的配置控制节点；
14
(2) 用来唯一识别某项（硬件和软件）所有构成部分的规程；
(3) 阻止非授权项进入服务的规程。
7.2.3 软件开发生命周期的划分及关系请见下图和表。
软件开发生命周期 计算机系 软件要求规范 软件质量计划
软件配置管理
统的需求 软件的设计和开发 软件确认计划 计算机系统的集成 （软件和硬件） 维护阶段的 软件安全
软件验证 质量保证体系 验证
图 7.2.3-1 软件开发生命周期
15
计算机系统需求
软件需求
软件设计及开发 PE系统集成 （软件和硬件）


计算机系统结构
硬件需求
硬件设计及开发
PE系统
软件
开发
生命
周期
范围
图 7.2.3-2 软件开发生命周期的范围及外部关系
计算机系统 要求规范
计算机系统 结构
输出 软件要求 规范
确认测试
软件结构
计算机系统 集成测试
软件系统 设计 集成测试

模型设计 模型测试

验证
编码
图 7.2.3-3 软件开发生命周期模型（V 模型）
注：除 V 模型外，本指南亦接受其他经本社同意的软件开发生命周期模型。
7.3 软件要求规范
7.3.1 目的
16
(1) 根据系统功能要求规定软件要求规范；
(2) 对每个需实现一定安全功能的计算机系统规定软件安全功能的要
求；
(3) 规定每一个计算机系统对于软件集成的要求。
7.3.2 要求
(1) 软件的开发人员应复审 7.3.1 中的信息以确保对要求全面规定，应
特别考虑以下环节：
① 安全功能；
② 系统配置或构成；
③ 硬件要求；
④ 软件要求；
⑤ 能力和响应时间性能；
⑥ 设备和操作人员界面。
(2) 在要求的系统类别等级范围内，软件安全的规定要求应得到表达和
组织，以使其：
① 清楚、准确、不含糊、可验证、可测量、可维护、可行；
② 可回溯到计算机系统的安全要求的规定；
③ 不使用不明确的或在软件开发生命周期任一阶段使用这些文档
的人所不能理解的术语和描述。
(3) 如果没有详细定义计算机系统的特殊安全要求，所有 EUC 的有关
操作模式应在软件安全的特殊要求中详细说明。
(4) 软件要求规范应对软件和硬件间的任何与安全有关的或相应的约
束进行规范并文档化。
17
(5) 在计算机系统硬件结构设计规范的范围内，软件要求规范应考虑如
下内容：
① 软件自监视；
② 可编程电子硬件、传感器和执行器的监视；
③ 在系统运行时对安全功能进行的周期测试；
④ EUC 可操作时，能够对安全功能进行测试。
(6) 软件要求规范应将计算机系统的非安全功能和安全功能清晰区分。
(7) 软件要求规范将表示出产品要求的安全属性，但不是工程项目的安
全属性。
7.3.3 输入
计算机系统要求规范
7.3.4 输出
软件要求规范
7.4 软件确认计划
7.4.1 目的
根据软件要求规范编制软件确认计划。
7.4.2 编制要求
(1) 软件确认计划应考虑：
① 确认时的细节问题。
② 执行确认的人员的细节问题。
③ EUC 操作的有关模式的识别应包括：
18
——使用的准备，包括设置和调整；
——启动、教学、自动化、手动、半自动化、操作的稳定状态；
——重置、关机、维护；
——合理的可预见异常条件。
④ 在开始试运行前，需要确认 EUC 操作的每一模式软件的识别。
⑤ 确认的技术路线（如分析方法、统计测试等） 。
⑥ 用于确定符合软件功能规定要求的每一功能的措施和规程。
⑦ 软件要求规范要求的特殊参考。
⑧ 确认活动所需要的环境（如测试将包括调校工具和设备）。
⑨ 通过/失败准则。
⑩ 评价确认记录，特别是评价失效的方针和规程。
(2) 确认软件的技术战略应包括下列信息：
① 手动或自动技术选一或选二；
② 动态或静态技术选一或选二；
③ 分析或统计技术选一或选二。
(3) 完成软件确认的通过/失败准则应包指：
① 要求的输入信号及其次序和值；
② 预期的输出信号及其次序和值；
③ 其他可接受的准则，如内存使用、定时、值的允许偏差。
7.4.3 输入
19
软件要求规范
7.4.4 输出
软件确认计划。
7.5 软件的设计与开发
这部分应描述软件开发生命周期中软件设计与开发活动。
7.5.1 软件结构和编码语言要求
(1) 目的
① 软件结构：
创建软件结构以满足不同系统等级对软件安全规定要求。
复审和评价计算机系统硬件对软件的要求，包括计算机系统中软
件和硬件相互作用对 EUC 安全性的影响。
② 编码语言要求：
在用于辅助验证、确认、评价和修改软件的整个生命周期中，根
据要求的系统等级选择合适的集成工具，包括语言和编译器。
(2) 软件结构的要求
软件结构是定义软件主要组件和子系统，包括它们如何实现内部连
接，如何获得所要求的属性，特别是安全完整性。主要软件组件包
括操作系统、数据库、大型设备输入/输出子系统、通信子系统、应
用程序、编程和诊断工具等。
计划的软件结构设计将由软件供方和/或开发人员来建立，软件结构
设计的描述应详细，描述将包括：
① 在所需的软件开发生命周期中，按不同等级的系统，选择和判
断满足软件要求规范的集成技术和措施集。这些技术和措施包
20
括故障允许偏差（与硬件一致）和故障避免的软件设计策略，
（适用时）冗余和多样性。
② 根据组件/子系统的划分，对每一部分应提供以下信息：
——它们是否是新的、已存在的或专利的；
——它们是否已被验证，如果是，它们的验证条件；
——每一个组件/子系统是否与安全有关；
③ 确定所有软件/硬件相互作用和评价及细化它们的重要性。
④ 使用符号表示法表示清楚定义的或限制清楚定义特性的结构。
⑤ 选择用于保持所有数据安全完整性的设计特征。这种数据可包
含大型设备输入/输出数据、通信数据、操作界面数据、维护数
据和内部数据库数据。
⑥ 规定适当的软件结构集成测试来保证软件结构满足规定系统等
级上的软件安全要求。
(3) 支持工具和编程语言的要求
① 对于使用有限可变语言的用户应用程序编程，在一个低安全完
整性等级下，要求的工具和编程语言可被限定为标准 PLC 语言、
编辑器、加载器。其符合性的责任主要由供方承担。
② 在较高等级的系统上，需限制 PLC 语言的子集，验证和确认工
具如代码分析器和仿真器等。在这些环境下责任由供方和用户
共同承担。
③ 即便是在低等级的系统上，也成广泛使用完全可变性语言的嵌
入应用工具，符合性的责任主要由软件开发人员来承担。这包
括使用完全可变语言为用户应用程序编程提供低可变语言的
PLC 供方。
21
④ 根据软件开发的固有特性，确保以下(a)~(d)要求的符合性要求的
责任由供方或用户单独承担，或由两者共同承担，责任的划分
应在安全技术编制中文档化。
(a) 一套合适的集成工具，包括语言、编译器、配置管理工具、
应用时的自动测试工具，应根据要求的系统等级选择。应考
虑在计算机系统整个生命周期中提供相应服务的合适的开
发工具（不是那些在系统开发的初始阶段期间使用的）的可
用性。
在安全完整性等级要求的范围内，程序编程语言选择应：
具备有国家标准或国际标准认可的确认证书的翻译器/编译
器，或对其目的的适宜性建立评估；
完全并清楚地定义或限制清楚定义特性；
与应用的特征匹配；
包括方便探测程序错误的特性；
支持与设计方法匹配的特性。
(b) 当不能满足①时，软件结构设计规范中应记录另一种可选
择语言的理由，理由应足够详细说明语言目的的适宜性和任