FS-17 功能安全ISO26262之敏捷开发融合深度解析

FS-17 功能安全ISO26262之敏捷开发融合深度解析

本文基于ISO 26262第三版Working Draft（WD）中Annex E（敏捷开发指南）草案内容，结合Scrum 2020指南与汽车功能安全工程实践，深度解析敏捷开发模式如何与功能安全合规要求相融合。全文涵盖Sprint安全集成、安全扩展Definition of Done、CI/CD安全门控、敏捷追溯性管理、安全基线策略及第三版新增条款等核心技术领域。

**
*图1: ISO 26262第三版敏捷安全融合框架思维导图（Annex E六大支柱）***ISO 26262第三版WD草案（Part 2 Annex E）、ISO 26262-2:2018 Clause 5/8/9、ISO 26262-6:2018 Clause 5-9、Scrum Guide 2020、SAFe 6.0 for Systems and Software Engineering

一、引言：V模型与敏捷开发的根本冲突

1.1 传统V模型在功能安全领域的统治地位

自ISO 26262:2011第一版发布以来，V模型（V-Model）一直是汽车功能安全开发的标准范式。V模型的核心逻辑是"先定义后实现再验证"------左侧自上而下地完成需求分解与架构设计，右侧自下而上地完成集成测试与安全确认。每个阶段都有明确的工作产品（Work Products）和准入准出标准，形成了严格的阶段门控（Phase Gate）流程。

V模型之所以在功能安全领域被广泛采用，根本原因在于其天然的追溯性保障 ：从HARA（危害分析与风险评估）输出的Safety Goal，逐层分解为Functional Safety Requirements（FSR）、Technical Safety Requirements（TSR）、Software Safety Requirements（SSR），最终映射到代码实现和测试用例。这种"瀑布式"的需求追溯链，恰好满足了ISO 26262对**双向追溯性（Bidirectional Traceability）**的强制要求。

1.2 敏捷开发带来的范式冲击

然而，随着汽车软件复杂度呈指数级增长（单车软件代码量已突破1亿行），传统V模型的弊端日益凸显：

• 需求冻结过早：V模型要求在项目初期完成全部需求定义，但汽车软件的实际需求往往在开发过程中持续演进
• 变更成本极高：后期需求变更需要重新走完整的变更管理流程，涉及多轮评审和回归测试
• 反馈周期过长：从需求到验证可能需要数月甚至数年，问题发现滞后
• 文档负担沉重：每个阶段都需要大量文档交付物，团队大量时间花在"为审计写文档"而非"构建安全产品"

与此同时，敏捷开发（Agile Development）------特别是Scrum框架------在IT行业已被证明是应对高复杂度、高不确定性项目的有效方法。其核心优势在于：短周期迭代（Sprint）、持续交付（Continuous Delivery）、快速反馈（Rapid Feedback）、拥抱变化（Embracing Change）。

1.3 核心冲突：安全合规 vs 敏捷速度

当敏捷方法论尝试进入汽车功能安全领域时，几个根本性冲突立即浮现：

维度	功能安全要求	敏捷开发偏好
需求管理	前期完整定义，冻结后严格变更控制	持续演进，拥抱变化
追溯性	双向追溯，每条需求可追踪到代码和测试	轻量文档，代码即文档
验证	完整的V模型右侧，独立验证团队	持续集成，开发者自测
安全案例	结构化论证，完整证据链	工作软件高于文档
配置管理	严格基线控制，变更需审批	持续合并，快速迭代
独立性	高ASIL等级需要独立审核	跨职能自组织团队

图2: 传统V模型与敏捷安全生命周期对比

。ISO 26262第三版Working Draft中的Annex E正是为此而生------它提供了将敏捷实践嵌入功能安全框架的具体路径和约束条件。

二、第三版Annex E：敏捷安全融合的理论框架

2.1 Annex E的定位与适用范围

ISO 26262第三版Working Draft中的Annex E（Informative Annex: Agile Development for Functional Safety）是一个指导性附录，而非规范性要求。它不改变标准的强制条款，而是为采用敏捷开发的组织提供合规路径指引。

