Collaborative manufacturing multi-subject data sharing and right confirmation method based on block chain

Abstract

The invention discloses a block chain-based collaborative manufacturing multi-subject data sharing and right confirmation method, which is suitable for a collaborative scene of supplier production and distribution-overall unit final assembly. The method comprises the following steps: constructing an alliance block chain system of double-main-body nodes and consensus nodes, and ensuring interaction security through combination of permission grading and zero-knowledge proof; production, distribution and final assembly whole-process data collected by the double main bodies are subjected to XML standardization, RSA encryption and SHA-256 hash processing and then are subjected to uplink evidence storage; deploying an intelligent contract written by a Solidity language, and automatically quantifying rights and interests based on a four-dimensional system (contribution degree, value degree, quality degree and use frequency); authorization sharing is realized through intelligent contract verification, and full-life-cycle tracing is completed based on a data hash value. According to the method, credible sharing of data and clear definition of rights and interests are realized, the collaboration efficiency and fairness are improved, and the privacy of main body core data is protected.

Description

TECHNICAL FIELD

[0001] The present application relates to the cross field of networked collaborative manufacturing and blockchain technology, and in particular to a collaborative manufacturing multi-agent data sharing and benefit confirmation method based on blockchain. BACKGROUND

[0002] In the networked collaborative manufacturing mode of supplier production and distribution and overall unit assembly, data has become the core link connecting the two main bodies - the supplier needs to dynamically adjust the production and distribution rhythm of parts according to the assembly plan of the overall unit, and the overall unit relies on the production progress, quality detection and other data of the supplier to optimize the assembly scheduling. However, the current mainstream data sharing mechanism still stays in the traditional centralized architecture, which is difficult to adapt to the collaborative needs in this scenario, highlighting three major defects: first, there is a "trust barrier" in data interaction. The supplier and the overall unit belong to independent interest subjects, and the data storage permission of the centralized platform is concentrated in one party or a third party, resulting in doubts about the authenticity of the data by both parties, for example, the supplier doubts the timeliness of the assembly progress data, and the overall unit worries about the tampering of the parts quality data; second, there is no basis for defining data rights and interests. The data such as production parameters, distribution trajectory and assembly demand list are in the process of circulation, and the contribution boundary and value weight are fuzzy. When the data generates derivative value or causes quality disputes, it is difficult to determine the responsibility subject and the ownership of the rights and interests; third, there is an "efficiency bottleneck" in data collaboration. The data formats of the two parties are not unified (such as the supplier using PDF to record production data and the overall unit using Excel to manage assembly information), which needs to be manually verified and converted repeatedly, and the privacy protection and sharing needs of core technical data (such as the supplier's precision machining process and the overall unit's modular assembly scheme) are difficult to balance. Either the encryption is too high to affect the collaboration efficiency, or the permission is too open to cause the leakage of business secrets. These problems directly lead to the extension of the collaborative cycle and the increase of communication costs, which restricts the optimal allocation of manufacturing resources.

[0003] The distributed ledger, tamper-proof, and smart contract automatic execution features of the blockchain technology provide a technical breakthrough for solving the above problems. In recent years, some research has attempted to apply blockchain to manufacturing data evidence, but for the strong correlation and high collaboration of production and distribution and assembly, the existing solutions still have obvious limitations: most solutions only realize the function of data on-chain evidence, and do not solve the problem of standardized access of manufacturing data, which makes it difficult for heterogeneous data of different subjects to interoperate; there is a lack of a rights and interests quantification model that adapts to both supply and demand, which cannot accurately calculate the contribution value of parts production data and assembly scheduling data; the smart contract is only used for simple permission verification, and does not form a full-process automatic closed loop. Therefore, it is urgent to build a blockchain solution that meets the collaborative needs of suppliers and overall units, to achieve the dual goals of data trusted sharing and clear definition of rights and interests. SUMMARY

[0004] In view of the above technical problems, the application discloses a collaborative manufacturing multi-agent data sharing and right confirmation method based on a blockchain, relies on a blockchain technology to build a whole-process solution, and realizes the collaborative goals of data credibility, clear rights, efficient sharing, and traceable controllability.

[0005] Technical scheme:

[0006] The collaborative manufacturing multi-agent data sharing and right confirmation method based on the blockchain comprises the following steps.

[0007] Step 1, an alliance blockchain system comprising a supplier node, a general unit node and a consensus node is constructed, a digital identity certificate based on an RSA algorithm is configured for each node, and differentiated data access permission rules are set based on an RBAC model, and the permissions of the supplier node and the general unit node are limited to each other.

[0008] Step 2, the supplier node and the general unit node respectively collect heterogeneous data in a production and distribution process and an assembly process, and synchronously record a collection time stamp, after being processed in a format standardization manner, the data are subjected to RSA encryption by using a receiver public key to generate a ciphertext, and a SHA-256 hash value of the ciphertext is calculated, and after being packaged with the ciphertext, the hash value, the time stamp and a node digital signature, the package is submitted to the consensus node, and after being verified by a PBFT consensus algorithm, the package is stored in a chain for evidence.

[0009] Step 3, a data right confirmation smart contract is deployed on the alliance blockchain, the contract internally comprises a four-dimensional right quantization index system including a data contribution degree, a data value degree, a data quality degree and a data use frequency, when a node calls data on a chain, the smart contract is automatically triggered, and the contract performs: permission verification, tracing of a contribution party based on a data hash value, matching of the four-dimensional index according to a data attribute and calculation of a right value, and writing of a right record into a blockchain.

