discussed in section II.A.2. Manufacturers may also forego this
monitoring within temperature regions where the temperature gauge
indicates a temperature in the engine overheating ``red zone'' should
the vehicle have a temperature gauge on the instrument panel that
displays the same temperature information as used by the OBD system
(note that a temperature gauge would be required, not a temperature
warning light).
c. Engine Cooling System Monitoring Conditions
i. Thermostat Monitoring Conditions
    We are proposing that manufacturers define the monitoring
conditions for thermostat malfunctions in accordance with the general
monitoring conditions for all engines described in section II.A.3.
Additionally, monitoring for thermostat malfunctions would have to be
done once per drive cycle on every drive cycle in which the ECT sensor
indicates, at engine start, a temperature lower than the temperature
established as the malfunction criteria in section II.D.2.b.i.
Manufacturers would be allowed to disable thermostat monitoring at
ambient engine start temperatures below 20 degrees Fahrenheit.
Manufacturers may suspend or disable thermostat monitoring if the
engine is subjected to conditions that could lead to false diagnosis
(e.g., engine operation at idle for more than 50 percent of the warm-up
time and/or hot restart conditions). To do so, the manufacturer must
submit data and/or engineering analyses that demonstrate that the
suspension or disablement is necessary. In general, the manufacturer
would not be allowed to suspend or disable the thermostat monitor on
engine starts where the engine coolant temperature at engine start is
more than 35 degrees Fahrenheit lower than the thermostat malfunction
threshold temperature.
ii. Engine Coolant Temperature Sensor Monitoring Conditions
    We are proposing that monitoring for ECT sensor circuit continuity
and out-of-range malfunctions be done continuously. Manufacturers would
be allowed to disable continuous ECT sensor monitoring when an ECT
sensor malfunction cannot be distinguished from other effects. To do
so, the manufacturer would have to submit test data and/or engineering
evaluation that demonstrate that a properly functioning sensor cannot
be distinguished from a malfunctioning sensor and that the disablement
interval is limited only to that necessary for avoiding false
detection.
    We are also proposing that manufacturers define the monitoring
conditions for ``time to reach closed-loop/feedback enable
temperature'' malfunctions in accordance with the general monitoring
conditions for all engines described in section II.A.3. Additionally,
monitoring for ``time to reach closed-loop/feedback enable
temperature'' malfunctions would have to be conducted once per drive
cycle on every drive cycle in which the ECT sensor at engine start
indicates a temperature lower than the closed-loop enable temperature
(i.e., all engine start temperatures greater than the ECT sensor out-
of-range low temperature and less than the closed-loop enable
temperature). Manufacturers would be allowed to suspend or delay the
``time to reach closed-loop/feedback enable temperature'' monitor if
the engine is subjected to conditions that could lead to false
diagnosis (e.g., vehicle operation at idle for more than 50 to 75
percent of the warm-up time).
    We are also proposing that manufacturers define the monitoring
conditions for ECT sensor ``stuck in a range below the highest minimum
enable temperature'' and ``stuck in a range above the lowest maximum
enable temperature'' malfunctions in accordance with the general
monitoring conditions for all engines described in section II.A.3 and
in accordance with the minimum performance ratio requirements discussed
in section II.E.
d. Engine Cooling System MIL Illumination and DTC Storage
    We are proposing the general requirements for MIL illumination and
DTC storage as discussed in section II.A.2.
3. Crankcase Ventilation System Monitoring
a. Background
    Crankcase emissions are the pollutants emitted in the gases that
are vented from an engine's crankcase. These gases are also referred to
as ``blowby gases'' because they result from engine exhaust from the
combustion chamber ``blowing by'' the piston rings into the crankcase.
These gases are vented to prevent high pressures from occurring in the
crankcase. Our emission standards have historically prohibited
crankcase emissions from all highway engines except turbocharged heavy-
duty diesel engines. The most common way to eliminate crankcase
emissions has been to vent the blowby gases into the engine air intake
system, so that the gases can be recombusted. We made the exception for
turbocharged heavy-duty diesel engines in the past because of concerns
about fouling that could occur by routing the diesel particulates
(including engine oil) into the turbocharger and aftercooler. Newly
developed closed crankcase filtration systems specifically designed for
turbocharged heavy-duty diesel engines now allow the crankcase gases to
be captured.
    In general, the crankcase ventilation system consists of a fresh
air inlet hose, a crankcase vapor outlet hose, and a crankcase
ventilation valve to control the flow through the system. Fresh air is
introduced to the crankcase via the inlet (typically a connection from
the intake air cleaner assembly). On the opposite side of the
crankcase, vapors are vented from the crankcase through the valve by
way of the outlet hose and then to the intake manifold. On gasoline
engines, the intake manifold provides the vacuum that is needed to
accomplish the circulation while the engine is running.
    For gasoline engines, the valve is used to regulate the amount of
flow based on engine speed. During low engine load operation (e.g.,
idle), the valve is nearly closed allowing only a small portion of air
to flow through the system. With open throttle conditions, the valve
opens to allow more air into the system. At high engine load operation
(i.e., hard accelerations), the valve begins to close again, limiting
air flow to a small amount. For most systems, a mechanical valve is all
that is necessary to adequately regulate crankcase ventilation system
air flow. The crankcase ventilation system on diesel engines, while
slightly different than that for gasoline engines, has essentially the
same purpose and function.
    We do not believe that failures involving cracked or deteriorated
hoses have a significant impact on crankcase emissions because vapors
are drawn into the engine by intake manifold vacuum which suggests that
fresh air would be drawn into the cracked hose rather than dirty
exhaust being blown out of the cracked hose. The more likely cause of
crankcase ventilation system malfunctions and excess emissions is
improper service or tampering of the system. Such failures include
misrouted or disconnected hoses and missing valves. Of these failures,
hose disconnections on the vapor vent side of the system and/or missing
valves can cause harmful crankcase emissions to be vented directly to
the atmosphere.

b. Crankcase Ventilation System Monitoring Requirements
    We are proposing that the OBD system monitor the crankcase
ventilation system on engines so equipped for system integrity. Engines
not equipped with crankcase ventilation systems would be exempt from
monitoring the crankcase ventilation system.
    Specifically for diesel engines, the manufacturer would be required
to submit a plan for the monitoring strategy, malfunction criteria, and
monitoring conditions prior to OBD certification. The plan would have
to demonstrate the effectiveness of the strategy to monitor the
performance of the crankcase ventilation system to the extent feasible
with respect to the malfunction criteria below and the monitoring
conditions required by the monitor.
    We are proposing that the OBD system detect a malfunction of the
crankcase ventilation system when a disconnection of the system occurs
between either the crankcase and the crankcase ventilation valve, or
between the crankcase ventilation valve and the intake manifold.
Manufacturers may forego detecting a disconnection between the
crankcase and the crankcase ventilation valve provided the manufacturer
can demonstrate that the crankcase ventilation system is designed such
that the crankcase ventilation valve is fastened directly to the
crankcase in a manner that makes it significantly more difficult to
remove the valve from the crankcase than to disconnect the line between
the valve and the intake manifold (aging effects must be taken into
consideration). Manufacturers may also forego detecting a disconnection
between the crankcase and the crankcase ventilation valve for system
designs that use tubing between the valve and the crankcase provided
the manufacturer can demonstrate that the connections between the valve
and the crankcase are: (1) Resistant to deterioration or accidental
disconnection; (2) significantly more difficult to disconnect than the
line between the valve and the intake manifold; and, (3) not subject to
disconnection per the manufacturer's repair procedures for non-
crankcase ventilation system repair work. Lastly, manufacturers may
forego detecting a disconnection between the crankcase ventilation
valve and the intake manifold upon determining that the disconnection:
(1) Causes the vehicle to stall immediately during idle operation; or,
(2) is unlikely to occur due to a crankcase ventilation system design
that is integral to the induction system (e.g., machined passages
rather than tubing or hoses).
c. Crankcase Ventilation System Monitoring Conditions
    We are proposing that manufacturers define the monitoring
conditions for crankcase ventilation system malfunctions in accordance
with the general monitoring conditions for all engines described in
section II.A.3, and the minimum performance ratio requirements
discussed in section II.E.
d. Crankcase Ventilation System MIL Illumination and DTC Storage
    We are proposing the general requirements for MIL illumination and
DTC storage as discussed in section II.A.2. The stored DTC need not
specifically identify the crankcase ventilation system (e.g., a DTC for
idle speed control or fuel system monitoring can be stored) if the
manufacturer can demonstrate that additional monitoring hardware would
be necessary to make this identification, and provided the
manufacturer's diagnostic and repair procedures for the detected
malfunction include directions to check the integrity of the crankcase
ventilation system.
4. Comprehensive Component Monitors
a. Background
    Comprehensive components is a term meant to capture essentially
every other emissions related component not discussed above.
Specifically, it covers all other electronic engine components or
systems not mentioned above that either can affect vehicle emissions or
are used as part of the OBD diagnostic strategy for another monitored
component or system. Comprehensive components are generally identified
as input components--i.e., those that provide input directly or
indirectly to the onboard computer--or as output components and/or
systems--i.e., those that receive commands from the onboard computer.
Typical examples of input components include temperature sensors and
pressure sensors, while examples of output components and/or systems
include the idle control system, glow plugs, and wait-to-start lamps.
    While a malfunctioning comprehensive component may not have as much
impact on emissions as a malfunctioning major emissions-related
component, it still could result in a measurable increase in emissions.
The proper performance of these components can be critical to both the
proper functioning of major emissions-related components, and to the
accurate monitoring of those components or systems. Malfunctions of
comprehensive components that go undetected by the OBD system may
disable or adversely affect the robustness of other OBD monitors
without any awareness by the operator that a problem exists. Due to the
vital role these components play, monitoring them properly is extremely
important.
b. Comprehensive Component Monitoring Requirements
    We are proposing that the OBD system monitor for malfunction any
electronic engine components/systems not otherwise described in
sections above that either provides input to (directly or indirectly)
or receives commands from the onboard computer(s), and: (1) Can affect
emissions during any reasonable in-use driving condition; or, (2) is
used as part of the diagnostic strategy for any other monitored system
or component.\43\
---------------------------------------------------------------------------

    \43\ When referring to ``comprehensive components'' and their
monitors, ``electronic engine components/systems'' is not meant to
include components/systems that are driven by the engine yet are not
related to the control of the fueling, air handling, or emissions of
the engine (e.g., PTO components, air conditioning system
components, and power steering components are not included).
---------------------------------------------------------------------------

    Input components required to be monitored may include the crank
angle sensor, knock sensor, throttle position sensor, cam position
sensor, intake air temperature sensor, boost pressure sensor, manifold
pressure sensor, mass air flow sensor, exhaust temperature sensor,
exhaust pressure sensor, fuel pressure sensor, and fuel composition
sensor (e.g., flexible fuel vehicles). Output components/systems
required to be monitored may include the idle speed control system,
glow plug system, variable length intake manifold runner systems,
supercharger or turbocharger electronic components, heated fuel
preparation systems, the wait-to-start lamp on diesel applications, and
the MIL. The manufacturer would be responsible for determining which
input and output components/systems could affect emissions during any
reasonable in-use driving condition. The manufacturer would be allowed
to make this determination based on data or engineering judgment.
However, if the Administrator reasonably believes that a manufacturer
has incorrectly determined that a component/system cannot affect
emissions, the manufacturer may be required to provide emissions data
showing that the component/system, when malfunctioning and installed in
a suitable test engine, does not have an emissions effect. Such
emissions data may be requested for any reasonable driving condition.

i. Input Components
    We are proposing that the OBD system detect malfunctions of input
components caused by a lack of circuit continuity, out-of-range values,
and, where feasible, improper rationality. To the extent feasible, the
rationality diagnostics should verify that a sensor's input to the
onboard computer is neither inappropriately high nor inappropriately
low (i.e., ``two-sided'' diagnostics should be used). Also to the
extent feasible, the OBD system should detect and store different DTCs
that distinguish rationality malfunctions from lack of circuit
continuity malfunctions and out-of-range values. For lack of circuit
continuity malfunctions and out-of-range values, the OBD system should
detect and store different DTCs for each distinct malfunction (e.g.,
out-of-range low, out-of-range high, open circuit). The OBD system is
not required to store separate DTCs for lack of circuit continuity
malfunctions that cannot be distinguished from malfunctions associated
with out-of-range values.
    For input components that are used to activate alternative
