Product full life cycle management method based on digital identification

Abstract

The invention discloses a product full life cycle management method based on a digital identifier, and belongs to the technical field of product management, and the method specifically comprises the steps: generating a digital identifier based on an initial bill of materials, writing the digital identifier into a product radio frequency tag, and registering the digital identifier to a block chain; periodically collecting label signal intensity and spatio-temporal information to form a physical track record and uploading the physical track record to the block chain; when the signal is continuously lower than a dynamic threshold value, judging that the physical signal is interrupted and triggering a logic tracing program, analyzing a product model in the digital identifier, and retrieving a corresponding bill of materials; searching supplier data according to the list to determine preparation suppliers, and extracting logistics coordinates and timestamps of recent supply of each supplier from the block chain to form a replacement tracing data set; fusing the physical track record and the data set according to a time sequence to generate a full life cycle data graph; according to the invention, continuous and complete tracing of the full life cycle data of the product under the condition of physical signal interruption is realized.

Description

Technical Field

[0001] This invention relates to the field of product management technology, and specifically to a product lifecycle management method based on digital identification. Background Technology

[0002] With the increasing demand for intelligent manufacturing and transparent supply chains, precise tracking and management of products throughout their entire lifecycle, from raw materials to final recycling, has become a key technological direction in the industrial internet field. By collecting data on the flow of products at each stage and building their digital twins, advanced applications such as quality traceability, supply chain optimization, and carbon footprint accounting can be effectively supported.

[0003] In current technological practices, using Radio Frequency Identification (RFID) tags for unique product identification and logistics node information collection is the mainstream solution. This method involves binding RFID tags to products during the production process and deploying fixed readers at key nodes such as warehouses and transportation vehicles to automatically record the product's location and time sequence, forming a physical flow trajectory. Furthermore, to enhance data credibility and tamper resistance, some solutions further upload the collected trajectory data to a blockchain network for evidence storage. Leveraging the distributed ledger characteristics of blockchain, this ensures the immutability of records, thereby establishing a product traceability chain based on physical detection.

[0004] However, the core logic of such existing technologies heavily relies on the continuous and reliable acquisition of physical signals (i.e., RFID reading and writing). In complex industrial and logistics environments, signal shielding, equipment failure, tag damage, or reading / writing failures due to dense stacking are difficult to completely avoid. Once such physical signal acquisition is interrupted, the product's flow data during the interruption period will form a "blind spot," and its digital trajectory will be broken. Existing technologies lack an effective mechanism to automatically maintain the continuity of product lifecycle data in the absence of physical signals. This results in data gaps in the constructed digital twin, fundamentally affecting the integrity and reliability of any advanced analysis, traceability, or management operations based on it. Therefore, how to overcome the absolute dependence on the continuity of physical signals and achieve robustness and self-recovery capabilities of the product lifecycle data chain under non-ideal conditions has become an urgent technical problem to be solved. Summary of the Invention

[0005] The purpose of this invention is to provide a product lifecycle management method based on digital identification, and to solve the following technical problems: Current solutions rely entirely on the continuous acquisition of physical signals to achieve product traceability. However, interruptions in physical signals are unavoidable in complex environments, leading to data gaps in the product's digital trajectory. Existing technologies lack an effective mechanism to automatically maintain or restore data continuity when physical signals are missing, affecting the integrity and availability of the entire lifecycle data chain.

[0006] The objective of this invention can be achieved through the following technical solutions: A product lifecycle management method based on digital identification includes the following steps: S1. Generate a structured digital identifier based on the initial bill of materials for the target product, write the identifier into the product's RFID tag, and register the identifier to the blockchain network; S2. Periodically collect the signal strength, location coordinates and collection timestamp of the RFID tag, generate physical trajectory records and upload them to the blockchain network; S3. Monitor signal strength. When the signal strength is lower than the dynamically calculated strength threshold for a continuous period, determine that the physical signal acquisition has been interrupted and trigger the logic tracing program. S4. The logical traceability program obtains a digital identifier from the blockchain network, parses the product model code embedded in the identifier, and retrieves the corresponding complete initial bill of materials accordingly. S5. Based on the material codes in the bill of materials, query the supplier relationship data to determine the prospective supplier corresponding to each material. Extract the final logistics coordinates and timestamps recorded by each prospective supplier when it most recently completed the delivery from the blockchain network to form a dataset of alternative traceability starting points. S6. Merge the physical trajectory records and alternative traceability starting point datasets according to time order to generate a product lifecycle data map with geographical coordinates as nodes and spatiotemporal transfer relationships as edges.

[0007] As a further aspect of the present invention: in step S2, the process of generating and uploading physical trajectory records is as follows: Scan the signal coverage area of ​​the RFID tag at preset fixed time intervals. When the digital identifier stored in the RFID tag is read, record the time of reading as the collection timestamp, and record the pre-stored geolocation code and the wireless signal strength value received in this reading operation. The digital identifier string, collection timestamp, geolocation code, and signal strength value are combined into a complete physical trajectory record. The physical trajectory record is sent to the logistics trajectory evidence storage contract in the blockchain network. The logistics trajectory evidence storage contract verifies the record format and then stores it in the distributed ledger.

