服务与数据的双螺旋：从SOME/IP到DDS看汽车电子架构的进化之路

过去十年，汽车电子电气架构在智能网联与软件定义汽车趋势下经历巨大变革。

早期汽车内部网络多采用CAN、LIN、FlexRay总线，这种基于信号的广播的静态模式，在ECU数量较少、功能简单时尚能应对。但随着ADAS、智能座舱和OTA升级等功能涌现，传统的通信架构已难以满足带宽、灵活性与软件解耦的需求。问题的核心在于，我们不能仅仅把汽车视为一个硬件的集合体，而是一个可以支持软件持续升级的智能平台。然而，要实现这个目标，必须解决一个关键问题，即如何将底层的车身、动力系统、底盘和多媒体等基础功能通过中间件与上层软件有效解耦，使各类功能以服务化方式灵活组合、调用与管理。

SOME/IP正是诞生于这样的背景之中。SOME/IP采用服务发现、远程过程调用(RPC)和发布订阅模式，实现了车辆内部应用软件的松耦合。2011年宝马主导完成了SOME/IP的设计，后于2014年被AUTOSAR正式采纳，实现了标准化与规模化应用。得益于与AUTOSAR体系的紧密结合，以及与车载以太网技术的融合，SOME/IP很快得到国内外众多OEM和Tier1厂商认可，广泛部署于智能座舱、域控制器以及部分ADAS应用中。

不久之后，随着自动驾驶技术的快速发展，汽车行业出现了一个新的需求：大量传感器数据需要在车内各计算单元间实时、高效、按QoS策略进行分发，例如激光雷达点云、摄像头图像、雷达目标以及高精地图等数据的发布/订阅。这时候我们把目光移到了DDS。与面向服务和车载应用的SOME/IP不同，DDS有另外一种完全不同的，以数据为中心的设计理念，非常契合自动驾驶应用的需求。随着ROS 2等机器人/自动驾驶软件框架采用DDS作为底层通信，使DDS在自动驾驶开发者社区中获得了认可。这样的趋势也影响到车企：为了兼容自动驾驶生态并满足车内高速网络需求，不少厂商尝试将DDS引入车载通信。DDS标准自身也在演进以贴近汽车需求，例如2017年OMG发布DDS-RPC规范，为DDS加入对远程过程调用的支持，使其在发布-订阅之外也能胜任SOA架构需要的请求/响应模式。

在AUTOSAR阵营，Adaptive平台最初侧重于SOME/IP，但近年来AUTOSAR与DDS社区逐步靠拢：2024年底AUTOSAR发布的Foundation Package已将DDS正式纳入其中，作为Classic和Adaptive平台共享的通信标准之一。这意味着DDS获得了AUTOSAR官方的支持地位，成为汽车开放系统架构中与SOME/IP并列的选项。

回顾过去可以发现，底层通信技术的演进始终是由应用需求的不断变化所驱动的。正如“进化论”所强调的，“适者生存”才是核心：并不存在放之四海而皆准的“最优”技术，只有在特定场景下最合适的解决方案。对于SOME/IP和DDS，很多人习惯于直接问“孰优孰劣”，但如果脱离具体的应用场景去讨论优劣，往往难有定论。北汇信息的一家之言，可以参考《SOME/IP与DDS对比及DDS测试策略和方案探讨》。

展望未来，SOME/IP和DDS基于各自的技术特点与成熟的市场应用基础，预计将在车内不同层级长期共存。SOME/IP作为AUTOSAR体系规定的标准协议，早已在车身控制、动力总成以及部分信息娱乐系统中实现了大规模部署，具有轻量、高效且易于在资源受限控制器上实现的优势。DDS则在高性能计算平台和自动驾驶领域展现强劲实力，能够满足多节点大数据交换和实时分布式控制的需求。

无论技术形态如何演变，可以确定的是，以太网必然会成为未来车内网络的主干标准，而SOME/IP、DDS乃至MQTT等多种中间件都将在IP协议栈之上发挥各自作用。北汇信息也将持续关注不同通信技术在汽车领域的新动向，并见证它们在软件定义汽车浪潮中的发展与演化。