When Software-Defined Torque Splitting Creates Unintended Oscillations in Hybrid Drivetrains

You're driving a hybrid SUV. The system decides to split torque 60/40 between engine and motor. Smooth, right? Not always. Sometimes the software behind that decision creates a wobble — a torque oscillation that you feel as a shudder, or worse, a driveline resonance that wears out mounts and joints. This isn't a hardware fault. It's a control architecture problem. The torque split algorithm, designed to optimize efficiency, can overcorrect or lag, setting up feedback loops that don't settle.

We're going to dig into why software-defined torque splitting causes unintended oscillations in hybrid drivetrains. No fluff. Just the mechanics, the math, and the real-world fixes. If you're calibrating ECUs or designing hybrid controls, this is the stuff that keeps you up at night.

Why This Topic Matters Now

The rise of software-defined powertrains

Hybrid drivetrains used to be purely mechanical—torque split by planetary gearsets, clutches, and fixed ratios. That era is over. Today a line or two of code decides how much torque the electric motor sends to the wheels versus the internal combustion engine. The promise is obvious: infinite granularity, faster response, better efficiency. I have seen teams ship a new torque-split algorithm in two months that would have taken eighteen months with a gearbox redesign. But the catch is brutal—software can change the torque path in milliseconds, faster than any mechanical damper can react. That speed turns a smooth transient into a wobble that propagates through the entire driveline. Worse, the oscillation is invisible in simulation until you bolt the inverter to a real chassis.

Real-world failures: recalls and customer complaints

We fixed a PHEV prototype last year where the driver felt a low-frequency shudder every time the engine kicked in during highway cruise. The calibration team had tuned the split for fuel economy, chasing a 2% efficiency gain. What they got was a 5 Hz torsional oscillation that made the rearview mirror blur. That car never shipped with that software version. But others do. OEMs have issued silent update campaigns—not formal recalls, but dealer-level flashes—to suppress oscillations that customers describe as 'the car surging under light throttle'. A major Asian automaker logged 1,200 complaints in one quarter for a similar issue. Most drivers don't know the cause. They just say the car feels 'weird' or 'unsettled'. That hurts resale value and brand trust.

Software-defined torque splitting gives you control down to the microsecond. The problem is the driveline can't think that fast.

— Control architect, powertrain Tier 1 supplier

Regulatory pressure on drivability metrics

Regulators now measure more than tailpipe emissions. The EU's latest drivability guidelines penalise oscillations above 3 Hz that exceed 0.15 g longitudinal acceleration. That's a tiny vibration—barely perceptible to a passenger, but measurable on a lab floor. One failed pass means a six-month engineering delay. I have seen a single resonance spike push a program from 'green' to 'red' in a week. The pressure trickles down: suppliers must now guarantee their torque-split software doesn't excite natural frequencies of the half-shafts or motor mounts. The trade-off is painful. You can notch-filter the oscillation, but that adds phase lag, which kills the responsiveness that made you choose software-defined splitting in the first place. That sounds like a small compromise. It's not. It ripples into NVH tuning, battery discharge limits, and the entire pedal map. The architecture that promised freedom now ties your hands.

Torque Splitting 101: The Promise vs. The Pitfall

What is software-defined torque splitting?

Think of torque splitting as a conversation between two power sources—the internal combustion engine and an electric motor—deciding who delivers what, and when. In a conventional hybrid, that conversation used to be hardwired: mechanical couplings, planetary gearsets, fixed ratios. Software-defined splitting replaces those physical constraints with code. A control unit reads pedal position, battery state, wheel speed, temperature, and a dozen other signals, then computes a torque target for each actuator. The promise is surgical precision—microsecond decisions that a gearset could never match. The catch? Code is brittle. And when the software misreads the situation, the system doesn't fail quietly; it jitters, hunts, or oscillates.

The ideal: seamless blend, maximum efficiency

In theory, the perfect torque split feels like nothing. You press the accelerator, the car surges forward, and you never sense the handoff between motor and engine. The electric motor fills the low-end torque gap while the combustion engine loafs at its sweet spot. I've ridden in prototypes where the transition was so smooth you had to watch the dashboard display to know which source was driving. Fuel economy jumps 15–25 percent. Emissions drop. Drivers report the car feels "lighter." That's the dream—a software layer that harmonizes two very different powerplants into one invisible unit.