Annex E的核心思想可以概括为："Safety activities are embedded in each Sprint, not sequential phases"------安全活动不是被推迟到开发后期，而是嵌入到每个Sprint的日常工作中。

**注意：**截至本文撰写时（2026年7月），ISO 26262第三版仍处于Working Draft阶段，预计2027年正式发布。因此本文所引用的Annex E内容为草案版本，最终发布时可能存在调整。工程实践中应持续关注标准修订动态。

2.2 六大融合支柱

Annex E提出了六大融合支柱（Six Pillars of Integration），构成了敏捷安全融合的理论框架：

1. Iterative Requirements Development（迭代式需求开发）：安全需求不必在Sprint 0全部定义完成，但每个Sprint必须有明确的"需求冻结点"
2. Sprint-Embedded Safety Activities（Sprint内嵌安全活动）：HARA、安全需求分析、FMEA等安全活动以"安全故事（Safety Story）"形式纳入Sprint Backlog
3. Safety-Aware Definition of Done（安全感知完成定义）：扩展标准DoD，增加安全合规验收标准
4. Continuous Traceability（持续追溯性）：利用工具链在每个Sprint自动维护RTM（需求追溯矩阵）
5. Incremental Safety Case Building（增量式安全案例构建）：Safety Case不是最终交付物，而是随每个Sprint增量更新
6. CI/CD with Safety Gates（带安全门控的持续集成）：在自动化流水线中嵌入强制安全门控点

三、Sprint安全集成：将安全活动嵌入迭代周期

3.1 Safety Story的概念与编写

在敏捷安全融合框架中，传统的Safety Activity被转化为Safety Story（安全故事），纳入Product Backlog管理。Safety Story遵循标准用户故事格式，但增加了安全特定字段：
As a Safety Stakeholder,
I want Safety Activity/Requirement,
So that Safety Goal is satisfied / Risk is mitigated.

Acceptance Criteria:

• ASIL Level: A/B/C/D
• Source: SG-XXX / TSR-XXX
• Verification Method: Analysis / Inspection / Test / Simulation
• Safety Mechanism: Description of mechanism
• Coverage Requirement: Statement/Branch/MC/DC %

Safety Story的关键特征是：它必须有明确的安全验收标准（Safety Acceptance Criteria），且这些标准在Sprint Planning阶段就必须被团队理解和接受。

3.2 Sprint Planning中的安全集成

在Sprint Planning阶段，安全集成涉及以下关键活动：

1. Safety Backlog梳理：Product Owner与Safety Manager共同评审Safety Story优先级。优先级排序原则为：高ASIL等级的安全故事优先、有FTTI（Fault Tolerant Time Interval）约束的故事优先、依赖链上游的故事优先。
2. 安全工作量估算：采用Planning Poker等敏捷估算技术，但估算必须包含安全特定活动------如MISRA合规编码时间、安全测试用例编写时间、安全评审时间、文档更新时间。
3. 安全容量规划：团队每个Sprint必须为安全活动预留至少20-30%的容量。对于ASIL D项目，这个比例可能需要提高到40%。
4. 依赖关系识别：安全故事之间的依赖关系必须在Sprint Planning中明确标注，避免"安全机制已实现但安全验证未完成"的情况。

3.3 各角色在安全Sprint中的职责

Scrum角色	标准敏捷职责	+安全扩展职责
Product Owner	最大化产品价值	在Backlog优先级中纳入安全约束，确保高ASIL故事不被低价值功能故事挤占
Scrum Master	移除障碍	确保每Sprint安全流程合规，促进安全评审会议，跟踪安全Metrics
Dev Team	交付增量	安全编码（MISRA C）+ 安全测试，在每个Sprint内完成安全故事的全生命周期
Safety Manager	（传统敏捷中无此角色）	安全Story评审、Safety Case维护、独立安全审核、与TÜV认证机构对接

图3: Sprint周期内嵌安全活动示意图

安全扩展Definition of Done：从代码完成到安全合规

4.1 标准DoD的局限性

