JP2005061038A - Mechanical parking lot control system, method, equipment and program - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To make it possible to efficiently and stably carry out the task of permitting a plurality of vehicle to enter and leave a parking lot. <P>SOLUTION: A mechanical parking lot control system executing operation control of a conveyance apparatus having at least an entry/leave gate, a lift device conveying vehicles between stories and parking chambers for parking the vehicle in a specified position on the entry/leave of the vehicles in a multistory parking lot having one or more parking chambers at every story comprises an entry/leave control means for executing control by accumulating execution reservation information for entry/leave requests corresponding to entry/leave request of the vehicles for entering/leaving the parking lot, a path generation means for generating a candidate path in the conveying device for every entry/leave request accumulated in the execution reservation information, a concurrence check means for checking whether the motion of the conveying device based on a path obtained by the path generating means interferes with the motion of the conveying device based on other entry/leave requests, and an execution control means for controlling the execution status based on the entry/leave request. <P>COPYRIGHT: (C)2005,JPO&NCIPI

Description

  The present invention relates to a mechanical parking lot control system, a mechanical parking lot control method, a mechanical parking lot control device, and a mechanical parking lot control program, and in particular, efficiently and stably executes a plurality of loading / unloading tasks. The present invention relates to a mechanical parking lot control system, a mechanical parking lot control method, a mechanical parking lot control device, and a mechanical parking lot control program.

  In recent years, there is a high demand for large-scale parking lots in large urban areas, and three-dimensional mechanical parking lots for the purpose of space saving and labor saving are used from the viewpoint of accommodation efficiency. In general, such a mechanical parking lot has a loading / unloading unit for loading and unloading a vehicle, a parking room having a plurality of vehicle shelves (parking positions) for parking the vehicle, and a vehicle between the loading / unloading unit and each vehicle shelf. A transport mechanism for transporting is provided. Normally, a plurality of parking rooms are provided in a three-dimensionally stacked state.

  Furthermore, this type of mechanical parking lot is provided with a lift for transporting the vehicle between the loading / unloading section and each parking room. And the vehicle received in the loading / unloading part is conveyed by a lift to a parking room, and is conveyed by being conveyed to the vehicle shelf in which the vehicle in the said parking room is not stored. Moreover, after the vehicle stored in the car shelf is transported to the lift, it is mounted on the lift and transported to the loading / unloading section.

  Here, the structure of the conventional mechanical parking lot is demonstrated using figures. FIG. 1 is a diagram illustrating a configuration example of a conventional mechanical parking lot. The mechanical parking lot 10 in FIG. 1 is a straight run that runs in a straight line on a lane shape with a warehousing berth 12 and a berthing berth 13 on the ground floor 11, a warehousing lift 14, a warehousing lift 15, a parking room 16. And a carriage 17. In FIG. 1, a parking space is provided in the basement. Moreover, since the parking space of a mechanical parking lot changes with places, space, etc. installed, it is good also as a structure which does not have a linear traveling trolley, for example, as a structure which has 1 or 3 or more berths and lifts in equipment. Also good.

A plurality of parking rooms 16 exist in the same hierarchy. In the parking room 16 shown in FIG. 1, car shelves are divided into a matrix and managed, and pallets 18 that are each identified by a unique ID or the like are arranged for each car shelf. In FIG. 1, the vehicle is loaded and unloaded by placing the vehicle on the pallet 18 and transporting it between the berth and the parking room. In addition, about the conveyance technique of the conveying apparatus which uses a pallet, it is already disclosed (for example, refer patent document 1).
As for the method of moving the arranged pallets, the so-called puzzle method is used in which the pallets on the front, rear, left and right are sequentially driven according to the empty space to move the vehicle to a predetermined position such as a straight traveling carriage. (For example, refer to Patent Document 2).

  Furthermore, in order to reduce waiting time at the loading / unloading berth and enable quick loading / unloading operations (loading / unloading tasks), the in-vehicle pallet and empty vehicle pallet are moved at the same time during loading / unloading, and efficient loading / unloading Operation is realized.

  Next, an example of the entry / exit route of the mechanical parking lot will be described with reference to the drawings. FIG. 2 is a diagram illustrating an example of a path between each component facility in the warehouse. Here, Fig.2 (a) has shown the basic path | route between each installation. Moreover, FIG.2 (b) and FIG.2 (c) have shown the path | route of the in-vehicle pallet and the empty vehicle pallet at the time of warehousing or delivery.

  As shown in FIG. 2 (a), the basic route consists of a berth for entry and exit, a lift, a straight traveling carriage, and a parking room. At the time of warehousing, a vehicle placed on the carriage is moved from a plurality of parking rooms. There is an operation of moving the carriage to the vicinity of a predetermined parking room (connection space).

  In the mechanical parking lot shown in FIG. 2, the incoming and outgoing berths and lifts always hold empty pallets in the non-operating state. In addition, the lift has a two-stage structure that can hold the in-vehicle pallet in the upper stage and the empty pallet in the lower stage. For this reason, in each transfer in a lift and a loading / unloading berth, a lift and a trolley, and a trolley and a connection space, the lift always adopts a method of exchanging an empty pallet and an in-vehicle pallet.

  First, the warehousing route will be described. As shown in FIG. 2 (b), in the warehousing route, the lift moves to the position of the berth berth, takes the pallet on the berth berth into the upper stage, aligns it again, and lowers the empty pallet on the lower stage. To the berth. As a result, preparation for the next warehousing of the warehousing berth is performed at the same time that the in-vehicle pallet is received. After that, the lift moves to a hierarchical position where the parking area is located.

  Here, at the same time as the above-described operation, an empty vehicle pallet is prepared in the connection space to be used in the warehousing destination parking room. At this time, if there is no empty car pallet on the connection space, the empty car pallet in the parking room is moved to the connection space by a puzzle operation. Thereafter, the carriage transports the empty pallet prepared on the connection space to the lift position.

  When both the lift and the trolley arrive at a predetermined position, the lift takes the empty pallet on the trolley into the lower stage, aligns it again, and pays out the upper pallet on the trolley. At this time, the lift becomes inoperative with the empty pallet held in the lower stage. The empty car pallet route is also completed at this point.

  Thereafter, the carriage transports the on-board pallet to the connection space position and pays out the on-board pallet to the connection space. At this point, the on-vehicle pallet route is completed. Note that the connection space forms part of the parking room, and when the parking room performs a puzzle operation by entering and leaving, the pallet of the connection space is moved to an appropriate parking position.

  Next, the case at the time of delivery will be described. As shown in FIG.2 (c), in a delivery route, a vehicle pallet is prepared to the connection space which is going to be used in the parking room to be delivered. At this time, if there is no pallet on the connection space, the pallet in the parking room is moved to the connection space by a puzzle operation. Thereafter, the carriage transports the on-vehicle pallet prepared on the connection space to the lift position. Further, the lift moves to a hierarchical position where there is a parking room to be delivered.

  When both the lift and the trolley arrive at a predetermined position, the lift takes the pallet on the trolley into the upper stage, aligns it again, and pays out the lower empty pallet to the trolley.

  Thereafter, the lift moves to the outgoing berth position, takes in the empty pallet in the outgoing berth to the lower stage, aligns again, and pays out the upper in-vehicle pallet to the outgoing berth. At this point, the lift becomes inoperative with the empty pallet held in the lower stage. The on-vehicle pallet route is also completed at this point.

  Further, simultaneously with the above-described operation (from moving to the unloading berth position until the vehicle becomes non-operating), the carriage transports the empty pallet to the connection space position and delivers the empty pallet to the connection space. At this point, the empty pallet route is complete.

  In addition, conventionally, it is common to provide a control device that controls the operation procedure of each transfer device in the storage route and the exit route of the mechanical parking lot described above.

  By the way, conventionally, when a plurality of loading / unloading tasks occur at the same time, a task conflict occurs between the carriage and the lift. For example, in a cart, there is a possibility that tasks having different transport directions such as entering and leaving compete. Also, if there is a cancellation instruction in the middle of leaving the lift, there is a possibility that tasks with different transport directions will compete.

  Once a conflict occurs, a state in which the competing tasks wait forever until the end of each other's tasks (deadlock) occurs, causing the entire parking lot facility to stop. In addition, even if it is not a serious situation such as deadlock, when multiple tasks with the same transport direction use the same transport device so that warehousing and unloading are continuous, the execution time of each transport device Waiting caused by the difference needs to be controlled by the control device.

