Monitoring and feedback system for processing container loads to control performance results

Abstract

Method for generating feedback for a container loading process, wherein the method comprises: Store, in a memory (154) of a computing device, a set of load stage definitions that define sequential load stages of the container loading process, each stage definition including: i) an intermediate performance target and ii) a stage duration; at a processor (150) of the computer device, in response to the arrival of a container (112) at the loading ramp (108-2), receiving a task definition that defines a performance target for the loading process; on the processor (150), retrieving the loading stages in sequence and, for each stage: i) Receiving sensor data depicting the interior of the container (112) from a sensor array (136) located at the loading ramp (108-2), ii) Determining a performance measurement of the container loading process based on the sensor data, iii) Comparing the performance measurement with the intermediate performance target corresponding to the stage, and iv) based on the comparison, generating an alarm for transmission to a client computing device (124).

Description

BACKGROUND

[0001] Material handling facilities, such as warehouses and the like, are increasingly computerized to cope with growing freight volumes and handling complexity while limiting the need for additional personnel. Machine and computer vision technologies can enable the monitoring of individual container operations within such facilities. However, the volume of such operations can overload recipients of monitoring information as well as the communication networks that relay this information.

[0002] DE 11 2018 005 979 T5 describes systems and methods for estimating the time associated with completing the loading and / or unloading of a container. Furthermore, a method for estimating the estimated time to completion (ETC) of loading a container is specified. The method comprises: capturing, via an image acquisition device, a three-dimensional image representing a three-dimensional formation, wherein the three-dimensional image has a plurality of points with three-dimensional point data; determining an active loading time for the container, at least partially based on a first submultiple of the points; determining a filling level of the container, at least partially based on a second submultiple of the points; and estimating the ETC by a controller, based on the active loading time and the filling level.

[0003] US 2016 / 0239790A1 describes devices, systems, nontransient media, and methods that use a detachable scan sensor node to control a loading process associated with a container. BRIEF DESCRIPTION OF THE MULTIPLE VIEWS OF THE DRAWINGS

[0004] The accompanying drawings, in which the same reference numerals refer to identical or functionally similar elements across the separate views, together with the detailed description below, are included and form part of the description and further serve to illustrate the embodiments of concepts that include the claimed invention and explain various principles and advantages of these embodiments. Fig. Figure 1 is a schematic representation of a system for monitoring and providing feedback on a container loading and unloading process. Fig. 2 is a schematic representation showing the interior of the Fig. 1 illustrated facility. Fig. Figure 3 is a schematic representation illustrating exemplary stages of a container loading process. Fig. Figure 4 is a flowchart of a procedure for monitoring and generating feedback for a loading and unloading process. Fig. Figure 5 is a schematic representation illustrating exemplary stages of a container loading process. Fig. Figure 6 is a flowchart of a procedure for carrying out block 420 of the procedure of Fig. 4. Fig. Figure 7 is a schematic representation that provides exemplary explanations of the procedures of Fig. 4 and Fig. 6 illustrates. Fig. 8 is a schematic representation showing exemplary alarms that occur during the execution of the procedures of Fig. 4 and Fig. 6 are generated, as illustrated. Fig. 9 is a schematic representation showing further exemplary alarms and status messages that result from an execution of the procedures of Fig. 4 and Fig. 6 are generated, as illustrated. Fig. 10 is a schematic representation that includes additional exemplary alarms and status messages generated by an execution of the procedures of Fig. 4 and Fig. 6 are generated, as illustrated. Fig. Figure 11 is a schematic representation illustrating exemplary stages of a container unloading process.

[0005] Those familiar with this field will recognize that elements of the figures are illustrated for the sake of simplicity and clarity and are not necessarily shown to scale. For example, the dimensions of some elements in the embodiments of the present invention may be exaggerated relative to other elements to further aid understanding of these embodiments.

[0006] Components of the apparatus and the method have been represented in the drawings, where appropriate, by conventional symbols which show only those specific details necessary for understanding the embodiments of the present invention, so as not to obscure the disclosure by details which will be readily apparent to the person skilled in the art in this field when he has the description given here. DETAILED DESCRIPTION

[0007] Examples disclosed herein are directed to a method for generating feedback for a container loading process, the method comprising: storing, in a memory of a computing device, a set of load stage definitions that define sequential load stages of the container loading process, each stage definition including: i) an intermediate performance target and ii) a stage duration; receiving, at a processor of the computing device, in response to the arrival of a container at a loading ramp, a task definition that defines a performance target for the loading process;The processor retrieves the loading stages sequentially and, for each stage: i) receives sensor data mapping the interior of the container from a sensor array located at the loading ramp, ii) determines a power measurement of the container loading process based on the sensor data, iii) compares the power measurement with the intermediate power target corresponding to the stage, and iv) based on the comparison, generates an alarm for transmission to a client computing device.

[0008] Additional examples disclosed herein relate to a computing device for generating feedback for a container loading process, the computing device comprising: a memory containing a set of load stage definitions that define sequential load stages of the container loading process, each stage definition including: i) an intermediate performance target and ii) a stage duration; a communication interface; and a processor configured to: receive, in response to the arrival of a container at the loading dock, a task definition that defines a performance target for the loading process;to retrieve the loading stages sequentially and for each stage: i) to receive sensor data from a sensor array located at the loading ramp, which maps the interior of a container, ii) to determine a performance measurement of the container loading process based on the sensor data, iii) to compare the performance measurement with the intermediate performance target corresponding to the stage, and iv) to generate an alarm for transmission to a client computing device based on the comparison.

[0009] Fig. Figure 1 represents a container loading and unloading system 100, which includes a facility 104 (e.g., a warehouse, a manufacturing facility, a retail establishment, or the like) with at least one loading ramp 108. As shown, the facility 104 comprises part of a building, such as the aforementioned warehouse or the like, such as a crossdock or part thereof, which includes the loading ramps 108. As will be apparent to a person skilled in the art, the facility 104 cannot include other non-infrastructure components. Fig. The illustrated example includes the parts shown. In the illustrated example, three loading ramps 108-1, 108-2, and 108-3 are shown. The loading ramps 108 can, for example, be arranged along an outer wall of the facility 104 so that containers can be approached to the loading ramp from the outside of the facility 104. In other examples, smaller or larger numbers of loading ramps 108 may be present. Furthermore, even if in Fig. While Figure 1 illustrates a single facility 104, in some examples the loading ramps 108 may also be distributed across several physically separate facilities. The loading ramps 108 are shown as docking structures that allow access from the interior of the facility 104 to an exterior of the facility 104 where a container 112 is located. In other examples, one or more loading ramps 108 may be implemented as a loading station within the facility 104 for loading and unloading containers that are handled within the facility 104.

