阅读说明：本技术 电梯门传感器融合、故障检测和服务通知 (Elevator door sensor fusion, fault detection and service notification ) 是由 M.J.特雷西 W.T.施密特 A.萨蒂 于 2019-08-19 设计创作，主要内容包括：提供了一种用于电梯门传感器融合、故障检测和服务通知的系统。所述系统包括：处理器；以及存储器,所述存储器包括计算机可执行指令,所述指令当由所述处理器执行时,使所述处理器执行操作。操作包括监测多个传感器的输出。确定多个传感器的输出是否遵循预期模式。至少部分基于确定多个传感器的输出不遵循预期模式：识别多个传感器中不遵循预期模式的传感器,并且传送指示该传感器正表现出意外行为的通知。(A system for elevator door sensor fusion, fault detection, and service notification is provided. The system comprises: a processor; and a memory including computer-executable instructions that, when executed by the processor, cause the processor to perform operations. The operations include monitoring outputs of a plurality of sensors. It is determined whether the outputs of the plurality of sensors follow a desired pattern. Based at least in part on determining that the outputs of the plurality of sensors do not follow an expected pattern: a sensor of the plurality of sensors that is not following the expected pattern is identified and a notification is transmitted indicating that the sensor is exhibiting unexpected behavior.)

1. A system configured to detect sensor failure, the system comprising:

a processor; and

a memory comprising computer-executable instructions that, when executed by the processor, cause the processor to perform operations comprising:

monitoring the output of a plurality of sensors;

determining whether the outputs of the plurality of sensors follow an expected pattern; and

based at least in part on determining that the outputs of the plurality of sensors do not follow the expected pattern:

identifying sensors of the plurality of sensors that do not follow the expected pattern; and

transmitting a notification indicating that the sensor is exhibiting unexpected behavior.

2. The system of claim 1, wherein the expected pattern comprises a maximum elapsed time between an output from the sensor and an output from a second sensor of the plurality of sensors.

3. The system of claim 1, wherein the expected pattern comprises a minimum frequency of output from the sensor.

4. The system of claim 1, wherein the expected pattern comprises an output from a second sensor occurring after an output from the sensor.

5. The system of claim 1, wherein the plurality of sensors detect objects proximate an elevator door of an elevator.

6. The system of claim 5, wherein the operations further comprise moving the elevator to a nudge mode based at least in part on determining that the outputs of the plurality of sensors do not follow the expected pattern.

7. The system of claim 5, wherein the operations further comprise removing the elevator from service based at least in part on determining that the outputs of the plurality of sensors do not follow the expected pattern.

8. The system of claim 1, wherein the sensor is a volume sensor.

9. The system of claim 1, wherein the sensor is a light curtain sensor.

10. The system of claim 1, wherein the operations further comprise updating the expected pattern based at least in part on the outputs of the plurality of sensors.

11. The system of claim 1, wherein the operations further comprise updating the expected pattern based at least in part on user input.

12. The system of claim 1, wherein the operations further comprise updating the expected pattern based at least in part on the outputs of the plurality of sensors and user inputs.

13. A method of detecting a sensor fault, the method comprising:

monitoring the output of a plurality of sensors;

determining whether the outputs of the plurality of sensors follow an expected pattern; and

based at least in part on determining that the outputs of the plurality of sensors do not follow the expected pattern:

identifying sensors of the plurality of sensors that do not follow the expected pattern; and

transmitting a notification indicating that the sensor is exhibiting unexpected behavior.

14. The method of claim 13, wherein the expected pattern comprises a maximum elapsed time between an output from the sensor and an output from a second sensor of the plurality of sensors.

15. The method of claim 13, wherein the expected pattern comprises a minimum frequency of output from the sensor.

16. The method of claim 13, wherein the expected pattern comprises an output from a second sensor occurring after an output from the sensor.

17. The method of claim 13, wherein the plurality of sensors detect an object proximate an elevator door of an elevator, and the method further comprises moving the elevator to a nudge mode based at least in part on determining that the outputs of the plurality of sensors do not follow the expected pattern.

18. The method of claim 13, wherein the plurality of sensors detect objects proximate elevator doors of an elevator, and the method further comprises removing the elevator from service based at least in part on determining that the outputs of the plurality of sensors do not follow the expected pattern.

