diff --git a/translation_zh-CN/P1_SystemServices/AUTOSAR_SRS_FreeRunningTimer.html b/translation_zh-CN/P1_SystemServices/AUTOSAR_SRS_FreeRunningTimer.html new file mode 100644 index 0000000..de47fb7 --- /dev/null +++ b/translation_zh-CN/P1_SystemServices/AUTOSAR_SRS_FreeRunningTimer.html @@ -0,0 +1,528 @@ + + + + +自由运行定时器需求 · AUTOSAR 4.4 中文翻译 + + + + +
+

自由运行定时器需求（Requirements on Free Running Timer）

+
+ 📄 文档 ID：211 + 🏷 类型：SRS（软件需求规范） + 📅 版本：AUTOSAR CP 4.4.0 + 📑 页数：19 + 📌 状态：Final + 🔗 原 PDF：AUTOSAR_SRS_FreeRunningTimer.pdf +
+
+ + + +
+

目录

+ +
+ +
+ +

1 文档范围（Scope of Document）

+

本文档定义了软件自由运行定时器（Software Free Running Timer，SWFRT）功能的需求。OS SWS 规范应当满足这些需求。

+ +

约束：特定微控制器的硬件可能无法支持自由运行定时器功能——那么此功能应当被省略。这在以下情况尤其适用：

+ + +

此模块的可配置性及其与其他模块的依赖关系是最关键的部分，因为许多情况下用于自由运行定时器的定时器应在模块之间共享。实现 SW-FRT 的模块应当导入任何其他工具关于定时器/时钟的设置，而不是定义设置。

+ +

2 约定（Conventions to be Used）

+

AUTOSAR 文档中的需求表示遵循 [5] 中指定的表格。在需求中，使用以下特定语义（基于 IETF RFC 2119）：

+ + +

3 缩略语与缩写（Acronyms and Abbreviations）

+ + + + + + + + + + + + + + + + + + + + + + +
缩略语说明
APIApplication Programming Interface（应用程序编程接口）
BSWBasic Software（基础软件）
COMCommunications（通信）
ECUElectronic Control Unit（电子控制单元）
GPTGeneral Purpose Timer（通用定时器，SWS 模块）
HWHardware（硬件）
Tick硬件定时器的一个增量 = HW 定时器 Tick；如果未明确说明，则指硬件定时器。TickType 由许多 HW-Timer Tick 组成；明确指向时将指出。
Interval of Timer两个测量点之间的时间距离
OSAUTOSAR Operating System（AUTOSAR 操作系统）
Range of Timer定时器可能覆盖的最大间隔
Reset Timer超过预定义边距时以预定义值启动的定时器。
Resolution of Timer可测量的最小时间间隔
SIInternational System of Units（国际单位制，法语缩写 SI）
SLASoftware Layered Architecture（软件分层架构）
SWCSoftware Component（软件组件）
SWFRTSoftware extending features of HW Free running timers（软件扩展硬件自由运行定时器功能）
Test Value当前读出值所比较的值。
Wrap Around定时器达到定义的最大值时采取的动作。
+ +

每个需求都有以 SWFRT 前缀开头的唯一标识符。

+ +

4 功能概述（Functional Overview）

+

本章描述了自由运行定时器（Free Running Timer）模块的功能需求。第 4.1 节通过概述介绍 SWFRT，第 4.2 和 4.3 节包含需求。该功能将被底层软件和应用层访问。因此在 SLA 中的位置需要是服务层（SLA ID：02-06）。

+ +

范围内的功能：

+ +

A) SWFRT 模块提供的代码访问一个或多个硬件定时器。此硬件定时器在运行期间不得被任何其他 SW 模块修改（自由运行硬件定时器或复位定时器，SRS_Gpt_12404：配置为连续模式）。该定时器也可以为不同目的执行功能。SWFRT 代码将可能变化的硬件功能始终映射到相同的 SW 功能：

+ +

功能 A）抽象 GPT 读出函数（SRS_Gpt_12117）或直接硬件访问（定时器单元可由 OS 直接管理，见第 5 章 SWS OS）。

+ +

B) SWFRT 还应扩展硬件的可能有限范围。特别是当硬件定时器的位数受到限制时，范围需要扩展。为此扩展，SWFRT 增加一个循环计数器。此计数器计数的间隔是硬件定时器的最大范围。

+

用于功能 A）和功能 B）的硬件定时器不一定是相同的定时器；在不同时间启动的两个不同硬件定时器以及范围也可以满足此功能。因此，功能 A）的硬件定时器和功能 B）的定时器之间可能会出现偏移。

+ +

范围内的用例：

+ + +

开销限制：

+

应用两种可能功能中的哪一种取决于 SWFRT 导入的配置需求（要测量的最小和最大间隔、定时器的范围和分辨率）以及合理的资源消耗。

+

应当避免高频通知功能。即：不要使用 SRS_Gpt_12120：GPT 通知来提供长范围。而是基于调用 SWFRT 主函数的 OS 任务构建长范围。

+ +

典型用户场景序列：

+
    +
  1. 读取 HW-FRT 或计数器；
    2. +
  2. 执行某些动作；
    3. +
  3. 循环测试此动作的成功；
    4. +
  4. 再次读出上述 FRT，并且
    5. +
  5. 如果与该 FRT 的后续读出值的差异未超过预定义超时，则将此动作标记为成功。
    6. +
+ +

SWFRT 软件功能有时使用多个递增计数器。HW 计数器递增 1 应称为"tick"。进一步，微控制器硬件（HW）可提供仅递增和/或递减的定时器。Ticks 将表示显著不同的值（ns、ms、s）。溢出或超过设定最大值（/最小值）会自动以零（/最大值）重新启动定时器。此动作称为 wrap around（环绕）。

+

在 SWFRT 定时器的定义范围内，任何时间计算都需要调整到环绕值。

+ +

硬件特性抽象

+

应当考虑以下特性：

+ + +

这些硬件特性应当与 MCU、GPT 和 OS 模块一起作为配置参数本地定义（其参数集可能不可移植到不同的微控制器）。它们的集合导致具有定义分辨率和范围的一个定时器的转换规则（可能不可移植到不同的配置）；生成的代码需要为每个新配置从头开始生成。应用这些转换规则将导致函数（宏）以定义的分辨率读取自由运行定时器以及可测量的最大/最小间隔。"用户"对由定时器、规则、分辨率和范围组成的一套感兴趣。

+

以上所有内容都将映射到所涉及模块的配置章节中。

+ +

5 需求追溯（Requirements Tracing）

+ + + + + + + + + + + +
需求描述由以下 SRS 满足
RS_BRF_01048AUTOSAR 模块设计应当支持模块在多任务环境中协作。SRS_Frt_00044
RS_BRF_01056AUTOSAR BSW 模块应当提供标准化接口。SRS_Frt_00033、SRS_Frt_00034、SRS_Frt_00047
RS_BRF_01096AUTOSAR 应当支持 ECU 的启动和关闭。SRS_Frt_00020、SRS_Frt_00029、SRS_Frt_00041、SRS_Frt_00048
RS_BRF_01104AUTOSAR 应当支持 ECU 和总线的睡眠与唤醒。SRS_Frt_00048
RS_BRF_01472AUTOSAR 应当支持模式。SRS_Frt_00022
RS_BRF_01856AUTOSAR 微控制器抽象应当提供对内部 MCU 配置的访问。SRS_Frt_00023、SRS_Frt_00024、SRS_Frt_00025、SRS_Frt_00026
RS_BRF_01904AUTOSAR 微控制器抽象应当提供对硬件定时器的访问。SRS_Frt_00019、SRS_Frt_00020、SRS_Frt_00021、SRS_Frt_00022、SRS_Frt_00023、SRS_Frt_00024、SRS_Frt_00025、SRS_Frt_00026、SRS_Frt_00028、SRS_Frt_00029、SRS_Frt_00030、SRS_Frt_00031、SRS_Frt_00032、SRS_Frt_00033、SRS_Frt_00034、SRS_Frt_00041、SRS_Frt_00044、SRS_Frt_00047、SRS_Frt_00048
+ +

