Vehicle controller development assistance device and vehicle controller development assistance method

Abstract

The invention relates to a vehicle controller development assisting device and a vehicle controller development assisting method, and relates to the technical field of automobile development. The device comprises a data interface module, an acquisition signal control module and a data monitoring module. The data interface module is used for sending a fault signal of the vehicle controller to the acquisition signal control module in the development process of the vehicle controller, and the fault signal indicates fault information of the vehicle controller; the acquisition signal control module is used for collecting the fault signal sent by the data interface module and sending the fault signal to the data monitoring module; and the data monitoring module is used for performing an integrity test on the fault signal, recording a fault problem indicated by the fault signal passing the integrity test, and sending the fault signal passing the integrity test and monitoring information to a computer terminal of a developer, so that the developer analyzes the fault problem, and sends the fault problem to the computer terminal of the developer. And debugging the vehicle controller based on the fault signal passing the integrity test and the monitoring information.

Description

Technical Field

[0001] The embodiments of the present application relate to the field of automobile development technology, and in particular to a vehicle controller development assistance device and a vehicle controller development assistance method. Background Art

[0002] With the rapid development of the automobile industry in recent years, automobile companies have developed and iterated many new car models every year. Therefore, in the process of automobile development, adjustments to automobile development are particularly important.

[0003] During the development process, if difficult problems are discovered, car companies will usually temporarily add manpower to arrange reproduction, record signals, and quickly arrange developers to analyze, modify software, and verify to solve problems that arise during the car development process.

[0004] However, the way to deal with development problems in the above development process is rather cumbersome and complicated, the time for R&D verification is seriously insufficient, and testing is insufficient, which reduces the efficiency of vehicle development. Summary of the Invention

[0005] The embodiments of the present application provide a vehicle controller development assistance device and a vehicle controller development assistance method, which can improve vehicle development efficiency. The technical solution is as follows:

[0006] In one aspect, a vehicle controller development auxiliary device is provided, the device comprising a data interface module, a signal acquisition control module, and a data monitoring module;

[0007] The data interface module is connected to the signal acquisition control module, and the signal control module is connected to the data monitoring module; the data interface module is set on the hardware of the vehicle controller;

[0008] The data interface module is configured to send a fault signal of the vehicle controller to the acquisition signal control module during the development of the vehicle controller, wherein the fault signal indicates fault information of the vehicle controller, and the fault information includes a fault error indication, a fault event, and a fault data source;

[0009] The signal acquisition control module is used to collect the fault signal sent by the data interface module and send the fault signal to the data monitoring module;

[0010] The data monitoring module is used to perform an integrity test on the fault signal, record the fault problem indicated by the fault signal after passing the integrity test, and send the fault signal and monitoring information after passing the integrity test to the developer's computer terminal. The monitoring information is the record information of the fault problem by the data monitoring module, so that the developer can analyze the fault problem and debug the vehicle controller based on the fault signal after passing the integrity test and the monitoring information.

[0011] In some embodiments, the data interface module has a built-in program for communicating with the vehicle controller via the vehicle controller's internal communication protocol and internal network signals;

[0012] The data interface module is used to record the fault signal of the vehicle controller through the internal communication protocol and internal network signal of the vehicle controller when the vehicle controller fails.

[0013] In some embodiments, the data monitoring module includes a physical reminder submodule;

[0014] The physical reminder submodule is used to issue an audible and visual reminder after receiving the fault signal, and send a reminder email to the development personnel, wherein the reminder email is used to inform the development personnel that a fault has occurred in the current vehicle controller.

[0015] In some embodiments, the reminder email includes the acquisition time of the fault signal, the vehicle controller identifier, and the fault type identifier.

[0016] In some embodiments, the physical reminder submodule includes a sound prompt device and a warning light, and the physical reminder submodule is used to:

[0017] After receiving the fault signal, the sound prompt device emits a buzzing sound;

[0018] After receiving the fault signal, the warning light flashes to remind the developer that there is a fault that needs to be handled.

[0019] In some embodiments, the data monitoring module is connected to the verification test platform, and the data monitoring module is used to:

[0020] After the fault of the vehicle controller is repaired, the historical fault data and the operating data of the repaired vehicle controller are uploaded to the verification test platform, so that the verification test platform generates test cases based on the historical fault data and performs automated reproduction testing on the repaired vehicle controller.

[0021] In some embodiments, the data monitoring module is further configured to:

[0022] The fault signals and operating data of the vehicle controller before and after the fault repair are uploaded to the verification test platform, so that the verification test platform can judge whether the repair effect of the vehicle controller meets the expected standards by comparing the fault signals and operating data before and after the fault repair.

[0023] In some embodiments, the acquisition signal control module is integrated into the PCBA circuit of the vehicle controller.

[0024] In some embodiments, when a fault occurs in the vehicle controller, the vehicle controller generates a wake-up signal and sends it to the acquisition signal control module, and the acquisition signal control module is used to:

