Data management method, system, equipment and medium for semiconductor process recipe parameters

Abstract

The embodiments of the present application relate to the field of semiconductor technology, and disclose a method, system, device and medium for data management of semiconductor process recipe parameters, wherein the method comprises: performing data analysis on the collected process recipes in one or more data formats to convert them into a target data format and store them in a database; in response to a data request passed in through a data interface, returning the corresponding process recipe data in the database through the data interface in the format of the data request based on the configured mapping relationship. Through the scheme of the present application, standardized semiconductor process recipe parameter-related data can be provided and output to other systems in a standard data structure, which at least solves the technical problems of low efficiency in viewing different equipment parameters, low production management efficiency, frequent errors and high management costs in the prior art.

Description

Technical Field

[0001] The present application relates to the field of semiconductor technology, and in particular to a method, system, device and medium for data management of semiconductor process recipe parameters. Background Art

[0002] Semiconductor manufacturing has become an important industry worldwide. It is closely related to a variety of electronic devices (such as smartphones, computers, and IoT devices). However, not all semiconductor manufacturers have achieved efficient process recipe parameter management, which leads to the traditional manual management method and the automated digital management method. The identification of traditional manual management and automated digital management involves distinguishing the differences in the efficiency of process recipe parameter management among enterprises. Although enterprises that have achieved automated digital management have invested a lot of money and manpower, they can significantly improve production efficiency, reduce errors, and shorten product time to market; enterprises that adopt traditional manual management face problems such as low efficiency and frequent errors. Therefore, the identification of automated digital management is particularly important for diagnosing, preventing and improving inefficient process recipe parameter management, which helps to improve the competitiveness and profitability of enterprises. At present, the identification of process recipe parameter management methods is mainly based on manual statistics, questionnaires, and on-site observations, such as counting the time for manual entry and conversion of recipe parameters, investigating engineers' feedback on the use of recipe management systems, and observing the process execution at the production site. Although these methods are effective to a certain extent, they have certain limitations. For example, manual statistics and questionnaires are easily affected by subjective factors, and on-site observations are difficult to fully evaluate the entire production process. These assessments usually require a lot of time and manpower, bringing additional cost burden to the enterprise.

[0003] In recent years, with the advancement of information technology, process management evaluation methods based on data analysis have gradually attracted attention. Equipment operation log data has become a research focus because it can objectively reflect the actual operation status of the equipment. Among them, the change records of equipment recipe parameters may be related to process management efficiency, which provides a new way to use equipment operation data to evaluate process recipe management efficiency. By using machine learning or deep learning technology, using complex algorithm models to process a large amount of equipment operation log data and learn from the patterns, it is possible to reveal subtle features under different management methods. In actual application scenarios, due to the huge amount of equipment operation log data and diverse formats, it is often necessary to improve data quality through data cleaning and feature engineering operations (such as conversion) when training the model. However, the existing data processing operations adopt a general data processing process, which will introduce irrelevant information in the processing process, resulting in the extracted features being out of touch with the actual business scenario, reducing the practicality of the model.

[0004] Therefore, there is an urgent need for a technical solution that can provide standardized semiconductor process recipe parameter-related data and output it to other systems in a standard data structure. Summary of the invention

[0005] One purpose of the present application is to provide a data management method, system, device and medium for semiconductor process recipe parameters, at least to solve technical problems such as low efficiency in viewing different equipment parameters, low production management efficiency, frequent errors and high management costs in the prior art.

[0006] To achieve the above objectives, some embodiments of the present application provide the following aspects:

[0007] In a first aspect, some embodiments of the present application provide a data management method for semiconductor process recipe parameters, comprising: performing data parsing on the collected process recipes in one or more data formats to convert them into a target data format and store them in a database; in response to a data request transmitted through a data interface, returning the corresponding process recipe data in the database through the data interface in the format of the data request based on a configured mapping relationship; wherein, performing data parsing on the collected process recipes in one or more data formats to convert them into a target data format and store them in a database, comprises: receiving a process recipe containing one or more process step information; wherein each process step contains a control code and multiple parameters; according to a predefined equipment manual, determining the meaning of each parameter under each control code; converting each parameter into a standardized format to store it in a database; wherein, according to a predefined parsing rule, parsing the binary data stream into multiple data segments, comprises: preprocessing the binary data stream according to a preset byte identifier and defining the data segment type, reading the front preset byte to extract the file header information and then establishing a segment relationship diagram; dividing the data stream into multiple data blocks and retaining overlapping areas between blocks, and organizing the data segments in a unified format after confirming the segment validity through feature library matching.

[0008] Furthermore, the binary data stream is preprocessed according to a preset byte identifier and the data segment type is defined, and an inter-segment relationship graph is established after reading the leading preset bytes to extract the file header information, including: preprocessing the binary data stream by identifying a specific byte pattern as a segment identifier, wherein the first preset byte is used as a start identifier and the second preset byte is used as an end identifier; three data segment types are defined based on a state transition method, including a parameter name segment starting with a third preset byte, a parameter value segment starting with a fourth preset byte, and a control segment starting with a fifth preset byte; reading the leading preset bytes of the data stream for initial analysis to extract the file header information, wherein the file header contains a data version number, a timestamp, and segment quantity information; establishing an inter-segment relationship graph and using an adjacency matrix to represent it, and calculating the association strength through a baseline association degree, a distance attenuation factor, and a segment length.

[0009] Furthermore, the data stream is divided into multiple data blocks and overlapping areas are reserved between the blocks. After the validity of the segments is confirmed by matching the feature library, the data segments are organized in a unified format, including: dividing the data stream into multiple data blocks of similar size, searching for segment boundary identifiers for each data block and constructing a segment position index; retaining overlapping areas between adjacent data blocks, and determining the ownership of data segments in the overlapping areas by calculating local context similarity; maintaining a dynamically updated segment feature library, calculating feature matching through feature weights and similarity scores, and confirming the validity of the segment when the feature matching exceeds a preset threshold; organizing the parsed data segments in a unified internal format, including segment type identification, segment length information, segment attribute flags, data payload and checksum.

