2. Simulink建模基础
在汽车控制算法开发中，Simulink 模型既是控制策略的“可执行规格说明”，也是后续自动代码生成、HIL 测试与标定的输入。因此，建模基础不只是“会拖模块、会连线”，而是要让模型在结构、信号语义、参数管理和复用方式上都具备工程可维护性。本节围绕五个相互关联的要素展开：常用模块库、信号与参数、子系统、模型引用、总线与信号线管理。
一、常用模块库：按“信号处理角色”选模块
Simulink 的库浏览器中模块很多，但汽车控制算法常用的可以按角色归为几类。第一类是源与汇：Inport/Outport 用于定义子系统或模型边界，Constant 提供标定量，From Workspace 或 Signal Builder 用于注入测试激励，Scope、To Workspace、Display 用于观测。第二类是数学与逻辑：Gain、Sum、Product、Relational Operator、Logical Operator、Switch。第三类是连续与离散动态：Integrator、Transfer Fcn、State-Space、Unit Delay、Discrete Transfer Fcn。第四类是查表与非线性：1-D Lookup Table、2-D Lookup Table、Saturation、Rate Limiter。第五类是信号路由与结构：Mux/Demux、Bus Creator/Bus Selector、Subsystem、Model 引用块。
选择模块时，先问“这个信号在算法中承担什么角色”，而不是先看模块名字。例如发动机扭矩控制中，驾驶员需求扭矩经过1-D Lookup Table（踏板—需求扭矩）后，与怠速扭矩通过Sum 相加，再经Rate Limiter 限制变化率，最后经Saturation 限幅输出。这条链路里每个模块都对应一个明确的物理或控制含义，而不是随意堆叠。
二、信号与参数：区分“会变的”和“不变的”
Simulink 中必须严格区分信号（Signal）与参数（Parameter）。信号是仿真过程中随时间变化的量，例如车速、电机转速、扭矩指令；参数是仿真过程中保持不变的量，例如 PID 的 Kp、Ki、查表数据、采样周期 Ts。参数应通过Simulink.Parameter 对象或数据字典管理，而不是直接写死在模块对话框中，否则后续标定和代码生成会非常困难。
信号线本身也可以携带元数据。右键信号线选择 Properties，可以设置信号名称、数据类型、单位、最小/最大值、初始值等。对于汽车控制模型，建议至少设置名称、数据类型、单位三项。例如一条名为 VehSpd_kph 的信号，数据类型为 single，单位为 kph，这样在模型评审和代码生成时都能自动检查一致性。
Sample time 应设为 0.01；若模型是多速率系统，需明确每个速率域，避免代数环和意外的速率转换。三、子系统：把“功能内聚”的部分封装起来
子系统（Subsystem）的作用不是“把图变小”，而是建立清晰的层次边界。常用形式有三种：普通子系统、使能子系统（Enabled Subsystem）、触发子系统（Triggered Subsystem）。在汽车控制中，普通子系统适合封装一个完整功能，例如“扭矩仲裁”“档位决策”“热管理请求”；使能子系统适合“条件执行”的逻辑，例如仅在 IgnitionOn == 1 时执行某段计算。
创建子系统时，应遵循“输入输出明确、内部不依赖外部隐藏变量”的原则。一个可维护的子系统，其 Inport 和 Outport 应能完整表达该功能的接口。例如“扭矩仲裁”子系统输入为驾驶员需求扭矩、怠速扭矩、限扭请求、档位，输出为最终扭矩请求和仲裁状态字。这样在模型评审时，评审者只看接口就能理解功能边界。
四、模型引用：从“复制粘贴”走向“组件复用”
当同一功能需要在多个车型或多个项目中复用时，应使用模型引用（Model Reference），而不是复制子系统。模型引用把被引用模型作为独立单元编译和仿真，支持增量编译、独立测试和版本管理。典型场景是：底层执行器控制模型（如电机控制、变速箱控制）由不同团队维护，上层整车控制器通过 Model 块引用它们。
使用模型引用时要注意：被引用模型必须有明确的输入输出接口；引用方与被引用方的采样周期要匹配或显式声明；被引用模型的配置参数（如求解器、代码生成设置）应独立管理。与子系统相比，模型引用更适合“跨项目、跨团队、跨版本”的复用，而子系统更适合“同一模型内部的功能划分”。
五、总线与信号线管理：让接口“可读、可查、可校验”
当信号数量增多时，逐根连线会导致模型难以阅读。总线（Bus）把一组相关信号打包成一个结构体，例如 Bus_VehicleState 可以包含 VehSpd、AccelPedal、BrakePedal、Gear、EngSpd。总线通过 Bus Creator 打包、Bus Selector 解包，配合 Simulink.Bus 对象定义，可以实现接口的集中管理和自动校验。
信号线管理还包括：为关键信号添加标签和注释；使用Signal Conversion 或 Bus Assignment 修改总线中的个别元素；避免使用 Mux 代替总线（Mux 只是虚拟向量，不携带信号名和单位）。在汽车控制模型中，推荐用总线表达“接口”，用 Mux 仅表达“同类型信号的向量化”，两者不要混用。
六、把五件事串起来：一个可维护的建模习惯
在实际项目中，这五个要素不是孤立的。一个推荐的做法是：先用总线定义模块之间的接口，再用子系统封装功能，把需要跨项目复用的部分做成模型引用，所有参数放入数据字典，所有信号设置名称、类型和单位。这样，模型在评审时能快速定位问题，在代码生成时能自动检查接口一致性，在标定时能通过参数对象直接调整。
例如，在整车控制器模型中，可以建立 Bus_VehicleState、Bus_DriverRequest、Bus_PowertrainStatus 三条总线，分别对应车辆状态、驾驶员请求、动力系统状态。扭矩仲裁子系统从 Bus_DriverRequest 和 Bus_PowertrainStatus 读取信号，输出 Bus_TorqueCommand。底层电机控制模型通过模型引用接入，其输入输出也使用总线。这样，接口变化时只需修改总线定义，所有引用点自动更新，避免“改一处、漏十处”。
Mux 把不同物理含义的信号打包成一根线，导致信号名和单位丢失；把标定参数直接写在 Gain 模块的 Gain 框中，导致无法批量标定；复制子系统代替模型引用，导致同一功能出现多个版本。这些都会在后续代码生成和 HIL 测试中放大为严重问题。总结来说，Simulink 建模基础的核心不是记住模块位置，而是建立“接口清晰、参数集中、功能内聚、复用可控”的工程习惯。常用模块库提供表达手段，信号与参数定义语义，子系统划分功能边界，模型引用实现组件复用，总线与信号线管理保证接口可读可查。把这五件事做好，后续的代码生成、模型验证和标定才有稳定的基础。