Vehicle registration method, system, equipment and product in research and development test stage

Abstract

The invention provides a vehicle registration method, system, equipment and product in a research and development test stage, and relates to the technical field of vehicle registration, and the method avoids the tedious and error of manual input by automatically reading a test state code and hardware information in a vehicle engineering mode; by verifying the integrity and legality of the registration information, it is ensured that only compliant research and development test vehicles can complete registration, and the safety and reliability of the system are enhanced; meanwhile, registration result information comprises registration records, vehicle information tables and associated test case numbers, automatic generation and structured storage can be achieved, centralized management and traceability of data are achieved, finally, results are pushed to users in real time through the front end, the response time is greatly shortened, and the user experience is improved. The problems that a traditional manual registration mode is low in efficiency, prone to making mistakes and difficult in collaboration are effectively solved, and efficient and intelligent technical support is provided for the research and development test process.

Description

Technical Field

[0001] This application relates to the field of vehicle registration technology, and in particular to a vehicle registration method, system, device and product in the research and development testing phase. Background Technology

[0002] With the rapid development of the automotive industry and vehicle-to-everything (V2X) technology, vehicle registration has become an indispensable part of the production, sales, and use of connected vehicles. However, during the research and development testing phase, traditional vehicle registration methods mainly rely on manual operation, including manually reading vehicle information, filling out forms, and having specialized personnel enter the data into the database. This method is inefficient and prone to errors, limiting the response to large-scale, high-frequency registration demands and increasing labor costs and the risk of operational errors. Therefore, existing technologies have significant drawbacks, such as low efficiency, poor accuracy, and high labor costs. Summary of the Invention

[0003] This application provides a vehicle registration method, system, device, and product for the research and development testing phase, to solve one or more technical problems existing in the prior art, and to at least provide a beneficial option or create conditions.

[0004] On the one hand, this application provides a vehicle registration method during the research and development testing phase. The method is applied to an integrated environment between a vehicle registration front-end built on a low-code platform and a vehicle cloud back-end system, and includes the following steps: The vehicle cloud backend system receives vehicle registration information submitted by users through the vehicle registration frontend. The vehicle registration information includes at least a test mode status code, a test batch number, a test stage identifier, and vehicle hardware information. The test mode status code and the vehicle hardware information are automatically read through a vehicle engineering mode preset interface. The vehicle registration information is verified to determine whether the vehicle is in the engineering mode of R&D testing. After the verification is passed, registration result information is generated, including the corresponding registration record, vehicle information table and associated test case number. In the service layer of the vehicle cloud backend system, the registration result information and the vehicle registration information are encapsulated into structured data and sent to the data layer of the vehicle cloud backend system for storage. The vehicle registration front end receives the registration result information returned by the vehicle cloud backend system and pushes it to the user terminal.

[0005] Furthermore, before receiving the vehicle registration information submitted by the user through the vehicle registration front-end, the method further includes: The system verifies whether a user account belongs to the R&D testing project team through the organizational structure interface between the vehicle registration front-end and the office software. The office software is deeply integrated with the low-code platform and supports obtaining the user's testing project permissions and permission validity period through the organizational structure level. If the user's permission validity period is within the current testing phase, the user is allowed to submit registration information; otherwise, the submission is rejected and a "No R&D testing permissions" message is returned.

[0006] Furthermore, the step of receiving vehicle registration information submitted by the user through the vehicle registration front-end in the vehicle cloud back-end system includes: Users can select the test batch number and test phase identifier associated with their R&D test project group; The vehicle cloud backend system calls the vehicle engineering mode wireless debugging tool to automatically import the test mode status codes and vehicle hardware information in engineering mode.

[0007] Furthermore, the vehicle hardware information includes the ECU firmware version number; The verification of the vehicle registration information includes field integrity verification, format correctness verification, and information legality verification. The information validity verification includes: Verify whether the ECU firmware version number matches the minimum firmware version requirement corresponding to the test batch number. If they match, the verification is considered successful. If they do not match, return the message "Version of R&D test vehicle is incompatible, registration is prohibited". The test mode status code is verified. If the test mode status code is R&D debugging mode, the status verification is deemed to have passed; otherwise, the message "Non-R&D test vehicle, registration prohibited" is returned.

[0008] Furthermore, the test phase identifier is associated with tags for various R&D scenarios and is linked to the year field in the test batch number.

[0009] Furthermore, the registration record includes a test batch association field for associating with the test batch number; the vehicle information table includes a test case association column, which records at least one test case number, which is automatically obtained by matching the test batch number from a preset test case library.

[0010] Furthermore, the service layer and data layer of the vehicle cloud backend system interact with each other through a caching layer and a message queue, wherein: The cache layer uses key-value pairs to store frequently queried vehicle registration information, and the cache validity period is set to 24 hours. The message queue is used to asynchronously process notification push tasks after successful registration, including sending a registration completion message and a link to generate a vehicle information table to the user terminal.

[0011] On the other hand, this application provides a vehicle registration system for the research and development testing phase, comprising: The front-end module is used to receive vehicle registration information submitted by users through the vehicle registration front-end in the vehicle cloud back-end system. The vehicle registration information includes at least a test mode status code, a test batch number, a test stage identifier, and vehicle hardware information. The test mode status code and the vehicle hardware information are automatically read through a preset interface of the vehicle engineering mode. The verification module is used to verify the vehicle registration information, check whether the vehicle is in the R&D engineering mode, and generate registration result information after the verification is passed, including the corresponding registration record, vehicle information table and associated test case number. An encapsulation and storage module is used to encapsulate the registration result information and the vehicle registration information into structured data at the service layer of the vehicle cloud backend system and send it to the data layer of the vehicle cloud backend system for storage. The message push module is used to receive the registration result information returned by the vehicle cloud backend system at the vehicle registration frontend and push it to the user terminal.

[0012] On the other hand, this application provides an electronic device including a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the aforementioned vehicle registration method in the research and development testing phase.

[0013] On the other hand, this application provides a computer program product, including a computer program that, when executed by a processor, implements the aforementioned vehicle registration method during the research and development testing phase.

