2. Simulink环境搭建：从安装到规范，一个都不能少
好，咱们正式开始动手了。这一章我带你搞定Simulink的环境搭建。说实话，很多新手工程师上来就急着写模型，结果后面编译报错、代码生成失败，回头一看——工具箱没装全，路径乱成一锅粥。嗯，这些坑我都踩过。
所以这一章，咱们把地基打牢。从安装配置、工具箱选择，到项目文件结构、建模规范，一条龙讲清楚。
2.1 Simulink安装与配置
安装这事，看着简单，其实门道不少。我个人的习惯是：不要装最新版。为什么？因为ADAS开发中很多第三方工具（比如dSPACE、ETAS）对新版本的适配往往滞后半年到一年。你装个2024b，结果发现某个关键的Vehicle Dynamics Blockset不兼容，那就尴尬了。
我建议用R2022b或R2023a，这两个版本在ADAS领域非常成熟。安装时注意以下几点：
- 安装路径不要有中文——这是老生常谈了，但每次都有同事中招。Simulink对中文路径的支持一直不太好，编译报错时你根本想不到是路径问题。
- 选择“自定义安装”——别偷懒点“典型安装”。ADAS开发需要的工具箱很多，默认安装会漏掉不少。
- 许可证配置——如果你用的是网络许可证，记得把
LM_LICENSE_FILE环境变量配好。我曾经因为环境变量没配，折腾了一整天，最后发现是IT同事少写了一个冒号。
ver，可以查看已安装的工具箱列表。我每次装完新环境，第一件事就是跑这个命令，确认所有需要的工具箱都在。
2.2 工具箱选择：ADAS开发必备清单
工具箱选不对，后面全是坑。我整理了一份ADAS开发必备的工具箱清单，你照着装就行：
| 工具箱名称 | 用途 | 推荐等级 |
|---|---|---|
| Simulink | 基础建模环境 | ★★★★★ |
| Stateflow | 状态机建模（ACC、LKA等模式切换） | ★★★★★ |
| Vehicle Dynamics Blockset | 车辆动力学模型（纵向/横向控制） | ★★★★★ |
| Sensor Fusion and Tracking Toolbox | 传感器融合（雷达、摄像头、激光雷达） | ★★★★☆ |
| Automated Driving Toolbox | ADAS场景仿真、道路建模 | ★★★★★ |
| Embedded Coder | 嵌入式代码生成（生成C代码） | ★★★★★ |
| Simulink Test | 测试用例管理、覆盖率分析 | ★★★★☆ |
你想想看，如果只装了个Simulink基础版，连Vehicle Dynamics Blockset都没有，那你怎么建车辆模型？用手画吗？
2.3 项目文件结构：别让你的模型变成一锅粥
项目文件结构这事，我刚开始做ADAS时也没太在意。结果项目做到一半，模型文件散落在各个文件夹里，同事之间互相拷来拷去，版本混乱得一塌糊涂。后来我痛定思痛，总结了一套结构：
Project_Root/
├── 00_Documentation/ # 需求文档、设计文档
├── 01_Requirements/ # 需求模型（Simulink Requirements）
├── 02_Architecture/ # 架构模型（顶层模型）
├── 03_Detailed_Design/ # 详细设计（子系统模型）
│ ├── SensorFusion/
│ ├── DecisionLogic/
│ └── VehicleControl/
├── 04_Test/ # 测试模型和测试用例
│ ├── MIL/ # 模型在环测试
│ ├── SIL/ # 软件在环测试
│ └── HIL/ # 硬件在环测试
├── 05_Code/ # 生成的代码
├── 06_Tools/ # 自定义脚本、工具
├── 07_Data/ # 参数文件、标定数据
└── 08_Results/ # 仿真结果、报告
这个结构的好处是：每个阶段的东西都有自己该待的地方。你找模型不会翻半天，别人接手你的项目也不会骂娘。
我个人习惯在07_Data/下面放一个initParams.m脚本，里面定义所有模型参数。这样模型里就不用写死数值了，改参数直接改脚本就行。嗯，这个习惯帮我省了不少事——有一次客户要求把ACC的跟车时距从1.5秒改成2.0秒，我改了一个数字，重新跑一遍仿真，搞定。
2.4 建模规范：让模型像代码一样可读
建模规范这事，很多人觉得无所谓。但你想过没有，一个ADAS项目动辄几十个工程师同时开发，模型几百个模块。如果没有规范，那画面太美我不敢看。
我参与过一个项目，有个同事把所有的逻辑都写在一个Subsystem里，里面密密麻麻全是Goto/From标签。我花了三天才看懂他那个模块是干嘛的——说白了就是ACC的跟车逻辑。从那以后，我对建模规范特别较真。
这里我列几条核心规范，你照着做就行：
- 命名规范：信号线用驼峰命名，比如
targetSpeed_kph。模块名用下划线分隔，比如ACC_Controller。别用拼音，别用中文，别用a1、b2这种鬼名字。 - 分层原则：每个Subsystem的功能要单一，一个Subsystem不要超过20个模块。如果超过了，说明你需要再拆一层。
- 信号流方向：从左到右，从上到下。别搞成从右往左流，别人看不懂，代码生成器也容易出问题。
- Goto/From的使用：能不用就不用。实在要用，只在同一层内使用，别跨层。跨层的Goto/From是代码生成的大敌——我曾经因为一个跨层Goto，生成的代码里多了一个全局变量，导致RAM溢出。
- 注释：每个Subsystem都要有Description，说明这个模块是干嘛的。关键信号线也要加注释。别觉得麻烦，三个月后你自己回头看，都会感谢当初写了注释的自己。
2.5 避坑指南：我踩过的那些坑
最后，分享几个我亲身踩过的坑，你遇到了直接绕开：
- 坑一：我曾经在模型里用了MATLAB Function模块，里面写了一大堆
eval语句。结果代码生成时，Embedded Coder直接报错——eval不支持代码生成。后来我花了两天把所有eval改成了switch-case。所以记住：代码生成环境下，别用动态执行的函数。 - 坑二：有一次我忘了设置
Model Configuration Parameters里的Hardware Implementation，默认是MATLAB Host Computer。生成的代码里全是double类型，烧到MCU上直接跑飞。后来改成NXP S32K144，数据类型自动优化成single和uint16，问题解决。 - 坑三：模型里用了
Variable Size Signal，结果代码生成时RAM占用暴涨。ADAS算法里，能不用的变长信号就别用。实在要用，记得在Signal Attributes里设置最大长度。
好了，环境搭建这部分就讲到这里。下一章咱们开始真正建模——从最简单的ACC跟车模型入手。你先把环境搭好，工具箱装全，项目结构建好，规范记牢。后面的事，咱们一步步来。