Hotdry.

Article

实体按键回归的EE架构代价:奔驰STAR3网络拓扑与信号路由工程分析

从EE架构视角分析奔驰实体按键回归对CAN/LIN/以太网混合网络的影响,给出网络拓扑变更与信号交互的参数建议。

2026-05-04systems

当梅赛德斯 - 奔驰在 2025 年 9 月宣布重新引入实体按键时,业界看到的不仅是用户体验的回调,更是整车电子电气(EE)架构面临的一次隐性重构。首席软件官 Magnus Östberg 向《Autocar》透露,数据明确显示实体按键在高频使用场景下优于触控交互,这一判断直接推动了新 GLC 与 CLA Shooting Brake 的方向盘重新配备 rocker switch、滚轮与实体按钮。然而,这种人机交互层面的 “复古” 选择,实质上对车载网络的拓扑结构、信号路由策略以及域间通信延迟提出了全新的工程要求。本文从 EE 架构视角切入,分析实体按键回归对奔驰 STAR3 网络中 CAN、LIN 与以太网混合组网格局的深层影响。

STAR3 架构的核心网络拓扑逻辑

理解实体按键回归的技术代价,首先需要明晰奔驰 STAR3 电子电气架构的网络分层设计。STAR3 采用域控制器(Domain Controller)与中央网关(Central Gateway)相结合的架构模式,整车网络被划分为多个功能域:动力域(Powertrain)、车身域(Body & Comfort)、信息娱乐域(Infotainment)以及高级驾驶辅助系统域(ADAS)。每个域由独立的域控制器负责本域内的功能编排与信号聚合,域间通信则通过中央网关完成协议转换与数据路由。

在物理层,STAR3 使用以太网作为骨干网(Backbone),传输速率达到 100BASE-T1 级别,满足高带宽数据流的需求,例如 ADAS 传感器的原始数据融合与信息娱乐域的实时媒体传输。值得注意的是,以太网骨干网并非大一统的单一网络,而是通过网关与传统的 CAN-FD(高速 CAN)以及 LIN(低速 CAN)子网并存。CAN-FD 主要用于对实时性要求较高但数据量适中的控制信号,例如动力域的发动机扭矩请求与底盘的稳定性控制;LIN 则承担车门锁闭、窗控、空调面板等低速、低带宽的开关量信号传输任务。这种混合组网策略本质上是在成本、可靠性与带宽之间取得的工程平衡:以太网承担域间大数据交换,CAN-FD 提供确定性的实时控制通道,LIN 则覆盖最末端的传感器与执行器。

STAR3 还引入了 SOME/IP(Scalable Service-Oriented Middleware over IP)作为服务导向通信的核心协议。SOME/IP 允许域控制器以服务形式向外发布功能接口,客户端通过服务发现(Service Discovery)机制动态订阅,这种松耦合的通信模式为 OTA 远程更新提供了架构层面的便利。与传统的基于信号(Signal-Based)的 CAN 通信不同,SOME/IP 本质上是面向服务的,消息格式更为灵活,但在实时性和确定性方面不如 CAN 总线。因此,STAR3 架构在实际运行中呈现出一个显著的二元特征:域内控制仍然高度依赖 CAN/LIN 的确定性通信,域间交互则迁移至以太网 + SOME/IP 的服务化通道。

实体按键回归对网络节点密度的影响

奔驰新方向盘上回归的实体按键 —— 包括 rocker switch(跷板开关)、滚轮(roller)与薄膜按键(tactile button)—— 在电气层面并非直接接入以太网,而是通过 LIN 总线或低速 CAN 接入车身域控制器。以典型的方向盘按键模组为例,假设该模组集成 6 至 8 个独立的按键 / 开关,每个按键对应一个 LIN 节点或一个 CAN 信号帧中的位域(bit field)。在纯触控交互时代,方向盘的交互输入可能完全由电容 - touch 传感 IC 捕获,经由 I2C 或 SPI 链路传至中控域控制器,再通过以太网传输至车载信息娱乐系统进行解析。回归实体按键后,每个按键的按下 / 释放动作需要在 LIN 子网中生成对应的报文,并通过 LIN-to-CAN 网关节点上传至车身域控制器进行状态解析。

这意味着实体按键的回归实质上增加了 LIN 子网的节点密度。以新 GLC 的方向盘为例,若同时保留触控交互与实体按键两条输入路径,则整个 HMI(人机交互)子网的节点数将增加约 30% 至 50%。更关键的是,这些新增节点并非简单的 “即插即用”,而是需要纳入车身域控制器的信号路由表。当驾驶员按下音量调节滚轮时,LIN 总线上的报文首先到达车身域控制器,域控制器判断该信号的目标接收方 —— 可能是信息娱乐域的音响放大器 —— 随后通过中央网关将请求转发至以太网骨干网的目标服务端口。这一过程中,信号经历了 LIN 物理层、LIN 协议层、网关翻译、CAN-FD(若网关内部使用 CAN-FD 作为内部总线)、以太网协议层以及 SOME/IP 服务层的多次封装与解析,任何一层的数据丢失或延迟都将影响用户体验。