As a means of avoiding the above deadlock and managing waiting, when multiple tasks occur, the task execution order and transport order are set by simulation to achieve conflict avoidance and waiting optimization. There is a technique for determining all in advance (see, for example, Patent Document 3).
JP-A 63-74804 JP-A-2-115467 JP 9-209603 A

  However, when all of the task execution order or the transport order are set in advance as shown in Patent Document 3, for example, when a warehouse entry / exit instruction that is not set in advance occurs suddenly, it is necessary to perform rescheduling. For this reason, when re-scheduling frequently occurs, a load is applied to the control device, and the standby time also becomes long, so that the equipment operation rate decreases.

  Furthermore, in machine equipment, the probability of machine failure cannot be zero. In the event of a failure, the operation is continued using the remaining transfer facility, or after the failed transfer device is restored, the suspended entry / exit task is resumed. At this time, if rescheduling is performed as described above, all tasks including facilities that have not failed are stopped, so the operating rate cannot be improved. Further, since it is necessary to perform automatic operation after moving the pallet on the failed transfer device to a predetermined location by manual operation at the time of recovery, personnel and time are required.

  The present invention has been made in view of the above points, and is a mechanical parking lot control system, a mechanical parking lot control method, and a mechanical parking lot that can efficiently and stably execute a plurality of loading / unloading tasks. It is an object to provide a control device and a mechanical parking lot control program.

  In order to solve the above problems, the present invention employs means for solving the problems having the following characteristics.

  The invention described in claim 1 conveys the vehicle between an entry / exit port and the tier with respect to the entry / exit of the vehicle in a three-dimensional parking lot having one or more parking rooms for each one or more tiers. In a mechanical parking lot control system for controlling the operation of a transfer device having at least a lift device and a parking room for parking the vehicle at a predetermined parking position, in response to a loading / unloading request for loading / unloading the vehicle Entry / exit management means for accumulating and managing execution reservation information for entry / exit, route generation means for generating route candidates in the transport device for each entry / exit request stored in the execution reservation information, and the route generation means And a conflict check means for checking whether the operation of the transfer device based on the route obtained in step 2 conflicts with the operation of the transfer device based on another loading / unloading request, and manages the execution status based on the loading / unloading request. And having a execution management unit.

  According to invention of Claim 1, operation | movement of the conveying apparatus with respect to a storage request can be performed efficiently and stably. For example, when multiple loading / unloading requests are executed at the same time, before each transfer operation to be executed by each request, a conflict check is performed based on the path of each loading / unloading request and the execution status of the transfer device. Can be avoided, and the vehicle can be transported quickly. Further, even when a plurality of tasks are added or deleted at an arbitrary timing, a route can be generated quickly.

  According to a second aspect of the present invention, the route generation unit has a route candidate table in which all the route candidates that can be used in advance are accumulated, and the contention check unit determines a route conflict based on the route candidate table. It has a route determination means for making a check request and determining a transportation route of the vehicle between the entrance / exit and the parking room based on a competition check result.

  According to the second aspect of the present invention, by determining the route based on the result of the conflict check, it is possible to generate a route that does not compete with the operation of the transport device in another request. Thereby, operation | movement of the conveying apparatus with respect to a several receipt / exit request | requirement can be performed efficiently and stably.

  The invention described in claim 3 is characterized in that the contention check means includes route information for each entry / exit request determined by the route determination means, and execution status information of the transfer device. Execution determination is performed based on execution status information.

  According to the third aspect of the present invention, highly accurate execution determination can be performed based on all the loading / unloading requests. Accordingly, it is possible to efficiently and stably perform the operation of the transport device with respect to the loading / unloading request while avoiding the conflict.

  According to a fourth aspect of the present invention, the execution management means includes in-going loading / unloading request information, path information for each loading / unloading request, and loading / unloading request information for each transport device, Alternatively, when executing the warehousing operation, if at least one of the transfer devices has an abnormality, a transfer execution means for detecting the warehousing request using the transfer device and transferring the detected warehousing request to another route and executing it. It is characterized by having.

  According to the fourth aspect of the present invention, even when there is an abnormality in the transport device, the transport of the vehicle in a plurality of storage / reception requests can be performed efficiently and stably without stopping the operation of the transport device in response to another storage request. Can be realized.

  According to a fifth aspect of the present invention, when there is no route that can be used for an outgoing request, the incoming / outgoing management means stores the outgoing request stored in the execution reservation information as recovery information. It is characterized by.

  According to the invention described in claim 5, the system administrator can easily grasp a request that cannot be issued without a route by referring to the recovery information.

  The invention described in claim 6 is characterized by comprising re-execution means for re-execution of the exit request stored as the recovery information.

  According to the sixth aspect of the present invention, it is possible to easily and efficiently execute a request desired from the recovery information for a request that cannot be issued without a route.

  The invention described in claim 7 is characterized by comprising display means for displaying at least the layout of the three-dimensional parking lot, the execution status in the loading / unloading request, and the execution reservation information and recovery information.

  According to the invention described in claim 7, the system administrator can easily grasp the configuration, execution status, etc. of the mechanical parking lot control system. Thereby, operation | movement of the conveying apparatus with respect to a storage / exit request | requirement can be performed efficiently and stably.

  The invention described in claim 8 conveys the vehicle between an entry / exit port and the tier with respect to the entry / exit of the vehicle in a three-dimensional parking lot having one or more parking rooms for each one or more tiers. In a mechanical parking control method for controlling the operation of a transfer device having at least a lift device and a parking room for parking the vehicle at a predetermined parking position, in response to a loading / unloading request for loading or unloading the vehicle The storage management stage for storing and managing execution reservation information for storage and storage, a path generation stage for generating path candidates in the transport device for each storage request stored in the execution reservation information, and the path generation stage The contention check stage for checking whether the operation of the transfer device based on the route obtained in step 2 conflicts with the operation of the transfer device based on another entry / exit request, and the execution status management based on the entry / exit request. And having a management stage.

  According to invention of Claim 8, operation | movement of the conveying apparatus with respect to a loading / unloading request | requirement can be performed efficiently and stably. For example, when multiple loading / unloading requests are executed at the same time, before each transfer operation to be executed by each request, a conflict check is performed based on the path of each loading / unloading request and the execution status of the transfer device. Can be avoided, and the vehicle can be transported quickly. Further, even when a plurality of tasks are added or deleted at an arbitrary timing, a route can be generated quickly.

  The invention described in claim 9 is based on the route candidate table in which all the route candidates that can be used in advance are accumulated, and the result of the conflict check from the conflict check stage. It is characterized by having a route determination step for determining a transportation route of the vehicle between.

  According to the ninth aspect of the present invention, by determining the route based on the conflict check result, it is possible to generate the route without competing with the operation of the transport device in other requests. Thereby, operation | movement of the conveying apparatus with respect to a several receipt / exit request | requirement can be performed efficiently and stably.

  According to a tenth aspect of the present invention, in the contention check stage, the execution determination is performed based on path information for each loading / unloading request determined in the path determination stage and execution status information of the transfer device. Features.

  According to the tenth aspect of the present invention, it is possible to make a highly accurate execution determination based on all the loading / unloading requests. Accordingly, it is possible to efficiently and stably perform the operation of the transport device with respect to the loading / unloading request while avoiding the conflict.

  In the invention described in claim 11, when there is an abnormality in at least one of the transfer devices at the time of warehousing or warehousing operation, warehousing request information for executing a warehousing request using the transfer device, and It has the transfer execution stage which detects based on the route information for every said loading / unloading request | requirement, and the loading / unloading request information for every said conveying apparatus, and transfers and detects the detected loading / unloading request to another path | route.

  According to the eleventh aspect of the present invention, even when there is an abnormality in the transport device, the transport of the vehicle in a plurality of storage requests can be efficiently and stably performed without stopping the operation of the transport device in response to another storage request. Can be realized.

  The invention described in claim 12 includes a recovery information accumulation step of accumulating the exit request stored in the execution reservation information as recovery information when there is no route available for the exit request. Features.

  According to the invention described in claim 12, the system administrator can easily grasp a request that cannot be issued without a route by referring to the recovery information.

  The invention described in claim 13 has a re-execution stage for re-execution of the shipping request stored in the recovery information storage stage.

  According to the thirteenth aspect of the present invention, it is possible to easily and efficiently execute a request desired from the recovery information for a request that cannot be issued without a route.

  The invention described in claim 14 includes a display step of displaying at least the layout of the three-dimensional parking lot, the execution status in the loading / unloading request, and the execution reservation information and recovery information.

  According to the invention described in claim 14, the system administrator can easily grasp the configuration, execution status and the like of the mechanical parking lot control system. Thereby, operation | movement of the conveying apparatus with respect to a storage / exit request | requirement can be performed efficiently and stably.

  The invention described in claim 15 conveys the vehicle between an entry / exit port and the tier with respect to the entry / exit of the vehicle in a three-dimensional parking lot having one or more parking rooms for each one or more tiers. In a mechanical parking control device that controls the operation of a transport device having at least a lift device and a parking room for parking the vehicle at a predetermined parking position, in response to a loading / unloading request for loading or unloading the vehicle Entry / exit management means for accumulating and managing execution reservation information for entry / exit, route generation means for generating route candidates in the transport device for each entry / exit request stored in the execution reservation information, and the route generation means The contention check means for checking whether the operation of the transfer device based on the route obtained in step 2 conflicts with the operation of the transfer device based on another entry / exit request, and manages the execution status based on the entry / exit request And having a line administration unit.

  According to the fifteenth aspect of the present invention, it is possible to efficiently and stably perform the operation of the transport device in response to a loading / unloading request. For example, when multiple loading / unloading requests are executed at the same time, before each transfer operation to be executed by each request, a conflict check is performed based on the path of each loading / unloading request and the execution status of the transfer device. Can be avoided, and the vehicle can be transported quickly. Further, even when a plurality of tasks are added or deleted at an arbitrary timing, a route can be generated quickly.

  According to a sixteenth aspect of the present invention, the route generation unit has a route candidate table in which all the route candidates that can be used in advance are accumulated, and the contention check unit determines a route conflict based on the route candidate table. It has a route determination means for making a check request and determining a transportation route of the vehicle between the entrance / exit and the parking room based on a competition check result.

  According to the sixteenth aspect of the present invention, by determining the route based on the result of the conflict check, it is possible to generate the route without competing with the operation of the transport device in other requests. Thereby, operation | movement of the conveying apparatus with respect to a several receipt / exit request | requirement can be performed efficiently and stably.

  The invention described in claim 17 is characterized in that the contention check means includes route information for each entry / exit request determined by the route determination means, and execution status information of the transfer device. Execution determination is performed based on execution status information.

  According to the seventeenth aspect of the present invention, it is possible to make a highly accurate execution determination based on all the loading / unloading requests. Accordingly, it is possible to efficiently and stably perform the operation of the transport device with respect to the loading / unloading request while avoiding the conflict.

  The invention described in claim 18 is characterized in that the execution management means includes running loading / unloading request information, path information for each loading / unloading request, and loading / unloading request information for each of the transfer devices. Alternatively, when executing the warehousing operation, if at least one of the transfer devices has an abnormality, a transfer execution means for detecting the warehousing request using the transfer device and transferring the detected warehousing request to another route and executing it. It is characterized by having.

  According to the invention described in claim 18, even when there is an abnormality in the transport device, the transport of the vehicle in a plurality of store / receive requests can be performed efficiently and stably without stopping the operation of the transport device in response to other store / unload requests. Can be realized.

  The invention described in claim 19 is characterized in that the entry / exit management means accumulates the exit request stored in the execution reservation information as recovery information when there is no route available for the exit request. It is characterized by.

  According to the nineteenth aspect of the present invention, the system administrator can easily grasp a request that cannot be issued without a route by referring to the recovery information.

  The invention described in claim 20 is characterized by comprising re-execution means for re-execution of the exit request accumulated as the recovery information.

  According to the twentieth aspect of the present invention, it is possible to easily and efficiently execute a request desired from the recovery information for a request that cannot be issued without a route.

  The invention described in claim 21 is characterized by comprising display means for displaying at least the layout of the three-dimensional parking lot, the execution status in the loading / unloading request, and the execution reservation information and recovery information.

  According to the invention described in claim 21, the system administrator can easily grasp the configuration, execution status, etc. of the mechanical parking lot control system. Thereby, operation | movement of the conveying apparatus with respect to a storage / exit request | requirement can be performed efficiently and stably.

  The invention described in claim 22 is a mechanical parking lot control program for causing a computer to execute the mechanical parking lot control method according to any one of claims 8 to 14.

  According to the present invention, a plurality of loading / unloading tasks can be executed efficiently and stably.