[0010] Step 4, a data request party node submits a sharing request comprising a use purpose, after being verified by the smart contract for permission and use compliance, a one-time temporary decryption key is obtained, and an authorized node queries whole life cycle information from collection, storage in a chain to all sharing and right records based on a data hash value.

[0011] Further, in step 1, the nodes interact with each other by using an encryption communication protocol, the digital identity certificate comprises a node type, a permission range, a key and a validity period, and the validity period is automatically reminded to be updated before expiration; a two-level permission system is built based on the RBAC model, the supplier node can only access assembly progress and acceptance data of the general unit, the general unit node can only access production parameters and distribution track data of the supplier, and the permission rules are written into the blockchain by the smart contract.

[0012] Further, in step 1, the sensitive data of the supplier nodes and the overall unit nodes is encrypted using zero-knowledge proof technology; wherein the sensitive data of the supplier includes production process, raw material procurement channel, and the sensitive data of the overall unit includes general assembly scheme and production capacity planning.

[0013] Further, in step 1, an abnormal node management mechanism is also included: when the consensus node monitors that the subject node has continuous data format error / signature invalidity / hash mismatch for several times, it is marked as an abnormal node and the data submission right is suspended until the rectification report submitted is jointly audited and passed by the consensus node and the supervision node.

[0014] Further, step 1 provides secure and reliable underlying support for the entire collaborative system, eliminates centralized risks, and clearly defines the interaction boundaries of the two main bodies through node architecture design and permission control.

[0015] Further, in step 2, the standardization processing includes: formulating a unified manufacturing data specification based on XML format, clearly defining field names, data types, units, precision, and mandatory items; using a rule engine to eliminate invalid data with values outside a reasonable range or format mismatches, and using a machine learning model to identify implicit abnormal data that deviates from historical data trends; and initiating a completion request for missing key data fields to ensure data format uniformity.

[0016] Further, in step 2, the PBFT consensus algorithm verification is as follows: each supplier node and overall unit node sends the encrypted ciphertext, unique hash value, collection timestamp, and node digital signature to the alliance blockchain after packaging, and the consensus node uses the PBFT algorithm for multi-round verification, including the consistency of the signature and identity certificate, the matching of the hash value and the data ciphertext, and the data is packaged into a block after verification, which contains block index, previous block hash value, block data hash set, and consensus timestamp, and is linked to the blockchain main chain to complete the evidence storage.

[0017] Step 2 converts the dispersed data of the two main bodies into "uniform format, tamper-proof, traceable" on-chain data through standardization processing and on-chain storage on a trusted infrastructure, providing a real data source for subsequent benefit calculation.

[0018] Further, in step 3, the smart contract is written in Solidity language and is uploaded to the alliance blockchain for deployment after being jointly audited and passed by the supplier nodes, overall unit nodes, and supervision nodes, and the contract address, interface information, and version number are publicly disclosed to the blockchain ledger; smart contract upgrade requires application initiated by more than 2 / 3 of the main bodies and is audited and passed by the consensus node, and the old version and upgrade record are retained for traceability.

[0019] Furthermore, in step 3, weights a, b, c, and d are assigned to the four-dimensional equity quantification index system. The formula for calculating the equity value is: Equity value = Contribution score × a + Value score × b + Quality score × c + Frequency of use score × d.

[0020] Furthermore, the criteria for evaluating data contribution include data completeness and data timeliness; the criteria for evaluating data value are: the weight of the data's impact on the core business decisions of suppliers and overall units in collaborative manufacturing is not less than a set threshold; the criteria for evaluating data quality is the accuracy error rate; the frequency of data use is accumulated based on the number of effective calls, and if a problem is found, the function is immediately suspended and repaired and updated according to the process.

[0021] Furthermore, in step 4, a maximum usage period is set, the temporary decryption key is encrypted during transmission and automatically expires; when the sharing request verification fails, the system returns a clear reason and uploads the request record to the blockchain for permanent storage; the full lifecycle information includes data collection nodes and time, standardized processing records, encryption and hash parameters, on-chain block information, all call records, equity calculation details and anomaly handling records.

[0022] Beneficial effects:

[0023] (1) The blockchain-based collaborative manufacturing multi-entity data sharing and rights confirmation method provided by the present invention makes rights clear and quantifiable: by setting up a rights indicator system through smart contracts, the automatic definition and quantification of the data contribution rights of suppliers and overall units are realized, which solves the problem of unclear ownership of rights between the two parties in the traditional model and ensures the fairness of the collaboration between the two parties.

[0024] (2) The blockchain-based collaborative manufacturing multi-entity data sharing and rights confirmation method provided by the present invention enables secure and controllable sharing: by combining permission level and zero-knowledge proof technology, data can be shared on demand and be available but not visible between suppliers and overall units, which not only meets the needs of production distribution and final assembly collaboration, but also protects the data privacy of both parties' core production technologies, final assembly processes and other data. Attached Figure Description

[0025] Figure 1 This is an overall flowchart of the present invention;

[0026] Figure 2 This is a block diagram of the consortium blockchain system architecture in this invention;

[0027] Figure 3 This is an interface for managing supplier menus, developed specifically for projects at the Second Academy of Aerospace Science and Technology.

[0028] Figure 4 This is an interface for managing the overall management unit menu, developed specifically for projects at the Second Academy of Aerospace Science and Technology.

