Vehicle cloud strategy execution method and device, vehicle machine end, server end and vehicle

Abstract

The application relates to a vehicle-cloud strategy execution method and device, a vehicle-machine terminal, a server and a vehicle. The method comprises the following steps: sending vehicle-machine running data to a server, wherein the vehicle-machine running data comprises driving state data and abnormal feature data; receiving vehicle-end execution budget data returned by the server according to the driving state data and vehicle-end execution fragments returned according to the abnormal feature data, wherein the vehicle-end execution budget data comprises actual budget data and residual budget data; determining elastic resource configuration data according to the proportion of the residual budget data and the actual budget data; allocating execution resources of the vehicle-machine terminal according to the elastic resource configuration data, and executing the vehicle-end execution fragments according to the execution resources. The method can be applied to complex and highly flexible dynamic scenes, and can reduce network load and resource occupation of the vehicle-machine terminal.

Description

Technical Field

[0001] This application relates to the field of vehicle-cloud collaborative operation and maintenance technology, and in particular to a vehicle-cloud strategy execution method, device, vehicle terminal, server, and vehicle. Background Technology

[0002] Traditional vehicle-service platform operations and maintenance rely on manually preset rules, triggering alarms or restarts through simple thresholds. These manually preset static rules are difficult to apply to complex, dynamic scenarios with high flexibility requirements, resulting in a high rate of policy mis-triggering.

[0003] The generation and execution of policies rely entirely on the server. The vehicle terminal acts as a data collection terminal, and the server sends complete policy instructions to the vehicle terminal, resulting in high network load and high resource consumption of the vehicle terminal. Summary of the Invention

[0004] Therefore, it is necessary to provide a vehicle-cloud strategy execution method, device, vehicle terminal, server, and vehicle that can be applied to complex and highly flexible dynamic scenarios and reduce network load and vehicle terminal resource consumption in order to address the above-mentioned technical problems.

[0005] Firstly, this application provides a vehicle-to-cloud strategy execution method, applied to an in-vehicle infotainment system, the method comprising:

[0006] The vehicle system operation data is sent to the server, and the vehicle system operation data includes driving status data and abnormal feature data;

[0007] The receiving server returns vehicle-side execution budget data based on the driving status data and vehicle-side execution shards based on the abnormal feature data. The vehicle-side execution budget data includes actual budget data and remaining budget data.

[0008] The flexible resource allocation data is determined based on the ratio of the remaining budget data to the actual budget data.

[0009] The vehicle-mounted system allocates execution resources based on the elastic resource allocation data, and executes the vehicle-mounted execution fragments based on the execution resources.

[0010] In some embodiments of the method, sending the vehicle system operation data to the server includes:

[0011] Determine the corresponding data acquisition strategy based on the current driving status data, and determine abnormal feature data based on the data acquisition strategy;

[0012] The abnormal feature data is transmitted to the server according to the first network adaptive transmission strategy corresponding to the current network quality. The first network adaptive transmission strategy represents the transmission of abnormal feature data with different degrees of completeness for different network qualities.

[0013] In some embodiments of the method, transmitting the abnormal feature data to the server according to a first network adaptive transmission strategy corresponding to the current network quality includes:

[0014] Extract abnormal feature codes from the abnormal feature data and perform hash operations to determine the corresponding data blocks;

[0015] If the current network quality is greater than the first network signal strength, transmit all data blocks corresponding to the abnormal feature data and the abnormal feature code completely.

[0016] When the current network quality is greater than the second network signal strength but less than the first network signal strength, the change data block and the abnormal feature code corresponding to the abnormal feature data of the server are transmitted and compared.

[0017] The abnormal signature code is transmitted when the current network quality is lower than the signal strength of the second network.

[0018] In some embodiments of the method, the step of allocating vehicle-mounted execution resources according to elastic resource configuration data and executing the vehicle-mounted execution shards according to the execution resources includes:

[0019] If the ratio of the remaining budget data to the actual budget data is greater than a first remaining ratio threshold and the current execution resources exceed a first resource threshold, the current execution resources are expanded according to the elastic resource configuration data, and the vehicle-side execution shards are executed based on the expanded execution resources.

[0020] In some embodiments of the method, the method further includes:

[0021] If the execution of the vehicle-side execution segment fails, roll back the already executed vehicle-side execution segment;

[0022] Generate the execution result and send the execution result to the server.

[0023] According to a second aspect of the present disclosure, a vehicle-to-cloud policy execution method is provided, applied to a server, the method comprising:

[0024] Receive vehicle operation data sent by the vehicle terminal, the vehicle operation data including driving status data and abnormal feature data;

[0025] The vehicle-side execution budget data is determined based on the driving status data.

[0026] Based on the abnormal feature data and the remaining budget matching model, multiple policy fragments to be executed are determined, including vehicle-side execution fragments and server-side execution fragments.

[0027] The vehicle-side execution budget data and the vehicle-side execution fragments are sent to the vehicle-mounted terminal. The vehicle-side execution budget data includes actual budget data and remaining budget data. The actual budget data and the remaining budget data are used by the vehicle-mounted terminal to determine elastic resource allocation data based on the ratio of the remaining budget data to the actual budget data. The elastic resource allocation data is used by the vehicle-mounted terminal to allocate execution resources based on the elastic resource allocation data and to execute the vehicle-side execution fragments based on the execution resources.

[0028] The server-side sharding is executed.

[0029] In some embodiments of the method, the vehicle-side execution budget data further includes basic budget data, and determining the vehicle-side execution budget data based on the driving status data includes:

[0030] The basic budget data is determined based on the driving status data;

[0031] The basic budget data is dynamically adjusted based on the service level target achievement rate and network signal strength to determine the actual budget data;

[0032] The deduction data is determined based on the historical execution time of the vehicle-side segment, and the remaining budget data is determined based on the deduction data and the actual budget data.

[0033] In some embodiments of the method, the remaining budget matching model is used to store the mapping relationship between at least two of the anomaly feature data, the ratio of the remaining budget data to the actual budget data, and the names of the strategies to be executed. The step of determining multiple strategy shards to be executed based on the anomaly feature data and the remaining budget matching model includes:

[0034] Based on the abnormal feature data and the ratio of the remaining budget data to the actual budget data, the corresponding strategy name to be executed is determined through the mapping relationship stored in the remaining budget matching model;

[0035] Multiple policy fragments to be executed are determined based on the names of the policies to be executed.

[0036] In some embodiments of the method, the method further includes:

[0037] Upon receiving the execution result returned by the vehicle terminal, the improvement rate of the service level target achievement rate is determined based on the service level target achievement rate after the execution of the strategy to be executed and the service level target achievement rate before the execution of the strategy to be executed. The resource consumption deviation rate is determined based on the actual value and expected value of resource consumption of the vehicle terminal and / or the server.

[0038] If the improvement rate of the service level target achievement rate is less than the first improvement rate threshold and / or the resource consumption deviation rate is greater than the first deviation rate threshold for a preset number of times, the corresponding pending strategy will be sent to the pending review area.

[0039] According to a third aspect of the present disclosure, a vehicle-to-cloud strategy execution device is provided, applied to a vehicle-mounted system, the device comprising:

[0040] The first communication module is used to send vehicle system operation data to the server. The vehicle system operation data includes driving status data and abnormal feature data.

[0041] The second communication module is used to receive vehicle-side execution budget data returned by the server based on the driving status data and vehicle-side execution fragments returned based on abnormal feature data. The vehicle-side execution budget data includes actual budget data and remaining budget data.

[0042] The first processing module is used to determine elastic resource allocation data based on the ratio of the remaining budget data to the actual budget data; it is also used to allocate execution resources on the vehicle terminal based on the elastic resource allocation data, and execute the vehicle terminal execution shards based on the execution resources.

[0043] According to a fourth aspect of the present disclosure, a vehicle-cloud strategy execution device is provided, applied to a server, the device comprising:

[0044] The third communication module is used to receive vehicle operation data sent by the vehicle terminal, the vehicle operation data including driving status data and abnormal feature data;

[0045] The second processing module is used to determine the vehicle-side execution budget data based on the driving status data;

