Method, system, device and medium for managing semiconductor back-end-of-line multi-layer carriers

Abstract

This invention discloses a method, system, device, and medium for managing multi-layer carriers in semiconductor back-end processes. The method includes: defining a data model containing a carrier type table and a carrier content mapping table; configuring station type parameters for processing stations based on the semiconductor process flow, including station type identifiers to distinguish between ordinary stations, wafer boat stations, and carrier replacement stations, and carrier replacement flags indicating carrier replacement needs; inputting the real-time carrier nesting relationship into the data model to generate a real-time data storage model; when a carrier arrives at a processing station, if it is determined that a carrier replacement is required, automatically querying the target carrier type for the next station, selecting an idle carrier from the available carrier pool to perform the replacement operation, updating the nesting relationship, and ensuring data consistency through database transactions. This invention solves the problems of low replacement efficiency and data consistency caused by insufficient nesting relationship management in multi-layer carriers in semiconductor back-end processes, improving the automation level and reliability of material flow.

Description

Technical Field

[0001] This invention belongs to the field of semiconductor packaging and testing technology, and particularly relates to a management method, system, equipment and medium for multilayer carriers in semiconductor back-end processes. Background Technology

[0002] Semiconductor manufacturing is generally divided into front-end processes (FEOL) and back-end processes (BEOL):

[0003] The front-end process involves the fabrication of devices on the wafer, such as photolithography, etching, and deposition, to form transistors and circuits.

[0004] Back-end processes, which begin after wafer dicing, include:

[0005] Packaging process: Dividing wafers into chips and packaging them to protect the circuitry (such as wire bonding, plastic encapsulation).

[0006] Testing process: Perform functional, performance and reliability tests on the packaged chip.

[0007] In semiconductor packaging and testing processes, carriers (such as FOUP wafer cassettes and trays) typically exist in a multi-layered nested structure, with wafer cassettes placed within trays for handling or storage. Current technologies rely heavily on decentralized subsystems for carrier management: the Materials Handling System (AMHS) handles physical transport, and the Manufacturing Execution System (MES) manages work order status. However, a unified modeling of the nested relationships between carriers is lacking. For example, carrier replacement often requires manual identification of the station type and manual updating of associated data, leading to inefficiency and a high risk of errors. Especially when processing stations involve special operations (such as carrier exchange or boat-type transfers), existing systems cannot automatically determine replacement needs, requiring operator intervention to check carrier status and process configuration. This not only delays production lines but may also cause material mixing or yield losses due to data asynchrony. Furthermore, while existing carrier management modules (such as semi-automated cleaning systems) can track the status of individual carriers, they cannot maintain multi-layered nested relationships. Therefore, the main problem with existing technologies lies in the management of multi-layer carriers in semiconductor back-end processes. Due to the lack of a unified data model for carrier nesting relationships and a dynamic configuration mechanism based on process stations, carrier replacement relies on manual labor, resulting in low efficiency and poor data consistency. Summary of the Invention

[0008] The technical problem this invention aims to solve is to address the shortcomings of the prior art by providing a management method, system, device, and medium for multi-layer carriers in semiconductor back-end processes. By defining a data model including a carrier type table and a carrier content mapping table, and dynamically triggering carrier change operations based on the type parameters of processing stations, unified management and automated switching of carrier nesting relationships are achieved. This effectively solves the problems of low carrier change efficiency and data consistency caused by insufficient management of nesting relationships, significantly improving the automation level and reliability of material flow in semiconductor back-end processes.

[0009] The first aspect of this invention discloses a method for managing multilayer carriers in semiconductor back-end processes, comprising the following steps:

[0010] Step 1: Define the data model, which includes a vehicle type table and a vehicle content mapping table. The vehicle type table is used to store the unique identifier and vehicle type of the vehicle, and the vehicle content mapping table is used to store the nesting relationship between parent vehicle identifiers and child vehicle identifiers, and to distinguish the nesting method by the relationship type.

[0011] Step 2: Determine the processing stations based on the semiconductor process flow, and configure station type parameters for each processing station. The station type parameters include a station type identifier and a carrier change flag corresponding to each process step. The station type identifier is used to distinguish between ordinary stations, crystal boat stations, and carrier change stations, and the carrier change flag is used to indicate whether a carrier change needs to be performed at the current processing station.

[0012] Step 3: Input the real-time nesting relationship of the real-time vehicles into the data model to generate a real-time data storage model corresponding to the real-time vehicles;

[0013] Step 4: When the real-time vehicle arrives at the processing station, based on the real-time data storage model, the following sub-steps are executed:

[0014] Sub-step 4.1: Analyze the station type parameter of the current processing station according to the current process step. When the station type is identified as a vehicle replacement station and the vehicle replacement flag is true, it is determined that the vehicle needs to be replaced, and sub-step 4.2 is executed. When it is determined that the vehicle does not need to be replaced, the vehicle location table is updated in the real-time data storage model, the current vehicle identifier is associated with the processing station, and a signal is triggered to the execution device to perform the current process step.

[0015] Sub-step 4.2: Query the target carrier type of the next processing station in the semiconductor process flow from the real-time data storage model;

[0016] Sub-step 4.3: Based on the target vehicle type, select an idle vehicle identifier from the available vehicle pool and perform a vehicle replacement operation, including removing the old vehicle association from the current nested relationship and adding a new vehicle association to the real-time data storage model, while updating the records in the vehicle content mapping table to ensure data consistency through database transactions.

[0017] The above method, in step three, inputting the real-time nesting relationship of real-time vehicles into the data model includes: parsing the input data of the real-time nesting relationship of actual vehicles, generating records of the vehicle type table and vehicle content mapping table based on the input data, and inputting them into the data model all at once through batch processing.

[0018] In the above method, in sub-step 4.1, if the site type is identified as a crystal boat site, then an additional operation is performed: query the sub-vehicle association data of the current vehicle, perform boat-type conversion processing based on the sub-vehicle association data, and determine that it is not necessary to change the vehicle.

[0019] The vehicle replacement operation in sub-step 4.3 of the above method also includes a verification step: before updating the vehicle content mapping table, verify the compatibility between the target vehicle type and the current vehicle type. If the verification fails, terminate the operation and record the error log.

[0020] The vehicle replacement operation in sub-step 4.3 of the above method further includes: before adding a new vehicle association, querying the vehicle status table, selecting an idle vehicle identifier from the vehicle status table according to the target vehicle type, and adding the selected idle vehicle identifier as a new vehicle association to the real-time data storage model.

[0021] In the above method, the relationship type in step one includes a string value used to represent the type of nested relationship. The relationship type includes "load" or "accommodate", where "load" indicates that the parent vehicle physically contains the child vehicle, and "accommodate" indicates that the parent vehicle logically associates with the child vehicle.

[0022] In the above method, the site type parameter in step two also includes a compatible vehicle type, which is used to specify the vehicle types allowed at the current processing site. The compatible vehicle type is input through a configuration interface and stored in the database.

[0023] A second aspect of this invention discloses a management system for a multilayer carrier in a semiconductor back-end process, comprising:

[0024] The data model definition module is used to define the data model, which includes a vehicle type table and a vehicle content mapping table. The vehicle type table is used to store the unique identifier and vehicle type of the vehicle, and the vehicle content mapping table is used to store the nesting relationship between the parent vehicle identifier and the child vehicle identifier, and to distinguish the nesting method by the relationship type.

[0025] The site configuration module is used to determine the processing site based on the semiconductor process flow and configure the site type parameter for each processing site. The site type parameter includes a site type identifier and a carrier change flag corresponding to each process step. The site type identifier is used to distinguish between ordinary sites, crystal boat sites and carrier change sites, and the carrier change flag is used to indicate whether a carrier change needs to be performed at the current processing site.

[0026] The real-time model generation module is used to input the real-time nesting relationship of the real-time vehicle into the data model and generate a real-time data storage model corresponding to the real-time vehicle.

[0027] The vehicle processing control module is used to execute vehicle processing logic based on the real-time data storage model when the real-time vehicle arrives at the processing station. The vehicle processing control module includes:

[0028] The site parameter parsing unit is used to parse the site type parameter of the current processing site according to the current process step. When the site type is identified as a vehicle replacement site and the vehicle replacement flag is true, it is determined that the vehicle needs to be replaced and the vehicle replacement unit is triggered. When it is determined that the vehicle does not need to be replaced, the vehicle location table is updated in the real-time data storage model, the identifier of the current vehicle is associated with the processing site, and a signal is triggered to the execution device to perform the current process step.

[0029] The target vehicle query unit is used to query the target vehicle type of the next processing station in the semiconductor process flow from the real-time data storage model when a vehicle change is required.

[0030] The vehicle replacement execution unit is used to select an idle vehicle identifier from the available vehicle pool according to the target vehicle type, and perform a vehicle replacement operation, including removing the old vehicle association from the current nested relationship, adding a new vehicle association to the real-time data storage model, and updating the records in the vehicle content mapping table to ensure data consistency through database transactions.

[0031] A third aspect of the present invention discloses an electronic device, comprising: a memory and a processor, wherein the processor and the memory are connected;

[0032] The memory is used to store programs;

[0033] The processor invokes a program stored in the memory to execute the method provided by the first aspect embodiment and / or any possible embodiment in combination with the first aspect embodiment.

