Vehicle log uploading method and device based on voice instruction, equipment and medium

Abstract

The invention discloses a whole vehicle log uploading method, device and equipment based on a voice instruction and a medium, and relates to the technical field of whole vehicle log upload, and the method comprises the steps: monitoring a voice instruction in a cabin in real time, and executing a log collection task when the voice instruction comprises a preset keyword; according to a mapping relation between a pre-configured domain controller and an application program, decomposing the whole vehicle log acquisition task into sub-acquisition tasks corresponding to each domain controller; and distributing the sub-collection tasks to each domain controller so as to collect and upload domain controller logs. According to the method, log collection is triggered by monitoring the cockpit voice instruction in real time and recognizing the preset keyword, so that a user can directly participate in a fault reporting process, timely uploading of the log can be triggered, and the situation that the log at the vehicle-mounted end is lost due to cyclic coverage is avoided. Meanwhile, through the mapping relation between the pre-configured domain controller and the application program, the relevance of related log data can be ensured.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of vehicle log uploading, in particular to a vehicle log uploading method and device based on voice instructions, equipment and medium. BACKGROUND

[0002] Under the background of the rapid development of vehicle intelligence and networking, the vehicle machine system and its related domain controllers will generate a large amount of log data during operation. These logs are of great significance for fault diagnosis, system optimization and user experience improvement.

[0003] Currently, multiple target domains are usually monitored in the vehicle machine system, abnormal system logs are identified and automatically compressed and uploaded to the cloud to achieve efficient acquisition of fault logs. However, automatic capture and identification may lead to invalid log uploading due to misjudgment, increasing the storage burden of the cloud. At the same time, since the user is not given the ability to actively trigger log uploading, log collection cannot be started immediately when the user perceives a fault, resulting in a delay between problem feedback and log collection. In addition, the existing scheme usually only supports cabin domain log collection and cannot cover multiple domain controllers of the whole vehicle, so the log information is incomplete and cannot support joint troubleshooting of cross-domain problems. SUMMARY

[0004] The present application provides a vehicle log uploading method and device based on voice instructions, which can solve the technical problems of inflexible triggering mechanism and incomplete log coverage in the prior art.

[0005] In a first aspect, the present application provides a vehicle log uploading method based on voice instructions, which comprises: Real-time monitoring of voice instructions in the cabin, and when the voice instructions include a preset keyword, performing a log collection task; According to the mapping relationship between the preconfigured domain controllers and the application programs, the vehicle log collection task is decomposed into sub-collection tasks corresponding to each domain controller; Distribute sub-collection tasks to each domain controller to collect and upload domain controller logs.

[0006] In combination with the first aspect, in an implementation mode, after real-time monitoring of voice instructions in the cabin, it comprises: Matching the fields contained in the voice instructions with the preset keywords until the voice instructions matching the preset keywords are captured; Determine whether the current communication state of the vehicle is normal; If yes, determine whether the triggering condition of the voice instruction is legal, if yes, confirm that the voice instruction includes a preset keyword, if no, terminate and discard the voice instruction this time; If not, after caching the voice command, check again whether the vehicle's current communication status is normal.

[0007] In conjunction with the first aspect, in one implementation, the step of decomposing the vehicle log collection task into sub-collection tasks corresponding to each domain controller based on the pre-configured mapping relationship between domain controllers and applications includes: Establish communication links between the master control process of the vehicle-mounted cockpit domain and the slave control processes of each domain controller; The master control process receives log collection tasks, and the log collection tasks include a two-dimensional task descriptor composed of the identifiers of each domain controller and the identifiers of the applications to be collected in each domain controller. The main control process decomposes the vehicle log collection task into sub-collection tasks corresponding to each domain controller based on the two-dimensional task descriptor and the pre-configured mapping relationship between domain controllers and applications.

[0008] In conjunction with the first aspect, in one implementation, the distribution of sub-collection tasks to each domain controller for collecting and uploading domain controller logs includes: The master control process distributes the generated multiple sub-acquisition tasks to the slave control processes on the corresponding domain controllers through a communication link. The slave control process retrieves and compresses logs generated by the applications to be collected in this domain within a preset time period; The slave process returns the collection status and collected logs to the master process; When the data collection status indicates that data collection is complete, the main control process uploads the collected logs.

