Vehicle control method, vehicle, and electronic device

Abstract

This application relates to a vehicle control method, a vehicle, and an electronic device, belonging to the field of vehicle control technology. It includes: acquiring multimodal driver commands; determining the command type of the multimodal driver commands to obtain the driver command type; at the framework layer, analyzing the driver command type according to preset command priority rules to determine whether the response strategy for each type of multimodal driver command is to allow passage; if so, sending the multimodal driver command to the application layer; otherwise, intercepting the multimodal driver command. By intercepting multimodal driver commands at the framework layer, control over multimodal driver commands can be implemented from the system's bottom layer, avoiding security risks caused by application layer interception being bypassed by physical buttons or shortcut operations. Thus, the execution of unnecessary commands is fundamentally eliminated, improving driving safety.

Description

Technical Field

[0001] This application relates to the technical field of vehicle control, and more particularly to a vehicle control method, a vehicle, and electronic equipment. Background Technology

[0002] As vehicles become more intelligent, the demands on driving safety and interactive experience place higher requirements on the integration between in-vehicle cockpit systems and Advanced Driving Assistance Systems (ADAS). To improve driving safety, existing technologies typically impose certain restrictions on drivers' entertainment activities while driving.

[0003] Currently, the control over unnecessary driver actions largely remains at the application layer. For example, video playback applications may automatically restrict playback when a vehicle is detected in motion. These solutions typically rely on the logical judgments of each application itself, or on rule-based judgments based on a few signals such as vehicle speed and gear position. Drivers can still bypass the restrictions set by specific applications by using physical buttons on the steering wheel, system-level shortcuts, or switching between applications. This means that in driving scenarios requiring a high level of driver concentration, existing solutions cannot fundamentally eliminate the driver's triggering of unnecessary commands, and the risk of distraction remains, potentially affecting driving safety. Summary of the Invention

[0004] This application addresses, to at least some extent, one of the technical problems in the related art.

[0005] Therefore, this application aims to provide a vehicle control method, a vehicle, and an electronic device.

[0006] To achieve the above objectives, in a first aspect, this application provides a vehicle control method applied to an in-vehicle infotainment system, the in-vehicle infotainment system comprising a framework layer and an application layer, which includes: Collect driver multimodal commands, determine the command type of the driver multimodal commands, and obtain the driver command type; In the framework layer, the driver command types are analyzed according to preset command priority rules to determine whether the response strategy for each type of driver multimodal command is to allow passage. If so, the driver multimodal command is sent to the application layer; otherwise, the driver multimodal command is intercepted.

[0007] In this technical solution, multimodal commands from the driver are collected and their types are determined. At the framework layer, the driver's command types are analyzed according to preset command priority rules to determine whether the response strategy should be to allow passage. Only when passage is allowed is the command sent to the application layer; otherwise, it is intercepted. By moving the interception decision to the framework layer, unified type determination and priority adjudication are completed before the command reaches the application layer, thus implementing proactive and unbypassable control over multimodal commands from the system's bottom layer. Therefore, in high-risk driving scenarios requiring high driver concentration, the possibility of unnecessary commands being triggered can be fundamentally eliminated, effectively reducing driver distraction and significantly improving driving safety. Simultaneously, because the interception logic does not rely on the judgments of individual applications, it avoids control failures caused by application-layer differences or bypass operations, ensuring the consistency and reliability of the control strategy.

[0008] In some embodiments of this application, the analysis of the driver command type according to a preset command priority rule includes analysis in conjunction with a driving risk level, which is determined through the following steps: Acquire environmental perception data, navigation data, vehicle driving data, and driver driving data; Each parameter in the environmental perception data, vehicle driving data, and driver data is quantitatively scored to obtain a single risk score for each parameter. Based on the individual risk scores, calculate the environmental perception score, scene recognition score, vehicle status score, and driver status score respectively. The environmental perception score, scene recognition score, vehicle status score, and driver status score are weighted and summed based on preset weights to obtain a comprehensive risk score. The comprehensive risk score is compared with a preset risk level classification threshold to obtain the driving risk level; wherein the driving risk level includes high risk level, medium risk level and low risk level.

[0009] In this technical solution, parameters from multiple dimensions of data, including environmental perception, scene, vehicle driving, and driver, are quantitatively scored. This maps raw data with different dimensions into comparable risk scores, solving the problem of fusion of multi-source heterogeneous data. The scores for each dimension are then calculated separately and weighted according to preset weights, comprehensively reflecting the differentiated impact of different dimensions on driving safety, making the overall risk score closer to the actual risk level. Finally, by comparing with preset thresholds, high, medium, and low risk levels are obtained, achieving refined classification of driving risk. Therefore, this application can accurately quantify the current driving risk status, providing a reliable basis for subsequent command interception and resource management, avoiding safety hazards or decreased user experience due to risk misjudgment, and effectively improving driving safety and system response rationality.

[0010] In some embodiments of this application, the acquisition of driver multimodal commands includes: Collect the driver's multimodal commands and encapsulate them into standardized command data; The standardized instruction data is transmitted to the framework layer, and the instruction interception service module deployed in the framework layer intercepts the standardized instruction data.

[0011] In this technical solution, by collecting the driver's multimodal commands and encapsulating them into standardized command data, commands from different sources and in different formats, such as voice, touch, gestures, physical buttons, and gaze, can be unified into a single data structure, reducing the complexity of subsequent command determination. The standardized command data is transmitted to the framework layer, where it is intercepted by a command interception service module deployed within the framework layer. This ensures that commands are uniformly controlled before reaching the application layer, achieving proactive intervention from the bottom layer and avoiding the bypass risks associated with traditional solutions that only intercept commands at the application layer. Therefore, this application can uniformly acquire and control all types of commands in the early stages of the command execution path, ensuring that unnecessary commands are reliably blocked in high-risk scenarios and effectively improving driving safety.

[0012] In some embodiments of this application, the step of determining the instruction type of the driver's multimodal instructions to obtain the driver instruction type includes: Based on the standardized instruction data, extract the instruction content field, instruction type field, and acquisition device source field; The matching instruction keywords are obtained by matching the instruction content field with the instruction keywords in the preset rule base. Based on the instruction type field and the acquisition device source field, the matched instruction keywords are classified into scenarios to obtain the driver instruction type; The types of driver commands include safety commands, vehicle control commands, and entertainment commands.

[0013] In this technical solution, by extracting instruction content, instruction type, and acquisition device source fields from standardized instruction data, the semantic information, input modality, and hardware source of the instruction can be comprehensively obtained, providing multi-dimensional basis for judgment. Matching the instruction content field with keywords in a preset rule base allows for rapid identification of the instruction's core intent. Furthermore, combining the instruction type and device source fields to categorize the matching results by scenario eliminates ambiguity that might arise from a single field, thereby improving the accuracy and robustness of instruction type determination. Therefore, this application can accurately distinguish between different categories of instructions, such as safety, vehicle control, and entertainment, providing reliable input for subsequent differentiated responses based on risk levels. This avoids the interception of safe instructions or the release of dangerous instructions due to misjudgment, further ensuring driving safety.

