Nox-Lumen Auto汽车场景
场景定位
combo agent 在汽车研发场景的解决方案，聚焦 ASPICE / V-Model 流程下的文档理解、追溯建立、合规检查、代码审查、测试生成等重复性工作。
面向：
- OEM / Tier1 研发团队
- 系统工程师 / 软件工程师
- 质量与合规团队
- 需求工程师 / 架构师
- 测试工程师 / HIL 实验室
本章同时承担方案视角与操作手册两个角色：上半段讲价值与痛点，下半段讲日常用法。汽车场景复用 combo agent 通用能力（登录、会话、上传、调用技能、编辑、导出、团队协作），本章只写汽车场景特有的内容。
行业痛点：V-Model 全链路正在断裂
汽车软件开发遵循 V-model，ASPICE 4.0 要求从需求获取（SYS.1）到系统验证（SYS.5）全过程域双向可追溯。但现实是：
追溯不了就确认不了，确认不了就不安全。 2025 年中国汽车召回 684 万辆，软件缺陷占比已升至 36.5%（国家市场监管总局）。中国车企 MC/DC 覆盖率平均不足 40%，头部企业也仅约 50%。追溯链断裂是召回和延期的系统性根因。
| 交接处 | 发生了什么 | 后果 |
|---|---|---|
| 需求获取→系统需求 | 多份异构文档格式各异，多维度变体，一对多/多对一映射不可见 | 需求遗漏、理解偏差 |
| 系统架构→软件需求 | SOA 架构下业务语言→技术语言跳跃大，映射不清晰 | 设计脱节 |
| 软件架构→详细设计 | 关键数值（信号名/阈值/接口）埋在大段文字中，一致性靠肉眼 | 参数不一致 |
| 详细设计→验证 | 量产 ECU 项目测试覆盖率不足 50%，测试用例很少标注父级需求 ID | 盲区上路 |
| 系统集成→信号验证 | 信号名/消息 ID/字节位/值域不一致，追溯链最后一环最易被忽略 | 通信故障 |
核心能力：围绕 ECU 研发与测试的四类智能体
四类专业化智能体分别承接 V-Model 的不同环节：
- 需求分析智能体 — 解析需求文档/DBC/A2L 等多源输入，自动进行需求一致性与冲突检测，输出评审建议并提示 ASIL 等级相关风险
- 智能缺陷定位智能体 — 解析 HIL/CANoe 等测试日志与诊断数据，智能分类缺陷类型（功能/通信/诊断/性能等），自动生成并回填 Polarion / Jira 缺陷工单
- 代码生成与工程化智能体 — 支持底软 / AUTOSAR 相关代码生成与配置辅助，MISRA-C 等代码规范与安全规则检查，自动接入 CI/CD 工具链
- 测试用例生成智能体 — 基于结构化需求自动生成 M-Script / TCL 测试用例，结合 FMEA 注入故障模式与边界场景，持续跟踪需求—测试覆盖关系
核心效率指标：70% 配置时间缩短 / 30–50% 项目周期缩短 / 95% 覆盖率提升
客户价值：更快、更稳、更可复制
| 维度 | 说明 |
|---|---|
| 🚀 更快 | 把原本跨部门、跨文档、跨版本的人工作业从周级压缩到天级。需求管理及代码审核：4–6 周 → 3–5 天；MCAL 底软生成：2–4 周 → 2–3 天 |
| 🔒 更稳 | 追溯更完整、审计准备更快、缺陷定位更准。交付确定性更高，合规审计时间大幅压缩，不再依赖少数专家记忆 |
| ♻️ 更可复制 | 方法论、规则、模板和历史经验被系统性沉淀，后续车型、模块和团队可以持续复用，形成组织级智能资产 |
核心能力分册
AI 需求管理
需求导入 · 追溯建立 · 版本 diff · 合规报告导出
AI 代码审查
L1 静态 + L2 语义双层审查 · 底软（MISRA / AUTOSAR / ISO 26262） + 座舱（Java / Kotlin / Compose）
汽车测试自动化
CANoe / dSPACE / NI 用例生成 · 执行 · 失败回流
MCAL 配置代理
AUTOSAR 4.x ARXML 自动生成
ASPICE 全链追溯
V-Model 双向可追溯 · 变更影响 · 覆盖审计
ALM 平台对接
DOORS / Polarion / Jama / Jira / 飞书项目 等深度集成
日常作业视图
企业系统对接清单（速查）
| 系统类型 | 支持工具 | 对接方式 |
|---|---|---|
| 需求管理 | IBM DOORS Next | OSLC RM 2.0 + Reportable REST |
| 需求管理 | DOORS 9 / Polarion / Jama / codeBeamer / 飞书项目 | REST / ReqIF / OpenAPI |
| 任务 / 缺陷 | Jira / Redmine / 禅道 / Azure DevOps | REST Webhook |
| 代码仓库 | Gerrit / GitLab / GitHub / Gitee | REST + Webhook |
| 信号 / 通信 | CAN DBC · AUTOSAR SRS · COVESA VSS | 标准文件导入 |
| HIL 测试 | CANoe · dSPACE · NI VeriStand · ETAS INCA | 脚本自动生成 + MCP |
| 文档格式 | ReqIF · DOCX · PDF · Markdown · Excel | 平台通用能力 |
常见问题
Q：我们的需求在 Word 里，没有 DOORS，能用吗？ A：可以。平台支持 DOCX / PDF / ReqIF / Excel 多种格式导入。走 需求工程分册 的"离线需求"路径即可。
Q：代码审查要不要把代码上传到平台？ A：不需要。Agent 通过 Webhook 拉取变更，或私有化部署下直接读内部代码仓库。代码不出网。
Q：我们的 ECU 项目没有结构化追溯 ID，怎么办？ A：走"自动追溯发现"路径，平台做语义追溯并给出置信度评分，由工程师确认。详见 aspice 的场景 B。
版本与支持
- 在线客服：登录后点击右下角客服图标
- 邮箱支持：info@nox-lumen.com
深入了解
- 🎯 案例演示：ASPICE 四场景案例
- 🔌 企业系统对接：DOORS / Gerrit / GitLab 集成
- 💡 平台基座：combo agent 核心概念