过去十年,汽车电子电气架构在智能网联与软件定义汽车趋势下经历巨大变革。
早期汽车内部网络多采用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协议栈之上发挥各自作用。北汇信息也将持续关注不同通信技术在汽车领域的新动向,并见证它们在软件定义汽车浪潮中的发展与演化。