结论：太阳能车队两代车的 CAN 定义是 7 份按功能域切开的 DBC，而非一份整车文件。Daybreak 三份合计 23 条报文、58 条信号，HighNoon 四份合计 82 条报文、435 条信号。决定复用方式的不是总量，而是信号密度：bps.dbc 平均每条报文只挂 1.47 条信号，LightingCAN.dbc 则高达 9.50 条。
七份 DBC 的目录划分与规模落差
归档保留了 7 份字节互不相同的 DBC，分别位于上游 can/dbc/Daybreak/ 与 can/dbc/HighNoon/ 两个目录，并随附上游 docs/README.md 与顶层 MIT LICENSE。目录结构本身就是第一条信息：两代车并不共用一份网络定义，而是各自维护一整套，跨代之间没有版本继承关系。
按单文件看落差极大。最小的两份是 Daybreak/contactor.dbc 与 HighNoon/SteeringCAN.dbc，各只有 2 条报文；最大的 HighNoon/CarCAN.dbc 有 55 条报文、305 条信号，单份就占全部 105 条报文的一半以上、全部 493 条信号的 61.9%。把它当「车队 CAN 数据集」整体引用会严重失真——重心几乎全在一份文件上。
| 文件 | 所属代次 | 报文数 | 信号数 | 平均信号 / 报文 |
|---|---|---|---|---|
can/dbc/Daybreak/bps.dbc |
Daybreak | 15 | 22 | 1.47 |
can/dbc/Daybreak/contactor.dbc |
Daybreak | 2 | 11 | 5.50 |
can/dbc/Daybreak/controls.dbc |
Daybreak | 6 | 25 | 4.17 |
can/dbc/HighNoon/CarCAN.dbc |
HighNoon | 55 | 305 | 5.55 |
can/dbc/HighNoon/BPSCAN.dbc |
HighNoon | 19 | 63 | 3.32 |
can/dbc/HighNoon/LightingCAN.dbc |
HighNoon | 6 | 57 | 9.50 |
can/dbc/HighNoon/SteeringCAN.dbc |
HighNoon | 2 | 10 | 5.00 |
两代车的量级对比
Daybreak 侧三份共 23 条报文、58 条信号；HighNoon 侧四份共 82 条报文、435 条信号。后者的报文数约为前者的 3.6 倍，信号数约为 7.5 倍。也就是说，代次更替不只是加了几个节点，而是单位报文承载的信号量整体翻了一倍（2.52 对 5.30）。
| 代次 | 保留文件数 | 报文合计 | 信号合计 | 功能域 |
|---|---|---|---|---|
| Daybreak | 3 | 23 | 58 | 电池包（BPS）、接触器、整车控制 |
| HighNoon | 4 | 82 | 435 | 整车（CarCAN）、电池（BPSCAN）、灯光、转向 |
| 合计 | 7 | 105 | 493 | 七份文件，互不覆盖 |
信号密度决定了每份 DBC 的读法
把信号数除以报文数得到的密度，是这几份文件里最实用的判据。它不需要打开文件就能告诉你：这份定义主要承载的是离散状态位，还是打包好的连续测量量。密度小于 2 的文件基本是「一条报文一个状态」，读数容易但信息量有限；密度大于 9 的文件则几乎必然是位域打包，必须逐位拆解才能用。
| 密度档位 | 平均信号 / 报文 | 落在档位内的文件 | 典型形态 | 使用建议 |
|---|---|---|---|---|
| 稀疏（小于 2） | 1.47 | Daybreak/bps.dbc |
单条报文只承载少量状态或告警位 | 逐位确认含义，不宜当作连续测量量使用 |
| 中等（3 到 6） | 3.32、4.17、5.00、5.50、5.55 | HighNoon/BPSCAN.dbc、Daybreak/controls.dbc、HighNoon/SteeringCAN.dbc、Daybreak/contactor.dbc、HighNoon/CarCAN.dbc |
状态位与测量量混合 | 先抓运行日志看取值分布，再定缩放与偏移 |
| 密集（大于 9） | 9.50 | HighNoon/LightingCAN.dbc |
位域打包大量开关与枚举 | 按位拆解，逐位与实车现象对齐 |
需要强调一点：密度是归档方统计出的 BO_ 与 SG_ 行数之比，它反映的是文件的组织方式，不代表信号已被验证。归档说明写得很清楚——具体车辆修订版本、组件固件与信号准确性均未独立核验。
另一个不该忽略的落差在命名口径上。Daybreak 这一侧按功能块命名（bps、contactor、controls），HighNoon 这一侧则按物理总线命名（CarCAN、BPSCAN、LightingCAN、SteeringCAN）。两套口径不同，意味着不能靠文件名去推断两代车信号的对应关系，跨代比对只能落到逐信号的位与缩放上。
被拦下的文件与权利边界
这一批有五类文件没有进入归档，理由分两种，处理方式也不同。区分清楚很重要，因为「内容为空」与「权利未定」在工程上的后果完全不一样：前者是这份定义本来就没有可用信息，后者是信息可能存在但你不能用。
| 对象 | 拦下理由 | 性质 | 处理动作 |
|---|---|---|---|
HighNoon/DAqCAN.dbc |
不含任何报文与信号定义 | 内容为空 | 不收录 |
| Prohelion 组件文件 | 待原始厂商数据权利审查 | 权利未定 | 暂缓收录 |
| TPEE MPPT 组件文件 | 待原始厂商数据权利审查 | 权利未定 | 暂缓收录 |
| Elcon 组件文件 | 待原始厂商数据权利审查 | 权利未定 | 暂缓收录 |
| 电机控制器组件文件 | 待原始厂商数据权利审查 | 权利未定 | 暂缓收录 |
DAqCAN.dbc 值得单独记录：DAQ 这样的名字很容易让人以为它提供采集通道的完整定义，实际上归档时它是空文件。此外，保留下来的 CarCAN.dbc 是一份聚合文件，其中引用了 BPS、MPPT 等组件的信号，但这些信号的原始来源并未独立确认。
校验值与去重：怎样确认拿到的是同一份文件
归档为每份 DBC 都登记了 Git blob 与 SHA-256，快照修订为 04d2b3286f50d8f4119d4dc11b7344140f449d15。两者用途不同：Git blob 用于在仓库内部定位文件版本，SHA-256 用于在仓库之外确认取到的字节是否一致。做二次分发或长期存档时，两个值都该留。
| 文件 | Git blob | SHA-256 |
|---|---|---|
Daybreak/bps.dbc |
27f2385d0e3d316841e73db2b51631cdaad25637 |
b84a9d61eb276587241b39d24792c6cb1c42eb3b6efaad3ecfa727d279f8de32 |
Daybreak/contactor.dbc |
11745daca9b071eb933a59471ed630c79510eaaf |
58ae79db80cb0d20e3dd2b585231b72f8a50bf41800fdd0d0f1878200a134672 |
Daybreak/controls.dbc |
db2678346ce5e7ded982f56ecfa1971a87cfc96d |
5484aa7a1ea8e4cc3925d5e714d5f37e58bd022569a4a106fa28ce5d1e06ae32 |
HighNoon/CarCAN.dbc |
175bc244c2a250857d393a27db6ffff1451bb906 |
fdd068b71ee3c891e3733d716c8ab4b8df211187892f5ed351dfe4f6f3076fbd |
HighNoon/BPSCAN.dbc |
56048d7c6f5d0fad5c655be31f00af5516717a6c |
4619aa34e75767a5e05557fa092fa883f90045147cb5e875ac352e7d9f95031f |
HighNoon/LightingCAN.dbc |
bcae89e10bf3dcb9088465061ceaf4eefcfac5de |
0a5fdefcc7f4bdbe5fa23161b544561704600e0fb7675360551381872d2d06ed |
HighNoon/SteeringCAN.dbc |
a6548a3e1ea4e5ba12af333e622be03efd10f121 |
64e87d4458729fed6b3d9e8866e26d95d20d113be29dc117fe57fd449e37f6cb |
比对时还有一个容易踩的坑：同一份逻辑文件在不同检出环境下可能呈现 CRLF 与 LF 两种字节序，直接按字节比较会把同一份文件误判成两份。归档方在其他项目上正是用 CRLF 归一化来识别重复的，这里同样应当先归一化再比对。
工程侧：MCU 端口移植的四项硬要求
随附的上游文档描述的是一套面向定制 STM32 PCB 的共享嵌入式代码仓库，本身不是 CAN 数据集。它与 DBC 的关联在于：DBC 里定义的报文最终由这些 MCU 上的固件收发，端口是否移植完整，直接决定某条报文在车上有没有对应的实现。
顶层 Makefile 编译 STM32 所需的全部文件，但设计上不打算被直接调用，而应由另一个 Makefile 调用。测试统一放在 test/ 目录，测试文件以 _test.c 结尾，命令形如 make TEST=blinky PROJECT_TARGET=stm32g473xx，烧录用 make flash。CI 侧提供 makeAllTests.py，支持 -v、-t TESTS、-p PORTS、-h 四个选项，默认对所有端口编译全部测试。
一个合法端口必须齐备的四样东西
| 要素 | 命名规则 | 文档给出的示例 |
|---|---|---|
| 端口目录 | 位于 stm/stm32f4xx、stm/stm32l4xx 或 stm/stm32g4xx 之下，用 MCU 通用名命名 |
stm32f413、stm32l431 |
| 链接脚本 | 形如 STM32*_FLASH.ld，须包含处理器全名 |
STM32F413RHTx_FLASH.ld、STM32L431CBTx_FLASH.ld |
| 启动汇编 | startup_stm32 加四位系列与线别再加 xx，含向量表与基础异常处理（最关键的是 Reset_Handler） |
startup_stm32f413xx.s |
| 配置文件 | 以精确 MCU 名命名，空格分隔列出要禁用的 BSP 模块 | stm32l432kcu.cfg，内容 BSP_DISABLE=CAN UART ADC |
文档特别提醒：请核对 MCU 上实际存在的外设再填写 BSP_DISABLE，否则会遇到奇怪的构建错误。对 CAN 相关项目来说这条尤其重要——如果误把 CAN 写进禁用列表，DBC 里定义得再完整，固件侧也发不出对应的帧。
常见问题
两代车的 DBC 能不能按文件名直接对齐？
不能。Daybreak 侧的命名偏功能块（bps、contactor、controls），HighNoon 侧则偏物理总线（CarCAN、BPSCAN、LightingCAN、SteeringCAN），两套命名口径不同。加上 CarCAN.dbc 是聚合文件，其中引用的 BPS、MPPT 等组件信号的原始来源并未独立确认，跨代只能逐信号比对位与缩放，不能靠文件名推导。
为什么 bps.dbc 有 15 条报文却只有 22 条信号？
它平均每条报文只挂 1.47 条信号，是 7 份文件里最稀疏的一份。这种密度通常意味着报文主要承载状态或告警位，而不是连续测量量。在拿它做趋势分析之前，需要逐条确认每个位的含义与有效性，不能假定它自带完整的物理量定义。
DAqCAN.dbc 与四类组件文件为什么没被收录？
理由不同。DAqCAN.dbc 在归档时不含任何报文与信号定义，属于内容为空，因此不收录；Prohelion、TPEE MPPT、Elcon 与电机控制器这四类组件文件，则是因为原始厂商数据权利尚待审查而暂缓收录，属于权利未定。前者没有可用信息，后者可能有但你不能用。
CarCAN.dbc 有 305 条信号，能当作整车信号全集吗？
不能。归档说明指出它是聚合文件，引用了 BPS、MPPT 等组件的信号，而这些信号的原始来源未经独立确认；同时归档方明确写明，车辆修订版本、组件固件与信号准确性均未核验。它适合作为总线结构的索引，不能直接当作已验证的信号全集使用。
这些 DBC 对应的 MCU 端口移植要准备什么？
四样东西：一是在 stm/stm32f4xx、stm/stm32l4xx 或 stm/stm32g4xx 下以 MCU 通用名建立端口目录；二是形如 STM32*_FLASH.ld 且含处理器全名的链接脚本；三是 startup_stm32 加四位系列名加 xx 的启动汇编，内含向量表与 Reset_Handler；四是以精确 MCU 名命名的配置文件，用空格分隔列出要禁用的 BSP 模块，例如 BSP_DISABLE=CAN UART ADC。
延伸阅读
- 方程式赛车总线档案：53 条报文与多设备 DBC 合并 —— 同为大学生车队的多文件 DBC 组织方式
- Waterloo 2024CAR DBC 档案：115 个报文与 890 条信号 —— 另一份车队归档的量级与统计口径
- Western Formula Racing 的 PECAN 遥测链 —— 车队总线从车端到服务端的落地路径
- 公共 CAN/DBC 数据集怎么选：四类来源与三道筛查 —— 把「重心全在一份文件」这类失真提前筛出来
参考资料
- 项目 01 ——
public-can-dbc-datasets/additional/lhr-solar-daybreak-highnoon/SOURCE.md（7 份字节互异 DBC 的目录归属、逐文件报文与信号数、各文件 Git blob 与 SHA-256、DAqCAN.dbc 为空故不收录、四类组件文件待厂商数据权利审查、CarCAN.dbc 为聚合文件且信号来源未独立确认、车辆修订与固件未核验的说明） - 项目 01 ——
public-can-dbc-datasets/additional/lhr-solar-daybreak-highnoon/README.md（顶层 Makefile 需由另一 Makefile 调用、test 目录与 _test.c 命名约定、make TEST 与 PROJECT_TARGET 用法、make flash、makeAllTests.py 的四个 CI 选项、STM32 端口四要素与 BSP_DISABLE 配置格式）
免责声明
本文所述报文数、信号数与文件路径均来自公开开源仓库的说明文档，属第三方逆向工程与团队自建产物，未经独立实车核验，也不代表车辆制造商的官方数据。不同车辆修订版本、组件固件与市场可能存在差异。涉及安全相关用途时请仅作参考，并以实际测量与官方资料为准。
更新记录
- 2026-10-14 初稿
发表回复