Blockchain-based vehicle maintenance management method and device, server terminal, and computer readable medium

Abstract

The application relates to a blockchain-based vehicle maintenance management method, device, server terminal and computer readable medium. The method comprises: obtaining information required for vehicle maintenance through a data interface, and generating a data packet based on the information; processing the data packet by converting the data packet into a uniform format of a consortium chain; in response to a query request issued by a user, initiating a multi-chain query for the data packet by calling a data aggregation engine on the chain, and enabling the information queried to be displayed to the user; and assigning different on-chain operation codes and corresponding permission ranges to parties related to the vehicle, and the permission range of each party can be dynamically adjusted under predetermined constraints set for other parties.

Description

Technical Field

[0001] This invention relates to the fields of artificial intelligence and blockchain technology, and in particular to a vehicle maintenance management method, apparatus and computer-readable medium based on blockchain (consortium blockchain). Background Technology

[0002] Existing vehicle maintenance organizations (such as 4S shops that operate car repair or maintenance) generally use electronic maintenance record systems to manage the regular maintenance of vehicles. The working principles of the maintenance record systems used are mainly divided into two categories: blockchain-based application systems or single query systems.

[0003] However, regardless of the maintenance system adopted, several technical issues exist. Specifically, blockchain-based application systems rely on centralized nodes at the OEM (Original Equipment Manufacturer) to review data, lacking multi-dimensional information such as parts manufacturers, quality inspection reports, and replacement images. Furthermore, there is no automatic data verification and update mechanism. Therefore, using this technology leads to high costs for manual data review and on-chain processing, and poses a risk of data entry errors. In contrast, single-query systems lack multi-dimensional filtering functions such as time range and parts model, and do not incorporate fault prediction or parts traceability capabilities. Consequently, existing technologies require users to manually match paper documents to confirm parts quality, resulting in low traceability efficiency. Summary of the Invention

[0004] To address the problems existing in the prior art, this invention proposes a vehicle maintenance management technology based on blockchain (consortium blockchain).

[0005] According to one aspect of the present invention, a method is provided to obtain information required for vehicle maintenance through a data interface and generate a data packet based on the information; process the data packet by converting it into a unified format of a consortium blockchain; in response to a query request issued by a user, initiate a multi-chain query for the data packet by calling an on-chain data aggregation engine, and enable the queried information to be displayed to the user; and assign different on-chain opcodes and corresponding permission ranges to vehicle-related participants, wherein the permission range of each participant can be dynamically adjusted under predetermined constraints set on other participants.

[0006] Based on the above embodiments, other embodiments of the present invention further include: the operation of acquiring information includes at least one of RFID scanning acquisition, OBD II interface acquisition, or manual entry acquisition by the client.

[0007] Based on the above embodiments, according to other embodiments of the present invention, the participating parties are defined as one or more of the following: vehicle owners, maintenance personnel, parts manufacturers, OEMs, and system administrators.

[0008] Based on the above embodiments, according to other embodiments of the present invention, it further includes: monitoring the vehicle condition based on real-time collected data related to vehicle operation, wherein when it is confirmed that the vehicle condition falls into an abnormal range, an abnormal data notification that informs the vehicle condition warning is pushed to the repair shop node and the vehicle owner node.

[0009] Based on the above embodiments, according to other embodiments of the present invention, it further includes: extracting historical data related to the vehicle from the blockchain and sending it to the model training terminal, wherein the model training terminal is configured to perform data cleaning, feature filtering and model training, and generate at least one of a vehicle performance evaluation report, a vehicle fault prediction report or a vehicle maintenance recommendation report based on information related to the current condition of the vehicle.

[0010] Based on the above embodiments, according to other embodiments of the present invention, the method further includes: during the execution of the OBD II interface acquisition, automatically converting the acquired data into an on-chain structured format and transmitting it to the application adaptation layer, wherein in the on-chain structured format, each data item includes a VIN code as a unique vehicle identifier, a data item, a value, an acquisition timestamp, and a terminal signature, and the application adaptation layer performs range verification on the received data, and according to the result of the range verification, abnormal data is packaged separately into an abnormal data temporary package, and normal data is packaged separately into a vehicle condition data package, and the abnormal data temporary package and the vehicle condition data package are transmitted into different on-chain queues respectively.

[0011] Based on the above implementation method, according to other embodiments of the present invention, the method further includes: for the uploaded data packets, consensus and on-chain are completed through the following operations: a master node is randomly elected from the consensus node pool at predetermined time intervals; the master node obtains the data packets to be subjected to consensus operations from the application adaptation layer, generates a consensus proposal based on the data packets, and broadcasts the consensus proposal to all consensus nodes; wherein the consensus proposal includes a list of data packets, a proposal timestamp, and a master node signature; after receiving the proposal, each consensus node verifies the validity of the master node signature, the integrity of the data packets, and the legality of the data, and feeds back the verification results of each node to the master node; and when the statistical value of the verification results reaches a predetermined proportion, consensus is determined to be formed; when the statistical value of the verification results does not reach the predetermined proportion, consensus is determined not to be formed.

[0012] Based on the above embodiments, according to other embodiments of the present invention, it further includes: deploying a core smart contract in a blockchain-based storage device to enable participants to perform access operations. The core smart contract is written in Solidity and has core node signature authentication. The core smart contract includes at least one of the following: a vehicle parts verification contract, wherein the vehicle parts verification contract is automatically invoked after the application adaptation layer uploads a parts data package to verify the validity of the parts; a vehicle maintenance reminder contract, wherein the vehicle maintenance reminder contract is automatically invoked after the vehicle condition data package is uploaded via the OBD II interface, wherein the vehicle maintenance reminder contract extracts information related to data of a predetermined type of vehicle and determines whether to send a reminder to the client based on the comparison result of the extracted information and a threshold; and a vehicle maintenance data update contract, wherein the maintenance personnel initiate a request to supplement or modify the maintenance records of the vehicle, and if the maintenance personnel's permissions meet the predetermined requirements, modification and updating of the vehicle's maintenance records are permitted.

[0013] Based on the above embodiments, according to other embodiments of the present invention, the participating parties include: vehicle owners, repair personnel, parts manufacturers, OEMs, and system administrators, and each participating party is assigned different operating permissions. Specifically, vehicle owners are limited to being able to invoke at least one of the following contracts: maintenance record query contract, parts traceability contract, vehicle condition query contract, and prediction result viewing contract; repair personnel are limited to being able to invoke at least one of the following contracts in which they participate: maintenance record modification contract, parts on-chain contract, and maintenance data entry contract; parts manufacturers are limited to being able to invoke at least one of the following contracts: parts traceability query contract and parts data update contract in which they participate; OEMs are limited to being able to invoke at least one of the following contracts: vehicle model summary data contract, fault statistics contract, and threshold configuration contract; and system administrators are limited to being able to invoke at least one of the following contracts: node audit contract, permission adjustment contract, full data query contract, and privacy authorization contract.

[0014] Based on the above embodiments, according to other embodiments of the present invention, the query further includes: the query includes: performing the query by using a tag scanning query or a multi-condition filtering query, wherein, in the tag scanning query, the user scans the VIN code, which is the unique identifier of the vehicle, or the RFID tag of the accessory that identifies the vehicle accessory through a mobile terminal to obtain information related to the vehicle or information related to the accessory; and in the multi-condition filtering query, the user inputs multiple combinations of conditions through a mobile terminal to obtain information related to the vehicle or information related to the accessory that meets the conditions.

