写在前面的话
兄弟们，又见面了。今天咱们聊聊自动驾驶里功能安全的硬件和软件开发。如果你前两节课没听，强烈建议回去补课，因为今天的内容会用到前面的基础知识。
好了，废话不多说，咱们直接开整！
第一章：功能安全在自动驾驶中的定位
1.1 先搞清楚大框架
大家得先在脑子里把这个结构理顺：
- ISO 26262是整车厂RFQ里几乎唯一会出现的功能安全标准
- 偶尔会看到ISO 21448（SOTIF），这个下节课讲
- 今天重点就是26262
上节课我们讲了从整车级到系统级怎么提安全需求，怎么做安全架构设计。今天的软硬件开发，就是用来实现那些设计思路的。
重点提示：系统设计是大脑，硬件软件是四肢。大脑想好了怎么做，四肢才知道往哪使劲。
第二章：硬件设计——从原理到实战
2.1 硬件工程师要干的三件大事
咱们先说硬件要做什么：
第一件事：实现系统需求
系统设计说要监控什么，你就得提供硬件平台：
- 要监控图像信号？给我上传感器接口
- 要监控电压？给我上ADC采样
- 要监控温度？温度传感器安排上
第二件事：分析硬件自己会怎么坏
这是个大头！为啥呢？因为：
- ADC坏了，电压监控就失效了
- 传感器挂了，数据就没了
- 所有硬件都会坏，这是铁律
所以你得做两件事：
- 定性分析：这玩意儿会怎么坏？
- 定量计算：坏的概率有多高？
第三件事：器件选型要讲究
不是所有芯片都能随便选：
- 单片机得选带功能安全等级的
- 电阻电容也有要求
- 供应商资质得看清楚
2.2 硬件随机失效——最难啃的骨头
敲黑板：这是硬件功能安全里工作量占50%以上的内容，也是最容易不过的地方！
2.2.1 为什么硬件会坏？
物理规律决定的，逃不掉：
- 热胀冷缩：温度一变，焊点疲劳，就容易裂
- 电磁冲击：EMC问题会打坏器件
- 金属须：焊点会”长毛”，这些毛会断或短路（没骗你，真的会长毛！）
- 宇宙射线：阿尔法粒子打到内存上，比特位就翻转了
- 制程问题：7纳米工艺的芯片，一个硅原子才几纳米，太敏感了
举个例子：DDR内存的失效率特别高，这是行业共识。为啥？因为它单元多、工作频率高、容易受干扰。
2.2.2 失效率怎么算？
先记住两个概念：
- FIT（Failure In Time）：失效率单位，1 FIT = 1×10^-9/小时
- 失效模式：坏的方式，比如电阻50%开路、50%短路
数据从哪来？
三个渠道：
- IEC 62380：汽车常用
- SN 29500：也很常用
- 半导体厂商数据手册：优先用这个，因为失效率更准
小贴士：德州仪器的IC，官网上都能搜到失效率数据。如果搜不到，就去查SN 29500标准，有计算公式。
2.2.3 三大指标必须达标
做完FMEDA（失效模式影响分析）后，得看三个指标：
| 等级 | SPFM（单点失效矩阵） | LFM（潜藏失效矩阵） | PMHF（随机硬件失效率） |
|---|---|---|---|
| ASIL B | ≥90% | ≥60% | <100 FIT |
| ASIL C | ≥97% | ≥80% | <100 FIT |
| ASIL D | ≥99% | ≥90% | <10 FIT |
注意：这三个都得达标，少一个都不行！
中国特色： 国内OEM特别看重这个定量计算，因为这是功能安全里唯一能用数字衡量等级的东西。国外倒没这么严格。
2.3 硬件器件选型——别踩坑
2.3.1 老标准的分类（ISO 26262:2011）
分四类，但简化看是三类：
第一类：基础器件
- 例子：电阻、电容、电感
- 要求：车规级就行（比如AEC-Q标准）
第二类：中等复杂度器件
- 例子：解码器、编码器
- 要求：同上，车规级
第三类：中等复杂度组件
- 例子：压力传感器、电流监控IC
- 要求：需要供应商提供分析报告和测试报告
第四类：复杂器件
- 例子：单片机、MCU
- 要求：必须有功能安全认证（这就是为啥你买MCU得选带ASIL等级的）
2.3.2 新标准更严了（ISO 26262:2018）
新标准把中等复杂度组件也归到”必须做功能安全认证”这一档了。所以趋势是越来越严。
采坑经验：有些供应商的IC没做功能安全认证，你得让他们补材料。如果时间来不及，就换器件，别硬扛。
2.4 自动驾驶硬件设计常见架构
目前主流方案：
高算力SOC（跑算法）
↕
安全MCU（监控）
↕
传感器接口 + 执行器接口
核心思路：
- SOC：负责AI算法、图像识别，算力强
- MCU：负责安全监控、总线通信、进入安全状态
2.4.1 常见的坑
坑1：SOC没有功能安全认证怎么办？
打补丁！虽然不完美，但可以跟客户谈：
- 外部监控：MCU监控SOC的供电、温度、输出
- 软件加固：用QNX系统，加自检算法
- 数据保护：E2E校验、冗余设计
坑2：供电精度要求太高
赛灵思FPGA要求±3%的供电精度，普通电路很难做到。
解决方案：
- 用专用的PMIC（电源管理IC）
- 优先用芯片厂推荐的配套方案
- 不要自己瞎配，容易翻车
坑3：发热太严重
自动驾驶域控制器就是个大电脑，发热量巨大。
怎么办？
- 温度传感器多布几个
- 传感器之间要能互相校验
- 过温保护必须做，而且要做到ASIL D
坑4：失效率太高
做出来一算，100多FIT，根本达不到ASIL D的10 FIT要求。
解法：
- 增加诊断覆盖率
- 换失效率更低的器件
- 如果只高一点（比如15-20 FIT），可以跟客户谈，现在大家失效率都挺高
第三章：软件设计——防自己出Bug
3.1 软件工程师的使命
硬件会坏，软件不会坏，软件只有Bug。
所以软件的任务是：
- 实现系统需求：系统说要监控啥，你就监控啥
- 防止自己出Bug：通过流程和技术手段
- 检测自己的Bug：设计安全机制
- 检测硬件的Bug：软件得帮硬件诊断
敲黑板：普通软件只要”防Bug”，功能安全软件还要”检测Bug”！
3.2 软件架构层的安全机制
这是重点中的重点！所有安全机制都在架构层实现。
3.2.1 防串扰设计
不同安全等级的软件不能互相干扰：
场景：QM的算法跑一半不退出，导致ASIL D的算法执行不了，怎么办？
方案一：软件防串扰
- 监控每个任务的执行时间
- 超时了就强制Kill掉
方案二：硬件防串扰
- QM任务跑在核1
- ASIL D任务跑在核2
- 物理隔离，谁也不影响谁
内存保护：用MPU（内存保护单元）把内存分区，数据不串。
3.2.2 十大安全机制（必看）
新标准更严格，只要适用你的项目，都得用上：
| 安全机制 | 说明 | 举例 |
|---|---|---|
| 数据范围检查 | 检查数据是否在合理范围内 | 车速不能负数 |
| 数据正确性校验 | 用多种方法验证 | 用电机转速反推车速 |
| 数据流监控 | 检查数据传输是否出错 | CRC校验 |
| 程序流监控 | 检查程序是否按顺序执行 | 看门狗 |
| 多样性设计 | 同一个算法用不同方法实现 | 两套算法结果对比 |
| 静态恢复 | 出错后重启 | 复位重启 |
老版本vs新版本：老标准按ABCD分级要求，新标准是”适用就必须做”。
3.3 软件分析——三大恶心分析
除了写代码，你还得做分析：
3.3.1 软件FMEA/FTA
跟硬件类似，但失效模式不同：
软件特有的失效模式：
- 数据溢出
- 指针悬挂
- 死锁
- 内存泄漏
- 时序错误
- 数组越界
3.3.2 DFA（相关性失效分析）
什么时候做？
- 不同安全等级的软件在一个ECU里
- 需要分析会不会互相影响
什么时候不用做？
- 所有软件都是同一个等级（比如都是ASIL D）
实战技巧：如果实在做不完DFA，就把所有软件都设计成同一个等级，虽然成本高，但省事。
3.4 软件单元设计——代码规范
ASIL D的代码跟QM代码长得不一样吗？
区别不大，但有要求：
✅ 必须做到的：
- 单入单出（一个函数只能有一个return）
- 不用递归
- 少用指针
- 少用全局变量
- 所有变量都要初始化
❌ 禁止的：
- 动态生成对象
- 多个出口的函数
好消息：很多公司现在写QM代码已经按这个标准了，所以改起来不难。
3.5 软件测试——最大的工作量
ASIL D的杀手锏：MC/DC覆盖率
MC/DC = Modified Condition/Decision Coverage（修正条件/决策覆盖）
简单说：所有if/else的条件排列组合都得测到。
有多恐怖？
- 如果你有10个if条件，组合起来是2^10 = 1024种情况
- 复杂模块可能一辈子都测不完
怎么办？
- 模块尽量小，别写大函数
- 减少条件判断的数量
- 用测试工具自动生成用例
3.6 自动驾驶软件常见架构
高算力SOC
├── POSIX系统（QNX）
│ ├── AUTOSAR Adaptive
│ ├── ASIL D监控算法
│ └── QM算法（图像识别）
│
安全MCU
├── RTOS（实时操作系统）
│ ├── AUTOSAR Classic
│ ├── Level 3监控（温度、电源）
│ └── 安全状态管理
核心原则：
- 底层中间件（OS、AUTOSAR）买现成的
- 应用层自己开发的部分，必须做分析
3.7 软件常见的坑
坑1：算法没法做功能安全
深度学习算法本身不是安全算法，怎么办？
解法：
- 加监控算法（用传统视觉方法校验结果）
- 多传感器融合
- 人工接管机制
坑2：算力不够
Level 2监控算法太复杂，MCU跑不动。
解法：
- 放SOC上跑，然后给SOC打补丁
- 优化算法，降低复杂度
坑3：操作系统不符合
Linux不能直接用在安全件上。
解法：
- 用QNX（黑莓，ASIL D认证）
- 用风河VxWorks（也有安全版）
- 绝对不要裸跑Linux
坑4：工具没认证
用了半导体厂商免费的代码生成工具，但它没过功能安全认证。
解法：
- 优先用MATLAB/Simulink（有认证）
- 编译器、烧写器、标定工具必须有认证
- Excel写需求、测试工具不需要认证
第四章：实战总结与避坑指南
4.1 硬件开发避坑清单
✅ 必做清单：
- FMEDA定量计算（SPFM、LFM、PMHF）
- 硬件FMEA/FTA分析
- 器件选型符合要求
- 热保护设计
- 电源监控精度达标
- 失效率控制在目标范围内
❌ 常见错误：
- 随便选芯片，不看是否有安全认证
- 失效率算出来100多FIT，远超目标
- 供电精度不够，监控不到故障
- 温度传感器布局不合理
4.2 软件开发避坑清单
✅ 必做清单：
- 架构层安全机制设计
- 软件FMEA/FTA分析
- DFA相关性失效分析（如需要）
- 代码符合规范
- MC/DC覆盖率达标
- 工具链有认证
❌ 常见错误：
- 用Linux跑安全软件
- 工具没认证就用了
- MC/DC覆盖率不够
- 忘记做DFA分析
4.3 如何判断达到了ASIL等级？
硬件怎么看？
- 看定量计算结果（三大指标）
- 看分析报告是否完整
- 看器件选型是否符合
软件怎么看？
- 看流程文档是否齐全（需求、设计、测试）
- 看代码规范是否符合
- 看测试覆盖率是否达标
- 看安全分析是否完整
重点：直接看代码，你看不出它是什么等级的。必须看配套文档！
4.4 与ASPICE的关系
很多人问：ASPICE和26262软件有什么关系？
答案：如果你按ASPICE CL2/CL3开发，80-90%的功能安全软件流程就自动满足了。
区别在哪？
- 代码规范：ASPICE没要求，26262有
- 测试覆盖率：ASPICE没要求MC/DC，26262要求
- 其他都类似：需求、设计、review等流程基本一致
第五章：写在最后
功能安全硬件和软件开发，核心就是：
硬件：
- 算失效率
- 选对器件
- 做好分析
软件：
- 防Bug（流程）
- 检测Bug（安全机制）
- 测试够（MC/DC覆盖率）
记住：流程永远是防Bug的最好办法！
常见问题FAQ
Q1：某颗IC的失效率从哪获取？ A：半导体厂商官网 > SN 29500标准 > 用工具查
Q2：如何确认软件达到了ASIL目标？ A：看文档！需求、设计、测试、review、覆盖率，缺一不可。
Q3：FMEDA计算时考虑软件安全等级吗？ A：不考虑等级，只考虑诊断覆盖率。软件等级只影响流程严格程度。
Q4：硬件达到ASIL D有什么方案？ A：供电模块有认证 + 软件ASIL D监控 + ADC自检防潜藏失效
Q5：有什么工具推荐？ A：FMEDA工具（有国产也有进口）、MATLAB/Simulink、QNX系统
原创文章，作者：self driving, lin，如若转载，请注明出处：https://www.key-iot.com.cn/jssf/1225.html
