Circuit chip production information tracing method and system

Abstract

The application discloses a circuit chip production information tracing method and system, and relates to the fields of semiconductor manufacturing and information technology. The method comprises the following steps: generating a unique identification for each chip based on wafer identification, physical coordinates and a monotonically increasing count value through a hash algorithm; adopting a two-stage fine engraving process to engrave the identification on the chip; collecting process parameters of each process through an edge computing node in real time and packaging the identification to form a process event record; uploading the process event record to a central tracing engine and aggregating the process event record according to the identification to form a single-chip full-process process path chain; dynamically calculating a waiting time window based on historical processing time by the central tracing engine and monitoring the integrity of the flow, and determining that the tracing is interrupted if the waiting time window exceeds the time limit; and returning the complete process path chain and the state in response to a query request. The application realizes fine tracing at the single-chip level, connects multi-process heterogeneous data through a unified identification and a data model, and improves the efficiency of quality control and failure analysis.

Description

Technical Field

[0001] This application belongs to the interdisciplinary field of semiconductor manufacturing and information technology, and specifically relates to a method and system for tracing information on circuit chip production. Background Technology

[0002] With the continuous evolution of semiconductor manufacturing processes, the production process of integrated circuit chips has become increasingly complex, encompassing multiple high-precision steps such as photolithography, etching, thin film deposition, electrical testing, and packaging. In current industry practice, each process step is typically executed independently by dedicated equipment provided by different manufacturers, and key data such as process parameters, test results, and operation logs are stored in local databases or Manufacturing Execution Systems (MES). To achieve quality control and failure analysis, the industry generally uses the batch number (Lot ID) as the traceability primary key, treating all chips within the same wafer batch as homogeneous units for management. However, this method cannot distinguish the actual process path and parameter deviations experienced by a single chip (Die) at the microscopic level, making it difficult to meet the refined requirements for tracking the entire lifecycle data of individual chips under advanced processes.

[0003] The core challenge of end-to-end chip traceability lies in the ability to integrate data across processes and systems. Existing traceability mechanisms, when faced with heterogeneous environments such as front-end wafer manufacturing, mid-stage testing, and back-end packaging, suffer from a lack of unified data models and semantic standards, making it difficult to automatically align records at each stage. When yield anomalies or reliability issues occur, engineers must manually extract data from multiple isolated systems and piece together possible process links based on experience, which is not only time-consuming and labor-intensive but also prone to missing critical anomaly nodes. Furthermore, due to diverse equipment interface protocols and inconsistent data formats, real-time acquisition and structured packaging of single-chip-level process events present significant technical obstacles, causing the traceability chain to frequently break at process junctions.

[0004] Therefore, there is an urgent need for a method and system for tracing circuit chip production information that can use a single chip as the smallest traceability unit and support multi-process collaboration and automatic data aggregation. Summary of the Invention

[0005] The purpose of this invention is to provide a method and system for tracing circuit chip production information, which can effectively solve the problems mentioned in the background art.

[0006] To achieve the above objectives, the technical solution adopted by the present invention is as follows: Firstly, a method for tracing circuit chip manufacturing information includes the following steps: A unique identifier is generated for each chip. The unique identifier is calculated by a hash algorithm based on the wafer identifier of the current wafer, the chip's physical coordinates on the wafer, and a monotonically increasing count value generated by the security element. A two-stage fine-refinement engraving process is adopted to engrave a unique identifier on the chip. The two-stage fine-refinement engraving process includes a first stage of using a first laser beam to etch out the character outline, and a second stage of using a second laser beam to finely refine the interior of the outline. At each critical process step, edge computing nodes collect the chip's process parameters in real time during the manufacturing process, and associate the process parameters with the chip's unique identifier, encapsulating them into process event records; The process event records are uploaded to the central traceability engine. The central traceability engine aggregates all process event records belonging to the same chip in chronological order based on the unique identifier, forming the entire process path chain of a single chip. The central traceability engine dynamically calculates the waiting time window for each chip based on the historical processing time of each process step, and monitors its actual waiting time. If the waiting time window is exceeded, it is determined to be a traceability interruption. In response to a query request containing a unique identifier, return the complete process path chain and traceability status of the corresponding chip.

[0007] Preferably, the step of generating a unique identifier for each chip specifically includes: Obtain the wafer identifier assigned by the manufacturing execution system, and the micron-level physical coordinates of the chip on the wafer output by the wafer alignment system; The wafer identifier, physical coordinates, and cyclic redundancy check code are concatenated and then combined with a 48-bit monotonically increasing count value generated by the security element in the edge computing node to form the input data string. Perform a SHA-256 hash operation on the input data string and extract the first 32 characters of the result as the chip's unique identifier.

[0008] Preferably, in the two-stage fine engraving process, the engraving depth in the first stage is controlled at 0.6 to 0.9 micrometers, and the final engraving depth in the second stage is controlled at 0.8 to 1.2 micrometers; Furthermore, before performing the etching, the process includes a step of dynamically retrieving laser etching parameters from a preset process parameter library based on the thin film stacking information of the chip's location.

[0009] Preferably, after the unique identifier is engraved, the process also includes online engraving quality inspection and compensation. The unique identifier of the engraved area is imaged and identified using an online optical detection module. If recognition fails or the quality parameters do not reach the threshold, it is determined to be a poor engraving. For minor defects, re-etching is performed at the same chip location, and the laser power density of the re-etching is increased by 5% to 10% compared to the original etching parameters; For serious defects, the chip is marked as invalid and reported to the manufacturing execution system so that it can be removed in subsequent processes.

[0010] Preferably, process event records are encapsulated according to a predefined unified data model, which includes at least: The die_id field is used to store a unique identifier, the process_step field is used to identify the current process step, and the parameters field is used to store the set of process parameters. The parameters field is a dynamic dictionary structure, in which each process parameter value is independently accompanied by the acquisition timestamp of the parameter and the sensor identifier that generated the parameter.

[0011] Preferably, the edge computing node establishes a real-time data channel with different types of process equipment controllers through a communication interface that supports SECS / GEMHSMS, ModbusTCP, IEEE488.2GPIB and EtherCAT protocols, and captures and extracts the raw process data associated with a single chip in real time through an event listening mechanism.

[0012] Preferably, the edge computing node has a built-in FPGA or GPU coprocessor for parallel execution of hash algorithms; The main processor and coprocessor of the edge computing node work together through a dual-buffer mechanism. After the main processor writes the data to be calculated into the first buffer, the coprocessor immediately starts the calculation. At the same time, the main processor writes the data of the next chip into the second buffer, realizing the pipelined and parallel processing of the hash calculation task.

[0013] Preferably, the central traceability engine dynamically calculates the waiting time window for each chip that is waiting for the next expected process. The waiting time window is obtained by multiplying the historical average processing time of the next expected process by a safety factor. The central traceability engine periodically scans all chips in a waiting state. If the actual waiting time of a chip since the completion of the current process exceeds its corresponding waiting time window, it is determined to be a traceability interruption.

[0014] Preferably, after determining that an interrupt has occurred, the method further includes the step of analyzing the spatial distribution characteristics of the interrupt chip: Based on the chip's physical coordinates, determine its designated area on the wafer; Count the number of chips that experience consecutive traceability interruptions within the same preset area; If the number of consecutive interruptions reaches a preset threshold, the alarm level will be upgraded, and an emergency notification containing the interruption location and associated device identifier will be pushed to the designated terminal.

