Combination instrument stability test system and method, electronic equipment and storage medium

Abstract

The invention discloses a combination instrument stability test system, and relates to the field of instrument testing, and the system comprises a CANOE random signal generation module which is used for simulating a vehicle state signal and outputting a CAN signal Message and an Ethernet event; the Monkey test module is used for executing a random operation test on an application program interacting with the combination instrument; the screenshot analysis module is used for intercepting a combination instrument interface according to a preset interval, and identifying blank screen, white screen and local display abnormity through an image processing algorithm; the log analysis module is used for exporting a combination instrument QNX system log according to a preset interval, and positioning system abnormity by identifying a coredump file or key log information; the Python upper computer is used for controlling start / stop and parameter configuration of each module and receiving abnormal data of each module; the exception response module executes hierarchical response according to the exception level; the report generation module is used for summarizing the test data and generating a test report; the test report comprises abnormity statistics, problem positioning and stability scoring.

Description

Technical Field

[0001] This application relates to the field of instrument testing, and in particular to a combined instrument stability testing system, a combined instrument stability testing method, electronic equipment, and storage medium. Background Technology

[0002] With the increasing number of cars on the road, people are becoming more and more reliant on automobiles as an efficient means of transportation for their daily travel. As a crucial component reminding drivers of speed, gear position, and warning information, the instrument cluster's stability is paramount, in addition to an aesthetically pleasing and user-friendly interface. Currently, OEMs and suppliers lack a clear testing methodology for instrument cluster stability, with most tests focusing on single operating conditions, such as power-on / off stress tests or durability tests on the hardware PCB board. However, these testing methods cannot fully simulate real-world vehicle conditions, thus failing to adequately verify the stability of the instrument cluster. Summary of the Invention

[0003] The purpose of this invention is to provide a system for testing the stability of a combination instrument cluster, a method for testing the stability of a combination instrument cluster, an electronic device, and a storage medium. By simulating the CAN load and Ethernet load during the operation of the combination instrument cluster, the actual vehicle operating environment of the instrument cluster is simulated. At the same time, during the instrument cluster stability test, the Monkey test program is run on the central control unit to test the stability of the central control instrument cluster's interactive part. During the test, the operation log is monitored to identify key QNX logs to find problems such as system crashes and anomalies. In addition, screenshot analysis is used to identify black and white screen problems during system operation. Through the above scheme, the stability of the combination instrument cluster can be fully verified.

[0004] This invention provides the following solution:

[0005] According to one aspect of the present invention, a combined instrument stability testing system is provided, comprising:

[0006] The CANOE random signal generation module is used to simulate vehicle status signals and output CAN signals (Message) and Ethernet events.

[0007] The Monkey test module runs on the central control equipment and is used to perform random operation tests on the application that interacts with the instrument cluster.

[0008] The screenshot analysis module is used to capture the instrument cluster interface at preset intervals and identify black screens, white screens, and partial display anomalies through image processing algorithms.

[0009] The log analysis module is used to export the QNX system log of the instrument cluster at preset intervals and locate system anomalies by identifying coredump files or key log information.

[0010] The Python host computer communicates with the above modules to control the start / stop and parameter configuration of each module, and to receive abnormal data from each module.

[0011] The exception response module connects to the Python host computer and is used to execute graded responses based on the exception level.

[0012] The report generation module is used to summarize test data and generate test reports.

[0013] The test report includes anomaly statistics, problem localization, and stability score.

[0014] Furthermore, including:

[0015] The CANOE random signal generation module further includes: a scenario-based signal sequence unit;

[0016] Scenario-based signal sequence units are used to simulate signal variation patterns under specific operating conditions.

[0017] Furthermore, including:

[0018] Vehicle status signals include vehicle speed, gear position, power status, and tire pressure.

[0019] The applications include multimedia music, navigation, and Bluetooth phone functionality;

[0020] The parameter configuration includes test duration, signal range, and number of operations.

