Information retrieval methods, systems, and related equipment based on vehicle characteristics

Abstract

This application discloses a method, system, and related equipment for information querying based on vehicle characteristics, relating to the field of automotive repair technology. The method includes: establishing and maintaining a local binding database to store binding records of VIN codes and vehicle model identifiers; receiving query requests containing either a VIN code or a vehicle model identifier; if the request contains a VIN code, first querying the local binding database to obtain the vehicle model identifier; if not found, calling a third-party API interface service and binding the VIN code and vehicle model identifier; if the request only contains the vehicle model identifier, ending the repair process. This application, by establishing and continuously updating a binding database, reduces dependence on and costs associated with external third-party APIs, improves system stability and response speed, achieves autonomous accumulation and management of core data assets, and supports repair queries in scenarios without VIN codes, expanding the application boundaries of the solution.

Description

Technical Field

[0001] This application relates to the field of automotive repair technology, and in particular to information query methods, systems and related equipment based on vehicle characteristics. Background Technology

[0002] In automotive repair systems, the Vehicle Identification Number (VIN) is typically used to uniquely identify a vehicle's model, year, configuration, and other information. This information is then combined with fault codes for accurate fault diagnosis, repair plan recommendations, and parts lookup. The current mainstream technical solution involves using a third-party VIN parsing API service to parse the VIN into corresponding vehicle characteristic information (or model identifier), such as brand, model, and year. Subsequent repair logic is then executed based on this information.

[0003] However, the current solution relies on external third-party services, and frequent calls to third-party API services generate ongoing costs, increasing operational expenses. Furthermore, the parsing process is limited by the network conditions, service availability, and performance of the third-party services. If the third-party service experiences anomalies or network fluctuations, it will directly cause interruptions or delays in the core business processes of this system, impacting user experience. Moreover, when the VIN code cannot be obtained or is inconvenient to obtain (e.g., the user only knows the vehicle model but not the VIN code, or the VIN code is damaged), the existing system lacks an effective alternative query path, causing business operations to be unable to proceed.

[0004] To address the aforementioned issues, it is necessary to design a vehicle repair information query solution that can reduce reliance on third parties, enhance system autonomy, and support more flexible query methods. Summary of the Invention

[0005] This application provides a method, system, and related equipment for information querying based on vehicle characteristics, relating to the field of automotive repair technology. This method establishes and manages a local database binding VIN codes and vehicle model characteristics, and based on a query mechanism of this database, achieves stable and efficient operation of the repair system in various scenarios while reducing dependence on external parsing services and associated costs. The specific technical solution is as follows: Firstly, a method for querying information based on vehicle characteristics is provided, comprising the following steps: obtaining a first vehicle model identifier based on an external interface; when the first vehicle identification number (VIN) is obtained by calling a third-party VIN parsing service, storing the binding record of the first VIN and the first vehicle model identifier in a local binding database; obtaining a vehicle repair query request, wherein the query request includes at least one of a second VIN and a second vehicle model identifier; if the query request includes the second VIN, querying the binding database to obtain a third vehicle model identifier bound to the second VIN, and performing repair processing based on the result of obtaining the third vehicle model identifier; if the query request does not include the second VIN but includes the second vehicle model identifier, querying the binding database to obtain a third VIN bound to the second vehicle model identifier, and performing repair processing based on the result of obtaining the third VIN.

[0006] In conjunction with the first aspect, the repair processing based on the acquisition result of the third vehicle model identifier specifically includes: if the binding database finds the third vehicle model identifier, then the repair processing is performed based on the second VIN and the third vehicle model identifier; if the binding database does not find the third vehicle model identifier, then a third-party VIN parsing service is called to obtain the third vehicle model identifier, and then the repair processing is performed based on the second VIN and the third vehicle model identifier.

[0007] In conjunction with the first aspect, the maintenance process based on the acquisition result of the third VIN specifically includes: if the binding database retrieves the third VIN, then the maintenance process is performed based on the third VIN and the second vehicle model identifier; otherwise, the maintenance process is terminated.

[0008] In conjunction with the first aspect, in some embodiments of the first aspect, after the third-party VIN resolution service is invoked to obtain the third vehicle model identifier, the method further includes: establishing a binding record between the second VIN and the third vehicle model identifier, and updating the binding database.

[0009] In conjunction with the first aspect, the binding database unbinds and rebinds the binding record, storing multiple different vehicle identification numbers bound to a single VIN code in the binding record.

[0010] In conjunction with the first aspect, in some implementations of the first aspect, querying the binding database to obtain the third vehicle model identifier bound to the second VIN specifically includes: when the binding database finds multiple sets of vehicle model identifiers bound to the second VIN, returning the multiple sets of vehicle model identifiers to the requester, and confirming whether the multiple sets of vehicle model identifiers include the third vehicle model identifier.

[0011] In conjunction with the first aspect, the external interface includes at least one of the following: external system interface, web interface, and application (APP) interface.

[0012] It should be noted that, in the absence of conflict, the features in the various embodiments of the first aspect can be combined with each other, and any combination of features in different embodiments is also within the protection scope of this application. That is to say, the various embodiments described above can also be arbitrarily combined according to actual needs.

[0013] Secondly, a vehicle feature-based information query system is provided to implement the method described in any of the first aspects, including: The binding record management module is used to maintain the binding database, which stores the binding records of the first VIN and the first vehicle model identifier, and supports the creation, deletion, modification and query of the binding records; The request receiving module is used to obtain a vehicle maintenance query request, which includes at least one of a second VIN and a second vehicle model identifier; The vehicle identification query module is used to obtain the bound third vehicle identification when the second VIN code is known, and to perform maintenance processing based on the obtained results; The VIN code query module is used to obtain the bound third VIN code when the second vehicle identification is known, and to perform maintenance processing based on the obtained result; The maintenance service module is used to perform corresponding maintenance diagnosis or solution matching logic on the obtained VIN code and vehicle model identifier.

