ECU Fuel Trim - use in Diagnostics

Fuel trim is technology used to keep the fuelling control operating correctly over vehicle lifetime, in order to comply with emissions regulations. Trim values are accessible via scan tools and this knowledge can help your diagnostic procedures.

What does it do?

Short-term fuel trim (STFT) and long-term fuel trim (LTFT) are expressed as a percentage, Positive fuel trim percentages indicate that the ECU is attempting to richen the fuel mixture, to compensate for a lean condition. Negative fuel trim percentages indicate the opposite. Fuel trim values are generated and stored with respect to engine operating condition – generally speed or load.

Why do you need it?

As vehicles operate over their lifetime, and accumulate mileage. The engine system components accumulate operating hours, and thus experience wear and tear. With respect to the fuelling control system – air flow meters can become dirty and contaminated, and this has an effect on their initial calibration and response characteristic. Oxygen sensors can also become contaminated and this impacts on their accuracy and reliability of the signal. The fuel injection wet system also suffers from long term fatigue effects – injectors can clog, thus affecting their spray pattern, and ability to provide a homogenous charge for combustion. Fuel pressure regulators lose their calibration and accuracy due to the continuous operation mode. Add to these factors, general engine wear, due to loading and thermal effects and it’s clear that over a long period of time, the accuracy and capability of the engine control system, with respect to correct fuelling, becomes compromised. In the past, this gradual loss of accuracy for fuel metering would have been accepted – just wear and tear. However, due to ever tightening emissions regulations, this is no longer accepted! The engine control system must maintain emissions within prescribed limits over vehicle life, and if it can’t (perhaps due to component failure) then the system must inform the driver that his vehicle has exceeded critical limits. So that’s why we need fuel trim – to monitor and compensate the closed loop emission control system, over a long term period (the life of the car).

Adaptive Learning

Fuel trim values are the result of an adaptive learning strategy within the ECU, this monitors the effectiveness of the control system during engine operation. For example, a gasoline engine ECU system will determine deviations from stoichiometry in the exhaust gas content over time. The information is stored in non-volatile memory and used to adjust or offset the fuelling value from the original stored fuel map value, to the required value, taking into account wear and tear factors. This is known as a long term trim value – it is learned by the ECU and it is not lost when the battery is disconnected, it generally can only be reset by a technician with a scan tool. 

In addition, there are short term trim values, these are offset values based on short term effects, in response to temporary changes. Typically, for a gasoline engine, the short term trim values are a result of the closed loop lambda control system, comprising of the pre-catalyst oxygen sensor signal, that helps maintain fuelling at the stoichiometric point. Short and long term fuel trim correction values work together to maintain the correct, required lambda value. The short term trim will provide immediate correction, and if this correction is needed to maintain the required value on an on-going basis, then the long term fuel trim will learn this and provide a permanent offset to the basic fuelling map. Note though, this process is monitored and maintained within calibrated limits that correlate with tailpipe emissions. If the long term trim value becomes greater than a certain, pre-set limit. Then this is used as a trigger in the diagnostic (OBD) system to inform the driver of an emissions related problem, via the MIL (Malfunction Indicator Lamp) and storage of an appropriate DTC (Diagnostic Trouble Code).

Fig 1 - Fuel trim is effected by modifying the basic injector demand, for the engine operating condition

Fuel trim diagnostics

A useful aspect of fuel trim values is the potential of being able to use them as part diagnostic procedures. Many fault coder readers, including low cost, generic devices, can provide fuel trim values. If you know and understand what these values are, and how they are generated, then you can use them to help you understand the nature and root cause of many fuel systems related faults that you may come across.

Assuming you can access fuel trim information, how does it help you? During normal engine operation, the ECU records long (LTFT) and short (STFT) term fuel trim values as ECU labels (accessible via a scan tool). STFT normally cycles at the same frequency as the oxygen sensor switches, in effect it reflects the operation of the closed loop lambda control. LTFT is normally quite stable, and any adjustment of the value is made over a long period of time, so is less noticeable. Remember that LTFT is held in non-volatile memory (also known as KAM – keep alive memory), but STFT is dynamic, thus constantly changes during run-time, but starting at zero, both values re-set when DTC’s are cleared.

Gasoline engines are inherently unstable! The cycle-to cycle, and cylinder to cylinder variations cause loss of efficiency and roughness. So the ECU is continually adjusting spark timing and fuelling to compensate for this fact. As injectors wear, the delivered quantity and spray pattern are compromised, and this can cause cylinder specific fuelling faults that can be identified very efficiently using fuel trim values! The long and short term fuel trim value will reflect any variations in injector delivery or combustion efficiency for a specific cylinder, and can help diagnose faults like leaking blocked or dirty injectors.

