3. 车载网络拓扑与EyeQ域控节点设计

在上一节中，我们已经明确了EyeQ域控在整车电子电气架构中的位置。本节进一步展开：当中央网关、区域控制器、传感器与执行器共同构成一张分层网络时，EyeQ究竟以什么身份接入、通过哪些接口收发数据、又承担哪些转发与诊断职责。理解这张拓扑，是后续配置通信矩阵、划分VLAN、设计诊断路由的前提。

一、分层拓扑：从中央网关到区域控制器

当前主流智能车采用“中央网关 + 区域控制器（Zonal Controller）+ 末端节点”的三层结构。中央网关位于顶层，负责跨域数据交换、诊断路由与整车级安全策略；区域控制器按物理位置划分（如左前、右前、左后、右后），就近汇聚本区域内的传感器与执行器，减少线束长度；末端节点则是摄像头、雷达、超声波、车门模块、灯光、座椅等具体设备。

EyeQ域控通常不直接挂在中央网关的骨干口上，而是作为“智能驾驶域”的一个高带宽节点，接入中央网关或某个区域控制器的以太网交换端口。它与中央网关之间一般使用1000BASE-T1或100BASE-T1车载以太网，与区域控制器之间则可能使用CAN FD、LIN或以太网混合连接。这样设计的原因是：EyeQ需要从多个摄像头获取原始或目标级数据，同时向底盘、车身执行器发送控制指令，带宽和实时性要求差异很大，必须分层承载。

二、EyeQ的接口角色：不只是“一个节点”

从拓扑图可以看到，EyeQ域控同时扮演三种接口角色。第一种是数据汇聚口：前视摄像头通过GMSL或LVDS串行链路把图像数据送入EyeQ的MIPI CSI-2接口，毫米波雷达和激光雷达则通过CAN FD或以太网发送目标级数据。EyeQ内部完成时间同步、坐标变换和感知融合，形成统一的环境模型。

第二种是控制输出口：融合后的决策结果通过CAN FD发送给EPS、ESP等底盘执行器，通过LIN或CAN FD发送给车身模块。这里需要注意，EyeQ通常不直接驱动执行器，而是把控制指令发给区域控制器或底盘域控，由后者完成最终的执行器驱动和闭环控制。EyeQ的输出更多是“目标指令”，例如期望方向盘转角、期望减速度，而不是PWM占空比。

第三种是诊断与刷写口：EyeQ通过中央网关与外部诊断仪建立DoIP连接，支持UDS诊断服务（0x10、0x22、0x2E、0x31、0x34/0x36/0x37等）。在产线或售后场景中，诊断仪先与中央网关建立TCP连接，再由网关路由到EyeQ的IP地址和端口。EyeQ自身需要维护诊断地址、会话状态和刷写引导流程。

三、连接关系中的关键参数与约束

设计这张拓扑时，有几个参数必须提前确认，否则后期会出现带宽瓶颈或诊断不通。以下是一组教学示例参数，用于说明典型配置方式，并非实测数据：

以EyeQ与中央网关的DoIP链路为例，典型配置中EyeQ的逻辑地址可设为0x1003，中央网关为0x1000，诊断仪为0x0F00。诊断仪发送目标地址为0x1003的UDS请求，中央网关根据路由表把请求转发到EyeQ的IP（例如192.168.10.30）和端口（13400）。EyeQ回复时源地址为0x1003，目标地址为0x0F00，网关再原路返回。这条路径是否通畅，取决于网关路由表、VLAN划分和防火墙规则三者是否一致。

四、从拓扑到工程落地：三个容易踩的坑

第一个坑是时间同步域不一致。摄像头、雷达和EyeQ如果分别使用不同的gPTP主时钟，融合时会出现毫秒级偏差，导致目标位置跳变。正确做法是在中央网关或EyeQ上配置gPTP Grandmaster，所有传感器节点作为Slave同步到同一时间基准。

第二个坑是CAN FD报文周期与带宽冲突。EyeQ向区域控制器发送的感知目标报文如果周期设为10 ms且数据场为64字节，单路CAN FD的负载率会快速上升。工程上通常把目标级数据压缩为关键字段，或改用SOME-IP over Ethernet传输大块数据，CAN FD只保留控制指令和状态反馈。

第三个坑是诊断路由与功能寻址混用。EyeQ既支持物理寻址（点对点诊断），也可能参与功能寻址（如0x7DF广播）。如果网关路由表没有区分这两种寻址方式，功能寻址请求可能被错误转发到EyeQ，造成诊断会话异常。建议在网关配置中明确：物理寻址按目标逻辑地址路由，功能寻址按网段广播，EyeQ只响应与自身相关的功能寻址请求。

把这三层拓扑、三种接口角色和三类约束放在一起看，EyeQ域控的节点设计就不再是“接上网线”这么简单。它需要在带宽、实时性、诊断可达性和功能安全之间取得平衡，而这张拓扑图正是后续所有通信矩阵和诊断配置的起点。