标准Scrum的Definition of Done（DoD）通常包括：代码编译通过、单元测试通过、代码评审完成、文档更新、Product Owner验收。这些标准对于一般软件项目已足够，但对于功能安全关键系统则远远不够。

核心问题在于：标准DoD不包含任何安全合规验收标准。一个功能可能"完成"了（代码能跑、测试通过），但完全没有满足ISO 26262的追溯性、覆盖率、安全机制验证等要求。

4.2 Safety-Extended DoD框架

安全扩展DoD在标准DoD基础上增加以下强制验收条件：

类别	验收条件	验证方法	适用ASIL
追溯性	所有安全需求的RTM已更新，双向链接完整	工具自动检查	A/B/C/D
结构覆盖率	达到该ASIL等级要求的覆盖率指标	覆盖率工具报告	B/C/D
编码规范	MISRA C:2012合规，0个Required/Mandatory违反	静态分析工具	A/B/C/D
安全机制	所有新增安全机制的功能测试已通过	测试报告	B/C/D
失效分析	FMEA/FTA已针对本次变更更新	评审记录	C/D
安全案例	Safety Case中相关章节已增量更新	文档评审	C/D
独立评审	ASIL C/D变更需通过独立安全评审	评审签核	C/D
配置管理	代码已按分支策略合并，基线已更新	Git记录	A/B/C/D

关键原则 ：Safety-Extended DoD不是可选的------它是每个Sprint必须满足的最低标准。任何不满足Safety-Extended DoD的Sprint Increment****

图4: 标准DoD与安全扩展DoD对比
**，即使所有标准DoD条件都已满足。

五、CI/CD安全门控：自动化流水线的功能安全约束

5.1 传统CI/CD在安全关键系统中的不足

标准的CI/CD流水线通常包含以下阶段：代码提交 → 静态分析 → 构建编译 → 单元测试 → 集成测试 → 部署。在功能安全关键系统中，这个流程存在几个严重不足：

• 缺少安全门控：流水线可以在安全测试未通过的情况下继续推进到部署阶段
• 覆盖率要求缺失：没有针对不同ASIL等级的结构覆盖率阈值控制
• 编码规范检查不足：MISRA等安全编码规范的检查可能未被集成到流水线中
• 追溯性断裂：流水线不验证需求-代码-测试之间的追溯关系

5.2 三层安全门控模型

在功能安全CI/CD流水线中，应设置三层安全门控（Safety Gates）：

第一层：编码质量门控（Code Quality Gate）

• MISRA C:2012 Required/Mandatory规则0违反
• 代码复杂度指标（Cyclomatic Complexity ≤ 10, Nesting Depth ≤ 4）
• 代码重复率 ≤ 3%
• 安全相关函数必须有完整的Doxygen注释

第二层：结构覆盖门控（Coverage Gate）

ASIL等级	语句覆盖	分支覆盖	MC/DC覆盖
ASIL A	100%	---	---
ASIL B	100%	100%	推荐
ASIL C	100%	100%	推荐
ASIL D	100%	100%	100%（强制）
引用依据：ISO 26262-6:2018 Table 2 --- Recommended/Required techniques and measures for software verification.

第三层：安全验证门控（Safety Validation Gate）

• 所有安全测试用例100%通过
• 残余风险评估已记录并被Safety Manager接受
• Safety Case相关章节已更新
• RTM中无"Unverified"状态的安全需求

5.3 门控失败的处理策略

🔴 强制规则： 任何一层安全门控失败，CI/CD流水线必须立即停止，不允许任何人工绕过。这与标准CI/CD中的"允许手动覆盖"原则完全不同。
门控失败后的标准处理流程：

1. 流水线自动创建缺陷工单（Defect Ticket），标注为Safety-Critical优先级
2. 通知Safety Manager和Scrum Master
3. 团队在下一个Daily Standup中优先讨论安全门控失败原因
4. 修复后重新触发流水线，所有门控从头验证（不允许从失败点继续）

六、敏捷追溯性管理：持续维护的需求追溯链

6.1 追溯性在功能安全中的核心地位

