全部学习汇总： https:///GreyZhang/hack_autosar
继续梳理《AUTOSAR_TR_TimingAnalysis》。
ECU 用例“收集SW-C 的时序信息”
在3.3 节中，描述了时序模型的创建。需要收集时序信息以建立时序模型。在此用例中，描述了收集特定 SW-C 的时序信息。 对于第 32 页图 3.1 中显示的示例，这可能意味着获取有关 ECU“ASA”内部特定 SW-C 的信息，例如 其最大执行时间。
表格是一个工作的提示清单，描述了内容以及相关的角色信息。
主要场景
1.当负责 SW-C 人员开始收集通常由 ECU 集成商请求触发的计时信息时，用例开始。
2.SW-C 负责人收集特定 SW-C 的所有可用时序数据，并将它们收集到 SW-C 范围的时序模型中。
• 对先前和类似项目、方法的一些估计，请参见第 6.5 节
• 在可运行级别及以下级别的运行时测量，方法，例如处理器在环仿真 (PIL) 或静态最坏情况执行时间分析，请参见第 6.5 节
• 此 SW-C 的时序要求基于功能要求，例如 – 触发事件 – 延迟 – 抖动 – 执行顺序 – 与安全相关要求的关系
• 方法：参见第 6.5 节 3. 将检索到的时序数据添加到时序模型。
4. 用例以 SW-C 时序信息结束。 时序信息可用于整个系统中的 SWC 集成。
#1 替代场景
在主场景的步骤#2 中，子步骤可以按任意顺序执行，也可以跳过。 跳过的理由可能是在这个特定阶段缺少信息。
相关的方法以及属性
方法
Tracing、PIL、调度分析、调度模拟、最差场景执行时间分析。几个方法看起来都有一定的可理解度，不过这里的tracing是否是我们之前一直提到的调试器的高级功能这个是有待确认的。
属性
资源负载率、执行时间、响应时间、中断负载率，从这些描述看，这个属性的概念也就是被分析的指标。
ECU 用例“选择ECU 供应商”
以下用例与AUTOSAR 方法论并不完全匹配，但非常重要。
在新 ECU 的订购阶段，一些性能关键指标用于评估指标，以决定 ECU 设计（例如处理器类型、内存、频率）。 此外，必须选择满足总体要求的供应商。
在这个阶段，来自 OEM 和 Tier1 的时序专家必须使用本文档中描述的一些用例一起工作，勾勒出一个粗略的 ECU 架构（关于硬件和软件），目的是展示整体可行性。
通常，在这项工作完成后，将提供初始时序模型。
相关方法和属性
• 方法
– 负载率，参见第 6.5 节
• 属性
– “资源负载率”，参见第 6.4 节
这里的负载率相比上一个章节在理解上怎么处于了两个维度？一个将其描述为属性，另一个将其描述为方法。或许，在提到的参考章节中还有更加明确的描述？
对这部分的信息做一个简单的小结：
1. 文档介绍了收集SWCs的时序信息，在这部分主要给出了主要应用场景以及选择性应用场景的介绍。在这个过程中，可以参考之前项目的经验，可以用各种仿真分析手段。当然，也有可能出现需求不清晰的可能，这样可能会导致分析环节跳过。
2. 供应商选择则是满足自己系统要求而提出需求，由此可能引导ECU的设计，比如MCU的能力以及存储的要求等。