[0029] Figure 5 A flow chart of a double-subject data chaining process in the present application;

[0030] Figure 6 A flow chart of smart contract right confirmation in the present application;

[0031] Figure 7 A flow chart of data authorization sharing and tracing in the present application;

[0032] Figure 8 A flow chart of exception handling in the present application;

[0033] Figure 9 A flow chart of overall collaborative closed loop in the present application. DETAILED DESCRIPTION

[0034] The present application will be further described in detail below in combination with specific embodiments. The embodiments are based on a certain equipment manufacturing project and are applicable to a collaborative manufacturing scenario involving two subjects, i.e. a supplier and a general unit, where the supplier is responsible for component production and distribution and the general unit is responsible for product assembly.

[0035] The collaborative subjects of the equipment manufacturing project include A supplier (responsible for core transmission component production and distribution) and B general unit (responsible for equipment assembly), and C supervision node (industry quality supervision agency) is introduced. In view of the problems of data right ambiguity, easy tampering, unsafe sharing and difficult tracing in the existing mode, the data sharing and right confirmation are realized by using the method of the present application, as shown in Figures 1-9 The specific implementation steps of the collaborative manufacturing multi-subject data sharing and right confirmation method based on blockchain are as follows:

[0036] Step 1: Construction of double-subject alliance blockchain system: an alliance blockchain system composed of double-subject nodes and consensus nodes is constructed, each node is configured with an independent identity authentication module and a permission control module, and a dual mechanism of permission grading and privacy protection is used to ensure the safety of interaction. Among them, the consensus node is jointly selected by the third-party authority and the double subjects, responsible for blockchain consensus verification, ledger maintenance and exception node supervision, solving the trust barrier problem of double-subject data interaction.

[0037] Specifically,

[0038] Step 1.1, Node Architecture Building: Build a consortium blockchain system composed of double-subject nodes (supplier nodes, general unit nodes), consensus nodes, and supervision nodes. Among them, the supplier node integrates the production data collection interface and the distribution information upload module; the general unit node configures the assembly demand publishing and acceptance data entry function; the consensus node is jointly selected by the third-party authority (such as industry association) and the double-subject; the supervision node is responsible for the whole-process compliance audit. The four types of nodes realize data interaction through encrypted communication protocol.

[0039] Step 1.2, Identity and Authority Solidification: Use RSA asymmetric encryption algorithm to generate unique digital identity certificate for each node, which contains node type, business authority range, key information and 12-month validity period. The system automatically reminds to update 30 days before the expiration date. Based on the RBAC model, a two-level permission system is built: the supplier node can only access the assembly progress, part acceptance results and corresponding demand data of the general unit, and cannot obtain the assembly process parameters and equipment operation core data. The general unit can only query the supplier's part production parameters, real-time production progress and distribution trajectory data, and cannot touch the production process and cost accounting data of the supplier. The permission rules are written into the blockchain through smart contract and cannot be modified arbitrarily.

[0040] Step 1.3, Privacy Protection Mechanism Embedded: The sensitive data of double subjects (supplier production process, raw material procurement channel; general unit assembly scheme, capacity planning) are encrypted by zero-knowledge proof technology, realizing the data "available but invisible" — authorized nodes can only get the data use value, but cannot analyze the original sensitive information, from the bottom to eliminate the risk of data privacy leakage.

[0041] Step 1.4, Abnormal Node Control: The consensus node monitors the data submission behavior of each subject node in real time. When it detects that a node has data format error, invalid signature or hash value mismatch for 3 times in a row, it will be immediately marked as "abnormal node" and suspended from data submission authority, and at the same time, it will send a warning to the supervision node and the opposite subject node. The abnormal node needs to submit rectification report and problem proof materials, which will be jointly audited by the consensus node and the supervision node. After passing, the authority can be restored to ensure the compliance of the blockchain network node behavior.

[0042] A consortium blockchain system is a decentralized distributed ledger collaboration network where ledger data is jointly maintained by pre-selected consortium members (in this example, suppliers, overall units, and third-party authoritative institutions). All member nodes enjoy equal consensus participation rights (or permissions are assigned according to preset rules). Data is only visible to authorized nodes within the consortium; external nodes cannot access or obtain the data. Its core objective is to establish a trusted data interaction channel among multiple entities that do not require complete trust. Through distributed storage, immutability, and consensus verification, it replaces traditional centralized intermediaries to achieve efficient and secure collaboration. Combined with the needs of collaborative manufacturing scenarios, such as... Figure 2 As shown: In this embodiment, the consortium blockchain mainnet adopts a multi-node collaborative architecture. Each component has clearly defined functions and responsibilities. The architecture mainly includes three types of nodes: A) supplier nodes, B) overall unit nodes, and C) regulatory nodes (consensus nodes) and other consensus nodes. A and B are dual-main-entity nodes, and C is one of the consensus nodes. Each node has a clear division of labor and complementary functions.

[0043] Supplier Node A: Its core functions are collecting and uploading production / delivery data, as well as querying data within its authorized scope. It represents the supplier entity in the supply chain and is responsible for uploading data from the production and logistics processes to the blockchain.

[0044] B. Overall Unit Node: Its function is to collect and upload assembly data and query data within authorized limits. It represents the integrator of the final product or system and is responsible for uploading data from assembly, testing, and other stages to the blockchain.