[0009] In conjunction with the first aspect, in one implementation, the main control process uploads the collected logs, including: The collected logs are divided into fragments according to the fragmentation algorithm; The fragments are uploaded in parallel using the Hypertext Transfer Security Protocol. Monitor the upload status of each fragment and check whether a successful response has been received; If so, continue uploading the fragments until all fragments have been uploaded; If not, the fragment for which no response was received will be retransmitted individually. If no response is received after retransmission, the fragment will be returned to the local mapping buffer for temporary storage until the network is restored and the incomplete fragment will be automatically resumed from the breakpoint until all fragments are uploaded.

[0010] In conjunction with the first aspect, in one implementation, after the main control process uploads the collected logs when the collection status indicates that collection is complete, the process includes: The generation and uploading of fault work orders are triggered based on the collected logs; Track the processing progress of the fault work orders in real time; After the fault work order is processed, a notification of the processing result of the fault work order is output.

[0011] In conjunction with the first aspect, in one implementation, the step of decomposing the vehicle log collection task into sub-collection tasks corresponding to each domain controller based on the pre-configured mapping relationship between domain controllers and applications includes: A communication link is established between the master control process in the vehicle-mounted cockpit domain and the slave control processes of each domain controller; The log collection task is generated based on the pre-configured collection scope information, which includes the target domain controllers to be collected and the target applications on each target domain controller. The master control process extracts a two-dimensional task descriptor composed of the target domain controller identifier and the target application identifier to be collected in each target domain controller; The master control process generates multiple sub-acquisition tasks for each target domain controller based on the two-dimensional task descriptor and the pre-configured mapping relationship between domain controllers and applications.

[0012] Secondly, embodiments of this application provide a vehicle log upload device based on voice commands, the vehicle log upload device based on voice commands includes: The vehicle-mounted voice module is used to monitor voice commands in the cabin in real time, and to perform log collection tasks when the voice command includes preset keywords. The decomposition module is used to decompose the vehicle log collection task into sub-collection tasks corresponding to each domain controller based on the pre-configured mapping relationship between the domain controller and the application. The data collection module is used to distribute sub-collection tasks to each domain controller for collecting and uploading domain controller logs.

[0013] Thirdly, embodiments of this application provide a vehicle log upload device based on voice commands. The vehicle log upload device based on voice commands includes a processor, a memory, and a vehicle log upload program based on voice commands stored in the memory and executable by the processor. When the vehicle log upload program based on voice commands is executed by the processor, it implements the steps of the vehicle log upload method based on voice commands as described in any of the above embodiments.

[0014] Fourthly, embodiments of this application provide a computer-readable storage medium storing a vehicle log upload program based on voice commands, wherein when the vehicle log upload program based on voice commands is executed by a processor, it implements the steps of the vehicle log upload method based on voice commands as described in any of the above embodiments.

[0015] The beneficial effects of the technical solutions provided in this application include: This application embodiment triggers log collection by real-time monitoring of cockpit voice commands and recognizing preset keywords, allowing users to directly participate in the fault reporting process. This ensures timely log uploads, preventing log loss due to cyclic overwriting and reducing cloud storage load caused by invalid log uploads, thus lowering maintenance costs. Furthermore, this embodiment's collection task covers logs generated by all domain controllers in the vehicle within a preset time period, ensuring log data integrity and end-to-end coverage. The pre-configured mapping between domain controllers and applications ensures the correlation of relevant log data, facilitating subsequent troubleshooting and analysis. Attached Figure Description

[0016] Figure 1 This is a flowchart illustrating an embodiment of the vehicle log upload method based on voice commands according to this application; Figure 2 An architecture diagram of the vehicle-mounted terminal and the cloud provided in the embodiments of this application; Figure 3 A fault handling flowchart provided for an embodiment of this application; Figure 4 This is a schematic diagram of the functional modules of an embodiment of the vehicle log upload device based on voice commands of this application; Figure 5 This is a schematic diagram of the hardware structure of the vehicle log upload device based on voice commands involved in the embodiments of this application. Detailed Implementation

[0017] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present application.

[0018] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0019] This application provides a method, apparatus, device, and medium for uploading vehicle logs based on voice commands, which can solve the technical problems of inflexible triggering mechanisms and incomplete log coverage in the prior art.

[0020] In a first aspect, embodiments of this application provide a method for uploading vehicle logs based on voice commands.

