
核心要点
- 转换器电路中最快的事件决定了时间步长,而时间步长则决定了你实际上可以使用哪种求解器。
- 离线工具用于解决设计问题,而实时硬件在环测试则用于解决集成问题,因此应将两者之间的转换作为一项独立任务进行规划,并制定相应的验收标准。
- 边缘定位精度比原始步长更为重要,因此在比较不同平台时,插值切换是首要检查的特性。
在电力电子领域,仿真 能在首块原型板组装之前就发现转换器故障,从而收回成本,而决定性因素在于您的模型实际需要的时间步长。
每款逆变器程序都会遇到同样的瓶颈。离线求解器提供无限的分辨率且不受时间限制,而实时平台则设有硬性时间限制,且每步的计算预算固定。若在这条界线上选错了边,将导致工期延误数周。过去三年间,美国公用事业级电池储能以年均70%的速度增长,而每一套安装系统背后,都有一台逆变器,这台逆变器必须经过建模、调试和验收。
实际的问题并不是哪款仿真器最好,而是哪款求解器能与您的开关频率、控制环路速率以及计划连接的硬件相匹配。只要将这两者正确匹配,验证工作就会变成一个可以重复的流程;如果匹配错误,您就会在整个项目周期内忙于追查那些在铜线和硅芯片中根本不存在的数值噪声。
《仿真 》在变流器设计中究竟发挥了什么作用
电力电子仿真 软件通过代码再现了换流器 及其控制回路的开关行为,因此您可以在投入硬件开发之前,对拓扑结构、调制方案和保护逻辑进行测试。测试范围涵盖从器件级损耗估算到全系统稳定性研究。上述每个问题都需要不同的模型。
一个三电平有源中性点钳位逆变器可以说明原因。如果采用详细的半导体物理模型进行模拟,虽然可以得到开关损耗和结温等参数,但完成一个线周期却需要数小时。若改用具有固定导通电阻的理想开关,该线周期即可在几秒内完成——这种精度对于控制调谐已足够,但对热设计却毫无用处。
这种区分之所以重要,是因为大多数变流器设计团队将仿真 视为一项活动,而实际上它包含三部分。拓扑筛选注重速度;控制验证要求在环路速率下具有正确的动态特性;保护工作则要求在开关边沿处能准确再现瞬态响应。如果仅靠一个模型同时满足这三方面的需求,最终生成的结果往往会让人无法信任。
时间步长的要求决定了您可以使用哪种求解器
时间步长必须能够捕捉到您所关注的最快事件。一个在脉冲宽度调制下以10 kHz频率切换的转换器,其时间步长必须足够小,才能准确捕捉每个边沿;通常在离线状态下,该时间步长约为1微秒,而一旦物理控制器加入控制回路,该时间步长将远小于此值。
假设有一台采用 20 kHz 调制频率的牵引逆变器。在 50 微秒的步长下,每个开关周期仅包含一个采样点,因此脉冲宽度会被量化到求解器的网格上,而你测得的电流纹波源于数值计算而非电路本身。波形在屏幕上看起来合乎情理,却回答了一个你从未提出的问题。
将步长缩短至250纳秒可以消除纹波,但计算负载会增加200倍。这个数字就概括了整个权衡关系。离线工具可以通过延长运行时间来消化这一成本,而实时平台则无法做到这一点,因为每个步骤必须完成后,下一个步骤才能开始,因此要么简化模型,要么将求解任务转移到能够并行执行算术运算的硬件上。
“将时步缩短至250纳秒可以消除纹波,但会使计算负载增加200倍。”
离线建模与实时验证如何划分工作
离线模式下,仿真 可解答设计相关问题;实时模式下,仿真 可解答集成相关问题。您可以在离线环境下对组件进行尺寸选型、选择调制策略并验证控制律,随后在实际控制器需要以全速针对被控对象模型运行时,转入硬件在环(HIL)模式。
在1 MW并网逆变器项目中,交接过程清晰可见。组件选型和损耗预算在离线状态下完成。一旦控制板就位,相同的电站模型便会在连接其模拟和数字I/O的实时仿真器上运行,团队可以模拟电网故障、抗故障运行市场活动 以及传感器故障——这些情况是任何台架测试都无法承受的。
交接环节也是进度延误的常见原因。离线模型中包含一些在固定步长下会悄然失效的假设,包括代数环路、刚性阻尼网络以及会通过不可能电流的理想开关。应预留时间来转换模型,而不是假设它能直接移植。
根据时间步长在CPU求解和FPGA求解之间进行选择
CPU求解与FPGA求解的主要区别在于时间步长的下限。CPU求解器在处理复杂模型和灵活拓扑结构时,时间步长大致在10至20微秒之间;而FPGA求解器则能将时间步长压缩至500纳秒以下,这是因为电路方程是以并行逻辑而非顺序指令的形式运行的。
大多数变流器实验室最终都会同时运行这两部分,而OPAL-RT正是有意进行了这种划分:ARTEMiS 在CPU上求解电气网络(因为模型规模在此处至关重要),而eHS则在FPGA上求解变流器级(因为边沿放置在此处至关重要)。这种划分方式确保了在物理模拟需要高精度的地方保持了相应的精度。
这种划分并非没有代价。任何跨越 CPU 与 FPGA 边界的数据都会增加一个延迟步骤,因此应将该边界设置在耦合较弱的部位,通常是滤波器的电感或直流链路电容器处,而不是桥式电路的中间位置。下表将常见的验证任务与其对应的求解方法进行了对应。
| 验证任务 | 所需的步长 | 为什么这一步很重要 |
| 拓扑筛选与损耗预算 | 10 至 50 微秒 | 表现达到平均水平就足够了,因为你是在比较候选人,而不是对某一位进行认证。 |
| 基于被控对象模型的控制回路调谐 | 1 至 10 微秒 | 该步骤必须满足电流环带宽要求,否则在硬件上无法保持调谐状态。 |
| 使用量产控制器进行硬件在环测试 | 250纳秒至1微秒 | 脉冲沿必须落在控制器认为其放置的位置上。 |
| 宽带隙转换器开关特性研究 | 小于 250 纳秒 | 快速边缘和振铃现象承载着你试图捕捉的信息。 |
| 电网互动与保护协调 | 20 至 50 微秒 | 由于网络动力学起主导作用,因此采用较粗的步长可以以较低的成本扩大模型规模。 |
在实践中,模型保真度转换何时会失效

