Air carrier controller

Abstract

The air carrier controller comprises a first core and a second core, and a heat switching module is arranged in the first core; the hot switching module is used for determining whether a second core is restarted or needs to be restarted after the application program opens a virtual equipment node, and releasing a mapping relation between a virtual handle fed back to the application program by the hot switching module and a file descriptor obtained when the virtual equipment is opened when determining that the second core is restarted or needs to be restarted; and after determining that the second core is restarted, the hot switching module opens a new virtual device node at the first core, obtains a new file descriptor corresponding to the new virtual device node, and updates the file descriptor having a mapping relationship with the virtual handle as a new file descriptor. The application program of the first core can not sense restarting of the second core, the problem existing in data transmission when the second core is restarted is avoided, the high availability of the system is guaranteed, and the maintainability of the program is improved.

Description

Technical Field

[0001] The present invention relates to the field of overhead transport vehicle handling systems, in particular to an overhead transport vehicle controller. Background Art

[0002] The semiconductor manufacturing process involves hundreds of steps leading to the final product, and hundreds of thousands of items are moved throughout the manufacturing process. To prevent contamination, damage, and delivery accidents during this material transfer process, overhead hoist transfers (OHTs) are used. OHTs move along ceiling-mounted rails to transport FOUPs (Front Opening Unified Pods) loaded with wafers. Patent application publication number CN114388411A discloses a practical OHT system.

[0003] As described in the patent document, the AHV is controlled by an AHV controller (control unit) to perform various operations.

[0004] As shown in the patent document with application publication number CN119094479A, the aerial transport vehicle controller includes a first core and a second core that communicate between cores via the RPMSG communication protocol. The first core runs the main program, and the second core is used for real-time, low-power control. At the same time, the second core is responsible for virtual device driving tasks, such as the second core driving virtual serial port devices and virtual network card devices. The virtual serial port device is used to forward the serial port data of the second core to the first core for use; the virtual network card device is used by the second core to mount the file system of the first core via NFS. Therefore, the first and second cores can transmit data through the established RPMSG communication channel and the virtual device created by the second core.

[0005] This leads to the following problems: When the second core needs to be restarted due to fault recovery or firmware upgrade, it will uninstall the established RPMSG communication channel, then uninstall the driver files of the first core, and thus uninstall the virtual device. In addition, the second core will go through the initialization process again and recreate the virtual device.

[0006] However, if before the second core is restarted, the application of the first core has opened the RPMSG communication channel bound to the virtual device in the virtual device node corresponding to the first core and obtained the file descriptor corresponding to the virtual device node, then after the second core is restarted, the recreated virtual device and virtual device node are different from the virtual device and virtual device node before the restart. If the application performs data transmission according to the file descriptor obtained before the restart, logical errors or memory leaks will occur.

[0007] In the prior art, in order to solve the above problems, the following means are usually adopted: (1) Adding other cores to implement active-standby switching increases hardware costs and is not suitable for embedded scenarios.

[0008] (2) Migrating the driver to the first core sacrifices real-time performance and violates the original intention of the second core design.

[0009] (3) Detecting the survival status of the M core through heartbeat packets cannot prevent transient failures. Summary of the Invention

[0010] The purpose of the present invention is to solve the above problems existing in the prior art and to provide an aerial transport vehicle controller.

[0011] The purpose of the present invention is achieved through the following technical solutions: An aerial transport vehicle controller includes a first core and a second core that implement inter-core communication via the RPMSG communication protocol, wherein the first core is provided with a hot-swap module; The hot swap module is configured to determine whether the second core is restarting or needs to be restarted after the application opens a virtual device node, and when it is determined that the second core is restarting or needs to be restarted, update a file descriptor that is mapped to the virtual handle fed back to the application by the hot swap module to a negative value; After determining that the second core has completed restarting, the hot switch module opens a newly created virtual device node at the first core, obtains a new file descriptor corresponding to the newly created virtual device node, and updates the file descriptor mapped to the virtual handle to the new file descriptor.

[0012] Preferably, the hot switching module monitors whether there is a second core restart event and a second core start event in the uevent event through the state proxy layer. If it is determined that there is a second core restart event, it is determined that the second core is restarting; if it is determined that there is a second core start event, it is determined that the second core has completed the restart.

