A debugging device, method, and vehicle

Abstract

The application relates to a debugging device, a method and a vehicle, relates to the technical field of vehicles, and aims to solve the technical problem of inaccurate fault positioning. The debugging device comprises a log collection module and a fault root cause tracing module; the log collection module is in communication connection with the fault root cause tracing module; the log collection module is used for collecting log information of a domain controller in the vehicle; a log file is generated based on the log information; the fault root cause tracing module is used for repeatedly executing a first operation until a first condition is reached in the case that a fault occurs in a first device in the domain controller; wherein the first operation is based on the log information of the first device and explores a second device; the second device is updated as the first device; the second device is a device corresponding to an abnormal keyword in the direct downstream devices of the first device; the first condition is that the second device cannot be explored; the first device when the first condition is met is determined as a fault root cause device, and the application of the scheme can improve the accuracy of fault positioning.

Description

Technical Field

[0001] This invention relates to the field of vehicle technology, and more specifically to a debugging device, method, and vehicle. Background Technology

[0002] With the deep integration of automotive intelligence, connectivity, and cockpit system functions, in-vehicle software systems are exhibiting characteristics of functional application, service diversification, and complex interaction, with both the number of functions and software scale growing exponentially. In contrast, existing in-vehicle equipment debugging tools, limited by their architecture designed for traditional electronic control units, struggle to meet the cross-functional and cross-level testing and verification requirements of current multi-domain integrated systems in terms of data processing bandwidth, real-time simulation accuracy, and multi-protocol collaborative analysis capabilities. This contradiction directly leads to inaccurate testing issues such as distorted debugging results under complex operating conditions, low problem reproducibility, and inefficient root cause analysis, severely impacting the reliability of system performance evaluation and the effectiveness of development decisions. Summary of the Invention

[0003] This invention provides a debugging device, method, and vehicle, aiming to improve the accuracy of fault location in vehicle infotainment systems.

[0004] In a first aspect, this application provides a debugging device comprising: a log acquisition module and a fault root cause tracing module; the log acquisition module and the fault root cause tracing module are communicatively connected; the log acquisition module is used to acquire log information of a domain controller in a vehicle; generate a log file based on the log information; the fault root cause tracing module is used to repeatedly execute a first operation when a first device in the domain controller fails, until a first condition is met; wherein, the first operation is to explore a second device based on the log information of the first device in the log file; update the second device to the first device; the second device is a device in the direct downstream devices of the first device that corresponds to a first target keyword; the first target keyword is a keyword in the keyword mapping set bound to the first device that has a mapping relationship with the second target keyword; the second target keyword is an abnormal keyword in the log information of the first device; the first condition is that the second device cannot be explored; the fault root cause tracing module is also used to determine the first device that meets the first condition as the fault root cause device.

[0005] Based on the aforementioned technical means, the log acquisition module can acquire real-time log data from the vehicle domain controller and efficiently transmit it to the fault root cause tracing module. Based on the log information, the fault root cause tracing module can progressively pinpoint the second and first target keywords, and then, guided by the first target keyword, accurately trace the fault back to the associated second device, ultimately reconstructing the complete fault propagation path. This not only significantly improves the automation level and analysis efficiency of fault location but also greatly enhances the accuracy and reliability of root cause determination.

[0006] Furthermore, the debugging device also includes: a debugging bridge; the fault root cause tracing module includes a first operation execution unit; the first operation execution unit is specifically used to send a debugging command to the debugging bridge, so that the execution object of the debugging bridge executes the debugging command; wherein, the debugging command is used to instruct the log information of the first device retrieved from the log acquisition module to be placed into the target signal slot; the target signal slot triggers a first slot function after the log information of the first device arrives; wherein, the first slot function is used to retrieve the keyword set bound to the first device; based on the keyword set and the log information of the first device, determine the abnormal keywords in the log information of the first device; determine the abnormal keywords as the second target keywords; the target signal slot triggers a second slot function after the first slot function is executed; wherein, the second slot function is used to retrieve the keyword mapping set; based on the keyword mapping set and the second target keyword, determine the first target keyword, determine the second device based on the first target keyword, and output an update instruction; the update instruction is used to instruct the second device to be updated to the first device.

[0007] Based on the above technical means, by calling the keyword set and the keyword mapping set through the first slot function and the second slot function respectively, a complete mapping relationship chain from the apparent keywords to the root cause keywords can be constructed, thereby providing a clear and traceable logical path for tracing the root cause of the fault and enhancing the transparency and credibility of the diagnostic results.

[0008] Furthermore, the fault root cause tracing module also includes a repeat execution unit; the repeat execution unit is communicatively connected to the first operation execution unit; the repeat execution unit is used to trigger an update function when an update command is detected to output a target signal slot; wherein, the update function is used to execute the update command if a second device is present in the update command, and send a repeat command to the first operation execution unit after the update command is executed; the repeat command is used to instruct the first operation execution unit to send a debug command to the debug bridge again; and if a second device is not present in the update command, the first device in the update command is identified as the fault root cause device.

[0009] Based on the aforementioned technical means, by using the presence of a second device in the update instruction as a condition for continuing tracing, a clear termination judgment basis can be provided for the root cause tracing process, thereby preventing infinite loop tracing and significantly improving the convergence speed and overall execution efficiency of fault diagnosis.

[0010] Furthermore, the first target keyword is used to indicate the device identifier of the device in the direct downstream device that has a causal relationship with the abnormal manifestation corresponding to the abnormal keyword; the root cause tracing module is specifically used to: identify the device corresponding to the device identifier as the second device.

[0011] Based on the above technical means, the precise correspondence between the first target keyword and the second device simplifies the device location process in cross-device fault tracing, significantly shortens the analysis time, and provides strong support for the efficient operation and maintenance of vehicle domain controllers.

[0012] Furthermore, the log acquisition module is specifically used for: acquiring online log information and / or local log information of the domain controller; the online log information is used to indicate logs stored in the vehicle communication device for transmission to devices outside the domain controller; and performing normalization operations on the online log information and / or local log information to obtain log files; the normalization operations include: encoding normalization operations and format normalization operations.

