PEGASUS方法学：自动驾驶测试验证的底层逻辑与场景库构建指南

简介：PEGASUS-Gesamtmethode.pdf是一份源自德国联邦经济事务与能源部资助的PEGASUS项目的方法论文档，面向自动驾驶研发工程师、测试验证人员及标准研究者。它聚焦高度自动化驾驶功能在量产发布前如何建立通用质量标准、工具与评判依据，提出以场景为基础的测试、验证与校验方法，替代传统基于距离的随机测试思路。文档正文包含摘要、方法总览、反思与展望等章节，并详细拆解SP1场景分析与质量度量、SP2实施过程、SP3测试、SP4结果反思与嵌入四个子项目，有助于读者理解高速公路Chauffeur ODD等典型场景下的测试流程、性能期望定义以及安全边界刻画。资源为单个PDF文件，体积约640KB，目前已有124人学习下载。对于关注自动驾驶安全验证、标准演进与量化评价的从业者而言，这份资料提供了从场景分类到质量评估、再到测试落地的系统性参考，适合作为技术调研、标准制定和功能安全评估的背景材料。

1. PEGASUS-Gesamtmethode到底是什么：自动驾驶行业绕不开的一份底稿

如果你现在从事自动驾驶测试验证相关的工作，那你大概率在某次项目会上听过“PEGASUS”这个名字。我第一次接触这套资料时，它在我眼里还只是一堆德文缩写和晦涩的流程图，真正读懂之后才发现，它几乎是过去五年里无人驾驶测试领域最扎实的一份“公共底座”。

PEGASUS项目是德国联邦经济事务和能源部资助的大型联合研究项目，从2016年到2019年，由大众、奥迪、宝马、戴姆勒这些主机厂，加上博世、大陆这样的Tier1供应商，以及众多高校和科研机构共同参与。项目要解决的那个核心问题，用大白话说就是：自动驾驶系统到底要跑多少公里的测试，才能让人相信它足够安全？纯靠实际道路测试去“堆里程”，成本上几乎没有天花板；但完全依赖仿真，又没人敢对虚拟世界的结论拍板负责。PEGASUS给出的答案，是一套把“真实世界”和“虚拟世界”结合起来、以场景为中心的验证方法学，也就是你手里这份Gesamtmethode（德语“整体方法”）。

这份资料的适用人群很明确：正在搭建自动驾驶测试体系的技术负责人、负责场景库建设的功能安全工程师、做仿真测试的算法工程师，还有准备做ISO 21448预期功能安全认证的团队。如果你刚接触这个概念，理解这套方法学之后，再去读ISO 21448、ISO 26262、ASAM OpenX系列标准，会顺畅很多，因为它把这些标准的“骨架”和“血肉”串到了一起。

我建议所有想认真做自动驾驶测试的人，把这套文档当做“测试方法论的第一课”来读。它不是具体某个软件的操作手册，而是告诉你“为什么应该这样做测试”的顶层逻辑。

2. 场景体系与六层模型：怎么把真实世界的无穷变化翻译成工程问题

2.1 为什么要用“场景”而不是“测试用例”来组织安全验证

自动驾驶面对的真实道路情况，理论上是一个无限集合：永远存在没见过的光照、没遇到过的加塞方式、说不清的临时施工路段。如果你用传统汽车开发的“测试用例”思路去穷举，写出来的用例永远追不上真实情况的速度。PEGASUS的核心思路，是引入“场景”这个概念作为连接真实世界和测试工具的中间层。

所谓场景，就是一段连续时空里，自车与周围交通参与者、道路结构、环境条件之间关系的完整描述。把它拆细一点，场景至少包含这些要素：车辆自车的运动状态、其他交通参与者的行为和位置、道路几何与拓扑、交通标志标线、天气光照等环境条件。PEGASUS把场景分成了三个层级，这是全行业都在用的经典划分：

• 功能场景（Functional Scenario）：用自然语言描述的场景，比如“本车在高速公路上巡航，前方车辆突然减速”；
• 逻辑场景（Logical Scenario）：同一个功能场景加入参数范围，比如前方车辆减速度在 2 m/s² 到 6 m/s² 之间，初始车距在 30 米到 80 米之间；
• 具体场景（Concrete Scenario）：把所有参数固定成一组确定数值，得到可以交给仿真引擎运行或用实车复现的具体测试用例。

这个三层结构解决了一个很现实的工程问题：团队里不同角色之间终于有了统一的“沟通语言”。产品经理可以说功能场景、算法工程师跑的是具体场景、测试经理做参数覆盖分析时用逻辑场景，大家讨论的是同一个东西的不同抽象程度。我在实际项目中深受其益——早期团队开会时，需求方说“测一下紧急制动”，算法说“紧急制动场景我已经加了”，结果一看双方描述的条目对不上。引入这套层级定义后，这类扯皮基本消失了。

