A door control method, device, equipment and medium

Abstract

This application discloses a vehicle door control method, device, equipment, and medium. The method includes: receiving at least two first operation requests through a standardized service interface; determining a corresponding target adapter based on an adapter identifier corresponding to each key type identifier; sending each first operation request to the corresponding target adapter and obtaining its feedback first key status data; performing centralized arbitration on the at least two first operation requests based on the first key status data to obtain an arbitration result; and generating a control command based on the arbitration result and sending it to the vehicle door control system and power system for execution. This application receives multiple operation requests through a unified interface and determines the corresponding target adapter to complete data adaptation, thereby performing centralized arbitration and collaborative control on the acquired multi-source key status data. This solves the problems of concurrent conflicts and software complexity caused by the decentralized processing of heterogeneous keys, and improves software efficiency and system management efficiency.

Description

Technical Field

[0001] This application relates to the field of vehicle control technology, and in particular to a door control method, device, equipment and medium. Background Technology

[0002] As the core interactive medium for vehicle entry and start systems, the efficiency of vehicle key management directly impacts user experience and vehicle security. With the development of intelligent connected vehicles, various key forms coexist, including remote control keys, Bluetooth keys, NFC (Near Field Communication) keys, UWB (Ultra-Wideband) keys, and remote control keys. How to achieve unified management and collaborative control of these heterogeneous keys has become a key technical issue in the field of vehicle control.

[0003] Existing solutions typically employ a distributed architecture, requiring each type of key to establish independent communication links and complete authentication with different execution units such as the door controller and power management system. When multiple keys make concurrent requests or different types of keys trigger operations simultaneously, the heterogeneous keys interact independently with different execution units, each requiring independent key status determination and decision-making. This can easily lead to task conflicts and control command confusion in multi-key concurrent scenarios, and also increases the software development complexity of distributed adaptation of heterogeneous communication protocols, affecting the real-time performance and reliability of vehicle entry control. Summary of the Invention

[0004] This application provides a door control method, device, equipment, and medium to solve the problems of concurrent conflicts and software complexity caused by the decentralized processing of heterogeneous keys in the prior art.

[0005] The technical solution adopted in this application is as follows: In a first aspect, this application provides a door control method, including: Receive at least two first operation requests through a standardized service interface; each first operation request includes a key type identifier. For each key type identifier, the corresponding target adapter is determined based on the adapter identifier corresponding to the key type identifier; Each first operation request is sent to the corresponding target adapter, and the first key status data fed back by the target adapter is obtained; Based on the status data of each first key, at least two first operation requests are centrally arbitrated to obtain an arbitration result; Based on the arbitration result, control commands are generated and sent to the door control system and power system to execute the control commands.

[0006] In one alternative of the first aspect, the first key status data includes key location information, key authentication status, and anti-theft authentication status; Based on the status data of each first key, at least two first operation requests are centrally arbitrated to determine the arbitration result, including: For each first operation request, the valid operation requests are obtained by filtering based on the corresponding first key status data and filtering conditions. Based on the key location information, determine the execution priority of each valid operation request; The filtering conditions include any of the following: The key authentication status is abnormal; The anti-theft authentication status is abnormal; The area type represented by the key location information is an invalid area.

[0007] In one alternative embodiment of the first aspect, the first key status data further includes a key validity identifier; Based on the key location information, the execution priority of each valid operation request is determined, including: The initial priority of each valid operation request is determined based on the area type represented by the key location information. The area type includes the in-vehicle area, the welcome area, and the outside area. The initial priority of a valid operation request corresponding to the in-vehicle area is higher than that of a valid operation request corresponding to the welcome area, and the initial priority of a valid operation request corresponding to the welcome area is higher than that of a valid operation request corresponding to the outside area. The initial priority is adjusted according to the validity level represented by the key validity identifier to obtain the target priority of the corresponding valid operation request; among them, the priority of valid operation requests with higher validity levels is higher than that of valid operation requests with lower validity levels.

[0008] In one alternative to the first aspect, the method further includes: The second operation request is received via the radio frequency antenna, and the corresponding second key status data is obtained. Based on the status data of each first key, at least two first operation requests are centrally arbitrated to obtain the arbitration result, including: Based on the status data of each first key and the status data of the second key, at least two first operation requests and second operation requests are centrally arbitrated to obtain an arbitration result.

[0009] In one alternative of the first aspect, the first operation request and / or the second operation request includes a door opening and power-on request; Control instructions are generated based on the arbitration result, including: In response to the request to open the door and power on, the target key is determined based on the arbitration result; If the target key is a remote key corresponding to the second key status data, and the area type represented by the key location information in the second key status data is the in-vehicle area, then the first authentication process is executed based on the second key status data to obtain the first authentication result; wherein, the first authentication process includes key authentication; If the first authentication result indicates that the key authentication status is normal, the authentication is deemed successful and a power-on control command is generated; otherwise, the first authentication process is executed based on the first key status data corresponding to the target key, and a power-on control command is generated after successful authentication.

[0010] In one alternative embodiment of the first aspect, the first operation request and / or the second operation request further include a brake-start request; Control instructions are generated based on the arbitration result, including: In response to the request to start by applying the brakes, the target key is determined based on the arbitration result; If the target key is a remote key corresponding to the second key status data, and the area type represented by the key location information in the second key status data is the in-vehicle area, then the second authentication process is executed based on the second key status data to obtain the second authentication result; wherein, the second authentication process includes key authentication and anti-theft authentication; If the second authentication result indicates that the key authentication status and the anti-theft authentication status are normal, then the authentication is deemed successful and a power-on control command is generated; otherwise, the second authentication process is executed based on the first key status data corresponding to the target key, and a power-on control command is generated after the authentication is successful.

[0011] In one alternative of the first aspect, the first operation request and / or the second operation request further include a lockout power-down request; Control instructions are generated based on the arbitration result, including: In response to the lockout power-off request, the target key is determined based on the arbitration result; Determine the region type represented by the key location information in the first or second state data corresponding to the target key; If the area type is in-vehicle area, an in-vehicle locking command is generated to control the door control system to lock and the power system to keep powered on. If the area type is an external area, an external locking command is generated to control the door control system to lock and the power system to power down.

[0012] Secondly, this application provides a door control device, comprising: The request receiving module is used to receive at least two first operation requests through a standardized service interface; wherein each first operation request includes a key type identifier; The adapter determination module is used to determine the corresponding target adapter for each key type identifier based on the adapter identifier corresponding to the key type identifier; The data acquisition module is used to send each first operation request to the corresponding target adapter and acquire the first key status data fed back by the target adapter; The centralized arbitration module is used to centrally arbitrate at least two first operation requests based on the status data of each first key, and obtain the arbitration result. The instruction generation module is used to generate control instructions based on the arbitration result and send the control instructions to the door control system and the power system to execute the control instructions.

[0013] Thirdly, this application provides an electronic device including a memory and a processor. The memory is used to store computer programs or instructions that, when executed by the processor, implement the method described in the first aspect or any of the alternative solutions of the first aspect.

[0014] Fourthly, this application provides a computer-readable storage medium. The storage medium stores a computer program or instructions that, when executed by a processor, implement the method described in the first aspect or any of the alternative solutions to the first aspect.

