IEC 15026-2-13:2017 系统和软件工程——系统和软件保证——第2部分：保证案例

IEC 15026-2-13:2017（同为 ISO/IEC 15026-2:2013，加拿大采纳版 CAN/CSA-ISO/IEC 15026-2-13:2017）是国际标准化组织在系统和软件工程领域针对保证案例（Assurance Case）制定的核心标准。该标准为安全关键系统（如航空、医疗、轨道交通、核能、自动驾驶等）的研制方和评估方提供了一套统一的框架，用以创建、沟通、评估和维护关于系统特定属性（如安全性、可靠性、可用性）的可信论证。

以下将从标准概况、主要技术内容、实施要点以及与其他标准的关系等方面进行详尽分析。

1. 标准概况与适用范围

背景与定位

ISO/IEC 15026 系列标准包括四个部分：概念与词汇（第1部分）、保证案例（第2部分）、系统完整性等级（第3部分）以及生命周期中的保证（第4部分）。IEC 15026-2-13:2017 专门针对保证案例的创建和管理，是系统性构建可信论证的国际标杆要求。

适用范围

该标准适用于任何需要显式论证某类属性满足要求的工程系统，尤其是对安全性、可靠性、信息安全等具有严格要求的临界系统。标准本身不限定具体领域，但特别适用于：

航空电子和空中交通管理系统
医疗设备和健康信息系统
汽车功能安全（ISO 26262 相关）
铁路信号与控制系统
核电安全仪表系统
工业过程控制安全系统

实用提示： 即使标准未强制要求图形化表示法，实际工程中普遍采用 GSN（Goal Structuring Notation）或 CAE（Claim-Argument-Evidence）模式进行建模，这有助于提升保证案例的可读性和审查效率。

2. 主要技术内容与要求

保证案例的定义与核心要素

标准将保证案例定义为“关于系统特定属性（或一组属性）的、包含论据和证据的可信且完整的论证”。其基本构成包括：

主张（Claim）：关于系统属性的陈述，例如“系统能够安全地处理所有失效模式”。
论据（Argument）：连接主张与证据的逻辑推理过程，包括推断规则、策略和理由。
证据（Evidence）：支持主张的具体事实、设计文档、测试报告、分析结果、历史数据等。
上下文（Context）：界定主张有效范围的假设、设计约束、运行条件等。
假设（Assumption）：论证中未经验证但被接受的陈述，需要显式记录。
理由（Rationale）：解释为何特定策略或证据被选用。

表1 IEC 15026-2-13 保证案例核心元素与要求
元素	定义	关键要求
主张（Claim）	对系统某个属性的可论证陈述	清晰、无歧义、可验证
论据（Argument）	支持主张的逻辑推理链条	逻辑一致、可追溯、无循环推理
证据（Evidence）	支持论据和主张的客观事实	可独立审计、可重现、充分覆盖
上下文（Context）	界定主张和论证的范围与假设	完整记录假设与边界条件
理由（Rationale）	解释使用特定策略或证据的原因	说明选择依据，确保透明性

保证案例的内容与结构

标准要求保证案例应包含以下内容：

标识信息：版本、修订历史、作者、审核者。
系统描述：包括功能、边界、接口、运行环境。
保证目标：底层主张及相关的完整性等级。
论证结构：主张分解树、策略选择、证据引用。
评估记录：独立评审结论、遗留风险、未解决的不确定性。

常见误区： 许多团队只提供证据清单而缺少显式论据，这往往导致保证案例无法说服评估者。必须明确阐述“证据为何支持主张”的逻辑链条，不能依赖隐含推理。

评估过程

标准定义了评估保证案例的三方模型：

创建者：负责构建保证案例。
评估者：独立（通常独立于开发团队）审查论证的有效性。
决策者：依据评估结论认可系统是否满足要求。

评估必须检查主张是否被充分论证、证据是否正确且充分、假设是否合理、推理是否无漏洞。评估结果应形成书面记录，包括任何未解决的条件或局限性。

