Method and apparatus for monitoring and managing loading dock and facility operation

Abstract

To provide a method and an apparatus for monitoring and managing a loading dock and facility operation.SOLUTION: In a material handling facility, an event manager of a main server comprises: a data analyzer to monitor first data indicating whether a truck trailer is present at a dock of the material handling facility and monitor second data which indicates a condition associated with a door at the dock and is different from the first data; a notification engine 916 being a notification generator to generate a notification based on the first data and the second data; and a web page analyzer 918.SELECTED DRAWING: Figure 9

Description

Field of Disclosure

[0001] This disclosure relates generally to monitoring systems, and more particularly, to methods and apparatus for monitoring and managing operations of loading docks and facilities.

[0002] A loading dock provides an area for vehicles (e.g., trucks, trailers, etc.) to move next to an elevated platform of a building (e.g., a material handling facility) so that cargo can be easily transferred between the vehicle and the building. Some loading docks include equipment such as dock levelers, vehicle restraints, and / or dock doors, any of which may be associated with one or more sensor / monitoring systems. In a material handling facility, additional equipment may be located to facilitate the movement, storage, and / or handling of cargo, such as grade level doors, HVAC (heating, ventilation, and air conditioning) systems, industrial doors for separating freezers and / or other rooms, conveyor systems, fans for moving air through the facility, lighting and signaling systems, etc. [Brief description of the drawings]

[0003] [Figure 1] FIG. 1 illustrates an example material handling facility in which the teachings disclosed herein may be implemented. [Diagram 2] 2 illustrates the example loading dock of FIG. 1 as viewed from the exterior of the material handling facility. [Diagram 3] 2 illustrates the example loading dock of FIG. 1 as viewed from inside the material handling facility with a trailer parked on the dock. [Figure 4] 4 is a cross-sectional side view of the exemplary loading dock of FIG. 1 with the associated trailer of FIG. 3. [Diagram 5] FIG. 2 is a block diagram of the example management server(s) of FIG. 1. [Figure 6] FIG. 2 is a block diagram of an exemplary main server of FIG. [Figure 7]FIG. 2 is a block diagram of an example database associated with the example main server of FIG. 1. [Figure 8] FIG. 7 is a block diagram of an exemplary video management system of the exemplary main server of FIG. 6. [Figure 9] 7 is a block diagram of an example event manager of the example main server of FIG. 6. [Figure 10] FIG. 1 is a block diagram of an example distributed system implementing the teachings disclosed herein. [Figure 11] FIG. 2 is a block diagram of an example implementation of an example local controller corresponding to any one of the controllers of FIG. 1. [Figure 12] 11 is a flow diagram representing example machine-readable instructions for implementing the example main server of FIG. 1, FIG. 6, and / or FIG. [Figure 13] 11 is a flow diagram representing example machine-readable instructions for implementing the example main server of FIG. 1, FIG. 6, and / or FIG. [Figure 14] 11 is a flow diagram representing example machine-readable instructions for implementing the example main server of FIG. 1, FIG. 6, and / or FIG. [Figure 15] 11 is a flow diagram representing example machine-readable instructions for implementing the example main server of FIG. 1, FIG. 6, and / or FIG. [Figure 16] 12 is a flow diagram representing example machine-readable instructions for implementing the example main server of FIG. 1, FIG. 6, and / or FIG. 10 or the example local controller of FIG. [Figure 17] 12 is a flow diagram representing example machine-readable instructions for implementing the example main server of FIG. 1, FIG. 6, and / or FIG. 10 or the example local controller of FIG. [Figure 18] 12 is a flow diagram representing example machine-readable instructions for implementing the example main server of FIG. 1, FIG. 6, and / or FIG. 10 or the example local controller of FIG. [Figure 19] 12 is a flow diagram representing example machine-readable instructions for implementing the example main server of FIG. 1, FIG. 6, and / or FIG. 10 or the example local controller of FIG. [Figure 20] 12 is a flow diagram representing example machine-readable instructions for implementing the example main server of FIG. 1, FIG. 6, and / or FIG. 10 or the example local controller of FIG. [Figure 21] 11A-11C are diagrams illustrating example graphical user interfaces of some example web pages hosted by a web server associated with the example main server(s) of FIGS. 1, 6, and / or 10. FIG. [Figure 22] 11A-11C are diagrams illustrating example graphical user interfaces of some example web pages hosted by a web server associated with the example main server(s) of FIGS. 1, 6, and / or 10. FIG. [Diagram 23] 11A-11C are diagrams illustrating example graphical user interfaces of some example web pages hosted by a web server associated with the example main server(s) of FIGS. 1, 6, and / or 10. FIG. [Figure 24] 11A-11C are diagrams illustrating example graphical user interfaces of some example web pages hosted by a web server associated with the example main server(s) of FIGS. 1, 6, and / or 10. FIG. [Figure 24B] 11A-11C are diagrams illustrating example graphical user interfaces of some example web pages hosted by a web server associated with the example main server(s) of FIGS. 1, 6, and / or 10. FIG. [Diagram 25] 11A-11C are diagrams illustrating example graphical user interfaces of some example web pages hosted by a web server associated with the example main server(s) of FIGS. 1, 6, and / or 10. FIG. [Figure 26] 11A-11C are diagrams illustrating example graphical user interfaces of some example web pages hosted by a web server associated with the example main server(s) of FIGS. 1, 6, and / or 10. FIG. [Figure 27]11A-11C are diagrams illustrating example graphical user interfaces of some example web pages hosted by a web server associated with the example main server(s) of FIGS. 1, 6, and / or 10. FIG. [Figure 28] 11A-11C are diagrams illustrating example graphical user interfaces of some example web pages hosted by a web server associated with the example main server(s) of FIGS. 1, 6, and / or 10. FIG. [Figure 29] 11A-11C are diagrams illustrating example graphical user interfaces of some example web pages hosted by a web server associated with the example main server(s) of FIGS. 1, 6, and / or 10. FIG. [Diagram 30] 11A-11C are diagrams illustrating example graphical user interfaces of some example web pages hosted by a web server associated with the example main server(s) of FIGS. 1, 6, and / or 10. FIG. [Diagram 31] 11A-11C are diagrams illustrating example graphical user interfaces of some example web pages hosted by a web server associated with the example main server(s) of FIGS. 1, 6, and / or 10. FIG. [Diagram 32] 11A-11C are diagrams illustrating example graphical user interfaces of some example web pages hosted by a web server associated with the example main server(s) of FIGS. 1, 6, and / or 10. FIG. [Diagram 33] 11A-11C are diagrams illustrating example graphical user interfaces of some example web pages hosted by a web server associated with the example main server(s) of FIGS. 1, 6, and / or 10. FIG. [Diagram 34] 11A-11C are diagrams illustrating example graphical user interfaces of some example web pages hosted by a web server associated with the example main server(s) of FIGS. 1, 6, and / or 10. FIG. [Diagram 35]11A-11C are diagrams illustrating example graphical user interfaces of some example web pages hosted by a web server associated with the example main server(s) of FIGS. 1, 6, and / or 10. FIG. [Diagram 36] 11A-11C are diagrams illustrating example graphical user interfaces of some example web pages hosted by a web server associated with the example main server(s) of FIGS. 1, 6, and / or 10. FIG. [Figure 37] 11A-11C are diagrams illustrating example graphical user interfaces of some example web pages hosted by a web server associated with the example main server(s) of FIGS. 1, 6, and / or 10. FIG. [Figure 38] 11A-11C are diagrams illustrating example graphical user interfaces of some example web pages hosted by a web server associated with the example main server(s) of FIGS. 1, 6, and / or 10. FIG. [Figure 39] 11A-11C are diagrams illustrating example graphical user interfaces of some example web pages hosted by a web server associated with the example main server(s) of FIGS. 1, 6, and / or 10. FIG. [Diagram 40] 11A-11C are diagrams illustrating example graphical user interfaces of some example web pages hosted by a web server associated with the example main server(s) of FIGS. 1, 6, and / or 10. FIG. [Diagram 41] 11A-11C are diagrams illustrating example graphical user interfaces of some example web pages hosted by a web server associated with the example main server(s) of FIGS. 1, 6, and / or 10. FIG. [Diagram 42] 11A-11C are diagrams illustrating example graphical user interfaces of some example web pages hosted by a web server associated with the example main server(s) of FIGS. 1, 6, and / or 10. FIG. [Diagram 43]11A-11C are diagrams illustrating example graphical user interfaces of some example web pages hosted by a web server associated with the example main server(s) of FIGS. 1, 6, and / or 10. FIG. [Diagram 44] 11A-11C are diagrams illustrating example graphical user interfaces of some example web pages hosted by a web server associated with the example main server(s) of FIGS. 1, 6, and / or 10. FIG. [Diagram 45] 11A-11C are diagrams illustrating example graphical user interfaces of some example web pages hosted by a web server associated with the example main server(s) of FIGS. 1, 6, and / or 10. FIG. [Diagram 46] 11A-11C are diagrams illustrating example graphical user interfaces of some example web pages hosted by a web server associated with the example main server(s) of FIGS. 1, 6, and / or 10. FIG. [Figure 47] 11A-11C are diagrams illustrating example graphical user interfaces of some example web pages hosted by a web server associated with the example main server(s) of FIGS. 1, 6, and / or 10. FIG. [Figure 48] 11A-11C are diagrams illustrating example graphical user interfaces of some example web pages hosted by a web server associated with the example main server(s) of FIGS. 1, 6, and / or 10. FIG. [Figure 49] 11A-11C are diagrams illustrating example graphical user interfaces of some example web pages hosted by a web server associated with the example main server(s) of FIGS. 1, 6, and / or 10. FIG. [Figure 50] 11A-11C are diagrams illustrating example graphical user interfaces of some example web pages hosted by a web server associated with the example main server(s) of FIGS. 1, 6, and / or 10. FIG. [Figure 51]11A-11C are diagrams illustrating example graphical user interfaces of some example web pages hosted by a web server associated with the example main server(s) of FIGS. 1, 6, and / or 10. FIG. [Figure 52] 11A-11C are diagrams illustrating example graphical user interfaces of some example web pages hosted by a web server associated with the example main server(s) of FIGS. 1, 6, and / or 10. FIG. [Figure 53] 11A-11C are diagrams illustrating example graphical user interfaces of some example web pages hosted by a web server associated with the example main server(s) of FIGS. 1, 6, and / or 10. FIG. [Figure 54] 11A-11C are diagrams illustrating example graphical user interfaces of some example web pages hosted by a web server associated with the example main server(s) of FIGS. 1, 6, and / or 10. FIG. [Figure 55] 11A-11C are diagrams illustrating example graphical user interfaces of some example web pages hosted by a web server associated with the example main server(s) of FIGS. 1, 6, and / or 10. FIG. [Figure 56] 11A-11C are diagrams illustrating example graphical user interfaces of some example web pages hosted by a web server associated with the example main server(s) of FIGS. 1, 6, and / or 10. FIG. [Figure 57] 11A-11C are diagrams illustrating example graphical user interfaces of some example web pages hosted by a web server associated with the example main server(s) of FIGS. 1, 6, and / or 10. FIG. [Figure 58] 11A-11C are diagrams illustrating example graphical user interfaces of some example web pages hosted by a web server associated with the example main server(s) of FIGS. 1, 6, and / or 10. FIG. [Figure 59]11A-11C are diagrams illustrating example graphical user interfaces of some example web pages hosted by a web server associated with the example main server(s) of FIGS. 1, 6, and / or 10. FIG. [Figure 60] FIG. 21 is a block diagram of an example processor platform configured to execute the instructions of FIGS. 12-20 to implement the example main server(s) of FIGS. 1, 6, and / or 10. [Figure 61] FIG. 21 is a block diagram of an example processor platform configured to execute the instructions of FIGS. 16-20 to implement the example local controller of FIG. 11. Detailed Description

[0004]

[0019] Generally, the same reference numbers are used throughout the drawing(s) and the accompanying specification to refer to the same or similar parts.

[0005]

[0020] In this specification, descriptive terms such as "first," "second," "third," and the like are used to identify multiple elements or components that may be referenced separately. Unless otherwise specified or understood based on the context of use, such descriptive terms are not intended to impute any sense of priority, physical order or placement in a list, or chronological order, but are used only as labels to refer to multiple elements or components separately to facilitate understanding of the disclosed examples. In some instances, the descriptive term "first" may be used to refer to an element in the detailed description, but the same element may be referred to in the claims by a different descriptive term such as "second" or "third." In such instances, it should be understood that such descriptive terms are used only to facilitate reference to multiple elements or components.

[0006]

[0021] FIG. 1 illustrates an exemplary material handling facility 100 in which teachings disclosed herein may be implemented. The material handling facility 100 may be associated with, for example, a storage warehouse, a distribution center, a manufacturing plant, a retail store, and the like. In the illustrated example, the material handling facility 100 includes multiple loading docks 102 (two shown) that provide a platform for trucks to back their trailers (or truck beds) to allow loading and / or unloading of materials between the inside of the trailer and the material handling facility 100. FIG. 2 illustrates an exemplary loading dock 102 as viewed from the exterior of the material handling facility 100. FIG. 3 illustrates an exemplary loading dock 102 as viewed from the interior of the material handling facility 100 with a trailer 300 parked on the dock 102. FIG. 4 illustrates a cross-sectional side view of the exemplary loading dock 102 with an associated trailer 300. 1-4, the example dock 102 includes a door 104, an entry barrier 106, a dock leveller 108, a vehicle restraint device 110, a presence / motion detector 112, and / or a notification system 114. In some examples, the dock 102 may be associated with and / or include other equipment, such as, for example, fans, lights, door seals, shelters, trailer stands, etc. In the illustrated example, the dock 102 includes a dock controller 116 for monitoring and / or controlling the operation of the door 104, the entry barrier 106, the dock leveller 108, the vehicle restraint device 110, the presence / motion detector 112, the notification system 114, and / or other equipment associated with the dock. In some examples, the dock controller 116 includes a display screen 117 for displaying information associated with the components monitored and / or controlled by the controller 116. The display screen 117 may be a touch screen through which a user may also enter commands and / or instructions for operating the controller and / or accessing specific information associated with the controller, the dock, or operations associated with the dock. In some examples, the display screen 117 may be incorporated into a different device that is separate from but in communication with the dock controller 116.Although a single controller 116 is shown as controlling all of the equipment associated with the dock 102, in some examples, each dock 102 may be associated with multiple controllers configured to control and / or monitor different ones of the doors 104, entry / exit barriers 106, dock levelers 108, vehicle restraint devices 110, presence / motion detectors 112, notification systems 114, and / or other equipment associated with the dock.

[0007]

[0022] A door 104 associated with the dock 102 is movable between an open position and a closed position to selectively open or close a gateway between an interior 118 of the material handling equipment 100 and an exterior environment 120. Thus, when a trailer 300 or truck bed is parked at the dock 102, the door 104 provides access to the trailer when the door 104 is in the open position and prevents such access when the door 104 is in the closed position.

[0008]

[0023] In some examples, the door 104 is associated with one or more sensors and / or a door monitoring system to facilitate monitoring and controlling the operation of the door 104. For example, one or more door status sensors can monitor and / or detect the status of the door 104 (e.g., whether the door is fully open, fully closed, partially open, partially closed, opening, or closing), one or more impact sensors can monitor and / or detect when something (e.g., a material handling vehicle (e.g., a forklift)) hits the door 104, one or more photoelectric eyes located on either side of the door 104 can monitor and / or detect when a person or object passes through the doorway when the door is open, one or more motion and / or presence sensors can monitor and / or detect activity in an area near the doorway, and one or more radio frequency identification (RFID) sensors can monitor and / or detect the identity of personnel, equipment, and / or materials passing through the doorway. One or more temperature sensors may monitor and / or detect temperature on one or both sides of the door 104, one or more airflow sensors may monitor and / or detect the flow of air through the door 104 (e.g., air passing through the door in an open or partially open position and / or air leaking through the door when closed in a closed position), one or more other environmental sensors may monitor and / or detect pressure, humidity, contaminants, particles, chemicals, etc., one or more actuator sensors may monitor and / or detect energy consumption and / or operation of a door actuator (e.g., a motor) used to open and close the door, and one or more image and / or video sensors (e.g., cameras) may be implemented to monitor and / or detect certain conditions of the dock based on image / video analysis. In some examples, the dock controller 116 receives output signals from these sensors to monitor and / or control the operation of the door 104.

[0009]

[0024] In some examples, the entry barrier 106 is constructed to provide a barrier that extends to a doorway associated with the door 104. The entry barrier 106 can block passage through the doorway even when the door 104 is in an open position. In this manner, the entry barrier 106 can be used as a safety precaution, for example, when the door 104 is open but there are no trailers parked or restrained at the dock 102 as shown in FIG. 2. The entry barrier 106 can also extend to the doorway in front of the door 104 in the interior 118 of the material handling facility 100 to protect the door 104 by reducing the likelihood that material handling equipment will collide with the door 104 when the door 104 is closed. In some examples, the entry barrier 106 is associated with a barrier sensor 302 (FIG. 3) that outputs a signal to the dock controller 116 to indicate the state of the entry barrier 106 (e.g., whether the barrier is in active use and blocking the entry (as shown in FIG. 2), stowed to provide passage for the entry (as shown in FIGS. 3 and 4), or in an intermediate state). In some examples, the barrier sensor 302 and / or a different sensor detects an impact (e.g., a force) on the barrier 106, and such an impact may indicate a collision with the barrier.

[0010]

[0025] Often, when a truck bed or trailer (e.g., trailer 300 shown in FIGS. 3 and 4 ) is parked on the dock 102, a gap may be located between the trailing edge of the truck bed or trailer and the outer surface of the platform of the dock 102. The dock leveller 108 provides an adjustable bridge across this gap, across which material handling equipment may navigate between the interior 118 of the material handling facility 100 and the trailer of a vehicle parked on the dock 102. Additionally, the dock leveller 108 may be vertically adjustable to act as a ramp to compensate for trailers having different heights relative to the platform of the dock 102. In some examples, the dock leveller 108 includes one or more sensors to facilitate monitoring and control of the operation of the dock leveller 108. For example, the leveller sensor may produce an output signal indicating whether the dock leveller 108 is in an active state (extended to bridge the gap between the dock platform and the trailer, as shown in FIGS. 3 and 4), an inactive state (with the leveller in a stowed position, as shown in FIG. 2), or an intermediate state. In some examples, a limit switch may detect that the trailer is being pulled away from the dock 102 when the dock leveller 108 is in an active state (e.g., detecting a drop of the leveller when the extended end is no longer supported by the trailer). In such examples, the limit switch output may trigger the dock controller 116 to retract the dock leveller 108 to the inactive stowed position.

[0011]

[0026] The vehicle restraint device 110 associated with the dock 102 is positioned in the external environment 120 to engage some portion of the vehicle (e.g., trailer 300) parked at the dock 102 to reduce inadvertent vehicle movement (e.g., the vehicle moving as a result of material handling equipment moving around in the trailer and / or the driver prematurely leaving the platform). In some examples, the vehicle restraint device 110 engages the rear impact guard of the vehicle (e.g., ICC bar 400 shown in FIG. 4) to restrain the vehicle. In some examples, the vehicle restraint device 110 engages tires and / or any other suitable portion of the vehicle. In some examples, the vehicle restraint device 110 includes one or more sensors to facilitate monitoring and controlling the operation of the vehicle restraint device 110. For example, the restraint sensor may generate an output signal indicating that the vehicle restraint device 110 is in a locked position (e.g., in a home position to engage / restrain the vehicle) or an unlocked position (e.g., stored away from the vehicle). Alternatively or additionally, the restraint sensor(s) may provide an output signal indicative of the position of the restraint device relative to a reference point and / or the force(s) experienced by the restraint device to determine whether the restraint device is actively engaging / restraining the vehicle.

[0012]

[0027] In the example illustrated in FIG. 1, the presence / motion detector 112 represents one or more presence or motion detector systems. In some examples, the presence / motion detector 112 includes a presence detector system to detect the presence of a trailer 300 located at the dock 102. The term "trailer" refers to a trailer, whether coupled to a tractor, or alternatively to a vehicle having a cargo hold or platform, for purposes of discussion related to sensing its presence or motion. In some examples, the presence of the trailer 300 is detected via one or more trailer sensors 202 ( FIG. 2 ) positioned in the external environment 120 at and / or near the building of the material handling facility 100. The trailer sensor(s) 202 may be implemented using any suitable sensor, such as, for example, a photoelectric eye, a proximity sensor, a motion sensor, an inductive loop sensor, a light detection and ranging (LIDAR) system, etc. In some examples, the presence / motion detector 112 may include a presence detector system to detect the presence of personnel / equipment (e.g., a person walking and / or operating material handling equipment, an autonomous vehicle, etc.) in the trailer 300 parked at the loading dock 102 (e.g., loading and / or unloading cargo) or outside the facility at the entrance to the dock 102. In some examples, the presence of personnel / equipment in the trailer 300 is detected based on a motion sensor 204 (FIGS. 2-4) facing the trailer from a position within the material handling facility 100. Additionally or alternatively, the presence / motion detector 112 may include a presence detector system to detect the presence of personnel / equipment / material on the platform of the leveler 108, in the leveler pit, and / or otherwise near the dock 102. In some examples, the presence of personnel / equipment in the material handling facility 100 proximate to the dock 102 is detected based on motion sensors 304 (FIGS. 3 and 4) facing the leveller and / or surrounding area. Additionally or alternatively, the presence of personnel / equipment / materials can be detected in a leveller pit 402 (FIG. 4) below the dock leveller 108 based on one or more presence / motion sensors 404 in the leveller pit 402 (e.g., when the leveller is stored in a vertical upright position).In addition to detecting the presence of vehicles, personnel, or material handling equipment, any one of the presence / motion systems represented by the presence / motion detector 112 of FIG. 1 may enable one to determine the movement (e.g., speed, direction, etc.), location (e.g., proximity, orientation, etc.), size, shape, etc., and combinations thereof, of vehicles, personnel, equipment, or other items (e.g., products, materials), and may enable one to distinguish between these items.

[0013]

[0028] The notification system 114 of the illustrated example may include multiple separately functioning notification systems including one or more visual indicators (e.g., lights, display screens, etc.) and / or one or more audible indicators (e.g., horns, bells, sirens, speakers, etc.) to inform personnel near the dock 102 of a particular status, warning, event, and / or other condition associated with some aspect or state of the dock 102 and / or vehicles located thereon. Additionally or alternatively, some of the visual indicators may be lights intended to improve illumination and / or visibility of areas associated with the dock 102 rather than to indicate any particular status or condition associated with the dock. The visual and / or audible indicators of the notification system 114 may be located in the interior 118 of the material handling equipment 100 and / or in the external environment 120 outside the material handling equipment 100 depending on the purpose of the indicator.

[0014]

[0029] In some examples, at least some indicators within the material handling equipment are positioned and / or oriented toward the exterior environment 120 (e.g., the end of an arm associated with the motion sensor 204 shown in FIGS. 2-4 ) to illuminate the interior of a trailer parked at the dock 102 when the door 104 is open, to be visible from the interior of the trailer, and / or to be audible from the interior of the trailer. Such indicators can provide additional visibility to personnel entering the trailer to load or unload cargo. Such indicators can also alert personnel within the trailer to potential safety risks, such as when the vehicle restraint device 110 is not engaged, and / or the presence of persons near the platform of the dock 102 that may not be visible from within the trailer. Other indicators within the material handling equipment 100 can be positioned and / or oriented to illuminate, be visible from, and / or be audible from areas of the interior 118 of the equipment (e.g., the dock platform and / or surrounding areas). Some such indicators may serve as warnings regarding potential safety risks, such as when the vehicle restraint device 110 is not engaged, and / or the presence of people in the trailer who may be about to unexpectedly turn up. Additionally or alternatively, the indicators may indicate the operational status of equipment associated with the dock 102.

[0015]

[0030] In some examples, the notification system 114 of FIG. 1 includes a timing indicator 306 (FIG. 3) positioned adjacent the door 104 for viewing from within the material handling equipment 100 to display a timer indicating how long the trailer has been parked at the dock 102. In this manner, personnel can be informed of how many hours remain before overdue and / or detention fees begin to accrue. In some examples, the timing indicator 306 is implemented via a display screen 117 associated with the dock controller 116. In some examples, the timing indicator 306 can count down instead of counting up. In some examples, when the timer reaches a threshold, the timing indicator 306 can change appearance (e.g., change color, start flashing, etc.) and / or activate another indicator to indicate to personnel that they are approaching an end time related to a particular operational constraint (e.g., the need to quickly finish loading and / or unloading the trailer). In some examples, the timing indicators 306 may indicate (e.g., based on color, flashing, etc.) that the loading and / or unloading of a trailer at a corresponding dock 102 is prioritized over the loading and / or unloading of other trailers at other docks 102. In some such examples, the prioritization may be based on projected time allocations and / or cost incurrences across the docks 102 of the material handling facility 100, taking into account available operational resources (e.g., personnel on hand, available material handling equipment, loading status, cross-dock order status, etc.).

[0016]

[0031] In some examples, one or more indicators are positioned outside the material handling equipment 100 to illuminate, be visible from, and / or be audible from an area outside the dock 102. In some examples, such indicators may be lights that illuminate an area to provide additional visibility to persons in the external environment 120 (e.g., a driver backing a trailer into the dock 102). Additionally or alternatively, in some examples, the indicators may be lights that provide warnings and / or guidance to persons in the external environment 120. For example, as shown in FIG. 2, the light indicators 206 on the exterior of the equipment 100 include red and green lights to guide truckers when they can back their trailers (e.g., trailer 300 in FIGS. 3 and 4 ) into an area adjacent to the dock 102 and / or when they can exit the dock 102. In some examples, lights and / or audible indicators may be used to indicate to the driver when the vehicle restraints are in override, when dock equipment is undergoing maintenance, when there are people / objects in or near the trailer's path, etc. These conditions may be communicated via separate indicators utilizing different states of a common indicator (color / tone changes, flashing / audio patterns, etc.) or combinations thereof. Additionally, in some examples, indicators associated with the dock 102 include lights and / or audible alarms that indicate to a person standing near the entrance to the dock that the truck is in reverse.

[0017]

[0032] In some examples, the dock controller 116 controls different indicators associated with the notification system 114 based on one or more of signals received from various sensors associated with the door 104, the entry barrier 106, the dock leveller 108, the vehicle restraint 110, and / or the presence detector 112. For example, in some such examples, the dock controller 116 causes the light indicator 206 to provide a red signal (e.g., a red light) whenever the restraint signal indicates that the vehicle restraint 110 is active and engaged with a trailer. As another example, if the door sensor indicates that the door 104 is open when the presence detector 112 does not detect a trailer parked on the dock 102, there is a risk that the open door will cause the dock platform to fall. Thus, in some such examples, the dock controller 116 can turn on a warning indicator to alert nearby individuals regarding an exposed fall. However, in some such instances, the dock controller 116 may not trigger a warning indicator when the barrier sensor 302 provides a signal indicating that the entry barrier 106 is in active use to prevent passage through an open entryway. Thus, different signals output from different ones of the various sensors may be used in combination to trigger the activation or change of state of an indicator associated with the notification system 114 to provide warnings, notifications, and / or guidance to persons within an area associated with the dock 102.

[0018]

[0033] The material handling facility 100 includes a dock 102 having various components and / or systems to facilitate the transfer of goods between trailers and the material handling facility 100, and the material handling facility 100 of FIG. 1 also includes other components and / or systems to facilitate the handling, movement, and / or storage of goods within the interior 118 of the material handling facility 100. In some examples, these components and / or systems may operate substantially independently of one another with separate controllers that monitor and / or control their operation. In particular, as shown in FIG. 1, the material handling facility 100 includes one or more door controller(s) 122, heating, ventilation, and air conditioning (HVAC) controller(s) 124, fan controller(s) 126, conveyor controller(s) 128, and / or traffic controller(s) 130. In some examples, the material handling facility 100 may include other equipment associated with the facility (e.g., smart barriers, machine guards, building automation, lighting, fire, and security systems, etc.) and their respective controllers.

[0019]