[0015] Secondly, a circuit chip manufacturing information traceability system includes: Multiple edge computing nodes are deployed at various key process equipment locations. Each edge computing node includes: Safety element used to generate a monotonically increasing count value; The data acquisition module is used to acquire raw process data related to a single chip in the process equipment in real time through various industrial communication protocols; The identifier generation and engraving control module is used to generate a unique identifier for the chip based on the wafer identifier, chip physical coordinates and monotonically increasing count value through a hash algorithm, and to control the laser engraving equipment to engrave the unique identifier on the chip using a two-stage fine engraving process. The data processing and encapsulation module is used to associate the collected raw process data with unique identifiers and encapsulate it into process event records. The secure communication module is used to encrypt process event records and upload them via a long connection; A central tracing engine, communicating with each edge computing node, includes: The receiving and verification module is used to receive and decrypt encrypted data from edge computing nodes; The data aggregation module is used to store the received process event records in chronological order using a unique identifier as the key, and to build a complete process path chain for each chip. The integrity monitoring module is used to dynamically calculate the waiting time window for each chip based on the historical processing time of each process step, monitor the integrity of its flow process, and mark the abnormal state when a traceability interruption is detected. The query interface module is used to respond to external query requests and return the complete process path chain and status information of the corresponding chip.

[0016] In summary, this application includes at least one of the following beneficial technical effects: 1. This invention generates a unique hash identifier for each chip based on wafer identification, physical coordinates, and security count value, and uses a two-stage fine-tuning and marking process for physical marking. This enables refined management with a single chip as the smallest traceability unit, accurately tracking the process parameter deviations of each chip throughout the entire process, and effectively overcoming the shortcomings of traditional batch-level traceability in locating individual problems.

[0017] 2. This invention collects data from multi-source heterogeneous devices in real time through edge computing nodes, encapsulates it into process event records according to a unified data model, and combines digital signatures and encrypted transmission to ensure the real-time nature of data collection, the consistency of format, and the security of the transmission process, thus solving the problems of difficult cross-process data integration and low efficiency of manual splicing.

[0018] 3. This invention dynamically calculates the waiting time window and monitors the integrity of chip flow through a central traceability engine. It can automatically identify traceability interruptions caused by missing data collection or equipment malfunctions, and achieve accurate early warning by combining spatial distribution analysis, which significantly improves the timeliness of anomaly detection and the accuracy of fault location. Attached Figure Description

[0019] Figure 1 This is a flowchart illustrating the circuit chip manufacturing information traceability method of the present invention; Figure 2 This is a flowchart illustrating the process of achieving full-process traceability of a single chip based on a unique die ID and a unified data model, according to the present invention. Figure 3 This is a schematic diagram of the process by which edge computing nodes collect, encapsulate, and encrypt process event records on key process equipment in this invention; Figure 4 This is a schematic diagram of the multi-level interaction relationship and data flow of the central traceability engine in this invention, which aggregates the process path chain, detects traceability integrity, and responds to query requests. Detailed Implementation

[0020] The circuit chip manufacturing information traceability method of this invention relies on the collaborative work of edge computing nodes deployed on the production site and a central traceability engine deployed in the data center. Edge computing nodes are deployed at each key process equipment, and have built-in control units, security elements, and data acquisition modules. They are responsible for real-time data collection from the equipment, generating unique chip identifiers, and encapsulating process event records. The central traceability engine is responsible for receiving and aggregating data uploaded by all edge computing nodes, forming a complete process path chain for a single chip, and providing traceability query and integrity detection functions. The following detailed description of the specific steps is provided.

[0021] For ease of description, the following abbreviations are used in this application: MES stands for Manufacturing Execution System, Die ID stands for Die Identifier, HSMS stands for High-Speed ​​Message Service, TLS stands for Transport Layer Security, and JWT stands for JSON Web Token.

[0022] Specifically, refer to Figures 1 to 4 As shown, this application provides a method for tracing circuit chip manufacturing information, including the following steps: Step S1: Assign a unique identifier (hereinafter referred to as Die ID) to each chip.

[0023] Step S101: Obtain the wafer ID of the current wafer. The wafer ID is assigned by the Manufacturing Execution System (MES) before the wafer enters the production line. It adopts a 12-digit alphanumeric format and contains the plant code, process node code and serial number information, which is used to uniquely identify the batch of wafers.

[0024] Step S102: Read the physical coordinates of each chip on the wafer. These physical coordinates are scanned and output by the wafer alignment system before the wafer is loaded onto the first process equipment. The coordinate values ​​are in micrometers, and the accuracy in both the X and Y directions is controlled within ±0.5 micrometers. The coordinate information accurately describes the specific position of each chip on the wafer.

[0025] Step S103: Concatenate the wafer ID with the chip's X and Y coordinates to form a raw string, and append a 32-bit Cyclic Redundancy Check (CRC-32) code to the end of this string to form a complete data string to be hashed.

[0026] The CRC checksum is used to increase the randomness of input data and reduce the probability of hash collisions. The CRC-32 algorithm is an industry standard algorithm that generates a 4-byte checksum, which can be directly appended to the end of the string.

[0027] Step S104: To enhance the anti-collision and security of the unique identifier, before inputting the original string composed of the wafer ID, chip coordinates and CRC check code into the hash function, a 48-bit monotonically increasing count value is generated by the security element in the edge computing node as the Nonce. This Nonce value is automatically incremented by one after each Die ID is generated for a chip, ensuring that the input data string for each hash operation is globally unique.

[0028] The wafer ID, chip X coordinate, chip Y coordinate, CRC checksum, and Nonce value are then concatenated in sequence into a complete string, which serves as the final input data string.

[0029] The above mechanism can effectively prevent identification conflicts caused by coordinate measurement errors or duplicate wafer IDs, and ensure the uniqueness of the Die ID throughout its entire lifecycle.

[0030] Step S105: Perform a one-way hash operation on the final input data string generated in step S104 using the SHA-256 hash algorithm. After the operation, a hash value of 64 hexadecimal characters is obtained. The first 32 characters are taken as the Die ID of the chip.

[0031] Due to the avalanche effect of the SHA-256 algorithm, the probability of duplicate Die IDs between any two different chips is lower than [missing information]. This ensures uniqueness across the entire production line.

[0032] Step S106: Dynamic configuration of laser marking parameters. Before laser marking, the laser marking equipment dynamically retrieves the optimal marking parameter set from the preset process parameter library based on the thin film stacking information and material characteristics of the current chip area.

[0033] Thin film stacking information includes the type and thickness of passivation layers, low-k dielectric layers, or other materials covering the surface of the dicing area, provided by the metrology equipment of the previous process and associated with the current wafer ID.

[0034] The parameter set includes at least the laser wavelength, such as 355 nm or 532 nm, the pulse width, such as picosecond or femtosecond, the repetition rate, and the power density.

[0035] By dynamically adapting parameters, we ensure that high-contrast and sharp-edged logo patterns can be formed on different materials.

[0036] Step S107: To avoid thermal effects and debris contamination from a single high-energy engraving, a two-stage engraving process of rough engraving and fine finishing is adopted.

[0037] In the first stage, a laser beam with a large focused spot is used to quickly ablate the outline of the Die ID character, with the imprinting depth controlled to be 0.6 to 0.9 micrometers.

[0038] In the second stage, a laser beam with a smaller focused spot and lower energy is used to perform a fine scan and trim the inside of the contour. This removes residue and precisely controls the final depth within the target range of 0.8 to 1.2 micrometers, forming a smooth groove bottom to enhance the contrast of subsequent optical recognition.

[0039] Step S108: Online engraving quality inspection and compensation.

[0040] After laser engraving is completed, the online optical inspection module located next to the engraving station immediately images and identifies the Die ID of the engraved area. The online optical inspection module includes a high-resolution industrial camera, a ring light source, and an image processing unit.

