A full life cycle traceability system and method for automotive parts

Abstract

The application discloses a kind of full life cycle tracing system and method of automobile accessories, it is related to supply chain tracing technical field, including, the basic information of automobile accessory raw material is spliced, raw material unique code is generated, and is uploaded to blockchain by encryption processing;Automobile accessory production parameters are monitored, and automobile accessory production processing is recorded according to raw material unique code, and accessory unique code is generated;The quality detection information of automobile accessory is recorded by accessory unique code, and quality detection unique code is generated;Based on quality detection unique code, the storage information of automobile accessory is recorded, and storage unique code is generated;According to storage unique code, the transportation information of automobile accessory is recorded, and transportation unique code is generated;Full life cycle summary of automobile accessory is constructed and anchored request target, and shared strategy is formulated to cross-enterprise request acceptance;Cross-enterprise data sharing authorization voucher is generated, and shared request record is submitted to blockchain.

Description

Technical Field

[0001] This invention relates to the field of supply chain traceability technology, and in particular to a full lifecycle traceability system and method for automotive parts. Background Technology

[0002] With the increasing complexity of modern industrial manufacturing and supply chain management, the production, processing, testing, warehousing, and transportation of auto parts typically involve multiple different companies and institutions. To ensure transparency and traceability throughout the process, the industry widely adopts information systems to record and trace auto parts production and logistics data. Currently, common traceability methods include centralized databases, barcode technology, and RFID technology. These methods effectively record key information about the parts, providing basic assurance for the production and distribution process.

[0003] However, traditional centralized data storage and transmission methods cannot effectively address the data sharing needs between different enterprises and provide insufficient protection for data privacy. Since data from the production, quality inspection, warehousing, and transportation of auto parts involves confidential information from multiple companies, existing technologies cannot achieve data sharing and traceability while ensuring data privacy. Blockchain technology, with its decentralized, immutable, and transparent characteristics, offers an effective solution. Through blockchain technology, different enterprises can achieve full-process traceability of auto parts from raw materials to transportation, while ensuring data security and privacy, and simultaneously guaranteeing data integrity and immutability. Summary of the Invention

[0004] In view of the aforementioned existing problems, the present invention is proposed.

[0005] Therefore, this invention provides a method for tracing the entire lifecycle of automotive parts, which solves the problem of how to achieve data sharing and traceability while ensuring data privacy in multi-party collaboration.

[0006] To solve the above-mentioned technical problems, the present invention provides the following technical solution:

[0007] In a first aspect, the present invention provides a method for tracing the entire lifecycle of automotive parts, comprising,

[0008] The basic information of automotive parts raw materials is pieced together to generate a unique code for the raw materials, and then uploaded to the blockchain through encryption.

[0009] Monitor automotive parts production parameters and record the automotive parts production and processing process based on the unique raw material codes to generate unique part codes;

[0010] The quality inspection information of automotive parts is recorded through a unique part code, and a unique quality inspection code is generated.

[0011] Based on the unique quality inspection code, record the warehousing information of auto parts and generate a unique warehousing code;

[0012] Based on the unique warehouse code, record the transportation information of auto parts and generate a unique transportation code;

[0013] Construct a summary of the entire lifecycle of automotive parts and anchor the target of requests, and formulate a sharing strategy for cross-enterprise request handling;

[0014] Generate cross-enterprise data sharing authorization credentials and submit the sharing request record to the blockchain.

[0015] As a preferred embodiment of the full lifecycle traceability method for automotive parts described in this invention, the steps of generating a unique code for raw materials and uploading it to the blockchain through encryption are as follows:

[0016] The basic information of automotive parts raw materials is pieced together to generate a unique code for the raw materials.

[0017] The unique code of the raw material is converted into a standard byte sequence using the UTF-8 encoding rule, which is then used as the original data.

[0018] The original data is encrypted using a hash algorithm to obtain the raw material code hash value;

[0019] The unique code of the raw material and the hash value of the raw material code are used to generate the on-chain record of the raw material, which is then packaged into an on-chain transaction of the raw material and uploaded to the blockchain using a distributed ledger method.

[0020] As a preferred embodiment of the full lifecycle traceability method for automotive parts described in this invention, the unique part code includes: recording information about the automotive part's production and processing process, and concatenating it with the unique code of the raw materials stored on the blockchain to generate a unique part code;

[0021] Simultaneously monitor automotive parts production parameters and link them with information from the automotive parts production and processing process to generate anomaly identifiers and dynamically adjust the unique part codes.

[0022] The adjusted unique code of the accessory is converted into a standard byte sequence for hash calculation to generate the accessory code hash value. This hash value is then combined with the adjusted unique code of the accessory to generate an on-chain record of the accessory. This record is then packaged into an on-chain transaction of the accessory and uploaded to the blockchain.

[0023] As a preferred embodiment of the full lifecycle traceability method for automotive parts described in this invention, the unique quality inspection code includes recording the quality inspection information of the automotive parts and concatenating it with the unique code of the parts stored on the blockchain to generate a unique quality inspection code.

[0024] The unique quality inspection code is converted into a standard byte sequence for hash calculation to generate a quality inspection code hash value. This hash value is then combined with the unique quality inspection code to generate a quality inspection on-chain record, which is then packaged into a quality inspection on-chain transaction and uploaded to the blockchain.

[0025] As a preferred embodiment of the full lifecycle traceability method for automotive parts described in this invention, the unique warehouse code includes recording the warehouse information of the automotive parts and concatenating it with the unique quality inspection code stored on the blockchain to generate a unique warehouse code.

[0026] The unique warehouse code is converted into a standard byte sequence for hash calculation to generate a warehouse code hash value. This hash value is then combined with the unique warehouse code to generate a warehouse on-chain record, which is then packaged into a warehouse on-chain transaction and uploaded to the blockchain.

[0027] As a preferred embodiment of the full lifecycle traceability method for automotive parts described in this invention, the transportation unique code includes recording the transportation information of the automotive parts and concatenating it with the warehouse unique code stored on the blockchain to generate a transportation unique code.

