A vehicle decision-making execution determination method and device and a vehicle

Abstract

The application discloses a vehicle execution decision determination method and device and a vehicle, and relates to the technical field of vehicle control. The method comprises the following steps: in response to the vehicle being started, acquiring vehicle state information, external environment information, and a user permission level corresponding to each user in the vehicle; identifying a request instruction issued by a user, determining the instruction safety level of the request instruction; and based on at least one of the instruction safety level, the user permission level, the external environment information, and the vehicle state information, determining an execution decision corresponding to the request instruction according to a preset permission rule library. The application realizes fine data access control for different users, controls the privacy protection limit of a large model, and effectively prevents privacy leakage. In addition, the application can provide active safety perception and risk reminding capability for external environment information, utilize the networking capability of a large model in combination with navigation information, and realize active reminding of environment risks for driving safety.

Description

Technical Field

[0001] This invention relates to the field of vehicle control technology, and in particular to a method for determining vehicle execution decisions, a device for determining vehicle execution decisions, and a vehicle. Background Technology

[0002] With the rapid development of large-scale AI model technology, in-vehicle intelligent cockpits are undergoing a profound transformation from functional cockpits to AI-native cockpits. The introduction of large-scale models enables cockpit systems to achieve advanced functions such as natural language interaction, personalized recommendations, and multimodal perception, greatly enhancing the user's driving and riding experience.

[0003] To address the challenge of effectively protecting user privacy and ensuring driving safety while deeply understanding user behavior and remembering user preferences through large-scale models, related technologies propose automatically activating privacy protection when multiple passengers are detected, hiding incoming call notifications and sensitive personal data, and only displaying incoming call notifications on the instrument panel to protect the driver's privacy. This solution automatically switches privacy protection states based on the number of people in the vehicle. Alternatively, it utilizes in-vehicle cameras to capture image information and combines it with contact information from mobile devices to automatically determine the closeness between passengers and the owner (family, partner, friend, or stranger), granting different levels of functional permissions and information display permissions based on the closeness. Another approach is to support the creation of adult and child accounts, with adult accounts linked to driving habits and conversation history, and child accounts linked to adult accounts, allowing parents to restrict voice shopping functions in the rear child seat area. Finally, by integrating a confidential computing platform, the privacy protection chain extends from the device to the cloud, relying on trusted keys, remote authentication, confidential containers, and other services to ensure the secure flow of sensitive user data between mobile phones, in-vehicle systems, and the cloud.

[0004] However, there are obvious shortcomings, such as (1) the lack of a dynamic and refined hierarchical permission system for privacy protection. Existing solutions generally adopt a coarse-grained hierarchical system of binary (privacy mode on / off) or ternary (high / medium / low level of intimacy), lacking a systematic hierarchical standard based on the sensitivity of data. For example, the privacy switch is triggered only by the number of people in the car, which cannot distinguish the sensitivity level of different data (such as travel trajectory vs. entertainment records). Existing technologies have not established a systematic user permission level (such as root permission, administrator, standard user, etc.), which makes it impossible to achieve differentiated data access control; the data access isolation mechanism between different user permissions is not perfect, for example, the privacy boundary between multiple administrators is blurred.

[0005] (2) The voice operation of intelligent systems lacks dynamic permission control based on vehicle status. Existing voice control solutions generally suffer from "confusing permission logic," with voice assistants being granted excessive operating permissions while the vehicle is in motion. Recent frequent safety accidents in the industry have fully exposed this deficiency. When a driver issued the command "turn off reading lights" while driving at high speed at night, the vehicle system misinterpreted it as "turn off all lights," causing the headlights to turn off instantly, and the vehicle crashed into the guardrail in the dark. The root cause of the accident was that the intelligent system did not set permission restrictions based on vehicle status for core driving safety functions such as headlights, and lacked a secondary confirmation mechanism. The industry generally lacks a multi-dimensional operation permission determination mechanism based on vehicle status (driving / parking / vehicle speed), external environment (weather / light), and user characteristics (child / adult).

[0006] (3) Large-scale models lack the ability to proactively perceive and warn about risks related to external environmental information. Existing large-scale model security solutions mainly focus on content security review (such as the AI ​​safety guardrail solution of Zebra Smart Mobility and Alibaba Cloud), but lack the ability to perceive and proactively warn about external environmental information in real time. Although large-scale models can obtain navigation information and weather data through the Internet, they fail to deeply integrate this information with driving safety scenarios. For example, they cannot proactively push driving safety reminders to users based on real-time road conditions and weather conditions (such as driving cautiously on mountain roads in rainy weather, one-way lane reminders, etc.), and they also lack a mechanism to incorporate external environmental information into the operation permission judgment.

[0007] (4) Lack of a unified "security sandbox" framework. In existing technologies, privacy protection, operational security, and environmental alerts are usually implemented as independent modules, lacking a unified "security sandbox" framework to coordinate and manage the security boundaries of large models in different scenarios. This decentralized architecture leads to: a lack of correlation mapping between permission policies and data hierarchies; operational permission determination cannot fully utilize environmental awareness information; and system security policies are difficult to maintain and dynamically adjust in a unified manner.

[0008] (5) Lack of emergency privacy protection mechanisms to deal with network attacks and location tracking. Existing smart cockpit systems generally rely on continuous network connectivity to achieve functions such as navigation, voice assistant, and online entertainment, but this also brings serious privacy and security risks. Once the in-vehicle system is penetrated by hackers through the network, attackers can remotely obtain sensitive data such as the vehicle's real-time location, driving trajectory, and in-vehicle conversations, and may even control some functions of the vehicle. Current mainstream cockpit systems lack an emergency mechanism to cut off all network connections with one click, and users cannot quickly isolate the vehicle from network communication with the outside world when they discover an anomaly. Continuous vehicle network connectivity means that location information is continuously uploaded to the cloud. For privacy-conscious users (such as those at risk of being tracked, employees in sensitive positions, etc.), existing systems do not provide a convenient switch to temporarily shut down all network communication and stop location reporting.