[0014] Thirdly, a computer device is provided, including one or more memories and one or more processors; the memory is coupled to the one or more processors, the memory is used to store computer program code, the computer program code including computer instructions, and the one or more processors call the computer instructions to cause the computer device to implement the method as described in the first aspect or any of the embodiments of the first aspect.

[0015] Fourthly, a computer-readable storage medium is provided that stores computer instructions thereon, which, when executed by a processor, implement the method as described in the first aspect or any of the embodiments in the first aspect.

[0016] In the embodiments of this application, the method provided by this application has the following beneficial effects: 1. Reduced costs and improved stability. By prioritizing queries to the locally bound database, the number of calls to external paid APIs is significantly reduced, directly saving costs. At the same time, it reduces the risk of business interruption due to the unavailability of external services, improving the overall stability and responsiveness of the system.

[0017] 2. Achieve data asset autonomy. Store the mapping relationship between VIN codes and vehicle identification numbers as core data assets in the enterprise's internal database, supporting the management of one-to-many binding records for VIN codes, making the data model more aligned with actual business needs.

[0018] 3. Enhance system intelligence and self-learning capabilities. By recording the VIN code and the associated vehicle identification in the binding database, the system can continuously learn and accumulate new knowledge during use.

[0019] 4. Expand business application scenarios. A query path based solely on vehicle model identification, without a VIN code, is provided, resolving the issue of service unavailability due to missing or difficult-to-obtain VIN codes, thus broadening the system's application boundaries and improving user experience. Attached Figure Description

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

[0021] Figure 1 This is a system framework diagram of an information query method based on vehicle features provided in an embodiment of this application; Figure 2 This is a schematic diagram of an information query system module based on vehicle characteristics provided in an embodiment of this application; Figure 3 This is a schematic diagram of the overall process of an information query method based on vehicle features provided in an embodiment of this application; Figure 4 This is a detailed processing flowchart illustrating a query request containing a VIN code, provided in an embodiment of this application. Figure 5 This is a detailed processing flowchart illustrating a query request that contains only vehicle model identifiers, provided in an embodiment of this application. Figure 6 This is a schematic diagram of the hardware structure of a computer device provided in an embodiment of this application; Figure 7 This is a schematic diagram of a computer-readable storage medium provided in an embodiment of this application. Detailed Implementation

[0022] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0023] It should be understood that "multiple" as mentioned in this application refers to two or more. In the description of this application, unless otherwise stated, " / " indicates "or," for example, A / B can mean A or B; "and / or" in this document is merely a description of the relationship between related objects, indicating that three relationships can exist, for example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Furthermore, to facilitate a clear description of the technical solutions of this application, the terms "first," "second," etc., are used to distinguish identical or similar items with essentially the same function and effect. Those skilled in the art will understand that the terms "first," "second," etc., do not limit the quantity or execution order, and that "first," "second," etc., do not necessarily imply differences.

[0024] The terms "one embodiment" or "some embodiments" used in this application mean that one or more embodiments of this application include the specific features, structures, or characteristics described in that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this application do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. Furthermore, the terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0025] The following describes the vehicle feature-based information query method, system, and related equipment provided in this application through three embodiments. Embodiment 1 describes the system framework of the vehicle feature-based information query method, Embodiment 2 describes the method flow for implementing the vehicle feature-based information query, and Embodiment 3 describes the module structure, computer equipment hardware structure, and computer-readable storage medium for executing the vehicle feature-based information query method.

[0026] Example 1 Figure 1 This is a system framework diagram of an information query method based on vehicle features provided in an embodiment of this application. For example... Figure 1 As shown, the system framework 100 mainly includes: a user terminal 110, a maintenance server 120, and a third-party vehicle identification number (VIN) parsing service interface 130. The maintenance server 120 is internally configured with a binding database 121.

[0027] In some implementations, user terminal 110 may be a diagnostic computer, mobile terminal (such as a mobile phone or tablet computer) used by a repair technician, or a dedicated on-board diagnostic device. User terminal 110 is configured to send a query request to repair server 120, the query request containing at least one of the following: VIN code and vehicle characteristic information (such as brand, model, and year).

[0028] The maintenance server 120, as the core processing unit of the system framework 100, establishes a communication connection between the user terminal 110 and the binding database 121, and optionally has access to the parsing service interface 130. The binding database 121 is used to store and maintain the mapping relationship data between vehicle characteristic information and VINs. In some examples, this mapping relationship can be a one-to-many relationship, meaning that one VIN code may be associated with a combination of multiple brands, models, or year information.

[0029] In a specific example, when a query request sent by user terminal 110 contains a VIN code, maintenance server 120 is configured to: first, query the binding database 121 and the cache of maintenance server 120 to attempt to directly obtain the vehicle characteristic information bound to the VIN code. If a corresponding binding record is found in binding database 121, maintenance server 120 executes subsequent maintenance and diagnostic logic based on the retrieved vehicle characteristic information. If the query fails, maintenance server 120 calls the parsing service interface 130 to parse the VIN code, and after obtaining the parsing result, stores the binding record between the VIN code and the parsed vehicle characteristic information in binding database 121 for subsequent queries.

[0030] In another specific example, when the query request sent by user terminal 110 directly contains vehicle characteristic information (such as brand, model, and year), the maintenance server 120 is configured to query the binding database 121 and the cache of maintenance server 120 to find one or more associated VIN codes based on the vehicle characteristic information, and then perform subsequent maintenance and diagnostic logic based on the found VIN codes. In this case, the system may not need to call the parsing service interface 130.

