Digital vehicle key state collaborative management system and method based on distributed synchronization engine

Abstract

The invention discloses a digital car key state collaborative management system and method based on a distributed synchronization engine, and relates to the technical field of car networking and digital security. The method aims to solve the technical problems that a traditional digital car key system is high in state synchronization delay, off-line conflicts are difficult to resolve, and safety verification is redundant. According to the system, through difference bitmap coding, a distributed version coordination algorithm and a layered security verification architecture, real-time coordination and security management of key states among multiple terminals and multiple vehicle nodes are realized. Specifically, the key state is mapped into a 256-dimensional Boolean vector space, and the data transmission quantity is reduced by adopting an increment synchronization mode; through vector clock comparison and an operation merging strategy, conflict automatic resolution in an off-line scene is realized. By means of layered signature verification and a hardware security module, the encryption operation overhead is reduced while the security is guaranteed.

Description

Technical Field

[0001] This invention relates to the field of intelligent connected vehicle technology, and in particular to a digital car key state collaborative management system and method based on a distributed synchronization engine. Background Technology

[0002] With the increasing popularity of intelligent connected vehicles, digital car keys are gradually replacing traditional physical keys, becoming the primary way for users to unlock and start their vehicles. Existing digital car key systems typically use a timed polling mechanism for state synchronization, but this has the following technical drawbacks:

[0003] 1. High state synchronization latency: Traditional timed polling cycles are mostly 30 seconds, resulting in a 2-5 second delay window for critical operations such as emergency reversal and freezing, which cannot meet security requirements;

[0004] 2. Weak offline conflict handling capability: When the vehicle or mobile device is offline, concurrent operations on multiple devices are difficult to guarantee eventual consistency and are prone to state confusion.

[0005] 3. Redundant security verification: Each synchronization requires a complete certificate chain verification, which increases network bandwidth usage by more than 42% and also increases the computational burden on the device.

[0006] 4. Insufficient scalability: It is difficult to support the concurrent management of millions of devices and lacks an operation traceability mechanism, which does not comply with data compliance requirements such as GDPR.

[0007] Therefore, there is an urgent need for a digital car key status collaborative management system based on a distributed synchronization engine to solve the existing technical problems. Summary of the Invention

[0008] The present invention aims to solve at least one of the technical problems existing in the prior art, and proposes a digital car key state collaborative management system and method based on a distributed synchronization engine.

[0009] In a first aspect, embodiments of the present invention provide a digital vehicle key status collaborative management system based on a distributed synchronization engine, comprising: a vehicle-side control module, an in-vehicle security module, a vehicle server cluster module, a device synchronization gateway module, a mobile device, and a vehicle execution module; wherein:

[0010] The vehicle-side control module is used to collect key status data via the CAN bus, send status change notifications to the vehicle safety module, receive synchronization confirmation instructions from the vehicle server cluster module, and control the actions of the vehicle execution unit.

[0011] The vehicle-mounted safety module is used for local version number generation, operation log encryption and signing, and key secure storage. It is also used for encrypted communication with the vehicle server cluster.

[0012] The vehicle server cluster module is used to generate incremental synchronization packets, push synchronization instructions, resolve multi-node conflicts and aggregate states by deploying a distributed version coordination algorithm. It is also used to communicate with the device synchronization gateway module through gRPC bidirectional stream.

[0013] The device synchronization gateway module is used to manage the access and forward data of mobile devices via a combination of MQTT and QUIC protocols.

[0014] The mobile device supports key operation initiation status confirmation function, has a built-in local clock synchronization module, and communicates with the vehicle actuator via Bluetooth protocol to achieve short-range control;

[0015] The vehicle execution module is used to receive control commands and execute specific operations, and to feed back the operation results to the vehicle-side control unit.

[0016] Furthermore, an incremental synchronization method based on differential bitmap encoding is used to process the key state data. The specific methods include:

[0017] Map the key status data to a state vector: decompose all the state parameters of the digital car key into a 256-dimensional Boolean vector space, with each vector bit corresponding to a unique key operation type;

[0018] Incremental packet generation: When a key state change is detected, only the changed bits in the Boolean vector space are identified, and the changed bit data is compressed using a run-length encoding compression algorithm to generate an incremental synchronization packet.

[0019] Dynamic version window setting: Set the version number within the version deviation compensation range. The vehicle server module carries this parameter when pushing synchronization instructions to the mobile device. When the local version number of the mobile device is within the version window range, it can directly receive synchronization data and update its status.