[0025] waking up according to the wake-up signal and receiving the fault information;

[0026] When the duration of not receiving the wake-up signal reaches a duration threshold, the system enters a dormant state.

[0027] In another aspect, a vehicle controller auxiliary development method is provided, the method being executed by the vehicle controller development auxiliary device, the method comprising:

[0028] During the development of the vehicle controller, a fault signal of the vehicle controller is sent to the acquisition signal control module via the data interface module, wherein the fault signal indicates fault information of the vehicle controller, and the fault information includes a fault error indication, a fault event, and a fault data source;

[0029] The fault signal sent by the data interface module is collected by the signal acquisition control module, and the fault signal is sent to the data monitoring module;

[0030] An integrity test is performed on the fault signal through the data monitoring module, and the fault problem indicated by the fault signal after passing the integrity test is recorded. The fault signal after passing the integrity test and the monitoring information are sent to the developer's computer terminal. The monitoring information is the record information of the fault problem by the data monitoring module, so that the developer can analyze the fault problem and debug the vehicle controller based on the fault signal after passing the integrity test and the monitoring information.

[0031] The technical solution provided by this application may have the following beneficial effects:

[0032] The data interface module is directly integrated into the vehicle controller hardware, allowing the vehicle controller's fault signals to be collected in real time and accurately during the vehicle controller's development process, reducing the time cost of manual troubleshooting. The data monitoring module performs integrity testing on the fault signal to ensure the authenticity and availability of the recorded fault problems, improving the accuracy of fault diagnosis. The complete fault signal and monitoring information are pushed to the development terminal, enabling developers to quickly locate the source of the problem and perform targeted debugging, significantly shortening the fault response cycle, thereby improving the overall development efficiency of the vehicle controller. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0034] Figure 1 This is a system environment diagram of a vehicle controller development auxiliary device application according to one embodiment of the present application;

[0035] Figure 2 This is a structural diagram of a vehicle controller development assistance device provided by one embodiment of the present application;

[0036] Figure 3 This is a flow chart of a vehicle controller development assistance method provided by one embodiment of the present application;

[0037] Figure 4 This is a flowchart of a system auxiliary device for quickly analyzing problems provided by an embodiment of the present application;

[0038] Figure 5 This is a flow chart of the internal logic processing of a system auxiliary device provided by one embodiment of the present application. DETAILED DESCRIPTION

[0039] Exemplary embodiments will be described in detail herein, with examples illustrated in the accompanying drawings. In the following description, when referring to the drawings, identical numerals in different figures represent identical or similar elements, unless otherwise indicated. The embodiments described in the following exemplary embodiments are not intended to represent all embodiments consistent with the present application. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the present application, as detailed in the appended claims.

[0040] like Figure 1 As shown, Figure 1 This is a system environment diagram of the vehicle controller development auxiliary device application involved in one embodiment of the present application. Figure 1 As shown, Figure 1The vehicle 100 is provided with a vehicle controller 10. During the development of the vehicle controller, the developer can use the vehicle controller development auxiliary device 100a to monitor the development status of the vehicle controller 10 in real time, and obtain a fault signal when there is a problem with the vehicle controller 10. The fault signal is sent to the developer, and the developer debugs the vehicle controller development auxiliary device according to the fault signal. In this embodiment, the vehicle controller development auxiliary device 100a includes a data interface module 11, a signal acquisition control module 12, and a data monitoring module 13.

[0041] like Figure 2 As shown, Figure 2 This is a structural diagram of a vehicle controller development auxiliary device provided by one embodiment of the present application. The device includes a data interface module 11, a signal acquisition control module 12, and a data monitoring module 13;

[0042] The data interface module 11 is connected to the acquisition signal control module 12, and the acquisition signal control module 12 is connected to the data monitoring module 13; the data interface module 11 is set on the hardware of the vehicle controller 10;

[0043] The data interface module 11 is used to send a fault signal of the vehicle controller 10 to the acquisition signal control module 12 during the development process of the vehicle controller 10. The fault signal indicates fault information of the vehicle controller 10. The fault information includes a fault error indication, a fault event, and a fault data source.

[0044] The signal acquisition control module 12 is used to collect the fault signal sent by the data interface module 11 and send the fault signal to the data monitoring module 13;

[0045] The data monitoring module 13 is used to perform an integrity test on the fault signal, record the fault problem indicated by the fault signal after passing the integrity test, and send the fault signal and monitoring information after passing the integrity test to the developer's computer terminal. The monitoring information is the record information of the fault problem by the data monitoring module, so that the developer can analyze the fault problem and debug the vehicle controller 10 based on the fault signal and monitoring information after passing the integrity test.

[0046] The data interface module is a functional module located within the vehicle controller hardware, used to establish a communication bridge with the vehicle controller's internal systems. It collects fault signals in real time during vehicle controller operation and transmits them to the subsequent processing module after standardization.

