wangfq/vd_960
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 4 Wiki Activity
Files
70e44e6241b9badbb193695c80cafb8201da6d4e
vd_960/docs/ROADMAP.md
T
wangfq 70e44e6241 docs(roadmap): 补充脱机日志子系统 + 日志导出管理 + 远程OTA路线细化 
- P1.2 脱机日志: W25Qxx 分区规划(参数/事件流/快照流/OTA暂存),
  事件流必录清单, 快照流同频落盘挂 iot_sensor_ingest 同源出口,
  无RTC时间戳方案(boot_seq+mstick+时钟锚点)
- P1.3 导出与管理: MQTT断网补报/命令分页拉取/BLE小程序读取
  三通道, log_stat/log_clear(鉴权+审计自记录)
- P1.4 远程OTA: 先走现网MQTT+复用ISP透传底层(与BLE OTA同构);
  Loop先存后刷+断点续传+回滚, 继电器安全底线;
  DBN自身远程OTA三路线比选(过渡态=仍走BLE最稳妥)
- 风险表新增: 无RTC时间戳、日志写与总线争用
2026-07-17 18:57:13 +08:00

14 KiB
Raw Blame History

vd960 (DLD960) 开发计划 — V1.0.0 之后

制定日期：2026-07-17 · 基线：整机 V1.0.0（2026-07-16 发布） 原则：先稳固、再上云、后算法深化；任何涉及继电器输出的改动，防砸车逻辑优先。

0. 现状基线

项 状态
整机版本 V1.0.0（首发），Loop/DBN 固件 1.0 配套
协议 Loop 串口 V1.05 / TTL 串口 V1.01 / TCP JSON V1.01 / IoT MQTT V1.05
在途改动（未提交） BLE 透传路径重构：usart_biz.c 0x7F→0x8F 帧改走 set_response_tran_to_notify()，原 _report_flag 保留机制移除
已知约束 无 RTC（依赖平台下发 ts）；CH32V208 栈紧张；Loop/DBN 固件禁止混刷

P0 — 发布后稳固（目标 V1.1.0，约 2~4 周）

P0.1 BLE 透传路径重构收尾 🔴（在途）

当前工作区改动把 0xC0 传感帧的 BLE 转发从"置 flag 延迟消费"改为"立即 notify"。收尾必须核对三件事：

  1. 帧消费方真值表：0xC0 帧现在有 三个消费方（TCP JSON 回调 / MQTT iot_sensor_ingest / BLE notify）。2026-07-15 的"陈旧快照 34 秒"事故根因就是消费路径数据源分裂——BLE 加入后必须重画一张"谁消费、谁清理（InitPkgUart）"的真值表，确保：
    • 每条路径都能拿到帧（同源汇聚不漏帧）；
    • 帧最终一定被清理（无滞留 → 无假"新帧"）；
    • BLE ACS 分支改 Magic 为 0x8F 后，MQTT/TCP 路径若还要读同一缓冲，读到的是被改过的帧头（待确认是否有影响）。
  2. set_response_tran_to_notify() 新增返回值的语义与调用方检查。
  3. 板上验证：BLE 小程序连上时，TCP/MQTT 上报不受影响；BLE 断开后无帧泄漏。

P0.2 代码 TODO 清剿

位置 问题 优先级
iot_mqtt_srv.c:753 loop_ok[i] = 1 硬编码，未取 Loop MCU 真实线圈状态 → 平台看到的线圈健康度是假的 🔴 高
net_srv.c:528 MQTT 接收长度未做溢出防护（len-received 越界风险） 🔴 高
storage.c:494（DBN） Flash_Model 读失败无停机/降级保护 中
net_srv.c:1225 序列号修改命令未实现 中
dbn_ble_srv.c:870 ACS timeout min→ms 换算待确认（当前 ×60×100，疑似按 10ms tick，需对时钟源） 中
main.c（Loop）多处 "不整个设备复位，只复位蓝牙以外部分"——历史注释，评估后关闭或立项 低