19. The method of claim 13, wherein the method further comprises updating the expected pattern based at least in part on the outputs of the plurality of sensors.

20. The method of claim 13, wherein the method further comprises updating the expected pattern based at least in part on user input.

Technical Field

The subject matter disclosed herein relates to the field of elevator sensors that detect the presence of passengers, and more particularly, to elevator door sensor fusion, fault detection, and service notification.

Background

Many elevator safety events are related to passenger and door interactions and door impacts. Sensing in the door plane is currently required by code (as specified, for example, in the american society of mechanical engineers a 17.1) and is typically achieved by using light curtain sensors. If a fault is detected in the light curtain sensor, the elevator is placed in nudge mode until the light curtain sensor is repaired. To counteract the possibility of door strikes, new elevator systems may use multiple sensors. Multiple sensors are commonly used in tandem to sense passengers as they approach the doors and to initiate door reversal before the elevator sill is breached.

Disclosure of Invention

According to an embodiment, a system configured to perform elevator door sensor fusion, fault detection, and service notification is provided. The system comprises: a processor; and a memory including computer-executable instructions that, when executed by the processor, cause the processor to perform operations. The operations include monitoring outputs of a plurality of sensors. Determining whether the outputs of the plurality of sensors follow an expected pattern. Based at least in part on determining that the outputs of the plurality of sensors do not follow the expected pattern: identifying a sensor of the plurality of sensors that does not follow the expected pattern, and transmitting a notification indicating that the sensor is exhibiting unexpected behavior.

In addition to, or as an alternative to, one or more features described herein, further embodiments of the system may include: the expected pattern includes a maximum elapsed time between an output from the sensor and an output from a second sensor of the plurality of sensors.

In addition to, or as an alternative to, one or more features described herein, further embodiments of the system may include: the expected pattern includes a minimum frequency of output from the sensor.

In addition to, or as an alternative to, one or more features described herein, further embodiments of the system may include: the expected pattern includes an output from a second sensor occurring after an output from the sensor.

In addition to, or as an alternative to, one or more features described herein, further embodiments of the system may include: the plurality of sensors detect objects approaching an elevator door of the elevator.

In addition to, or as an alternative to, one or more features described herein, further embodiments of the system may include: the operations further comprise moving the elevator to a nudge mode based at least in part on determining that the outputs of the plurality of sensors do not follow the expected mode.

In addition to, or as an alternative to, one or more features described herein, further embodiments of the system may include: the operations further comprise removing the elevator from service based at least in part on determining that the outputs of the plurality of sensors do not follow the expected pattern.

In addition to, or as an alternative to, one or more features described herein, further embodiments of the system may include: the sensor is a volume sensor.

In addition to, or as an alternative to, one or more features described herein, further embodiments of the system may include: the sensor is a light curtain sensor.

In addition to, or as an alternative to, one or more features described herein, further embodiments of the system may include: the operations further include replacing the sensor based at least in part on determining that the outputs of the plurality of sensors do not follow the expected pattern.

In addition to, or as an alternative to, one or more features described herein, further embodiments of the system may include: the operations further include updating the expected pattern based at least in part on user input.

In addition to, or as an alternative to, one or more features described herein, further embodiments of the system may include: the operations further comprise updating the expected pattern based at least in part on the outputs of the plurality of sensors and user inputs.

According to an embodiment, a method of performing elevator door sensor fusion, fault detection, and service notification is provided. The method includes monitoring outputs of a plurality of sensors. Determining whether the outputs of the plurality of sensors follow an expected pattern. Based at least in part on determining that the outputs of the plurality of sensors do not follow the expected pattern: identifying a sensor of the plurality of sensors that does not follow the expected pattern, and transmitting a notification indicating that the sensor is exhibiting unexpected behavior.

In addition to, or as an alternative to, one or more features described herein, further embodiments of the method may include: the expected pattern includes a maximum elapsed time between an output from the sensor and an output from a second sensor of the plurality of sensors.

In addition to, or as an alternative to, one or more features described herein, further embodiments of the method may include: the expected pattern includes a minimum frequency of output from the sensor.

In addition to, or as an alternative to, one or more features described herein, further embodiments of the method may include: the expected pattern includes an output from a second sensor occurring after an output from the sensor.