[0013] Preferably, it further includes an abnormality monitoring program running in the background, which monitors whether the second core is running normally after normal startup. When it is monitored that the second core is not running normally, the abnormality monitoring program restarts the second core.

[0014] Preferably, after calling the script to start the second core, the exception monitoring program monitors the uevent events in the kernel space and determines whether the second core startup event is detected within the specified time. If so, the exception monitoring program uses inotify to monitor the Message log of the Linux system and determine whether the Message log of the Linux system has changed. When it is determined that there is a change, the exception monitoring program reads the Message log content of the Linux system and determines whether it contains a dog-not-fed indicator. If so, the exception monitoring program calls the custom script to restart the second core.

[0015] Preferably, a main program runs in the first core, and the main program communicates with the abnormality monitoring program through semaphores. The abnormality monitoring program monitors whether the main program runs normally after normal startup. When it is monitored that the main program does not run normally, the abnormality monitoring program shuts down the second core.

[0016] Preferably, when the aerial transport vehicle controller is started, the abnormality monitoring program is started by systemd. After the abnormality monitoring program is started, the main program is started and monitored whether the main program is started normally. When it is determined that the main program is started normally, the watchdog is used to monitor whether the main program is running normally.

[0017] Preferably, the abnormality monitoring program determines whether the main program is started normally by monitoring the proc_events file in the kernel space to determine whether an initialization event fed back by the main program is received within a specified time.

[0018] Preferably, the abnormality monitoring program sends data packets to the hardware watchdog of the AHV controller at a certain period. If the abnormality monitoring program fails to send the data packets on time, the hardware watchdog generates a restart signal to restart the AHV controller.

[0019] Preferably, the abnormality monitoring program determines the occupancy rate and / or CPU occupancy rate and / or CPU load of each core by periodically reading the / proc / stat file and stores the information in the shared memory; And / or the abnormality monitoring program monitors the real-time performance of each core of the AHV controller and stores the monitored real-time performance data in the shared memory.

[0020] Preferably, the main program obtains data collected by the abnormality monitoring program from the shared memory and adjusts the operating speed of the AHV according to the obtained data.

[0021] The advantages of the technical solution of the present invention are mainly reflected in: The present invention realizes the decoupling of file descriptors and applications by setting a hot-swap module in the first core, and monitors whether the second core is restarting or needs to be restarted. When it is determined that the second core is restarting or needs to be restarted, the mapping relationship between the file descriptor and the virtual handle is released to avoid errors in continued data transmission. When the second core completes the restart, a new mapping relationship between the file descriptor and the virtual handle is established so that data transmission can continue. Therefore, the application of the first core can also be unaware of the restart of the second core, ensuring the high availability of the system and improving the maintainability of the program.

[0022] The present invention monitors the operation of the main program by setting up an abnormality monitoring program. When the main program is abnormal, the second core that controls the operation of the aerial transport vehicle can be immediately stopped, avoiding erroneous control caused by the normal operation of the second core due to the abnormality of the main program. This can effectively prevent the aerial transport vehicle from colliding with the track and reduce safety accidents. The exception monitoring program of the present invention also monitors the second core, can promptly detect abnormal conditions of the second core, can promptly release the mapping relationship between the file descriptor and the virtual handle, can promptly interrupt data transmission, and can restart the second core to restore the reliable operation of the second core.

[0023] The present invention also communicates with the abnormal monitoring program through the hardware watchdog, so that the entire operation control system can be restarted when the abnormal monitoring program is abnormal, thereby further ensuring the reliable operation of the entire system.

[0024] The abnormality monitoring program of the present invention can monitor the real-time performance of each core of the operation control system and the system load data such as the occupancy rate of each core in real time and share the data with the main program. The main program does not need to be distracted to monitor the system load. The main program can adjust the operation of the aerial transport vehicle and the operation of the system according to the system load and real-time data monitored by the abnormality monitoring program, so that the main program has a stronger control over the aerial transport vehicle and avoids the situation where the aerial transport vehicle cannot be controlled due to system jams. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] Figure 1 is a communication diagram of the first core and the second core of the aerial transport vehicle controller of the present invention; Figure 2 It is a schematic diagram of the communication between the main program in the first core and the second core of the aerial transport vehicle controller of the present invention and the abnormality monitoring program, and the communication between the abnormality monitoring program and the hardware electronic dog; Figure 3 It is a schematic diagram of the process of the abnormal monitoring program of the present invention performing second core monitoring; Figure 4 It is a schematic diagram of the process of the abnormal monitoring program of the present invention performing main program monitoring. DETAILED DESCRIPTION