[0014] This application provides at least the following beneficial effects: It offers a vehicle registration method for the R&D testing phase, which avoids the tediousness and errors of manual data entry by automatically reading test status codes and hardware information in vehicle engineering mode; by verifying the completeness and legality of registration information, it ensures that only compliant R&D testing vehicles can complete registration, enhancing the system's security and reliability; simultaneously, the registration result information, including registration records, vehicle information tables, and associated test case numbers, can be automatically generated and structured for storage, achieving centralized data management and traceability; finally, the results are pushed to users in real time through the front end, significantly shortening response time and effectively solving the problems of low efficiency, error-proneness, and difficulty in collaboration associated with traditional manual registration methods, providing efficient and intelligent technical support for the R&D testing process. This application also provides corresponding systems, equipment, and products, the beneficial effects of which are similar to the method and will not be elaborated upon here.

[0015] Other features and advantages of this application will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the application. The objectives and other advantages of this application may be realized and obtained by means of the structures particularly pointed out in the description, claims and drawings. Attached Figure Description

[0016] The accompanying drawings are provided to further understand the technical solutions of the present invention and constitute a part of the specification. They are used together with the embodiments of the present invention to explain the technical solutions of the present invention, and do not constitute a limitation on the technical solutions of the present invention.

[0017] Figure 1 This is a flowchart of the vehicle registration method during the research and development testing phase provided in this application; Figure 2 This is a structural diagram of the vehicle registration system during the research and development testing phase provided in this application. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0019] The present application will be further described below with reference to the accompanying drawings and specific embodiments. The described embodiments should not be considered as limitations on the present application, and all other embodiments obtained by those skilled in the art without inventive effort are within the scope of protection of the present application.

[0020] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0021] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0022] With the rapid development of the automotive industry, especially the continuous advancement of intelligent connected vehicle technology, vehicle registration has become a crucial link in vehicle lifecycle management. Throughout the entire process of vehicle development, testing, production, sales, and use, vehicle registration not only undertakes the basic functions of identification, information entry, and system access, but is also a prerequisite for realizing connected vehicle services (such as remote diagnostics, OTA upgrades, and data collection). Particularly during the R&D and testing phase, a large number of prototype vehicles need to be connected to connected vehicle platforms for functional verification, performance evaluation, and system debugging, which generates frequent and diverse vehicle registration demands.

[0023] Currently, vehicle registration mainly falls into two categories: automated batch registration during mass production and manual or semi-manual registration during the R&D and testing phase. For mass-produced vehicles, since vehicle information is relatively fixed and registration time is concentrated, registration can usually be completed through integration with the MES (Manufacturing Execution System) using batch data import or automated scripts, resulting in a highly automated and efficient process. However, the situation is quite different during the R&D and testing phase. Vehicles in this phase are mostly prototypes or trial production vehicles, and registration requirements are characterized by variable timing, large quantity fluctuations, diverse testing objectives, and complex vehicle states. For example, different test batches may correspond to different software versions, hardware configurations, or test scenarios, and registration information needs to be associated with specific test tasks, test cases, project team permissions, etc.

[0024] In current technological practices, vehicle registration during the R&D and testing phase generally employs traditional manual registration methods. The specific process typically involves the following: First, test engineers or relevant personnel need to enter the vehicle's engineering mode and manually read key hardware information such as the Vehicle Identification Number (VIN), T-Box serial number, SIM card information, gateway number, and ECU firmware version using the vehicle's infotainment system or specialized tools. Subsequently, this information needs to be transmitted through unstructured channels, such as filling the information into a shared Excel spreadsheet and submitting it to designated registration personnel via instant messaging tools (e.g., WeChat groups, DingTalk groups). Finally, a registration specialist logs into the backend management system and enters the information from the spreadsheet into the database of the Telematics Service Provider (TSP) platform, completing the registration. This traditional manual registration method has many serious shortcomings and is no longer able to meet the requirements of efficiency, accuracy, and collaboration in modern automotive R&D, specifically in the following aspects.

[0025] First, the entire registration process involves multiple stages and personnel collaboration, relying on manual operation and non-real-time communication, resulting in long response times. Registration specialists need to manually process each request, handling only a few dozen vehicle registrations per day. During peak development periods, registration requests accumulate significantly, severely impacting testing progress and project timelines. Furthermore, information transmission relies on group chats and file sharing, which is prone to omissions or duplications, further reducing processing efficiency.

[0026] Secondly, manual operation inevitably introduces subjective errors. Data errors can occur during information reading, recording, transmission, and entry, such as incorrect VIN code transcription, T-Box serial number confusion, and missing firmware version numbers. Once these errors enter the system, they may prevent vehicles from connecting to the network, cause test data corruption, or even affect the testing environment of other vehicles, causing significant difficulties for subsequent reviews, testing, and troubleshooting. In severe cases, it may lead to test failure or invalid data.

[0027] Furthermore, companies need to hire dedicated registration specialists to handle these repetitive, low-value manual tasks, which not only increases direct labor costs but also requires personnel training and management. Meanwhile, test engineers also waste time waiting for registration to complete, lowering overall R&D efficiency. This cost issue becomes particularly pronounced as companies grow and R&D tasks increase.

[0028] Furthermore, in the traditional approach, registration information is scattered and lacks a unified data management and auditing mechanism. Once a problem arises, it is difficult to quickly trace key information such as registration records, operation times, and responsible parties. At the same time, there is a lack of systematic correlation between the registration process and specific test projects, test batches, and test cases, making it impossible to automatically match registration information with test tasks, which is detrimental to the analysis and management of test data.

[0029] Moreover, with the diversification of R&D testing scenarios, registration requirements are becoming increasingly complex. For example, different test batches may require different firmware versions, different test mode states, and even the automatic association of specific test cases. Traditional manual methods cannot flexibly cope with these dynamic changes, let alone achieve intelligent verification and automated processing. In summary, existing vehicle registration technologies in the R&D testing phase mainly rely on inefficient, error-prone, and high-cost manual operation modes, which restricts the iteration speed and quality assurance capabilities of automotive R&D.