[0021] Furthermore, including:

[0022] The Monkey testing module includes an interaction frequency and type adjustment unit;

[0023] The interaction frequency and type adjustment unit is used to dynamically adjust the interval of random operations based on the response delay of the combined instrument.

[0024] Furthermore, including:

[0025] The screenshot analysis module runs an image processing algorithm to identify black screens, white screens, local anomalies, and display flickering.

[0026] Image processing algorithms include those for grayscale conversion, edge detection, thresholding, and continuous frame comparison.

[0027] Furthermore, including:

[0028] The log analysis module is used to support real-time log monitoring;

[0029] Real-time monitoring includes triggering an anomaly response module when critical log information is detected.

[0030] According to a second aspect of the present invention, a method for testing the stability of a combined instrument is provided, comprising:

[0031] Step S1: Set the test duration, CAN / Ethernet signal range, number of Monkey operations, screenshot and log interval, and anomaly detection threshold through the Python host computer.

[0032] Step S2, Step S2, CANOE random signal generation;

[0033] CANOE random signal generation includes outputting vehicle status signals;

[0034] Vehicle status signals are random values ​​or scene-based signal sequences;

[0035] Step S3: The Monkey test module performs random operations on the application that interacts between the central control unit and the instrument panel, and dynamically adjusts the operation frequency.

[0036] Step S4: The screenshot analysis module captures the interface at intervals and identifies and displays anomalies; the log analysis module monitors the QNX system log in real time and locates system anomalies.

[0037] Step S5: Based on the anomaly level, perform actions such as logging, pausing the test, or sending an alarm message;

[0038] Step S6: Summarize the test data and output a report;

[0039] The report includes anomaly statistics, problem identification, and stability score.

[0040] Furthermore, including:

[0041] The scenario-based signal sequences include vehicle speed fluctuations under urban congestion conditions and stable vehicle speeds under high-speed driving conditions.

[0042] Furthermore, including:

[0043] Display anomalies include overall black screen, overall white screen, localized anomalies, and sudden brightness changes in consecutive frames.

[0044] Furthermore, including:

[0045] Anomaly levels include: minor anomalies, which are logged; and severe anomalies, which result in the test being paused and an alarm being triggered.

[0046] According to three aspects of the present invention, an electronic device is provided, comprising: a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus;

[0047] The memory stores a computer program, which, when executed by a processor, causes the processor to perform the steps of a combined instrument stability test method.

[0048] According to four aspects of the present invention, a computer-readable storage medium is provided that stores a computer program executable by an electronic device, which, when run on the electronic device, causes the electronic device to perform the steps of a combined instrument stability test method.

[0049] Compared with the prior art, the present invention has the following advantages:

[0050] This application comprehensively simulates real vehicle operating conditions and innovatively simulates CAN and Ethernet loads to construct a simulation scenario that highly matches the actual vehicle operating environment of the instrument. This can more realistically reflect the complex signal interaction situations faced by the instrument during actual driving, providing a more targeted environmental foundation for instrument stability testing.

[0051] This application enhances the interactive stability test by incorporating Monkey testing of the central control system during the instrument stability test. This measure focuses on the stability detection of the interactive part of the central control instrument, which can effectively capture system problems that may be caused by frequent human-machine interaction operations, and further improves the comprehensiveness of the test.

[0052] This application utilizes efficient problem identification and localization. During testing, by monitoring operational logs and accurately identifying key logs of the QNX instrument cluster system, it can quickly pinpoint system issues. Simultaneously, screenshot analysis promptly identifies abnormal display problems such as black-and-white screens. These methods not only quickly detect potential faults during instrument cluster operation but also allow for targeted improvements to the program code based on the problem localization results. This significantly enhances the stability of the instrument cluster system, ultimately providing drivers with a more stable and reliable driving information display service, improving driving safety and comfort. Attached Figure Description