<Outline of the present invention>
The present invention relates to a mechanical parking lot for efficiently and stably executing a plurality of loading / unloading tasks. In particular, when a plurality of entry / exit tasks are executed at the same time, a conflict check is performed based on the execution status of the equipment in the mechanical parking lot immediately before the transfer operation to be executed by each task, thereby avoiding the conflict. Thereby, a plurality of tasks can be added and deleted at an arbitrary timing. In addition, the device failure is not affected on the entire loading / unloading task by judging whether each task autonomously interferes with the continuation of execution.

  In the present invention, it is possible to resume the automatic operation while the pallet is placed on the failure device. When a delivery task that cannot be executed due to a device failure is detected, the task is saved in a recovery task table or the like, so that the task can be resumed from the failure location.

<Embodiment>
Hereinafter, embodiments of the present invention will be described with reference to the drawings. FIG. 3 is a diagram illustrating a configuration example of a mechanical parking lot control system according to the present invention. The mechanical parking lot control system 30 shown in FIG. 3 has an integrated control device 31, an entry / exit operation device 32, a transport device control device 33, an operation mode / failure management device 34, and a system operation screen 35. It is configured.

  The integrated control device 31 manages input information, instruction information, execution information, and the like on the entry / exit operation device 32, the transport device control device 33, the operation mode / failure management device 34, and the system operation screen 35. In summary, the integrated control device 31 includes information management means 41 and execution management means 42.

  The entry / exit operation device 32 includes a keyboard, a mouse, and the like, and outputs an entry / exit request to the integrated control device 31 based on operation information input from a user who uses the parking lot. The information management unit 41 registers the entry / exit request input from the entry / exit operation device 32 as a task and outputs the task to the execution management unit 42. The execution management means 42 sequentially executes a plurality of registered entry / exit tasks. Note that specific configurations of the information management unit 41 and the execution management unit 42 will be described later.

  The transport apparatus control device 33 performs operation control on the berthing 43 for entry and exit, the lift 44, the carriage 45, and the parking room 46.

  The operation mode / failure management device 34 instructs and manages the operation mode of each transport device. Specifically, in a mechanical parking lot, since there is an automatic or manual operation mode, the operation mode (manual / automatic) of each transport device is managed. Further, execution information is managed as status information in each transport device. The integrated control device 31 controls the parking lot while constantly checking the operation mode and status information. The system operation screen 35 is a display device having an input function, and displays and operates a system execution status and registered data via an interface.

<Integrated control device>
Here, the hardware configuration of the integrated control device 31 will be described using an example. FIG. 4 is a diagram illustrating a hardware configuration example of the integrated control apparatus. The integrated control device 31 shown in FIG. 4 includes a drive device 51, a storage medium 52, an auxiliary storage device 53, a memory device 54, an arithmetic processing device 55, and an interface device 56 that are connected to each other via a bus B. And is configured to have.

  The mechanical parking lot control program used by the integrated control device 31 is provided by a storage medium 52 such as a CD-ROM. The storage medium 52 in which the mechanical parking lot control program is recorded is set in the drive device 51, and the mechanical parking lot control program is installed in the auxiliary storage device 53 from the storage medium 52 via the drive device 51.

  The auxiliary storage device 53 stores the installed mechanical parking lot control program and also stores necessary files and data. The memory device 54 reads the program from the auxiliary storage device 53 and stores it when there is an activation instruction of the mechanical parking lot control program, such as when the integrated control device 31 is activated. The arithmetic processing unit 55 executes a function related to the mechanical parking lot control system 30 according to the parking lot control program stored in the memory device 54.

  The interface device 56 connects the entry / exit operation device 32, the system operation screen 35, and the integrated control device 31 to realize data input or output.

  Next, a specific configuration of the integrated control device 31 will be described with reference to the drawings. FIG. 5 is a diagram illustrating a specific configuration example of the integrated control device 41.

  The information management means 41 is configured to include an initial setting database 61, a loading / unloading task management device 62, a path generator 63, a task arbitrator 64, and a shelf information table 65. In addition, the execution management means 42 is configured to include an automatic driving overall management device 66 and a device operation information table 67.

  In the mechanical parking lot control system according to the present invention, the mechanical parking lot control is realized by reading the initial data in the initial setting database 61 when the system is started. Also, by changing this data, it can be easily applied to various layouts of parking lots.

