Voice instruction monitoring method and device, control device, medium, product and vehicle

Abstract

The present disclosure provides a voice instruction monitoring method and device, a control device, a medium, a product and a vehicle, relates to the technical field of vehicles, and can improve the abnormal monitoring precision of the execution of the vehicle-mounted voice instruction; the method comprises the following steps: in response to the vehicle-mounted voice instruction, executing the vehicle-mounted voice instruction, and obtaining execution reporting information of a target node; the target node is a node in an execution state in an execution node chain of the vehicle-mounted voice instruction; based on the execution reporting information, performing abnormal monitoring on the execution of the vehicle-mounted voice instruction; the execution reporting information is used for indicating execution state information and first vehicle state transmission chain information; the first vehicle state transmission chain information comprises second vehicle state transmission chain information of a previous execution node of the target node and vehicle state information at the target node; when the target node is the first execution node in the execution node chain, the second vehicle state transmission chain information comprises a globally unique tracking identifier of the vehicle-mounted voice instruction and vehicle state information at a response moment of the vehicle-mounted voice instruction.

Description

Technical Field

[0001] This disclosure relates to the field of vehicle technology, and more particularly to the field of vehicle-mounted voice command monitoring technology, specifically to a voice command monitoring method and device, control device, medium, product and vehicle. Background Technology

[0002] With the development of smart cockpit technology, in-vehicle voice interaction has become one of the main ways for users to communicate with their vehicles. Users can complete various operations such as navigation settings, window control, air conditioning adjustment, and multimedia playback through voice commands. The accuracy and reliability of voice command execution have also become important aspects of measuring cockpit interaction performance. From being responded to to being executed, an in-vehicle voice command typically requires chain processing through voice recognition, intent understanding, command distribution, and multiple functional nodes. The processing status of each execution node jointly determines the execution result of the voice command.

[0003] However, the monitoring of the execution process of in-vehicle voice commands in related technologies is usually based on the execution result of a single execution node. It is difficult to fully grasp the execution status of voice commands throughout the entire execution chain. When anomalies occur in the execution of voice commands, it is difficult to quickly locate the execution link where the anomaly occurs. Furthermore, the analysis of the cause of the anomaly is usually separated from the actual state of the vehicle at the time of the anomaly, resulting in long troubleshooting time and inaccurate anomaly attribution, which affects the reliability of in-vehicle voice interaction functions and the user experience. Summary of the Invention

[0004] This disclosure provides a voice command monitoring method and apparatus, control device, medium, product, and vehicle to solve the problems in related technologies where it is difficult to locate abnormal links in the execution chain of vehicle voice commands and difficult to analyze the causes of abnormalities in conjunction with vehicle status, thereby realizing full-chain abnormal monitoring and fault attribution of the vehicle voice command execution process.

[0005] Firstly, this application provides a voice command monitoring method, the method comprising: In response to an in-vehicle voice command, the system executes the in-vehicle voice command and obtains the execution reporting information of the target node. The target node is a node in the execution node chain of the in-vehicle voice command that is currently in execution. Based on the execution reporting information, the system monitors for execution anomalies of the in-vehicle voice command. The execution reporting information indicates the execution status information and the first vehicle status transmission chain information. The first vehicle status transmission chain information includes the second vehicle status transmission chain information of the previous execution node of the target node and the vehicle status information at the target node. When the target node is the first execution node in the execution node chain, the second vehicle status transmission chain information includes the globally unique tracking identifier of the in-vehicle voice command and the vehicle status information at the time of the in-vehicle voice command response.

[0006] Based on this implementation, by responding to in-vehicle voice commands, executing the command, and obtaining the execution reporting information of the target node in the execution node chain, the abnormal monitoring of voice commands is based on the execution node chain, covering all aspects of command execution. Since the execution reporting information simultaneously indicates the execution status information and the first vehicle status transmission chain information, and the first vehicle status transmission chain information is composed of the second vehicle status transmission chain information of the previous execution node and the vehicle status information at the target node, the target node carries the complete vehicle status context from the command response during execution. Thus, when an execution anomaly occurs, the execution status of the abnormal node can be associated with the vehicle status at the time of the anomaly, improving the accuracy of execution anomaly monitoring. At the same time, when the target node is the first execution node, the second vehicle status transmission chain information contains a globally unique tracking identifier, which allows the execution links of multiple voice commands on the same vehicle to be distinguished, realizing full-link traceability of the voice command execution process.

[0007] In some possible implementations, the execution status information includes: node identifier, target execution event, execution timestamp of the target execution event, and execution success / failure return code; wherein, the target execution event is one of the execution start event, execution end event, and execution exception reporting event.

[0008] Based on this implementation method, by refining the execution status information into node identifier, target execution event, execution timestamp, and execution success / failure return code, and limiting the target execution event to one of the following: execution start event, execution end event, or execution exception reporting event, the reported content of each execution node has a unified structured format. This allows execution information of different nodes and different types to be parsed and compared in a consistent manner by the monitoring end. Due to the recording of execution timestamp and execution success / failure return code, the execution sequence and execution results of each node can be quantitatively verified, thereby providing a direct data foundation for execution time statistics and anomaly location, and improving the operability of execution anomaly monitoring.

[0009] In some possible implementations, the execution anomaly monitoring of in-vehicle voice commands is performed based on execution status information, including: finding the execution status information of the upstream execution node of the target node based on a globally unique tracking identifier; generating global execution traceability information based on the execution status information and execution reporting information of the upstream execution node; and performing execution anomaly monitoring of in-vehicle voice commands based on the global execution traceability information.

[0010] Based on this implementation method, by finding the execution status information of the upstream execution nodes of the target node based on the globally unique tracking identifier, and generating global execution tracing information based on the execution status information and execution reporting information of the upstream execution nodes, the local execution information scattered on each execution node can be linked into a complete view covering the entire execution link. Thus, execution anomaly monitoring is no longer limited to isolated judgment of a single node. On this basis, execution anomaly monitoring based on global execution tracing information enables anomaly analysis to simultaneously grasp the execution status of the target node itself and all its upstream nodes, thereby improving the comprehensiveness of anomaly judgment and the link-level attribution capability.

[0011] In some possible implementations, the execution reporting information instructs the target node to report anomalies; based on global execution tracing information, the execution anomaly monitoring of the vehicle voice commands is performed, including: tracing the first abnormal node among the upstream execution nodes; if the first abnormal node exists, marking the target node as a derived fault node; if the first abnormal node does not exist, marking the target node as a root cause fault node.

[0012] Based on this implementation method, in scenarios where the execution reporting information instructs the target node to report anomalies, by tracing the first abnormal node among the upstream execution nodes, and marking the target node as a derived fault node if the first abnormal node exists, and marking the target node as the root cause fault node if the first abnormal node does not exist, the anomaly of the target node can be distinguished as either caused by its own fault or by the propagation of the upstream fault based on the execution status of the upstream node, thereby realizing the automatic determination of the causal relationship of the fault. In this way, during troubleshooting, the source of the fault can be located directly based on the root cause fault node, and interference items can be eliminated based on the derived fault nodes, avoiding misjudging the propagation anomaly as an independent fault, and improving the fault location efficiency of execution anomaly monitoring.