[0026] The objects, advantages, and features of the present invention are illustrated and explained through the following non-limiting description of preferred embodiments. These embodiments are merely typical examples of the application of the technical solutions of the present invention, and any technical solutions formed by equivalent substitution or equivalent transformation fall within the scope of protection claimed by the present invention.

[0027] In the description of the scheme, it should be noted that the terms "center," "upper," "lower," "left," "right," "front," "back," "vertical," "horizontal," "inner," and "outer," etc., indicating orientations or positional relationships, are based on the orientations or positional relationships shown in the accompanying drawings and are intended solely for ease of description and simplification. They do not indicate or imply that the devices or components referred to must have a specific orientation, be constructed, or operate in a specific orientation. Therefore, they should not be construed as limitations on the present invention. Furthermore, the terms "first," "second," and "third" are used for descriptive purposes only and should not be construed as indicating or implying relative importance.

[0028] Example 1 The aerial transport vehicle controller disclosed by the present invention will be described below with reference to the accompanying drawings. Figure 1 As shown, it includes a first core and a second core that communicates with the first core via the RPMSG protocol. The first core is, for example, a master core or an A core, and the second core is, for example, a slave core or an M core. The technology for inter-core communication via the RPMSG protocol is well known and not innovative in the present invention, so it will not be described in detail here.

[0029] As attached Figure 2 As shown, the first core uses the powerful Linux system and is used to run high-performance programs such as the main program. The main program is used to communicate with the server and send control instructions to the second core to control the aerial transport vehicle to perform certain actions based on server instructions. Of course, other applications can also run in the first core.

[0030] The second core runs a real-time operating system (RTOS), ensuring exceptional real-time performance. This strong real-time performance allows it to run the EtherCAT (ECAT) master and execute control commands to enable the AHV to perform various actions. These include controlling forward and backward movement, steering, pick-and-place operations with the AHV's gripping mechanism, lifting and lowering mechanisms, and translational operations with the AHV.

[0031] When the main program needs to make the AHV perform a certain action, it sends a control instruction to the second core through the interface. The second core will execute the corresponding control instruction to make the AHV complete the corresponding action and return the execution result to the main program.

[0032] As attached Figure 1 As shown, a hot-swap module is provided in the first core, and the hot-swap module communicates with the application program (including but not limited to the main program) running in the first core.

[0033] The hot-swap module is used to determine whether the second core is restarting or needs to be restarted after the application opens a virtual device node. When it is determined that the second core is restarting or needs to be restarted, the file descriptor that is mapped to the virtual handle fed back to the application by the hot-swap module is updated to a negative value. At this time, the application of the first core will report an error, the virtual device node does not exist, and data sending will be stopped.

[0034] After determining that the second core has completed restarting, the hot swap module opens a newly created virtual device node on the first core, obtains a new file descriptor corresponding to the newly created virtual device node, and updates the file descriptor mapped to the virtual handle to the new file descriptor. At this point, the application on the first core can obtain the new file descriptor corresponding to the newly created virtual device node, allowing the application to continue sending and receiving previously unfinished data through the newly created RPMSG channel and virtual serial port.

[0035] Specifically, the hot-swap module includes a hot-swap control layer and a state proxy layer that communicate with each other; The hot-swap control layer provides a set of interfaces, including functions such as open(), close(), read(), write(), and select(). When an application calls the hot-swap control layer's open() function to open a virtual device node, the hot-swap control layer calculates a virtual handle (index) and feeds it back to the application and the state proxy layer. The state proxy layer then calls the native open interface to open the virtual device node, obtains the file descriptor corresponding to the virtual device node, and establishes a mapping relationship between the virtual handle and the file descriptor. For example, if the virtual handle is 1001 and the file descriptor is 3, the mapping relationship between the virtual handle and the file descriptor is 1001→3. Subsequently, the application can call other interfaces of the hot-swap control layer and perform various operations on the virtual device node using the aforementioned mapping relationship between the virtual handle and the file descriptor, including but not limited to close, read, write, and select.

