简介这份资源是百度Apollo联合多家主机厂与供应商于2019年发布的《自动驾驶安全第一白皮书》完整中文电子版面向SAE L3、L4级自动驾驶系统的研发工程师、功能安全与预期功能安全从业者以及高校智能网联汽车方向的学习者用于系统理解自动驾驶如何通过设计实现安全并取得正风险平衡。资源为单个PDF文件压缩包约4.44MB正文共149页由十余家国际企业技术团队联合撰写先拆解安全原则与架构设计再汇总验证与确认方法并对照ISO 26262、ISO/PAS 21448等标准展开说明便于读者建立功能安全与预期功能安全的整体知识框架。目前已有402人学习下载适合作为自动驾驶安全合规、系统设计评审与标准研读的案头参考资料。1. 这份 149 页白皮书为什么值得架构师逐页拆很多团队第一次接触 L3/L4 安全设计都是从一份「安全需求追溯表」开始的然后很快卡住——需求写不出因为不知道安全能力该拆到哪一层。这份 2019 年由 Aptiv、奥迪、宝马、百度、大陆、戴姆勒、FCA、HERE、英飞凌、Intel、大众联合署名的《自动驾驶安全第一白皮书》中文版 149 页解决的正是这个起点问题它把「通过设计实现安全」拆成可推导的能力项、要素和通用逻辑架构再配一套 VV 方法用来论证自动驾驶相比人类平均驾驶具有正风险平衡。它适合两类人一类是要落地 SOTIF 与 ISO 26262 协同的算法和系统工程师另一类是负责仿真、测试、场景库建设的技术负责人。读它的正确姿势不是通读而是按目录第四条线要素清单和附录三条开发示例TJP、HWP、UP反查自己模块的缺口。2. 从安全愿景到能力需求的推导链2.1 十二条指导原则如何约束架构选型白皮书第 1.3.2 节给出十二条自动驾驶指导原则这是整份文档最像「宪法」的部分。它的作用不是喊口号而是给后续所有设计决策提供一个可争论的锚点。比如「人机交互应保持简洁一致」这条直接约束了 ADS 模式管理器的状态机设计你不能在 L3 里让驾驶员用三种不同方式接管。又比如「车辆应具备冗余」这条落到架构上就是制动、转向、电源、通信网络都要有备份路径而不是靠单点高质量来兜底。我一般会把这十二条做成一张检查表逐条映射到自己项目的架构决策记录里。下面这段脚本是常见的做法把原则条目和设计项做交叉引用避免评审时凭记忆辩论。# 安全原则与架构决策的映射检查表 principles { P01: 安全优先于其他性能目标, P02: 人机交互简洁一致, P03: 运行设计域内保持可控, P12: 关键系统具备冗余, } # 每个架构决策项标注它响应了哪些原则 decisions [ {id: ARCH-01, desc: 制动子系统双回路冗余, covers: [P12]}, {id: ARCH-02, desc: HMI 统一接管提示时序, covers: [P02, P03]}, ] for d in decisions: missing [p for p in principles if p not in d[covers]] # 输出未覆盖的原则供评审会重点讨论 print(d[id], 未覆盖原则:, missing or 无)这段代码的逻辑是把「原则覆盖率」显式化。covers字段需要人工填写脚本只负责暴露空白。参数上principles建议只保留与当前项目阶段相关的条目全量十二条会让报告噪音过大decisions的粒度控制在系统级架构项不要下沉到函数名。运行后如果「未覆盖原则」大量出现说明架构评审还没做完不要急着进详细设计。2.2 SOTIF 与功能安全的边界划分第 2.1 节把相关安全标准的应用讲得很清楚ISO 26262 管的是电子电气系统的功能失效E/E 故障ISO/PAS 21448 管的是预期功能安全也就是系统没坏但能力不足导致的危害。这两者的边界经常被混淆。一个典型误用是把感知误检归到功能安全里去做 FMEA结果做不出有效的失效模式因为感知性能不足不是「失效」而是 SOTIF 要处理的「功能不足」和「性能局限」。实际工程里我一般按下面的判定顺序来分类一个危害场景场景特征归属标准典型缓解手段传感器硬件输出卡死、漂移ISO 26262冗余通道、诊断覆盖、安全机制逆光、雨雾导致漏检ISO/PAS 21448场景限制、ODD 收缩、性能监控通信被篡改或重放ISO/SAE 21434消息认证、密钥管理、入侵检测地图先验数据过期SOTIF 数据质量数据新鲜度校验、降级策略这张表的价值在于它决定了你后续写的是安全需求还是性能需求。落到项目里功能安全需求要能追溯到具体的硬件失效模式和诊断覆盖率指标而 SOTIF 需求往往表现为「在某某光照条件下目标检测召回率不低于某阈值」。两者的验证方法也完全不同前者靠故障注入后者靠场景测试和统计。2.3 能力要求与要素清单的对应关系第 2.1.6 节把自动驾驶能力初始推导为七项标称功能FS_1 到 FS_7和六项降级功能FD_1 到 FD_6第 2.2.1 节再逐条展开。这套编号体系是整份白皮书最实用的部分因为它是可以逐项打勾的清单。FS_1 是确定位置FS_2 是感知近邻静态和动态物体FS_3 是预测未来行为FS_4 是制定无碰撞且合法的驾驶规划FS_5 是正确执行规划FS_6 是与其他道路使用者沟通FS_7 是确认标称性能是否达到。降级侧同样重要FD_1 确保操作员可控FD_2 检测降级模式是否可用FD_3 确保模式转换和用户认知FD_4 到 FD_6 则是逐步降低性能并执行降级模式。很多项目把精力全放在 FS 上结果做 HWP 时发现接管流程根本没设计这就是 FD 项缺失的代价。第 2.2.2 节列出的二十个要素是能力落地到工程实体的桥梁。我一般用一张映射表来管理要素支撑的能力项常见实现环境感知传感器FS_2、FS_7摄像头、毫米波雷达、激光雷达定位FS_1GNSS IMU 地图匹配解释与预测FS_3目标跟踪、轨迹预测驾驶规划FS_4行为决策 运动规划监视器FS_7、FD_2标称与降级模式监控这张表在评审时的作用很大任何一条能力项都必须有至少一个要素承担任何要素也必须至少支撑一条能力项否则就是多余的或漏掉的。第 2.3 节的通用逻辑架构进一步把这些要素组织成可部署的模块视图是画自己架构图时的参照起点。3. 验证与确认从测试目标到仿真闭环3.1 L3 与 L4 的 VV 关键挑战第 3.2 节把 L3 和 L4 的验证挑战讲得比较透L3 的难点在于人机共驾边界驾驶员在接管请求后的反应时间不确定验证必须覆盖接管时序的各种分布L4 的难点在于 ODD 边界的完整定义因为它没有人类兜底任何未定义场景都可能是风险。这决定了两者的测试策略完全不同——L3 的重点是 HMI 与接管场景L4 的重点是 ODD 覆盖与降级策略。实际做的时候我会先把挑战转化成可测指标。L3 的接管测试通常关注接管请求到驾驶员接管的时延分布以及接管后控制质量L4 的测试则关注系统在 ODD 内外的识别准确率和降级动作的及时性。这些指标不是白皮书直接给的而是从它的方法论推导出来的属于「合格从业者最可能用的方案」。3.2 测试设计方法与测试平台的组合第 3.3 节把 VV 方法拆成四个问题为何与多好测试目标、如何测试设计、何地测试平台、以及应对关键挑战的策略。第 3.4 节讨论测试数量与质量提出等价类和基于场景的测试。这是我最常回头翻的一节因为它直接回答「要跑多少里程才够」这个折磨人的问题。基于场景的测试核心思路是不追求随机里程的统计显著性而是把 ODD 拆成参数化的场景空间用等价类覆盖关键维度。下面是一个典型的场景参数化定义用 Python 描述便于生成测试用例。# 基于场景的测试用例参数化定义TJP 场景 scenario_template { scenario: traffic_jam_cut_in, # 场景拥堵中切入 ego_speed_kph: [10, 30, 60], # 自车速度等价类 cut_in_gap_m: [5, 15, 30], # 切入间距 light: [day, dusk, night], # 光照条件 cut_in_actor: [car, truck], # 切入目标类型 } def expand(template): cases [] keys list(template.keys()) # 递归展开所有参数组合生成笛卡尔积用例 def rec(idx, current): if idx len(keys): cases.append(dict(current)); return k keys[idx] for v in template[k]: current[k] v rec(idx 1, current) rec(1, {keys[0]: template[keys[0]]}) return cases all_cases expand(scenario_template) print(用例总数:, len(all_cases)) # 3*3*3*2 54这段代码用笛卡尔积展开场景参数得到最小可执行用例集。参数选择上要注意两点一是每个维度的取值要对应等价类不是随便取三个数比如速度的 10/30/60 分别代表低速拥堵、中速跟车、接近退出阈值二是维度数量要控制维度一多组合会爆炸实操中通常用两两组合覆盖先跑一轮再对高风险维度做全组合。这个脚本输出 54 条用例在仿真平台里跑一轮通常几分钟到几十分钟比实车跑几千公里高效得多。3.3 仿真类型与情景生成的落地第 3.5 节把仿真分成几类并讨论情景生成和仿真确认。这里有一个容易被忽视的点仿真本身也需要被确认也就是要证明仿真结果与真实世界一致否则仿真里通过不代表实车安全。常见做法是用同一批场景在仿真和实车或封闭场地里各跑一遍比较关键指标的偏差。第 3.5.2 节的情景生成方法实际落地时通常结合日志回放和参数化生成。日志回放来自路测数据保真度高但覆盖有限参数化生成覆盖广但可能不真实。我一般用下面的流程做混合# 仿真场景生成与回放的常见流程伪命令 # 1. 从路测日志提取场景片段标注触发条件 python extract_scenarios.py --log drive_2024_*.bag --output scenes/ # 2. 基于提取片段做参数扰动扩充边界场景 python mutate_scenarios.py --input scenes/ --var cuts --output scenes_mutated/ # 3. 提交仿真集群批量回放输出指标报告 python run_sim.py --scenes scenes_mutated/ --metric collision,timeliness --report out.csv这套流程的关键参数是扰动幅度。--var cuts表示对切入场景做扰动扰动太大会产生不真实场景浪费算力。我通常限制在真实数据分布的 5% 到 15% 范围内超出部分单独标记为「极端场景」另行处理。输出报告里的collision和timeliness是最低限度的两个指标前者看安全后者看响应是否及时。回放时还要注意时间同步仿真时间步长与传感器采样率不一致会导致跟踪误差被放大。3.4 要素级 VV 的分工第 3.6 节按要素逐一给出验证方法这部分是各模块负责人最该看的内容。地图和先验信息、定位含 GNSS、环境感知与 V2X 融合、解释与预测、运动控制、监视器与模式管理、人机交互每一项都有对应的验证思路。它的价值在于给出了「这个模块该测什么」的清单而不是只讲整体 VV。以定位为例白皮书提到包括 GNSS 的验证实操中通常要覆盖隧道、城市峡谷、高架桥下等信号受限场景验证重点是定位跳变和与地图匹配的一致性。感知与融合的验证则要覆盖传感器单点失效和融合输出的时序一致性。这些验证的共性要求是要有可重复的场景输入和量化的通过判据否则无法回归。4. 附录三条开发示例的读法与复用4.1 TJP、HWP、UP 三条线的差异附录 A 给了三条开发示例L3 交通阻塞巡航 TJP、L3 高速公路巡航 HWP、L4 城市巡航 UP。每条都按标称功能定义、降级模式或最低风险状况、最低风险策略三部分展开。三条线的差异恰好覆盖了主要的设计分歧TJP 速度低、场景封闭主要挑战是跟车和切入HWP 速度高主要挑战是接管时序和退出策略UP 没有人类兜底主要挑战是 ODD 边界和远程协助。我建议把三条示例当成三个模板来复用而不是当成三个案例来读。具体做法是用 TJP 的模板写你的低速场景用 HWP 的模板写你的高速场景用 UP 的模板写你的无人场景然后对比三份模板里最低风险策略的差异。差异点就是你的设计决策点。4.2 最低风险状况与策略的工程落地最低风险状况MRC和最低风险策略MRM是 L3/L4 特有的概念也是新手最容易做浅的地方。常见误用是把 MRC 简单理解成「靠边停车」然后发现高速上根本没法立即靠边。白皮书的处理方式是先定义 MRC 的可达状态集再定义从各状态到达 MRC 的策略。下面是一张从示例里提炼的落地对照表场景最低风险状况 MRC最低风险策略 MRM触发条件TJP 低速拥堵本车道安全停车保持车道减速停车驾驶员长时间不接管HWP 高速巡航本车道或应急车道停车先减速再评估变道传感器降级、接管超时UP 城市巡航本车道停车或靠边减速、避让、靠边ODD 即将退出这张表在项目里可以扩展成状态机。关键在于每条策略都要有明确的触发条件、执行动作和失败后的兜底。实操中我一般会把 MRM 的决策逻辑单独做一个模块与标称规划解耦这样即使标称规划出问题MRM 仍能独立执行。这个解耦思路来自白皮书对监视器和降级模式要素的划分是 FD 项落地的核心技术点。4.3 现场操作与持续监控的闭环第 3.7 节讲现场操作包括测试可追溯性、鲁棒性配置与变更管理、回归预防、监控与更新、连续监控与纠正执行。这部分最容易被忽略但它是从开发到运营的必经环节。测试可追溯性要求每个测试用例能追溯到需求每个需求能追溯到场景。一个具体技巧是用唯一标识把需求和场景打通下面的 SQL 示例展示了追溯关系的存储结构-- 需求与测试场景的追溯关系表 CREATE TABLE requirement_scenario_map ( req_id VARCHAR(32) NOT NULL, -- 需求编号如 REQ-FS4-012 scenario_id VARCHAR(32) NOT NULL, -- 场景编号如 SCN-TJP-003 coverage DECIMAL(3,2), -- 覆盖度 0.00 到 1.00 last_run DATE, -- 最近一次执行日期 result VARCHAR(16), -- PASS / FAIL / PENDING PRIMARY KEY (req_id, scenario_id) ); -- 查询长期未执行或覆盖不足的需求 SELECT req_id, MIN(coverage) AS min_cov, MAX(last_run) AS last_run FROM requirement_scenario_map GROUP BY req_id HAVING min_cov 0.8 OR last_run 2024-01-01;这段 SQL 的用途是发现「需求有、场景没覆盖」的盲区。coverage字段建议按场景维度手工或半自动维护因为它涉及覆盖判据的判断。last_run用于发现长期未回归的需求通常在每次版本发布前扫一遍。连续监控与纠正执行则要求上线后持续收集运行数据把真实出现的边界场景反哺回场景库形成闭环。这个闭环的落地难点不在技术而在数据格式统一和场景入库的审核流程建议在项目早期就定下来否则后期数据没法用。把 MRM 模块、追溯表和场景闭环这三件事做扎实白皮书里的方法论才真正落到你的代码库里。本文还有配套的精品资源点击获取