AUTOSAR CP
AUTOSARCP与AP架构当前都是行业热门话题，简单来说都是汽车电子软件标准中间件架构，适用于不同的场景；
其实，CP架构主要干了两件事：标准化接口与模块化设计：
标准化接口：AUTOSAR CP架构通过定义统一的软件架构和接口，使得不同供应商开发的ECU能够基于同一标准进行开发，从而提高了系统的可移植性和互操作性。这有助于减少因接口不一致导致的兼容性问题，降低系统维护的复杂性和成本。
模块化设计：AUTOSAR CP架构将汽车软件系统划分为不同的软件组件，每个组件都有明确定义的接口，易于模块化开发和维护。这种设计方式使得开发人员可以更加专注于各自领域的开发，同时也方便了系统的升级和扩展。
所以，在做新车型开发时，可以复用/重用之前的开发产出，即便是不同供应商完成的；可以大大的减少重复开发的工作量，提高了开发效率。不过，同步的，CP架构也在一定程度上保证了汽车电子软件的功能安全和信息安全。
Classic 平台使用虚拟功能总线 (VFB) 来支持 AUTOSAR 应用程序软件的独立于硬件开发和使用。总线由特定 ECU 的 RTE 抽象表示组成，从而可以将架构应用层中的 AUTOSAR 软件组件与架构基础设施解耦。AUTOSAR 软件组件和总线通过专用端口进行通信。您通过将组件端口映射到系统 ECU 的 RTE 表示来配置应用程序。
CP架构有明显的层级关系，从上到下，依次是应用层SWC、RTE、BSW、微控制器层（HW）；实际运行过程中也严格遵守这种层级关系；BSW模块是与硬件相关的以及通用系统功能，应用功能定义为独立的软件组件SWC，用RTE分离SWC和BSW。，在实际开发分工中也是与此架构层级有关，如应用层软件工程师、BSW开发工程师等；
1. 应用层 - 软件组件 (SWC)
这是纯粹实现车辆功能逻辑的部分，完全不包含任何特定ECU的硬件信息。
组成：应用层由多个独立的SWC构成。比如，一个车灯控制功能可以拆分为“灯光请求判断”、“灯泡驱动”、“状态反馈”等几个 SWC。
SWC 的类型：
应用 SWC (Application SWC)：实现核心应用逻辑。
传感器/执行器 SWC (Sensor/Actuator SWC)：专门负责与传感器或执行器相关的逻辑处理，但它依然不直接操作硬件，而是通过 RTE 将信号传递给 BSW 去执行物理交互。
标定参数 SWC (Calibration SWC)：为其他 SWC 提供可在线调整的标定数据。
通信方式：SWC 之间通过端口 (Ports)和接口 (Interfaces)进行交互，接口定义了数据的类型和方向，主要有两种模式：
发送者-接收者 (S/R)：用于周期性或连续的数据流，如传感器数值。
客户端-服务器 (C/S)：用于触发式、需响应的操作，比如请求读取某个故障码。
2. 运行时环境 (RTE)
RTE 是整个 CP 架构的灵魂与粘合剂。它是 AUTOSAR 虚拟功能总线 (VFB) 在单个 ECU 上的具体实现。
核心职责：
为 SWC 提供通信服务：RTE 封装了所有底层通信细节，无论两个 SWC 是运行在同一个 ECU 上，还是通过车载网络（CAN/LIN/FlexRay）分布在不同的 ECU 上，SWC 的代码对于通信调用都是完全一致的。这实现了位置无关性。
SWC 与 BSW 的桥梁：SWC 需要调用硬件时，会通过 RTE 的标准化接口去请求 BSW 的服务。例如，一个 SWC 想通过 CAN 总线发送数据，它会调用
Rte_Send_CANMsg()，RTE 再负责将此次调用路由到正确的 BSW 通信服务模块。调度与事件触发：RTE 负责在正确的时刻触发 SWC 内的“可运行实体 (Runnables)”——可以理解为SWC里的具体函数。触发可以基于时钟周期、收到数据事件等。
实现形式：RTE 通常是基于配置自动生成的代码，它严格为每个 ECU 量身定制，是整个系统实时性、可靠性的核心保障。
3. 基础软件层 (BSW)
这是标准化的服务与驱动集合，它让上层 SWC 可以不用关心底层硬件的具体型号。BSW 内部又细分为多个垂直层和水平模块：
由下至上，分为三层和一个特殊区域：
微控制器抽象层 (MCAL)
BSW 的最底层，直接操作微控制器的内部外设寄存器。
模块示例：
Dio(数字IO驱动)、Adc(模数转换驱动)、Can(CAN控制器驱动)、Spi(SPI通信驱动)。意义：将硬件访问标准化，使得更换 MCU 时只需更换 MCAL 的驱动实现，其上层的 ECU 抽象层和应用层代码无需变动。
ECU 抽象层 (ECU Abstraction Layer)
位于 MCAL 之上，将整个 ECU 板载外设进行封装和抽象，而不仅仅局限于 MCU 内部。
模块示例：
IoHwAb(IO硬件抽象) 负责封装某个功能的信号路由，而不管这个信号来自MCU引脚还是外部扩展的IO芯片。CanIf(CAN接口) 提供了一个统一的 CAN 通信视图，屏蔽了底层是一个还是多个 CAN 控制器。
服务层 (Services Layer)
BSW 的最顶层，为应用层和 RTE 提供高级的、系统级的服务。它是 CP 架构中最核心的功能集合。
核心模块示例：
通信服务：
Com(信号级通信)、PduR(协议数据单元路由)、Dcm(诊断通信管理)、Nm(网络管理)。系统服务：
OS(符合OSEK/VDX标准的实时操作系统)，是整个系统的调度心脏。内存服务：
NvM(非易失性存储器管理)，用于存储和读取EEPROM/Flash中的持久数据。状态管理：
EcuM(ECU状态管理器)、BswM(基础软件模式管理器)，协同控制ECU的启动、睡眠和唤醒等模式切换。
复杂设备驱动 (CDD)
一个特殊区域，用于实现那些由于时序或功能复杂度极高而无法通过标准BSW模块抽象出来的特殊功能驱动，例如喷油嘴驱动、高速传感器芯片的直接控制等。
4. 微控制器层 (HW)
这就是实实在在的物理 MCU 芯片，以及其片上集成的最小系统（时钟、电源等）。所有 BSW 和 RTE 的代码最终都在这个硬件上执行，并通过 MCAL 驱动其内置的 CPU 内核、存储器、CAN 控制器、定时器、GPIO 引脚等。
以一个简单的“按下按钮，点亮LED”功能为例，数据流在分层架构中是这样流动的：
硬件层：司机按下按钮，导致一个 GPIO 引脚电平变化。
MCAL：
Dio驱动模块通过读取寄存器，捕获到这个引脚状态。ECU抽象层+服务层：
IoHwAb模块将这个物理信号封装成一个标准化的逻辑状态，然后交给系统服务中的处理链。RTE：RTE 调用一个接收 SWC 的
Runnable，将这个标准化状态作为数据元素传递进去。应用层 (SWC)：功能逻辑 SWC的
Runnable执行，逻辑判断“按钮被按下”，于是决定“点亮LED”，并调用 RTE 提供的发送函数，将“点亮”命令输出给执行器 SWC或直接通过 RTE 请求 BSW 服务。反过来逐层下达：RTE 将命令传递给
IoHwAb，再经Dio驱动控制另一个 GPIO 引脚输出高电平，最终点亮硬件 LED。
参考：AUTOSAR Classic 和 Adaptive 平台的比较 - MATLAB & Simulink
AUTOSAR AP & CP 开发的异同剖析-电子工程专辑