[0030] To address the aforementioned issues, this application provides a vehicle registration method, system, device, and product for the R&D testing phase. Its main technical features include: constructing a user-friendly front-end registration portal through a low-code platform and interfacing with a pre-defined interface for vehicle engineering mode, enabling automatic reading and submission of key hardware information such as test mode status codes, VIN codes, and T-BOX serial numbers, avoiding manual data entry; establishing a strict verification mechanism in the vehicle cloud backend system to verify whether the vehicle is in R&D engineering mode and whether the firmware version meets the test batch requirements, ensuring registration legitimacy; after successful registration, the system automatically generates structured data containing registration records, vehicle information tables, and associated test case numbers, which is then encapsulated in the service layer and stored in the data layer, achieving centralized and standardized information management; simultaneously, caching and message queue technologies are used to improve system performance and response speed, and registration results are pushed to users in real time through the front end, forming a closed loop. The entire process achieves end-to-end automation from information collection, verification, storage to feedback, significantly improving registration efficiency and accuracy while reducing labor costs and operational risks.

[0031] First, the vehicle registration method for the R&D testing phase provided in this application will be described in detail below with reference to the accompanying drawings. This method is applied to the integrated environment between a vehicle registration front-end built on a low-code platform and a vehicle cloud back-end system. The vehicle registration front-end built on a low-code platform provides R&D testers with a standardized and visual operation entry point. Users do not need to rely on unstructured methods such as WeChat groups or Excel spreadsheets to submit information; instead, they complete the registration request through a unified online form.

[0032] In this application, the low-code platform serves as the foundation for the vehicle registration front-end, playing a core role in rapidly building user interaction entry points and visually configuring business processes. The platform features a graphical, drag-and-drop development interface, enabling even non-professional developers to efficiently design and deploy registration forms, permission verification logic, and data display pages, significantly reducing the development threshold and cycle time for front-end applications. Through deep integration with enterprise office software, the low-code platform can seamlessly connect with organizational structures, achieving automatic user identification and dynamic permission control, ensuring that only personnel with R&D and testing qualifications can submit registration requests. Simultaneously, the platform supports automated process orchestration, standardizing the connection between user-submitted vehicle information and back-end services to achieve efficient data flow and closed-loop feedback, providing R&D personnel with a convenient, intuitive, and secure operating experience.

[0033] The TSP Vehicle Cloud Backend System is the key backend support system in this application, responsible for core business processing, data verification, and storage. It undertakes the logic processing and data management functions in the vehicle registration process. This system receives registration requests from the low-code frontend and verifies the completeness, format, and legality of key information such as the vehicle's test mode status code, ECU firmware version, and VIN code to ensure that registered vehicles meet the safety and technical requirements of R&D testing. Through service-layer business logic processing, the system intelligently associates registration information with test batches, test stages, and preset test case libraries, and persistently stores structured data in a database cluster, ensuring data reliability and traceability. Furthermore, the TSP Vehicle Cloud Backend integrates a caching layer and message queue to improve system performance and response speed, and supports asynchronous task processing, such as registration result notification pushes and information table generation. This enables stable operation under high-concurrency scenarios, providing a powerful, secure, and scalable technical foundation for R&D test vehicle management in a connected vehicle environment.

[0034] Reference Figure 1 The implementation process of the vehicle registration method in the research and development testing phase provided in this application embodiment includes, but is not limited to, the following steps.

[0035] Step S110: In the vehicle cloud backend system, receive the vehicle registration information submitted by the user through the vehicle registration frontend.

[0036] The vehicle registration information includes at least the test mode status code, test batch number, test phase identifier, and vehicle hardware information. The test mode status code and vehicle hardware information are automatically read through the vehicle engineering mode preset interface.

[0037] In step S110, the automated acquisition of key information is achieved—the test mode status code and vehicle hardware information (such as VIN code, T-BOX serial number, gateway number, card information, etc.) are not manually entered by the user, but are automatically read directly from the vehicle system by calling the preset interface in the vehicle engineering mode. This design fundamentally eliminates errors that may be caused by manual transcription (such as character confusion, omissions, etc.), improving the accuracy and completeness of the data. At the same time, the automatic reading method simplifies user operation, shortens information preparation time, and improves user experience. In addition, users also need to manually select or enter the test batch number and test stage identifier. This information is used to associate vehicle registration with specific R&D projects, test cycles, and test scenarios, providing a structured foundation for subsequent test management and data traceability. The vehicle cloud backend system, as the information receiving hub, ensures centralized management and unified processing of all registration requests, laying a solid data foundation for subsequent verification, storage, and feedback.

[0038] Step S120: Verify the vehicle registration information to check whether the vehicle is in the engineering mode of research and development testing. After the verification is passed, generate registration result information.

[0039] The registration result information includes the corresponding registration record, vehicle information table, and associated test case number.

[0040] In step S120, the submitted registration information undergoes multi-dimensional and multi-level verification to confirm whether the vehicle is in the engineering mode of R&D testing. After successful verification, a structured output result is generated. Only vehicles that pass rigorous verification can proceed to the next step, effectively ensuring the security of the vehicle networking platform and the purity of the testing environment. Upon successful verification, the system does not simply return "registration successful," but intelligently generates rich registration result information: including a "registration record" recording metadata such as registration time, operator, and batch number; a "vehicle information table" storing complete vehicle hardware and configuration information; and most importantly, a "test case number" automatically matched and associated from a preset test case library based on the test batch number. This association mechanism automatically binds vehicle registration with testing tasks, providing a direct data link for subsequent automated test execution, test data collection, and issue tracking, greatly improving the collaborative efficiency and data value of R&D testing.

[0041] In step S130, the registration result information and vehicle registration information are encapsulated into structured data in the service layer of the vehicle cloud backend system and sent to the data layer of the vehicle cloud backend system for storage.

[0042] In step S130, reliable storage and efficient management of registration data are ensured, along with support for subsequent business expansion. The service layer, as the processing center for business logic, is responsible for integrating and encapsulating the verified original registration information with system-generated registration result information (such as registration records, vehicle information tables, test case numbers, etc.) to form a unified, structured data packet conforming to a preset data model. This structured design not only facilitates standardized data storage but also greatly simplifies subsequent queries, analysis, and interface calls. Data is sent to the data layer (usually a relational database cluster) for persistent storage. Database master-slave replication and sharding technologies ensure high availability, consistency, and security of the data, preventing data loss due to system failures.

[0043] Step S140: At the vehicle registration front end, the registration result information returned by the vehicle cloud backend system is received and pushed to the user terminal.

