A method and system for l3 level autonomous vehicle admission to a connectivity platform
By collecting, encrypting, and verifying the multidimensional data of L3 autonomous vehicles in real time, and combining the Kafka partitioning mechanism and rule engine, the technical problems of high-frequency data processing, multi-platform compatibility, and safety compliance of L3 autonomous vehicles are solved, and the real-time, secure, and scalable transmission and management of data are achieved.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- DONGFENG MOTOR GRP
- Filing Date
- 2026-02-06
- Publication Date
- 2026-06-09
AI Technical Summary
Existing technologies are insufficient to simultaneously meet the requirements of Level 3 autonomous vehicles in terms of high-frequency real-time performance, multi-platform compatibility, and safety compliance. They suffer from problems such as insufficient data processing capabilities, high coupling between multi-platform interfaces, poor scalability, and inadequate security.
By collecting and preprocessing multi-dimensional data from the vehicle in real time, authenticating and encrypting the data, decompressing and verifying the format and standardizing the data, using Kafka's partitioning mechanism to achieve data sharding, and using a rule engine to perform cross-platform data transformation, vehicle files are established based on VINs to achieve full lifecycle management and anomaly warning.
It achieves real-time processing capabilities for high-frequency data, seamless integration with multiple platforms, and secure and compliant data transmission. It supports data traceability and anomaly monitoring throughout the vehicle's entire lifecycle, enhancing the system's scalability and security.
Smart Images

