27、嵌入式软件开发中的时序管理与验证

html8

于 2025-09-25 13:19:11 发布

阅读量53

点赞数

CC 4.0 BY-SA版权

分类专栏：嵌入式软件定时之道文章标签：时序管理嵌入式软件开发自动化测试

本文链接：https://blog.youkuaiyun.com/html8/article/details/152207303

嵌入式软件定时之道专栏收录该内容

30 篇文章 ¥499.90

订阅专栏¥69.90

会员秒杀 ¥9.9 重磅福利

超级会员免费看

嵌入式软件开发中的时序管理与验证

1. 时序验证

时序验证的有效性依赖于自动化时序测试的可用性。若有自动化测试且每晚执行，遇到意外时序问题的概率会极低。如今，越来越多的项目更进一步，每次提交或推送代码（即对版本控制进行更改时）都会运行时序测试，这种“持续集成”方法在功能测试中已得到广泛应用。

自动化测试可在不同环境中实现。单元测试通常在 x86 架构上运行，即本地 PC 或测试服务器。单元测试可相对轻松地扩展，除了功能测试外，还能初步捕获和监控被测函数的执行时间（CET），从而在不显著延长单元测试时间的情况下实现代码级别的性能分析。

将时序测试与功能测试并行的理念也可应用于更高层次。系统测试在硬件在环（HIL）和子系统测试站进行，同时也能进行性能分析。除了 CET，获取和监控调度级别的时序参数（如 CPU 负载、响应时间（RT）、时间差（DT）和净空闲时间（NST））也是可行且有用的。

HIL 提供的时序测试可分为以下几个测试阶段：

1.1 测试阶段“性能分析”

性能分析是确定时序参数的过程，可通过直接的时序测量或间接的跟踪来完成。各个功能测试针对特定功能和操作状态，通常为每个测试记录一组单独的性能分析数据，并与功能测试结果一起存储。部分测试会包含特定于该测试的时序参数，例如，检查测试部分中的所有诊断作业时，至少应测量诊断处理程序的 CET 以及每个作业从请求到执行的总时长。

1.2 测试阶段“兴趣点跟踪（POI Tracing）”

嵌入式系统大多时间处于正常状态，在此状态下，控制器可执行工作、路由消息、等待输入等。但有些事件会使系统偏离正常状态，对调度产生不同程度的影响，从时序分析的角度看，这些事件就是“兴趣点（POI）”。

这类事件包括错误处理、诊断作业执行、额外功能执行或操作状态更改等。单元测试的目标之一是有针对性地测试异常情况，兴趣点跟踪也基于此理念。在自动化测试中特意引发 POI，并创建跟踪记录其调度情况。若出现异常，可通过检查跟踪记录或自动检查预先设定的时序要求及时发现。若一切正常，将跟踪记录与其他测试结果一起存储，记录 POI 处的无错误调度情况。

1.3 测试阶段“边界情况”

单元测试会尝试通过采样输入变量的边缘区域来覆盖边界情况，但在调度中实现这一点并不容易。即便知道哪些任务、中断和 CET 组合会导致“最坏情况”，也难以轻易触发。因此，分析边界情况时，会使用独立于实际硬件和环境的技术，如调度模拟和静态调度分析。

1.4 测试阶段“经验性确定余量”

此测试阶段的目标是找出软件在出现时序问题前的余量，也可称为“鲁棒性分析”。具体做法是在待分析的代码中嵌入一个运行时可扩展的延迟函数，该延迟函数的 CET 可调整。在反复执行相关测试时，逐渐增加延迟函数的 CET，同时检查所有时序要求，尤其是 DT、RT 和 CPU 负载。一旦违反时序要求，记录当前延迟函数的 CET 作为受影响代码部分的测试结果。

虽然得到的值并非受影响代码位置可扩展的 CET，但这种经验性方法有助于了解项目当前的状态。若延迟函数的 CET 值很小，应视为警报信号，需立即采取行动。NST 与经验性确定可用时间密切相关，它从另一个角度计算可用空闲时间。

2. 提前考虑未来功能

前面提到的延迟函数还有其他用途。在项目进行过程中，可添加未来功能的占位符。这些占位符虽不能代表实际功能，但能代表其所需的运行时间。

例如，在 V0.1 版本发布后，可实现延迟函数作为未来功能的占位符。通过项目计划展望未来，考虑下一个版本计划的功能影响。若 V0.2 版本的扩展功能包含在其他项目中使用过且已测量过时序要求的功能，可在 10ms 任务中添加 CET 为 620μs 的占位符，在 1ms 任务中创建 CET 为 81μs 的占位符。

对于 V0.3 版本中尚未在其他项目使用过的新开发功能，可基于处理器在环（PIL）测量得到的 CET，通过合适的占位符将其纳入软件，远早于实际功能首次集成。

类似地，也可预估总线上的未来通信情况。例如使用 CAN 总线时，可提前以预期传输模式发送计划消息，初步定义总线负载。这样修改后的平台可进行广泛测试，功能对应 V0.1 版本，但时序与 V0.3 版本预期相同，测试范围不仅限于实验室或 HIL，还可扩展到嵌入式系统的最终环境。