[0028] The unique transportation code is converted into a standard byte sequence for hash calculation to generate a transportation code hash value. This hash value is then combined with the unique transportation code to generate an on-chain record for the accessory, which is then packaged into a transportation on-chain transaction and uploaded to the blockchain.

[0029] As a preferred embodiment of the full lifecycle traceability method for automotive parts described in this invention, the full lifecycle summary of automotive parts includes: performing secondary hash calculations on the hash values ​​of raw material codes, accessory codes, quality inspection codes, warehousing codes, and transportation codes to obtain leaf nodes, and then splicing the leaf nodes using a pairwise combination and single-leaf backfilling method to construct the full lifecycle summary of automotive parts.

[0030] As a preferred embodiment of the full lifecycle traceability method for automotive parts described in this invention, the step of formulating a sharing strategy for accepting cross-enterprise requests includes, when the requester initiates an on-chain sharing request, classifying the request fields in the sharing request into low-sensitivity fields, medium-sensitivity fields, and high-sensitivity fields according to their sensitivity, thereby obtaining the field sensitivity level.

[0031] Based on the sharing request provided by the requester, the ratio of the number of data holders who actually completed joint signature agreement to the total number of all data holders involved in the current sharing request is calculated to determine the business layer approval intensity of the current sharing request.

[0032] Based on the cooperative relationship between the data holder and the requester, the cooperative relationship is divided into long-term strategic cooperation, temporary cooperation, and competitive relationship to obtain the cooperation model;

[0033] Develop a sharing strategy based on the sensitivity level of the fields, the business layer approval strength of the current sharing request, and the cooperation model.

[0034] As a preferred embodiment of the full lifecycle traceability method for automotive parts described in this invention, the generation of cross-enterprise data sharing authorization credentials includes, when the sharing request meets the business layer approval strength requirements, collecting key fragments from all holders of the shared data.

[0035] The key is fragmented into temporary session keys through threshold aggregation operations, and shared credentials are generated according to the sharing policy. The sharing request record is then submitted to the blockchain.

[0036] Secondly, this invention provides a full lifecycle traceability system for automotive parts, including:

[0037] The raw materials module is used to piece together the basic information of automotive parts raw materials, generate a unique code for the raw materials, and upload it to the blockchain through encryption.

[0038] The production record module is used to monitor the production parameters of automotive parts and record the production and processing process of automotive parts based on the unique code of the raw materials, and generate a unique code for the parts.

[0039] The quality inspection module is used to record the quality inspection information of automotive parts through the unique part code and generate a unique quality inspection code.

[0040] The warehouse record module is used to record the warehouse information of auto parts based on the unique quality inspection code and generate a unique warehouse code;

[0041] The transportation record module is used to record the transportation information of auto parts based on the unique warehouse code and generate a unique transportation code;

[0042] The lifecycle module is used to construct a summary of the entire lifecycle of automotive parts and anchor the request target, and to formulate a sharing strategy for cross-enterprise request handling.

[0043] The data sharing module is used to generate cross-enterprise data sharing authorization credentials and submit sharing request records to the blockchain.

[0044] The beneficial effects of this invention are as follows: by combining each stage of the entire life cycle of automotive parts with a unique code, and using blockchain for data storage and encryption, the immutability, transparency, and traceability of parts information are ensured; by formulating differentiated sharing strategies based on the intensity of business layer approval, the sensitivity level of fields, and the cooperation model, the privacy protection problem when multiple enterprises share data is solved. Attached Figure Description

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

[0046] Figure 1 A flowchart illustrating the full lifecycle traceability method for automotive parts.

[0047] Figure 2 This is a schematic diagram of a full lifecycle traceability system for automotive parts.

[0048] Figure 3 A flowchart for constructing a summary of the entire lifecycle of automotive parts.

[0049] Figure 4 A flowchart for generating cross-enterprise data sharing authorization credentials. Detailed Implementation

[0050] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings.

[0051] Many specific details are set forth in the following description in order to provide a full understanding of the invention. However, the invention may also be practiced in other ways different from those described herein, and those skilled in the art can make similar extensions without departing from the spirit of the invention. Therefore, the invention is not limited to the specific embodiments disclosed below.

[0052] Secondly, the term "one embodiment" or "embodiment" as used herein refers to a specific feature, structure, or characteristic that may be included in at least one implementation of the present invention. The phrase "in one embodiment" appearing in different places in this specification does not necessarily refer to the same embodiment, nor is it a single or selective embodiment that is mutually exclusive with other embodiments.

[0053] Reference Figures 1-4 As one embodiment of the present invention, this embodiment provides a method for full lifecycle traceability of automotive parts, including the following steps:

[0054] S1. Assemble the basic information of the raw materials for auto parts, generate a unique code for the raw materials, and upload it to the blockchain through encryption.

[0055] Furthermore, the basic information of automotive parts raw materials includes supplier number, raw material batch number, purchase date, raw material type, and quality standard;

[0056] The supplier number is provided by the purchasing agent or supplier to identify the supplier of raw materials, and is usually recorded according to the supplier numbering rules (e.g., A001). The raw material batch number is generated by the manufacturer in the purchase order to identify all raw materials in the same batch, and is usually recorded based on the batch production identification rules (e.g., B12345). The purchase date is used to record the time when the raw materials were purchased, and is recorded in the form of year, month, and day (e.g., 20250101). The raw material type is used to indicate the type of raw materials in the current batch, and is recorded using raw material classification labels (e.g., AL for aluminum alloy and ST for steel). The quality standard is the industry standard or production standard (e.g., ISO, GB / T, etc.) that the current batch of raw materials conforms to, and can usually be simplified to a standard code (e.g., Q1 indicates a specific quality standard).

[0057] The basic information of automotive parts raw materials is concatenated in a fixed format to generate a unique code for the raw materials. The fixed format includes, but is not limited to, being concatenated in a fixed order of "supplier number + raw material batch number + purchase date + raw material type + quality standard". For example, the basic information recorded for a batch of purchased aluminum alloy raw materials is supplier number A001, raw material batch number B12345, purchase date 20250101, raw material type AL, and quality standard Q1. Concatenating them in the fixed format will generate a unique code for the raw materials, represented as: A001-B12345-20250101-AL-Q1.

