1. 功能安全与网络安全概述
各位同学好，我是老张。今天咱们聊聊功能安全和网络安全的基本概念。这两个领域，说白了就是给汽车电子系统上「双保险」。
我刚开始做功能安全那会儿，网络安全还是个新鲜词。后来发现，这两者就像硬币的两面——功能安全管的是「系统别出故障」，网络安全管的是「别被人搞出故障」。你想想看，如果黑客能远程控制你的刹车，那功能安全做得再好也没用。
1.1 功能安全：从IEC 61508到ISO 26262
功能安全的核心思想很简单：系统在发生故障时，必须能安全地进入一个可接受的状态。比如刹车失灵了，至少要让车能安全停下来，而不是直接失控。
最早的功能安全标准是IEC 61508，1998年发布的。它是个「万金油」标准，工业、医疗、交通都能用。但汽车行业觉得不够细，于是在2011年推出了ISO 26262，专门针对道路车辆。
核心目标：把系统风险降到可接受的水平。怎么衡量？用ASIL等级（A到D，D最严）。
我记得第一次做ASIL D的项目，光是安全机制的设计就改了七八版。嗯，这里要注意：ASIL等级不是越高越好，成本会指数级上升。我见过一个团队给雨刮器也定了ASIL D，结果被评审专家骂得狗血淋头。
1.2 网络安全：ISO 21434的诞生
网络安全就更有意思了。2015年之前，汽车网络安全基本是个笑话——很多ECU连基本的身份认证都没有。直到2015年，克莱斯勒被黑客远程破解了JEEP Cherokee，整个行业才慌了。
ISO 21434标准在2021年正式发布。它的核心逻辑是：威胁分析和风险评估（TARA）。说白了，就是先想想「谁会攻击我？怎么攻击？后果多严重？」然后针对性地做防护。
| 对比项 | 功能安全（ISO 26262） | 网络安全（ISO 21434） |
|---|---|---|
| 关注点 | 随机硬件故障、系统故障 | 恶意攻击、人为入侵 |
| 核心方法 | 安全机制、故障注入测试 | 威胁建模、渗透测试 |
| 风险度量 | ASIL等级 | CVSS评分、攻击可行性 |
| 生命周期 | 概念→开发→生产→运行→报废 | 概念→开发→生产→运行→报废 |
1.3 两者的「爱恨情仇」
你可能会问：这两个标准会不会打架？
会的，而且经常打。我举个例子：功能安全要求「发生故障时，系统必须降级运行」。但网络安全要求「检测到异常时，立即切断通信」。如果同时触发，系统该听谁的？
我的经验：在项目早期就要建立「安全-安全协同矩阵」。把功能安全的安全目标和网络安全的防护目标放在一起比对，找出冲突点。我曾经在一个项目中，因为没做这个矩阵，导致安全网关在故障模式下把OTA更新给拦截了——车机系统直接变砖。
另一个常见冲突是「冗余设计」。功能安全喜欢双冗余甚至三冗余，但网络安全最怕冗余——攻击面变大了。你想想看，两个ECU互相备份，黑客只要攻破一个就能控制整个系统。
1.4 发展历程：从各自为战到协同设计
2010年之前，功能安全和网络安全基本是两条平行线。功能安全工程师不懂网络攻击，网络安全工程师不懂故障树分析。
转折点在2018年。ISO组织开始意识到：没有网络安全的汽车，功能安全就是空中楼阁。于是有了ISO 21434和ISO 26262的联合工作组。
我个人习惯把这段历史分成三个阶段：
- 混沌期（2000-2010）：功能安全刚起步，网络安全没人管。我记得2008年做的一个项目，安全文档里连「网络攻击」四个字都没出现过。
- 觉醒期（2011-2018）：ISO 26262发布，网络安全事件频发。行业开始讨论「安全融合」，但实际落地很少。
- 协同期（2019至今）：ISO 21434发布，各大OEM要求供应商同时满足两个标准。我最近做的项目，安全评审会都是功能安全和网络安全工程师坐在一起开的。
1.5 避坑指南：新手最容易犯的错
我曾经踩过的坑：
- 把功能安全的安全机制直接当成网络安全防护——结果被渗透测试秒破。
- 网络安全只关注外部攻击，忽略了内部人员误操作——有一次测试工程师把安全密钥写进了日志文件。
- 两个标准分开做文档，导致安全需求互相矛盾——最后评审时被要求重做。
我的建议是：从概念阶段就把两个标准绑在一起。比如做TARA时，同时考虑功能安全的风险和网络安全的威胁。这样后面才不会手忙脚乱。
1.6 小结
功能安全和网络安全，说白了都是「风险管理」。一个管物理故障，一个管人为攻击。但最终目标一致：让汽车更安全、更可靠。
下一章，我会详细讲怎么把这两个标准融合到实际项目中。到时候咱们聊聊具体的工具链和流程设计。
嗯，今天就到这儿。有问题随时问我。