Design of OBD function test on production vehicle (PVE)

. Production Vehicle Evaluation (PVE) test mainly verifies the functionality of OBD system. PVE J2 test needs to verify the diagnostic mechanism for all the diagnostic Trouble Codes (DTC). While the design of fault simulation method is one of the technical difficulties of the whole PVE test. Due to the late start of PVE in China, test methods and technical skills are inadequate. This paper elaborates the failure monitoring principle and diagnosis mechanism of OBD system in detail,systematically introduces the PVE methods and J1, J2, J3 test procedures, studies and analyses the types of OBD malfunction and various fault simulation methods,finally forms a set of PVE test specifications.


Introduction
Production vehicle evaluation (PVE) is a new certification requirement in the emission standard of CHINA 6 [1]. Facing to this strange test, domestic enterprises have few relevant test experience. Especially, for some manufactures, OBD system are developed by suppliers, causing to lack of technical understanding of OBD system control strategy. Meanwhile, PVE J2 need to simulate all malfunction of OBD system, requiring in-depth understanding of each diagnosis theory and fault simulation methods. Different enterprises adopt different OBD suppliers and control strategies. In addition, different ECU hardware and software make it impossible to form a unified test specification for PVE test. In this paper, the fault diagnosis mechanism, PVE test method and fault simulation method are deeply traveled to form a complete set of PVE test specifications.

OBD system
As a function test of OBD system, to master the PVE test requires a certain understanding of OBD system. The OBD system is an on-board diagnostic system embedded in a vehicle controller that constantly monitors all components that affect emission performance to ensure that vehicle emissions are maintained at acceptable levels throughout the life cycle. If an emission-related component failure is detected, the OBD system lights up a warning light on the vehicle's instrument to alert the driver and stores the corresponding fault code and fault information for service. In addition to the fault warning function, the OBD system provides the ability to read parameters of powertrain, exhaust system and VIN through external tools.
As early as 1970s, many manufacturers such as Volkswagen and General Motors began to develop their own engine diagnostic system. In 1988, SAE issued standardized vehicle diagnosis protocol. Nearly by 1991, CARB issued OBDI standard. After that to 1994-1996, CARB phase introduced OBDII standard, experienced the continuous revision in 2002, 2006, 2012, gradually formed today's widely used OBDII standard. The OBD related requirements of CHINA6 refer to the OBDII standard in the United States [2]. Europe began to form its own EOBD standard system from 2000, and after years of development and improvement, it has been getting closer to the American OBDII standard. [3][4] After continuous development, the OBD system defines the pending, confirmed and permanent fault codes, forming a set of complete fault diagnosis mechanism including monitoring conditions, activation threshold, fault code storage, MIL ON, fault recovery. Each component and system checks that it is functioning properly through its own diagnostic logic. Once a failure is detected, the OBD system will go through a series of steps until the MIL is turn on to alert the driver, as shown in Table 1.
According to the diagnostic logic, each fault code has its own monitoring activation condition and threshold. When the corresponding activation condition is happened. OBD system monitors it and checks the performance, functionality and rationality of parts and systems. When the corresponding threshold is reached, the failure generates the pending fault code and the MIL is not lit.If the fault is detected again in the next driving cycle, the MIL is on and a confirmed fault code, freeze frame, and permanent fault code are generated. On the other hand, if no fault is detected until the end of the next drive cycle, the system automatically clears the pending fault code. If the fault is not detected in the next three consecutive driving cycles, the MIL would be turned off and the permanent fault code would be cleared, but it needs 41 warm-up cycles to clear confirmed fault code. MIL and fault information can also be cleared using the scan tool, but permanent fault codes cannot.
According to the monitoring parameters of each malfunction, the OBD system determines whether the threshold value is exceeded and then reports the corresponding fault code. Some failure threshold is relatively simple to meet, such as rationality and circuit fault. However, some fault monitoring thresholds are relatively complicated, such as the failure of EGR system, fuel system and oxygen sensor. The OBD system must determine whether the deterioration and damage of the system and components cause the emission to exceed the standard limits. Experiments show that the catalytic converters, oxygen sensors and misfire faults during CHINA 5 will cause a 10-fold increase in the emission of pollutants. The specific diagnostic system requirements in OBDII, such as cold start emission reduction strategy, engine cooling system, EGR, fuel system and VVT, will cause 1-9 times increase of pollutants in NMHC, CO and NOx respectively. Therefore, it is one of the difficulties in calibration work of OBD control system to link the condition of vehicle and performance of components with vehicle emissions and to judge when failure leads to emission exceeding limit.