[0013] Based on the above technical means, by collecting online logs and local logs and encoding and format normalizing them, the unified integration of multi-source heterogeneous logs is realized, providing standardized data input with consistent structure and direct parsing for root cause tracing, effectively reducing preprocessing complexity, and significantly improving the efficiency and accuracy of cross-device log correlation analysis.

[0014] Furthermore, the debugging device also includes: a communication module; the communication module is used to find the available IP address of the domain controller when there is a wired connection between the domain controller and the debugging device and a wireless connection indication is received between the domain controller and the debugging device; and to establish a wireless connection between the domain controller and the debugging device using the available IP address.

[0015] Based on the above technical means, the communication module automatically finds available IP addresses and establishes wireless connections on the basis of wired connections, realizing seamless switching between wired and wireless between the domain controller and the debugging device. There is no need to manually configure network parameters, which simplifies the process of setting up the debugging environment and improves the convenience and efficiency of on-site debugging.

[0016] Furthermore, the communication module is specifically used to: find available IP addresses using preset priorities; wherein, the preset priorities are used to instruct the priorities of the system property reading command getprop, the compatible network interface query command ifconfig, and the standardized network address query command ip addr to be progressively downgraded.

[0017] Based on the above technical means, the communication module searches for available IP addresses in a step-by-step manner through the getprop, ifconfig and ipaddr commands according to the preset priority, ensuring that effective network configuration can be obtained efficiently in different system environments. This takes into account both compatibility and reliability, and significantly improves the success rate of wireless connection establishment and the adaptability of the debugging environment.

[0018] Furthermore, the debugging device also includes: a display module; the display module is communicatively connected to the fault root cause tracing module; the fault root cause tracing module is also used to determine the fault propagation path from the first device to the fault root cause device; and to send the fault propagation path and / or the fault root cause device to the display module so that the display module can display it.

[0019] Based on the above technical means, after determining the fault propagation path and the root cause device, the fault root cause tracing module displays the information visually through the display module, making the fault propagation chain clear at a glance. This facilitates technicians to quickly locate the source of the problem and significantly improves the efficiency of fault investigation and the readability of diagnostic results.

[0020] Secondly, this application provides a debugging method including: collecting log information from a domain controller in a vehicle; generating a log file based on the log information; repeatedly performing a first operation when a first device in the domain controller fails, until a first condition is met; wherein, the first operation is to explore a second device based on the log information of the first device in the log file; updating the second device to the first device; the second device is a device in the direct downstream devices of the first device that corresponds to a first target keyword; the first target keyword is a keyword in the keyword mapping set bound to the first device that has a mapping relationship with the second target keyword; the second target keyword is an abnormal keyword in the log information of the first device; the first condition is that the second device cannot be explored; and the first device that meets the first condition is identified as the root cause device of the fault.

[0021] Thirdly, this application provides a vehicle comprising: a domain controller; the domain controller being communicatively connected to a debugging device; the domain controller being configured to send log information to the debugging device in response to a data acquisition command sent by the debugging device, so that the debugging device can determine the root cause device of the fault based on the log information.

[0022] Fourthly, this application provides an electronic device comprising: a processor and a memory; the memory storing processor-executable instructions. When the processor is configured to execute the instructions, the electronic device implements the method described in the second aspect.

[0023] Fifthly, this application provides a computer-readable storage medium storing computer program instructions that, when executed by a processor, implement the method described in the second aspect.

[0024] In a sixth aspect, this application provides a computer program product including computer program instructions that, when executed by a processor, implement the method described in the second aspect.

[0025] It should be noted that the technical effects of any of the implementation methods in aspects two through six can be found in the technical effects of the corresponding implementation methods in aspect one, and will not be repeated here.

[0026] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0027] Figure 1 A system architecture diagram of a debugging device provided in this application; Figure 2 A flowchart of a log collection module provided in this application; Figure 3 A flowchart of a fault root cause tracing module provided in this application; Figure 4 A flowchart illustrating the workflow of yet another fault root cause tracing module provided in this application; Figure 5 A flowchart illustrating the operation of a communication module provided in this application; Figure 6 A flowchart of a display module provided in this application; Figure 7 A flowchart of a debugging device provided in this application; Figure 8 A system architecture diagram of another debugging device provided in this application; Figure 9 A flowchart illustrating a debugging method provided in this application; Figure 10 This is a structural diagram of an electronic device provided in this application. Detailed Implementation

[0028] The embodiments of the present invention will be described below with reference to the accompanying drawings and preferred embodiments. Those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of the present invention. It should be understood that the preferred embodiments are only for illustrating the present invention and not for limiting the scope of protection of the present invention.

[0029] It should be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of the present invention. Therefore, the drawings only show the components related to the present invention and are not drawn according to the actual number, shape and size of the components in the actual implementation. In the actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0030] For ease of understanding, the debugging device provided in this application will be described in detail below with reference to the accompanying drawings.

[0031] In some embodiments, this embodiment also provides a vehicle, which includes: a domain controller; the domain controller is communicatively connected to a debugging device.

[0032] In an exemplary embodiment, the domain controller and the debugging device can establish a wired connection via USB. Once the wired connection is established, a wireless connection, such as a Bluetooth or Wi-Fi connection, can further be established between the domain controller and the debugging device. The wireless connection can be used to assist data transmission, extend communication bandwidth, or serve as a backup communication link in case of wired connection failure.

[0033] It should be understood that a wired connection between the domain controller and the debugging device via USB can be established when the user needs to troubleshoot, diagnose performance issues, or perform routine maintenance checks on the domain controller.

[0034] As a feasible implementation, the domain controller is used to respond to the acquisition command sent by the debugging device and send log information to the debugging device so that the debugging device can determine the root cause device of the fault based on the log information.

[0035] It should be understood that a domain controller is a specific implementation of the vehicle's infotainment system. Its physical form includes, but is not limited to, integrated domain controllers, cockpit domain controllers, distributed domain controllers, or logical domains composed of multiple electronic control units (ECUs) working together via a high-speed bus. Domain controllers are not limited to a single, independent hardware device.