[0045] C-level Supervisory Node - Consensus Node: This is a special node that combines both supervisory and consensus functions. Its C-level node functions include full data supervision, abnormal node monitoring, and participation in PBFT consensus. As the supervisor, it has higher-level data access permissions and is responsible for overseeing the compliance and stability of the entire network.

[0046] In the mainnet, besides the regulatory nodes, there are several other consensus nodes that participate in the consensus verification / ledger maintenance process, forming a distributed consensus network. All transactions and data that have passed consensus verification are recorded on the blockchain, thus realizing the core capabilities of blockchain: distributed storage, immutability, and smart contract deployment. Smart contracts are deployed on this mainnet to automatically execute data rights confirmation and sharing rules.

[0047] like Figure 3 As shown in Figure 4, the platform interface is controlled through a super administrator. RSA digital certificates are assigned to each node, and permission rules are set: A can access B's transmission component assembly progress and assembly compatibility testing data; B can access A's transmission component material parameters, production progress, and delivery trajectory data; C can access all data for quality supervision.

[0048] Step 2, double main body data standardization processing and uplink: the supplier and the overall unit collect production, distribution, and assembly process data through edge computing devices, first complete standardization processing according to unified specifications to obtain standardized data, then use the public key of the opposite node to encrypt the standardized data to generate encrypted ciphertext, and at the same time, calculate the unique hash value of the encrypted ciphertext through the SHA-256 algorithm, record the collection timestamp synchronously when collecting the original data, and finally use the private key to sign the combined data including the encrypted ciphertext, unique hash value, and collection timestamp to generate the node digital signature; package the encrypted ciphertext, unique hash value, collection timestamp, and node digital signature and upload them to the alliance block chain, and the consensus node verifies the data validity using the PBFT algorithm, and completes the uplink storage after verification, solving the problem of chaotic manufacturing data format and easy tampering.

[0049] Specifically,

[0050] Step 2.1, accurate collection of full-chain data: both parties collect collaborative data in real time through edge computing devices (supplier workshop Internet of Things terminal, overall unit assembly line data collector), covering the full link of production, distribution, and assembly, including:

[0051] Supplier side: component production parameters (material composition, size, hardness, and other performance indicators), production progress data (process completion rate, equipment utilization rate, quality detection results, and defect analysis report), distribution data (transportation tool information, real-time location, in-transit temperature and humidity, and estimated arrival time);

[0052] Overall unit side: assembly demand data (component model, quantity, delivery time node), assembly progress data (component input proportion, process completion, and equipment operation parameters), and quality acceptance data (component qualification rate, assembly adaptability result, and unqualified product handling record).

[0053] The collection frequency is dynamically adjusted according to the importance of the data, with core production / assembly data collected every 10 seconds, and ordinary logistics / demand data collected every minute to ensure real-time data.

[0054] Step 2.2, data standardization processing: based on XML format, a unified manufacturing data specification is formulated, which clearly defines each field name, data type, unit, precision, and mandatory items (such as component parameters including "material-specification-performance" three-field combination). The mixed cleaning strategy combining rule filtering and machine learning is used to process data.

[0055] The mixed cleaning strategy is as follows: the rule engine eliminates invalid data whose value is out of a reasonable range or whose format does not match; the machine learning model identifies and warns about implicit abnormal data that deviates from the regular trend by a large margin through historical data training, and decides whether to keep the data after manual review. For missing key fields (such as "performance indicators" of parts), the system automatically sends a request to the data collection node to complete the missing fields, and if no feedback is received within 30 minutes, the data is marked as "partially complete" with a note on the missing fields, ensuring uniform data format and controllable data quality.

[0056] Step 2.3, encryption and hash solidification: based on the standardized data obtained in step 2.2, the standardized data is encrypted using the public key of the other node to generate data ciphertext, and the private key is stored in the hardware encryption module by each node and updated automatically every 90 days to prevent private key leakage. The SHA-256 algorithm is called to calculate the hash value of the above data ciphertext, and the hash value is used as the unique "digital fingerprint" of the data, which corresponds to the data content one by one, and any minor modification will cause the hash value to change greatly, providing a basis for subsequent integrity verification.

[0057] Step 2.4, consensus on-chain storage: each subject node sends the encrypted ciphertext, unique hash value, collection timestamp, and node digital signature to the alliance blockchain after packaging. The consensus node uses the PBFT algorithm for multi-round verification, including the consistency of the signature and identity certificate, and the matching of the hash value and data ciphertext. After verification (more than 2 / 3 of the consensus nodes confirm validity), the data is packaged into a block, which contains block index, previous block hash value, block data hash set, and consensus timestamp, and is linked to the main chain of the blockchain to complete the storage, realizing the "once on-chain, cannot be tampered with" of the data.

[0058] The complete process of data on-chain is as follows Figure 5As shown, first, in the data processing and packaging stage, the two principal nodes work independently, following the same technical path. A supplier node collects specific production data of its transmission components, including material (e.g., high-strength alloy steel), hardness (HB280), current production progress (80% complete), and other information. At the same time, a B general unit node collects corresponding demand data of its assembly link, including demand quantity (100 sets) and delivery time requirement (before 2025-10-10). Both parties standardize the collected heterogeneous data in XML format to ensure the uniformity of data structure. Subsequently, each party encrypts the standardized data using its own RSA private key, generates the corresponding ciphertext, and calculates the SHA-256 hash value of the ciphertext (e.g., the hash value generated by the A supplier side is "0x123..."). Finally, each party attaches an accurate timestamp (e.g., "2025-10-01 08:30:00") and digital signature to the data package, completing the complete packaging before data submission. Second, in the submission and consensus verification stage, the packaged data is submitted to the consortium blockchain network. The submission is received by a group of consensus nodes including C regulatory nodes. All consensus nodes start the PBFT algorithm to collaboratively verify the validity of the submitted data, including the authenticity of the digital signature, the matching of the hash value, and the logicality of the timestamp, etc. Finally, in the result processing and evidence storage stage, the system executes different branch processes according to the consensus verification result. If the verification result is passed, all nodes unanimously agree to package the data into a block (in this embodiment, the index number of the block is 1001), and link the new block to the main chain, completing the final on-chain storage. If the verification result is not passed, the system will return the abnormal reason, and record the complete information of this exception to the log for subsequent audit and problem troubleshooting.