[0036] The state proxy layer includes a state machine, which monitors whether there is a second core restart event in the uevent event. If so, that is, there is a second core restart event, it is determined that the second core is restarting. At this time, the state machine state can be updated to the virtual device node does not exist. If the virtual device node is not opened, no processing is required. If the virtual device node has been opened before the second core restarts, the file descriptor is closed and the file descriptor is set to a negative number, such as -1, so that the mapping relationship between the virtual handle and the real descriptor is updated to 1001→-1.

[0037] At the same time, the state proxy layer can determine whether the second core has completed the restart by monitoring whether there is a second core startup event in the uevent event. When it is determined that there is a second core startup event, the state machine state is updated to the existence of the virtual device node, and the preset event is automatically executed according to the current state. If no virtual device node is opened before the second core is restarted, nothing is done. If a virtual device node has been opened before the second core is restarted, the native open interface is re-called to open a new virtual device node, and the new file descriptor corresponding to the new virtual device node is obtained, for example, 4, so that the mapping relationship between the virtual handle and the real descriptor is updated to 1001→4.

[0038] The subsequent application program can call various interfaces of the hot-swap control layer and perform various operations on the newly created virtual device node through the mapping relationship between the updated virtual handle and the new file descriptor corresponding to the newly created virtual device node.

[0039] The aerial transport vehicle controller also includes an exception monitoring program, which runs in the system background of the first core. The exception monitoring program introduces JSON as a configuration file to improve the configurability of the exception monitoring program. Some functions can be turned on and off in the configuration file, and the parameters of the exception monitoring program can be modified.

[0040] As attached Figure 3 As shown, the abnormality monitoring program communicates with the second core using the RPMSG protocol under the OpenAMP architecture. The abnormality monitoring program monitors whether the second core is running normally after normal startup, and restarts the second core when it is determined that the second core is not running normally.

[0041] Specifically, after the main program or exception monitoring program calls a script to start the second core, the exception monitoring program monitors kernel space for uevent events and determines whether a second core startup event is detected within a specified time period. If not, the second core startup is determined to have failed, a record is made in a log file, and the program exits. If so, the second core startup is determined to have been successful. At this point, the exception monitoring program uses inotify to monitor the Linux system's message log and determine whether there are any changes in the Linux system's message log. inotify is a subsystem (API) added to Linux kernel version 2.6.13 (June 18, 2005). It provides a mechanism for monitoring file system events, including file modifications, additions, and deletions, and notifies applications of corresponding events.

[0042] When it is determined that the Linux system's Message log has changed, the Linux system's Message log content is read to determine whether it contains a "not fed" indicator. The "not fed" indicator is generated by the Linux driver file used by the exception monitoring program in the Linux kernel using the sysfs system. If so, that is, if the "not fed" indicator exists in the Linux system's Message log, it is determined that the second core is not operating normally, and a custom script is called to restart the second core. Otherwise, the Linux system's Message log is continuously monitored to determine whether it has changed.

[0043] This method effectively solves the problem of the second core being affected by the multi-core heterogeneous hardware architecture, resulting in the inability to have its own hardware watchdog and independently monitor the second core. In addition, the use of inotify monitoring ensures that the CPU is busy doing what it should do most of the time, and only checks when the Linux system's message log changes. This achieves monitoring effects without occupying resources.

[0044] Furthermore, during the operation of the AHV, if the main program experiences an exception, the operation of the secondary core remains unaffected. However, if the main program experiences an exception after issuing a high-speed control command to the secondary core, the secondary core will continue to control the AHV at high speed according to the command. This could result in the AHV colliding with the track, causing economic losses. For example, if the main program issues a 4.5m / s control command to the secondary core, and the main program experiences an exception, the secondary core will continue to control the AHV at 4.5m / s. When the AHV reaches a curve, it could collide with the track, damaging both the track and the AHV.

[0045] Therefore, the abnormality monitoring program also communicates with the main program and monitors whether the main program runs normally after being normally started. When it is monitored that the main program does not run normally, the second core is shut down.