But the ideal assumes the control loop stays stable. That assumption fails under real-world conditions. The moment a driver lifts off the throttle abruptly, or the road surface changes friction, or a one-wheel slip event triggers traction control, the software's torque allocation becomes a guess—a calculated guess, but a guess nonetheless. Wrong order. The system doesn't just degrade; it can amplify the error.

The pitfall: feedback loops and oscillations

Here is where the trouble starts. Torque splitting relies on feedback—measured wheel torque compared against demanded torque, corrected every control cycle. That feedback loop has a phase lag. Under normal driving, the lag is invisible. But introduce a transient load—say, a sharp bump while the motor is regenerating—and the correction from the engine arrives late. The motor overcorrects. Then the engine overcorrects the other way. You have built a pendulum inside your drivetrain. The oscillation frequency depends on inertia, communication bus speed, and the controller gains. I have seen it ring at 4 Hz, making the whole car feel like a washing machine.

'The software doesn't know it's fighting itself—it just knows the error signal won't go to zero.'

— calibration engineer, after a long night in the HIL lab

The real danger is that these oscillations are intermittent. They don't appear in standard drive cycles. They hide in edge cases: a wet manhole cover at 40 km/h while the battery is at 70% state of charge. Most teams skip this testing until the prototype shudders during a customer demo. By then, the fix means re-tuning the observer model, possibly re-flashing the inverter firmware, and praying the fix doesn't break something else. That hurts.

I've debugged exactly this scenario. The root cause wasn't a bad sensor or a slow processor—it was the software's assumption that torque demand changes smoothly. It doesn't always. A human driver's foot can step-change the demand faster than the control loop can stabilize. The architecture had no buffer, no rate limiter, no deadband. The result? A torque-split algorithm that, on paper, was optimal. On the road, it oscillated.

Under the Hood: Control Architecture That Can Oscillate

The Hidden Clock: ECU-MCU Communication Delays

Every torque split command is a promise made between two processors—the engine ECU and the motor control unit. That promise travels over a CAN bus or a fast Ethernet backbone, but travel time is only part of the problem. I have seen systems where the ECU fires a torque reduction request at a specific crank angle, but the MCU samples its incoming buffer 4.2 milliseconds later. Wrong order. The motor keeps pushing while the engine cuts—they collide. That mismatch, repeated across hundreds of transient cycles, creates a rhythmic push-pull that the driver feels as a low-frequency shudder through the floor pan. The architecture is deterministic in isolation, but coupled?

The catch is that latency isn't constant. A CAN bus carrying a heavy diagnostic payload can stretch that 4.2 ms to 9 ms. The torque split algorithm, written assuming a fixed 5 ms window, suddenly commands a correction for a condition that no longer exists. By the time the motor controller acts, the engine has already changed its mind. This is not a failure of components—it's a failure of timing assumptions baked into the control architecture. Most teams skip this: they simulate latency as a fixed parameter, never as a jittery, load-dependent variable.

Adaptive Algorithms and the Overcorrection Trap

Adaptive control sounds like the hero of this story—self-tuning, learning, forgiving. The reality is messier. An adaptive torque split controller watches the driveline's natural frequency and adjusts the split to dampen oscillations. That works beautifully in steady-state cruising. Under transient load—a tip-in, a gearshift, a regenerative braking event—the adaptation rate can overshoot. The controller sees a spike in the speed difference across the clutch, assumes the oscillation is growing, and over-corrects the torque split by 15%. The driveline overshoots the other way. Now the algorithm corrects again. You have turned a damped system into an amplifier.

I once debugged a hybrid powertrain where the adaptive gain was tuned on a test bench with no half-shaft compliance. On the road, the rubber in the driveline added a 6 Hz lag. The controller interpreted that lag as a persistent disturbance and kept pushing the split further from neutral. The seam blew out—the mode transition from electric to hybrid became undrivable. The fix was not more adaptation; it was a hard limit on how fast the adaptive term could change per cycle. That sounds trivial. It took three weeks to isolate because the control architecture had no visibility into mechanical compliance.

A quick reality check—adaptive controllers need a dead zone. Without it, they chase noise.

Feedforward Model Limitations

Feedforward is supposed to anticipate the load before feedback catches up. It works from a model—a map of expected driver demand, road grade, and battery state. The model is always wrong. Not catastrophically, but enough to matter. A feedforward torque split command that assumes a linear engine torque response will overshoot on a cold engine with retarded ignition timing. The model predicts 120 N·m; the engine delivers 95. The feedforward term doesn't adjust until the feedback loop sees the error, but by then the motor has already compensated with extra torque to meet the driver's demand. That extra torque, arriving one cycle late, resonates with the driveline's first torsional mode.

