1242 lines
97 KiB
Markdown
1242 lines
97 KiB
Markdown
# BSW 分布指南
|
||
|
||
> **AUTOSAR CP Release 4.4.0**
|
||
>
|
||
> 原文：*Guide to BSW Distribution*（文档 ID 631）
|
||
>
|
||
> 翻译状态：**已完成 v1**（封面+变更历史+TOC+Ch 1-6 主体）
|
||
>
|
||
> 对应原文 PDF：`BSWGeneral/AUTOSAR_EXP_BSWDistributionGuide.pdf`
|
||
|
||
---
|
||
|
||
## 文档标识
|
||
|
||
| 字段 | 值 |
|
||
|------|-----|
|
||
| 文档标题 | BSW 分布指南（Guide to BSW Distribution） |
|
||
| 文档标识号 | 631 |
|
||
| 文档所有者 | AUTOSAR |
|
||
| 文档责任方 | AUTOSAR |
|
||
| 文档状态 | 正式版（Final） |
|
||
| 所属 AUTOSAR 标准 | Classic Platform |
|
||
| 所属标准版本 | 4.4.0 |
|
||
|
||
> 原文头部包含版权声明（Disclaimer）段落，已按规范要求略去，仅在此处说明。原文标题为 "Guide to BSW Distribution"。
|
||
|
||
---
|
||
|
||
## 文档变更历史
|
||
|
||
| 日期 | 版本 | 变更人 | 变更说明 |
|
||
|------|------|--------|----------|
|
||
| 2018-10-31 | 4.4.0 | AUTOSAR Release Management | 纳入"MCAL 多核分布"概念 |
|
||
| 2017-12-08 | 4.3.1 | AUTOSAR Release Management | 编辑性修订 |
|
||
| 2016-11-30 | 4.3.0 | AUTOSAR Release Management | 编辑性修订 |
|
||
| 2014-10-31 | 4.2.1 | AUTOSAR Release Management | 纳入"保护 ASIL BSW 免受 QM BSW 影响的机制和约束"概念；次要澄清 |
|
||
| 2014-03-31 | 4.1.3 | AUTOSAR Release Management | 澄清术语 |
|
||
| 2013-03-15 | 4.1.1 | AUTOSAR Administration | 初始发布 |
|
||
|
||
---
|
||
|
||
## 目录
|
||
|
||
1. [介绍](#1-介绍)
|
||
2. [多核系统中的 BSW 分布](#2-多核系统中的-bsw-分布)
|
||
3. [安全系统中的 BSW 分布](#3-安全系统中的-bsw-分布)
|
||
4. [对 AUTOSAR 未来版本的展望](#4-对-autosar-未来版本的展望)
|
||
5. [术语表](#5-术语表)
|
||
6. [参考文档](#6-参考文档)
|
||
|
||
---
|
||
|
||
## 1 介绍
|
||
|
||
本文档是 AUTOSAR 系统中 **BSW 分布**的通用介绍。它由两部分组成：第一章关注**多核**情况下的 BSW 分布；第二章关注**安全**情况下的分布。
|
||
|
||
**第 2 章**指导多核系统上符合 AUTOSAR 标准的软件的开发和配置。从 R4.1 开始，它涉及**AUTOSAR BSW 模块**到多核系统上的分区的**分配**以及它们之间的交互。BSW 模块到不同 BSW 分区的分配允许**增强功能安全**和**提高性能**。
|
||
|
||
> 所有"MCAL 多核分布"的概念部分以及 2.5 节 MCAL 分布章节均处于"草案（draft）"状态。
|
||
|
||
**第 3 章**描述安全情况下的 BSW 分布。从 R4.2 开始，AUTOSAR 允许将 BSW 模块映射到不同的分区并使这些分区**相互保护**。
|
||
|
||
**第 4 章**给出了 BSW 分布领域可能未来扩展的展望。
|
||
|
||
技术术语的术语表和外部信息的参考列表分别在**第 5 章**和**第 6 章**提供。
|
||
|
||
---
|
||
|
||
## 2 多核系统中的 BSW 分布
|
||
|
||
### 2.1 概述
|
||
|
||
本章包含 BSW 模块在多个分区和核心上的分布式执行的**支持场景**描述，以及 BSW 分布可以**提升性能**的若干用例。它还介绍了适用于分布式 BSW 执行的**基本同步概念**，并提供了**分区间通信**的介绍。
|
||
|
||
#### 2.1.1 支持的场景
|
||
|
||
可以将应用用于访问总线、非易失性存储器、I/O 通道和看门狗的 **BSW 模块功能集群**（"BSW Functional cluster"）分配给不同的 BSW 分区，理由是**安全**或**性能**。BSW 模块的集群化**当前未标准化**。除 MCAL 外，**同一类型**的功能集群在不同分区中的并行使用（"复制"）**通常不受支持**，但可以通过使用 **master/satellite 方法**实现。可以将功能集群分配到分区，使得：
|
||
|
||
- 一个 BSW 功能集群**仅在一个分区中可用**
|
||
- 一个 BSW 功能集群在**所有分区中**可用且具有所有接口
|
||
- 一个 BSW 功能集群**分布在多个分区**上（可能具有分区特定的功能子集），以允许**高并发度**
|
||
|
||
无论在哪种场景下，以下限制均适用：
|
||
|
||
- 当前**每个核心最多有一个 QM BSW 分区**
|
||
|
||
基于上述限制，AUTOSAR 支持上述场景。这样做涉及以下基本特性：
|
||
|
||
- **BSW 分区之间通信**的所有代码可以**自动生成**，以适应不同的系统配置。跨分区通信机制可以**以效率为重点**生成，或者在未来的版本中帮助提供**抗干扰自由度**（freedom of interference）。
|
||
- 如果需要访问**系统服务**（不属于 BSW 功能集群的一部分），则应根据需要为需要该系统服务的每个 BSW 分区提供相应接口。
|
||
- 在**每个 BSW 分区中**支持对硬件抽象和驱动程序的高效访问。
|
||
|
||
在所有场景中，**不同模块实体之间的通信**保持**不变**（相对于在单个分区中运行的 BSW）。
|
||
|
||
#### 2.1.2 性能用例和分配给不同核心的硬件
|
||
|
||
以下用例示例说明了如何通过将 BSW 分配到多个分区和核心来**提高系统性能**，以及在访问外设硬件被分配给多个核心的系统中如何从 BSW 到多个分区和核心的分配中受益：
|
||
|
||
- **提高分布式多核系统的性能并减少资源消耗**：可能需要将 BSW 模块的功能集群分配给不同的核心，例如根据硬件架构、负载均衡和 SW-C 的分布，将通信模块放在 BSW 分区 "A"，将 I/O 模块放在 BSW 分区 "B"。特别是，如果硬件资源在多核系统中**由一个核心独占访问**，则通过将相应的 BSW 用户、服务和驱动程序**放置在该核心**上来提高性能。
|
||
- **信号网关功能**：通过将 FlexRay 集群分配给一个核心，将 CAN 集群分配给另一个核心来实现。两个 COM 模块需要在这种情况下**同步**，并且在两个 COM 实例之间必须存在一些**直接的跨核心通信**。其中一个 COM 模块可能是**主 COM**，用于协调另一个核心上的**从 COM**。
|
||
- **两个通信集群位于不同核心**：一个访问 CAN 总线，另一个控制 FlexRay 总线。如果位于一个通信集群之上的应用 SW 位于同一核心上需要通过两个总线发送，则核心本地的 COM 模块可以直接与另一个核心上的对应模块通信，以有效地通过 CAN 或 FlexRay 发送信号。对于接收到的消息，COM 不知道 RTE 上方的接收方。因此，COM 必须在接收端将信号转发给 RTE，通信由 RTE 负责。
|
||
|
||
#### 2.1.3 技术概述
|
||
|
||
以下是对以下章节中描述的技术解决方案的简短总结：
|
||
|
||
- 定义**包含优选所有三个层（栈）的 BSW 模块集群**，或如果需要，包含栈的模块子集（例如通信、内存、I/O 栈）。
|
||
- 模块实体可以拆分为 **master 和 satellites**，并分配给不同的 BSW 分区。Master 和 satellites 可以使用**非标准化的** AUTOSAR 接口进行内部跨分区通信。**Master/satellite 方法**主要用于分布式系统服务模块和**同一类型**的 BSW 集群之间的通信。
|
||
|
||
所提出的解决方案满足对**性能和安全**的要求，同时**最小化**对已经标准化的 BSW 模块接口的影响（`RS_BRF_00206`、`RS_BRF_01160`）。大多数更改隐藏在模块内部（例如通过提供 master/satellite 实现），而**不影响其他模块**。不同模块之间的接口**不变**。
|
||
|
||
##### 2.1.3.1 BSW 功能集群
|
||
|
||
BSW 功能集群是**功能上一致的** BSW 模块的组。每个功能集群包含一组 BSW 模块。可以有**多个相同类型**的 BSW 功能集群（例如不同 BSW 分区中的多个 I/O 集群），每个使用不同的模块集（例如一个分区中的 IOHWA + ADC，另一个分区中的 IOHWA + ADC + DIO）。
|
||
|
||
以下类型的集群可能在以后的版本中标准化：
|
||
|
||
- 通信集群（Communication cluster）
|
||
- 内存集群（Memory cluster）
|
||
- I/O 集群（I/O cluster）
|
||
- 看门狗集群（Watchdog cluster）
|
||
|
||
BSW 功能集群到 BSW 分区的分配由应用软件对 BSW 模块的使用决定。功能集群可以分配给**不同的 BSW 分区**，**同一类型**的功能集群可以在**多个 BSW 分区**中可用。不同的功能集群可以分配到**相同或不同的 BSW 分区**。
|
||
|
||
**同一功能集群**在每个 BSW 分区中**最多只能存在一个**。
|
||
|
||
BSW 功能集群由应用或其他 BSW 模块用于访问总线、内存、I/O 通道和看门狗，它们通常仅在一个或少数 BSW 分区中需要。
|
||
|
||
BSW 功能集群的引入**不会改变** BSW 和 RTE 之间的现有 AUTOSAR 接口，这些接口主要用于实现 AUTOSAR 服务，即与应用层通信。然而，它**可能改变**标准化 AUTOSAR 接口在不同分区上的可用性。
|
||
|
||
BSW 功能集群的**内部结构**（包括 BSW 模块之间的内部通信）以及与 BSW 功能集群使用的系统服务的通信**不一定**受 BSW 并行化的影响，也不需要更改。然而，它**可能**会被调整，例如为了满足对并发的特殊需求，例如支持在不同分区中运行的同一模块的**不同实体**。
|
||
|
||
**同一类型**的 BSW 功能集群中的模块之间的通信和同步（例如，在两个通信集群中支持网关功能）**未标准化**。它将由**特定模块的实体之间的通信**实现（例如通过特定模块的 master 和 satellites），这些模块可以使用**非标准化**的接口在 BSW 分区边界之间进行通信，参见图 1。
|
||
|
||
> **图 1：相同类型的功能集群**
|
||
>
|
||
> （架构示意图：BSW 分区 A 中的功能集群 1 通过 BSW Cluster Interface 与 BSW 分区 B 中的功能集群 2 通信。同一类型的功能集群可分布在不同分区中。）
|
||
|
||
不属于 BSW 功能集群的模块（如系统服务）将**始终**在 BSW 功能集群所在的**同一 BSW 分区**内被访问。由于接口未更改，这些模块必须在**每个 BSW 分区中本地可用**（如果需要的话）。
|
||
|
||
##### 2.1.3.2 BSW 分区间通信
|
||
|
||
对预期在不同 BSW 分区/不同核心上执行的任务的函数调用**不能**实现为对该函数的简单 C 调用，因为这些调用将在本地 BSW 分区上处理。
|
||
|
||
因此，**BSW Scheduler（SchM）**提供函数以使用**客户端-服务器**或**发送方-接收方**通信在**不同的 BSW 分区**上调用**同一模块的 master 或 satellites**。SchM 此 API 的详细信息在 2.2.3 节中说明。
|
||
|
||
##### 2.1.3.3 确定服务执行的分区
|
||
|
||
RTE 事件处理的**实际 BSW 分区**由其**任务映射**决定。基本上：
|
||
|
||
- 如果事件被**映射到任务**，则在该任务所分配的**分区内执行**
|
||
- 如果事件**未映射到任务**，则在与引起该事件的任务相同的分区内执行
|
||
|
||
任务映射的详细信息在 2.4.1 节中描述。
|
||
|
||
从 BSW 实体到其他 BSW 实体的调用**未映射**到分区。它们**在调用位置执行**。因此，对 BSW 函数的多个调用可以**在不同分区和核心上并行处理**。因此，**此类函数必须仔细设计和实现**以处理不同分区中的并行执行；如有必要，它们**应可重入**或**并发安全**。
|
||
|
||
##### 2.1.3.4 BSW 分区
|
||
|
||
只有具有配置参数 `EcucPartitionBswModuleExecution = true` 的分区才能执行 BSW 模块。此类分区称为 **BSW 分区**。BSW 分区可能**额外地**包含 RTE 上方的应用软件组件。
|
||
|
||
### 2.2 BSW 模块的并行执行
|
||
|
||
本节面向 BSW 模块的开发者。
|
||
|
||
#### 2.2.1 核心相关分支
|
||
|
||
由于**同一模块的实体**共享**相同的实现**（即使它们运行在不同的核心上），**不同的行为**不能通过不同的代码来实现。相反，**特定行为**应由**运行时信息**决定。例如，可以使用**核心 ID**，即根据 OS API `GetCoreID()` 或 `GetApplicationID()` 的返回值来分支控制流。
|
||
|
||
实现共享同一实现但运行在不同核心上的模块的另一种变体可以基于**不同核心的单独配置**实现。这要求**按核心调用初始化例程 `Init()`**，传递指向相应配置的指针。**这种设计模式被视为实现 MCAL 核心相关分支的理想选择**。
|
||
|
||
#### 2.2.2 Master/Satellite 方法
|
||
|
||
需要在不同 BSW 分区中访问的模块可以使用 **master/satellite 模式**实现。
|
||
|
||
master 和 satellite 之间的工作分配是**特定于实现的**。一种极端是，**satellite** 仅提供**到同一 BSW 分区中其他模块的接口**，并将**所有请求路由到 master** 并应答回其他模块。另一种极端是，satellite 可以在本地提供**完整功能**（例如在同一 BSW 分区中运行的完整应用的本地模式管理），并且仅在必要时将其内部状态与 master 同步。甚至可能有**多个 master** 用于不同的功能，例如两个 PduR master 用于分布式 PduR 网关。
|
||
|
||
**Master** 协调来自 satellites 的请求，可以**过滤或监控**传入的 satellite 请求。Master 和一个或多个 satellites 在某些方面被视为**一个模块实体**：
|
||
|
||
- Master 和 satellites 始终是**供应商特定的解决方案**，来自**同一供应商**。
|
||
- Master 和 satellite 到其他模块实体的接口**通常与** AUTOSAR 中为传统模块指定的接口**相同**。Master 和 satellite 应提供**相同的 API**。这意味着当迁移到分区系统时，现有的模块实体**可以**被 master 和一个或多个 satellites **替换**，在大多数情况下**无需更改**其他模块。例外情况可能是对由**分区间通信**引起的**额外延迟**的模块内部调整。
|
||
- Master 和 satellites 在每个 BSW 分区中**具有相同的入口点**（即它们从共享内存开始执行相同的函数）并**在内部**根据它们运行的 OS-Application（分区）**分支**（例如通过使用 `GetApplicationID()` API）到 master 或 satellite 特定代码。根据构建策略，如果每个核心可以执行自己的代码，则在多核系统中可能存在其他实现。Satellites 也可能共享**相同的代码**而无需进一步分支。
|
||
- 作为替代实现，master-satellite 方法可以以**master 也实现为 satellite** 的方式实现，而**真正的 master 实现**仅由 BSW 模块内核组成，以便所有请求可以与此内核交换。**这种方法被视为 MCAL 实现的理想选择**。
|
||
- Master 和 satellites 之间的通信**未标准化**。它被认为是**模块内部的**，对其他模块**不可见**。
|
||
- Master 和 satellite 之间的通信可以**以任一方向启动**（即由 master 和 satellites 启动），也可以**从一个 satellite 到另一个 satellite**。
|
||
- Master 和 satellites 之间的**所有接口**只允许在**同一分布式模块内**连接。
|
||
- Master 和 satellites 之间的通信可以在**一个 `BswModuleEntity` 内**实现，也可以在**属于同一 BSW 模块的不同 `BswModuleEntities` 之间**实现。
|
||
- 根据应用，使用 master/satellite **可能**是合适的**或**不合适的。例如，使用**独立的、特定于分区的看门狗集群**（彼此独立工作）可能比在 master/satellite 方法中使用看门狗管理器**更有效**。
|
||
- **Master** 是分布式 BSW 模块的一部分，它**协调** satellites 的请求，并可以**过滤或监控**传入的 satellite 请求。这可能导致**额外的故障检测或故障缓解机制**。通常，由模块的分布式执行引起的**所有错误都应在模块内部处理**。
|
||
|
||
**Master/satellite 实现**是分区系统中**系统服务的标准解决方案**。
|
||
|
||
**特定驱动程序**可能也必须提供本地 satellites，如果硬件**只能从不同的核心访问**。如果可能，**标准解决方案**是在每个分区中执行**相同的多核可重入函数**，并将**待处理数据**分隔为**不相交的集合**（每个分区一个）。例如，**COM 模块**可能处理分配给该模块的 BSW 功能集群所属总线的**所有 IPDU**。对相同硬件或共享数据的**并发访问**需要受保护，例如在这种情况下使用 **ExclusiveAreas**。
|
||
|
||
在**特定情况下**，BSW 功能集群中的模块也**需要**实现为 master/satellite，如果 BSW 功能集群被**复制**并且**不同 BSW 分区中的实体**需要**同步**或**交换数据**。这可能适用于**看门狗管理器**、**NVRAM 管理器**，以及**复制通信集群**中的网络和状态管理器。**COM 模块**也**可能**需要 master 和 satellite 来实现**跨分区网关**功能。
|
||
|
||
#### 2.2.3 使用 BSW Scheduler 进行分区间通信
|
||
|
||
**BSW Scheduler（SchM）**提供了许多函数来支持**并行执行**的 BSW 模块实体之间的通信。更准确地说，它提供以下方法来处理**同步和异步调用**（包括回调）以及**发送方-接收方**通信。
|
||
|
||
该功能**通常类似于** SWC 和 BSW 之间的函数调用。但是，由于 RTE 在某些时间点（特别是在 ECU 启动期间）**可能不可用**，因此**此功能必须在 BSW 自身内可用**。
|
||
|
||
- **`Std_ReturnType SchM_Call_<bsnp>[_<vi>_<ai>]_<name>(...)`**
|
||
调用客户端-服务器操作，可能**跨越分区边界**。实际参数 `data_1 ... data_n` 是传递给被调服务 `[IN]` 和/或重新传递 `[IN/OUT | OUT]` 的信息。返回值参数及其类型 `<typeOfReturnValue>` 的存在**取决于被调服务**。对于**同步调用**，该参数存在且 `<typeOfReturnValue>` 是被调服务返回的类型。对于**异步**客户端-服务器操作和**返回类型为 void** 的操作，该参数**被省略**。
|
||
|
||
- **`Std_ReturnType SchM_Result_<bsnp>[_<vi>_<ai>]_<name>(...)`**
|
||
来自**异步**客户端-服务器操作的回调，可能**跨越分区边界**。回调的接收方由该回调的 `AsynchronousServerCallResultPoint` 确定。`AsynchronousServerCallResultPoint` 引用原始的 `AsynchronousServerCallPoint`，后者又"知道"调用模块实体。
|
||
|
||
- **`Std_ReturnType SchM_Send_<bsnp>[_<vi>_<ai>]_<name>(IN <data>)`**
|
||
将数据写入 BSW 模块之间的**发送方-接收方链接**，可能**跨越分区边界**。
|
||
|
||
- **`Std_ReturnType SchM_Receive_<bsnp>[_<vi>_<ai>]_<name>(OUT <data>)`**
|
||
从 BSW 模块之间的**发送方-接收方链接**读取数据，可能**跨越分区边界**。
|
||
|
||
#### 2.2.4 使用共享缓冲区（在无内存保护系统中）
|
||
|
||
在 BSW 分区之间**无内存保护**的系统中，**系统服务**和**所有 `BswCalledEntities`** 可以在**每个分区中直接调用**，包括**完整调用树**。这需要**可重入、并发安全**的实现。
|
||
|
||
服务和其他被调实体可能处理模块**内部数据**，这些数据在**同一模块的不同实体之间共享**。对此类数据的**所有访问**必须由 **ExclusiveAreas** 保护。具体保护机制的**适用性**取决于可能的访问类型。例如，**并发写入**通常需要**禁止**，而**并发读取**可能是**可接受的**，只要在**同一时间只有一个分区**在写入。
|
||
|
||
`BswSchedulableEntities` **仅位于一个核心**上，并**周期性地**或**事件驱动地**处理数据。
|
||
|
||
> **图 2：在不同核心上调用相同服务**
|
||
>
|
||
> （架构示意图：核心 0 和核心 1 都通过 RTE 调用同一服务 "X"。`BswSchedulableEntity` 映射到任务，从缓冲区读取数据。）
|
||
|
||
图 2 显示了**服务 "X"** 的示例，其中**相同 API 和相同代码**由 RTE **在不同核心上直接调用**。如果服务（分别 `OperationInvokedEvents`）**未映射到任务**，则为**默认**。
|
||
|
||
代码**必须**是**可重入和并发安全**的，这意味着对数据的**所有访问**都必须防止**来自相同模块的相同或不同实体的并发访问**。
|
||
|
||
在本示例中，**相同的服务 "X"（`BswCalledEntity`）**写入**可从核心 0 和核心 1 访问的**模块内部数据缓冲区。**`main function`（`BswSchedulableEntity`）**（映射到任务）从缓冲区**读取数据**以供进一步处理。为防止读/写冲突，**此 "main function"** 必须防止在写入时读取缓冲区。
|
||
|
||
这可以视为**无内存保护系统的通用 master/satellite 方法的特殊情况**。
|
||
|
||
**该方法的优点**是只要它们以**并发安全**的方式实现，就可以使用**原始的、未更改的模块**。如果同一模块的不同实体处理相同的数据（如此核心 0 的示例所示），通常**单核就是这种情况**。与 **AUTOSAR R4.0 解决方案**（所有服务调用都必须路由到主核心）相比，性能可以**大幅提高**，而无需太多工作（假设以后不需要进行跨核心通信）。
|
||
|
||
对于**并发安全、可重入**的实现，必须考虑以下几点：
|
||
|
||
- 对**所有共享资源**（例如缓冲区）的访问由 **ExclusiveAreas** 保护。
|
||
- 如果被调实体**安全**或调用**由 ExclusiveAreas 保护**（如果锁定时间保持在指定限制内），则**调用树**可以**多核安全**。
|
||
|
||
**可供 CDD 使用的 `BswCalledEntities`** 也可以由 CDD **直接调用**。R4.0 中的相同规则适用。
|
||
|
||
SchM **必须支持**跨核心 **ExclusiveAreas**，由**受保护的 Spinlocks** 实现。受保护的 spinlock 是具有 `OS_SPINLOCK` 作为其 `RteExclusiveAreaImplMechanism` 值的**独占区域**。此类独占区域**仅供 BSW 模块控制的访问使用**。受保护的 spinlocks 由**基础软件调度器**处理。
|
||
|
||
#### 2.2.5 访问硬件/驱动程序
|
||
|
||
MCAL 的 `BswModuleEntities`（驱动程序）应通过以下方式访问：
|
||
|
||
- 由**调用方所在 BSW 分区内的** BSW 功能集群访问。例如，FLS 驱动程序属于"Memory" BSW 功能集群。在 NVM 访问的情况下，NVM 模块可能作为 master/satellite 实现在**所有核心上提供**。**Master** 仅在**单个核心上使用** FLS 驱动程序。因此，**FLS 驱动程序**在该核心上**可用**。
|
||
- 应用所需的**任何 BSW** 都应在**调用方所在 BSW 分区内**访问。例如，I/O 驱动程序如 DIO、ADC 和 PWM 可由**任何核心/分区**使用。这些**要么**实现为 **master/satellite 实现**，要么基于对硬件的**原子访问**实现为**每个核心的冗余实现**。
|
||
|
||
MCAL 多核方法的详细实现在 2.5 节 MCAL Distribution 中描述。
|
||
|
||
#### 2.2.6 模块的并发安全实现
|
||
|
||
BSW 模块的并发安全性以及这些模块实现的函数**可能**通过不同的机制实现。
|
||
|
||
通常，根据（`TPS_BSWMDT_04103`）可以区分以下**可重入性级别**。`BswModuleEntity` 的具体级别在可选属性 `reentrancyLevel` 中定义：
|
||
|
||
- **多核可重入（Multi-core reentrant）**：接口的**无限并发执行**是可能的，包括在多核系统上的**抢占和并行执行**。此级别可以**通过进入临界区时的互斥**或**通过不存在此类区域**来实现，例如如果没有共享资源（包括硬件和内存）。
|
||
- **单核可重入（Single-core reentrant）**：接口在单核系统上的**伪并发执行**（即抢占）是可能的。这是 **AUTOSAR 4.0.3** 定义的**最高**可重入性级别。因为它**未明确涵盖**多核系统，所以**另外**引入了"并发安全"。此级别通常可以**通过与"并发安全"相同的机制**来确保，但它们必须确保**跨核心边界**工作。
|
||
- **不可重入（Non-reentrant）**：此接口的并发执行**不可能**。
|
||
|
||
如果一个**非并发安全**的模块在不同分区中被调用，则**不能保证**该模块将**保持其期望的行为**。在这种情况下，应通过**模块的使用**来确保正确的行为，例如**调用方**通过使用**独占区域**来**防止并行执行**。
|
||
|
||
### 2.3 并行 BSW 执行的 SchM 接口
|
||
|
||
本章描述概念"Enhanced BSW allocation"所需的 SchM 扩展。
|
||
|
||
**基础软件调度器（SchM）**负责处理 BSW 模块之间的**分区间通信**。这在概念上类似于 RTE 处理 SW-C 之间的分区间通信。但是，由于 BSW 模块在 AUTOSAR 架构中位于 RTE 之下，因此**通信必须在 RTE 可用之前可用**。因此，出于**性能原因**，BSW 模块使用 SchM 进行通信。
|
||
|
||
对于跨多个分区的 BSW 模块的分布，**SchM 应实现**方法 `SchM_Call`、`SchM_Result`、`SchM_Send` 和 `SchM_Receive`，这些方法用于**处理服务调用和回调**，以及**向发送方-接收方连接写入数据**和**从中读取数据**。有关这些函数签名的详细信息，请参阅 2.2.3 节，其中从 BSW 开发人员的角度描述了 SchM 扩展。
|
||
|
||
SchM 可以使用 `IocSend`（对 OS 的直接调用）在分区间通信中**发送数据**。在启动期间，**其他 RTE 内部机制可能不可用**。
|
||
|
||
**Inter-OS-Application Communicator（IOC）**应配置为**为所有跨分区边界的客户端-服务器和发送方-接收方连接**提供具有**唯一确定的 `<Id>`** 的 `IocSend_<Id>` 函数。
|
||
|
||
类似地，SchM 应使用 `IocReceive` 从分区间通信**接收数据**，并且 IOC 应提供相应的 `IocReceive_<Id>` 函数。
|
||
|
||
以下框架包含一些**伪代码片段**，展示如何使用 IOC 进行分区间通信：
|
||
|
||
```c
|
||
void some_BSW_function() {
|
||
char *str = "some text";
|
||
SchM_Send_Data_Src_DstN(str);
|
||
}
|
||
|
||
Std_ReturnType SchM_Send_Data_Src_DstN(char *str) {
|
||
IocSend_1(str, 5);
|
||
ActivateTask(TASK1);
|
||
}
|
||
|
||
Std_ReturnType SchM_Receive_Data_Src_DstN(char *str) {
|
||
IocReceive_1(str);
|
||
}
|
||
|
||
TASK(TASK1) {
|
||
char data[20];
|
||
SchM_Receive_Data_Master_Sat1(data);
|
||
/* do something with data */
|
||
}
|
||
```
|
||
|
||
### 2.4 分区系统中的基础软件配置
|
||
|
||
本节面向**集成商**。
|
||
|
||
#### 2.4.1 任务映射
|
||
|
||
BSW 模块的并行化向 AUTOSAR 元模型引入了几个**新的 BswEvent 子类**。这些类在图 3 中显示。每个 `BswEvent`（包括 `BswEvent` 子类的实例）被分配给一个 `BswSchedulableEntity`，该实体在事件发生时**启动**。
|
||
|
||
> **图 3：通过调用 BSW 函数触发的事件**
|
||
>
|
||
> （元模型示意图：`BswEvent` 的子类（如 `BswOperationInvokedEvent`、`BswTimingEvent`、`BswScheduleEvent`）映射到 `BswSchedulableEntity`）
|
||
|
||
实体**分区特定行为**的更细粒度描述可以通过使用 `BswDistinguishedPartitions` 来描述，如图 4 所示。`BswDistinguishedPartition` 是分区的**抽象表示**，它允许将**特定的 `BswEvent`、`BswModuleCallPoint` 或 `BswVariableAccess` 映射到一组抽象分区**。此时分区的表示是**抽象的**，因为它是 BSW 模块描述的一部分（根据模块描述模板），而**具体分区**在 ECU 配置时确定。
|
||
|
||
例如，如果**在分区 1 中运行的模块实体**通过 `VariableDataPrototype` 向**在分区 2 和 3 中运行的同一实体**提供数据，则 `BswModuleEntity` 聚合一个**具有到分区 1 的上下文限制的 `dataSendPoint`**，以及一个**具有到分区 2 和 3 的上下文限制的 `dataSendPoint`**。
|
||
|
||
> **图 4：使用 BswDistinguishedPartitions 对实体的分区特定属性建模**
|
||
>
|
||
> （元模型示意图：`BswModuleEntity` 包含 `BswDistinguishedPartition`，每个分区有对应的 `BswEvent`、`BswModuleCallPoint`、`BswVariableAccess`）
|
||
|
||
事件处理的**实际分区**由其**任务映射**确定。
|
||
|
||
图 5 显示了 AUTOSAR 元模型中的相应摘录。
|
||
|
||
> **图 5：将 `OperationInvokedEvents` 映射到任务**
|
||
>
|
||
> （元模型示意图：`RteBswEventToTaskMapping` 通过 `RteBswEventRef` 引用 `BswEvent`，并通过 `RteBswMappedToTaskRef` 引用 `OsTask`）
|
||
|
||
`RteBswEventToTaskMapping` 引用一个 `BswEvent`（间接通过其 `RteBswEventRef`）和一个 `OsTask`（也间接通过其 `RteBswMappedToTaskRef`）。该任务又映射到一个分区，分区映射到 µC 核心，**该核心负责处理事件**。将事件映射到任务是**可选的**；如果事件**未映射到任务**，则**在其原始分区中处理**。如果没有防止并发执行的特殊机制适用，则事件的**非强制性映射**到任务的**先决条件**是：
|
||
|
||
- 如果 BSW 实体**在多个 BSW 分区之间共享**，则该实体需要**并发安全**
|
||
- 如果它**仅在一个 BSW 分区中独占可用**，则它需要**至少是可重入的**
|
||
|
||
**请注意**，当前**不允许**将 SW 组件的 `RunnableEntities` 映射到**多个分区**（`SWS_Rte_07347`）。对于 BSW，**可以**通过使用引用同一实体的**不同 `BSWEvents`** 将**同一模块实体**映射到**不同的任务和分区**。
|
||
|
||
#### 2.4.2 Master 和 Satellites 的一般配置
|
||
|
||
应在多个分区中可用的模块可以实现为 **master 和 satellites**。在这种情况下，**同一模块的 master 和所有 satellites** 共享**相同的代码**（但可能实现核心相关的行为）和**相同的配置**。因此，**master 和其 satellites** 在其配置方面被视为**一个模块实体**。
|
||
|
||
Master 和 satellites 之间的通信**不应标准化**。它被认为是**模块内部的**，对其他模块**不可见**。但是，由于**建议**对内部通信使用 **SchM 机制**，因此需要在 BSWMD 中**配置非标准化的客户端-服务器条目和数据访问**以连接 master 和 satellite。
|
||
|
||
#### 2.4.3 配置 BswM（按分区）
|
||
|
||
在分布式 BSW 系统中，**每个分区**都有一个 **BSW 模式管理器（BswM）**（但**每个核心**有一个 OS 和 EcuM，只要**每个核心一个 BSW 分区**就相同）。这些 BswMs 中的每一个都可以**独立配置**。BswM 主要与**同一分区**上的**状态管理器**（例如 ECU 状态管理器和总线状态管理器）交互。
|
||
|
||
BswM 还负责**同一分区中运行的 BSW 模块的初始化和关闭**。因此，其配置**取决于 BSW 模块到分区的映射**。
|
||
|
||
BswMs 的配置在容器 `BswMGeneral` 中**拆分**，其中包含所有 BswM 实体的**共享配置参数**和 `BswMConfig` 容器，其中**为每个 BswM 实体定义了一个 `BswMConfig`**。因此，BswM 到其分区的映射在相应的 `BswMConfig` 容器中定义，该容器具有指向相应分区的 `BswMPartitionRef`。**BswM 配置到分区的映射**确保可以为每个分区确定 BswM 的正确配置。
|
||
|
||
用于将 BSW 模块分配到多个分区的 **BswM 配置的附加扩展**包括：
|
||
|
||
- 容器 `BswMAvailableActions` 中的引用 `BswMRequestRemoteMode`。此操作表示对**不同分区**中的 BswM 的调用，**用于传播模式请求**。
|
||
- 容器 `BswMModeRequestSource` 中的引用 `BswMBswMModeRequest` 和 `BswMBswMModeSwitchNotification`。`BswMBswMModeRequest` 表示模式请求的**源**是**在不同分区中运行的 BswM**（`ECUC_BswM_00980`，参见 [5]）。`BswMBswMModeSwitchNotification` 表示**另一个 BswM 已切换模式**。
|
||
- 由 BswM 实体处理的**操作列表**中列出的**所有函数**必须在**此 BswM 运行的分区中可用**。
|
||
|
||
#### 2.4.4 配置 EcuM（按核心）
|
||
|
||
在分布式 BSW 系统中，**每个核心**都有一个 EcuM（即使该核心上有多个 BSW 分区）。换句话说，**在每个核心上应有且仅有一个运行 EcuM 的分区**。**运行 EcuM 的分区**由 `EcuMFlexEcucPartitionRef` 确定，该引用在 EcuM 配置的容器 `EcuMFlexUserConfig` 中指定。
|
||
|
||
在**顺序启动核心的**架构上，有一个**指定的 master 核心**，其中**引导加载程序**通过 `EcuM_init` 启动 **master EcuM**。Master 核心中的 EcuM 启动**一些驱动程序**，确定**后构建配置**，并**启动所有剩余的核心**及其**所有 satellites EcuMs**。
|
||
|
||
在**所有核心同时启动的**架构上，`EcuM_init` 函数内的**核心相关分支**可用于实现**核心特定行为**。这又可用于**识别 EcuM master**（在 master 核心上运行），它负责**在 slaves 上**进行 EcuM 初始化。
|
||
|
||
### 2.5 MCAL 分布
|
||
|
||
> **注意**：所有"MCAL 多核分布"的概念部分以及 2.5 节 MCAL 分布章节均处于"草案（draft）"状态。
|
||
|
||
#### 2.5.1 介绍
|
||
|
||
由于需要从**多个核心和分区**提供对硬件功能的访问，**MCAL 功能**需要被提供到**需要它的核心**以及**提供该功能有用的**位置。因此，**MCAL 模块的分布**不是**对所有 MCAL 模块都相同**，而是需要遵循前面章节中描述的**功能集群**的需求。以下章节将指导**所需多核能力的分类**，介绍**分配给各个模块的相应多核类型**。此外，应展示一些**基本设计模式**以允许实现所需的功能。
|
||
|
||
**应注意**，**多核 MCAL 的引入**需要引入**异步行为的接口**以在多个核心上实现**非阻塞并行执行**。这些被引入到受影响的 AUTOSAR 模块的各个 SWS 中，在下面的章节中不再提及。
|
||
|
||
#### 2.5.2 使用假设
|
||
|
||
要应用 MCAL 分布，**应给出若干使用假设**，以定义 MCAL 环境的**边界条件**：
|
||
|
||
1. 需要**多分区（多应用）AUTOSAR 操作系统**来支持本概念中定义的用例。
|
||
2. 硬件实现**应允许将外设至少映射到核心**。在将来，**预期**硬件实现**允许映射到核心和分区**。
|
||
3. **应可能**将**硬件和软件中断**路由到**一个分区**或**至少一个专用核心**（供 OS 进一步路由）。
|
||
4. MCAL 驱动程序**所需的服务模块**应通过**能够接受对其服务 API 的调用**来支持**多核用例**——分别在**任何核心上**。**相关服务**是：
|
||
- Det
|
||
- Dem
|
||
- EcuM
|
||
- Os
|
||
- SchM
|
||
- NvM
|
||
|
||
此外，**假设**使用了**多核微控制器**，但这不是强制性的，因为该概念**无论单核还是多核实现**都提供**相同的服务 API 集**。此外，**可以实现**具有空间和时间隔离的**混合 ASIL 系统**，其中**可映射的 MCAL 元素**被分配给**不同的分区**，**尊重**所得到的 MCAL 实现的**安全完整性级别**。
|
||
|
||
**示例**是**一个核心上具有两个分区**的**系统**，它们**都访问 MCAL**。如果没有此概念，**驱动程序必须独占属于两个分区之一**，使**分区跨越执行**的**时间成本高昂**。有了新概念，**MCAL 元素**可以**单独分配给两个分区**，从而**消除了跨分区边界**的需要。
|
||
|
||
#### 2.5.3 约束
|
||
|
||
为了实现该概念，**定义了进一步的约束**以防止**低效**和**多核阻塞**的实现。在这个意义上，**特别重要的是**考虑到**在单核上实现独占区域已经不够了**，**还需要在资源需要跨多个分区（分布在多个核心上）共享的情况下确保访问序列化**。
|
||
|
||
1. **单核上的访问序列化**：对于单核系统，并发问题已得到很好的理解，并通过**独占区域**缓解，独占区域**限制**对**一个进程**的并发访问。这通常通过**锁定中断**、**使用 OS 资源**或**创建非抢占式调度**来完成。这有效地意味着**不同进程的访问序列化**。
|
||
2. **跨核心的访问序列化**：由于**独占区域**仅具有**核心范围的作用域**，因此它们**不足以防止多核环境中的并发访问**。但是，一旦需要访问**相同的资源**（例如通过访问服务 API、处理 ISR 和 main functions），就需要引入**跨核心手段**。除了**使用原子资源**外，最坏的（因为阻塞的）将是**通过使用信号量（spinlock）** 引入**跨核心独占区域**，这会**阻塞多个核心**。相反，**更好的选择**将是基于**专有的、精简的 IOC** 的**经典 master-satellite 实现**。
|
||
|
||
**总结**，**独占区域**可以在技术上扩展为**多核作用域**，但是将实现这些，但是这将**导致显著的性能缺点**，因为**两个甚至多个核心将被阻塞**。因此，该概念将描述**与本章中定义的多核类型一致的最佳保护手段的相应设计模式**。
|
||
|
||
#### 2.5.4 MCAL 用户的定义
|
||
|
||
需要考虑以下**不同的 MCAL 用户**：
|
||
|
||
- 通过 IoHwAbstr 的应用 SWC（RTE 上方）
|
||
- RTE 下方的 CDD 或 BSW 模块
|
||
|
||
因此，**MCAL 多核支持需要独立于 RTE** 提供，以涵盖**两个用例**。
|
||
|
||
#### 2.5.5 多核能力分类标准
|
||
|
||
以下段落给出了**统一**对**不同视角的所需多核能力**的理解。
|
||
|
||
##### 2.5.5.1 标准 1 – API 可用性
|
||
|
||
要分类 MCAL 模块的多核能力，**首先必须理解**用户对"服务 API 应从**哪个核心可访问**"的期望。从这个定义可以推导出以下两种情况：
|
||
|
||
- **1a**：本地服务 API（**仅在一个核心上可执行**）
|
||
- **1b**：全局（分布式/共享）服务 API（**在任何核心上可执行**）
|
||
|
||
##### 2.5.5.2 标准 2 – MCAL 内核执行上下文
|
||
|
||
其次，需要了解 **MCAL 模块内核应理想地驻留/位于何处**，以**限制**由于来自**多个核心**对 HW 外设的**并发访问**而对**总线和桥上的冲突**的**副作用**。定义**本地内核**并不排除**多重性**，例如提供**多个内核**处理**独立的外设模块**或**核心单独的**资源。定义了以下情况：
|
||
|
||
- **2a**：一个本地内核（**仅在一个核心上可执行**）
|
||
- **2b**：全局（分布式/共享）内核（**在任何核心上可执行**）
|
||
|
||
##### 2.5.5.3 标准 3 – 硬件元素映射
|
||
|
||
作为第三点，需要考虑**可映射元素的范围**（参见 4.1.3 节），包括其**数据**到**相应的内核实例**。考虑到这一点，根据**将 HW 外设映射到核心**的硬件能力**扩展**了分类。这里**不仅**要考虑**纯硬件能力**，还要考虑**相应映射的性能影响**。定义了以下情况：
|
||
|
||
- **3a**：一个 HW 元素**仅可映射到一个核心**
|
||
- **3b**：一个 HW 元素**可映射到多个核心**
|
||
|
||
##### 2.5.5.4 多核能力分类总结
|
||
|
||
下表总结了**所显示标准**的**所需选项范围**：
|
||
|
||
| | **仅一个核心** | **多个核心** |
|
||
|---|:---:|:---:|
|
||
| API | 1a | 1b |
|
||
| 内核执行上下文 | 2a | 2b |
|
||
| 硬件元素 | 3a | 3b |
|
||
|
||
**表 1：MC 能力标准**
|
||
|
||
#### 2.5.6 MCAL 多核类型的定义
|
||
|
||
以下段落介绍了**要应用于 MCAL 模块**的**相应多核类型**，分类**相应的多核能力**。
|
||
|
||
##### 2.5.6.1 MCAL 多核模块类型 I
|
||
|
||
MCAL 模块**仅在单个核心上可用**，**接口不是全局可用的**。
|
||
|
||
> **类型 I = 1a + 2a + 3a**
|
||
|
||
该类型被定义为**单核模块**，仅向**一个核心**提供其**服务 API**，并在该核心上**实现内核**，因为**相应的 HW 元素应仅由一个核心访问**。
|
||
|
||
> **图 6 – 类型 I**
|
||
>
|
||
> （示意图：所有元素（服务 API、ISR、main function）位于核心 0 上，HW 元素映射到核心 0。）
|
||
|
||
**类型 I 的示例**是 **FLS、MEMIF 和 FEE**。要将范围**限制在该核心**，可以应用具有**本地作用域**的相应 `SwAddrMethod`。
|
||
|
||
##### 2.5.6.2 MCAL 多核模块类型 II
|
||
|
||
MCAL 模块提供**分布式内核**，**按核心执行**，作用于**单独映射的 HW 元素**。
|
||
|
||
> **类型 II = 1b + 2b + 3a**
|
||
|
||
该类型被定义为**多核模块的特殊种类**，在**任何核心单独实例**上提供其**服务 API** 以及**控制 API（Init、DeInit 等）**。因此，**动作在触发该动作的核心上执行**。**每个核心实例**在其**自己的数据集**上操作。这对于**在可映射到一个专用核心的 HW 元素上操作的 MCAL 模块**特别有意义。**此类型的典型示例**是**通信驱动程序**，如 **CAN、ETH 和 FR**。
|
||
|
||
> **图 7 – 类型 II**
|
||
>
|
||
> （示意图：每个核心（核心 0、核心 1、核心 2）都有自己的实例。HW 元素（网络）映射到不同的核心。）
|
||
|
||
##### 2.5.6.3 MCAL 多核模块类型 III
|
||
|
||
MCAL 模块提供**分布式内核**，**按核心执行**，作用于**全局可用的 HW 元素**。
|
||
|
||
> **类型 III = 1b + 2b + 3b**
|
||
|
||
该类型被定义为**多核模块的特殊种类**，在**所有核心上**提供其**服务 API**，但**以全局方式实现内核**，使得**动作在触发该动作的核心上执行**，**直接访问全局可用的 HW 元素**，**可映射到任何核心**（包括**相关数据**）。**相应的控制 API（Init、DeInit 等）** **仅在单个核心上可用**。**特别是在 HW 可以原子访问的情况下**，**此模块类型被认为是有用的**。**最突出的示例**是 **DIO 驱动程序**。
|
||
|
||
> **图 8 – 类型 III**
|
||
>
|
||
> （示意图：每个核心（核心 0、核心 1、核心 2）都有自己的实例。HW 元素（端口）映射到多个核心（原子访问）。）
|
||
|
||
##### 2.5.6.4 MCAL 多核模块类型 IV
|
||
|
||
MCAL 模块提供**在任何核心上可用的接口**和**单个核心上的一个内核**，**通过仅一个核心访问可映射元素**。
|
||
|
||
> **类型 IV = 1b + 2a + 3a**
|
||
|
||
该类型被定义为**多核模块的特殊种类**，**跨所有核心**提供其**服务 API**，但**仅在一个核心上实现内核**，执行**访问可映射的 HW 元素**。**内核**可以**使用 `SwAddrMethod` "local" 分配**。**这种情况**需要**专有的多核手段**来执行**对内核的请求的同步（序列化）**。**此类多核手段**可以**是基于轮询或中断的高效消息传递**、**与信号量（用于低复发）相结合的多缓冲**。**类型 IV MCAL 模块的相应控制 API（Init、DeInit 等）****仅在内核所在的核上可用**，并具有**相应的本地作用域**。**此类 BSW 模块的示例**是 **ADC、PWM、ICU 和 OCU**。这是**经典的 master-satellite 实现**。
|
||
|
||
> **图 9 – 类型 IV**
|
||
>
|
||
> （示意图：服务 API 在多个核心上可用，但内核仅在核心 0 上。Satellite 路由请求到 master。）
|
||
|
||
##### 2.5.6.5 MCAL 多核模块类型 V
|
||
|
||
MCAL 模块提供**在任何核心上可用的接口**和**多个核心上的多个内核**，**通过相应核心单独访问可映射元素**。
|
||
|
||
> **类型 V = 1b + 2a + 3b**
|
||
|
||
**此多核模块**是**类型 IV 的扩展**，可以通过**允许完全独立处理外设模块或子模块的硬件实现**来实现。这是**一个相当学术性的星座**，**未给出示例图**。
|
||
|
||
##### 2.5.6.6 MCAL 多核类型总结
|
||
|
||
下表总结了**所定义的 MCAL 多核模块类型**的范围：
|
||
|
||
| | API（1a 仅一个核心） | API（1b 多个核心） | 内核（2a 仅一个核心） | 内核（2b 多个核心） | 硬件（3a 仅一个核心） | 硬件（3b 多个核心） |
|
||
|---|:---:|:---:|:---:|:---:|:---:|:---:|
|
||
| 类型 I | X | | X | | X | |
|
||
| 类型 II | | X | | X | X | |
|
||
| 类型 III | | X | | X | | X |
|
||
| 类型 IV | | X | X | | X | |
|
||
| 类型 V | | X | X | | | X |
|
||
|
||
**表 2 – MC 能力分类**
|
||
|
||
#### 2.5.7 将 MCAL 模块映射到多核类型
|
||
|
||
该概念**通常应应用于**以下表中列出的**所有 MCAL 驱动程序**：
|
||
|
||
| 模块缩写 | MSN | SW 层 |
|
||
|----------|-----|-------|
|
||
| Adc | ADC Driver | I/O Drivers |
|
||
| Can | CAN Driver | Communication Drivers |
|
||
| CanTrcv | CAN Transceiver Driver | Communication HW Abstraction |
|
||
| CorTst | Core test | Microcontroller Drivers |
|
||
| Dio | DIO Driver | I/O Drivers |
|
||
| Eth | Ethernet Driver | Communication Drivers |
|
||
| EthSwt | Ethernet Switch Driver | Communication HW Abstraction |
|
||
| EthTrcv | Ethernet Transceiver Driver | Communication HW Abstraction |
|
||
| Fr | FlexRay Driver | Communication Drivers |
|
||
| FrTrcv | FlexRay Transceiver Driver | Communication HW Abstraction |
|
||
| Gpt | GPT Driver | Microcontroller Drivers |
|
||
| Icu | ICU Driver | I/O Drivers |
|
||
| Lin | LIN Driver | Communication Drivers |
|
||
| LinTrcv | LIN Transceiver Driver | Communication HW Abstraction |
|
||
| Mcu | MCU Driver | Microcontroller Drivers |
|
||
| Ocu | OCU Driver | I/O Drivers |
|
||
| Port | Port Driver | I/O Drivers |
|
||
| Pwm | PWM Driver | I/O Drivers |
|
||
| RamTst | RAM Test | Memory Drivers |
|
||
| Spi | SPI Handler Driver | Communication Drivers |
|
||
| Ttcan | TTCAN Driver | Communication Drivers |
|
||
| WEth | Wireless Ethernet Driver | Wireless Comm. Drivers |
|
||
| WEthTrcv | Wireless Ethernet Transceiver | Wireless Comm. HW Abstraction |
|
||
|
||
**表 3 – 相关模块**
|
||
|
||
要识别**标准化 MCAL 模块的多核类型和映射关系**，**首先**需要识别**模块应访问的 HW"自然元素"**。**此外**，需要识别**可映射元素**，即**用户希望从各个核心访问的**元素。从定义中，可以推导出**可映射元素到核心的关系**。这里**可映射元素（ME）**与**它可以映射到的核心数（Core）**的关系如下所示。作为最终结论，显示了**相应的多核类型**，需要推导出**相应的 AUTOSAR 模块实现的最终设计模式建议**。
|
||
|
||
| 驱动程序 | HW"自然"元素 | 可映射元素（ME） | 关系（ME : Core） | 多核类型 |
|
||
|----------|---------------|------------------|-------------------|----------|
|
||
| Adc | HW Units | Channel group | n:m | 类型 IV |
|
||
| Can | CAN Controller | Network | n:1 | 类型 II |
|
||
| CanTrcv | Transceiver ASIC | Network | n:1 | 类型 II |
|
||
| CorTst | Core | Core | 1:1 | 类型 II |
|
||
| Crypto | HW based: HSM | Job | n:1 | 类型 II |
|
||
| Crypto | SW based: Job | - | - | - |
|
||
| Dio | Port / Channel（HW 依赖） | Port / Channel | n:m | 类型 III |
|
||
| Eth | MAC | Network | n:1 | 类型 II |
|
||
| EthSwt | Switch ASIC | Network | n:1 | 类型 II |
|
||
| EthTrcv | Transceiver ASIC | Network | n:1 | 类型 II |
|
||
| Eep | EEPROM Driver | MCAL Module | 1:1 | 类型 I |
|
||
| Fls | Flash | MCAL Module | 1:1 | 类型 I |
|
||
| FlsTst | Flash Test | MCAL Module | 1:1 | 类型 I |
|
||
| Fr | Controller | Network | n:1 | 类型 II |
|
||
| FrTrcv | Transceiver ASIC | Network | n:1 | 类型 II |
|
||
| Gpt | Timer Resource | Local Timer | n:1 | 类型 II |
|
||
| Gpt | Timer Resource | Global Timer | 1:m | 类型 III |
|
||
| Icu | Timer / Edge Detector | ICU Channel | n:m | 类型 IV |
|
||
| Lin | Lin Channel | Network | n:1 | 类型 II |
|
||
| LinTrcv | Transceiver ASIC | Network | n:1 | 类型 II |
|
||
| Mcu | Core | Core, System | 1:1 | 类型 II |
|
||
| Ocu | Timer | OCU Channel | n:m | 类型 IV |
|
||
| Port | Port / Channel（HW 依赖） | Port / Channel | n:m | 类型 III |
|
||
| Pwm | Timer | PWM Channel | n:m | 类型 IV |
|
||
| RamTst | Core | Core, System | n:1 | 类型 II |
|
||
| Spi | Channel（for individual sequences） / Device | Spi Device | n:m | 类型 IV |
|
||
| Ttcan | CAN Controller | Network | n:1 | 类型 II |
|
||
| Wdg | Watchdog Driver | Watchdog Resource | n:1 | 类型 II |
|
||
| WEth | MAC | Network | n:1 | 类型 II |
|
||
| WEthTrcv | Transceiver ASIC | Network | n:1 | 类型 II |
|
||
|
||
**表 4 – 相关模块**
|
||
|
||
作为结论，**属于类型 I 的驱动程序**（因此**不受此概念影响**）在下面列出。对于每个驱动程序，都给出了**为什么认为它不相关**的理由：
|
||
|
||
- **Eep（EEPROM 驱动程序）**：内存服务（NvM）**绑定到一个核心**。因此，**不需要驱动程序的**多核功能。
|
||
- **Fls（Flash 驱动程序）**：内存服务（NvM）**绑定到一个核心**。因此，**不需要驱动程序的**多核功能。
|
||
- **FlsTst（Flash 测试）**：Flash 测试**不提供**额外（应用）用例的潜力。其**目的是**检查**微控制器的闪存功能**作为一种服务。**通常没有使用此模块实现的 SW 功能**。
|
||
|
||
**注意**：**对于 Wdg 的未来实现**，**显然**要在多核系统上**支持多个看门狗**，因此**分配了多核类型 II**，即使**今天**它**大多是**根据**类型 I 的单核实现**。
|
||
|
||
#### 2.5.8 分离策略和元素映射
|
||
|
||
MCAL 多核分布的**挑战**是**如何处理全局资源**。这些是：
|
||
|
||
- 全局数据
|
||
- 共享特殊功能寄存器
|
||
- 外设寄存器
|
||
|
||
根据前面章节中给出的**约束**，**显然两个进程上下文**将**同时**访问**相同的全局资源**。这可能导致：
|
||
|
||
- **数据损坏**（特别是具有复杂（非原子）数据类型的问题）：
|
||
- 一部分数据**由第一个进程写入**；另一部分**由第二个进程写入**
|
||
- 仅**部分数据被写入**，然后**写入进程被抢占**，留下**损坏的数据集**
|
||
- **读-修改-写数据的竞争**：
|
||
- 由进程**写入的数据**（例如值的递增）由于**两个交错的读-修改-写操作**而**丢失**
|
||
|
||
在 **MCAL 驱动程序**中，**最多有三个元素**可以具有**自己的进程上下文**：
|
||
|
||
- **Main function**：在任务上下文中**映射和执行**
|
||
- **服务 API**：在一个或多个任务或 ISR 的上下文中**调用**
|
||
- **中断服务例程（ISR）**：在中断上下文中调用
|
||
|
||
**特别是服务 API**可能在**多个进程上下文**中被调用。这取决于**实现该 SW 的架构和功能**。
|
||
|
||
本章描述了**根据可映射元素**（对应于**功能元素**）的**多核能力**，这些元素**在本文件前面**提到并且**应注释到 MCAL 驱动程序**。此外，本章**定义了实现可映射元素所需的**基本分离策略**。
|
||
|
||
#### 2.5.9 分离策略
|
||
|
||
##### 2.5.9.1 硬件级分离
|
||
|
||
**实现多核实现**的**理想方式之一**（根据**定义的多核类型**）是**通过硬件级的分布/分离**。**理想情况**是**硬件支持**对**物理外设**的**分布/分离**，即：将外设模块**映射到各个核心**。
|
||
|
||
**注意**：**此硬件级分离**要求**各个外设的独立寄存器集**，可以从**一个核心**控制，**而不会影响另一个**，如图 10 所示。
|
||
|
||
> **图 10 – 独立寄存器集硬件级分离**
|
||
>
|
||
> （示意图：两个外设元素各有独立的寄存器集，可由不同核心独立访问。）
|
||
|
||
如图 10 所示，**各个硬件/外设元素后面的寄存器集是相互独立的**，因此可以视为**可映射元素**。**可映射元素**意味着，**一个元素可以独占映射到某个核心**。**如果寄存器集元素允许原子访问**，**则**也**可以使用此分离方法**支持**映射到多个核心**。
|
||
|
||
##### 2.5.9.2 软件级分离
|
||
|
||
**并非所有微控制器**都提供**严格分离的寄存器集**，或分别提供**硬件元素（外设、核心、内存）的功能**。通常，**这些硬件元素**需要**一组公共寄存器**来**控制无法原子访问的功能**。**这是几个外设模块和外设功能的情况**。因此，**需要通过软件进行分离**。
|
||
|
||
> **图 11 – 共享寄存器集可在软件级分离**
|
||
>
|
||
> （示意图：两个外设元素共享寄存器集，需要通过软件分离。）
|
||
|
||
**为此**，**需要应用软件设计模式**，在最坏情况下**可以是**在 MCAL 模块之间**访问相同硬件元素的**自旋锁（信号量）**。**独占区域的性能影响**取决于**应应用它的硬件元素**以及**自旋锁的实现**。因此，例如**仅在启动或关闭控制器期间偶尔写入的**硬件元素与**频繁访问的"业务"寄存器**相比，**影响要小得多**。
|
||
|
||
> **图 12 – 软件级可分离模块示例**
|
||
>
|
||
> （示意图：两个核心通过自旋锁保护对共享寄存器的访问。）
|
||
|
||
**对共享寄存器保护的另一种解决方案**是**通过最终将可映射元素的范围更改为允许独占映射到一个核心的下一个更高硬件元素**来**将对一个核心的访问限制为仅一个核心**。**请参考图 11**。**为此**，**对硬件元素的所有访问**都由**一个核心**协调，而**所有核心**都**使用消息传递系统**（如 IOC，但**针对 MCAL 需求进行了优化**）**传输其请求**。**此用例**要求**为处理此类硬件元素的 MCAL 模块实现的所有服务 API**都表现为**异步**，**以便**没有核心**被另一个核心阻塞**。如上所述**对于自旋锁策略**，**实现对性能有很大影响**，**如果实现错误**。
|
||
|
||
> **图 13 – 软件级分离替代解决方案**
|
||
>
|
||
> （示意图：通过 IOC 进行消息传递，所有请求都集中到一个核心。）
|
||
|
||
#### 2.5.10 元素的映射
|
||
|
||
##### 2.5.10.1 单核模块作为可映射元素
|
||
|
||
根据**多核类型 I**，**可映射元素**是**MCAL 模块本身**。**使用此能力**，**MCAL 驱动程序不提供任何多核特定的实现**，因此**不启用新的用例之一**。**其原因**是**使用的硬件元素**不允许**任何类型的并发访问**，**而无需高度复杂的保护策略**。
|
||
|
||
**然而**，**该概念会影响此 MCAL 驱动程序的映射**，因为**需要将整个驱动程序映射到一个核心**。这是通过**将其周期性 main function** 和/或**中断例程**（**如果有的话**）**映射到恰好一个 OS Application** 来完成的。**通过这样做**，**驱动程序**在**分配此 OS Application 的核心上独占可用**。**其结果是**，**MCAL 驱动程序的范围**变为**本地**。**此能力**由**任何标准的单核实现**满足。
|
||
|
||
> **图 14 – 可映射元素 – 单核模块**
|
||
>
|
||
> （示意图：所有核心绑定元素（服务 API、ISR、main function）都在同一核心上访问本地数据。）
|
||
|
||
图 14 显示了**此 MCAL 模块的简化模型**。**所有核心绑定元素**（服务 API、ISR 和 main function）都**可以访问相应的数据**（具有**本地作用域**）和**微控制器寄存器**（**可映射到此核心**）。**没有关于以下方面的分离**：
|
||
|
||
- 数据（RAM、寄存器）
|
||
- 处理（Main functions）
|
||
|
||
**所有可映射的 µC 元素**（例如 Timer channels）都由**相同的 main function 处理**；**所有服务 API 都可以控制所有 µC 元素**。**其结果是**，**服务 API 只能由一个核心调用**。
|
||
|
||
**得到的映射规则**是：**模块应仅映射到一个核心**。**因此**，**相关硬件元素**也**仅映射到同一核心**。
|
||
|
||
##### 2.5.10.2 独立硬件元素作为可映射元素
|
||
|
||
**可映射元素**是**独立硬件元素**，例如可以**独占映射到一个核心**（**因此**映射到**一个 MCAL 模块的实例**）的 **HW 外设**（例如 CAN 控制器、以太网控制器）、**核心或内存**。**此可映射元素**是**实现所述多核类型 II 所必需的**，**也是多核类型 IV 所必需的**，**请参考 MCAL 多核模块类型 II**。
|
||
|
||
**作为结论**，**相关的 ISR 和服务 API** 也**映射到同一核心**。**例如**，**如果外设**具有**两个独立的外设模块**，即元素（例如 CAN 网络），**一个**映射到**核心 1**，**另一个**映射到**核心 2**。**每个核心**仅**访问与其外设元素相关的寄存器集**。
|
||
|
||
**同样适用于 MCAL 驱动程序的数据**，**这些数据现在**处于**相应驱动程序实例的本地作用域**中。**因此**，**如果不能将数据 1:1 映射到外设元素**，**则必须**按**元素分别按核心**对**数据进行分离**。
|
||
|
||
> **图 15 – 可映射元素 – 独立硬件**
|
||
>
|
||
> （示意图：核心 1 访问 CAN 网络 1，核心 2 访问 CAN 网络 2。每个核心都有独立的数据和寄存器集。）
|
||
|
||
**如果存在不需要独占访问的共享数据和/或寄存器**，**此原则仍然适用**。**例如**，**全局驱动程序状态**可以**原子读取**。**同样适用于**可以**无副作用读取的状态寄存器**。
|
||
|
||
**从行为的角度来看**，**实现此原则的 MCAL 模块**似乎**被多次实例化**，**每个实例**包括**可映射元素的子集**，但**使用全局可用的公共代码**。
|
||
|
||
**得到的映射规则**是：**独立硬件元素应仅映射到一个核心**。**因此**，**在该硬件元素上操作的 MCAL 模块实例**也**映射到同一核心**。
|
||
|
||
##### 2.5.10.3 原子硬件元素作为可映射元素
|
||
|
||
**此特殊情况下的可映射元素**是**独立硬件元素**，例如**可以使用硬件总线的本机访问宽度原子访问的** HW 外设功能**（例如 32 位微控制器的 32 位）。**这允许**映射到**多个核心**，**而无需关心并发访问**（例如 DIO）。**因此**，**此可映射元素**是**实现多核类型 III 所必需的**，在 **MCAL 多核模块类型 III** 节中描述。
|
||
|
||
> **图 16 – 可映射元素 – 原子硬件**
|
||
>
|
||
> （示意图：原子硬件元素（DIO 通道）映射到多个核心，支持并发原子访问。）
|
||
|
||
**对于这种可映射元素**，**通常有一个简单的实现可用**，**不实现 main function**，因为**访问由服务 API 直接完成**。**如果使用数据**，**则需要**访问可以**与可映射硬件元素类似地原子完成**。
|
||
|
||
**得到的映射规则**是：**原子硬件元素可以映射到任何甚至多个核心**。**因此**，**MCAL 模块**也**映射到硬件元素映射到的核心**。
|
||
|
||
##### 2.5.10.4 多核模块作为可映射元素
|
||
|
||
**在这种情况下**，**可映射元素**又是**MCAL 模块**，它**可以映射到至少一个或多个核心**。**MCAL 模块本身**根据**多核类型 IV** 实现，并**应用**所示的**软件分离策略之一**。**然而**，**服务 API**在**MCAL 模块映射到的所有核心上可用**。**MCAL 模块的 ISR** **理想地映射**到**用户正在运行的核心**。**典型的 MCAL 模块**是**任何实现非原子硬件元素的核心所需的 IO 驱动程序**，如 **ADC、PWM、ICU、OCU 和 SPI**。
|
||
|
||
**得到的映射规则**是：**多核 MCAL 模块可以映射到任何甚至多个核心**。**因此**，**所有硬件元素**都**映射到使用 MCAL 模块的所有核心**。
|
||
|
||
#### 2.5.11 示例
|
||
|
||
**作为结论**，**MCAL 分布**将**所需的服务 API** 提供给**需要它们的核心**。**这是根据多核类型和相关可映射元素完成的**。**因此**，**下面应展示一些示例**：
|
||
|
||
**示例 1：DIO 由 2 个 IoHwAb 并发访问**
|
||
|
||
> **图 17 – 示例 1 – DIO – 在不同核心上由 2 个 IoHWAb 并发访问**
|
||
>
|
||
> （示意图：核心 1 和核心 2 上的 IoHWAB 模块都可以直接调用 `Dio_WriteChannel()`。）
|
||
|
||
**在示例中**，**DIO 的通道 5** 分配给**核心 1 和核心 2**，而**通道 6** 分配给**核心 2**。**每个核心**包含一个 **IOHWAB 模块**。**两个模块**都**允许**在**其本地核心上下文**中**直接调用 `Dio_WriteChannel()`**。**限制**是**它们仅写入**分配给**同一核心的通道**。
|
||
|
||
**示例 2：DIO 由 2 个 IoHwAb 访问**
|
||
|
||
> **图 18 – 示例 2 – DIO – 在不同核心上由 CanTrcv 和 IoHWAb 访问**
|
||
>
|
||
> （示意图：核心 1 的 CAN 收发器使用 DIO，核心 2 的 IOHWAB 也使用 DIO。）
|
||
|
||
**如示例所示**，**DIO** **由核心 1 上的 CAN 收发器**使用，**同时**由**核心 2 上的 IOHWAB** 使用。**两个 DIO 用户**都**可以**在**其本地核心上下文**中**直接调用 `Dio_WriteChannel()`**。
|
||
|
||
**示例 3：DIO 由 Master\Satellite 服务访问**
|
||
|
||
> **图 19 – 示例 3 – DIO – 由 Dem Master 和 Satellite 访问**
|
||
>
|
||
> （示意图：DIO 报告 DEM 的诊断错误。DIO 调用 DEM 是 DIO 所在的核心上发出的。）
|
||
|
||
**如示例所示**，**DIO** 向 **DEM** 报告**诊断错误**。**对 DEM 的调用**在**发生错误的核心上发出**。**DIO 不负责将调用上下文更改为另一个核心**。**当然**，**这要求 DEM** **将其服务 API 提供给**相应核心/分区。
|
||
|
||
---
|
||
|
||
## 3 安全系统中的 BSW 分布
|
||
|
||
### 3.1 安全概述
|
||
|
||
**在当今的汽车中**，**几个 ECU** 可以**控制安全相关的执行器**，**取决于车辆的功能**。**示例**是**电子转向锁系统**、**自适应巡航控制系统**或**制动系统**。**如果此类系统出现错误行为**，**则可能发生危险情况**，**驾驶员不再能够以安全的方式驾驶汽车**。**为了避免此类故障**，**特定的 ECU** 必须**以系统可以以受控方式检测和应对此类故障的方式**开发。**ISO 26262** 是**描述如何执行此类 ECU 的开发以实现安全系统的标准**。**此标准**定义了**四个"汽车完整性安全等级"（ASIL）**，**对系统的风险进行分类**。**基于风险**，**推导出系统的特定（安全）要求**。**这些要求**可能与**硬件**（例如支持多通道以允许检测硬件问题）有关，**或软件**（例如控制流检查），**或两者**。**在 AUTOSAR 中**，**我们专注于软件**，**因此硬件部分将不再考虑**。**请注意**，**ASIL 始终是针对系统定义的**，**这意味着**硬件和软件，**并且**关于**软件应用软件和基础软件**。
|
||
|
||
### 3.2 AUTOSAR 中的安全解决方案
|
||
|
||
**AUTOSAR 直到 R4.1** 通过提供**此类 ECU 通常所需的不同基本机制**来**支持安全系统**。**以下列表**包含**主要的安全机制**：
|
||
|
||
- **将 SWC 分区**以支持**空间隔离**。**这意味着**可以将**不同 ASIL 的 SWC 相互分离**，并**确保 SWC 不能写入其他 SWC 的数据**。**实现**需要**硬件支持**（**内存保护或内存管理单元**）并在 **Os 模块**中实现并由 **Rte** 使用。
|
||
- **时序和控制流监控**以**监控执行实体**并**检测由阻塞或错误执行引起的故障**。**在 AUTOSAR 中**，**Os 和 WdgM** 负责此问题。
|
||
- **通过端到端保护的安全通信**在 **ECU 之间**（**以及在 ECU 内部**）是**可能的**。**这保证了**例如**发送的数据在发送方和接收方之间未被修改**。**负责的模块**是 **E2E library**。
|
||
|
||
**一些其他模块**支持**附加机制**，这些机制**在安全系统中也很有用**（例如 **CoreTest 或 RamTest**）。
|
||
|
||
**下图**显示了**如何使用 AUTOSAR R4.1** 来**支持 ASIL ECU**。
|
||
|
||
> **图 20：所有 BSW 按 ASIL 开发**
|
||
>
|
||
> （架构示意图：所有 BSW 模块都按最高 ASIL 开发，位于同一分区。）
|
||
|
||
**该方法有效**，**但有一个很大的缺点**：**所有 BSW 模块**必须**根据系统的最高 ASIL** 开发。**即使**只有**一些 BSW 模块真正需要特定的安全要求**，**这也会导致大量额外工作**。
|
||
|
||
**从 R4.2 开始**，**AUTOSAR** 提供了一种**附加方式**，**可以开发安全系统**，**而无需**使用**相应的 ASIL 实现整个 BSW**。**新方法的关键方面**是：
|
||
|
||
- **BSW 模块**不是**全部映射到一个分区**，**而是**可以根据 **ASIL 需要** **放置在单独的分区**中。**这意味着**系统**可以有一个 QM 分区**和**每个 ASIL 级别的一个分区**（**或甚至更多 ASIL 分区**）
|
||
- **该方法对单个 BSW 模块的影响最小**。**这意味着模块的范围**在 **ASIL 和 QM 上是相同的**。**模块之间的接口没有变化**。
|
||
- **只有**提供**安全相关功能**的模块（例如 Os 提供的内存保护）**才需要根据系统的 ASIL 开发**。**有时**甚至**可以**将**所需的 ASIL 功能限制**为**BSW 模块的子集**。
|
||
|
||
**ASIL 分区中的 ASIL 模块**需要**专门开发**。**它们不仅**需要**满足 ASIL 级别的要求**，**而且**需要**检测**它们是**从分区内部还是外部调用**的。
|
||
|
||
**使用此方法**可以：
|
||
|
||
- **重用**以 **QM 级别**（**无 ASIL**）开发的**现有 BSW 模块**，**而无需修改模块**
|
||
|
||
**所提出的方法必须逐案评估**，以**估计该方法对特定安全案例的适用性**以及**与纯 ASIL 方法相比** **结合 QM/ASIL 模块的**好处**。
|
||
|
||
**BSW 模块**可以**放置在不同的分区中**。**AUTOSAR** 支持**一个 QM 分区**和**多个 ASIL 分区**。**下图**显示了一个**示例映射**。**这里**，**ASIL SWC** 通过 **BSW 中的自己分区**（**包含 IoHwAbs 和下面所需的驱动程序**）**安全访问某些硬件**。
|
||
|
||
> **图 21：BSW 模块映射到不同的分区**
|
||
>
|
||
> （架构示意图：QM 分区包含 QM BSW 模块，ASIL 分区包含 ASIL BSW 模块。ASIL SWC 通过 ASIL BSW 访问硬件。）
|
||
|
||
**强烈建议**，**如果可能**，**QM BSW 分区在用户模式下运行**，**以防**系统中**有 BSW ASIL 分区**，**以避免**对**硬件寄存器**（例如 **MPU 设置**）的更改。**如果不可能**（例如**硬件仅支持**监督员模式），**则**需要**附加手段**来**确保免受干扰**。
|
||
|
||
#### 3.2.1 某些模块始终是 ASIL
|
||
|
||
由于**保护机制**由**一些特定的 BSW 模块**（例如**操作系统**）提供，**这些模块**必须**根据系统中的最高 ASIL 开发**。**如果它们不是按此级别开发**，**则无法保证**它们**能够履行其监督任务**。**必须按 ASIL 开发的模块的决策**始终是**特定于项目的**，并由**系统的安全要求**决定。
|
||
|
||
#### 3.2.2 整体配置
|
||
|
||
**出于安全目的**将 BSW 模块**分离到不同的 BSW 分区**中需要**在 ECU 配置中配置**。**映射**在 **EcuC 和 Os 配置中完成**。
|
||
|
||
对于**每个此类 BSW 分区**，**需要一个 OsApplication**。**以下设置**适用于**每个 BSW OsApplication 的 Os 配置**：
|
||
|
||
| 名称 | BSW 分区的值 |
|
||
|------|---------------|
|
||
| OsTrusted | TRUE |
|
||
| OsTrustedApplicationWithProtection | TRUE 或 FALSE |
|
||
| OsTrustedApplicationDelayTimingViolationCall | TRUE |
|
||
|
||
**OsApplication 的其他属性**可以**根据需要填写**。**请注意**，**BSW 分区的 hook 函数**在 **AUTOSAR 中没有意义**，**应避免**。
|
||
|
||
**此外**，**请注意**，**OS-Application 的 OSApplication TRUSTED 属性（OsTrusted）** **与** ASIL/non-ASIL **无关**。
|
||
|
||
**之后**，**已使用的 BSW 模块**必须**配置**并**映射到不同的分区**。**映射**在 **EcuC 中完成**：
|
||
|
||
> **图 22：EcuC 配置 – 将 BSW 映射到分区**
|
||
>
|
||
> （配置示意图：`EcucPartitionCollection` 包含多个 `EcucPartition`，每个分区通过 `EcucPartitionBswModuleDistinguishedPartition` 引用 BSW 模块。）
|
||
|
||
`EcucPartitionCollection`（**多重性 0..1**）包含**系统的所有分区**。对于**每个分区**，存在**子容器 `EcucPartition`（0..*）**，其中包含**对此分区中放置的 BSW 模块**（**通过 BSWDT**）的**引用**（`EcucPartitionBswModuleDistinguishedPartition`（0..*））。
|
||
|
||
**以下设置**适用于**每个 BSW 分区的 `EcucPartition` 配置**：
|
||
|
||
| 名称 | BSW 分区的值 |
|
||
|------|---------------|
|
||
| EcucPartitionBswQmModuleExecution | TRUE 表示 QM 模块，FALSE 表示 ASIL 模块 |
|
||
| PartitionCanBeRestarted | FALSE |
|
||
| EcucPartitionBswModuleExecution | TRUE |
|
||
| OsAppEcucPartitionRef | 链接到此分区的 OsApplication |
|
||
|
||
**最后**，**我们配置了一个 QM 分区**和**一个（或多个）ASIL 分区**。
|
||
|
||
#### 3.2.3 跨分区边界
|
||
|
||
**当 BSW 模块放置到不同的分区**中时，**跨越边界**是**需要解决的最大问题**。**下图**以**相当一般的方式**显示了**场景**：
|
||
|
||
> **图 23：跨分区调用**
|
||
>
|
||
> （示意图：QM 分区中的 QM 模块调用 ASIL 分区中的 ASIL 模块。）
|
||
|
||
**这是因为被调服务假定它对模块本地数据具有完全访问权限**，**如果调用是从另一个分区执行的**，**这并不成立**，**因为内存保护设置仍然是调用方的设置**。**一般来说**，**有 3 种可能性**可以**解决问题**：
|
||
|
||
1. **调用方**可以**直接调用**改为对**被调方分区中的任务**执行 `ActivateTask()`。在这种情况下，**激活的任务**将**执行对函数的实际调用**。**作为替代**，**可以使用 `SetEvent()`** 来代替 `ActivateTask()`。**请注意**，**两种机制都以异步方式工作**，这意味着**原始调用方可能需要等待或轮询结果**
|
||
2. **调用方**可以使用 `CallTrustedFunction()` **进入被调方分区**，**或者被调方在被调用后**使用 `CallTrustedFunction()` **将其交给其分区**。**进入函数后**，**可以直接调用**。`CallTrustedFunction()` **确保调用方获得适当的权限**进行调用，例如**将内存保护更改为被调函数的设置**。
|
||
3. **如果被调函数不写入自己的数据或不调用写入此类数据**的其他函数，**则函数的调用**可能是**直接可能的**。例如，如果函数**只是读出一个值并返回它**。**基本上**，**这样的函数**表现为**库**。
|
||
|
||
**根据 BSW 模块到不同分区的映射**，**必须选择正确的选项**。对于**位于不同分区**的 BSW 模块之间的**所有同步函数调用**，**我们将关注调用可能性（2）和（3）**。**因为如已经声明**，**QM 模块未更改**，**我们必须封装**从 **QM 分区到 ASIL 的调用**以及**反之**。**ASIL 模块始终负责处理边界跨越**，**因为 QM 模块未被修改**且**不知道此边界**。**这意味着**，**如果 ASIL 模块是调用方**，**则边界处理需要在调用方侧进行**，**并且如果 ASIL 模块是被调方**，**则边界处理需要在被调方侧进行**。
|
||
|
||
**以下描述**侧重于 **ASIL 和 QM BSW 模块**。**除了 BSW 模块**，**CDD** 也**可能包含在系统中**。**对于 CDD**，**适用相同的规则和限制**（**除非另有明确说明**）。
|
||
|
||
##### 3.2.3.1 QM 模块调用 ASIL
|
||
|
||
> **图 24：QM 调用 ASIL**
|
||
>
|
||
> （示意图：QM 模块通过 stub 调用 ASIL 模块。）
|
||
|
||
**如已经声明**，**执行调用的 QM 模块** **未更改**。**甚至更多**：**QM 甚至不知道被调函数（模块）属于不同的分区**。**这意味着**我们必须**将调用的函数封装到执行边界跨越的 stub 中**。
|
||
|
||
> **图 25：QM 调用 ASIL 的详细信息**
|
||
>
|
||
> （示意图：stub 包含调用方侧和被调方侧两部分。）
|
||
|
||
**此 stub 函数**可以**是静态的**或**生成的**，**属于被调模块**。**它可以视为**被调 **ASIL 模块的函数的**新函数入口**。**以下消息序列图**显示了**调用序列**。**如您所见**，**stub 本身**也有**两部分**，**一个在调用方侧**，**一个在被调方分区**。
|
||
|
||
> **图 26：使用 stub 时的调用序列**
|
||
>
|
||
> （序列图：QM 模块 → 调用方侧 stub（打包参数）→ `CallTrustedFunction()` → 被调方侧 stub（解包参数并准备调用）→ 调用真实函数 → 打包结果 → 返回调用方侧 stub（解包结果）→ 返回 QM 模块）
|
||
|
||
**stub 本身**可以**是静态的（手写）**，**或**可以**根据可用的配置信息生成**。**接下来的两个子章节**详细说明了**不同的方法**。
|
||
|
||
###### 3.2.3.1.1 静态 stub
|
||
|
||
**静态 stub**必须**覆盖所有情况**。**在我们的案例中**，**重要的问题是** **找到调用方分区**以**进行调用类型**。**下一个代码片段**显示了**静态 stub 的示例**：
|
||
|
||
```c
|
||
Std_ReturnType module_function() {
|
||
runId = GetCurrentApplicationId();
|
||
if (runId == module_applicationId) {
|
||
/* direct call possible */
|
||
return Modulemodule_function_real();
|
||
} else {
|
||
CallTrustedFunction(MODULE_REALFUNCTION_ID, NULL);
|
||
/* ... */
|
||
}
|
||
}
|
||
```
|
||
|
||
**请注意**，**您必须** **初始化您自己的模块应用程序 ID**（**或** **直接使用生成的应用程序名称**）。
|
||
|
||
###### 3.2.3.1.2 生成的 stub
|
||
|
||
**如果**要生成**stub 的优化版本**，**生成器需要所有信息**（**例如谁调用函数**）以**创建最佳代码**。**如果信息缺失或不完整**，**则** **生成的代码** **可能无法** **生成代码**，**或者代码在运行时可能失败**。
|
||
|
||
**AUTOSAR** 具有**不同分区之间调用的抽象**。**此方法**用于多核系统以**允许模块在** **不同核心上的不同分区之间进行通信**。
|
||
|
||
**生成的代码使用的机制**由 **SchM** 提供：`SchM_Call()`。**`SchM_Call()`** 将在 **SchM 内**映射到 **3.2.2** 中列出的方法之一。
|
||
|
||
**对于找到跨越边界的最佳方法**，**中心问题是**：
|
||
|
||
> **谁将调用函数（并使用 stub）？**
|
||
|
||
**此信息**必须**由用户**通过 **SchM 配置提供**。**配置**由**调用方、被调方**和**对其模块的引用**（**也隐含到分区**）组成。**下图**来自 **RTE**，显示了 **`SchM_Call()` 的配置**：
|
||
|
||
> **图 27：`SchM_Call()` 的配置**
|
||
>
|
||
> （配置示意图：SchM 配置包含 `BswModuleCallPoint`、`BswCalledEntity` 和分区的引用。）
|
||
|
||
**基于此信息**以及 **BSW 模块的位置信息**，**SchM** 可以**生成 `SchM_Call()` 的优化版本**。
|
||
|
||
**例如**，**如果只有一个 stub 用户**且**此用户**放置在**与被调 BSW 模块相同的分区**中，**则可以进行直接调用**。**使用 `SchM_Call()` 的 stub 的示例**：
|
||
|
||
```c
|
||
Std_ReturnType module_function() {
|
||
Std_ReturnType r;
|
||
(void) SchM_Call_target_module_function(&r);
|
||
return r;
|
||
}
|
||
```
|
||
|
||
**生成 stub 的方法**有一些**限制**，**需要在系统开发期间考虑**：
|
||
|
||
- **来自集成商代码的调用**：**通过 `SchM_Call()` 进行配置**对于**集成商代码**是**不可能的**，**因为此代码** **不属于任何 BSW 模块**，**并且** **没有任何配置**（**EcuConfiguration**）和**模块**（**BSWDT**）信息**可以使用。**在这种情况下**，**必须使用手写的静态 stub**。
|
||
- **`SchM_Call()`** 配置**恰好一个调用方-被调方关系**。**如果函数** **由不同的调用方调用**，**则 stub 的生成部分** **无法区分哪个 `SchM_Call()`** **需要哪个调用方**。**在这种情况下**，**需要静态 stub**。
|
||
|
||
**注意**：**如果 QM 调用方也使用 `SchM_Call()`** **而不是** **实际函数名**，**则 stub 可以完全避免**。**但这将与** **重用现有 QM 代码的目标相矛盾**。
|
||
|
||
**有关参数处理**，**请参见 3.2.3.5**。
|
||
|
||
##### 3.2.3.2 ASIL 调用 QM 分区
|
||
|
||
> **图 28：ASIL 调用 QM**
|
||
>
|
||
> （示意图：ASIL 模块通过 wrapper 调用 QM 模块。）
|
||
|
||
**本章**现在涵盖**ASIL 调用方和 QM 被调方**的**方向**。**这里**，**ASIL 模块已经知道** **需要边界跨越**。（**否则**，**被调 QM 函数**将是 **ASIL 函数**。）**由于 QM 函数在从 ASIL 函数或同一分区中的 QM 函数调用时** **不应检测到任何差异**，**因此** **必须调用它**，**就像调用是本地执行的一样**。
|
||
|
||
> **图 29：ASIL 调用 QM 的 Wrapper**
|
||
>
|
||
> （示意图：wrapper 包含调用方侧（ASIL 分区）和被调方侧（QM 分区）两部分。）
|
||
|
||
**此 wrapper 函数**可以**是静态的**或**动态生成的**，**属于调用方模块**，**但部分在被调方的分区中执行**。**以下消息序列图**显示了**使用 `CallTrustedFunction()` 时的调用序列**：
|
||
|
||
> **图 30：使用 wrapper 时的调用序列**
|
||
>
|
||
> （序列图：ASIL 模块 → 调用方侧 wrapper（打包参数）→ `CallTrustedFunction()` → 被调方侧 wrapper（解包参数并准备调用）→ 调用真实函数 → 打包结果 → 返回调用方侧 wrapper（解包结果）→ 返回 ASIL 模块）
|
||
|
||
**我们可以**再次区分**静态 wrapper**和**从配置生成的** wrapper**。
|
||
|
||
**请注意**，**独立于技术解决方案**，**需要检查** **此类调用是否在项目特定的安全目标内**被允许。
|
||
|
||
###### 3.2.3.2.1 静态 wrapper
|
||
|
||
**以下代码片段**显示了**只有一个"用户"调用函数时的可能 wrapper**（**在其他情况下**，**需要扩展缓冲区处理**）。
|
||
|
||
**在示例中**，**使用 `CallTrustedFunction()` 机制**：
|
||
|
||
```c
|
||
/* 调用方侧代码 */
|
||
uint8 wrapper_function() {
|
||
/* ... */
|
||
CallTrustedFunction(MODULE_REALFUNCTION_ID, NULL);
|
||
return function_return_value;
|
||
}
|
||
|
||
/* 这是 wrapper 的第二部分，位于被调方分区中 */
|
||
uint8 function_return_value;
|
||
|
||
void TRUSTED_call_function(TrustedFunctionIndexType a,
|
||
parameter_struct *local_struct) {
|
||
function_return_value = function();
|
||
return;
|
||
}
|
||
```
|
||
|
||
###### 3.2.3.2.2 生成的 wrapper
|
||
|
||
**如果 wrapper 应生成**，**生成器需要特定信息**以**创建最佳代码**。**如果信息缺失或不完整**，**则生成的 wrapper 代码** **可能失败**。
|
||
|
||
**与 3.2.3.1 中的 stub 处理类似**，**我们可以使用 `SchM_Call()` 服务**来**隐藏分区转换**。**与 stub 相反**，**我们不需要关注 wrapper 的可能用户** —— **用户只是 ASIL 模块函数** —— **而是被调函数**。**这意味着我们必须找出被调方的分区**以**进行正确的调用**。**由于我们只支持一个 QM 分区**，**我们可以** **直接查找**（**参数 `EcucPartitionBswQmModuleExecution` 为 TRUE**）并**知道调用必须执行的位置**。
|
||
|
||
**此方法**也**有一个限制**：
|
||
|
||
- **来自集成商代码的调用**：**通过 `SchM_Call()` 进行配置**是**不可能的**，**因为集成商代码** **不属于任何 BSW 模块**，**并且** **没有任何配置**（**EcuConfiguration**）和**模块**（**BSWDT**）信息**可以使用。**在这种情况下**，**必须使用单独的静态 wrapper**来**封装来自集成商代码的调用**，**并且集成商代码需要小的更改**，例如**更改被调函数的名称**以**避免名称冲突**。
|
||
|
||
**有关参数处理**，**请参见 3.2.3.5**。
|
||
|
||
##### 3.2.3.3 ASIL 调用 ASIL
|
||
|
||
**ASIL 到 ASIL 调用的情况**可以视为 **3.2.3.2** 和 **3.2.3.1** 的**组合**。**同样**，**如果模块** **未放置在同一 ASIL 分区中**，**则可能需要通用粘合代码**。**在这种情况下**，**调用方或被调方**必须**提供此粘合代码**。**在 ASIL 系统中**，**粘合代码通常由** **具有较高 ASIL 的模块**提供。**粘合代码**可以**静态创建**，**也可以** **生成**。
|
||
|
||
**对于粘合代码的生成**，**存在以下限制**：
|
||
|
||
- **来自集成商代码的调用**：**通过 `SchM_Call()` 进行配置**是**不可能的**，**因为集成商代码** **不属于任何 BSW 模块**，**并且** **没有任何配置**（**EcuConfiguration**）和**模块**（**BSWDT**）信息**可以使用。**在这种情况下**：
|
||
- **要么**必须使用**静态粘合代码**来**封装来自/到集成商代码的调用**，**并且集成商代码可能需要小的更改**，例如**更改被调函数的名称**以**避免名称冲突**。
|
||
- **要么**提供**供应商特定的配置参数**，该参数**为每个调用保存**到**集成代码所在的 OsApplication**的**引用**。
|
||
- **如果我们只知道被调方的地址**（**如果接口是通用的**且**函数指针用于调用**，例如在 **PDU Router 中**），**我们需要**一个**专用的供应商特定的配置参数**用于 **ASIL 模块**，该参数**提供被调方所在分区的信息**。
|
||
|
||
##### 3.2.3.4 QM 调用 QM
|
||
|
||
**AUTOSAR 不支持此调用方-被调方组合**。**原因**是**这不可能** **而无需更改现有 QM 模块**。**因此**，**仅支持一个 BSW QM 分区**。**因此**，**所有这些调用都是分区本地的**。
|
||
|
||
##### 3.2.3.5 参数传递
|
||
|
||
**在前面的章节中**，**我们展示了如何**对**另一个分区中的函数进行调用**。**除了实际调用机制**，**还有另一个重要主题**，**这就是** **将参数传递给被调方**以及**将结果传递回调用方**。**其背后的**问题是：**被调方如何访问这些参数**，**以及** **如何将结果传播回调用方**。
|
||
|
||
**AUTOSAR** **区分传递的** **IN、OUT 和 INOUT 参数**。**IN 参数** **不关键**，**因为它们通常通过值传递**，**并且** **即使在通过引用传递的情况下**，**被调方也不允许**对它们**写入**。**这意味着** **它们不会将任何信息传递回调用方**。**OUT 和 INOUT 参数**用于**将结果从被调方返回给调用方**。**现在的问题是**：**如果被调方和调用方不在同一分区**，**这些值如何传递回调用方**。
|
||
|
||
**一般来说**，**以下方法是可能的**：
|
||
|
||
1. **如果调用方和被调方位于不同的分区**，**则被调方**对**副本**（**对于 INOUT 数据**）或**空空间**（**OUT 数据**）**进行操作**，**并且** **在返回调用方时**，**将值复制回来**。**对于数据的分区间通信**，**AUTOSAR** 提供 **OS 的 IOC 机制**。**然而**，**通过复制**，**通常可以避免使用 IOC**，**使得**仅需要**读访问**。
|
||
2. **硬件特定的解决方案**：**在这种情况下**，**通过使用所用微控制器的专用硬件功能**（**保证免受干扰**）来**避免复制/额外缓冲区**。**例如**，**如果硬件允许在调用方和被调方之间具有私有共享内存区域**。
|
||
|
||
**下面**我们将**展示（1）如何工作**。**选项（2）** **取决于所用硬件**，**在 AUTOSAR 中未标准化**。**以下代码片段**显示了**参数传递如何工作**的**示例**（**情况：ASIL 调用 QM**）：
|
||
|
||
```c
|
||
/* 调用方侧代码 */
|
||
Std_ReturnType _Dem_GetOperationCycleState(
|
||
uint8 id,
|
||
Dem_OperationCycleStateType* state) {
|
||
/* ... */
|
||
/* 使用参数设置 params 结构 */
|
||
ret = CallTrustedFunction(GETCYCLESTATE, ¶ms);
|
||
if (ret == E_OK) {
|
||
IocReceive_RETURNVALUEGETCYCLESTATE(&ret);
|
||
IocReceive_VALUEGETCYCLESTATE(state);
|
||
}
|
||
return ret;
|
||
}
|
||
|
||
/* 被调方侧代码 */
|
||
void TRUSTED_GETCYCLESTATE(TrustedFunctionIndexType a,
|
||
parameter_struct *local_struct) {
|
||
Std_ReturnType localreturn;
|
||
uint8 localid;
|
||
Dem_OperationCycleStateType localstate;
|
||
|
||
/* 从 local_struct 设置参数 */
|
||
/* ... */
|
||
localreturn = Dem_GetOperationCycleState(localid, &localstate);
|
||
IocSend_RETURNVALUEGETCYCLESTATE(localreturn);
|
||
IocSend_VALUEGETCYCLESTATE(localstate);
|
||
return;
|
||
}
|
||
```
|
||
|
||
**请注意**，**上面的示例**对于 AUTOSAR 分区间调用**相当典型**。**它假定** **缓冲区的生命周期等于被调函数的持续时间**。**如果不同**，例如**一个函数仅提供缓冲区**，**另一个函数在稍后时间表示缓冲区现已就绪**（**示例：NvM 读取机制**），**则需要采用**。
|
||
|
||
#### 3.2.4 访问外设/硬件
|
||
|
||
**在 AUTOSAR 中**，**对外设或硬件的访问** **仅限于 BSW 模块**。**通常**，**只有其中一些需要实际访问**，例如：
|
||
|
||
- **Os** 在**不同上下文之间切换**并需要**读/写上下文寄存器**。**此外**，**中断锁定**通常需要**访问硬件寄存器**或**执行特权指令**。
|
||
- **在启动期间**，**Mcu 驱动程序**需要**启用微控制器时钟**，**并且**可以**对寄存器执行进一步初始化**
|
||
- **IO 驱动程序**需要**访问其硬件部分**
|
||
- ...
|
||
|
||
**如果 BSW 的部分**现在**在启用内存保护的分区中运行**，**则通常不再可能**对硬件进行**完全访问**。**在这种情况下**，**可以通过以下方式实现硬件访问**：
|
||
|
||
1. **"CDD 方法"**：**创建访问所需硬件的代码片段**，**并将此代码映射到禁用内存保护的可信 OsApplication**。**这允许代码具有完全访问权限**。**在您的 BSW 模块中**，**所有硬件访问** **必须** **然后调用此小段代码**。**在这种情况下**，**此代码** **对硬件具有完全访问权限**。
|
||
2. **"硬件方法"**：**如果可能**，**将硬件寄存器映射到需要访问的分区的地址空间**。**这通常会打开**对位于分区中的 **BSW 模块**的**这些寄存器的访问**。**此方法的可用性** **在很大程度上取决于** **所用微控制器**和**内存保护单元的能力**。
|
||
|
||
**"CDD 方法" 的示例**：**CDD** **提供读取（peek）和写入（poke）硬件寄存器的方法**。**请注意**，**在这种情况下**，**应提到** **还需要访问管理**（**"谁被允许调用这些函数？"**），**因为否则** **无法保证免受干扰**。**CDD** **映射到具有完全内存访问权限的分区**。
|
||
|
||
> **图 31：CDD 方法**
|
||
>
|
||
> （示意图：QM BSW 模块调用 CDD，CDD 访问硬件寄存器。）
|
||
|
||
**请注意**，**一些模块**通常**具有隐式访问**，**因为它们的代码在内存保护方案在 Os 中启动之前执行**。**详细信息**可以在**下一章**中找到。
|
||
|
||
#### 3.2.5 启动、关闭和睡眠/唤醒
|
||
|
||
##### 3.2.5.1 启动
|
||
|
||
**在 AUTOSAR 中**，**启动**由 **EcuM 模块处理**。**它负责** **系统启动期间的正确顺序**。**在 ASIL 系统中**，**用户必须注意** **在启动期间不会覆盖相关数据**或**至少检测到该问题**。**此类故障** **可能发生**，**因为内存保护尚未运行**，**因为 Os 尚未启动**。**下图**来自 **EcuM**，显示了**启动期间的默认序列**。
|
||
|
||
> **图 32：ECU 启动**
|
||
>
|
||
> （序列图：`EcuM_Init` → 启动 OS → 启动 BSW 驱动 → 启动 RTE → 启动 SWC。）
|
||
|
||
**作为一般提示**，**始终最好** **最小化在 Os 启动之前执行的代码量**。**根据 ASIL**，**可能需要** **将启动的所有代码** **作为 ASIL 开发**，**或** **找到其他方式** **以确保在启动期间没有发生不好的事情**，**例如** **在稍后的时间点检查相关数据**。
|
||
|
||
##### 3.2.5.2 关闭
|
||
|
||
**对于关闭**，**我们必须区分不同的场景**。**从 AUTOSAR 的角度来看**，**EcuM** **还处理关闭**。**与启动相比**，**我们有一种情况**，**即在关闭期间也启用了内存保护**。
|
||
|
||
##### 3.2.5.3 睡眠/唤醒
|
||
|
||
**在 AUTOSAR 中**，**EcuM** **还负责睡眠/唤醒处理**。**如果系统** **在此区域具有特定的安全要求**，**则 EcuM 也应注意**。**例如**，**检查用户是否被允许触发睡眠/执行唤醒验证**。
|
||
|
||
#### 3.2.6 错误处理
|
||
|
||
**当 BSW 模块映射到不同的分区**时，**它们不会改变** **整体 AUTOSAR 错误处理**。**例如**，**对 Dem 或 Det 的调用** **仍然发生**，**并且** **根据映射** **可能跨越分区边界**。
|
||
|
||
**然而**，**使用多个具有 BSW 模块的分区** **会引入一些新的故障场景**：
|
||
|
||
- 位于**可信内存保护分区**中的 **BSW 函数** **可能引起内存违例**。
|
||
- **BSW 函数** **可以使用时序保护执行**，**并且** **可能超时**，**引起时序违例**。
|
||
- **BSW 函数** **可能尝试访问** **它无权访问的某些硬件寄存器**。
|
||
- ...
|
||
|
||
**在** **没有 BSW 分布的 AUTOSAR 系统中**，**这些问题** **通常** **不会被检测到**，**因为时序保护** **不用于 BSW 任务**。**这可能** **在正常程序执行期间** **或稍后** **引起问题**。
|
||
|
||
**在启用 BSW 模块保护的分区系统中**，**问题被检测到** **并通过 OsProtectionHook 报告**。**虽然** **可以重新启动单个 OsApplication**，**但无法重新启动单个 BSW 分区**，**因为 BSW 整体上** **在模块之间有太多依赖关系**。**这意味着**，**即使对于分区系统**，**保护故障也是致命的**，**并将导致系统重新启动**。**优点**是**可以更早地检测到故障**，**并且重新启动可以以更受控的方式进行**。
|
||
|
||
#### 3.2.7 时序保护
|
||
|
||
**从 3.2.6 中提到的错误**来看，**时序故障** **是一种特殊情况**，**因为它们可能随时发生**。**例如**，**考虑以下示例**：
|
||
|
||
> **图 33：时序故障**
|
||
>
|
||
> （序列图：SWC 的 runnable 调用 AUTOSAR 服务并继续在 QM BSW 分区中执行。从这里执行对位于不同分区的 ASIL 模块的调用。然后，在 ASIL 模块内部，发生时序违例。）
|
||
|
||
**这里**，**SWC 的 runnable** **调用 AUTOSAR 服务** **并在 QM BSW 分区中继续执行**。**从这里** **执行对位于不同分区的 ASIL 模块的调用**。**然后** —— **在 ASIL 模块内部** —— **时序违例发生**。**ASIL 模块** **没有机会检测到问题**，**并且系统将关闭**。
|
||
|
||
**为避免此类场景**，**可信 OsApplications** **具有** **将时序违例延迟** **到引起任务（或 ISR）离开分区时** 的**能力**。**如果两个 BSW 分区** **都启用了该标志**，**则时序违例** **在从 SWC 到 BSW 模块的调用返回点报告**。**然后** **它引起违例**，**并可能以 QM Application 分区的重新启动结束**。**此处的优点**是 **BSW 不报告问题**，**并且不需要关闭**。
|
||
|
||
**该功能**可以**通过配置参数** `OsTrustedApplicationDelayTimingViolationCall` **为每个可信 OsApplication 启用**。
|
||
|
||
#### 3.2.8 组合安全与多核
|
||
|
||
**如果** **使用多核架构实现 ASIL 系统**，**则** **迄今为止对** **安全** **和** **多核** **所做的所有考虑** **都有效**。**在多核系统中**，**BSW** **分配给** **核心特定的分区**。**如果添加安全**，**则** **我们有** **核心特定的 QM 分区**（**每个核心一个**）**和** **核心特定的 ASIL 分区**。**特定的多核配置参数**和**特定的安全配置参数** **是独立的**，**需要** **根据** **多核** **分别** **安全** **需求进行设置**。
|
||
|
||
#### 3.2.9 性能考虑
|
||
|
||
**BSW 在安全系统中的分布的主要目标**是**最小化工作量**，**如果只有（小）部分系统** **需要根据 ASIL 开发**。**缺点**是**保护模式** **引起额外的开销**。**开销所需的时间量** **取决于项目** **和** **BSW 模块的映射** **以及** **分区之间交互的频率**。
|
||
|
||
**如果……**，**开销将最小化**：
|
||
|
||
- **使用尽可能少的 BSW 分区**。**在所有情况下** **添加更多分区** **会引起更多开销**。
|
||
- **BSW 模块的映射遵循"最近"方法**。**这意味着** **具有高交互的模块** **应放置在一个分区中**。**例如**，**将整个通信栈** **放置在一个分区中** **比拆分它** **并将** **PduR** **放在单独的分区中** **要快得多**。
|
||
- **分区间调用的数量** **最小化**。**对用户的可能性** **通常有限**，**因为 AUTOSAR** **定义了 BSW 模块之间的交互**。**然而**，**集成商代码** **和** **CDDs** **可以** **以最小化此类分区间调用数量的方式** **编写**。
|
||
- **支持特定的硬件功能**。**例如**，**如果可能** **通过硬件具有更多内存区域**，**则** **可以利用它们** **来避免** **为 OUT 或 INOUT 参数复制数据**。**请注意**，**仅硬件提供此类机制是不够的**；**AUTOSAR 供应商** **还必须利用它**（**例如** **通过在 Os 或内存映射处理中支持此类功能**）。
|
||
- **避免 IOC 调用**。**IOC** **将始终** **复制您的数据**。**因此**，**避免调用它** **将提高性能**。**通常**，**尝试"拉"数据** **而不是"推"**，**这意味着** **调用方应**（**在 `CallTrustedFunction()` 返回后**）**尝试读取数据**。**缓冲区** **应尽可能位于被调方侧**。
|
||
|
||
#### 3.2.10 约束
|
||
|
||
**将 BSW 模块分离到不同分区的方法** **有效**，**但具有取决于可用硬件的限制**：
|
||
|
||
- **在一些 MCU 上**，**对寄存器的访问** **仅限于特定的处理器模式**。**在这种情况下**，**peek/poke 方法**（**参见 3.2.4**）**可用**，**但比直接访问** **消耗更多时间**。**这些函数所花费的时间量** **对于启动或关闭** **可能很好**，**但** **如果** **以高频率执行** **则在正常操作期间** **不好**。
|
||
- **通常**，**只有写访问** **在**（**BSW**）**分区之间受到限制**。**有时**，**甚至对外设寄存器的读访问** **具有写效果**（**例如读取接收字符的缓冲区**）。**在这种情况下**，**读访问也可能受到限制**。
|
||
- **有时**，**硬件** **不支持在特权模式下执行时** **使用内存保护**。**在这种情况下**，**建议** **在非特权模式下运行所有分区** **以使用内存保护**。**在这种情况下**，**需要特权模式的代码量** **应最小化**。
|
||
|
||
**请注意**，**对于这些措施**，**通常由 MCAL 供应商负责**。**如果 BSW 只是 QM**，**这也可能适用于 ASIL 限定的 MCAL**。
|
||
|
||
---
|
||
|
||
## 4 对 AUTOSAR 未来版本的展望
|
||
|
||
**在本章中**，**我们列出了** **BSW 分布的更改**，**这些更改** **可能发生在** **下一个不向后兼容的 AUTOSAR 版本中**。**因此**，**本章的内容** **不适用于 AUTOSAR 4.x 实现**，**但** **应显示未来 AUTOSAR 版本的** **可能扩展和增强**。**请注意**，**所有这些主题** **需要并行考虑**，**因为** **BSW 功能集群及其标准化接口**（**随后将命名为"标准化的 AUTOSAR BSW 集群接口"**）**的定义** **是支持安全用例所必需的**。
|
||
|
||
### 4.1 已知限制
|
||
|
||
**AUTOSAR 中对基础软件分配的支持** **目前仅限于向后兼容的更改**（**关于 AUTOSAR 4.0.3**）。**这目前导致** **以下限制**，**这些限制** **可能不适用于 AUTOSAR 的未来版本**：
|
||
|
||
- **每个核心只有一个 QM BSW 分区**。
|
||
- **Master 和 satellites 之间的通信** **未标准化**。
|
||
- **BSW 功能集群及其 AUTOSAR BSW 集群接口** **未标准化**。
|
||
|
||
### 4.2 分布式 BSW 中的 BSW 模块间调用
|
||
|
||
**目前**，**BSW 分布** **具有约束**，**即现有 QM 模块** **应按原样重用**。**如果** **我们放宽这一点**，**则** **可以允许模块之间更高效的通信**。**例如**，**可以直接在调用方** **包含 `SchM_Call()`**，**并避免 stub**。（**通常**，**调用方知道调用的上下文**，**并可以** **为调用准备最佳环境**。）
|
||
|
||
**此外**，**多核系统** **将受益**，**如果所有 BSW 模块间调用** **都使用 `SchM_Call()` 封装**。
|
||
|
||
### 4.3 标准化的 BSW 功能集群
|
||
|
||
**BSW 功能集群** **是功能上一致的** BSW 模块的**组**。**每个 BSW 功能集群** **包括一组 BSW 模块**。**可以有多个相同类型的功能集群**（**例如不同分区中的多个 I/O 集群**），**每个使用不同的模块集**（**例如一个分区中的 IOHWA + ADC**，**第二个分区中的 IOHWA + ADC + DIO**）。**每个功能集群** **具有** **"AUTOSAR BSW 集群接口"**，**该接口** **用于与其他功能集群通信**。
|
||
|
||
**BSW 功能集群** **可以分配给** **不同的分区**，**并且** **相同类型的功能集群** **可以在多个分区中可用**。**不同的功能集群** **可以分配给** **相同或不同的分区**。
|
||
|
||
**相同的功能集群** **在每个分区中** **最多只能存在一次**。
|
||
|
||
**但是**，**整个集群分配** **和** **由此产生的实际接口** **尚未标准化**，**这里只是提出了该技术**。**因此**：
|
||
|
||
**AUTOSAR 的未来版本** **可能标准化以下一项或多项**：
|
||
|
||
- **定义** **哪些模块** **分配给** **哪个 BSW 功能集群**（**=>"标准化的 BSW 功能集群"**）。**很可能** **同一栈的模块**（**例如 I/O 服务、I/O 硬件抽象和 I/O 驱动程序**）**将分配给同一功能集群**。
|
||
- **通过"标准化的 AUTOSAR BSW 集群接口"标准化不同类型功能集群之间的通信**，**如图 34 所示**。
|
||
|
||
> **图 34：标准化的 BSW 功能集群**
|
||
>
|
||
> （架构示意图：多个标准化的 BSW 功能集群（通信、内存、I/O、看门狗）通过 AUTOSAR BSW 集群接口彼此通信。）
|
||
|
||
---
|
||
|
||
## 5 术语表
|
||
|
||
**所有** **贯穿本文件使用的技术术语** **（除了在此列出的）** **可以在** **官方 AUTOSAR 术语表 [2]** **或** **软件组件模板规范 [3]** **中找到**。
|
||
|
||
### 5.1 缩略语和简称
|
||
|
||
| 缩略语 | 解释 |
|
||
|--------|------|
|
||
| ASIL | 汽车安全完整性等级（Automotive Safety Integrity Level） |
|
||
| QM | 质量管理（即不是根据 ASIL 要求开发） |
|
||
| IOC | OS 间应用通信器（Inter OS-Application communicator），OS 的一部分 |
|
||
| MCU | 微控制器单元，µC |
|
||
| MCAL | 微控制器抽象层（Microcontroller Abstraction Layer） |
|
||
|
||
### 5.2 技术术语
|
||
|
||
| 术语 | 解释 |
|
||
|------|------|
|
||
| **BSW 功能集群** | **BSW 模块的内聚组**。**该技术**在本文件中**提出**，**但** **模块到集群的实际分配** **目前未标准化**。**BSW 功能集群** **可能类似于通常称为"栈"的东西**，**但** **也可以将多个栈组合到一个集群中**，**或将一个栈分布在多个集群中**。**BSW 功能集群** **包括** **可以是功能集群一部分的模块的超集**，**但** **不是所有模块** **都需要在特定实现中可用**。**如果** **BSW 模块到 BSW 功能集群的实际分配** **在未来标准化**，**它们可能将命名为"标准化的 BSW 功能集群"**。**BSW 功能集群** **可以分配给** **不同的分区**，**并且** **相同类型的集群** **可以在多个分区中可用**（**在同一或不同的核心上**）。**不同的功能集群** **可以分配给** **同一分区**。**注意**：**与 ICC2 集群相反**，**AUTOSAR 4.1.1 中 BSW 多核支持** **不影响功能集群内的模块之间的内部结构和接口**。 |
|
||
| **AUTOSAR BSW 集群接口** | **由** **供应商/项目特定的 BSW 功能集群定义** **产生的** **BSW 功能集群之间的接口**。**该技术** **在本文件中** **以供应商/项目特定的方式提出**。**但是**，**BSW 功能集群的模块分配** **以及** **由此产生的接口** **尚未标准化**（**如果可能的话**）。**此术语** **可能在 AUTOSAR 的即将发布的版本中** **在标准化之后** **定义为"标准化的 AUTOSAR BSW 集群接口"**。**与** **标准化的 AUTOSAR 接口相反**，**AUTOSAR BSW 集群接口** **不应连接到** **其他 MCU 上的 SW-C 或 BSW 模块**。 |
|
||
| **Master** | **分布式 BSW 模块的一部分**，**协调** **satellites 的请求**，**并且** **可以过滤或监控** **传入的 satellite 请求**。**Master** **可以正常工作**，**即使** **satellites 不可用**。**在 AUTOSAR 的未来版本中**，**在分区** **可用于增强安全** **的情况下**，**可能建议或强制要求** **将 master 定位在具有高信任级别的分区中**，**例如** **在可信分区中**。 |
|
||
| **Satellite** | **分布式 BSW 模块的一部分**。**Master 和 satellite 之间的工作分配** **是特定于实现的**。**一种可能性**是，**satellite** **仅提供到其他模块的接口**，**并将** **所有请求** **路由到 master** **并将答案返回给其他模块**。**在不同的场景中**，**satellite** **可以在本地提供完整功能**，**并且** **仅在必要时** **将其内部状态与 master 同步**。**这些两种场景之间的中间形式** **是可能的**，**但** **satellites 通常不能** **在没有 master 的情况下工作**。 |
|
||
|
||
---
|
||
|
||
## 6 参考文档
|
||
|
||
| 编号 | 名称 |
|
||
|------|------|
|
||
| [1] | Requirements on Basic Software Module Description Template — `AUTOSAR_RS_BSWModuleDescriptionTemplate` |
|
||
| [2] | Glossary — `AUTOSAR_TR_Glossary` |
|
||
| [3] | Software Component Template — `AUTOSAR_TPS_SoftwareComponentTemplate` |
|
||
| [4] | Concept Enhanced BSW Allocation — `AUTOSAR_CONC_EnhancedBSWAllocation` |
|
||
| [5] | Specification of Basic Software Mode Manager — `AUTOSAR_SWS_BSWModeManager` |
|
||
|
||
---
|
||
|
||
## 翻译说明
|
||
|
||
- 本文档为**说明性文档（EXP）**，介绍了 BSW（基础软件）在多核系统和安全系统中的分布
|
||
- 第 2 章（多核）涵盖了 **BSW 功能集群**、**Master/Satellite 模式**、**SchM 分区间通信**、**配置任务映射**以及 **MCAL 多核类型 I-V** 的详细分类
|
||
- 第 3 章（安全）涵盖了 **ASIL/QM 分离**、**跨分区调用**（QM→ASIL、ASIL→QM、ASIL→ASIL、QM→QM）、**参数传递**、**硬件访问**、**启动/关闭/睡眠/唤醒**、**错误处理**、**时序保护**、**性能考虑**和**约束**
|
||
- 主要概念：`EcuCPartition`、`OsApplication`、`SchM_Call/Result/Send/Receive`、`CallTrustedFunction`、`IocSend/Receive`、`Master/Satellite`、`ExclusiveArea`、`OsProtectionHook`、`OsTrustedApplicationDelayTimingViolationCall`
|
||
- MCAL 多核类型：Type I（单核）、Type II（分布式内核，HW 元素映射到单一核心）、Type III（分布式内核，原子访问）、Type IV（master-satellite）、Type V（多个独立内核）
|
||
- 设计模式：`SchM_Call()`、`ActivateTask()`、`SetEvent()`、`CallTrustedFunction()`、`Wrapper`、`Stub`
|
||
- 配置概念：`EcucPartitionBswModuleExecution`、`EcucPartitionBswQmModuleExecution`、`PartitionCanBeRestarted`、`BswMPartitionRef`、`EcuMFlexEcucPartitionRef`
|
||
- 保留英文的标识符和缩写：所有 BSW 模块名（Can、Dio、Spi、Adc、Pwm、Icu、Ocu 等）、`Master/Satellite`、`SchM`、`WdgM`、`Dem`、`Det`、`EcuM`、`BswM`、`ComM`、`IOC`、`EcuCPartition`、`SchM_Call/Result/Send/Receive`、OS API（`GetCoreID`、`GetApplicationID`、`ActivateTask`、`SetEvent`、`CallTrustedFunction`、`TerminateApplication`）等
|
||
- `⌈⌋` 方框符、`RS_BRF_xxxxx`、`SWS_Rte_xxxxx`、`TPS_BSWMDT_xxxxx`、`ECUC_BswM_xxxxx` 等需求 ID 保持英文
|
||
|
||
---
|
||
|
||
*翻译：opencode-translator / Step 3 P0 批量翻译*
|