strategies that can affect emissions (e.g., AECDs, engine shutdown
systems), the OBD system would be required to detect rationality
malfunctions that cause the system to erroneously activate or
deactivate the alternative strategy. To the extent feasible when using
all available information, the rationality diagnostics should detect a
malfunction if the input component inappropriately indicates a value
that activates or deactivates the alternative strategy. For example, if
an alternative strategy requires an intake air temperature greater than
120 degrees Fahrenheit prior to activating, the OBD system should
detect malfunctions that cause the intake air temperature sensor to
inappropriately indicate a temperature above 120 degrees Fahrenheit.
    For engines that require precise alignment between the camshaft and
the crankshaft, the OBD system would be required to monitor the
crankshaft position sensor(s) and camshaft position sensor(s) to verify
proper alignment between the camshaft and crankshaft. The OBD system
would also have to monitor the sensors for circuit continuity and
rationality malfunctions. Such monitoring for proper alignment between
a camshaft and a crankshaft would only be required in cases where both
are equipped with position sensors.
    For engines equipped with VVT systems and a timing belt or chain,
the OBD system must detect a malfunction if the alignment between the
camshaft and crankshaft is off by one or more cam/crank sprocket cogs
(e.g., the timing belt/chain has slipped by one or more teeth/cogs). If
a manufacturer demonstrates that a single tooth/cog misalignment cannot
cause a measurable increase in emissions during any reasonable driving
condition, the OBD system would be required to detect a malfunction
when the minimum number of teeth/cogs misalignment needed to cause a
measurable emission increase has occurred.
ii. Output Components/Systems
    We are proposing that the OBD system detect a malfunction of an
output component/system when proper functional response of the
component/system to computer commands does not occur. If a functional
check is not feasible, the OBD system would be required to detect
malfunctions caused by a lack of circuit continuity (e.g., short to
ground or high voltage). For output component malfunctions associated
with the lack of circuit continuity, the OBD system is not required to
store different DTCs for each distinct malfunction (e.g., open circuit,
shorted low). Further, manufacturers would not be required to activate
an output component/system when it would not normally be active for the
exclusive purpose of performing functional monitoring of output
components/systems.
    Additionally, the idle control system would have to be monitored
for proper functional response to computer commands. For gasoline
engines that use monitoring strategies based on deviation from target
idle speed, a malfunction would have to be detected when either of the
following conditions occur: (a) The idle speed control system cannot
achieve the target idle speed within 200 revolutions per minute (rpm)
above the target speed or 100 rpm below the target speed--the OBD
system could use larger engine speed tolerances provided the
manufacturer is able to demonstrate via data and/or engineering
analyses that the tolerances can be exceeded without a malfunction
being present; or, (b) the idle speed control system cannot achieve the
target idle speed within the smallest engine speed tolerance range
required by the OBD system to enable any other OBD monitors. For diesel
engines, a malfunction would have to be detected when either of the
following conditions occur: (a) The idle fuel control system cannot
achieve the target idle speed or fuel injection quantity within +/-50
percent of the manufacturer-specified fuel quantity and engine speed
tolerances; or, (b) the idle fuel control system cannot achieve the
target idle speed or fueling quantity within the smallest engine speed
or fueling quantity tolerance range required by the OBD system to
enable any other OBD monitors.
    Glow plugs and intake air heater systems would also have to be
monitored for proper functional response to computer commands and for
malfunctions associated with circuit continuity. The glow plug and
intake air heater circuit(s) would have to be monitored for proper
current and voltage drop. The manufacturer may use other monitoring
strategies by submitting data and/or engineering analyses that
demonstrate that the strategy provides equally reliable and timely
detection of malfunctions. In general, the OBD system would have to
detect a malfunction when a single glow plug no longer operates within
the manufacturer's specified limits for normal operation. If a
manufacturer demonstrates that a single glow plug malfunction cannot
cause a measurable increase in emissions during any reasonable driving
condition, the OBD system must detect a malfunction for the minimum
number of glow plugs needed to cause an emissions increase. Further, to
the extent feasible without adding additional hardware for this
purpose, the stored DTC must identify the specific malfunctioning glow
plug(s).
    Lastly, the wait-to-start lamp circuit and the MIL circuit would
have to be monitored for malfunctions that cause either lamp to fail to
illuminate when commanded on (e.g., burned out bulb).
c. Comprehensive Component Monitoring Conditions
i. Input Components
    We are proposing that input components be monitored continuously
for circuit continuity and for providing values within the proper
range. For rationality monitoring, where applicable, manufacturers
would define the monitoring conditions for detecting malfunctions in
accordance with the general monitoring conditions for all engines
described in section II.A.3 and the minimum performance ratio
requirements described in section II.E except that rationality
monitoring would have to occur every time the monitoring conditions are
met during the drive cycle rather than once per drive cycle as required
in section II.A.3.
    A manufacturer may disable continuous monitoring for circuit
continuity, and for providing values within the proper range, when a

malfunction cannot be distinguished from other effects. To do so, the
manufacturer would have to submit data and/or engineering analyses that
demonstrate that a properly functioning input component cannot be
distinguished from a malfunctioning input component and that the
disablement interval is limited only to that necessary for avoiding
false detection.
ii. Output Components/Systems
    We are proposing that output components/systems be monitored
continuously for circuit continuity. For functional monitoring,
manufacturers would define the monitoring conditions for detecting
malfunctions in accordance with the general monitoring conditions for
all engines described in section II.A.3 and the minimum performance
ratio requirements described in section II.E.
    For the idle control system, we are proposing that manufacturers
define the monitoring conditions for functional monitoring in
accordance with the general monitoring conditions for all engines
described in section II.A.3 and the minimum performance ratio
requirements described in section II.E except that functional
monitoring would have to occur every time the monitoring conditions are
met during the drive cycle rather than once per drive cycle as required
in section II.A.3.
    A manufacturer may disable continuous monitoring for circuit
continuity when a malfunction cannot be distinguished from other
effects. To do so, the manufacturer would have to submit data and/or
engineering analyses that demonstrate that a properly functioning
output component cannot be distinguished from a malfunctioning output
component and that the disablement interval is limited only to that
necessary for avoiding false detection.
d. Comprehensive Component MIL Illumination and DTC Storage
    With a couple of exceptions, we are proposing the general
requirements for MIL illumination and DTC storage as discussed in
section II.A.2. The exceptions to this being that MIL illumination
would not be required in conjunction with storing a MIL-on DTC for any
comprehensive component if: (a) The component or system, when
malfunctioning, could not cause engine emissions to increase by 15
percent or more of the FTP standard during any reasonable driving
condition; and, (b) the component or system is not used as part of the
diagnostic strategy for any other monitored system or component. MIL
illumination is also not required if a malfunction has been detected in
the MIL circuit that prevents the MIL from illuminating (e.g., burned
out bulb or light emitting diode (LED)). However, the electronic MIL
status must be reported as ``commanded on'' and a MIL-on DTC would have
to be stored.
5. Other Emissions Control System Monitoring
a. Background
    As noted above, the primary purpose of OBD is to detect
malfunctions in the engine and/or emissions control system. Therefore,
we are proposing that manufacturers be required to submit to the
Administrator a monitoring plan for any new engine and/or emissions
control technology not otherwise described above. Such technology might
include hydrocarbon traps or homogeneous charge compression ignition
(HCCI) systems. This would allow manufacturers and EPA to evaluate the
new technology and determine an appropriate level of monitoring that
would be both technologically feasible and consistent with the
monitoring requirements for the other emissions control devices
described above.
    As proposed, the Administrator would provide guidance as to what
type of components would fall under the ``other emissions control
system'' requirements and which would fall under the comprehensive
component requirements. Specifically, we are concerned that uncertainty
may arise for those emission control components or systems that also
meet the definition of electronic engine components. As such, the
proposal would delineate the two by requiring components/systems that
fit both definitions but are not corrected or compensated for by the
adaptive fuel control system to be monitored as ``other emissions
control devices'' rather than as comprehensive components. A typical
device that would fall under this category instead of the comprehensive
components category because of this delineation would be a swirl
control valve system. Such delineation is necessary because such
emissions control components generally require more thorough monitoring
than comprehensive components to ensure low emissions levels throughout
an engine's life. Further, emissions control components that are not
compensated for by the fuel control system as they age or deteriorate
can have a larger impact on tailpipe emissions than is typical of
comprehensive components that are corrected for by the fuel control
system as they deteriorate.
    Note that the Administrator does not foresee any outcome where a
promising new emissions control technology would be prohibited based
solely on the lack of an OBD monitoring strategy for it. Instead, we
want to instill in manufacturers the need to consider OBD monitoring
when developing any new emissions control technology. Further, we want
to instill in manufacturers the sense that an OBD monitoring strategy
will, one day, be necessary so a plan for such should exist prior to
introducing the technology on new products.
b. Other Emissions Control System Monitoring Requirements/Conditions
    We are proposing that, for other emission control systems that are:
(1) Not identified or addressed in sections II.B through II.D.4--e.g.,
hydrocarbon traps, HCCI control systems; or, (2) identified or
addressed in section II.D.4 but not corrected or compensated for by an
adaptive control system--e.g., swirl control valves, manufacturers
would be required to submit a plan for Administrator approval of the
monitoring strategy, the malfunction criteria, and the monitoring
conditions prior to introduction on a production engine. Administrator
approval of the plan would be based on the effectiveness of the
monitoring strategy, the robustness of the malfunction criteria, and
the frequency of meeting the necessary monitoring conditions.
    We are also proposing that, for engines that use emissions control
systems that alter intake air flow or cylinder charge characteristics
by actuating valve(s), flap(s), etc., in the intake air delivery system
(e.g., swirl control valve systems), the manufacturers, in addition to
meeting the requirements above, may elect to have the OBD system
monitor the shaft to which all valves in one intake bank are physically
attached rather than monitoring the intake air flow, cylinder charge,
or individual valve(s)/flap(s) for proper functional response. For non-
metal shafts or segmented shafts, the monitor must verify all shaft
segments for proper functional response (e.g., by verifying the segment
or portion of the shaft furthest from the actuator functions properly).
For systems that have more than one shaft to operate valves in multiple
intake banks, manufacturers are not required to add more than one set
of detection hardware (e.g., sensor, switch) per intake bank to meet
this requirement.

6. Exceptions to Monitoring Requirements
a. Background
    Under some conditions, the reliability of specific monitors may be
diminished significantly. Therefore, we are proposing to allow
manufacturers to disable the affected monitors when these conditions
are encountered in-use. These include situations of extreme conditions
(e.g., very low ambient temperatures, high altitudes) and of periods
where default modes of operation are active (e.g., when a tire pressure
problem is detected). In some of these cases, we may allow
manufacturers to revise the emission malfunction threshold to ensure
the most reliable monitoring performance.
b. Requirements for Exceptions to Monitoring
    The Administrator may revise the emission threshold for any
monitor, or revise the PM filtering performance malfunction criteria
for DPFs to exclude detection of specific failure modes such as
partially melted substrates, if the most reliable monitoring method
developed requires a higher threshold or, in the case of PM filtering
performance, the exclusion of specific failure modes, to prevent
significant errors of commission in detecting a malfunction. The
Administrator would notify the industry of any such revisions to ensure
that all manufacturers would be able to implement OBD on an equal
basis. In other words, we would not allow one manufacturer to revise a
specific monitoring threshold upwards while insisting that another meet
the proposed threshold.
    Manufacturers may disable an OBD system monitor at ambient engine
start temperatures below 20 degrees Fahrenheit (low ambient temperature
conditions may be determined based on intake air or engine coolant
temperature at engine start) or at elevations higher than 8000 feet
above sea level. To do so, the manufacturer would have to submit data
and/or engineering analyses that demonstrate that monitoring would be
unreliable during the disable conditions. A manufacturer may request
that an OBD system monitor be disabled at other ambient engine start
temperatures by submitting data and/or engineering analyses
demonstrating that misdiagnosis would occur at the given ambient
temperatures due to their effect on the component itself (e.g.,
component freezing).
    Manufacturers may disable an OBD system monitor when the fuel level