[0013] In some possible implementations, the execution reporting information indicates that the target node has not reported any abnormalities, and the execution time of the target node exceeds the upper limit threshold of the execution time of the target node; based on global execution traceability information, the execution anomaly monitoring of the vehicle voice command is performed, including: based on the first vehicle status transmission chain information, determining the index value of each of at least one vehicle status index; if the index value of any vehicle status index deviates from the normal index value range of any vehicle status index, the target node is marked as a fault node caused by environmental factors.

[0014] Based on this implementation method, in scenarios where the target node fails to report an anomaly and the execution time exceeds the upper limit threshold of the execution time, the index values ​​of at least one vehicle status index are determined based on the first vehicle status transmission chain information. If the index value of any vehicle status index deviates from the normal index value range, the target node is marked as a fault node caused by environmental factors. This allows the abnormal situation where the node neither reports an anomaly nor exceeds the expected execution time, which is difficult to detect through the execution status information, to be attributed using the vehicle status recorded in the vehicle status transmission chain information, thereby distinguishing such silent anomalies from the node's own faults. Since the vehicle status index is taken from the vehicle status context at the time of the anomaly, the fault determination caused by environmental factors is closer to the actual vehicle condition, improving the ability of execution anomaly monitoring to identify and attribute hidden anomalies.

[0015] In some possible implementations, the upper limit threshold for the execution time of the target node is determined based on the scenario type of the first vehicle state transfer chain information matching.

[0016] Based on this implementation method, the upper limit threshold of the execution time of the target node is determined by matching the scenario type based on the information of the first vehicle state transmission chain. This makes the benchmark for judging the execution time no longer a fixed and uniform value, but dynamically adjusted according to the scenario in which the vehicle is located. Since the information of the first vehicle state transmission chain reflects the actual vehicle state during the instruction execution process, the scenario type matched in this way matches the real environment in which the target node is executed. Therefore, the upper limit threshold of the execution time can adapt to the objective differences in the execution time of nodes in different scenarios, reducing the situation of misjudging normal execution as time-consuming anomalies in scenarios where the execution time is naturally long, thereby improving the rationality of the judgment of execution anomaly monitoring.

[0017] In some possible implementations, the method further includes: generating and updating the floating window display content based on the target display content; wherein the target display content includes: a globally unique tracking identifier and completion status identifier information from the first execution node to the target node; the completion status identifier information includes: a completed without anomaly identifier, a completed with anomaly identifier, and a processing identifier; the completed with anomaly identifier includes subdivided identifiers corresponding to derivative faults, root cause faults, and faults caused by environmental factors, as well as a fault details description.

[0018] Based on this implementation method, by generating and updating the content displayed in the floating window, and the target display content includes a globally unique tracking identifier and completion status information from the first execution node to the target node, the completion status information includes a completed without anomalies identifier, a completed with anomalies identifier, and a processing identifier. The completed with anomalies identifier further includes subdivided identifiers and detailed descriptions of faults caused by derivative faults, root cause faults, and environmental factors. This allows the execution progress and anomaly judgment results of voice commands to be presented intuitively in the form of a floating window, so that users and maintenance personnel can grasp the real-time status of the entire execution chain without having to query logs node by node. Due to the presentation of the anomaly subdivision identifiers and detailed descriptions of faults, the fault type and cause are clear at a glance, thereby improving the readability of execution anomaly monitoring results and the human-computer interaction experience.

[0019] Secondly, this application provides a monitoring device for abnormal execution of vehicle voice commands, including: an execution module and a monitoring module.

[0020] The aforementioned execution module is used to respond to in-vehicle voice commands, execute in-vehicle voice commands, and obtain execution reporting information from target nodes; wherein, the target node is a node in the execution node chain of the in-vehicle voice command that is in the execution state; The aforementioned monitoring module is used to monitor execution anomalies of in-vehicle voice commands based on execution reporting information. The execution reporting information indicates execution status information and the first vehicle status transmission chain information. The first vehicle status transmission chain information includes the second vehicle status transmission chain information of the previous execution node of the target node and the vehicle status information at the target node. When the target node is the first execution node in the execution node chain, the second vehicle status transmission chain information... The above execution status information includes: node identifier, target execution event, execution timestamp of the target execution event, and execution success / failure return code; wherein, the target execution event is one of the execution start event, execution end event, and execution exception reporting event.

[0021] The aforementioned monitoring module is also used to find the execution status information of the upstream execution node of the target node based on the globally unique tracking identifier; to generate global execution traceability information based on the execution status information and execution reporting information of the upstream execution node; and to monitor the execution anomalies of the vehicle voice commands based on the global execution traceability information.

[0022] The aforementioned execution reporting information instructs the target node to report an anomaly; the aforementioned monitoring module is also used to trace the first abnormal node among the upstream execution nodes; if the first abnormal node exists, the target node is marked as a derived fault node; if the first abnormal node does not exist, the target node is marked as a root cause fault node.

[0023] The aforementioned execution reporting information indicates that the target node has not reported any abnormalities, and the execution time of the target node exceeds the upper limit threshold of the execution time of the target node; the aforementioned monitoring module is also used to determine the index value of at least one vehicle status index based on the first vehicle status transmission chain information; if the index value of any vehicle status index deviates from the normal index value range of any vehicle status index, the target node is marked as a fault node caused by environmental factors.

[0024] The upper limit threshold for the execution time of the aforementioned target node is determined based on the scenario type of the first vehicle state transmission chain information matching.

[0025] The aforementioned monitoring module is also used to generate and update the floating window display content based on the target display content; wherein, the target display content includes: a globally unique tracking identifier, and completion status identifier information from the first execution node to the target node; the completion status identifier information includes: completed without anomalies, completed with anomalies, and in progress; the completed with anomalies identifier has subdivided identifiers corresponding to derivative faults, root cause faults, and faults caused by environmental factors, as well as fault details descriptions.

[0026] Thirdly, this application provides a control device, including: a memory and a processor; the memory and the processor are coupled; the memory is used to store a computer program; when the processor executes the computer program, it implements the voice command monitoring method of any of the above embodiments.

[0027] Fourthly, this application provides a computer-readable storage medium storing computer program instructions that, when executed by a processor, implement the voice command monitoring method of any of the above embodiments.

[0028] Fifthly, this application provides a computer program product including computer program instructions that, when executed by a processor, implement the voice command monitoring method of any of the above embodiments.

[0029] Sixthly, this application provides a vehicle including the control device of any of the preceding embodiments; or the computer-readable storage medium of any of the preceding embodiments; or the computer program product of any of the preceding embodiments. Attached Figure Description

