第2章：AUTOSAR经典平台（CP）详解
好，咱们进入正题。AUTOSAR经典平台，也就是CP，是当前汽车嵌入式开发的主力军。我最早接触它的时候，说实话，被那一堆分层和模块搞得有点懵。但干久了你会发现，这套架构其实很有章法。
2.1 CP架构分层：应用层、RTE、基础软件层
CP的分层，说白了就是三块：应用层、运行时环境（RTE）、基础软件层（BSW）。
应用层放的是你的业务逻辑。比如车窗控制、雨刮器逻辑、ADAS算法。这一层不关心硬件细节，只关心功能。我个人习惯把应用层写得尽量“傻”——只做逻辑判断，不碰硬件寄存器。
RTE是中间人。它负责应用层和BSW之间的通信。你想想看，应用层想发个CAN消息，它不需要知道CAN控制器怎么配，只需要调用RTE的接口就行。RTE帮你把数据打包、路由、触发。
BSW是底层管家。它直接和硬件打交道，管理操作系统、通信栈、存储、诊断等。BSW又分了好几层：服务层、ECU抽象层、微控制器抽象层（MCAL）。
核心要点：分层的目的就是解耦。应用层换硬件，只要RTE接口不变，BSW随便换。我在项目中遇到过，客户临时换了MCU，我们只改了MCAL和部分BSW配置，应用层代码一行没动。
2.2 BSW模块详解
BSW里模块很多，我挑几个最常用的说说。
2.2.1 OS（操作系统）
CP里的OS是基于OSEK标准的。它支持任务调度、中断管理、资源锁、计数器等。嗯，这里要注意：OS的任务优先级不是越高越好。我曾经见过一个项目，把所有任务都设成最高优先级，结果系统直接卡死。优先级要按实时性需求来排。
2.2.2 COM（通信模块）
COM负责信号级别的通信。它把CAN/LIN/Ethernet上的原始数据，拆解成一个个信号。比如一个CAN报文里包含车速、转速、水温三个信号，COM帮你解析好，应用层直接读信号值就行。
我建议你在配置COM时，把信号更新周期和信号长度写清楚。否则后期调试时，信号值对不上，排查起来很痛苦。
2.2.3 DCM（诊断通信模块）
DCM处理UDS诊断协议。它负责接收诊断请求（比如读故障码、写数据），然后调用对应的服务。DCM的配置项很多，比如会话管理、安全访问、DID读写等。
避坑指南：我曾经在配置DCM时，忘了配安全访问的种子和密钥算法，结果诊断仪连不上ECU。后来查了半天才发现是安全等级没对上。
2.2.4 DEM（诊断事件管理模块）
DEM管理故障事件。它记录故障发生的时间、次数、环境数据。比如你检测到某个传感器电压异常，DEM会生成一个DTC（诊断故障码），并存储快照数据。
DEM的配置要注意事件优先级和存储策略。有些故障是临时的，有些是永久的。我习惯把临时故障的存储次数设小一点，避免把NVM写坏。
2.3 方法论与开发流程
AUTOSAR的开发流程，说白了就是“配置生成代码”。你不需要手写BSW，而是用工具配置好参数，工具自动生成代码。
流程大致分几步：
- 系统级设计：定义ECU之间的通信矩阵、信号路由。
- ECU级设计：配置BSW模块参数，比如OS任务、COM信号、DCM服务。
- 代码生成：用工具（比如Vector DaVinci、EB tresos）生成BSW代码。
- 集成与测试：把应用层代码和生成的BSW代码编译链接，刷到ECU里测试。
个人经验：配置阶段一定要仔细。我见过有人把CAN波特率配错，结果整车网络瘫痪。配置完最好做一次静态检查，工具一般都有校验功能。
你可能会问：为什么不用手写？因为手写BSW太容易出错了。AUTOSAR的配置项有几百个，手写一个OS配置就要几百行代码，还容易漏掉关键参数。用工具生成，至少保证语法正确。
2.4 小结
CP的分层架构，把应用和硬件隔离开，让开发更专注。BSW模块各司其职，OS管任务、COM管通信、DCM管诊断、DEM管故障。开发流程以配置驱动，工具生成代码，减少手写错误。
下一章，咱们聊聊自适应平台（AP），那个更灵活，但复杂度也更高。做好准备。