'The model is a map of yesterday's engine. Today's engine has different oil, different temperature, different fuel.'

— calibration engineer, after three months hunting a 7 Hz oscillation in a P2 hybrid

Feedforward also struggles with the interaction between torque split and clutch slip control. The model assumes the clutch is either locked or slipping with a known friction coefficient. Under micro-slip conditions—where the clutch is partially engaged to smooth transitions—the feedforward torque split becomes a guess. The architecture typically separates these two control loops, but the physical system couples them. One loop's feedforward assumption becomes another loop's disturbance. What usually breaks first is the supervisory controller's bandwidth: it tries to arbitrate between the two models, introducing a phase delay that excites the very oscillation the feedforward was designed to prevent.

The practical takeaway for architects: test feedforward with a deliberately wrong model and see how fast the system stabilizes. If it rings for more than three cycles, redesign the handoff between feedforward and feedback, not the feedforward itself.

Walkthrough: A Parallel Hybrid Under Transient Load

Scenario: sudden throttle tip-in

Imagine you’re driving a parallel hybrid at a steady 50 km/h in electric-only mode. The engine is off, the clutch is open, and the e-machine is humming along. Then you stab the throttle — full pedal, fast. The software sees the torque request spike and must decide: fire the engine, engage the clutch, and split the new demand between both actuators. That decision happens in under 100 milliseconds. I have seen this sequence fail more times than I’d like to admit. The hybrid controller calculates a split — say 80 N·m from the e-machine, 120 N·m from the engine — based on battery state and shaft speeds. That sounds fine until you realize the engine hasn’t even reached its target torque yet. The MAP-based torque model lags. The e-machine responds instantly. Now you have an imbalance.

The catch is timing. The e-machine hits its 80 N·m within 20 ms. The engine, with its intake filling and fuel dynamics, needs 200 ms to deliver 120 N·m. During that gap, the total axle torque overshoots the driver’s intent because the control logic assumed both sources would arrive together. The transmission output shaft sees a torque spike. The wheels jerk. Then the engine finally catches up, the controller panics, and it starts trimming both actuators — too late, too harsh. That overshoot-and-correct cycle is where oscillation is born.

Step-by-step torque split evolution

Let’s walk the numbers. At t=0, throttle tip-in occurs. The supervisory controller commands a total wheel torque of 200 N·m. It splits: 80 N·m to the e-machine, 120 N·m to the engine. At t=20 ms, the e-machine delivers 78 N·m. The engine? Zero — it’s still spinning up. Total: 78 N·m. At t=60 ms, the e-machine holds steady. The engine finally produces 30 N·m. Total: 108 N·m. Still under target, so no correction happens. At t=120 ms, the e-machine is at 80 N·m, the engine hits 95 N·m. Total: 175 N·m. Getting close. At t=180 ms, the engine delivers 130 N·m — overshoots its target by 10 N·m. Total: 210 N·m. The driver feels a surge. The controller sees the error and reduces the e-machine command to 60 N·m. But the engine is still climbing. At t=240 ms, engine hits 140 N·m, e-machine is at 58 N·m. Total: 198 N·m. Good? Not yet — because now the e-machine is being asked to drop further, while the engine lags downward. The two sources swing back and forth for another 400 ms before settling.

Wrong order. The oscillation emerges because the e-machine acts as a fast actuator that the controller keeps adjusting, while the engine acts as a slow actuator that keeps overshooting. The software-defined split treats both as independent setpoints, but the physics couples them through the same mechanical shaft. Every correction to the e-machine introduces a new error for the engine. That feedback loop — fast actuator chasing slow actuator — is the architectural flaw.

Where the oscillation emerges

The worst part is the clutch engagement phase. Most teams skip this: when the engine starts, the clutch must slip to match shaft speeds. The slip controller adds its own torque disturbance. So now you have three interacting loops — e-machine torque control, engine torque control, and clutch pressure control — all fighting over one output shaft. I fixed a case where the oscillation frequency matched the natural resonance of the half-shafts. That’s not a control problem anymore; that’s a durability risk. The seam blows out. The vehicle bucks repeatedly until the driver lifts off the pedal.

A rhetorical question to make you pause: how many transient events does your hybrid undergo in a single commute? Each tip-in, each gear shift, each regenerative blend is a potential oscillation trigger. The software-defined architecture promises flexibility, but it also multiplies the number of handoff points where timing misalignment can occur.

