CarMaker入门指南：从车辆动力学仿真到ADAS测试场景搭建

1. 为什么那么多OEM和Tier1都在用CarMaker，建议你先理解这一点

我第一次在项目里接触CarMaker，是在一个ADAS功能开发的初期。当时BLE（自动紧急制动）算法已经写完，但每一次上车实测的成本都让人心疼——场地租赁、车辆改装、测试工程师排期，一个白天下来可能只跑得完五六个场景，而且有相当一部分工况是不可控的：同一个场景，上午跑和下午跑，传感器感知结果可能就有差异。后来同事建议把算法验证放到CarMaker里先跑一轮，我当时对它的认知还很粗浅，以为这只是个“能在电脑里开车”的玩具。结果用了两周之后，我意识到这个工具在智能驾驶开发链条里的位置，比大多数人想象的要重要得多。

很多刚入行的工程师会把CarMaker单纯理解成“车辆动力学仿真软件”。这个说法没有错，但格局小了。它真正强大的地方在于：它是一个完整的整车级仿真平台，覆盖了车辆动力学模型、驾驶员模型、道路交通环境、传感器模拟、场景编辑、自动化批量测试，甚至直接支持硬件在环（HIL）连接。换句话说，你可以在办公室里用一个纯软件的方案，把一台真实的测试车搬到虚拟世界里，然后把你的感知算法、控制算法、甚至真实的ECU都接上去跑测试。

这套东西适合谁？我接触下来，主要是这三类人：

• 智能驾驶算法工程师：需要大量场景验证AEB、ACC、LKA等功能的边界，在CarMaker里搭场景比实车快得多，也安全得多。
• 底盘与车辆动力学正向开发工程师：用它的车辆模型做操稳性仿真、悬架参数敏感性分析，或者用它做控制器的快速原型验证。
• HIL测试工程师：把Simulink控制模型或者真实控制器接到CarMaker的实时环境里，做传感器信号级或动力学级的闭环测试。

如果你正在做的项目牵扯到“车要怎么动”“人在怎么开”“路上有什么情况发生”“传感器能看到什么”这四件事的任意一件，CarMaker总能在某个环节帮上忙。这篇文章不会讲太多底层理论，而是按一条实际项目里最常走的路径，带你把CarMaker从安装到跑通第一个完整仿真，把整个流程串起来。

2. 先用最短时间把环境跑起来，版本、License和目录结构一次讲清

2.1 版本选择和License的坑，不要等装完才后悔

CarMaker的版本迭代比较快，常用的大版本有8.x、9.x、10.x，各版本在GUI布局和关键字（Keyword）命名上有差异，网上的教程很多是基于旧版本的，照抄命令很容易踩坑。我的建议是：以你手里License对应的版本为准，不要盲目追最新版。很多公司采购的是固定版本号，比如8.1.1或9.0，版本之间的大模块功能差异不大，但菜单名称和部分配置文件的写法会变。如果需要在多个版本间切换，一定要把环境变量分开设置好。

另一个需要提前确认的是License类型。CarMaker的License分为**本地锁（Dongle）和网络License（Floating）**两种。用Dongle相对省心，插上就能识别；浮动License则需要配置LM_LICENSE_FILE或IPG_LICENSE_FILE环境变量指向License Server。很多人装完启动时报“License not found”，十有八九是这个环境变量没配对，或者服务端的端口被防火墙拦了。

2.2 安装完成后的目录结构，越早看懂越省心

安装完成之后，你会看到几个固定目录。这里我直接给出一张我当时整理过的结构表，方便你对照：

这个用户工作目录的概念特别重要。CarMaker默认会把当前工程文件、测试结果、日志都写到~/IPG/...下面，而不是装软件的系统目录。所以如果你的项目想迁移到另一台机器，直接把用户目录打包带过去就行了。

2.3 启动前的环境变量检查清单

在跑第一个仿真之前，建议你花两分钟确认一下这几个环境变量，实测下来这个动作能省掉后面大量的排查时间：

• IPG_HOME：指向软件安装根目录，很多脚本依赖它定位文件。
• IPG_LICENSE_FILE或LM_LICENSE_FILE：指向License Server或本地License文件路径。
• PATH：是否包含/IPG/carmaker/linux64，保证在终端里能直接敲carMaker启动。

配置完之后，在终端敲一下carMaker或者用启动脚本CMStart。如果GUI能正常弹出来，恭喜，环境基本OK了，可以开始搭模型跑仿真。

3. 抓住CarMaker最大的学习杠杆——主模型（Main Model）到底是一个什么样的概念