Fig 2 - Typical fuel trim values at idle, as shown on a standard scan tool, connected to the vehicle OBD connector. Note that STFT is negative and follows closed loop lambda operation. LTFT is much more stable over time, and is a positive value. Both are within acceptable limits

Trim values should generally not exceed 10% either way. Positive means the ECU is trying to compensate for a weak mixture, it does this by extending the basic injector pulse width. This could indicate faults caused by air leaks in the flow system, manifold or vacuum pipework. In addition, MAF (mass airflow meter) or oxygen sensor issues. Lean mixture problems are the most common failure mode. Negative trims mean that the engine is running rich, and the base pulse width is reduced to compensate. This could indicate problems with EGR, MAF, fuel pressure regulator, leaking injectors or oxygen sensor problems. Individual cylinder contributions can also be evaluated. Disconnecting the injectors one-by-one and monitoring fuel trim values allows the technician, to compare each cylinder with the others. Thus individual misfire or injector problems can be identified clearly.

Fig 3 - Fuel trim - high idle speed. STFT is now positive, LTFT has switched negative, this shows how both work together to achieve the required target of Lambda 1.

Summary

It is worth to remember though that different ECU’s will respond differently to a given fault or diagnostic stimulus, in particular with respect to how LTFT and STFT work together to address a deviation or system problem. This is part of the ECU calibration strategy, so there are no hard a fast rules, but if you understand what LT and ST fuel trims are, and what they do. Then you can observe what you see and make an informed judgement. There is no doubt that being familiar with the concept will help your diagnostics of fuelling related problems. If you have time, it’s always worth making some observational measurements of a known ‘good’ vehicle, and record/note the data. Ready for the next faulty vehicle of that type or make to appear!

Technology focus - Automotive ECU Development – a technology insight