[0053] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0054] Figure 1 This is a structural diagram of a combined instrument stability testing system provided by one or more embodiments of the present invention.

[0055] Figure 2 This is a flowchart of a combined instrument stability testing method provided by one or more embodiments of the present invention.

[0056] Figure 3 This is a schematic diagram of a combined instrument stability testing system according to a specific embodiment of the present invention.

[0057] Figure 4 This is a block diagram of an electronic device structure for a combined instrument stability testing method provided by one or more embodiments of the present invention. Detailed Implementation

[0058] The technical solution of the present invention will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0059] Figure 1 This is a structural diagram of a combined instrument stability testing system provided by one or more embodiments of the present invention.

[0060] like Figure 1 As shown, it includes:

[0061] The CANOE random signal generation module is used to simulate vehicle status signals and output CAN signals (Message) and Ethernet events.

[0062] The Monkey test module runs on the central control equipment and is used to perform random operation tests on the application that interacts with the instrument cluster.

[0063] The screenshot analysis module is used to capture the instrument cluster interface at preset intervals and identify black screens, white screens, and partial display anomalies through image processing algorithms.

[0064] The log analysis module is used to export the QNX system log of the instrument cluster at preset intervals and locate system anomalies by identifying coredump files or key log information.

[0065] The Python host computer communicates with the above modules to control the start / stop and parameter configuration of each module, and to receive abnormal data from each module.

[0066] The exception response module connects to the Python host computer and is used to execute graded responses based on the exception level.

[0067] The report generation module is used to summarize test data and generate test reports.

[0068] The test report includes anomaly statistics, problem localization, and stability score.

[0069] Furthermore, including:

[0070] The CANOE random signal generation module also includes: a scenario-based signal sequence unit;

[0071] Scenario-based signal sequence units are used to simulate signal variation patterns under specific operating conditions.

[0072] Furthermore, including:

[0073] Vehicle status signals include vehicle speed, gear position, power status, and tire pressure.

[0074] Applications include multimedia music, navigation, and Bluetooth phone calls;

[0075] The parameter configuration includes test duration, signal range, and number of operations.

[0076] Furthermore, including:

[0077] The Monkey testing module includes an interaction frequency and type adjustment unit;

[0078] The interaction frequency and type adjustment unit is used to dynamically adjust the interval of random operations based on the response delay of the combined instrument.

[0079] Furthermore, including:

[0080] The screenshot analysis module runs image processing algorithms to identify black screens, white screens, local anomalies, and display flickering;

[0081] Image processing algorithms include those for grayscale conversion, edge detection, thresholding, and continuous frame comparison.

[0082] Furthermore, including:

[0083] The log analysis module is used to support real-time log monitoring;

[0084] Real-time monitoring includes triggering an anomaly response module when critical log information is detected.

[0085] Specifically, the system simulates the real-vehicle operating environment of the instrument cluster by simulating the CAN and Ethernet loads during its operation. Simultaneously, during instrument cluster stability testing, the Monkey test program is run on the central control unit to test the stability of the instrument cluster's interactive components. During testing, the system logs are monitored to identify key QNX logs and pinpoint system crashes and anomalies. Furthermore, screenshot analysis is used to identify black-and-white screen issues. This approach effectively verifies the stability of the instrument cluster.

[0086] Figure 2 This is a flowchart of a combined instrument stability testing method provided by one or more embodiments of the present invention.

[0087] like Figure 2 As shown, it includes the following steps

[0088] Step S1: Set the test duration, CAN / Ethernet signal range, number of Monkey operations, screenshot and log interval, and anomaly detection threshold through the Python host computer.

[0089] Step S2, CANOE random signal generation;

[0090] CANOE random signal generation includes outputting vehicle status signals;

[0091] Vehicle status signals are random values ​​or scene-based signal sequences;

[0092] Step S3: The Monkey test module performs random operations on the application that interacts between the central control unit and the instrument panel, and dynamically adjusts the operation frequency.

