Vehicle permission control method and vehicle

Abstract

The application discloses a vehicle permission control method and a vehicle, and belongs to the field of intelligent networking. The method comprises the following steps: acquiring an identity of a digital key close to the vehicle, and determining a user identity; receiving a component operation request indicating a target component and an operation type; querying a permission from permission configuration information according to the user identity and the target component; when the permission is conditionally allowed, determining whether vehicle state data meets a constraint condition corresponding to the permission, and allowing or rejecting execution of the component operation request according to a determination result. The method can support fine differentiation of multiple types of user identities, realize component-level permission management based on the user identity, and realize dynamic permission control related to the vehicle state through constraint condition determination, effectively solving the problems of extensive identity differentiation and extensive permission granularity in the prior art, meeting differentiated needs in scenarios such as family sharing, time-sharing leasing and distribution services, and improving the safety and convenience of the vehicle in a multi-user sharing scenario.

Description

Technical Field

[0001] This application relates to the field of intelligent connected vehicles, and in particular to a vehicle access control method and a vehicle. Background Technology

[0002] With the development of intelligent and shared vehicles, vehicle users have expanded from single owners to include family members, visitors, maintenance personnel, chauffeurs, delivery personnel, and rental users. Users with different identities should have different access permissions to vehicle functions and components.

[0003] Currently, vehicle access control methods suffer from problems such as coarse-grained access control, the ability to distinguish only a very small number of fixed identities, and the inability to achieve fine-grained access management at the component level based on user identity. These issues make it difficult to meet the differentiated needs of scenarios such as family sharing, time-sharing rental, and delivery services. Summary of the Invention

[0004] This application provides a vehicle access control method and a vehicle, with the aim of achieving fine-grained access control at the component level based on user identity.

[0005] To achieve the above objectives, this application provides the following technical solution:

[0006] A vehicle access control method, comprising:

[0007] Obtain the identity of the digital key that approaches the vehicle to determine the corresponding user identity;

[0008] Receive a component operation request specifying the target component and operation type;

[0009] Based on the user identity and the target component, the corresponding permissions are queried from the permission configuration information; the permission configuration information defines the operation permissions of multiple user identities for multiple vehicle components.

[0010] When the permission is conditionally allowed, it is determined whether the current vehicle status data meets the constraint conditions corresponding to the permission, and the component operation request is allowed or denied based on the determination result.

[0011] A vehicle includes: a processor, a memory, and a bus; the processor and the memory are connected via the bus.

[0012] The memory is used to store a program, and the processor is used to run the program, wherein the program is executed by the processor to perform the vehicle access control method.

[0013] The technical solution provided in this application obtains the identity identifier of the digital key approaching the vehicle to determine the user's identity; receives a component operation request indicating the target component and operation type; queries permissions from the permission configuration information based on the user's identity and the target component; when the permission is conditionally allowed, it determines whether the vehicle status data meets the constraints corresponding to the permission, and allows or denies the execution of the component operation request based on the determination result. This application can support fine differentiation of multiple user identities, realize component-level permission management based on user identity, and realize dynamic permission control related to vehicle status through constraint condition determination. It effectively solves the problems of coarse identity differentiation and coarse permission granularity in existing technologies, meets the differentiated needs of scenarios such as family sharing, time-sharing rental, and delivery services, and improves the security and convenience of vehicles in multi-user sharing scenarios. Attached Figure Description

[0014] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0015] Figure 1 This is a first flowchart illustrating a vehicle access control method provided in an embodiment of this application;

[0016] Figure 2 This is a second flowchart illustrating a vehicle access control method provided in an embodiment of this application;

[0017] Figure 3 A schematic diagram of the third process of a vehicle access control method provided in an embodiment of this application;

[0018] Figure 4 A schematic diagram of the fourth process of a vehicle access control method provided in an embodiment of this application;

[0019] Figure 5 A fifth flowchart illustrating a vehicle access control method provided in an embodiment of this application;

[0020] Figure 6 A sixth flowchart illustrating a vehicle access control method provided in this application embodiment;

[0021] Figure 7 A seventh flowchart illustrating a vehicle access control method provided in an embodiment of this application;

[0022] Figure 8 This is an eighth flowchart illustrating a vehicle access control method provided in an embodiment of this application.

[0023] Figure 9 This is a schematic diagram of the architecture of a vehicle provided in an embodiment of this application. Detailed Implementation

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

[0025] In this application, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. The terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0026] like Figure 1 The diagram shown is a first flowchart of a vehicle access control method provided in this application embodiment, applicable to the keyless entry and start system (Passive Entry Passive Start, PEPS) controller of a vehicle. The method includes the following steps.

[0027] S101: Obtain the identity identifier of the digital key approaching the vehicle and determine the corresponding user identity.

[0028] Digital keys include, but are not limited to, portable terminals with near-field communication capabilities such as smartphones, smart wearable devices, and NFC cards. An Identity ID is a unique code assigned to the digital key in the pairing environment, and its format can be "Identity Type Prefix_Unique Number_Verification Code". User identities include preset identity types such as vehicle owner, family member, visitor, repair technician, chauffeur, delivery person, novice driver, rental user, test driver, and emergency contact. Each identity type corresponds to different vehicle component operation permissions.

[0029] It should be noted that the identity type prefix in the identity identifier uses 8-bit binary encoding, supporting 256 identity types to meet future expansion needs. The unique number is a 32-bit random number, ensuring global uniqueness during pairing; the checksum uses the CRC16 algorithm to verify the integrity of the identity identifier during transmission.

[0030] In some examples, the PEPS controller sends a wake-up signal via a low-frequency antenna array deployed on the vehicle body, triggering the digital key within its effective range to return a response value and its identity identifier. The low-frequency antenna array consists of 6 to 8 low-frequency 125kHz radio frequency antennas, distributed as follows: two on the front bumper, two on the rear bumper, one on each side mirror, and two inside the vehicle. After the digital key is woken up, it calculates the response value: Response = SM3(Vehicle ID || Random Number || Key), and sends the response value and identity identifier via a high-frequency channel (e.g., 433MHz or 13.56MHz). The PEPS controller verifies the response value; upon successful verification, it extracts the identity type prefix from the identity identifier and determines the user identity corresponding to the digital key based on the identity type prefix. The identity recognition process is entirely completed locally on the PEPS controller, without relying on cloud services, ensuring normal operation even in environments without network access, such as underground parking garages and tunnels, with an identity recognition time of less than 80ms.

