自动驾驶比人类驾驶更安全吗？从ODD、ISO 26262到ADS仿真的工程视角

1. 从热搜词里读懂这个问题的真实分量“自动驾驶汽车真的比人类驾驶汽车更安全吗”这个问题在技术圈里被反复拿出来讨论但每次讨论的落脚点都不太一样。有人拿事故率数据说事有人搬出功能安全标准还有人直接甩出一句“机器不会疲劳驾驶”就结束了。我做了几年自动驾驶相关的系统测试和仿真验证接触过不少ADS自动驾驶系统的开发和验证流程也跟做ISO 26262功能安全的同事有过不少交集。说实话这个问题没有一个简单的“是”或“否”能回答。先把这个问题的核心关键词拆开看自动驾驶、ADS、ISO 26262、UL 4600、ODD。这几个词基本上覆盖了从技术实现到安全认证的完整链条。ADS是Autonomous Driving System的缩写也就是自动驾驶系统本身ISO 26262是道路车辆功能安全的国际标准主要管的是电子电气系统的功能安全UL 4600则是专门针对自动驾驶产品安全的标准关注的是全生命周期内的安全论证ODD是Operational Design Domain运行设计域说白了就是“这套系统在什么条件下能工作、什么条件下不能工作”。热搜词里还出现了“决策延迟32.8毫秒”这个具体数字以及“自动驾驶数据集”“自动驾驶算法”“ADS仿真”这些偏工程落地的词。这说明大家关心的不只是哲学层面的“机器vs人”更关心具体的工程指标和验证方法。还有一条热搜是“ets2la在《欧洲卡车模拟2》中实现智能车道保持的自动驾驶插件”这其实反映了一个很有意思的现象——很多自动驾驶的入门者是从游戏模拟器开始接触车道保持、路径规划这些概念的。虽然游戏模拟和真实道路差距巨大但作为算法验证的早期环节它确实能帮人快速理解感知-决策-执行的闭环逻辑。那这篇文章适合谁看如果你是刚入行做自动驾驶测试或功能安全的工程师或者你是对自动驾驶安全性有疑虑的普通用户又或者你是做仿真验证、数据集标注的技术人员这篇文章都会给你一些可以直接参考的思路和数据。我不会给你一个“自动驾驶一定更安全”或者“自动驾驶就是不行”的结论而是把影响安全性的几个核心维度拆开让你自己判断在什么条件下、什么场景下自动驾驶的安全性到底处于什么水平。2. 安全性对比的核心维度拆解2.1 人类驾驶的事故特征与自动驾驶的事故特征完全不同要比较谁更安全首先得搞清楚“安全”怎么定义。人类驾驶的事故数据有非常成熟的统计体系比如每百万英里的事故率、致死率、受伤率。美国NHTSA的数据显示人类驾驶大约每百万英里发生1.5到2.5起需要报警的事故。但这个数字有个很大的问题它把不同道路类型、不同天气、不同时间段的数据混在一起了。如果你单独看高速公路白天正常天气下的人类驾驶事故率会低很多但如果你看夜间、雨雪天气、乡村道路事故率会飙升。自动驾驶的事故特征跟人类完全不同。人类驾驶的事故大头是追尾、变道刮擦、路口碰撞原因主要是分心、疲劳、判断失误、酒驾。自动驾驶的事故目前更多集中在几个特定场景一是感知系统对异形车辆、静止障碍物、施工区域的识别失败二是决策系统在复杂交互场景下的保守或激进策略不当三是接管过程中的交接失败。我印象很深的一个案例是某自动驾驶测试车在路口左转时对向有车直行人类驾驶员通常会判断对方车速和距离后决定是抢行还是等待但自动驾驶系统因为安全策略过于保守在路口犹豫了太久结果被后车追尾。这种事故在人类驾驶中极少发生但在自动驾驶测试中并不罕见。所以比较安全性的时候不能只看总事故率得看事故类型分布和场景覆盖率。自动驾驶在ODD范围内的事故率可能远低于人类但一旦超出ODD事故率会急剧上升。而人类驾驶虽然整体事故率高但在各种极端场景下都有一定的应对能力因为人类有常识推理和灵活应变的能力。2.2 ODD自动驾驶安全性的“边界条件”ODD这个概念是理解自动驾驶安全性的钥匙。它定义了一套系统能正常工作的条件范围包括道路类型高速公路、城市道路、乡村道路、地理区域是否有限制、天气条件晴天、雨天、雪天、雾天、光照条件白天、夜间、黄昏、交通密度畅通、拥堵、速度范围等。任何一套ADS都必须明确自己的ODD超出ODD时要么请求人类接管要么安全停车。我见过不少团队在定义ODD时过于乐观把“小雨”也写进了ODD结果测试时发现摄像头被泥水遮挡后感知性能骤降。后来他们把ODD收窄到“无降水”但用户在实际使用中并不会严格遵守这个限制这就产生了ODD边界模糊的问题。ISO 26262和UL 4600都强调要对ODD边界进行严格验证但标准本身并不规定ODD应该怎么定这完全是产品定义的问题。从安全性对比的角度看人类驾驶没有明确的ODD人类可以在任何天气、任何道路上开车虽然事故率不同但至少不会因为“超出ODD”而突然罢工。自动驾驶的优势在于ODD内的一致性——它不会因为昨晚没睡好而走神不会因为跟副驾聊天而忽略前车刹车。但劣势也很明显一旦遇到ODD外的场景它的表现可能远不如一个谨慎的人类驾驶员。2.3 决策延迟32.8毫秒意味着什么热搜词里“决策延迟32.8毫秒”这个数字很有意思。人类驾驶员的反应时间通常在200到500毫秒之间取决于是否预期到事件发生。如果是预期内的刹车可能200毫秒左右如果是突发状况可能需要500毫秒甚至更长。32.8毫秒的决策延迟意味着自动驾驶系统从感知到决策输出的时间远快于人类。但这里有个陷阱决策延迟只是整个链路中的一环。完整的链路是感知延迟决策延迟执行延迟。感知延迟包括摄像头曝光、图像处理、目标检测、跟踪决策延迟包括路径规划、行为决策执行延迟包括线控底盘的响应时间。32.8毫秒可能只是决策模块的计算时间加上感知的几十毫秒和执行的一百多毫秒总延迟可能还是在150到250毫秒之间。这个数字跟人类反应时间比确实有优势但优势没有32.8毫秒看起来那么大。更重要的是延迟低不代表决策质量高。人类驾驶员虽然反应慢但决策是基于对场景的深度理解——他知道那个骑电动车的人可能会突然变道因为他看到了对方在回头看。自动驾驶系统目前还很难做到这种意图预测它更多是基于当前轨迹的外推。所以延迟低只是必要条件不是充分条件。3. 功能安全标准到底管什么3.1 ISO 26262的适用范围与局限ISO 26262是功能安全领域最常被引用的标准但它其实主要针对的是电子电气系统的功能安全而不是自动驾驶系统的整体安全性。它关注的是系统失效导致的风险比如传感器故障、处理器死机、通信丢包等。它要求对每个危害事件进行ASIL等级评估A到DD最高然后根据等级采取相应的安全措施。但ISO 26262有一个根本性的局限它假设系统的功能定义是明确的然后去管理功能失效的风险。而自动驾驶系统面临的一个核心问题是功能本身就不完全明确——在复杂场景下系统应该怎么做才是安全的这个问题ISO 26262回答不了。比如“前方有行人站在路边系统应该减速还是绕行”这不是功能失效问题而是功能定义问题。我参与过一个L2级辅助驾驶系统的功能安全评估当时团队花了大量时间在FMEA失效模式与影响分析上把每个传感器的每种失效模式都列出来然后设计冗余和监控机制。这套方法对L2很有效因为L2的责任主体还是人类驾驶员系统只需要在失效时及时退出并提醒驾驶员即可。但到了L3及以上系统在ODD内要承担全部责任ISO 26262就不够用了。3.2 UL 4600的补充视角UL 4600是专门为自动驾驶产品安全制定的标准它的思路跟ISO 26262很不一样。它不要求你证明系统“没有失效”而是要求你提供一个安全论证Safety Case说明你为什么认为系统是安全的。这个安全论证需要覆盖全生命周期包括设计、开发、测试、部署、运维、更新。UL 4600的一个核心概念是“安全性能指标”而不是单纯的失效概率。比如它会要求你定义什么是“可接受的风险水平”然后通过数据证明系统达到了这个水平。这比ISO 26262更灵活但也更主观。我见过一些团队在写安全论证时把“可接受风险”定义得过于宽松结果被评审专家质疑。后来他们参考了人类驾驶的事故率数据把目标定在“不高于人类驾驶员的平均事故率”这才通过了评审。UL 4600还特别强调持续安全的概念。因为自动驾驶系统是持续迭代的每次OTA更新都可能引入新的风险。所以安全论证不是一次性的而是需要持续维护的。这一点跟ISO 26262的一次性认证思路很不一样。3.3 两个标准怎么配合使用在实际项目中ISO 26262和UL 4600通常是配合使用的。ISO 26262管底层电子电气系统的功能安全确保传感器、处理器、执行器不会因为随机硬件失效或系统性失效导致危险。UL 4600管上层系统的整体安全论证确保在ODD内的行为决策是安全的。我参与的一个L3级项目就是按这个思路做的底层用ISO 26262做ASIL D的冗余设计包括双电源、双通信、双处理器上层用UL 4600做安全论证定义了ODD、安全性能指标、接管策略、最小风险状态等。两个标准之间有交叉比如接管策略既涉及功能安全接管请求的可靠性也涉及产品安全接管请求的时机是否合理。处理交叉问题时我们通常以更严格的要求为准。4. 数据集与仿真在安全验证中的实际作用4.1 自动驾驶数据集的质量决定验证上限热搜词里出现了“自动驾驶数据集”这确实是安全验证的基础。没有高质量的数据集就无法训练出可靠的感知模型也无法验证决策算法的安全性。目前主流的数据集包括KITTI、nuScenes、Waymo Open Dataset等它们各有侧重KITTI偏重激光雷达和视觉的融合nuScenes强调多传感器和360度覆盖Waymo的数据集则在场景多样性上更丰富。但数据集有一个根本问题它只能覆盖已经发生过或已经被采集到的场景。那些罕见的、极端的、可能导致事故的场景在数据集中的比例往往很低。这就导致模型在训练时对这些场景的学习不足。我见过一个模型在正常跟车场景下表现很好但遇到前方车辆突然掉落货物的场景时完全不知道该怎么处理。后来团队专门采集了一批“掉落物”场景的数据才把这个短板补上。数据集的标注质量也很关键。我见过一些标注团队为了赶进度对远处的小目标只标一个粗略的框结果模型学到的就是“远处的东西可以忽略”。这种标注偏差在测试时可能看不出来但在实际道路上就是安全隐患。所以我现在看一个自动驾驶团队的水平首先看他们的数据集是怎么采集、怎么标注、怎么验证的。4.2 ADS仿真安全验证的加速器ADS仿真是另一个核心环节。真实道路测试的成本极高而且很多危险场景无法在真实道路上复现比如行人突然横穿。仿真可以在虚拟环境中生成大量极端场景快速验证算法的鲁棒性。热搜词里提到的“ets2la”插件虽然是在游戏里做车道保持但它背后的逻辑跟专业仿真工具是相通的都是通过传感器输入生成控制指令然后观察车辆行为。专业的ADS仿真工具包括CarSim、PreScan、CARLA、LGSVL等。CarSim偏重车辆动力学PreScan偏重传感器建模CARLA和LGSVL则是开源的自动驾驶仿真平台。我实际用下来CARLA的场景库比较丰富但传感器模型不够真实LGSVL的传感器模型更接近真实但场景库相对少一些。选择哪个工具取决于你的验证目标如果是验证感知算法传感器模型的真实性更重要如果是验证决策算法场景的多样性和交互性更重要。仿真验证的一个常见误区是过度依赖仿真结果。仿真再真实也无法完全复现真实世界的复杂性和不确定性。我见过一个团队在仿真中跑了上百万公里零事故结果实车测试第一天就遇到了仿真中从未出现过的场景——一个骑三轮车的老人在路口犹豫不决既不走也不停。这种场景在仿真中很难建模因为人的行为不是简单的规则可以描述的。所以仿真验证必须和实车测试结合仿真负责覆盖率和极端场景实车负责真实性和未知场景。4.3 数据集与仿真的闭环最理想的做法是让数据集和仿真形成闭环从真实数据中提取场景在仿真中泛化生成更多变体然后用仿真结果指导数据采集。比如你在真实数据中发现了一个“前车突然刹车”的场景可以在仿真中改变前车刹车时的减速度、两车距离、路面附着系数等参数生成几百个变体场景来测试算法的鲁棒性。如果算法在某些变体下表现不好就说明需要补充这类场景的真实数据来训练。这个闭环说起来简单做起来很难。最大的挑战是场景提取和泛化的自动化。从真实数据中自动提取关键场景需要强大的场景理解能力而场景泛化则需要合理的参数空间定义。我见过一些团队用人工方式做这件事效率极低而且容易遗漏。后来他们引入了基于规则和基于学习的场景挖掘方法效率提升了很多但准确性还需要人工校验。5. 实操如何评估一套ADS的安全水平5.1 第一步明确ODD和运行条件评估任何一套ADS的安全性第一步永远是看它的ODD定义。ODD定义得越清晰、越具体评估起来就越有依据。我通常会要求团队提供一份ODD文档里面至少包含以下内容维度示例验证方法道路类型高速公路、城市快速路地图数据实车测试地理区域特定城市、特定区域GPS围栏地图匹配天气条件无降水、能见度大于500米气象数据传感器融合光照条件白天、夜间有路灯光照传感器图像分析交通密度畅通到中度拥堵雷达/激光雷达目标数速度范围0到80公里/小时车速传感器线控响应这份表格看起来简单但实际做的时候很容易漏项。比如“路面类型”就是一个容易被忽略的维度——柏油路、水泥路、土路、积水路面的附着系数完全不同对刹车距离的影响很大。我见过一个系统在柏油路上表现很好到了水泥路上因为附着系数变化导致刹车距离变长差点追尾。5.2 第二步审查安全论证的结构UL 4600要求的安全论证通常包括以下几个部分系统描述、ODD定义、危害分析、安全要求、安全措施、验证结果、残余风险、持续安全计划。我会重点看危害分析是否全面、安全要求是否可验证、验证结果是否有数据支撑。危害分析常用的方法包括HAZOP危害与可操作性分析、STPA系统理论过程分析等。HAZOP更适合传统的功能失效分析STPA更适合复杂的系统交互分析。我倾向于两者结合使用先用HAZOP找出单点失效再用STPA分析系统间的交互风险。比如“感知系统延迟导致决策系统误判”这种风险HAZOP可能分析不出来但STPA可以。安全要求的可验证性也很关键。我见过一些安全要求写得很模糊比如“系统应确保安全”这种要求根本无法验证。好的安全要求应该是具体的、可量化的比如“在ODD内系统应在检测到前方障碍物后200毫秒内输出减速度不小于4米/秒²的制动请求”。5.3 第三步检查测试覆盖率和通过标准测试覆盖率是评估安全验证充分性的重要指标。我通常会看几个维度的覆盖率场景覆盖率、里程覆盖率、边界条件覆盖率。场景覆盖率是指测试场景占ODD内所有可能场景的比例里程覆盖率是指测试总里程与目标里程的比例边界条件覆盖率是指对ODD边界条件的测试情况。通过标准也很重要。我见过一些团队把通过标准定得很低比如“事故率低于人类驾驶员”就算通过。但人类驾驶员的事故率本身就是一个很宽泛的指标不同地区、不同道路类型的事故率差异很大。更合理的做法是定义场景级通过标准在某个特定场景下系统的事故率应该低于某个阈值或者系统的行为应该符合某个预期。5.4 第四步实车测试与仿真结果的交叉验证最后一步是交叉验证。仿真中表现好的场景在实车测试中是否也表现好实车测试中发现的异常场景在仿真中能否复现如果仿真和实车结果差异很大说明仿真模型或实车测试方法有问题需要排查。我参与过的一个项目就遇到过这种情况仿真中系统在“前车急刹”场景下表现完美但实车测试时发现系统有时会刹车过晚。后来排查发现仿真中的前车减速度是固定的而实车测试中前车驾驶员的减速度是变化的有时大有时小。系统对减速度变化的适应性不够导致刹车时机不准。后来他们在仿真中加入了减速度的随机变化才复现了实车的问题。6. 常见问题与排查技巧实录6.1 感知层面的典型问题问题一静止障碍物识别不稳定。这是自动驾驶感知的经典难题。毫米波雷达对静止物体容易过滤掉因为地面杂波也是静止的摄像头对静止物体的深度估计不够准确激光雷达虽然能测距但点云稀疏时容易漏检。我见过的解决方案包括多传感器融合时给静止物体更高的权重、用视觉语义分割辅助判断、在决策层对静止物体采取更保守的策略。问题二异形车辆识别失败。标准的数据集里主要是轿车、SUV、卡车但实际道路上还有三轮车、拖拉机、改装车、载货超宽的车辆。这些异形车辆在数据集中的比例很低模型容易漏检或误检。我的经验是在数据采集阶段就要刻意覆盖这些场景标注时也要单独分类不要笼统地标成“车辆”。问题三恶劣天气下的性能下降。雨雪雾天气对摄像头和激光雷达的影响很大。摄像头的图像会模糊、对比度下降激光雷达的点云会被雨滴和雪花干扰产生大量噪点。我见过一些团队用去雨去雾算法来预处理图像效果有限。更实际的做法是在ODD中明确限制天气条件同时在感知层加入天气检测一旦检测到超出ODD的天气就请求接管。6.2 决策层面的典型问题问题一交互场景下的博弈失败。在无保护左转、匝道汇入、环岛通行等场景中自动驾驶系统需要与其他车辆进行博弈。人类驾驶员可以通过眼神、车速、车头朝向等线索判断对方意图但自动驾驶系统目前还很难做到。我见过的解决方案包括基于博弈论的决策模型、基于强化学习的交互策略、基于规则的安全兜底。但说实话这些方案在复杂场景下都还不够成熟。问题二接管请求的时机不当。L3级系统在超出ODD时需要请求人类接管。接管请求太早驾驶员可能觉得系统过于保守接管请求太晚驾驶员可能来不及反应。我见过一个系统在接管请求发出后只给驾驶员2秒时间结果测试驾驶员根本来不及接管。后来他们参考了人类驾驶的研究数据把接管时间延长到4秒以上并加入了分级预警。问题三最小风险状态的选择。当系统无法继续运行时需要进入最小风险状态比如靠边停车、保持车道减速等。但选择哪种最小风险状态需要根据场景判断。在高速公路上靠边停车可能很危险因为后方车辆速度很快在市区道路上靠边停车相对安全。我见过一个系统在所有场景下都选择靠边停车结果在高速公路上差点被追尾。后来他们加入了场景判断逻辑高速公路场景下选择保持车道减速并开启双闪。6.3 功能安全层面的典型问题问题一ASIL等级分解不合理。ISO 26262允许对ASIL等级进行分解比如ASIL D可以分解为ASIL B(D)ASIL B(D)。但分解需要满足独立性要求否则分解无效。我见过一些团队为了降低开发成本强行分解ASIL等级但两个分解后的系统并不独立共用电源、共用通信结果被评审专家驳回。问题二安全机制误触发。安全机制的设计目标是“该触发时触发不该触发时不触发”。但实际中经常出现误触发比如监控系统误判处理器故障导致系统频繁进入安全状态。我见过一个系统因为看门狗定时器设置过短在处理器负载高时频繁复位。后来他们调整了看门狗的超时时间并加入了负载自适应机制。问题三安全论证的证据链不完整。UL 4600要求安全论证有完整的证据链从危害分析到安全要求到验证结果每一环都要有据可查。我见过一些团队的安全论证写得很漂亮但一问细节就发现证据链断了——比如危害分析中列出的某个危害在安全要求中没有对应的措施或者在验证结果中没有对应的测试。这种安全论证在评审时很难通过。6.4 常见问题速查表问题类型典型表现排查思路解决方向感知漏检静止障碍物、异形车辆检查数据集覆盖度、传感器融合逻辑补充数据、调整融合权重感知误检地面杂波、雨雪噪点检查滤波参数、天气检测逻辑优化滤波、限制ODD决策保守路口犹豫、频繁接管检查决策阈值、博弈模型调整阈值、引入交互预测决策激进跟车过近、变道鲁莽检查安全距离计算、变道条件增加安全裕度、严格变道条件接管失败接管请求太晚、驾驶员来不及检查接管时间预算、预警分级延长接管时间、分级预警功能安全误触发安全机制频繁介入检查监控阈值、看门狗设置调整阈值、加入自适应安全论证不完整证据链断裂逐条检查危害-要求-验证的对应关系补齐证据、重新评审7. 我个人的一些实操体会做了这几年自动驾驶安全相关的项目我最大的体会是安全性不是一个二元问题而是一个连续谱。一套ADS在某个ODD内可能比人类驾驶员安全10倍但在另一个ODD内可能比人类驾驶员危险10倍。所以讨论“自动驾驶是否比人类安全”时一定要加上限定条件在什么ODD内、什么场景下、什么版本的软件。另一个体会是数据比算法更重要。我见过太多团队在算法上花了很多精力但数据集的质量和覆盖度不够结果算法再好也发挥不出来。相反那些在数据采集和标注上投入足够的团队即使算法不是最先进的整体安全性也更好。这就像做菜食材不新鲜厨艺再好也做不出好菜。还有一个很实际的建议不要忽视仿真和实车的差异。仿真可以帮你快速迭代但仿真中表现好不代表实车表现好。我现在的做法是仿真中发现的每个问题都要在实车中验证实车中发现的每个问题都要在仿真中复现。只有两边对上了我才认为这个问题真正解决了。最后说一个容易被忽略的点安全文化的建设。技术手段再先进如果团队没有安全第一的文化早晚会出问题。我见过一些团队为了赶进度跳过必要的测试环节或者对已知的风险视而不见。这种团队做出来的系统即使通过了认证我也不敢坐。安全文化不是靠流程文件堆出来的而是靠每个工程师在日常工作中对安全的敬畏和坚持。