[0015] According to another aspect of the present invention, a blockchain-based vehicle maintenance management device is also provided, comprising: a data collection module, which acquires information required for vehicle maintenance through a data interface and generates data packets based on the information; a blockchain storage module, which processes the data packets by converting them into a unified format of a consortium blockchain; a data query module, which, in response to a query request issued by a user, initiates a multi-chain query on the data packets by calling an on-chain data aggregation engine, and enables the queried information to be displayed to the user; and a permission management module, which assigns different on-chain operation codes and corresponding permission ranges to vehicle-related participants, wherein the permission range of each participant can be dynamically adjusted under predetermined constraints set for other participants.

[0016] According to another aspect of the present invention, a server terminal is also provided, comprising: one or more processors; and a storage device for storing one or more programs, which, when executed by the one or more processors, cause the one or more processors to perform operations on the vehicle maintenance management method.

[0017] According to another aspect of the present invention, a computer-readable medium is provided having a computer program stored thereon, the program being executed by a processor to operate the vehicle maintenance management method described herein.

[0018] The further effects of the aforementioned unconventional alternative methods will be explained below in conjunction with specific implementation methods. Attached Figure Description

[0019] The accompanying drawings are provided to better understand the invention and are not intended to unduly limit the scope of the invention. Wherein: Figure 1 This is a schematic diagram of the data transmission structure for vehicle maintenance management according to an embodiment of the present invention; Figure 2 This is a schematic diagram of the main modules of a vehicle maintenance management device according to an embodiment of the present invention; Figure 3 This is an exemplary system architecture diagram in which embodiments of the present invention can be applied; Figure 4 This is a schematic diagram of the structure of a computer system suitable for implementing terminal devices or servers of the present invention. Detailed Implementation

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

[0021] It should be noted that the collection, gathering, updating, analysis, processing, use, transmission, and storage of user personal information involved in this disclosed technical solution all comply with relevant laws and regulations, are used for legitimate purposes, and do not violate public order and good morals. Necessary measures are taken to prevent unauthorized access to user personal information data and to safeguard user personal information security, network security, and national security.

[0022] This invention relates to several specific technical terms and commonly used expressions. The following provides a basic explanation of each term or expression. **Blockchain (Consortium Blockchain):** A decentralized distributed ledger composed of specific trusted nodes (such as OEMs and repair shops). Nodes require access approval, and data is only accessible to authorized nodes, balancing security and controllability, unlike public blockchains with no access restrictions. **RFID Tag:** A carrier of radio frequency identification technology, conforming to the ISO 18000-6C protocol. It can store information such as parts manufacturers and production dates, and is read via radio signals without physical contact, with a scanning distance of 0-5 meters. **Smart Contract Function:** A computer protocol deployed on the blockchain, with preset trigger conditions (such as successful parts signature verification or reaching a mileage threshold). When the conditions are met, it automatically executes operations (such as uploading data to the blockchain or sending push notifications), without third-party intervention, and the results are irreversible. **RBAC Model:** A role-based access control model that defines a "role-permission" mapping relationship, assigns permissions to roles, and then assigns roles to users, achieving fine-grained permission management and preventing permission abuse. Random Forest Algorithm: An ensemble learning algorithm that constructs multiple decision trees (100 in this solution) to predict input data. The final result is the vote / average of all decision trees, improving the model's generalization ability and suitable for multi-feature fault prediction scenarios. MAE / MSE: Mean Absolute Error and Mean Squared Error, both metrics for evaluating the accuracy of a prediction model. Smaller values ​​indicate smaller deviations between the model's predictions and actual values, resulting in higher accuracy. OBD II Interface: The second-generation interface for on-board diagnostic systems. It connects to the vehicle's ECU (Electronic Control Unit) via the CAN bus, allowing the reading of real-time data such as engine speed, coolant temperature, and fuel consumption, and is compatible with most mainstream vehicle models worldwide. PBFT Consensus Mechanism: A Practical Byzantine Fault Tolerance consensus algorithm that can tolerate malicious behavior (such as data tampering or non-response) from 1 / 3 of the nodes, ensuring the consistency of blockchain data in untrusted environments and suitable for consortium blockchain scenarios. TLS 1.3 Protocol: Transport Layer Security version 1.3, used for encryption during data transmission to prevent data interception and tampering. It reduces handshake time by 50% compared to the older version (TLS 1.2) and offers higher security. AES-256 Encryption: The 256-bit key version of the Advanced Encryption Standard, a symmetric encryption algorithm with high encryption strength and difficulty in cracking, suitable for blockchain data storage encryption.

[0023] Overall, the existing technology has several technical problems.

[0024] (1) Insufficient data security and integrity: For example, while existing technologies use blockchain to store data, the reliance on a single OEM's node for verification still poses a risk of centralization. Furthermore, the lack of encryption protocols for data transmission (such as uploading parts information) increases the risk of data interception and tampering. Additionally, the absence of crucial information such as parts production quality inspection reports and replacement images indicates insufficient data integrity.

[0025] (2) Inefficient querying and tracing: For example, existing technologies may only support a single query method, lack multi-dimensional filtering, and have a query response time exceeding 10 seconds. Furthermore, parts traceability relies on manually matching paper documents and cannot directly link parts manufacturer information through the system, making the traceability process cumbersome and prone to errors.

[0026] (3) Lack of intelligent analysis and fault prediction capabilities: Existing vehicle maintenance management systems can only display historical maintenance records and lack in-depth data analysis capabilities. Because they cannot predict malfunctions based on maintenance and vehicle operation data, car owners are forced to passively undergo repairs, increasing maintenance costs.

[0027] (4) Access control is crude and inflexible: The existing vehicle maintenance management system only has two levels of access control. This allows car owners to mistakenly access other people's data, and repair shops to modify maintenance records not entered into by the owner, meaning data privacy and security are difficult to guarantee. Furthermore, since access control adjustments require manual application submission, the process takes more than 24 hours, which cannot meet the needs of dynamic scenarios.

[0028] (5) Limited health management functions: Existing vehicle maintenance management systems can only remind users when a maintenance cycle is due, lacking real-time vehicle status monitoring (such as engine coolant temperature and brake pad wear), performance trend analysis, and visualization. This prevents car owners from fully understanding their vehicle's health status and makes it difficult to prevent potential malfunctions in advance.

[0029] Therefore, in order to solve the problems of the prior art, the present invention proposes a vehicle maintenance management method, device and computer-readable medium based on blockchain (consortium blockchain).

[0030] Figure 1 This is a schematic diagram of the data transmission structure of a vehicle maintenance management system according to an embodiment of the present invention. Figure 1 As shown, the system includes a data acquisition layer, a blockchain storage layer, and an application service layer.

[0031] The data acquisition layer includes one or more of the following: an RFID scanning module, an OBD II interface module, or a manual data entry terminal. The RFID scanning module conforms to the ISO 18000-6C protocol, with a scanning distance of 0-5m and a reading time of ≤100ms. The OBD II interface module is compatible with mainstream vehicle models, collecting vehicle operating data such as engine speed (0-8000rpm) and coolant temperature (-40-125℃), with a sampling frequency of, for example, 1 time / second. The manual data entry terminal can be, for example, a web / app interface, supporting batch import from Excel and performing field validation, such as specifying maintenance costs ≥0 and date format YYYY-MM-DD, etc.

[0032] The blockchain storage layer includes one or more modules or devices such as consortium blockchain nodes, consensus mechanisms, encryption modules, and smart contract modules. Consortium blockchain nodes store information related to car owners, repair shops, parts manufacturers, and OEMs. Node access requires submission of a business license and OEM certification. The consensus mechanism uses PBFT (Practical Byzantine Fault Tolerance), with a minimum of 4 nodes, a consensus latency of ≤500ms, and a fault tolerance rate of 1 / 3 node failure. The encryption module can store and encrypt data, such as using AES-256 symmetric encryption, or chained hashing (SHA-256), where each block contains the hash of the previous block. The smart contract module stores information such as parts verification contracts and maintenance reminder contracts, and can automatically execute preset rules.