模型保真度在边界处会出现偏差,这绝非虚言。理想的开关模型会将过渡点设置在步长边界上,因此当步长较粗时,转换器似乎会提前或延迟开关,偏差甚至可达一个完整的时间步长。这会改变有效占空比,并在输出电流中表现为直流偏移。
电动牵引驱动系统让这一成本变得切实可见。2025年,全球电动汽车销量突破2000万辆,约占新车总销量的四分之一,而每一套动力总成都需要先针对特定电机型号对逆变器进行验证。在20 kHz频率和1微秒步进的情况下,半步的边沿误差相当于开关周期的1%,这足以导致扭矩估算出现偏差,而这种偏差通常只有在测功机上才能显现出来。
插值开关通过计算阶跃内部的确切交叉点(而非四舍五入到边界),纠正了其中大部分问题。虽然这会消耗求解器的时间,但正是这一特性,将值得信赖的转换器模型与仅能运行的模型区分开来。在比较电力电子仿真 工具时,请先询问过渡点的放置方式,再询问阶跃大小。
“理想的开关模型将过渡点设置在步长边界处,因此当步长较粗时,变流器似乎会提前或延迟开关,延迟幅度可达一个完整的时间步长。”
转换器验证程序中的常见故障模式
大多数转换器验证问题归根结底源于流程而非物理原理。模型往往是为了解决某个问题而构建的,却被用于解决另一个问题;时间步长往往是出于习惯而选定的;而且没有人记录是哪一版本的被控对象模型产生了哪项测试结果。
五种情况占了工时损失的大部分。
- 在保护研究中重复使用控制调谐模型,此时理想开关会掩盖你试图捕获的过电流暂态。
- 根据平台允许的范围来选择时间步长,而不是根据最快的赛道赛事的要求来选择。
- 不为工厂模型分配版本号,因此两周后无法重现测试失败的情况。
- 跳过离线到实时转换的检查,并在调试期间发现代数循环。
- 当故障发生在换流器、滤波器和电网阻抗之间时,仅对换流器进行验证。
版本控制这一点值得更加重视。一次转换器验证活动会在不同固件版本间产生数百次运行,如果没有记录来关联模型版本、求解器设置和固件构建版本,就无法区分真正的回归问题与某人调整过的假设。
长期坚持进行规范的转换器验证能为您带来什么
那些根据时间步长要求而非惯例来选择求解器的转换器组,在实际应用中会遇到更少的意外情况。这一原则说起来简单,做起来却很难坚持。要明确电路中速度最快的事件,选择能解决该事件的时间步长,并保留产生所有已报告结果的模型。
经过几个项目周期,这种习惯便逐渐根深蒂固。由于大家信任损耗模型,组件尺寸的确定不再被反复讨论。控制回归问题会在固定步长运行中显现,而不是在测试台上。曾经需要牺牲一个原型机才能完成的故障测试,现在午饭前就能完成。
使用OPAL-RT的团队通常会采用相同的分区方式:在 CPU 上求解电力网络(因为模型规模至关重要),而在 FPGA 上求解变流器级(因为边缘放置至关重要)。关键不在于硬件本身,而在于两者之间的界限已成为你刻意做出的设计决策,而且在每次评审中,当有人问你对幻灯片上的数据有多大信心时,你都会切身感受到这种差异。

电力系统
10 / 24 / 2026
800 VDC power distribution for AI data centers
An explanation of how 800 VDC power distribution carries power from the grid to AI racks, covering conversion stages, DC fault protection and bus stability.

汽车
2026年10月21日
重型卡车兆瓦级充电系统的验证
本文从实际角度探讨了兆瓦级充电系统的运作原理、其与CCS系统的区别,以及在卡车充电站通电前如何对充电设备控制系统进行测试。

汽车
2026年10月19日
电动驱动程序中测功机测试与电机仿真的对比
针对电动驱动程序,对测功机测试与电机仿真进行了比较,内容涵盖了每种方法能验证什么、成本如何,以及各团队如何安排这两种方法的测试顺序。