[0014] In some embodiments of this application, the step of analyzing the driver command type according to a preset command priority rule at the framework layer and determining whether the response strategy for each type of driver multimodal command is to allow passage includes: When the driver's instruction type is the safety instruction, the response strategy is determined to be to allow passage; When the driver's instruction type is the vehicle control instruction, if the driving risk level is low, the response strategy is to release; if the driving risk level is medium, the response strategy is to delay release; if the driving risk level is high, the response strategy is to hold until the driving risk level decreases before releasing. When the driver's instruction type is an entertainment instruction, if the driving risk level is low, the response strategy is to allow passage; if the driving risk level is medium, the response strategy is to partially allow passage; if the driving risk level is high, the response strategy is to not allow passage.

[0015] The technical solution categorizes commands into safety, vehicle control, and entertainment, and incorporates high, medium, and low driving risk levels, pre-setting differentiated response strategies. This achieves cross-determination of risk level and command priority, allowing the response strategy to dynamically adjust according to risk. In high-risk scenarios, entertainment and non-emergency vehicle control commands are blocked at the source, reducing driver distraction; in medium-risk scenarios, basic operations are retained but heavy entertainment is limited, balancing safety and usability; and in low-risk scenarios, a complete interactive experience is provided. Therefore, this application achieves a reasonable balance between safety, user experience, and resource allocation while ensuring driving safety.

[0016] In some embodiments of this application, if so, the driver multimodal command is sent to the application layer; otherwise, intercepting the driver multimodal command includes: When the response strategy is to allow passage, the driver's multimodal command is sent to the application or system component corresponding to the application layer for execution; When the response strategy is to not allow passage, the driver's multimodal command is intercepted, and an interception prompt message is output through the human-machine interface; When the response strategy is delayed release, the driver's multimodal command is temporarily stored and executed after a preset delay time; When the response strategy is to temporarily store the driver's multimodal commands until the driving risk level is reduced, the driver's multimodal commands are temporarily stored, the driving risk level is monitored, and the commands are issued and executed after the driving risk level is reduced. When the response strategy is partial release, the executable part of the driver's multimodal instruction is parsed, and only the executable part is sent to the application or system component corresponding to the application layer for execution.

[0017] In this technical solution, fine-grained control over instructions is achieved by defining specific execution methods for different response strategies. Therefore, this application can accurately respond to user instructions with differentiated execution logic based on combinations of different risk levels and instruction types. This ensures driving safety in high-risk scenarios while maximizing interactive convenience in low- and medium-risk scenarios. Furthermore, it reduces user confusion through prompts, enhancing the system's intelligence and user experience.

[0018] In some embodiments of this application, the preset instruction priority rules are stored in the framework layer in the form of a configurable rule base.

[0019] In this technical solution, by storing preset instruction priority rules as a configurable rule base in the framework layer, the rule base is decoupled from the main system program. This allows for dynamic adjustments or online upgrades to instruction priorities, keyword matching rules, and response strategies without modifying the underlying system code or recompiling the operating system. Therefore, this application can quickly optimize the rule base based on different vehicle models, regulatory requirements, or user feedback, reducing system maintenance costs and update cycles. Furthermore, the rule base's location in the framework layer ensures immediate access to rules for judgment after instruction interception, avoiding delays caused by cross-layer calls. This enhances the system's flexibility and real-time performance while ensuring driving safety.

[0020] In some embodiments of this application, it further includes: Based on the aforementioned driving risk level, resource restrictions are applied to entertainment applications. The resource restrictions include at least one of the following: limiting CPU utilization, limiting memory usage, limiting rendering frame rate, limiting bus bandwidth usage, and limiting the number of background processes.

[0021] The technical solution implements differentiated resource restrictions on entertainment applications based on driving risk levels, including limiting CPU utilization, memory usage, rendering frame rate, bus bandwidth usage, and the number of background processes, thereby achieving dynamic control of system resources. This resource restriction approach enables passive risk mitigation, resolving the resource recovery issue for already running entertainment applications. It also reserves sufficient computing power and memory for intelligent driving algorithms in high-risk scenarios, improving driving safety and system stability.

[0022] In a second aspect, this application provides a vehicle including a controller for implementing the vehicle control method as described in the first aspect.

[0023] In a third aspect, this application provides an electronic device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, implements the vehicle control method as described in the first aspect.

[0024] As can be seen from the above technical solutions, additional aspects and advantages of this application will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this application. Attached Figure Description

[0025] Figure 1 This is a schematic diagram of the overall structure of a vehicle control system according to an embodiment of this application; Figure 2 This is a schematic diagram of the overall process of the vehicle control method according to the embodiments of this application; Figure 3 This is a schematic diagram of the driving risk assessment process according to the embodiments of this application; Figure 4 This is a schematic diagram of the multimodal command acquisition and interception process according to the embodiments of this application; Figure 5 This is a schematic diagram of the instruction type determination process according to the embodiments of this application; Figure 6 This is a schematic diagram of a computer device according to an embodiment of this application.

[0026] In the above figures: 40. Bus; 41. Processor; 42. Memory; 43. Communication interface; 100. Driving risk acquisition module; 200. Multimodal input acquisition module; 300. Android Framework layer instruction interception service module; 400. Intent priority judgment module; 500. System resource restriction module. Detailed Implementation

[0027] In this application, unless otherwise expressly specified and limited, "above" or "below" the second feature can mean that the first feature is in direct contact with the second feature, or that the first feature is in indirect contact with the second feature through an intermediate medium. Furthermore, "above," "on top of," and "over" the second feature can mean that the first feature is directly above or diagonally above the second feature, or simply that the first feature is at a higher horizontal level than the second feature. "Below," "below," and "under" the second feature can mean that the first feature is directly below or diagonally below the second feature, or simply that the first feature is at a lower horizontal level than the second feature. In this application, the terms "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to a specific feature, structure, material, or characteristic described in connection with that embodiment or example, which is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0028] The present application will now be described in detail through exemplary embodiments. However, it should be understood that, without further description, elements, structures, and features in one embodiment may be advantageously incorporated into other embodiments. It's important to note that in the automotive industry, with the deep integration of intelligent cockpits and Advanced Driving Assistance Systems (ADAS), in-vehicle operating systems (such as Android Automotive) need to simultaneously handle two core tasks: cockpit interaction and intelligent driving algorithms. On one hand, the cockpit system needs to respond in real-time to multimodal driver commands from voice, touch, gestures, physical buttons, and eye contact, providing a wealth of entertainment and vehicle control functions. On the other hand, the ADAS system needs to continuously perceive the environment, plan routes, and execute vehicle control, placing stringent demands on computing resources and real-time communication bandwidth.

[0029] However, in the current vehicle system architecture, the cockpit and ADAS often operate independently, lacking an effective real-time linkage mechanism. This makes it impossible to transmit risk level information to the cockpit system in a timely manner, and also makes it difficult to achieve risk-based command control and resource recovery.