[0036] In some embodiments, such as Figure 1 As shown, the debugging device 100 includes: a log acquisition module 101 and a fault root cause tracing module 102; the log acquisition module 101 and the fault root cause tracing module 102 are communicatively connected.

[0037] As a feasible implementation method, the log collection module 101 is used to collect log information from the domain controller in the vehicle; and generate log files based on the log information.

[0038] Log information refers to the data set generated by the domain controller during operation to record system state changes, event occurrences, and fault anomalies. It is used to reflect the operating status and behavior trajectory of the domain controller and its associated functional modules over time.

[0039] In an exemplary embodiment, after establishing a communication connection with the domain controller, the log collection module 101 can send a collection command to the domain controller to trigger the domain controller to return corresponding log data in response to the collection command.

[0040] As a feasible implementation method, the log collection module 101 is specifically used to: collect online log information and / or local log information of the domain controller; and perform normalization operation on the online log information and / or local log information to obtain log files.

[0041] The online log information is used to indicate logs stored in the vehicle communication device for transmission to devices outside the domain controller. The online log information can be online ADB log information.

[0042] Local log information is used to indicate log records stored locally on the domain controller.

[0043] Normalization operations include encoding normalization and format normalization.

[0044] In the exemplary embodiment, the encoding normalization operation is used to uniformly convert log information from different sources and with different encoding formats into a preset standard encoding format in order to avoid parsing anomalies or information loss caused by encoding inconsistencies.

[0045] Format normalization is used to structure log information, converting raw logs of different formats into a predefined standard data structure. This normalization process allows for the extraction of key fields such as device name, timestamp, and log level from the raw logs, ensuring structural consistency across logs from different sources. This facilitates subsequent keyword matching, fault tracing, and root cause analysis.

[0046] For example, a unified data structure (such as LogData) is set up to perform encoding normalization and format normalization operations on online log information and / or local log information, so that log information from different paths has a consistent data form in subsequent processing.

[0047] For example, if the panoramic imagery experiences issues such as stuttering, green screen, or failure to display when the initial preparation work is complete, after-sales personnel or R&D personnel can choose to obtain online or local log information based on actual needs. In response to the user's collection command, the log collection module 101 executes the corresponding log collection operation according to the command.

[0048] The collection command can include the specific type of information to be collected, such as specifying to collect online log information, local log information, or both simultaneously.

[0049] It should be understood that by normalizing online log information and / or local log information, local logs and real-time online logs can share the same set of keyword matching and tracing rules, thereby effectively solving the problem of independent analysis and low analysis efficiency of dual sources in traditional debugging tools, and significantly improving the accuracy and timeliness of fault location.

[0050] Optionally, real-time logs can read module log collection commands from the configuration file through a singleton class (ModuleConfig). When a new functional module needs to be added, no code modification is required; only the configuration file needs to be updated to complete the extension, thereby effectively reducing the system's expansion cost and maintenance complexity. At the same time, this solution supports real-time log collection and offline parsing, which can flexibly adapt to different debugging scenarios and meet the diverse debugging needs of the development and after-sales stages.

[0051] As a feasible implementation method, such as Figure 2 As shown, the process involves: starting the log collection module; reading the module configuration file; receiving collection instructions; obtaining the local log file if the instruction is to collect local log information; verifying the validity of the file format in the local log file; outputting a collection failure message if the format is invalid; parsing the local log content to obtain local log information if the format is valid; obtaining the connection status between the domain controller and the log collection module if the instruction is to collect online log information; outputting a collection failure message if the connection is abnormal; obtaining online log information if the connection is normal; performing encoding and format normalization operations on the local or online log information, encapsulating it into a unified LogData structure; outputting the normalized log file to the fault root cause tracing module; and simultaneously feeding back the collection status to the display module.

[0052] As a feasible implementation method, the fault root cause tracing module 102 is used to repeatedly execute the first operation when the first device in the domain controller fails, until the first condition is met.

[0053] The first operation involves exploring the second device based on the log information of the first device in the log file, and then updating the second device to the first device.

[0054] As a feasible implementation method, the second device is the device that corresponds to the first target keyword among the direct downstream devices of the first device.

[0055] Direct downstream devices refer to lower-level functional modules or hardware units that have a direct calling relationship or data interaction relationship with the current device.

[0056] The first target keyword is a keyword that has a mapping relationship with the second target keyword in the keyword mapping set bound to the first device. The first target keyword is used as a multi-level sub-keyword (nextKeywords) to gradually narrow down the fault range through a recursive matching mechanism after the faulty module is located by the second target keyword, and to locate a more specific cause of the anomaly.

[0057] A keyword mapping set is a pre-established set used to represent the mapping relationship between different devices and their corresponding abnormal keywords. This mapping set can be pre-configured and stored in the system as structured data (such as JSON files or database tables), where each device is bound to one or more primary keywords, and each primary keyword forms a mapping association with one or more sub-keywords, so that the corresponding device module can be quickly located based on the abnormal keywords when matching logs.

[0058] The second target keyword is the abnormal keyword found in the log information of the first device. This second target keyword serves as the primary keyword to locate the entry point of the faulty module in the current device.

[0059] Abnormal keywords can characterize abnormal events or error states that occur during the current operation of the device, such as "failed to open camera", "stream acquisition timeout", "interface call returned error code", etc., and are the starting basis for triggering the fault tracing process.

[0060] The first condition is that a second device cannot be found. That is, if there is no next-level device that matches the current abnormal keyword among all the direct downstream devices of the current device, it indicates that the end of the fault propagation link has been reached, the current device is the root cause device of the fault, and the tracing process terminates.

[0061] As a feasible implementation method, taking the camera failure to open in the panoramic imaging function as an example, when the fault root cause tracing module 102 obtains the log information of the first device (such as the panoramic imaging application module), it uses the abnormal keywords in the log information (i.e., the second target keywords, such as "camera failed to open") as the main keywords to match and locate the fault module entry of the current device, and determines that the current fault manifestation is "unable to open the camera".