[0009] Furthermore, even if users manually disable certain network functions, the vehicle's infotainment system continues to record operation logs, voice interaction records, navigation history, and other data locally. These local logs may be accessed unauthorizedly when the vehicle is used or repaired by others, and lack a "one-click cleanup without leaving a trace" function, failing to meet users' needs for "traceless vehicle use." Summary of the Invention

[0010] The purpose of this invention is to provide a vehicle execution decision determination method, a vehicle execution decision determination device, an electronic device, a storage medium, and a vehicle, at least to solve a technical problem in how to construct a two-dimensional privacy permission system, restrict privacy protection, and dynamically determine operation permissions.

[0011] This invention provides the following solution:

[0012] According to one aspect of the present invention, a method for determining vehicle execution decisions is provided, comprising:

[0013] In response to the vehicle being started, obtain vehicle status information, external environment information, and the user permission level corresponding to each user in the vehicle;

[0014] The system identifies the user's request instruction and determines the instruction's security level.

[0015] Based on at least one of the instruction security level, the user permission level, the external environment information, and the vehicle status information, the execution decision corresponding to the request instruction is determined according to a preset permission rule base.

[0016] Preferably, determining the execution decision corresponding to the request instruction based on at least one of the instruction security level, the user permission level, the external environment information, and the vehicle status information, according to a preset permission rule base, includes:

[0017] In response to the request instruction being a data access request, a corresponding data access control execution policy is determined from a preset privacy sandbox policy library based on the user permission level.

[0018] or

[0019] In response to the request instruction being an operation instruction request, a corresponding operation instruction control execution strategy is determined from a preset operation permission rule base based on the user permission level, the external environment information, the instruction security level, and the vehicle status information.

[0020] Preferably, the privacy sandbox policy library includes a mapping relationship between the user permission level and the data sensitivity level; the mapping relationship is a mapping relationship between each data sensitivity level and at least one user permission level;

[0021] The operation permission rule base includes the determination rules between the user permission level, the instruction security level, the external environment information, and the vehicle status information.

[0022] Preferably, after determining the execution decision corresponding to the request instruction, the method further includes:

[0023] In response to the execution decision being permitted, the operation corresponding to the request instruction is executed;

[0024] or

[0025] In response to the execution decision being prohibited, a prohibition prompt corresponding to the request instruction is returned;

[0026] or

[0027] In response to the execution decision requiring secondary confirmation, a secondary confirmation window pops up on the vehicle's display screen.

[0028] Preferably, the method further includes:

[0029] Based on the external environment information, identify security risks and generate security alerts corresponding to the security risks.

[0030] Preferably, the step of recognizing a request instruction issued by the user and determining the instruction security level of the request instruction includes:

[0031] Determine the request type of the request instruction, and determine the instruction security level of the request instruction based on the request type.

[0032] Preferably, the method further includes:

[0033] In response to activating the privacy emergency mode, the vehicle communication management middleware interface is invoked to disconnect each wireless communication stack one by one.

[0034] Based on a preset time interval, the system will prompt the network status via voice and downgrade network-dependent functions to offline mode or unavailable mode.

[0035] Stop generating behavior logs and downgrade the security alert to a basic security alert.

[0036] Preferably, stopping the generation of behavior logs further includes:

[0037] The vehicle's display screen prompts the user whether to erase all local historical behavior logs;

[0038] In response to a user click on the control, all historical behavior logs are securely erased, and the log storage area is marked as read-only and paused.

[0039] According to a second aspect of the present invention, a vehicle execution decision determination apparatus is provided, comprising:

[0040] The information acquisition module is used to acquire vehicle status information, external environment information, and the user permission level corresponding to each user in the vehicle in response to the vehicle being started.

[0041] The instruction security level module is used to identify the request instruction issued by the user and determine the instruction security level of the request instruction;

[0042] The execution strategy determination module is used to determine the execution decision corresponding to the request instruction in a preset security sandbox engine based on at least one of the instruction security level, the user permission level, the external environment information, and the vehicle status information.

[0043] According to three aspects of the present invention, an electronic device is provided, comprising: a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus;

[0044] The memory stores a computer program, which, when executed by the processor, causes the processor to perform the steps of the vehicle execution decision determination method.

[0045] According to four aspects of the present invention, a computer-readable storage medium is provided, comprising: storing a computer program executable by an electronic device, wherein when the computer program is run on the electronic device, the electronic device performs the steps of a vehicle execution decision determination method.

[0046] According to five aspects of the present invention, a vehicle is provided, comprising:

[0047] Electronic equipment used to implement the steps of a vehicle's decision-making method;

[0048] The processor runs a program, and when the program runs, it executes the steps of the vehicle execution decision-making method based on data output from the electronic device.

[0049] A storage medium for storing a program that, when run, executes the steps of a vehicle decision-making method based on data output from an electronic device.

[0050] The above solution achieves the following beneficial technical effects:

[0051] This invention enables fine-grained data access control for different users through user permission levels and command security levels, controls the privacy protection restrictions of large models, and effectively prevents privacy leaks.

