OHT walking shunt, confluence control method

Abstract

The application discloses an OHT walking shunting and converging control method, comprising a communication module, a data storage module and a ZCU controller; the communication module is used for interacting with OHT equipment driving on an air track, a barcode is arranged on the air track, and after the OHT equipment reads the barcode information, the communication module acquires and reports the barcode information to the ZCU control module; the data storage module is used for user data storage, and the user data comprises basic data and real-time data; the ZCU control module is used for calculating shunting and converging area traffic conditions, the ZCU control module acquires real-time state information of the OHT equipment through the communication module, and compares and schedules OHT equipment operation according to the OHT real-time state information and the basic data in the data storage module. The application avoids the shortcomings of hardware traffic control, and can also work cooperatively with hardware converging management, so that double protection is achieved to avoid the occurrence of OHT collision.

Description

Technical Field

[0001] This invention relates to the field of semiconductor technology, and specifically to an OHT (Outgoing Current Transport) walking shunt and bus control method. Background Technology

[0002] The semiconductor industry is currently booming. Domestic chip production has accelerated the development of chip manufacturing-related systems. Automated wafer handling systems are essential in semiconductor processes, and traffic control and safety collision avoidance mechanisms in the diversion and convergence areas are crucial aspects of the entire wafer handling process.

[0003] Currently, most OHT systems manage traffic at merging and diverging points through hardware, which has drawbacks such as high cost and the need for installation. Summary of the Invention

[0004] The technical problem to be solved by the present invention is to provide an OHT (Outbound Traffic Flow) diversion and merging control method that avoids the shortcomings of hardware traffic control and can also work in conjunction with hardware merging management, providing dual protection to prevent OHT from detecting collisions.

[0005] To address the aforementioned technical problems, this invention provides an OHT (Outgoing Traffic Flow) splitting and merging control method, comprising a communication module, a data storage module, and a ZCU (Zero-Control Unit) controller.

[0006] The communication module is used to interact with the OHT equipment traveling on the overhead track. The overhead track is equipped with barcodes. After the OHT equipment reads the barcode information, the communication module obtains and reports it to the ZCU control module.

[0007] The data storage module is used for user data storage, which includes basic data and real-time data;

[0008] The ZCU control module is used to calculate the traffic conditions in the diversion and merging areas. The ZCU control module obtains the real-time status information of the OHT equipment through the communication module, compares the real-time status information of the OHT equipment with the basic data in the data storage module, and schedules the operation of the OHT equipment.

[0009] Furthermore, the communication protocol is TCP communication, and the communication format is JSON format.

[0010] Furthermore, the data storage module uses a relational database and a Redis in-memory database to work together, and the relational database is either MySQL or Oracle.

[0011] Furthermore, the basic data includes barcode mapping and path basic data, and the real-time data includes OHT data and traffic control queues.

[0012] Furthermore, the interactive functions include acquiring and controlling the OHT to stop moving, controlling the OHT to start moving, and adjusting the OHT's driving speed.

[0013] Furthermore, the barcode information is divided into slow-down barcodes, pause barcodes, and release barcodes.

[0014] Furthermore, scheduling methods include:

[0015] Step 1: The ZCU control module establishes TCP communication with the communication module. When the current OHT device passes the barcode on the overhead track, the barcode information is reported to the ZCU control module in real time through the OHT communication module. At the same time, the ZCU control module obtains the barcode mapping from the data storage module and compares it with the barcode information to confirm whether the reported barcode information is a splitting and merging barcode. If it is, proceed to Step 2; otherwise, no splitting and merging control is performed.

[0016] Step 2: Determine the type of the currently reported barcode information. The type includes deceleration barcode, pause barcode, and release barcode. If it is a deceleration barcode, proceed to step 3; if it is a pause barcode, proceed to step 4; if it is a release barcode, proceed to step 5.

[0017] Step 3: The ZCU control module obtains the current traffic control queue in the diversion and merging area from the data storage module, and determines whether the traffic control queue is empty. If the traffic control queue is not empty, the ZCU control module controls the current OHT device to decelerate through the communication module and stores the current OHT device information at the end of the traffic control queue; if the traffic control queue is empty, the current OHT device information is stored at the end of the traffic control queue, and no deceleration is performed.

[0018] Step 4: The ZCU control module retrieves the current traffic control queue in the diversion and merging area from the data storage module, and determines whether the traffic control queue is empty. If the traffic control queue is not empty, the ZCU control module controls the current OHT device to pause through the communication module, and simultaneously stores the OHT device information into the tail of the traffic control queue and continues to determine whether the traffic control queue is empty. If the traffic control queue is empty, the current OHT device is stored into the tail of the traffic control queue without pausing, or the currently paused OHT device is controlled to start moving.