[0047] In some embodiments, during the development of the vehicle controller, when an abnormality occurs in the vehicle controller, the data interface module can directly obtain a fault signal generated by the vehicle controller.

[0048] The data monitoring module is used to perform integrity verification, fault problem recording and data transmission on the collected fault signals.

[0049] Among them, the above-mentioned fault signal is a set of structured data generated by the vehicle controller during the development process due to software or hardware abnormalities. The fault signal includes error indication, fault event and fault data source.

[0050] The integrity test mentioned above refers to checking the data integrity and logical consistency of the received fault signal to ensure that the fault signal is not lost or damaged during transmission; the fault problem record is to convert the fault signal that passes the test into a traceable problem entry to facilitate subsequent analysis.

[0051] In an embodiment of the present application, the data monitoring module can be composed of a high-performance processor or embedded system, equipped with functions such as data parsing and integrity testing algorithms. When the data monitoring module receives a fault signal, it first verifies the data integrity of the fault signal. If the fault signal passes the integrity test, the data monitoring module classifies the fault signal and stores it in a local database or uploads it to the cloud. The data monitoring module can also push the fault signal and monitoring information to the developer's computer terminal via the local area network or cloud platform.

[0052] In an embodiment of the present application, after receiving a fault signal, the data monitoring module can first perform a CRC (Cyclic Redundancy Check) check or a hash comparison to confirm that the data of the fault signal has not been tampered with or lost, parse the content of the fault signal, and determine whether the content of the fault signal meets the preset specifications. When the fault signal meets the integrity test, the data monitoring module will record the fault corresponding to the fault signal in a local database or send it to the cloud.

[0053] In some embodiments, the data monitoring module can send the fault signal and monitoring information after passing the integrity test to the developer's computer terminal, and the push method can be email, voice prompt, etc.

[0054] In an embodiment of the present application, the data interface module is directly integrated into the vehicle controller hardware, so that during the development process of the vehicle controller, the fault signal of the vehicle controller can be collected in real time and accurately, reducing the time cost of manual troubleshooting. The data monitoring module performs integrity testing on the fault signal to ensure the authenticity and availability of the recorded fault problems, thereby improving the accuracy of fault diagnosis, and pushing the complete fault signal and monitoring information to the development terminal, so that developers can quickly locate the source of the problem and perform targeted debugging, greatly shortening the fault response cycle, thereby improving the overall development efficiency of the vehicle controller.

[0055] Based on any one or more of the above embodiments, in one possible implementation, the data interface module has a built-in program for communicating with the vehicle controller through the vehicle controller's internal communication protocol and internal network signals;

[0056] The data interface module is used to record the fault signal of the vehicle controller through the internal communication protocol and internal network signal of the vehicle controller when a fault occurs to the vehicle controller.

[0057] In this embodiment of the present application, the data interface module integrates a communication protocol stack for the vehicle controller, automatically identifying the current firmware version running on the vehicle controller and loading the corresponding communication configuration parameters. When a vehicle controller fault occurs, the data interface module initiates a read request, retrieves a structured fault signal from the vehicle controller's memory, including an error indication, event type, and data source, and encapsulates it in a standard format (e.g., JSON, binary frame) for transmission to the subsequent processing module.

[0058] In the above solution, the data interface module judges the operating status of the vehicle controller by continuously monitoring the internal communication protocol and network signals of the vehicle controller, thereby determining whether the vehicle controller has failed.

[0059] The data interface module periodically sends heartbeat requests to the vehicle controller and monitors the response signal returned by the vehicle controller. If no response is received from the vehicle controller within a preset time window, or if the status flag in the response indicates an abnormality (e.g., an error code, unexpected operating mode, etc.), the vehicle controller is determined to be faulty.

[0060] In an embodiment of the present application, when a vehicle controller fails, the data interface module can automatically capture the fault signal according to the internal communication protocol and internal network signal without relying on external equipment or manual intervention, thereby improving the real-time and completeness of fault collection and effectively accelerating development and debugging efficiency.

[0061] Based on any one or more of the above embodiments, in one possible implementation, the data monitoring module includes a physical reminder submodule;

[0062] The physical reminder submodule is used to issue an audible and visual reminder after receiving a fault signal, and send a reminder email to the development personnel. The reminder email is used to inform the current vehicle controller of a fault.

[0063] Among them, the above-mentioned physical reminder sub-module is a hardware component integrated in the data monitoring module, which is used to remind developers of the current vehicle controller failure through physical means (such as sound, light) when a fault signal is detected.

[0064] Among them, the above-mentioned sound and light reminder refers to an emergency notification method that conveys to developers the current vehicle controller failure by working together through sound and visual signals.

[0065] In some embodiments, after receiving the fault signal, the data monitoring module may call the API (Application Programming Interface) interface of the physical reminder submodule to issue an audible and visual reminder.

