SOVD decentralized diagnosis method and system based on game theory incentive

Abstract

The application discloses a SOVD decentralized diagnosis method and system based on game theory incentive, which comprises generating a first phenomenon feature hash based on a novel mode event detected in a historical signal of a first vehicle, if a second phenomenon feature hash with a similarity higher than a preset threshold to the first phenomenon feature hash is queried from real-time signals of a second vehicle based on a SOVD server, obtaining a solution evidence, verifying the solution evidence and processing the verification result based on a game theory incentive method, if the solution evidence verification fails, making the second vehicle submit a guarantee token to a diagnosis blockchain, and if the verification passes, according to a contribution weight coefficient of the second vehicle, making the second vehicle extract a reward token from the diagnosis blockchain. The application can greatly shorten the long tail fault diagnosis cycle, eliminate the centralized single point fault and the computing power bottleneck, realize the SOVD value exchange semantics, and form a diagnosis positive incentive closed loop.

Description

Technical Field

[0001] This invention relates to the field of vehicle diagnostic technology, specifically to a decentralized diagnostic method and system for SOVD based on game theory incentives. Background Technology

[0002] The current SOVD (Service-Oriented Vehicle Diagnostics) system adopts a centralized diagnostic paradigm: vehicles act as "producers" of diagnostic data, while the cloud or service stations act as "consumers" and "analysts." Diagnostic rules, fault databases, and repair solutions are centrally defined and maintained by expert teams from OEMs or Tier 1 suppliers. In recent years, some studies have proposed fleet anomaly detection methods based on collective intelligence perception, which collect and statistically analyze data from a large number of vehicles.

[0003] At the protocol level, the SOVD standard already supports vehicles reporting identification data to the server and supports remote clients invoking diagnostic services. ISO 17978-3 specifies a service discovery mechanism, allowing clients to discover the diagnostic capabilities supported by the server at runtime. However, the "authoritative source" of all diagnostic logic remains a centralized cloud or pre-built rule base, and existing technologies have the following problems: Question 1: Diagnostic experience with long-tail faults cannot be efficiently reused. Rare faults (such as occasional restarts of a certain model of lidar at -15°C and during bumpy driving) are difficult to diagnose with high confidence based on diagnostic data from a single vehicle. The first owner to encounter this fault must go through a long period of "multiple visits to the shop, replacement attempts, manufacturer analysis, and announcements," while other owners cannot benefit in a timely manner, creating a time silo of diagnostic experience.

[0004] Question 2: Lack of economic incentives leads to low quality of diagnostic data. Currently, vehicles passively report data, and users have no incentive to provide high-quality, timely diagnostic feedback. The diagnostic system cannot distinguish between "vehicles that diligently report data" and "vehicles that randomly report noisy data," resulting in the cloud model being contaminated by low-quality data. Furthermore, there is a lack of a two-way trust mechanism: vehicles are unaware whether the cloud is actually using their data, and the cloud cannot verify the authenticity of the data.

[0005] Question 3: A single cloud-based authority has single points of failure and computing power bottlenecks. All diagnostic requests converge to the OEM cloud, and cloud inference latency increases significantly when a fleet of millions of vehicles simultaneously requests complex diagnostic analyses. During cloud outages or network cutovers, vehicles lose access to fresh diagnostic knowledge and can only rely on factory-preset static rules. Diagnostic knowledge bases between different OEMs are isolated, and cross-brand fault modes cannot be shared.

[0006] Question 4: The existing SOVD protocol lacks value exchange semantics. The SOVD protocol itself is an information exchange protocol and does not contain value exchange semantics. It cannot form a self-organizing market where "vehicle A discovers a certain fault mode, packages the diagnostic evidence, and sells it to other vehicles or repair shops that need the information". Summary of the Invention

[0007] To address the problems existing in the prior art, this invention provides a decentralized diagnostic method and system for SOVD based on game theory incentives, which can significantly shorten the diagnosis cycle of long-tail faults, eliminate centralized single-point faults and computing power bottlenecks, realize SOVD value exchange semantics, and form a positive incentive closed loop for diagnosis.

[0008] Other features and advantages of this application will become apparent from the following detailed description, or may be learned in part from practice of this application.

[0009] According to a first aspect of this application, a decentralized diagnostic method for SOVD based on game theory incentives is provided, comprising: Based on the novel pattern events detected in the historical signals of the first vehicle, a first phenomenon feature hash is generated; If, based on the SOVD server, a second phenomenon feature hash with a similarity higher than a preset threshold to the first phenomenon feature hash is found in the real-time signal of the second vehicle, the solution is obtained and stored. The solution is verified and the verification result is processed based on a game theory incentive method. If the solution verification fails, the second vehicle submits a quality assurance token to the diagnostic blockchain. If the verification passes, the second vehicle extracts a reward token from the diagnostic blockchain based on its contribution weight coefficient.