[0008] As a further aspect of the present invention: in step S3, the process of dynamically calculating the intensity threshold is as follows: From the blockchain logistics trajectory storage contract, query and download historical signal strength data of all RFID tags for the same product model in the most recent historical period, and divide all historical data into multiple independent data sets based on the geographical location code of the collected historical data. For each independent dataset corresponding to a geographic location code, calculate the lower bound of the distribution of all signal strength values ​​within the dataset, summarize and calculate the arithmetic mean of the lower bounds of the distributions corresponding to all geographic location codes to obtain the basic signal strength reference value, obtain the number of signal interference events reported by the current monitoring location in the past few operating cycles, and adjust the basic signal strength reference value upward based on the number of signal interference events. The result after compensation is the strength threshold.

[0009] As a further aspect of the present invention: in S4, the process of the logic traceability program retrieving the complete initial bill of materials is as follows: Initiate a query request to the product registration contract of the blockchain network to obtain a digital identifier, carry product information associated with the interruption event in the query request, and extract the complete string of the digital identifier from the registration record returned by the blockchain network; Parse the header field of the digital identifier string to obtain the product model code. Based on the product model code, access the external product data management service and obtain the storage address of the complete design document corresponding to the product model. Obtain the design document from the storage address and parse the complete initial bill of materials for the product from a specific section of the design document. The complete initial bill of materials contains the codes of all constituent materials and the corresponding preferred supplier information.

[0010] As a further aspect of the present invention: In step S5, the process of querying supplier relationship data based on material codes and determining potential suppliers is as follows: The system sequentially reads the complete initial bill of materials obtained from the external product data management service. For each material code explicitly recorded in the bill of materials, a query operation is initiated in the supplier relationship database. The query operation conditions are set as follows: the goods code field of the supplier recorded in the database must be completely consistent with the current material code, and the supplier's cooperation status field must be a specified valid status value. Receive all supplier records that meet the criteria. Each record contains a unique supplier identification code. Collect all returned unique supplier identification codes to form a preliminary supplier identity set for the current material code. Iterate through all material codes in the complete initial bill of materials and repeat this process until a summary of the preliminary supplier identity sets related to all materials is obtained.

[0011] As a further aspect of the present invention: in step S5, the process of forming the alternative tracing starting point dataset is as follows: For each unique identifier of a prospective supplier in the summary, construct a structured data query request. The query request points to the logistics trajectory storage contract of the blockchain network. The request includes the unique identifier of the prospective supplier as the query key and requires the contract to return the first record with the identifier as the shipper, the logistics status as the final completed status, and sorted in descending order by the completion timestamp. The system receives complete logistics records that meet the requirements from the blockchain network, extracts the geographical coordinates of the final delivery location and the timestamp of the goods receipt confirmation, and encapsulates the geographical coordinates, timestamp, corresponding alternative supplier unique identification code and its associated original material code into a standard format alternative traceability starting point data entry. It iterates through all alternative supplier unique identification codes and repeats this encapsulation operation, and collects all generated alternative traceability starting point data entries to form a structured alternative traceability starting point dataset.

[0012] As a further aspect of the present invention: in step S6, the process of generating a product lifecycle data map is as follows: Retrieve all physical trajectory records associated with the product's digital identifier from the blockchain ledger and sort them by timestamp. Process each physical trajectory record sequentially, creating a corresponding graph node in a directed graph structure. The node's attributes include the geolocation code and collection timestamp from the record. In chronological order, establish a directed connection edge between each newly created node and its predecessor, representing temporal continuity and spatial transition relationships. After traversing all physical trajectory records, the alternative traceability starting point dataset is read. For each data entry in the dataset, a new graph node is created in the directed graph structure. The node's attributes include the geographical coordinates and the goods receipt timestamp in the entry. Between the node created by the last physical trajectory record and the node created by the first alternative traceability data entry, a directed connection edge with a specific type identifier is created. The directed connection edge represents the connection from the measured physical trajectory to the logical inference path. All nodes and edges are integrated to output a complete directed graph structure as a product lifecycle data map.

[0013] As a further aspect of the present invention: the process of creating a directed connection edge with a specific type identifier is as follows: The value of the specific type identifier is a predefined string constant. Key information of the alternative traceability starting point data entry is extracted from the alternative traceability starting point data entry on which the directed connection edge is based. The key information includes the pre-existing supplier unique identification code and the original waybill number of the source logistics record. The extracted key information is stored as an additional attribute along with the specific type identifier in the attribute field of the directed connection edge.