[0066] In an embodiment of the present application, upon receiving a fault signal, the physical reminder submodule can immediately issue an audible and visual alarm and send a reminder email, which greatly shortens the fault response time and enables developers to immediately know that a fault has occurred in the vehicle controller. The active reminder mechanism reduces the risk of problem expansion due to delayed processing, effectively improving the timeliness of fault feedback during the vehicle development process, thereby effectively improving vehicle development efficiency.

[0067] Based on any one or more of the above embodiments, in a possible implementation manner, the reminder email includes the acquisition time of the fault signal, the vehicle controller identifier, and the fault type identifier.

[0068] The acquisition time of the above-mentioned fault signal refers to the specific time point when the data monitoring module reads the fault signal from the vehicle controller, which can be recorded in a standard time format.

[0069] In the embodiment of the present application, the acquisition time of the fault signal is an important basis for determining the occurrence sequence, duration, and periodicity of the vehicle controller fault.

[0070] In this embodiment, developers can accurately determine the fault occurrence time based on the acquisition time of the fault signal.

[0071] Among them, the above-mentioned vehicle controller identifier is an identity number or label used to uniquely identify the vehicle controller. Each vehicle controller has a vehicle controller identifier, and different vehicle controllers have different vehicle controller identifiers. In some embodiments, the vehicle controller identifier can be a hardware serial number.

[0072] In this embodiment, developers can quickly locate a specific vehicle controller through the vehicle controller identifier, which facilitates subsequent testing and adjustment.

[0073] The above-mentioned fault type identifier is a code or name used to describe the nature and category of the fault. One fault type corresponds to one fault type identifier, and different fault types correspond to different fault type identifiers.

[0074] In this embodiment, the developer can clearly identify the fault type of the vehicle controller through the fault type identifier.

[0075] In an embodiment of the present application, the content structure of the reminder email is expanded. The reminder email includes the acquisition time of the fault signal, the vehicle controller identifier and the fault type identifier. The acquisition time helps to determine whether the fault has periodic or sporadic characteristics. The vehicle controller identifier clarifies the fault controller. The fault type identifier can be used as a basis for preliminary diagnosis to assist in quickly identifying the fault problem. Based on the reminder email containing the above information, developers can more efficiently classify problems, prioritize and schedule resources, thereby improving overall development efficiency.

[0076] Based on any one or more of the above embodiments, in a possible implementation, the physical reminder submodule includes a sound prompt device and a warning light, and the physical reminder submodule is used to:

[0077] After receiving the fault signal, a buzzer sound is emitted through the sound prompt device;

[0078] After receiving a fault signal, the warning light flashes to remind developers that there is a fault that needs to be handled.

[0079] The above-mentioned sound prompt device refers to an electronic component for emitting a sound signal. The sound prompt device can be a buzzer or a speaker, which is used to remind the developer by auditory means after receiving a fault signal.

[0080] In this implementation, the function of the sound prompt device is to emit a buzzing sound of a specific frequency when a vehicle controller fails to function, so as to attract the attention of developers.

[0081] In some embodiments, the physical reminder submodule is used to analyze the fault type corresponding to the fault signal after receiving the fault signal, and to emit different beeps through the sound prompt device for different fault types; further, the physical reminder submodule is used to analyze the fault problem corresponding to the fault signal after receiving the fault signal, and to broadcast a voice description of the fault problem.

[0082] Among them, the above-mentioned warning light is a device that emits visible light signals through light-emitting diodes, and is used to visually remind developers after receiving a fault signal.

[0083] In some embodiments, the warning light can display multiple colors by controlling the combination of red, yellow, and green to indicate different levels of fault problems. For example, red indicates a serious fault, yellow indicates a warning, and green indicates normal operation.

[0084] In some embodiments, the physical reminder submodule is used to analyze the fault type corresponding to the fault signal after receiving the fault signal, and to prompt with different flashing frequencies of warning lights for different fault types to remind developers that different fault problems need to be handled.

[0085] In the embodiment of the present application, the fault reminder method is expanded, and the timeliness and reliability of fault response are effectively guaranteed through the multi-level reminder mechanism of sound and light reminder and email reminder, thereby improving the efficiency of the vehicle controller development process.

[0086] Based on any one or more of the above embodiments, in a possible implementation, the data monitoring module is connected to the verification test platform, and the data monitoring module is used to:

[0087] After the fault of the vehicle controller is repaired, the historical fault data and the operating data of the repaired vehicle controller are uploaded to the verification test platform, so that the verification test platform generates test cases based on the historical fault data and performs automated reproduction testing on the repaired vehicle controller.

[0088] Among them, the above-mentioned verification test platform is an automated testing system used to perform functional verification and performance evaluation on vehicle controllers after fault repair. The verification test platform can generate targeted test cases based on historical fault data and execute automated testing processes.

[0089] In an embodiment of the present application, after the verification test platform receives the data uploaded by the data monitoring module, it parses and obtains key information (such as fault type) in the historical fault data and the operating data of the repaired vehicle controller, calls the preset test template library, and automatically generates corresponding test cases.