[0010] In some embodiments of this application, based on the foregoing scheme, generating a first phenomenon feature hash based on novel pattern events detected in the historical signals of the first vehicle includes: Based on the novel pattern events detected in the historical signals of the first vehicle, relevant signals within the time window before and after the novel pattern events are collected to form an encrypted diagnostic evidence package. The encrypted diagnostic evidence package is then submitted to a distributed storage network, and a content identifier is returned. Based on the relevant signals within the time window before and after the novel pattern event, obtain the first phenomenon feature hash and signal fingerprint; Lock a first number of bounty tokens for the first vehicle, and write the content identifier, the first phenomenon feature hash, the signal fingerprint, the vehicle model software and hardware version hash, the timestamp, the information on seeking the same / similar cases or root cause solutions, and the first number of bounty tokens into the diagnostic blockchain.

[0011] In some embodiments of this application, based on the foregoing scheme, the method for obtaining the signal fingerprint is as follows: The relevant signal sequence within the time window before and after the novel pattern event is divided into several sub-segments according to a fixed sub-window length; For each segment, obtain statistics, including mean, variance, standard deviation, maximum value, minimum value, peak-to-peak value, kurtosis, skewness, and root mean square. Then, take the mean of the statistics across all segments to form a time-domain feature vector. Fast Fourier Transform is performed on the relevant signals within the time window before and after the novel mode event to extract the dominant frequency position, dominant frequency amplitude, spectral centroid, and spectral flatness of the spectrum, forming a frequency domain feature vector; The time-domain feature vector and the frequency-domain feature vector are concatenated to form a signal fingerprint; and / or, The method for obtaining the content identifier is as follows: For relevant signals within the time window before and after a novel pattern event, a cryptographic hash function is used to calculate the hash value, resulting in a fixed-length hash digest. The hash digest is encapsulated in a Multihash format, which includes a type, length, and value. Add the Multicodec identifier before Multihash; After adding the CID version number before the Multicodec identifier, it is converted into a readable string, which is the content identifier.

[0012] In some embodiments of this application, based on the aforementioned scheme and using an SOVD server, a second phenomenon feature hash with a similarity higher than a preset threshold to the first phenomenon feature hash is queried from the real-time signal of the second vehicle. The method is as follows: The first phenomenon feature hash, the signal fingerprint, and the vehicle model hardware and software version hash corresponding to the first vehicle are mapped to the key space of the DHT network through the Kademlia protocol, and several second vehicles are added to the DHT network. Based on the SOVD server, the phenomenon feature hash corresponding to the current phenomenon queried by the second vehicle and the first phenomenon feature hash are converted from binary to hexadecimal strings or integers respectively. The perceptual hash Hamming distance is obtained for the two hexadecimal strings or integers. The perceptual hash Hamming distance is the similarity. If the perceptual hash Hamming distance is greater than a preset threshold, the phenomenon feature hash corresponding to the current phenomenon is the second phenomenon feature hash, and the content identifier is returned.

[0013] In some embodiments of this application, based on the foregoing scheme, the method for generating the first phenomenon feature hash and the phenomenon feature hash corresponding to the current phenomenon is as follows: The signal waveform is divided into segments of fixed length, and each segment is preprocessed, namely, the removal of DC components and trend terms. For each preprocessed signal segment, perform discrete wavelet transform or short-time Fourier transform to extract the time-frequency domain feature vector of the signal. The time-frequency domain feature vector is reduced in dimension and compressed, and a binary hash sequence is generated by threshold comparison. The binary hash sequence is converted into a hexadecimal string or integer and used as the phenomenon feature hash of the signal waveform.

[0014] In some embodiments of this application, based on the foregoing scheme, the verification of the solution notarization and the processing of the verification result based on a game theory incentive method, if the solution notarization verification fails, then the second vehicle submits a warranty token to the diagnostic blockchain; if the verification passes, then a reward token is extracted from the diagnostic blockchain according to the contribution weight coefficient of the second vehicle, including: When the second vehicle is manufactured as a new car, a default reputation value is assigned. When the second vehicle reports the solution and evidence, a third number of guarantee tokens are pledged. If the solution submitted by the second vehicle passes the verification process, a reputation score is obtained, calculated using the following formula:

[0015] in, For credit score, To report probability estimates, For actual observation results, 1 represents verification passing and 0 represents verification failing; Based on the positive linear relationship between contribution weight coefficient and reputation score, the contribution weight coefficient of the second vehicle is obtained, and a second number of reward tokens are extracted from the diagnostic blockchain according to the contribution weight coefficient of the second vehicle. If the solution verification reported by the second vehicle fails, the second vehicle submits a third number of warranty tokens to the diagnostic blockchain.

