第三章 模型基础规范：Simulink建模命名规则、信号线命名规范、子系统封装规范

各位工程师朋友，大家好。欢迎来到《基于模型的MIL测试开发流程实战课程》的第三章。

这一章，咱们聊聊「规范」。嗯，我知道，一听到「规范」两个字，很多人就开始犯困了。觉得这东西虚头巴脑的，不如直接上手搭模型来得痛快。

但我得说句实在话：没有规范的模型，就是给自己挖坑。 我在项目里见过太多惨痛的教训了。一个模型，三个月后自己都看不懂，信号线满天飞，子系统封装得乱七八糟。最后出了问题，查错查到怀疑人生。

所以，这一章的内容，说白了就是教你如何「把模型写得像个人样」。咱们从三个维度来拆解：命名规则、信号线规范、子系统封装。

3.1 Simulink建模命名规则：别让你的模型变成「天书」

先说说命名。我个人习惯，给模块起名字，就像给孩子起名一样，要有点讲究。

3.1.1 模块命名规则

模块的名字，要能一眼看出它的功能。别用那些「Gain1」、「Sum2」、「Unit Delay3」之类的默认名字。默认名字是给机器看的，不是给人看的。

我建议的命名格式：[功能描述]_[数据类型]_[序号]

举个例子：

• Speed_Calc_F32 —— 计算速度的模块，数据类型是float32
• Brake_Cmd_Bool —— 制动指令，布尔类型
• Filter_Coef_U16 —— 滤波器系数，uint16

为什么要加数据类型？因为我在项目中遇到过，一个信号从float32变成了uint16，结果精度丢失，导致控制逻辑跑偏。查了两天才发现是数据类型不匹配。从那以后，我强制团队在命名里标注数据类型。

3.1.2 信号与参数命名规则

信号线的命名，我习惯用「匈牙利命名法」的变体。说白了，就是前缀表示信号来源或用途，后缀表示单位或数据类型。

格式：[前缀]_[信号名]_[单位/类型]

比如：

• Eng_Speed_rpm —— 发动机转速，单位rpm
• Veh_Vel_kmh —— 车速，单位km/h
• Brk_Press_bar —— 制动压力，单位bar

你想想看，如果信号线叫「Signal1」，你调试的时候是不是得一个个去查？但如果叫「Eng_Speed_rpm」，一眼就知道是发动机转速，单位是rpm。这就是规范的价值。

3.2 信号线命名规范：别让线乱飞

信号线，是模型的「血管」。血管乱了，整个系统就瘫痪了。

3.2.1 信号线的基本规范

我总结了三条「铁律」：

1. 每条信号线都必须有名字。 别偷懒。Simulink允许信号线无名，但那是灾难的开始。
2. 名字要唯一。 同一个模型里，不要出现两个同名的信号线。否则查错时你会疯掉。
3. 名字要反映物理意义。 别用「tmp1」、「tmp2」这种临时名字。临时名字最终会变成永久名字，相信我。

3.2.2 信号线分组与总线

当信号线多起来之后，你会发现模型变得像蜘蛛网。这时候，就需要用「总线」来管理了。

我建议的做法：

• 把相关的信号打包成总线。比如，把所有「发动机相关信号」打包成 Engine_Bus。
• 总线里的每个信号，也要遵循命名规范。
• 使用「Bus Creator」和「Bus Selector」来创建和提取总线信号。

3.2.3 信号线颜色与样式

Simulink支持给信号线设置颜色和线型。我个人习惯：

• 控制信号用蓝色实线
• 反馈信号用绿色实线
• 故障信号用红色虚线
• 标定参数用橙色点划线

这样，一眼就能看出信号的性质。调试的时候，红色虚线一出现，就知道是故障信号，直接定位问题。

3.3 子系统封装规范：把模型做成「黑盒子」

子系统封装，是Simulink建模的高级技巧。说白了，就是把一堆模块打包成一个「黑盒子」，只暴露必要的接口。

3.3.1 为什么要封装？

我刚开始做模型的时候，喜欢把所有逻辑都摊在顶层。结果模型越来越大，最后一张图都装不下。后来我学乖了，开始用子系统封装。

封装的好处：

• 模块化： 每个子系统负责一个独立的功能，便于复用。
• 可读性： 顶层模型变得简洁，只看到功能模块，看不到内部实现。
• 可维护性： 修改内部逻辑，不影响外部接口。

3.3.2 封装规范

我建议的封装规范：

1. 子系统命名： 用功能命名，比如 Brake_Control、Engine_Management。
2. 接口定义： 所有输入输出端口，都要有明确的命名和数据类型。别用默认的「In1」、「Out1」。
3. 参数化： 把可调参数暴露出来，用「Mask Editor」创建参数对话框。这样，使用者不需要打开子系统，就能修改参数。
4. 文档化： 在子系统的「Description」里，写清楚功能描述、输入输出说明、版本号、作者信息。

3.3.3 封装示例

咱们来看一个简单的封装示例。假设我们要封装一个「低通滤波器」子系统。

子系统名称：LowPass_Filter
输入端口：
    - Signal_In_F32 (输入信号，float32)
    - Enable_Bool (使能信号，boolean)
输出端口：
    - Signal_Out_F32 (滤波后信号，float32)
参数：
    - Cutoff_Freq_Hz (截止频率，单位Hz，默认值100)
    - Filter_Order (滤波器阶数，默认值2)
描述：
    "一阶/二阶低通滤波器，支持使能控制。截止频率可调。"

这样封装之后，别人用这个滤波器，只需要拖拽到模型里，设置截止频率和阶数，接上输入信号和使能信号，就能用了。内部怎么实现的？不用管。

3.4 避坑指南：我踩过的那些坑

最后，分享几个我亲身踩过的坑，希望能帮大家少走弯路。

• 坑一：信号线没命名。 有一次，我调试一个模型，发现某个信号值不对。但信号线没名字，我花了两个小时才找到是哪根线。从那以后，我强制团队所有信号线必须命名。
• 坑二：子系统封装太深。 我曾经见过一个模型，子系统套子系统，套了五层。最后想改一个参数，得一层层点进去。我建议，子系统嵌套不要超过三层。
• 坑三：命名不规范导致误解。 有个同事把「车速」信号命名为「Speed」，结果另一个同事以为是「发动机转速」。两个人吵了半天，最后发现是命名惹的祸。从那以后，我们统一了命名规范，前缀必须标明是「Veh」还是「Eng」。

好了，这一章的内容就到这里。总结一下：命名要规范、信号线要有名、子系统要封装好。这些看似琐碎的规范，其实是保证模型质量的基础。

下一章，咱们聊聊MIL测试环境的搭建。到时候见。