继续梳理《AUTOSAR_TR_TimingAnalysis》。
时序方法的定义、描述和分类
方法的分类和关系
方法大致可以分为三个主要领域：模拟、分析解析计算和测量。 区分方法的另一个标准是考虑数据的来源：基于模型或基于测量。这种分类与方法可以执行的计时过程的哪个阶段（在规范阶段或验证阶段）密切相关。
分析计算
静态代码分析在可执行软件或其一部分的源代码或二进制代码级别上工作。 确定特定属性执行时间的分布。因此，调用图和指令序列被重构和分析。BCET（最佳情况执行时间）的下限和 WCET（最坏情况执行时间）的上限是针对给定的代码片段（例如 一个函数）通过应用统计限定符。除了应该分析的软件之外，还必须提供附加约束（例如构建选项、输入值范围、集成/硬件特定约束）的符号信息和注释。 只要这个片段不被中断，任何真正的核心执行时间都保证在这个间隔内。此外，任何仅在运行时出现的数据（例如循环迭代的上限和动态函数指针的内容）都必须以附加注释的形式手动提供。为了进行正确的静态代码分析，必须详细了解目标硬件行为（例如，不同内存区域的访问时间、缓存等）。 在现代系统中，行为模型可能非常复杂，因此可能会出现有关结果精度的限制。静态代码分析的结果应该用时序方法的定义、描述和分类中描述的替代方法的结果进行验证。
调度分析
基于某个调度器（例如某个 RTOS）的模型，调度分析工具以最小/最大内核执行时间和应用程序模型作为输入，并提供诸如有保证的 WCRT。这允许检查在给定条件下是否会错过任何截止日期。对于每个任务和中断的最坏情况，会生成一个跟踪记录，允许分析它发生的运行时情况。输入到分析中的执行时间可以是预算、估计或来自其他工具的输出，例如静态分析 BCET/WCET 或跟踪/测量数据。因此，调度分析允许验证新概念，而无需将优先将他们实现。 此外，可以修改现有概念以进行概念验证或解决方案的探索。
网络分析
单个网段的网络分析计算通过网络传输的每个帧/包的最坏情况响应时间。 这通常可以基于配置连接的 ECU 所需的相同类型的设计数据（例如 AUTOSAR 系统提取）来实现。 主要信息是每个帧/包的（总）大小（例如，基于包含的信号/参数和协议头的大小）、帧的传输属性（即其循环时间或外部触发器的去抖动时间），以及当然是网络的传输速度。
该分析在计算最坏情况响应时间时考虑了网络冲突和帧之间的同步。该基本结果可以汇总为总线或门控网络的完整时序配置文件。在高度动态的时序行为的情况下，网络分析可以与基于测量的方法混合使用，方法是用来自实际测量的事件跟踪替换基于模型的设计数据。
组合分析
组合分析允许考虑由不同 <resources> 上的不同 <schedulable> 组成的活动链。它在第一步中将不同 <schedulable> 的链接响应时间添加到一个 <resource> 上，然后添加资源的响应时间。如果考虑最坏情况，则此方法可能非常保守，因为实际上，多个链接资源的最坏情况响应时间的概率远低于单个资源最坏情况的概率，后者本身是保守的。
仿真
一般来说，仿真需要足够的运行次数（仿真时间）以确保结果的统计相关性并覆盖所有自由度的参数空间（例如发送请求的抖动、帧的发送排列 ）。
代码模拟
代码模拟器模拟特定处理器的给定二进制代码的执行。存在各种各样的代码模拟器。 简单的指令集模拟器提供的关于执行时间的信息非常有限，而复杂的模拟器还考虑了管道和缓存效应。为了从代码模拟器获得可靠的 WCET 信息，必须将其嵌入到实际模拟最坏情况的测试环境中。
Windiss应该就是一种代码模拟器，其实在实际的测试中现在我是直接没有使用。
调度仿真
调度仿真器提供与调度分析类似的功能。它们不是计算结果，而是模拟运行时行为。 观察到的时序信息和生成的轨迹是主要输出。如果模拟最坏的情况，观察到的响应时间将等于 WCRT。一些模拟器允许使用 C 语言定义任务，以便支持复杂的应用程序模型，同时提供汽车工程师熟知的规范语言。
批注：感觉有种虚拟ECU的意思。
网络仿真
网络仿真是一种基于实际配置模型预测总线段或段网络的实际时序的技术。这些模型通常源自配置连接的 ECU 所需的相同设计数据（例如 AUTOSAR 系统提取）。 主要信息是每个帧/包的大小（例如基于包含的信号/参数和协议头的大小）、帧的传输属性（即它的循环时间或外部触发器的去抖动时间），当然还有网络的传输速度。 网络模拟器特定于特定的网络协议，通常会在模型数据指定的范围内创建随机流量并展开特定的时间表。可以根据结果帧响应时间、网络负载等来研究这些调度。作为另一种网络模拟，剩余的总线模拟不是时序特定的方法，但是出于实验目的，可以在真实的物理层上执行许多时序问题，例如仲裁延迟、抖动、高负载行为等。因此，可以验证其他模拟方法。
批注：没有理解这部分如何做，但是我想到了之前看到的开源UDS协议中的checker测试，会不会是同一类方法？
处理器在环仿真 (PIL)
用于确定时序属性，例如特定软件系统的 SPECIFIC PROPERTY Execution Time 或 GENERIC PROPERTY Load。因此，编译后的软件将在评估板、原型硬件或实际 ECU 上的嵌入式目标处理器中执行。为了能够正确执行软件，将模拟所需的运行时环境。仿真平台激励并调用被调查的软件。在执行期间，捕获所需的输出数据。分析输出数据以获得所需的时序特性。要执行 PIL，必须提供可分析的可执行文件（例如 elf 文件）和用于刺激的输入向量。PIL 模拟的结果应使用时序方法的定义、描述和分类中描述的替代方法的结果进行验证。
将用于 PIL 的输入激励向量需要以达到物理上可能的最高代码覆盖率的方式激励软件。 输入激励向量的质量应显示在单独的“输入激励向量验收测试”中，以证明适当的覆盖范围。 结果的准确性在很大程度上取决于输入刺激向量的质量。
捕获输出数据的跟踪解决方案必须能够测量定义的分析点之间的执行时间。分析点定义了测量的起点和终点。
相比HIL，这个能够提前发现什么呢？具体的做法又应该如何做呢？
离散事件模拟 (DES)
用于模拟系统的动态行为。它将系统的运行建模为时间上的离散事件序列。每个事件都发生在特定的时刻，并标志着系统状态的变化。只要系统的时序模型可用，就可以应用该方法。这种方法的结果是系统的时序特性。系统的时序模型必须可用，结果的准确性在很大程度上取决于输入模型的质量。
批注：这个可能是HIL或者MIL要做的，但是，这部分如何用来测试时间相关的信息我还真没有什么了解。
HIL
前面的理解看起来还是牵强附会，HIL来了。
硬件在环仿真 (HIL) 可用于确定时序属性，例如特定 ECU 软件的 GENERIC PROPERTY 响应时间或 GENERIC PROPERTY 负载。
要进行 HIL 仿真，必须将软件集成到实际的 ECU 中。ECU 连接到所谓的硬件在环模拟器，该模拟器能够模拟 ECU 正常功能所需的汽车环境。在模拟过程中，捕获所需的输出数据。分析输出数据以获得所需的时序特性。
输入激励向量需要以达到最高物理可能代码覆盖率的方式激励 ECU 软件。结果的准确性在很大程度上取决于输入刺激向量的质量。
跟踪解决方案必须能够测量定义的分析点之间的执行时间。分析点定义测量的起点和终点。
测量跟踪
ECU 级别的测量
定时测量通常基于由 RTOS 调用的钩子程序。分析真实系统并提供观察到的时序信息。
网络级测量
定时测量是通过连接到真实网络硬件的特殊硬件完成的。根据协议和应用的测量设备，在相关 <schedulable> 传输期间的不同时间点印上时间戳。 精度由跟踪装置给出，并应满足采样定理。
跟踪观察真实系统
跟踪意味着持续记录测量数据流。这可以是记录离散事件或来自时间连续源的采样和量化数据以及时间戳。对于专用事件，时间戳与事件信息一起放置在跟踪缓冲区中。事件的选择可以是非常细粒度的，例如允许重构每个机器指令的执行的流跟踪，或者是粗粒度的，例如仅在跟踪调度相关事件时。 跟踪可以基于仪器（即软件修改）或特殊跟踪硬件。跟踪可以离线可视化和分析，例如 用于调试目的。 可以从跟踪中提取不同种类的时序信息。有时必须包含隐式协议开销才能进行正确的计算（例如，用于 CAN 负载计算的填充位）。
确定不同方法的可比性
一方面比较分析，另一方面模拟/测量，载荷应在长时间限制内（在相同边界条件下）一致性。
如果以相同的方式选择所有参数，则差异将消失。通常，模拟和观察以相同的方式产生乐观近似，具体取决于样本/探针大小（测量/模拟时间）。
为了比较不同方法（尤其是模拟/分析和测量）的结果，强烈建议检查所有 <schedulables> 都包含在输出中。
批注：有些没理解，为什么调度表放到输出中在不同的方法中能够起到这么大的影响。同样不理解的点，没有调度表这个测量如何进行实质的量化呢？
实施
推导网络或ECU 负载的方法的实施取决于所考虑的方法，即分析、模拟或测量。实现细节可以在相应的具体方法中找到。
小结：这一段的信息量其实还是很大的，介绍了几种不同的测试方法以及本身的一些特点。同时，针对不同方法之间的可比性进行了描述，但是可比性这部分我个人没有理解透彻。或许，这部分章节，后面还是需要回顾一下的。
