第三章 CANoe仿真基础：CAPL语言入门
好，咱们进入第三章。这一章，我打算聊聊CAPL语言。
说实话，很多刚接触CANoe的朋友，一看到CAPL就头大。觉得它像C又不像C，语法看着眼熟，用起来却总踩坑。我当年刚入行时也是这样，第一次写CAPL，一个简单的on message事件，愣是折腾了一下午——因为忘了加分号。嗯，这种经历，估计不少人都体会过。
3.1 CAPL语言简介
CAPL，全称是Communication Access Programming Language。说白了，它就是Vector专门为CANoe开发的一种类C语言。你想想看，CANoe要模拟ECU、要分析总线、要自动测试，总得有个脚本语言来干这些活吧？CAPL就是干这个的。
它的语法和C语言非常像。有变量、有函数、有if-else、有while循环。但不一样的地方在于，CAPL是事件驱动的。什么意思呢？就是说，你的代码不是从头跑到尾，而是等着某个事件发生，然后才执行对应的处理函数。
我个人习惯把CAPL理解成「总线的管家」。你告诉它：当收到某个报文时做什么，当某个信号变化时做什么，当定时器到期时做什么。剩下的时间，它就在那等着，不干活。
核心特点：
- 类C语法，上手快
- 事件驱动，响应总线变化
- 专为汽车总线设计，原生支持CAN/LIN/FlexRay
- 运行在CANoe的仿真节点中
3.2 CAPL事件类型
事件类型，是CAPL的灵魂。你写CAPL程序，本质上就是在写各种事件处理函数。我遇到过不少新手，上来就想写个main函数——对不起，CAPL没有main。你得换个思路。
常用的CAPL事件类型，我整理了一下：
| 事件类型 | 关键字 | 触发时机 |
|---|---|---|
| 报文事件 | on message | 总线上收到指定报文时 |
| 信号事件 | on signal | 指定信号值变化时 |
| 定时器事件 | on timer | 定时器到期时 |
| 系统变量事件 | on sysvar | 系统变量值变化时 |
| 启动事件 | on start | 仿真开始时 |
| 停止事件 | on stopMeasurement | 仿真停止时 |
| 错误帧事件 | on errorFrame | 检测到错误帧时 |
你看，这些事件覆盖了总线仿真的方方面面。我最常用的是on message和on timer。为什么？因为大部分ECU仿真，就是「收到A报文，延时X毫秒，发送B报文」这种模式。on message负责收，on timer负责延时发。
小技巧：on start事件特别适合做初始化。比如设置波特率、启动定时器、初始化变量。我曾经有个项目，忘了在on start里初始化一个计数器，结果每次仿真重启，计数器还保留着上次的值，排查了好久才发现。
3.3 第一个CAPL程序
光说不练假把式。咱们写个最简单的CAPL程序，感受一下。
场景是这样的：我想让CANoe在仿真启动后，每隔1秒钟往总线上发一条CAN报文，ID是0x123，数据是0x01, 0x02, 0x03, 0x04。
/* 第一个CAPL程序：定时发送CAN报文 */
variables
{
msTimer myTimer; // 声明一个毫秒定时器
}
on start
{
setTimer(myTimer, 1000); // 启动定时器，1000ms = 1秒
write("仿真已启动，定时器开始工作");
}
on timer myTimer
{
message 0x123 msg; // 定义一个CAN报文，ID为0x123
msg.byte(0) = 0x01;
msg.byte(1) = 0x02;
msg.byte(2) = 0x03;
msg.byte(3) = 0x04;
msg.dlc = 4; // 数据长度
output(msg); // 发送到总线
setTimer(myTimer, 1000); // 重新启动定时器，实现循环
write("已发送报文 0x123");
}
这段代码，我解释一下：
- variables块：声明全局变量。这里声明了一个定时器myTimer。
- on start：仿真启动时执行一次。启动定时器，并打印一条消息。
- on timer myTimer：定时器到期时执行。构造报文、填充数据、发送、重新启动定时器。
注意最后那个setTimer。如果不重新启动，定时器只会触发一次。想要循环，就得在事件处理函数里再次调用setTimer。这个坑，我刚开始也踩过——定时器只触发了一次，我还以为代码写错了。
避坑指南：我曾经在写定时器循环时，忘记重新setTimer，结果报文只发了一次就停了。排查了半天，最后发现是逻辑问题。记住：定时器默认是一次性的，不是周期性的。想要周期执行，必须在事件处理函数末尾再次启动。
3.4 CAPL与系统变量的交互
系统变量，是CANoe里一个很强大的机制。它可以在CAPL、Panel、Test Module之间共享数据。说白了，它就是全局数据交换的桥梁。
为什么需要系统变量？你想想看，CAPL里定义的变量，只能在CAPL内部用。Panel上的控件，只能通过系统变量或信号来绑定。如果你想让一个Panel上的开关控制CAPL里的行为，怎么办？答案就是系统变量。
CAPL里操作系统变量，主要用两个函数：
- @sysvar::命名空间::变量名：读取系统变量的值
- putValue(sysvar, value)：写入系统变量的值
看个例子。假设我在CANoe里定义了一个系统变量：SysVar::Control::EnableSend，类型是整型。我想用这个变量来控制是否发送报文。
/* 使用系统变量控制报文发送 */
on sysvar SysVar::Control::EnableSend
{
if (@sysvar::SysVar::Control::EnableSend == 1)
{
write("系统变量 EnableSend 被置为1，开始发送");
setTimer(sendTimer, 100);
}
else
{
write("系统变量 EnableSend 被置为0，停止发送");
cancelTimer(sendTimer);
}
}
on timer sendTimer
{
// 发送报文的逻辑
// ...
setTimer(sendTimer, 100);
}
这段代码里，on sysvar事件监听系统变量的变化。当变量变为1时，启动定时器开始发送；变为0时，取消定时器停止发送。这样，你在Panel上放一个开关，绑定到EnableSend这个系统变量，就能通过开关控制CAPL的发送行为。
个人经验：我建议在系统变量的命名上，用清晰的层级结构。比如Control开头的放控制类变量，Status开头的放状态类变量。这样项目大了以后，查找和维护都方便。我曾经在一个项目里见过几十个系统变量全放在根命名空间下，那叫一个乱...
另外，系统变量还有一个好处：它可以在Write Window里实时查看和修改。调试的时候特别方便。你不需要重新编译，直接在Write Window里改系统变量的值，CAPL里的on sysvar事件就会触发。这个特性，我几乎每个项目都会用到。
好了，这一章的内容就到这里。CAPL的基础语法、事件类型、第一个程序、系统变量交互，这几个点掌握了，你就已经能写一些实用的仿真脚本了。下一章，咱们会深入CAPL的数据类型和函数，到时候再聊。