[0010] Furthermore, the standardized format includes storing the parameters of each process step as independent data entries, each data entry containing parameter name, parameter value, lower limit value and upper limit value fields; when the parameter name is a step, the parameter value is configured as a step identifier, and the corresponding lower limit value and upper limit value fields in the database are left blank.

[0011] Furthermore, in response to a data request transmitted through a data interface, the corresponding process recipe data in the database is returned through the data interface in the format of a data request based on a configured mapping relationship, including: establishing and storing a mapping relationship, wherein the mapping relationship is used to map the recipe name and parameter name of the target system to the corresponding name in the database; receiving a data request transmitted from the target system through the data interface, wherein the data request includes a system name and a recipe list, wherein the recipe list includes a tool identifier, a recipe name, and a parameter list; according to the configured mapping relationship, converting the recipe name and parameter name in the data request into the corresponding recipe name and parameter name in the database; based on the converted name, querying the corresponding recipe parameter information and parameter control range in the database; generating response data, wherein the response data includes a system name and a recipe list, wherein the recipe list includes a tool identifier, a recipe name, and parameter information, and the parameter information includes a parameter name, a parameter setting value, a parameter control lower limit value, and a parameter control upper limit value; and returning the response data to the target system through the data interface.

[0012] In the second aspect, some embodiments of the present application also provide a data management system for semiconductor process recipe parameters that applies the data management method as described in any of the above embodiments, including: a recipe acquisition unit and a data management unit; wherein the recipe acquisition unit is used to collect data in one or more formats containing semiconductor process recipes from one or more devices; the data management unit is used to perform data analysis on the collected process recipes in one or more data formats to convert them into a target data format, and store them in a database; in response to a data request transmitted through a data interface, the corresponding process recipe data in the database is returned through the data interface in the format of the data request based on the configured mapping relationship.

[0013] In a third aspect, some embodiments of the present application further provide an electronic device, comprising: one or more processors; and a memory storing computer program instructions, wherein the computer program instructions, when executed, cause the processor to perform the steps of the method described above.

[0014] In a fourth aspect, some embodiments of the present application further provide a computer-readable medium having computer program instructions stored thereon, wherein the computer program instructions can be executed by a processor to implement the method as described above.

[0015] In a fifth aspect, some embodiments of the present application further provide a computer program product, comprising a computer program / instruction, which implements the steps of the method described above when executed by a processor.

[0016] Compared with the related art, in the solution provided by the embodiment of the present application, by parsing the semiconductor process recipe parameter data of different formats of the equipment into data in a standard format and storing it in RMS, it is possible to provide standardized semiconductor process recipe parameter-related data and output it to other systems in a standard data structure. Furthermore, in some embodiments, through the offline and online sharing capabilities of RMS, engineers can quickly access and apply standardized recipe data, thereby reducing production preparation time, speeding up response speed, and significantly improving production efficiency and the smoothness of the process flow. Furthermore, in some embodiments, through standardized data management and automated sharing mechanisms, the process of manually inputting and converting recipe parameters is reduced, errors caused by human operations can be reduced, and the accuracy and reliability of the production process are improved. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] One or more embodiments are exemplarily described by pictures in the corresponding drawings, and these exemplified descriptions do not constitute limitations on the embodiments. Elements with the same reference numerals in the drawings represent similar elements, and unless otherwise stated, the figures in the drawings do not constitute proportional limitations.

[0018] Figure 1 A schematic diagram of a process flow of a semiconductor process recipe parameter data management method provided in an embodiment of the present application;

[0019] Figure 2 A flowchart of a data standardization method provided in an embodiment of the present application;

[0020] Figure 3 A flowchart of another data standardization method provided in an embodiment of the present application;

[0021] Figure 4 A flowchart of another data standardization method provided in an embodiment of the present application;

[0022] Figure 5 A schematic diagram of a hierarchical data structure provided in an embodiment of the present application;

[0023] Figure 6 A schematic diagram of a data stream encoding data structure provided in an embodiment of the present application;

[0024] Figure 7 A flowchart of a method for responding to a data request provided in an embodiment of the present application;

[0025] Figure 8 A schematic diagram of an example of a request data structure in a data return format provided in an embodiment of the present application;

[0026] Fig. 9 A schematic diagram of an example of a reply data structure in a data return format provided in an embodiment of the present application;

[0027] Fig.10 A schematic block diagram of a data management system for semiconductor process recipe parameters provided in an embodiment of the present application;

[0028] Fig.11 An exemplary structural diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0029] In order to make the purpose, technical solution and advantages of the embodiments of the present application clearer, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0030] First embodiment

[0031] It should be noted that the embodiment of the present application improves the management efficiency of recipe parameters and card control values ​​in semiconductor manufacturing through data standardization and enhanced sharing mechanism. The system supports offline and online sharing of recipe parameters through a unified data structure and format, allowing other systems (such as FDC, APC) to query recipe information in a standard format to ensure parameter consistency between different systems, significantly reducing the duplication of engineers in recipe management, thereby improving production efficiency and process quality stability.

[0032] Figure 1 A flowchart of a method for data management of semiconductor process recipe parameters provided in an embodiment of the present application.

[0033] Specifically, if Figure 1 As shown, the first embodiment of the present application relates to a method for data management of semiconductor process recipe parameters, comprising the following steps:

[0034] Step S101, data analysis is performed on the collected process recipes in one or more data formats to convert them into a target data format and store them in a database (e.g. Figure 2 , Figure 3 or Figure 4 as shown).