PVE certification procedure
Production vehicle evaluation (PVE) test is a new requirement for OBD certification in CHINA 6. Since the United States began to implement PVE test in 2002, it has gone through 17 years of development. The requirements of PVE in CHINA 6 basically refers to the relevant regulation of EPA and CARB. [5] CHINA 6 requires enterprises to conduct PVE certification according to the process shown in figure 1. Every year manufactures submit their test plan of PVE to system of VECC before the first of April, and at least three car models should be chosen to carry out the test. In principle, the tests of J1 and J3 should cover all newly added OBD families in the test year. When the test group of all families is less than three, it can be less than three models, but not less than the number of test group. PVE test consists of three parts: J1 standardized verification, J2 monitoring requirements verification, and J3 in-use monitoring performance verification. Among them, J1 test is mainly to verify that the vehicle can communicate with the scan tool normally and the OBD system can meet the relevant requirements of SAE J1979. The J2 test is to verify the mechanism of all OBD fault codes for the vehicle. That means OBD system should be able to detect faults, turn MIL on and store the corresponding confirmed and permanent fault codes. J3 test is primarily to collect in-use monitoring performance tracking ratio (IUPR).

J1 Standardized verification
As far as the overall PVE test is concerned, the J1 test is relatively simple. The operator only needs to run the static test of SAE j1699-3 software with the correct OBD communication interface device. It is important to note that most of diagnosis devices can be used for PVE J1 test, but some interface devices will cause to fail during testing due to the lack of protocol support. Therefore, the correct communication interface equipment is the necessary condition for the successful completion of J1 test. SAE j1699-3 protocol requires that the communication interface used in J1 test must support CAN, ISO9141, ISO14230, ISO15765, J1850VPW, J1850PWM and etc.
Test content of J1 has been fully embedded in SAE j1699-3 software. The operator only needs to follow the prompts of the software, such as starting, shutting off, disconnecting sensor, and gradually operate until the completion of all contents required by the software from 5.1 to 9.22. Finally, the software will automatically generate a report in the root directory.

J2 Monitoring requirements verification
J2 test is the most workload and the most difficult part of the whole PVE test. Every OBD fault code that lights the MIL should be verified, and how to implant the fault is the key of J2 test. The basic test flow for each fault code is shown in figure 2. Firstly, according to the simulation method of fault code, the vehicle is implanted with faults. The standard explicitly requires the use of hardware method rather than modified calibration for fault simulation. The vehicle then runs two separate driving cycles to check whether the vehicle stores the corresponding pending fault code, confirmation fault code, permanent fault code, and lights up the MIL. Each cycle stores the measurement record file. The driving cycle is the entire process of key on, start the engine, idling, running, shut down, and sleeping. Finally, the natural or passive cleaning method is selected to clean the permanent fault code of the vehicle.

J3 In-use monitoring performance verification
The J3 test requires the collection of in-use monitoring performance tracking ratio (IUPR) of in-use vehicles for 6-12 months after delivery. In addition, for one car model it is required to select samples of at least 15 vehicles. The sample vehicles must be maintained normally, free from abusive driving and overhauls, and meet the corresponding minimum denominator requirements. The method of data measurement is relatively simple,while the scanning tool is used to read the relevant diagnostic information through the vehicle OBD interface. The selection method of sample vehicle is the difficulty of J3 test, that is, how to ensure the validity and representative of data. Therefore, the sampling method of J3 test should use statistical method to collect a large number of OBD information of this model across the country, so as to form a normal distribution map of IUPR data, and then select distribution point on average in the figure to ensure the representative of J3 report data.