[0014] The beneficial effects of this invention are: This invention generates structured digital identifiers for products and registers them on a blockchain network, establishing data anchors independent of physical signals. When a physical signal acquisition is interrupted based on a dynamically calculated strength threshold, a logical traceability program is automatically triggered. This program parses the product model and material code from the digital identifier, retrieves the initial bill of materials, and uses the bill of materials to query a set of potential suppliers. It then automatically extracts the coordinates and timestamps of the nearest completed logistics endpoints from each potential supplier from the blockchain, using these as alternative data sources. By merging the actual collected physical trajectory with the alternative starting point data obtained from the logical traceability, a unified product lifecycle data map is generated in chronological order. This effectively fills data gaps in scenarios where physical signals are unreliable or interrupted, achieving continuity and integrity of the product's digital trajectory and overcoming the absolute dependence of existing technologies on continuous physical signal acquisition. Attached Figure Description

[0015] The invention will now be further described with reference to the accompanying drawings.

[0016] Figure 1 This is a flowchart illustrating the present invention. Detailed Implementation

[0017] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0018] Please see Figure 1 As shown, this invention is a product lifecycle management method based on digital identification, comprising the following steps: S1. Generate a structured digital identifier based on the initial bill of materials for the target product, write the identifier into the product's RFID tag, and register the identifier to the blockchain network; S2. Periodically collect the signal strength, location coordinates and collection timestamp of the RFID tag, generate physical trajectory records and upload them to the blockchain network; S3. Monitor signal strength. When the signal strength is lower than the dynamically calculated strength threshold for a continuous period, determine that the physical signal acquisition has been interrupted and trigger the logic tracing program. S4. The logical traceability program obtains a digital identifier from the blockchain network, parses the product model code embedded in the identifier, and retrieves the corresponding complete initial bill of materials accordingly. S5. Based on the material codes in the bill of materials, query the supplier relationship data to determine the prospective supplier corresponding to each material. Extract the final logistics coordinates and timestamps recorded by each prospective supplier when it most recently completed the delivery from the blockchain network to form a dataset of alternative traceability starting points. S6. Merge the physical trajectory records and alternative traceability starting point datasets according to time order to generate a product lifecycle data map with geographical coordinates as nodes and spatiotemporal transfer relationships as edges.

[0019] In a preferred embodiment of the present invention, the process of generating and uploading physical trajectory records in step S2 is as follows: First, standardized fixed UHF RFID readers are deployed at key physical locations such as production line workstations, warehouse entry and exit points, inside transport vehicles, and distribution center entrances. These readers maintain a network connection with the backend service and have a unique geolocation code pre-written into their configuration files. This code typically uses internationally standardized latitude and longitude coordinates; for example, a reader located at 116.407 degrees east longitude and 39.904 degrees north latitude has a location code of "116.407,39.904". All readers are programmed to automatically activate their radio frequency field at fixed 30-second intervals to scan the coverage area.

[0020] When a passive RFID tag affixed to a product packaging box enters the effective identification range of the reader, such as within 3 to 10 meters, the radio waves emitted by the reader activate the tag. The tag then backscatters the digitized identifier string stored inside back to the reader. After successfully receiving and decoding the string, the reader immediately records the precise current time marked by the central processing unit's clock, such as "2023-10-27, 14:30:05.123". This time point is defined as the acquisition timestamp for this operation. Simultaneously, the reader reads the pre-stored geolocation code from its own memory and obtains a value representing the strength of the received signal from the underlying signal strength indicator register of this communication. This value is usually in dBm, such as "-65dBm". Thus, a single read operation generates four core data elements: digitized identifier, acquisition timestamp, geolocation code, and signal strength value.

[0021] Subsequently, the reader's built-in processing unit combines these data elements according to a predefined serialization format. A typical format is to separate the four elements with commas, combining them into a string record such as "ID123456ABC,116.407,39.904,2023-10-27,14:30:05.123,-65". This string constitutes a complete physical trajectory record. The reader transmits this record in real time to the blockchain network access node deployed in the cloud via its onboard wireless communication module, such as a 4G or 5G module.

[0022] A smart contract called "Logistics Track Evidence Storage" is deployed in the blockchain network. Records sent by the reader are packaged into a transaction, calling the smart contract's "Upload Record" function. The contract function first validates the incoming data, checking if the number of fields meets expectations, if the timestamp format is valid, if the geolocation code is within a valid range, and if the signal strength value is within a reasonable range. For example, it will reject obviously erroneous data such as a signal strength of "300dBm". After successful validation, the smart contract associates this record with the timestamp and transaction hash value of the current block and writes it into the blockchain's distributed ledger. This process ensures the immutability and auditability of each physical track record, providing a trusted data source for all subsequent processing.

[0023] In another preferred embodiment of the present invention, the process of dynamically calculating the intensity threshold in step S3 is as follows: The threshold calculation can be triggered by a daily scheduled task or by accumulating 1000 new data entries at a specific reader location. Once the calculation begins, a read-only query is first initiated to the "Logistics Tracking Evidence" smart contract on the aforementioned blockchain network. The query request specifies product model filtering criteria, such as "Product Model: Model-X," and time range criteria, such as "within the past 7 days." The contract searches the ledger history and returns all historical records that meet the criteria. These records contain signal strength values ​​for all Model-X products collected by different readers at different times, along with their corresponding geolocation codes.