[0030] To more clearly illustrate the technical solutions in this disclosure, the accompanying drawings used in some embodiments of this disclosure will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this disclosure. For those skilled in the art, other drawings can be obtained based on these drawings.

[0031] Figure 1This is a schematic diagram of the architecture of a voice command monitoring system provided in an embodiment of the present disclosure; Figure 2 A flowchart illustrating a voice command monitoring method provided in an embodiment of this disclosure; Figure 3 A flowchart illustrating yet another voice command monitoring method provided in this disclosure embodiment; Figure 4 A flowchart illustrating yet another voice command monitoring method provided in this disclosure embodiment; Figure 5 This is a schematic diagram of the structure of a voice command monitoring device provided in an embodiment of the present disclosure; Figure 6 This is a schematic diagram of the structure of a control device provided in an embodiment of the present disclosure. Detailed Implementation

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

[0033] It should be noted that in this disclosure, the terms "exemplary" or "for example" are used to indicate examples, illustrations, or descriptions. Any embodiment or design described in this disclosure as exemplary or for example should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of terms such as "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner.

[0034] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature.

[0035] In the description of this disclosure, unless otherwise stated, / denotes "or," for example, A / B can mean A or B. The "and / or" in this document is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, and B alone. Furthermore, at least one means one or more, and multiple means two or more.

[0036] With the rapid development of smart cockpit technology and the increasing richness of in-vehicle functions, voice interaction has become one of the most core interaction methods between drivers and vehicles. Users can control dozens of in-vehicle functions such as air conditioning, navigation, media playback, and seat adjustment through voice commands, eliminating the need for manual operation and effectively improving driving safety and ease of use.

[0037] However, in real-world driving scenarios, user-issued voice commands often possess inherent ambiguity. For example, a user saying "It's too hot" might simultaneously correspond to multiple intentions such as turning on the air conditioning, turning off the seat heating, and lowering the steering wheel heating temperature; a user saying "It's a bit stuffy" might correspond to different actions such as opening the sunroof, turning on the external air circulation, and lowering the air conditioning temperature. When an in-vehicle voice system recognizes multiple candidate intentions from a single ambiguous voice command, accurately determining the user's true intended action is a key technical challenge for in-vehicle voice interaction.

[0038] The control system provided in the embodiments of this disclosure will now be described in detail with reference to the accompanying drawings.

[0039] Figure 1 This is a schematic diagram of the architecture of a voice command monitoring system provided in an embodiment of this disclosure. Figure 1 As shown, the voice command monitoring system 100 includes: a data acquisition device 101, a voice command monitoring device 102, and a controller 103. The voice command monitoring system 100 is used to execute the vehicle-mounted voice command execution anomaly monitoring method provided in this application embodiment.

[0040] In some embodiments, the data acquisition device 101 is communicatively connected to the voice command monitoring device 102, and the voice command monitoring device 102 is communicatively connected to the controller 103.

[0041] For example, the above communication connection can be implemented through the vehicle bus or through the vehicle Ethernet. This application embodiment does not limit the specific connection method.

[0042] The data acquisition device 101 is used to collect voice data and vehicle status information inside the vehicle cabin.

[0043] For example, the data acquisition device 101 may include a microphone array disposed in the cockpit for collecting voice data emitted by the user; the data acquisition device 101 may also include multiple status sensors disposed at different locations in the vehicle for collecting vehicle status information.

[0044] For example, the status sensor may include at least one of the following: vehicle speed sensor, power battery charge sensor, gear position sensor, or ambient temperature sensor. The vehicle status information includes the value of at least one vehicle status indicator such as vehicle speed, power charge, gear position, or ambient temperature.

[0045] The voice command monitoring device 102 is used to respond to vehicle-mounted voice commands, execute vehicle-mounted voice commands, acquire execution reporting information from target nodes, and monitor execution anomalies of vehicle-mounted voice commands based on the execution reporting information. The target node is a node in the execution node chain of the vehicle-mounted voice command that is in an execution state, and the execution reporting information is used to indicate the execution status information and the first vehicle status transmission chain information.

[0046] For example, the voice command monitoring device 102 can be the vehicle's cockpit domain controller or the main control chip of the vehicle system.

[0047] In some embodiments, the voice command monitoring device 102 is configured to: execute the vehicle voice command in response to the vehicle voice command and obtain the execution reporting information of the target node; monitor the execution anomaly of the vehicle voice command based on the execution reporting information; and generate and update the floating window display content based on the target display content after the execution anomaly monitoring is completed.

[0048] Controller 103 is an execution node in the execution node chain.

[0049] The controller 103 is used to receive execution instructions from the voice command monitoring device 102, execute the execution instructions, and send execution reporting information to the voice command monitoring device 102.

[0050] For example, the controller 103 can be a functional controller such as a body controller, air conditioning controller or window controller; the execution nodes in the execution node chain can include the processing node in the voice command monitoring device 102 and at least one controller 103.

[0051] During the operation of the voice command monitoring system 100, the data acquisition device 101 sends the acquired voice data to the voice command monitoring device 102; the voice command monitoring device 102 processes the voice data to obtain the vehicle voice command and executes the vehicle voice command along the execution node chain; after executing the execution command, the controller 103 sends execution reporting information to the voice command monitoring device 102; the voice command monitoring device 102 monitors the execution anomaly of the vehicle voice command based on the execution reporting information and displays the content of the floating window on the vehicle's in-vehicle display screen to show the status of the execution link.

[0052] The voice command monitoring method provided in the embodiments of this disclosure will be described in detail below.

[0053] Figure 2 This is a flowchart illustrating a voice command monitoring method provided in an embodiment of the present disclosure, as shown below. Figure 2 As shown, the method includes the following steps: S201. Responding to the in-vehicle voice command, execute the in-vehicle voice command and obtain the execution reporting information of the target node.

[0054] The target node is a node in the execution node chain of the vehicle voice command that is in the execution state.

[0055] The aforementioned in-vehicle voice commands refer to control commands issued by the user to the vehicle via voice, such as commands to control windows, air conditioning, navigation, or multimedia playback.

[0056] An execution node chain refers to the link formed by multiple execution nodes that an in-vehicle voice command passes through sequentially from being responded to to completion of execution.

[0057] For example, the execution node chain may include a speech recognition node, an intent understanding node, an instruction distribution node, and a function execution node.

[0058] The target node is the node in the execution node chain that is currently processing the task corresponding to the in-vehicle voice command.

[0059] In one possible implementation, user voice data is collected, and the voice data is recognized and parsed to obtain in-vehicle voice commands. At the response time, a globally unique tracking identifier for the in-vehicle voice command is generated, and vehicle status information at the response time is collected. Subsequently, the in-vehicle voice command is transmitted and executed node by node along the execution node chain, and the node in the execution state is the target node. During the execution process, the target node obtains the second vehicle status transmission chain information transmitted by the previous execution node, and collects the vehicle status information at the target node, and splices the two to form the first vehicle status transmission chain information. The target node reports the execution status information and the first vehicle status transmission chain information as execution reporting information, thereby obtaining the execution reporting information of the target node.