[0033] The application service layer includes at least a data query module, a permission management module, a health management module, and a data analysis and reporting module. The data query module supports tag scanning and multi-condition filtering based on time, vehicle model, and maintenance item, with a response time of ≤1 second. The permission management module uses the RBAC model, a 5-level role-based permission matrix, and supports dynamic adjustment and audit logs. The health management module provides real-time monitoring, early warning push notifications, and performance trend charts. The data analysis and reporting module is used for machine learning-based fault prediction, comprehensive performance scoring, and generates PDF / Excel reports.

[0034] Figure 2 This is a schematic diagram of the hardware structure of a vehicle maintenance management system according to an embodiment of the present invention. According to an embodiment of the present invention, a vehicle maintenance management system based on blockchain (consortium blockchain) is proposed, which can record and trace vehicle maintenance. It includes a data collection module, a blockchain storage module, a data query module, an access control module, a health management module, and a data analysis and reporting module. Each module collaborates through a closed-loop link of "collection-on-chain-call-feedback," and each link incorporates the unique trust processing logic of the consortium blockchain.

[0035] The following is a detailed description of the data collection module 201. The data collection module 201 performs on-chain adaptation preprocessing for multi-source data. This module not only achieves multi-dimensional data collection but also solves the problems of "data collection compatibility with blockchain storage format" and "pre-verification of data credibility," thereby laying the foundation for subsequent on-chain storage.

[0036] Data collection module 201: The operations performed by the data collection module 201 involve different data collection content and different data collection methods. The following is a description of these methods.

[0037] ——Content collected

[0038] In addition to traditional maintenance schedules, items, parts used, repair personnel, and costs, embodiments of the present invention add on-chain correlated core fields for data collection. This enables on-chain verification and traceability of key information, allowing linkage with consortium blockchain nodes and external authoritative platforms—such as national digital certificate authentication authorities (CA institutions) and national vehicle parts quality inspection platforms. Its core value is ensuring data integrity and credibility. This ensures data can be linked with blockchain nodes and external authoritative platforms. Specific collected content relates to information needed for vehicle maintenance, such as information related to "vehicle parts," "vehicle operation," and "vehicle maintenance process."