[0030] In existing technologies, the control of non-essential driver operations mostly remains at the application layer, such as restricting playback within video applications or turning off headlights via voice control while driving. These technologies cannot uniformly intercept and block multimodal commands at the operating system level. This allows users to bypass application-layer restrictions through shortcuts, switching between applications, or physical buttons, potentially triggering entertainment or non-emergency vehicle control commands in high-risk driving scenarios, leading to distraction and increasing the risk of accidents.

[0031] Meanwhile, in-cabin entertainment applications share computing resources such as domain control chips with intelligent driving algorithms. Existing solutions can only perform simple start-stop control of applications and cannot dynamically reclaim the CPU, memory, graphics processor rendering frame rate, and controller LAN bus bandwidth occupied by running entertainment applications based on risk levels. When high-risk scenarios such as emergency avoidance or highway construction occur, the resource contention of entertainment applications will directly lead to delays in the perception, decision-making, and control response of the intelligent driving system, severely weakening safety redundancy.

[0032] Based on this, this application proposes a vehicle control method, vehicle, and electronic device. It assesses driving risk levels by acquiring multi-dimensional data on environmental perception, scene, vehicle movement, and driver. At the framework layer, it intercepts the driver's multimodal commands, determines the command type, and then establishes a response strategy based on the current driving risk level and preset command priority rules. Simultaneously, it restricts and reclaims resources for entertainment applications according to the risk level. This proactively blocks the execution of unnecessary commands from the bottom layer in high-risk driving scenarios, preventing driver distraction. By dynamically reclaiming resources such as the central processing unit, memory, and bus bandwidth occupied by entertainment applications, it reserves sufficient computing power and communication bandwidth for the intelligent driving system, ensuring its real-time response in perception, decision-making, and control. In low- to medium-risk scenarios, it reasonably retains interactive functions and entertainment experiences, thus achieving dual coverage of real-time cockpit-driver linkage, proactive command interception, and passive resource rollback. This solves the problems of cockpit-driver system fragmentation, incomplete command interception, resource preemption, and the lack of a dual-scenario mechanism.

[0033] It should be noted that, for ease of understanding, the technical concepts involved in this application are briefly explained below.

[0034] In the following, embodiments of this application will be described in detail with reference to the accompanying drawings.

[0035] like Figure 1 As shown, to facilitate understanding of the vehicle control method provided in this application, the following is combined with... Figure 1 The vehicle control system architecture of this application is described in detail.

[0036] Preferably, the vehicle control system of this application includes a driving risk acquisition module 100, a multimodal input acquisition module 200, an Android application framework layer (Android Framework layer) instruction interception service module 300, an intent priority judgment module 400, and a system resource restriction module 500.

[0037] Furthermore, the driving risk acquisition module is connected to the vehicle's advanced driving assistance system (ADAS) and the Android Framework layer instruction interception service module 300 via a controller area network bus (CAN).

[0038] Specifically, the driving risk acquisition module 100 collects driving risk level signals generated by the ADAS system in real time. The ADAS system calculates the aforementioned risk level signals by fusing data collected from environmental perception sensors, vehicle status sensors, driver status monitoring sensors, and navigation and positioning sensors, according to a preset multi-dimensional risk assessment strategy.

[0039] The driving risk acquisition module 100 periodically receives the risk level signal via the CAN bus, verifies and parses the received signal, and then transmits the standardized risk level signal to the Android Framework layer instruction interception service module 300 via the Java Native Interface (JNI). Thus, the driving risk acquisition module 100 provides the Android Framework layer instruction interception service module 300 with real-time driving risk information, enabling differentiated responses based on instruction type.

[0040] Furthermore, the multimodal input acquisition module 200 is communicatively connected to the vehicle-mounted hardware device and the Android Framework layer instruction interception service module 300.

[0041] Specifically, the multimodal input acquisition module 200 is used to acquire the driver's multimodal commands. The multimodal input acquisition module 200 is communicatively connected to in-vehicle hardware devices, including a microphone array, a touch screen controller, a cockpit camera, steering wheel physical buttons, and central control physical buttons.

[0042] The multimodal input acquisition module 200 calls the driver program of the aforementioned hardware device through the Android native application programming interface to obtain raw instruction data, such as voice instructions, touch instructions, gesture instructions, physical button instructions, and gaze instructions.

[0043] The multimodal input acquisition module 200 encapsulates the raw instruction data into standardized instruction data and transmits the standardized instruction data to the Android Framework layer instruction interception service module 300 through the Binder cross-process communication mechanism.

[0044] Furthermore, the Android Framework layer instruction interception service module 300 is deployed in the SystemServer process of the in-vehicle Android system, located before the input dispatch component. The Android Framework layer instruction interception service module 300 is communicatively connected to the driving risk acquisition module 100, the multimodal input acquisition module 200, the intent priority judgment module 400, and the system resource restriction module 500.

[0045] Specifically, the Android Framework layer instruction interception service module 300 is used to intercept the standardized instruction data transmitted by the multimodal input acquisition module 200, and simultaneously acquire the current driving risk level signal provided by the driving risk acquisition module 100, and send the instruction data and risk level signal together to the intent priority judgment module 400.

[0046] Furthermore, the intent priority judgment module 400 pre-stores the instruction priority rule base and receives standardized instruction data and driving risk level signals from the Android Framework layer instruction interception service module 300, and first determines the instruction type.

[0047] Specifically, the intent priority determination module 400 extracts the instruction content field from the standardized instruction data and matches it with instruction keywords in a preset rule base. It then combines this with the instruction type field and the data acquisition device source field to classify the scenario, thereby obtaining the instruction type. Subsequently, the intent priority determination module 400 determines the response strategy according to the instruction priority rules based on the current driving risk level and instruction type, and the response strategy is executed by the vehicle application or system components.

[0048] Furthermore, the system resource limiting module 500 is communicatively connected to the Android Framework layer instruction interception service module 300 and interacts with the underlying Android system through the resource management application programming interface. The system resource limiting module 500 is used to obtain the current driving risk level and dynamically adjust the resource allocation rules of entertainment applications according to the driving risk level. The resource allocation rules include CPU utilization limits, memory allocation limits, rendering frame rate limits, bus bandwidth utilization limits, and background running limit limits.

[0049] Specifically, the system resource limiting module 500 limits CPU usage by calling the Android system's control group mechanism, limits memory usage through the activity manager service interface, limits rendering frame rate through the surface frame rate service interface, limits bus bandwidth usage through the controller LAN flexible data rate bus scheduling module, and forcibly terminates background entertainment application processes that exceed the limit through the package manager and activity manager. Thus, in high-risk scenarios, the system resource limiting module 500 proactively reclaims system resources occupied by entertainment applications, reserving sufficient computing power and memory for the advanced driver assistance system.

[0050] Through the above vehicle control system architecture, this application can realize unified interception of multimodal commands, risk linkage decision-making, and dynamic resource management at the framework layer of the vehicle Android system.

[0051] As attached Figure 2 As shown in the schematic embodiment of the vehicle control method, vehicle, and electronic device of this application, the vehicle control method includes the following steps.

