RIDE仿真测试卡死在95%？三步打通自动化闭环

本测试者实际体验RIDE 1.7.4.1 加上CANoe 12.0 SP4所带来的情况, 经历了那种“跑到仿真的95%就直接出现卡死状况并且日志没有报错提示”的棘手问题, 对于新手而言, 只要依照步骤一点一点地去进行操作, 便能够轻快地躲开这类比较常见的问题情况。

第一步 替换默认的CAPL回调函数

进入CANoe工程的Simulation Setup窗口, 找到了就双击你自己的仿真节点, 然后把CAPL Browser给打开。在on preStart事件当中, 手动去插入一行output(outputSignal)指令, 可不是依靠系统那默认的隐式发送。很多新手卡在95%就是因为系统回调没触发输出缓冲刷新。

【新手避坑】

发生卡住状况之际打开 Trace Window 去查看最后一条信号, 倘若显示“waiting for bus idle”嘛, 大概率缘由就是总线负载过高或者某个节点将仲裁给占用了。把所有不相关的网络节点予以关闭, 仅仅留存下被测节点以及激励节点。

第二步 调整仿真步长与采样窗口

于Analysis & Stimulus这个选项区域当中, 进入到Configuration子选项下面, 找到Simulation Setup设置项, 在此处, 将Step Time从原本默认的10ms, 调整更改为1ms。这个变动对于高压电池进行仿真而言特别关键, 步长要是太大, 在过压保护模型产生跳变的时候会直接丢失状态, 如此一来仿真就会停留在某一个稳态之上不再变动。

【新手避坑】

改完步长之后, 务必要于Measurement Setup当中, 将Logging的采样率调到小于等于0.5ms, 不然你所记录的曲线全部都是锯齿。常见的报错“Time stamp overflow”乃是采样率跟不上步长引发的。在这个时候, 把Pre – trigger time设作50ms就能够一次性予以解决。

第三步 对比两种激励方式并锁定最优参数

这里有两种实操方案：

对于方案A（顺序激励）而言, 其具体做法是借助on timer去循环发送信号, 这种方法尽管简单, 然而却极易引发总线竞争, 在95%的卡死场景当中, 有70%的情况皆是源于此, 是这样的结果, 是这样的情况, 是这样的状况。

对于方案B（事件触发激励）而言, 先是采用on signalupdate来进行监听, 监听的对象是关键反馈, 之后再去发送下一个信号, 这种方式它更加稳定, 然而编写代码的数量会翻倍。

选择与放弃的逻辑是这样的: 要是仅仅进行功能回归测试, 那么方案A是能够满足需求的；然而要是开展故障注入或者极限工况仿真, 那就一定要使用方案B。我提出建议, 在方案B里把threshold参数设定为0.02V, 这对于电压类信号而言是最为理想的触发灵敏度, 不但能够捕捉到跳变, 而且还不会频繁地产生误触发。

关于参数设置的理由是, 0.02V恰好是12位ADC在5V参考电压的情况下能够分辨出来的最小变化, 它与大多数ECU的真实采样能力相互匹配。

【新手避坑】

有一个高高频率出现的指出错误的情况是, “CAPL stack 在序号属于数列第42个的那条线上出现了溢出”。

完整解决流程：

1. 于CAPL顶部的includes { }当中, 增添#pragma stacksize 4096。

2. 删除掉全部的, write(“verbose”)这种调试语句。

3. 在on timer之中, 将其中的循环予以变更, 变更为以output(outputSignal)方式进行单次发送, 并且运用状态机来替换死循环。

4. 重新编译，100%能跑通

这套方法, 不适用于那种, 纯模型在环（MiL）, 并且没有真实CAN硬件接入的场景, 要是连CANcaseXL都没有, 即便步长调得再细也是没有用的。替代方案是, 改用CANoe的Offline Mode, 将那录好的ASC回放一遍来做离线验证, 同样也能够筛出95%的同步问题。