[0034] The fourth aspect of the present invention discloses a computer-readable storage medium having a computer program stored thereon, the computer program being executed by a computer to perform the methods provided by the embodiments of the first aspect and / or any possible embodiments in combination with the embodiments of the first aspect.

[0035] Compared with existing technologies, this invention has the following advantages: By defining a data model that includes a carrier type table and a carrier content mapping table, and particularly by using the carrier content mapping table to store the nesting relationship between parent and child carrier identifiers and distinguishing the nesting method by relationship type, this invention provides a unified and structured data management foundation for complex multi-layer carrier (such as FOUP, Cassette, Tray, etc.) nesting relationships in semiconductor back-end processes. This directly solves the deficiency of lacking unified modeling of carrier nesting relationships in the prior art, enabling clear and accurate recording and maintenance of the association relationships between carriers, laying a data foundation for subsequent automated management, and fundamentally avoiding management chaos and errors caused by unclear relationships.

[0036] Secondly, by configuring site type parameters (including site type identifiers and carrier changeover flags) for each processing station based on the semiconductor process flow, the system can automatically distinguish between ordinary stations, wafer boat stations, and carrier changeover stations, and dynamically determine carrier changeover needs. This mechanism automates the carrier changeover decision-making process, replacing the previous method of relying on manual identification of site types and manual judgment. When the carrier arrives at the station, the system can automatically parse the parameters and trigger the corresponding process, significantly reducing manual intervention and lowering the risk of production interruptions or erroneous operations caused by human error or delay, thereby improving the efficiency and accuracy of carrier changeover decisions.

[0037] Third, by inputting the nesting relationship of real-time vehicles into the data model to generate a real-time data storage model, and upon determining that a vehicle replacement is needed, the system automatically queries the target vehicle type for the next station, selects an available vehicle from the pool of available vehicles, executes the replacement operation, and updates the nesting relationship. Simultaneously, database transactions ensure data consistency, achieving automation and precise control of the entire vehicle replacement process. This not only significantly improves the execution efficiency of vehicle switching and reduces machine waiting time, but more importantly, it ensures the atomicity of changes in vehicle association relationships through transactional operations. This completely solves the consistency problems such as data asynchrony and material mixing that are easily caused by manual operations or non-transactional updates in the background technology, ensuring real-time matching of physical material flow and information flow, and improving the reliability and traceability of the entire production process.

[0038] The technical solution of the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. Attached Figure Description

[0039] Figure 1 This is a flowchart of the method in Embodiment 1 of the present invention.

[0040] Figure 2 This is an example diagram of the overall process flow for semiconductors.

[0041] Figure 3 This is a schematic diagram of a multi-vehicle station.

[0042] Figure 4 This is a sample diagram of the business process for the Jingzhou site.

[0043] Figure 5 This is a sample diagram of the business process for a normal website.

[0044] Figure 6 Example diagram of the business process for changing the station for a vehicle.

[0045] Figure 7 This is a system module diagram of Embodiment 2 of the present invention. Detailed Implementation

[0046] Example 1

[0047] like Figure 1 As shown, a method for managing multilayer carriers in semiconductor back-end processes includes the following steps:

[0048] Step 1: Define the data model, which includes a vehicle type table and a vehicle content mapping table. The vehicle type table is used to store the unique identifier and vehicle type of the vehicle, and the vehicle content mapping table is used to store the nesting relationship between parent vehicle identifiers and child vehicle identifiers, and to distinguish the nesting method by the relationship type.

[0049] During implementation, in the Manufacturing Execution System (MES), two core database tables are first created—a vehicle type table and a vehicle content mapping table—to standardize the management of vehicle nesting relationships. The vehicle type table stores the unique identifier of a vehicle (e.g., CarrierId) and its type (e.g., CarrierType, which can be defined as a string such as "Magazine", "Boat", or "Tray"). The vehicle content mapping table stores the nesting relationships between parent and child vehicles, including fields such as parent vehicle identifier (ParentCarrierId), child vehicle identifier (ChildCarrierId), and relationship type (RelationshipType). The relationship type distinguishes the nesting method through string values; for example, "load" indicates physical containment (e.g., Magazine directly contains Boat), while "contains" indicates logical association (e.g., Boat is associated with Substrate, but Substrate is not a vehicle).

[0050] This data model enables structured storage of vehicle information, improving data query efficiency and consistency. For example, during the initialization phase, engineers input vehicle data through the MES interface, such as the vehicle type table recording CarrierId as "M001" and CarrierType as "Magazine," and the vehicle content mapping table recording ParentCarrierId as "M001," ChildCarrierId as "B001," and RelationshipType as "Loading." This allows the system to quickly track vehicle levels and supports subsequent dynamic operations.

