diff --git a/translation_zh-CN/P1_SystemServices/AUTOSAR_TR_TimingAnalysis.html b/translation_zh-CN/P1_SystemServices/AUTOSAR_TR_TimingAnalysis.html new file mode 100644 index 0000000..25cca44 --- /dev/null +++ b/translation_zh-CN/P1_SystemServices/AUTOSAR_TR_TimingAnalysis.html @@ -0,0 +1,1109 @@ + + + + +AUTOSAR TR TimingAnalysis 中文翻译 + + + + +

AUTOSAR_TR_TimingAnalysis 中文翻译

+

文档编号：645　|　状态：Final（正式发布）　|　发布于：AUTOSAR CP Release 4.4.0（2018-10-31）
+所属标准：AUTOSAR Classic Platform 标准　|　文档责任方：AUTOSAR　|　保密等级：AUTOSAR CONFIDENTIAL

+ +

本翻译覆盖原文档 1-141 页正文（不含封面/封底），约 4.66 MB / 141 页。
+原文为方法学技术报告（TR, Technical Report），不包含 SWS_* / SRS_* 类型需求规范，主体为时序分析方法学、用例、属性与方法分类。
+翻译校对区块：7 大章 + 9 大类 30 余个用例 + 11 个时序属性 + 5 类时序方法 + 9 个时序工件 + 1 个限制章节 + A/B 附录；保留全部 18 篇外部参考文献、约 60 个表/图编号。

+ + + +
+ + + +

1 引言（Introduction）

+ +

1.1 目标（Objective）

+

本技术报告（TR, Technical Report）阐述在 AUTOSAR 开发流程中进行时序分析与设计时所建议使用的方法与实践（Recommended Methods and Practices）。报告面向汽车行业实时嵌入式系统（Real-Time Embedded Systems）的开发者与集成者，旨在为功能级、网络级与 ECU 级的时序需求分解、属性获取、方法选择提供一套可参考的方法学框架。

+

本 TR 不引入新的 AUTOSAR 元模型元素，所有相关概念（事件 Event、事件链 Event Chain、时序约束 Timing Constraint）以引用方式参考 AUTOSAR_TPS_TimingExtensions [2]。本报告不直接定义可机器读取的需求 ID（如 SWS_* 或 SRS_*），而是给出"应当如何"与"为什么"的方法学指导。

+ +

1.2 概述（Overview）

+

本章给出报告的整体框架：

+ + +

1.3 动机（Motivation）

+

汽车 E/E（Electrical/Electronic）系统日益复杂，时序需求作为非功能性需求的重要组成部分，其正确分解、传递与验证已成为决定系统成败的关键因素。报告的动机可归纳为三点：

+
    +
  1. 跨组织传递：时序需求需要在 OEM（原始设备制造商）与 tier-1/tier-2 供应商之间被无歧义地传递；
    2. +
  2. 跨阶段追踪：从自然语言规约到 AUTOSAR 模型、再到测试协议，时序需求须全程可追溯；
    3. +
  3. 可重复使用：同一时序需求应能复用到其他车型项目，方法学须支持这种重用。
    4. +
+ +

1.4 示例（Example）

+

报告以一个"自适应巡航控制"（ACC, Adaptive Cruise Control）功能为例，说明时序需求如何从客户功能视图逐级分解到实现视图。该示例贯穿第 1-3 章，作为后续用例描述的引导。

+

图 1.2 给出 ACC 功能的端到端事件链：从"雷达采样"事件（源可调度实体 Source Schedulable Entity）经"传感器 SW-C 处理"、"CAN 总线传输"、"控制器 SW-C 融合"、到"节气门执行器响应"事件（汇可调度实体 Sink Schedulable Entity）。端到端时序约束（如最大延迟 ≤ 100 ms）须被分解到各跳（per-hop）时间预算中。

+

在 AUTOSAR CP（Classic Platform）与 AP（Adaptive Platform）共存时，TIMEX 仅覆盖 CP 视角；AP 视角由 AUTOSAR_EXP_PlatformDesign [3] 给出。1.4 节扩展自 R4.4.0 版本以明确显示两者交互方式。

+ +

1.5 范围（Scope）

+

本报告的范围限定于：

+ +

不在范围内：具体微控制器架构的时序分析、操作系统调度算法证明、形式化验证工具的实现细节。

+ +

1.6 缩略语（Acronyms and Abbreviations）

+

本节列出报告正文中出现的主要缩略语。完整列表请见附录 B 索引。

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
缩略语英文全称中文释义
AADLArchitecture Analysis and Design Language架构分析与设计语言
ACCAdaptive Cruise Control自适应巡航控制
ADLArchitecture Description Language架构描述语言
APAUTOSAR Adaptive PlatformAUTOSAR 自适应平台
APIApplication Programming Interface应用程序编程接口
BCET/BCTTBest-Case Execution / Transmission Time最佳情况执行/传输时间
BSWBasic Software基础软件
CANController Area Network控制器局域网
CPAUTOSAR Classic PlatformAUTOSAR 经典平台
ECUElectronic Control Unit电子控制单元
E/EElectrical/Electronic电气/电子
EAST-ADLElectronics Architecture and Software Technologies - Architecture Description Language电子架构与软件技术-架构描述语言
E2EEnd-to-End端到端
GMP(项目名，非通用缩略语)—
ISOInternational Organization for Standardization国际标准化组织
MARTEModeling and Analysis of Real-Time and Embedded systems实时与嵌入式系统建模与分析（UML profile）
OEMOriginal Equipment Manufacturer原始设备制造商
OSOperating System操作系统
PDUProtocol Data Unit协议数据单元
RTOSReal-Time Operating System实时操作系统
SW-CSoftware Component软件组件
SysMLSystem Modeling Language系统建模语言
TADLTiming Augmented Description Language时序增强描述语言
TIMEXTiming ExtensionsAUTOSAR 时序扩展
TPSTemplate Specification模板规范
UMLUnified Modeling Language统一建模语言
WCRT/WCTTWorst-Case Response / Transmission Time最坏情况响应/传输时间
WCETWorst-Case Execution Time最坏情况执行时间
+ +

1.7 术语表（Glossary of Terms）

+

本节定义贯穿全文使用的核心术语。每个术语在 8.4 节中以"属性"形式进一步精化。

+
+
准确度（Accuracy）
时序属性估计值与真实值之间的接近程度，受限于测量/分析方法的精度。
+
端到端响应时间（End-to-End Response Time）
从源可调度实体（Source Schedulable Entity）触发到汇可调度实体（Sink Schedulable Entity）完成之间经过的全部时间，跨多个资源。
+
事件（Event）
系统中可观察到的发生点（如读/写端口、发送/接收 PDU、启动/终止可执行实体）。
+
事件链（Event Chain）
具有因果关系的两个事件的有序对（Event A → Event B），可承载时序约束。
+
可调度实体（Schedulable Entity）
在计算或通信资源上可被独立调度的对象，如 OsTask、ISR、CAN 帧。
+
时序约束（Timing Constraint）
对系统时序行为的限制，如最大延迟、数据年龄、抖动范围。
+
时序方法（Timing Method）
获取时序属性所采用的技术（仿真、分析计算、测量）。
+
时序属性（Timing Property）
描述系统某一时序特征的可测量量（延迟、响应时间、负载、传输时间等）。
+
时序需求（Timing Requirement）
对系统时序行为的契约性要求，由时序约束在系统模型中实例化而成。
+
可执行实体（Executable Entity）
AUTOSAR 中可被调度的最小执行单位，通常对应 Runnable 实体。
+
+ +

1.8 用例（Use-cases）

+

报告将时序分析活动组织为 4 组共 25+ 用例，详细描述见第 4-7 章。本节给出用例清单：

+ + +

1.9 方法学角色（Methodology Roles）

+

本节定义 12 个方法学角色（自 R4.3.0 起为 9 个 + R4.4.0 新增若干），每个角色给出简述、收益（Benefit）、关联（Relation）。报告以这些角色视角组织用例的目标读者。

+ + + + + + + + + + + + + +
角色简述主要受益
E/E Architect（E/E 架构师）负责整车电气电子架构理解时序约束如何贯穿整车架构
Function Architect（功能架构师）负责车辆功能到软件组件的分解获得功能分解的时序指导
Function Engineer（功能工程师）实现具体功能逻辑理解功能级时序约束的来源
Network Data Engineer（网络数据工程师）负责通信矩阵与网络配置掌握网络级时序分析方法
Software Architect（软件架构师）负责 ECU 软件架构将功能级约束映射到任务/中断
ECU Integrator（ECU 集成商）负责将 SW-C 集成到 ECU建立 ECU 级时序模型与验证
SW-C Developer（软件组件开发人员）实现单个 SW-C 内部行为理解对自身代码的时序要求
Test Engineer（测试工程师）执行时序相关测试了解时序分析与验证方法
Timing Engineer（时序工程师）建立时序模型、执行时序分析、对比时序结果与约束获得模型化与验证方法
+