[0031] In this embodiment of the application, the binding record between the VIN code and the vehicle model identifier in the binding database 121 can be dynamically adjusted, specifically including one or more of the following methods: In this embodiment, the binding database 121 can dynamically update binding records, for example, by managing the validity of binding records based on status flags. For instance, when the binding database 121 detects an error in a binding record, it can mark it as invalid, thereby unbinding the VIN code and vehicle model information from that record. The binding database 121 can also create new binding records for the unbound VIN code and / or vehicle model information after acquiring new binding records. Thus, by dynamically updating the binding records, it can be ensured that the binding database 121 can both promptly correct binding errors and completely retain the historical data of the binding records.

[0032] In some implementations, for scenarios where one VIN code corresponds to multiple vehicle model information, the binding database 121 can dynamically process binding records. For example, for a first VIN code with a binding record for first vehicle model information, when the binding database 121 determines that the first VIN code can also be bound to second vehicle model information, it can add the second vehicle model information to the association list of the first VIN code. When a user queries the first VIN code, the binding database 121 can return the corresponding first and second vehicle model information from the first VIN code to provide the user with a choice. For example, the binding database 121 can also dynamically predict and recommend the most likely vehicle model information based on the binding time, the reliability of the vehicle model information data source, and the current specific repair problem; this embodiment does not limit this.

[0033] In this embodiment, to ensure efficient querying of the binding database 121, stability of the maintenance server 120, and the ability to handle high-concurrency scenarios, a multi-level data storage and access strategy is adopted, specifically through the collaborative operation of the cache and the database. When the maintenance server 120 accesses the local binding database 121, it does not directly query the database but prioritizes accessing the faster cache. When it receives a query request containing a VIN code, it first checks the cache for the corresponding vehicle feature information. If the cache is not found (e.g., the cache expires or the query does not find the corresponding vehicle feature information), it then queries the local binding database 121. After successfully retrieving the binding record from the binding database 121, the maintenance server 120 can return the query result to the business process and can also synchronously write the query result to the cache, setting a cache expiration time. In this way, subsequent repeated queries for the same VIN code will be directly retrieved from the cache, effectively reducing the access pressure on the database.

[0034] This data storage method, incorporating both caching and database functionality, allows the cache in maintenance server 120 to absorb a large number of instantaneous read requests, preventing high-concurrency traffic from directly impacting the database and avoiding database connection exhaustion or overload, thereby improving the overall system robustness. In high-concurrency scenarios, the cache can offload the query load, enabling maintenance server 120 to handle a large number of concurrent query requests simultaneously with low latency. Furthermore, even if the cache service experiences a brief failure, maintenance server 120 can still degrade to directly querying the bound database 121, ensuring uninterrupted core services.

[0035] Through the aforementioned system framework, the binding database 121 based on the maintenance server 120 records the mapping relationship between vehicle characteristic information and VIN codes, which helps reduce the frequency of calls to the third-party parsing service interface 130, thereby reducing service costs. Simultaneously, prioritizing local data for queries helps avoid third-party interface call failures due to network issues, thus improving the stability and response efficiency of information queries. Furthermore, storing core mapping relationship data in the company's internal database facilitates stronger management and control of data assets.

[0036] It is understood that the functional division between the modules illustrated in the embodiments of this application is merely illustrative and does not constitute a functional limitation on the system framework 100. In other embodiments of this application, the system framework 100 may also employ different modules or combinations of multiple modules to implement the functions in the system framework 100.

[0037] Figure 2 This is a schematic diagram of a vehicle feature-based information query system module provided in an embodiment of this application. Figure 2 As shown, the vehicle feature-based information query system 200 specifically includes the following modules: The binding record management module 210 is used to maintain the binding database, which stores binding records between the first VIN and the first vehicle model identifier. It supports the creation, deletion, modification, and querying of binding records. Specifically, the binding record management module 210 can implement the following functions: allow one VIN code to be associated with multiple vehicle model identifiers, and implement logical unbinding and rebinding through status flags; provide data persistence and cache synchronization mechanisms, automatically updating the high-speed cache when the binding relationship changes to ensure query consistency; and provide an asynchronous task consumption interface to handle binding relationship establishment requests from other modules, achieving non-blocking data write-back.

[0038] The request receiving module 220 is used to obtain vehicle repair query requests, which contain at least one of a second VIN and a second vehicle model identifier. Specifically, the request receiving module 220 performs the following functions: parses and verifies the request to ensure it contains at least one valid parameter, either a second VIN or a second vehicle model identifier; performs routing judgment based on the parameters, directing requests containing a VIN to the vehicle model identifier query module 230, and directing requests containing only a vehicle model identifier to the VIN query module 240; and encapsulates and converts the request and response to adapt to the data formats of upstream and downstream modules.

[0039] The vehicle model identifier query module 230 is used to obtain the bound third vehicle model identifier when the second VIN code is known, and to perform maintenance processing based on the obtained result. Specifically, the vehicle model identifier query module 230 implements the following functions: First, it calls the query interface of the binding record management module 210 to obtain the bound third vehicle model identifier from the binding database; if the local query is empty, it calls the third-party VIN parsing API through the integrated external service adapter; when the call is successful, it automatically generates a binding record creation task and asynchronously submits it to the binding record management module 210 for updating; when the local query returns multiple vehicle model identifiers, it coordinates with the request receiving module 220 to guide the user to select and confirm.

[0040] The VIN code query module 240 is used to obtain the bound third VIN code when the second vehicle model identifier is known, and to perform maintenance processing based on the obtained result. Specifically, the VIN code query module 240 implements the following functions: calling the binding record management module 210 to query a list of all associated third VIN codes based on the second vehicle model identifier; and providing the queried list of associated VIN codes to other systems for data correlation analysis.