[0060] S202. Based on the execution report information, monitor the execution anomalies of the vehicle voice commands.

[0061] Among them, the execution reporting information is used to indicate the execution status information and the first vehicle status transmission chain information.

[0062] The aforementioned first vehicle state transmission chain information includes the second vehicle state transmission chain information of the previous execution node of the target node and the vehicle state information at the target node.

[0063] When the aforementioned target node is the first execution node in the execution node chain, the second vehicle status transmission chain information includes the globally unique tracking identifier of the in-vehicle voice command and the vehicle status information at the moment of the in-vehicle voice command response.

[0064] Execution status information is used to characterize the execution status of the target node.

[0065] The vehicle status information mentioned above is used to characterize the vehicle's status at the corresponding moment.

[0066] The aforementioned globally unique tracking identifier is a unique identifier generated at the moment the in-vehicle voice command is responded to, used to distinguish the execution links of different in-vehicle voice commands.

[0067] The globally unique tracking identifier is unique within the vehicle, meaning that the globally unique tracking identifiers corresponding to any two different in-vehicle voice commands are different.

[0068] For example, a globally unique tracking identifier can be a number consisting of numbers, letters, or a combination of both. The number can be generated by concatenating a timestamp of the response time with an auto-incrementing sequence number, or it can be generated based on a random number algorithm.

[0069] The globally unique tracking identifier is passed down level by level along the execution node chain after it is generated, so that the information at each execution node in the execution chain can be associated with the corresponding vehicle voice command, thereby distinguishing the execution chains of different vehicle voice commands.

[0070] The first vehicle status transmission chain information carries the vehicle status context from the moment the vehicle voice command is responded to, in a hierarchical splicing manner.

[0071] For example, when the execution node chain includes a first node, a second node, and a third node connected in sequence, if the third node is the target node, the first vehicle state transmission chain information of the third node includes the second vehicle state transmission chain information of the second node and the vehicle state information at the third node. The second vehicle state transmission chain information of the second node includes the second vehicle state transmission chain information of the first node and the vehicle state information at the second node, thereby realizing the step-by-step transmission of vehicle state information along the execution node chain.

[0072] When the target node is the first execution node in the execution node chain, the globally unique tracking identifier and the vehicle status information at the response time are used as the second vehicle status transmission chain information to be passed to the first execution node.

[0073] In one possible implementation, the execution status of the target node is determined based on the execution status information reported by the target node, and the vehicle status context carried by the first vehicle status transmission chain information is combined to determine whether there is an anomaly in the execution of the vehicle voice command; if the execution status information indicates that the target node has failed to execute, it is determined that there is an anomaly in the execution of the vehicle voice command, thereby realizing the monitoring of the execution anomaly of the vehicle voice command.

[0074] In one embodiment, the execution status information includes: node identifier, target execution event, execution timestamp of the target execution event, and execution success / failure return code.

[0075] The node identifier mentioned above is used to uniquely identify each execution node in the execution node chain.

[0076] For example, the node identifier can be a node number, node name, or node address, etc. The node identifier can determine which execution node the reported information comes from.

[0077] Target execution events are events that occur during the execution of a target node and are used for reporting.

[0078] The execution timestamp is the time information of when the target execution event occurred, used to record the occurrence time of the target execution event. The execution success / failure return code is encoded information used to characterize the execution result of the target execution event.

[0079] For example, the execution success / failure return codes may include return codes for indicating successful execution and return codes for indicating execution failure, and the return codes for indicating execution failure may further distinguish different reasons for failure.

[0080] The target execution event is one of the following: execution start event, execution end event, or execution exception reporting event.

[0081] Specifically, the execution start event indicates that the target node has started executing the task corresponding to the in-vehicle voice command; the execution end event indicates that the target node has completed the task corresponding to the in-vehicle voice command; and the execution exception reporting event indicates that the target node detected an exception during the execution process.

[0082] For example, taking the window control node as the target node, the window control node reports an execution start event when it starts executing the window opening task, reports an execution end event when the window opening task is completed, and reports an execution exception reporting event when it cannot continue execution due to an anomaly detected during the execution process. Each reported execution status information carries the node identifier, the corresponding target execution event, the execution timestamp of the target execution event, and the execution success or failure return code.

[0083] Figure 3 This is a flowchart illustrating yet another voice command monitoring method provided in an embodiment of the present disclosure, as shown below. Figure 3 As shown, the method includes the following steps: S301, responding to in-vehicle voice commands, executes the in-vehicle voice commands and obtains the execution reporting information of the target node.

[0084] For details, please refer to S201; further details will not be provided here.

[0085] S302. Based on the globally unique tracking identifier, find the execution status information of the upstream execution node of the target node.

[0086] Among them, the upstream execution node is the execution node that is located before the target node in the execution node chain.

[0087] For example, when the target node is the third node in the execution node chain, the upstream execution nodes include the first node and the second node.

[0088] In one possible implementation, the execution status information reported by each execution node in the execution node chain is associated with a globally unique tracking identifier corresponding to the vehicle voice command. After obtaining the execution reporting information of the target node, the globally unique tracking identifier is used as an index to search for all execution status information associated with the globally unique tracking identifier from the stored execution status information, and the execution status information of the upstream execution node of the target node is determined from it.

[0089] S303. Generate global execution traceability information based on the execution status information and execution reporting information of the upstream execution nodes.

[0090] The aforementioned global execution traceability information is used to characterize the entire execution process of in-vehicle voice commands on the execution node chain.

[0091] The aforementioned global execution traceability information includes the execution status information and vehicle status information of each execution node that has been executed on the execution node chain.

[0092] In one possible implementation, the execution status information of the upstream execution node and the execution reporting information of the target node are concatenated according to the order of each execution node in the execution node chain to obtain global execution traceability information.

[0093] For example, the execution node chain includes a first node, a second node, and a third node. When the third node is the target node, the global execution traceability information includes the execution status information and vehicle status information of the first node, the execution status information and vehicle status information of the second node, and the execution status information and vehicle status information of the third node.

[0094] S304. Based on global execution traceability information, monitor the execution anomalies of in-vehicle voice commands.

[0095] In one possible implementation, the execution status information and vehicle status information of each execution node in the global execution traceability information are verified, including verifying whether the execution sequence of each execution node is continuous, whether the execution success or failure return code indicates successful execution, and whether the vehicle status information at each execution node has undergone abnormal changes; if the verification determines that there is an execution abnormality, an execution abnormality prompt is output to realize the monitoring of execution abnormalities of in-vehicle voice commands.

[0096] In one embodiment, the above-mentioned execution reporting information instructs the target node to report an anomaly.