[0039] The "vehicle spare parts" aspect involves at least one or more pieces of information associated with vehicle spare parts, such as: manufacturer name and digital certificate (must be consistent with the certificate format of the national CA institution, including the manufacturer's public key), production date, quality inspection report number (linked to the national vehicle spare parts quality inspection platform API interface, with interface calls using TLS 1.3 encryption), and high-definition images before / after part replacement (resolution ≥1080P, MP4 storage format, single file ≤500MB, image files are uploaded to the blockchain after generating SHA-256 digests, and the original files are stored on off-chain distributed storage nodes, with a one-to-one correspondence between the digest and the original file). Existing maintenance systems use traditional data collection methods, which typically only record the part name / model, lacking manufacturer qualifications, quality inspection certificates, and replacement images, making it impossible to verify the authenticity and compliance of the parts. In contrast, the data collection method according to this invention adds the following information: (i) Add manufacturer digital certificate + public key, and associate it with the "parts manufacturer node filing information" of the core layer of the consortium chain to realize on-chain pre-verification of manufacturer identity (if not filed, it cannot be uploaded to the chain). (ii) Add a quality inspection report number, use TLS 1.3 encryption to call the national vehicle parts quality inspection platform interface, obtain the electronic report and generate a summary to upload to the blockchain, so as to realize authoritative linkage of parts quality inspection information; (iii) Add SHA-256 summaries of images before and after replacement of parts. The original images are stored off-chain, and the summaries are stored on-chain for evidence. Users can verify that the images have not been tampered with through the summaries, and complete the visual traceability of the replacement process.

[0040] By collecting data in association with the above information, the data on parts can be upgraded from "basic name records" to trusted on-chain data covering the entire chain from "manufacturer to quality inspection to replacement process".

[0041] The "vehicle operation" aspect involves at least one or more of the information related to the vehicle's own operation, such as: engine speed (e.g., 0-8000 rpm), coolant temperature (e.g., -40-125℃), fuel consumption (e.g., L / 100km), brake disc wear thickness (e.g., mm, accurate to 0.1mm), and tire pressure (e.g., kPa, accurate to 1kPa) collected by the OBD II interface. All data carries a collection timestamp (accurate to the second). Traditional vehicle-level data collection often lacks real-time vehicle condition data, relying solely on passive maintenance cycle reminders, which fails to grasp the vehicle's dynamic status. According to this invention, through the OBD II interface module (compatible with mainstream models, sampling frequency 1 time / second), quantitative vehicle condition fields such as engine speed, coolant temperature, and brake disc wear thickness are added in batches, and a timestamp is added to each data point, achieving real-time and continuous collection of vehicle status. Meanwhile, newly added data is automatically converted into an "on-chain structured format" (including VIN code and terminal signature), and the application adaptation layer gateway performs range verification (e.g., engine speed > 8000rpm is marked as abnormal), distinguishing between "normal / abnormal vehicle condition data packets" and entering different on-chain queues.

[0042] By collecting data in conjunction with the vehicle dimension and the above information, vehicle data can be upgraded from "stateless records" to dynamic monitoring data with "real-time quantification + on-chain anomaly marking," providing a foundation for subsequent health management and fault prediction.

[0043] The "vehicle maintenance process" aspect involves at least one or more pieces of information related to the work of repairing and maintaining a vehicle, such as: videos of maintenance personnel performing operations (key steps, e.g., duration ≤ 10 minutes, also generating SHA-256 digests and uploading them to the blockchain), and post-maintenance vehicle inspection data (e.g., engine idle speed stability, with idle speed fluctuation values ​​≤ 50 rpm considered normal; this threshold is preset by the OEM node and written into the on-chain configuration block). Traditional maintenance processes typically only record maintenance items, without leaving traces of the operation process or standards for verifying maintenance effectiveness, making it impossible to confirm the compliance and effectiveness of maintenance. According to an embodiment of the present invention, the following features are added: SHA-256 digests of key operation videos performed by maintenance personnel are used for video evidence storage of core maintenance steps (such as oil change and brake pad removal and installation), and the digests are uploaded to the blockchain to achieve traceability of the operation process; vehicle inspection data after maintenance (such as engine idle speed fluctuation value) with a pass threshold (≤50rpm) is written to the blockchain configuration block by the OEM, and the standardized verification of maintenance effect can be automatically completed after the data is uploaded to the blockchain, and if the threshold is not met, it is marked as abnormal; maintenance personnel registration ID verification logic is used, and the "maintenance personnel node registration contract" of the consortium blockchain is called when data is entered, and only data after the personnel's qualifications are confirmed can generate a "maintenance detail data package" and be uploaded to the blockchain.

[0044] By collecting data in association with the "maintenance process dimension" and the above information, the maintenance process can be upgraded from "project result recording" to a fully controllable chain of data that includes "operation traceability + effect verification + personnel qualification verification".

[0045] ——Data collection method (integrating on-chain pre-verification logic)

[0046] (1) RFID scanning and data collection: The system adapts to the RFID tags that come pre-installed with the parts (compliant with the ISO 18000-6C protocol). After the scanning module reads the "manufacturer ID, part number, and production date" from the tag, it automatically triggers on-chain pre-verification: it calls the "parts manufacturer authentication interface" through the application adaptation layer gateway (connected to the consortium blockchain application adaptation layer) to verify whether the manufacturer ID has been registered with the core layer node of the consortium blockchain; if the registration is successful, it simultaneously calls the national vehicle parts quality inspection platform interface (carrying the quality inspection report number) to obtain the electronic version of the quality inspection report (PDF format) and generates a report summary (SHA-256), which is packaged with the RFID reading data into an "on-chain data package" (JSON format, containing the "data type: RFID - parts" identifier), waiting to be uploaded to the blockchain; if it has not been registered or the quality inspection report does not exist, the module pops up a message "parts manufacturer not approved / quality inspection invalid", and the data does not enter the on-chain process.

[0047] This process breaks through the pre-verification logic of existing technologies, realizing automatic verification through "multi-node + external authoritative platform" linkage. Unlike the traditional, singular, and manual verification mode, it is key to achieving "pre-emptive assurance of data credibility before it goes on the blockchain." This process has outstanding effects, such as: automated triggering logic: verification is automatically triggered after RFID reads the part information without manual intervention, replacing the traditional manual submission and review mode; multi-source verification chain: it simultaneously links the "consortium blockchain core layer manufacturer registration node" and the "National Vehicle Parts Quality Inspection Platform," achieving dual verification of manufacturer identity and part qualifications; on-chain linkage of verification results: the verification result directly determines whether the data can enter the blockchain queue, and the verification log is traceable, forming a closed-loop trusted management system of "collection-verification-on-chain."

[0048] (2) OBD II interface acquisition: Connect to the vehicle's OBD interface via CAN bus to read vehicle operation data in real time (sampling frequency 1 time / second). After the data is processed by the acquisition terminal, it is automatically converted into "on-chain structured format": each data includes "VIN code (Vehicle Identification Number), data item (such as engine speed), value, acquisition timestamp, terminal signature (generated by the acquisition terminal private key)", and is transmitted to the consortium blockchain application adaptation layer via TLS 1.3 protocol; the application adaptation layer gateway performs "range verification" on the data (such as marking "abnormal data" when engine speed > 8000rpm), abnormal data is packaged separately into "abnormal data temporary package", and normal data is packaged separately into "vehicle condition data package", both types of data packages are marked "data type: OBD II - vehicle condition" and enter different on-chain queues respectively.

[0049] (3) Manual data entry: Supports single data entry on Web / APP (the form includes required fields such as "maintenance time, project, cost, and maintenance personnel ID") or batch import from Excel (the template presets "required fields on the chain", and import will fail if they are missing); After data entry is completed, the system automatically triggers on-chain format verification and pre-approval: ① Field validity verification (e.g., a pop-up prompt when maintenance cost < 0, automatic interception when the date format is not YYYY-MM-DD); ② Maintenance personnel ID verification (calls the consortium chain "maintenance personnel node registration contract" to confirm that the ID has been registered on the consensus layer node); After the verification is passed, the data generates a "maintenance detail data package" (including "data type: manual - maintenance" identifier and the signature of the data entry terminal), and if the verification fails, the error reason is returned (e.g., "maintenance personnel are not registered and cannot be entered").

[0050] Blockchain storage module 202: This module adopts a three-tier consortium blockchain architecture of "core layer - consensus layer - application adaptation layer", combined with fine-grained encryption and executable smart contracts, to solve the problems of "centralized risks in conventional blockchain storage, lack of linkage in contract execution, and untraceable data". The specific implementation is as follows: 1. Consortium blockchain layered architecture and node management: The layered architecture design is shown in Table 1 below: Table 1

[0051] Node management process: Node Admission: ① Enterprise nodes (repair shops / parts manufacturers) submit a scanned copy of their business license and an authorization letter from the OEM, while individual nodes (car owners) submit their ID card and vehicle registration certificate to the core layer "Node Review Contract"; ② The contract automatically distributes the materials to 4 core nodes, which complete the review within 72 hours and submit an "Agree / Reject" vote; ③ If ≥3 nodes agree, a "Node Admission Certificate" (including node ID and public key) is generated, and the node joins the corresponding layer (e.g., repair shop → consensus layer); If the review fails, a "Reason for Failure" is returned (e.g., "Missing OEM Authorization Letter").

[0052] Node Exit: Nodes must submit an exit application to the "Node Audit Contract" 72 hours in advance. The contract will notify the core layer to back up the data stored by the node (backup to 2 core nodes). After the backup is completed, the node will officially exit to avoid data loss.

[0053] 2. PBFT Consensus Mechanism Execution Process

[0054] For the "data packets" uploaded by the application adaptation layer, the consensus layer completes consensus and on-chain processing according to the following steps: (1) Master node election: The "round-robin election system" is adopted. Every predetermined time interval - for example, 10 minutes, one master node is randomly elected from the consensus node pool (which must meet the condition of "no consensus error in the past hour"). The master node is responsible for the data packet proposal of this consensus cycle.

[0055] (2) Proposal and preparation: The master node obtains the data packets to be agreed upon from the application adaptation layer (sorted by "data type priority", with parts data > abnormal vehicle condition data > maintenance data > regular vehicle condition data), generates a "consensus proposal" (including a list of data packets, a proposal timestamp, and the master node's signature), and broadcasts it to all consensus nodes.

[0056] (3) Node verification and voting: After receiving the proposal, each consensus node ① verifies the validity of the master node's signature (based on the master node's public key); ② verifies the integrity of the data packet (checks whether the SHA-256 digest is consistent with the original data); ③ verifies the legality of the data (if the accessory data needs to confirm that the manufacturer has filed it); if the verification is successful, it casts an "agree" vote; otherwise, it casts a "reject" vote and feeds back the voting results (including node signatures) to the master node.

[0057] (4) Result confirmation and on-chain: The master node counts the voting results. If ≥2 / 3 of the nodes vote "agree", the consensus is passed: ① Package the data package into a new block (including "the hash of the previous block, data digest, consensus node signature list, and timestamp"); ② Write the block into the chain of the corresponding data type (e.g., accessory data package → accessory chain, maintenance data package → maintenance chain); ③ Generate an "on-chain certificate" (including block number and block hash) and feed it back to the application adaptation layer; If less than 2 / 3 agree, the proposal fails and a new round of consensus is initiated by re-electing the master node.

[0058] 3. Encryption scheme and chain structure protection

[0059] Here, end-to-end encryption is used to achieve both "transmission encryption" and "storage encryption." During transmission encryption, data is encrypted using the TLS 1.3 protocol from the "data collection module → application adaptation layer" and from the "application adaptation layer → consensus layer," reducing handshake time by 50% compared to TLS 1.2 and preventing data interception and tampering during transmission. During storage encryption, ① before data packets are uploaded to the chain, AES-256 symmetric encryption is used (the key is managed by multiple nodes in the core layer), and the encrypted data contains only "ciphertext + data type identifier"; ② when a block is generated, the SHA-256 algorithm is used to generate a "block hash," and the hash of the previous block is written into the header of the current block, forming a "chain hash structure." If data in a block is tampered with, its hash value will change, causing the hash chain of all subsequent blocks to break. The system can immediately identify tampering behavior through a "real-time hash verification thread" (verifying the chain hash every 10 seconds) and trigger an alarm (such as pushing a "block tampering alarm" to the core layer nodes).

[0060] 4. Smart Contract Deployment and Execution Logic

[0061] The core layer of the consortium blockchain deploys three types of core smart contracts, all written in Solidity and authenticated by core nodes. The execution results of these contracts are irreversible. Specifically, these include: (4-1) Parts Verification Contract: The contract is deployed in a core layer, with four core nodes jointly signing the deployment. The contract is triggered automatically after the application adaptation layer uploads the "parts data package." The contract executes through the following process: ① The contract calls the national CA authority's interface via an "off-chain API gateway" (TLS 1.3 encryption), passing in the "parts manufacturer's digital certificate and parts number"; ② The CA authority returns a "certificate verification result" (including the CA signature), and the contract verifies the validity of the CA signature (based on the CA public key); ③ Verification successful: The contract generates a "parts on-chain permission" (including the contract signature), allowing the parts data package to enter the consensus process; ④ Verification failed: The contract generates a "rejection log" (including the rejection time, parts number, and the failure reason returned by the CA, such as "certificate expired"), writes it to an "abnormal data block," and pushes a "parts verification failed, unable to be on-chain" message to the data collection terminal.

[0062] (4-2) Maintenance Reminder Contract: The contract is deployed in the application adaptation layer and is bound to the vehicle owner node ID, making it visible only to the corresponding vehicle owner. The contract has preset threshold values. Specifically, during contract initialization, a "Vehicle Model-Maintenance Threshold" mapping table is read from the "OEM Vehicle Configuration Block" (core layer storage). For example, "Tesla Model 3: Oil change interval 10,000 km / 6 months, brake pad wear thickness ≤ 3mm" is stored in the contract state area.

[0063] The maintenance reminder contract is implemented through the following process: ① The OBD II interface uploads a "vehicle condition data package" every second, and the application adaptation layer automatically calls the contract; ② The contract extracts key data such as "vehicle mileage and brake pad wear thickness" and compares them with preset thresholds; ③ If the threshold is triggered (e.g., mileage reaches 10,000 kilometers, or wear thickness ≤ 3mm): a. A "reminder transaction" is generated (including the owner node ID, reminder content, threshold basis, and contract signature); b. After consensus is achieved by submitting to the consensus layer, the transaction is written to the "reminder record block"; c. A reminder is pushed to the owner through the "off-chain push gateway" (connected to the APP / SMS interface) (e.g., "Your vehicle's brake pads are worn to 2.8mm, it is recommended to replace them within 30 days"); ④ After the owner views the reminder through the APP, they click "read and confirm". The APP sends a "confirmation instruction" (including the owner's signature) to the contract, the contract updates its status to "confirmed", and records the confirmation time (written into the block).

[0064] (4-3) Data Update Contract: The contract is deployed at the consensus layer, requiring at least 3 nodes in the consensus node pool to sign for deployment. Triggering conditions for the contract include, for example, when maintenance personnel initiate a "Maintenance Record Supplement / Modification Request" (such as supplementing maintenance notes or uploading inspection reports) through the "Data Query Module".

[0065] The contract is implemented through the following process: ① The contract verifies the maintenance personnel's permissions (by calling the "RBAC Permission Contract" to confirm that the personnel ID can only modify "maintenance records they participated in"); ② Verification passed: modification is allowed, and a "modification record" is generated (including "original data summary, new data, reason for modification, and maintenance personnel signature"); ③ The "modification record + original data" are packaged into an "update block," submitted to the consensus layer to complete consensus, and then written to the maintenance chain (the original data is not deleted, and the modification trace is retained); ④ Verification failed (e.g., the maintenance personnel attempted to modify someone else's record): the contract rejects the request, generates an "excessive permission log," writes it to the "abnormal operation block," and pushes a "no permission to modify this record" message to the maintenance personnel's terminal.

[0066] Data Query Module 203: This module relies on an "on-chain data aggregation engine" to achieve integrated querying of "tag scanning - multi-chain association - result visualization," solving the problems of "scattered data and low traceability efficiency in conventional queries." In other words, it achieves efficient traceability through on-chain aggregation combined with multi-dimensional filtering. In module 203, (1) Query method and on-chain data association Tag Scan Query: Users scan the "Vehicle VIN code (17 digits)" or "parts RFID tag" via a mobile terminal—such as an app on their phone—triggering the following process: ① The app sends the scanned "VIN code / RFID number + user node signature" to the "query gateway"; ② The query gateway calls the "on-chain data aggregation engine," which initiates multi-chain queries based on the "identifier-chain" mapping relationship: a. Scanning the VIN code → simultaneously querying the "maintenance chain (get maintenance records), vehicle condition chain (get real-time vehicle condition), and reminder chain (get unread reminders)"; b. Scanning the RFID tag → simultaneously querying the "parts chain (get parts manufacturer, quality inspection report), and maintenance chain (get the replacement record of the part)"; ③ The aggregation engine receives the "block data" returned by each chain (based on block number location) and verifies the data integrity (verifying the SHA-256 digest); ④ The data is integrated into a "structured result" (including the block number of each link) and returned to the app within 1 second.

[0067] Multi-condition filtering query: Users input "multi-condition combinations" (e.g., "time range: 2023.01-2023.12, vehicle type: Tesla Model 3, maintenance item: oil change, parts brand: Shell") via Web / APP. The query process is as follows: ① The query gateway converts the filtering conditions into "on-chain query instructions" (e.g., "maintenance chain. maintenance time ∈ [2023-01-01, 2023-12-31] AND maintenance chain. vehicle type = Tesla Model 3"); ② The instruction is sent to the aggregation engine, which quickly locates the target block through "on-chain index nodes" (application adaptation layer components that store index information of each chain's data, such as "vehicle type - block number mapping"); ③ After extracting the data within the block, it is sorted by "maintenance time ascending / descending order" to filter out privacy data that cannot be viewed by the user (e.g., the repairman's mobile phone number is anonymized to "138"). 1234”); ④ Return the filtered results and support “Click to view details” (e.g., clicking “oil change” will show the part’s RFID number, replacement image summary, and corresponding vehicle condition data).