[0052] Preferably, this method first performs an initialization operation to ensure that each module works normally. The driving risk acquisition module 100 establishes a communication connection with the advanced driver assistance system through the controller area network bus to ensure real-time reception of driving risk level signals; the Android Framework layer instruction interception service module 300 starts in the system service (SystemServer) process of the in-vehicle Android system and registers the Binder cross-process communication interface to interact with other modules; the multimodal input acquisition module 200 initializes the connection of in-vehicle hardware devices, specifically including microphone arrays, touch screen controllers, cockpit cameras, steering wheel physical buttons, and central control physical buttons, to ensure that multimodal commands from the driver can be acquired.

[0053] Acquire environmental perception data, navigation data, vehicle driving data, and driver data.

[0054] Preferably, the environmental perception data mainly refers to the dynamic and static environmental information around the vehicle, which is collected by the on-board environmental perception sensor.

[0055] Specifically, environmental perception data includes, but is not limited to, distance to the vehicle in front, lane deviance, approach speed of the vehicle behind, distance to vehicles to the side, and obstacle type. Among them, the distance to the vehicle in front is collected by the forward-view camera and is measured in meters; the closer the distance to the vehicle in front, the higher the risk. The lane line deviation is collected by the forward-view camera and is measured in centimeters; the greater the lane line deviation, the more serious the vehicle deviates from its lane. The approach speed of the vehicle behind is collected by millimeter-wave radar and is measured in kilometers per hour; the faster the approach speed of the vehicle behind, the higher the risk of a rear-end collision. The distance to vehicles on the side is collected by millimeter-wave radar and is measured in meters; the closer the distance to vehicles on the side, the higher the risk of lane changing or collision. The type of obstacle is identified through the fusion of camera and radar, including pedestrians, vehicles, or fixed obstacles.

[0056] Furthermore, navigation data mainly refers to the macroscopic driving environment information of the vehicle's current location, which is obtained through the in-vehicle navigation system and high-precision maps.

[0057] Specifically, navigation data includes, but is not limited to, road type, traffic congestion level, and special scene markers.

[0058] The road types include highways, urban roads, or suburban roads; the traffic congestion levels include smooth traffic, slow traffic, or congestion; and special scene markers include construction sections, ramps, or tunnels.

[0059] Furthermore, vehicle driving data mainly refers to the vehicle's own motion status information, which is collected in real time through vehicle status sensors.

[0060] Specifically, vehicle driving data includes, but is not limited to, real-time vehicle speed, braking intensity, and steering wheel angle.

[0061] Among them, the real-time vehicle speed is collected by the vehicle speed sensor, and its unit is kilometers per hour; the braking intensity is collected by the brake pedal travel sensor, and its unit is percentage; the steering wheel angle is collected by the steering angle sensor, and its unit is degrees.

[0062] Furthermore, driver data mainly refers to the driver's facial expression and attention information, which is collected through the driver monitoring system.

[0063] Specifically, driver data includes, but is not limited to, the driver's blinking frequency, facial orientation, and area of ​​focused gaze.

[0064] Among them, blink frequency is collected by the driver monitoring camera and is measured in times per minute; facial orientation includes looking straight ahead, looking to the side, or looking down; the area of ​​focus of the gaze includes the road or the central control screen.

[0065] Based on environmental perception data, navigation data, vehicle driving data, and driver data, a driving risk level is obtained through a pre-set multi-dimensional risk assessment strategy.

[0066] In some embodiments, such as Figure 3As shown, the steps for determining the driving risk level specifically include the following steps S21-S24.

[0067] S21: Quantify and score each parameter in the environmental perception data, navigation data, vehicle driving data, and driver data to obtain the individual risk score for each parameter.

[0068] Preferably, the quantitative scoring refers to mapping the original measured values ​​of each parameter to a risk score between 0 and 100, with a higher score indicating a greater risk posed by that parameter. For continuous parameters, a piecewise linear function is used for mapping; for discrete parameters, a discrete mapping table is used.

[0069] Furthermore, the individual risk score function is defined as follows: for any parameter Its risks follow When the value increases and the value increases, the mapping formula is:

[0070] in and These are the safety threshold and danger threshold for the parameter, respectively. For parameters where the risk decreases as the parameter increases (such as distance to the vehicle ahead), a decreasing linear interpolation is used:

[0071] Taking specific parameters as an example, distance to the vehicle in front Pick , ,when hour ,when hour , intermediate linear interpolation.

[0072] Speed Pick , ,when hour ,when hour .

[0073] Braking strength Pick , .

[0074] Duration of closing eyes Pick , Other continuous parameters are handled similarly.

[0075] For discrete parameters such as obstacle type, the mapping is 0 when there is no risk and 100 when pedestrians or vehicles are present; road type is mapped as suburban 0 points, urban road 30 points, expressway 60 points, and construction section 100 points respectively; traffic congestion level is mapped as smooth 0 points, slow traffic 50 points, and congested 100 points.

[0076] By uniformly mapping raw sensor data of different dimensions and types to quantitative risk scores, this application solves the problem of direct comparison and fusion of multi-source heterogeneous data. For continuous parameters, a piecewise linear function is used to smoothly reflect the continuous impact of parameter changes on risk, avoiding score jumps caused by threshold abrupt changes. For discrete parameters, a discrete mapping is used to assign reasonable risk weights. Thus, this application achieves normalization of the risk contribution of each parameter, providing a unified, comparable, and calculable input basis for subsequent multi-dimensional comprehensive assessment, improving the accuracy and real-time performance of risk assessment.

[0077] S22: Calculate the environmental perception score, scene recognition score, vehicle status score, and driver status score based on the individual risk scores.

[0078] Preferably, the score for each dimension is the maximum value of the individual risk scores of all parameters under that dimension, in order to highlight the most serious risk factors.

[0079] Furthermore, the environmental perception parameter set is as follows: The environmental perception score is the maximum value of all individual risk scores in the environmental perception parameter set, denoted as... .

[0080] Scene recognition parameter set is The scene recognition score is the maximum value of all individual risk scores in the parameter set, denoted as . .

[0081] The vehicle state parameter set is The vehicle status score is the maximum value of all individual risk scores in the parameter set, denoted as . .

[0082] Driver status parameter set The driver status score is the maximum value of all individual risk scores in the parameter set, denoted as . .

[0083] By taking the maximum risk score for each parameter across all dimensions as the score for that dimension, the most severe risk factors in each dimension can be highlighted, avoiding the obscuring of single-point fatal risks by averages or weighted averages. For example, even if other environmental parameters are normal, the environmental perception score can still reflect high risk if the distance to the vehicle ahead is extremely close; similarly, even if other conditions are normal, the driver's state score can still detect danger if the driver's eye-closing time exceeds the limit. Taking the maximum value method aligns with the weakest link effect and single-point trigger principle in driving safety, ensuring that any parameter reaching a high-risk threshold can be identified promptly. This provides the most sensitive risk trigger conditions for subsequent command interception and resource management, maximizing driving safety.

[0084] S23: The environmental perception score, scene recognition score, vehicle status score, and driver status score are weighted and summed based on preset weights to obtain a comprehensive risk score.