[0046] The third processing module is used to determine multiple policy fragments to be executed based on the abnormal feature data and the remaining budget matching model. The policy fragments to be executed include vehicle-side execution fragments and server-side execution fragments.

[0047] The fourth communication module is used to send the vehicle-side execution budget data and the vehicle-side execution fragments to the vehicle terminal. The vehicle-side execution budget data includes actual budget data and remaining budget data. The actual budget data and the remaining budget data are used by the vehicle terminal to determine elastic resource allocation data based on the ratio of the remaining budget data to the actual budget data. The elastic resource allocation data is used by the vehicle terminal to allocate execution resources based on the elastic resource allocation data and execute the vehicle-side execution fragments based on the execution resources.

[0048] The fourth processing module is used to execute the server-side sharding.

[0049] According to a fifth aspect of the present disclosure, a vehicle-mounted terminal is provided, the vehicle-mounted terminal including a memory and a processor, the memory storing a computer program, and the processor executing the computer program to perform the following steps:

[0050] The vehicle system operation data is sent to the server, and the vehicle system operation data includes driving status data and abnormal feature data;

[0051] The receiving server returns vehicle-side execution budget data based on the driving status data and vehicle-side execution shards based on the abnormal feature data. The vehicle-side execution budget data includes actual budget data and remaining budget data.

[0052] The flexible resource allocation data is determined based on the ratio of the remaining budget data to the actual budget data.

[0053] The vehicle-mounted system allocates execution resources based on the elastic resource allocation data, and executes the vehicle-mounted execution fragments based on the execution resources.

[0054] According to a sixth aspect of the present disclosure, a server is provided, the server including a memory and a processor, the memory storing a computer program, and the processor executing the computer program performing the following steps:

[0055] Receive vehicle operation data sent by the vehicle terminal, the vehicle operation data including driving status data and abnormal feature data;

[0056] The vehicle-side execution budget data is determined based on the driving status data.

[0057] Based on the abnormal feature data and the remaining budget matching model, multiple policy fragments to be executed are determined, including vehicle-side execution fragments and server-side execution fragments.

[0058] The vehicle-side execution budget data and the vehicle-side execution fragments are sent to the vehicle-mounted terminal. The vehicle-side execution budget data includes actual budget data and remaining budget data. The actual budget data and the remaining budget data are used by the vehicle-mounted terminal to determine elastic resource allocation data based on the ratio of the remaining budget data to the actual budget data. The elastic resource allocation data is used by the vehicle-mounted terminal to allocate execution resources based on the elastic resource allocation data and to execute the vehicle-side execution fragments based on the execution resources.

[0059] The server-side sharding is executed.

[0060] According to a seventh aspect of the present disclosure, a vehicle is provided, including the vehicle-mounted terminal described above.

[0061] The vehicle-cloud strategy execution scheme provided in this application can adapt to the operation and maintenance needs of different driving modes of vehicles based on the vehicle-side execution budget data dynamically returned by the driving scenario. It can better adapt to complex and highly flexible dynamic scenarios and reduce the policy false trigger rate. It can also dynamically allocate vehicle-side execution resources to execute vehicle-side execution shards based on the vehicle-side execution budget data, avoiding the situation where policy generation and execution are completely dependent on the server side. It can dynamically adjust vehicle-side execution resources, solve the problem of resource idleness or resource over-provisioning, and improve the overall resource management efficiency.

[0062] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0063] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure, and are not intended to unduly limit this disclosure.

[0064] Figure 1 This is an application environment diagram illustrating a vehicle-to-cloud strategy execution method according to an exemplary embodiment;

[0065] Figure 2 This is a flowchart illustrating a vehicle-cloud policy execution method applied to an in-vehicle infotainment system according to an exemplary embodiment.

[0066] Figure 3 This is a flowchart illustrating the data acquisition steps of a vehicle-mounted system according to an exemplary embodiment.

[0067] Figure 4 This is a flowchart illustrating a vehicle-cloud policy execution method applied to a server according to an exemplary embodiment.

[0068] Figure 5 This is a flowchart illustrating the step of determining vehicle-side execution budget data according to an exemplary embodiment;

[0069] Figure 6 This is a flowchart illustrating the step of determining the strategy fragment to be executed, according to an exemplary embodiment.

[0070] Figure 7 This is a structural block diagram of a vehicle-cloud policy execution device applied to an in-vehicle infotainment system, according to an exemplary embodiment.

[0071] Figure 8 This is a structural block diagram of a vehicle-cloud policy execution device applied to a server, according to an exemplary embodiment. Detailed Implementation

[0072] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0073] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this disclosure are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this disclosure described herein can be implemented in orders other than those illustrated or described herein. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this disclosure. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this disclosure. The terms "comprising," "including," or any other variations thereof are intended to cover a non-exclusive inclusion, such that a process, method, product, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, product, or apparatus. Without further limitation, the presence of other identical or equivalent elements in a process, method, product, or apparatus that includes said elements is not excluded. For example, the use of terms such as "first," "second," etc., is to denote names and does not indicate any specific order.

[0074] The vehicle-to-cloud strategy execution method provided in this application embodiment can be applied to, for example... Figure 1 The application environment shown is as follows. In this environment, the vehicle terminal 102 is deployed on the vehicle 100, and the vehicle terminal 102 communicates with the server 104 through the network.

[0075] The server 104 can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, a cloud server that provides network security services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, cloud security, host security and other network security services, as well as basic cloud computing services such as big data and artificial intelligence platforms, or a server containing blockchain nodes and a combination thereof.

[0076] The vehicle terminal 102 can be an in-vehicle terminal or a mobile terminal deployed on the vehicle 100. In-vehicle terminals or mobile terminals deployed on the vehicle 100 include devices with wireless signal receivers (devices that only possess wireless signal receiver capabilities without transmission capabilities) and devices with receiving and transmitting hardware capable of performing bidirectional communication over a bidirectional communication link. Such devices can include: cellular or other communication devices with single-line displays, multi-line displays, or cellular or other communication devices without multi-line displays; PCS (Personal Communications Service) systems that can combine voice, data processing, fax, and / or data communication capabilities; and PDAs (Personal Digital Assistants) that can include radio frequency receivers, pagers, internet / intranet access, web browsers, notepads, calendars, and / or GPS (Global Positioning System) receivers or other in-vehicle devices. The in-vehicle terminal or mobile terminal deployed on vehicle 100 can be portable, transportable, installed in the vehicle's infotainment system, or suitable and / or configured to operate locally, and / or in a distributed manner, operating in any other location on Earth and / or in space. It can also be a communication terminal, internet access terminal, or music / video playback terminal, such as a PDA, MID (Mobile Internet Device), and / or a mobile phone with music / video playback capabilities. Vehicle 100 as used herein may include multimedia equipment, also referred to as in-vehicle multimedia equipment, which may include in-vehicle audio, in-vehicle displays, etc.; vehicle 100 can also be a manned or unmanned intelligent connected vehicle capable of establishing a communication connection with a user or server 104 via a vehicle network.

[0077] In some embodiments provided in this disclosure, the execution of the vehicle-to-cloud strategy execution method can be controlled by a unified controller or by multiple controllers. These controllers may include the controller of the vehicle-mounted terminal 102 or the controller of the server-side 104, such as the controller in a server that can communicate with the vehicle-mounted terminal 102. In some embodiments, the controller of the vehicle-mounted terminal 102 and the controller of the server-side 104 may jointly assist in completing the vehicle-to-cloud strategy execution method. The controllers described in this disclosure may include various control units capable of implementing logic processing functions, including but not limited to CPU (Central Processing Unit), PLC (Programmable Logic Controller), ECU (Electronic Control Unit), MCU (Microcontroller Unit), FPGA (Field Programmable Gate Array), and CPLD (Complex Programmable Logic Device), as well as controllers composed of one or more logic function units, chips, etc.

[0078] In some embodiments of this disclosure, a vehicle-to-cloud strategy execution method is provided, such as... Figure 2 As shown, this method is applied to Figure 1 Taking the vehicle-mounted terminal 102 as an example, the explanation includes the following steps:

[0079] S120. Send the vehicle system operation data to the server. The vehicle system operation data includes driving status data and abnormal feature data.

