竞品功能点数据库：怎么量化 Car Scanner 的字段覆盖度

结论：量化竞品覆盖度不能靠数功能菜单，而要按证据等级分层。Car Scanner 的 APK 2.1.50 快照有 1304 个配置、126217 条 PID 定义，但功能库只确认 226 个功能点（静态 80 / 界面 146）；其中 106198 条定义没有任何公开线索，本地实车能算出值的只有 130 条。定义存在、车辆响应、物理标定，是三件需要分别举证的事。

为什么「数功能菜单」量化不出真实的覆盖度

因为菜单里有这一项，和这一项在你车上能读出正确数值，完全是两回事。竞品拆解最容易犯的错，是把界面截图里出现的条目、或者配置库里存在的定义，直接当成「已经支持」的能力去计数。

一份可核查的功能点数据库应该把每条功能拆成「功能点 → 来源证据 → 验证等级」三段。在这份 Car Scanner（Android 包名 com.ovz.carscanner）的拆解里，功能点总计 226 条，挂接的来源关联 533 条，去重后不同的来源文件 305 个；如果只按 UI 截图计，会漏掉大量只有代码路径、没有界面去向的条目——实测有 94 个功能点没有直接界面产物，其中 76 个本属静态类。

验证等级只有两档，是刻意保守的：static（静态证据）80 条与 ui（界面证据）146 条。它不包含「实车响应验证」这一档，因为实车数据只覆盖极少车型，不足以支撑功能级结论。

226 个功能点拆到模块，才知道竞品把钱花在哪

因为总量相同不代表结构相同。把 226 条按模块归类后可以看到，Car Scanner 的重心明显压在「编码与适配」和「入门与连接」上，而不是实时数据可视化：

这个分布解释了一件事：竞品的护城河不在「能显示几个数字」，而在适配与配置体系的规模。同一目录下的来源台账记录 1004 条来源记录、合计 181,649,025 字节，直接引用表 77 张、引用发生 187,314 次；来源类型里 ui_dump 322 个、binary 410 个、list 236 个、screenshot 33 个、report 3 个。绝大多数证据是二进制产物与界面转储，而不是「一张截图说明一个功能」。

APK 里有 12 万条 PID 定义，但 10.6 万条没有公开线索

因为「配置里写了一条定义」和「有公开证据指向它被真的发出并被响应」是两个数字。APK 2.1.50 快照含 1304 个配置、126217 条车型 PID 定义；面向应用 2.1.0 的更新包（配置版本 2.2.21）为 1323 个配置、127126 条定义。手机端的品牌选择列表有 178 项，但品牌项 ≠ 车型数 ≠ 完整标定数。

把定义按「是否有公开线索」归并后，缺口非常直观：

整体画像见公开证据汇总：候选 PID 文件关联 86810 条、不同公开测试文件 15190 个、不同公开响应案例 89112 个，其中严格匹配的肯定请求案例 84803 个。看起来数字很大，但真正落到「数值等式」的只有 1916 条定义，且其中限定在明确年款内的仅 450 条。也就是说，可算 ≠ 可信。

六道验证门槛：从「有定义」走到「可展示」

因为每一步都可能失真，所以要把「一条 PID 是否可用于产品展示」拆成六个必须逐级通过的关口，任何一级缺失都只能停在候选状态：

三个实车案例说明「有响应」也不等于「标定成立」

因为公开的实车日志往往只证明了链路走通，证明了数值「算得出来」，却缺少独立仪表同步这一环。

斯柯达 Octavia 车主在 WiCAN 议题 771 上传的 Car Scanner 2.1.25 日志里，457 条 Mode 22 请求中有 267 条完整肯定响应、148 条 NRC 0x31、42 条 NO DATA。落到定义层，592 行肯定响应覆盖 117 条定义；其中 DPF 子集的 96 行肯定响应里只有 15 行能按简单公式复算，22114F 的六次烟炱响应原始值为 0861/0862，但静态除数为 0，不能据此显示烟炱克数。这就是第 4 道关口没过。

另一侧，KGM Torres EVX 的日志里 7E0/22FD0D 共 1232 次请求、1230 次完整多帧肯定响应，绝对/相对 SOC 算出 30.0% / 27.8%，补测 57.0% / 56.1%，后者与车主报告的车机 56.1% 一致。数值对上了，但车主车型、显示时点与物理 SOC 未独立核实，重复轮询也不构成独立标定，因此仍只能记为「作者显示值匹配、未标定」。