[0015] The beneficial effects of the technical solutions provided in some embodiments of this specification include at least the following: This application receives at least two first operation requests through a standardized service interface and determines the corresponding target adapter based on the key type identifier to complete data adaptation. It then performs centralized arbitration and collaborative control on the multi-source key status data. Unlike the decentralized processing method in the prior art where heterogeneous keys interact independently with different execution units, this application can realize unified access and centralized management of multiple key types, realize arbitration decision-making and collaborative execution in multi-key concurrent scenarios, meet users' convenient vehicle control needs in multiple scenarios, solve the problems of concurrency conflicts and software complexity caused by decentralized processing of heterogeneous keys, and significantly improve the response efficiency and system reliability of vehicle entry control. Attached Figure Description

[0016] 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 some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 A flowchart of a door control method provided in an embodiment of this application; Figure 2 This is a schematic diagram of the structure of the door control device provided in the embodiments of this application; Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0018] Embodiments of the present disclosure will now be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of the disclosure. Furthermore, descriptions of well-known structures and technologies are omitted in the following description to avoid unnecessarily obscuring the concepts of the present disclosure.

[0019] The accompanying drawings illustrate various structural schematics according to embodiments of the present disclosure. These drawings are not to scale, and some details have been enlarged for clarity, and some details may have been omitted. The shapes of the various regions and layers shown in the drawings, as well as their relative sizes and positional relationships, are merely exemplary and may deviate from reality due to manufacturing tolerances or technical limitations. Furthermore, those skilled in the art can design regions / layers with different shapes, sizes, and relative positions as needed.

[0020] In the context of this disclosure, when a layer / element is referred to as being "above" another layer / element, the layer / element may be directly above the other layer / element, or there may be an intermediate layer / element between them. Additionally, if a layer / element is "above" another layer / element in one orientation, then when the orientation is reversed, the layer / element may be "below" the other layer / element.

[0021] The following is a brief explanation of the terms used in this application: Key Management System: A software module integrated within the vehicle domain controller. As the core management unit of the vehicle entry system, it receives operation requests from heterogeneous keys such as remote control, Bluetooth, NFC, UWB, and remote keys. It performs key type identification, protocol adaptation, centralized arbitration, and sends collaborative control commands to the door control system and power system to achieve unified conflict resolution and collaborative control in multi-key concurrent scenarios.

[0022] Vehicle Domain Controller: A domain-level computing unit responsible for the centralized control of the vehicle's electronic systems. It integrates functions for managing doors, windows, lights, and vehicle entry. In this application, it serves as the hardware carrier of the key management system, providing standardized service interfaces and executing heterogeneous key protocol adaptation, centralized arbitration, and the issuance of cross-system collaborative control commands.

[0023] Vehicle entry system controller: A control unit dedicated to managing keyless entry and start functions. It interacts with the key and performs identity authentication through multi-mode communication methods such as radio frequency, Bluetooth, and UWB. In this application, it serves as a functional component of the key management system and is responsible for receiving heterogeneous key operation requests and performing status verification and permission determination.

[0024] Central Gateway: The data routing hub of the vehicle's heterogeneous network, enabling data exchange and forwarding between bus protocols such as CAN (Controller Area Network), LIN (Local Interconnect Network), and Ethernet. In this application, it serves as a communication node for multi-protocol data aggregation and supports cross-bus data access and distribution through standardized service interfaces.

[0025] Remote key: A physical key device based on radio frequency technology communication. It performs unlocking and locking operations and vehicle location operations by sending a rolling code encrypted signal through the pressing of a button. In this application, as a traditional key type, it establishes a direct communication link with the key management system through a radio frequency antenna to provide low-latency operation response.

[0026] Bluetooth key: A virtual key based on Bluetooth Low Energy technology, which runs on terminals such as smartphones and establishes an encrypted connection through a digital key. In this application, it is used as a heterogeneous digital key type and accessed through a standardized service interface to support seamless entry and identity authentication.

[0027] NFC key: A contactless digital key based on Near Field Communication (NFC) technology. It completes identity verification when the key is brought close to the vehicle's sensing area (<10cm) via high-frequency electromagnetic induction. In this application, it is used as a short-range communication key type for centralized arbitration and is suitable for special scenarios such as when the mobile phone is out of power.

[0028] UWB Key: A high-precision ranging digital key based on ultra-wideband (UWB) technology, which achieves centimeter-level positioning through time-of-flight measurement. In this application, it is used to accurately distinguish the spatial positions inside the vehicle, outside the vehicle, and the welcoming area, and supports arbitration decisions based on position priority.

[0029] Remote key: A wide-area virtual key based on cellular network (4G / 5G) or Wi-Fi, which transmits control commands via a mobile terminal APP through a cloud server. In this application, it is a type of long-distance control key with non-real-time connection, supporting remote locking and unlocking and pre-adjustment functions.

[0030] Passive Entry Zone (PE Zone): The effective sensing range of the keyless entry system, usually defined as the space within 1-2 meters of the door handle. The key position is identified by the vehicle's low-frequency antenna or UWB module. When the key enters this zone, it supports automatic unlocking when touching the door handle, and automatic locking when leaving the zone. In this application, it is distinguished from the "Welcome Zone" (3-5 meters, only triggering welcome lights) and the "Interior Zone" (inside the cabin, allowing start-up). The three constitute a gradient control strategy based on the key position, supporting position priority determination during arbitration.

[0031] As the intelligence and connectivity of automobiles continue to deepen, building an efficient and reliable multi-key collaborative management system has become a key technological path to optimize vehicle access control and ensure user safety and convenience. Currently, heterogeneous keys (such as remote control, Bluetooth, NFC, UWB, and remote keys) typically employ a point-to-point interaction architecture with independent links to the body controller and power management module. The inventors recognized that in real-world vehicle usage scenarios, due to the diverse communication protocols of various keys, random triggering sequences, and concurrent requests from multiple keys, traditional decentralized authentication decision-making mechanisms struggle to handle state synchronization and priority determination for multi-source requests. Furthermore, the independent key validity verification and location authentication by each execution unit easily leads to instruction conflicts and state competition in multi-task scenarios. The decentralized deployment of heterogeneous protocol adaptation logic also significantly increases system software coupling, making it difficult to ensure the real-time performance and reliability of vehicle access control.

[0032] Based on the aforementioned technical problems, the inventive concept of this application is as follows: At least two first operation requests are received through a standardized service interface, and the corresponding target adapter is determined based on the key type identifier to complete data adaptation. Then, the multi-source key status data is centrally arbitrated to obtain an arbitration result. Based on the arbitration result, control commands are generated and sent to the door control system and power system to execute coordinated control. This achieves centralized decision-making and cross-system coordinated response for concurrent multi-key requests, solves the problems of concurrent conflicts and software complexity caused by the decentralized processing of heterogeneous keys, ensures the consistency and reliability of control commands in multi-key scenarios, and improves user convenience and system management efficiency.

[0033] The technical solutions of this application and how they solve the aforementioned technical problems will be described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0034] It should be noted that the executor of this application may be, but is not limited to, vehicle body electronic control devices such as body domain controllers, vehicle entry system controllers, central gateways or vehicle key management terminals, which have the ability to manage standardized service interfaces, adapt heterogeneous key protocols, centrally arbitrate multi-source key status, and issue cross-system (door / power) collaborative control commands.