[0020] Clock skew compensation: After receiving the synchronization command, the mobile device returns an acknowledgment signal containing the local clock skew. The vehicle server cluster module uses the NTP-Precision protocol to adjust the synchronization timing according to the feedback clock skew, and controls the clock difference between devices within a preset range.

[0021] Furthermore, each vector bit corresponds to a unique key operation type, which includes at least preset operations such as key revocation, key freezing, and key authorization.

[0022] Furthermore, a digital car key status collaborative management system based on a distributed synchronization engine also includes: a blockchain notary node module, which is used to connect to the car server cluster module via a dedicated line, receive synchronization operation data, and generate an immutable audit evidence chain.

[0023] Furthermore, the interaction process between the vehicle server cluster module and the blockchain notary node includes:

[0024] After completing state synchronization, the vehicle server cluster module performs a hash operation on the synchronization log to generate a Merkle root.

[0025] Send the Merkle root and its corresponding timestamp and cluster signature to the blockchain notary node module;

[0026] The blockchain notary node module writes the received data into a block, generates a unique block height and transaction ID, and feeds it back to the vehicle server cluster module;

[0027] The vehicle server cluster module stores block information, which serves as the basis for subsequent auditing and dispute resolution.

[0028] Furthermore, the vehicle server cluster module deploys a distributed version coordination algorithm to achieve incremental synchronization packet generation, synchronization command push, multi-node conflict resolution, and state aggregation; the specific methods of the distributed version coordination algorithm include:

[0029] The vehicle server integration module collects 64-dimensional vector clocks of local status and the status of each remote device. Each dimension of the vector clock corresponds to a shard ID of a distributed node, which is used to identify the operation version of each node.

[0030] Calculate the maximum value of each dimension of all vector clocks to generate a dominant vector that identifies the current global latest state version, ensuring that all operations are merged based on the latest state;

[0031] Filter all device operation records whose vector clocks do not exceed the range of the dominant vector, determine the merging priority according to the device weight coefficient, and avoid low-priority operations from overwriting high-priority operations.

[0032] Based on the shard ID of the distributed nodes, a new version vector is generated by adding 1 to the corresponding dimension of the dominant vector, ensuring that the version number of each concurrent operation is unique.

[0033] Furthermore, the mechanism implemented by the vehicle-mounted safety module includes:

[0034] Layered signature verification process mechanism: The first layer adopts lightweight signature verification, and the second layer triggers full certificate chain verification during high-risk operations to reduce the amount of encryption computation;

[0035] Quantum random number generator mechanism: Integrates hardware-level quantum random number chip to provide high-entropy randomness for signature key generation and Nonce value allocation, resisting the risk of quantum computing cracking;

[0036] Physically unclonable function binding mechanism: Binds device hardware characteristics to key information, and can only pass the signature verification when the device hardware matches, preventing the key from being stolen and used on other devices.

[0037] Secondly, this invention also discloses a digital car key state collaborative management method based on a distributed synchronization engine, comprising:

[0038] The vehicle control module detects a change in the digital car key's status and sends a status change event to the vehicle security module via the mobile device CAN bus. The event includes the operation type and the current version number.

[0039] After signing the state change event, the onboard safety module sends it to the vehicle server cluster module via the TLS (True Mobile Device 1.3) mobile device protocol. The vehicle server cluster module identifies the changed bits based on differential bitmap encoding and generates incremental synchronization packets using run-length encoding.

[0040] The vehicle server cluster module pushes synchronization commands to the device synchronization gateway via bidirectional flow of gRPC from the mobile device. The commands include incremental packets, version windows, and timeout threshold parameters.

[0041] The device synchronization gateway module forwards synchronization commands to relevant mobile devices via the mobile device MQTT+QUIC mobile device protocol. After receiving the command, the mobile device performs lightweight signature verification. If successful, it returns an acknowledgment signal containing the local clock deviation.

[0042] The device synchronization gateway module aggregates the confirmation signals from all mobile devices and sends them back to the vehicle server cluster module. If not all confirmations are received within a preset time, the vehicle server cluster module triggers a retransmission mechanism. If no confirmation is received after a preset number of times, an anomaly is recorded and an alarm is triggered.

[0043] After receiving all confirmation signals, the vehicle server cluster module submits a final confirmation command to the vehicle control unit, performs a hash operation on the synchronization log to generate a Merkle root, and sends the Merkle root, timestamp, and cluster signature to the blockchain notary node module to write it into the block, thus completing the operation traceability.

[0044] Thirdly, the present invention also discloses an electronic device, comprising:

[0045] One or more processors;

[0046] Memory, used to store one or more programs;

[0047] When the one or more programs are executed by the one or more processors, the one or more processors implement the collaborative management method.

[0048] Fourthly, the present invention also discloses a computer-readable medium storing a computer program, characterized in that the computer program, when executed by a processor, implements the steps in the collaborative management method.

[0049] This invention discloses a digital car key status collaborative management system based on a distributed synchronization engine, relating to the fields of vehicle networking and digital security technology. It aims to solve the technical problems of high status synchronization latency, difficulty in resolving offline conflicts, and redundant security verification in traditional digital car key systems. This system achieves real-time collaborative and secure management of key states among multiple terminals and vehicle nodes through differential bitmap encoding, a distributed version coordination algorithm, and a layered security verification architecture. Specifically, the key state is mapped to a 256-dimensional Boolean vector space, and incremental synchronization is used to reduce data transmission volume; automatic conflict resolution in offline scenarios is achieved through vector clock comparison and operation merging strategies; and layered signature verification and hardware security modules are used to reduce encryption computation overhead while ensuring security.

[0050] The digital car key status collaborative management system based on a distributed synchronization engine of the present invention has the following advantages compared with the prior art:

[0051] 1. Significantly improved real-time performance: By adopting differential bitmap encoding and incremental synchronization mechanism, the synchronization latency of critical operations is reduced to 82ms (350ms in the traditional solution), an improvement of 76.5%, meeting the ASIL-D safety level requirements;

[0052] 2. Enhanced conflict resolution capabilities: The distributed version coordination algorithm enables automatic conflict resolution in offline scenarios, achieving a conflict resolution success rate of 99.7% (compared to 83.2% for traditional solutions), representing an improvement of 16.5%, and ensuring eventual consistency in concurrent operations across multiple devices;

[0053] 3. Significantly reduced resource consumption: The combination of incremental synchronization and hierarchical signature verification reduces network bandwidth consumption to 4.2Kbps (compared to 18Kbps in the traditional solution), a reduction of 76.7%, while also reducing encryption computation by 80%, thus alleviating the burden on equipment;

[0054] 4. Excellent scalability and compliance: Supports concurrent management of millions of devices in a single cluster, and the blockchain notarization mechanism enables traceable operations, complying with Article 32 of the GDPR "Secure processing" requirements, and is suitable for large-scale application scenarios;

[0055] 5. Comprehensive security protection: It integrates HSM hardware security module, quantum random number generation, PUF binding and anti-replay attack mechanism to form a multi-layer security protection system to resist security risks such as key theft, data tampering and replay attacks. Attached Figure Description

[0056] Figure 1A first structural block diagram of a digital car key status collaborative management system based on a distributed synchronization engine provided in an embodiment of the present invention;

[0057] Figure 2 A second structural block diagram of a digital car key status collaborative management system based on a distributed synchronization engine provided in an embodiment of the present invention;

[0058] Figure 3 A flowchart illustrating a digital car key state collaborative management method based on a distributed synchronization engine, provided for an embodiment of the present invention;

[0059] Figure 4 This is a structural block diagram of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0060] To enable those skilled in the art to better understand the technical solutions of the present invention, exemplary embodiments of the present invention are described below in conjunction with the accompanying drawings, including various details of the embodiments of the present invention to aid understanding. These should be considered merely exemplary. Therefore, those skilled in the art should recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of the present invention. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0061] Where there is no conflict, the various embodiments of the present invention and the features thereof may be combined with each other.

[0062] As used herein, the term “and / or” includes any and all combinations of one or more related enumerated entries.

[0063] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the invention. As used herein, the singular forms “a” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that when the terms “comprising” and / or “made of” are used in this specification, the presence of the stated feature, integral, step, operation, element, and / or component is specified, but the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or groups thereof is not excluded. Terms such as “connected” or “linked” are not limited to physical or mechanical connections but can include electrical connections, whether direct or indirect.

[0064] Unless otherwise specified, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art. It will also be understood that terms such as those defined in commonly used dictionaries should be interpreted as having the meaning consistent with their meaning in the context of the relevant art and the invention, and will not be interpreted as having an idealized or overly formal meaning unless expressly so defined herein.

[0065] In the technical solution of this invention, the collection, storage, use, processing, transmission, provision, and disclosure of user personal information all comply with relevant laws and regulations and do not violate public order and good morals. The use of user data in this technical solution follows relevant national laws and regulations (e.g., the "Information Security Technology - Personal Information Security Specification"). For example: appropriate measures are taken for personal information access control; restrictions are imposed on the display of personal information; the purpose of using personal information does not exceed the scope of direct or reasonable association; and explicit identity targeting is eliminated when using personal information to avoid precisely locating a specific individual.