<Initial setting database>
Here, an example of data stored in the initial setting database 61 will be described with reference to FIGS. FIG. 6 is a diagram showing device configuration data of a mechanical parking lot. FIG. 6A shows each hierarchical structure data, in which the hierarchical level of the target mechanical parking lot, the number of carts and the number of parking rooms for each level are defined. Moreover, FIG.6 (b) defines the apparatus ID of the parking room in each hierarchy, and FIG.6 (c) defines the apparatus ID of the connection space in each hierarchy. FIG. 6D defines the lift device ID, FIG. 6E defines the loading / unloading berth device ID, and FIG. 6F defines the bogie device ID. Specifically, the data items of the device configuration data shown in FIG. 6 include “device ID” (transport device identification number unique within the system) and “layer number” (which layer the device belongs to) for each transport device. In this embodiment, the layer number of the incoming / outgoing berth and incoming / outgoing lift is set to 0.), “operation mode” (define one of incoming / outgoing, incoming / outgoing exclusive use, outgoing output only), It consists of items such as “comment” (conveyance device name).

  Next, an example of data defining the layout of the mechanical parking lot stored in the initial setting database 61 is shown in FIG. The layout data shown in FIG. 7 is data that is defined as an identification number by giving a shelf ID with a parking position for parking a car as a shelf. Further, the layout data shown in FIG. 7 is the layout data of the parking room screen displayed on the system operation screen at the same time as the base data when the shelf information table described later is created. The data items of the layout data include “device ID” (device ID to which the shelf belongs), “X coordinate”, “Y coordinate” (shelf coordinate data), and “shelf ID” (shelf ID unique in the system). Number).

  Next, FIG. 8 shows an example of definition data relating to the connection relationship of each transport apparatus stored in the initial setting database 61. Based on this connection relation data, initial route candidates are created.

  In this data, when a pallet can be transferred between adjacent transport apparatuses, one direction is defined as one line of data. For example, in the first row of the table shown in FIG. 8, the shelf ID (9101) belonging to the warehousing berth (device ID: 101) is 9201, 9202 (belonging to the warehousing lift), and the pallet can be transferred. Is shown. Further, for example, the shelf ID (9201) belonging to the warehousing lift (device ID: 201) in the third row is 9101 (entry berth), 1501 (one-layer trolley), and 2501 (two-layer trolley), respectively. It shows that it can be posted.

  Next, FIG. 9 shows a parking layout example generated based on the data defined in FIGS. 6 to 8 described above. Here, FIG. 9A shows the parking lot layout of the layer number 1, and FIG. 9B shows the parking lot layout of the layer number 2. In FIG. 9, it has one warehousing lift, warehousing berth, warehousing lift, and warehousing berth, and is comprised of two puzzle parking rooms and one carriage for each tier. Moreover, as shown in FIG. 9, the pallet area in a parking room is positioned as shelf ID. In addition, shelf IDs associated with each layer (upper, lower, berth) of the warehousing lift and the warehousing lift are displayed on each layer. This layout screen is provided to the system operation screen 35 via the interface device 56.

  As described above, by having the initial setting database 61, the configuration of the parking lot can be easily defined. In addition, the initial setting database 61 can be easily applied to various layouts of parking lots.

<Incoming and outgoing task management device>
Next, the entry / exit task management device 62 will be described. The entry / exit task management device 62 registers the entry / exit request received from the entry / exit operation device 32 as a task. At this time, the received data is a management number (parking ticket number), a task type, and a request berth ID. A unique task ID is added in the control system and registered in the execution reservation table together with the reception time. . Other data is initialized with 0. The received entry / exit task is transmitted to the automatic operation management management device 66 in the order of reception time. At this time, the data transmitted to the automatic driving control device 66 is a management number, a task type, and a task ID.

  In addition, if any abnormality (failure, etc.) occurs during operation of the mechanical parking control system, the entry / exit task management device 62 stores the exit task that has become unexecutable when the abnormality occurs in the recovery task table. To do.

  Here, the table described above will be described with reference to the drawings. FIG. 10 is a diagram illustrating an example of a table stored in the loading / unloading task management device. 10A shows an execution reservation task table at the time of a warehousing request, FIG. 10B shows an execution reservation task table at the time of a warehousing request, and FIG. 10C shows a recovery task table. ing.

  The table shown in FIG. 10 is added, for example, as a record when the entry / exit task management device 62 receives an entry / exit request from the entry / exit operation device 32, and there are three types: entry request, exit request, and recovery. . In FIG. 10, the item “No.” is the record number generated for each table, “Registration time” is the time when the request is received from the loading / unloading operation device 32, and “Start time” is this record. The time when the information is transmitted to the automatic driving control device 66 is shown. It should be noted that a record for which no time is entered in the “start time” indicates that an execution request has not yet been issued to the automatic driving control device 66. The “management number” is a parking ticket number, and the “task ID” is a task identification number uniquely determined in the mechanical parking lot control system 30. “Task type” indicates receipt or delivery. The “berth ID” is a device ID of a berth used in the task. The “execution status” indicates the progress information of the task (whether or not the task is being executed or how far it has been completed in the route) which is transmitted from the automatic operation management management device 66 to the entry / exit task management device 62. In FIG. 10, if the task is being executed, “being executed” is accumulated.

  The recovery task table shown in FIG. 10C has “failure occurrence time”. This stores the time when the delivery operation is interrupted due to a failure or the like. These pieces of information are deleted when each task is completed.

<Path generator>
The path generator 63 generates a path that can be executed in response to an execution path query from the loading / unloading task management apparatus 62 and the automatic driving control management apparatus 66 (path generation means). The path generator 63 stores all the route candidates for the device ID of the mechanical parking lot in advance, and determines the route based on the result of the conflict check by the task arbitrator 64.

  Here, data stored in the path generator 63 will be described with reference to the drawings. FIG. 11 is a diagram illustrating an example of route candidate data stored in the path generator. Here, the route candidate table of FIG. 11 is described in ascending order of the number of movements. Further, FIG. 11 is a table in which route candidates by all the transport devices used when determining the route of entry and exit (the use permutation of the transport device from the departure to the destination) are accumulated. This table is calculated from the apparatus configuration data shown in FIG. 6 and the connection relation data shown in FIG. The procedure for creating a route candidate will be described below.

  First, since the connection relationship data as input information represents the relationship between adjacent devices that can move the pallet in one transfer, one transfer in the route candidate table is performed based on this data. Create a route that can be moved with. Next, a route that can be moved by one transfer is created by combining a route that can be moved by one transfer with each route that can be moved by one transfer.

  For example, a route “101 → 201 → 1501” (route identification ID61) that can be moved in two transfers by combining the route identification ID4 “201 → 1501” with the route “101 → 201” of the route identification ID1. Can be created. Further, a route that can be moved by three transfers is created by combining a route that can be moved by one transfer with each route that can be moved by two transfers. In this way, it is possible to create all candidate routes that are required during system operation by sequentially combining routes that can be moved.

  When an unusable device occurs due to a device failure or the like, a route candidate table reflecting the existence of the unusable device is created at that time. The calculation may be performed by ignoring the unusable device when referring to the connection relation data and creating a route that can be moved by one transfer. The path generator 63 periodically checks the apparatus operation information table 67 and monitors whether the transport apparatus is in an abnormal state. If an abnormality is found in the device, route information is recreated.