is 15 percent or less of the nominal fuel tank capacity for those
monitors that can be affected by low fuel level or running out of fuel
(e.g., misfire detection). To do so, the manufacturer would have to
submit data and/or engineering analyses that demonstrate that both
monitoring at the given fuel levels would be unreliable, and the OBD
system is still able to detect a malfunction if the component(s) used
to determine fuel level indicates erroneously a fuel level that causes
the disablement.
    Manufacturers may disable OBD monitors that can be affected by
vehicle battery or system voltage levels. For an OBD monitor affected
by low vehicle battery or system voltages, manufacturers may disable
monitoring when the battery or system voltage is below 11.0 Volts.
Manufacturers may use a voltage threshold higher than 11.0 Volts to
disable monitors but would have to submit data and/or engineering
analyses that demonstrate that monitoring at those voltages would be
unreliable and that either operation of a vehicle below the disablement
criteria for extended periods of time is unlikely or the OBD system
monitors the battery or system voltage and would detect a malfunction
at the voltage used to disable other monitors.
    For monitoring systems affected by high vehicle battery or system
voltages, manufacturers may disable monitoring when the battery or
system voltage exceeds a manufacturer-defined voltage. To do so, the
manufacturer would have to submit data and/or engineering analyses that
demonstrate that monitoring above the manufacturer-defined voltage
would be unreliable and that either the electrical charging system/
alternator warning light would be illuminated (or voltage gauge would
be in the ``red zone'') or the OBD system monitors the battery or
system voltage and would detect a malfunction at the voltage used to
disable other monitors.
    A manufacturer may also disable affected OBD monitors in vehicles
designed to accommodate the installation of power take off (PTO) units
provided disablement occurs only while the PTO unit is active and the
OBD readiness status is cleared by the onboard computer (i.e., all
monitors set to indicate ``not complete'') while the PTO unit is
activated (see section II.F.4 below). If the disablement occurs, the
readiness status may be restored, when the disablement ends, to its
state prior to PTO activation.

E. A Standardized Method To Measure Real World Monitoring Performance

    As was noted in section II.A.3, manufacturers determine the most
appropriate times to run the non-continuous OBD monitors. This way,
they are able to make their OBD evaluation either at the operating
condition when an emissions control system is active and its
operational status can best be evaluated, and/or at the operating
condition when the most accurate evaluation can be made (e.g., highly
transient conditions or extreme conditions can make evaluation
difficult). Importantly, manufacturers are prohibited from using a
monitoring strategy that is so restrictive such that it rarely or never
runs. To help protect against monitors that rarely run, we are
proposing an ``in-use monitor performance ratio'' requirement as
described here.
    The set of operating conditions that must be met so that an OBD
monitor can run are called the ``enable criteria'' for that given
monitor. These enable criteria are often different for different
monitors and may well be different for different types of engines. A
large diesel engine intended for use in a Class 8 truck would be
expected to see long periods of relatively steady-state operation while
a smaller engine intended for use in an urban delivery truck would be
expected to see a lot of transient operation. Manufacturers will need
to balance between a rather loose set of enable criteria for their
engines and vehicles given the very broad range of operation HD highway
engines see and a tight set of enable criteria given the desire for
greater monitor accuracy. Manufacturers would be required to design
these enable criteria so that the monitor:
     Is robust (i.e., accurate at making pass/fail decisions);
     Runs frequently in the real world; and,
     In general, also runs during the FTP heavy-duty transient
cycle.
    If designed incorrectly, these enable criteria may be either too
broad and result in inaccurate monitors, or overly restrictive thereby
preventing the monitor from executing frequently in the real world.
    Since the primary purpose of an OBD system is to monitor for and
detect emission-related malfunctions while the engine is operating in
the real world, a standardized methodology for quantifying real world
performance would be beneficial to both EPA and manufacturers.
Generally, in determining whether a manufacturer's monitoring
conditions are sufficient, a manufacturer would discuss the proposed
monitoring conditions with EPA staff. The finalized conditions would be
included in the certification applications and submitted to EPA staff
who would review the conditions and make determinations on a case-by-
case

basis based on the engineering judgment of the staff. In cases where we
are concerned that the documented conditions may not be met during
reasonable in-use driving conditions, we would most likely ask the
manufacturer for data or other engineering analyses used by the
manufacturer to determine that the conditions would occur in-use. In
proposing a standardized methodology for quantifying real world
performance, we believe this review process can be done more
efficiently than would occur otherwise. Furthermore, it would serve to
ensure that all manufacturers are held to the same standard for real
world performance. Lastly, we want review procedures that will ensure
that monitors operate properly and frequently in the field.
    Therefore, we are proposing that all manufacturers be required to
use a standardized method for determining real world monitoring
performance and to hold manufacturers liable if monitoring occurs less
frequently than a minimum acceptable level, expressed as minimum
acceptable in-use performance ratio. We are also proposing that
manufacturers be required to implement software in the onboard computer
to track how often several of the major monitors (e.g., catalyst, EGR,
CDPF, other diesel aftertreatment devices) execute during real world
driving. The onboard computer would keep track of how many times each
of these monitors has executed and how much the engine has been
operated. By measuring both of these values, the ratio of monitor
operation relative to engine operation can be calculated to determine
monitoring frequency.
    The proposed minimum acceptable frequency requirement would apply
to many but not all of the OBD monitors. We are proposing that monitors
be required to operate either continuously, once per drive cycle, or,
in a few cases, multiple times per drive cycle (i.e., whenever the
proper monitoring conditions are present). For components or systems
that are more likely to experience intermittent failures or failures
that can routinely happen in distinct portions of an engine's operating
range (e.g., only at high engine speed and load, only when the engine
is cold or hot), monitors would be required to operate continuously.
Examples of continuous monitors include the fuel system monitor and
most electrical/circuit continuity monitors. For components or systems
that are less likely to experience intermittent failures or failures
that only occur in specific vehicle operating regions or for components
or systems where accurate monitoring can only be performed under
limited operating conditions, monitors would be required to run once
per drive cycle. Examples of once per drive cycle monitors typically
include gasoline catalyst monitors, evaporative system leak detection
monitors, and output comprehensive component functional monitors. For
components or systems that are routinely used to perform functions that
are crucial to maintaining low emissions but may still require
monitoring under fairly limited conditions, monitors would be required
to run each and every time the manufacturer-defined enable conditions
are present. Examples of multiple times per drive cycle monitors
typically include input comprehensive component rationality monitors
and some exhaust aftertreatment monitors.
    Monitors required to run continuously, by definition, would always
be running, thereby making a minimum frequency requirement moot. The
new frequency requirement would essentially apply only to those
monitors that are designated as once per drive cycle or multiple times
per drive cycle monitors. For all of these monitors, manufacturers
would be required to define monitoring conditions that ensure adequate
frequency in-use. Specifically, the monitors would need to run often
enough so that the measured monitor frequency on in-use engines would
exceed the minimum acceptable frequency. However, even though the
minimum frequency requirement would apply to nearly all once per drive
cycle and multiple times per drive cycle monitors, manufacturers would
only be required to implement software to track and report the in-use
frequency for a few of the major monitors. These few monitors generally
represent the major emissions control components and the ones with the
most limited enable criteria.
    We believe that OBD monitors should run frequently to ensure early
detection of emissions-related malfunctions and, consequently, to
maintain low emissions. Allowing malfunctions to continue undetected
and unrepaired for long periods of time allows emissions to increase
unnecessarily. Frequent monitoring can also help to ensure detection of
intermittent emissions-related malfunctions (i.e., those that are not
continuously present but occur sporadically for days and even weeks at
a time). The nature of mechanical and electrical systems is that
intermittent malfunctions can and do occur. The less frequent the
monitoring, the less likely these malfunctions will be detected and
repaired. Additionally, for both intermittent and continuous
malfunctions, earlier detection is equivalent to preventative
maintenance in that the original malfunction can be detected and
repaired prior to it causing subsequent damage to other components.
This can help vehicle operators avoid more costly repairs that could
have resulted had the first malfunction gone undetected.
    Infrequent monitoring can also have an impact on the service and
repair industry. Specifically, monitors that have unreasonable or
overly restrictive enable conditions could hinder vehicle repair
services. In general, upon completing an OBD-related repair to an
engine, a technician will attempt to verify that the repair has indeed
fixed the problem. Ideally, a technician will operate the vehicle in a
manner that will exercise the appropriate OBD monitor and allow the OBD
system to confirm that the malfunction is no longer present. This
affords a technician the highest level of assurance that the repair was
indeed successful. However, OBD monitors that operate infrequently are
difficult to exercise and, therefore, technicians may not be able (or
may not be likely) to perform such post-repair evaluations. Despite the
service information availability requirements we are proposing--
requirements that manufacturers make all of their service and repair
information available to all technicians, including the information
necessary to exercise OBD monitors--technicians would still find it
difficult to exercise monitors that require infrequently encountered
engine operating conditions (e.g., abnormally steady constant speed
operation for an extended period of time). Additionally, to execute OBD
monitors in an expeditious manner or to execute monitors that would
require unusual or infrequently encountered conditions, technicians may
be required to operate the vehicle in an unsafe manner (e.g., at
freeway speeds on residential streets or during heavy traffic). If
unsuccessful in executing these monitors, technicians may even take
shortcuts in attempting to validate the repair while maintaining a
reasonable cost for customers. These shortcuts would likely not be as
thorough in verifying repairs and could increase the chance that
improperly repaired engines would be returned to the vehicle owner or
additional repairs would be performed just to ensure the problem is
fixed. In the end, monitors that operate less frequently can result in
unnecessary costs and inconvenience to both vehicle owners and
technicians.

1. Description of Software Counters to Track Real World Performance
    As stated above, manufacturers would be required to track monitor
peformance by comparing the number of monitoring events (i.e., how
often each monitor has run) to the number of driving events (i.e., how
often has the vehicle been operated). The ratio of these two numbers
would give an indication of how often the monitor is operating relative
to vehicle operation. In equation form, this can be stated as:
[GRAPHIC] [TIFF OMITTED] TP24JA07.004

    To ensure that all manufacturers are tracking in-use performance in
the same manner, we are proposing very detailed requirements for
defining and incrementing both the numerator and denominator of this
ratio. Manufacturers would be required to keep track of separate
numerators and denominators for each of the major monitors, and to
ensure that the data are saved every time the engine is shut off. The
numerators and denominators would be reset to zero only in extreme
circumstances when the non-volatile memory has been cleared (e.g., when
the onboard computer has been reprogrammed in the field or when the
onboard computer memory has been corrupted). The values would not be
reset to zero during normal occurrences such as clearing of stored DTCs
or performing routine service or maintenance.
    Further, the numerator and denominator would be structured such
that their maximum values would be 65,535 which is the maximum number
that can be stored in a 2-byte location. This would ensure that
manufacturers allocate sufficient and consistent memory space in the
onboard computer. If either the numerator or denominator for a
particular monitor reaches the maximum value, both values for that
particular monitor would be divided by two before counting resumes. In
general, the numerator and denominator would only be allowed to
increment a maximum of once per drive cycle because most of the major
monitors are designed to operate only once per drive cycle.
Additionally, incrementing of both the numerator and denominator for a
particular monitor would be disabled (i.e., paused but the stored
values would not be erased or reset) only when a problem has been
detected (i.e., a pending or MIL-on DTC has been stored) that prevents
the monitor from executing. Once the problem is no longer detected and
any stored DTCs associated with the problem have been erased, either
through the allowable self-clearing process or upon command by a
technician via a scan tool, incrementing of both the numerator and
denominator would resume.
    SAE has developed standards for storing and reporting the data to a
generic scan tool. This would help ensure that all manufacturers report
the data in an identical manner which should ease data collection in
the field.
a. Number of Monitoring Events (``Numerator'')
    For the numerator, manufacturers would be required to keep a
separate numeric count of how often each of the particular monitors has
operated. More specifically, manufacturers would have to implement a
software counter that increments by one every time the particular
monitor meets all of the enable/monitoring conditions for a long enough
period of time such that a malfunctioning component would have been
detected. For example, if a manufacturer requires a vehicle to be
warmed-up and at idle for 20 seconds continuously to detect a
malfunctioning catalyst, the catalyst monitor numerator could only be
incremented if the vehicle actually operates simultaneously in all of
those conditions. If the vehicle is operated in some but not all of the
conditions (e.g., at idle but not warmed-up), the numerator would not
be allowed to increment because the monitor would not have been able to
detect a malfunctioning catalyst since all of the conditions were not
satisfied simultaneously.
    Another complication is the difference between a monitor reaching a