[0016] In some embodiments of this application, based on the foregoing scheme, the method further includes performing false authentication on the encrypted diagnostic evidence package based on a verification node, wherein the verification node is a vehicle or a simulation environment, and the method is as follows: Based on the verification node, the third phenomenon hash value of the encrypted diagnostic evidence package is recalculated, and the hash value of the third phenomenon is compared with the hash value of the first phenomenon. If the comparison is inconsistent, it is determined that the first vehicle data has been tampered with, and the encrypted diagnostic evidence package is identified as false evidence; and / or, Based on the operating condition description in the encrypted diagnostic evidence package, an attempt is made to reproduce the same phenomenon at the verification node. If the phenomenon cannot be reproduced even with a preset number of vehicles or simulation environments, the encrypted diagnostic evidence package is deemed to be false evidence; and / or, After verifying the authenticity of the evidence through zero-knowledge proof, a vote is taken on whether the evidence is real or fake based on the verification nodes. The voting results are weighted and summarized according to the reputation score of the verification nodes. If the weighted reputation score exceeds the reputation score threshold, the encrypted diagnostic evidence package is considered to be fake evidence. If the encrypted diagnostic evidence package is determined to be false evidence, the first number of bounty Tokes shall be confiscated.

[0017] According to a second aspect of this application, a decentralized diagnostic system for SOVD based on game theory incentives is provided, comprising: The generation module is used to generate a first phenomenon feature hash based on novel pattern events detected in the historical signals of the first vehicle; The acquisition module is used to acquire the solution evidence when, based on the SOVD server, a second phenomenon feature hash with a similarity higher than a preset threshold is found in the real-time signal of the second vehicle. The verification module is used to verify the solution proof and process the verification result based on the game theory incentive method. If the solution proof verification fails, the second vehicle submits a quality assurance token to the diagnostic blockchain. If the verification passes, the second vehicle extracts a reward token from the diagnostic blockchain according to the contribution weight coefficient of the second vehicle.

[0018] According to a third aspect of this application, a computer-readable storage medium is provided that stores a computer program thereon, the computer program including executable instructions that, when executed by a processor, implement the method described above.

[0019] According to a fourth aspect of this application, an electronic device is provided, comprising: One or more processors; A memory for storing executable instructions of the processor, which, when executed by the one or more processors, cause the one or more processors to implement the method described above.

[0020] The beneficial effects of this application are as follows: (1) The SOVD decentralized diagnostic method and system based on game theory incentives provided in this application greatly shortens the diagnostic cycle of long-tail faults. It enables vehicles that encounter rare faults to quickly collect similar cases of other vehicles through a reward. The evidence of group reproduction enables the statistical confidence of the fault mode to be established quickly without waiting for the manufacturer's complete analysis process.

[0021] (2) The SOVD decentralized diagnostic method and system based on game theory incentives provided in this application can self-purify the quality of diagnostic data. This application combines logarithmic odds scoring rules and staking penalty mechanism to make honest reporting a game equilibrium. The expected payoff of malicious nodes uploading noisy data is strictly negative, which makes this application have the ability to resist attacks and pollution.

[0022] (3) The SOVD decentralized diagnostic method and system based on game theory incentives provided in this application eliminates centralized single point of failure and computing power bottleneck. Diagnostic requests are routed through DHT distributed routing and do not rely on a single cloud. The vehicle runs diagnostic reasoning locally and only exchanges the minimum necessary evidence data. When the network or cloud is disconnected, the vehicle can still obtain fresh diagnostic knowledge from the DHT network.

[0023] (4) The SOVD decentralized diagnostic method and system based on game theory incentive provided in this application makes it possible to share fault experience across brands. Unified feature hashing and encrypted storage enable vehicles of different brands to share anonymized fault fingerprints. Common problems (such as batch defects of a certain shared parts supplier) can be collectively discovered without exposing trade secrets.

[0024] (5) This application provides a decentralized diagnostic method and system for SOVD based on game theory incentives. The direct feedback of data value forms a positive incentive loop. Vehicle owners (or fleet operators) can obtain Token revenue by contributing diagnostic data. Tokens can be used to purchase other diagnostic services or redeem repair discounts. High-quality data contributors gain higher reputation, and reputation further amplifies their revenue multiplier, forming a data flywheel.

[0025] It should be understood that the above general description and the following detailed description are merely exemplary and explanatory, and do not limit this application. Attached Figure Description

[0026] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this application, illustrate exemplary embodiments of the invention and are intended to explain the invention, but do not constitute an undue limitation thereof. In the drawings: Figure 1 This is a flowchart of a decentralized diagnostic method for SOVD based on game theory incentives according to the present invention; Figure 2 This is a schematic diagram of a decentralized diagnostic system for SOVD based on game theory incentives according to the present invention. Figure 3 This is a schematic diagram of an electronic device according to the present invention. Detailed Implementation

[0027] To make the objectives, features, and advantages of this invention more apparent and understandable, the technical solutions of the embodiments of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the embodiments described below are only some embodiments of this invention, and not all embodiments. Based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this invention.

[0028] It should be understood that the terms "comprising" and other similar expressions in the specification, claims, and accompanying drawings of this invention are intended to cover a non-exclusive inclusion, such as a process, method, system, or apparatus that includes a series of steps or units and is not limited to the listed steps or units. Furthermore, "first" and "second" are used to distinguish different objects and are not intended to describe a specific order.

