728_AUTOSAR_TR_TimingAnalysis14_时序保证以及基于trace的需求跟踪

         全部学习汇总： https://github.com/GreyZhang/hack_autosar

         继续分析《AUTOSAR_TR_TimingAnalysis》。

         E2E 用例“确保保证声明时序要求”

该用例将通过分析实际设计（“保证”）得出的指标与系统规范（“要求”）进行比较。

此用例的最佳结果是保证是否满足要求。 否则，要么需要放宽要求，要么必须改进保证（例如，通过重新配置系统）。

         目标：

         评估特定实现的时序是否符合时序要求。

         成功条件：

         已知当前实现是否满足所有时序要求。 最好的结果是保证满足要​​求。否则，要么放宽要求，要么改进保障。

         主要场景

该用例通过以下过程实现：

1. 建立已知的时序要求（任务“收集时序要求”），例如根据 E2E 用例“从现有实现的时序评估中导出时序要求”。

2. 建立通过根据 ECU 用例评估实施提供的最佳保证 ECU 用例“时序验证”和类似的程序网络和端到端时序（任务“执行时序分析”）。

3. 报告两者的保证、要求和比较（任务“验证时间”）。

         相关的方法以及属性没有特殊的地方，跟之前接触到的各种方式一样。

E2E 用例“分布式实现的基于跟踪的时序评估”

无论是理解、调试还是验证分布式系统的时序行为，相关总线和 ECU（以下称为子系统）的跟踪都显著简化了时序分析。

如果来自各个子系统的轨迹记录可以对齐（即同步）以显示事件链的跨子系统时序效应，例如多核系统中的跨核通信，当 ECU 向/从通信网络发送/接收数据时的数据缓冲效应，甚至完整的终端结束计时场景。

         跟踪观察真实系统。对于专用事件，例如任务开始或总线上出现特定消息，时间戳与事件信息一起放置在跟踪缓冲区中，稍后可用于重建和分析观察到的场景。有关详细信息，请参阅测量和跟踪。为了分析跨子系统时序效应，有必要同步所有相关子系统的trace信息。

         通过条件：

         执行跟踪并准备好分析数据（=跟踪）； 如有必要，来自不同子系统（核心、ECU、总线）的跟踪是对齐的，即同步的。

         主要场景

该用例通过以下过程实现：

1. 时序专家/测试工程师准备测量和被测系统（工具、软件...）。 参见表 6.13 中的任务执行时序分析。

2. 时序专家/测试工程师对所考虑系统的现有实现进行相关（即同步）跟踪。

3. 时序专家/测试工程师检查走线的质量以及质量是否足够。

         这两部分主要是介绍了系统时序的保证以及保证不了时候的变通处理方式，同时介绍了基于trace的需求评估。对我个人本身的工作启发相对来说有限，真正有效的或许是我知道如何为设计不出来的功能找一个推脱的理由了。当然，说推脱其实是不恰当，这种情况当然大部分都是需求方面的问题了。