[0019] Step 5: The ZCU control module obtains the traffic control queue in the current diversion and merging area from the data storage module, and determines whether the current OHT device is at the head of the traffic control queue. If not, it indicates an abnormality and sends an Alarm to the ZCU control module; otherwise, proceed to Step 6.

[0020] Step Six: Remove the information of the current OHT device from the head of the traffic control queue, then determine whether there is still OHT device information in the traffic control queue after removal. If there is, retrieve the OHT information of the head of the traffic control queue again and proceed to Step Seven.

[0021] Step 7: Based on the newly acquired OHT information of the head of the traffic control queue, determine whether it is in a paused state. If so, send a cancellation message; otherwise, do nothing.

[0022] Furthermore, in step three, the traffic control queue is a deceleration queue between the deceleration barcode and the pause barcode.

[0023] Furthermore, in step four, the traffic control queue is the release queue between the pause barcode and the release barcode. If the traffic control queue is empty, that is, the release queue is empty, then the current OHT device is removed from the deceleration queue and stored at the tail of the release queue. When it is a merging process, it is determined whether the current OHT device is at the head of the release queue. If it is, then the release queue is empty; otherwise, the release queue is not empty.

[0024] Furthermore, the traffic control queue in step five is a release queue.

[0025] The beneficial effects of this invention are:

[0026] By installing JDK, Redis, and relational databases such as MySQL or Oracle on a Linux system server and deploying the ZCU management module and barcode, it is possible to effectively monitor OHT devices. This achieves software-based traffic splitting and convergence combined with hardware for traffic control, providing dual control for greater security. The efficient processing logic and in-memory database mechanism allow high-speed OHT devices to be paused within 50 milliseconds. Attached Figure Description

[0027] Figure 1 This is a schematic diagram of the module relationship of the present invention;

[0028] Figure 2 This is a schematic diagram of the communication module of the present invention;

[0029] Figure 3 This is a schematic diagram of the data storage module of the present invention;

[0030] Figure 4This is a schematic diagram of the diversion area of ​​the present invention;

[0031] Figure 5 This is a schematic diagram of the convergence area of ​​the present invention;

[0032] Figure 6 This is a schematic diagram of the queuing of the present invention;

[0033] Figure 7 This is a flowchart of the overall control method of the present invention. Detailed Implementation

[0034] The present invention will be further described below with reference to the accompanying drawings and specific embodiments, so that those skilled in the art can better understand and implement the present invention. However, the embodiments described are not intended to limit the present invention.

[0035] Reference Figures 1 to 3 As shown, an embodiment of the OHT (Outgoing Traffic Flow) splitting and merging control method of the present invention includes a communication module, a data storage module, and a ZCU (Zero-Cell Unit) controller. The data storage module is used for user data storage, which includes basic data and real-time data. The data storage module uses a relational database and a Redis in-memory database in collaboration. The relational database is either MySQL or Oracle. The basic data includes barcodes. Mapping and path baseline data, real-time data including OHT data and traffic control queues, are provided to the ZCU control module for comparison and judgment. The communication module interacts with the OHT devices traveling on the elevated track. Barcodes are set on the elevated track. After the OHT devices read the barcode information, the communication module obtains and reports it to the ZCU control module. The barcode information is divided into deceleration barcodes, pause barcodes, and release barcodes, which allows the ZCU control module to obtain the current position of the OHT devices and provide corresponding correct judgment and control. The communication protocol is TCP communication, and the communication format is JSON. The ZCU control module is used to calculate the traffic conditions in the diversion and merging areas. The ZCU control module obtains the real-time status information of the OHT devices through the communication module, compares the real-time status information of the OHT devices with the baseline data in the data storage module, and schedules the operation of the OHT devices. Specifically, the interactive functions include obtaining and controlling the OHT to stop movement, controlling the OHT to start movement, and adjusting the OHT travel speed, i.e., scheduling the OHT devices to decelerate, run, and pause.

[0036] Reference Figure 4 , 6As shown in Figure 7, scheduling control is performed in a traffic splitting scenario. The ZCU control module establishes TCP communication with the communication module. When the current OHT device passes the barcode on the air track, the current OHT device reads the barcode information and obtains the barcode information. The barcode information is reported to the ZCU control module in real time through the OHT communication module. At the same time, the ZCU control module obtains the barcode mapping from the data storage module and compares it with the barcode information to confirm whether the reported barcode information is a traffic splitting barcode. If not, it means that traffic splitting is not required here, and the ZCU control module does not perform any control operations on the current OHT device. If it is a traffic splitting barcode, then traffic splitting control is required.

