3. 面向代码生成的Simulink建模规范
在Embedded Coder的代码生成链路中，Simulink模型不只是仿真验证的工具，它同时是生成C代码的“源程序”。模型里每一个模块、每一条信号线、每一个数据类型，最终都会映射为嵌入式工程中的变量、函数、结构体或内存布局。因此，面向代码生成的建模规范，本质上是一套“让模型可被确定性地翻译成高质量C代码”的约束体系。它关注的不是模型能不能跑出正确波形，而是模型能不能生成可读、可维护、可移植、可追溯的嵌入式代码。
本节围绕五个关键维度展开：适合代码生成的建模风格、数据类型显式化、信号命名与总线对象、避免不可生成代码的建模模式、模型架构分层原则。这五点并非彼此独立，而是共同构成一条从“模型结构”到“代码结构”的映射链。
一、适合代码生成的建模风格
适合代码生成的模型，首要特征是“确定性”。同一个模型，在相同输入下，生成的代码结构、变量名、执行顺序应当稳定可复现。为此，建模时应遵循以下风格：
- 避免使用仿真专用模块：如Scope、Display、To Workspace等只用于观测的模块，它们不参与代码生成，却会污染模型结构。观测应通过信号记录或测试 harness 完成。
- 避免代数环：代数环会导致生成的代码出现直接反馈，编译器可能报错或产生不可预期的执行顺序。若必须存在反馈，应显式插入Unit Delay或Memory模块，明确状态。
- 避免连续状态与变步长求解器：嵌入式目标通常使用定步长离散求解器。模型应尽量使用离散模块，如Discrete Filter、Unit Delay、Discrete Integrator，避免连续积分器带来的求解器依赖。
- 避免动态类型与隐式类型转换：Simulink允许信号类型在仿真中自动推导，但代码生成要求类型在编译期确定。所有信号应显式指定数据类型。
- 避免使用可变大小信号：嵌入式C代码通常使用静态内存分配，可变大小数组会引入动态内存管理，增加不确定性和安全风险。
一个典型的反例是：在控制器模型中直接使用“Gain”模块而不指定输出类型，Simulink会继承输入类型。若输入为double，则生成double运算；若目标MCU为定点DSP，则会产生大量浮点库调用，严重影响实时性。正确做法是显式设置Gain的输出数据类型为int16或fixdt(1,16,12)，并配置舍入与溢出模式。
二、数据类型显式化
数据类型显式化是代码生成规范中最核心的一条。Embedded Coder通过“端口数据类型”和“参数数据类型”来决定生成变量的C类型。若模型中使用继承类型（Inherit: auto），代码生成器会尝试推导，但推导结果可能因模型版本、配置参数或信号传播路径而变化，导致代码不可复现。
显式化的具体做法包括：
- 在Inport、Outport、Signal、Parameter上直接指定数据类型，如uint8、int16、single、boolean，或使用fixdt构造定点类型。
- 为每个数据类型设置合理的舍入模式（Round: Floor/Ceiling/Convergent）和溢出模式（Saturate/Wrap）。例如，控制量输出建议使用Saturate，避免溢出后符号翻转导致执行器误动作。
- 使用Simulink.NumericType或Simulink.AliasType定义项目级类型别名，如
typedef int16_T MotorSpeed_T;，使生成代码中的类型名具有业务含义。 - 对定点运算，明确标定（Scaling），包括斜率与偏置，确保生成的C代码中定点运算的移位与饱和逻辑正确。
例如，一个温度采集通道，ADC为12位，参考电压3.3V，温度范围-40~125℃。若直接使用double，则生成浮点代码；若显式定义为fixdt(1,16,8)，则生成整数移位与饱和运算，既节省MCU周期，又便于与底层驱动对接。
三、信号命名与总线对象
信号命名直接影响生成代码的可读性。Simulink默认使用信号线名称作为变量名，若信号未命名，代码生成器会生成rtB.signal1之类的临时名。规范要求：
- 所有跨模块信号必须命名，命名采用驼峰或下划线风格，如
vehicleSpeed、motor_current，并保持全模型一致。 - 信号名应具有业务含义，避免
sig1、tmp等无意义名称。 - 对总线信号，使用Simulink.Bus对象定义总线结构，明确每个元素的名称、数据类型、维度、采样时间。总线对象应保存在数据字典或基础工作区中，随模型版本管理。
- 总线元素命名应与生成代码中的结构体成员一致，便于代码审查与调试。
例如，定义一个MotorCmd_Bus，包含enable（boolean）、targetSpeed（int16）、direction（uint8）、torqueLimit（int16）。生成代码中会出现MotorCmd_Bus motorCmd;，成员访问为motorCmd.targetSpeed，清晰且可追溯。
四、避免不可生成代码的建模模式
有些建模方式在仿真中完全正常，但无法生成嵌入式C代码，或生成的代码质量极差。常见模式包括：
- 使用MATLAB Function模块中的动态内存分配：如
zeros(n)且n为运行时变量，会生成malloc/free，嵌入式环境通常禁止。 - 使用Interpreted MATLAB Function：该模块依赖MATLAB引擎，无法生成独立C代码。
- 使用可变子系统或可变端口：代码生成器无法在编译期确定端口数量，导致生成失败。
- 使用未指定采样时间的模块：混合采样时间会导致代码生成器插入不必要的速率转换，增加开销。
- 使用递归函数或函数指针：在MATLAB Function中定义递归调用，生成的C代码可能栈溢出。
规避方法：在建模阶段就使用“Code Generation”检查，通过Simulink的“Model Advisor”运行“Check for code generation”检查项，提前发现不可生成模块。对于必须使用的MATLAB算法，应改写为Stateflow或MATLAB Function，并限制为静态内存、固定循环边界。
五、模型架构分层原则
面向代码生成的模型架构，应遵循“分层、分区、可复用”的原则。典型分层如下：
- 顶层：负责调度与接口，包含Inport/Outport、总线、采样时间定义，不包含具体算法。
- 功能层：按功能划分子系统，如信号采集、控制算法、执行输出。每个子系统应封装为原子子系统（Atomic Subsystem），以便生成独立函数。
- 基础层：可复用的工具函数、查表、滤波、限幅等，封装为库模块或引用模型。
分层带来的好处是：生成的代码具有清晰的函数边界，便于单元测试与集成。例如，将PID控制器封装为原子子系统，生成PID_Step()函数，输入输出通过结构体传递，既减少全局变量，又便于在C环境中单独调用。
上图展示了模型层与代码层之间的映射关系。左侧的模型分层结构，在右侧对应为类型定义、函数边界、定点运算和调度接口。可以看到，模型中的每一个规范约束，最终都会在代码中留下痕迹：显式类型对应typedef，原子子系统对应独立函数，总线对象对应结构体，饱和模式对应SATURATE宏。
总结来说，面向代码生成的Simulink建模规范，核心是“让模型在编译期就确定一切”。类型确定、命名确定、结构确定、内存确定，代码生成器才能稳定地输出高质量的嵌入式C代码。这五个维度——建模风格、类型显式化、命名与总线、规避不可生成模式、架构分层——共同构成了从模型到代码的可靠桥梁。