4. CAPL与总线报文交互

CAPL 与总线交互的核心，是把“报文”当作可读写的对象。CANoe 为每条报文提供数据库（DBC）映射，CAPL 通过 message 变量、output()、on message、on signal 等机制完成发送、接收、信号读写、周期模拟、过滤与事件响应。理解这些机制的关键，是分清“报文层”和“信号层”两条操作路径：报文层直接操作字节与 DLC，信号层则依赖 DBC 的编码规则自动完成位域打包与解包。

报文发送：从直接赋值到周期触发

发送报文最直接的方式是声明一个与 DBC 中报文同名的 message 变量，赋值后调用 output()。例如 DBC 中定义了一条 ID 为 0x123、DLC 为 8 的报文 EngineStatus，CAPL 中可写：

message EngineStatus msg;
msg.dlc = 8;
msg.byte(0) = 0x10;
msg.byte(1) = 0x20;
output(msg);

若使用信号名，则无需手动计算位域：msg.EngineSpeed = 2500; 后 output(msg)，CAPL 会按 DBC 的起始位、长度、字节序和缩放因子自动编码。发送前应确认 msg.dlc 与 DBC 一致，否则接收端可能因长度不符而丢弃。对于需要周期性发送的报文，可在 on timer 或 on key 中调用 output()，也可使用 setTimer 配合 output() 实现自定义周期。

报文接收与信号读取

接收侧使用 on message 事件处理块。当总线上出现匹配 ID 的报文时，处理块被触发，参数 msg 即为该报文对象。读取信号时直接访问信号名：

on message EngineStatus
{
  float speed = this.EngineSpeed;
  if (speed > 3000)
    write("EngineSpeed high: %f", speed);
}

这里 this 指代当前触发报文。若同一 ID 存在多条报文，可用 on message 0x123 按 ID 匹配。接收处理应尽量简短，避免在 on message 中执行耗时循环，否则会阻塞 CAPL 事件队列，导致后续报文丢失或时间戳抖动。

信号读写与编码一致性

信号读写依赖 DBC 的编码定义。以 EngineSpeed 为例，若 DBC 定义为起始位 8、长度 16、小端（Intel）、因子 0.25、偏移 0，则写入 2500 时，CAPL 内部计算原始值 2500 / 0.25 = 10000，再按小端填入字节 1 和字节 2。读取时反向还原。若因子或偏移配置错误，读写值会整体偏移，因此调试时可用 write() 打印原始字节与信号值对照验证。对于多路复用信号，需先设置 msg.MuxSelector 再访问对应信号，否则读到的是无效值。

周期报文模拟

模拟 ECU 周期报文时，常用 on timer 配合 output()。例如模拟 10 ms 周期发送：

variables
{
  msTimer tSend;
  message EngineStatus msg;
}

on start
{
  setTimer(tSend, 10);
}

on timer tSend
{
  msg.EngineSpeed = 2500;
  msg.EngineTemp = 85;
  output(msg);
  setTimer(tSend, 10);
}

周期精度受 CAPL 调度和总线负载影响，10 ms 定时器实际抖动通常在毫秒级。若需更稳定的周期，可使用 setTimerCyclic 或 CANoe 的周期发送配置。模拟时应确保报文 ID、DLC、信号范围与真实节点一致，否则接收端可能触发超时或范围校验错误。

报文过滤与总线事件响应

过滤用于减少无关报文对 CAPL 的干扰。可在 on message 中通过 if 判断 ID 或信号值，也可在 CANoe 的 Filter 配置中按 ID 范围过滤。CAPL 侧更常见的做法是使用 on message * 捕获所有报文，再按条件筛选：

on message *
{
  if (this.id == 0x123)
    write("EngineStatus received");
}

总线事件响应还包括错误帧、总线关闭、超时等。CAPL 提供 on errorFrame、on busOff、on timer 等事件。例如监测到 EngineStatus 超过 100 ms 未更新时，可置位超时标志：

on message EngineStatus
{
  cancelTimer(tTimeout);
  setTimer(tTimeout, 100);
}

on timer tTimeout
{
  write("EngineStatus timeout!");
}

这种“接收即重置超时定时器”的模式，是总线事件响应中最常用的超时监测结构。它把“报文到达”与“超时判断”解耦，逻辑清晰且易于扩展。

实际工程中，发送与接收往往同时存在：CAPL 节点既模拟 ECU 周期发送，又监听其他节点报文并做超时判断。此时需注意 output() 与 on message 的时序关系——同一节点发送的报文通常不会触发自身的 on message，除非在 CANoe 中启用了回环或自接收配置。若需要自测，可显式调用处理函数或使用 on message 配合 output() 的模拟回环。

综合来看，CAPL 报文交互的要点可归纳为：发送侧关注 DLC、信号编码与周期触发；接收侧关注事件匹配、信号解码与处理耗时；过滤与超时则通过条件判断和定时器重置实现。掌握这些机制后，即可在 CANoe 中构建稳定的总线仿真与测试逻辑。