[0034] In the illustrated example, the door controller 122 serves to control the operation of industrial doors located within the material handling facility 100. In some examples, such doors are positioned at various locations within the material handling facility 100 to separate different rooms and / or areas of the facility. Such doors may include sensors similar or the same as those described above for the doors 104 of the loading dock 102 to enable the door controller 122 to monitor and / or control the doors. For example, such doors may include sensors such as: one or more door status sensors may indicate the status of the door (e.g., open, closed, opening, closing, etc.), one or more impact sensors may monitor and / or detect when a material handling vehicle hits the door, one or more photoelectric eyes may monitor and / or detect when a person or object passes through a doorway associated with the door, one or more motion and / or presence sensors may monitor and / or detect activity in an area proximate the doorway, one or more RFID sensors may monitor and / or detect the identity of personnel, equipment, and / or materials passing through the doorway, and / or other sensors may monitor and / or detect the identity of personnel, equipment, and / or materials passing through the doorway. or detect, one or more temperature sensors may monitor and / or detect temperature on one or both sides of the door, one or more other environmental sensors may monitor and / or detect pressure, humidity, contaminants, particles, chemicals, etc., one or more airflow sensors may monitor and / or detect the flow of air through the door 104 (e.g., air passing through the door in an open or partially open position and / or air leaking through the door when closed in a closed position), and one or more actuator sensors may monitor and / or detect energy consumption and / or operation of a door actuator (e.g., a motor) used to open and close the door. In some examples, the door controller 122 includes and / or is communicatively coupled to a local display screen similar to the display screen 117 of the dock controller 116.

[0020]

[0035] In some examples, how the door controller 122 uses the signals output by such sensors may depend on the location and / or intended use of the associated door. For example, one or more doors may provide access to a freezer room. In such examples, the associated door controller 122 may monitor feedback signals provided by temperature sensors to ensure that the temperature on the freezer side of the room remains below a temperature setpoint. Additionally or alternatively, the door controller 122 for the freezer door may monitor how often and / or how long the door is opened (based on feedback from door status sensors) and generate an alarm when the frequency or duration of the door opening exceeds a corresponding threshold. In other examples, one or more doors may be used to control access to a clean room with relatively low levels of contaminants. In some such examples, the door controller 122 may monitor feedback signals from one or more airflow and / or pressure sensors to ensure that the amount of airflow (which may disperse contaminants) is maintained below a suitable threshold or that a certain differential pressure is maintained on both sides of the doorway. In some examples, the separate doors may be configured with an interlocking relationship such that the operation of one door is coordinated based on the state or operation of the second door (e.g., only one of the two doors may be open at any given time). In such examples, signals from sensors monitoring the operation of each door may be provided to separate door controllers 122 associated with each door (or to a single controller 122 that controls both doors).

[0021]

[0036] 1, the HVAC controller 124 serves to monitor and / or control the delivery of conditioned air to various areas within the material handling equipment 100 via air ducts. In some examples, the HVAC controller 124 monitors and / or controls the operation (e.g., speed, energy consumption, etc.) of blowers that force air through the air ducts. In some examples, the HVAC controller 124 receives feedback signals from temperature sensors positioned throughout the material handling equipment 100. In some examples, airflow sensors, humidity sensors, and / or other types of sensors (e.g., monitoring pressure, contaminants, particles, chemicals, etc.) may also provide input to the HVAC controller 124 to facilitate control and monitoring of associated HVAC systems.

[0022]

[0037] 1, the fan controller 126 serves to monitor and / or control one or more fans within the material handling facility 100. The fans may be positioned in the facility to augment air circulation beyond that provided by ventilation from ducts associated with the HVAC controller 124. In some examples, such fans include one or more sensors to detect the status of an operating parameter of the fan (e.g., on, off, fault (e.g., unable to start), speed, energy usage, etc.), which may be provided as a feedback signal to the fan controller 126.

[0023]

[0038] In the example illustrated in FIG. 1, the conveyor controller 128 serves to monitor and / or control one or more conveyor systems in the material handling facility 100. In some examples, the conveyor system may include multiple conveyor segments that are activated separately. In some examples, one or more sensors may be implemented to detect the state of each conveyor segment (e.g., active (moving), inactive (not moving)), the associated speed of a moving conveyor segment, and / or the position and / or shape of each conveyor segment (e.g., slope, stretch, etc.). Additionally or alternatively, the one or more sensors may provide an output indicative of the energy usage of a motor used to operate such conveyor segment. Furthermore, in some examples, the conveyor system may include one or more sensors to detect obstructions and / or jams on the conveyor. The output of any of these sensors may be used as a feedback signal received by the conveyor controller 128 to monitor and / or control the operation of such conveyor system. In some examples, feedback from the conveyor system can be used to measure and / or infer the amount and / or progress of cargo being moved to or from trailers parked at the dock.

[0024]

[0039] In the example illustrated in FIG. 1 , traffic controller 130 serves to monitor the flow of pedestrian and / or motorized vehicle (e.g., material handling equipment such as forklifts) traffic throughout material handling facility 100 and control signals to direct traffic and / or notify / warn personnel regarding traffic approaching from different directions. In some examples, a traffic signal system is positioned at the intersection of two or more aisles or travel paths for traffic within material handling facility 100 and has one or more signal lights and / or associated displays facing each aisle or travel path. In some examples, traffic controller 130 causes the example traffic signal system's signal lights and / or displays to provide different signals based on traffic detected along each of the aisles and / or travel paths associated with the traffic signal system. In some examples, traffic is detected along each aisle and / or travel path by individual traffic sensors (e.g., motion sensors) facing each aisle or travel path. Thus, if two traffic sensors facing separate paths both detect approaching traffic, the traffic controller 130 may generate a signal on a display facing the direction of the oncoming traffic to indicate that there is traffic approaching from the other direction. Additionally or alternatively, the traffic controller 130 may illuminate a single light visible from all directions to indicate that crossing traffic is approaching from at least two directions. In some examples, both the traffic signal display and the traffic sensor are located at the associated intersection (e.g., in a common housing). In some examples, the traffic signal system includes a display and / or a traffic sensor positioned remotely relative to the associated intersection and / or the traffic controller 130.

[0025]

[0040] In the example illustrated in FIG. 1, the controllers 116, 122, 124, 126, 128, 130 each communicate with a main server 132. More specifically, in some examples, the dock controller 116, the door controller 122, the HVAC controller 124, the fan controller 126, the conveyor controller 128, and the traffic controller 130 transmit values ​​corresponding to operational and / or status parameters set in the respective controllers and / or feedback signals collected from any sensors associated with the respective controllers. In this manner, the main server 132 aggregates in one location all available data associated with the various separate systems in the material handling facility 100. The aggregation of data from disparate sources allows the main server 132 to analyze and / or integrate the controller data to identify relationships that would not otherwise be possible. As described in more detail below, in some examples, the main server 132 organizes the aggregated controller data for presentation to end users via one or more dashboards or graphical user interfaces targeted to the end users' particular interests. The graphical user interface may be presented by one or more web pages, apps, applets, applications, etc. In some examples, the graphical user interface may be configurable to provide notifications and / or alerts when certain events are detected based on the values ​​of a combination of different parameters monitored by one or more of the controllers 116, 122, 124, 126, 128, 130. Further details regarding an exemplary main server 132 implementation are provided below with respect to FIGS. 6-10. Additionally or alternatively, in some examples, the main server 132 may transmit information back to the controllers 116, 122, 124, 126, 128, 130. In some such examples, the information transmitted to these controllers is passive in that it does not affect the operation of the components controlled by the controllers.In such examples, this information may be displayed on a local display screen (e.g., display screen 117 of dock controller 116 shown in FIG. 3 and / or a similar local display screen associated with one of the other controllers 122, 124, 126, 128, 130) and provided for viewing by personnel located near the controller. In other examples, the information transmitted from main server 132 to the controller may be active, in that it includes commands that cause the controller to implement certain actions. Although the illustrated example shows main server 132 located at material handling facility 100, in other examples main server 132 may be located remotely from material handling facility 100.

[0026]

[0041] In the illustrated example of FIG. 1, the material handling facility 100 includes one or more management server(s) 134 that facilitate management of various aspects of equipment assets and / or work operations of the material handling facility 100. In some examples, the management server(s) 134 communicate with the main server 132 via a bus, a local area network (LAN), and / or a wide area network (e.g., the Internet). An example management system associated with the management server(s) 134 of FIG. 1 is depicted diagrammatically in FIG. 5. As shown in FIG. 5, the example management server(s) 134 includes a dock / yard management system 502, an inventory control system 504, and a video management system (VMS) 506. In the illustrated example, the dock / yard management system 502, the inventory control system 504, and the video management system 506 are communicatively coupled via a bus and / or network to which the main server 132 is connected. 5 may be combined, divided, rearranged, and / or omitted from the example management server(s) 134. Further, in some examples, the management server(s) 134 may be associated with additional components and / or management systems (e.g., a warehouse management system (WMS), an enterprise resource planning (ERP) system, etc.) in addition to and / or as an alternative to those shown in the described examples. Additionally or alternatively, in some examples, one or more of a dock / yard management system 502, an inventory control system 504, and a video management system 506 may be combined with and / or implemented by the main server 132.

[0027]

[0042] 5 monitors and tracks all vehicles (e.g., delivery trucks, trailers, forklifts, hand trucks, hand carts, etc.) and / or other equipment associated with operation around the exterior of material handling facility 100. In some examples, dock / yard management system 502 generates alerts and / or notifications for scheduled maintenance, repairs, and / or replacement of equipment assets.

[0028]

[0043] 5 monitors and tracks inventory stored in the material handling facility 100. More specifically, this may be accomplished by identifying and monitoring the contents of trucks being loaded and unloaded at the dock 102. In some examples, the inventory control system 504 timestams the actual transfer of goods into or out of the facility. In some examples, the inventory control system 504 tracks the location and quantity of materials / products within the material handling facility 100.

[0029]

[0044] The example video management system 506 of FIG. 5 manages access to and collects video data from one or more cameras 508 positioned throughout the material handling facility 100. The cameras 508 may be Internet Protocol (IP) cameras, Universal Serial Bus (USB) cameras, analog cameras, closed circuit television (CCTV) cameras, and / or any other suitable type of cameras. The cameras 508 may be located in the interior 118 of the facility and / or located outside to monitor the dock 102 or yard. Additionally or alternatively, the cameras 508 may be positioned to monitor other spaces within the material handling facility, such as spaces associated with one or more of the door controller 122, the HVAC controller 124, the fan controller 126, the conveyor controller 128, and / or the traffic controller 130. In some examples, the video management system 506 extracts and / or generates video segments in response to detection of particular events triggered within the material handling facility 100. As described in more detail below, such events may be based on data collected by the main server 132 from the different controllers 116, 122, 124, 126, 128, 130. In some examples, the generated video segment may capture the circumstances giving rise to the detected event. In some examples, the video management system 506 may be implemented by and / or integrated into the main server 132. Additional details regarding implementations of the video management system 506 associated with the main server 132 are provided below with respect to Figures 6 and 8.

[0030]

[0045] Returning to the example illustrated in FIG. 1, the main server 132 may also communicate with one or more remote server(s) 136 that are not located at the material handling facility 100. In some examples, the remote server(s) 136 correspond to additional servers equivalent to the main server 132 and located at other locations associated with other material handling facilities and / or the enterprise operating the material handling facility 100 of FIG. 1. Additionally or alternatively, in some examples, the remote server(s) 136 may correspond to a server maintained by an equipment manufacturer associated with one or more of the dock controller 116, the door controller 122, the HVAC controller 124, the fan controller 126, the conveyor controller 128, and / or the traffic controller 130, or a remote asset management system for other equipment in the facility. For example, the remote server 136 may provide equipment warranty information, equipment version and / or update information, equipment installation dates, records of technician and / or service call requests, etc.

[0031]

[0046] For purposes of explanation, data reported from the different controllers 116, 122, 124, 126, 128, 130 of FIG. 1 to the main server 132 is referred to as IO (input / output) data, since it includes inputs and outputs monitored and / or provided by the respective controllers. In the illustrated example, the IO data collected by the main server 132 is transmitted from the controllers 116, 122, 124, 126, 128, 130 via a wireless mesh network (other network types can also be used (e.g., wired or wireless non-mesh)). Thus, as shown in the illustrated example of FIG. 1, the controllers 116, 122, 124, 126, 128, 130 are each equipped with an IO communication board 133 that includes a wireless transceiver (e.g., a radio) for transmitting IO data according to any suitable communication protocol. In some examples, the IO boards of the controllers 116, 122, 124, 126, 128, 130 transmit IO data directly to a receiver associated with the main server 132. In other examples, IO data from one controller can be transmitted indirectly to the main server 132 via an IO communication board 133 in a different controller and / or any other device or component capable of communicating in a mesh network (e.g., one or more gateways, relays, repeaters, etc.). In some examples, the IO boards of the controllers 116, 122, 124, 126, 128, 130 are implemented with reusable firmware modules that convert and normalize data collected by different controllers into a common format corresponding to a particular communication protocol. The reusable nature of the firmware allows it to be embedded into existing products and therefore can be modified to integrate into the monitoring system of the main server 132.Enabling each of the controllers 116, 122, 124, 126, 128, 130 to transmit data in a common format according to a single communications protocol enables the main server 132 to directly integrate and correlate data collected from different types of controllers, regardless of the original source of the data and / or the nature and / or type of sensors used to generate such data.

[0032]

[0047] In some examples, transmissions from controllers 116, 122, 124, 126, 128, 130 reporting IO data include device identification information, including an identifier, name, and / or type for the device or controller sending the message, as well as an address for the device on the network. The device identification information allows the main server 132 to determine the source of the message (e.g., the controller that sent the message). In some examples, each controller is modeled as a set of generic data points with a corresponding address to identify each data point. In such examples, each data point represents the value of a particular IO parameter monitored and / or generated by the controller. In some examples, the value of the IO parameter corresponds to a measured output of a sensor monitored by the corresponding controller (e.g., the output of a door sensor indicating whether the door 104 is open or closed). In other examples, the value of the IO parameter is derived based on one or more measurements rather than being directly measured or sensed (e.g., deriving the transition state of the door 104 (e.g., opening or closing) based on the last state of the door sensor and a signal from an actuator sensor indicating that the door actuator is moving the door).

[0033]

[0048] In some examples, a message transmitted to the main server 132 includes the current values ​​of one or more data points (e.g., IO parameters) associated with the device sending the message along with a unique address for each data point. Such a message is referred to herein as an IO message. The main server 132 can determine the meaning or importance of the reported data points (e.g., values ​​of IO parameters) in the IO message based on configuration data associated with the IO parameters that the main server 132 has stored in a database. The main server 132 can identify the correct configuration data specific to each IO parameter based on the address for the IO parameter included in the transmitted message along with the value of the IO parameter. In some examples, a controller can provide the main server 132 with configuration data for all data points associated with the controller for uploading to the database when the controller is initially configured with a wireless network. Uploading the configuration data to the database can be accomplished automatically when the associated controller implements the aforementioned reusable firmware module that serves to format and normalize all values ​​reported to the main server 132. If the controller or other device does not include a firmware module (e.g., a device manufactured by a third party), uploading the configuration parameters can be accomplished manually.

[0034]

[0049] In some examples, the nature of the IO board and associated radio used to transmit IO messages to the main server 132 depends on the nature and / or structure of the corresponding controller. In some examples, the IO board and associated radio are integrated into the main printed circuit board (PCB) of the associated controller. That is, a reusable firmware module implementing the communication protocol is directly implemented by the main PCB of the controller. In the example illustrated in FIG. 1, the door controller 122 includes such an integrated radio 138.

[0035]

[0050] In other examples, the radio can be built on a limited purpose interface board communicatively coupled to the main PCB of the associated controller via a serial port connection. In some such examples, the limited purpose radio relies on the memory and processor of the main PCB to provide IO communication functions associated with generating and formatting IO data for wireless transmission via the radio. That is, the main PCB of the controller can be modified to include reusable firmware modules without requiring a significant redesign of the controller since the radio is provided separately on a daughter board. In the example illustrated in FIG. 1, the dock controller 116 includes such a limited purpose radio interface board 140.

[0036]

[0051] In other examples, the IO board and associated radio can be built on a generic interface board with a local processor and memory implementing a reusable firmware module that handles processing and formatting of IO data for transmission via the radio. In some examples, such an IO board can be communicatively coupled to the controller in parallel with the controller's main PCB. That is, in such examples, the IO board directly monitors inputs and outputs associated with the controller, independent of the controller's main PCB. Such generic interface boards can be retrofitted to controllers and / or associated equipment that are not otherwise capable of generating IO data conforming to the particular communication protocol used to report to the main server 132 (e.g., devices that cannot be modified to include reusable firmware modules). In the example illustrated in FIG. 1, the HVAC controller 124, the conveyor controller 128, and the traffic controller 130 include such a generic radio interface board 142. In some such examples, the radios can be located on separate interface boards from the rest of the IO boards to allow for interchangeability with each other. Additionally, the use of separate boards allows the system to be configured for all digital IO, all analog IO, serial communications, Ethernet, and / or any combination of digital IO, analog IO, serial communications, and Ethernet, depending on the application for which the interface boards are used.

[0037]

[0052] In some examples, any one of the integrated radio 138, the limited purpose radio interface board 140, or the general purpose radio interface board 142 may include a Universal Serial Bus (USB) connection to facilitate configuration and commissioning of an associated device. Additionally or alternatively, in some examples, configuration and commissioning may be accomplished via a Bluetooth® connection provided by any one of the integrated radio 138, the limited purpose radio interface board 140, and / or the general purpose radio interface board 142.

[0038]

[0053] 1, the fan controller 126 monitors its associated fans using the Modbus protocol. In some examples, the fan controller 126 includes a wireless radio interface board 144 that includes a reusable Modbus module to snoop and wirelessly stream Modbus communications to the main server 132 without any modification of the format of the data. Thus, in some examples, the main server 132 includes the ability to interpret IO data received from the fan controller 126 as normalized and aggregated against other IO data received from the other controllers 116, 122, 124, 128, 130.

[0039]

[0054] As mentioned above, main server 132 serves as a central hub for aggregating and / or consolidating data associated with disparate systems operating throughout material handling facility 100. In some examples, main server 132 includes and / or is associated with web server 146 that hosts one or more web pages accessible by users via client devices 148. Client devices 148 may be any suitable computing device having a browser for accessing the web pages hosted by web server 146. Thus, client devices 148 may correspond to one or more worker stations located at the material handling facility (e.g., within a logistics office of the facility). In some examples, client devices may be portable devices (e.g., tablets, smartphones, etc.) carried by personnel throughout material handling facility 100 and / or away from the facility. Additionally, some client devices 148 may be portable devices used by truck drivers transporting trailers in and out of material handling facility 100 and / or yard jockeys repositioning trailers within dock 102 and / or the yard of material handling facility 100.

[0040]

[0055] Different web pages may include different graphical user interfaces designed to present different types of information in easily understandable formats that facilitate a user to recognize relationships in data collected from different sources within the material handling facility 100. In some examples, the main server 132 automatically updates one or more of the web pages via web-based communications 150 whenever new data pertaining to a particular web page is collected. Additionally, in some examples, the web pages are designed to receive user input that is again provided to the main server 132. In some examples, updates to the web pages are implemented based on pull requests from client devices requesting updated information. Additionally or alternatively, in some examples, updates may be pushed to web pages actively opened by a particular client device for dynamic updates through the use of push requests. In some examples, user input received on one web page may be pushed to other web pages (e.g., other web pages accessed by other client devices 148) that display information related to the user input. Although graphical user interfaces are disclosed herein with respect to web pages, graphical user interfaces can also be presented using other than web pages (e.g., via apps, applets, applications, etc.).

[0041]

[0056] In some examples, the main server 132 analyzes information provided by separate systems within the material handling facility 100 to identify situations, conditions, and / or events (collectively referred to herein as events) that may require a response or other resolution. In some examples, the identification of such events is based on configurable rules that depend on feedback (e.g., specific IO data) from multiple different ones of the controllers 116, 122, 124, 126, 128, 130 and / or servers 134, 136. In some examples, the main server 132 triggers a specific response based on detection of a specific event (e.g., when the conditions of an associated event rule are met). In some examples, the response may again include providing information and / or instructions to one or more of the controllers 116, 122, 124, 126, 128, 130 to cause such controller to initiate some action (e.g., opening or closing a door, changing the operating state of a fan, blower, or conveyor, toggling the state of an indicator light, etc.) on the equipment associated with the corresponding controller. In some examples, the main server 132 can respond to certain events by generating alerts, warnings, notifications, log entries, and / or reports (collectively referred to herein as notifications) that are provided to one or more client devices 148. In some examples, such notifications can be provided via web communications 150 when a web page is updated. Additionally or alternatively, the main server 132 can provide notifications to the client devices 148 independent of the web server 146 using other forms of network communications 152, such as, for example, email messages, SMS (Short Message Service) messages, push notifications, etc. Additionally or alternatively, the main server 132 can transmit notifications for rendering via local display screens (e.g., display screen 117) associated with one of the controllers 116, 122, 124, 126, 128, 130 throughout the facility 100.In this manner, such notifications provide information to personnel in close proximity to the same controller that reported the information to the main server 132 used to generate the notification.

[0042]

[0057] Providing automatic notifications to individuals as disclosed herein allows those individuals to become aware of certain events that would otherwise remain unknown to them. This is a significant improvement to the efficient use and operation of the aforementioned control system, as these events may correspond to activities that are disruptive to the efficient loading, unloading, and / or storage of goods at the facility 100, activities that pose safety risks to personnel in and / or around the facility 100, activities that result in energy losses that lead to increased strain on (and associated costs of) the HVAC system, etc. By monitoring various systems and operations within the material handling facility 100 and automatically generating and transmitting notifications, the examples disclosed herein allow such individuals to implement appropriate actions in response to various notifications (e.g., undoing previous actions that triggered the notification, providing additional training to reduce or eliminate the triggering event, scheduling and / or implementing preventative and / or maintenance actions, reconfiguring process flows and / or equipment usage procedures, etc.).

[0043]

[0058] Figure 6 is a block diagram illustrating an implementation of the example main server 132 of Figure 1. As shown in Figure 6, the example main server 132 includes a web server 146, an example network communication interface 602, an example IO network interface 604, an example restart watchdog 606, an example database 608, an example pull service manager 610, an example push service manager 612, an example video management system 614, and an example event manager 616.

[0044]

[0059] 6 enables communication with client devices 148 independent of the web server 146. For example, the network communication interface 602 can send email messages and / or SMS messages to one or more client devices 148. Additionally, in some examples, the network communication interface 602 can send and receive data to and from the local management server(s) 134 and / or the remote server(s) 136. In some examples, data received from the servers 134, 136 is stored in a database 608.

[0045]

[0060] 6 enables communication with the controllers 116, 122, 124, 126, 128, 130 according to a communication protocol that normalizes data associated with each controller into a consistent format. That is, the IO network interface 604 can receive IO data reported by the controllers 116, 122, 124, 126, 128, 130 and store that data in the database 608 for later analysis by the event manager 616. In some examples, the IO network interface 604 formats and / or normalizes data received from different controllers before providing the data to the database 608 for storage and / or the event manager 616 for analysis.

[0046]

[0061] The example restart watchdog 606 of FIG. 6 initiates and monitors the web server 146 and the IO network interface 604 for possible failures. When a failure is detected, the restart watchdog 606 can automatically restart the web server 146 and / or the IO network interface 604. Such a restart can trigger a process to label any OI data in the database that was collected or transmitted via the IO network interface 604 around the time of the fault / failure as possibly erroneous, and can then require replacement with new IO data. Additionally, in some examples, the restart watchdog 606 logs any detected failures to the database 608. In this manner, the cause of the failure and possible remedial actions can be determined by later analysis.

[0047]

[0062] As previously mentioned, the exemplary database 608 stores IO data and associated configuration data for IO parameters monitored by any of the controllers 116, 122, 124, 126, 128, 130. The database 608 may also store data received from any of the other servers 134, 136. Additionally, in some examples, the database 608 stores configuration data defining events, corresponding rules or conditions that trigger those events, and actions to be taken in response to an event trigger being detected. Additional details regarding the nature of some of the information stored in the database are described below with respect to FIG. 7.

[0048]

[0063] FIG. 7 is a block diagram illustrating an example database 608 that stores different types of information including configuration data associated with IO parameters corresponding to different devices or controllers in communication with the main server 132. In some examples, the database 608 is implemented using SQL (Structured Query Language) to store data according to the format of the communication protocol used by the IO communication boards of the controllers 116, 122, 124, 126, 128, 130. As depicted in the illustrated example, the database 608 stores device information 702 corresponding to different devices wirelessly networked with the main server 132. In some examples, the device information 702 associated with each device includes device identification information 704 and IO parameter information 706 for individual IO parameters (e.g., data points) associated with each device. As shown in FIG. 7, the device identification information 704 includes a device name, device type, and address for the device on the wireless network. Including IO parameter information 706 in device information 702 allows for a device-wide log of all data points, increasing the efficiency with which historical data can be archived versus generating individual history logs for each IO parameter. Additionally, in some examples, the efficiency with which data is reported from controllers and / or other devices is improved by devices storing such data locally in a compressed format. In this way, when main server 132 requests data, the device can respond more quickly because the data has already been compressed for transmission.

[0049]

[0064] The IO parameter information 706 includes a name for the IO parameter, an indication of the type of the IO parameter, and a unique address for other IO parameters associated with the corresponding device. Additionally, the IO parameter information 706 stored in the database 608 includes a current value for the parameter along with a timestamp for the current value. Furthermore, the IO parameter information 706 includes configuration data that allows the main server 132 to interpret the value of the IO parameter and determine whether any action needs to be taken based on the reported value of the IO parameter. In some examples, the configuration data includes one or more value update thresholds that define when a change is large enough to update the current value. That is, in some examples, a small variation in the reported parameter value relative to the current value can be ignored if the difference in values ​​is less than the threshold. In some examples, upon receiving a significant change in the IO parameter value, the main server 132 transmits a confirmation that the new value has been saved to the database 608. In some such examples, a linkage scheme is implemented in which the controller that originally reported the data holds the detected IO change until it receives such confirmation of the saved data.

[0050]

[0065] In some examples, the configuration data stored in the database 608 includes a conversion factor used by the main server 132 to convert the reported value of the IO parameter into one that is understandable to a human operator. For example, an analog data point may have a value ranging from 0 to 4096 to represent a temperature between 50°F and 120°F. The value itself may not be meaningful to an operator. Thus, in some examples, the conversion factor (e.g., based on a slope and intercept equation for a linear relationship) allows for the conversion from the reported value to an actual temperature. If the IO parameter corresponds to a non-linear measurement (e.g., the output signal of a thermistor), the conversion factor may include a linearization table selected based on the type of thermistor identified by the parameter type stored in the IO parameter information 706. In some examples, both the converted and unconverted values ​​for the parameter may be stored in the database.

[0051]

[0066] As shown in Figure 7, the configuration data may include textual state and / or value indicators that provide a textual description and / or indication of the meaning of the value of the IO parameter. For example, in the temperature example above, the textual value indicator may include a "degrees F" column to include with the converted value of the parameter so a user looking at the converted value can understand its meaning. In the case of discrete and / or digital values, the textual state indicator may provide a textual indication of what the parameter value represents (e.g., a text column of "Open" or "Closed" for a door).

[0052]

[0067] In some examples, the IO parameter information includes an identification of an event associated with the parameter. That is, the parameter may be the basis for a condition defined for one or more event rules. By identifying all event rules implied by the IO parameter in the database 706 shown in FIG. 7, the main server 132 is able to identify all of the event rules that need to be analyzed whenever a change in value for the IO parameter is detected. This can greatly improve the efficiency of the main server 132 over other systems that must evaluate all event rules every time a new parameter value is collected.

[0053]

[0068] In the example illustrated in FIG. 7, the database 608 stores event definitions 708 that can be configured to define specific events and conditions or rules that trigger such events. In some examples, the event definitions 708 include a name and / or description of the event, as well as event rules that define when the event should be triggered. In some examples, the event rules include one or more conditions (e.g., using AND and / or OR blocks) that are evaluated based on one or more value(s) of the IO parameters stored in the database 608. In this way, a specific IO parameter is associated with said specific event. Additionally, in some examples, the event definitions include information that sets a response and / or action to be taken when the event is triggered. One response can be to generate and transmit a notification to a specific recipient that may be interested in learning about the event. Thus, in some examples, the event definitions 708 include notification content data that defines what information should be included in the notification and / or how the notification should be generated and / or delivered (e.g., via email, SMS message, a popup on a dashboard, etc.). Additionally, the event definition 708 includes a list of notification recipients to whom the notification is intended, along with their contact information (e.g., email address, phone number) for sending the notification. In some examples, notifications can be delivered to a particular device without reference to a particular recipient or user associated with the device.

