AI车路协同配置：从环境准备到路侧单元联调

AI车路协同配置的核心是把路侧感知设备、边缘计算节点和路侧单元（RSU）接入同一套可通信、可同步、可验证的基础环境，让感知数据能稳定上传并触发协同决策。
本文按零基础可执行的方式，讲清配置前要准备什么、设备侧和节点侧怎么改、联调时怎么确认成功，以及最容易出错的几个地方。

先确认你的场景和前置条件

AI车路协同通常涉及三类设备：摄像头或雷达等感知设备、部署在路侧的边缘计算节点、负责车路通信的RSU。
配置前先确认以下条件，否则后面容易反复返工。

• 网络规划：确认边缘节点和RSU是否在同一网段，是否需要划分管理VLAN和业务VLAN。建议管理口和业务口分开，避免调试流量影响业务数据。
• 时间同步：车路协同对时间戳敏感，边缘节点和RSU应统一使用NTP或PTP同步。没有统一时钟时，感知融合结果容易出现错位。
• 设备访问方式：确认RSU和边缘节点是否支持SSH或Web管理后台，默认管理地址、账号和密码是否已从设备标签或交付文档中获取。
• 软件环境：边缘节点若运行AI推理服务，需要确认操作系统版本、容器运行时和推理框架已按交付要求安装。本文不限定具体版本，请以设备交付文档为准。

操作前建议先备份RSU和边缘节点的现有配置，涉及网络参数修改时保留一条带外管理通道，避免改错后无法远程登录。

配置边缘节点的基础网络与时间同步

边缘节点是AI车路协同配置里最先要调通的部分。
以常见的Linux边缘节点为例，先确认网卡名称和当前地址：

ip addr show
ip route show

假设业务网卡为eth1，管理网卡为eth0，需要把业务地址配置为静态地址。
以Ubuntu的netplan为例，编辑/etc/netplan/01-netcfg.yaml：

network:
  version: 2
  ethernets:
    eth0:
      dhcp4: true
    eth1:
      addresses:
        - 192.168.10.20/24
      routes:
        - to: default
          via: 192.168.10.1

保存后执行sudo netplan apply，再用ip addr show eth1确认地址已生效。
接着配置NTP同步，编辑/etc/systemd/timesyncd.conf，取消NTP=行的注释并填入可用的内网NTP地址：

[Time]
NTP=192.168.10.1

执行sudo systemctl restart systemd-timesyncd后，用timedatectl status查看System clock synchronized是否为yes。
如果边缘节点与RSU之间需要PTP，则按设备支持的PTP模式单独配置，不要和NTP混用在同一网卡上。

RSU侧的网络与通信参数配置

RSU的配置入口因厂商而异，常见方式是通过Web管理后台或SSH登录后修改配置文件。
无论哪种方式，重点检查三项：管理地址、业务地址和上行目标地址。

以Web后台为例，一般路径为“网络设置 → 接口配置”，将业务口地址设为与边缘节点同网段的静态地址，例如192.168.10.30/24，网关指向边缘节点或汇聚交换机。
然后进入“通信配置”或“PC5配置”页面，确认RSU与边缘节点之间的通信端口和协议与边缘侧保持一致。

如果通过SSH配置，修改前先备份：

cp /etc/rsu/network.conf /etc/rsu/network.conf.bak

在配置文件中确认业务地址、子网掩码和默认网关三项，保存后重启网络服务。
重启后用ping 192.168.10.20测试RSU到边缘节点的连通性，再用ping 192.168.10.30从边缘节点反向测试。
双向都能通，才说明基础链路配置正确。

注意：RSU的业务地址不要和感知设备地址冲突，同一网段内建议按设备类型分配地址段，例如感知设备用.100-.150，RSU用.30-.50，边缘节点用.20，方便后续排错。

联调验证：确认数据链路真的通了

配置完成后不能只看接口状态，要验证数据是否从感知侧到达边缘节点。
可以按以下顺序检查：

1. 在边缘节点上查看是否收到RSU或感知设备的上报数据。如果服务以容器运行，用docker logs --tail 100 容器名查看最近日志；如果是系统服务，用journalctl -u 服务名 -n 100查看。
2. 检查边缘节点业务端口是否处于监听状态，例如ss -lntp | grep 端口号，确认服务没有绑定到错误网卡。
3. 在RSU侧查看上行统计或通信日志，确认发送计数在增长。不同厂商界面名称不同，一般在“状态监控”或“通信统计”中查看。
4. 用tcpdump -i eth1 -nn host 192.168.10.30在边缘节点抓包，确认能收到RSU发来的报文。抓包有数据但应用无日志时，优先检查防火墙和端口配置。

如果联调时发现时间戳偏差较大，回到时间同步步骤检查NTP或PTP状态；
如果发现数据断续，优先检查网线、光模块和交换机端口错误计数，用ethtool -S eth1查看是否有丢包或CRC错误。

常见配置错误与避坑清单

• 管理地址和业务地址配在同一网段且未做隔离，调试时容易误改业务链路。建议管理口保持独立，至少保留一条可回退的登录路径。
• 只改了边缘节点地址，忘了同步修改RSU的上行目标地址，导致数据发往旧地址。修改一侧地址后，另一侧要同步核对。
• 防火墙默认拒绝业务端口，表现为能ping通但收不到数据。用ss -lntp和tcpdump交叉确认后，按最小范围放行端口。
• NTP服务器不可达时，边缘节点时间会逐渐漂移，短时间联调可能看不出问题，长时间运行后时间戳对不齐。配置完成后用timedatectl确认同步状态。
• 修改网络配置前没有备份，改错后只能现场恢复。涉及远程设备时，先备份再改，并保留带外管理方式。

完成以上步骤后，AI车路协同配置的基础链路就算调通了。
后续接入感知算法和协同决策服务时，建议保持网络、时间同步和端口配置不变，只在应用层做增量调整，这样出问题时更容易判断是链路问题还是业务问题。
如果设备交付文档对端口和协议有明确要求，以交付文档为准，本文命令和路径仅作为通用参考。