Task execution status visualization system, method, and electronic device

Abstract

Embodiments of the present application provide a task execution state visualization system, method and electronic device. The system comprises a task analysis module, an execution management module and a rendering module; the task analysis module is configured to respond to instruction information and perform analysis processing on the instruction information to obtain an executable list; the executable list is sent to the execution management module and the rendering module; the execution management module is configured to receive and execute the executable list to obtain a corresponding execution state; and the execution state is sent to the rendering module; the rendering module is configured to perform rendering processing on a display interface according to the executable list and the execution state, so as to display the execution process of the instruction information on the display interface. The method is used to achieve the effect of real-time presentation of the task execution state.

Description

Technical Field

[0001] This application relates to the field of vehicle management technology, and in particular to a task execution status visualization system, method, and electronic device. Background Technology

[0002] In intelligent driving vehicles, in-vehicle voice assistants are the preferred way for users to control vehicle functions, manage the cabin environment, and obtain information.

[0003] However, current in-vehicle voice interaction systems silently execute tasks in the background after the user issues a command, only providing success or failure feedback upon completion. This lack of visual guidance during execution presents a problem. Summary of the Invention

[0004] This application provides a task execution status visualization system, method, and electronic device to achieve the effect of presenting the task execution status in real time.

[0005] In a first aspect, embodiments of this application provide a task execution status visualization system, the system including a task parsing module, an execution management module, and a rendering module;

[0006] The task parsing module is used to respond to instruction information, parse and process the instruction information to obtain an executable list, and send the executable list to the execution management module and the rendering module.

[0007] The execution management module is used to receive and execute the executable list to obtain the corresponding execution status; and send the execution status to the rendering module.

[0008] The rendering module is used to render the display interface according to the executable list and the execution status, so as to display the execution process of the instruction information on the display interface.

[0009] In one possible implementation, the execution management module includes an execution submodule and a management submodule;

[0010] The execution submodule is used to execute the task of each item in the executable list, obtain the execution result, and send the execution result to the management submodule;

[0011] The management submodule is used to determine the execution status based on the executable list and the execution result; and send the execution status to the rendering module.

[0012] In one possible implementation, the execution submodule is further configured to:

[0013] If the execution result indicates execution failure, then the execution data of the executable list is obtained; and the execution result and the execution data are sent to the management submodule.

[0014] The management submodule is also used for:

[0015] If the execution result indicates an execution failure, the received execution data is processed to determine the cause of the failure; and the cause of the failure is sent to the rendering module.

[0016] In one possible implementation, the instruction information is parsed to obtain an executable list, including:

[0017] Based on natural language processing algorithms, the instruction information is processed to obtain standardized intent instructions; wherein, the standardized intent instructions are used to characterize the task intent contained in the instruction information and the key parameters required to execute the task intent;

[0018] The standardized intent instructions are processed to obtain the executable list.

[0019] In one possible implementation, the instruction information is processed based on a natural language processing algorithm to obtain a standardized intent instruction, including:

[0020] The instruction information is processed using a natural language processing algorithm to obtain the instruction intent; based on the instruction intent, the key parameters for executing the instruction information are determined.

[0021] Based on the stated instruction intent and the stated key parameters, a filtering process is performed to obtain a standardized intent instruction.

[0022] In one possible implementation, processing the standardized intent instructions to obtain the executable list includes:

[0023] Based on a preset rule base, the standardized intent instruction mapping process is performed to obtain an ordered set of steps.

[0024] The ordered set of steps is processed to obtain a multi-step sequence;

[0025] The multi-step sequence is validated to obtain the executable list.

[0026] In one possible implementation, the rendering module is further configured to:

[0027] If the execution status is determined to be "in execution", then the executable list corresponding to the execution status is rendered with a prompt message indicating that it is in execution.

[0028] If the execution status is determined to be "execution completed", then the executable list corresponding to the execution status is rendered with a message indicating that execution is complete.

[0029] If the execution status is determined to be execution failure, then the executable list corresponding to the execution status is processed to render the execution failure prompt information and output the reason for failure.

[0030] In one possible implementation, the rendering module is further configured to:

[0031] Provide user interaction buttons; the user interaction buttons include one or more of the following: pause button, continue button, stop button, retry button, and view details button.

[0032] Secondly, embodiments of this application provide a method for visualizing task execution status. The method is applied to a task execution status visualization system, which includes a task parsing module, an execution management module, and a rendering module. The method includes:

[0033] The task parsing module responds to the instruction information and parses the instruction information to obtain an executable list; then sends the executable list to the execution management module and the rendering module.

[0034] The execution management module receives and executes the executable list to obtain the corresponding execution status; and sends the execution status to the rendering module.

[0035] The rendering module renders the display interface according to the executable list and the execution status, so as to display the execution process of the instruction information on the display interface.

[0036] Thirdly, embodiments of this application provide an electronic device, including: a memory and a processor;

[0037] The memory stores computer-executed instructions;

[0038] The processor executes computer execution instructions stored in the memory, causing the processor to perform the first aspect and / or various possible implementations of the first aspect as described above.

[0039] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the first aspect and / or various possible implementations of the first aspect.

[0040] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the first aspect and / or various possible implementations of the first aspect.

