Methods and apparatus for monitoring and controlling the operation of loading docks and equipment

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 the Disclosure

[0001]

[0001] This disclosure generally relates to monitoring systems, and more particularly to methods and apparatuses for monitoring and managing the operation of loading docks and facilities. Background

[0002]

[0002] A loading dock provides an area for a vehicle (e.g., a truck, trailer, etc.) to move next to a high platform of a building (e.g., a material handling facility) so that goods can be easily transferred between the vehicle and the building. Some loading docks include equipment such as dock levelers, vehicle restraint devices, and / or dock doors, all of which can be associated with one or more sensor / monitoring systems. In a material handling facility, additional equipment can be located to facilitate the movement, storage, and / or handling of goods, such as grade-level doors, HVAC (heating, ventilation, and air conditioning) systems, industrial doors for separating freezer rooms and / or other rooms, conveyor systems, fans for moving air in the facility, lighting, and signal systems.

Brief Description of the Drawings

[0003] [Figure 1] A diagram showing an exemplary material handling facility capable of implementing the teachings disclosed herein. [Figure 2] A diagram showing an exemplary loading dock of FIG. 1 as viewed from outside the material handling facility. [Figure 3] A diagram showing an exemplary loading dock of FIG. 1 as viewed from inside the material handling facility with a trailer parked at the dock. [Figure 4] A cross-sectional side view showing the exemplary loading dock of FIG. 1 together with an associated trailer of FIG. 3. [Figure 5] [[ID=z8]]A block diagram of an exemplary management server(s) of FIG. 1. [Figure 6] A block diagram of an exemplary main server of FIG. 1. [Figure 7]This is a block diagram of the exemplary database associated with the exemplary main server in Figure 1. [Figure 8] Figure 6 is a block diagram of an exemplary video management system for an exemplary main server. [Figure 9] Figure 6 is a block diagram of the exemplary event manager for the exemplary main server. [Figure 10] This is a block diagram of an exemplary distributed system that implements the teachings disclosed herein. [Figure 11] This is a block diagram of an exemplary implementation of an exemplary local controller corresponding to one of the controllers in Figure 1. [Figure 12] Figures 1, 6, and / or 10 are flowcharts illustrating exemplary machine-readable instructions for implementing the exemplary main server. [Figure 13] Figures 1, 6, and / or 10 are flowcharts illustrating exemplary machine-readable instructions for implementing the exemplary main server. [Figure 14] Figures 1, 6, and / or 10 are flowcharts illustrating exemplary machine-readable instructions for implementing the exemplary main server. [Figure 15] Figures 1, 6, and / or 10 are flowcharts illustrating exemplary machine-readable instructions for implementing the exemplary main server. [Figure 16] This flowchart shows exemplary machine-readable instructions for implementing the exemplary main server in Figures 1, 6, and / or 10, or the exemplary local controller in Figure 11. [Figure 17] This flowchart shows exemplary machine-readable instructions for implementing the exemplary main server in Figures 1, 6, and / or 10, or the exemplary local controller in Figure 11. [Figure 18] This flowchart shows exemplary machine-readable instructions for implementing the exemplary main server in Figures 1, 6, and / or 10, or the exemplary local controller in Figure 11. [Figure 19] This flowchart shows exemplary machine-readable instructions for implementing the exemplary main server in Figures 1, 6, and / or 10, or the exemplary local controller in Figure 11. [Figure 20] This flowchart shows exemplary machine-readable instructions for implementing the exemplary main server in Figures 1, 6, and / or 10, or the exemplary local controller in Figure 11. [Figure 21] This figure shows exemplary graphical user interfaces for several exemplary web pages hosted by a web server associated with the exemplary main server(s) in Figures 1, 6, and / or 10. [Figure 22] This figure shows exemplary graphical user interfaces for several exemplary web pages hosted by a web server associated with the exemplary main server(s) in Figures 1, 6, and / or 10. [Figure 23] This figure shows exemplary graphical user interfaces for several exemplary web pages hosted by a web server associated with the exemplary main server(s) in Figures 1, 6, and / or 10. [Figure 24] This figure shows exemplary graphical user interfaces for several exemplary web pages hosted by a web server associated with the exemplary main server(s) in Figures 1, 6, and / or 10. [Figure 24B] This figure shows exemplary graphical user interfaces for several exemplary web pages hosted by a web server associated with the exemplary main server(s) in Figures 1, 6, and / or 10. [Figure 25] This figure shows exemplary graphical user interfaces for several exemplary web pages hosted by a web server associated with the exemplary main server(s) in Figures 1, 6, and / or 10. [Figure 26] This figure shows exemplary graphical user interfaces for several exemplary web pages hosted by a web server associated with the exemplary main server(s) in Figures 1, 6, and / or 10. [Figure 27]This figure shows exemplary graphical user interfaces for several exemplary web pages hosted by a web server associated with the exemplary main server(s) in Figures 1, 6, and / or 10. [Figure 28] This figure shows exemplary graphical user interfaces for several exemplary web pages hosted by a web server associated with the exemplary main server(s) in Figures 1, 6, and / or 10. [Figure 29] This figure shows exemplary graphical user interfaces for several exemplary web pages hosted by a web server associated with the exemplary main server(s) in Figures 1, 6, and / or 10. [Figure 30] This figure shows exemplary graphical user interfaces for several exemplary web pages hosted by a web server associated with the exemplary main server(s) in Figures 1, 6, and / or 10. [Figure 31] This figure shows exemplary graphical user interfaces for several exemplary web pages hosted by a web server associated with the exemplary main server(s) in Figures 1, 6, and / or 10. [Figure 32] This figure shows exemplary graphical user interfaces for several exemplary web pages hosted by a web server associated with the exemplary main server(s) in Figures 1, 6, and / or 10. [Figure 33] This figure shows exemplary graphical user interfaces for several exemplary web pages hosted by a web server associated with the exemplary main server(s) in Figures 1, 6, and / or 10. [Figure 34] This figure shows exemplary graphical user interfaces for several exemplary web pages hosted by a web server associated with the exemplary main server(s) in Figures 1, 6, and / or 10. [Figure 35]A diagram showing an exemplary graphical user interface of several exemplary web pages hosted by a web server associated with the exemplary main server(s) of FIG. 1, FIG. 6, and / or FIG. 10. [Figure 36] A diagram showing an exemplary graphical user interface of several exemplary web pages hosted by a web server associated with the exemplary main server(s) of FIG. 1, FIG. 6, and / or FIG. 10. [Figure 37] A diagram showing an exemplary graphical user interface of several exemplary web pages hosted by a web server associated with the exemplary main server(s) of FIG. 1, FIG. 6, and / or FIG. 10. [Figure 38] A diagram showing an exemplary graphical user interface of several exemplary web pages hosted by a web server associated with the exemplary main server(s) of FIG. 1, FIG. 6, and / or FIG. 10. [Figure 39] A diagram showing an exemplary graphical user interface of several exemplary web pages hosted by a web server associated with the exemplary main server(s) of FIG. 1, FIG. 6, and / or FIG. 10. [Figure 40] A diagram showing an exemplary graphical user interface of several exemplary web pages hosted by a web server associated with the exemplary main server(s) of FIG. 1, FIG. 6, and / or FIG. 10. [Figure 41] A diagram showing an exemplary graphical user interface of several exemplary web pages hosted by a web server associated with the exemplary main server(s) of FIG. 1, FIG. 6, and / or FIG. 10. [Figure 42] A diagram showing an exemplary graphical user interface of several exemplary web pages hosted by a web server associated with the exemplary main server(s) of FIG. 1, FIG. 6, and / or FIG. 10. [Figure 43]This figure shows exemplary graphical user interfaces for several exemplary web pages hosted by a web server associated with the exemplary main server(s) in Figures 1, 6, and / or 10. [Figure 44] This figure shows exemplary graphical user interfaces for several exemplary web pages hosted by a web server associated with the exemplary main server(s) in Figures 1, 6, and / or 10. [Figure 45] This figure shows exemplary graphical user interfaces for several exemplary web pages hosted by a web server associated with the exemplary main server(s) in Figures 1, 6, and / or 10. [Figure 46] This figure shows exemplary graphical user interfaces for several exemplary web pages hosted by a web server associated with the exemplary main server(s) in Figures 1, 6, and / or 10. [Figure 47] This figure shows exemplary graphical user interfaces for several exemplary web pages hosted by a web server associated with the exemplary main server(s) in Figures 1, 6, and / or 10. [Figure 48] This figure shows exemplary graphical user interfaces for several exemplary web pages hosted by a web server associated with the exemplary main server(s) in Figures 1, 6, and / or 10. [Figure 49] This figure shows exemplary graphical user interfaces for several exemplary web pages hosted by a web server associated with the exemplary main server(s) in Figures 1, 6, and / or 10. [Figure 50] This figure shows exemplary graphical user interfaces for several exemplary web pages hosted by a web server associated with the exemplary main server(s) in Figures 1, 6, and / or 10. [Figure 51]This figure shows exemplary graphical user interfaces for several exemplary web pages hosted by a web server associated with the exemplary main server(s) in Figures 1, 6, and / or 10. [Figure 52] This figure shows exemplary graphical user interfaces for several exemplary web pages hosted by a web server associated with the exemplary main server(s) in Figures 1, 6, and / or 10. [Figure 53] This figure shows exemplary graphical user interfaces for several exemplary web pages hosted by a web server associated with the exemplary main server(s) in Figures 1, 6, and / or 10. [Figure 54] This figure shows exemplary graphical user interfaces for several exemplary web pages hosted by a web server associated with the exemplary main server(s) in Figures 1, 6, and / or 10. [Figure 55] This figure shows exemplary graphical user interfaces for several exemplary web pages hosted by a web server associated with the exemplary main server(s) in Figures 1, 6, and / or 10. [Figure 56] This figure shows exemplary graphical user interfaces for several exemplary web pages hosted by a web server associated with the exemplary main server(s) in Figures 1, 6, and / or 10. [Figure 57] This figure shows exemplary graphical user interfaces for several exemplary web pages hosted by a web server associated with the exemplary main server(s) in Figures 1, 6, and / or 10. [Figure 58] This figure shows exemplary graphical user interfaces for several exemplary web pages hosted by a web server associated with the exemplary main server(s) in Figures 1, 6, and / or 10. [Figure 59]This figure shows exemplary graphical user interfaces for several exemplary web pages hosted by a web server associated with the exemplary main server(s) in Figures 1, 6, and / or 10. [Figure 60] This is a block diagram of an exemplary processor platform configured to implement the exemplary main server(s) of Figure 1, Figure 6, and / or Figure 10 by executing the instructions in Figures 12 to 20. [Figure 61] This is a block diagram of an exemplary processor platform configured to implement the exemplary local controller of Figure 11 by executing the instructions of Figures 16 to 20. Detailed explanation

[0004]

[0019] Generally, the same reference number is used to refer to the same or similar parts throughout the drawings(s) and accompanying specifications.

[0005]

[0020] In this specification, descriptive terms such as “first,” “second,” and “third” are used to identify multiple elements or components that may be referred to separately. Unless otherwise specified or understood based on the context in which they are used, such descriptive terms are not intended to imply any meaning of priority, physical order or arrangement in a list, or temporal order, but are used solely as labels to refer to multiple elements or components separately in order to facilitate understanding of the examples disclosed. In some examples, the descriptive term “first” may be used to refer to a certain element in the detailed description, but the same element may also be referred to by different descriptive terms such as “second” or “third” in the claims. In such cases, it should be understood that such descriptive terms are used solely to facilitate reference to multiple elements or components.

[0006]

[0021] Figure 1 shows an exemplary material handling facility 100 that can implement the teachings disclosed herein. The material handling facility 100 can be associated with, for example, a storage warehouse, distribution center, manufacturing plant, retail store, etc. In the example described, the material handling facility 100 includes a number of loading docks 102 (two shown) that provide a platform for trucks to back up their trailers (or truck beds) to load and / or unload materials between the inside of the trailer and the material handling facility 100. Figure 2 shows an exemplary loading dock 102 viewed from the outside of the material handling facility 100. Figure 3 shows an exemplary loading dock 102 viewed from the inside of the material handling facility 100 with a trailer 300 parked in the dock 102. Figure 4 shows a cross-sectional side view of the exemplary loading dock 102 with the associated trailer 300. As shown in Figures 1 to 4, the exemplary dock 102 includes a door 104, an entrance / exit barrier 106, a dock leveler 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, a fan, lights, door seals, a shelter, or a trailer stand. In the examples described, the dock 102 includes a dock controller 116 for monitoring and / or controlling the operation of the door 104, the entrance / exit barrier 106, the dock leveler 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 being monitored and / or controlled by the controller 116. The display screen 117 can be a touchscreen that allows the user to input commands and / or instructions for controller operation and / or access to specific information associated with the controller, dock, or operations associated with the dock. In some examples, the display screen 117 can be integrated into a different device that is separate from the dock controller 116 but communicates with the dock controller 116.Although a single controller 116 is shown controlling all 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 of the doors 104, entrance / 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] The door 104 associated with the dock 102 is movable between an open position and a closed position to selectively open or close the entrance between the interior 118 of the material handling facility 100 and the external environment 120. Thus, when a trailer 300 or truck bed is parked in the dock 102, the door 104 provides access to the trailer when it is in the open position and prevents such access when it 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 control of the door 104's operation. For example, one or more door state sensors may monitor and / or detect the state 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 may 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 may monitor and / or detect when a person or object has passed through the doorway when the door is open; one or more motion and / or presence sensors may monitor and / or detect activity in the area near the doorway; one or more radio frequency identification (RFID) sensors may monitor and / or identify personnel, equipment, and / or materials passing through the doorway. One or more temperature sensors may monitor and / or detect the temperature on one or both sides of the door 104; one or more airflow sensors may monitor and / or detect the airflow through the door 104 (e.g., air passing through the door in the open or partially open position, and / or air leaking through the door when it is closed in the 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 the energy consumption and / or operation of the door actuator (e.g., a motor) used to open and close the door; and one or more image and / or video sensors (e.g., a camera) may be implemented to monitor and / or detect specific states 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 entrance / exit barrier 106 is constructed to provide a barrier extending to the entrance / exit associated with the door 104. The entrance / exit barrier 106 can prevent passage through the entrance / exit even when the door 104 is in the open position. In this way, the entrance / exit barrier 106 can be used as a safety precaution, for example, when the door 104 is open, as shown in Figure 2, but no trailer is parked in the dock 102, or when a trailer in the dock 102 is not restrained. The entrance / exit barrier 106 can also extend to the entrance / exit in front of the door 104 inside the material handling equipment 100 118 to protect the door 104 by reducing the possibility of material handling equipment colliding with the door 104 when the door 104 is closed. In some examples, the entrance / exit barrier 106 is associated with a barrier sensor 302 (Figure 3), which outputs a signal to the dock controller 116 to indicate the state of the entrance / exit barrier 106 (for example, whether the barrier is actively in use and blocking the entrance / exit (shown in Figure 2), retracted to provide passage for the entrance / exit (shown in Figures 3 and 4), or in an intermediate state). In some examples, the barrier sensor 302 and / or other sensors detect impacts (e.g., forces) on the barrier 106, and such impacts may indicate a collision with the barrier.

[0010]

[0025] In many cases, when a truck bed or trailer (for example, the trailer 300 shown in Figures 3 and 4) is parked in dock 102, a gap may exist between the rear edge of the truck bed or trailer and the outer surface of the dock 102 platform. The dock leveler 108 provides an adjustable bridge spanning this gap, allowing material handling equipment to move between the interior 118 of the material handling facility 100 and the trailer of the vehicle parked in dock 102. Furthermore, the dock leveler 108 can be vertically adjustable to act as a ramp to compensate for trailers having different heights relative to the dock 102 platform. In some examples, the dock leveler 108 includes one or more sensors to facilitate monitoring and control of the dock leveler 108's operation. For example, the leveler sensor can produce an output signal indicating whether the dock leveler 108 is in an active state (extending to bridge the gap between the dock platform and the trailer, as shown in Figures 3 and 4), an inactive state (the leveler is in the retracted position, as shown in Figure 2), or an intermediate state. In some examples, when the dock leveler 108 is in an active state, the trailer being pulled away from the dock 102 is detected by a limit switch (for example, the leveler is detected to drop when the extended end is no longer supported by the trailer). In such examples, the output of the limit switch can trigger the dock controller 116 to retract the dock leveler 108 to the inactive retracted position.

[0011]

[0026] A vehicle restraint device 110 associated with dock 102 is positioned in the external environment 120 to engage with some part of a vehicle parked in dock 102 (e.g., trailer 300) to reduce accidental vehicle movement (e.g., vehicle movement as a result of material handling equipment moving around in the trailer, and / or the driver prematurely removing the vehicle from the platform). In some examples, the vehicle restraint device 110 restrains the vehicle by engaging with the vehicle's rear impact guard (e.g., the ICC bar 400 shown in Figure 4). In some examples, the vehicle restraint device 110 engages with the tires and / or any other suitable part of the vehicle. In some examples, the vehicle restraint device 110 includes one or more sensors to facilitate monitoring and control of the operation of the vehicle restraint device 110. For example, a restraint sensor may produce an output signal indicating that the vehicle restraint device 110 is in a locked position (e.g., a fixed position for engaging / restraining the vehicle) or an unlocked position (e.g., retracted away from the vehicle). Alternatively or in addition, a restraint sensor(s) may generate an output signal indicating the position of the restraint device relative to a reference point and / or the force(s) applied to the restraint device, in order to determine whether the restraint device is actively engaging / restraining the vehicle.

[0012]

[0027] In the example illustrated in Figure 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 or not it is coupled to a tractor, or, alternatively, a vehicle having a cargo compartment or platform, for the purposes of discussion relating to the sensing of its presence or motion. In some examples, the presence of the trailer 300 is detected via one or more trailer sensors 202 (Figure 2) positioned in the external environment 120 in and / or near the building of the material handling facility 100. The trailer sensors 202 may be implemented using any suitable sensors, such as photoelectric eyes, proximity sensors, motion sensors, guided loop sensors, or light sensing ranging (LIDAR) systems. 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.) inside a trailer 300 parked in the loading dock 102 (e.g., during loading and / or unloading of cargo) or at the entrance to the dock 102 outside the facility. In some examples, the presence of personnel / equipment inside the trailer 300 is detected based on a motion sensor 204 (Figures 2-4) positioned in the material handling facility 100 and facing the trailer. Additionally or alternatively, the presence / motion detector 112 may include a presence detector system to detect the presence of personnel / equipment / materials on the platform of the leveler 108, inside the leveler pit, and / or elsewhere in the vicinity of the dock 102. In some cases, the presence of personnel / equipment within material handling equipment 100 adjacent to dock 102 is detected based on motion sensors 304 (Figures 3 and 4) facing the leveler and / or surrounding area. Additionally or alternatively, the presence of personnel / equipment / materials can be detected in the leveler pit 402 (Figure 4) below the dock leveler 108 based on one or more presence / motion sensors 404 in the leveler pit 402 (for example, when the leveler 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 in Figure 1 can enable the determination of the movement (e.g., speed, direction, etc.), position (e.g., proximity, orientation, etc.), size, shape, etc., and combinations thereof of vehicles, personnel, equipment, or other things (e.g., products, materials), and can enable the distinction of these things.

[0013]

[0028] The notification system 114 in the example described may include several 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 dock 102 of specific situations, warnings, events, and / or other conditions associated with any manner or state of dock 102 and / or vehicles located in dock. In addition or alternatively, some of the visual indicators may be lights intended to improve illumination and / or visibility of areas associated with dock 102, rather than indicating any specific situation or condition associated with dock. Depending on the purpose of the indicators, the visual and / or audible indicators of the notification system 114 may be located inside the material handling facility 100 118 and / or in the external environment 120 outside the material handling facility 100.

[0014]

[0029] In some examples, at least several indicators within the material handling equipment are positioned and / or oriented toward the external environment 120 (e.g., the end of an arm associated with motion sensor 204 shown in Figures 2–4) so ​​as to be visible from inside the trailer and / or audible from inside the trailer, so as to illuminate the interior of the trailer parked in dock 102 when the door 104 is open. Such indicators can provide additional visibility to personnel entering the trailer for loading or unloading cargo. Such indicators can also warn personnel inside the trailer of potential safety risks, such as when the vehicle restraint device 110 is not engaged, and / or the presence of persons near the dock 102 platform that may not be visible from inside the trailer. Other indicators within the material handling equipment 100 can be positioned and / or oriented so as to be visible from and / or audible from areas within the equipment 118 (e.g., the dock platform and / or surrounding areas), so as to illuminate those areas. Some such indicators can serve as warnings of potential safety risks, such as when the vehicle restraint device 110 is not engaged, and / or the presence of a person in the trailer that may appear unexpectedly. In addition or otherwise, the indicators can show the operational status of equipment associated with the dock 102.

[0015]

[0030] In some examples, the notification system 114 in Figure 1 includes a timing indicator 306 (Figure 3) positioned next to the door 104 so as to be visible from inside the material handling equipment 100, to display a timer showing how long the trailer has been parked in the dock 102. In this way, staff can be informed of how many hours remain before overdue and / or parking charges 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 count up. In some examples, when the timer reaches a threshold, the timing indicator 306 can change its appearance (e.g., change of color, start flashing, etc.) and / or activate another indicator to indicate to staff that they are approaching an end time related to a specific operational constraint (e.g., the need to quickly complete loading and / or unloading of the trailer). In some examples, the timing indicator 306 may indicate that loading and / or unloading of a trailer in a corresponding dock 102 takes precedence over loading and / or unloading of other trailers in other docks 102 (e.g., based on color, flashing, etc.). In some such examples, prioritization may be based on the expected time allocation and / or cost incurrence of the entire dock 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 so as to be visible from and / or audible from the area outside the dock 102, to illuminate the area outside the dock 102. In some examples, such indicators may be lights that illuminate the area to provide greater visibility to persons in the external environment 120 (e.g., a driver backing a trailer into dock 102). In addition or alternatively, in some examples, the indicators may be lights that provide warning and / or guidance to persons in the external environment 120. For example, as shown in Figure 2, the light indicator 206 outside the equipment 100 includes a red light and a blue light to guide truck drivers when a trailer (e.g., trailer 300 in Figures 3 and 4) can be backed into an area adjacent to dock 102 and / or when a trailer can be moved out of dock 102. In some examples, lights and / or audible indicators can be used to show the driver when the vehicle restraint device is in override mode, when dock equipment is being serviced, or when there are people / objects in or near the trailer's path. These conditions can be communicated through separate indicators that utilize different states or combinations of common indicators (such as changes in color / tone, flashing / sound patterns). Furthermore, in some examples, indicators associated with dock 102 include lights and / or audible alarms that indicate to a person standing near the dock entrance that the truck is reversing.

[0017]

[0032] In some examples, the dock controller 116 controls different indicators associated with the notification system 114 based on one or more signals received from various sensors associated with the door 104, entrance / exit barrier 106, dock leveler 108, vehicle restraint device 110, and / or 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., red light) whenever the restraint signal indicates that the vehicle restraint device 110 is active and engaged with the trailer. In another example, if the presence detector 112 does not detect a trailer parked in the dock 102, and the door sensor indicates that the door 104 is open, there is a risk that the open door will cause the trailer to fall off the dock platform. Therefore, in some such examples, the dock controller 116 may turn on a warning indicator to alert nearby individuals about the exposed fall. However, in some such cases, the dock controller 116 may not trigger the warning indicator when the barrier sensor 302 provides a signal indicating that the entrance / exit barrier 106 is in active use to prevent passage through an open entrance / exit. Therefore, different signals output from different of the various sensors can be combined to trigger the activation or change of state of indicators associated with the notification system 114, providing warnings, notifications, and / or guidance to persons in the area associated with the dock 102.