In addition to, or as an alternative to, one or more features described herein, further embodiments of the method may include: the plurality of sensors detect objects proximate elevator doors of an elevator, and the method further comprises moving the elevator to a nudge mode based at least in part on determining that the outputs of the plurality of sensors do not follow the expected pattern.

In addition to, or as an alternative to, one or more features described herein, further embodiments of the method may include: the plurality of sensors detect objects proximate elevator doors of an elevator, and the method further comprises removing the elevator from service based at least in part on determining that the outputs of the plurality of sensors do not follow the expected pattern.

In addition to, or as an alternative to, one or more features described herein, further embodiments of the method may include: the operations further include updating the expected pattern based at least in part on user input.

In addition to, or as an alternative to, one or more features described herein, further embodiments of the method may include: the operations further comprise updating the expected pattern based at least in part on the outputs of the plurality of sensors and user inputs.

Technical effects of embodiments of the present disclosure include improved identification of sensor failures of users through sensor fusion and failure detection. Technical effects may also include enhanced passenger experience and better customer satisfaction by quickly relaying fault conditions to elevator service providers. The technical effect may further include ensuring robust sensor communication even when the sensor is in a failure state, such that the elevator is not prematurely forced into nudge mode, and operation continues in the safest state possible (e.g., nudge for code sensor failures, normal operation for non-code sensor failures) until a repair occurs.

The foregoing features and elements may be combined in various combinations, not exclusively, unless explicitly indicated otherwise. These features and elements, as well as their operation, will become more apparent from the following description and the accompanying drawings. It is to be understood, however, that the following description and the accompanying drawings are intended to be illustrative and explanatory in nature, and not restrictive.

Drawings

The present disclosure is illustrated by way of example and not limited in the accompanying figures in which like references indicate similar elements.

Fig. 1 is a schematic illustration of an elevator system that can employ various embodiments of the present disclosure;

fig. 2 is a simplified perspective view of a passenger detected by multiple sensors near an elevator door according to one or more embodiments of the present disclosure;

fig. 3 is a schematic diagram of a system for elevator door sensor fusion, fault detection, and service notification in accordance with one or more embodiments of the present disclosure; and

fig. 4 is a flow diagram illustrating a method of elevator door sensor fusion, fault detection, and service notification in accordance with one or more embodiments of the present disclosure.

Detailed Description

One or more embodiments of the present disclosure utilize multiple sensors to detect passenger presence and self-evaluate sensor health. If one or more sensors that normally follow a particular pattern no longer do so, this information can be used to identify faults within the sensors and preventative action can be taken to proactively ensure passenger safety. If the sensor associated with code compliance is deemed to be in a fault state, the elevator can be stopped or forced into a nudge mode and the elevator service provider can be contacted to ensure immediate resolution of the problem. In the event that the secondary sensor experiences a failure, the elevator may continue to operate in a normal manner (e.g., not forced into a nudge mode), the sensor of interest may be temporarily disabled, and a notification may be sent to the elevator service provider to resolve sooner or better.

In one or more embodiments of the invention, sensor health is self-assessed by monitoring actual sensor outputs and comparing them to expected sensor output patterns. If the actual output from the sensors contradicts the expected behavior of the sensors, sensor fusion will identify unexpected behavior and determine a series of actions that maximize occupant safety. For code-related sensors with unexpected behavior (those required for code compliance), the elevator may be forced into nudge mode and send a high priority notification to the elevator service provider to make repairs. For non-code dependent sensors exhibiting unexpected behavior (those sensors not needed for code compliance), the elevator may continue to operate normally and send a secondary priority notification to the elevator service provider.

As used herein, the term "sensor fusion" refers to the use of sensor outputs from multiple sensors that are combined into a single result. For example, sensor outputs from the light curtain sensor and the volume sensor may be combined to send a single command to the door controller of the elevator. In this example, the output from the light curtain sensor and the output from the volume sensor are fused to create a single command to control the operation of the elevator doors. In another example, sensor outputs from the light curtain sensor and the volume sensor are combined to determine whether the volume sensor is exhibiting the expected behavior. In this example, the sensor output from the light curtain sensor is expected to be generated within a threshold amount of time of generating the output from the volume sensor, and the timing of the outputs is fused to determine whether the sensor is operating in an expected manner. In one or more embodiments, the output from the sensor includes a timestamp indicating the exact time that the sensor creating the output was triggered.