ISO 26262-2:2018 Clause 7.4.3明确要求：组织必须建立和维护追溯关系，确保安全需求从最高层（Safety Goal）到最低层（代码和测试用例）的双向可追溯性。在传统V模型中，这通常在每个阶段结束时通过文档评审来验证；但在敏捷环境中，追溯性必须持续维护、自动验证。

6.2 敏捷追溯性模型

在敏捷环境中，追溯性管理的核心挑战是：如何在快速迭代中保持追溯链的完整性和准确性？
解决方案是采用**"追溯性即代码"（Traceability as Code）**理念：

• 需求ID嵌入代码注释 ：每个安全相关函数/模块的头部注释必须包含对应的需求ID（如 // @req FSR-042, TSR-117）
• 测试用例关联需求：每个测试用例的元数据必须包含被验证的需求ID
• 自动RTM生成：利用工具链从代码注释和测试元数据中自动提取追溯关系，生成RTM
• Sprint结束追溯性验证：每个Sprint结束时，自动检查RTM完整性，标识断裂的追溯链

6.3 RTM（需求追溯矩阵）的敏捷化管理

在敏捷环境中，RTM不再是静态文档，而是活的分析看板（Living Dashboard）。每个Sprint的RTM必须包含以下字段：

字段	说明	更新时机
Req ID	需求唯一标识（如FSR-042）	需求创建时
Source	上层需求来源（如SG-07）	需求分解时
ASIL	ASIL等级（QM/A/B/C/D）	HARA阶段确定
Status	需求状态（Draft/Reviewed/Implemented/Verified）	随开发进展更新
Test Case ID	关联的测试用例	测试编写时
Coverage %	结构覆盖率	测试执行后自动填入
Sprint	实现该需求的Sprint编号	Sprint Planning时
Reviewer	独立评审人	评审完成后
图7: 敏捷环境中的双向追溯性模型

配置管理在敏捷环境中的适配

7.1 传统配置管理 vs 敏捷配置管理

ISO 26262-2:2018 Clause 9要求组织建立配置管理（Configuration Management）体系，确保所有安全相关工作产品的版本可控、变更可追溯。传统配置管理通常采用"大基线"策略------在每个开发阶段结束时建立基线，后续变更需要正式的变更请求（Change Request）流程。
在敏捷环境中，代码每天都在频繁提交和合并，传统的"大基线"策略完全不适用。需要在保持安全合规的前提下，设计适配敏捷节奏的配置管理策略。

7.2 安全分支策略（Safety Branch Strategy）

推荐的敏捷安全分支策略如下：

• main分支（Safety Baseline）：受保护分支，所有合并需要Safety Review审批。代表当前已验证的安全基线。
• release/X.Y分支（Sprint Release）：每个Sprint结束时从main创建，标记为Sprint版本。在安全验证期间冻结，仅接受安全关键修复。
• feature/SG-XXX分支（Safety Story）：每个Safety Story一个特性分支，完成后通过Pull Request合并到main。
• hotfix/SAFETY-XXX分支：紧急安全修复分支，允许加速评审流程，但所有安全门控不可跳过。

7.3 合并控制规则

合并控制规则（安全关键）：

1. 所有合并到main的请求必须附带Safety Review审批
2. 合并请求必须包含更新后的RTM条目
3. 合并后结构覆盖率指标不得降低
4. 自动化MISRA检查必须通过（0违反）
5. Safety Case的增量更新必须记录
6. ASIL C/D级别的变更需要两名独立评审人

八、安全基线管理：增量式冻结策略

8.1 安全基线的概念

安全基线（Safety Baseline）是指在特定时间点，所有安全相关工作产品的已验证、已批准、已冻结的快照 。在传统V模型中，基线通常在每个阶段结束时建立；在敏捷环境中，基线需要以增量方式在每个Sprint结束时逐步建立。

8.2 增量式基线生命周期

安全基线在敏捷项目中的生命周期可分为五个关键阶段：