6 需求规范（Requirements Specification）

+

本章中同类需求按以下标题分组：

+ + +

6.1 功能需求（Functional Requirements）

+ +

6.1.1 配置（Configuration）

+

本章说明模块可配置性的需求。

+ +
+

[SRS_Frt_00019] 应当配置硬件定时器类型。

+ + + + + + + + + + +
类型New
描述根据要测量的范围、分辨率和最大/最小间隔，这定义了 SWFRT 模块应使用哪个（或哪些）硬件定时器用于哪个功能。选择满足分辨率范围等需求的定时器类型。这可以是 OS TickType 计数器或微控制器的硬件定时器。
理由限制可用的可能性以及实现的变体/开销。
用例定义：晶振和 PLL 的允许范围以及生成的定时器是否提供恒定频率；定时器应向上计数还是向下计数（虽然不阻碍使用，但所需程序会有所不同）；首选寄存器宽度；该定时器是否需要与寄存器宽度不同的环绕边距；环绕值；是否可以使用预分频器；可为哪些预分频器设置哪些值（范围）；可以级联哪些定时器；环绕之间的时间。
例如：选择 TriCore 的 System Timer。
依赖—
支持材料—
满足RS_BRF_01904
+
+ +
+

[SRS_Frt_00020] 如果不使用 GPT 定时器，配置和初始化应当由提供 SWFRT 功能的模块（OS）执行。

+ + + + + + + + + + +
类型New
描述如果不使用 GPT 定时器，配置和初始化应当由提供 SWFRT 功能的模块（OS）执行。
理由最高效地使用硬件。
用例通常有 "System Timer"、"Periodic Interrupt Timer"、"GPT Timer" 等定时器，可用于 SWFRT 和其他模块。使用哪个类型由需求 6.1.1.1 选择。它们仍具有需要按微控制器详细化和选择的功能——但不是按实现。这些设置不应被彼此覆盖，也不应被遗忘。
依赖SRS_Frt_00021
支持材料—
满足RS_BRF_01904、RS_BRF_01096
+
+ +
+

[SRS_Frt_00021] 计算 tick 持续时间所需的元素应当是导入的配置项。

+ + + + + + + + + + +
类型New
描述如果没有合适的硬件定时器配置，则设置新的硬件定时器配置。这是关于 SWS 第 10 章依赖项的需求。这应当确保设置是由 OS 完成还是 OS 将重用来自不同模块（例如 GPT）的定时器。
理由最高效地使用硬件。
用例硬件定时器能够提供大范围以及分辨率。它可用于 OS TickType 以及 SW FRT 的定时功能。只需应用不同的掩码操作。
依赖SRS_Frt_00020
支持材料—
满足RS_BRF_01904
+
+ +
+

[SRS_Frt_00022] 应当能够说明使用哪个硬件定时器。

+ + + + + + + + + + +
类型Valid
描述—
理由代码将根据使用的定时器而有显著不同。
用例定义将支持哪些定时器。
依赖—
支持材料—
满足RS_BRF_01472、RS_BRF_01904
+
+ +
+

[SRS_Frt_00023] 应当设置一个 tick 的持续时间。

+ + + + + + + + + + +
类型Valid
描述根据对定时器寄存器的访问，这会导致不同的分辨率——必须知道此分辨率。
理由SRS_Frt_00021 和 SRS_Frt_00020 的组合定义了用于哪个定时器及其规则的设置。这些规则按微控制器和硬件定时器（分别为 OS GlobalTimeTickType）定义。
用例在 80MHz 速度下运行的 TC1766 中，寄存器 TIM0 提供 12.5ns 的一个 tick。在用例 -C-（来自介绍章节）中，循环应循环读取定时器值并测试可能有故障的硬件。最大测试间隔为 500ns，因此第一次读取与其连续读取之间的差异被预定义为 40。
这样，基本 SW 模块和应用层都通过抽象的时间提供。
依赖[SRS_Frt_00021]、[SRS_Frt_00020]
支持材料—
满足RS_BRF_01904、RS_BRF_01856
+
+ +
+

[SRS_Frt_00024] SWFRT 应当支持不同的分辨率和范围。

+ + + + + + + + + + +
类型Valid
描述SWFRT 应当支持不同的分辨率和范围。即以覆盖范围和分辨率的方式设置不同 tick 长度的集合。这些由表示不同时间量的 tick 支持（见第 2.1 章表中的范围定义）。范围应当假定为从 0 到最大。
理由—
用例在 40MHz 速度下运行并使用 256 预分频器的 Star12 的 PIT 寄存器集提供 6.4µs 的一个 tick。对 16 位寄存器集寄存器的访问将提供 0...420ms 范围内的 ticks。由于无法覆盖大于 420ms 的间隔，因此应当实现额外的主函数计数器用于 0…2.6E3 s（1.8 天）的范围。
依赖—
支持材料—
满足RS_BRF_01904、RS_BRF_01856
+
+ +
+

[SRS_Frt_00025] 应为不同用户提供访问时间信息的方法。

+ + + + + + + + + + +
类型Valid
描述可能需要不同的定时器、定时器掩码。如果是这样，必须定义每种访问方法。
理由避免在 tick 计数和基于 SI 单位的比较之间的多次转换；改为使用具有预定义测试值的统一方法。
用例可以访问基本 tick，也可以访问每第 n 个 tick。其中 n 取决于微控制器（例如仅读取相应计数器的位 8...24）。如果访问跨越 16/32 位边界或超过一个时钟周期，必须特别注意一致性。
依赖SRS_Frt_00019、SRS_Frt_00020、SRS_Frt_00021、SRS_Frt_00022、SRS_Frt_00023；SRS_Frt_00034
支持材料—
满足RS_BRF_01904、RS_BRF_01856
+
+ +
+

[SRS_Frt_00026] 设置目标计数值：时间差应当在配置时以 SI 单位离线计算。

+ + + + + + + + + + +
类型Valid
描述目标计数值是与读取的定时器值进行比较的值。目标计数值应当以 SI 单位配置。等效的 tick 存储在 ECU 的内存中。
理由运行时应当保持低开销：在配置时计算用于测试定时器差值的边距（而不是在运行时乘以）。
用例离线计算的目标计数值可以是任何配置类。目标计数值是那些将在运行时与定时器的当前值进行比较的常量。这意味着比较指令必须遵守范围、分辨率和有效的定时器间隔。这样代码简化为比较指令。
用户模块所需的值在其 XML 中表达。SWFRT 的自动配置编辑器检查其他模块的时间，当找到时，使用定时器的范围和分辨率的知识来计算以 counter ticks 为单位的时间。然后将这些值放回用户的 XML 中，以便用户的代码生成可以访问这些值。
依赖SRS_Frt_00025
支持材料—
满足RS_BRF_01904、RS_BRF_01856
+
+ +
+

[SRS_Frt_00028] 应当确保连续运行模式。

+ + + + + + + + + + +
类型Valid
描述使用的硬件定时器可以具有不同目的的功能。此硬件应当是自由运行的硬件定时器或复位定时器，SRS_Gpt_12404：配置为连续模式。
理由—
用例—
依赖—
支持材料—
满足RS_BRF_01904
+
+ +

6.1.2 初始化（Initialisation）

+ +
+

[SRS_Frt_00029] 应当提供一个独立于是否需要设置或修改任何寄存器的初始化函数。