[0035] It should be understood that in the field of semiconductor manufacturing, process recipe parameters refer to specific parameter settings used to control and optimize various process steps in the semiconductor manufacturing process. These parameters may include, but are not limited to, physical quantities such as temperature, pressure, gas flow, voltage, current, and process control parameters such as time and step sequence. Process recipe parameters are crucial to ensuring the quality, yield, and consistency of semiconductor products. The data management method described in this application involves systematic management and optimization of these process recipe parameters.

[0036] Specifically, the method includes multiple steps such as data acquisition, data parsing, data conversion and data storage. Among them, data acquisition refers to obtaining original process recipe parameter data from semiconductor manufacturing equipment or related systems. These data may exist in a variety of formats, such as but not limited to text files, spreadsheets, database records or equipment output in proprietary formats. Data parsing refers to analyzing and processing the collected raw data to extract meaningful information. This may involve operations such as identifying data structures, separating parameter names and values, and interpreting units and ranges. The purpose of data parsing is to convert unstructured or semi-structured raw data into structured information that can be further processed. Data conversion refers to converting the parsed data into a predefined target data format. The purpose of this step is to achieve data standardization so that process recipe parameters from different sources and in different formats can be uniformly managed and used. The target data format can be a common data exchange format, such as JSON or XML, or a custom format designed specifically for semiconductor process parameter management. Data storage refers to saving the converted standard format data into a database. This database can be a relational database, such as MySQL or Oracle, or a non-relational database, such as MongoDB or Cassandra. The specific choice depends on the structure of the data, query requirements, and system performance requirements.

[0037] Step S102, in response to the data request passed in through the data interface, the corresponding process recipe data in the database is returned through the data interface in the format of the data request based on the configured mapping relationship. The data interface here can be in various forms such as API (application programming interface), Web service, message queue, etc. Data requests may come from various clients, including but not limited to manufacturing execution systems (MES), equipment automation systems, data analysis tools, etc. During the response process, this method will convert the standard format process recipe data stored in the database into the specific format required by the data requester based on the pre-configured mapping relationship. This dynamic format conversion mechanism enables the system to flexibly adapt to the data requirements of different systems without changing the core data storage structure.

[0038] Specifically, for the received hierarchical data structure (such as Figure 5 As shown), in one embodiment, Figure 2 The following is a flow chart of a data standardization method provided in an embodiment of the present application. Figure 2 As shown, a data standardization method includes the following steps:

[0039] Step S201, receiving a process recipe including one or more process step information; wherein each process step includes a control code and multiple parameters. The control code here can be understood as a unique identifier for identifying and distinguishing different process steps, and the parameters are specific settings and conditions corresponding to each process step, such as temperature, pressure, time, gas flow, etc.

[0040] Step S202, according to the predefined equipment manual, determine the meaning of each parameter under each control code. After receiving the process recipe containing process step information, the method determines the specific meaning of each parameter under each control code according to the predefined equipment manual. The so-called equipment manual can be a document or data sheet defined in advance by the equipment manufacturer or process engineer, which specifies in detail the parameter type, value range, physical meaning and other information corresponding to each control code. By consulting and parsing this equipment manual, the role and meaning of each parameter in a specific process step can be clearly understood.

[0041] It should be noted that in the actual semiconductor manufacturing process, different equipment models and different process nodes may use different control coding systems and parameter definition methods. Therefore, the predefined equipment manual may need to be customized and maintained according to the specific equipment model and process characteristics in actual applications. At the same time, the content of the equipment manual may also change with the upgrade and optimization of the process.