[0041] This application provides a task execution status visualization system, method, and electronic device. By employing a collaborative approach involving a task parsing module, an execution management module, and a rendering module, the system first processes instruction information, generating a structured executable list. This list is then simultaneously distributed to the execution management module and the rendering module. The execution management module receives the executable list and executes it sequentially, collecting real-time execution status data and feeding it back to the rendering module. Finally, the rendering module dynamically renders the display interface based on the task framework of the executable list and the real-time execution status. This solution utilizes a decoupled architecture of parsing, execution, and rendering to achieve synchronous flow of execution and display data, ensuring consistency between the displayed content and the actual execution progress. It provides an intuitive and visual display of the entire instruction execution process, allowing users to clearly observe the execution progress and node status of instructions, effectively improving the efficiency of task status perception and reducing the monitoring cost of the task execution process. Attached Figure Description

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

[0043] Figure 1 A flowchart illustrating a task execution status visualization system provided in this application embodiment. Figure 1 ;

[0044] Figure 2 A flowchart illustrating a task execution status visualization system provided in this application embodiment. Figure 2 ;

[0045] Figure 3 A flowchart illustrating step S201 in a task execution status visualization system provided in this application embodiment;

[0046] Figure 4 A flowchart illustrating a task execution status visualization method provided in an embodiment of this application;

[0047] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0048] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0049] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of systems and methods consistent with some aspects of this application.

[0050] In-vehicle voice interaction technology is widely used in human-machine interaction scenarios of intelligent driving vehicles. Users can trigger in-vehicle functions such as navigation, air conditioning, and media playback via voice, which is especially suitable for environments where manual operation is inconvenient while driving. Related systems typically rely on the in-vehicle voice entry point, function execution units, and display interfaces to work together to complete command reception, task execution, and result presentation.

[0051] Existing in-vehicle voice interaction systems typically first recognize and semantically analyze the user's voice, then convert the analysis results into corresponding function call flows according to preset rules. When an instruction involves multiple related operations, the system usually converts it into a sequentially executed task process and drives the relevant in-vehicle modules to complete the corresponding processing.

[0052] However, in practical applications, the above solutions tend to focus on outputting the final execution result, lacking continuous feedback on intermediate steps, current progress, and execution status. Users find it difficult to know in a timely manner whether the task has started, what step it has reached, or whether there has been an interruption. Especially in complex driving scenarios, this invisible interaction method can easily lead users to repeatedly confirm or issue commands.

[0053] Meanwhile, when a task fails, existing solutions often only provide a vague failure message, which is difficult to reflect the specific stage where the failure occurred. This makes it difficult for users to quickly determine whether the problem occurred in the parsing stage, the execution stage, or the function call stage, thus affecting interaction efficiency and reliability, and also hindering safe operation during driving.

[0054] To address the aforementioned issues, this application provides a task execution status visualization system. Through the collaborative work of a task parsing module, an execution management module, and a rendering module, the system parses instruction information to obtain an executable list, executes the instruction and generates an execution status, and then renders the display interface based on the executable list and the execution status to show the execution process of the instruction information.

[0055] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0056] Figure 1 A flowchart illustrating a task execution status visualization system provided in this application embodiment. Figure 1 ,like Figure 1 As shown, the task execution status visualization system includes a task parsing module, an execution management module, and a rendering module.

[0057] S101, Task parsing module, is used to respond to instruction information, parse and process the instruction information to obtain an executable list; and send the executable list to the execution management module and the rendering module.

[0058] For example, the task parsing module is a core front-end processing unit deployed in the vehicle terminal task execution status visualization system, responsible for understanding the natural interaction intentions of drivers and passengers.

[0059] In this scenario, the command information specifically refers to vehicle control and service requests issued by the user through in-vehicle voice, touch screen, or physical buttons, such as turning on the air conditioning, navigating to the airport, or playing a favorite playlist.

[0060] Parsing and processing refers to performing semantic understanding, intent classification, and parameter extraction on the instruction in the context of an in-vehicle scenario, and transforming it into a structured task description that can be recognized by the various electronic control units of the vehicle.

[0061] An executable list is a sequential list of one or more atomic vehicle tasks generated after parsing. Each subtask clearly defines the target functional domain (such as air conditioning control, telephone, navigation), execution parameters (such as temperature value, contact person, destination), and expected execution conditions.

[0062] The execution management module is a background component in the in-vehicle infotainment system or body domain controller that is responsible for receiving the list, actually scheduling the corresponding hardware abstraction layer or application service, and monitoring the task execution status.

[0063] The rendering module refers to the visualization engine that drives the central control screen, instrument panel, or head-up display. It pre-builds interface elements such as task cards, progress animations, and status feedback based on the executable list, and presents the task execution process to the driver and passengers in real time.

[0064] For example, the complete execution process of the task parsing module responding to instruction information and obtaining an executable list, and then sending the list to the execution management module and the rendering module is as follows: The task parsing module continuously listens for instruction delivery events from the user interface or interface. When it captures an instruction, it first enters the preprocessing stage to normalize and perform basic verification on the instruction; then it enters the deep parsing stage to extract the core task intent, key entities, and operation parameters by matching rule base or lightweight semantic model; next, it enters the list construction stage to expand the parsed intent and parameters into one or more sequential, independently executable atomic tasks, assign them unique identifiers, set the expected execution order or parallel flags, and finally encapsulate them into an executable list; finally, it enters the distribution stage, where the module synchronously sends the generated executable list to the execution management module through a message channel to start the actual scheduling, and pushes it to the rendering module so that it can parse the list structure in advance and render the corresponding task overview diagram, progress bar placeholder container, and stage nodes to prepare for real-time status updates.