We are all familiar with the fact that the complexity of modern vehicles is growing rapidly! With each new generation of vehicle, the sophistication of the power train, chassis and body control systems increases significantly. This is only possible due to the increasing number of electronic controllers around the vehicle (ECU's) and with each vehicle generation, they become more powerful (in terms of memory and processing power), and they are increasingly more 'connected' - sharing data and information during vehicle operation.

Having a complicated controller is now essential to achieve the required performance levels, as well as driver expectation – but have you ever considered the task of getting these control units to function and behave in the correct way. To set them up - fine tuning them for the application. This task is undertaken during vehicle and powertrain system development, and is known as 'calibration'!

Fig 1 - Typical ECU parameters needing to be adjusted in order to achieve the required targets for a modern diesel engine – this is ECU calibration!

What is ECU Calibration?

An ECU is a micro-processor based control unit that performs complex functions by running sophisticated control algorithms. The tuning of these to suit the application (e.g. engine, vehicle type etc.) is a task commonly known as CALIBRATION. The Calibration Engineer will adjust the parameters of the control function algorithms that are stored in permanent memory inside the ECU (maps, tables etc.) during development. This will allow optimisation the controller based on targets (good fuel consumption, good drivability) whilst keeping within boundary limits (noise, temperatures).

Fig 2 - The increasing complexity of the ECU calibration task

Within the ECU software, each physical data value is known as a 'label' - this could be a calibration value (i.e. a value that needs adjusting or 'calibrating') or a measurement value (i.e. an internal value used within the software, for example 'engine temperature' or ' desired ignition angle for spark advance'). The number of 'labels' has grown massively with increasing complexity - 10 years ago there were 3000 to 5000 labels to deal with, now, it is 40,000 to 50,000 labels. This shows what a massive task the overall calibration of an ECU is!

In order to 'calibrate' effectively, access to these labels is needed during ECU operation! Actually, that is not strictly true - in years gone by, the 'calibrations', which were much simpler, were held on memory chips. These chips could be replaced or re-written off line and re-installed into the ECU, thus providing a new calibration. There were (and are) many providers in the aftermarket doing this, providing updated calibrations that added horsepower (at the expense of other things, like fuel consumption and driveability) to boy racer types! The technical term for this approach is 'off line' calibration!

But this offline technology does not support an efficient calibration process in development - typically, there is a lot of 'round trip Engineering' when calibrating an ECU. For example, changing values, checking responses, comparing with measurement data on-line, and off-line. To support this task efficiently, 'on line' calibration technology is needed. That is, seeing and changing what is going on inside the ECU, during operation! Anyone who has used a scan tool to view and record data during a test drive will experience seeing on-line measurement labels. However, the calibrator needs to see all the labels for his task, including being able to change some of them, and test and measure the response immediately. For this, a suitable software and hardware tool chain is needed. Typically, this consists of application software running on a PC, in combination with an interface to the ECU.

Fig 3 - The calibration tool runs on a PC and connects to the ECU via an interface that allows changing of parameters during runtime (Source: ATI)

Fig 4 - ECU access methods and their relative performance

Technology focus - Engine Control Unit (ECU) - Torque based architecture explained

In older generation engine management systems, different internal control subsystems had conflicting demands on the overall control system, with no real co-ordination. This meant that there was an interdependence between these systems, which was difficult to handle during calibration and did not provide the optimum with respect to an overall engine control concept. The answer was a 'torque' based architecture in the ECU - that is, to focus on the driver demand for torque, rather than respond to the throttle pedal postion.

Fig 1 - Conflicting torque demands in an Engine control unit

The block diagram above shows the conflicting requirements - the answer was a torque based control architecture – an overall torque demand manager (TDM) co-ordinates all the overall torque and efficiency input values. Internal inputs are typically defined by the engine operating mode and protection limits, external inputs are driver demand, cruise control and vehicle dynamic control values (ABS, Stability control etc.). The TDM process the inputs, taking into account drivability optimisation factors (thus allowing ‘tuning’ of the vehicle behaviour with respect to vehicle type and driver expectation). The final output from the TDM is a required torque value, this is realised by the controller output stages and connected actuators which are available to influence the engine torque output – typically throttle angle, ignition timing (SI engine), injection parameters (SI and CI engine) and turbocharger control.

Fig 2 - Overview of the TDM function (Torque Demand Manager)

But how is engine torque measured? well it isn’t! it is derived from an internal model that takes into account cylinder air charge, lambda and ignition timing (SI engine). Combustion generates a cylinder based ‘internal’ torque, from this gas exchange and friction losses are estimated and subtracted, and this gives a final engine output torque. Clutch torque can then be derived by subtracting engine ancillary torque absorbers, for example, Electrical and HVAC loads.

Fig 3 - Virtual torque sensor function which forms the basis of a torque based ECU structure

Technology focus - Vehicle network and communication bus technology

Vehicle networks have become common place in modern automotive electrical and electronic systems. As the cost of electronic systems has reduced, this technology has become the most efficient way of handing the large amount of data required and shared by modern vehicle control systems. The introduction of automotive compatible serial data networks has expanded the capabilities for intelligent data transfer and sharing of information and is a logical development for modern vehicles.

Fig 1 - Relative comparison of BUS performance level

Bus systems for different applications require different data transmission rate capability (also known as bandwidth). It is very common to see a several networks on the same vehicle running at different speeds appropriate for the application. There are a number of typical groups implemented with different performance requirements: 

• Entertainment/Multimedia – Mobile communications, radio, navigation 
• Body and Convenience – Lighting, HVAC, Door locks, mirrors etc. 
• Powertrain – Powertrain control, Vehicle Dynamic control, Driver Safety systems 

Current Technology

The most widely adopted vehicle network technology was developed by Bosch and is known as CAN (Controller Area Network). This technology has established itself as the standard for vehicle manufacturers. It should be noted though that there are a number of other network technologies available and under development:

CAN

The basic principle of the CAN bus is that individual modules (ECU’s) are connected in parallel to the bus system. Each point of connection to the bus is known as a node and all the connected nodes have equal priority. This means that all messages on the bus are available to all the ECU’s at the same time. This is known as a multi-master system. The advantage of this method is that failure of one node does not impair bus-system access for the other connected nodes and this increases the overall reliability of the system. In addition, the system is designed with a high degree of inbuilt safety with respect to error checking and handling of transmitted data.

The basic principle is that each control unit is connected to the bus, in parallel, by transceiver modules. The transceiver is a transmitter and receiver amplifier. It converts serial data into electrical signals on the bus (and vice versa). Generally the signal is transmitted over a differential line as this provides superior electrical interference rejection. The information is transmitted as electronic messages and each control unit can send and receive them via the transceiver. A typical message would be a physical value, for example, engine speed. This is converted into a binary number and them transmitted electrically as a serial bit stream on the CAN data bus as 1’s and 0’s. All the other control units on the bus receive this data and can convert the bit stream back into a message ready for processing by the ECU.

Between the transceiver and ECU, the CAN module controls the data transfer process for the CAN messages to and from the ECU. It is divided into 2 sections – send and receive. The CAN module transmits data to the ECU via mailboxes (i.e. memory locations) which have read/write access to and from the ECU processor.The CAN data bus can be in one of 2 states representing 1 or 0. The transceiver is connected to the bus line via an open collector. This results in two possible states on the bus line:

• Transistor ‘open circuit’ - high state via resistor, bus level high (logic 1) 
• Transistor ‘closed circuit’ – low state, resistor shorted, bus level low (logic 0). 

These are known as recessive and dominant states. If we look at 3 transceivers connected on a bus line. It will be clear that if any switch is closed, the bus line becomes 0 state, if all switches are open, bus line become 1 status. Also, if the bus is in state 1 any node can overwrite this state to 0. This shows how the multi-master or broadcast system works but there are some considerations with this method: 

What if two control units send at the same time? 

Fault handling? 

In order to understand more clearly we will look at the send and receive process in more detail:

Example: Data Transmission

In this example we will look at the transmission of throttle position data to an ABS ECU. 

1. First the Engine ECU gets the throttle position value, this value is stored in the ECU microprocessor memory ready for transmission 
2. This data is then passed to the transmit mailbox of the CAN module, a electronic ‘flag’ is then raised to indicate that data is ready for transmission 
3. The data is then converted into a message in the correct format for transmission according to the CAN protocol. The main components of this protocol included in the message are: 

• Identifier – States what the message data is 
• Message content – Actual data value 
• Checksum – method or error protection 
• Acknowledge – Message acknowledgement 

In addition: 

• Other – start and end of frame messages, control message (size of data field) 
• CAN module checks that the bus is active and if necessary waits until it is free. When the bus is free, the data is transmitted by the transceiver. 

Fig 2 - CAN data transmission concept

Example: Data Receive

All nodes on the CAN bus receive the transmitted data at their transceivers. First the data is checked for errors and usability. This helps to detect local faults but still allows high data throughput on the bus. Using the checksum part of the protocol (CRC- Cyclic Redundancy Check) transmission faults can be detected. If no errors are found an acknowledgment is sent to the transmitter confirming reception of the data intact. The message is then processed in the CAN module and a decision is made as to whether that message is relevant to that control unit (or node). If so, the message is placed in the receive mailbox, otherwise it is discarded. When the receive flag is raised, the ECU microprocessor knows new information has arrived. This data is then copied into the input memory of the microprocessor ready for use. Data exchange is repeated cyclically according to the cycle time setting.

Error Handling

If several control units transmit data at once there would be collision on the bus. This is avoided by using bus arbitration with the following strategy. Every node starts its transmission by sending an identifier and all the nodes monitor the bus traffic. The identifier sets the priority of the message and the message with the highest priority is assigned first access to the bus without delay. Transceivers respond to failure to gain bus access by automatically switching into receive mode; they then repeat the transmission attempt as soon as the bus is free again.

The CAN protocol has an extensive error management system capable of detecting transmission errors with a high degree of certainty. Any node detecting an error can inform the other nodes via transmission of an error frame and the message can then be rejected by all nodes. Following this, an automatic re-transmission is executed and these are monitored. If these become frequent, a control unit can be automatically switched off to prevent bus traffic being impaired.

LIN

This is an acronym for Local Interconnect Network which is a technology that has been proposed and developed by a consortium of manufacturers including Audi, Daimler-Chrysler, Volkswagen and Volvo. It is a low-cost alternative to CAN where high bandwidth is not required (for example, comfort and convenience functions like window lift, central locking). The main difference between LIN and CAN is that bus access in a LIN network is controlled by a master node so that no arbitration or data collision management in the slave nodes is required. Note that LIN is implemented as a sub-bus and as such fully integrates with a vehicle CAN network. LIN is a complimentary bus system and is not designed as a replacement for CAN. It’s main application is where the throughput capability and versatility of CAN is not required.

Fig 3 - Typical applications for LIN bus

LIN bus is generally implemented as a single-wire serial communications protocol using simple UART hardware (which is available on most microcontrollers as standard). A particular feature is the self-synchronization in the slave nodes without crystal or ceramic oscillators. These two factors together significantly reduce the cost of the electronic hardware needed for interfacing to the bus.

The specification of the line driver and receiver follows the ISO 9141 single-wire standard (with some enhancements). The maximum transmission speed is limited to 20 kbit/s due to the requirements for electromagnetic compatibility (EMC) and clock synchronization. A node in a LIN network does not make use of any information about the system configuration, except for identification of the master node. Nodes can be added to the LIN network without requiring hardware or software changes in other slave nodes. The size of a LIN network is typically under 12 nodes (though not restricted to this), resulting from the fact that only 64 identifiers are available and also the relatively low transmission speed.

New Developments

Due to the rapid developments in automotive technology, faster, near real-time performance capability for data transmission networks will be essential (for example, drive or brake-by-wire systems). New bus systems are being developed and proposed for these applications. The leading technology is Flexray which has already been implemented in production (to an extent, on the suspension control of the BMW X5). This technology has been developed by a consortium including Volkswagen, BMW, Daimler-Chrysler, General Motors and Bosch

FLEXRAY

FlexRay has been designed to support the high-bandwidth needs of current and future in-car control applications. At the core of the system is the communications protocol. The protocol provides flexibility and performance and has the following features: 

• Time- and event-triggered communication schemes 
• High error detection and error diagnosis capability 
• Sophisticated power down and wake up mechanisms 
• Flexible extendibility and full scalability to enable upgrades 
• Collision-free bus access 
• Guaranteed message latency 
• Message oriented addressing via identifiers 
• Scalable system fault-tolerance via the support of either single or dual channels 

A hardware layer incorporating an independent bus monitoring feature provides further support for error management. The FlexRay system is targeted to support data rates of up to 10Mbit/sec with a gross of up to 20Mbit/sec possible. The system consists of a bus network and processors (ECU, electronic control units) similar to the CAN bus system. Each ECU has an independent clock. And these are frequently resynchronised to guarantee high performance. The Flexray network provides scalable fault-tolerance by allowing single or dual-channel communication. For security-critical applications, the devices connected to the bus may use both channels for transferring data. However, it is also possible to connect only one channel when redundancy is not needed, or to increase the bandwidth by using both channels for transferring non-redundant data.

Within the hardware layer, the Flexray protocol provides fast error detection and signalling, as well as error management via an independent Bus Guardian. The main benefits of:

• Provides up to 10Mbit/sec data rate on 2 channels, or a gross data rate up to 20Mbit/sec 
• Significantly increases Frame Length (compared to CAN – 8 Bytes per frame) 
• Synchronous and asynchronous data transfer possible 
• Guaranteed frame latency during synchronous transfer (deterministic performance) 
• Provides prioritization of messages during asynchronous transfer 
• Provides fault-tolerant clock synchronization via a global time base 
• Error detection and signalling capability 
• Enables error containment on the physical layer through the use of an independent bus guardian mechanism 
• Provides scalable fault-tolerance through single or dual channel communication 

Flexray has been specifically developed to support future requirements in the Industry and will become commonplace in the high-performance control systems mentioned above. In addition, it has the performance to support active and passive safety systems, collision avoidance and driver assistance systems.

CAN FD (CAN WITH FLEXIBLE DATA RATE)

The wide acceptance of vehicle serial communication buses like CAN, to more and more applications has led to requirements that the bandwidth for this serial communication needs to be increased. There are 2 factors that limit the effective data-rate in CAN networks, first the minimum bit length required for the CAN bus arbitration method and second, the relation between the numbers of data bits and other frame bits in a CAN message.

There is now an evolution of CAN to cope with this higher demand called "CAN with Flexible Data-Rate" or CAN FD. It is based on the CAN protocol as specified in ISO 11898-1. It still uses the CAN bus arbitration method, but it increases the bit-rate by switching to a shorter bit time after the end of the arbitration process, then returning to the longer bit time at the CRC delimiter (but before the receivers send their acknowledge bits). The effective data-rate is also increased by allowing longer data fields. CAN normally uses four bits as Data Length Code (DLC) resulting in 16 different codes, but generally, only the first nine values are used, codes [0 - 8] standing for a data field length of [0 - 8] bytes. In CAN, the codes [9 - 15] are defined to signify eight data bytes. In CAN FD, the codes are used to signify longer data fields.

So, there are two main differences between the CAN FD frame format and the CAN frame format, first the option to use frames with more than 8 data bytes and second the option to switch to a different bit rate after the arbitration is decided. Note that CAN systems can migrate gradually to CAN FD systems. All nodes in the network must have a CAN FD protocol controller for CAN FD communication, but all CAN FD protocol controllers are also able to take part in standard CAN communication. In the introductory phase, CAN FD communication may be limited to specific use cases or applications, e.g. software-download, while the other nodes that do not support CAN FD are kept in standby. If the CAN FD communication is limited to data fields with a length of up to eight data bytes, it is not necessary to change the application program apart from the initial configuration of the controller.