[0041] The image processing unit first preprocesses the acquired image, including noise reduction and contrast enhancement. Then, it calls the optical character recognition algorithm to convert the characters in the image into text, while calculating quality parameters such as grayscale contrast of the character region and integrity of the character connectivity.

[0042] If optical character recognition is successful and all quality parameters are within the preset threshold range, the engraving is deemed qualified; if optical character recognition fails, character connectivity is broken or missing, or contrast is lower than the preset lower limit, the engraving is deemed defective.

[0043] The control unit built into the edge computing node executes the corresponding compensation strategy according to the defect type, which is divided into two categories: minor defects and severe defects.

[0044] Minor defects refer to characters that are identifiable but have partial incompleteness, contrast slightly below the threshold, or initial recognition failure with acceptable image quality. For minor defects, the control unit triggers the laser engraving equipment to perform a re-engraving at the same chip location. During re-engraving, the laser power density is increased by 5% to 10% based on the original engraving parameters, or the pulse width is increased. The specific adjustment amount is calculated using a built-in empirical formula based on the degree of defect. After re-engraving, a second inspection is performed. If it still fails, it is upgraded to a serious defect.

[0045] A serious defect refers to a chip with characters that are completely unrecognizable, a large area that is missing, or a chip that fails to be re-engraved after multiple attempts. For serious defects, the control unit marks the chip as ID_MARK_FAIL in the corresponding status field and reports the defect coordinates, Die ID, and inspection image to the Manufacturing Execution System (MES) so that the chip can be removed or scrapped by an automatic sorting device in the subsequent process to prevent unmarked chips from entering the market.

[0046] All detected images, recognition results, and compensation operation records are bound to the Die ID as quality data and stored in the local database of the edge computing node.

[0047] Step S109: Simultaneously establish the identifier mapping and status mark. After the edge computing node successfully generates the Die ID and completes the imprinting, it immediately writes the mapping relationship between the Die ID and the chip's physical coordinates X and Y into the local cache, and at the same time marks the chip's status as allocated.

[0048] Edge computing nodes are deployed at the beginning of the production line and are responsible for maintaining an identification mapping table for all chips on the current wafer. This identification mapping table is stored with chip coordinates as keys and Die IDs as values.

[0049] When processing chips, subsequent equipment in each process can achieve cross-process data association and traceability by reading the Die ID on the chip or querying the corresponding Die ID from the edge computing node based on its physical coordinates.

[0050] Step S110: Pipeline and parallel processing of hash calculation tasks.

[0051] To match the production cycle of high-speed production lines, edge computing nodes have built-in FPGA or GPU coprocessors specifically responsible for executing the SHA-256 hash algorithm. The edge computing node continuously sends the input data string generated in step S104 to the coprocessor in the form of a data stream through a high-speed bus. The coprocessor adopts a pipelined architecture and can process multiple data blocks in one clock cycle. At the same time, the main processor CPU continues to perform tasks such as device control and data acquisition, forming a parallel operation with the hash calculation of the coprocessor.

[0052] The implementation employs a double-buffer mechanism: after the CPU writes the data to be computed into the first buffer, the coprocessor immediately begins computation; simultaneously, the CPU writes the data from the next chip into the second buffer. When the coprocessor completes its current computation and outputs the result, it seamlessly switches to the second buffer to continue computation, thus achieving a continuous pipeline with no waiting.

[0053] Step S2: Deploy edge computing nodes on each key process equipment.

[0054] Step S201: Deploy an edge computing node hardware platform at each critical process equipment. This hardware platform uses an industrial-grade embedded computer, and its core components must meet the following minimum configuration requirements: The central processing unit is equipped with an ARM Cortex-A72 quad-core processor with a main frequency of no less than 1.8 GHz, 4 gigabytes of DDR4 memory, 64 gigabytes of industrial-grade SLC NAND flash memory, dual gigabit Ethernet interfaces for network communication, and an isolated RS-485 serial interface for connecting to older devices.

[0055] The above configuration ensures that the edge computing nodes have sufficient computing performance and adaptability to industrial environments, and can withstand temperature fluctuations, electromagnetic interference and vibration environments within the wafer fab.

[0056] Step S202: Install and run a lightweight real-time operating system (RTOS) on the edge computing node, and set the system task scheduling cycle to 10 milliseconds.

[0057] The choice of real-time operating system includes FreeRTOS, VxWorks, or similar kernels. By configuring the system clock and task priorities, it is ensured that all data acquisition, processing, and communication tasks are completed within a deterministic time window. This avoids data loss or timestamp errors caused by scheduling delays of general-purpose operating systems, and guarantees the real-time performance and accuracy of data acquisition.

[0058] Step S203: Edge computing nodes establish real-time data channels with their respective connected process equipment controllers using the device's native communication protocol. The appropriate standard protocol is selected for different types of equipment. For lithography machines, the SECS / GEM HSMS protocol is used for communication based on TCP / IP. Edge computing nodes need to be configured as HSMS active connection ends, setting the device's IP address and port number, and negotiating to establish a session. For etching machines and chemical vapor deposition equipment, the Modbus TCP protocol is used, with edge computing nodes acting as Modbus clients, periodically polling or subscribing to changes in device registers; For the probe test station, the IEEE 488.2 GPIB protocol is adopted. The edge computing node connects to the device through the GPIB-USB controller and sends standard commands to read test data. For the chip mounter, the EtherCAT protocol is used, with the edge computing node acting as the EtherCAT master station, exchanging data with the slave devices in real time via network interface card.

[0059] Edge computing nodes are pre-configured with communication parameters for each device, including IP address, port number, protocol timeout, and number of retries, to ensure a stable and reliable connection.

[0060] In step S204, the edge computing node starts the event listening mechanism to sense the moment when a single chip enters the processing area of ​​the equipment in real time. When the chip arrives at the workstation, the equipment controller will send a trigger signal. This signal can be a hardware digital output, a distributed clock synchronization event based on EtherCAT, or a CEID event notification sent through the SECS / GEM protocol.

[0061] Edge computing nodes receive trigger signals through corresponding interfaces. For digital signals, edge computing nodes capture rising edges through GPIO interrupts. For network events, edge computing nodes register callback functions in the protocol stack. After the trigger signal arrives, the edge computing node immediately extracts all raw data streams related to the chip from the controller buffer.

[0062] The extraction method depends on the device type. For devices that support active push, edge computing nodes receive data through subscription. For devices that only support polling, edge computing nodes send a read command immediately after receiving a trigger to obtain sensor readings, actuator instruction feedback, process alarm records, and authentication information entered by the operator through a card reader from the buffer.

[0063] Edge computing nodes must be able to accurately identify and retrieve all data associated with a chip based on the identification information provided by the device, such as wafer ID or chip serial number, without missing any critical information.

[0064] In step S205, all extracted raw data is temporarily stored in the local memory of the edge computing node. The storage time is strictly controlled within 500 milliseconds. The edge computing node uses a circular buffer to manage memory. Data packets of each chip are stored independently and accompanied by a receiving timestamp.

[0065] After the temporary storage is completed, the original data is immediately transferred to the structured encapsulation process, which is the unified data model processing stage described in the subsequent step S3.

[0066] This short-term caching mechanism can handle instantaneous data spikes while avoiding the risk of data overflow caused by prolonged data retention in memory. If data cannot be processed within 500 milliseconds due to abnormal circumstances, a timeout alarm is triggered and the event is recorded for subsequent investigation.

[0067] Step S3: Package the process event records according to the unified data model.