+ + + + + + + + + + +
类型Valid
描述如果 MCU 驱动执行初始化，则必须在 MCU 驱动初始化被调用后调用 SWFRT init 函数。如果 GPT 驱动执行初始化，则必须在 GPT 驱动被调用后调用 SWFRT init 函数。
理由确保定时器和 PLL 已初始化。
用例—
依赖—
支持材料—
满足RS_BRF_01904、RS_BRF_01096
+
+ +

6.1.3 正常运行（Normal Operation）

+ +
+

[SRS_Frt_00030] 读出值应当从零开始。

+ + + + + + + + + + +
类型Valid
描述读出值从零开始；即使硬件从最大值向下计数到零。
理由支持定义标准接口。
用例例如，硬件以 0xE000 启动并向下运行到 0x100，由于需要一些比例因子，对读出值的所有调整应当在 SWFRT 内完成。
依赖—
支持材料—
满足RS_BRF_01904
+
+ +
+

[SRS_Frt_00031] SWFRT 应当递增，即连续读出值将增加——除非超过 SWFRT 的定义范围。

+ + + + + + + + + + +
类型Valid
描述这意味着：当硬件定时器向下计数时反转计数器；进一步：调整任何可能存在的偏移（当硬件定时器从某个边距向下计数到零或从某个边距向上计数到溢出时）。
理由支持定义标准接口。
用例—
依赖—
支持材料—
满足RS_BRF_01904
+
+ +
+

[SRS_Frt_00032] 环绕（wrap around）应当无需软件交互即可工作。

+ + + + + + + + + + +
类型Valid
描述—
理由节省运行时。不要让时间"走动"，即中断消耗时间，因此增加了定时器未跟踪的时间。
用例硬件定时器应当配置为连续运行。应当不需要任何动作来重新启动定时器。环绕应当在硬件支持下加载重新启动值：例如，没有额外的自由运行定时器可用。CapCom 定时器应当共享。其配置如下：CapCom 定时器从 0xFFFF 启动，重新加载边距值为 0x3ff，重新加载值为 0xFFFF，计数器配置为向下计数器。向下计数到 0x3FF 后，在没有软件交互的情况下重新加载 0xFFFF。
依赖—
支持材料—
满足RS_BRF_01904
+
+ +
+

[SRS_Frt_00033] 应当有一个原子读取定时器值的函数。

+ + + + + + + + + + +
类型Valid
描述此函数读取定时器 ticks。不包括从定时器 ticks 到 SI 单位（秒、毫秒、微秒、纳秒）的转换。
理由避免不一致的访问。
用例必须一致地读取定时器值（即使跨越字节边界或多个时钟周期）。这可能涉及对 8 位/16 位/32 位/64 位寄存器的保护访问：
例如，TriCore TC1766 提供 56 位的定时器宽度。这 56 位可通过 TIM0 ... TIM6 寄存器访问。其中 TIM0 读取 ticks。TIM1 每 16 ticks 读取一次，TIM2：216，TIM3：4096，TIM4：65536，TIM5：220，TIM6：232。如果按硬件定义的顺序读取寄存器，这些寄存器将在 32 位以上提供一致性。
依赖—
支持材料—
满足RS_BRF_01904、RS_BRF_01056
+
+ +
+

[SRS_Frt_00047] SWFRT 应当提供一个"用户"相关的 API（函数/宏）以将 ticks 转换为时间。

+ + + + + + + + + + +
类型Valid
描述此函数以 ticks 数作为参数，并将其参数转换为 SI 单位（秒、毫秒、微秒、纳秒）的时间。
理由允许转换为基于 SI 的时间单位。
用例A) 外围设备在被访问之前需要启动时间。此启动时间在 HW 描述中指定。需要实现超时（以 SI 单位）以避免读取无效数据。此超时需要映射到 a) 能处理该间隔的硬件定时器 b) 给该定时器 ticks 数的值。
B) 诊断通信需要可变的帧间时间（STMIN）。它们需要设置为测量间隔，范围为 100µs 到 900µ（9 个值）和第二个测量间隔 1...127 ms（126 个值）。这 135 个值需要基于可用的定时器和循环主函数进行离线计算。
依赖—
支持材料—
满足RS_BRF_01904、RS_BRF_01056
+
+ +
+

[SRS_Frt_00034] 该模块应当提供计算先前存储值（作为参数传递）与当前定时器值之间经过的 ticks 的功能。

+ + + + + + + + + + +
类型Valid
描述调用者需要提供最后读取的值。
理由支持不同功能级别（代码大小和执行时间）。
用例读取当前定时器值，并使用参数中的时间函数计算差异。
依赖—
支持材料—
满足RS_BRF_01904、RS_BRF_01056
+
+ +

6.1.4 关闭操作（Shutdown Operation）

+ +
+

[SRS_Frt_00041] SWFRT 不应有关闭操作。

+ + + + + + + + + + +
类型Valid
描述—
理由没有可关闭的内容；并非所有定时器都可以停止。
用例—
依赖—
支持材料—
满足RS_BRF_01904、RS_BRF_01096
+
+ +
+

[SRS_Frt_00048] SW FRT 功能应当在其 Init 函数之后被保证，并且在 ECU 的 'SLEEP'、'Wakeup I'、'StartUP I'、'Go OFF II' 和 'Power Off' 状态下不可用。

+ + + + + + + + + + +
类型Valid
描述在 ECU 的上述状态下，功能将返回未定义的结果，因此在这些状态下不应使用它。
理由PLL 可能不可用/降低等。
用例当存在未知定时器设置的风险时，不要使用此功能。
依赖—
支持材料—
满足RS_BRF_01904、RS_BRF_01104、RS_BRF_01096
+
+ +

6.1.5 故障操作（Fault Operation）

+

无特定需求。

+ +

6.2 非功能需求（Non-Functional Requirements）

+ +

6.2.1 时序需求（Timing Requirements）

+

无特定的时序需求。

+ +

6.2.2 资源使用（Resource Usage）

+ +
+

[SRS_Frt_00044] SWFRT 不应为使用而阻塞定时器。

+ + + + + + + + + + +
类型valid
描述允许多个模块使用相同的定时器。如果其他模块的需求在类似范围内，应当能够重用其配置。
理由支持定时器共享。
用例如果 PWM 以 SWFRT 需求范围内的频率工作，应当提供该定时器供使用。
依赖—
支持材料—
满足RS_BRF_01904、RS_BRF_01048
+
+ +

7 引用的 AUTOSAR 文档（Referenced AUTOSAR documents）

+ + +
+ +
+

📋 校对记录

+

校对轮次：L1 自动校对（2026-06-13）

+ +
+ + + + + \ No newline at end of file diff --git a/translation_zh-CN/P1_SystemServices/AUTOSAR_SRS_HWTestManager.html b/translation_zh-CN/P1_SystemServices/AUTOSAR_SRS_HWTestManager.html new file mode 100644 index 0000000..89972eb --- /dev/null +++ b/translation_zh-CN/P1_SystemServices/AUTOSAR_SRS_HWTestManager.html @@ -0,0 +1,283 @@ + + + + +硬件测试管理器启动与关闭需求 · AUTOSAR 4.4 中文翻译 + + + + +
+

硬件测试管理器启动与关闭需求（Requirements on Hardware Test Manager on start up and shutdown）

+
+ 📄 文档 ID：760 + 🏷 类型：SRS（软件需求规范） + 📅 版本：AUTOSAR CP 4.4.0 + 📑 页数：12 + 📌 状态：Final + 🔗 原 PDF：AUTOSAR_SRS_HWTestManager.pdf +
+
+ + + +
+

目录

+ +
+ +
+ +

1 文档范围（Scope of Document）

+

