wangfq
ea29433633
- 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、异常分支先行、 纯平台/纯单机/混合三方案对比
128 lines
7.9 KiB
Markdown
128 lines
7.9 KiB
Markdown
# 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 设备侧补强
|
||
|
||
- **远程 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 抗变频器/电磁干扰 🎯（你的长期主目标）
|
||
|
||
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 设备侧补强（协议 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 字节区分格式的兼容方案，发布走配套矩阵 |
|