As used herein, the term "nudge mode" refers to an elevator mode in which the doors are slowly closed while a buzzer or a tone (tonetones) signals the passengers to avoid the doors.

As used herein, the term "service provider" refers to any person or entity that is monitoring the condition of a product, such as an elevator. Upon notifying that an element of the product is exhibiting unexpected behavior (e.g., the sensor is not operating as expected), the service provider either repairs the product or notifies the correct organization to repair the product.

Embodiments of the invention are not limited to environments including elevators. Embodiments may be implemented in any environment in which sensors are used to indicate the presence of a person and the sensors track the expected patterns of the person in the environment.

Fig. 1 is a perspective view of an elevator system 101, the elevator system 101 including an elevator car 103, a counterweight 105, a tension member 107, a guide rail 109, a machine 111, a position reference system 113, and a controller 115. The elevator car 103 and counterweight 105 are connected to each other by a tension member 107. Tension members 107 may comprise or be configured as, for example, ropes, cables, and/or coated steel belts. The counterweight 105 is configured to balance the load of the elevator car 103 and to facilitate movement of the elevator car 103 within the elevator shaft 117 and along the guide rails 109 relative to the counterweight 105 simultaneously and in opposite directions.

The tension member 107 engages a machine 111, the machine 111 being part of an overhead structure of the elevator system 101. The machine 111 is configured to control movement between the elevator car 103 and the counterweight 105. The position reference system 113 may be mounted on a fixed part of the top of the elevator shaft 117, e.g. on a support or guide rails, and may be configured to provide position signals related to the position of the elevator car 103 within the elevator shaft 117. In other embodiments, position reference system 113 may be mounted directly to the moving components of machine 111, or may be located in other locations and/or configurations known in the art. The position reference system 113 can be any device or mechanism for monitoring the position of the elevator car and/or counterweight as is known in the art. For example, but not limiting of, the position reference system 113 can be an encoder, sensor, or other system, and can include velocity sensing, absolute position sensing, and the like, as will be understood by those skilled in the art.

As shown, the controller 115 is located in a controller room 121 of the elevator shaft 117 and is configured to control operation of the elevator system 101, and in particular the elevator car 103. For example, the controller 115 may provide drive signals to the machine 111 to control acceleration, deceleration, leveling, stopping, etc. of the elevator car 103. The controller 115 may also be configured to receive position signals from the position reference system 113 or any other desired position reference device. The elevator car 103 can stop at one or more landings 125 as controlled by the controller 115 when moving up or down along guide rails 109 within the elevator shaft 117. Although shown in the controller room 121, one skilled in the art will recognize that the controller 115 can be located and/or configured elsewhere or locations within the elevator system 101. In one embodiment, the controller may be located remotely or in the cloud.

The machine 111 may include a motor or similar drive mechanism. According to an embodiment of the present disclosure, the machine 111 is configured to include an electrically driven motor. The power supply to the motor may be any power source, including the power grid, which is supplied to the motor along with other components. The machine 111 may include a traction sheave that transmits force to the tension member 107 to move the elevator car 103 within the elevator shaft 117.

Although shown and described with a roping system including tension members 107, elevator systems employing other methods and mechanisms for moving an elevator car within an elevator hoistway may employ embodiments of the present disclosure. For example, embodiments may be used in a ropeless elevator system that uses a linear motor to impart motion to an elevator car. Embodiments may also be used in ropeless elevator systems that use a hydraulic hoist to impart motion to an elevator car. Fig. 1 is a non-limiting example presented for purposes of illustration and explanation only.

In other embodiments, the system includes a conveyor system that moves passengers between floors and/or along a single floor. Such transport systems may include escalators, people mover, and the like. Thus, the embodiments described herein are not limited to elevator systems such as that shown in fig. 1.

