Products: Motion Control, PXI/CompactPCI, LabVIEW, Distributed I/O The Challenge: In the development of automotive intelligent digital instrument clusters, the amount of information required is substantial, and the parameters vary significantly across different vehicle models. These issues pose challenges to real-vehicle testing and parameter calibration. To quickly and effectively test the system's various functions and improve development efficiency, we designed a testing system capable of simulating various automotive parameter information, rapidly conducting comprehensive testing of the designed instrument cluster, saving bench or real-vehicle testing time, and reducing testing risks. The Solution: Utilizing NI's hardware and software products, combined with a self-developed data communication conversion card, we constructed an online testing system for digital instrument clusters. The system simulates various vehicle status parameters and signals required for digital instrument cluster testing, including analog, digital, switch, and CAN signals, driving the digital instrument cluster under test, simulating relevant vehicle states, and providing feedback on the instrument cluster's operating status. The entire testing system was developed using NI's LabVIEW software platform, ultimately providing a complete testing solution for automotive intelligent digital instrument clusters. System Design The development of an automotive intelligent digital instrument testing system requires the ability to simulate and generate various acquisition signals needed by the instrument cluster for different vehicle models, and to communicate with the instrument under test via a CAN interface. The testing system described in this paper includes the following main functions: 1) Simulation generation of pulse signals for the speedometer/odometer; 2) Simulation generation of pulse signals for the engine tachometer; 3) Simulation generation of signals for the vehicle's fuel gauge; 4) Simulation generation of signals for the vehicle's coolant temperature gauge; 5) Simulation generation of signals from various vehicle lights, windows, doors, and other body switches; 6) The digital instrument cluster has a CAN communication interface, acting as a CAN node to communicate with other nodes on the vehicle's CAN network. System Hardware Design: The hardware system of the digital instrument testing system mainly includes a main controller, PXI boards, signal junction boxes, data communication conversion boards, a power supply, and the instrument under test. NI's PXI modular boards are characterized by their small size, high speed, and easy expansion; therefore, we adopted PXI boards to generate the various signals required by the automotive instrument cluster in the hardware design. The odometer and tachometer in a car's digital instrument cluster require the acquisition of digital pulse signals. Different vehicle models use different sensors, resulting in output pulse signals with high-level voltages ranging from 3V to 12V. To comprehensively test the signals of the designed instrument cluster, a PXI-6624 board, along with an external power supply circuit, is used to generate the series of digital pulse signals required by the instrument cluster. The PXI-6624 is an industrial-grade isolated 32-bit timer/counter PXI interface board with 8 isolated channels. We use Counter0 and Counter1 as the pulse signal channels for the speedometer and tachometer. The fuel gauge and coolant temperature gauge acquire analog signals. The PXI-6233 can output 4 channels of 10V analog level signals, and the PXI-6713 can output 8 channels of 10V analog level signals. We select two analog output channels from either the PXI-6713 or the PXI-6233 as the analog signal channels for the fuel gauge and coolant temperature gauge. Because the instrument panel displays numerous switching signals, such as brake, left and right turn signals, fuel alarm, coolant temperature alarm, and left and right door open/close signals, the interference between them is significant. We selected the PXI-6528 to control the instrument panel's switching signals. The PXI-6528 is a high-speed isolated digital I/O channel with independent input and output channels, effectively suppressing signal interference. A data communication conversion card was used to calibrate the instrument panel parameters and to act as a CAN node for data communication with other CAN nodes on the vehicle. The card's main function is to convert between serial port signals and CAN signals. The purpose of developing the data communication conversion card was twofold: firstly, to save costs, and secondly, to address the fact that most desktop or laptop computers do not have a CAN interface. This card was used to set the characteristic parameters of the controlled instrument panel, such as the vehicle's characteristic coefficients, sensor sensing coefficients, engine speed ratios, and some instrument calibration parameters. Since the target vehicle model is uncertain, some instrument panel characteristic parameters require actual vehicle testing for final calibration; therefore, this card can be used for future instrument panel parameter calibration. The hardware functional block diagram of the entire test system is shown in Figure 1. [align=center]Figure 1 Hardware Functional Block Diagram of the Instrument Testing System[/align] System Software Design: The instrument testing system software adopts the LabVIEW 8.20 platform from NI. LabVIEW is a virtual instrument software development platform based on a graphical programming language, with a powerful function module library, particularly suitable for the development of test and control systems. Combined with NI's hardware modules, it is easy to collect and analyze relevant test data. Considering the needs of overall instrument function testing and module function testing, the entire system mainly includes an interface module and various function test modules. According to the signal type, the instrument function tests are divided into the following main functional modules: speedometer test module, engine tachometer test module, fuel gauge test module, water temperature gauge test module, switch quantity test module, CAN communication test module, and parameter setting module. The overall functional block diagram of the automotive instrument testing system software is shown in Figure 2. [align=center]Figure 2 Overall Functional Block Diagram of the Instrument Testing Platform Software[/align] 1. Interface Module On the left side of the test platform are the switching buttons for various module function tests, which can switch to the test items of a single functional module. The main interface on the right simulates the display interface of a car dashboard, showing information such as speedometer, tachometer, water temperature gauge, fuel gauge, mileage indicator, and various alarm and switch signals. During testing, staff can observe the overall functionality of the instrument through the main interface. The front panel of the main interface is shown in Figure 3, and the control block diagram is shown in Figure 4. [align=center] Figure 3: Front panel of main interface Figure 4: Control block diagram of main interface[/align] 2. Module Test Design Testing the speedometer requires prior knowledge of the characteristic parameters of the target vehicle model, such as vehicle characteristic coefficients and the sensing coefficient of the speed sensor. These characteristic parameters are then downloaded to the instrument under test via a data communication card (CAN bus signal). A pulse signal is generated according to the test requirements. The amplitude and frequency of the signal can be adjusted manually/automatically. The speed signal has an overspeed alarm function. When the speed exceeds the set overspeed threshold, the overspeed alarm light on the front panel of the main interface flashes to indicate this. The test process can also be performed manually/automatically, and the test results are archived for future reference. [align=center]Figure 5 Module Software Test State Transition Diagram[/align] The speedometer test module adopts a state machine design pattern, as shown in Figure 5. It mainly consists of states such as start, parameter acquisition, manual/automatic selection, acquisition (manual), check time (automatic), output signal, and stop. Parameter acquisition primarily involves acquiring the characteristic coefficients and sensing coefficients from the front panel. These two values ​​typically need to be modified online during instrument parameter calibration. The check time refers to outputting a specified signal according to the program's time limit. In this system, the speed change trend in a triangular wave mode is used to test the instrument, and its control block diagram is shown in Figure 6. The engine tachometer test module is similar to the speedometer test module, but differs in its characteristic parameters. Depending on the specific vehicle model, the engine speed ratio is downloaded to the instrument under test via a data communication card (CAN bus signal), and then tested. The fuel gauge test requires pre-setting the fuel test range and fuel threshold alarm value for the target vehicle model. The parameter values ​​are downloaded to the instrument under test via a data communication card (CAN bus signal), and then the test begins according to the test requirements. According to the set fuel threshold, when the fuel level falls below the threshold, the fuel warning light on the front panel of the main interface will flash to indicate this. The test process can be performed manually or automatically. The fuel gauge test adopts a state machine design pattern, mainly divided into states such as start, parameter acquisition, manual/automatic, data acquisition, alarm check, and signal output. The water temperature gauge test is the same as the fuel gauge test and will not be described in detail here. [align=center] Figure 6 Vehicle speed test module control window[/align] 3. CAN Communication Test Module Before testing any module, the parameters of the module must first be initialized, such as setting the characteristic coefficient, sensing coefficient, engine speed ratio, overspeed threshold, fuel threshold, water temperature threshold, and measurement range. Data communication uses the CAN protocol. Considering cost, we operate the serial port in LabVIEW and then output the CAN signal through the data conversion board. The CAN signal directly communicates with the instrument under test. Therefore, a simple CAN communication protocol needs to be defined. The test system acts as a node on the CAN network. The node ID number can be set according to requirements. The data area consists of command word, data length, data, and check bit. Figure 7 below shows the CAN communication front panel diagram, and Table 1 shows the instrument parameter setting CAN communication simple protocol. [align=center] Figure 7 CAN Communication Test Front Panel Table 1 Instrument Test Parameter Setting CAN Protocol[/align] Test Result Analysis Through testing of the digital instruments installed in existing vehicles, the measurement errors of key indicators such as speed sensors and engine speed sensors all meet the requirements of national standard QC/T 727-2004. Simultaneously, as a CAN node, it can effectively realize the parameter setting of automotive instruments and CAN network communication according to a specific CAN application protocol. Summary Using NI's PXI platform and the flexible and convenient LabVIEW software system, we were able to build a multi-functional test platform integrating automotive digital instrument product development, testing, and evaluation in a short period of time. Through testing of actual instruments, the results show that this test system can quickly and accurately complete various functional tests of the instruments under test. Furthermore, the system is scalable and can be easily ported to test schemes for other products, accumulating testing experience for our subsequent automotive electronic product development. References: [1] Lei Zhenshan. Practical Technical Tutorial of LabVIEW 7 Express [M]. Beijing: China Railway Publishing House, 2004. [2] Zhou Haomin, Wang Rui. Test Signal Processing Technology [M]. Beijing: Beijing University of Aeronautics and Astronautics Press, 2004. [3] Yang Leping, Li Haitao, Zhao Yong, et al. Advanced LabVIEW Programming [M]. Beijing: Tsinghua University Press, 2005. [4] National Instrument Co. LabVIEW Programmer Reference Manual [Z]. 1998.