2. AUTOSAR分层架构与Vector工具链定位
AUTOSAR分层架构是车身ECU基础软件量产集成的“骨架”。理解BSW、RTE、SWC三层关系，以及Vector MICROSAR、DaVinci、CANoe等工具在其中的职责边界，是后续配置、生成、集成与验证工作的前提。本节从分层结构出发，逐层说明各层职责、层间接口，再落到Vector工具链在量产集成中的定位。
一、三层结构：SWC、RTE、BSW
AUTOSAR把ECU软件自上而下划分为三层：最上层是应用软件层（Application Layer），由若干软件组件SWC（Software Component）构成；中间是运行时环境RTE（Runtime Environment）；最下层是基础软件BSW（Basic Software）。三层之间通过标准化接口通信，使应用逻辑与硬件、总线、操作系统解耦。
SWC（软件组件）是功能实现单元，例如车身域中的车门控制、雨刮控制、灯光控制、座椅调节等。SWC不直接访问硬件，也不直接调用CAN驱动，它只通过端口（Port）声明自己需要的数据和提供的数据。端口分为需型端口（Require Port，R-Port）和供型端口（Provide Port，P-Port），分别表示“我需要”和“我提供”。SWC内部还可以包含可运行实体（Runnable Entity），由RTE按事件触发。
RTE（运行时环境）是SWC与BSW之间的“中间层”。它把SWC的端口通信映射为具体的函数调用或数据读写，负责SWC之间、SWC与BSW之间的通信调度。RTE由DaVinci Configurator等工具根据SWC描述和系统配置自动生成，开发者一般不手写RTE代码。RTE的存在使SWC可以独立于具体ECU和总线拓扑进行开发。
BSW（基础软件）是硬件相关与通用服务的集合，进一步分为服务层、ECU抽象层、微控制器抽象层和复杂驱动。服务层包括操作系统（OS）、通信服务（ComM、PduR、Com）、诊断服务（Dcm、Dem）、存储服务（NvM）等；ECU抽象层包括CAN驱动接口、IO硬件抽象等；微控制器抽象层包括MCU、CAN控制器、端口等寄存器级驱动。BSW通过RTE向SWC提供服务。
二、层间接口与通信机制
三层之间的接口是标准化的，这是AUTOSAR可移植性的关键。SWC与RTE之间通过端口接口通信，常见的有发送-接收接口（Sender-Receiver）和客户端-服务器接口（Client-Server）。发送-接收接口用于数据传递，例如车门状态SWC向灯光SWC发送“车门已开”信号；客户端-服务器接口用于服务调用，例如诊断SWC调用NvM的读写服务。
RTE与BSW之间通过标准接口通信。RTE调用BSW的服务，例如调用Com发送报文、调用Dcm处理诊断请求、调用NvM读写非易失数据。BSW内部各模块之间也有明确的接口，例如Com通过PduR路由到CanIf，CanIf再调用Can驱动。这种分层调用关系保证了上层不依赖具体硬件。
在量产集成中，一个常见的误区是把SWC直接调用BSW函数。这种做法会破坏分层，导致SWC无法复用、RTE无法正确生成。正确做法是SWC只声明端口，由RTE负责映射到BSW服务。
三、Vector工具链的职责边界
Vector在AUTOSAR量产集成中提供三类核心工具，分别对应不同层的工作。
MICROSAR是Vector的BSW协议栈实现，覆盖服务层、ECU抽象层和MCAL。它提供符合AUTOSAR标准的Com、Dcm、Dem、NvM、CanIf、CanTp等模块，以及针对具体芯片的MCAL驱动。MICROSAR的职责边界是“提供BSW代码和配置接口”，它不负责应用逻辑，也不负责RTE生成。量产集成中，MICROSAR以静态库或源码形式交付，配合DaVinci Configurator进行配置。
DaVinci Configurator是BSW和RTE的配置与代码生成工具。它读取ARXML描述文件（包括SWC描述、系统描述、ECU资源描述），生成RTE代码和BSW配置代码。DaVinci Configurator的职责边界是“配置与生成”，它不提供BSW协议栈本身，也不执行总线测试。典型工作流是：导入ARXML → 配置BSW模块参数 → 生成RTE和BSW配置 → 编译链接。
CANoe是总线仿真、测试与分析工具。它不参与ECU内部代码生成，而是从外部观察和激励总线。在量产集成中，CANoe用于验证ECU的通信行为是否符合设计，例如发送车门状态报文、模拟其他ECU节点、记录总线负载、触发诊断服务。CANoe的职责边界是“外部验证与测试”，它不修改ECU内部配置。
四、量产集成中的职责划分
把三层结构和工具链放在一起看，量产集成的职责划分就清晰了。应用层SWC由功能开发团队负责，他们用DaVinci Developer等工具设计SWC和端口，输出ARXML。RTE和BSW配置由集成团队负责，他们用DaVinci Configurator导入ARXML，配置MICROSAR模块，生成代码。总线测试由测试团队负责，他们用CANoe编写测试用例，验证通信和诊断。
一个典型的车身ECU集成流程如下：功能团队提供车门控制SWC的ARXML，其中包含R-Port“车门状态”和P-Port“灯光请求”；集成团队在DaVinci Configurator中导入该ARXML，配置Com模块的报文和信号映射，配置Dcm的诊断服务，配置NvM的存储块；生成RTE和BSW配置代码后，与MICROSAR库一起编译；最后用CANoe发送车门状态报文，观察灯光请求报文是否按预期发出。
五、常见边界问题与判断依据
量产集成中经常遇到“这个配置该谁做”的问题。判断依据是看它属于哪一层的职责。如果涉及应用逻辑和端口声明，属于SWC设计；如果涉及RTE映射和BSW参数，属于集成配置；如果涉及总线报文和诊断响应，属于通信测试。例如，Com模块的报文周期配置属于BSW配置，由集成团队在DaVinci Configurator中完成；而报文内容的业务含义属于SWC设计，由功能团队定义。
另一个常见问题是RTE生成失败。多数情况下是ARXML中的端口连接不完整或数据类型不匹配。此时应检查SWC的R-Port是否都有对应的P-Port连接，以及数据类型是否在系统描述中正确定义。DaVinci Configurator会在生成日志中给出具体错误位置，集成人员据此定位。