Turning now to fig. 2, a simplified perspective view 200 of a passenger detected by multiple sensors near or proximate to an elevator door is generally shown, in accordance with one or more embodiments of the present disclosure. FIG. 2 depicts a dual sensor door detection system having a light curtain sensor 206 for sensing objects in the door plane and a volume sensor 208 for detecting an approaching passenger 202 at a landing 125. Further, fig. 2 depicts a door controller 210, e.g., located atop the elevator car 103, the door controller 210 being capable of receiving output signals from the sensors and including logic to perform at least a subset of the processes described herein. In one or more embodiments, the door controller 210 directs operation of the passenger door 204, which passenger door 204 provides access to the elevator cab 103. In an alternative embodiment, all or a subset of the door controllers 210 are located in another location than the top of the elevator car, such as in the elevator controller 115.

As shown in fig. 2, passenger 202 is standing outside (e.g., 300 mm away) passenger door 204 with one hand 212 in the door sill. A hand 212 in the threshold will be sensed by the light curtain sensor 206 and the light curtain sensor 206 will instruct the door controller 210 to open the door 204. The presence of a passenger in front of the door 204 will be sensed by the volume sensor 208, which volume sensor 208 will also instruct the door controller 210 to open the door. When an approaching passenger 202 holds a hand 212 in the threshold, as shown in fig. 1, it is expected that both the light curtain sensor 206 and the volume sensor 208 will be triggered simultaneously (e.g., they will generate an output), or turned off in time. The maximum expected amount of time between triggered sensors may be specified by a threshold amount of time, such as one or five seconds. If the light curtain sensor 206 is triggered without an accompanying trigger from the volume sensor 208 within a threshold amount of time, that indicates that the volume sensor 208 may not be operating properly and that action is taken. The action may include alerting the service provider to: the volume sensor 208 may be faulty and the action may also include requesting a change in the operating mode of the elevator, for example by sending a request to the door controller 210. In one or more embodiments, action is taken only after a prescribed number of times the expected pattern is not detected.

Although it is possible to have a situation where the volume sensor 208 and the light curtain sensor 206 are not triggered at similar temporal proximity (e.g. when a person enters the door plane from the elevator car 103 to hold the elevator for a person), they will normally be triggered both when a person enters and exits the elevator car 103. If the light curtain sensor 206 is always triggered without the volume sensor 208 being triggered, or vice versa, the elevator can assume that the sensor is faulty and can take action, such as sending a notification to the elevator service provider.

One or more embodiments of sensor fusion and fault detection can be used with any combination of sensors positioned to detect people near elevator thresholds, such as, but not limited to: light curtain sensors, volume sensors, motion detector sensors, door edge detector sensors, door frame detector sensors, and cameras. One or more embodiments can be implemented with more than two sensors, and the sensors can be located inside or outside of the elevator car 103 (as shown in fig. 2). In one or more embodiments, more than one sensor of each type of sensor may be monitoring passengers entering the elevator car 103 from the landing 125. Further, more than one sensor of each type of sensor may be monitoring passengers exiting the elevator car 103 to the landing 125. In either case (e.g., monitoring entry or exit), the sensors can be located inside the elevator car 103 and/or outside the elevator car 103. Additional sensors can be located in a hallway near the landing 125 and/or on a route expected to be taken by a person going to the landing 125.

Turning now to fig. 3, a schematic diagram of a system 300 for elevator door sensor fusion, fault detection, and service notification is generally shown, in accordance with one or more embodiments of the present disclosure. The system 300 shown in fig. 3 includes a door controller 210, a logic card 302, a volume sensor 208, a light curtain sensor 206, and an elevator service provider 310. The logic card 302 is shown in FIG. 3 as a physical device separate from the door controller 210, however in one or more embodiments, the functions performed by the logic card 302 are integrated into the door controller 210.

As shown in fig. 3, the logic card 302 includes sensor fusion logic 304, fault detection logic 306, and service notification logic 308. The sensor fusion logic 304 receives sensor output from a sensor that is monitoring the entry of passengers into an elevator car (such as the elevator car 103 of fig. 2) and/or the exit from an elevator car (such as the elevator car 103 of fig. 2). Two sensors are shown in fig. 3, namely the volume sensor 208 of fig. 2 and the light curtain sensor 206 of fig. 2. The logic card 302 communicates with the sensors via any short-range wired or wireless communication method known in the art, such as but not limited to Wi-Fi, bluetooth, Zigbee, and infrared. In an embodiment, all subsets of the processing performed by the sensor fusion logic 304, the fault detection logic 306, and the service notification logic 308 are performed remotely from the logic card 302, e.g., in the cloud.