[0080] In some embodiments of this disclosure, vehicle system operation data typically refers to operational indicator information describing the operating status of the vehicle system. Vehicle system operation data can be obtained by collecting operational indicators of the vehicle's cockpit software through a perception module deployed on the vehicle system. Operational indicators may include process resource indicators and user experience indicators. Process resource indicators may include CPU utilization, memory utilization, memory bandwidth, I / O (Input / Output) read bandwidth, I / O write bandwidth, network transmission bandwidth, and network reception bandwidth, etc. User experience indicators may include language response latency and navigation rendering frame rate, etc. Vehicle system operation data may include driving status data and abnormal feature data. Driving status data typically refers to driving status information describing the vehicle system's operation. Driving status data may include the vehicle's driving mode. Driving mode may include the current driving model on the vehicle system, historical driving modes on the vehicle system, and preparatory or predicted driving modes waiting to be started, executed, or switched on the vehicle system. Driving modes may include autonomous driving mode, parking mode, automatic parking mode, cruise control mode, towing mode, and charging mode, etc. Abnormal feature data typically refers to abnormal events or abnormal information describing the vehicle system. In some examples, anomalous characteristic data may include CPU overload, high latency, etc.

[0081] In some examples, kernel-level tracing techniques can be used as a sensing module to collect data on target processes on the vehicle's infotainment system. This allows for the collection of process resource metrics, such as CPU and memory usage. Kernel-level tracing techniques can include the Extended Berkeley Packet Filter (eBPF). eBPF is a high-performance, secure technology for network filtering and monitoring. eBPF allows programs to run in kernel space, enabling efficient monitoring of network, storage, and system calls. eBPF is a virtual machine that runs within the Linux kernel with highly restricted access permissions, ensuring kernel security. Through eBPF, programs can be dynamically loaded and executed into the Linux kernel without modifying the kernel source code.

[0082] In other examples, the wake-up events of the voice service can be intercepted by the input / output control system (such as hardware button or voice command triggers). The total time from the issuance of the wake-up command to the completion of the voice feedback can be recorded with millisecond accuracy. The buffer exchange function call interval can be based on the open graphics library embedded system interface, and the number of frames rendered per second can be calculated. If the rendering time of a single frame exceeds 16 milliseconds (corresponding to a standard of 60 frames per second), it can be recorded as a frame drop event.

[0083] S140. Receive vehicle-side execution budget data returned by the server based on the driving status data, and vehicle-side execution shards returned based on the abnormal feature data. The vehicle-side execution budget data includes actual budget data and remaining budget data.

[0084] In some embodiments of this disclosure, vehicle-side execution budget data typically refers to the budget information bound to the vehicle-to-everything (V2X) strategy by the vehicle's infotainment system based on driving status data. The server can bind different vehicle-side execution budgets to different driving modes on the vehicle's infotainment system. In some examples, when the vehicle's infotainment system is in autonomous driving mode, a high-safety budget can be bound, with a corresponding base budget set to 5 minutes / month; when the vehicle's infotainment system is in parking mode, a high-tolerance budget can be bound, with a corresponding base budget set to 30 minutes / month. Vehicle-side execution sharding typically refers to the strategy sharding of the V2X strategy executed on the vehicle's infotainment system. Vehicle-side execution sharding can refer to independent sub-strategies, i.e., strategy shards, where the server splits a complete V2X strategy. Vehicle-side execution shards can be lightweight sub-tasks split from the V2X strategy, i.e., task shards; or lightweight data shards split during V2X transmission. Regardless of whether it's policy-based fragmentation, task-based fragmentation, or data fragmentation, vehicle-side execution fragmentation can be executed locally on the vehicle's infotainment system. It can also achieve independent transmission between the vehicle's infotainment system and the server, thus avoiding complete reliance on the server for policy generation and distribution, reducing network transmission pressure. In some examples, the server can determine vehicle-side execution fragments based on anomaly characteristic data and transmit these fragments to the vehicle's infotainment system for execution. In other examples, the server can determine both vehicle-side and server-side execution fragments based on anomaly characteristic data, where vehicle-side execution fragments are transmitted to the vehicle's infotainment system for execution, while server-side execution fragments are executed directly on the server.

[0085] S160. Determine the flexible resource allocation data based on the ratio of the remaining budget data to the actual budget data.

[0086] In some embodiments of this disclosure, the actual budget data typically refers to the real budget of the vehicle terminal under the current driving mode as determined by the server. The remaining budget data typically refers to the budget remaining after deducting the historical vehicle terminal execution fragments that have already been executed under the current driving mode. The current remaining budget situation can be determined based on the ratio of the remaining budget data to the actual budget data, for example, to determine whether the current remaining budget is sufficient. In some examples, when the vehicle terminal execution budget is sufficient (e.g., the remaining budget of the vehicle terminal accounts for more than 50%), additional execution resources can be allocated to perform additional operations, and additional operations such as configuring voice services can be allowed. The elastic resource quota of the vehicle terminal can be determined by using the following formula (1):

[0087]

[0088] In some embodiments of this disclosure, the elastic resource quota is used to characterize the elastic resource configuration data determined above. The base value is used to characterize the initial value of the processing resources configured on the vehicle terminal. In some examples, when the remaining budget is sufficient (i.e., the ratio of the remaining budget data to the actual budget data is greater than a first remaining ratio threshold) and the current execution resources exceed a first resource threshold (e.g., CPU utilization > 80%), the current execution resources (e.g., CPU or memory) can be expanded according to the elastic resource configuration data (i.e., the elastic resource quota), and vehicle terminal execution fragmentation can be performed based on the expanded execution resources.

[0089] S180. Allocate execution resources for the vehicle terminal according to the elastic resource configuration data, and execute the vehicle terminal execution fragments according to the execution resources.

[0090] In some embodiments of this disclosure, execution resources typically refer to the processing-capable resources configured on the vehicle-mounted system. Execution resources may include CPU resources, memory resources, etc. The execution strategy corresponding to vehicle-mounted execution sharding can typically be lightweight operations, including service restart, log collection, and log cleanup. The vehicle-mounted system can dynamically allocate execution resources based on its execution budget data. In some examples, when the vehicle-mounted execution budget is sufficient (e.g., the remaining budget on the vehicle-mounted system exceeds 50%), additional execution resources can be allocated to perform additional operations, such as allocating an additional 10% of CPU resources to configure additional operations like voice services. In other examples, when the vehicle-mounted execution budget is insufficient (e.g., the remaining budget on the vehicle-mounted system is less than 20%), the vehicle-mounted system can only perform necessary operations, such as log collection, releasing non-critical resources to reduce vehicle-mounted execution budget consumption and vehicle-mounted system resource usage.

[0091] The vehicle-cloud strategy execution solution disclosed herein can receive vehicle-side execution budget data dynamically returned by the server based on driving scenarios, in order to adapt to the operation and maintenance needs of different driving modes of vehicles. It can better adapt to complex and highly flexible dynamic scenarios and reduce the policy false trigger rate. It can dynamically allocate vehicle-side execution resources to execute vehicle-side execution shards based on vehicle-side execution budget data, avoiding the situation where policy generation and execution are completely dependent on the server. It can dynamically adjust vehicle-side execution resources, solve the problem of resource idleness or resource over-provisioning, and improve the overall resource management efficiency.

[0092] In some embodiments of this disclosure, such as Figure 3 As shown, step S120 includes:

[0093] S122. Determine the corresponding data acquisition strategy based on the current driving status data, and determine abnormal feature data based on the data acquisition strategy;

[0094] S124. The abnormal feature data is transmitted to the server according to the first network adaptive transmission strategy corresponding to the current network quality. The first network adaptive transmission strategy represents the transmission of abnormal feature data with different degrees of integrity for different network qualities.