[0021] In one embodiment, reference is made to Figure 1 , Figure 1 This is a flowchart illustrating an embodiment of the vehicle log upload method based on voice commands according to this application. Figure 1 As shown, the method for uploading vehicle logs based on voice commands includes the following steps: Step S1: Monitor voice commands in the cockpit in real time, and execute the log collection task when the voice command includes preset keywords.

[0022] Specifically, during vehicle startup or operation, applications on each domain controller in the vehicle generate logs or store data locally. When users encounter vehicle malfunctions, they can report them to after-sales personnel via a mini-program, application, or telephone. After-sales personnel will understand the general fault based on the user's description, record a summary of the fault, and then inform the vehicle user that they can trigger the upload of the entire vehicle log using voice commands. Vehicle malfunctions include, but are not limited to, air conditioning malfunctions and Bluetooth malfunctions. The voice module in the vehicle analyzes the audio signals captured in the cabin in real time to detect whether they contain preset keywords.

[0023] In this embodiment of the application, after real-time monitoring of voice commands within the cockpit, the following steps are included: Step S101: Match the fields contained in the voice command with preset keywords until a voice command that matches the preset keywords is captured.

[0024] Specifically, the preset keyword can be "log upload". Furthermore, to accommodate different user expression habits, the keyword library can also include semantically similar phrases such as "upload log", "report fault log", and "collect diagnostic data" to improve the recognition rate. When the user speaks the trigger command, the voice module set up in the vehicle will perform semantic analysis on the speech and match the key command fields in real time with the preset keyword library until a voice command that matches the preset keyword is captured.

[0025] Step S102: Determine whether the current communication status of the vehicle is normal. If yes, proceed to step S103; otherwise, proceed to step S104.

[0026] Specifically, after successfully capturing a voice command that matches a preset keyword, in order to ensure the continuity of the log collection process, it is necessary to determine whether the vehicle's current communication status is normal, specifically checking whether each domain controller on the vehicle can establish a stable connection with the Internet and whether it can access the specified cloud service.

[0027] Step S103: Determine whether the triggering condition of the voice command is valid. If yes, confirm that the voice command includes the preset keyword. If no, terminate and discard the current voice command.

[0028] Specifically, when communication is normal, the main control process of the vehicle's cockpit domain sends voice commands to the cloud log collection service module. Upon receiving the request, the cloud log collection service module performs a validity check on the voice command triggering conditions. The validity check verifies whether the vehicle has already successfully executed the voice-triggered log collection process within a certain time period. If it has already been triggered, the current log collection request is considered invalid, and the cloud will return a rejection command to the vehicle, terminating and discarding the voice command. This avoids duplicate uploads and saves bandwidth and storage space. The validity check prevents excessive triggering that could lead to multiple log uploads from the vehicle, avoiding excessive waste of cloud bandwidth. If the validity check passes, the cloud will create a vehicle log collection task based on the voice command and then distribute the task to the vehicle.

[0029] Step S104: After caching the voice command, determine again whether the vehicle's current communication status is normal.

[0030] Specifically, when the current network is unavailable (i.e., weak or no network), the vehicle-mounted device will cache data such as collection tasks, log files, and status, and then determine whether the vehicle's current communication status has returned to normal. Once the network is detected to be available again, the previously saved voice commands are immediately read from the cache, and step S102 is re-executed to attempt to send the voice commands to the cloud.

[0031] In this embodiment of the application, in order to ensure the security of the command interaction process between the cloud and the vehicle, a two-way authentication and encrypted transmission mechanism based on Public Key Infrastructure (PKI) is adopted. Both the cloud and the vehicle hold digital certificates, and an encrypted channel is established only after authentication is passed. The use of session keys to encrypt data transmission effectively prevents data leakage and identity spoofing, and establishes a reliable communication link.

[0032] Step S2: Based on the pre-configured mapping relationship between domain controllers and applications, decompose the vehicle log collection task into sub-collection tasks corresponding to each domain controller.

[0033] Specifically, in this embodiment of the application, step S2 includes the following steps: Step S201: Establish communication links between the master control process of the vehicle-mounted cockpit domain and the slave control processes of each domain controller.

[0034] Figure 2 For the architecture diagram of the vehicle terminal and cloud provided in the embodiments of this application, please refer to... Figure 2A master control process runs on the cockpit domain controller, and a slave control process runs on each domain controller in the vehicle that needs to collect logs. After the vehicle starts, the slave control processes on each domain controller establish a communication link with the cockpit domain master control process based on the TCP protocol (Transmission Control Protocol). The transmission control protocol establishes a connection through a three-way handshake, uses an acknowledgment mechanism to ensure reliable data reception, and implements flow control through a sliding window mechanism, thereby achieving secure transmission of data within the vehicle.

