结论：TrevCAN 的树莓派节点是一个纯发送端：它只读 SocketCAN 原始帧，按 100 ms、最多 500 帧一批推给服务端的 /ingest/can，本身不做任何 DBC 解码，也从不向物理总线发帧。它的仿真模式覆盖 7 份 DBC 里的全部 347 条报文定义、共 460 种载荷布局，但生成的是合成覆盖数据，不是物理自洽的车辆模型。
车端与服务端的职责切分
这个项目的设计取舍非常明确：车上那台树莓派上不需要 TREVCAN-Explorer 检出目录里的任何文件。DBC 解码、InfluxDB 写入与前端全部跑在车下的服务器上。车端只剩一个瘦发送器，负责把 SocketCAN 上收到的原始帧打包送走。
这样切分带来两个直接后果。好处是车端依赖少、故障面小，换 DBC 不必动车上的部署；代价是车端无法做本地语义判断——它不知道自己送走的是电池单压还是转向角，任何与信号含义相关的逻辑都必须放到服务端。
| 环节 | 运行位置 | 职责 | 是否接触总线 |
|---|---|---|---|
| SocketCAN 帧读取 | 树莓派 | 从 can0 读取原始帧 |
只收不发 |
| 批处理与 HTTP 上报 | 树莓派 | 按 100 ms、最多 500 帧一批推到 /ingest/can |
否 |
| DBC 解码 | 车下服务器 | 用已启用且已排序的 DBC 解码收到的帧 | 否 |
| InfluxDB 与前端 | 车下服务器 | 落库与展示 | 否 |
启动前必须先做的一件事
按车辆实际波特率配置并拉起 can0，再启动发送器。这一步在文档里被放在显眼位置，而且与另一条约束互为补充：发送器只接收 CAN 流量，不会向物理总线发送。也就是说它天然是只听（listen-only）的，不可能因为软件缺陷把帧打进整车网络——前提是 can0 本身配置正确。
如果车上用的不是原生 SocketCAN 设备，可用 --interface 与 --channel 选择其它 python-can 接口，无需改动代码。
仿真模式：347 条报文与 460 种布局
带 --simulate-rate 启动时，程序不会打开任何 CAN 接口，也绝不在物理总线上发送。它用 cantools 把 trevcan_pi/dbcs/ 里 7 份当前 DBC 的定义编码成原始帧，全部 347 条报文定义都会被覆盖，包括每一个多路复用分支——完整一轮是 460 种载荷布局。
460 对 347 这个差值本身就是信息：平均每 3 条报文里就有 1 条带多路复用，多出来的 113 种布局全部来自复用分支。如果解码端只按报文 ID 取第一个布局，这部分帧一定会被解错。
| 参数 | 取值 | 含义 |
|---|---|---|
| 覆盖报文定义 | 347 | 7 份 DBC 的全部报文定义 |
| 每轮载荷布局 | 460 | 含每个多路复用分支 |
| 速率语义 | 总帧率 | --simulate-rate 是每秒总帧数，不是每条报文的帧率 |
| 20 Hz 一轮耗时 | 约 23 秒 | 460 帧除以 20 |
| 460 Hz 一轮耗时 | 约 1 秒 | 不含处理开销 |
数值在后续轮次中会变化，但始终落在每个信号在 DBC 内可表示的上下限之内；枚举值则在已定义的值之间轮转。命令与配置类报文只作为网络遥测计入，不代表车辆真的执行了这些命令。
交付语义：批处理、队列与不保证送达
这一段是整个项目里最需要在使用前读明白的部分。它把「尽力而为」写得很具体，而不是含糊带过。
| 机制 | 取值 | 溢出或失败时的行为 |
|---|---|---|
| 批处理窗口 | 100 ms | 窗口内最多打包 500 帧 |
| 队列容量 | 10,000 帧 | 溢出时丢弃最旧的帧，并在日志中计数 |
| HTTP 批次失败 | 不重放 | 失败或不确定的批次不做重放 |
| 中断恢复 | 自动恢复传输 | 但中断期间无磁盘积压，也无送达保证 |
| 停止方式 | SIGTERM 与 Ctrl-C | 未发送的帧可能被丢弃 |
把这些数字连起来看，缓冲深度是可以估出来的：批处理窗口为 100 ms、每批上限 500 帧，对应每秒 5000 帧的处理上限；队列 10,000 帧约等于 2 秒的缓冲。总线负载一旦持续超过这个量级，丢的就是最老的数据，而不是最新的——对事后分析来说这个取舍需要提前想清楚。
安全侧也有明确要求：共享令牌和数据必须用私有网络、VPN 或 HTTPS 保护；INFLUXDB_TOKEN 只留在服务端，不上车。
开机自启与仿真切换
车上部署的关键不是写服务文件，而是把秘密与路径分开管理：服务文件里只留用户名与检出路径，令牌与服务端地址放进单独的 env 文件并收紧权限。这样既避免了令牌进版本库，也让同一份服务定义能在不同车上复用。
| 步骤 | 操作 | 要点 |
|---|---|---|
| 改服务文件 | 编辑 systemd/trevcan-pi.service，填入自己的用户名与检出路径 |
服务文件本身不含令牌 |
| 写环境变量 | 在 /etc/trevcan-pi.env 写入 CAN_INGEST_TOKEN 与 TREVCAN_SERVER |
地址形如 http 加主机名再加 8000 端口 |
| 收紧权限 | sudo chmod 600 /etc/trevcan-pi.env |
仅 root 可读 |
| 安装并启动 | 复制到 /etc/systemd/system/，执行 daemon-reload 与 systemctl enable --now trevcan-pi |
--now 同时完成开机自启与立即启动 |
| 看日志 | sudo journalctl -u trevcan-pi -f |
队列溢出计数也在这里 |
| 切换仿真 | 把 ExecStart 里的 --channel can0 换成 --simulate-rate 20 |
迁移时须先停掉并禁用旧的全栈服务 |
两点值得单独记：CAN 接口的配置由系统单独管理，不由这个服务负责；测试用 python -m unittest discover -s tests 即可跑完，测试用 cantools 对每条报文与每个复用布局做编解码往返、校验信号覆盖与取值边界，并 mock HTTP 上报，不需要硬件、InfluxDB 或网络监听。
归档取舍：保留 2 份、剔除 5 份
归档最终只保留了两份字节互异的 BMS 与 DAQ 固件 DBC 快照，合计 277 行 BO_ 报文定义与 1,373 行 SG_ 信号定义。其余五份各有各的去向，理由不完全相同。
| 文件 | 处置 | 理由 |
|---|---|---|
trevcan_pi/dbcs/BMS-Firmware-RTOS-Complete.dbc |
保留 | 与已有归档无重复；Git blob 94d4168a43352804615ae7659ac04475d09c43a8 |
trevcan_pi/dbcs/DAQ-Firmware.dbc |
保留 | 与已有归档无重复；Git blob 45ee363c49bdeeea30d0824bc0243529e118bf99 |
Baby_MOBO.dbc |
剔除 | CRLF 归一化后与同批次已有归档中的文件完全相同 |
VCU.dbc |
剔除 | CRLF 归一化后与同批次已有归档中的文件完全相同 |
can9-database-01.09.dbc |
剔除 | CRLF 归一化后与同批次已有归档中的文件完全相同 |
Inverter.dbc、hvc.dbc |
剔除 | 已与同批次已有归档中的文件字节完全相同 |
examples/simulation.dbc |
说明为合成示例 | 仅用于演示的最小样例 |
需要注意：这里被剔除的文件只是不重复归档，不代表它们在工程上被弃用。仿真模式仍然按 7 份当前 DBC 覆盖 347 条报文定义。
两个 ID 撞车：0xC0
文档点出了一个原始 CAN 的结构性限制：逆变器的 Command_Message 与 VCU 的 VCU_INV_Command 共用标准 ID 0xC0。两份定义都会被仿真并打印告警，但服务端解码时用的是第一个匹配的已启用 DBC，无法按 ID 区分这两条定义。后果很直接：同一 ID 的帧解出来是命令还是状态，取决于你在服务端启用了哪份 DBC、以及它的排序。测试某个仪表盘前，必须确认启用并排好的是目标那份。
常见问题
这个树莓派节点会往车上发 CAN 帧吗？
不会。文档写明发送器只接收 CAN 流量，不向物理总线发送；仿真模式下更是完全不打开 CAN 接口、绝不在物理总线上发送。启动前还需按车辆实际波特率配置并拉起 can0，配置正确时它对整车网络是只听的。
仿真生成的 460 种布局能当真实车辆数据用吗？
不能。它覆盖 7 份 DBC 中全部 347 条报文定义、含每个多路复用分支共 460 种布局，但数值只是在 DBC 可表示范围内变化、枚举按定义值轮转，属合成覆盖数据而非物理自洽的车辆模型。命令与配置类报文也仅作为网络遥测计入。
为什么 0xC0 这个 ID 会解出两种含义？
因为原始 CAN 不携带 DBC 身份。逆变器的 Command_Message 与 VCU 的 VCU_INV_Command 共用标准 ID 0xC0，服务端按第一个匹配的已启用 DBC 解码，无法靠 ID 区分。因此要在服务端启用并排好你实际要测的那份 DBC，否则解出来的是另一条定义。
断网期间采集到的报文会补传吗？
不会。批处理最多 500 帧、窗口 100 ms；队列容量 10,000 帧，溢出时丢弃最旧帧并在日志计数；失败或不确定的 HTTP 批次不重放。传输会自动恢复，但中断期间没有磁盘积压，也不保证送达；SIGTERM 或 Ctrl-C 停止时未发送的帧同样可能被丢弃。
归档只留了两份 DBC，其余五份为什么没有？
原因分两类：Baby_MOBO.dbc、VCU.dbc 与 can9-database-01.09.dbc 在 CRLF 归一化后与同批次已有归档中的文件完全相同；Inverter.dbc 与 hvc.dbc 则已字节完全相同；examples/simulation.dbc 是合成示例。剔除只是避免重复归档，不代表这些文件在工程上被弃用。
延伸阅读
- Western Formula Racing 的 PECAN 遥测链 —— 同样是车端采集、车下解码的总线遥测架构
- 车载信号为什么会说谎：TTL、源时间与 500 ms 新鲜度阈值 —— 批处理窗口与新鲜度阈值之间的换算
- OBD 零百计时的链路标定：轮询周期、往返延迟与丢包率怎么测 —— 量化批次丢失对分析结论的影响
- 公共 CAN/DBC 数据集怎么选：四类来源与三道筛查 —— 判断合成数据与实测数据的分界
参考资料
- 项目 01 ——
public-can-dbc-datasets/additional/elidresnin-trevcan-pi/UPSTREAM_README.md（纯发送端定位与车端不依赖 Explorer 检出文件、venv 与 requirements 安装流程、CAN_INGEST_TOKEN 与 –server 参数、can0 需按车辆波特率预配置、只收不发、–interface 与 –channel、–simulate-rate 的总帧率语义、347 条报文定义与 460 种布局、0xC0 ID 冲突与服务端按首个匹配 DBC 解码、–dbc 顶层目录扫描规则、systemd 开机自启与 /etc/trevcan-pi.env、500 帧 / 100 ms 批处理与 10,000 帧队列及不保证送达、unittest 测试范围） - 项目 01 ——
public-can-dbc-datasets/additional/elidresnin-trevcan-pi/SOURCE.md（保留两份 BMS 与 DAQ 固件 DBC 快照、277 行 BO_ 与 1,373 行 SG_ 合计、快照修订 684065b99b79ae2748fe061ccd70aaabf2f94337 与采集日期 2026-10-04、三份文件因 CRLF 归一化重复被剔除、两份已字节相同、examples/simulation.dbc 为合成示例、两份文件各自的 Git blob 与 SHA-256、未找到仓库许可证与原始组件归属故仅作私有离线研究副本）
免责声明
本文所述批处理参数、队列容量、报文与布局数量、命令与路径均来自公开开源仓库的说明文档，属第三方工程产物，未经独立实车核验。归档方已声明仿真数据为合成覆盖数据而非物理自洽的车辆模型，硬件适配与信号正确性未经检查，且该快照未找到仓库许可证与原始组件归属，仅应作为私有离线研究副本保留。涉及安全相关用途时请以实际测量与官方资料为准。
更新记录
- 2026-10-14 初稿
发表回复