[0097] The execution reporting information instructs the target node to report an anomaly. This means that the target execution event indicated by the execution status information in the execution reporting information is an execution anomaly reporting event. In other words, the target node detects an anomaly during the execution of the task corresponding to the vehicle voice command and reports the anomaly by reporting the execution anomaly reporting event.

[0098] For example, when a target node detects an execution error, it can set the execution success or failure return code to a value that indicates execution failure, and report it together with the execution exception reporting event, node identifier and execution timestamp. The execution reporting information obtained at this time indicates that the target node has reported the exception.

[0099] In this embodiment, when the target node is instructed to report an anomaly by the execution of the reporting information, it is determined that the target node has an anomaly. What needs to be further determined is whether the anomaly of the target node is caused by itself or by the anomaly propagation of the upstream execution node. The following sub-steps are for this determination process.

[0100] In one embodiment, the above-mentioned S304, monitoring for execution anomalies of in-vehicle voice commands based on global execution traceability information, includes the following sub-steps: Ⅰ. Trace the first abnormal node in the upstream execution nodes.

[0101] The first abnormal node is the earliest node in the upstream execution node chain to exhibit an execution abnormality.

[0102] An execution anomaly occurs in the upstream execution node, which means that the execution status information of the upstream execution node indicates execution failure or indicates an execution anomaly reporting event.

[0103] In one possible implementation, based on global execution tracing information, the execution status information of each upstream execution node is checked sequentially from the first execution node toward the target node according to the order of the execution node chain. When an upstream execution node is found whose execution status information indicates an execution abnormality, the upstream execution node is identified as the first abnormal node. If the execution status information of each upstream execution node indicates normal execution, the first abnormal node is determined to not exist.

[0104] II. If the first abnormal node exists, mark the target node as a derived fault node.

[0105] The aforementioned derived fault nodes are used to characterize the execution nodes whose anomalies are caused by the propagation of anomalies from upstream execution nodes.

[0106] If the first abnormal node exists, the target node is located after the first abnormal node and is in the same execution chain as the first abnormal node. The abnormality of the target node occurs against the background of an abnormality that has already occurred upstream, indicating that the abnormality of the target node is caused by the propagation of the upstream abnormality. Therefore, the target node is marked as a derived fault node.

[0107] III. If the first abnormal node does not exist, mark the target node as the root cause failure node.

[0108] The aforementioned root cause failure nodes are used to characterize the execution nodes that are the source of the anomaly.

[0109] In the absence of the first abnormal node, all upstream execution nodes performed normally, while the target node itself reported an anomaly, indicating that the anomaly originated from the target node itself rather than being propagated upstream. Therefore, the target node was marked as the root cause failure node.

[0110] For example, in the case where the execution node chain includes a first node, a second node, and a third node connected in sequence, and the third node is the target node: if the execution status information of the first node indicates an execution abnormality, and the third node reports an abnormality, then the first abnormal node traced back is the first node, and the third node is marked as a derived fault node; if the execution status information of both the first node and the second node indicates normal execution, and the third node reports an abnormality, then the first abnormal node does not exist, and the third node is marked as the root cause fault node.

[0111] In one embodiment, the execution reporting information indicates that the target node has not reported any abnormalities, and the execution time of the target node exceeds the upper limit threshold of the execution time of the target node.

[0112] Among them, execution time is the time consumed by the target node in executing the vehicle voice command.

[0113] For example, the execution time can be determined based on the time difference between the execution timestamp of the execution start event and the execution timestamp of the execution end event reported by the target node.

[0114] Alternatively, if the target node has not yet reported the execution completion event, the execution time can also be determined based on the time difference between the execution start event timestamp and the current time.

[0115] The above-mentioned upper limit threshold for execution time is the benchmark for judging the execution time of the target node. If the execution time exceeds the upper limit threshold, it is considered that the target node may have hidden anomalies such as slow execution.

[0116] In the above scenario, the target node did not report any anomalies, indicating that it did not detect any execution anomalies during the process. However, the execution time exceeded the upper limit threshold, suggesting that the target node may actually have unreported latent anomalies. The cause of these latent anomalies may be related to the external environment of the vehicle, such as low temperatures causing slow response of the actuators or low vehicle power supply voltage leading to insufficient power supply to the actuators. Therefore, in this scenario, it is necessary to further determine the cause of the target node's failure based on the vehicle's status.

[0117] In one embodiment, the above-mentioned S304, monitoring for execution anomalies of in-vehicle voice commands based on global execution traceability information, further includes the following sub-steps: I. Based on the information of the first vehicle state transmission chain, determine the index value of at least one vehicle state index.

[0118] Among them, vehicle status indicators are used to quantitatively characterize the operating status of vehicles.

[0119] For example, vehicle status indicators may include vehicle power supply voltage, vehicle ambient temperature, vehicle speed, etc.

[0120] The above indicator values ​​are the values ​​of the vehicle status indicators at the corresponding time.

[0121] In one possible implementation, since the first vehicle state transmission chain information records the vehicle state information at each execution node on the execution node chain, vehicle state parameters can be extracted from the vehicle state information contained in the first vehicle state transmission chain information, and the index value of at least one vehicle state index can be determined based on the extracted vehicle state parameters.

[0122] II. If the value of any vehicle status indicator deviates from the normal range of any vehicle status indicator, the target node shall be marked as a fault node caused by environmental factors.

[0123] Among them, the normal index value range is the range of values ​​that the vehicle status index should be in under normal vehicle operating conditions.

[0124] The failure nodes caused by the above-mentioned environmental factors are execution nodes whose failures originate from the external environment of the vehicle, rather than from defects in the execution nodes themselves.

[0125] In one possible implementation, the values ​​of each vehicle status indicator are compared with the corresponding normal indicator value range. If the value of any vehicle status indicator deviates from the normal indicator value range, it indicates that the current operating state of the vehicle is greatly affected by the external environment. The reason why the execution time of the target node exceeds the upper limit threshold of the execution time is related to environmental factors. Therefore, the target node is marked as a fault node caused by environmental factors.

[0126] For example, the in-vehicle voice command is "open the window". The execution node chain includes a first node, a second node, and a third node, with the third node being the window control node. The window control node does not report any abnormalities, but the execution time exceeds the upper limit threshold. Based on the information from the first vehicle status transmission chain, the index value of the vehicle's ambient temperature is determined to be -20℃, which deviates from the normal index value range of the vehicle's ambient temperature. Therefore, the window control node is marked as a fault node caused by environmental factors, indicating that the slow window execution is caused by the low temperature environment causing the window lift motor to respond slowly, rather than a defect in the window control node itself.

[0127] Based on this, the fault nodes caused by environmental factors, together with the aforementioned root cause fault nodes and derived fault nodes, constitute three complete categories of labels for the causes of execution anomalies, enabling the differentiation and localization of faults with different causes.