[0010] Each loading dock 108 is configured to accommodate one container, such as the one in Fig. The example container 112 shown in Figure 1 is intended to provide space. In particular, the container 112 is shown approaching the loading ramp 108-2. The container 112 can be any container that is transportable by at least one vehicle, train, watercraft, and aircraft, and configured to hold transportable goods, such as items packed and / or unpackaged in boxes and / or other types of cargo. The container 112 can therefore be, for example, a semi-trailer having an enclosed box fixed to a platform having one or more sets of wheels and a coupling arrangement for towing by a tractor unit. In other examples, the container 112 can be the box section of a van, with the container attached to the vehicle's body, which also carries a driver's cab, powertrain, and the like.In other examples, the container may be an air freight container (Unit Loading Device, ULD) of the type used for loading baggage, cargo, and the like onto aircraft. In these examples, the container 112 may be transported to and from the loading docks 108 by a vehicle, such as a forklift or the like. In still other examples, a ULD is handled at a loading dock 108 located within the facility 104, as mentioned above, rather than at a loading dock 108 that provides access to an exterior of the facility.

[0011] Each loading dock 108 has an opening, e.g., in a wall of facility 104, which allows personnel and / or equipment within facility 104 to access the interior of container 112. For example, after container 112 has been positioned at loading dock 108-2, as shown in Fig. As shown in Figure 1, where, for example, a rear wall 114 of container 112 is substantially flush with the opening of loading ramp 108-2, a worker 116 inside facility 104 can begin moving items 120 from facility 104 into container 112. For the loading process, once container 112 has been filled to a target level (which will be discussed in more detail below), a door of container 112 can be closed, and container 112 can be moved away from loading ramp 108-2 to make room for another container.

[0012] As will now become apparent, a similar process can be implemented to unload container 112, for example by worker 116, in order to receive a delivery of items at facility 104 for further processing. In this way, even though the process described here refers to loading container 112 with items 120, it will be evident that the functionality of system 100, discussed below, can be applied just as well to unloading processes. Loading and unloading processes are referred to here generally as "loading" processes.

[0013] The facility 104 may have a considerable number of loading docks 108 (e.g., some facilities may have hundreds of loading docks 108) as well as a considerable number of workers, such as worker 116. The nature of the items 120, and therefore the size, weight, and handling requirements of the items, may vary from container to container. Furthermore, the time available to fill a particular container 112 may change over the course of a day, a week, or a longer period. Even further, the degree to which a particular container 112 is expected to be filled may change over time.

[0014] Worker 116 may carry or otherwise operate a client computing device 124, such as a laptop, tablet, smartphone, or the like. The device 124 may, for example, receive messages from a server 128 containing instructions for worker 116. In other examples, worker 116 may not be issued a computing device 124. The instructions may specify which items 120 are to be loaded into the current container 112, as well as the time available for loading the container 112, the expected fill level of the container 112, and the like. The computing device 124 may also be mounted on a wall, suspended from a ceiling via a support system, or from another fixed part of the facility 104 at or near loading dock 108-2. Each loading dock 108 may have such a device.

[0015] Due to the variable nature of the items 120 and / or the containers 112 processed at the facility 104, and the complexity involved in distributing employees and containers 112 across a potentially large number of loading docks 108, certain loading processes may fail to meet the expected loading times, fill level targets, or both without external intervention. One or more supervisors 132 may be distributed throughout the facility 104, equipped, for example, with appropriate client devices 124. As mentioned above, in some examples, the workers 116 are not equipped with a client device 124, while the supervisor is. In other examples, both the worker 116 and the supervisor 132 are equipped with client devices 124.

[0016] Supervisor 132 can assume responsibility for allocating resources to the three in Fig. The loading bays 108 shown in Figure 1 are present. However, in some systems, the number of loading bays 108 managed by a specific supervisor may make it difficult to accurately estimate the performance of each bay 108, thus complicating resource allocation for the bays 108. Furthermore, in facilities with a large number of bays and therefore a large number of client computing devices 124 distributed among workers 116 and supervisors 132, internal networks (e.g., WLAN, Wireless Local Area Network) may become overloaded, reducing the facility's employees' ability to perform loading processes effectively.Additionally, the number of loading docks 108 managed by supervisor 132 may result in a volume of alarms or other information arriving at supervisor 132's client device 124 that is so large it leads to user fatigue, making it difficult for supervisor 132 to process and respond to such information. This fatigue, in turn, can also lead to operational problems, such as disrupted loading and unloading processes.

[0017] The system 100 therefore includes additional components and functions for assessing a loading and unloading work flow rate and critical timing control processes and for sending such assessments to subsets of client devices 124, while reducing network congestion and increasing the effectiveness with which each supervisor 132 can allocate resources to a set of loading docks 108.

[0018] In particular, the loading ramps 108 feature corresponding sensor arrays 136-1, 136-2, and 136-3, each comprising at least one image and / or depth sensor. For example, each sensor array 136 may include an RGB camera and a depth camera. In other examples, the sensor arrays 136 may include lidar sensors, ultrasonic sensors, path detection devices, sonar devices, or the like, in addition to or instead of the cameras mentioned above. Each sensor array 136 is arranged at the corresponding loading ramp 108 such that a field of view (FOV) 140 (the FOV 140-2 of sensor array 136-2 is in Fig. (1 shown) is directed from the loading ramp 108 outwards into the interior of a container 112 which is attached to the loading ramp 108. In some examples, the sensor arrangement 136 may be attached to the container 112 itself, or the sensor arrangement 136 may include sensors attached inside the container 112 as well as sensors attached to the loading ramp 108.

[0019] The sensor arrays 136 are therefore controllable, e.g., by the server 128, to collect sensor data, such as images and / or depth measurements (e.g., point clouds), corresponding to the interior of adjacent containers 112. The server 128 is configured to process the sensor data to assess one or more current performance attributes (also referred to here as performance measurements) for the loading process. In some examples, the sensor arrays 136 themselves may contain processing hardware and software to determine at least some of the performance measurements for subsequent use by the server 128. The server 128 is further configured to determine whether alarms and / or status messages (collectively referred to as notifications) are generated according to the performance measurements and to send these alarms and / or status messages to selected client devices 124.The alarms and / or status messages can, as discussed below, contain information indicating deviations from and compliance with expected performance, as well as the severity of such deviations. In some examples, the alarms and / or status messages may also include instructions on actions to be taken to correct performance deviations.

[0020] In this way, the server 128 enables the system 100 to provide essentially real-time feedback for the loading and unloading processes taking place at the loading docks 108 by measuring and assessing current loading performance via the sensor arrays 136 and generating the alarms and / or status messages mentioned above. The server 128 also mitigates the overtaxing of network and device resources by such alarms, as discussed in more detail below, and thus reduces information fatigue for the user 132 and / or 116.

[0021] The Server 128 contains a central processing unit (CPU), also referred to as a Processor 150, which is connected to a non-volatile, computer-readable storage medium, such as the Memory 154. The Memory 154 contains any suitable combination of volatile memory (e.g., random access memory, RAM) and non-volatile memory (e.g., read-only memory, ROM), electrically erasable programmable read-only memory (EEPROM), or flash memory). The Processor 150 and the Memory 154 each comprise one or more integrated circuits (ICs).