CarMaker的官方文档里反复出现一个词：主模型（Main Model）。很多新手一上来就对着满屏的参数表发懵，不知道这些参数怎么组织。我从实际使用的感受来说，把它理解成“一台虚拟整车的完整描述”就够了。

每一台真实的车辆都有几个核心子系统：车身、悬架、转向、动力总成、制动系统、轮胎等。CarMaker把这些物理系统组织成了两个大类：车辆模型（Vehicle Model）和被控对象模型（Plant Model）。车辆模型描述的是车辆的机械动力学部分，也就是你踩油门、打方向盘之后，车辆怎么响应；而被控对象模型描述的是电控部分，比如你发送一个AEB制动请求，制动系统如何响应这个请求。

对应的，CarMaker提供了几个核心组件，我帮初学者提炼成一个四层模型来看：

• Driver（驾驶员模型）：模拟人的驾驶行为。它可以实现车道保持、路径跟驰、速度控制，甚至能设定加速踏板的操作风格。这个模块决定了“谁在开车”。
• Traffic（交通参与者模型）：路上的其他车辆、行人、摩托车。这些对象控制的是“路上还有什么”。
• Road（道路模型）：描述车道线、曲率、坡度、摩擦系数、路面附着条件等。
• Vehicle（车辆模型）：整车的动力学响应，包括纵横向运动和垂向振动。

这四个模块共同构成了你在GUI的“Test Run”窗口里看到的那台虚拟车的运行环境。你接下来做的所有操作，本质上都是围绕这四部分去改参数、加场景、配模型。

理解了主模型的结构，再去看CarMaker的目录就很容易了。车辆相关的模型文件放在data/Vehicle下，道路文件在data/Road下，驾驶员行为文件在data/Driver下。你要新建一条测试道路，不需要从零开始写文件，直接找一个已有的道路文件另存为再改就行了。这个“改模板”的思路贯穿CarMaker使用的全过程，比从空白开始搭不知道高效多少倍。

3.1 被控对象模型（Plant Model）和应用模型（Application Model）别混淆

这是CarMaker学习里最容易被绕晕的一组概念，我当年也卡了不少时间。

• 被控对象模型（Plant）：是整车动力学部分，包括底盘、动力、制动、转向。它模拟的是物理世界本身，通常是CarMaker内置的，不需要你自己搭。
• 应用模型（Application）：是算法部分，比如你的AEB决策算法、ACC控制算法、ESP逻辑等。这一层通常是用户自己写的，通过Simulink、FMU或者其他接口挂到CarMaker上。

在项目里，你真正需要频繁改的是Application层，而Plant层一般用现成的车辆模型，除非你的工作是底盘调校，才需要深挖车辆动力学参数。这个区分直接决定了你的时间分配：做智能驾驶算法的，重点去啃Driver、Traffic、Sensor的配置；做底盘控制的，重点去研究悬架K&C参数和轮胎模型。

4. 图形界面里最常用的五个窗口，每个新用户都该先摸一遍

很多初学者下载完CarMaker，打开GUI后会觉得界面信息量很大，找不到入口。其实它的主界面布局相当固定，核心就五个窗口。我把它们的功能和使用逻辑整理在下面，都是实际项目里天天要用的：

新手最容易犯的错误是把所有时间耗在Parameter里改参数，却不看Movie验证效果。我的建议是：先跑通默认demo场景再看代码和参数，不要一开始就投入大量精力调车辆动力学参数。CarMaker内置了很完整的Demo Projects，路径通常在Demos/目录下。这些demo场景覆盖了高速公路巡航、城市拥堵跟车、紧急制动等多种典型工况，是最好的入门样本。

4.1 从打开一个demo工程开始，别从空白工程开始

我第一次用CarMaker时，想着赶紧建一个属于自己的工程，于是从File菜单新建了一个空工程，然后面对空荡荡的界面发呆了十分钟。后来老工程师告诉我，CarMaker的正确学习方式就是打开官方demo，一行一行看配置。

具体操作如下：启动CarMaker GUI后，在Test Run窗口里点击"Load"，浏览到Demos/目录下，随便选一个比如“Highway”相关的场景，加载后直接按Run。如果Movie窗口正常打开，你会看到一台车在虚拟道路上行驶。这时你按下暂停，到Parameter窗口里改一些参数，比如把驾驶员的目标车速从120改到80，再继续跑，观察车辆行为变化。

这种“改一个参数→跑一次看看→再改回来”的循环，是掌握CarMaker最快的方式。任何Paper、Course都不如这个循环理解深刻。

5. 手把手搭建第一个完整仿真：一条自定义路段 + 一台车 + 一个假想前车

