SW Architectural Decisions
1. 简介和功能概述¶
本说明文档为 AUTOSAR 标准所作的架构决策提供附加信息。
1.1. 目标¶
本文档的主要目标是为 AUTOSAR 标准所作的架构决策提供文档化，使这些决策在未来可被理解、可被评审，并最终使标准更易维护。
1.2. 范围¶
本文档涵盖为 AUTOSAR 标准的软件架构所作的决策。本文档的主要读者是 AUTOSAR 标准的架构师以及其他工作组的成员。
2. 定义和缩略语¶
2.1. 缩略语¶
API
应用编程接口（Application Programming Interface）
STL
标准模板库（Standard Template Library）
2.2. 术语定义¶
Adaptive Application
Execution Management
AUTOSAR 自适应平台中的一个功能簇。概览参见 [2, EXP_SWArchitecture]。
Functional Cluster
参见 [1, AUTOSAR Glossary]。[2, EXP_SWArchitecture] 给出了 AUTOSAR 自适应平台中所有功能簇的概览。
Platform Health Management
AUTOSAR 自适应平台中的一个功能簇。概览参见 [2, EXP_SWArchitecture]。
Process
State Management
AUTOSAR 自适应平台中的一个功能簇。概览参见 [2, EXP_SWArchitecture]。
Software Cluster
Thread
Watchdog
监督 AUTOSAR 自适应平台执行的外部组件。概览参见 [2, EXP_SWArchitecture]。
3. 相关文档¶
本文档概述为 AUTOSAR 标准所作的架构决策及其依据。AUTOSAR 标准架构的高层概览见 [3, EXP_LayeredSoftwareArchitecture]（AUTOSAR 经典平台）与 [2, EXP_SWArchitecture]（AUTOSAR 自适应平台）。
4. 概述¶
本章概述本文档所列决策的组织与结构。所有决策均以表的形式构造（模板见表 4.1）。架构决策按其适用的平台分节组织。
表4.1：架构决策模板（Template for Architectural Decisions）
| 字段 | 内容 |
|---|---|
| 适用平台（Applies to） | 本架构决策所适用的 AUTOSAR 平台清单。 |
| 决策（Decision） | 决策本身。决策的影响或直接后果（例如接口变更）不作记录。规范中的变更在决策作出后的推广过程中实施。 |
| 依据（Rationale） | 决策的依据。 |
| 类别（Category） | 决策的类别。 |
| 是否影响应用（Application affected） | 说明该决策是否对既有应用有直接影响。 |
| 假设（Assumptions） | 列出在作出决策之前所作的假设。记录这些假设是为了将来能够评审决策，并检查某些假设可能已不再成立。 |
| 约束（Constraints） | 概述已识别出的、对可能解决方案有影响的约束。记录这些约束也是为了作为未来评审决策的参照点。 |
| 备选方案（Alternatives） | 列出曾被考虑的备选方案，以及它们为何劣于已作出的决策。 |
| 备注（Remarks） | 列出关于决策的备注。 |
| 相关需求（Related requirements） | 列出与决策相关的需求。 |
| 发布（Release） | 首次包含所记录决策的 AUTOSAR 发布。 |
5. 架构决策¶
5.1. 通用决策¶
本章列出为 AUTOSAR 自适应平台与经典平台所作的架构决策。
5.1.1. PRS 文档变更对 AP 与 CP 的影响¶
| 字段 | 内容 |
|---|---|
| 适用平台 | AP、CP |
| 决策 | 如果 AUTOSAR 应支持多个协议版本，则它们应在同一发布的一个 PRS 文档中标准化。每个平台可以自行定义支持的程度。记录不同支持程度的一种方法是使用 SWS 的第 4 章来描述限制。（备选方案 3） |
| 依据 | 我们看到在不同的平台上使用不同协议版本的用例，例如 AP 可能同时支持"旧"版本与"新"版本，而 CP 只支持"旧"版本。同一协议版本的协议"特性"也是如此。 |
| 类别 | 无 |
| 是否影响应用 | 无 |
| 假设 | 未作假设。 |
| 约束 | AUTOSAR 遵循基于主干（trunk-based）的开发方式，没有任何缺陷修复分支。这意味着当前的 PRS 文档版本直接替代较旧的版本，不维护较旧的 PRS 文档版本。 |
| 备选方案 | 允许引用较旧的 AUTOSAR 发布——像 DLT v2 示例那样允许引用较旧的 AUTOSAR 发布。 |
| 备选方案 | 在同一 AUTOSAR 发布中支持多个版本——在同一 AUTOSAR 发布中支持一个 PRS 文档的多个版本。引入"变体感知"的可追溯性来表达 AP 与 CP 不同的支持程度。 |
| 备选方案 | 在单个文档中支持多个版本——如果 AUTOSAR 应支持多个协议版本，则它们应在同一发布的一个 PRS 文档中标准化。每个平台可以自行定义支持的程度。记录不同支持程度的一种方法是使用 SWS 的第 4 章来描述限制。 |
| 备选方案 | 在同一 AUTOSAR 发布中只支持一个版本——避免任何歧义，在一个 AUTOSAR 发布内只允许 AP 与 CP 都支持的一个 PRS 版本。 |
| 备注 | 无备注。 |
| 相关需求 | 无 |
| 发布 | R22-11 |
5.2. 自适应平台¶
本节列出仅为 AUTOSAR 自适应平台所作的架构决策。
5.2.1. 动态内存分配（Dynamic memory allocation）¶
| 字段 | 内容 |
|---|---|
| 适用平台 | AP |
| 决策 | 在设计 AUTOSAR 自适应平台标准时，允许并假定自适应应用和功能簇使用动态内存分配。 |
| 依据 | 由于 AUTOSAR 自适应平台标准采用 C++ 作为其 API 语言，动态内存分配的使用实际上是不可或缺的。由于 AUTOSAR 自适应平台标准将用于安全相关系统，动态内存分配可能导致非确定性行为。两个典型问题是碎片化以及不确定的分配/释放处理时间。为非安全关键系统设计的内存分配器常常表现出这些问题，因为它们在或多或少的程度上是为内存效率和/或平均处理性能设计的。这些问题可以通过使用确定性内存分配器来控制。内存分配是一个被充分研究的领域，已有多种技术被报道（一些例子见下文参考文献）。据报告，架构组内的多个 AUTOSAR 合作伙伴已经实现了此类确定性内存分配器，并将其用于量产系统。注意，此类分配器应替换标准 C 库提供的默认 malloc()/free() 实现——标准 C 库位于提供 new()/delete() 的 C++ 运行时库以及 AUTOSAR 自适应平台同样使用的 STL 之下。这使应用无需提供自己的自定义确定性分配器并将其安装到感知自定义分配器的类中。关于实时系统中内存碎片与内存分配的更多信息，请参见 [4]、[5]、[6] 和 [7]。 |
| 类别 | 安全（Safety） |
| 是否影响应用 | 否 |
| 假设 | 平台供应商和/或编译器供应商可以替换默认的内存分配/释放函数，以便在运行期的关键阶段——即出于安全目的需要这种确定性的阶段——使用这些函数的确定性版本。 |
| 约束 | 在运行期的某些阶段需要确定性。这些阶段正是需要将分配器替换为确定性版本的阶段。 |
| 备选方案 | 不使用动态内存分配——对于使用 C++ 而言，不使用动态内存分配不是一个备选项。 |
| 备选方案 | 将动态内存分配限制到特定阶段——在运行期中需要确定性的特定阶段禁止动态内存分配。这将使得在这些阶段运行复杂代码非常困难。 |
| 备注 | 无备注。 |
| 相关需求 | • [RS_AP_00129] 功能簇定义的公共类型应被设计为无需动态内存分配即可实现 |
| 发布 | R20-11 |
5.2.2. 自适应运行时定义的类型应为 final（Types defined in the Adaptive Runtime for Applications should be final）¶
| 字段 | 内容 |
|---|---|
| 适用平台 | AP |
| 决策 | 自适应运行时类型应使用 final 说明符，除非它们意在用作基类。 |
| 依据 | 将不打算用作基类的类声明为 final，可以更明确地表达设计（特别是类的层次结构）。这可以避免诸如以下问题：• 从一个未为派生子类做准备的类派生；• 由于签名稍有不同，无意中创建了新的虚函数而不是覆盖基类的函数。 |
| 类别 | 无 |
| 是否影响应用 | 否 |
| 假设 | 清晰地表达 AUTOSAR Runtime for Adaptive Applications 公共类层次的预期设计。 |
| 约束 | 未识别出约束。 |
| 备选方案 | 通过代码评审确保正确使用 AUTOSAR 类型——该备选方案是对使用 AUTOSAR 类型的应用代码进行代码评审。这完全超出 AUTOSAR 的范围，因此不是一个真正的备选项。 |
| 备注 | 无备注。 |
| 相关需求 | • [RS_AP_00140] 在 ara 类型中使用"final 说明符" |
| 发布 | R20-11 |
5.2.3. out 参数的使用（Usage of out parameters）¶
| 字段 | 内容 |
|---|---|
| 适用平台 | AP |
| 决策 | out 参数可用于就地修改，但不得用于返回值。 |
| 依据 | 统一的外观与感受。C++ 核心指南 [8]："F.20：对于'out'输出值，优先使用返回值而不是输出参数。[...] 返回值是自说明的，而引用 & 既可能是输入输出也可能是仅输出，容易被误用。这包括像标准容器这样使用隐式移动操作以提升性能并避免显式内存管理的大型对象。" |
| 类别 | 无 |
| 是否影响应用 | 否 |
| 假设 | 在所有使用 API 的情形下都允许动态内存分配，即使运行时间关键的安全相关代码（包括 ASIL D）时也是如此。 |
| 约束 | 输入/输出参数（即在函数内修改一个已存在的参数）是允许的。例如，清除或写入缓冲区的函数应将该缓冲区作为非 const 的输入/输出参数接收。 |
| 备选方案 | 未考虑任何备选方案。 |
| 备注 | 无备注。 |
| 相关需求 | • [RS_AP_00141] out 参数的使用 |
| 发布 | R20-11 |
5.2.4. 使用命名构造函数实现无异常对象创建（Usage of named constructors for exception-less object creation）¶
| 字段 | 内容 |
|---|---|
| 适用平台 | AP |
| 决策 | 返回 ara::core::Result 的无异常对象创建函数应使用"命名构造函数惯用法"（named constructor idiom）。 |
| 依据 | • 构造函数记号（token）类型是类的一个实现细节，因此不应被规定，甚至不应从外部访问。这使得必须使用 auto 来获取记号，因为记号类型无法以任何其他方式引用。• 必须非常小心地将记号的内容移动到 SomeClass 实例以满足"总是成功"的保证，如果需要获取多个资源，这可能很棘手。• 记号对象通过将其值 std::move 到 SomeClass 构造函数而"销毁"（实际上，按照 C++ 标准，它将处于一个"有效"但未指定的状态），但很容易误将它再次用于尝试创建另一个实例，导致未定义的结果。 |
| 类别 | 安全（Safety） |
| 是否影响应用 | 是 |
| 假设 | 未作假设。 |
| 约束 | 未识别出约束。 |
| 备选方案 | 构造函数记号方法——由于本决策依据中所述的缺点，未予考虑。 |
| 备选方案 | 常规构造函数调用——未予考虑，因为常规构造函数可能抛出异常，因而无法在无异常设计中使用。 |
| 备注 | 无备注。 |
| 相关需求 | 无相关需求。 |
| 发布 | R20-11 |
5.2.5. 引入单调时钟 API（Introduction of a monotonic clock API）¶
| 字段 | 内容 |
|---|---|
| 适用平台 | AP |
| 决策 | AUTOSAR Runtime for Adaptive Applications 应提供自己的单调的 std::chrono::SteadyClock，表示机器的上电时间。该时钟的精度由平台供应商定义。该时钟的精度可以用作平台的特征值，使项目能够检查该时钟是否满足项目特定的需求（例如时间同步通常需要精度更高的时钟）。机器的系统启动定义了该时钟的纪元，因此该时钟表示机器的上电时间。处理时间戳或时钟的功能簇应以该时钟为基础。 |
| 依据 | 时间同步簇使用的时间戳应基于 std::chrono。时间同步需要一个具有特殊精度的单调时钟。 |
| 类别 | 无 |
| 是否影响应用 | 是 |
| 假设 | 由于时间同步报文只有一个通信端点，时间同步簇通常是基于守护进程（daemon）的架构。需要一个具有特殊精度的标准化时钟作为公共基础，以同步守护进程与库。 |
| 约束 | 未识别出约束。 |
| 备选方案 | 将时钟类型作为模板实参传递——所使用的时钟也可以作为模板实参传递。但在时间同步簇基于守护进程的情况下，无论如何都需要一个具有特殊精度的标准化时钟作为公共基础。 |
| 备注 | 单调时钟 API 通过 ara::core::SteadyClock 实现。 |
| 相关需求 | • [RS_AP_00130] AUTOSAR 自适应平台应表现一个丰富而现代的编程环境。 |
| 发布 | R20-11 |
5.2.6. State Management、Execution Management 与 Platform Health Management 的职责（Responsibilities of State Management, Execution Management, and Platform Health Management）¶
| 字段 | 内容 |
|---|---|
| 适用平台 | AP |
| 决策 | State Management、Execution Management 与 Platform Health Management 是 AUTOSAR 自适应平台的基础。State Management、Platform Health Management 或 Execution Management 进程中的故障通常会典型地导致停止触发看门狗（watchdog）。Platform Health Management 监督 State Management 与 Execution Management。Platform Health Management 控制看门狗，因而反过来受硬件看门狗的监督。在自适应应用监督失败（即 Operating System/Execution Management/State Management/Platform Health Management 之外）的情况下，作为最后手段触发机器复位根本不应是一个选项。自适应应用中的监督失败应报告给 State Management。State Management 可以根据严重性将该失败转发给 Platform Health Management，以错误地触发或停止触发其服务的看门狗。Platform Health Management 对进程内或同一功能组内进程之间的检查点执行逻辑监督。Platform Health Management 向 State Management 报告任何监督失败。State Management 负责执行恢复动作，包括通过委托给自适应应用来切换功能组状态（Function Group State），或作为最后手段建议 Platform Health Management 执行硬件复位。Platform Health Management 用于监督安全关键进程。因此，对于非安全关键应用，Platform Health Management 是 AUTOSAR 自适应平台的可选部分。进程绝不应自行重启，因为它们可能具有未知的运行时依赖。进程与功能组之间的关系可以比作线程与进程之间的关系。即使在简单的/无依赖的情形下，State Management 也应始终触发一个请求（功能组状态变更）以重启进程。因此，Platform Health Management 与 Execution Management 之间没有直接接口。应移除 Platform Health Management 的不可恢复状态接口。 |
| 依据 | 所选方案使 Platform Health Management 的设计更简单，具有单一且明确定义的职责。所选方案同样遵循 State Management（控制系统状态）与 Execution Management（控制进程）的单一职责原则。恢复动作可以通过扩展（开闭原则）添加到 State Management。无需修改或配置 Platform Health Management。如果 State Management 选择将恢复委托给自适应应用，监督失败也可以由自适应应用处理。 |
| 类别 | 安全（Safety） |
| 是否影响应用 | 是 |
| 假设 | • State Management 是 AUTOSAR 自适应平台的必备部分。• 相对于执行合理的恢复动作（例如启动进程），经由 State Management 向自适应应用间接报告监督失败的性能影响/延迟可以忽略不计。 |
| 约束 | 未识别出约束。 |
| 备选方案 | 由 Platform Health Management 协调故障恢复——系统性故障的恢复由 Platform Health Management 协调。根据优先级涉及多个组件（自适应应用、Execution Management、State Management、看门狗）。Platform Health Management 按以下方式协调恢复：1. Platform Health Management 请求自适应应用恢复 2. 若失败，Platform Health Management 请求 Execution Management 重启失败的进程 3. 若失败，Platform Health Management 请求 State Management 通过切换功能组状态来恢复 4. 若失败，Platform Health Management 停止触发看门狗并复位机器 5. 若失败，Platform Health Management 切换到不可恢复状态（尚未完全定义）。由于多个组件对恢复动作负责、不符合单一职责原则，未考虑该备选方案。该方案还要求 Platform Health Management 具备应用知识，因为它必须在第 3 步确定适当的功能组状态。由于运行时依赖，重启单个进程可能并不合适（第 2 步）。 |
| 备选方案 | 分布式故障恢复——系统性故障的恢复由 Platform Health Management 与 State Management 协调。根据优先级涉及多个组件（自适应应用、Execution Management、看门狗）。Platform Health Management 与 State Management 按以下方式协调恢复：1. Platform Health Management 请求自适应应用恢复 2. 若失败，Platform Health Management 请求 State Management 通过重启应用来协调恢复 3. State Management 请求 Execution Management 变更状态/切换到降级状态或安全状态 4. 若失败，State Management 请求自适应应用恢复 5. 若第 2 步因应用依赖而失败，Platform Health Management 停止触发看门狗并复位机器。由于 Platform Health Management 与 State Management 共同承担协调恢复动作的职责、不符合单一职责原则，未考虑该备选方案。 |
| 备注 | • 按照 ISO 26262，必须确保在发生安全相关故障之后触发反应。因此，即使 Platform Health Management 与 State Management 通过不可靠的通信信道（例如进程间通信机制）通信，Platform Health Management 也应确保 State Management 收到关于所检测故障的通知。为此，Platform Health Management 应实现超时监控。如果在可配置的超时时间和尝试次数之后仍未收到 State Management 的响应，Platform Health Management 应通过硬件看门狗（Watchdog）触发反应。• 对于 AUTOSAR 自适应平台的 R19-11 发布，Platform Health Management 的配置包括监控（PhmSupervision）、仲裁与恢复动作的规则。随着本决策，Platform Health Management 只负责监控。监控规则（PhmSupervision）不受影响。但仲裁与恢复动作的职责移交给 State Management。在当前设计中，State Management 是只有少量配置的项目特定的、以代码实现的软件。应扩展 State Management 的配置以支持仲裁与恢复动作。这将允许基于标准化规则验证此类配置——这在源代码级别极难实现。 |
| 相关需求 | 无相关需求。 |
| 发布 | R20-11 |
5.2.7. 使用本地代理对象实现对对象的共享访问（Use of local proxy objects for shared access to objects）¶
| 字段 | 内容 |
|---|---|
| 适用平台 | AP |
| 决策 | 应使用本地代理对象（local proxy object）经由 AUTOSAR Runtime for Adaptive Applications 接口提供对对象实例的共享访问。 |
| 依据 | 本地代理对象隐藏共享访问的实现细节。AUTOSAR Runtime for Adaptive Applications 接口应按值返回代理对象。调用者应将该对象用作后续通信的本地代理。按值返回是返回数据最直接的方式。本决策强制 AUTOSAR Runtime for Adaptive Applications 接口的统一化。协议栈供应商可以自由选择如何在代理类内部实现共享访问。调用者使用本地代理对象的示例如下： |
Result<void> myFunc() {
Result<KeyValueStorage> kvsRes = KeyValueStorage::Create(KVS_ID);
if (kvsRes) {
KeyValueStorage kvs = std::move(kvsRes).Value();
auto keyRes = kvs.GetAllKeys(); // 值语义
// ...
} else {
return {std::move(kvsRes).Error()};
}
}
| 类别 | 无 |
|---|---|
| 是否影响应用 | 是 |
| 假设 | 未作假设。 |
| 约束 | 未识别出约束。 |
| 备选方案 | 使用句柄实现共享访问——使用代理类的备选方案是使用句柄。但句柄会暴露共享访问的实现细节。 |
| 备注 | 无备注。 |
| 相关需求 | • [RS_AP_00135] 避免共享所有权 |
| 发布 | R20-11 |
5.2.8. 功能簇应标准化其量产错误（Functional Clusters shall standardize their production errors）¶
| 字段 | 内容 |
|---|---|
| 适用平台 | AP |
| 决策 | 功能簇应针对市场所要求的常见用例标准化其量产错误（production error）。标准化应通过在所有规定量产错误的 SWS 文档中用一张标准化表汇总所有量产错误来实现。 |
| 依据 | 量产错误是客观存在的。为了能够（半）自动地分析它们并对它们作出反应，需要将它们及其文档化/持久化以及修复方式标准化。 |
| 类别 | 无 |
| 是否影响应用 | 是 |
| 假设 | 概念上，量产错误取自 AUTOSAR 经典平台。无需区分量产错误与扩展量产错误。 |
| 约束 | 未识别出约束。 |
| 备选方案 | 引入用于监控量产错误的接口——功能簇提供接口以允许应用监控量产错误。 |
| 备注 | 无。 |
| 相关需求 | 无 |
| 发布 | R21-11 |
5.2.9. 虚函数中不允许默认实参（Default arguments are not allowed in virtual functions）¶
| 字段 | 内容 |
|---|---|
| 适用平台 | AP |
| 决策 | 虚函数中完全不应使用默认实参。 |
| 依据 | "C++ 核心指南"中相应的需求太弱……（它们只要求确保默认实参总是相同）……这将导致带有依赖关系的代码重复以及高的一致性风险，很容易导致非预期行为。 |
| 类别 | 无 |
| 是否影响应用 | 是 |
| 假设 | 未作假设。 |
| 约束 | 未识别出约束。 |
| 备选方案 | 未考虑任何备选方案。 |
| 备注 | 无备注。 |
| 相关需求 | • [RS_AP_00148] 虚函数中不允许默认实参 |
| 发布 | R21-11 |
5.2.10. 断言只能调用来自已正确初始化的功能簇的 API（Assert that only APIs from properly initialized functional clusters can be called）¶
| 字段 | 内容 |
|---|---|
| 适用平台 | AP |
| 决策 | 如果调用了依赖于先经 ara::core::Initialize 初始化的功能，而 ara::core::Initialize 尚未被调用，则功能簇的实现应将其视为违规，并应遵循 [9, Specification of Adaptive Platform Core] 中的 SWS_CORE_00003。 |
| 依据 | 从未初始化的、依赖先前初始化的功能簇调用 API 无法正确执行。这会导致未定义行为。该问题通常由系统启动较早阶段的错误配置或不完整的初始化引起。在检测到错误的时刻，API 的调用者无法处理它。中止执行是发出这类系统性错误信号并防止后续故障的唯一方法。 |
| 类别 | 无 |
| 是否影响应用 | 是 |
| 假设 | 系统的部分内容需要静态初始化。 |
| 约束 | 未识别出约束。 |
| 备选方案 | 扩展所有 API 以报告特定错误码——为每个依赖先前初始化的 API 扩展一个特定错误码（例如 kNotInitialized），并强制调用者在每次调用时检查该错误码（并让它们自行中止）。 |
| 备注 | 无备注。 |
| 相关需求 | 无 |
| 发布 | R21-11 |
5.2.11. AUTOSAR Runtime for Adaptive Applications 应只定义打算供 AUTOSAR 应用和其他功能簇使用的接口（The AUTOSAR Runtime for Adaptive Applications shall define only interfaces that are intended to be used by AUTOSAR applications and other Functional Clusters）¶
| 字段 | 内容 |
|---|---|
| 适用平台 | AP |
| 决策 | 明确禁止标准化实现细节，例如：• 应用层级或平台扩展 API 中不使用的类、基类、函数等 • 公共 API 中的实现继承 • 任何形式的 C++ SFINAE 技术 • 类的私有成员 |
| 依据 | • 只提供狭窄的接口，以避免与实现细节耦合。 • 隐藏实现细节，因为按照 AUTOSAR 的定义，实现细节属于平台供应商。 |
| 类别 | 无 |
| 是否影响应用 | 是 |
| 假设 | 未作假设。 |
| 约束 | 未识别出约束。 |
| 备选方案 | 未考虑任何备选方案。 |
| 备注 | 无备注。 |
| 相关需求 | • [RS_AP_00150] 只提供打算供 AUTOSAR 应用和其他功能簇使用的接口 |
| 发布 | R21-11 |
5.2.12. AUTOSAR Runtime for Adaptive Applications 的 API 应遵循 C++ 核心指南（AUTOSAR Runtime for Adaptive Applications APIs should follow the C++ Core Guidelines）¶
| 字段 | 内容 |
|---|---|
| 适用平台 | AP |
| 决策 | AUTOSAR C++ API 应遵循 [8, C++ Core Guidelines]。硬实时系统的例外情形应予适用。发生冲突时，RS-General 中定义的 AUTOSAR 指南应优先于"C++ 核心指南"。如果 AUTOSAR C++ API 的某一部分出于其他原因无法遵循"C++ 核心指南"，其规范应说明依据（具体如何说明，应与架构组对齐）。 |
| 依据 | 这些指南在市场上被广泛接受。它们旨在帮助 C++ 程序员编写更简单、更高效、更易维护的代码。目前没有针对汽车领域的 C++14 专用指南。当即将发布的 MISRA C++ 标准出版时，本决策/需求可能被遵循 MISRA C++ 的决策/需求取代。 |
| 类别 | 无 |
| 是否影响应用 | 是 |
| 假设 | 未作假设。 |
| 约束 | 存在一些例外，例如 ARA API 的无异常处理。 |
| 备选方案 | 未考虑任何备选方案。 |
| 备注 | 无备注。 |
| 相关需求 | • [RS_AP_00151] C++ 核心指南 |
| 发布 | R21-11 |
5.2.13. 守护进程连接丢失的统一错误处理（Harmonized error handling for lost daemon connection）¶
| 字段 | 内容 |
|---|---|
| 适用平台 | AP |
| 决策 | 如果功能簇与远程对端通信（例如与守护进程的 IPC 通信），应为通信故障识别适当的错误情形（例如通信丢失）。这些错误情形应被分组（按照相同的错误恢复机制），并且如果 API 的用户应为某一特定组接收通知（例如通过回调或返回错误码），则应选择一种合适的通知机制。请注意，可能存在 API 的用户按设计不接收任何通知的场景（例如"即发即忘"（fire-and-forget）方法）。如果错误发生时需要立即动作，则应按以下方式确定动作类型：• 当前定义为返回类型 void 的函数（即发即忘方法）不需要立即动作。因此，此类函数无需提供返回类型和错误码。自适应平台应将此类函数的效果推迟到与守护进程的连接（重新）建立之后。示例：在诊断管理中对骨架（skeleton）调用 Offer() 应将回调的内部注册推迟到守护进程连接（重新）建立之后。• 同步函数（例如 getter 与 setter）需要立即动作。对同步函数应实现以下选项之一：- 提供错误码，例如类型为 ara::core::ErrorDomain::CodeType 的 kServiceNotAvailable。- 映射到所返回数据结构（例如类对象）内部的功能状态信息，以表示错误状态 • 异步函数（例如返回 ara::core::Future 的函数）需按个案决策，依据是能够在这些函数通常的时间界限内（重新）连接到守护进程的可能性。如果错误发生时需要将通知客户端作为立即动作，则通知机制应基于 ara::core::Future 中的机制或客户端回调。客户端回调使用状态 |
| 依据 | 应用需要在通信基础设施被中断时被告知，以便处理错误并采取对策（如有）。所提供的用于选择动作类型的指南提高了自适应平台 API 的可用性，因为错误基于 API 的类型以自然的方式发出信号。此外，错误处理部分由自适应平台完成。 |
| 类别 | 无 |
| 是否影响应用 | 是 |
| 假设 | 作出了以下假设：• 实现不依赖通信接口的类型，例如进程本地、ara::com 或原生 IPC 机制均在本决策的范围内。 • API 的用户不需要轮询通信状态。 • 服务断开的原因应对 API 的用户保持不可知。 • 面向连接的通信由于协议固有的检测机制而不在本决策的范围内。 |
| 约束 | 未识别出约束。 |
| 备选方案 | 未考虑任何备选方案。 |
| 备注 | 无备注。 |
| 相关需求 | 无 |
| 发布 | R21-11 |
5.2.14. 诊断的粒度（Granularity of diagnostics）¶
| 字段 | 内容 |
|---|---|
| 适用平台 | AP |
| 决策 | 诊断实体应与车辆内部署单元完全一致。部署单元指从硬件单元（ECU）直到软件集群（Software Cluster）。 |
| 依据 | 如果诊断具有相同的边界，可保持车下世界的一致性。生产与售后（workshop）系统通常绑定到物理设备。因此，许多 OEM 希望在自适应平台上同样从这一方法起步。因此，只要车辆不存在单独的软件配置（例如因为已安装的可选配置可以由驾驶员自行选择），车下系统就可以通过严格的工作流保持一致。 |
| 类别 | 无 |
| 是否影响应用 | 否 |
| 假设 | DM 核心不在乎是否（在新的软件集群的语境下）安装了另一个诊断服务器，还是仅仅扩展了当前诊断服务器。 |
| 约束 | 诊断是使用外部描述来记录通信内容的（非冗长的）车下通信。对于车辆的开发使用 AUTOSAR DEXT；对于车下世界通常使用 ASAM ODX 格式，因为它在不同车型系列之间提供了更高的灵活性。如今，保持两个世界的一致性通常已经是一个挑战。但随着自适应平台提供的动态部署，这更具挑战性，因为在最坏的情况下每台车辆都具有已安装软件集群的单独配置。 |
| 备选方案 | 无，因为两种选项都有市场需求。 |
| 备注 | 无备注。 |
| 相关需求 | 无 |
| 发布 | R21-11 |
5.2.15. 断言在工具链不支持异常时不能使用可能抛出异常的构造函数（Assert that exception-throwing constructors cannot be used if the toolchain does not support exceptions）¶
| 字段 | 内容 |
|---|---|
| 适用平台 | AP |
| 决策 | 如果编译工具链不支持异常，调用可能抛出异常（作为其定义行为的一部分）的构造函数应导致编译错误。该编译错误应由带有错误消息"This constructor requires exception support."的 static_assert 产生。 |
| 依据 | 对可能抛出异常的构造函数的非预期调用在编译期即被检测到。static_assert 是唯一可行的选项。将构造函数声明为 protected 或 private 更为复杂。此外，static_assert 支持自定义错误消息，可以明确陈述原因。 |
| 类别 | 无 |
| 是否影响应用 | 是 |
| 假设 | AUTOSAR 所面向的工具链中存在不支持异常的。 |
| 约束 | 未识别出约束。 |
| 备选方案 | 可能抛出异常的构造函数不参与重载决议——当编译工具链不支持异常时，可能抛出异常的构造函数不参与重载决议。•（优点）与 ara::core::Result::ValueOrThrow() 的解决方案类似 •（缺点）改变重载集合。因而可能导致对程序流的非预期改变，而不是编译错误。——由于重载和转换函数，可能发生对程序流的非预期改变。——关于构造函数重载的指南可能有帮助。——转换函数无法由 AUTOSAR 自适应平台控制。——该问题对 Result::ValueOrThrow() 不存在，因为该函数没有在不支持异常的工具链下可用的重载。•（缺点）可能导致供应商提供的头文件中出现大量 #ifdef。 |
| 备选方案 | 可能抛出异常的构造函数应调用 abort 而不是抛出异常——当编译工具链不支持异常时，可能抛出异常的构造函数应调用 abort 而不是抛出异常。•（优点）如果能够排除异常被抛出，那么即使工具链不支持异常，也可以使用可能抛出的构造函数。•（缺点）除非供应商对其 C++ 标准库进行大规模修改（如果它恰好不符合 AR 规定的风格），否则供应商可能难以支持。•（缺点）对此类构造函数的非预期调用只能在运行期、且仅在发生错误的情况下被检测到。 |
| 备选方案 | 实现特定的行为 •（缺点）违反 [RS_AP_00111]。 |
| 备选方案 | 将所有公共构造函数声明为 noexcept——所有公共构造函数应声明为 noexcept。代替可能抛出异常的公共构造函数，应使用命名构造函数惯用法（即使工具链支持异常）。•（优点）对可能抛出异常的构造函数的非预期调用在编译期即被检测到。•（缺点）当使用支持异常的工具链时是不必要的限制。 |
| 备注 | 无备注。 |
| 相关需求 | • [RS_AP_00152] 构造函数内部的故障 |
| 发布 | R21-11 |
5.2.16. 重启进程的范围是一个功能组（The scope for restarting processes is a FunctionGroup）¶
| 字段 | 内容 |
|---|---|
| 适用平台 | AP |
| 决策 | 应用可以在功能组（FunctionGroup）的范围内重启。理想情况下，监督错误的恢复应在其自己的功能组内处理。如果无法在自己的功能组内处理恢复，则必须在 State Management 内升级，恢复的协调应在那里进行。典型情形可以是：• 多个功能组的关闭/重启 • 其他功能组的启动 • 或整台机器的重启。整台机器重启的协调必须在平台核心（platform-core）软件集群的 State Management 内协调。 |
| 依据 | 软件集群是可独立部署的单元。它们可以在之后被添加到同一台机器，并且不应危害其他软件集群（软件集群之间的免受干扰）。恢复应始终首先在软件集群内尝试。 |
| 类别 | 安全（Safety） |
| 是否影响应用 | 否 |
| 假设 | 平台核心软件集群是承担日常管理职责的初始软件集群，Execution Management、Platform Health Management 与 State Management 是其必备部分（如果它是一台安全相关的机器）。 |
| 约束 | 未识别出约束。 |
| 备选方案 | 重启单个应用进程——应用可以在软件集群的范围内重启。软件集群是用于部署的，在运行期不可见。因此，它不能用于该语境。 |
| 备注 | 无备注。 |
| 相关需求 | 无 |
| 发布 | R21-11 |
5.2.17. APPLICATION_LAYER 类别软件集群的平台无关开发（Platform-independent development of Software Clusters of category APPLICATION_LAYER）¶
| 字段 | 内容 |
|---|---|
| 适用平台 | AP |
| 决策 | 功能簇守护进程及其启动协调应是 PLATFORM_CORE 或 PLATFORM 类别软件集群的一部分。 |
| 依据 | 这使得 APPLICATION_LAYER 类别的软件集群能够统一且平台无关地集成。因此，在开发 APPLICATION_LAYER 类别的软件集群时，无需关心平台软件。 |
| 类别 | 无 |
| 是否影响应用 | 是 |
| 假设 | 市场需求是交付预装了自适应平台软件的机器。 |
| 约束 | 未识别出约束。 |
| 备选方案 | 不限制平台软件在软件集群之间的分配——对平台软件不作任何限制。这可能导致平台软件集成的不统一。 |
| 备注 | 无备注。 |
| 相关需求 | 无 |
| 发布 | R21-11 |
5.2.18. 功能簇应标准化其日志/跟踪（Functional Clusters shall standardize their logging/tracing）¶
| 字段 | 内容 |
|---|---|
| 适用平台 | AP |
| 决策 | 功能簇应针对市场所要求的常见用例标准化其日志/跟踪。标准化应针对非冗长的日志/跟踪。如适用，应通过两张标准化表（一张用于日志、另一张用于跟踪）汇总，列出所有标准化的日志/跟踪消息。 |
| 依据 | 功能簇内标准化的日志/跟踪使得能够在整车层级对日志/跟踪进行统一评估。 |
| 类别 | 无 |
| 是否影响应用 | 是 |
| 假设 | 出于各种用例（根因分析、审计、调试）都需要日志/跟踪。特别是在分布式环境中，需要统一化以支持自动分析。 |
| 约束 | 未识别出约束。 |
| 备选方案 | 不标准化日志——完全不标准化日志。 |
| 备注 | 无备注。 |
| 相关需求 | 无 |
| 发布 | R21-11 |
5.2.19. 关于定义服务接口还是 C++ 接口的指导（Guidance whether to define a service or a C++ interface）¶
| 字段 | 内容 |
|---|---|
| 适用平台 | AP |
| 决策 | 选择服务接口还是 C++ 库接口，应基于与 API 消费者的接口可用性、自适应平台资源的高效使用以及通信所需能力相关的设计准则。在准则冲突的情况下，应通过库接口实现。该决策应考虑各种设计方面。偏向基于服务的接口设计的准则：• 使用可用于代码生成的建模数据类型。 • 支持面向服务通信的各种特性：服务接口提供方法（method）、事件（event）、触发器（trigger）、字段（field）等元素以满足特定类型的通信模式。此外，可以在单个服务接口中聚合这些元素中的任意类型。此类通信特性无法通过库接口提供。 • 支持通信端点的灵活发现——如果实现了服务接口，服务的消费者不必关心服务实例的位置。服务可能部署在不同的机器上。 • 专注于数据传输。偏向基于库的接口设计的准则： • 减少配置方面的工作量。 • 减少通信控制的开销——库接口不需要维护提供者与消费者之间的通信信道。某些类型的通信模式可能表现出更好的性能，例如不频繁的数据交换、点对点通信。 |
| 依据 | 质量要求提出"标准的使用对供应商和应用开发者而言应尽可能简单"。如果需要端点配置、服务发现或远程调用，使用服务的既有功能而不是单独的解决方案是明智的。质量要求还提出"整体方法不应被破坏（避免在一个标准中出现不同的方法）"。C++ 库接口更简单，可能更高效。它们还为实现留出更多自由，因为它们允许在自适应应用的进程中运行的实现。质量要求提出"规范应允许运行期高效的实现。运行期效率指所有资源消耗：CPU、RAM、ROM"。因此，在不确定服务接口是否有利时，应优先选择 C++ 库接口。 |
| 类别 | 无 |
| 是否影响应用 | 否 |
| 假设 | 未作假设。 |
| 约束 | 未识别出约束。 |
| 备选方案 | 总是使用服务接口——优点：• 所有功能簇使用同类接口。缺点：• 对应用开发者而言并非总是最自然的方式。在不需要通信管理功能的情况下带来不必要的复杂性与实现限制。 |
| 备选方案 | 总是使用 C++ 库接口——优点：• 所有功能簇使用同类接口。缺点：• 对应用开发者而言并非总是最自然的方式。将需要针对服务发现与选择的单独解决方案。 |
| 备注 | 在调用方自适应应用的进程中运行的进程内实现只对具有 C++ 库接口的功能簇可行。具有服务接口的功能簇需要一个专门的进程。按照本决策，网络管理应提供 C++ 库接口。尽管如此，网络管理仍保持使用服务接口以维持向后兼容。 |
| 相关需求 | 无 |
| 发布 | R22-11 |
5.2.20. 只支持软件集群之间的功能依赖（Support only functional dependencies between Software Clusters）¶
| 字段 | 内容 |
|---|---|
| 适用平台 | AP |
| 决策 | 软件集群之间只应支持功能依赖。 |
| 依据 | 软件集群已经是一个结构化的部署实体，并且技术上是在机器上可以单独安装和更新的最小单元（借助软件包（Software Package））。这意味着即使是增量更新（例如只更新该软件集群内的单个进程）也需要软件集群的一个新版本。 |
| 类别 | 无 |
| 是否影响应用 | 否 |
| 假设 | 未作假设。 |
| 约束 | 未识别出约束。 |
| 备选方案 | 支持嵌套的软件集群——结构化嵌套软件集群的备选方案曾在 AUTOSAR 中实现过，但市场用例也可以通过具有功能依赖的软件集群实现。 |
| 备注 | 停止使用结构化嵌套的软件集群（又称 Sub-SWCL）。 |
| 相关需求 | 无 |
| 发布 | R22-11 |
5.2.21. 功能簇的错误处理职责（Responsibility of clusters for error handling）¶
| 字段 | 内容 |
|---|---|
| 适用平台 | AP |
| 决策 | 功能簇应为每个可检测的错误定义错误处理策略——无论运行期问题的根因是该簇内部还是外部的。错误处理应在软件规范中针对所有类型的可检测错误进行文档化，并包含以下信息：• 响应所检测错误的机制 • 检测与响应的时序约束 • 以前置/后置条件的形式定义的对其他软件组件执行或抑制的任务的要求 |
| 依据 | 如果错误处理可能涉及多个软件组件，功能簇应避免隐式依赖其他软件组件的行为（例如其他功能簇、自适应应用、驱动与内核模块等基础软件）。对于不明显或非平凡的错误处理机制，应适用"按契约设计"（design by contract）原则。该原则可以通过在所涉软件组件的规范中一致地文档化错误处理来实现。 |
| 类别 | • 安全（Safety）• 信息安全（Security） |
| 是否影响应用 | 是 |
| 假设 | 对于涉及不同软件组件的复杂错误情形，需要评审错误处理的一致性。不同软件规范中的文档化共同构成关于错误处理的"按契约设计"。目前不考虑为此提供工具支持。 |
| 约束 | 以下情形不需要按契约设计的文档化：• 明显的错误，例如由返回给方法调用者的通用定义错误码表示的错误 • 纯粹局限于功能簇局部范围的错误无需按契约设计的描述 |
| 备选方案 | 未考虑任何备选方案。 |
| 备注 | 示例：如果由于文件系统损坏导致回滚到先前的软件集群版本失败，停留在 kRollingBack 状态而不作通知是不够的。 |
| 相关需求 | 无 |
| 发布 | R22-11 |
5.2.22. 引入虚函数需要审批（The introduction of virtual functions requires approval）¶
| 字段 | 内容 |
|---|---|
| 适用平台 | AP |
| 决策 | 对 AUTOSAR 自适应平台 API 中引入新虚函数的任何变更都应提交架构工作组审批。 |
| 依据 | AUTOSAR 自适应平台 API 被设计为由协议栈供应商直接实现。例如，通常没有定义抽象类或需要协议栈供应商实现的虚函数。因此，一般无需定义虚函数。但是，对于某些用例可能需要此类虚函数（例如应由应用实现的回调）。此类用例将被收集，之后应从中归纳出一般的设计模式。 |
| 类别 | 无 |
| 是否影响应用 | 否 |
| 假设 | AUTOSAR 自适应平台 API 被设计为由协议栈供应商直接实现（通常没有抽象类、没有需要协议栈供应商实现的虚函数）。 |
| 约束 | 未识别出约束。 |
| 备选方案 | 未考虑任何备选方案。 |
| 备注 | 推广不应影响已在已发布文档中规定的带有虚函数的类。 |
| 相关需求 | 无 |
| 发布 | R22-11 |
5.2.23. 将 SW 函数引入自适应架构的指南（Guidelines to introduce a SW function into Adaptive Architecture）¶
| 字段 | 内容 |
|---|---|
| 适用平台 | AP |
| 决策 | 在自适应架构内分配 SW 函数的决策应遵循一组准则。以下准则偏向将 SW 函数分配给自适应应用：• 该函数具有 OEM 业务竞争优势的潜力 • 该函数主要实现 OEM 特定的需求。以下准则偏向将 SW 函数分配给自适应平台功能簇：• 该函数可被多个 OEM 和多个项目复用 • 该函数可被同一项目中的多台机器复用 • 该函数对标准化的通信协议进行抽象 • 该函数向应用提供由其他标准定义的功能 • 该函数使用自适应平台内部接口。以下准则偏向将 SW 函数分配给基础软件：• 该函数对硬件资源的直接访问进行抽象 |
| 依据 | 未提供依据。 |
| 类别 | 无 |
| 是否影响应用 | 是 |
| 假设 | 术语"SW 函数"指处理数据的 SW 组件。因此，不进行处理的数据转发不在范围内。 |
| 约束 | 未识别出约束。 |
| 备选方案 | 未考虑任何备选方案。 |
| 备注 | 对于自适应架构，不存在将 SW 函数分配到特定域的普遍适用规则。因此，应将本架构决策理解为支持此类分配决策的指南。 |
| 相关需求 | 无 |
| 发布 | R23-11 |
5.2.24. 扩展接口的指南（Guidelines for Extension Interfaces）¶
| 字段 | 内容 |
|---|---|
| 适用平台 | AP |
| 决策 | 自适应平台应通过标准化的扩展接口（即所谓平台扩展接口（Platform Extension Interface））支持对其行为的扩展。平台扩展接口的实现例如由 OEM、集成者或其他第三方应用提供。此类扩展将以某种编程语言实现，不带任何代码生成支持，也不在清单（Manifest）中进行任何运行期配置。平台扩展接口的使用应限于这样一些情形：提供行为的一个实现比通过清单配置一个通用行为有充分理由。使用插件（Plugin）模式的平台扩展接口（参见 [2, EXP_SWArchitecture]，8.5.4 节）需要架构工作组的评审与批准。 |
| 依据 | 允许平台扩展接口的依据是自适应平台标准具有更好的可用性。特别是，以下质量属性的满足程度得到提升：• "AUTOSAR 自适应平台标准元素应易于使用且难以误用。"——因为在平台扩展接口适用的情形下，它们使用起来更方便。为平台扩展接口提供模式（参见 [2, EXP_SWArchitecture]，8.5.4 节）有助于满足以下质量属性：• "AUTOSAR 自适应平台标准应记录其决策，包括其依据与后果。" • "AUTOSAR 自适应平台标准应遵循整体方法并避免在一个标准中出现不同的方法。"平台扩展接口不干扰质量属性"应用开发者不应能够为预定义的平台功能提供自定义实现"，因为平台扩展接口的实现确实提供的是平台本身未提供的功能。 |
| 类别 | 无 |
| 是否影响应用 | 否 |
| 假设 | 假定通过清单对自适应平台协议栈实现进行完全定制并不能提供最佳可用性。对于某些变化点，假定提供行为的一个实现比配置一个通用行为更容易。在此类情形下，自适应平台需要通过由 OEM、集成者或其他第三方应用实现的标准化平台扩展接口来支持扩展。 |
| 约束 | 未识别出约束。 |
| 备选方案 | 只使用清单——该备选方案将禁止任何平台扩展接口。AUTOSAR 自适应平台行为的任何变化都需要通过清单配置。未考虑该备选方案，因为对某些变化点而言，配置一个通用行为比提供行为本身的实现要复杂得多。 |
| 备注 | 平台扩展接口受支持的模式在 [2, EXP_SWArchitecture] 的 8.5.4 节中描述。 |
| 相关需求 | 无 |
| 发布 | R23-11 |
5.3. 经典平台¶
本节列出仅为 AUTOSAR 经典平台所作的架构决策。
5.3.1. 结构体元素的顺序是标准的有约束力部分（The ordering of structure elements is a binding part of the standard）¶
| 字段 | 内容 |
|---|---|
| 适用平台 | CP |
| 决策 | SWS 定义的结构体元素的顺序被视为标准的一部分。因此，实现特定的优化（例如按大小对结构体元素重新排序以避免对齐间隙）不符合标准。 |
| 依据 | 偏离的结构体类型定义可能危害目标代码的互操作性。 |
| 类别 | 无 |
| 是否影响应用 | 是 |
| 假设 | 结构体元素通常通过名称访问，这意味着顺序不应有影响。但也存在有效的用例，例如不带指定初始化器的结构体初始化（例如 my_struct x = {0, 42}），此时完全不涉及元素名称。 |
| 约束 | 无 |
| 备选方案 | 结构体元素不设标准化顺序——SWS 中结构体元素的顺序不由标准规定。实现可以自由地进行任何期望的重新排序。 |
| 备注 | 在资源优化的实现中，结构体元素通常按大小排序以避免对齐间隙。这有助于提高效率并减少内存消耗。尽管如此，AUTOSAR 定义的一些结构体并不遵循这一规则。 |
| 相关需求 | 无 |
| 发布 | R21-11 |
5.3.2. 标准化头文件的类型（Types of standardized header files）¶
| 字段 | 内容 |
|---|---|
| 适用平台 | CP |
| 决策 | 应只有 3 种类型的头文件：1. 模块头文件（例如 NvM.h、CanIf.h、EcuM.h……） 2. 两个模块之间的私有头文件（例如 BswM_Sd.h、Adc_SchM.h、Dcm_Externals.h……） 3. 共享头文件（例如 PlatformTypes.h、StandardTypes.h、Can_GeneralTypes.h、ComStackTypes.h……）。任何其他头文件都不再必要，并从 SWS 中删除/移除。这意味着它们不再被标准化。不过，实现可以出于自身目的自由拥有此类头文件。规则：• 所有头文件都是自包含的 • 在自己的接口中使用另一 BSW 模块类型的模块必须考虑将此类类型移入共享头文件（例外：由 RTE 生成并经由 Rte_<Mip>.h 提供的服务接口类型） • 按定义，库不能有私有头文件 • 共享头文件只由类型和枚举组成（没有函数原型……） • 共享头文件从不依赖其他模块头文件或私有头文件 • 对于到集成代码或 CDD 的 callout：原型经由 <Mip>_Externals.h 提供。后果：• 类型与 API（C 接口）的表应有一行"Available via"，以指示导出该类型/函数的头文件的名称 |
| 依据 | 这对于回答"用户需要哪个头文件"这一问题的外部视角而言已经足够。 |
| 类别 | 无 |
| 是否影响应用 | 否 |
| 假设 | 无 |
| 约束 | 无 |
| 备选方案 | 面向 BSW 实现的头文件概念——保留当前面向 BSW 实现的头文件概念。 |
| 备注 | 无。 |
| 相关需求 | 无 |
| 发布 | R21-11 |
5.3.3. 不兼容 API 变更的指导（Guidance for incompatible API changes）¶
| 字段 | 内容 |
|---|---|
| 适用平台 | CP |
| 决策 | 如果 BSW 模块的函数需要不兼容的变更，API 名称的变更应基于以下决策矩阵：[变更] → [API 应更名（即新 API，旧 API 置为 obsolete）] [新增/移除参数且行为改变] → [是] [新增/移除参数且行为不变] → [否：直接变更、"缺陷"、"优化"] [更改既有类型/返回类型且行为改变] → [是] [更改既有类型/返回类型且行为不变] → [否] [函数行为的重大变更而不更改原型] → [是]。如果新 API 替代旧 API，旧的（被废弃的）API 应包含应改用哪个新 API 的信息。A) 对于不被其他 BSW 模块使用的外部 API，应适用以下生命周期变更：1. 引入新函数并将既有的旧函数置为"obsolete" 2. 在发布 +1 中：移除旧函数。B) 对于主要或专用于 BSW 模块之间的其他 API，变更应立即可见（直接变更既有函数，不设"obsolete"）。 |
| 依据 | 该方法提供最佳的向后兼容评级，并为用户提供迁移时间。 |
| 类别 | 无 |
| 是否影响应用 | 否 |
| 假设 | 被变更的函数是普通服务函数。Callout（原型由模块定义但代码不由模块定义的函数）可以用不同方式处理。 |
| 约束 | 无 |
| 备选方案 | 直接变更既有函数——也可以直接变更既有函数而不是新增函数。•（优点）如果只是新增/移除参数，则函数名称不变 •（缺点）不为用户提供迁移阶段。 |
| 备选方案 | 为未来的变更做好准备——如果已经知道该函数将来可能变更，则参数可以以标签/值对的形式提供。•（优点）允许为未来用例对参数进行兼容扩展 •（缺点）需要变长参数（"..."），会引起 MISRA 问题。 |
| 备注 | 本决策的缺点是新函数需要新的函数名。对于既有原型无法支持已定义行为的真实缺陷（"根本无法工作"），无需迁移阶段的直接变更更为可取。如果一个 C 类型被变更（例如结构体新增一个字段）且该类型出现在原型中，则该类型的变更被视为兼容。因此不需要强制变更函数原型（例如函数名）。（注：源文档中该决策的备选方案/备注/发布各行在 PDF→markdown 转换中严重乱序，此处按可读内容保守重组。） |
| 相关需求 | 无 |
| 发布 | R22-11 |
5.3.4. AUTOSAR 经典平台中时间的处理（Handling of Time in the AUTOSAR Classic Platform）¶
| 字段 | 内容 |
|---|---|
| 适用平台 | CP |
| 决策 | Tm 模块应处理与本地时间处理相关的所有用例。这包括当前使用 Os 的所有情形（例如时间处理的服务接口）。 |
| 依据 | 这减少了 AUTOSAR 经典平台中既有时间服务的重叠与歧义。 |
| 类别 | 无 |
| 是否影响应用 | 是 |
| 假设 | 未作假设。 |
| 约束 | 全局时间同步仍然需要单独的模块（例如 StbM）。此外，EcuM 中存在不受本决策影响的特定时序用例。 |
| 备选方案 | 将功能集成到 Os 模块——移除 Tm 模块并将功能集成到 Os 模块中。 |
| 备选方案 | 移除 Tm 模块——移除 Tm 模块且不替代其功能。 |
| 备选方案 | 将功能集成到 StbM 模块——移除 Tm 模块并将功能集成到 StbM 模块中。 |
| 备注 | 无备注。 |
| 相关需求 | 无 |
| 发布 | R23-11 |
参考文献¶
AUTOSAR_FO_TR_Glossary
[2] Explanation of Adaptive Platform Software Architecture
AUTOSAR_AP_EXP_SWArchitecture
[3] Layered Software Architecture
AUTOSAR_CP_EXP_LayeredSoftwareArchitecture
[4] Dynamic Memory Allocation and Fragmentation https://www.researchgate.net/publication/295010953_Dynamic_Memory_Allocation_and_Fragmentation
[5] Dynamic Memory Allocation on Real-Time Linux https://static.lwn.net/images/conf/rtlws-2011/proc/Jianping.pdf
[6] TLSF: a new dynamic memory allocator for real-time systems https://doi.org/10.1109/EMRTS.2004.1311009
[7] The Memory Fragmentation Problem: Solved? https://doi.org/10.1145/286860.286864
[8] C++ Core Guidelines https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md
[9] Specification of Adaptive Platform Core
AUTOSAR_AP_SWS_Core