自动驾驶安全标准完整解析：从ISO 26262到SOTIF的实战指南

c23fbd47bd656b8700621ff23d40ae3f

为什么自动驾驶需要专门的安全标准

最近几年，自动驾驶从科幻概念变成了实实在在的产品。百度、特斯拉、小马智行这些公司的无人车已经在路上跑了，但问题来了：怎么保证这些车是安全的？

传统汽车行业有一套成熟的安全体系，但到了自动驾驶这儿，发现不够用了。为什么？因为自动驾驶系统太复杂了——摄像头、激光雷达、毫米波雷达、高精地图、深度学习算法，这些东西以前的标准根本没考虑过。

自动驾驶安全的金字塔架构

行业里现在基本形成了一个共识，就是用”金字塔”或者说”马斯洛层次”来理解自动驾驶的安全体系。从下到上分四层：

第一层：功能安全（ISO 26262）

这是地基，解决的是”机器人本身是不是正常的”这个问题。就像人要开车，首先得是个身体健康、心智正常的人，不能有严重的身体缺陷或精神疾病。

对应到自动驾驶系统，就是要保证软硬件没有重大缺陷。这套标准叫ISO 26262，是从工业安全标准演化来的，2011年正式发布，现在已经是汽车行业的强制性要求。

第二层：预期功能安全（SOTIF/ISO 21448）

这层解决的是”认知问题”。一个小婴儿要学会认识世界——这是车、那是行人、前面是红绿灯。自动驾驶系统也一样，它用深度学习算法来”认识”周围环境。

但问题来了：深度学习算法不是百分之百准确的。你给它看一张图片，它可能认出是行人，也可能认不出来。特斯拉在杭州撞垃圾车就是个典型案例——系统之前没见过这种车，识别不出来。

SOTIF（Safety Of The Intended Functionality）标准就是解决这个问题的。它的核心思想是：既然算法不能百分之百准确，那我们就要通过大量测试，让”已知”的范围足够大，”未知”的范围足够小。

第三层：多角色安全（Market Agent Safety）

这层解决的是”怎么跟别人共享道路”的问题。人开车要学交规，机器开车也得懂规矩。

Mobileye提出了一个RSS（Responsibility-Sensitive Safety）理论，核心观点是：自动驾驶系统要保证三件事——

No Accident（最理想，但不可能百分之百做到）
No Guilty（这是必须的，事故责任不能在我）
No Blame（尽量做到，让社会能接受）

举个例子：有人闯红灯过马路，按交规你可以不让他（责任不在你），但实际开车时你还是会让，因为撞了人社会舆论受不了。自动驾驶系统也要考虑这种情况。

第四层：政府法律法规

这是顶层，目前还在制定中。美国NHTSA（高速公路交通安全局）出了一个指导文件，提出了12条原则。国内的法规也在起草，但大家都还在看美国怎么搞。

有意思的是，现在还出现了一些”集大成”的标准，比如UL 4600，想把功能安全、SOTIF、网络安全这些都整合到一起，以后大家读一本就够了。不过目前还是草稿阶段。

功能安全：自动驾驶的基石

功能安全到底管什么

简单说，功能安全管两件事：

系统性失效：人为引入的bug。比如工程师心情不好写了段有问题的代码，或者硬件设计有缺陷
随机失效：硬件自己坏了。任何电子元器件都会坏，只是时间早晚的问题

功能安全的整个ISO 26262标准有800多页，分成12本书。刚入行的人看着头大，但核心思想其实就两条：

第一，流程管控。通过严格的流程来防止人出错。从需求分析、系统设计、编码实现到测试验证，每一步都有详细的要求，而且要做好文档追溯。这套方法叫”系统工程”（System Engineering）。

第二，安全机制。通过技术手段来诊断和容错。最简单的例子就是看门狗（Watchdog）——单片机配个看门狗来监控主程序有没有跑飞。再比如油门踏板用两个传感器，互相对比来判断是否失效。