[0042] Step S203, converting each parameter into a standardized format for storage in a database. After clarifying the meaning of each parameter, the method further converts these parameters into a standardized format for subsequent storage and processing (such as Figure 4 The standardized format here can be designed and defined according to actual needs and system environment. For example, all parameter values ​​can be uniformly converted into a specific data type (such as floating point numbers, integers, etc.), or parameter values ​​of different units can be unified into consistent units. The purpose of standardization is to eliminate differences and incompatibilities between different equipment and different processes, and to improve the consistency and comparability of data.

[0043] For the received data stream encoding data structure (such as Figure 6 As shown), in one embodiment, Figure 3 A flow chart of another data standardization method provided in an embodiment of the present application. Figure 3 As shown, another data normalization method includes the following steps:

[0044] Step S301, receiving a binary data stream containing a process recipe. It should be noted that the "process recipe" described in the present invention refers to a set of parameters and instructions used to guide production operations in an industrial production process. The process recipe generally includes but is not limited to information such as raw material ratios, production process parameters, and quality control indicators. This information is of great significance for ensuring product quality and improving production efficiency.

[0045] Furthermore, the "binary data stream" described in the present invention refers to a data sequence encoded in binary format. Binary data stream is a commonly used data transmission and storage format in computer systems, and has the characteristics of high data density and high transmission efficiency. In the specific implementation of the present invention, the process recipe information is encoded as a binary data stream to facilitate data transmission and processing.

[0046] Step S302, according to predefined parsing rules, the binary data stream is parsed into multiple data segments. The parsing rules here refer to a set of pre-set rules for identifying and segmenting different parts in the data stream. The parsing rules can be based on the structural characteristics of the data stream, such as fixed-length fields, specific delimiters or specific data patterns. The parsing process can use a variety of algorithms and techniques, such as regular expression matching, state machine parsing or custom parsing algorithms. The purpose of parsing is to segment the original binary data stream into multiple meaningful data segments, each of which represents a specific parameter or information.

[0047] Among them, according to the predefined parsing rules, the binary data stream is parsed into multiple data segments, including: preprocessing the binary data stream according to the preset byte identifier and defining the data segment type, reading the front preset bytes to extract the file header information and then establishing an inter-segment relationship diagram; dividing the data stream into multiple data blocks and retaining the overlapping area between the blocks, and organizing the data segments in a unified format after confirming the validity of the segments through feature library matching.

[0048] Preferably, the binary data stream is preprocessed according to a preset byte identifier and the data segment type is defined, and an inter-segment relationship graph is established after reading the front preset bytes to extract the file header information, including: preprocessing the binary data stream by identifying a specific byte pattern as a segment identifier, wherein the first preset byte is used as the start identifier and the second preset byte is used as the end identifier; three data segment types are defined based on a state transition method, including a parameter name segment starting with a third preset byte, a parameter value segment starting with a fourth preset byte, and a control segment starting with a fifth preset byte; reading the front preset bytes of the data stream for initial analysis to extract the file header information, wherein the file header contains a data version number, a timestamp, and segment quantity information; establishing an inter-segment relationship graph and using an adjacency matrix to represent it, and calculating the association strength through a baseline association degree, a distance decay factor, and a segment length.

[0049] Specifically, the parsing rules can adopt a segmented parsing method based on state transition. This method first preprocesses the binary data stream and identifies a specific byte pattern as a segment identifier. Specifically, 0x55 is used as the start identifier and 0x65 is used as the end identifier. The parsing rules define three main data segment types: parameter name segment, parameter value segment, and control segment. The parameter name segment starts with 0x73, the parameter value segment starts with 0x72, and the control segment starts with 0x6D.

[0050] The length of each data segment is determined by dynamic length coding. In specific implementation, a variable length coding algorithm is used, where the first 4 bytes are used to store segment length information. The length calculation formula is: ,in, The actual length of the data segment to is the 4-byte value in the length field, Represents a left shift operation.

[0051] To improve parsing efficiency, the present application embodiment introduces a sliding window mechanism, and the window size W is dynamically adjusted according to data characteristics. The adjustment of the window size follows the following rules: ,in, is the base window size, which is 128 bytes. is the adjustment coefficient, the value is 0.15, is the standard deviation of the lengths of the last 100 data segments, The maximum window limit is set to 8192 bytes.

[0052] In the process of identifying data segment boundaries, the improved Boyer-Moore algorithm is used for pattern matching. The algorithm accelerates the matching process by building a bad character table and a good suffix table. For special cases, such as when encountering possible data segment overlap, the system will use the forward verification method to handle it. The specific operation is: check the data features of the 32 bytes before and after the suspicious boundary and calculate its entropy value ,in is the probability of occurrence of byte value i in the range. When the E value is between 2.5 and 6.7, the boundary is considered valid. This method can effectively avoid misjudgment and improve parsing accuracy.

[0053] In order to ensure the stability of the parsing process, each potential data segment needs to be checked and verified. The checksum calculation uses the improved Fletcher algorithm: ,in is the value of the ith byte in the data segment. The data segment is considered valid only if the calculated checksum matches the checksum stored at the end of the data segment.

[0054] In the actual data segment parsing implementation process, the system first loads the predefined segment type mapping table, which defines the specific structural characteristics of different types of data segments. The mapping table is stored in the local configuration file in the form of key-value pairs, where the key is the segment type identifier (1 byte) and the value is a detailed description of the type of segment, including the expected length range, internal structure, etc.

[0055] The parsing process of data segments is divided into the following specific steps: First, the system reads the first 32 bytes of the data stream for initial analysis and extracts the file header information. The file header contains basic information such as the data version number, timestamp, and number of segments. The version number is used to determine the parsing strategy used. The currently supported version number range is 1.2.3 to 2.1.0. Next, the system establishes a segment relationship graph (SRG). The graph is represented by an adjacency matrix, and the matrix element aij represents the strength of association between the i-th segment and the j-th segment. The formula for calculating the association strength is: ,in, is the baseline correlation (value 0.8), is the distance between the two segments in the data stream, is the distance attenuation factor (value is 256), and are the lengths of the two segments respectively.

[0056] Furthermore, the data stream is divided into multiple data blocks and overlapping areas are reserved between the blocks. After the validity of the segments is confirmed by matching the feature library, the data segments are organized in a unified format, including: dividing the data stream into multiple data blocks of similar size, searching for segment boundary identifiers for each data block and constructing a segment position index; retaining overlapping areas between adjacent data blocks, and determining the ownership of data segments in the overlapping areas by calculating local context similarity; maintaining a dynamically updated segment feature library, calculating feature matching through feature weights and similarity scores, and confirming the validity of the segment when the feature matching exceeds a preset threshold; organizing the parsed data segments in a unified internal format, including segment type identification, segment length information, segment attribute flags, data payload and checksum.

[0057] Specifically, when extracting specific data segments, the system can adopt an improved divide-and-conquer strategy. First, the data stream is divided into multiple blocks of similar size. The block size is automatically adjusted according to the system memory limit and is usually set to 4096 bytes. For each block, the following operations are performed: Search for segment boundary identifiers within the block and build a preliminary segment position index. For each possible segment boundary position, calculate the statistical characteristics of the previous and subsequent data, including byte frequency distribution, repetitive patterns, etc. Use a dynamic programming algorithm to optimize the segment boundary position and minimize the probability of segmentation errors. To handle situations where data segments may span blocks, the system reserves a 64-byte overlapping area between blocks. For data segments in the overlapping area, their attribution is determined by calculating local context similarity. The similarity calculation takes into account the continuity and semantic consistency of the byte sequence.

[0058] During the parsing process, the system maintains a dynamically updated segment feature library to optimize the subsequent parsing process. The feature library contains statistical information of the identified segments, such as length distribution, content characteristics, etc. Calculated by feature matching: ,in is the feature weight (determined through experiments, for example, the length feature weight is 0.4, the content feature weight is 0.6), is the similarity score of the corresponding feature. When the value exceeds the threshold of 0.85, the validity of the segment can be quickly confirmed.

[0059] For the handling of abnormal situations, the system can run a multi-level fault-tolerance mechanism: When a data segment checksum mismatch is detected, try to use the alternative CRC32 check When the segment length exceeds the expected range, make corrections based on the characteristics of adjacent segments When an unknown segment type identifier appears, mark the segment as an object to be analyzed, and record the context information for subsequent analysis.

[0060] The parsed data segments are organized in a unified internal format, including: segment type identifier (1 byte), segment length information (4 bytes), segment attribute flag (1 byte), data payload (variable length), checksum (2 bytes). This organizational structure ensures the integrity and traceability of the data, and provides a clear processing boundary for the subsequent decoding process.

[0061] Step S303, decode each data segment to obtain the corresponding parameter name and parameter value; wherein the decoding process includes: converting the ASCII code in the target data segment into a string to obtain the parameter name; converting other data segments into unsigned integers to obtain parameter values. In a preferred embodiment of the present invention, the decoding process of the data segment includes two main steps: first, converting the ASCII code in the target data segment into a string to obtain the parameter name; second, converting other data segments into unsigned integers to obtain parameter values. This decoding method makes full use of the characteristics of ASCII encoding, so that the parameter name can be presented in a human-readable form, and at the same time, by converting the parameter value into an unsigned integer, the accuracy and consistency of the numerical value are guaranteed.

[0062] It should be noted that the decoding process may involve the conversion of multiple data types, not limited to ASCII code and unsigned integers. For example, some parameters may need to be decoded into floating point numbers, signed integers or other complex data types. Therefore, the decoding process of the present invention can be expanded and customized according to actual needs to support more data types and formats.

[0063] Step S304, convert the decoded data stream into a standardized format for storage in a database. A standardized format refers to a unified, standardized data representation format that facilitates data exchange and processing between different systems. The choice of a standardized format can be determined based on specific application scenarios and system requirements. For example, common data exchange formats such as JSON, XML, and CSV can be used, or a custom structured data format (such as Figure 4 The process of converting data into a standardized format may involve operations such as reorganizing the data structure, converting data types, and adding metadata. The step of storing in a database is to persist the standardized data for subsequent query, analysis, and use. The database can be a relational database (such as MySQL, Oracle, etc.), a non-relational database (such as MongoDB, Cassandra, etc.), or other types of data storage systems. Choosing the right database type and structure is crucial for efficient management and fast retrieval of data.

[0064] Figure 4 A flowchart of another data standardization method provided in an embodiment of the present application is shown below. Figure 4 As shown, the standardized format includes storing the parameters of each process step as independent data entries, each data entry contains parameter name, parameter value, lower limit value and upper limit value fields; when the parameter name is a step, the parameter value is configured as a step identifier, and the corresponding lower limit value and upper limit value fields in the database are left blank.

[0065] Figure 5A schematic diagram of a hierarchical data structure provided in an embodiment of the present application.

[0066] like Figure 5 As shown, 1001 is the control code (CCode). The device manual will explain what the parameters under each CCode mean. There are 4 parameters under 1001. Suppose the parameter names of the four parameters are as follows: StepName1 (StepName), 20 (Time), 30 (Temperature), 40 (Pressure). RMS will parse the content into the following format and store it in the database, as shown in Table 1:

[0067] Table 1 The data format stored in the database after parsing the hierarchical data

[0068]

[0069] Figure 6 A schematic diagram of a data stream encoding data structure provided for an embodiment of the present application requires parsing of binary data. The parsing rules will be described in the manual of the device. The following is a parsing of the simple Demo above, where the first part is 16 bytes, excluding the leading 00 bytes, and the following eight bits are converted into a string according to the ASCII code to be UserName. The second part is 4 bytes of Unsigned Int data, which is converted into a number to be 300. The third part is also 4 bytes of Unsigned Int data, which is converted into a number to be 200. The actual Body will be very long, and the parsing rules will be more complicated. RMS will parse the data into the following format and store it in the database, as shown in Table 2:

[0070] Table 2 Data format stored in the database after parsing the data stream encoding stream

[0071]

[0072] Figure 7 A flow chart of a method for responding to a data request provided in an embodiment of the present application. Figure 7 As shown, a method for responding to a data request includes the following steps:

[0073] Step S701, establish and store a mapping relationship, which is used to map the recipe name and parameter name of the target system to the corresponding name in the database. Configure the mapping relationship. There may be differences in recipe names and parameter naming between different systems. The system integrates a conversion configuration function. This function can automatically convert recipe names and parameter names in the FDC system, including but not limited to, into corresponding names and parameters in the RMS system, thereby eliminating naming differences between different systems and ensuring the consistency and accuracy of recipe data.

[0074] Step S702, receiving a data request from the target system through a data interface, wherein the data request includes a system name and a recipe list, wherein the recipe list includes a tool identifier, a recipe name, and a parameter list. For example, for an FDC system request through a specified data interface, the request data structure is as follows:

[0075] 1. SystemName (request system name)

[0076] 2. RecipeList (request recipe list)

[0077] 2.1. ToolId (Which device does the recipe belong to)

[0078] 2.2 RecipeName (recipe name)

[0079] 2.3. Params (String array, which parameters need to be queried)

[0080] Step S703: convert the recipe name and parameter name in the data request into the corresponding recipe name and parameter name in the database according to the configured mapping relationship.

[0081] Step S704: Based on the converted name, query the corresponding recipe parameter information and parameter control range in the database.

[0082] Specifically, RMS performs data mapping: According to the Mapping configuration, the recipe name and parameter name in the FDC request are converted into the corresponding recipe name and parameter name in the RMS system, and the recipe parameter information and card control range data are queried.

[0083] Step S705, generating response data, the response data including the system name, the recipe list, wherein the recipe list includes the tool identifier, the recipe name and the parameter information, the parameter information includes the parameter name, the parameter setting value, the parameter lower control limit value and the parameter upper control limit value. At step S606, the response data is returned to the target system through the data interface.

[0084] Taking the above content as an example, the data returned by RMS to the FDC system in the standard data structure is as follows:

[0085] 1. SystemName (request system name)

[0086] 2. RecipeList (request recipe list)

[0087] 2.1. ToolId (Which device does the recipe belong to)

[0088] 2.2, RecipeName (Recipe name)

[0089] 2.3 Params

[0090] 2.3.1. Name (parameter name)

[0091] 2.3.2. Value (parameter setting value)

[0092] 2.3.3, LSL (parameter card control lower limit)

[0093] 2.3.4. USL (lower limit of parameter card control)

[0094] Figure 8 A schematic diagram of an example of a request data structure in a data return format provided in an embodiment of the present application; Fig. 9 This is a schematic diagram of an example of a reply data structure in a data return format provided in an embodiment of the present application. The final return format described in the above embodiment can be as follows Figure 8 and 9 The effect is shown.

[0095] Second embodiment

[0096] Fig.10 A schematic block diagram of a data management system for semiconductor process recipe parameters provided in an embodiment of the present application. It should be understood that the system shown in the figure is exemplary and non-restrictive. This means that the system architecture involved is not limited to a specific form or design, but is presented as an example. In other words, the architecture shown in the figure can be regarded as a way of expression to clearly describe related concepts and relationships, and does not exclude other forms of architecture. Therefore, when interpreting the architecture in the picture, it should be understood that the model is flexible and diverse, and its purpose is to provide an exemplary description rather than a restrictive provision on a specific form.

[0097] Specifically, if Fig.10As shown, a data management system for semiconductor process recipe parameters is used to execute the above-mentioned data management method, and the system includes: a recipe collection unit 1001 and a data management unit 1002; wherein, the recipe collection unit 1001 is used to collect data in one or more formats containing semiconductor process recipes from one or more devices; the data management unit 1002 is used to perform data analysis on the collected process recipes in one or more data formats to convert them into a target data format and store them in a database; in response to a data request transmitted through a data interface, the corresponding process recipe data in the database is returned through the data interface in the format of the data request based on the configured mapping relationship.

[0098] In summary, the embodiment of the present application supports offline and online sharing of recipe parameters through a unified data structure and format. It should be understood that offline sharing here refers to data exchange and use in a non-automated production environment. For example, when engineers configure fault detection and classification (FDC) parameters, they need to call relevant parameters from the recipe management system (RMS) for pre-filling. This offline sharing method does not rely on real-time network connection, and data exchange can be performed through file transfer or other non-real-time methods. Online sharing refers to the situation in which the system automatically checks and uses recipe parameters during the automated production process. For example, in the process of automated production and processing of wafers, the control program will access the RMS in real time, automatically check whether the currently used recipe meets the specification requirements, and update it in real time when necessary. This online sharing mechanism ensures that the recipe parameters used in the production process are always up to date and compliant. This flexible sharing mechanism of the present embodiment has many advantages: first, it adapts to different work scene requirements. In an offline environment, engineers can easily obtain and pre-fill parameters, which improves configuration efficiency; in an online production environment, the system can automatically check and update parameters to ensure the stability and consistency of the production process. Secondly, the unified data structure and format simplifies the difficulty of system integration, allowing RMS to seamlessly connect to various upstream and downstream systems, such as FDC systems, manufacturing execution systems (MES), etc. Thirdly, this mechanism improves data consistency and traceability. Whether it is offline configuration or online use, all parameter changes can be recorded and managed in RMS, which is convenient for subsequent auditing and analysis.

[0099] Furthermore, this system enables other systems (such as the FDC system and the APC system) to query the recipe information in a standard format. This interoperability ensures parameter consistency between different systems and avoids production problems caused by inconsistent data. For example, the FDC system can use standardized recipe parameters to set monitoring thresholds, and the APC system can make real-time process adjustments based on these parameters.

[0100] The method of the embodiment of the present application significantly reduces the duplication of engineers in recipe management. Traditionally, engineers may need to manually input recipe parameters from one system to another, or convert between different formats. This is not only time-consuming, but also prone to errors. Through automated data management processes, engineers can focus more time and energy on process optimization and problem solving, thereby improving production efficiency.

[0101] In addition, this method helps improve the stability of process quality. By ensuring that all related systems use consistent and up-to-date recipe parameters, process fluctuations caused by inconsistent or outdated parameters can be reduced. This is especially important in industries such as semiconductor manufacturing, which require extremely high precision and consistency.

[0102] It is not difficult to find that this embodiment is a system embodiment corresponding to the first embodiment, and this embodiment can be implemented in conjunction with the first embodiment. The relevant technical details mentioned in the first embodiment are still valid in this embodiment, and in order to reduce repetition, they are not repeated here. Accordingly, the relevant technical details mentioned in this embodiment can also be applied in the first embodiment.

[0103] It is worth mentioning that all modules involved in this embodiment are logic modules. In practical applications, a logic unit can be a physical unit, a part of a physical unit, or a combination of multiple physical units. In addition, in order to highlight the innovative part of this application, this embodiment does not introduce units that are not closely related to solving the technical problems proposed by this application, but this does not mean that there are no other units in this embodiment.

[0104] Third embodiment

[0105] In addition, some embodiments of the present application also provide an electronic device. The electronic device may be a digital computer in various forms, such as a laptop computer, a desktop computer, a workbench, a personal digital assistant, a server, a blade server, a mainframe computer, etc. The electronic device may also be a mobile device in various forms, such as a personal digital processing, a cellular phone, a smart phone, a wearable device, and other similar computing devices.

[0106] The electronic device includes: one or more processors; and a memory storing computer program instructions, wherein when the computer program instructions are executed, the processor executes the steps of the method provided in any one or more of the above embodiments. Fig.11 An exemplary structural diagram of the electronic device is disclosed. Fig.11As shown, the electronic device includes: one or more processors 1101, a memory 1102, and interfaces for connecting various components, including high-speed interfaces and low-speed interfaces. The various components are connected to each other using different buses and can be installed on a common mainboard or installed in other ways as needed. The processor can process instructions executed in the electronic device, including instructions stored in or on the memory to display graphical information of the GUI on an external input / output device (such as a display device coupled to the interface). In some other embodiments, if necessary, multiple processors and / or multiple buses can be used with multiple memories and multiple memories. Similarly, multiple electronic devices can be connected, and each device provides some necessary operations (for example, as a server array, a group of blade servers, or a multi-processor system). Among them, the components shown in this article, their connections and relationships, and their functions are only examples, and are not intended to limit the implementation of the present application described and / or required herein.

[0107] The electronic device may further include: an input device 1103 and an output device 1104. The processor 1101, the memory 1102, the input device 1103 and the output device 1104 may be connected via a bus or other means. Fig.11 The example of connecting through bus is taken in the following.

[0108] The input device 1103 can receive input digital or character information, and generate key signal input related to the user settings and function control of the electronic device, such as a touch screen, a keypad, a mouse, a track pad, a touch pad, an indicator rod, one or more mouse buttons, a trackball, a joystick and other input devices. The output device 1104 may include a display device, an auxiliary lighting device (e.g., an LED) and a tactile feedback device (e.g., a vibration motor), etc. The display device may include, but is not limited to, a liquid crystal display (LCD), a light emitting diode (LED) display and a plasma display. In some embodiments, the display device may be a touch screen.

[0109] To provide interaction with a user, the electronic device may be a computer. The computer has: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and a pointing device (e.g., a mouse or a trackball), through which the user can provide input to the computer. Other types of devices may also be used to provide interaction with a user; for example, the feedback provided to the user may be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user may be received in any form (including acoustic input, voice input, or tactile input).

[0110] Fourth embodiment

[0111] In the embodiments of the present application, a computer program / instruction is stored on a computer-readable medium, and when the computer program / instruction is executed by a processor, the steps of the method provided by any one or more of the above embodiments are implemented. The computer-readable medium may be included in the electronic device described in the above embodiments; or it may exist independently without being assembled into the device. The above computer-readable medium carries one or more computer-readable instructions.

[0112] The memory 1102 can be used as a non-transient computer-readable storage medium, which can be used to store non-transient software programs, non-transient computer executable programs and modules. The processor 1101 executes various functional applications and data processing of the server by running the non-transient software programs, instructions and modules stored in the memory 1102, so as to implement the program instructions / modules corresponding to the method provided by any one or more embodiments in the embodiments of the present application.

[0113] The memory 1102 may include a program storage area and a data storage area, wherein the program storage area may store an operating system, an application required for at least one function; the data storage area may store data created according to the use of the electronic device, etc. In addition, the memory 1102 may include a high-speed random access memory, and may also include a non-transient memory, such as at least one disk storage device, a flash memory device, or other non-transient solid-state storage device. In some embodiments, the memory 1102 may optionally include a memory remotely arranged relative to the processor 1101, and these remote memories may be connected to the electronic device via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0114] It should be noted that the computer-readable medium described in this application may be a computer-readable signal medium or a computer-readable storage medium or any combination of the above two. The computer-readable medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared or semiconductor system, device or device, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In this application, a computer-readable medium may be any tangible medium containing or storing a program that can be used by or in combination with an instruction execution system, device or device.

[0115] Computer readable media include permanent and non-permanent, removable and non-removable media, and can be implemented by any method or technology to store information. Information can be computer readable instructions, data structures, modules of programs or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, read-only compact disk (CD-ROM), digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic tape disk storage or other magnetic storage devices or any other non-transmission medium that can be used to store information that can be accessed by a computing device.

[0116] Computer program code for performing the operations of the present application may be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages, such as Java, Smalltalk, C++, and conventional procedural programming languages, such as "C" or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as a separate software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0117] In the above embodiments, all or part of the embodiments may be implemented by software, hardware, firmware or any combination thereof. For example, an application specific integrated circuit (ASIC), a general-purpose computer or any other similar hardware device may be used to implement the embodiments. In some embodiments, the software program of the present application may be executed by a processor to implement the above steps or functions. Similarly, the software program of the present application (including related data structures) may be stored in a computer-readable recording medium, such as a RAM memory, a magnetic or optical drive or a floppy disk and the like. In addition, some steps or functions of the present application may be implemented by hardware, for example, as a circuit that cooperates with a processor to perform various steps or functions.

