《嵌入式软件的时间分析》读书活动：9 第九章读书笔记-开发过程中的方法技巧

hehung

《嵌入式软件的时间分析》读书活动：9 第九章读书笔记-开发过程中的方法技巧 [复制链接]

本章节主要讲解开发过程中的一些方法和技巧。

目录如下：

第9章 开发过程中的方法技巧 202
9.1 与时间相关的各种需求 202
- 9.1.1 时间需求 202
- 9.1.2 对于方法和工具的需求 207
- 9.1.3 通用需求模板 208
9.2 开发期间的协作 209
9.3 软件运行时间概念、调度设计和操作系统配置 210
9.4 软件运行时间调试 210
9.5 运行时间优化 211
9.6 时间验证 211
- 9.6.1 测试阶段“分析” 212
- 9.6.2 测试阶段“POI（兴趣点）追踪” 212
- 9.6.3 测试阶段“情况” 212
- 9.6.4 测试阶段“凭经验确定空间” 212
9.7 尽早考虑后期的功能 213
9.8 终产品中的时间监测 214
9.9 一个好例子：Vitesco Technologies出品的CoReMa 215
9.10 总结 216

1. 时间需求

• 启动时间：重启后某些功能达到可用状态所经过的时间。对于大部分嵌入式系统，启动时间通常只有几毫秒。而大部分汽车ECU必须能够在100ms内启动并正常进行总线通信，即启动100ms以内必须能够发送和接收网络管理报文。
• 端到端时间需求：“端”是指事件链的两端。一端可以是传感器(例如刹车踏板)另一端可以是执行器(例如控制刹车灯的电力电子器件)。
• 允许的最大净运行时间(CET)。
• 周期性。大多数嵌入式系统，都包含必须以一定时间间隔定期执行的代码。如果实际时间间隔(时间差(DT))与所需的值相差太大，则控制算法将无法正常运行。控制器可能会变得不稳定并开始振荡，这对连接的任何机械系统都可能造成灾难性后果。
• 执行顺序：系统架构师知道Runnable 之间存在的依赖关系，们可以在核心之间或CPU任之间迁移多核系统的Runnable ，以提高系统利用率。
• 允许的最大响应时间(截止时间)：响应时间描述了从发出执行(启动)需求到执行完成(终止或结束)的时间跨度。
• 允许的最大数据龄期：对数据龄期的要求是与定义的任务和中断的响应时间是正交关系。
• 允许的最大 CPU 负载。

书中提到了可以通过访谈确定时间需求，按顺序采访涉及的函数开发人员、网络专家和集成人员获取时间需求，并给出了时间需求的文档格式（Page 204）。AUTOSAR可以使用TIMEX的形式将时间需求纳入需求规范，非AUTOSAR项目则可以以书面形式记录。

对方法和工具的要求（软件检测在功能安全相关的项目中是必要的）：

可以通过时间测量、追踪、代码仿真和/或静态代码分析来确定和监测 CET。对于调度层级的时间参数(例如响应时间、时间差 DT或 CPU 负载)，可以使用时间测量、追踪、调度模拟和/或静态调度分析。甚至在硬件和软件可用之前，就可以使用基于仿真和模型的方法，可以在较短的评估周期内快速评估不同的配置。通过测量和追踪，可以深入了解不受模型或仿真限制的可能存在的任何错误或缺点影响的真实系统。

2. 开发期间的协作

“项目合作伙伴”是指客户与供应商之间的关系。如果尽早讨论和指定有关合作的其他主题，则可以节省很多时间。

信息交换的时候还可以爆出知识产权（IP）。

3. 软件运行时间概念、调度设计和操作系统配置

一旦确定了具体的时间需求并选定了处理器，就可以处理软件运行时间概念。从概念出发，确定调度设计，最后得到操作系统配置结果。只有在大致了解哪些软件元素将在哪些处理核心上运行后，才能做出合理的负载估算。但是当前没有任何简单的规则可以用来将软件分发到处理器的不同核心。需要根据具体的需求来分配。

