Vehicle diagnostic methods, devices, equipment, and media

Abstract

This application relates to the field of vehicle technology, and particularly to a vehicle diagnostic method, apparatus, device, and medium. The method includes: receiving a first voice command while performing a first diagnostic task on a first vehicle, the first voice command requesting the execution of a second diagnostic task on the first vehicle, the first diagnostic task being different from the second diagnostic task; determining whether there is a resource conflict between the first and second diagnostic tasks, obtaining a determination result, whereby a resource conflict refers to multiple diagnostic tasks requiring the same communication channel resources during execution; and determining the execution mode of the second diagnostic task based on the determination result, the execution mode of the second diagnostic task being used to avoid resource conflict. Introducing conflict detection and dynamic scheduling mechanisms into the voice control process of vehicle diagnostics provides a solution for efficiently and reliably handling concurrent user diagnostic requests in a resource conflict environment.

Description

Technical Field

[0001] This application belongs to the field of vehicle technology, and in particular relates to a vehicle diagnostic method, device, equipment, and medium. Background Technology

[0002] In the field of modern automotive repair, technicians often use diagnostic equipment equipped with voice-activated AI (Artificial Intelligence). These devices have a built-in diagnostic app that allows users to invoke its functions via voice commands. This enables convenient operation of the equipment while both hands are on tools or the vehicle is in sight, thus improving efficiency.

[0003] The diagnostic process involves some high-risk operations, such as reprogramming the vehicle's ECU (Electronic Control Unit). These operations require a stable and continuous use of the vehicle's communication resources; interference from other diagnostic commands can easily lead to failure or even hardware damage.

[0004] To ensure the safety of such critical operations, related technologies typically employ a simple approach: when the system begins executing any diagnostic task, the voice interaction function is locked, directly rejecting all newly received voice commands. This approach results in a severe lack of system flexibility; technicians are unable to perform other voice operations during long-term tasks, forced to interrupt or wait, severely disrupting workflow and leading to a poor user experience. Summary of the Invention

[0005] This application provides a vehicle diagnostic method, apparatus, device, and medium that introduces conflict detection and dynamic scheduling mechanisms into the voice control process of vehicle diagnostics, providing a solution for efficiently and reliably handling concurrent user diagnostic requests in resource-occupancy conflict environments.

[0006] In a first aspect, embodiments of this application provide a vehicle diagnostic method, the method comprising: When performing a first diagnostic task on the first vehicle, a first voice command is received. The first voice command is used to request a second diagnostic task to be performed on the first vehicle. The first diagnostic task is different from the second diagnostic task. Determine whether there is a resource conflict between the first diagnostic task and the second diagnostic task, and obtain the judgment result. A resource conflict means that multiple diagnostic tasks need to occupy the same type of communication channel resources when they are executed. The execution method of the second diagnostic task is determined based on the judgment result. The execution method of the second diagnostic task is used to avoid resource occupation conflicts.

[0007] The beneficial effects of the first aspect are as follows: By receiving and responding to new voice diagnostic commands while executing the current diagnostic task, and intelligently judging communication resource conflicts between old and new tasks, the system dynamically determines the execution strategy for the new task. This effectively solves the technical problems in existing technologies, such as execution failure, low efficiency, system response delays, and poor user experience caused by multiple voice-triggered vehicle diagnostic tasks competing for limited communication channels. It improves the resource utilization efficiency and task execution success rate of the vehicle diagnostic system, enhances the real-time performance of the system response, and improves the smoothness of the user experience. Through conflict prediction and execution mode control, the access to channel resources is arranged in an orderly manner from the source, preventing excessive impact on the vehicle communication network, ensuring the reliability of the diagnostic communication process, and maintaining the overall stability of the vehicle bus system.

[0008] In one implementation, determining whether there is a resource conflict between the first diagnostic task and the second diagnostic task, and obtaining the determination result, includes: If either the first diagnostic task or the second diagnostic task does not require the use of communication channel resources, then the determination result is that there is no resource conflict between the first diagnostic task and the second diagnostic task. Communication channel resources refer to the session channel established when interacting with the electronic control system of the first vehicle; or... If both the first diagnostic task and the second diagnostic task require the use of communication channel resources, the judgment result is determined based on the first communication channel resources required by the first diagnostic task and the second communication channel resources required by the second diagnostic task.

[0009] In this implementation, a rapid screening of potential resource conflicts is achieved by initially distinguishing whether diagnostic tasks require the use of communication channel resources. If at least one task does not require channel resources, no complex channel type comparison is needed, and a conflict-free determination can be made immediately, significantly improving judgment efficiency and reducing system processing overhead. For tasks that all require resource usage, a more refined judgment mechanism is initiated, laying the foundation for accurate conflict detection in the future.

[0010] In one implementation, if both the first diagnostic task and the second diagnostic task require communication channel resources, the judgment result is determined based on the first communication channel resources required by the first diagnostic task and the second communication channel resources required by the second diagnostic task, including: If the types of the first communication channel resources and the second communication channel resources are different, then the judgment result is determined to be that there is no resource occupation conflict between the first diagnostic task and the second diagnostic task; or, If the first communication channel resource and the second communication channel resource are of the same type, the resource reconfiguration identifier of the second diagnostic task is obtained, and the judgment result is determined based on the resource reconfiguration identifier. The resource reconfiguration identifier is used to indicate whether it is allowed to allocate alternative communication channel resources for the second diagnostic task. The type of alternative communication channel resources is different from that of the second communication channel resource.

[0011] In this implementation, when two tasks both require communication channel resources, the system first determines whether the required channel resources are of the same type, thus accurately identifying resource conflict. If the types are different, the physical or logical channels themselves are not in contention, and a direct determination of no conflict can be made, simplifying the process. If the types are the same, a "resource reconfiguration flag" configuration parameter is introduced as a flexible judgment criterion. This allows the system to flexibly decide whether to avoid conflict by allocating alternative channels based on the characteristics of different tasks (such as real-time performance, importance, and protocol compatibility), enhancing the adaptability and flexibility of the solution to different diagnostic scenarios.

[0012] In one implementation, if the first communication channel resource and the second communication channel resource are of the same type, then the resource reconfiguration identifier of the second diagnostic task is obtained, and the judgment result is determined based on the resource reconfiguration identifier, including: If the resource reconfiguration flag indicates that alternative communication channel resources can be allocated for the second diagnostic task, then the determination result is that there is no resource conflict between the first and second diagnostic tasks; or, If the resource reconfiguration flag indicates that alternative communication channel resources are not allowed to be allocated for the second diagnostic task, then the judgment result is determined to be that there is a resource occupation conflict between the first diagnostic task and the second diagnostic task.

[0013] In this implementation, decision-making based on resource reconfiguration identifiers upgrades the technical solution from a binary judgment of conflict existence to an intelligent decision based on whether conflict can be resolved through resource reconfiguration. When reconfiguration is allowed, the system can proactively allocate alternative channels for tasks, thereby logically resolving conflicts and increasing the likelihood of parallel task execution. When reconfiguration is not allowed, it accurately determines the existence of a hard resource conflict, providing accurate input for subsequent implementation of other scheduling strategies (such as queuing or rejection). This mechanism maximizes the utilization of available communication resources while ensuring the correctness of diagnostic functions.