[0090] Among them, automated reproduction testing refers to using an automated testing platform to simulate the original fault scenario on the repaired vehicle controller to verify whether the repair effect of the vehicle controller meets the expected goals.

[0091] In an embodiment of the present application, after the fault of the vehicle controller is repaired, the verification test platform generates targeted test cases based on the historical fault data and the repaired operating data, simulating the original fault scenario to verify the repair effect of the vehicle controller. This testing mechanism not only saves the time cost of manually writing test scripts, but also improves the coverage and accuracy of the verification test, improves the vehicle development links, and improves vehicle development efficiency.

[0092] Based on any one or more of the above embodiments, in a possible implementation method, the data monitoring module is also used to upload the fault signals and operating data of the vehicle controller before and after the fault repair to the verification test platform, so that the verification test platform can judge whether the repair effect of the vehicle controller meets the expected standards by comparing the fault signals and operating data before and after the fault repair.

[0093] In an embodiment of the present application, the data monitoring module can uniformly upload the fault signals, error codes, context information recorded by the vehicle controller during the occurrence of the fault, as well as the operating status data during normal operation after repair, to the verification test platform.

[0094] In an embodiment of the present application, after receiving the fault signals and operating data before and after the repair, the verification test platform compares the fault signal before the repair with the operating data after the repair item by item to identify whether the repair of the vehicle controller meets the expected standards.

[0095] In some embodiments, the expected standard may be at least one of: no identical error code reappears; a response delay is lower than a specified threshold; and input and output signals return to normal.

[0096] In the embodiment of the present application, the data monitoring module can accurately determine whether the fault repair of the vehicle controller is complete by comparing and analyzing the data before and after the repair, thereby improving the repair and testing link of the vehicle controller during the development process and improving the development efficiency of the entire vehicle control system.

[0097] Based on any one or more of the above embodiments, in a possible implementation, the wireless communication module and the signal acquisition control module are integrated into the PCBA circuit of the vehicle controller.

[0098] Among them, the above-mentioned PCBA is a printed circuit board in the vehicle controller with all electronic components already soldered.

[0099] In an embodiment of the present application, the acquisition signal control module is soldered on the PCBA board through a standard packaging process and shares power and ground lines with the controller main chip.

[0100] In an embodiment of the present application, by directly integrating the acquisition signal control module into the PCBA circuit of the vehicle controller, deep integration at the hardware level is achieved, eliminating the problems of connection delay, interface incompatibility, etc. brought by the traditional external acquisition module, and improving the real-time and stability of signal acquisition.

[0101] Based on any one or more of the above embodiments, in a possible implementation, when a vehicle controller fails, the vehicle controller generates a wake-up signal and sends it to a signal acquisition control module, which is used to:

[0102] Wake up according to the wake-up signal and receive fault information;

[0103] When the duration of not receiving the wake-up signal reaches a duration threshold, the system enters the sleep state.

[0104] The wake-up signal is an electrical signal actively sent by the vehicle controller when a fault occurs.

[0105] In some embodiments, when the vehicle controller detects abnormal behavior (e.g., communication interruption, watchdog timeout, memory error, etc.), it generates a wake-up signal in a specific format and sends it to the acquisition signal control module via the CAN (Controller Area Network) bus to activate the acquisition signal control module.

[0106] The above-mentioned entry into the dormant state means that when the acquisition signal control module does not receive any wake-up signal within a set time threshold, it automatically switches to a low-power operation mode to reduce energy consumption and resource occupation.

[0107] In the embodiments of this application, a wake-up signal mechanism is introduced to achieve intelligent start-stop management of the signal acquisition control module. When a vehicle controller malfunctions, the vehicle controller proactively sends a wake-up signal, triggering the signal acquisition control module to enter an active state, enabling it to receive and process fault information. In a fault-free state, if the signal acquisition control module does not receive a wake-up signal for an extended period, it automatically enters sleep mode, reducing power consumption and extending system life. This on-demand wake-up design ensures timely capture of fault signals while avoiding unnecessary resource waste.

[0108] like Figure 3 As shown, Figure 3 This is a flow chart of a vehicle controller development assistance method provided by an embodiment of the present application. The vehicle controller development assistance method can be executed by a vehicle controller development assistance device, for example, the vehicle controller development assistance device can be the above-mentioned Figure 1 The vehicle controller development assistance device 100a is shown. The vehicle controller development assistance method includes steps 310, 320, and 330, which are described in detail as follows.

[0109] Step 310: During the development of the vehicle controller, the fault signal of the vehicle controller is sent to the acquisition signal control module through the data interface module. The fault signal indicates the fault information of the vehicle controller. The fault information includes a fault error indication, a fault event, and a fault data source.

[0110] Step 320: The fault signal sent by the data interface module is collected by the signal acquisition control module, and the fault signal is sent to the data monitoring module.

