zjk 5b8f0b1421 锂电池改用 BCU-MBMS CAN 协议按节点解析 + bcu_node 解析数据落库 + 板卡对时脚本
- pCCU/CanBms:按《04KT38电池BCU-MBMS通信(CAN)定义》重写解码,
  BmsStatus 单状态模型改为 BcuNodeStatus 多节点模型(0x10XX00YY,
  节点地址 01~36h),支持 0x0000 电压/电流/SOC/告警码、0x0001 单体
  电压、0x0002 单体温度、0x0003 继电器、0x0006 绝缘/端口电压、
  0x0010 告警位(附录1 中文码表)六类报文
- 平均单体温度偏移修正:协议文档 BYTE5 写"偏移0"有误,实测固件与
  最高/最低一致均带 -40℃ 偏移(实车 0x10020002 原始 68/69 减 40 后
  为 28/29℃,落在最低28~最高30区间内,按文档直读则超出物理范围)
- pCCU/DbStore:新增 bcu_node 解析数据表,锂电池 BMS 报文每帧落一行
  节点合成状态(原 comm_log 仅原始帧,BMS/CAN 帧此前不落 pCCU 库),
  buildReport 增加 BMS 记录数
- 快照/网页:BCU 按节点分组展示(告警位解析中文含义、数据 age),
  PM 状态报文锂电池/应急电池卡片
- pPowerManger:新增 iport 本地输入端口配置(UDP bind 延迟到
  OnStartUp 读取配置后执行,保证 iport/ccuhost/ccuport 生效),
  各 mission 文件补充注释
- test:CAN BCU 解码用例按新协议/新偏移更新(实车抓包 + 文档示例值),
  133 项全部通过
- docs:删除旧 BMS 协议(xlsx/20230324docx),归档 04KT38 BCU-MBMS
  CAN 定义、配电控制器通信协议 20260824、配电系统 CAN 通讯协议
- scripts:新增 sync-board-time.sh,223 板卡(RK3588)时间校正
  (本机为基准 + RTT 折半补偿对时,尽力写 RTC,支持 status/--time)
2026-09-01 12:58:33 +08:00
2026-01-19 21:52:26 +08:00
2025-04-07 21:18:02 +08:00
2024-10-22 17:28:15 +08:00
2025-09-12 11:35:17 +08:00
2025-06-06 13:28:05 +08:00
2025-05-23 15:38:23 +08:00
2025-07-02 16:20:36 +08:00

H100PowerManger

H100 能源管理程序

CI

测试报告

每次 CI 运行后自动生成测试报告:

自动化测试(PowerManger)

CI 在 aarch64 (QEMU) 环境下运行两类测试,不改动任何 src/ 生产代码:

单元测试(GoogleTest,PowerMangerTests,56 例)

  • DriverTest:10 个工况的设备表生成(STANDBY/岸基备航/水中备航/巡航/高速/上浮下潜/浮调/水下侦查/水面侦查/DJ)+ 设备状态读写 + JSON 往返
  • SystemDataTest:4 类配电/CCU 反馈的故障检测(断路器 0x55/0xAA/0x5A 映射、绝缘低、电源失电、漏水、DCDC、继电器位提取、缩放)+ 故障码集合/等级 + 漏水位
  • FaultMapTest:锂电池故障表(54) / 配电故障表(45) 完整性
  • UpmsgTest:上位机/外部通信 JSON 消息解析与序列化往返
  • UdpCommTest:UDP 校验和 / 消息头识别 / 校验解析 / 日期
  • PmSysvariableTest:#pragma pack(1) 协议结构体大小/偏移 + 枚举完整性
  • SqliteTest:用裸 sqlite3 读回校验 10 个 insertData 写入

集成测试

  • 冒烟:MOOSDB + pPowerManger 拉起存活
  • UDP 回环:udpFeeder 发送真实 CCU 反馈 → 校验 power_data.db 落行(验证 UDP→SystemData→SQLite 全链路)

本地跑测试:需要 GoogleTest(git clone https://gitea2.zhaojingkui.xyz/zjk/googletest.git 后 cmake && make && make install),然后 ./build.sh 即可。

构建产物(Gitea Releases,手动部署)

CI 构建的 aarch64 二进制(RK3588 / Ubuntu 22.04,板卡实测为 Orange Pi 5 Plus 的 Jammy 系统)会发布到 Gitea Releases,供手动下载部署:

  • 版本号 Release:推送 v* tag(如 v1.0.0)时创建,正式版 → https://gitea2.zhaojingkui.xyz/zjk/H100PowerManger/releases/tag/v1.0.0
  • latest Release(测试):每次 main push 时更新,标记为预发布(测试用) → https://gitea2.zhaojingkui.xyz/zjk/H100PowerManger/releases/tag/latest

发布流程(CI 自动执行,仅测试通过后发布)

Publish release / Publish latest release 步骤(if: success(),即构建 + 测试全部通过才发布)用 ${{ secrets.CI_TOKEN }} 调 Gitea API 完成:

  1. 创建 Release:POST /releases
  2. 删除旧 latest(仅 latest):DELETE /releases/tags/latest
  3. 上传附件:POST /releases/{id}/assets?name=pPowerManger(multipart 字段 attachment)
  4. 按 github.ref 分支处理:
    • refs/tags/v* → 直接为该 tag 创建版本号 Release
    • refs/heads/main → git tag -f latest && git push -f origin latest,删除旧 latest Release,重建为 prerelease,再上传二进制
  5. Release body 自动带上:commit / 时间 / 测试报告链接 / 手动部署命令

手动部署到板卡

从 Releases 页面下载 pPowerManger 后,手动推送到板卡(仅推送,不自动重启):

rsync -avz pPowerManger root@192.168.0.223:/root/work/moos_ws/moos-ivp-extend/bin/pPowerManger
S
Description
No description provided
Readme
33 MiB
Languages
C 79%
C++ 14.4%
Python 5.4%
Shell 0.6%
HTML 0.4%
Other 0.2%