[0052] This invention determines the execution decision corresponding to the requested command in a preset security sandbox engine by considering at least one of the command security level, user permission level, external environment information, and vehicle status information, thereby realizing a dynamic operation permission determination mechanism. This mechanism automatically restricts high-risk operations (such as turning off headlights, turning off rearview mirrors, and opening doors) while the vehicle is in motion, thus avoiding safety accidents caused by voice misoperation.

[0053] This invention incorporates external environmental information into the mechanism for determining operating permissions, and can also provide proactive safety perception and risk warning capabilities for external environmental information. By utilizing large-scale model networking capabilities combined with navigation information, it can achieve proactive environmental risk warnings for driving safety. Attached Figure Description

[0054] Figure 1 This is a flowchart of a vehicle execution decision determination method provided by one or more embodiments of the present invention.

[0055] Figure 2 This is a structural diagram of a vehicle execution decision determination device provided in one or more embodiments of the present invention.

[0056] Figure 3 This is a schematic diagram of a sound source fade-in / fade-out strategy provided in a specific embodiment of the present invention.

[0057] Figure 4 This is a schematic diagram of the fade-in and fade-out process of a sound source provided in a specific embodiment of the present invention.

[0058] Figure 5 This is a schematic diagram of a head-to-tail sound source provided in a specific embodiment of the present invention.

[0059] Figure 6 This is a block diagram of an electronic device structure for a vehicle execution decision determination method provided in one or more embodiments of the present invention. Detailed Implementation

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

[0061] This invention proposes a vehicle execution decision determination method, device, and vehicle, and proposes refined privacy protection by introducing a three-dimensional judgment matrix of vehicle status, external environment, and user characteristics to achieve dynamic operation permission control. Through this dynamic operation permission determination mechanism, high-risk operations are automatically restricted while the vehicle is in motion, avoiding safety accidents caused by voice-based misoperation. The design of this embodiment fully considers the compliance requirements of national standards such as GB / T 44464-2024 "General Requirements for Automotive Data" and GB / T 45574-2025 "Security Requirements for Sensitive Personal Information Processing," as detailed below.

[0062] Figure 1 This is a flowchart of a vehicle execution decision determination method provided by one or more embodiments of the present invention.

[0063] like Figure 1 The vehicle execution decision determination method shown includes:

[0064] Step S1: In response to the vehicle being started, obtain vehicle status information, external environment information, and the user permission level corresponding to each user in the vehicle.

[0065] After the vehicle is started, the user's identity can be identified through biometrics (face, voiceprint, etc.) and / or account authentication, thereby determining the user's corresponding user permission level.

[0066] Figure 2 This is a schematic diagram of the framework of a security sandbox engine provided in a specific embodiment of the present invention. Figure 2 As shown, the data classification and grading module, user permission management module, and environment perception module, after acquiring the relevant data, can pass their identification results to the preset security sandbox engine in this embodiment. The security sandbox engine, as the core decision-making unit, receives multi-dimensional inputs such as user identity, data sensitivity level, vehicle status information, and external environment information, performs permission determination based on the preset sandbox policy library, and outputs the decision result.

[0067] User permission levels can include the highest root user permission level, administrator user permission level, standard user permission level, and user with no permission level.

[0068] For example, the top-level root user can be the vehicle owner or vehicle manager, possessing full permissions to access, modify, and delete all memory data, and can configure system policies. Administrators can be family members or authorized users of the vehicle owner or vehicle manager, possessing access and deletion permissions for all behavioral memory data of themselves, standard users, and users without permissions. Other administrators can only access their first-level (general personal information) data. Standard users are ordinary authorized users who can only access their own behavioral memory data. Users without permissions are visitors or temporary passengers who do not have permission to access any user behavioral data.

[0069] In addition, this embodiment can also acquire current vehicle status information and external environment information through a series of sensors.

[0070] External environmental information is obtained through real-time fusion of multi-source data using a large model. For example, real-time traffic conditions, weather forecasts, traffic control information, and traffic restriction policies are obtained through network data. Navigation data provides information such as the current navigation route, destination information, road conditions at waypoints, and road attributes (e.g., whether it is a mountain road, one-way lane, etc.). Sensor data, including data from vehicle cameras, millimeter-wave radar, light sensors, and rain sensors, is also used.

[0071] Step S2: Identify the request command issued by the user and determine the command security level.

[0072] In this embodiment, the user issues operation commands via voice. The voice recognition module parses the commands. If the user's request command is recognized, the type of the request command can be determined, and the security level of the corresponding command can be determined based on the type of the request command.

[0073] The safety levels of the commands are divided into low-risk (S1), medium-risk (S2), high-risk (S3), and highest-risk (S4). The safety level of each request command is pre-defined, and its level changes in real time based on the current vehicle status information.

[0074] For example, the request command type for low-risk security level can be entertainment or information services, including request commands such as playing music, querying navigation, and making phone calls. The permissions are allowed in both the driving and parked states.

[0075] The type of request command for the medium-risk safety level can be the control of vehicle internal components. Typical commands include adjusting the seat, adjusting the window, and playing videos while the driver is driving. The permission is conditionally allowed when the vehicle is in motion and allowed when the vehicle is parked.

[0076] The type of request command for high-risk security level can be control of external vehicle components. Typical commands include opening the sunroof in the rain or opening the window at high speed. The permission is prohibited when the vehicle is in motion, except under dynamic conditions. The permission is subject to secondary confirmation when the vehicle is parked.

[0077] The highest level of security requests can be for core vehicle safety controls, such as turning off headlights at night, turning off rearview mirrors while driving, and opening doors while driving. The permission is prohibited when the vehicle is in motion and permitted when the vehicle is parked.

[0078] Step S3: Based on at least one of the instruction security level, user permission level, external environment information, and vehicle status information, determine the execution decision corresponding to the request instruction according to the preset permission rule base.