[0128] The upper limit threshold for the execution time of the aforementioned target node is determined based on the scenario type of the first vehicle state transmission chain information matching.

[0129] Among them, the scenario type refers to the type of scenario in which the vehicle operates, which is determined based on the vehicle's state.

[0130] For example, the scene type may include low temperature scene, normal temperature scene, high speed driving scene, low speed driving scene, stationary scene, etc.

[0131] It should be understood that the execution time of execution nodes varies depending on the environment and operating conditions in different scenario types. For example, the response speed of the window lift motor is slower in low-temperature scenarios than in normal-temperature scenarios. Therefore, the upper limit threshold of the execution time of the target node may be different in different scenario types.

[0132] In one possible implementation, a correspondence between scenario types and execution time upper limit thresholds can be established in advance. After obtaining the execution reporting information of the target node, vehicle status parameters are extracted from the vehicle status information contained in the first vehicle status transmission chain information. The scenario type is matched according to the extracted vehicle status parameters. Then, the execution time upper limit threshold of the target node under the scenario type is determined according to the matched scenario type and the above correspondence.

[0133] For example, the above correspondence records the following: the upper limit threshold for the execution time of the window control node in a normal temperature scenario is 5 seconds, the upper limit threshold for the execution time of the window control node in a low temperature scenario is 15 seconds, the in-vehicle voice command is "open the window", the third node is the target node, and the vehicle ambient temperature recorded in the first vehicle state transmission chain information is -20℃. Based on this, the matched scenario type is a low temperature scenario, so the upper limit threshold for the execution time of the window control node is determined to be 15 seconds. The execution time of the window control node is 12 seconds, which does not exceed 15 seconds, so the window control node is judged to be executing normally. If a fixed upper limit threshold for the execution time is used (such as 5 seconds in a normal temperature scenario), the 12-second execution time of the window control node will be mistakenly judged as an abnormal execution.

[0134] Based on this, the upper limit threshold of execution time is determined by matching the scenario type based on the information of the first vehicle state transmission chain. This makes the judgment benchmark of execution time compatible with the actual scenario in which the vehicle is located, avoiding misjudging normal execution as execution abnormality in scenarios where the environment or working conditions cause the normal execution time to increase. It also avoids missing judgment due to the threshold being too wide in abnormal scenarios, thus improving the accuracy of execution abnormality monitoring.

[0135] Figure 4 This is a flowchart illustrating yet another voice command monitoring method provided in an embodiment of the present disclosure, as shown below. Figure 4 As shown, the method includes the following steps: S401, responding to in-vehicle voice commands, executes the in-vehicle voice commands and obtains the execution reporting information of the target node.

[0136] For details, please refer to S201; further details will not be provided here.

[0137] S402. Based on the execution report information, monitor the execution anomalies of the vehicle voice commands.

[0138] For details, please refer to S202; further details will not be provided here.

[0139] S403. Generate and update the content displayed in the floating window based on the target display content.

[0140] The target display content includes: a globally unique tracking identifier and completion information from the first execution node to the target node.

[0141] The completion status information includes: completed without any abnormalities, completed with abnormalities, and in progress.

[0142] The above has completed the subdivision of faults and detailed descriptions corresponding to faults that are derived, root cause, or caused by environmental factors in the anomaly identification.

[0143] The content displayed in the floating window refers to the content shown in the floating window.

[0144] The aforementioned floating window is a display window that is overlaid on the display interface of the vehicle's infotainment system. It is used to display the execution status of in-vehicle voice commands without obstructing or interrupting the current display interface.

[0145] The aforementioned completion status information is used to characterize the execution completion status of each execution node between the first execution node and the target node.

[0146] The above-mentioned "completed without anomalies" flag indicates that the execution node has completed execution and no anomalies occurred during the execution process.

[0147] The above-mentioned "completed exception" flag is used to indicate that the execution node has completed execution but an exception occurred during the execution process.

[0148] In the above process, the identifier is used to indicate that the execution node has not yet completed execution and is in the process of execution.

[0149] The aforementioned subdivision identifiers include subdivision identifiers corresponding to derived faults, subdivision identifiers corresponding to root cause faults, and subdivision identifiers corresponding to faults caused by environmental factors, which are used to indicate whether the execution node is marked as a derived fault node, a root cause fault node, or a fault node caused by environmental factors.

[0150] The above fault details description provides information about the specific circumstances of the fault.

[0151] For example, the fault details description may include information such as the node identifier of the faulty node, the fault type, the time of the fault occurrence, and the cause of the fault.

[0152] In one possible implementation, during the execution of in-vehicle voice commands, as the execution node chain progresses, the target display content is determined in real time based on the acquired execution reporting information and the marking results of each execution node; if the target display content changes, the floating window display content is generated and updated based on the updated target display content, so that the floating window display content remains synchronized with the actual execution progress of the execution node chain.

[0153] For example, the circumstances under which the target displayed content changes may include: the target node reporting an execution start event, an execution end event, or an execution exception reporting event, or the execution node being marked as a derived failure node, a root cause failure node, or a failure node caused by environmental factors.

[0154] For example, the in-vehicle voice command is "open the car window", and the execution node chain includes a first node, a second node, and a third node.

[0155] During the execution of the first node, the floating window displays a globally unique tracking identifier and a "processing in progress" identifier for the first node. When the first node completes execution without exception and the second node begins execution, the floating window updates to display the globally unique tracking identifier, the "completed without exception" identifier for the first node, and the "processing in progress" identifier for the second node. When the second node completes execution and is marked as a root cause failure node, and the third node begins execution, the floating window updates to display the globally unique tracking identifier, the "completed without exception" identifier for the first node, the "completed with exception" identifier for the second node, and the "processing in progress" identifier for the third node. The "completed with exception" identifier for the second node carries the sub-identifier and fault details description corresponding to the root cause failure. When the third node completes execution and is marked as a derivative failure node, the floating window updates to display the globally unique tracking identifier, the "completed without exception" identifier for the first node, the "completed with exception" identifier for the second node, and the "completed with exception" identifier for the third node. The "completed with exception" identifier for the third node carries the sub-identifier and fault details description corresponding to the derivative failure.

[0156] Based on this, a floating window displays a globally unique tracking identifier and the completion status information from the first execution node to the target node. In the completed but abnormal identifier, further detailed identifiers and fault details are displayed, enabling users to intuitively perceive the execution progress and abnormal situations of voice commands, and realize the visual monitoring of the voice command execution process.

[0157] Figure 5 This is a schematic diagram of the structure of a vehicle-mounted voice command execution anomaly monitoring device provided in an embodiment of this disclosure, as shown below. Figure 5 As shown, the device includes an execution module 501 and a monitoring module 502.

[0158] The aforementioned execution module 501 is used to respond to in-vehicle voice commands, execute in-vehicle voice commands, and obtain execution reporting information from target nodes; wherein, the target node is a node in the execution node chain of the in-vehicle voice command that is in the execution state.