[0062] Furthermore, the current application module analyzes the log keywords and determines that "unable to open the camera" may be due to reasons such as the current application not receiving a signal that the vehicle is not powered on, failure to call the downstream interface, or abnormal return from the downstream device.

[0063] For example, keyword analysis reveals that the camera cannot be opened because the downstream interface reports "failed to open camera" when the downstream interface is called. The root cause tracing module 102 can then further narrow down the fault scope by using the first target keyword (i.e., multi-level sub-keywords) to locate the problem in the downstream image middleware module, and the downstream module can then take over for the next round of analysis.

[0064] Optionally, the fault root cause tracing module 102 can also configure downstream module identifiers in each level of keywords (second target keywords and first target keywords). When a certain level of keyword is matched, the second device is automatically loaded through the next-level interface set by the corresponding keyword module in the pre-configured JSON file, and the log collection and matching of the second device is triggered. In this way, there is no need to manually switch analysis modules, which solves the problem of cumbersome operation and low efficiency in cross-module fault tracing of traditional debugging tools. Using the above recursive mechanism, the fault root cause tracing module 102 can trace the faults of downstream modules level by level, store the matching results of each level into the fault chain, and finally output the complete fault transmission link of "upper-level anomaly → downstream root cause", intuitively presenting the complete transmission path of the fault from the manifestation to the root cause.

[0065] As a feasible implementation method, the first target keyword is used to indicate the device identifier of the device that has a causal relationship with the abnormal manifestation corresponding to the abnormal keyword in the direct downstream device.

[0066] The fault root cause tracing module 102 is specifically used to: identify the device corresponding to the device identifier as the second device.

[0067] Device identifiers are unique identifiers used to distinguish different functional modules or hardware units. Device identifiers can be used to accurately locate the corresponding target device in the system topology.

[0068] For example, device identifiers include: module name, service identifier (ID), process number or device address, etc. The device identifier can accurately locate the corresponding target device in the system topology.

[0069] The causal relationship of a fault refers to the sequential transmission logic between the abnormal phenomenon of the current equipment and the abnormal state of the downstream equipment. That is, the abnormal appearance exhibited by the current equipment is not its own root cause, but is caused by the functional abnormality or return error of the directly downstream equipment. The two constitute a causal chain of "appearance-cause".

[0070] In an exemplary embodiment, taking the "camera cannot be opened" fault in the panoramic imaging function as an example, the log of the panoramic imaging application module records the abnormal keyword "failed to open camera". This abnormal keyword serves as the second target keyword (i.e., the primary keyword) to locate the current fault module entry point. Further, through a pre-configured keyword mapping set, the primary keyword is mapped to the corresponding first target keyword (i.e., multi-level sub-keywords), indicating that the downstream device with a causal relationship to the abnormal phenomenon is identified as the "image middleware module". Based on this device identifier, the fault root cause tracing module 102 determines the "image middleware module" as the second device, thereby completing the tracing jump from the upper-layer application module to the downstream middleware module. Subsequently, the fault root cause tracing module 102 uses the second device as the new first device, repeats the first operation, and continues to delve deeper into the abnormal keywords in the log information of the image middleware module until the first condition is met, ultimately locating the fault root cause device.

[0071] In another example, if the log record of the image middleware module shows the abnormal keyword "camera driver interface returned timeout", this abnormal keyword is used as a new second target keyword (primary keyword) to locate the current fault module entry point, and is mapped to the corresponding first target keyword (subkeyword) through the keyword mapping set, indicating that the downstream device with a fault causal relationship with the abnormal phenomenon is identified as "camera driver module". Then the fault root cause tracing module 102 further identifies "camera driver module" as a new second device and continues to trace downwards until no next-level device can be explored, thereby outputting the complete fault propagation link of "panoramic image application module → image middleware module → camera driver module".

[0072] As a feasible implementation method, the fault root cause tracing module 102 is also used to identify the first device that meets the first condition as the fault root cause device.

[0073] In the exemplary embodiment, the "camera cannot be turned on" fault in the panoramic imaging function is still taken as an example. When the fault root cause tracing module 102 traces downstream from the panoramic imaging application module as the first device to the image middleware module and the camera driver module, if there is no next-level device matching the current abnormal keyword among all the direct downstream devices of the camera driver module, that is, the first condition is met, then the fault root cause tracing module 102 determines the current first device (i.e., the camera driver module) as the root cause device of the fault. At this point, the tracing process ends, and the complete fault propagation link of "panoramic imaging application module → image middleware module → camera driver module" is output, where the camera driver module is the root cause device of this fault.

[0074] It should be understood that, through the aforementioned recursive tracing mechanism, the fault root cause tracing module 102 can start from the fault symptoms and explore downstream step by step along the fault propagation link until the root cause node with no further related downstream devices is located. This transforms the tedious process of manual, layer-by-layer troubleshooting and cross-module switching required in traditional debugging methods into an automated and systematic tracing process. This not only effectively avoids omissions or deviations in problem location due to excessively long fault propagation links, but also presents the complete fault propagation path intuitively in the form of a fault chain, providing R&D or after-sales personnel with clear and accurate fault location information, significantly improving the efficiency and accuracy of fault troubleshooting.

[0075] In some embodiments, the debugging apparatus further includes: an Android Debug Bridge (ADB); the root cause tracing module 102 includes a first operation execution unit.

[0076] The first operation execution unit is specifically used to send debugging commands to the debugging bridge so that the execution object of the debugging bridge can execute the debugging commands.

[0077] The debugging command is used to instruct the log information of the first device retrieved from the log acquisition module 101 to be placed into the target signal slot.

[0078] As a feasible implementation, the target signal slot triggers the first slot function after the log information from the first device arrives.

[0079] The first slot function is used to retrieve the keyword set bound to the first device; based on the keyword set and the log information of the first device, it determines the abnormal keywords in the log information of the first device; and identifies the abnormal keywords as the second target keywords.

[0080] The first slot function can be a predefined callback function used to automatically perform the extraction and matching of abnormal keywords when the log file arrives.