<Task arbitrator>
Next, the task arbitrator 64 will be described. The task arbitrator 64 performs a conflict check with each incoming / outgoing route and each transport device that is operating in response to the conflict check request, and determines whether or not it can be executed. Here, the contents of the data stored in the task arbitrator 64 will be described with reference to the drawings. FIG. 12 is a diagram illustrating an example of the executing table. Here, FIG. 12A shows a running path table, and FIG. 12B shows an apparatus execution status table.

  The in-execution route table of FIG. 12A is obtained by accumulating the route information inquired by the automatic operation management device 66 using the task ID as a key. In this example, two paths are accumulated. Since this parking lot is a type of parking room in which the pallet is moved, when the pallet of the actual vehicle is moved, it is necessary to return the empty pallet accordingly. For this reason, “real” and “empty” pallet routes are required for the respective requests for entry and exit. “Task ID” and “task type” are the same as those in the execution reservation task table shown in FIG. The “path type” is for identifying a path for “real” and “empty” pallets. Further, a set of “conveyance device ID” in the route, “shelf ID” used at the time of conveyance, and “state” of the conveyance device is accumulated.

  Here, the “status” indicates the progress status of the task. When the status value is “2”, it indicates the current position of the pallet to be transported. In the case of “0”, the pallet to be transported indicates an apparatus used in the past. Therefore, in the case of registering in the in-execution route table at the time of route determination, the “state” of the transport device ID1 is 2, and the “state” of the transport device ID is 1 for the subsequent transport devices.

  Also, the apparatus execution status table of FIG. 12B starts from the head apparatus of the route to be registered, and sets the two apparatuses of the pre-movement apparatus ID and the movement destination apparatus ID as a set of “FROM” and “To”. "Task ID", "Route No.", and "State" are registered for the set of. However, for the head device in the path, “FROM device ID” is set to 0, and the head device ID is set in “To device ID” and registered. That is, the “To device ID” indicates the current position. Note that the “state” in FIG. 12B is the same as the “state” of the transport device ID in the running path table (FIG. 12A). From this table, it is possible to grasp the device currently in use, the device to be used, and the transition relationship (route direction).

<Shelf information table>
Next, the shelf information table 65 will be described. The shelf information table 65 includes a management number (parking ticket) for a location (shelf) where each pallet can hold a pallet, if the pallet has an identification number, a pallet ID, and an actual vehicle on the pallet. Number) is a table that is stored together. This information is used when the path generator 63 determines a delivery route using the management number as a key. In addition, the automatic operation supervising management device 66 updates this table after the operation command to each transfer device is completed. Here, a table example of the shelf information table 66 will be described with reference to FIG. As shown in FIG. 13, in the shelf information table 66, a “management number”, a “pallet ID” for identifying a pallet, and a “shelf ID” for identifying the position of a stored parking room are accumulated for each device ID. ing. Thereby, it is possible to easily grasp each conveyance device and the shelf ID.

  Next, specific contents of the execution management unit 42 will be described.

<Autonomous driving control device>
The automatic operation supervising management device 66 sequentially executes the loading / unloading tasks instructed from the loading / unloading task management device 62. In the case of warehousing, the path generator 63 is inquired about the execution route from the berth to the parking room, and in the case of warehousing, from the parking room to the berth. When an executable route is received, an operation control instruction signal is output to the transporting device in the route, but the task arbitrator 64 is inquired whether a deadlock will occur immediately before this. Here, the data with which the automatic driving | operation integrated management apparatus 66 is provided is demonstrated using a figure.

  14-16 is a figure which shows an example of the data with which the automatic driving | operation integrated management apparatus 66 is provided. Here, FIG. 14 shows an example of an in-execution task table that stores task information received from the entry / exit task management device 62, and FIG. 15 shows a task-by-task for defining a route preset for each task. An example of a route table is shown, and FIG. 16 shows an example of a task table for each transport device.

  In FIG. 14, “start time” is the time when the task is started, and “management number”, “task ID”, and “task type” are data transmitted when the entry / exit task management device 62 makes a task request. It is. The “execution status” stores where in the path is being executed. In the “execution status” shown in FIG. 10, this information is transmitted and stored, and whether or not it is being executed is displayed. The “route direction” indicates whether the direction in which the pallet is actually moved is inbound or outbound. The “route direction” is usually the same as the “task type”, but may be operated in the opposite direction to the task type, such as when a deadlock occurs, in which case different information may be entered. “Route information” indicates whether an execution route can be executed for each task. “Destination device ID” includes the transport device ID of the parking room when entering, and the exit berth when entering. These pieces of information are deleted when the task is completed.

  In the task-by-task route table of FIG. 15, route information is stored in this table if the route is determined among the tasks being executed. These pieces of information are erased when the task is finished or a route change is required. The route information is a result of an inquiry made by the automatic driving control apparatus using the task ID as a key. Although the data contents are the same as those in the in-execution route table shown in FIG. 12, the transport device ID state is internal information of the task arbitrator 64 and is not transmitted to the automatic driving control device 66 as a route.

  In the task table for each transfer device in FIG. 16, when a route is determined, a task to be performed for each transfer device is determined. Therefore, a task to be executed for each transfer device and an execution order are stored. The “execution step” stores the step because the operation by the task may be divided into a plurality of steps for each transport device. For example, the movement of the cart at the time of unloading may be as follows: “Running toward the parking room” → “Transfer to / from the parking room” → “Run to the lift” → “Transfer to / from the lift” It becomes a set of single actions. Such a set of single operations is a pattern determined for each transport device. The automatic operation supervising management device 66 determines a single operation command to be output to the transport device next by the execution step indicating this pattern, route type, and how far the single operation has progressed. Further, the “route type” is the same as that in the task-specific route table. “Own shelf ID”, “front shelf ID”, and “rear shelf ID” store specific shelf IDs used before and after the transport device. Specific processing contents of the automatic driving control device 66 will be described later.

<Device operation information table>
Next, the apparatus operation information table 67 will be described with reference to the drawings. FIG. 17 is a diagram illustrating an example of the apparatus operation information table. The apparatus operation information table in FIG. 17 is a table in which operation information for each transport apparatus ID is accumulated. The device operation information is collected and set by the operation mode / failure management device 34. The data items are “operation mode” (automatic, manual), “device status” (normal, abnormal), “execution task ID”, “shelf ID”, “shelf status” (normal, abnormal) It is comprised so that it may have.

  The apparatus operation information table 67 is used when the task abitator 64 makes a reservation for use of the transfer apparatus, and after the use of the transfer apparatus, the automatic operation management management apparatus 66 releases the use reservation.

  A plurality of loading / unloading tasks can be executed efficiently and stably by the above-described apparatus configuration.