[0079] In this embodiment, the execution decision corresponding to the request instruction can be executed through a preset security sandbox engine, where the security sandbox can also be understood as a security sandbox.

[0080] Figure 3 This is a schematic diagram illustrating the operation of a security sandbox engine provided in a specific embodiment of the present invention. Figure 3 As shown, the security sandbox engine dynamically determines permissions based on vehicle status information, external environment information, and user permission levels, combined with the command security level of the operation instructions, within a preset security sandbox engine. The permission decision is derived from the determination matrix, resulting in one of three options: allow, prohibit, or require secondary confirmation.

[0081] If the decision is "Allow", the policy execution module executes the instruction; if it is "Deny", a voice prompt is returned; if it is "Confirmation Required", a secondary confirmation interface pops up. All operation judgment results are recorded in the security log.

[0082] The user permission level is determined by the features obtained through identity recognition.

[0083] In this embodiment, the request instruction can be a data access request or an operation instruction request.

[0084] In one implementation, if the request instruction is a data access request, the corresponding data access control execution policy is determined from a preset privacy sandbox policy library based on the user's permission level.

[0085] The privacy sandbox policy library includes a mapping between user permission levels and data sensitivity levels. It also stores this mapping, determining the access permissions (access, modification, deletion) of different levels of data for users with different permissions.

[0086] The mapping relationship is the mapping relationship between each data sensitivity level and at least one user permission level.

[0087] For core sensitive data with a sensitivity level of three, the highest root user permission level user has full permissions for everyone, the administrator user permission level user has full permissions for themselves and full permissions for standard users / users without permissions, the standard user permission level user has permissions only for themselves, and users without permission are prohibited from accessing the data.

[0088] For sensitive personal information with a data sensitivity level of 2, the highest root user permission level user has full permissions for everyone, the administrator user permission level user has full permissions for themselves and full permissions for standard users / users without permissions, the standard user permission level user has permissions only for themselves, and users without permission level user are prohibited from accessing the data.

[0089] For general personal information with a data sensitivity level of Level 1, users with the highest root user permission level have full permissions for everyone, users with the administrator user permission level have full permissions for everyone, users with the standard user permission level have permissions only for themselves, and users without permission levels are prohibited from accessing the data.

[0090] In this embodiment, cross-user data access rules are also included. Specifically, the highest root privileges can access all levels of data of any user in the vehicle; administrators can access all levels of their own data, and can also access all data of standard users and users without privileges; administrators can only access the first-level data of other administrator users; all data access operations are recorded in audit logs and included in the sandbox monitoring scope.

[0091] When a user requests access to certain data, the data classification and grading module determines the sensitivity level of the data. The security sandbox engine receives the user's permission level and the data sensitivity level, queries the privacy sandbox policy library, and determines whether authorization is granted. If authorization is granted, the policy execution module allows the data access request and records the operation log; if authorization is denied, an insufficient permission message is returned.

[0092] In another embodiment, if the requested instruction is an operation instruction request, the corresponding operation instruction control execution strategy is determined from a preset operation permission rule base based on the user's permission level, external environment information, instruction security level, and vehicle status information. The operation permission rule base includes the determination relationships between user permission level, instruction security level, external environment information, and vehicle status information. It can also be used to store permission determination rules for operation instructions under different vehicle states, external environments, and user characteristics.

[0093] The vehicle status information includes at least the following: vehicle speed (whether the vehicle is in motion), gear (P / D, etc.), door status (locked, unlocked, open), window status (open, closed), and sunroof status (open, closed). External environment information includes at least the following: weather conditions (rain, snow, sunny, fog), light intensity (daytime / nighttime), and road type (highway, mountain road, city road). User permission levels can also determine the characteristics of the corresponding user, such as age, whether they are a child, driver, or administrator, using cameras or seat sensors.

[0094] Thus, the safety sandbox engine dynamically determines the operation command control execution strategy based on vehicle status information, external environment information, and user characteristics, combined with the command security level of the operation command.

[0095] The determination rules are as follows:

[0096] Rule 1: Core safety lock while driving

[0097] When the vehicle speed is greater than 0 km / h (driving status), voice commands for S4 level (highest risk) operations are prohibited. For commands such as "turn off headlights" at night and "turn off rearview mirrors" while driving, the system will directly intercept and provide a voice prompt: "To ensure driving safety, please operate after parking."

[0098] Rule 2: Environment Coupling Permission Restriction

[0099] When the weather is detected as "rainy", the operation of opening the sunroof by voice is automatically restricted (even if the vehicle speed is 0), and the system prompts "It is currently raining. In order to ensure the environment inside the vehicle, the sunroof cannot be opened by voice".

[0100] When the weather is detected as "snow / fog", the headlights cannot be turned off and the system will display the message "The visibility is currently low. For driving safety, the headlights cannot be turned off".

[0101] When nighttime (low light intensity) is detected, the voice command "turn off all lights" is restricted, and at least the parking lights or low beams must be kept on.

[0102] Rule 3: User Feature Condition Restrictions

[0103] When it is determined that the current voice operation is initiated by a child (based on voiceprint features or seat sensors), operations at S2 level and above require secondary confirmation from an administrator-privileged user; children cannot perform operations such as opening car doors or windows via voice, regardless of vehicle speed or status.

[0104] Rule 4: Dynamic Condition Exception Rule

[0105] When the vehicle speed is 0 and the gear is P, S4 level operation still requires secondary confirmation and cannot be executed directly;

[0106] When an emergency is detected (such as when a vehicle collision detection is triggered), some operating permissions can be temporarily unlocked to support emergency escape.