[0081] The keyword set refers to a pre-configured set of abnormal keywords bound to the first device. This set contains one or more abnormal keywords, each keyword corresponding to an abnormal event or error state that may occur on the first device, such as "failed to open camera", "stream acquisition timeout", "interface call returned error code", etc. The keyword set can be pre-stored in the debugging device in the form of a JSON file and loaded when needed.

[0082] In an exemplary embodiment, taking the panoramic imaging application module as the first device as an example, the first operation execution unit sends a debugging command to the domain controller via ADB. This debugging command places the log information of the panoramic imaging application module into the target signal slot. When the log information arrives at the target signal slot, the execution of the first slot function is triggered. The first slot function loads the keyword set bound to the panoramic imaging application module and matches abnormal keywords in the log information. For example, if "failed to open camera" is matched, the keyword is determined as the second target keyword.

[0083] It should be understood that the first operation execution unit automates the acquisition of log information from the first device and the extraction of abnormal keywords, eliminating the need for manual log viewing and keyword filtering. This provides an accurate and reliable input foundation for subsequent fault tracing. Simultaneously, the unified handling of ADB connections and process management class (QProcess) signals and slots through singleton pattern management effectively avoids redundant connection creation and resource waste, improving the execution efficiency of debugging commands and system stability.

[0084] As a feasible implementation, the target signal slot triggers the second slot function after the first slot function has been executed.

[0085] The second slot function is used to retrieve the keyword mapping set; based on the keyword mapping set and the second target keyword, the first target keyword is determined; based on the first target keyword, the second device is determined, and an update instruction is output; the update instruction is used to instruct the second device to be updated to the first device.

[0086] In the exemplary embodiment, the keyword mapping set refers to a pre-established structured data set (such as a JSON file or database table) used to characterize the mapping relationship between different devices and their corresponding abnormal keywords. Each device is bound to one or more primary keywords (i.e., first target keywords), and each primary keyword forms a mapping association with one or more sub-keywords (i.e., second target keywords) so that the corresponding target device can be quickly located after the abnormal keyword is determined.

[0087] For example, taking the panoramic imaging application module as an example, the first slot function has identified "failed to open camera" as the second target keyword. After the second slot function is triggered, it loads the keyword mapping set, searches for the main keyword (i.e., the first target keyword) that has a mapping relationship with "failed to open camera" in the mapping set, and this main keyword points to the fault entry point of the "panoramic imaging application module"; further, according to the device mapping relationship pre-configured in the keyword mapping set, the second slot function determines that the second device corresponding to the first target keyword is the "image middleware module", and outputs an update instruction to update the "image middleware module" to the new first device.

[0088] As another example, if the current first device is an image middleware module and its exception keyword is "camera driver interface returned timeout", then the second slot function determines the corresponding second device as "camera driver module" through the keyword mapping set and outputs an update instruction to continue tracing downwards.

[0089] It should be understood that through the relay execution mechanism of the first and second slot functions, the fault root cause tracing module 102 achieves automated chaining from abnormal keyword extraction to downstream device location. The first slot function is responsible for mining abnormal keywords from the original logs, while the second slot function uses these keywords in conjunction with pre-configured mapping relationships to complete the jump location of downstream devices. The two functions have clear division of labor and are triggered sequentially, forming a complete closed loop of "log input → abnormal extraction → device jump → loop tracing". Compared with the traditional manual cross-module switching analysis debugging method, this solution significantly improves the automation and efficiency of fault location and effectively solves the problem of difficulty in fault root cause tracing in multi-module linkage scenarios.

[0090] For example, such as Figure 3 As shown, the fault root cause tracing module is started; multi-level keyword configuration rules are loaded; and log files sent by the log collection module are received. The first slot function is called and executed to match the log information in the log file with the keyword set bound to the current first device; if the log information does not match any keyword in the keyword set, the result "No matching fault" is output; if the log information matches a keyword in the keyword set, the matched keyword is recorded as the second target keyword; it is determined whether the second target keyword has a corresponding keyword mapping set. If no corresponding keyword mapping set exists, the result "No downstream mapping configuration" is output, and the current first device is determined as the fault root cause device; if a corresponding keyword mapping set exists, based on the keyword mapping set corresponding to the second target keyword, it is determined whether a matched first target keyword exists; if no sub-keyword in the keyword mapping set is matched, the result "No matching sub-keyword" is output, and the current first device is determined as the fault root cause device; if a sub-keyword in the keyword mapping set is matched, the matched first target keyword is recorded as the new second target keyword; the process returns to determine whether the new second target keyword has a corresponding keyword mapping set.

[0091] In some embodiments, the fault root cause tracing module 102 further includes a repeat execution unit; the repeat execution unit is communicatively connected to the first operation execution unit.

[0092] The repetitive execution unit is used to output an update command upon detecting the target signal slot, thereby triggering the update function.

[0093] As a feasible implementation, the update function is used to execute the update instruction when a second device exists in the update instruction, and then send a repeat instruction to the first operation execution unit after the update instruction is executed.

[0094] The repeat instruction is used to instruct the first operation execution unit to send the debug command to the debug bridge again.

[0095] In an exemplary embodiment, a "camera cannot be turned on" fault in the panoramic imaging function is taken as an example. After the first operation execution unit completes the log analysis of the panoramic imaging application module and determines that the second device is the "image middleware module", the target signal slot outputs an update instruction containing the identifier of the second device. After the repeat execution unit detects the update instruction, it triggers the execution of the update function, updates the current first device from "panoramic imaging application module" to "image middleware module", and sends a repeat instruction to the first operation execution unit. In response to the repeat instruction, the first operation execution unit again obtains the log information of the image middleware module through the debug bridge, and performs keyword matching and downstream device exploration, and so on, until the final root cause device of the fault is traced.

[0096] As another feasible implementation, if there is no second device in the update instruction, the first device in the update instruction is identified as the root cause device of the fault.

