全部学习汇总： https://github.com/GreyZhang/hack_autosar
继续梳理《AUTOSAR_TR_TimingAnalysis》。
专属的属性，响应时间，主要是针对CAN
该属性提供了从帧准备好发送（<activate>，即将帧放置在 CAN 驱动程序的输出消息缓冲区中）到帧完全通过总线传输（<end>，即通常 导致接收 ECU 上的 Tx IRQ）。
该属性允许评估时序关键帧的通信延迟。
• 假设总线上的所有通信都没有错误，即每次传输只发生一次。
• 假设网络中所有准备发送的帧中，CAN 总线总是选择具有最低 CAN-ID 的帧进行传输。
• 对于总线上的每个帧，以下是已知的： – 帧长度，包括填充位 – CAN-ID
该方法可用于每个迭代步骤，在该步骤中可以使用时序模型或系统测量。
该属性可用于计算实时余量（在容纳通信矩阵中指定的所有帧后的可用带宽）。
AUTOSAR 计时扩展定义了 LatencyTimingConstraint 以指定对 EventChains 延迟的约束。 <schedulable> 的响应时间对应于由所考虑的可执行实体的激活事件和终止事件构成的（短）EventChain 的 Latency。
对于 CAN 帧的响应时间，事件由系统视图级别的时序描述事件标识。
激活事件由时序描述事件 TDEventFrame(TDEventType=frameQueuedForTransmission) 给出，终止事件由 TDEventFrame(TDEventType=frameTransmittedOnBus) 给出。
以上是接口信息以及分析的表现力
表达能力
定义的 CAN 响应时间的表达在某种意义上是有限的：
1. 由于内部缓冲区结构，某些 CAN 控制器可能无法始终提供具有最低 CAN-ID（最高优先级）的帧立即即准备发送到总线仲裁。 这可能导致优先级反转，其响应时间可能比此属性定义的时间更长。
2. 很难测量目标设置中的延迟。 虽然通过探测总线很容易识别传输完成事件，但帧准备好发送的时间点更加困难（黑盒测量）。 一种选择是通过在传输完成事件之前检查总线繁忙时间来估计时间。 另一种选择是使用参考时基将 ECU 内部跟踪与网络跟踪相结合。
当前的研究（如 [15]、[16]）部分放宽了这些限制。
有可能，这个就是导致一些控制器实现不了100%负载率的一个原因吧，MCU可能是一个限制点。
通用的属性-传输时间
该属性是响应时间的特例，不考虑任何调度影响。 该属性提供了在单个 <resource> 上传输 <schedulable> 的纯时间，而不考虑此 <resource> 上的任何其他 <schedulable>。
针对CAN，还有一个专门的传输时间属性。
批注：一者可以看出CAN的特殊性，另一方面则可以看出其重要性。
该方法可用于每个迭代步骤，在该步骤中可以使用时序模型或系统测量。
AUTOSAR 时序扩展中定义的传输时间没有直接约束。一个相关的约束是 ExecutionTimeConstraint，用于指定对 ExecutableEntities 执行时间的约束，但这仅针对软件计时。
执行时间表示某个计算所需的时间。在这种情况下，计算可以是可运行的、子功能或只是一系列命令。
此属性是运行时间预算和 ECU 调度可行性所需的输入信息。
AUTOSAR 计时扩展定义了一个 ExecutionTimeConstraint 来指定对 ExecutableEntities 执行时间的约束。 “净”和“总”执行时间是有区别的。 上面定义的属性执行时间对应于“总”执行时间类型（包括对外部函数的调用）。
表达能力
对于硬实时系统，一个重要的统计限定符（另见约束类型）是完成特定计算所需的最坏情况执行时间 (WCET)。WCET 是资源消耗的指标，通常必须达到或导出预定义的值。 为了预测和证明正确的软件执行，WCET 是一个重要的属性。 在实践中，建议使用不同的计时方法来确定 WCET，以获得结果的可信度。这些方法是静态、动态和混合方法。如果无法在现场确定 WCET，则需要使用安全上限作为等效值。基于若干计算的最坏情况执行时间，可以确定在大多数情况下更相关的一个或多个WCRT（最坏情况响应时间）。
对于 WCET 旁边的 ECU 用例“优化代码”，平均执行时间可能很有相关性的。 两者之间或平均执行时间和最大执行时间之间的巨大差异通常表明优化潜力。
小结：这部分给出了一些通用的以及CAN专用的一些评估的属性的具体定义，算是为度量方式提出了一个参考的信息。