[0093] Step S4: The screenshot analysis module captures the interface at intervals and identifies and displays anomalies; the log analysis module monitors the QNX system log in real time and locates system anomalies.

[0094] Step S5: Based on the anomaly level, perform actions such as logging, pausing the test, or sending an alarm message;

[0095] Step S6: Summarize the test data and output a report that includes anomaly statistics, problem location, and stability score.

[0096] Furthermore, including:

[0097] The scenario-based signal sequences include vehicle speed fluctuations under urban congestion conditions and stable vehicle speeds under high-speed driving conditions.

[0098] Furthermore, including:

[0099] Display anomalies include overall black screen, overall white screen, localized anomalies, and sudden brightness changes in consecutive frames.

[0100] Furthermore, including:

[0101] Anomaly levels include: minor anomalies, which are logged; and severe anomalies, which result in the test being paused and an alarm being triggered.

[0102] Specifically, a CANOE signal simulation project is created for all the signals received by the instrument cluster, simulating vehicle status signals such as speed, gear position, power status, and tire pressure. The CANOE random signal generation process mainly outputs the CAN signal Message through the output function, creates service events and sends Ethernet event events through the SomeIpAddEvent function, and then the Python host computer module sets the system variables of the CAN and Ethernet signals to random values ​​or other custom signal waveforms by calling the random module.

[0103] The instrument cluster and central control unit primarily interact via JSON strings. Stability of this interaction is simulated by running the Monkey program within the central control unit. The Monkey test process mainly restricts the running and integration of application packages that interact with the instrument cluster, such as multimedia music, navigation, and Bluetooth phone calls. These applications are added to the Monkey whitelist, and then the Monkey test is executed via `adb shell monkey`.

[0104] The screenshot export analysis process mainly involves capturing the instrument's operating interface at fixed intervals during the instrument stability test using the screenshot command. Then, image processing algorithms are used to determine whether the current screen is an abnormal interface such as a black screen or a white screen. Alternatively, the judgment area can be limited to determine local black screens or white screens.

[0105] Among them, the scenario-based signal sequence is linked to the Monkey operation frequency through the host computer (Python) as an intermediate coordination layer.

[0106] The host computer receives contextual signals (such as vehicle speed, road condition signs, etc.) sent by CANOE in real time and identifies the current scenario (such as vehicle speed fluctuating between 0-30km / h when in urban congestion, and vehicle speed stabilizing between 80-120km / h when driving on highways).

[0107] Preset mapping rules between scenarios and operation frequencies (configurable via Python), for example:

[0108] Urban congestion scenario: Frequent signal changes (such as acceleration, deceleration, start and stop) correspond to an increased Monkey operation frequency (such as 3-5 operations per second), simulating users frequently operating the central control in complex road conditions (such as switching navigation and adjusting the air conditioning).

[0109] High-speed driving scenario: The signal is stable (vehicle speed and engine speed fluctuations are small), corresponding to a reduced Monkey operation frequency (e.g., once every 3-5 seconds), simulating the low-frequency interaction of the user when driving smoothly (e.g., occasionally switching music).

[0110] When scene recognition fails, the host computer automatically switches to the default frequency mode (such as medium frequency) to avoid test interruption.

[0111] Combined with the anomaly detection module in step S4, if a system anomaly is triggered by high-frequency operation, the frequency can be temporarily reduced and related logs can be recorded for subsequent problem analysis.

[0112] Figure 3 This is a schematic diagram of a combined instrument stability testing system according to a specific embodiment of the present invention.

[0113] like Figure 3 As shown,

[0114] The system mainly consists of four parts: CANOE random signal generation process, Monkey testing process, screenshot export and analysis process, and log export and analysis process; the Python host computer controls the operation of the above four parts through scripts.

