继续梳理《AUTOSAR_TR_TimingAnalysis》。
ECU 用例“验证时序模型”
任何基于模型的设计或验证过程都必须经过模型检查以确保模型代表相关属性的真实性。
示例1：一个完美的代码级WCET计算静态代码分析工具，如果配置不正确，很容易产生错误结果（误报！）。
示例2：一个完美的ECU层面WCRT计算的静态调度分析工具，当真正的ECU遇到操作系统bug时，很容易产生错误的结果（误报！）。
在这两个例子中，模型和基于模型的算法可能是绝对正确的，但它们仍然会产生符合要求的结果。换句话说：软件可能会通过基于模型的验证，但仍会显示严重的时序缺陷。
目标：测量/跟踪时序指标与基于模型的方法提供的时序指标的比较表明，基于模型的方法产生了合理的结果。
主要场景
1. 当基于模型的方法可用或变得可用并且真实系统可用或变得可用时，用例开始。通常，这将发生在两种设置中的任何一种中：对于现有系统，添加基于模型的方法或在早期开发阶段使用基于模型的方法，并且（真实）系统可用。
2. 使用基于模型的方法生成指标，例如 WCET 或 WCRT；
3. 使用真实系统测量或跟踪可比较的指标，例如 最大限度。 CET 或最高 RT 。
4. 将基于模型的结果与测量或跟踪的结果进行比较。基于模型的方法产生的所有“最坏情况”结果都必须比观察到的结果“更糟”。如需比较时序属性，另请参见 ECU 用例“比较时序属性”。
5. 用例结束。然而，这种方法不能保证模型的正确性，因为测量所基于的测试向量没有覆盖可以发现模型问题的情况。但至少它提供了一个额外的和非常重要的检查。
这个环节会涉及到模型的概念，但是这个模型得与开发过程中的模型有一定的区分度。这里的模型，其实更好的理解可以理解为测试验证的方法，而不是开发过程中针对逻辑策略所做的设计。
ECU 用例“比较时序属性”
比较两组时序属性。 这些可能是：
• 通过不同的时序分析技术获得，例如： 模拟和测量；
• 通过分析不同版本的 ECU 软件获得或
• 与不同的约束类型相关，例如 “要求”和“保证”。
将通过响应时间分析和/或调度分析获得的时序属性与测量的时间值进行比较。
与测试不同，时序验证可以在设计阶段的早期通过基于遗留软件组件和/或预算的响应时间分析和/或调度分析进行。为了验证 a) 单个软件组件的执行时间和 b) 产生的时序属性，例如在设计阶段早期收集的响应时间，必须将时序属性与测量的时间值进行比较。
主要场景
1. 1. 当参与者决定比较时序属性时，用例开始。
2. 参与者测量系统的时序属性；
3. 参与者将通过响应时间分析和/或调度分析获得的时序属性与测量值进行比较：
• 参与者从测量值中生成时序模型，并将时序模型与每个其他
• 参与者将时序模型的选定元素与测量值进行比较；
4. 参与者查看比较结果并选择以下操作之一：
• 时序模型中与测量值不同的元素被更新或补充测量值；
• 生成带有测量值的新时序模型 另见第 6.5 节]
这部分看起来主要是用来做一些软件移植或者改进时候的对比验证，采用的验证的技巧或者手段多少有点与前面雷同。主要的差异点其实还是在于目的不同，在开发过程中所处的阶段不同。
好，这一次的小结到此结束了，接下来应该要开启新的篇章了。