[0118] Fifth embodiment

[0119] The computer program product provided in the embodiment of the present application includes one or more computer programs / instructions, which, when executed by the processor, generate in whole or in part the process or function described in the embodiment of the present application. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions may be transmitted from a website site, a computer, a server, or a data center to another website site, a computer, a server, or a data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can access or a data storage device such as a server or a data center that includes one or more available media integrated. The available medium may be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid state disk (SSD)), etc.

[0120] The flow chart or block diagram in the accompanying drawings shows the possible architecture, function and operation of the equipment, method and computer program product according to various embodiments of the present application. In this regard, each box in the flow chart or block diagram can represent a module, a program segment or a part of a code, and the module, the program segment or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order from the order marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flow chart, and the combination of the boxes in the block diagram and / or flow chart can be implemented with a dedicated system for hardware that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0121] The scope of the present application is defined by the appended claims rather than the above description, and it is intended that all changes that fall within the meaning and scope of the equivalent elements of the claims are included in the present application. Any figure mark in the claims should not be regarded as limiting the claims involved. In addition, it is clear that the word "comprising" does not exclude other units or steps, and the singular does not exclude the plural. Multiple units or devices stated in the device claim may also be implemented by one unit or device through software or hardware. The words "first", "second", etc. are only used to distinguish the description, and do not indicate any particular order, nor can they be understood as indicating or implying relative importance.