[0115] A CANOE signal simulation project is created for all signals received from the instrument cluster, simulating vehicle status signals such as speed, gear position, power status, and tire pressure. The CANOE random signal generation process mainly outputs CAN signals (Message) through the `output` function, creates service events and sends Ethernet events through the `SomeIpAddEvent` function, and then the Python host computer module calls the `random` module to set the system variables of the CAN and Ethernet signals to random values ​​or other custom signal waveforms.

[0116] The instrument cluster and central control unit primarily interact via JSON strings. Stability of this interaction is simulated by running the Monkey program within the central control unit. The Monkey test process mainly restricts the running and integration of application packages that interact with the instrument cluster, such as multimedia music, navigation, and Bluetooth phone calls. These applications are added to the Monkey whitelist, and then the Monkey test is executed via `adb shell monkey`.

[0117] The screenshot export analysis process mainly involves capturing the instrument's operating interface at fixed intervals during the instrument stability test using the `screenshot` command, and then... Image processing algorithms To determine whether the current screen is an abnormal interface such as a black screen or a white screen, you can also limit the judgment area to determine a local black screen or white screen.

[0118] The log export and analysis process mainly involves exporting the system logs generated during the operation of the QNX system at fixed intervals during instrument stability testing using the adb pull command. By analyzing key files such as the coredump file or keywords like "The send thread is interrupted, the IPC client will be closed" in the logs, the cause of abnormal exits in the QNX core CAN communication is identified, allowing for improvements to the program code and enhancing the stability of the instrument system.

[0119] In the entire test plan, the CANOE random test module randomly simulates the signals of the instrument controller in the actual vehicle, and the Monkey test module randomly simulates the JSON data in the interaction of the central control instrument. By simulating inputs in two different ways, the test data input for the stability test of the instrument is completed. The screenshot export analysis module and the log export analysis module are used to discover crashes, anomalies or black and white screen problems during the test process, and then the logs are used to locate and analyze the problems.

[0120] According to another specific embodiment, the process includes the following:

[0121] I. Test Environment Setup

[0122] Hardware preparation: Prepare a computer with CANOE software installed as the signal simulation host, and connect it to the instrument cluster of the car to be tested and the central control device running the QNX operating system via CAN cable and Ethernet cable.

[0123] Software Configuration: In the CANOE software, a detailed CANOE signal simulation project is created based on the signal matrix of the target instrument cluster received by the target instrument cluster. In the Python host computer, control scripts are written to coordinate the control of the CANOE random signal generation process, the Monkey testing process, the screenshot export and analysis process, and the log export and analysis process.

[0124] II. Implementation of CANOE Random Signal Generation Process

[0125] Detailed Signal Simulation Engineering: In the CANOE signal simulation engineering, the vehicle speed signal is set to a range of 0-200 km / h to simulate various speed states of the vehicle from standstill to high-speed travel. For gear signals, common gear signals such as P (Park), R (Reverse), N (Neutral), and D (Drive) are included. The power status signal simulates different power states of the vehicle, such as starting, running, and stopping. The tire pressure signal is set to fluctuate within the normal tire pressure range to simulate changes in tire pressure during actual driving. Other alarm signals can be added as needed.

[0126] Signal Output and Event Creation: The CANOE's `output` function outputs CAN signals (Messages) based on the approximate frequency and pattern of signal changes during actual vehicle operation. Simultaneously, the `SomeIpAddEvent` function creates Ethernet service events to simulate various Ethernet alarm events from other vehicle controllers.

[0127] Signal customization and randomization: The Python host computer calls the `random` module to set the vehicle speed signal to generate a random value within the range of 0-200 km / h every 10 seconds; the gear signal to switch randomly every 30 seconds; the power status signal to randomly simulate the changes in start-up, running, and shutdown states every 5 minutes; and the tire pressure signal to randomly vary within the range of normal pressure ± 0.2 bar every 20 seconds. Furthermore, complex signal waveforms can be customized according to specific testing needs, such as simulating sudden changes in the vehicle speed signal during rapid acceleration and deceleration.