本文档列出适用于 AUTOSAR HTMSS 模块（Hardware Test Management Startup Shutdown，硬件测试管理启动与关闭）设计的需求。

+ +

2 约定（Conventions to be used）

+

AUTOSAR 文档中的需求表示遵循 [TPS_STDT_00078] 中指定的表格。

+

在需求中，使用以下特定语义（基于 IETF RFC 2119）：

+ + +

3 缩略语与缩写（Acronyms and abbreviations）

+ + + + + + + + + + + + +
缩略语英文说明
ADCAnalog to Digital Converter模数转换器
BISTBuilt In Self Test内建自检
BSWBasic Software基础软件
ECUElectronic Control Unit电子控制单元
EcuMECU State ManagerECU 状态管理器
HTMSSHardware Test Management Startup Shutdown硬件测试管理启动与关闭
MCUMicro Controller Unit微控制器单元
MSTPMicrocontroller Specific Test Package微控制器专用测试包
+ +

4 功能概述（Functional Overview）

+

本模块的目的是提供一个基础设施，用于在 AUTOSAR 标准软件平台中集成/转换微控制器厂商特有的启动与关闭测试（如 BIST）的测试结果/状态。

+ +

本模块的基本功能包括：

+ + +

HTMSS 模块集成在 AUTOSAR BSW 服务层级别。

+ +
+ 图 1：HTMSS 交互概述 + 
+应用 SW-C
+   │
+   ▼
+HTMSS ←→ EcuM
+   │
+   ▼
+MSTP（微控制器专用测试包）
+   │
+   ▼
+硬件
+
+
+ +

HTMSS 模块的预集成需求：

+ + +

4.1 功能需求（Functional Requirements）

+ +

4.1.1 HTMSS 与 MSTP 测试的配置需求

+ +
+

[SRS_HTMSS_00001] HTMSS 应当允许配置启动与关闭测试。

+ + + + + + + + + + +
类型Valid
描述应当能够配置微控制器专用的启动与关闭测试。
理由需要能够根据 HTMSS 集成商的需求选择和配置测试。
用例HTMSS 配置开发者在模块配置集中映射微控制器专用测试。
依赖[SRS_HTMSS_00002]
支持材料—
满足的功能需求FS_HTMSS_00001
+
+ +
+

[SRS_HTMSS_00002] HTMSS 应当允许在单个硬件资源级别配置测试。

+ + + + + + + + + + +
类型Valid
描述应当能够在给定硬件上对各个硬件资源（例如通过模块/通道 ID 选择）进行测试。
理由给定硬件可能包含两个被测资源对应的硬件单元（例如 2 个独立的 ADC 硬件单元）。在此示例中，可能需要单独对每个 ADC 单元进行测试/获取结果。
用例用户可能需要测试所有被测硬件资源（已使用和未使用的），因为某些微控制器厂商可能声明不保证未使用的硬件资源中的错误不会传播或影响微控制器的其他部分。
依赖—
支持材料—
满足的功能需求FS_HTMSS_00001
+
+ +

4.1.2 HTMSS 的主要功能

+ +
+

[SRS_HTMSS_00003] HTMSS 应当提供一个收集 MSTP 测试结果的服务。

+ + + + + + + + + + +
类型Valid
描述HTMSS 应当收集并提供所有已执行测试的测试结果。
理由MSTP 测试结果应当可访问。
用例获得测试结果详情应传达微控制器的故障状态。
依赖[SRS_HTMSS_00001]、[SRS_HTMSS_00002]
支持材料—
满足的功能需求FS_HTMSS_00001
+
+ +
+

[SRS_HTMSS_00004] HTMSS 应当提供一个与应用层软件共享测试结果的机制。

+ + + + + + + + + + +
类型Valid
描述当前的 MSTP 测试结果应当在 RUN 时提供给应用层软件。
理由应用软件评估关键错误并做出反应以确保安全状态（例如从正常运行时切换到降级模式）。
用例应用软件应当根据测试结果维持安全状态。例如根据系统安全目标判断的关键错误可能导致进入安全状态。
依赖[SRS_HTMSS_00001]、[SRS_HTMSS_00002]、[SRS_HTMSS_00004]
支持材料—
满足的功能需求FS_HTMSS_00001
+
+ +

4.1.3 HTMSS 的 EcuM 集成功能

+

以下 HTMSS 模块功能应当集成在 EcuM 模块中。

+ +
+

[SRS_HTMSS_00005] HTMSS 应当提供一个在 EcuM 启动阶段配置/初始化 MSTP 测试的服务。

+ + + + + + + + + + +
类型Valid
描述应当能够通过 HTMSS 接口在 EcuM 启动阶段配置启动与关闭测试。
理由需要初始化以预初始化 HTMSS 和 MSTP 测试的变量。
用例在 MCU 启动期间，硬件被初始化以执行 MSTP 测试。
依赖[SRS_HTMSS_00001]、[SRS_HTMSS_00002]
支持材料—
满足的功能需求FS_HTMSS_00001
+
+ +
+

[SRS_HTMSS_00006] HTMSS 应当提供一个触发测试执行的服务。

+ + + + + + + + + + +
类型Valid
描述应当能够通过 HTMSS 提供的服务函数在 EcuM 启动阶段触发启动测试，在 EcuM 关闭阶段触发关闭测试。
理由启动测试应在 EcuM 启动阶段执行，关闭测试应在 EcuM 关闭阶段执行。
用例在 ECU 启动和关闭阶段，配置的 MSTP 测试被触发执行。
依赖—
支持材料—
满足的功能需求FS_HTMSS_00001
+
+ +

4.1.4 故障操作（Fault Operation）

+ +
+

[SRS_HTMSS_00007] HTMSS 应当提供处理测试失败条件的回调（callout）选项。

+ + + + + + + + + + +
类型Valid
描述在测试失败（关键错误条件）时，应当能够调用错误钩子（error hook）作为回调函数。
理由例如：对测试失败做出反应以触发 ECU 复位、安全状态等。
用例ECU 软件需要通过准备系统状态（例如复位、停止、安全状态）来响应测试失败。
依赖—
支持材料—
满足的功能需求FS_HTMSS_00001
+
+ +

5 需求追溯（Requirements Tracing）

+ + + + + +
需求描述由以下 SRS 满足
FS_HTMSS_00001—SRS_HTMSS_00001、SRS_HTMSS_00002、SRS_HTMSS_00003、SRS_HTMSS_00004、SRS_HTMSS_00005、SRS_HTMSS_00006、SRS_HTMSS_00007
+

注意：目前 HTMSS 概念结果是自包含的，因此不引用 AUTOSAR 中的其他文档（即 FS_HTMSS_00001 在 TR_HWTestManagementIntegrationGuide 中规定）。

+ +

6 参考资料（References）

+ +

6.1 AUTOSAR 交付物

+ + +

6.2 相关标准与规范

+ + +
+ +
+

📋 校对记录

+

校对轮次：L1 自动校对（2026-06-13）

+ +
+ + + + + \ No newline at end of file diff --git a/translation_zh-CN/P1_SystemServices/AUTOSAR_SRS_TimeService.html b/translation_zh-CN/P1_SystemServices/AUTOSAR_SRS_TimeService.html new file mode 100644 index 0000000..665b263 --- /dev/null +++ b/translation_zh-CN/P1_SystemServices/AUTOSAR_SRS_TimeService.html @@ -0,0 +1,317 @@ + + + + +时间服务需求 · AUTOSAR 4.4 中文翻译 + + + + +
+

时间服务需求（Requirements on Time Service）

+
+ 📄 文档 ID：623 + 🏷 类型：SRS（软件需求规范） + 📅 版本：AUTOSAR CP 4.4.0 + 📑 页数：13 + 📌 状态：Final + 🔗 原 PDF：AUTOSAR_SRS_TimeService.pdf +
+
+ + + +
+