[0022] The server 128 also includes a communication interface 158, which enables the server 128 to exchange data with other computing devices, such as the client devices 124. The communication interface 158 therefore includes any suitable hardware (e.g., transmitter, receiver, network interface controller, and the like) that enables the server 128 to communicate, for example, over local area networks (LANs) and / or wide area networks (WANs).

[0023] Memory 154 stores a number of machine-readable instructions, for example, in the form of a load assessment application 162. Application 162 is executable by processor 150 to implement various functions performed by server 128. As discussed below, application 162 performs the assessment and alarm generation mentioned above. In this example, memory 154 also stores a repository 166 containing data used in the assessment and alarm generation mentioned above. Specifically, repository 166 contains a set of stage definitions that define successive stages of the container load and unload processes. The definition for each stage includes a stage duration and an intermediate performance target for the stage.In short, each duration defines a period after which the next stage is expected to begin, and the intermediate performance target sets an expected state of container 112 when the aforementioned duration expires. The stage definitions, along with performance measurements derived from sensor data, are used by server 128 to determine if and when to generate alarms and / or status information for transmission to client device 124.

[0024] If we now Fig. Turning to Figure 2, a partial view inside facility 104 is shown after the container has been picked up at loading ramp 108-2 and loading or unloading of container 112 has begun. In particular, loaded items 200 inside the partially loaded container 112 are shown, and items 120 inside facility 104 adjacent to loading ramp 108-2 and vice versa for unloading are also shown. As in Fig. As shown in Figure 2, the sensor arrays 136 are attached to each loading ramp 108 to capture sensor data representing the interior of a container 112 when the container 112 is open. Loading ramp 108-3 is occupied by another container with a closed door 204 (e.g., because loading is complete or has not yet started).

[0025] With reference to Fig. Figure 3 shows an example illustrating a set of loading stages defined in Repository 166. Various other sets of stages may be represented in Repository 166, depending on the specific activities and / or structure of Facility 104. As in Fig. Figure 3 illustrates that, in the current exemplary implementation, the repository contains 166 stage definitions for four loading stages. The in Fig. The three example stages shown illustrate the time required for each stage (on the horizontal axis) and the expected fill level of container 112 during each stage, which is shown on the vertical axis.

[0026] In particular, the defined stages include an initial stage 300, which can also be referred to as the pre-loading stage, during which a container delivered to a loading ramp 108 is prepared for loading (or unloading, as previously noted). Preparation for loading or unloading may include opening the container door, rearranging items 120 within the facility 104, a worker completing a data entry, or the like.

[0027] As noted above, Repository 166 defines each stage by duration and intermediate performance target. The duration can be defined as a specific period of time, a percentage, or another fraction of the total time available to complete the loading process. The total available time can be determined by an external process (performed, for example, on Server 128 itself or another computing device), based on scheduling data and personnel availability data. In other words, the durations defined in Repository 166 can be defined as relative rather than absolute values. In some examples, Repository 166 can be dynamically updated by the aforementioned external process to reflect more or less intensive operations across the entire Facility 104, for example, by compressing some stages and extending others.

[0028] The initial stage 300, for example, can be defined in repository 166 to have a duration of approximately 7.5% of the total process time, even if other parts below or above 7.5% are also considered. The initial or pre-load stage 300 can also have an intermediate performance target of a non-zero fill level or a specific minimum fill level target. This means that the expected state of the container at the end of the defined duration must be a non-zero fill level. In other words, in a loading process, if container 112 remains empty after pre-load stage 300 has elapsed (or if container 112 remains full in an unloading process after pre-load stage 300 has elapsed), system 100 can generate an alarm.In the illustrated idealized example, container 112 begins to be filled at the end of stage 300, as indicated by graphic 302 for the idealized work rate (in this example, a filling rate, although in other cases the ideal work rate is an unloading or emptying rate). Various other intermediate performance targets can be defined in addition to or instead of the non-zero fill level target specified above. For example, the intermediate performance target could be an expected state of the door of container 112 (e.g., that the door must be open at the end of the initial stage 300).

[0029] The stages defined in Repository 166 further include a loading activity stage 304, during which items 120 are placed into container 112 or during which items are moved from container 112 into the facility (for unloading processes). Loading activity stage 304 can have a defined duration, for example, approximately 80% of the total process time if defined as a percentage of the total process time. As will be evident, other percentages above or below 80% can also be specified for the duration of loading activity stage 304. The intermediate performance target for loading activity stage 304 is a target fill level for container 112. The target fill level can be determined by the aforementioned external process, for example, based on workforce and other resource allocation parameters. As in Fig. As shown in Figure 3, the target fill level for this example stage definition is 75% (i.e., three-quarters of the internal volume of container 112 to be filled with items 120). However, as can be seen, the target fill level can vary across different loading processes. Other intermediate performance targets can also be used in addition to or instead of fill level targets. For example, an intermediate performance target might include a target fill rate (e.g., as a percentage of fill level per minute or the like), an estimated time to completion (ETC) based on a current work rate, and the like.

[0030] The stages defined in repository 166 also include a final or post-loading stage 308, for example, during which container 112 is prepared for transport from loading ramp 108. The intermediate goal for stage 308 could, for example, be a state for the door of container 112 (e.g., that the door must be closed). The duration of stage 308 in this example can be approximately 7% of the total process duration, although other parts can also be used.

[0031] The stages defined in Repository 166 may also include a transition stage 312, which, for example, begins when the preceding container 112 is removed from loading dock 108 and ends when the next container 112 arrives at loading dock 108 (after which a new loading or unloading process is initiated, starting with another instance of stage 300). The intermediate performance target for stage 312 may, for example, be a state associated with loading dock 108 itself, such as the loading dock being occupied (as opposed to empty) with a container 112 at the time stage 312 ends. The duration of stage 312 may, for example, be defined as 5.5% of the total process duration (although other parts may also be used).

[0032] If we now Fig. Turning to section 4, a procedure 400 for monitoring and generating feedback for a loading process is shown there. The procedure 400 is described in connection with its exemplary performance within system 100. In particular, the blocks of procedure 400 are executed by server 128, which is configured via the execution of application 162.