[0018]

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

[0019]

[0034] In the described example, the door controller 122 is responsible for controlling the operation of industrial doors located inside the material handling facility 100. In some examples, such doors are positioned in various locations within the material handling facility 100 to demarcate different rooms and / or areas of the facility. Such doors may include sensors similar to or the same as those described above for the door 104 of the loading dock 102 to enable the door controller 122 to monitor and / or control the door. For example, such a door may include sensors such as: one or more door state sensors that can indicate the state of the door (e.g., open, closed, opening, closing, etc.); one or more impact sensors that can monitor and / or detect when a material handling vehicle hits the door; one or more photoelectric eyes that can monitor and / or detect when a person or object passes through an entrance associated with the door; one or more motion and / or presence sensors that can monitor and / or detect activity in an area near the entrance; and one or more RFID sensors that can monitor and / or identify personnel, equipment, and / or materials passing through the entrance. Alternatively, one or more temperature sensors may monitor and / or detect the 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 airflow through the door 104 (e.g., air passing through the door in the open or partially open position, and / or air leaking through the door when it is closed in the closed position); and one or more actuator sensors may monitor and / or detect the energy consumption and / or operation of the door actuator (e.g., a motor) used to open and close the door. In some examples, the door controller 122 includes and / or is communicably 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 the intended use of the associated door. For example, one or more doors may provide access to a freezer. In such an example, the associated door controller 122 may monitor the feedback signals provided by the temperature sensor to ensure that the temperature on the freezer side of the room remains below a temperature setpoint. In addition 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 the door state sensor) and generate an alarm if the frequency or duration of the door being open exceeds a corresponding threshold. In other examples, one or more doors may be used to control access to a cleanroom 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 diffuse contaminants) is maintained below a suitable threshold or that a specific differential pressure is maintained on both sides of the entrance / exit. In some examples, separate doors can be configured, depending on the interlocking relationship, such that the operation of one door is coordinated based on the state or operation of a second door (for example, at any given time, only one of the two doors can be opened). In such examples, signals from sensors monitoring the operation of each door can be provided to separate door controllers 122 associated with each door (or a single controller 122 that controls both doors).

[0021]

[0036] In the example illustrated in Figure 1, the HVAC controller 124 monitors and / or controls the delivery of conditioned air to various areas within the material handling facility 100 via air ducts. In some examples, the HVAC controller 124 monitors and / or controls the operation of the blowers that supply air to the air ducts (e.g., speed, energy consumption, etc.). In some examples, the HVAC controller 124 receives feedback signals from temperature sensors positioned throughout the material handling facility 100. In some examples, airflow sensors, humidity sensors, and / or other types of sensors (e.g., monitoring pressure, contaminants, particles, chemicals, etc.) can also provide inputs to the HVAC controller 124 to facilitate the control and monitoring of the associated HVAC system.

[0022]

[0037] In the example illustrated in Figure 1, the fan controller 126 is responsible for monitoring and / or controlling one or more fans within the material handling equipment 100. The fans can be positioned in the equipment to increase the air circulation beyond that provided by the ventilation from the ducts associated with the HVAC controller 124. In some examples, such fans include one or more sensors to detect the status of the fan's operating parameters (e.g., on, off, fault (e.g., unable to start), speed, energy usage, etc.) which can be provided to the fan controller 126 as feedback signals.

[0023]

[0038] In the example illustrated in Figure 1, the conveyor controller 128 is responsible for monitoring and / or controlling one or more conveyor systems within the material handling equipment 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 the moving conveyor segments, and / or the position and / or shape of each conveyor segment (e.g., gradient, expansion, etc.). Additionally or alternatively, one or more sensors may provide an output indicating the energy usage of the motors used to operate such conveyor segments. Furthermore, in some examples, the conveyor system may include one or more sensors to detect obstacles and / or blockages 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 cases, feedback from the conveyor system can be used to measure and / or estimate the amount and / or progress of cargo being loaded and / or loaded onto trailers docked in the dock.

[0024]

[0039] In the example illustrated in Figure 1, the traffic controller 130 monitors the flow of pedestrian and / or powered vehicle traffic (e.g., material handling equipment such as forklifts) throughout the material handling facility 100 and controls signals to guide traffic and / or notify / warn staff about traffic approaching from different directions. In some examples, the traffic signaling system is positioned at the intersection of two or more lanes or travel paths for traffic within the material handling facility 100 and has one or more signal lights and / or associated displays facing the direction of each lane or travel path. In some examples, the traffic controller 130 causes the signal lights and / or displays of the exemplary traffic signaling system to provide different signals based on traffic detected along each of the lanes and / or travel paths associated with the traffic signaling system. In some examples, traffic is detected along each lane and / or travel path by individual traffic sensors (e.g., motion sensors) facing the direction of each lane or travel path. Therefore, if two traffic sensors facing separate paths both detect approaching traffic, the traffic controller 130 can generate a signal on a display facing the direction of the approaching traffic indicating that there is traffic approaching from another direction. In addition or alternatively, the traffic controller 130 can illuminate a single light visible from all directions to indicate that intersecting traffic is approaching from at least two directions. In some examples, both the traffic signal display and traffic sensors are located at the associated intersection (e.g., within a common housing). In some examples, the traffic signal system includes a display and / or traffic sensors positioned at a distance from the associated intersection and / or the traffic controller 130.

[0025]

[0040] In the example illustrated in Figure 1, controllers 116, 122, 124, 126, 128, and 130 each communicate with the main server 132. More specifically, in some examples, the dock controller 116, door controller 122, HVAC controller 124, fan controller 126, conveyor controller 128, and traffic controller 130 transmit values ​​corresponding to the operation and / or state parameters set for their respective controllers, as well as feedback signals collected from any sensors associated with their respective controllers. In this way, the main server 132 aggregates all available data associated with various separate systems within the material handling facility 100 in one place. By aggregating data from heterogeneous sources, the main server 132 is able to analyze and / or integrate the controller data to identify relationships that would not normally be possible. As will be described in more detail later, in some examples, the main server 132 organizes the aggregated controller data for presentation to end users through one or more dashboards or graphical user interfaces targeted at the specific interests of the end user. The graphical user interface can be presented by one or more web pages, apps, applets, applications, etc. In some examples, the graphical user interface can be configured to provide notifications and / or alarms when a specific event is detected based on the values ​​of different parameter combinations monitored by one or more of the controllers 116, 122, 124, 126, 128, and 130. Further details regarding the implementation of the exemplary main server 132 are provided below with respect to Figures 6 to 10. In addition or alternatively, in some examples, the main server 132 can again transmit information to the controllers 116, 122, 124, 126, 128, and 130. In some such examples, the information transmitted to these controllers is passive, as it does not affect the operation of the components controlled by the controllers.In such examples, this information can be displayed on a local display screen (for example, the display screen 117 of the dock controller 116 shown in Figure 3 and / or a similar local display screen associated with one of the other controllers 122, 124, 126, 128, 130) and made available for reference by personnel located near the controller. In other examples, the information transmitted from the main server 132 to the controller can be active, as it includes commands that cause the controller to implement specific actions. In the described example, the main server 132 is shown to be located at the material handling facility 100, but in other examples, the main server 132 may be located away from the material handling facility 100.

[0026]

[0041] In the example described in Figure 1, the material handling facility 100 includes one or more management servers 134 that facilitate the management of various aspects of the equipment assets and / or operational behavior of the material handling facility 100. In some examples, the management servers 134 communicate with a main server 132 via a bus, a local area network (LAN), and / or a wide area network (e.g., the Internet). An exemplary management system associated with the management servers 134 in Figure 1 is schematically represented in Figure 5. As shown in Figure 5, the exemplary management servers 134 include a dock / yard management system 502, an inventory control system 504, and a video management system (VMS) 506. In the example described, the dock / yard management system 502, the inventory control system 504, and the video management system 506 are coupled together so as to be communicative via a bus and / or network to which the main server 132 is connected. In some examples, one or more of the blocks shown in Figure 5 may be combined, divided, rearranged, and / or omitted from the exemplary management server(s) 134. Furthermore, 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.) as additions and / or alternatives to those shown in the described examples. Additionally or alternatively, in some examples, one or more of the dock / yard management system 502, inventory control system 504, and video management system 506 may be combined with and / or implemented by the main server 132.

[0027]

[0042] The exemplary dock / yard management system 502 in Figure 5 monitors and tracks all vehicles (e.g., delivery trucks, trailers, forklifts, hand trucks, wheelbarrows, etc.) and / or other equipment associated with the operation of the external perimeter of the material handling facility 100. In some examples, the dock / yard management system 502 generates alarms and / or notifications for scheduled maintenance, repairs, and / or replacements of equipment assets.

[0028]

[0043] The exemplary inventory control system 504 in Figure 5 monitors and tracks inventory stored in the material handling facility 100. More specifically, this can be achieved by identifying and monitoring the contents of trucks being loaded and unloaded at the dock 102. In some examples, the inventory control system 504 times 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 exemplary video management system 506 in Figure 5 manages access to and collects video data from one or more cameras 508 positioned throughout the material handling facility 100. The cameras 508 can be Internet Protocol (IP) cameras, Universal Serial Bus (USB) cameras, analog cameras, closed-circuit television (CCTV) cameras, and / or any other suitable type of camera. The cameras 508 can be located inside the facility 118 and / or outside to monitor the dock 102 or yard. In addition or alternatively, the cameras 508 can be positioned to monitor other spaces within the material handling facility, such as spaces associated with one or more of the door controllers 122, HVAC controllers 124, fan controllers 126, conveyor controllers 128, and / or traffic controllers 130. In some examples, the video management system 506 extracts and / or generates video segments in response to the detection of specific events triggered within the material handling facility 100. As will be described in more detail later, such events may be based on data collected by the main server 132 from different controllers 116, 122, 124, 126, 128, and 130. In some examples, the generated video segments may capture the circumstances that give rise to the detected events. In some examples, the video management system 506 may be implemented by and / or integrated into the main server 132. Additional details regarding the implementation forms 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 Figure 1, the main server 132 can also communicate with one or more remote servers 136 not located in the material handling facility 100. In some examples, the remote servers 136 correspond to additional servers equivalent to the main server 132 and are located elsewhere in association with other material handling facilities and / or the company operating the material handling facility 100 in Figure 1. In addition or alternatively, in some examples, the remote servers 136 may correspond to servers maintained by the equipment manufacturers associated with one or more remote asset management systems for the dock controller 116, door controller 122, HVAC controller 124, fan controller 126, conveyor controller 128, and / or traffic controller 130, or other equipment within the facility. For example, the remote server 136 may provide equipment warranty information, equipment version and / or update information, equipment installation date, technician and / or service request call records, etc.

[0031]

[0046] For illustrative purposes, the data reported from the different controllers 116, 122, 124, 126, 128, and 130 in Figure 1 to the main server 132 is referred to as I / O (input / output) data, as it includes inputs and outputs monitored and / or provided by each controller. In the example described, the I / O data collected by the main server 132 is transmitted from the controllers 116, 122, 124, 126, 128, and 130 via a wireless mesh network (other network types may also be used (e.g., wired or wireless non-mesh)). Thus, as shown in the example described in Figure 1, each controller 116, 122, 124, 126, 128, and 130 is equipped with an I / O communication board 133 that includes wireless transceivers (e.g., radios) to transmit I / O data according to any preferred communication protocol. In some examples, the I / O boards of controllers 116, 122, 124, 126, 128, and 130 directly transmit I / O data to receivers associated with the main server 132. In other examples, I / O data from one controller can be transmitted indirectly to the main server 132 via an I / O 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 I / O boards of controllers 116, 122, 124, 126, 128, and 130 are implemented with a reusable firmware module that converts and normalizes data collected by different controllers into a common format corresponding to a specific communication protocol. The reusable nature of the firmware allows it to be embedded into existing products and thus modified for integration into the monitoring system of the main server 132.Each of the controllers 116, 122, 124, 126, 128, and 130 can transmit data in a common format according to a single communication protocol, enabling 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 the sensors used to generate such data.

[0032]

[0047] In some examples, transmissions from controllers 116, 122, 124, 126, 128, and 130 reporting I / O data include device identification information, which includes 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 group of general-purpose data points, each with a corresponding address to identify it. In such examples, each data point represents a value for a specific I / O parameter monitored and / or generated by the controller. In some examples, the value of the I / O parameter corresponds to a measured output from a sensor monitored by the corresponding controller (e.g., the output of a door sensor indicating whether door 104 is open or closed). In other examples, the value of the I / O parameter is not directly measured or sensed, but derived based on one or more measurements (e.g., the transition state of 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., the values ​​of IO parameters) within an IO message based on the configuration data associated with the IO parameters stored in the 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 upload to the database when the controller is first configured on a wireless network. Uploading configuration data to the database can be done automatically when the associated controller implements the aforementioned reusable firmware module, which formats and normalizes 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 done manually.

[0034]

[0049] In some examples, the nature of the I / O board and associated radio used to transmit I / O messages to the main server 132 depends on the nature and / or structure of the corresponding controller. In some examples, the I / O board and associated radio are integrated into the main printed circuit board (PCB) of the associated controller. That is, a reusable firmware module that implements the communication protocol is implemented directly by the controller's main PCB. In the example described in Figure 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 that is 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 I / O communication functions associated with generating and formatting I / O data for wireless transmission over the radio. That is, the controller's main PCB can be modified to include a reusable firmware module without requiring a major redesign of the controller, since the radio is provided separately on a daughterboard. In the example described in Figure 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 general-purpose interface board having a local processor and memory that implements a reusable firmware module that handles the processing and formatting of IO data for transmission via the radio. In some examples, such an IO board can be coupled to the controller in a communicative manner in parallel with the controller's main PCB. That is, in such examples, the IO board directly monitors the inputs and outputs associated with the controller, independently of the controller's main PCB. Such a general-purpose interface board can be retrofitted to a controller and / or associated equipment that would not normally be able to generate IO data conforming to a specific communication protocol used to report to a main server 132 (for example, a device that cannot be modified to include a reusable firmware module). In the example described in Figure 1, the HVAC controller 124, the conveyor controller 128, and the traffic controller 130 include such a general-purpose radio interface board 142. In some such examples, the radios can be located on a separate interface board from the rest of the IO board to allow for interchangeability with each other. Furthermore, by using separate boards, the system can be configured for all digital I / O, all analog I / O, serial communication, Ethernet®, and / or any combination of digital I / O, analog I / O, serial communication, and Ethernet®, depending on the application in which the interface board is used.

[0037]

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

[0038]

[0053] In the example illustrated in Figure 1, the fan controller 126 monitors the associated fan using the Modbus protocol. In some examples, the fan controller 126 includes a wireless radio interface board 144 containing a reusable Modbus module for snooping and wirelessly streaming Modbus communications to the main server 132 without any modification of the data format. Thus, in some examples, the main server 132 includes the ability to interpret the I / O data received from the fan controller 126 so that it is normalized and aggregated with respect to other I / O data received from other controllers 116, 122, 124, 128, and 130.

[0039]

[0054] As described above, the main server 132 acts as a central hub for aggregating and / or integrating data associated with heterogeneous systems operating throughout the material handling facility 100. In some examples, the main server 132 includes and / or is associated with a web server 146 that hosts one or more web pages accessible by users via client devices 148. The client device 148 can be any suitable computing device having a browser for accessing the web pages hosted by the web server 146. Thus, the client device 148 can correspond to one or more worker stations located within the material handling facility (e.g., within the facility's logistics office). In some examples, the client device can be a portable device (e.g., a tablet, smartphone, etc.) carried by staff throughout the material handling facility 100 and / or away from the facility. Furthermore, some client devices 148 can be portable devices used by truck drivers transporting trailers in and out of the material handling facility 100, and / or by yard jockeys who move trailers within the dock 102 and / or the yard of the material handling facility 100.

[0040]

[0055] Different web pages may include different graphical user interfaces designed to present different types of information in an easily understandable format that facilitates users recognizing the relationships between data collected from different sources within the material handling equipment 100. In some examples, the main server 132 automatically updates one or more web pages via web-based communication 150 whenever new data relevant to a particular web page is collected. Furthermore, in some examples, web pages are designed to receive user input again provided to the main server 132. In some examples, web page updates are implemented based on pull requests from client devices requesting the updated information. Additionally or alternatively, in some examples, updates can be pushed to web pages actively opened by client devices specific for dynamic updates using push requests. In some examples, user input received on one web page can be pushed to other web pages displaying information about the user input (for example, other web pages accessed by other client devices 148). While this specification discloses graphical user interfaces for web pages, graphical user interfaces can also be presented using methods other than web pages (for example, through apps, applets, applications, etc.).

[0041]

[0056] In some examples, the main server 132 analyzes information provided by separate systems within the material handling equipment 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 I / O data) from several different 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 the detection of a specific event (e.g., when the conditions of the associated event rule are met). In some examples, the response may again provide information and / or commands to one or more of the controllers 116, 122, 124, 126, 128, 130 to cause such controllers to initiate some action on equipment associated with the corresponding controller (e.g., opening and closing a door, changing the operating state of a fan, blower, or conveyor, switching the state of an indicator light, etc.). In some examples, the main server 132 may respond to specific events by generating alarms, 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 may be provided via web communications 150 when a web page is updated. In addition or alternatively, the main server 132 may provide notifications to client devices 148 independently of the web server 146 using other forms of network communications 152, such as email messages, SMS (Short Message Service) messages, and push notifications. In addition or alternatively, the main server 132 may transmit notifications for drawing via local display screens (e.g., display screen 117) associated with one of the controllers 116, 122, 124, 126, 128, and 130 throughout the facility 100.In this way, such a notification provides information to personnel who are close to the same controller that reported the information to the main server 132 used to generate the notification.

[0042]

[0057] As disclosed herein, by providing individuals with automated notifications, those individuals can become aware of certain events that would otherwise remain unknown. These events may include activities that disrupt the efficient loading, unloading, and / or storage of goods in facility 100, activities that pose a safety risk to personnel in and / or around facility 100, and activities that result in energy loss leading to increased burden on the HVAC system (and associated costs), thus representing a significant improvement to the efficient use and operation of the aforementioned control systems. Monitoring of various systems and operations within the material handling facility 100, as well as the automated generation and transmission of notifications, enables, as illustrated in the examples disclosed herein, individuals to implement appropriate actions in response to various notifications (e.g., canceling a previous action that triggered a notification, providing additional training to mitigate or eliminate the trigger event, scheduling and / or implementing preventive and / or maintenance activities, reconfiguring process flows and / or equipment usage procedures, etc.).

[0043]

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

[0044]

[0059] The exemplary network communication interface 602 in Figure 6 enables communication with client devices 148 independently 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. In addition, in some examples, the network communication interface 602 can send and receive data with local management servers 134 and / or remote servers 136. In some examples, data received from servers 134, 136 is stored in a database 608.

[0045]

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

[0046]

[0061] The exemplary restart watchdog 606 in Figure 6 starts and monitors the web server 146 and the IO network interface 604 for potential 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 collected or transmitted via the IO network interface 604 during or before / after the failure as potentially erroneous, and then request that it be replaced with new IO data. In addition, in some examples, the restart watchdog 606 logs any detected failures to the database 608. In this way, subsequent analysis can determine the cause of the failure and possible countermeasures.

[0047]

[0062] As previously mentioned, the exemplary database 608 stores I / O data and associated configuration data for I / O parameters monitored by any of the controllers 116, 122, 124, 126, 128, and 130. Database 608 can also store data received from any of the other servers 134 and 136. In addition, in some examples, database 608 stores configuration data that defines events, the corresponding rules or conditions that trigger those events, and the actions to be taken in response to the detection of event triggers. Further details regarding some of the nature of the information stored in the database are described below with reference to Figure 7.

[0048]

[0063] Figure 7 is a block diagram illustrating an exemplary database 608 that stores different types of information, including configuration data associated with IO parameters corresponding to different devices or controllers communicating 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 controllers 116, 122, 124, 126, 128, and 130. As shown in the examples described, 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 Figure 7, the device identification information 704 includes the device name, device type, and address for devices on the wireless network. Including IO parameter information 706 in device information 702 enables device-wide logging of all data points, increasing the efficiency of archiving data history compared to generating individual history logs for each IO parameter. Furthermore, in some examples, the efficiency of data reporting from controllers and / or other devices is improved by devices that locally store such data in a compressed format. In this way, when the main server 132 requests data, the device can respond more quickly because the data is already compressed for transmission.

[0049]

[0064] The IO parameter information 706 includes the name of 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 the current value of the parameter, along with a timestamp for the current value. Furthermore, the IO parameter information 706 includes configuration data that enables 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 a change large enough to update the current value. That is, in some examples, small fluctuations in the reported parameter value relative to the current value can be ignored if the difference in value is smaller than the threshold. In some examples, when a significant change in the IO parameter value is received, the main server 132 transmits a confirmation that the new value has been stored in the database 608. In some such examples, a linked mechanism is implemented in which the controller that initially reported the data retains the detected IO change until it receives such confirmation of the stored data.

[0050]

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

[0051]

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

[0052]

[0067] In some cases, IO parameter information includes the identification of events associated with the parameter. That is, the parameter can serve as the basis for conditions defined for one or more event rules. By identifying all event rules suggested by the IO parameters in the database 706 shown in Figure 7, the main server 132 can identify all event rules that need to be analyzed whenever a change in the value of an IO parameter is detected. This significantly improves the efficiency of the main server 132 compared to other systems that must evaluate all event rules every time a new parameter value is collected.

[0053]