[0014] In one implementation, the execution method of the second diagnostic task is determined based on the judgment result, including: If the determination result indicates a resource conflict between the first diagnostic task and the second diagnostic task, then the second diagnostic task will not be executed, and a rejection message will be output; or, If the determination result is that there is no resource conflict between the first diagnostic task and the second diagnostic task, then the execution of the second diagnostic task is allowed.

[0015] In this implementation, the execution action is directly determined based on the conflict assessment result, resulting in clear logic and rapid response. For tasks with conflicts, a conservative strategy of refusing execution is adopted, effectively preventing diagnostic command confusion, communication timeouts, or even system failures caused by resource contention. This ensures the integrity of the ongoing primary diagnostic task and system stability, and clearly informs the user through prompts, improving the user experience. For tasks without conflicts, execution is immediately allowed, minimizing user waiting time and improving the response efficiency of the diagnostic system.

[0016] In one implementation, if the determination result indicates that there is no resource conflict between the first diagnostic task and the second diagnostic task, then after allowing the execution of the second diagnostic task, the following steps are also included: Control the first diagnostic task and the second diagnostic task to be executed simultaneously; or, If the jump execution conditions are met, the first diagnostic task is interrupted and the second diagnostic task is switched to execution; wherein the jump execution conditions include at least one of the following: the first diagnostic task does not need to occupy communication channel resources; the task level of the first diagnostic task is lower than the task level of the second diagnostic task; the task type of the first diagnostic task is configured to allow interruption.

[0017] In this implementation, after determining that there are no resource conflicts, various advanced task scheduling strategies are provided to achieve fine-grained management and optimized resource allocation for multiple diagnostic tasks. Simultaneously, the execution strategies fully utilize the system's parallel processing capabilities and idle communication resources, improving overall diagnostic efficiency. The conditional jump execution strategy introduces a set of intelligent interruption rules based on task attributes (such as resource occupancy status, priority, and interruptibility), enabling the system to dynamically respond to higher-priority or more urgent user requests, achieving on-demand allocation of diagnostic resources and meeting the need for flexible task scheduling in complex diagnostic scenarios.

[0018] In one implementation, controlling the simultaneous execution of the first diagnostic task and the second diagnostic task includes: The diagnostic running interface displays the execution progress of the first and second diagnostic tasks simultaneously in a split-screen display mode.

[0019] In this implementation, split-screen display technology visually and synchronously presents the execution progress of multiple concurrent diagnostic tasks to the user. This not only enhances the user's awareness of the parallel execution status of complex background tasks, allowing them to easily grasp the progress of each diagnostic, but also significantly improves the information capacity and user-friendliness of the interface. This visualized feedback on parallel processing enhances the user's trust in the system's intelligent scheduling capabilities, making it a key element in improving the human-computer interaction experience.

[0020] Secondly, embodiments of this application provide a vehicle diagnostic device, including: The interface module is used to receive a first voice command when performing a first diagnostic task on the first vehicle. The first voice command is used to request the performance of a second diagnostic task on the first vehicle. The first diagnostic task is different from the second diagnostic task. The processing module is used to determine whether there is a resource occupation conflict between the first diagnostic task and the second diagnostic task, and obtain the judgment result. The resource occupation conflict refers to the fact that multiple diagnostic tasks need to occupy the same communication channel resources when they are executed. The processing module is also used to determine the execution method of the second diagnostic task based on the judgment result. The execution method of the second diagnostic task is used to avoid resource occupation conflicts.

[0021] Thirdly, this application also provides an electronic device. The electronic device includes a memory, one or more processors, and a computer program stored in the memory and executable on the processor. The electronic device executes the computer program to implement any of the implementations of the first aspect described above.

[0022] Fourthly, this application also provides a computer-readable storage medium. The computer-readable storage medium stores a computer program, which, when executed by a processor, implements the method of any of the implementations of the first aspect described above.

[0023] Fifthly, this application also provides a computer program product that, when run on an electronic device, causes the electronic device to execute any of the implementation methods of the first aspect described above.

[0024] It is understood that the beneficial effects of the second to fifth aspects mentioned above can be found in the relevant descriptions in the first aspect above, and will not be repeated here. Attached Figure Description

[0025] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0026] Figure 1 This is a schematic diagram of the architecture of a vehicle diagnostic system provided in one embodiment of this application; Figure 2 This is a flowchart of a vehicle diagnostic method provided in an embodiment of this application; Figure 3 This is a schematic diagram showing the changes in the execution progress of the first diagnostic task and the second diagnostic task displayed on the same screen before and after, according to an embodiment of this application. Figure 4 This is a structural block diagram of an apparatus for processing employee change records according to an embodiment of this application; Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0027] In the modern automotive repair field, diagnostic equipment based on intelligent mobile platforms has become a standard operating tool. These devices typically feature a voice AI interaction system and run a professional diagnostic app. Technicians can directly access various diagnostic functions within the app using natural voice commands, enabling efficient, contactless operation control even when both hands are holding tools and their eyes are simultaneously focused on vehicle components and the equipment screen. This significantly improves the convenience and continuity of the repair process. To further enhance the interactive experience, related technologies allow voice AI to respond globally across different functional pages of the application. This means technicians can issue commands to execute other tasks from any interface. While this increases operational freedom and user experience, it also introduces new operational risks.

[0028] Vehicle diagnostics encompasses various operation types, some of which are high-risk operations requiring extremely high system stability. A typical example is online reprogramming of the vehicle's ECU. Reprogramming refers to erasing and writing to the non-volatile memory (usually flash memory) inside the vehicle's electronic control unit via a diagnostic communication interface to install new control programs or calibration data.

[0029] During the execution of this type of operation, the diagnostic communication channel with the target ECU must be exclusively occupied, and the transmission of commands must be absolutely continuous and undisturbed. Any other diagnostic commands executed concurrently that may occupy the same communication resources will interrupt the process, causing programming failure at best, and permanent damage to the ECU at worst.

[0030] For example, during ECU remapping, if a technician issues a command to clear fault codes via voice, it will trigger typical resource conflicts and process disruptions. At this time, the diagnostic equipment is maintaining a high-privilege, exclusive programming session with the target ECU (such as the engine ECU) through a single diagnostic communication channel, and continuously sending programming data packets with high priority.

[0031] Clearing fault codes also requires initiating a standard diagnostic session request to the same ECU through the same communication channel. These two sessions are mutually exclusive at the protocol level; forcibly inserting them can cause bus arbitration chaos or ECU session state machine errors, resulting in interruption of the programming data stream.

[0032] This will cause the ECU flashing process to fail completely. The ECU will have neither a complete old program nor a complete new program, losing all executable code and thus becoming an unbootable electronic component, requiring expensive and complex offline repair or direct replacement.