PVE malfunction simulating method
The fault simulation method shall be designed according to the diagnosis principle, activation condition and threshold value of each fault code. By manipulating equipment and tools to implant failure signals and driving to enters an effective monitoring condition, vehicle will automatically detect parameters exceed the fault threshold and generate fault code. So as to verify the circuit integrity, rationality and functionality of the monitoring components and subsystems of the OBD system.
The number of emission related fault codes of a traditional gasoline vehicle is around 200-350, while the number of fault codes of a hybrid vehicle is 2-3 times that of a traditional vehicle. Among them, malfunctions that directly affect the emission exceeding the limit account for 10%, and most of the fault codes are non-emission limit monitoring, which belongs to comprehensive components monitoring, such as the circuit fault of the sensor, rational check and functional fault of the output system. In PVE test, we tend to classify all fault codes according to the type of fault codes and the simulation method to improve the test efficiency.
According to the fault simulation method, fault codes can be divided into 8 categories, as shown in table 2. It is worth noting that nearly 30% of fault codes are not feasible that cannot be verified in PVE tests. Because the PVE test requires to simulated by hardware, but can not modify calibration for fault simulation. Meanwhile fault codes which verified during OBD demonstration certification and may cause damage to the vehicle or need to destroy the vehicle can apply for exemption from PVE test. For example, failure of security monitoring(torque monitoring P061A), internal failure of ECU hardware and software(chip power supply channel temperature fault P0634), air-fuel ratio closed-loop control self learning failure (P2177) which needs to modify the calibration, oil level sensor fault which needs to destroy the vehicle seat to cutoff wiring harness to simulation, etc.

a) Open Circuit
Open-circuit fault is refers to disconnection of the sensor or actuator, mainly involved inlet and exhaust VVT control circuit, oxygen sensor heating control circuit, fuel injector control circuit, the ignition coil driver stage, carbon tank ventilation, electronic throttle valve control circuit, turbo charge bypass valve control circuit and air flow control circuit, etc. In general, the simulation method is to remove the PIN bridge corresponding to the sensor or actuator control circuit on breakout box, as shown in figure 3. [6]For most circuit faults, the in-situ idling of the vehicle can satisfy the monitoring condition and then report the fault. Some fault codes may need to increase the engine speed or drive the vehicle to achieve the monitoring condition.

b) Short Circuit
Including malfunctions of short circuit to ground, short circuit to the power supply, two signals shortcut, involving the sensors and actuators such as the intake manifold pressure sensor, oxygen sensor signal lines, boost pressure sensor, high and low edge of fuel injector, intake the exhaust camshaft position sensor, knock sensor, etc. The simulation method is to short the sensor or actuator signal PIN with the corresponding "ground", "power" and "other signals" PIN through breakout box, as shown in figure 4.

c) Out of Range
Out of range or circuit high/low faults refer to the output voltage of sensor or actuator are less than or greater than the normal output signal, mainly related to oxygen sensor heating control circuit, intake air temperature sensor, coolant temperature sensor, electronic throttle position sensor, fuel pressure sensor, fuel tank pressure sensor, oil pump control circuit, VVT control circuit, the ignition coil control circuit, etc.
Generally, for circuit high and low faults, the voltage regulating box or the DC power supply should be used to output the voltage value exceeding the normal working range of the component to the corresponding signal PIN. This voltage signal should be received by the engine controller. Generally, the working range of the sensor is 0.2v-4.8v. When the voltage input value of the voltage regulator box exceeds 4.8v, the ECU will report the fault of the corresponding sensor with too high voltage.When the voltage input value of the voltage regulator box is lower than 0.2v, the ECU will report the fault of the corresponding voltage too low.
According to the current diagnostic logic, it is difficult for general suppliers to distinguish between circuit low/high and short circuit to ground/power fault. Therefore, the fault of circuit low can be simulated by short signal line to ground line, and the fault of circuit high can be simulated by short signal line to power line.

Rationality & range check faults
The rationality check faults mainly represent that signals of sensors is different from the reference signals unusually, and the controller determines that the signal of the input components is not reasonable, which mainly involves the rail pressure sensor, crankshaft position sensor, throttle position sensor, camshaft position sensor, intake air pressure sensor and so on. Functional failure mainly refers to the failure of output components/systems to make reasonable functional response to the controller, which mainly involves idle speed control system, catalyst heating, fuel system, crankcase ventilation system, etc. Faults such as signal slow response, stuck and unreasonable checksum can usually be simulated by resistors or signal generator implanting in the line of the sensor, as shown in FIG. 5. Based on failure activation parameters, driving vehicle reach the monitoring condition, adjusting the resistance value to cause signal exceeds the threshold value, and then the corresponding fault code is generated. General circuit fault belongs to continuous diagnosis, as long as the vehicle on power or idle can generate fault; But the activation condition of rationality and functional failure is relatively complex, the fault monitoring auxiliary parameters needs to be further studied to be able to interpret the suitable driving conditions for fault simulation. Recommended driving condition may be driving the vehicle reaches a certain speed, idling a certain time, soaking the car more than six to eight hours, or intense driving, etc. For example, the rationality check faults of the coolant temperature sensor include unreasonable low P0116 23 and signal stuck P0116 26, rationality check during cold start P050C 24 and P050C 23, which respectively require two driving conditions (normal idle speed and running the vehicle after cold start). To simulate such faults, firstly, the sensor characteristics should be analyzed. The NTC temperature sensor characteristics are that the internal resistance value increases as the temperature decreases, as shown in figure 6a. Through the characteristic diagram, we can get the corresponding relationship between the resistance value and the temperature, and then we can simulate the required coolant temperature value by series or parallel corresponding resistor. When the adjusted coolant temperature value exceeds the fault threshold, the corresponding fault code is reported. We can simulate P0116 at idle speed by means of series 3000 ohm resistance in the line of coolant temperature sensor, or simulate P050C during cold start condition by means of parallel 40k ohm resistance, as shown in figure 6b.   Fig. 6. a&b characteristics of coolant temperature sensor.