[0085] Preferably, the preset weights are set according to the degree of influence of each dimension on driving safety, wherein the environmental perception dimension has a weight of 40%, the vehicle state dimension has a weight of 30%, the driver state dimension has a weight of 15%, and the scene recognition dimension has a weight of 15%.

[0086] Furthermore, the comprehensive risk score The calculation formula is:

[0087] Calculated The range is from 0 to 100 points.

[0088] It should be noted that the preset weights are not limited to the specific values ​​mentioned above. They can be adjusted according to different vehicle models, driving environments, or safety strategies. For example, the weight of the vehicle state dimension can be appropriately increased in sporty vehicles, or the weight of the scene recognition dimension can be increased in complex urban road scenarios to achieve adaptive risk assessment.

[0089] By assigning differentiated weights to different risk dimensions, the varying contributions of each dimension to driving safety can be objectively reflected. The weighted summation method integrates risk factors from multiple dimensions, avoiding misjudgments based on a single dimension while ensuring that high-risk dimensions dominate the overall score. Therefore, this application achieves a comprehensive and balanced assessment of driving risks, preventing false triggers due to occasional fluctuations in a single parameter and ensuring that the cumulative effects of serious risks are not overlooked. This provides accurate and reliable risk quantification for subsequent command interception and resource management.

[0090] S24: Compare the comprehensive risk score with the preset risk level classification threshold to obtain the driving risk level; where the driving risk level includes high risk level, medium risk level and low risk level.

[0091] Driving risk level is used to characterize the overall level of danger in the current driving scenario, providing a basis for subsequent command interception and resource management.

[0092] Preferably, the preset risk level classification thresholds include a high-risk threshold of 80 points and a medium-risk threshold of 40 points.

[0093] Furthermore, driving risk level The judgment is as follows:

[0094] The advanced driver assistance system performs the above calculations in real time and outputs the resulting driving risk level in the form of a digital signal, such as a high risk level corresponding to the number 3, a medium risk level corresponding to the number 2, and a low risk level corresponding to the number 1, so that subsequent modules can quickly identify and use it.

[0095] It should be noted that the risk level classification thresholds are not limited to the above thresholds. They can be adjusted according to the safety calibration of different vehicle models, driving habits in different regions, or different regulatory requirements. For example, the high-risk threshold can be appropriately increased in sports vehicles to allow for more aggressive driving behavior, or the medium-risk threshold can be lowered in the elderly driver mode to provide early warning.

[0096] S3: Collect driver multimodal commands, determine the command type of the driver multimodal commands, and obtain the driver command type.

[0097] In some embodiments, such as Figure 4 As shown, collecting driver multimodal commands includes the following steps S31-S32.

[0098] S31: Collect driver multimodal commands and encapsulate the driver multimodal commands into standardized command data.

[0099] Preferably, the driver's multimodal commands include one or more of the following: voice commands, touch commands, gesture commands, physical button commands, and gaze commands, which are collected through corresponding in-vehicle hardware devices.

[0100] Furthermore, voice commands are collected from the driver's voice information via an in-vehicle microphone array and converted into text commands by a voice recognition chip.

[0101] Touch commands are collected by the touch sensor on the central control screen, such as click, swipe, or long press.

[0102] Gesture commands are captured by the cockpit's built-in camera, which captures preset dynamic gestures, such as waving to adjust the volume or clenching a fist to pause playback. These gestures are then interpreted into commands by an image recognition algorithm.

[0103] Physical button commands are triggered by the steering wheel buttons or the central control physical buttons, such as pressing a button to start navigation.

[0104] The gaze command is determined by capturing the driver's gaze point through the driver monitoring camera and combining the gaze duration. For example, if the gaze is focused on the entertainment screen for more than 1.5 seconds, it is determined as a command to view entertainment content.

[0105] Furthermore, the multimodal input acquisition module encapsulates the acquired raw instruction data into standardized instruction data.

[0106] Specifically, standardized instruction data can be in JSON format, including instruction type field, instruction content field, timestamp field, data acquisition device source field, and priority field.

[0107] The instruction type information field identifies the input modality of the instruction, such as voice, touch, gesture, physical button, or gaze; the instruction content information field stores the specific instruction semantics or operation data, such as speech-recognized text, touch coordinates, or gesture identifiers; the timestamp information field records the millisecond-level time of instruction acquisition; the device source field identifies the hardware device that acquired the instruction, such as a microphone, touchscreen, camera, or button; and the priority field identifies the default priority of the instruction, such as high priority, normal priority, or low priority.

[0108] For example, standardized instruction data can be represented in the following format: { "instructionType": "voice", / / Instruction type: voice / touch / gesture / key / vision "content": "Open video", / / Instruction content (text / operation coordinates / gesture identifier) ​​"timestamp": 1712345678901, / / Capture timestamp (milliseconds) "deviceSource": "microphone", / / Capture device: microphone / touchScreen / camera / steeringKey / dmsCamera "priority": "normal" / / Default instruction priority: high / normal / low} It should be noted that the names and specific formats of the above fields can be adjusted according to the system design, as long as they can uniquely identify the type, content, and source of the instruction. Through this standardized encapsulation method, instructions of different modalities are unified into the same data structure, which facilitates unified parsing and processing by subsequent modules.

[0109] S32: The standardized instruction data is transmitted to the framework layer, and the instruction interception service module deployed in the framework layer intercepts the standardized instruction data.

[0110] Preferably, the multimodal input acquisition module 200 transmits standardized instruction data to the Android Framework layer instruction interception service module 300 via the Binder inter-process communication mechanism. A cyclic redundancy check (CRC) code is appended during transmission to ensure data integrity; the receiving end uses this check code to verify whether the data has been tampered with or lost.

[0111] Furthermore, the Android Framework layer instruction interception service module 300 is deployed in the system service process of the in-vehicle Android system, located before the input dispatch component. Internally, it maintains an instruction cache queue, with a queue length of, for example, ten lines. When the queue is full, newly arriving standardized instruction data discards the earliest instruction according to its timestamp to ensure system real-time performance and controllable resource consumption.

[0112] The Android Framework layer instruction interception service module 300 is used to intercept all standardized instruction data transmitted by the multimodal input acquisition module in real time, and after interception, it synchronously obtains the current driving risk level signal provided by the driving risk acquisition module 100, and sends the instruction data and risk level signal together to the intent priority judgment module 400 to provide input for subsequent instruction type determination and response strategy determination.

[0113] Through the aforementioned transmission and interception mechanisms, this application is able to uniformly obtain driver instructions from all modes at the operating system level, avoiding the risk that application-layer interception may be bypassed, and providing reliable underlying protection for proactive instruction interception.

[0114] In some embodiments, such as Figure 5 As shown, the step of determining the driver's multimodal commands and obtaining the driver's command type includes the following steps S41-S43.

[0115] S41: Extract instruction content field, instruction type field, and acquisition device source field based on standardized instruction data.

[0116] Preferably, after the multimodal input acquisition module 200 transmits the standardized instruction data to the Android Framework layer instruction interception service module 300, it first parses the standardized instruction data and extracts the instruction content field, instruction type field, and acquisition device source field from it.