[0128] III. Monkey Testing Process Implementation

[0129] Application package identification: Identify applications that interact closely with the instrument cluster, such as the multimedia music application, high-precision navigation application, and Bluetooth phone application pre-installed in a certain brand of car. Obtain the package names of these applications, for example, the multimedia music application package name is "com.example.music", the navigation application package name is "com.example.navigation", and the Bluetooth phone application package name is "com.example.btphone".

[0130] Test Execution: Add the above application package names to the Monkey test whitelist. Start the Monkey test by executing the command "adb shell monkey -pcom.example.music -p com.example.navigation -pcom.example.btphone -v 500" in the command line. The "-v" parameter indicates detailed output of test process information, and "500" represents simulating 500 random user actions. The Monkey test will randomly trigger multimedia music playback, pause, and song switching; navigation application destination setting and map zooming; Bluetooth phone calls, making and answering, etc., with a certain probability, to simulate the interaction scenarios between the driver and these applications in actual driving, and test the stability of the instrument cluster under complex interactions.

[0131] IV. Screenshot Export and Analysis Process Implementation

[0132] Scheduled screenshot settings: In the Python host computer control script, configure the screenshot export analysis process to execute the `screenshot` command every minute to capture an image of the instrument cluster's operating interface. The screenshot files are named with timestamps for easy subsequent analysis in chronological order.

[0133] Abnormal Interface Detection: The captured image is transmitted to the image processing algorithm module. This module first converts the image to grayscale, and then uses edge detection algorithms, threshold segmentation algorithms, and other techniques to determine whether the image has a black screen (overall grayscale value close to 0) or a white screen (overall grayscale value close to 255). For local black screen and white screen detection, the algorithm analyzes preset regions of interest (ROIs), such as areas where instrument displays and navigation are prone to black screens, to determine whether there are local abnormal displays. Once an abnormal interface is detected, the system immediately records the time and details of the anomaly, providing a basis for subsequent troubleshooting.

[0134] V. Implementation of Log Export and Analysis Process

[0135] Scheduled log export: In the Python host computer control script, set the log export analysis process to execute the command "adb pull / var / log / qnx_log" every 5 minutes to export the system log files generated during the operation of the QNX operating system from the target central control device to the local specified folder "qnx_logs".

[0136] Problem Localization and Analysis: Use specialized log analysis tools or write Python scripts to analyze the exported log files line by line. Pay special attention to the coredump file and log lines containing the keyword "The send thread is interrupted, the IPC client will be closed". When such key information is found, combine it with the timestamps in the logs and other relevant contextual information to accurately pinpoint the time of the system anomaly and the related operations. For example, if the keyword "CAN communication anomaly" appears in the logs after a sudden change in vehicle speed signal, it can be preliminarily determined that there may be a compatibility issue between the vehicle speed signal simulation and the CAN communication module. Developers can then use this information to specifically check and optimize the relevant program code.

[0137] Through the above specific embodiments, the complex operating conditions of the automotive instrument cluster in actual operation were fully simulated, covering multiple aspects such as signal interaction and human-machine interaction. Through screenshot analysis and log analysis, potential problems were promptly identified and located, effectively verifying the stability of the instrument cluster.

[0138] Figure 4 The present invention provides an electronic device structural block diagram of a method for testing the stability of a combined instrument, according to one or more embodiments.

[0139] like Figure 4 This application provides an electronic device, including: a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus;

[0140] The memory stores a computer program, which, when executed by the processor, causes the processor to perform the steps of a combined instrument stability test method.

[0141] This application also provides a computer-readable storage medium storing a computer program executable by an electronic device, which, when run on the electronic device, causes the electronic device to perform the steps of a combined instrument stability test method.