P0.3 回归验证清单（配合 vd_test_fixture 工装）

  • 长车双线圈场景复测：car_leave 事件后下一条 loop_data 的 iscar 必须已翻 false（同源验证）
  • event_report 断网入队 → 重连补报闭环；5s 超时重发 ×3 后的放弃行为
  • 时钟同步：校准前 ts=上电秒数的平台侧兼容；mstick 49.7 天回绕仿真（gcc 隔离单测）
  • MQTT 稳定性：>512B 帧、PINGREQ 保活、broker 主动踢线后的重连节奏
  • 拨码/灵敏度/hold_time/relay_delay 全参数配置读写一致性（BLE 链路 + MQTT 链路交叉验证）

P0 出口条件：以上全绿 → 两侧 FIRMWARE_VER 升 1.1 → 整机 tag v1.1.0。

P1 — 传感数据上云闭环（目标 V1.2.x，约 1~2 月，与 edc_server 平台侧并行）

这是你"传感数据云 + 业务平台"目标的主线，设备侧固件已基本就绪，重心在平台侧消费。

P1.1 平台侧对接（edc_server）

  • event_report 消费契约：平台先落库、后 ACK（code=0）——严禁先 ACK 后落库（设备出队后事件不可再生）
  • loop_data 落库 + 可视化：variation 有符号曲线（正=车/裕量，负=基线污染——免费的诊断维度）、频率漂移趋势图；锯齿波形态识别（5s 基线阶跃是正常形态，别当故障）
  • 流量/占用 API：基于 car_enter/car_leave 事件 + 通过时间/车间距（50ms 单位）产出分通道流量计数、占用率、平均通过时间
  • 设备台账：initialize 上线登记、心跳离线判定（阈值=心跳间隔×3）、report_config 远程下发界面

P1.2 脱机日志子系统 🆕（W25Qxx SPI NOR）

硬件底子：DBN 外挂 W25Qxx（SPI1，驱动支持 Q80~Q128，板上型号待确认——容量决定快照保留时长）。参数区只占头部 <1KB，其余全部可规划。

分区规划（建议，按 W25Q64/8MB 算）：

分区 容量 用途
参数区 64KB（0x000000 起，现用 <1KB） 现有配置，留余量
事件日志区 256KB 环形，关键事件流，不被快照冲掉
传感快照区 ~6MB 环形，0xC0 帧原样落盘
OTA 镜像暂存区 512KB Loop 固件（64KB×2 版本回滚）+ 预留 DBN 镜像

两条日志流分开存：

  1. 事件流（必录，低速率）：car_enter/car_leave（含时间量）、线圈断线/恢复、继电器动作、上电/复位（含复位原因）、MQTT/TCP 连接与断开、event_report ACK 超时/重发/放弃、配置变更（含来源：BLE/MQTT/TCP）、灵敏度换档、时钟同步锚点、固件升级开始/结果、日志清除操作（审计自记录）
  2. 快照流（环形可覆盖）：0xC0 帧二进制原样 + 头部（序号/boot_seq/mstick），~64B/条，记录节奏与网络上报同频（空闲按 interval、活动 300ms、car 沿立即）——直接挂在 iot_sensor_ingest() 同源出口，天然与上报一致

容量预算（W25Q64）：6MB 快照区 ≈ 9.8 万条；快档 300ms 连续压满也能存 ~8 小时，实际车流场景（空闲 30s + 过车突发）可保留数周。W25Q80（1MB）则只有 ~1.1 万条，所以先确认板上焊的哪颗。

⚠ 无 RTC 的时间戳设计（最容易踩的坑）：断电后 mstick 归零，纯 Unix 时间戳不可行。方案：每条记录带 (boot_seq, mstick)；每次时钟同步成功时写一条时间锚点事件（boot_seq ↔ unix_ts 映射）；导出时由平台/小程序用锚点回算绝对时间。从未同步过的 boot 段只有相对时间——协议文档里要写明这个语义。

磨损与 RAM：环形顺序写天然磨损均衡（4KB sector 顺序擦除，W25Q 10 万次擦写寿命无忧）；复用现有 SPI_FLASH_BUF[4096]，不新增大缓冲（CH32V208 SRAM 紧张的教训）。