4. 软件运行时间调试

在出现明显错误的时间点停止软件，可以检查变量的内容，此外，在单步模式下，还可以追踪软件的流程。

深入了解真实系统的调度层级的最好办法是追踪。调度追踪图表可以将所有相关CPU上中断和任务的执行、线程和进程的执行以及相关数据可视化。

5. 时间验证

时间验证的成功与否取决于自动化时间测试的可用性。每晚进行一次自动测试，那么突然出现时间问题的可能性非常低。项目在每次提交或推送代码时(即提交更改以实施版本控制时)都会执行时间测试。

测试阶段“分析”：分析是指确定时间参数的过程。可以直接使用时间测量来进行，也可以间接使用追踪来进行。

测试阶段“POI(兴趣点)追踪”：某一些事件导致系统偏离正常状态运行，通常会或多或少地对调度产生重大影响，从时间分析的角度来看，此类事件为“POI”(兴趣点)，因为还必须确保在偏离正常状态期间，调度和运行时间保持正常。此类事件包括错误处理、执行诊断作业、执行附加功能或变换到另一种运行状态。（可以使用单元测试来检测）

测试阶段“极端情况”：对于极端情况的分析，可使用与实际硬件和环境无关的分析方法，例如调度拟和静态调度分析。

测试阶段“凭经验确定空间”：目标是我出软件在遇到时间问题之前有多大的空间。也可称"稳键性分析”。将可在运行时扩展的延迟函数内置于要执行分析的代码中。此延迟应可调节，以便消耗定义的CET。在重复执行相关测试时，调节延迟时间使此延迟函数的 CET 缓慢增加，并在此期间检查所有时间需求，尤其是有关 DT、RT和CPU 负载的时间需求。一旦违反时间需求，就会将延迟的当前 CET 记录为受影响代码节和所执行测试的测试结果。

6. 尽早考虑后期的功能

提前为后续功能添加占位符，代表功能所需的运行时间。未来功能的占位符将在后续版本实现。这种项目计划用于展望未来，并考虑为下一个版本规划的功能带来的影响。

这种方式还可以估计将来总线上的通信量。例如，如果使用了CAN总线，则在早期阶段可以按照预期传输模式发送计划的报文，因而可以暂时确定总线负载。

在插入所有占位符之后，可能会发现系统完全无法运行。这说明了如果没有实现时间优化，该软件未来版本将不稳定。如果没有占位符，则可能在未来出现问题的时候才注意到这一点，这个时候再优化将会非常耗时还难以优化。

7. 最终产品中的时间监测

一种时间验证方式是看门狗。看门狗需要定期重置计数器，没有重置计数器，则会复位。如果软件由于错误而“挂起”，则计数器不会复位，看门狗也将触发软件重置。软件应具有在初始化过程中确定上次复位原因的能力。

但是看门狗未重置并不意味着系统没有时间问题。看门狗只是最后的一道保障。所以需要常规时间测量作为基础，对时间的监控会更加清晰。用户可以在运行时确定和监测特定的时间参数。最小值和最大值可以有在非易失性存储器(例如NVRAM或EEPROM)中，并在以后访问入式系统时读出。如果非易失性存储器具有足够的空间，则可以在观测到不符合时间需求时永久储存追踪图表。

8. 总结

本证讲解了一些在开发过程中的方法技巧，但多数都是一些理论的方式，作者并没有给出具体的实现方法，所以具体的方法还需要读者自己去摸索。

最后一个章节，讲解了纬湃科技的软件开发方法，该公司有一套相关的工具用来统计每个软件组件在什么条件下使用了多少资源。纬湃科技能够在非常早期的阶段提供对未来调度的可靠估计，这也使得他们的开发人员很少需要处理不可预见的时间问题。