[0107] Based on the two implementation methods described above, if the execution decision is "allow," the operation corresponding to the requested instruction is executed. If the execution decision is "prohibit," a prohibition prompt corresponding to the requested instruction is returned. If the execution decision requires secondary confirmation, a secondary confirmation window pops up on the vehicle's display screen.

[0108] In this embodiment, security risks can also be identified by obtaining external environmental information, and security alerts corresponding to the security risks can be generated.

[0109] Specifically, semantic understanding and risk identification are performed on external environmental information that integrates multi-source data to generate proactive security alerts.

[0110] For example, in a rainy mountain road driving scenario, if the weather is rainy and the road type is mountain road, the user will be reminded that "the road ahead is a mountain road. The road surface is slippery due to rain. Please slow down and be careful of falling rocks."

[0111] In a one-way lane driving scenario, the navigation will display that there is a one-way lane ahead and remind the user "Entering a one-way lane ahead, please pay attention to the driving direction".

[0112] In traffic restriction reminder scenarios, the system connects to the internet to obtain the current city's traffic restriction policy and prompts the user with "Today, the license plate number ending in X is restricted in your city. Please pay attention to your travel arrangements."

[0113] In the fog warning driving scenario, the weather is foggy, and the visibility sensor triggers "There may be fog ahead, please turn on the fog lights and slow down".

[0114] In fatigue alert scenarios, the in-car camera detects driver fatigue characteristics and reminds the user, "You have been driving continuously for a long time; we recommend taking a rest nearby." By leveraging large-scale model networking capabilities combined with navigation information, proactive environmental risk alerts for driving safety are achieved, helping drivers avoid road hazards in advance.

[0115] External environmental information can also be fed back as input parameters to the operation permission determination process, realizing a closed loop of the security sandbox engine that links "environment and permission". For example, when the combined risk of "rainy weather and mountain road" is identified, the security sandbox engine automatically increases the safety level of window operation, temporarily upgrading the original S3 level operation to S4 level restriction.

[0116] This embodiment establishes a two-dimensional privacy protection mechanism based on data sensitivity level and user permission level to achieve differentiated data access control. It enables dynamic determination of multi-dimensional operation permissions based on vehicle status (driving / parking, door / window / sunroof status), external environment (weather, lighting, road conditions), and user characteristics (whether the user is a child, whether they are a driver). A unified security sandbox framework is constructed, integrating privacy policies, dynamic operation permission rules, and environmental awareness rules. High-risk operations (such as turning off headlights, turning off rearview mirrors, and opening doors) are automatically restricted while the vehicle is in motion to prevent safety accidents caused by voice-activated misoperations.

[0117] In this embodiment, a privacy emergency mode is also provided. This privacy emergency mode is a mode in the security sandbox engine that is independent of the regular permission system. It can be triggered by the user with the highest root privileges or any user (which can be configured to be administrator only or all users) in an emergency.

[0118] Figure 4 This is a schematic diagram of a privacy emergency mode provided in a specific embodiment of the present invention. For example... Figure 4 As shown, users can trigger the following operations via the "Privacy Emergency Mode" shortcut switch on the central control screen (similar to the airplane mode icon on a mobile phone) or voice commands (such as "Turn on Privacy Emergency Mode"):

[0119] Perform the following steps: Disable cellular network, disconnect the T-BOX (vehicle communication terminal) from 4G / 5G, disable Wi-Fi, disconnect all Wi-Fi connections, and stop hotspot scanning. Disable Bluetooth, disconnect Bluetooth connections (including mobile phone Bluetooth keys, Bluetooth headsets, etc.). Disable near-field communication (NFC) (e.g., wireless key sensing). Disable GPS / BeiDou reporting, stop actively reporting location information to the cloud (but the vehicle can still receive satellite signals for local navigation, without uploading). All of the above operations will automatically resume after manually disabling emergency mode.

[0120] Upon receiving the "Enable Privacy Emergency Mode" command, the security sandbox engine calls the vehicle communication management middleware interface to disconnect each wireless communication stack one by one. The system status bar prominently displays the "Privacy Emergency Mode Enabled" icon and periodically (e.g., every 5 minutes) provides a voice reminder that the system is currently offline. In this mode, network-dependent functions (such as online voice assistants, real-time traffic updates, and online searches) automatically downgrade to offline mode or are indicated as unavailable. Emergency call functions (such as eCall) are unaffected by this mode to ensure rescue communication in the event of a collision or other accident—this exception is explicitly stated when the user enables it.

[0121] In addition, when the privacy emergency mode is enabled, the system will simultaneously execute the following log processing policies:

[0122] Stored operation logs, voice recordings, and navigation history will be overwritten and deleted using the secure deletion API (not a regular deletion, to prevent data recovery tools from recovering them). New logs generated during the mode's operation will be paused, and no sensitive data such as user behavior logs, voice interaction content, or travel trajectories will be written to them. Necessary system logs (excluding user identity information) will retain only the minimum diagnostic information and will be anonymized from user identity.

[0123] Specifically, when a user activates the privacy emergency mode, a pop-up window prompts "Do you want to erase all local historical behavior logs at the same time?". After confirmation, a secure erase is performed. After the erase is completed, the system marks the log storage area as "read-only and paused" until the user manually closes the mode. After the user closes the privacy emergency mode, the system resumes normal log recording, but the previously erased data cannot be recovered, and new logs are recorded from the moment the mode is closed. All erase operations are recorded in a special protected area of ​​the security audit log (readable only by the highest root user, and this protected area itself is not cleared by one-click erase to prevent abuse of auditing).

