3. AUTOSAR Classic Platform架构速览

AUTOSAR Classic Platform（CP）的分层架构，是理解DaVinci工具链一切配置行为的起点。很多工程师在DaVinci Configurator里点开几十个配置节点，却说不清某个参数最终落在哪一层、由谁生成、被谁调用，根本原因是没有把“分层”和“生成物”这两件事对应起来。本节先把CP的纵向分层讲清楚，再把DaVinci的配置边界与生成物映射关系落到具体文件上。

一、CP的四层纵向结构

AUTOSAR CP自上而下分为四层：应用层（Application Layer）、运行时环境（RTE）、基础软件（BSW）以及微控制器抽象（MCAL，属于BSW的最底层）。应用层由若干软件组件（SWC）构成，SWC只描述“做什么”，不关心“跑在哪个核、用哪路CAN、寄存器怎么配”。RTE是应用层与BSW之间的唯一中介，它把SWC的端口（Port）与BSW提供的服务连接起来，并负责跨ECU的通信映射。BSW则进一步细分为服务层（Services）、ECU抽象层（ECU Abstraction）、微控制器抽象层（MCAL）和复杂驱动（Complex Drivers）。

关键约束是：SWC不能直接调用BSW。一个SWC要发一帧CAN报文，它只能通过RTE提供的Sender-Receiver端口写数据，由RTE把数据交给Com模块，再由Com交给CanIf、CanDrv，最终写入CAN控制器。这条链路决定了DaVinci中“配置一个信号”往往要跨多个配置模块联动修改。

二、DaVinci的配置边界在哪里

DaVinci Developer与DaVinci Configurator分工明确。Developer负责应用层：定义SWC类型、Runnable、端口、接口、数据类型，输出的是SWC描述ARXML。Configurator负责RTE以下：导入SWC描述后，配置RTE连接、BSW各模块参数、MCAL寄存器级参数，并生成可编译的C代码。

因此配置边界可以概括为：Developer管“接口契约”，Configurator管“实现与映射”。一个典型误区是试图在Configurator里改SWC的端口方向——这属于Developer的职责，Configurator只能消费不能修改。反过来，在Developer里配置CAN波特率也是无效的，因为那属于CanDrv/CanIf的MCAL与ECU抽象层参数。

三、生成物映射：从配置到文件

理解生成物映射，才能在做集成时快速定位问题。以“SWC_A通过CAN发送一个车速信号”为例，配置完成后DaVinci会生成如下文件：

这张表的价值在于：当CAN报文发不出去时，你可以按“SWC→RTE→Com→PduR→CanIf→CanDrv”的顺序逐层检查生成物，而不是盲目重配。例如Rte.c里没有生成Rte_Write调用，说明RTE连接没配；Com_Cfg.c里信号周期为0，说明Com配置漏了；Can_Cfg.c里波特率与硬件不符，说明MCAL参数错误。

四、一个可复用的检查顺序

在DaVinci集成中，建议按以下顺序核对配置与生成物，避免跨层返工：

1. 先确认SWC描述：在Developer中检查端口方向、接口类型、Runnable触发方式，导出ARXML。
2. 再导入Configurator并建立RTE连接：确认每个SWC端口都映射到具体的BSW服务或信号。
3. 配置Com/PduR/CanIf/CanDrv：从信号到PDU到帧到控制器，逐级对齐ID、长度、周期。
4. 配置Os与EcuM/BswM：确认Task周期、初始化顺序、通信模式切换。
5. 生成代码并检查关键文件：重点看Rte.c、Com_Cfg.c、Can_Cfg.c、Os_Cfg.c是否包含预期条目。

五、分层关系对集成工作的实际影响

分层带来的最大好处是解耦：更换MCU只需重配MCAL，更换CAN控制器只需改CanDrv，应用逻辑不动。但代价是配置分散在多个模块，一个信号要跨四五个配置节点。DaVinci的价值正是把这些分散配置集中到统一工程中，并通过生成器保证层间一致性。理解“哪一层归谁配、生成什么文件”，就能在集成时快速判断问题归属，而不是在几十个配置页之间反复试错。

最后强调一点：RTE不是简单的函数转发，它承担了数据一致性、跨核通信、模式切换等语义。因此RTE生成物（Rte.c/Rte.h）是应用与BSW之间的契约文件，任何手动修改都会在下次生成时被覆盖。正确做法是回到配置层修改，让生成器重新产出。