星核火花赛车科技

标签： 研究项目

  • EdgeDeploy：BLE 与 USB 两条通道怎么把签名包送到 ESP32-S3

    很多 MCU 升级方案把「签名校验」当作终点，实际上它只是中间检查点。真正难的是链路：BLE 有 MTU 限制、USB 会掉线、UART 会丢字节。EdgeDeploy 就是把「包可信」与「包能完整到达」拆成两件事分别解决的那一层。

    三条链路，同一套帧语义

    EdgeDeploy v1 的协议语义与承载链路解耦：无论走 UART、原生 USB 还是 BLE，都使用固定帧头、CRC32、传输 ID、分片 ACK、丢包重试、断点续传、接收端重启恢复、提交结果重放和整包 SHA-256。差别只在分片大小与传输载体：BLE 通道把 512 字节的 EdgeDeploy DATA 拆成 128 字节的 GATT 写片，靠通知流重组、超时、取消与重试补齐。

    链路 分片与载体 已完成的软件/实板验证 仍未验证
    原生 USB 序列包分帧，独立流解码器 + 共享加锁接收器 COM6 从 3,504 字节断点续传并成功 COMMIT；序列 4 包七帧 DATA 完整安装；B 槽 Flash 回读 SHA-256 与发送包一致 掉电恢复、目视显示确认
    BLE（GATT） 512 字节 DATA → 128 字节写片；固定 128 位服务/Request/Response UUID ESP32-S3 加密写入/通知服务、NimBLE Host 复用、浏览器闭环 16/16 场景通过 真实射频与配对不在任务验收内
    UART 按传输 ID 分片 ACK 与重传 框架测试覆盖；外接 UART 实传仍待验证 外接 UART 实传、掉电恢复
    Android APK 系统配对 + 签名 EFP 文件选择 + 分片/重试/断点/提交 + 进度界面 ARM64 构建、3 项协议测试、Lint 0 错误；APK 2,987,883 字节 真机配对、安装、重启健康确认、断线恢复与后台行为

    断点续传和提交结果重放解决的是两个不同的失败

    断点续传解决「写到一半断了」：传输 ID 与序号让接收端知道已经收了多少，重连后从偏移继续，而不是从 0 重来。提交结果重放解决「提交后不知道成功没有」：接收端重启后能回答上一次 COMMIT 的结果，避免主机重复提交或误判失败。

    这两条都服务于同一个下游动作——只有当整包 SHA-256 与签名校验通过，C99 接收器才把完整 EFP 交给 A/B 包管理器，随后才是暂存、试运行、原子激活与 5 秒健康窗口确认。也就是说，传输层只保证「完整送到」，是否运行仍由 96 字节事务状态记录与三态机制决定。

    现在已经验证到什么程度

    微雪 ESP32-S3-Touch-AMOLED-1.75 是目前走得最远的实板：EF-106 记录它已从 ota_1 启动并保留 ota_0 原应用与完整 Flash 备份；EF-106D 的串口观察显示 COM6 复位后 7 个信号、2 条管线、4 个组件就绪，65 秒无复位，UI 任务最低剩余栈 7,576 字节。框架侧自动测试当前共 46 项，本机 44 项通过，另 2 项 Linux POSIX 与 SocketCAN vcan0 集成测试在非 Linux 主机按条件跳过。

    需要说清楚的边界是：以上都是串口可见的软件行为，不等于整机通过。屏幕像素、手指触摸、外部传感器、掉电与长期运行尚未验收；Wasm 后端属于 P3 计划，尚未完成。把「编译通过」或「COM 口有输出」说成「产品可用」，是这类端侧项目最常见的自我误导。

    这对赛道数据链路意味着什么

    赛道日的现实是：设备已经在车上、线束已经走好，此时才发现某个信号解析有误，可用的补救窗口只有几十分钟。因此部署通道的价值不在「无线很方便」，而在可断点、可校验、可回退——包传一半断连不必重来，装上去不健康能在 5 秒内自动回到旧槽。

    这与车载采集和复盘环节的诉求是一致的：SR-RaceBox 车载数据采集器 负责把姿态与位置数据完整落盘，SR-Data 圈速分析器 负责事后复盘，任何一次「改完就回不去」的更新都会让整段数据失去连续性。对 Toyota GR86 这类以 OBD 车速作为计时输入的场景尤其明显——计时口径一旦在更新中改变，同一条赛道（例如 宁波国际赛车场）的历史圈速就无法再横向比较。

    FAQ

    EdgeDeploy 和 OTA 是一回事吗？

    不是。OTA 通常指整份固件的无线替换；EdgeDeploy 传的是签名的功能包 EFP，落地后要经 A/B 包管理器暂存、试运行与原子激活，且传输层自带断点续传与提交结果重放。

    BLE 传固件为什么一定要拆成 128 字节？

    因为 GATT 写片受 MTU 限制。EdgeDeploy 把 512 字节 DATA 拆成 128 字节写片，配合通知流重组与重传，才能在受限链路上保证完整性。

    断点续传后还需要重新验签吗？

    需要。整包 SHA-256 与 Ed25519 验签在接收端完成后才交给包管理器，续传只解决字节完整性，不替代来源校验。

    现在能说 EdgeDeploy 已经量产可用吗？

    不能。外接 UART 实传、掉电恢复、Android 真机配对与长期运行仍未验证，Wasm 后端属 P3 未完成项。

    参考资料

    • 项目 05 —— D:/Backup/Documents/开发板侧端模型/EdgeForge自编译软件框架方案.md（V1.4，平台层五类接口、EdgeDeploy v1、MVU 与 P3 路线）
    • 项目 05 —— D:/Backup/Documents/开发板侧端模型/DEVELOPMENT_TASKS.md（EF-105 / EF-105A / EF-105C / EF-106 / EF-106D / EF-114A 状态）

    更新记录

    首次发布 2026-10-11 最近核对：2026-10-11

  • 赛道日数据复盘：用 42 条赛道分段定位每一秒失分

    先说明数据来源：本篇所属的赛道工程实验数据项目（nixiang-tracklab）存放在 NAS，当前因缺少 SMB 凭据而不可达，本次没有任何来自该项目的输入。以下内容基于站点既有的赛道档案与产品能力写成，属于通用复盘方法，不含该项目的实验结论。

    结论先行：复盘的产出不是「我今天快了多少」，而是「我在第几段慢了、为什么慢、下一步先改什么」。这三问必须按顺序回答，跳过前面直接改硬件，是最常见的浪费。

    第一步：先有分段，再谈圈速

    没有分段的圈速只是一个数字。SR-Track 中国赛道数据包当前收录 42 条赛道，提供赛道中心线、自动分段、按车型规格分组的参考圈速、关键超车点与刹车点标注、地形剖面与高差数据；赛道改版后 7 个工作日内更新，历史版本保留 12 个月。

    赛道 全长 弯数 官方单圈（登记值）
    宁波国际赛车场 4.014 km 12 1:38.5（GT3，2024）
    鄂尔多斯国际赛车场 4.005 km 19 1:39.0（GT3，2024）
    天津滨海国际赛车场 3.594 km 18 1:42.3（GT3，2024）
    上海国际赛车场 5.451 km 16 1:31.4（GT3，2024）

    弯数越多，分段对比的价值越大。鄂尔多斯国际赛车场 有 19 个弯，是练习分段拆解的理想场地；宁波国际赛车场 弯型组合紧凑，适合建立连续节奏并做分段对比。

    第二步：定位最大失分路段

    把每一段的最快值与本次值做差，取绝对值最大的那一段。这一步要刻意忽略总圈速——总圈速的改善是结果，不是抓手。SR-Data 圈速分析套件会自动完成逐段对比并标出最大失分路段。

    需要注意的是，参考圈速按车型规格分组。用 GT3 规格的参考值去比一台原厂车，得到的差值没有意义；正确做法是同车型规格、同场地条件下的纵向对比，或者与自己本场的最快圈做横向对比。

    第三步：判断成因，而不是猜成因

    失分通常来自三类：刹车点过早或过晚、出弯油门开度不足、走线偏差。三者在数据上的表现不同，可以区分：

    成因 数据表现 判读方法
    刹车点问题 入弯前速度曲线提前下降 刹车点反推与理论最优值比较
    出弯牵引不足 出弯段油门开度滞后或波动 油门开度图识别隐形损失
    走线偏差 分段速度整体偏低且稳定 走线偏差计算
    轮胎状态 同一段随时间单调变慢 胎温、胎压与磨损趋势追踪

    SR-Data v2.4.0 重写了刹车点反推算法，精度提升约 0.05 秒；v2.4.1 新增胎温趋势热力图。0.05 秒这个量级未必直接改变你的驾驶，但它决定了「这一段到底差多少」这个判断是否可信。

    第四步：按车型特性排优先级

    同样的失分，在不同车型上的改进顺序不同。以 Nissan GT-R (R35) 为例，它的全时四驱会掩盖走线问题——驾驶员不容易察觉出弯牵引与走线的缺陷，因此第一步永远是建立客观数据基线，而不是先改 ECU、排气或避震。四驱让车「感觉很快」，但分段数据通常不这么认为。

    相反，轻量后驱车的失分更多出现在出弯阶段，此时轮胎与避震的收益远高于动力。判断依据是分段差值集中在哪一类路段：集中在低速弯多半是机械抓地问题，集中在长直道末端才是动力问题。

    采集端要保证数据完整。SR-RaceBox 车载数据采集器 以 IMU 50 Hz、GPS 20 Hz 同步记录，宽压 CAN 覆盖 12V–36V，掉电保护保证异常断电不丢已记录段，本地 SD 与实时上传双通道并存。分析在 SR-Data 圈速分析套件 中离线完成，数据不出本地。

    复盘流程

    1. 确认赛道分段与同规格参考圈速（赛道改版后需重新核对版本）
    2. 导入本场全部圈速，剔除无效圈（出站圈、被阻挡圈、黄旗圈）
    3. 逐段对比，定位绝对值最大的失分路段
    4. 用刹车点反推与油门开度图判断该段成因
    5. 按车型特性排改进优先级，一次只改一个变量
    6. 下一场用同样的分段重新采集，验证改动是否生效

    第 5 步最容易被忽略。一次改三个变量，得到的数据无法归因，等于这一场白跑。

    FAQ

    没有参考圈速就不能复盘吗？

    可以复盘，只是基准不同。可以先与自己本场的最快圈做横向对比，同车型同条件下的纵向对比也有价值。

    50 Hz 采样够用吗？

    够做刹车点与走线分析。SR-RaceBox 采用 IMU 50 Hz、GPS 20 Hz 同步记录；采样率需求随分析精度提高而提高。

    为什么四驱车更依赖数据？

    因为四驱会掩盖走线问题。GT-R R35 的改装建议第一条就是「先做数据记录」，否则后续改装容易变成盲目投入。

    一次能改几个变量？

    一个。多变量同时改动会导致数据无法归因，无法判断哪项改动真正生效。

    参考资料

    • 站点赛道档案 —— https://sracing.cn/wp/wp-json/wp/v2/track（2026-10-11 实测，8 条赛道）
    • 站点产品档案 —— SR-Data 圈速分析套件 v2.4.1、SR-RaceBox 车载数据采集器 v3.1.2、SR-Track 中国赛道数据包 2026.10
    • 说明 —— 项目 03 nixiang-tracklab（\192.168.31.115团队文件-星核公司数据库公共中转站nixiang-tracklab）本次不可达，无输入

    更新记录

    首次发布 2026-10-11 最近核对：2026-10-11

  • 52 张预览自动校验：五屏 HUD 怎么把「文字出界」变成一条断言

    结论：当原型扩展到 5 块屏 × 5 套主题 × 全部副视图之后，人工目检一定会漏。capture.mjs 用 Playwright 遍历这个矩阵、输出 52 张预览，并把六类检查写成断言——其中最关键的一条是：用 getBBox() 逐项检测每个 <text> 是否越出画布，把「文字出界」从肉眼问题变成可回归的失败。

    为什么人工目检在 5×5 矩阵下必然漏

    5 块屏乘以 5 套主题，再乘上每块屏的副视图，需要核对的画面数量在几十到上百量级。人工看图的失效方式很规律：前十几张会认真比对，之后注意力衰减，最后只看「有没有明显崩掉」。而越界的文字往往只差几个像素——恰恰是最不容易被肉眼抓住的那类问题。

    更麻烦的是回归：一旦改了某个令牌或布局推导规则，理论上所有尺寸都要重看一遍。人工流程做不到这一点，于是问题会以「上个版本还好好的」的形式在下游暴露。

    遍历矩阵与产出

    脚本按「屏幕 × 主题 × 副视图」三重循环遍历，每张画面截图输出到 previews/，同时执行断言。最终产物是 52 张预览加一份断言结果——前者用于人工确认视觉意图，后者用于机器判定是否回归。

    运行方式上有一个实际操作细节：node 不在系统 PATH 上，必须用完整路径调用，因此脚本入口固定写明了解释器路径，避免在不同机器上以不同的 Node 版本跑出不同结果。

    六类自动断言

    断言 检查什么 为什么重要
    viewBox 原生像素 SVG viewBox 是否等于各板原生分辨率 防止某个尺寸悄悄套用了别的画布
    文字越界 所有 <text> 的 getBBox() 是否超出画布 最容易被肉眼漏掉、也最影响可读性
    undefined 泄漏 SVG 内容中是否出现字符串 undefined 数据绑定失败的典型症状
    默认主题 默认主题是否为 pro、主题切换是否生效 防止切换逻辑静默失效
    状态推进 OBD 回放推进、计时完成、断连状态、路书翻页 验证交互状态机而非静态版式
    移动端溢出 移动端是否出现横向溢出 预览页本身的可用性

    getBBox 为什么是关键一条

    浏览器渲染文本时，元素的实际包围盒由字体度量决定，而不是由设计稿里的数字决定。所以「设计上放得下」和「渲染后放得下」是两件事。getBBox() 返回的是渲染后的真实尺寸，用它逐项比对画布边界，才能把这类问题从主观判断变成布尔结果。

    这条断言的直接收益是：改了字号、字距或字体之后，脚本会立刻告诉你哪些画面出界，而不需要人再逐张看。它同时也解释了为什么「换字体」必须重跑校验——字体一换，字宽就变，原本贴边的文本可能立刻越界。

    字体是隐性风险

    原型使用的是系统字体（Bahnschrift / Microsoft YaHei / Impact / Georgia / Consolas）。这些字体在桌面浏览器上可用，但不一定允许嵌入式再分发。因此固件移植前必须重新选定字体，并重跑一次越界检测。

    这类风险的特点是「在原型的阶段看不出来，在移植阶段集中爆发」。把它写进校验清单，而不是留到移植时才发现，是这套流程设计上比较值的一点。

    自动校验证明不了什么

    边界必须写清楚。这套校验只覆盖原型层的布局与状态逻辑，不证明：ESP-IDF/LVGL 的点屏、SPI/DSI 实际帧率、实车 PID 支持，以及计时精度。所有画面数值均为模拟数据并永久标注 DEMO，档位与油压尚无车型适配，实机须接入受保护的 OBD 网关。

    另外两项待实机确认的项：3.5 寸现有固件 DEMO 已采用横屏坐标，但尚未移植这套 UI；1.64 寸的横屏旋转与触摸映射仍待实机验证。浏览器里的通过，不等于屏幕上的通过。

    实测之后的链路可以这样分工：赛道上的实时状态由 SR-Telemetry 实时遥测云 以低于 500 ms 的延迟推给场边教练；像 肇庆国际赛车场 这类高差明显的场地，更适合用来验证坡度相关信息的显示优先级。

    FAQ

    为什么不能靠设计师人工看预览图？

    因为 5 块屏 × 5 套主题 × 副视图是上百量级的画面，人工注意力会衰减，而文字越界往往只差几个像素。改一次规则就要全部重看，人工流程无法回归。

    getBBox 检测的是什么？

    检测渲染后的真实文本包围盒。字体度量与实际渲染尺寸只有在浏览器里才能确定，所以「设计上放得下」不等于「渲染后放得下」。

    为什么换字体要重跑校验？

    因为字宽会变。原本贴边的文本在换字体后可能立刻越界，必须重跑一次越界检测。

    自动校验通过了能直接上实机吗？

    不能。它只覆盖原型层的布局与状态逻辑，不证明 ESP-IDF/LVGL 点屏、SPI/DSI 帧率、实车 PID 支持与计时精度；1.64 的横屏旋转与触摸映射也仍需实机验证。

    参考资料

    • 项目 06 —— D:/AI/PROJECTS/kno/capture.mjs（Playwright 自动校验脚本）、previews/（52 张预览）
    • 项目 06 —— D:/AI/PROJECTS/kno/README.md（校验清单与已知限制）
    • 项目 04 —— research/instrument-matrix.md（风格覆盖规则与 52 张预览口径）

    更新记录

    首次发布 2026-10-11 最近核对：2026-10-11

    {“@context”:”https://schema.org”,”@graph”:[{“@type”:”FAQPage”,”mainEntity”:[{“@type”:”Question”,”name”:”为什么 HMI 原型不能靠设计师人工看预览图？”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”因为 5 块屏乘以 5 套主题再加副视图是上百量级的画面，人工注意力会衰减，而文字越界往往只差几个像素。改一次规则就要全部重看，人工流程无法做回归。”}},{“@type”:”Question”,”name”:”getBBox 越界检测到底检测什么？”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”检测渲染后的真实文本包围盒。字体度量与实际渲染尺寸只有在浏览器里才能确定，所以设计上放得下不等于渲染后放得下。”}},{“@type”:”Question”,”name”:”为什么更换字体后要重跑越界校验？”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”因为字宽会变。原型使用系统字体（Bahnschrift、Microsoft YaHei 等）且不一定允许嵌入式再分发，移植前必须重选字体并重跑文字边界检测。”}},{“@type”:”Question”,”name”:”自动视觉校验通过后能直接上实机吗？”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”不能。这套校验只覆盖原型层的布局与状态逻辑，不证明 ESP-IDF/LVGL 点屏、SPI/DSI 实际帧率、实车 PID 支持与计时精度；1.64 的横屏旋转与触摸映射仍需实机验证。”}}]}]}

    延伸阅读

  • 一套令牌覆盖 5 种分辨率：车载 HUD 从 456×280 到 1280×720 的适配工程

    结论：一块屏扩成五块屏，成本取决于「一套规则能复用多少」，而不是画了多少张图。我们的赛道 HMI 原型用一套设计令牌加一组布局推导规则驱动 5 种画布，从 456×280 到 1280×720，自动生成 52 张预览。新增一块屏时改的是推导规则，不是重画一套视觉。

    五块画布的尺寸与旋转关系

    画布 UI 分辨率 物理面板 定位
    1.64 寸 456×280 280×456 竖屏，旋转使用 极简零百计时
    3.5 寸 480×320 320×480 竖屏，旋转使用 单表
    4.3 寸 800×480 480×800 IPS 横屏使用 赛道分区
    5.0 寸 1280×720 720×1280 IPS 横屏使用 宽屏全景
    3.97 寸电子纸 800×480 800×480 电子纸 离线路书

    这里有个容易沿用的错误：1.64 寸不是圆屏。它的原生面板是 280×456 的长方形 AMOLED，早期视觉稿里的「400×400 圆表」是过时概念稿。这个数字很重要——它决定了 UI 必须按 456×280 重新排，而不是把圆表缩放过来。

    令牌分两层：结构色与语义色

    以默认的「厂商（pro）」主题为例，令牌按职责分成两层，这个分层是跨尺寸复用的前提：

    层 令牌 色值 用途
    结构层 背景 #05080A 夜间主屏
    面板 #0D1417 卡片与次级底条
    抬升面 #131D21 最佳成绩与告警格底
    主读数 #EDF3F4 车速、转速、时间
    次级文字 #93A7AC 标签与单位
    三级文字 #5B6E75 指标名与弱化信息
    语义层 青色 #4FD1C5 最佳圈、速度弧
    琥珀 #F5B942 DELTA、预警、转速弧
    绿色 #7CD98A 低转换挡灯、正常状态
    红色 #FF5A4E 高转灯、报警

    结构层可以随主题变化，语义层不可以。红 / 琥珀 / 绿在五套主题中始终对应报警、预警与正常——这样驾驶员换主题后仍然能「不读数值就判断状态」。语义色不得用于装饰，只能承载状态。

    布局靠推导，不靠等比放大

    这是跨分辨率适配的核心规则：圆表的半径与圆心由可用区宽与高度共同推导，而不是从一个基准尺寸缩放。宽屏下如果直接放大，两个圆表会重叠；按可用区反推半径之后，4.3 寸与 5.0 寸都能保证不重叠。

    同理，信息密度也不是线性增长。5.0 寸的底栏比 4.3 寸多一格胎压，这是宽屏专属的密度提升，而不是把 4.3 的布局拉长。反过来，1.64 寸承担不了圈速栈——那个尺寸只做超大数字双格与底部进度条。

    两类硬约束：电子纸与浅底主题

    电子纸单独一套版式，白底黑字，不套用任何彩屏主题。这不是风格偏好，而是刷新特性决定的：它只用于静态路书与停车状态信息，不显示实时车速、转速或胎压告警。局刷、翻页残影与休眠电流目前仍是待实测项目，在确认波形与刷新能力之前，不能把部分刷新写成必然支持。

    复古主题是浅底设计，被明确排除在夜间驾驶首屏之外——浅底在夜间的反差不足。这条排除规则和电子纸一样，属于设计约束而非审美取舍。

    余光可读靠排版，不只靠字号

    标签统一加字距，数值走 Bahnschrift 类窄体无衬线。窄体能让同样的横向空间容纳更多字符，加字距则让标签在余光扫过时更容易被区分。这两个手段加起来的效果，比单纯放大字号更省空间。

    需要提醒的是，预览使用的是系统字体（Bahnschrift / Microsoft YaHei / Impact / Georgia / Consolas）。固件移植前必须选定允许嵌入式再分发的字体，并重新检查文字边界——换字体就会改变字宽，越界检测要重跑一遍。

    主题切换在设计上有一个可复现的前提：五套主题共享同一组模拟 OBD 数据、计时与告警状态，切换主题不重置回放。这让主题对比变成可比较的实验，而不是五次不同的演示。像 鄂尔多斯国际赛车场 这类高差明显的场地，坡度信息在底部辅助条里的价值更高；而赛道数据的赛后分段复盘可以交给 SR-Data 圈速分析套件，HMI 只负责当场能读懂的那一屏。

    FAQ

    一套令牌真的能覆盖 456×280 到 1280×720？

    能。令牌定义的是色板与字号层级，布局由可用区宽与高度共同推导。例如双圆表的半径与圆心会按可用区计算，以保证宽屏下不重叠。

    1.64 寸是圆屏吗？

    不是。它的原生面板是 280×456 长方形 AMOLED，UI 横屏使用为 456×280，早期视觉稿里的 400×400 圆表是过时概念稿。

    为什么切换主题不会重置回放？

    因为五套主题共享同一组模拟 OBD 数据、计时与告警状态，主题只改变渲染方式，不重置数据。

    语义色可以跟着主题改吗？

    不可以。红 / 琥珀 / 绿在五套主题中分别对应报警、预警与正常，主题只改变底色与版式。

    参考资料

    • 项目 06 —— D:/AI/PROJECTS/kno/README.md（五屏五主题、设计令牌与布局推导）
    • 项目 06 —— D:/AI/PROJECTS/kno/style-skill-research.md（原创风格与检索边界）
    • 项目 04 —— research/five-board-hardware-facts.md（各板原生分辨率与旋转关系）
    • 项目 04 —— research/instrument-matrix.md（风格覆盖规则与 52 张预览）

    更新记录

    首次发布 2026-10-11 最近核对：2026-10-11

    {“@context”:”https://schema.org”,”@graph”:[{“@type”:”FAQPage”,”mainEntity”:[{“@type”:”Question”,”name”:”一套设计令牌真的能覆盖 456×280 到 1280×720 五种分辨率？”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”能。令牌定义的是色板与字号层级，布局由可用区宽与高度共同推导。双圆表的半径与圆心会按可用区计算，以保证宽屏下不重叠。”}},{“@type”:”Question”,”name”:”1.64 寸车载屏是圆屏吗？”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”不是。它的原生面板是 280×456 长方形 AMOLED，UI 横屏使用为 456×280。早期视觉稿里的 400×400 圆表是过时概念稿。”}},{“@type”:”Question”,”name”:”为什么切换主题不会重置 OBD 回放？”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”五套主题共享同一组模拟 OBD 数据、计时与告警状态，主题只改变渲染方式，不重置数据，因此主题对比是可复现的实验。”}},{“@type”:”Question”,”name”:”HMI 的语义色可以跟着主题改变吗？”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”不可以。红、琥珀、绿在五套主题中分别对应报警、预警与正常状态，主题只改变底色与版式，语义色不得用于装饰。”}}]}]}

    延伸阅读

  • 汽车 / 摩托 / 自行车：三类骑行场景对仪表的需求差异

    结论：汽车、摩托、自行车三类骑行场景看着都是「一块小屏」，实际是三条不同的产品线。汽车要的是真实 OBD 适配，摩托要的是耐候结构与手机后台链路，自行车要的是传感器生态——三者的门槛几乎不重叠，把一块屏做成三个尺寸解决不了任何一条。

    三条需求线的分野

    核对过 7 款在售产品的官网信息之后，需求的分化比价格的分化更值得注意：

    场景 用户真正在买什么 典型在售产品
    汽车 OBD 监测 可读车型、OBD 线束、安装与故障状态 ScanGauge 3（US$269.95）
    摩托小型导航 手机后台链路、支架、雨天与手套交互 Beeline Moto II（£179.99）
    摩托互联屏 无线投屏链路与耐候结构 Carpuride W702（US$269.99）
    摩托高亮大屏 户外可读性、供电、振动与生态附件 CHIGEE AIO-6 Max（US$499.00）
    自行车导航码表 导航、记录、传感器与 App 的闭环 Wahoo ELEMNT ACE（US$499.99）
    自行车生态码表 自定义数据页与传动系统集成 Hammerhead Karoo（US$525.00）

    口径先说清楚：以上均为厂商官网当时展示的商品信息与币种，不是中国到手价、销量或长期零售价；本轮没有购买竞品做拆机、亮度、续航或协议测试。

    汽车：真实 OBD 适配是门槛

    ScanGauge 3 官网强调的是 OBDII 车辆数据、彩色触控与故障码读取 / 清除，页面口径是「1996 年后的 OBDII 车辆兼容」。这是典型的汽车线逻辑：用户买的不是一块圆屏，而是「这辆车我读得到」。中国车型覆盖必须另测，不能从 OBDII 兼容这一句推出来。

    对自研产品来说，这条线最难的地方在车型适配而不是显示——可读字段、协议路径、刷新率都随车型与网关变化。

    摩托：耐候结构与手机后台链路才是主体

    Beeline Moto II 只做逐路口导航、骑行数据与数字速度，官网标称防水、抗震与 14 小时续航，不承诺读取摩托 ECU。这个小屏之所以成立，是因为它把手机后台链路、支架、雨天与手套交互都解决了。

    往上走的 Carpuride W702（IP67、1000 nit）与 CHIGEE AIO-6 Max（6 寸 1280×720、2300 nit）卖的是耐候与可读性。这些数字是厂商标称值，需要与实测区分表述。摩托线的门槛可以概括成一句话：外壳不等于防水整机，防水、振动与手套测试是上市门槛。

    自行车：传感器生态比屏幕重要

    Wahoo ELEMNT ACE 与 Hammerhead Karoo 的定位很明确——它们是导航、数据记录、传感器与 App 的闭环，Karoo 还强调自定义数据页与 SRAM AXS 集成。自行车线的竞争点不在屏幕，而在能连上多少传感器、能自定义多少数据页。因此标准 BLE 心率服务优先，自有协议只能作为后续扩展。

    大屏是第四类边界，不该混进来

    Carpuride W903 双摄版（US$249.99）是 9.3 寸车载多媒体屏，功能涉及手机互联、前后摄像头与语音控制。后视影像与导航属于另一个尺寸与安全边界——5 寸板只能先做非安全关键演示，不应纳入圆形 OBD 小表的首发范围。把这条线混进小表，会让显示、供电与法规边界一起失控。

    差异化验证清单

    产品线 首版主张 必须与竞品对照的实测项 暂不承诺
    汽车 OBD 小表 紧凑的可配置转速 / 车速 / G 值与清晰失联状态 目标车型 PID 覆盖、刷新率、夜间与日光可读性、安装与完整交付成本 通用适配所有车型、靠主控板直连 OBD、未核实的故障诊断能力
    摩托小表 手机路线转向 + 倾角；车型适配后才加入发动机数据 防水振动、手套交互、手机后台可靠性、目标车型线束与协议 1.85 寸完整 CarPlay / Android Auto、所有摩托通用 OBD
    自行车码表 轮速 / GPS 速度、转向提示、标准 BLE 心率优先 速度来源、心率兼容、续航、阳光可读、雨天操作 仅凭 IMU 算出可靠骑行速度、未经证明的戒指心率广播
    大屏探索 结构化导航与摄像头链路技术样机 阳光亮度、延迟、供电、环境可靠性与安装遮挡 可代替后视镜或安全关键影像显示

    三条线的工程资产可以复用：传感器数据模型、蓝牙协议、UI 组件、日志与 OTA 框架共用，但发布与 BSP 分开。采集与实时链路可以分别参照 SR-RaceBox 车载数据采集器 与 SR-Telemetry 实时遥测云。像 宁波国际赛车场 这类可高频复用的场地，适合用来同时验证三类场景的数据链路。

    FAQ

    同一块屏能同时服务汽车和摩托吗？

    硬件可以共用，产品线不能合并。汽车要解决 OBD 车型适配，摩托要解决耐候与手机链路，验证项几乎不重叠。

    为什么摩托仪表不承诺读 ECU？

    因为摩托的 ECU 协议与诊断接口远不如乘用车统一，车型线束与协议差异很大。在车型适配完成之前，只承诺手机发送的转向信息与 IMU 倾角更诚实。

    自行车码表为什么强调标准 BLE 心率？

    因为自有协议无法替代通用传感器生态。标准心率服务优先，戒指等自有协议只能作为后续扩展，且需协议资料到手后才接入。

    大屏导航能不能作为首发的第四类产品？

    不建议。后视影像与导航属于另一个尺寸与安全边界，未通过延迟、环境与法规评估前只能作为技术样机。

    参考资料

    • 项目 04 —— D:/AI/PROJECTS/vehicle-display-board-research/research/market-products.md（市场产品对照，查阅于 2026-10-03）
    • 项目 04 —— research/model-product-designs.md（三个产品族与目标价假设）
    • 厂商页面 —— scangauge.com、beeline.co、carpuride.com、chigee.com、wahoofitness.com、shop.sram.com

    更新记录

    首次发布 2026-10-11 最近核对：2026-10-11

  • 84% 的 PID 没有公开证据：OBD 私有协议解析的现实边界

    「插上 OBD 就能读出全部车辆数据」是一句在销售话术里反复出现、但在工程上站不住的话。真实情况是：私有 PID 不是不能解，而是绝大多数定义缺乏可交叉验证的证据来源。我们对 126,217 条 PID 定义做了证据分层统计，得到的比例足以说明问题。

    证据分层的四个台阶

    证据等级 条数 占总数 能推出什么
    有数值相等性用例 1,916 约 1.5% 可做数值校验，可信度最高
    有公开测试文件 16,807 约 13% 有参考样本，仍需实车核对
    有公开精确定义线索 16,589 约 13% 有定义文字，未验证数值
    无公开索引线索 106,198 约 84% 无法交叉验证

    也就是说，能拿来做数值相等性校验的只有约 1.5%。数据库自身还标注了一层不确定性：public_case_origin 字段说明公开用例并未被独立验证为真实车辆通信流量。这两层叠加后，任何「覆盖十万条 PID」的宣传都需要打折理解。

    私有协议解析到底难在哪？

    难在三件事同时成立：协议未知、单位未知、适用条件未知。一条私有 PID 即便拿到了请求与响应模板，也需要回答「这个字节是温度还是压力」「系数是多少」「适用于哪个年款」。缺任何一项，解出来的数字都只是字节的排列。

    我们的处理方式是分层授权而非全量开放。插件化平台允许通过签名协议包新增 PID/DID 的解码定义，但前提是传输方式已支持、来源合法且请求模板经验证。新诊断传输、加密接入与复杂状态机则可能需要固件升级；新 CAN 控制器、引脚与显示驱动通常需要固件甚至硬件改动。

    首期明确不做什么

    这份清单比「能做什么」更重要：

    类别 状态 原因
    任意 C/C++ 动态代码 暂缓 无法静态验证资源与权限
    行驶中主动探测未知诊断服务 暂缓 可能影响车辆总线
    由模型直接发送 CAN 帧 暂缓 绕过确定性校验
    刷写 ECU / 清故障码 暂缓 超出辅助信息仪表边界
    执行器测试与安全关键控制 暂缓 需单独立项与安全评审

    对 Honda Civic Type R FK8 这类涡轮前驱车，车主最想要的通常是增压压力与油温，但这些字段恰恰常落在私有定义里。我们的做法是把已验证的部分明确标注，未验证的部分留白——这与 SR-ECU 赛车 ECU 标定工具 坚持的「写入前全量逻辑校验 + 原始固件一键回滚」是同一条原则：宁可少给一个数字，也不给一个无法追溯来源的数字。

    那还能做什么？

    能做的比想象中多，只是路径不同。采集端先把原始样本攒够：以 SR-RaceBox 车载数据采集器 这类设备按 IMU 50 Hz、GPS 20 Hz 同步记录，并保留原始帧、解码值与时间戳，之后再用统计方法反推定义。

    这属于差分定位思路的工程化应用：不依赖单条定义的先验知识，而是用同一车型多次采集之间的差分关系，配合已知标准 PID 做锚点，逐步收敛出私有字段的语义与系数。它的产出不是一份拍脑袋的 PID 表，而是一份带证据、带适用条件、带车型年款的结构化结果。

    同时必须守住一条底线：实验解析使用独立命名空间与显著状态，实验能力不得在日常仪表中冒充正式测量值；AI 不得自动通过「让数值看起来合理」来完成标定。

    FAQ

    能不能一次解析出全部私有 PID？

    不能。约 84% 的定义没有公开索引线索，仅约 1.5% 有数值相等性用例，无法批量验证。

    公开测试文件算不算已验证？

    不算完全验证。它提供参考样本，但采集条件与车型范围仍需实车核对，数据库也标注了公开用例未独立验证为真实车流。

    新增一个 PID 定义需要刷固件吗？

    不一定。若传输方式已支持、来源合法且请求模板经验证，可通过签名协议包新增；新诊断传输或加密接入仍需固件更新。

    AI 能自动解出私有协议吗？

    不能直接发布。AI 只能输出结构化提案，不能把猜测的协议发布为正式信号，也不能自动完成标定。

    参考资料

    • 项目 01（本地镜像）—— D:/Backup/Documents/开发板侧端模型/Car-Scanner-功能点数据库/apk_pid_evidence_summary.json
    • 项目 01（本地镜像）—— apk_pid_evidence_coverage.csv（126,234 行逐条证据）
    • 项目 05 —— OBD_AI插件化平台方案书.md（V1.0，首期交付与暂缓范围）
    • 项目 04 —— research/five-board-hardware-facts.md（第 7 条：CAN 帧解码与 OBD-II 是不同路径）

    更新记录

    首次发布 2026-10-11 最近核对：2026-10-11

  • 226 个功能点拆成 20 个模块：一款 OBD App 的能力地图

    结论：把一款 OBD 应用拆成 226 个功能点之后，真正有用的信息不是总数，而是它们落在哪 20 个模块里。排名第一的不是界面、不是数据展示，而是「编码与适配」——33 个功能点。这份模块分布说明了一件事：OBD 应用的门槛从来不在屏幕上，而在「这台车、这个年款、这条 PID 到底怎么解」。

    226 个功能点是怎么拆出来的

    这份清单不是厂商公布的口径，而是按实机截图、布局 XML 与静态资料逐条拆解、建库统计的结果。每个功能点都挂了来源证据，最终形成 533 条来源链接、覆盖 305 个不同来源。方法上刻意做成「可审计」：任何一条功能点都能追回它对应的截图或文档，而不是凭印象罗列。

    20 个模块的分布

    模块 功能点数 它解决什么问题
    编码与适配 33 协议与车型适配，最大的模块
    入门与连接 27 首次启动、适配器选择与连接向导
    故障诊断 22 故障码读取与解释
    所有传感器 20 标准传感器数据的组织与展示
    自定义传感器 20 用户自定义 PID 与换算公式
    数据记录 19 日志记录与导出

    前六个模块合计 141 个功能点，占了 226 里的六成以上；剩下十余个模块分担了仪表、界面、单位、设置、分享等外围能力。

    为什么「编码与适配」排第一

    因为它对应的是产品最难被复制的那部分工作量。传感器列表、仪表盘样式这类功能谁都能做，而「某个年款、某个区域版本的车型，第几条 PID 用什么公式解」只能一条一条积累和验证。这也是为什么这个模块的功能点数最多——它反映的不是设计者的偏好，而是行业本身的难度分布。

    「入门与连接」排第二同样值得注意：27 个功能点都在处理适配器、蓝牙链路与连接向导。这说明实际使用中，用户卡住的地方往往不是读不懂数据，而是连不上。

    功能点的证据强度分三级

    同一份清单里，功能点被证明的程度并不一样：

    证据层级 功能点数 含义
    实机 UI 证据 146 有截图与布局 XML 直接佐证
    静态资料验证 80 由文档、资源或配置文件佐证
    尚无直接证据 94 其中静态类 76 个，需要继续补证

    这张表的价值在于它自带「不确定性刻度」。引用这份数据时，必须同时说明哪些功能点是实测看到的、哪些只是资料推断的——否则清单看起来一样整齐，可信度却差很多。

    功能清单不等于可用能力

    把视角从功能点切到字段规模，差距更明显。从 APK 2.1.50 抽取出的 PID 定义有 126,217 条，分布在 1,304 个车型配置档里。但按证据分层看：

    证据层级 条数 占比
    PID 定义总数 126,217 100%
    无公开索引线索 106,198 约 84%
    有公开测试文件 16,807 约 13%
    有数值相等性用例 1,916 约 1.5%

    约 84% 的定义没有公开索引线索，能拿来做数值相等性校验的只有约 1.5%。数据库自身也标注了 public_case_origin 未独立验证为真实车辆通信流量。这决定了任何「自动解析全部私有协议」的宣传都不成立。

    对自研产品的能力地图启示

    第一，把能力按验证等级发布：标准服务验证通过、厂商授权验证通过、实验适配、尚未支持。实验能力不得在日常仪表中冒充正式测量值。

    第二，「自定义传感器」能单独成为一个 20 功能点的模块，说明用户愿意自己写公式——但这恰恰是校验最容易缺失的地方。单位转换规则应来自确定性库，格式错误与量纲冲突必须在绑定时被拒绝，缺失数据不得默认为零，估算值必须带标记。

    第三，竞争力最终回到数据闭环。SR-Data 圈速分析套件 坚持桌面端离线运行、数据不出本地，就是因为采集端积累的样本才是长期资产，而不是某一份静态 PID 清单。对 Mazda MX-5 ND 这类赛道日常见车型，跑够样本之后能回答的问题，比任何通用数据库都具体；而写入类能力（如 SR-ECU 赛车 ECU 标定工具）属于受控操作，不应与只读解析混在同一权限层级。

    FAQ

    226 个功能点是官方公布的吗？

    不是。是按实机截图、布局 XML 与静态资料逐条拆解并建库统计的结果，非厂商官方口径。

    为什么功能点数最多的模块是「编码与适配」？

    因为它对应最难积累的部分——特定车型与年款的 PID 定义与解码公式，只能逐条验证，无法靠通用逻辑覆盖。

    「尚无直接证据」的 94 个功能点应该怎么处理？

    应作为待补证项保留并标注，而不是删除或默认其为真。证据分层本身就是这份数据的价值之一。

    126,217 条 PID 都能用吗？

    不能这么理解。这是 APK 中抽取的定义数量，其中约 84% 没有公开索引线索，仅约 1.5% 有数值相等性用例。

    参考资料

    • 项目 01 Car Scanner 竞品研究（本地镜像）—— D:/Backup/Documents/开发板侧端模型/Car-Scanner-功能点数据库/feature_evidence_summary.json
    • 同目录 —— apk_pid_evidence_summary.json、features.psv、feature_source_evidence.csv
    • 实机 UI 证据 —— live-2026-09-26/（截图与布局 XML，采集于 2026-09-26）
    • 说明 —— 项目 01 的 NAS 原始副本 \192.168.31.115团队文件-星核公司数据库公共中转站car-scanner-research 当前不可达，本次处理基于 D 盘本地镜像

    更新记录

    首次发布 2026-10-11 最近核对：2026-10-11

  • openpilot 的 100 Hz 控制回路：开源 ADAS 能给车载设备什么

    需要事先说明一件事：本次项目 02 的内部深度研究副本存放在 NAS（\192.168.31.115谭健强openpilot-research），当前因缺少 SMB 凭据而不可达。本文只基于公开可核验来源写成，涉及车型覆盖数量与硬件售价的数字在不同来源间存在口径差异，已标注为待核实。

    结论先行：openpilot 对车载只读设备最大的参考价值，是它把「感知—决策—执行」拆成了通过消息总线解耦的独立进程，并且严格区分了只读信号与控制指令。这两点恰恰是 OBD 仪表最容易做错的地方。

    100 Hz 是怎么排出来的？

    openpilot（comma.ai 开源的 L2 级辅助驾驶系统）按职责拆分进程：camerad 负责摄像头采集，modeld 运行驾驶模型推理，plannerd 负责横向与纵向规划，controlsd 以 100 Hz 频率输出控制指令，locationd 做基于卡尔曼滤波的定位，calibrationd 动态校准相机姿态，pandad 负责 CAN 收发。这些进程通过 cereal 消息框架解耦通信。

    进程 职责 对只读设备的启发
    modeld 运行驾驶神经网络 采集线程不做重计算
    controlsd 100 Hz 输出控制指令 控制回路频率与显示刷新频率分离
    locationd 卡尔曼滤波定位 定位需要独立的质量状态
    calibrationd 动态校准相机姿态 标定参数需记录版本与有效期
    pandad CAN 收发 车辆接口应独立成宿主进程

    这张表的关键不在频率数字，而在「100 Hz 与显示刷新率无关」。我们在车载仪表上反复强调同一件事：显示每秒重绘 30 次，不代表接收到 30 个独立样本；采样频率、传输频率、模型消费频率与显示频率必须分别记录。

    为什么端到端模型不能替代协议定义？

    openpilot 的 supercombo 模型直接从相机图像预测车辆行驶轨迹，这在感知层是有效的。但车辆信号是另一回事——私有 PID 的定义、单位与量纲需要可验证的来源，不能靠模型「让数值看起来合理」来完成标定。

    我们在 LINK 设计说明里把这条写成了硬约束：需要传感器标定或零点补偿时，必须记录标定人、时间、原始单位、有效范围与参数版本，AI 不得自动通过拟合外观来完成标定。同样，AI 只能输出 EdgeSpec 提案，不能把猜测的协议发布为正式信号。

    开源 ADAS 与只读 OBD 仪表的边界在哪？

    两者都通过 CAN 总线读车，但权限完全不同。openpilot 是向车辆发送控制指令的 L2 级辅助驾驶系统，需要驾驶员随时接管。OBD 仪表则是辅助信息显示设备，明确不替代车辆原有法定或安全关键仪表，不直接控制车辆执行器。

    我们的插件化平台把这条边界写进了首期暂缓清单：任意 C/C++ 动态代码、行驶中主动探测未知诊断服务、由模型直接发送 CAN 帧、刷写 ECU、清故障码、执行器测试与安全关键控制，都不在插件权限内。后续如果确有控制需求，应单独立项并重新开展安全与合规评审。

    这也是为什么驾驶员监控（Driver Monitoring）值得单独研究：它是 openpilot 中最常被部署的开源 DMS 实现之一，依赖车内摄像头做注意力与疲劳检测。对我们来说，它的参考价值在于「如何用视觉信号产生一个带质量状态的布尔量」，而不是如何介入车辆。

    车型适配为什么是最难的一环？

    openpilot 的公开资料显示支持的车型数量在 275 至 325 款之间，且随版本持续增加，不同来源口径不一致，准确情况应以 comma.ai 官方兼容列表为准。即便在这个量级上，安装仍需车型专用线束——这恰恰说明车型适配没有捷径。

    我们自己的经验与此一致。像 Honda Civic Type R FK8 的 K-Type ECU 与老车的 Bosch M1.2 走的是完全不同的协议路径；在 珠海国际赛车场 这类高频开放场地积累的多车型样本，比任何一份通用兼容清单都更有价值。采集侧我们使用 SR-RaceBox 车载数据采集器 以 IMU 50 Hz、GPS 20 Hz 同步记录，先把数据攒够再谈协议覆盖。

    FAQ

    openpilot 是开源的吗？

    是。它以 MIT 许可开源，由 comma.ai 维护，定位为 L2 级辅助驾驶系统。

    控制回路真的是 100 Hz 吗？

    公开技术资料的口径是 controlsd 以 100 Hz 输出控制指令。该数字未由本项目实机验证，属公开来源转述。

    OBD 仪表能像 openpilot 一样控制车辆吗？

    不能，也不应该。OBD 仪表是辅助信息显示设备，不控制执行器、不刷写 ECU、不清故障码；首期暂缓清单已明确排除这些能力。

    为什么本文的车型数量是一个区间？

    因为公开来源分别给出 325+ 与 275+ 两种口径，且随版本变化。准确情况应以 comma.ai 官方兼容列表为准。

    参考资料

    • 公开来源 —— comma.ai openpilot 仓库 https://github.com/commaai/openpilot（2026-10-11 采集）
    • 公开来源 —— openpilot 架构与硬件参数综述 https://bikmantech.com/blogs/blogs/openpilot-everything-you-need-to-know（2026-10-11 采集）
    • 公开来源 —— openpilot daemon 架构与部署实践 https://blog.csdn.net/wenxin77wx/article/details/162380437（2026-10-11 采集）
    • 内部对照 —— 项目 05 OBD_AI插件化平台方案书.md（V1.0，首期暂缓范围）
    • 说明 —— 项目 02 内部深度研究副本位于 NAS，本次因缺少凭据不可达

    更新记录

    首次发布 2026-10-11 最近核对：2026-10-11

  • OBD 零百计时的链路标定：轮询周期、往返延迟与丢包率怎么测

    结论：OBD 加速计时器的精度不是「算出来的」，是「标出来的」。在宣称任何指标之前，必须先把三件事定义清楚：界面刷新频率不等于车速采样频率、时间戳记的是 OBD 响应接收时刻而非 ECU 采样时刻、以及一次「有效样本」的判定条件。之后才谈台架注入与实车链路测量。

    标定前必须先定义的三件事

    三件事不定义清楚，后面的数据都不可比：

    1. 采样 ≠ 刷新。屏幕每秒重绘 30 次，不代表每秒拿到 30 个车速样本。采样频率、传输频率、模型消费频率与显示频率必须分别记录。
    2. 时间戳口径。所有时间戳都是 OBD 响应接收时刻，不是 ECU 实际采样时刻。这是链路的固有偏差，只能披露，不能消除。
    3. 有效样本定义。连续 0 km/h 的判定需要多个有效样本——网关断连期间「保持」的旧值不计入。

    每条样本要留哪六项

    标定能复现的前提是原始记录完整。每条车速样本至少保存六项：

    字段 作用
    原始响应 可回溯协议层实际返回值，便于事后复核解码
    解码值 换算后的车速数值，用于比对
    请求发出时间 往返延迟的起点
    响应接收时间 往返延迟的终点，也是计时所用的时间戳
    网关状态 区分「车没给数据」与「网关断了」
    单调时钟时间戳 不受系统对时跳变影响，保证乱序可检

    台架注入：六类异常必须全部覆盖

    把速度曲线喂给同一套解析与状态机，逐条核对状态切换与时间戳是否正确。以下六类场景缺一条，标定就不算完成：

    异常场景 要验证什么
    缓慢起步 车辆长时间停留在 1 km/h 附近时，起点判定是否仍然确定
    瞬时跳值 单帧车速从 0 跳到 60 这类超物理变化是否被拦下
    重复帧 同一时刻收到多条相同样本时是否误判
    乱序 时间戳非单调递增时的处理
    超时 请求发出后长时间无响应是否判无效
    中途失联 RUNNING 期间网关断开是否正确作废本次成绩

    实车要记录的五组链路参数

    台架通过只说明逻辑对，不代表这台车的数据质量够用。在目标车型上至少要记录五组：

    • PID 支持情况——这台车到底报不报 0x0D，以及是否走专用车速信号。
    • 有效车速更新率——每秒真正拿到多少个可信样本。
    • 请求往返延迟分布——不只看平均值，要看分布形状。
    • 网关额外延迟——受保护网关引入的附加时延。
    • 计时期间丢包率——0–100 全过程里的样本丢失比例。

    这五组数据共同决定一件事：这台车上「起点」和「终点」两个时间戳的可信区间有多宽。

    参考设备比对怎么做

    用独立参考设备同步采集多次 0–100，统计偏差（系统误差）与离散程度（随机误差）。这里要区分两个量：偏差小说明链路没系统性跑偏，离散大说明重复性差——后者对用户体验的伤害往往更大，因为它让同一台车同一次操作给出不同数字。

    不同动力特性对窗口的要求也不同。Porsche 911 GT3 RS (992) 的 525 PS 会把 0–100 的时间窗压得很窄，对链路分辨率的要求高于 Nissan GT-R R35 这类大扭矩平台。

    什么时候可以宣称精度

    「±0.05 秒」与「优于手机」在规格文件中被明确列为待验证目标。要把它变成可宣称的指标，必须走完上面三步并获得实测数据统计。在那之前：

    • 首版不插值，也不借用 IMU 或 GPS 填补样本；
    • README 与文案不得出现未经验证的精度数字；
    • 界面提供五种状态——待连接、待起步、计时中、成绩、无效记录；
    • 历史最佳只收录有效且带车型 / 数据源元信息的成绩，没有元信息的成绩无法复盘，也就不该进榜。

    成绩出来之后的分段复盘可以交给 SR-Data 圈速分析套件 处理，计时器本身只负责给出可追溯的原始时间线。

    FAQ

    为什么时间戳不能直接用 ECU 采样时刻？

    因为标准 OBD 响应里拿不到这个信息。链路能观测到的最早时点是响应接收时刻，它是固有偏差，只能记录与披露。

    台架测试全过了，能直接上实车吗？

    不能。台架验证的是逻辑与状态机，实车还要记录 PID 支持情况、更新率、往返延迟分布、网关额外延迟与丢包率，才能判断这台车的数据质量是否够用。

    参考设备比对要采多少次？

    规格要求「多次」，目的是同时估计偏差与离散程度；单次比对无法区分系统误差与随机误差。

    ±0.05 秒可以写进宣传文案吗？

    不可以。它是待验证目标，需要台架注入测试与目标车型实测统计之后才能确认。

    参考资料

    • 项目 04 —— D:/AI/PROJECTS/vehicle-display-board-research/research/obd-acceleration-timing.md（1.64 寸 OBD 零百计时规格）
    • 项目 04 —— research/five-board-hardware-facts.md（第 5 条：零百只用 OBD 车速计时）
    • 项目 04 —— research/prototype-portfolio-v2.md（03 号原型功能边界）

    更新记录

    首次发布 2026-10-11 最近核对：2026-10-11

  • Ed25519 签名加 96 字节事务记录：让 MCU 升级不怕中途断电

    升级失败有两种形态：一种是包本身不可信，另一种是包可信但没写完。前者靠密码学解决，后者靠事务与双槽解决。EdgeForge 把这两件事做成同一条发布链上的不同检查点，任何一环不过就拒绝加载。

    签名验的是什么？

    EFP v2 同时包含 EFB（EdgeVM 字节码包）与 EFIR（中间表示）两个产物，Ed25519 签名覆盖包头、ESEC 安全索引、审计 JSON 以及这两个产物。ESEC 是给 MCU 用的二进制安全索引，不依赖 JSON 解析，携带目标平台、应用版本、发布序列、密钥 ID、最低 Host API、能力清单与两个 SHA-256 摘要。

    检查层 检查内容 验证方式
    包结构 包长、段边界、ESEC 记录与签名长度 C99 安装层逐项核对
    兼容策略 目标平台、Host API、序列下限、能力策略 与平台配置比对
    完整性 EFB 与 EFIR 的 SHA-256 与 ESEC 摘要比对
    来源 Ed25519 验签 强制平台回调完成

    加密库的选择按平台分开：ESP32-S3 Host 接入固定版本的 Espressif 官方 libsodium 组件，RP2040 与 STM32F4 Host 接入 Monocypher 4.0.2。三个 MCU 平台的实板验签与密钥生命周期验证目前仍待完成，这是量产前必须补上的一环。

    断电之后，设备怎么知道该用哪个版本？

    靠 96 字节的事务状态记录。功能包采用 A/B 双槽与 active / candidate / last-known-good 三态：候选包先在暂存区落地，试运行通过后才原子激活；激活后有 5 秒的健康窗口等待 ACK 确认；未确认或连续启动超过限制就自动回退到已知可用版本。

    完整的安装流程是：能力查询 → 用户批准 → 分片传输与重传 → 完整摘要与签名校验 → 资源与依赖校验 → 暂存 → 试运行 → 原子激活 → ACK 健康确认。包状态与用户配置分别版本化，升级过程中断电，重启后按事务记录恢复。

    规则是：首次安装候选被拒绝且没有旧稳定版本时，公共层会清空运行态；已有稳定版本时立即回载旧槽；连续启动超过限制时由包管理器自动回退。回退受最低安全版本限制，不能恢复已撤销的漏洞版本；没有可用旧版时进入受限模式，保留基础采集与恢复通道。

    端侧编译完成后还要再核对一次吗？

    要，而且是逐字节核对。通用 MCU 自编译 Host 的启动链固定为：读取活动 A/B 槽中的 EFP → 校验目标、Host API、能力、摘要与签名 → 验证 EFB/EIDX → 解析 EFIR → 在设备内把 EFIR 编译到 RAM → 逐字节核对生成代码与管线描述是否与签名 EFB 一致 → 直接执行 RAM 中的端侧编译结果。任何不一致都拒绝加载，EFB 保留为签名参考与信号、事件、UI 描述的来源。

    权限不是签名给的

    签名只证明来源与完整性，不代表插件自动获得清单里请求的全部权限。实际权限是五者的交集：包声明、发布者权限、用户授权、设备能力与平台策略。这条设计直接影响车载场景——一个页面包不能携带新增的车辆请求权限，普通插件也无法拿到原始射频、任意 BLE 写入或 CAN 发送能力。

    这与我们在 SR-ECU 赛车 ECU 标定工具 上坚持的「写入前全量逻辑校验 + 原始固件一键回滚」是同一条思路：能力可以给，但必须可审计、可回滚。对 Nissan GT-R (R35) 这类四驱高性能车尤其重要——四驱会掩盖走线问题，任何错误的写入都会让后续数据失去参考价值。采集端的 SR-RaceBox 车载数据采集器 同样依赖掉电保护，异常断电不丢已记录段。

    FAQ

    签名成功就等于可以发布了吗？

    不等于。AI 生成、开发者编译与维护方签名是三个不同角色，编译成功不代表已获发布许可，发布链还包含仿真回放、资源分析与发布审核。

    断电时正好写到一半会变砖吗？

    不会。96 字节事务状态记录配合 A/B 双槽，重启后按事务恢复；已有稳定版本会立即回载旧槽，无旧版则进入受限模式并保留恢复通道。

    回退能退回到任意旧版本吗？

    不能。回退受最低安全版本限制，不能恢复已撤销的漏洞版本。

    验签用的库在三个平台上一样吗？

    不一样。ESP32-S3 用 Espressif 官方 libsodium 组件，RP2040 与 STM32F4 用 Monocypher 4.0.2，均通过平台回调接入。

    参考资料

    • 项目 05 —— D:/Backup/Documents/开发板侧端模型/EdgeForge自编译软件框架方案.md（V1.4，第 10 节安装、签名和回退）
    • 项目 05 —— OBD_AI插件化平台方案书.md（V1.0，治理与分发层）

    更新记录

    首次发布 2026-10-11 最近核对：2026-10-11