[0029] According to the first aspect of this application, Figure 1 As shown in the figure, this embodiment provides a decentralized diagnostic method for SOVD based on game theory incentives, including: Step S1: Generate a first phenomenon feature hash based on the novel pattern events detected in the historical signals of the first vehicle.

[0030] In this embodiment, a novel pattern event is a phenomenon that cannot be matched by the local diagnostic rule base, or an edge case with a confidence level lower than a preset threshold.

[0031] In some embodiments of this example, generating a first phenomenon feature hash based on novel pattern events detected in the historical signals of the first vehicle includes: Based on the novel pattern events detected in the historical signals of the first vehicle, relevant signals within the time window before and after the novel pattern events are collected to form an encrypted diagnostic evidence package. The encrypted diagnostic evidence package is then submitted to a distributed storage network (such as IPFS), and a content identifier is returned. Based on the relevant signals within the time window before and after the novel pattern event, obtain the first phenomenon feature hash and signal fingerprint; A first number of bounty tokens are locked for the first vehicle, and the content identifier, the hash of the first phenomenon feature, the signal fingerprint, the hash of the software and hardware version of the vehicle corresponding to the first vehicle, the timestamp, the information of seeking the same / similar cases or root cause solutions, and the first number of bounty tokens are written into the diagnostic blockchain to form on-chain evidence. The historical signals of the first vehicle are not stored to protect privacy.

[0032] In this way, the hash of the first vehicle diagnostic evidence is written into the blockchain, and the evidence ontology (encrypted diagnostic evidence package) is stored in a distributed storage network.

[0033] In some embodiments of this example, the time window before and after the novel pattern event is automatically pruned based on causal relationships, rather than being fully recorded.

[0034] In some embodiments of this example, the method for obtaining the signal fingerprint is as follows: The relevant signal sequence within the time window before and after the novel pattern event is divided into several sub-segments according to a fixed sub-window length; For each segment, obtain statistics, including mean, variance, standard deviation, maximum value, minimum value, peak-to-peak value, kurtosis, skewness, and root mean square. Then, take the mean of the statistics across all segments to form a time-domain feature vector. Fast Fourier Transform is performed on the relevant signals within the time window before and after the novel mode event to extract the dominant frequency position, dominant frequency amplitude, spectral centroid, and spectral flatness of the spectrum, forming a frequency domain feature vector; The time-domain feature vector and the frequency-domain feature vector are concatenated to form a signal fingerprint.

[0035] In this embodiment, the type is the hash algorithm used to identify (e.g., the identifier for SHA2-256 is 0x12), the length is the byte length of the hash value (0x20 for SHA2-256, i.e., 32 bytes), and the value is the hash digest.

[0036] In some embodiments of this example, the Content Identifier (CID) is a unique identifier generated in IPFS based on the content itself. It does not represent the storage location of the content, but rather an address formed based on the cryptographic hash of the content. The method for obtaining the Content Identifier is as follows: For relevant signals within the time window before and after a novel pattern event, a cryptographic hash function is used to calculate the hash value, resulting in a fixed-length hash digest. The hash digest is encapsulated in a Multihash format, which includes a type, length, and value. Add the Multicodec identifier before Multihash to specify the encoding format of the content (e.g., 0x70 represents DAG-PB, which is the default MerkleDAG encoding format of IPFS). After adding the CID version number (0x00 for CIDv0, 0x01 for CIDv1) before the Multicodec identifier, the above binary data is converted into a readable string, which is the content identifier.

[0037] In this embodiment, a first number of bounty tokens is locked for the first vehicle. The first number is set by the publisher (first vehicle), and the system provides a recommended value for reference. The publisher can adjust it manually, but it must not be lower than the minimum bounty value MinToken preset by the system (default 50 tokens, configurable).

[0038] Step S2: If, based on the SOVD server, a second phenomenon feature hash with a similarity higher than a preset threshold to the first phenomenon feature hash is found in the real-time signal of the second vehicle, the solution is stored.

[0039] In some embodiments of this example, the method for querying the second phenomenon feature hash from the real-time signal of the second vehicle based on the SOVD server, which has a similarity to the first phenomenon feature hash higher than a preset threshold, is as follows: The first phenomenon feature hash, the signal fingerprint, and the vehicle model hardware and software version hash corresponding to the first vehicle are mapped to the key space of the DHT (Distributed Hash Table) network through the Kademlia protocol. Several second vehicles are added to the DHT network. Based on the diagnostic knowledge index of Kademlia DHT, distributed case matching with O(logN) complexity is achieved. If the second vehicle joining the DHT network queries the SOVD server and finds that the similarity between the phenomenon feature hash corresponding to the current phenomenon and the first phenomenon feature hash is higher than a preset threshold, then the phenomenon feature hash corresponding to the current phenomenon is the second phenomenon feature hash.