目录

+ +
+ +
+ +

1 文档范围（Scope of Document）

+

本规范定义了 BSW 模块时间服务（Time Service）的需求。

+ +

约束：基础软件模块需求规范的首要范围是非安全相关的系统。对于安全相关系统中基础软件模块的实现，应当检查是否需要附加需求。

+ +

2 约定（Conventions to be used）

+

AUTOSAR 文档中的需求表示遵循 [1] 中指定的表格。在需求中，使用以下特定语义（基于 IETF RFC 2119）：

+ + +

3 功能概述（Functional Overview）

+

时间服务（Time Service）模块是服务层的一部分。该模块提供基于时间的功能服务。用例包括：

+ + +

如果硬件支持且通过配置启用，可使用多种"定时器类型"——即所谓的"时间服务预定义定时器"（Time Service Predef Timers）。

+

每个预定义定时器具有预定义的刻度时长（物理时间单位）和预定义的位数（物理范围）。由此，确保了所有支持所需时间服务预定义定时器的平台之间基于时间的功能兼容性。

+

时间服务预定义定时器基于所谓的"GPT 预定义定时器"（GPT Predef Timers），即由 GPT 驱动提供的自由运行硬件定时器。

+

所有服务都由用户轮询调用。不支持通知机制。

+

时间服务模块不使用也不分发GPT 驱动的所有功能。时间服务模块不是"定时器栈"的顶层。

+ +

4 缩略语、缩写与术语（Acronyms, abbreviations and terms）

+ + + + + + + + + +
缩略语 / 术语英文说明
GPT Predef TimerGPT Predefined Timer由 GPT 驱动提供的自由运行向上计数器。哪些 GPT Predef Timer 可用取决于硬件（时钟、硬件定时器、预分频器、定时器寄存器宽度等）和配置。GPT Predef Timer 具有预定义的物理时间单位和范围。
Time Service Predef TimerTime Service Predefined Timer具有预定义物理时间单位和范围的自由运行向上计数器。硬件定时器功能基于相应的 GPT Predef Timer。对于每个预定义定时器，时间服务模块提供一组 API 服务。用户可以实例化任意数量的定时器（仅受可用内存限制）并彼此独立使用这些实例。
Timer instance定时器实例定时器实例是 API 数据类型的数据对象。
Reference time参考时间参考时间是为每个定时器实例存储的时间值。
+ +

5 需求追溯（Requirements Tracing）

+ + + + + + + +
需求描述由以下 SRS 满足
RS_BRF_01056AUTOSAR BSW 模块应当提供标准化接口。SRS_Tm_00004、SRS_Tm_00005、SRS_Tm_00006、SRS_Tm_00007、SRS_Tm_00008
RS_BRF_01408AUTOSAR 应当提供可从每个基础软件层访问的服务层。SRS_Tm_00001、SRS_Tm_00002、SRS_Tm_00003、SRS_Tm_00004、SRS_Tm_00005、SRS_Tm_00006、SRS_Tm_00007、SRS_Tm_00008
RS_BRF_01468AUTOSAR 服务应当支持用于相对时间测量的时间服务。SRS_Tm_00001、SRS_Tm_00002、SRS_Tm_00003、SRS_Tm_00004、SRS_Tm_00005、SRS_Tm_00006、SRS_Tm_00007、SRS_Tm_00008
+ +

6 需求规范（Requirements Specification）

+ +

6.1 功能需求（Functional Requirements）

+ +

6.1.1 通用（General）

+ +
+

[SRS_Tm_00001] 时间服务模块应当支持不同类型的预定义定时器。

+ + + + + + + + + + +
类型Valid
描述时间服务模块应当支持以下类型的预定义定时器： +
    +
  • 定时器 1µs16bit
    • +
  • 定时器 1µs24bit
    • +
  • 定时器 1µs32bit
    • +
  • 定时器 100µs32bit
    • +
+
理由1µs：高分辨率定时器。
16bit 定时器：支持 16bit 硬件定时器。
24bit 定时器：支持 24bit 硬件定时器。
32bit 定时器：支持 32bit 硬件定时器。
100µs32bit 定时器：覆盖汽车用例（时间跨度 4.9 天）。
用例时间测量、基于时间的状态机、超时监控、忙等待。
依赖[SRS_BSW_00343] 时间的规范与配置
支持材料—
满足RS_BRF_01408、RS_BRF_01468
+
+ +
+

[SRS_Tm_00002] GPT 预定义定时器应当用作时间服务模块预定义定时器的时间基准。

+ + + + + + + + + + +
类型Valid
描述GPT 预定义定时器应当用作时间服务模块预定义定时器的时间基准。
理由时间服务模块必须使用驱动模块进行硬件访问。
用例读取当前定时器值。
依赖—
支持材料—
满足RS_BRF_01408、RS_BRF_01468
+
+ +

6.1.2 配置（Configuration）

+ +
+

[SRS_Tm_00003] 时间服务模块应当能够配置启用哪些预定义定时器。

+ + + + + + + + + + +
类型Valid
描述时间服务模块应当能够配置启用哪些预定义定时器。对于每个启用的预定义定时器，应当提供一组 API 服务： +
    +
  • 复位定时器
    • +
  • 获取时间跨度
    • +
  • 平移定时器
    • +
  • 同步定时器
    • +
  • 忙等待（仅 1µs 定时器）
    • +
+
理由在不需要时禁用预定义定时器，或当相关 GPT Predef Timer 不可用时。
用例—
依赖—
支持材料—
满足RS_BRF_01408、RS_BRF_01468
+
+ +

6.1.3 初始化（Initialization）

+

（无具体需求，参见 SRS_BSWGeneral 中的初始化通用需求）

+ +

6.1.4 正常运行（Normal Operation）

+ +
+

[SRS_Tm_00004] 时间服务模块应当提供一个用于复位定时器实例的同步服务。

+ + + + + + + + + + +
类型Valid
描述时间服务模块应当为每个启用的预定义定时器提供一个同步服务，用于复位定时器实例。通过此服务设置参考时间，这是后续服务所需的。该服务应当具有以下参数： +
    +
  • 指向用户定义的定时器实例的指针
    • +
+
理由基本功能。出于性能原因，每个预定义定时器都需要此服务。使用指针（而不是标识符）来引用定时器实例，以避免对时间服务模块的用户相关配置。因此，该服务可以像库服务一样灵活使用。
用例时间测量、基于时间的状态机、超时监控、忙等待。
依赖—
支持材料—
满足RS_BRF_01408、RS_BRF_01056、RS_BRF_01468
+
+ +
+

[SRS_Tm_00005] 时间服务模块应当提供一个用于获取时间跨度的同步服务。

+ + + + + + + + + + +
类型Valid
描述时间服务模块应当为每个启用的预定义定时器提供一个同步服务，用于获取时间跨度。时间跨度是参考时间与当前时刻之间的时间差。该服务应当具有以下参数： +
    +
  • 指向用户定义的定时器实例的指针
    • +
+
理由基本功能。出于性能原因，每个预定义定时器都需要此服务。使用指针（而不是标识符）来引用定时器实例，以避免对时间服务模块的用户相关配置。因此，该服务可以像库服务一样灵活使用。
用例时间测量、基于时间的状态机、超时监控、忙等待。
依赖—
支持材料—
满足RS_BRF_01408、RS_BRF_01056、RS_BRF_01468
+
+ +
+

[SRS_Tm_00006] 时间服务模块应当提供一个用于平移定时器实例参考时间的同步服务。