[0035] refer to Figure 1 , Figure 1 A flowchart illustrating a door control method provided in an embodiment of this application. Figure 1 As shown, the door control method includes at least the following steps: S101: Receive at least two first operation requests through the standardized service interface.

[0036] Specifically, during the door control process, the key management system listens for and receives operation requests from different key terminals through a standardized service interface. This standardized service interface is configured to support unified data access for multiple heterogeneous communication protocols (such as radio frequency, Bluetooth, near field communication NFC, ultra-wideband UWB, or cellular networks), and is used to convert the original requests transmitted at different physical layers into a first operation request in a unified format, thereby shielding the differences in underlying protocols and realizing centralized reception of multi-source data.

[0037] In practical applications, when a user triggers different types of key operations simultaneously or sequentially (e.g., the user presses the unlock button on a remote key and also initiates an unlock request for a Bluetooth key via a mobile app), the standardized service interface can simultaneously receive remote key operation requests from the radio frequency module and Bluetooth key operation requests from the Bluetooth module, i.e., the aforementioned "at least two first operation requests." Each first operation request carries a specific key type identifier, which indicates the key type corresponding to the current operation request (e.g., "0x01" represents a remote key, "0x02" represents a Bluetooth key, etc.), so that subsequent steps can determine the corresponding target adapter for data parsing and conversion based on this identifier.

[0038] S103: For each key type identifier, determine the corresponding target adapter based on the adapter identifier corresponding to the key type identifier.

[0039] Specifically, the key management system pre-stores a mapping table between key type identifiers and adapter identifiers. For each first operation request received by the standardized service interface, the system parses the key type identifier it carries, retrieves the corresponding adapter identifier based on the mapping table, and then determines the target adapter that the adapter identifier points to.

[0040] The aforementioned target adapter is a pre-configured protocol conversion module used to process communication protocol data for specific types of keys. There is a one-to-one correspondence between various heterogeneous keys and target adapters. For example, a remote key type identifier corresponds to an RF communication adapter, a Bluetooth key type identifier corresponds to a Bluetooth protocol adapter, an NFC key type identifier corresponds to a near-field communication adapter, a UWB key type identifier corresponds to an ultra-wideband positioning adapter, and a remote key type identifier corresponds to a network communication adapter.

[0041] In multi-key concurrent scenarios, the key management system executes the above-mentioned operation of determining the target adapter based on the key type identifier in parallel or serially for each of the at least two first operation requests received. This ensures that heterogeneous key data of different physical layer protocols can be routed to the corresponding target adapter for independent parsing and format conversion, thereby providing a protocol-independent standardized data foundation for subsequent centralized arbitration steps.

[0042] S105: Send each first operation request to the corresponding target adapter and obtain the first key status data fed back by the target adapter.

[0043] Specifically, after identifying the target adapter, the key management system sends each first operation request to the corresponding target adapter. Upon receiving the operation request, the target adapter establishes a communication connection with the corresponding key terminal based on its configured specific communication protocol, converts the operation request into a physical layer protocol data frame corresponding to the key type, and sends it to the key terminal. Simultaneously, it initiates a key status query request to the key terminal to obtain real-time status information. After the key terminal responds, the target adapter receives the raw response data from the key terminal, parses it into standardized first key status data, and feeds it back to the key management system.

[0044] The aforementioned first key status data includes, but is not limited to, key location information (such as in-vehicle area, out-of-vehicle area, welcome area, or invalid area), key validity indicators (such as battery status and signal strength), key authentication results (such as identity verification status), and key physical address identifiers. In multi-key concurrent scenarios, each target adapter independently and in parallel processes the corresponding type of first operation request. The key management system synchronously obtains the first key status data fed back by each target adapter, which corresponds one-to-one with the operation request, providing a complete decision-making basis for subsequent centralized arbitration steps.

[0045] S107: Based on the status data of each first key, at least two first operation requests are centrally arbitrated to obtain an arbitration result.

[0046] Specifically, after obtaining the first key status data from each target adapter, the key management system calls its internal centralized arbitration module, inputting the aforementioned at least two first operation requests and their corresponding first key status data into this module for unified decision-making. This centralized arbitration module, as the core arbitration decision-making unit of the key management system, is configured to perform comprehensive analysis and conflict detection on the location information, validity identifiers, authentication results, and timestamps in each key status data based on a preset arbitration rule engine, in order to determine the execution priority, execution sequence, or execution rejection policy for each operation request.

[0047] For example, in the door opening and power-on scenario, if the centralized arbitration module receives unlocking requests from both the remote key and the Bluetooth key simultaneously, the system first parses the location field in the status data of each key to determine if there is a key with a location status of "valid inside the vehicle." If the remote key is detected as being "outside the vehicle" while the Bluetooth key is "inside the vehicle," then based on the preset "inside key priority" rule, the arbitration result indicates that the unlocking and power-on request corresponding to the Bluetooth key should be executed first, while the repeated request from the remote key is postponed or rejected. As another example, in the vehicle exit and locking scenario, the centralized arbitration module continuously monitors the location changes in the status data of each key. When it detects that the location status of all keys has migrated from the welcome area or PE area to the invalid area, the arbitration result generates a locking command and a power-off command, triggering the automatic locking process upon exiting the vehicle. Through the above centralized arbitration mechanism, the key management system replaces the traditional independent decision-making mode of each execution unit, realizing unified conflict resolution and collaborative control decisions for multi-source heterogeneous key requests, ensuring the generation of conflict-free and time-appropriate arbitration results in concurrent operation scenarios.

[0048] S109: Generate control commands based on the arbitration results and issue control commands to the door control system and power system to execute the control commands.

[0049] Specifically, the key management system parses the arbitration result output by the centralized arbitration module and generates corresponding control commands based on the execution strategy indicated in the result (including the type of operation to be executed, the target system, and timing requirements). These control commands include door lock control commands (such as unlocking commands, locking commands, or trunk opening commands) sent to the door control system and power mode control commands (such as high-voltage power-on requests, low-voltage power-on commands, or power-off commands) sent to the power system.

[0050] The key management system sends the aforementioned control commands to the corresponding target systems via the vehicle's internal communication bus (such as CAN bus, LIN bus, or in-vehicle Ethernet). Specifically, the door control system receives and parses the door lock control commands, drives the door lock actuators to complete the door unlocking or locking actions, and feeds back the execution status to the key management system; the power system receives power mode control commands, executes the switching control of the vehicle's power state (such as switching from OFF to ACC or ON, or executing the high-voltage system power-off procedure), ensuring that the vehicle's power state and door state are coordinated and matched.

[0051] For example, in the door unlocking and power-on scenario, if the arbitration result indicates that the operation request corresponding to the key inside the vehicle is permitted, the key management system generates a control command set containing unlocking and power-on instructions, and simultaneously sends them to the door control system and the power system to achieve coordinated execution of door unlocking and vehicle power-on. In the locking and power-off scenario or when the vehicle is locked upon leaving the vehicle, if the arbitration result indicates that locking operation should be performed, locking and power-off instructions are generated to ensure that the vehicle power is safely cut off while the door is locked, avoiding redundant power consumption or safety hazards. Through the above cross-system collaborative control mechanism, this application achieves accurate implementation of arbitration decisions and linkage response of the door and power systems in multi-key scenarios.