[0065] S102, Execution Management Module, is used to receive and execute the list of executables, obtain the corresponding execution status, and send the execution status to the rendering module.

[0066] For example, the execution management module is the core scheduling and monitoring component in the vehicle terminal task execution status visualization system. It is located between the task parsing module and the underlying vehicle subsystems, playing a central role in connecting the upper and lower levels.

[0067] For example, in the task execution status visualization system of the vehicle terminal, the complete process of the execution management module from receiving the executable list to generating and sending the execution status is as follows: When the execution management module receives the executable list from the task parsing module through the in-vehicle communication bus, it first enters the list parsing and verification stage, performs a legality check on each sub-task in the list, confirms that the subsystem corresponding to the target functional domain is currently available and the required parameters are complete and valid, and constructs an internal directed acyclic task scheduling graph based on the dependencies; then it enters the scheduling and execution stage, where the module initiates calls to various underlying services of the vehicle in sequence or in parallel according to the task graph, such as sending a temperature setting frame to the air conditioning controller through the CAN bus, or calling the contact query interface of the Bluetooth phone service; during the lifecycle of each sub-task, the module continuously listens for callbacks and status reports from each subsystem, capturing every status change of the task from "waiting for scheduling", "in execution" to "complete" or "abnormal"; finally, it enters the status encapsulation and push stage, where the module encapsulates the latest execution status of each task according to a unified data structure and sends it to the rendering module in real time through a publish-subscribe mode or a direct callback interface, ensuring that the front end always receives the latest task running snapshot.

[0068] S103, Rendering module, is used to render the display interface according to the executable list and execution status, so as to display the execution process of the instruction information on the display interface.

[0069] For example, the rendering module is the front-end visualization engine in the vehicle terminal task execution status visualization system, which is responsible for converting the task flow and real-time status into an intuitive graphical interface.

[0070] The execution status is a snapshot of the running process that is sent back in real time by the execution management module during the life cycle of each task, including but not limited to waiting, executing, completed, abnormal, and related intermediate data (such as current temperature and call duration).

[0071] The display interface specifically refers to the information output interface for drivers and passengers, such as the vehicle's central infotainment screen, full LCD instrument panel, or head-up display.

[0072] Rendering processing refers to the rendering module pre-generating a framework of visual elements such as task cards, progress bars, status icons, and transition animations based on the executable list, and continuously mapping the received execution status to the dynamic updates of these elements, so as to present the entire execution process from instruction initiation to final completion in a smooth visual manner on the display interface.

[0073] For example, the complete process of the rendering module rendering the display interface according to the executable list and execution status is as follows: First, after receiving the executable list pushed by the task parsing module, the rendering module enters the interface pre-construction stage, parses the list, identifies the functional domain to which each task belongs (such as telephone, air conditioning, navigation), and creates a corresponding visual container for each task on the display interface, such as a task card or status bar item, and pre-sets the progress bar track, icon placeholders and target parameter display area. At the same time, it pre-sets the linkage layout between task cards according to the dependency relationship between tasks (such as graying out and shrinking the navigation card that is waiting).

[0074] Subsequently, the rendering module enters the state subscription and mapping phase, subscribing to the execution state update stream from the execution management module. When an execution state data packet arrives, the module routes the state data to the corresponding visualization container based on the task identifier, and the execution state drives the rules: for example, when waiting, the corresponding card is semi-transparent or displays an hourglass icon; when executing, it drives the progress bar to fill or breathe animation; when completed, it triggers a success check animation and highlights the result parameters; and when there is an error, it triggers the card to turn red and an error message to pop up.

[0075] Finally, the rendering module performs smooth rendering and transition processing. Through frame animation and interpolation algorithms, it ensures that the state transitions are smooth and natural, and automatically triggers layout adjustments based on the task completion event, such as putting away completed cards, activating the waiting next task card and centering and enlarging it, so as to fully display the continuous process of the instruction information from initiation to completion on the interface.

[0076] This application provides a task execution status visualization system. Through a collaborative approach involving a task parsing module, an execution management module, and a rendering module, the system first processes instruction information, generating a structured executable list. This list is then simultaneously distributed to the execution management module and the rendering module. The execution management module receives the executable list and executes it sequentially, collecting real-time execution status data and feeding it back to the rendering module. Finally, the rendering module dynamically renders the display interface based on the task framework of the executable list and the real-time execution status. This solution utilizes a decoupled architecture of parsing, execution, and rendering to achieve synchronous flow of execution and display data, ensuring consistency between the displayed content and the actual execution progress. It provides an intuitive visualization of the entire instruction execution process, allowing users to clearly observe the execution progress and node status, effectively improving the efficiency of task status perception and reducing the monitoring cost of the task execution process.

[0077] Figure 2 A flowchart illustrating a task execution status visualization system provided in this application embodiment. Figure 2 ,like Figure 2 As shown, the task execution status visualization system includes a task parsing module, an execution management module, and a rendering module; the execution management module includes an execution submodule and a management submodule.

[0078] S201, Task parsing module, is used to respond to instruction information, parse and process the instruction information to obtain an executable list; and send the executable list to the execution management module and the rendering module.