``pass'' or ``fail'' decision. At first glance, it would appear that a
manufacturer should simply increment the numerator anytime the
particular monitor reaches a decision, be it ``pass'' or ``fail''.
However, monitoring strategies may have a different set of criteria
that must be met to reach a ``pass'' decision versus a ``fail''
decision. As a simple example, a manufacturer may appropriately require
only 10 seconds of operation at idle to reach a ``pass'' decision but
require 30 seconds of operation at idle to reach a ``fail'' decision.
Manufacturers would not be allowed to increment the numerator if the
vehicle had idled for 10 seconds and reached a ``pass'' decision since
insufficient time had passed to allow for a possible ``fail'' decision.
This is necessary because the primary function of OBD systems is to
detect malfunctions (i.e., to correctly reach ``fail'' decisions, not
``pass'' decisions) and, thus, the real world ability of the monitors
to detect malfunctions is the parameter we want most to measure.
Therefore, monitors with different criteria to reach a ``pass''
decision versus a ``fail'' decision would not be allowed to increment
the numerator solely upon satisfying the ``pass'' criteria.
    The correct implementation of the numerator counters by
manufacturers is imperative to ensure a reliable measure for
determining real world performance. ``Overcounting'' would falsely
indicate the monitor is executing more often than it really is, while
``undercounting'' would make it appear as if the monitor is not running
as often as it really is. Manufacturers would be required to describe
their numerator incrementing strategy in their certification
documentation and to verify the proper performance of their strategy
during production vehicle evaluation testing.
b. Number of Driving Events (``Denominator'')
    We are also proposing that manufacturers separately track how often
the engine is operated. Basically, the denominator would be a counter
that increments by one each time the engine is operated. We are
proposing that the denominator counter be incremented by one only if
several criteria are satisfied during a single drive cycle. This allows
very short trips or trips during extreme conditions such as very cold
temperatures or very high altitude to be filtered out and excluded from
the count. This is appropriate because these are also conditions where
most OBD monitors are neither expected nor required to operate.
    Specifically, the denominator would be incremented if, on a single
key start, the following criteria were satisfied while ambient
temperature remained above 20 degrees Fahrenheit and altitude remained
below 8,000 feet:
     Minimum engine run time of 10 minutes;

     Minimum of 5 minutes, cumulatively, of operation at
vehicle speeds greater than 25 miles-per-hour for gasoline engines or
calculated load greater than 15 percent for diesel engines; and
     At least one continuous idle for a minimum of 30 seconds
encountered.
    We intend to work with industry to collect data during the first
few years of implementation and make any adjustments, if necessary, to
the criteria used to increment the denominator to ensure that the in-
use performance ratio provides a meaningful measure of in-use
monitoring performance.
2. Proposed Performance Tracking Requirements
a. In-use Monitoring Performance Ratio Definition
    For monitors required to meet the in-use performance tracking
requirements,\44\ we are proposing that the incrementing of numerators
and denominators and the calculation of the in-use performance ratio be
done in accordance with the following specifications.
---------------------------------------------------------------------------

    \44\ These monitors, as presented in section II.A.3, are, for
diesel engines: the NMHC catalyst, the CDPF system, the
NOX adsorber system, the NOX converting
catalyst system, and the boost system; and, for gasoline engines:
the catalyst, the evaporative system, and the secondary air system;
and, for all engines, the exhaust gas sensors, the EGR system, and
the VVT system.
---------------------------------------------------------------------------

    The numerator(s) would be defined as a measure of the number of
times a vehicle has been operated such that all monitoring conditions
necessary for a specific monitor to detect a malfunction have been
encountered. Except for systems using alternative statistical MIL
illumination protocols, the numerator is to be incremented by an
integer of one. The numerator(s) may not be incremented more than once
per drive cycle. The numerator(s) for a specific monitor would be
incremented within 10 seconds if and only if the following criteria are
satisfied on a single drive cycle:
     Every monitoring condition necessary for the monitor of
the specific component to detect a malfunction and store a pending DTC
has been satisfied, including enable criteria, presence or absence of
related DTCs, sufficient length of monitoring time, and diagnostic
executive priority assignments (e.g., diagnostic ``A'' must execute
prior to diagnostic ``B''). For the purpose of incrementing the
numerator, satisfying all the monitoring conditions necessary for a
monitor to determine that the component is passing may not, by itself,
be sufficient to meet this criteria.
     For monitors that require multiple stages or events in a
single drive cycle to detect a malfunction, every monitoring condition
necessary for all events to have completed must be satisfied.
     For monitors that require intrusive operation of
components to detect a malfunction, a manufacturer would be required to
request Administrator approval of the strategy used to determine that,
had a malfunction been present, the monitor would have detected the
malfunction. Administrator approval of the request would be based on
the equivalence of the strategy to actual intrusive operation and the
ability of the strategy to determine accurately if every monitoring
condition was satisfied as necessary for the intrusive event to occur.
     For the secondary air system monitor, the three criteria
above are satisfied during normal operation of the secondary air
system. Monitoring during intrusive operation of the secondary air
system later in the same drive cycle solely for the purpose of
monitoring may not, by itself, be sufficient to meet these criteria.
    The third bullet item above requires explanation. There may be
monitors, and there have been monitors in light-duty, designed to use
what could be termed a two stage or two step process. The first step is
usually a passive and/or short evaluation that can be used to ``pass''
a properly working component where ``pass'' refers to evaluating the
component and determining that it is not malfunctioning. The second
step is usually an intrusive and/or longer evaluation that is necessary
to ``fail'' a malfunctioning component or ``pass'' a component nearing
the point of failure. An example of such an approach might be an
evaporative leak detection monitor that uses an intrusive vacuum pull-
down/bleed-up evaluation during highway cruise conditions. If the
evaporative system is sealed tight, the monitor ``passes'' and is done
with testing for the given drive cycle. If the monitor senses a leak
close to the required detection limit, the monitor does not ``pass''
and an internal flag is stored that will trigger the second stage of
the test during the next cold start when a more accurate evaluation can
be conducted. On the next cold start, provided the internal flag is
set, an intrusive vacuum pull-down/bleed up monitor might be conducted
during engine idle a very short time after the cold start. This second
evaluation stage, being at idle and cold, gives a more accurate
indication of the evaporative system's integrity and provides for a
more accurate decision regarding the presence and size of a leak.
    In this example, the second stage of this monitor would run less
frequently in real use than the first stage since it is activated only
on those occasions where the first stage suggests that a leak may be
present (which most cars will not have). The rate-based tracking
requirements are meant to give a measure of how often a monitor could
detect a malfunction. To know the right answer, we need to know how
often the first stage is running and could ``fail'', thus triggering
the second stage, and then how often the second stage is completing. If
we track only the first stage, we would get a false indication of how
often the monitor could really detect a leak. But, if we track only the
second stage, most cars would never increment the counter since most
cars do not have leaks and would not trigger stage two.
    In considering this, we see two possible solutions: (1) Always
activate the second stage evaluation in which case there would be an
intrusive monitor being performed that does not really need to be
performed; or, (2) implement a ``ghost'' monitor that pretends that the
first stage evaluation triggers the second stage evaluation and then
also looks for when the second stage evaluation could have completed
had it been necessary. The third bullet item in the list above requires
that, if a manufacturer intends to implement a two stage monitor and
intends to implement such a ``ghost'' monitor as described here for
rate based tracking, approval must be sought for doing so to make sure
we agree that you are doing it correctly and properly.
    For monitors that can generate results in a ``gray zone'' or ``non-
detection zone'' (i.e., results that indicate neither a passing system
nor a malfunctioning system) or in a ``non-decision zone'' (e.g.,
monitors that increment and decrement counters until a pass or fail
threshold is reached), the manufacturer would be responsible for
incrementing the numerator appropriately. In general, the numerator
should not be incremented when the monitor indicates a result in the
``non-detection zone'' or prior to the monitor reaching a decision.
When necessary, the Administrator would consider data and/or
engineering analyses submitted by the manufacturer demonstrating the
expected frequency of results in the ``non-detection zone'' and the
ability of the monitor to determine accurately, had an actual
malfunction been present, whether or not the monitor would have
detected a malfunction instead of a result in the ``non-detection
zone.''

    For monitors that run or complete their evaluation with the engine
off, the numerator must be incremented either within 10 seconds of the
monitor completing its evaluation in the engine off state, or during
the first 10 seconds of engine start on the subsequent drive cycle.
    Manufacturers using alternative statistical MIL illumination
protocols for any of the monitors that require a numerator would be
required to increment the numerator(s) appropriately. The manufacturer
may be required to provide supporting data and/or engineering analyses
demonstrating both the equivalence of their incrementing approach to
the incrementing specified above for monitors using the standard MIL
illumination protocol, and the overall equivalence of their
incrementing approach in determining that the minimum acceptable in-use
performance ratio has been satisfied.
    Regarding the denominator(s), defined as a measure of the number of
times a vehicle has been operated, we are proposing that it also be
incremented by an integer of one. The denominator(s) may not be
incremented more than once per drive cycle. The general denominator and
the denominators for each monitor would be incremented within 10
seconds if and only if the following criteria are satisfied on a single
drive cycle during which ambient temperature remained at or above 20
degrees Fahrenheit and altitude remained below 8,000 feet:
     Cumulative time since the start of the drive cycle is
greater than or equal to 600 seconds (10 minutes);
     Cumulative gasoline engine operation at or above 25 miles
per hour or diesel engine operation at or above 15 percent calculated
load, either of which occurs for greater than or equal to 300 seconds
(5 minutes); and
     Continuous engine operation at idle (e.g., accelerator
pedal released by driver and vehicle speed less than or equal to one
mile per hour) for greater than or equal to 30 seconds.
    In addition to the requirements above, the evaporative system
monitor denominator(s) must be incremented if and only if:
     Cumulative time since the start of the drive cycle is
greater than or equal to 600 seconds (10 minutes) while at an ambient
temperature of greater than or equal to 40 degrees Fahrenheit but less
than or equal to 95 degrees Fahrenheit; and
     Engine cold start occurs with engine coolant temperature
at engine start greater than or equal to 40 degrees Fahrenheit but less
than or equal to 95 degrees Fahrenheit and less than or equal to 12
degrees Fahrenheit higher than ambient temperature at engine start.
    In addition to the requirements above, the denominator(s) for the
following monitors must be incremented if and only if the component or
strategy is commanded ``on'' for a time greater than or equal to 10
seconds:
     Gasoline secondary air system;
     Cold start emission reduction strategy;
     Components or systems that operate only at engine start-up
(e.g., glow plugs, intake air heaters) and are subject to monitoring
under ``other emission control systems'' (section II.D.5) or
comprehensive component output components (see section II.D.4).
    For purposes of determining this commanded ``on'' time, the OBD
system may not include time during intrusive operation of any of the
components or strategies later in the same drive cycle solely for the
purposes of monitoring.
    In addition to the requirements above, the denominator(s) for the
monitors of the following output components (except those operated only
at engine start-up as outlined above) must be incremented if and only
if the component is commanded to function (e.g., commanded ``on'',
``open'', ``closed'', ``locked'') two or more times during the drive
cycle or for a time greater than or equal to 10 seconds, whichever
occurs first:
     Variable valve timing and/or control system
     ``Other emission control systems''
     Comprehensive component (output component only, e.g.,
turbocharger waste-gates, variable length manifold runners)
    For monitors of the following components, the manufacturer may use
alternative or additional criteria to that set forth above for
incrementing the denominator. To do so, the manufacturer would need to
be able to demonstrate that the criteria would be equivalent to the
criteria outlined above at measuring the frequency of monitor operation
relative to the amount of engine operation:
     Engine cooling system input components (section II.D.2)
     ``Other emission control systems'' (section II.D.5)
     Comprehensive component input components that require
extended monitoring evaluation (section II.D.4, e.g., stuck fuel level
sensor rationality)
    For monitors of the following components or other emission controls
