REMOTE CONTAINER HANDLING SYSTEM
FIELD OF THE INVENTION
This invention relates to a remotely controllable handling system, of particular but by no means exclusive application in the handling of containers .
DESCRIPTION OF THE PRIOR ART
Existing container handling systems employ various forms of transport and cranes, including prime movers (PMs) , automated guided vehicles (AGVs) , straddle carriers, fork lifts and yard cranes. Generally, however, each existing system employs a combination of yard container handling cranes (for container movements within container stacking yards) and ground vehicles (or one or more kinds) for moving containers to or from those yards . Each crane and vehicle requires a driver.
In one prior art system, the number of crane drivers is somewhat reduced by locating a driver between or near a pair of cranes, with a direct line-of-sight both of the pair of cranes and of the containers to be moved by those cranes . The cranes are then controlled by the driver from a portable controller connected by wireless means to each crane, by means of which the driver can control each crane in tur .
However, existing combinations of these practices require a large number of drivers, as each crane and most ground vehicles must be manned at essentially all times, which leads to high standby times and, as a result, low individual productivity. Wage, recruitment and training costs are high, and some systems — being labour intensive — require considerable logistic support in the form of employee transport and meal delivery. Further, the high level of human involvement inevitably leads to human errors, causing the incorrect inventory of containers, due
to errors in stacking containers and positioning machinery, and inflexibility in the planning of operations in the stacking yard.
Existing attempts to overcome such problems have essentially been in the form of stream lining of operational procedures and improved yard planning.
Some attempts have been made to control the cranes remotely, employing radio frequency communications links. However, these systems are costly owing to the limited bandwidth of the rf communications networks, and still typically required one driver per crane.
Further, existing yard cranes commonly run on rubber types which flex differently according to load leading to large variations in gantry position during any extended period of use. As automation typically requires precise and repeatable motion, this feature of the cranes has impeded any attempt to introduce automation in this field.
Finally existing cranes do not have standardised control systems, which has further inhibited development in this area.
SUMMARY OF THE INVENTION
It is an object of the present invention, therefore, to provide a remotely controllable container handling system.
The present invention provides a container handling system comprising: a plurality of yard cranes for moving said containers ; control means for controlling said cranes and located remotely therefrom; communication means for providing two way communication between said control means and each of said
plurality of cranes; wherein said control means is operable by a single operator to control each of said plurality of cranes .
Thus , a single operator at a remote location can control more than one crane.
Preferably each of said cranes has one or more cameras , the output of which is displayable by said control means to said operator.
Preferably each of said cranes has one or more location sensors for sensing the location of said respective crane, and providing location data relating to said respective crane to said system. Optionally said location data is displayable by said control means to said operator so that said operator can ascertain of the location of said respective container, though the operator does not need to know where the container that he or she is presently handling is. Preferably said system is operable in response to said location data to move said respective crane if said respective crane is incorrectly located.
Preferably said system is operable to move a container between two locations specified by a yard plan. Preferably said yard plan is determined by said system.
Thus, rather than requiring to drive the crane so as to move a container between two locations, the system directs that a particular container (having a location) be moved to another location and, provided that these locations are valid, the system can perform the task without further intervention. The two locations may be one above the other, or in greatly separated parts of the container storage yard. In either case, however, the operator is not required to jockey a container over the entire distance the
container is to be moved: the system can perform the movement automatically, aided if necessary by the sensors. At most the operator will control the movement of the container at the beginning and/or end of the movement of the container, or should a situation occur outside the system's design parameters, such as an accident, an equipment failure or system error.
Preferably said system includes job assignment means for assigning jobs to said operator.
Thus, the system determines what job the operator (or each operator in a multi-operator system) should attend to next. Preferably, after completing one job, the operator indicates his or her readiness for the next assigned job
(for example, by selecting that specific job or indicating readiness for the next job on a control panel, or by indicating the completion of the previous job) .
Each operator is responsible, therefore, for a sequence of jobs assigned by the system, rather than for a specific crane.
Preferably said communication means is operable to transmit a plurality (and preferably all) control, video and sensor signals for a respective crane in a single circuit so that said signals are synchronized.
Preferably said communication means operates in asynchronous transmission or transfer mode. More preferably the communication means is operable to transmit signals in logical connections using the asynchronous transmission mode virtual path facility.
Thus, the mixing of signals from different cranes can be avoided, and significant delay between different signals, which could prejudice the system, can be eliminated.
Preferably, if each of a plurality of the desired handlings of containers is regarded as an individual job, said system is operable to queue said jobs so that said operator can attend to each of said jobs according to said queue. Thus, the operator can be presented with the jobs according to the sequence of the queue, rather than being required to select which job to attend to next.
Preferably said system includes queue determining means for determining said queue according to predetermined criteria. More preferably said predetermined criteria include minimising the total number of jobs and/or minimising the total time required to complete said jobs.
Preferably said system includes, for each of said cranes, a crane control interface, where each respective crane control interface is matched to its respective crane so that said operator can control each of said cranes in the same manner irrespective of variations in said cranes.
Preferably said control means includes a control panel having a single set of controls by means of which each of said plurality of cranes can be controlled by said operator.
Thus, a single set of controls, provided in the control means, can be used to operate different cranes even though those cranes may differ in construction and/or specification .
Preferably said communication means includes communication cables provided as a cable reel system, and more preferably said cables comprise optical fibre cables.
Thus, the bandwidth and interference problems associated with radio frequency communications are avoided.
Preferably said communication means is a broad band low delay network employing a synchronous transfer mode.
Preferably said communication means includes switching means for switching the crane to be controlled from a first crane to a second crane, whereby said system is operable to become responsive to or display the output of said cameras and also said sensors.
Preferably said system includes automated guided vehicles for handling containers beyond the range of said cranes . Preferably said automated guided vehicles employ magnetic field sensors .
Preferably said system is operable by said operator to interrupt, vary or intervene in the otherwise automatic movement by said system of a container.
Thus, an operator can intervene in, vary or terminate the movement of a container between two specified location, and may observe the progress of that movement by means of the aforementioned cameras and/or sensors .
Preferably each of said plurality of cranes is provided with wheels for rail mounting, and more preferably said system includes rails whereby each of said plurality of cranes is rail mounted.
By using rail mounted cranes, there is less variation in the position of the cranes according to load.
BRIEF DESCRIPTION OF THE DRAWING
In order that the present invention may be more clearly ascertained, a preferred embodiment will now be described, by way of example, with reference to the accompanying drawing, in which:
Figure la is a schematic view of a container handling system according to a preferred embodiment of the present invention;
Figure lb is a view of an example of a container terminal at which the container handling system of figure la;
Figure lc is a schematic diagram of the overall remote operation system (ROS) architecture of the system of figure la; Figure 2a is a process diagram of the operation of the system of figure la;
Figure 2b is a flow chart of the off-loading of a container onto an OHBC yard during remote operation in the system of figure la; Figure 2c is a flow chart of the mounting of a container from an OHBC yard during remote operation in the system of figure la;
Figure 3a is a schematic view of the yard block server and associated subsystems of the system of figure 1; Figure 3b is a schematic view of the yard block server of the system of figure 1;
Figure 4 is a schematic view of the crane control interface of the system of figure la;
Figure 5a is a schematic representation of the relationship between the communication network and various components of the system of figure la;
Figure 5b is a schematic CVSS Communications Flow Diagram on System (Active) of the system of figure la;
Figures 5c and 5d are a pseudo-code representation of the Request Processor Module of the system of figure la;
Figure 6 is a view of the remote operator console (ROC) of the system of figure la;
Figure 7a is a system interaction diagram for the scenario in which a prime mover has arrived for offloading of containers during remote operation according to the system of figure la;
Figure 7b is a system interaction diagram for the scenario in which a prime mover has arrived for mounting of containers during remote operation according to the system of figure la; Figure 7c is a system interaction diagram for the scenario in which the Remote Supervisor Console (RSC) requests full control over a OHBC (possibly for searching for containers) according to the system of figure la;
Figure 7d is a system interaction diagram for the scenario in which an exception occurs during offloading of containers (stack profile mismatch) according to the system of figure la;
Figure 7e is a system interaction diagram for the scenario in which an exception occurs during the mounting of a container (stack profile mismatch) according to the system of figure la;
Figure 8a is a schematic view of crane coverage in a linear stretch of yard blocks in an example; and
Figure 8b is a schematic view of crane response time in an example.
DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT A container handling system according to a preferred embodiment of the present invention includes a remote control operation centre (RCOC) as illustrated schematically at 2 in figure la. It is envisaged - and the following description assumes - that the system 2 will be employed at a container terminal located at a quayside, though clearly it could be employed in essentially any container handling facility. The system 2 includes a remote control operation centre 3 for controlling container movements in a container yard 4. The yard 4 comprises a linear stretch of yard blocks 5. The system 2 also includes a yard block server 10 for managing and controlling all activities at the yard 4, and an integrated communication network 8a,b,c linking the remote control operation centre 3, the yard 4 and the yard block server
10. Although the following description refers to one yard block server 10 for managing and controlling all activities in one yard 4, it will be understood that a facility generally includes several essentially identical yard block servers, each for managing and controlling the activities of a separate yard.
Additional communications links 8b and 8c are provided between the yard block server 10, and yard 4 and remote control operation centre 3 respectively.
An example of such a container terminal is shown in figure lb, in which the system is deployed at a quay 6 at which container ships 7 are docked for loading and unloading. Yard blocks 5a, 5b and 5c are located near the quay 6; yard blocks 5a include eight OHBCs , yard blocks 5b four OHBCs and yard block 5c six OHBCs. Figure lc is a schematic diagram of the overall remote operation system (ROS) architecture of the system of figure la: each component shown in this figure and its function is described below.
The system 2 also includes an automatic crane control system (ACCS) , for controlling individual OHBCs according to the commands of the yard block server 10. Further, the system 2 includes a job monitoring and allocation system
(JMAS) (not shown) for tracking all container movement jobs and allocating each such job to an OHBC and/or operator as required.
In broad terms, all OHBCs in the various yard blocks 5 are controlled remotely and automatically by yard block server 10 via the ACCS, except at more critical phases of container handling by an OHBC when operator intervention is required. At such times, an operator at remote control operation centre 3 assumes remote control of that OHBC.
The allocation of OHBC and operator resources is determined by the JMAS.
Figure 2a is a process diagram of the operation of the system, and shows the interaction between a prime mover 12 and OHBC/ACCS combination 14, a remote crane operator 16, 5 the yard block server 18 and the JMAS 20.
When a primer mover 12 arrives 22 at a yard slot for mounting operations, the yard block server 18 assigns 24 an OHBC to service that prime mover 12. The yard block server
10 18 then sends 26 commands to the ACCS 14 to gantry the OHBC into position. The ACCS gantries 28 the OHBC to the correct slot, then the yard block server 18 sends 30 commands to the ACCS to pick up the container from the stack . The ACCS/OHBC picks up 32 the container from the
15 yard stack, and the yard block server 18 sends 34 commands to the ACCS to trolley to the primer mover chassis lane. The ACCS/OHBC trolleys 36 to the prime mover chassis lane and lowers the spreader of the OHBC to a predetermined safety height, at which point the yard block server 18
20 informs 38 the JMAS to select a remote operator. The JMAS 20 selects 40 an available console and establishes video and data link by means of a control and video switching system (CVSS) (not shown: see discussion below) . Thus, the remotely located crane operator 16 assumes control of the
25 OHBC and lowers 42 the container onto the prime mover. The operator then lifts 44 the empty spreader to the safety height and signals 12 completion, which prompts the JMAS to disconnect 46 the video and data links from that operator's console.
30.
Figures 2b and 2c are, respectively, flow charts of the off-loading of a container onto and mounting of a container from an OHBC yard during remote operation according to system 2. In these figures, C3I" refers to "Command,
35 Control, Communication and Intelligence", the container terminal operational control room.
Referring to figures 3a and 3b, the system 2 includes, at a more detailed level, a yard operation system 54, a yard space manager 56, overhead bridge crane PC 58 (representing one of plurality of such OHBC PCs, one for each OHBC), a yard planning system 60, an automatic crane control system 64 , a computer aided maintenance management system 66 and the JMAS 68.
The yard block server 10 includes several modules: a yard profile module 70, a yard inventory module 72, a job allocation module 74, a local job control module 76, a crane controller module 78, a crane allocation module 80, a remote job control module 82, and a breakdown detection module 84.
Each of the OHBCs of the system 2 is equipped with cameras, the output of which can be displayed to an operator located in the control centre 3, as well as location sensors. The location sensors provide the system 2 with location data relating to that OHBC; this data can be used either by an operator to locate an OHBC, or by the system 2 when necessary (as discussed below) .
The OHBCs run on rails, to minimize variation in their attitude under load, and the system includes communication means in the form of a broad band low delay network employing a synchronous transfer mode, and transmitted over optical fibre cable reel system between each OHBC and fixed cable communication links 8a and 8b. The use of optical fibre cables obviates bandwidth and interference problems.
All communications (including control, video and sensor signals) with any particular OHBC, however, are transmitted in a single circuit. This is principally to avoid the mixing of signals from different cranes, but also so that that the signals from any one crane are synchronized, to eliminate as far as possible delay between different
signals .
Job and crane allocation modules 74 and 78 constitute a queue determining system, for determining the most appropriate order in which jobs should be performed, and by which crane.
A key component of the system 2 is the ACCS 64 which is provided by the yard block server 10 with stack profile information, as well as information concerning jobs, OHBC movements, etc, so that each OHBC can be controlled automatically by the system 2 and the remote operator manning the remote console in the control centre is only required intervene in the movement of a container to lower the container from a predetermined safety height onto the prime mover chassis, or optionally to pick up the container to the safety height. The ACCS 64 handles all gantrying of the crane to the correct slot in the yard. For mounting operations, an OHBC picks up a container from the container stack and brings it to the chassis lane above the parked prime mover. For off-loading operations, the OHBC brings the container to the safety height above the prime mover chassis and stacks the container into the stack, with only this last step requiring remote operator control.
Thus, in normal use the ACCS 64 attends to jobs until manual intervention is required, at which point the yard block server 10, which interacts with the ACCS 64, indicates the required operator intervention to the job monitoring and allocation system 68, for mounting and offloading. The JMAS 68 in turn assigns a remote console to allow intervention by a remote operator. Operator intervention may also be indicated should any form of error condition, equipment failure, emergency, etc. be detected, at which point the operator can interrupt or intervene in the movement of a container.
The remote console comprises a standardized interface from which two or more OHBCs can be controlled in turn; the interface is independent of the type of OHBC being handled. This is accomplished by providing each OHBC with a crane control interface (see below) that can accept standardized signals from the control centre 3 (converting them as necessary into the requirements of the particular OHBC) and converting OHBC outputs into the standard format of the system 2. The operator is thus relieved of having to use different interfaces depending on the type of OHBC in use, and pay full attention to the actual job.
The system 2 can switch the operator interface between different OHBCs according to the job, thereby switching all controls and camera/sensor data accordingly. This switching is performed as each job is completed, and the next job in the queue (as determined by the system 2) is then switched to the operator console.
The yard planning system 60 constitutes a central source of yard profile information for the yard block server 10. This information is transmitted 61 to the yard block server 10 and stored in the yard profile module 70 within yard block server 10, in the form of a copy of the profile of various yard blocks in the yard. All updates of yard profile information in the yard planning system 60 are automatically transmitted to the yard profile module 70 and made available to users .
The yard profile information includes the dimension of each yard block, as well as the various characteristics of each block, including, for example, the location of 45' slots, locations of OHBC columns and location of concrete maintenance areas. This information is required by the yard allocation and crane control functions of the yard block server 10.
The yard space manager 56 transmits 57a container details to the yard block server 10, including a yard inventory at yard block server 10 start up. Further, details of any movements of a container performed manually are transmitted 57b by the yard block server 10 to the yard space manager 16. This information, collectively, constitutes a yard inventory which is retained in a yard inventory module 72 within the yard block server 10. Further, this information, owing to the accurate capture of all OHBC movements, can be used to provide an accurate stack profile, which can be used to verify the OHBCs internal stack profile as a safety measure for the unmanned operation of the OHBC. The information in the yard inventory module 72 also ensures that containers are placed across a slot of uniform size. The yard inventory module 72 takes into consideration the yard characteristics provided by the yard profile module 70 and allocates the precise yard location for each OHBC move. The yard inventory module 72 is also responsible for providing the precise yard location of jobs to be handled and, for mounting jobs, provides the latest location in the yard of the particular container. If the mounting container required is not the top most in its stack, the yard inventory module 72 triggers appropriate moves to shuffle the overstowed containers to locations less likely to effect the original plans .
For off-loading jobs, the yard inventory module 72 allocates a suitable off-loading location within a yard range provided by the yard planning system 60. This allocation just prior to operation ensures that the location will be the most accurate based on the latest yard inventory information.
The crane controller module 78 provides an interface directly with a crane' s ACCS 64. The crane controller module 78 sends job instructions 65b to the ACCS 64, which
feeds back to the crane controller module information 75a on the crane's current status, location, etc.
The remote job module 82, for handling exceptions that occur or manual intervention that is required during remote crane operation. Should such a situation occur, a message containing the identity of the crane is sent 69b to the JMAS 68, at which point the crane will not accept any instructions or controls from the crane controller module of the yard block server 10. From this point on, until the exception is resolved, the crane only receives control from the remote control operation centre 3 (see figure la) . Once the remote handling is complete, the JMAS 68 notifies the yard block server 10, and the crane controller module can then resume the control of the crane. The system 2 includes a remote supervisor control console or RSC (not shown) in the remote control operation centre 3, which is the complete remote operator console with devices allowing one supervisor to remotely operate an OHBC and to supervise the operators in the remote control operation centre 3.
The supervisor can thereby override the normal operation of the system. Thus, if necessary the supervisor can switch the control of a particular crane to the supervisor console, or the allocation of a particular job from the console selected by the system to another console (including the supervisor console) .
The job allocation module 74 is for sending a (mounting) job 65b to a free OHBC when the yard block server 10 receives a signal (or job trigger) indicating that the prime mover (or other ground vehicle) has arrived at a slot. This signal provides the container location tracking information required by the system 2. When that ground vehicle is a prime mover, the driver signals that he or she has arrived at the slot by pressing a λPM ARIV" button at their terminal, indicating that the prime mover has docked. In those embodiments in which AGVs are employed, this
signal is generated automatically based on the continual tracking of the location of each AGV. When the yard block server 10 receives this information, it triggers the most appropriate job. The yard block server 10 communicates with the JMAS 68 and the remote control operation centre 3 to ensure that the correct prime mover has arrived at the slot.
Similarly, for off-loading jobs, the driver of a prime mover pushes a "PMGO" button at the quay site terminal, transmitting a signal to the yard block server 10 that indicates that the prime mover has left the quay. The automated job allocation module 74 determines the best location to off-load the discharged containers, and informs the yard operation system 54 and the driver of the prime mover .
Once there is a job for a crane to perform, the crane allocation module 80 is responsible for allocating the most appropriate crane to the job. In order to perform crane allocation, this module 80 is provided with details 67 of the status of all the cranes (including any maintenance, training plans, etc) by the computer aided maintenance and management system 66 and the crane controller module 78. An example of its operation is discussed below.
Finally, the break down detection module 84 is provided for detecting if the yard block server 10 is down and, if so, taking over the functions of the yard block server 10 without interruption of operations. A "peer" server is made responsible for the tasks of the yard block server 10, with peer alive signals 85b being received by the break down detection module 84, and alive signals transmitted from break down detection module 84.
The information transmitted from the various systems 54 , 56, 58, 60, 64, 66 and 68 to the various modules 70, 72,
74, 76, 78, 80, 82 and 84 of the yard block server 10 are summarized in the following table:
Messages are sent from the yard block server 10 to the other systems as information or to update certain attributes in their systems. Listed below are the important yard block server 10 output messages sent to other systems:
Figure 4 is a schematic view of the crane control interface referred to above. The remote operator's console 90 is connected to the systems integrated communication network or ICN 92 by means of a bi-directional serial link 94. Also connected to the integrated communication network 92 by means of bi-directional serial link 96, is the actual crane control interface 98. Interface 98 includes a generic control signal interface 100 connected by means of bi- directional parallel link 102 with a signal translation unit 104, itself connected by means of bi-directional parallel link 106 to a machine dependent interface and switch 108. The machine dependent interface and switch communicates by means of bi-directional parallel link 110 to the control circuitry 112 of an individual OHBC. The signals carried by bi-directional parallel link 110 comprise command and status signals for the OHBC hoist, spreader, trolley, gantry and (for quay cranes only) boom controls.
Thus, machine dependent signals received by interface and switch 108 are translated by signal translation unit 104 into a uniform set of signals so that signals outputted by the generic control signal interface 100 to the integrated communication network 92, or received by the generic
control signal interface 100 from the network 92 can be standardised and not dependent on the particular characteristics of the OHBC currently in use. The operator control 90 (and consequently the operator) need not, therefore, be conscious of the different types of OHBC being controlled from time to time.
It should also be noted that the integrated communication network 92 also functions as a communication interface 114, providing parallel/serial conversion 116 of command and status signals.
Figure 5a is a schematic representation of the relationship between the integrated communication network 92 , the JMAS 68, the console 90 (one of a plurality of consoles) and an OHBC 118 (again, one of a plurality of OHBCs) . The integrated communication network 92 comprises meshed Asynchronous Transmission Mode (ATM) switches and hubs. The function of the ICN is to transmit the video, control and data signals between container yard cranes and remote operator consoles .
The integrated communication network 92 includes a plurality of Intermediate Control Centres or ICCs (the ATM switches that give ATM access to each OHBC) 120 (one for each of the OHBCs), and a central hub/switch 122. The integrated communication network 92 also includes control and video switching system or CVSS 124, which communicates with JMAS 68 and ICCs 120.
Each OHBC 118 includes a DCC access hub 126, coupled to the cameras 128 and crane interface unit 98 of the respective OHBCs 118.
The CVSS 124 is an application server specifically for allowing the JMAS 68 to control the ICN 92.
The video, control and data signals are transmitted in logical connections using the ATM Virtual Path facility. This is to eliminate the possibility that the video, control and data signals from one container yard crane can be crossed with those from another container yard crane. Likewise, as this is a bi-directional connection, the control and data from the remote operator console cannot be crossed with those from another console.
The CVSS 124 provides a real-time switching function for the ICN 92 and so that, unlike in existing manual methods using a network management station in which each connection can take minutes to set up or take down, the remote operation system can make and take down connections within seconds to match the job rates handled. The CVSS 124 has been found to be able to handle 15 connections per minute.
Further, the CVSS 124 eliminates human error.
The CVSS 124 software operates in a continuous loop waiting for the JMAS 38 to send it instructions. When the CVSS 124 receives an instruction from the JMAS 38, it processes it to set up the connection between a remote operator console and the container yard crane.
The CVSS 124 resides in two workstations . One workstation is active and the other is on standby. The two workstations continuously exchange messages to keep each other up to date. In the event of the active workstation failing to operate, the standby workstation detects this and takes over its operation.
The CVSS 124 comprises the following five modules:
• Three main modules - Communication Module (CM) , Communication Ping Module (CMPING) and Request Processor Module (RPM) .
• Two auxiliary modules (Housekeeping/Maintenance) -
Maintenance Module (MM) , and the Communication Archive Module (CMARCV) .
The overall architecture is shown schematically in figure 5b.
The CM maintains the communication link with the JMAS 38, and is responsible for establishing and maintaining the network connections to the JMAS 68. It communicates with the JMAS 38 using the TCP/IP networking protocol and connection-oriented sockets .
The CM receives requests from the JMAS 68 and sends these to the RPM. It is always JMAS 68 that initiates communication with CVSS 124.
Once connections have been established with the JMAS 68, the CVSS 124, as a whole, then receives and processes JMAS requests .
The JMAS 68 and the CVSS 124 are processes that reside in two pairs of workstations or computers. Within one pair, only one will be active and the other acts as backup at any one time. There are thus four possible configurations of active and inactive machines.
These are linked over redundant Ethernet network links.
The CMPING Module regularly tests the communication links among these workstations to ensure prompt detection of any failed communication links, and sends update messages to the CM.
This is to activate backup processes whenever an active component fails.
The RPM is the key component in the CVSS 124 that actually
sets up connections .
The RPM handles the setting up and tearing down of virtual circuits for the video and control connections between a console and a crane. It does this by building up and invoking a script file, containing macro instructions that the ATM switch program can process. The ATM specification does not include a way of setting up and tearing down virtual circuits in real-time so, rather using the existing approach of manual set-up or provisioning, in the present embodiment uses the network management system itself.
The RPM receives messages from the CM program to establish or tear down virtual circuits. The RPM returns response messages to the CM to indicate the outcome.
The RPM program flow is described in pseudo-code format in figures 5c and 5d (in which the functions used do not have a one-to-one direct mapping to the actual code) . It should be noted that AMI is the software that resides in the ATM switch that responds to manual input. The RPM simulate the manual input using a text-based script file.
The CVSS 124 creates and updates files in disk storage as well as tables in system memory.
The Address File (ADF) contains information on the Video Boxes and ATM switches such as hostname, ATM port connection used, Virtual Path Identifiers, Virtual Circuit Identifiers, crane/console ID, etc. It maps the crane/console ID' s to their corresponding addresses and ports on the network. The combinations of all fields in the file are unique in that no two cranes/consoles would map to the same address. The RPM reads the ADF data into the Address Memory Table upon system initialization.
The Address Table (System Memory) is a copy of the Address
File kept and dynamically updated in the computer memory to reflect the current configurations .
The Connection File contains the status of all the consoles and any existing links to the cranes. This file is an image of the Connection Table and is over-written every time, the CT is updated or rebuilt. This is an output of the RPM and is used mainly for debugging purposes to show any existing links to the consoles.
Connection Table (System Memory) - This is a copy of the Connection File kept and dynamically updated in the computer memory to keep track of the video-to-console connections and the control-to-console connections when it becomes active.
The Audit Trail File is a file of all requests and response codes for diagnostics and trouble-shooting.
The main Data/message queue in system memory is the Request Queue (RQQ) , for allowing asynchronous operation of the Communication Module and the Request Processing Module.
Figure 6 is a view of remote operator console (ROC) 90. The console 90 includes a video monitor 132 for displaying both video images received from the cameras with which each OHBC is provided and information of use to the operator (such as the location of the OHBC, and the identification numbers of the prime mover or other ground vehicle, the container being moved, and the OHBC) . Console 90 includes joysticks 134 and 136 and control panels 138 and 140 for controlling the OHBC. A keyboard 142 is also provided so that the operator can enter or log any information required by the system 14, or issue more complex commands.
An indicator light 144 is provided on the console 90, and is automatically illuminated when the console 90 is active.
An intercom set 146 is provided so that operator can communicate with his or her supervisor, or with workers in the yard should an exceptional or emergency situation arise.
Crane allocation module 80 of yard block server 10 determines the manner in which each crane is to be deployed. The objective is to deploy a number x of cranes in a linear stretch of yard blocks 5 under the control of yard block server 10 such that the turnover rate achieved is maximized. The cranes are preferably deployed in such a manner that the number of cranes in each block is proportional to the number of jobs in their blocks. Secondly, within each block 5, prime movers are preferably served as soon possible, to maximize turnaround time.
In the following example, there are eight cranes for a stretch of 5 blocks (each block measuring approximately 40 slots) . Each crane has an approximate span of 1H blocks. Figure 8a is a schematic depiction of the crane coverage (CR1 to CR8) in a linear stretch of yard blocks Al to El.
As is apparent from figure 8a, the end blocks Al and El can each be served by two cranes (CR1,CR2 and CR7,CR8 respectively) , and the middle blocks Bl to Dl each by four cranes (CR1 to CR4 , CR3 to CR6 and CR5 to CR8 respectively) . The slots at the very end of end blocks Al and El can be reached by one crane only (CR1 and CR8 respectively) . Any individual slot in the middle blocks Bl to Dl can be reached by a maximum of three cranes. It should be noted, however, that this example is intended to illustrate the density of cranes in the yard, not as a factor to relax the crane deployment scheme,
In system 2, and for a prime mover working on a particular slot, all the jobs concerning that slot are preferably handled by the same crane and the same remote crane
operator. This implies that for every prime mover parked at a particular slot, regardless of the number of jobs at that slot, the prime mover need only be assigned to a crane as a whole. In the following, the term λPM job' is used to refer to the list of jobs for a prime mover deployed to the slot concerned.
The system includes a yard activity consolidator module, which has data of estimated yard activity based on past practice. This module is able to provide the estimated number of container moves at a yard range for a specified period of time. This information can enable the yard block server 10 to estimate the number of jobs in each block 5 under its control and distribute its cranes accordingly.
The yard block server 10 polls the yard activity consolidator module at regular intervals (say, every half hour) for the yard activity forecast of the next interval for every yard block under its control. The number of cranes deployed to each block is calculated to be proportional to the number of jobs forecast in that block. If the calculation indicates a need to gantry cranes, the cranes concerned will have their current ratio of jobs computed. If their current ratio of jobs favours the gantry, the crane will be instructed to gantry after completion of its current job.
For example, suppose the number of jobs forecast by the yard activity consolidator module for the various blocks are: Al=10, Bl=10, Cl=30, Dl=20, El=10. We can normalize the number of cranes in each block as follows : Al=l , Bl=l , Cl=3; Dl=2; El=l. If, at present, the number of cranes in each block are: Al=l, Bl=2, Cl=2 , Dl=2, El=l, and crane at Bl has 3 jobs while those at Cl have 5 jobs, then a crane from block Bl will be instructed to gantry to block Cl .
The following are the triggering events in a yard block
server 10 job cycle:
Procedure: Re-sort job list
Trigger: 1. New job instruction downloaded
2. Container movement of a job in the job list
Procedure: Job Allocation Trigger : 1. PM deployed
2. PM deployment canceled
3. PM arrived
Procedure: Crane Deployment Trigger : 1. PM deployed
2. PM arrived
3. Crane breakdown; crane move in/out of a block
The list of jobs downloaded to the yard block server 10 are sorted by their block_id (block identity) and op_grp (operator group) . Each prime mover deployed to a block is assigned to mount containers from the same block and op_grp. No inter-op_grp jobs are assigned as the ratio of prime movers per op_grp is predetermined.
The list of jobs downloaded are also in the sequence to be done by the quay crane, starting from the current crane sequence in ascending order of job sequence, followed by the lookahead crane sequences. The job list 19b in the yard block server 10 is sorted by ascending tier (of the location on the vessel) for each crane sequence. For two jobs of the same tier (on the vessel) and in the same stack in the yard, the higher container found in the yard will be placed before the lower container.
Prime movers are assigned jobs when they are deployed. From the job list of the same block and op_grp, the prime mover is assigned the first x number of jobs based on its capacity. The number of containers that can be mounted on a prime mover is dependent on the prime mover chassis type,
the number of containers already mounted on the prime mover, and any additional checks (e.g. weight check) that needs to be satisfied.
Of the assigned jobs, the prime mover is instructed to go to the lowest slot. This instruction will be sent to the yard operation system 14 and later appear on the prime mover's terminal. The crane deployment scheme is also informed of a prime mover on its way to that slot. The crane deployment scheme can then lookahead for a potential crane to serve this prime mover.
When a prime mover has keyed arrive at a slot, the list of prime movers instructed to go to that slot will be scanned. This prime mover is mounted with containers assigned to the first prime mover instructed to go to that same slot, so that the tying of jobs assigned to the first prime mover that was deployed is avoided.
When a prime mover has been assigned container jobs, that prime mover is added in one of the crane's loading queue. For a mounting prime mover, this is done after the job assignment procedure. For an offloading prime mover, this is done after the prime mover has been laden at the quay. The prime mover travels to an assigned slot. The crane assignment looks ahead for a crane to serve this prime mover. The possible cranes to service this prime mover are identified; if the job can only be done by one crane, the job is added to that crane's queue. If there are more than one possible crane, the lookahead jobs for these cranes, including the new job, are divided among evenly among these possible cranes. This preliminary step balances the load among the cranes .
When a prime mover arrives at the designated slot, the crane recommended during the preliminary step is checked to see if it is able to service that prime mover. If it is
unable to do so, cranes in that block are scanned and, if there is a crane at the same slot, the prime mover is assigned to that crane. Otherwise, the two cranes that can potentially serve that slot are determined. If the nearer crane is free and is not the same crane as that earlier recommended, the prime mover is assigned to it. If it is not, and if the further crane is free and different from the recommendation, a calculation is made to determine if it is justified for the further crane to service a job that is nearer to another crane.
Example
Referring to figure 8b, cranes CR1 and CR2 are at slots 10 and 20 of a block respectively, and CR2 is working on a job at slot 20 and is estimated to complete after 1 minute, while CR1 is available. Prime mover PMl arrives at slot 18. Assuming it takes 5 s to gantry one slot, the estimated time when PMl will be served by CR2 is 60 s + 2x5 s = 70 s. The estimated time when PMl can be served by CRl is 8x5 s = 40 s. Suppose the threshold at which a further crane to serve a prime mover is set at 2 minutes. Since the advantage of CRl serving PMl is only 30 s, CRl is not instructed to gantry. Suppose now that prime mover PM2 arrives at slot 16. Assuming it takes approximately 100 s to mount the container at slot 18 on PMl, then the estimated time for CR2 to serve PM2 is 60 s + 2x5 s + 100 s + 2x5 s = 180 s. The estimated time for CRl to serve PM2 is 6x5 s = 30s. The advantage of CRl serving PM2 is thus 150 s, which exceeds 2 minutes. Hence CRl is instructed to serve PM2.
If neither crane is free, the prime mover is assigned to the crane that it was initially recommended at deployment time. It will be trigger to be done when one of the cranes become available.
When a crane finishes its current job, the queues of the
adjacent cranes are inspected. If either crane has a queue that is very much longer than that of the free crane, an arrived prime mover that is furthest away from that adjacent crane may be added to the free crane's queue, is provided that the prime mover can served within the free crane's span and that it has been waiting for longer than a threshold time. Otherwise no prime movers are removed from other queues .
A search is then performed on the free crane's queued prime movers. The nearest arrived prime mover is served, but prime movers which have been waiting for more than a stipulated time have priority.
Example
Cranes CRl and CR2 are working at slots 10 and 20 of a block respectively. CR2 completes its current task, but has two jobs at slot 18 in its queue. CRl has PMl at slot 13 in its queue, which has arrived 30 minutes earlier. If the threshold time for transferring a prime mover job from another crane is set to be 20 minutes, then PMl will be transferred to CR2's queue. If CR2's threshold time is 30 minutes, then CR2 serves a prime mover at slot 18 first, after which PMl will have waited for longer than 30 minutes and will be served.
Modifications within the spirit and scope of the invention may readily be effected by a person skilled in the art, and it is to be understood that this invention is not limited to the particular embodiments described by way of example hereinabove.