723_AUTOSAR_TR_TimingAnalysis10_时序分析验证2

梦里梦外; 2022-09-04 13:59 95阅读 0赞

全部学习汇总： [https://github.com/GreyZhang/hack\_autosar][https_github.com_GreyZhang_hack_autosar]

继续梳理《AUTOSAR\_TR\_TimingAnalysis》。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dyZXlfY3Nkbg_size_16_color_FFFFFF_t_70][]

ECU 用例“优化ECU 的时序”

这个用例背后的主要思想是优化工作ECU 的时序行为。有时资源消耗高于预期或需要进一步将 SW-C 集成到 ECU 中。

这个现象或者问题，在我接触的开发中其实是遇到很多次的。

目标：消除时序违规（优化资源消耗、数据一致性、减少抖动等）或最小化资源消耗。

简介：基于时序要求，同时考虑所有时序约束，优化 ECU 的整体时序架构。

成功的条件：找到了一个更好的解决方案来满足所有时间和资源要求（即使有附加功能，如果适用）。 主要包括：

•（新计划

• 更新时序模型）和/或

•（优化代码

• 新内存布局

• 新代码生成器选项

• 新编译器选项）

上面的这几种手段，在我自己接触的软件开发项目中基本都是遇到过的。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dyZXlfY3Nkbg_size_16_color_FFFFFF_t_70 1][]

主要场景

1. 当主要参与者意识到时序违规或需要向已经很重负载的系统添加更多功能时，用例开始。

2. 分析当前系统（验证系统时序，参见ECU用例“Debug Timing”）并找到可能的热点（问题点？）。这些是调度中的情况，其中时序要求或资源消耗约束已经被违反，或者如果添加更多负载就会违反。

3. 基于每个热点定义优化目标。

4. 分析可用选项，以放松热点。 这些选项可以包括调度配置的修改（包括可运行到任务的映射、可运行的任务内部顺序/顺序、将任务分配到不同的核心、将任务划分为更小的实体以进行负载平衡、优先级/偏移量的改变 /recurrences of task）和/或代码优化（包括将数据重新映射到内存）。 对于每个选项，继续使用相应的子用例。

5. 参与者执行权衡分析以权衡优化时序的不同可能性及其对系统的影响。

6. 参与者决定修改并更改系统的时序模型/代码。

7. 参与者验证 ECU 的时序。

8. 针对优化目标的验证。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dyZXlfY3Nkbg_size_16_color_FFFFFF_t_70 2][]

可能的不同性能关键指标：

• 负载平衡（在时间轴上分配负载，在不同内核上进行负载平衡）；

• 最大限度地减少系统响应时间、抖动等。

• 减少抢占次数（从而减少操作系统开销）；

• 减少移植次数（从而减少移植开销）；

• 减少资源消耗（内核间通信、内存（缓冲区大小）、负载）；

• 减少调度中断次数；

• 减少等待时间；

上面这些基本是软件设计的一个基本原则了。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dyZXlfY3Nkbg_size_16_color_FFFFFF_t_70 3][]

方法以及指标其实跟之前看过的其他部分是大同小异的。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dyZXlfY3Nkbg_size_16_color_FFFFFF_t_70 4][]

ECU 用例“优化调度”

该用例背后的主要思想是优化工作 ECU 的现有调度，并具有明确的目标，例如“消除局部过载”或“减少任务 xyz 的响应时间”。

怎么会有一个xyz的叫法，这个是一个专用术语还是为了做一个类比？

最终的目标是确定的：找到了一个修改后的调度配置，它实现了目标，而不会导致新的时序违规。相关的方式：

• 新调度，在特定指标方面优于原始计划；

• 更新计时模型；

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dyZXlfY3Nkbg_size_16_color_FFFFFF_t_70 5][]

主要场景

1. 当主要参与者面临有关调度的某个优化目标时，用例开始；

2. 可用选项的分析，例如 可运行到任务映射的修改，任务内部的可运行顺序/顺序，将任务分配到不同的核心，将任务划分为更小的实体以进行负载平衡，更改任务的优先级/偏移/重复。

3. 参与者执行权衡分析以权衡调度优化的不同可能性及其对系统的影响；