In one or more embodiments, the fault detection logic 306 compares the expected pattern of sensor outputs to the received or actual pattern of sensor outputs. The expected pattern can be applied to expected outputs from a single sensor and expected output sequences for multiple sensors. An example mode is that it may be expected that the volume sensor 208 is triggered at least once per hour during a work cycle (or any other time range). If no output from the volume sensor 208 is received every hour, this may indicate that the volume sensor 208 is not functioning properly. Another example mode is if someone is assigned an elevator, e.g. by a destination entry terminal, they are expected to be at the elevator doors for a prescribed amount of time. If the volume sensor 208 has not detected any people after the elevator is assigned, this may indicate that the volume sensor is not working.

The expected sensor output pattern may be entered by a user (such as a system administrator) via a user interface. Additionally or alternatively, an expected sensor output pattern may be generated and updated based on an observed pattern of sensor outputs. Alternatively, the expected sensor output pattern may be entered by a system administrator and then updated based on the observed pattern. For example, a system administrator may enter an expected elapsed time between two sensors being triggered. The actual amount of time observed based on the sensor output may be longer than the expected elapsed time, and the system may update the expected elapsed time to the longer amount of time.

In one or more embodiments, the fault detection logic 306 determines or selects an action to take based at least in part on detecting a sensor that does not follow the expected pattern(s). The selection can be based on the type of sensor that does not follow the expected pattern (e.g., code or non-code dependent). The action may include changing the operating mode of the elevator to a nudge mode or removing the elevator car from service. This action can be communicated to door controller 210 via a communication interface, which can be accomplished through any short or long range wired or wireless communication method known in the art, through a network such as, but not limited to, the Internet, a Local Area Network (LAN), and a Wide Area Network (WAN). Examples of short-range wireless communication methods that can be utilized include, but are not limited to: Wi-Fi, Bluetooth, Zigbee, and Infrared.

The actions determined by the fault detection logic 306 may also include generating an alert to be sent to the elevator service provider 310. The alert may be sent by the service notification logic 308 to the elevator service provider 310. The alert can be communicated to the elevator service provider 310 via a communication interface, which can be accomplished through any short or long range wired or wireless communication method known in the art, through a network such as, but not limited to, the internet, a Local Area Network (LAN), a Wide Area Network (WAN), and a cellular network.

Although not shown, the logic card 302 can include hardware devices, such as a processor for executing the sensor fusion logic 304, the fault detection logic 306, and the service notification logic 308, which can each include hardware instructions and/or software instructions. The processor may be a custom made or commercially available processor, a Central Processing Unit (CPU), an auxiliary processor among several processors, a semiconductor based microprocessor (in the form of a microchip or chip set), a macroprocessor, or other means for executing instructions. In addition, the logic card 302 may include memory for storing instructions and desired patterns. The memory may include one or a combination of the following: volatile memory elements (e.g., random access memory RAM, such as DRAM, SRAM, SDRAM, and the like) and nonvolatile memory elements (e.g., ROM, Erasable Programmable Read Only Memory (EPROM), Electrically Erasable Programmable Read Only Memory (EEPROM), Programmable Read Only Memory (PROM), magnetic tape, compact disc read only memory (CD-ROM), disks, magnetic disks, cartridges, tape cards, and the like). The instructions in the memory may comprise one or more separate programs, each program comprising an ordered listing of executable instructions for implementing logical functions. In an embodiment, the instructions are executed in the cloud.

It should be understood that although specific elements are defined separately in the schematic block diagram of fig. 3, each or any of the elements may be otherwise combined or separated via hardware and/or software.

Turning now to fig. 4, a flow diagram 400 illustrating a method of elevator door sensor fusion, fault detection, and service notification is generally shown, in accordance with one or more embodiments of the present disclosure. In accordance with one or more embodiments, all or a subset of the processing shown in fig. 4 is performed by the logic card 302 of fig. 3 and/or by computer instructions located in the cloud. At block 402, the outputs of a plurality of sensors (such as the volume sensor 208 of FIG. 2 and the light curtain sensor 206 of FIG. 2) are monitored. In an embodiment, the monitoring is performed by the sensor fusion logic 304 of fig. 3 and when the sensors detect an object, such as an approaching elevator passenger, they are triggered to send an output to a monitor (e.g., the sensor fusion logic 304). In an embodiment, the sensor is positioned to identify or locate an object, such as a passenger inside or outside the elevator car, near the elevator doors.

