全部学习汇总： https://github.com/GreyZhang/hack_autosar
继续梳理《AUTOSAR_TR_TimingAnalysis》。
可以根据目标测量/模拟的 <activate> 和 <terminate> 以及用于分析的帧长度（参见 CAN）和激活模式（参见激活）计算时间份额。
小结：没想到这个开始以及结束的概念，不仅仅用在调度上，而且在通信类的层面也是用到的。
接口
总线负荷 (CAN) 是属性 GENERIC PROPERTY Load 的一个实例，其参数在表 6.9 中描述。
根据激活模式，以下 CAN 负载是不同的，具体参考上面的表格。
表现力
在运行时，CAN 总线和传输的帧通常表现出动态行为：
• 帧周期可能会从指定的周期时间（抖动和漂移）略微波动
• 填充位数取决于实际有效载荷
• 消息帧每次传输可能不总是携带相同数量的有效载荷
根据所选的<统计限定符>（即平均值、最大值、...），由于这种动态性，可能需要对 CAN 配置的属性进行不同的解释。
批注：其实，类似的指标看起来都是一些参考层面的意义。但是，比较具有代表性。
延迟是 <schedulables> 列表中第一个 <schedulable> 的 <activate>（它准备传输/占用 <resource> ）和最后一个 <schedulable> 的 <end> 之间的时间量 （从占用中解放出来）在名单中。 这包括调度效应。
根据相关的时间属性和应用程序的性质，可以区分两种类型的延迟（也称为“语义”）：反应时间延迟，即对变化的第一反应的时间量。输入和数据有效期延迟，这是在更新的输入值可用之前可以处理特定输入数据的时间量。有关详细信息，请参阅 AUTOSAR 计时扩展 (TIMEX) [2] LatencyConstraint。
AUTOSAR 计时扩展定义了 LatencyTimingConstraint 以指定对 TimingDescriptionEventChain 延迟的约束。TimingDescriptionEventChain 是指系统中的特定事件。
表达能力
对于顺序<schedulable>列表的每一跳（元素），<schedulable>的每跳延迟测量相关<single resource>的利用的时间延迟。由于安全性和可扩展性的原因，较小的延迟对于稳定的功能操作来说更好。然而，它表明如果延迟相对于端到端截止日期太小，则至少有一部分 <resources> 没有得到充分利用，可能会错过成本优化的机会。然而，延迟必须小于端到端的截止时间，否则可能会发生信息丢失。如果 <schedulables> 的很大一部分错过了 <single resource> 之一的截止日期，则它没有足够的容量或调度不够好。
传输或执行 <schedulable> 期间的错误可能导致特定 <schedulable> 的重新传输/重新执行，这会增加负载和延迟。
延迟的最坏情况可以通过基于模型的形式分析方法得出，如 [14] 中提出的。 由此，保守地计算延迟属性。
延迟的最坏情况可以通过模拟来近似，尽管只是乐观的。相关的传输/执行请求和传输/执行完成事件可以随机生成和观察。观测值的最大值是最坏情况延迟的乐观近似值。
当使用不同的方法（尤其是模拟/分析和测量）导出属性时，仅考虑顺序 <schedulable> 列表中的一个元素，以下必须是正确的（WC 缩写为最坏情况）： WC LatencyAnalysis(<Schedulable>) ≥ WC LatencySimulation( <Schedulable>) 和 WC LatencyAnalysis(<Schedulable>) ≥ WC LatencyMeasurement(<Schedulable>)。
通用属性响应时间
范围和应用
响应时间是仅涉及单个 <schedulable> 的延迟的特例，即 <schedulable> 的 <activate> 和 <schedulable> 的 <end> 之间的时间量。这包括调度效果对共享 <resource> 的并发访问。人们可以区分静态优先级抢占式访问（在 OSEK 和其他操作系统的情况下）和静态优先级非抢占式访问（在 CAN 和大多数其他网络系统的情况下）。
<schedulable> 的响应时间等于它的 GENERIC PROPERTY 传输时间或 SPECIFIC PROPERTY 执行时间，在资源专供此 <schedulable> 使用的情况下。 在存在多个同时准备好的 <schedulables> 的情况下，结果响应时间由实际计划定义。
对于每个周期性和每个混合激活，以下是已知的：
• 周期
• 参考时钟（可选）
• 参考偏移（可选）
对于每个触发的事件和每个混合激活，以下是已知的：
• 偶发事件的事件模型，包括最小到达时间
该方法可用于每个迭代步骤，在该步骤中可以使用时序模型或系统测量。
AUTOSAR 计时扩展定义了 LatencyTimingConstraint 以指定对 EventChains 延迟的约束。 <schedulable> 的响应时间对应于由所考虑的可执行实体的激活事件和终止事件构成的（短）EventChain 的 Latency。
批注：从上面的描述看，我倒觉得调度表是一个不错的处理方式。
表达能力
定义的响应时间表达在某种意义上是有限的：
1. 在大量非谐波时基的情况下，分析时间可能会增长到超出可接受的时间。在这种情况下，在分析过程中可以忽略一些偏移关系，这可能会稍微降低精度。
就只有一条居然还列一个条目，看起来这个格式的要求近乎死板啊！
做一个小结：这部分介绍一部分专用自己通用的属性指标参数，对相关的参数进行了详细的解释，同时也描述了相关参数的表现力或者说是表征能力。