[0095] In some embodiments of this disclosure, the data acquisition strategy typically refers to a specific acquisition method formulated for obtaining the required data corresponding to the driving state. The data acquisition strategy may also differ for different driving state data (e.g., autonomous driving mode or parking mode). In some examples, when the current driving state data indicates that the vehicle's infotainment system is in autonomous driving mode, the data acquisition strategy can be configured to increase the data acquisition frequency, acquiring data at a first data acquisition frequency (e.g., acquiring at 1kHz). It can also be configured to lower the acquisition alarm threshold; when a certain resource indicator on the vehicle's infotainment system (e.g., CPU utilization or memory utilization, configured according to the actual acquisition scenario) exceeds the first alarm threshold (e.g., CPU utilization exceeding 85%), an abnormal alarm is triggered. In other examples, when the current driving state data indicates that the vehicle's infotainment system is in parking mode, the data acquisition strategy can be configured to decrease the data acquisition frequency, acquiring data at a second data acquisition frequency (e.g., acquiring at 100Hz). It can also be configured to raise the alarm threshold. When a certain resource indicator on the vehicle's infotainment system (such as CPU utilization or memory utilization, configured according to the actual data collection scenario) exceeds the second alarm threshold (e.g., CPU utilization exceeds 90%), an abnormal alarm is triggered. This means that corresponding data collection strategies are adopted for different driving modes on the vehicle's infotainment system to better meet the data collection needs of actual scenarios, rationally allocate data collection resources while satisfying different scenario requirements, and minimize false triggering.

[0096] In some embodiments of this disclosure, network quality typically refers to the strength of the wireless network signal. Network quality can be characterized by the magnitude of the Reference Signal Receiving Power (RSRP). RSRP is a key parameter representing wireless signal strength and is one of the physical layer measurement requirements; it is typically the average signal power received on all REs (resource particles) carrying the reference signal within a symbol. The unit of RSRP is dBm. The first network adaptive transmission strategy typically refers to a transmission method where the vehicle-mounted unit adaptively adjusts its transmission based on the current network quality when transmitting data to the server. The first network adaptive transmission strategy can be configured to transmit anomaly characteristic data with different levels of integrity according to different network quality conditions, adapting to the current network situation and reducing data transmission overhead.

[0097] In some embodiments of this disclosure, step S124 includes:

[0098] Extract abnormal feature codes from the abnormal feature data and perform hash operations to determine the corresponding data blocks;

[0099] If the current network quality is greater than the first network signal strength, transmit all data blocks corresponding to the abnormal feature data and the abnormal feature code completely.

[0100] When the current network quality is greater than the second network signal strength but less than the first network signal strength, the change data block and the abnormal feature code corresponding to the abnormal feature data of the server are transmitted and compared.

[0101] The abnormal signature code is transmitted when the current network quality is lower than the signal strength of the second network.

[0102] In some embodiments of this disclosure, hashing generally refers to a calculation method that computes a fixed-length output digest from any set of input data. Hashing can improve storage space utilization, increase data query efficiency, and ensure data transmission security. In some examples, the collected abnormal feature data can be divided into 1-kilobyte blocks, and abnormal feature codes can be extracted. For example, a CPU overload exception can be marked as "0xA1", and a high-latency exception can be marked as "0xB3". Then, a hash operation is performed, and a unique digest value is generated for each block of data using a secure hash algorithm with 256 bits (e.g., block 1 hash value = "3A8B1D"), forming an encrypted data block. The formed encrypted data block and the abnormal feature code can be sent to the server.

[0103] In some embodiments of this disclosure, anomaly characteristic data with varying degrees of completeness can be transmitted based on different network qualities. In some examples, when the current network quality is greater than a first network signal strength, all data blocks and anomaly signatures corresponding to the anomaly characteristic data can be transmitted completely. For example, when the current RSRP > -90dBm (i.e., when the current network quality is excellent), a full transmission mode can be used to transmit the complete data blocks and their corresponding hash sequences and anomaly signatures.

[0104] In other examples, when the current network quality is greater than the second network signal strength but less than the first network signal strength, the changed data block and abnormal signature code corresponding to the abnormal feature data of the comparison server are transmitted. For example, when -110dBm < RSRP < -90dBm (i.e., under the current network quality conditions), a differential transmission mode can be used. Only the changed data block can be transmitted. By comparing the hash sequences of the server and the vehicle-mounted device, the corresponding differences can be identified and selectively transmitted (e.g., only the updated part of data block 2 is sent).

[0105] In other examples, when the current network quality is lower than the second network signal strength, only the anomaly signature can be transmitted. For example, if RSRP < -110dBm (i.e., when the current network quality is poor), a metadata transmission mode can be used, transmitting only the anomaly signature (e.g., "0xA1+0xB3", indicating an anomaly of CPU overload and high latency). In cases of poor network quality, the vehicle-mounted system can also trigger a local pre-store strategy, performing transmission only after the network environment improves, thus improving transmission efficiency. It's important to note that endpoint values ​​such as the first and second network signal strengths can be categorized differently depending on the specific circumstances. For example, the first network signal strength (-90dBm) can be categorized as either excellent or average network quality; similarly, the second network signal strength (-110dBm) can be categorized as either average or poor network quality. The values ​​of -90dBm and -110dBm mentioned above are merely exemplary values ​​corresponding to the first network signal strength and the second network signal strength, respectively. They are for illustrative purposes only and not for actual limitation. They can be set according to specific usage scenarios.

[0106] In some embodiments of this disclosure, the transmission mechanism can be optimized through a network adaptive transmission strategy, transmitting abnormal feature data with different integrity levels according to different network qualities, flexibly adapting to network environments with different network qualities, reducing data transmission overhead; and ensuring the reliable execution of core operation and maintenance functions in weak network environments.

[0107] In some embodiments of this disclosure, step S180 includes:

[0108] If the ratio of the remaining budget data to the actual budget data is greater than a first remaining ratio threshold and the current execution resources exceed a first resource threshold, the current execution resources are expanded according to the elastic resource configuration data, and the vehicle-side execution shards are executed based on the expanded execution resources.

[0109] In some examples, the vehicle-mounted system can dynamically adjust resource allocation within its hardware capabilities (e.g., prioritizing CPU allocation for critical policy sharding tasks) to optimize the processing priority of existing resources, thereby achieving resource consolidation and capacity expansion. In other examples, the vehicle-mounted system has limited self-scaling capabilities; insufficient local resources may lead to prolonged CPU overruns. In such cases, a request can be sent to the server for resource expansion. In other implementations, the vehicle-mounted system can also send elastic resource configuration data, expansion status, and execution results to the server, allowing the server to adjust and update the sharding configuration of pending policy shards. By adjusting and updating the sharding configuration, a closed-loop feedback loop from the vehicle-mounted system to the server can be achieved, enabling vehicle-cloud collaborative optimization of policy sharding and improving vehicle-cloud collaborative operation and maintenance efficiency.

[0110] In some embodiments of this disclosure, the vehicle-mounted system can dynamically allocate resources based on the remaining budget when performing vehicle-mounted execution sharding. When the remaining budget is insufficient, only necessary operations can be performed, releasing non-critical resources to reduce vehicle-mounted execution budget consumption and vehicle-mounted system resource occupation; when the remaining budget is sufficient, elastic resource configuration data can be determined, and additional resources can be allocated based on the elastic resource configuration data to improve strategy execution efficiency, thereby improving the overall vehicle-cloud collaborative operation and maintenance efficiency.

[0111] In some embodiments of this disclosure, the method further includes:

[0112] If the execution of the vehicle-side execution segment fails, roll back the already executed vehicle-side execution segment;

[0113] Generate the execution result and send the execution result to the server.

[0114] In some embodiments of this disclosure, the execution result typically refers to the execution status of the vehicle-mounted execution segment. The execution result may include success or failure, the corresponding vehicle-mounted execution segment information (success or failure), and the corresponding execution mode (e.g., the execution mode corresponding to sufficient budget or insufficient budget). In some examples, the vehicle-mounted terminal can execute the vehicle-mounted execution segments sequentially. In the event of a vehicle-mounted execution segment failure (e.g., timeout during the execution of one or more segments), the executed operations can be rolled back. For example, if the first vehicle-mounted execution segment executes successfully but the second fails, the first vehicle-mounted execution segment is rolled back. Rollback of executed operations can be achieved by restoring cache files, etc.

[0115] In some embodiments of this disclosure, when vehicle-side sharding fails, the executed vehicle-side sharding can be rolled back to restore the previous state in case of an error, avoiding data loss or inconsistency and ensuring data consistency and reliability of vehicle-cloud strategy execution.