P1.3 日志导出与管理 🆕

导出通道（三条，统一按序号分页，不按时间——时间不可靠）：

通道 机制 说明
MQTT 自动补报 断网期间事件流落盘，重连后按序号续传 现有 16 深 RAM 队列扩展为 flash-backed，溢出转日志区；与 event_report ACK 闭环衔接
MQTT/TCP 命令拉取 log_query {stream, start_seq, count} 分页 复用现有 cmd 分发框架；注意 Publish≤500B 分批（MSS=576 教训）
BLE 小程序读取 复用 0x8F 通道新增日志读命令 BLE MTU 分包（20~244B），小程序侧分页 UI

管理命令：

  • log_stat：各流的序号区间、条数、容量占用
  • log_clear {stream}：需鉴权；分流清除；清除动作本身写入事件流（审计——谁在什么时候清了日志）
  • 自动管理：环形覆盖为常态，无需人工干预；满不停写

P1.4 远程 OTA 🆕（路线已定：先走现网 MQTT，底层复用 ISP 透传）

关键认知：BLE 给 Loop MCU 升级 = "镜像经手机流式送到 CH32V208 → ISP 串口透传刷写"。远程 OTA 只是把"送镜像"的传输层从 BLE 换成 MQTT，ISP 透传底层完全复用——且 Loop MCU 的 OTA 根本不需要 CH32V208 做 A/B 分区，镜像只是路过。

分两档，难度和节奏完全不同：

① Loop MCU (AT32F421) 远程 OTA —— v1.2.x 落地

采用先存后刷（优于流式直透）：

  1. 平台 MQTT 分片下发（每片带 offset+CRC，≤500B/片，支持断点续传）→ 写入 W25Qxx 暂存区
  2. 全镜像 CRC 校验通过后，才启动 ISP 透传本地刷写（复用 BLE OTA 的透传状态机）
  3. 抗网络抖动：下载阶段断网无所谓，续传即可；刷写阶段纯本地，窗口短
  4. 暂存区保留上一版镜像 → 支持回滚重刷

安全底线（会车产品，升级失败=继电器行为不可控）：

  • 升级窗口检查：有车压线圈时告警/延迟启动——待定策略
  • ISP 期间 Loop MCU 停止检测，继电器处于什么状态？（复位后 GPIO 默认态应为断开=常开安全侧，待板上验证）
  • 刷写失败自动重试 ×3，仍失败 → event_report 告警 + 保持 ISP 可重入（AT32 ISP bootloader 兜底，不会真砖）
  • 升级开始/结果写入事件日志

② DBN (CH32V208) 自身远程 OTA —— 方案评审先行，落地后置

难点：128KB Flash 装不下 APP 双分区；现有 BLE OTA 走 WCH "OnlyUpdateApp" IAP 框架（bootloader 固定只认 BLE）。候选路线：

  • (a) 镜像下到 W25Qxx 暂存 + 校验 → 改 bootloader 支持从外部 Flash 搬运（动 bootloader 风险高，刷坏只能拆壳烧录）
  • (b) RAM 驻留搬运代码自刷写（掉电=砖，不推荐）
  • (c) 维持现状：DBN 升级仍走 BLE（现场人员），只有 Loop 支持远程——最稳妥的过渡态

先出方案评审文档比选，v1.2.x 期间不阻塞 ①。

③ 4G 通道下的 OTA：4G 模组（TTL 对接 UART1）跑 MQTT 后，①②的分片下载协议原样复用——传输层无关是这套设计的出发点。注意 4G 流量成本：64KB 镜像 + 重传开销可忽略，但快照流补报要设流量上限。

P1.5 设备侧其他补强

  • loop_data 增补字段（若 P1.1 分析需要）：如 Origin 绝对值上报，便于平台重建基线轨迹——走协议 V1.06 流程，两侧同版本配套
  • DBNMQTTool 同步：日志拉取/OTA 分片下发的模拟与断言（工具先行，固件后到）

