RESCUE MODE IN SHUTTLE SHELVING ARRANGEMENT
Patent Information
- Application Number
- DE502021008302
- Authority / Receiving Office
- DE · DE
- Patent Type
- Patents
- Current Assignee / Owner
- Priority Date
- 2020-12-14
- Filing Date
- 2021-11-19
- Publication Date
- 2025-08-28
- Estimated Expiration
- 2041-11-19
AI Technical Summary
Energy-autonomous vehicles in automated warehouse systems lose control during power outages, leading to safety concerns and requiring manual intervention for system restart due to their limited operational time without communication.
Implementing a rescue mode where vehicles autonomously return to charging stations after a predetermined time period, ensuring they are in a controlled state for system restart, and using initial pairing data stored in non-volatile memory to verify their positions and enable automatic reconfiguration without manual intervention.
Ensures safe and automated system restart by verifying vehicle positions and recharging, eliminating the need for manual inspection and reducing downtime.
Description
[0001] The present disclosure relates to an automatic warehouse system having a plurality of energy-autonomous vehicles, as well as a method for restarting the automatic warehouse system after a power failure, which results in particular in a parallel communication interruption.
[0002] Automated storage systems are known that comprise a racking arrangement consisting of two racks, which in turn define a rack aisle between them. The racks have several vertical levels stacked one above the other, which are served by one or more storage and retrieval machines for storing and retrieving goods in and out of rack storage locations.
[0003] Storage and retrieval machines are vehicles. If the vehicles are designed without a lifting function, they are so-called single-level storage and retrieval machines, also known as "shuttles." However, there are also vehicles with a lifting function, allowing them to serve several vertically adjacent rack levels. For example, there are known storage and retrieval machines that serve two to four rack levels.
[0004] These vehicles can be permanently connected to an (external) energy source, for example, via a conductor line, or be energy-autonomous. Energy-autonomous vehicles have an on-board energy storage unit and are not permanently connected to the energy source. The on-board energy storage unit is charged in or at so-called charging stations. The vehicles (usually rail-bound) drive to the charging station, where charging contact points are provided to (temporarily) connect the respective vehicle to the energy source for charging.
[0005] However, safety requirements are higher when energy-autonomous vehicles are used. For example, it must be ensured that the energy-autonomous vehicles are permanently under the control of a higher-level system controller to prevent the vehicles from performing any unintentional actions. This is particularly important because the vehicles must be maintained by operators (humans). In the case of (manual) maintenance, the maintenance technician must physically enter the rack arrangement. In this case, it must be ensured that the vehicles do not move unintentionally. For vehicles that are permanently supplied with power via a conductor line, it is sufficient to interrupt the power supply, because in this case the vehicles can no longer move. For energy-autonomous vehicles, this measure is not sufficient.
[0006] Following a power outage and the resulting loss of communication between the energy-autonomous vehicles and a higher-level control system, the automated warehouse system must be restarted as quickly as possible once the power supply is restored. Energy-autonomous vehicles are only operational for a limited period of time because their energy storage systems discharge over time. If the energy-autonomous vehicles come to a stop at any position within a rack aisle, the automated warehouse system can only be restarted with manual intervention by a maintenance technician after the vehicles have been completely unloaded.
[0007] The document DE 20 2020 104 954 U1 concerns a shuttle for a shelving system and a shelving system.
[0008] The document AT 516 231 A1 relates to an automated shelf storage system and a method for its safe operation.
[0009] According to its abstract, document US 2017 182 664 A1 relates to systems and methods for limiting the capabilities of a robot during teleoperation based on network connection strength. The method may include determining levels of operations that can be performed by a robot. One or more network strength thresholds corresponding to one or more of the robot's operating levels may also be determined. The robot may then measure the network strength for the communication network between the robot and a remote control system. Based on the measured network strength and the determined network strength thresholds, one or more of the operating levels may be enabled for selection by the remote control system. The robot may determine the network strength based on network latency and / or packet loss rate.The robot may provide notification to the remote control system about disabling a previously enabled level of operations due to reduced network strength.
[0010] Therefore, it is an object of the present disclosure to provide an improved automated warehouse system with energy-autonomous vehicles and a method for automated resumption of operations, wherein safety is particularly ensured.
[0011] This object is achieved by an automatic storage system according to claim 1.
[0012] If the power in the storage system fails, a communications network through which the vehicles communicate with the system controller also no longer receives power. The system controller loses control of the vehicles. This is critical from a safety point of view. To prevent unintentional actions by the vehicles, the vehicles are switched to an autonomous rescue mode after the first time period T1. The first time period T1 can represent a time period that is usually required to restart the communications network. The first time period is 35 seconds, for example. After this time has elapsed, the vehicles switch to a rescue mode in which they are permitted to move for a short time without the control of the system controller. In rescue mode, the vehicles are autonomous. This means that the vehicles can be moved under their own control. In rescue mode, the vehicles can be driven to their charging station.
[0013] At the latest when the vehicles are at their charging stations, physical contact is (again) established between the vehicles and the higher-level system controller. This measure enables the system controller to obtain information about the respective vehicle.
[0014] In addition, the vehicles’ energy storage units can be recharged once the power outage is over.
[0015] After the power outage, the vehicles are located in clearly defined positions, namely on their charging stations. The maintenance technician can verify whether the vehicles behaved compliantly during the power outage simply by observing them from the outside. Vehicles not positioned on their charging stations have not behaved compliantly, so there is a risk that a safety-relevant error has occurred. The maintenance technician can determine this simply by observing them from the outside, without having to enter the rack aisle.
[0016] However, the condition described above can also be verified virtually at the system control level, without the maintenance technician having to physically inspect the system. After a power outage, the vehicles report their current position back to the system control. If the current position does not match the position of the assigned charging station, there is likely an error that requires manual inspection. Otherwise, the storage system can be automatically restarted.
[0017] Preferably, the pairing process is initiated as soon as communication with the system controller is restored and as soon as the corresponding vehicle is supplied with energy via the charging station.
[0018] It is possible that communication is interrupted for another reason that is not caused by a power outage. In this case, too, the vehicles return to their charging station after the first predetermined time period T1 has elapsed to complete the (re-)pairing process. This condition is again visually detectable because the vehicle(s) will return to their charging station on their own.
[0019] However, if the power fails for a very long period of time, the pairing process can only be carried out when the (discharged) vehicles have sufficient power again to restart the vehicle control system, in particular to re-establish communication with the system control system based on the initial pairing data.
[0020] The pairing process is carried out based on the initial pairing data, which includes a location address and a (unique) identifier of the vehicle, which are permanently and unambiguously assigned to each other, and wherein the initial pairing data is stored in a permanent memory of the vehicle.
[0021] The initial pairing data assigns each vehicle to a location in the racking arrangement. This information can be used when the warehouse system is restarted. The respective vehicle does not need to be reconfigured. The pairing process therefore uses previously stored data without the need for manual intervention.
[0022] This data is stored in a section of the vehicle's data storage that the vehicle's CPU (vehicle control system) doesn't use for normal operation. This data can be stored in a specially protected memory area. This data is never lost, even during very long power outages, even if the vehicle's energy storage is completely discharged.
[0023] Communication is preferably wireless, especially via WLAN.
[0024] Because the vehicle is energy-autonomous, there is no permanent physical (data) connection to the system controller. Communication therefore takes place via a local wireless network, particularly Wi-Fi. If a power failure occurs in the entire warehouse system, communication also fails. The system controller loses control of the respective vehicle. Nevertheless, it is possible to automatically move the respective vehicle to its reference point (charging station) without compromising safety.
[0025] Furthermore, it is possible that the data memories of the vehicles each have a non-volatile area for storing initial pairing data and a volatile area for working for the respective vehicle control.
[0026] The data relevant for the pairing process is located in a different memory area than the CPU's RAM. This reduces the risk of errors. The data relevant for the pairing process cannot be overwritten with data that the vehicle's CPU needs to function. This increases security.
[0027] Preferably, the energy storage devices of the vehicles each have a quick-charging energy storage device for energy to move the respective vehicle and a (separately arranged) backup energy storage device for energy to maintain stored data and to execute emergency functions by the vehicle control system.
[0028] The backup energy storage ensures that the data relevant for the pairing process can be retained in the vehicle for a very long time. In the event of a very long power outage, the vehicle may no longer be able to move. However, sufficient energy is available to re-establish the communication required to automatically restart the storage system without the need for manual intervention by the maintenance technician.
[0029] Furthermore, the object is achieved by a method according to claim 6 for restarting an automatic storage system.
[0030] This type of driving allows the advantages already described above in connection with the storage system to be achieved.
[0031] The pairing process is based on initial pairing data that is permanently stored in a data memory of the respective vehicle, whereby an initial configuration of the respective vehicle has the initial pairing data, which includes an identifier of the respective vehicle and a location address of the respective vehicle, which were initially assigned to each other.
[0032] In particular, the step of initiating a pairing process may comprise the respective vehicle performing a characteristic interaction with the charging station assigned to it and comparing the location address of the respective vehicle with a location address assigned to the corresponding charging station, which provides a characteristic status signal in response to the characteristic interaction of the respective vehicle.
[0033] Preferably, a characteristic charging current is considered. The vehicles are successively verified with regard to the data stored in the vehicles. Verification is performed by the system controller. This increases security. The system controller does not rely solely on the data provided by the respective vehicle. The system controller verifies whether the data stored in the vehicle matches the data stored in the system controller. This verifies that the data stored in the vehicle was not changed during the power outage, eliminating the need for a new initial configuration when the storage system is restarted.
[0034] Preferably, the respective vehicle changes to a driveless operating mode after the expiry of a second predetermined time period T2, which follows the first predetermined time period T1.
[0035] In driveless mode, the vehicles' (electric) drives are switched to zero torque. This mode can only be changed by the system controller. In other words, a vehicle in driveless mode cannot be moved on its own, especially not by the vehicle controller itself. This increases safety. A maintenance technician can therefore enter an area where the vehicle is normally moving.
[0036] In particular, the method further comprises: periodically checking whether communication between the respective vehicle controller and the system controller has been restored after the interruption.
[0037] Preferably, the method further comprises: requesting an enable signal from the system controller by the respective vehicle controller after communication has been restored.
[0038] The system control's request for approval ensures that the vehicle does not move on its own or revert to automatic mode, which places increased safety demands. Approval is only granted once the system control has checked the vehicle's data and is certain that the data stored in the vehicle matches the data stored in the system control.
[0039] In particular, a communication interruption is logged by the respective vehicle in its data memory.
[0040] The communication interruption log can be used by the system controller to determine whether or not the vehicle in question has fully completed a travel order it had during the communication interruption. This information is particularly important for a material flow controller to determine whether the travel order needs to be reissued or has been completed.
[0041] Preferably, the method further comprises: checking whether the respective vehicle is positioned on the pre-assigned charging station after the respective vehicle has switched to the rescue mode.
[0042] It is understood that the features mentioned above and those to be explained below can be used not only in the combination specified in each case, but also in other combinations or on their own, without departing from the scope of the present invention.
[0043] Embodiments of the invention are illustrated in the drawings and explained in more detail in the following description. They show: Fig. 1 shows a block diagram of a storage and picking system; Fig. 2 shows a block diagram of a vehicle, a system controller, and a station; Fig. 3 shows an exemplary assignment table during an initial configuration; Fig. 4 shows a flowchart of a method for restarting an automated storage system; and Fig. 5 shows a diagram of time sequences.
[0044] The present disclosure is used in intralogistics systems.
[0045] The subject matter of the disclosure opens up the possibility of "safely" re-assigning physical addresses and logical addresses (e.g. IP addresses) of vehicles in the intralogistics system after a power failure, which consequently also results in a communication failure.
[0046] It must be ensured that the location where a vehicle is supposedly located – for the system controller – overrides the location where the vehicle actually is. The location where the vehicle is supposedly located is the same as the location where the system controller believes the vehicle to be. This verification is particularly necessary for the automated resumption of system operation after a power failure.
[0047] In particular, a physical address represents an address of a location (location address) where the corresponding vehicle is located within the system, and the logical address represents in particular a communication address (e.g. an IP address) via which a vehicle is addressed in order to exchange data.
[0048] Intralogistics generally deals with the organization, control, implementation and optimization of internal material flows, information flows and goods handling, for example in industry, trade and public institutions.
[0049] The following description is given by way of example with reference to a Cartesian coordinate system XYZ, where X denotes a longitudinal direction, Y a vertical direction and Z a transverse direction, as is common in intralogistics.
[0050] Fig. 1 shows a block diagram of a warehouse system (hereinafter also referred to as "system") 10, where goods are stored. The warehouse system 10 may be part of a picking system (not shown in detail), where the stored goods are picked.
[0051] The system 10 comprises at least one vehicle 12 and preferably a plurality of vehicles 12. The system further comprises at least one station 14 and preferably a plurality of stations 14. Finally, the system 10 also comprises a system controller 16, which preferably also includes the function of an access control. In automated systems, access controls ensure that people gaining access to the systems cannot be injured by automated machines.
[0052] The system 10 further comprises a rack assembly 18 having at least two parallel racks 20 defining a rack aisle 22 (not shown) therebetween, as is known.
[0053] Fig. 2 shows a block diagram of the system controller 16. The system controller 16 comprises one or more data processing devices 24, one or more data memories 26, and one or more interfaces (I / O) 28 for communicating with entities of the system 10, such as the vehicles 12 and the stations 14, by exchanging data. Communication takes place via fixed lines 30 and / or wireless connections 32. In particular, communication between the system controller and the vehicles 12 takes place wirelessly, e.g., via WLAN using TCP / IP.
[0054] The system control 16 can be implemented centrally or decentrally.
[0055] The system controller 16 can implement one or more of the following functions: warehouse management, in particular storage location management; quantity management (inventory management); material flow control; data acquisition, processing, and visualization; picking strategies; optimizations (e.g., regarding transport, picking sequence, route planning, batch creation, and the like); and / or access control. It is understood that this list is not exhaustive and other intralogistics-relevant functions may also be included.
[0056] The data processing device 24, the memory 26 and the interface 28 of the system control 16 are connected to one another, for example, via a bus system 34.
[0057] Fig. 2 further shows, by way of example, a block diagram of one of the vehicles 12. The following description generally also applies to a plurality of vehicles 12. Each vehicle 12 of the system 10 has at least one data memory 26, a vehicle controller 36 and a communication interface 28. Furthermore, the vehicles 12 have an energy storage device 38 (e.g. battery, capacitor, power cap, etc.) in order to be operated in an energy-autonomous manner. This means that the vehicles 12 are not permanently connected to a power supply line (not shown) while the vehicles 12 move in the rack aisles. The vehicle controller 36 also comprises a CPU and programs that are stored in the memory 26 and executed by the CPU, for example to store and retrieve the stored goods according to transport orders, to monitor communication with the system controller 16, to execute emergency procedures and the like.
[0058] The vehicles 12 are rack-bound, ie they travel in a forced manner on or in rails (not shown) that are attached to the shelves 20.
[0059] Furthermore, the vehicles 12 can each have a load handling device (LAM) 40 for storing and retrieving the stored goods.
[0060] It is understood that each of the vehicles 12 may have further components, such as a drive, wheels, a frame, sensors, a switchable discharge resistor and the like, which are not considered in detail here to simplify the illustration.
[0061] The communication interface 28 of the vehicle 12 is connectable to the interface 28 of the system controller 16. The interface 28 of the vehicle 12 is further configured to be connected to a data terminal 42 (e.g., laptop, tablet PC, mobile data terminal, or the like).
[0062] The data terminal 42 is a portable unit that an operator (e.g., a maintenance technician) can carry. Fig. 2 The data terminal 42 is physically connected to the interface 28 of the vehicle 12, for example, via a cable 46. It is understood that this connection can also be in the form of a wireless connection 32 (e.g., WiFi).
[0063] The data terminal 42 preferably has a visual display 48 and an input device 50 (e.g., keyboard, microphone, touch panel, or the like) (not shown in detail). A configuration screen can be displayed to the operator 44 via the display 48, with the aid of which the operator 44 can select and enter configuration data, such as a vehicle ID 52, ie, a vehicle-specific identifier, a specific location address 54, ie, a location-specific or physical address, and the like, as described in connection with the Fig. 4 DE 10 2018 132 814 B3, to which reference is made here. This document also describes an initial configuration, to which reference is also made here, and according to which it can also be automatically verified whether a location address (initially) stored in the vehicle 12 matches a location address assigned to one of the stations 14 that can interact with this vehicle 12. This is preferably a charging station 14 specific to the rack aisle and rack level, via which the vehicle 12 assigned to this rack aisle and rack level is charged.
[0064] Furthermore, the Fig. 2 One of the stations 14 is shown as an example. The station 14 also has a (communication) interface 28 for communicating with the interfaces 28 of the system controller 16 and / or the vehicles 12, i.e., for exchanging data. Depending on the station type, each station 14 can have a power supply 56, a light barrier 58, and / or other sensors and / or actuators. The following preferably considers charging stations 14, each of which has a power supply 56 for charging the energy storage devices 38 of the vehicles 12 when the corresponding vehicle 12 is positioned at the charging station 14.
[0065] Each station 14 is assigned a station ID 60 (not shown here) (cf. Fig. 4 ), i.e., a station-specific identifier. The station ID 60 can be stored in a (data) memory 26 of the station 14, just as the vehicle ID 52 is stored in the memory 26 of the vehicles 12.
[0066] The racks 20 have rack levels RE1 to REn in the Y direction, where n is an integer greater than zero. The first rack level RE1 is typically the lowest rack level. The rack level RE comprises a plurality of rack locations where the goods are stored in the rack 20. Preferably, each rack level RE is served by one of the vehicles 12, which is movable horizontally in the X direction in the rack aisle 22.
[0067] Each rack level RE, where one of the vehicles 12 is located, is equipped with a charging station 14 to charge the energy-autonomous vehicles 12 from time to time. The charging stations 14 can be positioned at any location in the X direction within the rack aisle 22. Preferably, the locations of the charging stations 14 represent a reference point (zero point) for the respective vehicle 12. This means that the zero point for a horizontal travel of the vehicles 12 in the X direction is referenced to the charging station 14.
[0068] Vehicles 12 represent storage and retrieval machines (SRMs), in particular single-level SRMs (shuttles).
[0069] The shelf arrangement 18 can further be divided into access areas 68 (not shown) which are not further designated and shown, so that a configuration or allocation table 70 results which is shown in the Fig. 3 is shown.
[0070] Fig. 3 shows an example configuration or assignment table 70. Table 70 of the Fig. 3 can be stored in the data memory 26 of the system control 16 (cf. Fig. 2 ). Parts of the table 70 can also be stored in parallel in the vehicle (data) memory 26, in particular the initial pairing data, which comprise mutually assigned location addresses 54 and vehicle IDs 52, such as the location address 54-1 and the vehicle ID 52-1.
[0071] In particular, Table 70 of the Fig. 3 essentially three groups of information, namely information on (specific) location addresses 54, information on stations 14 and information on vehicles 12.
[0072] The stations 14 are preferably the charging stations 14, with at least one of the charging stations 14 being provided on each vehicle-operated shelving level RE. The charging stations 14 can be provided, for example (in the longitudinal direction X) at the beginning of the respective travel or shelving level RE. It goes without saying that the charging stations 14, in particular their charging contacts, can also be provided at a different location along the respective travel level 66. Furthermore, it goes without saying that more than one charging station 14 can be provided per travel level 66. To simplify the following explanation, it is assumed that only one station 14 is provided per travel level 66. This means that the respective location of the stations 14 is fixed.
[0073] Station 14, which is assigned to the lowest, first travel level 66-1 of a first access area 68-1 of the first rack aisle 22-1, has a specific station ID 60-1 with the content "14-1." Each station ID 60 is assigned uniquely within system 10 and uniquely identifies the associated station 14. The specific station ID 60 itself already represents a logical address under which the corresponding station 14 can be addressed by the system controller 16. The first station 14-1 can be assigned a further logical address in the form of a (station-)specific network address 72, either additionally or alternatively.
[0074] In the Fig. 3 The specific network addresses 72 of the stations 14 are implemented, for example, by (exemplarily local) IP addresses. In this case, the specific network addresses 72 of the station 14 span the address range "192.168.0.0" to "192.168.0.255." To distinguish these local IP addresses from other local IP addresses and other lanes 22, lane 22-1 could have a controller (not shown and not further identified), which in turn could be linked to a global IP address to restore the uniqueness of the address. This means that each of the lanes 22 of the system 10 could be provided with its own controller to enable unambiguous addressing of all stations 14 of the system 10.
[0075] Returning to Table 70 of the Fig. 3 The first station 14-1 is assigned the specific location address 54-1 with the content "111." The content "111" indicates that station 14-1 is located in the first aisle 22-1 within the first access area 68-1 on the first travel level 66-1.
[0076] The first vehicle 12-1 or the first shuttle is assigned to this specific location address 54-1. The first vehicle 12-1 has a specific vehicle ID 52-1, whose content is "12-1." Generally, the vehicle IDs 52 are also logical addresses. Additionally or alternatively, the first vehicle 12-1 or the first shuttle can also be assigned a specific network address 74. In the example of Fig. 3 A local IP address is selected, e.g., from the range "192.168.1.0" to 192.168.1.255". The specific network address 74-1 of the first vehicle 12-1 is "192.168.1.0".
[0077] In the first access area 68-1 of the Fig. 3 In addition to the first travel level 66-1, the fourth travel level 66-4 is already equipped with the shuttle or vehicle 12-4. This is expressed in Table 70 by the fourth data record or fourth row from the top. The fourth row contains the specific location address 54-4 (with the content "114"), to which the fourth station 14-4 and the fourth vehicle 12-4 are assigned. The fourth station 14-4 is assigned the specific network address 72-4 (192.168.0.3). The vehicle 12-4 is assigned the specific network address 74-4 (192.168.1.3).
[0078] The same applies to the fifth shuttle (see fifth row of Table 70 in Fig. 3 ) and the ninth shuttle (see ninth row of Table 70 in Fig. 3 ). Table 70 of the Fig. 3 It can also be seen that no vehicles 12 are (yet) assigned to the remaining driving levels.
[0079] An initial configuration procedure is described below. It should be understood that in practice, both the station ID 60 and the vehicle ID 52 will not be listed in ascending order in table 70. In practice, an operator 44 (e.g., a mechanic) will randomly distribute the stations 14 and the vehicles 12 across the rack levels RE.
[0080] The aim of the configuration is to create table 70 of the Fig. 3 to complete, in particular, to reliably assign a specific location address 54 to each vehicle 12. This means, in particular, that the vehicles 12 are reliably assigned one of the locations, i.e., one of the specific location addresses 54. This assumes that the assignment between the specific location addresses 54 and the stations 14 has already been (reliably) made. This means that the stations 14 have already been reliably assigned their respective locations or assigned travel levels 66 in the form of the specific location addresses 54.
[0081] The task of the operator 44 is then to equip the (empty) travel levels 66 with vehicles 12 by assigning the correct specific location addresses 54 to the vehicles 12 newly inserted into the rack aisle 22-1 or into the empty travel levels 66.
[0082] The specific location addresses 54 define driving areas or movement areas of the vehicles 12. In general, at least one station 14 is assigned to each driving area, so that a location for a vehicle 12 newly inserted into the lane 22 can be assigned via the specific location address 54 of the corresponding station 14.
[0083] To completely fill access area 68-1, two additional vehicles 12 must be inserted into travel levels 66-2 and 66-3. For this purpose, operator 44 moves to the first access area 68-1. As soon as operator 44 arrives there, operator 44 can signal the (higher-level) system controller 16, e.g., using the data terminal 42 carried along, that a new vehicle 12 should be inserted, e.g., into the second rack level RE2.
[0084] The system controller 16 can then cause the already installed vehicles 12-1 and 12-4, for example, to drive to their (charging) stations 14 and remain there. As soon as the vehicles 12-1 and 12-4 have arrived at their charging stations 14, these vehicles 12 are charged. The system controller 16 detects the corresponding charging currents or voltages present at the power supplies 56 (see FIG. Fig. 1 ) of this station 14. These charging currents or charging voltages represent changes in the state of the respective stations 14.
[0085] The stations 14 are each set up to provide (specific) status signals 76 (cf. Fig. 2 ) to the higher-level system controller 16. These status signals 76 are (station-)specific, because, for example, the associated station ID 60 (cf. Fig. 4 ) is transmitted. The transmitted station ID 60 enables identification of the transmitting station 14. In other words, this means that each specific status signal 76 can be uniquely assigned to one of the stations 14.
[0086] The system controller 16 is therefore able to detect whether and when the vehicles 12-1 and 12-4 are in contact with their respective charging stations 14.
[0087] Once this has happened, the operator 44 is authorized to enter the access area 68-1 in order to load the second rack level RE2 or the second travel level 66-2 and the third rack level RE3 or the third travel level 66-3 with a vehicle 12 each. In the following, it is assumed that the operator 44 first loads the second travel level 66-2 with a vehicle 12.
[0088] As soon as a vehicle 12, which the operator 44 can select from a pool (not shown), is located on the second driving level 66-2, the operator 44 can establish a data connection to this vehicle 12 using their data terminal 42. The connection can be made via the cable 46 or wirelessly. As soon as the vehicle 12 and the data terminal 42 are connected to one another, the system controller 12 can be signaled that the vehicle 12 is ready for configuration. This information includes, in particular, the vehicle ID 52 (logical address) of the corresponding vehicle 12. The vehicle ID 52 can either be entered manually by the operator 44 or automatically read from the vehicle memory 26 by the vehicle controller 36 and transmitted to the system controller 16.
[0089] Furthermore, the specific location address 54 belonging to the second travel level 66-2 is transmitted to the system controller 16 as the desired location address. The specific location address 54-2 belonging to the second travel level 66-2 is "112." This desired location address 54 can, for example, be manually entered into the data terminal 42 by the operator 44 or read using a handheld scanner, in which case the travel level 66-2 is provided with a unique corresponding barcode, for example.
[0090] As soon as this information is available to the system controller 16, the system controller 16 initiates an interaction between the vehicle 12 to be configured and the station 14 assigned to this travel level 66-2. In the present example, this is station 14-2. Since station 14-2 is a charging station, the interaction is defined as a charging process. The operator 44 has therefore positioned the vehicle 12 to be configured on the (charging) station 14-2 of the travel level 66-2.
[0091] To make the charging process clearly identifiable, the system controller 16 also causes the vehicle 12 to be configured to be discharged below a predetermined threshold value. This can be done, for example, by the operator 22 connecting a discharge resistor 78 (see FIG. Fig. 2 ) is plugged into the vehicle 12 to be configured or a built-in discharge resistor is activated. As soon as a desired discharge threshold is reached, the system controller 16 can initiate recharging and begin monitoring the statuses of all (charging) stations 14. However, since only the vehicle 12 to be configured has been discharged below the defined threshold, this means that the other vehicles 12 are all less discharged. Therefore, the specific status signal of this charging station is characteristic.
[0092] Characteristic generally means that the status signal 76 of this station 14 differs significantly from the (specific) status signals 76 of the other stations 14. Thus, the system controller 16 is able to precisely verify which of the stations 14 is currently operating with the vehicle 12 to be configured.
[0093] Therefore, the system controller 16 is also able to check whether the station 14 providing the characteristic status signal 76 is the same station 14 assigned to the driving level 66-2 to be configured. This comparison is performed via the specific location address 54. In other words, this means that if the specific location address 54 of the station 14 selected for charging matches the specific location address 54 of the station 14-3 providing the characteristic status signal 76, the vehicle 12 to be configured has been placed in the correct driving level 66. If the vehicle 12 to be configured has been placed in an incorrect driving level 66, charging will occur via the incorrect station 14. In this case, the specific location addresses 54 do not match.
[0094] The initial configuration of the vehicles 12 described above results in initial pairing data, which is defined by the mutually assigned location addresses 54 and vehicle IDs 52. During the initial configuration, for example, the vehicle 12-1 and the system controller 16 establish a communication connection with each other. As long as this connection exists, which can be verified by both the vehicle 12-1 and the system controller, for example, based on periodically exchanged status signals (e.g., the "heartbeat" function in "Profisafe"), the vehicle-location assignment is also reliably established.
[0095] This "secure" assignment is maintained even if the communication connection between vehicle 12 and system controller 16 is temporarily interrupted. When using Wi-Fi for communication, for example, a temporary interruption can result from shadowing effects caused by metallic shelving components or from dead spots. Vehicles 12 and the system controller each have a timer to record the duration of the communication interruption.
[0096] Depending on the duration of an interruption, different processes are carried out. In the event of a brief communication interruption (e.g., less than 20 seconds), operation of vehicle 12 continues without safety being considered at risk. In the event of a longer interruption, conventional vehicles switch to a so-called STO mode (STO: safe torque off, see EN 60204), which immediately interrupts the power supply to the drive. In this case, the drive is shut down without control. After shutdown, the drive can no longer generate any torque, including braking torque, so that undesirable coasting occurs. The conventional vehicle stops somewhere in the rack aisle. To resume operation, the maintenance mechanic must enter the rack aisle and manually restart the conventional vehicle, possibly including a new initial configuration.This is the only way to ensure safety.
[0097] In the present disclosure, in the event of a prolonged communication interruption, the vehicles 12 are switched from a normal (automatic) operating mode to a rescue mode. In rescue mode, the vehicles 12 return independently, i.e., automatically, to their charging station 14 and remain there until the communication connection is re-established.
[0098] Since the vehicle 12 is already initially configured, the corresponding data is permanently stored in a (fixed-value) area of the memory 26 of the vehicle 12. In this case, the vehicle 12 has at least one piece of information that expresses its location address. A vehicle 12 that has not yet been initially configured does not know its location address. A vehicle 12 with an error may not (or no longer) know its location address or may not be certain that the stored location address is correct. In these cases, it is not possible to (re-)establish a secure connection between this vehicle 12 and the system controller 16. Again, manual intervention is required to ensure the required security.
[0099] In rescue mode, the initially configured vehicle 12 is located at its assigned charging station 14 and waits for the connection to be reestablished. If this vehicle 12 can supply itself with its own power during this time, there is no concern that the data stored in the vehicle, in particular its location address 54, could be incorrect. As soon as power is restored, the communication connection can be established, and operation of the system 10 can resume without the vehicles 12 having to be reconfigured.
[0100] Furthermore, the verification process described above is repeated. The vehicles 12, all of which are currently at their charging stations, are instructed one after the other to discharge below a predetermined threshold and then recharge, resulting in the characteristic status signal (charging current) of the corresponding charging station 14, so that the location address comparison described above can be performed for the corresponding vehicle 12 and the corresponding charging station 14. In this case, the system 10 can be safely restarted—despite a (prolonged) power outage—without requiring manual interaction. The restart occurs automatically (and safely).
[0101] The flow chart of the Fig. 4 illustrates a method for restarting an automated warehouse system 10 having a plurality of energy-autonomous vehicles 12 operating in the racking arrangement 18 and already configured, wherein a configuration of a respective vehicle 12 includes initial pairing data comprising a (unique) identifier 52 of the vehicle 12 and a location address 54 of the vehicle 12 that have been (initially) assigned to each other in advance.
[0102] Although the following description of the procedure Fig. 4 only a single vehicle 12 is considered, it is understood that the description applies to all vehicles 12 in the system 10.
[0103] In a step S10, the vehicle 12 checks, using its controller 36, which may comprise, for example, a CPU or a microcomputer that accesses corresponding procedures stored in the vehicle data memory 26 in the form of programs, whether communication between the vehicle controller 36 and the system controller 16 has been interrupted for longer than a predetermined period of time T1. It is understood that the vehicle controller 36 may alternatively or additionally be implemented by ASICs (application-specific integrated circuits) or the like. The vehicle controller 36 is generally implemented by software, firmware, and / or hardware.
[0104] Furthermore, it is assumed that communication between the vehicles 12 and the system controller 16 takes place via a wireless local area network (e.g., Bluetooth, WLAN, 5G, or similar). This is a local radio network with sufficiently high transmission power and range to ensure controlled operation of the vehicles 12 within the rack arrangement 18. The operation of the vehicles is controlled by the higher-level system controller (16). The vehicles 12 typically do not perform any action without authorization from the system controller 16.
[0105] Communication is wireless because the vehicles 12 are energy-autonomous, so there is usually no physical connection between the vehicle controller 36 and the system controller 16. The physical connection can exist, for example, when the vehicle 12 is positioned at the charging station 14 (information modulated to the charging current). During normal operation, however, the vehicle 12 is not positioned at the charging station 14, but rather stores and retrieves the stored goods by driving the vehicle 12 to the corresponding shelf locations according to transport orders that originate from a material flow computer and are communicated to the vehicles 12 via the system controller 16.
[0106] In conventional automated warehouse systems with energy-autonomous vehicles, the predetermined time period T1 is typically 20 seconds. If a communication interruption lasts longer than 20 seconds, the conventional vehicles are put into the aforementioned STO mode, so that their drives are switched off without torque.
[0107] However, the present disclosure typically selects a longer time period T1, particularly to enable a reboot of the wireless network. Rebooting a WLAN access point (e.g., router, not shown) currently takes approximately 35 seconds. This time period depends on the type of components used to establish the local wireless network. In the present example, the time period T1 is therefore preferably 35 seconds.
[0108] As long as the time period T1 has not expired, vehicle 12 continues its (automatic) operation. This means, in particular, that the execution of transport orders for the storage or retrieval of stored goods continues.
[0109] If the communication interruption lasts longer than the predetermined period T1 (YES in step S10), the vehicle 12 switches to the rescue mode mentioned above. In rescue mode, the vehicle 12 performs a rescue trip to its charging station 14 (step S12). The vehicle 12 knows its current X-position within the rack aisle 22. Furthermore, the vehicle 12 knows the X-position of its charging station 14 (reference point or home position). This information is stored in the data memory 26 of the vehicle 12. The (current) X-position of the vehicle 12 is periodically updated, e.g., by the vehicle controller 36 evaluating corresponding information from the drive of the vehicle 12.
[0110] The rescue trip interrupts the execution of a current driving task, which is also stored in the data memory 26 of the vehicle 12. The cancellation of the driving task can be logged in the data memory 26 of the vehicle 12 (step S14). Logging is optional, and the corresponding data is also stored in the vehicle's data memory 26.
[0111] After a second predetermined time period T2 has elapsed, the operating mode of the vehicle 12 of the present disclosure changes at the latest (and always) from rescue mode to the conventional STO mode. The second predetermined time period T2 is dimensioned such that the vehicle 12 can travel safely to its charging station 14 regardless of its current X-position. The time period T2 can, for example, be dimensioned such that the vehicle 12 can travel at a predetermined (rescue) speed from one end of the rack aisle 22 to the other end of the rack aisle 22, i.e., can travel through the full length of the rack aisle. In the present disclosure, the time period T2 is, by way of example, 41 seconds in order to be able to travel safely through a rack aisle 150 m long.
[0112] After the second time period T2 has elapsed, the vehicle is, under normal circumstances, located at its charging station 14. Under normal circumstances, the vehicle 12 also still has sufficient energy in its energy storage unit 38 to store the current X-position in its data storage unit 26. In this case, the current X-position of the vehicle 12 corresponds to the X-position of the charging station 14. This can be queried in a step S18.
[0113] If the query in step 18 reveals that vehicle 12 is not at its charging station 14, this vehicle 12 should not be automatically put back into operation. This vehicle 12 has an error because it is not at its charging station 14 despite taking into account tolerances (e.g., distance and time) and reserves (e.g., energy). In this case, this vehicle 12 must be inspected more closely.
[0114] Preferably, the system controller 16 waits for a further third predetermined time period T3 before access is granted so that the maintenance technician can also physically enter the corresponding access area 68 to inspect the faulty vehicle 12 (step S20). In this case, the maintenance technician moves the faulty vehicle 12 to its charging station 14 (recovery), preferably initially configures the vehicle 12, and then leaves the access area 68 again. The duration T3 is, for example, 25 s, which corresponds to the maximum time that the vehicle 12 requires to come to a stop with a torque-free drive because no active brake is present. The maintenance technician can therefore safely enter the rack aisle after approximately 100 s (T1 + T2 + T3) at the latest, see also Fig. 5 .
[0115] If the query in step S18 shows that the vehicle 12 is positioned on its charging station 14 (YES in step S18), an (optional) condition for an automated restart of the system 10 is met.
[0116] In step S22, the vehicle 12 checks whether the (residual) energy remaining in the energy storage device 38 has fallen below a critical threshold after the rescue trip. The critical energy threshold is determined by whether sufficient energy is still available in the vehicle 12 to keep the vehicle controller 36 alive, restore the communication connection with the system controller 16, and exchange data for a pairing process.
[0117] If the power supply remains interrupted, the communication connection cannot be restored and the energy storage device 38 cannot be charged, even if the vehicle 12 is at its charging station 14. Under these circumstances, the vehicle 12 discharges over time. If the query in step S22 reveals that the energy has fallen below the critical threshold, the vehicle 12 deletes all data from its (volatile) RAM. This ensures that the vehicle 12 cannot be removed from its driving level and placed in a different driving level and then still assume that it is in the original driving level. In this case, the pairing process described below cannot be carried out by a simple acknowledgment at the level of the system controller 16. In this case, the vehicle 12 must be initially configured (manually).
[0118] However, if the query in step S22 reveals that sufficient energy is still available (NO in step S22), the vehicle 12 periodically checks whether the communication connection with the system controller 16 has been restored. This check is repeated as long as (vehicle) energy is available or until the communication connection is restored.
[0119] If the communication connection is restored (YES in step S24), the vehicle controller 36 and / or the system controller 16 checks whether initial pairing data is stored in the vehicle 12 (step S26). This data can be stored in a (volatile) working memory of the vehicle if the vehicle was permanently powered during the general power outage. Alternatively, this data can be stored in the non-volatile part of the data memory 26 of the vehicle 12 if the energy storage of the vehicle 12 was completely depleted (see steps S22 and S23).
[0120] If this check reveals that no initial pairing data is present (NO in step S26), a manual initial configuration is required to allow the vehicle 12 to switch back to automatic operation.
[0121] However, if the check reveals that initial pairing data is stored in the vehicle (YES in step S26), the vehicle 12 requests authorization from the system controller 16 (step S28). In particular, the vehicle 12 informs the system controller 16 of its vehicle ID 52 and its location address 54 (initial pairing data).
[0122] In step S30, the system controller 16 generally checks whether there are any release requests from vehicles 12. The release is required to end the STO mode (see step S16). Whether the release can be granted without manual inspection by the maintenance technician can be determined by whether the (reawakened) vehicle 12 is located at its charging station 14 or not (see step S18). If the vehicle 12 is located at its charging station 14, the system controller 16 can be certain that the rescue trip was carried out correctly and can issue the release based solely on the reported X-position of the vehicle 12 to end the STO mode.
[0123] The pairing process is complete when communication is re-established and the system controller 16 has granted approval (step S34). It should be noted that the charging station 14 itself does not necessarily have to be (already) supplied with power at this time. It is possible that the communication connection is established first and the pairing process is carried out before the charging stations 14 are also re-energized. It is also possible that the vehicles 12 (in automatic mode) are already executing driving tasks again even though the charging stations 14 are not (yet) re-energized. In this case, it is only important that the vehicles 12 have sufficient energy to complete the driving task and return to the respective charging station 14, as is the case during normal operation.
[0124] If a release request is received (Yes in step S30), the system controller 16 can further verify the transmitted initial pairing data (step S32), in particular by running the procedure described above using a characteristic status signal from the assigned charging station 12. This means that the vehicle 12 is specifically discharged and then recharged in order to check the location address stored in the vehicle against the location address for the charging station 14 stored in the system controller 16, as already described above for the initial configuration. If the location addresses match, the system controller can be sure that the data is correct. This increases overall security. The vehicle 12 can be put back into operation automatically.
[0125] However, the release (step S34) can also be carried out by the system controller 16 based on other criteria (e.g. by manual acknowledgment in a master control system).
[0126] The release is sent from the system controller 16 to the corresponding vehicle 12. The pairing process is then complete. The vehicle 12 switches back to automatic mode (step S36). In automatic mode, the vehicle 12 can receive new driving orders, which it then executes automatically.
[0127] Fig. 5 illustrates the time sequences again using an example. After approximately 100 seconds, each vehicle 12 is safely parked (either on its charging station 14 or faulty somewhere in rack aisle 22), so that a mechanical access protection (safety door lock) can be removed to allow the maintenance technician access to rack aisle 22. Bezugszeichenliste:
[0128] 10Storage system or "System" 12Vehicle 14Station 16System controller 18Shelf arrangement 20Shelf 22(Shelf) aisle 24Data processing device 26(Data) memory 28(Communication) interface (I / O) 30Cable 32Wireless connection 34Bus system 36Vehicle controller 38Energy storage device 40Load handling device (LHD) 42Data terminal 44Operator 46Cable 48Display 50Input device 52Vehicle ID 54Specific location address 56Power supply unit 58Light barrier 60Station ID 64Shuttle 66Travel level 68Access level 70Assignment table 72(Station)-specific network address 74(Vehicle)-specific network address 76(Station)-specific status signal
Claims
1. An automated storage system (10) including: a rack arrangement (18) including two racks (20), which define a rack aisle (22) between them, wherein the racks (20) comprise multiple rack levels (RE) vertically on top of each other; energy-autonomous vehicles (12) arranged in the rack aisle (22) on the rack levels (RE) and being horizontally movable for automatically storing and retrieving storage goods, wherein each of the rack levels (RE), where one of the vehicles (20) is provided, is equipped with a charging station (14), wherein each of the vehicles (12) is initial-configured and comprises a vehicle control (36), an energy storage (38), and a data storage (26); a system control (16) communicating with each of the vehicle controls (36); and an assignment table (70), which is stored in a data storage (26) of the system control (16) and which includes initial-pairing data including mutually assigned location addresses (54) and vehicle-specific identifiers (52); wherein each of the vehicle controls (36) is configured: to cause the corresponding vehicle (12) to switch into an autonomous rescue mode and to automatically move to an assigned charging station (14), if communication between the corresponding vehicle control (36) and the system control (16) has been interrupted for longer than a first predetermined time period T1; and to initiate a pairing process as soon as the communication with the system control (16) is restored, wherein the pairing process is performed based on initial-pairing data including a location address and an identifier of the respective vehicle (12), which are fixedly and uniquely assigned to each other, and being stored in a permanent memory of the vehicle.
2. The automated storage system (10) of claim 1, wherein the pairing process is initiated as soon as the communication with the system control (16) is restored and as soon as supply of the respective vehicle (12) with energy via the charging station (14) exists.
3. The automated storage system (10) of one of claims 1 to 2, wherein the communication is wireless, preferably via WLAN.
4. The automated storage system (10) of any one of claims 1 to 3, wherein the data storages (26) of the vehicles (12) respectively comprise a non-volatile area for storing the initial-pairing data and a volatile area for processing by the respective vehicle control (36).
5. The automated storage system (10) of any one of claims 1 to 4, wherein the energy storages (38) of the vehicles (12) respectively comprise a fast-charging energy storage for energy to move the respective vehicle (12) and a backup-energy storage for energy to maintain stored data and to execute emergency functions by the vehicle control (36).
6. A method for restarting an automated storage system (10), which comprises multiple energy-autonomous vehicles (12) operated on rack levels (RE) of a rack aisle (22) of a rack arrangement (18) and being initial-configured, wherein each of the rack levels (RE), where one of the vehicles (12) is provided, is equipped with a charging station (14), wherein the method comprises the steps of: checking (S10), by a respective vehicle (12), whether communication between a vehicle control (36) of the respective vehicle (12) and a system control (16) of the storage system (10) has been interrupted for longer than a first predetermined time period T1, wherein an assignment table (70) is stored in a data storage (26) of the system control (16), and wherein the assignment table (70) includes initial-pairing data including mutually assigned location addresses (54) and vehicle-specific identifiers (52); if the communication has been interrupted for longer than the first predetermined time period T1, the respective vehicle (12) switches into an autonomous rescue mode and automatically moves (S12) to the charging station (14), which is assigned in advance to the vehicle (12) from the plurality of charging stations (14); and initiating a pairing process (S28) as soon as the communication is restored, wherein the pairing process is performed based on initial-pairing data stored permanently in a data storage (26) of the respective vehicle (12), and wherein an initial configuration of the respective vehicle (12) comprises the initial-pairing data including an identifier of the respective vehicle (12) and a location address of the respective vehicle (12) which have been initially assigned to each other.
7. The method of claim 6, wherein the pairing process is initiated as soon as the communication is restored and as soon as supply of the vehicle (12) with energy via the charging station (14) exists.
8. The method of claim 6 or 7, wherein the step of initiating a pairing process includes that the respective vehicle (12) performs a characteristic interaction with its assigned charging station (14) and compares the location address of the respective vehicle (12) with a location address assigned to the corresponding charging station (14), which delivers a characteristic state signal in response to the characteristic interaction of the respective vehicle (12).
9. The method of any one of claims 6 to 8, wherein the respective vehicle (12), after expiry of a second predetermined time period T2 following the first predetermined time period T1, switches into a non-driven operation mode.
10. The method of any one of claims 6 to 9 further comprising: periodically checking whether the communication between the respective vehicle control (36) and the system control (16) has been restored after the interruption.
11. The method of claim 10 further comprising: requesting a release signal, by the respective vehicle control (36), from the system control (16) after the communication has been restored.
12. The method of any one of claims 6 to 11, wherein communication interruption is logged by the respective vehicle (12) in its data storage (26).
13. The method of any one of claims 6 to 12 further comprising: checking whether the respective vehicle (12) is positioned on the charging station (4) assigned in advance, after the respective vehicle (12) has switched into the rescue mode.