[0066] To address at least one of the technical problems existing in the aforementioned related technologies, the present invention provides a digital car key status collaborative management system and method based on a distributed synchronization engine.

[0067] This implementation discloses a digital car key status collaborative management system based on a distributed synchronization engine, such as... Figure 1 It includes: a vehicle-side control module, an in-vehicle safety module, a vehicle server cluster module, a device synchronization gateway module, a mobile device, and a vehicle execution module; among which:

[0068] The vehicle-side control module is used to collect key status data (such as current authorization status and operation records) via the CAN bus, send status change notifications to the vehicle-mounted safety module, receive synchronization confirmation instructions from the vehicle server cluster module, and control the actions of the vehicle execution unit.

[0069] Specifically, in this embodiment, an incremental synchronization method based on differential bitmap encoding is used to process the key state data. The specific method includes:

[0070] The key status data is mapped using a state vector: all status parameters of the digital car key are decomposed into a 256-dimensional Boolean vector space, with each vector bit corresponding to a unique key operation type. For example, all status parameters of the digital car key (such as revocation, freeze, authorization, deauthorization, etc.) are decomposed into a 256-dimensional Boolean vector space, with each vector bit corresponding to a unique operation type. For example, the revocation operation is mapped to 0x00000001, the freeze operation is mapped to 0x00000002, the authorization operation is mapped to 0x00000004, and so on, ensuring that each operation status is independently identified.

[0071] Incremental packet generation: When a key state change is detected, only the changed bits in the Boolean vector space are identified. A run-length encoding compression algorithm is used to compress the changed bit data, generating an incremental synchronization packet. Compared to traditional methods that transmit complete state data, the incremental packet size is only 23% of the traditional method, significantly reducing network bandwidth usage.

[0072] Dynamic version window settings: Set the version number within the version deviation compensation range. The vehicle server module carries this parameter when pushing synchronization instructions to the mobile device. When the local version number of the mobile device is within the version window range, it can directly receive synchronization data and update its status. The dynamic version window eliminates the need for additional version negotiation and adapts to high-latency network environments.

[0073] Clock skew compensation: After receiving the synchronization command, the mobile device returns an acknowledgment signal containing the local clock skew. The vehicle server cluster module uses the NTP-Precision protocol to adjust the synchronization timing according to the feedback clock skew, keeping the clock difference between devices within a preset range and avoiding synchronization failure due to clock inconsistency.

[0074] By adopting differential bitmap encoding and incremental synchronization mechanism, the synchronization latency of critical operations is reduced to 82ms (350ms in the traditional solution), an improvement of 76.5%, meeting the ASIL-D safety level requirements.

[0075] The vehicle-mounted safety module is used for local version number generation, operation log encryption and signing, and key secure storage. It is also used for encrypted communication with the vehicle server cluster.

[0076] In this embodiment, the mechanism implemented by the vehicle-mounted safety module includes:

[0077] Layered signature verification process mechanism: The first layer adopts lightweight signature verification, and the second layer triggers full certificate chain verification during high-risk operations to reduce the amount of encryption computation;

[0078] Quantum random number generator mechanism: Integrates hardware-level quantum random number chip to provide high-entropy randomness for signature key generation and Nonce value allocation, resisting the risk of quantum computing cracking;

[0079] Physically unclonable function binding mechanism: Binds device hardware characteristics to key information, and can only pass the signature verification when the device hardware matches, preventing the key from being stolen and used on other devices.

[0080] This implementation of the vehicle-mounted security module employs quantum random number generation, PUF binding, and anti-replay attack mechanisms to form a multi-layered security protection system, resisting security risks such as key theft, data tampering, and replay attacks.

[0081] The vehicle server cluster module is used to generate incremental synchronization packets, push synchronization instructions, resolve multi-node conflicts and aggregate states by deploying a distributed version coordination algorithm. It is also used to communicate with the device synchronization gateway module through gRPC bidirectional stream.

[0082] Specifically, the distributed version coordination algorithm includes the following methods:

[0083] The vehicle server integration module collects 64-dimensional vector clocks of local status and the status of each remote device. Each dimension of the vector clock corresponds to a shard ID of a distributed node, which is used to identify the operation version of each node.

[0084] Calculate the maximum value of each dimension of all vector clocks to generate a dominant vector that identifies the current global latest state version, ensuring that all operations are merged based on the latest state;