[0033] To ensure the security of such critical operations, related technologies generally employ a conservative mutual exclusion strategy. The core of this strategy can be summarized as "what you see is what you do" and "task exclusivity": First, the triggering scope of voice commands is strictly limited to the currently displayed functional page; that is, technicians can only trigger functions supported by the current page. Second, as long as a task is being executed on the current page, the system will not respond to any other voice commands. While this one-size-fits-all blocking mechanism is logically simple and avoids conflict risks, it directly leads to significant drawbacks such as low system intelligence and poor operational flexibility. The system cannot intelligently determine the actual risks and resource requirements of new voice commands, resulting in the arbitrary rejection of many inherently safe and reasonable requests that do not compete with the current task for resources. Consequently, when technicians are performing long diagnostic or programming tasks, they cannot initiate any auxiliary operations in parallel via voice; they must passively wait for the current task to finish or manually interrupt the process. This severely disrupts the natural rhythm of the work and the continuity of thought, making it impossible to realize the convenient interactive advantages advocated by voice AI, ultimately leading to a significant decline in user experience.

[0034] Therefore, this application provides a vehicle diagnostic method to solve the above-mentioned problems. The core of this method lies in the intelligent judgment and arbitration of communication channel resource occupation conflicts between concurrent diagnostic tasks. Specifically, after receiving a voice command requesting the execution of a second diagnostic task during the execution of a first diagnostic task, the system first determines whether there is a resource occupation conflict between the two tasks: if either the first or second diagnostic task is of a type that does not require communication channel resources, it is directly determined that there is no conflict; if both tasks require resources, the types of resources required by the two tasks are further compared. If the types are different, it is determined that there is no conflict; if the types are the same, the system queries the resource reconfiguration identifier pre-configured for the second diagnostic task. If the identifier indicates that alternative communication channel resources of different types can be allocated, it is determined that there is no conflict; otherwise, it is determined that there is a conflict. Based on the final conflict judgment result, the system determines the execution mode of the second diagnostic task, including: refuse execution or allow execution. If there is a conflict, the execution of the second diagnostic task is refused and a prompt is given; if there is no conflict, execution is allowed. When execution is allowed, the two tasks can be controlled to execute concurrently (e.g., through split-screen display), or the current task can be interrupted to execute a new task when specific conditions are met.

[0035] Through the refined arbitration mechanism based on resource conflict analysis, this method can safely allow multiple diagnostic tasks to run concurrently while ensuring that high-risk operations have exclusive access to communication resources and are absolutely free from interference. This effectively balances the security of diagnostic operations, the flexibility of system operation, and user experience.

[0036] Figure 1 This is a schematic diagram of the architecture of a vehicle diagnostic system provided in an embodiment of this application. The system 100 mainly consists of a diagnostic device 110, a VCI (Vehicle Communication Interface) diagnostic box 120, a vehicle electronic control system 130, and a remote cloud server 140.

[0037] The system 100 uses a diagnostic device 110 (such as an Android tablet) equipped with a professional diagnostic app as its intelligent core. The diagnostic device 110 connects to the VCI diagnostic box 120 wirelessly (Bluetooth / Wi-Fi) or via wired connection. The VCI diagnostic box 120 then connects to the vehicle's internal network bus via a physical cable inserted into the vehicle's standardized diagnostic interface, for example, through the OBD-II (On-Board Diagnostics) port. The vehicle contains multiple Electronic Control Units (ECUs) distributed across different subsystems (such as the engine, transmission, and body), which together constitute the vehicle's electronic control system 130. Furthermore, the diagnostic device 110 can independently access a remote cloud server 140 to obtain data via a mobile network.

[0038] In system 100, when a user issues a command via voice, the processing module within diagnostic device 110 converts it into a structured diagnostic task request. If system 100 is currently executing a task, the task scheduler will initiate an arbitration process: querying the resource rule base to obtain attribute data such as the target ECU and required communication channels for the new and old tasks, and the conflict judgment engine will determine whether there is a resource occupation conflict based on preset rules (such as whether it is for the same ECU or whether a dedicated channel is required).

[0039] After arbitration, system 100 performs traffic control based on the result. If the task is allowed to be executed and is vehicle-oriented, the diagnostic command is sent to the VCI diagnostic box 120, which converts it into a vehicle bus signal and transmits it to the target ECU through the diagnostic interface. The ECU's response data returns along the original path, is parsed, and displayed. If the task is only an information query, the diagnostic device 110 communicates directly with the remote server and presents the result. If the task is prohibited due to a conflict, system 100 will suppress the issuance of the command and prompt the user with the reason for the rejection via voice.

[0040] Through the aforementioned intelligent scheduling mechanism based on resource conflict judgment, System 100 can perform safe management of concurrent voice tasks that target different ECUs and occupy different channel resources. While ensuring the absolute safety of critical operations such as flashing specific ECUs, it effectively improves the flexibility of operation and user experience.

[0041] Figure 2 This is a flowchart of a vehicle diagnostic method provided in an embodiment of this application. The method can be performed by a diagnostic device or... Figure 1 The system 100 shown executes a method that includes the following steps.

[0042] S201, when performing a first diagnostic task on the first vehicle, receives a first voice command.

[0043] The first voice command is used to request the execution of a second diagnostic task on the first vehicle. The first diagnostic task is different from the second diagnostic task.

[0044] The diagnostic equipment establishes a physical connection with the first vehicle via a VCI diagnostic box. Specifically, one end of the VCI diagnostic box connects to the vehicle's OBD-II diagnostic interface, while the other end communicates with the diagnostic equipment, thus establishing a data exchange path between the diagnostic equipment and the vehicle's electronic control system. In this connected state, a professional diagnostic app running on the diagnostic equipment can perform various diagnostic operations on the first vehicle. To enhance ease of use, the diagnostic app integrates a voice AI interaction module. When a user (e.g., a repair technician) issues commands via natural language, the voice AI module, based on its pre-deployed internal model, recognizes and parses the voice signal into corresponding executable diagnostic tasks within the app.

[0045] To achieve secure and intelligent scheduling of concurrent tasks, during the deployment phase, security levels were pre-classified for various functions within the diagnostic app, and corresponding operable settings were configured to build a rule base for task scheduling. This classification is primarily based on whether a function needs to interact with the vehicle through the VCI diagnostic box and the degree of its impact on the vehicle; for example, it can be divided into the following three levels: (1) Basic APP functions: These functions only involve the visualization of data, such as viewing diagnostic reports, accessing the repair community, and browsing the diagnostic history list. Its characteristic is that the data comes from a remote cloud server and does not communicate with the vehicle's electronic control system through the connected VCI diagnostic box, so there is no operational risk.

[0046] (2) Basic diagnostic functions: These functions require communication with the vehicle's electronic control system via the VCI diagnostic box, but are limited to reading information, such as reading the version information of the vehicle's ECU, reading the current fault codes, and reading real-time data streams. Its characteristic is that it does not modify any electronic control system data, and the risk is low.