P1.6 4G 上云通道（UART1 RFU 启用，可后置到 P3）

  • 模组选型（Cat.1 足够：EC800 系列/Air780 级别），AT 透传 vs 模组内置 MQTT 两条路线对比
  • 网口 MQTT 与 4G MQTT 复用同一 iot_mqtt_srv 状态机，仅换传输层——架构上先留接口

P2 — 检测算法深化（Loop 侧，目标 V2.x，约 2~3 月）

P2.1 抗变频器/电磁干扰 🎯（你的长期主目标）

  1. 先取证再动手：用工装+现场采集受扰线圈的 CAPVD 原始序列（10ms 粒度），确认干扰形态（周期性拍频 / 白噪 / 突发脉冲）——待现场验证
  2. 频点错开：4 路线圈两级调频电容（33nF/10nF）已有硬件基础，上电自检各路振荡频率，间距不足时自动切档，抑制相邻串扰
  3. 算法层：现有 IIR+斜率限幅+进入确认对突发脉冲已有基础免疫；针对周期性拍频评估陷波/中值预滤（注意 10ms tick 下的计算预算）
  4. 产出：抗干扰测试报告（干扰源型号、距离、频谱、误检率前后对比）

P2.2 双线圈测速 + 车型粗分类

  • 利用现有 misc 时间量（通过时间/车间距，50ms 单位）+ 已知线圈间距 → 速度估计
  • 信号长度（占用时间×速度）→ 车长 → 粗分类（小车/大车/拖挂）
  • 拖挂车"半截车"识别：单通道内 variation 双峰形态检测——直接服务会车防砸
  • 输出通道：event_report 新增 speed/class 字段（协议升版）

P2.3 方向判别

  • 线圈 1→2 与 2→1 的触发时序 → 方向语义，供会车/双向流量使用
  • Loop 侧输出还是平台侧算：倾向 Loop 侧（时序精度 50ms 内，平台侧受上报调度抖动影响）

P3 — 会车控制与融合（依赖 P1/P2 产出）

  • 会车控制逻辑平台侧先行：基于多台 DLD960 的 event_report（有 ACK 闭环，可靠交付）做单通道红绿灯会车状态机；业务逻辑只认 event_report，loop_data 仅做展示——两通道职责不混
  • 异常分支优先设计：设备离线（心跳超时）→ 会车灯降级策略；继电器粘连检测（relay_count 与命令数比对）；车辆长时间停留（hold_time 超时全通道重启的平台侧感知）
  • 单机版会车评估：DLD960 四通道 + 继电器本地联动能否覆盖小型场景（无平台依赖，可靠性更高）——出对比方案：纯平台 / 纯单机 / 混合
  • 雷达/相机融合接口预留：扩展 UART1 或网口接入目标列表，融合仲裁放平台侧

版本映射与节奏

版本 内容 前置
v1.1.0 P0 全部（BLE 收尾 + TODO 清剿 + 回归全绿） —
v1.2.x P1 设备侧（脱机日志 + Loop 远程 OTA + 协议 V1.06） edc_server 对接联调；W25Q 型号确认
v2.0.0 P2 算法深化（抗干扰 + 测速分类 + 方向） 现场干扰数据采集
v2.x P3 会车控制 P1 平台 + P2 方向判别

风险与待现场验证

# 风险 应对
1 BLE 重构改动帧消费时序，复发"不同源"类 bug P0.1 真值表 + 长车复测强制过
2 变频器干扰形态未知，算法方案可能推倒重来 先采数据后设计，不拍脑袋
3 DBN 自身远程 OTA 无安全落点（128KB 无 A/B、bootloader 只认 BLE） 过渡态：DBN 走 BLE、Loop 走远程；bootloader 改造单独评审
4 协议再升版（V1.06）又是双侧死绑定 沿用 Len 字节区分格式的兼容方案，发布走配套矩阵
5 无 RTC，脱机日志绝对时间不可靠 boot_seq+mstick+时钟锚点回算；协议明示"未同步段仅相对时间"
6 日志高频写与 MQTT/BLE 共抢主循环与 SPI 总线 快照落盘按 page 缓写、擦除放空闲窗口；实测不达标就降快照档频率
Reference in New Issue View Git Blame Copy Permalink