Files

T

wangfq ea29433633 docs: 新增 ROADMAP — V1.0.0 之后的开发计划 (P0稳固→P1上云→P2算法→P3会车)

- P0 (v1.1.0): BLE透传重构收尾(0xC0三消费方真值表) + TODO清剿
  (loop_ok硬编码/MQTT接收溢出防护) + 工装回归清单
- P1 (v1.2.x): edc_server消费契约(先落库后ACK)、流量API、
  远程OTA方案评审、4G通道预研
- P2 (v2.0.0): 抗变频器干扰(先现场采CAPVD取证)、双线圈测速+
  车型粗分类、半截车双峰识别、方向判别
- P3 (v2.x): 会车控制 — 业务只认event_report、异常分支先行、
  纯平台/纯单机/混合三方案对比

2026-07-17 18:13:29 +08:00

7.9 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"。收尾必须核对三件事：

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

远程 OTA 评估：当前仅 BLE OTA + Loop ISP 串口透传。评估经网口/MQTT 下发固件的可行性（CH32V208 Flash 128KB 分区是否够 A/B，还是走"下载到外部存储再搬运"）——先出方案文档再动手
loop_data 增补字段（若 P1.1 分析需要）：如 Origin 绝对值上报，便于平台重建基线轨迹——走协议 V1.06 流程，两侧同版本配套
DBNMQTTool 同步：新增字段/命令的模拟与断言

P1.3 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 抗变频器/电磁干扰 🎯（你的长期主目标）

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

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 设备侧补强（协议 V1.06、OTA 方案落地）	edc_server 对接联调
v2.0.0	P2 算法深化（抗干扰 + 测速分类 + 方向）	现场干扰数据采集
v2.x	P3 会车控制	P1 平台 + P2 方向判别

风险与待现场验证

#	风险	应对
1	BLE 重构改动帧消费时序，复发"不同源"类 bug	P0.1 真值表 + 长车复测强制过
2	变频器干扰形态未知，算法方案可能推倒重来	先采数据后设计，不拍脑袋
3	CH32V208 资源（RAM/栈）不够支撑 OTA A/B	方案评审先行，必要时外部 Flash
4	协议再升版（V1.06）又是双侧死绑定	沿用 Len 字节区分格式的兼容方案，发布走配套矩阵

7.9 KiB Raw Blame History Unescape Escape