FuSaCert · 功能安全学习
ISO 26262 功能安全入门：从概念到软件开发
从一个功能出发，问清楚“它出错时会带来什么危险、需要怎样避免、怎样证明措施有效”，比从头背完所有缩写更适合入门。下面是一条按理解依赖排列的学习路径。
学习路线为 FuSaCert 原创建议；标准范围说明为对 ISO 26262:2018 的转述。练习任务是教学活动，不代表正式项目所需的全部工作。
第一步：建立生命周期地图
先看 12 个 Part 的分工，认识管理、概念、系统、硬件、软件、生产运行以及支持过程如何连接。不要把 ISO 26262 理解成只有软件编码规范或最后一次测试。
建议输出一张自己的关系图：概念阶段形成哪些输入？系统设计如何分配安全需求？软件与硬件各自需要什么验证证据？先能解释方向，再深入条款。
第二步：把 HARA、ASIL 和安全目标连起来
Part 3 的概念阶段包含相关项定义、危害分析与风险评估（HARA）以及功能安全概念。先明确功能、边界和运行场景，再分析故障行为引起的危害事件。
用严重度 S、暴露度 E 和可控性 C 进行风险分类，随后得到相应 ASIL。E 关注运行场景的出现，不是故障发生概率；ASIL 是风险分类结果，不是产品质量评分。
练习输出：一个有边界的相关项说明、一条完整的危害事件、S/E/C 的假设理由，以及与该危害事件对应的安全目标。
第三步：理解需求如何逐层落地
安全目标回答需要防止什么危害；功能安全需求说明需要怎样的安全行为；后续技术和软件安全需求继续细化实现约束。它们不能只靠把同一句话改写几遍完成。
练习时，检查每条下游需求能否找到上游依据、责任分配和验证方式。发现需求含糊时，先补清输入条件和期望行为，再谈测试用例。
第四步：进入 Part 6 的软件开发链条
按软件安全需求、架构、单元设计与实现、单元验证、软件集成与验证、嵌入式软件测试的顺序学习。将开发活动与对应验证活动配对，而不是把测试放到末尾才考虑。
练习输出：选择一条软件安全需求，画出它分配到哪个组件，由哪些单元实现，在哪一级验证，以及证据如何回到原需求。
第五步：用问题检验理解
概念检查
能否解释 HARA、FMEA 和软件测试各自回答什么问题？能否区分故障、故障行为、危害与危害事件？
案例检查
换一个运行场景后，S/E/C 的判断是否需要变化？需要什么资料支持，而不是直接套用案例评级？
证据检查
如果评审者问“为什么这条安全需求已经满足”，能否给出需求、设计、验证结果之间的关联？
常见问题
- 应该先学 Part 3 还是 Part 6？
- 初学者先建立 Part 3 的概念链，再进入自己的工程方向。软件工程师可以随后重点学习 Part 6，同时理解它与系统需求、支持过程的关系。
- 看完指南就能做真实项目的 HARA 吗？
- 本指南提供学习顺序。真实 HARA 还需要完整相关项定义、运行场景资料、专业判断及评审，不能把教学示例直接复制为项目结论。
- 是否需要立即购买全部工具？
- 入门阶段可以先用纸笔或表格整理概念、假设和追溯关系。工具的价值在于帮助执行和检查过程，而不是替代判断。
依据与范围
- ISO 26262-3:2018 · ISO 官方目录
概念阶段范围：相关项定义、HARA、功能安全概念。
- ISO 26262-6:2018 · ISO 官方目录
产品开发软件层面的范围。