1. Initial Baseline（初始基线）：Sprint 0/Sprint 1结束时建立，包含HARA输出、Safety Goals、ASIL分配表。这是所有后续安全工作的基础。
2. Sprint 3 Baseline（架构基线）：TSR冻结、系统架构获批。此后架构级变更需要正式变更请求。
3. Sprint 6 Baseline（实现基线）：SSR完成、安全机制验证通过。此后需求级变更需要评估影响范围。
4. Release Baseline（发布基线）：完整Safety Case、所有测试通过、残余风险被接受。这是提交认证审核的基线。
5. Post-release Baseline（发布后基线） ：
   图9: 安全基线生命周期与增量冻结策略
   、变更请求记录、OTA更新安全评估。

8.3 需求冻结点（Requirements Freeze Point）策略

在敏捷安全项目中，"完全冻结"和"完全开放"都不是正确答案。正确的策略是分层冻结（Layered Freezing）：

• Safety Goals（不可变）：一旦HARA完成并通过评审，Safety Goals在整个项目生命周期内不可变更。如需变更，必须重新执行HARA流程。
• TSR（半冻结）：架构基线建立后，TSR变更需要Safety Impact Analysis + 变更审批。允许因实现约束而微调。
• SSR（灵活但有约束）：在实现基线之前，SSR可以在Sprint内调整。但每个Sprint结束时，已验证的SSR被冻结。

九、增量式安全案例构建：从文档到活证据

9.1 安全案例的传统困境

在传统V模型中，Safety Case（安全案例）通常是项目后期的"大文档"------团队在项目接近尾声时集中编写，汇总所有安全证据。这种方式存在严重问题：

• 证据收集滞后：许多安全证据（如测试覆盖率、评审记录）在开发过程中产生，但等到写Safety Case时已经难以追溯
• 集中编写风险高：在最后阶段发现证据缺失或不一致，修复成本极高
• 与敏捷节奏不匹配：敏捷强调持续交付，但Safety Case的"大爆炸"式编写违背了这一原则

9.2 增量式Safety Case模型

在敏捷安全融合框架中，Safety Case采用**"增量构建、持续维护"**模式：

• 每个Sprint更新：每个Sprint结束时，团队将本Sprint产生的安全证据追加到Safety Case的对应章节
• 结构化证据模板：预先定义Safety Case的结构和各章节的证据模板，团队只需按模板填充
• 自动化证据收集：覆盖率报告、MISRA检查结果、测试报告等由工具链自动收集并关联到Safety Case
• Sprint Review中的Safety Case评审：在Sprint Review会议中，包含Safety Case增量更新的评审环节

十、常见陷阱与避坑指南

陷阱一："安全Sprint"反模式

**错误做法：**在常规Sprint之后单独安排"安全Sprint"来补做安全活动。
**正确做法：**安全活动必须嵌入每个常规Sprint，而非集中在特定Sprint。"安全Sprint"会导致安全问题积压到最后，违背了敏捷"早期发现问题"的核心价值。

陷阱二：追溯性只在Sprint结束时补

**错误做法：**开发过程中不维护追溯关系，Sprint结束时集中补录RTM。
**正确做法：**追溯性必须是开发过程的一部分------每次代码提交时通过注释关联需求ID，每次测试编写时关联被验证的需求。

陷阱三：CI/CD安全门控可被手动绕过

**错误做法：**在紧急情况下手动跳过安全门控，先发布后补测。
正确做法： 安全门控是强制的、不可绕过的。如果确实需要紧急发布，应走正式的hotfix流程
图8: 敏捷安全项目配置管理策略

陷阱四：敏捷团队没有Safety Manager角色

**错误做法：**完全依赖自组织团队，没有专职安全负责人。
正确做法： 即使在敏捷团队中，也需要明确的Safety Manager角色
图10: Scrum角色安全职责扩展映射表
，负责安全流程合规、Safety Case维护和外部审核对接。

陷阱五：把ISO 26262的"指导性条款"当作"可选项"

错误做法：认为Annex E是informative的，所以可以选择不执行。
正确做法： Annex E虽然是指导性附录，但它描述的是满足规范性条款（Normative Clauses）的推荐方法。如果不采用Annex E的方法，组织必须提供等效的替代方案来证明合规性。

十一、工具链选型建议