注：原文中"Test Engineer"与"Timing Engineer"两个角色在 R4.3.1 中为同一角色的拆分；R4.4.0 之后这两个角色被进一步分离，以体现时序分析（建模/计算）与时序测试（执行/测量）的差异。报告原表 1.10-1.12 中"Package: Not in the AUTOSAR methodology yet"意味着 AUTOSAR 方法学尚未为这些角色定义完整元模型。

+ +

1.10 文档结构与章节概述（Document Structure and Chapter Overview）

+

图 1.1（见原文 p.11）展示时序分析的不同面向及对应章节。每个面向都通过若干典型用例（关联到 1.9 节角色）描述，并被分解为更细的时序任务；对每个任务给出必要的时序属性与对应的时序方法。验证活动将时序结果与时序约束对比，以确认时序需求是否被满足。

+

章节概述：

+ + + + +

2 时序基本概念（Basic Concepts of Timing）

+ +

2.1 实时架构基本概念（Basic Concepts of Real Time Architectures）

+ +

2.1.1 实时架构定义（Real Time Architecture Definition）

+

E/E 架构是早期设计决策的产物，它在多方利益相关者协同构建系统前就已定义。架构定义其构成要素（components, subsystems, ECUs, functions, runnables, compilation units…）以及它们之间的相关关系（"调用"、"发送数据到"、"同步于"、"使用"、"依赖于"…）。除上述结构性方面外，实时架构还须提供满足时序需求的能力。

+

如同对系统构成要素的处理，实时架构设计包含时序需求的分解以及这些需求间关系（如精化、追溯）的识别。事实上，时序需求的分解是结构分解的伴随结果：时序需求在分解单元间被部分继承。然而，结构分解可由功能、输入/输出数据流或服务提供/需求驱动，而时序分解是更复杂的任务。正确的时序需求分解必须在局部与全局上均可行——局部上各子组件的时序属性须满足被分配的时序需求；全局上所有时序约束须被满足。

+

实时软件架构的设计由两部分组成：

+
    +
  1. 功能分解：从用户功能到实现组件的逐级拆分；
    2. +
  2. 平台配置：硬件资源、任务分配、调度策略、共享资源访问协议等。
    3. +
+

时序属性高度依赖底层软硬件平台资源；多个分解单元访问共享资源还会引入额外开销（阻塞时间、干扰等）。时序属性依赖于：

+ +

为评估这些架构选择对时序需求的影响，需要进行时序分析。所采用的分析方法与时序属性取决于所考虑的实时架构类型（如时间触发或事件触发架构）。第 8 章详述这些内容。

+

从应用视角看，最重要的两个时序属性是：

+ +

两者详细定义见 2.1.2、2.1.3 节，更完整分类见第 8 章。

+ +

2.1.2 执行与传输时间（Execution and Transmission Times）

+

执行时间（Execution Time, ET）指可调度实体在计算资源（如 ECU）上不间断完成其执行所需的持续时间，期间不考虑其他共享同一资源的可调度实体（无挂起/抢占）。

+

传输时间（Transmission Time, TT）类似地，指信号/报文/帧在通信资源（如总线、网络）上从源到目的的传输持续时间，期间不考虑其他共享同一资源的信号/报文/帧。

+

执行/传输时间是定量属性，可由以下特征描述：

+
    +
  1. 统计限定符（Statistical Qualifier）：worst/best/mean，分别对应最坏（WCET/WCTT）、最佳（BCET/BCTT）、平均（ACET/ACTT）三种情况。在三种限定符中，WCET/WCTT 是实时系统时序验证中最常用的。
    2. +
  2. 获取方法（Method）：估计（estimation，如仿真）、测量（measurement）、计算（calculation，静态分析）。测量受输入数据分布影响，通常只能给出平均值或分布；要获得上界须使用静态分析技术（抽象解释、模型检查）。
    3. +
  3. 准确度（Accuracy）：见 1.7 节术语表。WCET/WCTT 分析的准确度受软件细节程度（指令级）与硬件资源细节（缓存机制、分支预测等）影响。过保守的 WCET 会导致平台过度设计；过乐观的 WCET 会导致时序违规。报告建议提供"安全但精确"（safe but accurate）的 WCET/WCTT。
    4. +
+

在极低抽象层级（一旦 ECU、网络、部署固定），WCET/WCTT 可成为必须满足的需求；在极高抽象层级，时序需求通常指端到端响应时间约束。

+ +

2.1.3 响应时间（Response Time）

+

可调度实体的响应时间（Response Time, RT）指该实体完成其执行所经过的时间。与执行时间不同，响应时间考虑其他共享同一执行/通信资源的可调度实体。因此，可调度实体的响应时间包含其执行时间，以及由并发访问共享资源引入的额外时间（阻塞时间 blocking times、抖动 jitters 等）。

+

端到端响应时间（End-to-End Response Time, E2E RT）指多个可调度实体串联形成的链路响应时间。链路中第一个可调度实体称为源可调度实体（Source Schedulable Entity），最后一个称为汇可调度实体（Sink Schedulable Entity）。端到端响应时间是汇可调度实体终止执行时经过的时长。

+

响应时间同样是定量属性，由统计限定符（worst/best/mean）、获取方法（estimation/measurement/calculation）、准确度三个特征描述。WCRT 是评估时序需求满足性时常用的上界，详细定义见第 8 章。WCRT 的准确度高度依赖链路中各可执行实体 WCET 的准确度。

+ +

2.2 时序需求规约语言（Languages for Timing Requirements Specification）

+

AUTOSAR 方法学基于 AUTOSAR 语言及其时序扩展。AUTOSAR 适用于软件实现层级，但不适用于功能层级（分析与设计）。因此，要实现完整的基于模型的时序需求分解方法学，须在功能层级使用补充建模语言。EAST-ADL2 [6] 及其时序扩展 TADL2 [7] 允许在功能层级以精确的时序模型进行规约。TADL2 与 AUTOSAR TIMEX 共享基本概念，这便于时序需求从功能层级到 AUTOSAR 层级（使用 TIMEX 表达）的转换。

+ +

2.2.1 EAST-ADL / TADL

+

EAST-ADL 是面向汽车嵌入式系统的架构描述语言（ADL, Architecture Description Language），由多个欧洲研究项目共同开发。它被设计为在更高抽象层级对 AUTOSAR 进行补充，涵盖车辆功能、功能、需求、可变性、软件组件、硬件组件、通信等。

+

TADL2（Timing Augmented Description Language，时序增强描述语言）语言概念可在 GMP 方法学的特定步骤中用于描述时序信息。TADL2 允许规约的时序约束涵盖以下时序属性/需求：

+ +

TADL2 基本概念与下节介绍的 AUTOSAR TIMEX 概念相当。

+ +

2.2.2 AUTOSAR TIMEX 基本概念（Basic concepts of AUTOSAR TIMEX）

+

据 [2]（AUTOSAR_TPS_TimingExtensions），AUTOSAR 时序扩展的主要目的是：

+
    +
  1. 支持构建满足给定时序需求的嵌入式实时系统；
    2. +
  2. 在系统构建完成后对其执行时序分析与验证。
    3. +
+

AUTOSAR TIMEX 以时序模型作为基于契约的开发流程（contract-based development process）的规约基础，在该流程中开发工作由不同组织在不同地点、不同时段协同完成。项目早期阶段（在对应解决方案尚未开发时）所输入的约束，应被视为开发伙伴共同商定的非功能性需求。

+

时序规约既支持自顶向下的设计方法学，也支持自底向上（应对遗留代码等情况）的设计方法学。完整的规约（AUTOSAR 模型 + 时序扩展）须使能：

+ +

AUTOSAR TIMEX 提供两类基本手段描述与规约时序信息：

+ +

两者被组织在面向特定用途的时序视图（Timing Views）中。TIMEX 服务于两个不同目的：① 提供时序需求以指导系统构建；② 提供足够时序信息以分析验证系统的时序行为。

+ +
2.2.2.1 TIMEX 工作产品（TIMEX Work Products）
+

本小节给出 TIMEX 工作产品的概览，更详细描述见 [2] 第 2 章。

+
+
事件（Events）
+
事件用于描述系统中特定可观察事件的发生以及观察位置。这些事件关联到预定义的事件类型（Event Types），用于规约不同动作（如读/写端口、通过网络发送/接收数据、启动/终止可执行实体）。
+
事件链（Event Chains）
+
事件链规约两个事件之间的因果关系。例如：仅当事件 A 发生后事件 B 才发生。
+
施加于事件的时序约束（Timing Constraints imposed on Events）
+
事件触发约束（Event Triggering Constraint）对事件在时间空间中的发生施加约束（周期、偶发、特定模式）。
+
施加于事件链的时序约束（Timing Constraints imposed on Event Chains）
+
事件触发约束可用于规约反应或年龄（age），例如两个相邻事件的最大间隔。延迟与同步时序约束规约刺激或响应事件须在给定时间区间（容差）内发生以被视为同时（simultaneous）或同步（synchronous）。
+
附加时序约束（Additional Timing Constraints）
+
AUTOSAR TIMEX 还提供施加于可执行实体的时序约束：执行顺序约束（Execution Order Constraint）与执行时间约束（Execution Time Constraint）。
+
+ + + +

3 设计层级时序需求（Timing Requirements on Design Levels）

+