+ + + + + + + + + + +
类型Valid
描述时间服务模块应当为每个启用的预定义定时器提供一个同步服务，用于平移定时器实例的参考时间。平移意味着将一个时间值添加到参考时间以获得新的参考时间。该服务应当具有以下参数： +
    +
  • 指向用户定义的定时器实例的指针
    • +
  • 要添加到参考时间的时间值
    • +
+
理由扩展功能。出于性能原因，每个预定义定时器都需要此服务。使用指针（而不是标识符）来引用定时器实例，以避免对时间服务模块的用户相关配置。因此，该服务可以像库服务一样灵活使用。
用例在不损失精度的情况下测量软件可运行体的周期时间。
依赖—
支持材料—
满足RS_BRF_01408、RS_BRF_01056、RS_BRF_01468
+
+ +
+

[SRS_Tm_00007] 时间服务模块应当提供一个用于同步两个定时器实例的同步服务。

+ + + + + + + + + + +
类型Valid
描述时间服务模块应当为每个启用的预定义定时器提供一个同步服务，用于同步两个定时器实例。同步意味着将定时器实例"目标"的参考时间设置为定时器实例"源"的参考时间。该服务应当具有以下参数： +
    +
  • 指向用户定义的目标定时器实例的指针
    • +
  • 指向用户定义的源定时器实例的指针
    • +
+
理由扩展功能。出于性能原因，每个预定义定时器都需要此服务。使用指针（而不是标识符）来引用定时器实例，以避免对时间服务模块的用户相关配置。因此，该服务可以像库服务一样灵活使用。
用例测量与同一参考时间相关的不同时间戳（例如某些任务的首次调用）。
依赖—
支持材料—
满足RS_BRF_01408、RS_BRF_01056、RS_BRF_01468
+
+ +
+

[SRS_Tm_00008] 时间服务模块应当提供一个刻度时长为 1µs 的同步服务，用于通过轮询执行忙等待。

+ + + + + + + + + + +
类型Valid
描述时间服务模块应当为每个启用的预定义定时器提供刻度时长为 1µs 的同步服务，用于通过轮询执行忙等待（主动等待）。等待时间应当限制为 8 位（255µs），以防止长时间阻塞代码执行。不应当禁用中断，这意味着实际等待时间可能大于期望的等待时间。 + +该服务应当具有以下参数： +
    +
  • 最小等待时间
    • +
+
理由扩展功能。出于性能原因，每个 1µs 预定义定时器都需要此服务。该服务可以像库服务一样灵活使用。
降低用户软件层面错误实现忙等待的风险。
确保正确的等待时间，与以下因素无关： +
    +
  • CPU 速度
    • +
  • 流水线效应
    • +
  • 缓存效应
    • +
  • 内存访问时间（总线宽度、等待状态等）
    • +
  • 编译器版本、编译器选项、编译器优化
    • +
+
用例驱动的实现（硬件相关的等待时间）。
依赖—
支持材料—
满足RS_BRF_01408、RS_BRF_01056、RS_BRF_01468
+
+ +

7 参考资料（References）

+ +

7.1 AUTOSAR 交付物

+ + +
+ +
+

📋 校对记录

+

校对轮次：L1 自动校对（2026-06-13）

+ +
+ + + + + \ No newline at end of file diff --git a/translation_zh-CN/P1_SystemServices/AUTOSAR_TR_HWTestManagementIntegrationGuide.html b/translation_zh-CN/P1_SystemServices/AUTOSAR_TR_HWTestManagementIntegrationGuide.html new file mode 100644 index 0000000..e12df66 --- /dev/null +++ b/translation_zh-CN/P1_SystemServices/AUTOSAR_TR_HWTestManagementIntegrationGuide.html @@ -0,0 +1,424 @@ + + + + +硬件测试管理启动与关闭规范与集成 · AUTOSAR 4.4 中文翻译 + + + + +
+

硬件测试管理启动与关闭规范与集成（Specification and Integration of Hardware Test Management at start up and shutdown）

+
+ 📄 文档 ID：804 + 🏷 类型：TR（技术报告） + 📅 版本：AUTOSAR CP 4.4.0 + 📑 页数：15 + 📌 状态：Final + 🔗 原 PDF：AUTOSAR_TR_HWTestManagementIntegrationGuide.pdf +
+
+ + + +
+

目录

+ +
+ +
+ +

1 文档范围（Scope of this document）

+

本文档简要介绍了硬件测试管理（Hardware Test Management）概念在标准 AUTOSAR 软件平台中的集成。它可作为那些希望按照 AUTOSAR 方法和过程实现硬件测试管理启动与关闭模块（作为 AUTOSAR BSW 模块）的人员的用户指南。

+ +

HTMSS 模块本身的需求在 HTMSS SRS 和 SWS 文档中描述。

+ +

本文档主要内容：

+ + +

1.1 限制（Limitations）

+

无。

+ +

2 目标（Objective）

+

每个 ECU 设计为在给定系统架构的上下文中提供预定义的功能。因此，ECU无故障运行极为重要，这可以通过简单监控预期故障来避免或在故障出现前检测到。监控 ECU 可操作性的一种策略是执行检查给定逻辑和条件的测试，并保存结果供进一步分析。

+ +

HTMSS 概念描述了应对此类测试结果的需求，并按需提供其状态。

+ +

该测试和监控活动集应当提供所需的诊断覆盖范围（针对潜在故障），以满足 ISO 26262 第 5 部分第 8 章对硬件架构指标的要求。

+ +
+ 图 1：安全状态的维护 + 
+  故障发生 ──→ 故障检测（预设时间）──→ 通知软件组件
+                                                 │
+                                                 ▼
+                                          反故障反应
+                                                 │
+                                                 ▼
+                                          维持安全状态
+
+
+ +

测试和监控设施的目标是保证在预定义时间间隔内执行故障检测（参见图 1）。故障检测后，相关的软件组件应当采取必要的行动；应用反故障反应以维持安全状态。

+ +

本文档提供了在标准 AUTOSAR 环境中集成启动与关闭测试的通用用例和需求。

+ +

3 目的（Goal）

+

在基于 AUTOSAR 的系统开发期间，应当考虑一种技术方法，用于在标准 AUTOSAR 中集成半导体厂商特定的测试。

+

目标是标准化可访问的接口，使用微控制器特定测试包（可能是非 AUTOSAR 软件模块），并集成到 AUTOSAR 系统中，该系统配置测试、触发测试执行并收集测试结果。因此，本概念引入了一个名为 HTMSS 的 BSW 模块来实现其功能。

+ +

4 动机（Motivation）

+

HTMSS 概念的动机是支持系统对给定功能可信性的感知。例如，资源可用、处于操作条件下且未检测到故障。即使检测到某些故障，系统仍可能能够执行某些活动并信任其结果。系统对这些故障的反应确定性必须基于系统分析和推荐实现。HTMSS 概念应当提供支持以实现此感知。收集多个测试的结果可以提供系统资源条件和方面的实际情况。

+ +

该概念应当满足以下需求：

+ + +

5 用例（Use Case）

+

在安全关键系统的上下文中，对潜在故障的诊断对于实现功能安全目标至关重要。它需要集成测试、执行和结果传播，与预期功能并行。这意味着有必要在系统服务层引入一个新组件——一个名为硬件测试管理器（HTMSS）的基础软件模块。它实现测试和监控编排，并将结果传播给利益相关者软件组件。

+ +
+ 图 2：硬件测试管理器 — 用例概念 + 
+  MSTP (µC Hardware BIST / µC Safety Library)
+      │
+      ▼
+  HTMSS ────→ Safety SW-C ──→ Functional Degradation/Limp Home
+      │
+      ▼
+  Custom Integrator Code
+  
+  隐式故障报告：
+  - MCU 复位 / AUTOSAR 未启动
+  - 由于关键故障，AUTOSAR 在 HTM 初始化前停止
+
+
+ +