[0085] Filter all device operation records whose vector clocks do not exceed the range of the dominant vector, determine the merging priority according to the device weight coefficient, and avoid low-priority operations from overwriting high-priority operations.

[0086] Based on the shard ID of the distributed nodes, a new version vector is generated by adding 1 to the corresponding dimension of the dominant vector, ensuring that the version number of each concurrent operation is unique.

[0087] By adopting the distributed version coordination algorithm in this embodiment, automatic conflict resolution in offline scenarios is achieved, with a conflict resolution success rate of 99.7% (compared to 83.2% for traditional solutions), representing an improvement of 16.5%, ensuring the eventual consistency of concurrent operations across multiple devices;

[0088] The device synchronization gateway module, using a combination of MQTT and QUIC protocols, is responsible for managing mobile device access and forwarding data. Specifically, it forwards synchronization commands to relevant mobile devices via MQTT and QUIC. Upon receiving the command, the mobile device performs lightweight verification; if successful, it returns an acknowledgment signal including the local clock offset. The device synchronization gateway module aggregates the acknowledgment signals from all mobile devices and sends them to the vehicle server cluster module. If all acknowledgments are not received within 1.5 seconds, the vehicle server cluster module triggers a retransmission mechanism; if no acknowledgment is received after three timeouts, an anomaly is recorded and an alarm is triggered.

[0089] The mobile device supports key operation initiation status confirmation function, has a built-in local clock synchronization module, and communicates with the vehicle execution unit via Bluetooth protocol to achieve short-range control. Specifically, in this embodiment, the mobile device includes terminals such as the owner's mobile phone and smartwatch, supports key operation initiation (such as unlocking and authorization) and status confirmation functions, has a built-in local clock synchronization module, and communicates with the vehicle execution unit via BLE5.2 protocol to achieve short-range control.

[0090] The vehicle execution module receives control commands, executes specific operations, and sends the results back to the vehicle control unit. Specifically, it receives control commands and executes actions such as unlocking doors, starting the engine, and opening the trunk, then sends the results back to the vehicle control unit.

[0091] In some preferred embodiments, such as Figure 2 A digital car key status collaborative management system based on a distributed synchronization engine also includes: a blockchain notary node module, which is used to connect to the car server cluster module via a dedicated line, receive synchronization operation data, and generate an immutable audit evidence chain.

[0092] Specifically, the interaction process between the vehicle server cluster module and the blockchain notary node includes:

[0093] After completing state synchronization, the vehicle server cluster module performs a hash operation on the synchronization log to generate a Merkle root.

[0094] Send the Merkle root and its corresponding timestamp and cluster signature to the blockchain notary node module;

[0095] The blockchain notary node module writes the received data into a block, generates a unique block height and transaction ID, and feeds it back to the vehicle server cluster module;

[0096] The vehicle server cluster module stores block information, which serves as the basis for subsequent auditing and dispute resolution.

[0097] This embodiment discloses a digital car key state collaborative management system based on a distributed synchronization engine, relating to the fields of vehicle networking and digital security technology. It aims to solve the technical problems of high state synchronization latency, difficulty in resolving offline conflicts, and redundant security verification in traditional digital car key systems. This system achieves real-time collaborative and secure management of key states among multiple terminals and vehicle nodes through differential bitmap encoding, a distributed version coordination algorithm, and a layered security verification architecture. Specifically, the key state is mapped to a 256-dimensional Boolean vector space, and incremental synchronization is used to reduce data transmission volume; automatic conflict resolution in offline scenarios is achieved through vector clock comparison and operation merging strategies; and layered signature verification and hardware security modules are used to reduce encryption computation overhead while ensuring security.

[0098] To better understand this embodiment, the following explanation uses a multi-device key freeze operation and an emergency batch undo scenario as examples. When performing a multi-device key freeze operation:

[0099] The car owner initiates a key freeze request via mobile phone. The mobile phone records the operation version number N and sends it to the device synchronization gateway module via MQTT+QUIC protocol.

[0100] At this time, the owner's smartwatch is offline. It detects that the local key status is inconsistent with the cache and generates a freeze operation record, version number N+1.

[0101] After the smartwatch regains its network connection, it automatically uploads offline operation records to the device's synchronization gateway module.

[0102] The vehicle server cluster module uses a distributed version coordination algorithm to merge the operation records of the mobile phone (version N) and the smartwatch (version N+1) to generate the final version N+2.

