实际上，我对CANoe 12.0 SP5版本进行了实测，在此过程中，遭遇了诸如DBC文件加载出现报错情况、CAPL脚本编译遭遇失败情况、仿真节点面临无法通讯这种问题等诸多棘手情况。
第一步 搭建仿真工程并加载数据库
去将CANoe打开，把File点击一下，再点New，而后从当中选择CAN 500kBaud 1ch模板。在Simulation Setup窗口里，对着CAN总线用右键点击，选Add Network Node，给其命名为ECU_Sim。把这个节点进行双击，在CAPL Browser里写入基础报文发送脚本。下面点击菜单栏Home，再点Databases，然后选Add，把你的DBC文件拿去加载。在DBC路径选择时，务必确保文件不包含中文字符或空格。
新手要避开的坑是，常见的报错呈现为“Error loading DBC: unknown symbol”，其核心的原因在于, DBC内定义了并非标准的信号名。或者是使用了特殊字符，解决的办法是，打开DBC文件，运用CANdb++ Editor去检查所有的Signal名称。把@、#、$等符号去掉，全部变更为字母加下划线的格式，保存之后重新加载。
第二步 配置仿真节点并绑定报文
在Simulation Setup情境下，轻点ECU_Sim节点导致其被选中，在右侧属性面板内寻觅Configuration进而找到Assignment，把该节点同你已然加载的DBC里的某一ECU绑定。随后于Insert -> Network Node列表当中，查证你的节点已然关联了确切的CAN ID。紧接着返回至CAPL脚本，运用on message 0x123结构去撰写接收处理逻辑，关键参数波特率建议设定为500 kbps，这属于大多数车载网络的标准数值，其兼容性最佳，时序比较宽松，不容易出现丢帧现象。
【新手避坑】要是仿真过后总线窗口没有报文，那就先去检查一下System Variables是不是处于激活状态。在Home这个选项里，找到Measurement并且进入，然后找到System Variables，把与相应ECU对应的Tx变量那儿设置为Enable。还有一个平常比较常见的原因是Vector Hardware配置存在错误，在这里的话得在Hardware里面找到Network Hardware，确认一下CAN通道所选择的是Channel 1，并且Termination电阻已经开启了。
第三步 编写CAPL脚本实现逻辑完整流程
在CAPL浏览器里撰写一个呈循环模式发送的逻辑，举例来说，在on timer CyclicSend里进行output(message msg)的调用，每隔100毫秒发送一回，并且，在on key ‘a’事件当中触发一次手动报文发送。此部分的关键之处可谓是对比两种发送方案，有这样一种发射方案，是纯粹依靠定时器进行逐个步骤的循环发送，它是适宜应用于持续不断的心跳报文的；还有另外一种情况，是基于事件触发的，比如说在收到请求报文之后才去回复响应。在实际的工程当中，心跳类报文是采用定时器来处理的，诊断类报文则是依靠事件触发来处理的，要是这两种方式混合使用的话，就会导致总线负载过高或者造成响应延迟。
想要新手避开坑，最高频出现的报错是“CAPL: syntax error before ‘output’”。有完整的解决流程，其一，要去检查所有变量定义是不是在variables块内；其二，得确认message类型变量是否已用message 0x123 msg；这种形式进行定义；其三，要确保所有花括号是成对出现的；其四，需在菜单栏CAPL -> Compile当中来查看具体行号以此定位错误。还有一处不容易被发现的隐患：如果运用output(msg)，然而却未曾在on start当中开启定时器，那么脚本将不会自行运行，务必要在on start里添加上一句setTimer(CyclicSend,100);。
这套方法在标准CAN网络仿真里很稳定，然而却不适用于CAN FD或者LIN总线场景。要是你所使用的是CAN FD，那就得挑选对应的模板，并且在Hardware里启用CAN FD支持，不然波特率不匹配将会导致大量错误帧出现。替代的方案是直接运用CANoe自带的Virtual Bus模式，无需硬件同样能够让基础逻辑运行通畅，适宜前期验证。