2.2 六层场景模型：把“路况”拆成六个可管理的维度

如果说三层场景分类回答了“场景怎么描述”，那么PEGASUS提出的六层模型回答了“场景里到底有哪些内容”。每次我在分享会上讲到这个模型，都会类比成做菜的“食材清单”：你要做一道菜，得先知道有哪些食材类别，再按类别去挑具体的料。道路、设施、物体、环境这些，就是自动驾驶场景的食材类别。

六层模型的每一层，都对应场景描述中的一个维度：

1. 道路层：包括车道数量、车道宽度、曲率、坡度、路面材料、路口拓扑等；
2. 交通设施层：交通标志、信号灯、护栏、路侧单元等静态设施；
3. 临时设施层：施工围挡、临时标志、锥桶等非永久的交通设施；
4. 物体层：其他车辆、行人、自行车、动物、散落物等动态交通参与者；
5. 环境条件层：天气（雨、雪、雾）、光照（白天、夜晚、逆光）、温度、路面湿滑程度；
6. 数字信息层：V2X通信信息、高精度地图信息、云端下发的事件提醒等。

有意思的是，这套六层模型后来被ASAM OpenX标准吸纳深化，成为OpenSCENARIO等标准的底层参考。你在做场景库结构设计时，如果直接把六层模型作为数据库的顶层分类，字段扩展和跨团队复用都会顺滑很多。我见过一些团队自己拍脑袋设计场景分类体系，结果建到后面场景越多、分类越乱，最后只能推倒重来——早先用六层模型做底子，就不会走这条弯路。

3. 场景库的构建与工具链：从原始数据到可复用测试资产

3.1 素材从哪来：四个主要来源及其价值排序

场景不是拍脑袋编出来的，构建一个高价值的场景库，素材质量决定了整个测试体系的上限。根据PEGASUS的方法论和行业经验，场景素材主要有四个来源：

• 自然驾驶数据：通过量产车或测试车采集的真实道路数据，包括毫米波雷达、摄像头、激光雷达、GPS/IMU等传感器数据和CAN总线底盘信号。这是最宝贵的第一手材料，因为里面包含真实的驾驶行为分布、真实的交通流特征。缺点是采集成本高、数据清洗工作量大；
• 事故数据：包括国家交通事故数据库、保险公司的碰撞数据、企业自有的剐蹭记录等。事故数据是长尾场景的金矿，很多极端但真实的场景（比如突然窜出的行人、异常低速的车辆）只有在事故数据里才能找到；
• 测试数据：已有的场地测试、道路测试过程中记录的数据。这类数据质量高，但覆盖范围有限，通常作为补充；
• 仿真生成数据：通过参数采样、对抗生成等方式，在虚拟环境中批量生成边缘场景。这一类现在越来越重要，但前提是仿真模型必须经过充分验证，否则生成一堆虚拟垃圾场景只会污染场景库。

我在做场景库规划时，给团队的分配比例大约是自然驾驶数据占50%到60%，事故数据占20%，仿真生成占15%，测试数据占5%到10%。这个比例不是死的，但大方向可以参考。很多团队一上来就想做仿真生成，觉得成本低、速度快，跳过真实数据采集，结果建出来的场景库在工程评审时根本没有说服力——“你的场景是不是真的？真实世界会发生吗？”

3.2 从数据到场景：标注、提取、参数化的一条完整流水线

拿一段自然驾驶数据来说，它落到场景库之前，要经过这么一条流水线：

第一步，数据清洗与分割。把原始数据里无效片段、传感器异常片段剔除，按时间或事件把长日志切成小段。这一步看着简单，做起来非常费手工。我在项目里见过一台测试车跑一天能产生几个TB的数据，里面真正有分析价值的可能就几分钟。

第二步，目标检测与轨迹提取。用感知算法对传感器数据做自动标注，提取出每个交通参与者的轨迹、速度、加速度、相对距离等参数。这里要强调，自动标注的精度一定要做人工抽检，否则错误标注会直接污染后续的场景参数化结果。

第三步，场景切割与聚类。通过规则或算法识别出“有分析价值”的片段：急刹车、换道、切入、路口交互等。把相似片段聚类，合并成可管理的场景原型。PEGASUS项目里一个很有价值的产出，是他们对高速公路典型场景的聚类结果，后来的ASAM标准也吸收了相关思路。

第四步，场景参数化。把聚好的场景转成逻辑场景，提取参数分布。比如“前车切入”这个场景，切入时刻的相对速度是一个分布、切入时的横向距离是一个分布。这些分布参数，直接决定了后续仿真测试的采样空间。

第五步，格式标准化与入库。把场景导出成OpenSCENARIO、OpenDRIVE等标准格式，写入场景库管理系统，附带标签、版本号、参数范围、数据来源、验证状态等元信息。

