2. ADAS功能与场景需求解析

在构建ADAS场景库之前，必须先回答一个基础问题：每个功能的场景需求究竟从哪里来？如果场景设计脱离了功能的行为定义与触发条件，就会产生大量“看似合理但实际无效”的测试用例。本节围绕AEB、ACC、LKA、APA四类典型功能，梳理其行为边界、触发逻辑与场景需求来源，为后续场景库的结构化设计提供依据。

一、功能行为定义：从“系统做什么”到“何时介入”

ADAS功能的行为定义通常包含三个层次：感知输入、决策逻辑和执行输出。以AEB（自动紧急制动）为例，其行为定义可描述为：当车辆前方存在碰撞风险且驾驶员未及时响应时，系统通过制动执行器施加减速度，以减轻或避免碰撞。这里的“碰撞风险”由TTC（碰撞时间）或安全距离模型量化，典型触发阈值在TTC小于1.5秒时进入预警，小于0.8秒时触发部分制动，小于0.4秒时触发全力制动。这些参数并非固定值，而是根据车速、路面附着系数和目标类型动态调整。

ACC（自适应巡航）的行为定义则不同：它要求系统在驾驶员设定的巡航速度与跟车时距之间取得平衡。其核心参数是设定速度与跟车时距（通常以秒为单位，如1.0s、1.5s、2.0s）。当本车与前车距离大于期望时距时，系统加速至设定速度；小于期望时距时，系统减速以维持时距。ACC的触发条件相对宽松，通常要求车速高于某一阈值（如30km/h）且驾驶员通过按键激活。

LKA（车道保持辅助）的行为定义聚焦于横向控制：当车辆无意识偏离车道时，系统通过转向干预或方向盘振动提醒驾驶员。其触发条件包括：车道线清晰可见、车速在设定范围内（如60~180km/h）、驾驶员未主动打转向灯。LKA的介入力度通常分为两级：一级为预警（振动或声音），二级为转向修正（施加小扭矩）。

APA（自动泊车辅助）的行为定义最为复杂，因为它涉及低速、多阶段、多传感器协同。其行为可分解为：车位搜索、路径规划、路径跟踪、泊入完成。触发条件包括：车速低于30km/h、超声波传感器检测到足够空间、驾驶员确认泊车指令。APA的场景需求来源与上述三个功能有本质区别——它更依赖静态环境几何而非动态交通流。

二、触发条件的参数化表达

触发条件不能停留在文字描述，必须转化为可配置的参数。以AEB为例，其触发逻辑可表达为：

if (TTC < TTC_warning && driver_brake == false) {
    trigger_warning();
}
if (TTC < TTC_partial_brake && driver_brake == false) {
    apply_brake(partial_decel);
}
if (TTC < TTC_full_brake && driver_brake == false) {
    apply_brake(full_decel);
}

其中TTC_warning、TTC_partial_brake、TTC_full_brake是标定量，通常随车速变化。例如在50km/h时，三者可能分别为1.2s、0.7s、0.35s；在80km/h时，则可能调整为1.5s、0.9s、0.45s。这种参数化表达直接决定了场景库中需要覆盖的参数组合空间。

ACC的触发条件同样需要参数化：v_set（设定速度）、t_gap（跟车时距）、v_min（最低激活车速）。场景设计时，需要覆盖t_gap从1.0s到2.0s的多个档位，以及v_set从30km/h到120km/h的典型值。LKA则需要参数化v_min、v_max、torque_max（最大转向扭矩）、lane_confidence（车道线置信度阈值）。APA的参数化最为特殊，它需要slot_length、slot_width、slot_angle等几何参数，以及v_search（搜索车速）和v_park（泊入车速）。

三、场景需求来源的三大渠道

场景需求并非凭空产生，它有三个明确的来源渠道：

• 法规与标准：如Euro NCAP的AEB测试场景（CCRs、CCRm、CCRb）、UN R152的AEB城市工况、ISO 15622的ACC性能要求。这些场景具有强制性和通用性，是场景库的基线。
• 真实事故与边缘场景：从事故数据库（如GIDAS、CIDAS）中提取的碰撞形态，往往包含法规未覆盖的极端工况，如夜间行人横穿、摩托车突然切入、隧道口逆光等。这类场景是提升系统鲁棒性的关键。
• 功能设计参数边界：每个功能都有其设计运行域（ODD），超出ODD的场景不应被纳入常规测试，但需要作为边界场景进行验证。例如LKA在车道线完全缺失时不应激活，但需要测试其误激活风险。

四、从功能到场景的映射示例

以AEB为例，其场景需求可映射为以下具体测试用例：

类似地，ACC的场景需求可覆盖：前车匀速、前车变速、前车切入、前车切出、弯道跟车等。LKA的场景需求可覆盖：直道偏离、弯道偏离、车道线模糊、车道线分叉、相邻车道车辆压迫等。APA的场景需求可覆盖：平行车位、垂直车位、斜列车位、窄车位、通道狭窄等。

五、场景需求解析的工程落地

在实际工程中，场景需求解析的产出通常是一份场景需求规格书，其核心字段包括：功能名称、行为定义、触发条件参数、场景来源、场景描述、预期输出、优先级。这份规格书直接作为场景库设计的输入，确保每个场景都能追溯到明确的功能需求。

需要特别注意的是，不同功能之间的场景需求可能存在冲突。例如AEB的全力制动场景与ACC的舒适性跟车场景在减速度要求上存在矛盾——AEB要求减速度≥8m/s²，而ACC通常限制减速度≤3.5m/s²。这种冲突需要在场景库中通过功能优先级和场景隔离来化解，而不是简单合并。

综上所述，ADAS功能与场景需求解析的核心在于：先明确每个功能的行为定义与触发条件，再将其参数化，最后从法规、事故、参数边界三个渠道提取场景需求。只有完成这一步，后续的场景库构建与回归验证才有坚实的依据。