汽车专属 Skill：把 V 字两侧的机械活全包了

ASPICE 4.0 要求 SYS.1 ↔ SWE.6 双向追溯，现实中工程团队大量时间花在"对格式、对编号、对覆盖率"。这一篇拆开 Nox-Lumen Auto 应用层的几个汽车专属 Skill，看它们具体在做哪些活。

三件套总览

Skill	主要工作	核心输出
automotive-process-analyzer	V 字两侧的体检	断链清单 + 覆盖率分布 + 下一步建议
canoe-test-automation	测试脚本生成 + 执行	CAPL / M-Script / Python 脚本 + HIL 调度
standards-converter	多标准互转	ARXML ↔ DBC ↔ A2L ↔ LDF 双向 + 一致性校验

下面拆开看每一件。

automotive-process-analyzer

输入

需求文档（DOORS / Polarion / Jama / Jira / 飞书项目 / ReqIF 文本）
架构 / 详细设计文档（Word / Markdown / 飞书）
测试用例库（Excel / Polarion / vTESTstudio）
ALM 导出的链接关系

输出

输出物	说明
断链清单	哪条需求没有对应的设计 / 代码 / 测试
覆盖率分布	按需求类型 / 子系统 / ASIL 维度统计
建议下一步	缺哪条 trace、要不要补哪个测试、优先级 P0/P1/P2

支持的追溯语义

语义	含义	使用场景
`:satisfies:`	A 需求满足 B 需求	Stakeholder → Feature → System → Component
`:fulfils:`	架构 / 实现履行需求	Component Req → Architecture / Code
`# req-Id:`	源码注释绑定需求	Implementation → Requirement
`fully_verifies:` / `partially_verifies:`	测试完全 / 部分验证某需求	Test → Requirement
CAN 信号绑定	集成测试 → DBC 报文	信号一致性追溯

操作命令样例

把 ABZ-Lightcontrol 的所有文档入库，按 Stakeholder → Feature → 
Component 的顺序建立追溯链，输出追溯矩阵并高亮断链。

对历史项目 X11 做语义追溯发现（没有结构化 ID），输出候选链接清单
和置信度评分。

需求-设计-代码-测试断链定位

canoe-test-automation

输入

需求 ID + 信号定义 + 期望响应（结构化或自由文本）
DBC / ARXML 引用（用于信号名校验）
期望测试台架（CANoe / dSPACE / NI / ETAS）

输出

输出物	说明
CAPL / M-Script / Python 脚本	按需求 ID 命名，注释里写源需求 / 信号 / 期望 / 超时
测试执行调度	HIL / CANoe 环境上跑、回放结果
覆盖率反哺	哪条需求的 MC/DC 还差什么

多台架兼容

同一份需求，一次点击同时产出：

CANoe CAPL —— Vector 主线
dSPACE M-Script —— ControlDesk / AutomationDesk
NI TestStand Sequence —— LabVIEW / VeriStand 工程
Python with iTestStudio —— 自研框架

按实验室既有设备分派执行。

FMEA 故障注入

不是只生成"正常路径"，而是按 FMEA 模式自动派生：

故障类型	注入策略
信号丢失	模拟节点断连 / Bus-Off
值域越界	物理量超过 min / max
时序错乱	周期抖动 / 突发 / 乱序
报文劫持	第三方节点伪造 ID
诊断异常	DTC 触发 / 清除时序

结果回流与缺陷归档

日志解析：CANoe .blf / dSPACE .mat / NI .tdms 原生数据
失败分类：按功能 / 通信 / 诊断 / 性能自动分类
缺陷单自动回填：通过 bug-import 写入 Jira / Polarion / Redmine，附执行日志 + 失败现场快照
历史对照：失败用例对照 LTM 中的历史 Bug 模式，给出疑似根因提示

从需求到 CAPL 脚本派生

standards-converter

汽车工程里的"格式税"：

AUTOSAR ARXML（4.x 多版本：4.2 / 4.3 / 4.4 / 4.5 / R20-11 / R21-11 / R22-11）
CAN 总线 DBC（Vector 格式 + 早期 dSPACE 格式）
标定 A2L（ASAM MCD-2 MC）
LDF（LIN 描述）
FIBEX（AUTOSAR / FlexRay）

支持的转换矩阵

源 → 目标	用法
ARXML → DBC	拿一份 ARXML 网络模型生成 CAN 报文清单
DBC → ARXML	老项目的 DBC 升级到 AUTOSAR 网络栈
A2L ↔ ARXML	标定参数与软件组件接口的一致性维护
LDF → ARXML	LIN 网络迁移到 AUTOSAR LIN Slave
ARXML 升版	4.2 → 4.5 / R22-11 自动迁移

一致性校验

任何两个格式之间转换后自动校验：

信号名一致性：DBC 里的 EngSpd 和 ARXML 里的 Eng_Speed 是不是同一个？
物理值映射：min/max/offset/factor 是否对齐
报文周期：DBC 周期与 ARXML Timing 是否一致
报文 ID 冲突：转换后 ID 不重复

不再有"工程师手动开 Excel 比 DBC 和 ARXML 的信号名字" 这种活。

操作命令样例

把 v3.2 的 ARXML 升到 R22-11，列出有断章风险的部分，
对所有信号做与现有 DBC 的一致性校验。

三件一起怎么用

Rendering diagram…

三个 Skill 是封装在 Nox-Lumen Auto 应用层的——平台层（combo agent）的多 Agent 编排、上下文管理、Memory 是通用能力，应用层只装"汽车工程师每天会用到的工具盒"。

与 ALM 工具链的接入

DOORS / Polarion / Jama / Jira / 飞书项目都有适配器，不要求客户换工具——Agent 在客户现有的 ALM 边上工作，不替代它。

工具	接入方式	双向同步
IBM DOORS Next	REST API + OSLC	✓
Siemens Polarion	REST API + WSDL	✓
Jama Connect	REST API	✓
Atlassian Jira	REST API + ScriptRunner	✓
飞书项目	OpenAPI	✓
自研 ALM	适配器开发	按需

详见 ALM 平台对接。

客户常问

Q：我们是 dSPACE 主线，CANoe 用得少，三件套对我们有用吗？ A：有。canoe-test-automation 名字带 CANoe，但实际同时产出 dSPACE M-Script / NI TestStand Sequence / 自研框架脚本。只要你的台架日志能解析（.mat / .tdms / .csv），结果回流也走得通。

Q：我们规则集是 MISRA C:2012 + 客户内部规范，能加进 Agent 吗？ A：能。客户内部编码规范录入 KB，L2 语义评审时自动检索对照。详见 AI 代码审查。

Q：必须开重索引才能用吗？ A：不必须。日常 PR 审用轻索引（默认），秒级响应。只在做"改这一行影响 ASIL-D 模块哪些下游"这种深度问题时才需要开重索引。详见代码索引三档。

Q：能不能完全本地化部署？ A：能。L1 静态分析可完全本地化（不出数据），L2 走客户内网 LLM endpoint。私有化部署细节联系 info@nox-lumen.com。

完整 Skill 列表与命令签名见 docs/skills/industry/automotive，方案能力清单看 solutions/automotive。