Introduction In the development of automotive intelligent digital instrument clusters, the amount of information that needs to be collected is substantial, and the information parameters vary significantly across different vehicle models. These issues pose challenges to the actual vehicle testing and parameter calibration of the instrument clusters. To quickly and effectively test the various functions of the system during development and improve system development efficiency, we designed a testing system capable of simulating various parameter information from the vehicle, rapidly conducting comprehensive testing of the designed instrument cluster, saving bench or actual vehicle testing time, and reducing testing risks. System Design The development requirements of the automotive intelligent digital instrument cluster testing system are to be able to simulate and generate various acquisition signal information required 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: Simulation generation of pulse signals for the speedometer and odometer; Simulation generation of pulse signals for the engine tachometer; Simulation generation of signals for the vehicle fuel gauge; Simulation generation of signals for the vehicle coolant temperature gauge; Simulation generation of signals for various vehicle lights, windows, doors, and other body switch signals. The digital instrument cluster has a CAN communication interface and, as a CAN node, can communicate with other nodes on the vehicle's CAN network. System Hardware Design The hardware system of the digital instrument test system mainly includes a main controller, PXI boards, signal junction boxes, data communication conversion boards, power supplies, and the instruments under test. NI's PXI modular boards are characterized by their small size, high speed, and easy expansion. Therefore, in the hardware design, we used PXI boards to generate the various signals required by automotive instruments. The odometer and tachometer of automotive digital instruments require the acquisition of digital pulse signals. Different vehicle models use different sensors, resulting in output pulse signal high-level values ​​ranging from 3V to 12V. To test the signal range applicability of the designed instruments, we used the PXI-6624 board, along with an external power supply circuit, to generate the digital pulse signals required by the instruments. The PXI-6624 is an industrial-grade isolated 32-bit timer/counter: a PXI interface board with 8 isolated channels. We used C outer 0 and Counter 1 as the pulse signal channels for the speedometer and tachometer. The fuel gauge and coolant temperature gauge collect analog signals. The PXI-6233 can output four 10V analog level signals, and the PXI-6713 can output eight 10V analog level signals. We selected two analog output channels of the PXI-6713 as the signal supply channels. Since there are many switching signals on the instrument panel, the interference between them is also significant. We chose the PXI-8528R to control the switching signals of the instrument panel. The PXI-6528 is a high-speed isolated digital I/O channel with independent input and output channels, effectively suppressing interference between signals. The calibration of the instrument panel parameters and data communication with other CAN nodes on the vehicle are accomplished using a data communication conversion card. The main function of this card is to convert serial port signals to CAN signals. The purpose of developing the data communication conversion card is twofold: first, to save costs, and second, to address the fact that most PCs do not have a CAN interface. This card is 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 calibration parameters of the instrument panel. Since the target vehicle model is uncertain, some characteristic parameters of the instrument require actual vehicle testing for final calibration. Therefore, this board can be used for future instrument parameter calibration. The hardware functional block diagram of the entire testing system is shown in Figure 1. System Software Design The instrument testing system software is designed using NI's LabVIEW 8.20 platform. This system uses LabVIEW's graphical programming language to create the front panel human-machine interface and program block diagram in a very intuitive way. The front panel is visible to the user, similar to the operation panel of a traditional instrument. Input controllers and output indicators are added from the control template using tool templates. The types of controllers and indicators are selectable. The program block diagram is the core that supports the virtual instrument in realizing its functions. The design of the program block diagram involves the design of nodes, data ports, and connections. Connections represent data flow, and nodes are functions, subroutines, structures, or code interfaces. This testing system considers the needs of overall instrument function testing and module function testing. The entire system mainly includes an interface module and various functional testing modules. Based on 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, coolant 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 is shown in Figure 2. Interface Module On the left side of the test platform are the switching buttons for various module function tests, allowing switching to individual functional module test items. The main interface on the right simulates the display interface of a car dashboard, such as the speedometer, tachometer, coolant temperature gauge, fuel gauge, odometer, and various alarm and switch signals. During the test experiment, the operator can observe the overall function of the instrument test through the main interface, as shown in Figure 3. The speedometer module test design requires prior knowledge of the target vehicle's characteristic parameters, such as vehicle characteristic coefficients and the sensor's sensing coefficient. These parameters are then downloaded to the instrument under test via a data communication card (CAN bus signal). Pulse signals are generated according to the test requirements; the amplitude and frequency of the signals can be adjusted manually or automatically. The speed signal includes an overspeed alarm function; if the speed exceeds a set overspeed threshold, an overspeed alarm light on the front panel of the main interface flashes. The test process can be performed manually or automatically, and test results are archived for future reference. The software test state transition diagram is shown in Figure 4. The speedometer test module adopts a state machine design pattern, mainly divided into states such as start, parameter acquisition, manual/automatic selection, acquisition (manual), check time (automatic), output signal, and stop. Parameter acquisition primarily involves obtaining the characteristic coefficient and sensing coefficient values ​​from the front panel. These 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 prescribed time. This system uses a 'V' mode with a stepped speed change trend to test the instrument, as shown in Figure 5. The engine tachometer test module is similar to the speedometer test module, but the difference lies 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 the test is performed. 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 the data communication card (CAN bus signal), and then the test begins according to the set fuel threshold value. If the fuel level falls below the threshold, the fuel warning light on the front panel of the main interface will flash as a warning. The test process can be performed manually or automatically. The fuel gauge test uses a state machine design pattern, mainly divided into states such as start, parameter acquisition, manual/automatic, data acquisition, alarm check, and output signal. The coolant temperature gauge test is the same as the fuel gauge test and will not be described in detail here. CAN Communication Test Module Before testing any module, its parameters must first be initialized, such as setting characteristic coefficients, sensing coefficients, engine speed ratio, overspeed threshold, fuel threshold, coolant 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 a data conversion board. The CAN signal directly communicates with the instrument under test (DUT). Therefore, a simple CAN communication protocol needs to be defined. The test system acts as a node on the CAN network; the node ID can be set according to requirements. The data area consists of command word, data length, data, and checksum. Figure 6 and Table 1 show the simple CAN communication protocol for setting instrument parameters. Conclusion Using NI series PXI boards and the flexible and convenient LabVIEW software platform, we were able to build a multi-functional test platform integrating automotive digital instrument product development, testing, and evaluation in a short period. Testing of actual instruments shows that this test system can quickly and accurately complete various functional tests of the DUT. Furthermore, the system is scalable and can be easily ported to test solutions for other products, accumulating valuable testing experience for our subsequent automotive electronic product development.