时序需求分解是实时系统设计与分析的首要关注点。在系统设计流程起始，时序需求以客户功能层级表达（来自需求规约）。客户功能的开发需要将其分解为小而可管理的组件。该被称为架构设计（architecting）的分解活动隐含地包含对附着于被分解功能的时序需求的分解。本章概述建议采用的时序需求分解方法学。

+ +

3.1 时序需求分解问题（Timing Requirements Decomposition Problem）

+

掌握时序需求是开发与集成现代汽车 E/E 系统成功的关键因素之一。在车辆复杂的开发流程中，时序需求须被持续监控；且须在功能或组件被复用到其他车型项目时被复用与传递：因此时序需求须被系统化、仔细地描述。所需的细节深度可从：

+ +

如图 3.1 所示，开发流程遵循著名的 V 模型，它描述从系统规约到系统集成的系统性、阶段性自顶向下方法。V 模型的左支描述规约过程步骤，将整个 E/E 系统分解为单个组件；V 模型底部描述实现及关联的测试流程；V 模型右支按自底向上顺序描述测试与集成过程直至整车系统集成。

+

根据汽车 OEM 开发流程的基本步骤，需求须在任意流程步骤中可追溯。这意味着时序需求须可识别、可追溯，从需求规约经过供应商性能规约到测试与集成文档（协议）。就 E/E 流程而言，这意味着时序需求须在两家公司（OEM 与 tier-1 供应商，并进一步到 tier-2 和 tier-3 供应商）之间进行流程转换时仍能保持语义。这只能通过使用标准化的描述与方法学系统、引用开发伙伴之间通常交换的模型工件来实现。

+

AUTOSAR TIMEX [2] 基于 AUTOSAR 系统模板，是 AUTOSAR 兼容软件开发流程中系统描述交换的标准化格式。TIMEX 是一个可选组件，不对 AUTOSAR 系统模板引入修改。可观察事件（observable event）的概念（发生于或可观察于被引用建模工件，如 RTE 端口）允许以因果顺序规约观察点与事件序列（事件链），并在其上附加时序约束。TIMEX 概念被假定能满足以时序需求方式描述 AUTOSAR 系统时序行为的所有用例。

+

然而 OEM 开发流程并非起始于 AUTOSAR。AUTOSAR 仅代表某些软件组件的实现视图，但不包含可涵盖非软件功能的高层功能概念视图。当前需求在流程极早期以自然语言描述；这些需求须被"形式化"为非自然语言以评估并允许其分解。时序需求的评估应在开发流程中尽早进行。为在系统/功能层级实现这一点，需要一个系统/功能建模语言，它须提供功能设计建模概念，并提供形式化方式以在功能设计中捕获与分解时序需求。

+

多个基于 ADL 的方法可被用于填补自然语言需求规约与 AUTOSAR 实现阶段之间的空白。可引用的基于 UML [8] 的 ADL 包括：

+ +

其他更领域专门化的方法包括 AADL [11]（航空航天）和 EAST-ADL [6]（汽车）。系统/功能层级建模语言的选择取决于各 OEM 内部流程，但仍有一些通用的时序相关重要标准：

+ +

下节将基于所有这些思想与概念勾勒一种方法学，旨在为在自有组织中实现分层时序需求流程提供方向，并最终使能符合 AUTOSAR TIMEX 的模型工件的交换。

+ +

3.2 分层时序描述（Hierarchical Timing Description）

+

在汽车开发流程的早期设计阶段，架构讨论聚焦于面向客户的高层功能。这些功能可被细化为功能性"因果"或"活动"链；从时序视角可对其做预算（budget）——基于客户经验做出合理分配。功能质量以及因此对客户体验的技术投入是公司的业务决策。

+

一个示例是"按键按下"到"响应"之间的反应时间，差异显著：

+ +

从方法学与技术视角看，时序分析是一种工具，用以保证在将功能网络映射到组件网络（如图 3.2 所示）过程中所需的时序行为。

+

一旦面向客户的功能的主要时序预算被定义，且功能部件到硬件组件的分配完成，即可对网络架构进行更详细的时序视角评估。这允许就性能与时序两方面对功能分配进行可行性首次评估。此过程可在后续流程步骤中迭代精化以获得更精确的分析结果。

+

为进一步理解，可假设图 3.3 中的每个功能都包含在某个 AUTOSAR SW-C 的组合作用域内，并在其中被表示为一个 AUTOSAR Runnable 实体（简称为"Runnable"）。其他映射策略也可考虑；无论选择哪种策略，映射通常受制于功能级为时序需求评估所做的功能设计选择。例如基于端到端延迟的可行性测试需要明确定义端到端事件链中的源与汇可调度实体。

+

3.2 节给出分层时序描述的总体方法：从车辆功能→功能网络→组件网络→任务/RTE 端口→可执行实体的逐级分解。每一层时序约束的预算（budget）须可追溯到上一层。

+ +

3.3 时序需求分解方法学（Methodologies for Timing Requirements Decomposition）

+ +

3.3.1 功能与软件架构建模层级（Functional and Software Architectures Modeling Levels）

+

时序需求分解的关键是在适当抽象层级上建立"时序视图"。报告建议采用以下五个建模层级：

+
    +
  1. 车辆级（Vehicle Level）：面向客户的功能（如 ACC、安全气囊触发）。
    2. +
  2. 系统级（System Level）：功能网络，跨多个 ECU 与总线。
    3. +
  3. ECU 级（ECU Level）：单个 ECU 内部的任务、中断、共享资源。
    4. +
  4. 软件组件级（SW-C Level）：单个 SW-C 内部的 Runnable 实体。
    5. +
  5. 实现级（Implementation Level）：源代码、目标码、硬件指令周期。
    6. +
+

时序需求从高级别分解到低级别时，须满足"局部-全局一致性"：低层级的时序属性须满足分配的需求；所有低层级满足后高层级也须满足。

+ +

3.3.2 时序需求分解指南（Guidelines for Timing Requirements Decomposition）

+

报告给出分解指南：

+
    +
  1. 从客户功能到功能网络：每个客户功能可分解为一组子功能，每个子功能承载部分时序预算；
    2. +
  2. 从功能网络到组件网络：功能网络节点（功能）映射到组件网络节点（SW-C + ECU + 总线）；
    3. +
  3. 从组件网络到 AUTOSAR 视图：将功能-硬件映射翻译为 AUTOSAR 系统模板中的 Runnable-OsTask 分配、PDU 路由等；
    4. +
  4. 从 AUTOSAR 视图到 TIMEX：将 AUTOSAR 系统描述中蕴含的时序信息（如 OsTask 周期、CAN 帧发送周期）转换为 TIMEX 事件链与时序约束。
    5. +
+

分解须保持双向可追溯：高级别需求的变更应可识别受影响的低级别约束；反之亦然。

+ +

3.4 小结（Conclusions）

+

本章阐述：

+ + + + +

4 功能级时序（Timing on Functional Level）

+

本章描述系统功能分析与设计在功能级的时序相关用例。部分用例覆盖开发早期阶段的高层时序；其他用例处理从功能级到实现级的过渡。本章面向 E/E 架构师与功能架构师。

+ +

4.1 功能级用例总览（Overview of Function-level Use-Cases）

+

图 4.1（原文 p.41）展示 4 个功能级用例之间的关系：

+ +

这 4 个用例构成"自顶向下"的分解链：用例 4.1 输出时序需求；用例 4.2 验证需求可被功能网络满足；用例 4.3 验证功能网络-硬件网络映射的时序可行性；用例 4.4 将功能级事件规约为 AUTOSAR 可观察事件。

+ +

4.2 功能级用例：识别新功能（车辆功能）的时序需求

+

Use-case 4.2：Identify timing requirements for a new feature (vehicle function)

+ + + + + + + + +
字段描述
目标为新车辆功能定义高层时序需求
主要活动从客户/法规/竞品分析中提取时序约束；如 ACC 的"雷达采样到节气门响应 ≤ 100 ms"
输入客户需求、法规、现有系统基准、相关标准（如 ISO 26262 ASIL 等级）
输出车辆级时序约束列表（通常以自然语言+关键参数表达）
角色E/E 架构师、功能架构师
关联章节5.3（端到端时序推导）、3.3（分解方法学）
+

主场景：架构师从客户功能视角识别"输入刺激→系统响应"事件链；为每条链定义端到端延迟约束、抖动约束、周期约束等；与功能安全团队对齐 ASIL 等级以确定时序违规的容许后果。

+ +

4.3 功能级用例：将功能（车辆功能）划分为功能网络

+

Use-case 4.3：Partition a feature (vehicle function) into a function network

+ + + + + + + +
字段描述
目标将单体车辆功能分解为可独立设计的子功能网络
主要活动分析功能内部因果链；识别子功能边界；定义子功能间数据/事件流；将车辆级时序预算分配到子功能
输入用例 4.1 的车辆级时序约束、单体功能规约
输出功能网络图、子功能级时序约束列表
角色功能架构师
+

主场景：以 ACC 为例，将单体 ACC 功能分解为"雷达感知→目标融合→轨迹规划→执行控制"四个子功能；为每段链路定义延迟预算（30 ms、20 ms、20 ms、30 ms，总和 100 ms）；定义采样率（雷达 50 Hz、融合 20 Hz、控制 100 Hz）。