现在进入正题：我们自己动手搭一个最简单的可跑场景。这个场景不需要复杂，但要把CarMaker里最核心的几个概念全部过一遍。比如：道路怎么建，车辆怎么选，驾驶员怎么设速度，前面的车怎么出现。

5.1 搭建道路：在Scenario Editor里画一条带有弯道的测试路

在Scenario Editor窗口里，你看到的是一片俯视视图。右键打开道路编辑面板，选择新建道路（New Road）。CarMaker支持从OpenDRIVE导入路网，也支持手动绘制道路中心线。我们这里直接用绘制模式，沿着X轴方向拖出一条约500米长的直线，然后在300米处加一个半径100米的弯道，再延续100米直线。

绘制完成后，重点来了——务必给道路指定铺装参数。很多新手跑着跑着发现车辆侧滑失控，大概率是因为路面的摩擦系数被设置成1.0的干燥沥青，但某一段被无意中设置成了0.3的冰雪路面。这个参数在道路属性面板里的Friction项，默认可能被人为改过，需要自己检查。初次实验建议全路段都设为1.0或0.9，尽量排除路面干扰。

5.2 选择车辆：在Parameter窗口换一辆真实验车

在Parameter窗口左侧找到Vehicle类目，点击下拉菜单可以看到CarMaker自带的车辆数据库，里面有轿车、SUV、面包车、甚至半挂车模型。选一辆标准轿车即可，比如内部编号为“Hatchback_Ref”的参考模型。

这里我要多说一句：CarMaker自带的车辆模型已经足够大多数智能驾驶算法测试使用，它的纵向动力学精度经过官方大量验证，除非你研究的是悬架KC特性对操稳性的影响，否则不推荐一开始就改车辆质量、重心、轮胎侧偏刚度这些参数。改坏了往往不如原厂参考模型可信。

5.3 配置驾驶员：设定目标车速和期望车道

在Parameter窗口的Driver类目下，可以设置驾驶员行为。CarMaker的驾驶员模型可以支持非常细腻的行为设定，比如目标车速、期望跟车距离、换道策略、加速踏板风格等。我们的第一个demo，只需要设置目标车速为80 km/h、保持在当前车道行驶，其他全部用默认值。

车辆会在仿真开始后自动加速到80 km/h并在当前车道行驶，方向盘、油门、刹车的控制信号全部由驾驶员模型自动生成。你可以把Driver想象成一个“标准司机模板”，所有“人在开车”的动作都由它代劳。

5.4 放置一辆前车：在Scenario Editor里创建交通目标

在Scenario Editor的左侧对象列表里，点击添加Traffic目标（Object），选一辆轿车，放置在道路起始位置前方大概80米处。默认情况下，前车是静止不动的，此时如果你直接跑仿真，会发生下面的情况：本车加速到80 km/h后，检测到前方有静置车辆，驾驶员模型会因为碰撞风险而触发制动。这就是一个最简单的AEB功能验证场景。

如果你想模拟更常见的城市跟车场景，可以把前车设置为动态目标（Maneuver），给它设定一个60 km/h的匀速行驶策略。这样本车会以80 km/h逼近前车，然后由于跟车距离过近，驾驶员模型会自动减速到60 km/h跟随前车。你看，不需要写任何算法，CarMaker自带的驾驶员模型就已经具备基础的ACC功能。这就是它能用来验证控制策略边界的原因——仿真环境中天然存在一个“虚拟驾驶员”在干活。

5.5 设置输出：规定要记录哪些数据

仿真跑完以后，光看动画是不够的，你需要在Data窗口里分析曲线。在Parameter窗口的Output类目下，勾选你要记录的信号，比如车速（v）、纵向加速度（ax）、转角（SteeringAngle）、与前车距离（RelativeDistance）等。这些信号会按设定的采样频率保存到输出文件里。输出频率默认一般是100 Hz或200 Hz，如果后面要做离线数据分析或用来回灌算法，建议直接设为1000 Hz，数据量不夸张，但后处理时方便很多。

5.6 运行仿真并分析结果

以上全部配置好后，回到Test Run窗口，点击Run。仿真会按实际物理时间推进，如果计算性能不够，可以切换为“快速模式（Fast Forward）”，让仿真跑得比实际时间快很多。跑完之后，打开Data窗口，你能看到一条完整的速度曲线：本车从0开始加速到80 km/h，逼近前车后减速到60 km/h，然后保持跟车。整个过程顺畅无异常，说明你的CarMaker环境、道路、车辆、驾驶员和交通目标配置全部正确。

6. 新手最常见的五个卡壳场景，我把排查路径直接给你列出来

6.1 GUI打开了但点击运行就报错：大概率是场景文件损坏或者路径含中文

