为什么自动代码生成比手动编写的转换器固件更胜一筹

核心要点

• 自动代码生成消除了控制设计与固件之间反复的转换，从而减少了审查债务，并确保实现与模型保持一致。
• 当模型已经反映了固定的时序、数值限制、保护顺序和处理器约束时，生成的控制器代码才能发挥最佳效果。
• 在外设配置和系统服务方面，手动固件仍然很重要，而控制回路本身则最能从基于模型的生成和原型设计中获益。

当控制律不断变化而时序仍需保持精确时，自动代码生成比手动编写的转换器固件更胜一筹。

电源转换器团队很少在编写C语言代码时遇到困难。他们面临的挑战在于重新调整电流环路、更新保护逻辑，以及在每次设计变更后保持采样时间的一致性。2023年，电动汽车销量接近1400万辆，约占汽车总销量的18%。如此庞大的规模给转换器和电机控制代码带来了更大压力，而手动固件开发工作则成为整个流程中最耗时的环节。 当控制模型成为“权威来源”，而控制器代码由此模型生成时，您将获得更好的体验。这种方法特别适合变流器实验室和教学实验室——在这些场景中，算法不断迭代，而低级固件工作往往会成为阻碍。

自动代码生成将控制模型转换为嵌入式软件

自动代码生成可将控制模型转换为C代码，同时保留模型的结构、时序和数据流。您只需使用模块或方程构建控制律，指定采样时间，即可为目标平台生成源文件。这确保了实现与经过验证的设计保持一致，同时也缩短了从仿真 执行的过渡时间。

三相逆变器的电流控制器就是一个典型的例子。你可以对克拉克坐标与帕克坐标之间的转换、比例积分控制环路、饱和现象以及脉宽调制占空比计算进行建模，然后为中断处理步骤生成代码。在部署之前，每条信号路径都清晰可见。而手动编写的固件往往会将相同的逻辑分散在多个文件、宏和中断分支中。

这种提升并非只需按一下按钮就能神奇地提升代码质量。

“这一优势源于消除了控制设计与固件实现之间的转换工作。”

每当您重新调整增益、添加前馈或插入防饱和路径时，模型与代码始终保持一致。这种一致性比单纯的编码速度更为重要，因为转换器项目的绝大多数时间都花在修订上，而非首次实现。

固件开发的工作重心正从编写代码转向塑造行为

主要工作重点从手动编写函数转向在模型中定义精确的控制行为。您仍然需要选择速率、数值类型、缩放因子和接口。您无需再花费数小时编写千篇一律的调度器代码和重复的信号连接工作。您的精力将转向控制意图的定义——而在这一环节，错误的代价更高。

一个相位偏移的全桥控制器很好地展示了这种偏移。手动编写代码时，需要连接模数转换器的读取信号、对测量值进行归一化处理、安排补偿模块的执行、对输出进行钳位，并在每次中断编辑后保持相位逻辑的一致性。生成的代码虽然仍需配置，但补偿律始终保持在一个模型中。这使得您在设计评审期间只需在一个地方即可审查系统行为。

控制团队往往低估了固件手动工作中的文书性质。复制增益值、重命名变量以及将方程转换为整数运算，这些操作并不会带来任何控制方面的洞见。这些步骤还会仿真 嵌入式执行之间产生隐性不一致。自动代码生成可以消除大部分此类文书工作，从而避免因抄写错误而浪费验证时间。

Embedded Coder 适用于 C2000 等电机控制目标平台

C2000 等小型电机控制处理器适合代码生成，因为它们需要处理固定步长的任务、可预测的中断以及明确的输入/输出时序。合适的代码生成器会将模型时序映射到该执行模式上。您仍需审查内存使用情况和外设时序。控制器逻辑以联系表 可运行联系表 传递给处理器。

场定向电机控制器就是一个很好的例子。该模型可以包含电流重建、速度估计、比例积分控制器、解耦项和空间矢量调制，而外围设置则保留在控制律之外。生成的代码涵盖了重复的控制任务。随后，手动编写的代码可以围绕它封装模拟采样、脉宽调制同步、故障跳闸和通信接口等功能。

正是这种分工，使得基于模型的控制在这些设备上运行良好。处理器在确定性循环执行方面表现出色，但在算法仍在运行时，频繁重写代码会对其造成负担。生成的控制器代码提供了与模型模块相关联且易于阅读的函数，这在代码审查、标定和实验室调试过程中非常有帮助。这比每次重新调优后都对固件进行全面重写，更贴近Simulink代码生成的初衷。

当控制环路持续变化时，手动转换器固件运行会变慢

手动编写的转换器固件会拖慢开发进度，因为每次控制逻辑的变更都会迫使开发人员进行从方程到代码的二次转换。这一额外步骤会产生代码审查债务、重复测试工作以及时间风险。2022年，软件质量问题在美国造成的损失至少达2.41万亿美元。转换器开发团队每周都会感受到这种浪费的缩小版。

双有源桥式方案通常从一种调制方法开始，待台架测试结果出来后，再依次添加软启动逻辑、死区时间补偿和限流功能。每次固件修改都会涉及比例系数调整、中断定时以及故障交互机制。控制工程师和固件工程师虽然在数学原理上达成一致，但在具体实现细节上仍可能存在分歧。每当控制回路结构发生变化时，这种分歧就会进一步扩大。