[0052] Therefore, this application receives at least two first operation requests through a standardized service interface, realizing unified access and centralized management of heterogeneous key operation requests. This replaces the traditional distributed architecture where various keys need to interact independently with different execution units. Simultaneously, it determines the corresponding target adapter based on the key type identifier to complete data adaptation, and encapsulates the parsing and conversion function of heterogeneous communication protocols within each adapter, thereby reducing the software complexity of heterogeneous key processing. Furthermore, by acquiring the first key status data fed back by each target adapter and performing centralized arbitration, the independent decision-making processes dispersed across execution units are consolidated into a unified arbitration mechanism for conflict resolution and priority determination. Then, based on the arbitration result, control commands are generated and sent to the door control system and power system for coordinated control. This solves the problems of concurrent conflicts and software complexity caused by the distributed processing of heterogeneous keys, realizing centralized management and cross-system coordinated response of multi-source key requests, and improving the response efficiency and system reliability of vehicle entry control.

[0053] In some embodiments, the first key status data includes key location information, key authentication status, and anti-theft authentication status; Based on the status data of each first key, at least two first operation requests are centrally arbitrated to determine the arbitration result, including: For each first operation request, the valid operation requests are obtained by filtering based on the corresponding first key status data and filtering conditions. Based on the key location information, determine the execution priority of each valid operation request; The filtering conditions include any of the following: The key authentication status is abnormal; The anti-theft authentication status is abnormal; The area type represented by the key location information is an invalid area.

