简介这份资料围绕智能驾驶巡航功能ACCL2级辅助驾驶展开适合智驾产品经理、功能定义工程师、系统需求与测试人员作为场景梳理与需求拆解的参考模板。内容从功能简介、场景定义、系统需求三个层面组织梳理了定速巡航、跟车巡航、跟随前车停止与起步、智能限速控制、智能红绿灯启停等主场景给出41条场景描述及关键参数定义并覆盖智能限速、V2X与红绿灯交通等典型工况。系统需求部分阐述了7个状态之间的条件切换逻辑并从法规合规、交互体验及与车辆动态控制、传感器融合、车联网等关联系统的信息交互出发整理了35条域控制器需求同时涉及功能安全中的故障检测与接管提醒后续还将持续更新KPI与功能安全信息。资源包内1个PDF文件约1.44MB篇幅紧凑、结构清晰便于快速通读与按模块检索。目前已有413人学习下载。1. 巡航功能场景定义不是写文档而是给系统需求画边界很多团队把 ACC 跟车做得很顺却在近距离 Cut-in、静止目标、弯道曲率突变时频繁退出回头查代码发现控制器没问题问题出在场景定义没有把边界收住。巡航功能场景定义与系统需求解析要做的就是把“驾驶员按下巡航按钮后车应该怎么走”这种自然语言拆成 ODD、场景条目、功能需求、系统需求和验证用例。它面向的是功能设计、需求工程、测试标定和系统集成人员也适合刚接手 ADAS 纵向功能的人建立全局视角。场景定义不是文档工作而是后续控制器参数、传感器选型、HMI 报警和故障降级的总开关。边界没定清楚系统需求就会互相打架标定工程师也不知道该往哪个方向调。2. 巡航功能场景定义从 ODD 到场景库的拆解方法场景定义的关键是“可枚举、可复现、可判定”。巡航功能不是只有高速跟车还有城市 StopGo、弯道、坡道、切入切出。下面从 ODD 边界开始把场景拆成可被需求追溯的字段。2.1 用 ODD 边界锁定巡航功能可用的道路与交通条件写 ODD 时最忌讳“正常道路”“良好天气”这类词需求工程师没法拿它做验证。常见做法是把道路类型、车道线、曲率、天气、光照、交通密度、速度范围、目标类型逐项枚举成数值或状态。比如 CCS 常见激活区间是 40-130 km/hACC 扩展到 0-130 km/h其中 0 km/h 附近要支持 StopGo。每个 ODD 维度都要映射到需求 ID否则它只是说明书。| ODD 维度 | 示例取值 | 对巡航功能的影响 | 需求归属 | | 道路类型 | 封闭高速、城市快速路 | 决定是否支持 StopGo | FR-001 | | 车道曲率 | 半径 250 m 可激活 150 m 逐步降级 | 影响横向感知和目标筛选 | SR-012 | | 天气 | 无雨、小雨、大雨 | 大雨限制最高设定车速 | SR-020 | | 交通密度 | 低、中、高 | 高密度下缩短时距会引发频繁制动 | FR-008 | | 自车速度 | 0-130 km/h | 决定 ACC 与 CCS 的激活区间 | FR-002 |这张表不是抄来的标准而是多数项目会采用的拆法。把 ODD 写成表格后下一步才是往里面填场景。2.2 场景元素枚举把跟车、切入、静止目标写成可执行条目巡航功能场景六要素是道路、交通、目标、环境、自车状态、驾驶员状态。以“旁车 Cut-in”为例要写清楚自车速度 80 km/h、前车距离 30 m、旁车以 20 km/h 相对速度切入、切入后距离 12 m预期行为是平滑减速到 1.5 s 时距减速度不超过 -3.5 m/s²且 ACC 不退出。每个场景必须带触发条件、初始状态、预期行为和失败判据。操作步骤可以这样走先列主场景稳定跟车、前车减速、前车切出、旁车切入、静止目标、StopGo。对每个主场景做变体相对速度、距离、曲率、天气、目标类型。给每个变体写触发条件和预期行为行为要带数值。把预期行为关联到功能需求和系统需求 ID。标记哪些场景属于安全相关需要故障注入和降级验证。场景条目不要写“前方有车时减速”要写“相对速度 20 km/h、距离 12 m 时请求减速度不超过 -3.5 m/s²”。有了这种条目测试工程师才能判 pass/fail。2.3 用 YAML 建一个最小巡航场景库并做需求追溯场景库最常见的形式是 YAML 或 JSON方便版本管理和脚本校验。下面给一个最小 Cut-in 场景。# 最小巡航场景库示例Cut-in 场景 scenario_id: ACC_CUTIN_001 odd: road: highway speed_limit_kph: 120 weather: no_rain curvature_radius_m: 400 ego: speed_kph: 80 set_speed_kph: 90 time_gap_s: 1.5 lead: initial_distance_m: 30 speed_kph: 60 cutin: relative_speed_kph: 20 final_distance_m: 12 lateral_speed_mps: 0.8 expected: max_decel_mps2: -3.5 min_time_gap_s: 1.2 function_state: active driver_override: false requirement_ids: - FR_003 - SR_007 - SR_015配套的校验脚本可以放在 CI 里防止场景字段缺失或需求 ID 为空。import yaml REQUIRED_FIELDS [scenario_id, odd, ego, lead, expected, requirement_ids] def validate_scenario(path): with open(path, encodingutf-8) as f: data yaml.safe_load(f) missing [k for k in REQUIRED_FIELDS if k not in data] if missing: raise ValueError(f场景缺少字段: {missing}) # 需求 ID 必须非空否则场景无法追溯 if not data[requirement_ids]: raise ValueError(requirement_ids 为空无法做追溯) # 检查减速度方向预期最大减速度用负值表示制动 if data[expected][max_decel_mps2] 0: raise ValueError(max_decel_mps2 应为负值) return True assert validate_scenario(acc_cutin_001.yaml) print(场景校验通过)这段代码只做字段完整性和基础语义校验确保场景能被需求追溯。参数说明scenario_id是场景唯一编号odd存放运行设计域ego.set_speed_kph是设定车速lead.initial_distance_m是初始车距cutin.relative_speed_kph是切入相对速度expected.max_decel_mps2是预期最大减速度requirement_ids关联需求。实际项目里可以扩展 JSON Schema把枚举值也约束住。追溯矩阵可以长这样| 场景编号 | 场景名称 | 功能需求 | 系统需求 | 验证方法 | | ACC_CUTIN_001 | 旁车切入 | FR_003 跟车时距保持 | SR_007 目标筛选、SR_015 制动响应 | 仿真实车 | | ACC_STOP_002 | 静止目标 | FR_005 静止目标停车 | SR_009 静止目标识别 | 台架实车 | | ACC_CURVE_003 | 弯道跟车 | FR_006 弯道降级 | SR_012 曲率估计 | 仿真 |注意场景库版本要和需求基线一起冻结否则测试执行时需求已经变了追溯矩阵会失效。3. 巡航系统需求解析功能需求如何落到系统需求场景定义给出“要什么”系统需求解析给出“做到什么程度”。功能需求描述行为系统需求描述接口、性能和故障边界。两者之间要有追溯不能从场景直接跳代码否则控制器写完了才发现感知给不出对应精度。3.1 功能需求目标车速、跟车时距与 StopGo功能需求是驾驶员能感知、测试能判定的条目。巡航功能常见功能需求包括FR-001驾驶员设定车速在 30-130 km/h步进 1 km/h 或 5 km/h。FR-002ACC 在 0-130 km/h 范围内可用0 km/h 支持 StopGo。FR-003跟车时距可选 1.0/1.5/2.0/2.5 s。FR-004前车切出后自车自动加速到设定车速加速度不超过 2.0 m/s²。FR-005对静止目标在 TTC 大于 2.5 s 时开始减速最大减速度不超过 -3.5 m/s²必要时升级到 -6.0 m/s²。FR-006曲率半径小于 150 m 且车速大于 80 km/h 时限制设定车速或请求接管。| 功能需求 ID | 描述 | 关键参数 | 场景来源 | | FR-001 | 设定车速 | 30-130 km/h步进 1 或 5 | 驾驶员输入 | | FR-003 | 跟车时距 | 1.0/1.5/2.0/2.5 s | 稳定跟车 | | FR-005 | 静止目标停车 | TTC 2.5 s减速度 -3.5 | 静止目标 | | FR-006 | 弯道降级 | 曲率半径 150 m | 弯道跟车 |功能需求要能被驾驶员感知也要能被测试判定。写“保证安全”没有意义要写触发条件、阈值和可测数值。比如“前车切出后 2 s 内开始加速”就比“及时恢复设定车速”有用得多。3.2 系统需求感知、执行与 HMI 的接口约束系统需求把功能需求翻译成感知、执行、HMI 和通信的具体约束。常见拆法如下感知前向毫米波雷达和摄像头融合目标距离范围 0.5-150 m距离精度 ±2% 或 ±0.5 m速度精度 ±0.5 m/s输出周期 50 ms时延 150 ms。执行驱动扭矩请求范围 0-100%制动减速度请求 0 到 -6.0 m/s²响应时间 200 msjerk 限制 5 m/s³。HMIACC 激活时显示设定车速和时距退出时声音报警故障时显示故障码。通信CAN FD 或以太网信号超时 100 ms 进入降级。| 系统需求 ID | 指标 | 验证方法 | | SR-007 | 目标筛选延迟 150 ms | 台架注入 | | SR-009 | 静止目标识别距离 100 m | 雷达测试 | | SR-015 | 制动响应 200 ms | 实车测量 | | SR-020 | 雨雾降级策略 | 环境舱 |系统需求要写接口和数值不要写“感知要准确”。每个系统需求对应一个功能需求至少要有一个验证方法。如果某个系统需求找不到验证方法要么指标写得不可测要么它根本不是系统需求而是设计约束。3.3 性能参数表与安全需求解析性能参数是需求解析阶段最需要拉齐的部分。下面是常见巡航功能的参数范围。| 参数 | 典型值 | 说明 | | 最大加速度 | 2.0 m/s² | 切出后加速 | | 舒适减速度 | -3.5 m/s² | 一般跟车 | | 紧急减速度 | -6.0 m/s² | 静止目标或 Cut-in | | 跟车时距 | 1.0-2.5 s | 驾驶员可选 | | 最小跟车距离 | 5 m | 低速 StopGo | | 控制周期 | 50 ms | 纵向控制 | | 目标时延 | 150 ms | 感知到执行 |安全需求上常见做法是把“非预期加速”和“非预期制动”分别做安全分析分配功能安全等级。故障时退出并提示驾驶员单点故障不能导致非预期加速。下面这段代码用于需求解析阶段的边界估算。def safety_distance(speed_mps, time_gap_s, decel_mps2): 计算给定速度和减速度下的理论安全距离 # 制动距离 v^2 / (2 * |a|) braking (speed_mps ** 2) / (2 * abs(decel_mps2)) # 时距距离 v * t gap speed_mps * time_gap_s return braking gap v 22.22 # 80 km/h print(round(safety_distance(v, 1.5, 3.5), 2)) # 单位 m这个函数用于需求解析阶段做边界估算不替代控制器设计。参数说明speed_mps是自车速度time_gap_s是跟车时距decel_mps2是预期减速度取正值表示减速度大小。结果给出“制动距离 时距距离”的粗算安全距离。实际系统还要考虑目标速度、反应时间和传感器延迟。4. 巡航功能实现与标定状态机、纵向控制和参数校核需求落到实现时最怕状态机乱跳和参数拍脑袋。巡航功能通常有一个明确的状态机激活、待机、退出、故障、驾驶员接管。纵向控制负责把期望加速度变成驱动或制动请求。下面按可复现的顺序写。4.1 激活/退出状态机与驾驶员接管条件状态机要覆盖合法迁移和非法事件保持。常见状态如下| 状态 | 进入条件 | 退出条件 | 输出 | | OFF | 上电默认 | 按下主开关 | 无 | | STANDBY | 主开关开条件满足 | 按下 SET | 显示待机 | | ACTIVE | 车速在 ODD无故障 | 制动、取消、故障、超时 | 扭矩/制动请求 | | OVERRIDE | 驾驶员踩油门或制动 | 释放后条件满足 | 驾驶员优先 | | FAULT | 传感器故障、通信超时 | 故障清除并重启 | 降级报警 |用代码表达时可以这样from enum import Enum class State(Enum): OFF 0 STANDBY 1 ACTIVE 2 OVERRIDE 3 FAULT 4 def next_state(state, event): transition { (State.OFF, main_switch): State.STANDBY, (State.STANDBY, set): State.ACTIVE, (State.ACTIVE, brake): State.OVERRIDE, (State.ACTIVE, fault): State.FAULT, (State.OVERRIDE, release): State.STANDBY, (State.FAULT, clear): State.OFF, } return transition.get((state, event), state)状态机只处理合法迁移非法事件保持原状态防止误激活。参数说明state是当前状态event是驾驶员输入或系统事件。实际项目里还要加去抖时间和条件守卫比如车速、车门、安全带、雷达可用性。如果条件守卫没写进状态机测试时会出现“满足条件但不激活”的偶发问题。4.2 纵向控制参数加速度、减速度与跟车时距怎么设纵向控制的目标是把实际车距收敛到时距距离desired_gap ego_speed * time_gap min_gap。常见做法是用比例-积分控制或模型预测控制。参数上最大加速度 2.0 m/s²舒适减速度 -3.5 m/s²紧急减速度 -6.0 m/s²jerk 限制 5 m/s³时距 1.0/1.5/2.0/2.5 s最小跟车距离 5 m。def accel_command(ego_speed, lead_speed, distance, time_gap1.5, min_gap5.0): desired_gap ego_speed * time_gap min_gap gap_error distance - desired_gap speed_error lead_speed - ego_speed # 比例增益和速度增益需要标定此处为示例 kp, kv 0.3, 0.8 raw kp * gap_error kv * speed_error # 加速度饱和 return max(-3.5, min(2.0, raw))desired_gap是期望车距gap_error为正说明车距偏大可以加速为负则减速。speed_error用来补偿相对速度。参数说明time_gap来自驾驶员选择min_gap是低速兜底距离kp和kv需要按车型标定。输出被限制在舒适减速度和最大加速度之间。实际还要做 jerk 限制和制动/驱动切换否则乘客会感到顿挫。4.3 用 Python 做需求仿真校核与边界扫描需求解析阶段可以用脚本扫描时距和速度组合检查最小距离是否合理。import numpy as np def min_distance_check(time_gap, ego_kph, lead_kph, decel3.5, delay0.15): ego ego_kph / 3.6 lead lead_kph / 3.6 rel ego - lead if rel 0: return np.inf # 简化延迟期间自车继续行驶随后以 decel 减速 delay_dist ego * delay brake_dist (ego ** 2 - lead ** 2) / (2 * decel) return delay_dist brake_dist - ego * time_gap for tg in [1.0, 1.5, 2.0, 2.5]: print(tg, round(min_distance_check(tg, 80, 60), 2))这段扫描用于检查不同时距下自车从 80 km/h 接近 60 km/h 前车所需的最小距离帮助需求工程师判断时距档位是否合理。参数说明time_gap是跟车时距ego_kph和lead_kph是自车与前车速度decel是减速度大小delay是系统延迟。输出为负说明当前时距下初始距离不足需要更早制动或限制时距下限。5. 巡航场景覆盖度验证与系统需求排错技巧场景定义和需求解析做完后要验证覆盖度。不是跑一遍高速跟车就算完要看极端组合有没有被场景库和需求覆盖。下面给覆盖度表格和常见失效排查。5.1 场景覆盖度评估与需求追溯检查| 场景类型 | 覆盖状态 | 测试方法 | 对应需求 | | 稳定跟车 | 已覆盖 | 仿真实车 | FR_003 | | 前车切出 | 已覆盖 | 仿真 | FR_004 | | 旁车切入 | 部分覆盖 | 仿真实车 | FR_003/SR_007 | | 静止目标 | 待补 | 台架实车 | FR_005/SR_009 | | 弯道降级 | 已覆盖 | 仿真 | FR_006/SR_012 | | 雨雾降级 | 待补 | 环境舱 | SR_020 |追溯检查可以用脚本自动跑防止场景引用了已删除或改名的需求。import yaml def trace_check(scenario_file, requirements_file): with open(scenario_file, encodingutf-8) as f: scen yaml.safe_load(f) with open(requirements_file, encodingutf-8) as f: reqs yaml.safe_load(f) req_ids {r[id] for r in reqs} missing [rid for rid in scen[requirement_ids] if rid not in req_ids] if missing: raise ValueError(f场景 {scen[scenario_id]} 引用了不存在需求: {missing}) return True这段检查防止追溯链断裂。参数说明scenario_file是场景 YAMLrequirements_file是需求清单requirement_ids是场景关联的需求 ID。需求基线变更后要重新跑否则测试报告里的追溯矩阵会过期。5.2 常见失效静止目标、近距离切入、弯道误判怎么排查排查顺序可以固定下来先看日志里的场景编号和需求 ID确认失效场景是否在场景库内。检查感知目标列表距离、速度、RCS、置信度、跟踪 ID 是否稳定。检查状态机是否因为超时、条件守卫、驾驶员输入退出。检查控制输出加速度请求是否被饱和、被 jerk 限制截断。回灌场景改单一变量看失效边界。import json def parse_log(line): data json.loads(line) # 只保留排查巡航失效需要的字段 return { t: data[timestamp], state: data[acc_state], target_id: data.get(target_id), distance: data.get(distance_m), rel_speed: data.get(relative_speed_mps), accel_cmd: data.get(accel_cmd_mps2), scenario: data.get(scenario_id), } # 示例过滤出 ACC 退出前后 2 秒的日志 logs [parse_log(l) for l in open(acc_log.jsonl, encodingutf-8)]把日志字段压缩到状态、目标、距离、相对速度、加速度指令和场景编号方便按场景回放。参数说明timestamp用于对齐时间acc_state判断是否退出distance_m和relative_speed_mps用于复现 TTCscenario_id用于回灌。静止目标排查重点看雷达对静止物体的过滤逻辑近距离切入重点看目标筛选和时距下限弯道误判重点看曲率估计和相邻车道目标。把场景编号写进回放日志下次失效直接按编号回灌比重新造场景快得多。本文还有配套的精品资源点击获取
简介这份资料围绕智能驾驶巡航功能ACCL2级辅助驾驶展开适合智驾产品经理、功能定义工程师、系统需求与测试人员作为场景梳理与需求拆解的参考模板。内容从功能简介、场景定义、系统需求三个层面组织梳理了定速巡航、跟车巡航、跟随前车停止与起步、智能限速控制、智能红绿灯启停等主场景给出41条场景描述及关键参数定义并覆盖智能限速、V2X与红绿灯交通等典型工况。系统需求部分阐述了7个状态之间的条件切换逻辑并从法规合规、交互体验及与车辆动态控制、传感器融合、车联网等关联系统的信息交互出发整理了35条域控制器需求同时涉及功能安全中的故障检测与接管提醒后续还将持续更新KPI与功能安全信息。资源包内1个PDF文件约1.44MB篇幅紧凑、结构清晰便于快速通读与按模块检索。目前已有413人学习下载。1. 巡航功能场景定义不是写文档而是给系统需求画边界很多团队把 ACC 跟车做得很顺却在近距离 Cut-in、静止目标、弯道曲率突变时频繁退出回头查代码发现控制器没问题问题出在场景定义没有把边界收住。巡航功能场景定义与系统需求解析要做的就是把“驾驶员按下巡航按钮后车应该怎么走”这种自然语言拆成 ODD、场景条目、功能需求、系统需求和验证用例。它面向的是功能设计、需求工程、测试标定和系统集成人员也适合刚接手 ADAS 纵向功能的人建立全局视角。场景定义不是文档工作而是后续控制器参数、传感器选型、HMI 报警和故障降级的总开关。边界没定清楚系统需求就会互相打架标定工程师也不知道该往哪个方向调。2. 巡航功能场景定义从 ODD 到场景库的拆解方法场景定义的关键是“可枚举、可复现、可判定”。巡航功能不是只有高速跟车还有城市 StopGo、弯道、坡道、切入切出。下面从 ODD 边界开始把场景拆成可被需求追溯的字段。2.1 用 ODD 边界锁定巡航功能可用的道路与交通条件写 ODD 时最忌讳“正常道路”“良好天气”这类词需求工程师没法拿它做验证。常见做法是把道路类型、车道线、曲率、天气、光照、交通密度、速度范围、目标类型逐项枚举成数值或状态。比如 CCS 常见激活区间是 40-130 km/hACC 扩展到 0-130 km/h其中 0 km/h 附近要支持 StopGo。每个 ODD 维度都要映射到需求 ID否则它只是说明书。| ODD 维度 | 示例取值 | 对巡航功能的影响 | 需求归属 | | 道路类型 | 封闭高速、城市快速路 | 决定是否支持 StopGo | FR-001 | | 车道曲率 | 半径 250 m 可激活 150 m 逐步降级 | 影响横向感知和目标筛选 | SR-012 | | 天气 | 无雨、小雨、大雨 | 大雨限制最高设定车速 | SR-020 | | 交通密度 | 低、中、高 | 高密度下缩短时距会引发频繁制动 | FR-008 | | 自车速度 | 0-130 km/h | 决定 ACC 与 CCS 的激活区间 | FR-002 |这张表不是抄来的标准而是多数项目会采用的拆法。把 ODD 写成表格后下一步才是往里面填场景。2.2 场景元素枚举把跟车、切入、静止目标写成可执行条目巡航功能场景六要素是道路、交通、目标、环境、自车状态、驾驶员状态。以“旁车 Cut-in”为例要写清楚自车速度 80 km/h、前车距离 30 m、旁车以 20 km/h 相对速度切入、切入后距离 12 m预期行为是平滑减速到 1.5 s 时距减速度不超过 -3.5 m/s²且 ACC 不退出。每个场景必须带触发条件、初始状态、预期行为和失败判据。操作步骤可以这样走先列主场景稳定跟车、前车减速、前车切出、旁车切入、静止目标、StopGo。对每个主场景做变体相对速度、距离、曲率、天气、目标类型。给每个变体写触发条件和预期行为行为要带数值。把预期行为关联到功能需求和系统需求 ID。标记哪些场景属于安全相关需要故障注入和降级验证。场景条目不要写“前方有车时减速”要写“相对速度 20 km/h、距离 12 m 时请求减速度不超过 -3.5 m/s²”。有了这种条目测试工程师才能判 pass/fail。2.3 用 YAML 建一个最小巡航场景库并做需求追溯场景库最常见的形式是 YAML 或 JSON方便版本管理和脚本校验。下面给一个最小 Cut-in 场景。# 最小巡航场景库示例Cut-in 场景 scenario_id: ACC_CUTIN_001 odd: road: highway speed_limit_kph: 120 weather: no_rain curvature_radius_m: 400 ego: speed_kph: 80 set_speed_kph: 90 time_gap_s: 1.5 lead: initial_distance_m: 30 speed_kph: 60 cutin: relative_speed_kph: 20 final_distance_m: 12 lateral_speed_mps: 0.8 expected: max_decel_mps2: -3.5 min_time_gap_s: 1.2 function_state: active driver_override: false requirement_ids: - FR_003 - SR_007 - SR_015配套的校验脚本可以放在 CI 里防止场景字段缺失或需求 ID 为空。import yaml REQUIRED_FIELDS [scenario_id, odd, ego, lead, expected, requirement_ids] def validate_scenario(path): with open(path, encodingutf-8) as f: data yaml.safe_load(f) missing [k for k in REQUIRED_FIELDS if k not in data] if missing: raise ValueError(f场景缺少字段: {missing}) # 需求 ID 必须非空否则场景无法追溯 if not data[requirement_ids]: raise ValueError(requirement_ids 为空无法做追溯) # 检查减速度方向预期最大减速度用负值表示制动 if data[expected][max_decel_mps2] 0: raise ValueError(max_decel_mps2 应为负值) return True assert validate_scenario(acc_cutin_001.yaml) print(场景校验通过)这段代码只做字段完整性和基础语义校验确保场景能被需求追溯。参数说明scenario_id是场景唯一编号odd存放运行设计域ego.set_speed_kph是设定车速lead.initial_distance_m是初始车距cutin.relative_speed_kph是切入相对速度expected.max_decel_mps2是预期最大减速度requirement_ids关联需求。实际项目里可以扩展 JSON Schema把枚举值也约束住。追溯矩阵可以长这样| 场景编号 | 场景名称 | 功能需求 | 系统需求 | 验证方法 | | ACC_CUTIN_001 | 旁车切入 | FR_003 跟车时距保持 | SR_007 目标筛选、SR_015 制动响应 | 仿真实车 | | ACC_STOP_002 | 静止目标 | FR_005 静止目标停车 | SR_009 静止目标识别 | 台架实车 | | ACC_CURVE_003 | 弯道跟车 | FR_006 弯道降级 | SR_012 曲率估计 | 仿真 |注意场景库版本要和需求基线一起冻结否则测试执行时需求已经变了追溯矩阵会失效。3. 巡航系统需求解析功能需求如何落到系统需求场景定义给出“要什么”系统需求解析给出“做到什么程度”。功能需求描述行为系统需求描述接口、性能和故障边界。两者之间要有追溯不能从场景直接跳代码否则控制器写完了才发现感知给不出对应精度。3.1 功能需求目标车速、跟车时距与 StopGo功能需求是驾驶员能感知、测试能判定的条目。巡航功能常见功能需求包括FR-001驾驶员设定车速在 30-130 km/h步进 1 km/h 或 5 km/h。FR-002ACC 在 0-130 km/h 范围内可用0 km/h 支持 StopGo。FR-003跟车时距可选 1.0/1.5/2.0/2.5 s。FR-004前车切出后自车自动加速到设定车速加速度不超过 2.0 m/s²。FR-005对静止目标在 TTC 大于 2.5 s 时开始减速最大减速度不超过 -3.5 m/s²必要时升级到 -6.0 m/s²。FR-006曲率半径小于 150 m 且车速大于 80 km/h 时限制设定车速或请求接管。| 功能需求 ID | 描述 | 关键参数 | 场景来源 | | FR-001 | 设定车速 | 30-130 km/h步进 1 或 5 | 驾驶员输入 | | FR-003 | 跟车时距 | 1.0/1.5/2.0/2.5 s | 稳定跟车 | | FR-005 | 静止目标停车 | TTC 2.5 s减速度 -3.5 | 静止目标 | | FR-006 | 弯道降级 | 曲率半径 150 m | 弯道跟车 |功能需求要能被驾驶员感知也要能被测试判定。写“保证安全”没有意义要写触发条件、阈值和可测数值。比如“前车切出后 2 s 内开始加速”就比“及时恢复设定车速”有用得多。3.2 系统需求感知、执行与 HMI 的接口约束系统需求把功能需求翻译成感知、执行、HMI 和通信的具体约束。常见拆法如下感知前向毫米波雷达和摄像头融合目标距离范围 0.5-150 m距离精度 ±2% 或 ±0.5 m速度精度 ±0.5 m/s输出周期 50 ms时延 150 ms。执行驱动扭矩请求范围 0-100%制动减速度请求 0 到 -6.0 m/s²响应时间 200 msjerk 限制 5 m/s³。HMIACC 激活时显示设定车速和时距退出时声音报警故障时显示故障码。通信CAN FD 或以太网信号超时 100 ms 进入降级。| 系统需求 ID | 指标 | 验证方法 | | SR-007 | 目标筛选延迟 150 ms | 台架注入 | | SR-009 | 静止目标识别距离 100 m | 雷达测试 | | SR-015 | 制动响应 200 ms | 实车测量 | | SR-020 | 雨雾降级策略 | 环境舱 |系统需求要写接口和数值不要写“感知要准确”。每个系统需求对应一个功能需求至少要有一个验证方法。如果某个系统需求找不到验证方法要么指标写得不可测要么它根本不是系统需求而是设计约束。3.3 性能参数表与安全需求解析性能参数是需求解析阶段最需要拉齐的部分。下面是常见巡航功能的参数范围。| 参数 | 典型值 | 说明 | | 最大加速度 | 2.0 m/s² | 切出后加速 | | 舒适减速度 | -3.5 m/s² | 一般跟车 | | 紧急减速度 | -6.0 m/s² | 静止目标或 Cut-in | | 跟车时距 | 1.0-2.5 s | 驾驶员可选 | | 最小跟车距离 | 5 m | 低速 StopGo | | 控制周期 | 50 ms | 纵向控制 | | 目标时延 | 150 ms | 感知到执行 |安全需求上常见做法是把“非预期加速”和“非预期制动”分别做安全分析分配功能安全等级。故障时退出并提示驾驶员单点故障不能导致非预期加速。下面这段代码用于需求解析阶段的边界估算。def safety_distance(speed_mps, time_gap_s, decel_mps2): 计算给定速度和减速度下的理论安全距离 # 制动距离 v^2 / (2 * |a|) braking (speed_mps ** 2) / (2 * abs(decel_mps2)) # 时距距离 v * t gap speed_mps * time_gap_s return braking gap v 22.22 # 80 km/h print(round(safety_distance(v, 1.5, 3.5), 2)) # 单位 m这个函数用于需求解析阶段做边界估算不替代控制器设计。参数说明speed_mps是自车速度time_gap_s是跟车时距decel_mps2是预期减速度取正值表示减速度大小。结果给出“制动距离 时距距离”的粗算安全距离。实际系统还要考虑目标速度、反应时间和传感器延迟。4. 巡航功能实现与标定状态机、纵向控制和参数校核需求落到实现时最怕状态机乱跳和参数拍脑袋。巡航功能通常有一个明确的状态机激活、待机、退出、故障、驾驶员接管。纵向控制负责把期望加速度变成驱动或制动请求。下面按可复现的顺序写。4.1 激活/退出状态机与驾驶员接管条件状态机要覆盖合法迁移和非法事件保持。常见状态如下| 状态 | 进入条件 | 退出条件 | 输出 | | OFF | 上电默认 | 按下主开关 | 无 | | STANDBY | 主开关开条件满足 | 按下 SET | 显示待机 | | ACTIVE | 车速在 ODD无故障 | 制动、取消、故障、超时 | 扭矩/制动请求 | | OVERRIDE | 驾驶员踩油门或制动 | 释放后条件满足 | 驾驶员优先 | | FAULT | 传感器故障、通信超时 | 故障清除并重启 | 降级报警 |用代码表达时可以这样from enum import Enum class State(Enum): OFF 0 STANDBY 1 ACTIVE 2 OVERRIDE 3 FAULT 4 def next_state(state, event): transition { (State.OFF, main_switch): State.STANDBY, (State.STANDBY, set): State.ACTIVE, (State.ACTIVE, brake): State.OVERRIDE, (State.ACTIVE, fault): State.FAULT, (State.OVERRIDE, release): State.STANDBY, (State.FAULT, clear): State.OFF, } return transition.get((state, event), state)状态机只处理合法迁移非法事件保持原状态防止误激活。参数说明state是当前状态event是驾驶员输入或系统事件。实际项目里还要加去抖时间和条件守卫比如车速、车门、安全带、雷达可用性。如果条件守卫没写进状态机测试时会出现“满足条件但不激活”的偶发问题。4.2 纵向控制参数加速度、减速度与跟车时距怎么设纵向控制的目标是把实际车距收敛到时距距离desired_gap ego_speed * time_gap min_gap。常见做法是用比例-积分控制或模型预测控制。参数上最大加速度 2.0 m/s²舒适减速度 -3.5 m/s²紧急减速度 -6.0 m/s²jerk 限制 5 m/s³时距 1.0/1.5/2.0/2.5 s最小跟车距离 5 m。def accel_command(ego_speed, lead_speed, distance, time_gap1.5, min_gap5.0): desired_gap ego_speed * time_gap min_gap gap_error distance - desired_gap speed_error lead_speed - ego_speed # 比例增益和速度增益需要标定此处为示例 kp, kv 0.3, 0.8 raw kp * gap_error kv * speed_error # 加速度饱和 return max(-3.5, min(2.0, raw))desired_gap是期望车距gap_error为正说明车距偏大可以加速为负则减速。speed_error用来补偿相对速度。参数说明time_gap来自驾驶员选择min_gap是低速兜底距离kp和kv需要按车型标定。输出被限制在舒适减速度和最大加速度之间。实际还要做 jerk 限制和制动/驱动切换否则乘客会感到顿挫。4.3 用 Python 做需求仿真校核与边界扫描需求解析阶段可以用脚本扫描时距和速度组合检查最小距离是否合理。import numpy as np def min_distance_check(time_gap, ego_kph, lead_kph, decel3.5, delay0.15): ego ego_kph / 3.6 lead lead_kph / 3.6 rel ego - lead if rel 0: return np.inf # 简化延迟期间自车继续行驶随后以 decel 减速 delay_dist ego * delay brake_dist (ego ** 2 - lead ** 2) / (2 * decel) return delay_dist brake_dist - ego * time_gap for tg in [1.0, 1.5, 2.0, 2.5]: print(tg, round(min_distance_check(tg, 80, 60), 2))这段扫描用于检查不同时距下自车从 80 km/h 接近 60 km/h 前车所需的最小距离帮助需求工程师判断时距档位是否合理。参数说明time_gap是跟车时距ego_kph和lead_kph是自车与前车速度decel是减速度大小delay是系统延迟。输出为负说明当前时距下初始距离不足需要更早制动或限制时距下限。5. 巡航场景覆盖度验证与系统需求排错技巧场景定义和需求解析做完后要验证覆盖度。不是跑一遍高速跟车就算完要看极端组合有没有被场景库和需求覆盖。下面给覆盖度表格和常见失效排查。5.1 场景覆盖度评估与需求追溯检查| 场景类型 | 覆盖状态 | 测试方法 | 对应需求 | | 稳定跟车 | 已覆盖 | 仿真实车 | FR_003 | | 前车切出 | 已覆盖 | 仿真 | FR_004 | | 旁车切入 | 部分覆盖 | 仿真实车 | FR_003/SR_007 | | 静止目标 | 待补 | 台架实车 | FR_005/SR_009 | | 弯道降级 | 已覆盖 | 仿真 | FR_006/SR_012 | | 雨雾降级 | 待补 | 环境舱 | SR_020 |追溯检查可以用脚本自动跑防止场景引用了已删除或改名的需求。import yaml def trace_check(scenario_file, requirements_file): with open(scenario_file, encodingutf-8) as f: scen yaml.safe_load(f) with open(requirements_file, encodingutf-8) as f: reqs yaml.safe_load(f) req_ids {r[id] for r in reqs} missing [rid for rid in scen[requirement_ids] if rid not in req_ids] if missing: raise ValueError(f场景 {scen[scenario_id]} 引用了不存在需求: {missing}) return True这段检查防止追溯链断裂。参数说明scenario_file是场景 YAMLrequirements_file是需求清单requirement_ids是场景关联的需求 ID。需求基线变更后要重新跑否则测试报告里的追溯矩阵会过期。5.2 常见失效静止目标、近距离切入、弯道误判怎么排查排查顺序可以固定下来先看日志里的场景编号和需求 ID确认失效场景是否在场景库内。检查感知目标列表距离、速度、RCS、置信度、跟踪 ID 是否稳定。检查状态机是否因为超时、条件守卫、驾驶员输入退出。检查控制输出加速度请求是否被饱和、被 jerk 限制截断。回灌场景改单一变量看失效边界。import json def parse_log(line): data json.loads(line) # 只保留排查巡航失效需要的字段 return { t: data[timestamp], state: data[acc_state], target_id: data.get(target_id), distance: data.get(distance_m), rel_speed: data.get(relative_speed_mps), accel_cmd: data.get(accel_cmd_mps2), scenario: data.get(scenario_id), } # 示例过滤出 ACC 退出前后 2 秒的日志 logs [parse_log(l) for l in open(acc_log.jsonl, encodingutf-8)]把日志字段压缩到状态、目标、距离、相对速度、加速度指令和场景编号方便按场景回放。参数说明timestamp用于对齐时间acc_state判断是否退出distance_m和relative_speed_mps用于复现 TTCscenario_id用于回灌。静止目标排查重点看雷达对静止物体的过滤逻辑近距离切入重点看目标筛选和时距下限弯道误判重点看曲率估计和相邻车道目标。把场景编号写进回放日志下次失效直接按编号回灌比重新造场景快得多。本文还有配套的精品资源点击获取