[0044] In step S140, real-time information feedback and user experience optimization are achieved. After the data is verified, encapsulated, and stored, the vehicle cloud backend system returns response information, including registration results, vehicle information table links, and associated test cases, to the low-code vehicle registration frontend via an API interface. Upon receiving this information, the frontend system can push it to the user's terminal that initiated the registration in a clear and intuitive manner (such as pop-up prompts, status updates, and the generation of downloadable PDF reports). This instant feedback mechanism allows users to immediately know whether registration was successful, which test tasks were associated, and whether the vehicle information is correct, without actively querying or waiting for manual notification, greatly improving operational transparency and user satisfaction.

[0045] More importantly, the registration result information pushed to users is not just a simple "success / failure" notification, but a "result package" containing rich context. Users can directly click to view or download the vehicle information form to understand which test batch their vehicle has been included in and which test cases it will participate in, providing clear guidance for subsequent testing. This closed-loop design not only completes the final confirmation of the registration process but also enhances the system's usability and practicality, truly achieving an efficient service experience of "one-time submission, full visibility, and clear results," effectively solving the problems of delayed and opaque information feedback in the traditional manual mode.

[0046] In some embodiments of this application, before receiving vehicle registration information submitted by a user through the vehicle registration front-end, it is necessary to verify whether the user account belongs to the R&D testing project team through the organizational structure interface between the vehicle registration front-end and the office software. The office software is deeply integrated with the low-code platform, supporting the acquisition of the user's testing project permissions and their validity period through the organizational structure hierarchy. If the user's permissions are valid within the current testing phase, the submission of registration information is allowed. Otherwise, the submission is rejected and a "No R&D testing permissions" message is returned.

[0047] This step serves as a preliminary security verification step in the entire vehicle registration process. Its core function is to build the first line of defense for access control, ensuring that only R&D and testing personnel with legitimate identities and valid permissions can initiate registration requests, thereby guaranteeing the security and data compliance of the vehicle networking platform from the source.

[0048] In traditional manual registration, registration requests are often submitted through open channels such as group chats or emails, which cannot effectively identify and verify the submitter's identity and permissions, posing a risk of unauthorized or malicious submissions. This application, however, deeply integrates the vehicle registration front-end with the organizational structure interface of enterprise office software, achieving automatic user identification and dynamic permission verification. When a user attempts to access the registration page or submit information, the system calls the office software's API in real time to query whether the user belongs to a specific R&D testing project team and further obtains the validity period of their permissions within that project. This organizational structure-based permission management mechanism accurately matches user roles (such as test engineers, project managers, outsourced personnel, etc.) with their actual job responsibilities, preventing permission abuse.

[0049] Crucially, the system not only verifies whether a user belongs to the project team but also determines whether their permission validity period covers the current testing phase, thus supporting refined management of temporary and interim participants. Only when both verifications (organizational affiliation + validity period) pass will the system allow the user to submit registration information; otherwise, it immediately returns a clear "No R&D testing permissions" message, preventing unauthorized operations. This design not only enhances system security, preventing potential risks (such as data leaks and system interference) from unauthorized access to the platform, but also improves management standardization, achieving automated control over "who can register and when can register," laying a solid foundation for reliable identity authentication throughout the registration process.

[0050] In some embodiments of this application, step S110 involves receiving vehicle registration information submitted by the user through the vehicle registration front-end in the vehicle cloud back-end system, including the following steps.

[0051] Step S210 allows users to select the test batch number and test phase identifier associated with their R&D test project group.

[0052] In step S210, the structured and contextualized association of registration information is implemented at the user interaction level. Its core function is to precisely bind vehicle registration behavior with specific R&D projects, testing cycles, and testing objectives, providing crucial contextual information for subsequent test management, data traceability, and resource scheduling. During the R&D testing phase, vehicles do not exist in isolation but belong to specific test projects, test batches, and test phases (such as functional verification, performance testing, and durability testing). Different test batches may correspond to different software versions, hardware configurations, test case sets, and quality objectives.

[0053] By providing a drop-down menu or selector at the vehicle registration front end, users can select the corresponding "test batch number" and "test phase identifier" from the scope of their respective R&D testing project group. The system can automatically obtain the metadata of the batch (such as start time, end time, person in charge, test objectives, etc.) and record this information as part of the registration data.

[0054] This design not only avoids formatting errors or semantic ambiguity that may result from manual user input, but more importantly, it establishes a structured association between vehicles and testing tasks. For example, the system can automatically match the minimum ECU firmware version required for a test batch number, performing version compliance checks in subsequent verification stages. Simultaneously, the vehicle information table and registration records generated during registration will also include batch and stage information, facilitating administrators to count the number of registered vehicles by batch, analyze testing progress, and track problematic vehicles. Furthermore, this step supports parallel management of multiple projects and teams, ensuring that test vehicle information from different project groups is isolated and does not interfere with each other, thus improving the system's organizational management capabilities.

[0055] Step S220: Through the vehicle cloud backend system, call the vehicle engineering mode wireless debugging tool to automatically import the test mode status code and vehicle hardware information in engineering mode.

[0056] In step S220, technical means are used to replace traditional manual transcription and input, achieving zero-error and high-efficiency collection of key vehicle information. In the traditional mode, test engineers need to enter vehicle engineering mode to manually view and record hardware information such as VIN code, T-BOX serial number, gateway number, card information, and ECU firmware version, a tedious and error-prone process. This application integrates a "vehicle engineering mode wireless debugging tool" (such as a Wi-Fi or Bluetooth-based remote diagnostic tool, OBD-II wireless adapter, or a dedicated debugging APP) into the vehicle cloud backend system, enabling remote communication with the vehicle ECU and T-Box.

[0057] When a user initiates a registration request, the system can automatically or on-demand trigger the tool to connect to the target vehicle via a preset communication protocol (such as UDS, DoIP, etc.) and directly read the "test mode status code" and various "vehicle hardware information" from the vehicle's firmware or configuration files. This automated data collection method has multiple advantages: First, the data is highly accurate, as the information comes directly from the vehicle system, eliminating errors and omissions during manual copying and transcription; second, the operation is highly efficient, with the entire reading process completed within seconds, significantly shortening information preparation time; and third, it is easy to operate, as users do not need in-depth vehicle electronics knowledge or to repeatedly enter and exit the vehicle's infotainment system, lowering the operational threshold.