实施益处： 遵循该标准构建的保证案例不仅有助于通过安全认证审查，还能在系统全生命周期中作为沟通工具，使不同专业团队（开发、测试、安全、质量）对齐理解，大幅降低因论证缺失导致的设计返工。

3. 实施与应用要点

构建保证案例的推荐步骤

识别保证目标：从系统安全/可靠要求导出顶级主张。
定义分解策略：选择结构分解（如按子系统、按失效模式、按运行阶段）。
收集并生成证据：包括测试、分析、形式化方法、经验数据等。
构造论证：使用自然语言或图形化表示（如 GSN）连接主张与证据。
组织独立评估：邀请未参与创建的评估者进行审查。
维护与更新：系统变更或发现新证据时及时修订保证案例。

强制性要求： 对于安全完整性等级（SIL）≥3 的系统，标准要求评估者必须独立于开发团队，且保证案例必须覆盖所有相关的失效场景和极端条件，否则认证机构有权拒绝接受。

工具支持与最佳实践

市场上有若干工具支持保证案例的创建和管理，如 AdvoCATE、CERT CAFE、ASM 工具等。建议采用支持版本管理和影响分析的工具，以便高效维护大型保证案例。

常见实践包括为每个关键系统属性建立独立的保证案例，然后通过交叉引用避免重复。此外，将假设定义为可控变量，并在每次评估时重新确认其有效性。

4. 与其他标准的关系

与 ISO/IEC 15026 系列内部关系

第2部分依赖于第1部分提供的术语和概念，与第3部分（系统完整性等级）协同使用以定义主张的严格程度，与第4部分（生命周期中的保证）结合可以覆盖整个系统开发过程中的保证活动。

与领域安全标准的配合

ISO 26262（道路车辆功能安全）：要求建立安全案例，其内容结构可以参照 IEC 15026-2-13 的框架，但需符合 ISO 26262 的具体证据要求（如 ASIL 分解）。
IEC 61508（电气/电子/可编程电子安全系统）：第1部分的第6条明确要求建立安全案例，IEC 15026-2-13 提供了更系统的论证方法。
ISO 14971（医疗器械风险管理）：风险分析报告构成证据主体，结合保证案例可展现剩余风险的可接受性论证。
DO-178C/DO-331（航空软件）：可作为软件等级（DAL）论证的补充，强化工具鉴定和分析过程的可信度。

未来发展与趋势

随着人工智能和自动驾驶的发展，保证案例在应对机器学习安全论证中的作用日益凸显。IEC 15026-2-13 提供的框架可以被扩展用于 AI 安全案例，结合 ISO/IEC TR 5469（人工智能可解释性）等新兴标准。

常见问题 FAQ

问： IEC 15026-2-13 是否强制要求使用特定的图形化表示法（如 GSN）？
答：不强制。标准适用于任何显式、结构化的论证方式，包括纯文本。但实际工程中，使用 GSN 或 CAE 可以显著提高论点的可读性、一致性和可审查性，建议安全关键系统采用。

问：保证案例与安全案例（Safety Case）有什么区别？
答：安全案例是保证案例的一种特例，专门用于论证系统的安全性。保证案例可针对任何属性（如可靠性、信息安全、可用性）。两者的结构和方法论完全一致。

问：如何判断保证案例中的证据是否足够充分？
答：标准建议通过独立评估来检查：证据应能直接支持所对应的主张，且覆盖所有潜在的失效模式和运行条件。实践中需结合领域经验、完整性等级和风险容忍度进行综合判断，必要时引入敏感性分析。

问：该标准是否适用于敏捷开发流程？
答：可以。可将保证案例视为“活文档”，在每个迭代周期中同步更新主张和证据。采用增量式论证构建方法，允许在早期仅建立顶层论证，后续逐步精细化。

📥 标准文件下载

🔒

请等待 10 秒，广告加载完成后将自动显示下载链接