[0037] During the flow control process, it is first necessary to determine the type of the currently reported barcode information. The types include deceleration barcodes, pause barcodes, and release barcodes. Based on the type of barcode information, corresponding control processing is performed. Specifically, if it is a deceleration barcode, deceleration logic control is performed; if it is a pause barcode, pause logic control is performed; and if it is a release barcode, release logic control is performed. On the air track, deceleration barcodes and release barcodes can be used together, pause barcodes and release barcodes can be used together, or deceleration barcodes, pause barcodes, and release barcodes can be used in sequence.

[0038] Control is achieved through the coordination of deceleration and release barcodes, as well as pause and release barcodes. Specifically, during deceleration logic control, the ZCU control module retrieves the traffic control queue of the current diversion area from the data storage module and determines whether the traffic control queue is empty. If the traffic control queue is not empty, it means that there are OHT devices in the area that have not yet undergone release barcodes and are still in the diversion area. Therefore, to avoid collisions between the current OHT devices and those still in the area, the ZCU control module controls the current OHT devices to decelerate through the communication module and stores the current OHT device information at the end of the traffic control queue. If the traffic control queue is empty, the current OHT device information is simply stored at the end of the traffic control queue without deceleration, maintaining the current speed. Subsequently, the current OHT device undergoes entry and release logic control.

[0039] When pausing logic control, the ZCU control module retrieves the current traffic control queue in the merging / diversion area from the data storage module. It then checks if the queue is empty. If not, it indicates the presence of an OHT device that hasn't yet released its barcode. To avoid collisions, the ZCU control module uses the communication module to pause the current OHT device and stores its information at the end of the traffic control queue, continuing to check if the queue is empty. If empty, the OHT device is at the head of the queue, and its information is stored at the end. If not paused, the device continues running without pause. If paused, the paused OHT device begins moving forward. Subsequently, the current OHT device undergoes entry / exit logic control.

[0040] When releasing the logic control, the ZCU control module obtains the current traffic control queue in the diversion and merging area from the data storage module. It determines whether the current OHT device is at the head of the traffic control queue. If not, it indicates an abnormality and sends an alarm to the ZCU control module, reporting the error information. If it is at the head of the queue, the information of the current OHT device is removed from the head of the traffic control queue. It then determines whether there is still information of an OHT device in the removed traffic control queue. If there is, it obtains the OHT information of the head of the traffic control queue again. Based on the newly obtained OHT information of the head of the traffic control queue, it determines whether it is in a paused state. If the OHT device at the head of the queue is paused, it sends a cancel pause command and controls it to continue moving forward. Otherwise, it does not do anything, allowing the OHT device at the head of the queue to continue moving out of the release barcode area.

[0041] When deceleration, pause, and release bars are controlled sequentially, deceleration logic control is performed first. The traffic control queue here is the area between the deceleration bar and the pause bar, which is the deceleration queue. Within the deceleration queue, it is checked whether the traffic control queue is empty. If it is not empty, it means that there is a paused OHT device at the pause bar, or there is a moving OHT device between the deceleration bar and the pause bar, and deceleration is required. If it is empty, it means that there is no OHT device at the pause bar or between the deceleration bar and the pause bar, and the current OHT device can proceed normally.

[0042] Subsequently, the OHT device enters the pause barcode position and performs pause logic control. The traffic control queue here is the position between the pause barcode and the release barcode, which is the release queue. If the traffic control queue is not empty, the current OHT device is paused, and the OHT information of the current OHT device is not deleted from the deceleration queue to ensure accurate judgment during subsequent deceleration logic control. If the traffic control queue is empty, that is, the release queue is empty, the OHT information of the current OHT device is deleted from the deceleration queue and the OHT information of the current OHT device is stored at the end of the release queue for release logic control.

[0043] Reference Figure 5 As shown, this is a scheduling control scenario for the confluence. It determines whether the current OHT device is at the head of the release queue. If it is, the release queue is empty; otherwise, the release queue is not empty. This ensures that two OHT devices that are paused at the same time during the confluence process have a sequential judgment order.

[0044] This invention combines hardware and software, using barcodes as the basis for location identification. It controls the operation of the current OHT device by judging the operating status of the OHT devices in the entire queue through software. It has the ability to trigger actions in a short time, which is flexible, efficient, and safer. It effectively avoids OHT detection collisions and has low manufacturing cost.