本地哈弗 H6 混动日志则是国内车型的直接样本：78B/22E0DD → 7CB/62E0DD0000180C 是真实实车响应，但 H6 配置把这条定义为 BMS 上次休眠时长，所以 180C 不能当电池电流；0104 可算出计算负荷约 29.8%，也不能乘额定功率就冒充发动机实际功率。本地日志共涉及 170 条定义，其中 130 条得到肯定响应、全部会话累计 148 条——但那 130 条的状态明确写着「local_positive_response_not_physically_calibrated」，即未物理标定。这一点与站内 OBD-II PID 入门：车速 0x0D 为什么是整数 讲的「样本必须带元数据才能判断可信」是同一条原则。

顺带一个反面样本：2024 Tata Nexon 汽油版车主公布的 19 组 SavvyCAN 请求/响应截图，与当前 APK 的 Tata 配置没有任何一组请求头加命令精确相交。这提醒我们，外部来源的「有响应」不能直接并入竞品覆盖率。

做自己的产品时，这份数据库能直接拿来干什么

因为拆解的价值不在「抄功能」，而在知道哪些结论有证据、哪些只是存在定义。对自研 OBD 仪表而言，这份库能提供三样东西：一是分母（12 万条定义里有多少是真有公开线索的），二是分层口径（六道关口），三是不可迁移清单——共享同一配置的车型（如 Hyundai / Kia / Genesis，或 SsangYong）不会因为其中一个车型验证过就跟着升级验证等级；跨年款的作者报告也不能扩展配置的实车验证范围。

目前公开库索引的 178 个品牌里，仍有 40 个品牌处于无 PID 索引来源候选状态。这意味着行业里「某车型能读某字段」的说法，大多停留在单一作者报告，缺少可复现的原始帧。如果你打算对外宣称字段覆盖度，分母口径必须比竞品更保守，否则迟早被实车打脸。自研数据链路的设计思路，另见 OBD AI 插件化平台：端侧解析为什么必须插件化 与 EdgeForge：嵌入式侧端框架的自编译方案；采集侧硬件可参考 SR-RaceBox 车载数据采集器。竞品的市场定价与形态对照，见同批发布的 仪表市场对照：ScanGauge / Beeline / CHIGEE / Wahoo / Karoo。

常见问题

Car Scanner 到底支持多少车型，126217 条定义算多吗？

126217 是 APK 2.1.50 快照里的车型 PID 定义条数，不是车型数、更不是已标定字段数。它分布在 1304 个配置里，其中 106198 条没有任何公开 PID 线索。判断「算不算多」要看有效分母——真正有公开数值等式对照的只有 1916 条定义。

界面里能看到的功能，能直接算作已支持吗？

不能。226 个功能点里 146 条只有界面证据、80 条只有静态证据，两者都不等于实车可用。94 个功能点连直接界面产物都没有。要判断可用性必须看链路是否有实车响应，以及是否完成物理标定。

为什么公开的实车日志很多，却仍说「未标定」？

因为实车日志通常只证明请求发出、ECU 响应和公式算得出值这三步。真正的标定需要不同工况下与同步仪表或独立测量比对。多数公开案例只有单一车主的显示值，且车型年款、电池版本或显示时点未核实，重复轮询同一命令也不构成独立采样。

共享同一配置的其他品牌车型，可以跟着算验证过吗？

不可以。拆解文档对每一个案例都单独声明了适用范围，例如共享配置的 Kia / Genesis / SsangYong 不因某一款车验证而升级；跨年款的作者报告（如把 2021 款结论套到 2016–2019 配置）也不被接受。协议可迁移的假设必须由目标车自己的原始帧来支撑。

本文数据来自星核火花赛车科技内部「Car Scanner 功能点数据库」拆解项目（对象为 Android 包名 com.ovz.carscanner，索引更新至 2026-10-05），全部数字以该目录现有索引为准，属某一版本快照，不代表软件当前最新版本。文中所有公开案例均标注为「候选 / 未物理标定」，仅代表作者报告与算术对照，不构成 Car Scanner 或任何车辆的实测标定结论；共享配置的关联品牌与跨年款报告未纳入验证范围。篇幅所限未逐一列出案例来源文件名，完整引用见该目录下的《拆解总览》《数据脉络与软件架构》与 public_pid_research/ 台账。