★ FEATURED ARTICLE 飞行汽车这个词听起来像是科幻片道具但真正把一版eVTOL电动垂直起降飞行器的电控方案做过一遍之后你会发现它本质上就是一台对安全冗余要求苛刻到极致的高速电动车。整条电控链路上最核心的三块东西是主控MCU、电机驱动和功率逆变器。而在过去几年我接触过的技术方案里英飞凌的AURIX和SiC几乎是一个绕不开的组合——前者负责系统大脑后者负责功率心脏两者放在一起基本就是飞行汽车完整电控技术版图的主干。这篇文章不讲PPT框架我想结合自己调板子、跑方案时的实际理解把从AURIX到SiC这条链路掰开揉碎说清楚让准备入行的团队知道该往哪儿使劲也让已经在用这些芯片的人少走几个弯路。1. 飞行汽车的电控骨架为什么偏偏是AURIX加SiC这套组合一台飞行汽车和一台电动车的区别不只是多了几个螺旋桨。地面车辆在出现严重故障时最坏结局是靠边停车等待救援飞行器则不行任何一个推力单元失效都要靠剩余通道继续维持可控飞行。这意味着电控系统的每一层从控制、驱动、功率到通信都必须具备冗余和故障隔离能力而且关键动作必须要有确定的时间边界。从电气参数上看飞行汽车几乎就是照着高压高功率路线设计的。电压平台从普通汽车的400V直接拉到800V甚至更高单台电机的功率随便就是50到150kW起步整机悬停时所有电机长时间处于接近满功率输出状态。悬停阶段对逆变器效率极其敏感效率每下降一个点航程和留空时间立刻就会反映出来。高压、大功率、长时间高负荷这三个词加在一起基本就决定了功率半导体的选型方向。IGBT在600V到1200V级别依然可靠但开关频率上不去、开关损耗偏大在需要极致功率密度的飞行器上并不划算。SiC MOSFET的耐压、高温能力、低开关损耗正好卡在这个需求点上。MCU层面的选型逻辑也同样清晰。飞行控制、电机控制、状态监控这些任务需要在一个平台上同时跑并且要满足严格的功能安全等级。AURIX系列从第一天起就是按照ISO 26262的ASIL-D目标设计的多核、锁步、硬件安全管理单元、硬件定时器这些都是标配。更关键的是AURIX在汽车和工业驱动领域积累了非常完整的软件生态底层有iLLD和MCAL上层有AUTOSAR应用层有各种电机控制参考方案。所以英飞凌这套版图逻辑上其实很直接AURIX解决系统是否安全可控SiC解决功率能不能高效可靠地送出去中间的EiceDRIVER驱动芯片再把这两个世界衔接起来。对比市面上MCU和功率器件各买各的做法这种组合的优势在于整条链路是经过协同验证的。后文把每个环节拆开讲先从作为大脑的AURIX说起。2. AURIX到底强在哪不是多核跑得快而是关键活都交给了硬件外设2.1 TC2xx与TC3xx先分清你手里拿的是哪一代AURIX这个家族跨度很大。TC264这种属于第一代双核产品主频200MHz级别在车身控制、电池管理、中小功率电机驱动里非常常见很多做BMS和EPS的团队对它熟得不能再熟。到了TC3xx这一代比如TC377、TC397就是第二代产品核心数到了三核、六核主频拉到300MHz片上Flash和SRAM容量也大了一圈算力提升明显。选型时最容易犯的错是只看主频够不够。TC264如果只是裸机跑写逻辑其实和一颗普通的高性能MCU拉不开差距真正能拉开差距的是外设和工具链。做飞行汽车主飞控或者主驱协同控制器我建议直接上TC3xx理由不是单纯算力强而是TC3xx在冗余、诊断、高精度定时器方面的设计更完整留的余量也更足。TC264更适合做分布式执行器节点比如某个舵机控制器、某个电池采样板这类对算力要求不高但需要稳定可靠的任务。对比维度TC264第一代双核TC3xx第二代多核典型型号TC264、TC275TC377、TC397核心与频率双核200MHz级别三核/六核300MHz级别片上资源满足车身与中小驱动场景大容量Flash/SRAM资源明显宽裕适合定位执行器节点、中小功率控制主飞控、主驱协同、高冗余主控2.2 GTM真正让AURIX适合电机控制的是这个定时器模块很多第一次接触AURIX的人会问同样是MCU凭什么说它适合电机控制原因就在GTMGeneric Timer Module这个模块上。GTM不是普通MCU上的那几个高级定时器而是一个完整的、独立于CPU的定时器子系统它内部有多个子模块协同工作。在电机控制里最常用的组合是TOM和ARU。TOM负责生成多路PWM输出ARU负责在模块之间传递数据。可以把它理解成一个硬件级的调度员CPU算完FOC之后把占空比结果写到GTM的寄存器里之后所有PWM边沿、死区延迟、互补输出都由GTM自己完成CPU不需要再为波形细节操心。更重要的一点是GTM可以生成带死区的互补PWM而且死区时间可配这对三相桥式逆变器是刚需。GTM里的DPLL数字锁相环也是好东西特别适合处理旋变、编码器的位置信号。飞行汽车电机控制对转子位置精度要求很高如果每个角度脉冲都靠CPU中断来处理主控很容易被实时任务淹没。DPLL能用硬件完成位置信号解码和角度运算CPU只读结果这等于把最耗时的脏活从软件里摘了出去。还有一点必须单独强调GTM支持故障输入硬关断。电机控制里最怕的事不是报错而是PWM停不下来。GTM可以在检测到外部故障信号比如过流信号的同一个硬件周期内立即封锁所有PWM输出这个响应时间是确定的、微秒纳秒级别的不依赖任何软件判断。飞行器恰恰最需要这种出事即断的确定性这也是我推荐把电机控制放在AURIX平台上的核心原因之一。2.3 锁步核与SMU飞行安全真正依赖的硬件机制AURIX经常被安全工程师挂在嘴边的一个词是锁步核Lockstep core。原理不复杂两个CPU核执行完全相同的指令硬件模块把两份输出逐周期比对一旦结果不一致立即触发SMU安全管理单元错误处理。单点故障不需要靠软件自检去发现硬件本身就会给出信号。对飞行汽车来说这相当于给主控上了一道双重保险。SMU的角色是把各种错误事件分类、分级。过流属于紧急错误可能走故障输出引脚直接断PWM某路温度过高属于警告先上报任务再处理。每一类错误映射到哪个动作都可以根据安全概念来配置。再加上HSM硬件安全模块负责密钥管理和系统完整性校验主控可以从上电开始就确认自己的健康状态这在功能安全审查里是非常有分量的技术依据。我个人的体会是AURIX这套安全机制并不是给软件加负担而是把很多安全证明工作从软件挪到了硬件。软件只需要按照规范读取错误状态并执行策略剩下的比较、诊断都是硬件在后台跑系统设计反而简单很多。飞行器项目做安全分析的时候有这种硬件基础能省下不少和审查方来回解释的精力。2.4 开发工具链怎么选IDE、编译器和调试器AURIX的官方IDE叫AURIX Development Studio也就是常说的ADS免费基于Eclipse集成开发环境下载后基本开箱即用。ADS本身自带基于GCC的编译器工具链对个人学习和原型验证完全够用。如果进入量产项目有AUTOSAR、MCAL或者特定编译器认证要求再考虑TASKING、HighTec这类第三方工具链。TC264经常被问该用哪个编译器其实这个问题没有标准答案。我的建议是原型阶段用ADS默认工具链别在工具上折腾太多等进入量产前再按照整个软件栈对编译器特性的要求做一次切换。不同编译器对中断关键字、位域操作、内存布局的默认处理方式都不一样交叉切换代码不是复制粘贴就能搞定的所以这个决定早点做比晚点做好。调试器方面入门用英飞凌自家的DAP调试器配合Memtool烧录成本可控如果要大规模调试多核应用Lauterbach TRACE32依然是战斗力最强的选择就是不便宜。ADS工程搭建和调试里常见的坑我会在文章后半段专门展开。3. SiC那半边器件、驱动电路和那个绕不开的串扰问题3.1 为什么飞行汽车逆变器要切到SiC结论先行SiC MOSFET在大功率电机驱动里是用效率换航程的关键角色。在800V级母线上1200V的SiC器件比同等级IGBT在开关频率和开关损耗上有明显优势。IGBT通常在8到10kHz开关频率下运行再往上拖尾电流和开关损耗会迅速恶化SiC很轻松可以跑到20kHz以上甚至更高。开关频率提高的直接好处是电机电流谐波变小铁损和噪音下降还允许把滤波电感做得更小更轻对飞行器轻量化非常友好。悬停时电机长时间满功率输出开关损耗的降低直接体现在发热和效率上在续航预算里这是一笔非常可观的账。CoolSiC系列MOSFET的正温度系数特性还让并联均流变得相对容易多管并联做大功率逆变器时省不少心。但SiC绝对不是更快的IGBT那么简单。开关速度上去了电压变化率dV/dt到了几十伏每纳秒寄生参数的影响力被无限放大。很多团队第一次做SiC逆变器板子还没怎么跑就出问题原因几乎都出在驱动电路和串扰控制上。3.2 驱动电路设计的核心参数电压、电阻和隔离SiC MOSFET的栅极驱动电压和IGBT不完全一样。开通电压通常给到15到18V为了把导通电阻压下去关断电压建议给-3到-5V的负压而不是0V原因就是后面要讲的串扰问题。栅极电阻往往分成开通电阻和关断电阻两路中间用二极管隔开目的是分别控制开通速度和关断速度在开关损耗和EMI之间找平衡。栅极电阻放得越靠近器件引脚越好回路越小越不容易受干扰。我见过不少新手的板子SiC器件的功率回路和驱动回路没有做源极分离导致功率回路的寄生电感分压叠进栅极驱动信号里波形乱七八糟。正规做法是采用开尔文源极连接驱动回路的参考点独立接在器件源极引脚上和功率回路分开走线。驱动电源也必须是隔离的通常每个桥臂用一个独立的小功率隔离DC-DC或者带变压器的反激电源供电否则高压侧的开关噪声会顺着驱动电源串得到处都是。EiceDRIVER系列是英飞凌配SiC用的驱动IC常见的单通道双通道隔离驱动都带了不少硬核功能DESAT过流保护负责检测饱和压降有源米勒钳位负责压住关断状态下的栅极软关断在过流时降低关断尖峰UVLO欠压锁定防止驱动电压不够时误开通。这些功能在大功率SiC场景不是可选项是需要认真对待的必选项。3.3 串扰到底是怎么回事SiC半桥最容易踩的坑串扰是实测中经常翻车的点。拿最常见的半桥电路来说高侧管Q1开通时它的漏源电压从母线电压快速下降到接近零这个dv/dt会通过Q1的米勒电容Cgd传导出来但实际受害的是同一桥臂的低侧管Q2。Q2此时处于关断状态栅极被驱动负压压住但高侧管的高速dv/dt会通过Q2自身的Cgd向栅极注入电流在栅源之间形成电压尖峰。如果这个尖峰超过Q2的VGS(th)Q2就会瞬时误开通上下管直通母线电压直接短路烧器件基本就在一瞬间。SiC比IGBT更容易触发串扰原因很直接开关dv/dt更高、栅极电荷更少、阈值电压又偏低留给负压的噪声裕量本来就不多。所以关断负压不是随便给的。我对比过同一块板子在-2V和-5V关断电压下的表现同样的布局和dv/dt-2V那块的振铃尖峰明显更危险。解决串扰的方向大致有四条。第一加深关断负压把噪声裕量做大。第二用驱动器的有源米勒钳位功能一旦检测到栅极电压掉到夹断值以下内部钳位管导通把米勒电流旁路掉从而压住尖峰。第三优化栅极回路尽量减小寄生电感。第四在极端情况下稍微调慢dv/dt也就是增大开通电阻代价是开关损耗增加。验证手段就是双脉冲测试看VGS波形。串扰应对手段核心思路代价/注意点加深关断负压提高噪声容限驱动电源复杂度增加有源米勒钳位旁路米勒电流依赖驱动器功能支持优化栅极回路/开尔文接法降低耦合路径布板要求提高增大开通电阻降低dv/dt开关损耗增加3.4 功率回路和布局的隐性门槛SiC的开关速度决定了功率回路电感是生死线。我常说一句话SiC逆变器的命一半写在布局上。功率回路指的是母线电容、开关管、续流二极管、输出端子构成的电流路径这个回路的寄生电感一定要压到最低通常要靠叠层母排、大面积铺铜、电容紧贴器件来实现。为什么这么较真回路的寄生电感配合SiC的大di/dt会在关断瞬间产生电压尖峰公式就是VL*di/dt。di/dt一大几纳亨的寄生电感都能制造几十伏的尖峰吃掉的电压余量可能直接让管子进入雪崩区。散热也要单独说SiC模块结温上限高但热流密度也大冷板设计、导热材料、器件贴装都得按功率密度重新算不能照搬IGBT那套水冷板经验。飞行器上散热条件往往比地面车辆更苛刻这一点在设计初期就要和结构团队一起定方案。4. 从AURIX到SiC串成一条完整链路主驱电机控制方案这样搭4.1 一套PMSM主驱方案的信号流现在把两半拼起来看。一套典型的飞行汽车主驱方案信号流向大概是这样的旋转变压器或者编码器把电机转子位置送给AURIXAURIX的GTM用DPLL解析这些位置信号得到实时转子角度同时三路相电流经过采样电阻或者电流传感器进ADC由GTM触发在PWM周期的中心点采样避开开关噪声尖峰底层跑Clarke变换、Park变换然后两个电流环PI调节器输出d轴和q轴电压再经过逆Park变换得到三相电压给定最后SVPWM把目标电压转换成占空比写到GTM的TOM模块GTM自动生成带死区的六路PWM经过EiceDRIVER驱动再驱动SiC三半桥最终输出到PMSM。这整条链路里GTM不只是生成方波它还担当了时间基准的角色。PWM中心对齐、ADC采样触发、占空比更新、故障封锁都以GTM的时间轴为主。这样CPU就不用在中断里掐着时间点去追PWM边沿软件压力小很多也不会出现采样点偏移导致的电流波动。英飞凌面向电机控制也提供iMOTION系列的一体化电机控制IC但那个更适合家电和工业小功率场景飞行汽车主驱要做深度定制、安全冗余和复杂保护还是AURIX加独立驱动加SiC模块这条路线更合适。4.2 飞行工况对FOC算法的额外要求电机控制算法本身是成熟的但飞行场景会让人更较真。悬停状态下每个电机都要输出精确而稳定的转矩电流环的带宽和延迟都需要仔细调转子位置延迟补偿没做好轻则静差重则带载抖动。我建议在整机集成之前先做一台静态推力测试台专门标定电机控制器在小转矩下的波动和响应带宽把姿态控制给到的转矩指令动态也录下来看。巡航时如果需要高速弱磁控制必须平滑过渡。SiC的高母线电压会让高速范围显得很宽裕但弱磁区域的电流分配和温度保护也要提前写好否则长时间在弱磁区运行电机发热和退磁风险会冒出来。逆变器的故障信号应当直接接到GTM的故障输入让最坏情况发生时AURIX可以先在硬件层面切断PWM再进中断做善后。这套硬件断PWM、软件管恢复的分工是我在项目里坚持的原则。4.3 冗余和安全飞行器电控和汽车电控的分水岭汽车电控讲安全飞行器电控讲不能只靠一次硬件正常。整个系统的余度设计要从架构做起。AURIX内部的锁步核是主控层面的一套自检但系统级还需要双控制器、双电源、甚至双套驱动器和双套功率级。比较常见的做法是双绕组电机配双逆变器一个通道失效后另一个通道还能顶住部分推力继续飞行让飞行员或飞控有时间完成安全处置。传感器也别省转子位置传感器至少做两路互相校验相电流采样最好有两路独立通道通信层面CAN FD做双通道或者用带冗余的以太网。AURIX的SMU在这里的用法是把关键故障统一转发给外部安全监控MCU由它决定降级策略而不是让主控自己既当运动员又当裁判。我在项目里还坚持一件事从设计验证阶段就必须做故障注入不是模拟寄存器逻辑是真的把PWM输出对地短路、把相线剪断、把旋变线拔掉看系统在真实故障下能不能按预期安全降级。这种测试暴露出来的问题比任何仿真都更有价值。4.4 从方案到板子拓扑选型和器件清单的思考顺序如果从零开始选择一套平台应该按什么顺序思考先把系统需求列出来母线电压、电机峰值和连续功率、开关频率、冗余通道数、冷却条件。然后定逆变器拓扑大多数情况下就是三相两电平全桥多通道就并行。接着选SiC模块或分立器件功率等级小用分立封装功率大了用半桥模块、H桥模块英飞凌的汽车级模块在车规供应链里验证非常多。再定驱动IC单管单驱或双管双驱按拓扑选。最后回到AURIX具体型号把需要的ADC通道数、GTM通道数、CAN/FD接口、锁步核数量、片上Flash容量都捋一遍。这时候你会发现选型其实是一个需求倒推的过程而不是先看哪个芯片热门。很多团队先把芯片定死再凑方案后面越做越别扭就是这个顺序反了。5. 落地时绕不开的坑ADS工程搭建、烧录调试与SiC实板经验5.1 ADS的下载安装和第一个工程很多人第一次装ADS就卡住。建议到英飞凌官网注册个人账号直接在下载中心找AURIX Development Studio选择对应系统版本下载。安装时留意两点一是路径不要带中文和空格否则后面编译报错会让人崩溃二是首次启动会让设置workspace目录建议专门建一个干净目录放工程。新建工程时向导会让你选芯片型号、编译工具链和工程模板。新手最推荐选自带iLLD库的空工程模板至少先确认编译器、链接脚本、启动文件能正常通过编译再往里加自己的代码。工程结构里iLLD库里包含了外设驱动的封装可以直接当底层库来用学习价值很高。常见的问题包括老工程拿到新版本ADS编译报错、明明装好了编译器却提示找不到、DAP调试器不识别。这些大多和版本匹配、驱动安装有关先检查IDE日志和DAP接线比反复重装软件更有效。5.2 调试顺序从点亮GPIO到跑起一台电机拿到一套新平台我不建议一上来就写完整的FOC。先把GPIO点灯、时钟配置、串口或CAN通信跑通再用一个定时器产生简单PWM用示波器确认波形。第二步做ADC采样把相电流、母线电压读到串口打印。第三步接上旋变或编码器确认位置角度连续且方向正确。第四步才把GTM的PWM和FOC算法结合起来先给开环占空比观察电机是否平稳转动、电流波形是否正常再上闭环。AURIX的引脚复用非常灵活但反面就是配置繁琐。外设不输出、信号没反应的时候先回寄存器里确认端口功能是否配置正确不要先怀疑芯片坏了。多核调试时也要特别注意TC397这种六核片子如果某些核没有正常启动会导致部分外设没反应在线调试时要学会单独暂停指定核来看状态。5.3 TC264的编译器选型以及别在编译器上浪费时间TC264到底用哪个编译器这个问题被问得很多。我的回答是快速验证用ADS自带工具链免费且够用如果项目明确要上AUTOSAR再根据MCAL供应商支持的编译器清单来选。TASKING、HighTec都是成熟选择但各有版本和license成本。最不该做的事是项目途中频繁切换编译器因为位域、字节序、中断函数、内联汇编这些语法在不同编译器下表现不一样重写工作量非常大。更好的做法是项目一开始就把编译器和底层库版本锁定出一个编译基线之后所有人都在同一个基线上开发。我见过不少团队在用哪个编译器这种工具问题上反复折腾真正该花精力的电机控制算法和系统保护反而没时间细抠。工具链本质上是为了支撑应用TC264也好、TC3xx也罢都只是平台最终交付的是能稳定飞行的系统而不是好看的编译配置界面。5.4 SiC板子先做双脉冲测试再从测试台走向试飞新画的SiC功率板上电之前先做双脉冲测试DPT这是行业里公认的体检项目。双脉冲测试可以在不接电机的情况下单独验证某个桥臂的开通、关断波形测量开关损耗、评估VDS尖峰、检查串扰。通过DPT你可以直观看到栅极电阻选得合不合理开通电阻大了开关慢、损耗高关断负压不够串扰尖峰很吓人吸收电路是否必要也一目了然。做DPT测量时有个经验VGS要用差分探头带宽至少几百MHz测量点要尽量靠近引脚别用带长地线的无源探头那会把地回路电感加进去测出来的波形根本不能信。还要注意空载跑PWM和带载跑完全两码事带载时的母线电压跌落和噪声小功率空载测试根本模拟不出来。所以板子验证节奏应该是双脉冲测试、低功率对拖测试、满功率加载测试、最后才装机。5.5 写在最后三件我建议团队早点做好的事最后再聊几句我自己的体会。第一件事把AURIX和SiC当成一套系统来学不要分开研究。很多资料是分开的但真正出问题都在接口和配合的地方比如GTM的PWM和驱动器输入端的时序关系、SiC开关带来的噪声对MCU采样的影响。先把一套参考方案整体跑通再开始自己改效率高得多。第二件事硬件、驱动、算法三拨人尽早对齐。串扰问题软件觉得是硬件问题硬件觉得是驱动问题驱动觉得是算法问题实际往往是三者耦合在一起。每周固定时间坐在一起看波形哪怕是远程共享示波器截图都能提前解决很多隐性矛盾。第三件事留好调试接口。CAN日志、上位机波形、故障记录存储这些在测试阶段是救命的东西。飞行汽车项目时间紧、测试场景多很多时候问题只在试飞中出现一次如果没有完整的日志回放能力排查起来几乎无从下手。把这套调试基础设施当做和硬件一样重要的交付物是我在做这块项目时最深的感受。
阅读完成 · 觉得有帮助？