[0116] The vehicle-mounted system policy execution solution disclosed herein can receive vehicle-mounted execution budget data dynamically returned by the server based on the driving scenario, in order to adapt to the operation and maintenance needs of different driving modes of the vehicle. It can better adapt to complex and highly flexible dynamic scenarios and reduce the policy false trigger rate. It can dynamically allocate vehicle-mounted execution resources to execute vehicle-mounted execution shards based on vehicle-mounted execution budget data, avoiding the situation where policy generation and execution are completely dependent on the server. It can dynamically adjust vehicle-mounted execution resources, solve the problem of resource idleness or resource over-provisioning, and improve the overall resource management efficiency.

[0117] The foregoing describes the applications provided in this disclosure. Figure 1 The vehicle-to-cloud policy execution method of the vehicle terminal 102 in the system. In some other embodiments of this disclosure, a method for applying to Figure 1 The execution method of the vehicle cloud strategy in server 104, such as Figure 4 As shown, it includes the following steps:

[0118] S200: Receive vehicle operation data sent by the vehicle terminal, the vehicle operation data including driving status data and abnormal feature data.

[0119] In some embodiments of this disclosure, vehicle system operation data typically refers to operational indicator information describing the operating status of the vehicle system. Vehicle system operation data can be obtained by collecting operational indicators of the vehicle's cockpit software through a perception module deployed on the vehicle system. Operational indicators may include process resource indicators and user experience indicators. Process resource indicators may include CPU utilization, memory utilization, memory bandwidth, I / O (Input / Output) read bandwidth, I / O write bandwidth, network transmission bandwidth, and network reception bandwidth, etc. User experience indicators may include language response latency and navigation rendering frame rate, etc. Vehicle system operation data may include driving status data and abnormal feature data. Driving status data typically refers to driving status information describing the vehicle system's operation. Driving status data may include the vehicle's driving mode. Driving mode may include the current driving model on the vehicle system, historical driving modes on the vehicle system, and preparatory or predicted driving modes waiting to be started, executed, or switched on the vehicle system. Driving modes may include autonomous driving mode, parking mode, automatic parking mode, cruise control mode, towing mode, and charging mode, etc. Abnormal feature data typically refers to abnormal events or abnormal information describing the vehicle system. In some examples, anomalous characteristic data may include central processing unit overload, high latency, etc. Vehicle operation data can be collected via the vehicle-mounted system, and the server receives vehicle operation data directly transmitted from the vehicle-mounted system or transmitted through a first network adaptive transmission strategy.

[0120] S220. Determine the vehicle-side execution budget data based on the driving status data.

[0121] In some embodiments of this disclosure, the vehicle-side execution budget data typically refers to the budget information bound to the vehicle-mounted system based on driving status data for executing vehicle-cloud strategies. The server can bind different vehicle-side execution budgets to different driving modes of the vehicle-mounted system. In some examples, when the vehicle-mounted system is in autonomous driving mode, a high-safety budget can be bound, and the corresponding base budget can be set to 5 minutes / month; when the vehicle-mounted system is in parking mode, a high-tolerance budget can be bound, and the corresponding base budget can be set to 30 minutes / month.

[0122] S240. Based on the abnormal feature data and the remaining budget matching model, determine multiple policy fragments to be executed, including vehicle-side execution fragments and server-side execution fragments.

[0123] S260. The vehicle-side execution budget data and the vehicle-side execution fragments are sent to the vehicle terminal. The vehicle-side execution budget data includes actual budget data and remaining budget data. The actual budget data and the remaining budget data are used by the vehicle terminal to determine elastic resource allocation data based on the ratio of the remaining budget data to the actual budget data. The elastic resource allocation data is used by the vehicle terminal to allocate execution resources based on the elastic resource allocation data and to execute the vehicle-side execution fragments based on the execution resources.

[0124] In some embodiments of this disclosure, a second network adaptive transmission strategy can be used to transmit different numbers of vehicle-side execution fragments to the vehicle-mounted terminal based on different network qualities. In some examples, when the current network quality is greater than the first network signal strength, all vehicle-side execution fragments can be transmitted in real time. For example, when the current RSRP > -90dBm (i.e., when the current network quality is good), a full transmission mode can be used, transmitting all vehicle-side execution fragments of size 3KB. In other examples, when the current network quality is greater than the second network signal strength but less than the first network signal strength, the changed fragments corresponding to the abnormal feature data of the comparison server can be transmitted. For example, when -110dBm < RSRP < -90dBm (i.e., when the current network quality is average), a differential transmission mode can be used, transmitting only one changed fragment or a partial fragment (e.g., transmitting a partial changed fragment of size 1KB). In other examples, when the current network quality is less than the second network signal strength, the abnormal feature code is transmitted. For example, when RSRP < -110dBm (i.e., when the current network quality is poor), a metadata transmission mode can be used, transmitting only the anomaly signature (e.g., "0xA1+0xB3", indicating an anomaly of CPU exceeding limits and high latency). It's important to note that the endpoint values ​​such as the first network signal strength and the second network signal strength can be categorized differently depending on the specific circumstances. For instance, the first network signal strength (-90dBm) can be categorized as either excellent or average network quality; similarly, the second network signal strength (-110dBm) can be categorized as either average or poor network quality. The values ​​of -90dBm and -110dBm are merely exemplary values ​​for the first and second network signal strengths, used for illustrative purposes only and not as actual limitations; they can be set according to specific usage scenarios.

[0125] S280, Execute the server-side sharding.

[0126] In some embodiments of this disclosure, the remaining budget matching model typically refers to a matching method and / or rule for determining the strategy to be executed based on anomaly feature data and the remaining budget data on the vehicle-mounted system. The remaining budget matching model can be in the form of a database, an algorithm, or a matching configuration file. Regardless of the form, it is sufficient to implement the function of determining the strategy to be executed based on anomaly feature data and the remaining budget data on the vehicle-mounted system. In some examples, the server can determine the vehicle-mounted execution shard and the server-side execution shard based on the anomaly feature data and the remaining budget matching model. The vehicle-mounted execution shard transmission refers to the vehicle-mounted system providing the shard for execution, while the server-side execution shard is executed directly on the server.

[0127] In some embodiments of this disclosure, vehicle-side execution budget data adapted to different driving modes can be determined based on driving status data transmitted from the vehicle terminal. This can meet the operation and maintenance needs of different driving modes, better adapt to complex and highly flexible dynamic scenarios, and reduce the policy false trigger rate. The policy to be executed can be split into vehicle-side execution fragments and server-side execution fragments to avoid the situation where policy generation and execution are completely dependent on the server. By decomposing complex operation and maintenance policies into independent execution fragments, the overall resource management efficiency can be improved while reducing data transmission overhead.

[0128] In some embodiments of this disclosure, the vehicle-side execution budget data also includes basic budget data, based on which, such as Figure 5 As shown, step S220 includes:

[0129] S222. Determine the basic budget data based on the driving status data;

[0130] S224. The basic budget data is dynamically adjusted based on the service level target achievement rate and network signal strength to determine the actual budget data;

[0131] S226. Determine the deduction data based on the historical execution time of the vehicle-side segment, and determine the remaining budget data based on the deduction data and the actual budget data.

[0132] In some embodiments of this disclosure, the initial budget of the vehicle terminal in the current driving mode is determined by the basic budget data server. The actual budget data usually refers to the real budget of the vehicle terminal in the current driving mode determined by the server. The remaining budget data usually refers to the budget remaining after deducting the historical vehicle terminal execution fragments that have been executed in the current driving mode. The Service Level Objective (SLO) usually refers to the highest level objective of the maintenance system, or the service quality objective in the service level agreement. The service level objective can define the expected service quality level when using the software system and provide a standard for reference and evaluation by the development and operation teams. The initial budget can be allocated to the vehicle terminal based on the driving status data, i.e., the basic budget data mentioned above. The basic budget data can be dynamically adjusted based on the service level objective achievement rate and network signal strength to determine the actual budget data. In some examples, the actual budget data can be determined by the following formula (2):

[0133]