4. 参与者决定解决方案并修改系统的时序模型/代码。

5. 参与者通过执行响应时间分析、调度分析或测量来验证 ECU 的时序；

6. 针对优化目标的验证。

基本的处理模式是能够理解的，不过最后两条感觉在内容上似乎有一些重复。可能5是对时序指标的验证测试，而6是一个系统功能的验证吧。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dyZXlfY3Nkbg_size_16_color_FFFFFF_t_70 6][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dyZXlfY3Nkbg_size_16_color_FFFFFF_t_70 7][]

相关的方法以及指标中，这一次比较特殊的是一个调度安排的分析以及仿真。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dyZXlfY3Nkbg_size_16_color_FFFFFF_t_70 8][]

ECU 用例“优化代码”

由于代码和代码部署对时序有巨大影响，因此可以执行不同的优化活动。优化的范围可以不同（内存、运行时间、安全性、可重用性、易于理解等），但在本文档的范围内，优化范围仅限于时序效应。但必须考虑到，这种时序优化会影响系统的其他方面，例如内存和可重用性，并且这种优化受到安全或安保方面的限制。

目标：

找到了一个关于时间的更好的代码。可能的方案：

• 优化的代码

• 新的内存布局

• 新的代码生成器选项

• 新的编译器选项

这部分我个人相对来说其实还熟悉一些，毕竟在代码设计上还是有一些工作以及学习的经历。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dyZXlfY3Nkbg_size_16_color_FFFFFF_t_70 9][]

主要场景

1. 当主要参与者决定优化某个代码片段（任务、中断、可运行、函数或函数的一部分）时，用例开始；

2. 定义优化目标；

3. 可用选项分析；

4. 修改；

5. 测试；

6. 针对优化目标的验证；

大概的步骤其实跟前面的方式是差不多的。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dyZXlfY3Nkbg_size_16_color_FFFFFF_t_70 10][]

这里新增的两个指标：中断负荷率以及代码矩阵，这两部分究竟该如何做一个测量或者有什么标准的确是一个比较新的知识点，后面得注意一下这方面的信息。

这一次的小结到此结束了，关于内容总结上其实是跟其他部分有些雷同的，只是涉及到的是不同的方向。而新的点，基本是在于对调度以及中断的分析，在配置以及代码方面的优化。实践方法论方面有一定的提示作用，实践方法本身并没有太多的描述。

[https_github.com_GreyZhang_hack_autosar]: https://github.com/GreyZhang/hack_autosar
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dyZXlfY3Nkbg_size_16_color_FFFFFF_t_70]: /images/20220829/b6daa93467074e918c38cafbf11b74eb.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dyZXlfY3Nkbg_size_16_color_FFFFFF_t_70 1]: /images/20220829/5b0128ec7d2d425e8a51110aeca5456f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dyZXlfY3Nkbg_size_16_color_FFFFFF_t_70 2]: /images/20220829/42942f30024f4f4d865f95755a834968.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dyZXlfY3Nkbg_size_16_color_FFFFFF_t_70 3]: /images/20220829/a77d833091b1458ea0038c5042c6830e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dyZXlfY3Nkbg_size_16_color_FFFFFF_t_70 4]: /images/20220829/97cacefa5382425295dd6ae4f856e742.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dyZXlfY3Nkbg_size_16_color_FFFFFF_t_70 5]: /images/20220829/79c714a91bfa414982b76ddfa479f712.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dyZXlfY3Nkbg_size_16_color_FFFFFF_t_70 6]: /images/20220829/9c9a8b27189a4d32949e6b53a967cbfc.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dyZXlfY3Nkbg_size_16_color_FFFFFF_t_70 7]: /images/20220829/0020b85f9d5b410d875569d6664138c9.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dyZXlfY3Nkbg_size_16_color_FFFFFF_t_70 8]: /images/20220829/aae44d2e952241dbb7fdec2ed1023020.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dyZXlfY3Nkbg_size_16_color_FFFFFF_t_70 9]: /images/20220829/402f69e9480d4beba82b54d59949a7b5.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dyZXlfY3Nkbg_size_16_color_FFFFFF_t_70 10]: /images/20220829/503602d551e044e1be782dd3f2c4e9d2.png