[0058] More importantly, automatically reading the "test mode status code" is a crucial basis for verifying whether a vehicle is in the research and development debugging stage, providing a reliable data source for subsequent safety verification. This step not only significantly improves the automation level of the registration process but also ensures the originality, authenticity, and integrity of the registration data, providing a solid guarantee for the data quality of the vehicle networking platform and serving as the core technical support for achieving "efficient, accurate, and intelligent" registration.

[0059] In some embodiments of this application, the vehicle hardware information includes the vehicle VIN code, TBOX device serial number, vehicle gateway number, ECU firmware version number, and card information. In step S120, the vehicle registration information is verified, including field integrity verification, format correctness verification, and information legality verification.

[0060] The purpose of verifying vehicle registration information is to build a multi-layered, multi-dimensional data verification system to ensure that every test vehicle entering the vehicle-to-everything (V2X) platform meets safety, compliance, and functional requirements. Traditional registration methods often only focus on whether information is filled in, lacking a systematic verification mechanism, which leads to the entry of incorrect or non-compliant vehicle information, thereby affecting the stability of the testing environment and the reliability of the data.

[0061] This application achieves comprehensive oversight from the surface to the depths by introducing a triple verification mechanism: "integrity verification," "format correctness verification," and "information legality verification." Integrity verification ensures that all required fields (such as VIN code, T-BOX serial number, and test batch number) have been submitted, preventing subsequent process interruptions due to missing information. Format correctness verification standardizes the data structure, for example, verifying whether the VIN code is 17 characters and whether the ECU firmware version number conforms to the "vX.YZ" format, ensuring that the data can be correctly parsed and processed in the system. These two types of verification are basic checks. However, the "information legality verification" truly reflects the intelligence and business depth of this application. It closely integrates the registration process with specific R&D testing business rules, using logical judgment to ensure that the vehicle status and configuration meet the requirements of the current testing task, thereby eliminating the risk of "incorrect vehicles, incorrect versions, and incorrect modes" accessing the system at the source, ensuring the purity of the testing environment and the validity of the data.

[0062] Information validity verification includes: (1) Verify whether the ECU firmware version number matches the minimum firmware version requirement corresponding to the test batch number. If it matches, the verification is considered successful. If it does not match, the message "The version of the R&D test vehicle does not match, registration is prohibited" will be returned.

[0063] The purpose of verifying the validity of the ECU firmware version number is to ensure that the vehicle's software version is consistent with the technical requirements of the current testing task, avoiding test failures or data anomalies due to version incompatibility. During R&D testing, different test batches often verify specific software versions. For example, one test batch might focus on verifying new features in version "v2.1.0," while another batch is used to fix known defects in version "v2.0.5." If a vehicle running version "v2.0.3" is incorrectly registered to a test batch requiring version "v2.1.0" or higher, its test results will be meaningless and may even lead to system crashes or misleading data due to interface incompatibility.

[0064] This application pre-defines the minimum firmware version requirement for each test batch in the backend system and automatically extracts and compares the ECU firmware version number reported by the vehicle during registration. If the vehicle version is lower than the requirement, the system immediately determines it to be non-compliant, refuses registration, and returns a clear error message. This mechanism not only ensures the accuracy and consistency of test results but also avoids wasting test resources. Furthermore, this verification logic can be extended to multiple ECUs (such as powertrain domain, chassis domain, and intelligent driving domain), enabling more refined version control and demonstrating the system's adaptability to complex R&D scenarios.

[0065] (2) Verify the test mode status code. If the test mode status code is R&D debugging mode, the status verification is deemed to be successful. Otherwise, return the message "Non-R&D test vehicle, registration is prohibited".

[0066] The purpose of test mode status code verification is to confirm, from the perspective of the vehicle's physical state, whether it has the legitimate status of a research and development test vehicle, preventing mass-produced vehicles, sales vehicles, or vehicles that have exited testing from mistakenly or maliciously accessing the research and development environment. The test mode status code is a status identifier generated by the T-Box or central gateway when the vehicle is in engineering mode, indicating the vehicle's current operating mode (such as "Research and Development Debugging Mode," "Production Mode," "After-Sales Mode," "User Mode," etc.). Only vehicles in "Research and Development Debugging Mode" have permission to access debugging interfaces such as remote diagnostics, data reporting, and firmware updates, making them suitable for research and development testing.

[0067] This application verifies the status code to ensure that only prototype vehicles genuinely used for R&D purposes can complete registration. If the system detects a vehicle's status code as "production mode" or "user mode," it immediately determines it as an illegal request, rejects registration, and returns a "Non-R&D test vehicle, registration prohibited" message. This mechanism builds a robust security boundary, effectively preventing non-test vehicles from occupying R&D resources, interfering with test data, or even using debugging interfaces for security attacks. Simultaneously, it complies with the company's management standards for R&D assets, ensuring that the vehicle's usage status strictly matches the business scenario, thus improving system security and compliance. This verification, together with ECU version verification, constitutes a dual "status + configuration" legitimacy verification system, a key technical means to ensure the safe, controllable, and efficient operation of the R&D testing environment.

[0068] In some embodiments of this application, the testing phase identifier is associated with tags for various R&D scenarios and linked to the year field in the test batch number. These R&D scenario tags include, but are not limited to: prototype verification phase, cold-region endurance testing phase, software integration testing phase, or final acceptance phase.

[0069] Specifically, a structured data model deeply binds vehicle registration information to the complex R&D lifecycle, enabling traceability, analyzability, and automated management of test data. In automotive R&D, testing is not a singular activity but rather permeates multiple key stages from concept design to pre-mass production, each with its specific objectives, environmental requirements, and evaluation criteria. By introducing a "Test Phase Identifier" field and associating it with the year field (e.g., "2025") in the "Test Batch Number," the system can automatically identify the time period and R&D stage to which the batch belongs, thus assigning a clear "time-stage" coordinate to the registered vehicle. For example, a test batch named "2025-Winter" can have its year field "2025" automatically associated with the "Cold Region Durability Test Phase" label, allowing the system to preload test cases, environmental monitoring indicators, and data collection strategies specific to that phase. This association mechanism not only simplifies user operations (eliminating the need to manually input complex stage descriptions), but also ensures that test tasks from different years and cycles can be accurately distinguished and managed by the system, avoiding management misalignments caused by batch naming confusion or human misunderstanding, and providing a unified data framework for cross-year, multi-cycle R&D projects.