[0097] In an exemplary embodiment, in a panoramic imaging scenario, after the repetitive execution unit updates the current first device to "camera driver module," the first operation execution unit analyzes the log information of the camera driver module. If no next-level device matching the current anomaly keyword is found among all its direct downstream devices, the update instruction output by the target signal slot will not include the second device. Upon detecting this update instruction, the repetitive execution unit triggers the update function execution, identifies the current first device (i.e., the camera driver module) as the root cause device, terminates the tracing process, and outputs the complete fault propagation chain: "panoramic imaging application module → imaging middleware module → camera driver module," where the camera driver module is the final root cause device.

[0098] For example, such as Figure 4As shown, the fault root cause tracing module is activated, and the update command output by the first operation execution unit is received; it is determined whether there is a device identifier for the second device; if not, the result "No need for cross-module tracing" is output; if it exists, the communication connection status between the domain controller and the debugging device is verified; if the connection is abnormal, a tracing failure message is output; if the connection is normal, the second device is updated to the first device, and the log information of the first device is obtained; based on the updated log information of the first device, the second device is explored; it is determined whether there is a second device; if there is a second device, the communication connection status between the domain controller and the debugging device is verified; if there is no second device, the complete fault chain is assembled, and the complete fault chain and the tracing status are output to the display module.

[0099] In some embodiments, the debugging apparatus further includes a communication module.

[0100] As a feasible implementation, the communication module is used to find the available IP address of the domain controller when there is a wired connection between the domain controller and the debugging device and a wireless connection indication is received between the domain controller and the debugging device; and to establish a wireless connection between the domain controller and the debugging device using the available IP address.

[0101] In an exemplary embodiment, after the domain controller and the debugging device establish a wired connection via USB, if the user wishes to switch to wireless debugging mode, or if the system detects that the wired connection bandwidth is insufficient to meet the current debugging task requirements, the communication module can receive a wireless connection instruction from the user or automatically triggered by the system to trigger the wireless connection establishment process.

[0102] For example, when a user clicks the "Start Wireless Debugging" button on the human-machine interface of the debugging device, the communication module responds to the operation and starts the process of finding the IP address and establishing a wireless connection.

[0103] It should be understood that by establishing a wireless connection on top of an existing wired connection, a communication architecture can be formed between the domain controller and the debugging device that is "wired-centric with wireless as a supplement" or "both coexisting." The wired connection can be used for high-speed data transmission and power supply, while the wireless connection can be used for the transmission of low-bandwidth control commands or as a redundant backup for the wired link, thereby improving the reliability and flexibility of the connection while ensuring communication efficiency.

[0104] As a feasible implementation method, the communication module is specifically used to: find available IP addresses using preset priorities.

[0105] The preset priority is used to indicate that the priority of the system property reading command getprop, the compatible network interface query command ifconfig, and the standardized network address query command ip addr will be downgraded in turn.

[0106] Specifically, the communication module first executes the `getprop` command to attempt to read the network interface configuration information stored in the system properties to obtain the domain controller's IP address. If the `getprop` command fails or does not return a valid IP address, it then executes the `ifconfig` command to obtain the IP address by querying compatible network interface information. If the `ifconfig` command still fails to obtain a valid IP address, it further executes the `ip addr` command to obtain the IP address using a standardized network address lookup method. Through this step-by-step priority strategy, the communication module can be compatible with different versions and configurations of domain controller system environments, improving the success rate and adaptability of IP address acquisition.

[0107] For example, when the domain controller and the debugging device are connected via USB wired connection, the communication module receives a user-triggered wireless connection instruction, triggering the ADB wireless connection process. The communication module sends the getprop, ifconfig, and ip addr commands in descending order of priority, using a preset priority indicator, to obtain the available IP address of the domain controller.

[0108] After successfully obtaining a usable IP address from the domain controller, the communication module further executes the ADB wireless connection command using the usable IP address and a preset device port (e.g., the ADB default port 5555) to establish a wireless connection and perform wireless debugging. If a valid IP address is still not obtained after all commands of the preset priority have been executed, the communication module outputs a "wireless connection establishment failed" message and continues to maintain adb tcpip debugging communication via a wired connection to ensure the basic progress of the debugging task.

[0109] For example, such as Figure 5 As shown, the process initializes the ADB process; detects wired ADB connections; if the detection fails, outputs a connection error message; if the detection succeeds, receives a wireless connection indication; prioritizes executing the system property read command to obtain the available IP address of the domain controller; if the available IP address is invalid, executes the compatible network interface query command to obtain the available IP address of the domain controller; if the available IP address is invalid, executes the standardized network address query command to obtain the available IP address of the domain controller; if the available IP address is invalid, outputs a connection error message; if the available IP address is valid, enables wireless debugging; establishes a wireless connection and manages the connection status; outputs the available IP address and connection status to the log collection model; and simultaneously feeds back the connection status to the display module.

[0110] In some embodiments, the debugging apparatus further includes a display module; the display module is communicatively connected to the fault root cause tracing module 102.

[0111] As a feasible implementation method, the fault root cause tracing module 102 is also used to determine the fault propagation path from the first device to the fault root cause device; and send the fault propagation path and / or the fault root cause device to the display module so that the display module can display it.

[0112] In the exemplary embodiment, after the fault root cause tracing module 102 completes the entire tracing process, it encapsulates the determined fault propagation link (e.g., "panoramic imaging application module → image middleware module → camera driver module") and the finally located fault root cause device (e.g., "camera driver module") into diagnostic result data and sends it to the display module. After receiving and parsing the diagnostic result data, the display module presents a complete fault analysis report to the user in the form of a graphical interface.

[0113] As a feasible implementation method, the display module should include at least the following when presenting diagnostic results: visually displaying specific error log information and corresponding error text descriptions so that users can intuitively understand the fault phenomenon; displaying multi-level cross-module fault propagation links, presenting the complete propagation path of the fault from the upper-level manifestation to the downstream root cause in the form of topology diagrams or tree structures, and annotating the keyword matching results of each level; and highlighting the final root cause device and fault type in a prominent position on the interface to facilitate users to quickly locate the core of the problem.

