这篇文章介绍了一个名为 Req2Road（从需求到上路）的创新系统。简单来说，它是一套利用人工智能（AI），自动把汽车工程师写的“文字说明书”变成“实际可运行的测试代码”的工具。
为了让你更容易理解，我们可以把整个过程想象成**“把一本复杂的食谱，自动变成一道能直接端上桌的菜肴”**。
1. 背景：为什么需要这个？
现在的汽车（软件定义汽车，SDV）越来越像装了轮子的超级电脑，里面的软件功能成千上万。
- 传统痛点：工程师们写的需求是自然语言（比如：“如果检测到后座有孩子，5 分钟后要鸣笛”），还有各种图表。但测试人员需要把这些文字翻译成代码，让汽车去执行。这就像要把“食谱”翻译成“厨师的具体动作指令”。
- 困难：以前这全靠人工，容易出错、效率低，而且不同部门用的工具不一样，就像厨师用的锅具不通用，导致很难把“食谱”直接变成菜。
2. Req2Road 是如何工作的？（四个步骤）
这个系统就像一个超级智能的“翻译官 + 厨师团队”，分四步走：
第一步：读懂“食谱”（生成测试场景）
- 输入：工程师写的文字需求（比如“孩子检测系统”的说明书）和流程图。
- AI 动作：系统里的大语言模型（LLM） 像一位经验丰富的老厨师，读懂了文字，然后把它写成一种标准的“测试剧本”（叫 Gherkin）。
- 比喻：就像把“把鸡蛋打散”这种模糊指令，变成了标准的“步骤 1：取鸡蛋，步骤 2：敲开蛋壳”。
第二步：找对“食材”（信号映射）
- 挑战：汽车里有成千上万个传感器信号（比如“车门状态”、“电池电量”），就像超市里有几万个商品。如果让 AI 直接去几万个商品里找，它很容易“幻觉”（找错东西）。
- AI 动作：系统使用了一种叫 RAG（检索增强生成） 的技术。
- 比喻：这就像在让厨师找“盐”之前，先让助手去缩小范围，只把“调味品区”的货架（比如 16 种常用调料）拿给厨师看，而不是把整个超市（982 种信号）都搬过去。
- 这样，AI 就能准确地把“鸣笛”对应到汽车里的“喇叭信号”，把“空调”对应到“温度控制信号”。
第三步：看图说话（处理图表）
- 输入：有时候需求里还有复杂的流程图或 UML 图。
- AI 动作：系统使用视觉语言模型（VLM），就像一位能看懂图纸的工程师。
- 比喻：它不仅能读文字，还能“看”懂流程图，知道如果“状态 A"变成了“状态 B"，应该触发什么动作。
第四步：下厨做菜（生成代码）
- AI 动作：最后，系统根据前面的剧本和找到的“食材”（信号），自动生成Python 测试代码。
- 结果：这些代码可以直接在电脑模拟器（SiL）里跑，甚至可以直接装进真实的汽车里跑（ViL）。
3. 他们做了什么实验？（儿童存在检测系统）
为了验证这个系统，他们选了一个很严肃的安全功能：儿童存在检测系统（CPDS）。
- 场景：如果车停着，后座有孩子被遗忘了，系统该怎么办？（比如：先提醒司机，如果没反应，就开空调、按喇叭、甚至报警）。
- 过程：
- 输入 36 条关于这个系统的文字需求。
- 让 Req2Road 自动生成测试剧本和代码。
- 结果：
- 89% 的需求（32 条）直接变成了可运行的测试，无需修改。
- 剩下的 4 条因为描述太模糊（比如“或者”的情况没写清楚），需要人工稍微改一下。
- 真实测试：他们把生成的代码装进了一辆真实的汽车里，甚至在后座放了一个模拟婴儿（会哭、会震动），测试系统是否真的会启动空调、按喇叭。结果测试通过了！
4. 核心亮点与局限
亮点（好消息）：
- 自动化：以前需要人花几天写的测试代码，现在 AI 几分钟就能搞定草稿。
- 通用性：因为用了标准的“信号字典”（VSS），这套代码可以在不同的汽车型号、不同的测试台上跑，不用重写。
- 人机协作：它不是完全取代人，而是**“人机回环”**。AI 做 90% 的脏活累活，人类专家负责最后把关（比如检查那些模糊的逻辑）。
局限（需要注意的地方）：
- 不能太复杂：如果需求太复杂（比如同时涉及 3 个以上的条件），AI 生成的代码可能会出错，需要人工检查。
- 数据隐私：有些汽车公司的核心机密（比如具体的专利图纸）不能发给公用的 AI 模型，所以系统支持在本地部署 AI 模型来保护隐私。
- 幻觉问题：如果让 AI 直接面对几千个信号而不加筛选，它很容易“瞎编”信号，所以必须先用“缩小范围”的策略。
总结
Req2Road 就像是给汽车测试领域装了一个**“智能翻译器”**。它把工程师脑子里的“想法”（自然语言需求），自动翻译成了汽车能听懂的“行动指令”（可执行代码）。
虽然它还不能完全取代人类测试工程师（毕竟安全无小事，必须有人把关），但它极大地提高了效率，让汽车软件测试变得更快速、更标准化，让未来的智能汽车能更快地、更安全地上路。
Req2Road：面向软件定义汽车（SDV）测试的生成式 AI 管道技术总结
1. 研究背景与问题 (Problem)
随着汽车向软件定义汽车 (SDV) 转型，软件复杂性显著增加，导致测试工作量激增、变异性加大，且对系统性验证与确认（V&V）的压力日益增大。当前汽车测试领域面临以下核心挑战：
- 需求形式异构：需求通常以自然语言编写，规格说明混合了文本、表格和图表（如 UML 图），难以直接用于自动化测试。
- 测试资产分散：测试资产分散在异构的工具链中，缺乏统一标准。
- 自动化与可移植性不足：现有的测试规划往往不一致、依赖人工，且难以在不同子系统或测试台架间复用。信号定义的不一致阻碍了自动化和跨平台的移植。
- 可追溯性差：从自然语言需求到可执行测试用例的推导过程复杂，限制了跨工件的可追溯性。
2. 方法论：Req2Road 管道 (Methodology)
本文提出了 Req2Road，这是一个基于生成式 AI（GenAI）的端到端管道，旨在将异构的需求规格（文本、图表）转化为可在 SDV 上执行的测试工件。该管道结合了大型语言模型（LLM）、视觉 - 语言模型（VLM）和检索增强生成（RAG）技术。
核心流程
Req2Road 包含四个主要阶段：
- 初始 Gherkin 场景生成：
- 利用 LLM（如 GPT-5）和 VLM（如 Qwen 2.5 VL 72B）从自然语言需求和行为流程图（UML 状态图/流程图）中提取逻辑。
- 生成结构化的 Gherkin 场景（Given/When/Then 格式），作为 BDD（行为驱动开发）测试的基础。
- 采用“人在回路”（Human-in-the-Loop）机制进行初步的人工审查和修正。
- VSS 信号映射 (Signal Mapping)：
- 引入 车辆信号规范 (Vehicle Signal Specification, VSS) 作为标准化的信号参考，避免硬编码，实现硬件抽象和跨平台移植。
- 采用 检索增强生成 (RAG) 策略：首先使用 SentenceTransformer 将场景文本与 VSS 信号目录进行嵌入，通过最近邻搜索和交叉编码器重排序，从庞大的 VSS 目录（如 982 个信号）中预筛选出少量候选信号（如 16 个）。
- 利用 LLM（如 GPT-4o-mini）从候选列表中精确选择相关信号路径，生成包含明确 VSS 路径的 Gherkin 场景。
- 细化 Gherkin 场景生成：
- 将选定的 VSS 信号注入 Gherkin 场景，确保测试逻辑与车辆信号语义对齐。
- 测试代码生成：
- 利用 LLM（如 GPT-4.1）结合预定义的代码模板（KUKSA 客户端 API 示例、Behave 框架示例），将带有 VSS 映射的 Gherkin 场景转化为可执行的 Python 测试脚本。
- 生成的代码包含环境设置（
environment.py）和步骤定义（steps/*.py）。
关键技术组件
- 模型选择：综合评估了商业模型（GPT-4o-mini, GPT-5, Gemini 2.5 Pro）和本地部署的开源模型（Llama, Vicuna, Qwen, InternVL）。
- 执行环境：
- SiL (Software-in-the-Loop)：在
digital.auto 云原生沙箱环境中运行。
- ViL (Vehicle-in-the-Loop)：在真实车辆（搭载 NVIDIA Jetson）上运行，通过 KUKSA 实例连接车辆信号。
3. 关键贡献 (Key Contributions)
- 端到端架构演示：首次展示了从异构需求（文本 + 图表）到 SDV 可执行测试（SiL 和 ViL）的完整 GenAI 管道架构。
- VSS 标准化集成：通过 RAG 辅助的 VSS 信号映射，解决了信号定义不一致问题，显著提高了测试工件在不同子系统间的可移植性。
- 多模态模型评估：系统评估了 LLM 和 VLM 在提取行为逻辑、映射信号和生成代码方面的性能，证明了在特定任务（如从 UML 图提取信号）中 VLM 的有效性。
- 真实场景验证：在儿童存在检测系统 (CPDS) 这一安全相关案例上进行了验证，成功在仿真环境和真实车辆上执行了生成的测试。
- 开源工件：提供了包括提示词、Gherkin 文件、VSS 映射和 Python 脚本在内的完整数字资产，并在
digital.auto 平台上公开。
4. 实验结果 (Results)
研究基于 36 个源自 CPDS 升级逻辑的自然语言需求进行了评估：
- Gherkin 场景生成：
- 89% (32/36) 的需求无需修改即可转化为可执行的 Gherkin 场景。
- 剩余 4 个需求需要针对性调整，主要问题在于模糊的边缘情况和未明确枚举的"OR"条件。
- VSS 信号映射：
- RAG 预筛选至关重要：当候选信号池从 16 个缩减到全量 982 个时，映射质量显著下降（幻觉增加）。
- GPT-4o-mini 在 16 个候选信号下实现了 100% 的召回率和 0 个误报；而本地模型（Vicuna）在 16 个候选下召回率 100% 但有 7 个误报。
- 直接在全量目录上提示会导致性能大幅下降，证明了 RAG 预筛选的必要性。
- 代码生成 (Pass@k 指标)：
- 对于单个或两个需求组合的场景，GPT-4.1、GPT-4o-mini 和 GPT-5 均能达到 Pass@3 = 1（即生成 3 次尝试中至少有一次完全正确）。
- 对于三个需求组合的复杂场景，只有 GPT-4.1 达到了 Pass@3 = 1，其他模型（GPT-4o-mini, GPT-5）未能生成完全正确的解决方案（存在语法错误或逻辑终止错误）。
- 执行验证：
- 生成的测试脚本在
digital.auto (SiL) 和真实车辆 (ViL) 上均成功运行。
- ViL 测试中，系统成功触发了 HVAC 调整干预，将车内温度从 18°C 提升至 22°C，并正确执行了升级逻辑（灯光、喇叭等），证明了从仿真到实车的无缝迁移能力。
5. 意义与局限性 (Significance & Limitations)
意义
- 提升效率与可移植性：Req2Road 展示了 GenAI 如何将非结构化需求转化为标准化的可执行测试，减少了人工编写测试脚本的时间，并解决了跨平台信号定义不一致的痛点。
- 安全关键系统的可行性：在 CPDS 这一安全相关案例上的成功验证，表明在“人在回路”的监督下，GenAI 生成的测试足以覆盖安全关键行为。
- 架构指导：为未来 SDV 测试自动化提供了架构蓝图，强调了 RAG、VSS 标准化和分层模型（LLM+VLM）结合的重要性。
局限性与未来工作
- 复杂场景的鲁棒性：随着需求组合数量的增加（如 3 个以上），代码生成的正确性显著下降，需要采样、执行检查和人工审查。
- 信号目录规模：直接处理未过滤的大规模信号目录会导致幻觉，必须依赖 RAG 预筛选。
- 数据隐私：商业模型在处理敏感专有需求时存在风险，需依赖本地部署模型（目前精度略低）。
- 测试有效性：当前评估侧重于“可执行性”和“映射正确性”，尚未深入评估测试用例发现缺陷的能力（如通过故障注入测试）。
- 扩展性：目前仅在单一车辆配置和单一 SDV 平台上验证，未来需在更多样化的架构和信号目录上评估鲁棒性。
总结：Req2Road 证明了生成式 AI 在连接自然语言需求与 SDV 可执行测试之间的巨大潜力，特别是在结合 VSS 标准和 RAG 技术后，能够有效克服传统自动化测试中的异构性和可移植性障碍，但仍需人工监督以确保复杂场景下的安全性和准确性。
每周获取最佳 computer science 论文。
受到斯坦福、剑桥和法国科学院研究人员的信赖。
请查收邮箱确认订阅。
出了点问题，再试一次？
无垃圾邮件，随时退订。