that experience infrequent regeneration events, the manufacturer may
use alternative or additional criteria to that set forth above for
incrementing the denominator. To do so, the manufacturer would need to
demonstrate that the criteria would be equivalent to the criteria
outlined above at measuring the frequency of monitor operation relative
to the amount of engine operation:
     Oxidation catalysts
     Diesel particulate filters
    For hybrid engine systems, engines that employ alternative engine
start hardware or strategies (e.g., integrated starter and generators),
or alternative fueled engines (e.g., dedicated, bi-fuel, or dual-fuel
applications), the manufacturer may request Administrator approval to
use alternative criteria to that set forth above for incrementing the
denominator. In general, approval would not be given for alternative
criteria that only employ engine shut off at or near idle/vehicle
stationary conditions. Approval of the alternative criteria would be
based on the equivalence of the alternative criteria at determining the
amount of engine operation relative to the measure of conventional
engine operation in accordance with the criteria above.
    The numerators and denominators may need to be disabled at some
times. To do this, within 10 seconds of a malfunction being detected
(i.e., a pending, MIL-on, or active DTC being stored) that disables a
monitor required to meet the performance tracking requirements,\45\ the
OBD system must disable further incrementing of the corresponding
numerator and denominator for each monitor that is disabled. When the
malfunction is no longer detected (e.g., the pending DTC is erased
through self-clearing or through a scan tool command), incrementing of
all corresponding numerators and denominators should resume within 10
seconds. Also, within 10 seconds of the start of a power takeoff unit
(PTO) that disables a monitor required to meet the performance tracking
requirements, the OBD system should disable further incrementing of the
corresponding numerator and denominator for each monitor that is
disabled. When the PTO operation ends, incrementing of all
corresponding numerators and denominators should resume within 10
seconds. The OBD system must disable further incrementing of all
numerators

and denominators within 10 seconds if a malfunction has been detected
in any component used to determine if: vehicle speed/calculated load;
ambient temperature; elevation; idle operation; engine cold start; or,
time of operation has been satisfied, and the corresponding pending DTC
has been stored. Incrementing of all numerators and denominators should
resume within 10 seconds when the malfunction is no longer present
(e.g., pending DTC erased through self-clearing or by a scan tool
command).
---------------------------------------------------------------------------

    \45\ These monitors, as presented in section II.A.3, are, for
diesel engines: the NMHC catalyst, the CDPF system, the
NOX adsorber system, the NOX converting
catalyst system, and the boost system; and, for gasoline engines:
the catalyst, the evaporative system, and the secondary air system;
and, for all engines, the exhaust gas sensors, the EGR system, and
the VVT system.
---------------------------------------------------------------------------

    The in-use performance monitoring ratio itself is defined as the
numerator for the given monitor divided by the denominator for that
monitor.
b. Standardized Tracking and Reporting of Monitor Performance
    We are proposing that the OBD system separately report an in-use
monitor performance numerator and denominator for each of the following
components:
     For diesel engines: NMHC catalyst bank 1, NMHC catalyst
bank 2, NOX catalyst bank 1, NOX catalyst bank 2,
exhaust gas sensor bank 1, exhaust gas sensor bank 2, EGR/VVT system,
DPF system, turbo boost control system, and the NOX
adsorber. The OBD system must also report a general denominator and an
ignition cycle counter in the standardized format discussed below and
in section II.F.5.
     For gasoline engines: catalyst bank 1, catalyst bank 2,
oxygen sensor bank 1, oxygen sensor bank 2, evaporative leak detection
system, EGR/VVT system, and secondary air system. The OBD system must
also report a general denominator and an ignition cycle counter in the
standardized format specified below and in section II.F.5.
    The OBD system would be required to report a separate numerator for
each of the components listed in the above bullet lists. For specific
components or systems that have multiple monitors that are required to
be reported under section II.B--e.g., exhaust gas sensor bank 1 may
have multiple monitors for sensor response or other sensor
characteristics--the OBD system should separately track numerators and
denominators for each of the specific monitors and report only the
corresponding numerator and denominator for the specific monitor that
has the lowest numerical ratio. If two or more specific monitors have
identical ratios, the corresponding numerator and denominator for the
specific monitor that has the highest denominator should be reported
for the specific component. The numerator(s) must be reported in
accordance with the specifications in section II.F.5.
    The OBD system would also be required to report a separate
denominator for each of the components listed in the above bullet
lists. The denominator(s) must be reported in accordance with the
specifications in section II.F.5.
    Similarly, for the in-use performance ratio, determining which
corresponding numerator and denominator to report as required for
specific components or systems that have multiple monitors that are
required to be reported--e.g., exhaust gas sensor bank 1 may have
multiple monitors for sensor response or other sensor
characteristics'the ratio should be calculated in accordance with the
specifications in section II.F.5.
    The ignition cycle counter is defined as a counter that indicates
the number of ignition cycles a vehicle has experienced. The ignition
cycle counter must also be reported in accordance with the
specifications in section II.F.5. The ignition cycle counter, when
incremented, should be incremented by an integer of one. The ignition
cycle counter may not be incremented more than once per ignition cycle.
The ignition cycle counter should be incremented within 10 seconds if
and only if the engine exceeds an engine speed of 50 to 150 rpm below
the normal, warmed-up idle speed (as determined in the drive position
for vehicles equipped with an automatic transmission) for at least two
seconds plus or minus one second. The OBD system should disable further
incrementing of the ignition cycle counter within 10 seconds if a
malfunction has been detected in any component used to determine if
engine speed or time of operation has been satisfied and the
corresponding pending DTC has been stored. The ignition cycle counter
may not be disabled from incrementing for any other condition.
Incrementing of the ignition cycle counter should resume within 10
seconds after the malfunction is no longer present (e.g., pending DTC
erased through self-clearing or by a scan tool command).

F. Standardization Requirements

    The heavy-duty OBD regulation would include requirements for
manufacturers to standardize certain features of the OBD system.
Effective standardization assists all repair technicians in diagnosing
and repairing malfunctions by providing equal access to essential
repair information, and requires structuring the information in a
common format from manufacturer to manufacturer. Additionally, the
standardization would help to facilitate the potential use of OBD
checks in heavy-duty inspection and maintenance programs.
    Among the features that would be standardized under the proposed
heavy-duty OBD regulation include:
     The diagnostic connector, the computer communication
protocol;
     The hardware and software specifications for tools used by
service technicians;
     The information communicated by the onboard computer and
the methods for accessing that information;
     The numeric designation of the DTCs stored when a
malfunction is detected; and,
     The terminology used by manufacturers in their service
manuals.
    Our proposal would require that only a certain minimum set of
emissions-related information be made available through the
standardized format, protocol, and connector. We are not limiting
engine manufacturers as to what protocol they use for engine control,
communication between onboard computers, or communication to
manufacturer-specific scan tools or test equipment. Further, we are not
prohibiting engine manufacturers from equipping the vehicle with
additional diagnostic connectors or protocols as required by other
suppliers or purchasers. For example, fleets that use data logging or
other equipment that requires the use of SAE J1587 communication and
connectors could still be installed and supported by the engine and
vehicle manufacturers. The OBD rules would only require that engine
manufacturers also equip their vehicles with a specific connector and
communication protocol that meet the standardized requirements to
communicate a minimum set of emissions-related diagnostic, service and,
potentially, inspection information.
    Additionally, our proposal includes a phase-in of one engine family
meeting the requirements of OBD in the model years 2010 through 2012.
Because non-compliant engines would not require the proposed
standardization features, truck and coach builders could be faced with
several integration issues when building product in 2010 through 2012.
Specifically, they could be faced with designing their vehicles to
accommodate a standardized MIL, diagnostic connector, and communication
protocol when using a compliant engine yet to not accommodate those
features when using a non-compliant engine. This outcome could easily
arise since only one engine-family per manufacturer would be compliant
and, therefore, a given truck

designed to accommodate several engines from several engine
manufacturers would very likely need to accommodate a compliant engine
from manufacturer A and a non-compliant engine from manufacturer B. It
should be noted that engine choices are typically driven by the end
user--the truck buyer--and not by the truck or coach builder. For that
reason, the truck builder must accommodate all possible engines for the
truck size and cannot necessarily demand from the engine manufacturer a
compliant versus a non-compliant engine.
    As a result, rather than force truck and coach builders to
accommodate two different systems and risk incompatibilities, we are
proposing to exempt the 2010 through 2012 model year engines from
meeting certain standardization requirements of OBD. This should allow
truck and coach builders to integrate engines in the same manner as
done currently and then to switch over to integrating a single system
in 2013 when all engines are required to meet all of the
standardization requirements of OBD. The proposed implementation
schedule for standardization features is shown in Table II.G-2.
1. Reference Documents
    We are proposing that OBD systems comply with the following
provisions laid out in the following Society of Automotive Engineers
(SAE) and/or International Organization of Standards (ISO) documents
that are or would be incorporated by reference (IBR) into federal
regulation:

                          Table II.F--1. Reference Documents for Over 14,000 Pound OBD
----------------------------------------------------------------------------------------------------------------
       Document No.                    Document title                    Date                   Comment
----------------------------------------------------------------------------------------------------------------
SAE J1962.................  ``Diagnostic Connector--Equivalent   April 2002..........  Updated IBR.
                             to ISO/DIS 15031-3: December 14,
                             2001''.
SAE J1930.................  ``Electrical/Electronic Systems      April 2002..........  Updated IBR.
                             Diagnostic Terms, Definitions,
                             Abbreviations, and Acronyms--
                             Equivalent to ISO/TR 15031-2:
                             April 30, 2002''.
SAE J1978.................  ``OBD II Scan Tool--Equivalent to    April 2002..........  Updated IBR.
                             ISO/DIS 15031-4: December 14,
                             2001''.
SAE J1979.................  ``E/E Diagnostic Test Modes--        April 2002..........   Updated IBR.
                             Equivalent to ISO/DIS 15031-5:
                             April 30, 2002''.
SAE J2012.................  ``Diagnostic Trouble Code            April 2002..........  Updated IBR.
                             Definitions--Equivalent to ISO/DIS
                             15031-6: April 30, 2002''.
SAE J1939.................  ``Recommended Practice for a Serial  2005 Edition, March   Updated IBR.
                             Control and Communications Vehicle   2005.
                             Network,'' and the associated
                             subparts included in SAE HS-1939,
                             ``Truck and Bus Control and
                             Communications Network Standards
                             Manual''.
SAE J2403.................  ``Medium/Heavy-Duty E/E Systems      August 2004.........  New IBR.
                             Diagnosis Nomenclature''.
SAE J2534.................  ``Recommended Practice for Pass-     February 2002.......  New IBR.
                             Thru Vehicle Reprogramming''.
ISO 15765-4:2001..........  ``Road Vehicles--Diagnostics on      December 2001.......  New IBR.
                             Controller Area Network (CAN)--
                             Part 4: Requirements for emission-
                             related systems''.
----------------------------------------------------------------------------------------------------------------

    Copies of these SAE materials may be obtained from Society of
Automotive Engineers International, 400 Commonwealth Dr., Warrendale,
PA, 15096-0001. Copies of these ISO materials may be obtained from the
International Organization for Standardization, Case Postale 56, CH-
1211 Geneva 20, Switzerland.
2. Diagnostic Connector Requirements
    We are proposing that a standard data link connector conforming to
either SAE J1962 or SAE J1939-13 specifications (except as noted below)
would have to be included in each vehicle. The connector would have to
be located in the driver's side foot-well region of the vehicle
interior in the area bound by the driver's side of the vehicle and the
driver's side edge of the center console (or the vehicle centerline if
the vehicle does not have a center console) and at a location no higher
than the bottom of the steering wheel when in the lowest adjustable
position. The Administrator would not allow the connector to be located
on or in the center console (i.e., neither on the horizontal faces near
the floor-mounted gear selector, parking brake lever, or cup-holders,
nor on the vertical faces near the car stereo, climate system, or
navigation system controls). The location of the connector must be
easily identifiable and accessed (e.g., to connect an off-board tool).
For vehicles equipped with a driver's side door, the connector would
have to be easily identified and accessed by someone standing (or
``crouched'') on the ground outside the driver's side of the vehicle
with the driver's side door open.
    If a manufacturer wants to cover the connector, the cover must be
