730_AUTOSAR_TR_TimingAnalysis16_协议规范以及时序属性定义和分类

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

       继续梳理《AUTOSAR_TR_TimingAnalysis》。

       协议规范

       CAN

       为了定义 CAN 总线的属性，使用上面表格中的定义。

       将所有参数加在一起得出帧长度/时间（lframe/tframe）。

       因此，一般的 CAN 属性和参数由上面的第二个表格给出。

       为了将通用描述应用于 CAN 总线，应用了上面表格中的关系。这里，把之前看过的资源、调度等进行了一个实际的举例。

       周期性的以及事件触发的消息诊相对来说熟悉了，不去看了，还有一个混合的消息帧：通过周期或外部事件激活的帧。存在处理周期性部分的不同概念（即在偶发事件到达时重置周期性计时器）。

       从这个描述看，混合帧的概念其实是多了一个优先级更好的事件触发。

       可以为 Autosar 范围内的帧定义更复杂的激活模式。此外，还存在 OEM 特定的传输模式。

       6.3 计时任务的描述

       本节介绍为完成第 3、4 和 5 章中描述的用例而必须执行的计时任务。

       从规范文档中收集已知的时序要求。如有必要，在与功能所有者和系统架构师的讨论/采访中找到时间要求。从跟踪、测量和实验中得出新的时序要求。

       第一步工作，看起来都是从需求的梳理开始。

       模型参数源自与时序相关的信息。根据综合规则估计或生成不完整的信息。记录了其他假设/操作场景/边界条件。

       小结：关于时序相关的模型建模，其实就是确定一个分析验证的方法。

       进行时序分析。

       确认是否满足要求。

       小结：这里定义了这么多的角色，但是这些角色在我现在的团队中全都没有，这的确是一个比较头疼的点。看起来，这类工作有专职专业的人员做比较好一些，但是，现在如果推的话基本就意味着继续让不成熟的工程师再次兼任新的角色。在工程师经验不足的情况下，这类工作看起来不是很好做。

       时序属性的定义和分类

       属性的分类和关系

       属性可以分为两个主要领域：容量属性（<resource>容量）和延迟属性（<schedulable>延迟）。 容量属性是 <schedulables> 的容量需求与 <resource> 的容量之比。 延迟属性是 <schedulables> 由于常用 <resource> 上的调度（优先级架构）的延迟。

       负荷是一组 <schedulables> 占用 <single resource> 的总时间份额。如果计算占用时间，它可能会超过可用资源时间（过载）。 在使用模拟或测量的实际实现中，这种情况不会发生。 但是，如果所有 <schedulables> 的传输负载超过 100%（发送请求的数量）没有缓冲，则传输所需的信息可能会丢失或覆盖。

       表现力

       “负载”表示给定<单一资源>的整体利用率。由于安全性和可扩展性的原因，小负载更适合稳定运行。但是，它表明 <single resource> 没有得到充分利用，可能会错过成本优化的机会。另一方面，剩余的空闲资源可以用于未来的扩展，因此被有意保留。

       从实时应用和可调度的角度来看，负载的表现力是有限的。低于 100% 的负载值允许推断出最终每个 <schedulable> 的每个实例都将在 <resource> 上调度和执行的保证。 但是，可调度的完成时间可能大于其周期或任何给定的最后期限。

       实际上，与 <schedulable's> 最坏情况响应时间的相关性很小。根据时间表，有高负载和短总响应时间以及低（但高度可变）负载和高总响应时间的示例。（比较延迟、时序属性最坏情况的响应/执行时间）。

       小结：这一段的描述其实是很有道理的，单纯的负荷率不足以表征一个系统的实时性，存在太多的变数。即使是负荷率非常低，也有可能在各种实时性需求上满足不了需求。

       在 文档[13] 中，表明仅给定期限等于其周期的周期性 <schedulables>，如果负载小于 69%（独立的 <schedulables>），则所有 <schedulable> 将在它们的期限之前得到服务。 然而，在实践中，偶尔激活的 <schedulables> 的存在避免了该声明的直接适用性。