[0122] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art can easily mention changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims, and the above embodiments should be regarded as exemplary and non-restrictive.

Claims

1. A method for data management of semiconductor process recipe parameters, characterized in that: include: Performing data analysis on the collected process recipes in one or more data formats to convert them into target data formats and store them in a database; In response to a data request transmitted through a data interface, corresponding process recipe data in a database is returned through the data interface in a format of the data request based on a configured mapping relationship; The collected process recipes in one or more data formats are analyzed to convert them into target data formats and stored in a database, including: If the process recipe is a hierarchical data structure, receiving a process recipe including one or more process step information; wherein each process step includes a control code and multiple parameters; determining the meaning of each parameter under each control code according to a predefined equipment manual; and converting each parameter into a standardized format for storage in a database; If the process recipe is a binary data stream encoding data structure, a binary data stream containing the process recipe is received; according to a predefined parsing rule, the binary data stream is parsed into a plurality of data segments; each data segment is decoded to obtain a corresponding parameter name and parameter value; wherein the decoding process includes: converting an ASCII code in a target data segment into a string to obtain a parameter name; converting other data segments into unsigned integers to obtain parameter values; converting the decoded data stream into a standardized format to be stored in a database; According to the predefined parsing rules, the binary data stream is parsed into multiple data segments, including: preprocessing the binary data stream according to the preset byte identifier and defining the data segment type, reading the front preset byte to extract the file header information and then establishing an inter-segment relationship diagram; dividing the data stream into multiple data blocks and retaining the overlapping area between the blocks, and organizing the data segments in a unified format after confirming the validity of the segments through feature library matching; the inter-segment relationship diagram is a data structure represented by an adjacency matrix, and the elements of the adjacency matrix are It is used to characterize the correlation strength between the i-th segment and the j-th segment in the data stream. The correlation strength is determined by the following calculation formula: ,in, is the benchmark correlation, is the distance attenuation factor, is the distance between the i-th segment and the j-th segment in the data stream, and are the lengths of the i-th segment and the j-th segment respectively.

