《嵌入式软件的时间分析》读书活动：6 第六章读书笔记-软件时间问题案例

hehung

《嵌入式软件的时间分析》读书活动：6 第六章读书笔记-软件时间问题案例 [复制链接]

第六章通过实践来讲解了实践分析的应用，每一节都提供了实际项目中的一个时间问题案例。可以清楚地了解到导致时间问题的各种不同的原因以及问题显现方式的差异。

目录如下：

第6章 软件时间问题案例 139
6.1 中断都是哪来的? 139
6.2 OSEK ECC：并非选择 140
6.3 重置17 min后发生偶发崩溃 143
6.4 遗漏及重复的传感器数据 144
6.5 拉着手刹去比赛 149
6.6 实际测量得到的 WCET 比静态代码分析得到的更大 150
6.7 有时候网络管理报文来得太早了 151
6.8 系列项目中无间断的时间分析 152
6.9 时间分析使得车厂节省了1200万欧元 152
6.10 总结 153

1. 时间分析问题案例总结

• 中断触发次数远高于预期的问题：预期中断10ms一次，但事实际上通过ECU下载后的第一个追踪表中发现7ms内中断就触发了高达200次。经过分析发现是中断的触发方式为引脚状态触发，实际上应该为边沿触发，修改成边沿触发，中断变成了10ms一次。该案例说明调度追踪表的重要性，从中可以发现一些调度异常的问题。
• OSEK ECC：并非最优选择：系统出现函数问题和通信不稳定的问题，作者发现是因为任务过载，软件中使用的是ECC任务（Extended Conformance Class：扩展任务），这种任务不会终止。原因为本来该10ms执行完成的任务，可能由于某种原因导致实际执行时间多于10ms，这样就会导致一些任务不能及时处理（每当运行服务发现时，负责通信的任务都具有非常高的CET），造成延时，出现上述问题。
• 重置17分钟后发生有发崩溃：问题现象是操作系统运行一段时间（大约17分钟后，34分钟后又会发生一次）就像“卡死”一样，不再继续执行任务。但是，中断依然继续发生。作者发现定时器的一次跳动需要237ns，位宽为32，表示大约每17分钟就会溢出一次。作者通过减少定时器中断触发周期来快速定位问题，发现在进入中断服务程序后，忘记了保存堆栈上的一个寄存器（这部分为手动编写），正确配置后，问题不再出现。
• 遗漏及重复的传感器数据：系统运行时，CAN报文会时不时的丢失，最初发现几分钟丢失一次，很有规律，但是对于不同的ECU，信号丢失的间隔时间不同。作者发现CAN报文接收周期为10ms，但是存在一定的抖动，不是精确的10ms一次，任务Runnable的执行也存在抖动，这样就会出现任务和接收的CAN报文不匹配导致问题。还存在CAN发送器的晶振工艺的差别，出现发送CAN报文周期为9.9999925ms，而控制器的接收周期为10.000038ms，这些问题的叠加，导致了数据的丢失和重复。作者还详细说明了一种模拟该问题的代码实现，可以看原文Page146。该问题有如下解决方法：

• • 同步：由于晶体无法同步，因此必须在软件中实现同步。如果发射器和接收器均使用AUTOSAR,则可以通过“Synchronized Time-Base Maager”进行同步。或者不将计算任务放在周期任务中，而是收到了CAN报文在进行计算，但是这样会存在于其他任务不同步的问题，但是可以通过这种方式检测接收的数据是否正确。也可以将发送器和接收器同步，ECU可以在每次接收的时候显式的发送数据请求。
  • 超采样：如果每个测量值发送两次，同时丢弃重复接收的测量值，则不会丢失任何数据。显然，这种方法增加了网络的负载，需要对算法进行相应的修改。

• 拉着手刹去比赛：客户发现控制单元软件不稳定，代码不能正常下载追踪图表，处理器出现了一般性过载导致的该问题，开启了P-Cache之后解决了该问题，开启之后，代码运行速度快了4倍，之前的代码被作者称为“拉着手刹行驶”。
• 实际测量得到的 WCET 比静态代码分析得到的更大：作者在使用基于追踪和测量的时间分析方法，将自己的结果与其他工具的结果进行比较发现净运行时间(CET，核心执行时间)的测量结果大于项目合作伙伴使用静态代码分析计算出的上限。换句话说，测得的值大于数学上可能的WCET(Worst-Case Execution Timo最坏情况执行时间)。原因是静态代码分析工具忘记为执行程序代码的闪存指定等待状态。因此，以前所有静态代码分析的结果都太低、太乐观了。这个故事说明只有通过对真实系统的观测或测量来验证这些方法的关键数据，才能确保模拟以及基于模型的分析可信。验证范围无须太广泛，但必须确模型或模拟环境在其核心方面充分反映现实情况。
• 有时候网络管理报文来得太早了：网络管理报文应每10ms发送一次。允许的偏差在1ms 以内。接收ECU 检查了此时间需求，偶尔发现两个连续消息之间的时间差小于3ms。原因是每当从一种应用模式切换到另一种应用模式时，该报文的周期性发送就变得“失步”。每个应用模式都有其自己的一组任务，上一个应用模式的最后一次调用与下一个应用模式的第一次调用之间的时间差过小，差了7ms。

2. 总结

该章节通过几个示例说明了软件时间分析的重要性，就像是看一个个小故事一样，比枯燥乏味的理论知识有意思的多。并且从这些故事中也能了解到一些问题的原因查找方法以及解决方法，还是有很多的收获。

该章节的第8,9两个章节主要是说明了时间分析的好处，作者通过实例说明了时间分析的好处，带来了性能上的有效以及CPU负载的有效降低，为公司节省成本。