[0117] For example, for the voice command "Open video", the extracted command content field is "Open video", the command type field is "voice", and the acquisition device source field is "microphone". For the touch command, the command content field is touch coordinates, the command type field is "touch", and the acquisition device source field is "touchscreen".

[0118] S42: Match the instruction content field with the instruction keywords in the preset rule base to obtain the matched instruction keywords.

[0119] Preferably, the preset rule base stores multiple instruction keywords and their corresponding instruction categories in advance. The Android Framework layer instruction interception service module 300 performs semantic matching or keyword matching between the extracted instruction content fields and the instruction keywords in the rule base to determine the instruction keywords corresponding to the user's intent.

[0120] Furthermore, the matching methods include exact matching, synonym matching, or fuzzy matching based on edit distance. For example, when the instruction content field is "I want to watch a movie," it can match the keyword "open video" in the rule base; when the instruction content field is "turn the volume down," it can match the keyword "adjust volume." If the match is successful, the matched instruction keyword is obtained; if the match fails, the instruction is marked as an abnormal instruction.

[0121] S43: Based on the instruction type field and the data acquisition device source field, the matched instruction keywords are classified into scenarios to obtain the driver instruction type; among them, the driver instruction type includes safety instructions, vehicle control instructions and entertainment instructions.

[0122] Preferably, after obtaining the matching instruction keywords, the instruction is further confirmed and the scenario is classified by combining the instruction type field and the data acquisition device source field to eliminate the ambiguity that a single field may cause, and finally determine the driver instruction type.

[0123] Furthermore, the scene classification rules are as follows: When the matched instruction keywords belong to the safety instruction category, such as "brake", "navigation avoidance", "turn on hazard lights", or "emergency call", they are classified as safety instructions regardless of the instruction type or the data collection device.

[0124] When the matched command keywords belong to the vehicle control command category, such as "adjust the air conditioning", "adjust the seat", "switch driving mode", "adjust the rearview mirror", if the command type field is voice or physical button, and the data collection device source is a microphone or steering wheel button, it is classified as a vehicle control command; if the command type field is touch or line of sight, it may be judged as an invalid command or requires further confirmation.

[0125] When the matched instruction keywords belong to the entertainment instruction category, such as "open video", "play music", "adjust volume", "open game", if the instruction type field is voice, touch or gaze, and the data collection device source is a microphone, touch screen or driver monitoring camera, then it is classified as an entertainment instruction; if the instruction type field is a physical button but the button function is not related to entertainment, then it is re-evaluated.

[0126] Through the above methods, this application can accurately distinguish between safety commands, vehicle control commands, and entertainment commands, providing reliable input for subsequent differentiated responses based on risk levels.

[0127] S2: At the framework layer, the driver's command type is analyzed according to the preset command priority rules to determine whether the response strategy for each type of driver multimodal command is to allow passage.

[0128] In some embodiments, preset instruction priority rules are stored in the framework layer in the form of a configurable rule base.

[0129] Preferably, the rule base is stored in a structured configuration file, such as in Extensible Markup Language format, in a directory specified by the system, which facilitates subsequent updates and upgrades.

[0130] In some embodiments, the instruction priority rule is as follows: When the driver's instruction type is a safety instruction, the response strategy is to allow passage.

[0131] Preferably, safety commands refer to operations directly related to vehicle driving safety, such as braking, navigation avoidance, activating hazard lights, or emergency calls. Regardless of whether the current driving risk level is low, medium, or high, the system unconditionally allows and prioritizes execution, ensuring that the driver can take timely evasive action in emergency situations.

[0132] By unconditionally releasing all levels of safety commands, the driver's emergency control over the vehicle can be guaranteed in any risk scenario, avoiding obstruction of evasive maneuvers due to command interception or delay, thereby minimizing the possibility of accidents and improving driving safety.

[0133] When the driver's command type is a vehicle control command, if the driving risk level is low, the response strategy is to release; if the driving risk level is medium, the response strategy is to delay release; if the driving risk level is high, the response strategy is to temporarily store the command until the driving risk level decreases before releasing.

[0134] Preferably, the vehicle control commands include non-emergency vehicle control operations such as adjusting the air conditioning, adjusting the seat, switching driving modes, and adjusting the rearview mirrors.

[0135] When the risk level is low, the system immediately grants permission to ensure smooth interaction.

[0136] At medium risk levels, the system will temporarily store the instructions and execute them after a preset delay time, such as 300 milliseconds, to avoid distracting the driver's attention with immediate operations.

[0137] When the risk level is high, the system will temporarily store the instruction and continuously monitor the driving risk level. The instruction will be executed only after the risk level is reduced to medium or low risk, so as not to lose the user's operating intention or interfere with the driving focus in high-risk scenarios.

[0138] By differentiating responses to vehicle control commands based on risk levels, the system effectively reduces driver distraction caused by operating unnecessary vehicle control functions in medium- and high-risk scenarios. At the same time, it preserves user operational needs through delayed execution or temporary execution mechanisms, thus balancing driving safety and operational convenience.

[0139] When the driver's instruction type is entertainment instruction, if the driving risk level is low, the response strategy is to allow passage; if the driving risk level is medium, the response strategy is to partially allow passage; if the driving risk level is high, the response strategy is to intercept.

[0140] Preferably, entertainment commands include opening videos, playing music, adjusting volume, and launching games. At low risk levels, the system allows all entertainment commands, providing a complete entertainment experience. At medium risk levels, the system allows only light entertainment commands, such as adjusting volume, while blocking heavy entertainment commands, such as opening videos or games. At high risk levels, the system completely blocks all entertainment commands, prohibiting any entertainment operations.

[0141] In addition, when the driver's instruction type is other, if the driving risk level is low, the response strategy is to release; if the driving risk level is medium or high, the response strategy is to delay release, and if the driving risk level escalates during the delay, it will switch to interception.

[0142] Preferably, other instructions refer to instructions that are not safety instructions, vehicle control instructions, or entertainment instructions, such as viewing notifications, setting alarms, and other non-emergency, non-entertainment, and non-vehicle control auxiliary function operations.

[0143] When the risk level is low, the system immediately grants permission to ensure convenient interaction.

[0144] At medium or high risk levels, the system will temporarily store the instruction and execute it after a preset delay, such as 500 milliseconds. During the delay, the system continuously monitors the driving risk level. If the risk level escalates further, the instruction will be blocked and execution prohibited; if the risk level does not escalate or decreases, execution will be allowed after the delay ends.

[0145] By implementing risk-based control of entertainment commands, this application completely blocks entertainment operations from the ground up in high-risk scenarios, preventing accidents caused by drivers being distracted by entertainment functions; in medium-risk scenarios, it retains necessary light operations, such as volume adjustment, which satisfies users' reasonable needs while limiting high-risk entertainment behaviors; and in low-risk scenarios, it ensures complete entertainment functions, achieving a reasonable balance between driving safety and interactive experience.

[0146] S3: If yes, then send the driver's multimodal instructions to the application layer; otherwise, intercept the driver's multimodal instructions.