[0111] Step 330: Perform an integrity test on the fault signal through the data monitoring module, record the fault problem indicated by the fault signal after passing the integrity test, and send the fault signal and monitoring information after passing the integrity test to the developer's computer terminal. The monitoring information is the record information of the fault problem by the data monitoring module, so that the developer can analyze the fault problem and debug the vehicle controller based on the fault signal and monitoring information after passing the integrity test.

[0112] In an embodiment of the present application, the data interface module is directly integrated into the vehicle controller hardware, so that during the development process of the vehicle controller, the fault signal of the vehicle controller can be collected in real time and accurately, reducing the time cost of manual troubleshooting. The data monitoring module performs integrity testing on the fault signal to ensure the authenticity and availability of the recorded fault problems, thereby improving the accuracy of fault diagnosis, and pushing the complete fault signal and monitoring information to the development terminal, so that developers can quickly locate the source of the problem and perform targeted debugging, greatly shortening the fault response cycle, thereby improving the overall development efficiency of the vehicle controller.

[0113] Illustratively, an embodiment of the present application proposes a system auxiliary device for quickly analyzing and solving problems of a vehicle function controller, hereinafter referred to as a "system auxiliary device."

[0114] This embodiment addresses the issue of developers repeatedly reproducing the problem on test vehicles due to a failure to capture fault signals in a timely manner during vehicle function controller development, wasting significant manpower and development and verification time. While a single fault may take longer to reproduce, the risk of user-side issues arising from a failure to capture and analyze effective signals can arise during user experience.

[0115] Therefore, in order to facilitate developers to solve various problems encountered in testing and verification in a timely manner, they can obtain fault data and make analysis feedback as soon as possible when product development, testing and verification problems occur, automatically collect problem data, and the data collection information unit will promptly transmit the received messages to the verification personnel or developers through signal transmission and other methods for timely analysis, so as to solve development problems more quickly.

[0116] In this embodiment, the core technology of the system auxiliary device for quickly analyzing and solving problems with the vehicle function controller is to collect a signal from the fault end in a timely manner, and provide the collected fault end signal to the developer (including verification developer) to grasp the phenomenon (or essence) of the fault problem, so as to achieve an auxiliary device to quickly solve the problem.

[0117] Please refer to Figure 4 , Figure 4This is a workflow diagram of a system auxiliary device for quickly analyzing problems provided by an embodiment of the present application.

[0118] This figure briefly introduces the processing logic workflow of the system auxiliary device during the automobile development process. It is an auxiliary device that collects data information at the fault end, transmits it to the background analysis, and closely cooperates with the background system through signal transmission in the middle to quickly resolve test failure problems.

[0119] The key system modules are described as follows:

[0120] Functional controller 1: refers to the product module where the fault problem occurs.

[0121] Data acquisition interface 2: This module is one of the three core units of the system auxiliary device. Software developers have written various processing logic functions such as the fault signal acquisition path, processing method, and signal transmission method into the processing unit through the software internal program (solidified). When a fault occurs, the data acquisition connection work of the unit module will be immediately triggered.

[0122] Among them, the above-mentioned admission path refers to the method of admission of the fault component itself, such as using internal transmission protocol code, internal network signal, etc.

[0123] Data acquisition signal control unit 3: It is the most critical processing unit of the entire system auxiliary device and serves as a bridge between the data acquisition interface 2 and the processing terminal analysis.

[0124] Signal transmission: refers to the virtual signal transmission between the hardware interface connecting the function controller and the monitoring data processing terminal interface.

[0125] The monitoring data processing terminal 4 is one of the three core units of the monitoring system device. It is mainly responsible for problem data analysis and processing, and is also the connection between staff and the validity of data transmission and whether the format is complete.

[0126] The physical reminder notification is a reminder indication signal attached to the monitoring data processing terminal 4, which notifies the developer to handle the fault by sound prompt or warning light.

[0127] Email notification: The developer will automatically send the collected signal data to the relevant developers via email.

[0128] Developer analysis and solution: Analyze the causes and optimize the problems based on the received fault admission data.

[0129] Verification test: After correcting the problem, conduct a thorough test and verification of the fault phenomenon on the faulty vehicle or on a test bench. After confirming that there is no problem with the controller, systematically release the controller software for subsequent program integration.

[0130] Manual software refresh and upgrade: The software that has been verified to be problem-free is updated through manual upgrade and refresh to update the software of the functional controller, and finally the fault is verified to be eliminated and the problem is solved.

[0131] This device mainly includes a dedicated data acquisition interface 2 for the function controller 1, a data acquisition signal control unit 3, and a monitoring data processing terminal 4 (including a physical reminder device). However, it is not limited to these modules and also includes some human intervention, such as R&D personnel, test and verification personnel, etc.

[0132] The data acquisition interface 2 (hereinafter referred to as "data interface") is added to the hardware of the controller and is used as a "link" to connect the fault end of the functional controller and the data signal acquisition unit.