removable by hand without the use of any tools and be labeled ``OBD''
to aid technicians in identifying the location of the connector. Access
to the diagnostic connector could not require opening or removing any
storage accessory (e.g., ashtray, coinbox). The label would have to
clearly identify that the connector is located behind the cover and is
consistent with language and/or symbols commonly used in the automobile
and/or heavy truck industry.
    If the ISO 15765-4 protocol (see section II.F.3) is used for the
required OBD standardized functions, the connector would have to meet
the ``Type A'' specifications of SAE J1962. Any pins in the connector
that provide electrical power must be properly fused to protect the
integrity and usefulness of the connector for diagnostic purposes and
may not exceed 20.0 Volts DC regardless of the nominal vehicle system
or battery voltage (e.g., 12V, 24V, 42V).
    If the SAE J1939 protocol (see section II.F.3)) is used for the
required OBD standardized functions, the connector must meet the
specifications of SAE J1939-13. Any pins in the connector that provide
electrical power must be properly fused to protect the integrity and
usefulness of the connector for diagnostic purposes.
    Manufacturers would be allowed to equip engines/vehicles with
additional diagnostic connectors for manufacturer-specific purposes
(i.e., purposes other than the required OBD functions). However, if the
additional connector conforms to the ``Type A'' specifications of SAE
J1962 or the specifications of SAE J1939-13 and is located in the
vehicle interior near the required connector as described above, the
connector(s) must be clearly labeled to identify which connector is
used to access the standardized OBD information proposed below.

3. Communications to a Scan Tool
a. Background
    In light-duty OBD, manufacturers are allowed to use one of four
protocols for communication between a generic scan tool and the
vehicle's onboard computer. A generic scan tool automatically cycles
through each of the allowable protocols until it hits upon the proper
one with which to establish communication with the particular onboard
computer. While this has generally worked successfully in the field,
some communication problems have arisen.
    In an effort to address these problems, CARB has made recent
changes to their light-duty OBD II regulation that require all light-
duty vehicle manufacturers to use only one communication protocol by
the 2008 model year. In making these changes, CARB staff argued that
their experience with standardization under the OBD II regulation
showed that having a single set of standards used by all vehicles would
be desirable. CARB staff argued that a single protocol offers a
tremendous benefit to both scan tool designers and service technicians.
Scan tool designers could focus on added feature content and could
expend much less time and money validating basic functionality of their
product on all the various permutations of protocol interpretations
that are implemented. In turn, technicians would likely get a scan tool
that works properly on all vehicles without the need for repeated
software updates that incorporate ``work-arounds'' or other patches to
fix bugs or adapt the tool to accommodate slight variances in how the
multiple protocols interact with each other or are implemented by
various manufacturers. Further, a single protocol should also be
beneficial to fleet operators that use add-on equipment such as data
loggers, and for vehicle manufacturers that integrate parts from
various engine and component suppliers all of which must work together.
    Based on our similar experiences at the federal level with
communication protocols giving rise to service and inspection/
maintenance program issues, we initially wanted to propose a single
communication protocol for engines used in over 14,000 pound vehicles.
However, the affected industry has been divided over which single
protocol should be required and has strongly argued for more than one
protocol to be allowed. Therefore, for vehicles with diesel engines, we
are proposing that manufacturers be required to use either the
standards set forth in SAE J1939, or those set forth in the 500 kbps
baud rate version of ISO 15765. For vehicles with gasoline engines, we
are proposing that manufacturers be required to use the 500 kbps baud
rate version of ISO 15765. Manufacturers would be required to use only
one standard to meet all the standardization requirements on a single
vehicle; that is, a vehicle must use only one protocol for all OBD
modules on the vehicle.
    Several in the heavy-duty industry have argued for options that
would allow the use of more than these two protocols on heavy-duty
engines. Some have even argued for combinations of these protocols--
e.g., diagnostic connector and messages of ISO 15765 on an SAE J1939
physical layer network. However, as described above, experience from
multiple protocols and multiple variants within the protocols has
unnecessarily caused a significant number of problems with engine and
vehicle related computer communications.
b. Requirements for Communications to a Scan Tool
    We are proposing that all OBD control modules--e.g., engine,
auxiliary emission control module--on a single vehicle be required to
use the same protocol for communication of required emissions-related
messages from onboard to off-board network communications to a scan
tool meeting SAE J1978 specifications or designed to communicate with a
SAE J1939 network. Engine manufacturers would not be allowed to alter
normal operation of the engine emissions control system due to the
presence of off-board test equipment accessing the OBD information
proposed below. The OBD system would be required to use one of the
following standardized protocols:
     ISO 15765-4 and all required emission-related messages
using this protocol would have to use a 500 kbps baud rate.
     SAE J1939 which may only be used on vehicles with diesel
engines.
4. Required Emissions Related Functions
    Most of the proposed emissions related functions are elements that
exist in our light-duty OBD requirements. We are proposing several
required functions, these are:
     Readiness status
     Distance and number of warm-up cycles since DTC clear
     Permanent DTC storage
     Real time indication of monitor status
     Communicating readiness status to the vehicle operator
     Diagnostic trouble codes (DTC)
     Data stream
     Freeze frame
     Test results
     Software calibration identification
     Software calibration verification number
     Vehicle identification number (VIN)
i. Readiness Status
    The main intent of readiness status is to ensure that a vehicle is
ready for an OBD-based inspection--by indicating that monitors have run
and operational status of the emissions-control system has been fully
evaluated--and to prevent fraudulent testing in inspection programs. In
general, for OBD-based inspections, technicians ``fail'' a vehicle with
an illuminated MIL since this would indicate the presence of an
emissions control system malfunction. Without the readiness status
indicators, technicians would not have a clear indication from the OBD
system that it had sufficiently evaluated the emissions control system
prior to the inspection. Since the potential exists for OBD checks to
be used as part of a heavy truck inspection program, we believe that
having readiness status indicators as part of this proposal is
important--waiting for a subsequent OBD-I/M rulemaking to require such
indicators would unnecessarily delay implementation of such OBD-I/M
programs.
    Absent such OBD-I/M programs, we still believe that readiness
indicators are an important OBD tool. Technicians would be expected to
use the readiness status to verify OBD-related repairs. Specifically,
technicians would clear the computer memory after repairing an OBD-
detected fault in order to erase the DTC, extinguish the MIL, and reset
the readiness status to ``incomplete.'' Then the vehicle could be
operated in such a manner that the monitor of the repaired component
would run (i.e., the readiness status of the monitor would be set to
``complete''). The absence of any DTCs or MIL illumination upon
readiness status indicating ``complete'' would indicate a successful
repair.
    Therefore, we are proposing that manufacturers be required to
indicate the readiness status of the OBD monitors. This would serve to
indicate whether or not engine operation has been sufficient to allow
certain OBD monitors to perform their system evaluations. The OBD
system would be required to report a readiness status of either
``complete'' if the monitor has run a sufficient number of times to
detect a malfunction since computer memory was last cleared,
``incomplete'' if the monitor has not yet run a sufficient number of
times since the memory was last cleared, or ``not applicable'' if the

monitor is not present or if the specific monitored component is not
equipped on the vehicle. The readiness status of monitors that are
required to run continuously would always indicate ``complete.'' The
details of the proposal discussed below clarify that the readiness
status would be set to ``incomplete'' whenever memory is cleared either
by a battery disconnect or by a scan tool but not after a normal
vehicle shutdown (i.e., key-off).
ii. Distance Traveled and Number of Warm-Up Cycles Since DTC Clear
    As originally envisioned in our OBD-I/M rulemaking (61 FR 40940),
we intended to require that all readiness status indicators be set to
``complete'' prior to accepting a vehicle for I/M inspection. However,
it became clear that some vehicles were being rejected from inspection
for reasons beyond the driver's control. For example, a vehicle driven
in extreme ambient conditions would prohibit monitors from running and
setting readiness status indicators to ``complete.'' Also, a vehicle
repaired just prior to arriving at the inspection station may not have
been operated sufficiently to set the readiness status of the monitor
for the recently repaired component to ``complete.'' The driver of such
a vehicle would, in essence, be punished unintentionally for having
taken the time and expense to repair the vehicle just prior to the
inspection. As a result, we issued guidance (cite) to state inspectors
recommending that vehicles be accepted for I/M inspection provided two
or fewer readiness status indicators are ``incomplete.'' Note that most
light-duty gasoline vehicles--the bulk of the vehicle fleet facing OBD-
I/M checks--have only four monitors for which the readiness status
indicator is meaningful (all of their other monitors being continuous
monitors). However, there exists evidence that this policy is perhaps
accepting vehicles for I/M inspection that should not be accepted due
to unscrupulous clearing of DTCs and readiness status by people that
understand how to do so and then operate their vehicles just enough to
set the required minimum number of readiness indicators to
``complete.''
    As a result, we are proposing some additional features that should
better differentiate between vehicles that have been repaired recently
or have ``incomplete'' readiness indicators through circumstances
outside the driver's control, and those vehicles operated by drivers
that are attempting to fraudulently get through an OBD-based
inspection. We are proposing that the OBD system make available data
that would report the distance traveled or engine run time for those
engines that do not use vehicle speed information, and the number of
warm-up cycles since the fault memory was last cleared.\46\ By
combining these data with the readiness data, technicians or inspectors
would better be able to determine if ``incomplete'' readiness status
indicators or an extinguished MIL are due to unscrupulous memory
clearing or circumstances beyond the driver's control. For example, a
vehicle with several ``incomplete'' readiness indicators but with a
high distance traveled/engine run time and a high number of warm-up
cycles since the last clearing of fault memory would be unlikely to
have undergone a recent fault memory clearing for the purpose of
extinguishing the MIL prior to inspection. On the other hand, a vehicle
with only one or two ``incomplete'' readiness indicators and a very low
distance traveled/engine run time and a low number of warm-up cycles
since fault memory clearing should probably be rejected or failed at an
inspection. This would better allow an inspection program to be set up
to reject only those vehicles with recently cleared memories while
minimizing the chances of rejecting vehicles that driven such that
monitors rarely run whether by unique driver behaviors or extreme
ambient conditions.
---------------------------------------------------------------------------

    \46\ The fault memory being any DTCs, readiness status
indicators, freeze frame information, etc.
---------------------------------------------------------------------------

iii. Permanent Diagnostic Trouble Code Storage
    Consistent with the proposal for distance traveled/engine run time
and number of warm-up cycles, we are proposing a requirement to make it
much more difficult for a vehicle owner or technician to clear the
fault memory and erase all traces of a previously detected malfunction.
Current OBD systems on under 14,000 pound vehicles allow a technician
or vehicle owner to erase all DTCs and extinguish the MIL by issuing a
command from a generic scan tool or, in many cases, simply by
disconnecting the vehicle battery. This would set to ``incomplete'' the
readiness status indicators for all monitors and would remove all
record of the malfunction that had been detected.
    We are proposing that manufacturers be required to store in non-
volatile memory random access memory (NVRAM) a minimum of four MIL-on
DTCs that are, at present, commanding the MIL-on. These ``permanent''
DTCs would have to be stored in NVRAM at the end of every key cycle. By
requiring these permanent DTCs to be stored in NVRAM, one would not be
able to erase them simply by disconnecting the battery. Further,
manufacturers would not be allowed to design their OBD systems such
that these permanent DTCs could be erased by any generic or
manufacturer-specific scan tool command. Instead, the permanent DTCs
could be erased only via an OBD system self-clearing--i.e., upon
evaluating the component or system for which the permanent DTC has been
stored and detecting on sufficient drive cycles that the malfunction is
no longer present, the OBD system would erase the fault memory as
discussed in section II.A.2. Once this has occurred, the permanent DTC
stored in NVRAM would be erased also.
    The permanent DTCs should help if states choose to implement OBD-
based I/M programs for heavy trucks. A truck with readiness status
indicators for EGR and boost control set to ``incomplete'' and with
permanent DTCs stored for both EGR and boost control would quite
probably be a truck that should be rejected from inspection. The OBD
system on such a truck has almost certainly had its fault memory
cleared--via scan tool command or battery disconnect--which would set
the readiness indicators to ``incomplete'' and erase all MIL-on DTCs
but would still have permanent DTCs stored (only the OBD system itself
can erase permanent DTCs). Likewise, a truck with the same readiness
indicators set to ``incomplete'' and no permanent DTCs for those
monitors should almost certainly be accepted for inspection since the
lack of readiness is almost certainly due to circumstances outside the
driver's control.
    We believe that the permanent DTCs also provide advantages to