[0041] The maintenance service module 250 is used to perform corresponding maintenance diagnosis or solution matching logic on the acquired VIN code and vehicle model identifier.

[0042] In this embodiment of the application, the binding records of VIN codes and vehicle identification stored in the binding database include not only one-to-one correspondences, but also one-to-many or many-to-one relationships.

[0043] For example, in a scenario where a VIN code corresponds to multiple vehicle model identifiers, a first VIN code (e.g., "LSVHJ133022217501") can be bound to a first vehicle model identifier (e.g., brand: Volkswagen, model: Magotan, year: 2022, etc.) in a vehicle feature-based information query system 200. Simultaneously, due to vehicle model updates, regional configuration differences, etc., this first VIN code may also be bound to a second vehicle model identifier (e.g., brand: Volkswagen, model: Magotan, year: 2023, etc.).

[0044] For example, in a scenario where multiple VIN codes correspond to a single vehicle model identifier, different VIN codes can point to the same vehicle configuration. The second VIN code (e.g., "LSVHJ133022217502") and the third VIN code (e.g., "LSVHJ133022217503") are vehicles produced in the same batch with identical configurations. Therefore, the second and third VIN codes may both be bound to the same third vehicle model identifier in the system (brand: Volkswagen, model: Magotan, year: 2022 Luxury model, etc.).

[0045] It is understood that the functional division between the modules illustrated in the embodiments of this application is merely illustrative and does not constitute a limitation on the functionality of the vehicle feature-based information query system 200. In other embodiments of this application, the vehicle feature-based information query system 200 may also employ different modules or combinations of multiple modules to implement the functionality of the vehicle feature-based information query system 200.

[0046] Example 2 This embodiment will combine information query methods based on vehicle characteristics to address issues such as... Figure 1 The collaborative working method of each module in the system framework 100 shown is described in detail.

[0047] Figure 3 This is a schematic diagram of the overall process of an information query method based on vehicle features provided in an embodiment of this application, which is applied to, for example... Figure 1 The system framework 100 shown and as follows Figure 2 The vehicle feature-based information query system 200 shown specifically includes: S101. Establish a binding database to store the binding records of VIN codes and vehicle model identifiers.

[0048] In this embodiment of the application, the maintenance server 120 has a binding database built inside to store the mapping relationship between VIN codes and vehicle characteristic information (such as brand, model, and year).

[0049] In this embodiment of the application, the method for establishing the binding database includes: obtaining the first vehicle model identifier based on an external interface; when the first vehicle identification code (i.e., the first VIN) calls a third-party VIN parsing service to obtain the first vehicle model identifier, storing the binding record of the first VIN and the first vehicle model identifier in a local binding database, and using the binding database as the data basis for implementing the query function in subsequent steps.

[0050] Specifically, external interfaces include at least one of the following: external system interfaces, web interfaces, and application (APP) interfaces. Once the system successfully parses the vehicle characteristic information corresponding to a VIN code (which can be referred to as the first VIN code) through an external interface (e.g., parsing the first vehicle brand, first model information, first year information, etc., which can be collectively considered as the first model identifier), the system can store the correspondence between the first VIN code and the first model identifier as a binding record in the local binding database. Simultaneously, as the system continues to run, more VIN code and model identifier binding records can be added to the binding database, gradually improving the database's storage content.

[0051] S102. Receive query request.

[0052] In this embodiment of the application, the query request originates from the user terminal, and its content may include at least one of VIN and vehicle identification (such as brand, model, year, etc.).

[0053] In this embodiment, during initial system operation or daily maintenance, a local binding database needs to be built and improved through various channels. The system can provide multiple external interfaces to receive vehicle identification data. For example, in the backend management interface, maintenance personnel can manually input or batch import known VIN codes and vehicle identification correspondences through the API interface of a webpage (WEB) or an application (APP); in the business system interface, it connects with other business systems of the company, automatically synchronizing existing vehicle file information through the external interfaces of these systems.

[0054] In this embodiment, the data in the bound database can also come from third-party parsing results: when a user queries an unknown VIN code for the first time through the system, and the system successfully parses it using a third-party API, it not only returns the result to the user but also asynchronously triggers a data write-back task. This task associates the parsed first vehicle model identifier with the first VIN code used in the query and stores it in the bound database. Through this mechanism, the system's local knowledge base is expanded every time a new VIN code is successfully parsed.

[0055] In this embodiment, a record in the binding database includes at least the following fields: VIN code, vehicle model identifier, binding time, and binding data source. The vehicle model identifier can be associated with vehicle characteristic information, which can be structured and stored in detail, such as brand, model series, vehicle type, year, and engine model. Crucially, the binding database design supports one VIN code corresponding to multiple vehicle model identifiers, and manages the validity of the binding by judging the status flag of the binding record. For example, a first value in the status flag indicates unbinding of the VIN code from the vehicle characteristic information, while a second value indicates binding of the VIN code to the vehicle characteristic information.

[0056] S103. Determine whether the query request contains a VIN code.

[0057] In this embodiment, when the system receives a vehicle repair query request, the query request contains at least one of a second VIN code and a second vehicle model identifier. The system proceeds to different processing branches based on whether the query request contains a VIN code.

[0058] In this embodiment, if it is determined that the query request contains the second VIN code, the detailed processing flow for query requests containing the VIN code is executed, i.e., the subsequent step S104. Otherwise, if it is determined that the query request does not contain the second VIN code but only contains the second vehicle model identifier (i.e., brand, model, year, etc.), the detailed processing flow for query requests containing only the vehicle model identifier is executed, i.e., the subsequent step S105.

[0059] S104. Obtain vehicle model identification based on VIN code.

