4. 场景抽象与描述语言
在ADAS场景库工程中，场景描述语言决定了场景能否被机器理解、复用和自动执行。同一个“前车急刹”场景，用自然语言写出来是给人看的，用结构化字段写出来是给数据库检索的，而用OpenSCENARIO写出来才是给仿真器执行的。三者不是替代关系，而是从模糊到精确、从人工到自动的抽象层级递进。理解这条抽象链，是Bosch场景库能够支撑大规模回归验证的前提。
三个抽象层级各自解决什么问题
自然语言场景是最贴近人类经验的描述方式，例如“本车以80 km/h在高速公路上行驶，前方同车道车辆突然以4 m/s²减速，本车应在TTC小于2.5 s时发出FCW警告”。它的优势是沟通成本低，适合需求评审、事故报告转写和测试用例初稿。但自然语言存在歧义：多“突然”算突然？减速度是恒定还是阶跃？本车是否允许变道？这些歧义在人工测试中可由测试员临场判断，在自动化回归中却会导致不可复现。
结构化场景把自然语言中的关键要素拆成带类型的字段，通常包括道路拓扑、交通参与者、初始状态、行为触发条件、评价指标五类。结构化之后，场景可以被数据库索引、被参数化批量生成、被脚本批量调度。例如把“前车急刹”抽象为：道路=直道双车道、本车速度=80 km/h、目标车初始距离=40 m、目标车减速度=-4 m/s²、触发条件=目标车开始制动、评价=TTC最小值与碰撞标志。此时场景已可被程序读取，但还缺少统一的执行语义。
OpenSCENARIO/OpenDRIVE是ASAM定义的标准交换格式。OpenDRIVE描述静态道路网络：车道几何、车道线类型、限速、路口连接关系；OpenSCENARIO描述动态剧情：车辆、行人、触发条件、动作序列、参数声明。两者配合，才能让仿真器在正确的道路上执行正确的行为。Bosch在内部场景库中通常以OpenDRIVE作为道路资产底座，以OpenSCENARIO作为场景剧本，再通过参数化接口把结构化字段映射为标准XML节点。
OpenSCENARIO 的核心结构
一份可执行的 .xosc 文件通常由四部分组成：FileHeader 声明版本与作者；ParameterDeclarations 定义可扫描参数，例如 EgoSpeed、LeadDecel、InitialGap；Catalog 引用可复用的车辆、行人、控制器定义；Storyboard 描述剧情，其中 Init 设置初始位姿，Story 下的 Act 和 Maneuver 定义动作序列，Trigger 定义触发条件。OpenDRIVE 则独立描述道路，通过 <header> 的 revMajor/revMinor 标识版本，用 <road>、<geometry>、<laneSection> 表达几何与车道。
在Bosch项目中，落地方式通常不是让工程师手写全部XML，而是建立“结构化场景表 → 模板引擎 → .xosc”的生成链。结构化表可以用Excel或内部数据库维护，每行代表一个场景变体，列包括场景ID、道路ID、本车速度、目标车速度、初始距离、目标减速度、触发方式、评价阈值。模板引擎读取这些字段，填充到预定义的.xosc模板中，输出可被仿真器加载的文件。这样做的价值在于：当需要把“前车急刹”从80 km/h扩展到60、100、120 km/h，或把减速度从-4扩展到-3、-5、-6 m/s²时，只需增加参数组合，而不必重新编写场景逻辑。
参数化与场景变体管理
参数化是场景库规模化的关键。以“前车急刹”为例，可定义三个扫描维度：本车速度 EgoSpeed ∈ {60, 80, 100, 120} km/h，初始距离 InitialGap ∈ {20, 30, 40, 50} m，目标车减速度 LeadDecel ∈ {-3, -4, -5, -6} m/s²。全组合共64个变体。若再叠加天气、路面附着系数，变体数量会迅速膨胀。因此Bosch场景库通常采用“基础场景 + 参数集”的管理方式：基础场景定义剧情骨架，参数集定义扫描范围和采样策略，回归任务按需选择参数子集，而不是每次全量执行。
从标准到Bosch工程落地的关键约束
标准本身只规定语法和语义，不规定工程流程。Bosch在落地时通常补充以下约束：第一，场景ID命名规范，例如 SCN_AEB_CCRs_080_040_m4 表示AEB、CCRs工况、本车80 km/h、距离40 m、减速度-4 m/s²，使场景可被快速检索和追溯；第二，OpenDRIVE道路资产版本锁定，避免道路更新导致历史回归结果不可比；第三，评价指标与场景绑定，每个场景在结构化表中声明通过/失败判据，例如“TTC最小值 ≥ 1.2 s 且无碰撞”；第四，回归报告按场景ID聚合，支持按参数维度下钻，定位是哪个速度区间或哪个距离区间出现退化。
需要特别注意的是，OpenSCENARIO 1.x 与 2.0 在结构上有差异，Bosch内部工具链通常锁定某一主版本，并在场景库元数据中记录版本号。跨版本迁移时，Storyboard 的触发逻辑和 Entity 引用方式可能需要调整，不能直接复用。这也是为什么结构化场景层要独立于标准版本存在——它保存的是工程语义，而.xosc只是当前工具链下的一种序列化形式。
抽象层级的选择原则
实际项目中，三个层级并非严格串行。事故数据转写可能直接从自然语言跳到结构化表；已有标准场景可能直接复用.xosc并只改参数；新功能预研可能先用自然语言写清意图，再逐步细化。选择原则是：沟通和评审用自然语言，检索和批量生成用结构化表，仿真执行和回归用OpenSCENARIO/OpenDRIVE。三者之间保持可追溯的映射关系，才能让场景库既被人理解，又被机器执行，还能在回归失败时快速定位到原始需求。