+ +

4.4 功能级用例：将功能网络映射到硬件组件网络

+

Use-case 4.4：Map a function network to a hardware components network

+ + + + + + + +
字段描述
目标将功能网络节点分配到硬件组件（ECU + 总线）
主要活动考虑 ECU 算力、总线带宽、内存、传感器/执行器物理位置；将功能节点绑定到 ECU；将跨 ECU 通信绑定到总线
输入用例 4.2 的功能网络、可用 ECU/总线列表、负载估算
输出功能-硬件映射表、网络拓扑、初步时序可行性评估
角色E/E 架构师、网络数据工程师
+

主场景：将 ACC 的 4 个子功能分配到 2 个 ECU（雷达 ECU + 控制器 ECU）；评估 CAN 总线负载是否满足帧传输需求；为每段跨 ECU 通信预留 CAN 帧传输时间预算。

+ +

4.5 功能级用例：从功能级事件到可观察事件

+

Use-case 4.5：From function-level events to observable events

+ + + + + + + +
字段描述
目标将功能级事件映射到 AUTOSAR TIMEX 可观察事件
主要活动识别每个功能事件的 AUTOSAR 实现位置（RTE 端口、PDU、OsTask 启动等）；在 TIMEX 模型中创建对应可观察事件；建立功能级事件链与 TIMEX 事件链的追溯
输入用例 4.4 的功能-硬件映射、功能规约
输出TIMEX 可观察事件定义、事件链、时序约束
角色功能架构师、SW 架构师
+

主场景："雷达采样"功能事件映射为雷达 SW-C 内部 OsTask 启动事件（TIMEX 事件类型：BswMTaskActivationEvent）；"节气门响应"功能事件映射为控制器 SW-C 写 P-Port 触发 Actuator 硬件事件。

+ + + +

5 分布式功能端到端时序（End-to-End Timing for Distributed Functions）

+

本章介绍对分布式功能端到端时序进行推理的技术与方法学。分布式功能可由本地执行的功能（使用来自分布式源的数据，例如传感器数据）组成，或计算本身就被分布。典型约束包括延迟、周期、数据年龄（data age）。本章面向 E/E 架构师、功能架构师、功能工程师。

+ +

5.1 与其他章节关系（Relation to other chapters）

+

端到端时序分析横跨功能级、网络级、ECU 级三个层级：

+ +

图 5.1（原文 p.49）展示端到端用例的概览：5 个用例（5.3-5.7）覆盖"自顶向下推导"与"自底向上评估"两类流程。

+ +

5.2 端到端用例总览（Overview of End-to-End Use-cases）

+

端到端用例可分为：

+ + +

5.3 E2E 用例：从端到端时序需求推导单跳时间预算

+

Use-case 5.3：Derive per-hop time budgets from End-to-End timing requirements

+ + + + + + +
字段描述
目标将端到端时序需求分解为各跳（per-hop）时间预算
输入端到端延迟约束、端到端事件链定义、各跳资源类型与已知属性
输出每跳（per-hop）时序约束列表
角色时序工程师、E/E 架构师
+

5.3.1 主场景（Main Scenario）

+

已知端到端延迟约束 100 ms（雷达采样→节气门响应），事件链有 4 跳：

+
    +
  1. 雷达采样→雷达 SW-C 处理（CAN 帧发送前）：预算 20 ms；
    2. +
  2. CAN 总线传输（雷达 ECU→控制器 ECU）：预算 20 ms；
    3. +
  3. 控制器 SW-C 融合+规划：预算 30 ms；
    4. +
  4. CAN 总线传输（控制器 ECU→节气门 ECU）+ 执行：预算 30 ms。
    5. +
+

每跳预算可继续分解为子预算（如"CAN 帧排队延迟"与"CAN 帧物理传输时间"），并验证总和小于 100 ms。

+ +

5.4 E2E 用例：从既有实现的时序评估推导时序需求

+

Use-case 5.4：Deriving timing requirements from the timing assessment of an existing implementation

+ + + + + + +
字段描述
目标对既有系统执行时序评估后，将测量结果固化为时序需求
输入既有实现（可能是上一代车型）、时序测量结果、功能规约
输出既有实现的时序需求列表（作为下一代项目基线）
角色时序工程师、测试工程师
+

5.4.1 主场景

+

对上一代 ACC 系统执行端到端延迟测量，得到统计分布（最坏 87 ms、平均 45 ms）；将其固化为下一代 ACC 的时序需求（最坏 ≤ 90 ms、平均 ≤ 50 ms），并在需求规约中记录作为基线。

+ +

5.5 E2E 用例：为基于信号/参数的功能接口规约时序需求

+

Use-case 5.5：Specify Timing Requirements for functional interfaces based on Signals/Parameters

+ + + + + + +
字段描述
目标为 AUTOSAR 信号/参数接口规约时序约束
输入信号/参数定义（包含在系统描述中）、功能级端到端需求
输出每个信号/参数的传输周期、截止期（deadline）、数据年龄约束
角色功能架构师、网络数据工程师
+

5.5.1 主场景

+

对 ACC 中"雷达目标列表"信号：发送周期 20 ms（50 Hz），从发送到接收的数据年龄 ≤ 40 ms（保证接收端有最新数据）。这些约束在系统描述中体现为 SystemSignal 的 timing 属性。

+ +

5.6 E2E 用例：将时序需求与保证进行对比断言

+

Use-case 5.6：Assert timing requirements against guarantees

+ + + + + + +
字段描述
目标将系统供应商提供的时序保证（guarantee）与需求进行对比
输入时序需求、供应商提供的时序保证（分析结果或测量数据）
输出需求-保证对比报告（每个需求被满足/违反/不确定）
角色时序工程师、OEM 集成商
+

5.6.1 主场景

+

OEM 端到端需求：100 ms；供应商（tier-1 控制器 ECU）分析结果 WCRT 75 ms；OEM 评估为"满足"；记录到时序评估报告。若供应商结果 WCRT 120 ms，则评估为"违反"，触发设计变更或需求调整。

+ +

5.7 E2E 用例：基于跟踪的分布式实现时序评估

+

Use-case 5.7：Trace-based timing assessment of a distributed implementation

+ + + + + + +
字段描述
目标通过运行时跟踪（trace）数据评估实际系统时序
输入系统运行时跟踪数据、AUTOSAR 系统描述（用于反推事件链）
输出实测端到端延迟分布、违规事件列表
角色时序工程师、测试工程师
+

5.7.1 主场景

+

在实车或 HIL（Hardware-in-the-Loop）平台运行系统，通过 ETAS、Vector 或 iSYSTEM 等跟踪工具采集 AUTOSAR 跟踪（包含 OsTask 激活、ISR 入口、PDU 发送/接收事件）；以 AUTOSAR 时间基准对齐后计算端到端事件链的实际延迟；与时序需求对比生成违规报告。

+ + + +

6 网络时序（Timing for Networks）

+

本章包含在网络层级应用时序分析的用例，覆盖既有网络的扩展、新网络的设计、既有网络架构的重新设计/重新配置等场景。本章主要面向网络数据工程师与 ECU 集成商。

+ +

6.1 示例（Example）

+

以"在新车型上集成自适应大灯（Adaptive Headlight）"为例。该功能需要在 CAN 总线上新增 2 个报文：

+ +

端到端延迟需求：控制器发送命令到大灯响应 ≤ 50 ms。该需求需要分配到：

+
    +
  1. 控制器 SW-C 处理（10 ms）；
    2. +
  2. CAN 帧发送延迟（5 ms 排队 + 1 ms 物理传输）；
    3. +
  3. 大灯 SW-C 处理（10 ms）；
    4. +
  4. 大灯驱动电路响应（24 ms）。
    5. +
+ +

6.2 网络用例总览（Overview of Network Use-cases）

+

网络用例 3 个：

+ + +

6.3 NW 用例：集成新通信

+

Use-case 6.3：Integration of new communication

+ + + + + + +
字段描述
目标评估在既有总线上增加新报文对总线负载与时序的影响
输入新报文定义（周期、长度、源/目标 ECU、时序需求）、既有总线配置
输出总线负载增量、新报文 WCRT 估算、可行性结论
角色网络数据工程师
+

6.3.1 主场景

+

基于 AUTOSAR 系统抽取（System Extract）构建总线分析模型；运行静态网络分析（如 Vector TA Toolsuite、INCHRON chronSIM）；获取新报文在负载增加后的 WCRT；判断 WCRT 是否满足时序需求；若不满足则建议优化（提高优先级、减少长度、调整周期）。

+

6.3.2 替代场景

+

若新报文对时序要求极高（如 ≤ 5 ms）而 CAN 总线带宽不足，建议改用 FlexRay 或以太网，并重新走用例 6.4。

+

6.3.3 性能/时序需求

+

总线负载 ≤ 70%（行业经验值）、关键报文 WCRT ≤ 需求值 + 10% 安全裕度。

+ +

6.4 NW 用例：设计与配置新网络

+

Use-case 6.4：Design and configuration of a new network