[0159] The aforementioned monitoring module 502 is used to monitor for abnormal execution of in-vehicle voice commands based on the execution report information.

[0160] Among them, the execution reporting information is used to indicate the execution status information and the first vehicle status transmission chain information; the first vehicle status transmission chain information includes the second vehicle status transmission chain information of the previous execution node of the target node and the vehicle status information at the target node; when the target node is the first execution node in the execution node chain, the second vehicle status transmission chain information includes the globally unique tracking identifier of the vehicle voice command and the vehicle status information at the time of the vehicle voice command response.

[0161] In one embodiment, the execution status information includes: node identifier, target execution event, execution timestamp of the target execution event, and execution success / failure return code; wherein, the target execution event is one of execution start event, execution end event, and execution exception reporting event.

[0162] In one embodiment, the monitoring module 502 is further configured to: locate the execution status information of the upstream execution node of the target node based on the globally unique tracking identifier; generate global execution traceability information based on the execution status information and execution reporting information of the upstream execution node; and monitor the execution anomalies of the vehicle voice commands based on the global execution traceability information.

[0163] In one embodiment, the aforementioned execution reporting information instructs the target node to report an anomaly; the aforementioned monitoring module 502 is also used to trace the first abnormal node among the upstream execution nodes; if the first abnormal node exists, the target node is marked as a derived fault node; if the first abnormal node does not exist, the target node is marked as a root cause fault node.

[0164] In one embodiment, the aforementioned execution reporting information indicates that the target node has not reported any abnormalities, and the execution time of the target node exceeds the upper limit threshold of the execution time of the target node; the aforementioned monitoring module 502 is further configured to determine the index values ​​of at least one vehicle status index based on the first vehicle status transmission chain information; if the index value of any vehicle status index deviates from the normal index value range of any vehicle status index, the target node is marked as a fault node caused by environmental factors.

[0165] In one embodiment, the upper limit threshold for the execution time of the target node is determined based on the scenario type of the first vehicle state transmission chain information matching.

[0166] In one embodiment, the monitoring module 502 is further configured to generate and update the floating window display content based on the target display content; wherein, the target display content includes: a globally unique tracking identifier and completion status identifier information from the first execution node to the target node; the completion status identifier information includes: a completed without anomaly identifier, a completed with anomaly identifier, and a processing identifier; the completed with anomaly identifier includes subdivided identifiers corresponding to derivative faults, root cause faults, and faults caused by environmental factors, as well as a fault details description.

[0167] The vehicle voice command execution anomaly monitoring device provided in this embodiment can implement each step of the vehicle voice command execution anomaly monitoring method provided in the above method embodiment. To avoid repetition, it will not be described again here.

[0168] For details on the specific functions and interaction methods of each module, please refer to the detailed description of the corresponding steps in the aforementioned method embodiments, which will not be repeated here.

[0169] In the case of implementing the functions of the integrated modules described above in hardware, this disclosure provides a possible structure for the control device involved in the above embodiments. Figure 6 This is a schematic diagram of a control device provided in an embodiment of this disclosure. Figure 6 As shown, the control device 600 includes a processor 602 and a bus 604. Optionally, the control device may also include a memory 601; optionally, the control device 600 may also include a communication interface 603.

[0170] Processor 602 may implement or execute various exemplary logic blocks, modules, and circuits described in conjunction with embodiments of this disclosure. Processor 602 may be a central processing unit, a general-purpose processor, a digital signal processor, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It may implement or execute various exemplary logic blocks, modules, and circuits described in conjunction with embodiments of this disclosure. Processor 602 may also be a combination that implements computing functions, such as including one or more microprocessor combinations, a combination of a DSP and a microprocessor, etc.

[0171] Communication interface 603 is used to connect to other devices via a communication network. This communication network can be Ethernet, wireless access network, wireless local area network (WLAN), etc.

[0172] The memory 601 may be a read-only memory (ROM) or other type of static storage device capable of storing static information and instructions, random access memory (RAM) or other type of dynamic storage device capable of storing information and instructions, or electrically erasable programmable read-only memory (EEPROM), disk storage medium or other magnetic storage device, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but is not limited thereto.

[0173] In one possible implementation, the memory 601 can exist independently of the processor 602. The memory 601 can be connected to the processor 602 via a bus 604 and is used to store instructions or program code. When the processor 602 calls and executes the instructions or program code stored in the memory 601, it can implement the voice command monitoring method provided in this embodiment. In another possible implementation, the memory 601 can also be integrated with the processor 602.

[0174] Bus 604 can be an extended industry standard architecture (EISA) bus, etc. Bus 604 can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 6 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0175] Some embodiments of this disclosure provide a computer-readable storage medium (e.g., a non-transitory computer-readable storage medium) storing computer program instructions that, when executed on a processor, cause the processor to perform the voice command monitoring method as described in any of the above embodiments.

[0176] Exemplary examples of computer-readable storage media may include, but are not limited to: magnetic storage devices (e.g., hard disks, floppy disks, or magnetic tapes), optical discs (e.g., compact disks (CDs), digital versatile disks (DVDs), etc.), smart cards, and flash memory devices (e.g., erasable programmable read-only memory (EPROMs), cards, sticks, or key drives, etc.). The various computer-readable storage media described in this disclosure may represent one or more devices for storing information and / or other machine-readable storage media. The term machine-readable storage media may include, but is not limited to, wireless channels and various other media capable of storing, containing, and / or carrying instructions and / or data.

[0177] This disclosure provides a computer program product containing instructions that, when run on a processor, cause the processor to execute the voice command monitoring method described in any of the above embodiments.

[0178] This disclosure provides a vehicle including the control device of any of the preceding embodiments; or the computer-readable storage medium of any of the preceding embodiments; or the computer program product of any of the preceding embodiments.

[0179] The vehicle provided in this application may be a passenger vehicle or a freight vehicle, and may also be an electric vehicle or a hybrid vehicle. This application does not limit the specific purpose or power type of the vehicle, and the choice can be made according to actual needs.

[0180] In some examples, a vehicle consists of a body and wheels. The body is used for passengers and for carrying goods, while the wheels are mounted underneath the body to support it and allow it to roll on the road surface, thus enabling the vehicle to move.

[0181] In some possible examples, the vehicle is equipped with a control system, which typically adopts a layered distributed architecture. From the bottom layer to the top layer, it can be roughly divided into a perception layer, a control layer, a coordination layer, and an interaction layer. The layers communicate with each other through an in-vehicle network.

[0182] The perception layer mainly consists of various sensors distributed inside and outside the vehicle, including but not limited to external environment cameras, millimeter-wave radar, lidar, ultrasonic sensors, in-vehicle driver monitoring cameras, microphone arrays, and various vehicle status sensors (such as wheel speed sensors, inertial measurement units, temperature sensors, etc.). The perception layer is responsible for collecting multi-dimensional data such as the vehicle's own operating status, driver behavior, and external driving environment in real time.