[0079] For example, this step can be referred to step S101, and will not be repeated here.

[0080] The instruction information is parsed and processed to obtain an executable list, including:

[0081] In one example, the instruction information is processed based on a natural language processing algorithm to obtain standardized intent instructions; the standardized intent instructions are then processed to obtain an executable list.

[0082] Among them, standardized intent instructions are used to characterize the task intent contained in the instruction information and the key parameters required to execute the task intent.

[0083] For example, the natural language processing algorithm is a core intelligent algorithm unit deployed in the task parsing module, responsible for converting instructions in human natural language form into structured machine semantics. In this in-vehicle scenario, it specifically refers to a lightweight, low-latency edge semantic understanding model capable of performing intent recognition and key information extraction from the voice or text instructions of drivers and passengers.

[0084] Standardized intent instructions are the output of natural language processing algorithms. They are structured semantic representation objects. Unlike original natural language instructions, they have normalized the fuzzy and diverse expressions into a fixed format that can be processed by machines. They contain at least two core fields: one is the task intent, which represents the core operation category that the user wants to perform; the other is the key parameters, which represent the entities and attribute values ​​necessary to perform the intent.

[0085] An executable list is a list of atomic tasks that are broken down and arranged into an ordered set of tasks that can be directly executed by each vehicle subsystem, according to the division of vehicle functional domains and the dependency and mutual exclusion rules between tasks.

[0086] For example, after receiving the instruction information text, the task parsing module first enters the natural language processing algorithm pipeline. This pipeline performs basic language analysis such as text normalization, word segmentation, and named entity recognition during the preprocessing stage. Subsequently, the algorithm performs intent classification and slot filling based on a joint model. Through a shared coding network, it simultaneously captures the global intent signal of the sentence and the entity annotation signal of the local sequence, outputting an intent category label and a set of slot-value mapping pairs. These results are then packaged and encapsulated to generate a standardized intent instruction object. This process achieves a one-time mapping from unstructured natural language to structured semantics.

[0087] After obtaining standardized intent commands, the module enters the executable list generation stage. First, the command undergoes context-aware functional domain parsing, routing it to the corresponding vehicle functional domain controller knowledge graph based on the intent category. Next, the task orchestration engine is activated. This engine, using a pre-defined atomic task template library, expands a single intent-parameter combination into an ordered queue of atomic tasks, strictly adhering to the safety mutual exclusion rules and logical execution order between the vehicle's internal subsystems. For example, an intent involving multiple steps will be decomposed into a sequence of sequential atomic tasks: first checking the system's readiness state, then issuing an enable command, and finally setting the target parameters. If the command contains multiple parallelizable intents, the orchestration engine will set parallel flags or specify their startup order based on system resource usage, describing them in a dependency graph within the list.

[0088] Finally, the engine attaches a globally unique tracking identifier and execution lifecycle strategy to the generated list of atomic tasks, serializes it into an executable list data structure, and immediately pushes it concurrently to the execution management module and the rendering module, completing the end-to-end processing from semantic understanding to task orchestration.

[0089] Figure 3 This is a flowchart illustrating step S201 in a task execution status visualization system provided in an embodiment of this application; as shown below. Figure 3 As shown, S201 includes:

[0090] S2011. Based on natural language processing algorithms, process the instruction information to obtain the instruction intent; based on the instruction intent, determine the key parameters of the execution instruction information; based on the instruction intent and key parameters, perform filtering processing to obtain standardized intent instructions.

[0091] For example, after receiving the instruction information, the task parsing module first sends it to the intent recognition sub-model of the natural language processing algorithm. This model performs global semantic encoding on the input text and outputs an intent category label based on the pre-trained classification head, thus completing the mapping from natural language to instruction intent.

[0092] After determining the instruction intent, the task parsing module immediately starts the parameter extraction subprocess. This subprocess dynamically activates the slot set definition bound to the identified intent category and uses sequence labeling or machine reading comprehension technology to perform fine-grained parsing of the instruction information, accurately extracting the slot-value pairs required for each intent from the text and assembling them into a key parameter structure.

[0093] The process involves several steps: First, validating the validity of key parameters by checking their existence, type, and value within acceptable ranges. Second, performing intent-parameter consistency checks to determine if the parameter combination matches the intent semantics. Third, applying safety policy filtering based on real-time vehicle status, considering factors such as current speed, driver load, and system usage to determine if the intent is allowed in the current scenario. If parameters are missing but can be inferred, the filtering process will complete them based on user history or default settings. If parameters exceed limits, they are automatically corrected to safety boundary values. Only intent-parameter combinations that pass all the above filtering checks are encapsulated into standardized intent command objects and passed to the subsequent executable list generation stage.

[0094] S2012. Based on the preset rule base, the standardized intent instruction mapping is processed to obtain an ordered set of steps; the ordered set of steps is processed to obtain a multi-step sequence; the multi-step sequence is verified to obtain an executable list.

[0095] For example, after the task parsing module obtains the standardized intent instruction, it first enters the rule base mapping stage. It uses the intent category in the instruction as the primary key to search in the preset rule base. The rule base stores a one-to-many mapping relationship between intents and step templates. Each template defines the sequence of operation steps to be executed in a standard scenario for this type of intent and the parameter binding rules for each step. After the module matches the corresponding template, it injects the key parameters in the standardized intent instruction into the parameter fields of each step according to the slot binding relationship defined in the template, generating an ordered set of steps that has not yet been time-sequenced. The steps in this set are arranged in the default logical order of the template.