[0051] In the scenario implementation, Magazine M001 nests Boat B001, and Boat B001 in turn loads Substrate. After the data model records these relationships, the system can accurately manage vehicle movement and avoid confusion.

[0052] Step 2: Determine the processing stations based on the semiconductor process flow, and configure station type parameters for each processing station. The station type parameters include a station type identifier and a carrier change flag corresponding to each process step. The station type identifier is used to distinguish between ordinary stations, crystal boat stations, and carrier change stations, and the carrier change flag is used to indicate whether a carrier change needs to be performed at the current processing station.

[0053] When implementing, refer to Figure 2 and Figure 3As shown, a complete process flow diagram is defined in the MES, including multiple processing stations (such as cutting stations, cleaning stations, and packaging stations). Each station is configured with station type parameters, including a station type identifier (SiteTypeId) and a carrier change flag (CarrierChangeFlag). The station type identifier distinguishes the station category: normal station (identified as "Normal"), carrier station (identified as "SBSTOnBoat"), and carrier change station (identified as "ExchangeCarrier"). The carrier change flag is a Boolean value; true indicates that a carrier change is required. Parameters are entered through the MES configuration interface. For example, an engineer sets SiteTypeId to "ExchangeCarrier" and CarrierChangeFlag to true for the packaging station.

[0054] Parametric configuration enables the system to flexibly adapt to different process requirements, reduces hard-coding dependencies, and improves maintainability and scalability. For example, when the vehicle arrives at the station, the system automatically parses the parameters to achieve precise control.

[0055] In this scenario, the wafer moves from the dicing station (normal station) to the cleaning station (crystal boat station), and finally to the packaging station (carrier change station). The packaging station is configured to require carrier change to ensure that the carrier type matches the next process.

[0056] Step 3: Input the real-time nesting relationship of the real-time vehicles into the data model to generate a real-time data storage model corresponding to the real-time vehicles;

[0057] During implementation, the system receives real-time nested relationship data of actual vehicles through interfaces (such as sensors or upstream systems), including vehicle identifiers and parent-child relationships. After parsing the input data, records in a vehicle type table and a vehicle content mapping table are generated and written to the database all at once through batch processing, avoiding the latency caused by operating each record individually. The real-time data storage model is an in-memory data structure (such as an object model or cache) that maps the current state of the vehicles, supporting fast querying and updating.

[0058] It achieves efficient data initialization and real-time synchronization, ensuring system response speed and data consistency. Batch processing reduces database load and improves performance.

[0059] In the scenario implementation, when Magazine M001 carries Boat B001 into the system, the real-time data input includes ParentCarrierId as "M001" and ChildCarrierId as "B001". After parsing, the system updates the data model and generates a real-time storage model for subsequent site decisions.

[0060] Step 4: When the real-time vehicle arrives at the processing station, based on the real-time data storage model, the following sub-steps are executed:

[0061] Sub-step 4.1: Analyze the station type parameter of the current processing station according to the current process step. When the station type is identified as a vehicle replacement station and the vehicle replacement flag is true, it is determined that the vehicle needs to be replaced, and sub-step 4.2 is executed. When it is determined that the vehicle does not need to be replaced, the vehicle location table is updated in the real-time data storage model, the current vehicle identifier is associated with the processing station, and a signal is triggered to the execution device to perform the current process step.

[0062] When implementing, refer to Figure 4 , 5 As shown in Figure 6, the system monitors the carrier's position. When the carrier arrives at the station, it queries the real-time data storage model to obtain the current carrier identifier and then parses the station type parameter. If the station type identifier is "ExchangeCarrier" and the carrier replacement flag is true, the system determines that the carrier needs to be replaced; otherwise, the system updates the carrier location table (e.g., associating the carrier identifier with the station ID) and triggers a signal to the execution device (e.g., a robotic arm) to perform the process operation.

[0063] Automated decision-making reduces human error and improves process efficiency. For example, when no replacement is needed, the system can directly skip the station, saving time.

[0064] In the scenario implementation, Boat B001 arrives at the packaging station (ExchangeCarrier station). After the system parses the parameters, it determines that the carrier needs to be changed, and then proceeds to sub-step 4.2.

[0065] Sub-step 4.2: Query the target carrier type of the next processing station in the semiconductor process flow from the real-time data storage model;

[0066] During implementation, the system queries the configuration information of the next station based on the process flow diagram to obtain the target vehicle type (e.g., read from the station parameters). The target vehicle type specifies the types of vehicles allowed at the next station. For example, if the next station after the packaging station is the testing station, the target vehicle type is "Tray". This ensures the forward-looking nature of vehicle replacement and avoids process interruptions caused by type mismatches.