technicians attempting to repair a malfunction and prepare it for
subsequent inspection or proof of correction. The permanent DTC would
identify the specific monitor that would need to be exercised after
repair and prior to inspection to be sure that the malfunction has been
repaired. By combining this information with the vehicle manufacturer's
service information, technicians could identify the exact conditions
necessary to exercise the particular monitor. As such, technicians
could more effectively verify that the specific monitor (that monitor
having illuminated the MIL for which the repair has been done) has run
and confirmed that the malfunction no longer exists and the repair has
been made correctly. This should also reduce vehicle owner ``come-
backs'' for incomplete or ineffective repairs.

iv. Real Time Indication of Monitor Status
    We are also proposing provisions to make it easier for technicians
to prepare a vehicle for an inspection following a repair. These
provisions would require that the OBD system provide real time data
that indicate whether the necessary conditions are present currently to
set all of the readiness indicators to ``complete.'' These data would
indicate whether a particular monitor may still have an opportunity to
run on the current drive cycle or whether a condition has been
encountered that has disabled the monitor for the rest of the drive
cycle regardless of the driving conditions that might be encountered.
While these data would not provide technicians with the exact
conditions necessary to exercise the monitors (only service information
would provide such information), the date in combination with the
service information should assist technicians in verifying repairs and/
or preparing a vehicle for inspection. Technicians would be able to use
this information to identify when specific monitors have indeed
completed or to identify situations where they have overlooked one or
more of the enable criteria and need to check the service information
and try again.
v. Communicating Readiness Status to the Vehicle Operator
    As mentioned above, substantial feedback has been received from
OBD-based I/M programs throughout the U.S. Much of this feedback
pertains to the effect on vehicle owners caused by being rejected from
I/M inspection due to ``incomplete'' readiness status indicators. To
address this, some light-duty vehicle manufacturers requested that they
be allowed to communicate the vehicle's readiness status to the vehicle
owner directly without need of a scan tool. This would provide
assurance to the vehicle owner that their vehicle is ready for
inspection prior to taking the vehicle to the I/M station. We are
proposing that heavy-duty engine manufacturers be allowed to do the
same thing (this is a proposed option, not a proposed requirement). If
a manufacturer chooses to implement this option, though, they would be
required to do so in a standardized manner. On engines equipped with
this option, the owner would be able to initiate a self-check of the
readiness status, thereby greatly reducing the possibility of being
rejected at a roadside inspection.
vi. Diagnostic Trouble Codes (DTC)
    Malfunctions are reported by the OBD system and displayed on a scan
tool for service technicians in the form of diagnostic trouble codes
(DTCs). We are proposing that manufacturers be required to report all
emissions-related DTCs using a standardized format and to make them
accessible to all service technicians, including the independent
service industry. The reference document standards selected by the
manufacturer would define many generic DTCs to be used by all
manufacturers. In the rare circumstances that a manufacturer cannot
find within the reference documents a suitable DTC, a unique
``manufacturer-specific'' DTC could be used. However, such
manufacturer-specific DTCs are not as easily interpreted by the
independent service industry. Excessive use of manufacturer-specific
DTCs may increase the time and cost for vehicle repairs. Thus, we are
proposing to restrict the use of manufacturer-specific DTCs. If a
generic DTC suitable for a given malfunction cannot be found, the
manufacturer would be expected to pursue approval and addition of
appropriate generic DTCs into the reference documents; the intent being
to standardize as much information as possible.
    Additionally, we are proposing that the OBD system store DTCs that
are as specific as possible to identify the nature of the malfunction.
The intent being to provide service technicians with as detailed
information as possible to diagnose and repair vehicles in an efficient
manner. In other words, manufacturers should use separate DTCs for
every monitor where the monitor and repair procedure, or likely cause
of the failure, is different. Generally, a manufacturer would design an
OBD monitor that detects different root causes (e.g., sensor shorted to
ground or battery) for a malfunctioning component or system. We would
expect manufacturers to store a specific DTC such as ``sensor circuit
high input'' or ``sensor circuit low input'' rather than a general code
such as ``sensor circuit malfunction.'' Further, we expect
manufacturers to store different DTCs that distinguish circuit
malfunctions from rationality and functional malfunctions since the
root cause for each is different and, thus, the repair procedures may
be different.
    We are also proposing specific provisions for storage of pending
and MIL-on DTCs. These proposed provisions were discussed in section
II.A.2.
    We are also proposing requirements that would help to distinguish
between DTCs stored for malfunctions that are currently present and for
malfunctions that are no longer present. These requirements would apply
only to those engines using ISO 15765-4 as the communication protocol.
As described in section II.A.2, the OBD system would generally
extinguish the MIL if the malfunction responsible for the MIL
illumination has not been detected (i.e., the monitor runs and
determines that the malfunction no longer exists) on three subsequent
sequential drive cycles. However, a manufacturer would not be allowed
to erase the associated MIL-on DTC until 40 engine warm-up cycles have
occurred without again detecting the malfunction. So even though the
malfunction is no longer present and a MIL-on is not being commanded,
the DTC would still remain (termed a ``history'' code in the ISO
standard). Consequently, if another unrelated malfunction occurs and
results in a MIL-on, a new DTC would be stored along with the history
DTC. When trying to diagnose the OBD problem, technicians accessing DTC
information may have trouble distinguishing which DTC is responsible
for illuminating the MIL (i.e., which malfunction is present
currently), and thus could have trouble determining what exactly must
be repaired. Therefore, we are proposing this requirement for ISO
engines to help distinguish between DTCs stored for malfunctions that
are present and those that were present. Note that, for engines using
SAE J1939 as the communication protocol, such a distinction is already
provided for.
    Permanent DTCs would also need to be separately identified from the
other types of DTCs. Additionally, as described above, manufacturers
would be required to develop additional software routines to store and
erase permanent DTCs in NVRAM and to prevent erasure from any battery
disconnect or scan tool command.
vii. Data Stream/Freeze Frame/Test Results
    An important aspect of OBD is the ability of technicians to access
critical information from the onboard computer to diagnose and repair
emissions-related malfunctions. We believe that having access through
the diagnostic connector to real-time electronic information regarding
certain emissions critical components and systems would provide
valuable assistance for repairing vehicles properly. The availability
of real-time information would also provide assistance to technicians

responding to drivability complaints since the vehicle could be
operated within the necessary operating conditions and the technician
could see how various sensors and systems were acting. Similarly, fuel
economy complaints, loss of performance complaints, intermittent
problems, and others issues could also be addressed.
    We are proposing a number of data parameters that the OBD system
would be required to report to a generic scan tool. These parameters,
which would include information such as engine speed and exhaust gas
sensor readings, would allow technicians to understand how the vehicle
engine control system is functioning, either as the vehicle operates in
a service bay or during actual driving. They would also help
technicians diagnose and repair emission-related malfunctions by
allowing them to watch instantaneous changes in the values while
operating the vehicle.
    Some of the data parameters we are proposing are intended to assist
us in performing in-use testing of heavy-duty engines for compliance
with emissions standards. One of the parameters that manufacturers
would be required to report is the real-time status of the
NOX and PM ``not-to-exceed'' (NTE) control areas. The NTE
standards define a wide range of engine operating points where a
manufacturer must design the engine to be below a maximum emission
level. In theory, whenever the engine is operated within the speed and
load region defined as the NTE zone, emissions will be below the
required standards. However, within the NTE zone, manufacturers are
allowed, if justified on a case-by-case basis, to either modify the
time frame in which the standard must be met, and in the second case to
be exempted from the emission standards under specific conditions
(e.g., an NTE deficiency). Manufacturers can request two types of
modifications: first, a five percent limited testing region within
which no more than five percent of in-use operation is expected to
occur and, thus, no more than five percent of NTE emissions sampling
within that region can be compared to the NTE standard for a given
sampling event; and second, NTE deficiencies which are precisely
defined exemption conditions where compliance cannot be met due to
technical reasons or for engine protection. These regions and
conditions can be defined by directly measured signals or, in some
cases, by complicated modeled values calculated internally in the
engine computer. When conducting emissions testing of these engines,
knowing if the engine is inside the NTE zone--and subject to the NTE
standards--or is outside of the NTE zone or, perhaps, in an NTE limited
testing region or covered by an NTE deficiency is imperative. As our
in-use testing program requirements are written currently, we must post
process data to determine which data points were generated within a
compliance zone and which were generated within an exempted zone. Such
post processing, while possible, is inefficient, time consuming, and
resource intensive. Having the NTE zone data broadcast in real-time
over the engine's network would allow for a much more efficient use of
our resources.
    The specific parameters we are proposing for inclusion in the data
stream are, for gasoline engines: calculated load value, engine coolant
temperature, engine speed, vehicle speed, time elapsed since engine
start, absolute load, fuel level (if used to enable or disable any
other monitors), barometric pressure (directly measured or estimated),
engine control module system voltage, commanded equivalence ratio,
number of stored MIL-on DTCs, catalyst temperature (if directly
measured or estimated for purposes of enabling the catalyst
monitor(s)), monitor status (i.e., disabled for the rest of this drive
cycle, complete this drive cycle, or not complete this drive cycle)
since last engine shut-off for each monitor used for readiness status,
distance traveled/engine run time with a commanded MIL-on, distance
traveled/engine run time since fault memory last cleared, number of
warm-up cycles since fault memory last cleared, OBD requirements to
which the engine is certified (e.g., California OBD, EPA OBD, non-OBD)
and MIL status (i.e., commanded-on or commanded-off). And, for diesel
engines: calculated load (engine torque as a percentage of maximum
torque available at the current engine speed),\47\ driver's demand
engine torque (as a percentage of maximum engine torque), actual engine
torque (as a percentage of maximum engine torque), reference engine
maximum torque, reference maximum engine torque as a function of engine
speed (suspect parameter numbers (SPN) 539 through 543 defined in SAE
J1939 within parameter group number (PGN) 65251 for engine
configuration), engine coolant temperature, engine oil temperature (if
used for emission control or any OBD monitors), engine speed, time
elapsed since engine start, fuel level (if used to enable or disable
any other diagnostics), vehicle speed (if used for emission control or
any OBD monitors), barometric pressure (directly measured or
estimated), engine control module system voltage, number of stored MIL-
on DTCs, monitor status (i.e., disabled for the rest of this drive
cycle, complete this drive cycle, or not complete this drive cycle)
since last engine shut-off for each monitor used for readiness status,
distance traveled/engine run time with a commanded MIL-on, distance
traveled/engine run time since fault memory last cleared, number of
warm-up cycles since DTC memory last cleared, OBD requirements to which
the engine is certified (e.g., EPA OBD parent rating, EPA OBD child
rating, non-OBD), and MIL status (i.e., commanded-on or commanded-off).
Also for diesel engines, as discussed above, separate NOX
and PM NTE control area status (i.e., inside control area, outside
control area, inside manufacturer-specific NTE carve-out area, or
deficiency active area). Also, for all engines so equipped (and only
those so equipped): absolute throttle position, relative throttle
position, fuel control system status (e.g., open loop, closed loop),
fuel trim, fuel pressure, ignition timing advance, fuel injection
timing, intake air/manifold temperature, engine intercooler
(aftercooler) temperature, manifold absolute pressure, air flow rate
from mass air flow sensor, secondary air status (upstream, downstream,
or atmosphere), ambient air temperature, commanded purge valve duty
cycle/position, commanded EGR valve duty cycle/position, actual EGR
valve duty cycle/position, EGR error between actual and commanded, PTO
status (active or not active), redundant absolute throttle position
(for electronic throttle or other systems that utilize two or more
sensors), absolute pedal position, redundant absolute pedal position,
commanded throttle motor position, fuel rate, boost pressure,
commanded/target boost pressure, turbo inlet air temperature, fuel rail
pressure, commanded fuel rail pressure, DPF inlet pressure, DPF inlet
temperature, DPF outlet pressure, DPF outlet temperature, DPF delta
pressure, exhaust pressure sensor output, exhaust gas temperature
sensor output, injection control pressure, commanded injection control
pressure, turbocharger/turbine speed,