[0068] Step S301: First, define the field structure of the unified data model. This unified data model is instantiated in the memory of the edge computing node using the TraceRecord class and must contain the following six core fields: The die_id field is a 32-character string used to store the Die ID generated in step S1. This identifier ensures that each chip can be uniquely identified throughout the entire production cycle.

[0069] The `process_step` field is an enumeration type, and its value must be a preset standard process code. For example, `LITHOGRAPHY` represents the photolithography process, `ETCHING` represents the etching process, `CVD` represents the chemical vapor deposition process, `PROBE_TEST` represents the probe testing process, and `PACKAGING` represents the packaging process. These codes are consistent with the actual process flow in the factory, which facilitates subsequent cross-process data aggregation and querying.

[0070] The equipment_id field is the equipment asset number, which is uniformly assigned by the factory equipment management system. It is in the format of an 8-digit number and can be used to trace the specific equipment model, manufacturer, and maintenance records for the current process.

[0071] The operator_id field is the operator's employee number, which is 6 digits long. This information is obtained in real time when the operator logs into the device via the device's card reader and is collected along with process events for subsequent quality responsibility traceability.

[0072] The event_time field is an ISO 8601 format timestamp accurate to microseconds. This timestamp is generated by the local high-stability crystal oscillator of the edge computing node and is periodically synchronized with the Network Time Protocol (NTP) server to ensure that the time base of each edge computing node is consistent, providing a basis for subsequent timeline sorting and integrity detection.

[0073] The parameters field is a dynamic dictionary structure used to store the set of key process parameters for the current process. The key names and key values ​​of this dictionary are automatically adapted according to the process type. Different process types correspond to different parameter sets, and the specific mapping relationship is defined by the parameter mapping table in the edge computing node.

[0074] Step S302: For different process types, define corresponding process parameter key-value pairs in the parameters field. Taking the photolithography process as an example, the parameters dictionary must contain the following keys, each key corresponding to a specific process parameter, with units and typical ranges: The exposure_dose key represents the exposure dose, measured in millijoules per square centimeter (mJ / cm²), with a typical value range of 15 to 35. This parameter directly affects the photosensitivity of the photoresist.

[0075] The `overlay_error_x` key represents the overlay error in the X direction, measured in nanometers (nm), with a typical range of ±50. It is used to measure the alignment accuracy between the current layer and the reference layer.

[0076] The `overlay_error_y` key indicates the overlay error in the Y direction, measured in nanometers (nm), with a range of ±50.

[0077] The chamber_temperature key represents the temperature of the reaction chamber, in degrees Celsius, ranging from 22 to 24 degrees. This temperature affects the chemical reaction rate of the photoresist.

[0078] The `relative_humidity` key represents relative humidity, expressed in %RH, ranging from 40 to 60%. Humidity control is crucial for the stability of the photolithography process.

[0079] The above parameter values ​​are all parsed from the raw data stream reported by the lithography machine through the SECS / GEM protocol. The edge computing node is pre-configured with a parameter mapping table to establish a correspondence between the names of the original data items of the device, such as ExposureDose and OverlayErrorX, and the keys of the parameters dictionary, and automatically completes the conversion and filling when the data is received.

[0080] Step S303: In the etching process, the parameters field must contain the following keys: The gas_ratio_cf4_o2 bond represents the flow ratio of carbon tetrafluoride to oxygen, which is a dimensionless ratio with a typical value range of 0.8 to 1.2. This ratio directly affects the etching rate and sidewall morphology.

[0081] The `rf_power` key represents the radio frequency power, measured in watts (W), ranging from 500 to 1500. The power level determines the plasma density and ion energy.

[0082] The etch_rate key represents the etching rate, measured in nanometers per minute (nm / min), ranging from 80 to 120. This parameter reflects how quickly the material is removed and is typically calculated in real time by an endpoint detection system.

[0083] These parameter values ​​are obtained from the etching device controller via the Modbus TCP protocol. The edge computing nodes periodically poll or receive data actively pushed by the device and extract the corresponding values ​​according to the predefined register address mapping table.

[0084] Step S304: In the electrical testing procedure, the parameters field must contain the following keys: The open_circuit_voltage key represents the open-circuit voltage, in volts (V), ranging from 0.6 to 0.8. This parameter reflects the characteristics of the PN junction inside the chip.

[0085] The short_circuit_current key represents the short-circuit current, measured in milliamperes (mA), ranging from 10 to 50, and is used to evaluate the current-driving capability of a device.

[0086] The leakage_current_threshold key represents the leakage current threshold, in nanoamperes (nA), with a threshold of 100. This parameter is used to determine whether the leakage current of the chip exceeds the limit under a specific bias voltage.

[0087] Electrical test data is read from the probe test station via the IEEE 488.2 GPIB protocol. After receiving the trigger signal, the edge computing node sends a standard command set to obtain the test results and parse them into corresponding values.

[0088] In step S305, each parameter value must be stored along with its own acquisition timestamp and sensor ID metadata to ensure that it can be traced back to the specific sensor and acquisition time during subsequent analysis.

[0089] This is achieved by constructing the value of each parameter as an object containing three subfields: the value subfield stores the actual numerical value of the parameter; the timestamp subfield stores the acquisition time of the parameter, in the same format as event_time, accurate to microseconds; and the sensor_id subfield identifies the sensor or data source that generated the parameter. For example, for a chamber temperature parameter, sensor_id can correspond to the temperature sensor number inside the device.

[0090] The data acquisition timestamp is recorded by the edge computing node when it receives the data, or obtained directly from the time field extracted from the device data packet; the sensor ID is parsed from the device data stream, and if the device does not provide it, the edge computing node can fill it in according to the pre-configured default value.

[0091] Step S306: After assigning values ​​to all fields, serialize the TraceRecord object into a UTF-8 encoded JSON string. The serialization process is implemented using a standard JSON library to ensure the universality and parsability of the data format.

[0092] The average length of the serialized string needs to be controlled within 1.2KB. This metric is ensured by reasonably selecting the number of parameters and the precision of the values, so as to meet the network transmission efficiency while retaining sufficient process information.

[0093] The serialized data will then be used for subsequent encryption and uploading processes.

[0094] Step S4: Encrypt and upload structured data to the central traceability engine.

[0095] In step S401, the edge computing node first performs digital signature calculation on the JSON format string generated in step S306. The signature algorithm adopts ECDSA based on elliptic curve cryptography, and the selected curve is the standardized NIST P-256 curve.

[0096] The signing private key is generated during initialization by the security element built into the edge computing node and is permanently stored inside the security element. The private key is never exported to external storage or memory to ensure that it cannot be read or tampered with externally. The public key corresponding to the private key needs to be exported in advance and registered in the trust list of the central traceability engine for subsequent verification of signature validity.

[0097] In step S402, after completing the digital signature, the edge computing node performs symmetric encryption on the original JSON data along with the digital signature. The encryption algorithm adopts AES-128-GCM, which is an authentication encryption mode that can simultaneously provide data confidentiality and integrity verification. The session key required for encryption is generated through the TLS 1.3 handshake process between the edge computing node and the central traceability engine when establishing an MQTT connection.

[0098] Specifically, the two parties first establish a TCP connection, then perform a TLS 1.3 handshake to negotiate a temporary master key, and derive a 128-bit AES-GCM key and initialization vector from this master key. This session key is only used for the lifetime of this connection and is renegotiation every time the connection is reconnected, thereby ensuring forward security.

[0099] Step S403: Encapsulate the encrypted binary data into an MQTT PUBLISH message. The message topic is constructed according to a fixed format as / trace / {equipment_id} / {process_step}, where equipment_id is the current device number and process_step is the current process code.