[0067] In the scenario implementation, the system queries that the next station (test station) requires a Tray vehicle, therefore the target vehicle type is "Tray".

[0068] Sub-step 4.3: Based on the target vehicle type, select an idle vehicle identifier from the available vehicle pool and perform a vehicle replacement operation, including removing the old vehicle association from the current nested relationship and adding a new vehicle association to the real-time data storage model, while updating the records in the vehicle content mapping table to ensure data consistency through database transactions.

[0069] During implementation, the system queries the vehicle status table (e.g., the list of available vehicles in the database) and selects an idle vehicle identifier (e.g., "T001") based on the target vehicle type (e.g., "Tray"). Then, it performs a replacement operation: removing the old vehicle association from the current nested relationship (e.g., deleting the association between B001 and M001), adding a new vehicle association (e.g., adding the association between T001 and M001), and updating the vehicle content mapping table. Data consistency is guaranteed through database transactions, meaning all update operations are executed atomically, and a rollback occurs if an update fails. This achieves seamless vehicle replacement, ensuring data integrity and process continuity, and reducing resource waste.

[0070] In the scenario implementation, the system selects an idle Tray T001 from the available vehicle pool, removes Boat B001 from Magazine M001, and associates T001 with M001. After completion, the real-time data storage model is updated, and M001 now nests T001, ready to enter the test station.

[0071] In one embodiment, step three, inputting the real-time nesting relationship of real-time vehicles into the data model, includes: parsing the input data of the real-time nesting relationship of actual vehicles, generating records of the vehicle type table and vehicle content mapping table based on the input data, and inputting them into the data model all at once through batch processing.

[0072] During implementation, when the system initializes or a vehicle enters the process, real-time nested relationship data (such as vehicle identifiers and parent-child relationships obtained from sensors or upstream systems) is parsed and, instead of inserting data into the database record by record, is first cached in a temporary data structure (such as a list or queue). Then, the system uses batch processing techniques, such as JDBC's batch update function or database batch INSERT statements, to write multiple records to the vehicle type table and vehicle content mapping table at once. Batch processing operations are automatically triggered by the system, typically when the data volume reaches a threshold or when a scheduled task is executed, ensuring that all related records are committed atomically.

[0073] This method significantly reduces the number of database interactions, lowers system load and network latency, and improves data initialization efficiency. Meanwhile, batch processing ensures data consistency, avoiding data inconsistencies caused by partial insertion failures.

[0074] In a scenario implementation, when multiple Magazines (such as M001 and M002) simultaneously bring Boats (such as B001 and B002) into the system, the system collects all nested relationship data (such as M001-B001, M002-B002) and then writes it to the database in a single batch operation. This saves time compared to inserting data row by row, and significantly improves system response speed, especially during peak periods.

[0075] In one embodiment, in sub-step 4.1, if the site type is identified as a crystal boat site, then an additional operation is performed: query the sub-vehicle association data of the current vehicle, perform boat-type conversion processing based on the sub-vehicle association data, and determine that no vehicle replacement is required.

[0076] During implementation, when the carrier arrives at the processing station, the system parses the station type parameter. If the station type is identified as "SBSTOnBoat," it first queries the real-time data storage model to obtain the sub-carrier association data of the current carrier (such as the Substrate list under Boat). Then, the system performs boat-like conversion processing, such as adjusting the carrier's orientation or triggering specific equipment (such as a robotic arm) to perform rotation or alignment operations to ensure process requirements (such as uniform cleaning or heating). After processing, if the system determines that the carrier does not need to be replaced, it directly updates the carrier position table, associates the current carrier with the station, and triggers a signal to the execution equipment.

[0077] The above operations optimize the dedicated processing logic of the crystal boat site, avoiding unnecessary vehicle changes and improving process accuracy and efficiency. The boat-type conversion process ensures the adaptability of the vehicle to specific sites and reduces human error.

[0078] In the scenario implementation, Boat B001, carrying the Substrate, arrives at the cleaning station (crystal boat station). The system detects multiple Substrates under B001 and then performs a boat-type conversion (e.g., rotating the Boat 180 degrees to ensure double-sided cleaning) without triggering a vehicle change. This streamlines the process and saves changeover time.

[0079] In one embodiment, the vehicle replacement operation in sub-step 4.3 further includes a verification step: before updating the vehicle content mapping table, verify the compatibility between the target vehicle type and the current vehicle type; if the verification fails, terminate the operation and record an error log.

