第1章：功能安全基础
1.1 ISO 26262标准概述
说起ISO 26262，我得先跟你聊聊它的全称——「道路车辆功能安全标准」。说白了，它就是一套专门给汽车电子电气系统制定的安全规则。
我刚开始接触这个标准时，第一反应是：好家伙，这玩意儿真厚！但干久了你会发现，它其实就解决一个问题——怎么让车上的电子系统在出故障时也不伤人。
ISO 26262最早是2011年发布的，2018年更新了第二版。它覆盖了从概念设计到生产报废的全生命周期。你想想看，一个刹车系统、一个转向系统，要是出了bug，那可是人命关天的事。
我个人习惯把ISO 26262理解成一本「安全教科书」。它不告诉你具体怎么设计，而是告诉你该走什么流程、该做哪些分析、该留什么证据。
核心要点：ISO 26262不是技术规范，而是流程规范。它关注的是「你怎么证明你的系统是安全的」。
1.2 功能安全的历史与重要性
功能安全这概念，其实不是汽车行业原创的。它最早来自工业控制领域，比如核电、化工、航空。那些地方要是出事故，后果更严重。
汽车行业真正开始重视功能安全，跟几件事有关：
- 电子系统越来越多——以前车上都是机械件，坏了最多车不动。现在全是ECU、传感器、执行器，一个软件bug就能让车乱窜。
- 自动驾驶来了——人开车出事故，那是驾驶员的责任。机器开车出事故，那就是设计者的责任了。
- 召回成本太高——我在项目中遇到过一家主机厂，因为一个安全相关的软件缺陷，全球召回了30万辆车。那损失，够买好几个小公司了。
我记得2015年左右，国内很多车企对功能安全还不太上心。觉得「车能跑就行」。但近几年，随着新能源和智能驾驶的爆发，功能安全已经成了准入门槛。没有ISO 26262的认证，很多主机厂根本不跟你谈合作。
避坑指南：我曾经见过一个团队，产品都开发完了才想起来做功能安全。结果发现架构设计完全不满足要求，只能推倒重来。嗯，那叫一个惨。功能安全一定要从项目一开始就介入。
1.3 ASIL等级概念
ASIL，全称是Automotive Safety Integrity Level，汽车安全完整性等级。它是ISO 26262里最核心的概念之一。
说白了，ASIL就是给系统的风险程度打个分。分四个等级：
| ASIL等级 | 风险程度 | 典型应用 |
|---|---|---|
| ASIL A | 低 | 尾灯、车内照明 |
| ASIL B | 中 | 雨刮器、车窗控制 |
| ASIL C | 高 | 自适应巡航、自动大灯 |
| ASIL D | 最高 | 刹车系统、转向系统、安全气囊 |
你可能会问：ASIL等级是怎么确定的？
它由三个参数决定：
- 严重度（Severity）——出事故了，人受伤有多重？
- 暴露率（Exposure）——这种危险情况出现的频率高不高？
- 可控性（Controllability）——驾驶员能不能在危险发生时及时控制住？
举个例子。刹车失灵，严重度肯定是S3（最严重），暴露率E4（经常用），可控性C3（很难控制）。三个一组合，妥妥的ASIL D。
而尾灯坏了呢？严重度S1（最多追尾），暴露率E4（晚上开车），可控性C2（还能靠刹车灯警示）。组合下来就是ASIL A。
个人经验：我建议产品经理在定义功能需求时，就初步评估ASIL等级。别等到开发完了才发现某个功能需要ASIL D，那架构设计、硬件选型全得变。提前评估，能省很多返工成本。
还有一个概念叫QM（Quality Management）。它不算ASIL等级，意思是「按普通质量管理就行，不需要额外安全措施」。比如车载娱乐系统、导航地图，这些功能出故障不会直接导致人身伤害，归到QM就够了。
但要注意——QM不是可以随便糊弄。它只是说不需要走功能安全的开发流程，但基本的质量管理还是要的。
1.4 为什么产品经理要懂功能安全？
你可能觉得功能安全是安全工程师的事。错了。产品经理不懂功能安全，会出大问题。
我见过太多这样的场景：
- 产品经理拍脑袋定了个功能，结果ASIL等级评估下来是D，硬件成本直接翻倍。
- 产品经理把安全机制砍了，说「用户感知不到，没必要」。结果安全评审没过，项目延期三个月。
- 产品经理不懂ASIL分解，把ASIL D的功能直接分给一个普通MCU，最后测试全挂。
所以，产品经理至少要懂三件事：
- 能看懂ASIL等级——知道哪些功能是安全关键件。
- 能评估成本影响——ASIL等级越高，开发成本、硬件成本、测试成本都越高。
- 能跟安全工程师对话——别人家说「这个需要ASIL D」，你一脸懵。
一句话总结：功能安全不是技术问题，是管理问题。产品经理是那个把安全要求翻译成产品需求的人。
好了，第一章就聊到这儿。下一章我们聊聊怎么在实际项目中做危害分析和风险评估（HARA），那是确定ASIL等级的关键一步。