[0103] The vehicle server cluster module pushes the final status to all relevant devices to ensure that the status of the mobile phone, smartwatch, and vehicle key are consistent, and the freeze operation takes effect.

[0104] In emergency batch undo scenarios:

[0105] The security center detected a risk of key leakage and sent a batch revocation command to the vehicle server cluster module;

[0106] The vehicle server cluster module generates incremental synchronization packets and broadcasts cancellation commands to 5000+ associated devices through the device synchronization gateway module.

[0107] Utilizing the low-latency transmission characteristics of the QUIC protocol, all device commands are delivered and acknowledged within 1.2 seconds.

[0108] The vehicle server cluster module will generate Merkle root from the revocation operation log, write it to the blockchain notary node module, and generate an immutable audit evidence chain.

[0109] All devices complete the key status revocation to avoid security risks caused by key leakage.

[0110] Based on the same inventive concept, embodiments of the present invention also provide a method for collaborative management of the state of a digital car key based on a distributed synchronization engine, such as... Figure 3 ,include:

[0111] The vehicle control module detects a change in the digital car key's status and sends a status change event to the vehicle security module via the mobile device CAN bus. The event includes the operation type and the current version number.

[0112] After signing the state change event, the onboard safety module sends it to the vehicle server cluster module via the TLS (True Mobile Device 1.3) mobile device protocol. The vehicle server cluster module identifies the changed bits based on differential bitmap encoding and generates incremental synchronization packets using run-length encoding.

[0113] The vehicle server cluster module pushes synchronization commands to the device synchronization gateway via bidirectional flow of gRPC from the mobile device. The commands include incremental packets, version windows, and timeout threshold parameters.

[0114] The device synchronization gateway module forwards synchronization commands to relevant mobile devices via the mobile device MQTT+QUIC mobile device protocol. After receiving the command, the mobile device performs lightweight signature verification. If successful, it returns an acknowledgment signal containing the local clock deviation.

[0115] The device synchronization gateway module aggregates the confirmation signals from all mobile devices and sends them back to the vehicle server cluster module. If not all confirmations are received within a preset time, the vehicle server cluster module triggers a retransmission mechanism. If no confirmation is received after a preset number of times, an anomaly is recorded and an alarm is triggered.

[0116] After receiving all confirmation signals, the vehicle server cluster module submits a final confirmation command to the vehicle control unit, performs a hash operation on the synchronization log to generate a Merkle root, and sends the Merkle root, timestamp, and cluster signature to the blockchain notary node module to write it into the block, thus completing the operation traceability.

[0117] The specific working methods of the vehicle-side control module, vehicle-mounted security module, vehicle server cluster module, device synchronization gateway module, mobile device and vehicle execution module have been described in detail in the above-mentioned digital car key status collaborative management system based on distributed synchronization engine, and will not be repeated here in this embodiment.

[0118] Based on the same inventive concept, embodiments of the present invention also provide an electronic device. Figure 4 This is a structural block diagram of an electronic device provided in an embodiment of the present invention. Figure 4 As shown, an embodiment of the present invention provides an electronic device including: one or more processors 101, a memory 102, and one or more I / O interfaces 103. The memory 102 stores one or more programs, which, when executed by the one or more processors, cause the one or more processors to implement any of the collaborative management methods described in the above embodiments; the one or more I / O interfaces 103 are connected between the processors and the memory, configured to enable information interaction between the processors and the memory.

[0119] The processor 101 is a device with data processing capabilities, including but not limited to a central processing unit (CPU); the memory 102 is a device with data storage capabilities, including but not limited to random access memory (RAM, more specifically SDRAM, DDR, etc.), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), and flash memory (FLASH); the I / O interface (read / write interface) 103 is connected between the processor 101 and the memory 102, and can realize information interaction between the processor 101 and the memory 102, including but not limited to a data bus (Bus).

[0120] In some embodiments, the processor 101, memory 102, and I / O interface 103 are interconnected via bus 104, and thus connected to other components of the computing device.

[0121] In some embodiments, the one or more processors 101 include a field-programmable gate array.

[0122] This invention also provides a computer-readable medium. The computer-readable medium stores a computer program, which, when executed by a processor, implements the steps of any of the cooperative management methods described in the above embodiments. The computer-readable storage medium may be volatile or non-volatile.

[0123] This invention also provides a computer program product, including computer-readable code, or a non-volatile computer-readable storage medium carrying computer-readable code. When the computer-readable code is run in the processor of an electronic device, the processor in the electronic device executes the above-described collaborative management method.