[0059] Step 3, smart contract deployment and interest confirmation: deploy a data interest confirmation smart contract on the consortium blockchain, which has a built-in interest quantification index system, calculation rules and triggering mechanism for the two principals; when any party calls shared data, the contract automatically triggers and completes data source tracing, contribution party interest quantification and interest information on-chain recording, solving the problem of no basis for data interest definition and difficulty in quantification.

[0060] Specifically,

[0061] Step 3.1, Smart Contract Rule Customization: A data rights confirmation smart contract is written using the Solidity language, with a built-in four-dimensional quantitative indicator system, weighted calculation rules, and multi-scenario triggering mechanism. The rule content is written into the contract after being jointly negotiated and confirmed by both parties. The four-dimensional indicators include: data contribution (30%, including completeness ≥95% and timeliness ≤2 hours), data value (40%, core decision data weight ≥0.6), data quality (20%, accuracy error rate ≤1%), and data usage frequency (10%, accumulated based on the number of effective calls). Completeness ≥ 95% means that the completeness rate of the preset mandatory key fields in the submitted data is no less than 95%; Timeliness ≤ 2 hours means that the time interval from data generation (such as the completion of part production or the end of the final assembly process) to uploading to the consortium blockchain does not exceed 2 hours; Core decision data weight ≥ 0.6 means that the system will preset decision influence weights for different types of data (0-1 points, 1 point is the greatest influence), and the weight of core decision data is set to no less than 0.6 (that is, the system will preset decision influence weights for different types of data. When the decision influence weight is ≥ 0.6, it is core data with a high value score, and when the decision influence weight is < 0.6, it is auxiliary data with a low value score); Accuracy error rate ≤ 1% means that the deviation ratio between the recorded value and the actual value of index-based data does not exceed 1%. For non-numerical data such as "delivery status", it is necessary to ensure that the record is consistent with the actual value and without error.

[0062] The scoring criteria are as follows: for contribution, "completeness 95%-100% earns 90-100 points, 90%-95% earns 70-89 points"; for value, "core data earns 90-100 points, auxiliary data earns 70-89 points." These specific criteria are deeply tied to the dual-entity business scenario. Triggering mechanisms include three scenarios: immediate data access triggering, monthly end-of-month periodic summary triggering, and data dispute tracing triggering.

[0063] Step 3.2, Contract Review and Deployment: Submit the contract code to the dual-entity node and the regulatory node for joint review, focusing on verifying the fairness of the rights and interests rules and the absence of loopholes in the code logic. After the review is passed, upload it to the consortium blockchain to complete the deployment. The contract address, interface information and version number are made public to the blockchain ledger for all nodes to query and call, ensuring that the contract is transparent and supervised.

[0064] Step 3.3, Automatic Calculation and Recording of Rights: When a supplier or overall unit calls on-chain shared data, the system automatically triggers the smart contract and executes four steps: verification, tracing, calculation, and recording. ① Verify whether the calling node's permissions comply with the contract's preset RBAC rules to prevent unauthorized calls; ② Trace the data's on-chain record through the data's unique hash value to accurately locate the data contributor (supplier or overall unit); ③ Match four-dimensional indicators based on data attributes, automatically determine the score of each indicator, and calculate the rights value according to "Rights Value = Contribution × 30% + Value × 40% + Quality × 20% + Usage Frequency × 10%"; ④ Write the contributor identifier, caller identifier, data hash value, scores of each indicator, rights value, trigger type, timestamp, and other information into the blockchain to form an immutable rights ledger, providing a reliable basis for subsequent rights realization. The four-dimensional rights quantification indicator system and its automatic triggering calculation mechanism disclosed in this embodiment realize a qualitative change from data sharing to rights confirmation, which is different from existing blockchain solutions that only focus on data storage or simple sharing.

[0065] The process of confirming rights and interests is as follows Figure 6 As shown, unit B calls the transmission component production parameter data of unit A to formulate the final assembly process plan, triggering the execution of the smart contract. Step 1: The contract verifies the legality of node B's permissions. If the verification is successful, the process continues; if the permissions are invalid, the smart contract will reject the call request and record it accordingly. Step 2: The data contributor is traced back to A through hash value. The smart contract uses the unique hash identifier of the target data stored on the blockchain to query its historical records, accurately trace and determine that its original contributor is node A. Step 3: Quantitative index scoring. The smart contract scores the called data in multiple dimensions based on a preset equity quantification model. In this embodiment, the data contribution score is determined to be 92 (data is complete and updated in a timely manner), the data value score is 90 (directly determines the final assembly process parameter design), and the usage frequency is 1. Step 4: The equity value is calculated according to the formula = 92 × 30% + 90 × 50% + 1 × 20% = 87.8; "Contributor A, Caller B, Equity Value 87.8, Timestamp 2025-10-01 09:15:00" is written into the blockchain. When supplier A accesses supplier B's final assembly requirements data, the smart contract similarly confirms and records supplier B's rights and interests.