[0024] Next, the returned massive historical data is cleaned and grouped. The processing program divides the data into different sets based on the geolocation code in each record. For example, all records with location codes "116.407,39.904" are grouped into set A, all records with codes "121.473,31.230" are grouped into set B, and so on. For each independent dataset representing a specific physical location, in-depth statistical analysis is performed to characterize the historical fluctuations in signal strength at that location. Specifically, the lower bound of the distribution of all signal strength values ​​within the set is calculated. One feasible definition is to sort all values ​​in the set from smallest to largest and take the value at the 5th percentile as the lower bound. This value represents the signal strength at that location in 95% of historical cases, and can be considered as the "background noise" level or the minimum acceptable signal level at that location under ideal, interference-free conditions.

[0025] After obtaining the distribution lower bounds for all geographic locations, the arithmetic mean of these lower bounds is calculated. For example, if there are 50 valid locations with lower bounds of -70, -68, -72, ..., the average of these values ​​is calculated, resulting in a value such as "-68.5dBm". This average is set as the basic signal strength reference value, reflecting the general signal reception level of this product model in the overall deployment environment.

[0026] However, the baseline values ​​do not take into account real-time environmental changes at specific locations. Therefore, a dynamic compensation mechanism is needed. The program accesses the device management log database to retrieve abnormal events reported in the past 8 operating cycles (i.e., the past 240 seconds) for the specific reader location (e.g., location code "116.407, 39.904") for which the threshold needs to be calculated. These events are generated by the reader's own diagnostic functions or environmental monitoring modules and are categorized and recorded. Key signal interference events mainly include two categories: one is electromagnetic interference alarm records caused by the start / stop of nearby large motors, frequency converters, or equipment on the same frequency band; the other is physical obstruction alarm records triggered by video surveillance or infrared sensors, indicating that a large object is temporarily blocking the reader antenna. The program counts the total number of times these two types of events occurred in the past time period.

[0027] Finally, the baseline reference value is adjusted upwards based on the number of interference events recorded. The compensation logic is linear; for example, the preset rule is to increase the threshold by 1.5 dBm for each interference event. Assuming the baseline reference value is -68.5 dBm, and the current location has reported 3 interference events in the past 240 seconds, the compensation amount is 3 * 1.5 = 4.5 dBm. The final dynamic strength threshold is calculated to be -68.5 + 4.5 = -64.0 dBm. This compensated threshold means that, at this specific location where intermittent interference may exist, the threshold for determining signal failure is appropriately relaxed. If the signal strength in subsequent consecutive reading cycles is below -64.0 dBm, it is more likely to indicate a real interruption such as tag loss or reader hardware failure, rather than temporary environmental interference, thus improving the accuracy of interruption determination and reducing the false alarm rate.

[0028] In another preferred embodiment of the present invention, in step S4, the process of the logic traceability program retrieving the complete initial bill of materials is as follows: The logical traceability program constructs a query request based on the affected product batch number or associated identifier recorded in the interruption event log. This request is directed to a smart contract named "Product Registration" in the blockchain network. The request includes key query parameters, such as a parameter named "productBatch" with the value "BATCH20231027-001". Upon receiving the request, the smart contract looks up the latest digital identifier string associated with that batch number in its stored mapping table, and encapsulates this string along with its registration timestamp, registration node, and other information in a response data packet, returning it to the logical traceability program.

[0029] Upon receiving the response, the program extracts the complete string of the digital identifier. Let's assume this string is "HEADER_MODELX_P12345#MAT_A001,B002,C003#TAIL_8F3A". The program parses this string according to predefined format rules. It identifies the parts of the string separated by the "#" symbol. The first part, "HEADER_MODELX_P12345", is identified as a header field. The program further parses the header field, determining the product model code as "P12345" by searching for the specific prefix "MODELX_".

[0030] After obtaining the product model code "P12345", the logical tracing program needs to use this code to find the product's most original design documents. To do this, the program initiates an application programming interface (API) call to the "Product Data Management Service" deployed in the enterprise intranet or trusted cloud environment. The call request carries the product model code "P12345". The Product Data Management Service uses the model code as the primary key to perform a lookup in its core database. This database records the metadata and storage index of the complete set of design documents corresponding to each product model. For model "P12345", the database returns a record indicating that its complete design documents are stored in a specific path on a distributed file system, such as a hash address pointing to an IPFS network, "QmX86f9LpD4J8zCkw8YvV7gH7P".

[0031] The logical traceability program, based on the returned storage address, calls the corresponding file system client interface to retrieve the design document file remotely. The design document is typically a structured, machine-readable file, such as a bill of materials file in XML or JSON format following specific standards. After loading the document, the program navigates to a specific section marked "Bill of Materials" or similar, according to a pre-defined data schema. Within that section, the program reads all "Item" entries. Each entry contains several subfields, such as "MaterialCode," "Description," and "PrimarySupplierID." The program extracts this information item by item and organizes it into a list or table-like data structure.