从网络拓扑的角度看,实体按键回归还带来一个容易被忽视的挑战:信号路径的不确定性。在纯以太网服务化架构中,所有的 HMI 输入可以被视为统一的服务请求,经由中央网关的路由表分发至目标域控制器,路径是清晰且可预测的。但在混合网络中,实体按键的信号首先在 LIN 子网内完成初步的滤波与消抖(debounce)处理,然后通过网关转发,这一过程增加了信号传输的跳数(hop count),同时也引入了更多的潜在故障点 —— 任何 LIN 节点的通信故障都可能表现为某个实体按键的 “失灵”,而诊断和定位的复杂度远高于以太网节点的故障追踪。

信号交互范式转变:从服务化回归信号翻译

实体按键回归对信号交互范式的另一个深层影响体现在域间通信模式的转变。STAR3 架构在设计之初旨在推进 “软件定义汽车”(SDV),其核心理念是将尽可能多的功能抽象为以太网之上的服务,通过 SOME/IP 进行远程过程调用(RPC)。在这种范式下,HMI 域的按键事件本质上是一个服务请求 —— 例如 “设置音量 + 1” 的请求被封装为 SOME/IP 消息,直接投递至信息娱乐域的音量控制服务,中间不涉及协议转换的开销。

然而,实体按键的回归迫使奔驰在部分高频交互场景中退回到基于信号的通信模式。当用户转动方向盘滚轮时,LIN 总线上产生的是一个周期性的数值递增信号(例如每转动一个刻度对应 LIN 帧中一个计数器值的增加),该信号在车身域控制器侧被解释为 “音量调节请求”,随后被转换为 SOME/IP 服务调用转发至信息娱乐域。这种 “信号 - 服务” 翻译过程不仅增加了端到端延迟(实测延迟从纯以太网路径的约 20 毫秒增加至包含 LIN 转发的约 50 至 80 毫秒),还要求车身域控制器维护一个信号到服务的映射表,该映射表需要根据不同市场、不同配置进行差异化配置,进一步增加了软件集成的复杂度。

延迟的增加在工程层面是可以容忍的 —— 毕竟音量调节并非安全关键功能 —— 但它揭示了一个更根本的矛盾:实体按键的物理确定性优势(触觉反馈 immediate tactile confirmation)与数字通信的延迟特性之间的张力。用户按下实体按键时预期的是即时生效,但经过多层网络协议栈的处理后,这个 “即时” 在某些场景下可能接近百毫秒级别。对于空调控制、座椅加热等非实时功能,这种延迟通常不会引发用户不满;但对于与 ADAS 功能联动的实体按键(例如驾驶模式切换或巡航控制激活),延迟需要被严格控制在安全阈值之内,这往往要求为这些关键功能单独预留 CAN-FD 的实时通道,而非经由 LIN + 网关的路径。

工程实践参数建议与监控要点

基于以上分析,本文为即将面临类似架构选择的 OEM 提供若干可落地的工程参数建议。首先,在网络拓扑层面,建议将新增实体按键的 LIN 子网节点数量控制在车身域控制器总节点数的 20% 以内,避免 LIN 子网过载导致的消息仲裁延迟。若实体按键数量超过这一阈值,应考虑将高优先级的按键(如驾驶模式切换)直接接入 CAN-FD 而非 LIN,以确保在网关负载较高时仍能保证关键信号的实时传输。

其次,在信号路由层面,建议为实体按键信号设置专用的服务路由通道,而非与触控交互共享同一服务总线。具体做法是在车身域控制器中为每个实体按键功能分配独立的服务标识符(SOME/IP Service ID),这样可以避免信号在网关处的队列竞争,同时便于实现精确的延迟监控。对于延迟敏感型功能(如驾驶模式切换),应强制使用 CAN-FD 作为传输通道,并将端到端延迟目标设定为不超过 30 毫秒。

监控体系建设同样是不可或缺的一环。实车测试阶段需要在网关处部署 CAN/LIN/ 以太网三层的流量监控工具,实时采集以下关键指标:LIN 总线负载率(建议不超过 40%)、CAN-FD 报文响应时间(关键信号不超过 10 毫秒)、以太网服务调用的平均延迟与 P99 延迟。当实体按键回归导致 LIN 负载率超过 50% 或 CAN-FD 关键信号延迟超过 15 毫秒时,应触发架构层面的重新评估,必要时将部分实体按键的信号路径改为直接以太网接入,跳过 LIN 子网的中间环节。

最后,在 OTA 更新策略方面,由于实体按键引入了新的信号映射层,OTA 更新包需要包含车身域控制器的信号路由表更新。这意味着 OTA 包的大小和分发策略需要相应调整 —— 更新路由表的增量包虽然较小,但必须保证在刷写过程中不影响实车的按键功能,建议采用双分区冗余刷写策略,确保在更新失败时能够回滚至稳定版本。

人机交互与 EE 架构的协同演进

奔驰实体按键的回归,表面上是用户体验层面的一次复古尝试,实则折射出当前汽车 EE 架构在追求服务化、 Ethernet 化的同时,对末端执行器与用户输入的物理层兼容性的忽视。STAR3 架构已经证明了自己能够承载高带宽的域间通信与灵活的 OTA 能力,但当实体按键重新成为高频交互入口时,架构不得不重新面对混合网络环境下的信号完整性、延迟确定性以及网关负载等老问题。这些问题并非无解 —— 通过合理的节点规划、专用的路由通道以及完善的监控体系,实体按键可以在不显著增加系统复杂度的前提下融入现代 EE 架构 —— 但它们提醒我们,汽车 HMI 的设计从来不只是交互层面的审美选择,更是对整车网络能力的深度考验。

资料来源:Paul Tan's Automotive News,42how

systems