插入所有占位符后，系统可能无法运行，这看似令人失望，但实际上是非常有价值的洞察，能提前明确若不进行时序优化，V0.3 版本的软件将不稳定。使用占位符的方法可将可能出现的问题分散到项目过程中，使时序问题能独立于特定功能提前被调查和解决，而新功能的添加通常对时序的影响较小。占位符的激活时间可自由选择，建议在版本发布后的相对平静阶段进行，如示例中的 V0.1 版本发布后。

以下是一个简单的 mermaid 流程图，展示提前考虑未来功能的流程：

graph LR
    A[项目进行中] --> B[添加未来功能占位符]
    B --> C[根据项目计划预估功能影响]
    C --> D[确定占位符 CET]
    D --> E[进行广泛测试]
    E --> F{系统是否可运行}
    F -- 是 --> G[继续项目]
    F -- 否 --> H[进行时序优化]
    H --> E

3. 最终产品中的时序监控

时序验证通常被视为嵌入式软件开发的一部分，但在系统正常使用过程中，时序分析也很有用。

简单的做法是使用看门狗，硬件定时器倒计时，归零后触发软件复位。在低优先级任务（如后台任务）中，软件为计数器设置初始值。若软件正常运行，计数器不会归零；若软件因错误“挂起”，计数器不会复位，看门狗倒计时归零触发软件复位。软件应具备确定上次复位原因的能力，任何意外复位（如看门狗复位）都应记录在诊断错误缓冲区中。

然而，看门狗提供的错误分析信息有限，且无看门狗复位并不意味着系统没有时序问题，它只是最后的保障。若以定期时序测量为基础，对时序的监控会更细致。可在运行时确定和监控特定的时序参数，将最小值和最大值存储在非易失性存储器（如 NVRAM 或 EEPROM）中，后续访问嵌入式系统时读取。

在这种情况下，代表时序测量的代码不再只是单纯的测量技术，而是成为软件的一部分，需满足生产软件的质量和安全要求。对于安全相关的汽车控制单元（如转向或制动系统），建议甚至要求进行 ISO 26262 ASIL - D 认证。

即便进行了时序测量，分析错误原因通常仍很困难，此时跟踪是解决时序问题的首选方法。若非易失性存储器空间足够，可在观察到时序违规时持久存储跟踪记录。随着存储器容量不断增大，存储虽绝对长度较短但通常足以用于分析的跟踪记录变得越来越可行。不过，在很多情况下，从现场收集跟踪记录是更大的问题，部分场景（如工业工厂）可通过远程访问获取跟踪记录。

4. 成功案例：Vitesco Technologies 的 CoReMa

汽车行业供应商 Vitesco Technologies 采用的 CoReMa 方法非常成功。多年来，该公司针对发动机控制单元，系统地收集了多个软件版本的软件资源需求信息，包括 RAM、堆栈、闪存需求以及时序要求。

RAM 和闪存需求可从链接器映射中轻松读取，堆栈需求通过静态代码分析确定，CET 则通过多个 HIL 上的自动化测试中的基于软件的测量来确定。所有数据至少在 AUTOSAR 所称的可运行体级别（即任务直接调用的函数）进行确定，一组特定的函数代表特定功能，类似于 AUTOSAR 中的软件组件（SW - C）。

大多数软件组件独立于特定项目开发，可在不同项目中反复使用，就像建筑套件中的积木。尽管不同项目使用的处理器类型和编译器不同，但资源信息都会系统地收集到数据库中。这种方法、数据库及相关工具被称为 CoReMa（核心资源管理），随着时间推移，Vitesco Technologies 对每个软件组件在不同条件下使用的资源有了非常详细的了解。

4.1 CoReMa 的优势

软件开发与安全 ：软件变更产生的新值会自动与之前的值进行比较，若软件变更意外大幅改变资源需求，能立即被发现，避免在组件集成数周后才发现现场出现零星错误，从而节省大量分析时间和成本。
未来项目规划 ：若 Vitesco Technologies 收到客户对即将开展项目的规格要求，开发人员可基于 CoReMa 数据通过调度模拟虚拟组装未来的控制单元。根据需求规格选择所需的软件组件，集成到模拟中代表所需功能。通过调度模拟，可进行软件的时序设计、估算预期 CPU 负载等，能提前回答关键问题，如选择较便宜的处理器 A 是否足够，在模拟中可快速完成处理器更换。

一旦软件在新硬件的早期样品上运行，就能进行高效的跟踪，并将生成的跟踪记录与模拟结果进行比较，还能在开发人员桌面、HIL 或车辆中进行高效的（时序）调试。

这种方法为想要在项目过程中关注和控制时序的人提供了蓝图，引入该方法虽需前期投入，但后续遇到的时序问题会大大减少，Vitesco Technologies 的开发人员很少遇到意外的时序问题。

4.2 总结

在嵌入式软件开发的各个阶段考虑时序问题，目的是低成本开发出安全且高度可靠的嵌入式系统。建议采取的措施包括确定具体的时序要求和分析要求、进行专门的时序测试以及在最终产品中监控时序。