[0033] Server 128 is configured to receive a task definition (also referred to as task data) at block 405, corresponding to a loading dock 108. Generally, the task data defines a loading or unloading operation for a specific container 112 at a specific loading dock 108. In this example, the task data is assumed to define a loading operation for container 112 at loading dock 108-2. The task data can be received, for example, essentially simultaneously with the arrival of container 112 at loading dock 108-2.

[0034] The task data defines a performance target for the loading process as a whole. The performance target includes at least one fill level target, expressed, for example, as a percentage of the container volume to be filled with items 120, and a time target, expressed, for example, as a total process duration or a specific time at which the process is expected to be completed. In some examples, the performance target specifies both a fill level target and a time target. For example, in the present embodiment of procedure 400, the task data specifies that container 112 must be filled to 80% of its capacity at a specific time, such as a time one hour in the future relative to the time container 112 arrives at loading dock 108-2.

[0035] The aforementioned performance targets can be generated on server 128 or received from another server within system 100.

[0036] The performance targets can be adjusted periodically and / or dynamically determined for each loading and unloading process, e.g., based on the object handling capacity of the facility 104 as a whole and on the basis of the total volume of the objects 120 currently processed in the facility 104.

[0037] Server 128 is configured, after receiving the task data, to retrieve the stage definitions from repository 166 and generate process-specific stage definitions. For example, if we consider... Fig. Turning to section 5, a set of stages for the current loading process is illustrated there, generated based on the target completion time ten hours in the future (e.g., as received from another computer device of System 100 or as calculated by Server 128 itself), and the aforementioned target fill level of 80% (although, as noted, many different target fill level values ​​can be used). Server 128 can be configured to translate the percentages into specific time periods based on the task data if the stage durations are defined as percentages of a total available time. In this way, in the present example, an initial stage 500 has a target duration of 45 minutes (i.e., 0.75 hours, which is 7.5%, as shown in Fig. 3 shown) and an intermediate performance target of a non-zero fill level no later than the end of stage 500. A loading activity stage 504 has a duration of 8 hours (so that in the present example, stage 504 ends 8.75 hours after the process is initiated) and an intermediate performance target of 80% fill level (i.e., the target fill level of the task definition). As shown in Fig. As shown in Figure 5, the expected ideal working rate of container 112 during loading activity level 504 is a rate of 506.

[0038] A post-load stage 508 can last 42 minutes (e.g., 7% of the total process time, as in connection with Fig. 3 noted) and have an intermediate performance target of the door of container 112 being in a closed state. Finally, a transition stage 512, even if it does not directly relate to the process of loading container 112, may have a target duration of 33 minutes (e.g., 5.5% of the total process duration, as mentioned in connection with Fig. 3 noted) and have an intermediate performance target of an occupied state for loading ramp 108-2 at the end of stage 512.

[0039] If we go to Fig. Returning to block 4, server 128 is configured to load the next stage at block 410. In this example, no stages are loaded or completed, and the server is therefore configured to load the initial stage 500.

[0040] Server 128 is configured to control sensor array 136-2 at block 415 and to capture sensor data representing the interior of container 112. As previously noted, the sensor data can contain either image or depth data, or both. Server 128 is configured to determine a performance measurement corresponding to the loading process based on this sensor data. Various performance measurements can be determined at block 415, which depend at least partially on the current stage. For example, the performance measurement(s) determined at block 415 includes a measurement of the same type as the intermediate performance target of the current stage.

[0041] As noted previously, in the present example, the intermediate performance target for the initial stage 500 is a fill level target (specifically, a fill level above zero). In some examples, the intermediate performance target may include the presence of a worker (or workers) 116 in container 112, i.e., within the FOV 140 of sensor array 136. Server 128 therefore determines a current fill level of container 112 at block 415. Determining a fill level may, for example, involve detecting items 120 within the container from image and / or depth data, estimating the combined volume of the items 120, and comparing the estimated volume with a previously recorded total volume of container 112. Other examples of performance measurements determined at block 415 are discussed in the context of subsequent stages of the loading process.

[0042] Server 128 is configured to determine at block 420, based on the intermediate performance target set by the stage definition loaded at block 410 and the performance measurements from block 415, whether alarms and / or status messages should be generated and sent. This means that each stage definition can also define alarm and / or status message criteria, which define the conditions under which alarms and / or status messages are generated at block 420. The determination of whether alarms and / or status messages should be generated at block 420 is described in more detail below. In general, the determination at block 420 involves a comparison between the intermediate performance target of the current stage and the performance measurement, as well as an assessment of whether the time criteria for generating an alarm and / or status message are met.The timing criteria enable the server 128, as will be evident from the discussion given below, to deliver information to the client devices 124 for alarms and / or status messages, while reducing user fatigue (for example, of the supervisor 132) resulting from an excessive volume of alarms, and minimizing additional load on networks within the facility 104 and on the client devices 124 and their operators.

[0043] If the determination at block 420 is negative, server 128 determines at block 425 whether the current stage has ended. This means that server 128 determines at block 425 whether the previously defined duration of the stage loaded at block 410 has expired. Server 128 is configured, if the determination at block 425 is negative, to return to block 415 to collect more sensor data and update the performance measurement. The determination at block 420 is then repeated, proceeding to block 425 if no alarm and / or status message is to be generated, or to block 430 if the determination at block 420 is positive. As will be discussed in greater detail below, at block 430, one or more alarms and / or status messages are transmitted from server 128 to selected client devices 124.

[0044] Server 128 is configured to determine at block 435, if the determination at block 425 is positive, whether there are still stages to process. If further stages remain, the determination at block 435 is positive, and server 128 returns to block 410. Otherwise (if all stages are completed), the execution of procedure 400 ends. Upon the arrival of another container at loading dock 108, another instance of procedure 400 can be initiated.