功能安全把风险分了四个等级：ASIL A、B、C、D。等级越高，要求越严格。对自动驾驶系统来说，涉及横向控制（转向）和纵向控制（加减速）的部分，基本都要做到ASIL D。

功能安全在自动驾驶上的应用

整车架构设计

做自动驾驶的功能安全，最重要的是顶层架构。现在比较主流的方案是”双控制器冗余”：

主控制器：负责正常的自动驾驶功能
副控制器（Fallback控制器）：主控出问题时接管，执行安全停车等动作

这两个控制器是完全独立的，各有自己的传感器输入和执行器输出通道。这样就避免了”单点失效”——不会因为某一个点坏了就导致整个系统完蛋。

奥迪A8的L3系统就是这么设计的。它的策略是：如果主控诊断出问题，系统会切换到”失效静默”模式，由副控制器接管，在本车道内缓慢停车。因为A8定义的使用场景是城市封闭环路（比如高速内环），车速上限60公里/小时，所以在本车道停车是可以接受的。

但如果是高速公路自动驾驶，情况就不一样了。你在高速上突然停车是非常危险的，所以L3系统会给驾驶员10秒左右的接管时间，同时尝试把车开到应急车道。如果驾驶员还是不接管，那就只能在本车道缓慢停车了——这叫”最小风险状态”（Minimal Risk Condition, MRC）。

传感器的功能安全

传感器是自动驾驶的”眼睛”，但每种传感器都有自己的功能安全等级上限：

摄像头、毫米波雷达、激光雷达：目前最高做到ASIL B
执行器（ESP、EPS、VCU等）：可以做到ASIL D
域控制器：主控避免错误输出可以做到ASIL D，但避免功能丢失只能做到ASIL B

为什么传感器做不到ASIL D？因为单个传感器本身的可靠性有限。解决办法是用”冗余”和”多样性”——同时用多个不同类型的传感器，通过融合来提高可靠性。

有个很实用的方法叫”FOV网格分析”：把所有传感器的视野（Field of View）画在一张图上，然后打网格，每个格子标注能被几个传感器覆盖。如果某个关键区域只有一个传感器覆盖，那就是潜在的安全盲区，需要调整传感器布局。

控制器的功能安全

控制器的功能安全设计有个经典框架叫”三层监控”：

第一层：功能层。这是正常的业务逻辑，比如障碍物识别、路径规划、运动控制等。

第二层：功能监控层。用一个不同的算法来监控功能层的输出是否合理。比如用深度学习识别障碍物，就用一个传统算法来做粗略判断——不需要很精确,只要能判断”结果是否在合理范围内”就行。这个范围就叫”安全信封”（Safety Envelope）。

举个例子：功能层算出前方障碍物距离是80米，功能监控层算出来是个范围（60-120米）。只要80落在这个范围内，就认为功能层的结果是可信的。如果功能层突然算出来是300米，明显超出合理范围，就说明可能出问题了。

第三层：控制器监控层。这是传统功能安全的内容，监控硬件是否失效、程序流是否正常、数据流是否被破坏等等。

这套三层监控的思路现在被广泛应用。你去看百度、Waymo、Intel发布的安全报告，基本都能看到类似的架构。

f929d36f03ebac252f0c377c5d33b97d

功能安全的工作量

做功能安全不是一件轻松的事。一个完整的自动驾驶项目，功能安全相关的工作量大概占到总工作量的30-40%。具体包括：

危害分析与风险评估（HARA）：识别所有可能的危害场景
安全概念设计：定义安全目标和安全需求
系统/软件/硬件安全分析：每一层都要做失效模式分析
安全机制设计与实现：写代码、做硬件设计
安全验证：测试、评审、评估

这还不算最难的。最难的是”思维方式的转变”。传统工程师习惯想”这个功能怎么实现”，做功能安全要想”这个功能可能怎么失效，失效了会造成什么后果，怎么防止失效”。

预期功能安全（SOTIF）：应对深度学习的不确定性

为什么功能安全不够用

几年前，我们团队去给一些自动驾驶创业公司做功能安全咨询。有个AI大佬问了个很尖锐的问题：”我的障碍物识别算法成功率不是百分之百，是个概率算法。你们功能安全能解决这个问题吗？”