Vitesco Technologies 的 CoReMa 数据库多年来已多次证明其价值，通过自动化流程监控时序，甚至能借助调度模拟对新项目的未来情况进行一定的预测。

以下是 CoReMa 工作流程的简单表格总结：
|步骤|描述|
|----|----|
|收集资源信息|收集软件的 RAM、堆栈、闪存和时序需求等信息|
|存储到数据库|将资源信息系统地存储在 CoReMa 数据库中|
|新项目模拟|根据客户需求，从数据库中选择软件组件进行调度模拟|
|分析与决策|通过模拟进行时序设计、估算 CPU 负载等，为项目决策提供依据|
|实际验证|软件在新硬件上运行后，进行跟踪并与模拟结果比较，进行调试|

5. 时序管理的关键要点总结

5.1 时序验证要点

自动化测试 ：利用自动化时序测试，通过持续集成在代码提交或推送时运行测试，降低意外时序问题出现的概率。
多环境测试 ：单元测试在 x86 架构上运行并扩展以监控 CET，系统测试在 HIL 和子系统测试站进行，同时监控调度级别的时序参数。
分阶段测试 ：
- 性能分析 ：为每个功能测试记录独立的性能分析数据，测量特定测试的时序参数。
- 兴趣点跟踪 ：特意引发 POI 并创建跟踪记录，及时发现异常调度情况。
- 边界情况分析 ：使用调度模拟和静态调度分析等独立于硬件和环境的技术。
- 经验性确定余量 ：通过嵌入可调整 CET 的延迟函数，找出软件的时序余量。

以下是时序验证各阶段的对比表格：
|测试阶段|方法|目的|
|----|----|----|
|性能分析|直接测量或间接跟踪|确定时序参数，记录功能测试的性能数据|
|兴趣点跟踪|引发 POI 并创建跟踪|监控异常调度情况，确保时序正常|
|边界情况分析|调度模拟和静态分析|分析难以触发的最坏情况|
|经验性确定余量|嵌入可调整延迟函数|找出软件的时序余量|

5.2 提前考虑未来功能要点

占位符应用 ：在项目中添加未来功能的占位符，代表其所需运行时间。
功能预估 ：根据项目计划和过往经验，预估未来功能对时序的影响，确定占位符的 CET。
测试范围扩展 ：对修改后的平台进行广泛测试，将测试范围从实验室和 HIL 扩展到最终环境。
问题提前发现 ：提前发现系统在添加未来功能时可能出现的时序问题，及时进行优化。

5.3 最终产品时序监控要点

看门狗机制 ：作为简单的时序监控手段，在软件异常时触发复位，但提供的错误分析信息有限。
定期时序测量 ：以定期时序测量为基础，更细致地监控时序参数，将关键值存储在非易失性存储器中。
代码要求 ：时序测量代码成为软件一部分，需满足生产软件的质量和安全要求。
跟踪方法 ：在出现时序违规时，利用跟踪方法分析错误原因，存储跟踪记录。

5.4 CoReMa 方法要点

资源信息收集 ：系统收集多个软件版本的 RAM、堆栈、闪存和时序需求等资源信息。
数据库管理 ：将资源信息存储在 CoReMa 数据库中，便于后续查询和分析。
调度模拟 ：基于数据库数据，在新项目中进行调度模拟，进行时序设计和 CPU 负载估算。
高效调试 ：软件在新硬件上运行后，通过跟踪记录与模拟结果比较，进行高效调试。

6. 时序管理的应用建议

6.1 项目初期

明确时序要求 ：根据项目需求，确定具体的时序参数和分析要求，为后续开发提供明确的目标。
规划测试策略 ：制定自动化时序测试计划，包括单元测试、系统测试等各个阶段的测试方法和频率。
考虑未来功能 ：提前添加未来功能的占位符，预估其对时序的影响，为项目的可扩展性做好准备。

6.2 开发过程中

持续集成测试 ：在每次代码提交或推送时运行时序测试，及时发现和解决时序问题。
分阶段测试执行 ：按照性能分析、兴趣点跟踪、边界情况分析和经验性确定余量等阶段，逐步进行时序测试。
监控资源使用 ：利用 CoReMa 等方法，监控软件的资源使用情况，及时发现资源需求的异常变化。

6.3 项目后期

最终产品监控 ：在最终产品中部署看门狗和定期时序测量机制，持续监控时序情况。
问题分析与优化 ：若出现时序问题，利用跟踪方法分析原因，进行针对性的优化。
经验总结与传承 ：总结项目中的时序管理经验，为后续项目提供参考和借鉴。

以下是时序管理应用建议的 mermaid 流程图：

graph LR
    A[项目初期] --> B[明确时序要求]
    A --> C[规划测试策略]
    A --> D[考虑未来功能]
    B --> E[开发过程中]
    C --> E
    D --> E
    E --> F[持续集成测试]
    E --> G[分阶段测试执行]
    E --> H[监控资源使用]
    F --> I[项目后期]
    G --> I
    H --> I
    I --> J[最终产品监控]
    I --> K[问题分析与优化]
    I --> L[经验总结与传承]