2. The data management method according to claim 1, characterized in that: in, Preprocess the binary data stream according to the preset byte identifier and define the data segment type, read the front preset byte to extract the file header information and then establish the inter-segment relationship diagram, including: Preprocessing the binary data stream by identifying a specific byte pattern as a paragraph identifier, wherein a first predetermined byte is used as a start identifier and a second predetermined byte is used as an end identifier; Based on the state transfer method, three data segment types are defined, including a parameter name segment starting with a third preset byte, a parameter value segment starting with a fourth preset byte, and a control segment starting with a fifth preset byte; Reading the data stream and presetting the bytes therein for initial analysis to extract the file header information, wherein the file header includes the data version number, timestamp and the number of segments; The inter-segment relationship graph is established and represented by an adjacency matrix, and the association strength is calculated by the baseline association degree, distance decay factor and segment length.

3. The data management method according to claim 1, characterized in that: in, Divide the data stream into multiple data blocks and retain the overlapping areas between the blocks. After confirming the validity of the segments through feature library matching, organize the data segments in a unified format, including: Divide the data stream into multiple data blocks of similar size, search for segment boundary identifiers for each data block and build a segment position index; The overlapping area is retained between adjacent data blocks, and the ownership of the data segment in the overlapping area is determined by calculating the local context similarity; Maintain a dynamically updated segment feature library, calculate feature matching through feature weights and similarity scores, and confirm the validity of the segment when the feature matching exceeds the preset threshold; The parsed data segments are organized according to a unified internal format, including segment type identification, segment length information, segment attribute flags, data payload and checksum.