[0183] The control layer consists of dozens to hundreds of electronic control units (ECUs), distributed across multiple functional domains including powertrain, chassis, body, intelligent driving, and infotainment. Each ECU embeds real-time control software that performs closed-loop control of the vehicle's actuators based on preset control strategies or upper-level commands, and generates corresponding alarm signals when abnormal conditions are detected. Typical ECUs include the engine control unit, transmission control unit, brake control unit, steering control unit, vehicle stability control unit, airbag control unit, intelligent driving domain controller, and in-vehicle infotainment unit.

[0184] The coordination layer typically exists in the form of a domain controller or a central computing platform, responsible for cross-domain data fusion, global state management, and collaborative decision-making. The coordination layer centrally processes and schedules the sensing data and control commands that were originally scattered across various functional domains, connecting downwards to various electronic control units and supporting human-machine interaction functions upwards.

[0185] The interaction layer mainly includes in-cabin display devices (such as instrument panel, central control screen, head-up display), voice interaction system, haptic feedback device, etc., which are responsible for presenting vehicle status, warning information and driving suggestions to the driver in the form of visual, auditory or tactile, while receiving the driver's touch, voice and other input commands.

[0186] Data transmission and interaction between different layers are achieved through the vehicle bus network. Common vehicle bus protocols include CAN (Controller Area Network), CAN FD (CAN with Flexible Data-Rate), LIN (Local Interconnect Network), FlexRay, and vehicle Ethernet, which supports high-bandwidth data transmission. Among these, CAN and CAN FD buses are widely used for communication in real-time control domains such as powertrain and chassis, while vehicle Ethernet is gradually being applied to high-bandwidth sensor data transmission in the intelligent driving domain and multimedia interaction scenarios in the cockpit domain.

[0187] In some possible examples, the intelligent driving domain controller, as the core of the in-vehicle computing platform, is equipped with a processor and memory to execute the voice command monitoring method provided in the embodiments of this application.

[0188] For example, the control device of this application is arranged in the intelligent driving domain controller.

[0189] For example, the intelligent driving domain controller has multiple functional modules deployed to perform the various method steps.

[0190] The above description is merely a specific embodiment of this disclosure, but the scope of protection of this disclosure is not limited thereto. Any changes or substitutions within the technical scope disclosed in this disclosure should be included within the scope of protection of this disclosure. Therefore, the scope of protection of this disclosure should be determined by the scope of the claims.

Claims

1. A voice command monitoring method, characterized in that, The method includes: In response to an in-vehicle voice command, the in-vehicle voice command is executed, and the execution reporting information of the target node is obtained; wherein, the target node is a node in the execution node chain of the in-vehicle voice command that is in the execution state; Based on the reported execution information, the execution anomaly of the vehicle voice commands is monitored. The execution reporting information is used to indicate the execution status information and the first vehicle status transmission chain information; The first vehicle state transmission chain information includes the second vehicle state transmission chain information of the previous execution node of the target node and the vehicle state information at the target node; When the target node is the first execution node in the execution node chain, the second vehicle status transmission chain information includes the globally unique tracking identifier of the vehicle voice command and the vehicle status information at the moment of the vehicle voice command response.

2. The voice command monitoring method according to claim 1, characterized in that, The execution status information includes: node identifier, target execution event, execution timestamp of the target execution event, and execution success / failure return code; The target execution event is one of the following: execution start event, execution end event, or execution exception reporting event.

3. The voice command monitoring method according to claim 2, characterized in that, The monitoring of execution anomalies of the in-vehicle voice commands based on the execution status event includes: Based on the globally unique tracking identifier, find the execution status information of the upstream execution node of the target node; Based on the execution status information of the upstream execution node and the execution reporting information, global execution traceability information is generated; Based on the global execution traceability information, the execution anomaly of the vehicle voice commands is monitored.

4. The voice command monitoring method according to claim 3, characterized in that, The execution reporting information instructs the target node to report an anomaly. The step of monitoring execution anomalies of the in-vehicle voice commands based on the global execution traceability information includes: Trace the first abnormal node in the upstream execution nodes; If the first abnormal node exists, the target node is marked as a derived fault node; If the first abnormal node does not exist, the target node is marked as the root cause failure node.

5. The voice command monitoring method according to claim 3, characterized in that, The execution reporting information indicates that the target node did not report any abnormalities, and the execution time of the target node exceeds the upper limit threshold of the execution time of the target node; The step of monitoring execution anomalies of the in-vehicle voice commands based on the global execution traceability information includes: Based on the first vehicle status transmission chain information, determine the index value of at least one vehicle status index. If the value of any vehicle status indicator deviates from the normal range of the at least one vehicle status indicator, the target node is marked as a fault node caused by environmental factors.

6. The voice command monitoring method according to claim 5, characterized in that, The upper limit threshold for the execution time of the target node is determined based on the scenario type matched by the information of the first vehicle state transmission chain.

7. The voice command monitoring method according to any one of claims 1-6, characterized in that, The method further includes: Generate and update the content of the floating window based on the target display content; The target display content includes: the globally unique tracking identifier and the completion status identifier information from the first execution node to the target node; the completion status identifier information includes: completed without anomalies, completed with anomalies, and in progress; the completed with anomalies identifier includes subdivided identifiers corresponding to derivative faults, root cause faults, and faults caused by environmental factors, as well as fault details descriptions.

8. A voice command monitoring device, characterized in that, The device includes: An execution module is used to respond to an in-vehicle voice command, execute the in-vehicle voice command, and obtain execution reporting information from a target node; wherein, the target node is a node in the execution node chain of the in-vehicle voice command that is in the execution state. The monitoring module is used to monitor for execution anomalies of the vehicle voice commands based on the execution reporting information. The execution reporting information is used to indicate the execution status information and the first vehicle status transmission chain information; The first vehicle state transmission chain information includes the second vehicle state transmission chain information of the previous execution node of the target node and the vehicle state information at the target node; When the target node is the first execution node in the execution node chain, the second vehicle status transmission chain information includes the globally unique tracking identifier of the vehicle voice command and the vehicle status information at the moment of the vehicle voice command response.

9. A control device, characterized in that, The control device includes: a memory and a processor; the memory and the processor are coupled; the memory is used to store instructions executable by the processor; when the processor executes the instructions, it performs the voice command monitoring method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that, when executed on an electronic device, cause the electronic device to perform the voice command monitoring method as described in any one of claims 1 to 7.

11. A computer program product, characterized in that, It includes a computer program; when the computer program is executed, it is capable of implementing the voice command monitoring method as described in any one of claims 1 to 7.

12. A vehicle, characterized in that, Includes the voice command monitoring device as described in claim 8; or the computer-readable storage medium as described in claim 10; or the computer program product as described in claim 11.

Images