[0046] As attached Figure 2 As shown, the exception monitoring program and the main program use semaphores to achieve inter-process communication, and when the semaphore used for communication between the main program and the exception monitoring program is not incremented by 1 within a specified time, the exception monitoring program directly uses the Remoteproc framework to shut down the second core. When the second core is shut down, the ECAT master station deployed on the second core will stop running. At this time, the servo system on the aerial transport vehicle will automatically stop because it cannot receive periodic control data, thereby stopping various actions of the aerial transport vehicle.

[0047] As attached Figure 4 As shown, when the aerial transport vehicle controller is powered on, the exception monitoring program is started by systemd. After the exception monitoring program is started, the main program is started and the main program is monitored to see whether it is started normally. Specifically, the exception monitoring program determines whether the initialization event feedback from the main program is received within the specified time by monitoring the proc_events file in the kernel space, and then determines whether the main program is started normally. When it is determined that the initialization event is received, the exception monitoring program determines that the main program is started normally; when it is determined that the initialization event is not received, the exception monitoring program determines that the main program has failed to start, and at this time calls the error script to inform the outside world that the main program has failed to start.

[0048] The reason for this operation is that the exception monitoring program is used to assist the main program and monitor it. First, the exception monitoring program is started and then the main program is started by the exception monitoring program, and whether the startup of the main program is successful is monitored. In this way, a closed loop can be achieved to ensure that the entire running process of the main program is monitored by the exception monitoring program.

[0049] When the abnormal monitoring program determines that the main program has started normally, the watchdog monitors whether the main program is running normally. The watchdog can determine whether the main program is running normally according to whether the main program feeds the dog according to the specified requirements. The corresponding technology is a known technology and will not be described in detail here. When the abnormal monitoring program determines that the main program is not running normally, the abnormal monitoring program can call a custom script to shut down the second core, and can restart the main program at the same time. The method of shutting down the second core is the same as above and will not be described in detail here. And when it is determined that the main program has started normally, the second core can be restarted.

[0050] At the same time, the abnormality monitoring program also communicates with the hardware watchdog of the aerial transport vehicle controller. The abnormality monitoring program sends data packets to the hardware watchdog at a certain period. If the abnormality monitoring program fails to send data packets on time, it may be that there is a serious problem with the operation control system, such as system freeze, which causes the abnormality monitoring program to fail to operate normally or there may be an abnormality in the abnormality monitoring program. At this time, the hardware watchdog generates a restart signal to restart the aerial transport vehicle controller.

[0051] Furthermore, the abnormal monitoring program determines the occupancy rate and / or CPU occupancy rate and / or CPU load of each core by periodically reading the / proc / stat file and stores the information in the shared memory. Monitoring the above parameters is to monitor the current system load of the operation control system.

[0052] The exception monitoring program also monitors the real-time performance of each core in the AHV controller and stores the monitored real-time performance data in shared memory. The real-time performance of a core is the actual wakeup time after the core has been dormant for a specified period of time. This can be achieved by creating a thread and binding it to different cores. The corresponding technology is well known and will not be described in detail here.

[0053] The reason for monitoring the real-time performance of each core is that if the real-time performance of each core is poor, the faster the speed, the greater the position offset after the command is issued. For example, if the real-time performance is excellent, at 1µs, the position offset is basically negligible when controlling an AMT at a speed of 5m / s. However, when the real-time performance of the core drops to 100µs, the position offset becomes significant. Furthermore, when controlling the AMT, multiple task switches occur during the process, and each task switch adds an additional 100µs. This cumulative offset increases, seriously affecting the AMT's positioning accuracy.

[0054] Therefore, the real-time data and occupancy rate data stored in the shared memory by the abnormality monitoring program will be synchronized to the main program, and the main program can perform various dynamic adjustments based on the real-time data and occupancy rate data.

[0055] For example, after the main program obtains the real-time data of each core from the shared memory, it can adjust the operating speed of the AHV according to the real-time data, thereby achieving safer, smarter, and more controllable control of the AHV.

[0056] For example, after the main program senses the system load of the operation control system, it can understand the current operation status of the operation control system, and can perform early warning, control logic adjustment, and operation control adjustment of the aerial transport vehicle based on the current system load.

