结论：这份「车型 CAN 数据档案」的对象是 Tesla Model3 的一台 CANoe / CAPL 仿真工程，不是一台真实车辆：它用三份逆向得来的 DBC（Battery / Thermal / Drive）和一条「电池异常 → 热管理响应 → 扭矩降额」的因果链，在总线上造出约 67 条报文、其中 8 条为核心周期报文。总线为 500 kBaud 经典 CAN、11 位标准帧，另叠加一条 Ethernet / DoIP 诊断通道，CAN 侧用标准 ISO-TP（CanTp）承载 UDS。关键结论——例如硬切断后扭矩以 kHardCutoffTau=0.4s 衰减、集中式架构下 bmsContactorState 稳定在 80.500s——全部来自仿真，不能当作实车测量，也不能外推到其他 Model3 车或年款。
车辆与适用范围
源文档是一套围绕仿真节点搭建的工程：三个业务 ECU（Battery / Thermal / Drive）实现核心因果链，一个独立的 SafetyMonitor 节点只监听总线，外加测试驱动与 DoIP 网关/以太网诊断。以下范围只对应这套仿真的内部设定。
| 项 | 内容 |
|---|---|
| 车型 | Tesla Model3（仿真建模对象，非实车采集） |
| 年款 / 市场版本 | 源文档未确认；DBC 名称仅区分 Battery / Drive / Thermal 三个域 |
| ECU / 改装状态 | 仿真态：Battery_ECU、ThermalCtrl_ECU、DriveInverter_ECU、SafetyMonitor_ECU 四个 CAPL 节点 |
| 采集跨度 | 约 121.5 分钟的四阶段自动化场景（Phase0 正常基线 / Phase1 冷被动 / Phase2 热被动软限 / Phase3 热主动硬切断） |
| 适用范围 | 仅限该仿真工程产出的 .asc 日志与其下游分析；不代表真实 Model3 的任何总线行为 |
总线与寻址
总线侧为经典 CAN，叠加以太网诊断扩展。源文档给出的寻址与帧格式信息如下；需要注意，DBC 本身是逆向产物，其对报文周期的标注并不完整。
| 项 | 内容 |
|---|---|
| 物理层 / 比特率 | CAN 500 kBaud；另设一条 Ethernet 通道（DoIP / OSEK_TP 节点层 DLL） |
| 寻址 / 帧格式 | 经典 CAN；总线负载按 CAN 2.0A 标准帧 47 位开销计算，即 11 位标识符 |
| CAN FD | 源文档未使用 CAN FD；诊断走 CAN 侧 ISO-TP（CanTp）与以太网 DoIP |
| 报文规模 | 三份 DBC 去重后共 67 条报文；CAPL 仿真实际周期发送 8 条核心报文 |
| 周期标注完整性 | 67 条中 45 条没有 GenMsgCycleTime，为原始逆向 DBC 的数据缺口 |
已解码信号
下表抽取源文档中最有代表性的条目。位置一列尽量保留源文档的 ID 与消息名写法；「证据」一列注明来自 DBC、CAPL 设定还是分析脚本的输出口径。凡源文档标注为「未完全根因」或「数据缺口」的，均原样保留。
| 信号 | 位置（ID / 字节域） | 解码 | 证据 |
|---|---|---|---|
| BMSmaxPackTemperature | Battery 域锚点信号 | 电池包最高温度，跨域因果链的温度锚点 | anchor_signals.csv；Phase0 拟合归一化 |
| BMS_maxDischargePower | ID252BMS_powerAvailable（十进制 594） |
最大放电功率，驱动域软限跟踪的输入 | DBC；CAPL 设定 |
| VCFRONT_coolantFlowBatActual | Thermal 域锚点信号 | 电池冷却液实际流量 | anchor_signals.csv |
| CMP_speedRPM | ID227CMP_state |
压缩机转速档位；三级压缩机转速状态机 | CAPL 设定；故障注入用例 |
| DIR_torqueCommand | Drive 域锚点信号 | 驱动扭矩指令；硬切断后按指数衰减到近零 | anchor_signals.csv；kHardCutoffTau=0.4s |
| BMS_contactorState | Battery 域广播 | 接触器状态；==1 时 Thermal 冻结全部热信号 |
CAPL 设定；SafetyMonitor Rule 1/5 |
| ID312BMSthermal 广播 | ID312BMSthermal（十进制 786） |
电池热报文；被抑制即触发 SafetyMonitor 通信超时 | CAPL 设定；故障注入用例 |
| gFlowRequest | Simulink 信号链（1000 ms 周期） | 流量请求；延迟/量化行为最高约 1.92s | Simulink 验证；已调查未完全根因 |
| gCompressorRPM | Simulink Drive 分支 | 随机游走驱动的压缩机转速 | Stateflow；随机序列复现问题见边界 |
| gTorqueCommand | Simulink Drive 分支 | 随机游走驱动的扭矩指令 | Stateflow；同上 |
| targetPower（稳态） | Simulink 两架构对照 | 稳态目标功率，两架构均为 40.0000 | Verify_key_metrics.m 校验 |
| HardCutoff.Opening 时长 | 状态机（Battery_ECU） | 硬切断 OPENING→OPEN 过渡，精确 200ms | CAPL 设定；Simulink 复核 |
| UDS 0x22 ReadDataByIdentifier | Battery_ECU 诊断栈 | 5 个 DID，含两个由其他 ECU 拥有的网关式 DID（被动缓存） | CAPL；UDS_DiagnosticsTest 14 个检查点 |
| UDS 0x19 / 0x14 与 0x7F | Battery_ECU 诊断栈 | 读/清 DTC（子功能 0x02/0x04）；7 种否定响应场景 | CAPL；Freeze Frame 用例 |
读取方法与注意事项
解析链以 cantools 为基础。源文档明确：默认采用流式解析以适配大日志，小于 200 MB 时才用 --in-memory；解码后的长表可再重采样到 100ms 均匀网格，但真实逐帧时间戳只在长表里，做周期核验必须用长表而非重采样结果。引用因果滞后结论时，源文档要求只引用 causal_lag_analysis_HIGH_CONFIDENCE_ONLY.csv。
数据完整性有专门的检查脚本，给出三种判定：CLEAN（可直接使用）、ISOLATED, LIKELY OK（不超过 5 个孤立点，建议抽查）、CORRUPTED（存在大段连续异常，不可直接使用）。源文档建议在 LSTM 训练或引用因果滞后结论之前先跑这一检查，用于识别已知的 CAPL/CANoe 信号解码缺陷是否复现。
异常检测模块有一处容易踩的坑：训练与评估的 --val-fraction、--block-size、--seed 必须完全一致，否则 Phase0 基线会落在模型已训练过的窗口上，静默低估基线误差。归一化只在 Phase0 上拟合，以避免把异常期统计量泄漏进「正常」基线。总线负载侧，长表须先按 (timestamp_s, frame_id) 去重，否则到达帧会被按信号重复计数，严重高估发送频率。
时延分析脚本不接收命令行参数，输入文件名固定为 CAN.asc 与 Eth.asc；它以两个文件各自的时间戳相减来定义时延，而不是信任 UDP 载荷内的 Timestamp 字段（后者存在约 0.5ms 的整毫秒截断偏置）。匹配采用精确 RawValue 相等、平分时取最近在前的策略，源文档明确这是尽力而为、不保证唯一的匹配。
证据等级与边界
本档案的全部信号都是仿真观测，没有任何实车旁证。DBC 是逆向结果，45/67 条报文缺少周期标注，因此总线负载只能给出「未填充下界」与「+20% 填充上界」两个口径，30%/50% 也只是业界经验阈值、非强制标准。Simulink 侧两架构对照给出确定性结论：集中式架构的 bmsContactorState 在 11 次重复仿真中稳定到达 80.500s（零方差），分布式架构则落在 0–110ms、10ms 栅格的延迟窗内，且在受控变量测试下确认延迟来自接收域自身采样节拍。
已知缺陷必须原样保留。其一，Battery_ECU.can 内部使用了两个互不同步的 100ms 定时器，CAPL 不定义其相对触发顺序，在窄时序巧合下会令 SafetyMonitor 的 Rule 1 在模拟上电复位后短暂重触发，源文档将其记为未修复的开放问题（低优先级、影响面窄），根因已分析但未获得带时间戳的证据确认。其二，Simulink 中 Stateflow 的随机游走函数在独立 sim() 调用间复现同一随机序列，机制未定位，只影响随机游走驱动信号，不影响上述确定性结论。其三，1000ms 周期的 gFlowRequest 链出现最高约 1.92s 的延迟/量化，与其余信号的 0–110ms 模式不一致，已调查但未完全根因、被降级搁置。
不能外推的部分：本文所有数值限定在这套仿真的设定与日志；40.0000、200ms、80.500s 等均属工程参数，不构成对任何真实 Model3 的描述。源文档未提供对车辆安全机制的绕过方法，且不建议尝试；本文只讨论仿真工程的公开文档。
常见问题
这是不是一台真实 Model3 的数据？
不是。它是 CANoe/CAPL 仿真工程：三个业务 ECU 加一个独立监听节点，用逆向 DBC 复现「电池异常 → 热响应 → 扭矩降额」的因果链。所有信号与节拍都来自仿真设定，源文档未包含任何实车采集。
为什么 67 条报文里只有 8 条能算总线负载？
因为逆向 DBC 中 45 条报文没有 GenMsgCycleTime，且核心 8 条里还有两条在 DBC 里根本没有周期。源文档的做法是以 CAPL 的 setTimer() 调用作为周期的唯一真实来源，并逐行标注对应的 CAPL 源码位置以便追溯。
引用因果滞后结论时要注意什么？
源文档要求只引用 HIGH_CONFIDENCE_ONLY 的结果文件，并在引用前先跑数据完整性检查以排除已知的解码缺陷；LSTM 训练/评估的 val-fraction、block-size、seed 必须一致，否则基线会被静默低估。峰值与时长在本数据集中还存在部分混淆。
SafetyMonitor 的 Rule 1 为什么会误触发？
因为 Battery_ECU.can 内部两个不同步的 100ms 定时器相对顺序未定义，在窄时序巧合下会在模拟上电复位后短暂重触发。源文档标记为开放且未修复，根因已分析但未经带时间戳的证据确认，影响面窄。
延伸阅读
- 离线与实时数据管线：日志回放如何保证结论可复算 —— 与本文
.asc解析、100ms 重采样与可复算脚本的关系。 - CAN 报文解析的「健康位」在说什么：校验、计数器与总线空窗 —— 对应本文的计数器/校验与 SafetyMonitor 通信超时监督。
- 车载信号为什么会说谎：TTL、源时间与 500 ms 新鲜度阈值 —— 解释本文「缓存 DID」「跨域滞后」的数据新鲜度问题。
- CAN FD 与经典 CAN 的安全模式差异 —— 对照本文为何在经典 CAN 上叠加 DoIP 而非改用 CAN FD。
- 公开 DBC 数据集的整理：来源、版本与可信度分层 —— 与本文「45/67 条缺周期」的 DBC 缺口同题。
参考资料
- 项目 01 ——
public-can-dbc-datasets/additional/model3-can-simulation/README.md（本项目车型档案主来源：节点与因果链、DBC 与锚点信号、总线负载、时延分析与 Simulink 对照）。
说明：本文整理自第三方开源项目的公开文档，仅代表该文档所记录的单个车辆样本，不代表同型号全系车型。CAN 与诊断操作存在风险，任何实车操作前请自行复核并遵守当地法规。
更新记录
首次发布 2026-10-11 最近核对：2026-10-11
发表回复