[0100] The Quality of Service (QoS) level is set to 1 to ensure that messages are delivered to the central tracing engine at least once, avoiding data loss due to network packet loss. If the acknowledgment times out, the edge computing node will retransmit the message until an acknowledgment is received or the maximum number of retries is reached.

[0101] In step S404, the edge computing node maintains a long MQTT connection with the central tracing engine, with a heartbeat interval of 30 seconds. The edge computing node sends a PINGREQ message to the server in each heartbeat interval, and the server replies with a PINGRESP message to confirm that the connection is alive.

[0102] When a network anomaly causes a connection to be lost, the edge computing node's built-in reconnection mechanism will automatically attempt to re-establish the connection within 5 seconds and re-perform the TLS handshake and MQTT connection to ensure the continuity of data transmission.

[0103] Step S405: In a high-concurrency production scenario, if a large number of records to be sent are generated in a short period of time, the edge computing node uses a built-in circular buffer queue to smooth out traffic spikes. This queue is implemented using a circular buffer with a maximum capacity of 1,000 records.

[0104] When network congestion occurs or the central tracing engine is temporarily unavailable, newly generated records are first stored at the tail of the queue. If the queue is full, the old records at the head of the queue are discarded according to the first-in-first-out principle. At the same time, a packet loss alarm is recorded to prevent memory overflow. After the network is restored, the edge computing nodes take records from the head of the queue in the first-in-first-out order and continue to send them until the queue is cleared.

[0105] Step S406: The entire encryption and encapsulation process is completed locally on the edge computing node, with the time strictly controlled within 8 milliseconds. The size of the encrypted data packet increases by no more than 15% compared to the original JSON data, ensuring that the transmission efficiency is not significantly affected. This performance indicator is achieved by selecting appropriate hardware and optimizing the encryption library, which can meet the production line cycle time requirements.

[0106] Step S5: Aggregate to form a single-chip full-process chain.

[0107] In step S501, the central traceability engine runs on the data center server cluster. This engine also runs as an MQTT server, using the distributed in-memory database Redis Enterprise as the core storage, and is configured with a three-node master-slave architecture to ensure high availability and data consistency.

[0108] The central traceability engine needs to support a write throughput of no less than 50,000 records per second to meet the data aggregation needs of high-concurrency production lines. When the central traceability engine starts, it loads a TLS certificate and listens for MQTT over TLS connection requests from edge computing nodes on a designated port.

[0109] In step S502, the central tracing engine initializes the MQTT subscriber and subscribes to the topic wildcard " / trace / #" published by all edge computing nodes. This subscription ensures that the engine can receive encrypted process event messages from any device and any process. The subscriber uses multi-threading to support high-concurrency message reception.

[0110] Step S503: Whenever the central tracing engine receives an encrypted MQTT message through a TLS connection, it first confirms from the current connection context that the TLS handshake phase has been completed and that the certificate of the peer edge computing node (if client certificate verification is configured) has passed the validity verification; if no client certificate is configured, it at least ensures that the communication channel is encrypted and the server certificate is trusted to guarantee the security of the message transport layer.

[0111] In step S504, after the transport layer verification is successful, the central traceability engine parses the equipment_id field in the message and looks up the ECDSA public key corresponding to the device number from the locally maintained trust list. The trust list is a mapping table pre-imported by the factory's information security department, which binds the device number to its public key and updates it regularly.

[0112] The central traceability engine uses the public key to verify the digital signature attached to the message, confirming that the message payload has not been tampered with during transmission and that it does indeed originate from the claimed device.

[0113] Step S505: After the signature verification is successful, the central traceability engine extracts the AES-128-GCM key and initialization vector negotiated in this session from the current TLS connection context, decrypts the encrypted payload of the message, and obtains the original TraceRecord JSON object after decryption. This object contains all the process data of a single chip in the current process.

[0114] At this point, the central traceability engine has completed the reception, verification, and reconstruction of a process event message, preparing for subsequent aggregation to form a process path chain.

[0115] Step S506: Parse the die_id field from the restored TraceRecord object, and use this field as the key to query the Redis database to see if the corresponding process path chain exists.

[0116] The process path chain is stored in Redis as an ordered set data structure. The key of the set is directly the die_id string. Each member in the set corresponds to the serialized data of a process event, and the score of the member is set to the occurrence time of the event.

[0117] Step S507: If the query result is empty, it means that the chip is appearing in the traceability system for the first time. In this case, a new ordered set is created in Redis, and the key of the set is set to the die_id.

[0118] The serialized JSON string of the current TraceRecord object is added as a member to this collection. The score of the member is set to the Unix microsecond timestamp converted from the event_time field. The Unix microsecond timestamp is calculated by parsing the ISO 8601 format time string into the number of microseconds since January 1, 1970, 00:00:00 UTC. For example, the conversion can be done using standard time library functions. This score ensures that Redis can automatically sort all records in chronological order.

[0119] Step S508: If the query result already has a corresponding ordered set, insert the serialized string of the current TraceRecord object as a new member into the set, and set the score to the Unix microsecond timestamp corresponding to the current event.

[0120] Redis automatically inserts new members into the correct position in the sorted set based on their scores, keeping all members in ascending order of timestamps. Since it is impossible for two identical events to occur at the same time on the same chip, the possibility of score duplication is extremely low. Even if a slight time duplication occurs, Redis will retain two records. Conflicts can be avoided by introducing microsecond-level timestamps.

[0121] In step S509, after the insertion operation is completed, the central traceability engine updates the last update time of the die_id and the current process status.

[0122] This metadata is stored in another key-value space in Redis, for example, using the key format die_id:meta. Fields include last_update_time (stores the timestamp of the last insert event), current_step (stores the latest completed process code), and trace_status (indicates the traceability integrity status). This metadata can be used for subsequent integrity monitoring, such as quickly determining the current process stage of the chip in step S6.

[0123] In step S510, the central traceability engine maintains a global process flow graph. This graph defines the legal transition sequences between each process step in the form of a directed graph. For example, the graph specifies that after LITHOGRAPHY, there can only be ETCHING, after ETCHING, there can only be CVD, after CVD, there is PROBE_TEST, and after PROBE_TEST, there is PACKAGING.

[0124] The graph can be stored in Redis using graph data structures, such as treating each process as a node and allowed transitions as directed edges, or simply maintaining a mapping table in memory to record the list of successor processes for each process. This graph is used for traceability integrity verification in the subsequent step S6. When a new process event occurs in the chip, the central traceability engine checks whether the preceding process of the current process is valid. If it is invalid, an exception is triggered.

[0125] Step S511: The process path chain is persistently stored in a Redis in-memory database, supporting millisecond-level range queries. For example, to query a specific die_id within a time window... to When dealing with all records within a range, the Redis ZREVRANGEBYSCORE command can be used to specify the score range. and The corresponding Unix microsecond timestamp is used to obtain the member list in ascending or descending order, and then deserialized to obtain the original data.

[0126] According to Redis's official documentation and typical hardware performance, such range queries typically return results within 2 milliseconds, which meets the high efficiency requirements of real-time traceability queries.

[0127] Step S6: Automatically detect traceability integrity and mark abnormal states.

[0128] Step S601: The central traceability engine maintains a process cycle database. This database continuously records the historical processing time data of each process step over the past 7 days. When each chip completes a process, the processing time of that process is recorded in the database. The processing time is defined as the time interval from when the chip enters the process to when it completes the process.

[0129] Based on this historical data, the central traceability engine recalculates the average processing time for each process daily. The calculation method is the arithmetic mean of the processing times for all processes over the past 7 days, denoted as... At the same time, calculate its standard deviation. .

[0130] The average processing time and standard deviation are used to dynamically set the time window threshold in subsequent steps.