[0047] (3) Complex diagnostic functions: These functions require writing or complex control of the vehicle's electronic control system through the VCI diagnostic box, such as ECU flashing and programming, DPF (Diesel Particulate Filter) regeneration, actuator operation testing, etc. The operation process requires exclusive access to communication resources and cannot be interrupted, which is extremely risky.

[0048] Any diagnostic task mentioned in this application, such as the first diagnostic task and the second diagnostic task, refers to any two possible scheduled function instances provided by the diagnostic APP according to the above classification rules.

[0049] In other words, when any function is invoked, a corresponding diagnostic task will be started. This diagnostic task is a specific functional instance of the function, used to realize the function's impact on the vehicle.

[0050] The aforementioned security levels and corresponding scheduling rules are integrated into the decision-making model of the voice AI through the intelligent voice AI training process. This enables the AI ​​to understand the user's command intent while associating the inherent risks and resource requirements of the task, laying the foundation for subsequent conflict judgment.

[0051] Among them, the risk level of the APP's basic functions is lower than the risk level of the basic diagnostic functions, which is lower than the risk level of the complex diagnostic functions. Correspondingly, the task risk level of a diagnostic task implemented by calling the APP's basic functions is lower than the task risk level of a diagnostic task implemented by calling the basic diagnostic functions, which is lower than the task risk level of a diagnostic task implemented by calling the complex diagnostic functions.

[0052] For example, when a user says "Check the engine fault codes" to the diagnostic equipment connected to the first vehicle, the integrated voice AI interaction module immediately initiates its workflow. At its core is a domain-optimized natural language understanding model. It first converts the command into text through automatic speech recognition, then performs intent recognition and entity extraction to accurately parse the user's core intent as: to perform diagnostic readings and extract the key entities "engine" and "fault codes." Based on this analysis, the model maps this command to the predefined "read fault codes" function in the diagnostic app's function library, thereby generating a structured diagnostic task request targeting the engine system that can be directly scheduled by the system.

[0053] At the same time, based on the pre-built rule base, the system immediately associates the inherent attributes of this task request: the function is classified as a basic diagnostic function, which means that it has a medium risk level, requires the use of specific diagnostic channel resources for communication with the vehicle's engine ECU when executed, and the operation is read-only and does not modify any vehicle data.

[0054] The training process for the voice AI interaction module within the diagnostic app is as follows: First, a large number of real voice commands and operation logs from various maintenance scenarios are collected, and experts annotate their corresponding standardized function IDs and parameters. Then, this annotated data is used to train a pre-set large language model, enabling it to learn the professional expressions and functional mapping relationships in the vehicle maintenance field. Finally, during the model deployment phase, the aforementioned functional safety level classification and scheduling rules are integrated as prior knowledge into the decision-making process. This achieves a seamless connection from voice interaction to safety scheduling decisions.

[0055] S202, determine whether there is a resource conflict between the first diagnostic task and the second diagnostic task, and obtain the judgment result.

[0056] Resource conflict refers to the situation where multiple diagnostic tasks need to occupy the same communication channel resources during execution. Communication channel resources refer to the session channels established when interacting with the electronic control system of the first vehicle.

[0057] The first vehicle's electronic control system contains multiple independent electronic control units (ECUs). Therefore, interacting with the electronic control system operationally involves exchanging diagnostic data with a specific ECU or group of ECUs. Thus, communication channel resources essentially refer to an exclusive logical session or physical connection established and maintained for diagnostic data exchange with a specific ECU of the first vehicle. Specifically, communication channel resources can be implemented in one or a combination of the following forms.

[0058] (1) Logical session: For example, a diagnostic dialogue context established with the engine ECU based on diagnostic protocols such as UDS (Unified Diagnostic Services) and KWP2000 (Keyword Protocol 2000) and has specific access permissions (such as default session, extended diagnostic session, high-risk programming session).

[0059] (2) Physical / logical connection: For example, a dedicated hardware communication channel in the VCI diagnostic box, or a message identifier and communication bandwidth allocated to a specific diagnostic communication on the vehicle's internal network (such as CAN bus, LIN bus).

[0060] This step S202 executes a hierarchical and progressive judgment logic based on the risk level of the functional type of the diagnostic task and the actual resource requirements. Its core is to assess whether the two diagnostic tasks' requests for the above-mentioned communication channel resources will constitute non-shareable competition, which can be divided into the following situations.

[0061] 1. If there is a task in the first diagnostic task and the second diagnostic task that does not require the use of communication channel resources, then the judgment result is that there is no resource usage conflict between the first diagnostic task and the second diagnostic task.

[0062] For example, tasks that do not require the use of communication channel resources refer to tasks that invoke basic APP functions. First, check if any of the first and second diagnostic tasks are classified as basic APP functions. These tasks (such as viewing repair data) source their data from a remote cloud server and do not communicate with the vehicle through the VCI diagnostic box at all; therefore, they do not require the use of any vehicle communication channel resources. Consequently, there is no conflict regarding communication channel resources.

[0063] (1) Both the first and second diagnostic tasks do not require the use of communication channel resources.

[0064] For example, the first diagnostic task is "viewing historical diagnostic reports," and the second diagnostic task is "browsing the repair community." Both are basic functions of the app and do not consume vehicle communication resources, therefore they are determined to be conflict-free.

[0065] (2) The first diagnostic task is a task that does not require the use of communication channel resources, while the second diagnostic task is a task that requires the use of communication channel resources.

[0066] For example, the first diagnostic task is "querying the circuit diagram" (a basic function of the app), and the second diagnostic task is "reading engine fault codes" (a basic diagnostic function). Since the first task does not consume communication resources, the two can be safely performed in parallel, and are determined to be conflict-free.

[0067] (3) The first diagnostic task is a task that requires the use of communication channel resources, and the second diagnostic task is a task that does not require the use of communication channel resources.

[0068] For example, the first diagnostic task is "perform a full vehicle system scan" (basic diagnostic function), and the second diagnostic task is "open the repair case library" (basic APP function). Since the second task does not consume communication resources, it is determined to be conflict-free.

[0069] If neither the first diagnostic task nor the second diagnostic task belongs to the basic functions of the APP (i.e., both are basic diagnostic functions or complex diagnostic functions), it means that both need to interact with the vehicle through the VCI diagnostic box, and further judgment is needed to determine whether there is a conflict.

[0070] 2. Alternatively, if both the first diagnostic task and the second diagnostic task are tasks that require the use of communication channel resources, the judgment result shall be determined based on the first communication channel resources required by the first diagnostic task and the second communication channel resources required by the second diagnostic task.

[0071] For example, tasks that require communication channel resources refer to tasks executed by calling basic or complex diagnostic functions. Therefore, when neither the first nor the second diagnostic task belongs to the basic functions of the app, it means that both are tasks that require communication channel resources. The system needs to further compare whether the communication channel resources required by the two tasks conflict.

[0072] 2.1 If the types of the first communication channel resources and the second communication channel resources are different, then the judgment result is determined to be that there is no resource occupation conflict between the first diagnostic task and the second diagnostic task.