[0045] The above-described embodiments are merely preferred embodiments provided to fully illustrate the present invention, and the scope of protection of the present invention is not limited thereto. Equivalent substitutions or modifications made by those skilled in the art based on the present invention are all within the scope of protection of the present invention. The scope of protection of the present invention is defined by the claims.

Claims

1. A method for controlling the flow splitting and merging of an OHT (Outgoing Traffic Controller), characterized in that, Includes a communication module, a data storage module, and a ZCU control module; The communication module is used for the ZCU control module to interact with the OHT equipment traveling on the overhead track. The overhead track is equipped with barcodes. After reading the barcode information, the OHT equipment reports it to the ZCU control module. The ZCU control module is used to calculate the traffic situation in the diversion and merging areas. The ZCU control module obtains the real-time status information of the OHT equipment, compares the real-time status information of the OHT with the basic data in the data storage module, and schedules the operation of the OHT equipment. Scheduling methods include: Step 1: The ZCU control module establishes TCP communication with the communication module. When the current OHT device passes the barcode on the overhead track, the barcode information is reported to the ZCU control module in real time. At the same time, the ZCU control module obtains the barcode mapping from the data storage module and compares it with the barcode information to confirm whether the reported barcode information is a splitting and merging barcode. If it is, proceed to Step 2; otherwise, no splitting and merging control is performed. Step 2: Determine the type of the currently reported barcode information. The type includes deceleration barcode, pause barcode, and release barcode. If it is a deceleration barcode, proceed to step 3; if it is a pause barcode, proceed to step 4; if it is a release barcode, proceed to step 5. Step 3: The ZCU control module retrieves the current traffic control queue in the diversion and merging area from the data storage module, and determines whether the traffic control queue is empty. If the traffic control queue is not empty, the ZCU control module controls the current OHT device to decelerate and stores the current OHT device information at the end of the traffic control queue; if the traffic control queue is empty, the current OHT device information is stored at the end of the traffic control queue, and no deceleration is performed. Step 4: The ZCU control module retrieves the current traffic control queue in the diversion and merging area from the data storage module, and determines whether the traffic control queue is empty. If the traffic control queue is not empty, the ZCU control module controls the current OHT device to pause, and simultaneously stores the OHT device's information into the tail of the traffic control queue and continues to determine whether the traffic control queue is empty. If the traffic control queue is empty, the ZCU control module performs the operation of storing the information into the tail of the traffic control queue for the current OHT device, without pausing it, or controls the currently paused OHT device to start moving. Step 5: The ZCU control module obtains the traffic control queue in the current diversion and merging area from the data storage module, and determines whether the current OHT device is at the head of the traffic control queue. If not, it indicates an abnormality and sends an Alarm to the ZCU control module; otherwise, proceed to Step 6. Step Six: Remove the information of the current OHT device from the head of the traffic control queue, then determine whether there is still OHT device information in the traffic control queue after removal. If there is, retrieve the OHT information of the head of the traffic control queue again and proceed to Step Seven. Step 7: Based on the newly acquired OHT information of the head of the traffic control queue, determine whether it is in a paused state. If so, send a cancellation message; otherwise, do nothing.

2. The OHT walking splitting and merging control method as described in claim 1, characterized in that, The data storage module uses a relational database and a Redis in-memory database to work together. The relational database can be MySQL or Oracle.

3. The OHT walking splitting and merging control method as described in claim 1, characterized in that, The data storage module is used for user data storage, which includes basic data and real-time data. The basic data includes barcode mapping and path basic data, and the real-time data includes OHT data and traffic control queues.

4. The OHT walking splitting and merging control method as described in claim 1, characterized in that, The interaction includes acquiring and controlling the OHT to stop moving, controlling the OHT to start moving, and adjusting the OHT's speed.

5. The OHT walking splitting and merging control method as described in claim 1, characterized in that, In step three, the traffic control queue is the deceleration queue between the deceleration barcode and the pause barcode.

6. The OHT walking splitting and merging control method as described in claim 5, characterized in that, In step four, the traffic control queue is the release queue between the pause barcode and the release barcode. If the traffic control queue is empty, that is, the release queue is empty, then the current OHT device is removed from the deceleration queue and stored at the tail of the release queue. When it is a merging process, it is determined whether the current OHT device is at the head of the release queue. If it is, then the release queue is empty; otherwise, the release queue is not empty.

7. The OHT walking splitting and merging control method as described in claim 6, characterized in that, The traffic control queue in step five is the release queue.

Images