172、影像系统安全与可靠性：功能安全标准与故障容错设计去年夏天，我在产线盯一个车载环视系统的量产导入，凌晨三点，测试台架突然报出一帧诡异的图像——右视摄像头画面出现半幅雪花，但系统自检日志显示“正常”。更麻烦的是，这帧错误图像被直接送入了泊车路径规划模块，导致虚拟车位线偏移了30厘米。要不是测试工程师眼尖，这批次车可能就带着“间歇性幽灵车位”出厂了。这个坑让我重新审视影像系统的安全设计。很多人觉得影像系统嘛，画面花一点、卡一帧，大不了重启。但在车规、医疗、工业场景下，一帧错误图像可能意味着转向误判、诊断漏检、甚至人身伤害。今天这篇笔记，我就把这些年踩过的功能安全坑、容错设计套路，以及ISO 26262、IEC 61508在影像系统中的落地经验，掰开揉碎讲清楚。功能安全标准：别当文档搬运工ISO 26262（汽车）和IEC 61508（通用）是影像系统安全设计的两座大山。但很多团队把功能安全做成了“文档工程”——堆一堆FMEA表格、画几个安全目标，代码里却连基本的故障检测都没有。影像系统的特殊性在于：错误不是二进制的。CPU挂了是硬故障，但ISP输出一帧偏色、畸变、或者时序错乱的图像，是软故障。软故障最难检测，也最容易绕过安全机制。我见过一个项目，安全目标写的是“图像传输延迟不超过100ms”，但实际代码里只监控了硬件中断响应时间，完全没考虑ISP pipeline内部因为参数配置错误导致的帧率抖动。结果路试时，某次场景切换触发了ISP的自动曝光震荡，帧率掉到8fps，但硬件中断依然准时——因为中断是DM
