575 lines
28 KiB
Markdown
575 lines
28 KiB
Markdown
# AUTOSAR 时序扩展需求
|
||
|
||
> **AUTOSAR CP Release 4.4.0**
|
||
>
|
||
> 原文：*Requirements on Timing Extensions*（文档 ID 410）
|
||
>
|
||
> 翻译状态：**已完成 v1**（封面+前言+用例+需求+变更历史完整翻译）
|
||
>
|
||
> 对应原文 PDF：`MethodologyAndTemplates/AUTOSAR_RS_TimingExtensions.pdf`
|
||
>
|
||
> 翻译日期：Step 3 - P0 批量翻译
|
||
|
||
---
|
||
|
||
## 文档标识
|
||
|
||
| 字段 | 值 |
|
||
|------|-----|
|
||
| 文档标题（Document Title） | 时序扩展需求（Requirements on Timing Extensions） |
|
||
| 文档所有者（Document Owner） | AUTOSAR |
|
||
| 文档责任人（Document Responsibility） | AUTOSAR |
|
||
| 文档标识号（Document Identification No） | 410 |
|
||
| 文档状态（Document Status） | 正式版（Final） |
|
||
| 所属 AUTOSAR 标准 | Classic Platform |
|
||
| 所属标准版本 | 4.4.0 |
|
||
|
||
> 原文版权：© AUTOSAR — 机密文件
|
||
> 本中文译文仅供学习参考。
|
||
|
||
---
|
||
|
||
## 文档变更历史
|
||
|
||
| 日期 | 版本 | 变更人 | 变更说明 |
|
||
|------|------|--------|----------|
|
||
| 2018-10-31 | 4.4.0 | AUTOSAR Release Management | 新增需求 RS_TIMEX_00022 和 RS_TIMEX_00023 |
|
||
| 2017-12-08 | 4.3.1 | AUTOSAR Release Management | 编辑性修订 |
|
||
| 2016-11-30 | 4.3.0 | AUTOSAR Release Management | 编辑性修订 |
|
||
| 2015-07-31 | 4.2.2 | AUTOSAR Release Management | 编辑性修订 |
|
||
| 2014-10-31 | 4.2.1 | AUTOSAR Release Management | 编辑性修订 |
|
||
| 2013-10-31 | 4.1.2 | AUTOSAR Release Management | 移除 RS_TIMEX_00021（与 RS_TIMEX_00009 重复） |
|
||
| 2011-12-22 | 4.0.3 | AUTOSAR Administration | 新增 RS_TIMEX_00013 至 RS_TIMEX_00021，反映新支持特性 |
|
||
| 2009-12-18 | 4.0.1 | AUTOSAR Administration | 初始发布 |
|
||
|
||
---
|
||
|
||
## 目录
|
||
|
||
1. [本文档范围](#1-本文档范围)
|
||
2. [使用的约定](#2-使用的约定)
|
||
3. [用例与需求追溯](#3-用例与需求追溯)
|
||
4. [需求](#4-需求)
|
||
5. [支持的用例](#5-支持的用例)
|
||
6. [变更历史](#6-变更历史)
|
||
|
||
---
|
||
|
||
## 参考文献
|
||
|
||
- [1] Specification of Timing Extensions，AUTOSAR_TPS_TimingExtensions
|
||
- [2] Main Requirements，AUTOSAR_RS_Main
|
||
- [3] R. Henia, A. Hamann, M. Jersak, R. Racu, K. Richter, R. Ernst. *System Level Performance Analysis - The SymTA/S Approach*. IEE Proceedings Computers and Digital Techniques, 152(2): 148-166, 2005.
|
||
- [4] T. Pop, P. Eles, Z. Peng. *Holistic Scheduling and Analysis of Mixed Time/Event-Triggered Distributed Embedded Systems*. CODES 2002, pp. 187-192.
|
||
- [5] M. G. Harbour, J. J. Gutierrez Garcia, J. C. Palencia Gutierrez, J. M. Drake Moyano. *MAST: Modeling and Analysis Suite for Real-Time Applications*. ECRTS 2001, p. 125.
|
||
- [6] L. Thiele, S. Chakraborty, M. Naedele. *Real-Time Calculus for Scheduling Hard Real-Time Systems*. ISCAS 2000, pp. 101-104.
|
||
|
||
---
|
||
|
||
## 1 本文档范围
|
||
|
||
本文档收集对**时序模型（Timing Model）**及其在 AUTOSAR 模板中的整合方面的需求。
|
||
|
||
时序模型的主要目标是用时序信息扩展 AUTOSAR 模板，以便对系统的时序行为进行分析与验证。
|
||
|
||
本文档收集的需求将由 *AUTOSAR Specification of Timing Extensions* [1] 满足。
|
||
|
||
---
|
||
|
||
## 2 使用的约定
|
||
|
||
AUTOSAR 文档中需求的表示遵循 [TPS_STDT_00078] 中规定的表格。
|
||
|
||
用于表达义务的动词形式应遵循 [TPS_STDT_00053] 的规定。
|
||
|
||
---
|
||
|
||
## 3 用例与需求追溯
|
||
|
||
下表列出所有用例与主要需求，并将其链接到相关需求。
|
||
|
||
| 用例/主需求 | 描述 | 满足者 |
|
||
|--------------|------|--------|
|
||
| [RS_Main_00010] | AUTOSAR 应支持安全相关系统的开发 | [RS_TIMEX_00022], [RS_TIMEX_00023] |
|
||
| [RS_Main_00011] | AUTOSAR 应支持可靠系统的开发 | [RS_TIMEX_00022], [RS_TIMEX_00023] |
|
||
| [RS_Main_00050] | AUTOSAR 应为应用提供执行框架以实现并发的应用内控制流 | [RS_TIMEX_00022], [RS_TIMEX_00023] |
|
||
| [RS_Main_00130] | AUTOSAR 应提供硬件抽象 | [RS_TIMEX_00022], [RS_TIMEX_00023] |
|
||
| [RS_Main_00150] | AUTOSAR 应支持 AUTOSAR 应用软件的部署与重分配 | [RS_TIMEX_00022], [RS_TIMEX_00023] |
|
||
| [RS_Main_00200] | AUTOSAR 规范应允许资源高效实现 | [RS_TIMEX_00022], [RS_TIMEX_00023] |
|
||
| [RS_Main_00410] | AUTOSAR 应为应用软件常用例程提供规范以支持共享和优化 | [RS_TIMEX_00022], [RS_TIMEX_00023] |
|
||
| [RS_Main_01001] | AUTOSAR 应支持 ECU 内通信 | [RS_TIMEX_00022], [RS_TIMEX_00023] |
|
||
| [UC_TIMEX_00001] | 本地时序分析（调度分析） | RS_TIMEX_00001、00002、00004–00008、00010–00012 |
|
||
| [UC_TIMEX_00002] | 开环控制系统的端到端时序分析 | RS_TIMEX_00001、00002、00004–00012 |
|
||
| [UC_TIMEX_00003] | 闭环控制系统的端到端时序分析 | RS_TIMEX_00001、00002、00004–00012 |
|
||
| [UC_TIMEX_00004] | 端到端时序验证 | RS_TIMEX_00001、00002、00004–00012 |
|
||
| [UC_TIMEX_00005] | 多传感器系统中的传感器数据融合 | RS_TIMEX_00001、00002、00004–00008、00010–00012 |
|
||
| [UC_TIMEX_00006] | 执行器同步 | RS_TIMEX_00001、00002、00004–00008、00010–00012 |
|
||
| [UC_TIMEX_00007] | 总线同步 / 网关 | RS_TIMEX_00001、00002、00004–00008、00010–00012 |
|
||
| [UC_TIMEX_00008] | 增加组件导致的影响 | RS_TIMEX_00001、00002、00004–00006、00010–00012 |
|
||
| [UC_TIMEX_00009] | 硬件尺寸（dimensioning）支持 | RS_TIMEX_00001、00002、00004–00008、00010–00012 |
|
||
| [UC_TIMEX_00010] | 拓扑决策 | RS_TIMEX_00001、00002、00004–00008、00010–00012 |
|
||
|
||
---
|
||
|
||
## 4 需求
|
||
|
||
本章描述所有需求，这些需求是 *AUTOSAR Specification of Timing Extensions* [1] 的基础，并追溯到主要需求 [2]。
|
||
|
||
### 4.1 时序属性
|
||
|
||
#### ⌈[RS_TIMEX_00001] 时序属性⌋
|
||
|
||
| 属性 | 值 |
|
||
|------|-----|
|
||
| **类型** | 有效 |
|
||
| **描述** | AUTOSAR 模板应提供描述系统动态时序属性的手段，这些属性由计算、通信及其他硬件资源的消耗决定。 |
|
||
| **理由** | 在 AUTOSAR 模板中描述时序属性是分析和验证系统时序行为或在流程早期对其进行预测的必要前提。 |
|
||
| **用例** | 时序行为的分析与验证、修改影响的早期预测、硬件尺寸支持、系统配置优化 |
|
||
| **依赖** | 无 |
|
||
|
||
⌊(UC_TIMEX_00001 – UC_TIMEX_00010)
|
||
|
||
### 4.2 时序约束
|
||
|
||
#### ⌈[RS_TIMEX_00002] 时序约束⌋
|
||
|
||
| 属性 | 值 |
|
||
|------|-----|
|
||
| **类型** | 有效 |
|
||
| **描述** | AUTOSAR 模板应提供描述时序约束的手段，例如软硬件延迟、输入/输出延迟、同步、runnable 执行顺序约束（语义需明确定义）。此外，时序约束的范围与边界也应明确描述。 |
|
||
| **理由** | 在 AUTOSAR 模板中描述时序约束是正式地表达对系统时序行为的期望与限制的必要前提，这些约束指导系统生成过程，并可用于验证给定系统配置。 |
|
||
| **用例** | 时序行为的分析与验证、硬件尺寸支持、系统配置优化 |
|
||
| **依赖** | [RS_TIMEX_00004] |
|
||
|
||
⌊(UC_TIMEX_00001 – UC_TIMEX_00010)
|
||
|
||
### 4.3 时序约束的可选性
|
||
|
||
#### ⌈[RS_TIMEX_00003] 时序约束的可选性⌋
|
||
|
||
| 属性 | 值 |
|
||
|------|-----|
|
||
| **类型** | 有效 |
|
||
| **描述** | AUTOSAR 模板中时序约束的使用应为可选。 |
|
||
| **理由** | 通常仅对有限数量的（如安全相关的）子系统指定时序约束，而非整个系统。 |
|
||
| **用例** | 时序行为的分析与验证 |
|
||
|
||
⌊()
|
||
|
||
### 4.4 事件链（Event chains）
|
||
|
||
#### ⌈[RS_TIMEX_00004] 事件链⌋
|
||
|
||
| 属性 | 值 |
|
||
|------|-----|
|
||
| **类型** | 有效 |
|
||
| **描述** | AUTOSAR 模板应提供描述时序相关事件链的手段。事件链作为附加时序约束的对象。它描述两个可观察事件（称为 *stimulus* 与 *response*）之间的时间相关性，二者具有功能依赖。 |
|
||
| **理由** | 事件链是定义时序约束范围与语义的必要前提。 |
|
||
| **用例** | 时序行为的分析与验证 |
|
||
|
||
⌊(UC_TIMEX_00001 – UC_TIMEX_00010)
|
||
|
||
### 4.5 事件链的结构
|
||
|
||
#### ⌈[RS_TIMEX_00005] 事件链的结构⌋
|
||
|
||
| 属性 | 值 |
|
||
|------|-----|
|
||
| **类型** | 有效 |
|
||
| **描述** | 应能将事件链组织成层次结构。即事件链可由任意事件子链构造而成。层次结构的叶节点是**原子事件链（atomic event chains）**，其 stimulus 与 response 由交互语义明确定义。 |
|
||
| **理由** | 分层事件链结构支持时序约束的可伸缩性与可演进性。 |
|
||
| **依赖** | [RS_TIMEX_00004] |
|
||
|
||
⌊(UC_TIMEX_00001 – UC_TIMEX_00010)
|
||
|
||
### 4.6 事件链的触发行为
|
||
|
||
#### ⌈[RS_TIMEX_00006] 事件链的触发行为⌋
|
||
|
||
| 属性 | 值 |
|
||
|------|-----|
|
||
| **类型** | 有效 |
|
||
| **描述** | AUTOSAR 模板应提供描述事件链触发行为（如周期性、偶发性、任意性）的手段。 |
|
||
| **理由** | 分析与验证事件链的时序约束需要对相应 stimulus 与 response 事件的发生特征作出假设。 |
|
||
| **依赖** | [RS_TIMEX_00004] |
|
||
|
||
⌊(UC_TIMEX_00001 – UC_TIMEX_00010)
|
||
|
||
### 4.7 事件链的同步
|
||
|
||
#### ⌈[RS_TIMEX_00007] 事件链的同步⌋
|
||
|
||
| 属性 | 值 |
|
||
|------|-----|
|
||
| **类型** | 有效 |
|
||
| **描述** | AUTOSAR 模板应提供描述多个事件链同步的时序约束的手段（这些事件链可能具有独立的 stimulus 与 response 事件）。 |
|
||
| **理由** | 在考虑冗余通信时，同步是关键问题。 |
|
||
| **依赖** | [RS_TIMEX_00002], [RS_TIMEX_00004] |
|
||
|
||
⌊(UC_TIMEX_00001 – UC_TIMEX_00007, UC_TIMEX_00009, UC_TIMEX_00010)
|
||
|
||
### 4.8 多重异步时基
|
||
|
||
#### ⌈[RS_TIMEX_00008] 多重异步时基⌋
|
||
|
||
| 属性 | 值 |
|
||
|------|-----|
|
||
| **类型** | 有效 |
|
||
| **描述** | AUTOSAR 模板应提供描述多重异步时钟/时基及其相互关系的手段。 |
|
||
| **理由** | 在联网系统中，即便存在多重异步时基，描述同步事件也是合理的。 |
|
||
|
||
⌊(UC_TIMEX_00001 – UC_TIMEX_00007, UC_TIMEX_00009, UC_TIMEX_00010)
|
||
|
||
### 4.9 发送方-接收方通信中的回环信号流
|
||
|
||
#### ⌈[RS_TIMEX_00009] 发送方-接收方通信中的回环信号流⌋
|
||
|
||
| 属性 | 值 |
|
||
|------|-----|
|
||
| **类型** | 有效 |
|
||
| **描述** | 应能在 VFB 级别上对 SWC 之间的连接进行注解，以表明 sender-receiver 通信需要被缓冲。 |
|
||
| **理由** | 当软件组件通过 sender-receiver 通信协同工作时，组合中存在自然信号流，一个 SW-Component 产生数据被另一个消耗并进一步处理。当此设置也包含信号回环时，便无法判定哪部分信号流应在本轮处理，哪部分应缓冲作为下一次执行的回环。 |
|
||
| **用例** | 闭环控制系统中时序行为的分析与验证 |
|
||
| **依赖** | [RS_TIMEX_00001], [RS_TIMEX_00003] |
|
||
| **支撑材料** | Requirements on BSW & RTE Features |
|
||
|
||
⌊(UC_TIMEX_00002, UC_TIMEX_00003, UC_TIMEX_00004)
|
||
|
||
### 4.10 时序属性与约束的有效性
|
||
|
||
#### ⌈[RS_TIMEX_00010] 时序属性与约束的有效性⌋
|
||
|
||
| 属性 | 值 |
|
||
|------|-----|
|
||
| **类型** | 有效 |
|
||
| **描述** | AUTOSAR 模板应提供描述时序属性与约束有效性的手段，例如适用于某种硬件或软件配置的条件。 |
|
||
| **理由** | 为正确利用时序属性与约束，必须知道它们获得时的上下文：例如 WCET 仅对特定实现与目标平台有效。 |
|
||
| **依赖** | [RS_TIMEX_00001], [RS_TIMEX_00002] |
|
||
|
||
⌊(UC_TIMEX_00001 – UC_TIMEX_00010)
|
||
|
||
### 4.11 模式依赖
|
||
|
||
#### ⌈[RS_TIMEX_00011] 模式依赖⌋
|
||
|
||
| 属性 | 值 |
|
||
|------|-----|
|
||
| **类型** | 有效 |
|
||
| **描述** | AUTOSAR 模板应提供描述时序属性与约束对系统/ECU 级别上定义的操作模式的依赖的手段。 |
|
||
| **理由** | 根据模式不同系统行为可能改变，从而影响系统时序特性。 |
|
||
| **依赖** | [RS_TIMEX_00001], [RS_TIMEX_00002], [RS_TIMEX_00010] |
|
||
|
||
⌊(UC_TIMEX_00001 – UC_TIMEX_00010)
|
||
|
||
### 4.12 传感器/执行器延迟
|
||
|
||
#### ⌈[RS_TIMEX_00012] 传感器/执行器延迟⌋
|
||
|
||
| 属性 | 值 |
|
||
|------|-----|
|
||
| **类型** | 有效 |
|
||
| **描述** | AUTOSAR 模板应提供描述物理传感器采集（或物理执行器变更）与对应数据在 VFB 级别上的传感器（或执行器）软件组件端口上的可用性（或提供）之间时间关系的手段。 |
|
||
| **理由** | 该信息可用于指定物理传感器（或执行器）到对应软件组件之间数据流的时间延迟，而无需涉及具体硬件实现。 |
|
||
| **依赖** | [RS_TIMEX_00002] |
|
||
|
||
⌊(UC_TIMEX_00001 – UC_TIMEX_00010)
|
||
|
||
### 4.13 时序资源的规范
|
||
|
||
#### ⌈[RS_TIMEX_00013] 软件组件描述的时序资源规范⌋
|
||
|
||
| 属性 | 值 |
|
||
|------|-----|
|
||
| **类型** | 有效 |
|
||
| **描述** | 将 SW-C 映射到 ECU 的主要标准之一是分配到单个 ECU 上的完整软件系统的资源需求。为估算软件系统所需的总资源量，需要每个分配的 SW-C 的相关信息。就此用例而言，相关的 CPU 特定资源信息是最坏情况执行时间。请注意，整体用例无法在本文档范围内完全覆盖，因为资源消耗的最终评估仅在 ECU 配置上下文中可行。另一方面，在 ECU 配置范围内进行评估需要事先通过软件组件指定资源声明。 |
|
||
| **理由** | 为集成目的，必须指定可执行实体的最坏情况执行时间，以保证正确集成。 |
|
||
| **用例** | 应能对可执行实体施加执行时间约束以确保时间资源消耗。 |
|
||
| **依赖** | [FDUC 3.2.8] |
|
||
|
||
⌊()
|
||
|
||
### 4.14 Runnable Entities
|
||
|
||
#### ⌈[RS_TIMEX_00014] runnable entities 的执行顺序⌋
|
||
|
||
| 属性 | 值 |
|
||
|------|-----|
|
||
| **类型** | 有效 |
|
||
| **描述** | 模板必须允许指定：不同 runnable entities 的执行顺序约束。 |
|
||
| **依赖** | [RS_SWCT_00090] |
|
||
|
||
⌊()
|
||
|
||
### 4.15 SW-C 的时序需求
|
||
|
||
#### ⌈[RS_TIMEX_00015] SW-C 的时序需求⌋
|
||
|
||
| 属性 | 值 |
|
||
|------|-----|
|
||
| **类型** | 有效 |
|
||
| **描述** | SW-Component template 必须允许指定 SW-Component 的每个 runnable entity 的时序需求（如：Period（周期）、Reaction time（反应时间））。 |
|
||
| **理由** | SW-Component template 必须允许描述：必须运行的频率；从硬件或软件实体的状态变更等 stimulus 到系统期望响应（如响应、执行器激活）之间的时间。 |
|
||
| **依赖** | [RS_TIMEX_00013] |
|
||
|
||
⌊()
|
||
|
||
### 4.16 时序扩展的部分元素应可作为蓝图
|
||
|
||
#### ⌈[RS_TIMEX_00016] 时序扩展的部分元素应可作为蓝图⌋
|
||
|
||
| 属性 | 值 |
|
||
|------|-----|
|
||
| **类型** | 有效 |
|
||
| **描述** | Timing Extensions 应允许对元素（即 port interfaces 元素，作为 Application Interface 规范的一部分）指定时序约束。 |
|
||
| **理由** | Application Interface Specification 中包含的信息应使用容许年龄、周期等进行注解。 |
|
||
| **依赖** | [RS_TIMEX_00001] |
|
||
|
||
⌊()
|
||
|
||
### 4.17 事件上的同步约束
|
||
|
||
#### ⌈[RS_TIMEX_00017] 事件上的同步约束⌋
|
||
|
||
| 属性 | 值 |
|
||
|------|-----|
|
||
| **类型** | 有效 |
|
||
| **描述** | Timing Extension 应允许对两个或多个时序描述事件施加同步约束。 |
|
||
| **理由** | 在构建系统时，需要指定事件的发生应同步，例如转向灯指示器、防抱死系统中来自多个车轮的信息非常重要。 |
|
||
| **依赖** | [RS_TIMEX_00001] |
|
||
|
||
⌊()
|
||
|
||
### 4.18 VFB 级别端口接口的预定义事件
|
||
|
||
#### ⌈[RS_TIMEX_00018] VFB 级别端口接口的预定义事件⌋
|
||
|
||
| 属性 | 值 |
|
||
|------|-----|
|
||
| **类型** | 有效 |
|
||
| **描述** | Timing Extensions 应提供专用于端口（如 trigger port）的时序描述事件类型。 |
|
||
| **理由** | 由于引入了新的端口类型（如 trigger port），Timing Extensions 应提供专用类型的时序描述事件以支持此类端口。 |
|
||
| **依赖** | [RS_TIMEX_00001] |
|
||
|
||
⌊()
|
||
|
||
### 4.19 AUTOSAR 方法论支持
|
||
|
||
#### ⌈[RS_TIMEX_00019] AUTOSAR 方法论支持⌋
|
||
|
||
| 属性 | 值 |
|
||
|------|-----|
|
||
| **类型** | 有效 |
|
||
| **描述** | Timing Extensions 应提供支持复用和使用 SW-C 类型级别已指定时序模型的手段。 |
|
||
| **理由** | Timing Extensions 缺乏对有效复用的支持。为此 Timing Extension 应提供使用不同时序视图的时序模型的手段。 |
|
||
| **依赖** | [RS_TIMEX_00001] |
|
||
|
||
⌊()
|
||
|
||
### 4.20 指示变量访问的事件支持
|
||
|
||
#### ⌈[RS_TIMEX_00020] 指示变量访问的事件支持⌋
|
||
|
||
| 属性 | 值 |
|
||
|------|-----|
|
||
| **类型** | 有效 |
|
||
| **描述** | Timing Extension 应提供引用可执行实体（即 runnable entities）访问变量时间点的手段。 |
|
||
| **理由** | 在某些情况下，需要引用可执行实体访问变量数据的时间点，并能对这些时序描述事件施加时序约束。例如，在 VFB 时序视图中，对接收 variable data prototype 的时间点施加一个年龄约束。但可能有多个可执行实体访问此类变量数据，其中部分可能具有不同的年龄时序约束。为避免此类 runnable entities 被映射到激活频率高于所需的任务，最好注解特定变量访问。 |
|
||
| **依赖** | [RS_TIMEX_00001] |
|
||
|
||
⌊()
|
||
|
||
### 4.21 装配连接器上的年龄约束（已移除）
|
||
|
||
#### ⌈[RS_TIMEX_00021] 装配连接器上的年龄约束⌋
|
||
|
||
| 属性 | 值 |
|
||
|------|-----|
|
||
| **类型** | 已移除（与 RS_TIMEX_00009 重复） |
|
||
| **描述** | Timing Extension 应提供注解装配连接器的手段，以解决数据流中的环路与数据依赖。 |
|
||
| **理由** | 在复杂系统中，常有 SW-C 产生数据被其他 SW-C 消耗，而后者又产生数据被前者消耗。在最简单情况下，一个 SW-C 产生的数据被另一个消耗，反之亦然。为解决此类循环依赖，必须能注解最重要的"生产者-消费者"关系，以使一个 SW-C (A) 所需的数据在 SW-C (A) 执行前由另一个 SW-C (B) 产生。 |
|
||
|
||
⌊()
|
||
|
||
### 4.22 逻辑执行时间（LET）支持
|
||
|
||
#### ⌈[RS_TIMEX_00022] 逻辑执行时间（LET）支持⌋
|
||
|
||
| 属性 | 值 |
|
||
|------|-----|
|
||
| **类型** | 有效 |
|
||
| **描述** | AUTOSAR 模板应提供支持描述 **Logical Execution Time（LET）** 或时间确定性（Time Determinism）的手段。具体应描述：<br>• LET 区间的参数：长度、重现类型、重现性；<br>• LET 区间之间的关系，如 offset、gap、overlap；<br>• 应在 LET 上下文中执行的可执行实体及/或可执行实体组；<br>• 应在 LET 区间内进行的数据交换，即可执行实体之间的时间确定性数据交换；<br>• 用于指定若干可执行实体之间执行顺序的手段。 |
|
||
| **理由** | 时间确定性是嵌入式分布式实时系统的关键特性，确保：可靠运行（由于确定性的数据交换与可执行实体执行）；系统分析与验证（在开发流程早期进行时序分析）。 |
|
||
| **用例** | 设计与定义应用程序的时序行为，以及时序行为的分析与验证 |
|
||
| **依赖** | [RS_TIMEX_00001], [RS_TIMEX_00002], [RS_TIMEX_00003], [RS_TIMEX_00004], [RS_TIMEX_00006] |
|
||
|
||
⌊(RS_Main_00010, RS_Main_00011, RS_Main_00050, RS_Main_00130, RS_Main_00150, RS_Main_00200, RS_Main_00410, RS_Main_01001)
|
||
|
||
### 4.23 指定同步的支持
|
||
|
||
#### ⌈[RS_TIMEX_00023] 指定同步的支持⌋
|
||
|
||
| 属性 | 值 |
|
||
|------|-----|
|
||
| **类型** | 有效 |
|
||
| **描述** | AUTOSAR 模板应提供对可执行实体及/或可执行实体组之间同步规范的支持。 |
|
||
| **理由** | 在某些情况下，仅指定可执行实体的执行顺序并使用同步时序约束表达"某些可执行实体在其他实体完成执行前不得执行"并不充分。AUTOSAR Timing Extensions 提供的 Execution Order Constraint 允许指定可执行实体之间的顺序，但不提供在此顺序的何处使用同步手段以保证若干可执行实体完成执行后才允许其他可执行实体开始执行的手段。Synchronization Timing Constraint 允许就时间特性（即时间区间）指定同步。 |
|
||
| **用例** | 确保在不同任务、不同核心上执行的可执行实体的正确同步 |
|
||
| **依赖** | [RS_TIMEX_00022] |
|
||
|
||
⌊(RS_Main_00010, RS_Main_00011, RS_Main_00050, RS_Main_00130, RS_Main_00150, RS_Main_00200, RS_Main_00410, RS_Main_01001)
|
||
|
||
---
|
||
|
||
## 5 支持的用例
|
||
|
||
AUTOSAR 中的时序信息应支持以下用例。
|
||
|
||
以下章节中描述的功能用例来自若干预系列项目中实现并经验证的实际应用，涉及底盘应用（chassis）。它们源自车辆功能的功能实现。因此，以下描述并非具体应用，而是用以解释底盘功能中常见的时序相关问题特征，包括：
|
||
|
||
- 主要由闭环控制特征驱动的时序约束；
|
||
- 由 FlexRay 总线强制的等距时间片中的数据传输；
|
||
- 与总线调度同步的应用数据计算。
|
||
|
||
### 5.1 端到端时序
|
||
|
||
AUTOSAR 时序模型所提供信息的一个典型用例是时序分析。时序分析是一个相当宽泛的术语，可分解为多个子活动，以获得整体的端到端时序分析。可区分单一资源（一个 ECU 或总线）的本地时序分析与多个互连资源（ECU 与总线）的全局时序分析。时序分析结果可通过将分析结果与给定时序约束比较来用于验证。
|
||
|
||
#### 5.1.1 本地时序分析（调度分析）
|
||
|
||
##### ⌈[UC_TIMEX_00001] 本地时序分析（调度分析）⌋
|
||
|
||
工程师可能想分析单一资源的本地时序行为，而不关心全局依赖。本地时序分析针对单一总线或 ECU（该 ECU 上的处理器）的孤立调度问题。例如，在早期设计阶段，这有助于获得资源利用率的印象。此外，本地时序分析也可用于优化目的。
|
||
|
||
本地时序分析是端到端分析的基础。⌊()
|
||
|
||
#### 5.1.2 开环控制系统中的端到端时序分析
|
||
|
||
##### ⌈[UC_TIMEX_00002] 开环控制系统中的端到端时序分析⌋
|
||
|
||
典型开环控制系统至少包含一个传感器、一个控制器和一个执行器组件。此类控制系统的分析需要端到端时序。端到端时序分析包括：
|
||
|
||
- 识别不同事件链和可选事件链段；
|
||
- 分析端到端延迟；
|
||
- 详细审视不同执行顺序对时序属性（即端到端延迟）的影响；
|
||
- 确定事件链和/或执行顺序中的自由度；
|
||
- 选择最合理（最可靠或最有效）的事件链。
|
||
|
||
⌊()
|
||
|
||
#### 5.1.3 闭环控制系统中的端到端时序分析
|
||
|
||
##### ⌈[UC_TIMEX_00003] 闭环控制系统中的端到端时序分析⌋
|
||
|
||
与开环控制系统相比，闭环控制系统包含一个或多个反馈回路。分析需要识别和描述这些反馈回路，以及如何在时序上处理它们。此外，时序属性的影响应可分析。⌊()
|
||
|
||
#### 5.1.4 端到端时序验证
|
||
|
||
##### ⌈[UC_TIMEX_00004] 端到端时序验证⌋
|
||
|
||
基于端到端时序分析得到的结果，应能验证系统的实际/给定时序行为是否满足其约束。具体示例包括响应时间、缓冲区大小或吞吐量的验证。在所有情况下，分析方法（如 [3]、[4]、[5]、[6]）或仿真/测量的结果可用于确定要根据给定时序约束集进行验证的系统时序行为。⌊()
|
||
|
||
### 5.2 同步
|
||
|
||
时序分析中的同步关注共同功能上下文内并发事件链的时间相关性。如果对应 stimulus 和/或 response 事件的发生在时间上以一定预定义容差重合，则两个或多个事件链被视为同步。
|
||
|
||
#### 5.2.1 多传感器系统中的传感器数据融合
|
||
|
||
##### ⌈[UC_TIMEX_00005] 多传感器系统中的传感器数据融合⌋
|
||
|
||
现代汽车通常在其车载网络中配备多个传感器。这些传感器可被许多软件功能使用。其中部分需要来自不同传感器的数据同时计算更复杂的传感器信息相关性。
|
||
|
||
包含传感器数据融合的功能示例有 ACC（自适应巡航控制，需要雷达和车轮数据）或 PDC（停车距离控制，需要多个同类传感器以获取整体环境模型）。
|
||
|
||
此类功能的时序分析不能仅关注每个传感器自身的孤立信号路径。更有趣的部分是这些路径在功能中的同步。因此，时序模型必须能为多个事件链表达同步性约束，并提供验证所需信息。⌊()
|
||
|
||
#### 5.2.2 执行器同步
|
||
|
||
##### ⌈[UC_TIMEX_00006] 执行器同步⌋
|
||
|
||
除了上述传感器数据融合用例，还必须能够同步执行器。现代控制系统包含分布式智能执行器，其同步对于确保同时操作至关重要。一个例子是同步开门功能。
|
||
|
||
典型示例是危险报警灯的同步。⌊()
|
||
|
||
#### 5.2.3 总线同步 / 网关
|
||
|
||
##### ⌈[UC_TIMEX_00007] 总线同步 / 网关⌋
|
||
|
||
存在多种网关同步场景。网关可与一条或多条 FlexRay 总线同步，以减少网关任务的发送/读取延迟。还应能同步多个网关活动，以优化后续 CAN 上的传输时间。⌊()
|
||
|
||
### 5.3 早期预测
|
||
|
||
上一节描述了通用用例，时序增强的 AUTOSAR 元模型是不同领域端到端时序分析的使能因素。本节关注早期预测——使用此类分析框架在设计阶段进行时序分析。基于估计或部分已知的时序信息进行时序验证，可在系统设计或规范阶段尽早发现潜在设计弱点。
|
||
|
||
#### 5.3.1 增加组件导致的修改影响
|
||
|
||
##### ⌈[UC_TIMEX_00008] 增加组件导致的修改影响⌋
|
||
|
||
组件集成是一个多面问题。首先，被集成的组件必须提供时序数据以使分析（与仿真）成为可能，判断该组件是否能融入目标系统并确定对目标系统的影响。目标系统对被集成的组件施加一些时序约束。另一方面，被集成的组件对目标系统施加一些时序约束以正常运行。
|
||
|
||
由于错误的时序行为，向现有系统集成新软件可能导致优先级反转、死锁等意外现象。因此，简单地计算现有（如 70% CPU 使用率）与新增（如 20%）软件加合并非可接受的时序行为评估方式。⌊()
|
||
|
||
#### 5.3.2 硬件尺寸支持
|
||
|
||
##### ⌈[UC_TIMEX_00009] 硬件尺寸支持⌋
|
||
|
||
硬件资源（如计算能力、带宽、内存访问时间）显著影响软件的时序行为。另一方面，硬件成本应限制在绝对最小值，因为它们主导了单件成本。因此，为最小化成本，自然要在硬件设计空间中搜索，使软件组件提供的时序属性仅勉强满足时序约束。关键问题可能是 ECU 时钟频率、总线带宽或内存模块访问速度等。基本要求是已知（至少作为估计值）硬件配置对时序属性的影响。若如此，时序行为可针对某些硬件设置进行验证，并在早期设计阶段选择最小成本解决方案。⌊()
|
||
|
||
#### 5.3.3 拓扑决策
|
||
|
||
##### ⌈[UC_TIMEX_00010] 拓扑决策⌋
|
||
|
||
确定特定拓扑的主要目标是按预定义质量标准（如最大延迟、最小总线负载）对整个系统进行优化。这些决策基于系统所处状态作出。为确定该状态，需要可分析的信息以访问系统特征。
|
||
|
||
就时序而言，一个有意义的优化标准是传感器数据处理时的最小年龄。考虑一个通信周期长度为 10ms 的 FlexRay 通信系统。若传感器 ECU 每 40ms 提供数据，使用周期复用（cycle multiplexing）将每第 4 个通信周期的某槽位分配给传感器 ECU 可能是合理的。然而，为达到最小数据年龄目标，需要附加信息。例如，估计的抖动值和相对于某参考事件（如 FR 周期开始）的释放偏移。提供上述信息的形式化手段需在即将到来的概念中定义。⌊()
|
||
|
||
---
|
||
|
||
## 6 变更历史
|
||
|
||
### 6.1 R4.0.3 相对于 R4.0.1（无）
|
||
|
||
### 6.2 R4.1.1 相对于 R4.0.3 — 新增 SRS 条目
|
||
|
||
| 编号 | 标题 |
|
||
|------|------|
|
||
| [RS_TIMEX_00013] | 时序资源的规范（原 RS_SWCT_02050） |
|
||
| [RS_TIMEX_00014] | runnable entities 的执行顺序（原 RS_SWCT_03060） |
|
||
| [RS_TIMEX_00015] | SW-C 的时序需求（原 RS_SWCT_03080） |
|
||
| [RS_TIMEX_00016] | Timing Extensions 部分元素应可作为蓝图 |
|
||
| [RS_TIMEX_00017] | 事件上的同步约束 |
|
||
| [RS_TIMEX_00018] | VFB 级端口接口的预定义事件 |
|
||
| [RS_TIMEX_00019] | AUTOSAR 方法论支持 |
|
||
| [RS_TIMEX_00020] | 指示变量访问的事件支持 |
|
||
| [RS_TIMEX_00021] | 装配连接器上的年龄约束 |
|
||
|
||
**表 6.1：4.1.1 新增的规范条目**
|
||
|
||
### 6.3 R4.1.2 相对于 R4.1.1 — 移除 SRS 条目
|
||
|
||
| 编号 | 标题 |
|
||
|------|------|
|
||
| [RS_TIMEX_00021] | 装配连接器上的年龄约束（注：[RS_TIMEX_00009] 的重复） |
|
||
|
||
**表 6.2：4.1.2 移除的规范条目**
|
||
|
||
### 6.4 – 6.8 R4.1.3 – R4.3.1（无变更）
|
||
|
||
### 6.9 R4.4.0 相对于 R4.3.1 — 新增 SRS 条目
|
||
|
||
| 编号 | 标题 |
|
||
|------|------|
|
||
| [RS_TIMEX_00022] | 逻辑执行时间（LET）支持 |
|
||
| [RS_TIMEX_00023] | 指定同步的支持 |
|
||
|
||
**表 6.3：4.4.0 新增的规范条目**
|
||
|
||
---
|
||
|
||
## 翻译说明
|
||
|
||
- 本文档为 **AUTOSAR 时序扩展需求**（RS_TIMEX）的完整中文翻译，包含 23 条需求与 10 个用例。
|
||
- 所有需求 ID（如 `RS_TIMEX_xxxxx`、`UC_TIMEX_xxxxx`、`RS_Main_xxxxx`、`FDUC_xxx`、`RS_SWCT_xxxxx`）保持英文。
|
||
- 专业术语首次出现时给出英文：*event chain*（事件链）、*stimulus / response*、*WCET*（最坏情况执行时间）、*LET*（Logical Execution Time，逻辑执行时间）、*Execution Order Constraint*、*Synchronization Timing Constraint*、*runnable entity*、*atomic event chain*、*sender-receiver communication* 等。
|
||
- 缩略语：CAN、FlexRay、VFB、SWC、ECU、SW-C、ACC、PDC、FR（FlexRay）保持英文。
|
||
- 学术引用文献保持原文。
|