[0040] In some implementations of this embodiment, the perceptual hash algorithm is used to extract the first phenomenon feature hash and the phenomenon feature hash corresponding to the current phenomenon. The core idea of ​​perceptual hashing (pHash for short) is to convert the signal waveform into a fixed-length hash sequence, so that perceptually similar signal waveforms generate similar hash sequences (rather than cryptographic hashing which requires "a small change in input to a drastic change in output"). The specific method is as follows: The signal waveform is divided into segments of fixed length (e.g., each segment contains N sampling points, N=128 or 256), and each segment of the signal is preprocessed, which involves removing the DC component and trend term. Perform Discrete Wavelet Transform (DWT) or Short Time Fourier Transform (STFT) on each preprocessed signal segment to extract the time-frequency domain feature vector of the signal; The time-frequency domain feature vector is reduced in dimension and compressed, and a binary hash sequence is generated by threshold comparison. The binary hash sequence is converted into a hexadecimal string or integer and used as the phenomenon feature hash of the signal waveform.

[0041] In this embodiment, the wavelet transform method is to perform multi-level wavelet decomposition on each preprocessed signal segment, extract the detail coefficients (high-frequency components) and approximation coefficients (low-frequency components) of each level, and obtain the energy distribution characteristics of the signal at different scales; the frequency domain transform method is to perform Fast Fourier Transform (FFT) on each preprocessed signal segment, and extract the key frequency components in the spectrum (such as the top M frequency components with the largest amplitude and their amplitudes).

[0042] In this embodiment, the time-frequency domain feature vector is reduced in dimension and compressed, and a binary hash sequence is generated by threshold comparison, including: Calculate the mean or median of the time-frequency domain eigenvectors as eigenvalues; For each feature value, if the feature value is greater than the threshold, it is recorded as 1; if the feature value is less than or equal to the threshold, it is recorded as 0. The final result is a fixed-length binary hash sequence (such as 64-bit or 128-bit).

[0043] In some embodiments of this example, the method for obtaining the similarity between the first phenomenon feature hash and the phenomenon feature hash corresponding to the current phenomenon is as follows: Convert the first phenomenon feature hash and the phenomenon feature hash corresponding to the current phenomenon from binary to hexadecimal strings or integers respectively. Obtain the perceptual hash Hamming distance between the two hexadecimal strings or integers. The perceptual hash Hamming distance is the similarity. The smaller the perceptual hash Hamming distance, the higher the similarity. If the perceptual hash Hamming distance is greater than a preset threshold, then the phenomenon feature hash corresponding to the current phenomenon is the second phenomenon feature hash, and the content identifier is returned.

[0044] In some embodiments of this example, after obtaining the content identifier, the second vehicle retrieves the encrypted diagnostic evidence package from the IPFS network. Therefore, the CID obtained during the submission phase and the CID returned during the query phase point to the same stored content on the IPFS network, namely the encrypted diagnostic evidence package.

[0045] In this embodiment, vehicles from different OEMs (Original Equipment Manufacturers) can join the same diagnostic DHT network (which requires a standardized feature hash algorithm) to achieve cross-brand fault mode sharing, while encryption mechanisms protect the proprietary information of each OEM from being directly read.

[0046] Step S3: Verify the solution notarization and process the verification result based on the game theory incentive method. If the solution notarization verification fails, the second vehicle submits a quality assurance token to the diagnostic blockchain. If the verification passes, the second vehicle extracts a reward token from the diagnostic blockchain according to the contribution weight coefficient of the second vehicle.

[0047] In some embodiments of this example, the game theory incentive method is a reputation score acquisition method based on Bayesian truth discovery. The process involves verifying the solution's provenance and processing the verification result based on the game theory incentive method. If the solution's provenance verification fails, the second vehicle submits a warranty token to the diagnostic blockchain. If the verification passes, the second vehicle extracts a reward token from the diagnostic blockchain based on its contribution weight coefficient. This includes: When the second vehicle is manufactured as a new car, a default reputation value is assigned. When the second vehicle reports the solution and evidence, a third number of guarantee tokens are pledged. If the solution submitted by the second vehicle passes the verification process, a reputation score is obtained, calculated using the following formula:

[0048] in, For credit score, To report probability estimates, For actual observation results, 1 represents verification passing and 0 represents verification failing; Based on the positive linear relationship between contribution weight coefficient and reputation score, the contribution weight coefficient of the second vehicle is obtained, and a second number of reward tokens are extracted from the diagnostic blockchain according to the contribution weight coefficient of the second vehicle. If the solution verification reported by the second vehicle fails, the second vehicle submits a third number of warranty tokens to the diagnostic blockchain.

[0049] Thus, by adopting a reputation system with logarithmic odds scoring rules and staking penalties, honest reporting becomes the dominant strategy in the game.

[0050] In some implementations of this embodiment, high-reputation vehicles can post higher bounties, have priority routing for diagnostic service requests, and receive discounts on staking token fees; low-reputation vehicles have reduced weight for reported evidence and require higher staking amounts.