[0032] Finally, the program outputs this complete initial bill of materials (BOM). This list meticulously details all the material items required to constitute product model "P12345". For example, the list might include: material code "IC-7805", description "5V voltage regulator", preferred supplier code "SUP-1001"; material code "CAP-100uF", description "100µF electrolytic capacitor", preferred supplier code "SUP-1002"; material code "PCB-MAIN", description "motherboard printed circuit board", preferred supplier code "SUP-2005", etc. This list provides the most authoritative and original material-supplier association basis for subsequent selection of potential suppliers, ensuring the accuracy and reliability of the data source for logical traceability.

[0033] In another preferred embodiment of the present invention, in step S5, the process of querying supplier relationship data based on material codes and determining potential suppliers is as follows: First, the program obtains a complete initial bill of materials (BOM) from the product data management service. This BOM typically exists in memory as a structured data list. Starting with the first item in the list, the program reads each material record sequentially. Assume the first material record read contains a material code field with the value "CAP-100uF-50V". The program then prepares to initiate an exact query to the supplier relationship database. The supplier relationship database is a separate relational database that maintains a "Supplier Master Data Table" and a "Supplier-Material Supply Relationship Table". The program constructs a structured query language statement with the core condition that it must join these two tables, and the final result must simultaneously satisfy two conditions. The first condition is that the "Material Code" field in the "Supplier-Material Supply Relationship Table" must be exactly the same as the material code "CAP-100uF-50V" currently held by the program. The second condition is that the "Cooperation Status" field in the "Supplier Master Data Table" must have a value equal to a predefined enumerated value, such as the string "ACTIVE". This value indicates that the supplier is in an active cooperation state and has the qualifications and capabilities to supply goods normally.

[0034] The program sends the constructed query statement for execution via a database connection. After executing the query, the database engine returns a result set. Assume this result set contains three records, each containing a unique identifier field for suppliers that meet the criteria, for example, "SUP-1002", "SUP-1105", and "SUP-1218". The logical traceability program iterates through this result set, extracting each supplier's unique identifier and adding it to a temporary set. This temporary set, such as a list object in a programming language, constitutes a preliminary supplier identity set for material code "CAP-100uF-50V". The program then reads the next material record from the initial bill of materials, for example, material code "IC-7805". The exact same query process is repeated: constructing the query, sending it to the supplier relational database, receiving the returned result set, extracting supplier identifiers, and forming another preliminary supplier identity set for "IC-7805". Assume this query returns "SUP-1001" and "SUP-1150".

[0035] The program iterates through all material codes recorded in the complete initial bill of materials in this manner. For each individual material code in the bill of materials, the program performs a separate database query and generates a corresponding set of prospective supplier identities. After iterating through all material codes, the program obtains multiple such sets. Finally, the program performs a summary operation, such as merging these independent sets into a larger list or mapping data structure. This summary data structure clearly records the association between each original material code and its corresponding one or more prospective supplier identity codes, providing a precise list of query targets for the next step of retrieving real-time logistics data for each supplier from the blockchain.

[0036] After obtaining the summary of the preliminary supplier identities, the logical traceability procedure then performs the operation of forming an alternative traceability starting point dataset. The procedure begins to traverse each preliminary supplier unique identifier in the aforementioned summary data structure. For example, the procedure first processes the identifier "SUP-1002".

[0037] For this identifier, the program needs to construct a data request specifically for querying blockchain logistics records. This request is structured as a function call to the "Logistics Tracking Evidence" smart contract in the blockchain network. The request includes explicit input parameters: the pre-selected supplier unique identifier "SUP-1002" is used as the "shipper" query key. Simultaneously, strict filtering conditions are specified in the request: the smart contract is required to return only records whose "Logistics Status" field equals a specific completion status code (e.g., "DELIVERED"). Furthermore, the request specifies a sorting rule: the results must be sorted in descending order by the "Completion Timestamp" field, with the newest record at the top. And, the parameters limit the number of returned results to the first record. Essentially, this request is: "Please tell me the information about the most recent successfully completed delivery by supplier SUP-1002."

[0038] The request is sent to a node in the blockchain network. The "Logistics Tracking Evidence" smart contract on the node is triggered. The contract code accesses the blockchain's distributed state database, quickly searching the index for all records where the shipper is "SUP-1002" and the status is "DELIVERED". Subsequently, the contract code sorts these records by completion timestamp, selecting the complete record with the latest timestamp. Assume this record contains fields such as: waybill number "LOG-20231028-0001", shipper "SUP-1002", consignee "FACTORY-A", final delivery location coordinates "112.543,37.869", and goods receipt timestamp "2023-10-28, 16:45:30". The smart contract packages this complete record data and returns it as the query result to the logical traceability program.