[0142] For the sake of simplicity, the method embodiments are described as a series of actions. However, those skilled in the art should understand that the embodiments of the present invention are not limited to the described order of actions, because according to the embodiments of the present invention, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions involved are not necessarily essential to the embodiments of the present invention.

[0143] As can be seen from the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware platforms. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in various embodiments or some parts of the embodiments of this application.

[0144] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A combination instrument stability test system, characterized by, Comprise: CANOE random signal generation module for simulating vehicle state signals, outputting CAN signal Message and Ethernet event; Monkey test module running on the central control device, for performing random operation test on the application program interacting with the combination instrument; screenshot analysis module for intercepting the combination instrument interface at preset intervals, identifying black screen, white screen and local display abnormalities through image processing algorithm; log analysis module for exporting combination instrument QNX system log at preset intervals, locating system abnormalities by identifying coredump file or key log information; Python host computer communicating with the above modules respectively, for controlling the start / stop and parameter configuration of each module, and receiving abnormal data of each module; abnormal response module connected with the Python host computer, for performing hierarchical response according to the abnormal level; report generation module for summarizing test data and generating test report; The test report includes abnormality statistics, problem positioning and stability score.

2. The combination instrument stability test system of claim 1, wherein, The CANOE random signal generation module further comprises a scenario signal sequence unit; The scenario signal sequence unit is used for simulating the signal change rule of a specific working condition.

3. The combination instrument stability test system according to claim 1, wherein The vehicle state signals include vehicle speed, gear position, power supply state and tire pressure value; The application program includes multimedia music, navigation and Bluetooth phone; The parameter configuration includes test duration, signal range and operation times.

4. The combination instrument stability test system of claim 1, wherein, The Monkey test module includes an interaction frequency and type adjustment unit; The interaction frequency and type adjustment unit is used for dynamically adjusting the interval of random operation according to the response delay of the combination instrument.

5. The combination instrument stability test system of claim 1, wherein, The screenshot analysis module runs an image processing algorithm for identifying black screen, white screen, local abnormalities and display flicker; The image processing algorithm includes grayscale processing, edge detection, threshold segmentation and continuous frame comparison algorithm.

6. The combination instrument stability test system of claim 1, wherein, The log analysis module is used for supporting real-time monitoring of logs; Real-time monitoring includes triggering the abnormal response module when key log information is detected.

7. A method of testing the stability of a combination meter, characterized by, The steps include: Step S1, setting test duration, CAN / Ethernet signal range, Monkey operation times, screenshot and log interval and abnormality determination threshold through the Python host computer; Step S2, CANOE random signal generation; CANOE random signal generation includes outputting vehicle state signals; The vehicle state signals are random values or scenario signal sequences; Step S3, Monkey test; Monkey test includes performing random operation on the application program interacting with the central control and instrument, and dynamically adjusting the operation frequency; Step S4, screenshot analysis and log analysis; Screenshot analysis includes intercepting the interface at intervals and identifying display abnormalities; Log analysis includes real-time monitoring of QNX system logs and locating system abnormalities; Step S5, obtaining abnormal level information; According to the abnormal level, record logs, pause test or send alarm information; Step S6, summarize test data and output report; The report includes abnormal statistics, problem positioning and stability score.

8. The method of claim 7, wherein, The scenario signal sequence includes signal change rules simulating specific working conditions; The specific working conditions include urban congestion working conditions and high-speed driving working conditions; The signal change rules include vehicle speed fluctuation rules in urban congestion working conditions and vehicle speed stability rules in high-speed driving working conditions.

9. An electronic device, comprising: Comprise: A processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory complete mutual communication through the communication bus; The memory stores a computer program, and when the computer program is executed by the processor, the processor executes the steps of the combination instrument stability test method in any one of claims 7-8.

10. A computer-readable storage medium, characterized in that, It stores a computer program executable by the electronic device, and when the computer program runs on the electronic device, the electronic device executes the steps of the combination instrument stability test method in any one of claims 7-8.

Images