[0035] Step S202: The master process receives the log collection task. The log collection task includes a two-dimensional task descriptor composed of the identifiers of each domain controller and the identifiers of the applications to be collected in each domain controller.

[0036] Specifically, each domain controller identifier specifies the list of domain controllers from which logs need to be collected, and the application identifier within each domain controller specifies which applications' logs need to be collected for each of the aforementioned domain controllers. Since a vehicle may contain multiple domain controllers, and each domain controller may run multiple applications, the accuracy of the log collection targets can be ensured through the setting of two-dimensional task descriptors.

[0037] Step S203: The main control process decomposes the vehicle log collection task into sub-collection tasks corresponding to each domain controller based on the two-dimensional task descriptor and the pre-configured mapping relationship between the domain controller and the application.

[0038] Specifically, the master control process stores or has access to a pre-configured mapping table. This mapping table contains metadata such as which domain controllers are available in the vehicle, which critical applications are running on each domain controller and need to be monitored, the storage path of these applications' logs on the domain controllers, and the collection method. The master control process compares and associates the two-dimensional task descriptors issued from the cloud with the locally pre-configured mapping table. For example, if the two-dimensional task descriptor requires the collection of logs from the S32G domain controller and the TBOK domain controller, the master control process will find the corresponding execution parameters for collecting logs from the S32G domain controller and the TBOK domain controller based on the mapping table. The master control process decomposes a single vehicle-wide task into a set of independent, target-specific sub-collection tasks. Each sub-collection task contains a clear target domain controller address, a list of applications to be collected, and specific collection parameters. Through this decomposition, the master control process can effectively manage log collection activities across the entire vehicle, ensuring that the collected log data is both comprehensive and targeted, providing support for subsequent data analysis and problem diagnosis.

[0039] In another embodiment of this application, step S2 includes the following steps: Step S211: Establish a communication link between the master control process in the vehicle-mounted cockpit domain and the slave control processes of each domain controller.

[0040] Step S212: Generate a log collection task based on the pre-configured collection scope information. The collection scope information includes the target domain controllers to be collected and the target applications on each target domain controller.

[0041] Specifically, in the case of partial log collection, the cloud log collection service module receives a voice trigger command from the vehicle terminal. At this time, the cloud service does not directly issue the default whole vehicle log collection command, but queries the collection range pre-configured in the cloud database based on the identifier of the triggering vehicle.

[0042] The data collection scope is pre-defined by operations or product personnel via a web page, specifying the list of target domain controllers to be collected in the case of partial log collection, as well as the list of target applications to be collected on each target domain controller. In the case of partial log collection, after receiving a voice command, the cloud generates a log collection task based on the pre-configured collection scope information and sends the log collection task to the main control process on the vehicle.

[0043] Step S213: The master process extracts a two-dimensional task descriptor composed of the target domain controller identifier and the target application identifier to be collected in each target domain controller.

[0044] Step S214: The master control process generates multiple sub-acquisition tasks for each target domain controller based on the two-dimensional task descriptor and the pre-configured mapping relationship between the domain controller and the application.

[0045] During the process of triggering vehicle log collection by voice command, it can be configured to collect vehicle logs by default. However, for troubleshooting a certain type of high-frequency fault, maintenance personnel can quickly narrow the collection scope to a few key domain controllers and applications through the web page, thereby significantly reducing the amount of log data uploaded and saving vehicle cloud traffic and cloud storage space.

[0046] Step S3: Distribute sub-collection tasks to each domain controller to collect and upload domain controller logs.

[0047] Specifically, in this embodiment of the application, step S3 includes the following steps: Step S31: The master process distributes the generated sub-acquisition tasks to the slave processes on the corresponding domain controllers through the communication link.

[0048] Specifically, the master control process distributes the generated sub-collection tasks in parallel to the slave control processes on the corresponding domain controllers through the TCP communication link established in step S201. The master control process itself also acts as an execution node, initiating log collection for its own domain (cockpit domain) while distributing tasks.

[0049] Step S32: Retrieve and compress logs generated by the applications to be collected within a preset time period from the control process.