[0039] After receiving the returned blockchain logistics record, the logical traceability program begins parsing the necessary fields. The program precisely extracts the value of the "Final Delivery Location Coordinates" field ("112.543, 37.869") and the value of the "Goods Receipt Timestamp" field ("2023-10-28, 16:45:30") from the record. Subsequently, the program encapsulates this extracted data with the currently processed context information. During encapsulation, a new, standard-format data object (such as a JSON object or an instance of a specific class) is created. This object contains at least the following fields: the field "geographic_coordinates", with a value set to "112.543, 37.869"; the field "timestamp", with a value set to "2023-10-28, 16:45:30"; the field "supplier_id", with a value set to the current provisional supplier identifier "SUP-1002"; and the field "material_code", with a value set to the original material code associated with this supplier identifier in the aggregated data, such as "CAP-100uF-50V". This newly created data object is a complete alternative traceability starting point data entry, indicating that supplier SUP-1002 delivered material CAP-100uF-50V to the coordinate location (112.543, 37.869) at 16:45 on October 28, 2023.

[0040] After processing supplier "SUP-1002", the program continues to iterate through the next candidate supplier unique identifier in the summary list, such as "SUP-1105". The exact same steps are repeated: a query request is constructed pointing to the same smart contract (the query key is changed to "SUP-1105"), the latest completed logistics record is received, the geographical coordinates and timestamp are parsed out, and then encapsulated into a new data entry containing "SUP-1105" and its associated material code.

[0041] The program processes all the unique identifiers of prospective suppliers in the summary list sequentially in this manner. After processing each identifier, a corresponding standard-format data entry is generated. Finally, once all identifiers have been processed, the program collects all the generated data entries, for example, storing them in a list or array. This final collection containing multiple data entries constitutes the structured alternative traceability starting point dataset. Essentially, this dataset utilizes the latest and verified logistical activity information from the prospective supplier group to construct a series of possible destination nodes and their time information based on historical logical inferences for products whose physical trajectory has been lost due to signal interruption.

[0042] In another preferred embodiment of the present invention, the process of generating a product lifecycle data map in step S6 is as follows: A historical query is initiated to the "Logistics Tracking Evidence" smart contract on the blockchain network. The query criteria specify the complete digital identifier string of the product to be traced, such as "ID_7F3A9B_MODELX_P12345". The smart contract retrieves all transaction records containing this identifier string from the blockchain's distributed ledger history. These records are all extracted and formed into a list, where each record corresponds to a physical track data point collected at a specific reader location at a specific time in the past. Subsequently, all records in this list are sorted in ascending order based on their internal "collection timestamp" field. For example, these timestamps might be "2023-10-27, 09:00:00", "2023-10-27, 09:00:30", "2023-10-27, 15:45:22", etc. The sorted list forms a sequence of physical track records arranged in chronological order.

[0043] Next, the program initializes an empty directed graph data structure. This graph structure in memory typically consists of two core parts: a set to store all nodes and a set to store all connecting edges. The program then begins to process the sorted sequence of physical trajectory records sequentially.

[0044] When processing the first record, the program extracts two key attributes: geolocation code (e.g., "116.407,39.904") and collection timestamp (e.g., "2023-10-27, 09:00:00"). The program creates a new graph node in the set of nodes in the graph structure. This node is assigned a unique internal identifier, and its attribute fields are assigned values: the "location" attribute is set to "116.407,39.904", and the "timestamp" attribute is set to "2023-10-27, 09:00:00". Additionally, a "node_type" attribute is set with a value of "physical", explicitly indicating that this node originated from actual physical data collection. Since this is the first node and has no predecessor nodes connected to it, no edges are created at this stage.

[0045] The program then processes the second physical trajectory record in the sequence. Similarly, it extracts its geolocation code (e.g., "121.473,31.230") and collection timestamp (e.g., "2023-10-27, 09:00:30"). Based on this information, a second graph node is created with the "location" attribute set to "121.473,31.230", the "timestamp" attribute set to "2023-10-27, 09:00:30", and the "node_type" attribute also set to "physical". After creating this node, the program immediately establishes a directed edge between the first and second nodes. This edge, pointing from the first node to the second, represents the temporal and spatial transfer of the product from the first location to the second. This directed edge also has attributes, such as setting the "edge_type" attribute to "physical_transfer", and can calculate and store derived information such as time intervals.

[0046] The program continues this process, creating a new "physical" type graph node for each new physical trajectory record read, and immediately establishing a "physical_transfer" type edge between this node and the previously created node. Once all sorted physical trajectory records have been processed, a chain is formed in the graph structure, consisting of sequentially connected "physical" nodes and "physical_transfer" edges. This chain visually represents the recorded flow path of the product in the physical world.

[0047] The program then enters the logical traceability data integration phase. At this point, the logical traceability program has generated an alternative traceability starting point dataset. The program begins reading this dataset. The dataset is a list containing multiple data entries. The program processes each data entry sequentially. For example, the first data entry processed might contain: geographic coordinates "112.543,37.869", timestamp "2023-10-28, 16:45:30", supplier identifier "SUP-1002", and material code "CAP-100uF-50V".