[0070] Furthermore, the testing phase is transformed into specific and actionable R&D scenarios, enabling the registration platform to execute differentiated processing logic based on the characteristics of different scenarios. For example, when the "Testing Phase Identifier" is associated with the "Prototype Verification Phase" tag, the system can automatically relax the verification standards for some hardware configurations (such as allowing the use of non-mass-production T-Boxes) and associate test cases focusing on functional usability; when associated with the "Cold Region Durability Testing Phase," the system can automatically activate the data acquisition template under low-temperature conditions, associate test indicators related to temperature and battery performance, and assign specific monitoring dashboards to the vehicle; when associated with the "Software Integration Phase," the system can force the ECU firmware version to meet specific communication protocol versions and associate integration test cases; and when associated with the "Final Acceptance Phase," the system executes the strictest verification standards to ensure that the vehicle configuration fully meets mass production requirements and generates a formal acceptance report for auditing.

[0071] In some embodiments of this application, the registration record includes a test batch association field to associate the test batch number, establishing a structured and traceable association between vehicle registration behavior and specific R&D projects, and realizing contextualized and project-based management of registration data.

[0072] In traditional registration models, registration records often only contain basic vehicle information and timestamps, lacking deep integration with the R&D process. This makes subsequent statistical analysis and auditing by project or batch difficult. By explicitly introducing a "test batch association field" into the "registration record," the system can clearly attribute each registration operation to a specific test batch (e.g., "ADAS_V2.3_Beta_2025Q2"). This field is not only a foreign key in the database but also a crucial link connecting vehicles, personnel, time, and tasks. It allows managers to quickly calculate key indicators such as the total number of registered vehicles, registration time distribution, and personnel distribution within a specific test batch through simple queries, providing data support for project progress management. Furthermore, when vehicle issues arise, this field can quickly locate the test batch to which it belongs, allowing for the tracing of the batch's test objectives, responsible personnel, and environmental configurations, significantly improving the efficiency of problem investigation and accountability. In addition, this design supports cross-system data integration, such as synchronizing registration data with project management tools (e.g., Jira) or test management platforms, achieving data continuity throughout the entire R&D process and forming a crucial foundation for building a digital R&D system.

[0073] In some embodiments of this application, the vehicle information table includes a test case association column, which records at least one test case number. The test case number is automatically obtained from a preset test case library by matching the test batch number.

[0074] Specifically, in R&D testing, each vehicle needs to execute a series of pre-set test cases after registration to verify its functionality, performance, and stability. In the traditional model, test case allocation relies on manual scheduling or later manual association, which is inefficient and prone to omissions. This application automates the distribution of test tasks by setting a "Test Case Association Column" in the "Vehicle Information Table" and automatically matching and filling in relevant test case numbers from the "Pre-set Test Case Library" in the background based on the vehicle's "Test Batch Number" after successful registration.

[0075] For example, a vehicle belonging to the "Intelligent Parking Function Verification Batch" will automatically have test case numbers such as "TC-PARK-001" (perpendicular parking) and "TC-PARK-002" (parallel parking) associated with its information table after registration. This mechanism has multiple benefits: First, it ensures test completeness, avoiding omissions of test items due to human error; second, it improves testing efficiency, allowing test engineers to directly work based on the associated test cases in the information table without needing to consult the task list; third, it supports automated execution, as this association can be read by the automated testing platform, triggering the automatic execution of corresponding test scripts; and finally, it facilitates result traceability, as all test results can be back-linked to specific vehicles and registration batches through the test case number, forming a complete chain of test evidence. Therefore, this design not only optimizes the data structure but also establishes a closed-loop test process of "registration-assignment-execution-feedback," significantly improving the automation and intelligence level of R&D testing.

[0076] In some embodiments of this application, the service layer and data layer of the vehicle cloud backend system interact with each other through a caching layer and a message queue. This architecture design is a key technical support for the system to achieve high performance, high availability and a good user experience, and embodies the best practices of modern distributed system design.

[0077] First, the caching layer uses key-value pairs to store frequently queried vehicle registration information, with a cache expiration time set to 24 hours. Its core function is to significantly improve the system's response speed and data query performance, while reducing the access pressure on the database. During peak R&D testing periods, a large number of test engineers may frequently query the vehicle registration status, vehicle information table, or test case associations within the same test batch. If each query directly accesses the underlying database (such as a MySQL cluster), it will not only increase the database I / O load and cause response delays, but may also lead to database performance bottlenecks or even service degradation due to high concurrency access. By introducing a caching layer (such as Redis), the system stores frequently accessed vehicle registration information (such as registration records, basic vehicle information, test batch status, etc.) in memory in the form of key-value pairs.

[0078] When a user initiates a query request, the service layer prioritizes reading data from the cache. Since memory access speed is far superior to disk access, response time can be reduced from hundreds of milliseconds to milliseconds or even microseconds, improving the user experience. Setting the cache expiration time to 24 hours is a reasonable strategy that balances data real-time performance and system performance: on the one hand, registration information for R&D testing typically remains stable in the short term (e.g., within a day), and a 24-hour expiration time is sufficient to cover most query scenarios; on the other hand, excessively long cache times may lead to data staleness (e.g., vehicle status changes not being updated in a timely manner), while the 24-hour expiration mechanism ensures that cached data is refreshed within a reasonable period, guaranteeing relative data consistency. Furthermore, the cache layer supports high-availability deployment (e.g., master-slave replication, cluster mode), ensuring that the system can continue to provide services even if some nodes fail, enhancing the overall architecture's fault tolerance.

[0079] Secondly, message queues are used to asynchronously process notification push tasks after successful registration, including sending registration completion messages to user terminals and generating vehicle information table links. Their fundamental significance lies in decoupling system components, smoothing out peak and valley loads, and ensuring the reliable execution of critical tasks. In the vehicle registration process, core registration information verification and storage must be completed quickly to ensure efficient response of the main process. However, post-registration notification pushes (such as DingTalk messages, emails, and SMS) and the generation of vehicle information table links often involve external system calls or time-consuming file generation tasks. If these are executed synchronously in the main registration process, it will significantly extend user waiting time and affect the registration experience. By introducing message queues (such as Kafka and RocketMQ), the system encapsulates these non-core, time-consuming tasks as "messages" and places them in the queue, which are then asynchronously consumed and executed by an independent background "task processing service."