[0073] The difference in type here refers to the fact that the communication channel resources required by the two diagnostic tasks do not overlap or compete in key attributes, and do not need to use the same communication channel. This is mainly reflected in the following situations: (1) For different target ECUs: The two diagnostic tasks need to communicate with different electronic control units on the first vehicle.

[0074] For example, the first diagnostic task is "reading engine data stream" (the type of the first communication channel resource is: a diagnostic session established with the engine ECU), and the second diagnostic task is "clearing vehicle fault codes" (the type of the second communication channel resource is: a diagnostic session established with the vehicle ECU). Since they target different ECUs and have different resource types, they are determined to be conflict-free.

[0075] For example, the first diagnostic task is "to flash the transmission ECU" (the type of the first communication channel resource is an exclusive programming session established with the transmission ECU), and the second diagnostic task is "to read the wheel speed sensor data of the ABS" (the type of the second communication channel resource is a diagnostic session established with the ABS (Antilock Braking System) ECU). Since these two tasks target different ECUs and typically use independent communication paths with different resource types, they are considered to be conflict-free.

[0076] (2) Use physically or logically independent communication paths: if the VCI diagnostic box supports multiple independent channels and the two diagnostic tasks are assigned to different channels; or, the two diagnostic tasks use different, non-interfering communication identifiers in the vehicle network.

[0077] The first diagnostic task is "monitoring the data flow of the engine ECU via channel A" (basic diagnostic function), and the second diagnostic task is "calibrating the parameters of the engine ECU via channel B" (complex diagnostic function). This scenario requires the VCI diagnostic box to have multiple independent hardware channels (such as channel A and channel B), and the engine ECU to support concurrent access through different physical paths or logical sessions. Although the two tasks target the same engine ECU, they use physically isolated communication paths (channel A and channel B) and have different resource types (defined by "target ECU + specific path"), so they can still be determined to be conflict-free.

[0078] If the first communication channel resource and the second communication channel resource are of the same type, it indicates that the two tasks are requesting to use the same critical resource, which may cause a potential conflict. In this case, it is necessary to further determine whether the diagnostic task allows the re-establishment of the communication channel resource.

[0079] 2.2 Alternatively, if the first communication channel resource and the second communication channel resource are of the same type, the resource reconfiguration identifier of the second diagnostic task is obtained, and the judgment result is determined based on the resource reconfiguration identifier. The resource reconfiguration identifier is used to indicate whether it is allowed to allocate alternative communication channel resources for the second diagnostic task. The type of the alternative communication channel resource is different from the type of the second communication channel resource.

[0080] When two tasks require the same type of resources, the system will query the resource reconfiguration identifier pre-configured for the second diagnostic task. This identifier indicates whether the system is allowed to attempt to allocate a different type of alternative communication channel resource to the second diagnostic task to resolve the conflict when such a resource conflict occurs.

[0081] 2.2.1 If the resource reconfiguration flag indicates that alternative communication channel resources can be allocated for the second diagnostic task, then the determination result is that there is no resource occupation conflict between the first diagnostic task and the second diagnostic task.

[0082] For example, in this scenario, although the two tasks initially request the same type of resource, the system is able to successfully allocate alternative resources for the second diagnostic task because the second diagnostic task is configured to "allow reconfiguration" and the system has available alternative resources (such as another idle hardware channel of the VCI), thereby resolving the conflict.

[0083] For example, the first diagnostic task is a high-risk "engine ECU flashing" (its resource type is: exclusive programming session established with the engine ECU), and the second diagnostic task is "reading engine coolant temperature" (a basic diagnostic function, which usually also requires communication with the engine ECU). Both initially have the same resource type, resulting in a high risk of conflict. However, the "reading engine coolant temperature" function is pre-configured to allow reconfiguration, and the system detects that the VCI diagnostic box has another independent channel that can connect to the engine ECU. The system then allocates this alternative channel to the read task, thereby resolving the conflict and determining it as conflict-free.

[0084] 2.2.2 Alternatively, if the resource reconfiguration flag indicates that alternative communication channel resources are not allowed to be allocated for the second diagnostic task, then the judgment result is determined to be that there is a resource occupation conflict between the first diagnostic task and the second diagnostic task.

[0085] For example, in this case, since the second diagnostic task is configured to "disable reconfiguration", or although it is allowed but there are no available alternative resources in the system, the conflict cannot be resolved by resource reconfiguration, and therefore a conflict is determined to exist.

[0086] For example, the first diagnostic task is "engine ECU flashing," and the second diagnostic task is "performing an engine cylinder balance test" (a complex diagnostic function requiring exclusive control interaction with the engine ECU). Both have highly similar resource types (both require establishing a high-privilege control session with the engine ECU). Furthermore, the "performing an engine cylinder balance test" function is pre-configured to prevent reconfiguration, or the current VCI diagnostic box has no other available channels. The conflict cannot be resolved, therefore it is determined to be a resource usage conflict.

[0087] S203, determine the execution method of the second diagnostic task based on the judgment result.

[0088] The execution method of the second diagnostic task is used to avoid resource occupation conflicts. The purpose of this step is to select a safe and efficient task execution mode based on the resource competition relationship and task attributes between diagnostic tasks.

[0089] Optionally, if the judgment result indicates that there is a resource conflict between the first diagnostic task and the second diagnostic task, the second diagnostic task will be refused to be executed, and a rejection message will be output.

[0090] For example, when it is determined that two tasks have a resource conflict, a conservative rejection strategy will be adopted to ensure the absolute safety and continuous execution of the first diagnostic task (especially the high-risk task).

[0091] The system (or diagnostic device) will suppress the issuance of instructions for the second diagnostic task, that is, it will not send any requests related to the task to the VCI diagnostic box or remote server.

[0092] Simultaneously, the system outputs a clear rejection message to the user through the diagnostic device's speech synthesis module or graphical interface. This message should clearly explain the reason for the rejection, such as a voice announcement: "A critical operation is currently in progress and this command cannot be executed. Please try again later."

[0093] For example, when performing the first diagnostic task "Engine ECU flashing" (complex diagnostic function), if the user requests the second diagnostic task "Read engine data stream" (basic diagnostic function), the system will refuse to read the task and output a voice prompt message: "The second diagnostic task cannot be performed at present" because the communication channel resources occupied are of the same type and the resource reconfiguration indicator for this task prohibits reconfiguration.

[0094] Alternatively, if the determination result indicates that there is no resource conflict between the first diagnostic task and the second diagnostic task, then the execution of the second diagnostic task is allowed.

[0095] For example, when the system determines that there are no resource conflicts between tasks, the second diagnostic task will be allowed to execute. The specific execution method needs to be selected based on task attributes, user configuration, and system status. In this case, there are several execution methods, mainly including: (1) Control the simultaneous execution of the first diagnostic task and the second diagnostic task.

[0096] While maintaining the execution of the first diagnostic task, resources are scheduled to start the second diagnostic task, and the two tasks run in parallel logically.

[0097] For example, the execution progress of the first diagnostic task and the second diagnostic task can be displayed simultaneously in a split-screen manner on the diagnostic running interface.