[0134] In equation (2), a represents the actual budget data, and b represents the basic budget data. is the difference between the current SLO compliance rate and the initial SLO compliance rate, c is the service level target improvement weight, d is the network signal strength, and e is the network signal strength improvement weight.

[0135] In some examples, we will use 'c' and 'e' configured as 0.1 as an example. When the vehicle is in autonomous driving mode, the base budget is 5 minutes / month, the initial SLO compliance rate is 99%, the actual compliance rate is 99.5%, and the network signal is enhanced by 5dBm. At this time, the actual budget is 5 + 0.5% × 100 × 0.1 + 5 × 0.1 = 5.55 minutes / month. That is, the dynamically allocated actual budget is 5.55 minutes / month.

[0136] In some embodiments of this disclosure, the deduction data can be determined based on the historical execution time of the vehicle-side segment, and the remaining budget data can be determined based on the deduction data and the actual budget data. In some examples, the deduction data can be determined using the following formula (3):

[0137]

[0138] In formula (3), the deduction value is the deduction data mentioned above, and the sharding execution time is the historical execution time of the sharding on the vehicle side. The resource consumption ratio of the corresponding historical execution of the sharding can be determined according to the ratio of the sharding resource consumption to the total resource quota.

[0139] In some examples, we'll use a historical fragment resource consumption ratio of 0.1 to the total resource quota and a fragment execution time of 0.5 minutes as an example. The deduction value = 0.1 × 0.5 = 0.05 (minutes). Based on the deduction data and the actual budget data, the remaining budget data is determined, and the remaining budget data is 5.5 minutes.

[0140] In some embodiments of this disclosure, the basic budget can be dynamically allocated based on different driving modes, and resource quotas can be adjusted in real time by the service level target achievement rate and network signal strength, so as to achieve a balance between risk control and operation and maintenance efficiency. Furthermore, the remaining budget data can be determined based on the deduction data and the actual budget data, and the remaining budget can be monitored and managed reasonably to ensure reasonable resource allocation under different driving modes.

[0141] In some embodiments of this disclosure, the remaining budget matching model is used to store the mapping relationship between the abnormal feature data, the ratio of the remaining budget data to the actual budget data, and at least two of the names of the strategies to be executed. Based on this, such as Figure 6 As shown, step S240 includes:

[0142] S242. Based on the abnormal feature data and the ratio of the remaining budget data to the actual budget data, determine the corresponding strategy name to be executed through the mapping relationship stored in the remaining budget matching model;

[0143] S244. Determine multiple policy fragments to be executed based on the names of the policies to be executed.

[0144] In some embodiments of this disclosure, the remaining budget matching model can be used to store the mapping relationship between at least two of the following: abnormal feature data, the ratio of remaining budget data to actual budget data, and the name of the strategy to be executed. In some examples, after building the initial remaining budget matching model, it can be trained using a machine learning model (e.g., a deep neural network learning model) to obtain a trained remaining budget matching model. The trained remaining budget matching model can also be continuously updated and optimized. The trained remaining budget matching model can automatically generate the corresponding name of the strategy to be executed based on the abnormal feature data and / or the ratio of remaining budget data to actual budget data, thereby improving the matching efficiency of the strategy to be executed.

[0145] In some examples, the abnormal characteristic data includes abnormal signature codes, such as "0xA1" and "0xB3". "0xA1" indicates an abnormal event of CPU exceeding limits, and "0xB3" indicates an abnormal event of high latency. When the ratio of remaining budget data to actual budget data is greater than a first ratio threshold, the matched policy name to be executed can be "Service Restart" and / or "Resource Expansion" and / or "Log Analysis"; when the ratio of remaining budget data to actual budget data is greater than a second ratio threshold but less than the first ratio threshold, the matched policy name to be executed can be "Service Degradation" and / or "Resource Limitation"; when the ratio of remaining budget data to actual budget data is less than the second ratio threshold, the matched policy name to be executed can be "Process Circuit Breaker" and / or "Minimize Log Collection".

[0146] In some embodiments of this disclosure, the corresponding name of the policy to be executed can be quickly matched by the mapping relationship stored in the remaining budget matching model, thereby quickly determining the shard of the policy to be executed, which can significantly shorten the response time and improve the efficiency of exception handling.

[0147] In some embodiments of this disclosure, the method further includes:

[0148] Upon receiving the execution result returned by the vehicle terminal, the improvement rate of the service level target achievement rate is determined based on the service level target achievement rate after the execution of the strategy to be executed and the service level target achievement rate before the execution of the strategy to be executed. The resource consumption deviation rate is determined based on the actual value and expected value of resource consumption of the vehicle terminal and / or the server.

[0149] If the improvement rate of the service level target achievement rate is less than the first improvement rate threshold and / or the resource consumption deviation rate is greater than the first deviation rate threshold for a preset number of times, the corresponding pending strategy will be sent to the pending review area.

[0150] In some embodiments of this disclosure, the server can be configured with an effectiveness evaluation model. The effectiveness evaluation model can be used to evaluate the SLO improvement rate and resource consumption deviation. In some examples, the improvement rate of the service level target achievement rate can be determined using the following formula (4):

[0151]

[0152] In formula (4), the post-execution compliance rate represents the service level target compliance rate after the above-mentioned strategy to be executed is executed, and the pre-execution compliance rate represents the service level target compliance rate before the above-mentioned strategy to be executed is executed.

[0153] In other examples, the resource consumption deviation rate can be determined using the following formula (5):

[0154]

[0155] In equation (5), the actual value represents the actual value of the resource consumption mentioned above, and the expected value represents the expected value of the resource consumption mentioned above.

[0156] In some embodiments of this disclosure, the remaining budget matching model can update and optimize the matching of the strategy to be executed based on the improvement rate of the service level target achievement rate and the resource consumption deviation rate. In some examples, if the improvement rate of the service level target achievement rate is less than a first improvement rate threshold (e.g., 5%) and / or the resource consumption deviation rate is greater than a first deviation rate threshold (e.g., 30%) for a preset number of times (e.g., 3 times), the corresponding strategy to be executed can be sent to the review area. The strategy to be executed can be re-verified in the review area through manual review or machine review.

[0157] The vehicle-cloud policy execution solution disclosed herein, applied to the server side, can determine the vehicle-side execution budget data adapted to different driving modes based on the driving status data transmitted from the vehicle terminal. It can meet the operation and maintenance needs of different driving modes, better adapt to complex and highly flexible dynamic scenarios, and reduce the policy false trigger rate. It can split the policy to be executed into vehicle-side execution shards and server-side execution shards, avoiding the situation where policy generation and execution are completely dependent on the server side. It decomposes complex operation and maintenance policies into independent execution shards, thereby reducing data transmission overhead while improving overall resource management efficiency.

[0158] It is understood that the various embodiments of the methods described in this specification are presented in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on its differences from other embodiments. Relevant details can be found in the descriptions of other method embodiments.

[0159] It should be understood that although the steps in the flowcharts shown in the accompanying drawings are displayed sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise expressly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some of the steps in the accompanying drawings may include multiple steps or stages, which are not necessarily completed at the same time, but may be executed at different times, and the execution order of these steps or stages is not necessarily sequential, but may be performed alternately or in turn with other steps or at least a portion of the steps or stages of other steps.

[0160] Based on the description of the vehicle-cloud strategy execution method embodiments described above, this disclosure also provides a vehicle-cloud strategy execution device for implementing the aforementioned vehicle-cloud strategy execution method. The device may include a system (including a distributed system), software (application), module, component, controller, server, terminal, etc., using the method described in the embodiments of this specification, combined with necessary implementation hardware. Based on the same innovative concept, the devices in one or more embodiments provided by the embodiments of this disclosure are as described in the following embodiments. Since the implementation schemes and methods for solving the problem by the devices are similar, the implementation of specific devices in the embodiments of this specification can refer to the implementation of the aforementioned method, and repeated details will not be repeated. As used below, the terms "unit" or "module" can refer to a combination of software and / or hardware that implements a predetermined function. Although the devices described in the following embodiments are preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0161] Figure 7 This is a schematic block diagram illustrating a vehicle-to-cloud policy execution device applied to an in-vehicle infotainment system, according to an exemplary embodiment. For details, please refer to... Figure 7 The device 110 may include a first communication module 120, a second communication module 140, and a first processing module 160. The first communication module 120 is used to send vehicle-mounted system (V2S) operation data to the server, the V2S operation data including driving status data and abnormal feature data. The second communication module 140 is used to receive vehicle-mounted execution budget data returned by the server based on the driving status data and vehicle-mounted execution fragments returned based on the abnormal feature data, the vehicle-mounted execution budget data including actual budget data and remaining budget data. The first processing module 160 is used to determine elastic resource allocation data based on the ratio of the remaining budget data to the actual budget data; and is also used to allocate execution resources for the V2S based on the elastic resource allocation data, and execute the vehicle-mounted execution fragments based on the execution resources.