[0114] Optionally, the debugging device also provides a manual debugging function. Users can manually enter the IP address of the wireless connection to the vehicle's infotainment system through the interactive interface of the display module and trigger the manual connection operation to flexibly adapt to the connection requirements in different debugging scenarios. Simultaneously, the debugging device also supports local log analysis. Users can select stored local log files for offline analysis, completing fault diagnosis without real-time connection to the domain controller.

[0115] As a feasible implementation, the display module sets time-consuming operations such as log collection, keyword matching, and cross-module tracing to be executed asynchronously. This avoids blocking the main interface thread and prevents interface lag from affecting the user experience. During the asynchronous operation execution, the display module continuously displays a loading animation to inform the user of the current operation status. At the same time, related interactive buttons are disabled during the asynchronous operation execution to prevent users from repeatedly triggering the same operation, which could lead to resource contention or process chaos. The buttons are restored to their available state after the operation is completed.

[0116] Optionally, the UI layout of the display module adopts a nested adaptive design, supporting free window scaling. All controls in the interface can automatically stretch and adapt according to changes in window size, ensuring good display effects and user experience across different screen sizes and resolutions, meeting the usage needs of after-sales and R&D personnel on different terminal devices. Through the above design, the debugging device can provide users with a fully visualized operation experience from fault triggering, log collection, cross-module tracing to result display, significantly improving the convenience and efficiency of fault diagnosis.

[0117] For example, such as Figure 6 As shown, the process starts the display module and initializes its UI layout; initializes the loading animation and button controls; receives user collection commands; triggers an asynchronous task, starts the loading animation, and disables the operation buttons; asynchronously executes time-consuming operations without blocking the UI thread; if execution fails, stops the loading animation, enables the operation buttons, and outputs an error message; if execution succeeds, stops the loading animation and enables the operation buttons; receives the fault propagation path and / or the root cause device; the UI interface scales adaptively; and displays the fault propagation path and / or the root cause device.

[0118] In some embodiments, such as Figure 7 As shown, the debugging device is specifically used for: dynamically loading modules (outputting module configuration upon completion of loading); multi-level progressive keyword diagnosis (first-level diagnosis (determining the second target keyword) and outputting preliminary faults; second-level diagnosis (determining the first target keyword) and converging the fault range); direct downstream device linkage tracing (tracing the first-level downstream module and outputting the fault module; recursively tracing multiple-level downstream modules and outputting the complete fault propagation path); and a display module that displays step-by-step information (first step: displaying multi-level diagnostic results; second step: displaying the tracing link; third step: displaying the complete root cause); UI window 1: core fault prompts; UI window 2: second device; UI window 3: fault root cause device and fault propagation path.

[0119] In some embodiments, such as Figure 8 As shown, the debugging device 100 specifically includes: a debugging bridge 801, a log acquisition module 101, a fault root cause tracing module 102, and a display module 802.

[0120] Specifically, the log acquisition module 101 collects online log information from the domain controller via the debug bridge 801, or directly obtains local log information from the domain controller; the log acquisition module 101 sends a normalized log file to the fault root cause tracing module 102, and simultaneously reports the acquisition status to the display module 802; the fault root cause tracing module 102 determines the fault root cause device and fault propagation path based on the log file, and sends the fault root cause device and fault propagation path to the display module 802; the display module 802 displays the fault root cause device and fault propagation path to the user or debug engineer.

[0121] In some embodiments, the debugging method provided in this application can be applied to the aforementioned debugging apparatus. For example... Figure 9 As shown, the debugging methods include: S901: Collect log information from the vehicle's central domain controller; generate log files based on the log information.

[0122] S902. In the event of a failure of the first device in the domain controller, repeat the first operation until the first condition is met.

[0123] The first operation involves exploring the second device based on the log information of the first device in the log file; updating the second device to the first device; the second device is the device that corresponds to the first target keyword among the direct downstream devices of the first device; the first target keyword is a keyword that has a mapping relationship with the keyword mapping set bound to the first device; the second target keyword is an abnormal keyword in the log information of the first device; and the first condition is that the second device cannot be explored.

[0124] S903. The first device that meets the first condition is identified as the root cause device of the fault.

[0125] like Figure 10 As shown, the electronic device 1000 includes, but is not limited to, a processor 1001 and a memory 1002.

[0126] The aforementioned memory 1002 is used to store the executable instructions of the aforementioned processor 1001. It is understood that the aforementioned processor 1001 is configured to execute instructions to implement the debugging method in the above embodiments.

[0127] It should be noted that those skilled in the art will understand that Figure 10 The electronic device structure shown does not constitute a limitation on electronic device 1000; electronic device 1000 may include, but is not limited to, other electronic devices. Figure 10 This may indicate more or fewer components, or combinations of certain components, or different component arrangements.

[0128] The processor 1001 is the control center of the electronic device 1000. It connects various parts of the electronic device via various interfaces and lines. By running or executing software programs and / or modules stored in the memory 1002, and by calling data stored in the memory 1002, it performs various functions and processes data of the electronic device 1000, thereby providing overall monitoring of the electronic device 1000. The processor 1001 may include one or more processing units. Optionally, the processor 1001 may integrate an application processor and a modem processor. The application processor mainly handles the operating system, user interface, and applications, while the modem processor mainly handles wireless communication. It is understood that the modem processor may not be integrated into the processor 1001.

[0129] The memory 1002 can be used to store software programs and various data. The memory 1002 may primarily include a program storage area and a data storage area. The program storage area may store the operating system, application programs required by at least one functional module (such as a determination unit, processing unit, etc.), etc. Furthermore, the memory 1002 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device.

[0130] In an exemplary embodiment, a computer-readable storage medium including instructions is also provided, such as a memory 1002 including instructions, which can be executed by a processor 1001 of an electronic device 1000 to implement the debugging method in the above embodiments.

[0131] Optionally, the computer-readable storage medium may be a non-transitory computer-readable storage medium, such as a read-only memory (ROM), random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device.