[0057] For example, if a high number of I / O operations is a factor affecting system load, the control logic can be adjusted. For example, when an I / O operation is required, the system load is checked first. If the load is high, the I / O operation is skipped and other operations are performed, waiting until the system load drops to a normal or lower level before the I / O operation is performed again. For another example, if the CPU utilization reaches 99%, this indicates an internal abnormality within the control system. The main program needs to detect this and communicate it to the outside world through various means, such as flashing a red LED, displaying a high system load on the screen, and sounding an error alarm from the speaker, providing an early warning and enabling action to be taken. Furthermore, when the handling system is highly loaded, the overhead transport vehicle cannot be controlled to move at high speeds. For example, when the CPU utilization reaches 80%, the main program cannot control the overhead transport vehicle to move faster than 3 m / s.

[0058] Moreover, in other embodiments, the status proxy layer can also monitor whether the main program and / or the second core are running normally, just like the exception monitoring program. When it is determined that the main program and / or the second core are running abnormally, it is determined that the second core needs to be restarted. Of course, this is not necessary.

[0059] There are many implementation methods of the present invention, and all technical solutions formed by equivalent transformation or equivalent transformation fall within the protection scope of the present invention.

Claims

1. An aerial transport vehicle controller, comprising a first core and a second core that implement inter-core communication via the RPMSG communication protocol, characterized in that: A hot-swap module is provided in the first core; The hot swap module is configured to determine whether the second core is restarting or needs to be restarted after the application opens a virtual device node, and when it is determined that the second core is restarting or needs to be restarted, update a file descriptor that is mapped to the virtual handle fed back to the application by the hot swap module to a negative value; After determining that the second core has completed restarting, the hot switch module opens a newly created virtual device node at the first core, obtains a new file descriptor corresponding to the newly created virtual device node, and updates the file descriptor mapped to the virtual handle to the new file descriptor.

2. The AHV controller according to claim 1, wherein: The hot switch module monitors whether there is a second core restart event and a second core start event in the uevent event through the state proxy layer, and if it is determined that there is a second core restart event, it is determined that the second core is restarting; If it is determined that the second core startup event exists, it is determined that the second core completes restarting.

3. The AHV controller according to claim 1, wherein: The system further includes an abnormality monitoring program running in the background, wherein the abnormality monitoring program monitors whether the second core is running normally after normal startup. When it is monitored that the second core is not running normally, the abnormality monitoring program restarts the second core.

4. The AHV controller according to claim 3, wherein: After calling the script to start the second core, the exception monitoring program monitors the uevent events in the kernel space and determines whether the second core startup event is detected within the specified time. If so, the exception monitoring program uses inotify to monitor the Message log of the Linux system and determine whether the Message log of the Linux system has changed. When it is determined that there is a change, the exception monitoring program reads the Message log content of the Linux system and determines whether it contains a dog-not-fed indicator. If so, the exception monitoring program calls the custom script to restart the second core.

5. The AHV controller according to claim 1, wherein: A main program runs in the first core, and the main program communicates with an abnormality monitoring program through semaphores. The abnormality monitoring program monitors whether the main program runs normally after normal startup. When it is monitored that the main program does not run normally, the abnormality monitoring program shuts down the second core.

6. The AHV controller according to claim 5, characterized in that: When the aerial transport vehicle controller is started, the abnormality monitoring program is started by systemd. After the abnormality monitoring program is started, the main program is started and monitors whether the main program is started normally. When it is determined that the main program is started normally, the watchdog is used to monitor whether the main program is running normally.

7. The AHV controller according to claim 6, wherein: The abnormal monitoring program determines whether the main program is started normally by monitoring the proc_events file in the kernel space to determine whether an initialization event fed back by the main program is received within a specified time.

8. The AHV controller according to claim 3, wherein: The abnormality monitoring program sends data packets to the hardware watchdog of the AHV controller at a certain period. If the abnormality monitoring program fails to send the data packets on time, the hardware watchdog generates a restart signal to restart the AHV controller.

9. The AHV controller according to any one of claims 3 to 8, characterized in that: The abnormality monitoring program determines the occupancy rate and / or CPU occupancy rate and / or CPU load of each core by periodically reading the / proc / stat file and stores the information in the shared memory; And / or the abnormality monitoring program monitors the real-time performance of each core of the AHV controller and stores the monitored real-time performance data in the shared memory.

10. The AHV controller according to claim 9, wherein: The main program obtains data collected by the abnormality monitoring program from the shared memory and adjusts the operating speed of the aerial transport vehicle according to the obtained data.

Images