[0066] Step 4, Data Sharing and Traceability: The two main nodes submit data sharing requests through the blockchain system. After verification by the smart contract in terms of identity, permissions, and purpose, they obtain data access permissions and decryption keys. At the same time, they can query the entire lifecycle information based on the unique identifier of the data, realizing secure data sharing and full traceability, and solving the problems of imbalance between sharing efficiency and privacy protection, and difficulty in tracing responsibility for problems.

[0067] Specifically,

[0068] Step 4.1, Tiered Authorization Data Sharing: When a primary node needs to access data, it submits a sharing request containing the node identifier, target data hash value, intended use (e.g., "adjust delivery plan," "formulate final assembly schedule"), usage period (maximum 30 days), and confidentiality commitment. The smart contract verifies the data from three dimensions: ① Identity legitimacy: verifying the consistency between the requesting node's digital signature and its on-chain identity certificate; ② Permission matching: ensuring the target data's access permission identifier matches the requesting node's permission scope; ③ Usage compliance: ensuring the usage falls within the pre-defined compliance list of "production collaboration, quality traceability, and schedule matching." Upon successful verification, the system generates a one-time temporary decryption key bound to the usage period and sends it to the requesting node via an encrypted channel. The key automatically expires. If verification fails, a clear reason such as "invalid identity / insufficient permissions / non-compliant usage" is returned, and the request record is uploaded to the blockchain to ensure the sharing process is controllable.

[0069] Step 4.2, Full Lifecycle Data Traceability: Any authorized node can query the entire data process information through a combination of multiple conditions such as "data hash value / node identifier / time range". The traceability content covers the entire process of collection, processing, on-chain, sharing, and rights, including: data collection node and time, standardized processing records (cleaning / completion status), encryption and hash parameters, on-chain block information (index, previous block hash), all call records (caller, time, purpose), rights calculation details, and anomaly handling records.

[0070] Step 4.3, Anomaly Tracing and Accountability: When the hash value of the queried data is found to be inconsistent with the hash value stored on the chain during the tracing process, the system immediately triggers an anomaly alarm, synchronizes it to the supervisory node and the dual-principal nodes, and automatically locks the disputed data and the operation logs of the relevant nodes (including data submission, call, and modification records). The consensus node verifies the tampering node by combining the logs and on-chain records, and the supervisory node handles the matter according to the contract rules to ensure that data issues are traceable, responsibilities are clear, and a collaborative closed loop is completed.

[0071] Data traceability and sharing, such as Figure 7 As shown, the process begins with supplier A initiating a sharing request. This request is a structured data packet, and its content includes at least: supplier A's own node identifier, the hash of the final assembly progress data to be queried, and the specific purpose of this query (in this embodiment, supplier A queries supplier B's final assembly progress data to confirm subsequent delivery arrangements). After the request is submitted, it enters the smart contract verification stage. The smart contract automatically verifies the compliance of this request from multiple verification dimensions according to preset rules. Figure 7All verification dimensions in the system focus on identity legitimacy, specifically verifying whether the requester's digital signature matches the certificate registered on the blockchain. This repetition emphasizes the system's use of multiple security verification mechanisms to ensure the authenticity of the requester's identity. If verification fails, the process terminates and the request is rejected; if all verification dimensions pass, encrypted data and the decryption key are returned. The system decrypts the overall assembly progress data of unit B and authorizes supplier A with the decrypted data along with a one-time decryption key, enabling A to access the decrypted assembly progress data. After obtaining the necessary information, supplier A can arrange subsequent logistics activities accordingly. Supervisory node C queries the entire data flow of the transmission component using the data hash value "0x123...", clearly obtaining A's production acquisition information, on-chain time, B's call records, and the rights and interests of both parties, ensuring transparent and traceable production-assembly data flow.

[0072] like Figure 8 As shown in the flowchart, the anomaly handling process is a core security element of the blockchain collaborative manufacturing data sharing system. The process begins with the system monitoring data flow in real time, continuously monitoring all on-chain and shared data activities. Monitoring relies on SHA-256 hash value verification to check data integrity. If the detection result is consistent, the data flows normally; if the detection result is inconsistent (suspected tampering), the system refuses to access the data and records the error, including the consensus nodes at the data level refusing to write data, fundamentally preventing potentially tampered data from entering the blockchain. The system then synchronizes the anomaly information to nodes A / B / C, ensuring that all nodes, including supplier node A, overall unit node B, and supervisory node C, are simultaneously aware of the anomaly and lock the disputed data and operation logs, preserving original evidence for subsequent audits. Supervisory node C leads the verification process. If a node is confirmed to have tampered, its permissions are immediately suspended, access is refused, and the node applies for restoration after rectification, then re-verification is performed. If no tampering is found, the data verification parameters are corrected. The anomaly handling system operates on a closed-loop logic of real-time monitoring, anomaly identification, rapid response, and accountability. Relying on hash value verification and monitoring, it locks disputed data and operation logs, and the consensus group verifies and holds individuals accountable. This enables rapid blocking of abnormal data and clarification of responsibility. Its design relies on the PBFT consensus algorithm and the immutability of blockchain, which not only connects the data on-chain process to form full-cycle protection, but also ensures the trustworthiness of collaborative data by clarifying the responsibilities of nodes. It can effectively prevent problems such as production data tampering and misoperation, and maintain collaborative order.