<Control system operation details>
Next, the operation content of the parking lot control system based on the above-described device configuration and data content will be described.

  FIG. 18 is an example chart showing a control procedure for realizing the parking lot control system according to the present invention. In addition, in FIG. 18, it has the entering / exiting task management apparatus 62, the automatic driving | operation supervision management apparatus 66, the path generator 63, and the task arbitrator 64. FIG.

  First, the loading / unloading task management device 62 receives a task request from the loading / unloading operation device 32, and when a loading / unloading task occurs, the loading / unloading task management device 62 changes to FIG. 10 (a) or FIG. The entry / exit task is registered in the table shown (S01). At this time, the request information received by the loading / unloading task management device 62 is a management number (parking ticket number), a task type, and a requested berth ID. The entry / exit task management device 62 adds a unique task ID to the received request information and registers it in the execution reservation task table together with the reception time. Other data is initialized with 0. The loading / unloading task management device outputs the received loading / unloading tasks to the automatic operation management management device 66 in the order of reception time.

  The automatic driving control device 66 registers the received entry / exit task information in the running task table (S02). At this time, the table registration time is registered as the start time, and the same task type is registered in the route direction. Other data is initialized with 0.

  The automatic driving control device 66 inquires the path generator 63 about the route to the parking room that can be entered in the case of entry, and the route to the exit berth in the case of exit (S03). Information used for the inquiry is task ID, task type, and route direction information.

  The path generator 63 selects a route candidate in response to an inquiry (route request) from the automatic driving control device 66 (S04). Specifically, the path generator 63 stores all the available route candidates in advance in the route candidate table shown in FIG. 11, and selects an available route from these. The path generator 63 periodically checks the device operation information table 67 (FIG. 17), and if there is a device whose device status is abnormal, it recreates the entire route and deletes the unusable route.

  Next, the reachability of available routes is checked, and unreachable routes are excluded (S05). Here, the term “unreachable” refers to a case where there is a transport device in the path that is disconnected from automatic operation due to machine failure or maintenance. In S05, even if a device malfunctions while periodically checking the device operation information, the device operation information table 67 is referenced to check whether there is a device with an abnormal device status in the path. . If such a route exists, the entire route is recreated.

  Next, a competitive path check is performed (S06). The conflict possibility route check is performed in order to avoid conflict with the route used by the currently executing task as much as possible. The scheduled route used by the executing task and its execution status are stored in the executing route table and the device execution status table by the task arbitrator 64, and the path generator 63 makes a check request to the task arbitrator 64. Note that when a plurality of routes are selected in S05, a route with the least possibility of competition is finally selected.

  The task arbitrator 64 confirms the scheduled route of the other task (S07), further confirms the current execution status of the transport device using the device execution status table, searches for a route with no opposing task as much as possible, and generates the path generator 63. (S08).

  When the path is determined, the path generator 63 outputs instruction information to the task abitator 64 to perform path registration and initialization of the execution status. After the task abitator 64 finishes the process, the path generator 63 automatically determines the determined path. 66. The task arbitrator 64 performs route registration based on the instruction information (S10), and initializes the execution status / occupied device (S11). Specifically, the task route information and progress status (state) are registered in the in-execution route table and the device execution status table shown in FIG. Of the contents registered in the running route table, the route information is an answer to the route request itself. Further, the transfer device ID state indicates the progress of the task, and the “state” of the table described in FIG. 12 is updated. From this table, the device currently in use, the device to be used, and the transition relationship (route direction) are grasped.

  The automatic driving control device 66 determines the determined route result from the path generator 63 (S12). If the determined route result is that another task that uses the same route or the transfer device is currently being executed and is waiting to be executed (Wait in S12), the steps after S03 are performed again, and the route request is made again. Thereby, it is possible to change the route and realize quick vehicle entry / exit. In addition, even when an abnormality such as a conveyance device failure occurs, stable entry / exit processing can be realized by changing the route. If there is no available route in the determined route result (NG in S12), an NG process is performed (S13). Specific contents of the NG process will be described later.

  Further, when the determined route result can be executed immediately (OK in S12), the result route information is output together with the determined route result from the path generator 63, so that the automatic driving control device 66 receives the received route information. Are stored in the task-by-task route table shown in FIG. 15, tasks to be executed are assigned to the respective transport devices in the route, and stored in the transport device-specific task table shown in FIG. Further, command expansion for task execution to the intra-path transfer device is performed (S14).

  Next, the automatic operation supervising management device 66 sequentially extracts the transfer commands from the tasks stored in the transfer device task table for each transfer device, and executes the transfer commands until there are no more commands to be taken out. Note that the path is checked with respect to the path generator 63 before the transfer command is executed, and further the command execution possibility is checked with respect to the task task arbitrator 64. In the following, a specific description will be given of processing for sequentially performing from the take-out of the transfer command to the execution of the transfer command until the end of the command.

  First, a carrying command is taken out (S15), and it is determined whether there is an unexecuted command (S16). If there is no command that has not been executed (No in S16), it is determined that the execution of the corresponding task has been completed for all of the transfer devices, and the entry / exit task management device 62 is notified that the task has been completed normally, Corresponding task information in the task-specific route table and the transfer device-specific task table is deleted (S17).

  If there is a command that has not been executed in S16 (Yes in S16), the path is checked using the path generator 63 (S18). In this confirmation, the task ID, route type, own transport device ID, and next transport device ID are transmitted to the path generator 63. A specific transfer command is determined by the automatic driving control device 66 according to the execution step of the task assigned to each transfer device.

  The path generator 63 performs a reachability check based on the current execution status in other tasks, and outputs the check result (S19). Here, the same processing as S05 is performed. Based on the check result of the path generator 63, the automatic driving control device 66 determines whether the set route is OK (S20). If the route is not OK due to the influence of a failure or the like (No in S20), an NG process is performed (S21). This NG process is the same as that in S13, but will be described in detail later. If the path is OK (Yes in S20), it is checked whether the command can be executed using the task arbitrator 64 (S22).

  Specifically, by executing a command to the task arbitrator 64, it is checked whether a deadlock occurs due to contention with other tasks. In this confirmation, the task ID, the route type, the own transfer device ID, and the next transfer device ID are transmitted to the task arbitrator 64. The task arbitrator 64 confirms the scheduled route of the other task (S23), further confirms the current execution status of the transport device using the device execution status table, and checks whether there is an opposing task (S24). Next, by executing the transport command, it is checked whether deadlock is caused or not and a check result is output (S25).

  In S25, starting from the transfer device that is the current position of the route information of the invoking task registered in the in-execution route table shown in FIG. 12, the two devices of the pre-movement device ID and the movement destination device ID are designated as “FROM” and “To”. As the set of “”, the presence or absence of the opposite task route is checked on the apparatus execution status table.

  Next, the check result of S25 is judged (S26). In S26, if each “From”-“To” on the own route is associated with “To”-“From” on the table and it is checked whether other tasks are registered, the other task opposite to the own task is determined. The presence or absence of can be determined. If the opposite task check is OK, the occupation state of the next device on the task route by the other task is checked, and if there is an occupation, it is determined as Wait (in S26, Wait), and if there is no occupation, it is determined OK. (OK in S26). If there is an opposing task, it is determined as deadlock (in S26, deadlock).

  Further, when the deadlock check is “Wait” or “deadlock” in S <b> 26, the task arbitrator 64 outputs the check result to the automatic operation management management device 66. If the check result is OK in S26, the check result is output to the automatic operation management device 66 after updating the running path table and the device execution status table (S27).

  Here, the in-execution path table and the device execution status table manage the progress of the task, and information is updated as the task progresses. In the in-execution route table, when the transition from the current position to the next device is determined, the transfer device ID state at the current position is set to 0 (setting of the device used in the past), and the transfer device ID state of the next device is set to 2 ( Set new current position). In the device execution status table, when the transition from the current position to the next device is determined, the registration information of the task for the device ID of “From”-“To” corresponding to “Previous device”-“Current position” is stored. The transfer device ID state is set to 2 in the registration information of the task for the device ID of “From”-“To” corresponding to “Current position”-“Next device”.

  The automatic driving control device 66 determines the check result (S28). If the result of the deadlock check indicates that a task that uses the same route or device is currently being executed and is waiting to start command execution, or is not deadlocked at the current operating position, but a deadlock occurs when the command is executed (In S28, Wait), the steps after S18 are performed again. When a deadlock occurs as a result of the deadlock check (in S28, deadlock), deadlock processing is performed (S29). Details of the deadlock process will be described later.

  If the result of the deadlock check indicates OK (OK in S28), the automatic driving control device 66 transmits a transfer command to the transfer device controller 33 and waits for its completion (S30). After completion, the automatic driving control management device 66 updates the pallet ID and management number in the shelf information table 65 and deletes the task ID in the device operation information table 67 (S31).

  The steps from S15 to S31 described above are performed until there is no transfer command that is not executed, and when the transfer command is lost, the execution result is output to the loading / unloading task management device 62. The entry / exit task management device 62 waits for the completion of execution from the automatic driving control device 66 (S32), and after receiving the completion result, performs the entry / exit task completion processing (S33). Specifically, for tasks that have been completed normally, the corresponding task in the execution reservation task table shown in FIG. 10A and FIG. In the embodiment, the corresponding task in the execution reservation task table is deleted. However, for example, a separate transfer history table may be provided, and task history may be sequentially stored therein, or the corresponding task record in the execution reservation task table may be stored. The end time may be set in and stored.

  Next, the NG process of S13 and S21 described above will be described using a flowchart.

  FIG. 19 is an example flowchart illustrating a processing procedure in the NG processing. In NG processing, processing differs depending on whether the task is inbound or outbound. Therefore, it is determined whether it is a warehousing task (S41). If it is a warehousing task (Yes in S41), there is no need to urgently enter the warehousing task, so the vacant route may be used for warehousing. Therefore, in order to continue the task in the new route, the steps after S03 shown in FIG. 18 are continued (S42). If the task is a delivery task (No in S41), there is a possibility that the passenger of the vehicle may be waiting, and it is necessary to make the delivery immediately, so the automatic driving control device 66 terminates the task abnormally. The result is output to the loading / unloading task management device 62 (S43). The output contents are an end notification, a task ID, and an end status (normal / abnormal).

  The entry / exit task management device 62 stores the task from the execution reservation task table in the recovery task table of FIG. That is, the contents of the execution reservation task table accumulated in FIG. 10A or FIG. 10B are moved and stored in the recovery task table in FIG. 10C together with the failure occurrence time. The administrator quickly performs the recovery process from the recovery task list screen displayed on the system operation screen 35. The operation screen and the like will be described later.

  Next, the deadlock process in S29 will be described. FIG. 20 is a flowchart illustrating an example of a deadlock processing procedure. When the deadlock occurs, the automatic driving control device 66 determines whether there is another route whose destination has been changed or a return route that returns to the route so that the deadlock does not occur (S51). If another route or a return route exists (Yes in S51), the route is recreated (S52), and the steps after S03 shown in FIG. 18 are continued based on the recreated result (S53). If there is no separate route and no return route (No in S51), the automatic driving management device 66 abnormally ends the task and outputs the result to the loading / unloading task management device 62 (S54). The output contents are an end notification, a task ID, and an end status (normal / abnormal).

  The entry / exit task management device 62 saves the task from the execution reservation task table to the recovery task table. The contents of the execution reservation task table accumulated in FIG. 10 (a) or FIG. 10 (b) are moved and stored in the recovery task table of FIG. 10 (c) together with the failure occurrence time.

  In the above-described processing procedure, the automatic driving control device 66 deletes the route from the task arbitrator 64 and deletes the execution / occupation state at the normal end (S17) or at the abnormal end result output (S43, S54). Request. Upon receiving the request, the task arbitrator 64 deletes the contents related to the task stored in the in-execution route table (FIG. 12A) and the device execution status table (FIG. 12B) included in the task arbitrator 64. In addition, the contents regarding the task in the apparatus operation information table 67 are deleted.

  By performing the above-described processing, a plurality of loading / unloading tasks can be executed efficiently and stably. In particular, a plurality of tasks can be executed at the same time, and even when a new interrupt task is added during the sequential execution of tasks, it is possible to achieve efficient and stable vehicle entry and exit. Further, even when the transport device used at the time of entry / exit cannot be used for reasons such as failure or deadlock avoidance, it is possible to change the route and realize quick entry / exit of the vehicle.

  Furthermore, a task having an abnormality can be saved as recovery data, and can be re-executed after repairing a failure or when the task can be executed.

  Thereby, for example, efficient and stable processing can be performed, for example, processing for preferential entry / exit of special vehicles, recovery processing for troubles that cannot be performed due to a failure during delivery, and the like.