[0048] For this data entry, the program creates a new graph node in the node set of the graph structure. The node's "location" attribute is set to the geographic coordinates "112.543, 37.869" from the data entry, and its "timestamp" attribute is set to the goods receipt timestamp "2023-10-28, 16:45:30" from the data entry. Unlike physical nodes, this node's "node_type" attribute is set to "logical_inferred," indicating that this node is generated based on logical inference rather than direct physical measurement. Assuming this is the first entry in the dataset, this node is the first "logical_inferred" type node to be created.

[0049] At this point, the graph structure contains the ends of two node sequences: one is the last node in the physical trajectory node chain (assuming its timestamp is "2023-10-27, 15:45:22"), and the other is the first logical inference node that was just created (timestamp "2023-10-28, 16:45:30"). To connect the physical trajectory and the logical inference path into a continuous, full-lifecycle graph, a special directed edge needs to be established between these two nodes. This edge points from the last physical trajectory node to the first logical inference node.

[0050] The process of creating this special edge involves specific attribute assignment operations. First, a specific type identifier is assigned to the edge. This identifier is a predefined string constant in the program's global configuration, such as "bridge_physical_to_logical". The edge's "edge_type" attribute is then set to this constant value. Second, key information needs to be extracted as additional attributes of the edge from the alternative traceability starting point data entry upon which this edge is based. The extracted key information includes the "prepared supplier unique identifier" field (e.g., "SUP-1002") and the "original waybill number of the source logistics record" field (e.g., "LOG-20231028-0001") from the data entry. The program stores this information in a structured way in the edge's attribute fields, for example, by adding an attribute named "inference_source", whose value can be a JSON string such as "{'supplier_id':'SUP-1002','waybill_no':'LOG-20231028-0001'}". This special edge not only connects two different types of node sequences, but also carries metadata about the source of this logical connection, ensuring the interpretability and traceability of the graph.

[0051] After processing the first logical data entry, the program continues to read subsequent entries from the dataset. For each new data entry, the program creates a new "logical_inferred" type node. Furthermore, in chronological order, a directed edge is established between the newly created logical inferred node and the previously created logical inferred node. The "edge_type" attribute of this edge can be set to "logical_sequence," indicating the continuity between logical inferred nodes. For example, if the timestamp of the second data entry is "2023-10-29, 09:30:00," then the edge created between the first logical node (timestamp 16:45:30) and the second logical node (timestamp 09:30:00) will record this time span and coordinate changes in its attribute.

[0052] After all alternative tracing starting point data entries have been processed and transformed into nodes and edges integrated into the graph structure, the program performs the final integration and output operations. The program checks and ensures that all nodes in the entire directed graph structure have a global temporal order according to their "timestamp" attribute, forming a timeline from the earliest physical trajectory node to the latest logical inference node. Finally, the program serializes this complete directed graph data structure, which includes "physical" nodes, "logical_inferred" nodes, "physical_transfer" edges, "bridge_physical_to_logical" special edges, and "logical_sequence" edges. The serialization format can be a standard graph file format such as GraphML or GEXF, or a customized JSON object containing a list of nodes and edges. This serialized graph structure is the final product lifecycle data map, which presents the actual trajectory of the product during the physical signal acquisition phase in a machine-readable and visual way, as well as the potential paths supplemented by logical inference after the physical signal is interrupted, thus achieving a complete data chain structure.

[0053] The foregoing has provided a detailed description of one embodiment of the present invention, but this description is merely a preferred embodiment and should not be construed as limiting the scope of the invention. All equivalent variations and modifications made within the scope of the claims of this invention should still fall within the patent coverage of this invention.

Claims

1. A product lifecycle management method based on digital identification, characterized in that, Includes the following steps: S1. Generate a structured digital identifier based on the initial bill of materials for the target product, write the identifier into the product's RFID tag, and register the identifier to the blockchain network; S2. Periodically collect the signal strength, location coordinates and collection timestamp of the RFID tag, generate physical trajectory records and upload them to the blockchain network; S3. Monitor signal strength. When the signal strength is lower than the dynamically calculated strength threshold for a continuous period, determine that the physical signal acquisition has been interrupted and trigger the logic tracing program. S4. The logical traceability program obtains a digital identifier from the blockchain network, parses the product model code embedded in the identifier, and retrieves the corresponding complete initial bill of materials accordingly. S5. Based on the material codes in the bill of materials, query the supplier relationship data to determine the prospective supplier for each material. Extract the final logistics coordinates and timestamps recorded by each prospective supplier when it most recently completed the delivery from the blockchain network to form a dataset of alternative traceability starting points. S6. Merge the physical trajectory records and alternative traceability starting point datasets according to time order to generate a product lifecycle data map with geographical coordinates as nodes and spatiotemporal transfer relationships as edges.

2. The product lifecycle management method based on digital identification according to claim 1, characterized in that, In step S2, the process of generating and uploading physical trajectory records is as follows: Scan the signal coverage area of ​​the RFID tag at preset fixed time intervals. When the digital identifier stored in the RFID tag is read, record the time of reading as the collection timestamp, and record the pre-stored geolocation code and the wireless signal strength value received in this reading operation. The digital identifier string, collection timestamp, geolocation code, and signal strength value are combined into a complete physical trajectory record. The physical trajectory record is sent to the logistics trajectory evidence storage contract in the blockchain network. The logistics trajectory evidence storage contract verifies the record format and then stores it in the distributed ledger.