[0133] The data acquisition signal control unit 3 (hereinafter referred to as the "data acquisition control unit") is a control unit that pre-installs the acquisition unit module (the relevant acquisition and processing programs have been developed) into the circuit of the PCBA (Printed Circuit Board Assembly) at the early stage of the controller's hardware development. The central processing unit of the acquisition unit collects fault signals at any time, and then sends them to the monitoring data processing terminal in a timely manner through the internal transmission protocol and signal stack protocol for R&D personnel to process and analyze. Among them, the fault signal specifically refers to the error signal generated by the faulty component itself. Fault signals include but are not limited to fault error indications and fault events. The fault signal indicates the root cause of the fault data.

[0134] The monitoring data processing terminal (including the physical reminder device) receives the fault signal collected at the front and transmits the recorded signal to the developer's computer terminal through the internal information transmission system. At this time, the developer can arrange to analyze the specific cause in a timely manner.

[0135] The system auxiliary device for rapid problem analysis of this embodiment pre-installs the information acquisition interface unit control module on the hardware side at the early stage of the development of the functional controller. If a problem occurs during the development and testing process, the module will transmit the recorded signal (with a fixed file format and size designed internally) to the monitoring data processing terminal via the internal communication protocol stack. At this time, the monitoring terminal will promptly use physical reminders (sound prompts or warning lights) to remind the developer to immediately deal with the fault problem, so that fault data can be extracted and analyzed at any time, thereby rapidly improving the speed of problem analysis and solution. In addition, it greatly avoids the impact of the failure problem on the development progress and quality of the entire product due to the inability to reproduce the problem, improves product quality, and greatly reduces user complaints about quality problems of new cars.

[0136] Please refer to Figure 5 , Figure 5 This is a flow chart of the internal logic processing of a system auxiliary device provided by one embodiment of the present application.

[0137] This flowchart mainly explains the internal processing logic diagram of the auxiliary device of the entire system, which has three key points:

[0138] The first is a key data interface component pre-installed in the functional controller unit's control module hardware. Developers must pre-match the data interface's internal processing program with the functional controller's interface. The hardware interface is then mounted on a PCB (Printed Circuit Board). The ability to capture complete critical fault data signals depends entirely on this component.

[0139] The second is the data acquisition and control unit involved in fault problems. The acquisition unit is a key unit connecting the controller interface and the background terminal data analysis. Once the collected data is wrong or the conversion fails, it will be another process of waiting for review.

[0140] The third one involves judging whether the quality of the software that fixes the problem can pass acceptance.

[0141] This step requires both manual work and the pre-implanted unit control module. After releasing the corrected software, developers conduct multiple on-vehicle tests and verification based on the original problem symptoms. The synchronized unit control module also keeps track of the operating status of the faulty controller.

[0142] Problem Occurrence and Handling Process: First, when a functional controller fails, the data interface instantly receives an internal request command, instantly opening the data link and connecting to the data acquisition control unit module. It then performs internal processing logic and begins recording signals, which are then transmitted to the backend monitoring data processing terminal via network transmission in a specific file format. The file format can be either the software internal code format or the network signal format.

[0143] At this point, the system will notify the developer physically (or visually and audibly), and simultaneously via email or other internal transmission methods, that a function controller on the actual vehicle has failed and requires urgent attention. The developer in charge of verification will then notify the corresponding software engineer for analysis and resolution. Once the software is updated and confirmed to be problem-free, it will be released to dedicated developers for on-vehicle verification.

[0144] Verification: This step is also an important step in proving whether the problem has been resolved. It can be conducted through two acceptance methods. One is manual verification on a real vehicle or test bench, where the test developer reproduces the problem discovered at the time to determine whether the problem still exists. The other is a method where the data acquisition signal control unit on the controller side tracks the fault. Both can be verified simultaneously. If any of these two methods encounter problems during the verification process, the conclusion is unqualified and the software must be returned and revised, and the verification test cycle continues until the problem no longer occurs. The acceptance of these two methods is a continuous process, and the final verification software can only be released after the problem is completely resolved, and qualified products for mass production of complete vehicles can be used.

[0145] Acceptance Conclusion: This phase involves verifying the software's reliability through the aforementioned tests. After multiple rounds of testing and review, the software is reintegrated into the functional controller under development. At this point, the problem is considered resolved.

[0146] This repetitive process of solving development problems has greatly accelerated the R&D efficiency of vehicle products, improved product R&D quality, and ensured software reliability.

[0147] Note the following definitions:

[0148] Manual acceptance method: refers to the developer testing and verifying the problem points directly on the test vehicle or the test bench after receiving the software, while also testing other software functions.

[0149] Data Acquisition and Control Unit (DACU) acceptance: After receiving software updates from the functional controller, the DACU (verification phase) tracks the controller's performance. If a controller fault signal is triggered again or other anomalies occur, the DACU continues tracking the signal and, in a loop, feeds it back to the developer through the monitoring data processing terminal, following the previous round of functional processing logic. This action encourages the developer to initiate a new round of problem remediation.