[0068] (2) Results presentation and traceability design: 1. Basic Information List: Displays "Maintenance Time, Item, Cost, Repair Personnel (Anonymized), On-Chain Time, Block Number". The block number can be clicked to jump to the "Blockchain Explorer" (a built-in tool that can view complete block information, such as consensus node signature and data digest).

[0069] 2. Parts Traceability Details: Click on “Parts Name” to display “Manufacturer Name (link to manufacturer registration page), production date, quality inspection report (including a link to the national quality inspection platform, click to view the original report), and before / after replacement images (click to view high-definition images, with SHA-256 digests marked below the images, which can be compared with the digests stored on the blockchain)”.

[0070] 3. Data visualization charts: ① Line chart showing "Changes in maintenance costs over the past year" (horizontal axis represents months, vertical axis represents costs, and data points are labeled with the corresponding maintenance block number); ② Bar chart showing "Percentage of different maintenance items" (each bar is labeled with the number of maintenance sessions for that item and the block number of the most recent maintenance session); ③ Trend chart showing "Changes in brake pad wear over the past 3 months" (the normal range is marked as 80-100°C, abnormal data points are marked in red, and associated with the corresponding abnormal vehicle condition block).

[0071] Access Control Module 204

[0072] This module is based on the "Five-Level Role-Based Access Control (RBAC) Model." Combined with on-chain permission contracts and multi-node privacy authorization, this module addresses the problems of "coarse conventional permission management, easy leakage of privacy data, and low efficiency in permission adjustment." In other words, it enables fine-grained control through RBAC combined with on-chain contracts.

[0073] (1) The RBAC five-level roles and on-chain opcodes are defined as follows: The core layer of the consortium blockchain deploys the "RBAC permission contract," defining the "on-chain opcodes" and corresponding permission scopes for five levels of roles, ensuring that the permission rules are immutable, as shown in the table below:

[0074] (2) On-chain permission verification process: Taking "vehicle owner querying their own maintenance records" as an example, permission verification is achieved through "contract linkage" to ensure no unauthorized access. The specific process is as follows: (i) The vehicle owner initiates a query request through the APP, carrying "the owner's private key signature, the target maintenance time range, and the VIN code".