这条流水线走通之后，场景库才真正变成可复用的测试资产。注意，这一步不是一次性投入，场景库需要持续的采集补充、版本迭代和淘汰清理。我在后续项目中反复强调过：场景库要当成一个“活产品”来运营，而不是“一次性项目”来交付。

3.3 工具链选型：商业软件与开源方案怎么组合

做场景库构建和基于场景的测试，工具链的选型是个现实问题。按行业里常见的组合方式，我把工具分成几类：

现在插一句关于“PEGASUS-Gesamtmethode.pdf”这份文档的使用感受。它本身是方法学的说明文档，不含可直接运行的代码，但如果你按它的框架去搭建自己的场景库，它就是最好的“检查清单”。比如文档里对“场景库应包含功能场景、逻辑场景、具体场景三层结构”的描述，我会把这句话翻译成数据库设计里的三张关联表：功能场景表、逻辑场景表（带参数范围和约束）、具体场景表（带确定性参数值）。

4. 在真实项目中落地这套方法：从0到1的实操路径

4.1 第0步：先定义ODD，再谈场景库

很多团队在落地时犯的一个次序性错误，是一上来就狂建场景库，觉得“场景越多越好”。这么做往往建了一座没有根基的“空中楼阁”。PEGASUS方法论的真正起点，是先定义ODD（Operational Design Domain，运行设计域）。

ODD说白了就是一句话：你的自动驾驶系统在什么条件范围内才能安全运行？高速公路L2级辅助驾驶，ODD可能是“有清晰车道线的高速公路，天气无雨雪，光照良好，车速60-120km/h”。如果场景库里全是城市交叉路口、雨夜无路灯的场景，那这套场景库和待测系统根本不匹配。我在实际项目中的做法是：先组织团队把ODD写成结构化的条目，逐条对照六层模型过一遍，确认每个ODD子项都有对应的场景类别。这套“ODD到场景”的映射关系，是场景库设计的锚点。

4.2 覆盖度论证：如何回答“测够了没有”

做自动驾驶测试验证，最怕被问的一个问题是：“你们做了这么多测试，覆盖度够了吗？”这个问题在PEGASUS框架下，变成了一个可以量化论证的问题。

覆盖度论证分两层：

参数覆盖度：对某个逻辑场景，在参数空间里做了多少采样？比如“前车切入”场景，相对的切入车速范围是20-100km/h，切入横向距离范围是0.5-2m，在二维参数空间里取了哪些点？有没有覆盖边界条件？有没有在概率密度高的区域加密采样？这些都可以用统计方法量化。

场景分布覆盖度：场景库里的场景类别分布，和真实道路场景分布是否一致？这一步需要定义基准分布，通常来自自然驾驶数据的场景统计。如果场景库里高速巡航场景占80%，但在真实使用中城市工况占了一半，那就说明场景库的分布失配了。

实际操作中，我建议用一份“覆盖度论证报告”拉着管理层和工程团队一起过，其中包括：ODD清单、场景类别与ODD的映射矩阵、每个场景类别的数量与来源、参数采样的网格图、仿真与实车测试的比例。这份报告的价值在于，它把“安全”这个模糊的词，翻译成了可审查的工程证据。PEGASUS项目的“安全论证”框架，本质上就是这套“目标 -> 场景 -> 测试 -> 证据”的链条，你在做ISO 21448预期功能安全的评估时，也会需要同样的论证逻辑。

4.3 仿真与实车测试的配比怎么定

关于仿真和实车的配比，行业里存在不少争论。PEGASUS方法学的观点很务实：仿真负责“广覆盖”，实车负责“高置信”。仿真测试适合大批量覆盖逻辑场景的参数组合，速度快、成本低、无安全风险；实车测试用于验证仿真结果的可信度，特别是识别仿真环境中未建模的物理效应（如传感器噪声、通信延迟、车辆动力学差异）。

我实践里的一个参考配比是：单车功能验收阶段，仿真用例量级在万级甚至十万级以上，实车用例在百级到千级。但这不意味着所有仿真用例都跑到实车复现——那成本还是不可控。合理的做法是，对每个场景类别抽取若干典型参数点做实车验证，用于建立“仿真结果和实车结果的可比性”；一旦比对模型建立完成，后续的批量参数采样就可以放心交给仿真。

这里面有几个细节值得注意：仿真器的传感器模型必须经过单体验证（比如摄像头模型模拟的逆光效果是否与实车一致）；场景里的目标车辆运动学模型要经过校准；仿真数据与实车数据要统一格式便于回放比对。

5. 做过这套流程之后踩过的坑：三条常见误区与排查心得

5.1 误区一：场景库只增不减，“数据垃圾”越堆越多