当算法稳定且团队对设备了如指掌时，手动编写代码仍然可行。问题往往比大多数团队预期的出现得更早，因为转换器项目在第一个测试周期中很少能保持稳定。下表总结了在开始修订后，工作重点通常会转向哪些方面。这说明了为什么瓶颈在于转换和重新测试，而不是计算本身。

生成的控制器代码取决于简洁且确定性的模型设计

代码生成的质量取决于其背后的模型结构、时间精度要求以及数值选择。一个结构清晰的固定步长模型将生成易于阅读的控制软件；而一个粗糙的模型则会更快地生成令人困惑的软件。在开始代码生成之前，模型必须准确反映实际嵌入式系统的情况。

一个已准备好进行代码生成的转换器模型具有以下几个明显特征：速率明确；状态以受控方式重置；信号限值设定在硬件饱和发生的位置；数值选择与目标平台相匹配。

• 每个控制任务都使用与实际中断相匹配的固定采样时间。
• 每次状态重置都是可见的，并且与一个已定义的运行状态相关联。
• 传感器量程和执行器限制不仅出现在封装代码中，也出现在模型中。
• 在开始计时工作之前，数据类型就反映了处理器的限制。
• 保护路径按照与控制循环相匹配的已知顺序执行。

这些规则听起来很普通，却能避免最糟糕的意外。如果模型中存在隐含的速率转换或浮点假设，虽然它能编译通过，但在小型处理器上遇到中断压力时就会出错。结构清晰还能让生成的文件更容易与固件领域的同行进行审查。你并没有要求生成器去解决那些本应由工程师负责的建模问题。

在进行低级固件开发之前，先通过控制原型验证进行时序检查

通过控制原型设计，您可以在确定低级固件细节之前，测试执行时序、输入/输出行为以及闭环响应。这一步骤能在算法仍易于修改时，揭示未达成的时限、扩展性差以及保护逻辑薄弱等问题。它将时序转化为设计变量，而非后期才出现的意外。

将基于模型的控制器与 C2000 控制原型相结合的实验室配置，能迅速展现其价值。OPAL-RT 采用了这种模式，使工程师和学生能够针对正在运行的被控对象模型对变流器和电机算法进行迭代，而无需将每次修订手动编码到固件中。在故障和阶跃变化条件下，可以验证电流限制、观测器增益以及脉宽调制（PWM）的更新情况。相关工作始终聚焦于控制质量和执行时序。

这一阶段至关重要，因为仿真 无法发现所有问题。在中端机型上，中断抖动、量化误差、模拟采样对齐以及饱和顺序等问题往往看似无害。

“原型设计能在团队将这些细节埋入外围代码之前，将其暴露出来。”

您进入固件开发的最后阶段时，未知因素已减少，且控制律已经证明能够按时执行。

当模型忽略硬件约束时，代码生成会失败

在实际应用中，当模型假设数学条件理想且硬件资源无限时，代码生成就会失败。小型控制处理器具有严格的时序限制、有限的分辨率以及外设规则，模型必须遵守这些限制。对于超出中断时槽的控制设计，生成的代码无法挽救，它只会让这种不匹配更早地显现出来。

一个数字功率因数校正控制环路，在双精度计算且传感器无延迟的情况下可能表现稳定，但一旦使用量化后的模拟值和存在延迟的电流采样数据运行，就会出现异常。这并非生成的代码有问题，而是模型忽略了被控对象的接口特性以及处理器的限制。当模型使用可变步长逻辑，而该逻辑无法适应固定的中断调度时，也会出现类似的问题。

通过严格遵守规范，可以避免这种陷阱。在模型中体现传感器滤波、转换延迟和执行器饱和等特性。尽早选择适合处理器的数据类型，然后在每次功能变更后观察执行时间。能够做到这一点的团队会将代码生成视为一种实现方法，而非替代嵌入式设计判断的手段。

手动代码仍适用于控制回路中的外设处理

在转换器控制器中，手动编写的代码在某些边缘领域仍然有其用武之地，特别是在电路板调试、通信协议栈、自定义保护功能以及特定设备的周边设备配置方面。而控制环路本身则最能从代码生成中获益。这种分工使您能够清晰区分行为变化频繁的区域，并在硬件细节已确定的情况下进行手动调优。

一个实用的固件堆栈通常是这样的。生成的代码负责运行电流或电压闭环，而手动编写的代码则负责管理启动序列、故障日志记录、总线消息以及非易失性参数存储。这种分工符合变流器项目在实验室中的实际推进过程。在调试期间，控制方程每周都会发生变化，而外围服务则会更早地稳定下来，因此值得投入细致的手动工作。

这就是为什么在大多数控制任务中，自动代码生成比手动编写的转换器固件更具优势。其优势并不在于源文件更短，而在于您所信赖的模型、您所验证的时序以及您最终发布的代码之间能够实现更紧密的对齐。OPAL-RT非常符合这一标准，因为它支持控制团队在低级固件开发锁定设计之前，先在硬件上验证执行过程这一关键步骤。