[0060] In this embodiment, the system prioritizes querying the vehicle model identifier (i.e., the third vehicle model identifier) ​​bound to the second VIN code from the cache and the local binding database. To improve query performance and response speed, a hierarchical caching strategy can be adopted: first, query the high-speed cache; if the third vehicle model identifier is found in the cache, the result is returned directly; if the third vehicle model identifier is not found in the cache, the binding database is then queried. In some implementations, the obtained results are backfilled into the high-speed cache and a reasonable expiration time is set to accelerate subsequent identical queries.

[0061] In this embodiment of the application, if a uniquely bound third vehicle model identifier is found, the process jumps to the subsequent S106 step, whereby the third vehicle model identifier and the second VIN code are used together for subsequent maintenance processing.

[0062] In this embodiment, if multiple bound third vehicle model identifiers are found, it indicates that the second VIN code corresponds to multiple possible vehicle configurations in the binding database (one-to-many relationship). To ensure accuracy, the system can return an optional list containing all matching vehicle model identifiers to the requesting party (such as a repair application interface or a web interface) through a user interface (such as a repair application interface or a web interface), and request the requesting party to confirm the specific vehicle model configuration corresponding to this repair.

[0063] In this embodiment, if no binding record is found, it indicates that the second VIN code is unknown in the local knowledge base. The system then calls a third-party VIN code parsing API service through an external interface to obtain the vehicle model identifier corresponding to the second VIN code. During this process, if the number of failed calls exceeds a preset threshold within a short period, subsequent requests can be directly invalidated to avoid exhausting system thread resources due to the unavailability of the third-party service.

[0064] In this embodiment, if the third-party API call is successful and a valid third vehicle model identifier is obtained, the system can perform subsequent maintenance processing based on this identifier and the second VIN code. Simultaneously, to enrich the local knowledge base, the system can match the parsed textual vehicle model description with entries in the binding database (e.g., through keyword extraction and similarity calculation) to find the corresponding vehicle model identifier. Then, a new binding record is generated (containing the second VIN code, the matched vehicle model identifier, binding time, data source information, etc.) and sent via a message queue. The binding record management module 210 processes this message, updating the binding record in the binding database to ensure data consistency.

[0065] In this embodiment of the application, if a third-party API call fails (such as network timeout, service return error, etc.), the system will return a clear error message to the requester and the process will terminate.

[0066] S105. Obtain the VIN code based on the vehicle model identifier.

[0067] In this embodiment of the application, the system can perform a reverse query in the binding database based on the second vehicle identification provided in the query request (for example, a combination of brand, model series and year selected by the user) to find a list of all VIN codes (i.e., the third VIN codes) that are bound to it.

[0068] In this embodiment, if one or more third VIN codes are found, business scenarios can be expanded based on these codes. For example, the system can query the historical repair records of the vehicle model, perform batch data analysis, or generate statistical reports. For the current repair service request, the system will directly use the second vehicle model identifier without relying on or waiting for the VIN code result from the reverse query. This ensures that core repair services can still be executed without interruption even in the absence of a VIN code.

[0069] In this embodiment, if no bound third VIN code is found, it indicates that no vehicle has been bound to this specific vehicle model identifier in the binding database. The system will then perform maintenance processing based solely on the second vehicle model identifier.

[0070] S106. Execute the corresponding maintenance diagnostic logic based on the acquired vehicle information.

[0071] In this embodiment, step S106 is the final execution stage of the query process, which is handled by the maintenance service module. Vehicle information can be obtained through step S104, i.e., obtaining the vehicle model identifier from the VIN code, or through step S105, i.e., directly obtaining the vehicle model identifier. Ultimately, the system will obtain information used to uniquely identify the vehicle specifications, including a valid vehicle model identifier and possibly the accompanying VIN code.

[0072] In this embodiment of the application, after receiving this information pair, the repair service module can execute the corresponding vehicle repair and diagnostic process. For example, it can combine the vehicle model identifier with the received Diagnostic Trouble Code (DTC), query the repair knowledge base, and obtain the fault cause analysis, possible subsystems involved, repair suggestions, and diagnostic steps for the specific vehicle model. Based on the vehicle model identifier and repair items, it can generate a complete repair plan that includes a list of required parts (accurate part numbers adapted to the vehicle model), estimated labor hours, and technical points. It can also query the compatible part models, prices, and inventory information based on the vehicle model identifier.

[0073] Finally, the repair service module encapsulates the diagnostic results, repair solutions, or parts information into a response and returns it to the user terminal that initiated the query (such as the application interface of the diagnostic equipment or repair technician) through the system, thus completing the repair information query service.

[0074] Based on the methods shown in steps S101-S106 above, the information query method based on vehicle characteristics demonstrates the ability to ensure the continuous, stable, and efficient operation of core maintenance services in both scenarios with and without VIN codes.

[0075] Figure 4 This is a detailed processing flowchart illustrating a query request containing a VIN code, provided in an embodiment of this application, applicable to applications such as... Figure 1 The system framework 100 shown and as follows Figure 2 The vehicle feature-based information query system 200 shown specifically includes: S201. Receive a query request containing the VIN code.

[0076] In this embodiment, the maintenance server 120 can receive query requests, which may include the specific VIN code, i.e., the second VIN code, entered by the maintenance technician in the user terminal 110. The query request may also include other auxiliary information, such as fault codes.

[0077] In this embodiment, before the maintenance server 120 receives a query request containing a VIN code, the maintenance server 120 internally constructs a binding database for storing the mapping relationship between VIN codes and vehicle characteristic information (such as brand, model, and year). The specific method for establishing the binding database can be referred to the foregoing. Figure 3 The steps in S101 shown will not be repeated here.

[0078] S202. Query the bound database.