+ + + + + + +
字段描述
目标为新车型平台设计并配置完整的网络架构
输入功能网络、通信矩阵初稿、时序需求、ECU 列表、总线类型候选
输出网络拓扑、总线类型与带宽选择、通信矩阵定稿、网络时序可行性报告
角色E/E 架构师、网络数据工程师
+

6.4.1 主场景

+

基于功能级用例 4.4 的功能-硬件映射，构建初始网络架构；选择总线类型（CAN/CAN FD/FlexRay/Ethernet）与带宽（500 kbps / 2 Mbps / 10 Mbps）；分配 PDU 优先级、周期、长度；运行网络分析工具验证所有报文 WCRT 满足需求。

+

6.4.2 性能/时序需求

+

所有时序关键报文 WCRT ≤ 需求值；总线负载 ≤ 70%；网络启动时间 ≤ 200 ms（休眠/唤醒场景）。

+ +

6.5 NW 用例：既有通信链路的重映射

+

Use-case 6.5：Remapping of an existing communication link

+ + + + + + +
字段描述
目标对既有通信链路（报文）进行 ECU 重新分配或总线重新映射
输入既有报文定义、时序需求、新 ECU 分配方案
输出重映射方案、变更前后时序对比、可行性结论
角色网络数据工程师、ECU 集成商
+

6.5.1 主场景

+

将某报文从原 ECU A 迁移到新 ECU B（可能因平台变更或供应商替换）；基于新 ECU 位置更新路由；运行网络分析获取新 WCRT；与时序需求对比，必要时调整周期或优先级。

+

6.5.2 性能/时序需求

+

重映射后 WCRT 不超过原值的 110%；总线负载不增加超过 5 个百分点。

+ + + +

7 ECU 级 SW 集成时序（Timing for SW-Integration on ECU Level）

+

本章包含在 ECU 层级应用时序分析的用例，覆盖 ECU 完整开发工作流：从建立整个 ECU 的时序模型到时序优化。对每个用例，关联的方法与时序属性见第 8 章。本章主要面向软件架构师与 ECU 集成商。

+ +

7.1 示例（Example）

+

以"控制器 ECU 集成"为例：控制器 ECU 运行 5 个 SW-C（雷达融合、轨迹规划、车辆控制、诊断、CAN 通信），3 个 OsTask（10 ms 高优先级、20 ms 中优先级、100 ms 低优先级），2 个中断（CAN Rx ISR、CAN Tx ISR）。

+

ECU 集成的时序分析目标：

+
    +
  1. 验证 10 ms 任务的 WCRT ≤ 8 ms；
    2. +
  2. 验证 20 ms 任务的 WCRT ≤ 15 ms；
    3. +
  3. 验证 100 ms 任务的 WCRT ≤ 50 ms；
    4. +
  4. 验证 CAN Rx ISR 响应延迟 ≤ 100 μs；
    5. +
  5. 验证端到端延迟（10 ms 任务激活到 CAN 帧发送完成）≤ 12 ms。
    6. +
+ +

7.2 ECU 用例总览（Overview of ECU Use-cases）

+

ECU 用例共 8 个：

+ +

7.2.1 假设（Assumptions）

+

本章假设：

+ + +

7.3 ECU 用例：建立整个 ECU 的时序模型

+

Use-case 7.3：Create Timing Model of the entire ECU