[0073] like Figure 9The table shown illustrates the breakdown of the entire process and the completion score of key tasks for an example of this invention. It displays the four core stages from system construction to collaborative optimization, the key tasks of each stage, and the completion status of each task. The implementation of the technical solution is divided into four progressive stages: system construction, data interaction, shared traceability, and collaborative optimization. Each stage proceeds sequentially and completes its corresponding core tasks. The system construction stage is the foundational preparation for the implementation of the solution, requiring the completion of consortium blockchain construction, permission rule configuration, and smart contract deployment: a consortium blockchain system consisting of a supplier (A), an overall unit (B), and consensus / supervisory nodes (C) is built, and node deployment is completed (score 5); a two-level permission system is configured based on the RBAC model to achieve permission isolation between the supplier and the overall unit, and the permission rules take effect (score 4); at the same time, a smart contract for equity calculation is deployed, and its built-in equity rules pass the review (score 5). After entering the data interaction phase, the core data flow and rights mechanism are activated: the supplier processes the production data of the transmission components and stores it on the blockchain (score 5), and the overall unit processes the final assembly requirement data and stores it on the blockchain (score 5); when the overall unit calls the supplier's on-chain data, the smart contract automatically triggers the rights calculation (score 4), and at the same time confirms that the rights rules of the smart contract have been approved (score 5). The shared traceability phase focuses on data value and security, realizing data sharing, supervision and anomaly prevention: the supplier can query the overall unit's final assembly progress data (score 4), the regulatory node conducts compliance verification of the entire process data on the blockchain (score 5), and the system detects that the on-chain data has not been tampered with, and the data security meets the standards (score 5). Finally, the collaborative optimization phase is entered, realizing business value through data collaboration: the supplier adjusts its own delivery plan based on the obtained final assembly progress data (score 4), and the overall unit optimizes the final assembly schedule based on the supplier's component production progress (score 4). The numbers following each task represent the degree of task completion or the level of achievement of the target. 5 points is the maximum score, and 4 points represents a high degree of completion with some room for optimization. Overall, the solution of this invention has a good implementation effect in each stage, and the core tasks have reached or are close to the maximum score standard.

[0074] It should be noted that this application is not a simple application of blockchain, but rather the construction of a fully automated, closed-loop system for data rights confirmation and secure sharing in a collaborative manufacturing scenario involving suppliers and final assembly units. This application addresses four core technical issues in the collaborative scenario of supplier production and distribution with final assembly unit assembly:

[0075] Firstly, there is the lack of a reliable data interaction mechanism. In traditional centralized architectures, the production and assembly data of suppliers and overall units are stored in independent systems. Data transmission is easily tampered with and lacks cross-verification methods, leading to a trust gap between the two parties regarding data authenticity and affecting the accuracy of collaborative decision-making. Step 1 of this application constructs a consortium blockchain system including dual subjects, consensus, and supervisory nodes. It adopts dual protection of permission hierarchical (RBAC model) and zero-knowledge proof, combined with RSA encryption and SHA-256 hash solidification technology, to achieve distributed data storage and immutability. This achieves refined management of data that is "usable but not visible" in an untrusted environment, satisfying collaborative needs while protecting core data privacy. Furthermore, through multiple rounds of verification using the PBFT algorithm of the consensus nodes, a cross-verification mechanism has been technically established.

[0076] Secondly, there is the issue of quantifying and defining data rights. The existing model lacks a data value assessment system. The interaction between supplier component production parameters and delivery dynamics data and overall unit assembly requirements and acceptance standards data leads to blurred contribution boundaries, making it impossible to scientifically quantify the rights of both parties and causing disputes. Step 3 of this application deploys a smart contract written in Solidity to construct a four-dimensional quantification system (contribution, value, quality, and usage frequency) and weighted calculation rules. This transforms abstract data rights into an automatically calculable four-dimensional indicator system, which is then automatically executed through the smart contract. When data is accessed, the source is automatically traced, rights are calculated, and recorded on the blockchain, providing a clear basis for rights ownership and resolving the problem of lacking a legal basis for rights definition.

[0077] Thirdly, there is the issue of standardization and efficient sharing of heterogeneous data. Inconsistent data formats and collection dimensions between the two parties necessitate significant manual intervention for data integration. Furthermore, conflicts exist between the privacy protection and collaborative needs of core technical data, making it difficult to balance sharing efficiency and data security. Step 2 of this application establishes a unified data specification based on XML. Through a combination of rule filtering and machine learning, heterogeneous data cleaning and format conversion are completed. Simultaneously, zero-knowledge proofs are used to encrypt sensitive data, and smart contracts provide three-dimensional verification and authorization to generate temporary decryption keys, achieving efficient and secure sharing that is "usable but not visible."

[0078] Fourth, the issue of full-process data traceability and accountability—the entire lifecycle of data, from collection and transmission to use, lacks a traceable link. When problems arise such as substandard component quality or delays in final assembly, it is impossible to quickly identify the responsible party, resulting in low traceability efficiency. This invention addresses the above-mentioned technical problems by building a full-process solution based on blockchain technology, achieving the collaborative goals of "trustworthy data, clear rights and interests, efficient sharing, and controllable traceability." Step 2 of this application uploads key information such as unique data hash values, collection timestamps, and node signatures to the blockchain, supporting multi-condition combined queries and covering all stages including collection, processing, uploading to the blockchain, sharing, and rights and interests. In abnormal situations, disputed data and operation logs can be locked, enabling rapid identification of responsibility.