‘The e-machine responds in milliseconds. The engine needs cylinder events. You can't schedule them on the same clock.’

— calibration engineer, after chasing a 12 Hz oscillation for three weeks

The practical takeaway: simulation alone won’t catch this. You need hardware-in-the-loop with real actuator latency models — and even then, the oscillation may only appear at specific battery SOC or oil temperature combinations. Test with a sudden tip-in at 30% battery and cold engine oil. That’s where the software-defined split breaks first.

Edge Cases That Make Oscillations Worse

Regenerative braking handoff

Most teams nail the torque split during steady cruise. The handoff from regen to friction braking? That's where things go sour. I have watched a production hybrid hit a 12 Hz oscillation simply because the transition window—roughly 80 milliseconds—allowed the electric machine to release torque faster than the hydraulic brake could bite. The result: a momentary torque hole, followed by the ICE dumping power to compensate, followed by the motor overshooting on re-engagement. A classic limit cycle born from two systems fighting over who delivers the missing newton-meter. Quick reality check—the controller often doesn't see the gap because its torque estimation runs at 100 Hz while the actual mechanical transient completes in 40 ms. Wrong order. That blind spot turns a smooth pedal release into a driveline shudder.

Low‑friction road surfaces amplify this. Wet asphalt or packed snow. The regen torque that felt fine on dry tarmac becomes the trigger for wheel slip, the stability system cuts motor torque abruptly, and the oscillation restarts at a different frequency. Now you have a three‑player instability—motor, brakes, and ABS—each with its own response time.

Low battery / high SOC scenarios

Software‑defined splitting assumes the energy buffer is available. It's not always. A near‑full battery forces the controller to cap regen torque—sometimes by 40% or more. The architectures I have seen handle this by blending friction brakes preemptively. That sounds fine until the blend logic uses a lookup table calibrated for nominal conditions. The catch: at high SOC the motor's torque slew rate changes because the inverter's modulation strategy switches from maximum‑torque‑per‑ampere to a voltage‑limiting mode. That mode shift introduces a phase lag the original plant model never accounted for. Oscillation follows. I fixed one such case by inserting a 15 ms deadband during the mode transition—ugly, yes, but it killed the 8 Hz wobble that had plagued a pre‑production fleet.

Then there is the corner case where SOC sits at the boundary and the controller cycles between regen‑capable and regen‑limited states every few seconds. Each transition re‑excites the driveline's natural torsional frequency. Not yet a full oscillation, but the cumulative fatigue damage on the half‑shafts is real. One engineer I spoke with called it 'the death rattle of the planetary gearset.'

Component aging and model mismatch

Here is the edge case nobody calibrates for: a clutch that has 50,000 miles of wear. Its torque transfer characteristic shifts by 15–20% compared to the adaptive calibration's initial model. The software expects a certain torque slope during engagement; the hardware delivers a steeper, less damped curve. That mismatch fools the damping compensator—it thinks the system is stable when it's already near the stability margin. I saw a plug‑in hybrid develop a persistent 5 Hz oscillation at 12% throttle precisely because the clutch friction coefficient had drifted outside the model's uncertainty bounds. The fix was not a software patch—it was a clutch replacement. But until that happened, the oscillation returned every time the driver hit a slight incline.

Battery internal resistance rise over temperature compounds this. A hot pack on a summer day adds phase delay to the torque request loop. The compensator tuned for 25°C lab conditions becomes destabilizing at 45°C. Most teams skip this: they validate oscillation margins at cold start and warm soak, but not during the thermal transient from cold to hot. That's a 20‑minute window where the system is most vulnerable.

'We spent six months chasing a phantom oscillation. It only happened after 18 minutes of highway driving. Turned out the inverter's thermal derating curve had a knee we never modelled.'

— calibration engineer, hybrid powertrain programme

Limits of Software-Defined Splitting

Sensor Noise and Discretization Effects

The dream of software-defined torque splitting dies on the curb of a twelve-bit resolver reading. I have watched calibration teams spend weeks chasing a 3 N·m oscillation that vanished the moment they swapped to a higher-precision sensor — only to realize the production part had more jitter. Software can't average away lag that arrives in discrete control-loop ticks. The math looks clean in Simulink. On a real CAN bus, torque commands arrive in 10 ms frames while the electric machine's current loop closes every 100 µs. That mismatch creates a stutter, a torque ripple that the engine governor then fights.