[0147] In some embodiments, the following corresponding operations are performed according to different response strategies.

[0148] When the response policy is to allow passage, the driver's multimodal instructions are sent to the corresponding application or system component at the application layer for execution.

[0149] Preferably, the Android Framework layer instruction interception service module 300 distributes standardized instruction data to the target application through the input dispatch component.

[0150] When the response strategy is to block, a prompt message is output through the human-machine interface, and the execution of driver multimodal commands is prohibited.

[0151] Preferably, after receiving the interception signal sent by the intent priority judgment module 400, the human-machine interface generates corresponding prompt information based on the current driving risk level and instruction type.

[0152] As shown in Table 1, the following are examples of prompt messages corresponding to different risk levels and instruction types.

[0153]

[0154] Table 1. Interception Prompt Message Mapping Table In addition, all prompts follow the principles of simplicity and non-interference with driving. Text prompts are displayed for no more than two seconds, and voice prompts are displayed for no more than 1.5 seconds. They also do not generate pop-ups that obstruct the driver's view, thus informing the user of the reason for the interception while avoiding additional distraction.

[0155] When the response strategy is delayed release, the driver's multimodal commands are temporarily stored and then issued for execution after a preset delay time.

[0156] Preferably, delayed release is mainly applied to vehicle control commands or other commands under medium-risk levels. The Android Framework layer command interception service module 300 stores standardized command data in its internal cache queue and starts a timer with a preset delay time, for example, 300 milliseconds for vehicle control commands and 500 milliseconds for other commands.

[0157] During the delay period, if the driving risk level does not increase, the Android Framework layer instruction interception service module 300 will perform the release operation after the timer is triggered; if the risk level increases during the delay period, the instruction can be temporarily stored before release or directly intercepted to ensure safety first.

[0158] When the response strategy is to temporarily store the driver's multimodal commands until the driving risk level decreases, the driver's multimodal commands will be temporarily stored, and the driving risk level will be monitored. Once the driving risk level decreases, the commands will be issued and executed.

[0159] Preferably, this strategy is mainly applied to vehicle control commands under high-risk levels. The Android Framework layer command interception service module 300 stores the commands in a persistent cache and continuously monitors the current risk level signal through the driving risk acquisition module 100.

[0160] When the risk level decreases from high to medium or low, the Android Framework layer instruction interception service module 300 automatically retrieves the temporarily stored instructions and performs a release operation. If the user actively cancels the instruction or the instruction times out during the storage period, the instruction can be discarded to avoid unnecessary resource consumption.

[0161] When the response strategy is partial release, the executable part of the driver's multimodal instruction is parsed, and only the executable part is sent to the corresponding application or system component for execution.

[0162] Preferably, partial release is mainly applied to entertainment commands at the medium-risk level. The Android Framework layer command interception service module 300 first performs semantic parsing on the standardized command data to identify executable and non-executable sub-items in the command.

[0163] For example, if a user commands "open the video and turn the volume up to 50%", the system will determine that "open the video" is a heavy entertainment command and block it, while "adjust the volume" is a light entertainment command and will be allowed. Ultimately, only the volume adjustment command will be issued and executed, while the video opening command will be discarded and optionally prompted by the human-computer interaction interface. Through this fine-grained control, this application retains necessary light interactions in medium-risk scenarios while effectively limiting high-risk entertainment behaviors.

[0164] In some embodiments, the vehicle control method provided in this application further includes a resource limiting step, which is executed in parallel with the instruction interception step, and is used to dynamically adjust the resource consumption of entertainment applications according to the driving risk level to achieve passive risk rollback.

[0165] Preferably, the resource restriction step includes implementing resource restrictions on entertainment applications based on driving risk levels; Resource restrictions include at least one of the following: limiting CPU utilization, limiting memory usage, limiting rendering frame rate, limiting bus bandwidth usage, and limiting the number of background processes.

[0166] Preferably, the system resource restriction module 500 automatically executes differentiated resource restriction rules based on the current driving risk level.

[0167] As shown in Table 2, examples of resource restriction rules corresponding to different risk levels are as follows.

[0168]

[0169] Table 2. Mapping Table of Risk Levels and Resource Constraint Rules Furthermore, the system resource limiting module 500 implements the above resource limiting in the following ways: Regarding CPU utilization, an independent control group is assigned to entertainment applications through the Android system's control group mechanism. The thread priority setting interface is called to set the thread priority to the background. Combined with the CPU core binding function, entertainment applications are only allowed to use one CPU core in high-risk situations.

[0170] Regarding memory usage, a maximum memory threshold is set for entertainment applications through the Activity Manager service interface. When the threshold is exceeded, the system's least recently used cache reclamation mechanism is triggered to prioritize releasing the memory occupied by entertainment applications.

[0171] Regarding the rendering frame rate, the surface rendering frame rate of entertainment applications can be directly limited through the surface frame rate service interface to avoid excessive consumption of graphics processor resources.

[0172] Regarding bus bandwidth usage, the Controller Area Network (CAN) Flexible Data Rate Bus Scheduling Module allocates bandwidth based on priority, setting Advanced Driver Assistance System (ADAS) signals to the highest priority and limiting the proportion of entertainment data transmitted on the bus.

[0173] To determine the number of background applications, obtain the package names of all entertainment applications through the package manager, and then call the activity manager to forcibly terminate background entertainment application processes that exceed the limit.

[0174] Through the aforementioned resource restriction rules and implementation methods, this application can dynamically adjust the resource consumption of entertainment applications based on the driving risk level. In high-risk scenarios, it proactively reclaims critical resources such as the central processing unit, memory, graphics processing unit, and bus bandwidth occupied by entertainment applications, reserving sufficient computing and communication resources for the advanced driver assistance system (ADAS), avoiding intelligent driving response delays caused by resource contention, and ensuring the real-time performance and reliability of the intelligent driving system. Simultaneously, in low- to medium-risk scenarios, entertainment functions are appropriately retained, achieving a dynamic balance between driving safety and user experience. The resource restriction steps, together with the aforementioned command interception steps, constitute a dual security mechanism of proactive command interception and passive resource rollback, comprehensively covering the security requirements in high-risk scenarios.

[0175] This application provides a vehicle, including a controller, which is used to implement the vehicle control method as described above.

[0176] Combination Figure 6 As shown, this embodiment discloses a specific implementation of a computer device. The computer device may include a processor 41 and a memory 42 storing computer program instructions.

[0177] Specifically, the processor 41 may include a central processing unit (CPU), an application specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of this application.