[0080] This asynchronous processing model offers several advantages: First, it decouples the system. The service layer doesn't need to worry about how notifications are sent or how links are generated; it only needs to publish the messages to the queue, reducing dependencies between system modules. Second, it smooths out peak traffic. During peak registration periods, a large number of notification tasks are buffered in the queue, allowing the background service to consume them gradually according to its processing capacity, preventing sudden high concurrency from causing external services (such as SMS gateways) to crash. Third, it ensures reliability. Message queues typically have persistence and retry mechanisms, so even if the task processing service experiences a temporary failure, messages will not be lost and can be reprocessed after the service recovers, ensuring that every notification is ultimately delivered to the user. For example, when a user completes registration, the system immediately returns a "Registration successful" message and simultaneously places the tasks of "sending DingTalk notification" and "generating PDF information form link" into the message queue. The background service completes these operations later and pushes them to the user, achieving the ideal user experience of "fast response, background processing."

[0081] Therefore, the introduction of a caching layer and message queue not only solves the performance bottlenecks and response latency issues in high-concurrency scenarios, but also improves the system's stability, scalability, and reliability through asynchronous and decoupled design. These two technologies, working in conjunction with components such as the low-code frontend, vehicle cloud backend, and database cluster, jointly construct an efficient, intelligent, and scalable vehicle registration platform, fully demonstrating the advanced nature and practicality of this application's system architecture design.

[0082] In summary, the vehicle registration method for the research and development testing phase provided in this application has the following technical effects.

[0083] This method achieves end-to-end automation and intelligence in the vehicle registration process by constructing a deeply integrated architecture between a low-code platform frontend and a vehicle-cloud backend system. It abandons the inefficient traditional model that relies on manual reading, filling, and input, automatically collecting test status codes and hardware information using pre-set interfaces based on vehicle engineering models. Combined with office software organizational structures for user permission verification, it ensures the accuracy of data sources and the legitimacy of the operating entities. Through multi-layered information verification mechanisms, including field completeness, format correctness, and legality judgment based on firmware version and debug mode status of the test batch, it effectively prevents erroneous or non-compliant vehicles from accessing the system, ensuring the security and stability of the development environment. Simultaneously, the system can automatically associate the corresponding test case number with the test batch number, achieving intelligent linkage of registration and task assignment, significantly improving the collaborative efficiency and management standardization of R&D testing.

[0084] Furthermore, this application optimizes the overall system architecture and user experience by introducing high-performance middleware technologies such as a caching layer and message queues. The caching layer uses key-value storage for frequently queried registration information, significantly improving data retrieval speed and reducing database load. The message queue asynchronously processes time-consuming operations such as notification pushes and file generation, ensuring both rapid response of the main registration process and reliable task execution. The structured encapsulation and centralized storage of registration results enable data traceability and auditability, providing a solid foundation for subsequent data analysis and project management. The entire solution not only significantly improves registration efficiency and reduces labor costs and operational error risks, but also enhances the system's adaptability to complex R&D processes through scenario-based tag management and automated task association, providing an efficient, secure, and intelligent technical support system for the R&D and testing of intelligent connected vehicles.

[0085] Secondly, refer to Figure 2 This application provides a vehicle registration system for the research and development testing phase, including: The front-end module 310 is used in the vehicle cloud back-end system to receive vehicle registration information submitted by users through the vehicle registration front-end. The vehicle registration information includes at least the test mode status code, test batch number, test stage identifier, and vehicle hardware information. The test mode status code and vehicle hardware information are automatically read through the vehicle engineering mode preset interface.

[0086] The verification module 320 is used to verify the vehicle registration information and check whether the vehicle is in the R&D engineering mode. After the verification is passed, the registration result information is generated, including the corresponding registration record, vehicle information table and associated test case number.

[0087] The encapsulation and storage module 330 is used to encapsulate the registration result information and vehicle registration information into structured data in the service layer of the vehicle cloud backend system, and send it to the data layer of the vehicle cloud backend system for storage.

[0088] The message push module 340 is used to receive registration result information returned by the vehicle cloud backend system at the vehicle registration front end and push it to the user terminal.

[0089] Furthermore, embodiments of this application provide an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the aforementioned vehicle registration method during the research and development testing phase.

[0090] Furthermore, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the aforementioned vehicle registration method during the research and development testing phase.

[0091] Similarly, the technical effects of the above system embodiments, program product embodiments, and electronic device embodiments are consistent with the technical effects of the above method embodiments.

[0092] It should be noted that in all specific embodiments of this application, all data processing activities related to user identity or personal characteristics, such as user information, user behavior data, historical data, and location information, will be conducted in accordance with the principles of legality, legitimacy, and necessity. All data collection, use, storage, and processing will be subject to compliance with applicable national and regional laws, regulations, and industry standards, and informed consent from users will be obtained in a clear and explicit manner before processing. For the processing of sensitive personal information, separate consent from users will be obtained through prominent means such as pop-up prompts and independent confirmation pages. If any processing conflicts with laws and regulations, the laws and regulations will prevail, and necessary data processing will only be carried out within the scope permitted by laws and regulations, ensuring that all data-based applications, analyses, and technical implementations are conducted within the scope permitted by laws and regulations.

[0093] In some alternative embodiments, the functions / operations mentioned in the block diagrams may not occur in the order shown in the operation diagrams. For example, depending on the functions / operations involved, two consecutively shown blocks may actually be executed substantially simultaneously, or the blocks may sometimes be executed in reverse order. Furthermore, the embodiments presented and described in the flowcharts of this application are provided by way of example to provide a more comprehensive understanding of the technology. The disclosed methods are not limited to the operations and logic flows presented herein. Alternative embodiments are contemplated in which the order of various operations is changed and sub-operations described as part of a larger operation are executed independently.

[0094] Furthermore, although this application is described in the context of functional modules, it should be understood that, unless otherwise stated, one or more of the functions and / or features may be integrated into a single physical device and / or software module, or one or more functions and / or features may be implemented in a separate physical device or software module. It is also understood that a detailed discussion of the actual implementation of each module is unnecessary for understanding this application. Rather, given the properties, functions, and internal relationships of the various functional modules in the apparatus disclosed herein, the actual implementation of the module will be understood within the scope of ordinary skill of an engineer. Therefore, those skilled in the art can implement the application set forth in the claims using ordinary skill. It is also understood that the specific concepts disclosed are merely illustrative and are not intended to limit the scope of this application, which is determined by the full scope of the appended claims and their equivalents.