[0096] Subsequently, the system traverses the set of steps, identifies the preconditions and postconditions of each operation, and establishes sequential dependency edges or parallel markers between steps based on the identification results. For operations with conditional branches, branch decisions are made based on the current vehicle status and user historical preferences, and the selected branch path is solidified into a definite sequence of steps, ultimately generating a multi-step sequence with a strictly defined execution order.

[0097] Finally, the module performs verification processing on the multi-step sequence. The verification pipeline includes integrity verification, resource conflict verification, security rule verification, and atomicity verification. The multi-step sequence that passes all verification items is given a globally unique execution identifier and execution validity period, and is formally packaged into an executable list and published to the execution management module and rendering module.

[0098] S202, Execution submodule, is used to execute the task of each item in the executable list and obtain the execution result; the execution result is sent to the management submodule.

[0099] For example, the execution submodule is a proxy execution unit in the execution management module that directly faces the various functional domains of the vehicle. Each execution submodule usually corresponds to one or more vehicle functional domains. It is responsible for receiving specific atomic tasks dispatched by the management submodule, executing the task by calling the corresponding vehicle hardware abstraction layer interface or service API, and converting the original response of each call into a standardized execution result and sending it back to the management submodule in real time.

[0100] The execution result is a structured feedback message generated after the execution submodule completes a single task call. It includes at least the task identifier, execution status code, and business data fields, and serves as the basic data unit for the management submodule to perform status aggregation and flow decision-making.

[0101] For example, the execution submodule performs availability detection and interface readiness checks on the target services of the vehicle functional domain under its responsibility, confirms that the communication link is unobstructed and the service is in a responsive state, and performs final type validation and legality checks on the parameters attached to the task to ensure that the parameters fully comply with the calling contract of the target interface.

[0102] Once ready, the execution submodule strictly follows the order or parallel marking specified in the received task list to initiate calls to the underlying vehicle services one by one. Simultaneously with each call, the execution submodule starts an independent execution watchdog timer for that task, monitoring the response time of the call within a set timeout threshold to prevent the execution flow from stalling due to the target service being unresponsive or experiencing prolonged blocking.

[0103] When the underlying service returns a response, the execution submodule immediately captures the returned data and enters the result encapsulation stage. In this stage, the execution submodule converts the original status code and business data returned by the underlying service into a unified standard status code system within the system according to predefined mapping rules, and extracts fields that are meaningful to the upper-level management logic, and assembles them together with the task identifier into a standard execution result data structure.

[0104] After encapsulation, the execution submodule immediately pushes the execution result to the management submodule in real time using an event-driven approach, ensuring that the management submodule can perceive the termination status of each task at the first moment. Regardless of whether the result of the task execution is success, failure, or forced termination due to timeout, the execution submodule ensures that a definite execution result is generated and sent, enabling the management submodule to obtain complete task execution closed-loop information.

[0105] In one example, if the execution result indicates that the execution failed, the execution data of the list of executables is obtained, and the execution result and execution data are sent to the management submodule.

[0106] For example, the execution submodule continuously monitors the response or timeout event of the underlying service during each task call. When a response is received from the underlying service or a watchdog timeout interrupt is triggered, the execution submodule first enters the result determination stage, analyzes the returned status code, error code, or timeout signal, and compares it with the predefined set of success status codes in the system; if the match fails, the task execution result is determined to be a failure.

[0107] Upon failure, the execution submodule immediately suspends the initiation of subsequent dependent tasks in the current task flow and transitions to the execution data collection phase. In this phase, the execution submodule extracts a complete process record related to the failed call from the local task execution context. This includes the complete timestamp chain from task receipt of the failure determination, the complete request payload sent to the underlying service, the original error code returned by the underlying service and its technical description text, a comparison of the actual waiting time with the preset timeout threshold if a timeout occurred, and the health status diagnostic information of the vehicle functional domain service bound to the task at the time of failure.

[0108] Simultaneously, the execution submodule structures and annotates the collected execution data, encapsulating it according to a unified diagnostic information format. Finally, the execution submodule enters the joint reporting phase, treating the generated execution result object and the encapsulated execution data object as a pair of related information bodies, and synchronously sending them to the management submodule via an internal event channel in the form of atomic messages. This ensures that the management submodule receives both the failure notification and the complete diagnostic context in a single message push, avoiding inconsistencies in abnormal decisions due to the separation of information arrival times.

[0109] Understandably, the execution submodule incorporates a structured failure cause classification and detection mechanism during the execution of each task in the executable list. This mechanism pre-builds a failure cause classification library containing four main categories and sixteen subcategories, with each category of failure cause associated with a fixed set of abnormal data characteristics. When the execution submodule completes a task call and captures the response or timeout signal returned from the underlying layer, it enters the anomaly detection process:

[0110] First, extract multi-dimensional feature information such as the return code, parsing log, permission verification record, hardware status log, and network status data of this execution. Then, compare and match these features one by one with the abnormal feature templates in the classification library.