[0098] Split-screen display provides users with intuitive feedback on the parallel status of tasks, enhancing the interactive experience and information transparency, allowing users to monitor the progress of multiple diagnostic operations simultaneously without switching interfaces.

[0099] Please refer to Figure 3 , Figure 3 This is a diagram showing the progress of the first and second diagnostic tasks displayed on the same screen before and after the execution.

[0100] like Figure 3 As shown, in the diagnostic operation interface 300, before receiving a voice command, the execution status of the first diagnostic task 310 is displayed in full screen. When the voice command is received and it is determined that the second diagnostic task 320 requested by the voice command can be executed simultaneously, the execution status of the first diagnostic task 310 and the second diagnostic task 320 are displayed simultaneously in a split-screen layout.

[0101] The first diagnostic task 310 area displays its corresponding progress information (first task progress 311) and real-time status information (first task status 312) (e.g., in progress, paused, or interrupted). The first task progress 311 is presented as a progress bar to indicate the percentage of completion of the first diagnostic task 310. The first task status 312 is highlighted to show the current task execution status. Figure 3 The first task status 312 corresponds to the "In Progress" status, indicating that the first diagnostic task 310 is being executed normally. The "Pause" and "Interrupt" task statuses are optional. If the user selects "Pause," the first diagnostic task 310 will pause execution until the user reselects "In Progress," at which point execution will resume from the paused point. If the user selects "Interrupt," the first diagnostic task 310 will stop execution until the user reselects "In Progress," at which point execution will restart from a progress point of 0.

[0102] Correspondingly, the second diagnostic task 320 area also displays its corresponding progress information (second task progress 321) and real-time status information (second task status 322).

[0103] This split-screen interface intuitively reflects the scenario where two tasks are executed in parallel without resource conflicts, allowing users to clearly grasp the progress and status of each task at a glance.

[0104] Before and after displaying the relevant task information of the first diagnostic task 310 and the second diagnostic task 320 in split-screen / simultaneous display, the information presented by the first diagnostic task 310 in the diagnostic operation interface 300 remains unchanged; the only difference is that its display area becomes smaller. When the task information of the first diagnostic task 310 and the second diagnostic task 320 are displayed in the same screen, the user can manually adjust the display area of ​​each task in the diagnostic operation interface 300.

[0105] (2) Alternatively, if the jump execution conditions are met, the first diagnostic task is interrupted and the second diagnostic task is switched to execution. The jump execution conditions include at least one of the following.

[0106] [1] The first diagnostic task does not require the use of communication channel resources; When the first diagnostic task being performed does not occupy the communication channel with the first vehicle at all, since it does not involve direct operation or access to the first vehicle, the system can safely interrupt the task to respond to new user requests that may require resource consumption.

[0107] For example: A user is currently browsing the cloud-based repair community (a basic app function that does not require communication channels) through the diagnostic interface. At this moment, the user gives the voice command "Read engine fault codes." The system determines that the new task (basic diagnostic function) requires communication resources, while the current task does not, thus meeting the redirection criteria. The system will interrupt the community browsing interface, automatically redirect to the fault code reading function page, and begin executing the new task.

[0108] [2] The task level of the first diagnostic task is lower than that of the second diagnostic task; When a new diagnostic task is requested that has a higher security or priority level than the current task, the system may interrupt the lower-level task in order to respond to the more urgent or important operation.

[0109] For example: A user is reading the vehicle module data stream (basic diagnostic function, task level: medium) when suddenly a serious warning light appears on the vehicle's instrument panel. The user immediately requests an emergency ECU remapping to repair the control program via voice command (complex diagnostic function, task level: high). The system determines that the new task is of a higher level and may pose a safety risk requiring immediate attention, thus meeting the jump criteria. The system will interrupt the data stream reading and prioritize switching to the ECU remapping process.

[0110] [3] The task type for the first diagnostic task is configured to allow interrupts.

[0111] Some diagnostic tasks are marked as interruptible during the functional design phase, which means that such diagnostic tasks can be safely paused during execution without causing operational failure, data loss, or device damage.

[0112] For example: A user is performing a full vehicle system scan (basic diagnostic function), which is marked as "interruptible" in the configuration. During the scan, the user requests a specific actuator action test via voice (complex diagnostic function). The system detects that the current scan task is of the "interruptible" type, meeting the jump condition. The system will pause the scan process, save the current progress, then switch to the action test interface and execute the new task. After the test is completed, the system will prompt the user whether to resume the previous scan.

[0113] For example, to support flexible scheduling and collaborative execution between diagnostic tasks, various operation setting strategies are provided based on the function types corresponding to the first and second diagnostic tasks, and each case is summarized and explained below.

[0114] (1) When both the first diagnostic task and the second diagnostic task are basic functions of the APP; It supports direct navigation or seamless switching between functions. For example, if the first diagnostic task is to view repair cases and the second diagnostic task is to view the diagnostic report, you can directly jump to the report page; or if the first diagnostic task is to view the diagnostic report and the second diagnostic task is to switch the system language to English, the system can automatically switch the language without needing to enter the settings page.

[0115] (2) When the first diagnostic task is the basic function of the APP and the second diagnostic task is the basic diagnostic function; New tasks can be executed via navigation or split-screen mode. For example, if the first diagnostic task is to view the diagnostic report and the second diagnostic task is to read fault codes, the system can navigate to the code reading page or display both the report and the code reading progress in a split-screen mode.

[0116] (3) When the first diagnostic task is a basic function of the APP and the second diagnostic task is a complex diagnostic function; It also supports switching between screens or split-screen execution. For example, if the first diagnostic task is browsing the community and the second diagnostic task is performing ECU flashing, the system can automatically switch to the flashing interface or use a split-screen method to display both the community and the flashing progress simultaneously.

[0117] (4) When the first diagnostic task is a basic diagnostic function and the second diagnostic task is a basic APP function; Accessibility features can be accessed via split-screen mode. For example, if the first diagnostic task is to view the data stream and the second diagnostic task is to open the diagnostic report, the data stream and report pages can be displayed simultaneously in split-screen mode to assist in repair analysis.

[0118] (5) When the first diagnostic task is a basic diagnostic function and the second diagnostic task is another basic diagnostic function; If two tasks do not occupy the same electronic control system resources, synchronous execution is supported; otherwise, parallel operation is not supported by default. For example, if the first diagnostic task is to scan the engine system and the second diagnostic task is to scan the body system, they can be executed simultaneously; however, if both the first and second diagnostic tasks are to scan the engine system, parallel execution is not supported.

[0119] (6) When the first diagnostic task is a basic diagnostic function and the second diagnostic task is a complex diagnostic function; By default, synchronous execution is not supported; parallel execution is only allowed when two tasks do not consume the same system resources. For example, if the first diagnostic task is reading the engine data stream and the second diagnostic task is performing an engine ECU remapping, they cannot be performed in parallel. However, if the first diagnostic task is reading the engine data stream and the second diagnostic task is scanning the braking system, they can be performed synchronously. The system will provide voice prompts for situations where synchronization is not supported.