[0058] Furthermore, the raw materials are uniquely coded, encrypted using a hash algorithm, and uploaded to the blockchain using a distributed ledger method. The specific steps are as follows:

[0059] The unique code of raw materials is a string composed of English letters, numbers and hyphens. Before hashing and encrypting the unique code of raw materials, the string must be converted into a standard byte sequence.

[0060] In this method, the UTF-8 encoding rule is used to map each character in the unique code of the raw material to its corresponding byte value, while maintaining the original order of the characters to generate a standard byte sequence. UTF-8 encoding is a universal character encoding method. For characters within the ASCII range (decimal 0~127), such as English letters, numbers, and hyphens, each character occupies 1 byte (8 bits), and the byte value is consistent with the ASCII code value. For example, the letter "A" corresponds to the byte value 0×41, the number "0" corresponds to the byte value 0×30, and the hyphen "-" corresponds to the byte value 0×2D. For the unique code of the raw material A001-B12345-20250101-AL-Q1, the standard byte sequence obtained according to the UTF-8 encoding rule is represented as follows:

[0061] 0×41 0×30 0×30 0×31 0×2D 0×42 0×31 0×32 0×33 0×34 0×35 0×2D 0×32 0×30 0×32 0×35 0×30 0×31 0×30 0×31 0×2D 0×41 0×4C 0×2D 0×51 0×31.

[0062] The resulting standard byte sequence is the original data. The length of the original data is expressed in bits and is equal to the number of bytes in the standard byte sequence multiplied by 8. For example, if the length of the example standard byte sequence is 26 bytes, then the length of the original data is 208 bits.

[0063] The original data is encrypted using a hash algorithm. This method uses the SHA-256 hash algorithm as the encryption algorithm. The SHA-256 encryption process includes three main stages:

[0064] In the preprocessing stage, a binary "1" (hexadecimal 0x80) is appended to the end of the original data, followed by several binary "0"s, until the total number of bits in the original data differs from an integer multiple of 512 by 64 bits. Next, a 64-bit unsigned integer is appended to the end of the original data to represent the bit length of the original data, and written in big-endian format. The sequence obtained after the preprocessing stage is called the padded data. Big-endian format means that the values ​​are stored in order from the most significant bit to the least significant bit.

[0065] During the packet processing phase, the padded data is divided into one or more packets of 512 bits each, and each packet is expanded to generate 64 32-bit message words.

[0066] During the iterative compression phase, eight initial hash registers (A0 to A7) and 64 round constants defined by the SHA-256 standard are used to perform 64 rounds of Boolean operations, circular shift operations, and modulo 2^32 addition operations on each block, gradually updating the value of the hash registers.

[0067] The values ​​of the above 8 hash registers are concatenated in a fixed order, namely A0, A1, A2, A3, A4, A5, A6, A7, to form a continuous 256-bit binary string. Then, the binary string is converted into a hexadecimal character in 4-bit increments to obtain a raw material code hash value with a length of 64 hexadecimal characters.

[0068] After the encrypted raw material code hash value, along with the corresponding unique raw material code and generation timestamp, forms a raw material on-chain record, it is encapsulated into a raw material on-chain transaction and broadcast in the blockchain network. Verification nodes that reach the chain-layer consensus confirmation threshold perform validity verification and signature confirmation on the raw material on-chain transaction. Multiple raw material on-chain transactions are then packaged into a block. The block header at least includes the hash value of the previous block, the block timestamp, and the Merkle root hash calculated from all raw material on-chain transactions within the block (used for integrity verification), and also includes necessary fields for consensus (e.g., ...). (e.g., the set of validator signatures); the block body contains several plaintext fields of raw material on-chain transactions, including the unique raw material code, the raw material code hash value, and the generation timestamp; when the block is confirmed by a majority of validator nodes according to the consensus mechanism to reach the chain layer consensus threshold, the block is appended to the end of the blockchain and persistently stored in the ledger copies of all participating nodes; through the dual constraints of the hash value of the previous block and Merklegen, the continuity of the blockchain structure and the immutability of the raw material on-chain records (i.e., raw material on-chain transactions containing the unique raw material code, the raw material code hash value, and the generation timestamp) are guaranteed;

[0069] Among them, raw material on-chain transactions refer to on-chain transactions with raw material on-chain records as the payload;

[0070] Consensus mechanism is the general term for the overall rules and processes used in a blockchain network to make data copies distributed across different nodes reach a consensus. Consensus algorithm is the specific algorithm or protocol that implements the consensus mechanism, such as Byzantine fault-tolerant consensus algorithms and proof-of-stake consensus algorithms.

[0071] The chain-layer consensus confirmation threshold refers to the minimum percentage of validator nodes that must agree to complete block confirmation. An example value range can be set to greater than 50% and not higher than 100%, depending on the security requirements of the consensus algorithm and the scale of the blockchain network. When using a Byzantine fault-tolerant consensus algorithm, under the condition that "the total number of validator nodes is not less than three times the number of tolerant Byzantine fault nodes plus one", the chain-layer consensus confirmation threshold should not be lower than the percentage corresponding to "twice the number of tolerant Byzantine fault nodes plus one", which is usually equal to or higher than two-thirds of all validator nodes.

[0072] When using a proof-of-stake consensus algorithm, the chain-layer consensus confirmation threshold is based on the effective voting weight. The party voting in favor should have a cumulative effective voting weight greater than half of the total effective voting weight across the entire network. When higher security margins and resistance to forks are required, the effective voting weight ratio should be increased to two-thirds or more. The above settings ensure that the unique code of the raw material, its hash value, and the generation timestamp are written into the block body via the raw material's on-chain transaction, and are constrained by the hash value of the previous block in the block header and the Merkle root, thereby guaranteeing the integrity and immutability of the on-chain record.

