The engine torque produced by combustion is calculated by the ECU using modelled algorithms and is referred to as Ideal Engine Torque. The moving parts inside the engine assembly create drag and therefore limit the torque available. The estimate of torque required to overcome this drag effect is called Frictional Loss.
The ECU also produces a calculation for Driver Demand Torque using a weighted mathematic model from multiple inputs. This is explained more in the Driver Demand Torque topic below.
The Engine Torque and Driver Demand Torque calculations have no correlation and operate independently. Both calculations will merge and track very closely, however the accuracy of these calculations will depend on the accuracy of the engine setup and mapping: i.e Injector Data, Fuel Density, VE Model etc. The ECU calculates Torque in the units of Newton-metre (Nm).
The Engine Torque and Driver Demand Torque data can be transmitted over the CAN bus in some OEM applications, which is another reason the accuracy of the calculation is important.
The Primary data source for calculating Engine Torque is the Final Air Mass (g/s) entering the engine. The Final Air Mass will be heavily influenced by VE table and Injector charachterisation so this data must be as accurate as possible to ensure the accuracy of the Engine Torque calculation.
Ideal Engine Torque is caclulated using the following inputs:
Uncorrected Engine Torque is calculated by accounting for the frictional loss of the engine. It is named “uncorrected” because other inputs can further change the Engine Torque. An Engine Torque Correction factor can also be applied and is described further down the page.
Final Engine Torque accounts for the additional inputs that can reduce or increase Engine Torque such as:
The Driver Demand Torque is the torque requested by the driver, primarily as a function of engine speed and pedal position to give a requested throttle area. We know through mathematical modeling that from throttle area we can calculate airflow and from airflow we can calculate torque.
Apart from some specific exceptions, the engine torque must be controlled by the driver. Some exceptions include: downshifts, traction control (VDC event), pit lane speed limiter and cruise control.
The driver only has control of torque by using the pedal, but other factors get included into the mathematical model to give a final Driver Demand Torque. These include:
All those parameters get included in a complex mathematical model which generates a runtime called Driver Demand Torque Ideal.
Accounting for frictional loss of the engine the final Driver Demand Torque can be expressed as:
It is worth mentioning the Boost Target and how the Boost Target table should be setup to help generate a more accurate Driver Demand Torque. The Y-Axis or load axis should be set to “Throttle Area Demand - Pedal” and not the raw Pedal Position Sensor.
Nissan GT-R R35 Boost Target table.
Engine Torque and Driver Demand Torque data is available in the Runtime Values(F3) > Torque Data tab.
This table calibrates the torque reduction % per degree. When a torque request is applied the ECU will calculate how much retard is required to achieve this torque request.
Typical Torque Reduction Ignition Retard Gain Table
In a wide variety of applications, the default table shown above will give very useable results.
This table calibrates the torque reduction % per %cut. When a torque request is applied the ECU will calculate how much cut is required to achieve this torque request.
Typical Torque Reduction Cut Gain Table
Firstly, the Engine Torque values must be validated on a dyno to ensure the ECU Torque Calculation (Engine Torque Ideal, Engine Torque), are close to the values being produced on the dyno.
Note: If using a dyno where wheel power is reducing values, then this error must be factored in.
A properly tuned engine, with no error in the basic fuel model is the first step. Having proper injector data, engine displacement, fuel type/stoich, and a tuned VE table will already calculate accurate engine torque.
If engine torque is not calculating accurately, you can correct the torque calculation via the Engine Torque Correction Table.
Tip: A value of 1.0 = no correction.
Driver Demand channel is used in some OEM applications, but also can be used as a channel in the ECU to feed forward the driver tour requests. The Driver Demand can be corrected via the Driver Demand Torque Correction Table.
Tip: A value of 1.0 = no correction.
During engine cranking (Engine Speed < Crank Exit RPM setting) this table is used to generate a Throttle Area Demand ,overriding any request from the pedal. The ECU then uses the Throttle Body Area table to convert Throttle Area into the DBW Servo Position target.
See the DBW Torque Management help topic for more information on the process of converting Pedal Position to Throttle Area to DBW Servo target.
This table is available from the Engine Functions -> Torque Management -> Cranking Throttle Area Demand menu.
This is available from the runtime (F3) menu , Torque or DBW 1/2 tab.
Torque Information over the CAN bus can be modified.
This can change the behavior of the Gearshift along with clutch pressure in gear.
If there is excessive slip typically the Torque reported should be increased.
If the gearshift feel is too sharp and aggressive the Torque reported should be reduced.
The table applies an offset.
This effects:
Engine Torque Demand
Engine Torque
Table range is +/- 500Nm
The above example shows a typical setting.
The increase in Torque reported over the CAN bus will have the effect of sharpening the transmission shifting and clutch lockup.
It is important to note that directly programming the TCM through a third party flashing tool is advised over using the ECU to offset the torque reported.
The ECU uses a torque based system for DBW throttle plate control, which means all torque requests are done using Throttle Area, not Throttle Position.
There is no direct DBW Servo Position “Target” table, but instead a Throttle Area Demand table (more information below). So the throttle area directly relates to the engine torque which is why this function is under Torque Management.
For Engine torque calculations and during Torque limiting events the ECU converts the engines throttle area into engine airflow (g/s), then into engine torque (Nm) using mathematical models. This model allows the ECU to use this calculation in either direction:
Throttle Area data is available either in the Runtime menu(F3) -> Torque or DBW 1/2 tab. The “Throttle Area Demand Status” indicates the current throttle area in use.
How does the ECU then convert throttle area to DBW servo position target?
This is done using the “Throttle Body Area Table " which translates Throttle Area into Servo Position. The ECU uses this as a lookup table, converting any requested Throttle Area into a Servo Position target for the DBW system. See the Throttle Body Area help topic for more information.
To understand the process of converting Pedal Position into Throttle Area, carefully read this section.
See the Pedal Demand Filter help topic for more information.
**Tuning Tip**: To avoid large input delays from the Pedal Position Sensor the filter setting on the raw input should be keep small . i.e the input filtering is done during the **Pedal Position Sensor -> Pedal Position Demand** so minimal filtering is required on the raw Pedal Position Sensor Input (See Config View -> Channels -> Inputs Setup -> DBW/Servo Tab). A Typical value will be between 0 - 4.
So this step is Pedal Position Demand ->Throttle Area Demand
See the Pedal to Throttle Area Translation help topic for more information.
So this final step is Throttle Area Demand -> DBW Servo Position Target
See the Throttle Body Area help topic for more information and examples
Driver Demand Torque is calculated based on various parameters in the ECU along with driver controlled pedal inputs.
If however there are correlation errors between the actual Engine Torque and Driver Demand torque, these can be trimmed using this table.
The range is 0.000 to 2.000. A value of 1.000 being equivalent to the calculated torque demand without correction. As with the Engine torque correction table the default table is produced using only the the X axis as an example. However both the X & Y axis are available and can be enabled at any time in the axis setup form.
Note: The Driver Demand Torque is calculated fully Independent to the Engine Torque, so there will always be a small error between the two. A normal and acceptable error is around 10%. For example Driver Demand Torque might be 470Nm and Engine Torque 490Nm. This is an acceptable error & not unusual.
This table calibrates the torque reduction % per degree. When a torque request is applied the ECU will calculate how much retard is required to achieve this torque request.
Example : 1.5%/ Deg.
The Engine is running at 600Nm and a Torque Reduction to 400Nm is requested.
This is a 33% reduction in Torque so at 1.5%/Deg the ECU will Retard the Ignition 22 Degrees.
(33% / 1.5%/deg = 22 Deg)
Example : 16 degrees of ignition trims (Ignition Trims Total) are being applied - for any reason (comps, secondary load, etc)
The ECU will calculate 20% of torque reduction - can be observed with Runtime “Torque Reduction - Retard (Nm)”
See default table settings below.
Torque Reduction Ignition Retard Gain Table
This table calibrates the torque reduction % per %cut. When a torque request is applied the ECU will calculate how much cut is required to achieve this torque request.
See default table settings below.
Torque Reduction Cut Gain Table
During Torque Limiting the ECU calculates (when enabled) the Minimum Boost Target required for the engine to achieve this Torque. The engine actually needs more than this minimum for the Throttle Mass Limiting to be effective so the " Boost Target Margin" is added to this value.
Example: ECU calculates a Boost Target of 150 kPa. If Boost Target Margin is 20kPa, the final Boost Target during Throttle Mass Flow Limiting will be 170kPa
A total of 5 different Torque Limit strategies can be configured. Different situations and scenarios may call for multiple methods of torque limiting strategies.
Torque Strategies can use a combination of Throttle Area, Ignition Retard, and Cutting to achieve the requested torque target. A priority system is used to determine the prefferred method of torque reduction, this is particularly useful during long sustained Torque Limit conditions.
The first priority is always given preference, however should the chosen priority mode not achieve the torque target before hitting a clamp value or during the time it takes for Throttle Air Mass to change, the next priority mode will be used.
When the Torque Limit is entered, the Throttle Area will begin to transition to the position calculated to acheive the requested torque air mass. During this transition the torque limit will likely not be achieved, so the system will shift to Priority 2 and introduce the calculated Ignition Retard required to achieve the torque target.
Should be torque target still not be met and the Retard applied has reached the max clamp, the system will shift to Priority 3 to complete the torque reduction with cutting.
Similarly, when the Ignition Retard is enough to maintain the torque reduction, the cutting will be removed. Finally, once the Throttle Area is able to sustain the Torque Limit, the Ignition Retard will be removed.
This clamp value sets the maximum amount of ignition timing retard the ECU is able to apply during a torque reduction event.
Note: An insufficient clamp value will result in an insufficient torque reduction when requested resulting in an failed torque reduction event
In applications where Nitrous is used to increase torque. The ECU calculates this torque increase however if required the gain of this torque increase can be used to trim the output.
The brake specific fuel consumption of an engine depends on many factors including thermal efficiency, mechanical efficiency and air to fuel ratios.
Brake specific fuel consumption should be set at Lambda 1.000. The ECU will automatically scale this value based on Lambda Target. The assumption is the engine is tuned to this Target.
Typical Value: 304 - 243 g/kW.h
In addition to Motorsport and special features included in the firmware that utilize Torque Management (Launch Control, Traction Control, Engine Speed limiting), there are 5 User Configurable Torque Limits.
The User Torque Limits must be enabled in the Function Output Setup
Furthermore, a Custom Label can be assigned to the function
Choose Strat to use for each Torque Limit
Choose Target Gear for Normalised Torque target
Example Below: (Gear Ratio Table MUST be setup)
Normalised Gear = 2 (which is Ratio 2.130)
Feedforward Torque = 300Nm
Select Tq Limit User Enable
This entry value in Nm is the torque target when the limit is active.
This entry will compensate the torque target table. Values entered are +/- %.
The ECU accurately calculates the Engine Torque, however if any calibration errors lead to incorrect readings, this table allows the user to adjust the gain based on any parameter listed in the axis setup form.
The range is 0.000 to 2.000, a value of 1.000 being equivalent to the calculated torque demand without correction. The default table is produced using only the X axis as an example. The Y axis is available and can be enabled at any time in the axis setup form.
Engine Torque Ideal = 490Nm
Frictional Loss Total = -88Nm
Engine Torque Correction = 0.985
The engine torque produced by combustion is calculated by the ECU and referred to as “Ideal” Engine Torque. The moving parts within the engine have mass and are subject to frictional losses and therefore limit the actual torque available. As such, the estimate of torque required to overcome this drag effect is called Frictional Loss. This estimate is found in the Frictional Loss Table in units of Nm. A default table is provided as a guide to be adjusted (See below)
These internal torque losses are mainly influenced by the cylinder count i.e. the more cylinders you have, the more moving parts and therefore more friction & the more parasitic loss of torque.
The engine must be actually mapped and calibrated before editing this table. An easy way to get a close representation of this loss is to adjust the frictional loss value at each RPM point to achieve a normal Engine Torque (uncorrected) value of 0 Nm (i.e. no engine acceleration or deceleration). Another hint that there is an incorrect setting will be correlation problems between the ECU calculated torque and a known accurate reading. See the Torque tab in the Runtime menu (F3) to view this data
| Engine Torque (Uncorrected) = (Engine Torque Ideal - Torque Frictional Loss) x Engine Torque Correction |
|---|
There are two (2) tables that allow offsetting of the frictional loss. One typical example will be adjusting the loss based on oil temperature.
Frictional loss is instrumental in torque management tuning. If any function in the ECU requires torque targeting, feeding error here will cause the system to not function correctly.
Tuning the Frictional Loss tables when the engine is in “maintenance” free revving range (neutral) is the simplest way to do this -
Example - change the engine speed in neutral (with nothing dragging on the engine) and adjust the frictional loss table until Engine Torque (Uncorrected) = 0
**** Note - engine temperature, oil temperature, and other factors will greatly affect Frictional loss. There are two offset tables available to adjust for those factors.**
**** Error in fuel model or basic setup will cause base torque values to not calculate correctly. Make sure there is no error in lambda target during tests.**
Torque Frictional Loss = -76.0
Engine Torque Ideal = 74.4
Engine Torque Uncorrected = -1.6
Tuning -> Engine Functions -> Torque Management -> Frictional Loss Table
This procedure teaches the ECU how much “Ideal” torque is required to achieve different engine speeds, and is instrumental in RPM targeting the engine for any kind of function requiring that (RPM limiting, Launch Limiting, etc)
The ECU takes the raw Pedal Position Sensor 1 input, passes it through exponential filter to help smooth out signal fluctuations, then generates a new runtime Pedal Position Demand.
| Pedal Position Sensor -> EXPONTENTIAL FILTER -> Pedal Position Demand |
|---|
The filter coefficients for the exponential filter are adjustable using a table. These filter coefficients can be used to heavily filter small throttle corrections, while allowing large throttle changes to have little or no filtering. By heavily filtering small throttle corrections, throttle sensitivity can be reduced, helping the throttle “feel” when driving over bumpy roads or when making small throttle changes. Little filtering when making large throttle changes helps to give a fast throttle response when a large acceleration or deceleration is requested.
See the DBW Torque Management help topic for more information on the process of converting Pedal Position to Throttle Area to DBW Servo target.
These settings allow for the lockout of the pedal filter based on the pedal position.
This controls how much filtering is applied. It is common to filter heavily at low rates of pedal position sensor output in order to achieve a smooth driver torque demand.
0 = Filtering OFF
99 = Max Filtering
Important Note: It is strongly recommended to span the table axis as follows:
Using dPedal Position Sensor 1 and Pedal Position Sensor 1, the Throttle Area Demand can be softened at low dPedal rates whilst also giving the ability to change the filtering based on the raw pedal position.
Reviewing PC/ECU logs will allow the user to achieve the desired effect.
As discussed at the beginning of this section DBW Torque Management the ECUs Torque Management using DBW requires the plate control to be in Throttle Area, not Throttle position.
.
Pedal to Throttle Area Demand translation is performed using a 3D table. Three tables are available, only 1 can be active at any one time.
NOTE: This table targets Throttle Area (NOT DBW Servo Position)
The relationship of Servo Position should be ignored with a properly tuned Throttle Body Area system in the Throttle Body Model. Torque targeting should be the overall mentality of this map, and while with everything configure as it should (TMF, etc), linearized table may produce linearized Driver Demand, this may not be ideal for how the vehicle will want to drive. More often than not the demand table will end up in a shape where the higher end of the table (60+) has much larger values in it - to demand more torque.
The Y-Axis runtime should be spanned using “Pedal Position Demand” which is a filtered version of the raw Pedal Position sensor. See Pedal Position Demand Filter .
A typical runtime for the X-Axis is Engine Speed.
Pedal to Throttle Area Demand Translation table
This is a 3D table that clamps the maximum allowable throttle area. If no clamping of the Throttle Demand is needed, a single value of 100% can be used.
Two examples are shown below.
Basic Throttle Area clamp table (no Throttle Demand Clamping is needed)
Advanced clamp table (based on Traction Target Error and Ground Speed Limiter)
As mentioned at the start, there are 3 tables which can be control in a variety of ways. The following options are available
0: N/A (Tables OFF)
1: ON – Table 1 (Table 1 Available)
2: ON – Table 2 (Table 2 Available)
3: ON – Table 3 (Table 3 Available)
4: N/A
5: Cal Slot (Cal Slot Control selects active table)
6: ON – Z-Axis (Z Axis Table selects/blends active table)
7: ON – Table 1 = DBW 1/Table 2 = DBW2 Air Bleed
Modes 1-3: Activate individual tables
** Mode 1 is most common (Table 1 activated)
Mode 5: Allows Cal Slot Control to select the active table (See Cal Slot Control)
Mode 6: Enables a Z-Axis table that allows selection/blending of the active table,
Axis based on Front Axle Speed. Units are active table
Mode 7: Allows two different drive by wire servos to have different targets. DBW Servo 1 controlling the main airflow into the engine, and DBW Servo 2 being used for a different purpose like DBW Air Bleed on turbocharged or supercharged engines.
Pedal to Throttle Demand Translation Table 1 = DBW 1 Control .
Pedal to Throttle Demand Translation Table 2 = DBW 2. This is used for compressor surge control by venting excess air the engine cannot use.
This is a good example of how Emtron allows you to layer multiple functions together to obtain a desired result