[0162] In some embodiments of the device, the first communication module 120 is further configured to determine a corresponding data acquisition strategy based on the current driving state data, determine abnormal feature data based on the data acquisition strategy, and transmit the abnormal feature data to the server based on a first network adaptive transmission strategy corresponding to the current network quality, wherein the first network adaptive transmission strategy represents the transmission of abnormal feature data with different degrees of completeness for different network qualities.

[0163] In some embodiments of the device, the first communication module 120 is further configured to extract anomaly feature codes from the anomaly feature data and perform hash operations to determine the corresponding data blocks; the first communication module 120 is further configured to transmit all data blocks corresponding to the anomaly feature data and the anomaly feature codes completely when the current network quality is greater than the first network signal strength; the first communication module 120 is further configured to transmit the changed data blocks corresponding to the anomaly feature data compared with the server and the anomaly feature codes when the current network quality is greater than the second network signal strength and less than the first network signal strength; the first communication module 120 is further configured to transmit the anomaly feature codes when the current network quality is less than the second network signal strength.

[0164] In some embodiments of the device, the first processing module 160 is further configured to, when the ratio of the remaining budget data to the actual budget data is greater than a first remaining ratio threshold and the current execution resources exceed a first resource threshold, expand the current execution resources according to the elastic resource configuration data, and execute the vehicle-side execution sharding according to the expanded execution resources.

[0165] In some embodiments of the device, the first processing module 160 is further configured to roll back the executed vehicle-side execution fragment if the execution of the vehicle-side execution fragment fails; the first communication module 120 is further configured to generate an execution result and send the execution result to the server.

[0166] Figure 8 This is a schematic block diagram illustrating a vehicle-to-cloud policy execution device applied to a server, according to an exemplary embodiment. For details, please refer to... Figure 8The device 200 may include: a third communication module 220, a second processing module 240, a third processing module 260, a fourth communication module 280, and a fourth processing module 290. The system includes the following components: a third communication module 220 for receiving vehicle operation data sent from the vehicle terminal, including driving status data and abnormal feature data; a second processing module 240 for determining vehicle-side execution budget data based on the driving status data; a third processing module 260 for determining multiple strategy fragments to be executed based on the abnormal feature data and a remaining budget matching model, including vehicle-side execution fragments and server-side execution fragments; a fourth communication module 280 for sending the vehicle-side execution budget data and the vehicle-side execution fragments to the vehicle terminal, wherein the vehicle-side execution budget data includes actual budget data and remaining budget data, and the actual budget data and remaining budget data are used by the vehicle terminal to determine elastic resource allocation data based on the ratio of the remaining budget data to the actual budget data, and the elastic resource allocation data is used by the vehicle terminal to allocate execution resources based on the elastic resource allocation data, and to execute the vehicle-side execution fragments based on the execution resources; and a fourth processing module 290 for executing the server-side execution fragments.

[0167] In some embodiments of the device, the vehicle-side execution budget data also includes basic budget data. Based on this, the second processing module 240 is further configured to determine the basic budget data according to the driving status data; the second processing module 240 is further configured to dynamically adjust the basic budget data according to the service level target achievement rate and network signal strength to determine the actual budget data; the second processing module 240 is further configured to determine the deduction data according to the historical execution time of the vehicle-side execution segments, and determine the remaining budget data according to the deduction data and the actual budget data.

[0168] In some embodiments of the device, the remaining budget matching model is used to store the mapping relationship between at least two of the abnormal feature data, the ratio of the remaining budget data to the actual budget data, and the name of the strategy to be executed. Based on this, the third processing module 260 is further used to determine the corresponding name of the strategy to be executed based on the abnormal feature data and the ratio of the remaining budget data to the actual budget data, through the mapping relationship stored in the remaining budget matching model; and to determine multiple strategy fragments to be executed based on the name of the strategy to be executed.

[0169] In some embodiments of the device, the third processing module 260 is further configured to, upon receiving the execution result returned by the vehicle terminal, determine the improvement rate of the service level target achievement rate based on the service level target achievement rate after the execution of the strategy to be executed and the service level target achievement rate before the execution of the strategy to be executed; determine the resource consumption deviation rate based on the actual and expected resource consumption values ​​of the vehicle terminal and / or the server; and send the corresponding strategy to be executed to the review area if the improvement rate of the service level target achievement rate is less than a first improvement rate threshold and / or the resource consumption deviation rate is greater than the first deviation rate threshold for a preset number of times.

[0170] Each module in the aforementioned vehicle-cloud strategy execution device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can call and execute the corresponding operations of each module.

[0171] In some embodiments, a vehicle-mounted terminal is provided, including a memory and a processor, the memory storing a computer program, the processor executing the computer program to implement the steps described in any method embodiment of this disclosure applied to a vehicle-mounted terminal.

[0172] In some embodiments, a server is provided, including a memory and a processor, the memory storing a computer program, the processor executing the computer program to implement the steps described in any method embodiment of this disclosure applied to a server.

[0173] In some implementations, a vehicle is provided that includes the aforementioned vehicle-mounted terminal.

[0174] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to interchangeably. Each embodiment focuses on its differences from other embodiments. In particular, for hardware + program embodiments, since they are basically similar to the method embodiments, the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

[0175] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties.

[0176] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments described above. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0177] It should be noted that the apparatus, computer equipment, storage medium, and computer program products described above may also include other implementation methods according to the description of the method embodiments. Specific implementation methods can be found in the description of the relevant method embodiments. Furthermore, new embodiments formed by combinations of features from various methods, apparatuses, devices, and server embodiments still fall within the scope of this disclosure and will not be elaborated upon here.

[0178] For ease of description, the above devices are described in terms of function, divided into various modules. Of course, when implementing one or more of these specifications, the functions of each module can be implemented in the same or different software and / or hardware, or a module that performs the same function can be implemented by a combination of multiple sub-modules or sub-units. The device embodiments described above are merely illustrative. For example, the division of modules or units is only a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling and communication connections between the devices or units shown or described can be implemented through direct and / or indirect coupling / connection, through standard or custom interfaces or protocols, and can be implemented electrically, mechanically, or in other forms.

[0179] Other embodiments of this disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This disclosure is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this disclosure are indicated by the following claims.

[0180] It should be understood that this disclosure is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope.

Claims

1. A vehicle-to-cloud strategy execution method, characterized in that, Applied to in-vehicle infotainment systems, the method includes: The vehicle system operation data is sent to the server, and the vehicle system operation data includes driving status data and abnormal feature data; The receiving server returns vehicle-side execution budget data based on the driving status data and vehicle-side execution shards based on the abnormal feature data. The vehicle-side execution budget data includes actual budget data and remaining budget data. The flexible resource allocation data is determined based on the ratio of the remaining budget data to the actual budget data. The vehicle-mounted system allocates execution resources based on the elastic resource allocation data, and executes the vehicle-mounted execution fragments based on the execution resources. The vehicle-side execution budget data also includes basic budget data, which is determined through the following steps: The server determines the basic budget data based on the driving status data; The server dynamically adjusts the basic budget data based on the service level target achievement rate and network signal strength to determine the actual budget data; The server determines the deduction data based on the historical execution time of the vehicle segment, and determines the remaining budget data based on the deduction data and the actual budget data. The vehicle-side sharding is determined by the server based on the abnormal feature data and the remaining budget matching model through the following steps: The remaining budget matching model is used to store the mapping relationship between the abnormal feature data, the ratio of the remaining budget data to the actual budget data, and at least two of the names of the strategies to be executed; The server determines the corresponding strategy name to be executed based on the abnormal feature data and the ratio of the remaining budget data to the actual budget data, through the mapping relationship stored in the remaining budget matching model; The server determines multiple policy fragments to be executed based on the name of the policy to be executed.

