ISO 26262 不是法律，但它是汽车半导体的入场券
一篇文章讲清功能安全的底层逻辑：两类故障、两种应对策略，以及 ISO 26262 如何重塑汽车半导体行业的游戏规则。
自动驾驶每往前走一步，功能安全的门槛就抬高一级。ISO 26262 从 2011 年发布第一版至今，适用范围已经从 3500kg 以下的乘用车扩展到卡车、公共汽车甚至两轮机动车。在中国，它被转化为国标 GB/T 34590，2018 年起正式施行。全球范围内，功能安全合规不再是加分项，而是进入汽车供应链的入场券。
但对很多工程师来说，" 功能安全 " 四个字仍然停留在 " 听说过 " 的层面。它和 " 本质安全 " 有什么区别？ISO 26262 到底在要求什么？半导体企业为什么要从规格阶段就把安全概念纳入设计？
从铁路道口理解功能安全
安全的定义是 " 免于不可接受的风险 "。这是 ISO/IEC Guide 51 给出的标准定义——没有不可接受的高风险状态，就是安全。
以铁路和公路的交叉口为例，要避免火车和汽车相撞，有两种截然不同的思路。第一种是建立交桥，把铁路和公路在物理上彻底分开，碰撞根本不可能发生——这是 本质安全（Inherent Safety），通过消除危险原因来确保安全，绝对可靠但成本高昂。
第二种是设置铁路道口：安装传感器检测火车接近，触发警报器、降下栏杆；火车通过后再升起栏杆。铁路和公路仍然交叉，但通过一套功能系统把碰撞风险降低到可接受水平——这就是 功能安全（Functional Safety）。
功能安全的代价相对较低，但引入了一个棘手的问题：如果传感器坏了怎么办？警报器不响、栏杆不落，" 安全措施 " 反而变成了 " 危险掩护 "。因此功能安全必须配套两种设计思路。
故障安全（Fail Safe）：故障发生时系统自动导向安全状态，比如传感器自诊断出问题就默认降下栏杆。冗余设计则是另一条路：关键部件双重配置，一个坏了另一个顶上。铁路道口的双红灯、汽车的前灯和尾灯，都是冗余设计的日常案例——不是为了好看，而是即使一个灯灭了也能确保最低限度的安全。
两类故障，两种应对
功能安全的底层逻辑建立在一个朴素的前提上：人会犯错，东西会损坏。这两句话分别对应两类性质完全不同的故障，ISO 26262 的全部要求，都是围绕这两类故障展开的。
系统性故障是设计阶段就隐含的缺陷，通俗说就是 Bug。它不是制造出来的问题，而是 " 想错了 " 的问题。代码里的逻辑漏洞、需求理解偏差、接口定义错误，都属于这一类。
防止的方法是建立严格的设计流程——从需求规格到架构设计、代码实现、测试验证，每个阶段都有明确的输入输出和评审机制，确保 Bug 在早期被发现。所有的软件故障都是系统性故障。
随机性故障是制造后发生的硬件故障，无法完全预防。芯片上的晶体管可能因为温度循环而退化，焊点可能因为振动而断裂，存储单元可能因为宇宙射线而翻转。对于随机性故障，方法不是 " 防止发生 " 而是 " 发生后应对 "——在产品中设计安全机制，确保即使硬件出故障，系统也能检测到并进入安全状态。
ISO 26262 的核心框架
ISO 26262 是专门针对汽车电气/电子系统的功能安全标准，基于 IEC 61508——功能安全的 " 母标准 "——针对汽车场景裁剪和扩展而成。IEC 61508 覆盖工厂、发电厂、铁路、医疗设备等所有领域，而 ISO 26262 专注于汽车。
其他行业也有各自的衍生标准：流程工业用 IEC 61511，工业机械用 IEC 62061，铁路用 IEC 62278，医疗设备用 IEC 60601。
值得强调的是，ISO 26262 不是法律。不遵守它不违法。但现实是，没有哪家汽车制造商会采购不符合 ISO 26262 标准的产品。通过按照 ISO 26262 设计电气/电子系统，汽车制造商能够证明自己尽到了安全义务——即使发生了系统故障，也不会对驾驶员、乘客或行人造成伤害。
同时，ISO 26262 以 AUTOSAR 等软件架构标准和 IATF 16949 质量管理体系为前提，先有质量管理基础，再叠加上功能安全要求。
满足 ISO 26262 标准，需要从两个维度同时发力。
流程支持对应系统性故障。它要求企业建立完善的开发流程体系——公司内部规定、开发标准、程序文件，确保每个开发阶段都有明确的文档记录和评审机制。这些文档和评审记录既是质量保证手段，也是应对产品责任（Product Liability）的法律证据。
如果产品因缺陷造成人身伤害或财产损失，设计者需要证明自己不存在设计缺陷，而流程文档就是最有力的证据。
产品支持 对应随机性故障。它要求在产品设计中加入安全机制——在某个功能模块发生故障时，能够检测到故障并执行适当的安全响应。这意味着在设计初期的规格探讨阶段，就要逐个分析每个功能可能发生的故障模式，以及针对每种故障应该设置什么样的安全机制。
ISO 26262 第二版在三个方向做了重要扩展。适用范围从乘用车扩大到卡车、公共汽车和两轮机动车（新增 Part 12）；新增 Part 11 半导体指南，为芯片设计者提供了实践参考；大量增加了目的描述、备注和案例，标准的可操作性显著提升。
半导体为什么是功能安全的关键
随着汽车电子化程度持续攀升，半导体在功能安全中的角色越来越关键。以车载显示系统为例，仪表盘从机械指针变成 LCD 液晶屏，后视镜从玻璃镜片变成电子摄像头加显示屏。这些显示装置的核心任务是向驾驶员传递信息，如果发生故障，后果不只是 " 看不了 "，而是 " 看错 "。
黑屏不可怕，驾驶员会立刻意识到出了问题。真正危险的是 错误显示。车速里程表显示卡顿，显示的速度低于实际车速，驾驶员可能毫无察觉地超速。电子后视镜的画面出现延迟，后方来车已经逼近，屏幕上却还没有出现——如果此时变道，后果不堪设想。
这意味着车载显示系统的安全设计必须确保 " 即使出故障也要让驾驶员知道出了故障 "。实际的做法是：在显示系统中加入实时数据监测，当检测到画面卡顿或数据异常时，主动切换到错误警告画面或黑屏，确保驾驶员能感知到异常。这种 " 故障导向安全 " 的设计理念，正是功能安全在半导体层面的具体体现。
要实现这一目标，液晶面板的芯片组需要构成一个完整的检测网络。时序控制器监测来自 GPU 的图像数据，检测异常时通知微控制器显示警告画面。源极驱动器和栅极驱动器互相校验显示状态，随时反馈损坏、剥落等故障信息。电源管理 IC 持续监测供电电压，异常时自动保护并尝试恢复。
另一个典型场景是 嵌入式系统 中 ECU 内部的电源监控。汽车 ECU 需要为 MCU、传感器、电机驱动器、CAN 收发器等多个子系统提供不同规格的电源。电源异常可能导致 ECU 整体失控，因此需要独立的电源监控 IC 实时监测各路电压，在欠压或过压时通知 MCU 执行安全处理。
同时，监控 IC 本身也需要自我诊断功能——内置多重基准电压互相校验，启动时自动检测内部功能是否正常，确保 " 监控者 " 本身是可靠的。
功能安全对半导体行业提出的要求，可以归结为一句话：从规格阶段就把安全概念纳入设计。半导体产品封装在黑色树脂里，内部包含成千上万的晶体管和电阻，复杂度极高。如果等芯片设计完成后再考虑功能安全，几乎不可能补上。
正确的做法是在定义产品规格时，就同时定义安全等级、故障检测机制和安全响应策略。这也是为什么 ISO 26262 第二版专门新增了半导体指南——芯片设计者需要一个清晰的框架来理解自己的责任边界。
功能安全不是某个部门的事，也不是项目末期的一份检查清单。它是一种从需求阶段就嵌入产品基因的设计哲学——先承认 " 人会犯错、东西会损坏 "，然后用流程防止人为错误，用安全机制应对硬件故障。对于半导体企业来说，能否在产品定义阶段就把功能安全纳入考量，已经不是 " 做得好不好 " 的问题，而是 " 能不能上桌 " 的问题。