实现敏捷安全融合离不开合适的工具链支撑。以下是各功能领域的推荐工具组合：

功能领域	推荐工具	说明
需求管理	IBM DOORS / Polarion / Codebeamer	支持安全需求全生命周期管理，内置RTM功能
敏捷管理	Jira + Advanced Roadmaps	支持Safety Story管理、Sprint规划、与需求工具集成
静态分析	Polyspace / Coverity / PC-lint Plus	MISRA C:2012合规检查，集成到CI流水线
覆盖率分析	BullseyeCoverage / Cantata / Tessy	支持Statement/Branch/MC/DC覆盖率测量
单元测试	GoogleTest / Unity / CppUTest	轻量级C/C++单元测试框架
CI/CD	Jenkins / GitLab CI / Azure DevOps	支持自定义安全门控插件和流水线编排
版本控制	Git（受保护分支策略）	配合安全分支策略使用
安全案例	Assure.com / Claimant	结构化安全案例管理与证据关联

图11: ISO 26262第三版敏捷开发新增条款全景

12.1 核心要点回顾

本文系统梳理了ISO 26262第三版Annex E中关于敏捷开发融合的核心内容，涵盖六大融合支柱的工程实践：

1. Sprint安全集成：将安全活动转化为Safety Story，嵌入每个Sprint的规划和执行中
2. Safety-Extended DoD：扩展完成定义，增加追溯性、覆盖率、MISRA合规等安全验收条件
3. CI/CD安全门控：三层门控模型（编码质量/结构覆盖/安全验证），强制不可绕过
4. 持续追溯性：追溯性即代码，利用工具链自动维护RTM
5. 适配的配置管理：安全分支策略 + 合并控制规则，平衡敏捷速度与合规要求
6. 增量Safety Case：每个Sprint更新安全案例，避免"大爆炸"式编写

12.2 第三版展望

ISO 26262第三版预计2027年正式发布。除了Annex E的敏捷开发指南外，第三版还可能引入以下重要变更：

• 退化故障框架（Dependent Failure Framework）：更细化的共因失效分析方法
• 网络安全与功能安全协同：与ISO/SAE 21434的深度整合指引
• AI/ML组件的功能安全：针对自动驾驶中AI算法的安全评估方法
• OTA更新安全：更完善的OTA功能安全约束框架
• 混合系统ASIL分解：E/E系统+机械/液压系统的联合安全目标定义

12.3 工程落地建议

对于正在考虑采用敏捷方法的功能安全团队，建议按以下步骤逐步推进：

1. 第一步：试点Sprint------选择1-2个ASIL B级别的安全故事进行敏捷试点
2. 第二步：扩展DoD------在试点中验证Safety-Extended DoD的可行性和工作量影响
3. 第三步：CI/CD集成------搭建带安全门控的CI/CD流水线
4. 第四步：全流程推广------将试点经验推广到全团队，覆盖所有ASIL等级
5. 第五步：认证对接------与TÜV等认证机构沟通，确保敏捷实践满足审核要求
   核心理念： 敏捷与功能安全并非对立关系。ISO 26262第三版的Annex E证明了：通过合理的流程适配和工具链支撑，敏捷开发完全可以在满足功能安全合规要求的前提下，显著提升开发效率和产品质量。关键在于------将安全活动嵌入迭代，而非推迟到迭代之后。

参考标准：

• ISO 26262-2:2018 Clause 5 (Safety Planning), Clause 8 (Change Management), Clause 9 (Configuration Management)
• ISO 26262-6:2018 Clause 5-9 (Software Development), Table 2 (Verification Methods)
• ISO 26262第三版WD Annex E (Agile Development for Functional Safety)
• Scrum Guide 2020 (Scrum.org)
• SAFe 6.0 for Systems and Software Engineering (Scaled Agile, Inc.)
• IEC 61508-3:2010 Clause 7 (Software Requirements) --- 父标准参考
  本文是FS系列功能安全技术贴第17篇。下一篇FS-18将聚焦自动驾驶的功能安全挑战：从L2到L4的安全分级，探讨自动驾驶对功能安全体系的颠覆性影响及应对策略。**