Files

T

opencode-translator 0d470d1f17 P0 batch translation: 49 PDFs (General + BSWGeneral + MethodologyAndTemplates)

2026-06-12 17:31:38 +08:00

97 KiB

Raw Blame History

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 介绍

本文档是 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 进行分区间通信：

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 环境的边界条件：

需要多分区（多应用）AUTOSAR 操作系统来支持本概念中定义的用例。
硬件实现应允许将外设至少映射到核心。在将来，预期硬件实现允许映射到核心和分区。
应可能将硬件和软件中断路由到一个分区或至少一个专用核心（供 OS 进一步路由）。
MCAL 驱动程序所需的服务模块应通过能够接受对其服务 API 的调用来支持多核用例——分别在任何核心上。相关服务是：
- Det
- Dem
- EcuM
- Os
- SchM
- NvM

此外，假设使用了多核微控制器，但这不是强制性的，因为该概念无论单核还是多核实现都提供相同的服务 API 集。此外，可以实现具有空间和时间隔离的混合 ASIL 系统，其中可映射的 MCAL 元素被分配给不同的分区，尊重所得到的 MCAL 实现的安全完整性级别。

示例是一个核心上具有两个分区的系统，它们都访问 MCAL。如果没有此概念，驱动程序必须独占属于两个分区之一，使分区跨越执行的时间成本高昂。有了新概念，MCAL 元素可以单独分配给两个分区，从而消除了跨分区边界的需要。

2.5.3 约束

为了实现该概念，定义了进一步的约束以防止低效和多核阻塞的实现。在这个意义上，特别重要的是考虑到在单核上实现独占区域已经不够了，还需要在资源需要跨多个分区（分布在多个核心上）共享的情况下确保访问序列化。

单核上的访问序列化：对于单核系统，并发问题已得到很好的理解，并通过独占区域缓解，独占区域限制对一个进程的并发访问。这通常通过锁定中断、使用 OS 资源或创建非抢占式调度来完成。这有效地意味着不同进程的访问序列化。
跨核心的访问序列化：由于独占区域仅具有核心范围的作用域，因此它们不足以防止多核环境中的并发访问。但是，一旦需要访问相同的资源（例如通过访问服务 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 种可能性可以解决问题：

调用方可以直接调用改为对被调方分区中的任务执行 ActivateTask()。在这种情况下，激活的任务将执行对函数的实际调用。作为替代，可以使用 SetEvent() 来代替 ActivateTask()。请注意，两种机制都以异步方式工作，这意味着原始调用方可能需要等待或轮询结果
调用方可以使用 CallTrustedFunction() 进入被调方分区，或者被调方在被调用后使用 CallTrustedFunction() 将其交给其分区。进入函数后，可以直接调用。CallTrustedFunction() 确保调用方获得适当的权限进行调用，例如将内存保护更改为被调函数的设置。
如果被调函数不写入自己的数据或不调用写入此类数据的其他函数，则函数的调用可能是直接可能的。例如，如果函数只是读出一个值并返回它。基本上，这样的函数表现为库。

根据 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 的示例：

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 的示例：

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() 机制：

/* 调用方侧代码 */
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 参数用于将结果从被调方返回给调用方。现在的问题是：如果被调方和调用方不在同一分区，这些值如何传递回调用方。

一般来说，以下方法是可能的：

如果调用方和被调方位于不同的分区，则被调方对副本（对于 INOUT 数据）或空空间（OUT 数据）进行操作，并且 在返回调用方时，将值复制回来。对于数据的分区间通信，AUTOSAR 提供 OS 的 IOC 机制。然而，通过复制，通常可以避免使用 IOC，使得仅需要读访问。
硬件特定的解决方案：在这种情况下，通过使用所用微控制器的专用硬件功能（保证免受干扰）来避免复制/额外缓冲区。例如，如果硬件允许在调用方和被调方之间具有私有共享内存区域。

下面我们将展示（1）如何工作。选项（2） 取决于所用硬件，在 AUTOSAR 中未标准化。以下代码片段显示了参数传递如何工作的示例（情况：ASIL 调用 QM）：

/* 调用方侧代码 */
Std_ReturnType _Dem_GetOperationCycleState(
    uint8 id,
    Dem_OperationCycleStateType* state) {
    /* ... */
    /* 使用参数设置 params 结构 */
    ret = CallTrustedFunction(GETCYCLESTATE, &params);
    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 的部分现在在启用内存保护的分区中运行，则通常不再可能对硬件进行完全访问。在这种情况下，可以通过以下方式实现硬件访问：

"CDD 方法"：创建访问所需硬件的代码片段，并将此代码映射到禁用内存保护的可信 OsApplication。这允许代码具有完全访问权限。在您的 BSW 模块中，所有硬件访问 必须 然后调用此小段代码。在这种情况下，此代码 对硬件具有完全访问权限。
"硬件方法"：如果可能，将硬件寄存器映射到需要访问的分区的地址空间。这通常会打开对位于分区中的 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 批量翻译

97 KiB Raw Blame History Unescape Escape