[0068] In the example illustrated in Figure 7, database 608 stores event definitions 708 that can be configured to define specific events and the conditions or rules that trigger such events. In some examples, the event definition 708 includes the 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 values ​​(possibly multiple) of IO parameters stored in database 608. In this way, specific IO parameters are associated with the aforementioned specific events. In addition, in some examples, the event definition includes information that sets out the response and / or action to be taken when the event is triggered. One response may be to generate and transmit a notification to specific recipients who may be interested in learning about the event. Thus, in some examples, the event definition 708 includes 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, dashboard popup, etc.). Furthermore, event definition 708 includes a list of notification recipients to whom the notification is intended, along with its contact information for sending the notification (e.g., email address, phone number). In some examples, notifications can be delivered to specific devices without referring to specific recipients or users associated with those devices.

[0054]

[0069] In some examples, one or more of the cameras 508 associated with the video management system 506 (and / or the video management system 614 described later) in Figure 5 can be positioned to capture the circumstances that may have led to the occurrence of an event. In this specification, an event occurring within the recordable range of one or more cameras is referred to as a video capture event. In some examples, an event definition may include a video segment definition that identifies the camera(s) 508, and a pre-event and post-event interval that identifies a time window that begins before the event and ends after the event for which the camera(s) 508 should capture video of the video segment. That is, the pre-event interval defines the duration of the corresponding video segment before the event is triggered, and the post-event interval defines the duration of the video segment that continues after the event is triggered. For example, one video segment can be defined with a 10-second pre-event interval and a 20-second post-event interval, resulting in a video segment duration of 30 seconds, and the event occurring 10 seconds after the segment begins. In other examples, the post-event time interval can begin after the detection of the second event associated with the first event (for example, the first event is triggered by the end of a condition). For example, if the condition that triggers the event lasts for 15 seconds, the total duration for the video segment in the above example should be 45 seconds (10 seconds for the pre-event time interval, 15 seconds for the event to be 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 archiving purposes. In other examples, the video segment definition can include timing parameters defined based on the total video duration (for example, the duration from the start to the end of the video segment) and a time offset to the event (for example, the duration after the start of the video segment where the event should occur). For example, to produce the same video as in the above example, the total video duration should be defined as 30 seconds and the time offset as 10 seconds.Additionally, a video segment definition may include a thumbnail offset time that defines the point in time within the video segment from which a video frame should be extracted as a thumbnail for that video segment.

[0055]

[0070] In addition to the event definition 708, the exemplary database 608 in Figure 7 includes an event log 710, which is archived each time an event is triggered. Thus, as shown in the examples described, the event log includes trigger event information 712 corresponding to a series of trigger events. In some examples, the trigger event information 712 includes the 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 of the event captured by one or more cameras 508 installed around the material handling equipment 100.

[0056]

[0071] The exemplary pull service manager 610 in Figure 6 enables communication with a client device 148 via a web page hosted by a web server 146. More specifically, in some examples, the pull service manager 610 enables the initial loading of relevant data from the database 608 in response to a pull request from the client device 148 accessing the web page. Additionally, the pull service manager 610 enables the content of the web page to be updated virtually in real time by dynamic retrieval of data from the database 608. In some examples, the pull service manager 610 enables the request for new data via a pull request in response to an end user (e.g., on the client device 148) entering data into an available user entry field within the web page. In some examples, new data can be retrieved while the user is entering (e.g., typing) data, before the user actually submits the data.

[0057]

[0072] The exemplary push service manager 612 in Figure 6 uses the push request communication protocol to push data between different live web pages (accessed, for example, by different client devices 148) and provides 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 web pages among these web pages without having to wait for client devices 148 to request data updates (for example, via pull requests). In addition, the push service manager 612 enables the provision of user input data provided by an end user through one web page to other web pages for substantially real-time updates between heterogeneous and / or unrelated web pages, without the need for such data requests from the web server 146 by separate web pages, and / or modification of the web server 146. Hereinafter, the exemplary pull service manager 610 and the exemplary push service manager 612 are collectively referred to as exemplary notification generators. In this specification, an exemplary notification generator generates information to be provided for drawing via a display (for example, via one or more web pages and / or graphical user interfaces associated with other applications implemented on the computer), or otherwise, information to be provided for user access (for example, transmission in an email message, storage in an event history log, etc.).

[0058]

[0073] In some examples, push updates are achieved by configuring separate web pages with push requests that subscribe to dynamic (e.g., virtually real-time) updates of a particular type of information identified based on specific columns 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., specific controllers 116, 122, 124, 126, 128, 130). For example, a web page might include a column called "DockSubscribe" to subscribe to updates when IO data reported from dock controller 116 changes. Thus, when one IO parameter value reported by dock controller 116 changes, the push service manager 612 pushes the new value to the subscribing web page. In some examples, multiple IO parameters can be grouped together to be reported together based on their interrelationships related to the content that should be displayed on the web page. Thus, in some examples, when any one of the IO parameters in that group changes, the push service manager 612 can send all associated IO parameters to the subscribing web page. In another example, only new I / O parameters could be reported to a webpage, which could then initiate a pull request to retrieve other such parameters.

[0059]

[0074] In some examples, as soon as a user accesses a particular webpage via client device 148, the scripting within the webpage can join a push request. In other examples, the webpage cannot begin joining until the user starts entering data through the webpage. The push service manager 612 monitors all webpages open on all client devices 148 to track all joinings being made by any currently open webpage. When the main server 132 collects new I / O data from one or more controllers associated with a particular joining, it can automatically push the new data to the webpage corresponding to that joining.

[0060]

[0075] Following the same method, user input data received on one webpage can be obtained and distributed to other webpages hosted by the web server 146. In particular, when a user enters data (via client device 148), this data is provided to the main server 132 (via web server 146). Based on the type of information provided, the push service manager 612 pushes that information to all other active webpages that have subscribed to the same type of information, based on the fact that the webpage's scripting contains the same specific column. Thus, the specific column acts as a destination address for other webpages to send user input data. This makes it possible to send user input data between different websites without modifying the server to incorporate new routing paths between new webpages that the web server 146 did not previously host.

[0061]