Faults simulated by tools
In PVE J2 test, the faults simulated by tools mainly include misfire faults, oxygen sensor performance faults, unreasonable faults of camshaft position signal, CAN communication faults, etc. The main tools used include misfire generator, oxygen sensor fault simulator, signal generator and CANoe software. [6] The misfire generator can directly control the ignition coil of the engine and make the ignition coil out of work at a certain frequency through the on-off signal of a certain frequency, so as to simulate the engine misfire fault. By setting the misfire rate and random/periodic mode, the single cylinder misfire and random misfire faults can be simulated respectively.
The camshaft signal is PWM signal, so the signal generator should be used to intervene the signal with the duty cycle required by the failure, so as to generate the corresponding fault, as shown in figure 5.
Communication faults can be simulated by shielding messages or changing parameters' value from corresponding module by CANoe software, thus generating CAN communication faults.
The oxygen sensor is an essential part of the vehicle which adjust the engine control parameters to keep the air-fuel ratio of the mixture near the theoretical air-fuel ratio and to evaluate the catalytic converter conversion performance. [7] The oxygen sensor features a sudden change in the output voltage near the theoretical air-fuel ratio (14.7:1), so it is used to monitor the oxygen concentration in the exhaust and feed it back to the engine controller to form a closed-loop control to regulate the air-fuel ratio. [8] Once the air-fuel ratio of the mixture deviates from the theoretical air-fuel ratio, the catalytic converters' purification and transformation capacity of CO, HC and NOx will decrease sharply. However, the effective use of catalytic converters is the main mean to reduce emissions on vehicles, as shown in FIG. 7.  Fig. 7. Influence of oxygen sensor voltage characteristics and catalytic converters on emission.
In addition, two oxygen sensors are usually installed before and after the catalytic converter, and the aging level of the catalytic converter can be determined by the signal difference between the two sensors calculated from oxygen storage capacity. Under normal circumstances, the signal voltage of the front oxygen sensor is much higher than that of the rear oxygen sensor. However, when the catalytic converter is aging or failure, the signal voltage of the two tends to be the same, as shown in FIG. 8.   Fig. 8. Comparison of oxygen sensor signals before and after.
The signal characteristics of the oxygen sensor are relatively complex, so it is impossible to achieve the relevant fault simulation by using the general method of implanting resistance or input voltage. At present, the fault simulator of the oxygen sensor is a common method for fault simulation of the oxygen sensor. On the basis of the original signal, the fault simulator of oxygen sensor can be modified with delay, rich-to-lean or lean-to-rich transition, or offset, so as to achieve the fault requirements and generate the corresponding fault codes.

Faults simulated by failure components
The PVE J2 test also has a class of faults that need to be simulated with related hardware, such as component stuck, catalytic converter aging, evaporation 1mm leakage, etc. The required components include electronic throttle, VVT actuator, canister ventilation valve, thermostat, canister purge valve, etc. Among them, the components stuck faults only require the parts to be stuck in a certain position and connected in breakout box to bypass the original parts on the car, as shown in figure 9.

Conclusions
The CHINA 6 standard requires manufactures to conduct PVE tests of at least three car models every year, among which the PVE J2 test is the most complex, requiring verification of all OBD diagnostic trouble codes. According to the simulation method, fault codes can be divided into five categories: circuit fault, rationality fault, performance fault, communication fault, and faults not feasible for PVE. The faults simulated by Breakout box and resistor box account for 50% of all faults. At present, domestic manufactures have carried out the research and development of automatic fault simulation device, but it is still not mature. Most failure simulation still requires manual operation, and in particular, different diagnostic control strategies are adopted by different enterprises, while a common PVE test specification has yet to be developed.