[0095] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several programs to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0096] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequential list of executable programs for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, a program execution system, apparatus, or device (such as a computer-based system, a processor-included system, or other system that can retrieve and execute a program from or in conjunction with such a program execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can mean any means that can contain, store, communicate, propagate, or transmit a program for use by or in conjunction with a program execution system, apparatus, or device.

[0097] More specific examples (a non-exhaustive list) of computer-readable media include: electrical connections (electronic devices) having one or more wires, portable computer disk drives (magnetic devices), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). Additionally, computer-readable media can even be paper or other suitable media on which programs can be printed, for example, by optically scanning the paper or other media, then editing, interpreting, or, if necessary, processing it in a suitable manner to obtain the program electronically, and then storing it in computer memory.

[0098] It should be understood that various parts of the present invention can be implemented in hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented in software or firmware stored in memory and executed by a suitable program execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0099] In the foregoing description of this specification, the reference to terms such as "one embodiment / implementation," "another embodiment / implementation," or "certain embodiments / implementations," etc., indicates that a specific feature, structure, material, or characteristic described in connection with an embodiment or example is included in an embodiment or example of the present invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0100] Although embodiments of the invention have been shown and described, those skilled in the art will understand that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the claims and their equivalents.

[0101] The above is a detailed description of the preferred embodiments of the present invention. However, the present invention is not limited to the embodiments. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of the present invention. All such equivalent modifications or substitutions are included within the scope defined by the claims of the present invention.

Claims

1. A vehicle registration method during the research and development testing phase, characterized in that, The method is applied to the integration environment between the vehicle registration front-end and the vehicle cloud back-end system built on a low-code platform, and includes the following steps: The vehicle cloud backend system receives vehicle registration information submitted by users through the vehicle registration frontend. The vehicle registration information includes at least a test mode status code, a test batch number, a test stage identifier, and vehicle hardware information. The test mode status code and the vehicle hardware information are automatically read through a vehicle engineering mode preset interface. The vehicle registration information is verified to determine whether the vehicle is in the engineering mode of R&D testing. After the verification is passed, registration result information is generated, including the corresponding registration record, vehicle information table and associated test case number. In the service layer of the vehicle cloud backend system, the registration result information and the vehicle registration information are encapsulated into structured data and sent to the data layer of the vehicle cloud backend system for storage. The vehicle registration front end receives the registration result information returned by the vehicle cloud backend system and pushes it to the user terminal.

2. The vehicle registration method during the research and development testing phase according to claim 1, characterized in that, Before receiving the vehicle registration information submitted by the user through the vehicle registration front-end, the method further includes: The system verifies whether a user account belongs to the R&D testing project team through the organizational structure interface between the vehicle registration front-end and the office software. The office software is deeply integrated with the low-code platform and supports obtaining the user's testing project permissions and permission validity period through the organizational structure level. If the user's permission validity period is within the current testing phase, the user is allowed to submit registration information; otherwise, the submission is rejected and a "No R&D testing permissions" message is returned.

3. The vehicle registration method during the research and development testing phase according to claim 2, characterized in that, The vehicle cloud backend system receives vehicle registration information submitted by the user through the vehicle registration frontend, including: Users can select the test batch number and test phase identifier associated with their R&D test project group; The vehicle cloud backend system calls the vehicle engineering mode wireless debugging tool to automatically import the test mode status codes and vehicle hardware information in engineering mode.

4. The vehicle registration method during the research and development testing phase according to claim 1, characterized in that, The vehicle hardware information includes the ECU firmware version number; The verification of the vehicle registration information includes field integrity verification, format correctness verification, and information legality verification. The information validity verification includes: Verify whether the ECU firmware version number matches the minimum firmware version requirement corresponding to the test batch number. If they match, the verification is considered successful. If they do not match, return the message "Version of R&D test vehicle is incompatible, registration is prohibited". The test mode status code is verified. If the test mode status code is R&D debugging mode, the status verification is deemed to have passed; otherwise, the message "Non-R&D test vehicle, registration prohibited" is returned.

5. The vehicle registration method during the research and development testing phase according to claim 1, characterized in that, The test phase identifier is associated with tags for various R&D scenarios and is linked to the year field in the test batch number.

6. The vehicle registration method during the research and development testing phase according to claim 1, characterized in that, The registration record includes a test batch association field, which is used to associate the test batch number; the vehicle information table includes a test case association column, which records at least one test case number, which is automatically obtained by matching the test batch number from a preset test case library.

7. The vehicle registration method during the research and development testing phase according to claim 1, characterized in that, The service layer and data layer of the vehicle cloud backend system interact with each other through a caching layer and a message queue, wherein: The cache layer uses key-value pairs to store frequently queried vehicle registration information, and the cache validity period is set to 24 hours. The message queue is used to asynchronously process notification push tasks after successful registration, including sending a registration completion message and a link to generate a vehicle information table to the user terminal.

8. A vehicle registration system in the research and development testing phase, characterized in that, include: The front-end module is used to receive vehicle registration information submitted by users through the vehicle registration front-end in the vehicle cloud back-end system. The vehicle registration information includes at least a test mode status code, a test batch number, a test stage identifier, and vehicle hardware information. The test mode status code and the vehicle hardware information are automatically read through a preset interface of the vehicle engineering mode. The verification module is used to verify the vehicle registration information, check whether the vehicle is in the R&D engineering mode, and generate registration result information after the verification is passed, including the corresponding registration record, vehicle information table and associated test case number. An encapsulation and storage module is used to encapsulate the registration result information and the vehicle registration information into structured data at the service layer of the vehicle cloud backend system and send it to the data layer of the vehicle cloud backend system for storage. The message push module is used to receive the registration result information returned by the vehicle cloud backend system at the vehicle registration frontend and push it to the user terminal.

9. An electronic device, characterized in that, The electronic device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the vehicle registration method in the research and development testing phase as described in any one of claims 1 to 7.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the vehicle registration method in the research and development testing phase as described in any one of claims 1 to 7.

Images