[0111] Specifically, if the return code falls between 100 and 199 and the parsing log shows semantic ambiguity or missing parameters, it is matched as a command parsing failure, and further determined to be a specific subcategory of unclear command semantics, missing key parameters, or unrecognizable command based on feature details; if the return code falls between 200 and 299 and the permission verification record shows unauthorized, it is matched as a permission failure, and further subdivided into application not obtaining permission, user refusing authorization, or expired permission; if the return code falls between 300 and 399 and the hardware status log is abnormal or the execution module is unresponsive, it is matched as a hardware or module failure, covering six sub-situations such as application unresponsiveness, hardware failure, and abnormal module communication; if the return code falls between 400 and 499 and the network status data shows disconnection or abnormal environmental parameters, it is matched as an environment or network failure, including four sub-categories such as network disconnection, excessive network latency, and driving environment restrictions.

[0112] After completing the cause matching, the system automatically extracts the key information of the failure cause, binds it to the corresponding failure step in the executable list, and forms a failure cause annotation that can be directly used by the rendering module.

[0113] Understandably, if multiple abnormal characteristics overlap, the system will prioritize matching the core cause affecting the execution of the steps, and use derivative issues as auxiliary references, only marking the core failure cause to avoid user confusion; if a clear failure cause cannot be located after a full database match, it will be marked as an unknown error, and the system will automatically trigger a self-check program and upload the complete abnormal data packet to the backend, providing data support for the iterative optimization of the subsequent failure cause classification database.

[0114] S203, the management submodule, is used to determine the execution status based on the executable list and execution results; and to send the execution status to the rendering module.

[0115] For example, after receiving the executable list, the management submodule first performs a deep analysis to extract the identifiers, functional domain affiliations, and dependencies between all atomic tasks. Based on these dependencies, it constructs a directed acyclic task graph, where each node represents an atomic task, and each directed edge represents a constraint that the execution of a subsequent task can only be activated after the completion of a preceding task. Simultaneously, it identifies groups of tasks that can be executed concurrently based on parallel tags. After construction, the management submodule assigns all ready task nodes in the graph to their corresponding execution submodules and initiates a global lifecycle tracking session for the entire executable list.

[0116] As each execution submodule reports its execution results, the management submodule enters a continuous state aggregation loop: Upon receiving each execution result, it immediately locates the corresponding node in the task graph based on the task identifier, updates the node's status to success, failure, or timeout, and attaches the business data from the result to that node. Then, it checks all successor nodes of that node to determine if all their preconditions are met. If so, the successor node is marked as ready and execution is initiated. Simultaneously, the management submodule performs a global execution status determination based on the completion status and dependencies of all nodes in the entire task graph. If there are still ready or executing nodes in the graph, the execution status is "in execution"; if all nodes have successfully completed, the execution status is "complete"; if any critical path node fails and is unrecoverable, the execution status is updated to "abnormal termination," and the failed node is marked. Each time the execution status changes, the management submodule immediately encapsulates the latest aggregated execution status into a state snapshot and pushes it to the rendering module in real time via publish / subscribe or callback channels.

[0117] In one example, if the execution result indicates that the execution failed, the received execution data is processed to determine the reason for the failure, and the reason for the failure is sent to the rendering module.

[0118] For example, when the management submodule parses the execution result status code reported by an execution submodule as a failure in its continuous status aggregation loop, it immediately suspends the normal progress of the task flow to which the task belongs and enters the failure diagnosis process.

[0119] The management submodule first extracts key diagnostic fields from the execution data reported in association with the failure results, including the original error code returned by the underlying service, the comparison between the task execution time and the timeout threshold, the number of retries, the identity of the target service, and a snapshot of the system status of the functional domain at the time of failure.

[0120] Subsequently, the management submodule inputs these extracted fields into a pre-defined multi-layered fault diagnosis rule engine: The first layer performs direct error code matching, comparing the native error codes returned by the underlying hardware or services with the error code-cause mapping table maintained by the system. If a match is found, the basic cause category is directly determined. The second layer performs contextual reasoning, jointly analyzing cases where the error code is not directly matched or failures requiring further refinement with auxiliary information such as execution time, number of retries, and target service status, and using pre-built decision trees or rule combinations to deduce root causes. The third layer performs functional domain semantic enhancement, associating the derived technical cause labels with the target functional domain knowledge graph to supplement the semantic description that users can perceive, forming the final failure cause statement.

[0121] Finally, the management submodule encapsulates the reason for failure and the corresponding failed task identifier into an exception notification message, and sends it to the rendering module through the status push channel to ensure that the rendering module can obtain accurate exception information to update the interface.

[0122] S204, Rendering module, is used to render the display interface according to the executable list and execution status, so as to display the execution process of the instruction information on the display interface.

[0123] For example, the rendering module first receives the executable list pushed by the task parsing module when instruction parsing is complete, and enters the interface pre-construction stage. In this stage, the rendering module performs in-depth parsing of the executable list, traversing each atomic task in the list, identifying its functional domain affiliation, task type and dependency relationship, and dynamically creating the corresponding visual container in the layout manager of the display interface based on this information. A task card or status node is instantiated for each task, and title text, icon placeholders, progress bar tracks, parameter display areas and status indicators are pre-arranged in the card. At the same time, according to the serial dependency or parallel relationship between tasks, the rendering module presets the linkage layout logic and transition animation parameters between cards to complete the construction of the overall interface skeleton.

