CANoe仿真工程

操作面板是长这样的，总线上挂了两个模块，一个是开关，一个是指示灯。这里不去考虑鼠标点击开关的时候操作系统做的哪些乱七八糟的事情，虽然我们看见的按钮开与闭显示在屏幕上，操作系统也默默做了很多很多细枝末节的进程调度。逻辑上，我们只认为是开关打开和关闭是一个只有两个状态的变量，这里把变量定义为系统变量，这样读起来写起来会方便一些。

现在仿真工程要做的就是将两个模块挂到总线上，响应两个事件，一个是系统变量svSwitch的改变，一个是收到报文。开关变量改变后，事件函数将系统变量svSwitch的当前值读出来，复制给报文的信号bsSwitch，然后再将报文输出到总线上。收到报文后，相关的事件函数负责将报文的信号读出来，赋值给系统变量svLight，这个时候我们就可以看见灯泡的颜色改变，表示被打开或者被关闭。

在干完教程所说的一切之后我非常荣幸遇到了应答码错误，问题产生的原因是发送节点在发送完15位CRC校验码和CRC分隔符之后，在ACK SLot上发送一位隐形电平，接收节点此时在 ACK SLot上发送一位显性电平作为ACK响应，之后发送节点发送ACK分隔符以及EOF，没有收到ACK响应的即not ACK。

解决办法，有两个，感谢同事的帮忙。先说可靠的，勾选 TX Self-ACK。（只管发报文就好了）

再说不可靠的，我按照同事的提醒，连上了EPS作为真实节点，当然这里还需要修改通道，需要把canape，ees以及canoe都挂到新的端口下面，默认这个时候EPS是被唤醒了的。这个时候运行我自己的仿真工程，就会检测到很多莫名其妙的报文，看解析出来的ID就会发现和原本定义的差别很大。但是这个不重要，重要的是，这个时候不再报ACK应答错误了，真实节点应答了，但是真实节点并不需要开关节点发出的报文。但是不管怎样，报文是发出去了，发出去了之后，灯泡节点自然而然就响应了。这个时候，我就想关掉EPS试试看，然后就非常荣幸遇到了第二个错误Stuff Error，填充错误，节点在检测对象的时候违反填充规则，出现连续6位或者连续6位以上相同电平，判定为填充错误。

解决办法是我自己摸索出来的，我调低了波特率，改为100就行了。所以我的理解就是波特率太高了，所以会出现连续六位判定为相同电平的情况，这是我个人的猜测，还需要和别人讨论一下。（说实话，排除其他可能性，复现故障也是个技术活）

最后简单介绍一下创建工程。新建工程，新建数据库并添加，添加系统变量，绘制控制面板，添加ECU，写CAPL代码并编译。最后运行，可以在trace里面查看报文以及系统变量，打开控制面板控制并且观察。