[0050] Specifically, after receiving a sub-collection task, the slave processes of each domain controller retrieve and collect logs generated within a preset time period based on the application identifier in the instruction. The preset time period can be the past 24 hours. By setting the preset time period, the determinism of the log time window can be ensured, providing end-to-end, full-coverage log information, effectively avoiding the loss of logs at critical time points, and providing a complete data chain for troubleshooting. To improve transmission efficiency, the slave processes compress and package the collected log data to generate compressed files.

[0051] In this embodiment, to ensure that the log collection task is not interrupted due to vehicle power failure, the on-board unit automatically requests the vehicle controller to maintain a high-voltage state when the collection task begins. This keeps the vehicle's power system powered throughout the entire log collection process, completely unnoticed even when the user leaves or locks the vehicle. After the task is completed, it automatically requests to de-energize, restoring the vehicle to normal operation. Users do not need to change their driving habits; leaving or locking the vehicle does not affect the automatic maintenance of high-voltage levels. By triggering vehicle log collection via voice commands, users can complete the log collection process anytime, anywhere, without needing to drive to a 4S shop.

[0052] Step S33: The slave process returns the acquisition status and the acquired logs to the master process.

[0053] Specifically, during the data acquisition process, each slave control process returns the acquisition status and the final collected log compressed package to the cockpit domain's file transfer module via a file transfer link using the FTP (File Transfer Protocol) protocol. The file transfer module then aggregates the log files from different domain controllers and sends them to the master control process. The acquisition status can include whether the task has been issued to the vehicle terminal, whether the vehicle terminal has received the acquisition command, the task execution progress, and the task completion status. The master control process synchronizes the acquisition status to the cloud via the MQTT (Message Queuing Telemetry Transport) protocol, and the cloud displays the task execution status in real time on a web page.

[0054] The collected logs can include maintenance logs and business logs. Maintenance logs accumulate the health status and performance of vehicles for vehicle diagnosis and maintenance, while business logs record vehicle usage and user behavior for business analysis and user experience improvement.

[0055] Step S34: When the acquisition status shows that acquisition is complete, the main control process uploads the acquired logs.

[0056] Specifically, in this embodiment of the application, the main control process uploading the collected logs in step S34 includes: Step S341: Divide the collected logs into shards according to the sharding algorithm; Step S342: Upload each fragment in parallel using the Hypertext Transfer Security Protocol; Step S343: Monitor the upload status of each fragment and check if a successful response has been received. If yes, proceed to step S344; otherwise, proceed to step S345.

[0057] Step S344: If yes, continue uploading the fragments until all fragments have been uploaded; Step S345: If not, retransmit the fragment for which no response has been received individually. If no response is received after retransmission, return the fragment to the local mapping buffer for temporary storage until the network is restored and the incomplete fragment is automatically resumed from the breakpoint until all fragments are uploaded.

[0058] Once the main control process confirms that all subtasks have completed data collection, it begins to perform a unified upload. All upload operations are performed using the HTTPS protocol (Hypertext Transfer Protocol Secure), ensuring the security of the transport layer.

[0059] The main control process will divide the large log compressed package into multiple smaller fragments according to the fragmentation algorithm. The main control process will upload these fragments in parallel and monitor the upload status of each fragment. For fragments that fail to upload, the system will retransmit them separately. If the failure is caused by network anomalies, the fragment will be returned to the local mapping buffer for temporary storage until the network is restored and the incomplete fragments will be automatically resumed from the breakpoint.

[0060] This application embodiment reduces the burden of large file uploads by segmenting them into chunks, and the breakpoint resume mechanism effectively addresses the challenges of unstable network environments, significantly improving the success rate of uploading large log files. Simultaneously, HTTPS-based transmission, combined with PKI two-way authentication, forms a secure communication link from the vehicle to the cloud, preventing data from being stolen or tampered with during transmission.

[0061] In this embodiment of the application, after the main control process uploads the collected logs when the collection status shows that the collection is complete in step S34, the following steps are included: Step S41: Trigger the generation and uploading of fault work orders based on the collected logs.

[0062] Figure 3 A fault handling flowchart provided for an embodiment of this application. See also... Figure 3 Once the cloud confirms that all vehicle log files have been uploaded to the cloud storage module, the work order creation process is automatically triggered. After the entire data collection task is complete, the relevant after-sales or maintenance personnel will be automatically notified via email. Upon receiving the notification, the maintenance personnel will combine the initial fault description provided by the 4S after-sales personnel with the complete logs just uploaded to the cloud to create a formal fault work order in the maintenance system. The work order system can automatically assign the fault work order to the corresponding technical engineer for analysis and location based on the faulty module, application identifier, or manual specification.