[0075] (ii) After receiving the request, the "Maintenance Record Query Contract" ① calls the "Signature Verification Contract" to verify the validity of the signature based on the vehicle owner node's public key (to prevent forged requests); ② calls the "RBAC Permission Contract" to check whether the requesting node's opcode is "01" (vehicle owner role) and confirms that the query contract can be called.

[0076] (iii) After the permission verification is successful, the contract calls "VIN code binding contract" to confirm that the VIN code has been bound to the vehicle owner node ID (to prevent querying other people's vehicles).

[0077] (iv) The contract extracts "blocks bound to the VIN code and within the time frame" from the maintenance chain, and performs "privacy anonymization" on the data (e.g., replacing the maintenance personnel's mobile phone number with "138"). The query "1234" generates the query results and sends them to the app.

[0078] (v) If any step of the verification fails (such as invalid signature, mismatched opcode, or unbound VIN code), the contract generates a "permission denial log" (including request node ID, failure reason, and timestamp), writes it to the "abnormal operation block", and pushes a failure message to the APP.

[0079] (3) Dynamic adjustment of permissions and privacy authorization Dynamic permission adjustment: When a system administrator needs to adjust user permissions (e.g., "temporarily authorize the car owner to view the complete quality inspection report of a certain maintenance"), the process is as follows: ① The administrator initiates a "permission adjustment request" through the backend, carrying "the adjustment object ID, the adjustment content (e.g., "role 01 temporarily accesses the quality inspection report to view the contract"), the adjustment validity period (e.g., 24 hours), and the administrator's signature"; ② The request is submitted to the "permission adjustment contract", and the contract verifies the administrator's signature (based on the administrator's public key) and the operation code (must be "05"); ③ After the verification is successful, the contract generates a "temporary permission certificate" (including the validity period, adjustment content, and contract signature) and writes it into the "permission adjustment block"; ④ A "temporary permission effective notification" is pushed to the adjusted object. After the validity period expires, the contract automatically revoks the temporary permission and generates a "permission revocation log".

[0080] Multi-node authorization decryption of privacy data: When an administrator needs to view "complete privacy data of the vehicle owner (such as mobile phone number, ID card number)", a multi-node vote must be initiated through the "Privacy Authorization Contract": ① The administrator submits "reason for viewing (such as "verification of identity is required to handle vehicle owner complaints"), target vehicle owner ID, and administrator signature"; ② The contract pushes an "authorization vote request" to 4 core nodes, and the nodes submit "agree / reject" votes (including node signatures) within 24 hours; ③ If ≥3 nodes agree, the contract calls the core layer key management module, concatenates the AES-256 key, and decrypts the privacy data; ④ After the administrator views the data, the operation record (including viewing time and viewing content summary) is written to the "Privacy Operation Block", which is permanently traceable; if less than 3 nodes agree, the contract rejects the request and generates an "authorization failure log".

[0081] Health Management Module 205

[0082] This module, based on vehicle condition data and maintenance data on a consortium blockchain, enables real-time monitoring, anomaly alerts, and performance visualization, addressing the issues of limited functionality and unreliable data in conventional health management. In other words, it achieves real-time monitoring and alerts through on-chain data-driven solutions. The specific implementation details are explained below.

[0083] First, this module includes real-time monitoring and anomaly marking. The system collects vehicle data in real time (once per second) through the "OBD II interface." After the data is uploaded to the blockchain: ① The "Vehicle Condition Monitoring Contract" (deployed in the application adaptation layer) automatically extracts key indicators such as "engine coolant temperature, brake disc wear thickness, and tire pressure"; ② It compares the data with the "OEM preset thresholds" (read from the "Vehicle Configuration Block," such as engine coolant temperature within the normal range of 80-100℃, brake disc wear within the normal range of ≥3mm, and tire pressure within the normal range of 220-250kPa); ③ If the indicators exceed the normal range, the contract marks the data as "abnormal data" and writes it to the "Vehicle Condition Anomaly Block" (including "abnormal indicator, collection time, VIN code, and contract signature"); ④ At the same time, an "abnormal data notification" is triggered and pushed to the repair shop node (the vehicle's usual repair shop) and the owner's APP.

[0084] Secondly, this module includes anomaly warning and linkage services. When "abnormal data persists for 5 minutes (the duration can be modified in the 'Warning Configuration Contract')," the "Warning Contract" is triggered to execute: ① The contract generates a "Warning Work Order" (including "abnormal indicators (e.g., brake disc wear 2.8mm), risk level (medium), recommended measures (replace within 30 days), and a list of nearby repair shops (extracted from the 'Repair Shop Node Block', including distance, rating, and contact information)"); ② After the "Warning Work Order" is submitted to the consensus layer and consensus is achieved, it is written to the "Warning Record Block"; ③ The warning is pushed to the car owner via the APP (supporting both "pop-up window + SMS" reminders). Clicking the warning allows the view of the "block number corresponding to the abnormal data" and the "repair shop navigation link"; ④ If the car owner clicks "Schedule Repair," the APP automatically pushes a "Schedule Request" to the target repair shop node. After the repair shop confirms, the appointment record is written to the "Repair Appointment Block."

[0085] Secondly, this module includes performance visualization and comprehensive scoring. Comprehensive performance scoring is achieved through performance trend visualization. In performance trend visualization, the system generates visual charts based on on-chain "vehicle condition data for the past 3 months and maintenance data for the past 6 months": ① A timeline chart showing "engine power changes" (horizontal axis for date, vertical axis for power, with maintenance time points and corresponding block numbers marked); ② A bar chart showing "brake distance changes for the past 6 months" (each bar is marked with braking distance and the corresponding vehicle condition data block number); ③ Data points in the charts are marked with "green (normal), yellow (warning), and red (abnormal)," and hovering the mouse over them displays "index value, collection time, and whether it is on-chain (including block number)." The comprehensive performance rating can be implemented using the following model: On the 1st of each month, the "Performance Rating Contract" (deployed in the core layer) automatically calculates the vehicle's comprehensive rating: ① Extracts on-chain "engine performance data (30% weight), braking system data (25% weight), fuel consumption data (25% weight), and tire condition data (20% weight)"; ② Calculates the score for each dimension according to the principle of "full marks for normal indicators and deductions for abnormal indicators based on deviation ratio"; ③ Total score = score of each dimension × weight, with a maximum score of 100 (80-100 is excellent, 60-79 is good, and <60 requires maintenance); ④ The rating result is written to the "Performance Rating Block" (including "rating basis and block number of data source for each dimension") and pushed to the car owner's APP. The car owner can click "View Details" to verify the rating logic and on-chain data.

[0086] Data Analysis and Reporting Module 206

[0087] This module achieves a closed loop of "historical data extraction from the blockchain - model training - prediction results fed back to the blockchain," solving the problems of "unreliable data in conventional data analysis and lack of traceability in prediction results." In other words, it enables fault prediction and reliable reporting through the integration of blockchain and AI.

[0088] Module 206 may include a machine learning fault prediction submodule, which is supported by blockchain data. On-chain historical data extraction: ① The "Data Extraction Contract" (deployed in the application adaptation layer) extracts historical data from 2020-2023 (covering 10 mainstream vehicle models, totaling 100,000 records) from the "Maintenance Chain, Vehicle Condition Chain, and Anomaly Chain." During extraction, "privacy-free" processing is automatically performed (deleting owner's personal information, retaining VIN code hash, vehicle model, and data value); ② Data is sent to the model training end via an "encrypted transmission channel" (AES-256 encryption), simultaneously generating a "Data Extraction Log" (including extraction block number, data volume, and extraction time), which is written to the "Analysis Data Block."

[0089] Data Preprocessing and Model Training: ① Data Cleaning: Outliers were removed (e.g., negative brake disc wear thickness, based on the "Outlier Data Block" marker), and missing values ​​were filled with the "Average Value of the Same Model on the Chain" (the average value of this indicator for the same model was read from the "Model Summary Block"); ② Feature Selection: Four types of input features were identified: "Brake disc wear rate (mm / 1000km), engine idle speed fluctuation (rpm), engine oil contamination level (API level), and driving road condition ratio (highway / urban, calculated from OBD II speed data)"; ③ Model Training: A random forest algorithm was used to construct 100 decision trees (maximum depth 15 layers), with the training set accounting for 80% (randomly selected from the extracted data) and the test set accounting for 20%; the accuracy was evaluated using MAE (Mean Absolute Error) and MSE (Mean Squared Error), ensuring MAE ≤ 0.1mm and MSE ≤ 0.02mm. 2 .

[0090] Fault prediction and result feedback: ① Input current vehicle data (e.g., "brake disc wear rate 0.2mm / 1000km, current thickness 2.8mm"), the model outputs "remaining life (5000km), fault risk (15%), and recommended measures (replace within 5000km)"; ② Package the prediction results into a "prediction result package" (including "VIN code, feature data summary, predicted value, model version number, and training end signature"); ③ Submit to the consensus layer through the "result feedback contract", and write the "prediction result block" (including block number and consensus node signature) after consensus is passed; ④ Generate a "prediction report" (including results and on-chain block number) and push it to the car owner's APP. The car owner can verify the credibility of the data source of the prediction results through the block number.

[0091] Then, module 206 also implements report generation and traceability design. In this regard, report types and content may involve, for example: (i) Vehicle performance evaluation report: including “overall performance score, scores for each dimension (engine / brake / fuel consumption / tires), scoring basis (related performance score block number), performance trend analysis (with visualization charts and data source blocks)”.

[0092] (ii) Fault prediction report: including "predicted fault type (e.g., excessive brake pad wear), remaining life, fault risk probability, characteristic data details (e.g., idle speed fluctuation value), suggested countermeasures, and prediction result block number".

[0093] (iii) Maintenance Recommendation Report: including "Recommended maintenance time (based on maintenance cycle threshold and current mileage), recommended maintenance items (based on abnormal vehicle condition data), recommended parts brands (based on parts traceability data of the same model and related parts chain blocks), and estimated cost (based on the summary data of maintenance costs of the same model in the past year)".

[0094] Furthermore, the reports can be exported and are traceable. For example, optionally, reports can be downloaded in PDF and Excel formats and viewed directly within a mobile app. All report homepages include headings such as "Data Source: Blockchain Block XXX-XXX," "Generation Time," and "Report Hash (SHA-256)." Users can input the report hash using the "Report Verification Tool" (built-in function) to verify its consistency with the hash of the on-chain "Report Evidence Block" (associated with the prediction result block / performance score block), ensuring the report has not been tampered with.

[0095] According to embodiments of the present invention, a trusted management solution for automobile maintenance data combining consortium blockchain and dual smart contracts can be realized.

[0096] Specifically, by constructing a consortium blockchain comprising car owners, repair shops, parts manufacturers, and OEMs, and employing the PBFT consensus mechanism and AES-256 encrypted storage, combined with a "parts verification contract (connecting to national CA institutions)" and a "maintenance reminder contract (based on threshold triggering)," automatic data verification, on-chain processing, and alerts are achieved. In this regard, addressing the shortcomings of traditional technologies such as "centralized review and lack of automatic alerts," the embodiments of this invention reduce the data tampering rate from 10% to 0%, shorten the data on-chain review time from 30 minutes to 500ms, and improve the maintenance reminder response speed by 100 times.

[0097] Furthermore, according to the technical solution of this invention, a multi-feature random forest is used to construct an automotive fault prediction model. Technically, using "parts wear rate, engine idling speed fluctuation, engine oil contamination level, and driving road conditions" as input features, a random forest model with 100 decision trees is constructed. The accuracy is optimized using MAE (≤0.1mm) and MSE (≤0.02mm²), enabling life prediction of key components such as brake pads and engine oil. Addressing the shortcomings of traditional technologies that lack fault prediction capabilities, this solution improves fault prediction accuracy to 92%, a 53% increase compared to the industry's simple statistical model (60% accuracy), helping car owners prevent faults in advance and reducing average maintenance costs by 2000 yuan per vehicle per year.

[0098] Furthermore, according to the technical solution of this invention, a fine-grained permission management system for different participants is achieved by adopting a five-level role-based access control (RBAC). Specifically, based on the RBAC model, different participants are designed with five levels of roles: vehicle owner, repair personnel, parts manufacturers, OEMs, and administrators, defining a "query-modify-manage" permission matrix. Under the constraints on the participants, dynamic adjustment and audit logs can be achieved, and privacy data requires authorization from three core nodes to view. In this regard, compared with the shortcomings of traditional technologies such as "two-level permissions and an 8% privacy leakage rate," the embodiment of this invention achieves "vehicle owners can only see their own data, and OEMs can only see anonymous aggregated data," reducing the privacy leakage rate to 0% and shortening the permission adjustment time from 24 hours to 5 minutes.

[0099] Furthermore, the technical solution according to embodiments of the present invention enables a visualized traceability solution that integrates multi-source data. Specifically, by integrating multi-source data from RFID (parts traceability), OBD II (real-time vehicle status), and manual entry (maintenance details), it supports "tag scanning + multi-condition filtering" queries, displays results in a "list + chart + traceability link" format, and links parts information to the national quality inspection platform. In this regard, compared to the shortcomings of traditional technologies such as "inconsistent data formats and low traceability efficiency," this solution's data format compatibility covers more than 95% of mainstream vehicle models, reducing parts traceability time from 2 hours to 1 second, and query response time from 10 seconds to 0.8 seconds.

[0100] Figure 3 An exemplary system architecture 300 for a vehicle maintenance management device to which embodiments of the present invention can be applied is shown.

[0101] like Figure 3 As shown, system architecture 300 may include terminal devices 301, 302, and 303, a network 304, and a server 305. Network 304 serves as the medium for providing communication links between terminal devices 301, 302, and 303 and server 305. Network 304 may include various connection types, such as wired or wireless communication links, or fiber optic cables, etc.

[0102] Users can use terminal devices 301, 302, and 303 to interact with server 305 via network 304 to receive or send messages, etc. Various communication client applications can be installed on terminal devices 301, 302, and 303, such as shopping applications, web browser applications, search applications, instant messaging tools, email clients, social media platform software, etc. (for example only).

[0103] Terminal devices 301, 302, and 303 can be various electronic devices with displays and web browsing capabilities, including but not limited to smartphones, tablets, laptops, and desktop computers.

[0104] Server 305 can be a server that provides various services, such as a backend management server that supports shopping websites browsed by users using terminal devices 301, 302, and 303 (for example only). The backend management server can analyze and process data such as received product information query requests, and feed back the processing results (such as target push information and product information - for example only) to the terminal devices.

[0105] It should be understood that Figure 3 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.

[0106] The following is for reference. Figure 4 It shows a schematic diagram of the structure of a computer system 400 suitable for implementing a terminal device of the present invention. Figure 4 The terminal device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of the present invention.

[0107] like Figure 4 As shown, the computer system 400 includes a central processing unit (CPU) 401, which can perform various appropriate actions and processes based on programs stored in read-only memory (ROM) 402 or programs loaded from storage section 408 into random access memory (RAM) 403. The RAM 403 also stores various programs and data required for the operation of the system 400. The CPU 401, ROM 402, and RAM 403 are interconnected via a bus 404. An input / output (I / O) interface 405 is also connected to the bus 404.

[0108] The following components are connected to I / O interface 405: an input section 406 including a keyboard, mouse, etc.; an output section 407 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 408 including a hard disk, etc.; and a communication section 409 including a network interface card such as a LAN card, modem, etc. The communication section 409 performs communication processing via a network such as the Internet. Drive 410 is also connected to I / O interface 405 as needed. Removable media 411, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 410 as needed so that computer programs read from them can be installed into storage section 408 as needed.

[0109] In particular, according to the embodiments disclosed in this invention, the processes described above with reference to the schematic diagrams can be implemented as computer software programs. For example, embodiments disclosed in this invention include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for executing the system illustrated in the schematic diagrams. In such embodiments, the computer program can be downloaded and installed from a network via communication section 409, and / or installed from removable medium 411. When the computer program is executed by central processing unit (CPU) 401, it performs the functions defined above in the system of this invention.

[0110] It should be noted that the computer-readable medium shown in this invention can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this invention, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this invention, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media can also be any computer-readable medium other than computer-readable storage media, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

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

[0112] The "modules" described in the embodiments of the present invention can be implemented in software or hardware. The described "modules" can also be located in a processor. For example, an embodiment of the present invention can be described as a server terminal, including: one or more processors; and a storage device for storing one or more programs, which, when executed by the one or more processors, cause the one or more processors to operate or implement the vehicle maintenance management system as described above.

[0113] In another aspect, the present invention also provides a computer-readable medium, which may be included in the device described in the above embodiments; or it may exist independently and not assembled into the device. The computer-readable medium carries one or more programs that, when executed by the device, operate or implement the vehicle maintenance management system as described above.

[0114] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can occur depending on design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A vehicle maintenance management method based on blockchain, characterized in that, include: The system obtains the information required for vehicle maintenance through a data interface and generates data packets based on that information. The data packets are processed by converting them into a unified blockchain format. In response to a user's query request, the system initiates a multi-chain query on the data packet by calling the on-chain data aggregation engine, and enables the queried information to be displayed to the user. as well as Different on-chain opcodes and corresponding permission ranges are assigned to the participants related to the vehicle. The permission range of each participant can be dynamically adjusted under the predetermined constraints set on other participants.

2. The vehicle maintenance and management method according to claim 1, characterized in that, The information acquisition process includes at least one of the following: RFID scanning, OBD II interface acquisition, or manual entry by the client.

3. The vehicle maintenance and management method according to claim 1, characterized in that, The participants include one or more of the following: vehicle owners, repair personnel, parts manufacturers, OEMs, and system administrators.

4. The vehicle maintenance and management method according to claim 1, characterized in that... Also includes: Vehicle condition is monitored based on real-time collected data related to vehicle operation. Specifically, when a vehicle's condition is confirmed to fall into an abnormal range, an abnormal data notification that includes a vehicle condition warning is pushed to both the repair shop node and the vehicle owner node.

5. The vehicle maintenance and management method according to claim 1, characterized in that... Also includes: Historical vehicle-related data is extracted from the blockchain and sent to the model training terminal, which is configured to perform data cleaning, feature selection, and model training. Generate at least one of the following reports based on information related to the current condition of the vehicle: a vehicle performance assessment report, a vehicle fault prediction report, or a vehicle maintenance recommendation report.

6. The vehicle maintenance and management method according to claim 2, characterized in that: During the OBD II interface data acquisition process, the acquired data is automatically converted into an on-chain structured format and transmitted to the application adaptation layer. In this on-chain structured format, each data entry includes a VIN (Vehicle Identifier), data items, a numerical value, a data acquisition timestamp, and a terminal signature. The application adaptation layer performs range verification on the received data. Based on the result of the range verification, abnormal data is packaged into a temporary abnormal data package, and normal data is packaged into a vehicle condition data package. The temporary abnormal data package and the vehicle condition data package are then transmitted into different on-chain queues.

7. The vehicle maintenance and management method according to claim 1, characterized in that, For uploaded data packets, consensus and on-chain processing are completed through the following operations: A master node is randomly elected from the consensus node pool at predetermined time intervals. The master node obtains the data packets to be used for consensus operations from the application adaptation layer, generates a consensus proposal based on the data packets, and broadcasts the consensus proposal to all consensus nodes. The consensus proposal includes a list of data packets, a proposal timestamp, and the master node's signature. After receiving a proposal, each consensus node verifies the validity of the master node's signature, the integrity of the data packet, and the legality of the data, and then feeds back the verification results of each node to the master node. When the statistical value of the verification result reaches a predetermined proportion, it is determined that a consensus has been reached; when the statistical value of the verification result does not reach the predetermined proportion, it is determined that no consensus has been reached.

8. The vehicle maintenance and management method according to claim 1, characterized in that... Also includes: A core smart contract is deployed in a blockchain-based storage device to enable participants to perform access operations. This core smart contract is written in Solidity and has core node signature authentication. The core smart contract includes at least one of the following: The vehicle parts verification contract is automatically invoked after the application adaptation layer uploads the parts data package to authenticate the parts' validity. The vehicle maintenance reminder contract is automatically invoked after a vehicle condition data packet is uploaded via the OBD II interface. This contract extracts information related to the vehicle's predetermined type and determines whether to send a reminder to the client based on a comparison of the extracted information and a threshold. A vehicle maintenance data update contract, wherein the maintenance personnel initiate a request to supplement or modify the vehicle's maintenance records, and, provided that the maintenance personnel's permissions meet predetermined requirements, the modification and update of the vehicle's maintenance records are permitted.

9. The vehicle maintenance and management method according to claim 3, characterized in that, The participants include vehicle owners, repair personnel, parts manufacturers, OEMs, and system administrators, and each participant is assigned different operating permissions. The vehicle owner is limited to having access to at least one of the following contracts: maintenance record query contract, parts traceability contract, vehicle condition query contract, and prediction result viewing contract. The maintenance personnel are limited to those who can access at least one of the following contracts: maintenance record modification contract, parts on-chain contract, and maintenance data entry contract in which they participated. The parts manufacturer is limited to being able to invoke at least one of the parts traceability query contract and the parts data update contract in which the manufacturer participates. The OEM is limited to being able to access at least one of the following: vehicle model aggregated data contract, fault statistics contract, and threshold configuration contract. The system administrator is limited to having the ability to invoke at least one of the following contracts: node audit contract, permission adjustment contract, full data query contract, and privacy authorization contract.

10. The vehicle maintenance and management method according to claim 1, characterized in that, The query includes: performing the query using tag scanning or multi-condition filtering, wherein... In the tag scanning query, the user scans the VIN code, which serves as the unique identifier of the vehicle, or the RFID tag identifying the vehicle accessory using a mobile terminal to obtain information related to the vehicle or the accessory. In the multi-condition filtering query, the user inputs multiple condition combinations through a mobile terminal to obtain information related to the vehicle or accessories that meets the conditions.

11. A vehicle maintenance management device based on blockchain, characterized in that, include: A data collection module acquires information required for vehicle maintenance through a data interface and generates data packets based on that information. A blockchain storage module that processes data packets by converting them into a unified format for the consortium blockchain. The data query module responds to a user's query request by invoking an on-chain data aggregation engine to initiate a multi-chain query on the data packet and display the queried information to the user. as well as The permission management module assigns different on-chain operation codes and corresponding permission ranges to participants related to the vehicle. The permission range of each participant can be dynamically adjusted under predetermined constraints set on other participants.

12. A server terminal, characterized in that, include: One or more processors; Storage device for storing one or more programs. When the one or more programs are executed by the one or more processors, the one or more processors perform operations to operate the vehicle maintenance management method as described in any one of claims 1-10.

13. A computer-readable medium having a computer program stored thereon, characterized in that, The program is executed by a processor to operate the vehicle maintenance management method as described in any one of claims 1-10.

Images