At block 404, the output of the sensor is compared to the expected pattern(s), and at block 406, it is determined whether the output of the sensor follows the expected pattern(s). The expected pattern(s) may specify a maximum elapsed time between the output from the first sensor and the output from the second sensor. For example, the first sensor may be a volume sensor located outside of the elevator car, such as volume sensor 208 of fig. 1, and the second sensor may be a light curtain sensor across a threshold, such as light curtain sensor 206 of fig. 1. In this case, the volume sensor is expected to detect passengers approaching the elevator door, and the light curtain sensor is expected to detect when a passenger is in the door sill. The expected mode may specify any time an output is received from the light curtain sensor, within the previous two seconds (the maximum elapsed time in this example) the output should have been received from the volume sensor. If the monitored output does not follow this pattern (e.g., no output was received from the volume sensor within the first two seconds before the output was received from the light curtain), this may be an indication that the volume sensor is not operating properly.

The expected pattern may also specify a sequence of outputs from two or more sensors, e.g., a first sensor is expected to be triggered before a second sensor. The expected pattern may further specify a relative amount of output expected from each sensor, e.g., a first sensor is expected to be triggered twice as often as a second. The expected pattern may further specify an expected or minimum frequency at which the sensor is to be triggered during a particular time period. The time period may be a number of hours, days or months. The time period may also specify other parameters such as the time of day or month, etc. For example, it is contemplated that the first sensor is triggered at least once per hour during the morning hours of the work day.

If it is determined at block 406 of FIG. 4 that the output from the sensor follows the expected pattern(s), processing continues at block 402 with monitoring the output from the sensor.

If it is determined at block 406 of FIG. 4 that the output from the sensor does not follow the expected pattern(s) indicating that the sensor may be faulty, processing continues at block 408 with determining actions to take. The action can be selected based on the type of sensor that does not follow the intended pattern. For example, if the sensors are operating normally for code compliance requirements (the sensors are code dependent sensors), then the action may include placing the elevator in a nudge mode and sending a high priority notification to the elevator service provider for repair or replacement of the sensors. In another example, if the sensors are not required to operate normally for code compliance (the sensors are non-code dependent sensors), the action may include sending a second level priority notification to the elevator service provider for repairing or replacing the sensors. At block 410, the action is initiated or performed, and processing continues at block 402.

While the above description has described the flow of fig. 4 in a particular order, it should be understood that the order of the steps may be changed unless otherwise specifically claimed in the appended claims.

As described above, embodiments can take the form of processor-implemented processes and apparatuses (such as processors) for practicing those processes. Embodiments can also take the form of computer program code containing instructions embodied in tangible media, such as network cloud storage, SD cards, flash drives, floppy diskettes, CD ROMs, hard drives, or any other computer-readable storage medium, wherein, when the computer program code is loaded into and executed by a computer, the computer becomes an apparatus for practicing the embodiments. Embodiments can also take the form of computer program code, for example, whether stored in a storage medium, loaded into and/or executed by a computer, or transmitted over some transmission medium, such as over electrical wiring or cabling, through fiber optics, or via electromagnetic radiation, wherein, when the computer program code is loaded into and executed by a computer, the computer becomes an apparatus for practicing the embodiments. When implemented on a general-purpose microprocessor, the computer program code segments configure the microprocessor to create specific logic circuits.

The term "about" is intended to include a degree of error associated with a measurement based on a particular quantity of equipment and/or manufacturing tolerances available at the time of filing the application.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the disclosure. As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms "comprises" and/or "comprising," when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, element components, and/or groups thereof.

Those skilled in the art will understand that various exemplary embodiments have been illustrated and described herein, each having certain features in certain embodiments, but the disclosure is not so limited. Rather, the disclosure can be modified to incorporate any number of variations, alterations, substitutions, combinations, sub-combinations or equivalent arrangements not heretofore described, but which are commensurate with the scope of the disclosure. Additionally, while various embodiments of the disclosure have been described, it is to be understood that aspects of the disclosure may include only some of the described embodiments. Accordingly, the disclosure is not to be seen as limited by the foregoing description, but is only limited by the scope of the appended claims.