[0054]

[0069] In some examples, one or more of the cameras 508 associated with the video management system 506 of FIG. 5 (and / or the video management system 614 described below) may be positioned to capture circumstances that may have led to the occurrence of an event. An event that occurs within the recordable range of one or more cameras is referred to herein as a video capture event. In some examples, an event definition may include a video segment definition that identifies the camera(s) 508, a pre-event time interval and a post-event time interval that identify a time window beginning before the event and ending after the event during which the camera(s) 508 should capture video for the video segment. That is, the pre-event time interval defines the duration of the corresponding video segment before an event is triggered, and the post-event time interval defines the duration of the video segment that continues after the event is triggered. For example, a video segment may be defined with a pre-event time interval of 10 seconds and a post-event time interval of 20 seconds, resulting in a video segment duration of 30 seconds and an event occurring 10 seconds after the segment begins. In other examples, the post-event time interval can begin after detection of a second event associated with the first event (e.g., the end of a condition triggers the first event). For example, if the condition that triggers the event lasted 15 seconds, the total duration for the video segment in the previous example would be 45 seconds (10 seconds for the pre-event time interval, 15 seconds when the event is triggered, and 20 seconds for the post-event time interval). In some such examples, the first and second events are treated as the start and end of a single event for archival purposes. In other examples, the video segment definition can include timing parameters defined based on the total video duration (e.g., the duration from the start to the end of the video segment) and a time offset for the event (e.g., the duration after the start of the video segment that the event should occur). For example, to produce the same video as the previous example, the total video duration would be defined as 30 seconds and the time offset would be defined as 10 seconds.Additionally, the video segment definition may include a thumbnail offset time that defines a point in time within the video segment from which a video frame should be extracted as a thumbnail for the video segment.

[0055]

[0070] 7 includes an event log 710 that archives each time an event is triggered. Thus, as shown in the illustrated example, the event log includes trigger event information 712 that corresponds to a series of trigger events. In some examples, the trigger event information 712 includes a name and / or description of the event, a timestamp indicating when the event occurred, the last IO parameter(s) that triggered the event, and one or more video segments for the event captured by one or more of the camera(s) 508 located around the material handling equipment 100.

[0056]

[0071] The example pull service manager 610 of FIG. 6 enables communication with client devices 148 via web pages hosted by web server 146. More specifically, in some examples, the pull service manager 610 enables data in a web page to be initially loaded from database 608 upon a pull request from a client device 148 accessing the web page. Additionally, the pull service manager 610 enables the content of the web page to be updated substantially in real time through dynamic retrieval of data from database 608. In some examples, the pull service manager 610 enables new data to be requested via a pull request in response to an end user (e.g., at client device 148) entering data into available user entry fields in the web page. In some examples, new data may be retrieved as the user is entering (e.g., typing) the data, prior to the user actually submitting the data.

[0057]

[0072] The example push service manager 612 of FIG. 6 uses a push request communication protocol to push data between different live web pages (e.g., accessed by different client devices 148) and provide updates to all such web pages in substantially real-time. That is, the push service manager 612 enables the web server 146 to transmit update data to different ones of these web pages without having to wait for the client device 148 to request the data update (e.g., via a pull request). Additionally, the push service manager 612 enables user input data provided by an end user via one web page to be provided to other web pages for substantially real-time updates between disparate and / or unrelated web pages without the need for separate web pages to request such data from the web server 146 and / or modify the web server 146. The example pull service manager 610 and the example push service manager 612 are collectively referred to herein as an example notification generator. As used herein, an exemplary notification generator generates information that is provided for rendering via a display (e.g., via one or more web pages and / or graphical user interfaces associated with other computer-implemented applications) or that is otherwise provided for access by a user (e.g., for transmission in an email message, storage in a historical log of events, etc.).

[0058]

[0073] In some examples, push updates are accomplished by configuring a separate web page with a push request to subscribe to dynamic (e.g., substantially real-time) updates of a particular type of information identified based on a particular column included in the scripting for the web page. In some examples, the information associated with a particular column corresponds to a particular type of device (e.g., a particular controller 116, 122, 124, 126, 128, 130). For example, the web page may include a column called "DockSubscribe" to subscribe to updates when IO data reported from the dock controller 116 changes. Thus, when one IO parameter value reported by the dock controller 116 changes, the push service manager 612 pushes the new value to the subscribing web page. In some examples, multiple IO parameters may be grouped to be reported together based on a correlation associated with the content to be displayed on the web page. Thus, in some examples, when any one of the IO parameters in the group changes, the push service manager 612 may send all associated IO parameters to the subscribing web page. In another example, only the new IO parameters can be reported to a web page, which can then initiate a pull request to retrieve other such parameters.

[0059]

[0074] In some examples, scripting within a web page can subscribe to push requests as soon as a user accesses a particular web page via a client device 148. In other examples, the web page cannot begin subscribing until the user begins inputting data via the web page. The push service manager 612 monitors all web pages open on all client devices 148 to keep track of all subscriptions made by any currently open web page. When the main server 132 collects new IO data from one or more controllers associated with a particular subscription, it can automatically push the new data to the web page that corresponds to the subscription.

[0060]

[0075] Following this same approach, user input data received on one web page can be taken and distributed to other web pages hosted by the web server 146. In particular, when a user inputs data (via the client device 148), this data is provided to the main server 132 (via the web server 146). Based on the type of information being provided, the push service manager 612 pushes the information to all other active web pages that have subscribed to the same type of information based on including the same unique string in the scripting of the web page. Thus, the unique string serves as a destination address for the other web pages to send the user input data. This allows the user input data to be sent between different websites without modifying the server to incorporate new routing paths between new web pages that were not previously hosted by the web server 146.

[0061]

