# can-mock

**Repository Path**: cc-customer-project/mock

## Basic Information

- **Project Name**: can-mock
- **Description**: No description available
- **Primary Language**: Python
- **License**: Not specified
- **Default Branch**: main
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 0
- **Created**: 2026-07-20
- **Last Updated**: 2026-07-20

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

# CAN总线信号模拟联调套件

基于《数据上报补充.xlsx》中C列筛选出的45条"CAN总线提供"记录生成。

## ⚠️ 先读这个：本套件解决的是什么问题，不解决什么问题

《数据上报补充.xlsx》给出的是**信号级**信息（物理量程、初始值、单位、raw值枚举含义），
**但完全没有给出报文级信息**：每个信号挂在哪个CAN仲裁ID（nodeId）上、在报文内第几字节、
占几个字节、大端还是小端、是否多个信号共享同一报文。这些正是此前反馈中指出的、
必须由对方补充的DBC文件才能确定的信息。

因此本套件做的是：
1. **能确定的部分**——根据表中给出的物理最小/最大值、以及部分信号自带的
   "raw值→物理值"对照说明（如 `0xFFFE:8191.75`），反推出每个信号的
   分辨率（resolution）和偏移量（offset），这部分换算是有依据的。
2. **不能确定、因此自行假设的部分**——CAN仲裁ID、字节偏移、字节长度、字节序。
   `can_signal_map.py` 里把每个信号独立分配了一个CAN ID（0x100起步，按系统分段），
   全部从第0字节开始、大端序、按需要的精度选1或2字节。**这套映射是自建的、
   仅用于打通"模拟发送→网关接收解析→ThingsBoard入库"这条链路，不是真车的实际映射。**
   拿到对方真实DBC文件后，必须用真实的nodeId/字节偏移替换掉这部分假设。

## 文件说明

| 文件 | 作用 |
| --- | --- |
| `can_signal_map.py` | **唯一数据源**：45个信号的key/物理量程/CAN映射（自建）/换算公式，模拟器和配置生成器都从这里读取，保证两边一致 |
| `can_simulator.py` | 模拟发送脚本，在虚拟CAN总线（vcan0）上按信号定义周期性发送45路CAN报文 |
| `generate_can_config.py` | 从`can_signal_map.py`自动生成`can_connector.json` |
| `can_connector.json` | 已生成好的ThingsBoard CAN连接器配置文件，可直接用 |

## 快速开始（Linux环境）

### 1. 创建虚拟CAN接口（无需真实硬件）

```bash
sudo modprobe vcan
sudo ip link add dev vcan0 type vcan
sudo ip link set up vcan0
```

### 2. 安装依赖

```bash
pip install python-can --break-system-packages
```

### 3. 启动模拟器（终端1）

```bash
python3 can_simulator.py --channel vcan0 --interval 1 --mode sweep
```

- `--mode sweep`：45路信号的值会在各自量程内做正弦波动，便于在ThingsBoard上观察曲线变化
- `--mode random`：每轮随机取值
- `--mode mid`：固定输出量程中间值，适合最简单的连通性验证
- `--once`：只发一轮就退出，适合快速验证某次修改

### 4. 把 `can_connector.json` 接入 thingsboard-gateway

将 `can_connector.json` 放入网关的连接器配置目录（通常是 `config/can.json`，具体路径以
你部署的 `tb_gateway.yaml` 中 `connectors` 一节的配置为准），并在网关主配置中启用该连接器
（参考此前整理的《CAN连接器配置》文档中"通用配置"部分的启用方式），然后启动/重启网关。

网关启动后应能在日志中看到从 `vcan0` 收到CAN帧、解析出45个key、并按MQTT上报到
ThingsBoard平台的telemetry数据。

### 5. 如果要重新生成配置（比如改了某个信号的映射）

直接改 `can_signal_map.py` 里对应信号的字段，然后：

```bash
python3 generate_can_config.py -o can_connector.json
```

`can_simulator.py` 会自动跟着用新的映射发送，两边永远保持一致。

## 关于生成的45个信号key与设备分组

按原表"系统（一级）"分成4个ThingsBoard设备：`动力系统`、`底盘系统`、`车身系统`、
`电气电子系统`，每个设备下的timeseries key沿用了原表"子系统（二级）"的英文缩写前缀
（如 `fuel_`、`edrive_`、`battery_`、`hybrid_`、`transmission_`、`driving_`、`steering_`、
`braking_`、`cabin_`、`low_voltage_`），具体每个信号的中文含义、量程、换算依据见
`can_signal_map.py` 中每条记录的 `desc` 和 `note` 字段。

## 已知的数据缺口（建议后续向对方确认）

以下几处，原表只给出了单个具体位置的信号（如左前轮、左前门），大概率实际车辆上
其余位置（右前/左后/右后轮、其余车门等）也有对应CAN信号，但本次筛选出的45条记录中
没有覆盖，需要向对方补充确认是否存在、CAN ID是多少：

- 胎压低报警：仅有"左前轮"（driving_tire_pressure_low_fl），右前/左后/右后未见
- 轮速信号：仅有"左前轮"（braking_wheel_speed_fl_rpm），右前/左后/右后未见
- 车门状态、门锁状态：仅有"左前门"（cabin_door_fl_state / cabin_door_fl_lock_state），
  其余车门未见
- `steering_angle_deg`（转向角）：原表给出的是分段公式（14bit环绕编码），本套件按
  标准16位有符号整数做了简化近似处理，量程基本吻合，但如果对方能提供准确的位定义，
  建议以真实定义为准重新校准