学功能安全

第一阶段：建立全局认知（第1~2周）

目标：搞清楚功能安全到底在干什么，和你日常工作的关系是什么。

读什么

ISO 26262 Part 1（词汇）------先把术语搞明白：ASIL、HARA、FMEA、FMEDA、SPFM、LFM、PMHF、DFA......这些"黑话"不搞清楚，后面读啥都云里雾里
ISO 26262 Part 10（指南）------这是标准的"人话翻译版"，帮你理解其他部分在说什么
ISO 26262 Part 5（硬件层产品开发） ------这是你的主战场，从硬件安全需求定义、硬件设计、架构度量评估到集成验证，全部在这里

怎么读

不要从头到尾逐字读，而是带着一个问题读："我画的这块板子，如果某个元器件坏了，系统会怎样？"

建立认知框架

ISO 26262第二版（2018年发布）由12个部分组成，你不需要全读，重点关注：

优先级	部分	内容	你的角色
必读	Part 5	硬件层产品开发	你的主战场
必读	Part 9	安全分析方法（FMEA/FTA/FMEDA）	你日常要用的工具
重点读	Part 4	系统级产品开发	理解上游输入从哪来
重点读	Part 8	支持过程（配置管理、验证）	理解流程要求
了解	Part 2	安全管理	知道项目层面怎么管
了解	Part 3	概念阶段（HARA）	知道ASIL怎么来的
参考	Part 11	半导体指南	如果做芯片相关

第二阶段：掌握硬件工程师的核心技能（第3~6周）

目标：学会硬件功能安全的三个核心分析工具。

技能一：FMEA（故障模式与影响分析）

一句话：逐个元器件分析"如果它坏了，会怎样"。

怎么练：拿你手边一块正在开发的板子，对着BOM表，逐个元器件列出：

故障模式（开路、短路、漂移、卡死......）
故障影响（对系统功能的影响）
严重度S / 发生度O / 探测度D
现有安全机制能否覆盖

技能二：FMEDA（故障模式、影响及诊断分析）

一句话：FMEA的"量化升级版"，算出三个硬性指标来证明硬件设计满足ASIL等级要求。

三个核心指标：

指标	全称	含义
SPFM	单点故障度量	单个元器件故障时，系统能否检测到并安全处理
LFM	潜伏故障度量	多个元器件同时故障时，系统能否检测到
PMHF	概率化硬件失效率	整个硬件的随机失效率是否低于目标值

FMEDA五步法：

基于BOM，查每个元器件的失效率（参考SN29500等手册）
确定每个元器件的失效模式及分布比例
确定安全机制及其诊断覆盖率（参考ISO 26262 Part 5 附录D）
分析失效影响，确定故障类型（安全/危险/无影响）
计算SPFM、LFM、PMHF，判断是否满足目标ASIL等级

不达标怎么办？ 优化电路架构（加冗余、加诊断），然后重新算，循环迭代直到达标。

技能三：DFA（相关失效分析）

一句话：分析"一个故障源会不会同时搞挂多个功能"。

典型场景：

多个模块共用一路电源 → 电源故障 = 全部失效
多个模块共用PLL时钟 → 时钟故障 = 全部失效
多路传感器共用同一个ADC → ADC故障 = 全部失效

怎么练：拿你的板子，画出所有共享资源（电源、时钟、总线、复位信号），逐个分析"如果这个共享资源挂了，会影响哪些功能"。

第三阶段：理解硬件在V模型中的位置（第7~8周）

目标：搞清楚你的工作在整个功能安全流程中的上下游关系。

复制代码

系统工程师做HARA → 确定ASIL等级
        ↓
系统工程师定义技术安全需求（TSR）
        ↓
    ┌───────────────────────────┐
    │  你的工作从这里开始        │
    │                           │
    │  ① 导出硬件安全需求（HSR）│
    │  ② 硬件安全架构设计       │
    │  ③ 硬件详细设计           │
    │  ④ FMEA / FMEDA / DFA    │
    │  ⑤ 硬件集成与验证         │
    │  ⑥ 故障注入测试           │
    │                           │
    └───────────────────────────┘
        ↓
系统工程师做安全确认（验证整体是否安全）

关键认知：硬件安全需求不是凭空来的，它从系统级的技术安全需求（TSR）分解而来。你需要理解上游给你的需求是怎么推导出来的，才能设计出正确的安全机制。

第四阶段：在实际项目中落地（持续）

具体怎么做

找一个在研项目练手：拿你正在开发的ECU或控制器，从HARA开始，完整走一遍硬件功能安全流程
建立硬件安全需求追溯矩阵：每个硬件安全需求 → 对应哪个系统安全需求 → 对应哪个危害 → 用什么安全机制覆盖 → 用什么测试验证
做一次完整的FMEDA：从BOM表开始，算出SPFM/LFM/PMHF，看看能不能达标
做一次故障注入测试：人为注入故障（比如断开某个传感器、短路某个信号），验证系统是否按预期进入安全状态

用途	工具
需求管理与追溯	DOORS / Polarion / Jama
FMEA/FMEDA分析	APIS IQ / ReliaSoft / medac
故障树分析	FaultTree+ / Isograph
HIL测试	dSPACE / NI / ETAS

第五阶段：学习资源推荐

资源	说明	适合阶段
ISO 26262 Part 5 + Part 9	硬件工程师的"圣经"	全程参考
Udemy: ISO 26262 Crash Course	4小时速成，建立全局观	入门
NXP安全学院	免费，有硬件工程师专属路径	入门~进阶
JARI硬件技术者课程	日本自動車研究所出品，含实战演习，附HORIBA MIRA证书	进阶
《从IEC61508到ISO26262》	中文书籍，深度讲解FMEA/FTA/FMEDA/DFA	进阶

一句话总结你的学习路线

先读Part 5搞清硬件开发流程 → 用FMEA/FMEDA/DFA三个工具分析你手边的板子 → 在实际项目中完整走一遍从HSR到验证的闭环。

你目前手边有在做的项目吗？如果有的话，可以直接拿它当练手对象，我帮你梳理第一步该从哪里切入。