[0073] S2. Monitor the production parameters of automotive parts and record the production and processing process of automotive parts based on the unique code of the raw materials, and generate a unique code for the parts.

[0074] Furthermore, monitoring automotive parts production parameters includes equipment operating status, temperature and humidity of the production environment, pressure and power consumption, and information on the automotive parts production and processing process includes unique raw material codes, production batch numbers, production dates, production process numbers, production line numbers, and processing procedure parameters.

[0075] Among them, the unique code of raw materials is a code generated in S1 and stored on the blockchain, used to identify the source of raw materials used in automotive parts; the production batch number is used to identify all automotive parts produced in the same batch, usually generated according to the batch rules set in production management; the production date is the date on which the current batch of automotive parts is actually completed, recorded in the form of year, month and day; the production process number is used to identify the production process flow or mold model used, usually recorded in the form of process category plus serial number (e.g., ALM01 represents aluminum alloy mold process 1); the production line number is used to identify the location or number of the production line for producing automotive parts (e.g., L03 represents production line 3); the processing parameters are the recorded information of key processing links in the production process (e.g., die casting temperature, pressure, cooling time, etc.), recorded in numerical form with units attached.

[0076] This involves linking automotive parts production parameters with information about the automotive parts manufacturing process. Specifically, it links equipment operating status with production process numbers. When the equipment temperature exceeds the safe operating temperature (which is usually set by the equipment manufacturer based on the equipment's materials, structure, and working principle), an abnormal equipment temperature indicator is added to the production process number. When the equipment temperature returns to the normal range, the production process number is updated to the original process number, and the abnormal equipment temperature indicator is removed. The adjustment of the production process number reflects the changes in equipment status during the process, thereby accurately recording the impact of abnormal temperatures on the process.

[0077] Changes in the production environment's temperature and humidity are linked to the production batch and production date. When these changes exceed the normal range (which is typically defined by product quality standards, material requirements, and industry standards), an environmental anomaly flag is added to the production batch and production date, and the current temperature and humidity values ​​are recorded. When the production environment's temperature and humidity return to the normal range, an environmental recovery record (including recovery time, temperature, and humidity values ​​at recovery) is added to the corresponding production batch and production date records, and the environmental anomaly flag is removed. The updates to the production batch and production date reflect the impact of temperature and humidity changes during production on the batch and date of production, thus ensuring accurate traceability of automotive parts produced under specific environmental conditions.

[0078] By associating pressure with production line numbers, when pressure fluctuations during production exceed the normal range (which is typically set based on process requirements and equipment design parameters), a pressure anomaly flag is added to the production line number, and the current production line's pressure data is recorded. When the pressure returns to the normal range, a pressure recovery record (including recovery time, pressure data at recovery time, and fluctuation amplitude) is added to the record corresponding to the production line number, and the pressure anomaly flag is removed. The update of the production line number reflects the impact of production line pressure changes on the production process, thereby ensuring that pressure problems occurring on a specific production line can be accurately traced.

[0079] Power consumption is associated with the production process number and production date. When the power consumption of the equipment exceeds the normal power consumption level (the normal power consumption level of the equipment is usually set based on the rated power of the equipment and normal load conditions), a power anomaly flag is added to the production process number and production date, and the current power consumption value and deviation ratio are recorded. When the power consumption returns to the normal power consumption level, a power recovery record (including recovery time, power consumption value at recovery time, and deviation ratio) is added to the record corresponding to the production process number and production date, and the power anomaly flag is removed. The update of the production process number and production date reflects the impact of power consumption anomalies on the production process and date, ensuring that power anomalies during the production process can be accurately traced.

[0080] Information from the production and processing of automotive parts is concatenated in a fixed format to generate a unique part code. The fixed format includes, but is not limited to, a fixed sequence of “unique raw material code + production batch number + production date + production process number + production line number + processing procedure parameters + anomaly identifier”.

[0081] Furthermore, the encryption and on-chain process of the unique part code is the same as that of the unique raw material code in S1. This includes converting the unique part code into a standard byte sequence, calculating the part code hash value, forming a part on-chain record and encapsulating it into a part on-chain transaction, generating a block after consensus confirmation, and permanently appending the block to the end of the blockchain, with the integrity and immutability jointly guaranteed by the hash value of the previous block and the Merkle root.

[0082] S3. Record the quality inspection information of automotive parts through the unique part code and generate a unique quality inspection code.

[0083] Furthermore, the quality inspection information for automotive parts includes the part's unique code, inspection batch number, inspection date, inspection item number, inspection equipment number, and inspection result parameters;

[0084] Among them, the unique code of the part is a code generated in S2 and stored on the blockchain, used to identify the automotive part corresponding to the inspection record; the inspection batch number is used to identify all automotive part inspection records within the same inspection cycle, usually generated according to the batch rules set in the inspection management; the inspection date is the date on which the quality inspection of the automotive part is actually completed, recorded in the form of year, month and day; the inspection item number is used to identify the inspection standard item performed, usually recorded in the form of inspection category plus serial number (e.g., DIM02 represents size inspection item No. 2); the inspection equipment number is used to identify the equipment that performs the inspection (e.g., E07 represents inspection equipment No. 7); the inspection result parameters are the key inspection values ​​and judgment results obtained during the inspection process (e.g., size deviation ±0.05mm, surface defect level 1, etc.), recorded in numerical or level form with attached unit or level standard.

[0085] The quality inspection information of automotive parts is spliced ​​together in a fixed format to generate a unique quality inspection code. The fixed format includes, but is not limited to, being concatenated in a fixed order of "unique part code + inspection batch number + inspection date + inspection item number + inspection equipment number + inspection result parameters".

[0086] Furthermore, the encryption and on-chain process of the unique quality inspection code is the same as that of the unique raw material code in S1. This includes converting the unique quality inspection code into a standard byte sequence, calculating the quality inspection code hash value, forming a quality inspection on-chain record and encapsulating it into a quality inspection on-chain transaction, generating a block after consensus confirmation, and permanently appending the block to the end of the blockchain, with the integrity and immutability jointly guaranteed by the hash value of the previous block and the Merkle root.

[0087] S4. Based on the unique quality inspection code, record the warehousing information of the auto parts and generate a unique warehousing code.

[0088] Furthermore, the warehousing information for auto parts includes a unique quality inspection code, batch number upon entry, date of entry, warehouse number, storage location number, and warehousing environment parameters;

[0089] Among them, the unique quality inspection code is a code generated in S3 and stored on the blockchain, used to identify the corresponding auto parts in the warehousing record; the warehousing batch number is used to identify all auto parts in the same warehousing operation, usually generated according to the batch rules set in the warehousing management; the warehousing date is the actual date on which the auto parts were warehoused, recorded in the form of year, month and day; the warehouse number is used to identify the warehouse where the auto parts are stored (e.g., WH02 represents warehouse number 2); the storage location number is used to identify the specific location of the parts in the warehouse (e.g., S05-R03-B12 represents the 5th row, 3rd column, 12th layer storage location); and the warehousing environment parameters are the key environmental conditions of the parts during storage (e.g., temperature 22°C, humidity 50%), recorded in numerical form with units.

[0090] The warehousing information of auto parts is concatenated in a fixed format to generate a unique warehousing code. The fixed format includes, but is not limited to, being concatenated in a fixed order of "unique quality inspection code + batch number upon entry + date upon entry + warehouse number + storage location number + warehousing environment parameters".

[0091] Furthermore, the encryption and on-chain process of the unique warehouse code is the same as that of the unique raw material code in S1. This includes converting the unique warehouse code into a standard byte sequence, calculating the warehouse code hash value, forming a warehouse on-chain record and encapsulating it as a warehouse on-chain transaction, generating a block after consensus confirmation, and permanently appending the block to the end of the blockchain, with the integrity and immutability jointly guaranteed by the hash value of the previous block and the Merkle root.

[0092] S5. Based on the unique warehouse code, record the transportation information of the auto parts and generate a unique transportation code.

[0093] Furthermore, the transportation information for auto parts includes a unique warehouse code, transportation batch number, shipping date, mode of transport number, carrier number, and transportation process parameters;

[0094] Among them, the unique warehouse code is a code generated in S4 and stored on the blockchain, used to identify the auto parts corresponding to the transportation record; the transportation batch number is used to identify all auto parts in the same shipment batch, usually generated according to the batch rules set in transportation management; the shipment date is the actual date the current batch of auto parts was shipped, recorded in the form of year, month and day; the transportation mode number is used to identify the transportation mode used (e.g., TRK01 indicates truck transportation mode 1); the carrier number is used to identify the carrier performing the transportation task (e.g., CARR05 indicates carrier number 5); the transportation process parameters are key status information during transportation (e.g., average transportation temperature 20°C, humidity 55%, number of GPS track points, etc.), recorded in numerical form with units attached.

[0095] The transportation information of auto parts is concatenated in a fixed format to generate a unique transportation code. The fixed format includes, but is not limited to, being concatenated in a fixed order of "unique warehouse code + transportation batch number + shipment date + mode of transport number + carrier number + transportation process parameters".

[0096] Furthermore, the encryption and on-chain process of the unique transportation code is the same as that of the unique raw material code in S1, including converting the unique transportation code into a standard byte sequence, calculating the transportation code hash value, forming a transportation on-chain record and encapsulating it into a transportation on-chain transaction, generating a block after consensus confirmation, permanently appending the block to the end of the blockchain and ensuring its integrity and immutability through the hash value of the previous block and Merkle root.

[0097] S6. Construct a summary of the entire lifecycle of automotive parts and anchor the target of requests, and formulate a sharing strategy for cross-enterprise request handling.

[0098] Furthermore, a secondary hash calculation is performed on the hash values ​​of raw material codes, component codes, quality inspection codes, warehousing codes, and transportation codes to obtain 5 leaf nodes. These leaf nodes are then concatenated using a pairwise combination and single-leaf backfilling method to construct a publicly verifiable Merkle tree, representing the entire lifecycle summary of automotive parts, as follows:

[0099] ;

[0100] ;

[0101] in, This represents the hash value of the raw material code. This represents the hash value of the part code. This represents the hash value of the quality inspection code. Represents the warehouse code hash value, Represents the transport code hash value, This represents the leaf node after performing a hash operation on the raw material code hash value. This represents the leaf node after hashing the hash value of the accessory code. This represents the leaf node after hashing the quality inspection code hash value. This represents the leaf node after hashing the storage code hash value. This represents the leaf node after hashing the transport code hash value. This represents the first intermediate node. This represents the second intermediate node. This represents the third intermediate node. This indicates a hash algorithm, such as SHA-256. This indicates a byte concatenation operation. It represents a summary of the entire life cycle of automotive parts and is a public, unique, and unforgeable anchor point.

[0102] Furthermore, using the entire lifecycle summary of automotive parts as the anchor target, the unique part codes in any cross-enterprise sharing request are identified, and the list of request fields submitted by the requester is analyzed to determine the sensitivity level of the request fields. The specific steps are as follows:

[0103] When any cross-enterprise requester, including but not limited to raw material suppliers, manufacturers, testing institutions, warehousing companies, and logistics companies, needs to access automotive parts information, it initiates an on-chain sharing request. The sharing request includes the requester's identifier, the unique code of the part, a list of request fields, and a request timestamp. Using the automotive parts' full lifecycle summary as the anchor target, the unique code of the part in the sharing request is identified, and five types of hash values ​​associated with the unique code of the part are sequentially retrieved in the blockchain, including raw material code hash value, part code hash value, quality inspection code hash value, warehousing code hash value, and transportation code hash value.

[0104] After identifying the unique part code, each field in the request field list is parsed to determine which part lifecycle stage the request field belongs to. For example, if the request field is a production process number, it should belong to the lifecycle stage corresponding to the unique part code; if the request field is a test result parameter, it should belong to the lifecycle stage corresponding to the unique quality inspection code; if the request field is a transportation process parameter, it should belong to the lifecycle stage corresponding to the unique transportation code.

[0105] After completing the field attribution analysis, the sensitivity level of each field in the request field list is further assessed, and the request fields are divided into three levels according to their sensitivity: Level 1 is low-sensitivity fields, such as transportation trajectory and storage status, whose content does not involve process secrets and can be regarded as ordinary business flow information; Level 2 is medium-sensitivity fields, such as production process number and test item name, which may involve some enterprise management model or quality control structure, and leakage may result in damage to commercial interests; Level 3 is high-sensitivity fields, such as raw test data, mechanical test records, etc., which belong to the enterprise's core process control parameters or product safety evaluation standards, and are generally only disclosed in legally mandated or important cooperative relationships;

[0106] After parsing the sensitivity level of each field, the most sensitive level is selected from all requested fields and used as the overall sensitivity level of this sharing request. If the field list contains both transportation trajectory and detection raw data, then although transportation trajectory is a low-sensitivity field, detection raw data is a high-sensitivity field. Therefore, the overall sharing request will be processed according to the high-sensitivity level.

[0107] Furthermore, based on the sharing request provided by the requester, the business-level approval strength of the current sharing request is calculated. Specifically, the total number of all data holders involved in the current sharing request (e.g., raw material suppliers, manufacturers, testing institutions, warehousing companies, and logistics companies) is counted, and the number of data holders who have actually completed joint signature agreement in the current sharing request is determined. Joint signature agreement means that each participant in the sharing request agrees to provide its corresponding data to the requester. The business-level approval strength of the current sharing request is calculated by the ratio of the number of data holders who have actually completed joint signature agreement to the total number of all data holders involved in the current sharing request, expressed as:

[0108] ;

[0109] in, This indicates the business layer approval strength of the current sharing request. 0 indicates that no companies agree, and 1 indicates that all companies agree. This indicates the number of data holders who actually completed the joint signature agreement. This indicates the total number of data holders involved in the current sharing request.

[0110] Based on the cooperative relationship between the data holder and the data requester, the cooperation models are defined as long-term strategic cooperation, temporary cooperation, and competitive relationship;

[0111] Among them, long-term strategic cooperation refers to a long-term and stable cooperative relationship between the partners. They usually have a strong foundation of trust in various aspects such as product research and development, production, and after-sales service. Under long-term strategic cooperation, the partner companies usually share core data and have less concern about data leakage or misuse.

[0112] Temporary cooperation refers to a loosely structured partnership between partners with relatively little need for data sharing. It is typically aimed at solving a specific problem or completing a specific task. Temporary partnerships have low continuity, thus requiring higher security for data sharing.

[0113] A competitive relationship refers to a situation where companies are in competition with each other. Data sharing is often severely restricted, especially when it involves sensitive information such as core technologies, trade secrets, and customer data. In this case, data sharing not only needs to be strictly controlled, but also requires the adoption of the most advanced privacy protection measures to ensure that competitive advantages are not leaked.

[0114] Based on the sensitivity level of the fields, the business layer approval strength of the current sharing request, and the cooperation mode, formulate sharing strategies, including plaintext authorization strategies, selective disclosure strategies, and multi-party secure computation strategies;

[0115] When the cooperation mode is a long-term strategic cooperation and the field sensitivity level is low or medium, and the business layer approval strength is greater than or equal to the business layer approval threshold, an plaintext authorization policy is executed; when the cooperation mode is a temporary cooperation and the field sensitivity level is low or medium, and the business layer approval strength is greater than or equal to the business layer approval threshold, and the selective disclosure ratio is less than or equal to the minimum disclosure ratio threshold, a selective disclosure policy is executed; when the cooperation mode is a competitive relationship or the field sensitivity level is high, and the business layer approval strength is greater than or equal to the business layer approval threshold, a multi-party secure computation policy is executed; when the business layer approval strength is less than the business layer approval threshold, the current sharing request is rejected, as indicated by:

[0116]

[0117] in, This indicates the sharing policy, with values ​​of 1 for plaintext authorization, 2 for selective disclosure, 3 for secure multi-party computation, and 0 for denial of sharing. This indicates the sensitivity level of the field, with values ​​of 1 for low sensitivity, 2 for medium sensitivity, and 3 for high sensitivity. This indicates the cooperation mode, with values ​​of 1 representing long-term strategic cooperation, 2 representing temporary cooperation, and 3 representing a competitive relationship. This represents the approval threshold at the business layer; example values ​​are provided. This is used to define the proportion of data that all parties agree to share. It is usually set to at least two-thirds, or at least 66% of the data holders, before sharing can continue. It can be adjusted according to specific business circumstances. Setting a stricter business-level approval threshold will raise the approval threshold and reduce the risk of leakage. This represents the minimum disclosure ratio threshold; example values ​​are provided. This is used to limit the maximum proportion of sensitive data that can be disclosed during data sharing. The value is mainly determined by the sensitivity level of the field and the cooperation mode. Typically, a larger value (e.g., 0.8) is used for low-sensitivity fields, while a smaller value (e.g., 0.3) is used for high-sensitivity fields to ensure privacy protection. This indicates the proportion of disclosure in selective disclosure. Indicates the number of fields that can be disclosed. This indicates the total number of fields requested.

[0118] S7. Generate cross-enterprise data sharing authorization credentials and submit the sharing request record to the blockchain.

[0119] Furthermore, upon receiving a valid sharing request, i.e. when At that time, a temporary session key is generated. Specifically, key fragments from all data-sharing participants are collected and denoted as... In this process, key fragments are generated when each data holder agrees to participate in data sharing. Each holder, when generating their key pair, uses a secure encryption algorithm to generate a pair of keys: a private key and a public key. Each holder keeps their private key secret and uses it only for signing operations, while the public key is used to generate key fragments. Then, in... At that time, based on the actual number of data holders who completed the joint signature agreement. A valid temporary session key is generated, which depends on the number of holders who have reached an agreement. The key fragments are aggregated using a threshold aggregation function and then merged. Each key is fragmented to generate a temporary session key, represented as follows:

[0120] ;

[0121] in, Indicates a temporary session key. This indicates a threshold aggregation operation. Indicates the first Key fragments of each participating data share holder.

[0122] Furthermore, under the plaintext authorization policy, sharing requests will be transmitted directly without encryption, thus avoiding additional encryption steps. The temporary session key will be bound to the automotive part's lifecycle summary, the requester's identifier, the request timestamp, and the list of request fields to generate a sharing credential under plaintext authorization, represented as follows:

[0123] ;

[0124] in, This indicates a shared credential under plaintext authorization. Indicates the requester's identifier. Indicates a request for a timestamp. This indicates the list of authorized data fields, i.e., the list of fields requested by the requesting party.

[0125] Under the selective disclosure strategy, the data holder selectively discloses data based on the fields authorized by the requester, without revealing all data content. This means that the data holder only discloses information related to the fields required by the requester. To ensure data privacy and verify data legitimacy, this method employs zero-knowledge proofs and searchable encryption. Zero-knowledge proofs are used to prove that a certain data field meets the requester's requirements without revealing the data content. For example, the data holder can use zero-knowledge proofs to verify the correctness of a production process number without disclosing the actual process number content. Searchable encryption allows the requester to query encrypted data without decryption, thus preventing the leakage of the entire dataset. The requester can search for authorized fields without needing to know the content of other fields. Under the selective disclosure sharing strategy, a shared certificate under selective disclosure is generated, represented as follows:

[0126] ;

[0127] in, This indicates a shared certificate under selective disclosure. This indicates a list of authorized data fields. The generated zero-knowledge proof proves the validity of a field but does not expose its specific content. This indicates that based on searchable encryption technology, it allows querying a list of authorized data fields within encrypted data. It only returns the calculation result of the authorized field, without decrypting the entire data;

[0128] Under a multi-party secure computation strategy, multiple data holders jointly perform encrypted computations to ensure the privacy of all parties' data. During this process, each data holder only provides encrypted data and does not disclose its original data. All data remains encrypted, and the participants jointly compute the final result through a computation protocol without disclosing their respective data content. To further ensure the privacy of the computation results, this method employs differential privacy technology. By adding noise to the computation results, it prevents the inference of information from any single data point, thereby further enhancing the effectiveness of data privacy protection. Under the sharing strategy of multi-party secure computation, a shared credential is generated, represented as follows:

[0129] ;

[0130] in, This represents a shared credential under secure multi-party computation. This indicates that the data field calculation results are used under multi-party secure computation. The data holders encrypt the authorized list of data fields and jointly calculate the final result without exposing the original data of any individual data holder. This indicates the computation result based on differential privacy technology, preventing the original data from being inferred from the result. Differential privacy ensures that the final computation result does not expose the content of a single data point by adding noise.

[0131] Under different sharing strategies, after the sharing certificate is generated, the sharing request record, including the entire lifecycle summary of the auto parts, the requester's identifier, the request timestamp, the sharing certificate under different sharing strategies, the list of authorized data fields, and the approval signature set (the set of signatures generated by all parties who agree to share the data), is packaged into a sharing certificate on-chain transaction and broadcast in the blockchain network. In the blockchain network, it is verified and confirmed by the consensus mechanism. The verification node confirms the validity of the transaction according to the consensus algorithm. When the chain-layer consensus confirmation threshold is met, the sharing certificate on-chain transaction will be packaged into a new block. The confirmed block will be appended to the end of the blockchain and permanently stored in the ledger copies of all participating nodes. Through the decentralized and immutable characteristics of the blockchain, the integrity, transparency, and traceability of the sharing request record are ensured, preventing any party from tampering with or withdrawing the shared data.

[0132] This embodiment also provides a full lifecycle traceability system for automotive parts, including:

[0133] The raw materials module is used to piece together the basic information of automotive parts raw materials, generate a unique code for the raw materials, and upload it to the blockchain through encryption.

[0134] The production record module is used to monitor the production parameters of automotive parts and record the production and processing process of automotive parts based on the unique code of the raw materials, and generate a unique code for the parts.

[0135] The quality inspection module is used to record the quality inspection information of automotive parts through the unique part code and generate a unique quality inspection code.

[0136] The warehouse record module is used to record the warehouse information of auto parts based on the unique quality inspection code and generate a unique warehouse code;

[0137] The transportation record module is used to record the transportation information of auto parts based on the unique warehouse code and generate a unique transportation code;

[0138] The lifecycle module is used to construct a summary of the entire lifecycle of automotive parts and anchor the request target, and to formulate a sharing strategy for cross-enterprise request handling.

[0139] The data sharing module is used to generate cross-enterprise data sharing authorization credentials and submit sharing request records to the blockchain.

[0140] This embodiment also provides a computer device applicable to the full lifecycle traceability method for automotive parts, including: a memory and a processor; the memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions to implement the full lifecycle traceability method for automotive parts as proposed in the above embodiment.

[0141] The computer device can be a terminal, comprising a processor, memory, communication interface, display screen, and input devices connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, carrier networks, NFC (Near Field Communication), or other technologies. The display screen can be an LCD screen or an e-ink screen. The input devices can be a touch layer covering the display screen, buttons, a trackball, or a touchpad on the computer device's casing, or an external keyboard, touchpad, or mouse.

[0142] This embodiment also provides a storage medium storing a computer program, which, when executed by a processor, implements the method for full lifecycle traceability of automotive parts as proposed in the above embodiments. The storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random Access Memory (SRAM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Erasable Programmable Read Only Memory (EPROM), Programmable Red-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0143] In summary, this invention addresses the privacy concerns of multiple companies when sharing data by combining each stage of the entire lifecycle of automotive parts with a unique code and using blockchain for data storage and encryption.

[0144] It should be noted that 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 preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention, and all such modifications or substitutions should be covered within the scope of the claims of the present invention.

Claims

1. A method for tracing the entire lifecycle of automotive parts, characterized in that: include, The basic information of automotive parts raw materials is pieced together to generate a unique code for the raw materials, and then uploaded to the blockchain through encryption. Monitor automotive parts production parameters and record the automotive parts production and processing process based on the unique raw material codes to generate unique part codes; The quality inspection information of automotive parts is recorded through a unique part code, and a unique quality inspection code is generated. Based on the unique quality inspection code, record the warehousing information of auto parts and generate a unique warehousing code; Based on the unique warehouse code, record the transportation information of auto parts and generate a unique transportation code; Construct a summary of the entire lifecycle of automotive parts and anchor the target of requests, and formulate a sharing strategy for cross-enterprise request handling; Generate cross-enterprise data sharing authorization credentials and submit the sharing request record to the blockchain.

2. The method for full lifecycle traceability of automotive parts as described in claim 1, characterized in that: The steps for generating a unique code for the raw material and uploading it to the blockchain through encryption are as follows: The basic information of automotive parts raw materials is pieced together to generate a unique code for the raw materials. The unique code of the raw material is converted into a standard byte sequence using the UTF-8 encoding rule, which is then used as the original data. The original data is encrypted using a hash algorithm to obtain the raw material code hash value; The unique code of the raw material and the hash value of the raw material code are used to generate the on-chain record of the raw material, which is then packaged into an on-chain transaction of the raw material and uploaded to the blockchain using a distributed ledger method.

3. The method for full lifecycle traceability of automotive parts as described in claim 2, characterized in that: The unique part code includes information recording the production and processing process of the automotive part, which is then combined with the unique code of the raw materials stored on the blockchain to generate the unique part code. Simultaneously monitor automotive parts production parameters and link them with information from the automotive parts production and processing process to generate anomaly identifiers and dynamically adjust the unique part codes. The adjusted unique code of the accessory is converted into a standard byte sequence for hash calculation to generate the accessory code hash value. This hash value is then combined with the adjusted unique code of the accessory to generate an on-chain record of the accessory. This record is then packaged into an on-chain transaction of the accessory and uploaded to the blockchain.

4. The method for full lifecycle traceability of automotive parts as described in claim 3, characterized in that: The unique quality inspection code includes recording the quality inspection information of the auto parts and concatenating it with the unique code of the parts stored on the blockchain to generate a unique quality inspection code. The unique quality inspection code is converted into a standard byte sequence for hash calculation to generate a quality inspection code hash value. This hash value is then combined with the unique quality inspection code to generate a quality inspection on-chain record, which is then packaged into a quality inspection on-chain transaction and uploaded to the blockchain.

5. The method for full lifecycle traceability of automotive parts as described in claim 4, characterized in that: The unique warehouse code includes recording the warehouse information of the auto parts and concatenating it with the unique quality inspection code stored on the blockchain to generate a unique warehouse code. The unique warehouse code is converted into a standard byte sequence for hash calculation to generate a warehouse code hash value. This hash value is then combined with the unique warehouse code to generate a warehouse on-chain record, which is then packaged into a warehouse on-chain transaction and uploaded to the blockchain.

6. The method for full lifecycle traceability of automotive parts as described in claim 5, characterized in that: The unique transportation code includes recording the transportation information of the auto parts and concatenating it with the unique warehouse code stored on the blockchain to generate a unique transportation code. The unique transportation code is converted into a standard byte sequence for hash calculation to generate a transportation code hash value. This hash value is then combined with the unique transportation code to generate an on-chain record for the accessory, which is then packaged into a transportation on-chain transaction and uploaded to the blockchain.

7. The method for full lifecycle traceability of automotive parts as described in claim 6, characterized in that: The automotive parts lifecycle summary includes performing secondary hash calculations on the raw material code hash value, part code hash value, quality inspection code hash value, warehousing code hash value, and transportation code hash value to obtain leaf nodes. The leaf nodes are then spliced ​​together using a pairwise combination and single-leaf backfilling method to construct the automotive parts lifecycle summary.

8. The method for full lifecycle traceability of automotive parts as described in claim 7, characterized in that: The aforementioned strategy for developing a sharing approach for cross-enterprise request acceptance includes, when a requester initiates an on-chain sharing request, classifying the request fields in the sharing request into low-sensitivity fields, medium-sensitivity fields, and high-sensitivity fields according to their sensitivity, thereby obtaining the field sensitivity level. Based on the sharing request provided by the requester, the ratio of the number of data holders who actually completed joint signature agreement to the total number of all data holders involved in the current sharing request is calculated to determine the business layer approval intensity of the current sharing request. Based on the cooperative relationship between the data holder and the requester, the cooperative relationship is divided into long-term strategic cooperation, temporary cooperation, and competitive relationship to obtain the cooperation model; Develop a sharing strategy based on the sensitivity level of the fields, the business layer approval strength of the current sharing request, and the cooperation model.

9. The method for full lifecycle traceability of automotive parts as described in claim 8, characterized in that: The generation of cross-enterprise data sharing authorization credentials includes collecting key fragments from all data sharing holders when the sharing request meets the business layer approval strength requirements; The key is fragmented into temporary session keys through threshold aggregation operations, and shared credentials are generated according to the sharing policy. The sharing request record is then submitted to the blockchain.

10. A full lifecycle traceability system for automotive parts, based on the full lifecycle traceability method for automotive parts according to any one of claims 1 to 9, characterized in that: include, The raw materials module is used to piece together the basic information of automotive parts raw materials, generate a unique code for the raw materials, and upload it to the blockchain through encryption. The production record module is used to monitor the production parameters of automotive parts and record the production and processing process of automotive parts based on the unique code of the raw materials, and generate a unique code for the parts. The quality inspection module is used to record the quality inspection information of automotive parts through the unique part code and generate a unique quality inspection code. The warehouse record module is used to record the warehouse information of auto parts based on the unique quality inspection code and generate a unique warehouse code; The transportation record module is used to record the transportation information of auto parts based on the unique warehouse code and generate a unique transportation code; The lifecycle module is used to construct a summary of the entire lifecycle of automotive parts and anchor the request target, and to formulate a sharing strategy for cross-enterprise request handling. The data sharing module is used to generate cross-enterprise data sharing authorization credentials and submit sharing request records to the blockchain.

Images