# 032、AutoSAR AP与CP协同：混合架构设计与桥接通信

从一次诡异的信号丢失说起

上个月在实车路试时，我们遇到了一个让人头疼的问题：智能座舱的导航引导线偶尔会在仪表盘上“卡顿”甚至消失，但座舱主屏显示完全正常。抓取日志发现，仪表盘（CP架构）每隔几秒就会丢失来自座舱域控制器（AP架构）的导航事件信号。问题不在功能逻辑，也不在单个模块——而是出在AP与CP两个异构AutoSAR平台之间的“握手”环节。

这个坑让我意识到，很多团队在迈入混合AUTOSAR架构时，低估了AP与CP协同的复杂度。今天我们就来拆解这个问题背后的核心：混合架构设计与桥接通信。

混合架构不是简单的“AP+CP”

很多人初次接触AutoSAR混合架构，容易把它理解为“AP负责高性能应用，CP负责实时控制，两者用个中间件连起来就行”。这种想法在实际量产中会带来大量集成隐患。真正的混合架构设计，必须从资源、时序、安全三个维度统一规划。

比如，我们那个导航信号丢失的问题，根源在于AP端采用SOME/IP发布服务时，默认的TTL（Time To Live）设置与CP端DCM的预期不匹配。CP端的COM模块等待严格周期信号，而AP端在负载高时会延长发布间隔——两边节奏没对齐，信号链就断了。

桥接通信的三种典型模式

模式一：SOME/IP + DDS 作为“翻译官”

这是目前最常见的桥接方式。AP侧用SOME/IP或DDS发布服务，CP侧通过一个桥接代理（通常是单独的ECU或隔离核）转换到CAN/LIN信号。关键点在于协议映射表