当时我们懵了。因为传统功能安全假设的是”算法是确定的”——比如温度传感器，读数就是读数，不存在”有80%的概率读对”这种事。但深度学习算法确实是这样的，它本质上是个黑盒子，你不知道它内部到底发生了什么。

还有个问题：传感器的物理限制。摄像头会有畸变、白平衡问题，镜头热胀冷缩会导致成像不一致，感光元件也会有坏点。毫米波雷达有多径反射，对不同材质的反射强度差异很大——塑料桶反射很弱，金属物反射很强。这些都不是”失效”，而是传感器与生俱来的特性。

SOTIF标准就是在这个背景下诞生的。2019年ISO 21448发布了公开草案（PAS版），目前还在完善中。

SOTIF的四象限理论

SOTIF用一个很巧妙的思路来分析安全：把所有场景分成四个象限——

横轴是”已知”和”未知”，纵轴是”安全”和”不安全”：

已知安全：测试过，没问题。这是好事，不用管
已知不安全：测试过，发现有问题。这是重点要解决的
未知安全：没测过，但碰到了也没事。这是好事，不用管
未知不安全：没测过，碰到了会出事。这是潜在风险

SOTIF要做的就是：把象限2（已知不安全）变成象限1（已知安全），同时让象限4（未知不安全）的面积尽可能小。

关键问题是：怎么让整个圆（所有场景的集合）是固定的？答案是”明确定义使用场景”（ODD, Operational Design Domain）。

比如你的自动驾驶系统是做高速公路的，那就不要去考虑山区土路、停车场这些场景。ODD定义得越清晰，圆的面积就越小，测试的目标就越明确。

怎么解决”已知不安全”

对付象限2有几种方法：

1. 改进算法 最直接的办法就是提高算法准确率。比如原来误检率10%，通过改进降到1%。

2. 增加冗余 视觉识别不行？加个激光雷达。两种不同技术融合后，漏检率会大幅下降。

3. 提升性能 算法不变，但提高芯片算力。比如原来30帧/秒，现在60帧/秒。即使连续误检10帧，原来需要0.33秒，现在只需要0.16秒，安全性就提高了。

4. 限制功能 实在搞不定，就从ODD里把这个场景扣掉。

举个真实的例子：某泊车系统在重庆推广时遇到问题。重庆是山城,很多停车场建在悬崖边。长安汽车要求系统能识别悬崖，不能开到悬崖下面去。但纯视觉算法识别不出悬崖——这是技术限制，不是失效。

怎么办？要么增加专门的”悬崖传感器”（比如超声波测深），要么就在用户手册里明确说明”本系统不支持悬崖场景”，并通过HMI提示驾驶员。

怎么解决”未知不安全”

这个只有一个办法：测试、测试、再测试。

但问题来了：要测多少才算够？

有人算过一笔账：如果要穷举测试一张1080p图片的所有可能像素组合，需要的测试次数远远超过宇宙中原子的数量。显然不可能这么干。

所以现在的做法是：设定一个测试目标（比如测100万公里或1000小时），只要在这个范围内没出事，就认为”已知”的面积足够大了，剩下的”未知”面积可以接受。

这个测试目标怎么定？目前还没有统一标准。有人提出”要比人类驾驶员安全10倍”，那人类驾驶员的事故率是多少？按照美国数据，大概是每1亿英里1次致命事故。所以自动驾驶系统至少要测10亿英里？

这显然不现实。所以业界现在大量使用仿真测试。比如Waymo说他们在仿真环境里跑了几十亿英里。英伟达甚至搭建了一套游戏级别的高清仿真系统，随机生成各种场景来测试算法。

SOTIF的难点

SOTIF现在最大的挑战是”怎么测”。功能安全有明确的测试目标（针对需求的验证测试），但SOTIF的验证测试是开放式的——你要尽可能多地覆盖各种场景。

目前业界的做法是：