[0051] In some embodiments of this example, it further includes performing false authentication on the encrypted diagnostic evidence package based on a verification node, wherein the verification node is a vehicle or a simulation environment, and the method is as follows: Based on the verification node, the third phenomenon hash value of the encrypted diagnostic evidence package is recalculated, and the hash value of the third phenomenon is compared with the hash value of the first phenomenon. If the comparison is inconsistent, it is determined that the first vehicle data has been tampered with, and the encrypted diagnostic evidence package is identified as false evidence; and / or, Based on the operating condition description in the encrypted diagnostic evidence package, an attempt is made to reproduce the same phenomenon at the verification node. If the phenomenon cannot be reproduced even with a preset number of vehicles or simulation environments, the encrypted diagnostic evidence package is deemed to be false evidence; and / or, After confirming the authenticity of the evidence through zero-knowledge proof, a vote is taken on whether the evidence is real or fake based on the verification nodes. The voting results are weighted and summarized according to the reputation score of the verification nodes. If the weighted reputation score exceeds the reputation score threshold (e.g., 70%), the encrypted diagnostic evidence package is considered to be fake evidence. If the encrypted diagnostic evidence package is determined to be false evidence, the first number of reward tokens will be confiscated.

[0052] In some implementations of this embodiment, to resolve the conflict between verifying the authenticity of encrypted diagnostic evidence packages and protecting data privacy, this embodiment introduces zero-knowledge proofs: The vehicle only needs to prove to the verification node that "my vehicle observed a certain phenomenon under a certain operating condition", without exposing the specific raw data or location information.

[0053] In this embodiment, the method for generating zero-knowledge proofs is as follows: the SOVD server makes a commitment to sensitive fields (such as precise GPS coordinates, precise timestamps, and vehicle owner identifiers) within the encrypted diagnostic evidence package, and generates a zero-knowledge proof π using the Groth16 protocol. The zero-knowledge proof π has a constant size (<1KB) and a verification time of <10ms, which is suitable for vehicle-side computing power constraints.

[0054] Validating nodes can verify the validity of commitments and proofs without seeing historical signals. High-reputation nodes can participate in consensus as validators without obtaining core privacy data of other vehicles, complying with regulations such as GDPR.

[0055] In some implementations of this example, the Token is a functional token running on a consortium blockchain, used for payment of diagnostic services, bounty posting, staking, and reputation incentives.

[0056] In this embodiment, the first vehicle initiates a "real-time diagnostic service request" to the second vehicle through the SOVD protocol. After the second vehicle performs local diagnostic inference, it returns the result, and the smart contract automatically transfers an agreed number of tokens from the first vehicle's account to the second vehicle.

[0057] In this embodiment, when the repair station verifies that the encrypted diagnostic evidence package reported by a vehicle accurately guides the repair, the repair station (SOVD Client) calls the claims function in the smart contract. This claims function is a publicly callable function in the smart contract deployed on the diagnostic blockchain. It is triggered by the repair station (SOVD Client) after confirming the validity of the diagnostic evidence and is used to automatically allocate token rewards to the second vehicle that first provided correct evidence. Token rewards are automatically allocated from the first vehicle (beneficiary) or the insurance pool to the second vehicle that first provided correct evidence.

[0058] In this embodiment, after each diagnostic service is completed, the requester and the provider rate each other, and the rating updates the service quality reputation of both parties. Nodes with low ratings will automatically have their staking requirements increased in future transactions.

[0059] In some embodiments of this example, the method for allocating reward tokens to the second vehicle is as follows: Verify whether the caller is a registered repair station address (by checking the on-chain repair station whitelist); calls from non-whitelisted addresses are directly rejected.

[0060] Read the metadata of the encrypted diagnostic evidence package to confirm that the encrypted diagnostic evidence package is in a state of being stored and has not yet been claimed, thus avoiding double-spending claims; Read all response records corresponding to the bounty from the bounty pool ID, sort them by submission time, filter out the list of node addresses that have passed reputation verification (stage 3 reputation verification passed) and whose evidence hashes match, and take out the second vehicle that submitted the earliest as the reward recipient; A second number of reward tokens are extracted from the diagnostic blockchain based on the contribution weighting coefficient of the second vehicle; Transfer a third number of warranty tokens from the tokens locked in the first vehicle to the second vehicle; Update the status of the encrypted diagnostic evidence package to "claimed" and record the claim time, repair station address, and transaction hash for auditing and tracing purposes.

[0061] In this way, vehicles encrypt and store diagnostic evidence and issue a reward (supply). Other vehicles discover and submit solutions through a distributed index (demand). After dual verification by reputation and zero knowledge (trust), the smart contract automatically settles the tokens (incentive), thus forming a decentralized, self-organizing, and fraud-proof diagnostic knowledge market.

