一、为什么车载系统必须谈功能安全？
说实话，我刚入行做手机系统时，从来没想过「死机」会是个要命的问题。手机死机了，重启一下就好。但在车上，屏幕黑掉、刹车没反应、转向突然失灵——这不是体验问题，这是人命关天。
我参与的第一个车载项目，客户要求我们分析「中控屏死机是否会导致倒车影像丢失」。当时我心想：死机了当然丢失啊，这还用分析？后来才知道，功能安全要的不是「会不会发生」，而是「发生之后怎么办」。
这就是功能安全的核心逻辑：系统可以出故障，但不能出危险。
二、ISO 26262 到底是什么？
ISO 26262 是汽车行业的功能安全标准，全称叫「Road vehicles — Functional safety」。它源自工业界的 IEC 61508，但专门针对汽车做了裁剪和增强。
说白了，它就是一套方法论，告诉你：
- 怎么识别风险
- 怎么评估风险等级
- 怎么设计系统来降低风险
- 怎么验证你的设计是有效的
我刚开始看这个标准时，觉得它又厚又绕。后来发现，你不需要背下所有条款，但必须理解它的核心思想：危害分析与风险评估。
2.1 功能安全的 V 模型
ISO 26262 推荐用 V 模型来组织开发流程。左边是设计，右边是验证，中间是需求。
嗯，这张图我画过无数次。每次给团队讲 V 模型时，我都会强调：左边每一步都对应右边一个验证活动。没有追溯，就等于没做。
三、ASIL 等级——你的系统有多「危险」？
ASIL 全称是 Automotive Safety Integrity Level，汽车安全完整性等级。它分四个等级：
| 等级 | 含义 | 典型场景 |
|---|---|---|
| ASIL A | 最低 | 信息娱乐系统（非安全相关） |
| ASIL B | 中等 | 仪表盘显示、空调控制 |
| ASIL C | 较高 | 自适应巡航、自动紧急制动 |
| ASIL D | 最高 | 线控转向、线控制动 |
还有一个叫 QM（Quality Management），意思是「不需要安全措施，普通质量管理就行」。比如车载音乐播放器，死机了顶多没音乐，不会出人命。
3.1 ASIL 怎么定出来的？
ASIL 等级由三个参数决定：
- 严重度（Severity）：伤害有多重？轻伤、重伤、致命？
- 暴露概率（Exposure）：这种情况发生的频率高不高？
- 可控性（Controllability）：驾驶员能不能在故障时补救？
我记得有一次评审，一个功能被定为 ASIL B，但团队觉得「这功能挺重要的，应该上 C」。后来我们仔细分析暴露概率——这个故障只在特定工况下出现，而且驾驶员有足够时间反应。最后确认 B 级就够了。
核心原则：ASIL 不是拍脑袋定的，是三个维度综合评估的结果。不要盲目拔高等级，那意味着更多的开发成本和验证工作。
四、Android 在功能安全中扮演什么角色？
这个问题我经常被问到。Android 本身不是为功能安全设计的，它是个通用操作系统。但车载场景下，Android 必须承担安全相关的职责。
4.1 Android 的「安全边界」
在 Automotive 架构中，Android 通常运行在「非安全域」或「部分安全域」。什么意思呢？
- 非安全域：信息娱乐、导航、语音助手——这些功能出问题不会直接导致危险
- 部分安全域：仪表盘显示、倒车影像、HUD——这些功能出问题会影响驾驶安全
我参与的一个项目中，客户要求 Android 系统在倒车影像显示时，必须保证 200ms 内响应。如果超时，系统要自动切换到备用显示通道。这就是典型的「功能安全需求」。
4.2 Android 能做什么？
说实话，Android 本身不提供功能安全认证。但我们可以通过架构设计来弥补：
- 隔离机制：把安全关键功能放在独立进程中，用 SELinux 限制权限
- 看门狗监控：用硬件看门狗监控 Android 系统是否「活着」
- 降级策略：当 Android 系统异常时，自动切换到安全模式
- 日志与诊断：记录所有安全相关事件，便于事后分析
我的经验：不要试图让 Android 去「保证」安全。Android 能做的是「检测」和「报告」。真正的安全决策，应该由底层的安全 MCU 或独立的安全域控制器来做。
4.3 一个实际案例
之前有个项目，客户要求在 Android 中实现「驾驶员状态监测」功能。这个功能需要调用摄像头，分析驾驶员是否疲劳驾驶。
功能安全分析发现：如果 Android 系统死机，摄像头数据无法处理，系统必须能检测到「数据丢失」并发出警告。
我们怎么做的？
- 在 Android 中跑一个安全监控服务，定期向硬件看门狗发送心跳
- 如果看门狗在 500ms 内没收到心跳，就认为 Android 异常
- 硬件看门狗直接触发仪表盘显示「系统故障，请立即停车」
你看，Android 本身没有「保证」安全，但它参与了「安全链」的一部分。
五、功能安全开发中的常见坑
避坑指南：
- 不要迷信「Android 原生支持」——Android 没有功能安全认证，所有安全机制都得自己加
- 不要忽略「故障注入测试」——我曾经以为系统很稳定，结果注入一个内存泄漏，整个显示链路就崩了
- 不要等到最后才做安全分析——功能安全要贯穿整个开发周期，越早介入成本越低
六、小结
功能安全不是「加个看门狗」那么简单。它是一套从需求到验证的完整方法论。ISO 26262 给了我们框架，ASIL 帮我们定等级，Android 在其中扮演的是「参与者」而非「保证者」。
我个人习惯在项目启动时就拉上功能安全工程师一起做 HARA（危害分析与风险评估）。虽然前期会多花点时间，但后期返工的痛苦会少很多。
记住一句话：功能安全不是测试出来的，是设计出来的。