场景库建设：收集真实道路上的各种边缘场景
仿真测试：在虚拟环境里跑大量场景
封闭场地测试：在测试场复现一些典型场景
开放道路测试：真车上路，积累里程

这四种方法各有侧重，需要配合使用。

网络安全：自动驾驶的新战场

为什么汽车需要网络安全

以前汽车是个封闭系统，顶多通过OBD接口连一下诊断仪。但现在的智能汽车变了——联网、OTA升级、远程控制，这些功能带来便利的同时也带来了风险。

2015年，两个白帽黑客远程控制了一辆正在高速公路上行驶的Jeep自由光，操控了转向、刹车，最后把车开进了沟里。这个事件震惊了整个行业，也催生了汽车网络安全标准ISO 21434。

对自动驾驶系统来说，网络安全的重要性更高。因为一旦被攻击，后果可能是批量的、灾难性的。

设想一个场景：某租车公司买了1万台带自动驾驶功能的车投放运营。一个间谍租车后，在偏僻地方把车拆开，装了个小装置。这个装置平时不工作，但可以远程激活，激活后向执行器发送错误指令。

如果在同一天激活所有被改装的车，让它们同时”发疯”撞人，这就是一起大规模恐怖袭击。攻击者甚至可以在期货市场上做空相关股票，通过这种方式获利。

这种场景在传统IT安全里不会考虑——你不会设想黑客会偷你的电脑，拆开来装个硬件木马。但在汽车行业，这是必须防范的。

ISO 21434的核心思路

ISO 21434标准目前还是草稿（DIS版），但基本框架已经清晰了。总共100多页，比ISO 26262简洁很多。

这个标准的思路跟功能安全很像：

威胁分析与风险评估（TARA，对应功能安全的HARA）：分析可能的攻击手段
网络安全概念设计：定义防御措施
网络安全等级评估（CAL，对应功能安全的ASIL）：根据风险评定等级
安全机制实现与验证：在系统/软件/硬件层面落地

但网络安全有几个明显不同：

第一，分析的是”恶意行为”而不是”失效”。功能安全分析的是”东西坏了会怎样”，网络安全分析的是”别人想搞你会怎样”。这要求你了解各种攻击手段。

第二，非常重视后市场监控。一旦发现新的攻击方式，需要立即打补丁。这跟功能安全不同——功能安全的产品一旦定型，基本不会大改。

第三，强调应急响应小组（CSIRT, Cybersecurity Incident Response Team）。要有专门的团队实时监控市场上的安全事件，快速响应。

4de5032e3f4909627506f24edaac4b06

自动驾驶的网络安全特殊性

汽车网络安全跟传统IT安全有些不同：

1. 传感器攻击 这是汽车特有的攻击面。比如GPS欺骗——发射伪造的GPS信号,让你的定位系统以为自己在别的地方。现在已经有这种攻击设备了，淘宝上甚至能买到简化版的”GPS干扰器”。

好消息是，一些高端GNSS模块（比如u-blox的新产品）已经能够识别和抵御GPS欺骗攻击。

2. 后装设备攻击 黑客可以通过改装车辆来植入恶意硬件。这在IT领域不用考虑，但在汽车领域必须防范。

应对措施包括：硬件加密芯片（HSM）、防拆检测、数字签名验证等。

3. 逆向工程防护 要防止攻击者拆解控制器、破解固件、分析CAN矩阵。这需要在软硬件层面都做保护。

4. OTA升级安全 远程刷写固件很方便，但如果黑客伪造升级包呢？所以需要数字签名、安全启动等机制。

自动驾驶网络安全的最佳实践

业界总结了一些常见的防御措施：

1. 最小化接口（Minimize Tamper Interface）减少不必要的物理接口。比如量产车上不要留调试接口,容易被利用。

2. ECU间通信加密 现在很多自动驾驶系统的CAN报文都是明文，拿台设备接上去就能监听。这个必须要改，至少关键报文要加密。

3. 防止嵌入式软件逆向 在代码层面做混淆、加壳,增加逆向难度。