[0062] According to the second aspect of this application, such as Figure 2 As shown in the figure, this embodiment provides a decentralized diagnostic system for SOVD based on game theory incentives, including: The generation module is used to generate a first phenomenon feature hash based on novel pattern events detected in the historical signals of the first vehicle; The acquisition module is used to acquire the solution evidence when the second vehicle queries the real-time signal for a second phenomenon feature hash whose similarity to the first phenomenon feature hash is higher than a preset threshold. The verification module is used to verify the solution proof and process the verification result based on the game theory incentive method. If the solution proof verification fails, the second vehicle submits a quality assurance token to the diagnostic blockchain. If the verification passes, a reward token is extracted from the diagnostic blockchain according to the contribution weight coefficient of the second vehicle.

[0063] Specifically, this embodiment corresponds one-to-one with the above method embodiments. The functions of each module have been described in detail in the corresponding method embodiments, so they will not be repeated here.

[0064] According to a third aspect of this application, this embodiment provides a computer-readable storage medium having a computer program stored thereon, the computer program including executable instructions that, when executed by a processor, implement the method described above.

[0065] The present invention can implement all or part of the processes in the above methods, or it can be accomplished by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when the computer program is executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable file, or some intermediate form. The computer-readable medium can include: any entity or system capable of carrying computer program code, recording media, USB flash drive, portable hard drive, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc.

[0066] According to the fourth aspect of this application, such as Figure 3 As shown, an electronic device is provided, comprising: One or more processors; Memory is used to store executable instructions for the processor, which, when executed by one or more processors, cause one or more processors to implement the methods described above.

[0067] Electronic devices are manifested in the form of general-purpose computing devices. Components of an electronic device may include, but are not limited to: at least one processor, at least one memory, and a bus connecting different system components (including memory and processor).

[0068] The processor 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. A general-purpose processor can be a microprocessor or any conventional processor. The processor is the control center of a computer system, connecting all parts of the computer system through various interfaces and lines.

[0069] Memory can be used to store computer programs and / or modules. The processor implements various functions of the computer system by running or executing the computer programs and / or modules stored in the memory, and by accessing data stored in the memory. Memory can mainly include a program storage area and a data storage area. The program storage area can store the operating system and at least one application program required for a function (e.g., sound playback, image playback, etc.); the data storage area can store data created based on the use of the mobile phone (e.g., audio data, video data, etc.). Furthermore, memory can include high-speed random access memory, and can also include non-volatile memory, such as hard disks, RAM, plug-in hard disks, SmartMedia Cards (SMC), Secure Digital (SD) cards, Flash Cards, at least one disk storage device, flash memory device, or other volatile solid-state storage devices.

[0070] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, servers, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage and memory) containing computer-usable program code.

[0071] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), servers, and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A system that specifies functions in one or more boxes.

[0072] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including an instruction set implemented in a process. Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0073] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0074] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0075] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0076] The above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A decentralized diagnostic method for SOVD based on game theory incentives, characterized in that, include: Based on the novel pattern events detected in the historical signals of the first vehicle, a first phenomenon feature hash is generated; If, based on the SOVD server, a second phenomenon feature hash with a similarity higher than a preset threshold to the first phenomenon feature hash is found in the real-time signal of the second vehicle, the solution is obtained and stored. The solution is verified and the verification result is processed based on a game theory incentive method. If the solution verification fails, the second vehicle submits a quality assurance token to the diagnostic blockchain. If the verification passes, the second vehicle extracts a reward token from the diagnostic blockchain based on its contribution weight coefficient.

2. The method according to claim 1, characterized in that, The generation of a first phenomenon feature hash based on novel pattern events detected in the historical signals of the first vehicle includes: Based on the novel pattern events detected in the historical signals of the first vehicle, relevant signals within the time window before and after the novel pattern events are collected to form an encrypted diagnostic evidence package. The encrypted diagnostic evidence package is then submitted to a distributed storage network, and a content identifier is returned. Based on the relevant signals within the time window before and after the novel pattern event, obtain the first phenomenon feature hash and signal fingerprint; Lock a first number of bounty tokens for the first vehicle, and write the content identifier, the first phenomenon feature hash, the signal fingerprint, the vehicle model software and hardware version hash, the timestamp, the information on seeking the same / similar cases or root cause solutions, and the first number of bounty tokens into the diagnostic blockchain.

3. The method according to claim 2, characterized in that: The method for obtaining the signal fingerprint is as follows: The relevant signal sequence within the time window before and after the novel pattern event is divided into several sub-segments according to a fixed sub-window length; For each segment, obtain statistics, including mean, variance, standard deviation, maximum value, minimum value, peak-to-peak value, kurtosis, skewness, and root mean square. Then, take the mean of the statistics across all segments to form a time-domain feature vector. Fast Fourier Transform is performed on the relevant signals within the time window before and after the novel mode event to extract the dominant frequency position, dominant frequency amplitude, spectral centroid, and spectral flatness of the spectrum, forming a frequency domain feature vector; The time-domain feature vector and the frequency-domain feature vector are concatenated to form a signal fingerprint; and / or, The method for obtaining the content identifier is as follows: For relevant signals within the time window before and after a novel pattern event, a cryptographic hash function is used to calculate the hash value, resulting in a fixed-length hash digest. The hash digest is encapsulated in a Multihash format, which includes a type, length, and value. Add the Multicodec identifier before Multihash; After adding the CID version number before the Multicodec identifier, it is converted into a readable string, which is the content identifier.

