11、Camera系统安全分析：HARA分析、FMEA与FTA在Camera系统中的应用
做车载Camera系统这些年，我越来越觉得——功能安全不是锦上添花，而是底线。你想想看，一个ADAS摄像头如果关键时刻掉链子，后果是什么？不是黑屏，是可能撞车。
所以这一章，咱们聊聊Camera系统里最核心的三个安全分析方法：HARA、FMEA和FTA。说白了，就是一套系统化的「找茬」方法论。我当年刚接触功能安全时，觉得这些工具太繁琐，后来吃过亏才明白——这些流程救过我的命。
11.1 为什么Camera系统需要专门的安全分析？
车载Camera和手机Camera完全是两码事。手机拍糊了可以重拍，车载摄像头如果输出一帧错误数据，可能直接导致决策系统误判。
我举个例子。之前有个项目，环视摄像头在夜间低照度场景下，偶尔会输出一帧「雪花图」。测试团队觉得概率低，没当回事。结果在功能安全评审时，HARA分析一跑——这个失效模式对应的ASIL等级是B级。嗯，后来老老实实加了硬件诊断电路。
Camera系统的特殊性在于：
- 多路输入：4路甚至8路摄像头同时工作，相互之间可能有干扰
- 高动态范围：HDR处理涉及多帧合成，时序错乱会导致严重失真
- 实时性要求：从Sensor曝光到ISP输出，延迟必须控制在毫秒级
- 环境复杂性：温度、振动、电磁干扰，哪个都能让摄像头「抽风」
所以，安全分析不是走过场，是真刀真枪的工程实践。
11.2 HARA分析：从「可能出啥事」到「多严重」
HARA（Hazard Analysis and Risk Assessment）是功能安全的起点。它的核心任务就三个字：找危害。
我个人习惯，做HARA时先列一个「失效场景清单」。比如：
- 摄像头被泥水遮挡
- MIPI信号线被电磁干扰
- ISP芯片过热导致输出冻结
- 多路Camera的帧同步信号丢失
然后对每个场景，评估三个维度：
| 维度 | 含义 | Camera典型场景 |
|---|---|---|
| Severity (S) | 危害严重程度 | 前视摄像头失效可能导致碰撞 → S3 |
| Exposure (E) | 暴露概率 | 夜间行驶概率约10% → E3 |
| Controllability (C) | 驾驶员可控性 | 高速场景下驾驶员很难补救 → C2 |
根据S、E、C的组合，查ISO 26262的表格，就能得到ASIL等级（A、B、C、D或QM）。
关键点：HARA不是一次性的。我建议在架构设计阶段做一次，在详细设计阶段再review一次。因为随着设计深入，你会发现新的失效模式。
我曾经在一个项目中，HARA分析时漏掉了「摄像头加热器短路导致Sensor过热」这个场景。结果冬天路试时，加热器控制逻辑有bug，摄像头内部温度飙到90度，图像直接偏色。嗯，后来补了HARA，加了温度监控电路。
11.3 FMEA：把「可能坏」的地方逐个排查
FMEA（Failure Mode and Effects Analysis）比HARA更细。HARA是「找危害」，FMEA是「找失效原因」。说白了，就是对着系统框图，一个一个元件问：你如果坏了，会怎样？
做Camera系统的FMEA，我习惯按信号链路来拆：
- Sensor层：像素失效、增益异常、帧同步丢失
- 传输层：MIPI信号眼图劣化、SerDes链路断开
- ISP层：HDR合成错位、白平衡漂移、降噪算法跑飞
- 输出层：帧率抖动、时间戳错误、数据校验失败
每个失效模式，FMEA表格里要填：
- 失效原因（比如：电源纹波过大导致Sensor PLL失锁）
- 失效影响（比如：输出图像出现水平条纹）
- 检测措施（比如：硬件锁相环状态寄存器监控）
- 严重度、发生度、探测度 → 算出RPN（风险优先级数）
我的经验：RPN超过100的项，必须要有设计改进或增加诊断。别指望靠「测试覆盖」来降低风险——测试永远测不完所有边界条件。
举个例子。之前做多路Camera的FMEA，发现「帧同步信号线短路」这个失效模式的RPN高达168。原因是多路Camera共用一条同步信号线，一旦短路，所有摄像头都会失步。解决方案很简单——每路Camera独立同步信号，再加一个看门狗检测同步脉冲丢失。
11.4 FTA：从「灾难」倒推「原因」
FTA（Fault Tree Analysis）和FMEA是反过来的。FMEA是从下往上推（元件失效→系统影响），FTA是从上往下推（系统故障→根因）。
我个人觉得，FTA更适合分析那些「一旦发生就很严重」的故障。比如：
顶事件：前视Camera输出错误图像，导致AEB误触发。
然后往下拆：
- OR门：硬件故障 OR 软件故障 OR 环境干扰
- 硬件故障下再拆：Sensor损坏 OR ISP异常 OR 电源失效
- 软件故障下再拆：算法bug OR 配置错误 OR 时序异常
每个分支都要量化概率。比如Sensor损坏的概率是10^-6/h，ISP异常的概率是10^-7/h。然后通过布尔代数算出顶事件的发生概率。
注意：FTA的难点在于概率数据的准确性。很多团队拍脑袋填数据，那FTA就变成了数字游戏。我建议至少用供应商提供的失效率数据，或者参考SN 29500标准。
我曾经在一个项目中，FTA分析发现「HDR多帧合成时序错乱」这个分支的概率被低估了。后来实际路测，确实在隧道出入口场景频繁触发。嗯，FTA没骗人。
11.5 三种方法的协同使用
你可能会问：这三个工具到底怎么配合？我画了一张图来说明。
实际项目中，我的做法是：
- 先做HARA：确定哪些功能需要安全设计，定ASIL等级
- 再做FMEA：针对高ASIL等级的功能，逐模块分析失效模式
- 最后FTA：对关键顶事件（比如「输出错误图像」）做定量分析
三者不是串行的，而是迭代的。FMEA发现的新失效模式，可能反过来更新HARA的评估。FTA算出来的概率太高，可能需要增加新的安全机制，然后重新跑FMEA。
11.6 Camera系统安全分析的常见坑
做了这么多项目，我总结几个容易踩的坑：
- 坑一：忽略多路Camera的相互影响。比如一路Camera的电源短路，可能拉低整个电源轨，导致其他Camera也掉电。FMEA时一定要考虑「共因失效」。
- 坑二：HDR场景的时序分析不到位。多帧合成对时序极其敏感，帧同步信号抖动超过一个像素时钟，合成图像就会出现鬼影。这个在FTA里要单独建分支。
- 坑三：安全机制本身也会失效。比如你加了一个看门狗来监控ISP，但看门狗芯片自己先坏了怎么办？FMEA里要包含「诊断电路的诊断」。
避坑指南：我曾经在一个项目中，FMEA分析时漏掉了「ISP温度传感器失效」这个模式。结果温度传感器输出错误值，导致ISP降频保护误触发，帧率掉到10fps。后来在FMEA里补了「传感器自检」这一项——每次上电先读温度传感器的ID寄存器，确认通信正常。
11.7 小结
HARA、FMEA、FTA这三个工具，是车载Camera系统功能安全的「三驾马车」。HARA告诉你「要防什么」，FMEA告诉你「哪里会坏」，FTA告诉你「坏的概率有多大」。
做安全分析，最忌讳的就是「为了过评审而做文档」。我见过太多团队，FMEA表格填得漂漂亮亮，但实际代码里一个诊断都没加。嗯，那样的话，评审过了，车在路上可不会给你留情面。
记住一句话：安全分析的价值，不在于文档有多厚，而在于你真正发现了多少隐患，并且把它们堵死了。
公众号:蓝海资料掘金营，微信deep3321