硬件测试应当与整体系统行为协调执行。它们不应负面影响预期功能。这是对需要执行的测试点进行精确选择的原因。通常测试分为两个基本组：

+ + +

系统中的故障影响需要考虑。一些故障（通用核故障、RAM 测试故障），此处称为关键故障，会使系统启动变得无意义。相反，MCU 可以保持在持续复位状态，或另一种静默模式，禁止其启动。所有其他检测到的故障由负责维护安全状态的相应应用软件组件识别。

+ +

诊断测试执行不应在 MCAL 的 Init() 函数中执行，它们应当在 Init() 函数执行之前执行：

+ + +

6 约束与假设（Constraints and assumptions）

+

HTMSS 目标是为收集和报告特定硬件模块或外设的运行状态提供必要的环境和基础设施。运行状态是对这些硬件模块和外设测试评估的结果。基本上，根据其对系统/微控制器的影响，这些阶段执行两种类型的测试：破坏性和非破坏性。

+ +

该概念要求使用的微控制器具有在执行破坏性测试期间在专用内存地址/寄存器中维护测试结果完整性的能力。测试结果可供 HTMSS 访问。在硬件模块发生严重故障（核或 RAM/ROM 故障）的情况下，通过 MSTP 检测，可以决定不继续执行后续软件。在这种情况下，系统必须进入安全状态。持续复位被视为安全状态。MSTP 负责维护安全状态。MSTP 设计和实现由微控制器供应商提供。

+ +

计划在 AUTOSAR 初始化中执行的测试可以由微控制器供应商（微控制器特定测试）或系统集成商设计和实现（ECU 功能特定测试）。它们由 HTMSS 自身进行编排和评估。

+ +

7 缩略语与缩写（Acronyms and abbreviations）

+ + + + + + + + + + +
缩略语说明
HTMSSHardware Tests Management Start up and Shutdown（硬件测试管理启动与关闭）
DEMDiagnostic Event Manager（诊断事件管理器）
ECUElectronic Control Unit（电子控制单元）
BISTBuilt-In Self Tests（内建自检）
CDDComplex Device Driver（复杂设备驱动）
MSTPMicrocontroller Specific Test Package（微控制器特定测试包）
+ +

8 相关文档（Related Documents）

+ + +

在实现 HTMSS 和受影响模块中的相关扩展需求以保证 AUTOSAR 软件平台兼容性时，应当考虑其他 AUTOSAR 通用规范。

+ +

9 HTMSS AUTOSAR 集成方法（HTMSS AUTOSAR integration approach）

+

硬件测试管理启动与关闭提出了在 AUTOSAR 软件环境中集成微控制器特定测试包（MSTP）的方案。标准 AUTOSAR 模块与 MSTP 之间的交互通过在 BSW 服务层中引入新模块 HTMSS 来管理。

+ +

HTMSS 的基本功能：

+ + +

为实现功能集成，需要扩展某些 AUTOSAR 标准模块，特别是 ECU 状态管理器的 UP 阶段和 DOWN 阶段。

+ +

10 HTMSS 特性描述（HTMSS Feature Description）

+ +
+

[FS_HTMSS_00001] AUTOSAR 应当提供一种标准化的安全机制来集成微控制器特定的硬件测试。

+ + + + + + + + + +
类型Draft
描述AUTOSAR 应当提供一种机制，用于收集启动与关闭阶段执行的微控制器特定测试、评估测试状态并将其提供给利益相关者 SW-C。
理由硬件测试的失败可能导致进入安全状态。
用例例如，关键硬件资源测试确定 MCU 的健康状况。
依赖无
支持材料无
+
+ +

11 AUTOSAR 架构解决方案（AUTOSAR Architecture solution）

+

启动与关闭的硬件测试管理集成需要功能扩展几个 BSW 模块，并在 BSW 层中引入新模块 HTMSS。

+ +

新模块 HTMSS 应当满足以下功能需求：

+ + +

HTMSS 与 MSTP 之间的接口应当是厂商特定的，可以通过 AUTOSAR 开发过程中实现的 MSTP wrapper 处理。

+ +
+ 图 4：HTMSS 在 AUTOSAR 架构中的概览 + 
+  ┌─────────────────────────────────┐
+  │       应用层 SW-C              │
+  ├─────────────────────────────────┤
+  │             RTE                  │
+  ├─────────────────────────────────┤
+  │  Services                       │
+  │  ┌─────┐  ┌────┐  ┌──────┐    │
+  │  │EcuM │  │BswM│  │ HTMSS│◄──┼─→ MSTP（厂商特定）
+  │  └─────┘  └────┘  └──────┘    │
+  ├─────────────────────────────────┤
+  │  ECU Abstraction                │
+  ├─────────────────────────────────┤
+  │  MCAL（MCU 驱动等）           │
+  └─────────────────────────────────┘
+            ▼
+        硬件
+
+
+ +

12 AUTOSAR 软件架构中的集成需求（Integration requirements in AUTOSAR SW architecture）

+

本节描述了为在标准 AUTOSAR 模块中集成 HTMSS 模块和相应的微控制器特定测试包，必须在受影响的 AUTOSAR 模块中实现的基本需求。

+ +

在此上下文中受影响的 AUTOSAR 模块：

+ + +

12.1 ECU 状态管理器（ECU state manager）

+

EcuM 模块需要按以下方式扩展以将 HTMSS 纳入 AUTOSAR 软件环境：

+ +

扩展需要满足以下建议的功能集成方法：

+ + +

EcuM 的详细需求在以下小节中描述。

+ +

12.1.1 通用需求（General requirements）

+ +
+

[SWS_EcuM_04136_EXTENSION]

+

EcuM_ShutdownTargetType 应当扩展 ECUM_SHUTDOWN_HWTEST_RESET 和 ECUM_SHUTDOWN_HWTEST_OFF，以处理由关闭测试执行引起的复位。

+ + + + + + + + + + + + +
名称EcuM_ShutdownTargetType
类型uint8
取值范围ECUM_SHUTDOWN_TARGET_SLEEP 0x0
ECUM_SHUTDOWN_TARGET_RESET 0x1
ECUM_SHUTDOWN_TARGET_OFF 0x2
ECUM_SHUTDOWN_HWTEST_RESET 0x3
ECUM_SHUTDOWN_HWTEST_OFF 0x4
描述—
+
+ +

12.1.2 在 EcuM 启动阶段（During EcuM START UP PHASE）

+ +
+

[SWS_EcuM_HTMSS_00001]

+

在 Init block 1 中，EcuM 应当调用 HTMSS_Init() 来初始化 HTMSS 模块。（参考：HTMSS SWS 第 9.1.1 节）

+
+ +
+

[SWS_EcuM_HTMSS_00002]

+

ECU 管理器模块应当调用 HTMSS_StartTest() 来触发 MSTP 启动测试执行，基于 Mcu_GetResetReason API 的返回值。（参考：HTMSS SWS 第 9.1.2 节）

+
+ +
+

[SWS_EcuM_HTMSS_00003]

+

ECU 管理器模块应当调用 HTMSS_GetTestStatus() 来收集 MSTP 启动测试结果或关闭测试结果，基于 Mcu_GetResetReason API 的返回值。（参考：HTMSS SWS 第 9.1.2 节和 9.1.5 节）

+
+ +
+

[SWS_EcuM_HTMSS_00004]

+

ECU 管理器模块应当在 HTMSS_GetTestStatus() 返回 HTMSS_STATUS_NOK 时调用 HTMSS_StartupTestErrorHook()。（参考：HTMSS SWS 第 9.1.2 节）

+
+ +

12.1.3 在 EcuM 关闭阶段（During EcuM SHUTDOWN PHASE）

+ +
+

