结论：端侧解析必须插件化，因为车辆私有协议、界面布局与派生算法都属于高频变化项，用整机固件去覆盖它们，等于每改一条规则就要重编译、重烧录一次主机。可行做法是把变化频率不同的职责拆成五层，让协议包、规则包、界面包独立签名发布，固件只保留低频 OTA 通道。但插件不等于万能：数据若不经过 OBD 网关，装什么插件都读不到，这一点必须在上架前就声明清楚。
为什么「整机重编译」模式撑不住车型差异
因为一旦把应用逻辑编译进固件，任何一个信号解码的改动都会变成一次固件发布，而品牌、年款、地区、动力类型与 ECU 软件版本的差异是持续出现的。
源方案书把「哪些能力可以动态升级」逐项列了出来，判断依据不是功能大小，而是宿主是否已提供对应的底层原语：
| 改动类型 | 能否通过插件完成 | 必要条件 |
|---|---|---|
| 新页面、布局、颜色、单位、辅助阈值提醒 | 通常可以 | 使用宿主提供的界面组件和信号 |
| 新衍生指标、过滤、统计、异常检测 | 通常可以 | 算力、内存、数据源与准确性满足要求 |
| 新 PID / DID 的解码定义 | 有条件可以 | 传输方式已支持，来源合法，请求模板经验证 |
| 新诊断传输、加密接入、复杂状态机 | 可能需要固件升级 | 宿主缺少相应底层原语或安全接口 |
| 新 CAN 控制器、引脚、显示驱动 | 通常需要固件及可能的硬件改动 | 插件不能补齐缺失的电气接口 |
| ECU 写入、制动或动力控制 | 不在本方案插件权限内 | 不通过普通用户插件开放 |
这里必须纠正一个常见误解：插件化不等于「未知车型插上就能自动破解全部协议」。未知数据可能根本不经过 OBD 接口，可能受安全网关限制，也可能没有合法可用的定义；硬件能力、驱动、运行时漏洞和新宿主接口仍然可能需要固件升级。所以方案书给出的正确承诺是「多数应用功能无需重编译整机固件」，而不是「以后永远不更新底层软件」。
插件化把职责拆成五层，各自按不同频率更新
因为不同职责的变化频率相差几个数量级，把它们绑在同一次发布里才是问题的根源。方案按更新频率重新切分，低频层保留固件通道，高频层走签名包：
| 层次 | 长期职责 | 主要更新方式 |
|---|---|---|
| 硬件与稳定底座 | 电源保护、CAN 驱动、诊断调度、看门狗、安全存储、升级恢复 | 低频固件 OTA；硬件变更仍需重新设计 |
| 协议与数据层 | 标准 OBD、经过验证的私有信号定义、单位与数据质量 | 签名协议包；超出解释器能力时更新固件 |
| 功能插件层 | 计算指标、辅助提醒、记录策略、仪表布局 | 声明式规则为主，按平台增加 Lua 或 Wasm |
| AI 与交互层 | 理解需求、组合已知能力、生成候选插件、解释限制 | 手机、Linux 或云端模型服务；可独立升级 |
| 治理与分发层 | 协议权利来源、验证证据、发布签名、授权、灰度、撤回 | 手机应用与可选服务平台 |
首个产品的建议形态是「ESP32-S3 仪表 + 手机伴侣应用 + 声明式插件运行时」：仪表负责稳定采集与执行，手机负责自然语言交互、插件编辑、验证编排和分发；联网时可选云端 AI，离线时仍可执行已安装插件和手工创建规则。首期交付限定为：标准 OBD 数据、少量授权车型协议包、用户自定义页面、基于已知信号的规则提醒、插件签名与权限检查、故障回退与基础固件 OTA。首期暂缓包括任意 C/C++ 动态代码、行驶中主动探测未知诊断服务、由模型直接发送 CAN 帧、刷写 ECU、清故障码与执行器测试。
六个核心模块，以及它们明确不授予的能力
因为安全边界不能只在文档里写「不开放」，而要在模块职责上就切掉能力。方案把整机拆成六个模块，每个模块都写明它不拥有什么：
| 模块 | 负责内容 | 不授予的能力 |
|---|---|---|
| Vehicle Gateway | CAN 收发、ISO-TP、标准 OBD、经批准的诊断读取、请求预算 | 不接受插件直接传入任意 CAN 帧 |
| Signal Service | 标准名称、单位、时间戳、来源、质量、订阅与缓存 | 不把缺失或超时值伪装为零 |
| Plugin Runtime | 规则执行、状态隔离、超时控制、受限算法 | 不直接访问驱动、密钥、任意地址 |
| Plugin Manager | 校验、依赖解析、兼容性、原子激活、回退、卸载 | 不接受无来源认证的安装包 |
| AI Orchestrator | 需求转配置、引用协议资料、候选实现和测试 | 不修改策略、签名根或自行授予权限 |
| Release Service | 审核、签名、车型发布、灰度与撤回 | 不把模型输出直接当作可信版本 |
配套的稳定信号接口规定：每个信号至少携带 signal_id、数值、单位、来源 ECU / 协议包、采集时间、单调时钟时间、有效期、质量状态与错误原因；质量至少区分 valid、stale、unavailable、error，分析候选数据另标 experimental。标准信号与厂商信号使用不同命名空间，例如 obd.engine_rpm 与 vendor.example.transmission_oil_temp，避免同名不同义。这与站内 OBD-II PID 入门：车速 0x0D 为什么是整数 里讲的「样本必须带元数据才能判断可信」是同一套约束。
为什么「只读」业务仍然会向车辆发送报文
因为被动监听在 OBD 接口上通常只能看到很少数据，要拿到标准 PID 就必须主动发请求，而请求本身会占用总线并消耗 ECU 的处理时间。
产品标称「只读」意味着不允许状态改变类业务，不意味着物理上不发送 CAN 帧。因此宿主必须统一执行请求合并、每 ECU 并发限制、重试上限、总线与响应时间监测和休眠控制。方案特别提醒：总线平均占用率低并不代表 ECU 负载安全，所以「请求预算必须经过具体车型验证，不能用一个全车型统一比例作为安全证明」。遇到超时、bus-off、异常响应、供电下降或诊断冲突迹象时，应停止新增请求并退避；外部诊断仪并不总能被可靠识别，产品还需要提供明确的维修停用模式。
不是所有缺失数据都能靠插件补上
因为「没有数据」有多种成因，只有其中一部分属于插件的能力范围。方案把成因和对应限制列成一张表，避免把工程限制伪装成产品能力：
| 情况 | 可采用的方法 | 必须呈现的限制 |
|---|---|---|
| 标准 OBD 已定义且车辆支持 | 查询受支持项，按标准解析 | 支持情况与刷新频率因车辆而异 |
| 已有合法厂商定义 | 整理为协议包，测试车型与 ECU 版本 | 协议适用范围和权利范围受限 |
| 数据可从已知信号推算 | 提供估计值与适用条件 | 明确标注估计，不能冒充传感器实测 |
| 仅有可访问的未知报文 | 授权记录、离线分析、对照验证 | 相关性不代表信号含义被证实 |
| 数据不经过 OBD 网关 | 获取正式接口、授权网关支持或专用硬件 | 单靠插件无法创造物理访问路径 |
| 需要安全网关或受保护会话 | 走厂商允许的接入机制 | 用户同意不等于获得解锁或绕过权限 |
此外，方案区分了三种彼此独立的「同意」：安装功能的同意、访问车辆的授权、以及协议与数据权利（协议资料的使用与再分发权，采样、上传、保留与训练数据的许可）。车主允许安装，不自动覆盖厂商协议权利，也不自动允许绕过安全网关。
插件靠什么被约束住：宿主管线、资源预算与权限交集
因为仅靠签名无法限制插件行为，所以约束分三层落地：清单声明、宿主独立拒绝、资源配额。方案给出的清单数据契约里，一条冷却液提醒插件声明 state_bytes: 16384、max_rule_nodes: 64、max_eval_ops: 256、min_interval_ms: 1000；宿主实际授权取「用户批准、发布者权限上限、设备策略、车型能力、清单请求」的交集，清单里的 false 或上限声明不是自我证明，宿主必须独立拒绝所有未开放操作。
ESP32-S3 档的资源起始预算写得很克制，且被明确标注为实验上限候选值，必须结合显示、无线、TLS、CAN 与 OTA 同时运行的峰值收紧或调整：同时启用 3–5 个简单插件；单个规则包不超过 128 KB；每个插件的规则状态先限制为 16–64 KB；所有插件计算占用总 CPU 的预算先设为不超过 10%。界面侧建议 UI 数据刷新目标先按 5–10 Hz 设计、慢变化的温度信号按约 1 Hz 评估，但实际请求频率受车型能力限制，不能机械套用。
验收门槛同样给了可核查的数字：安装、试运行、激活和迁移阶段注入断电，首轮累计至少覆盖 100 次故障注入，量产前扩展为自动化长期测试；并完成至少 72 小时组合功能稳定性测试。该测试不替代量产寿命试验。分阶段计划按约 5 人核心团队估算，总历时约 16–20 周达到受控试点；核心投入约 80–100 人周（约 18.5–23 人月），按每人月 3–6 万元全成本假设粗算，核心研发人力约 56–138 万元——方案书注明这是预算模型示例，不是报价，且不含硬件试制、协议许可、认证与云服务。
四档硬件参考配置从 ESP32-S3（双核最高 240 MHz、片内 SRAM 512 KB，建议选配 16 MB Flash 与 8 MB PSRAM）一路延伸到手机级（建议 8–16 GB RAM、64 GB 以上存储）。方案强调「中高性能 MCU」不是单纯比主频更高，而应比较片内可用 RAM、MPU、CAN FD、缓存与 DMA 限制、图形加速和实时性；外部 RAM 也不自动等价于实时任务可用的片内 RAM。采集侧若需要对照方案，可参考 SR-RaceBox 车载数据采集器；数据回传与云端分析可对照 SR-Telemetry 实时遥测云。计时链路本身为什么不能用 GPS 替代 OBD 车速，另见 OBD 零百加速计时：为什么手机测不准，仪表该怎么算。
常见问题
「AI 插件化」是不是意味着未知车型插上就能自动破解？
不是。方案明确不宜承诺「未知车型插上即自动破解全部协议」。未知数据可能不经过 OBD 接口、可能受安全网关限制，也可能没有合法可用的定义；插件无法创造物理访问路径，缺失时必须明确提示不可用，或走经授权的适配申请。
插件能升级到什么程度，哪些还必须刷固件？
页面、布局、单位、阈值提醒、衍生指标、窗口统计和经过验证的 PID / DID 解码通常可以通过插件完成；而新诊断传输、加密接入、复杂状态机、新 CAN 控制器 / 显示驱动、驱动与内核漏洞修复，通常需要固件升级。因此平台必须长期保留固件 OTA 通道。
为什么标称「只读」的仪表还会向车辆发报文？
因为被动监听拿到的数据很少，读取标准 PID 必须主动发请求。标称「只读」指的是不允许状态改变类业务，不代表物理上不发送 CAN 帧。请求需经宿主统一调度，且请求预算必须按具体车型验证。
AI 在平台里能决定什么，不能决定什么？
AI 可以做需求理解、生成结构化候选规则、解释数据为何不可用、生成边界测试；但不能决定车辆请求白名单、信任根、权限上限、密钥使用和协议量产签名。AI 的输出必须经过独立确定性校验器，不能靠另一个模型说一句「安全」就通过。
本文数据来自星核火花赛车科技内部 OBD 仪表 AI 插件化平台方案的 V1.0 稿（2026-09-13，架构规划与立项评审状态）。文中的内存、Flash、CPU 占用、插件数量与界面刷新频率均为方案给出的选型建议或实验上限候选值，不代表已完成样机验证；约定「首期暂缓」的能力不在本方案插件权限内。分阶段历时、人力与费用口径为题述假设下的预算模型示例，不是报价，也不构成任何交付承诺。