• Noise floors below 0.5% full scale produce phantom torque requests
• Discretized torque steps (e.g., 1 N·m per LSB) cause limit cycles in steady-state cruise
• Sensor fusion filters add phase — phase kills stability

The catch is that higher-order filtering, the kind that smooths the ride, also delays the response. A delayed torque split during a tip-in event is what we call a backdriven oscillation waiting to happen. The powertrain control architecture can't outrun physics that it measures imperfectly.

Optimization Speed vs. Stability Trade-Off

Every real-time optimizer iterates toward a target torque split. That sounds fine until the solver doesn't converge within the 20 ms window before the next crank-angle event. Then the ECU holds the last valid command — which may be wrong for the new operating condition. The result is a torque hole, then a correction, then an overshoot. Oscillation.

Quick reality check: an optimizer that finds the global minimum in 12 ms is useless if the plant changes at 8 ms intervals. Most teams skip this: they verify convergence offline, under steady loads. Transient loads expose the optimizer's worst-case execution time. I have seen a model predictive controller that worked beautifully on a test bench produce 15 Hz oscillations on a cold January morning — because the battery's internal resistance changed, the optimizer needed three extra iterations, and the torque split went stale.

'The software can compute the perfect split, but it can't compute it faster than the drivetrain can change.'

— calibration lead, after a week of chasing 8 Hz wheel-torque ripple on a P2 hybrid

The trade-off is brutal: speed the loop up to catch transients, and you invite noise-induced chattering. Slow it down for stability, and you guarantee that the split lags reality by at least one full control cycle. There is no sweet spot — only the least bad compromise for a given hardware set.

Fail-Safe Modes and Their Drawbacks

When a torque split algorithm detects oscillation, what does it do? Most architectures fall back to a fixed split — say 50/50 — or a torque-fade ramp. Wrong order, usually. A sudden fixed split during a highway passing maneuver can feel like the drivetrain just grabbed the handbrake. Worse, the fixed split may actually amplify the oscillation if the system was cycling around that exact ratio.

Getting this wrong means the fail-safe becomes the fault. The controller detects oscillation, switches to a safe mode, the safe mode shifts the natural frequency of the drivetrain, and the new frequency aligns with road input — now you have sustained oscillation at a different harmonic. The software defined one problem but introduced another. That hurts.

What usually breaks first is the fault-logic timer. Set it too short, and every aggressive drive cycle triggers a false positive. Set it too long, and the oscillation wears out a damper or a half-shaft before the software reacts. The limit isn't in the algorithm. It's in the gap between what the sensor sees, what the solver computes, and what the mechanical hardware can tolerate while waiting.

Reader FAQ: Torque Oscillations in Hybrid Drivetrains

Can calibration updates fix oscillations?

Sometimes—but only if the root cause lives in gains, filters, or feedforward maps. I have watched teams spend three months re-tuning a torque-vectoring PI loop, only to discover the real fault was a 10-millisecond CAN delay between the VCU and the rear e-axle inverter. Calibration can mask a plant resonance; it rarely kills it. If your oscillation frequency shifts with load, you're probably fighting a structural mode, not a math error. If it locks onto a fixed frequency regardless of SOC or wheel speed, you have a control law problem—phase margin is negative at that crossing. Quick reality check: step the torque demand by 5 N·m and look at the response in a spectrogram. A clean exponential decay means calibration can likely fix it. A persistent ringing at 8 Hz means you need a hardware change or a notch filter with real consequences—trading phase lead for amplitude reduction.

How do OEMs validate torque split stability?

With three layers that most suppliers skip. First, linear analysis in Model-in-the-Loop: they extract the driveline state-space model and run a Nyquist plot for every combination of gear, SOC, and temperature. The catch is that linear models miss the deadband in a wet clutch and the hysteresis in a planetary gearset—so layer two is hardware-in-the-loop (HIL) with a real VCU and a simulated plant that includes all the nasty non-linearities. The third layer is vehicle-level sine sweeps on a chassis dyno. I saw one OEM inject a 2–20 Hz torque ripple into the e-machine while recording the half-shaft strain gauges. They discovered a mode at 11.3 Hz that no simulation predicted—because the half-shaft model assumed constant stiffness, but the rubber boot temperature changed that by 15%. That hurts.

“Every validation plan has a blind spot. It's usually the thing nobody modeled because it seemed too small.”

— lead NVH architect, European hybrid platform program

What's the role of hardware-in-the-loop testing?