[0124] Those skilled in the art will understand that all or some of the steps, systems, and apparatuses disclosed above, and their functional modules / units, can be implemented as software, firmware, hardware, or suitable combinations thereof. In hardware implementations, the division between functional modules / units mentioned above does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be performed collaboratively by several physical components. Some or all physical components may be implemented as software executed by a processor, such as a central processing unit, digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit (ASIC). Such software can be distributed on a computer-readable storage medium, which may include computer storage media (or non-transitory media) and communication media (or transient media).

[0125] As is known to those skilled in the art, the term computer storage medium includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information, such as computer-readable program instructions, data structures, program modules, or other data. Computer storage media includes, but is not limited to, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), static random access memory (SRAM), flash memory or other memory technologies, portable compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible to a computer. Furthermore, it is known to those skilled in the art that communication media typically contain computer-readable program instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.

[0126] The computer-readable program instructions described herein can be downloaded from computer-readable storage media to various computing / processing devices, or downloaded via a network, such as the Internet, local area network, wide area network, and / or wireless network, to an external computer or external storage device. The network may include copper transmission cables, fiber optic transmission, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to the computer-readable storage media in the respective computing / processing device.

[0127] The computer program instructions used to perform the operations of this invention may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, etc., and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The computer-readable program instructions may be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, electronic circuitry, such as programmable logic circuitry, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), is personalized by utilizing state information from the computer-readable program instructions. This electronic circuitry can execute the computer-readable program instructions to implement various aspects of the invention.

[0128] The computer program product described herein can be implemented specifically through hardware, software, or a combination thereof. In one alternative embodiment, the computer program product is specifically embodied in a computer storage medium; in another alternative embodiment, the computer program product is specifically embodied in a software product, such as a software development kit (SDK), etc.

[0129] Various aspects of the present invention are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0130] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that, when executed by the processor of the computer or other programmable data processing apparatus, they create means for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner; thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0131] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions executed on the computer, other programmable data processing apparatus, or other device to perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0132] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of an instruction, which contains one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than those shown in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0133] Example embodiments have been disclosed herein, and while specific terminology has been used, it is for illustrative purposes only and should be construed as such, and is not intended to be limiting. In some instances, it will be apparent to those skilled in the art that features, characteristics, and / or elements described in conjunction with particular embodiments may be used alone, or in combination with features, characteristics, and / or elements described in conjunction with other embodiments, unless otherwise expressly indicated. Therefore, those skilled in the art will understand that various changes in form and detail may be made without departing from the scope of the invention as set forth in the appended claims.

Claims

1. A digital car key status collaborative management system based on a distributed synchronization engine, characterized in that, include: The vehicle-side control module, vehicle-mounted safety module, vehicle server cluster module, device synchronization gateway module, mobile device, and vehicle execution module; among which: The vehicle-side control module is used to collect key status data via the CAN bus, send status change notifications to the vehicle safety module, receive synchronization confirmation instructions from the vehicle server cluster module, and control the actions of the vehicle execution unit. The vehicle-mounted safety module is used for local version number generation, operation log encryption and signing, and key secure storage. It is also used for encrypted communication with the vehicle server cluster. The vehicle server cluster module is used to generate incremental synchronization packets, push synchronization instructions, resolve multi-node conflicts and aggregate states by deploying a distributed version coordination algorithm. It is also used to communicate with the device synchronization gateway module through gRPC bidirectional stream. The device synchronization gateway module is used to manage the access and forward data of mobile devices via a combination of MQTT and QUIC protocols. The mobile device supports key operation initiation status confirmation function, has a built-in local clock synchronization module, and communicates with the vehicle actuator via Bluetooth protocol to achieve short-range control; The vehicle execution module is used to receive control commands and execute specific operations, and to feed back the operation results to the vehicle-side control unit.

2. The collaborative management system as described in claim 1, characterized in that, An incremental synchronization method based on differential bitmap encoding is used to process the key status data. Specific methods include: Map the key status data to a state vector: decompose all the state parameters of the digital car key into a 256-dimensional Boolean vector space, with each vector bit corresponding to a unique key operation type; Incremental packet generation: When a key state change is detected, only the changed bits in the Boolean vector space are identified, and the changed bit data is compressed using a run-length encoding compression algorithm to generate an incremental synchronization packet; Dynamic version window setting: Set the version number within the version deviation compensation range. The vehicle server module carries this parameter when pushing synchronization instructions to the mobile device. When the local version number of the mobile device is within the version window range, it can directly receive synchronization data and update its status. Clock skew compensation: After receiving the synchronization command, the mobile device returns an acknowledgment signal containing the local clock skew. The vehicle server cluster module uses the NTP-Precision protocol to adjust the synchronization timing according to the feedback clock skew, and controls the clock difference between devices within a preset range.