3. The product lifecycle management method based on digital identification according to claim 1, characterized in that, In S3, the process of dynamically calculating the intensity threshold is as follows: From the blockchain logistics trajectory storage contract, query and download historical signal strength data of all RFID tags for the same product model in the most recent historical period, and divide all historical data into multiple independent data sets based on the geographical location code of the collected historical data. For each independent dataset corresponding to a geographic location code, calculate the lower bound of the distribution of all signal strength values ​​within the dataset, summarize and calculate the arithmetic mean of the lower bounds of the distributions corresponding to all geographic location codes to obtain the basic signal strength reference value, obtain the number of signal interference events reported by the current monitoring location in the past few operating cycles, and adjust the basic signal strength reference value upward based on the number of signal interference events. The result after compensation is the strength threshold.

4. The product lifecycle management method based on digital identification according to claim 1, characterized in that, In S4, the process of the logic traceability program retrieving the complete initial bill of materials is as follows: Initiate a query request to the product registration contract of the blockchain network to obtain a digital identifier, carry product information associated with the interruption event in the query request, and extract the complete string of the digital identifier from the registration record returned by the blockchain network; Parse the header field of the digital identifier string to obtain the product model code. Based on the product model code, access the external product data management service and obtain the storage address of the complete design document corresponding to the product model. Obtain the design document from the storage address and parse the complete initial bill of materials for the product from a specific section of the design document. The complete initial bill of materials contains the codes of all constituent materials and the corresponding preferred supplier information.

5. The product lifecycle management method based on digital identification according to claim 1, characterized in that, In step S5, the process of querying supplier relationship data based on material codes and determining potential suppliers is as follows: The system sequentially reads the complete initial bill of materials obtained from the external product data management service. For each material code explicitly recorded in the bill of materials, a query operation is initiated in the supplier relationship database. The query operation conditions are set as follows: the goods code field of the supplier recorded in the database must be completely consistent with the current material code, and the supplier's cooperation status field must be a specified valid status value. Receive all supplier records that meet the criteria. Each record contains a unique supplier identification code. Collect all returned unique supplier identification codes to form a preliminary supplier identity set for the current material code. Iterate through all material codes in the complete initial bill of materials and repeat this process until a summary of the preliminary supplier identity sets related to all materials is obtained.

6. The product lifecycle management method based on digital identification according to claim 5, characterized in that, In S5, the process of forming the alternative tracing starting point dataset is as follows: For each unique identifier of a prospective supplier in the summary, construct a structured data query request. The query request points to the logistics trajectory storage contract of the blockchain network. The request includes the unique identifier of the prospective supplier as the query key and requires the contract to return the first record with the identifier as the shipper, the logistics status as the final completed status, and sorted in descending order by the completion timestamp. The system receives complete logistics records that meet the requirements from the blockchain network, extracts the geographical coordinates of the final delivery location and the timestamp of the goods receipt confirmation, and encapsulates the geographical coordinates, timestamp, corresponding alternative supplier unique identification code and its associated original material code into a standard format alternative traceability starting point data entry. It iterates through all alternative supplier unique identification codes and repeats this encapsulation operation, and collects all generated alternative traceability starting point data entries to form a structured alternative traceability starting point dataset.

7. The product lifecycle management method based on digital identification according to claim 1, characterized in that, In step S6, the process of generating a product lifecycle data map is as follows: Retrieve all physical trajectory records associated with the product's digital identifier from the blockchain ledger and sort them by timestamp. Process each physical trajectory record sequentially, creating a corresponding graph node in a directed graph structure. The node's attributes include the geolocation code and collection timestamp from the record. In chronological order, establish a directed connection edge between each newly created node and its predecessor, representing temporal continuity and spatial transition relationships. After traversing all physical trajectory records, the alternative traceability starting point dataset is read. For each data entry in the dataset, a new graph node is created in the directed graph structure. The node's attributes include the geographical coordinates and the goods receipt timestamp in the entry. Between the node created by the last physical trajectory record and the node created by the first alternative traceability data entry, a directed connection edge with a specific type identifier is created. The directed connection edge represents the connection from the measured physical trajectory to the logical inference path. All nodes and edges are integrated to output a complete directed graph structure as a product lifecycle data map.

8. A product lifecycle management method based on digital identification according to claim 7, characterized in that, The process of creating a directed connection edge with a specific type identifier is as follows: The value of the specific type identifier is a predefined string constant. Key information of the alternative traceability starting point data entry is extracted from the alternative traceability starting point data entry on which the directed connection edge is based. The key information includes the pre-existing supplier unique identification code and the original waybill number of the source logistics record. The extracted key information is stored as an additional attribute along with the specific type identifier in the attribute field of the directed connection edge.

Images