[0031] In a possible implementation, the pairing process between the digital key and the vehicle is completed within a pairing environment (such as a dealership or the owner's mobile application). During pairing, the vehicle generates a random key and writes it to the secure storage area of ​​the digital key, while simultaneously assigning an identity identifier to the digital key. This key is used for encrypted authentication in subsequent response value calculations. After pairing is complete, the vehicle stores the mapping relationship between the identity identifier and the user's identity in the permission configuration information.

[0032] Optionally, the process of obtaining the identity of the digital key approaching the vehicle and determining the corresponding user identity can be found in [reference needed]. Figure 2 The steps are shown.

[0033] S102: Receive a component operation request indicating the target component and operation type.

[0034] The target components are functional parts of the vehicle with independently configurable permissions, including driving permissions, doors, trunk, vehicle infotainment system, vehicle personal data, air conditioning system, seat system, window system, glove box, hood, and diagnostic interface. Driving permissions include starting the vehicle, driving, and speed limit settings. Doors include the left front door, right front door, left rear door, and right rear door. Operation type represents the specific operation to be performed on the target component, such as opening, closing, adjusting, or starting.

[0035] It should be noted that each target component has a unique component ID, which also uses an 8-bit code and supports fine-grained management of 256 different components. The correspondence between component IDs and physical components or functional logic is pre-defined in the configuration table of the PEPS controller.

[0036] In some examples, component operation requests can be initiated via a digital key button, a selection on the vehicle's infotainment system, or physical vehicle operations (such as pulling a door handle). The PEPS controller receives the request via the CAN (Controller Area Network) bus or near-field communication interface. The data format of the component operation request is a fixed-length frame, containing: request ID (2 bytes), component identifier (1 byte), operation type code (1 byte), timestamp (4 bytes), and checksum (1 byte). The operation type code uses a predefined enumeration value, for example, 0x01 indicates open, 0x02 indicates closed, 0x03 indicates unlocked, and 0x04 indicates locked.

[0037] In a possible implementation, when triggered by a digital key button, the digital key maps the button event to the corresponding component identifier and operation type. For example, pressing and holding the unlock button for 3 seconds maps to the "trunk" component and the "open" operation. After receiving the request, the PEPS controller first performs format verification and timestamp anti-replay checks (e.g., a timestamp difference of less than 5 seconds from the local time is considered valid).

[0038] S103: Based on the user identity and target component, query the corresponding permissions from the permission configuration information.

[0039] The permission configuration information defines the operation permissions of multiple user identities for various vehicle components. This permission configuration information can be stored in the non-volatile memory of the PEPS controller. Each permission record in the permission configuration information includes an identity identifier, a component identifier, and a permission flag. The identity identifier uses an 8-bit code (supporting 256 identities), the component identifier uses an 8-bit code (supporting 256 components), and the permission flag uses a 16-bit bitmap, with each bit representing an operation permission: bit 0 corresponds to read permission, bit 1 to write permission, bit 2 to execute permission, and bit 3 to configuration permission. The permission configuration information uses sparse matrix compression storage, storing only non-zero permission entries. The query algorithm uses hash table and bitmap operations, with a single query time of less than 0.5ms.

[0040] It should be noted that the permission configuration information is stored using a hash table structure, with the combination of identity ID and component ID ((Identity ID << 8) | Component ID) as the key and the permission record as the value. Queries are performed by directly locating the record using the hash value, with a time complexity of O(1). In the sparse matrix compression storage method, non-zero permission entries refer to records where the permission flag is not 0, and zero-permission entries (operations prohibited) do not occupy storage space, thus reducing the use of non-volatile memory.

[0041] In a possible implementation, in the 16-bit bitmap of the permission flag, bits 0-3 correspond to read, write, execute, and configure, respectively, while bits 4-15 are reserved for expanding operation types, such as temporary authorization, proxy execution, and emergency overwrite. A permission flag of 0xFFFF indicates all permissions are allowed, and 0x0000 indicates all permissions are denied. For conditional permissions, the corresponding bits of the permission flag are set to special values, and a separate constraint pointer field points to the constraint storage address.

[0042] In addition, the operation permissions corresponding to various user identities have preset default configurations.

[0043] For example, the vehicle owner has operating permissions for all vehicle components, as well as permissions to modify permission configurations and initiate temporary authorizations.

[0044] For example, family members have full driving privileges and access to the doors, trunk, and interior functions, but do not have permission to modify privilege configurations.

[0045] For example, visitors have access to the car doors, trunk, air conditioning, and windows, but not driving privileges or access to personal data on the vehicle's infotainment system.

[0046] For example, the repair technician has access to the doors, trunk, hood, and diagnostic interface, which requires temporary authorization activation, but does not have driving privileges or access to the glove box.

[0047] For example, a designated driver has driving privileges but is constrained by a preset speed limit (e.g., 60 km / h), has access to the driver's side door, but does not have access to the glove box or the vehicle's personal data. Access to the trunk can be configured by the vehicle owner.

[0048] For example, the delivery person only has access to the trunk, and the trunk is limited to a preset height (e.g., 50%), with the access automatically limited to a time limit (e.g., 5 minutes).

[0049] For example, a novice driver has driving privileges but is restricted by a preset speed limit (e.g., 80 km / h) and is forced to activate driver assistance functions.

[0050] For example, the test driver has driving authority but is subject to preset speed limits (e.g., 60 km / h), preset mileage limits (e.g., 50 km), and preset time limits (e.g., 30 minutes).

[0051] For example, the emergency contact has door unlocking and air conditioning operation permissions, which only take effect after the vehicle owner initiates a temporary authorization.

[0052] Optionally, the permission configuration information can be temporarily authorized and updated in the following way: in response to the temporary authorization operation, a local authorization credential is generated, the authorization credential is sent to the target digital key via near-field communication, and after receiving the confirmation information returned by the target digital key, the corresponding temporary permission record is added to the permission configuration information.

[0053] It is important to emphasize that the temporary authorization update of permission configuration information is completed entirely locally, without relying on the cloud network, thus solving the authorization problem in environments without network access, such as underground parking garages and tunnels. Furthermore, the two-way confirmation mechanism based on the confirmation information returned by the target digital key also prevents misauthorization. The overall authorization process is fast, improving the convenience and usability of temporary authorization.

[0054] In some examples, temporary authorization is initiated by the authorizing party via the vehicle control interface or a combination of digital key buttons. The local authorization credential includes the target user's identity, authorized component, constraints, and validity period. It may further include a version number, serial number, effective date, expiration date, and a digital signature generated using the authorizing party's private key. The serial number is randomly generated and for one-time use to prevent replay attacks. Near-field communication includes Bluetooth Low Energy (BLE) or NFC, where BLE has a transmission distance of less than 5 meters, NFC has a transmission distance of less than 10 centimeters, and a transmission time of less than 500 milliseconds. If the target digital key is outside the effective communication range, the authorizing party is notified that the target user is not within range.

[0055] After receiving the authorization credential, the target digital key displays an authorization summary (including authorized identity type, authorized components, constraints, and validity period) to the target user. The target user confirms acceptance or rejection via a button on the digital key. If accepted, the target digital key signs the confirmation message using its private key and returns the signed confirmation message. The PEPS controller holds the public key corresponding to the target digital key and uses it to verify the signature of the confirmation message. After successful signature verification, the corresponding temporary permission record is written to the temporary permission partition of the permission configuration information, and the authorization status is marked as activated.

[0056] Furthermore, the PEPS controller starts a hardware timer to keep track of the duration. When the timer reaches the valid duration of the temporary permission record, the temporary permission record is automatically deleted from the permission configuration information. In addition, the authorizing party can also actively revoke the issued temporary authorization at any time through the vehicle control interface or digital key button combination. The revocation command is sent to the target digital key via near-field communication. Upon receiving the revocation command, the target digital key immediately deletes the locally stored authorization certificate.

[0057] Optionally, based on the user identity and target component, the implementation process of the corresponding permission can be queried from the permission configuration information. (See also...) Figure 3 The steps are shown.

[0058] Optionally, for details on the specific implementation process of temporarily updating permission configuration information, please refer to [link to relevant documentation]. Figure 5 The steps are shown.

[0059] S104: When the permission is conditionally allowed, determine whether the current vehicle status data meets the constraint conditions corresponding to the permission, and allow or refuse to execute the component operation request based on the determination result.

[0060] The vehicle status data includes real-time status information such as vehicle speed, gear position, power status, and door lock status, acquired via the CAN bus at a frequency of 100Hz. Constraints include at least one constraint type and its Boolean expression.

[0061] In possible implementations, constraint types include vehicle state constraints (such as vehicle speed less than a threshold, gear in P, power status OFF), time constraints (such as authorization validity period, specific time period 8:00-20:00, weekday constraints), frequency constraints (such as maximum usage limit), and numerical constraints (such as speed limit value, mileage limit).

[0062] It should be noted that Boolean expressions support the following operators: >, <, ==, !=, >=, <=, AND, OR, NOT, and parentheses, for example: "(vehicle speed < 5) AND (gear == P) OR (power status == OFF)". The Boolean expressions for constraints are stored as strings during permission configuration. The PEPS controller has a built-in lightweight expression parser that can convert the expressions to Reverse Polish notation at runtime and perform fast evaluation, with a single evaluation time of less than 30ms.

[0063] In some examples, the PEPS controller substitutes the current vehicle status data and current time information into the Boolean expression of the constraint conditions for logical operation. If the result is true, the constraint conditions are satisfied and operation is allowed; if the result is false, the constraint conditions are not satisfied and operation is rejected, while a specific rejection message is returned to the user. The rejection message may include that the current user does not have permission to operate the component, the vehicle status does not meet the operation requirements (e.g., "current vehicle speed is not 0, operation is not allowed"), or permission has been suspended.

[0064] In a possible implementation, for the usage constraint, the PEPS controller maintains a usage counter in non-volatile memory for each temporary permission record with a usage constraint. Before each operation is executed, it checks whether the number of uses is less than the maximum number of uses; if it is less, the operation is allowed and the counter is incremented by 1; otherwise, the operation is rejected. When a temporary permission is deleted, the corresponding counter is cleared simultaneously.

[0065] Optionally, when the permission is conditionally allowed, the process of determining whether the current vehicle status data meets the constraints corresponding to the permission can be found in [reference needed]. Figure 4 The steps are shown.

[0066] Optionally, for issues related to conflicts when multiple users operate the same component simultaneously, please refer to... Figure 6 The steps are shown.

[0067] The processes shown in S101-S104 above determine the user's identity by obtaining the identity identifier of the digital key, and query the corresponding permissions from the locally stored permission configuration information based on the user's identity and the target component. This achieves fine-grained permission management at the component level and solves the problem of the existing technology's coarse control that only distinguishes between vehicle owners and non-owners. When the permission is conditionally allowed, the constraints are determined based on the vehicle status data to allow or deny the operation, thus achieving dynamic permission constraints.

[0068] like Figure 2 The diagram shown is a second flowchart of a vehicle access control method provided in an embodiment of this application, including the following steps.

[0069] S201: Sends a wake-up signal via a low-frequency antenna to trigger the digital key approaching the vehicle to calculate the response value and return the response value and its identity identifier.

[0070] The low-frequency antenna is an antenna deployed in the PEPS antenna array on the vehicle body, operating at a frequency of 125kHz. The response value is generated by the digital key based on the vehicle identifier, a random number, and a key, for example, using the SM3 hash algorithm.

[0071] It should be noted that the low-frequency wake-up mechanism is based on electromagnetic induction. The low-frequency antenna continuously transmits a 125kHz carrier signal. When the digital key enters the effective range of the magnetic field (typically 1.5 to 2.5 meters), its internal low-frequency receiver senses the signal energy, activating the digital key's radio frequency circuitry and calculating the response value. This process does not require the digital key to actively power itself; the electromagnetic field radiated by the antenna provides the instantaneous energy, thus achieving low-power proximity detection.

[0072] In a possible implementation, the response value is calculated using the HMAC-SM3 algorithm. The inputs are the vehicle ID (4 bytes), a random number (4 bytes), and a preset key (16 bytes). The output is the first 8 bytes of a 32-byte hash value as the response value. The random number is generated by the PEPS controller on each wake-up and sent along with the wake-up signal to prevent replay attacks. The PEPS controller calculates a local response value using the same key and random number, compares it with the response value returned by the digital key, and verifies success if they match.

[0073] In some examples, each antenna in the low-frequency antenna array sends wake-up signals sequentially in time slices, with each antenna having a 10ms transmission time slot. By measuring the signal strength of the digital key under different antennas, the precise location of the digital key (e.g., the left front door side, the right rear door side, or inside the vehicle) can be further located for subsequent fine-grained control (e.g., unlocking only the door on the closer side).

[0074] S202: Verify the response value. If the verification is successful, extract the identity type prefix from the identity identifier.

[0075] The identity identifier is formatted as “identity type prefix_unique number_verification code”. The identity type prefix is ​​used to identify the user identity type corresponding to the digital key. For example, “OWNER_001_ABC” indicates the car owner, and “CHILD_002_XYZ” indicates the child.

[0076] In a possible implementation, the process of verifying the response value is as follows: The PEPS controller extracts the random number sent during wake-up, retrieves the shared key corresponding to the digital key identity from local storage, calculates the local response value using the same HMAC-SM3 algorithm, and compares the local response value with the response value returned by the digital key over a constant time (to prevent timing attacks). If they are equal, the verification passes; otherwise, the request is discarded and the authentication failure event is recorded. If more than 3 consecutive failures occur, the identity of the digital key is temporarily locked.

[0077] S203: Determine the user identity corresponding to the digital key based on the identity type prefix.

[0078] The user identities include preset identity types such as vehicle owner, family member, visitor, repair technician, designated driver, delivery person, novice driver, rental user, test driver, and emergency contact. There is a one-to-one mapping relationship between the identity type prefix and the user identity. This mapping relationship is pre-stored in the non-volatile memory of the PEPS controller and is stored in the form of a hash table or direct mapping table to support fast lookup.

[0079] In some examples, identity type prefixes are encoded using fixed-length strings. For example, "OWNER" represents the vehicle owner, "FAMILY" represents a family member, "GUEST" represents a visitor, "MECH" represents a mechanic, "DRIVER" represents a designated driver, "COURIER" represents a delivery person, "NEWBIE" represents a new driver, "RENTER" represents a rental user, "TESTER" represents a test driver, and "EMER" represents an emergency contact. Each prefix string is 4 to 8 characters long and is stored in a read-only area of ​​non-volatile memory.

[0080] In a possible implementation, the direct mapping table uses a direct indexing method: the identity type prefix is ​​hashed using a function (e.g., converting the first four characters of the prefix string to a 32-bit integer modulo 256) to obtain an 8-bit identity type code, which is directly used as the index for the user identity enumeration value. The PEPS controller internally maintains a 256-character user identity conversion table, where each entry stores a user identity enumeration value (e.g., 0x01 represents the vehicle owner). Upon receiving the identity type prefix, the hash value is calculated, and the corresponding user identity can be obtained by looking up the table in constant time. If the identity enumeration value obtained from the table lookup is 0xFF (indicating undefined), the digital key is considered a "guest" identity with the lowest privileges, and an exception is logged.

[0081] It's important to note that the identity type prefix is ​​written into the digital key's identity identifier by the PEPS controller based on the authorizing party's selection during digital key pairing with the vehicle. During pairing, the authorizing party (usually the vehicle owner) selects the target user's identity type through the vehicle control interface or mobile application. The PEPS controller generates the corresponding identity type prefix and combines it with a randomly generated unique number and verification code to form a complete identity identifier, which is then written to the digital key's secure storage area. Simultaneously, the PEPS controller also records the mapping relationship between this identity identifier and the identity type in its local permission configuration information to ensure consistency during subsequent identification.

[0082] In some examples, to support dynamic identity updates (e.g., upgrading existing family member permissions to owner permissions), the PEPS controller provides an identity reassignment mechanism. The authorizing party selects the "Modify Digital Key Identity" function through the vehicle's infotainment interface, changing the target digital key's identity type prefix from "FAMILY" to "OWNER" and generating a new identity identifier. The PEPS controller writes the new identity identifier to the digital key via near-field communication and updates the local mapping table and permission configuration information. This process requires interactive authentication using the digital key's private key to prevent unauthorized tampering.

[0083] In addition, after determining the user's identity based on the identity type prefix, the PEPS controller also records the corresponding identity priority value in the local session context for subsequent conflict arbitration. For example, if the identity type prefix is ​​identified as "OWNER", the user is identified as the vehicle owner, with a corresponding identity priority value of 6; if it is "COURIER", the user is identified as a delivery person, with an identity priority value of 1. This session context is automatically cleared when the digital key leaves the valid range or the vehicle is powered off.

[0084] The process described in S201-S203 above triggers the digital key to return a response value and identity identifier by sending a wake-up signal through a low-frequency antenna. After verifying the response value, the identity type prefix is ​​extracted to determine the user's identity. This achieves localized and accurate identification of the digital key's identity. The identification process does not rely on a network connection and has a high accuracy rate, providing a reliable basis for subsequent refined permission queries based on identity.

[0085] like Figure 3 The diagram shown is a third-stage schematic of a vehicle access control method provided in an embodiment of this application, including the following steps.

[0086] S301: Based on the identity identifier corresponding to the user's identity and the component identifier corresponding to the target component, retrieve the corresponding permission record from the permission configuration information.

[0087] The permission configuration information is stored in the non-volatile memory of the PEPS controller. When querying, the storage address is calculated based on the identity identifier and component identifier, and the permission data is read from the corresponding address.

[0088] In a possible implementation, the storage address can be calculated as follows: Address = Base Address + (Identity ID << 8) + Component ID, where Base Address represents a predefined constant pointing to the starting address of the two-dimensional matrix of permission configuration information in memory.

[0089] It should be noted that this storage address calculation method assumes that the permission configuration information is arranged continuously in memory according to the combination of identity identifier and component identifier, forming a two-dimensional matrix. Since both the identity identifier and component identifier are 8 bits, the matrix size is 256 × 256 = 65536 entries, and each entry is fixed at 32 bytes (permission record structure), occupying a total of approximately 2MB of storage space. The non-volatile memory capacity of modern PEPS controllers (typically 4MB to 8MB) can fully meet this requirement, and the contiguous storage makes the lookup a direct addressing with constant time complexity.

[0090] In some examples, permission records use a fixed-length 32-byte structure: identity identifier (1 byte), component identifier (1 byte), permission flag (2 bytes), constraint pointer (4 bytes), and reserved fields (24 bytes). The constraint pointer points to the address of the Boolean expression for the constraint stored in non-volatile memory. For records with "prohibited" permission, the constraint pointer is set to NULL (all zeros), and the corresponding bit of the permission flag is 0; for records with "allowed" permission and no constraints, it indicates unconditional permission.

[0091] S302: Determine the type of permission shown in the permission record based on the permission flag and operation type in the permission record.

[0092] The type is one of permitted, prohibited, or conditionally permitted.

[0093] In some examples, the permission flag uses a 16-bit bitmap, where each bit represents an operation permission: bit 0 corresponds to read permission, bit 1 to write permission, bit 2 to execute permission, and bit 3 to configuration permission. The permission value is determined by checking the bit corresponding to the operation type in the permission bitmap. For example, if the requested operation type is "execute", then check if bit 2 is 1.

[0094] In a possible implementation, the mapping relationship between operation type and permission flag bits is predefined by the system: read operations (such as reading door status) correspond to bit 0, write operations (such as modifying seat position) correspond to bit 1, execution operations (such as starting the engine) correspond to bit 2, and configuration operations (such as modifying permission configuration) correspond to bit 3. If the bit corresponding to the operation type is 1, the permission is "allowed"; if it is 0, a further check is performed to see if there is a conditional allow flag. The conditional allow flag is located at bit 15. If bit 15 is 1 and the bit corresponding to the operation type is 0, the permission is "conditionally allowed"; otherwise, it is "prohibited". This design allows conditionally allowed permissions to simultaneously set the operation bit to 0 and the conditional flag bit to 1 in the permission flag, to distinguish them from direct allowance.

[0095] S303: When the permission is conditionally allowed, retrieve the corresponding constraint pointer from the permission record.

[0096] The constraint pointer is a 4-byte unsigned integer that points to the starting address of the non-volatile memory where constraint description information (such as a Boolean expression string or a pre-compiled expression tree) is stored.

[0097] In some examples, the permission record uses a fixed-length 32-byte structure, with the constraint pointer field located at an offset of 8 bytes (after the permission flag field). When the permission flag indicates "conditionally allowed," the pointer value is neither 0 nor a reserved value of all Fs; if the permission is "allowed" and there are no constraints; if the permission is "prohibited," the pointer is set to 0. After reading the permission record, the PEPS controller first checks whether permission flag 15 (conditionally allowed flag) is set; if it is set, it continues reading the constraint pointer field.

[0098] It's important to note that the storage area pointed to by the constraint pointer is independent of the permission record table and is typically located in a separate partition of non-volatile memory. Each constraint entry is stored as a NULL-terminated (0x00) string, with a length not exceeding 256 bytes. The PEPS controller incorporates a lightweight expression parser. Upon first access to a constraint pointer, it reads the corresponding string, parses it into a Reverse Polish Notation expression tree, and caches the parsing result in RAM. Subsequent accesses to the same pointer retrieve the expression tree directly from the cache, avoiding repeated string parsing and thus reducing runtime overhead.

[0099] In a possible implementation, the constraint pointer can also point to a pre-compiled binary structure containing: an expression type identifier (0x01 for a Boolean expression string, 0x02 for an RPN instruction sequence), the bytecode length of the expression, and the bytecode body. This method completes compilation during permission configuration and eliminates the need for runtime parsing, further improving decision-making efficiency. When the PEPS controller is configured at the factory or the vehicle owner modifies permissions, it compiles the constraints into bytecode, writes it to the address pointed to by the pointer, and updates the pointer value.

[0100] In addition, after reading the constraint pointer, the PEPS controller performs a validity check: it checks whether the pointer address falls within a valid non-volatile memory address range (e.g., from 0x0800E000 to 0x0800FFFF), and whether the first 4 bytes of the address pointed to by the pointer are a predefined magic number (e.g., 0x434F4E53, the ASCII code for "CONS"). If the check fails, the permission configuration data is considered corrupted, and the permission is temporarily treated as "prohibited," with an error log recorded for subsequent diagnosis.

[0101] S304: Read the constraints corresponding to the permissions based on the constraint pointer.

[0102] The constraints include Boolean expressions of at least one of the following constraint types: vehicle state constraints, time constraints, frequency constraints, and numerical constraints.

[0103] For example, constraints are stored in the form of predefined Boolean expressions, such as "(speed < 5) AND (gear == P)".

[0104] In a possible implementation, constraint strings are stored in a separate area of ​​non-volatile memory, with each constraint terminated by NULL. A constraint pointer points to the starting address of the string. The PEPS controller internally maintains a constraint cache to reduce the overhead of repeatedly reading non-volatile memory. When a constraint pointer in a permission record matches a record in the cache, the parsed expression tree from the cache is used directly; otherwise, the string is read from memory and parsed.

[0105] The processes shown in S301-S304 above obtain permission records from the permission configuration information based on the identity identifier and component identifier, determine whether the permission is allowed, prohibited, or conditionally allowed based on the permission flag and operation type, and read the corresponding constraint conditions through the constraint condition pointer when the permission is conditionally allowed. This achieves rapid location and type determination of permissions, high permission query efficiency, and provides an accurate source of constraint data for subsequent constraint condition determination.

[0106] like Figure 4 The diagram shown is a fourth step of a vehicle access control method provided in this application embodiment, including the following steps.

[0107] S401: Constraints for obtaining permissions.

[0108] The constraints include at least one constraint type and its Boolean expression. Constraint types include vehicle state constraints, time constraints, frequency constraints, and numerical constraints.

[0109] In some examples, vehicle status constraints can be such as vehicle speed being less than a preset threshold, gear being in P gear, or power being OFF; time constraints can be such as authorization validity period, specific time period, or weekday constraints; usage constraints can be such as maximum usage limit; and numerical constraints can be such as speed limit and mileage limit.

[0110] For example, vehicle status constraints can be "vehicle speed less than 5km / h", "gear in P", and "power status OFF"; time constraints can be "authorization validity period from 2025-01-01 00:00:00 to 2025-01-02 00:00:00", "daily 8:00-20:00", and "weekdays only"; frequency constraints can be "maximum number of uses ≤ 3"; and numerical constraints can be "speed limit ≤ 60km / h" and "mileage limit ≤ 50km".

[0111] In possible implementations, constraints support compound expressions, such as: "(vehicle speed < 5 AND gear == P) OR (power state == OFF AND current time BETWEEN '22:00' AND '06:00')". The expression parser evaluates according to operator precedence and parentheses.

[0112] S402: Substitute the current vehicle status data and current time information into a Boolean expression for logical operation to obtain the result.

[0113] The vehicle status data is obtained from various sensors and controllers in the vehicle via the CAN bus, including vehicle speed, gear position, power status, and door lock status.

[0114] In a possible implementation, the PEPS controller periodically broadcasts status data requests via the CAN bus, and each component controller responds with the latest status. Vehicle speed information comes from wheel speed sensors, gear information from the transmission controller, and power status from the body control module. Current time information is provided by a real-time clock module built into the PEPS controller, which is independently battery-powered to ensure that time is not lost after system power failure. Time information includes year, month, day, hour, minute, second, and day of the week; the day of the week field is used to determine constraints such as "working days only".

[0115] In some examples, to improve evaluation efficiency, the PEPS controller pre-converts Boolean expressions into Reverse Polish Notation (RPN) sequences and maps variables (such as vehicle speed and gear position) to fixed indices. At runtime, the currently acquired variable values ​​are pushed onto a stack, and the calculations are performed according to the RPN sequence to obtain the final Boolean result. This interpreted execution method avoids the overhead of re-parsing the string each time an evaluation is performed.

[0116] S403: If the calculation result is true, then the vehicle status data is determined to meet the constraint conditions.

[0117] A true result indicates that the current vehicle status data and time information fully satisfy all constraints defined in the Boolean expression associated with the permission. In this case, the PEPS controller allows the execution of the corresponding component operation request and issues the permission command to the controller of the target component.

[0118] In some examples, taking vehicle speed constraints as an example, if the Boolean expression of the constraint condition is "(vehicle speed < 5) AND (gear == P)", and the current vehicle speed read by the CAN bus is 3 km / h, and the gear is P, then both sub-conditions are true, the result of the logical AND operation is true, and the constraint condition is determined to be satisfied. At this time, the PEPS controller sends an execution permission command to the target component controller through the CAN bus, and the component controller performs the corresponding operation (such as unlocking the door, starting the air conditioner, etc.).

[0119] It should be noted that when a constraint includes both vehicle state constraints and time constraints, all constraint sub-conditions must be satisfied simultaneously for the condition to be considered true. For example, if the constraint is "(vehicle speed == 0) AND (current time BETWEEN '09:00' AND '17:00')", the result will only be true if the vehicle speed is 0 and the current time is between 9:00 AM and 5:00 PM. If any sub-condition is not satisfied, the result will be false.

[0120] In a possible implementation, for temporary permissions involving usage limits, after the calculation result is true, the PEPS controller also increments the usage counter maintained in non-volatile memory by 1. For example, if the temporary authorization credential defines "maximum usage count ≤ 3", when the first operation is determined to meet the constraint and allowed to execute, the PEPS controller increments the usage count corresponding to that permission from 0 to 1. When subsequent operations continue to be evaluated, in addition to checking the Boolean expression, it is also necessary to check whether the current usage count is less than the maximum usage count. If the maximum usage count has been reached, even if the Boolean expression result is true, execution will be refused and a "maximum usage count reached" message will be returned to the digital key.

[0121] S404: If the calculation result is false, the vehicle status data is determined not to meet the constraints.

[0122] When a constraint is determined not to be met, the PEPS controller returns a rejection message to the user. The message includes the specific constraint that is not met, such as the vehicle speed being non-zero and therefore inoperable, or the current time period being outside the authorized range.

[0123] In a possible implementation, a rejection message is sent to the digital key via near-field communication, and the digital key prompts the user via a pop-up window or voice message. The content of the message is dynamically generated based on the type of constraint. For example, if the vehicle speed constraint is not met, the message will say, "The current vehicle speed is XX km / h. You need to reduce the vehicle speed to below 5 km / h before you can operate." If the time constraint is not met, the message will say, "The current time period is not within the authorized range (authorized time period: 8:00-20:00)."

[0124] The processes shown in S401-S404 above obtain the Boolean expression in the constraint conditions, substitute the vehicle status data and current time information into the logical operation, and determine whether the constraint conditions are met based on the operation result. This realizes dynamic permission constraints on vehicle status and time, avoids the execution of component operations when safety conditions are not met, and improves the operational safety in multiple scenarios.

[0125] like Figure 5 The diagram shown is a fifth step of a vehicle access control method provided in an embodiment of this application, including the steps shown below.

[0126] S501: In response to a temporary authorization operation initiated by the licensor through the vehicle control interface or digital key button combination, generate an authorization certificate.

[0127] The authorization credential includes the target user's identity, authorized components, constraints, and validity period.

[0128] In some examples, the authorization certificate also includes a version number, serial number, effective date, expiration date, and digital signature.

[0129] It should be noted that the digital signature in the authorization credential uses the SM2 elliptic curve public-key cryptography algorithm. The authorizing party uses its private key to sign the credential digest (version number, serial number, target identity, authorized component, constraints, and validity period). The target digital key and the PEPS controller use the authorizing party's public key to verify the signature's validity. The serial number is a randomly generated 16-byte random number. The PEPS controller maintains a list of used serial numbers (a circular buffer with a capacity of 64 entries) to prevent replay attacks. If the serial number in the received authorization credential is already in the list, the credential is rejected and an exception is logged.

[0130] Authorizing parties include vehicle owners and users with temporary authorization initiation permissions.

[0131] The vehicle control interface is a graphical configuration interface provided by the vehicle infotainment system, which supports the selection of target users, authorized components, constraints, and authorization duration.

[0132] The digital key button combination includes a predefined button sequence, such as long-pressing the unlock button for 3 seconds to enter the authorization mode, short-pressing to cycle through the target identity, long-pressing to increase the duration, short-pressing to decrease the duration, and double-clicking to confirm and send, which is used to initiate temporary authorization when disconnected from the vehicle's infotainment system.

[0133] In a possible implementation, temporary authorization can also be initiated via the authorizing party's mobile application (APP). The APP establishes a connection with the PEPS controller via near-field communication, generates authorization credentials internally, and transmits them to the PEPS controller through a secure channel. This method is suitable for scenarios where the authorizing party is not near the vehicle, but requires that the authorizing party's mobile APP has been pre-bound to the vehicle and has remote authorization permissions.

[0134] S502: Send the authorization credentials to the target digital key via near-field communication.

[0135] Near-field communication includes Bluetooth Low Energy (BLE) and NFC (Near Field Communication). BLE has a transmission distance of less than 5 meters, and NFC has a transmission distance of less than 10 centimeters, with a transmission time of less than 500ms. If the target digital key is not within the effective communication range, the PEPS controller will notify the authorizing party that the target user is not within range.

[0136] In a possible implementation, the PEPS controller first attempts to locate the device address of the target digital key via BLE broadcast. If a response is received within 5 seconds, a BLE connection is established and authorization credentials are sent. If no response is received, the authorizing party is prompted to bring the target digital key close to the NFC sensing area (usually located on the center console inside the vehicle or the B-pillar outside the vehicle) and send it via NFC. The BLE method is suitable for scenarios where both the authorizing party and the target user are outside the vehicle and relatively close, while the NFC method is suitable for situations where the user is already inside the vehicle or near the vehicle.

[0137] S503: Receive confirmation information returned by the target digital key.

[0138] The confirmation message is signed by the private key of the target digital key. After receiving the authorization credential, the target digital key displays an authorization digest to the target user. The authorization digest includes the authorized identity type, authorized components, constraints, and validity period. The target user confirms acceptance (e.g., double-clicking the unlock button) or rejects (e.g., long-pressing the unlock button) via the digital key buttons. After confirmation, the digital key signs the confirmation message.

[0139] It should be noted that the private key of the target digital key is stored in the secure element or trusted execution environment of the digital key and cannot be read externally. The signing process is completed within the secure environment to ensure the non-repudiation of the confirmation message. The digest of the confirmation message includes the serial number of the authorization credential and an acceptance flag to prevent replay attacks.

[0140] S504: Verify the signature of the confirmation message, and after the signature verification is successful, write the temporary permission record corresponding to the authorization credential into the permission configuration information.

[0141] The PEPS controller holds the public key corresponding to the target digital key, which is used to verify the signature of the confirmation information. After successful signature verification, the temporary permission record is added to the temporary permission partition of the permission configuration information, and the authorization status is marked as activated.

[0142] In a possible implementation, the temporary permission partition and the permanent permission partition are physically separated. Temporary permission records are organized in the form of a linked list, and each record contains all fields of the authorization credential and an activation timestamp. During a query, the PEPS controller queries both the permanent permission partition and the temporary permission partition simultaneously. If permission records for the same identity and component exist in both partitions, the temporary permission partition takes precedence (temporary overrides permanent), thereby achieving flexible temporary authorization.

[0143] S505: Start a timer to keep track of the time. When the timer reaches the effective duration of the temporary permission record, delete the temporary permission record from the permission configuration information.

[0144] The timer is a hardware timer of the PEPS controller that periodically scans the expiration time of temporary permission records. When the current time exceeds the expiration time, the corresponding permission record is automatically deleted. In addition, the authorizing party can also actively revoke the issued temporary authorization at any time through the vehicle interface or digital key button combination. The revocation command is sent to the target digital key via near-field communication, and the target digital key deletes the authorization certificate immediately upon receiving the revocation command.

[0145] In a possible implementation, a hardware timer triggers an interrupt every 10 seconds. The interrupt service routine traverses the temporary permission partition list, deletes all records with expiration times less than the current time, and releases the corresponding storage space. During active revocation, the authorizing party sends an instruction containing the target serial number and a revocation command. After verifying the authorizing party's identity, the PEPS controller deletes the matching temporary permission record and sends a revocation notification to the target digital key.

[0146] The processes described in S501-S505 above involve the licensor initiating temporary authorization via the vehicle control interface or digital key button. This generates an authorization credential containing the target user's identity, authorized components, constraints, and validity period. This credential is then sent to the target digital key via near-field communication. After verifying the confirmation information from the target digital key's private key signature, the temporary permission record is written into the permission configuration information and automatically deleted by a timer when the validity period expires. This achieves localized, fine-grained temporary authorization and automatic revocation. The authorization process does not rely on the cloud, making it convenient and highly secure. Furthermore, digital signatures and serial numbers are used throughout the process to prevent forgery and replay attacks on the authorization credential.

[0147] like Figure 6 The diagram shown is a sixth step of a vehicle access control method provided in an embodiment of this application, including the following steps.

[0148] S601: When multiple authorized component operation requests target the same component, conflict arbitration is performed based on preset user identity priority and operation type priority to determine the request that takes priority.

[0149] User identity priority is determined according to a preset identity priority sequence, which, from highest to lowest priority, includes: vehicle owner (priority 6), family member (priority 5), rental user (premium version priority 4), visitor / rental user standard version (priority 3), chauffeur / novice driver / test driver (priority 2), and service personnel (repair technician / delivery person) (priority 1). Operation type priority is determined according to a preset operation priority sequence, which, from highest to lowest priority, includes: safety operations (priority 3, such as emergency door unlocking, hazard warning light activation), functional operations (priority 2, such as door opening / closing, air conditioning adjustment, window control), and setting operations (priority 1, such as seat memory storage, volume preset, permission configuration modification).

[0150] It should be noted that the values ​​of 0.6 for identity priority and 0.4 for operation priority are derived from numerous priority conflict simulation experiments in multi-user scenarios. This weight ratio ensures the priority of users with higher identities while allowing security-related operations (operation priority 3) to still have a chance to be executed when identity priorities are lower. For example, the overall priority of a delivery person (identity priority 1) initiating a security-related operation (operation priority 3) is 1×0.6+3×0.4=1.8, while the overall priority of a vehicle owner (identity priority 6) initiating a settings-related operation (operation priority 1) is 6×0.6+1×0.4=4.0, and the vehicle owner still has priority. However, if the difference in identity priorities is not significant (e.g., a family member with priority 5 initiates a settings-related operation with an overall priority of 5×0.6+1×0.4=3.4, while a visitor with priority 3 initiates a security-related operation with an overall priority of 3×0.6+3×0.4=3.0, and the family member has priority), it reflects both the authority of identity and the urgency of security operations.

[0151] In some examples, the PEPS controller obtains the user identity priority value and operation type priority value corresponding to each component operation request, calculates the overall priority, and determines the request with the highest overall priority as the priority for execution. Requests that are not executed are placed in a waiting queue or receive a conflict notification. The overall priority is calculated using the weighted formula: Overall Priority = Identity Priority × 0.6 + Operation Priority × 0.4. When multiple component operation requests have the same overall priority, the priority for execution is determined by the order in which the requests arrive. The waiting queue has a preset upper limit (e.g., 10), and automatically exits if the waiting time exceeds a preset duration (e.g., 60 seconds).

[0152] In a possible implementation, requests in the waiting queue are ordered in descending order of overall priority. When the currently executing request completes, the PEPS controller retrieves the next request from the head of the waiting queue for execution. If a new, higher-priority request arrives during the waiting period, the queue is reordered, and the new request may be inserted at the head of the queue to get an execution opportunity. When the waiting queue is full, newly arriving lowest-priority requests are discarded, and a "request rejected, waiting queue full" notification is returned to the corresponding digital key.

[0153] Optionally, when multiple authorized component operation requests target the same component, conflict arbitration is performed based on preset user identity priority and operation type priority to determine the priority of the request. The implementation process can be found in [link to relevant documentation]. Figure 7 The steps are shown.

[0154] S602: Control the vehicle to perform the component operation corresponding to the priority request.

[0155] The PEPS controller sends a control permission command to the controller of the target component via the CAN bus, and the component controller executes the corresponding component operation and returns the execution result.

[0156] In some examples, the frame format for the control enable command sent by the PEPS controller via the CAN bus is: ID (target component controller address), DLC (data length), Data[0] = operation type code, Data[1] = execution sequence number, and CRC checksum. After execution, the component controller returns an execution status frame, which includes the execution sequence number, result code (e.g., 0x00 success, 0x01 failure, 0x02 timeout, etc.), and execution feedback data (e.g., current window position). After receiving the status frame, the PEPS controller feeds back the execution result to the corresponding digital key via near-field communication.

[0157] It should be noted that for operations involving security (such as granting driving privileges), the PEPS controller will perform a secondary confirmation before sending the control permission command, requiring the digital key to send the confirmation command again within 1 second to prevent accidental triggering.

[0158] Optionally, component operation requests are updated in real time. When a new component operation request is detected, adaptive control must be performed on the currently executing component operation based on the user identity priority and operation type priority of the new component operation request. For details on the adaptive control process, please refer to [link to relevant documentation]. Figure 8 The steps are shown.

[0159] The processes shown in S601-S602 above resolve the control chaos caused by the lack of an arbitration mechanism when multiple requests target the same component. This is achieved by arbitrating conflicts based on user identity priority and operation type priority.

[0160] like Figure 7 The diagram shown is a seventh step of a vehicle access control method provided in this application embodiment, including the following steps.

[0161] S701: Obtain the user identity priority value and operation type priority value corresponding to multiple allowed component operation requests.

[0162] The user identity priority value is determined based on preset user identity priorities, which are listed in descending order as follows: vehicle owner (priority 6), family member (priority 5), rental user - premium version (priority 4), visitor / rental user - standard version (priority 3), chauffeur / new driver / test driver (priority 2), and service personnel (repair technician / delivery person) (priority 1). The operation type priority value is determined based on preset operation type priorities, which are listed in descending order as follows: safety operations (priority 3), functional operations (priority 2), and settings operations (priority 1).

[0163] In a possible implementation, both user identity priority and operation type priority are stored as enumerations in the read-only memory of the PEPS controller, and the corresponding values ​​are retrieved via a fast table lookup. For example, identity type enumeration value 0x01 corresponds to priority 6, and 0x02 corresponds to priority 5.

[0164] S702: Calculate the overall priority of operation requests for each component.

[0165] The overall priority is calculated by weighting the user's identity priority value and the operation type priority value, and can be expressed by the formula: Overall Priority = Identity Priority × 0.6 + Operation Priority × 0.4.

[0166] It should be noted that the overall priority calculation result is a floating-point number, but for easier comparison and sorting, it can be multiplied by 100 and converted to an integer. For example: identity priority 6 × 60 + operation priority 3 × 40 = 360 + 120 = 480. The PEPS controller uses integer arithmetic to avoid floating-point overhead.

[0167] In some examples, when a designated driver (priority 2) initiates a window closing operation (function type, priority 2), the overall priority is 2 × 0.6 + 2 × 0.4 = 2.0; when the car owner (priority 6) initiates a seat memory setting operation (setting type, priority 1), the overall priority is 6 × 0.6 + 1 × 0.4 = 4.0, with the car owner's request having priority. If the delivery person (priority 1) initiates an emergency unlock operation (safety type, priority 3), the overall priority is 1 × 0.6 + 3 × 0.4 = 1.8, which is still lower than the family member's setting operation (5 × 0.6 + 1 × 0.4 = 3.4), demonstrating the dominant role of identity differences.

[0168] S703: The component operation request with the highest overall priority is determined as the request to be executed first.

[0169] For requests not designated as priority, the PEPS controller adds them to a waiting queue. The waiting queue has a preset limit (e.g., 10 requests) and automatically exits after a preset time (e.g., 60 seconds), returning a conflict notification to the corresponding digital key. When multiple component operation requests have the same overall priority, the priority request is determined by the order in which they arrive.

[0170] In a possible implementation, the waiting queue uses a priority queue data structure, with a comprehensive priority as the key, and the highest priority request at the top of the heap. Whenever a new request arrives, it is inserted into the heap. If the heap size exceeds the upper limit, the lowest priority request that arrived latest is discarded. Once the current request is completed, the PEPS controller retrieves the next request from the top of the heap for execution. This implementation balances fairness and priority.

[0171] The processes shown in S701-S703 above obtain the user identity priority value and operation type priority value corresponding to the operation request of each component, calculate the comprehensive priority, and determine the request with the highest comprehensive priority as the priority for execution. This realizes quantitative arbitration of multi-user conflicts, avoids operational chaos, ensures that high-priority users and key operations are executed first, and has high arbitration decision efficiency.

[0172] like Figure 8 The diagram shown is an eighth step of a vehicle access control method provided in this application embodiment, including the following steps.

[0173] S801: When a component operation request for a safety-related operation is detected, the currently executing non-safety-related operation is interrupted, and the component operation request for a safety-related operation is executed first.

[0174] Safety-related operations include emergency door unlocking and hazard warning light activation, which have the highest priority. When a non-safety-related operation is interrupted, the PEPS controller sends an interruption notification to the digital key that was interrupted.

[0175] In a possible implementation, when an ongoing non-safety operation is interrupted, the PEPS controller sends an "immediate stop" command to the target component controller. The command frame contains the execution sequence number of the current operation. Upon receiving this command, the component controller stops the current action (e.g., the window motor stops) and returns to its current position state. The PEPS controller then sends an interruption notification frame to the source digital key, containing the operation ID and reason code of the interrupted operation (e.g., 0x01 indicates a safety operation preemption). After the safety operation is completed, if the interrupted operation is still in a recoverable state (e.g., the window is not fully closed) and the original requesting digital key is still within its valid range, the PEPS controller can ask the user whether to resume the operation.

[0176] S802: When a digital key with a higher user priority is detected approaching the vehicle, the operation of the component corresponding to the current lower user priority is suspended, and a suspension notification is sent to the digital key whose operation is suspended.

[0177] The PEPS controller continuously monitors the identity of the digital key approaching the vehicle. When it detects a digital key with a higher user priority entering the valid range, it triggers the aforementioned pause mechanism. For example, when the vehicle owner approaches the vehicle, the system pauses the current driver's or delivery person's operations. When the digital key with the higher user priority leaves the valid range, the paused component operations automatically resume as long as the temporary permission record remains valid.

[0178] In a possible implementation, when pausing a low-priority operation, the PEPS controller records the current operation context (component, operation type, progress percentage), sends a pause notification to the low-priority digital key (e.g., reason code 0x02 indicating a high-priority user is approaching), and stops the current operation. Simultaneously, the PEPS controller starts a "high-priority user departure detection" timer to continuously monitor the signal strength of the high-priority digital key. When its RSSI falls below the departure threshold (indicating the user has moved away from the vehicle), the paused operation context is automatically restored, and a resumption notification (containing progress information, allowing the user to choose to continue or abandon) is sent to the low-priority digital key.

[0179] The process shown in S801-S802 above interrupts the current non-security operation and prioritizes the security operation when a security operation request is detected, ensuring that the security operation always responds first; when a digital key corresponding to a higher user identity priority is detected approaching the vehicle, the current low-priority operation is paused and a pause notification is sent, realizing automatic permission rollback when a high-priority user approaches, further improving security and user experience in multi-user scenarios.

[0180] In practical engineering implementation, the vehicle access control method shown in this application can be deployed in a PEPS controller and can be implemented using a three-layer architecture. The first layer is the identity recognition layer, responsible for digital key identity recognition and basic access query, including the PEPS antenna array, digital key identity recognition unit, and basic access configuration storage unit. The second layer is the state perception layer, responsible for collecting the state information required for access determination, including the vehicle state detection module and the component state detection module. The vehicle state detection module reads vehicle speed, gear position, power status, and door lock status via the CAN bus, while the component state detection module obtains the door status, trunk position, and hood status through the position feedback signals of each component actuator. The third layer is the access execution layer, responsible for access verification, constraint determination, conflict arbitration, and component control command issuance, including the access verification unit, constraint determination unit, conflict arbitration unit, temporary access management unit, and configuration management unit. The total access verification response time is: identity recognition 80ms + access query 0.5ms + constraint determination 30ms + CAN command 50ms = approximately 161ms.

[0181] The method shown in the embodiments of this application will be described below in conjunction with specific application scenarios.

[0182] Application Scenario 1: Family members without driver's licenses: The car owner assigns a digital key to a minor child as a "family member" and sets the "driving permission" flag for that identity to be prohibited in the permission configuration information; when the woman approaches the vehicle with the digital key and attempts to start the vehicle, the PEPS controller queries the permission configuration information based on the child's user identity and the target component's "driving permission" and finds that the permission is prohibited, thus refusing to execute the start operation; the child can normally perform permitted operations such as opening the car door, opening the trunk, operating the windows and air conditioning.

[0183] Application Scenario 2: Temporary Authorization for Delivery Personnel: The vehicle owner initiates a temporary authorization operation through the in-vehicle control interface, selects the "delivery person" identity, authorizes the trunk as the authorized component, and sets the constraints to "limited opening to 50% height" and "validity period of 5 minutes." The PEPS controller generates a local authorization certificate (including identity ID, permission bitmap, serial number, effective / expiring time, and SM2 signature) and sends it to the delivery person's digital key via BLE. After the delivery person confirms acceptance, the PEPS controller adds the temporary permission record to the permission configuration information. When the delivery person approaches the vehicle, they can only perform the trunk's limit opening operation. After 5 minutes, the temporary permission record is automatically deleted, and the trunk is relocked. Throughout the entire process, the delivery person cannot open any doors or start the vehicle.

[0184] Application Scenario 3: Conflict Arbitration in Designated Driver Services: The designated driver, holding a digital key identifying them as a "designated driver," is performing a driving operation (a functional operation, priority 2); the vehicle owner, holding a digital key identifying them as the "owner," approaches the vehicle and initiates a seat adjustment request (a settings operation, priority 1). The PEPS controller detects multiple authorized component operation requests for the same target component (seat system). It calculates the overall priority of the designated driver's request as 2 × 0.6 + 2 × 0.4 = 2.0, and the overall priority of the vehicle owner's request as 6 × 0.6 + 1 × 0.4 = 4.0. The vehicle owner's request is determined as the priority request, the designated driver's seat operation is suspended, and a suspension notification is sent to the designated driver's digital key. After the vehicle owner completes their operation and leaves, the designated driver's permissions are automatically restored (if the authorization is still valid).

[0185] Application Scenario 4, Maintenance and Repair Scenario: The car owner initiates a temporary authorization for the repair technician, selecting the "Repair Technician" identity. Authorized components include the car doors, trunk, hood, and diagnostic interface, with the constraint that it is "valid within the authorized period (e.g., 2 hours)". After obtaining authorization, the repair technician can open the car doors to enter the vehicle, open the hood to perform repairs, and use the diagnostic interface to read fault codes, but cannot start the vehicle or open the glove box. After the repair is completed, the car owner actively revokes the authorization, or the temporary permission record is automatically deleted after the authorization period expires.

[0186] Application Scenario 5: Multiple users operating the same component simultaneously: When a delivery person is placing items in the trunk, and the vehicle owner approaches the vehicle, the PEPS controller detects the approach of a digital key corresponding to a higher user priority (vehicle owner priority 6 > delivery person priority 1), suspends the delivery person's trunk operation, and sends a pause notification to the delivery person's digital key (e.g., a vibration indicating "Permission suspended"). After the vehicle owner completes the operation, if the delivery person's temporary permission is still valid, it will be automatically restored.

[0187] Application Scenario Six: Permission Configuration Management and Backup / Restore: Vehicle owners can view the permission configurations for all identity types through the vehicle's infotainment system, and can filter by identity type or component type. When a vehicle owner modifies the permission configuration (e.g., adjusting the speed limit for valet parking from 60km / h to 40km / h), confirmation via the vehicle owner's digital key is required. The modification takes effect immediately and is saved to the user-defined configuration partition on non-volatile memory. Vehicle owners can also export the permission configuration to a USB flash drive (encrypted format) or import and restore it from a USB flash drive. During import, the configuration file version compatibility and encryption signature are verified. One-click restoration of factory default configuration is supported (requires vehicle owner password confirmation).

[0188] The above application scenarios are only some examples provided by the embodiments of this application. Those skilled in the art can understand that, based on the technical solutions provided by this application, more permission control methods adapted to different user identities and usage scenarios can be derived.

[0189] like Figure 9 The diagram shown is a schematic representation of a vehicle architecture according to an embodiment of this application. The vehicle includes a processor 901, a memory 902, and a bus 903. The processor 901 and the memory 902 are connected via the bus 903. The memory 902 is used to store programs, and the processor 901 is used to run the programs. When the programs run, they execute the vehicle access control method provided in this application. The vehicle access control method can be encapsulated into the unit shown below.

[0190] The identity recognition unit 100 is used to obtain the identity identifier of the digital key approaching the vehicle and determine the corresponding user identity.

[0191] Optionally, the identity recognition unit 100 is specifically used to: send a wake-up signal through a low-frequency antenna to trigger the digital key approaching the vehicle to calculate a response value and return the response value and its identity identifier; verify the response value, and after successful verification, extract the identity type prefix from the identity identifier; and determine the user identity corresponding to the digital key based on the identity type prefix.

[0192] The request receiving unit 200 is used to receive a component operation request that indicates the target component and the operation type.

[0193] The permission query unit 300 is used to query the corresponding permissions from the permission configuration information based on the user identity and the target component; the permission configuration information defines the operation permissions of multiple user identities for multiple vehicle components.

[0194] Optionally, the permission query unit 300 is specifically used to: obtain the corresponding permission record from the permission configuration information based on the identity identifier corresponding to the user's identity and the component identifier corresponding to the target component; determine whether the permission is allowed, prohibited, or conditionally allowed based on the permission flag and operation type in the permission record; when the permission is conditionally allowed, obtain the corresponding constraint pointer from the permission record; and read the constraint corresponding to the permission based on the constraint pointer.

[0195] The condition determination unit 400 is used to determine whether the current vehicle status data meets the constraint conditions corresponding to the permission when the permission is conditionally allowed, and to allow or refuse to execute the component operation request based on the determination result.

[0196] Optionally, the condition determination unit 400 is specifically used for: obtaining the constraint conditions corresponding to the permission; the constraint conditions include at least one constraint type and its Boolean expression; substituting the current vehicle status data and current time information into the Boolean expression for logical operation to obtain the operation result; if the operation result is true, the vehicle status data is determined to meet the constraint conditions; if the operation result is false, the vehicle status data is determined not to meet the constraint conditions.

[0197] The conflict arbitration unit 500 is used to arbitrate conflicts based on preset user identity priority and operation type priority when multiple authorized component operation requests are directed to the same target component, and to determine the request that is to be executed first.

[0198] Optionally, the conflict arbitration unit 500 is specifically used to: obtain the user identity priority value and operation type priority value corresponding to multiple allowed component operation requests; the user identity priority value is determined according to the preset user identity priority; the operation type priority value is determined according to the preset operation type priority; calculate the comprehensive priority of each component operation request; and determine the component operation request with the highest comprehensive priority as the request to be executed first.

[0199] The execution control unit 600 is used to control the vehicle to perform the component operation corresponding to the priority execution request.

[0200] Optionally, the execution control unit 600 is also configured to: interrupt the currently executing non-safety operation when a component operation request for a safety-related operation is detected, and prioritize the execution of the component operation request for the safety-related operation; and suspend the component operation corresponding to the current low user identity priority when a digital key corresponding to a higher user identity priority is detected approaching the vehicle, and send a suspension notification to the digital key whose operation has been suspended.

[0201] The temporary authorization unit 700 is used to generate a local authorization credential in response to a temporary authorization operation, send the authorization credential to the target digital key via near-field communication, and add the corresponding temporary permission record to the permission configuration information after receiving the confirmation information returned by the target digital key.

[0202] Optionally, the temporary authorization unit 700 is further configured to: generate an authorization credential in response to a temporary authorization operation initiated by the authorizing party through the vehicle control interface or digital key button combination; the authorization credential includes the target user identity, authorized component, constraints, and validity period; send the authorization credential to the target digital key via near-field communication; receive confirmation information returned by the target digital key; sign the confirmation information with the private key of the target digital key; verify the signature of the confirmation information, and after the signature verification is successful, write the temporary permission record corresponding to the authorization credential into the permission configuration information; start a timer to count down, and when the countdown time reaches the validity period of the temporary permission record, delete the temporary permission record from the permission configuration information.

[0203] The units described above achieve fine-grained permission management at the component level through locally stored identity-component-condition three-dimensional permission configuration, solving the problem of coarse-grained permission control in existing technologies. Through a local temporary authorization and automatic revocation mechanism based on near-field communication, rapid temporary authorization in offline environments is achieved, resolving the issues of offline failure and cumbersome operation caused by reliance on cloud communication. Furthermore, through conflict arbitration based on user identity priority and operation type priority, and a mechanism that prioritizes security operations and automatically rolls back lower-priority users when they are nearby, the control chaos caused by the lack of arbitration in simultaneous multi-user operations is resolved. Overall, the solution does not rely on a network connection, has a fast response speed, and balances operational security, orderliness, and ease of use in multi-user scenarios.

[0204] While several specific implementation details are included in the foregoing discussion, these should not be construed as limiting the scope of this application. Certain features described in the context of individual embodiments may also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may also be implemented individually or in any suitable sub-combination in multiple embodiments.

[0205] The above description is merely a preferred embodiment of this application and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of disclosure in this application is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-described concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features with similar functions disclosed in this application.

Claims

1. A vehicle access control method, characterized in that, include: Obtain the identity of the digital key that approaches the vehicle to determine the corresponding user identity; Receive a component operation request specifying the target component and operation type; Based on the user identity and the target component, query the corresponding permissions from the permission configuration information; The permission configuration information defines the operation permissions of multiple user identities for multiple vehicle components. When the permission is conditionally allowed, it is determined whether the current vehicle status data meets the constraint conditions corresponding to the permission, and the component operation request is allowed or denied based on the determination result.

2. The method according to claim 1, characterized in that, Obtain the identity of the digital key approaching the vehicle to determine the corresponding user identity, including: A wake-up signal is sent via a low-frequency antenna, triggering the digital key that approaches the vehicle to calculate a response value and return the response value and its identity identifier. Verify the response value, and if the verification is successful, extract the identity type prefix from the identity identifier; The user identity corresponding to the digital key is determined based on the identity type prefix.

3. The method according to claim 1, characterized in that, Based on the user identity and the target component, query the corresponding permissions from the permission configuration information, including: Based on the identity identifier corresponding to the user identity and the component identifier corresponding to the target component, obtain the corresponding permission record from the permission configuration information; Based on the permission flag in the permission record and the operation type, the type of permission shown in the permission record is determined; the type is one of allow, prohibit, or conditionally allow. When the permission is conditionally allowed, the corresponding constraint pointer is retrieved from the permission record; Based on the constraint pointer, read the constraint conditions corresponding to the permission.

4. The method according to claim 1, characterized in that, When the permission is conditionally allowed, determine whether the current vehicle status data meets the constraints corresponding to the permission, including: Obtain the constraints corresponding to the permission; the constraints include at least one constraint type and its Boolean expression. Substitute the current vehicle status data and current time information into the Boolean expression for logical operation to obtain the calculation result; If the calculation result is true, then the vehicle status data is determined to satisfy the constraint condition; If the calculation result is false, then the vehicle status data is determined not to meet the constraint conditions.

5. The method according to claim 1, characterized in that, The permission configuration information is temporarily authorized and updated in the following way: in response to the temporary authorization operation, a local authorization credential is generated, the authorization credential is sent to the target digital key via near-field communication, and after receiving the confirmation information returned by the target digital key, the corresponding temporary permission record is added to the permission configuration information.

6. The method according to claim 1, characterized in that, The permission configuration information is also temporarily updated through the following methods: In response to a temporary authorization operation initiated by the authorizing party through the vehicle control interface or digital key button combination, an authorization credential is generated; the authorization credential includes the target user's identity, authorized component, constraints, and validity period; The authorization credential is sent to the target digital key via near-field communication; Receive confirmation information returned by the target digital key; the confirmation information is signed with the private key of the target digital key; Verify the signature of the confirmation information, and after the signature verification is successful, write the temporary permission record corresponding to the authorization credential into the permission configuration information; Start a timer to keep track of the duration. When the timer reaches the validity period of the temporary permission record, delete the temporary permission record from the permission configuration information.

7. The method according to claim 1, characterized in that, The method further includes: When multiple authorized component operation requests target the same component, conflict arbitration is performed based on preset user identity priority and operation type priority to determine the request that takes precedence. Control the vehicle to perform the component operation corresponding to the priority request.

8. The method according to claim 7, characterized in that, When multiple authorized component operation requests target the same component, conflict arbitration is performed based on preset user identity priority and operation type priority to determine the request with priority, including: Obtain the user identity priority value and operation type priority value corresponding to multiple allowed component operation requests; the user identity priority value is determined according to a preset user identity priority; the operation type priority value is determined according to a preset operation type priority. Calculate the overall priority of each component's operation request; The component operation request with the highest overall priority will be selected as the request to be executed first.

9. The method according to claim 8, characterized in that, The method further includes: When a component operation request for a safety-related operation is detected, the currently executing non-safety-related operation is interrupted, and the component operation request for the safety-related operation is executed first. When a digital key corresponding to a higher user identity priority is detected approaching the vehicle, the operation of the component corresponding to the current lower user identity priority is suspended, and a suspension notification is sent to the digital key whose operation is suspended.

10. A vehicle, characterized in that, include: Processor, memory, and bus; The processor and the memory are connected via the bus; The memory is used to store a program, and the processor is used to run the program, wherein the program is executed by the processor to perform the vehicle access control method according to any one of claims 1-9.

Images