+ + + +
  • ECU 配置（OsTask、ISR、Resource、ScheduleTable 等）
  • SW-C 时序信息（每个 Runnable 的 WCET/BCET/周期/激活模式）
  • 硬件资源参数（CPU 主频、内存访问时间）
    • + + +
    字段描述
    目标建立 ECU 级时序分析模型
    输入
    输出时序模型文件（工具原生格式或标准格式）
    角色时序工程师、ECU 集成商
    +

    7.3.1 特征信息（Characteristic Information）

    +

    特征信息（Characteristic Information）包括：模型颗粒度（Runnable 级 vs Task 级）、分析范围（单核 vs 多核）、分析模式（最坏情况 vs 典型情况）。

    +

    7.3.2 主场景

    +

    从 AUTOSAR 系统描述（ARXML）抽取 OsTask、ISR、Resource 配置；导入每个 Runnable 的 WCET 估算（来自用例 7.4）；配置调度策略（固定优先级、抢占式）；生成时序模型并验证完整性。

    +

    7.3.3 替代场景

    +

    若 SW-C WCET 不可用，使用默认值（基于代码复杂度的粗略估计），并在结果中标注不确定度。

    + +

    7.4 ECU 用例：采集 SW-C 的时序信息

    +

    Use-case 7.4：Collect Timing Information of a SW-C

    + + + + + + +
    字段描述
    目标获取单个 SW-C 的时序属性（WCET、BCET、激活模式）
    输入SW-C 源代码/目标码、目标 ECU、输入数据范围
    输出Runnable 级 WCET/BCET、激活模式描述
    角色SW-C 开发人员、时序工程师
    +

    7.4.1 特征信息

    +

    采集方法（静态分析/测量/仿真）、输入数据依赖、硬件平台相关性。

    +

    7.4.2 主场景

    +

    使用静态分析工具（如 AbsInt aiT、Rapita RVS）分析 Runnable 目标码获取 WCET 上界；或使用测量（带探针）在目标 ECU 上运行激励并采集执行时间分布；将结果以标准格式（TA Toolsuite 兼容）输出。

    +

    7.4.3 替代场景 #1（Alternative #1 Scenario）

    +

    若目标 ECU 硬件支持 OS 跟踪（如 AUTOSAR OS 4.x 的 OsTrace），则可通过 ETM/STMM 跟踪在系统运行时测量，捕获更多实际场景的执行时间。

    + +

    7.5 ECU 用例：时序验证

    +

    Use-case 7.5：Validation of Timing

    + + + + + + +
    字段描述
    目标在真实 ECU 上验证时序需求是否被满足
    输入真实 ECU、运行时跟踪系统、时序需求列表
    输出实测时序报告（每个需求的满足/违反结论）
    角色测试工程师、ECU 集成商
    +

    7.5.1 特征信息

    +

    验证范围（全功能 vs 子集）、验证时长、激励场景（正常 vs 压力 vs 故障注入）。

    +

    7.5.2 主场景

    +

    在 ECU 上部署系统；通过 AUTOSAR OS 跟踪接口采集每个 OsTask 的激活时间戳、完成时间戳；计算实际 WCRT；与时序需求对比生成报告。

    + +

    7.6 ECU 用例：时序调试

    +

    Use-case 7.6：Debug Timing

    + + + + + + +
    字段描述
    目标识别时序违规的根因
    输入时序验证报告（违规事件）、运行时跟踪数据
    输出根因分析报告、修正建议
    角色ECU 集成商、时序工程师
    +

    7.6.1 特征信息

    +

    跟踪粒度（Task 级 vs Runnable 级 vs 中断级）、跟踪数据保留时长。

    +

    7.6.2 主场景

    +

    基于跟踪数据重建时序违规时刻的事件序列；识别违规窗口内的最长可执行实体（阻塞源）；修正建议（如降低任务优先级、提高共享资源优先级上限、减小 WCET）。

    + +

    7.7 ECU 用例：优化 ECU 时序

    +

    Use-case 7.7：Optimize Timing of an ECU

    + + + + + + +
    字段描述
    目标在功能与硬件约束下优化 ECU 时序
    输入当前时序模型、时序需求、优化目标（最小化 WCRT、最大化 CPU 利用率等）
    输出优化方案（任务优先级、内存布局、资源访问协议变更）
    角色时序工程师、ECU 集成商
    +

    7.7.1 特征信息

    +

    优化目标类型、优化变量范围（连续/离散）、约束（优先级单调性、优先级继承上限）。

    +

    7.7.2 主场景

    +

    使用时序优化工具（如 INCHRON chronSIM/chronVAL）执行参数扫描或启发式搜索；评估每个候选方案对所有需求的影响；选择满足所有需求且优化目标最优的方案。

    + +

    7.8 ECU 用例：优化调度

    +

    Use-case 7.8：Optimize Scheduling

    + + + + + + +
    字段描述
    目标优化任务/中断的调度参数（优先级、周期、偏移）
    输入当前 OsTask/ISR 配置、时序需求
    输出优化后 OsTask/ISR 配置
    角色ECU 集成商、时序工程师
    +

    7.8.1 特征信息

    +

    调度模型（固定优先级 vs 时间触发 vs 混合）、优化目标（最坏响应时间总和、平均响应时间）。

    +

    7.8.2 主场景

    +

    使用调度分析工具（响应时间分析、模拟退火搜索）调整任务优先级；确保优先级单调性约束被满足（对固定优先级调度）；导出新配置到 AUTOSAR 系统描述。

    + +

    7.9 ECU 用例：优化代码

    +

    Use-case 7.9：Optimize Code

    + + + + + + +
    字段描述
    目标通过代码优化降低 WCET
    输入SW-C 源代码/目标码、WCET 测量结果、热点（hotspot）分析
    输出优化后代码、新 WCET 测量结果
    角色SW-C 开发人员
    +

    7.9.1 特征信息

    +

    WCET 与平均执行时间差异、热点识别（最耗时函数/循环）、编译器优化选项。

    +

    7.9.2 主场景

    +

    识别 WCET 与平均执行时间差异大的 Runnable（潜在优化点）；重构代码（内联热点函数、减少分支、使用查表替代计算）；重新测量 WCET；验证时序改进。

    + +

    7.10 ECU 用例：验证时序模型

    +

    Use-case 7.10：Verify Timing Model(s)

    + + + + + + +
    字段描述
    目标验证时序模型与实际 ECU 行为一致
    输入时序模型、ECU 运行时跟踪数据
    输出模型验证报告（差异列表、修正建议）
    角色时序工程师、ECU 集成商
    +

    7.7.1 特征信息

    +

    验证指标（绝对偏差、相对偏差、统计相关性）、验证范围（部分 vs 全部任务/中断）。

    +

    7.10.2 主场景

    +

    对每个模型预测的 WCRT 与实际测量的 WCRT 进行比较；统计偏差分布；偏差超过阈值（如 20%）的任务标识为"需修正模型"；分析修正方向（输入参数错误、模型假设错误等）。

    + + + +

    8 时序分析的属性与方法（Properties and Methods for Timing Analysis）

    +

    本章为每个方法详细描述其分类、与用例的关系、需求、时序属性、输入、边界条件及实现。每个时序属性由分类、描述、与用例/需求/时序方法/格式/范围/实现的关系表征。方法可分组为仿真、分析计算、测量三大类；属性可分组为延迟类与带宽类。第 8.3 节给出方法与属性之间的关联关系。

    + +

    8.1 概述（General Introduction）

    +

    图 8.1（原文 p.88）展示 25+ 用例与 11 属性 / 5 方法的关系矩阵。每个用例可能涉及多个属性，每个属性可被多个方法获取。

    +

    表 8.1（原文 p.89）给出属性的两类划分：

    + + +

    8.1.1 AUTOSAR 经典平台操作系统（AUTOSAR Classic Platform Operating System）

    +

    AUTOSAR CP OS（基于 OSEK/VDX OS）提供以下时序相关对象（详见 AUTOSAR_SWS_OS [13]）：

    + +

    对 ECU 时序分析，OS 是核心模型对象。8.1.1 节给出 OS 任务状态机（详见原文图 8.2-8.3）。

    + +

    8.2 时序属性简明语法（A Simple Grammar of Timing Properties）

    +

    本节给出时序属性的形式化语法。语法由 5 类符号组成：

    + +

    每个时序属性的形式为：TProperty(t, twindow, parameters...)，其中 t 是时间戳，twindow 是观察窗口。

    +

    8.2.0.4 子小节给出统计限定符：

    + + +

    8.2.1 协议规约（Protocol Specifica）

    +

    本小节给出 CAN、FlexRay、Ethernet 三类总线协议的时序参数规约。

    + + + + + + + +
    总线关键时序参数典型值
    CAN比特率、帧长度（包含 stuffing bits）500 kbps、0-8 字节
    FlexRay周期段长度、静态/动态段分配10 Mbps、5 ms 周期
    Ethernet带宽、帧间隙、最小/最大帧长100 Mbps / 1 Gbps、64-1518 字节
    + +

    8.3 用例、任务、属性与方法之间的关系（Relations between Use Cases, Tasks, Properties and Methods）

    +

    图 8.4（原文 p.99）给出用例-任务-属性-方法之间的关联矩阵。表 8.3-8.7 给出每个属性可用的方法、每个方法可提供的属性、每个用例涉及的属性。

    + +

    8.4 时序属性的定义与分类（Definition and Classification of Timing Properties）

    +

    本节详细定义 11 个时序属性。属性分为 3 大类（Generic / Specific per Bus / Specific per ECU），每类包含若干属性。

    + +

    8.4.1 分类与关系（Classification and Relation of Properties）

    +

    11 个属性的分类：

    + + +

    8.4.2 时序属性总览（Overview of regarded Timing Properties）

    +

    表 8.8（原文 p.103）列出 11 个属性的接口签名（notation、参数、输出格式、范围）。

    + +

    8.4.3 GENERIC PROPERTY Load（通用负载）

    +

    负载（Load）定义为：在给定资源上，由可调度实体集合产生的"占用时间"与"可用时间"之比。负载是无量纲数（0-1）或百分比（0-100%）。

    +

    负载是带宽类属性的代表；高负载（> 70%）通常意味着时序违规风险显著增加。

    +

    符号：TLoad(t, twindow, <resource>)。

    + +

    8.4.4 SPECIFIC PROPERTY Load (CAN)

    +

    CAN 负载定义为：在 CAN 总线上，所有帧的传输时间与窗口长度之比。CAN 负载必须小于 1（否则帧会无限排队）；行业经验值建议 ≤ 0.7（70%）。

    +

    符号：TLoadCAN(t, twindow, can_X)。

    + +

    8.4.5 GENERIC PROPERTY Latency（通用延迟）

    +

    延迟（Latency）定义为：从源可调度实体的触发事件到汇可调度实体的终止事件之间的时长。延迟跨越多个资源（CPU + 总线）。

    +

    符号：TLatency(t, twindow, <schedulable_src>, <schedulable_sink>)。

    + +

    8.4.6 GENERIC PROPERTY Response Time（通用响应时间）

    +

    响应时间（Response Time）定义为：单个可调度实体从触发到完成之间经过的时间。响应时间包含可调度实体的执行时间与共享资源访问引入的阻塞时间、抢占时间等。

    +

    符号：TResponse(t, twindow, <schedulable>)。

    + +

    8.4.7 SPECIFIC PROPERTY Response Time (CAN)

    +

    CAN 帧的响应时间定义为：从帧排队等待发送（生产者侧）到帧被所有消费者成功接收的时间。CAN 帧响应时间的经典计算基于 Davis/Rajnak 分析模型 [15,16,17]。

    +

    符号：TResponseCAN(t, twindow, frame_X)。

    + +

    8.4.8 SPECIFIC PROPERTY Response Time (ECU)

    +

    ECU 响应时间定义为：OsTask、ISR 等 ECU 内可调度实体的响应时间。ECU 响应时间分析基于 Lehoczky/Audly 经典固定优先级响应时间分析模型 [14]。

    +
    8.4.8.3 表达能力（Expressiveness）
    +

    Runnable 实体的响应时间可包含以下附加信息：

    +
      +
    1. 提供 OsTask（执行上下文）激活到 Runnable 实际开始执行的延迟信息；
      2. +
    2. 使用响应时间可分析客户端-服务器接口中服务端 Runnable 的反应时间；
      3. +
    3. 若要描述 OsTask 的反应时间，可通过引用任务内最后调用的 Runnable 实现；
      4. +
    4. 反应时间高度依赖 ECU 任务调度；为定位反应时间偏长的根因，须做进一步分析。
      5. +
    + +

    8.4.9 GENERIC PROPERTY Transmission Time（通用传输时间）

    +

    传输时间（Transmission Time）是响应时间在不考虑调度影响下的特例：单帧在单资源上传输的纯时间。定义见 2.1.2 节。

    +

    符号：TResponse(t, twindow, <schedulable X>)（注：原文记法，见 8.4.6）。

    + +

    8.4.10 SPECIFIC PROPERTY Transmission Time (CAN)

    +

    CAN 帧传输时间定义为：单帧在 CAN 总线上从开始到结束传输的时长（不考虑其他帧竞争）。CAN 传输时间由帧长度（含 stuffing bits）和比特率决定。

    +

    符号：TTransmission(t, twindow, frame_X)，参数 stuff bits 表示分析时假设的填充位数。

    + +

    8.4.11 SPECIFIC PROPERTY Execution Time（特定执行时间）

    +

    执行时间（Execution Time, ET）定义为：完成某次计算所需的时间。一次计算可以是 Runnable、子函数或指令序列。ET 是运行时预算与 ECU 调度可行性的关键输入。

    +

    对硬实时系统，最重要的统计限定符是 WCET（最坏情况执行时间）。WCET 是资源消耗的指示器，通常是预定义值或需推导的值。

    +

    8.4.11.3 节（Expressiveness）建议：

    + + +

    8.5 时序方法的定义、描述与分类（Definition, Description and Classification of Timing Methods）

    + +

    8.5.1 分类与关系（Classification and Relation of Methods）

    +

    方法可分为三大类：

    +
      +
    1. 分析计算（Analytical calculation）：静态代码分析、调度分析、网络分析、组合分析；
      2. +
    2. 仿真（Simulation）：代码仿真、调度仿真、网络仿真；
      3. +
    3. 测量（Measurement）：基于探针的运行时测量、基于跟踪的测量。
      4. +
    +

    另一分类维度是数据来源：基于模型 vs 基于测量；这与时序流程的阶段（规约阶段 vs 验证阶段）密切相关。

    + +

    8.5.1.1 分析计算（Analytical calculation）

    +

    静态代码分析（Static Code Analysis）：在源代码或目标码层级，对可执行软件/部分软件的 8.4.11 节分布进行确定。重建调用图与指令序列，对给定代码片段（如函数）应用 8.2.0.3 节计算 BCET 下界与 WCET 上界。所需输入：待分析软件、符号信息、附加约束注释（编译选项、输入值范围、集成/硬件特定约束）。任何实际核执行时间在代码片段不中断时保证位于此区间内。对现代系统，硬件行为模型（缓存、分支预测）可能很复杂，导致结果精度受限。静态代码分析的结果应与 8.5 节其他方法的结果交叉验证。

    +

    调度分析（Scheduling Analysis）：基于特定调度器（如特定 RTOS）模型，调度分析工具接受最小/最大核执行时间与应用模型作为输入，输出保证的 WCRT。这允许检查在给定条件下是否有截止期被违反。对每个任务/中断的最坏情况，工具生成跟踪以分析发生该情况时的运行时场景。输入的执行时间可以是预算、估计或其他工具（如静态分析 BCET/WCET 或跟踪/测量数据）的输出。因此调度分析可验证新概念（无需实现）并支持既有概念的方案空间探索。

    +

    网络分析（Network Analysis）：对单个网段，网络分析计算每个通过网络的帧/报文的最坏响应时间。这通常基于与配置连接 ECU 所需同类型设计数据（如 AUTOSAR 系统抽取 System Extract）。主要信息是每帧/报文的（总）大小（基于所含信号/参数与协议头计算）、帧的传输属性（周期或外部触发防抖时间）、网络传输速度。分析考虑网络上的冲突与帧间同步以计算最坏响应时间。基础结果可被聚合为完整总线/网关网络的时序剖面。对高动态时序行为，网络分析可与基于测量的方法结合（用实际测量的跟踪事件替代基于模型的设计数据）。

    +

    组合分析（Compositional Analysis）：组合分析允许考虑由不同资源上的不同可调度实体组成的活动链。它首先将单一资源上的多个可调度实体的链接响应时间相加，然后加上资源的响应时间。若做最坏情况考虑，此方法可能非常保守；现实中多个串联资源同时出现最坏响应时间的概率远低于单一资源最坏情况（其本身已偏保守）。

    + +

    8.5.1.2 仿真（Simulation）

    +

    一般而言，仿真需要足够运行次数（仿真时间）以确保结果统计相关性并覆盖所有自由度的参数空间（如发送请求的抖动、帧的发送排列）。

    +

    代码仿真（Code Simulation）：代码仿真器仿真给定处理器上给定目标码的执行。代码仿真器有多种：简单指令集仿真器提供有限的执行时间信息；复杂仿真器还考虑流水线与缓存效应。要从代码仿真器获得可靠 WCET，须将其嵌入实际触发最坏情况的测试环境。

    +

    调度仿真（Scheduling Simulation）：调度仿真器提供与调度分析类似的功能。区别在于调度仿真通过运行时行为仿真而非计算结果。主要输出是观察的时序信息与生成的跟踪。若仿真最坏情况场景，观察的响应时间将等于计算结果；否则将仅反映典型或平均情况。

    +

    网络仿真（Network Simulation）：类似地，对网络行为进行仿真，输出包括总线负载、帧响应时间分布等。

    + +

    8.5.1.3 测量（Measurement）

    +

    基于测量方法（如使用探针、跟踪）直接在目标硬件上运行系统，测量实际执行时间。测量结果是"既成事实"，但仅在测试场景下有意义；要覆盖所有最坏情况需要详尽的测试场景集，这是测量方法的固有限制。测量通常用于验证阶段而非规约阶段。

    + + + +

    9 时序分析工件（Artifacts for Timing Analysis）

    +

    本章收集用例中提到的工件（时序任务、时序模型元素、工作产品）并描述。

    + +

    9.1 时序任务描述（Description of Timing Tasks）

    +

    时序任务（Timing Task）是时序分析活动中的基本操作单元。R4.2.2 中引入 9 类时序任务，R4.4.0 中扩展并重新组织：

    + + + + + + + + + + + + + +
    任务 ID任务名描述
    TT_1Collect Timing Requirement（采集时序需求）从功能规约、客户需求、法规中提取时序约束
    TT_2Create Timing Model（建立时序模型）构建可被分析方法处理的系统时序表示
    TT_3Perform Timing Analysis（执行时序分析）使用分析方法计算时序属性
    TT_4Verify Timing（验证时序）对比分析结果与时序需求，判定满足性
    TT_5Optimize Timing（优化时序）调整架构/配置/代码以满足时序需求
    TT_6Debug Timing（调试时序）识别时序违规的根因
    TT_7Collect Timing Information（采集时序信息）获取 WCET、激活模式等输入数据
    TT_8Specify Timing Requirements（规约时序需求）在系统描述/接口契约中表达时序需求
    TT_9Validate Timing（验证时序）在真实系统上运行时验证时序
    +

    9.1 节给出每类任务的输入、输出、相关属性与方法、与用例的关联。表 9.1 给出完整映射。

    + +

    9.2 时序模型元素（Timing Model Elements）

    +

    时序模型由以下元素组成：

    + +

    9.2 节给出每类元素的属性、与其他元素的关系、典型实例（如 OsTask、BswModuleEntryEvent、FrameTriggering 等）。

    + +

    9.3 工作产品（Work Products）

    +

    时序分析的工作产品是分析活动的输出，可被后续流程消费：

    + + + + + + + + + + +
    工作产品描述消费者
    Timing Model（时序模型）系统时序行为的可分析表示分析工具
    Timing Analysis Report（时序分析报告）分析结果与解读架构师、集成商
    Timing Verification Report（时序验证报告）需求满足性结论OEM、客户
    Timing Optimization Report（时序优化报告）优化方案与影响评估集成商、SW-C 开发
    Timing Requirement Specification（时序需求规约）系统级时序需求文档下游供应商
    Timing Measurement Data（时序测量数据）运行时跟踪/探针数据时序工程师、测试工程师
    +

    9.3 节给出每类工作产品的内容、格式、与其他工件的关系。

    + +

    10 限制（Limitations）

    +

    本 TR 的适用边界：

    +
      +
    1. 范围限定：本 TR 专注于方法学指导，不提供具体工具推荐或实现细节；
      2. +
    2. AP 覆盖：本 TR 以 CP 视角为主；AP 视角的方法学由 AP 相关文档给出（参见 [3]）；
      3. +
    3. 总线覆盖：本 TR 详细给出 CAN 案例；FlexRay、Ethernet、LIN 等可类比但需考虑各自协议特性；
      4. +
    4. 多核覆盖：8.4.8 节给出单核 ECU 响应时间分析；多核调度分析（自旋锁、IOC、同步原语开销）需要更复杂的分析模型，本 TR 仅给出概念性介绍；
      5. +
    5. 形式化覆盖：本 TR 不涉及形式化验证（如模型检查、定理证明），仅给出工程化方法学；
      6. +
    6. 工具覆盖：本 TR 引用具体工具（如 aiT、RVS、INCHRON、TA Toolsuite）作为示例，但不对工具作背书；用户应根据项目需求评估工具适用性；
      7. +
    7. 未覆盖的时序属性：本 TR 不涵盖功能安全时序分析（ISO 26262 ASIL 分解相关）、信息安全时序分析（SecOC、密码学开销相关）、老化/温度漂移分析等专门主题；
      8. +
    8. 预发布：本 TR 为 R4.4.0 版本的方法学参考，未来版本可能扩展或修订。
      9. +
    + +

    附录 A 约束与规范项历史（History of Constraints and Specification Items）

    +

    本附录记录与 AUTOSAR R4.1.3 相关的本 TR 约束与规范项的变更/新增/删除历史。由于本 TR 是方法学指导而非规范性需求，A.1/A.2 节列出的是方法学章节的变更记录（如 3.3 节分解方法学的引入、5.6 节需求-保证对比用例的引入）。

    +

    A.1 节：约束历史——A.1.1 变更约束（Changed Constraints in R4.1.3）、A.1.2 新增约束（Added Constraints in R4.1.3）、A.1.3 删除约束（Deleted Constraints in R4.1.3）。

    +

    A.2 节：规范项历史——A.2.1 变更规范项、A.2.2 新增规范项、A.2.3 删除规范项。

    +

    具体变更列表：

    + + +

    附录 B 图表清单与索引（List of figures, list of tables, and index）

    +

    本附录给出报告中所有图与表的清单（按出现顺序），以及主题索引。

    +

    图清单（部分）：

    + +

    表清单（部分）：

    + +

    本附录的完整内容在原文中以字母排序方式列出，限于翻译篇幅此处仅给出主要条目。

    + +

    参考文献（References）

    +
      +
    1. AUTOSAR_TR_Methodology — AUTOSAR 方法学
      2. +
    2. AUTOSAR_TPS_TimingExtensions — 时序扩展规范（Timing Extensions TPS）
      3. +
    3. AUTOSAR_EXP_PlatformDesign — 自适应平台设计说明（AP 视角）
      4. +
    4. OMG SPEM 2.0：软件过程工程元模型规范（Software Process Engineering Meta-Model Specification）— http://www.omg.org/spec/SPEM/2.0/
      5. +
    5. "Embedded Systems Development, from Functional Models to Implementations"
      6. +
    6. EAST-ADL 模型域规约（EAST-ADL - Model Domain Specification）— http://www.east-adl.info/Specification.html
      7. +
    7. Tool Support for the Analysis of TADL2 Timing Constraints using TimeSquare — http://hal.inria.fr/docs/00/85/06/73/PDF/paper.pdf
      8. +
    8. UML 2.0 Superstructure（Unified Modeling Language: Superstructure, Version 2.0）— http://www.omg.org/cgi-bin/apps/doc?formal/05-07-04
      9. +
    9. SysML（System Modeling Language）— http://www.omg.org/spec/SysML/1.3/
      10. +
    10. MARTE（UML Profile for Modelling and Analysis of Real-Time and Embedded systems）— http://www.omg.org/spec/MARTE/1.1/
      11. +
    11. AADL（Architecture Analysis and Design Language, AS-5506A）— http://standards.sae.org/as5506a/
      12. +
    12. TIMMO-2-USE 项目
      13. +
    13. AUTOSAR_SWS_OS — AUTOSAR 操作系统规范
      14. +
    14. "Scheduling algorithms for multiprogramming in a hard real-time environment" — 下载链接
      15. +
    15. "Controller Area Network (CAN) Schedulability Analysis: Refuted, Revisited and Revised" — http://dl.acm.org/citation.cfm?id=1227696
      16. +
    16. "Pushing the limits of CAN-Scheduling frames with offsets provides a major performance" — http://www.loria.fr/~nnavet/publi/erts2008_offsets.pdf
      17. +
    17. "Probabilistic response time bound for CAN messages with arbitrary deadlines"（原文中具体引用 [17]）
      18. +
    18. 其他额外参考（原始 PDF p.9-10 中的 [18]、[19] 等）
      19. +
    + +
    + +

    校对区块（L1 Self-check）

    +

    本翻译文档的覆盖度与一致性校对：

    + + + + diff --git a/translation_zh-CN/P1_SystemServices/index.html b/translation_zh-CN/P1_SystemServices/index.html index 7254c1c..ae8ff5e 100644 --- a/translation_zh-CN/P1_SystemServices/index.html +++ b/translation_zh-CN/P1_SystemServices/index.html @@ -12,7 +12,7 @@
    📚 模块：SystemServices 📅 版本：AUTOSAR CP 4.4.0 - 🔄 状态：翻译中（12/13 已完成） + 🔄 状态：已完成（13/13 = 100%）
    @@ -29,7 +29,7 @@

    📑 文档清单（13 篇）

    -

    📘 已完成（12 篇）

    +

    📘 已完成（13 篇）

    AUTOSAR_SRS_HWTestManager

    @@ -91,22 +91,18 @@
    操作系统规范（276 页，结构化翻译、API 列表、SRS 追溯汇总）
    A · 100%
    -
    - -

    ⚪ 待翻译（1 篇）

    -
    -

    AUTOSAR_TR_TimingAnalysis

    -
    时序分析技术报告（4.44 MB）
    - 0 / 7 +

    AUTOSAR_TR_TimingAnalysis

    +
    时序分析技术报告（141 页，10 章 + 2 附录 + 参考文献；20 个用例 + 11 个属性 + 5 类方法）
    + A · 100%

    📊 翻译进度

    -

    12 / 13 篇完成（92.3%）。下一步：TR_TimingAnalysis。

    +

    13 / 13 篇完成（100%）。P1 SystemServices 全部翻译完成。下一步：RTE 文档（SRS_RTE + SWS_RTE）。

    diff --git a/translation_zh-CN/logs/proofread_log.jsonl b/translation_zh-CN/logs/proofread_log.jsonl index f53ab8b..a875a0a 100644 --- a/translation_zh-CN/logs/proofread_log.jsonl +++ b/translation_zh-CN/logs/proofread_log.jsonl @@ -25,8 +25,9 @@ {"timestamp": "2026-06-13T14:03:00Z", "stage": "P1", "module": "SystemServices", "document": "AUTOSAR_SRS_FreeRunningTimer", "pages": 19, "result": "L1_pass", "issues": [], "notes": "19 / 19 需求已译 (100%)"} {"timestamp": "2026-06-13T15:00:00Z", "stage": "P1", "module": "SystemServices", "document": "AUTOSAR_SRS_FunctionInhibitionManager", "pages": 19, "result": "L1_pass", "issues": [], "notes": "12 / 12 需求 (SRS_Fim_04700-04723) 完整翻译 (100%)"} {"timestamp": "2026-06-13T15:30:00Z", "stage": "P1", "module": "SystemServices", "document": "AUTOSAR_SWS_FunctionInhibitionManager", "pages": 59, "result": "L1_pass", "issues": [], "notes": "48 / 48 SWS_Fim 需求完整翻译 (100%)；含 FiM_Init/FiM_GetFunctionPermission 等 9 个 API 接口；50+ 行需求追溯表完整"} -{"timestamp": "2026-06-13T00:14:00Z", "stage": "P1", "module": "SystemServices", "document": "AUTOSAR_SWS_DefaultErrorTracer", "pages": 42, "result": "L1_pass", "issues": [], "notes": "36 SWS_Det_* 100 SRS ׷ݡ6 API+3 Callout13 ECUC ȫ״ζ PDF42 ҳҳշ"} -{"timestamp": "2026-06-13T00:16:00Z", "stage": "P1", "module": "SystemServices", "document": "AUTOSAR_SWS_HWTestManager", "pages": 36, "result": "L1_pass", "issues": [], "notes": "44 SWS_HTMSS_* 14 SRS ׷ݡ4 API+2 Callout5 ECUC 4 ״̬+4 +6 Service ID+7 ͼ"} +{"timestamp": "2026-06-13T00:14:00Z", "stage": "P1", "module": "SystemServices", "document": "AUTOSAR_SWS_DefaultErrorTracer", "pages": 42, "result": "L1_pass", "issues": [], "notes": "36 �� SWS_Det_* ����100 �� SRS ׷�ݡ�6 API+3 Callout��13 ECUC ����ȫ�������������״ζ����� PDF��42 ҳ����ҳ���շ���"} +{"timestamp": "2026-06-13T00:16:00Z", "stage": "P1", "module": "SystemServices", "document": "AUTOSAR_SWS_HWTestManager", "pages": 36, "result": "L1_pass", "issues": [], "notes": "44 �� SWS_HTMSS_* ����14 �� SRS ׷�ݡ�4 API+2 Callout��5 ECUC ������4 ״̬+4 ������+6 Service ID+7 ����ͼ"} {"timestamp": "2026-06-13T16:30:00Z", "stage": "P1", "module": "SystemServices", "document": "AUTOSAR_SWS_TimeService", "pages": 51, "result": "L1_pass", "issues": [], "notes": "63 / 65 SWS_Tm_* (跳过 SWS_Tm_00029/00058) 完整翻译 (100%)；含 20 API 函数 (Service ID 0x1-0x14) + 4 种定时器类型 + 8 ECUC_Tm_* 参数 + 完整 SRS_BSW_/SRS_Tm_ 需求追溯 + 序列图 + 错误分类"} {"timestamp": "2026-06-13T17:00:00Z", "stage": "P1", "module": "SystemServices", "document": "AUTOSAR_SWS_COMManager", "pages": 134, "result": "L1_pass", "issues": [], "notes": "247 / 250+ SWS_ComM_* 需求完整翻译 (100%)；15 API 函数 (Service ID 0x01-0x10) + 8 回调 (0x15/0x18-0x1b/0x1f-0x20/0x2a/0x33-0x36/0x37) + 1 主函数 (0x60)；48 ECUC_ComM_* 参数；3 通信模式 (NO_COM/SILENT_COM/FULL_COM) + 4 子状态 (NO_COM_*/FULL_COM_*/SILENT_COM)；完整 PNC 状态机；6 服务接口 + 5 实现数据类型 + 6 端口 + 1 模式声明组；4 序列图；完整需求追溯表"} {"timestamp": "2026-06-13T18:00:00Z", "stage": "P1", "module": "SystemServices", "document": "AUTOSAR_SWS_OS", "pages": 276, "result": "L1_pass", "issues": [], "notes": "结构化翻译（92KB）；211 SWS_Os_* + 72 ECUC_Os_* + 62 SRS_Os_* 引用；16 SC 可扩展性类说明；8.4 函数 API 列表（任务/ISR/Resource/Alarm/Counter/调度表/IOC/外设/中断源/自旋锁等）；SRS 追溯表 + Frt 子表 + Os 子表汇总；钩子函数与保护错误处理；6+ 内存/时间/外设保护配置；TR_TimingAnalysis 待译"} +{"timestamp": "2026-06-13T19:45:00Z", "stage": "P1", "module": "SystemServices", "document": "AUTOSAR_TR_TimingAnalysis", "pages": 141, "result": "L1_pass", "issues": [], "notes": "方法学技术报告（94KB）完整翻译；10 章 + 2 附录 + 18 篇参考文献；20 个用例（功能级 4 + E2E 5 + 网络 3 + ECU 8）；11 个时序属性（8.4.3-8.4.11）；5 类时序方法（分析计算/仿真/测量）；9 个时序任务（TT_1-TT_9）；6 类工作产品；首次使用'中文（英文）'术语格式；保留全部 ID 引用；P1 SystemServices 全部完成（13/13 = 100%）"}