[0063] Furthermore, log files uploaded to the cloud are uniformly stored in the cloud storage module with a fixed storage period of two months. A manual early deletion mechanism is also supported. This effectively avoids the unlimited growth of cloud storage space, thereby significantly reducing storage costs. On the other hand, the two-month storage window provides sufficient time for after-sales, operation and maintenance, and technical personnel to analyze, locate, and reproduce problems, ensuring the availability of log data during critical periods.

[0064] Step S42: Track the processing progress of fault work orders in real time.

[0065] Specifically, when a technical engineer receives a work order, they begin analyzing and locating the root cause of the problem based on the provided logs. The technical engineer needs to update the processing status in the work order system in real time, and the processing status can include "Analyzing," "Problem Located," "Repairing," "Pending Verification," and "Completed."

[0066] Step S43: After the fault work order is processed, output the processing result notification of the fault work order.

[0067] Specifically, once the engineer marks the work order status as "completed," a closed-loop notification mechanism is activated. The processing result of the work order is automatically notified to the vehicle user who initially reported the problem via email, app push, or SMS, informing them that the issue has been resolved.

[0068] Based on a vehicle log upload solution triggered by cockpit voice commands, this application embodiment constructs a complete closed-loop business process for vehicle-cloud collaborative fault handling. When a user encounters a functional malfunction during vehicle use, they can contact after-sales personnel immediately. After understanding the malfunction, the after-sales personnel remotely guide the user to trigger the vehicle log upload via voice commands on the vehicle side. Subsequently, the after-sales personnel record the malfunction reported by the user and notify the maintenance personnel that the log has been successfully triggered and uploaded to the cloud. After receiving the notification that the log upload is complete, the maintenance or technical personnel create a corresponding fault work order in the system based on the problem description provided by after-sales and the log data already stored in the cloud, and assign it to the appropriate technical engineer. The technical engineer conducts problem analysis and localization based on the logs and updates the processing progress in the work order system in real time. Once the problem is resolved, the work order is marked as completed, and the system automatically feeds back the processing result to the user, thereby realizing a fully online and traceable closed-loop management process from problem reporting to resolution notification.

[0069] This application embodiment triggers log collection by real-time monitoring of cockpit voice commands and recognizing preset keywords, enabling users to directly participate in the fault reporting process. This ensures timely log uploads, preventing log loss due to cyclic overwriting and reducing cloud storage load caused by invalid log uploads, thus lowering maintenance costs. Simultaneously, this embodiment's collection task covers logs generated by all domain controllers in the vehicle within a preset time period, ensuring log data integrity and full-link coverage. The pre-configured mapping between domain controllers and applications ensures the correlation of relevant log data, facilitating subsequent troubleshooting and analysis. Furthermore, from user voice triggering to automatic log upload, cloud work order creation, engineer analysis and status updates, and finally, feedback to the user, this embodiment breaks down business workflow boundaries, building a seamless collaborative operation and maintenance ecosystem. Based on real-time uploaded complete logs, technicians can quickly and accurately locate problems, avoiding information distortion and delays in traditional communication. Combined with automated work order flow and status tracking, this significantly shortens the overall cycle from fault occurrence to resolution.

[0070] Secondly, embodiments of this application also provide a vehicle log uploading device based on voice commands.

[0071] In one embodiment, reference is made to Figure 4 , Figure 4 This is a functional module diagram of an embodiment of the vehicle log upload device based on voice commands according to this application. Figure 4 As shown, the vehicle log upload device based on voice commands includes: The in-vehicle voice module is used to monitor voice commands in the cabin in real time and to perform log collection tasks when the voice command includes preset keywords. The decomposition module is used to decompose the vehicle log collection task into sub-collection tasks corresponding to each domain controller based on the pre-configured mapping relationship between the domain controller and the application. The data collection module is used to distribute sub-collection tasks to each domain controller for collecting and uploading domain controller logs.

[0072] The functions of each module in the above-mentioned vehicle log upload device based on voice commands correspond to the steps in the above-mentioned vehicle log upload method embodiment based on voice commands, and their functions and implementation processes will not be described in detail here.