[0079] In this embodiment of the application, after receiving a query request, the vehicle identification query module 230 in the information query system 200 instructs the binding record management module 210 to query the cache and local binding database to obtain all activated binding records with the second VIN code, thereby obtaining the corresponding vehicle identification.

[0080] S203. Determine whether the query results include the binding record corresponding to the VIN code.

[0081] In this embodiment of the application, the system judges the query result of S202 to determine the subsequent process flow: If one or more third vehicle model identifiers (i.e., binding records corresponding to the VIN code) are found in the local database, the subsequent process jumps to step S206, where further processing is performed based on the vehicle feature information retrieved from the local database. If the third vehicle model identifier is unique, it is used directly; if there are multiple third vehicle model identifiers, all options must be presented to the user through an interactive interface (such as a pop-up window or drop-down list), requesting confirmation of the exact configuration corresponding to the current vehicle.

[0082] Otherwise, if no third vehicle model identifier corresponding to the VIN code is found in the local database (i.e., not including the binding record corresponding to the VIN code), it indicates that the second VIN code is unknown in the binding database, and the subsequent S204 step is executed: call the third-party VIN code parsing service interface to parse the VIN code and obtain the corresponding vehicle model identifier.

[0083] S204. Call the third-party VIN code parsing service interface to obtain the vehicle model identifier.

[0084] In this embodiment, the vehicle model identification query module 230 in the information query system 200 calls a configured third-party VIN code API through an integrated external service adapter. If the call is successful, the vehicle model description text parsed by the third-party service is obtained, i.e., the third vehicle model identifier.

[0085] S205. Update the bound database.

[0086] In this embodiment, after successfully obtaining the third vehicle model identifier by calling the third-party VIN code API in step S204, the system can perform the following operations: match the textual vehicle model description returned by the third party with the vehicle model information in the binding database, and determine the matching vehicle model identifier; create a binding record object containing information such as the second VIN code, the matched vehicle model identifier, the binding time, and the data source; and publish the binding record object to the message queue. The binding record management module 210 can retrieve messages from the queue, perform database insertion operations, and delete or update the corresponding cache key after success, ensuring that subsequent queries can immediately obtain the latest binding record.

[0087] In this embodiment, the method described above allows subsequent queries for the same VIN code to be performed in the local binding database without needing to call the paid third-party interface again, and avoids the risk of parsing failure due to network issues. Specifically, step S205 accumulates data in the binding database, enabling subsequent queries for the same VIN code to directly access the local database, thus avoiding the need to call the paid third-party interface again and avoiding the risk of parsing failure due to network issues.

[0088] S206. Execute subsequent logic based on the acquired vehicle feature information.

[0089] In this embodiment, the system sends the determined combination of the second VIN code and the third vehicle model identifier to the maintenance service module 250 in the information query system 200. The maintenance service module 250 can execute core business logic based on the vehicle identification information, such as matching the corresponding fault cause, detection steps, repair plan, and required parts list in the maintenance knowledge graph by combining the simultaneously input fault code. The final result is returned to the user terminal through the request receiving module, completing the maintenance query service.

[0090] Based on the method shown in steps S201-S205 above, this application fully realizes the technical path for obtaining accurate vehicle information with low cost and high reliability in scenarios with known VIN codes.

[0091] Figure 5This is a detailed processing flowchart illustrating a query request containing only vehicle model identifiers, provided in an embodiment of this application. It is applicable to applications such as... Figure 1 The system framework 100 shown and as follows Figure 2 The vehicle feature-based information query system 200 shown specifically includes: S301. Receive a query request containing vehicle model identifier.

[0092] In this embodiment, this step is handled by the request receiving module 220 in the information query system 200, specifically serving query scenarios without a VIN code. The query request includes a second vehicle model identifier, or other parameter combinations that uniquely point to a vehicle model configuration, selected or entered by the user.

[0093] In this embodiment, before receiving a query request containing vehicle model identification, the information query system 200 can act as a maintenance server 120, constructing a binding database through the binding record management module 210 to store the mapping relationship between VIN codes and vehicle characteristic information (such as brand, model, and year). The specific method for establishing the binding database can be referred to the foregoing. Figure 3 The steps in S101 shown will not be repeated here.

[0094] S302. Query the bound database.

[0095] In this embodiment, this step is performed by the VIN code query module 240 in the information query system 200, which performs a reverse query. Based on the received second vehicle model identifier, the system searches for a binding record with that second vehicle model identifier in the cache and binding database. Since a clear mapping relationship has been established between vehicle feature information and the VIN code in the binding database, this reverse association query can be completed directly.

[0096] S303. Determine whether the query results include the VIN code associated with the vehicle model identifier.

[0097] In this embodiment, the system processes the reverse query results: if one or more bound third VIN codes (i.e., VIN codes bound to the vehicle model identifier) ​​are found, the system can reuse the existing subsequent processing logic that uses the VIN code as an input parameter based on these third VIN codes. For example, an internal service can be called to indirectly convert the vehicle feature information input by the user into an internal VIN code entity through internal data mapping relationships, thereby triggering a series of deep data services based on the VIN code, without relying on any external parsing services, which can reduce dependence on third parties and the corresponding costs and risks.

[0098] Otherwise, if no bound third VIN code is found (i.e., excluding the VIN code bound to this vehicle model identifier), it indicates that no vehicle has been bound to this specific configuration in the system, and the process ends. In some implementations, the system may also perform subsequent maintenance processing based solely on the obtained second vehicle model identifier, providing services such as fault diagnosis and solution matching; this application embodiment does not impose such limitations.

[0099] S304. Execute subsequent logic based on the acquired vehicle feature information.

