Timing Extensions
参考文献¶
[1] Specification of Timing Extensions for Classic Platform
AUTOSAR_CP_TPS_TimingExtensions
[2] Specification of Timing Extensions for Adaptive Platform
AUTOSAR_AP_TPS_TimingExtensions
AUTOSAR_FO_TPS_StandardizationTemplate
AUTOSAR_FO_RS_Main
[5] Timing Analysis and Design
AUTOSAR_FO_TR_TimingAnalysis
1. 引言¶
本文档定义对 AUTOSAR 时序扩展规范 [1] 和 [2] 施加的需求。总体上，AUTOSAR 时序扩展规范应同时支持两个 AUTOSAR 平台，即经典平台和自适应平台。因此，第 2 章分为三个小节：第 2.1 节包含对两个平台都施加的需求，第 2.2 节包含仅对经典平台施加的需求，第 2.3 节包含仅对自适应平台施加的需求。
1.1. 本文档的范围¶
本文档收集对时序模型（Timing Model）及其纳入 AUTOSAR 模板的需求。
时序模型的主要目标是用时序信息扩展 AUTOSAR 模板，以支持系统时序行为的分析和验证。
本文档收集的需求将由 AUTOSAR 时序扩展规范 [1] 和 [2] 满足。
1.2. 文档约定¶
AUTOSAR 文档中需求的表述遵循约束 TPS_STDT_00078 规定的表格，见 Standardization Template 的「Support for Traceability」章（[3]）。
需求的表达应使用约束 TPS_STDT_00053 规定的义务表达动词形式，见 Standardization Template 的「Support for Traceability」章（[3]）。
1.3. 指南¶
应引用既有规范（以单一需求的形式）。与这些规范的差异作为附加需求规定。所有需求应具有以下属性：
- 冗余性（Redundancy）
需求不得在一个需求内部或其他需求中重复。
- 清晰性（Clearness）
所有需求只允许一种解释。使用的、术语表中没有的技术术语必须加以定义。
- 原子性（Atomicity）
每个需求应只包含一条需求。如果一个需求无法再拆分为更多需求，则该需求是原子的。
- 可测试性（Testability）
需求应能够通过分析、评审或测试加以检验。
- 可追溯性（Traceability）
需求的来源和状态应始终可见。
2. 需求¶
本章描述作为 AUTOSAR 时序扩展规范 [1] 和 [2] 基础的全部需求。这些需求可追溯至主要需求 [4]。
2.1. 平台无关需求¶
本节定义对所有 AUTOSAR 平台（即 AUTOSAR 经典平台、AUTOSAR 自适应平台和 AUTOSAR 抽象平台）施加的需求。
2.1.1. 时序属性¶
| 描述 | AUTOSAR 模板应提供描述系统动态时序属性的手段，这些属性由计算、通信和其他硬件资源的消耗决定。 |
|---|---|
| 理由 | 在 AUTOSAR 模板中描述时序属性，是在流程早期分析和验证系统时序行为或预测其行为的基本前提。 |
| 用例 | 时序行为的分析与验证、修改影响的早期预测、硬件选型（dimensioning）支持、系统配置优化。另见 3.1.1、3.1.2、3.1.3、3.1.4、3.2.1、3.2.2、3.2.3、3.3.1、3.3.2 和 3.3.3 节 |
| 依赖项 | - |
| 适用平台 | AP、CP |
| 支撑材料 | - |
2.1.2. 时序约束¶
| 描述 | AUTOSAR 模板应提供以明确定义的语义描述时序约束（例如软件和硬件延迟、输入/输出延迟、同步和执行顺序）的手段。此外，时序约束的作用域和边界应被显式描述。 |
|---|---|
| 理由 | 在 AUTOSAR 模板中描述时序约束，是正式捕获对系统时序行为的期望和限制的基本前提；这些期望和限制指导系统生成过程，并可用于验证给定的系统配置。 |
| 用例 | 时序行为的分析与验证、硬件选型支持、系统配置优化。另见 3.1.1、3.1.2、3.1.3、3.1.4、3.2.1、3.2.2、3.2.3、3.3.1、3.3.2 和 3.3.3 节 |
| 依赖项 | §2.1.4 |
| 适用平台 | AP、CP |
| 支撑材料 | - |
2.1.3. 时序约束的可选性¶
| 描述 | AUTOSAR 模板中时序约束的使用应是可选的。 |
|---|---|
| 理由 | 通常只对有限数量的（例如安全相关的）子系统规定时序约束，而不对整个系统规定。 |
| 用例 | 时序行为的分析与验证 |
| 依赖项 | - |
| 适用平台 | AP、CP |
| 支撑材料 | - |
2.1.4. 事件链¶
| 描述 | AUTOSAR 模板应提供描述时序特定事件链（event chain）的手段。事件链用作附加时序约束的主体。它描述具有功能依赖关系的两个可观测事件（称为激励（stimulus）和响应（response））之间的时间关联。 |
|---|---|
| 理由 | 事件链是定义时序约束的作用域和语义的基本前提。 |
| 用例 | 时序行为的分析与验证。另见 3.1.1、3.1.2、3.1.3、3.1.4、3.2.1、3.2.2、3.2.3、3.3.1、3.3.2 和 3.3.3 节 |
| 依赖项 | - |
| 适用平台 | AP、CP |
| 支撑材料 | - |
2.1.5. 事件链的结构¶
| 描述 | 应能够将事件链组织为层级结构。也就是说，事件链可以由任意事件子链构建。层级的叶子是原子事件链。原子事件链的定义是：激励和响应由交互语义明确界定。 |
|---|---|
| 理由 | 分层的事件链结构支持时序约束的可扩展性和演进。 |
| 用例 | 时序行为的分析与验证。另见 3.1.1、3.1.2、3.1.3、3.1.4、3.2.1、3.2.2、3.2.3、3.3.1、3.3.2 和 3.3.3 节 |
| 依赖项 | §2.1.4 |
| 适用平台 | AP、CP |
| 支撑材料 | - |
2.1.6. 事件链的触发行为¶
| 描述 | AUTOSAR 模板应提供描述事件链触发行为（例如周期性、偶发性和任意性）的手段。 |
|---|---|
| 理由 | 对事件链时序约束的分析和验证，需要对相应激励和响应事件的出现特征作出假设。 |
| 用例 | 时序行为的分析与验证。另见 3.1.1、3.1.2、3.1.3、3.1.4、3.2.1、3.2.2、3.2.3、3.3.1、3.3.2 和 3.3.3 节 |
| 依赖项 | §2.1.4 |
| 适用平台 | AP、CP |
| 支撑材料 | - |
2.1.7. 事件链的同步¶
| 描述 | AUTOSAR 模板应提供描述多条事件链（其激励和响应事件可能相互独立）同步的时序约束的手段。 |
|---|---|
| 理由 | 当考虑冗余通信时，同步是一个关键问题。 |
| 用例 | 时序行为的分析与验证。另见 3.1.1、3.1.2、3.1.3、3.1.4、3.2.1、3.2.2、3.2.3、3.3.2 和 3.3.3 节 |
| 依赖项 | §2.1.2、§2.1.4 |
| 适用平台 | AP、CP |
| 支撑材料 | - |
2.1.8. 多个异步时基¶
| 描述 | AUTOSAR 模板应提供描述多个异步时钟/时基及其相互关系的手段。 |
|---|---|
| 理由 | 在联网系统中，基于多个异步时基描述同步事件是合理的。 |
| 用例 | 时序行为的分析与验证。另见 3.1.1、3.1.2、3.1.4、3.2.1、3.2.2、3.2.3、3.3.2 和 3.3.3 节 |
| 依赖项 | - |
| 适用平台 | AP、CP |
| 支撑材料 | - |
2.1.9. 时序属性和约束的有效性¶
| 描述 | AUTOSAR 模板应提供描述时序属性和约束有效性的手段，例如针对特定的硬件或软件配置。 |
|---|---|
| 理由 | 为了正确使用时序属性和约束，必须知道它们获得的上下文：例如 WCET 只对特定的实现和目标平台有效。 |
| 用例 | 时序行为的分析与验证。另见 3.1.1、3.1.2、3.1.3、3.1.4、3.2.1、3.2.2、3.2.3、3.3.1、3.3.2 和 3.3.3 节 |
| 依赖项 | §2.1.1、§2.1.2 |
| 适用平台 | AP、CP |
| 支撑材料 | - |
2.1.10. 模式依赖¶
| 描述 | AUTOSAR 模板应提供描述时序属性和约束对系统和 ECU 级所定义运行模式依赖关系的手段。 |
|---|---|
| 理由 | 依据模式的不同，系统的行为可能改变，这会影响系统的时序特性。 |
| 用例 | 时序行为的分析与验证。另见 3.1.1、3.1.2、3.1.3、3.1.4、3.2.1、3.2.2、3.2.3、3.3.1、3.3.2 和 3.3.3 节 |
| 依赖项 | §2.1.1、§2.1.2、§2.1.9 |
| 适用平台 | AP、CP |
| 支撑材料 | - |
2.1.11. 传感器/执行器延迟¶
| 描述 | AUTOSAR 模板应提供描述物理传感器采集（或物理执行器变化）与相应数据对（来自）处理该传感器（或执行器）的软件组件可用（或提供）之间的时间关系的手段。 |
|---|---|
| 理由 | 该信息可用于规定物理传感器（或执行器）与相应传感器（或执行器）软件组件之间数据流的时间延迟，而无需指向具体的硬件实现。 |
| 用例 | 时序行为的分析与验证。另见 3.1.1、3.1.2、3.1.3、3.1.4、3.2.1、3.2.2、3.2.3、3.3.1、3.3.2 和 3.3.3 节 |
| 依赖项 | §2.1.2 |
| 适用平台 | AP、CP |
| 支撑材料 | - |
2.1.12. 时序扩展的部分元素应可使用蓝图¶
| 描述 | 时序扩展应能够为元素（即端口接口的元素，属于应用接口规范的一部分）规定时序约束。 |
|---|---|
| 理由 | 应用接口规范中包含的信息应标注允许的数据年龄、周期等。 |
| 用例 | - |
| 依赖项 | §2.1.1 |
| 适用平台 | AP、CP |
| 支撑材料 | - |
2.1.13. 事件上的同步约束¶
| 描述 | 时序扩展应能够对两个或多个时序描述事件施加同步约束。 |
|---|---|
| 理由 | 在构建系统时，需要规定事件的出现应是同步的，例如转向信号指示灯、防抱死系统（其中来自多个车轮的信息很重要）的情形。 |
| 用例 | - |
| 依赖项 | §2.1.1 |
| 适用平台 | AP、CP |
| 支撑材料 | - |
2.1.14. AUTOSAR 方法论支持¶
| 描述 | 时序扩展应提供支持复用以及使用已在 SWC 类型级规定的时序模型的手段。 |
|---|---|
| 理由 | 时序扩展缺乏以高效方式支持复用的能力。为实现这一点，时序扩展应提供利用来自不同时序视图的时序模型的手段。 |
| 用例 | - |
| 依赖项 | §2.1.1 |
| 适用平台 | AP、CP |
| 支撑材料 | - |
2.1.15. 对系统级逻辑执行时间的支持¶
| 描述 | AUTOSAR 模板应提供支持描述系统级逻辑执行时间（SL-LET）的手段。特别地，应描述以下内容： * SL-LET 区间的参数：长度、重复类型和重复 * SL-LET 区间之间的关系，例如偏移、间隙和重叠 * 在 SL-LET 区间的开始和结束处交换的数据 * SL-LET 区间的（分层）组合 * 与某个 SL-LET 区间关联的 LET 区间（仅 CP） |
|---|---|
| 理由 | SL-LET 可用于在不同设计阶段（分别在不同的抽象层级上）描述时间确定性的数据流。SL-LET 区间可以被细化/分解，并可能与 CP 中的 LET 区间关联。SL-LET 区间指向被交换的数据类型（例如 SW 组件的端口），而 LET 区间指向一组可执行实体。 |
| 用例 | 设计和定义应用的时序行为，以及时序行为的分析与验证。 |
| 依赖项 | §2.1.1、§2.1.2、§2.1.3、§2.1.4、§2.1.6 |
| 适用平台 | AP、CP |
| 支撑材料 | [5] |
2.2. 经典平台需求¶
2.2.1. 发送方-接收方通信中的环回信号流¶
| 描述 | 应能够在 VFB 级标注 SWC 之间的连接，以指示发送方-接收方通信需要缓冲。 |
|---|---|
| 理由 | 当软件组件使用发送方-接收方通信连接协同工作时，这种组合中隐含着一个自然的信号流：一个 SW 组件产生一些数据，随后由另一个软件组件消费并进一步处理。当这样的设置还包含信号环回时，就无法再确定哪些信号流要在一次遍历中处理、哪些信号流应作为下一次执行的环回进行缓冲。 |
| 用例 | 一种使用多个软件组件实现、并将算法结果作为输入反馈回去的滤波算法。当标注了这个环回信号流时，其他软件组件之间的关系可以按顺序安排，并且可以确定相关可执行实体的执行顺序。闭环控制系统中时序行为的分析与验证。另见 3.1.2、3.1.3 和 3.1.4 节 |
| 依赖项 | §2.1.1、§2.1.3 |
| 适用平台 | CP |
| 支撑材料 | 面向 BSW 与 RTE 特性的需求（Requirements on BSW & RTE Features） |
2.2.2. 时序资源的规定¶
| 描述 | AUTOSAR 模板应提供对可执行实体施加执行时间约束的手段，以确保时间资源消耗可控。 |
|---|---|
| 理由 | 将 SWC 映射到 ECU 的主要准则之一，是分配给单个 ECU 的完整 SW 系统的资源需求。为了估计软件系统所需的资源总量，必须拥有每个被分配 SWC 的信息。就此用例而言，相关的 CPU 特定资源信息是最坏情况执行时间（WCET）。再次请注意，整体用例无法完全在本文档的范围内覆盖，因为资源消耗的最终评估只有在 ECU 配置的上下文中才可行。另一方面，ECU 配置范围内的评估需要通过在软件组件范围内规定资源声明来准备。该约束主要由如下事实造成：相关的基础软件配置在工作流中只能在 ECU 配置的范围内首次可用。显然，基础软件在或大或小的程度上贡献于整体资源消耗。 |
| 用例 | 出于集成目的，需要规定可执行实体的最坏情况执行时间，以确保在时序需求方面的正确集成。 |
| 依赖项 | - |
| 适用平台 | CP |
| 支撑材料 | - |
2.2.3. 可运行实体¶
| 描述 | AUTOSAR 模板应提供对不同可运行实体执行顺序规定约束的手段。 |
|---|---|
| 理由 | 在某些情形下，可运行实体之间的数据依赖无法用于推导一组可运行实体的执行顺序。要么这种数据依赖是含糊的、因而无法得出具体的执行顺序，要么可运行实体之间不存在数据依赖而需要强制规定执行顺序。 |
| 用例 | 时序行为的分析与验证。另见 3.1.1 节 |
| 依赖项 | RS_SWCT_00090 |
| 适用平台 | CP |
| 支撑材料 | - |
2.2.4. SW 组件的时序需求¶
| 描述 | SW 组件模板必须允许规定 SW 组件每个可运行实体的时序需求（例如）： * 周期 * 反应时间 |
|---|---|
| 理由 | SW 组件模板必须允许描述： * 它必须以什么频率运行 * 诸如硬件或软件实体状态变化之类的激励与系统期望反应（例如响应、执行器激活）之间的时间 |
| 用例 | - |
| 依赖项 | §2.2.2 |
| 适用平台 | CP |
| 支撑材料 | - |
2.2.5. VFB 级端口接口的预定义事件¶
| 描述 | 时序扩展应提供专用于端口的时序描述事件类型，例如触发端口（trigger port）。 |
|---|---|
| 理由 | 由于引入了新的端口类型（例如触发端口），时序扩展应提供特定类型的时序描述事件以支持此类端口。 |
| 用例 | - |
| 依赖项 | §2.1.1 |
| 适用平台 | CP |
| 支撑材料 | - |
2.2.6. 对指示变量访问的事件的支持¶
| 描述 | 时序扩展应提供引用可执行实体（即可运行实体）访问变量的时间点的手段。 |
|---|---|
| 理由 | 在某些情形下，需要引用可执行实体访问变量数据的时间点，并能够对这些时序描述事件施加时序约束。例如，在 VFB 时序视图中，对变量数据原型被接收的时间点施加年龄（age）约束。但可能有多个可执行实体访问这样的变量数据，而其中一些可执行实体可能具有不同的年龄时序约束。为了避免此类可运行实体被映射到激活频率高于所需的任务，最好标注特定的变量访问。 |
| 用例 | - |
| 依赖项 | §2.1.1 |
| 适用平台 | CP |
| 支撑材料 | - |
2.2.7. 对逻辑执行时间的支持¶
| 描述 | AUTOSAR 模板应提供支持描述逻辑执行时间（LET）（即时间确定性）的手段。特别地，应描述以下内容： * LET 区间的参数：长度、重复类型和重复 * LET 区间之间的关系，例如偏移、间隙和重叠 * 应在 LET 上下文中执行的可执行实体和/或可执行实体组 * 应在 LET 区间上下文中进行的数据交换，即可执行实体和/或可执行实体组之间时间确定性的数据交换 * 在若干可执行实体之间规定执行顺序的手段 |
|---|---|
| 理由 | 时间确定性是嵌入式分布式实时系统的关键特性，它确保： * 由于确定性的数据交换和可执行实体的执行，此类系统可靠运行； * 可以对此类系统进行分析和验证，以便在开发流程早期进行时序分析。 |
| 用例 | 设计和定义应用的时序行为，以及时序行为的分析与验证。 |
| 依赖项 | §2.1.1、§2.1.2、§2.1.3、§2.1.4、§2.1.6 |
| 适用平台 | CP |
| 支撑材料 | - |
2.2.8. 对规定同步的支持¶
| 描述 | AUTOSAR 模板应提供支持规定可执行实体和/或可执行实体组之间同步的手段。 |
|---|---|
| 理由 | 在某些情形下，仅规定可执行实体的执行顺序、并使用同步时序约束表达「可执行实体不得在其他实体完成执行之前执行」是不充分的。AUTOSAR 时序扩展提供的执行顺序约束允许在可执行实体之间规定顺序，但不提供手段来规定在此顺序中的何处应使用同步手段，以保证若干可执行实体在其他可执行实体被允许开始执行之前完成执行。AUTOSAR 时序扩展提供的同步时序约束允许就时间特性（即时间区间）规定同步。 |
| 用例 | 确保在不同任务和不同核上执行的可执行实体执行期间的正确同步。 |
| 依赖项 | §2.2.7 |
| 适用平台 | CP |
| 支撑材料 | - |
2.2.9. 对软件集群的支持¶
| 描述 | AUTOSAR 模板应提供支持为软件集群规定时序的手段。 |
|---|---|
| 理由 | AUTOSAR 的灵活性允许规定各种软件集群。一些软件集群提供时间和动态资源，另一些软件集群需要时间和动态资源。这些供给与需求使用时序扩展的能力、在考虑一个或多个软件集群范围的情况下加以描述。 |
| 用例 | - |
| 依赖项 | - |
| 适用平台 | CP |
| 支撑材料 | - |
2.3. 自适应平台需求¶
本节定义专门对 AUTOSAR 自适应平台施加的需求。
2.3.1. 对面向服务通信的支持¶
| 描述 | AUTOSAR 模板应提供支持为面向服务的通信规定时序的手段。 |
|---|---|
| 理由 | AUTOSAR 自适应平台为自适应应用之间的通信提供面向服务的通信。 |
| 用例 | - |
| 依赖项 | - |
| 适用平台 | AP |
| 支撑材料 | - |
3. 支持的用例¶
AUTOSAR 中的时序信息应支持以下用例。
以下各节描绘的功能用例源自多个预研项目中实现并积累经验的实际应用。这些用例收集自底盘应用。它们由车辆功能的功能实现导出。因此，以下描述不描绘具体应用，而是解释利用时序相关问题的底盘功能的共同特性。这些特性包括：
- 主要由闭环控制特性驱动的时序约束
- 由 FlexRay 总线强制的等距时间片内的数据传输
- 与总线调度同步的应用数据计算
3.1. 端到端时序¶
AUTOSAR 时序模型所给出信息的一个典型用例是时序分析。时序分析是一个相当宽泛的术语，可以拆分为获得整体端到端时序分析所需的多种子活动。可以区分单个资源（一个 ECU 或总线）的局部时序分析和多个互连资源（ECU 和总线）的全局时序分析。时序分析结果可通过将分析结果与给定的时序约束比较而用于验证。
3.1.1. 用例 1：局部时序分析（调度分析）¶
工程师可能希望在不考虑全局依赖的情况下分析单个资源的局部时序行为。因此，局部时序分析处理关于单个总线或 ECU（该 ECU 上的一个处理器）的隔离调度问题。例如，在早期设计阶段，这有助于了解资源利用率的概貌。此外，局部时序分析还可用于优化目的。
局部时序分析是端到端分析的基础。这将在以下小节中阐述。
3.1.2. 用例 2：开环控制系统中端到端时序的分析¶
典型的开环控制系统至少包含传感器、控制器和执行器组件。为了分析这样的控制系统，需要端到端时序。端到端时序的分析包括：
- 识别不同的事件链和备选事件链分段。
- 端到端延迟的分析
- 审视不同执行顺序对时序属性（即端到端延迟）的影响。
- 确定事件链和/或执行顺序中的自由度。
- 选择最合理的（即最可靠或最有效的）事件链。
3.1.3. 用例 3：闭环控制系统中端到端时序的分析¶
与开环控制系统中端到端时序的分析相比，闭环控制系统包含一个或多个反馈环。分析需要识别和描述这些反馈环以及如何按时序处理它们。此外，时序属性的影响应可分析。
3.1.4. 用例 4：端到端时序的验证¶
基于端到端时序分析期间获得的结果，应能够验证系统的实际/给定时序行为是否满足其约束。具体示例包括响应时间、缓冲区大小或吞吐量的验证。在所有情形下，都可以使用分析方法或仿真/测量的结果来确定待验证的系统时序行为，并与给定的时序约束集比较。
3.2. 同步¶
时序分析中的同步关注同一功能上下文内并发事件链的时间关联。如果两个或多个事件链的相应激励和/或响应事件在时间上以某个预定义容差重合，则称它们是同步的。
因此应考虑以下用例。
3.2.1. 用例 5：多传感器系统中的传感器数据融合¶
一辆现代汽车通常在其车载网络中配备多个传感器。这些传感器可被许多软件功能使用。其中一些功能需要同时来自不同传感器的数据，以计算传感器信息的更复杂关联。
包含传感器数据融合的功能示例有 ACC（自适应巡航控制，需要雷达和车轮数据）或 PDC（驻车距离控制，需要同一类型的多个传感器以获得整体环境模型）。
对这类功能的时序分析不能只孤立地聚焦于每个传感器各自的信号路径。更有意思的部分是该功能所涉及的这些路径的同步。因此，时序模型必须能够表达多条事件链的同步性约束，并提供验证它们所需的信息。
3.2.2. 用例 6：执行器同步¶
除前面提到的传感器数据融合用例之外，还必须能够同步执行器。现代控制系统包含分布式智能执行器，其同步对于确保同时操作至关重要。该用例应用的一个示例是同步车门开启功能。一般而言，此类用例的共同行为是：对执行器的访问由同一激励事件触发。如果访问应当被同步，则必须能够规定这样的时序约束。
一个典型的示例是危险警告灯的同步。首先，为每个指示灯规定事件链，对危险警告灯开关的状态变化与指示灯的状态变化（例如闪烁）之间的时序流建模。多条事件链的激励事件相互关联，即开关的变化。对于响应事件（即指示灯的激活），必须能够规定同步约束，以限制响应事件的出现，即强制它们的同步激活。
3.2.3. 用例 7：总线同步与网关¶
网关同步存在多种场景。网关可以与一个或多个 FlexRay 总线同步，以减少网关任务的发送或读取延迟。还应能够同步多个网关活动，以优化后续 CAN 上的传输时间。
3.3. 早期预测¶
上一节描绘了一般用例，其中合适的、增强时序的 AUTOSAR 元模型是不同领域端到端时序分析的使能器。在下面关于早期预测的小节中，我们讨论这样的分析框架可用于在设计阶段实现时序分析的用例。由此，可以进行时序行为的早期预测，尽早解决设计中的潜在弱点。时序验证基于系统设计或规范阶段的估计值或部分已知的时序信息进行。
3.3.1. 用例 8：添加组件引起的修改影响¶
组件集成是一个多方面的问题。首先，待集成的组件必须提供时序数据，以便分析（以及仿真）该组件是否适合目标系统，并确定对目标系统的影响。因此，目标系统对待集成组件施加一些时序约束。另一方面，待集成的组件为了正常运行也对目标系统施加一些时序约束。
与硬件选型用例相比，该用例中的时序不确定性相当有限。时序属性和大部分约束在系统中已经众所周知。待集成组件的时序属性（以及可能的约束）也至少部分已知，或可以粗略估计提供。尽管如此，集成附加组件对时序的影响仍可被分析和验证。即使新组件尚未实现（即属性完全基于猜测值），该用例也可以在早期设计阶段避免昂贵的软件重设计甚至硬件修改（例如提高 ECU 时钟频率）。
该用例的主要原因是：由于错误的时序行为，向既有系统集成的软件可能导致优先级反转、死锁等意外现象。因此，简单计算既有（比方说 70 percent CPU 占用）和新（例如 20 percent）软件并将其相加，不是对时序行为的可接受考虑。
3.3.2. 用例 9：硬件选型的支持¶
硬件资源1显著影响软件的时序行为。另一方面，硬件成本应限制在绝对最小值，因为它们主导单件成本。因此，为了最小化成本，直接的做法是在硬件设计空间2中搜索，使软件组件能够提供勉强满足时序约束的时序属性。重要的基本问题可能是 ECU 的时钟频率、总线的带宽或内存模块的访问速度等。一个基本要求是：硬件配置对时序属性的影响是已知的（至少作为猜测值）。如果这一点成立，则可以针对特定硬件设置验证时序行为，并在早期设计阶段选择成本最小的解决方案。
例如计算能力和带宽，也包括内存的访问时间。
对于该用例，假设固定的系统拓扑。
3.3.3. 用例 10：拓扑决策¶
确定特定拓扑的主要目标是依据预定义的质量准则优化整个系统。这些准则可能包括最大延迟、最小总线负载等。所提到的决策基于系统所处的状态作出。为了确定该状态，需要可分析的信息以提供对系统特性的访问。
就时序而言，一个有意义的优化准则是传感器数据在其处理时的最小数据年龄。考虑一个通信周期长度为 10ms 的基于 FlexRay 的通信系统。如果传感器 ECU 每 40ms 提供一次数据，则有充分理由使用周期复用，将某个特定时隙在每个第 4 个通信周期分配给传感器 ECU。然而，要达到最小数据年龄的目标，还需要附加信息。因此，定义实际分配给传感器 ECU 的 FlexRay 时隙（与其他数据甚至其他 ECU 复用）需要关于传感器数据可以写入 FR 通信控制器缓冲区的确切时间点的精确知识。该时隙应尽可能靠近传感器在硬件缓冲区中可用的时间。例如，这可能包括相对于某个参考事件（如 FR 周期开始）估计的抖动值和释放偏移。
4. 变更历史¶
请注意，本章中的列表还包括在后续版本中已从规范中移除的需求项。这些需求项在文档中不作为超链接出现。
4.1. 本文档依据 AUTOSAR 版本 4.1.1 的变更历史¶
4.1.1. R4.1.1 中新增的需求¶
表4.1：4.1.1 中新增的规范项
| 标题 |
|---|
| 时序资源的规定（原 RS_SWCT_02050） |
| 可运行实体的执行顺序（原 RS_SWCT_03060） |
| SW-C 的时序需求（原 RS_SWCT_03080） |
| 面向软件组件描述的时序资源规定 |
| 可运行实体的执行顺序 |
| SW 组件的时序需求 |
| 时序扩展的部分元素应可使用蓝图 |
| 事件上的同步约束 |
| VFB 级端口接口的预定义事件 |
| AUTOSAR 方法论支持 |
| 对指示变量访问的事件的支持 |
| 装配连接器上的年龄约束（Age constraint on assembly connector） |
4.1.2. R4.1.1 中变更的需求¶
无
4.1.3. R4.1.1 中删除的需求¶
无
4.2. 本文档依据 AUTOSAR 版本 4.1.2 的变更历史¶
4.2.1. R4.1.2 中新增的需求¶
无
4.2.2. R4.1.2 中变更的需求¶
无
4.2.3. R4.1.2 中删除的需求¶
无
4.3. 本文档依据 AUTOSAR 版本 4.1.3 的变更历史¶
4.3.1. R4.1.3 中新增的需求¶
表4.2：4.1.2 中移除的规范项（Removed Specification Items in 4.1.2）
| 标题 |
|---|
| 装配连接器上的年龄约束。注：RS_TIMEX_00009 的重复 |
无
4.3.2. R4.1.3 中变更的需求¶
无
4.3.3. R4.1.3 中删除的需求¶
无
4.4. 本文档依据 AUTOSAR 版本 4.2.1 的变更历史¶
4.4.1. R4.2.1 中新增的需求¶
无
4.4.2. R4.2.1 中变更的需求¶
无
4.4.3. R4.2.1 中删除的需求¶
无
4.5. 本文档依据 AUTOSAR 版本 4.2.2 的变更历史¶
4.5.1. R4.2.2 中新增的需求¶
无
4.5.2. R4.2.2 中变更的需求¶
无
4.5.3. R4.2.2 中删除的需求¶
无
4.6. 本文档依据 AUTOSAR 版本 4.3.0 的变更历史¶
4.6.1. R4.3.0 中新增的需求¶
无
4.6.2. R4.3.0 中变更的需求¶
无
4.6.3. R4.3.0 中删除的需求¶
无
4.7. 本文档依据 AUTOSAR 版本 4.3.1 的变更历史¶
4.7.1. R4.3.1 中新增的需求¶
无
4.7.2. R4.3.1 中变更的需求¶
无
4.7.3. R4.3.1 中删除的需求¶
无
4.8. 本文档依据 AUTOSAR 版本 4.4.0 的变更历史¶
4.8.1. R4.4.0 中新增的需求¶
4.8.2. R4.4.0 中变更的需求¶
表4.3：4.4.0 中新增的规范项（Added Specification Items in 4.4.0）
| 标题 |
|---|
| 对逻辑执行时间的支持 |
| 对规定同步的支持 |
无
4.8.3. R4.4.0 中删除的需求¶
无
4.9. 本文档依据 AUTOSAR 版本 R19-11 的变更历史¶
4.9.1. R19-11 中新增的需求¶
无
4.9.2. R19-11 中变更的需求¶
无
4.9.3. R19-11 中删除的需求¶
无
4.10. 本文档依据 AUTOSAR 版本 R20-11 的变更历史¶
4.10.1. R20-11 中新增的需求¶
表4.4：20-11 中新增的规范项（Added Specification Items in 20-11）
| 标题 |
|---|
| 对面向服务通信的支持 |
| 对软件集群的支持 |
4.10.2. R20-11 中变更的需求¶
无
4.10.3. R20-11 中删除的需求¶
无
4.11. 本文档依据 AUTOSAR 版本 R21-11 的变更历史¶
4.11.1. R21-11 中新增的需求¶
无
4.11.2. R21-11 中变更的需求¶
无
4.11.3. R21-11 中删除的需求¶
无
4.12. 本文档依据 AUTOSAR 版本 R22-11 的变更历史¶
4.12.1. R22-11 中新增的需求¶
表4.5：R22-11 中新增的需求
| 标题 |
|---|
| 对系统级逻辑执行时间的支持 |
4.12.2. R22-11 中变更的需求¶
无
4.12.3. R22-11 中删除的需求¶
无
4.13. 本文档依据 AUTOSAR 版本 R23-11 的变更历史¶
4.13.1. R23-11 中新增的需求¶
无
4.13.2. R23-11 中变更的需求¶
无
4.13.3. R23-11 中删除的需求¶
无