[0120] (7) When the first diagnostic task is a complex diagnostic function and the second diagnostic task is a basic APP function; It supports accessing APP functions via split-screen mode. For example, if the first diagnostic task is ECU remapping and the second diagnostic task is viewing repair data, the data can be opened via voice AI commands in split-screen mode, improving operational convenience.

[0121] (8) When the first diagnostic task is a complex diagnostic function and the second diagnostic task is a basic diagnostic function: By default, synchronous execution is not supported; parallel execution is only allowed when task resources do not conflict. For example, if the first diagnostic task is engine ECU remapping and the second diagnostic task is reading engine data streams, parallel execution is not supported. However, if the first diagnostic task is engine ECU remapping and the second diagnostic task is scanning the vehicle body system, they can be performed synchronously. The system will provide voice prompts indicating when execution is not supported.

[0122] (9) When both the first diagnostic task and the second diagnostic task are complex diagnostic functions: Synchronous execution is generally not supported, especially when two tasks involve the same electronic control system. For example, if the first diagnostic task is engine ECU flashing and the second diagnostic task is engine immobilizer matching, the system prohibits simultaneous execution. Parallel execution is only allowed when resources are completely unconflicted, such as when the first diagnostic task is engine ECU flashing and the second diagnostic task is body module programming, and the system will provide an explicit prompt.

[0123] In some embodiments, to enhance the flexibility and intelligent self-learning capabilities of the diagnostic system, a new scenario collection and analysis mechanism is implemented. This mechanism continuously records the multi-task operations triggered by the technician during voice AI interactions, especially in scenarios where a second diagnostic task is requested before the first diagnostic task has concluded. The system's response status and execution results are archived and periodically analyzed. For example, if the first diagnostic task (scanning the engine system) is still in progress, and the technician issues a second diagnostic task (scanning the transmission system) via voice AI, and if parallel processing is not initially supported, the system will record the request and its current status. If subsequent scheduling optimization or system updates support such operations, the relevant interaction and execution data will be extracted for scenario modeling and rule verification.

[0124] The system also integrates customer feedback from multiple channels, including diagnostic feedback, user communities, and voice recordings, to analyze high-frequency, emerging, or under-covered task combination scenarios, identifying feasible parallel execution modes or resource conflict rules that need optimization. Based on the analysis results, the system can dynamically modify the functional safety level assessment model and update the scheduling strategies and execution permissions for various task combinations in the aforementioned "Function Operation Settings," enabling the system to more intelligently identify and support parallel diagnostic task combinations.

[0125] Furthermore, the newly collected scenario data and feedback information will be used to retrain the system's embedded intelligent AI model. Through reinforcement learning and pattern recognition, its capabilities in multi-task scheduling, resource conflict prediction, and user intent understanding will be continuously improved. As a result, while ensuring diagnostic security, the system can gradually expand the range of supported concurrent tasks, optimize task switching and interface presentation, and achieve adaptive optimization of the diagnostic process and continuous improvement of the user experience.

[0126] In summary, the vehicle diagnostic method provided in this application effectively solves the technical problems in existing technologies, such as execution failure, low efficiency, system response delay, and poor user experience caused by multiple voice-triggered vehicle diagnostic tasks competing for limited communication channels during the execution of the current diagnostic task. This is achieved by receiving and responding to new voice diagnostic commands while executing the current diagnostic task, intelligently judging communication resource conflicts between old and new tasks, and dynamically determining the execution strategy for the new task. This improves the resource utilization efficiency and task execution success rate of the vehicle diagnostic system, enhances the real-time performance of the system response, and improves the smoothness of the user experience. Through conflict prediction and execution mode control, the access to channel resources is arranged in an orderly manner from the source, preventing excessive impact on the vehicle communication network, ensuring the reliability of the diagnostic communication process, and maintaining the overall stability of the vehicle bus system.

[0127] That is, collecting user voice interaction records and operation behavior data in multi-task scenarios, and performing scenario analysis on the data based on a preset period to identify supportable parallel task combinations; updating the functional safety level and task operation rules according to the analysis results; and using the updated rules and scenario data to train the intelligent scheduling model to optimize the support capability for concurrent execution of multi-tasks and the adaptive scheduling strategy.

[0128] Corresponding to the vehicle diagnostic method in the above embodiments, Figure 4 A structural block diagram of a vehicle diagnostic device provided in an embodiment of this application is shown. For ease of explanation, only the parts related to the embodiment of this application are shown.

[0129] Reference Figure 4 The device 400 includes: a receiving module 410, configured to receive a first voice command when performing a first diagnostic task on a first vehicle, the first voice command being used to request the performance of a second diagnostic task on the first vehicle, the first diagnostic task being different from the second diagnostic task; a processing module 420, configured to determine whether there is a resource occupation conflict between the first diagnostic task and the second diagnostic task, and obtain a determination result, the resource occupation conflict referring to multiple diagnostic tasks requiring the same communication channel resources during execution; the processing module 420 is also configured to determine the execution method of the second diagnostic task based on the determination result, the execution method of the second diagnostic task being used to avoid resource occupation conflict.

[0130] It should be noted that the information interaction and execution process between the above-mentioned devices / modules are based on the same concept as the method embodiments of this application. For details on their specific functions and technical effects, please refer to the method embodiments section, and they will not be repeated here.

[0131] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments 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. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0132] To implement the above embodiments, this application also proposes an electronic device. Figure 5 This is a schematic diagram of the structure of an electronic device according to an embodiment of this application.

[0133] like Figure 5 As shown, the above-mentioned electronic device 500 includes: The system includes a memory 510 and at least one processor 520, and a bus 530 connecting the different components (including the memory 510 and the processor 520). The memory 510 stores a computer program, and when the processor 520 executes the program, it implements the method for controlling the robot according to the embodiments of this application.

[0134] Bus 530 represents one or more of several bus architectures, including a memory bus or memory controller, a peripheral bus, a graphics acceleration port, a processor, or a local bus using any of the various bus architectures. For example, these architectures include, but are not limited to, the Industry Standard Architecture (ISA) bus, the Micro Channel Architecture (MAC) bus, the Enhanced ISA bus, the Video Electronics Standards Association (VESA) local bus, and the Peripheral Component Interconnect (PCI) bus.

[0135] Electronic device 500 typically includes a variety of electronic device readable media. These media can be any available media that can be accessed by electronic device 500, including volatile and non-volatile media, removable and non-removable media.

[0136] Memory 510 may also include computer system readable media in the form of volatile memory, such as random access memory (RAM) 540 and / or cache memory 550. Electronic device 500 may further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, storage system 560 can be used to read and write non-removable, non-volatile magnetic media (… Figure 5 Not shown; usually referred to as a "hard drive"). Although Figure 5 As not shown, a disk drive for reading and writing to a removable non-volatile disk (e.g., a "floppy disk") and an optical disk drive for reading and writing to a removable non-volatile optical disk (e.g., a CD-ROM, DVD-ROM, or other optical media) may be provided. In these cases, each drive may be connected to bus 530 via one or more data media interfaces. Memory 510 may include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of the embodiments of this application.