Figure CN122179147A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of autonomous driving data transmission and processing technology, and in particular to a method and system for an L3-level autonomous vehicle access connection platform. Background Technology
[0002] With the commercialization of Level 3 autonomous driving technology, vehicles need to upload high-frequency dynamic data (such as location, speed, and system status) to regulatory platforms in real time, and support immediate reporting of emergencies such as collisions and malfunctions to meet safety and compliance requirements. Simultaneously, Level 3 vehicle data needs to be integrated with regulatory systems from multiple departments, including security, industry and information technology, and local authorities, involving cross-platform data rule conversion, high-concurrency processing, and full lifecycle traceability. However, existing technologies struggle to simultaneously meet the three core requirements of "high-frequency real-time performance, multi-platform compatibility, and safety compliance," exhibiting numerous shortcomings.
[0003] In existing technologies, solutions for uploading vehicle-side data to a cloud platform and connecting it with multiple regulatory platforms mainly have the following implementation methods and problems:
[0004] 1. Single Protocol Data Transmission Scheme: This scheme uses the MQTT protocol to achieve one-way data transmission between the vehicle and the cloud. Periodic data is reported at a fixed frequency (e.g., 1Hz), and event data is reported through a simple trigger mechanism. This scheme lacks sufficient high-frequency data processing capabilities to support concurrent transmission of high-frequency data at 5Hz and above, easily leading to data backlog or delays. It also lacks a layered buffering mechanism, allowing direct interaction between the vehicle and the cloud. Fluctuations in cloud services directly affect the stability of data transmission on the vehicle side. Furthermore, the data is not specifically compressed, resulting in excessive bandwidth consumption in weak in-vehicle network environments, making transmission interruptions likely.
[0005] 2. Multi-platform integration solution: This solution achieves data integration with regulatory platforms such as security and industrial information technology through customized interfaces, requiring the development of independent data conversion modules for different platforms. This solution suffers from high interface coupling; adding or changing regulatory platforms necessitates restructuring the data processing logic of the information department, resulting in poor scalability. Furthermore, the lack of a unified data rule conversion engine leads to inconsistencies when merging fields from multiple platforms (such as VIN and vehicle status codes), affecting data compliance. The absence of middleware for data distribution also contributes to a decrease in system throughput during concurrent requests from multiple platforms.
[0006] 3. Vehicle Management Solution: While basic data association is achieved based on vehicle ID, it lacks integration of metadata such as VIN, enterprise code, and vehicle model series, making it impossible to trace the entire lifecycle of vehicles from production and access to operation. Furthermore, the data security mechanism is inadequate, posing a risk of leakage during the transmission of sensitive information such as VIN.
[0007] Therefore, there is an urgent need for a method and system that can solve the above-mentioned technical problems and realize access connection platform for high-frequency data real-time processing, seamless multi-platform integration, secure and compliant data transmission, and full life cycle management of vehicles. 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 method and system for an L3 level autonomous vehicle access connection platform.
[0009] In a first aspect, embodiments of the present invention provide a method for accessing and connecting a Level 3 autonomous driving vehicle platform, comprising:
[0010] Real-time acquisition and preprocessing of multidimensional data from the vehicle, including periodic data and event data;
[0011] Receive preprocessed vehicle-side multidimensional data, and perform access authentication and encrypted transmission on the multidimensional data;
[0012] Decompress, validate, handle anomalies, and standardize fields of encrypted multidimensional data;
[0013] The standardized multidimensional data is sent to the corresponding topic in the Kafka environment. Data sharding is achieved through Kafka's partitioning mechanism, which supports multi-threaded concurrent consumption.
[0014] Subscribe to the corresponding Kafka topic, implement data transformation based on the rule engine, perform data format conversion, field supplementation or structure adaptation for different regulatory platforms, and ensure cross-platform data consistency by associating vehicle identifiers across multiple platforms through VIN;
[0015] Vehicle files are established based on VINs, linking vehicle data throughout its entire lifecycle. The system monitors vehicle data reporting status in real time and triggers anomaly alerts, while storing historical data to support full lifecycle data traceability.
[0016] Furthermore, the periodic data includes location, speed, and vehicle status data, and the event data includes collision and fault event data. The collected multidimensional data is encapsulated in JSON format and compressed using the GZIP algorithm.
[0017] Furthermore, the access authentication uses an independent domain name, account, and a fixed-format client ID. The client ID is fixed through a vehicle identification code, and the independent domain name and account are used for identity authentication.
[0018] Furthermore, the encrypted multidimensional data undergoes decompression, format verification, anomaly handling, and field standardization. Specific steps include: after receiving the encrypted multidimensional data, decompressing it and verifying its format validity; marking abnormal data and logging it.
[0019] Convert fields such as vehicle status code and event type to a unified encoding.
[0020] Furthermore, the standardized multidimensional data is sent to the corresponding topics in the Kafka environment, including SIT, PERF, UAT, and PRO environments. The data types include periodic data and event data, and data sharding is achieved through Kafka's partitioning mechanism.
[0021] Furthermore, data format conversion is performed for different regulatory platforms, specifically including: for security platforms: converting data formats according to preset frequencies and supplementing GNSS timestamps and vehicle driving mode fields; for information platforms: adapting data structures according to preset frequencies to ensure compliance with the data collection specifications for intelligent connected vehicles.
[0022] Furthermore, the historical data includes cold data and hot data. The cold data storage period is a first time period, and the hot data storage period is a second time period, with the first time period being longer than the second time period. The hot data consists of core vehicle operation data that is accessed frequently and responded to in real time, while the cold data consists of static vehicle data that is accessed infrequently and archived for a long period of time.
[0023] Furthermore, a method for accessing and connecting a Level 3 autonomous vehicle platform also includes: ensuring reliability and security, wherein the reliability assurance includes automatic retrying when data processing fails, recording error logs and issuing alarms, and implementing traffic shaping through Kafka; and the security assurance includes encrypting and storing sensitive information, using preset security protocols for access authentication, and detecting injection attacks on input data.
[0024] Secondly, this invention also discloses a system for an L3-level autonomous vehicle access connection platform, comprising: a vehicle-side data acquisition module, an MQTT access module, a data processing module, a Kafka distribution module, a multi-platform interface module, and a vehicle management module; wherein:
[0025] The vehicle-side data acquisition module is used to collect and preprocess multi-dimensional data from the vehicle in real time, including periodic data and event data.
[0026] The MQTT access module is used to receive pre-processed multidimensional data from the vehicle, and to perform access authentication and encrypted transmission of the multidimensional data.
[0027] The data processing module is used to decompress, validate, handle anomalies, and standardize fields of the encrypted multidimensional data.
[0028] The Kafka distribution module is used to send standardized multidimensional data to the corresponding topics in the Kafka environment. It uses Kafka's partitioning mechanism to achieve data sharding and supports multi-threaded concurrent consumption.
[0029] The multi-platform integration module is used to subscribe to Kafka topics for the corresponding environment, and to perform data transformation based on the rule engine. It performs data format conversion, field supplementation or structure adaptation for different regulatory platforms, and ensures cross-platform data consistency by associating vehicle identifiers across multiple platforms through VIN.
[0030] The vehicle management module is used to create vehicle files based on VIN, associate vehicle lifecycle data, monitor vehicle data reporting status in real time and trigger abnormal warnings, and store historical data to support full lifecycle data traceability.
[0031] Thirdly, the present invention also discloses an electronic device, comprising:
[0032] One or more processors;
[0033] Memory, used to store one or more programs;
[0034] When the one or more programs are executed by the one or more processors, the one or more processors implement the connection platform method.
[0035] This invention provides a method and system for an L3-level autonomous vehicle access connection platform. The method involves real-time acquisition and preprocessing of multi-dimensional data from the vehicle, followed by access authentication and encrypted transmission of the multi-dimensional data. The encrypted multi-dimensional data is then decompressed, format-validated, anomaly-handled, and field-standardized. The standardized multi-dimensional data is sent to corresponding Kafka topics, with data sharding achieved through Kafka's partitioning mechanism. Subscriptions to Kafka topics are made, and data transformation is performed based on a rule engine, including data format conversion, field supplementation, and structure adaptation for different regulatory platforms. Vehicle identifiers from multiple platforms are associated via Vehicle Identifiers (VINs). Vehicle profiles are established based on VINs, linking them to the vehicle's entire lifecycle data. The system monitors vehicle data reporting status in real-time and triggers anomaly warnings, storing historical data to support full lifecycle data traceability. This invention addresses the technical problems of existing L3-level autonomous vehicle data connection platforms, such as insufficient high-frequency data processing capabilities, poor compatibility with multiple regulatory platforms, inadequate security and compliance, and weak system scalability. Attached Figure Description
[0036] Figure 1A flowchart illustrating a method for access connection platform for L3-level autonomous vehicles provided in an embodiment of the present invention;
[0037] Figure 2 A structural block diagram of an L3-level autonomous vehicle access connection platform system provided in an embodiment of the present invention;
[0038] Figure 3 This is a structural block diagram of an electronic device provided in an embodiment of the present invention. Detailed Implementation
[0039] 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.
[0040] Where there is no conflict, the various embodiments of the present invention and the features thereof may be combined with each other.
[0041] As used herein, the term “and / or” includes any and all combinations of one or more related enumerated entries.
[0042] 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.
[0043] 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.
[0044] 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.
[0045] To address at least one of the technical problems existing in the aforementioned related technologies, the present invention provides a method and system for an L3-level autonomous vehicle access connection platform;
[0046] This implementation discloses a method for accessing and connecting a Level 3 autonomous driving vehicle platform, such as... Figure 1 ,include:
[0047] S100. Real-time collection and preprocessing of multi-dimensional data from the vehicle, the multi-dimensional data including periodic data and event data; in this embodiment, the periodic data includes location, speed, and vehicle status data, the event data includes collision and fault event data, and the collected multi-dimensional data is encapsulated in JSON format and compressed using the GZIP algorithm.
[0048] Specifically, when collecting periodic data, vehicle dynamic data (such as longitude, latitude, vehicle speed, heading angle, etc.) is collected at a frequency of 5Hz and encapsulated in JSON format; when collecting event data, such as when a collision or malfunction is triggered, event details (such as event type, occurrence time, location, etc.) are collected in real time and encapsulated in JSON format; the JSON data is compressed using the GZIP algorithm to reduce the bandwidth usage.
[0049] S200. Receive preprocessed vehicle-side multidimensional data, and perform access authentication and encrypted transmission on the multidimensional data; in this embodiment, the access authentication uses an independent domain name, account, and fixed-format client ID. The client ID is fixed through the vehicle identification code, and the independent domain name and account are used for identity authentication.
[0050] Specifically, the vehicle connects to the cloud platform via the MQTT protocol, with a fixed client ID of "L3@${vin}", and uses an independent domain name and account (MQusername) for authentication; event data is handled by...
[0051] Reporting topic “L3periodic / clientId / {MQusername} / terminal / up / data”;
[0052] Event data is reported by the Topic “L3event / clientId / {MQusername} / terminal / up / data”; the transport layer uses TLS 1.2 encryption to ensure data transmission security.
[0053] S300. Decompress, format verify, handle anomalies, and standardize fields of the encrypted multidimensional data; In this embodiment, the specific steps of decompressing, format verifying, handling anomalies, and standardizing fields of the encrypted multidimensional data include: after receiving the encrypted multidimensional data, decompressing and verifying the legality of the format; marking abnormal data and recording it in the log; and converting fields such as vehicle status code and event type into a unified code.
[0054] In this embodiment, null values and numerical values outside the reasonable range are marked and logged; a transaction rollback and automatic retry mechanism is adopted to ensure recovery in case of data processing failure; traffic smoothing is achieved through the Kafka information department queue to avoid system overload caused by sudden increases in vehicle-side data. Specifically, after receiving data, it is decompressed and its format validity is verified (such as field integrity and data type matching); abnormal data (such as null values and numerical values outside the reasonable range) is marked and logged; standardization processing is performed: fields such as vehicle status code and event type are converted into unified codes (such as mapping to the standard code values of the security information department / information department information platform).
[0055] S400. The standardized multidimensional data is sent to the corresponding topic in the Kafka environment. Data sharding is achieved through Kafka's partitioning mechanism, supporting multi-threaded concurrent consumption. In this embodiment, the standardized multidimensional data is sent to the corresponding topic in the Kafka environment, which includes SIT, PERF, UAT, and PRO environments. The data types include periodic data and event data, and data sharding is achieved through Kafka's partitioning mechanism.
[0056] Specifically, in this embodiment, the naming rule for the information department topic used for distribution is as follows:
[0057] Periodic data information department Topic: "L3_period_tsp_up_data_${environment}";
[0058] The event data information department topic is: "L3_event_tsp_up_data_${environment}"; the environment includes four types of information departments: SIT, PERF, UAT, and PRO. The information department isolation through the information department topic enables independent data transmission in different deployment environments.
[0059] S500 subscribes to the corresponding Kafka topic, performs data transformation based on the rule engine, performs data format conversion, field supplementation or structure adaptation for different regulatory platforms, and ensures cross-platform data consistency by associating vehicle identifiers across multiple platforms through VIN;
[0060] In this embodiment, data format conversion is performed for different regulatory platforms, specifically including: for security platforms: converting data format according to a preset frequency and supplementing GNSS timestamp and vehicle driving mode fields; for information platforms: adapting data structure according to a preset frequency to ensure compliance with the data collection specifications for intelligent connected vehicles.
[0061] Specifically, the multi-platform interface layer subscribes to the corresponding Kafka topic in the information department and performs data transformation based on the rule engine: For the security platform: the data format is transformed according to the information department's 5Hz frequency, and fields such as the information department's GNSS information department timestamp and vehicle driving mode are added; For the information platform: the data structure is adapted according to the information department's 1Hz frequency to ensure compliance with the "Intelligent Connected Vehicle Data Collection Specification"; the information department's VIN information department is associated with the vehicle identifiers of multiple platforms to ensure cross-platform data consistency.
[0062] S600. Establishes vehicle files based on VIN, associates them with vehicle lifecycle data, monitors vehicle data reporting status in real time and triggers anomaly warnings, and stores historical data to support full lifecycle data traceability. Historical data includes cold data and hot data. The cold data storage period is a first time period, and the hot data storage period is a second time period, with the first time period being longer than the second time period. Among them, the hot data is core vehicle operation data that is accessed frequently and responded to in real time, while the cold data is static vehicle data that is accessed infrequently and archived for a long time.
[0063] Specifically, for the full lifecycle management of vehicles, metadata is linked: using the VIN information department as the unique identifier, metadata such as enterprise code, vehicle model series, production information, and access status are linked to build a complete vehicle file;
[0064] Status monitoring: Real-time monitoring of vehicle data reporting status, triggering alerts for vehicles that are offline for more than a preset time or have abnormal data, so that maintenance personnel can handle them in a timely manner;
[0065] Data is stored in a tiered manner: hot data is stored in a high-speed cache to ensure high-frequency access efficiency; cold data is stored in low-cost offline media to reduce storage costs, balancing efficiency and economy.
[0066] In this embodiment, a method for accessing and connecting a Level 3 autonomous vehicle platform further includes: S600. Ensuring reliability and security, wherein the reliability assurance includes automatic retrying when data processing fails, recording error logs and issuing alarms, and implementing traffic shaping through Kafka; the security assurance includes encrypting and storing sensitive information, using preset security protocols for access authentication, and detecting injection attacks on input data.
[0067] To better understand this implementation, the following example illustrates the processing flow of periodic data and event data:
[0068] The periodic data processing workflow includes:
[0069] The vehicle-side collects data such as location, speed, and heading angle at 5Hz, encapsulates it into JSON format (including header and body fields), compresses it with GZIP, and then reports it to the corresponding Topic via MQTT protocol.
[0070] Verify the client's information department ID and access permissions, and decrypt the data via information department TLS before forwarding it to the data processing layer;
[0071] Decompress the data, verify the integrity of the fields and the validity of the data types, and convert the status codes into a unified encoding;
[0072] Data is distributed to the corresponding information department topic in Kafka according to the environment, and concurrent consumption is achieved through a partitioning mechanism;
[0073] Subscribe to the Information Department Topic, and distribute the data after adapting the data format to the frequencies of the Security Platform Information Department (5Hz) and the Information Department Platform Information Department (1Hz).
[0074] The vehicle management module stores data and updates vehicle status, supporting subsequent traceability.
[0075] The event data processing flow includes:
[0076] When a vehicle collides or malfunctions, event data is collected, encapsulated in JSON format (including event type, occurrence time, location, etc.), compressed by GZIP, and then reported through the Topic information department.
[0077] Prioritize processing event data and quickly forward it to the data processing layer;
[0078] Identify event types, trigger high-priority processing flows, and ensure zero data latency;
[0079] Data is distributed to the information department's Kafka event category information department topic, and relevant data is supplemented as required by regulations (such as high-frequency status data of the information department 15 seconds before and after the collision event).
[0080] Distribute data to relevant platforms to ensure complete reporting of event information;
[0081] Record event data, update vehicle malfunction status, and trigger warnings.
[0082] This embodiment provides a method for access connection platform for L3 autonomous vehicles. The method involves real-time acquisition and preprocessing of multi-dimensional data from the vehicle, followed by access authentication and encrypted transmission of the multi-dimensional data. The encrypted multi-dimensional data is then decompressed, format-validated, anomaly-handled, and field-standardized. The standardized multi-dimensional data is sent to corresponding Kafka topics, with data sharding achieved through Kafka's partitioning mechanism. Subscription to Kafka topics within the corresponding environment is performed, and data transformation is implemented based on a rule engine. Data format conversion, field supplementation, or structure adaptation are performed for different regulatory platforms. Vehicle identifiers from multiple platforms are associated through the Vehicle Identifier (VIN). A vehicle profile is established based on the VIN, linking it to the vehicle's entire lifecycle data. The vehicle data reporting status is monitored in real-time, triggering anomaly warnings, and historical data is stored to support full lifecycle data traceability. This invention addresses the technical problems of existing L3 autonomous vehicle data connection platforms, including insufficient high-frequency data processing capabilities, poor compatibility with multiple regulatory platforms, inadequate security and compliance, and weak system scalability.
[0083] Based on the same inventive concept, embodiments of the present invention also provide a system for an L3-level autonomous vehicle access connection platform, such as... Figure 2 It includes: a vehicle-side data acquisition module, an MQTT access module, a data processing module, a Kafka distribution module, a multi-platform integration module, and a vehicle management module; among which:
[0084] The vehicle-side data acquisition module is used to collect and preprocess multi-dimensional data from the vehicle in real time, including periodic data and event data.
[0085] The MQTT access module is used to receive pre-processed multidimensional data from the vehicle, and to perform access authentication and encrypted transmission of the multidimensional data.
[0086] The data processing module is used to decompress, validate, handle anomalies, and standardize fields of the encrypted multidimensional data.
[0087] The Kafka distribution module is used to send standardized multidimensional data to the corresponding topics in the Kafka environment. It uses Kafka's partitioning mechanism to achieve data sharding and supports multi-threaded concurrent consumption.
[0088] The multi-platform integration module is used to subscribe to Kafka topics for the corresponding environment, and to perform data transformation based on the rule engine. It performs data format conversion, field supplementation or structure adaptation for different regulatory platforms, and ensures cross-platform data consistency by associating vehicle identifiers across multiple platforms through VIN.
[0089] The vehicle management module is used to create vehicle files based on VIN, associate vehicle lifecycle data, monitor vehicle data reporting status in real time and trigger abnormal warnings, and store historical data to support full lifecycle data traceability.
[0090] The specific working methods of the vehicle-side data acquisition module, MQTT access module, data processing module, Kafka distribution module, multi-platform integration module, and vehicle management module have been described in detail in the above-mentioned platform connection method, and will not be repeated here.
[0091] Based on the same inventive concept, embodiments of the present invention also provide an electronic device. Figure 3 This is a structural block diagram of an electronic device provided in an embodiment of the present invention. Figure 3 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 platform connection methods described in the above embodiments; the one or more I / O interfaces 103 are connected between the processor and the memory, configured to enable information interaction between the processor and the memory.
[0092] 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).
[0093] 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.
[0094] In some embodiments, the one or more processors 101 include a field-programmable gate array.
[0095] 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 platform connectivity methods described in the above embodiments. The computer-readable storage medium may be volatile or non-volatile.
[0096] 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 platform connection method described above.
[0097] 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).
[0098] 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.
[0099] 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.
[0100] 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.
[0101] 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.
[0102] 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.
[0103] 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.
[0104] 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.
[0105] 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.
[0106] 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 method for accessing and connecting a Level 3 autonomous driving vehicle platform, characterized in that, include: Real-time acquisition and preprocessing of multidimensional data from the vehicle, including periodic data and event data; Receive preprocessed vehicle-side multidimensional data, and perform access authentication and encrypted transmission on the multidimensional data; Decompress, validate, handle anomalies, and standardize fields of encrypted multidimensional data; The standardized multidimensional data is sent to the corresponding topic in the Kafka environment. Data sharding is achieved through Kafka's partitioning mechanism, which supports multi-threaded concurrent consumption. Subscribe to the corresponding Kafka topic, implement data transformation based on the rule engine, perform data format conversion, field supplementation or structure adaptation for different regulatory platforms, and ensure cross-platform data consistency by associating vehicle identifiers across multiple platforms through VIN; Vehicle files are established based on VINs, linking vehicle data throughout its entire lifecycle. The system monitors vehicle data reporting status in real time and triggers anomaly alerts, while storing historical data to support full lifecycle data traceability.
2. The connection platform method according to claim 1, characterized in that, The periodic data includes location, speed, and vehicle status data, and the event data includes collision and fault event data. The collected multidimensional data is encapsulated in JSON format and compressed using the GZIP algorithm.
3. The method according to claim 1, characterized in that, The access authentication uses an independent domain name, account, and a fixed-format client ID. The client ID is fixed through a vehicle identification code, and the independent domain name and account are used for identity authentication.
4. The connection platform method according to claim 1, characterized in that, The encrypted multidimensional data is decompressed, format verified, anomaly handled, and field standardized. The specific steps include: after receiving the encrypted multidimensional data, decompressing and verifying the format validity; marking abnormal data and logging it; and converting fields such as vehicle status code and event type into a unified code.
5. The connection platform method according to claim 1, characterized in that, The standardized multidimensional data is sent to the corresponding topics in the Kafka environment, which includes SIT, PERF, UAT, and PRO environments. The data types include periodic data and event data, and data sharding is achieved through Kafka's partitioning mechanism.
6. The connection platform method according to claim 1, characterized in that, Data format conversion is performed for different regulatory platforms, specifically including: for security platforms: converting data formats according to preset frequencies and supplementing GNSS timestamps and vehicle driving mode fields; for information platforms: adapting data structures according to preset frequencies to ensure compliance with the data collection specifications for intelligent connected vehicles.
7. The connection platform method according to claim 1, characterized in that, Historical data includes cold data and hot data. The cold data storage period is a first time period, and the hot data storage period is a second time period, with the first time period being longer than the second time period. The hot data consists of core vehicle operation data that is accessed frequently and responded to in real time, while the cold data consists of static vehicle data that is accessed infrequently and archived for a long period of time.
8. The connection platform method according to claim 1, characterized in that, Also includes: Reliability and security are ensured. The reliability assurance includes automatic retrying when data processing fails, recording error logs and issuing alarms, and traffic shaping through Kafka. The security assurance includes encrypting and storing sensitive information, using preset security protocols for access authentication, and detecting injection attacks on input data.
9. A system for an L3-level autonomous vehicle access connection platform, characterized in that, include: The system includes a vehicle-side data acquisition module, an MQTT access module, a data processing module, a Kafka distribution module, a multi-platform integration module, and a vehicle management module; among which: The vehicle-side data acquisition module is used to collect and preprocess multi-dimensional data from the vehicle in real time, including periodic data and event data. The MQTT access module is used to receive pre-processed multidimensional data from the vehicle, and to perform access authentication and encrypted transmission of the multidimensional data. The data processing module is used to decompress, validate, handle anomalies, and standardize fields of the encrypted multidimensional data. The Kafka distribution module is used to send standardized multidimensional data to the corresponding topics in the Kafka environment. It uses Kafka's partitioning mechanism to achieve data sharding and supports multi-threaded concurrent consumption. The multi-platform integration module is used to subscribe to Kafka topics for the corresponding environment, and to perform data transformation based on the rule engine. It performs data format conversion, field supplementation or structure adaptation for different regulatory platforms, and ensures cross-platform data consistency by associating vehicle identifiers across multiple platforms through VIN. The vehicle management module is used to create vehicle files based on VIN, associate vehicle lifecycle data, monitor vehicle data reporting status in real time and trigger abnormal warnings, and store historical data to support full lifecycle data traceability.
10. 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 connection platform method as described in any one of claims 1 to 8.