[0131] Step S602, for each one that has completed the current process And it is currently awaiting the next expected process. For a chip in a certain state, the engine needs to preset a waiting time window. The calculation of the waiting time window Δt is based on the next process. Average processing time The calculation formula is: Where k is the safety factor, with a default value of 2.5. This factor can be adjusted in the configuration file according to the actual fluctuations in the production line. This indicates the next process retrieved from the process cycle time database. The average processing time is used as a benchmark because the waiting time for a chip to move from the current process to the next process is usually related to the processing cycle of the next process. If the waiting time is much longer than the normal processing time of the next process, it is very likely that data acquisition has been missed or the equipment has malfunctioned.

[0132] In step S603, the central traceability engine runs a timed scanning task in the background. This task iterates through all chips whose current state is waiting for the next process every 10 seconds. For each scanned chip, the central traceability engine retrieves the chip's process path to complete the current process. The moment, recorded as .

[0133] At the same time, according to the current system time For reference, calculate the actual waiting time of the chip since the completion of the current process. The calculation formula is: In step S604, the central tracing engine will record the actual waiting time. Compare with the preset time window Δt.

[0134] if If the chip's latency is within the normal range, it will continue to wait for the next process.

[0135] if Then it is determined that the chip is in the process of manufacturing. To process If a traceability interruption occurs during the process, meaning that the chip is not detected and reported by the next process equipment within the expected time window, the central traceability engine will immediately trigger the subsequent abnormal handling process, including marking the interruption status, recording the interruption location, and generating alarms.

[0136] Step S605: When a tracing interruption is detected, the central tracing engine immediately performs the following atomic operations: First, set the status field corresponding to the Die ID in the Redis database to TRACE_INTERRUPTED to indicate its abnormal state. This operation is performed using Redis's transaction commands MULTI and EXEC or encapsulated using Lua scripts to ensure the atomicity of status updates and subsequent record operations, thus avoiding data inconsistency in concurrent scenarios.

[0137] Then record the specific location where the interruption occurred, i.e., from the current process. To the next expected process The transfer pair is generated and the information is stored together with the interrupt time. The storage uses a Redis hash structure, with the key being die_id followed by the suffix: interrupt, and the fields including from_step, to_step, and interrupt_time.

[0138] Finally, an alarm event is generated, and the event content is written to the alarm topic in the Kafka message queue for consumption by downstream monitoring systems. The alarm event content includes key fields such as Die ID, interrupted process pair, actual waiting time, preset time window, and interruption time.

[0139] In step S606, the central tracing engine further analyzes the spatial distribution characteristics of the interrupt chip.

[0140] The central tracing engine uses the chip's physical coordinates X and Y, combined with the region mapping table on the wafer, to deduce the wafer region number to which the Die ID belongs.

[0141] The region partitioning mapping table is predefined and stored in Redis. For example, the wafer surface is divided into multiple annular regions such as inner circle, middle circle, and outer circle. Each region corresponds to a set of coordinate ranges. The region partitioning table is stored in JSON format with the key being wafer_region_map.

[0142] During the calculation, the central tracing engine traverses the mapping table, finds the first region containing the current coordinates, and returns its number.

[0143] Step S607: The central traceability engine counts the number N of chips that have experienced consecutive traceability interruptions within the same wafer area.

[0144] In the latest round of scanning, the central tracing engine traverses all chips in the TRACE_INTERRUPTED state according to their physical order on the wafer (e.g., increasing by X coordinate, and increasing by Y under the same X coordinate), and groups them according to their respective regions.

[0145] For each region, the number of consecutive occurrences is counted. That is, if all the chips scanned in a region are in an interrupted state, the consecutive count is incremented. Once a normal chip or a chip belonging to another region is encountered, the count is reset. If the number N of interrupted chips that occur consecutively in a certain region reaches or exceeds 5, the alarm level escalation mechanism is triggered.

[0146] In step S608, the alarm level is automatically upgraded from the initial INFO to CRITICAL.

[0147] After the upgrade, the central traceability engine pushes emergency notifications to the on-duty process engineers and quality supervisors via the WeChat Work robot. The notifications include key information such as the list of interrupted die IDs, interrupted process pairs, time deviation values, and associated equipment IDs, making it easier for on-site personnel to quickly locate the root cause of the problem, whether it is equipment downtime, material blockage, or data acquisition failure.

[0148] The integration method for the WeChat Work robot is to pre-configure the robot's Webhook address, and the central tracing engine sends the alarm content to this address via an HTTP POST request.

[0149] Step S7: Respond to the traceability query request and return complete process data.

[0150] Step S701: The trace query terminal receives the Die ID and optional filtering conditions input by the user. The terminal can be a web application deployed on the intranet or an application installed on a mobile device.

[0151] Users can enter the Die ID to be queried through the interface, and can select filter parameters such as start_time and end_time, and equipment_id_list to narrow down the search scope.

[0152] After a user submits a query, the traceability query terminal assembles the input parameters into the data structure for subsequent requests.

[0153] In step S702, the traceability query terminal encapsulates the query request into an HTTPS RESTful API call and sends the query instruction to the central traceability engine.

[0154] The request body must be in JSON format and must include the die_id field, as well as optional filter fields such as start_time, end_time, and equipment_id_list.

[0155] All communication is encrypted via TLS to ensure secure data transmission. The trace query terminal uses a standard HTTP client library to initiate POST requests to specific endpoints of the engine, such as / api / trace / query.

[0156] In step S703, after receiving the request, the central traceability engine first verifies the permissions of the user identity token JWT. The central traceability engine parses the signature and validity period in the JWT to confirm that the token was issued by the trusted authorization center and has not expired.

[0157] Next, the user role or permission identifier is extracted from the JWT payload, and it is checked whether the user has permission to access the requested data. Permission checks can be based on global roles. For example, process engineers can access all chip data, while operators can only access data for specific devices. Specific rules are pre-configured by the factory in the engine's permission mapping table.

[0158] If verification fails, the central tracing engine will directly return an HTTP 401 Unauthorized Error.

[0159] Step S704: After the permission verification is passed, the central traceability engine queries the Redis database for the corresponding ordered set of process path chains using die_id as the key. This ordered set stores serialized TraceRecord objects of all process events of the chip, with the event timestamp as the score.

[0160] If the query result is empty, it means that the Die ID does not exist in the system. The central tracing engine immediately returns an HTTP 404 Not Found error response with the error message "Die ID does not exist". If the query result exists, the subsequent steps continue.

[0161] In step S705, the central traceability engine retrieves all TraceRecord members from the ordered set in ascending order of timestamps. These members are previously stored serialized JSON strings, which the central traceability engine deserializes into an array of TraceRecord objects using a JSON parsing library.

[0162] Subsequently, the array is filtered according to the optional filtering conditions carried in the request: if start_time and end_time are provided, only records with event times within this range are retained; if equipment_id_list is provided, only records with device numbers belonging to this list are retained.

[0163] After filtering, the final list of records to be returned is obtained.

[0164] In step S706, the central traceability engine simultaneously reads the status field of the Die ID. This status field is stored in Redis as a separate key-value pair, with a value of NORMAL or TRACE_INTERRUPTED, indicating the traceability integrity status of the chip.

[0165] If the status field does not exist, the central traceability engine defaults to NORMAL, indicating that the chip is in normal condition. This status will be used together with the record list to construct the final response.

[0166] Step S707: The central traceability engine constructs a response JSON object, which contains the following fields: The die_id field is the Die ID queried; The status field is the status read from Redis. If this field does not exist, the default value is NORMAL. The total_steps field indicates the total number of steps the chip has undergone, which is calculated from the length of the records array; The records field is an array of process path chain objects, each object containing detailed data such as process_step, equipment_id, operator_id, event_time, and parameters.