[SWS_EcuM_HTMSS_00005]

+

ECU 管理器模块应当调用 HTMSS_StartTest 服务函数，基于 EcuM_ShutdownTarget 触发 MSTP 关闭测试执行。（参考：HTMSS SWS 第 9.1.3 节）

+
+ +
+

[SWS_EcuM_HTMSS_00006]

+

ECU 管理器模块应当基于 Mcu_ResetType 调用 HTMSS_GetTestStatus()。（参考：HTMSS SWS 第 9.1.4 节和 9.1.5 节）

+

提示：通常关闭测试执行会导致硬件复位。复位后，在 EcuM_Init 中，EcuM 将调用 Mcu_GetReason()。如果复位原因是 MCU_HWTEST_RESET，则 EcuM 应当调用 HTMSS_GetTestStatus() 来收集关闭测试结果。

+
+ +
+

[SWS_EcuM_HTMSS_00007]

+

ECU 管理器模块应当在 HTMSS_GetTestStatus() 返回 HTMSS_STATUS_NOK 时调用 HTMSS_ShutdownTestErrorHook()。（参考：HTMSS SWS 第 9.1.5 节）

+
+ +

12.1.4 HTMSS 集成到 EcuM 的示例时序图（Example sequence diagrams for HTMSS integration in ECUM）

+

以下序列图应当作为将 HTMSS 集成到 EcuM UP 和 DOWN 阶段的参考。

+ +
+

[SWS_EcuM_HTMSS_00008]

+

关于在 EcuM 中集成 HTMSS init 函数，请参考：AUTOSAR_SWS_HWTestManager 第 9.1.1 节。

+
+ +
+

[SWS_EcuM_HTMSS_00009]

+

关于在 EcuM 中集成 HTMSS 启动测试，请参考：AUTOSAR_SWS_HWTestManager 第 9.1.2 节。

+
+ +
+

[SWS_EcuM_HTMSS_00010]

+

关于在 EcuM 中集成 HTMSS 关闭测试执行，请参考：AUTOSAR_SWS_HWTestManager 第 9.1.3 节。

+
+ +
+

[SWS_EcuM_HTMSS_00011]

+

关于为应用收集最后的关闭测试结果，请参考：AUTOSAR_SWS_HWTestManager 第 9.1.4 节和 9.1.5 节。

+
+ +
+

[SWS_EcuM_HTMSS_00012]

+

关于在 EcuM 关闭阶段集成关闭测试执行，请参考：AUTOSAR_SWS_HWTestManager 第 9.1.6 节。

+
+ +

12.2 BSW 模式管理器（BSW mode manager）

+

BswMEcuMSelectShutdownTarget 应当扩展 HWTEST_OFF 和 HWTEST_RESET，以处理由关闭测试执行引起的复位。

+ +
+

ECUC_BswM_00993_EXTENSION

+ + + + + + + + + + + + + + +
名称BswMEcuMShutdownTarget
描述此参数包含 BswM 在 EcuM 处选择的关闭目标。
多重性1
类型EcucEnumerationParamDef
取值OFF
RESET：若配置为 RESET，则 BswMEcuMResetModeRef 参数应当存在并包含对 EcuM 复位模式的有效引用。
SLEEP：若配置为 SLEEP，则 BswMEcuMSleepModeRef 参数应当存在并包含对 EcuM 睡眠模式的有效引用。
HWTEST_OFF：若配置为 HWTEST_OFF，则 BswMEcuMSleepModeRef 参数应当存在并包含对 EcuM 关闭硬件测试 OFF 模式的有效引用。
HWTEST_RESET：若配置为 HWTEST_RESET，则 BswMEcuMSleepModeRef 参数应当存在并包含对 EcuM 关闭硬件测试 RESET 模式的有效引用。
配置类Pre-compile time、Link time、Post-build time
范围/依赖scope: local
+
+ +

12.3 MCU 驱动（MCU driver）

+ +
+

SWS_Mcu_00252_EXTENSION

+

Mcu_ResetType 应当扩展 MCU_HWTEST_RESET，以处理由关闭测试执行引起的复位。

+ + + + + + + + + + + + +
名称Mcu_ResetType
类型Enumeration
取值MCU_POWER_ON_RESET：上电复位（默认）。
MCU_WATCHDOG_RESET：内部看门狗定时器复位。
MCU_SW_RESET：软件复位。
MCU_HWTEST_RESET：由关闭测试引起的复位。
MCU_RESET_UNDEFINED：复位未定义。
描述这是包含复位类型子集的复位枚举器类型。不要求硬件支持所有复位类型。
+
+ +

13 对 AUTOSAR 性能和软件行为的影响（Impact on performance and software behaviour in AUTOSAR）

+

HTMSS 集成到 AUTOSAR 中会影响 ECU 中的 EcuM 启动和关闭行为。其后果包括：

+ + +

因此，集成商可以自主决定 AUTOSAR 中的 HTMSS 集成需求，该需求作为符合 AUTOSAR 软件环境的可选特性提出。

+ +
+ +
+

📋 校对记录

+

校对轮次：L1 自动校对（2026-06-13）

+ +
+ + + + + \ No newline at end of file diff --git a/translation_zh-CN/logs/proofread_log.jsonl b/translation_zh-CN/logs/proofread_log.jsonl index cedce1e..9d1de64 100644 --- a/translation_zh-CN/logs/proofread_log.jsonl +++ b/translation_zh-CN/logs/proofread_log.jsonl @@ -19,4 +19,7 @@ {"timestamp": "2026-06-13T00:18:00Z", "stage": "P0", "module": "General", "document": "AUTOSAR_TR_AIMeasurementCalibrationDiagnostics", "pages": 59, "result": "L1_pass", "issues": [], "notes": "FlatMap 机制与 P/L-List 完整"} {"timestamp": "2026-06-13T00:19:00Z", "stage": "P0", "module": "General", "document": "AUTOSAR_TR_SWCModelingGuide", "pages": 57, "result": "L1_pass", "issues": [], "notes": "SWC 建模指南完整"} {"timestamp": "2026-06-13T00:20:00Z", "stage": "P0", "module": "General", "document": "AUTOSAR_EXP_VFB", "pages": 104, "result": "L1_pass", "issues": [], "notes": "VFB 概念、通信机制、模式管理完整"} -{"timestamp": "2026-06-13T00:21:00Z", "stage": "P0", "module": "General", "document": "AUTOSAR_EXP_LayeredSoftwareArchitecture", "pages": 104, "result": "L1_pass", "issues": [], "notes": "AUTOSAR 分层架构完整（P0 阶段核心文档）"} \ No newline at end of file +{"timestamp": "2026-06-13T00:21:00Z", "stage": "P0", "module": "General", "document": "AUTOSAR_EXP_LayeredSoftwareArchitecture", "pages": 104, "result": "L1_pass", "issues": [], "notes": "AUTOSAR 分层架构完整（P0 阶段核心文档）"}{"timestamp": "2026-06-13T14:00:00Z", "stage": "P1", "module": "SystemServices", "document": "AUTOSAR_SRS_HWTestManager", "pages": 12, "result": "L1_pass"} +{"timestamp": "2026-06-13T14:01:00Z", "stage": "P1", "module": "SystemServices", "document": "AUTOSAR_SRS_TimeService", "pages": 13, "result": "L1_pass"} +{"timestamp": "2026-06-13T14:02:00Z", "stage": "P1", "module": "SystemServices", "document": "AUTOSAR_TR_HWTestManagementIntegrationGuide", "pages": 15, "result": "L1_pass"} +{"timestamp": "2026-06-13T14:03:00Z", "stage": "P1", "module": "SystemServices", "document": "AUTOSAR_SRS_FreeRunningTimer", "pages": 19, "result": "L1_pass"}