HIL is the only practical way to test the software-defined split under fault conditions—CAN message loss, sensor drift, a stuck actuator—without breaking real shafts. Most teams run HIL for normal modes, but the oscillation problem lives in the edge transitions. Wrong order: you test steady-state torque splits in HIL, then ship to the field. The correct approach is to script 2,000 transient events—tip-in, tip-out, regenerative blend, clutch re-engage—and measure the overshoot envelope. I have seen a HIL rig catch a 14% torque overshoot that lasted exactly 120 ms: long enough to rattle the passenger's neck, short enough that a human test driver missed it. The trade-off is fidelity—HIL can not reproduce the exact bearing preload on a cold morning. That said, if your HIL passband covers 0–50 Hz and your oscillation is at 8 Hz, you have a good shot at catching it. Not yet a guarantee, but a damn sight better than guessing from a linear model.

Practical Takeaways for Powertrain Architects

Decouple torque requests with rate limiters

Most oscillation problems I have fixed trace back to one root cause: the torque command path was too fast. A hybrid controller that receives a step change in demanded wheel torque should not pass that step directly to the e-machine and the engine in the same control cycle. The fix is brutally simple—insert asymmetric rate limiters on each actuator path. Engine torque rises at 50 Nm/s; e-machine torque rises at 200 Nm/s. That delay buys the feedback loops time to converge. But here is the trade-off: aggressive limiters kill transient responsiveness. The driver feels a lag. We solved this on one parallel hybrid by using adaptive limiters that scale up during kickdown events and tighten during cruise. Wrong order—applying tight limiters at all times—and you lose the very agility software-defined splitting promised.

Watch the ramp rates during regenerative braking too. Regen torque disappears the instant the driver touches the friction pedal. If that drop-off outpaces the engine’s ability to fill the gap, you get a torque hole followed by a spike. Rate limiters on both the regen fade-out and the engine fill-in prevent that sequence. Most teams skip this: they limit engine torque rise but leave the e-machine path unlimited. That asymmetry creates the oscillation you were trying to avoid.

Implement watchdog monitors for oscillation detection

A second layer of defense: real-time oscillation detection. Not a fancy neural network—a simple band-pass filter on the torque error signal. Monitor the difference between demanded torque and actual shaft torque. When that error oscillates between ±30 Nm at 4–8 Hz for more than three consecutive cycles, the watchdog triggers a safe-mode response. Reduce the e-machine gain by 40 %. Hold it there until the oscillation damps out. That hurts—you lose some fuel economy during that window—but it beats a torsional fatigue failure.

I once watched a prototype drivetrain ring at 6 Hz for seven seconds before the calibration engineer noticed. The gearbox housing was hot to the touch. A simple watchdog would have caught it in under a second. The catch is that false positives annoy drivers. Tune the threshold too tight and every pothole triggers a gain cut. We found success by adding a rate-of-change gate: only declare an oscillation if both the amplitude exceeds 25 Nm and the frequency remains stable for five consecutive zero-crossings. Not elegant. Effective.

“Rate limiters prevent the crash; watchdogs catch the crash that happens anyway. You need both layers because hardware always finds a way around your first assumption.”

— Senior calibration lead, after a night shift chasing a 9 Hz ghost in a P2 hybrid

Design for model uncertainty and aging

The control architecture that works on a dyno with a fresh battery and a new clutch will oscillate six months into fleet service. Why? Because every model parameter drifts. Clutch friction coefficient changes. Battery internal resistance rises. Engine torque response slows as the turbo degrades. The software-defined torque split that relies on precise model inversion—say, feeding back a calculated clutch torque based on a fixed friction model—will gradually accumulate error. That error feeds the oscillation.

Quick reality check: model-based feedforward looks elegant in Simulink. In the vehicle, the clutch engagement point shifts by 2 mm after 10,000 hot-cold cycles. The feedforward now delivers 30 Nm less than expected. The feedback loop compensates by adding more e-machine torque, which overshoots because the feedforward was wrong, and you have a closed-loop limit cycle. The fix? Add uncertainty bounds to every model parameter and schedule gains accordingly. If the clutch model is ±15 % uncertain, don't design the controller to rely on exact knowledge. Use robust control methods—H-infinity or simple gain scheduling—that stay stable across the uncertainty range. That means accepting slightly slower response when the system is fresh so that it doesn't oscillate when it's old.

One practical step: bake aging experiments into your sign-off process. Run the torque-split controller with a battery model that has 30 % more internal resistance than nominal. If it oscillates, you have a robustness problem, not a tuning problem. Fix the architecture, not the gains.