去年参与一个自动驾驶项目的时候，遇到过一次让整个团队焦头烂额的问题。车辆在测试场跑得好好的，突然域控制器就报告收不到云端下发的地图更新指令了。查了两天才发现，是车载网关和域控制器之间的通信链路出了幺蛾子，数据包在网关内部被错误地路由到了其他接口。
这件事让我深刻意识到，车载网关和域控制器之间的配合，远比表面看起来复杂得多。今天就从工程实践的角度，聊聊这两个设备是怎么协同工作的。
域控制器在整车架构里的位置
先说说域控制器是什么。传统汽车的电子架构是分布式的，几十上百个ECU各管一摊。但到了智能汽车时代，这种架构已经不适应了。自动驾驶需要强大的计算能力，需要实时处理来自十几个传感器的海量数据。
域控制器就是在这个背景下出现的。它把原来分散的功能集中到几个高性能的计算平台上。一台L4级无人车通常会有3-4个域控制器：智能驾驶域控制器、智能座舱域控制器、车身控制域控制器、动力域控制器。
智能驾驶域控制器是核心，负责自动驾驶的感知、决策、规划、控制。市面上常见的有NVIDIA Drive Orin、地平线征程5、华为MDC系列。算力从几十TOPS到上千TOPS不等。
这个域控制器需要和车载网关打交道，原因很简单：它需要跟外界通信。
为什么域控制器不直接联网
有人可能会问，域控制器这么强大，为什么不直接集成4G/5G模组，还要通过车载网关？
这个问题在行业里也讨论过。确实有一些方案是把通信模组直接集成到域控制器里，但主流方案还是分离的。原因有几个。
第一是功能安全的要求。域控制器是ASIL-D级别的安全关键部件，任何故障都可能导致事故。如果把通信模组集成进去，通信模组的问题可能会影响到整个域控制器。分离开来，通信出问题了，域控制器还能继续本地运行。
第二是认证和迭代周期不一样。域控制器的硬件和软件认证周期很长，动辄一两年。但通信技术迭代很快，4G升5G，5G又分R15、R16、R17。把通信模组独立出来，可以根据需求快速升级，不用整个域控制器重新认证。
第三是成本和供应链管理。车载网关可以统一采购，不同车型、不同配置的车可以用同样的网关。域控制器则根据自动驾驶等级不同，配置差异很大。分离开来更灵活。
第四是网络安全隔离。域控制器处理的是车辆控制指令，非常敏感。如果直接暴露在互联网上，攻击面太大。通过网关做中转，可以在网关层做安全隔离和防护，域控制器只跟内网打交道。
所以主流架构是：域控制器通过车内以太网连接到车载网关，网关负责对外的4G/5G通信。
它们之间传输什么数据
域控制器和网关之间的数据流，大致可以分为几类。
第一类是云端下发的控制指令。比如远程启动车辆、修改行驶路线、设置地理围栏、OTA升级任务。这些指令对实时性要求高，延迟要控制在几百毫秒以内。数据量不大，但很关键。
第二类是高精地图数据。域控制器要用高精地图做路径规划和定位校准。地图数据量很大，一个城市的地图可能几个GB。不可能全部预装在车上，需要根据车辆位置动态下载。网关要管理地图数据的下载、缓存、更新。
第三类是传感器数据上传。用于训练自动驾驶算法的数据，包括摄像头视频、激光雷达点云、毫米波雷达数据。这些数据通常是域控制器处理完之后，选择性地通过网关上传到云端。数据量非常大，是上行带宽的主要消耗。
第四类是车辆状态数据和诊断数据。车速、转向角、制动状态、各种传感器的健康状态，都要实时上报到云端监控平台。数据量不大，但频率高，通常是10Hz或者更高。
第五类是V2X通信数据。如果车辆支持V2X功能，域控制器需要跟路侧单元、其他车辆通信。V2X数据对延迟要求极高，通常在100毫秒以内。这部分数据可能走专门的C-V2X通信模组，但也需要通过网关做协调。
这五类数据的特点完全不同，对带宽、延迟、可靠性的要求也不一样。网关要能区分处理，不能一刀切。
通信协议和接口标准
域控制器和网关之间用什么协议通信？这是个很实际的问题。
车内以太网现在基本是标配，千兆带宽。物理层通常用100BASE-T1或者1000BASE-T1，这是专门为汽车环境设计的单对以太网标准，抗干扰能力强。
传输层协议有几种选择。最常见的是TCP/IP，成熟稳定，开发简单。但TCP有个问题，就是重传机制导致的延迟不确定性。自动驾驶对确定性延迟要求很高，TCP不太合适。
所以越来越多的项目开始用UDP，甚至是基于UDP的自定义协议。优点是延迟可控，缺点是可靠性需要应用层自己保证。通常会加上应用层的ACK机制、序列号、超时重传，把UDP做成可靠传输。
更高级的方案是用SOME/IP协议。这是AUTOSAR定义的服务化通信协议，专门为汽车设计。支持服务发现、事件订阅、可靠性保证。缺点是复杂度高，开发周期长。
还有一个趋势是TSN（Time-Sensitive Networking，时间敏感网络）。TSN是一组IEEE标准，在以太网上提供确定性延迟和带宽保证。对自动驾驶这种安全关键应用来说，TSN是未来方向。但目前还在推广阶段，成本也比较高。
我们项目里用的是混合方案。控制指令用TCP，因为必须可靠到达。传感器数据上传用UDP，允许一定程度的丢包。地图下载用HTTP/HTTPS，因为要跟云端服务器兼容。V2X数据用专门的C-V2X协议栈。
网关要能同时处理这几种协议，做好路由和转发。这对网关的处理能力要求很高。
带宽分配和QoS管理
千兆以太网听起来带宽很大，但实际用起来会发现，很容易打满。
想想看，激光雷达的点云数据，一个雷达就是200Mbps。摄像头的视频流，一个1080P摄像头压缩后也要10-20Mbps。再加上毫米波雷达数据、定位数据、控制指令、地图下载，总带宽需求可能上千Mbps。
如果所有数据都往网关挤，会发生什么？缓冲区溢出，丢包，延迟飙升。最要命的是，关键的控制指令可能被淹没在海量的传感器数据里，收不到或者延迟太高。
所以必须做QoS管理，给不同类型的数据分配优先级。
最高优先级：紧急控制指令。比如远程紧急制动、碰撞预警。这类数据要绝对保证，哪怕丢掉其他所有数据。通常会预留一定的带宽，专门用于紧急指令。
第二优先级：V2X通信数据。红绿灯信息、前方事故通知、车辆协同。延迟要求很高，但数据量小。
第三优先级：常规控制指令和车辆状态数据。这是自动驾驶系统正常运行必需的。
第四优先级：地图数据下载。重要但不紧急，可以在带宽空闲的时候下载。
最低优先级：训练数据上传。完全可以延后，甚至可以等车辆回到停车场再传。
在网关上实现QoS，通常用Linux的流量控制工具。tc命令可以配置复杂的队列调度算法，比如PRIO（优先级队列）、HTB（分层令牌桶）、CAKE（Common Applications Kept Enhanced）。
举个例子，可以把以太网接口分成几个队列，高优先级队列总是先发送。即使传感器数据把低优先级队列塞满了，高优先级的控制指令也能立刻发出去。
但这里有个难点：怎么识别数据包的优先级？如果用应用层协议，需要深度包检测，解析应用层数据包。这会增加延迟和CPU负担。
更好的办法是用VLAN优先级标记或者DSCP字段。域控制器在发送数据的时候，就在以太网帧或IP包头里打上优先级标签。网关只需要看标签，不用解析整个数据包，就能决定放到哪个队列。这样延迟很低，性能损耗小。
安全隔离和防护
域控制器处理的是车辆控制指令，如果被攻击者入侵，后果不堪设想。车载网关作为车辆和外界的唯一通道，必须做好安全防护。
第一道防线是防火墙。网关上要配置严格的防火墙规则，只允许必要的端口和协议通过。所有从互联网来的数据包，默认拒绝，只有在白名单里的才放行。
第二道防线是入侵检测。监控异常的流量模式，比如突然的流量暴增、扫描探测、异常的连接请求。一旦发现可疑行为，立刻报警甚至自动阻断。
第三道防线是数据加密。域控制器和云端的通信，必须用TLS或者IPsec加密。即使数据包被截获，也无法解密。密钥管理是个挑战，通常会用硬件安全模块（HSM）来存储和管理密钥。
第四道防线是身份认证。不是任何云端服务器都能给域控制器下发指令的，必须经过认证。通常用数字证书，车辆和云端互相验证身份。证书要定期更新，过期的证书自动失效。
第五道防线是审计日志。所有通过网关的数据流都要记录，包括时间、源地址、目的地址、数据量、协议类型。出了问题可以追溯。日志本身也要保护好，防止被篡改。
这些防护措施会增加延迟和计算开销，但为了安全是必须的。关键是要平衡安全和性能，不能因为加密导致延迟超标，也不能为了性能牺牲安全。
功能安全的考虑
自动驾驶系统必须符合ISO 26262功能安全标准。车载网关虽然不是直接的控制部件，但它的失效也可能导致安全问题，所以也要满足一定的功能安全等级。
最核心的要求是故障诊断和冗余。网关要能实时监测自己的健康状态，包括CPU占用率、内存使用率、网络连接状态、接口状态。一旦发现异常，要立刻报告给域控制器。
通信链路也要有冗余。比如配两张SIM卡，主用和备用。主链路断了，自动切换到备用链路。切换时间要足够短，不能导致通信中断超过安全时限。
有些项目会用双网关方案，两个网关互为备份。一个工作，一个待机。主网关出问题了，备用网关立刻接管。这种方案成本高，但可靠性好。
另一个要求是确定性行为。网关不能出现不可预测的延迟或丢包。所有的异常情况都要有预案，系统要能优雅降级，不能直接崩溃。
比如带宽不够用了，怎么办？不能让所有数据包都排队，导致延迟全面上升。应该按优先级丢弃低优先级数据，保证高优先级数据正常传输。这就是我们说的优雅降级。
第三个要求是时间同步。域控制器、网关、各个传感器的时钟必须同步，误差要在微秒级。否则数据的时间戳就对不上，无法做多传感器融合。
网关通常会跑NTP客户端或者PTP协议，从GPS或者云端时间服务器同步时间。然后把时间分发给车内的其他设备。这里要考虑网络延迟的影响，做延迟补偿。
OTA升级中的角色
车辆的OTA升级越来越常见，不仅是娱乐系统，连域控制器的固件也可以远程升级。车载网关在OTA流程中扮演关键角色。
第一步是下载升级包。升级包通常几个GB，不能一次性下载，会耗尽带宽。网关要分段下载，利用车辆空闲时间慢慢下载。比如夜间停车的时候，或者在WiFi覆盖区域的时候。
下载过程中要做完整性校验。每下载一个分段，都要验证哈希值。最后下载完了，还要验证整个升级包的数字签名，确保没有被篡改。
第二步是分发给域控制器。升级包下载到网关后，要传给域控制器。这个传输过程也要可靠，不能因为网络问题导致升级包损坏。通常会用可靠传输协议，带重传和校验。
第三步是升级过程中保持通信。域控制器在升级的时候，可能会重启，可能会短时间失联。网关要能处理这种情况，不能因为域控制器暂时不响应就报错。
同时，网关要监控升级进度，定期向云端汇报。如果升级卡住了或者失败了，云端能及时知道，可以远程干预。
第四步是回滚机制。如果升级后发现问题，要能回滚到旧版本。域控制器会保留旧固件的副本，通过网关接收回滚指令后，可以恢复。
OTA升级失败的风险很高，因为涉及的环节太多。网络中断、存储空间不足、升级包损坏、兼容性问题，都可能导致失败。所以整个流程要设计得非常鲁棒，每一步都要有异常处理和恢复机制。
延迟和抖动的优化
自动驾驶对端到端延迟要求很高。从云端下发一个控制指令，到域控制器接收并执行，整个链路延迟要控制在几百毫秒以内。
这个延迟预算怎么分配？云端到网关的4G/5G传输可能占100-200毫秒，网关内部处理10-50毫秒，网关到域控制器的车内以太网传输5-10毫秒，域控制器处理和执行50-100毫秒。
可以看到，网关内部的处理延迟虽然不是最大头，但也不能忽视。特别是当网关负载高的时候，延迟可能会飙升。
优化延迟的办法有几个。第一是减少中断处理时间。网络数据包到达时会产生中断，中断处理函数要尽可能快，不能做太多事情。复杂的处理放到软中断或者工作队列里做。
第二是用高性能的网络协议栈。Linux内核的网络栈虽然功能完善，但为了通用性牺牲了一些性能。可以用DPDK（Data Plane Development Kit）这种用户态网络栈，绕过内核，直接从网卡接收数据包。延迟能降低一个数量级。
第三是用零拷贝技术。数据包在内核态和用户态之间拷贝很耗时。用内存映射或者专门的零拷贝API，可以让数据包直接在网卡和应用之间传递，不经过内存拷贝。
第四是CPU绑定和优先级调整。把关键的网络处理线程绑定到特定的CPU核心，避免线程在不同核心间迁移导致的缓存失效。同时提高线程优先级，让它能抢占其他低优先级任务。
抖动（jitter）也是个问题。延迟不仅要低，还要稳定。如果平均延迟是50毫秒，但有时候会突然跳到200毫秒，这种不确定性对实时系统来说很致命。
降低抖动的办法主要是避免突发负载和资源竞争。比如不要让CPU满负荷运行，留一些余量。不要让内存用满，避免频繁的页面交换。不要让多个高优先级任务同时运行，造成相互抢占。
不同场景下的架构变化
车载网关和域控制器的配合方式，在不同应用场景下会有差异。
封闭场景的无人车，比如矿区、港口、园区，通常会部署专网。这种情况下，网关可以简化一些。不需要支持漫游，不需要考虑运营商信号覆盖。可以用WiFi或者5G专网，带宽和延迟都很可控。
但封闭场景对可靠性要求更高，因为没有人工接管的余地。网关的冗余设计要做得更好，故障后能自动恢复。
开放道路的乘用车，场景最复杂。高速公路、城市道路、地下车库、隧道，网络状况千变万化。网关要能适应各种网络环境，自动选择最优的通信方式。
而且乘用车的成本压力大，不能像商用车那样堆料。网关要在性能、成本、可靠性之间找平衡。
商用车队，比如robotaxi或者无人配送车，通常由运营公司统一管理。网关可以和车队管理平台深度集成，提供更丰富的功能。比如车辆调度、远程诊断、数据分析。
车队规模大了，流量费用也是个问题。网关要做好流量管理和优化，在保证功能的前提下尽量节省流量。
未来的演进方向
车载网关和域控制器的架构还在演进中。
一个趋势是网关功能融合到域控制器里。随着域控制器算力越来越强，体积越来越小，把通信模组集成进去在技术上已经可行。这样可以减少一个单独的硬件，降低成本和复杂度。
但融合的挑战在于功能安全和认证。把通信模组集成进域控制器，意味着整个系统的ASIL等级要提升，认证难度和成本都会增加。所以短期内分离架构还会是主流。
另一个趋势是边缘计算能力的增强。网关不再是简单的数据转发，而是要在本地做一些智能处理。比如数据过滤、格式转换、简单的AI推理。这样可以减少需要传输到云端的数据量，降低带宽和延迟。
第三个趋势是软件定义网络。网关的功能越来越多地由软件实现，硬件只提供基本的转发能力。这样可以通过OTA升级来增加新功能，不用换硬件。
TSN技术的应用也是大方向。确定性延迟和带宽保证对自动驾驶太重要了。虽然现在TSN设备还比较贵，但随着规模化，成本会降下来。
从我自己这几年的经验看，车载网关和域控制器的配合，本质上是在解决确定性通信的问题。怎么在不确定的网络环境下，提供确定性的服务质量，这是核心挑战。技术在进步，但基本矛盾不会变。做好这件事需要从协议设计、系统架构、软硬件优化等多个层面综合考虑，没有捷径可走。