[0080] During implementation, before performing a vehicle replacement operation, the system reads compatibility rules from the configuration data (such as a vehicle type compatibility matrix stored in a database table), and then verifies whether the target vehicle type (e.g., Tray as required by the next stop) is compatible with the current vehicle type (e.g., Boat). The verification logic is based on predefined rules, such as comparing type matches through SQL queries or application logic (e.g., Tray can replace Boat, but Magazine cannot directly replace Substrate). If the verification fails (i.e., type incompatibility), the system terminates the operation, performs no updates, and logs an error to the system log file, including a timestamp, vehicle identifier, and error reason.

[0081] The above operations enhance the system's error prevention capabilities, preventing process interruptions or equipment damage caused by incompatible vehicle replacements, and improving reliability and safety. Error logs facilitate subsequent analysis and troubleshooting.

[0082] In the scenario implementation, if the target vehicle type of the system is Tray, but the current vehicle is Boat, and the verification rule allows for replacement (because Tray and Boat are compatible in the packaging process), then the operation continues; if it is mistakenly configured as Magazine, the verification fails, the system terminates and logs the error to prevent the propagation of errors.

[0083] In one embodiment, the vehicle replacement operation in sub-step 4.3 further includes: before adding a new vehicle association, querying the vehicle status table, selecting an idle vehicle identifier from the vehicle status table according to the target vehicle type, and adding the selected idle vehicle identifier as a new vehicle association to the real-time data storage model.