2. The method according to claim 1, characterized in that, Sending vehicle system operation data to the server includes: Determine the corresponding data acquisition strategy based on the current driving status data, and determine abnormal feature data based on the data acquisition strategy; The abnormal feature data is transmitted to the server according to the first network adaptive transmission strategy corresponding to the current network quality. The first network adaptive transmission strategy represents the transmission of abnormal feature data with different degrees of completeness for different network qualities.

3. The method according to claim 2, characterized in that, The step of transmitting the abnormal feature data to the server according to the first network adaptive transmission strategy corresponding to the current network quality includes: Extract abnormal feature codes from the abnormal feature data and perform hash operations to determine the corresponding data blocks; If the current network quality is greater than the first network signal strength, transmit all data blocks corresponding to the abnormal feature data and the abnormal feature code completely. When the current network quality is greater than the second network signal strength but less than the first network signal strength, the change data block corresponding to the abnormal feature data of the server and the abnormal feature code are transmitted for comparison. The abnormal signature code is transmitted when the current network quality is lower than the signal strength of the second network.

4. The method according to claim 1, characterized in that, The step of allocating vehicle-mounted execution resources according to elastic resource configuration data, and executing the vehicle-mounted execution shards according to the execution resources, includes: If the ratio of the remaining budget data to the actual budget data is greater than a first remaining ratio threshold and the current execution resources exceed a first resource threshold, the current execution resources are expanded according to the elastic resource configuration data, and the vehicle-side execution shards are executed based on the expanded execution resources.

5. The method according to claim 1, characterized in that, The method further includes: If the execution of the vehicle-side execution segment fails, roll back the already executed vehicle-side execution segment; Generate the execution result and send the execution result to the server.

6. A vehicle-to-cloud strategy execution method, characterized in that, Applied to the server side, the method includes: Receive vehicle operation data sent by the vehicle terminal, the vehicle operation data including driving status data and abnormal feature data; The vehicle-side execution budget data is determined based on the driving status data. Based on the abnormal feature data and the remaining budget matching model, multiple policy fragments to be executed are determined, including vehicle-side execution fragments and server-side execution fragments. The vehicle-side execution budget data and the vehicle-side execution fragments are sent to the vehicle-mounted terminal. The vehicle-side execution budget data includes actual budget data and remaining budget data. The actual budget data and the remaining budget data are used by the vehicle-mounted terminal to determine elastic resource allocation data based on the ratio of the remaining budget data to the actual budget data. The elastic resource allocation data is used by the vehicle-mounted terminal to allocate execution resources based on the elastic resource allocation data and to execute the vehicle-side execution fragments based on the execution resources. The server-side sharding is executed. The vehicle-side execution budget data also includes basic budget data, and determining the vehicle-side execution budget data based on the driving status data includes: The basic budget data is determined based on the driving status data; The basic budget data is dynamically adjusted based on the service level target achievement rate and network signal strength to determine the actual budget data; The deduction data is determined based on the historical execution time of the vehicle-side segment, and the remaining budget data is determined based on the deduction data and the actual budget data. The remaining budget matching model is used to store the mapping relationship between the abnormal feature data, the ratio of the remaining budget data to the actual budget data, and at least two of the names of the strategies to be executed. The step of determining multiple strategy shards to be executed based on the abnormal feature data and the remaining budget matching model includes: Based on the abnormal feature data and the ratio of the remaining budget data to the actual budget data, the corresponding strategy name to be executed is determined through the mapping relationship stored in the remaining budget matching model; Multiple policy fragments to be executed are determined based on the names of the policies to be executed.

7. The method according to claim 6, characterized in that, The method further includes: Upon receiving the execution result returned by the vehicle terminal, the improvement rate of the service level target achievement rate is determined based on the service level target achievement rate after the execution of the strategy to be executed and the service level target achievement rate before the execution of the strategy to be executed. The resource consumption deviation rate is determined based on the actual value and expected value of resource consumption of the vehicle terminal and / or the server. If the improvement rate of the service level target achievement rate is less than the first improvement rate threshold and / or the resource consumption deviation rate is greater than the first deviation rate threshold for a preset number of times, the corresponding pending strategy will be sent to the pending review area.

8. A vehicle-to-cloud strategy execution device, characterized in that, The device, applied to in-vehicle infotainment systems, includes: The first communication module is used to send vehicle system operation data to the server. The vehicle system operation data includes driving status data and abnormal feature data. The second communication module is used to receive vehicle-side execution budget data returned by the server based on the driving status data and vehicle-side execution fragments returned based on abnormal feature data. The vehicle-side execution budget data includes actual budget data and remaining budget data. The first processing module is configured to determine flexible resource allocation data based on the ratio of the remaining budget data to the actual budget data; and to allocate execution resources on the vehicle-mounted system based on the flexible resource allocation data, and execute the vehicle-mounted execution shards based on the execution resources. The vehicle-side execution budget data also includes basic budget data. The second communication module is further used to receive vehicle-side execution budget data determined by the server according to the following steps: the server determines basic budget data based on the driving status data; the server dynamically adjusts the basic budget data based on the service level target achievement rate and network signal strength to determine the actual budget data; the server determines deduction data based on the historical execution time of vehicle-side execution segments, and determines the remaining budget data based on the deduction data and the actual budget data. The second communication module is further configured to receive vehicle-side execution shards determined by the server based on the abnormal feature data and the remaining budget matching model through the following steps: the remaining budget matching model is used to store mapping relationships of at least two of the abnormal feature data, the ratio of the remaining budget data to the actual budget data, and the names of the strategies to be executed; the server determines the corresponding names of the strategies to be executed based on the abnormal feature data and the ratio of the remaining budget data to the actual budget data, through the mapping relationships stored in the remaining budget matching model; the server determines multiple strategy shards to be executed based on the names of the strategies to be executed.

9. A vehicle-to-cloud strategy execution device, characterized in that, Applied to the server side, the device includes: The third communication module is used to receive vehicle operation data sent by the vehicle terminal, the vehicle operation data including driving status data and abnormal feature data; The second processing module is used to determine the vehicle-side execution budget data based on the driving status data; The third processing module is used to determine multiple policy fragments to be executed based on the abnormal feature data and the remaining budget matching model. The policy fragments to be executed include vehicle-side execution fragments and server-side execution fragments. The fourth communication module is used to send the vehicle-side execution budget data and the vehicle-side execution fragment to the vehicle terminal. The vehicle-side execution budget data includes actual budget data and remaining budget data. The actual budget data and the remaining budget data are used by the vehicle terminal to determine elastic resource allocation data based on the ratio of the remaining budget data to the actual budget data. The elastic resource allocation data is used by the vehicle terminal to allocate execution resources based on the elastic resource allocation data and execute the vehicle-side execution fragment based on the execution resources. The fourth processing module is used to execute the server-side sharding. The vehicle-side execution budget data also includes basic budget data, and the second processing module is further used to determine the basic budget data based on the driving status data; The second processing module is also used to dynamically adjust the basic budget data based on the service level target achievement rate and network signal strength to determine the actual budget data; The second processing module is also used to determine the deduction data based on the historical execution time of the vehicle-side segment, and to determine the remaining budget data based on the deduction data and the actual budget data; The remaining budget matching model is used to store the mapping relationship between at least two of the abnormal feature data, the ratio of the remaining budget data to the actual budget data, and the name of the strategy to be executed. The third processing module is also used to determine the corresponding name of the strategy to be executed based on the abnormal feature data and the ratio of the remaining budget data to the actual budget data, through the mapping relationship stored in the remaining budget matching model; and to determine multiple strategy shards to be executed based on the name of the strategy to be executed.

10. A vehicle-mounted terminal, characterized in that, It includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the steps of the method according to any one of claims 1 to 5.

11. A server, characterized in that, It includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the steps of the method according to any one of claims 6 to 7.

12. A vehicle, characterized in that, Including the vehicle-mounted terminal as described in claim 10.

Images