1. 联合仿真平台的整体架构与安装前必读1.1 为什么要做CarMaker与NS3联合仿真在智能网联汽车和自动驾驶研发这条线上大家迟早会遇到同一个问题单靠车端动力学仿真或者单靠网络仿真都没法回答“车在复杂交通场景里通信延迟和丢包到底对控制决策有多大影响”这类问题。CarMaker是整车动力学和场景仿真工具能把车辆底盘、传感器、道路模型做得很细NS3则是网络仿真器能模拟V2X通信、协议栈、信道衰减和丢帧。把两者凑在一起就能在仿真环境里跑“真实车辆模型 真实通信模型”的闭环。这套联合仿真平台的典型应用有三类第一车路协同算法的验证比如红绿灯调度和限速提醒第二自动驾驶决策在通信受限条件下的鲁棒性测试比如隧道里信号差、遮挡导致报文丢失第三多车协同编队和碰撞预警算法开发。正因为这两套工具都有很强的专业壁垒安装部署就成了跑通一切的前提。我自己在这个环节踩了不少坑所以把安装全过程整理出来后面的人照着做至少能少走两天弯路。1.2 联合仿真的数据流与组件划分在动手安装之前有必要把两个软件之间到底怎么配合搞清楚否则安装完也不知道该测什么。典型的数据流是这样的CarMaker负责车辆动力学建模、场景搭建、传感器输出运行时会周期性给出车辆的位置、速度、航向角等状态信息这些状态通过一个中间桥接模块传交给NS3NS3负责模拟路侧单元RSU、车载单元OBU以及它们之间的通信链路产生消息收发事件、延迟和丢包结果再反馈给CarMaker侧的应用程序来控制车辆行为。从这个结构可以看出安装阶段就需要保证三样东西齐全CarMaker本体、NS3本体以及两者之间的桥接代码或接口库。很多教程在讲安装时把这套数据流忽略了导致后面联调的时候找不到问题根源。这里先记住一句话联合仿真能不能通首先看两边的环境变量和库依赖是否互相认识其次才谈通信实时性。本文的安装步骤也是按照这个思路组织的先装网络侧再装车辆侧最后做桥接联调。2. 环境搭建与版本选型准备2.1 操作系统与Ubuntu版本选择CarMaker官方支持的主要是Ubuntu LTS版本NS3则对主流Linux发行版的适配都比较友好。但联合仿真最大的坑恰恰在版本兼容性上。我个人建议直接选择Ubuntu 20.04 LTS或22.04 LTS这两个版本在当前CarMaker版本列表里被覆盖得比较全面NS3的编译环境也是在这两个版本上验证最充分。如果条件允许尽量用一台独立的物理机或者配置不低于4核CPU、16GB内存、50GB空闲磁盘的虚拟机。虚拟机的网络模式建议选择桥接模式因为在后续联合仿真中CarMaker和NS3之间的Socket通信需要真实的网络回环环境如果虚拟网络配置不当经常会出现“两个进程都能起来但就是连不上”的诡异问题。系统安装完成后记得先执行一次完整的系统更新sudo apt update sudo apt upgrade -y这一步的意义在后续编译NS3时会体现出来很多依赖包在旧软件源里版本过低会直接导致编译失败。更新完系统后重启一次让内核和库的版本统一。2.2 NS3版本选择和依赖包预装NS3的开源版本迭代很快但并不是越新越好。联合仿真桥接代码通常针对某个特定NS3版本编写如果NS3版本跟桥接代码的API不匹配轻则编译警告重则直接编译失败。我遇到过最典型的情况某桥接代码基于NS3.35开发换成NS3.40之后原来用于启停仿真线程的几个API被重构了整个代码需要大改。比较稳妥的选择是使用NS3.35或同期的稳定发行版这两个版本在联合仿真社区里使用率最高教程和案例也最多。如果项目组没有特殊要求就不要追新版本。NS3的编译依赖于一批基础工具在安装NS3之前先把这些依赖一次性装齐sudo apt install gcc g python3 python3-dev pkg-config \ libboost-all-dev libssl-dev sqlite3 libsqlite3-dev \ libxml2 libxml2-dev libgtk-3-dev libgsl-dev \ libtbb-dev libpcap-dev libfl-dev libfmt-dev \ doxygen graphviz autoconf automake libtool -y这里有几个依赖需要特别说明。libpcap-dev是NS3用来做网络数据包捕获的底层库如果做仿真级别测试可能用不到但NS3编译时默认会检查它缺了会编译不过。libfmt-dev在一些老版本Ubuntu上可能没有单独的包可以用更基础的libstdc替代但推荐还是把版本仓库更新后安装。gsl库是NS3做统计和数学计算用的装不上会影响部分模块的启用。另外需要检查一下g版本是否支持C17标准NS3.35以上的版本会用到C17特性。可以用下面的命令确认g --version如果版本低于GCC 7就说明系统镜像太老建议直接升级系统到22.04 LTS再继续。2.3 CarMaker安装环境要求CarMaker的安装对系统环境的要求比NS3要挑剔一些。它需要特定的图形库、Java运行环境部分版本用于License管理工具和一套专属的授权服务。在官网或者项目邮箱拿到安装包后先不要急着装按照下面的检查单逐项核对确认系统架构是x86_64不支持ARM架构在ARM开发板上装过踩过坑不建议尝试。确认有本地管理员权限因为安装过程中会往/opt目录写入文件。确认系统时间准确License校验会检查时间戳时间偏差超过阈值会导致授权失效。确认没有安装多个版本的CarMaker不同版本会覆盖同一个环境变量配置文件导致模块加载错乱。Java运行时如果系统里没有提前安装sudo apt install openjdk-11-jre -y这里特别强调一下CarMaker安装目录不要选择带中文或空格的路径。例如“/home/user/My Documents/CarMaker”这样的路径后续编译联合仿真代码时绝对会让你怀疑人生。最稳妥的位置是“/home/user/CarMaker”或者“/opt/carmaker”。3. NS3安装与验证3.1 下载源码与编译配置NS3的安装有两种主流方式通过apt直接安装预编译包以及下载源码自行编译。这里建议一定选择源码编译因为联合仿真需要NS3的静态库和头文件参与后续桥接代码的编译预编译包往往不包含配置阶段生成的模块配置文件。源码下载推荐从NS3官网的Release页面获取下载后的压缩包放在工作目录比如“~/workspace/ns3”mkdir -p ~/workspace/ns3 cd ~/workspace/ns3 tar xjf ns-allinone-3.35.tar.bz2 cd ns-allinone-3.35NS3目录下的ns-3.35就是主代码目录其他目录是辅助工具。进入主目录后用NS3的构建工具完成配置cd ns-3.35 ./waf configure --build-profiledebug --enable-examples --enable-tests这一步如果前面的依赖装齐了理论上会看到输出结果里显示“Build profile: Debug”以及一系列模块的状态例如“Build: wlan, wifi, lte, ...”。如果显示某个模块是“Not enabled”并且你是需要的比如wave模块车辆通信常用就要回头检查对应的依赖库是否缺失。在联合仿真场景里wave模块和point-to-point模块是重点前者覆盖DSRC专用短程通信标准后者是CarMaker桥接代码传输车辆状态经常用到的链路模型。配置完成后执行编译./waf build -j4编译过程大约需要10到20分钟取决于机器配置。-j4的意思是使用4个并行任务如果你的机器是8核可以改成-j8加速。如果中途报错最常见的是某个头文件找不到这种时候不要盲目尝试修复优先查看错误信息里提到的缺失头文件属于哪个库然后用apt补装对应开发包再重新执行configure和build。3.2 编译结果验证与基础测试编译完成后强烈建议先跑一个自带的测试用例确认NS3核心功能正常./waf --run hello-simulator如果能看到“Hello Simulator”输出说明NS3的仿真核心和调度器已经能正常跑起来。接下来再测试一下网络模块是否正常跑一个简单的点对点通信示例./waf --run first这个示例会在两个网络节点间通过点对点链路发送数据包输出结果里会出现一些数据包对列状态的日志。如果这个也通过了NS3安装工作就算完成了一大半。还有一个容易被忽略的步骤确认NS3的库文件路径。编译好的库位于“build/lib”目录下后续CarMaker桥接代码编译时需要用pkg-config方式或者手动指定-L参数引用这些库文件。测试一下pkg-config是否能找到NS3的库信息export PKG_CONFIG_PATH$HOME/workspace/ns3/ns-allinone-3.35/ns-3.35/build/lib/pkgconfig pkg-config --list-all | grep ns3如果能看到以ns3开头的包列表说明pkg-config路径配置正确。这个路径信息一定要记着后面写进环境变量配置文件里。4. CarMaker安装与授权配置4.1 获取安装文件与基础安装CarMaker的正式安装文件一般有三种来源官方送测许可、项目组内部License服务器、教育授权。无论哪种方式拿到的通常是一个包含图形安装器或者二进制压缩包的资源包。这里以最常见的Linux二进制包为例。先解压安装包tar -xzf CarMaker_版本号_Linux.tar.gz cd CarMaker_版本号_Linux查看目录下的README或者INSTALL文件确认有没有特殊说明。正式安装通常通过脚本执行./install.sh脚本会询问安装目录、是否安装Matlab接口、是否安装自动化测试组件等。按顺序回答即可需要注意的一点是安装目录不要放在共享目录或者挂载目录下因为License校验服务需要稳定的文件读写权限。安装完成后会在指定目录下生成几个关键子目录包括carmaker、carmakerlinux64、Data、Doc等。这里的carmakerlinux64是实际的运行二进制目录而Data目录存放场景、车辆模型和路面数据。这套目录结构在后面配置环境变量时要原样引用不能自作主张改动。4.2 环境变量与License授权配置CarMaker运行最依赖的就是环境变量配置。安装脚本会生成一个环境变量配置文件一般叫“carmaker.sh”或者“env.sh”位于安装目录下的某个位置通常是“/home/user/CarMaker/carmaker.sh”。打开这个文件查看核心内容里面至少会定义这些变量export CARMAKER/home/user/CarMaker export IPG_HOME$CARMAKER/carmakerlinux64 export LD_LIBRARY_PATH$IPG_HOME/lib:$LD_LIBRARY_PATH export MATLAB_LIBRARY_PATH... export IPGALLOWED...将这些环境变量写入用户级别配置让它每次登录自动加载echo source ~/CarMaker/carmaker.sh ~/.bashrc source ~/.bashrc这里特别说一下IPGALLOWED变量它用于指定允许访问License服务器的IP地址范围。如果做本机仿真测试通常设为“127.0.0.1”或本机局域网IP。如果使用远程License服务器则要设置成服务器的IP地址。这一步设置错误会在启动CarMaker时直接卡在授权验证界面。License授权方面常见的模式分为本地加密锁、本地激活文件和远程License服务器三种。如果你拿到的是远程License服务器的连接方式需要确认服务器端口是开放且网络可通的telnet licence_server_ip 端口号如果连接不通联合仿真平台后续就没法启动因为CarMaker在运行时会反复校验License。我遇到过一个案例某高校实验室把License服务部署在一台Windows服务器上防火墙没有开放UDP端口导致Linux客户端连不上排查了半天才发现是防火墙的问题。4.3 CarMaker首次启动验证安装完成后先不要急着进行联合仿真单独启动一次CarMaker确认自己能跑。进入CarMaker安装目录下找到图形界面启动脚本cd $CARMAKER ./carmaker.sh如果License正常图形界面会弹出来默认加载一个示例场景。在这个界面里可以试着切换视角、调整仿真速度确认基本功能无异常。对于命令行测试场景CarMaker也提供了批处理模式可以通过执行一个已有的测试用例来验证核心引擎是否可运行cd $CARMAKER ./carmakerlinux64/bin/StartSimulation -p TestRun如果在执行过程中没有任何报错并且在结果目录下生成了测量数据文件就说明CarMaker本体已经可以正常运转。到了这个阶段两个独立的仿真工具都已经安装完成接下来的重点就是让它们“对话”。5. 联合仿真的桥接编译与配置5.1 桥接代码的概念与定位CarMaker和NS3之间默认没有互相通信的能力需要通过一段桥接代码把CarMaker的车辆状态实时写入NS3的仿真节点然后NS3仿真出的通信结果再通过回调机制返回到CarMaker的应用层。这段代码的形态通常是一个NS3模块加上一个CarMaker接口库。在安装阶段我们并不需要深入编写业务逻辑而是要完成两件事第一把桥接代码编译出可执行的动态库或者可执行文件第二把两边的配置参数对上比如端口号、仿真步长、节点数量。常见的桥接项目结构大致如下bridging_ws/ ├── src/ │ ├── ns3_bridge_module/ │ └── carmaker_adapter/ ├── build/ └── configure.sh如果项目组内部有现成的桥接代码直接按照它的README来编译即可。如果是自己从零开始建议不要一开始就追求复杂的无线信道模型先用最简单的点对点链路打通数据通路验证两个软件能互通再逐步把信道模型换成更真实的WAVE/5G模型。5.2 编译桥接库的完整流程以一份典型的桥接代码为例它的编译过程大致是先编译NS3模块再编译CarMaker适配器最后链接生成联合仿真运行入口。首先把桥接模块的源码复制到NS3的src目录下cp -r /path/to/src/ns3_bridge_module ~/workspace/ns3/ns-allinone-3.35/ns-3.35/src/然后重新配置和编译NS3让新模块被识别cd ~/workspace/ns3/ns-allinone-3.35/ns-3.35 ./waf configure --build-profiledebug --enable-examples --enable-tests ./waf build -j4编译完成后确认模块库文件已经生成例如“build/lib/libns3.35-ns3_bridge_module-debug.so”。如果这个文件存在说明桥接模块可以被NS3调度器加载。接下来编译CarMaker适配器。这个环节最容易出错的是头文件路径和库路径。CarMaker头文件位于“$CARMAKER/carmakerlinux64/Include”目录库文件位于“$CARMAKER/carmakerlinux64/lib”目录。用g编译时需要明确指定这些路径g -stdc17 -shared -fPIC -o libcarmaker_adapter.so \ -I$CARMAKER/carmakerlinux64/Include \ -I$HOME/workspace/ns3/ns-allinone-3.35/ns-3.35/build/include \ -L$CARMAKER/carmakerlinux64/lib \ -L$HOME/workspace/ns3/ns-allinone-3.35/ns-3.35/build/lib \ -lns3.35-ns3_bridge_module-debug \ -Wl,-rpath,$CARMAKER/carmakerlinux64/lib \ -Wl,-rpath,$HOME/workspace/ns3/ns-allinone-3.35/ns-3.35/build/lib这里的-Wl,-rpath参数很关键它让生成的动态库在运行时能找到NS3的库文件避免出现“cannot open shared object file”的错误。很多新手在编译阶段完全不报错一运行就报库缺失就是因为漏了rpath设置。5.3 配置文件参数匹配桥接代码编译通过后需要在一份配置文件里声明通信参数。这份配置文件通常以XML或者JSON格式存在核心参数包括参数名推荐值说明SimStep0.01CarMaker仿真步长秒需与NS3的仿真时钟步长匹配Ns3Port50010NS3侧监听的UDP端口用于接收车辆状态VehicleCount2仿真车辆数必须与CarMaker场景中车辆数一致ChannelModelPointToPoint初期联调用点对点模型后续可换为WAVE模型RsuCount1路侧单元数量通常固定为1这里重点强调的是仿真步长。CarMaker默认步长可能设为1毫秒或者10毫秒而NS3默认的时间单位是纳秒级。如果两侧的步长设置差异太大数据到达的顺序会乱最直观的表现就是车辆位置跳变或者通信事件乱序。联调初期步长可以适当放宽到10毫秒等确认基本通信正常之后再逐步缩小。5.4 环境变量与启动顺序联合仿真的启动顺序有讲究。先启动NS3侧的仿真进程让它进入监听状态然后再启动CarMaker仿真场景。NS3进程一般是一个后台运行的程序命令行示例./run_ns3_bridge --configbridge_config.json --port50010 NS3进程启动后会创建一个Socket监听50010端口等待CarMaker侧发送车辆状态数据包。可以用ss命令确认端口确实处于监听状态ss -ulpn | grep 50010看到LISTEN状态后再启动CarMaker侧。在CarMaker的图形界面或者批处理脚本中指定运行联合仿真模式通过“Simulation Parameters”配置窗口把输出接口指向本地回环地址“127.0.0.1”和对应端口。如果一切顺利CarMaker侧的命令行窗口会持续输出类似“Packet sent at time xxx”的日志NS3侧则会输出“Packet received”的日志。这就是联合仿真平台跑通的标志。6. 常见问题与故障排查6.1 安装与联合仿真典型问题速查表根据我自己折腾的经验以及身边人遇到的高频问题整理成一张速查表安装的时候对照排查比翻文档省事很多。现象可能原因解决思路NS3编译时提示缺少“ns3/core-module.h”编译路径不对或waf configure失败回到ns-3.35根目录重新configure确认输出里模块均为enabledCarMaker启动后卡在授权界面License服务器连接失败或IPGALLOWED设置错误检查License服务器端口连通性确认IPGALLOWED正确桥接代码编译找不到CarMaker头文件CARMAKER环境变量未加载执行source ~/CarMaker/carmaker.sh用echo $CARMAKER验证运行时提示找不到libns3库缺少rpath配置编译时增加-Wl,-rpath参数或运行前export LD_LIBRARY_PATHNS3端口监听正常但CarMaker收不到数据两侧仿真步长不匹配导致数据包乱序将两个软件的步长统一例如都设为0.01秒CarMaker批处理模式下无法加载NS3场景路径配置文件里的路径用了相对路径工作目录不一致在配置文件中全部改为绝对路径联合仿真运行几十秒后卡死数据包队列满了CarMaker侧接收线程没有及时消费增大Socket缓冲区或在桥接代码中增加Qt事件处理等待机制第二个现象其实是CarMaker运行的老大难特别是远程License模式每次机器重启后有时会忘记启动License客户端服务这时候用systemctl或者ps检查License进程是否活跃即可。6.2 联调过程中的独家避坑技巧第一个避坑技巧在两套系统联调时先用脚本模拟CarMaker发送固定的车辆状态数据来测试NS3侧接收等NS3侧日志稳定显示收包后再启动真正的CarMaker。这能大大缩小问题排查范围把“通信问题”和“车辆模型问题”分开。简单的模拟脚本用Python就好按照约定的数据帧格式发送UDP数据包import socket import struct import time sock socket.socket(socket.AF_INET, socket.SOCK_DGRAM) packet struct.pack(Ifff, 1, 100.0, 200.0, 30.0) while True: sock.sendto(packet, (127.0.0.1, 50010)) time.sleep(0.01)如果NS3收到数据并打印日志说明通信链路是通的问题出在CarMaker侧的报文格式或发送频率上。第二个避坑技巧NS3仿真时钟推进速度远快于真实时间因为它是事件驱动的。而CarMaker受限于动力学积分运行速度无法大幅超过实时。两者联合时NS3容易“等待”得过于超前导致内存中出现大量积压事件。一个经验做法是把NS3启用的节点数量控制在20个以内RSU和OBU之间的数据包发送间隔不要小于50毫秒否则仿真耗时会成倍增加。第三个避坑技巧如果项目里同时存在多个版本的NS3库文件尽量通过LD_LIBRARY_PATH明确指定要用的版本否则运行时可能加载到旧版本库导致段错误。用ldd命令检查可执行文件的动态库依赖ldd ./run_ns3_bridge如果看到链接到的Libns3路径不是预期版本就修改LD_LIBRARY_PATH的顺序确保目标版本的库路径在最前面。6.3 遇到问题时的系统排查思路有时候问题很隐蔽表面上是连接错误实际上是系统层面的库冲突。我推荐按三层分析法排查第一层看网络用ss和tcpdump确认UDP端口是否在实际收发数据第二层看日志把NS3的日志级别调到最大开启所有的日志分组第三层看内存如果仿真跑了有一段时间用htop观察NS3进程的内存占用如果内存持续飙升大概率是仿真事件积压。三层分析法能过滤掉大多数表面问题。我曾经遇到过一起很奇葩的案例两个进程都在同一台机器上端口也开着但NS3就是收不到数据。最后定位到原因是CarMaker运行在容器里容器网络的回环地址和宿主机的回环地址不互通。把容器网络模式改成host模式后立刻通了。如果大家也在容器里跑CarMaker提前检查这一点会省去大量时间。7. 最后的实操经验补充整个安装过程走下来我个人最深的感触是不要追求一次性把WAVE信道模型、多节点协同、动态场景全部配置到位而是分阶段跑通。第一步只要是“CarMaker发出的数据包能到NS3”就算成功第二步跑通双向链路第三步再引入复杂信道模型。每一阶段都在上一阶段基础上改动一个变量出了任何问题都能快速定位。另外建议在环境装好之后立刻把整个工作目录打包备份。因为NS3的编译产物、CarMaker的环境变量配置文件、桥接代码的二进制这些组合起来的完整环境很多时候具备“一次性搭建属性”——重新装一遍的成本远高于保存一份快照的成本。用tar打包整个联合仿真工作目录保留到网盘或者移动硬盘里后续换机器或者环境崩溃时能快速恢复tar -czf cosim_platform_backup.tar.gz ~/workspace/ns3 ~/CarMaker bridge_ws最后再分享一个小技巧如果实验室或团队里有多个同事都要用这套环境不要让他们各自在本地重复安装而是在服务器上搭好一套完整环境然后通过远程桌面或远程运行的方式共用。这既省去重复踩坑也方便统一版本管理。CarMaker的License本身是按浮动授权走的共用服务器还能提高License利用率。我目前的实验环境就是这么搭的实际效果比一人一套虚拟机好太多出问题和维护的成本都大幅降低。