[0178] The memory 42 may include a large-capacity storage device for data or instructions. For example, and not limitingly, the memory 42 may include a hard disk drive (HDD), a floppy disk drive, a solid-state drive (SSD), flash memory, an optical disk drive, a magneto-optical disk drive, magnetic tape, or a Universal Serial Bus (USB) drive, or a combination of two or more of these. Where appropriate, the memory 42 may include removable or non-removable (or fixed) media. Where appropriate, the memory 42 may be internal or external to the data processing device. In a particular embodiment, the memory 42 is non-volatile. Volatile memory. In a particular embodiment, memory 42 includes read-only memory. ROM (ROM-only memory) and RAM (Random Access Memory). Where appropriate, the ROM can be a mask-programmed ROM or a programmable ROM. Only Memory (PROM) and Erasable Programmable Read-Only Memory (EPRROM) The RAM can be a type of RAM, such as EPROM (Electrically Erasable Programmable Read-Only Memory), EEPROM (Electrically Erasable Programmable Read-Only Memory), EAROM (Electrically Alterable Read-Only Memory), or FLASH (Flash Memory), or a combination of two or more of these. Where appropriate, the RAM can be a Static Random Access Memory (SRAM). Access Memory (SRAM) or Dynamic Random Access Memory (DRAM) can be Fast Page Mode Dynamic Random Access Memory (FPMDRAM), Extended Data Out Dynamic Random Access Memory (EDODRAM), Synchronous Dynamic Random-Access Memory (SDRAM), etc.

[0179] The memory 42 can be used to store or cache various data files that need to be processed and / or used for communication, as well as possible computer program instructions executed by the processor 41.

[0180] The processor 41 implements the vehicle control method in the above embodiments by reading and executing computer program instructions stored in the memory 42.

[0181] In some embodiments, the computer device may further include a communication interface 43 and a bus 40. For example, Figure 6 As shown, the processor 41, memory 42, and communication interface 43 are connected through bus 40 and complete communication with each other.

[0182] Communication interface 43 is used to enable communication between modules, devices, units and / or equipment in the embodiments of this application.

[0183] Communication port 43 can also enable data communication with other components such as external devices, image / data acquisition devices, databases, external storage, and image / data processing workstations.

[0184] Bus 40 includes hardware, software, or both, that couples components of a computer device together. Bus 40 includes, but is not limited to, at least one of the following: a data bus, an address bus, a control bus, an expansion bus, and a local bus. For example, and not as a limitation, bus 40 may include an Accelerated Graphics Port (AGP) or other graphics bus, an Extended Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), a Hyper Transport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an InfiniBand interconnect, a Low Pin Count (LPC) bus, a memory bus, a Micro Channel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, and a PCI bus. Express (PCI The bus may be an X-bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local Bus (VLB) bus, or other suitable buses, or a combination of two or more of these. Where appropriate, bus 40 may include one or more buses. Although specific buses are described and illustrated in embodiments of this application, this application contemplates any suitable bus or interconnect.

[0185] Furthermore, in conjunction with the vehicle control methods in the above embodiments, this application embodiment can provide a computer-readable storage medium for implementation. This computer-readable storage medium stores computer program instructions; when these computer program instructions are executed by a processor, they implement any of the vehicle control methods in the above embodiments.

[0186] The present invention provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the above-described vehicle control method.

[0187] The present invention provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the above-described vehicle control method.

[0188] Although embodiments of the invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the invention. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of the invention.

Claims

1. A vehicle control method, characterized in that, It is applied to in-vehicle infotainment systems, which include a framework layer and an application layer, and includes: Collect driver multimodal commands, determine the command type of the driver multimodal commands, and obtain the driver command type; In the framework layer, the driver command types are analyzed according to preset command priority rules to determine whether the response strategy for each type of driver multimodal command is to allow passage. If so, the driver multimodal command is sent to the application layer; otherwise, the driver multimodal command is intercepted.

2. The vehicle control method according to claim 1, characterized in that, The analysis of the driver's command type according to the preset command priority rules includes analysis in conjunction with the driving risk level, which is determined through the following steps: Acquire environmental perception data, navigation data, vehicle driving data, and driver driving data; Each parameter in the environmental perception data, navigation data, vehicle driving data, and driver data is quantitatively scored to obtain a single risk score for each parameter; Based on the individual risk scores, calculate the environmental perception score, scene recognition score, vehicle status score, and driver status score respectively. The environmental perception score, scene recognition score, vehicle status score, and driver status score are weighted and summed based on preset weights to obtain a comprehensive risk score. The comprehensive risk score is compared with a preset risk level classification threshold to obtain the driving risk level; wherein the driving risk level includes high risk level, medium risk level and low risk level.

3. The vehicle control method according to claim 2, characterized in that, The collection of driver multimodal commands includes: Collect the driver's multimodal commands and encapsulate them into standardized command data; The standardized instruction data is transmitted to the framework layer, and the instruction interception service module deployed in the framework layer intercepts the standardized instruction data.

4. The vehicle control method according to claim 3, characterized in that, The step of determining the command type of the driver's multimodal commands to obtain the driver command type includes: Based on the standardized instruction data, extract the instruction content field, instruction type field, and acquisition device source field; The matching instruction keywords are obtained by matching the instruction content field with the instruction keywords in the preset rule base. Based on the instruction type field and the acquisition device source field, the matched instruction keywords are classified into scenarios to obtain the driver instruction type; The types of driver commands include safety commands, vehicle control commands, and entertainment commands.

5. The vehicle control method according to claim 4, characterized in that, In the framework layer, the driver command types are analyzed according to preset command priority rules to determine whether the response strategy for each type of driver multimodal command is to allow passage, including: When the driver's instruction type is the safety instruction, the response strategy is determined to be to allow passage; When the driver's instruction type is the vehicle control instruction, if the driving risk level is low, the response strategy is to release; if the driving risk level is medium, the response strategy is to delay release; if the driving risk level is high, the response strategy is to hold until the driving risk level decreases before releasing. When the driver's instruction type is an entertainment instruction, if the driving risk level is low, the response strategy is to allow passage; if the driving risk level is medium, the response strategy is to partially allow passage; if the driving risk level is high, the response strategy is to not allow passage.

6. The vehicle control method according to claim 5, characterized in that, If so, the driver multimodal command is sent to the application layer; otherwise, intercepting the driver multimodal command includes: When the response strategy is to allow passage, the driver's multimodal command is sent to the application or system component corresponding to the application layer for execution; When the response strategy is to not allow passage, the driver's multimodal command is intercepted, and an interception prompt message is output through the human-machine interface; When the response strategy is delayed release, the driver's multimodal command is temporarily stored and executed after a preset delay time; When the response strategy is to temporarily store the driver's multimodal commands until the driving risk level is reduced, the driver's multimodal commands are temporarily stored, the driving risk level is monitored, and the commands are issued and executed after the driving risk level is reduced. When the response strategy is partial release, the executable part of the driver's multimodal instruction is parsed, and only the executable part is sent to the application or system component corresponding to the application layer for execution.

7. The vehicle control method according to claim 1, characterized in that, The preset instruction priority rules are stored in the framework layer in the form of a configurable rule base.

8. The vehicle control method according to claim 2, characterized in that, Also includes: Based on the aforementioned driving risk level, resource restrictions are applied to entertainment applications. The resource restrictions include at least one of the following: limiting CPU utilization, limiting memory usage, limiting rendering frame rate, limiting bus bandwidth usage, and limiting the number of background processes.

9. A vehicle, characterized in that, Includes a controller for implementing the vehicle control method as described in any one of claims 1 to 8.

10. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the vehicle control method as described in any one of claims 1 to 8.

Images