⚙️ The Core Concept — Torque as Currency
Inside the ECU, torque is the universal language.
Every subsystem — engine, transmission, traction control, A/C, even cruise control — speaks in torque requests and torque permissions, not raw throttle or boost.
You can think of torque like a digital currency the ECU uses to negotiate power:
-
The Driver Wish module says, “I want 500 Nm.”
-
The Traction Control module says, “That’s too much, I allow only 300 Nm.”
-
The Engine Protection module says, “Cylinder pressure is high, cap it at 450 Nm.”
-
The A/C compressor requests “-20 Nm offset for accessory load.”
The ECU takes all of these votes and decides on a final delivered torque — called M_mot in Bosch terminology — which becomes the command target for air, fuel, and ignition.
🕹️ The Real-Time Debate Loop
This negotiation happens every 10 ms (100 Hz) in the torque-based main loop:
-
Read all torque demands from subsystems (CAN, internal modules).
-
Normalize them to the same “engine-torque” base using the current gear ratio.
-
Apply multipliers from protections (component, knock, EGT, catalyst).
-
Compute
M_des(desired torque) andM_act(actual torque). -
Adjust throttle, boost, spark, and injection to close the gap.
If one module yells “limit!” mid-cycle (like ESP or TCU), the arbitration instantly cuts air or spark — within a few milliseconds.
Where You See It in Maps
This “parliament” or torque arbitration loop may show up as:
-
MDVERB— torque demand derivation from pedal -
MDGRS— coordination / arbitration -
MDKOL,MDFUE,MDGRSA,MDGRMOT— component subsystems -
MOTR,MOLIM— gearbox and limiter integration -
MDIAG/MDDYN— runtime torque monitoring and filtering
Many of these contain “max permissible torque,” “filtered torque,” and “actual torque” maps TunedMercedes and The Drivers Mark tunes— those are effectively each member’s voting limits.
Arbitration Logic (The Actual Parliament Vote)
Simplified pseudo code:
MDGRS_ArbitrateTorque()
// Step 1: Gather all requests
M_drv = M_req_ped;
M_tcu = M_req_tcu;
M_esp = M_req_esp;
M_prot = M_lim_prot;
M_idle = M_req_idle;
M_aux = M_req_aux;
// Step 2: Apply hard limits first
M_lim_total = min(M_prot, M_cat, M_safety);
// Step 3: Arbitration – who wins
M_req_final = min(M_drv, M_tcu, M_esp, M_lim_total);
// Step 4: Add offsets (idle, aux)
M_req_final += (M_idle + M_aux);
// Step 5: Sanity-check & rate-limit
M_req_final = clamp(M_req_final, M_min, M_max);
M_req_final = rate_limit(M_req_final, dM_dt_max);
// Step 6: Output to air/fuel path
M_desired = M_req_final;
Key Functions Called
| Function | Purpose |
| ————————- | —————————————– |
| `MDGRS_GetRequests()` | Reads all subsystem torque requests |
| `MDGRS_MinLimit()` | Finds the lowest safe torque request |
| `MDGRS_AddOffsets()` | Adds accessory and idle compensation |
| `MDGRS_Filter()` | Smooths transitions between torque states |
| `MDGRS_OutputToAirpath()` | Passes target to `MDKOL` (air model) |