[0100] In this embodiment, the maintenance service module 250 in the information query system 200 can use the second vehicle model identifier and the third VIN code provided by the user as input, and query the maintenance knowledge base according to the vehicle model identifier to provide services such as fault diagnosis and solution matching.

[0101] Based on the method shown in steps S301-S304 above, this application constructs a maintenance information query path independent of the VIN code, expanding the application scenarios of the system.

[0102] It should be understood that, as mentioned above Figure 3 , Figure 4 and Figure 5 The steps in the flowcharts are shown sequentially as indicated by the arrows, but these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise explicitly stated herein, there is no strict order in which these steps are performed; they can be executed in other orders. Furthermore, as mentioned above... Figure 3 , Figure 4 and Figure 5 The flowchart may include at least some steps or stages. These steps or stages are not necessarily completed at the same time, but may be executed at different times. The execution order of these steps or stages is not necessarily sequential, but may be executed in turn or alternately with other steps or at least some of the steps or stages in other steps.

[0103] In this embodiment, taking a specific repair diagnosis request as an example, the specific steps of the interaction between the internal modules of the vehicle feature-based information query system 200 can be as follows: the binding record management module 210 constructs a binding database containing VIN codes and vehicle model identification records; the technician enters the VIN code in the repair APP and sends a vehicle repair query request; the request receiving module 220 obtains the query request and submits it to the vehicle feature-based information query system; the system identifies that the request contains the VIN code (the second VIN code) and calls the vehicle model identification query module 230; the vehicle model identification query module 230 first instructs the binding record management module 210 to query the binding database; binding After the record management module 210 checks the cache and database, it returns the binding record of the VIN code through the VIN code query module 240, for example, there are two third vehicle model identifiers; the vehicle model identifier query module 230 returns the two third vehicle model identifiers to the APP interface through the request receiving module 220, prompting the technician to select the specific configuration, and the technician confirms the required third vehicle model identifier; after the system obtains the confirmed vehicle model identifier, it submits it to the repair service module 250 along with the original VIN code; the repair service module 250 queries the fault code knowledge base based on the two key pieces of information, the second VIN code and the third vehicle model identifier, generates a specific diagnostic report and repair suggestions, and returns them to the APP to be presented to the technician.

[0104] In this embodiment of the application, when the binding record between the VIN code and the vehicle model identifier changes (such as adding a binding record, unbinding, or changing the binding), in addition to updating the database, it is also necessary to synchronize or invalidate the corresponding cache key to prevent invalid data from appearing.

[0105] In this embodiment, when determining the binding record between the VIN code and the vehicle model identifier, the system needs to match the textual vehicle model description returned by the third-party API with the entries in the local vehicle feature information database. This can be achieved through techniques such as keyword extraction and cosine similarity calculation to improve the accuracy of automatic binding.

[0106] Example 3 Figure 6 This is a schematic diagram of the hardware structure of a computer device provided in an embodiment of this application. The computer device 600 may include the aforementioned... Figure 1 The system framework 100 shown and as follows Figure 2 The illustrated information query system 200 is based on vehicle characteristics. (For example...) Figure 6 As shown, the computer device 600 includes: a processor 601, a memory 602, a communication module 604, and a computer program 603 stored in the memory 602 and executable on the processor 601. When the processor 601 executes the computer program 603, it implements the aforementioned... Figures 3-5The execution steps are shown. For example, the computer program 603 described above can be divided into one or more units / modules, which are stored in the memory 602 and executed by the processor 601 to complete this application.

[0107] The aforementioned one or more units / modules may be a series of computer program instruction segments capable of performing a specific function. These instruction segments describe the execution process of the aforementioned computer program 603 within the aforementioned computer device 600. For example, the aforementioned computer program 603 may be used to perform actions such as... Figure 3 The information query method based on vehicle features shown in steps S101-S106 has been described in the above embodiments for its specific functions or mechanisms, and will not be repeated here.

[0108] Those skilled in the art will understand that Figure 6 This is merely an example of computer device 600 and does not constitute a limitation on computer device 600. It may include more or fewer components than shown, or combine certain components, or different components. For example, the computer device 600 described above may also include input / output devices, network access devices, buses, etc.

[0109] The processor 601 mentioned above can be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor.

[0110] In some embodiments, the processor 601 may include one or more interfaces. These interfaces may include: an internal integrated circuit I2C interface, an integrated circuit built-in audio bus I2S interface, a pulse code modulation (PCM) interface, a universal asynchronous transceiver (URAT) interface, a mobile industry processor MIPI interface, a general purpose input / output (GPIO) interface, an on-board diagnostic (OBD) system interface, and / or a universal serial bus (USB) interface, etc. It is understood that the interface connection relationships between the modules illustrated in the embodiments of this application are merely illustrative and do not constitute a structural limitation on the computer device 600. In other embodiments of this application, the computer device 600 may also employ different interface connection methods or combinations of multiple interface connection methods as described in the above embodiments.

[0111] In some embodiments, the computer device 600 can connect internal devices and modules through one or more interfaces. The aforementioned memory 602 can be an internal storage unit of the computer device 600, such as a hard disk or RAM. The aforementioned memory 602 can also include both internal storage units and external storage devices. The aforementioned memory 602 is used to store the aforementioned computer program and other programs and data required by the computer device 600. The aforementioned memory 602 can also be used to temporarily store data that has been output or will be output.

[0112] The communication module 604 can provide solutions for wireless communication applications on the computer device 600, including Wireless Local Area Network (WLAN), Bluetooth (BT), Global Navigation Satellite System (GNSS), Frequency Modulation (FM), Near Field Communication (NFC), and Infrared (IR). The communication module 604 can be one or more devices integrating at least one communication processing module. The communication module 604 receives electromagnetic waves via an antenna, demodulates and filters the electromagnetic wave signals, and sends the processed signals to the processor 601. The communication module 604 can also receive signals to be transmitted from the processor 601, frequency modulate and amplify them, and then convert them into electromagnetic waves for radiation via the antenna.