[0137] A program / utility 580 having a set (at least one) of program modules 570 may be stored, for example, in memory 510. Such program modules 570 include—but are not limited to—an operating system, one or more application programs, other program modules, and program data. Each or some combination of these examples may include an implementation of a network environment. Program modules 570 typically perform the functions and / or methods described in the embodiments of this application.

[0138] Electronic device 500 can also communicate with one or more external devices 590 (e.g., keyboard, pointing device, display 591, etc.), and with one or more devices that enable a user to interact with electronic device 500, and / or with any device that enables electronic device 500 to communicate with one or more other computing devices (e.g., network card, modem, etc.). This communication can be performed via input / output (I / O) interface 595. Furthermore, electronic device 500 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 593. As shown, network adapter 593 communicates with other modules of electronic device 500 via bus 530. It should be understood that, although not shown in the figures, other hardware and / or software modules can be used in conjunction with electronic device 500, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0139] The processor 520 performs various functional applications and data processing by running programs stored in the memory 510.

[0140] It should be noted that the implementation process and technical principles of the electronic device in this embodiment are explained in the foregoing description of the robot control method in the embodiments of this application, and will not be repeated here.

[0141] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps described in the various method embodiments above.

[0142] This application provides a computer program product that, when run on an electronic device, enables the electronic device to perform the steps described in the various method embodiments above.

[0143] 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 computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments of this application can be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. A computer-readable medium can include at least: any entity or device capable of carrying computer program code to a photographic device / electronic device, a recording medium, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media. Examples include USB flash drives, portable hard drives, magnetic disks, or optical disks. In some regions, according to legislation and patent practice, computer-readable media cannot be electrical carrier signals or telecommunication signals.

[0144] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0145] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0146] In the embodiments provided in this application, it should be understood that the disclosed devices / electronic devices and methods can be implemented in other ways. For example, the device / electronic device 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 system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0147] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0148] In the foregoing, specific details such as particular system architectures and techniques have been set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application can also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted to avoid unnecessary detail from obscuring the description of this application.

[0149] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0150] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0151] As used in this application specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if detected [the described condition or event]" may be interpreted, depending on the context, as meaning "once determined," "in response to determination," "once detected [the described condition or event]," or "in response to detection [the described condition or event]."

[0152] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0153] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0154] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A vehicle diagnostic method, characterized in that, The method includes: When performing a first diagnostic task on a first vehicle, a first voice command is received, which is used to request a second diagnostic task to be performed on the first vehicle, and the first diagnostic task is different from the second diagnostic task. Determine whether there is a resource occupation conflict between the first diagnostic task and the second diagnostic task, and obtain the determination result. The resource occupation conflict refers to the fact that multiple diagnostic tasks need to occupy the same type of communication channel resources when they are executed. The execution method of the second diagnostic task is determined based on the judgment result. The execution method of the second diagnostic task is used to avoid the resource occupation conflict.

2. The method according to claim 1, characterized in that, The step of determining whether there is a resource conflict between the first diagnostic task and the second diagnostic task, and obtaining the determination result, includes: If either the first diagnostic task or the second diagnostic task does not require the use of communication channel resources, then the determination result is that there is no resource conflict between the first diagnostic task and the second diagnostic task. The communication channel resources refer to the session channel established when interacting with the electronic control system of the first vehicle; or... If both the first diagnostic task and the second diagnostic task require communication channel resources, then the judgment result is determined based on the first communication channel resources required by the first diagnostic task and the second communication channel resources required by the second diagnostic task.

3. The method according to claim 2, characterized in that, If both the first diagnostic task and the second diagnostic task require communication channel resources, then the determination of the judgment result is based on the first communication channel resources required by the first diagnostic task and the second communication channel resources required by the second diagnostic task, including: If the first communication channel resource and the second communication channel resource are of different types, then the determination result is that there is no resource occupation conflict between the first diagnostic task and the second diagnostic task; or, If the first communication channel resource and the second communication channel resource are of the same type, then the resource reconfiguration identifier of the second diagnostic task is obtained, and the judgment result is determined according to the resource reconfiguration identifier. The resource reconfiguration identifier is used to indicate whether it is allowed to allocate alternative communication channel resources for the second diagnostic task. The type of the alternative communication channel resource is different from the type of the second communication channel resource.

4. The method according to claim 3, characterized in that, If the first communication channel resource and the second communication channel resource are of the same type, then the resource reconfiguration identifier of the second diagnostic task is obtained, and the judgment result is determined based on the resource reconfiguration identifier, including: If the resource reconfiguration indicator allows the allocation of the alternative communication channel resource for the second diagnostic task, then the determination result is that there is no resource conflict between the first diagnostic task and the second diagnostic task; or, If the resource reconfiguration flag indicates that the alternative communication channel resource is not allowed to be allocated to the second diagnostic task, then the determination result is that there is a resource occupation conflict between the first diagnostic task and the second diagnostic task.

5. The method according to any one of claims 1 to 4, characterized in that, The step of determining the execution method of the second diagnostic task based on the judgment result includes: If the determination result indicates that there is a resource conflict between the first diagnostic task and the second diagnostic task, then the execution of the second diagnostic task is refused, and a rejection message is output; or, If the determination result indicates that there is no resource conflict between the first diagnostic task and the second diagnostic task, then the execution of the second diagnostic task is permitted.

6. The method according to claim 5, characterized in that, If the determination result indicates that there is no resource conflict between the first diagnostic task and the second diagnostic task, then after allowing the execution of the second diagnostic task, the method further includes: Control the first diagnostic task and the second diagnostic task to be executed simultaneously; or... If the jump execution conditions are met, the first diagnostic task is interrupted and the second diagnostic task is switched to execution; wherein, the jump execution conditions include at least one of the following: the first diagnostic task does not need to occupy communication channel resources; the task level of the first diagnostic task is lower than the task level of the second diagnostic task; the task type of the first diagnostic task is configured to allow interruption.

7. The method according to claim 6, characterized in that, The control of the simultaneous execution of the first diagnostic task and the second diagnostic task includes: The diagnostic running interface displays the execution progress of the first diagnostic task and the second diagnostic task simultaneously in a split-screen display mode.

8. A vehicle diagnostic device, characterized in that, The device includes: An interface module is used to receive a first voice command when performing a first diagnostic task on a first vehicle. The first voice command is used to request the performance of a second diagnostic task on the first vehicle. The first diagnostic task is different from the second diagnostic task. The processing module is used to determine whether there is a resource occupation conflict between the first diagnostic task and the second diagnostic task, and to obtain a judgment result. The resource occupation conflict refers to the fact that multiple diagnostic tasks need to occupy the same type of communication channel resources when they are executed. The processing module is further configured to determine the execution mode of the second diagnostic task based on the judgment result, wherein the execution mode of the second diagnostic task is used to avoid the resource occupation conflict.

9. An electronic device comprising a memory, one or more processors, and a computer program stored in the memory and executable on the one or more processors, characterized in that, When the one or more processors execute the computer program, the electronic device performs the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1 to 7.

Images