[0167] If the status is TRACE_INTERRUPTED, a virtual record is inserted at the end of the records array. This virtual record is used to mark the missing step. Its process_step field is set to MISSING, the equipment_id and operator_id fields are set to empty strings, the event_time field is set to the time when the interruption occurred, the parameters field contains information about the missing process pair, such as from_step and to_step, and a field estimated_time that indicates the estimated missing time, which is taken from the interruption time recorded when the interruption was detected.

[0168] In step S708, the central traceability engine performs gzip compression on the constructed response JSON data to reduce network transmission load. The compressed data is returned to the traceability query terminal via HTTPS response. The average latency of the entire process from receiving the request to returning the response is controlled within 800 milliseconds. This latency metric is ensured by optimizing Redis queries and selecting appropriate server hardware to meet real-time query requirements.

[0169] In step S709, after receiving the response data, the front-end terminal first decompresses the gzip content, then parses the JSON and uses the front-end visualization component to display the process path chain in the form of an interactive timeline.

[0170] Each process on the timeline is represented by a rectangular block, which displays the process name and a summary of key parameters. For example, the photolithography process displays the exposure dose, and the etching process displays the radio frequency power.

[0171] When the user hovers the mouse over the rectangle, a detailed parameter window pops up, displaying all the parameters and their values ​​for that process.

[0172] In step S710, if the response contains virtual records of missing steps, the corresponding position on the timeline will be highlighted with a red dashed box and marked with the text "Data Missing" to remind the user that the data for this process has not been collected normally.

[0173] Step S711: The traceability query terminal also supports advanced query functions with multi-condition combination filtering. For example, a user can query all chips in an etching process performed by a certain machine within a specified time range whose gas ratio deviates from the historical average of that process by more than two standard deviations. When the traceability query terminal initiates such a complex query, the central traceability engine selects the execution method based on the query conditions: If the query conditions only involve device ID, time range, and threshold comparison of a single parameter, and this parameter already has a secondary index in Redis, the central traceability engine directly uses Redis's SORTED SET structure to retrieve data based on the parameter value range. The secondary index is created as follows: for parameters requiring indexing, a separate Redis ordered set is used, with the key format `index:process:parameter_name`, members being `die_id`, and the score being the parameter's numerical value. When a new process event is inserted, the central traceability engine synchronously updates these index sets.

[0174] If the query conditions involve a combination of multiple parameters or require real-time calculation of statistical values, the central traceability engine will submit the query task to the Apache Spark cluster for distributed offline analysis. The Spark cluster will synchronize the process path chain data in Redis to the distributed file system in advance through periodic tasks to form a divisible dataset.

[0175] The central traceability engine converts query conditions into Spark SQL statements, submits them to a Spark job, and returns the result set to the engine upon completion. The central traceability engine then returns the result set to the traceability query terminal. The traceability query terminal displays the Die IDs that meet the criteria in a list format, and allows users to click to view the detailed process path of each Die.

[0176] The present invention also provides a circuit chip manufacturing information traceability system, including multiple edge computing nodes and a central traceability engine.

[0177] Multiple edge computing nodes are deployed at various key process equipment locations. Each edge computing node includes: A secure element is used to generate a 48-bit monotonically increasing counter value, which is automatically incremented by one after a unique identifier is generated for each chip, ensuring that the input data for each hash operation is globally unique.

[0178] The data acquisition module establishes a real-time data channel with the process equipment controller through a communication interface that supports SECS / GEM HSMS, Modbus TCP, IEEE 488.2 GPIB, and EtherCAT protocols. This module initiates an event listening mechanism. When the equipment controller sends a chip arrival trigger signal, it captures the signal through a GPIO interrupt or protocol callback function and immediately extracts all raw process data related to the chip from the controller buffer, including sensor readings, actuator feedback, alarm records, and operator authentication information. At the same time, it accurately associates the data with the individual chip based on the wafer ID or chip serial number provided by the equipment.

[0179] The identifier generation and engraving control module is used to generate a unique identifier for the chip according to the wafer ID of the current wafer, the physical coordinates of the chip, and the monotonically increasing count value generated by the security element, following steps S103 to S105. Specifically, the wafer ID, chip coordinates, and CRC-32 checksum are concatenated and then combined with the count value to form an input data string. The string is then hashed using SHA-256 and the first 32 characters are extracted as the Die ID. This module also controls the laser engraving equipment to engrave the unique identifier on the chip using a two-stage fine-tuning engraving process. In the first stage, a larger spot laser beam is used to ablate the character outline, with the depth controlled between 0.6 and 0.9 micrometers. In the second stage, a smaller spot laser beam is used for fine trimming, with the final depth controlled between 0.8 and 1.2 micrometers, forming a smooth groove bottom surface to enhance optical recognition contrast.

[0180] The data processing and encapsulation module associates the raw process data acquired by the data acquisition module with the Die ID and encapsulates it into process event records according to a unified data model. This unified data model includes at least the fields die_id, process_step, equipment_id, operator_id, event_time, and parameters. The parameters field is a dynamic dictionary, and each parameter value includes its own acquisition timestamp and sensor identifier. The encapsulated records are then serialized into JSON format strings.

[0181] The secure communication module digitally signs the encapsulated JSON string using the ECDSA P-256 algorithm, with the signing private key stored in the secure element. After signing, the data, along with the signature, is encrypted using the AES-128-GCM algorithm. The encryption session key is generated through the TLS 1.3 handshake negotiation during MQTT connection establishment. The encrypted data is encapsulated as an MQTTPUBLISH message with the subject format / trace / {equipment_id} / {process_step}, QoS set to 1, and uploaded via a long-lived MQTT connection maintained with the central trace engine. In the event of a network interruption, this module initiates a reconnection mechanism and temporarily stores data to be sent in a local circular buffer queue with a capacity of 1000 records; once full, the oldest record is discarded.

[0182] The central traceability engine runs on a data center server cluster and communicates with various edge computing nodes. The central traceability engine includes: The receiving and verification module is used to listen to the MQTT topic / trace / #, receive encrypted messages, first verify the validity of the TLS connection certificate, then look up the corresponding public key from the trust list based on the equipment_id in the message, verify the ECDSA digital signature, and confirm the data source and integrity; after the signature verification is successful, the message payload is decrypted using the AES-128-GCM key negotiated in the TLS session, and the original TraceRecord JSON object is restored.

[0183] The data aggregation module uses the reconstructed `die_id` as the key to query the corresponding ordered set of process path chains in the Redis database. If it doesn't exist, it creates a new ordered set with `die_id` as the key; otherwise, it inserts the serialized string of the current `TraceRecord` object as a member of the set, setting the member's score to the Unix microsecond timestamp corresponding to `event_time`. Redis automatically sorts the data by timestamps, forming a complete process timeline for the chip. Simultaneously, this module updates the metadata of `die_id`, including the last update time and the current process status.

[0184] The integrity monitoring module dynamically calculates the waiting time window for each chip based on the historical processing time of each process step. For chips that have completed the current process and are waiting for the next expected process, the waiting time is calculated based on the average processing time of the next process. Multiplying by a safety factor k yields the waiting time window Δt, where k defaults to 2.5. This module periodically scans all chips in a waiting state and calculates the actual waiting time since the completion of the current process. ,like If an interrupt is detected, an atomic operation is performed: the chip status is marked as TRACE_INTERRUPTED, the interrupt process pair and interrupt time are recorded, and the alarm event is written to the Kafka message queue. Furthermore, this module analyzes the spatial distribution of the interrupted chips, determines their region on the wafer based on their physical coordinates, counts the number of consecutive interrupts within the same region, and if more than 5 occur, the alarm level is escalated and an emergency notification is pushed via WeChat.