[0054] Specifically, after obtaining the first key status data from each target adapter, the key management system extracts the key authentication status, anti-theft authentication status, and key location information from the corresponding first key status data for each first operation request, and compares and verifies the above status information with preset filtering conditions. If an abnormality is detected in the key authentication status of a first operation request (e.g., authentication failure), an abnormality in the anti-theft authentication status (e.g., verification failed), or the key location information indicates that the current key is in an invalid area (i.e., outside the vehicle's sensing range), then the operation request is marked as an invalid request and filtered out; only when both the key authentication status and the anti-theft authentication status are normal and the key is located within the effective sensing area can the operation request pass the filtering and become a valid operation request, proceeding to the subsequent arbitration process.

[0055] Based on this, for each valid operation request obtained through the above screening, the centralized arbitration module further determines the execution priority based on its corresponding key location information. The system can hierarchically divide and sort the key locations associated with each valid operation request according to preset location priority rules (such as "in-vehicle area takes priority over PE area, PE area takes priority over welcome area"). The closer the key's location is to the vehicle's core control area, the higher the execution priority of its corresponding operation request, to ensure that the most clearly defined near-vehicle operation is responded to first in concurrent scenarios.

[0056] Furthermore, the specific criteria for the aforementioned filtering conditions can be dynamically configured based on the vehicle security strategy. For example, abnormal key authentication status includes key identity verification failure, key expiration, or positive signal replay attack detection; abnormal anti-theft authentication status includes engine immobilizer system verification failure or vehicle illegal intrusion warning triggering; invalid areas refer to spatial locations where the key's radio frequency signal strength is below the receiving sensitivity threshold or the UWB positioning coordinates exceed the preset geofence. Through the combined application of the above multi-dimensional filtering conditions, the system can effectively eliminate operation requests with security risks or uncertain locations before arbitration, avoiding invalid or malicious requests from consuming arbitration resources and downstream execution system bandwidth.

[0057] Thus, this embodiment employs a two-level arbitration mechanism of "screening-priority sorting." First, it uses filtering conditions to perform a preliminary security and validity screening of multi-source heterogeneous key requests, filtering out requests with authentication anomalies and invalid locations, significantly reducing the system resource consumption of invalid requests. Then, based on key location information, it determines the spatial priority of valid requests, ensuring that in-vehicle key operations take precedence over external key operations, overcoming control command conflicts and execution timing chaos in multi-key concurrent scenarios. Therefore, this embodiment further refines the execution granularity of the arbitration strategy, ensuring both the security of vehicle entry control and improving the rationality of responses in multi-key scenarios. This achieves efficient, secure, and orderly collaborative control of multi-source key requests, significantly improving the reliability of the vehicle entry system and the user experience.

[0058] In some embodiments, the first key status data further includes a key validity identifier; Based on the key location information, the execution priority of each valid operation request is determined, including: The initial priority of each valid operation request is determined based on the area type represented by the key location information. The area type includes the in-vehicle area, the welcome area, and the outside area. The initial priority of a valid operation request corresponding to the in-vehicle area is higher than that of a valid operation request corresponding to the welcome area, and the initial priority of a valid operation request corresponding to the welcome area is higher than that of a valid operation request corresponding to the outside area. The initial priority is adjusted according to the validity level represented by the key validity identifier to obtain the target priority of the corresponding valid operation request; among them, the priority of valid operation requests with higher validity levels is higher than that of valid operation requests with lower validity levels.

[0059] Specifically, when parsing the raw response data from the key, the target adapter extracts key location information, key authentication status, and anti-theft authentication status, and further obtains a key validity identifier. This validity identifier characterizes the current physical operational reliability of the key, including but not limited to the key battery level, RF / Bluetooth / UWB signal strength level, stability level of the key-vehicle communication link, or a combination thereof. By introducing this validity identifier, the system can further evaluate the real-time communication quality and energy status of the key corresponding to each valid operation request based on key location arbitration, providing multi-dimensional data support for subsequent dynamic priority adjustment and avoiding control response failures or false triggers due to key physical performance degradation.

[0060] Based on this, the centralized arbitration module first assigns an initial priority to each valid operation request based on the area type represented by the key location information corresponding to that request. The system can preset a three-level spatial priority gradient: when the key location information indicates that the key is in an area inside the vehicle (such as inside the cabin or driver's seat), the corresponding operation request is given the highest initial priority, indicating that the user is already inside the vehicle and the operation intention is most explicit; when the key is in a welcoming area (such as the PE sensing area near the door handle), a medium initial priority is assigned, indicating that the user is approaching the vehicle; when the key is in an area outside the vehicle but still within the effective sensing range, a lower initial priority is assigned. This initial priority setting follows the spatial logic of "the closer to the core control area of ​​the vehicle, the clearer the operation intention," ensuring priority response to operations near and inside the vehicle.

[0061] Furthermore, after determining the initial priority of each valid operation request, the centralized arbitration module retrieves the validity identifier of the corresponding key and dynamically adjusts the initial priority based on the validity level it represents, generating the final target priority. Specifically, the adjustment rules are as follows: for keys with high validity levels (e.g., sufficient power, excellent signal strength, stable communication link), the target priority of their corresponding operation requests is increased or maintained based on the initial priority; conversely, for keys with low validity levels (e.g., insufficient power, weak signal, intermittent communication interruptions), their target priority is reduced accordingly, or even filtered out directly if the validity is below a preset security threshold. Thus, the system not only considers the spatial location of the key but also comprehensively evaluates the reliability of its physical communication quality, ensuring that operation requests from high-reliability keys receive priority execution and avoiding control command loss or delays caused by low-quality communication links.

[0062] Therefore, this embodiment constructs a dual-priority arbitration mechanism of "spatial location classification + physical quality assessment." First, an initial priority reflecting the clarity of the user's intent is determined based on the type of area where the key is located. Then, each initial priority is dynamically corrected based on the key's validity identifier to generate a target priority that comprehensively reflects both spatial location and communication reliability. Because this embodiment incorporates the key's physical state (battery level, signal strength) into the arbitration decision, it overcomes the shortcomings of simply relying on location-based arbitration, which may lead to low-battery or weak-signal keys mistakenly triggering control commands. In addition to resolving control command conflicts in multi-key concurrent scenarios, it further ensures that operation requests from highly reliable keys are responded to first, thereby significantly improving the accuracy of vehicle entry control, system robustness, and user safety experience.

[0063] In some embodiments, the method further includes: The second operation request is received via the radio frequency antenna, and the corresponding second key status data is obtained. Based on the status data of each first key, at least two first operation requests are centrally arbitrated to obtain the arbitration result, including: Based on the status data of each first key and the status data of the second key, at least two first operation requests and second operation requests are centrally arbitrated to obtain an arbitration result.

[0064] Specifically, in addition to receiving first operation requests from heterogeneous keys such as Bluetooth, NFC, UWB, and remote keys through a standardized service interface, the key management system also directly receives second operation requests from traditional remote keys through radio frequency antennas deployed around the vehicle. This second operation request is transmitted in the form of a radio frequency signal, containing the physical identifier of the remote key and operation instructions (such as locking / unlocking and vehicle location). The system receives this signal through the radio frequency antenna and performs physical layer decoding to directly obtain the corresponding second key status data (including the remote key's radio frequency signal strength, rolling code verification status, and rough location estimation information). Therefore, the system is compatible with heterogeneous digital keys that require protocol adaptation while retaining native support for traditional remote keys, ensuring that traditional remote keys can participate in system arbitration without complex protocol conversions.

[0065] Building upon this foundation, the input data source for the centralized arbitration module has been expanded from a single standardized service interface to dual channels. The system acquires the first key status data (standardized data after protocol conversion) from each target adapter and the second key status data (native RF status data) from the RF antenna decoding module. These two types of data are then uniformly mapped to standardized status fields (such as location, validity, and authentication status) required for arbitration decisions. Based on this mapped complete status dataset, at least two first operation requests and a second operation request are centrally arbitrated. Regardless of whether the operation request originates from the standardized service interface or the direct RF connection channel, they are all incorporated into the same arbitration decision framework, and conflict detection and execution priority ranking are performed according to the same arbitration rules (such as location priority and authentication validity).

[0066] Furthermore, since remote keys are typically used for immediate locking and unlocking operations (such as pressing a button when a user approaches a vehicle with a physical key), their second operation requests often require low latency and high real-time response. In contrast, the first operation requests received by the standardized service interface (from Bluetooth / NFC / UWB / remote key) often involve multi-protocol handshakes and authentication processes, resulting in relatively longer response latency. Therefore, during centralized arbitration, for the second operation request (i.e., the remote key request) received via the radio frequency antenna, a higher arbitration response weight or a fast arbitration channel is assigned, provided that security filtering conditions are met, prioritizing the real-time response needs of the remote key. For the first operation request, complete protocol adaptation and multi-dimensional state arbitration are performed. Through differentiated arbitration strategy configuration, the system ensures centralized control while taking into account the differences in response characteristics between remote keys and digital keys.

[0067] Based on this, this embodiment achieves unified centralized arbitration management of heterogeneous digital keys and traditional remote keys by adding a direct radio frequency connection channel and expanding the arbitration input data source. Since this embodiment incorporates traditional remote keys (which typically bypass the central management system and interact directly with the vehicle controller) into the centralized arbitration scope of the key management system, it overcomes the cross-system task conflicts and state inconsistencies caused by remote keys and digital keys belonging to different control domains in traditional solutions. Simultaneously, through dual-channel reception and differentiated arbitration strategies, it retains the fast response characteristics of radio frequency keys while ensuring the uniqueness and timing rationality of control commands in multi-source concurrent scenarios using a centralized arbitration mechanism, thereby significantly improving the compatibility, real-time response capability, and control reliability of the vehicle key management system.

[0068] In some embodiments, the first operation request and / or the second operation request includes a door opening and power-on request; Control instructions are generated based on the arbitration result, including: In response to the request to open the door and power on, the target key is determined based on the arbitration result; If the target key is a remote key corresponding to the second key status data, and the area type represented by the key location information in the second key status data is the in-vehicle area, then the first authentication process is executed based on the second key status data to obtain the first authentication result; wherein, the first authentication process includes key authentication; If the first authentication result indicates that the key authentication status is normal, the authentication is deemed successful and a power-on control command is generated; otherwise, the first authentication process is executed based on the first key status data corresponding to the target key, and a power-on control command is generated after successful authentication.

[0069] Specifically, when the first operation request and / or the second operation request includes a request to open the door and power on, the key management system first invokes the aforementioned centralized arbitration result to determine a unique target key from at least two first operation requests and / or second operation requests participating in the arbitration. This target key is the key that wins the arbitration and has the highest execution priority at present (it may be a Bluetooth key, UWB key, or remote control key, etc.). Subsequent door lock control and power control will be based on the authentication status and permissions of this target key, ensuring that only the single key intent determined by the arbitration is executed in multi-key concurrent scenarios, avoiding conflicts between multiple source commands.

[0070] Based on this, the system further determines the type of the target key and its location. If the target key corresponds to the second operation request received via the radio frequency antenna (i.e., the remote key), and the key location information in its second key status data indicates that it is currently located inside the vehicle, the system prioritizes executing the first authentication process based on this second key status data. This first authentication process includes at least key authentication (such as remote key rolling code verification, encryption key matching, and other identity verification), utilizing the high real-time characteristics of direct radio frequency channel connection to quickly verify the validity of the remote key, thus meeting the response speed requirements of the door opening and power-on scenario.

[0071] It should be noted that if the remote key is determined not to be inside the vehicle, or if no valid remote key location signal is received within a preset time threshold (e.g., 5 seconds), the system sends a location query request to the Bluetooth key, NFC key, UWB key, and remote key through a standardized service interface, and listens for the first key status data fed back by each target adapter within the time threshold. If a valid in-vehicle location signal for any key is received within 5 seconds, the first authentication process is executed based on the corresponding key status data. If no valid in-vehicle location signal for any key is received after the timeout, it is determined that no valid key is inside the vehicle, the system generates a user reminder message (e.g., displays a prompt text on the dashboard or triggers a buzzer alarm) and terminates the power-on process to avoid invalid power-on requests.

[0072] Accordingly, the system performs branch processing based on the feedback results of the first authentication process. If the first authentication result indicates that the key authentication status is normal (e.g., successful rolling code matching, key verification passed), the system immediately determines that the authentication is successful and generates a power-on control command (e.g., high-voltage or low-voltage power-on enable command) to be sent to the power system, while simultaneously generating a door lock unlocking command. If the first authentication result indicates that the authentication is abnormal (e.g., signal decoding failure, rolling code mismatch, or communication interruption), a supplementary authentication mechanism is initiated. The system then re-executes the first authentication process based on the first key status data corresponding to the target key (i.e., data from Bluetooth, NFC, UWB, or remote key after protocol adaptation), and generates a power-on control command after successful authentication. This ensures that vehicle entry control can still be completed through the heterogeneous key even when remote key communication fails intermittently.

[0073] In view of this, this application embodiment constructs a control command generation mechanism for the door opening and power-on scenario, which is "arbitration to determine the target - priority fast authentication - failure fallback redundancy". Since this embodiment first determines a unique target key based on the arbitration result, it avoids control object confusion when multiple keys are concurrently used. Then, it prioritizes the use of the radio frequency direct connection channel for authentication of the remote key, fully utilizing its low latency and high real-time performance advantages to ensure rapid power-on response in normal scenarios. Simultaneously, by automatically falling back to a supplementary authentication process based on the first key's state data when the remote key authentication fails, it utilizes the complementary communication capabilities of heterogeneous digital keys to overcome the technical defect that a single authentication path failure would prevent the user from entering the vehicle. Therefore, this embodiment, while ensuring priority response from the remote key, significantly improves the fault tolerance and system reliability of the door opening and power-on control through the redundant authentication capabilities of multi-source heterogeneous keys, avoiding user vehicle interruption due to occasional factors such as key signal obstruction, insufficient power, or radio frequency interference, thereby improving the robustness of the vehicle entry system and the user experience.

[0074] In some embodiments, the first operation request and / or the second operation request further include a brake start request; Control instructions are generated based on the arbitration result, including: In response to the request to start by applying the brakes, the target key is determined based on the arbitration result; If the target key is a remote key corresponding to the second key status data, and the area type represented by the key location information in the second key status data is the in-vehicle area, then the second authentication process is executed based on the second key status data to obtain the second authentication result; wherein, the second authentication process includes key authentication and anti-theft authentication; If the second authentication result indicates that the key authentication status and the anti-theft authentication status are normal, then the authentication is deemed successful and a power-on control command is generated; otherwise, the second authentication process is executed based on the first key status data corresponding to the target key, and a power-on control command is generated after the authentication is successful.

[0075] Specifically, the brake-activated start request is triggered when the user presses the brake pedal. At this time, the vehicle needs to switch from a low-voltage standby state to a high-voltage ready state to drive the power system, which has a higher safety level than the door-opening power-on scenario. In response to this request, the key management system first determines a unique target key from multiple concurrent requests based on the aforementioned centralized arbitration result. This ensures that there is a clear and single control object at the critical operation node of brake activation, preventing ambiguous execution or conflicting issuance of start commands in multi-key concurrent scenarios.

[0076] Based on this, the system further determines whether the target key corresponds to the second key status data (i.e., the remote key), and whether its key location information indicates that it is currently inside the vehicle. If the above conditions are met, the second authentication process is executed based on the second key status data. Unlike the first authentication process in the door opening and power-on scenario, this second authentication process includes not only key authentication to verify the legality of the key's identity (such as rolling code verification and encryption key matching), but also anti-theft authentication to verify the legality of the vehicle's anti-theft system (such as engine immobilizer IMMO authentication and anti-theft coil matching verification). This dual authentication mechanism ensures that the current operator possesses a legitimate key and that the vehicle has not been illegally accessed. At the same time, it utilizes the high real-time characteristics of direct RF channel connection to meet the stringent requirements for response speed when starting by pressing the brake.

[0077] If the remote key is determined not to be inside the vehicle, or if no valid remote key location signal is received within a preset time threshold (e.g., 5 seconds), the system initiates a location query to other heterogeneous digital keys through a standardized service interface and waits for a response within that time threshold. If a valid in-vehicle location signal from any key is received within 5 seconds, a second authentication process, including key authentication and anti-theft authentication, is executed based on the corresponding key status data. If no valid key is detected inside the vehicle after the timeout, it is determined that no valid key is inside the vehicle, the system generates a reminder message to remind the user that no valid key is inside the vehicle, and terminates the start-up process.

[0078] Accordingly, the system performs branch processing based on the second authentication result. If the second authentication result indicates that both the key authentication status and the anti-theft authentication status are normal (i.e., both authentications are passed), the authentication is deemed successful and a power-on control command (such as a high-voltage system enable command or a starter activation command) is generated and sent to the power system. If either authentication result indicates an anomaly (such as anti-theft authentication failure, rolling code mismatch, or RF communication interruption), a redundant authentication mechanism is activated. The system then re-executes the second authentication process, which includes both key authentication and anti-theft authentication, based on the first key status data corresponding to the target key (i.e., Bluetooth, NFC, UWB, or remote key data adapted to the protocol). After successful authentication, a power-on control command is generated, thereby ensuring that legitimate startup can still be completed through the heterogeneous digital key even in the event of occasional failure of remote key communication.

[0079] Therefore, this application embodiment constructs a control mechanism of "arbitration uniqueness determination - remote key priority dual authentication - heterogeneous key redundancy fallback" for the high-security scenario of brake-activated start. This embodiment first determines a unique target key through centralized arbitration results, avoiding control object confusion in multi-key concurrent scenarios. Then, it prioritizes the execution of a second authentication process including anti-theft authentication for the remote key, utilizing the low latency of direct radio frequency connection to meet the real-time start requirement, and significantly improving the vehicle's start security level through dual authentication of the key and anti-theft. Simultaneously, by automatically falling back to a redundant authentication process based on the first key's state data when dual authentication fails, it utilizes complementary communication paths of heterogeneous keys such as Bluetooth and UWB to suppress the risk of start failure caused by a single authentication path failure. Therefore, this embodiment, while ensuring start real-time performance and security, significantly improves the fault tolerance and system reliability of brake-activated start control through the redundant authentication capability of multi-source heterogeneous keys, preventing user start interruptions due to radio frequency signal obstruction, key battery depletion, or occasional anti-theft system malfunctions, thereby improving the robustness of the vehicle's powertrain control and the user experience.

[0080] In some embodiments, the first operation request and / or the second operation request further include a lockout power-down request; Control instructions are generated based on the arbitration result, including: In response to the lockout power-off request, the target key is determined based on the arbitration result; Determine the region type represented by the key location information in the first or second state data corresponding to the target key; If the area type is in-vehicle area, an in-vehicle locking command is generated to control the door control system to lock and the power system to keep powered on. If the area type is an external area, an external locking command is generated to control the door control system to lock and the power system to power down.

[0081] Specifically, when a user triggers a locking operation (such as pressing the key's locking button or touching the door handle's sensor area), the first and / or second operation requests include a locking power-off request. In response to this request, the key management system first determines the target key (i.e., the winning key with the highest execution priority) based on the aforementioned centralized arbitration result. This ensures that, in multi-key concurrent scenarios, the system clearly identifies the unique control object for the current locking operation, avoiding locking logic confusion caused by multiple source commands.

[0082] Subsequently, the system analyzes the first key status data or the second key status data corresponding to the target key, extracts the key location information, and determines the current area type of the key (inside or outside the vehicle). This location determination result is the key decision basis for generating differentiated control commands, ensuring that the control strategy matches the user's actual situation.

[0083] If the target key is determined to be located in an area inside the vehicle (e.g., the key is left on the seat or the user is inside the vehicle attempting to lock it), it indicates that the user may still be inside the vehicle or the key has been forgotten in the cabin. In this case, the system generates an in-vehicle locking command and sends it to the door control system to lock the doors. Simultaneously, it generates a power-keeping command (do not power off) and sends it to the power system, maintaining the vehicle's current power-on state (e.g., ACC or ON). This strategy prevents accidental power-off due to the key being inside the vehicle, which could lock the user inside and prevent them from starting the vehicle, or avoids safety hazards caused by power outages (e.g., windows cannot be raised or lowered, air conditioning stops), ensuring both in-vehicle safety and power continuity.

[0084] Accordingly, if the target key is located in an external area (e.g., the user leaves the vehicle with the key and triggers the lock), it indicates that the user is leaving the vehicle. At this time, the system generates an external locking command and sends it to the door control system to lock the doors. Simultaneously, it generates a power-down command and sends it to the power system, controlling the vehicle to switch from its current power-on state (e.g., ON or ACC) to a power-down state (e.g., OFF or sleep mode). This strategy achieves automatic safety locking and energy management when the user leaves the vehicle, avoiding battery drain caused by prolonged standby, while ensuring the vehicle enters a secure armed state and reducing energy waste.

[0085] Therefore, this embodiment constructs a control mechanism of "arbitration to determine the target - location determination - differentiated instruction generation" for the locking and power-off scenario. This embodiment first determines a unique target key through centralized arbitration, clarifying the problem of control object confusion in multi-key concurrent scenarios; then, based on the target key's location information, it accurately distinguishes between in-vehicle and external locking scenarios, and generates differentiated collaborative control instructions accordingly (in-vehicle locking with power on, or external locking with power off), achieving refined situational awareness and intelligent decision-making for the locking scenario. Therefore, this embodiment overcomes the safety hazards (such as the user being trapped due to accidental power-off caused by a key left inside the vehicle) or energy management defects (such as long-term standby power consumption after external locking) that may arise from the lack of location awareness and uniform power-off execution in traditional solutions. While ensuring safe locking and energy-saving management when the user leaves the vehicle, it effectively suppresses the risk of power interruption and user entrapment caused by a key left inside the vehicle, thereby significantly improving the system's situational adaptability, control security, and energy management efficiency.

[0086] In some embodiments, the method further includes vehicle departure locking control. After the user closes the last door, the key management system continuously monitors the key position information in the first key status data or second key status data. If the position of any key is detected to have migrated from the welcome area or PE area to an invalid area (i.e., beyond the vehicle's sensing range), it is determined that the user is moving away from the vehicle. At this time, the centralized arbitration module generates a vehicle departure locking arbitration result, and the instruction generation module generates a locking instruction based on the result and sends it to the door control system to trigger automatic locking. Since this embodiment automatically determines the user's intention to leave the vehicle through dynamic migration detection of the key position status (from the near-vehicle area to the invalid area), the user does not need to manually trigger the locking operation, thereby achieving seamless automatic security protection. This overcomes the security risks of users forgetting to lock the car in traditional solutions, resulting in the vehicle being in an unsecured state for a long time, and improves the convenience of car use and theft prevention security of the vehicle.

[0087] In some embodiments, the method further includes welcome unlock control; the key management system continuously monitors the key position through a radio frequency antenna or a standardized service interface in a dormant state. When the position of any valid key is detected to have migrated from an invalid area to a welcome area or a PE area, the key management system is awakened and an unlock command is generated and sent to the door control system to trigger welcome unlock. Since this embodiment can identify the user's approach intention through low-power position monitoring only in a dormant state, and automatically wakes the system to perform unlock when the user enters the welcome or PE area, it achieves a seamless entry function while ensuring low-power system operation. This overcomes the inconvenience of traditional solutions requiring the user to actively press the key or touch the door handle, significantly improving the ease of operation and smoothness of the user's experience before entering the vehicle.

[0088] In some embodiments, after the door control system performs a locking or unlocking operation, the key management system records the locking / unlocking type (interior locking / exterior locking / welcome unlocking / departure locking), the target key identifier, and the key location information to a memory for subsequent vehicle usage behavior analysis and system diagnostics. Because this embodiment establishes a complete vehicle entry operation log by synchronously recording multi-dimensional information such as operation type, key identity, and location after arbitration execution, it provides data support for subsequent user vehicle usage behavior analysis (such as frequently used entry locations and statistics of frequently used key types) and system fault diagnosis (such as tracing abnormal unlocking records and analyzing arbitration logic failures). This overcomes the difficulties in fault location and insufficient basis for user experience optimization caused by the lack of operation tracing capabilities in traditional solutions, and improves the system's maintainability and data value mining capabilities.

[0089] Based on the same technical concept, this application also provides a door control device, see reference. Figure 2 , Figure 2This is a schematic diagram of the structure of the door control device provided in an embodiment of this application. Figure 2 As shown, the door control device includes at least a request receiving module 201, an adapter determining module 202, a data acquisition module 203, a centralized arbitration module 204, and an instruction generation module 205, wherein: The request receiving module 201 is used to receive at least two first operation requests through a standardized service interface; wherein each first operation request includes a key type identifier; The adapter determination module 202 is used to determine the corresponding target adapter for each key type identifier based on the adapter identifier corresponding to the key type identifier; The data acquisition module 203 is used to send each first operation request to the corresponding target adapter and acquire the first key status data fed back by the target adapter; The centralized arbitration module 204 is used to centrally arbitrate at least two first operation requests based on the status data of each first key, and obtain an arbitration result. The instruction generation module 205 is used to generate control instructions based on the arbitration result and send the control instructions to the door control system and the power system to execute the control instructions.

[0090] It should be noted that this door control device can be used to implement any of the above-described method embodiments.

[0091] Based on the same technical concept, this application also provides an electronic device, see reference. Figure 3 , Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 3 As shown, the electronic device includes a memory 301 and a processor 302. The memory 301 is used to store computer instructions; when the processor 302 executes the computer instructions, it implements any of the above-described method embodiments.

[0092] The specific entity of the electronic device can be a smartphone, wearable device, tablet computer, personal computer, in-vehicle terminal, game console, virtual device, workbench, digital assistant, set-top box, robot, or other terminal device. In other embodiments, it can be a rack server, blade server, tower server, or cabinet server (including a standalone server or a server cluster composed of multiple servers).

[0093] The memory 301 includes at least one type of computer-readable storage medium, including flash memory, hard disk, multimedia card, random access memory (RAM), static random access memory (SRAM), read-only memory (ROM), magnetic disk, optical disk, etc. In some embodiments, the computer-readable storage medium may be an internal storage unit of an electronic device, such as the hard disk or memory of the electronic device. In other embodiments, the computer-readable storage medium may also be an external storage device of the electronic device, such as a plug-in hard disk, secure digital card (SD card), flash memory card, etc., equipped on the electronic device. Of course, the computer-readable storage medium may include both internal storage units and external storage devices of the electronic device. In this embodiment, the computer-readable storage medium is typically used to store the operating system and various application software installed on the electronic device, such as the program code of the door control method in the embodiment. In addition, the computer-readable storage medium may also be used to temporarily store various types of data that have been output or will be output.

[0094] In some embodiments, processor 302 may be a central processing unit (CPU), a controller, a microcontroller, a microprocessor, or other chip. Processor 302 is typically used to control the overall operation of the processing device, such as performing control and processing related to data interaction or communication with other entities. In this embodiment, processor 302 is used to run program code stored in memory 301 or process data.

[0095] Based on the same technical concept, this application also provides a computer-readable storage medium, which includes a computer program or instructions stored in the storage medium. When the computer program or instructions are executed by a processing device, they implement any of the above-described method embodiments. Further details can be found in the method embodiments, which will not be repeated here. In this embodiment, the computer-readable storage medium includes flash memory, hard disk, multimedia card, random access memory (RAM), static random access memory (SRAM), read-only memory (ROM), magnetic disk, optical disk, etc. In some embodiments, the computer-readable storage medium can be an internal storage unit of an electronic device, such as the hard disk or memory of the electronic device. In other embodiments, the computer-readable storage medium can also be an external storage device of the electronic device, such as a plug-in hard disk, a secure digital card (SD card), a flash memory card, etc., equipped on the electronic device. Of course, the computer-readable storage medium can also include both internal storage units and external storage devices of the electronic device. In this embodiment, the computer-readable storage medium is typically used to store the operating system and various application software installed on the electronic device, such as the program code of the door control method in the embodiment. Furthermore, the computer-readable storage medium can also be used to temporarily store various types of data that have been output or will be output.

[0096] The above description does not provide detailed technical specifications regarding the structure of each layer. However, those skilled in the art should understand that layers and regions of desired shapes can be formed using various technical means. Furthermore, to form the same structure, those skilled in the art can also design methods that are not entirely identical to those described above. Additionally, although various embodiments have been described above, this does not mean that the measures in the various embodiments cannot be advantageously combined.

[0097] Although preferred embodiments of this application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of this application.

[0098] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A door control method, characterized in that, include: Receive at least two first operation requests through a standardized service interface; each first operation request includes a key type identifier. For each key type identifier, the corresponding target adapter is determined based on the adapter identifier corresponding to the key type identifier; Each of the first operation requests is sent to the corresponding target adapter, and the first key status data fed back by the target adapter is obtained; Based on the status data of each of the first keys, the at least two first operation requests are centrally arbitrated to obtain an arbitration result; Based on the arbitration result, control commands are generated and sent to the door control system and power system to execute the control commands.

2. The method according to claim 1, characterized in that, The first key status data includes key location information, key authentication status, and anti-theft authentication status; The step of centrally arbitrating the at least two first operation requests based on the status data of each of the first keys, and determining the arbitration result, includes: For each first operation request, the valid operation requests are obtained by filtering based on the corresponding first key status data and filtering conditions. Based on the key location information, the execution priority of each valid operation request is determined; The filtering conditions include any one of the following: The key authentication status is abnormal; The anti-theft authentication status is abnormal; The region type represented by the key location information is an invalid region.

3. The method according to claim 2, characterized in that, The first key status data also includes a key validity identifier; The step of determining the execution priority of each valid operation request based on the key location information includes: The initial priority of each valid operation request is determined based on the area type represented by the key location information; wherein, the area type includes the interior area, the welcome area, and the exterior area, the initial priority of the valid operation request corresponding to the interior area is higher than the initial priority of the valid operation request corresponding to the welcome area, and the initial priority of the valid operation request corresponding to the welcome area is higher than the initial priority of the valid operation request corresponding to the exterior area. The initial priority is adjusted according to the validity level represented by the key validity identifier to obtain the target priority of the corresponding valid operation request; wherein, the priority of a valid operation request with a higher validity level is higher than that of a valid operation request with a lower validity level.

4. The method according to claim 3, characterized in that, The method further includes: The second operation request is received via the radio frequency antenna, and the corresponding second key status data is obtained. The centralized arbitration of the at least two first operation requests based on the status data of each of the first keys, to obtain the arbitration result, includes: Based on the status data of each of the first key and the status data of the second key, the at least two first operation requests and the second operation request are centrally arbitrated to obtain an arbitration result.

5. The method according to claim 4, characterized in that, The first operation request and / or the second operation request includes a door opening and power-on request; The generation of control instructions based on the arbitration result includes: In response to the door opening and power-on request, the target key is determined based on the arbitration result; If the target key is a remote key corresponding to the second key status data, and the area type represented by the key location information in the second key status data is the in-vehicle area, then a first authentication process is executed based on the second key status data to obtain a first authentication result; wherein, the first authentication process includes key authentication; If the first authentication result indicates that the key authentication status is normal, then the authentication is deemed successful and a power-on control command is generated; otherwise, the first authentication process is executed based on the first key status data corresponding to the target key, and the power-on control command is generated after successful authentication.

6. The method according to claim 4, characterized in that, The first operation request and / or the second operation request also include a brake start request; The generation of control instructions based on the arbitration result includes: In response to the brake start request, the target key is determined based on the arbitration result; If the target key is a remote key corresponding to the second key status data, and the area type represented by the key location information in the second key status data is the in-vehicle area, then a second authentication process is executed based on the second key status data to obtain a second authentication result; wherein, the second authentication process includes key authentication and anti-theft authentication; If the second authentication result indicates that the key authentication status and the anti-theft authentication status are normal, then the authentication is deemed successful and a power-on control command is generated; otherwise, the second authentication process is executed based on the first key status data corresponding to the target key, and the power-on control command is generated after the authentication is successful.

7. The method according to claim 4, characterized in that, The first operation request and / or the second operation request may further include a lockout power-down request; The generation of control instructions based on the arbitration result includes: In response to the lockout power-off request, the target key is determined based on the arbitration result; Determine the region type represented by the key location information in the first or second state data corresponding to the target key; If the area type is the in-vehicle area, an in-vehicle locking command is generated to control the door control system to lock and the power system to keep powered on. If the area type is the external area, an external locking command is generated to control the door control system to lock and the power system to power off.

8. A vehicle door control device, characterized in that, include: The request receiving module is used to receive at least two first operation requests through a standardized service interface; wherein each first operation request includes a key type identifier; The adapter determination module is used to determine the corresponding target adapter for each key type identifier based on the adapter identifier corresponding to the key type identifier; The data acquisition module is used to send each of the first operation requests to the corresponding target adapter and acquire the first key status data fed back by the target adapter; A centralized arbitration module is used to centrally arbitrate the at least two first operation requests based on the status data of each of the first keys, and obtain an arbitration result; The instruction generation module is used to generate control instructions based on the arbitration result, and send the control instructions to the door control system and the power system to execute the control instructions.

9. An electronic device, characterized in that, It includes a memory and a processor, the memory being used to store computer programs or instructions; when the computer programs or instructions are executed by the processor, the method of any one of claims 1-7 is implemented.

10. A computer-readable storage medium, characterized in that, The storage medium stores a computer program or instructions, which, when executed by a processor, implement the method of any one of claims 1-7.

Images