[[Continued on page 3249]]

]

[[pp. 3249-3298]] Control of Air Pollution From New Motor Vehicles and New Motor
Vehicle Engines; Regulations Requiring Onboard Diagnostic Systems on
2010 and Later Heavy-Duty Engines Used in Highway Applications Over
14,000 Pounds; Revisions to Onboard Diagnostic Requirements f[[Page 3249]]

[[Continued from page 3248]]

variable geometry turbo position, commanded variable geometry turbo
position, turbocharger compressor inlet temperature, turbocharger
compressor inlet pressure, turbocharger turbine inlet temperature,
turbocharger turbine outlet temperature, wastegate valve position, glow
plug lamp status, oxygen sensor output, air/fuel ratio sensor output,
NOX sensor output, and evaporative system vapor pressure.
---------------------------------------------------------------------------

    \47\ Note that, for purposes of the calculated load and torque
parameters for diesel engines, manufacturers would be required to
report the most accurate values that are calculated within the
applicable electronic control unit (e.g., the engine control
computer). ``Most accurate values,'' in this context, would be those
of sufficient accuracy, resolution, and filtering that they could be
used for the purpose of in-use emissions testing with the engine
still in a vehicle (e.g., using portable emissions measurement
equipment).
---------------------------------------------------------------------------

    We are also proposing requirements for storage of ``freeze frame''
information at the time a malfunction is detected and a DTC is stored.
The freeze frame provides the operating conditions of the vehicle at
the time of malfunction detection and the DTC associated with the data.
The parameters we are proposing for inclusion in the freeze frame are a
subset of the parameters listed above for the data stream. Note that
storage of only one freeze frame would be required. Manufacturers may
choose to store additional frames, provided that the required frame can
be read using a scan tool meeting SAE J1978 specifications or designed
to communicate with an SAE J1939 network.
    We are also proposing that the OBD system store the most recent
monitoring results for most of the major monitors. Manufacturers would
be required to store and make available to the scan tool certain test
information--i.e., the minimum and maximum values that should occur
during proper operation along with the actual test value--of the most
recent monitoring event. ``Passing'' systems would store test results
that are within the test limits, while ``failing'' systems would store
test results that are outside the test limits. The storage of test
results would assist technicians in diagnosing and repairing
malfunctions and would help distinguish between components that are
performing well below the malfunction thresholds from those that are
passing the malfunction thresholds marginally.
viii. Identification Numbers
    We are also proposing that manufacturers be required to report two
identification numbers related to the software and specific calibration
values in the onboard computer. The first item, Calibration
Identification Number (CAL ID), would identify the software version
installed in the onboard computer. Software is often changed following
production of the engine. These software changes often make changes to
the emissions control system or the OBD system. We are proposing that
these changes include a new CAL ID and that it be communicated via the
diagnostic connector to the scan tool. The second item, Calibration
Verification Number (CVN), would help to ensure that the current
software has not been corrupted, modified inappropriately, or otherwise
tampered with. Both CAL ID and CVN help ensure the integrity of the OBD
system. The CVN proposal would require manufacturers to develop
sophisticated software algorithms that would essentially be a self-
check calculation of all of the emissions-related software and
calibration values in the onboard computer and would return the result
of the calculation to a scan tool. If the calculated result did not
equal the expected result for that CAL ID, one would know that the
software had been corrupted or otherwise modified. The CVN result would
have to be made available at all times to a generic scan tool.
    We are also proposing that the Vehicle Identification Number (VIN)
be communicated via the diagnostic connector to a generic scan tool in
a standardized format. The VIN would be a unique number assigned by the
vehicle manufacturer to every vehicle built. The VIN is commonly used
for purposes of ownership and registration to uniquely identify every
vehicle. By requiring the VIN to be stored in the onboard computer and
available electronically to a generic scan tool, the possibility of a
fraudulent inspection (e.g., by plugging into a different vehicle than
an inspection citation was issued originally to generate a proof of
correction) would be minimized. Electronic access to this number would
also simplify the inspection process and reduce transcription errors
from manual data entry.
    We are proposing that the VIN be electronically stored in a control
module on the vehicle, but not that it necessarily be stored in the
engine control module. As long as the VIN is reported correctly and
according to the selected reference document standards, we consider it
irrelevant as to which control module (e.g., engine controller,
instrument cluster controller) contains the information. Further, we
are proposing that the ultimate responsibility would lie with the
engine manufacturer to ensure that every vehicle manufactured with one
of its engines satisfies this requirement. However, we would expect
that the physical task of implementing this requirement would likely be
passed from the engine manufacturer to the vehicle manufacturer via an
additional build specification. Thus, analogous to how the engine
manufacturer currently provides engine purchasers with detailed
specifications regarding engine cooling requirements, additional sensor
inputs, physical mounting specifications, weight limitations, etc., the
engine manufacturer would likely include an additional specification
dictating the need for the VIN to be made available electronically. It
would be left to each engine manufacturer to determine the most
effective method to achieve this, as long as the VIN requirement is
met. Some manufacturers may find it most effective to provide the
capability in the engine control module delivered with the engine
coupled with a mechanism for the vehicle manufacturer to program the
module with the VIN upon installation of the engine into an actual
vehicle. Others may find it more effective to require the vehicle
manufacturer to have the capability built into other modules installed
on the vehicle such as instrument cluster modules, etc. We are aware of
several current vehicles with engines from three different engine
manufacturers that already have the VIN available through engine-
manufacturer specific scan tools; this indicates that such arrangements
already exist in one form or another and that they are working.
5. In-Use Performance Ratio Tracking Requirements
    To separately report an in-use performance ratio for each
applicable monitor as discussed in sections II.B through II.D, we are
proposing that manufacturers be required to implement software
algorithms to report a numerator and denominator in the standardized
format specified below and in accordance with the specifications of the
reference documents listed in section II.F.1.
    For the numerator, denominator, general denominator, and ignition
cycle counter:
     Each number must have a minimum value of zero and a
maximum value of 65,535 with a resolution of one.
     Each number must be reset to zero only when a non-volatile
random access memory (NVRAM) reset occurs (e.g., reprogramming event)
or, if the numbers are stored in keep-alive memory (KAM), when KAM is
lost due to an interruption in electrical power to the control module
(e.g., battery disconnect). Numbers may not be reset to zero under any
other circumstances including when commanded to do so via a scan tool
command to clear DTCs or reset KAM.
     If either the numerator or denominator for a specific
component reaches the maximum value of 65,535 2, both
numbers should be divided by two before either is incremented again to
avoid overflow problems.

     If the ignition cycle counter reaches the maximum value of
65,535 2, the ignition cycle counter should rollover and
increment to zero on the next ignition cycle to avoid overflow
problems.
     If the general denominator reaches the maximum value of
65,535 2, the general denominator should rollover and
increment to zero on the next drive cycle that meets the general
denominator definition to avoid overflow problems.
     If an engine is not equipped with a component (e.g.,
oxygen sensor bank 2, secondary air system), the corresponding
numerator and denominator for that specific component should always be
reported as zero.
    For the in-use performance ratio:
     The ratio should have a minimum value of zero and a
maximum value of 7.99527 with a resolution of 0.000122.
     A ratio for a specific component should be considered to
be zero whenever the corresponding numerator is equal to zero and the
corresponding denominator is not zero.
     A ratio for a specific component should be considered to
be the maximum value of 7.99527 if the corresponding denominator is
zero or if the actual value of the numerator divided by the denominator
exceeds the maximum value of 7.99527.
    For engine run time tracking on all gasoline and diesel engines,
manufacturers would be required to implement software algorithms to
individually track and report in a standardized format the engine run
time while being operated in the following conditions:
     Total engine run time
     Total idle run time (with ``idle'' defined as accelerator
pedal released by driver, vehicle speed less than or equal to one mile
per hour, and PTO not active);
     Total run time with PTO active.
    Each of the above engine run time counters would have the following
numerical value specifications:
     Each numerical counter must be a four-byte value with a
minimum value of zero at a resolution of one minute per bit.
     Each numerical counter must be reset to zero only when a
nonvolatile memory reset occurs (e.g., a reprogramming event).
Numerical counters cannot be reset to zero under any other
circumstances including a scan tool (generic or enhanced) command to
clear DTCs or reset KAM.
     When any of the individual numerical counters reaches its
maximum value, all counters must be divided by two before any are
incremented again. This is meant to avoid overflow problems.
6. Exceptions to Standardization Requirements
    For alternative-fueled engines derived from a diesel-cycle engine,
we are proposing that the manufacturer be allowed to meet the
standardized requirements discussed in this section that are applicable
to diesel engines rather than meeting the requirements applicable to
gasoline engines.

G. Implementation Schedule, In-Use Liability, and In-Use Enforcement

1. Implementation Schedule and In-Use Liability Provisions
    Table II.G-1 summarizes the proposed implementation schedule for
the OBD monitoring requirements--i.e., the proposed certification
requirements and in-use liabilities. More detail regarding the
implementation schedule and liabilities can be found in the sections
that follow.

 Table II.G-1.--OBD Certification Requirements and In-use Liability for
Diesel Fueled and Gasoline Fueled Engines over 14,000 Pounds: Monitoring
                              Requirements
------------------------------------------------------------------------
                                        Certification
    Model year        Applicability      requirement    In-use liability
------------------------------------------------------------------------
2010-2012.........  Parent rating     Full liability    Full liability
                     within 1          to thresholds     to 2x
                     compliant         according to      thresholds. \c\
                     engine family.    certification
                     \a\               demonstration
                                       procedures. \b\
                    Child ratings     Certification     Liability to
                     within the        documentation     monitor and
                     compliant         only (i.e., no    detect as noted
                     engine family.    certification     in
                                       demonstration);   certification
                                       no liability to   documentation.
                                       thresholds.
                    All other engine  None............  None.
                     families and
                     ratings.
2013-2015.........  Parent rating     Full liability    Full liability
                     from 2010-2012    to thresholds     to 2x
                     and parent        according to      thresholds.
                     rating within 1-  certification
                     2 additional      demonstration
                     engine families.  procedures.
                    Child ratings     Full liability    Full liability
                     from 2010-2012    to thresholds     to 2x
                     and parent        but               thresholds.
                     ratings from      certification
                     any remaining     documentation
                     engine families   only.
                     or OBD
                     groups.\d\
                    Additional        Certification     Liability to
                     engine ratings.   documentation     monitor and
                                       only; no          detect as noted
                                       liability to      in
                                       thresholds.       certification
                                                         demonstration.
 2016-2018........  One rating from   Full liability    Full liability
                     1-3 engine        to thresholds     to thresholds.
                     families and/or   according to
                     OBD groups.       certification
                                       demonstration
                                       procedures.
                    Remaining         Full liability    Full liability
                     ratings.          to thresholds     to 2x
                                       but               thresholds.
                                       certification
                                       documentation
                                       only.
2019+.............  One rating from   Full liability    Full liability
                     1-3 engine        to thresholds     to thresholds.
                     families and/or   according to
                     OBD groups.       certification
                                       demonstration
                                       procedures.
                    Remaining         Full liability    Full liability
                     ratings.          to thresholds     to thresholds.
                                       but
                                       certification
                                       documentation
                                       only.
------------------------------------------------------------------------
Notes: (a) Parent and child ratings are defined in section II.G; which
  rating(s) serves as the parent rating and which engine families must
  comply is not left to the manufacturer, as discussed in section II.G.
  (b) The certification demonstration procedures and the certification
  documentation requirements are discussed in section VIII.B. (c) Where
  in-use liability to thresholds and 2x thresholds is noted,
  manufacturer liability to monitor and detect as noted in their
  certification documentation is implied. (d) OBD groups are groupings
  of engine families that use similar OBD strategies and/or similar
  emissions control systems, as described in the text.

    For the 2010 through 2012 model years, manufacturers would be
required to implement OBD on one engine family. All other 2010 through
2012 engine families would not be subject to any OBD requirements
unless otherwise required to do so (e.g., to demonstrate that SCR
equipped vehicles will not be operated without urea). For 2013,

manufacturers would be required to implement OBD on all engine
families.
    We are proposing this implementation schedule for several reasons.