[0113] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the above equipment can be divided into different functional units or modules to complete all or part of the functions described above.

[0114] The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or in the form of software functional units.

[0115] In the embodiments of this application, the specific names of each functional unit and module are only for easy distinction and are not intended to limit the scope of protection of this application. It should be understood that each step in the above-described method embodiments provided in this application can be completed by the integrated logic circuits in the processor hardware or by instructions in software form. The method steps disclosed in the embodiments of this application can be directly manifested as being executed by a hardware processor, or being executed by a combination of hardware and software modules in the processor.

[0116] This application also provides a computer program product, which includes a computer program (also referred to as code or instructions) that, when run, causes a computer to execute the information query method based on vehicle features described in the above embodiments.

[0117] The various embodiments of this application can be combined arbitrarily to achieve different technical effects.

[0118] In the embodiments provided in this application, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented, in whole or in part, in the form of a computer program product.

[0119] The computer program product includes one or more computer instructions. When these computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in this application are generated. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device.

[0120] This application also provides a computer-readable storage medium storing a computer program (also referred to as code or instructions). When the computer program is run, it causes the computer to perform the method executed by the computer device in any of the foregoing embodiments.

[0121] Figure 7 This is a schematic diagram of a computer-readable storage medium provided in an embodiment of this application. For example... Figure 7 As shown, the computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means.

[0122] The computer-readable storage medium can be any available medium that a computer can access, or a data storage device such as a server or data center that integrates one or more available media. The available medium can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., Digital Universal Optical Discs, DVDs), or semiconductor media (e.g., solid-state drives, SSDs), etc.

[0123] Those skilled in the art will understand that implementing all or part of the processes in the foregoing embodiments can be accomplished by a computer program instructing related hardware. This program can be stored in a computer-readable storage medium, and when executed, it can include the processes described in the foregoing method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as ROM or RAM, magnetic disks, or optical disks.

[0124] In summary, the above description is merely an embodiment of the technical solution of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made based on the disclosure of this application should be included within the scope of protection of this application.

Claims

1. A method for information querying based on vehicle characteristics, characterized in that, Includes the following steps: The first vehicle model identifier is obtained based on an external interface. When the first vehicle identification code (VIN) calls a third-party VIN parsing service to obtain the first vehicle model identifier, the binding record between the first vehicle identification code (VIN) and the first vehicle model identifier is stored in the local binding database. Obtain a vehicle repair query request, wherein the query request contains at least one of a second VIN and a second vehicle model identifier, and determine whether the query request contains the second VIN; If the query request contains the second VIN, then the binding database is queried to obtain the third vehicle model identifier bound to the second VIN, and the repair process is performed based on the result of obtaining the third vehicle model identifier; If the query request does not contain the second VIN but contains the second vehicle model identifier, then the binding database is queried to obtain the third VIN bound to the second vehicle model identifier, and the repair process is performed based on the result of obtaining the third VIN.

2. The method according to claim 1, characterized in that, The repair process based on the acquisition result of the third vehicle model identifier specifically includes: If the binding database finds the third vehicle model identifier, then repair processing is performed based on the second VIN and the third vehicle model identifier; Otherwise, a third-party VIN parsing service is invoked to obtain the third vehicle model identifier, and then the repair process is performed based on the second VIN and the third vehicle model identifier.

3. The method according to claim 1, characterized in that, The maintenance process based on the obtained third VIN specifically includes: If the third VIN is found in the bound database, repair processing is performed based on the third VIN and the second vehicle model identifier; otherwise, the repair processing is terminated.

4. The method according to claim 2, characterized in that, After obtaining the third vehicle model identifier by calling a third-party VIN resolution service, the method further includes: Establish the binding record between the second VIN and the third vehicle model identifier, and update the binding database based on the binding record.

5. The method according to claim 1, characterized in that, The method further includes: The binding database unbinds and rebinds the binding records, and stores multiple different vehicle identification numbers bound to a single VIN code in the binding records.

6. The method according to claim 5, characterized in that, The step of querying the binding database to obtain the third vehicle model identifier bound to the second VIN specifically includes: When the binding database finds that the second VIN is bound to multiple vehicle model identifiers, it returns the multiple vehicle model identifiers to the requester and confirms whether the multiple vehicle model identifiers include the third vehicle model identifier.

7. The method according to claim 1, characterized in that, The external interface includes at least one of the following: external system interface, web interface, and application (APP) interface.

8. An information query system based on vehicle characteristics, used to implement the method as described in any one of claims 1-7, characterized in that, include: The binding record management module is used to maintain the binding database, which stores the binding records of the first VIN and the first vehicle model identifier, and supports the creation, deletion, modification and query of the binding records; A request receiving module is used to obtain a vehicle maintenance query request, wherein the query request includes at least one of a second VIN and a second vehicle model identifier; The vehicle identification query module is used to obtain the bound third vehicle identification when the second VIN code is known, and to perform maintenance processing based on the obtained result; The VIN code query module is used to obtain the bound third VIN code when the second vehicle identification is known, and to perform maintenance processing based on the obtained result; The maintenance service module is used to perform corresponding maintenance diagnosis or solution matching logic on the obtained VIN code and vehicle model identifier.

9. A computer device, characterized in that, The device includes one or more memories and one or more processors; the memories are coupled to the one or more processors, the memories are used to store computer program code, the computer program code including computer instructions, and the one or more processors invoke the computer instructions to cause the computer device to perform the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium storing computer instructions thereon, characterized in that, When the computer instructions are executed by the processor, they implement the method of any one of claims 1 to 7.

Images