CarMaker对路径里的中文字符支持不好。如果你把工程文件放在D:\我的项目\test下面，运行时很容易出现读取失败或写入异常。解决办法是：把整个工程目录移动到纯英文路径下，比如D:\CarMaker_Projects\test。这个问题在社区里被问过无数次，凡是用中文路径跑不起来的，基本都可以先怀疑这里。

6.2 仿真跑起来但车辆纹丝不动：检查手刹或者挡位

我第一次搭场景的时候也遇到过，车辆模型加载成功了，动画也在播放，但车就是停在原地。排查到最后发现是车辆的初始状态设置了手刹拉紧（ParkingBrake = On），或者挡位处于空挡（Neutral）。在Parameter窗口的Vehicle类目里，把初始状态改为Handbrake Off并且挂到D挡，问题就解决了。输出曲线里如果能看到发动机转速上升但车速恒为0，基本就是这个原因。

6.3 加载场景文件后报“Sensor not found”：批量测试前先检查传感器列表

做ADAS测试的同学很容易遇到这个问题。CarMaker的传感器（Sensor）配置是挂在TestRig或车辆系统下面的，如果你在场景里新增了目标物，但传感器列表里没有对应的检测目标类型，系统就会在运行时报错。解决路径是：打开Parameter窗口的Sensor列表，确认摄像头或毫米波雷达的探测类型是否覆盖了你新增的目标类别。

6.4 联合仿真时Simulink模型连接超时：检查MATLAB版本和接口设置

CarMaker与Simulink联合是目前最常见的应用方式。如果连接不上，通常的原因有三个：一是MATLAB版本与CarMaker版本不兼容，CarMaker每个版本都标注了官方支持的MATLAB版本号；二是模型编译未成功，需要在MATLAB中先跑一次模型编译，生成对应的MEX文件或DLL；三是端口冲突，58680等接口端口可能被占用，重启机器或更换端口能解决大部分问题。

6.5 数据记录不完整：检查输出文件的采样率和记录时长

很多人在Data窗口看到的曲线只覆盖了很短一段时间，或者某些信号完全没有。原因是Parameter窗口里Output条件没配置好，比如你设置了仅在特定事件触发时记录，但事件没被触发。初学阶段建议直接设置为“记录整个仿真过程”，事后再裁剪比漏记录要省事得多。

7. 从入门到进阶的路径建议，避免你多走半年弯路

当你完成了上面那个带前车的跟车场景之后，其实CarMaker的主要脉络你已经掌握了。下一步的进阶路径，我个人建议按这个顺序来走，效率是最高的：

1. 学会用IPGControl做自动化测试。IPGControl是CarMaker自带的自动化测试工具，你可以创建多个场景、批量修改参数、批量化运行，并把结果自动保存。这是做算法回归测试的必备技能。学会它之后，你手动跑一天的测试量，机器可能十几分钟就跑完了。

2. 搭一次基于Simulink的联合仿真。这是从“纯CarMaker用户”迈向“算法开发人员”的关键一步。你把一个简单的速度控制模型放到Simulink里，把CarMaker的车辆动力学作为被控对象，实现闭环控制，然后把控制效果在Movie里可视化出来。这一套通了，后面做AEB、ACC、LKA算法验证就比较熟练了。

3. 探索Python API接口。CarMaker支持通过Python脚本控制仿真流程，你可以写脚本批量跑场景、修改参数文件、解析输出结果，构建自己的自动化测试流水线。相比于GUI手动操作，脚本化是提升效率的终极手段。很多智能驾驶团队会把CarMaker的Python接口嵌入到持续集成（CI）流程里，每次代码更新后自动跑一遍场景集。

4. 再去碰车辆动力学深度参数。这里面涉及轮胎魔术公式、悬架运动学、转向系统刚度等内容，调试起来很耗时，但对底盘控制开发很重要。建议等前几步都熟练了再涉猎。

给新手的一个最核心的建议：先不要追求实现多么复杂的逻辑，而是先理解CarMaker里数据是怎么流的。Scenario Editor里定义的事件，Parameter里配置的参数，Sensor模型输出的信号，最终都要汇聚到主模型里参与车辆动力学解算，再把结果写入输出文件。这套数据流的理解一旦建立，你再去看任何复杂场景，都不会觉得无从下手。

CarMaker的学习曲线其实并不可怕，它只是一个封装度较高的专业工具，只要把道路、车辆、驾驶员、交通这几个概念吃透，再亲手跑通一个最简单的场景，剩下的内容都可以在项目实战中逐步积累。希望这篇文章能帮你把第一块台阶搭稳。