[0185] The query interface module provides an HTTPS RESTful API to respond to external query requests. Upon receiving a request containing the die_id and optional filter conditions, it first verifies the user's JWT token permissions. Then, it queries the ordered set of the corresponding chip's process path chain from Redis, retrieves all records in ascending order of timestamp, deserializes them into an object array, and filters them according to the filter conditions. Simultaneously, it reads the chip status field; if it does not exist, it defaults to NORMAL. Finally, it constructs a JSON response containing the die_id, status, total number of processes, and a list of records, compresses the response using gzip, and returns it. If the status is TRACE_INTERRUPTED, a virtual record is inserted at the end of the record list to mark the missing process.

[0186] It will be apparent to those skilled in the art that the present invention is not limited to the details of the exemplary embodiments described above, and that the present invention can be implemented in other specific forms without departing from the spirit or essential characteristics of the present invention. Therefore, the embodiments should be regarded as exemplary and non-limiting in all respects.

[0187] Furthermore, it should be understood that although this specification describes embodiments, not every embodiment includes only one independent technical solution. This narrative style is merely for clarity. Those skilled in the art should consider the specification as a whole, and the technical solutions in each embodiment can also be appropriately combined to form other embodiments that can be understood by those skilled in the art.

Claims

1. A method for tracing circuit chip manufacturing information, characterized in that, Includes the following steps: A unique identifier is generated for each chip. The unique identifier is calculated by a hash algorithm based on the wafer identifier of the current wafer, the chip's physical coordinates on the wafer, and a monotonically increasing count value generated by the security element. A two-stage fine-refinement engraving process is adopted to engrave a unique identifier on the chip. The two-stage fine-refinement engraving process includes a first stage of using a first laser beam to etch out the character outline, and a second stage of using a second laser beam to finely refine the interior of the outline. At each critical process step, edge computing nodes collect the chip's process parameters in real time during the manufacturing process, and associate the process parameters with the chip's unique identifier, encapsulating them into process event records; The process event records are uploaded to the central traceability engine. The central traceability engine aggregates all process event records belonging to the same chip in chronological order based on the unique identifier, forming the entire process path chain of a single chip. The central traceability engine dynamically calculates the waiting time window for each chip based on the historical processing time of each process step, and monitors its actual waiting time. If the waiting time window is exceeded, it is determined to be a traceability interruption. In response to a query request containing a unique identifier, return the complete process path chain and traceability status of the corresponding chip.

2. The method for tracing circuit chip production information according to claim 1, characterized in that, The specific steps for generating a unique identifier for each chip include: Obtain the wafer identifier assigned by the manufacturing execution system, and the micron-level physical coordinates of the chip on the wafer output by the wafer alignment system; The wafer identifier, physical coordinates, and cyclic redundancy check code are concatenated and then combined with a 48-bit monotonically increasing count value generated by the security element in the edge computing node to form the input data string. Perform a SHA-256 hash operation on the input data string and extract the first 32 characters of the result as the chip's unique identifier.

3. The method for tracing circuit chip production information according to claim 1, characterized in that, In the two-stage fine engraving process, the engraving depth in the first stage is controlled at 0.6 to 0.9 micrometers, and the final engraving depth in the second stage is controlled at 0.8 to 1.2 micrometers. Furthermore, before performing the etching, the process includes a step of dynamically retrieving laser etching parameters from a preset process parameter library based on the thin film stacking information of the chip's location.

4. The method for tracing circuit chip production information according to claim 1, characterized in that, After the unique identifier is engraved, the process also includes online engraving quality inspection and compensation. The unique identifier of the engraved area is imaged and identified using an online optical detection module. If recognition fails or the quality parameters do not reach the threshold, it is determined to be a poor engraving. For minor defects, re-etching is performed at the same chip location, and the laser power density of the re-etching is increased by 5% to 10% compared to the original etching parameters; For serious defects, the chip is marked as invalid and reported to the manufacturing execution system so that it can be removed in subsequent processes.

5. The method for tracing circuit chip production information according to claim 1, characterized in that, Process event logs are encapsulated according to a predefined unified data model, which includes at least the following: The die_id field is used to store a unique identifier, the process_step field is used to identify the current process step, and the parameters field is used to store the set of process parameters. The parameters field is a dynamic dictionary structure, in which each process parameter value is independently accompanied by the acquisition timestamp of the parameter and the sensor identifier that generated the parameter.

6. The method for tracing circuit chip production information according to claim 1, characterized in that, Edge computing nodes establish real-time data channels with different types of process equipment controllers through communication interfaces that support SECS / GEMHSMS, ModbusTCP, IEEE488.2GPIB and EtherCAT protocols, and capture and extract raw process data associated with a single chip in real time through an event listening mechanism.

7. The method for tracing circuit chip production information according to claim 1, characterized in that, Edge computing nodes have built-in FPGA or GPU coprocessors for executing hash algorithms in parallel; The main processor and coprocessor of the edge computing node work together through a dual-buffer mechanism. After the main processor writes the data to be calculated into the first buffer, the coprocessor immediately starts the calculation. At the same time, the main processor writes the data of the next chip into the second buffer, realizing the pipelined and parallel processing of the hash calculation task.

8. The method for tracing circuit chip production information according to claim 1, characterized in that, The central traceability engine dynamically calculates the waiting time window for each chip that is waiting for the next expected process. The waiting time window is obtained by multiplying the historical average processing time of the next expected process by a safety factor. The central traceability engine periodically scans all chips in a waiting state. If the actual waiting time of a chip since the completion of the current process exceeds its corresponding waiting time window, it is determined to be a traceability interruption.

9. The method for tracing circuit chip production information according to claim 8, characterized in that, After determining the interrupt, the process also includes analyzing the spatial distribution characteristics of the interrupt chip: Based on the chip's physical coordinates, determine its designated area on the wafer; Count the number of chips that experience consecutive traceability interruptions within the same preset area; If the number of consecutive interruptions reaches a preset threshold, the alarm level will be upgraded, and an emergency notification containing the interruption location and associated device identifier will be pushed to the designated terminal.

10. A circuit chip manufacturing information traceability system, used in the circuit chip manufacturing information traceability method according to any one of claims 1 to 9, characterized in that, include: Multiple edge computing nodes are deployed at various key process equipment locations. Each edge computing node includes: Safety element used to generate a monotonically increasing count value; The data acquisition module is used to acquire raw process data related to a single chip in the process equipment in real time through various industrial communication protocols; The identifier generation and engraving control module is used to generate a unique identifier for the chip based on the wafer identifier, chip physical coordinates and monotonically increasing count value through a hash algorithm, and to control the laser engraving equipment to engrave the unique identifier on the chip using a two-stage fine engraving process. The data processing and encapsulation module is used to associate the collected raw process data with unique identifiers and encapsulate it into process event records. The secure communication module is used to encrypt process event records and upload them via a long connection; A central tracing engine, communicating with each edge computing node, includes: The receiving and verification module is used to receive and decrypt encrypted data from edge computing nodes; The data aggregation module is used to store the received process event records in chronological order using a unique identifier as the key, and to build a complete process path chain for each chip. The integrity monitoring module is used to dynamically calculate the waiting time window for each chip based on the historical processing time of each process step, monitor the integrity of its flow process, and mark the abnormal state when a traceability interruption is detected. The query interface module is used to respond to external query requests and return the complete process path chain and status information of the corresponding chip.

Images