做分布式驱动汽车稳定性控制最直观的感受是车变“活”了但问题也变多了。四个轮子各自带一个驱动电机每个轮子的扭矩都能独立控制这对整车动力学控制来说是一个全新维度。传统燃油车时代稳定性控制依赖发动机总扭矩调节和单轮制动干预能用的“牌”不多到了分布式驱动平台每个轮子都是一张牌怎么出牌、出多大力、什么时候出就成了一个典型的“多执行器协调控制”问题。而这里面最核心的抓手就是直接横摆力矩控制Direct Yaw-moment Control, DYC——通过左右两侧车轮的驱动力差人为制造一个绕车辆垂直轴的力矩把车辆的横摆运动拉回驾驶员期望的轨迹上。这篇文章把我在开发一套分层式直接横摆力矩控制策略时的完整思路、架构设计、控制算法选型、仿真验证到实车调试的整个过程做个总结。适合正在做分布式驱动整车控制、底盘集成或者学生毕设相关方向的朋友参考。我不会只讲“分了两层所以好了”这种空话而是把每一层为什么要这么设计、参数怎么定、调试时会踩哪些坑都写清楚。看完之后你应该能自己搭出一套可运行的稳定性控制框架。1. 传统稳定性控制与分布式平台之间差的不只是执行器1.1 传统ESC在分布式平台上为什么“水土不服”先聊一个经常被忽略的问题传统车身稳定系统ESC的核心逻辑是“制动优先”。当车辆出现过多转向时ESC通过对弯内侧前轮施加制动产生一个额外的横摆力矩来抵抗甩尾出现不足转向时则对弯内侧后轮制动帮助车头往弯里收。这种策略在集中式驱动平台上是合理的因为发动机只能输出一个总扭矩无法单独控制左右车轮的驱动力矩制动力矩是唯一能快速独立作用于每个车轮的手段。但到了分布式驱动平台这套逻辑就显得很浪费了。四个轮毂电机或轮边电机可以独立输出正负扭矩这意味着车辆完全可以通过左右驱动力差来产生横摆力矩而不需要牺牲车速去制动。举个例子一个向左急转弯的工况车辆出现转向过度传统ESC的做法是给右前轮一脚制动把车速也拖下来了而分布式驱动平台可以直接加大左侧车轮的驱动扭矩、同时减小甚至反向输出右侧车轮的扭矩在几乎不损失纵向速度的情况下把横摆力矩补回来。另一个问题在于传统ESC的制动干预是在一个相对窄的执行器带宽内工作的——液压制动系统的建压时间通常是100到300毫秒而且制动压力控制本身存在非线性比如摩擦片的动静摩擦切换、制动液的温度特性等。分布式驱动的电机扭矩响应时间一般在10到50毫秒带宽高了一个数量级这为控制算法提供了更大的设计空间但同时也意味着算法必须处理更高频的状态信息否则执行器的快速响应反而会放大噪声和控制误差。所以说在分布式驱动平台上直接套用传统ESC的控制逻辑本质上是用一种低自由度的思路去指挥高自由度的执行器既浪费硬件能力也掩盖不了控制架构本身的局限性。1.2 直接横摆力矩到底在控制什么物理量要理解DYC先要弄清楚它控制的核心物理量是什么。车辆绕垂直轴z轴旋转的力矩叫横摆力矩记为M_z车辆绕z轴的旋转角速度叫横摆角速度记为r。车辆在转弯时真正决定“转得灵不灵”的是两个状态量横摆角速度r和质心侧偏角β。横摆角速度直观反映了车辆转动的快慢驾驶员打方向盘心理预期的是车辆以一个符合当前车速和转向角的速度转过弯来质心侧偏角则反映了车辆实际运动方向和车头朝向之间的夹角这个量一旦过大车看起来就像“横着滑”一样这时候无论怎么打方向车辆都不会按照轮胎指向的方向转弯因为轮胎已经进入饱和状态。DYC的核心思想很直接通过左右侧车轮的纵向力差产生一个人为的附加横摆力矩ΔM_z让车辆的实际横摆角速度和质心侧偏角都尽量贴近驾驶员意图所对应的参考值。用一个简单的线性二自由度车辆模型来说明参考横摆角速度的计算r_d Vx × δ / (L × (1 K × Vx²))其中Vx是纵向车速δ是前轮转角L是轴距K是稳定性因子。K大于0表示不足转向K小于0表示过多转向。这个公式的物理含义是在稳态转弯工况下一个给定车速和方向盘转角所对应的“正常”横摆角速度应该有多大。DYC的工作就是当实际横摆角速度偏离这个参考值时计算出需要补充的ΔM_z是多少。但注意这个参考值只在轮胎线性区是准确的。在极限工况下轮胎侧向力饱和实际能达到的最大横摆角速度远小于线性模型的预测值所以必须要对参考值做饱和限制。限制的方法通常是考虑路面附着系数μr_max ≈ μ × g / Vx。这个限幅看起来简单但在实际工程中路面附着系数的估计本身就是一个大坑后面我会专门说。2. 分层式架构的诞生逻辑为什么非得分层不可2.1 单层一体化控制的痛点设计一个统一控制器输入车辆状态直接输出四个轮子的扭矩命令从控制理论的角度看似乎更“优雅”——省略了中间环节理论上可以实现全局最优。但落到工程实际一体化方案有几个难以绕开的痛点。第一个痛点是状态维度带来的设计复杂度。车辆动力学模型本身是非线性的状态量包括纵向速度、侧向速度、横摆角速度、质心侧偏角、四个轮子的转速等再加上轮胎的非线性特性如果在一个控制器里同时处理这些耦合关系控制器的设计、调参、稳定性证明都会变得非常困难。更何况模型不准确是常态一个对模型误差高度敏感的一体化控制器在实车上是灾难。第二个痛点是从研发分工的角度。在整车厂或者零部件供应商的架构里车辆运动控制VMC和扭矩矢量分配往往是不同团队负责的。运动控制团队关心的是“车辆要产生多大的横摆力矩和纵向力”扭矩分配团队关心的是“四个轮子怎么出力才能满足这个需求”。如果做成单层控制两个团队就得同时改一个控制器代码耦合度高版本管理混乱现场标定更是谁也说不清问题出在哪。第三个痛点是故障降级。分布式驱动的核心优势之一就是容错某个电机故障时可以通过其他三个轮子重新分配扭矩来维持车辆稳定。但如果是一体化控制器故障后需要重新设计整个控制律这在运行时是不可能完成的而分层架构下只需要在上层保持原有控制律在下层分配器中把故障轮的扭矩约束设为零即可其他三个轮子的分配权重重新计算就行了。2.2 分层式控制的职责切分与信息流我采用的架构是经典的两层结构有些团队会拆成三层外加底层执行器控制但核心逻辑是一致的。最顶层是“决策层”也叫上层控制器。它接收驾驶员输入方向盘转角、加速踏板/制动踏板开度和车辆状态反馈横摆角速度、质心侧偏角估计值、纵向车速基于参考模型计算期望的横摆角速度r_d和期望质心侧偏角β_d然后通过控制律计算出车辆需要的总纵向力F_xd和附加横摆力矩ΔM_z。这一层的输出是一个“力/力矩需求”和具体执行器无关——你可以用电机实现也可以用制动系统实现甚至可以混用上层不关心。最底层是“分配层”也叫下层控制器。它接收F_xd和ΔM_z结合每个车轮的垂直载荷估计、路面附着估计、电机峰值扭矩限制等约束把总需求分解为四个车轮的各自扭矩命令T_fl、T_fr、T_rl、T_rr。分配层只关心“怎么分最合理”不需要理解车辆为什么需要这个横摆力矩。这两个层之间传递的信息量很小一个纵向力需求、一个横摆力矩需求加上一些状态和约束条件。这种清晰的信息流带来三个直接好处一是上层算法可以在各种平台间复用我在开发过程中就用同一套上层控制器分别匹配过轮毂电机试验车和四轮驱动混合动力模型二是底层分配器只需要保证“给的力和力矩尽量等于需求”逻辑验证和质量把控都能独立完成三是控制问题的复杂度被拆解为“决策”和“分配”两个相对独立的子问题每个子问题都能用成熟的理论工具单独解决。3. 上层决策层设计目标横摆力矩计算的几个实用方案3.1 参考模型不只是线性二自由度那么简单参考模型的输出是上层控制器的跟踪目标。最基础的就是前面提到的线性二自由度参考横摆角速度但实际工程中参考模型需要包含三个额外处理环节。第一环节是稳态增益的限幅。如前面所说路面附着决定了车辆能达到的最大横摆角速度所以要对参考值做饱和处理r_d min(r_model, μ·g/Vx)。这里的路面附着系数μ不能设置为定值否则在低附着路面上参考值会远大于实际能达到的值控制器会命令一个巨大的横摆力矩结果就是车轮打滑加剧。我的做法是实时估计μ低通滤波后用于参考值的限幅。第二环节是瞬态响应的整形。线性二自由度模型给的是稳态值但实际车辆有一个瞬态响应过程。如果直接把稳态值作为跟踪目标控制器的跟踪误差在瞬态阶段会非常大。做法是给参考模型加一个一阶惯性环节r_d_actual r_d_ss × (1 - exp(-t/τ))τ根据车辆参数和车速调整一般在0.1到0.2秒。这个τ值调好了双移线的跟踪表现会明显改善。第三环节是质心侧偏角参考值的设置。理论上β_d应该设为0但实际中在不足转向工况下车辆天然会有一个负的侧偏角强制要求β0会导致控制器输出一个不合理的横摆力矩。更实用的做法是设定一个β的边界约束比如在常规工况下允许β在±2度范围内波动超过边界才重点控制。3.2 滑模控制、LQR和PID哪个更适合第一版标定上层控制器的核心任务是根据横摆角速度误差e_r r - r_d和质心侧偏角误差e_β β - β_d计算ΔM_z。我做过几种控制器的实车对比结论是最省事的不一定最好用最好用的不一定最稳定。PID是最容易上手的选择。横摆角速度偏差作为输入P项提供即时响应I项消除稳态误差D项抑制超调。问题在于PID对车辆参数变化比如载荷变化导致横摆转动惯量改变和路面附着变化的自适应能力很差同一个参数组在干燥沥青路面上跑得好好的换到低附着路面就完蛋。所以PID只建议在早期算法验证阶段使用搞清楚控制对象的响应特性。LQR线性二次型调节器是我第二版的选择。用线性二自由度模型作为预测模型定义状态变量为x [e_r, e_β]^T控制量为ΔM_z设计一个二次型性能指标J ∫(x^T Q x R u²)dt求解Riccati方程得到反馈增益K。LQR的优势是可以显式地权衡横摆角速度跟踪精度和质心侧偏角约束之间的权重比如在高速工况下Q矩阵中β对应的权重会调得更大因为高速时侧偏角过大的危险性远大于低速工况。实际调参时Q和R的初始值可以设为对角阵先固定R然后逐个增大Q的对角元素观察仿真里两个状态量的响应找到一个平衡点。我这套系统的初始参数是Q111横摆角速度权重、Q225侧偏角权重、R0.01后续根据低附着路面的表现又做了调整。LQR在常规工况下表现很好跟踪误差小控制量平滑但遇到强非线性工况比如轮胎进入饱和时线性模型的控制律就有些力不从心。滑模控制SMC是我最终的选择。原因不是它的理论多么漂亮而是它的鲁棒性在实车上经得住考验。滑模控制的思路是设计一个滑模面s e_r λ·e_β然后通过控制律让系统状态快速收敛到这个滑模面上并保持在上面滑动。滑模面的物理含义很直观它把横摆角速度误差和质心侧偏角误差组合成一个标量当s0时车辆状态就在期望的稳定域内。控制律采用趋近律设计ΔM_z -k·sgn(s) 前馈项。这里最需要注意的是符号函数sgn(s)会导致控制量高频抖振在实车上表现为扭矩命令的剧烈跳变轻则影响平顺性重则激励传动系统共振。解决方法是把sgn(s)替换为饱和函数sat(s/Φ)Φ是边界层厚度取值范围在0.05到0.15之间。Φ太小平顺性差太大跟踪精度差这个参数我在仿真和实车之间反复调了好几轮才找到合适值。3.3 质心侧偏角的估计工程里最头疼的一块质心侧偏角β在乘用车上通常没有直接传感器因为需要高精度的GPS/惯导组合导航系统才能测准量产车根本不可能标配。所以β只能靠估计算法算出来。最朴素的计算方法是对β的微分方程积分β_dot (ΣF_y / (m × Vx)) - r这个公式看着简单实际用起来问题很多轮胎侧向力ΣF_y需要估计Vx在急加减速时也不准而积分运算对噪声和偏差极其敏感一个小的传感器偏差经过几秒钟积分就会让β估计值漂移得离谱。工程上比较务实的方案是用扩展卡尔曼滤波器EKF系统的状态量取β和r观测量取横向加速度a_y和横摆角速度r横摆角速度已有陀螺仪可直接测量。这里的核心是把轮胎模型线性化在预测步骤中用线性二自由度模型预测下一时刻的状态在更新步骤中用a_y的测量值修正预测值。EKF在干燥路面、常规驾驶工况下能把β估计误差控制在1度以内但在低附着路面或激烈转向时误差可能飙到3到4度这已经足以让上层控制器的输出产生明显偏差。我的做法是给β估计值加一个“可信度判断”当横向加速度a_y与方向盘转角推算的期望横向加速度偏差过大时认为车辆已经进入非线性区EKF的预测模型不再可靠此时降低β在控制器中的权重把控制重心更多放在横摆角速度跟踪上。这个策略虽然不是学术上最优雅的方案但在实车上能有效避免β估计误差导致的控制量误动作。4. 下层分配层设计四个轮子的扭矩如何分才稳4.1 分配目标函数的构造上层控制器计算出的是整车层面的需求总纵向力F_xd和横摆力矩ΔM_z。下层要回答的是这四个轮子各自的扭矩T_i是多少。这个问题本质是一个带约束的优化问题。先建立执行器到整车力的映射关系。设每个车轮的纵向力为F_xi轮距左右轮距为B则F_x_sum F_xfl F_xfr F_xrl F_xrr M_z_from_torque (B/2) × (F_xfl - F_xfr F_xrl - F_xrr)写成矩阵形式就是v B × u其中v [F_x_sum, M_z]^Tu [F_xfl, F_xfr, F_xrl, F_xrr]^T。B矩阵是轮距和轮胎半径的组合关系。分配问题的目标函数通常包含两项跟踪误差项和调节代价项。跟踪误差项最小化的是“实际能产生的力和力矩”与“需求值”之间的偏差范数调节代价项最小化的是四个轮子的扭矩负荷让每个轮子的利用率尽量均衡。加权最小二乘的形式如下u argmin( ||W_v × (B × u - v_d)||² γ × ||W_u × u||² )其中W_v是力和力矩跟踪的权重矩阵W_u是四个轮子扭矩的惩罚权重矩阵γ是权衡参数。这个形式的好处是物理含义很清楚第一项保证分配的结果尽量满足上层的需求第二项保证四个轮子不要太“拼命”避免某个轮子过载而其他轮子闲着。轮胎负荷率的概念值得多说一句每个轮子的负荷率定义为该轮当前纵向力与当前附着条件下最大可用纵向力之比。当某个轮子的负荷率达到1说明该轮已经饱和再增加扭矩只会打滑。分配算法的核心任务之一就是让四个轮子的负荷率尽量接近避免出现一个轮子饱和、另外几个还有余力的情况。4.2 电机峰值扭矩、路面附着和故障约束怎么叠加约束条件是分配问题里真正体现工程难度的地方。至少四类约束必须在优化求解时考虑进去。电机峰值扭矩约束是硬性的每个电机的扭矩命令不能超过其峰值值而且峰值扭矩在持续运行时会降额热保护所以约束条件里最好根据电机温度动态调整上限。这个约束的实现比较简单直接在优化求解后做一个饱和处理就行但如果饱和发生的频率过高说明上层需求的力矩超出了执行器的能力范围此时需要在上层控制律里做抗积分饱和处理。路面附着约束是分配问题中最关键也最麻烦的一个。每个轮子的纵向力不能超过该轮当前附着条件下能提供的最大纵向力而这个最大值取决于轮胎垂直载荷和路面峰值附着系数F_xi_max μ_i × F_zi。垂直载荷在稳态工况下可以用静态分配近似但在急加速、急刹车和过弯时会发生明显的载荷转移——刹车时前轴载荷增大加速时后轴载荷减小过弯时外侧载荷增大。忽略载荷转移的分配算法在极限工况下几乎必然导致某个轮子打滑。我在实现时用一个简化的载荷转移模型基于纵向加速度和侧向加速度实时修正每个轮子的垂直载荷估计精度够用也避免了复杂的悬架模型。故障约束是分布式驱动平台特有的安全需求。某个电机出现故障后该轮的扭矩上限设为零同时该轮的负荷率权重也设为零让其他三个轮子承担更多的分配任务。这里有一个容易被忽视的细节如果故障的是前轮由于前轴还承担转向功能前轮的机械转向失效和扭矩失效对整车稳定性的影响路径完全不同降级策略也不能一概而论。我在实车测试时遇到过右后电机过温降扭的情况如果分配器不提前把扭矩转移到其他轮子车辆会突然出现一个意外的附加横摆力矩尤其在转弯过程中非常危险。4.3 分配算法的落地选择伪逆法、二次规划还是加权最小二乘优化问题构造出来之后怎么实时求解就成了下一个问题。伪逆法是最快的方案当不考虑约束时上面的加权最小二乘问题有解析解直接计算B矩阵的加权伪逆再乘上需求向量就行。伪逆法的计算量极小在普通MCU上都能轻松跑通但问题是一旦约束条件生效伪逆解可能落在约束之外此时只能做简单的截断处理截断后的结果可能违反力矩跟踪精度。二次规划QP是完整的方案可以同时处理等式约束和不等式约束在约束满足和跟踪精度之间取最优折中。代价是计算量大幅增加需要硬件平台有一定的算力。我在RT系统上用过OSQP求解器问题规模是4个变量、约8个不等式约束单步求解时间在1到2毫秒之间放控制周期10毫秒的系统中是可行的。但要注意的是QP求解器的问题病态处理不如离线优化那么稳定如果约束条件和权重参数设置不当求解器可能出现数值不收敛的情况所以一定要在仿真中遍历各种极端工况确认求解器在所有情况下都能在最大迭代次数内收敛否则就降低迭代精度或者增大迭代上限。最终我采用了带约束的加权最小二乘WLS方案先用解析法求无约束解然后检查是否有约束被违反如果有再用活动集方法Active Set求解带约束的优化问题。这个方案的收敛性比QP稳定计算量又比完整的QP小实车跑下来表现很稳定。还有一个工程细节分配层输出的扭矩命令必须做变化率限制。即使电机本身响应很快如果扭矩命令从100牛米瞬间跳到-100牛米车辆的纵向冲击度会非常剧烈乘员舒适性大打折扣。所以在分配层输出端加一个斜率限制器扭矩变化率一般限制在每个控制周期20到50牛米。这个限制加上之后控制器的名义响应带宽会降低但实车感受和安全性都会好很多。5. 仿真验证到实车试验调试全程的坑和应对5.1 仿真平台的搭建先提醒一句只在线性二自由度模型上验证控制算法是远远不够的最后一定会在实车上翻车。我的做法是直接用CarSim这样高精度车辆动力学软件作为被控对象控制算法在Simulink里实现两者联合仿真。高精度模型的价值在于它包含了悬架运动学、轮胎非线性、载荷转移、执行器延迟等我在控制模型中刻意简化掉的因素。只有在这些因素同时存在的仿真环境里控制算法的鲁棒性才能被真正检验。仿真环境里还应该主动注入两类干扰一是传感器噪声横摆角速度传感器的测量噪声一般是高斯白噪声加少量偏置轮速信号在低速时会因为齿圈分辨率的限制出现量化的跳动二是执行器延迟电机响应虽然是毫秒级的但加上整车控制器通信周期通常是5到10毫秒和电机逆变器内部的转矩上升斜率限制等效延迟可能在20到50毫秒之间。这些干扰注入之后你会发现很多在理想模型里看不出来的问题——比如分配层对轮速噪声敏感把扭矩命令抖得乱七八糟。5.2 典型工况验证双移线、正弦扫频和对开路面仿真和试验工况的选择必须覆盖三类场景常规驾驶工况验证舒适性和基本跟踪精度极限工况验证稳定性控制的有效性还有特殊路面工况验证鲁棒性。双移线工况是最经典也最接近真实危险场景的评价工况之一。它模拟的是驾驶员遇到障碍物后紧急变线再回到原车道的过程。在这个工况里车辆需要在高速条件下连续完成两次快速变线对横摆角速度跟踪精度和质心侧偏角约束的考验都非常大。我的评价指标是三条横摆角速度跟踪的均方根误差RMS误差不超过1.5度/秒质心侧偏角峰值不超过3度干沥青路面以及双移线过程中车辆侧向位移和参考路径的偏差保持在合理范围内。正弦扫频工况是用来评价控制器的频率响应特性的。给方向盘一个从0.3赫兹扫到3赫兹的正弦输入观察横摆角速度的幅值衰减和相位滞后。这个工况能暴露控制器在高频段的动态响应问题如果相位滞后过大说明执行器延迟补偿还不够。对开路面工况是我认为最能体现分布式驱动优势也最能暴露问题的工况。左轮在低附着路面压实的冰雪路面μ约0.2右轮在高附着路面干燥沥青μ约0.8车辆在这种路面上直线加速时左右驱动力的差异会直接产生一个强烈的横摆力矩如果没有稳定性控制车辆会不受控制地向低附着一侧偏转。传统ESC在这种工况下只能靠制动干预效果有限而且车速会明显降低分布式驱动平台则可以直接降低低附着一侧车轮的输出扭矩、同时保持高附着侧正常输出在几乎不损失加速度的情况下保持车辆直线行驶。我实测下来在50%油门开度下车辆侧向位移偏差能控制在0.3米以内而没有控制的情况下这个数字是几米。5.3 实车调试的几个真实教训仿真跑得再漂亮实车总会有几个此前完全没预料到的问题。我这里记几个印象最深的坑。第一个坑是轮速信号低速时的跳变。轮速传感器在车速低于5km/h时由于齿圈分辨率限制输出的转速信号会出现明显的量化和丢失导致滑移率计算值毛刺很大。如果分配层或者观测器直接用这个滑移率作为输入控制量会出现高频抖动。我最初用一阶低通滤波器去做平滑但在急加速工况下低通滤波会引入相位滞后导致滑移率观测滞后于真实值反而激发了更严重的振荡。最后的解决办法是改用变截止频率的滤波低速时降低截止频率多滤波高速时提高截止频率保响应。第二个坑是执行器延迟的补偿不足。电机的响应速度很快但如果整车控制器的CAN通信周期是10毫秒上层控制器和下层分配器的计算又占掉5毫秒一个扭矩命令从发出到实际作用到车轮上延迟可能达到25到30毫秒。在中等频率的正弦工况下30毫秒延迟对应大约29度的相位滞后这个滞后对横摆角速度跟踪的影响很大。我试过两种补偿方案一种是Smith预估器用车辆模型预测延迟期间的状态变化另一种更简单实用的是在前向通路加一个相位超前滤波器根据延迟时间α补偿相位。在实车上相位超前方案更容易调但要对滤波后的控制量做饱和限制防止高频放大过头。第三个坑是标定顺序。我第一轮做调试时直接先调下层分配的权重再调上层的控制参数结果车辆表现不稳定时很难定位问题出在哪一层。正确顺序应该是首先在低速、低负荷工况下验证上层控制器的横摆角速度跟踪把下层分配简化为平均分配然后固定上层参数在同样的工况下调整下层权重确认分配精度最后才是在极限工况下做联合调参。每一步验证通过后再进入下一步出了问题能快速定位。这个流程虽然慢但调试效率反而是最高的。第四个坑是低附着路面标定时的数据异常。冰雪路面上轮胎的附着椭圆和仿真模型里的参数差很多尤其是侧向力和纵向力的耦合关系比模型里描述的要复杂得多。如果按仿真里的附着约束去分配扭矩实车打滑的概率会明显增加。我的处理是为下层分配的摩擦约束留一个安全裕量比如仿真里计算出的最大附着纵向力为1000牛实车上只允许分配到不超过700牛。这个裕量可以在不同路面上通过实测调整但建议至少保留20%的余量。5.4 扭矩分配系统的安全冗余与降级策略最后单独说一段安全冗余。分布式驱动平台最危险的情况不是某个电机故障本身而是故障发生后整个控制系统的误动作。我的做法是在分配层之上加了一个安全监控逻辑独立于控制算法运行实时监测四个轮子的扭矩命令和实际反馈扭矩、电机温度、母线电压等状态。一旦检测到某个电机扭矩响应异常或者过温降扭安全监控立刻把故障轮的扭矩余量置零同时触发降级策略。降级策略分两级。一级降级是扭矩重分配当单个轮子失效时重新求解分配优化问题让剩余三个轮子分担总需求二级降级是能力降低如果两个轮子同时失效比如同一侧的电机都出问题此时已经无法产生两侧驱动力差来维持横摆稳定性上层控制器会退出DYC模式只维持基本的纵向驱动同时点亮仪表报警提示驾驶员谨慎驾驶。这些逻辑在实车调试中必须专门做故障注入测试人为地让某个电机扭矩输出突然清零或者突变为异常值验证车辆在高速转弯时会不会瞬间失稳。我做完这个测试后的体会是故障切换的时间比预想的更重要——从检测到故障到完成扭矩重分配整个链路如果在50毫秒以内完成车辆的状态偏差可以控制在可接受的范围内如果超过100毫秒危险性会显著上升。所以故障检测不能依赖太复杂的算法直接比较指令扭矩和反馈扭矩是最快的方式。做完整套系统我个人的体会是分层式控制策略最大的价值不是让性能上限提高了多少而是让一个复杂到几乎无法调校的系统变成两个可以分别验证、分别调校、分别复用的模块。上层算法在换车辆平台时几乎不需要改动下层分配器在换执行器时只需修改约束条件。这种设计上的解耦才是它在工程上被广泛采用的根本原因。如果你正在做类似的工作建议一开始就按这个思路搭好框架别贪图一体化控制的理论优雅——控制系统的价值在于稳定可靠地跑在车上而不是在论文里完美。
