继续梳理《AUTOSAR_TR_TimingAnalysis》。
ECU 用例“在 SW-C 集成后验证时序”
此用例的另一个标题是“使用现有的、从时序角度来看最合适的 SW-C 来构建系统”。 在这种情况下，目标是该系统满足给定的时间限制，例如“从传感器到执行器”。
特征信息
在给定/已经存在的系统中，SW-C 之一被新版本取代。 新版本可能包含 1)与先前版本相同数量的 RE（但实现不同），或 2) 与先前版本不同数量的 RE（更少或更多 RE）。 从时序分析的角度来看，必须确保新版本仍然满足给定的时序约束。 这需要进行 1) 响应时间分析，和/或 2) 调度分析，表明满足给定的时序约束。
前提条件
1. 相关时序约束的定义，应满足。
2. SW-C/s 已经被映射到一个特定的 ECU，这受时序分析的影响。
3. SW-C 从结构上进行了整合，这意味着“RE”已经映射到相应的任务并在任务中正确定位。 工作产品：ECU 配置，包括 OS 配置（任务模型和任务参数）和 RTE 配置（RTE 事件到任务映射）。
4. 所有端口接口都有效/兼容，并且所有端口都已与 SWC 的相应端口连接。 集成的SWCs正在与之交换数据。 工作产物：SW-C 描述，系统描述。
5. 系统的系统/ECU 时序模型可用 [StKu：是否应该在这里说明时序模型的粒度？] 工作产物：ECU 时序，系统时序。
这个文档比较有意思，这里怎么带了一个备注之类的信息？StKu是一个人员还是组织？
通过条件：
时序分析表明满足前提条件中定义的给定时序约束（在所有条件下）。 所有相关文档都已更新。
主要场景
1. 当参与者从变更控制委员会 (CCB) 收到 SW-C 包和变更单时，用例开始。
2. 参与者进行结构整合。
3. 参与者将当前版本SW-C的时序模型替换为系统时序模型中新版本SW-C的时序模型[VFB or/and SW-C Timing]。
4. 本质上，这只是从新 SW-C 被“集成”的系统时序模型中引用新 SW-C 时序模型中的事件链。
5. 参与者确定先前和新 SW-C 之间的差异。确认这对集成商提出了什么需求？
6. 参与者进行时序分析
7. 参与者审查时序分析的结果并得出满足给定时序约束的结论。
8. 参与者将工作产品标记为有效，即时序模型和分析报告。
ECU时序的验证
验证时序以确保系统的可调度性并满足所有给定的时序约束。时序验证可以通过各种时序分析方法进行，例如，响应时间分析和/或可调度性分析取决于时序约束的性质和/或预期的置信水平。如果存在系统的实现，则还可以基于时序跟踪来测量和验证时序。
对该事件链施加至少一个具有指定信号接收的激励和指定信号在连接的总线/网络上传输的响应以及延迟时间约束的事件链。执行可运行实体到任务的映射，并且可以使用 RTE 和 OS 配置。
通过条件：可调度性分析和跟踪确认满足给定的时序约束。这意味着时间是有效的。
主要场景
1. 用例从触发事件开始；
2. 参与者通过以下方式进行时序分析：1) 响应时间分析，2) 调度分析，或 3) 测量（子用例）；
3. 参与者审查时序分析的结果并得出（是否）满足给定时序约束的结论。
4. 参与者将工作产物标记为有效，即时序模型和分析报告。
这里面应该是一个设计的目标而不是工作的过程定义，不然的话3、4这边应该没有被否定的可能性了。
相关信息
这个相关信息表格的信息太苍白了，什么都是没有。
相关方法和属性
• 方法 – tracing、PIL、调度分析、调度模拟
• 属性 – 资源负荷、执行时间、响应时间、中断负荷
ECU 用例“调试时序”
每当 ECU 显示零星系统崩溃、数据不一致或意外过载情况、延迟或抖动时，时序问题可能是问题的原因。 使用传统的调试方法跟踪问题可能非常痛苦和耗时。 即使某个问题与时序非常明显相关，也是如此。
在解决任何问题之前，必须先了解它。 这就是时序调试的意义所在：了解真实 ECU 上存在的时序问题。 一旦理解了问题，接下来就是解决方案的寻找和解决，请参见第 45 页的第 3.9 节“ECU 用例“优化 ECU 的时序”。该用例侧重于调试单个 ECU 的时序，例如 第 32 页图 3.1 中所示的“ASA”。
目标：了解（时间）问题并找出问题的原因。
使用专用的时序调试方法（参见第 6 章），调试问题并找出是否是时序问题。 如果是这样，找出问题的原因，以便完全了解问题。 这使得在下一步中解决问题成为可能。
主要场景
1. 当主要角色面临计时问题或可能由真实 ECU 上的计时引起的问题时，用例开始。
2、如果问题可重现，则使用真实系统进行时序调试。 如果没有，请尝试使其可重现。 当这意味着对系统进行修改时，将所有后续步骤的变化反映在结果上（即使进行了修改，所有假设仍然正确吗？）。 如果问题仍然无法重现，请尝试使用以前出现的数据。
3. 使用专用时序分析方法进行调试，请参阅第 6 章
4. 孤立问题
5. 如果原因不重要，请修复并测试。 如果没有，请将结果交给用例，以寻找更复杂的解决方案，例如 ECU UC08 优化串联 ECU 的时序。
第4条，我的理解应该是要确认一个最小的复现单元。
相关的方法和属性
方法：提取时序trace、评估时序trace
属性：资源负载
给看过的这一部分做一个小结：
1. SWCs集成后如何验证，这个可能是我现在接触的工作中较为容易推进的一个工作环节。从这段文档描述看，这个动作本身通常是伴随着需求确认或者变更而来的。
2. 提供了一部分有效的验证方法和检测指标，而验证的那个小章节则是这方面的一个具体说明了。