<System operation screen>
Next, a display screen displayed when the parking lot control system is displayed on the system operation screen 35 will be described with reference to the drawings.

  FIGS. 21-23 is a figure which shows an example of the screen of the parking lot control system in this invention. Here, FIG. 21 shows an example of the main menu screen of the parking lot control system, FIG. 22 shows an example of the parking room screen, and FIG. 23 shows an example of the execution reservation task display screen. 21 to 23 are software that can be provided by installing a parking lot control program in a general-purpose computer or the like.

  The main menu screen 100 in FIG. 21 is configured to include an apparatus operating status confirmation area 101, a basic information display area 102, a name display area 103, and a button display area 104. The button display area 104 includes a parking room display button 105 and a work screen display button 106 during execution.

  First, the apparatus operation status confirmation area 101 has a lamp display unit 111, and includes an N-CPS (integrated control device 31: host system control system) and a transport device (berth 43, lift 44, carriage 45, parking room 46). ), The lamp color indicating normal (for example, green) is displayed if it is operating normally, and if there is an abnormality, the lamp color is changed (for example, green to red). ). Thereby, the system administrator can easily grasp that there was an abnormality in the parking lot control system.

  The basic information display area 102 displays the software version, current time, and the like. Moreover, a name display area | region displays the name of the parking lot control system used as the object of the display screen. The button display area 104 displays various button groups for displaying information necessary for managing the parking lot control system according to the present invention. In FIG. 21, only the parking room display button 105 and the in-execution work screen display button 106 are displayed. However, the types of buttons that can be displayed are not limited to this, for example, for viewing and updating device configuration data. Screen display buttons, screen display buttons for viewing and updating shelf information tables, and the like. For example, when the menu screen is activated, a user ID, a password, or the like can be input, and a button group displayed in the button simultaneous area 104 can be changed based on the input content. .

  When the parking room display button 105 is selected, a parking room screen shown in FIG. 22 is displayed. Specifically, a parking room screen 120 and a route information screen 130 are displayed. The parking room display screen 120 includes a device operation status confirmation area 101 and a layout display area 121 for displaying a layout of a parking room, a lift, a loading / unloading berth, etc. for each level of the parking lot. The tab selection part 122 is for selecting the parking lot of the hierarchy which wants to be displayed, and can grasp | ascertain the mode of the hierarchy which wants to browse easily by selecting a tab.

  For example, the shelf ID “1001” of the parking room 1 shown in FIG. 22 indicates that the pallet with the current pallet ID “55” is installed and the pallet ID “55” is an empty pallet. Further, the shelf ID “1004” indicates that the pallet with the current pallet ID “53” is installed, and the pallet ID “53” indicates that the pallet with the management number 3106 is an actual pallet. . In this manner, parking space availability information and the like can be easily grasped from the parking room screen 120. Note that this screen is updated at a constant cycle or updated as soon as a loading / unloading task is requested. In addition, as the information inside the shelf, a pallet ID and a management number for each shelf stored in the shelf information table are displayed.

  In addition, the route information screen 130 is configured to include a management number display area 131 and a running path information display area 132 that are targeted for each task ID. The tab selection unit 133 can display the currently executed route information and the execution status for each work ID. Further, in the in-execution path information display area 132, a path is displayed with reference to the in-execution path table and the apparatus execution status table shown in FIG. In addition, a lamp display unit 141 is provided for each shelf ID for each route, so that it is possible to quickly grasp which shelf ID is currently being moved by color-coding the lamps.

  In FIG. 21, when the in-execution work screen 106 is selected, an execution reservation task table display screen 150 having a tab selection unit 151 is displayed as shown in FIG. In FIG. 23, the entry / exit task and the recovery task that are reserved for execution are displayed in a list format. As this data, the data (FIG. 10) of the entry / exit task management device 62 is displayed. The warehousing work and the warehousing work are displayed as shown in FIG. Further, the recovery task list is displayed as shown in FIG. 23B. When the recovery task list is displayed, a re-execution start button 152 is displayed on the execution reservation task table display screen 150. In addition, it is possible to select a row of a task for which recovery processing is to be executed from the recovery task list. For example, when the management number 3018 is selected and the re-execution start button 152 is selected, the work related to the work ID 2699 is executed.

  As a result, it is possible to easily grasp the processing contents that need to be recovered, and to quickly execute the recovery processing.

  As described above, according to the present invention, it is possible to efficiently and stably perform the operation of the transport device in response to a loading / unloading request. For example, when a plurality of loading / unloading requests are executed at the same time, a conflict is avoided by performing a conflict check with the execution status of the transfer device before the transfer operation to be executed by each request. Can be realized. Further, even when a plurality of tasks are added or deleted at an arbitrary timing, a route can be generated quickly.

  More specifically, in a mechanical parking lot device having a plurality of loading / unloading ports, a lift device, a linear track cart device, and a parking room, it is possible to avoid the occurrence of deadlock and execute a plurality of loading / unloading tasks. In addition, if a part of the device configuration of the mechanical parking lot control system breaks down and cannot be moved in and out, save it as a recovery task and re-execute it easily when the broken device is restored. be able to.

  The preferred embodiments of the present invention have been described in detail above, but the present invention is not limited to such specific embodiments, and various modifications can be made within the scope of the gist of the present invention described in the claims.・ Change is possible.

It is a figure which shows the example of 1 structure of the conventional mechanical parking lot. It is a figure of an example which shows the path | route between each structural equipment in loading / unloading. It is a figure which shows one structural example of the mechanical parking lot control system in this invention. It is a figure which shows the hardware structural example of an integrated control apparatus. 3 is a diagram illustrating a specific configuration example of an integrated control device 41. FIG. It is a figure which shows the apparatus structure data of a mechanical parking lot. It is a figure which shows the example of data which defines the layout of a mechanical parking lot. It is a figure which shows the example of definition data regarding the connection relation of each conveying apparatus. It is a figure which shows the parking lot layout example. It is a figure which shows an example of the table accumulate | stored in the entering / exiting task management apparatus. It is a figure which shows the example of route candidate data accumulate | stored in a path generator. It is a figure which shows an example of a running table. It is a figure which shows the table example of a shelf information table. It is a figure which shows the example task table in execution which preserve | saves the task information received from the entering / exiting task management apparatus. It is a figure which shows the example of a route table for every task for defining the route preset for every task. It is a figure which shows the example of a task table for every conveying apparatus. It is a figure which shows an example of an apparatus operation information table. It is a chart figure of an example which shows the control procedure for implement | achieving the parking lot control system in this invention. It is a flowchart of an example which shows the process sequence in NG process. It is a flowchart of an example which shows a deadlock processing procedure. It is a figure which shows an example of the main menu screen of a parking lot control system. It is a figure which shows an example of a parking room screen. It is a figure which shows an example of an execution reservation task display screen.