[0124] The privacy emergency mode offers a one-click network disconnection function (or hardware-based one-click network disconnection), allowing users to quickly cut off all external network communication and create a network isolation zone within the vehicle when they suspect their vehicle is under cyberattack or do not wish to be tracked. It also provides a one-click function to clear local logs without leaving a trace, and supports pausing log recording in a traceless mode to prevent sensitive behavioral data from being stored locally. For example, if a user suspects their vehicle has been hacked, they can cut off all network channels with one click, blocking the attacker's remote access path and buying time for a security response. This successfully blocks the attacker's remote access channel, preventing vehicle location information from being continuously reported to the cloud, meeting privacy protection needs in highly sensitive scenarios. Simultaneously, it clears potentially stolen local logs, ensuring that the previous user's behavioral data is not leaked in scenarios such as shared use, maintenance, or resale of the vehicle, minimizing the risk of privacy breaches.

[0125] It's important to note that the privacy emergency mode takes precedence over the regular permission policy. This means that regardless of user permission level, once this mode is activated, all network communication and log records are forcibly cut off / cleared. However, the user with the highest root privileges can individually set a lock to "prevent other users from turning off this mode." During the mode's activation, basic driving safety operation permissions (such as brakes, lights, and wipers) are still retained, but remote control operations requiring network support (such as remotely turning on the air conditioning via a mobile app) will be unavailable. The environmental perception module is downgraded to a purely local sensor mode (no longer connecting to the internet to obtain weather / road conditions), relying solely on onboard cameras, radar, and other sensors for basic alerts (such as collision warnings).

[0126] The following embodiments will illustrate the present invention using specific implementation scenarios as examples.

[0127] Example 1: The vehicle owner (with the highest root user privileges) drives the vehicle, which carries his wife (with administrator privileges) and two strangers (users without privileges). After the vehicle starts, the system uses facial recognition to identify the identities and privilege levels of the four people in the vehicle.

[0128] When the car owner views their trip records (level 3 core sensitive data) on the central control screen, the security sandbox engine detects whether there are authorized users in the back seat and automatically performs privacy filtering on the content displayed on the central control screen, only displaying de-identified information (such as hiding specific location names).

[0129] When the wife requested to view the car owner's trip records via voice, the security sandbox engine determined that the wife had administrator privileges and the data being queried belonged to the car owner's level 3 data. According to the policy library rule that "administrators can only access level 1 data from other administrators", access was denied and a voice prompt was given that "you do not have permission to view this information".

[0130] When a passenger requests to play music (which does not involve sensitive user data), the system allows the request to be made, but does not record the passenger's entertainment preferences in their personal profile.

[0131] Example 2: A vehicle is traveling at 100 km / h on a highway at night in clear weather. The user issues a voice command to "turn off the headlights." The voice recognition module recognizes the command as "turn off the headlights" and classifies it as an S4 level (highest risk) operation. The safety sandbox engine collects the vehicle's status: speed = 100 km / h (driving state), gear = D, weather = clear, time = night; the engine queries the operation permission rule base: rule 1 stipulates that S4 level operations are prohibited in the driving state; the engine outputs the decision "reject execution".

[0132] The policy execution module announces via voice: "To ensure driving safety, the headlights cannot be turned off while the vehicle is in motion. Please manually turn them off after parking." This refusal to turn off is recorded in the safety audit log.

[0133] Comparison scenario: When the vehicle is in park (vehicle speed = 0, gear = P), the same command is issued, and the system performs a second confirmation before allowing execution.

[0134] Example 3: When the vehicle is parked in the rain, a child in the rear seat issues a voice command to "open the sunroof." The voice recognition module recognizes the command as "open the sunroof" and classifies it as an S3 level (high-risk) operation.

[0135] The safety sandbox engine collects user characteristics: identifying children through voiceprint recognition or seat sensors; the engine also collects environmental information: a rain sensor detects rain. The engine queries the operation permission rule base: Rule 2 prohibits voice-activated sunroof opening in rainy weather, and Rule 3 prohibits children from performing voice-activated door / window opening operations; the engine outputs a decision "Reject Execution". The policy execution module announces via voice: "It is currently raining. To ensure a safe environment inside the vehicle, the sunroof cannot be opened by voice. If you need to open the sunroof, please have an adult operate it manually." The system also pushes a reminder to the owner's mobile app: "Your vehicle received a child's voice request to open the sunroof while parked; this has been automatically blocked."

[0136] Example 4: The vehicle navigation route plans through a mountainous road. The large model obtains the weather forecast for this section of road via the network, indicating rain. The environmental perception module periodically (e.g., every 10 minutes) fuses navigation data and networked weather data through the large model; the large model performs semantic understanding and identifies the combined risk of "route type = mountain road" and "weather forecast for the area ahead = rain"; the safety sandbox engine receives environmental risk information, queries the environmental perception reminder rule base, and matches the "rainy mountain road driving reminder" rule; the engine outputs the decision "proactive push reminder"; the strategy execution module simultaneously pushes a message via voice and the central control screen: "We are about to enter a mountainous section of road. The weather forecast indicates rain. The road surface is slippery. Please slow down and be careful of falling rocks." At the same time, the system automatically adjusts the windshield wiper speed preset and reminds the user to turn on the fog lights (if the light is insufficient).

