Have you ever wondered how trips, (aka micro-trips, trip cycles) differ from drive cycles? If so, you are not alone, but while “trips” are easy to define, the term “drive cycle” means different things to different people. For instance, to automotive engineers, legislators, and accountants a drive cycle is a means to reduce per-vehicle test costs, while to a technician a drive cycle is a valuable diagnostic aid that can be used both to diagnose faults, and to verify repairs. This article will explore drive cycles and how they relate to OBD II diagnostic procedures, starting with this question-
Put simply, in the vehicles’ test/development phase, a trip is defined as the period in which a vehicle is in operation, provided that each period begins with a period of idling, and ends with a period of idling before the ignition is switched off. In practice, many, if not most drive cycles consist of varying numbers of trips performed under different driving conditions that are cobbled together to form a cohesive test program.
From a vehicle design and testing perspective, drive cycles are defined as speed-time profiles that are designed to represent or mimic real-world driving conditions in order to calculate emission and energy consumption levels. However, while drive cycles in this context reduces per-vehicle test costs, the limited duration of these cycles (typically, between 2 and 30 minutes) are inherently flawed since vehicle are always tested without ancillary loads. These typically include switched on headlights, and added weight to represent passengers, etc. Using data obtained during dynamometer tests, correction factors for speed, emissions, and particularly gearshift points are developed and incorporated into a drive cycle to represent emissions under different driving and/or operating conditions.
In Australia, the Australian Design Rules dictate that all new vehicles offered for sale in Australia must be tested with the same procedure, and under the same conditions by accredited emissions laboratories. In fact, the same drive cycle is used for all vehicles to assess emission levels, particularly CO2 emissions and fuel consumption rates. In practice, Australian authorities use two drive cycles, the CUEDC (Composite Urban Emissions Drive Cycle) for light duty petrol vehicles, and the various CUEDC drive cycles that were developed in 1998 to assess diesel vehicles.
It should be noted though that the CUEDC drive cycles are used only to ensure that all new vehicles sold in Australia meet the minimum emissions standards, and not to provide objective, and repeatable test results for every model sold. For instance, many major cities the world over including Perth, Melbourne, and Sydney have developed their own versions of existing drive cycles that resemble actual driving conditions in these cities more closely than generic drive cycles can ever do, which brings us to-
While the above is no doubt very interesting, it has very little, if any bearing on what trips and drive cycles mean to a technician in terms of generally accepted OBD II diagnostic standards and procedures. Most experienced technicians are no doubt conversant with the relationship between drive cycles and readiness monitors, but technicians and mechanics that are not fully up to speed in this area might benefit from what follows.
For any given vehicle to be fully OBD II compliant, it has to be able to perform a series of self-diagnostic tests to ensure that all components and systems that can effect emissions are fully functional. In diagnostic parlance, these tests are known as “readiness monitors”, and while we don’t have to delve into the various types of monitors here, it must be noted that for any given monitor to run or complete successfully, a set of very specific preconditions must be present.
Typical preconditions might include the following examples, depending on the application and the monitor-
There are many other examples, but the point is this; vehicle manufacturers have developed drive cycles that allow these (and other) preconditions to be met under conditions that closely resemble real world driving conditions. The purpose of these drive cycles then is to set the conditions required by any particular monitor to run.
In practice though, and assuming that the ECU (which incidentally, is the final “arbiter” in matters of DTC priorities) does not detect issues with any monitor, the ECU will mark all monitors as “Completed Successfully”. Provided that no defects, failures, or malfunctions that affect emissions occur during the trip, the ECU will also record this fact in its trip counter.
While there are some exceptions, the OBD II system uses “two-trip” detection logic, with a trip in this context being a period in which the vehicle is operation, but with the added requirements that the coolant temperature is above a minimum prescribed level, and that the ECU is in closed loop communication with the emission control system components/sensors.
In simple terms, this means that a failure, defect, or malfunction that has the potential to affect emissions must occur on two consecutive trips before a DTC will set as an active fault. However, most, if not all emissions related DTC’s will be noted as “pending” when it first occurs; if the same issue is noted on the subsequent trip, the ECU will escalate the issue to an active DTC and illuminate a warning light, which brings us to-
As technicians, we have the responsibility of fixing our customers’ vehicle right the first time. However, how often do we perform a quick fix and then do a quick road test before handing the vehicle back to the customer only to have the same problem reappear a day or two later, and then having to explain the situation to an irate customer?
The trick to avoiding scenarios like this is to understand three things-
To illustrate the relationship between these factors, we will use two common generic DTC’s as examples-
Imagine you are presented with DTC P0133 on say, a 2004 Toyota Lexus. You repair the circuit issue, clear the code, take the vehicle for a quick test drive around the block, and hand the vehicle back to the customer, being satisfied that the problem had been fixed since the “CHECK ENGINE” did not come on during the test drive. However, the customer returns two days later, and upon investigation, it turns out that DTC P0133 had returned as well, accompanied by another emissions related codes. How did this happen, and how could this have been avoided?
The answers are simple, really. The code returned because the customer had completed two trips with a pending (emissions related) code you did not catch, and you did not perform a DTC specific drive cycle to allow the ECU to verify the original repair of DTC P0133 by allowing all monitors to run and complete.
This unpleasant situation could have been avoided had you;
Although the drive cycle that is required to verify repairs of DTC P0133 on most Toyota applications could take as much as 40 minutes to complete, it is our responsibility as experienced technicians to research all available and recommended repair options. If those options include 40 minutes to complete a drive cycle that was designed to verify a repair, simply quote the additional time on the work order. We are, after all, in the business of repairing cars right the first time- not to lose money on relatively simple repairs.
This is a common code, and particularly on many Ford F-series trucks, so if the code comes back a day or two later, there are a two possibilities to consider-
For instance, you may have found and repaired the intake manifold leak, but missed the small tear in an engine vacuum hose, which it turns out, the customer found when the “CHECK ENGINE” light came on again.
The key points to bear in mind here is that one or more monitors would not have run and/or completed with the broken engine vacuum hose. Thus, by performing a drive cycle whose purpose it is to verify a repair of in this case, P0171 (assuming that all enabling conditions have been met), greatly reduces the chances that pending codes, and/or remaining causes of a DTC go undetected.
Ultimately, our goal is to perform vehicle repairs right the first time, but we can only do this if we use all of the tools we have at our disposal, and foremost among these tools are drive cycles that are specifically designed to verify repairs.
In practice, the ECU is king in the land of OBD II diagnostics, and as such, in some cases it might prevent a monitor from running or completing if pending code with a higher priority is present in the engine management system. An example of this scenario would be if the ECU couldn’t run the relevant monitor to test or verify a repair of say, DTC P0133 if faults relating to the engine coolant temperature sensor or misfire codes are set and stored, since these faults have a higher priority than anything that could have caused DTC P0133.
If a high-end scan tool is used to best effect, it allows us to see everything the ECU “sees”, and deals with on an almost real-time basis. As a practical matter however, the ECU can only verify repairs if it is allowed to run all monitors that apply to the affected vehicle, which it can only do if we, as technicians, perform the proper drive cycles.