4. The data management method according to claim 2 or 3, characterized in that: in, The standardized formats include: The parameters of each process step are stored as independent data entries. Each data entry contains parameter name, parameter value, lower limit value and upper limit value fields. When the parameter name is step, the parameter value is configured as the step identifier, and the corresponding lower limit value and upper limit value fields in the database are left blank.

5. The data management method according to claim 1, characterized in that: in, In response to a data request passed in through a data interface, the corresponding process recipe data in the database is returned through the data interface in the format of the data request based on the configured mapping relationship, including: Establishing and storing a mapping relationship, wherein the mapping relationship is used to map the recipe name and parameter name of the target system to the corresponding name in the database; Receiving a data request from a target system through a data interface, wherein the data request includes a system name and a recipe list, wherein the recipe list includes a tool identifier, a recipe name, and a parameter list; According to the configured mapping relationship, the recipe name and parameter name in the data request are converted into the corresponding recipe name and parameter name in the database; Based on the converted name, query the corresponding recipe parameter information and parameter control range in the database; Generate response data, the response data including a system name and a recipe list, wherein the recipe list includes a tool identifier, a recipe name and parameter information, and the parameter information includes a parameter name, a parameter setting value, a parameter lower control limit value and a parameter upper control limit value; The response data is returned to the target system through the data interface.

6. A data management system for semiconductor process recipe parameters using the data management method according to any one of claims 1 to 5, characterized in that: include: Recipe collection unit and data management unit; among them, The recipe collection unit is used to collect data in one or more formats containing semiconductor process recipes from one or more devices; The data management unit is used to parse the collected process recipes in one or more data formats to convert them into a target data format and store them in a database; in response to a data request passed in through a data interface, the corresponding process recipe data in the database is returned through the data interface in the format of the data request based on the configured mapping relationship.

7. An electronic device, characterized in that: The electronic device comprises: one or more processors; and A memory storing computer program instructions, which, when executed, cause the processor to perform the steps of the method as claimed in any one of claims 1 to 5.

8. A computer readable medium having a computer program / instruction stored thereon, characterized in that: When the computer program / instructions are executed by a processor, the steps of the method according to any one of claims 1 to 5 are implemented.

9. A computer program product comprising a computer program / instructions, characterized in that When the computer program / instructions are executed by a processor, the steps of the method described in any one of claims 1 to 5 are implemented.

Images