[0084] During implementation, the system maintains a vehicle status table containing fields such as vehicle identifier, vehicle type, and status (e.g., "Idle," "In Use," or "Under Repair"). When a vehicle needs to be replaced, the system first queries this table, using SQL statements to filter out a list of vehicles of the target vehicle type (e.g., Tray) with an "Idle" status. Then, based on a strategy (e.g., First-In-First-Out (FIFO) or Most Recently Used, an idle vehicle identifier (e.g., T001) is selected. After selection, the system temporarily locks the vehicle's status before performing the replacement operation to prevent concurrent access.

[0085] The above operations enable dynamic management of vehicle resources, ensuring resource availability during replacement, optimizing resource utilization, and reducing waiting time and conflict risks.

[0086] In the scenario implementation, the system finds the idle Tray T001 from the vehicle status table, associates it with MagazineM001, and updates the status to "in use". This avoids multiple processes competing for the same vehicle.

[0087] In one embodiment, the relationship type in step one includes a string value representing the type of nested relationship. The relationship type includes "load" or "accommodate", where "load" indicates that the parent vehicle physically contains the child vehicle, and "accommodate" indicates that the parent vehicle logically associates with the child vehicle.

[0088] During implementation, when defining the data model, relation type fields are set to string types (such as VARCHAR) in the database design and constrained to predefined values ​​(e.g., "Load" indicates physical containment, "Contain" indicates logical association). The application layer parses these string values ​​to determine nesting behavior; for example, when the relation type is "Load," the system may trigger physical operations (such as robotic arm grasping); when it is "Contain," only logical association is performed. The relation type is input through the MES configuration interface and stored in the vehicle content mapping table.

[0089] The above operations make the data model more semantic and scalable, easier to understand and maintain, and support the addition of new relationship types (such as "fixed" or "temporary") in the future without modifying the core structure.

[0090] In the scenario implementation, the vehicle content mapping table records the relationship type "Loading" for Magazine M001 and Boat B001 (indicating physical containment), while "Containing" is used for Boat B001 and Substrate (indicating logical association). The system distinguishes operations based on type to ensure accuracy.

[0091] In one embodiment, the site type parameter in step two further includes a compatible vehicle type, which is used to specify the vehicle types allowed at the current processing site. The compatible vehicle type is input through a configuration interface and stored in a database.

[0092] During implementation, when configuring processing stations, engineers add a compatible vehicle type parameter for each station via the MES graphical interface. This parameter is entered in a list or multiple-selection format (e.g., allowing selection of Magazine, Boat, or Tray) and stored in the station configuration table in the database. The system reads this parameter at runtime to verify whether a vehicle is allowed to enter the station. For example, the compatible vehicle type in the station type parameter may include multiple options to accommodate mixed processes.

[0093] The above operations enable personalized configuration of sites, improve the flexibility and adaptability of the system, ensure that only compatible vehicles can enter specific sites, and reduce the risk of type errors.

[0094] In the scenario implementation, if the test station is configured with the compatible vehicle type as Tray, the system will prevent Boat vehicles from entering, thus avoiding process incompatibility; at the same time, the interface input makes the configuration easy to adjust and supports rapid response to process changes.

[0095] Example 2

[0096] like Figure 7 As shown, a management system for a multilayer carrier in a semiconductor back-end process includes:

[0097] The data model definition module is used to define the data model, which includes a vehicle type table and a vehicle content mapping table. The vehicle type table is used to store the unique identifier and vehicle type of the vehicle, and the vehicle content mapping table is used to store the nesting relationship between the parent vehicle identifier and the child vehicle identifier, and to distinguish the nesting method by the relationship type.

[0098] The site configuration module is used to determine the processing site based on the semiconductor process flow and configure the site type parameter for each processing site. The site type parameter includes a site type identifier and a carrier change flag corresponding to each process step. The site type identifier is used to distinguish between ordinary sites, crystal boat sites and carrier change sites, and the carrier change flag is used to indicate whether a carrier change needs to be performed at the current processing site.

[0099] The real-time model generation module is used to input the real-time nesting relationship of the real-time vehicle into the data model and generate a real-time data storage model corresponding to the real-time vehicle.

[0100] The vehicle processing control module is used to execute vehicle processing logic based on the real-time data storage model when the real-time vehicle arrives at the processing station. The vehicle processing control module includes:

[0101] The site parameter parsing unit is used to parse the site type parameter of the current processing site according to the current process step. When the site type is identified as a vehicle replacement site and the vehicle replacement flag is true, it is determined that the vehicle needs to be replaced and the vehicle replacement unit is triggered. When it is determined that the vehicle does not need to be replaced, the vehicle location table is updated in the real-time data storage model, the identifier of the current vehicle is associated with the processing site, and a signal is triggered to the execution device to perform the current process step.

[0102] The target vehicle query unit is used to query the target vehicle type of the next processing station in the semiconductor process flow from the real-time data storage model when a vehicle change is required.

[0103] The vehicle replacement execution unit is used to select an idle vehicle identifier from the available vehicle pool according to the target vehicle type, and perform a vehicle replacement operation, including removing the old vehicle association from the current nested relationship, adding a new vehicle association to the real-time data storage model, and updating the records in the vehicle content mapping table to ensure data consistency through database transactions.

[0104] The management system for semiconductor back-end process multilayer carriers provided in this embodiment has the same implementation principle and technical effects as the method embodiment in Embodiment 1. For the sake of brevity, any parts not mentioned in the system embodiment can be referred to the corresponding content in Embodiment 1.

[0105] Example 3

[0106] A computer-readable storage medium having a computer program stored thereon, the computer program being executed by a computer to perform the management method of a semiconductor back-end process multilayer carrier described in Embodiment 1 above.

[0107] Example 4

[0108] An electronic device includes: a memory and a processor, wherein the processor and the memory are connected;

[0109] The memory is used to store programs;

[0110] The processor invokes a program stored in the memory to execute a management method for a semiconductor back-end process multilayer carrier as described in Embodiment 1.

[0111] It should be noted that the electronic device mentioned may be, but is not limited to, personal computers (PCs), tablet computers, mobile internet devices (MIDs), etc.

[0112] It should be noted that processors, memory, and other components that may be present in electronic devices are electrically connected to each other, directly or indirectly, to enable data transmission or interaction. For example, processors, memory, and other components may be electrically connected to each other via one or more communication buses or signal lines.

[0113] It should be noted that the various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0114] In the several embodiments provided in this application, it should be understood that the disclosed systems and methods can also be implemented in other ways. The system embodiments described above are merely illustrative. For example, the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0115] In addition, the functional modules in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0116] If the aforementioned functions are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, laptop, server, mobile phone, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0117] The above description is merely a preferred embodiment of the present invention and does not constitute any limitation on the present invention. Any simple modifications, alterations, or equivalent structural changes made to the above embodiments based on the technical essence of the present invention shall still fall within the protection scope of the present invention.

Claims

1. A method for managing multilayer carriers in semiconductor back-end processes, characterized in that, The method comprises the following steps: Step 1: defining a data model, wherein the data model comprises a carrier type table and a carrier content mapping table, the carrier type table is used to store unique identification of a carrier and a carrier type, and the carrier content mapping table is used to store a nesting relationship between a parent carrier identification and a child carrier identification and distinguish a nesting mode through a relationship type; Step 2: determining a processing station based on a semiconductor process flow, and configuring a station type parameter for each processing station, wherein the station type parameter comprises a station type identification and a carrier replacement flag corresponding to each process step, the station type identification is used to distinguish a normal station, a boat station and a carrier replacement station, and the carrier replacement flag is used to indicate whether a carrier replacement needs to be performed at a current processing station; Step 3: inputting real-time nesting relationship of a real-time carrier into the data model to generate a real-time data storage model corresponding to the real-time carrier; Step 4: when the real-time carrier reaches a processing station, based on the real-time data storage model, the following sub-steps are performed: Sub-step 4.1: analyzing the station type parameter of the current processing station according to a current process step, when the station type identification is a carrier replacement station and the carrier replacement flag is true, it is determined that a carrier needs to be replaced, and sub-step 4.2 is performed; when it is determined that a carrier does not need to be replaced, a carrier position table is updated in the real-time data storage model, the identification of the current carrier is associated with the processing station, and a signal is triggered to an execution device to perform the current process step; Sub-step 4.2: querying a target carrier type of a next processing station of the semiconductor process flow from the real-time data storage model; Sub-step 4.3: selecting an idle carrier identification from an available carrier pool according to the target carrier type, and performing a carrier replacement operation, including removing an old carrier association from the real-time data storage model and adding a new carrier association to the real-time data storage model, and updating a record in the carrier content mapping table to ensure data consistency through a database transaction.