[0124] After pre-building, the rendering module enters the state subscription and dynamic update phase, subscribing to the execution state update stream from the management submodule of the execution management module. Whenever a new execution state data packet is received, the rendering module immediately parses the task identifier and state change information within it. Through the task identifier, the state data is precisely routed to the corresponding visualization container, triggering state-driven visual update rules: executing the corresponding visual mapping according to the state category, for example, reducing the card's transparency and displaying a waiting animation when waiting, starting the progress bar filling and breathing light effect when executing, checking the animation effect and highlighting the result parameters when playback is successful, and turning the card's border red and displaying a failure reason prompt when failing.

[0125] After a single state update rendering is completed, the rendering module checks the dependency triggering conditions between tasks. If the completion of a task causes subsequent tasks to be activated, the preset card transition and layout adjustment animations are executed to ensure that the interface always reflects the overall progress of the task flow in a smooth and continuous manner.

[0126] In one example, the rendering module is also used to: if the execution status is determined to be "in execution", then render the "in execution" prompt message for the executable list corresponding to the execution status; if the execution status is determined to be "execution completed", then render the "execution completed" prompt message for the executable list corresponding to the execution status; if the execution status is determined to be "execution failed", then render the "execution failed" prompt message for the executable list corresponding to the execution status and output the reason for the failure.

[0127] For example, the rendering module continuously receives execution status updates pushed by the management submodule in its state subscription loop. Each time a new execution status data packet is received, the rendering module first enters the state determination and branch routing stage, parses the execution status field carried in the data packet, and routes it to one of the three predefined rendering pipelines according to the status value.

[0128] If the execution status is determined to be "in progress", the rendering module enters the in progress rendering pipeline, locates the task card group corresponding to the executable list associated with the status update, and applies the in progress visual style to the currently active task card, including starting a progress bar fill animation, displaying a rotating activity indicator in the task title area, updating the status text to "in progress" and adding a breathing light effect or pulse animation to indicate that the system is processing the user request but has not yet completed it.

[0129] If the execution status is determined to be "execution completed", the rendering module enters the execution completion rendering pipeline. First, it plays a success confirmation animation for the last completed task card, instantly filling the progress bar to full and transitioning the fill color from blue (in progress) to green (completed). A checkmark icon is briefly displayed in the center of the card, and a zoom-in animation is played. Then, the status text is updated to "Completed". If the executable list contains multiple tasks, the rendering module plays completion animations for all task cards sequentially or simultaneously. After all animations have finished playing, it performs an overall layout adjustment, such as smoothly collapsing the task card group to the status bar thumbnail icon to free up space in the main display area.

[0130] If the execution status is determined to be execution failure, the rendering module enters the execution failure rendering pipeline. First, it locates the task card corresponding to the failed task, changes its border color to warning red and starts a border flashing animation to attract attention, locks the progress bar status at the current progress and marks the stop position in red, and updates the status text to failure. At the same time, the rendering module extracts the failure reason field from the execution status data packet, expands a prompt area inside or below the failed task card, renders the failure reason text in a high-contrast color, and can optionally add interactive guidance buttons to key operation words.

[0131] In one example, the rendering module is also used to: provide user interaction buttons; user interaction buttons include one or more of the following: pause button, continue button, stop button, retry button, and view details button.

[0132] For example, during the interface pre-construction phase, the rendering module determines the button types and their initial states that need to be dynamically generated for each task card or the overall task flow panel, based on the functional domain attributes of the tasks in the executable list, the interruptibility metadata, and the current interaction mode of the system.

[0133] The generation of buttons follows the visibility and enable rules bound to the task lifecycle. For example, the pause and stop buttons are generated and are clickable when the task is in execution. The continue button is initially hidden or grayed out and only becomes visible and active after the task is paused. The retry button is dynamically added and displayed only when the task card is marked as having failed. The view details button is a persistent auxiliary control that remains visible.

[0134] After the button is rendered, the rendering module registers a touch event listener or physical button mapping callback for it. When the driver touches or presses a button, the rendering module first performs immediate visual state feedback locally, such as the button's pressed state color deepening or a brief scaling animation, to confirm that the user action has been received.

[0135] Subsequently, the rendering module generates corresponding user control instructions based on the button type, which includes the target task identifier, instruction type (pause, continue, stop, retry, view details) and trigger timestamp, and sends the control instruction to the execution management module through the system's internal control command channel.

[0136] After receiving the instruction, the execution management module performs corresponding scheduling operations on the task flow according to the instruction type. For example, when pausing, it suspends all active nodes in the task graph and maintains the context; when stopping, it clears unexecuted nodes and notifies each execution submodule to execute cleanup logic; when retrying, it resets the state of failed tasks and their successor nodes and re-dispatches them. After completing the scheduling, the execution management module pushes the new aggregated execution state back to the rendering module. The rendering module then updates the button combinations and states based on the latest state, forming an interactive closed loop.

[0137] This application provides a task execution status visualization system. By setting up a task parsing module, an execution management module (including execution and management sub-modules), and a rendering module that operate collaboratively, the task parsing module first responds to instruction information and completes parsing processing to obtain an executable list, which is then synchronously distributed to the execution management module and the rendering module. Next, the execution sub-module executes each task in the list and reports the execution results. The management sub-module combines the executable list and real-time execution results to determine the current execution status and pushes it to the rendering module. Finally, the rendering module renders the display interface based on the executable list and the dynamic execution status. Through data synchronization and hierarchical processing between modules, the execution progress of background tasks is transformed into standardized interface display elements, achieving an intuitive visualization of the instruction execution process. This clearly presents the execution progress and overall completion status of each task, allowing users to monitor the task running status in real time. This effectively improves the intuitiveness of task monitoring and the transparency of the execution process. Simultaneously, the modular division of labor architecture ensures the real-time nature of status updates and the stability of system operation.