[0132] In an exemplary embodiment, this application also provides a computer program product including one or more instructions, which can be executed by the processor 1001 of the electronic device 1000 to complete the debugging method in the above embodiments.

[0133] It should be noted that when one or more instructions in the computer-readable storage medium or computer program product are executed by the processor of an electronic device, they implement the various processes of the above method embodiments and achieve the same technical effect as the above method. To avoid repetition, they will not be described again here.

[0134] Through the above description of the embodiments, those skilled in the art can clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0135] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another apparatus, or some features may be ignored or not executed. Furthermore, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0136] The units described as separate components may or may not be physically separate. A component shown as a unit can be one or more physical units; that is, it can be located in one place or distributed in multiple different locations. Some or all of the classified units can be selected to achieve the purpose of this embodiment, depending on actual needs.

[0137] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0138] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solution of the embodiments of this application, essentially, or the part that contributes to the prior art, or a complete or partial classification of the technical solution, can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.

[0139] The above embodiments are merely preferred embodiments provided to fully illustrate the present invention, and the scope of protection of the present invention is not limited thereto. Equivalent substitutions or modifications made by those skilled in the art based on the present invention are all within the scope of protection of the present invention.

Claims

1. A debugging device, characterized in that, The debugging device includes: a log acquisition module and a fault root cause tracing module; the log acquisition module and the fault root cause tracing module are communicatively connected. The log collection module is used to collect log information from the vehicle's domain controller; and generate log files based on the log information. The fault root cause tracing module is used to repeatedly execute a first operation when a first device in the domain controller fails, until a first condition is met; wherein, the first operation is to explore a second device based on the log information of the first device in the log file; update the second device to the first device; the second device is a device that corresponds to a first target keyword among the direct downstream devices of the first device; the first target keyword is a keyword that has a mapping relationship with the keyword mapping set bound to the first device; the second target keyword is an abnormal keyword in the log information of the first device; the first condition is that the second device cannot be explored; The fault root cause tracing module is also used to identify the first device that meets the first condition as the fault root cause device.

2. The debugging device according to claim 1, characterized in that, The debugging device further includes a debugging bridge; the fault root cause tracing module includes a first operation execution unit. The first operation execution unit is specifically used to send a debugging command to the debugging bridge so that the execution object of the debugging bridge executes the debugging command; The debugging command is used to instruct the log information of the first device retrieved from the log collection module to be placed into the target signal slot. The target signal slot triggers a first slot function after the log information from the first device arrives; wherein, the first slot function is used to retrieve the keyword set bound to the first device; based on the keyword set and the log information from the first device, determine the abnormal keywords in the log information from the first device; and determine the abnormal keywords as the second target keywords; The target signal slot triggers a second slot function after the first slot function has been executed; wherein, the second slot function is used to retrieve the keyword mapping set; based on the keyword mapping set and the second target keyword, the first target keyword is determined, the second device is determined based on the first target keyword, and an update instruction is output; the update instruction is used to instruct the second device to be updated to the first device.

3. The debugging device according to claim 2, characterized in that, The fault root cause tracing module further includes a repetitive execution unit; the repetitive execution unit is communicatively connected to the first operation execution unit. The repetitive execution unit is used to output the update instruction upon detecting the target signal slot, thereby triggering the update function; The update function is used to execute the update instruction when the second device is present in the update instruction, and to send a repeat instruction to the first operation execution unit after the update instruction is executed; the repeat instruction is used to instruct the first operation execution unit to send the debug command to the debug bridge again; And if the second device is not present in the update instruction, the first device in the update instruction is identified as the root cause device of the fault.

4. The debugging device according to claim 1, characterized in that, The first target keyword is used to indicate the device identifier of the device in the direct downstream device that has a causal relationship with the abnormal phenomenon corresponding to the abnormal keyword; The fault root cause tracing module is specifically used to: identify the device corresponding to the device identifier as the second device.

5. The debugging device according to claim 1, characterized in that, The log collection module is specifically used for: Collect online log information and / or local log information of the domain controller; the online log information is used to indicate logs stored in the vehicle communication device for transmission to devices outside the domain controller; The online log information and / or the local log information are normalized to obtain the log file; The normalization operations include encoding normalization and format normalization.

6. The debugging device according to claim 1, characterized in that, The debugging device further includes: a communication module; The communication module is used to find the available IP address of the domain controller when there is a wired connection between the domain controller and the debugging device and a wireless connection indication is received between the domain controller and the debugging device; and to establish a wireless connection between the domain controller and the debugging device using the available IP address.

7. The debugging device according to claim 6, characterized in that, The communication module is specifically used for: The available IP address is found using a preset priority; wherein the preset priority is used to indicate that the priority of the system attribute read command getprop, the compatibility network interface query command ifconfig, and the standardized network address query command ip addr are successively downgraded.

8. The debugging device according to claim 1, characterized in that, The debugging device further includes: a display module; the display module is communicatively connected to the fault root cause tracing module; The fault root cause tracing module is also used to determine the fault propagation path from the first device to the fault root cause device; and to send the fault propagation path and / or the fault root cause device to the display module so that the display module can display it.

9. A debugging method, characterized in that, Applied to the debugging apparatus as described in any one of claims 1-8; the debugging method includes; Collect log information from the vehicle's central domain controller; generate a log file based on the log information; In the event of a failure of the first device in the domain controller, the first operation is repeated until a first condition is met; wherein, the first operation is to explore a second device based on the log information of the first device in the log file; and update the second device to the first device; the second device is a device that corresponds to the first target keyword among the direct downstream devices of the first device; the first target keyword is a keyword that has a mapping relationship with the keyword mapping set bound to the first device; the second target keyword is an abnormal keyword in the log information of the first device; The first condition is that the second device cannot be detected; The first device that meets the first condition is identified as the root cause device of the fault.

10. A vehicle, characterized in that, The vehicle includes: a domain controller; the domain controller is communicatively connected to the debugging device according to any one of claims 1-8; the domain controller is configured to send log information to the debugging device in response to a data acquisition command sent by the debugging device, so that the debugging device can determine the root cause device of the fault based on the log information.

Images