[0076] In some examples, updated separate web pages may be different instances of the same web page (for example, accessed by two different client devices 148) and / or completely different web pages hosted by the web server 146. For example, different web pages that can subscribe to updates of common information may include web pages for truck drivers to sign in and sign out, web pages to be displayed in driver lounges or waiting rooms, web pages to provide driver-specific status updates (for example, to drivers' personal smartphones), web pages to be displayed in the dock allocation center of the logistics office, web pages for the yard map dashboard of the logistics office, and / or web pages for the event log notification center.

[0062]

[0077] In some examples, the main server 132 can distinguish between updated information collected from controllers 116, 122, 124, 126, 128, and 130 and user input data from another web page manually entered via client device 148. In some examples, an instruction for the type of update for data associated with a particular parameter (e.g., data reported by a sensor or manually updated data) is stored in database 608 along with the collected data. In some examples, the instruction for 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 instructions when the updated information is based on sensor data (e.g., from a controller) or human-entered data.

[0063]

[0078] In the example described in Figure 6, the video management system 614 can function substantially the same as the video management system 506 in Figure 5. In some examples, when the video management system 506 in Figure 5 is implemented, the video management system 614 in Figure 6 can be omitted. Similarly, in other examples, when the video management system 614 in Figure 6 is implemented by the main server 132, the video management system 506 in Figure 5 can be omitted. In some examples, the system may not include a video management system at all; that is, in some examples, both the video management system 506 in Figure 5 and the video management system 614 in Figure 6 can be omitted. Additional details regarding the implementation forms of the video management system 614 in Figure 6 (and / or the video management system 506 in Figure 5) are shown in Figure 8.

[0064]

[0079] As shown in Figure 8, the video management system 614 of Figure 6 (and / or the video management system 506 of Figure 5) includes an exemplary communication interface 802, an exemplary video segment generator 804, an exemplary video analyzer 806, and an exemplary video database 808. As shown in the examples described, 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 can generate video segments associated with specific events detected in relation to the operation of the material handling equipment 100. In some examples, the detected events correspond to events detected by the main server 132 based on analysis of I / O data collected by the main server 132, as will be described in more detail later. In some examples, the video segments generated by the video segment generator 804 include video that extends over a period before the detected event (e.g., 10 seconds, 30 seconds, 1 minute, 5 minutes, etc.) and a period after the detected event. The duration of both the pre- and post-detection video segments can be set separately based on the nature of the specific event being 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 one or more client devices (e.g., associated with warehouse managers and / or other interested individuals) and / or for transmission to one or more client devices (e.g., as email attachments).

[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, erratic forklift behavior, etc.) and / or other configurable situations (e.g., identification of individuals based on facial recognition, detection of 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 detected events. In other examples, the video analyzer 806 can sequentially analyze video streams from one or more of the cameras 508 with respect to safety events. Safety events may include collisions, near misses, and / or other accidents occurring in 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 within and around the material handling equipment 100. Person identification can be useful in determining who triggered the initial event that led to the generation of the video segment. In some examples, the video analyzer 806 uses facial recognition technology to identify detected individuals (for example, to determine whether the person works in the material handling facility or is an unrecognized visitor or intruder).

[0067]

[0082] As shown in the examples described, 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 continuously captures video, and the captured data is archived in the database 808 over a long period (e.g., 24 hours, 1 week, 1 month). In addition 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, video segments are stored over a threshold period (e.g., 24 hours, 1 week, 1 month) unless the user requests that video segments be stored for a longer duration (e.g., indefinitely). In some examples, the video database 808 also stores annotations and / or comments received from the user after reviewing the video segments. Furthermore, the video database 808 can store video segment definitions that outline the timing and duration of the video segments for detected events. In some examples, the database 808 in Figure 8 can be incorporated into the exemplary database 608 in Figure 6.

[0068]

[0083] Returning to the example illustrated in Figure 6, the exemplary event manager 616 of the main server 132 analyzes the IO data received from controllers 116, 122, 124, 126, 128, and 130 to detect the occurrence of a particular event. For example, the event manager 616 may determine that specific alarm conditions for triggering an alarm have been met. In some examples, the conditions and / or rules used to detect such events are stored in the aforementioned database 608. In the illustrated example, the event manager 616 causes the network communication interface 602 to update all 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 events detected from data received on the IO network interface 604 to web pages that have a subscription for dynamic updates using push requests. In addition or alternatively, in some examples, the event manager 616 instructs the push service manager 612 to route changes received from one client device 148 (for example, based on user input on 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. In addition or alternatively, the event manager 616 may 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] Furthermore, in response to detecting a specific 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 detection of the event, and then immediately thereafter (for example, after the video segment has been generated to include a configured post-event time interval associated with the segment), send a second email with the video segment attached. 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 the implementation of the event manager are provided below with respect to Figure 9. Specifically, as shown in the example described in Figure 9, the event manager 616 includes an exemplary device identifier 902, an exemplary configuration engine 904, an exemplary data analyzer 906, an exemplary time stamper 908, an exemplary parameter value converter 910, an exemplary event analyzer 912, an exemplary event logger 914, an exemplary notification engine 916, and an exemplary web page analyzer 918.

[0071]

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

[0072]

[0087] In the examples described, the configuration and / or commissioning of new devices (and / or reconfiguration of existing devices) is achieved via the exemplary configuration engine 904 in Figure 9. In some examples, upon receiving an I / O message from a device (e.g., a controller) (e.g., a new device) whose device identifier 902 does not recognize, the configuration engine 904 may prompt the operator to authenticate the automatic upload for configuration of all data associated with the device. Additionally or alternatively, the device name and address may be stored in a database without requiring authentication to upload such data for configuration. Instead, the configuration engine 904 may wait for the operator to initiate the device configuration. In such examples, the configuration engine 904 may provide a list of devices found on the wireless network communicating with the main server 132. Since the names and addresses of unconfigured devices are stored in the database, the operator can include those unconfigured devices in a list for selection for configuration. In this way, the user is assisted with the commissioning and configuration of new devices to be monitored by the main server 132.

[0073]

[0088] The illustrative data analyzer 906 in Figure 9 monitors and / or analyzes IO data contained in IO messages received from controllers 116, 122, 124, 126, 128, and 130, and / or any other data reported to the main server 132 from any other device (e.g., management server 134, remote server 135, client device 148, etc.). In some examples, any one of controllers 116, 122, 124, 126, 128, and 130 may report data associated with multiple different IO parameters. Therefore, 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, identifying a specific IO parameter is based on looking up the parameter address contained in the IO message in database 608. After a specific IO parameter is identified, the data analyzer 906 can compare the value of the IO parameter reported in the IO message with the most recent value stored in database 608. If this value does not change, the IO message does not carry any new information and no further analysis is required. However, if the value of the IO parameter changes, 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 dead zone when the change in value exceeds a threshold assigned to the parameter. When the reported value for the IO parameter has changed sufficiently, the exemplary time stamper 908 can timestamp the new value stored in the database 608 to record when the change occurred.

[0074]

[0089] When the reported value for an IO parameter changes, an exemplary parameter value converter 910 is implemented to convert or translate that value into a human-readable format. In some examples, this involves applying one or more conversion factors associated with the IO parameter stored in the database 608. The parameter value converter 910 can also convert this value into a text format corresponding to a specific state for a digital IO value associated with the context of the IO parameter (e.g., "OPEN" or "CLOSED" for a door), or a descriptive statement for an analog IO value (e.g., "27 degrees F"). In addition or alternatively, the parameter value converter 910 can convert the IO parameter value into non-textual visual context-specific indicators such as images, icons, or colors.

[0075]

[0090] In the example illustrated in Figure 9, the exemplary event analyzer 912 determines whether the IO parameter reported in the IO message identified by the data analyzer 906 is associated with or suggested by an event rule. That is, the event analyzer 912 determines whether the IO parameter is the basis for a condition that defines the trigger of an event. If the IO parameter is 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 parameter to determine whether an 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 the 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 may initiate one or more actions in response to that event. In some examples, one response includes generating and distributing a notification to the individual concerned. Thus, the exemplary event manager 616 includes a notification engine 916 for generating 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 trigger event. Furthermore, in some examples, the configured data associated with the trigger event identifies the intended recipient of the notification, along with contact information (e.g., email address, telephone number, etc.) used to deliver the notification. In some examples, the notification engine generates a notification for display on a specific computing device and / or display screen, regardless of the identification information of the specific recipient. For example, the notification may include an update to a display screen in the logistics office of the material handling facility 100. In some examples, the notification engine 916 can generate notifications to be provided to one or more of the controllers 116, 122, 124, 126, 128, and 130 in Figure 1 for display on a local screen (for example, the display screen 117 in Figure 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 exemplary web page analyzer 918. Thus, the exemplary notification engine 916 and the web page analyzer 918 are additional examples of notification generators (along with the aforementioned push service managers 610 and 612).

[0077]

[0092] Regardless of whether a specific event is triggered, the exemplary webpage analyzer 918 in Figure 9 can determine whether an IO parameter is associated with content displayed through one or more webpages hosted by the web server 146, and update the webpage by sending out any new reported values ​​for the parameter. As mentioned above, in some examples, webpage updates can be pushed to the webpage via the push service manager 612 for virtually real-time updates without polling for such updates. Alternatively, the pull service manager 610 can also poll for updates using pull requests.

[0078]

[0093] Figure 6 shows an exemplary implementation of the main server 132 in Figure 1 (and associated video management system 614 in Figure 8 and event manager 616 in Figure 9), but one or more of the elements, processes, and / or devices shown in Figures 6 and 9 can be combined, split, rearranged, omitted, removed, and / or implemented in any other way. Furthermore, the exemplary network communication interface 602, exemplary I / O network interface 604, exemplary restart watchdog 606, exemplary database 608, exemplary pull service manager 610, exemplary push service manager 612, exemplary video management system 614 (including any of exemplary communication interface 802, exemplary video segment generator 804, exemplary video analyzer 806, and / or exemplary video database 808), exemplary event manager 616 (including any of exemplary device identifier 902, exemplary configuration engine 904, exemplary data analyzer 906, exemplary time stamper 908, exemplary parameter value converter 910, exemplary event analyzer 912, exemplary event logger 914, exemplary notification engine 916, and / or exemplary web page analyzer 918), and / or, more generally, the exemplary main server 132 in Figure 1 can be implemented by hardware, software, firmware, and / or any combination of hardware, software, and / or firmware.Therefore, for example, an exemplary network communication interface 602, an exemplary I / O network interface 604, an exemplary restart watchdog 606, an exemplary database 608, an exemplary pull service manager 610, an exemplary push service manager 612, an exemplary video management system 614 (including any one of the exemplary communication interface 802, an exemplary video segment generator 804, an exemplary video analyzer 806, and / or an exemplary video database 808), an exemplary event manager 616 (including an exemplary device identifier 902, an exemplary configuration engine 904, an exemplary data analyzer 906, an exemplary time stamper 908, an exemplary parameter value converter 910, an exemplary event analyzer 912, 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 circuits, logic circuits, programmable processors, programmable controllers, graphics processing units (GPUs), digital signal processors (DSPs), application-specific integrated circuits (ASICs), programmable logic devices (PLDs), and / or field-programmable logic devices (FPLDs).When reading any of the claims of the apparatus or system of this patent that pertain purely to implementations of software and / or firmware, the following are described: Exemplary network communication interface 602, Exemplary I / O network interface 604, Exemplary restart watchdog 606, Exemplary database 608, Exemplary pull service manager 610, Exemplary push service manager 612, Exemplary video management system 614 (including any of Exemplary communication interface 802, Exemplary video segment generator 804, Exemplary video analyzer 806, and / or Exemplary video database 808), and / or Exemplary event manager 616 (Exemplary device At least one of the following (including any one of the following): IS identifier 902, exemplary configuration engine 904, exemplary data analyzer 906, exemplary time stamper 908, exemplary parameter value converter 910, exemplary event analyzer 912, exemplary event logger 914, exemplary notification engine 916, and / or exemplary web page analyzer 918) is expressly defined herein to include a non-temporary computer-readable storage device or storage disk, such as memory, digital versatile disk (DVD), compact disk (CD), Blu-ray disk, USB memory stick, or solid state memory disk device, including software and / or firmware. Furthermore, the exemplary main server 132 in Figure 1 may include one or more elements, processes, and / or devices in addition to, or instead of, those shown in Figures 6, 8, and 9, and / or may include two or more of any or all of the elements, processes, and devices shown. In this specification, the term “communicate,” including its variations, encompasses direct communication and / or indirect communication through one or more intermediate components, and does not require direct physical (e.g., wired) communication and / or continuous communication, but rather includes, additionally, selective communication at periodic intervals, scheduled intervals, non-periodic intervals and / or one-time events.

[0079]

[0094] In some examples, one or more of the blocks in Figure 6 (and / or the associated blocks in Figures 8 and 9) can be implemented on one or more separate servers. For example, in some examples, the database 608 can be implemented on a server separate from that of the main server 132. Additionally or alternatively, in some examples, the IO network interface 604 can be implemented on a separate IO server different from the main server 132, which includes the event manager 616. Furthermore, as shown in the example described in Figure 10, a distributed system 1000 can be created in which 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 within the distributed system 1000 and connected communicably via one or more routers 1004. In the example described, a single database 608 is responsible for 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 shown in Figure 10, each of the IO servers 1002 is communicably coupled to a different set of wireless IO devices (e.g., equivalent to any of controllers 116, 122, 124, 126, 128, and 130). As shown in the described example, a separate IO server 1002 communicates with the main server 132 via an exemplary router 1004. This arrangement makes it possible to collect and integrate data from geographically distributed devices (e.g., beyond the signal range of effective wireless communication) 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 described 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 router 1004 can enable a large number of TCP connections. Therefore, since communication between router 1004 and server 132 is based on a TCP connection, when IO server 1002 is located within the wireless range of wireless IO device 1006, router 1004 and / or server 132 can be positioned beyond the wireless communication range. Thus, router 1004 acts as a concentrator for the TCP connection for the distributed system shown in Figure 10. In some examples, the number of main servers 132 can be scaled up or down depending on considerations of processing capacity and bandwidth (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 Figure 10 may be suitable for applications spanning multiple buildings on a large campus and / or for enterprises with multiple facilities in geographically separated locations (e.g., different cities, different states, different countries, etc.).

[0081]

[0096] Except in some examples, the analysis and processing of I / O data in each controller may be limited to less I / O data than all I / O data aggregated by the main server 132 from all sources across the entire material handling facility 100, at least some of the functions implemented by the main server 132 can be implemented, alternatively and / or separately, by any one of the controllers 116, 122, 124, 126, 128, and 130 in Figure 1. That is, in some examples, controllers 116, 122, 124, 126, 128, and 130 can analyze their respective I / O data to identify events that trigger the implementation of specific actions, such as drawing via a local display screen (e.g., display screen 117 in Figure 3), and / or storing in a database, and / or generating notifications for further analysis, processing, and / or transmission to the main server 132 for distribution. While controllers 116, 122, 124, 126, 128, and 130 may be limited to processing I / O data directly collected by their respective corresponding controllers, in some examples, the main server 132 may provide additional information obtained from other sources (e.g., different controllers in material handling equipment 100, client device(s) 148, management server(s), and / or remote server(s)).

[0082]

[0097] More specifically, Figure 11 shows an exemplary implementation of a local controller 1100 that can correspond to any one of the controllers 116, 122, 124, 126, 128, and 130 of Figure 1, and these controllers are local to the equipment operated and / or controlled by such controllers. Thus, as shown in the examples described, the local controller 1100 includes an exemplary communication board 133, and the controller 1100 is able to transmit I / O data to the main server 132 via the communication board 133. Furthermore, in some examples, as described above, the controller 1100 can also receive feedback and / or other such information from the main server 132. In addition, as shown in the example described in Figure 11, the local controller includes an exemplary communication interface 1102, an exemplary data analyzer 1104, an exemplary event analyzer 1106, an exemplary parameter value converter 1108, an exemplary notification engine 1110, an exemplary database 1112, an exemplary display 1114, and an exemplary device controller 1116.

[0083]

[0098] The exemplary communication interface 1102 enables the controller 1100 to communicate with associated devices monitored and / or controlled by the controller 1100. For example, the communication interface 1102 to the dock controller 116 in Figure 1 enables the dock controller 116 to send commands or instructions to actuators, sensors, and / or other devices associated with the dock, including the door 104, entrance / exit barrier 106, dock leveler 108, vehicle restraint device 110, presence detector 112, and notification system 114, and to receive feedback from those devices. In some examples, the communication board 133 and the communication interface 1102 can be integrated and function as a single component.

[0084]

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

[0085]

[0100] More specifically, the exemplary data analyzer 1104 in Figure 11 monitors and / or analyzes I / O data received from an associated device or sensor via the communication interface 1102 to determine if such data has changed to reflect a change in the state or condition of the device or sensor. In some examples, when the exemplary data analyzer 1104 identifies a change in I / O data, the data analyzer 1104 can store that change in the database 1112. In some examples, the data analyzer 1104 monitors and / or analyzes I / O data without storing it in the database 1112. Instead, in some such examples, the data analyzer 1104 works in conjunction with the event analyzer 1106 to determine any preferred action or operation based on the current value of the I / O data determined by the data analyzer 1104. In some examples, the data analyzer 1104 can also store, monitor, and / or analyze data provided by the main server 132. For example, with respect to the dock controller 116, maintenance personnel can provide details regarding the maintenance of equipment in dock 102 and / or instructions to deactivate the dock for maintenance via one of the client devices 148. In addition or by alternative means, information collected by the main server 132 from a truck driver's portable device (corresponding to another of the client devices 148) regarding details associated with a trailer parked in the associated dock 102 can 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 in Figure 11.

[0086]

[0101] As described above, the exemplary data analyzer 1104 can operate together with the exemplary event analyzer 1106 in the example described in Figure 11. In some examples, the data analyzer 1104 and the event analyzer 1106 can be integrated into a single component. The exemplary event analyzer 1106 determines whether certain I / O data associated with certain I / O parameters corresponds to conditions that define the trigger for one or more events, which the event analyzer 1106 can store information defining the event and / or initiate an action. In some examples, this action may involve activating a particular device (e.g., opening and closing a door, generating an alarm, changing the output of a visual and / or audible indicator). Furthermore, in some examples, the event analyzer 1106 may determine that an appropriate action in response to an event being triggered is to store locally, transmit to the main server 132, and / or generate a specific notification that can be displayed via a local display screen such as the exemplary display 1114.

[0087]

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

[0088]

[0103] An exemplary implementation of any one of the exemplary controllers 116, 122, 124, 126, 128, and 130 in Figure 1 is shown by the exemplary local controller 1100 in Figure 11, but one or more of the elements, processes, and / or devices shown in Figure 11 can be combined, split, rearranged, omitted, removed, and / or implemented in any other way. Furthermore, the exemplary communication board 133, exemplary communication interface 1102, exemplary data analyzer 1104, exemplary event analyzer 1106, exemplary parameter value converter 1108, exemplary notification engine 1110, exemplary database 1112, exemplary display 1114, exemplary equipment controller 1116, and / or, more generally, the exemplary local controller 1100 in Figure 11 can be implemented by hardware, software, firmware, and / or any combination of hardware, software, and / or firmware. Therefore, for example, any of the exemplary communication board 133, exemplary communication interface 1102, exemplary data analyzer 1104, exemplary event analyzer 1106, exemplary parameter value converter 1108, exemplary notification engine 1110, exemplary database 1112, exemplary display 1114, exemplary equipment controller 1116, and / or, more generally, exemplary local controller 1100, may be implemented by one or more analog or digital circuits, logic circuits, programmable processors, programmable controllers, graphics processing units (GPUs), digital signal processors (DSPs), application-specific integrated circuits (ASICs), programmable logic devices (PLDs), and / or field-programmable logic devices (FPLDs).When reading any of the claims of the apparatus or system of this patent that pertain purely to implementations of software and / or firmware, at least one of the exemplary communication board 133, exemplary communication interface 1102, exemplary data analyzer 1104, exemplary event analyzer 1106, exemplary parameter value converter 1108, exemplary notification engine 1110, exemplary database 1112, exemplary display 1114, and / or exemplary device controller 1116 is expressly defined herein as including a memory, digital versatile disc (DVD), compact disc (CD), Blu-ray disc, or other non-temporary computer-readable storage device or storage disk containing software and / or firmware. Furthermore, the exemplary local controller 1100 in Figure 11 may include, in addition to or instead of, those shown in Figure 11, one or more elements, processes, and / or devices, and / or two or more of any or all of the elements, processes, and devices shown. In this specification, the term “communicate,” including its variations, encompasses direct communication and / or indirect communication through one or more intermediate components, and does not require direct physical (e.g., wired) communication and / or continuous communication, but rather includes, additionally, selective communication at periodic intervals, scheduled intervals, non-periodic intervals and / or one-time events.

[0089]

[0104] Figures 12 to 15 show flowcharts representing exemplary hardware logic or machine-readable instructions, hardware-implemented state machines, and / or any combination thereof for implementing the main server 132 of Figures 1, 6, and / or Figure 10. The machine-readable instructions may be one or more executable programs or parts(s) of executable programs for execution by a processor such as the processor 6012 shown in the exemplary processor platform 6000 discussed below with respect to Figure 60. The programs may be implemented as software stored on a non-temporary computer-readable storage medium such as a CD-ROM, floppy disk, hard drive, DVD, Blu-ray disk, or memory associated with the processor 6012; however, the entire program and / or parts of the program may be executed by a device other than the processor 6012, and / or by firmware or dedicated hardware. Furthermore, while the exemplary programs will be described with reference to the flowcharts shown in Figures 12 to 15, a number of other methods for implementing the exemplary main server 132 may also be used. For example, the execution order of these blocks can be changed, and / or some of the described blocks can be modified, removed, or combined. In addition or alternatively, any or all of the blocks can 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 running software or firmware.

[0090]

[0105] The machine-readable instructions described herein may be stored in one or more of the following formats: compressed format, encrypted format, fragmented format, packaged format, etc. The machine-readable instructions described herein may be stored as data (e.g., parts of instructions, code, code representation, etc.) that can be used to create, manufacture, and / or form machine-executable instructions. For example, machine-readable instructions may be fragmented and stored in one or more storage devices and / or computing devices (e.g., servers). Machine-readable instructions may require one or more of the following processes to be made directly readable and / or executable by computing devices and / or other machines: installation, modification, adaptation, updating, combining, supplementing, setting up, decryption, recovery, unpacking, distribution, reallocation, etc. For example, machine-readable instructions may be stored in multiple parts individually compressed, encrypted, and stored in separate computing devices, which, when decrypted, recovered, and combined, form a set of executable instructions that implement a program as described herein. In another example, machine-readable instructions can be stored in a state that can be read by a computer, but require additional libraries (e.g., dynamic link libraries (DLLs)), software development kits (SDKs), application programming interfaces (APIs), etc., to execute the instructions on a particular computing device or other device. In yet another example, machine-readable instructions may need to be set up before the machine-readable instructions and / or corresponding program(s) can be executed in whole or in part (e.g., storing settings, entering data, recording network addresses, etc.). Thus, the disclosed machine-readable instructions and / or corresponding program(s) are intended to encompass such machine-readable instructions and / or programs(s) regardless of the specific format or state of the machine-readable instructions and / or programs(s) at the time of storage or otherwise while stationary or in transition.

[0091]

[0106] As described above, the exemplary processes in Figures 12 to 15 can be implemented using executable instructions (e.g., computer and / or machine-readable instructions) stored in non-temporary computer and / or machine-readable media such as hard disk drives, flash memory, read-only memory, compact disks, digital multipurpose disks, caches, random-access memory, and / or any other storage devices or storage disks, where the information is stored for any duration (e.g., over a long period, permanently, in short instances, temporarily for buffering, and / or for caching information). In this specification, the term non-temporary computer-readable media is explicitly defined to include any type of computer-readable storage device and / or storage disk, and to exclude propagating signal and transmission media.

[0092]

[0107] In this specification, “includes” and “equip” (and all their forms and tenses) are used as unrestricted terms. Therefore, whenever a claim uses any form of “includes” or “equip” (e.g., equip, include, possess, contain, have, etc.) as a preamble or in the description of any type of claim, it should be understood that additional elements, terms, etc., may exist without exceeding the scope of the corresponding claim or description. In this specification, when the phrase “at least” is used, for example, as a transitional clause in the preamble of a claim, it is unrestricted in the same way that the terms “equip” and “include” are unrestricted. The term “and / or” when used, for example, in the form of A, B, and / or C, refers to any combination or subset of A, B, and 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, B and C. In this specification, in the context of describing a structure, component, article, object, and / or thing, the phrase “at least one of A and B” is intended to mean an implementation comprising (1) at least one A, (2) at least one B, and (3) either at least one A and at least one B. Similarly, in this specification, in the context of describing a component, article, object, and / or thing, the phrase “at least one of A or B” is intended to mean an implementation comprising (1) at least one A, (2) at least one B, and (3) either at least one A and at least one B. In this specification, in the context of describing the implementation or execution of a process, instruction, action, activity, and / or step, the phrase “at least one of A and B” is intended to mean an implementation comprising (1) at least one A, (2) at least one B, and (3) either at least one A and at least one B.Similarly, in the context of describing the implementation or execution of a process, instruction, action, activity, and / or step, the phrase “at least one of A or B” is intended to mean (1) at least one A, (2) at least one B, and (3) an implementation comprising either at least one A or at least one B.

[0093]

[0108] The program in Figure 12 begins in block 1202, where an exemplary IO network interface 604 receives IO messages from a wireless device. The wireless device can correspond to any of the controllers 116, 122, 124, 126, 128, 130 and / or any other device communicating with the main server 132 in Figure 1. The IO messages contain IO data corresponding to specific IO parameters monitored by the reporting device. In block 1204, an exemplary event manager 616 processes the IO messages. Further details regarding the implementation of block 1204 are provided below with respect to Figure 13.

[0094]

[0109] In block 1206, the exemplary 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 the most recent value for the parameter stored in the exemplary database 608. The threshold for change can be defined in the configuration data stored in the database 608 for this parameter. In some examples, the threshold can be zero; that is, in some examples, any change in the IO parameter value may suffice. If the exemplary data analyzer 906 determines that the value of the IO parameter has changed by at least a threshold amount (block 1206), the exemplary data analyzer 906 updates the database 608 (block 1208). If the exemplary data analyzer 906 determines that the value of the IO parameter has not changed by at least a threshold amount, there is nothing to update. Therefore, control proceeds to block 1220. In some examples, an event can be triggered based on the fact that a particular IO parameter has not changed beyond a threshold period. In such cases, the control can proceed to block 1210 for further analysis of the IO parameters, rather than proceeding to block 1220.

[0095]

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

[0096]

[0111] In block 1214, the exemplary webpage analyzer 918 determines whether the IO parameter is associated with one or more webpages. That is, the exemplary webpage analyzer 918 determines whether one or more webpages contain content generated based on the value of the IO parameter. In some examples, this is determined based on whether the webpages are subscribed to dynamic updates for the type of data corresponding to the IO parameter. If the IO parameter is associated with one or more webpages, the exemplary webpage analyzer 918 evaluates the web application configured for the IO parameter (block 1216). That is, the webpage analyzer 918 determines whether and how the content generated by the web application changes based on the change in the IO parameter value. Then, in block 1218, the exemplary push service manager 612 pushes updates to all subscribed webpages. Exemplary graphical user interfaces for webpages that can be updated are described below with reference to Figures 21 to 59. In some examples, the update includes adding any newly created video segment to the video event archive webpage 4400, shown with reference to Figure 44 and described later. Control then proceeds to block 1220. Returning to block 1214, if the IO parameter is not associated with any web page, control proceeds directly to block 1220. In block 1220, the program determines whether to continue. If it should continue, control returns to block 1202 to receive and process another IO message. Otherwise, the exemplary program in Figure 12 terminates. Blocks 1214-1218 have described web pages and associated web applications, but in some examples, the main server 132 can implement web pages, web applications, and / or applications that provide a graphical user interface (such as those shown in Figures 21-59) via a display screen independently of the internet.

[0097]

[0112] Figure 13 is a flowchart showing an exemplary implementation of block 1204 in Figure 12. The exemplary program in Figure 13 starts in block 1302, where the exemplary device identifier 902 determines whether the device that received the IO message (block 1202 in Figure 12) is represented in the database 608. If it is not represented, control returns to block 1304, where the exemplary device identifier 902 stores the device name and address in the database 608. In this way, when an operator attempts to configure the device, there is no need to later discover the device on the network. In block 1306, the exemplary configuration engine 904 determines whether to upload all device configuration data from the device. As previously mentioned with respect to Figure 7, the configuration data from the device includes both device identification information 704 and 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 the 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 exemplary program in Figure 13 terminates.

[0098]

[0113] When the configuration engine 904 receives a command to upload device configuration data (block 1306), control proceeds to block 1308, in which the exemplary 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, as well as IO parameter information corresponding to each IO parameter the device is equipped to monitor and / or report. In block 1310, the exemplary configuration engine 904 updates the database 608 with the device configuration data.

[0099]

[0114] In some examples, a device that has received an IO message from but has not yet been commissioned (for example, not represented in database 608) is configured to store generated IO data locally so that it becomes available when the device is commissioned and actively communicates with the main server 132. For example, in some examples, a 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, in which the exemplary configuration engine 904 updates 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 can be omitted. The exemplary program in Figure 13 then terminates. All of the device configuration data stored in the database allows the user to easily access the 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 is commissioned and configured in the manner described above for blocks 1304-1312, the device is represented in database 608, and because block 1302 yields a different result, subsequent IO messages received from the device follow a different path in the exemplary flowchart. That is, returning to block 1302, if the exemplary device identifier 902 determines that the device that received the IO message is represented in database 608, control proceeds to block 1314. In block 1314, the exemplary data analyzer 906 identifies the IO parameters corresponding to the received IO message. In some examples, the data analyzer 906 identifies the IO parameters based on a lookup of the parameter addresses provided in the IO message within the configuration data stored in database 608.

[0101]

[0116] In block 1316, the exemplary parameter value converter 910 determines whether the IO parameter is analog or discrete. If the IO parameter is discrete, the exemplary parameter value converter 910 converts the value of the IO parameter into state text or other context-specific state indicators (block 1318). That is, instead of a binary value of 0 or 1, the exemplary parameter value converter 910 can convert the value into a state based on the text represented by the value (e.g., On, Off, Opened, Closed, etc.) or into 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 exemplary parameter value converter 910 determines that the IO parameter is analog (block 1316), control proceeds to block 1320, in which the exemplary parameter value converter 910 converts the value of the IO parameter into descriptive text or other context-specific descriptive indicators. Similar to block 1318, the conversion in block 1320 is intended to convert the IO parameter value into a human-readable indicator 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 end-user-readable image, number, or icon. For some analog-based values, the parameter value converter 910 can also apply one or more conversion factors with respect to the generation of the descriptive indicator. In some examples, blocks 1316-1320 can be omitted, and therefore the IO parameter value is not converted into a context-specific indicator. In block 1322, the exemplary time stamper 908 timestamps the value of the IO parameter at the time of receipt of the IO message. That is, in the example described, the time stamper 908 stores the time of receipt of the IO message, along with the reported IO parameter value, in the exemplary database 608. The exemplary program in Figure 13 then terminates and returns to complete the process in Figure 12.

[0102]

[0117] Figure 14 is a flowchart showing an exemplary implementation of block 1212 in Figure 12. The exemplary program in Figure 14 starts in block 1402, where the exemplary event analyzer 912 evaluates the event rules associated with the IO parameter. In 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, in block 1406, the exemplary notification engine 916 generates a notification about the triggered event. In block 1408, the notification engine 916 sends the notification to the recipient associated with the triggered event. In some examples, the recipient is stored in database 908 as configuration data associated with the event.

[0103]

[0118] In block 1410, the exemplary event logger 914 updates the event log in 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 that reports the parameter value, and a timestamp (indicating when the event was detected or triggered) when the parameter value was received. In block 1412, the exemplary event analyzer 912 determines whether the event corresponds to a video capture event. 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 before and after a trigger event. In that case, in block 1414, the event analyzer 912 requests the 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, in block 1416, the exemplary notification engine 916 sends a second notification with the video segment attached 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), which is defined by the configuration data assigned to the event that generated the notification.

[0104]

[0119] After sending the second notification (block 1416), control proceeds to block 1418. Returning to block 1412, if the exemplary event analyzer 912 determines that the event does not correspond to a video capture event, control proceeds directly to block 1418. In block 1418, the exemplary 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 returns to block 1402. Otherwise, the exemplary process in Figure 14 terminates.

[0105]

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

[0106]

[0121] Figure 15 is a flowchart showing an exemplary program for implementing the video management system 614 on the main server 132. Alternatively, the exemplary program in Figure 15 can be implemented independently of the main server 132 by the video management system 506 in Figure 5. The exemplary program in Figure 15 begins in block 1502, in which the exemplary video segment generator 804 identifies trigger events in the event log associated with pending video capture events. As previously mentioned with respect to block 2810 in Figure 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 way, the video management system 614 can automatically start the process of generating video segments without receiving a request from the event manager 616 as previously mentioned.

[0107]

[0122] In block 1504, the exemplary video segment generator 804 determines whether a threshold period has elapsed for a camera (e.g., camera 508) to capture video. If the threshold period has not elapsed, control remains in 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 a specific identified event. For example, if the post-event time interval is defined as 1 minute, the video segment generator 804 waits at least 1 minute after detecting an event before proceeding. As mentioned above, in some examples, the post-event time interval cannot begin until events are no longer triggered (or a second event is detected indicating that the condition that triggered the first event is no longer applicable). In some examples, the threshold period also includes a post-processing period to compensate for the time delay required for the camera to capture, encode, and store the video stream corresponding to the desired video segment.

[0108]

[0123] After a threshold period has elapsed, the video segment generator 804 extracts video segments within a time window before and after the trigger event (block 1506). In some examples, the start and end times for video segments are defined by the pre-event and post-event time intervals set for events stored in the exemplary database 608. In some examples, the extracted video segments are stored in the video database 808. In block 1508, the exemplary video segment generator 804 converts the video segments to a web-readable format and creates thumbnails with a thumbnail offset time set by the user. In some examples, the web-readable format is the MP4 format. The thumbnail offset time defines the point in the video segment when 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 event time so that, if the offset is set to 0 seconds, a thumbnail corresponding to the video frame captured at the time the event is detected is obtained. The thumbnail offset time can be set to any point in 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 the thumbnail is likely to represent the effect 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 the thumbnail is likely to capture the person or situation that ultimately triggers the event.

[0109]

[0124] In block 1510, the exemplary video analyzer 806 determines whether an event is set up for computer vision analysis. If an event is set up 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 from camera 508. Vision-based events are useful when it may be difficult or impossible to set up sensors to directly detect an event. Some exemplary vision-based events include certain safety events such as collisions and / or near misses between a person and / or material handling equipment moving around material handling equipment 100. As an example, the video analyzer 806 may determine that a moving vehicle (e.g., a forklift) has entered within a few inches of a person working in the area. In such an example, if there is no collision, damage, or injury, it is unlikely that the parties will report the event (whether or not they are even aware of its occurrence), making it difficult to reduce the occurrence of such a potentially dangerous situation. However, by using the video analysis disclosed herein, these events can be detected and automatically captured by the camera. In other examples, image analysis may include facial recognition analysis to identify individuals captured in a video segment. In block 1514, the video analyzer 806 updates the event log with events based on identified vision. Control then proceeds to block 1516. If the exemplary video analyzer 806 determines that the event is not set up for computer vision analysis (block 1510), control proceeds directly to block 1516.

[0110]

[0125] In block 1516, the exemplary push service manager 612 pushes instructions to all subscribed web pages where video segments are available. In block 1518, the exemplary network communication interface 602 sends a notification with a video segment attached to the recipient. In block 1520, the exemplary video segment generator 804 determines if there are any other pending video capture events. If there are, 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 and analyzing video segments can be implemented for multiple cameras for a single trigger event. If the exemplary video segment generator 804 determines that there are no pending video capture events (block 1520), the exemplary process in Figure 15 terminates.

[0111]

[0126] By aggregating data from various controllers 116, 122, 124, 126, 128, 130 and / or servers 134, 136 in the main server 132, the main server 132 becomes capable of detecting configurable events occurring in any mode of operation of the material handling equipment 100 in Figure 1. Furthermore, the main server 132 can initiate specific actions and / or responses based on the detection of system-defined events. As illustrated with the flowcharts in Figures 12 to 15, actions initiated by the main server 132 include generating a notification to be 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). Furthermore, the main server can automatically generate a report and / or update a log of detected events based on the analysis of the data aggregated by the main server 132. In addition or by alternative means, as described above, the main server 132 may integrate the collected data and display the current data relating to some aspect of the conditions and / or operation of the material handling equipment 100 through various web pages and / or web applications hosted by the web server 146. In some examples, such web pages are dynamically updated, and the current data is provided to client devices 148 accessing a particular web page in substantially real time. In addition or by alternative means, the main server 132 may generate one or more graphical user interfaces for rendering via a display, independently of the web pages and / or associated web applications.

[0112]

[0127] In some examples, different graphical user interfaces (whether provided via a web page or otherwise) may consist of different types of information corresponding to different aspects of the material handling equipment 100 that a particular user may be interested in. Furthermore, Figures 21 to 59, described later, show exemplary graphical user interfaces for several exemplary web pages hosted by the web server 146. Although Figures 21 to 59 are described as web pages, in other examples, the same or similar graphical user interfaces may be generated not by a web application, but by an application for on-screen display independent of the web page.

[0113]

[0128] As described above, each of the controllers 116, 122, 124, 126, 128, and 130 can implement the same or similar functions as the main server 132 based on a limited set of I / O data collected by each specific controller (and additional data provided by the main server). Schematics representing exemplary hardware logic, machine-readable instructions, hardware-implemented state machines, and / or any combination thereof for implementing the local controller 1100 in Figure 11 (representing any one of the controllers 116, 122, 124, 126, 128, and 130 in Figure 1) are shown in Figures 16 to 20. The machine-readable instructions may be one or more executable programs or parts(s) of executable programs for execution by a computer processor, such as the processor 6112 shown in the exemplary processor platform 6100 discussed below with respect to Figure 61. The program can be implemented as software stored on a non-temporary computer-readable storage medium such as a CD-ROM, floppy disk, hard drive, DVD, Blu-ray disc, or memory associated with the processor 6112. Alternatively, the entire program and / or parts of the program can be executed by a device other than the processor 6112, and / or by firmware or dedicated hardware. Furthermore, the exemplary program will be described with reference to the flowcharts shown in Figures 16 to 20, but alternatively, a number of other methods can be used to implement the exemplary local controller 1100. For example, the execution order of these blocks can be changed, and / or some of the described blocks can be modified, removed, or combined. In addition or alternatively, any or all of the blocks can 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 described above, the exemplary processes in Figures 16 to 20 can be implemented using executable instructions (e.g., computer and / or machine-readable instructions) stored in non-temporary computer and / or machine-readable media such as hard disk drives, flash memory, read-only memory, compact disks, digital multipurpose disks, caches, random access memory, and / or any other storage devices or storage disks, where the information is stored for any duration (e.g., over a long period, permanently, in short instances, temporarily for buffering, and / or for caching information).

[0115]

[0130] The exemplary program in Figure 16 begins in block 1602, where the exemplary data analyzer 1104 monitors the collected data. In some examples, the collected data includes I / O data provided by equipment and / or associated sensors controlled and / or monitored by the controller 1100. In addition or alternatively, the collected data may include information received from the main server 132. In block 1604, the exemplary data analyzer 1104 identifies the I / O parameters associated with the collected data. In block 1606, the exemplary parameter value converter 1108 determines whether the I / O parameters are analog or discrete. If the I / O parameters are discrete, the exemplary parameter value converter 1108 converts the values ​​of the I / O parameters into state text or other context-specific state indicators (block 1608). That is, instead of a binary value of 0 or 1, the exemplary parameter value converter 1108 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 1612. If the exemplary parameter value converter 1108 determines that the IO parameter is analog (block 1606), control proceeds to block 1610, in which the exemplary parameter value converter 1108 converts the value of the IO parameter to descriptive text or other context-specific descriptive indicator, and then control proceeds to block 1612. Similar to block 1608, the conversion in block 1610 is intended to convert the IO parameter value to a human-readable indicator based on the context represented by the IO parameter value. In some cases, the descriptive indicator may be a text-based description and / or an image, number, or icon that is easily understood by the end user. For some analog-based values, the parameter value converter 1108 may also apply one or more conversion factors to the generation of the descriptive indicator.In some cases, blocks 1606-1610 can be omitted, and therefore the IO parameter values ​​are not converted to context-specific indicators.

[0116]

[0131] In block 1612, the exemplary event analyzer 1106 determines whether the value of an IO parameter triggers an event. In some examples, an event can be triggered based on several different parameters having a specific value and / or satisfying a specific threshold, based on event rules stored in the exemplary database 1112. Thus, in some examples, the determination in block 1612 is made based on an analysis of several IO parameters monitored by the data analyzer 1104. If an event is triggered, control proceeds to block 1614, where the exemplary event analyzer 1104 determines whether the triggered event is associated with the operation of the equipment. That is, when an event identified by the main server 132 relates to updates to web pages and / or other graphical user interfaces and / or changes in data for generating notification information for a specific individual of the event, the local controller 1100 is implemented to control equipment within the material handling equipment 100, and therefore the event monitored by the exemplary event analyzer 1106 is associated with the operation of such equipment. If the trigger event is associated with an operation of the device, control proceeds to block 1616, where the exemplary device controller 1116 implements the operation. Control then proceeds to block 1618. If the trigger event is not associated with an operation of the device (block 1614), control proceeds directly to block 1618.

[0117]

[0132] In block 1618, the exemplary event analyzer 1106 determines whether a trigger event is associated with a notification. If the trigger event is associated with a notification, control proceeds to block 1620, where the exemplary notification engine 1110 generates a notification about the trigger event. In block 1620, the exemplary notification engine 1110 draws the notification on a display. In some examples, the display corresponds to display 1114 associated with the local controller 1100. In other examples, the notification may be drawn on a display that is separate from but nearby the local controller 1100. In block 1624, the exemplary communication board 133 transmits the notification to the main server 132. In some examples, the notification drawn on 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 contain different information. In some examples, blocks 1622 or 1624 can be omitted, and therefore the notification generated in block 1620 is drawn via the display or transmitted to the main server 132.

[0118]

[0133] In block 1626, the exemplary data analyzer 1104 determines whether the IO parameter has triggered another event. If the IO parameter has triggered another event, control returns to block 1614. Otherwise, control proceeds to block 1628. Returning to block 1612, if the exemplary event analyzer 1106 determines that the value of the IO parameter does not trigger an event, control proceeds directly to block 1628. Similarly, if the exemplary event analyzer 1106 determines that the trigger event is not associated with a notification, control proceeds directly from block 1618 to block 1628. In block 1628, the exemplary data analyzer 1104 determines whether there is another IO parameter. If there is another IO parameter, control returns to block 1608. Otherwise, control proceeds to block 1630, where the process determines whether it should continue. If it should continue, control returns to block 1602. Otherwise, the exemplary process in Figure 16 terminates.

[0119]

[0134] Figure 16 shows an exemplary general process flow that can be implemented by any one of the controllers 116, 122, 124, 126, 128, and 130 of Figure 1, while Figures 17–19 provide specific exemplary processes outlining specific event rules and / or actions that can be implemented by the dock controller 116 in response to the detection of a specific event associated with the corresponding dock 102. Furthermore, Figure 20 provides a specific exemplary process outlining specific event rules and / or actions that can be implemented by the door controller 122 in response to the detection of a specific event associated with a door in the material handling facility 100. Alternatively, since the dock 102 includes a door 104, the exemplary process in Figure 20 can be implemented by the dock controller 116. For illustrative purposes, the implementation forms of the exemplary processes in Figures 17–20 will be described with reference to the local controller 1100. However, since the I / O data collected by the various controllers 116, 122, 124, 126, 128, and 130 is aggregated by the main server 132, the exemplary processes can also be implemented by the main server 132, either additionally or alternatively.

[0120]

[0135] The exemplary process in Figure 17 begins in block 1702, where the exemplary data analyzer 1104 monitors dock data. As previously stated, Figure 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 I / O data received via the exemplary communication interface 1102 from equipment and / or sensors communicably coupled to the dock controller 116, as well as any data received from the main server 132 via the exemplary communication board 133. In block 1704, the exemplary event analyzer determines whether the dock data indicates that a truck / trailer (e.g., trailer 300 in Figures 3 and / or 4) is present in dock 102. Different types of dock data can be used to make this determination. In some examples, dock data indicating such content is based on feedback from the trailer sensor 202. Additionally or otherwise, the presence of trailer 300 can be inferred based on the fact that the vehicle restraint device 110 is in the engaged position and / or that the dock leveler 108 is deployed and active. Additionally or otherwise, the presence of trailer 300 can be determined based on information received from the main server 132, which transmits information indicating a message sent (via client device 148) by a truck driver reporting that trailer 300 has been parked in the designated dock 102.

[0121]

[0136] If the event analyzer 1106 determines that the trailer is not present in dock 102, control proceeds to block 1706, in which the exemplary event analyzer 1106 determines whether dock data indicates that a door (e.g., door 104) is in an open state (e.g., based on feedback from a door sensor). If the door is in an open state, control proceeds to block 1708, in which the event analyzer 1106 determines whether an entrance / exit barrier (e.g., barrier 106) is available at the dock. If the entrance / exit barrier is not available, control proceeds to block 1712, in which the exemplary notification engine 916 generates a notification indicating a potential fall hazard. In some examples, the generation of the notification may involve drawing the notification via a local screen on the controller 116, such as a display screen 117. In addition or by alternative means, generating a notification may involve transmitting the notification to the main server 132 to distribute the notification to specific recipients, and / or drawing a notification and / or graphics indicating the notification via one or more such web pages and / or other graphical user interfaces. As previously stated, in some examples, the exemplary process in Figure 17 may be independently implemented so that the main server 132 determines whether it is necessary to generate this notification 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 entrance / exit barrier 106 is available, control proceeds to block 1710. In block 1710, the exemplary event analyzer 1106 determines whether the dock data indicates that the entrance / exit barrier 106 is blocking the opening in the entrance / exit (because, according to the determination in block 1704, the door is in an unclosed state). If the entrance / exit barrier 106 is blocking the opening, there is no need to generate a notification because the barrier 106 acts as protection from the risk of falling. Therefore, control proceeds directly to block 1714. However, if barrier 106 does not prevent the opening, control proceeds to block 1712 and generates the aforementioned notification.

[0122]

[0137] In block 1714, the exemplary event analyzer 1106 determines whether the dock data indicates that no trailer is assigned to the dock. In some examples, this determination is based on dock assignment information provided from the main server 132 to the dock controller 116, which can receive information from a dock management system (e.g., dock management system 502). If no trailer is assigned to the dock (but the determination in block 1704 detects the presence of a trailer), control proceeds to block 1716, where the exemplary notification engine 1110 generates a notification indicating that 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 exemplary event analyzer 1106 determines whether the dock data indicates that a vehicle restraint device (e.g., vehicle restraint device 110) is in override mode. If the vehicle restraint device is in override mode, control proceeds to block 1720, where the exemplary equipment controller 116 switches an external light indicator (e.g., light indicator 206) to a state (e.g., red light) indicating that the truck trailer should not be moved. In block 1722, the exemplary event analyzer 1106 determines whether the dock data indicates that the truck trailer is no longer in the dock. If the truck trailer is no longer in the dock, control proceeds to block 1724, where the exemplary notification engine 1110 generates a notification indicating a potential withdrawal with a red light. Control then proceeds to block 1726. If the trailer is still in the dock (block 1722), control proceeds directly to block 1726. In block 1726, the exemplary process determines whether it should continue. If it should continue, control returns to block 1702. Otherwise, the exemplary process in Figure 17 terminates.

[0124]

[0139] The exemplary process in Figure 18 begins in block 1802, where the exemplary data analyzer 1104 monitors dock data. In block 1804, the exemplary event analyzer 1106 determines whether the dock data indicates that activity has been detected within the truck trailer. In some examples, this determination is based on feedback from an exemplary motion sensor 204 that monitors movement within the trailer 300. If activity is detected within the trailer, control proceeds to block 1806, where the exemplary event analyzer sets the timer to zero. Control then returns to block 1802. If no activity is detected within the trailer 300, control proceeds to block 1808, where the exemplary event analyzer 1106 determines whether the timer has started. If it does not determine that the timer has started, the event analyzer 1106 starts the timer in block 1810. Control then proceeds to block 1812. If the determination in block 1808 indicates that the timer has already started, control proceeds directly to 1812. In block 1812, the exemplary event analyzer 1106 determines whether the timer has exceeded a threshold (e.g., 5 minutes, 10 minutes, 15 minutes, or a time set or calculated based on data specific to the cargo, carrier, and / or equipment). If the timer has exceeded the threshold, control proceeds to block 1814, where the exemplary notification engine 1110 generates a notification indicating that there is no activity in 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 exemplary process determines whether it should continue. If it should continue, control returns to block 1802. Otherwise, the exemplary process in Figure 18 terminates.

[0125]

[0140] The exemplary process in Figure 19 begins in block 1902, where the exemplary data analyzer 1104 monitors dock data. In block 1904, the exemplary event analyzer 1106 determines whether the dock data indicates user activation of a manually initiated (i.e., selectively initiated) actuator. A manually initiated actuator can be activated by the user based on the user pressing a button, selecting an option on a touchscreen, and / or any other preferred means. As a specific example, the user may request to open or close a door 104, move a vehicle restraint device 110 to an engaged or disengaged position, and / or extend a leveler 108 to an active position or retract it to a retracted 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 exemplary event analyzer 1106 determines whether the operation associated with the actuator is prevented by the interlocking relationship. The interlocking relationships can respond to specific actions that the user intends to implement. For example, the opening of a door can be interlocked or adjusted by the presence of the trailer 300 and / or the engagement of the vehicle restraint device 110 with the trailer 300. That is, the opening of the door is prevented until the presence of the trailer 300 and / or the engagement of the restraint device 110 is detected. Furthermore, the operation of the leveler 108 can also be interlocked or adjusted by the door 104. That is, the leveler can only be activated when the door 104 is opened. These interlocking relationships ensure that the correct sequence of operations is followed in order to maintain safety in the dock. If the event analyzer 1106 determines in block 1906 that there are no interlocking relationships preventing an operation, control proceeds to block 1908, where the equipment controller 1116 implements the operation associated with the actuator. Control then proceeds to block 1912.

[0126]

[0141] If a user attempts to implement a particular action in the wrong order, or if the interlock prevents the action for any other reason, the interlock will prevent the action from being performed. This ensures the safety of the user and any other personnel involved, while the user's attempt to implement the action may indicate that the user does not understand the correct sequence of actions and / or is simply ignoring the correct sequence. This may indicate that the user needs training. However, because of the interlock, there is no way to track this behavior and make the user aware of such a need, since nothing actually happens as a result of the user attempting to start the actuator. However, the examples disclosed herein overcome this challenge as well. In particular, when the event analyzer 1106 determines that an action has been prevented due to the interlock, control proceeds to block 1910, in which the exemplary notification engine 1110 generates a notification indicating an improper start of the action. In some examples, such events can be logged and tracked over time (for example, by the main server 132) to determine whether the event was a separate incident or a recurring problem, allowing the dock administrator or other staff to identify the potential need to provide training to anyone attempting to implement behavior different from established procedures. Control then proceeds to block 1912, where it is determined whether the exemplary process should continue. If it should continue, control returns to block 1902. Otherwise, the exemplary process in Figure 19 terminates.

[0127]

[0142] The exemplary process in Figure 20 begins in block 2002, where the exemplary data analyzer 1104 monitors dock data. In block 2004, the exemplary event analyzer 1106 detects a door cycle in which door 104 opens and then closes again. In block 2006, the exemplary 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 exemplary notification engine 1110 generates a notification indicating a malfunction of door 104. Control then proceeds to block 2010. In block 2010, the exemplary process determines whether to continue. If it should continue, control returns to block 2002. Otherwise, the exemplary process in Figure 20 terminates.

[0128]

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

[0129]

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

[0130]

[0145] The exemplary dock and yard summary block 2102 provides a summary of the number and location of trailers currently parked in dock 102 of the material handling facility 100. The dock and yard summary block 2102 may include an indication of the number of active alarms and / or associated events triggered in relation to dock 102 and / or associated loading and unloading of trailers in the dock. In some examples, the dock and yard summary block 2102 further provides links to one or more other web pages, such as those shown later in Figures 23–43 and 47–50.

[0131]

[0146] The exemplary 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 if the material handling equipment 100 includes one or more cold storage rooms. In some examples, the energy summary block 2104 provides an indication of the amount of energy consumed against a threshold to show 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 rooms (monitored and controlled by the corresponding door controller 122 in Figure 1) are being opened for too long and / or too frequently, potentially resulting in energy loss. In some examples, these scenarios are associated with configurable events and / or alarms that can be triggered. In some such examples, the energy summary block 2104 includes an indication of the number of triggered active alarms and / or associated events. In some examples, the energy summary block 2104 provides links to one or more other web pages that provide additional details about the freezer, the door associated with the freezer, and / or other items related to energy consumption within the material handling equipment 100, such as the exemplary web pages shown later in Figures 45 and 46.

[0132]

[0147] The exemplary safety summary block 2106 provides a summary of detected events and / or alerts that indicate safety conditions and / or potential safety risks. Safety events may relate to the unloading and loading of trailers at dock 102 (for example, whether or not the vehicle restraint device 110 secures the trailer in place), and / or the movement and handling of materials within the material handling equipment 100 (for example, 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 later in Figures 50-56.

[0133]

[0148] The exemplary maintenance and asset management summary block 2108 provides a summary of information relating to the maintenance, repair, and / or warranty of equipment assets used in the material handling facility 100. In some examples, the maintenance and asset management summary block 2108 further provides links to one or more other web pages, such as those shown later in Figures 57-59.

[0134]

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

[0135]

[0150] Figure 22 is another exemplary graphical user interface presented by an overview webpage 2200 that provides summary information associated with the operation and / or conditions of material handling equipment 100, which may be of interest to a particular user. Similar to the overview webpage 2100 in Figure 1, the exemplary overview webpage 2200 in Figure 22 includes exemplary dock and yard summary blocks 2202, exemplary energy summary block 2204, exemplary safety summary block 2206, and exemplary maintenance and asset management summary block 2208. As shown in the example described in Figure 22, summary blocks 2202, 2204, 2206, and 2208 show information similar to the summary blocks 2102, 2104, 2106, and 2108 in Figure 21 described above. Furthermore, by selecting a particular summary block from the summary blocks 2202, 2204, 2206, and 2208 in Figure 22, the user can be directed to other webpages that provide more detailed information.

[0136]

[0151] Figure 23 shows an exemplary graphical user interface presented by the exemplary dock monitoring webpage 2300. As shown in the example described, the dock monitoring webpage 2300 includes an exemplary current period summary block 2302, an exemplary historical usage summary block 2304, and an exemplary historical loading time summary block 2306. The exemplary current period summary block 2302 presents the number of incoming and outgoing trailers scheduled to be loaded and / or unloaded during the current period (e.g., today), the number of incoming and outgoing trailers that have completed loading and / or unloading, and the number of trailers that are currently loading or unloading. Furthermore, the exemplary current period summary block 2302 provides an indication of the progress of all trailers for the current period. Exemplary historical usage summary block 2304 and Exemplary historical loading time summary block 2306 provide indications of dock usage within the material handling facility 100, as well as indications of the average time taken to load and / or unload trailers over a specified historical period (e.g., the previous day, last week, last month, individual period). In some examples, the historical period can be selected by the user. Furthermore, as shown in the described example, the dock monitoring webpage 2300 provides a table 2308 containing usage and loading times for individual docks within the material handling facility 100.

[0137]

[0152] Figure 24 shows an exemplary graphical user interface presented by an exemplary dock monitoring webpage 2400. As shown in the examples described, the dock monitoring webpage 2400 includes a set of graphics, icons, and / or associated information representing the conditions of a set of docks 102 of the material handling facility 100, which are determined based on data collected by the main server 132 from the dock controller 116 and / or other devices communicating with the main server 132. For example, when a trailer sensor 202 detects and / or generates a signal indicating the presence of a trailer in a corresponding dock, a trailer icon 2402 is shown for the corresponding dock in the dock monitoring webpage 2400. In some examples, next to the trailer icon 2402 (for example, above the trailer icon identified by a cargo identification reference 2403 shown for the ninth dock in Figure 24), a carrier code, carrier name, cargo number, and trailer number may also be identified. The trailer icon 2402 or cargo identification reference 2403 can be an active link, and when selected, it redirects to or opens another webpage or window / popup containing information related to a particular cargo. As shown in Figure 24B, symbols / icons adjacent to the cargo identification reference can function similarly. In some examples, after a trailer is detected or verified at a particular dock (for example, based on feedback from the trailer sensor 202), the main server retrieves carrier and trailer number information collected from the driver (as described later) and pushes that information to the dock monitoring webpage 2400 for rendering. Alternatively, this can be done when assigning a trailer to a particular loading dock.

[0138]

[0153] Whether the tractor unit icon 2406 is represented together with the trailer icon 2402 may be based on feedback from separate sensors and / or input provided by the truck driver or carrier when checking in, regarding whether the trailer (e.g., the monitored trailer in dock 4 in Figure 24) is being delivered or whether the trailer is actually being loaded / unloaded (e.g., the trailer in dock 3 in Figure 24). In situations where the trailer is not actively being loaded or unloaded (whether it is a delivered or monitored load or an actual load), the corresponding dock (e.g., dock 12 in the described example) may be shown with a parked trailer icon 2404 along with a “parked” indicator or trailer stand icon. In some examples, logistics personnel assign a specific name to the parked trailer which may be shown next to the parked trailer icon 2404.

[0139]

[0154] In some examples, the refrigeration indicator 2401 is associated with the trailer icon 2402, corresponding to the refrigerated or temperature-controlled cargo. In the examples described, the temperature control indicator 2401 is a snowflake, but it 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 blue or red bars, outlines, and / or fills. In some examples, the dock monitoring webpage 2400 for the temperature control indicator 2401 also displays the trailer's current temperature indicator 2405 based on feedback from temperature sensors for each trailer. In some examples, the current temperature indicator 2405 can function as the temperature control indicator 2401. In some examples, the main server 132 monitors the current temperature against threshold temperatures or upper and lower thresholds of a temperature range. If the temperature exceeds or falls below a threshold temperature, or falls outside that range, the main server can generate an alarm or notification to the dock manager at the logistics office indicating that the trailer temperature in the designated dock has exceeded or fallen below the threshold, or has fallen outside the acceptable range. Monitoring the temperature in this way helps the dock manager maintain a cold chain for unloading products from the trailer. In some examples, the temperature 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 made accessible via an exemplary dock monitoring webpage 2400.

[0140]

[0155] In some examples, a driver arriving at the facility in a trailer for loading and / or unloading may check in at a kiosk corresponding to one of the client devices 148 in Figure 1, which provides access to an exemplary driver check-in webpage 2500 shown in Figure 25. That is, in some examples, the kiosk comprises a client device 148 maintained by an operator of the material handling facility 100. In addition or alternatively, the driver may access the driver check-in webpage 2500 using their own smartphone or other portable device (for example, corresponding to a different client device 148). In some examples, as shown in Figure 25, the driver may provide a mobile phone number, which is then used to transmit text messages to the driver for providing instructions and / or indicating the loading and / or unloading status of the truck. For example, the driver may complete the entry fields shown in the example described in Figure 25. In the case of a refrigerated or temperature-controlled trailer, as shown in the example described, the driver may be prompted to enter the current temperature of the trailer. Another exemplary driver check-in webpage 2600 is shown in the example described in Figure 26.

[0141]

[0156] After the driver submits the information, the main server 132 may generate a first notification directly on the web page confirming that the check-in information has been received and sent to the logistics office. This notification may further instruct the driver to check the dock status page for dock assignment. In addition or by alternative means, if the driver has included a mobile phone number, the main server 132 may transmit a command and / or confirmation via text message acknowledging receipt of the check-in information and indicating that the next text message containing dock assignment will be sent.

[0142]

[0157] In addition to providing a confirmation notice 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 staff) of the logistics office of the new arrival and the need for a new dock assignment. In some examples, this notification is a check-in popup 2407 that appears on the dock monitoring webpage 2400 in Figure 24, along with the information and options for a user (e.g., a dock manager) to assign a truck to a specific dock. If the user chooses to assign a dock, a dock assignment webpage 2700 may appear, as shown in Figure 27, along with a dock assignment popup 2702 that provides a list of available docks. In some examples, the list of available docks corresponds to docks that are not aware of the presence of the trailer and are not otherwise scheduled for different trucks.

[0143]

[0158] In some cases, after a truck has been assigned to a specific dock, information can be relayed back to the driver via driver check-in web pages 2500, 2600 and / or other similar web pages. In some such cases, equipment-related information that may be relevant to the driver (e.g., instructions that the dock is cold, estimates 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 the web page for driver review. Thus, in some cases, according to the teachings of this 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 in Figure 24, the notification to the dock manager that a trailer needs to be assigned to a dock may include a visual indicator other than an automatic pop-up, such as a bell icon 2408 that lights up, becomes visible, and / or changes its appearance in other ways. In some such examples, when the user selects the bell icon 2408, a dock and trailer queue pop-up 2800 containing check-in information may appear on the assignment tab, as shown in Figure 28. In some examples, if the trailer temperature entered by the driver exceeds a certain temperature threshold, the pop-up 2800 may include an overheating warning for the trailer. In addition or alternatively, the main server 132 may transmit a separate notification to the dock manager and / or shipping and receiving manager reporting the overheating of the trailer, allowing the problem to be addressed, for example, by refusing shipment. In some examples, the assignment tab of the dock and trailer queue pop-up 2800 includes a drop-down selector 2802 that lists only the docks available for assignment. In other words, the dropdown selector 2802 should not list docks that have already been assigned a trailer from among the dock monitoring webpage 2400. As previously stated, the main server 132 determines whether a trailer is associated with a particular dock based on trailer sensors and / or any other sensors or devices associated with the dock (e.g., where the vehicle restraint device is engaged). Thus, as can be seen, the main server can streamline dock management by collecting data and analyzing data obtained from heterogeneous locations. This is only possible in the technical environment of the material handling facility disclosed herein, where sensors in the docks are monitored by the respective dock controllers 116, which report to the main server 132, and the server can also receive network communications from drivers providing check-in information and transmit the collected information to logistics personnel to determine where to assign a new truck.

[0145]

[0160] After a specific dock is selected and assigned to a trailer, the main server 132 can generate a timestamp for that action and generate multiple notifications, which are transmitted to appropriate recipients and update the appropriate web page interface. For example, the first notification can be displayed on a web page viewed by the logistics personnel who performed the dock assignment to confirm that the trailer has been assigned. Separately, the main server 132 can transmit details associated with the trailer regarding 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. Furthermore, in some examples, the main server 132 can transmit another text message to the truck driver indicating the assigned dock. In some examples, the text message may include the direction the dock is located, a timestamp indicating the check-in time, and / or any other suitable information (e.g., the scheduled reservation time). In some examples, the main server 132 updates the dock monitoring web page 2400. In particular, once a dock is assigned, it may take a short time for the truck driver to move the trailer to its designated position in the dock. Therefore, in some examples, instructions such as the message 2410 "Waiting for trailer" shown in the second dock in Figure 24 are provided to indicate that the dock has been allocated but the trailer has not yet arrived. After the trailer is detected, the main server 132 updates the dock monitoring webpage 2400 again to display the trailer icon 2402. In some examples, a second timestamp is generated when the trailer is first detected. In this way, the time between the initial check-in (e.g., dock allocation) and the actual arrival of the trailer at the dock can be monitored. This facilitates the appropriate determination of late fees imposed by the owner of the material handling facility.

[0146]

[0161] A trailer may be positioned in a dock to which it was not assigned. In some such cases, if a trailer is detected in a dock but no trailer is assigned to that dock, the main server 132 may generate an alarm and display an indicator 2412 that says "Not Assigned," as shown in the example illustrated in Figure 24 for dock 8. In some cases, the indicator 2412 may flash to draw the attention of logistics workers regarding the trailer being in the wrong dock. In some cases, the flashing may stop after the worker has acknowledged the alarm and / or has cleared or avoided the alarm in other ways. In some cases, additional actions may be taken when a trailer is detected in a dock that is not assigned to accept trailers. For example, dock doors may be interlocked to prevent them from being opened as a security measure. Additionally or alternatively, the alarm signal in the dock may be activated to notify the driver and / or other personnel in the dock where the trailer should not be. As described above, the alarm signal can be turned off when a person acknowledges the alarm, dismisses the alarm, avoids the alarm, and / or responds to the alarm in any other way.

[0147]

[0162] In some examples, after the trailer is positioned in the correct dock, the vehicle restraint device 110 is activated to fix the trailer in place. Whether the vehicle restraint device 110 is active (engaged with the trailer), in an overridden state, or in a stowed state (not engaged with the trailer) can be represented by a restraint signal icon 2414 on the exemplary dock monitoring webpage 2400. In some examples, the restraint signal icon 2414 matches and / or is similar to the light indicator 206 shown in Figure 2, providing a red light (e.g., red light) whenever the restraint signal indicates that the vehicle restraint device 110 is active or in overridden mode, and a blue light (e.g., green light) when the vehicle restraint device is not active or in the stowed position. In some examples, an event rule can trigger an alarm in the case of the first dock on the exemplary dock monitoring webpage 2400 in Figure 24 when the presence of a trailer is detected in a particular dock, but the vehicle restraint device 110 is not active and not engaged with the trailer. In such examples, the alarm icon 2416 can be displayed next to the corresponding dock. In some examples, when a user (e.g., a logistics worker) clicks the alarm icon 2416, additional details about the trigger event associated with the alarm can pop up. In some examples, a video segment captured in relation to the event can pop up and start playing automatically.

[0148]

[0163] In the example illustrated in Figure 24, the dock monitoring webpage 2400 includes a door icon 2418 to indicate whether a door 104 in a corresponding dock is closed (for example, represented in the first and second docks shown in Figure 24) or open (for example, represented in the third and fourth docks shown in Figure 24). In some examples, a door 104 is represented as open as long as it is at least partially open (for example, not closed). Whether a door is closed or open (for example, 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 (for example, from a forklift operator or another person near the door), a sensor associated with the door 104 (for example, a limit switch) may generate an output indicating that the door is open. After the dock controller 116 receives this sensor feedback, it transmits a network communication (e.g., an IO message) to the main server indicating that the door is open. Upon receiving such a message, the main server 132 updates the dock monitoring webpage 2400 (e.g., via push notifications to all active instances of the webpage that subscribe to such information), and the door icon 2418 then indicates that the door in the corresponding dock is open. Almost 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 workers moving around within the trailer). In some examples, when the motion sensor 204 detects the presence of workers 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 update the dock monitoring webpage 2400 again to include a forklift icon 2420 within an open door icon 2418 (shown in relation to the fifth dock in Figure 24) to indicate that a person has been detected inside the trailer. In some examples, if no movement is detected inside the trailer over a threshold period, the main server 132 may infer that no one is working inside the trailer and therefore remove the forklift icon 2420.

[0149]

[0164] Furthermore, in some examples, when sensor feedback associated with barrier 106 in Figures 1 to 4 indicates that the barrier is actively in use at the door entrance, a barrier icon 2422 can be drawn on the door icon 2418 corresponding to the door. The barrier icon 2422 can be drawn when the door icon 2418 indicates that the door is closed (dock 6 in Figure 24) or when the door is open (dock 9 in Figure 24).

[0150]

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

[0151]

[0166] In addition or by alternative means, 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 loading / unloading time set for the expected duration for loading and / or unloading the trailer. In the example described, the threshold time is set to a default duration of 2 hours. However, in other examples, the threshold loading / unloading time may be different. Furthermore, in some examples, different threshold loading / unloading times can 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 remains in the driver's current working hours) and / or loading-related information (e.g., how much material is loaded onto the truck to be unloaded) that can be used to adjust the threshold time. In some examples, the threshold time can be automatically adjusted based on such driver input. In other examples, such driver input may be provided to a dock manager to assess whether the threshold time for a particular truck should be adjusted based on available resources, taking into account other trucks loading and / or unloading. In some examples, as the timer approaches the threshold loading / unloading time (e.g., less than 30 minutes remaining, 75% of the time has elapsed), the appearance of the timer progress bar 2426 may change (e.g., from green to yellow, blinking, and / or thickening, as represented by the difference between the fourth and fifth docks in the described example). Furthermore, the appearance of the timer progress bar 2426 may change again after the threshold loading / unloading time is reached and / or after the threshold loading / unloading time is exceeded (e.g., to red, blinking, and / or thickening, as represented for the ninth dock in the described example).In some cases, the same color-changing scheme is implemented on the display of the timing indicator 306 in Figure 3, so that personnel working at the dock have the same indicator as shown on the dock monitoring webpage 2400 viewed in the logistics office. As shown in Figure 24, providing a visual timer in an integrated manner for multiple docks allows dock managers and / or other personnel to identify trailers that may be behind schedule in loading and / or unloading. As a result, dock managers can quickly reallocate resources to accelerate processes at specific docks and reduce late fees.

[0152]

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

[0153]

[0168] The exemplary dock monitoring webpage 2400 in Figure 24 provides a time-based metric 2430 for each dock, showing the percentage of trailers that were in the dock during a given period (e.g., one week, one month, etc.) that were loaded or unloaded within an allocated time (e.g., two hours). The time-based metric 2430 may also include a trend indicator (e.g., an arrow pointing up or down) to show whether the rate of time-based loading or unloading at a particular dock is increasing or decreasing. In this way, docks associated with a larger number of delays that would incur late fees can be identified, and actions can be taken to reduce such costs.

[0154]

[0169] In some examples, selecting a specific dock and / or trailer on the dock monitoring webpage 2400 brings up an optional menu 2432, which the dock manager can use to indicate that loading and / or unloading of the associated trailer is complete. In some examples, the options presented via 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 menu 2432 are limited to information about the dock itself. However, after a trailer is detected at its location, menu 2432 can be automatically updated to allow the user to access information about the trailer (e.g., driver and / or carrier information, booking information, cargo information, etc.). In some examples, completion of loading (loading or unloading) can trigger additional options available in menu 2432 for the associated trailer. In some examples, alternatively, a forklift operator may access the dock monitoring webpage 2400 via a portable device (e.g., remote client device 148) to indicate the completion of trailer loading. Additionally or alternatively, a display screen 117 on the dock controller 116 may include buttons on a graphical user interface that can be presented to indicate the completion of loading and / or unloading. When the user indicates that loading is complete, the main server 132 may generate a loading completion popup 2900, shown in Figure 29, which provides details associated with the specific trailer selected for the user to confirm that the correct trailer was selected. After the user confirms that loading is complete, the main server 132 may generate a second notification confirming that the trailer has successfully checked out from its active status in the dock management system. In some examples, the trailer icon 2402 on the dock monitoring webpage 2400 is updated to reflect this change in status (e.g., a checkmark positioned above the trailer) until the trailer leaves the dock.In some cases, the main server 132 transmits a text message to the driver indicating that the load is complete and requesting the driver to proceed safely to the logistics office for paperwork. Simultaneously, as shown in Figure 30, information associated with the completed trailer can be added to the dock's release tab and the trailer queue popup 2800.

[0155]

[0170] As illustrated in the example in Figure 30, the pop-up 2800 includes a trailer seal entry field 3002 where 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 webpage 2400), or a yard jockey or supervisor at the dockyard. Recording the seal in this manner enables the creation of an electronic seal log linked to other information generated for the trailer, including specific cargo 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 is complete and that the driver can safely proceed to the trailer for departure.

[0156]

[0171] For illustrative purposes, Figure 24B is a magnified view of a portion of an exemplary dock monitoring webpage 2400, where different trailer icons 2402 are located in different docks of the material handling facility 100 (e.g., dock numbers 13–18). Figure 24B shows additional and / or alternative graphics that may be provided to the user to enable the user to understand the situation associated with the trailers in each dock. In some examples, a reservation time 2436 is drawn on the trailer icon 2402 to indicate the scheduled reservation (arrival and / or departure) time for the trailer. In some examples, if the trailer arrives before the scheduled reservation time, a reservation countdown 2438 is provided to show the amount of time remaining until the scheduled reservation start time. In some examples, an additional timer may be triggered to start 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 a timer can be monitored to determine the occurrence of leniency or late charges. In some cases, when this timer reaches a threshold, a notification can be triggered to inform the individual concerned about a delay beyond their scheduled appointment.

[0157]

[0172] In the example shown, where the trailer associated with the delivered cargo is indicated, and therefore described, the dock monitoring webpage 2400 may 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, indicated by a trailer icon 2402 (for example, the trailers at dock numbers 15 and 16) that is not associated with a tractor unit icon 2406.

[0158]

[0173] In the examples described, a loading direction indicator 2442 is drawn for each trailer. The loading direction indicator 2442 indicates whether the load is an incoming load to be unloaded at the facility (the arrow on indicator 2442 points to the door icon 2418) or an outgoing load to be loaded at the facility (the arrow on indicator 2442 points away from the door icon 2418). In some examples, the dock monitoring webpage 2400 includes a loading counter 2444 that tracks the progress of the associated load's movement (loading or unloading) and the total size of the load. More specifically, as shown in the examples described, the loading counter includes two digits: the first digit indicates the number of cargo units moved (e.g., pallets, racks, parcels, or other loading units), and the second digit indicates the total number of cargo units to be moved to complete the load. In addition or alternatively, in some examples, a loading status indicator 2446 is drawn to indicate the progress of the load being packed into 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) before start (for dock number 16), (2) partially completed or in progress (for dock number 13), (3) waiting (for dock number 15), and (4) completed (for dock number 17). The waiting state is intended to convey the idea that the cargo to be loaded is still being prepared within the material handling equipment 100, or that elements of the load are not available for loading. In some examples, a check mark is also displayed next to the associated trailer with a completed loading state.

[0159]

[0174] In some examples, different docks and / or related trailers located in different docks can be assigned different priorities for loading or unloading. In the example described, the trailer in dock number 17 is designated as having priority over the other trailers, as indicated by priority indicator 2448 with a single exclamation mark. Furthermore, in this example, the trailer in dock number 15 is given a higher priority (e.g., double the priority) than the trailer in dock number 17, as indicated by priority indicator 2448 with two exclamation marks.

[0160]

[0175] In some situations, it may be necessary to move cargo or goods from one trailer in a particular dock to a different trailer in a different dock. This scenario can be represented on the dock monitoring webpage 2400 via a mutual dock status indicator 2450, shown next to the trailer icon at dock number 14 in the example illustrated in Figure 24B. In some examples, the mutual dock status indicator 2450 includes a direction indicator with two arrows: one pointing outward (illustrated) away from each other, and another pointing inward towards each other. The outward-pointing direction indicator indicates that the goods in the trailer need to be moved to one or more different trailers. In contrast, the inward-pointing arrow indicates that goods from one or more other trailers need to be moved into the corresponding trailer. In some examples, the mutual dock status indicator 2450 also includes a mutual dock trailer involvement indicator to show the number of other trailers currently located in different docks to which the goods should be transferred to the corresponding trailer. In this example, the number is zero, indicating that there are currently no trailers at material handling facility 100 that should receive cargo for trailer at dock number 14. In other examples, the mutual trailer involvement indicator 2450 may include both trailers currently in different docks and trailers expected but not yet arrived at different docks on which the cargo in the corresponding dock depends. The mutual dock status indicator can be an active link, which, when selected, redirects to or opens another webpage or window / popup containing information related to the mutual dock relationships and status.

[0161]

[0176] Figure 31 shows an exemplary graphical user interface presented by the dock scheduling webpage 3100. The dock scheduling webpage 3100 in Figure 31 enables the arrangement or scheduling of inter-company reservations (for example, between a carrier and material handling facility 100). In particular, truck drivers and / or other personnel from the carrier can access the exemplary webpage 3100 in Figure 31 to set up reservations for trailer deliveries and / or loadings. In some examples, after the reservation information is entered, the main server 132 transmits a notification (for example, via text or email) to workers in the logistics office, shipping and receiving managers, and / or other relevant recipients. Furthermore, in some examples, a bell 2408 can be activated to indicate that new information is available via the dock and trailer queue popup 2800 in Figures 28 and 30. Specifically, the received reservation information can be provided in the reservations tab of the popup 2800.

[0162]

[0177] In some cases, it may be necessary to take a particular dock down for maintenance (e.g., equipment repair or replacement). Therefore, in some examples, the main server 132 may provide a maintenance schedule popup 3200 to schedule maintenance, as shown in Figure 32. Maintenance may be preventative, scheduled, or corrective (e.g., based on equipment failure), as illustrated in the example in Figure 32. In any case, when maintenance is designated for a particular dock, the main server 132 generates a notification confirming the action to be taken by the user. The main server 132 may also transmit a notification to the maintenance manager indicating that a particular dock door has been taken down for maintenance (e.g., via text or email). Additionally, the main server 132 updates the dock monitoring webpage 2400 by drawing one or more maintenance icons 2434 (e.g., orange cones) associated with the specific door designated for maintenance (e.g., the 10th door in the example illustrated in Figure 24). Additionally or alternatively, the maintenance status of the door can be reflected in the exemplary maintenance and asset management summary block 2108 of the overview webpage 2100 in Figure 21 (represented by reference no. 2114). Furthermore, the main server 132 can transmit the door status to the dock controller 116 associated with a particular dock, and a notification can be displayed on the local display screen 117 indicating that the door is down and / or inoperable for maintenance.

[0163]

[0178] After maintenance is complete, the user can indicate this by the maintenance complete popup 3300 shown in Figure 33. As shown in the example described, the completion of maintenance can be time-stamped to track when maintenance occurs at each dock. After indicating maintenance completion, the main server 132 can refresh the dock monitoring webpage 2400 again by removing the maintenance icon 2434 and specifying that the dock is available for trailers.

[0164]

[0179] Figure 34 shows an exemplary graphical user interface corresponding to the dock status webpage 3400. In some examples, the dock status webpage 3400 in Figure 34 contains information similar to that shown in the dock monitoring webpage 2400 in Figure 24, except that the information in Figure 34 is presented in a tabular format to allow sorting and / or filtering of the data. In some examples, the dock status webpage 3400 in Figure 34 may include additional and / or different information from the dock monitoring webpage 2400 in Figure 24. For example, as shown in Figure 34, the exemplary dock status webpage 3400 may include information identifying the driver, company, type of loading and / or unloading, amount of cargo being loaded and / or unloaded, check-in and check-out times, excess charge rules associated with the driver / company, etc.

[0165]

[0180] Figure 35 shows an exemplary graphical user interface presented by the yard management webpage 3500, which includes a trailer icon 3502 similar to the trailer icon 2402 in Figure 24, located in a parking area representing a material handling facility yard. In some examples, the user can use the trailer move popup 3600 shown in Figure 36 to identify a specific trailer that should be moved to a new parking space or a specific dock within the yard. In some examples, after a new location is specified for the selected trailer, the main server 132 automatically transmits a notification to the yard jockey or supervisor in the yard indicating which trailers need to be moved where. Additionally, the main server 132 can automatically update the yard management webpage 3500 and / or the dock monitoring webpage 2400 to reflect the change in trailer locations.

[0166]

[0181] Furthermore, in some examples, the user can specify a particular trailer in the yard that should be taken out of service for maintenance or repair via the inactivity pop-up 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 can also automatically transmit a notification (for example, via email) to the trailer maintenance company that the trailer has been taken out of service and needs repair.

[0167]

[0182] Figure 38 shows an exemplary graphical user interface corresponding to the yard status webpage 3800. In some examples, the yard status webpage 3800 in Figure 38 contains information similar to that shown in the yard management webpage 3500 in Figure 35, except that the information in Figure 38 is presented in a tabular format to allow sorting and / or filtering of the data. In some examples, the yard status webpage 3800 in Figure 38 may include additional and / or different information from the dock monitoring webpage 2400 in Figure 24. For example, as shown in Figure 38, the exemplary yard management webpage 3500 in Figure 35 may include information identifying slot numbers, trailer numbers, yard deliveries, status, scheduled reservations, load numbers, carriers, etc.

[0168]

[0183] Figure 39 shows an exemplary graphical user interface corresponding to the dock / driver logbook webpage 3900. The exemplary dock / driver logbook webpage 3900 is a searchable repository of information regarding the loading and unloading of trailers at docks, as well as the associated carriers and drivers of trucks associated with such trailers. Figure 40 shows an exemplary graphical user interface corresponding to the late charges webpage 4000. The exemplary late charges webpage 4000 in Figure 40 is similar to the dock / driver logbook webpage 3900 in Figure 39, except that the information represented in Figure 40 is specific to the trailer and / or dock associated with the late charges. Figure 41 shows an exemplary graphical user interface corresponding to the yard logbook webpage 4100. The exemplary yard logbook webpage 4100 in Figure 41 is similar to the dock / driver logbook webpage 3900 in Figure 39, except that the information shown in Figure 41 is specific to trailers parked in a yard associated with material handling equipment 100. Figure 42 shows an exemplary graphical user interface corresponding to the reservation summary webpage 4200. The reservation summary webpage 4200 provides a summary of scheduled reservations for trailers and the information associated with such reservations.

[0169]

[0184] Figure 43 shows an exemplary graphical user interface presented by the loading dock statistics webpage 4300, which provides various statistics on the efficiency and utilization of different docks within a material handling facility. For example, the exemplary webpage 4300 provides statistics on overdue charges and average loading time. In some examples, the user can manually enter the loading dock capacity.

[0170]

[0185] Figure 44 shows an exemplary graphical user interface corresponding to the video event archive webpage 4400. The exemplary video event archive webpage 4400 provides a list of detected events associated with captured video segments. In the example described, video events are listed, with the most recently detected events at the top. In some examples, for recently occurring events, the 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 has been processed, a thumbnail of the video is provided and the video event is displayed. As previously mentioned, the thumbnail can be obtained from a specific frame of the video segment, defined by a set thumbnail offset time. In some examples, any specific video segment can be played if selected by the user. In some examples, the archived list of video segments can be filtered based on duration, camera, and / or event type. The event types selected in the example described include video segments that captured a door being open 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 significant impact on energy consumption because, as a result of the doors being open, conditioned air (heating or cooling) can move freely from one area to another, potentially creating the need for additional heat generation or cooling of the air within a specific designated area. When doors are kept closed and / or opened only when necessary, heat transfer between compartmentalized areas is greatly reduced. Therefore, in the examples disclosed herein, the use of doors within the material handling facility 100 is monitored to identify when doors are open for too long, opened too frequently, opened when not necessary, and / or used in other circumstances that adversely affect 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 Figure 45.

[0172]

[0187] The exemplary energy monitoring webpage 4500 provides summary statistics related to door usage in a material handling facility 100. In some examples, a facility summary block 4502 is provided that contains summary information representing all doors in the facility. In addition or by alternative means, a product category summary block 4504 contains summary information categorized by different product or door types used in the facility. Door types may include freezer doors, refrigerator doors, cleanroom doors, high-speed exterior doors, dock doors (e.g., dock door 104 in Figure 1), grade-level classification doors, etc. In the examples described, the facility summary block 4502 and the product category summary block include an energy trend indicator 4506, a cycle trend indicator 4508, a malfunction indicator 4510, a trailer-less door open indicator 4512, a door open-for-fail indicator 4514, and a cycle disruption indicator 4516 (shown only in the facility summary block 4502 of the examples described). Indicators 4506, 4508, 4510, 4512, 4514, and 4516 in the equipment summary block 4502 show values ​​corresponding to all doors monitored within the material handling equipment 100. In contrast, indicators 4506, 4508, 4510, 4512, and 4514 in the product category summary block 4504 show corresponding values, but are limited to specific types of doors in their respective represented product categories.

[0173]

[0188] The exemplary energy trend indicator 4506 displays the trend of energy use calculated based on the use of doors in the material handling facility 100 (e.g., how often and for how long the doors are opened) and the energy characteristics associated with the doors (e.g., the temperature / humidity / pressure difference on both sides of the door). In some examples, the trend is based on a comparison of the current period (e.g., the current month) to a previous period (e.g., the previous month). The specific 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 the warehouse manager, general manager, and / or other relevant personnel to alert them that a negative energy trend has been detected and that additional details can be found on the energy monitoring webpage 4500. In addition or alternatively, the alert can be represented in the energy summary block 2104 on the overview webpage 2100 shown in Figure 21.

[0174]

[0189] The exemplary cycle trend indicator 4508 shows the trend of the number of cycles (e.g., the number of times the door was opened and closed) received by an associated door within the material handling facility 100 over a certain period (e.g., one week, two weeks, one month) compared to a previous period. In some examples, if the trend exceeds a threshold, the main server 132 can automatically transmit a notification to the warehouse manager, general manager, and / or other relevant 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 webpage 4500. In addition or by alternative means, the alert can be represented in the energy summary block 2104 on the overview webpage 2100 shown in Figure 21. In some examples, instead of showing a trend, the cycle trend indicator 4508 can represent the absolute number of cycles for one or more doors during the period. In some such examples, an alarm and / or notification can be triggered when the number of cycles for that door(s) exceeds a certain threshold.

[0175]

[0190] The exemplary false-start indicator 4510 shows the trend of false starts experienced by an associated door within the material handling facility 100 over a certain period (e.g., one week, two weeks, one month) compared to a previous period. As used herein, a false start refers to a situation where a door moves from a closed position (e.g., partially or fully opened) and then closes without any traffic passing through it. Thus, false starts are associated with unnecessary door openings that could unnecessarily increase energy consumption in the material handling facility and increase the burden on the HVAC system to maintain a controlled temperature environment. Monitoring false starts 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 the opening associated with the door). Therefore, the feedback from this combination of sensors must be synchronized in time so that the detection of presence corresponds to the period the door is open. In some examples, if the false activation trend exceeds a threshold, the main server 132 can automatically transmit a notification to the warehouse manager, general manager, and / or other relevant personnel to alert them that a relatively high percentage of false activations have been detected for a door, and that additional details can be found on the energy monitoring webpage 4500. Additionally or alternatively, the alarm can be represented in the energy summary block 2104 on the overview webpage 2100 shown in Figure 21. In some examples, instead of showing a trend, the false activation indicator 4510 can represent the absolute number of false activations for one or more doors during the period. In some such examples, an alarm and / or notification can be triggered when the number of false activations exceeds a certain threshold.

[0176]

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

[0177]

[0192] The exemplary door open / closed indicator 4514 shows a trend in the number of doors that remain open beyond a threshold duration (e.g., 1 minute, 2 minutes, 5 minutes, etc.) over a certain period (e.g., one week, two weeks, one month) compared to a previous period. In some examples, if the trend exceeds a threshold, the main server 132 can automatically transmit a notification to the warehouse manager, general manager, and / or other relevant personnel to alert that the proportion of doors remaining open is relatively high. In addition or alternatively, the alarm can be represented in the energy summary block 2104 on the overview webpage 2100 shown in Figure 21. In some examples, instead of showing a trend, the door open / closed indicator 4514 can represent the absolute number of times one or more doors remain open beyond the corresponding threshold duration over the given period. In some such examples, an alarm and / or notification can be triggered when the number of door open instances exceeding the duration limit exceeds a certain threshold.

[0178]

[0193] The exemplary cycle disruption indicator 4516 shows the number of times a cycle disruption was detected for the door over a given period (e.g., one week, two weeks, one month). A cycle disruption refers to a situation where something was detected crossing the doorway under the door's path while the door was closing, causing it to change direction. In the example described, the absolute number of cycle disruptions is provided, but in other examples, the cycle disruption indicator 4516 may represent a trend in the number of cycle disruptions during the current period compared to previous periods.

[0179]

[0194] As previously mentioned, Figure 45 shows summary statistics at the equipment level (e.g., within equipment summary block 4502) and the product category level (e.g., within product category summary block 4504). In some examples, the user can delve further to access energy-related information associated with individual doors shown in the exemplary product summary webpage 4600 in Figure 46. In such examples, similar information to that described above can be provided, except that the information is specific to the individual door(s) selected to be displayed via the energy monitoring webpage 4500.

[0180]

[0195] In some cases, warehouse managers, general managers, and / or other personnel may want to track or compare the impact of door use on energy consumption after taking corrective action in response to any of the negative energy trends outlined above. Therefore, in some cases, the energy monitoring webpage 4500 provides users with the ability to set or schedule a time frame in which energy metrics are collected and monitored, and then automatically generate an energy corrective action report at a future scheduled time. In some cases, after the scheduled time has arrived, the main server 132 generates the report and transmits a notification to the warehouse manager, general manager, and / or other relevant individuals to confirm that the report is ready.

[0181]

[0196] Figure 47 shows an exemplary graphical user interface presented by a safety monitoring webpage 4700 that provides summary statistics of safety-related events within and around the material handling facility 100. The exemplary safety monitoring webpage 4700 includes a loading dock trend summary 4702 and an on-site trend summary 4704. The exemplary loading dock trend summary 4702 includes a long-term trend line 4706 representing the trend (e.g., a 12-month moving average) of the number of safety events detected in the loading dock 102 shown in Figure 1 over a long period. Furthermore, the exemplary loading dock trend summary 4702 includes a short-term trend line 4708 representing the short-term change in the number of safety events detected over a period (e.g., monthly in the example described). The exemplary loading dock trend summary 4702 also includes a target line 4709 representing a user-defined target for the number of safety events detected within that period (e.g., one month). An exemplary on-site trend summary 4704 includes similar long-term and short-term trend lines 4710, 4712 representing the trend in the number of safety events detected at locations within the material handling facility 100 during the corresponding period, along with a corresponding target line 4713 indicating the target number of associated safety events.

[0182]

[0197] In some examples, specific values ​​(e.g., counts) of certain types of safety events contributing to trend lines 4706, 4708, 4710, and 4712 are also provided to the safety monitoring webpage 4700, along with the corresponding loading dock trend summary 4702 and / or premises trend summary 4704. An exemplary type of safety event associated with loading dock 102 includes trailer restraint device failure 4714. A trailer restraint device failure event can 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 failures on the safety monitoring webpage 4700, the main server 132 can also automatically transmit notifications to the relevant individuals to report that a trailer restraint device failure has been detected.

[0183]

[0198] Another exemplary type of safety event associated with a loading dock involves the intrusion of an unsecured trailer 4716. An unsecured trailer intrusion event can be detected when a motion sensor 204 detects movement within the trailer while the vehicle restraint device 110 is not engaged with the trailer (for example, based on feedback from a restraint sensor). In some such examples, the main server 132 automatically transmits a notification to safety managers, shipping and receiving managers, and / or other personnel to report a dangerous intrusion of an unsecured trailer in the corresponding dock. In addition or by alternative means, the main server 132 may record the detected event in an alarm or event log for later access and reinvestigation. Furthermore, the main server 132 may transmit the information again to the dock controller 116 associated with a particular dock to provide a notification that the trailer is dangerous to the local display screen 117.

[0184]

[0199] Another exemplary type of safety event associated with a loading dock involves a dock barrier 4718 that is not properly engaged. Such an event can be detected when there is no feedback from a barrier sensor (e.g., a magnetic resonance switch) indicating that the entrance / exit barrier 106 is extended to an entrance / exit associated with a door 104 that has been opened without the presence of a trailer being detected. In some such examples, the main server 132 automatically transmits a notification to the safety manager, shipping and receiving manager, and / or other personnel to report the improper engagement of the barrier in the corresponding dock. In addition or by alternative means, the main server 132 may record the detected event in an alarm or event log for later access and reinvestigation.

[0185]

[0200] Another exemplary type of safety event associated with a loading dock includes a dock door reversal 4720. A dock door reversal corresponds to the detection of a cycle disruption at a dock door. In some such cases, the main server 132 automatically transmits a notification to the appropriate personnel to report the door reversal at the corresponding dock. In addition or by alternative means, the main server 132 may record the detected event in an alarm or event log for later access and reinvestigation.

[0186]

[0201] Another exemplary type of safety event associated with a loading dock includes a possible trailer withdrawal attempt 4722. Such an event can be detected when a truck driver or supervisor attempts to withdraw a trailer from a dock when it is dangerous to do so (e.g., the dock leveler 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 cases, the main server 132 automatically transmits a notification to the safety manager and / or other personnel indicating that a dangerous withdrawal attempt may have been attempted at a particular dock. In addition or by alternative means, the main server 132 may record the detected event in an alarm or event log for later access and reinvestigation. Furthermore, the main server 132 may transmit such information to the dock controller 116 associated with a particular dock in order to enable a notification on the local display screen 117 indicating that a possible withdrawal attempt has been detected.

[0187]

[0202] While there may never have been an attempt to withdraw a trailer, it may nevertheless move or shift relative to the dock during loading and / or unloading. Such inadvertent movement of a trailer is sometimes referred to as "trailer creep." In some situations, trailer creep can cause the trailer to move to a position where it is impossible to release and disengage the vehicle restraint device 110 from the trailer. In some cases, a sensor may detect trailer creep, thereby triggering the main server 132 to transmit a notification to the yard jockey or overseer to proceed to the corresponding dock and release the trailer (for example, by repositioning the trailer so that it is released from the vehicle restraint device 110). Additionally or alternatively, the main server 132 may record detected events in an alarm or event log for later access and reinvestigation.

[0188]

[0203] Another exemplary type of safety event associated with a loading dock involves a hazardous linked action 4724. A hazardous linked action can be detected when certain actions are performed in the wrong order. For example, the door 104, the dock leveler 108, and the vehicle restraint device 110 can be linked to each other to control the order of actions. In particular, when a trailer is positioned in the dock for loading or unloading, the dock leveler 108 cannot be activated until the door 104 is opened, and the door 104 cannot be opened until the vehicle restraint device 110 engages with the trailer. In some examples, actions are performed in the reverse order to release the trailer from the loading dock. Thus, a hazardous linked action event can be detected when actions are performed in the wrong order, or at least when actions are attempted to be performed in the wrong order. In some examples, a linkage system set up for these components can prevent actions from being performed in the wrong order. However, merely attempting to deviate from the correct sequence of actions may indicate that a person does not understand the correct sequence, which can lead to safety problems. This is a particularly significant problem when other docks may be set up without linkage components. In some cases, a hazard trigger can only set a safety event when the frequency of such actions exceeds a certain threshold. In some such cases, the main server 132 automatically transmits a notification to safety managers, shipping and receiving managers, and / or other personnel to report a hazard trigger event (or a relatively strong tendency to such an event) detected at a particular door. In addition or by alternative means, the main server 132 may record the detected event in an alarm or event log for later access and reinvestigation. Furthermore, the main server 132 may transmit this information to the dock controller 116 associated with a particular dock to provide a notification to the local display screen 117 reminding personnel at the dock to follow a safe operation sequence.

[0189]

[0204] Another exemplary type of safety event associated with a loading dock involves leveler operation due to motion detected in pit 402 (which may indicate the presence of a pedestrian in the pit). Such an event may be detected when motion (presumably a person) is detected in leveler pit 402 and a person attempts to lower the vertically retracted dock leveler 108. In some such examples, the main server 132 automatically transmits a notification to safety managers, shipping and receiving managers, and / or other personnel to report dangerous operation of the dock leveler in the corresponding dock when a pedestrian may be in the leveler pit. In addition or alternatively, the main server 132 may record the detected event in an alarm or event log for later access and reinvestigation. Furthermore, the main server 132 may transmit this information to the dock controller 116 associated with a particular dock to provide a notification to 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 the opening of a dock door when there is no trailer or barrier present 4728. Such an event can be detected when the presence of a trailer is not detected and the dock barrier 106 is not crossing the opening of an open dock door. This poses a safety issue because an open door without a trailer would result in a dangerous fall. In some examples, when such an event is detected, the main server 132 automatically transmits a notification to the safety manager, shipping and receiving manager, and / or other personnel reporting that a particular dock door is open in the absence of a trailer. In addition or by alternative means, the main server 132 may record the detected event in an alarm or event log for later access and reinvestigation. Furthermore, the main server 132 may transmit this information to the dock controller 116 associated with a particular dock and provide a notification to the local display screen 117 instructing personnel in that area to close the door or extend the barrier over the open opening.

[0191]

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

[0192]

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

[0193]

[0208] Exemplary types of safety events associated with the activities of the material handling equipment 101 (for example, contributing to the site trend summary 4704) include fast door switching 4734. Fast door switching corresponds to the detection of cycle disruption at a fast internal door. In some examples, fast door switching may only set a safety event when the frequency of such occurrences exceeds a certain threshold. In some such examples, the main server 132 automatically transmits a notification to safety managers and / or other personnel to report door switching (or a relatively high tendency for such switching at a particular door). In addition or alternatively, the main server 132 may record detected events in an alarm or event log for later access and reinvestigation.

[0194]

[0209] Another exemplary type of safety event associated with on-site activities includes excessively open fast doors 4736. Such events can be detected when it is determined that a fast door has been left open for longer than a threshold duration. While such events may increase energy costs, as previously mentioned, doors associated with cold storage rooms that are left open for too long can also pose a safety hazard due to potential condensation and ice buildup. Therefore, when it is detected that a door has been left open for too long, the main server 132 may automatically transmit a notification to the safety manager and / or other personnel reporting that the door has remained open beyond the associated time limit. In addition or by alternative means, the main server 132 may record the detected event in an alarm or event log for later access and reinvestigation.

[0195]

[0210] Another exemplary type of safety event associated with on-premises activity includes unauthorized door operation 4738. Unauthorized door operation can be detected when a person attempts to operate a door in a manner not permitted by their security credentials and / or attempts to perform an operation (e.g., changing certain parameters associated with the door) without providing an appropriate security password. In some such examples, the main server 132 automatically transmits a notification to the security manager and / or other personnel to report the unauthorized operation of the door. In addition or otherwise, the main server 132 may record the detected event in an alarm or event log for later access and reinvestigation. Furthermore, the main server 132 may transmit this information to the door controller 122 associated with the particular door in question to display a notification on the local display screen indicating that access to the attempted operation was denied.

[0196]

[0211] Another exemplary type of safety event associated with on-site activities includes high-volume low-speed (HVLS) fan failure 4740. Such events can be detected when a fan does not operate as expected. In some such examples, the main server 132 automatically transmits a notification to the safety manager and / or other personnel to report the fan failure. In addition or alternatively, the main server 132 may record the detected event in an alarm or event log for later access and reinvestigation.

[0197]

[0212] Another exemplary type of safety event associated with on-site activity includes unauthorized fan operation 4742. Such an event can be detected when a person attempts to operate a fan in a manner not permitted by their security credentials and / or attempts to perform an operation (e.g., changing specific parameters associated with the fan) without providing an appropriate security password. In some examples, the main server 132 automatically transmits a notification to the safety manager and / or other personnel to report the unauthorized operation of the fan in question. In addition or by alternative means, the main server 132 may record the detected event in an alarm or event log for later access and reinvestigation. Furthermore, the main server 132 may transmit this information to the fan controller 126 associated with the particular fan in question and display a notification on the local display screen indicating that access to the attempted operation was denied.

[0198]

[0213] Another exemplary type of safety event associated with on-site activities includes a high-speed door impact 4744. A high-speed door impact can be detected when a door sensor detects that an object has struck a door. In some examples, the main server 132 automatically transmits a notification to the safety manager and / or other personnel to report that an object has struck the door. In addition or by alternative means, the main server 132 may record the detected event in an alarm or event log for later access and reinvestigation.

[0199]

[0214] In some cases, users can access further information by selecting either the loading dock trend summary 4702 or the on-site trend summary 4704. For example, by selecting the loading dock trend summary 4702 in Figure 7, users can access the detailed loading dock web trend page 4800, as shown in Figure 48. Similarly, by selecting the on-site trend summary 4704 in Figure 7, users can access the detailed on-site trend web page 4900, as shown in Figure 49.

[0200]

[0215] Figure 50 shows another exemplary graphical user interface presented by the safety monitoring webpage 5000, which provides summary statistics of safety-related events within and around the material handling facility 100. As shown in the example described, the safety monitoring webpage 5000 includes loading dock trend summaries 5002 and premises trend summaries 5004, similar to the loading dock trend summaries 4702 and premises trend summaries 4704 in Figure 47. In addition, the safety monitoring webpage 5000 includes traffic trend summaries 5006, which provide summary statistics of usage and congestion at different intersections within the material handling facility 100. Congestion statistics represent events in which two personnel / equipment (a person walking or in a vehicle (e.g., a forklift), or autonomously operating equipment) approached 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 Figure 50, the safety monitoring webpage 5000 may include the traffic trend summary 5100 shown in Figure 51. The traffic trend summary 5100 provides trend statistics on traffic congestion or volume at one or more intersections within the material handling facility 100, which are monitored by traffic sensors. Furthermore, the traffic trend summary 5100 provides trend statistics corresponding to collision risk at one or more intersections. 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 indicating that the intersection poses a relatively high risk of collision.

[0202]

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

[0203]

[0218] In some examples, the traffic analysis webpage 5200 includes a traffic volume heatmap 5206 that represents the relative volume of traffic (e.g., traffic volume) and / or relative congestion (shown in the exemplary webpage 5300 in Figure 53) at corresponding intersections at different times of day (horizontal axis) and different days of the week (vertical axis) over a specified period. In the example described in Figure 52, the heatmap 5206 represents all traffic detected at a particular intersection. In some examples, the user can toggle between graphics showing the total traffic volume or congestion from all directions detected at a particular intersection (shown in Figure 52) and graphics showing traffic volume or congestion based on a specific approach direction associated with the intersection (shown in Figure 54). In some examples, collision risk graphics can be provided for traffic approaching a selected intersection from a specific direction. Thus, as shown in Figure 54, the traffic analysis webpage 5200 can provide a direction heatmap 5402 that represents the collision risk associated with traffic specific to a particular direction selected by the user (e.g., north in the described example). More specifically, in the example described, the directional heatmap 5402 is selected to represent the collision risk between northbound traffic and traffic approaching the intersection from another specific direction (e.g., south, indicated by a checkmark 5404 in Figure 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. Furthermore, the directional heatmap 5402 can show the collision risk from the north for all other directions by selecting the all-directions icon 5408. Thus, four separate heatmaps 5402 can be represented with respect to the collision risk associated with traffic approaching the corresponding intersection from the north. Similar heatmaps can also be generated for any other selected direction.These various heatmaps allow safety managers to identify potential trends and / or high-risk traffic flows associated with specific directions and / or at specific times, enabling them to determine whether specific personnel require additional training and / or whether traffic routes need to be altered to reduce congestion and collision risks.

[0204]

[0219] In some cases, safety managers and / or other personnel may want to track or compare trends in safety events and / or traffic patterns and collision risks after taking corrective actions in response to the detection of potential hazardous conditions as outlined above. Therefore, in some cases, the safety monitoring webpage 4700 provides users with the ability to set or schedule timeframes in which safety metrics are collected and monitored, and then automatically generate safety corrective action reports at future scheduled times. In some cases, after the scheduled time has arrived, the main server 132 generates the report and transmits a notification to the safety manager and / or other relevant individuals to confirm that the report is ready.

[0205]

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

[0206]

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

[0207]

[0222] Figure 57 shows an exemplary graphical user interface presented by an asset management webpage 5700 that provides summary statistics corresponding to assets within the material handling facility 100. As shown in the examples described, the asset management webpage 5700 includes a maintenance plan indicator 5702 to show the number of maintenance event plans for scheduled assets. In some examples, the user can schedule additional maintenance events by selecting a calendar button. In some examples, when maintenance is scheduled to take place within a threshold period (e.g., 30 days), the main server 132 automatically generates and transmits a notification reminder that the scheduled maintenance is approaching for the asset, so that maintenance managers and / or other personnel can contact the asset manufacturer to schedule the maintenance.

[0208]

[0223] In the described examples, the asset management webpage 5700 includes a list 5704 of faults detected for a particular asset, as well as a list 5706 of non-operational assets. In some examples, when an asset is made non-operational, the main server 132 transmits a notification to the individual concerned informing them that the corresponding asset is non-operational. Furthermore, the main server 132 can transmit the door status to the controller associated with the particular asset and display a notification that the asset is non-operational on the local display screen.

[0209]

[0224] Furthermore, in some examples, the asset management webpage 5700 includes an asset lifespan summary 5708 that identifies and tracks the lifespan of all assets (e.g., from the date of manufacture and / or installation). In some examples, the asset lifespan summary 5708 can be categorized into different items, such as the installation date or cycle count or usage, which are monitored by sensors associated with the asset. In some examples, the user can schedule the generation of an asset lifespan report, and the main server 132 transmits a notification that it is ready to review the asset lifespan report at a specific point in the future. This can be useful as a reminder to review the asset lifespan cycle before planning a budget for future maintenance costs in the material handling equipment 100. Figure 58 shows another exemplary asset management webpage 5800.

[0210]

[0225] Figure 59 shows an asset management webpage 5900 displaying an asset profile 5902 for a specific asset within the material handling equipment 100. In this example, the specific 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 general image of the asset or a photograph of the actual product installed within the equipment 100. The asset profile 5902 provides equipment details specific to the represented asset, such as the asset name, asset type, asset manufacturer, and installation date. Furthermore, in some examples, the asset profile 5902 includes statistics on the operation and / or use of the asset. For example, in the example described, the asset profile 5902 includes indications of the number of cycles the door has undergone since installation, the number of failures detected against the door, and the number of false starts. In some examples, these statistics can be expressed over a period of time (for example, providing indications of the number of cycles from a given month (or other relevant period) 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, the exemplary graphical user interfaces shown in Figures 21 to 59 have been described in the context of web pages, but any of the graphical user interfaces disclosed herein can also be implemented by non-web based applications, independently of the internet and / or web pages.

[0212]

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

[0213]

[0228] The processor platform 6000 described in the example includes a processor 6012. The processor 6012 described in the 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 exemplary web server 146, an exemplary network communication interface 602, an exemplary I / O network interface 604, an exemplary restart watchdog 606, an exemplary pull service manager 610, an exemplary push service manager 612, an exemplary video management system 614, and an exemplary event manager 616.

[0214]

[0229] The processor 6012 in the described example includes local memory 6013 (e.g., cache). The processor 6012 in the described example communicates with main memory, which includes volatile memory 6014 and non-volatile memory 6016, via bus 6018. 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. Non-volatile memory 6016 can be implemented by flash memory and / or any other desired type of memory device. Access to main memory 6014, 6016 is controlled by a memory controller.

[0215]

[0230] The example processor platform 6000 described also includes an interface circuit 6020. The interface circuit 6020 can be implemented by 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 described example, one or more input devices 6022 are connected to the interface circuit 6020. The input device(s) 6022 allows the user to input data and / or commands to the processor 6012. The input device(s) can be implemented by, for example, a voice sensor, microphone, camera (still image or video), keyboard, buttons, mouse, touchscreen, trackpad, trackball, IsoPoint, and / or voice recognition system.

[0217]

[0232] One or more output devices 6024 are also connected to the interface circuit 6020 of the example described. The output devices 6024 can be implemented by, for example, display devices (e.g., light-emitting diodes (LEDs), organic light-emitting diodes (OLEDs), liquid crystal displays (LCDs), cathode ray tube displays (CRTs), in-place switching (IPS) displays, touchscreens, etc.), haptic output devices, printers, and / or speakers. Thus, the interface circuit 6020 of the example described typically includes a graphics driver card, a graphics driver chip, and / or a graphics driver processor.

[0218]

[0233] The interface circuit 6020 in the example described also includes communication 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) via the network 6026. Communication can be carried out via, for example, Ethernet® connections, digital subscriber line (DSL) connections, telephone line connections, coaxial cable systems, satellite systems, line-of-sight wireless systems, mobile phone systems, etc.

[0219]

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

[0220]

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

[0221]

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

[0222]

[0237] The processor platform 6100 described in the example includes a processor 6112. The processor 6112 described in the 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 exemplary data analyzer 1104, an exemplary event analyzer 1106, an exemplary parameter value converter 1108, an exemplary notification engine 1110, an exemplary display 1114, and an exemplary instrument controller 1116.

[0223]

[0238] The processor 6112 in the described example includes local memory 6113 (e.g., cache). The processor 6112 in the described example communicates with main memory, which includes volatile memory 6114 and non-volatile memory 6116, via 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 main memory 6114, 6116 is controlled by a memory controller.

[0224]

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

[0225]

[0240] In the described example, one or more input devices 6122 are connected to the interface circuit 6120. The input device(s) 6122 allows the user to input data and / or commands to the processor 6112. The input device(s) can be implemented by, for example, a voice sensor, microphone, camera (still image or video), keyboard, buttons, mouse, touchscreen, trackpad, trackball, IsoPoint, and / or voice recognition system.

[0226]

[0241] One or more output devices 6124 are also connected to the interface circuit 6120 of the example described. The output devices 6124 can be implemented by, for example, display devices (e.g., light-emitting diodes (LEDs), organic light-emitting diodes (OLEDs), liquid crystal displays (LCDs), cathode ray tube displays (CRTs), in-place switching (IPS) displays, touchscreens, etc.), haptic output devices, printers, and / or speakers. Thus, the interface circuit 6120 of the example described typically includes a graphics driver card, a graphics driver chip, and / or a graphics driver processor.

[0227]

[0242] The interface circuit 6120 in the described example also includes communication devices such as transmitters, receivers, transceivers, modems, residential gateways, wireless access points, and / or network interfaces to facilitate data exchange with external machines (e.g., any type of computing device) via the network 6126. Communication can be conducted via, for example, Ethernet® connections, digital subscriber line (DSL) connections, telephone line connections, coaxial cable systems, satellite systems, line-of-sight wireless systems, mobile phone systems, etc. In this example, the interface circuit 6120 implements the exemplary communication interface 1102.

[0228]

[0243] The processor platform 6100 described in the 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, independent disk redundant array (RAID) systems, and digital versatile disk (DVD) drives. In this example, the mass storage 6128 implements the exemplary database 1112.

[0229]

[0244] The machine-executable instructions 6132 shown in Figures 16 to 20 can be stored in a mass storage device 6128, volatile memory 6114, non-volatile memory 6116, and / or a removable non-temporary computer-readable storage medium such as a CD or DVD.

[0230]

[0245] From the above, it will be understood that exemplary methods, apparatus, and products are disclosed that enable the aggregation and integration of data from heterogeneous controllers, sensors, etc., within material handling equipment for the generation and / or later analysis for the provision of notifications via a substantially real-time updated web page (or other application) interface. The examples disclosed herein improve the efficiency of using electronic devices to monitor material handling equipment by collecting heterogeneous information in an integrated manner, thereby avoiding redundancy from monitoring multiple separate systems. Furthermore, the combination of information collected from different sources enables users to access and / or become aware of certain situations that were previously not possible to automatically detect, such as the accidental opening of a door. Notifications of such situations can be generated based on events triggered by a combination of parameters reported from different controllers that satisfy specific configurable conditions. In some examples, such events can initiate the generation of video segments capturing the occurrence of the event with a camera, and such video segments can be included in the notification as attachments. Furthermore, in some examples, the video segments can be subjected to video analysis to detect additional safety events and / or persons in the video and potentially identify the cause of the initially triggered event. Notification of events that would normally be unknown also contributes to the efficient use and improved operation of control systems within material handling facilities that generate the data enabling event detection in the first place. For example, by informing relevant personnel (e.g., safety managers) of potential safety risks, those personnel can take corrective actions to reduce or eliminate the risk (e.g., quickly changing the operation 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 quickly detected and addressed, some safety events are based on the recurrence of specific conditions occurring over a period of time (e.g., exceeding a certain threshold). This cannot be directly detected due to its temporal component.However, according to the teachings disclosed herein, events based on such trends can be detected by tracking conditions over time. Once such events are detected and appropriate personnel become aware of an undesirable trend, the personnel can then implement appropriate actions to resolve or mitigate the impact of the factors contributing to the undesirable trend. Furthermore, notification of detected events can also significantly reduce unnecessary energy consumption within material handling facilities by enabling appropriate personnel (e.g., general managers) to identify conditions and / or trends that lead to energy loss (e.g., doors being left open too frequently and / or for 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 energy waste. This not only saves costs but also reduces the burden on heating and / or cooling systems used to provide a 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, the updates may include user input data provided on one webpage, and such data is pushed to different webpages based on subscriptions to such data by different webpages.

[0231]

[0246] Exemplary methods, apparatus, systems, and products for monitoring and controlling loading dock and equipment operations are disclosed herein. Further examples and combinations thereof include:

[0232]

[0247] Example 1 includes a device for monitoring operations in a material handling facility, the device comprising a data analyzer that monitors first data indicating whether a truck trailer is present in the dock of the material handling facility and second data different from the first data indicating conditions associated with equipment in the dock, and a notification generator that generates notifications based on the first and second data.

[0233]

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

[0234]

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

[0235]

[0250] Example 4 includes the apparatus of Example 3, wherein a data analyzer monitors third data indicating whether a barrier different from the door is preventing passage through an entrance associated with an open door, and the apparatus further includes an event analyzer that suppresses the generation of a notification when the third data indicates that the barrier is preventing passage through the entrance.

[0236]

[0251] Example 5 includes the apparatus of Example 2, wherein a second data source corresponds to a light indicator, which switches between a first state in which the vehicle restraint device is in the engaged position and a second state in which the vehicle restraint device is in the retracted position, the vehicle restraint device engages with a trailer in the dock when the vehicle restraint device is in the engaged position, the light indicator switches to the first state when the vehicle restraint device is put into override mode regardless of whether the vehicle is in the engaged position or the retracted position, and a notification generator generates a notification in response to (1) a first data indicating that the trailer is not in the dock and (2) a second data indicating that the light indicator is in the first state in relation to the vehicle restraint device being in override mode, the notification indicating that the trailer was taken out of 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, which stores dock management data indicating the assignment of different trailers to different docks of material handling equipment, and the notification generator generates a notification in response to the first data indicating that a trailer is present in a dock when the second data indicates that no trailer is assigned to a dock, and the notification indicates that the trailer is in 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 docked, the condition corresponds to the duration of no activity detected within the trailer, and the notification generator generates a notification in response to the duration exceeding a threshold.

[0239]

[0254] Example 8 includes the apparatus of Example 2, wherein a data analyzer monitors third data indicating a user activation of a manually started actuator that enables the operation of a first device associated with a dock; a second data source corresponds to a second sensor, the second sensor monitors the state of a second device which is interdependent with the operation of the first device, the condition corresponds to whether the state of the second device prevents the operation of the first device based on the interdependence; and a notification generator generates a notification in response to a user activation when the second data indicates that the state of the second device prevents the operation of the first device.

[0240]

[0255] Example 9 includes the device from Example 1, where the notification generator draws information associated with the notification on a screen located near the dock.

[0241]

[0256] Example 10 includes the device from Example 1, where the notification generator renders the information associated with the notification onto a web page accessible by a device away from the dock.

[0242]

[0257] Example 11 includes the device from Example 1, and further includes an event logger that logs events to a database, where the events are associated with the content of a notification.

[0243]

[0258] Example 12 includes a device for monitoring the operation of a material handling facility, the device comprising: a data analyzer that monitors first data indicating that a door associated with the material handling facility is in an open state, and second data indicating the passage of at least one person or object at an entrance associated with the open door; and a notification generator that generates a notification in response to the second data indicating that there has been no passage of at least one person or object at the entrance during the duration that the first data indicates the door is in an open state, the notification indicating a malfunction of the door.

[0244]

[0259] Example 13 includes a device for monitoring operations in a material handling facility, the device being a database that aggregates dock data associated with multiple docks of the material handling facility, the database including (1) instructions on the operating status of equipment associated with the multiple docks, (2) instructions on personnel activities near the multiple docks based on feedback from sensors associated with the multiple docks, and (3) cargo information associated with trailers in which at least one of loading or unloading is performed at one of the multiple docks, and a notification generator that draws multiple dock icons corresponding to the multiple docks, and in response to the user selecting a first dock icon from the multiple dock icons, draws a menu of options for the 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, wherein the notification generator, in response to dock data indicating that a first trailer is present in a first dock among a plurality of docks, draws a trailer icon having the shape of a truck trailer adjacent to the first dock icon corresponding to the first dock among a plurality of dock icons, and updates the 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 a notification generator dynamically updates a timing indicator in the trailer icon, which indicates the 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 apparatus of Example 15, where the timing indicator includes a progress bar corresponding to a first portion of the trailer icon drawn in a color different from a second portion of the trailer icon, and the first portion increases in size in proportion to the duration.

[0249]

[0264] Example 18 includes the apparatus of Example 17, where the first portion corresponds to the whole of the trailer icon when the duration exceeds a threshold period corresponding to the demurrage period.

[0250]

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

[0251]

[0266] Example 20 includes the apparatus of Example 19, where the notification generator draws a reservation countdown within the trailer icon, and the reservation countdown indicates the time remaining until the scheduled reservation.

[0252]

[0267] Example 21 includes the apparatus of Example 14, where the notification generator draws a loading status indicator adjacent to the trailer icon, and the loading status indicator indicates the progress of moving goods into or out of the first trailer, and the progress corresponds to at least one of before start, waiting on the goods, partially completed, or completed.

[0253]

[0268] Example 22 includes the apparatus of Example 14, where the notification generator draws a tractor unit icon adjacent to the trailer icon in response to dock data indicating that the first trailer is associated with an actual load, illustrating that the tractor unit is connected to the first trailer, and draws a receiving status indicator adjacent to the trailer icon in response to dock data indicating that the first trailer is associated with the received load, and the receiving status indicator indicates whether the first trailer should be moved to the trailer yard or remain at the first dock.

[0254]

[0269] Example 23 includes the apparatus of Example 22, where the notification generator modifies the 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, where the notification generator draws an inter-dock status indicator adjacent to the trailer icon, and the inter-dock status indicator indicates at least one of (1) that the cargo in the first trailer should be moved to a different trailer, or (2) that the 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 draws a load direction indicator adjacent to the trailer icon, and the load direction indicator indicates whether the first trailer is associated with an incoming load to which the cargo on the first trailer should be unloaded, or an outgoing load to which the cargo should be loaded onto the first trailer.

[0257]

[0272] Example 26 includes the apparatus of Example 14, where the notification generator draws a priority indicator adjacent to the trailer icon, and the priority indicator indicates the priority of the first trailer.

[0258]

[0273] Example 27 includes the apparatus of Example 26, where the priority indicator switches between a first appearance indicating the 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, where the notification generator draws a load counter within the trailer icon in response to dock data indicating that the first trailer is associated with an incoming load, and the load counter indicates the 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 the remaining number of cargo units to be removed from the first trailer based on activity detected within the trailer, and a notification generator that dynamically updates a cargo counter to indicate the remaining number of cargo units to be moved out of the first trailer, with the remaining number drawn along with the total number.

[0261]

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

[0262]

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

[0263]

[0278] Example 32 includes the device from Example 13, where the notification generator dynamically switches between multiple dock icons based on dock data to represent a change in the state of a corresponding dock among multiple docks.

[0264]

[0279] Example 33 includes a non-temporary computer-readable medium containing instructions, which, when executed, cause a processor to monitor at least first data indicating whether a truck trailer is present in a dock of material handling equipment, second data different from the first data indicating conditions associated with equipment in the dock, and generate a notification based on the first and second data.

[0265]

[0280] Example 34 includes the non-temporary computer-readable medium of Example 33, wherein 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 being different from the second data source, the first data source corresponding to at least one of a first sensor in the dock, a vehicle restraint device in the dock, a leveler, a light indicator in the dock, or a database for a dock management system associated with material handling equipment, and the second data source corresponding to at least one of a second sensor in a different dock, a vehicle restraint device, a leveler, a light indicator, or a database.

[0266]

[0281] Example 35 includes the non-temporary computer-readable medium of Example 34, wherein a second data source corresponds to a second sensor, the second sensor monitors the operation of a door, the condition corresponds to whether the door is in an open state, and the instruction causes the processor to generate a notification when the first data indicates that the trailer is not docked and the second data indicates that the door is in an open state, the notification indicating a fall hazard associated with the door.

[0267]

[0282] Example 36 includes the non-temporary computer-readable medium of Example 35, wherein the instruction further causes the processor to monitor third data indicating whether a barrier different from the door is preventing passage through an entrance associated with an open door, and to suppress the generation of a notification when the third data indicates that the barrier is preventing passage through the entrance.

[0268]

[0283] Example 37 includes the non-temporary computer-readable medium of Example 34, wherein a second data source corresponds to a light indicator, which switches between a first state in which the vehicle restraint is in the engaged position and a second state in which the vehicle restraint is in the retracted position, the vehicle restraint engages with a trailer in the dock when the vehicle restraint is in the engaged position, the light indicator switches to the first state when the vehicle restraint is put into override mode, regardless of whether the vehicle is in the engaged position or the retracted position, the instruction causes the processor to generate a notification in response to (1) a first data indicating that the trailer is not in the dock and (2) a second data indicating that the light indicator is in the first state in relation to the vehicle restraint being in override mode, the notification indicating that the trailer was taken out of the dock when the light indicator was in the first state.

[0269]

[0284] Example 38 includes the non-temporary computer-readable medium of Example 34, wherein the second data source corresponds to a database which stores dock management data indicating the assignment of different trailers to different docks of a material handling facility, and the instruction causes the processor to generate a notification in response to the first data indicating that a trailer is present in a dock and the second data indicating that a trailer is not assigned to a dock, the notification indicating that the trailer is in the wrong dock.

[0270]

[0285] Example 39 includes the non-temporary computer-readable medium of Example 34, where a second data source corresponds to a second sensor, the second sensor monitors activity within a trailer docked, a condition corresponds to the duration of activity-free periods perceived within the trailer, and a command causes a processor to generate a notification in response to the duration exceeding a threshold.

[0271]

[0286] Example 40 includes the non-temporary computer-readable medium of Example 34, wherein an instruction further causes the processor to monitor third data indicating a user activation of a manually initiated actuator that enables the operation of a first device associated with a dock, a second data source corresponding to a second sensor, the second sensor monitoring the state of a second device which is interdependent with the operation of the first device, a condition corresponding to whether the state of the second device prevents the operation of the first device based on the interdependence, and the instruction further causes the processor to generate a notification in response to a user activation when the second data indicates that the state of the second device prevents the operation of the first device.

[0272]

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

[0273]

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

[0274]

[0289] Example 43 includes a non-temporary computer-readable medium containing instructions, which, when executed, cause a process to monitor at least first data indicating that a door associated with material handling equipment is in an open state, and second data indicating the passage of at least one person or object at an entrance associated with the open door, and in response to the first data indicating that the door is in an open state and the second data indicating that there is no passage of at least one person or object at the entrance, the process generates a notification indicating a door malfunction.

[0275]

[0290] Example 44 includes a non - transient computer - readable medium containing instructions that, when executed, cause a process to at least: aggregate dock data including (1) an indication of the operating state of equipment associated with a plurality of docks, (2) an indication of the activities of personnel 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 at which at least one of loading or unloading is being performed at one of the plurality of docks, for a plurality of docks; draw a plurality of dock icons corresponding to the plurality of docks; in response to a user selecting a first dock icon among the plurality of dock icons, draw an option menu for the user to select, and the options presented in the menu are dynamically updated based on the dock data.

[0276]

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

[0277]

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

[0278]

[0293] Example 47 includes the non - transient 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-temporary computer-readable medium of Example 46, wherein the timing indicator includes a progress bar corresponding to a first part of the trailer icon, which is drawn in a different color from a second part of the trailer icon, and the size of the first part increases in proportion to its duration.

[0280]

[0295] Example 49 includes the non-temporary computer-readable medium of Example 48, where the first part corresponds to the entire trailer icon when the duration exceeds a threshold period corresponding to the late fee period.

[0281]

[0296] Example 50 includes the non-temporary computer-readable medium of Example 45, where the instruction further causes the processor to draw a reservation time indicator within a trailer icon, the reservation time indicator showing the scheduled reservation time for the first trailer.

[0282]

[0297] Example 51 includes a non-temporary computer-readable medium of Example 50, where the instruction further causes the processor to draw a reservation countdown within a trailer icon, the reservation countdown indicating the time remaining until the scheduled reservation.

[0283]

[0298] Example 52 includes the non-temporary computer-readable medium of Example 45, wherein the instruction further causes the processor to draw a loading status indicator adjacent to a trailer icon, the loading status indicator indicating the progress of moving the cargo into or out of the first trailer, the progress of which corresponds to at least one of: before start, waiting on cargo, partially completed, or completed.

[0284]

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

[0285]

[0300] Example 54 includes the non-temporary computer-readable medium of Example 53, wherein the instruction further causes the processor to modify the appearance of at least one of the trailer icon or tractor unit icon when the cargo information indicates that the first trailer is temperature-controlled.

[0286]

[0301] Example 55 includes the non-temporary computer-readable medium of Example 45, wherein the instruction further causes the processor to draw a mutual docking status indicator adjacent to the trailer icon, the mutual docking status indicator indicating at least one of (1) cargo in a first trailer to be moved to a different trailer, or (2) cargo in a different trailer to be moved to the first trailer.

[0287]

[0302] Example 56 includes the non-temporary computer-readable medium of Example 45, wherein the instruction further causes the processor to draw a loading direction indicator adjacent to the trailer icon, the loading 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 with an outgoing load from which cargo is to be loaded onto the first trailer.

[0288]

[0303] Example 57 includes a non-temporary computer-readable medium of Example 45, where the instruction further causes the processor to draw a priority indicator adjacent to the trailer icon, the priority indicator indicating the priority of the first trailer.

[0289]

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

[0290]

[0305] Example 59 includes the non-temporary computer-readable medium of Example 45, where the instruction further causes the processor to draw a cargo counter within a trailer icon in response to dock data indicating that a first trailer is associated with incoming cargo, the cargo counter indicating the total number of cargo units to be moved out of the first trailer.

[0291]

[0306] Example 60 includes the non-temporary computer-readable medium of Example 59, wherein the instruction further causes the processor to determine the remaining number of cargo units to be removed from the first trailer based on activity detected within the trailer, and to dynamically update the cargo counter to indicate the remaining number of cargo units to be moved out of the first trailer, the remaining number being drawn along with the total number.

[0292]

[0307] Example 61 includes the non-temporary computer-readable medium of Example 45, where the instruction further causes the processor to draw at least one of the carrier code or trailer number adjacent to the trailer icon.

[0293]

[0308] Example 62 includes the non-temporary computer-readable medium of Example 44, wherein the instruction further causes the processor to draw a plurality of restraint signal icons adjacent to a corresponding dock icon among a plurality of dock icons, the plurality of restraint signal icons representing the state of a corresponding vehicle restraint device in a corresponding dock among the plurality of docks, the state of the vehicle restraint device including a first state in which the vehicle restraint device is engaged with the trailer in a corresponding do...

Claims

1. A device for monitoring the operation of material handling equipment, The first data indicating that the door associated with the material handling equipment is in an open state is monitored. The system monitors second data indicating the passage of at least one person or object at the entrance associated with the door in the open state. Data analyzer and A notification generator that generates a notification in response to the second data indicating that no person or object has passed through the entrance during the duration that the first data indicates the door is in the open state, wherein the notification indicates a false opening of the door. A device equipped with the following features.

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

3. The apparatus according to claim 1, wherein the data analyzer determines a trend of malfunctions over a certain period of time, and the notification generator provides instructions for the trend.

4. The apparatus according to claim 3, wherein the notification generator generates an alarm in response to the trend that exceeds a threshold.

5. The apparatus according to claim 1, wherein the data analyzer tracks the number of malfunctions detected over a certain period of time.

6. The apparatus according to claim 1, further comprising an I / O network interface for receiving the first and second data communicated from a controller associated with the door, wherein the data analyzer and the notification generator are located away from the controller.

7. The apparatus according to claim 6, wherein the door is one of a plurality of doors associated with the material handling equipment, and the I / O 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, wherein, when the instructions are executed, the processor receives at least: The system monitors the first data indicating that the door associated with the material handling equipment is in an open state. The system monitors second data indicating the passage of at least one person or object at the entrance associated with the door in the open state. A computer-readable medium which generates a notification in response to first data indicating that the door is in the open state and second data indicating that at least one of the persons or objects has not passed through the entrance, the notification indicating that the door has been erroneously opened.

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

10. The computer-readable medium according to claim 8, wherein the processor generates instructions for a trend of malfunctions over a period of time.

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

12. The computer-readable medium according to claim 8, wherein the processor tracks the number of malfunctions detected over a certain period of time.

13. The computer-readable medium according to claim 8, wherein the processor acquires the first and second data communicated from the controller associated with the door, and the processor is located away from the controller.

14. The computer-readable medium according to 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. A method for monitoring the operation of material handling equipment, A step of monitoring first data indicating that the door associated with the material handling equipment is in an open state, A step of monitoring second data indicating the passage of at least one person or object at an entrance associated with the door in the open state, A step of generating a notification in response to first data indicating that the door is in the open state and second data indicating that at least one of the person or object has not passed through the entrance, wherein the notification indicates that the door has been falsely activated. A method that includes this.

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

17. The method according to claim 15, further comprising the step of generating an indication of a false start trend over a period of time.

18. The method according to claim 17, further comprising the step of generating an alarm in response to the trend exceeding a threshold.

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

20. The method of claim 15, further comprising the steps of 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 located away from the controller.

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

22. A system for monitoring the operation of doors associated with material handling equipment, A first sensor that generates a first output indicating that the door is in an open state, A second sensor that generates a second output indicating the passage of at least one person or object at an entrance associated with the door in the open state, A processor that receives the first and second outputs, and when the first output indicates that the door is in the open state and the second sensor does not generate the second output, the processor detects the malfunction of the door. A system equipped with these features.

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

24. The system according to claim 22, wherein the processor generates instructions for a trend of false startups over a certain period of time.

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

26. The system according to claim 22, wherein the processor tracks the number of malfunctions detected over a certain period of time.

27. The system according to claim 22, wherein the processor is executed by a server located away from the first and second sensors.

28. The system according to 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