结论：ECT2026 的 network.dbc 不是挂在某个 App 旁边的说明文件，而是同时被 C 固件工具链与 Dart 解码目录消费的唯一真源：16 条报文、61 个信号。真正的使用门槛不在信号规模，而在两处容易被忽略的事实——归档方在该修订版里没有找到仓库许可证，且这个 DBC 描述的是一台生态马拉松原型车的自建网络，不是任何量产车型的原厂定义。
一份 DBC，两条生成链
这套舱内 telemetry 面板值得借鉴的地方在于：它没有让「协议定义」和「解析代码」各自演化。上游文件被固定为 dbc/network.dbc，一致性靠代码生成保证，而不是靠人工同步。
| 下游产物 | 生成方式 | 消费方 | 漂移风险 |
|---|---|---|---|
| C 语言解码源码 | python -m cantools generate_c_source --database-name network dbc/network.dbc |
ECT2026 车载固件 | 低，由 cantools 统一语义 |
| Dart 解码目录 | tools/generate_can_dart.py 生成并提交入库 |
Flutter App 解码路径 | 低，产物入版本库可 diff |
| 信号与状态映射 | lib/models/telemetry/can_bindings.dart 手工维护 |
App 状态树与 MQTT 指标名 | 中，改名需同步 broker 侧订阅 |
| Spool 与 CSV 镜像 | 由信号解码结果透传 | 本地会话 CSV 与 Grafana 面板 | 中，字段名变更会污染历史数据 |
这张表里真正需要人盯的只有第三、四行。前两行是「改 DBC 后跑一遍生成器」，机器保证一致；后两行是「改命名之后谁还依赖旧名」，只能靠约定。实际踩坑通常出现在 MQTT 指标名上——telemetry/eco_archers/events 这个导出主题一旦被外部订阅方写死，重命名就不再是本地重构，而是跨端协议变更。
DBC 的 61 个信号按功能分成踏板与辅助控制、电池包与辅助电源、车辆运动与时间、GPS、电机状态五类。这个切面恰好说明车辆本身的形态：它不是一条完整的动力总成总线，而是「驾驶员输入 + 能耗 + 位置 + 电机」的最小闭环，服务于节能赛事的能耗管理，而不是故障诊断或刷写。
数据流背后的三层持久性
这份文档的工程价值更在于它把「车里可能断电」「蜂窝链路可能断」「服务端可能挂」三件事分别做了兜底，且每一个参数都写死在文档里，可以直接对照自己的项目做取舍。
| 层级 | 取值 | 触发时机 | 失效后的表现 |
|---|---|---|---|
| 可读 CSV 镜像 | 缓冲写、每秒 flush；默认保留 7 天 | MQTT 服务启动时按保留天数裁剪 | 突发断电最多丢约 1 秒的行，不清空整份数据 |
| MQTT 本地 spool | 磁盘最多保留 50,000 个待发批次 | broker 不可达时堆积，恢复后重放 | 触及上限丢弃最旧批次，驾驶舱显示 SPOOL 并标记 DROP-OLDEST |
| 服务端 CSV 落盘 | csv_streamer.py，1 秒 fsync、不设保留策略 |
随写入持续进行 | 服务端异常时该侧数据缺失，但车端 spool 仍完整 |
三层的关键在于「各自独立」。车端 SQLite/WAL 的 edge_spool.db 面向链路可靠性，CSV 镜像面向现场可读性，服务端 1 秒 fsync 面向服务端掉电。把它们合成一层，任何一次裁剪或掉电都会同时击穿三个目标。
还有一个容易被忽略的行为：镜像的 7 天裁剪发生在 MQTT 服务启动时。如果设备长期离线不启动服务，策略并不会执行，磁盘占用会一直往上涨。做车机部署时，容量估算要按「上线时才裁剪」而不是「按自然时间滚动」来做。
怎么把这套后端跑起来
文档给了两条等价路径。一条是单容器：仓库里的 ops/backend/Dockerfile 把 TimescaleDB、Mosquitto、Telegraf 与 Grafana 打包进同一个镜像，运行在 tini 之下作为 PID 1，并把 Telegraf 固定在 1.31.x、Grafana 固定在 13.1.1，同时对数据库、broker 与 CSV 服务分别做健康检查；对外暴露 1883、5432、3000、8080 四个端口。另一条是 ops/local-stack/docker-compose.yml 的多容器栈。
两条路径的选择依据其实很朴素：单容器适合快速验证，代价是任一组件重启会牵动整容器；多容器适合长期运行，代价是编排与网络配置要自己维护。若只需要观测而不需要长期留存，还可以只跑 ops/backend/Dockerfile.csv-streamer 给出的最小镜像。
建议的顺序是先用样本数据跑通整条链路——docker build 之后直接 docker run，再用 db/scripts/verify_setup.sql 核对 hypertable 与索引，确认 telemetry_raw、sessions、laps 三张表的行数符合预期——最后才替换成自己的 DBC 与会话数据。跳过这一步，后面所有的曲线都可能是空跑。
什么时候不该直接搬用它
有三个边界必须提前划清。第一是权利状态：归档说明在检视的修订版中没有找到仓库许可证，因此该 DBC 与派生文件被作为私有离线研究副本保留，任何再分发或对外数据服务之前都需要先确认权利。第二是适用范围：它是项目专用车辆网络定义，把 ID 与信号布局套到量产车上属于无意义迁移。第三是证据强度：这一归档没有独立核验部署情况、信号缩放系数与物理量测量，61 个信号的单位与 factor 不应被当作可直接用于能耗结算的标定值。
常见问题
ECT2026 的 DBC 能用于量产车的 CAN 解析吗？
不能。它描述的是生态马拉松项目车自建的网络，覆盖踏板与辅助控制、电池包与辅助电源、车辆运动与时间、GPS、电机状态五类，共 16 条报文 61 个信号，属于项目专用定义。任何 ID 与信号布局都不能跨车型迁移。
本地 CSV 镜像的 7 天保留是怎么执行的？
由 MQTT 服务启动时按配置的保留天数裁剪，默认值是 7 天。这意味着裁剪时机与服务的启动强绑定：设备长时间离线且不启动服务时，镜像文件不会被清理，磁盘占用会持续增长，部署前需要按最坏情况估算容量。
MQTT 断连一段时间后数据会全部重放吗？
不一定。本地 spool 最多在磁盘保留 50,000 个待发批次，broker 恢复后自动重放；一旦触及这个上限，最旧的批次会被丢弃，同时驾驶舱显示 SPOOL 并标记 DROP-OLDEST，此时需要人工判断数据缺口的位置。
这份 DBC 现在适合公开再分发吗？
不适合。归档说明指出在检视的修订版中没有找到仓库许可证，虽然 Git blob 与 SHA-256 都已固定可用于比对，但权利状态未明。在确认权利之前，它只适合作为私有离线研究副本，不应集成进对外产品或公开发布的数据集。
延伸阅读
- 公共 CAN/DBC 数据集怎么选：四类来源与三道筛查 —— 判断一份项目专用 DBC 能否外推的第一道筛查
- 2330 份 DBC、294 个来源：公开 CAN 数据集的收录与分级 —— 大批量收录时如何处理许可证缺失的项目专用文件
- 车载信号为什么会说谎：TTL、源时间与 500 ms 新鲜度阈值 —— 为什么逐层缓存会让同一个信号出现两个时间戳
- 方程式赛车总线档案：53 条报文与多设备 DBC 合并 —— 同为赛事平台的官方 DBC 组织方式对照
参考资料
- 项目 01 ——
public-can-dbc-datasets/additional/lugilugi-ect2026/SOURCE.md（仓库与固定修订版、DBC blob 与 SHA-256、16 报文 61 信号、五类信号切面、未找到许可证与未独立核验的声明） - 项目 01 ——
public-can-dbc-datasets/additional/lugilugi-ect2026/README.md（App 栈与 MQTT 导出主题、spool 与 50,000 批上限、7 天保留与每秒 flush、单容器后端与四个端口、generate_can_dart.py与can_bindings.dart、cantools generate_c_source调用方式）
免责声明
本文引用的报文数量、信号数量与工具链调用方式均来自公开开源仓库的说明文件，属社区项目产物，未经独立实车核验，也不代表任何车辆制造商的官方定义。文中参数（如 50,000 批上限、7 天保留、每秒 flush、Telegraf 1.31.x 与 Grafana 13.1.1）为上游文档声明值，不同版本部署可能存在差异。涉及行车安全与能耗结算的判断请以实车测量为准。
更新记录
- 2026-10-14 初稿
发表回复