1 文档范围（Scope of Document）
本文件的目的如下：
- 对复杂驱动（Complex Driver，CDD）给出整体概述；
- 为 CDD 在 AUTOSAR 架构内的实现和集成提供建议。
本文档面向 CDD 的开发者和集成者。
2 缩略语与术语（Acronyms and Abbreviations）
仅在本文件局部使用、因而未收录到 AUTOSAR 术语表 中的缩略语和术语，必须在本节"局部术语表"中给出。
| 缩略语 / 术语 | 说明 |
|---|---|
CDD |
CDD 原本是 Complex Device Driver（复杂设备驱动）或 Complex Driver（复杂驱动）的缩写，但其涵盖范围并不局限于"驱动"。 |
2.1 术语表（Glossary of terms）
术语表见文档 [1] AUTOSAR Glossary。
| 术语 | 定义 |
|---|---|
<MODULENAME> |
该术语的定义见文档 [4] AUTOSAR General Requirements on Basic Software Modules（基础软件模块通用需求）。 |
3 约定（Conventions to be used）
- 在需求描述中应使用以下特定语义（基于互联网工程任务组 IETF 的规范）。
本文档中的关键字
MUST、MUST NOT、REQUIRED、SHALL、SHALL NOT、SHOULD、SHOULD NOT、RECOMMENDED、MAY与OPTIONAL的含义如下：- SHALL（应当）：表示该句是 AUTOSAR 规范的绝对要求。因此，设计者必须遵守原始 AUTOSAR 规范的要求。
- SHALL NOT（不得）：表示该句是 AUTOSAR 规范的绝对禁止。因此，设计者必须遵守原始 AUTOSAR 规范的要求。
- MUST（必须）：表示该句是基于法律/标准原因的 AUTOSAR 规范的绝对要求。因此，设计者必须遵守原始 AUTOSAR 规范的要求。
- MUST NOT（禁止）：表示由于法律/标准约束，该句是规范的绝对禁止。因此，设计者必须遵守原始 AUTOSAR 规范的要求。
- SHOULD / RECOMMENDED（建议 / 推荐）：表示在特定情形下可能存在合理的理由忽略某项要求，但在选择不同做法之前，必须充分理解其全部含义并谨慎权衡。
- SHOULD NOT / NOT RECOMMENDED（不建议）：表示在特定情形下该行为可能是可接受的甚至是有用的，但在实现任何带此标签的行为之前，应充分理解其全部含义并谨慎权衡。
- MAY / OPTIONAL（可以 / 可选）：表示该项是真正可选的。一家供应商可能因特定市场需求而选择包含该项；另一家供应商也可能省略该项。未包含某选项的实现 必须 能够与包含该选项的实现互通（即便功能有所缩减）；反之亦然（该选项所提供的特性除外）。
4 相关文档（Related documentation）
4.1 输入文档（Input documents）
通用输入文档：
| 编号 | 文档名 | 原 PDF |
|---|---|---|
| [1] | AUTOSAR Glossary | AUTOSAR_TR_Glossary.pdf |
| [2] | List of Basic Software Modules | AUTOSAR_TR_BSWModuleList.pdf |
| [3] | AUTOSAR Layered Software Architecture | AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf |
| [4] | AUTOSAR General Requirements on Basic Software Modules | AUTOSAR_SRS_BSWGeneral.pdf |
| [5] | General Specification on BSW modules | AUTOSAR_SWS_BSWGeneral.pdf |
| [6] | Specification of Standard Types | AUTOSAR_SWS_StandardTypes.pdf |
| [7] | Specification of Platform Types | AUTOSAR_SWS_PlatformTypes.pdf |
| [8] | Specification of Communication Stack Types | AUTOSAR_SWS_CommunicationStackTypes.pdf |
模板规范文档：
| 编号 | 文档名 | 原 PDF |
|---|---|---|
| [9] | Specification of BSW Module Description Template | AUTOSAR_TPS_BSWModuleDescriptionTemplate.pdf |
| [10] | Specification of ECU Configuration | AUTOSAR_TPS_ECUConfiguration.pdf |
模块参考文档：
| 编号 | 文档名 | 原 PDF |
|---|---|---|
| [11] | Specification of ECU State Manager | AUTOSAR_SWS_ECUStateManager.pdf |
| [12] | Specification of Watchdog Manager | AUTOSAR_SWS_Watchdog Manager.pdf |
| [13] | Specification of Operating System | AUTOSAR_SWS_OS.pdf |
| [14] | Specification of Default Error Tracer | AUTOSAR_SWS_DefaultErrorTracer.pdf |
| [15] | Specification of Diagnostic Event Manager | AUTOSAR_SWS_DiagnosticEventManager.pdf |
| [16] | Description of the AUTOSAR standard errors | AUTOSAR_EXP_ErrorDescription.pdf |
| [17] | Specification of RTE | AUTOSAR_SWS_RTE.pdf |
| [18] | Specification of Memory Mapping | AUTOSAR_SWS_MemoryMapping.pdf |
| [19] | Specification of PDU Router | AUTOSAR_SWS_PDURouter.pdf |
| [20] | Specification of Communication | AUTOSAR_SWS_COM.pdf |
| [21] | Specification of Communication Manager | AUTOSAR_SWS_COMManager.pdf |
| [22] | Specification of Network Management Interface | AUTOSAR_SWS_NetworkManagementInterface.pdf |
| [23] | Specification of TCP/IP Stack | AUTOSAR_SWS_TcpIp.pdf |
| [24] | Specification of Synchronized Time Base Manager | AUTOSAR_SWS_SynchronizedTimeBaseManager.pdf |
4.2 相关标准与规范（Related standards and norms）
相关标准和规范详见文档 [5] General Specification on BSW modules。
5 复杂驱动（CDD）介绍（Introduction to CDD）
复杂驱动（Complex Driver，CDD）是一种未被 AUTOSAR 标准化的软件实体，可以通过 AUTOSAR 接口（AUTOSAR Interface）和/或基础软件模块 API 访问其他模块，或被其他模块访问。
依据文档 [3] Layered Software Architecture（分层软件架构），CDD 是位于基础软件"复杂驱动层"中的一个特定模块，与标准 BSW 模块或 RTE 进行交互：
- CDD 可能需要与分层软件架构中的模块对接；
- 分层软件架构中的模块可能需要与 CDD 对接；
- CDD 可能需要通过 RTE 与软件组件（SW-C）对接。
图 5-1：CDD 在分层软件架构中的位置
自上而下：RTE → ECU 抽象层 → 微控制器抽象层 → 微控制器硬件。CDD 位于"复杂驱动层"，可与 RTE、ECU 抽象层以及微控制器抽象层进行直接交互。
CDD 的主要目标是：实现复杂的传感器评估与执行器控制，需要直接访问微控制器，使用特定的中断和/或复杂的微控制器外设、外部设备（通信收发器、ASIC 等），以满足特殊的功能需求和时序需求。
此外，CDD 也可用于：
- 实现增强的服务 / 协议；
- 封装来自非 AUTOSAR 系统的遗留功能。
CDD 的实现可能与应用、µC 和 ECU相关。
最后，CDD 还可以作为一种迁移机制，将既有或新引入的概念纳入 AUTOSAR 软件架构。
6 CDD 设计建议（CDD design recommendations）
为便于 CDD 与 AUTOSAR 架构对接并简化集成，设计者应（shall）考虑以下几点。
6.1 文档（Documentations）
6.1.1 用户手册（User's Manual）
CDD 设计者应当（shall）提供一份用户手册，以便于集成并向客户提供信息：
- CDD 介绍与概述；
- 功能操作的描述（初始化、正常运行、关闭、故障运行等）；
- 与其他 BSW 模块、SchM（基础软件调度器）以及 RTE 的关系与依赖（如 NvM 提供的内存块、需要配置的临界区）；
- 文件结构与依赖关系；
- 接口描述（含服务）：名称、说明、可重入性、参数（名称、类型、范围、取值）、返回值（名称、类型、范围、取值）、配置类；
- 非功能性需求描述：时序与行为需求、资源使用、与其它 BSW 模块或 SW-C 的交互行为；
- Dem 错误描述，可选的 Det 错误描述，调试变量；
- 配置参数描述（名称、类型、范围、取值）；
- 内存映射需求描述（Flash、RAM）；
- 使用限制与未解决的问题；
- 集成约束及对其他模块的需求；
- 示例。
6.1.1.1 模块 ID（Module ID）
CDD 的模块 ID 见文档 [2] List of Basic Software Modules。
6.2 实现（Implementation）
AUTOSAR 对 CDD 的实现约束较少，至少包括：
- CDD 应当（shall）遵守输入规范 [3]、[4]、[5]、[6]、[7]、[8]、[9]、[10]。
- CDD 应当（shall）保护其临界资源，定义可由 SchM 或 OS 机制处理的临界区。
- CDD 的模式可以由 EcuM 和 BswM 模块管理。
- CDD 可以使用内存映射机制处理其内存段。
- CDD 可以使用 Det 或 Dem 模块上报其错误。
6.3 CDD 文件（CDD Files）
本节仅为建议，并未完整定义模块的文件结构。
6.3.1 源文件（Code file(s)）
CDD 模块的源文件结构未做强制规定，但需满足文档 [4] AUTOSAR General Requirements on Basic Software Modules 和文档 [5] General Specification on BSW modules 中的要求。
至少应当（shall）提供一个 CDD_<MODULENAME>.c 文件。
中断函数可以放在 CDD_<MODULENAME>_Irq.c 文件中。
回调（callout）函数可以放在 CDD_<MODULENAME>_Callout.c 文件中。
根据需要，链接时（Link time）从配置生成的 C 对象可以放在 CDD_<MODULENAME>_Lcfg.c 文件中。
根据需要，构建后（Post Build time）从配置生成的 C 对象可以放在 CDD_<MODULENAME>_PBcfg.c 文件中。
若 CDD 模块的实现需要更多源文件，可自行加入。
6.3.2 头文件（Header file(s)）
下图展示了 CDD 模块定义的 AUTOSAR 头文件层次结构。
CDD 模块应当（shall）提供一种头文件结构，使得 CDD 模块的使用者仅需包含 CDD_<MODULENAME>.h 文件。
如果存在需要由其他 BSW 模块处理的回调函数，CDD 模块可以（may）提供 CDD_<MODULENAME>_Cbk.h 头文件。
根据需要，从配置生成的 C 对象声明可以放在 CDD_<MODULENAME>_Cfg.h、CDD_<MODULENAME>_PBcfg.h、CDD_<MODULENAME>_Lcfg.h 文件中。
若 CDD 模块的实现需要更多头文件，可自行加入。头文件是自包含的（self-contained），即：它们应当（shall）包含自身所依赖的所有其他头文件。
CDD 模块可以包含 Det.h 和/或 Dem.h 头文件用于错误上报。
若需要定义内存映射区，CDD 模块可以包含 <Mip>_MemMap.h 头文件，其中 <Mip> 是模块实现前缀（Module Implementation Prefix）。
若配置了与 RTE 的接口，CDD 模块可以包含 Rte_CDD_<MODULENAME>.h 头文件。
6.3.3 推荐的文件结构（Recommended files structure）
下图展示了一个 CDD 模块的基本 AUTOSAR 头文件层次结构。
图 6.3-1：CDD 的头文件结构
CDD_<MODULENAME>.c → include → CDD_<MODULENAME>.h → Std_Types.h
↘ Compiler.h
↘ Platform_Types.h
↘ CDD_<MODULENAME>_Cfg.h
↘ <Mip>_MemMap.h
↘ Det.h
↘ Dem.h
↘ Rte_CDD_<MODULENAME>.h
↘ <MODULENAME>.h
↘ CDD_<MODULENAME>_Cbk.h
6.3.4 一致性检查（Coherence checks）
CDD 模块应当（shall）避免集成不兼容的（.c 或 .h）文件，具体规则详见文档 [5] General Specification on BSW modules。
6.4 行为与接口描述（Behaviour and Interfaces description）
部分 CDD 不仅包含与其他 BSW 模块或集群的接口，还包含更抽象的接口——这些接口由应用层 SW-C 通过 RTE 访问。
在这些场景下，需要一个 CDD SW-C 类型 来对接 RTE，且 CDD 应当（shall）遵守文档 [9] Specification of BSW Module Description Template 中的要求。
该描述文件应包含：
- CDD 服务的描述；
- 类型与端口接口；
- 内部行为与可运行实体（Runnable Entity）的描述；
- 可运行实体所需触发事件的描述；
- 用于共享资源保护的排他区（Exclusive Area）描述；
- 内存映射。
这里所需的高层抽象接口称为 AUTOSAR 接口（AUTOSAR Interface），由软件组件模板（Software Component Template，SWCT）描述，包含端口、端口接口及其细节描述。
SWCT 中用于描述 CDD 这些元素的根类为 ComplexDeviceDriverSwComponentType。
从 RTE 到 CDD 的函数调用被建模为可运行实体（RunnableEntity），同样包含在 SWCT 中。SWCT 中用于描述可运行实体（及其他一些元素）的根类称为 SwcInternalBehavior。
提示：CDD 的可运行实体的设计应尽量减少 RTE 开销，例如：
- 服务器端可运行实体应设计为可重入的：
can be invoked concurrently = TRUE。- 可运行实体签名应为：
void或StdReturnType RunnableName(void or parameters)。
6.5 参数配置（Parameters configuration）
若需要使用 AUTOSAR 配置编辑器（GCE）配置参数，CDD 应当（shall）遵守文档 [10] Specification of ECU Configuration 中的要求。
至少包括：
- 模块的 AUTOSAR 版本和软件版本应当（shall）由配置文件标识；
- 生产阶段不应包含 Det，因此需要在配置中提供一个参数以禁用错误上报。
7 与其他模块的接口（Interfacing to other modules）
本节描述 CDD 与基础软件中其他模块的关系。
7.1 与 RTE 和软件组件（SW-C）的接口
CDD 可能需要通过 RTE 与 SW-C 对接：
- 必需端口（Required ports）和接口应当（shall）按照 AUTOSAR 标准（AUTOSAR 接口）进行规范与实现。
- 某些情形下，CDD 需要使用 RTE 定义的某些端口专用参数。
请参见前面的 6.4 节。
7.2 与库的接口（Interfacing to libraries）
CDD 可以使用 AUTOSAR 库。
示例：CDD 可以使用 E2E 库机制实现传输保护，防止数据损坏或丢失。
7.3 与标准 BSW 模块的接口（Interfacing to standard BSW modules）
CDD 可能需要与分层软件架构中的其他模块对接，反之亦然。若属于这种情况，应遵循以下建议：
从分层软件架构模块访问 CDD：
CDD 应当（shall）提供可由访问方 AUTOSAR 模块以通用方式配置的接口。
典型示例：PDU 路由器（PDU Router）——CDD 可以作为新总线系统的接口模块实现。这一点已在 PDU 路由器的配置中处理。
从 CDD 访问分层软件架构模块：
仅当分层软件架构中相应模块提供了接口，并准备好被 CDD 访问时才允许。通常这意味着：
- CDD 应当（shall）关注接口的可重入性。对于非可重入接口，一次只能有一个调用方访问。对于条件可重入接口，若使用不同 id，则允许多个调用方并发访问。
- 若使用回调函数，其名称应可以（shall/may）通过配置指定。
- 不存在对该模块进行状态管理的上层模块（否则并发访问将变更状态但上层模块无法察觉）。
CDD 应当（shall）提供所有必要的配置参数，以满足依赖这些信息的其他 AUTOSAR 模块的需求。例如：当调用 Dem 上报生产错误时，Dem 错误码必须按照 Dem 错误码定义的标准进行定义并在 CDD 配置中引用。
对于多核架构，请参见 7.4 节。
通常，可以访问以下模块：
7.3.1 与 MCAL 模块的接口
CDD 可以直接访问微控制器资源（例如硬件定时器）。若所需资源由 MCAL 模块管理且无特定约束（例如实时性需求），CDD 应使用 MCAL。强烈推荐这样做，以避免冲突（例如：对同一组/通道的并行访问通常不被允许，因为 DIO 服务不可重入）。
此种情形下，CDD 应当（shall）使用 MCAL 模块的标准 API 访问 MCAL 模块。
7.3.2 与 BSW 模式管理器和 ECU 状态管理器的接口
若使用了 ECU 状态管理器，EcuM 和 BSW 模式管理器应是模式管理的唯一入口。
ECU 状态管理器应（should）用于：
- 初始化和去初始化函数应当（shall）只能由 EcuM 和/或 BswM 模块调用。
- 若 CDD 处理一个唤醒源，必须遵循文档 [11] Specification of ECU State Manager 中规定的唤醒事件处理协议。
BSW 模式管理器应（should）用于：
- CDD 模式的变更管理；
- BswM（在主核上）确认 ECU 应被关闭，并将相应的模式切换分发到每个核。从核上的 CDD 必须捕获此模式切换，相应地进行去初始化，并向 BswM 发送适当的信号表明其就绪状态。
7.3.3 与内存栈的接口
若内存由 CDD 独占管理，则允许绕过 NVRAM 管理器直接访问。若 CDD 使用标准内存栈，则 NVRAM 管理器是访问内存栈的唯一入口：CDD 应当（shall）使用 NVM 的 API 访问内存。
7.3.4 与看门狗栈的接口
看门狗管理器可将 CDD 一个或多个可运行实体作为被监督实体进行监督。应当（shall）对看门狗管理器进行配置，且 CDD 的可运行实体应当（shall）按文档 [12] Watchdog Manager 的规定调用看门狗 API。
看门狗管理器是访问看门狗栈的唯一入口。
CDD 不应（should not）直接与看门狗管理器交互，而应通过 RTE 定义的端口进行。
通常，RTE 负责将 CDD 中被监督实体的检查点（Checkpoint）信息传递给看门狗管理器。看门狗管理器使用 RTE 的服务，将监督状态的变化通知给 CDD。
为控制 CDD 与状态相关的行为，RTE 提供"模式端口（mode port）"机制。模式管理器可在模式端口所定义的不同模式间切换。连接到模式端口的 CDD 可以以下两种方式使用模式信息：
- CDD 可通过模式端口查询当前模式；
- CDD 可声明由 RTE 在模式变化时启动或停止的可运行实体。
出现故障时，看门狗管理器可通过 RTE 模式机制将监督故障通知 CDD 的被监督实体。被监督实体可据此采取恢复动作。
7.3.5 与通信栈的接口
有多个可能的访问入口：
- 可以接入 PDU 路由器（PDU Router）模块以处理 IPDU；
- 可以接入
<Bus>接口模块； - 可以接入 NM 模块；
- 可以接入 TcpIp 模块；
- 可以直接接入 Com 模块（因为 Com 提供信号接口）。
通常，不建议混用访问入口，即不应同时使用 PduR 接入和 Com 接入或 <Bus> 接口接入。
负责通信并可能触发 PDU 发送的 CDD 应当（shall）提供使能/禁止发送的 API。这将使 Dcm 等模块能够在诊断请求中禁用整个通信。这些由 CDD 提供的函数可以在与该函数关联的配置动作列表中被调用。参考通信栈中类似 API 的做法。
7.3.5.1 与 PDU 路由器的接口
PDU 路由器（PduR）是访问通信栈 IPDU 的独立于总线和协议的入口。
CDD 应当（shall）使用 PduR 模块的标准 API 访问 IPDU。
当 CDD 与 PduR 交互时，应在 PduR 中为每个 CDD 配置一个容器。
详见文档 [19] Specification of PDU Router。
7.3.5.2 与 <Bus> 接口模块的接口
<Bus> 接口模块是访问通信栈的总线特定入口。
CDD 应当（shall）使用 <Bus> 接口模块的标准 API 访问 IPDU。
当 CDD 与 <Bus> 接口交互时，CDD 使用为 <Bus> 接口定义的访问函数，并应按 CDD 需求配置 <Bus> 接口回调函数。<Bus> 接口应当（shall）被配置为包含 CDD_<MODULENAME>_Cbk.h 头文件。
详见 <BUS> 接口规范及用户手册。
7.3.5.3 与 Com 模块的接口
若 CDD 处理 Com 信号，CDD 应当（shall）使用 Com 模块或 RTE 定义的标准 API 访问信号。
详见文档 [20] Specification of Communication。
7.3.5.4 与 Com 管理器的接口
若 CDD 使用 Com 信号，CDD 应当（shall）使用 Com 管理器的标准 API 请求"通信模式"。
若 CDD 处理一个非 AUTOSAR 标准的 <Bus>，则 <Bus> 状态应由 ComM 处理以协调总线通信栈。
详见文档 [21] Specification of Communication Manager。
7.3.5.5 与网络管理接口模块的接口
若 CDD 处理一个非 AUTOSAR 标准的 <Bus>，则 <Bus> 状态应由 <Bus>Nm_CDD 模块处理。
<Bus>Nm_CDD 应当（shall）向网络管理器提供服务以管理 <Bus> 状态。
详见文档 [22] Specification of Network Management Interface。
7.3.5.6 与 TcpIp 模块的接口
TcpIp 模块是访问通信栈的基于 socket 的唯一入口。
CDD 应当（shall）使用 TcpIp 模块的标准 API 访问 socket。
详见文档 [23] Specification of TCP/IP Stack。
7.3.6 与 XCP 模块的接口
若 CDD 处理一个非 AUTOSAR 标准的 <Bus>，XCP 可以接入 <Bus>_CDD 以转发数据。
XCP 模块提供可由 CDD 使用的可配置接口：
<Cdd_Transmit>：请求通过 CDD 发送一个 PDU；<Xcp_CddTxConfirmation>：确认 PDU 成功发送的 API；<Xcp_CddRxIndication>：CDD 调用的 API，指示成功接收一个 LPDU。
XCP 模块应当（shall）被配置为允许 CDD 功能：应激活 XcpOnCddEnabled 参数。
若需要，CDD 可以（may）调用回调函数 Xcp_<module>RxIndication。
7.3.7 与诊断日志与跟踪（DLT）的接口
若 CDD 处理一个非 AUTOSAR 标准的 <Bus>，DLT 可以接入 <Bus>_CDD 以转发数据。
DLT 将数据转发给 Dcm 或使用串行接口的 CDD。
DLT 未定义特定的通信接口。DLT 规范定义了到内部 DLT 通信模块的 API。如何实现该通信模块以及如何与可能的 CDD（例如 Serial 或 USB）通信，由实现者决定。
7.3.8 与默认错误追踪器（DET）和诊断事件管理器（DEM）的接口
CDD 应当（shall）按文档 [16] Description of the AUTOSAR standard errors 的描述使用 Det、Dem 上报错误。
CDD 应当（shall）使用 Det 和 Dem 模块的标准 API。CDD 的反应应与其他 BSW 模块相同。错误 ID 在 CDD 模块内部定义，CDD 负责启动内部恢复。
7.3.9 与 OS 的接口
通常，只有 BSW 调度器（BSW Scheduler）和 RTE 应使用 OS 对象或 OS 服务。因此，CDD 应仅访问 OS 的 GetCounterValue 和 GetElapsedCounterValue 服务。
只要所使用的 OS 对象未被其他 BSW 模块使用，OS 就可以被 CDD 访问，例如：CDD 可以创建一个 OS 报警并使用它。
当 OS-Application 被终止并重启时，OS 可以通过 OsRestartTask 通知 CDD。CDD 须执行相应的清理动作。
详见文档 [13] Specification of Operating System。
7.3.10 与 StbM 模块的接口
若 CDD 模块实现了一个用户自定义的 Timebase Provider，即它处理全局时间同步（Global Time Synchronization）消息，CDD 模块应当（shall）使用 StbM 模块的 API：
StbM_GetCurrentTime：从 StbM 读取最新的时间基准值；StbM_GetCurrentTimeRaw、StbM_GetCurrentTimeDiff：计算时间基准值的更新；StbM_BusSetGlobalTime：将总线上接收到的时间基准值转发到 StbM。
此接口当前仅限于无硬件时间戳的 Timebase Provider。API 详情请参见文档 [24] Specification of Synchronized Time Base Manager。
全局时间同步相关 CDD 配置项在 CDD 模块定义中由容器 CddGlobalTimeContribution 指定。请参见文档 [10] Specification of the ECU Configuration。
7.4 多核系统中的 CDD（CDD in multi-cores system）
CDD 可用于多核架构。
在多核架构中，CDD 可以驻留在任何核上，但需遵守以下规则：
- 跨越分区（partition）和核边界的通信仅允许用于模块内部通信，应使用主/卫星（master/satellite）实现方式。
- 因此，若 CDD 需要访问 BSW 的标准化接口，它必须驻留在同一核上。
- 若 CDD 驻留在不同的核上，它可以使用普通端口机制访问 AUTOSAR 接口和标准化的 AUTOSAR 接口。这会调用 RTE，RTE 使用操作系统的 IOC 机制将请求传递到其他核。
- 然而，若 CDD 需要访问 BSW 的标准化接口但又不在同一核上：
- 可以在 CDD 所在核上运行一个提供该标准化接口的卫星（satellite），将调用转发到另一核；
- 或者在另一核上实现 CDD 的 stub 部分，并使用操作系统的 IOC 机制（类似于 RTE 的做法）以 CDD 局部方式组织通信。
- 此外，在后一种情况下，CDD 的初始化部分也必须驻留在另一核上的 stub 部分中。
7.5 作为 MCAL 模块的 CDD（CDD module of the MCAL）
可以为微控制器驱动编写 CDD，但与处于更低层的普通 CDD 不同，它不能访问其他标准模块，例外仅包括 Det、Dem、SchM 等。
通常，若对某一特定层施加了某些限制，则这些限制同样适用于 CDD。