Explanation of symbols

DESCRIPTION OF SYMBOLS 10 Mechanical parking lot 11 Ground floor 12 Warehousing berth 13 Warehousing berth 14 Warehousing lift 15 Warehousing lift 16 Parking room 17 Linear traveling trolley 18 Pallet 30 Mechanical parking garage control system 31 Integrated control device 32 Warehousing / exiting operation device 33 Conveyance equipment control device 34 Operation Mode / Fault Management Device 35 System Operation Screen 41 Information Management Means 42 Execution Management Means 61 Initial Setting Database 62 Entry / Exit Task Management Device 63 Path Generator 64 Task Abitrator 65 Shelf Information Table 66 Automatic Operation Control Management Device 67 Device Operation Information Table 100 Main menu screen 101 Device operation status confirmation area 102 Basic information display area 103 Name display area 104 Button display area 105 Parking room display button 106 Work screen display button 111, 141 lamp display 120 parking room screen 121 layout display area 122,133,151 tab selection section 130 the route information screen 131 management No display area 132 running route information display area 150 executes the reserved task table display screen 152 re-execution start button

Claims (22)

For entry / exit of vehicles in a three-dimensional parking garage having one or more parking rooms for each of one or more floors, an entrance / exit, a lift device for transporting the vehicles between the floors, and predetermined parking of the vehicles In a mechanical parking control system for controlling the operation of a transfer device having at least a parking room for parking at a position,
Entry / exit management means for accumulating and managing execution reservation information for warehousing / receipt in response to a warehousing / receipt request for warehousing or leaving a vehicle;
Route generating means for generating route candidates in the transport device for each loading / unloading request accumulated in the execution reservation information;
A conflict check unit that checks whether the operation of the transfer device based on the route obtained by the route generation unit conflicts with the operation of the transfer device based on another entry / exit request;
An execution management means for managing an execution status based on the entry / exit request, a mechanical parking lot control system. The route generation means includes
It has a route candidate table in which all route candidates that can be used in advance are accumulated, makes a route conflict check request to the conflict check means based on the route candidate table, and based on the conflict check result, the entry / exit port The mechanical parking lot control system according to claim 1, further comprising route determination means for determining a vehicle conveyance route between the vehicle and the parking room. The conflict check means includes:
The route determination unit includes route information for each entry / exit request determined by the route determination unit and execution status information of the transfer device, and performs execution determination based on the route information and the execution status information. Item 4. The mechanical parking lot control system according to Item 2 or 3. The execution management means includes
It has the loading / unloading request information that is being executed, the route information for each loading / unloading request, and the loading / unloading request information for each of the transfer devices. 4. The apparatus according to claim 1, further comprising a transfer execution unit that detects a loading / unloading request that uses the transfer device and transfers the detected loading / unloading request to another route. The mechanical parking lot control system as described in. The storage management means is
5. The storage system according to claim 1, wherein when there is no route that can be used for a shipping request, the shipping request stored in the execution reservation information is stored as recovery information. Mechanical parking lot control system.   The mechanical parking lot control system according to any one of claims 1 to 5, further comprising a re-execution unit that re-executes the exit request stored as the recovery information.   7. The display device according to claim 1, further comprising a display unit configured to display at least the layout of the three-dimensional parking lot, the execution status in the loading / unloading request, and the execution reservation information and recovery information. The described mechanical parking lot control system. For entry / exit of vehicles in a three-dimensional parking garage having one or more parking rooms for each of one or more floors, an entrance / exit, a lift device for transporting the vehicles between the floors, and predetermined parking of the vehicles In a mechanical parking control method for controlling the operation of a transfer device having at least a parking room for parking at a position,
Incoming / outgoing management stage for accumulating and managing execution reservation information for in / out of goods in response to the in / out request for entering or leaving the vehicle,
A route generation stage for generating route candidates in the transport device for each loading / unloading request accumulated in the execution reservation information;
A contention check step for checking whether the operation of the transport device based on the route obtained in the route generation step conflicts with the operation of the transport device based on another entry / exit request;
And an execution management stage for managing an execution status based on the entry / exit request.   Based on the route candidate table in which all the route candidates that can be used in advance are accumulated and the conflict check result from the conflict check stage, the transport route of the vehicle between the entrance / exit and the predetermined parking position is determined. 9. The mechanical parking control method according to claim 8, further comprising a route determination step for determining. The conflict check stage includes
The mechanical parking lot control according to claim 8 or 9, wherein execution determination is performed based on route information for each entry / exit request determined in the route determination step and execution status information of the transfer device. Method.   At the time of warehousing or warehousing operation, if there is an abnormality in at least one of the transport devices, the warehousing request information for executing the warehousing request using the transport device, route information for each warehousing request, The transfer execution stage which detects based on the loading / unloading request information for every said conveyance apparatus, and transfers and detects the detected loading / unloading request to another path | route, The any one of Claim 8 thru | or 10 characterized by the above-mentioned. The mechanical parking lot control method as described.   12. The recovery information accumulation step of accumulating the exit request stored in the execution reservation information as recovery information when there is no route available for the exit request. The mechanical parking lot control method according to claim 1.   The mechanical parking lot control method according to any one of claims 8 to 12, further comprising a re-execution stage for re-executing the exit request accumulated in the recovery information accumulation stage.   14. The display device according to claim 8, further comprising a display step of displaying at least the layout of the three-dimensional parking lot, the execution status in the loading / unloading request, and the execution reservation information and recovery information. The mechanical parking lot control method as described. For entry / exit of vehicles in a three-dimensional parking garage having one or more parking rooms for each of one or more floors, an entrance / exit, a lift device for transporting the vehicles between the floors, and predetermined parking of the vehicles In a mechanical parking control device for controlling the operation of a transport device having at least a parking room for parking at a position,
Entry / exit management means for accumulating and managing execution reservation information for warehousing / receipt in response to a warehousing / receipt request for warehousing or leaving a vehicle;
Route generation means for generating route candidates in the transport device for each loading / unloading request accumulated in the execution reservation information;
A conflict check unit that checks whether the operation of the transfer device based on the route obtained by the route generation unit conflicts with the operation of the transfer device based on another entry / exit request;
An execution management means for managing an execution status based on the entry / exit request, a mechanical parking lot control device. The route generation means includes
It has a route candidate table in which all route candidates that can be used in advance are accumulated, makes a route conflict check request to the conflict check means based on the route candidate table, and based on the conflict check result, the entry / exit port The mechanical parking lot control device according to claim 15, further comprising route determination means for determining a vehicle conveyance route between the vehicle and the parking room. The conflict check means includes:
The route determination unit includes route information for each entry / exit request determined by the route determination unit and execution status information of the transfer device, and performs execution determination based on the route information and the execution status information. Item 15. The mechanical parking lot control device according to Item 15 or 16. The execution management means includes
It has the loading / unloading request information that is being executed, the route information for each loading / unloading request, and the loading / unloading request information for each of the transfer devices. 18. A transfer execution unit that detects a loading / unloading request that uses the transfer device and transfers the detected loading / unloading request to another route when there is a transfer device. 18. The mechanical parking lot control apparatus according to 1. The storage management means is
19. The exit request stored in the execution reservation information is stored as recovery information when there is no route that can be used for the exit request. Mechanical parking lot control device.   The mechanical parking lot control device according to any one of claims 15 to 19, further comprising re-execution means for re-executing the exit request accumulated as the recovery information.   21. The display device according to any one of claims 15 to 20, further comprising display means for displaying at least the layout of the three-dimensional parking lot, the execution status in the loading / unloading request, and the execution reservation information and recovery information. The mechanical parking lot control apparatus as described.   The mechanical parking lot control program for making a computer perform the mechanical parking lot control method of any one of Claims 8 thru | or 14.

Images