[0079] Finally, it is understood that the above embodiments are merely exemplary embodiments used to illustrate the principles of the present invention, and the present invention is not limited thereto. For those skilled in the art, various modifications and improvements can be made without departing from the principles and essence of the present invention, and these modifications and improvements are also considered to be within the scope of protection of the present invention.

Claims

1. A blockchain-based collaborative manufacturing multi-agent data sharing and benefit confirmation method, characterized in that, The application comprises the following steps: Step 1, constructing an alliance blockchain system comprising a supplier node, a general unit node and a consensus node, configuring a digital identity certificate based on an RSA algorithm for each node, and setting differentiated data access permission rules based on an RBAC model, and the permissions of the supplier node and the general unit node are mutually restricted; Step 2, the supplier node and the general unit node respectively collect heterogeneous data in the production and distribution process and the assembly process, and synchronously record the collection time stamp, after format standardization processing, RSA encryption is performed by using the public key of the receiving party to generate ciphertext, and the SHA-256 hash value of the ciphertext is calculated; the ciphertext, hash value, time stamp and node digital signature are packaged and submitted to the consensus node, and after verification by the PBFT consensus algorithm, the chain is stored for evidence; Step 3, deploying a data right confirmation smart contract on the alliance blockchain, the contract contains a four-dimensional right quantization index system including data contribution, data value, data quality and data use frequency; when a node calls the on-chain data, the smart contract is automatically triggered, and the contract performs: permission verification, data hash value-based contribution party tracing, four-dimensional right quantization index matching according to data attributes and right value calculation, and right record writing into the blockchain; Step 4, the data request node submits a sharing request containing the use purpose, and obtains a one-time temporary decryption key after the smart contract verifies the permission and use compliance; the authorized node queries the whole life cycle information from collection, chain storage to all sharing and right records based on the data hash value.

2. The method of claim 1, wherein, In step 1, the nodes interact with each other using an encrypted communication protocol, the digital identity certificate contains node type, permission range, key and validity period, and automatic reminder for updating before the validity period expires; A two-level permission system is constructed based on the RBAC model, the supplier node can only access the assembly progress and acceptance data of the general unit, and the general unit node can only access the production parameter and distribution track data of the supplier, and the permission rules are written into the blockchain through the smart contract.

3. The method of claim 1, wherein, In step 1, the sensitive data of the supplier node and the general unit node is encrypted by using zero-knowledge proof technology; wherein, the sensitive data of the supplier includes production process and raw material procurement channel, and the sensitive data of the general unit includes assembly scheme and capacity planning.

4. The method of claim 1, wherein, Step 1 also includes an abnormal node management mechanism: when the consensus node monitors that the subject node has continuous data format error / signature invalidity / hash mismatch for a plurality of times, the abnormal node is marked and the data submission permission is suspended until the rectification report submitted is jointly audited and passed by the consensus node and the supervision node.

5. The method of claim 1, wherein, In step 2, the standardization processing includes: formulating a manufacturing data unified specification based on XML format, clearly defining field name, data type, unit, precision and mandatory item; invalid data with value exceeding a reasonable range or format mismatch is removed through a rule engine, and implicit abnormal data deviating from historical data trend is identified by using a machine learning model; a completion request is initiated for missing key data fields to ensure uniform data format.

6. The method of claim 1, wherein, In step 2, the PBFT consensus algorithm verifies that each supplier node and overall unit node sends the encrypted ciphertext, unique hash value, collection timestamp, and node digital signature to the alliance blockchain after packaging, and the consensus node uses the PBFT algorithm for multi-round verification, including the consistency of the signature and identity certificate, the matching of the hash value and data ciphertext, and the data is packaged into a block after verification, including block index, previous block hash value, block data hash set, and consensus timestamp, and is linked to the blockchain main chain to complete the evidence.

7. The method of claim 1, wherein, In step 3, the smart contract is written in Solidity language and is uploaded to the alliance blockchain after being jointly audited by the supplier node, overall unit node, and regulatory node, and the contract address, interface information, and version number are disclosed to the blockchain ledger; smart contract upgrade requires 2 / 3 or more subjects to initiate an application and pass the consensus node audit, and the old version and upgrade record are retained for tracing.

8. The method according to any one of claims 1 to 7, characterized in that, In step 3, weights a, b, c, and d are assigned to the four-dimensional equity quantification index system, and the calculation formula of the equity value is: equity value = contribution score × a + value score × b + quality score × c + usage frequency score × d.

9. The method of claim 8, wherein, The evaluation criteria for data contribution include data integrity and data timeliness; the evaluation criteria for data value are that the influence weight of data on the core business decision-making of supplier and overall unit collaboration manufacturing is not less than the set threshold; the evaluation criteria for data quality are accuracy error rate; the data usage frequency is accumulated according to the number of effective calls, and if a problem is found, the function is immediately suspended and repaired and updated.

10. The method of claim 1, wherein, In step 4, set the longest usage period, temporarily decrypt the encrypted transmission and automatically expire; if the sharing request verification fails, the system returns the specific reason and uploads the request record to the blockchain for permanent retention; the whole life cycle information includes data collection node and time, standardized processing record, encryption and hash parameter, on-chain block information, historical call record, equity calculation details, and exception handling record.

Images