[0137] Example 5: While resting in a parking lot, the car owner (with the highest root user privileges) notices an unusual pop-up on the central control screen, suspecting that the vehicle may have been compromised by hackers via the network. The owner wants to immediately disconnect all network connections and clear any traces of data that may have been stolen locally. During the system operation, software prompts will appear, while hardware-based methods will execute directly: The owner clicks the "Privacy Emergency Mode" shortcut switch in the top status bar of the central control screen or uses the voice command "Activate Privacy Emergency Mode." The security sandbox engine verifies the owner's privileges (highest root user privilege level), and a pop-up prompts: "All network communications will be immediately disconnected and local historical logs will be cleared, except for the emergency call function. Continue?"; the owner clicks "Confirm." The one-click network disconnection submodule executes the following steps in sequence: disable T-BOX cellular connection; disable Wi-Fi; disable Bluetooth; stop location reporting; the local log trace-free submodule executes simultaneously: a pop-up message appears asking "Erase all historical behavior logs? Unrecoverable," and the owner confirms; the system calls the secure deletion API to overwrite the storage partition, writing random data to overwrite the original log area; after erasure, a message appears: "Historical logs have been safely cleared. No new logs will be recorded while this mode is active."; the status bar displays a "Privacy Emergency Mode" shield icon, and a voice announcement is made once: "Privacy Emergency Mode has been entered. All networks have been disconnected, and historical logs have been cleared. To restore, please manually disable this mode."; after the owner has eliminated the risk, if they contact after-sales service to confirm safety, they can click to disable this mode. The system reinitializes network communication, requiring the vehicle's infotainment system password for confirmation, and log records are restored (new records begin from the moment of disabling; previous data is permanently lost).

[0138] Figure 5 This is a structural diagram of a vehicle execution decision determination device provided in one or more embodiments of the present invention.

[0139] like Figure 5 The vehicle execution decision determination device shown includes: an information acquisition module, an instruction safety level module, and an execution strategy determination module.

[0140] The information acquisition module is used to acquire vehicle status information, external environment information, and the user permission level corresponding to each user in the vehicle in response to the vehicle being started.

[0141] The command security level module is used to identify the request commands issued by the user and determine the command security level of the request commands;

[0142] The execution strategy determination module is used to determine the execution decision corresponding to the request command based on at least one of the command security level, user permission level, external environment information and vehicle status information, according to a preset permission rule base.

[0143] The execution strategy determination module is used to determine the corresponding data access control execution strategy in a preset privacy sandbox policy library based on the user's permission level when the request instruction is a data access request; or, in response to the request instruction is an operation instruction request, determine the corresponding operation instruction control execution strategy in a preset operation permission rule library based on the user's permission level, external environment information, instruction security level, and vehicle status information.

[0144] The privacy sandbox policy library includes a mapping relationship between user permission levels and data sensitivity levels; the mapping relationship is between each data sensitivity level and at least one user permission level; the operation permission rule library includes judgment rules between user permission levels, command security levels, external environment information, and vehicle status information.

[0145] The execution strategy determination module is also used to execute the operation corresponding to the request instruction in response to the execution decision being allowed; or, in response to the execution decision being prohibited, return a prohibition prompt corresponding to the request instruction; or, in response to the execution decision being pending secondary confirmation, pop up a secondary confirmation window on the vehicle's display screen.

[0146] The execution strategy determination module is also used to identify security risks based on external environment information and generate security alerts corresponding to those risks.

[0147] The instruction security level module is used to determine the request type of the request instruction and determine the instruction security level of the request instruction based on the request type.

[0148] The execution strategy determination module is also used to respond to the activation of the privacy emergency mode by calling the vehicle communication management middleware interface to disconnect each wireless communication stack one by one; based on a preset time interval, it provides voice prompts about the network disconnection status and downgrades network-dependent functions to offline mode or unavailable mode; it stops generating behavior logs and downgrades security reminders to basic security reminders.

[0149] The execution strategy determination module is also used to prompt the user on the vehicle's display screen whether to erase all local historical behavior logs; in response to the user clicking the control, all historical behavior logs are safely erased and the log storage area is marked as read-only and paused.

[0150] Figure 6 This is a block diagram of an electronic device structure for a vehicle execution decision determination method provided in one or more embodiments of the present invention.

[0151] like Figure 6 As shown, the present invention provides an electronic device, including: a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus;

[0152] The memory stores a computer program that, when executed by a processor, causes the processor to perform steps of a vehicle execution decision determination method.

[0153] The present invention also provides a computer-readable storage medium storing a computer program executable by an electronic device, which, when run on the electronic device, causes the electronic device to perform the steps of a vehicle execution decision determination method.

[0154] The present invention also provides a vehicle, comprising:

[0155] Electronic equipment for implementing steps of a vehicle-based decision-making method;

[0156] The processor runs a program, and when the program runs, it executes the steps of the vehicle execution decision-making method based on data output from the electronic device.

[0157] A storage medium for storing a program that, when run, executes the steps of a vehicle decision-making method based on data output from an electronic device.

[0158] The communication bus mentioned in the above electronic devices can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not indicate that there is only one bus or one type of bus.

[0159] The electronic device comprises a hardware layer, an operating system layer running on top of the hardware layer, and an application layer running on the operating system. The hardware layer includes hardware such as a central processing unit (CPU), a memory management unit (MMU), and memory. The operating system can be any one or more computer operating systems that control the electronic device through processes, such as Linux, Unix, Android, iOS, or Windows. Furthermore, in this embodiment of the invention, the electronic device can be a smartphone, tablet computer, or other handheld device, or a desktop computer, portable computer, or other electronic device; there is no particular limitation in this embodiment.