[0073] Thirdly, embodiments of this application provide a vehicle log upload device based on voice commands. The vehicle log upload device based on voice commands includes a processor, a memory, and a vehicle log upload program based on voice commands stored in the memory and executable by the processor. When the vehicle log upload program based on voice commands is executed by the processor, it implements the steps of the vehicle log upload method based on voice commands as described in any of the above embodiments.

[0074] This application provides a vehicle log upload device based on voice commands. The vehicle log upload device based on voice commands can be a personal computer (PC), a laptop computer, a server, or other device with data processing capabilities.

[0075] Reference Figure 5 , Figure 5 This is a schematic diagram of the hardware structure of a vehicle log upload device based on voice commands, as described in an embodiment of this application. In this embodiment, the vehicle log upload device based on voice commands may include a processor, a memory, a communication interface, and a communication bus.

[0076] The communication bus can be of any type and is used to interconnect the processor, memory, and communication interface.

[0077] The communication interface includes input / output (I / O) interfaces, physical interfaces, and logical interfaces used for interconnecting internal components of the voice-command-based vehicle log upload device, as well as interfaces used for interconnecting the voice-command-based vehicle log upload device with other devices (such as other computing devices or user equipment). Physical interfaces can be Ethernet interfaces, fiber optic interfaces, ATM interfaces, etc.; user equipment can be displays, keyboards, etc.

[0078] Memory can be various types of storage media, such as random access memory (RAM), read-only memory (ROM), non-volatile RAM (NVRAM), flash memory, optical storage, hard disk, programmable ROM (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), etc.

[0079] The processor can be a general-purpose processor, which can call the vehicle log upload program based on voice commands stored in the memory and execute the vehicle log upload method based on voice commands provided in the embodiments of this application. For example, the general-purpose processor can be a central processing unit (CPU). The method executed when the vehicle log upload program based on voice commands is called can be referred to the various embodiments of the vehicle log upload method based on voice commands in this application, and will not be repeated here.

[0080] Those skilled in the art will understand that Figure 5 The hardware structure shown does not constitute a limitation of this application and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0081] Fourthly, embodiments of this application provide a computer-readable storage medium storing a vehicle log upload program based on voice commands, wherein when the vehicle log upload program based on voice commands is executed by a processor, it implements the steps of the vehicle log upload method based on voice commands as described in any of the above embodiments.

[0082] The present application provides a computer-readable storage medium storing a vehicle log upload program based on voice commands, wherein when the vehicle log upload program based on voice commands is executed by a processor, it implements the steps of the vehicle log upload method based on voice commands as described above.

[0083] The method implemented when the vehicle log upload program based on voice commands is executed can be referred to in the various embodiments of the vehicle log upload method based on voice commands in this application, and will not be repeated here.

[0084] It should be noted that the sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0085] The terms "comprising" and "having," and any variations thereof, in the specification, claims, and accompanying drawings of this application are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to such process, method, product, or apparatus. The terms "first," "second," and "third," etc., are used to distinguish different objects, etc., and do not indicate a sequence, nor do they limit "first," "second," and "third" to different types.

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

[0087] In the description of the embodiments of this application, unless otherwise stated, " / " means "or". For example, A / B can mean A or B. The "and / or" in the text is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist simultaneously, and B exists alone. In addition, in the description of the embodiments of this application, "multiple" means two or more.

[0088] In some processes described in the embodiments of this application, multiple operations or steps are included in a specific order. However, it should be understood that these operations or steps may not be executed in the order they appear in the embodiments of this application, or they may be executed in parallel. The sequence number of the operation is only used to distinguish different operations, and the sequence number itself does not represent any execution order. In addition, these processes may include more or fewer operations, and these operations or steps may be executed sequentially or in parallel, and these operations or steps may be combined.

[0089] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) as described above, and includes several instructions to cause a terminal device to execute the methods described in the various embodiments of this application.

[0090] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A method for uploading vehicle logs based on voice commands, characterized in that, The method for uploading vehicle logs based on voice commands includes: The system monitors voice commands in the cockpit in real time and executes a log collection task when the voice command includes preset keywords. Based on the pre-configured mapping relationship between domain controllers and applications, the vehicle log collection task is decomposed into sub-collection tasks corresponding to each domain controller. Distribute sub-collection tasks to each domain controller to collect and upload domain controller logs.

