一、从一次深夜联调说起
上周和座舱域同事联调，遇到个典型问题：仪表盘需要获取导航的实时路径规划数据，传统CP架构下，两边ECU走CAN信号，信号表改了又改，版本还对不上。现在切到AP平台，导航服务通过SOME/IP发布路径数据，仪表盘作为客户端订阅，理论上应该很顺畅。但实际调试时，客户端死活收不到数据，Wireshark抓包一看，服务发现报文正常，但服务接口版本号对不上——服务端升级了数据结构，客户端没同步更新。
这个坑让我重新审视AP平台的核心：面向服务架构（SOA）不是简单的“发消息”，而是一整套设计范式的转变。
二、SOA在车载领域到底解决了什么？
传统CP架构是“信号导向”，比如车速信号0x123，长度2字节，精度0.1，周期20ms。这种架构在功能固定的时代够用，但现在智能座舱、自动驾驶功能迭代快，各ECU之间数据交互复杂，信号表维护成了噩梦。
AP平台的SOA把一切都看作“服务”。服务提供者（比如导航模块）对外暴露能力，消费者（比如仪表、HUD）按需订阅。好处很明显：
- 解耦：服务接口约定好，两边独立升级，只要接口兼容，内部怎么改都行
- 动态发现：服务上线、下线，消费者自动感知，不用静态配置
- 复用性：一个服务可以被多个消费者使用，避免重复开发
但这里有个关键点：服务接口设计是重中之重。那次联调的问题，根源就是接口版本管理没做好。AP