4. GPS防欺骗 选用带防欺骗功能的GNSS模块。

5. 软件刷写保护 使用数字签名、安全启动、硬件加密模块（HSM）等技术，确保刷入的软件是可信的。

6. 最小权限原则 不要给用户和模块不必要的权限。

7. 纵深防御（Defense in Depth）一件事情要有多层防护：首先防止攻击发生，其次能够检测到攻击，第三能够在攻击发生后补救，第四能够验证防御是否有效。

8. 安全擦除考量 如果检测到攻击,是否要擦除数据？这要慎重，因为数据记录对事故分析很重要。如果黑客利用”安全擦除”机制来删除行车记录,会影响保险理赔。

网络安全的工作流程

跟功能安全一样，网络安全也是从正向设计开始：

威胁建模：列出所有可能的攻击面
资产识别：哪些是需要保护的（算法、密钥、个人数据等）
攻击树分析：攻击者会通过什么路径达到目的
风险评估：评估每种攻击的可能性和影响
防御措施设计：针对每种攻击设计对应的防御
渗透测试：找白帽黑客来攻击你的系统，看防御是否有效

这里面最关键的是渗透测试（Penetration Testing）。现在有专门的公司提供这种服务——他们会用各种攻击手段来测试你的系统，找出漏洞。

网络安全的供应链

好消息是,网络安全的供应链比较成熟：

攻击测试服务商：提供渗透测试服务（不会把攻击手段直接卖给你）
防御方案提供商：提供加密芯片、安全模块、入侵检测系统等
咨询认证机构：TÜV、DNV等传统功能安全认证机构也开始做网络安全认证

坏消息是，这套体系还在建立中，标准也还没最终定稿，所以现在大家都在摸索。

e6821f7c253ddaf9d6497edeebecbd60

三大标准的关系与协调

很多人会问：ISO 26262、ISO 21448、ISO 21434这三个标准是什么关系？在实际项目中怎么协调？

目前行业里有两种做法：

第一种：统一部门管理 把功能安全、SOTIF、网络安全放在一个部门，做一套完整流程。比如做一次Item Definition（功能定义）、一次威胁和风险分析，但分析时同时考虑失效、功能限制、恶意攻击三个维度。

这种做法的好处是避免重复工作，缺点是对团队要求很高——既要懂功能安全，又要懂SOTIF和网络安全。

第二种：分开但协同 功能安全和SOTIF合在一起（因为思路比较像），网络安全独立。但很多文档是共享的，定期开联合评审会。

目前大部分公司采用第一种做法，因为这三个标准的方法论确实很像，统一管理更高效。

未来趋势和职业发展建议

标准的发展方向

SOTIF会成为强制性标准 目前ISO 21448还在草稿阶段，但大概率会在2026-2027年正式发布，成为跟ISO 26262一样的强制性要求。
网络安全的重要性会越来越高 随着V2X、5G、云端互联的普及，汽车越来越”在线”，网络安全会变得跟功能安全一样重要。
可能出现”大一统”标准 像UL 4600这种试图整合所有安全标准的努力会继续，未来可能真的有一套标准覆盖所有方面。
测试和验证会成为重点 SOTIF的核心挑战是验证，未来会有更多仿真工具、测试场景库、验证方法论出现。

对功能安全工程师的建议

如果你已经有功能安全背景，想进入自动驾驶领域，建议：

深入理解标准 ISO 26262要烂熟于心，能告诉别人”这样做违反了标准第几条”。标准就像法律，你得当个”律师”。
学习自动驾驶技术 了解传感器原理、融合算法、深度学习基础，知道自动驾驶系统是怎么工作的。你不需要会写代码，但要能跟算法工程师对话。
积累落地经验 知道标准怎么要求是一回事，知道怎么落地是另一回事。多参与实际项目，了解业界的Best Practice。
拓展到SOTIF和网络安全 这两个方向人才缺口更大。SOTIF现在处于萌芽期，谁先掌握谁就有优势。网络安全虽然有IT背景的人竞争，但汽车网络安全有其特殊性，懂车的人更有优势。