2. The method of claim 1, wherein, In the step 3, inputting the real-time nesting relationship of the real-time carrier into the data model comprises: analyzing input data of the real-time nesting relationship of the actual carrier, generating records of the carrier type table and the carrier content mapping table according to the input data, and inputting the data model through a batch processing operation at one time.

3. The method of claim 1, wherein, In the sub-step 4.1, if the station type identification is a boat station, an additional operation is performed: querying child carrier association data of the current carrier, and performing a boat conversion process based on the child carrier association data, and it is determined that a carrier does not need to be replaced.

4. The method of claim 1, wherein, The carrier replacement operation in the sub-step 4.3 further comprises a verification step: before updating the carrier content mapping table, the compatibility of the target carrier type and the current carrier type is verified, and if the verification fails, the operation is terminated and an error log is recorded.

5. The method of claim 1, wherein, The carrier replacement operation in the sub-step 4.3 further comprises: before adding the new carrier association, querying a carrier state table, selecting an idle carrier identification from the carrier state table according to the target carrier type, and adding the selected idle carrier identification as the new carrier association to the real-time data storage model.

6. The method of claim 1, wherein, The relationship type in the step one includes a string value, used to represent the type of nested relationship, and the relationship type includes "loading" or "containing", wherein "loading" represents that the parent carrier physically contains the child carrier, and "containing" represents that the parent carrier logically associates the child carrier.

7. The method of claim 1, wherein, The site type parameter in the step two further includes a compatible carrier type, used to specify the carrier type allowed by the current processing site, and the compatible carrier type is input through a configuration interface and stored in the database.

8. A management system of a semiconductor back-end-of-line multilayer carrier, characterized by, Comprise: a data model definition module, used to define a data model, wherein the data model comprises a carrier type table and a carrier content mapping table, the carrier type table is used to store the unique identification of a carrier and the carrier type, and the carrier content mapping table is used to store the nested relationship between the parent carrier identification and the child carrier identification, and distinguish the nested mode through the relationship type; a site configuration module, used to determine a processing site based on a semiconductor process flow, and configure a site type parameter for each processing site, wherein the site type parameter includes a site type identification and a carrier replacement flag corresponding to each process step, the site type identification is used to distinguish a normal site, a boat site and a carrier replacement site, and the carrier replacement flag is used to indicate whether carrier replacement needs to be performed at the current processing site; a real-time model generation module, used to input the real-time nested relationship of a real-time carrier into the data model, and generate a real-time data storage model corresponding to the real-time carrier; a carrier processing control module, used to execute carrier processing logic based on the real-time data storage model when the real-time carrier arrives at a processing site, and the carrier processing control module comprises: a site parameter analysis unit, used to analyze the site type parameter of the current processing site according to the current process step, and when the site type identification is a carrier replacement site and the carrier replacement flag is true, it is determined that the carrier needs to be replaced and a carrier replacement unit is triggered; when it is determined that the carrier does not need to be replaced, the carrier position table in the real-time data storage model is updated, the identification of the current carrier is associated with the processing site, and a signal is triggered to the execution equipment to perform the current process step; a target carrier query unit, used to query the target carrier type of the next processing site of the semiconductor process flow from the real-time data storage model when the carrier needs to be replaced; a carrier replacement execution unit, used to select an idle carrier identification from the available carrier pool according to the target carrier type, and perform a carrier replacement operation, including removing the old carrier association from the current nested relationship, and adding a new carrier association to the real-time data storage model, while updating the record in the carrier content mapping table to ensure data consistency through database transaction.

9. An electronic device, comprising: Comprise: a memory and a processor, wherein the processor is connected with the memory; the memory is used to store a program; the processor invokes the program stored in the memory to execute the method in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, A computer program is stored thereon, and the computer program is used to execute the method in any one of claims 1-7 when run by a computer. A computer program is stored thereon, and the computer program is used to execute the method in any one of claims 1-7 when run by a computer.

Images