[0138] Figure 4 This is a flowchart illustrating a task execution status visualization method provided in an embodiment of this application; as shown below. Figure 4 As shown, this method is applied to a task execution status visualization system, which includes a task parsing module, an execution management module, and a rendering module. The method includes:

[0139] S401, the task parsing module, responds to the instruction information and parses and processes the instruction information to obtain the executable list; it then sends the executable list to the execution management module and the rendering module.

[0140] S402. The execution management module receives and executes the executable list to obtain the corresponding execution status; and sends the execution status to the rendering module.

[0141] S403 The rendering module renders the display interface according to the executable list and execution status to display the execution process of the instruction information on the display interface.

[0142] The task execution status visualization method provided in this application embodiment can be applied to the system provided in the above-mentioned task execution status visualization system embodiment. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0143] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 5 As shown, the electronic device 50 provided in this embodiment includes at least one processor 501 and a memory 502. Optionally, the electronic device 50 further includes a communication component 503. The processor 501, memory 502, and communication component 503 are connected via a bus 504.

[0144] In a specific implementation, at least one processor 501 executes computer execution instructions stored in memory 502, causing at least one processor 501 to perform the above-described method.

[0145] The specific implementation process of processor 501 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0146] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0147] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0148] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0149] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0150] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0151] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0152] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0153] The division of units is merely a logical functional division; 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 indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0154] 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.

[0155] In addition, the functional units in the various embodiments of the present invention 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.

[0156] If a function 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, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0157] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0158] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope.

Claims

1. A task execution status visualization system, characterized in that, The system includes a task parsing module, an execution management module, and a rendering module; The task parsing module is used to respond to instruction information, parse and process the instruction information to obtain an executable list, and send the executable list to the execution management module and the rendering module. The execution management module is used to receive and execute the executable list to obtain the corresponding execution status; And send the execution status to the rendering module; The rendering module is used to render the display interface according to the executable list and the execution status, so as to display the execution process of the instruction information on the display interface.

2. The system according to claim 1, characterized in that, The execution management module includes an execution submodule and a management submodule; The execution submodule is used to execute the task of each item in the executable list and obtain the execution result; The execution result is sent to the management submodule; The management submodule is used to determine the execution status based on the executable list and the execution result; The execution status is sent to the rendering module.

3. The system according to claim 2, characterized in that, The execution submodule is also used for: If the execution result indicates execution failure, then the execution data of the executable list is obtained; and the execution result and the execution data are sent to the management submodule. The management submodule is also used for: If the execution result indicates an execution failure, the received execution data is processed to determine the cause of the failure; and the cause of the failure is sent to the rendering module.

4. The system according to claim 1, characterized in that, The instruction information is parsed to obtain an executable list, including: Based on natural language processing algorithms, the instruction information is processed to obtain standardized intent instructions; wherein, the standardized intent instructions are used to characterize the task intent contained in the instruction information and the key parameters required to execute the task intent; The standardized intent instructions are processed to obtain the executable list.

5. The system according to claim 4, characterized in that, Based on natural language processing algorithms, the instruction information is processed to obtain standardized intent instructions, including: The instruction information is processed using a natural language processing algorithm to obtain the instruction intent; based on the instruction intent, the key parameters for executing the instruction information are determined. Based on the stated instruction intent and the stated key parameters, a filtering process is performed to obtain a standardized intent instruction.

6. The system according to claim 4, characterized in that, The standardized intent instructions are processed to obtain the executable list, including: Based on a preset rule base, the standardized intent instruction mapping process is performed to obtain an ordered set of steps. The ordered set of steps is processed to obtain a multi-step sequence; The multi-step sequence is validated to obtain the executable list.

7. The system according to any one of claims 1-6, characterized in that, The rendering module is also used for: If the execution status is determined to be "in execution", then the executable list corresponding to the execution status is rendered with a prompt message indicating that it is in execution. If the execution status is determined to be "execution completed", then the executable list corresponding to the execution status is rendered with a message indicating that execution is complete. If the execution status is determined to be execution failure, then the executable list corresponding to the execution status is processed to render the execution failure prompt information and output the reason for failure.

8. The system according to any one of claims 1-7, characterized in that, The rendering module is also used for: Provide user interaction buttons; the user interaction buttons include one or more of the following: pause button, continue button, stop button, retry button, and view details button.

9. A method for visualizing task execution status, characterized in that, The method is applied to a task execution status visualization system, which includes a task parsing module, an execution management module, and a rendering module. The method includes: The task parsing module responds to the instruction information and parses the instruction information to obtain an executable list; then sends the executable list to the execution management module and the rendering module. The execution management module receives and executes the executable list to obtain the corresponding execution status; and sends the execution status to the rendering module. The rendering module renders the display interface according to the executable list and the execution status, so as to display the execution process of the instruction information on the display interface.

10. An electronic device, characterized in that, include: Memory, processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in claim 9.

Images