[0045] If we Fig. Turning to section 6, a procedure 600 for determining whether alarms and / or status messages should be generated at block 420 is illustrated there. The execution of procedure 600 is described in connection with the execution of procedure 400 to load container 112 at loading ramp 108-2. After sensor data has been collected at block 415 and (in the present example) a performance measurement in the form of a current fill level for the container has been carried out, server 128 is configured to determine at block 605 whether an alarm period (which can also be called a notification period, since both alarms and status messages can result from the expiration of an alarm period) has expired. The stage definitions mentioned above can also define one or more alarm periods (i.e.,These include time periods after which a decision is triggered to assess process performance and, if necessary, generate alarms and / or status messages within each stage. For example, the alarm period for the initial stage 500 in this example is equal to the stage duration itself. In other words, at stage 500, the trigger for whether or not to generate an alarm is the end of stage 500 itself. If the determination at block 605 is negative, indicating that the alarm period has not yet expired, no alarm is generated, regardless of the performance measurement, and server 128 proceeds to block 425. This helps to mitigate user fatigue (the supervisor 132 and / or the worker 116).

[0046] Server 128 is configured, if the determination at block 605 is positive, to proceed to block 615 and evaluate the current performance measurement against the intermediate performance target for the relevant load stage. Based on this evaluation, as discussed below, server 128 can send an alert and / or a status message to one or more client devices 124. In other examples, the execution order of blocks 605 and 615 can be reversed. That is, in some examples, server 128 can be configured to evaluate the performance measurement from the current instance of block 415 against the intermediate performance target, detecting that performance issues are occurring during the load process or that previous performance issues have been resolved.Server 128 can then, after assessing the performance at block 605, determine whether an alarm period has expired and determine whether an alarm and / or status messages should be sent in accordance with this determination.

[0047] If we Fig. Turning to Figure 7, stages 500 to 512 are shown there, along with an ideal operating rate of 700. The execution of block 415 can be repeated with a sampling frequency of the sensor arrangement 136-2, for example, every 15 seconds (although a wide variety of other sampling frequencies can also be used). However, the determination at block 615 is only performed at specific trigger points, which correspond to the alarm and / or status message periods mentioned above. For example, at time 702, approximately halfway through the first stage 500, the fill level can be measured as zero via an execution of block 415, indicating that the loading of container 112 has not yet begun. However, time 702 is before the end of the initial stage 500, which coincides with the alarm period defined for the initial stage 500.Therefore, the determination at block 605 is negative, which is equivalent to a negative determination at block 420. Server 128 thus returns to block 415, performs another sensor data sampling, and determines another power measurement. In this way, another instance of procedure 600 is initiated. This process is repeated until the first alarm period has expired, which in this example is the end of stage 500.

[0048] When we meet again Fig. If the server moves to block 7, time 704 coincides with the end of the initial stage 500 and therefore with the expiration of the alarm period for stage 500. Therefore, the determination at block 605 is positive, and server 128 proceeds to block 615. At block 615, the server determines whether the power measurement from block 415, corresponding to the sensor data captured at trigger time 704, meets the intermediate power target for the current stage. As can be seen, the determination at block 615 is not performed before the alarm period has expired, which is why no alarms are generated, even if the power measurement has not yet met the intermediate power target. In other examples, where the order of blocks 605 and 615 is reversed, the determination at block 615 can, however, be performed at least once before trigger time 704, but no alarms are generated before trigger time 704 occurs.

[0049] As noted above, the intermediate performance target for the initial stage 501 is a non-zero fill level. As in Fig. As can be seen in Figure 7, the actual fill level, represented by a solid line on graph 706, remains at zero at time 704, which is why the determination at block 615 is negative. If the determination at block 615 is positive, server 128 proceeds to block 425. In some examples, server 128 may generate and send a status message at block 620 before proceeding to block 425 (rather than an alarm indicating that action is needed to correct a deficiency in the loading process). For example, as noted above, in some examples server 128 may execute block 615 before block 605. In this way, the determination at block 615 may be positive, after which server 128 may determine at block 605 to send a status message (i.e., to proceed to block 620).

[0050] The stage definitions of Repository 166 can also define conditions under which status messages are sent. Generally, status messages indicate that a previous defect in a load process has been resolved and / or that the load process is proceeding as expected. The use of status messages may be omitted entirely for some stages in certain examples, according to the stage definitions.

[0051] Server 128 is configured to generate an alarm for a negative determination at block 615, as in the present exemplary implementation of procedure 600, but for a positive determination at block 425 (i.e., the determination at block 420). The stage definitions in repository 166 can also contain alarm definitions for each stage (which, for example, define the content of an alarm). In this example, it is assumed that the stage definition for the initial stage 500 contains a single alarm definition, which is then triggered if the fill level of container 112 remains at zero at time 704 after stage 500 has finished.

[0052] Server 128 can also be configured to update the alarm period at block 630 (for example, to counteract information exhaustion for supervisor 132 and worker 116) and optionally the alarm severity level. The level definitions can also specify available severity levels for alarms. In this example, level 500 is assumed to use a single severity level, so no update is needed for the severity level. Additionally, no updated alarm period is generated at block 630 because level 500 generates at most one alarm. Therefore, server 128 proceeds to block 430.

[0053] Again with reference to Fig. Server 128 is configured to send an alarm generated at Block 625 to selected target client devices 124 at Block 430. The client devices 124 selected at Block 430 to receive the alarm and / or status message can be chosen based on stored mappings between client devices 124 and loading docks 108, as well as the severity level mentioned earlier. For example, Server 128 can maintain or access a list of computer devices 124 assigned to loading dock 108-2, such as those operated by worker 116 and supervisor 132, if such information is maintained by another computer device. Server 128 can then transmit the generated alarm and / or status message to a subset of such devices according to the severity level.For example, a minimal severity level may result in the alarm being transmitted only to the client devices 124 assigned to workers, while higher severity levels may result in the alarm also being sent to the client device 124 operated by the supervisor 132.

[0054] If we briefly Fig. Turning to section 8, an example alarm is displayed on the screen 800 of a client device 124. The alarm can be displayed, for example, as a notification element 804 overlaid on an underlying interface (which, for example, contains icons 808 for launching applications in this example). For instance, the notification element 804 can be generated on a home screen (containing the icons 808 commonly found on smartphones running Android or iOS, or on ruggedized portable computers running Windows) of the computer device 124. In other examples, the alarm can be displayed within an interface generated by a specific application running on the client device 124, for example, after the application has been launched, by selecting a corresponding icon 808.Message element 804 contains an identifier for loading ramp 108-2 and a text string indicating the type of alarm and / or status message (in this case, that the loading activity did not start as expected before the end of the initial stage 500). Message element 804 can also contain a gravity indicator 812, for example, a "warning" icon and / or a pictogram in this example. A wide variety of other gravity indicators can be used for the alarms described here, including colored messages, text-based indicators, audible or vibrating gravity indicators, and the like.

[0055] If we go to Fig. Returning to block 4, server 128 determines at block 425, after block 430, whether the current stage has been completed. In this exemplary implementation of procedure 400, the determination at block 425 is positive because the duration specified for stage 500 has expired. In other examples, the determination at block 425 may also be positive even if the duration of the stage in question has not yet expired. In particular, if the intermediate performance target corresponding to a stage has been met (i.e., the determination at block 615 was positive), a stage may also be considered completed before the initial time set by the stage definitions. This can lead to the early completion of a stage extending the following stage by allowing the subsequent stage to start earlier.

[0056] Server 128 therefore returns to block 410 and loads data for load activity level 504, which is in the Fig. 5 and Fig. 7 is shown.

[0057] The stage definition for stage 504 specifies that the intermediate performance target has reached a fill level of 80% at the end of stage 504 (for example, 8.75 hours after the start of the charging process). The stage definition for stage 504 also includes a set of rules that define successive alarm periods and severity levels, as discussed further below.

[0058] Server 128 is configured to collect additional sensor data at block 415 and determine a performance measurement. Because the intermediate performance target is a fill level at the completion of stage 504, the performance measurement at block 415 can be a predicted fill level at the completion of stage 504, for example, based on a linear extrapolation of the currently measured fill level. In other examples, the currently measured fill level can be compared to an expected current fill level interpolated from the intermediate performance target. In some examples, server 128 can use a series of individual measurements from successive performances of block 415 to generate the performance measurement. For example, server 128 can combine the last five (although other numbers of measurements can be used) to estimate a current fill rate of container 112.The estimated fill rate can be extrapolated for block 415, as mentioned above.

[0059] Server 128 is configured to then execute block 420, for example by starting an instance of procedure 600. Specifically, server 128 is configured to determine at block 605 whether the alarm period has expired. If we look at Fig. Turning to section 7, it is assumed that the first alarm period defined for stage 504 occurs at time 708, because a deviation in the work rate greater than a predetermined threshold (for example, the work rate deviated by more than 5 percentage points from the ideal fill rate of 700) was detected, for example, approximately 15 minutes after the start of stage 504 (or approximately one hour after the start of the entire process). As will be evident, numerous executions of block 415 occur between times 704 and 708, but in the absence of a positive determination at block 605, no alarm decision is triggered from these executions of block 415. At time 708, however, the decision at block 605 is positive, and therefore an execution of block 615 is triggered.

[0060] In other examples, such as the previously mentioned implementation where performance is assessed at block 615 before the determination at block 605, the first alarm period can be dynamically determined such that the determination at block 605 is automatically positive in response to the initial finding at block 615 that the performance measurement does not meet the intermediate performance target. This means that at time 708, server 128 may have accumulated enough samples to estimate the work rate at block 415, and if this work rate indicates that the target level will not be reached, server 128 determines at block 605 that an alarm should be sent essentially immediately.

[0061] As in Fig. As shown in Figure 7, the performance measurement representing the current fill rate of container 112 (indicated in the continuous curve 706) is more than half a level below the fill rate required to meet the intermediate performance target (80% full). After the positive determination at block 605, the determination at block 615 is negative because the measured fill rate is below the rate required to reach the target fill level. Therefore, server 128 is configured to generate an alarm at block 625, for example, at an initial severity level. For instance, level 504 can define three ascending severity levels, with the lowest being the default level.

[0062] At block 630, in response to an alarm being generated at the first of the severity levels mentioned above, server 128 can update either the alarm period, the severity level, or both. For example, server 128 might be configured to increment the current severity level so that the next alarm generated via procedure 600 (within level 504) will have the second of the three severity levels mentioned above. Server 128 can also determine a subsequent alarm interval based on the current time and the duration of level 504. For example, the level definition for level 504 might specify that, in addition to the first alarm period mentioned above, four additional alarm periods should be used, starting at the point halfway between the first alarm period (at time 708) and a time at or near the end of level 504 (for example, at 708). Fig. 7 (a time approximately 15 minutes before the end of stage 504 is used). As in Fig. As shown in Figure 7, the remaining alarm periods can occur at times 712, 716, 720 and 724, with times 716 and 720, for example, dividing the period between times 712 and 724 equally.

[0063] Server 128 is configured to send the alarm generated at block 625 at block 430 of procedure 400, for example, to client device 124 operated by worker 116, or to client device 124 operated by supervisor 132, or both. Fig. Figure 8 illustrates a message element 816, displayed on indicator 800, indicating that the fill rate of container 112 needs to be increased. Message element 816 cannot contain an icon or pictogram similar to the one used to implement indicator 812 in the previously mentioned message element 804, because in this example, the severity associated with this alarm is at its lowest level. However, message element 816 can contain another form of severity indicator, such as a color change in the text within message element 816, the background of that text, or the like.

[0064] The result at block 425 is negative because stage 504 has not yet completed. Therefore, server 128 repeats the execution of blocks 415, 420, 430 (if applicable), and 435 until the result at block 425 is positive. For example, with reference to Fig. 7. A further execution of block 415 may result in the current fill rate of container 112 being sufficiently increased to meet the intermediate performance target, for example, as shown in segment 713, which illustrates a larger slope relative to the ideal fill rate of 700. In some examples, because the next alarm period (which expires at 712) has not yet elapsed, no messages are generated in response to the increased performance. However, in other examples, separate alarm periods for status messages may be defined. In still other examples, server 128 may be configured to generate an alarm and / or a status message before the alarm period ending at 712 expires in response to a recovery in the work rate, as detected, for example, at segment 713, regardless of the specific time at which the recovery is detected.

[0065] For example, at block 620, server 128 generates a status message and sends it to client device(s) 124. The status message indicates that the fill rate has recovered and can have the lowest severity level or a separate severity level that does not trigger an alarm. For example, as in Fig. Figure 9 shows a message element 900 being displayed on the indicator 800, containing the status message indicating that the fill rate has recovered, as well as a severity indicator 904 that does not correspond to an alarm (for example, different from the severity indicators used for alarms). In response to the status message being sent at block 620, server 128 can optionally update the severity for subsequent messages, for example, by decrementing the severity if it was previously increased (for example, after the alarm generated at time 708).

[0066] The work rate may subsequently decrease, as indicated by segment 714 (where loading pauses). However, in this implementation, server 128 does not generate any alarms until the alarm period, which expires at time 712, has elapsed. When time 712 arrives, the determination at block 605 is positive (because time 712, shortly before the end of five hours in the loading process, marks the end of the next alarm period, as mentioned above), and the determination at block 615 is negative because the current work rate indicates that the intermediate performance target will not be met. In this example, server 128 is therefore configured to generate an alarm at block 625, such as the one shown in Fig. The message element 816 shown in section 8 is generated. The severity level of block 630 can be incremented (for example, returning to the second of the three levels after being downgraded to the first level following the status message mentioned above).

[0067] Before time 716 (corresponding to the expiration of another alarm period), the measured fill rate (for segment 715 of curve 706) has increased relative to the ideal fill rate of 700, but remains below a rate required to reach the fill level at the end of stage 504. Therefore, at time 716, server 128 generates another alarm for transmission. As noted above, the severity of this alarm is increased relative to the first alarm generated at time 712. In some examples, a recovery, such as the one recorded for segment 713, can lead to a decrement in severity, while in other examples, the severity is only increased or prevented from decrementing if the time remaining before the end of stage 504 is below a threshold (for example, if less than 25% or any other percentage of stage 504 remains).In the present example, the alarm generated at the moment is 716 relative to the one in . Fig. Alarm 816, as shown in section 8, indicates an increased severity level. In particular, it shows Fig. 9 a message element 908 containing an alarm indicating the need for an increased filling rate, with the previously mentioned severity indicator 812. In some examples, the severity indicator can be further increased at block 630. However, in other examples, the severity level can only be raised to the third and highest level if the time is within a specific period before the end of level 504 (for example, 15 minutes, which coincides with the end of the last alarm period at time 724).

[0068] Between time 716 and time 720, the work rate increases again relative to the ideal fill rate of 700, as shown by segment 717 of curve 706. However, the work rate remains too low to achieve the intermediate performance target. Therefore, by executing blocks 415, 420 (via procedure 600), and 430, server 128 generates and sends another alarm. In this example, the gravity indicator remained unchanged after the previous alarm, allowing for the generation of another alarm similar to the one shown in message element 908.

[0069] Following the aforementioned alarm, the work rate can be further increased, as shown, for example, by segment 721. However, the increased work rate remains insufficient to reach the intermediate performance target. Therefore, server 128 generates another alarm at the current time, 724, with the third (and in this case, maximum) severity level. Fig. Figure 9 illustrates a message element 912 indicating an urgent need for additional resources at loading dock 108-2 to increase the fill rate, and may include another severity indicator 916. In some examples, the alert 912 may be transmitted to additional client devices 124 beyond those of the worker 116 and the supervisor 132.

[0070] As in Fig. As shown in section 7, the interim performance target was reached at the end of stage 504 as a result of an increased fill rate between time 724 and the end of stage 504, therefore no further alarm is sent. A status message, such as message 900, which appears in Fig. However, it can be sent at the end of stage 504, as shown in 9.

[0071] After stage 504 is completed, the final or post-load stage 508 is loaded at block 410, and blocks 415, 420, and 425 (and, if applicable, block 430) are executed at least once for stage 508. In this example, it is assumed that a single alarm time period and severity level are used for stage 508. For example, at time 728, server 128 can determine a performance measurement indicating whether the door of container 112 is closed. If the door is not closed, an alarm can be generated indicating that the door closure at loading dock 108-2 is delayed.

[0072] The processing of stage 512 can also use a single alarm period, ending at time 732, and a single severity level. Specifically, when executing block 415 for stage 512, server 128 can determine, as a performance measurement after the previous container has been removed, whether loading bay 108-2 is occupied. If loading bay 108-2 is not occupied, the determination at block 615 is negative, and a further alarm can be generated, indicating, for example, that the arrival of the next container at loading bay 108-2 is delayed.

[0073] Various additional pieces of information may also be included in the alarms mentioned above, or may be accessible, for example, by selecting a notification element provided via such an alarm. For example, in Fig. As shown in Figure 10, the client device 124 can receive additional information from the server 128, which includes a current image 1000 of the interior of container 112, taken by the sensor arrangement 136-2, as well as a current status measured at block 415, which contains a current fill level, the target fill level and a time remaining until the end of stage 504.

[0074] In some examples, multiple alarms and / or status messages can be displayed in a staggered arrangement, for example, on the client device 124 of the supervisor 132. For example, a notification application executed by the client device 124 can display nested sets of alarms and / or status messages 1008, 1012, and 1016 for the respective loading docks 108. Selecting a specific set (for example, selecting set 1008 in the Fig. (See example 10) to expand a list of recent alarms and / or status messages issued in connection with loading dock 108, for example, in ascending or descending chronological order. The alarms and / or status messages can also be listed in other orders, for example, sorted by severity.

[0075] As previously mentioned, procedures 400 and 600, implemented by server 128, can also be applied to unloading processes, whereby container 112 arrives at loading dock 108 fully or partially filled, and the items 120 contained therein are unloaded from container 112 and transported to facility 104. Fig. Figure 11 illustrates an idealized container unloading process. Each stage of the unloading process, as in the one described in Fig. The loading process shown in Figure 3 can be defined by a duration and an intermediate performance target. For example, the unloading process can include an initial stage 1100, which is assigned a duration of a certain percentage (for example, 10%) of the total time available for unloading, and an intermediate performance target that indicates a non-zero fill level of the container at the end of stage 1100.

[0076] The unloading process may also include an unloading activity stage 1104, which has a duration defined as another percentage (for example, 80%) of the total available time, and an intermediate performance target of a fill level of zero. In other examples, the intermediate performance target may be a negative target fill rate, also referred to, for example, as an emptying rate, as indicated by the slope of curve 1106. The unloading process may also include a final or post-loading stage 1108, in which the now empty container 112 is prepared for removal from loading ramp 108. As with the previously mentioned final stage 308, the intermediate performance target for stage 1108 may be the state of the container 112 door (for example, the door may be expected to be closed at the end of stage 1108). The process may further include a transition stage 1112, which is associated with the Fig.The 3 discussed transition stage 312 is equivalent.

[0077] Specific embodiments have been described in the above description. However, the person skilled in the art will recognize that various modifications and changes can be made without derogating from the scope of the invention as set forth in the claims below. Accordingly, the description and the figures are to be understood in an illustrative and not a limiting sense, and all such modifications are to be included within the scope of the present teaching.

[0078] The advantages, benefits, solutions to problems, and any elements that may give rise to or make a benefit, benefit, or solution appear more pronounced are not to be understood as critical, necessary, or essential features or elements of any or all claims. The invention is defined solely by the accompanying claims, including all amendments made during the pending state of the present application, and all equivalents of these claims as granted. For the sake of clarity and conciseness, features are described here as part of the same or separate embodiments; however, it is understood that the scope of the invention may also include embodiments incorporating combinations of all or some of the described features.It is understood that the embodiments shown have the same or similar components, unless they are described as different.

[0079] Furthermore, in this document, terms indicating a relationship, such as first and second, top and bottom, and the like, may only be used to distinguish one entity or action from another, without requiring or implying any actual relationship or order between such entities or actions.The terms "includes," "comprising," "has," "having," "includes," "contains," "includes," "contains," or any other variation thereof are intended to cover non-exclusive presence, such that a process, method, article, or apparatus that includes, has, has, or contains a list of elements may not only have those elements but may also have other elements not expressly listed or inherent to such process, method, article, or apparatus. If an element is preceded by "includes," "has," "has," or "contains," this does not preclude, without further limitations, the existence of additional identical elements in the process, method, article, or apparatus that includes, has, has, or contains the element.The words "one" are defined as one or more unless explicitly stated otherwise herein. The terms "essentially", "essentially", "approximately", "about", or any version thereof are defined to approximate what a person skilled in the art in this field would understand by them, and in one non-restrictive embodiment, the expression is defined as being within 10% of one range, within 5% of another, within 1% of another, and within 0.5% of yet another. The term "coupled" is used here to mean connected, even if not necessarily directly or mechanically. A device or structure that is "configured" in a certain way is configured at least in that way, but may also be configured in ways not listed.

[0080] It will be understood that some embodiments may consist of one or more specialized processors (or “processing devices”), such as microprocessors, digital signal processors, custom processors, and field programmable gate arrays (FPGAs), and unique stored program instructions (containing both software and firmware) that control the one or more processors to implement, in conjunction with certain non-processor circuitry, some, most, or all of the functions of the method and / or device described herein.Alternatively, some or all functions can be implemented by a state machine that does not store any program instructions, or in one or more application-specific integrated circuits (ASICs) where each function, or some combinations of specific functions, are implemented as custom logic. Of course, combinations of both approaches could also be used.

[0081] Furthermore, an embodiment can be implemented as a computer-readable storage medium in which computer-readable code is stored for programming a computer (which, for example, contains a processor) to execute a method described and claimed herein. Examples of such computer-readable storage media include, but are not limited to, a hard disk, a CD-ROM, an optical storage device, a magnetic storage device, a ROM (Read Only Memory), a PROM (Programmable Read Only Memory), an EPROM (Erasable Programmable Read Only Memory), an EEPROM (Electrically Erasable Programmable Read Only Memory), and flash memory.Furthermore, it is assumed that an average professional, even despite potentially considerable effort and many design decisions motivated, for example, by available time, current technology and economic considerations, will be able to easily create such software instructions and programs and integrated circuits with minimal experimental effort if guided by the concepts and principles revealed here.

[0082] The abstract of the invention is given to enable the reader to quickly gain an impression of the nature of the technical disclosure. It is presented with the understanding that it is not to be used to interpret or limit the scope or meaning of the claims. In addition, it can be seen from the preceding detailed description that various features in different embodiments have been combined for the purposes of a more rational disclosure. This method of disclosure should not be interpreted as implying that the claimed embodiments require more features than are expressly stated in the respective claim. Rather, as reflected in the following claims, the subject matter of the invention consists of fewer than all the features of a single disclosed embodiment.In this way, the following claims are hereby incorporated into the detailed description, each claim representing a separate subject matter. The mere fact that certain measures are specified in different claims does not indicate that a combination of these measures cannot also be advantageously employed. Many variations will be apparent to those skilled in the art in this field. All variations shall be understood as being included within the scope of the invention as defined in the following claims.

Claims

[1] Method for generating feedback for a container loading process, the method comprising: Store, in a memory (154) of a computing device, a set of load stage definitions that define sequential load stages of the container loading process, each stage definition including: i) an intermediate performance target and ii) a stage duration; at a processor (150) of the computer device, in response to the arrival of a container (112) at the loading ramp (108-2), receiving a task definition that defines a performance target for the loading process; on the processor (150), retrieving the loading stages in sequence and, for each stage: i) Receiving sensor data depicting the interior of the container (112) from a sensor array (136) located at the loading ramp (108-2), ii) Determining a performance measurement of the container loading process based on the sensor data, iii) Comparing the performance measurement with the intermediate performance target corresponding to the stage, and iv) based on the comparison, generating an alarm for transmission to a client computing device (124). [2] Method according to claim 1, wherein the stage duration of each stage definition is defined as one of i) a period of time or ii) a percentage of a total time corresponding to the charging process; and wherein the task definition defines the total time. [3] Method according to claim 1, wherein generating the alarm includes determining that an alarm period has elapsed within the stage. [4] Method according to claim 3, wherein the stage definition defines a sequence of alarm periods; and wherein the method further comprises: repeating the determination of a power measurement and generating an alarm for each alarm period. [5] Method according to claim 1, wherein the client computer device (124) comprises at least one consisting of a worker device and a supervisor device; and wherein the method further comprises: In response to the generation of the alarm, select at least one from the worker device and the supervisor device to receive the alarm. [6] Method according to claim 1, wherein the charging stages comprise an initial stage which has an intermediate performance target which defines a non-zero fill level of the container (112). [7] Method according to claim 1, wherein the charging stages include an active charging stage which has an intermediate performance target which defines at least one of a final fill level of the container (112) and a filling rate. [8] Method according to claim 1, wherein the charging stages include a final stage which has an intermediate performance target that indicates a closed state for a door of the container (112). [9] Method according to claim 1, wherein the charging stages include a transition stage which has an intermediate performance target which indicates an occupied state for the loading ramp (108-2). [10] Method according to claim 1, wherein the performance measurement includes at least one container fill level, an estimated time to completion (ETC) and a container door state. [11] Computer device for generating feedback for a container loading process, the computer device comprising: a memory (154) in which a set of load stage definitions is stored, defining sequential load stages of the container loading process, each stage definition including: i) an intermediate performance target and ii) a stage duration; a communication interface (158); and a processor (150) configured to: in response to the arrival of a container (112) at the loading ramp (108-2), to receive a task definition that defines a performance target for the loading process; to call up the charging stages in sequence and for each stage: i) Receiving sensor data depicting the interior of the container (112) from a sensor array (136) located at the loading ramp (108-2), ii) to determine a performance measurement of the container loading process based on the sensor data, iii) to compare the performance measurement with the intermediate performance target corresponding to the stage and iv) based on the comparison, to generate an alarm for transmission to a client computing device (124). [12] Computer device according to claim 11, wherein the stage duration of each stage definition is defined as one of i) a period of time or ii) a fraction of a total time corresponding to the loading process; and wherein the task definition defines the total time. [13] Computer device according to claim 11, wherein the processor (150) is configured to generate the alarm by determining that an alarm period has elapsed within the stage. [14] Computer device according to claim 13, wherein the stage definition defines a sequence of alarm periods; and wherein the processor (150) is further configured to repeat the determination of a power measurement and to generate the alarm for each alarm period. [15] Computer device according to claim 11, wherein the client computer device (124) comprises at least one consisting of a worker device and a supervisor device; and wherein the processor (150) is further configured to: In response to the generation of the alarm, at least one of the worker device and the supervisor device must be selected to receive the alarm. [16] Computer device according to claim 11, wherein the charging stages comprise an initial stage which has an intermediate performance target which defines a non-zero fill level of the container (112). [17] Computer device according to claim 11, wherein the charging stages include an active charging stage which has an intermediate performance target which defines at least one of a final fill level of the container (112) and a filling rate. [18] Computer device according to claim 11, wherein the charging stages include a final stage which has an intermediate performance target that indicates a closed state for a door of the container (112). [19] Computer device according to claim 11, wherein the loading stages include a transition stage which has an intermediate performance target which indicates an occupied state for the loading ramp (108-2). [20] Computer device according to claim 11, wherein the performance measurement includes at least one container fill level, an estimated time to completion (ETC) and a container door state.

Images