2. The method for uploading vehicle logs based on voice commands according to claim 1, characterized in that, Following the voice commands received in the real-time monitoring cockpit, the following are included: The fields contained in the voice command are matched with preset keywords until a voice command that matches the preset keywords is captured. Determine if the vehicle's current communication status is normal; If yes, then determine whether the triggering condition of the voice command is valid. If yes, then confirm that the voice command includes the preset keyword. If not, then terminate and discard the current voice command. If not, after caching the voice command, check again whether the vehicle's current communication status is normal.

3. The method for uploading vehicle logs based on voice commands according to claim 1, characterized in that, The process of decomposing the vehicle log collection task into sub-collection tasks corresponding to each domain controller, based on the pre-configured mapping relationship between domain controllers and applications, includes: Establish communication links between the master control process of the vehicle-mounted cockpit domain and the slave control processes of each domain controller; The master control process receives log collection tasks, and the log collection tasks include a two-dimensional task descriptor composed of the identifiers of each domain controller and the identifiers of the applications to be collected in each domain controller. The main control process decomposes the vehicle log collection task into sub-collection tasks corresponding to each domain controller based on the two-dimensional task descriptor and the pre-configured mapping relationship between domain controllers and applications.

4. The method for uploading vehicle logs based on voice commands according to claim 3, characterized in that, The process of distributing sub-collection tasks to each domain controller for collecting and uploading domain controller logs includes: The master control process distributes the generated multiple sub-acquisition tasks to the slave control processes on the corresponding domain controllers through a communication link. The slave control process retrieves and compresses logs generated by the applications to be collected in this domain within a preset time period; The slave process returns the collection status and collected logs to the master process; When the data collection status indicates that data collection is complete, the main control process uploads the collected logs.

5. The method for uploading vehicle logs based on voice commands according to claim 4, characterized in that, The logs uploaded and collected by the main control process include: The collected logs are divided into fragments according to the fragmentation algorithm; The fragments are uploaded in parallel using the Hypertext Transfer Security Protocol. Monitor the upload status of each fragment and check whether a successful response has been received; If so, continue uploading the fragments until all fragments have been uploaded; If not, the fragment for which no response was received will be retransmitted individually. If no response is received after retransmission, the fragment will be returned to the local mapping buffer for temporary storage until the network is restored and the incomplete fragment will be automatically resumed from the breakpoint until all fragments are uploaded.

6. The method for uploading vehicle logs based on voice commands according to claim 4, characterized in that, When the data collection status indicates that data collection is complete, after the main control process uploads the collected logs, it includes: The generation and uploading of fault work orders are triggered based on the collected logs; Track the processing progress of the fault work orders in real time; After the fault work order is processed, a notification of the processing result of the fault work order is output.

7. The method for uploading vehicle logs based on voice commands according to claim 1, characterized in that, The process of decomposing the vehicle log collection task into sub-collection tasks corresponding to each domain controller, based on the pre-configured mapping relationship between domain controllers and applications, includes: A communication link is established between the master control process in the vehicle-mounted cockpit domain and the slave control processes of each domain controller; The log collection task is generated based on the pre-configured collection scope information, which includes the target domain controllers to be collected and the target applications on each target domain controller. The master control process extracts a two-dimensional task descriptor composed of the target domain controller identifier and the target application identifier to be collected in each target domain controller; The master control process generates multiple sub-acquisition tasks for each target domain controller based on the two-dimensional task descriptor and the pre-configured mapping relationship between domain controllers and applications.

8. A vehicle log upload device based on voice commands, characterized in that, The vehicle log upload device based on voice commands includes: The vehicle-mounted voice module is used to monitor voice commands in the cabin in real time, and to perform log collection tasks when the voice command includes preset keywords. The decomposition module is used to decompose the vehicle log collection task into sub-collection tasks corresponding to each domain controller based on the pre-configured mapping relationship between the domain controller and the application. The data collection module is used to distribute sub-collection tasks to each domain controller for collecting and uploading domain controller logs.

9. A vehicle log upload device based on voice commands, characterized in that, The vehicle log upload device based on voice commands includes a processor, a memory, and a vehicle log upload program based on voice commands stored in the memory and executable by the processor. When the vehicle log upload program based on voice commands is executed by the processor, it implements the steps of the vehicle log upload method based on voice commands 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 a vehicle log upload program based on voice commands, wherein when the vehicle log upload program based on voice commands is executed by a processor, it implements the steps of the vehicle log upload method based on voice commands as described in any one of claims 1 to 7.

Images