场景库建到一定规模之后，最大的问题往往不是“场景不够”，而是“场景太多、太杂”。有些团队为了追求数量指标，把大量低质量、低价值的场景塞进库里。结果工程师在运行测试时，花了大量时间跑一堆和ODD无关的场景，真正的关键场景反而被淹没。

我的建议是建立场景淘汰机制，定期按三个标准清理：有效性（该场景是否在ODD范围内）、区分度（该场景是否带来了新的参数覆盖或行为挑战）、可执行性（该场景能否在仿真或实车中稳定复现）。在项目迭代过程中，每两周清理一次无效场景，比每半年做一次“大扫除”要高效得多。

5.2 误区二：标注标准不统一，场景复用率低

场景参数的标注规范如果不在一开始就定死，后面跨团队复用时必然踩坑。我碰到过一个典型情况：两个团队都标注了“前车切入”场景，但A组对“切入时刻”的定义是目标车辆前轮越过车道线，B组定义是目标车辆中心点越过车道线。两边的场景数据一合并，参数分布错位，整个分析白做。

所以无论做什么项目，第一步先把“场景参数定义”这份文件敲定，里面包括每个参数的名称、单位、坐标系、时序定义、边界条件、采样规则。最好做成一个可查询的线上文档。这个文档的权威性，一定要压过任何人的个人主观判断。参数定义一旦发布，就按版本管理，要修改也要走评审流程。

5.3 误区三：忽略“虚拟仿真里的现实差距”，对仿真结果过度信任

仿真测试效率是高，但仿真结果不能等于真实安全结论。我见过某个团队在仿真里跑出一组很漂亮的指标，结果把同一组场景放到实车验证时，发现实车在湿滑路面的表现和仿真差了很远——原因是仿真里的轮胎模型没有正确标定湿滑系数。

所以我强烈建议在项目计划阶段就预留“仿真可信度验证”的工作量，具体做法是：挑选10到20个基础场景，仿真和实车同时跑，对比轨迹误差和决策结果一致性。通常来说，横向位移误差在0.3米以内、纵向相对距离误差在0.5米以内、决策行为一致（比如都触发了AEB或都在同一位置完成转向），可以认为仿真模型基本可信。这个阈值没有硬性标准，但可以作为团队的初始参考值。

这里再说一个环境类场景的坑：很多团队在仿真里做雨天场景，调了个降雨强度参数就认为“仿真下雨了”，却忽略了雨滴造成的传感器衰减、路面反光、车道线可视性下降这些复杂物理效应。实际做下来，雨天场景的仿真真实性远比其他场景更难保证，需要有针对性的传感器模型和验证数据。

5.4 实操心得：把PEGASUS方法学落地的三个有用习惯

最后分享几个我实际工作中觉得特别有用的习惯，如果你也在做类似的事，可以少走弯路：

第一个习惯，把场景库当作“数据库产品”来用。所有场景必须有版本号、创建人、修改时间、参数来源、验证状态。哪怕是内部自用的小场景库，也建议做这套基础管理动作。实际项目跑到后期，你会因为当初建了版本管理而感谢自己。

第二个习惯，建立“ODD变更”与“场景变更”的联动评审。很多项目是ODD已经改动了（比如运行车速范围从120km/h扩展到130km/h），场景库却没有同步更新。建议ODD变更走一个正式流程，并且设置一个固定动作：ODD变更后，必须由场景库管理员提交一个“场景库受影响分析”，列出需要新增或调整的场景。

第三个习惯，在项目初期就写好“覆盖度论证模板”，哪怕没有完整数据也先把框架搭出来。等到测试数据逐步积累后，把数据填进去，就能实时看到覆盖度指标的变化。比起项目快结束了再补报告，这个习惯节省了大量无效工时。

6. 最后再聊两句

PEGASUS这套方法学现在已经被整合进了一系列国际标准和行业实践中，其中最直观的体现就是ASAM OpenX标准对场景交换格式的规范化，以及ISO 21448预期功能安全标准中对场景分析的要求。如果你手头正好拿到了这份PDF，别把它当成一份“收藏夹吃灰”的资料。我建议的打开方式是：先读第三章对整体方法的概述，然后直接跳到场景定义相关章节，对照自己手头项目的ODD和测试场景梳理一遍，最后再回头读验证与评估部分——这套“先框架、再场景、后验证”的阅读顺序，效率会高不少。

从我个人的实操体会来说，自动驾驶测试验证不是一个“看谁跑得多”的比赛，而是一个“看谁论证得清晰”的工程问题。场景库、ODD、覆盖度、仿真实车配比，这些都不是独立的模块，而是围绕“如何证明系统足够安全”这一件事形成的闭环。PEGASUS方法论给了这个闭环一个很好的起点，剩下的，就是在你自己的项目和团队里，把这套骨架填上血肉。

本文还有配套的精品资源，点击获取