4. The method according to claim 1, characterized in that, Based on the SOVD server, the method for querying the second phenomenon feature hash from the real-time signal of the second vehicle, which has a similarity to the first phenomenon feature hash higher than a preset threshold, is as follows: The first phenomenon feature hash, the signal fingerprint, and the vehicle model hardware and software version hash corresponding to the first vehicle are mapped to the key space of the DHT network through the Kademlia protocol, and several second vehicles are added to the DHT network. Based on the SOVD server, the phenomenon feature hash corresponding to the current phenomenon queried by the second vehicle and the first phenomenon feature hash are converted from binary to hexadecimal strings or integers respectively. The perceptual hash Hamming distance is obtained for the two hexadecimal strings or integers. The perceptual hash Hamming distance is the similarity. If the perceptual hash Hamming distance is greater than a preset threshold, the phenomenon feature hash corresponding to the current phenomenon is the second phenomenon feature hash, and the content identifier is returned.

5. The method according to claim 4, characterized in that, The methods for generating the first phenomenon feature hash and the phenomenon feature hash corresponding to the current phenomenon are as follows: The signal waveform is divided into segments of fixed length, and each segment is preprocessed, namely, the removal of DC components and trend terms. For each preprocessed signal segment, perform discrete wavelet transform or short-time Fourier transform to extract the time-frequency domain feature vector of the signal. The time-frequency domain feature vector is reduced in dimension and compressed, and a binary hash sequence is generated by threshold comparison. The binary hash sequence is converted into a hexadecimal string or integer and used as the phenomenon feature hash of the signal waveform.

6. The method according to claim 1, characterized in that, The process involves verifying the solution's provenance and processing the verification results using a game theory incentive method. If the solution's provenance verification fails, the second vehicle submits a warranty token to the diagnostic blockchain. If the verification passes, a reward token is extracted from the diagnostic blockchain based on the second vehicle's contribution weight coefficient, including: When the second vehicle is manufactured as a new car, a default reputation value is assigned. When the second vehicle reports the solution and evidence, a third number of guarantee tokens are pledged. If the solution submitted by the second vehicle passes the verification process, a reputation score is obtained, calculated using the following formula: in, For credit score, To report probability estimates, For actual observation results, 1 represents verification passing and 0 represents verification failing; Based on the positive linear relationship between contribution weight coefficient and reputation score, the contribution weight coefficient of the second vehicle is obtained, and a second number of reward tokens are extracted from the diagnostic blockchain according to the contribution weight coefficient of the second vehicle. If the solution verification reported by the second vehicle fails, the second vehicle submits a third number of warranty tokens to the diagnostic blockchain.

7. The method according to claim 1, characterized in that, It also includes performing fake authentication on the encrypted diagnostic evidence package based on a verification node, where the verification node is a vehicle or simulation environment, and the method is as follows: Based on the verification node, the third phenomenon hash value of the encrypted diagnostic evidence package is recalculated, and the hash value of the third phenomenon is compared with the hash value of the first phenomenon. If the comparison is inconsistent, it is determined that the first vehicle data has been tampered with, and the encrypted diagnostic evidence package is identified as false evidence; and / or, Based on the operating condition description in the encrypted diagnostic evidence package, an attempt is made to reproduce the same phenomenon at the verification node. If the phenomenon cannot be reproduced even with a preset number of vehicles or simulation environments, the encrypted diagnostic evidence package is deemed to be false evidence; and / or, After verifying the authenticity of the evidence through zero-knowledge proof, a vote is taken on whether the evidence is real or fake based on the verification nodes. The voting results are weighted and summarized according to the reputation score of the verification nodes. If the weighted reputation score exceeds the reputation score threshold, the encrypted diagnostic evidence package is considered to be fake evidence. If the encrypted diagnostic evidence package is determined to be false evidence, the first number of bounty Tokes shall be confiscated.

8. A decentralized diagnostic system for SOVD based on game theory incentives, characterized in that, include: The generation module is used to generate a first phenomenon feature hash based on novel pattern events detected in the historical signals of the first vehicle; The acquisition module is used to acquire the solution evidence when, based on the SOVD server, a second phenomenon feature hash with a similarity higher than a preset threshold is found in the real-time signal of the second vehicle. The verification module is used to verify the solution proof and process the verification result based on the game theory incentive method. If the solution proof verification fails, the second vehicle submits a quality assurance token to the diagnostic blockchain. If the verification passes, the second vehicle extracts a reward token from the diagnostic blockchain according to the contribution weight coefficient of the second vehicle.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, The computer program includes executable instructions that, when executed by a processor, implement the method of any one of claims 1-7.

10. An electronic device, characterized in that, include: One or more processors; A memory for storing executable instructions of the processor, which, when executed by the one or more processors, cause the one or more processors to perform the method according to any one of claims 1-7.

Images