3. The collaborative management system as described in claim 1, characterized in that, Each vector bit corresponds to a unique key operation type, which includes at least preset operations such as key revocation, key freezing, and key authorization.

4. The collaborative management system as described in claim 1, characterized in that, Also includes: The blockchain notary node module is used to connect to the vehicle server cluster module via a dedicated line, receive synchronous operation data, and generate an immutable audit evidence chain.

5. The collaborative management system as described in claim 3, characterized in that, The interaction process between the vehicle server cluster module and the blockchain notary node module includes: After completing state synchronization, the vehicle server cluster module performs a hash operation on the synchronization log to generate a Merkle root. Send the Merkle root and its corresponding timestamp and cluster signature to the blockchain notary node module; The blockchain notary node module writes the received data into a block, generates a unique block height and transaction ID, and feeds it back to the vehicle server cluster module; The vehicle server cluster module stores block information, which serves as the basis for subsequent auditing and dispute resolution.

6. The collaborative management system as described in claim 1, characterized in that, The vehicle server cluster module utilizes a distributed version coordination algorithm to achieve incremental synchronization packet generation, synchronization command push, multi-node conflict resolution, and state aggregation. The specific methods of the distributed version coordination algorithm include: The vehicle server integration module collects 64-dimensional vector clocks of local status and the status of each remote device. Each dimension of the vector clock corresponds to a shard ID of a distributed node, which is used to identify the operation version of each node. Calculate the maximum value of each dimension of all vector clocks to generate a dominant vector that identifies the current global latest state version, ensuring that all operations are merged based on the latest state; Filter all device operation records whose vector clocks do not exceed the range of the dominant vector, determine the merging priority according to the device weight coefficient, and avoid low-priority operations from overwriting high-priority operations. Based on the shard ID of the distributed nodes, a new version vector is generated by adding 1 to the corresponding dimension of the dominant vector, ensuring that the version number of each concurrent operation is unique.

7. The collaborative management system as described in claim 1, characterized in that, The mechanisms implemented by the vehicle-mounted safety module include: Layered signature verification process mechanism: The first layer adopts lightweight signature verification, and the second layer triggers full certificate chain verification during high-risk operations to reduce the amount of encryption computation; Quantum random number generator mechanism: Integrates hardware-level quantum random number chip to provide high-entropy randomness for signature key generation and Nonce value allocation, resisting the risk of quantum computing cracking; Physically unclonable function binding mechanism: Binds device hardware characteristics to key information, and can only pass the signature verification when the device hardware matches, preventing the key from being stolen and used on other devices.

8. A method for collaborative management of digital car key status based on a distributed synchronization engine, characterized in that, include: The vehicle control module detects a change in the digital car key's status and sends a status change event to the vehicle security module via the mobile device CAN bus. The event includes the operation type and the current version number. After signing the state change event, the vehicle-mounted safety module sends it to the vehicle server cluster module via the Mobile Device TLS 1.3 mobile device protocol. The vehicle server cluster module identifies changed bits based on differential bitmap encoding and generates incremental synchronization packets using run-length encoding. The vehicle server cluster module pushes synchronization instructions to the device synchronization gateway via bidirectional flow from the mobile device gRPC. The instructions include incremental packets, version windows, and timeout threshold parameters. The device synchronization gateway module forwards synchronization commands to relevant mobile devices via the mobile device MQTT+QUIC mobile device protocol. After receiving the command, the mobile device performs lightweight signature verification. If successful, it returns an acknowledgment signal containing the local clock deviation. The device synchronization gateway module aggregates the confirmation signals from all mobile devices and sends them back to the vehicle server cluster module. If not all confirmations are received within a preset time, the vehicle server cluster module triggers a retransmission mechanism. If no confirmation is received after a preset number of times, an anomaly is recorded and an alarm is triggered. After receiving all confirmation signals, the vehicle server cluster module submits a final confirmation command to the vehicle control unit, performs a hash operation on the synchronization log to generate a Merkle root, and sends the Merkle root, timestamp, and cluster signature to the blockchain notary node module to write it into the block, thus completing the operation traceability.

9. An electronic device, characterized in that, include: One or more processors; Memory, used to store one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the collaborative management method as described in claim 8.

10. A computer-readable medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps in the collaborative management method as described in claim 8.

Images