[0076] In some examples, the updated separate web pages can be different instances of the same web page (e.g., accessed by two different client devices 148) and / or completely different web pages hosted by web server 146. For example, different web pages that may subscribe to updates of common information can include a web page for truck drivers to sign in and sign out, a web page for display in a lounge or waiting room for drivers, a web page that provides driver-specific status updates (e.g., to the driver's personal smartphone), a web page for display at a dock assignment center at a logistics office, a web page for a yard map dashboard at a logistics office, and / or a web page for an event log notification center.

[0062]

[0077] In some examples, the main server 132 can distinguish between updated information collected from the controllers 116, 122, 124, 126, 128, 130 and user-entered data from another web page manually entered via the client device 148. In some examples, an indication of the type of update for data associated with a particular parameter (e.g., sensor-reported data or manually updated data) is stored in the database 608 along with the collected data. In some examples, the indication of the type of update is communicated to the web page when the web page requests or otherwise receives the corresponding data. Thus, in some examples, the web page can provide an indication when the updated information is based on sensor data (e.g., from a controller) or human-entered data.

[0063]

[0078] In the example illustrated in FIG. 6, the video management system 614 can function substantially similarly to the video management system 506 of FIG. 5. In some examples, when the video management system 506 of FIG. 5 is implemented, the video management system 614 of FIG. 6 can be omitted. Similarly, in other examples, when the video management system 614 of FIG. 6 is implemented by the main server 132, the video management system 506 of FIG. 5 can be omitted. In some examples, the system may not include a video management system. That is, in some examples, both the video management system 506 of FIG. 5 and the video management system 614 of FIG. 6 can be omitted. Additional details regarding the implementation of the video management system 614 of FIG. 6 (and / or the video management system 506 of FIG. 5) are provided in FIG. 8.

[0064]

[0079] 8, the video management system 614 of FIG. 6 (and / or the video management system 506 of FIG. 5) includes an example communication interface 802, an example video segment generator 804, an example video analyzer 806, and an example video database 808. As shown in the illustrated example, the communication interface 802 receives video data from the camera 508. In some examples, the communication interface 802 also enables communication with the main server 132.

[0065]

[0080] In some examples, the video segment generator 804 may generate segments of video associated with particular events detected with respect to the operation of the material handling facility 100. In some examples, the detected events correspond to events detected by the main server 132 based on an analysis of IO data collected by the main server 132, as described in more detail below. In some examples, the video segments generated by the video segment generator 804 include video extending over a period of time (e.g., 10 seconds, 30 seconds, 1 minute, 5 minutes, etc.) before the detected event and a period of time after the detected event. The duration of the video segments both before and after the detected event may be set separately based on the nature of the particular event detected. In some examples, the video segment generator 804 provides the generated video segments to the main server 132 for storage for future reference by and / or transmission (e.g., as an email attachment) to one or more client devices (e.g., associated with warehouse managers and / or other interested individuals).

[0066]

[0081] In some examples, the video analyzer 806 analyzes images and / or video streams provided by one or more of the cameras 508 to identify safety events (e.g., near misses, irregular forklift behavior, etc.) and / or other configurable conditions (e.g., identifying individuals based on facial recognition, detecting lost or misplaced pallets, etc.) associated with the operation of the material handling equipment 100. In some examples, the video analyzer 806 is limited to analyzing video segments generated by the video segment generator 804. That is, in some examples, the video analyzer 806 is invoked in response to a detected event. In other examples, the video analyzer 806 may continuously analyze the video streams of one or more of the cameras 508 for safety events. The safety events may include collisions, near misses, and / or other incidents occurring at the material handling equipment 100. In some examples, the video analyzer 806 analyzes images and / or video captured by the cameras 508 to detect and / or monitor the location and / or movement of persons in and / or around the material handling equipment 100. Identification of the person may be useful in determining who was responsible for triggering the initial event that resulted in the generation of the video segment. In some examples, the video analyzer 806 uses facial recognition technology to identify the detected person (e.g., to determine whether the person works in the material handling equipment or is an unrecognized guest or intruder).

[0067]

[0082] As shown in the described examples, the video management system 614 includes a video database 808 to store video data received from the camera 508. In some examples, the camera 508 captures video continuously and the captured data is archived in the database 808 for an extended period of time (e.g., 24 hours, 1 week, 1 month, etc.). Additionally or alternatively, the video database 808 can store video segments generated by the video segment generator 804 for later retrieval and / or analysis. In some examples, the video segments are stored for a threshold period of time (e.g., 24 hours, 1 week, 1 month, etc.) unless a user requests the video segment to be stored for a longer duration (e.g., indefinitely). In some examples, the video database 808 also stores annotations and / or comments received from a user after reviewing a video segment. Additionally, the video database 808 can store video segment definitions that outline the timing and duration of the video segment relative to a detected event. In some examples, the database 808 of FIG. 8 can be incorporated into the example database 608 of FIG. 6.

[0068]

[0083] Returning to the example illustrated in FIG. 6, the exemplary event manager 616 of the main server 132 analyzes the IO data received from the controllers 116, 122, 124, 126, 128, 130 to detect the occurrence of a particular event. For example, the event manager 616 can determine that a particular alarm condition is met to trigger an alarm. In some examples, the conditions and / or rules used to detect the event are stored in the database 608 described above. In the illustrated example, the event manager 616 causes the network communication interface 602 to update all the relevant web pages associated with the detected event. More specifically, in some examples, the event manager 616 instructs the push service manager 612 to route the detected event from the data received at the IO network interface 604 to a web page that has a subscription for dynamic updates using a push request. Additionally or alternatively, in some examples, the event manager 616 instructs the push service manager 612 to route changes received from one client device 148 (e.g., based on user input in a corresponding web page) to all other client devices 148 or to one or more types of accounts specified in the scripting of the corresponding web page. Additionally or alternatively, the event manager 616 can generate and send email and / or SMS messages to one or more of the client devices 148 via the network communication interface 602 in response to detecting a particular event.

[0069]

[0084] Further, in response to detecting a particular event, the event manager 616 can cause the video segment generator 804 to generate a video segment associated with the detected event. In some examples, the video segment generated by the video segment generator 804 can be included as an attachment to such a message. In some examples, the event manager 616 can automatically send an initial email in response to the event being detected, and then send a second email with the video segment attached shortly thereafter (e.g., after the video segment has been generated to include a configured post-event time interval associated with the segment). In some examples, the event manager 616 can wait until the video segment has been generated to include such a post-event time interval in the initial email notification.

[0070]

[0085] Additional details regarding implementations of the event manager are provided below with respect to Figure 9. Specifically, as shown in the example illustrated in Figure 9, the event manager 616 includes an example device identifier 902, an example configuration engine 904, an example data analyzer 906, an example time stamper 908, an example parameter value converter 910, an example event analyzer 912, an example event logger 914, an example notification engine 916, and an example web page analyzer 918.

[0071]

[0086] In the example illustrated in FIG. 9, the exemplary device identifier 902 identifies the device transmitting the message including the IO data. In some examples, the IO data reported to the main server 132 by any one of the controllers 116, 122, 124, 126, 128, 130 and / or any other device is transmitted in an IO message including the name or identifier and associated address of the transmitting device. The device identifier 902 can identify the device from which it received the IO message by searching for the corresponding identifier and / or address for the device stored in the database 608 when the device was configured and commissioned in the system. That is, when a device (e.g., the controllers 116, 122, 124, 126, 128, 130) is configured and commissioned in the system, the main server 132 stores the name and address of the device in the database 608. Thus, when a new IO message is received, the exemplary device identifier 902 can identify the source of the IO data included in the message by searching for the device in the database 608. However, in some examples, the main server 132 may receive an IO message from a device that is not represented in the database, for example when the device is new to the network. In such examples, the device identifier 902 may store the name and address of the unrecognized device in the database 608, but may ignore the IO data specific to the reported IO parameter values ​​and / or any other information included in the IO message until the device is configured.

[0072]

[0087] In the described example, the configuration and / or commissioning of a new device (and / or reconfiguration of an existing device) is accomplished via the example configuration engine 904 of FIG. 9. In some examples, in response to receiving an IO message from a device (e.g., a controller) that the device identifier 902 does not recognize (e.g., a new device), the configuration engine 904 can prompt the operator to authorize an automatic upload for configuration of all data associated with the device. Additionally or alternatively, the name and address of the device can be stored in a database without requiring authorization to upload the data for configuration. Instead, the configuration engine 904 can wait for the operator to initiate configuration of the device. In such an example, the configuration engine 904 can provide a list of devices discovered on a wireless network in communication with the main server 132. Since the names and addresses of unconfigured devices are stored in the database, the unconfigured devices can be included in the list for the operator to select for configuration. In this manner, the user is assisted with the commissioning and configuration of new devices to be monitored by the main server 132.

[0073]

[0088] The example data analyzer 906 of FIG. 9 serves to monitor and / or analyze IO data contained in IO messages received from the controllers 116, 122, 124, 126, 128, 130 and / or any other data reported to the main server 132 from any other devices (e.g., management server(s) 134, remote server(s) 135, client device 148, etc.). In some examples, any one of the controllers 116, 122, 124, 126, 128, 130 may report data associated with multiple different IO parameters. Thus, in some examples, the data analyzer 906 monitors and / or analyzes the IO data to determine which IO parameter the IO message is associated with. In some examples, the particular IO parameter reported is based on searching for a parameter address contained in the IO message in the database 608. After the particular IO parameter is identified, the data analyzer 906 may compare the value of the IO parameter reported in the IO message to a recent value stored in the database 608. If the value does not change, the IO message is not carrying any new information and no further analysis is required. However, if the value of the IO parameter has changed, the data analyzer 906 can update the database 608 with the new value. In some examples, the data analyzer 906 can update the value for the IO parameter to omit non-consequential fluctuations within the deadband range when the change in value exceeds a threshold assigned to the parameter. When the value reported for the IO parameter has changed sufficiently, the example time stamper 908 can timestamp the new value stored in the database 608 to record when the change occurred.

[0074]

[0089] When a value reported for an IO parameter changes, an example parameter value converter 910 is implemented to convert or translate the value into a human understandable form. In some examples, this involves applying one or more conversion factors associated with the IO parameter stored in database 608. The parameter value converter 910 can also convert this value into a textual form that corresponds to a particular state for a digital IO value (e.g., "OPEN" or "CLOSED" for a door) or a descriptive statement for an analog IO value (e.g., "27 degrees F") associated with the context of the IO parameter. Additionally or alternatively, the parameter value converter 910 can convert the IO parameter value into a non-textual visual context-specific indicator, such as, for example, an image, an icon, a color, etc.

[0075]

[0090] In the example illustrated in FIG. 9, the exemplary event analyzer 912 determines whether the IO parameters reported in the IO message identified by the data analyzer 906 are associated with or implied in any event rules. That is, the event analyzer 912 determines whether the IO parameters are the basis for a condition that defines the triggering of an event. If the IO parameters are associated with one or more event rules, the event analyzer 912 evaluates each of the associated event rules based on the new reported value for the parameters to determine whether any event has been triggered. If no event has been triggered, no further action is taken. If an event has been triggered, the exemplary event logger 914 logs the event to the database 608 along with an associated timestamp provided by the exemplary timestamper 908.

[0076]

[0091] After an event is triggered or detected, the event manager 616 of the main server 132 can initiate one or more actions in response to the event. In some examples, one response includes generating and distributing notifications to the appropriate individuals. Accordingly, the example event manager 616 includes a notification engine 916 to generate such notifications. In some examples, the notification engine 916 generates the content of the notification based on notification content data stored in association with the triggering event. Additionally, in some examples, the configured data associated with the triggering event identifies the intended recipients for the notification along with contact information (e.g., email address, phone number, etc.) to be used to deliver the notification. In some examples, the notification engine generates a notification for display via a particular computing device and / or display screen regardless of the identity of the particular recipient. For example, the notification may include an update to a display screen in a logistics office of the material handling facility 100. In some examples, the notification engine 916 can generate notifications that are provided to one or more of the controllers 116, 122, 124, 126, 128, 130 of FIG. 1 for display on a local screen (e.g., display screen 117 of FIG. 3). In some examples, the notification engine 916 can generate notifications to be provided as updates to one or more web pages managed by the web server 146. In some examples, such notifications are processed by the example web page analyzer 918. Thus, the example notification engine 916 and web page analyzer 918 are additional examples of notification generators (along with the push service manager 610 and push service manager 612 discussed above).

[0077]

[0092] Whether or not a particular event is triggered, the example web page analyzer 918 of Figure 9 can determine whether the IO parameters are associated with content displayed via one or more web pages hosted by the web server 146 and can send out any new reported values ​​for the parameters to update the web pages. As mentioned above, in some examples, updates to the web pages can be pushed to the web pages via the push service manager 612 for substantially real-time updates without polling for such updates. Alternatively, the pull service manager 610 can poll for updates using pull requests.

[0078]

[0093] Although an example manner of implementing the main server 132 of FIG. 1 (and the associated video management system 614 of FIG. 8 and event manager 616 of FIG. 9) is illustrated in FIG. 6, one or more of the elements, processes, and / or devices illustrated in FIGS. 6 and 9 may be combined, divided, rearranged, omitted, removed, and / or implemented in any other manner. Additionally, the example network communication interface 602, the example IO network interface 604, the example restart watchdog 606, the example database 608, the example pull service manager 610, the example push service manager 612, the example video management system 614 (including any of the example communication interface 802, the example video segment generator 804, the example video analyzer 806, and / or the example video database 808), the example event manager 616 (including any of the example device identifier 902, the example configuration engine 904, the example data analyzer 906, the example time stamper 908, the example parameter value converter 910, the example event analyzer 912, the example event logger 914, the example notification engine 916, and / or the example web page analyzer 918), and / or, more generally, the example main server 132 of FIG. 1 may be implemented by hardware, software, firmware, and / or any combination of hardware, software, and / or firmware.Thus, for example, an example network communication interface 602, an example IO network interface 604, an example restart watchdog 606, an example database 608, an example pull service manager 610, an example push service manager 612, an example video management system 614 (including any of an example communication interface 802, an example video segment generator 804, an example video analyzer 806, and / or an example video database 808), an example event manager 616 (including an example device identifier 902, an example configuration engine 904, an example data analyzer 906, an example time stamper 908, an example parameter value converter 910, an example event analyzer 912,

[0046] The exemplary event logger 914, the exemplary notification engine 916, and / or the exemplary web page analyzer 918, and / or, more generally, any of the exemplary main server 132 may also be implemented by one or more analog or digital circuit(s), logic circuit(s), programmable processor(s), programmable controller(s), graphics processing unit(s) (GPU(s)), digital signal processor(s) (DSP(s)), application specific integrated circuit(s) (ASIC(s)), programmable logic device(s) (PLD(s)), and / or field programmable logic device(s) (FPLD(s)).When reading any of the apparatus or system claims of this patent directed to a purely software and / or firmware implementation, it is understood that the exemplary network communication interface 602, the exemplary IO network interface 604, the exemplary restart watchdog 606, the exemplary database 608, the exemplary pull service manager 610, the exemplary push service manager 612, the exemplary video management system 614 (including any of the exemplary communication interface 802, the exemplary video segment generator 804, the exemplary video analyzer 806, and / or the exemplary video database 808), and / or the exemplary event manager 616 (including any of the exemplary device At least one of the device identifier 902, the example configuration engine 904, the example data analyzer 906, the example time stamper 908, the example parameter value converter 910, the example event analyzer 912, the example event logger 914, the example notification engine 916, and / or the example web page analyzer 918 is hereby expressly defined to include a non-transitory computer-readable storage device or storage disk, such as a memory, a digital versatile disk (DVD), a compact disk (CD), a Blu-ray disk, a USB memory stick, a solid-state memory disk device, etc., that includes software and / or firmware. Furthermore, the example main server 132 of FIG. 1 may include one or more elements, processes, and / or devices in addition to or instead of those shown in FIGs. 6, 8, and 9, and / or may include two or more of any or all of the shown elements, processes, and devices. As used herein, the phrase "communicate," including variations thereof, encompasses direct communication and / or indirect communication via one or more intermediate components and does not require direct physical (e.g., wired) communication and / or continuous communication, but rather additionally includes selective communication at periodic intervals, scheduled intervals, aperiodic intervals, and / or one-time events.

[0079]

[0094] In some examples, one or more of the blocks in FIG. 6 (and / or associated blocks in FIGS. 8 and 9) may be implemented in one or more separate servers. For example, in some examples, the database 608 may be implemented in a server separate from that of the main server 132. Additionally or alternatively, in some examples, the IO network interface 604 may be implemented in a separate IO server different from the main server 132 that includes the event manager 616. Further, as shown in the illustrated example in FIG. 10, a distributed system 1000 may be created, where multiple IO servers 1002 (each including an IO network interface 604) and / or multiple main servers 132 (each including an event manager 616) are implemented in the distributed system 1000 and communicatively coupled via one or more routers 1004. In the illustrated example, a single database 608 serves each of the main servers 132. In other examples, different main servers 132 may include different databases 608 and / or different main servers 132 may be associated with different databases 608.

[0080]

[0095] As depicted in FIG. 10, each of the IO servers 1002 is communicatively coupled to a different set of wireless IO devices (e.g., equivalent to any of the controllers 116, 122, 124, 126, 128, 130). As shown in the illustrated example, the separate IO servers 1002 communicate with the main server 132 via an exemplary router 1004. This arrangement allows data from geographically distributed devices (e.g., beyond the signal range of the available wireless communication) to be collected and consolidated into a single system. In some examples, the main server 132 may also be geographically distributed and / or hosted by a cloud service provider. In the illustrated example, the IO server 1002 may host only a single TCP (Transmission Control Protocol) connection to the array of main servers 132. In contrast, the main server 132 and the router 1004 may allow multiple TCP connections. Thus, because communication between the router 1004 and the server 132 is based on TCP connections, when the IO server 1002 is located within the wireless range of the wireless IO device 1006, the router 1004 and / or the server 132 can be located beyond the wireless communication range. Thus, the router 1004 acts as a concentrator of TCP connections for the distributed system shown in FIG. 10. In some examples, the number of main servers 132 can be scaled up or down depending on processing capacity and bandwidth considerations (e.g., based on web access requests). In some examples, a single main server 132 can be implemented to receive and aggregate all data from each of the separate IO servers 1002. The distributed system shown in FIG. 10 can be suitable for applications that span multiple buildings in a large campus and / or for enterprises that include multiple facilities in different geographically separated locations (e.g., different cities, different states, different countries, etc.).

[0081]

[0096] 1 , except that in some examples, analysis and processing of IO data at each controller may be limited to less than all IO data aggregated by main server 132 from all sources across material handling facility 100. That is, in some examples, controllers 116, 122, 124, 126, 128, 130 may analyze each IO data to identify events that trigger implementation of a particular action, such as, for example, generating a notification for rendering via a local display screen (e.g., display screen 117 of FIG. 3 ) and / or storage in a database and / or transmission to main server 132 for further analysis, processing, and / or distribution. While the controllers 116, 122, 124, 126, 128, 130 may be limited to processing IO data collected directly by each corresponding controller, in some examples, the main server 132 may provide additional information obtained from other sources (e.g., different controllers within the material handling facility 100, the client device(s) 148, the management server(s), and / or remote server(s)).

[0082]

[0097] More specifically, Figure 11 illustrates an example implementation of a local controller 1100, which may correspond to any one of the controllers 116, 122, 124, 126, 128, 130 of Figure 1, which are local to the equipment being operated and / or controlled by such controller. Thus, as shown in the illustrated example, the local controller 1100 includes an example communication board 133, by which the controller 1100 is capable of transmitting IO data to the main server 132. Additionally, in some examples, the controller 1100 may also receive feedback and / or other such information from the main server 132, as previously discussed. Additionally, as shown in the example illustrated in FIG. 11, the local controller includes an example communication interface 1102, an example data analyzer 1104, an example event analyzer 1106, an example parameter value converter 1108, an example notification engine 1110, an example database 1112, an example display 1114, and an example device controller 1116.

[0083]

[0098] The exemplary communication interface 1102 allows the controller 1100 to communicate with associated equipment monitored and / or controlled by the controller 1100. For example, the communication interface 1102 for the dock controller 116 of FIG. 1 allows the dock controller 116 to send commands or instructions to, and receive feedback from, actuators, sensors, and / or other equipment associated with the dock, including the door 104, the entry barrier 106, the dock leveller 108, the vehicle restraint device 110, the presence detector 112, and the notification system 114. In some examples, the communication board 133 and the communication interface 1102 may be integrated and function as a single component.

[0084]

[0099] 11 serve the same or similar purposes as the corresponding example data analyzer 906, example event analyzer 912, example parameter value converter 910, example notification engine 916, and example database 608 of FIGS. 6 and 9 associated with the main server 132. However, the example data analyzer 1104, example event analyzer 1106, example parameter value converter 1108, example notification engine 1110, and example database 1112 of the example local controller 1100 of FIG. 11 may be limited in terms of the amount and type of data stored, analyzed, and / or processed as compared to the main server 132.

[0085]

[0100] More specifically, the example data analyzer 1104 of FIG. 11 monitors and / or analyzes IO data received from an associated device or sensor via the communication interface 1102 to determine that such data has changed to reflect a change in the state or condition of the device or sensor. In some examples, when the example data analyzer 1104 identifies a change in the IO data, the data analyzer 1104 may store the change in the database 1112. In some examples, the data analyzer 1104 monitors and / or analyzes the IO data without storing the IO data in the database 1112. Instead, in some such examples, the data analyzer 1104 operates in conjunction with the event analyzer 1106 to determine any suitable action or behavior based on the current value of the IO data as determined by the data analyzer 1104. In some examples, the data analyzer 1104 may also store, monitor, and / or analyze data provided by the main server 132. For example, with respect to the dock controller 116, maintenance personnel may provide details regarding maintenance of equipment at the dock 102 and / or instructions to take the dock out of service for maintenance via one of the client device(s) 148. Additionally or alternatively, information collected by the main server 132 from a truck driver's portable device (corresponding to another of the client device(s) 148) regarding details associated with a trailer parked at the associated dock 102 may also be provided to the local dock controller 116 for storage and / or further analysis and / or processing by the data analyzer 1104 and / or event analyzer 1106 of FIG.

[0086]

[0101] As mentioned above, the example data analyzer 1104 can operate in conjunction with the example example event analyzer 1106 illustrated in FIG. 11. In some examples, the data analyzer 1104 and the event analyzer 1106 can be integrated into a single component. The example event analyzer 1106 determines whether the particular IO data associated with the particular IO parameter corresponds to a condition that defines a trigger of one or more events, which can cause the event analyzer 1106 to store information defining the event and / or initiate an action. In some examples, the action can involve activating a particular device (e.g., opening or closing a door, generating an alarm, changing the output of a visual and / or audible indicator, etc.). Furthermore, in some examples, the event analyzer 1106 can determine that the appropriate action in response to the event being triggered is to generate a particular notification that can be stored locally, transmitted to the main server 132, and / or displayed via a local display screen, such as the example display 1114.

[0087]

[0102] In some examples, notifications provided to the example display 1114 and / or transmitted to the main server 132 are generated by the notification engine 1110. Thus, the example notification engine 1110 and web page analyzer 918 are additional examples of notification generators (along with the push service manager 610 and push service manager 612 of FIG. 6 and the notification engine 916 and web page analyzer 918 of FIG. 9 discussed above). In some examples, such notifications can include and / or be based on the output of the example parameter value converter 1108. The parameter value converter 1108 of FIG. 11 is implemented to convert or translate values ​​of certain parameters represented in the IO data collected by the communication interface 1102 into a human understandable form. In some examples, the parameter value converter 1108 of FIG. 11 operates in a manner similar to the example parameter value converter 910 of FIG. 9 discussed above. The example appliance controller 1116 of FIG. 11 controls the operation of appliances monitored and / or controlled by the local controller 1100, for example, by transmitting instructions, commands, and / or signals to the appliances via the communications interface 1102.

[0088]

[0103] An example manner of implementing any one of the example controllers 116, 122, 124, 126, 128, 130 of Figure 1 is illustrated by the example local controller 1100 of Figure 11, although one or more of the elements, processes, and / or devices illustrated in Figure 11 may be combined, divided, rearranged, omitted, removed, and / or implemented in any other manner. Additionally, the example communication board 133, example communication interface 1102, example data analyzer 1104, example event analyzer 1106, example parameter value converter 1108, example notification engine 1110, example database 1112, example display 1114, example appliance controller 1116, and / or, more generally, the example local controller 1100 of Figure 11 may be implemented by hardware, software, firmware, and / or any combination of hardware, software, and / or firmware. Thus, for example, any of the example communications board 133, the example communications interface 1102, the example data analyzer 1104, the example event analyzer 1106, the example parameter value converter 1108, the example notification engine 1110, the example database 1112, the example display 1114, the example equipment controller 1116, and / or, more generally, the example local controller 1100 may be implemented by one or more analog or digital circuit(s), logic circuit(s), programmable processor(s), programmable controller(s), graphics processing unit(s) (GPU(s)), digital signal processor(s) (DSP(s)), application specific integrated circuit(s) (ASIC(s)), programmable logic device(s) (PLD(s)), and / or field programmable logic device(s) (FPLD(s)).When reading any of the apparatus or system claims of this patent directed to a purely software and / or firmware implementation, at least one of the example communication board 133, the example communication interface 1102, the example data analyzer 1104, the example event analyzer 1106, the example parameter value converter 1108, the example notification engine 1110, the example database 1112, the example display 1114, and / or the example appliance controller 1116 are hereby expressly defined to include a non-transitory computer-readable storage device or storage disk, such as a memory, a digital versatile disk (DVD), a compact disk (CD), a Blu-ray disk, etc., that contains software and / or firmware. Furthermore, the example local controller 1100 of FIG. 11 may include one or more elements, processes, and / or devices in addition to or instead of those shown in FIG. 11 and / or may include two or more of any or all of the elements, processes, and devices shown. As used herein, the phrase "communicate," including variations thereof, encompasses direct communication and / or indirect communication via one or more intermediate components and does not require direct physical (e.g., wired) communication and / or continuous communication, but rather additionally includes selective communication at periodic intervals, scheduled intervals, aperiodic intervals, and / or one-time events.

[0089]

[0104] Flow diagrams representing example hardware logic or machine readable instructions, hardware implemented state machines, and / or any combination thereof for implementing the main server 132 of FIG. 1, FIG. 6, and / or FIG. 10 are shown in FIG. 12-15. The machine readable instructions may be one or more executable programs or a portion(s) of an executable program for execution by a processor, such as the processor 6012 shown in the example processor platform 6000 discussed below with respect to FIG. 60. The programs may be implemented in software stored on a non-transitory computer readable storage medium, such as a CD-ROM, a floppy disk, a hard drive, a DVD, a Blu-ray disk, or a memory associated with the processor 6012, although alternatively the entire program and / or portions of the program may be executed by a device other than the processor 6012 and / or implemented in firmware or dedicated hardware. Additionally, although the example programs are described with reference to the flow diagrams shown in FIG. 12-15, alternatively numerous other ways of implementing the example main server 132 may be used. For example, the order of execution of these blocks may be changed, and / or some of the described blocks may be changed, removed, or combined. Additionally or alternatively, any or all of the blocks may be implemented by one or more hardware circuits (e.g., discrete and / or integrated analog and / or digital circuits, FPGAs, ASICs, comparators, operational amplifiers (opamps), logic circuits, etc.) configured to perform the corresponding operations without executing software or firmware.

[0090]

[0105] The machine-readable instructions described herein may be stored in one or more of a compressed format, an encrypted format, a fragmented format, a packaged format, and the like. The machine-readable instructions described herein may be stored as data (e.g., a portion of instructions, a code, a code representation, and the like) that can be utilized to create, manufacture, and / or form machine-executable instructions. For example, the machine-readable instructions may be fragmented and stored in one or more storage devices and / or computing devices (e.g., servers). The machine-readable instructions may require one or more of placing, modifying, adapting, updating, combining, supplementing, configuring, decrypting, restoring, unpacking, distributing, reallocating, and the like to become directly readable and / or executable by the computing device and / or other machines. For example, the machine-readable instructions may be stored in multiple portions that are individually compressed, encrypted, and stored in separate computing devices, which portions, when decrypted, restoring, and combined, form a set of executable instructions that implement a program as described herein. In another example, machine-readable instructions may be stored in a state readable by a computer, but require the addition of a library (e.g., a dynamic link library (DLL)), a software development kit (SDK), an application programming interface (API), or the like, to execute the instructions on a particular computing device or other device. In another example, the machine-readable instructions may require configuration (e.g., storing settings, entering data, recording network addresses, etc.) before the machine-readable instructions and / or corresponding program(s) can be executed in whole or in part. Thus, the disclosed machine-readable instructions and / or corresponding program(s) are intended to encompass such machine-readable instructions and / or program(s) regardless of the particular format or state of the machine-readable instructions and / or program(s) when stored or otherwise at rest or in transition.

[0091]

[0106] As previously mentioned, the example processes of Figures 12-15 may be implemented using executable instructions (e.g., computer and / or machine readable instructions) stored on a non-transitory computer and / or machine readable medium, such as a hard disk drive, flash memory, read-only memory, compact disk, digital versatile disk, cache, random access memory, and / or any other storage device or storage disk, on which information is stored for any duration (e.g., for an extended period of time, permanently, for brief instances, temporarily for buffering, and / or for caching of information). As used herein, the term non-transitory computer readable medium is expressly defined to include any type of computer readable storage device and / or storage disk, and to exclude propagating signals and transmission media.

[0092]

[0107] As used herein, "including" and "comprises" (and all forms and tenses thereof) are used as open-ended terms. Thus, whenever a claim uses any form of "including" or "comprises" (e.g., comprises, includes, comprises, includes, has, etc.) as a preamble or in any type of claim recitation, it is to be understood that additional elements, terms, etc. can be present without departing from the scope of the corresponding claim or recitation. As used herein, when the phrase "at least" is used as a transitional phrase, for example in the preamble of a claim, it is open-ended in the same manner that the terms "comprises" and "comprising" are open-ended. The term "and / or," when used in the form of, for example, A, B, and / or C, refers to any combination or subset of A, B, C, such as (1) A alone, (2) B alone, (3) C alone, (4) A and B, (5) A and C, and (6) B and C, and (7) A and B and C. As used herein, in the context of describing structures, components, articles, objects, and / or things, the phrase "at least one of A and B" is intended to refer to implementations that include any of (1) at least one A, (2) at least one B, and (3) at least one A and at least one B. Similarly, as used herein, in the context of describing components, articles, objects, and / or things, the phrase "at least one of A or B" is intended to refer to implementations that include any of (1) at least one A, (2) at least one B, and (3) at least one A and at least one B. As used herein, in the context of describing the performance or execution of a process, instruction, action, activity, and / or step, the phrase "at least one of A and B" is intended to refer to implementations that include any of (1) at least one A, (2) at least one B, and (3) at least one A and at least one B.Similarly, as used herein, in the context of describing the implementation or performance of a process, instruction, action, activity, and / or step, the phrase “at least one of A or B” is intended to refer to implementations that include any of: (1) at least one A; (2) at least one B; and (3) at least one A and at least one B.

[0093]

[0108] The program of FIG. 12 begins at block 1202, where an example IO network interface 604 receives an IO message from a wireless device. The wireless device may correspond to any of the controllers 116, 122, 124, 126, 128, 130 and / or any other device in communication with the main server 132 of FIG. 1. The IO message includes IO data corresponding to a particular IO parameter monitored by the reporting device. At block 1204, an example event manager 616 processes the IO message. Further details regarding the implementation of block 1204 are provided below with respect to FIG.

[0094]

[0109] At block 1206, the example data analyzer 906 determines whether the value of the IO parameter in the message has changed by at least a threshold amount. In some examples, this determination is made by comparing the IO parameter value with recent values ​​for the parameter stored in the example database 608. The threshold for change may be defined in configuration data stored in the database 608 for this parameter. In some examples, the threshold may be zero. That is, in some examples, any amount of change in the IO parameter value may be sufficient. If the example data analyzer 906 determines that the value of the IO parameter has changed by at least the threshold amount (block 1206), the example data analyzer 906 updates the database 608 (block 1208). If the example data analyzer 906 determines that the value of the IO parameter has not changed by at least the threshold amount, there is nothing to update. Thus, control proceeds to block 1220. In some examples, an event may be triggered based on a particular IO parameter not changing for more than a threshold period of time. In such an example, instead of proceeding to block 1220, control may proceed to block 1210 for further analysis of the IO parameters.

[0095]

[0110] At block 1210, the example event analyzer 912 determines whether the IO parameter is associated with an event rule. That is, the example event analyzer 912 determines whether the value of the IO parameter corresponds to a condition or rule that serves to detect or trigger an event. If the IO parameter is associated with an event rule, the example event manager 616 evaluates the IO parameter with respect to a trigger event (block 1212). Further details regarding the implementation of block 1212 are provided below with respect to FIG. 14. Control then proceeds to block 1214. Returning to block 1210, if the example data analyzer 906 determines that the IO parameter is not associated with an event rule, control proceeds directly to block 1214.

[0096]

[0111] At block 1214, the exemplary web page analyzer 918 determines whether the IO parameter is associated with one or more web pages. That is, the exemplary web page analyzer 918 determines whether the one or more web pages include content generated based on the value of the IO parameter. In some examples, this is determined based on whether the web page subscribes to dynamic updates for the type of data corresponding to the IO parameter. If the IO parameter is associated with one or more web pages, the exemplary web page analyzer 918 evaluates the web application configured for the IO parameter (block 1216). That is, the web page analyzer 918 determines whether and how the content generated by the web application changes based on the change to the IO parameter value. Then, at block 1218, the exemplary push service manager 612 pushes the update to all subscribed web pages. Exemplary graphical user interfaces for web pages that can be updated are described below with respect to FIGS. 21-59. In some examples, the update includes adding any newly created video segments to a video event archive web page 4400 shown with respect to FIG. 44 and described below. Control then proceeds to block 1220. Returning to block 1214, if the IO parameters are not associated with any web page, control proceeds directly to block 1220. At block 1220, the program determines whether to continue. If so, control returns to block 1202 to receive and process another IO message. Otherwise, the example program of FIG. 12 ends. Although blocks 1214-1218 have been described with respect to web pages and associated web applications, in some examples, the main server 132 may implement web pages, web applications, and / or applications that provide a graphical user interface (such as those shown with respect to FIGS. 21-59) via a display screen independent of the Internet.

[0097]

[0112] FIG. 13 is a flow diagram illustrating an example implementation of block 1204 of FIG. 12. The example program of FIG. 13 begins at block 1302, where the example device identifier 902 determines whether the device from which it received the IO message (block 1202 of FIG. 12) is represented in the database 608. If not, control returns to block 1304, where the example device identifier 902 stores the name and address of the device in the database 608. In this way, the operator does not have to discover the device on the network later when he or she wants to configure the device. At block 1306, the example configuration engine 904 determines whether to upload all device configuration data from the device. As discussed above with respect to FIG. 7, the configuration data from the device includes both the device identification information 704 as well as the IO parameter information 706 for all IO parameters (data points) associated with the device. In some examples, the configuration engine 904 determines whether to upload device configuration data based on user input. If the configuration engine 904 does not receive a command to upload device configuration data (block 1306), the example program of FIG. 13 ends.

[0098]

[0113] If the configuration engine 904 receives a command to upload device configuration data (block 1306), control proceeds to block 1308, where the example configuration engine 904 requests all device configuration data from the device. In some examples, the device configuration data includes device information associated with the device and IO parameter information corresponding to each IO parameter that the device is equipped to monitor and / or report. At block 1310, the example configuration engine 904 updates the database 608 with the device configuration data.

[0099]

[0114] In some examples, devices that have received IO messages from but are not yet commissioned (e.g., not represented in the database 608) are configured to store the generated IO data locally so that it is available when the device is commissioned and in active communication with the main server 132. For example, in some examples, the device may include a circular buffer for historical data that stores recently generated IO data, thereby overwriting the oldest IO data stored in memory. In some such examples, control proceeds to block 1312, where the example configuration engine 904 updates the database 608 with the historical IO data provided by the device. In some examples, if the device is not configured to store historical IO data, block 1312 may be omitted. The example program of FIG. 13 then ends. With all of the device configuration data stored in the database, a user may easily access IO parameters identified in the device configuration data and configure those IO parameters in association with one or more event rules and / or web pages.

[0100]

[0115] After the device has been commissioned and configured in the manner described above with respect to blocks 1304-1312, subsequent IO messages received from the device will follow a different path in the example flow diagram because the device is now represented in the database 608, resulting in a different outcome at block 1302. That is, returning to block 1302, if the example device identifier 902 determines that the device from which the IO message was received is represented in the database 608, control proceeds to block 1314. At block 1314, the example data analyzer 906 identifies IO parameters corresponding to the received IO message. In some examples, the data analyzer 906 identifies the IO parameters based on searching for the parameter addresses provided in the IO message in configuration data stored in the database 608.

[0101]

[0116] At block 1316, the example parameter value converter 910 determines whether the IO parameter is analog or discrete. If the IO parameter is discrete, the example parameter value converter 910 converts the value of the IO parameter to status text or other context-specific status indicator (block 1318). That is, rather than a binary 0 or 1 value, the example parameter value converter 910 can convert the value to a state based on the text represented by the value (e.g., On, Off, Opened, Closed, etc.), or some other binary indicator (e.g., one of two icons, one of two colors (e.g., red / green), a show / hide icon, etc.). Control then proceeds to block 1322. If the example parameter value converter 910 determines that the IO parameter is analog (block 1316), control proceeds to block 1320, where the example parameter value converter 910 converts the value of the IO parameter to descriptive text or other context-specific descriptive indicator. Similar to block 1318, the conversion at block 1320 is intended to convert the IO parameter value into an indicator that is easily understandable to a human based on the context represented by the IO parameter value. In some examples, the descriptive indicator can be a text-based description and / or an image, number, or icon that is easily understandable to an end user. For some analog-based values, the parameter value converter 910 can also apply one or more conversion factors in connection with the generation of the descriptive indicator. In some examples, blocks 1316-1320 can be omitted, and thus the IO parameter value is not converted into a context-specific indicator. In block 1322, the example time stamper 908 timestamps the value of the IO parameter at the time of receipt of the IO message. That is, in the illustrated example, the time stamper 908 stores the time of receipt of the IO message in the example database 608 along with the reported IO parameter value. The example program of FIG. 13 then ends and returns to complete the process of FIG. 12.

[0102]

[0117] FIG. 14 is a flow diagram illustrating an example implementation of block 1212 of FIG. 12. The example program of FIG. 14 begins at block 1402, where the example event analyzer 912 evaluates an event rule associated with an IO parameter. At block 1404, the event analyzer 912 determines whether the value of the IO parameter triggers an event. If the value of the IO parameter triggers an event, at block 1406, the example notification engine 916 generates a notification about the trigger event. At block 1408, the notification engine 916 sends a notification to the recipient associated with the trigger event. In some examples, the recipient is stored in the database 908 as configuration data associated with the event.

[0103]

[0118] At block 1410, the example event logger 914 updates the event log in the database 608. In some examples, the event logger 914 generates a log entry that identifies the IO parameter, the value of the IO parameter, the device reporting the parameter value, and a timestamp of when the parameter value was received (indicating when the event was detected or triggered). At block 1412, the example event analyzer 912 determines whether the event corresponds to a video capture event. If the event is configured by a definition to capture a video segment during a time window around the trigger event, then the event corresponds to a video capture event. If so, at block 1414, the event analyzer 912 requests a video segment corresponding to the event. In some examples, the request is sent to the video management system 614 to generate the video segment. Then, at block 1416, the example notification engine 916 sends a second notification with the video segment as an attachment to the recipient. The recipient of the second notification (sent in block 1418) may be the same as or different from the recipient of the first notification (sent in block 1408) as defined by the configuration data assigned to the event for which the notification was generated.

[0104]

[0119] After sending the second notification (block 1416), control proceeds to block 1418. Returning to block 1412, if the example event analyzer 912 determines that the event does not correspond to a video capture event, control proceeds directly to block 1418. At block 1418, the example event analyzer 912 determines whether the IO parameter is associated with another event rule. If the IO parameter is associated with another event rule, control proceeds back to block 1402. Otherwise, the example process of FIG. 14 ends.

[0105]

[0120] In some examples, blocks 1412-1416 may be omitted from the example program of Figure 14 because the video management system 614 is configured to independently determine when a video segment is needed and generate and send an associated notification without receiving a request from the event analyzer 912 as described above. An example process for implementing the video management system 614 in this manner is described in more detail below with respect to Figure 15.

[0106]

[0121] FIG. 15 is a flow diagram representing an exemplary program for implementing the video management system 614 of the main server 132. Alternatively, the exemplary program of FIG. 15 can be implemented by the video management system 506 of FIG. 5, independent of the main server 132. The exemplary program of FIG. 15 begins at block 1502, where the exemplary video segment generator 804 identifies a trigger event in an event log associated with a pending video capture event. As described above with respect to block 2810 of FIG. 28, each time an event is triggered (e.g., detected), the trigger event is logged in the event log. Thus, in some examples, the video segment generator 804 monitors the event log for changes and determines whether a newly detected event is associated with a video capture event. In this manner, the video management system 614 can automatically initiate a process for generating video segments without receiving a request from the event manager 616 as described above.

[0107]

[0122] At block 1504, the exemplary video segment generator 804 determines whether a threshold period for a camera (e.g., camera 508) to capture video has elapsed. If the threshold period has not elapsed, control remains at block 1504 until the threshold period has elapsed. In some examples, the threshold period is defined based on a post-event time interval set for the particular event identified. For example, if the post-event time interval is defined as one minute, the video segment generator 804 waits at least one minute after the detection of the event before proceeding. As mentioned above, in some examples, the post-event time interval cannot begin until the event is no longer triggered (or a second event is detected indicating that the conditions that triggered the first event no longer apply). In some examples, the threshold period also includes a post-processing period to compensate for the time delay for the camera to capture, encode, and store the video stream corresponding to the desired video segment.

[0108]

[0123] After the threshold period has elapsed, the video segment generator 804 extracts a video segment during a time window around the time of the trigger event (block 1506). In some examples, the start and end times for the video segment are defined by a pre-event time interval and a post-event time interval set for the event stored in the example database 608. In some examples, the extracted video segment is stored in the video database 808. In block 1508, the example video segment generator 804 converts the video segment into a web-readable format and creates a thumbnail with a thumbnail offset time set by a user. In some examples, the web-readable format is MP4 format. The thumbnail offset time defines the point in time in the video segment at which a frame is selected for a thumbnail image to be associated with the video segment. In some examples, the thumbnail offset time is defined relative to the start time of the video segment. Thus, if the thumbnail offset time is set to 0 seconds and the pre-event interval for the video segment is 20 seconds, the thumbnail should correspond to a video frame that occurs 20 seconds before the event. In other examples, the thumbnail offset time is defined relative to the time of the event such that an offset set to 0 seconds will result in a thumbnail corresponding to the video frame captured at the time the event is detected. The thumbnail offset time can be set to any point during the video segment. In some examples, the offset can default to the time of the event and / or a short period thereafter (e.g., 1 second, 2 seconds, 5 seconds, etc.), so that the thumbnail is more likely to represent the effects of the event and / or its immediate consequences. For some types of events, the thumbnail offset time can be set to occur before the event, so that the thumbnail is more likely to capture the person or situation that ultimately causes the event to occur.

[0109]

[0124] At block 1510, the exemplary video analyzer 806 determines whether the event is configured for computer vision analysis. If the event is configured for computer vision analysis, the exemplary video analyzer 806 analyzes the video segment for a vision-based event (block 1512). A vision-based event is an event that can be identified by image analysis of the video stream of the camera 508. Vision-based events are useful when it may be difficult or impossible to configure sensors to directly detect the event. Some exemplary vision-based events include certain safety events, such as collisions and / or near misses between people and / or material handling equipment moving around the material handling facility 100. As an example, the video analyzer 806 may determine that a moving vehicle (e.g., a forklift) has come within a few inches of a person working in the area. In such an example, in the absence of a collision, damage, or injury, the parties involved are unlikely to report the event (whether they are even aware of its occurrence or not), making it difficult to mitigate the occurrence of such potentially dangerous situations. However, using the video analytics disclosed herein, these events can be detected and automatically captured on the camera. In another example, the image analysis may include facial recognition analysis to identify a person captured in the video segment. At block 1514, the video analyzer 806 updates an event log with the identified vision-based event. Control then proceeds to block 1516. If the example video analyzer 806 determines that the event is not set for computer vision analysis (block 1510), control proceeds directly to block 1516.

[0110]

[0125] At block 1516, the example push service manager 612 pushes an indication to all subscribed web pages where the video segment is available. At block 1518, the example network communication interface 602 sends a notification with the video segment as an attachment to the recipient. At block 1520, the example video segment generator 804 determines whether there is another pending video capture event. If there is another pending video capture event, control returns to block 1502. In some examples, if the event is associated with multiple different cameras 508, control returns to block 1502 for the same trigger event. That is, in some examples, the process of extracting video segments and analyzing such video segments can be implemented for multiple cameras for a single trigger event. If the example video segment generator 804 determines that there are no pending video capture events (block 1520), the example process of FIG. 15 ends.

[0111]

[0126] The aggregation of data from the various controllers 116, 122, 124, 126, 128, 130 and / or servers 134, 136 in the main server 132 enables the main server 132 to detect configurable events occurring with respect to any aspect of the operation of the material handling facility 100 of FIG. 1. Additionally, the main server 132 may initiate certain actions and / or responses based on the detection of a system-defined event. As described with respect to the flow diagrams of FIGS. 12-15, actions initiated by the main server 132 may include generating a notification that is sent to a designated recipient to report the detection of the event and / or capturing a video segment associated with the event (which may be sent as an attachment with one of the notifications). Additionally, the main server may automatically generate reports and / or update a log of detected events based on an analysis of the data aggregated by the main server 132. Additionally or alternatively, as discussed above, the main server 132 may consolidate the collected data and display current data pertaining to any aspect of the condition and / or operation of the material handling facility 100 via various web pages and / or web applications hosted by the web server 146. In some examples, such web pages are dynamically updated such that current data is provided in substantially real-time to client devices 148 accessing a particular web page. Additionally or alternatively, the main server 132 may generate one or more graphical user interfaces for rendering via a display independent of the web pages and / or associated web applications.

[0112]

[0127] In some examples, different ones of the graphical user interfaces (whether provided via web pages or otherwise) may be configured with different types of information corresponding to different aspects of material handling equipment 100 that may be of interest to a particular user. Figures 21-59, described further below, show example graphical user interfaces for several example web pages hosted by web server 146. Although Figures 21-59 are described as web pages, in other examples, the same or similar graphical user interfaces may be generated by applications for display on a screen that are not web applications but are independent of web pages.

[0113]

[0128] As mentioned above, each of the controllers 116, 122, 124, 126, 128, 130 may implement the same or similar functionality as the main server 132 based on a limited set of IO data collected by each particular controller (and additional data provided by the main server). Flow diagrams illustrating example hardware logic, machine readable instructions, hardware implemented state machines, and / or any combination thereof for implementing the local controller 1100 of FIG. 11 (representing any one of the controllers 116, 122, 124, 126, 128, 130 of FIG. 1) are shown in FIGS. 16-20. The machine readable instructions may be one or more executable programs or portions of executable programs for execution by a computer processor, such as the processor 6112 shown in the example processor platform 6100 discussed below with respect to FIG. 61. The program may be implemented in software stored on a non-transitory computer-readable storage medium, such as a CD-ROM, a floppy disk, a hard drive, a DVD, a Blu-ray disk, or a memory associated with the processor 6112, although alternatively, the entire program and / or portions of the program may be executed by devices other than the processor 6112 and / or implemented in firmware or dedicated hardware. Additionally, although the exemplary program is described with reference to the flow diagrams shown in Figures 16-20, alternatively, numerous other ways of implementing the exemplary local controller 1100 may be used. For example, the order of execution of these blocks may be changed, and / or some of the described blocks may be modified, removed, or combined. Additionally or alternatively, any or all of the blocks may be implemented by one or more hardware circuits (e.g., discrete and / or integrated analog and / or digital circuits, FPGAs, ASICs, comparators, operational amplifiers (op-amps), logic circuits, etc.) configured to perform the corresponding operations without executing software or firmware.

[0114]

[0129] As mentioned above, the example processes of FIGS. 16-20 may be implemented using executable instructions (e.g., computer and / or machine readable instructions) stored on a non-transitory computer and / or machine readable medium, such as a hard disk drive, flash memory, read-only memory, compact disk, digital versatile disk, cache, random access memory, and / or any other storage device or storage disk in which information is stored for any duration (e.g., for an extended period of time, permanently, for brief instances, temporarily for buffering, and / or for caching of information).

[0115]

[0130] The example program of FIG. 16 begins at block 1602, where the example data analyzer 1104 monitors collected data. In some examples, the collected data includes IO data provided by devices and / or associated sensors being controlled and / or monitored by the controller 1100. Additionally or alternatively, the collected data may include information received from the main server 132. At block 1604, the example data analyzer 1104 identifies IO parameters associated with the collected data. At block 1606, the example parameter value converter 1108 determines whether the IO parameter is analog or discrete. If the IO parameter is discrete, the example parameter value converter 1108 converts the value of the IO parameter to status text or other context-specific status indicator (block 1608). That is, rather than a binary 0 or 1 value, the example parameter value converter 1108 may convert the value to a state (e.g., On, Off, Opened, Closed, etc.) based on the text represented by the value, or some other binary indicator (e.g., one of two icons, one of two colors (e.g., red / green), show / hide icon, etc.). Control then proceeds to block 1612. If the example parameter value converter 1108 determines that the IO parameter is analog (block 1606), control proceeds to block 1610 where the example parameter value converter 1108 converts the value of the IO parameter to descriptive text or other context-specific descriptive indicator, and control then proceeds to block 1612. As with block 1608, the conversion at block 1610 is intended to convert the IO parameter value to an indicator that is easily understandable to a human based on the context represented by the IO parameter value. In some examples, the descriptive indicator may be a text-based description and / or an image, number, or icon that is easily understandable to an end user. For some analog-based values, the parameter value converter 1108 may also apply one or more conversion factors in connection with the generation of the descriptive indicator.In some examples, blocks 1606-1610 may be omitted, and thus the IO parameter values ​​are not converted into context-specific indicators.

[0116]

[0131] At block 1612, the example event analyzer 1106 determines whether the value of the IO parameter triggers an event. In some examples, the event can be triggered based on multiple different parameters having a particular value and / or meeting a particular threshold based on the event rules stored in the example database 1112. Thus, in some examples, the determination at block 1612 is made based on an analysis of multiple IO parameters monitored by the data analyzer 1104. If an event is triggered, control proceeds to block 1614, where the example event analyzer 1104 determines whether the triggering event is associated with an operation of equipment. That is, when the event identified by the main server 132 relates to a change in data for updating a web page and / or other graphical user interface and / or generating a particular individual's notification information of the event, the local controller 1100 is implemented to control equipment in the material handling facility 100, and thus the event monitored by the example event analyzer 1106 is associated with the operation of such equipment. If the trigger event is associated with an appliance action, control proceeds to block 1616 where the example appliance controller 1116 implements the action. Control then proceeds to block 1618. If the trigger event is not associated with an appliance action (block 1614), control proceeds directly to block 1618.

[0117]

[0132] At block 1618, the example event analyzer 1106 determines whether a trigger event is associated with the notification. If a trigger event is associated with the notification, control proceeds to block 1620, where the example notification engine 1110 generates a notification regarding the trigger event. At block 1620, the example notification engine 1110 renders the notification via a display. In some examples, the display corresponds to the display 1114 associated with the local controller 1100. In other examples, the notification may be rendered via a display separate from but in proximity to the local controller 1100. At block 1624, the example communication board 133 transmits the notification to the main server 132. In some examples, the notification rendered via the display (block 1622) and the notification to the main server 132 (block 1624) are the same notification. In other examples, these notifications may relate to the same trigger event but may include different information. In some examples, block 1622 or block 1624 may be omitted, such that the notification generated in block 1620 is rendered via a display or transmitted to the main server 132 .

[0118]

[0133] At block 1626, the example data analyzer 1104 determines whether the IO parameter triggered another event. If the IO parameter triggered another event, control returns to block 1614. Otherwise, control proceeds to block 1628. Returning to block 1612, if the example event analyzer 1106 determines that the value of the IO parameter does not trigger an event, control proceeds directly to block 1628. Similarly, when the example event analyzer 1106 determines that the triggering event is not associated with a notification, control proceeds directly from block 1618 to block 1628. At block 1628, the example data analyzer 1104 determines whether there is another IO parameter. If there is another IO parameter, control proceeds back to block 1608. Otherwise, control proceeds to block 1630, where the process determines whether to continue. If so, control proceeds back to block 1602. If not, the example process of FIG. 16 ends.

[0119]

[0134] While Figure 16 illustrates an exemplary general process flow that may be implemented by any one of the controllers 116, 122, 124, 126, 128, 130 of Figure 1, Figures 17-19 provide specific exemplary processes outlining specific event rules and / or actions that may be implemented by the dock controller 116 in response to detecting a particular event associated with a corresponding dock 102. Additionally, Figure 20 provides specific exemplary processes outlining specific event rules and / or actions that may be implemented by the door controller 122 in response to detecting a particular event associated with a door in the material handling facility 100. Alternatively, the exemplary process of Figure 20 may be implemented by the dock controller 116 since the dock 102 includes a door 104. For purposes of illustration, implementations of the exemplary processes of Figures 17-20 will be described with reference to the local controller 1100. However, since the IO data collected by the various controllers 116 , 122 , 124 , 126 , 128 , 130 is aggregated by the main server 132 , the exemplary processes may additionally or alternatively be implemented by the main server 132 .

[0120]

[0135] The example process of FIG. 17 begins at block 1702, where the example data analyzer 1104 monitors dock data. As mentioned above, FIG. 17 is specific to the dock controller 116. Thus, as used herein, dock data refers to all data available to the dock controller 116 and may include IO data received from instruments and / or sensors communicatively coupled to the dock controller 116 via the example communication interface 1102, as well as any data received from the main server 132 via the example communication board 133. At block 1704, the example event analyzer determines whether the dock data indicates that a truck / trailer (e.g., trailer 300 of FIG. 3 and / or FIG. 4) is present at the dock 102. Different types of dock data may be used to make this determination. In some examples, the dock data indicative of such content is based on feedback from the trailer sensor 202. Additionally or alternatively, the presence of the trailer 300 may be inferred based on the vehicle restraint device 110 being in the engaged position and / or the dock leveller 108 being deployed and active. Additionally or alternatively, the presence of the trailer 300 may be determined based on information received from the main server 132 forwarding information indicative of a message sent by a truck driver (via the client device 148) reporting that the trailer 300 is parked at the designated dock 102.

[0121]

[0136] If the event analyzer 1106 determines that a trailer is not present at the dock 102, control proceeds to block 1706 where the example event analyzer 1106 determines whether the dock data indicates that a door (e.g., door 104) is not closed (e.g., based on feedback from a door sensor). If the door is not closed, control proceeds to block 1708 where the event analyzer 1106 determines whether an entry barrier (e.g., barrier 106) is available at the dock. If an entry barrier is not available, control proceeds to block 1712 where the example notification engine 916 generates a notification indicating a potential fall hazard. In some examples, generating the notification may involve rendering the notification via a screen local to the controller 116, such as, for example, the display screen 117. Additionally or alternatively, generating the notification may involve transmitting the notification to the main server 132 to disperse the notification to specific recipients and / or rendering a notification and / or graphics indicating the notification via one or more of the web pages and / or other graphical user interfaces. As previously mentioned, in some examples, the main server 132 may independently implement the example process of FIG. 17 to determine whether this notification needs to be generated without explicit communication from the controller 116 regarding such content. After generating the notification, control proceeds to block 1714. Returning to block 1708, if the entry barrier 106 is available, control proceeds to block 1710. At block 1710, the example event analyzer 1106 determines whether the dock data indicates that the entry barrier 106 is blocking an opening in the entry door (because the door is in an unclosed state, as determined by block 1704). If the entry barrier 106 is blocking an opening, there is no need to generate a notification because the barrier 106 acts as a protection against a fall hazard. Therefore, control passes directly to block 1714. However, if the barrier 106 is not blocking the opening, control passes to block 1712, which generates the notification discussed above.

[0122]

[0137] At block 1714, the example event analyzer 1106 determines whether the dock data indicates that no trailer is assigned to the dock. In some examples, this determination is made based on dock assignment information provided to the dock controller 116 from the main server 132, which may receive the information from a dock management system (e.g., the dock management system 502). If no trailer is assigned to the dock (but a trailer is detected to be present as determined at block 1704), control proceeds to block 1716, where the example notification engine 1110 generates a notification indicating that the trailer 300 is in the wrong dock. Control then proceeds to block 1718. If a trailer is assigned to the dock, control proceeds directly to block 1718.

[0123]

[0138] In block 1718, the example event analyzer 1106 determines whether the dock data indicates that the vehicle restraint (e.g., the vehicle restraint 110) is in override mode. If the vehicle restraint is in override mode, control proceeds to block 1720, where the example equipment controller 116 switches the exterior light indicator (e.g., the light indicator 206) to a state (e.g., a red light) indicating that the truck trailer should not be moved. In block 1722, the example event analyzer 1106 determines whether the dock data indicates that the truck trailer is no longer present at the dock. If the truck trailer is no longer present at the dock, control proceeds to block 1724, where the example notification engine 1110 generates a notification indicating a potential retreat at a red light. Control then proceeds to block 1726. If the trailer is still present at the dock (block 1722), control proceeds directly to block 1726. At block 1726, the example process determines whether to continue. If so, control returns to block 1702. Otherwise, the example process of FIG.

[0124]

[0139] The example process of FIG. 18 begins at block 1802 where the example data analyzer 1104 monitors dock data. At block 1804, the example event analyzer 1106 determines whether the dock data indicates that activity has been sensed within the truck trailer. In some examples, this determination is made based on feedback from the example motion sensor 204 monitoring movement within the trailer 300. If activity has been sensed within the trailer, control proceeds to block 1806 where the example event analyzer sets a timer to zero. Control then returns to block 1802. If no activity has been sensed within the trailer 300, control proceeds to block 1808 where the example event analyzer 1106 determines whether a timer has started. If not, the event analyzer 1106 starts the timer at block 1810. Control then proceeds to block 1812. If the timer has already started, as determined by block 1808, control proceeds directly to 1812. In block 1812, the example event analyzer 1106 determines whether the timer has exceeded a threshold (e.g., 5 minutes, 10 minutes, 15 minutes, a time set or calculated based on load, carrier, and / or equipment specific data, etc.). If the timer has exceeded the threshold, control proceeds to block 1814, where the example notification engine 1110 generates a notification indicating that there is no activity on the trailer 300. Control then proceeds to block 1816. If the time has not exceeded the threshold (block 1812), control proceeds directly to block 1816. In block 1816, the example process determines whether to continue. If so, control returns to block 1802. Otherwise, the example process of FIG. 18 ends.

[0125]

[0140] The example process of FIG. 19 begins at block 1902, where the example data analyzer 1104 monitors the dock data. At block 1904, the example event analyzer 1106 determines whether the dock data indicates user activation of a manually initiated (i.e., selectively initiated) actuator. A manually initiated actuator may be activated by a user based on the user pressing a button, selecting an option on a touch screen, and / or any other suitable means. As a specific example, the user may request that the door 104 be opened or closed, that the vehicle restraint device 110 be moved to an engaged or disengaged position, and / or that the leveler 108 be extended to an active position or retracted to a stored position. If the user has not activated a manually initiated actuator, control returns to block 1902. If the user has activated a manually initiated actuator, control proceeds to block 1906, where the example event analyzer 1106 determines whether a motion associated with the actuator is prevented by a linkage. The interlocks may depend on the particular action the user wishes to implement. For example, the opening of the door may be interlocked or coordinated with the presence of the trailer 300 and / or the vehicle restraint device 110 being engaged with the trailer 300, i.e., the door is prevented from opening until the trailer 300 is sensed to be present and / or the restraint device 110 is in an engaged position. Additionally, the operation of the leveller 108 may also be interlocked or coordinated with the door 104, i.e., the leveller may only be activated once the door 104 is open. These interlocks ensure that the correct sequence of actions is followed to maintain safety at the dock. If the event analyzer 1106 determines in block 1906 that there is no interlock that would prevent the action, control proceeds to block 1908, where the equipment controller 1116 implements the action associated with the actuator. Control then proceeds to block 1912.

[0126]

[0141] If the user attempts to implement a particular action in the wrong order, or if the interlocking prevents the action for some other reason, the interlocking prevents the action from being performed. While this ensures the safety of the user and any other personnel involved, the user's actions in attempting to implement the action may indicate that the user does not understand the correct action order and / or is simply ignoring the correct action order. This may indicate a need for the user to receive training. However, because of the interlocking, there is no way to track this behavior and bring such a need to attention, since nothing actually happened as a result of the user attempting to start the actuator. However, the examples disclosed herein overcome that challenge as well. In particular, when the event analyzer 1106 determines that the action was prevented due to the interlocking, control proceeds to block 1910, where the example notification engine 1110 generates a notification indicating the improper start of the action. In some examples, such events may be logged and tracked (e.g., by main server 132) over time to determine whether the event was an isolated incident or a recurring problem, allowing dock managers or other personnel to identify the potential need to provide training to anyone who attempted to implement actions that differ from established procedures. Control then proceeds to block 1912. At block 1912, the example process determines whether to continue. If so, control returns to block 1902. If not, the example process of FIG. 19 ends.

[0127]

[0142] The example process of FIG. 20 begins at block 2002, where the example data analyzer 1104 monitors dock data. At block 2004, the example event analyzer 1106 detects a door cycle in which the door 104 opens and then closes again. At block 2006, the example event analyzer 1106 determines whether the door data indicates that an object passed through the doorway during the door cycle. If an object passed through the doorway, control proceeds to block 2010. If nothing passed through the doorway, control proceeds to block 2008, where the example notification engine 1110 generates a notification indicating a false activation of the door 104. Control then proceeds to block 2010. At block 2010, the example process determines whether to continue. If so, control returns to block 2002. Otherwise, the example process of FIG. 20 ends.

[0128]

[0143] 16-20 have been described with reference to the local controller 1100 of FIG. 11, the example processes of FIG. 16-20 may additionally or alternatively be implemented by the main server 132 based on IO data received from the corresponding controllers 116, 122, 124, 126, 128, 130. That is, in some examples, the example data analyzer 906, the example parameter value converter 910, the example event analyzer 912, and the example notification engine 916 of FIG. 9 may perform corresponding functions and / or operations described in FIG. 16-20 with respect to the corresponding example data analyzer 1104, the example parameter value converter 1106, the example event analyzer 1106, and the example notification engine 1110 of FIG.

[0129]

[0144] 21 is an example graphical user interface presented by an overview web page 2100 that provides summary information associated with the operation and / or condition of the material handling facility 100 that may be of interest to a particular user. In particular, the overview web page 2100 includes an example dock and yard summary block 2102, an example energy summary block 2104, an example safety summary block 2106, an example maintenance and asset management summary block 2108, an example event log 2110, and an example video log 2112.

[0130]

[0145] The example dock and yard summary block 2102 provides a summary of the number and location of trailers currently parked at the docks 102 of the material handling facility 100. The dock and yard summary block 2102 may include an indication of the number of active alerts and / or associated events that have been triggered for the dock 102 and / or associated loading and unloading of trailers at the dock. In some examples, the dock and yard summary block 2102 provides links to one or more other web pages, such as those shown in Figures 23-43 and 47-50, which are described further below.

[0131]

[0146] The example energy summary block 2104 provides a summary of the amount of energy consumed by the material handling equipment 100 and / or specific parts of the material handling equipment. Such information may be useful when the material handling equipment 100 includes one or more cold storage compartments. In some examples, the energy summary block 2104 provides an indication of the amount of energy consumed relative to a threshold to indicate whether the energy consumed is more or less than expected. If the energy consumed is more than expected, this may indicate that one or more doors of one or more cold storage compartments (monitored and controlled by corresponding door controllers 122 in FIG. 1 ) have been opened too long and / or too often, potentially resulting in a loss of energy. In some examples, these scenarios are associated with configurable events and / or alarms that may be triggered. In some such examples, the energy summary block 2104 includes an indication of the number of active alarms and / or associated events that have been triggered. In some examples, the energy summary block 2104 provides links to one or more other web pages that provide additional details regarding the freezer compartments, doors associated with the freezer compartments, and / or other items related to energy consumption within the material handling equipment 100, such as the example web pages shown in FIGS. 45 and 46, further described below.

[0132]

[0147] The example safety summary block 2106 provides a summary of detected events and / or alarms indicating safety conditions and / or potential safety risks. The safety events may relate to the unloading and loading of trailers at the dock 102 (e.g., whether or not the vehicle restraints 110 have secured the trailers in place) and / or the movement and handling of material within the material handling equipment 100 (e.g., collisions and / or near misses). In some examples, the safety summary block 2106 provides links to one or more other web pages, such as those shown in Figures 50-56, which are described further below.

[0133]

[0148] The example maintenance and asset management summary block 2108 provides a summary of information related to maintenance, repairs, and / or warranties for equipment assets used in the material handling facility 100. In some examples, the maintenance and asset management summary block 2108 provides links to one or more other web pages, such as those shown in Figures 57-59, which are described further below.

[0134]

[0149] The example event log 2110 provides a list of events triggered within the material handling equipment 100 along with summary information including time of occurrence, a brief description of the event, and / or a link to a video segment associated with the detected event. The example video log 2112 provides a list of recent video segments captured and their association with events detected in the material handling equipment 100. In some examples, the event log 2110 and / or the video log 2112 may be provided on a separate web page, independent of the summary blocks 2102, 2104, 2106, 2108.

[0135]

[0150] 22 is another example graphical user interface presented by an overview web page 2200 that provides summary information associated with the operation and / or conditions of the material handling facility 100 that may be of interest to a particular user. Similar to the overview web page 2100 of FIG. 1, the example overview web page 2200 of FIG. 22 includes an example dock and yard summary block 2202, an example energy summary block 2204, an example safety summary block 2206, and an example maintenance and asset management summary block 2208. As shown in the example illustrated in FIG. 22, the summary blocks 2202, 2204, 2206, 2208 show similar information to the summary blocks 2102, 2104, 2106, 2108 of FIG. 21 discussed above. Additionally, by selecting a particular one of the summary blocks 2202, 2204, 2206, 2208 of FIG. 22, the user may be directed to other web pages that provide more detailed information.

[0136]

[0151] 23 is an example graphical user interface presented by an example dock monitor web page 2300. As shown in the illustrated example, the dock monitor web page 2300 includes an example current period summary block 2302, an example historical utilization summary block 2304, and an example historical loading time summary block 2306. The example current period summary block 2302 presents the number of incoming and / or outgoing trailers scheduled to be loaded and / or unloaded during the current period (e.g., the current day), the number of incoming and / or outgoing trailers that have completed loading and / or unloading, and the number of trailers currently in the process of loading or unloading. Additionally, the example current period summary block 2302 provides an indication of the progress of all trailers for the current period. An example historical utilization summary block 2304 and an example historical loading time summary block 2306 provide an indication of utilization of docks within material handling facility 100, as well as an indication of the average time it takes to load and / or unload a trailer for a specified historical period (e.g., last day, last week, last month, individual period). In some examples, the historical period may be user selectable. Additionally, as shown in the illustrated example, dock monitor web page 2300 provides a table 2308 that includes utilization and loading times for individual docks within material handling facility 100.

[0137]

[0152] 24 is an example graphical user interface presented by an example dock monitor web page 2400. As shown in the illustrated example, the dock monitor web page 2400 includes a series of graphics, icons, and / or associated information representing the condition of a series of docks 102 of the material handling equipment 100 as determined based on data collected by the main server 132 from the dock controllers 116 and / or other devices in communication with the main server 132. For example, when the trailer sensor 202 detects and / or generates a signal indicating the presence of a trailer at the corresponding dock, a trailer icon 2402 is shown at the corresponding dock in the dock monitor web page 2400. In some examples, next to the trailer icon 2402 (e.g., above the trailer icon identified by the load identification reference 2403 shown for the ninth dock in FIG. 24), a carrier code, a shipping company name, a load number, and a trailer number may also be identified. The trailer icon 2402 or the load identification reference 2403 may be an active link that, when selected, redirects or opens another web page or window / pop-up containing information related to the particular load. As shown in FIG. 24B, a symbol / icon adjacent to a load identification reference may function similarly. In some examples, after a trailer is detected or verified at a particular dock (e.g., based on feedback from the trailer sensor 202), the main server retrieves the carrier and trailer number information collected from the driver (discussed further below) and pushes that information to the dock monitoring web page 2400 for rendering. Alternatively, this may be done when assigning a trailer to a particular loading dock.

[0138]

[0153] Whether the tractor unit icon 2406 is depicted with the trailer icon 2402 can be based on feedback from a separate sensor and / or input provided by the trucker or carrier when checking in regarding whether the trailer is being delivered (e.g., a monitored trailer in Dock 4 of FIG. 24) or whether the trailer is actually being loaded / unloaded (e.g., a trailer in Dock 3 of FIG. 24). In situations where a trailer is not being actively loaded or unloaded (whether a delivered or monitored load or an actual load), a parked trailer icon 2404 can be shown on the corresponding dock (e.g., Dock 12 in the illustrated example) along with a "parked" indicator or trailer stand icon. In some examples, logistics personnel assign parked trailers a specific name that can be shown next to the parked trailer icon 2404.

[0139]

[0154] In some examples, a refrigeration indicator 2401 is associated with a trailer icon 2402 corresponding to a refrigerated or temperature controlled load. In the illustrated example, the temperature control indicator 2401 is a snowflake, but can be any other indicator. For example, in some examples, the temperature control indicator 2401 is represented by drawing the trailer icon 2402 and / or the tractor unit icon 2406 with a blue or red bar, outline, and / or fill. In some examples, the dock monitoring webpage 2400 for the temperature control indicator 2401 also shows a current temperature indicator 2405 for the trailer based on feedback from a temperature sensor for the respective trailer. In some examples, the current temperature indicator 2405 can serve as the temperature control indicator 2401. In some examples, the main server 132 monitors the current temperature against a threshold temperature or upper and lower thresholds of a temperature range. If the temperature rises above or falls below the threshold temperature or falls outside of the range, the main server can generate an alert or notification to a dock manager at a logistics office that the trailer temperature at a specified dock has risen above or fallen below the threshold or is outside of an acceptable range. Monitoring the temperature in this manner can assist the dock manager in maintaining a cold chain for unloading the products in the trailer. In some examples, the temperatures of individual pallets and / or other cargo units or sections (e.g., separated by bulkheads) within the trailer and / or material handling equipment 100 can be displayed and / or accessible for display via the example dock monitoring web page 2400.

[0140]

[0155] In some examples, a driver arriving at the facility with a trailer for loading and / or unloading can check in at a kiosk corresponding to one of the client devices 148 of FIG. 1 that provides access to an exemplary driver check-in webpage 2500 shown in FIG. 25. That is, in some examples, the kiosk comprises a client device 148 maintained by an operator of the material handling facility 100. Additionally or alternatively, the driver can access the driver check-in webpage 2500 using his or her smartphone or other handheld device (e.g., corresponding to a different client device 148). In some examples, as shown in FIG. 25, the driver can provide a mobile phone number, which is then used to transmit a text message to the driver to provide instructions and / or indicate the status of the loading and / or unloading of the truck. For example, the driver can complete the entry fields shown in the example illustrated in FIG. 25. As shown in the illustrated example, in the case of a refrigerated or temperature-controlled trailer, the driver can be prompted to enter the current temperature of the trailer. Another exemplary driver check-in web page 2600 is shown in the illustrated example of FIG.

[0141]

[0156] After the driver submits the information, the main server 132 can generate a first notification directly on a web page confirming that the check-in information has been received and sent to the logistics office. This notification can further instruct the driver to check the dock status page for dock assignments. Additionally or alternatively, if the driver included a mobile phone number, the main server 132 can transmit instructions and / or confirmation via text message confirming receipt of the check-in information and indicating that a next text message with the dock assignment will be sent.

[0142]

[0157] In addition to providing a confirmation notification to the driver, after receiving the aforementioned new check-in information, the main server 132 generates a separate notification to inform the dock manager (or other personnel) at the logistics office of the new arrival and the need for a new dock assignment. In some examples, this notification is a check-in pop-up 2407 that appears on the dock monitoring web page 2400 of FIG. 24 with the relevant information and an option for the user (e.g., dock manager) to assign the truck to a particular dock. If the user chooses to assign a dock, a dock assignment web page 2700 can appear with a dock assignment pop-up 2702 providing a list of available docks, as shown in FIG. 27. In some examples, the list of available docks corresponds to docks that have not sensed the presence of a trailer and are not otherwise scheduled for a different truck.

[0143]

[0158] In some examples, after a truck is assigned to a particular dock, the information can be conveyed back to the driver via the driver check-in web page 2500, 2600 and / or another similar web page. In some such examples, facility-related information that may be relevant to the driver (e.g., an indication that the dock is cold, an estimate of the completion time for loading / unloading the truck based on current activity at all docks, and available material handling equipment and / or personnel working at the dock) can be pushed to a web page for review by the driver. Thus, in some examples, in accordance with the teachings of the present disclosure, the driver and the dock manager (or other personnel) can communicate such information to each other in substantially real-time.

[0144]

[0159] In some examples of FIG. 24, the notification to the dock manager that a trailer needs to be assigned to a dock can include a visual indicator other than an automatic popup, such as, for example, a bell icon 2408 that illuminates, becomes visible, and / or changes appearance in other ways. In some such examples, when a user selects the bell icon 2408, a dock and trailer queue popup 2800 can appear in the assignment tab with check-in information, as shown in FIG. 28. In some examples, if the trailer temperature entered by the driver is above a certain temperature threshold, the popup 2800 can include an alert of trailer overheating. Additionally or alternatively, the main server 132 can transmit a separate notification to the dock manager and / or the shipping and receiving manager to report the trailer overheating and address the issue, for example, by rejecting the shipment. In some examples, the assignment tab of the dock and trailer queue popup 2800 includes a drop-down selector 2802 that lists only the docks available for assignment. That is, the drop-down selector 2802 would not list any docks shown on the dock monitoring web page 2400 that already have a trailer assigned to them. As previously mentioned, the main server 132 determines whether a trailer is associated with a particular dock based on the trailer sensor associated with the dock (e.g., vehicle restraint engaged) and / or any other sensor or device. Thus, as can be seen, the main server can facilitate dock management by collecting data and analyzing data obtained from disparate locations. This is only possible in the technical environment of the material handling facility disclosed herein, where sensors at the docks are monitored by the respective dock controllers 116, which report to the main server 132, which also receives network communications from drivers providing check-in information and transmits the collected information to logistics personnel to make a decision on where to assign new trucks.

[0145]

[0160] After a particular dock is selected and assigned to the trailer, the main server 132 generates a timestamp for the action and can again generate multiple notifications that are transmitted to appropriate recipients and update appropriate web page interfaces. For example, a first notification can be displayed on a web page viewed by the logistics personnel who made the dock assignment confirming that the trailer has been assigned. Separately, the main server 132 can transmit details associated with the trailer with respect to the assigned dock (e.g., carrier name, customer name, trailer number, etc.) to the dock controller 116 and display that information via the display screen 117. Additionally, in some examples, the main server 132 can transmit another text message to the trucker indicating the assigned dock. In some examples, the text message can include the direction in which the dock is located, a timestamp indicating the check-in time, and / or any other suitable information (e.g., the time of the scheduled appointment). In some examples, the main server 132 updates the dock monitoring web page 2400. Notably, when a dock is assigned, it may take a short period of time for the trucker to move the trailer into position at the dock. Thus, in some examples, an indication is provided, such as the message "Waiting for Trailer" 2410 shown in the second dock of FIG. 24, to indicate that the dock has been assigned but the trailer has not yet arrived. After the trailer is detected, the main server 132 again updates the dock monitoring web page 2400 to show the trailer icon 2402. In some examples, a second timestamp is generated when the trailer is first detected. In this manner, the time between the initial check-in (e.g., dock assignment) and the actual arrival of the trailer at the dock can be monitored. This can facilitate the appropriate determination of late fees to be assessed by the owner of the material handling equipment.

[0146]

[0161] The trailer may be positioned at a dock to which it was not assigned. In some such examples, if a trailer is detected at a dock, but the dock does not have a trailer assigned to it, the main server 132 may generate an alarm and display an indicator 2412 that reads "Not assigned," as shown for dock 8 in the example illustrated in FIG. 24. In some examples, the indicator 2412 may flash to draw the attention of a logistics worker that the trailer is at the wrong dock. In some examples, the indicator 2412 may stop flashing after the worker acknowledges the alarm and / or otherwise silences or avoids the alarm. In some examples, additional actions may be taken when a trailer is detected at a dock that is not assigned to receive trailers. For example, the dock doors may be interlocked so that they cannot be opened as a security measure. Additionally or alternatively, an alarm signal at the dock may be activated to inform the driver and / or other personnel that the trailer is at a dock where it should not be. Similar to the above, the alarm signal may be turned off when a person acknowledges the alarm, turns off the alarm, bypasses the alarm, and / or responds to the alarm in other ways.

[0147]

[0162] In some examples, after the trailer is positioned in the correct dock, the vehicle restraint 110 is activated to secure the trailer in place. Whether the vehicle restraint 110 is in an active state (engaged to a trailer), an override state, or a stowed state (not engaged to a trailer) can be represented in the example dock monitoring webpage 2400 by a restraint signal icon 2414. In some examples, the restraint signal icon 2414 corresponds to and / or is similar to the light indicator 206 shown in FIG. 2 and provides a red signal (e.g., a red light) whenever the restraint signal indicates that the vehicle restraint 110 is active or in an override mode and provides a green signal (e.g., a green light) when the vehicle restraint is not active or in a stowed position. In some examples, the event rule can trigger an alarm when the presence of a trailer is sensed at a particular dock but the vehicle restraint 110 is not active and not engaged to a trailer, for the first dock in the example dock monitoring webpage 2400 of FIG. 24. In such examples, an alert icon 2416 may be displayed adjacent to the corresponding dock. In some examples, when a user (e.g., a logistics worker) clicks on the alert icon 2416, additional details about the triggering event associated with the alert may pop up. In some examples, a video segment captured about the event may pop up and automatically begin playing.

[0148]

[0163] In the example illustrated in FIG. 24 , the dock monitor web page 2400 includes a door icon 2418 to illustrate whether the door 104 at the corresponding dock is closed (e.g., represented in the first and second docks depicted in FIG. 24 ) or open (e.g., represented in the third and fourth docks depicted in FIG. 24 ). In some examples, the door 104 is represented as open as long as the door is at least partially open (e.g., not closed). Whether the door is closed or open (e.g., not closed) can be determined based on sensor feedback, which is provided to the associated dock controller 116 and then reported to the main server 132. That is, in some examples, after the dock controller 116 receives and executes a command to open the door (e.g., from a forklift operator or other person near the door), a sensor (e.g., a limit switch) associated with the door 104 can generate an output indicating that the door is open. After the dock controller 116 receives this sensor feedback, the dock controller 116 transmits a network communication (e.g., an IO message) to the main server indicating that the door is open. After receiving such a message, the main server 132 updates the dock monitoring web page 2400 (e.g., via a push notification to all active instances of the web page that subscribe to such information) so that the door icon 2418 illustrates that the door at the corresponding dock is open. Substantially simultaneously with the dock controller 116 reporting that the door is open, the dock controller 116 may receive feedback from the motion sensor 204 facing the trailer indicating that motion has been detected within the trailer (likely indicating the presence of one or more personnel moving about within the trailer). In some examples, when the motion sensor 204 detects the presence of personnel within the trailer, the dock controller 116 sends a second network transmission (e.g., an IO message) to the main server 132.In response to this second message, the main server 132 may again update the dock monitor web page 2400 to include a forklift icon 2420 within the open door icon 2418 (shown for the fifth dock in FIG. 24) to represent that a person has been detected within the trailer. In some examples, if no motion is sensed within the trailer for a threshold period of time, the main server 132 may infer that no one is working within the trailer and therefore remove the forklift icon 2420.

[0149]

[0164] Additionally, in some examples, when sensor feedback associated with a barrier 106 of Figures 1-4 indicates that the barrier is in active use at the door's entrance, a barrier icon 2422 may be drawn on the door icon 2418 corresponding to the door. The barrier icon 2422 may be drawn when the door icon 2418 indicates that the door is closed (sixth dock in Figure 24) or when the door is open (ninth dock in Figure 24).

[0150]

[0165] In some examples, the duration each trailer has been parked at its corresponding dock is illustrated in the example described in Figure 24 with a timer 2424 displayed on the trailer icon 2402. In some examples, the time represented by the timer 2424 on the dock monitor web page 2400 of Figure 24 corresponds to (e.g., is synchronized with) the time indicated by the timing indicator 306 located on the dock as shown and described with respect to Figure 3. In some examples, the timing indicator 306 and timer 2424 are started automatically in response to a driver checking in via the driver check-in web pages 2500, 2600 of Figure 25 or Figure 26. In other examples, the timer 2424 is triggered based on another input and / or combination of inputs. For example, the timer 2424 may additionally and / or alternatively be triggered based on at least one of when the presence detector 112 detects the presence of a trailer at the dock, when the vehicle restraint device 110 is activated to engage the trailer, when the door 104 is initially opened, and / or when the dock leveler 108 is activated and extended into the trailer. In some examples, the particular trigger(s) for starting the timer may be set by a user. In some examples, the trigger(s) may be defined globally (e.g., for all docks or a selected group of docks) or may be set individually for separate docks. In some examples, the trigger for the timer 2424 may depend on some other user-defined parameter (e.g., different trigger(s) may be defined for different carriers).

[0151]

[0166] Additionally or alternatively, in some examples, a timer progress bar 2426 is displayed on the trailer icon 2402 that advances over the length of the trailer icon 2402 as time progresses toward a threshold load / unload time set for the expected duration for loading and / or unloading the trailer. In the described example, the threshold time is set to a default duration of two hours. However, in other examples, the threshold load / unload time may vary. Furthermore, in some examples, different threshold load / unload times may be set for different trailers and / or based on specific information provided by the driver via the check-in webpage 2500 and / or based on carrier, customer, and / or contact information. For example, in some examples, the driver may provide time-sensitive information (e.g., the driver's work schedule and how much time is left in the driver's current shift) and / or loading-related information (e.g., how much material is loaded on the truck to be unloaded) that can be used to adjust the threshold time. In some examples, the threshold time may be automatically adjusted based on such driver input. In other examples, such driver input can be provided to a dock manager to evaluate whether the threshold time for a particular truck should be adjusted based on available resources, taking into account other trucks that are loading and / or unloading. In some examples, as the timer approaches the threshold load / unload time (e.g., less than 30 minutes of threshold time remaining, 75% of the time has elapsed, etc.), the appearance of the timer progress bar 2426 can change (e.g., from green to yellow, flashing, and / or thickening, etc.), as represented by the difference between the fourth and fifth docks in the described example. Additionally, the appearance of the timer progress bar 2426 can change again (e.g., to red, flashing, and / or thickening, etc.) after the threshold load / unload time is reached and / or exceeded, as represented for the ninth dock in the described example.In some examples, the same color change scheme is implemented in the display of the timing indicator 306 of Figure 3 so that personnel working on the dock have the same indicator as represented in the dock monitoring web page 2400 seen in the logistics office. Providing a visual timer in a unified manner for multiple docks, as represented by Figure 24, allows dock managers and / or other personnel to identify trailers that may be late in loading and / or unloading so that the dock manager can quickly reallocate resources to speed up processes at a particular dock and reduce overdue fees.

[0152]

[0167] In some examples, an inactivity alert 2428 may be generated in response to no motion being sensed in the trailer for a threshold period (e.g., 15 minutes) while the timer 2424 is running. In some examples, the alert may vary as the period of inactivity increases over different intervals (e.g., 15, 30, 45, 60, 90, or 120 minutes). This may provide information regarding whether the loading and / or unloading of a particular trailer is progressing to complete the task within an allotted time frame (e.g., threshold loading / unloading time).

[0153]

[0168] The example dock monitor web page 2400 of Figure 24 provides an on-time metric 2430 for each dock that indicates the percentage of trailers that were at the dock in a given period (e.g., a week, a month, etc.) that were loaded or unloaded within an allotted amount of time (e.g., 2 hours). The on-time metric 2430 may also include a trend indicator (e.g., an arrow pointing up or down) to show whether the percentage of on-time loading or unloading at a particular dock is increasing or decreasing. In this manner, docks associated with a greater number of delays that result in late fees can be identified and actions can be taken to reduce such costs.

[0154]

[0169] In some examples, upon selection of a particular dock and / or trailer on the dock monitor web page 2400, a menu of options 2432 appears through which the dock manager can indicate that loading and / or unloading of the associated trailer is complete. In some examples, the options presented via the menu 2432 are dynamically updated based on available information about the dock and / or trailer located at the dock. For example, if no trailer is present at the dock, the available options listed in the menu 2432 are limited to information about the dock itself. However, after a trailer is detected at the location, the menu 2432 can automatically update to allow the user to access information about the trailer (e.g., driver and / or carrier information, reservation information, load information, etc.). In some examples, completion of a load (load or unload) can trigger additional options available in the menu 2432 for the associated trailer. In some examples, a forklift operator may alternatively access the dock monitor web page 2400 via a handheld device (e.g., remote client device 148) to indicate completion of the trailer load. Additionally or alternatively, the display screen 117 on the dock controller 116 may include a button on a graphical user interface that may be presented to indicate completion of loading and / or unloading. When the user indicates that the load is complete, the main server 132 may generate a load complete popup 2900, shown in FIG. 29, that provides details associated with the particular trailer selected for the user to verify that the correct trailer was selected. After the user confirms that the load is complete, the main server 132 may generate a second notification that confirms that the trailer has been successfully checked out of the active state in the dock management system. In some examples, the trailer icon 2402 on the dock monitor web page 2400 is updated to reflect this change in state (e.g., a check mark positioned on the trailer) until the trailer is removed from the dock.In some examples, the main server 132 transmits a notification to the driver via text message indicating that the load is complete and requesting the driver to safely proceed to the logistics office for paperwork. At the same time, information associated with the completed trailer can be added to the dock release tab and trailer queue pop-up 2800, as shown in FIG.

[0155]

[0170] As shown in the example illustrated in FIG. 30, the pop-up 2800 includes a trailer seal entry field 3002 in which a trailer seal identification number can be entered. The seal can be entered by a dock manager at the logistics office, a forklift operator at the dock (via a remote device accessing the dock monitoring web page 2400), or a yard jockey or watchman at the dock yard. Recording the seal in this manner allows for the creation of an electronic seal log that is linked to other information generated for the trailer, including the specific load and its timing. After the trailer seal is recorded and all other paperwork is completed (e.g., the driver physically checks boxes verifying the bill of lading, trailer temperature, seal number, etc.), the dock manager can finalize the transaction by checking out the trailer. In some examples, the main server 132 transmits a second text notification to the driver to confirm that the paperwork has been completed and that the driver can safely proceed to the trailer for departure.

[0156]

[0171] For purposes of illustration, FIG. 24B is an expanded view of a portion of an exemplary dock monitor web page 2400 in which different trailer icons 2402 are located on different docks (e.g., dock numbers 13-18) of the material handling facility 100. FIG. 24B illustrates additional and / or alternative graphics that may be provided to a user to enable the user to understand the status associated with the trailers at each dock. In some examples, a reservation time 2436 is rendered on the trailer icon 2402 to indicate the time of the scheduled reservation (arrival and / or departure) for the trailer. In some examples, if the trailer arrives before the time of the scheduled reservation, a reservation countdown 2438 is provided to indicate the amount of time remaining until the scheduled reservation start time. In some examples, an additional timer may be triggered to begin counting when the reservation time is reached, regardless of whether the trailer has arrived and / or whether the trailer is loaded and ready to move. Such timers may be monitored to determine the occurrence of detention or overdue fees. In some examples, when this timer reaches a threshold, a notification may be triggered to inform the appropriate individual regarding the delay beyond the scheduled appointment.

[0157]

[0172] The trailer associated with the delivered load is shown, and thus in the illustrated example, with the trailer icon 2402 (e.g., trailers at dock numbers 15 and 16) that does not have a tractor unit icon 2406 associated with it, the dock monitoring web page 2400 can include a delivery status indicator 2440 that indicates whether the delivered trailer should remain at the dock or be moved to the yard after loading or unloading is complete.

[0158]

[0173] In the illustrated example, a load direction indicator 2442 is rendered for each trailer. The load direction indicator 2442 indicates whether the load is an incoming load to be unloaded at the facility (the arrow of the indicator 2442 points toward the door icon 2418) or an outgoing load to be loaded at the facility (the arrow of the indicator 2442 points away from the door icon 2418). In some examples, the dock monitor web page 2400 includes a load counter 2444 that tracks the progress of the associated load movement (loading or unloading) and the total size of the load. More specifically, as shown in the illustrated example, the load counter includes two numbers, a first number indicating the number of cargo units (e.g., pallets, racks, parcels, or other cargo units) that have been moved, and a second number indicating the total number of cargo units to be moved to complete the load. Additionally or alternatively, in some examples, a loading status indicator 2446 is rendered to provide an indication of the progress of the load assembled in the scaffolding environment associated with the loading dock. In this example, the loading status indicator 2446 is associated with one of four states including: (1) not started (in the case of dock #16), (2) partially completed or in progress (in the case of dock #13), (3) waiting (in the case of dock #15), and (4) complete (in the case of dock #17). The waiting state is intended to convey the concept that the cargo to be loaded is still being prepared within the material handling equipment 100 or that an element of the load is not available for loading. In some examples, a check mark is also displayed adjacent to the associated trailer having a loading status of complete.

[0159]

[0174] In some examples, different docks and / or associated trailers on the docks may be assigned different priorities for loading or unloading. In the illustrated example, the trailer on dock number 17 is designated as having priority over the other trailers, as indicated by the priority indicator 2448 including a single exclamation point. Additionally, in this example, the trailer on dock number 15 is given a higher priority (e.g., twice the priority) than dock number 17, as indicated by the priority indicator 2448 having two exclamation points.

[0160]

[0175] In some situations, a load or cargo in one trailer at a particular dock may need to be moved to a different trailer at a different dock. This scenario may be represented on the dock monitor webpage 2400 via a reciprocal dock status indicator 2450, shown adjacent to a trailer icon at dock number 14 in the example illustrated in FIG. 24B. In some examples, the reciprocal dock status indicator 2450 includes a directional indicator that includes two arrows, either arrows pointing outward away from each other (as shown) or arrows pointing inward toward each other. The directional indicator pointing outward represents that cargo in the trailer needs to be moved to one or more different trailers. In contrast, an arrow pointing inward represents that cargo from one or more other trailers needs to be moved into the corresponding trailer. In some examples, the reciprocal dock status indicator 2450 also includes a reciprocal dock trailer involvement indicator to indicate the number of other trailers currently located at different docks to which cargo should be transferred to or from the corresponding trailer. In this example, the number is zero, indicating that there are no trailers currently in the material handling equipment 100 that should receive cargo for the trailer at dock number 14. In other examples, the inter-trailer involvement indicators 2450 can include both trailers currently at different docks and trailers that are expected but have not yet arrived at different docks on which the load at the corresponding dock depends. The inter-dock status indicators can be active links that, when selected, redirect or open another web page or window / pop-up that contains information related to inter-dock relationships and status.

[0161]

[0176] FIG. 31 illustrates an exemplary graphical user interface presented by a dock scheduling web page 3100. The dock scheduling web page 3100 of FIG. 31 allows for the arrangement or scheduling of business-to-business reservations (e.g., between a carrier and a material handling facility 100). In particular, truck drivers and / or other personnel from a carrier may access the exemplary web page 3100 of FIG. 31 to set up reservations for delivery and / or loading of a trailer. In some examples, after the reservation information is entered, the main server 132 transmits a notification (e.g., via text or email) to personnel in a logistics office, shipping and receiving managers, and / or other applicable recipients. Additionally, in some examples, a bell 2408 may be activated to indicate that new information is accessible via the dock and trailer queue pop-up 2800 of FIGS. 28 and 30. In particular, the received reservation information may be provided in a reservation tab of the pop-up 2800.

[0162]

[0177] In some cases, it may be necessary to take a particular dock out of service for maintenance (e.g., equipment repair or upgrade). Thus, in some examples, the main server 132 may provide a maintenance schedule pop-up 3200 to schedule maintenance, as shown in FIG. 32. As shown in the example illustrated in FIG. 32, the maintenance may be preventative or scheduled, or may be corrective (e.g., based on equipment failure). In either case, when maintenance is designated for a particular dock, the main server 132 generates a notification confirming the action taken by the user. The main server 132 may also transmit a notification (e.g., via text or email) to a maintenance manager to indicate that a particular dock door has been taken out of service for maintenance. Additionally, the main server 132 updates the dock monitor webpage 2400 by drawing one or more maintenance icons 2434 (e.g., orange cones) associated with the particular door designated for maintenance (e.g., the 10th door in the example illustrated in FIG. 24). Additionally or alternatively, the example maintenance and asset management summary block 2108 of the overview webpage 2100 of FIG. 21 may reflect the maintenance status of the door (represented by reference numeral 2114). Further, the main server 132 may transmit the door status to the dock controller 116 associated with the particular dock to display a notice on the local display screen 117 that the door is disabled and / or out of service for maintenance.

[0163]

[0178] After the maintenance is completed, the user may so indicate via a maintenance completed pop-up 3300 shown in Figure 33. As shown in the illustrated example, the completion of the maintenance may be time-stamped to track when the maintenance at each dock occurred. After indicating the completion of the maintenance, the main server 132 may again update the dock monitor web page 2400 by removing the maintenance icon 2434 and designating the dock as available for trailers.

[0164]

[0179] FIG. 34 illustrates an exemplary graphical user interface corresponding to a dock status web page 3400. In some examples, the dock status web page 3400 of FIG. 34 includes information similar to that shown in the dock monitor web page 2400 of FIG. 24, except that the information in FIG. 34 is presented in a tabular format to allow for sorting and / or filtering of the data. In some examples, the dock status web page 3400 of FIG. 34 can include additional and / or different information from the dock monitor web page 2400 of FIG. 24. For example, as shown in FIG. 34, the exemplary dock status web page 3400 can include information identifying the driver, company, type of loading and / or unloading, amount of cargo to be loaded and / or unloaded, check-in and check-out times, overage rules associated with the driver / company, etc.

[0165]

[0180] FIGURE 35 illustrates an exemplary graphical user interface presented by a Yard Management web page 3500 that includes a trailer icon 3502, similar to trailer icon 2402 of FIGURE 24, located in a parking lot that represents a yard of material handling equipment. In some examples, a user can use a trailer move pop-up 3600, illustrated in FIGURE 36, to identify a particular trailer to be moved to a new parking space in the yard or to a particular dock. In some examples, after a new location for the selected trailer is specified, the main server 132 automatically transmits a notification to a yard jockey or watchman in the yard indicating which trailer needs to be moved to where. Additionally, the main server 132 can automatically update the Yard Management web page 3500 and / or the dock watchman web page 2400 to reflect the change in the trailer's location.

[0166]

[0181] Additionally, in some examples, a user may specify a particular trailer in the yard to be taken out of service for maintenance or repair via the out of service popup 3700 shown in FIGURE 37. In some such examples, the main server 132 automatically transmits a notification to the yard jockey to take the specified trailer out of service. The main server 132 may also automatically transmit a notification (e.g., via email) to the trailer maintenance facility that the trailer has been taken out of service and needs to be repaired.

[0167]

[0182] FIG. 38 illustrates an exemplary graphical user interface corresponding to a yard status web page 3800. In some examples, the yard status web page 3800 of FIG. 38 includes information similar to that shown in the yard management web page 3500 of FIG. 35, except that the information in FIG. 38 is presented in a tabular format to enable sorting and / or filtering of the data. In some examples, the yard status web page 3800 of FIG. 38 can include additional and / or different information from the dock monitor web page 2400 of FIG. 24. For example, as shown in FIG. 38, the exemplary yard management web page 3500 of FIG. 35 can include information identifying a slot number, trailer number, yard delivery, status, scheduled reservations, load number, carrier, etc.

[0168]

[0183] FIG. 39 illustrates an exemplary graphical user interface corresponding to a Dock / Driver Logbook web page 3900. The exemplary Dock / Driver Logbook web page 3900 is a searchable repository of information regarding the loading and unloading of trailers at a dock and the associated carriers and drivers of trucks associated with such trailers. FIG. 40 illustrates an exemplary graphical user interface corresponding to a Late Charges web page 4000. The exemplary Late Charges web page 4000 of FIG. 40 is similar to the Dock / Driver Logbook web page 3900 of FIG. 39, except that the information depicted in FIG. 40 is specific to the trailer and / or dock associated with the late charge. FIG. 41 illustrates an exemplary graphical user interface corresponding to a Yard Logbook web page 4100. The exemplary yard logbook web page 4100 of Figure 41 is similar to the dock / driver logbook web page 3900 of Figure 39, except that the information depicted in Figure 41 is specific to trailers parked at a yard associated with material handling equipment 100. Figure 42 illustrates an exemplary graphical user interface corresponding to a reservation summary web page 4200. The reservation summary web page 4200 provides a summary of scheduled reservations for trailers and relevant information associated with such reservations.

[0169]

[0184] 43 illustrates an example graphical user interface presented by a loading dock statistics web page 4300 that provides various statistics regarding the efficiency and utilization of different docks within a material handling facility. For example, the example web page 4300 provides statistics regarding late fees and average loading times. In some examples, a user can manually input loading dock capacity.

[0170]

[0185] FIG. 44 illustrates an exemplary graphical user interface corresponding to a video event archive web page 4400. The exemplary video event archive web page 4400 provides a list of detected events associated with captured video segments. In the described example, the video events are listed with the most recently detected events at the top. In some examples, for recently occurring events, video may not yet be available because the post-event time interval and post-processing have not yet elapsed. However, in some such examples, the video event is nevertheless listed in the video event archive with an indication that the video segment is still being processed. After the video is processed, a thumbnail of the video is provided to display the video event. As previously mentioned, the thumbnail may be taken from a particular frame of the video segment defined by a set thumbnail offset time. In some examples, any particular video segment may be played if selected by the user. In some examples, the archived list of video segments may be filtered based on a time period, a camera, and / or a type of event. The types of events selected in the described example include video segments that captured a door opening for more than 30 seconds and video segments that captured a traffic violation.

[0171]

[0186] The use of doors (both dock doors and interior doors) within the material handling facility 100 can have a substantial impact on energy consumption, as open doors can result in the free movement of conditioned air (heated or cooled) from one area to another, creating a need for additional heat generation or cooling of air within certain designated areas. When doors are kept closed and / or opened only when needed, the movement of heat between compartmentalized areas is greatly reduced. Thus, examples disclosed herein monitor the use of doors within the material handling facility 100 to identify when doors are open too long, too frequently, when not needed, and / or used in other situations that negatively impact the energy requirements of the facility. In some examples, information corresponding to the monitored doors is provided via an energy monitoring webpage 4500 shown in FIG. 45.

[0172]

[0187] The exemplary energy monitoring webpage 4500 provides summary statistics related to door usage in the material handling facility 100. In some examples, an equipment summary block 4502 is provided that includes summary information representative of all doors in the facility. Additionally or alternatively, a product category summary block 4504 includes summary information categorized by different products or door types used in the facility. Door types can include freezer doors, refrigerator doors, clean room doors, high speed exterior doors, dock doors (e.g., dock doors 104 in FIG. 1), grade level classification doors, etc. In the illustrated example, the equipment summary block 4502 and product category summary block include energy trend indicators 4506, cycle trend indicators 4508, false start indicators 4510, door open without trailer indicators 4512, door left open indicators 4514, and cycle upset indicators 4516 (only shown in the equipment summary block 4502 in the illustrated example). Indicators 4506, 4508, 4510, 4512, 4514, 4516 in equipment summary block 4502 show values ​​corresponding to all doors monitored in material handling equipment 100. In contrast, indicators 4506, 4508, 4510, 4512, 4514 in product category summary block 4504 show corresponding values, but are limited to the particular types of doors in each represented product category.

[0173]

[0188] The example energy trend indicator 4506 shows a trend in energy usage calculated based on door usage (e.g., frequency and duration the door is opened) and the relevant energy characteristics associated with the door (e.g., temperature / humidity / pressure difference on either side of the door) in the material handling facility 100. In some examples, the trend is based on a comparison of a current period (e.g., the current month) to a previous period (e.g., last month). The particular period used to calculate the trend can be any suitable period (e.g., 3 days, 1 week, 2 weeks, 1 month, etc.). In some examples, if the trend falls below a threshold (e.g., becomes negative), the main server 132 can automatically transmit a notification to a warehouse manager, general manager, and / or other relevant personnel to alert them that a negative energy trend has been detected and that they can refer to the energy monitoring web page 4500 for additional details. Additionally or alternatively, the alert can be displayed in the energy summary block 2104 on the overview web page 2100 shown in FIG. 21.

[0174]

[0189] The exemplary cycle trend indicator 4508 shows a trend in the number of cycles (e.g., the number of times the door is opened and closed) experienced by an associated door in the material handling facility 100 over a period of time (e.g., a week, two weeks, a month) compared to a previous period of time. In some examples, if the trend exceeds a threshold, the main server 132 can automatically transmit a notification to a warehouse manager, general manager, and / or other applicable personnel to alert them that a relatively high level of activity has been detected for the door and that additional details can be found on the energy monitoring web page 4500. Additionally or alternatively, the alert can be displayed in the energy summary block 2104 on the overview web page 2100 shown in FIG. 21. In some examples, rather than displaying a trend, the cycle trend indicator 4508 can represent an absolute value of the number of cycles for one or more doors over the period of time. In some such examples, an alert and / or notification can be triggered when the number of cycles for the door(s) exceeds a certain threshold.

[0175]

[0190] The exemplary false activation indicator 4510 indicates a trend of false activations suffered by an associated door in the material handling facility 100 over a period of time (e.g., one week, two weeks, one month) compared to a previous period. As used herein, a false activation refers to a situation in which a door moves from a closed position (e.g., opens partially or fully) and later closes without any traffic passing through the door. Thus, a false activation is associated with an unnecessary door opening that may unnecessarily increase energy consumption in the material handling facility and increase the strain placed on the HVAC system to maintain a controlled temperature environment. False activation monitoring relies on a unique combination of sensors that detect the opening and closing of a door (e.g., based on feedback from a limit switch) and sensors that detect whether a person or object has passed through an open doorway (e.g., based on feedback from a photoelectric eye extending into an opening associated with the door). Thus, the feedback from this combination of sensors needs to be synchronized in time so that the detection of presence corresponds to the period during which the door is open. In some examples, if the false activation trend exceeds a threshold, the main server 132 may automatically transmit a notification to a warehouse manager, general manager, and / or other appropriate personnel to alert them that a relatively high rate of false activations has been detected for a door, and that additional details may be referenced to the energy monitoring web page 4500. Additionally or alternatively, the alert may be displayed in the energy summary block 2104 on the overview web page 2100 shown in FIG. 21. In some examples, rather than showing a trend, the false activation indicator 4510 may represent an absolute value of the number of false activations for one or more doors over the time period. In some such examples, an alert and / or notification may be triggered when the number of false activations exceeds a particular threshold.

[0176]

[0191] The exemplary door open without trailer indicator 4512 shows a trend in the number of times the dock door was opened when no trailer was present on the dock over a period of time (e.g., one week, two weeks, one month) compared to a previous period. Similar to the false activation indicator 4510, the door open without trailer indicator 4512 is generated based on a combination of sensors including a sensor monitoring the state of the door (e.g., open or closed) and a separate sensor monitoring the presence of a trailer on the dock. In some examples, if the trend exceeds a threshold, the main server 132 can automatically transmit a notification to a warehouse manager, general manager, and / or other applicable personnel to alert them that a relatively high level of activity has been detected for the door and that they can refer to the energy monitoring web page 4500 for additional details. Additionally or alternatively, the alert can be displayed in the energy summary block 2104 on the overview web page 2100 shown in FIG. 21. In some examples, rather than showing a trend, the no trailer doors open indicator 4512 may represent the number of doors and / or the absolute number of times one or more particular doors are open when no trailer is present over a period of time. In some such examples, an alarm and / or notification may be triggered when the number of doors open when no trailer is present exceeds a particular threshold.

[0177]

[0192] The exemplary doors left open indicator 4514 shows a trend in the number of doors left open for more than a threshold duration (e.g., 1 minute, 2 minutes, 5 minutes, etc.) over a period of time (e.g., 1 week, 2 weeks, 1 month) compared to a previous period of time. In some examples, if the trend exceeds a threshold, the main server 132 can automatically transmit a notification to a warehouse manager, general manager, and / or other appropriate personnel to alert them to a relatively high percentage of doors being held open. Additionally or alternatively, the alert can be displayed in the energy summary block 2104 on the overview webpage 2100 shown in FIG. 21. In some examples, rather than showing a trend, the doors left open indicator 4514 can represent an absolute value of the number of times one or more doors remain open for more than a corresponding threshold duration over the period of time. In some such examples, an alert and / or notification can be triggered when the number of doors left open that exceed a duration limit exceeds a certain threshold.

[0178]

[0193] An example cycle perturbation indicator 4516 indicates the number of times a cycle perturbation has been detected for that door over a period of time (e.g., one week, two weeks, one month). A cycle perturbation refers to a door being turned around while in the process of closing because something was detected crossing the doorway under the door's path. In the illustrated example, an absolute value of the number of cycle perturbations is provided, but in other examples, the cycle perturbation indicator 4516 may represent a trend in the number of cycle perturbations during the current period compared to a previous period.

[0179]

[0194] As discussed above, Figure 45 shows summary statistics at the equipment level (e.g., in equipment summary block 4502) and at the product category level (e.g., in product category summary block 4504). In some examples, a user may drill down to a further level to access energy related information associated with individual doors shown in the example product summary webpage 4600 of Figure 46. In such examples, similar information as discussed above may be provided, except that the information is specific to the individual door(s) selected for viewing via the energy monitoring webpage 4500.

[0180]

[0195] In some examples, a warehouse manager, general manager, and / or other personnel may wish to track or compare the impact of door usage on energy consumption after taking corrective action in response to any of the negative energy trends outlined above. Thus, in some examples, the energy monitoring webpage 4500 provides a user with the ability to set or schedule a time frame during which energy metrics will be collected and monitored, and then automatically generate an energy corrective action report at the scheduled time in the future. In some examples, after the scheduled time arrives, the main server 132 generates the report and transmits a notification to the warehouse manager, general manager, and / or other appropriate individuals to confirm that the report is ready.

[0181]

[0196] FIG. 47 illustrates an example graphical user interface presented by a safety monitoring web page 4700 that provides summary statistics of events associated with safety in and around the material handling facility 100. The example safety monitoring web page 4700 includes a loading dock trend summary 4702 and a premises trend summary 4704. The example loading dock trend summary 4702 includes a long-term trend line 4706 that represents a trend (e.g., a 12-month moving average) in the number of safety events detected at the loading dock 102 shown in FIG. 1 over a long period of time. Additionally, the example loading dock trend summary 4702 includes a short-term trend line 4708 that represents a short-term change in the number of safety events detected per period of time (e.g., per month in the illustrated example). The example loading dock trend summary 4702 also includes a goal line 4709 that represents a user-defined target for the number of safety events detected within that period of time (e.g., one month). The exemplary premises trend summary 4704 includes similar long-term and short-term trend lines 4710, 4712 representing trends in the number of safety events detected at locations within the material handling equipment 100 during corresponding periods of time, along with a corresponding goal line 4713 showing a target number of associated safety events.

[0182]

[0197] In some examples, characteristic values ​​(e.g., counts) of particular types of safety events contributing to the trend lines 4706, 4708, 4710, 4712 are also provided on the safety monitoring web page 4700 along with the corresponding loading dock trend summary 4702 and / or yard trend summary 4704. An example type of safety event associated with the loading dock 102 includes a trailer restraint failure 4714. A trailer restraint failure event may be detected when the vehicle restraint device 110 does not operate as expected. In some such examples, in addition to representing the occurrence of such a failure on the safety monitoring web page 4700, the main server 132 may also automatically transmit a notification to report to appropriate individuals that a trailer restraint failure was detected.

[0183]

[0198] Another exemplary type of safety event associated with a loading dock includes an intrusion of an unsecured trailer 4716. An unsecured trailer intrusion event can be detected when the motion sensor 204 detects movement within the trailer when the vehicle restraint 110 is not engaged with the trailer (e.g., based on feedback from the restraint sensor). In some such examples, the main server 132 automatically transmits a notification to a safety manager, a shipping and receiving manager, and / or other personnel to report an unsecured trailer intrusion at the corresponding dock. Additionally or alternatively, the main server 132 can record the detected event in an alarm or event log for later access and review. Furthermore, the main server 132 can transmit the information back to the dock controller 116 associated with the particular dock to provide a notification on the local display screen 117 that the trailer is unsafe.

[0184]

[0199] Another example type of safety event associated with a loading dock includes a dock barrier 4718 not being properly engaged. Such an event may be detected when there is no feedback from a barrier sensor (e.g., a magnetic resonance switch) indicating that an entry barrier 106 is extended at an entryway associated with an open door 104 without the presence of a trailer being detected. In some such examples, the main server 132 automatically transmits a notification to a safety manager, a shipping and receiving manager, and / or other personnel to report the improper engagement of the barrier at the corresponding dock. Additionally or alternatively, the main server 132 may record the detected event in an alarm or event log for later access and review.

[0185]

[0200] Another example type of safety event associated with a loading dock includes a dock door diversion 4720. A dock door diversion corresponds to a cycle disruption being detected at a dock door. In some such examples, the main server 132 automatically transmits a notification to appropriate personnel to report a door diversion at the corresponding dock. Additionally or alternatively, the main server 132 can record the detected event in an alert or event log for later access and review.

[0186]

[0201] Another exemplary type of safety event associated with a loading dock includes a possible trailer backout attempt 4722. Such an event may be detected when a truck driver or spotter attempts to back out a trailer from a dock when it is unsafe to do so (e.g., the dock leveller 108 is still in the active position, the door 104 is still open, the vehicle restraint device 110 is still engaged, etc.). In some such examples, the main server 132 automatically transmits a notification to a safety officer and / or other personnel to indicate a possible unsafe backout attempt at a particular dock. Additionally or alternatively, the main server 132 may record the detected event in an alarm or event log for later access and review. Furthermore, the main server 132 may transmit the information to a dock controller 116 associated with a particular dock to enable a notification on a local display screen 117 indicating that a possible backout attempt has been detected.

[0187]

[0202] Although there may be no attempt to withdraw the trailer, the trailer may nevertheless move or move relative to the dock during loading and / or unloading of the trailer. Such inadvertent movement of the trailer may be referred to as "trailer creep." In some circumstances, trailer creep may cause the trailer to be in a position such that it is not possible to release and disengage the vehicle restraint device 110 from the trailer. In some examples, a sensor may detect trailer creep, which may trigger the main server 132 to transmit a notification to a yard jockey or spotter to proceed to the corresponding dock and release the trailer (e.g., reposition the trailer so that it is free from the vehicle restraint device 110). Additionally or alternatively, the main server 132 may record the detected event in an alarm or event log for later access and review.

[0188]

[0203] Another example type of safety event associated with a loading dock includes a dangerous interlocking operation 4724. A dangerous interlocking operation can be detected when certain operations are performed in the wrong order. For example, the door 104, the dock leveller 108, and the vehicle restraint 110 can be interlocked with each other to control the order of operations. In particular, when a trailer is positioned at the dock for loading or unloading, the dock leveller 108 cannot be activated until the door 104 is opened, and the door 104 cannot be opened until the vehicle restraint 110 engages the trailer. In some examples, a reverse order of operations is performed to release the trailer from the loading dock. Thus, a dangerous interlocking operation event can be detected when operations are performed in the wrong order, or at least when operations are attempted to be performed in the wrong order. In some examples, the interlocking system configured for these components can prevent improperly sequenced operations. However, even an attempt to deviate from the correct sequence of operations can lead to safety issues, as it may indicate that a person does not understand the correct sequence. This is a major issue, especially when other docks may be configured without the interlocking components. In some examples, a hazardous linked operation may set a safety event only if the frequency of such operation exceeds a certain threshold. In some such examples, the main server 132 automatically transmits notifications to safety managers, shipping and receiving managers, and / or other personnel to report hazardous linked events (or a relatively high tendency for such) detected at a particular door. Additionally or alternatively, the main server 132 may record the detected events in an alarm or event log for later access and review. Furthermore, the main server 132 may transmit the information to the dock controller 116 associated with a particular dock to provide notifications on the local display screen 117 to remind personnel at the dock to follow a safe operating sequence.

[0189]

[0204] Another exemplary type of safety event associated with a loading dock includes leveler operation due to motion detected in the pit 402, which may indicate the presence of pedestrians in the pit. Such an event may be detected when a person attempts to lower the vertically stored dock leveler 108 when motion (presumably a person) is detected in the leveler pit 402. In some such examples, the main server 132 automatically transmits a notification to a safety manager, shipping and receiving manager, and / or other personnel to report unsafe operation of the dock leveler at the corresponding dock when a pedestrian may be in the leveler pit. Additionally or alternatively, the main server 132 may record the detected event in an alarm or event log for later access and review. Furthermore, the main server 132 may transmit the information to the dock controller 116 associated with the particular dock to provide a notification on the local display screen 117 that motion has been detected in the leveler pit.

[0190]

[0205] Another exemplary type of safety event associated with a loading dock includes a dock door opening 4728 in the absence of a trailer or barrier. Such an event may be detected when the presence of a trailer is not detected and the dock barrier 106 does not cross the threshold of an open dock door. This poses a safety issue as the door opening without a trailer could result in a dangerous fall. In some examples, upon detecting such an event, the main server 132 automatically transmits a notification to a safety manager, a shipping and receiving manager, and / or other personnel to report that a particular dock door has been opened without a trailer present. Additionally or alternatively, the main server 132 may record the detected event in an alarm or event log for later access and review. Furthermore, the main server 132 may transmit the information to a dock controller 116 associated with the particular dock to provide a notification to the local display screen 117 instructing personnel in the area to close the door or extend a barrier over the open threshold.

[0191]

[0206] Another exemplary type of safety event associated with a loading dock includes a trailer restraint override 4730. A trailer restraint override event may be detected when a person stops or overrides the operation of the vehicle restraint 110. In some examples, such activity may set a safety event only when the frequency with which the override action occurs exceeds a certain threshold. When a trailer restraint override event is detected, the main server 132 automatically transmits a notification to a safety manager, a shipping and receiving manager, and / or other personnel to report the override event (or a relatively high tendency for such activity). Additionally or alternatively, the main server 132 may record the detected event in an alert or event log for later access and review.

[0192]

[0207] Another exemplary type of safety event associated with a loading dock includes trailer restraint override when no trailer is present 4732. This event is similar to the trailer restraint override event discussed above, except that it is related to a situation where no trailer is detected at the dock. In some examples, when such an event is detected, the main server 132 automatically transmits a notification to a safety manager, a shipping and receiving manager, and / or other personnel to report that the vehicle restraint 110 is in an override state when no trailer is present. Additionally or alternatively, the main server 132 can record the detected event in an alarm or event log for later access and review. Furthermore, the main server 132 can transmit the information to a dock controller 116 associated with the particular dock to provide a notification on the local display screen 117 instructing personnel in the area to store the vehicle restraint (e.g., remove the override).

[0193]

[0208] An exemplary type of safety event associated with activity in the material handling facility 101 (e.g., contributing to the premises trend summary 4704) includes a fast door diversion 4734. A fast door diversion corresponds to a cycle disruption being detected at a fast interior door. In some examples, a fast door diversion may set a safety event only when the frequency of such occurrences exceeds a certain threshold. In some such examples, the main server 132 automatically transmits a notification to a safety manager and / or other personnel to report the door diversion (or a relatively strong tendency for such at a particular door). Additionally or alternatively, the main server 132 may record the detected event in an alarm or event log for later access and review.

[0194]

[0209] Another exemplary type of safety event associated with premises activity includes a fast door open too long 4736. Such an event may be detected when a fast door is determined to be open for longer than a threshold duration. While such an event may increase energy costs, as discussed above, a door associated with a cold storage room that is open too long may also create a safety hazard due to potential condensation and ice buildup. Thus, when a door is detected to be open too long, the main server 132 may automatically transmit a notification to a safety manager and / or other personnel to report that the door has remained open beyond the associated time limit. Additionally or alternatively, the main server 132 may record the detected event in an alarm or event log for later access and review.

[0195]

[0210] Another exemplary type of safety event associated with a premises activity includes an unauthorized door operation 4738. An unauthorized door operation may be detected when a person attempts to operate a door in a manner not permitted by the person's security credentials and / or attempts to perform an operation (e.g., change a particular parameter associated with the door) without providing the appropriate security password. In some such examples, the main server 132 automatically transmits a notification to a safety officer and / or other personnel to report the unauthorized operation of the door. Additionally or alternatively, the main server 132 may record the detected event in an alarm or event log for later access and review. Furthermore, the main server 132 may transmit the information to the door controller 122 associated with the particular door in question to render a notification on a local display screen that access to the attempted operation was denied.

[0196]

[0211] Another example type of safety event associated with premises activity includes a high volume, low speed (HVLS) fan failure 4740. Such an event may be detected when a fan does not operate as expected. In some such examples, the main server 132 automatically transmits a notification to a safety officer and / or other personnel to report the fan failure. Additionally or alternatively, the main server 132 may record the detected event in an alarm or event log for later access and review.

[0197]

[0212] Another exemplary type of safety event associated with premises activities includes unauthorized fan operation 4742. Such an event may be detected when a person attempts to operate a fan in a manner not permitted by the person's security credentials and / or attempts to perform an operation (e.g., change a particular parameter associated with the fan) without providing the appropriate security password. In some examples, the main server 132 automatically transmits a notification to a safety officer and / or other personnel to report the unauthorized operation of the fan. Additionally or alternatively, the main server 132 may record the detected event in an alarm or event log for later access and review. Furthermore, the main server 132 may transmit the information to the fan controller 126 associated with the particular fan in question to render a notification on a local display screen that access to the attempted operation was denied.

[0198]

[0213] Another example type of safety event associated with premises activity includes a high velocity door impact 4744. A high velocity door impact may be detected when a door sensor detects that an object has hit a door. In some examples, the main server 132 automatically transmits a notification to a safety officer and / or other personnel to report the door hit. Additionally or alternatively, the main server 132 may record the detected event in an alert or event log for later access and review.

[0199]

[0214] In some examples, a user can drill down and access further information by selecting loading dock trend summary 4702 or yard trend summary 4704. For example, selecting loading dock trend summary 4702 in Figure 7 can access detailed loading dock web trends page 4800, as shown in Figure 48. Similarly, selecting yard trend summary 4704 in Figure 7 can access detailed yard trends web page 4900, as shown in Figure 49.

[0200]

[0215] FIG. 50 illustrates another exemplary graphical user interface presented by a safety monitoring web page 5000 that provides summary statistics of events associated with safety in and around the material handling facility 100. As shown in the illustrated example, the safety monitoring web page 5000 includes a loading dock trend summary 5002 and a yard trend summary 5004 similar to the loading dock trend summary 4702 and yard trend summary 4704 of FIG. 47. Additionally, the safety monitoring web page 5000 includes a traffic trend summary 5006 that provides summary statistics of utilization and congestion of different intersections within the material handling facility 100. The congestion statistics represent events where two personnel / equipment (persons on foot or in a vehicle (e.g., a forklift), or equipment operating autonomously) approach the same intersection from different directions at substantially the same time.

[0201]

[0216] In addition to or instead of the traffic trend summary 5006 shown in FIG. 50, the safety monitoring web page 5000 can include a traffic trend summary 5100 shown in FIG. 51. The traffic trend summary 5100 provides trend statistics regarding traffic congestion or volume at one or more intersections in the material handling facility 100 that are being monitored by the traffic sensors. Additionally, the traffic trend summary 5100 provides trend statistics corresponding to collision risk at one or more intersections. The collision risk is determined based on the number and / or frequency of traffic approaching a single intersection from at least two different directions simultaneously. In some examples, if the collision risk trend for a particular intersection exceeds a threshold, the main server 132 automatically transmits a notification to safety managers and / or other personnel to indicate that the intersection presents a relatively high risk for collisions.

[0202]

[0217] Additional details regarding the analysis of traffic within the material handling facility 100 can be accessed via an example traffic analysis webpage 5200 shown in FIG. 52. As shown in the illustrated example, an intersection traffic graphic 5202 is provided that represents both the volume of traffic passing through the intersection from each direction over a user-specified time period for a particular intersection monitored within the material handling facility 100. In the illustrated example, the collision risk or congestion for each direction is calculated as the percentage of all traffic from the corresponding direction that approached the intersection at substantially the same time as traffic that was approaching from at least one other direction. Additionally, a directional intersection graphic 5204 can be provided to summarize the sources of oncoming traffic that create collision risk based on the traffic approaching from each direction.

[0203]

[0218] In some examples, the traffic analysis web page 5200 includes a traffic volume heat map 5206 that represents the relative traffic volume (e.g., traffic volume) and / or relative congestion (shown in the example web page 5300 of FIG. 53) at a corresponding intersection at different times of day (horizontal axis) and different days of the week (vertical axis) over a specified time period. In the example illustrated in FIG. 52, the heat map 5206 represents all traffic detected at a particular intersection. In some examples, a user can toggle between graphics showing total traffic volume or congestion from all directions detected at a particular intersection (shown in FIG. 52) and graphics showing traffic volume or congestion based on a particular approach direction associated with the intersection (shown in FIG. 54). In some examples, collision risk graphics can be provided for traffic approaching a selected intersection from a particular direction. Thus, as shown in FIG. 54, the traffic analysis web page 5200 can provide a directional heat map 5402 that represents the collision risk associated with traffic specific to a particular direction selected by the user (e.g., northbound in the illustrated example). More specifically, in the illustrated example, the directional heatmap 5402 is selected to represent the collision risk between northbound traffic and traffic approaching the intersection from another particular direction (e.g., south, as indicated by checkmark 5404 in FIG. 54). The collision risk between the selected direction (e.g., north) and one of the other directions (e.g., east or west) can be represented in the heatmap 5402 by selecting the corresponding analysis icon 5406. Additionally, the directional heatmap 5402 can show the collision risk from the north direction against all of the other directions by selecting the all-direction icon 5408. Thus, four separate heatmaps 5402 can be represented for the collision risk associated with traffic approaching the corresponding intersection from the north direction. Similar heatmaps can also be generated for any other selected directions.These various heat maps enable safety managers to identify potential trends and / or high-risk traffic flows associated with particular directions and / or at particular times to determine whether particular personnel require additional training and / or traffic routes need to be rerouted to reduce congestion and collision risk.

[0204]

[0219] In some examples, safety managers and / or other personnel may wish to track or compare trends in safety events and / or traffic patterns and crash risks after taking corrective action in response to a potentially hazardous condition being detected as outlined above. Thus, in some examples, the safety monitoring webpage 4700 provides users with the ability to set or schedule a time frame during which safety metrics will be collected and monitored, and then automatically generate a safety corrective action report at the scheduled time in the future. In some examples, after the scheduled time arrives, the main server 132 generates the report and transmits a notification to the safety manager and / or other appropriate individuals to confirm that the report is ready.

[0205]

[0220] FIG. 55 illustrates an exemplary graphical user interface corresponding to a traffic signal analysis web page 5500 that provides an analysis of traffic events occurring at a particular intersection in the material handling facility 100. In some examples, the traffic events are detected based on signals provided from traffic sensors operated by a corresponding traffic controller 130. As previously described, when a traffic intersection (e.g., traffic from two directions approaching a single intersection at the same time) is detected, the traffic controller 130 can display a traffic signal to an individual corresponding to the detected traffic. In some examples, the traffic signal is a blue light. Thus, as shown in the example illustrated in FIG. 55, the number and / or frequency of blue lights (i.e., detected traffic intersections) for a represented intersection are displayed over a period of time. In some examples, this data is provided in comparison to other intersections and / or traffic at the same intersection but for different periods of time. In this manner, a user can assess reoccurring problems at the intersection.

[0206]

[0221] 56 illustrates an example graphical user interface corresponding to an entire facility traffic webpage 5600 that provides a map 5602 depicting routes and intersections throughout the material handling facility 100. In some examples, the map 5602 includes indicators at each intersection that identify how frequently traffic passes through the intersection and / or how frequently intersecting traffic events are detected at each intersection. This can facilitate a person identifying locations of bottlenecks and / or overly congested intersections to potentially identify whether different travel routes and / or traffic patterns can be constructed to improve the flow of material handling equipment.

[0207]

[0222] FIG. 57 illustrates an example graphical user interface presented by an asset management webpage 5700 that provides summary statistics corresponding to assets in the material handling facility 100. As shown in the illustrated example, the asset management webpage 5700 includes a maintenance planned indicator 5702 to indicate the number of scheduled maintenance events planned for the asset. In some examples, a user can select a calendar button to schedule additional maintenance events. In some examples, when maintenance is scheduled to occur within a threshold period (e.g., 30 days), the main server 132 automatically generates and transmits a notification reminder that scheduled maintenance is approaching for the asset so that a maintenance manager and / or other personnel can contact the asset's manufacturer to schedule the maintenance.

[0208]

[0223] In the illustrated example, the asset management webpage 5700 includes a list of faults detected for a particular asset 5704, as well as a list of assets that are out of service 5706. In some examples, when an asset is taken out of service, the main server 132 transmits a notification to an appropriate individual to report that the corresponding asset is out of service. Additionally, the main server 132 can transmit the status of the door to a controller associated with the particular asset and display a notification on a local display screen that the asset is out of service.

[0209]

[0224] Additionally, in some examples, the asset management webpage 5700 includes an asset age summary 5708 that identifies and tracks the age (e.g., from manufacture and / or installation date) of all assets. In some examples, the asset age summary 5708 can be categorized into different considerations including, for example, installation date or number of cycles or usage monitored by sensors associated with the asset. In some examples, a user can schedule the generation of an asset age report so that the main server 132 transmits a notification that the asset age report is ready to be reviewed at a particular time in the future. This can be useful as a reminder to review the life cycle of assets before planning a budget for future maintenance costs in the material handling facility 100. FIG. 58 illustrates another example asset management webpage 5800.

[0210]

[0225] FIG. 59 illustrates an asset management webpage 5900 showing an asset profile 5902 for a particular asset in the material handling facility 100. In this example, the particular asset is a high speed door. In some examples, the asset profile 5902 includes an image 5904 of the asset. The image can be a generic image for the asset or a photo of the actual product installed in the facility 100. The asset profile 5902 provides equipment details specific to the particular asset being represented, such as, for example, the name of the asset, the type of asset, the manufacturer of the asset, and the installation date. Additionally, in some examples, the asset profile 5902 includes statistics regarding the operation and / or use of the asset. For example, in the illustrated example, the asset profile 5902 includes an indication of the number of cycles the door has undergone since installation, the number of faults detected for the door, and the number of false activations. In some examples, these statistics can be represented over a period of time (e.g., providing an indication of the number of cycles from a month (or other period of interest) for different months). In some examples, the asset profile 5902 can provide real-time updates of parameter values ​​corresponding to sensors associated with the asset.

[0211]

[0226] As mentioned above, although the exemplary graphical user interfaces illustrated in Figures 21-59 have been described in the context of web pages, any of the graphical user interfaces disclosed herein may also be implemented by non-web based applications independent of the Internet and / or web pages.

[0212]

[0227] Figure 60 is a block diagram of an exemplary processor platform 6000 configured to execute the instructions of Figures 12-20 to implement the main server 132 of Figures 1, 6, and / or 10. The processor platform 6000 can be, for example, a server, a personal computer, a workstation, a self-learning machine (e.g., neural networks), or any other type of computing device.

[0213]

[0228] The processor platform 6000 of the illustrated example includes a processor 6012. The processor 6012 of the illustrated example is hardware. For example, the processor 6012 can be implemented by one or more integrated circuits, logic circuits, microprocessors, GPUs, DSPs, or controllers from any desired family or manufacturer. The hardware processor can be a semiconductor-based (e.g., silicon-based) device. In this example, the processor implements an example web server 146, an example network communication interface 602, an example IO network interface 604, an example restart watchdog 606, an example pull service manager 610, an example push service manager 612, an example video management system 614, and an example event manager 616.

[0214]

[0229] The processor 6012 of the illustrated example includes a local memory 6013 (e.g., a cache). The processor 6012 of the illustrated example communicates with a main memory, including a volatile memory 6014 and a non-volatile memory 6016, via a bus 6018. The volatile memory 6014 can be implemented by Synchronous Dynamic Random Access Memory (SDRAM), Dynamic Random Access Memory (DRAM), RAMBUS®, Dynamic Random Access Memory (RDRAM®), and / or any other type of random access memory device. The non-volatile memory 6016 can be implemented by flash memory and / or any other desired type of memory device. Access to the main memory 6014, 6016 is controlled by a memory controller.

[0215]

[0230] The processor platform 6000 of the illustrated example also includes an interface circuit 6020. The interface circuit 6020 can be implemented with any type of interface standard, such as an Ethernet interface, a Universal Serial Bus (USB), a Bluetooth interface, a Near Field Communication (NFC) interface, and / or a PCI Express interface.

[0216]

[0231] In the illustrated example, one or more input devices 6022 are connected to the interface circuit 6020. The input device(s) 6022 allow a user to input data and / or commands to the processor 6012. The input device(s) may be implemented by, for example, an audio sensor, a microphone, a camera (still or video), a keyboard, buttons, a mouse, a touch screen, a trackpad, a trackball, an isopoint, and / or a voice recognition system.

[0217]

[0232] One or more output devices 6024 are also connected to the interface circuitry 6020 of the described example. The output device(s) 6024 may be implemented by, for example, a display device (e.g., a light emitting diode (LED), an organic light emitting diode (OLED), a liquid crystal display (LCD), a cathode ray tube display (CRT), an in-place switching (IPS) display, a touch screen, etc.), a tactile output device, a printer, and / or a speaker. Thus, the interface circuitry 6020 of the described example typically includes a graphics driver card, a graphics driver chip, and / or a graphics driver processor.

[0218]

[0233] The interface circuitry 6020 of the illustrated example also includes communications devices such as transmitters, receivers, transceivers, modems, residential gateways, wireless access points, and / or network interfaces to facilitate the exchange of data with external machines (e.g., any type of computing device) over the network 6026. Communications may occur, for example, via an Ethernet connection, a Digital Subscriber Line (DSL) connection, a telephone line connection, a coaxial cable system, a satellite system, a line-of-sight wireless system, a cellular phone system, etc.

[0219]

[0234] The processor platform 6000 of the illustrated example also includes one or more mass storage devices 6028 for storing software and / or data. In this example, the mass storage device 6028 implements the example database 608 of the example main server 132. Examples of such mass storage devices 6028 include floppy disk drives, hard drive disks, compact disk drives, Blu-ray disk drives, redundant array of independent disks (RAID) systems, USB memory sticks, solid state disk drives, and digital versatile disk (DVD) drives.

[0220]

[0235] The machine-executable instructions 6032 of Figures 12-20 may be stored on the mass storage device 6028, the volatile memory 6014, the non-volatile memory 6016, and / or a removable non-transitory computer-readable storage medium such as a CD or DVD.

[0221]

[0236] Fig. 61 is a block diagram of an exemplary processor platform 6100 configured to execute the instructions of Fig. 16-20 to implement the local controller 1100 of Fig. 11 (representing any one of the controllers 116, 122, 124, 126, 128, 130 of Fig. 1). The processor platform 6100 can be, for example, a server, a personal computer, a workstation, a self-learning machine (e.g., neural network), or any other type of computing device.

[0222]

[0237] The processor platform 6100 of the illustrated example includes a processor 6112. The processor 6112 of the illustrated example is hardware. For example, the processor 6112 can be implemented by one or more integrated circuits, logic circuits, microprocessors, GPUs, DSPs, or controllers from any desired family or manufacturer. The hardware processor can be a semiconductor-based (e.g., silicon-based) device. In this example, the processor implements an example data analyzer 1104, an example event analyzer 1106, an example parameter value converter 1108, an example notification engine 1110, an example display 1114, and an example device controller 1116.

[0223]

[0238] The processor 6112 of the illustrated example includes a local memory 6113 (e.g., a cache). The processor 6112 of the illustrated example communicates with a main memory, including a volatile memory 6114 and a non-volatile memory 6116, via a bus 6118. The volatile memory 6114 can be implemented by synchronous dynamic random access memory (SDRAM), dynamic random access memory (DRAM), Rambus, dynamic random access memory (RDRAM), and / or any other type of random access memory device. The non-volatile memory 6116 can be implemented by flash memory and / or any other desired type of memory device. Access to the main memory 6114, 6116 is controlled by a memory controller.

[0224]

[0239] The processor platform 6100 of the illustrated example also includes an interface circuit 6120. The interface circuit 6120 can be implemented with any type of interface standard, such as an Ethernet interface, a Universal Serial Bus (USB), a Bluetooth interface, a Near Field Communication (NFC) interface, and / or a PCI Express interface.

[0225]

[0240] In the illustrated example, one or more input devices 6122 are connected to the interface circuit 6120. The input device(s) 6122 allow a user to input data and / or commands to the processor 6112. The input device(s) may be implemented by, for example, an audio sensor, a microphone, a camera (still or video), a keyboard, buttons, a mouse, a touch screen, a trackpad, a trackball, an isopoint, and / or a voice recognition system.

[0226]

[0241] One or more output devices 6124 are also connected to the interface circuitry 6120 of the described example. The output device(s) 6124 may be implemented by, for example, a display device (e.g., a light emitting diode (LED), an organic light emitting diode (OLED), a liquid crystal display (LCD), a cathode ray tube display (CRT), an in-place switching (IPS) display, a touch screen, etc.), a tactile output device, a printer, and / or a speaker. Thus, the interface circuitry 6120 of the described example typically includes a graphics driver card, a graphics driver chip, and / or a graphics driver processor.

[0227]

[0242] The interface circuitry 6120 of the illustrated example also includes communications devices such as transmitters, receivers, transceivers, modems, residential gateways, wireless access points, and / or network interfaces to facilitate the exchange of data with external machines (e.g., any type of computing device) over the network 6126. Communications may occur, for example, via an Ethernet connection, a Digital Subscriber Line (DSL) connection, a telephone line connection, a coaxial cable system, a satellite system, a line-of-sight wireless system, a cellular phone system, etc. In this example, the interface circuitry 6120 implements an exemplary communications interface 1102.

[0228]

[0243] The processor platform 6100 of the illustrated example also includes one or more mass storage devices 6128 for storing software and / or data. Examples of such mass storage devices 6128 include floppy disk drives, hard drive disks, compact disk drives, Blu-ray disk drives, Redundant Array of Independent Disks (RAID) systems, and Digital Versatile Disk (DVD) drives. In this example, the mass storage 6128 implements the example database 1112.

[0229]

[0244] The machine-executable instructions 6132 of Figures 16-20 may be stored on the mass storage device 6128, the volatile memory 6114, the non-volatile memory 6116, and / or a removable non-transitory computer-readable storage medium such as a CD or DVD.

[0230]

[0245] From the above, it will be appreciated that exemplary methods, apparatus, and products are disclosed that enable aggregation and integration of data from disparate controllers, sensors, and the like in a material handling facility for subsequent analysis for generating notifications and / or providing outputs via a web page (or other application) interface that is updated substantially in real time. Examples disclosed herein improve the efficiency of using electronic devices to monitor material handling facilities by gathering disparate information in an integrated manner, thereby avoiding redundancy from monitoring multiple isolated systems. Furthermore, the combination of information gathered from different sources allows a user to access and / or become aware of certain conditions that were not previously possible to detect automatically, such as, for example, a false door activation. Notifications of such conditions can be generated based on events triggered by a combination of parameters reported from different controllers that meet certain configurable conditions. In some examples, such events can trigger the generation of a video segment that captures the occurrence of the event on a camera, and such video segment can be included in the notification as an attachment. Furthermore, in some examples, the video segment can be subjected to video analytics to detect additional safety events and / or people in the video, potentially identifying the cause of the originally triggered event. Notification of otherwise unknowable events also contributes to improved efficient use and operation of the control systems within material handling equipment that generate the data that allows the event to be detected in the first place. For example, informing relevant personnel (e.g., safety managers) of a potential safety risk allows them to take corrective action to reduce or eliminate the risk (e.g., quickly reversing the effects of hazardous behavior, implementing additional and / or different equipment, restructuring processes and / or procedures that create the risk, providing additional training to personnel, etc.). Furthermore, while isolated safety events can be detected and treated quickly, some safety events are based on the repeated occurrence of certain conditions (e.g., exceeding a certain threshold) over a period of time, which cannot be detected directly due to a time component.However, in accordance with the teachings disclosed herein, by tracking conditions over time, such trend-based events can be detected. After such events are detected and appropriate personnel become aware of the undesirable trend, the personnel can then implement appropriate actions to resolve or reduce the impact of the factors contributing to the undesirable trend. Furthermore, notification of detected events can also significantly reduce unnecessary energy consumption within the material handling facility by enabling appropriate personnel (e.g., a general manager) to identify conditions and / or trends that result in energy loss (e.g., doors opening too frequently and / or too long to allow conditioned air to escape). Based on such notification, personnel can then take appropriate actions to reduce the conditions and / or behaviors that result in the energy waste. This not only saves costs, but also reduces the strain on the heating and / or cooling systems used to provide the conditioned air environment. In some examples, the interface presenting the collected data can be updated in substantially real-time based on push request subscriptions. In some such examples, updates can include user-entered data provided to one web page, and such data is pushed to different web pages based on subscriptions to such data by the different web pages.

[0231]

[0246] Exemplary methods, apparatus, systems, and articles of manufacture for monitoring and managing loading dock and facility operations are disclosed herein. Further examples and combinations thereof include the following:

[0232]

[0247] Example 1 includes an apparatus for monitoring operations at a material handling facility, the apparatus comprising: a data analyzer that monitors first data indicative of whether a truck trailer is present at a dock of the material handling facility and monitors second data, different from the first data, indicative of a condition associated with equipment at the dock; and a notification generator that generates a notification based on the first data and the second data.

[0233]

[0248] Example 2 includes the apparatus of Example 1, where the first data is generated by a first data source and the second data is generated by a second data source, the first data source is different from the second data source, the first data source corresponds to at least one of a first sensor at the dock, a vehicle restraint device at the dock, a leveler at the dock, a light indicator, or a database for a dock management system associated with the material handling equipment, and the second data source corresponds to at least one of a second sensor at the dock different from the first sensor, a vehicle restraint device, a leveler, a light indicator, or a database.

[0234]

[0249] Example 3 includes the apparatus of example 2, where the second data source corresponds to a second sensor, the second sensor monitors operation of the door, and the condition corresponds to whether the door is in an unclosed state, and the notification generator generates a notification when the first data indicates that the trailer is not present at the dock and the second data indicates that the door is in an unclosed state, the notification indicating a fall hazard associated with the door.

[0235]

[0250] Example 4 includes the device of example 3, where the data analyzer monitors third data indicative of whether a barrier distinct from the door is preventing passage through a doorway associated with the door in an unclosed state, and the device further includes an event analyzer that suppresses generation of a notification when the third data indicates that the barrier is preventing passage through the doorway.

[0236]

[0251] Example 5 includes the device of example 2, where the second data source corresponds to a light indicator, the light indicator switching between a first state when the vehicle restraint is in an engaged position and a second state when the vehicle restraint is in a stowed position, the vehicle restraint engages a trailer at the dock when the vehicle restraint is in the engaged position, the light indicator switching to the first state when the vehicle restraint is placed in an override mode regardless of whether the vehicle is in the engaged position or the stowed position, and the notification generator generates a notification in response to (1) the first data indicating that a trailer is not at the dock and (2) the second data indicating that the light indicator is in the first state associated with the vehicle restraint being in the override mode, the notification indicating that the trailer has been removed from the dock when the light indicator was in the first state.

[0237]

[0252] Example 6 includes the apparatus of example 2, where the second data source corresponds to a database, the database storing dock management data indicating assignment of different trailers to different docks of the material handling equipment, and the notification generator generates a notification in response to the first data indicating that the trailer is present at the dock when the second data indicates that the trailer is not assigned to the dock, the notification indicating that the trailer is at the wrong dock.

[0238]

[0253] Example 7 includes the apparatus of example 2, where the second data source corresponds to a second sensor, the second sensor monitors activity within a trailer at the dock, the condition corresponds to a duration of no activity sensed within the trailer, and the notification generator generates the notification in response to the duration exceeding a threshold.

[0239]

[0254] Example 8 includes the apparatus of Example 2, where the data analyzer monitors third data indicative of user activation of a manually initiated actuator enabling operation of a first device associated with the dock, the second data source corresponds to a second sensor, the second sensor monitors a state of a second device in an interlocking relationship with the operation of the first device, the condition corresponds to whether the state of the second device prevents operation of the first device based on the interlocking relationship, and the notification generator generates the notification in response to the user activation when the second data indicates that the state of the second device prevents operation of the first device.

[0240]

[0255] Example 9 includes the device of example 1, where the notification generator renders information associated with the notification on a screen located proximate the dock.

[0241]

[0256] Example 10 includes the apparatus of example 1, where the notification generator renders information associated with the notification in a web page accessed by the undocked device.

[0242]

[0257] Example 11 includes the apparatus of example 1, further including an event logger that logs an event in a database, the event being associated with content of the notification.

[0243]

[0258] Example 12 includes an apparatus for monitoring operations in materials handling equipment, the apparatus comprising: a data analyzer that monitors first data indicating a door associated with the materials handling equipment is in an unclosed state and that monitors second data indicative of a passage of at least one person or object through a doorway associated with the door in the unclosed state; and a notification generator that generates a notification in response to the second data indicating a lack of passage of at least one person or object through the doorway during a time duration during which the first data indicates the door is in the unclosed state, the notification indicating a false activation of the door.

[0244]

[0259] Example 13 includes an apparatus for monitoring operations at a material handling facility, the apparatus comprising: a database that aggregates dock data associated with a plurality of docks of the material handling facility, the database including: (1) an indication of equipment operational status associated with the plurality of docks; (2) an indication of personnel activity in the vicinity of the plurality of docks based on feedback from sensors associated with the plurality of docks; and (3) load information associated with a trailer that is at least one of loaded or unloaded at one of the plurality of docks; and a notification generator that renders a plurality of dock icons corresponding to the plurality of docks and, in response to a user selecting a first dock icon of the plurality of dock icons, renders a menu of options for a user to select, the options presented in the menu being dynamically updated based on the dock data.

[0245]

[0260] Example 14 includes the apparatus of Example 13, where the notification generator, in response to the dock data indicating a first trailer is present at a first dock of the plurality of docks, draws a trailer icon having a shape representing a truck trailer adjacent to a first dock icon of the plurality of dock icons that corresponds to the first dock, and updates options presented in the menu to include a first option for accessing cargo information associated with the first trailer.

[0246]

[0261] Example 15 includes the apparatus of example 14, where the notification generator dynamically updates a timing indicator within the trailer icon, the timing indicator indicating a duration that the first trailer is located in the first dock.

[0247]

[0262] Example 16 includes the apparatus of example 15, where the timing indicator includes a timer value corresponding to the duration.

[0248]

[0263] Example 17 includes the device of example 15, where the timing indicator includes a progress bar corresponding to a first portion of the trailer icon rendered in a different color than a second portion of the trailer icon, the first portion increasing in size in proportion to its duration.

[0249]

[0264] Example 18 includes the apparatus of example 17, where the first portion corresponds to an entirety of the trailer icon when the duration exceeds a threshold period corresponding to a late fee period.

[0250]

[0265] Example 19 includes the apparatus of example 14, where the notification generator renders a reservation time indicator within the trailer icon, the reservation time indicator indicating a time of a scheduled reservation for the first trailer.

[0251]

[0266] Example 20 includes the apparatus of example 19, where the notification generator renders an appointment countdown within the trailer icon, the appointment countdown indicating time remaining until the scheduled appointment.

[0252]

[0267] Example 21 includes the apparatus of example 14, where the notification generator renders a loading status indicator adjacent to the trailer icon, the loading status indicator indicating a progress status of moving the cargo into or out of the first trailer, the progress status corresponding to at least one of not yet started, waiting on the cargo, partially completed, or completed.

[0253]

[0268] Example 22 includes the apparatus of example 14, wherein the notification generator, in response to the dock data indicating the first trailer is associated with an actual load, draws a tractor unit icon adjacent to the trailer icon to illustrate that the tractor unit is coupled to the first trailer, and, in response to the dock data indicating the first trailer is associated with a delivered load, draws a delivery status indicator adjacent to the trailer icon, the delivery status indicator indicating whether the first trailer should be moved to a trailer yard or should remain at the first dock.

[0254]

[0269] Example 23 includes the apparatus of example 22, wherein the notification generator modifies an appearance of at least one of the trailer icon or the tractor unit icon when the load information indicates that the first trailer is temperature controlled.

[0255]

[0270] Example 24 includes the apparatus of example 14, wherein the notification generator renders a reciprocal dock status indicator adjacent to the trailer icon, the reciprocal dock status indicator indicating at least one of: (1) cargo in a first trailer should be moved to a different trailer, or (2) cargo in a different trailer should be moved to the first trailer.

[0256]

[0271] Example 25 includes the apparatus of example 14, where the notification generator renders a load direction indicator adjacent to the trailer icon, the load direction indicator indicating whether the first trailer is associated with an incoming load from which cargo on the first trailer is to be unloaded or an outgoing load from which cargo is to be loaded onto the first trailer.

[0257]

[0272] Example 26 includes the apparatus of example 14, where the notification generator renders a priority indicator adjacent to the trailer icon, the priority indicator indicating a priority of the first trailer.

[0258]

[0273] Example 27 includes the device of example 26, wherein the priority indicator toggles between a first appearance indicating a first priority and a second appearance indicating a second priority greater than the first priority.

[0259]

[0274] Example 28 includes the apparatus of example 24, wherein the notification generator, in response to the dock data indicating the first trailer is associated with an incoming load, renders a load counter within the trailer icon, the load counter indicating a total number of cargo units to be moved out of the first trailer.

[0260]

[0275] Example 29 includes the apparatus of Example 28, further including an event analyzer that determines a remaining number of cargo units to be removed from the first trailer based on activity detected within the trailer, and the notification generator dynamically updates a load counter to indicate the remaining number of cargo units to be moved out of the first trailer, the remaining number being plotted along with the total number.

[0261]

[0276] Example 30 includes the apparatus of example 24, wherein the notification generator renders at least one of a carrier code or a trailer number adjacent to the trailer icon.

[0262]

[0277] Example 31 includes the apparatus of Example 13, where the notification generator draws a plurality of restraint signal icons adjacent to corresponding dock icons of the plurality of dock icons, the plurality of restraint signal icons representing states of corresponding vehicle restraint devices at corresponding docks of the plurality of docks, the states of the vehicle restraint devices including a first state in which the vehicle restraint device is engaged with the trailer at the corresponding docks of the docks and a second state in which the vehicle restraint device is in a stowed position, and dynamically switches the plurality of restraint signal icons between displaying a red light and a green light based on the states of the corresponding vehicle restraint devices, the red light indicating the first state and the green light indicating the second state.

[0263]

[0278] Example 32 includes the apparatus of example 13, wherein the notification generator dynamically switches the plurality of dock icons to represent a change in a state of a corresponding one of the plurality of docks based on the dock data.

[0264]

[0279] Example 33 includes a non-transitory computer-readable medium including instructions that, when executed, cause a processor to at least monitor first data indicative of whether a truck trailer is present at a dock of a material handling facility, monitor second data different from the first data indicative of a condition associated with the equipment at the dock, and generate a notification based on the first data and the second data.

[0265]

[0280] Example 34 includes the non-transitory computer-readable medium of Example 33, where the first data is generated by a first data source and the second data is generated by a second data source, the first data source is different from the second data source, the first data source corresponds to at least one of a first sensor at the dock, a vehicle restraint device at the dock, a leveler at the dock, a light indicator, or a database for a dock management system associated with the material handling equipment, and the second data source corresponds to at least one of a second sensor at the dock different from the first sensor, a vehicle restraint device, a leveler, a light indicator, or a database.

[0266]

[0281] Example 35 includes the non-transitory computer-readable medium of Example 34, where the second data source corresponds to a second sensor, the second sensor monitoring operation of the door, and the condition corresponds to whether the door is in an unclosed state, and the instructions further cause the processor to generate a notification when the first data indicates that the trailer is not present at the dock and the second data indicates that the door is in an unclosed state, the notification indicating a fall hazard associated with the door.

[0267]

[0282] Example 36 includes the non-transitory computer-readable medium of Example 35, where the instructions further cause the processor to monitor third data indicative of whether a barrier distinct from the door is preventing passage through a doorway associated with the door in an unclosed state, and to suppress generating the notification when the third data indicates that the barrier is preventing passage through the doorway.

[0268]

[0283] Example 37 includes the non-transitory computer-readable medium of Example 34, where the second data source corresponds to a light indicator, the light indicator switching between a first state when the vehicle restraint is in an engaged position and a second state when the vehicle restraint is in a stowed position, the vehicle restraint engages a trailer that is docked when the vehicle restraint is in the engaged position, and the light indicator switching to the first state when the vehicle restraint is placed in an override mode regardless of whether the vehicle is in the engaged position or the stowed position, the instructions further cause the processor to generate a notification in response to (1) the first data indicating that a trailer is not present at the dock and (2) the second data indicating that the light indicator is in the first state associated with the vehicle restraint being in the override mode, the notification indicating that the trailer has been removed from the dock when the light indicator was in the first state.

[0269]

[0284] Example 38 includes the non-transitory computer-readable medium of Example 34, where the second data source corresponds to a database, the database storing dock management data indicating assignment of different trailers to different docks of the material handling equipment, and the instructions further cause the processor to generate a notification in response to the first data indicating that the trailer is present at the dock and the second data indicating that the trailer is not assigned to the dock, the notification indicating that the trailer is at the wrong dock.

[0270]

[0285] Example 39 includes the non-transitory computer-readable medium of Example 34, where the second data source corresponds to a second sensor, the second sensor monitoring activity within a trailer at the dock, and the condition corresponds to a duration of no activity sensed within the trailer, and the instructions further cause the processor to generate a notification in response to the duration exceeding a threshold.

[0271]

[0286] Example 40 includes the non-transitory computer-readable medium of Example 34, where the instructions further cause the processor to monitor third data indicative of user activation of a manually initiated actuator enabling operation of a first device associated with the dock, the second data source corresponding to a second sensor, the second sensor monitoring a state of a second device in an interlocking relationship with the operation of the first device, the condition corresponding to whether the state of the second device prevents operation of the first device based on the interlocking relationship, and the instructions further cause the processor to generate a notification in response to the user activation when the second data indicates that the state of the second device prevents operation of the first device.

[0272]

[0287] Example 41 includes the non-transitory computer-readable medium of example 33, where generating the notification includes rendering information associated with the notification on a screen located near the door.

[0273]

[0288] Example 42 includes the non-transitory computer-readable medium of example 33, where generating the notification includes rendering information associated with the notification on a web page accessed by a device away from the door.

[0274]

[0289] Example 43 includes a non-transitory computer-readable medium including instructions that, when executed, cause a process to at least monitor first data indicating a door associated with material handling equipment is in an unclosed state, monitor second data indicative of a passage of at least one person or object through a doorway associated with the door in an unclosed state, and generate a notification in response to the first data indicating the door is in an unclosed state and the second data indicating a lack of passage of at least one person or object through the doorway, the notification indicating a false activation of the door.

[0275]

[0290] Example 44 includes a non-transitory computer-readable medium including instructions that, when executed, cause a process to aggregate dock data associated with a plurality of docks of a material handling facility, including at least: (1) indications of operational status of equipment associated with the plurality of docks; (2) indications of personnel activities in the vicinity of the plurality of docks based on feedback from sensors associated with the plurality of docks; and (3) load information associated with a trailer that is at least one of loaded or unloaded at one of the plurality of docks; render a plurality of dock icons corresponding to the plurality of docks; and, in response to a user selecting a first dock icon of the plurality of dock icons, render a menu of options for a user to select, wherein the options presented in the menu are dynamically updated based on the dock data.

[0276]

[0291] Example 45 includes the non-transitory computer-readable medium of Example 44, where the instructions further cause the processor, in response to the dock data indicating a first trailer is present in a first dock of the plurality of docks, to draw a trailer icon having a shape representing a truck trailer adjacent to a first dock icon of the plurality of dock icons that corresponds to the first dock, and update the options presented in the menu to include a first option for accessing cargo information associated with the first trailer.

[0277]

[0292] Example 46 includes the non-transitory computer-readable medium of Example 45, where the instructions further cause the processor to dynamically update a timing indicator within the trailer icon, the timing indicator indicating a duration that the first trailer is located in the first dock.

[0278]

[0293] Example 47 includes the non-transitory computer-readable medium of example 46, where the timing indicator includes a timer value corresponding to the duration.

[0279]

[0294] Example 48 includes the non-transitory computer-readable medium of example 46, where the timing indicator includes a progress bar corresponding to a first portion of the trailer icon rendered in a different color than a second portion of the trailer icon, the first portion increasing in size proportional to the duration.

[0280]

[0295] Example 49 includes the non-transitory computer-readable medium of example 48, where the first portion corresponds to an entirety of the trailer icon when the duration exceeds a threshold period corresponding to a late fee period.

[0281]

[0296] Example 50 includes the non-transitory computer-readable medium of example 45, where the instructions further cause the processor to render a reservation time indicator within the trailer icon, the reservation time indicator indicating a time of the scheduled reservation for the first trailer.

[0282]

[0297] Example 51 includes the non-transitory computer-readable medium of example 50, where the instructions further cause the processor to render a reservation countdown within the trailer icon, the reservation countdown indicating time remaining until a scheduled reservation.

[0283]

[0298] Example 52 includes the non-transitory computer-readable medium of example 45, where the instructions further cause the processor to render a loading status indicator adjacent to the trailer icon, the loading status indicator indicating a progress status of moving the cargo into or out of the first trailer, the progress status corresponding to at least one of not yet started, waiting on the cargo, partially completed, or completed.

[0284]

[0299] Example 53 includes the non-transitory computer-readable medium of Example 45, where the instructions further cause the processor, in response to the dock data indicating the first trailer is associated with an actual load, to draw a tractor unit icon adjacent to the trailer icon to illustrate that the tractor unit is coupled to the first trailer, and, in response to the dock data indicating the first trailer is associated with a delivered load, to draw a delivery status indicator adjacent to the trailer icon, the delivery status indicator indicating whether the first trailer should be moved to a trailer yard or should remain at the first dock.

[0285]

[0300] Example 54 includes the non-transitory computer readable medium of Example 53, where the instructions further cause the processor to modify an appearance of at least one of the trailer icon or the tractor unit icon when the load information indicates that the first trailer is temperature controlled.

[0286]

[0301] Example 55 includes the non-transitory computer-readable medium of example 45, where the instructions further cause the processor to render a reciprocal dock status indicator adjacent to the trailer icon, the reciprocal dock status indicator indicating at least one of: (1) cargo in the first trailer should be moved to a different trailer, or (2) cargo in the different trailer should be moved to the first trailer.

[0287]

[0302] Example 56 includes the non-transitory computer-readable medium of example 45, where the instructions further cause the processor to render a load direction indicator adjacent to the trailer icon, the load direction indicator indicating whether the first trailer is associated with an incoming load from which cargo on the first trailer is to be unloaded or an outgoing load from which cargo is to be loaded onto the first trailer.

[0288]

[0303] Example 57 includes the non-transitory computer-readable medium of example 45, where the instructions further cause the processor to render a priority indicator adjacent to the trailer icon, the priority indicator indicating a priority of the first trailer.

[0289]

[0304] Example 58 includes the non-transitory computer-readable medium of example 57, where the priority indicator toggles between a first appearance indicating the first priority and a second appearance indicating a second priority greater than the first priority.

[0290]

[0305] Example 59 includes the non-transitory computer-readable medium of example 45, where the instructions further cause the processor to, in response to dock data indicating the first trailer is associated with an incoming load, render a load counter within the trailer icon, the load counter indicating a total number of cargo units to be moved out of the first trailer.

[0291]

[0306] Example 60 includes the non-transitory computer-readable medium of example 59, where the instructions further cause the processor to determine a remaining number of cargo units to be removed from the first trailer based on activity detected within the trailer, and dynamically update a load counter to indicate the remaining number of cargo units to be moved out of the first trailer, the remaining number being plotted along with the total number.

[0292]

[0307] Example 61 includes the non-transitory computer-readable medium of example 45, where the instructions further cause the processor to render at least one of a carrier code or a trailer number adjacent to the trailer icon.

[0293]

[0308] Example 62 includes the non-transitory computer-readable medium of Example 44, where the instructions further cause the processor to render a plurality of restraint signal icons adjacent to corresponding dock icons of the plurality of dock icons, the plurality of restraint signal icons representing states of corresponding vehicle restraint devices at corresponding docks of the plurality of docks, the states of the vehicle restraint devices including a first state in which the vehicle restraint device is engaged with the trailer at the corresponding dock of the docks and a second state in which the vehicle restraint device is in a stowed position, and dynamically switch the plurality of restraint signal icons between displaying a red light and a green light based on the states of the corresponding vehicle restraint devices, the red light indicating the first state and the green light indicating the second state.

[0294]

[0309] Example 63 includes the non-transitory computer-readable medium of Example 44, wh...

Claims

1. 1. An apparatus for monitoring operations in a material handling facility, comprising: monitoring for first data indicative of a door associated with the material handling equipment being in an unclosed state; monitoring second data indicative of the passage of at least one person or object through a doorway associated with the door in the unclosed state; A data analyzer; a notification generator that generates a notification in response to the second data indicating a lack of passage of at least one of the person or object through the doorway during a duration during which the first data indicates the door is in the unclosed state, the notification indicating a false activation of the door; and An apparatus comprising:

2. 2. The apparatus of claim 1, wherein the data analyzer and the notification generator are executed by a controller located next to the door, the controller controlling operation of the door.

3. The apparatus of claim 1 , wherein the data analyzer determines a trend of false activations over a period of time, and the notification generator provides an indication of the trend.

4. The apparatus of claim 3 , wherein the notification generator generates an alert in response to the trend exceeding a threshold.

5. The apparatus of claim 1 , wherein the data analyzer tracks the number of false activations detected over a period of time.

6. 2. The apparatus of claim 1, further comprising an IO network interface for receiving the first and second data communicated from a controller associated with the door, the data analyzer and the notification generator being remote from the controller.

7. 7. The apparatus of claim 6, wherein the door is one of a plurality of doors associated with the material handling equipment, and the IO network interface determines at least one of a trend or number of false activations of the plurality of doors detected over a period of time.

8. A computer-readable medium containing instructions that, when executed, cause a processor to at least: monitoring first data indicative of a door associated with the material handling equipment being in an unclosed condition; monitoring second data indicative of the passage of at least one of a person or an object through a doorway associated with the door in the unclosed state; A computer-readable medium that generates a notification in response to the first data indicating that the door is in the unclosed state and the second data indicating a lack of passage of at least one of the person or the object through the doorway, the notification indicating a false activation of the door.

9. 9. The computer readable medium of claim 8, wherein the processor is executed by a controller located next to the door, the controller controlling operation of the door.

10. The computer-readable medium of claim 8 , wherein the processor generates an indication of a trend of false activations over a period of time.

11. The computer-readable medium of claim 10 , wherein the processor generates an alert in response to the trend exceeding a threshold.

12. 10. The computer-readable medium of claim 8, wherein the processor tracks the number of false activations detected over a period of time.

13. 9. The computer readable medium of claim 8, wherein the processor obtains the first and second data communicated from a controller associated with the door, the processor being remote from the controller.

14. 14. The computer-readable medium of claim 13, wherein the door is one of a plurality of doors associated with the material handling equipment, and the processor determines at least one of a trend or number of false activations of the plurality of doors detected over a period of time.

15. 1. A method for monitoring operations in material handling equipment, comprising: monitoring first data indicative of a door associated with the material handling equipment being in an unclosed state; monitoring second data indicative of the passage of at least one of a person or object through a doorway associated with the door in the unclosed state; generating a notification in response to the first data indicating that the door is in the unclosed state and the second data indicating a lack of passage of at least one of the person or the object through the doorway, the notification indicating a false activation of the door; The method includes:

16. 16. The method of claim 15, wherein the steps of monitoring the first and second data and generating a notification are performed by a controller located next to the door, the controller controlling operation of the door.

17. 16. The method of claim 15, further comprising generating an indication of a trend of false activations over a period of time.

18. The method of claim 17 further comprising generating an alert in response to the trend exceeding a threshold.

19. 16. The method of claim 15, further comprising tracking the number of false activations detected over a period of time.

20. 16. The method of claim 15, further comprising obtaining the first and second data communicated from a controller associated with the door, wherein the steps of monitoring the first and second data and generating the notification are performed by a server remote from the controller.

21. 21. The method of claim 20, wherein the door is one of a plurality of doors associated with the material handling equipment, the method further comprising determining at least one of a trend or number of false activations of the plurality of doors detected over a period of time.

22. 1. A system for monitoring operation of a door associated with material handling equipment, comprising: a first sensor generating a first output indicative of the door being in an unclosed condition; a second sensor that generates a second output indicative of the passage of at least one of a person or object through a doorway associated with the door in the unclosed state; a processor receiving the first and second outputs, the processor detecting a false actuation of the door when the first output indicates that the door is in the unclosed state and the second output is not generated by the second sensor; A system comprising:

23. 23. The system of claim 22, wherein the processor is executed by a controller located next to the door, the controller controlling operation of the door.

24. 23. The system of claim 22, wherein the processor generates an indication of a trend of false activations over a period of time.

25. 25. The system of claim 24, wherein the processor generates an alert in response to the trend exceeding a threshold.

26. 23. The system of claim 22, wherein the processor tracks the number of false activations detected over a period of time.

27. The system of claim 22 , wherein the processor is executed by a server remote from the first and second sensors.

28. 30. The system of claim 27, wherein the door is one of a plurality of doors associated with the material handling equipment, and the processor determines at least one of a trend or number of false activations of the plurality of doors detected over a period of time.

Images