[0150] Those skilled in the art will understand that all or part of the steps to implement the above embodiments may be accomplished by hardware, or may be accomplished by a program to instruct the relevant hardware, and the program may be stored in a computer-readable storage medium, which may be a read-only memory, a disk, or an optical disk, etc.

[0151] Those skilled in the art will appreciate that in one or more of the above examples, the functions described in the embodiments of the present application can be implemented using hardware, software, firmware, or any combination thereof. When implemented using software, these functions can be stored in a computer-readable medium or transmitted as one or more instructions or codes on a computer-readable medium. Computer-readable media include computer storage media and communication media, wherein communication media include any media that facilitates the transmission of computer programs from one place to another. The storage medium can be any available medium that can be accessed by a general-purpose or special-purpose computer.

[0152] The above description is merely an optional embodiment of the present application and is not intended to limit the present application. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present application shall be included in the scope of protection of the present application.

Claims

1. A vehicle controller development auxiliary device, characterized in that: The device includes a data interface module, a signal acquisition control module, and a data monitoring module; The data interface module is connected to the signal acquisition control module, and the signal acquisition control module is connected to the data monitoring module; the data interface module is set on the hardware of the vehicle controller; The data interface module is configured to send a fault signal of the vehicle controller to the acquisition signal control module during the development of the vehicle controller, wherein the fault signal indicates fault information of the vehicle controller, and the fault information includes a fault error indication, a fault event, and a fault data source; The signal acquisition control module is used to collect the fault signal sent by the data interface module and send the fault signal to the data monitoring module; The data monitoring module is used to perform an integrity test on the fault signal, record the fault problem indicated by the fault signal after passing the integrity test, and send the fault signal and monitoring information after passing the integrity test to the developer's computer terminal. The monitoring information is the record information of the fault problem by the data monitoring module, so that the developer can analyze the fault problem and debug the vehicle controller based on the fault signal after passing the integrity test and the monitoring information.

2. The device according to claim 1, characterized in that The data interface module has a built-in program for communicating with the vehicle controller through the internal communication protocol and internal network signals of the vehicle controller; The data interface module is used to record the fault signal of the vehicle controller through the internal communication protocol and internal network signal of the vehicle controller when the vehicle controller fails.

3. The device according to claim 1, characterized in that The data monitoring module includes a physical reminder submodule; The physical reminder submodule is used to issue an audible and visual reminder after receiving the fault signal, and send a reminder email to the development personnel, wherein the reminder email is used to inform the development personnel that a fault has occurred in the current vehicle controller.

4. The device according to claim 3, characterized in that The reminder email includes the acquisition time of the fault signal, the vehicle controller identifier and the fault type identifier.

5. The device according to claim 3, characterized in that The physical reminder submodule includes a sound prompt device and a warning light, and the physical reminder submodule is used to: After receiving the fault signal, the sound prompt device emits a buzzing sound; After receiving the fault signal, the warning light flashes to remind the developer that there is a fault that needs to be handled.

6. The device according to claim 1, characterized in that The data monitoring module is connected to the verification test platform, and the data monitoring module is used to: After the fault of the vehicle controller is repaired, the historical fault data and the operating data of the repaired vehicle controller are uploaded to the verification test platform, so that the verification test platform generates test cases based on the historical fault data and performs automated reproduction testing on the repaired vehicle controller.

7. The device according to claim 6, characterized in that The data monitoring module is further used to: The fault signals and operating data of the vehicle controller before and after the fault repair are uploaded to the verification test platform, so that the verification test platform can judge whether the repair effect of the vehicle controller meets the expected standards by comparing the fault signals and operating data before and after the fault repair.

8. The device according to claim 1, characterized in that The acquisition signal control module is integrated into the PCBA circuit of the vehicle controller.

9. The device according to claim 8, characterized in that When a fault occurs in the vehicle controller, the vehicle controller generates a wake-up signal and sends it to the acquisition signal control module, and the acquisition signal control module is used to: waking up according to the wake-up signal and receiving the fault information; When the duration of not receiving the wake-up signal reaches a duration threshold, the system enters a dormant state.

10. A vehicle controller auxiliary development method, characterized in that: The method is executed by the vehicle controller development assistance device according to claim 1, and the method includes: During the development of the vehicle controller, a fault signal of the vehicle controller is sent to the acquisition signal control module via the data interface module, wherein the fault signal indicates fault information of the vehicle controller, and the fault information includes a fault error indication, a fault event, and a fault data source; The fault signal sent by the data interface module is collected by the signal acquisition control module, and the fault signal is sent to the data monitoring module; An integrity test is performed on the fault signal through the data monitoring module, and the fault problem indicated by the fault signal after passing the integrity test is recorded. The fault signal after passing the integrity test and the monitoring information are sent to the developer's computer terminal. The monitoring information is the record information of the fault problem by the data monitoring module, so that the developer can analyze the fault problem and debug the vehicle controller based on the fault signal after passing the integrity test and the monitoring information.

Images