[0160] In this embodiment of the invention, the executing entity for electronic device control can be an electronic device itself, or a functional module within an electronic device capable of calling and executing a program. The electronic device can obtain the firmware corresponding to the storage medium. This firmware is provided by the supplier, and different storage media may have the same or different firmware; no limitation is made here. After obtaining the firmware corresponding to the storage medium, the electronic device can write this firmware into the storage medium; specifically, it burns the firmware corresponding to the storage medium into the storage medium. The process of burning the firmware into the storage medium can be implemented using existing technology, and will not be elaborated upon in this embodiment of the invention.

[0161] Electronic devices can also obtain reset commands corresponding to the storage media. The reset commands corresponding to the storage media are provided by the supplier. The reset commands corresponding to different storage media can be the same or different, and no restrictions are imposed here.

[0162] At this time, the storage medium of the electronic device is a storage medium on which the corresponding firmware has been written. The electronic device can respond to the reset command corresponding to the storage medium on which the corresponding firmware has been written, thereby resetting the storage medium on which the corresponding firmware has been written according to the reset command. The process of resetting the storage medium according to the reset command can be implemented by existing technology and will not be described in detail in this embodiment of the invention.

[0163] For ease of description, the above apparatus is described by dividing it into various units and modules according to their functions. Of course, in implementing this invention, the functions of each unit and module can be implemented in one or more software and / or hardware.

[0164] It will be understood by those skilled in the art that, unless otherwise defined, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. It should also be understood that terms such as those defined in general dictionaries should be understood to have the meaning consistent with their meaning in the context of the prior art, and should not be interpreted in an idealized or overly formal sense unless specifically defined.

[0165] For the sake of simplicity, the method embodiments are described as a series of actions. However, those skilled in the art should understand that the embodiments of the present invention are not limited to the described order of actions, because according to the embodiments of the present invention, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions involved are not necessarily essential to the embodiments of the present invention.

[0166] As can be seen from the above description of the embodiments, those skilled in the art can clearly understand that the present invention can be implemented by means of software plus necessary general-purpose hardware platforms. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in various embodiments or some parts of the embodiments of the present invention.

[0167] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for determining vehicle execution decisions, characterized in that, include: In response to the vehicle being started, obtain vehicle status information, external environment information, and the user permission level corresponding to each user in the vehicle; The system identifies the user's request instruction and determines the instruction's security level. Based on at least one of the instruction security level, the user permission level, the external environment information, and the vehicle status information, the execution decision corresponding to the request instruction is determined according to a preset permission rule base.

2. The vehicle execution decision determination method according to claim 1, characterized in that, The step of determining the execution decision corresponding to the request instruction based on at least one of the instruction security level, the user permission level, the external environment information, and the vehicle status information, according to a preset permission rule base, includes: In response to the request instruction being a data access request, a corresponding data access control execution policy is determined from a preset privacy sandbox policy library based on the user permission level. or In response to the request instruction being an operation instruction request, a corresponding operation instruction control execution strategy is determined from a preset operation permission rule base based on the user permission level, the external environment information, the instruction security level, and the vehicle status information.

3. The vehicle execution decision determination method according to claim 2, characterized in that, The privacy sandbox policy library includes a mapping relationship between the user permission level and the data sensitivity level; the mapping relationship is a mapping relationship between each data sensitivity level and at least one user permission level. The operation permission rule base includes the determination rules between the user permission level, the instruction security level, the external environment information, and the vehicle status information.

4. The vehicle execution decision determination method according to claim 1, characterized in that, After determining the execution decision corresponding to the request instruction, the method further includes: In response to the execution decision being permitted, the operation corresponding to the request instruction is executed; or In response to the execution decision being prohibited, a prohibition prompt corresponding to the request instruction is returned; or In response to the execution decision requiring secondary confirmation, a secondary confirmation window pops up on the vehicle's display screen.

5. The vehicle execution decision determination method according to claim 1, characterized in that, The method further includes: Based on the external environment information, identify security risks and generate security alerts corresponding to the security risks.

6. The vehicle execution decision determination method according to claim 1, characterized in that, The process of identifying a user-issued request instruction and determining the security level of that request instruction includes: Determine the request type of the request instruction, and determine the instruction security level of the request instruction based on the request type.

7. The vehicle execution decision determination method according to claim 1, characterized in that, The method further includes: In response to activating the privacy emergency mode, the vehicle communication management middleware interface is invoked to disconnect each wireless communication stack one by one. Based on a preset time interval, the system will prompt the network status via voice and downgrade network-dependent functions to offline mode or unavailable mode. Stop generating behavior logs and downgrade the security alert to a basic security alert.

8. The vehicle execution decision determination method according to claim 7, characterized in that, The method of stopping the generation of behavior logs also includes: The vehicle's display screen prompts the user whether to erase all local historical behavior logs; In response to a user click on the control, all historical behavior logs are securely erased, and the log storage area is marked as read-only and paused.

9. A vehicle execution decision-making device, characterized in that, Determining the shift execution trajectory using the method according to any one of claims 1-8 includes: The information acquisition module is used to acquire vehicle status information, external environment information, and the user permission level corresponding to each user in the vehicle in response to the vehicle being started. The instruction security level module is used to identify the request instruction issued by the user and determine the instruction security level of the request instruction; The execution strategy determination module is used to determine the execution decision corresponding to the request instruction based on at least one of the instruction security level, the user permission level, the external environment information, and the vehicle status information, according to a preset permission rule base.

10. A vehicle, characterized in that, include: An electronic device for implementing the steps of the vehicle execution decision determination method as described in any one of claims 1 to 8; A processor that runs a program that, when the program is running, executes the steps of the vehicle execution decision determination method as described in any one of claims 1 to 8 from data output by the electronic device. A storage medium for storing a program that, when run, performs the steps of the vehicle execution decision determination method as described in any one of claims 1 to 8 on data output from an electronic device.

Images