Abstract
An elevator monitoring system, includes: one or more sensors; a controller arranged to acquire sensor data from the one or more sensors; analyse the sensor data to identify a first event and a second event, the first event corresponding to an elevator door motion; categorize the first event based on the sensor data for the first event and the second event.
Claims
1. An elevator monitoring system, comprising: one or more sensors; a controller arranged to: acquire sensor data from the one or more sensors; analyse the sensor data to identify a first event and a second event, the first event corresponding to an elevator door motion; categorize the first event based on the sensor data for the first event and the second event.
2. An elevator monitoring system as claimed in claim 1, wherein the one or more sensors comprises an accelerometer and the controller is arranged to acquire accelerometer data.
3. An elevator monitoring system as claimed in claim 2, wherein the controller is arranged to analyse the accelerometer data to identify the first event.
4. An elevator monitoring system as claimed in claim 3, wherein identifying the first event comprises identifying a period of elevator door motion between two periods of the elevator door being stationary.
5. An elevator monitoring system as claimed in claim 1, wherein the second event is an elevator car start or an elevator car stop event.
6. An elevator monitoring system as claimed in claim 1, wherein the second event is an earlier elevator door motion event.
7. An elevator monitoring system as claimed in claim 6, wherein the second event is an earlier elevator door opening event.
8. An elevator monitoring system is claimed in claim 7, wherein the second event is the first elevator door opening event following the most recent elevator car stop event.
9. An elevator monitoring system as claimed in claim 6, wherein the controller is arranged to categorize the first event based on a correspondence of the sensor data for the first event and the sensor data for the second event.
10. An elevator monitoring system as claimed in claim 1, wherein categorizing the first event comprises at least one of: categorizing the first event as a door open event; categorizing the first event as a door close event; and categorizing the first event as a door reversal event.
11. An elevator monitoring system as claimed in claim 1, wherein categorizing the first event comprises adjusting a counter corresponding to a category.
12. An elevator monitoring system as claimed in claim 1, wherein categorizing the first event is based on an amount of time between the first event and the second event.
13. An elevator monitoring system as claimed in claim 12, wherein when the second event precedes the first event by a predetermined amount of time, the controller is arranged to categorize the first event as a door open event.
14. An elevator monitoring system as claimed in claim 1, wherein categorizing the first event is based on a previously determined state of the elevator door.
15. A method of monitoring an elevator system comprising: acquiring sensor data from one or more sensors; analysing the sensor data to identify a first event and a second event, the first event corresponding to an elevator door motion; categorize the first event based on the sensor data for the first event and the second event.
Description
BRIEF DESCRIPTION OF DRAWINGS
[0023] FIG. 1 is a schematic illustration of an elevator system according to examples of the present disclosure;
[0024] FIG. 2 is a schematic illustration of a sensor system for the elevator system of FIG. 1, according to examples of the present disclosure;
[0025] FIG. 3 is a schematic illustration of the location of a sensor system for the elevator system of FIGS. 1 and 2, according to examples of the present disclosure;
[0026] FIG. 4 is a schematic illustration of a sensing unit according to examples of the present disclosure;
[0027] FIG. 5 illustrates a process for elevator door monitoring;
[0028] FIG. 6 is a flow chart of a first example of a door monitoring process;
[0029] FIG. 7 is a flow chart of a second example of a door monitoring process; and
[0030] FIG. 8 shows an algorithm with pseudo-code for a door monitoring process similar to FIG. 7.
DETAILED DESCRIPTION
[0031] FIG. 1 is a perspective view of an 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 the tension member 107. The tension member 107 may include or be configured as, for example, ropes, steel cables, and/or coated-steel belts. The counterweight 105 is configured to balance a load of the elevator car 103 and is configured to facilitate movement of the elevator car 103 concurrently and in an opposite direction with respect to the counterweight 105 within an elevator shaft 117 and along the guide rail 109.
[0032] The tension member 107 engages the machine 111, which is 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 at the top of the elevator shaft 117, such as on a support or guide rail, and may be configured to provide position signals related to a position of the elevator car 103 within the elevator shaft 117. In other embodiments, the position reference system 113 may be directly mounted to a moving component of the machine 111, or may be located in other positions and/or configurations as known in the art. The position reference system 113 can be any device or mechanism for monitoring a position of an elevator car and/or counter weight, as known in the art. For example, without limitation, the position reference system 113 can be an encoder, sensor, or other system and can include velocity sensing, absolute position sensing, etc., as will be appreciated by those of skill in the art.
[0033] The controller 115 is located, as shown, in a controller room 121 of the elevator shaft 117 and is configured to control the operation of the elevator system 101, and particularly the elevator car 103. For example, the controller 115 may provide drive signals to the machine 111 to control the 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. When moving up or down within the elevator shaft 117 along guide rail 109, the elevator car 103 may stop at one or more landings 125 as controlled by the controller 115. Although shown in a controller room 121, those of skill in the art will appreciate that the controller 115 can be located and/or configured in other locations or positions within the elevator system 101. In one embodiment, the controller may be located remotely or in the cloud.
[0034] The machine 111 may include a motor or similar driving mechanism. In accordance with embodiments of the disclosure, the machine 111 is configured to include an electrically driven motor. The power supply for the motor may be any power source, including a power grid, which, in combination with other components, is supplied to the motor. The machine 111 may include a traction sheave that imparts force to tension member 107 to move the elevator car 103 within elevator shaft 117.
[0035] Although shown and described with a roping system including tension member 107, elevator systems that employ other methods and mechanisms of moving an elevator car within an elevator shaft may employ embodiments of the present disclosure. For example, embodiments may be employed in ropeless elevator systems using a linear motor or pinched wheel propulsion to impart motion to an elevator car. Embodiments may also be employed in ropeless elevator systems using a hydraulic lift to impart motion to an elevator car. FIG. 1 is merely a non-limiting example presented for illustrative and explanatory purposes.
[0036] In other embodiments, the system comprises a conveyance system that moves passengers between floors and/or along a single floor. Such conveyance systems may include escalators, people movers, etc. Accordingly, embodiments described herein are not limited to elevator systems, such as that shown in FIG. 1. In one example, embodiments disclosed herein may be applicable to conveyance systems such as an elevator system 101 and a conveyance apparatus of the conveyance system such as an elevator car 103 of the elevator system 101. In another example, embodiments disclosed herein may be applicable to conveyance systems such as an escalator system and a conveyance apparatus of the conveyance system such as a moving stair of the escalator system.
[0037] Referring now to FIG. 2, with continued referenced to FIG. 1, a view of a sensor system 200 including a sensing apparatus 210 is illustrated, according to an embodiment of the present disclosure. The sensing apparatus 210 is configured to detect sensor data 202 of the elevator car 103 and transmit the sensor data 202 to a remote device 280. Sensor data 202 may include but is not limited to pressure data 314, vibratory signatures (i.e., vibrations over a period of time) or accelerations 312 and derivatives or integrals of accelerations 312 of the elevator car 103, such as, for example, distance, velocity, jerk, jounce, snap . . . etc. Sensor data 202 may also include light, sound, humidity, and temperature, or any other desired data parameter. The pressure data 314 may include atmospheric air pressure within the elevator shaft 117. It should be appreciated that, although particular systems are separately defined in the schematic block diagrams, each or any of the systems may be otherwise combined or separated via hardware and/or software. For example, the sensing apparatus 210 may be a single sensor or may be multiple separate sensors that are interconnected.
[0038] In an embodiment, the sensing apparatus 210 is configured to transmit sensor data 202 that is raw and unprocessed to the controller 115 of the elevator system 101 for processing. In another embodiment, the sensing apparatus 210 is configured to process the sensor data 202 prior to transmitting the sensor data 202 to the controller 115 through a processing method, such as, for example, edge processing. In another embodiment, the sensing apparatus 210 is configured to transmit sensor data 202 that is raw and unprocessed to a remote system 280 for processing. In yet another embodiment, the sensing apparatus 210 is configured to process the sensor data 202 prior to transmitting the sensor data 202 to the remote device 280 through a processing method, such as, for example, edge processing.
[0039] The processing of the sensor data 202 may reveal data, such as, for example, a number of elevator door openings/closings, elevator door time, vibrations, vibratory signatures, a number of elevator rides, elevator ride performance, elevator flight time, probable car position (e.g. elevation, floor number), releveling events, rollbacks, elevator car 103 x, y acceleration at a position: (i.e., rail topology), elevator car 103 x, y vibration signatures at a position: (i.e., rail topology), door performance at a landing number, nudging event, vandalism events, emergency stops, etc.
[0040] The remote device 280 may be a computing device, such as, for example, a desktop, a cloud based computer, and/or a cloud based artificial intelligence (AI) computing system. The remote device 280 may also be a mobile computing device that is typically carried by a person, such as, for example a smartphone, PDA, smartwatch, tablet, laptop, etc. The remote device 280 may also be two separate devices that are synced together, such as, for example, a cellular phone and a desktop computer synced over an internet connection.
[0041] The remote device 280 may be an electronic controller including a processor 282 and an associated memory 284 comprising computer-executable instructions that, when executed by the processor 282, cause the processor 282 to perform various operations. The processor 282 may be, but is not limited to, a single-processor or multi-processor system of any of a wide array of possible architectures, including field programmable gate array (FPGA), central processing unit (CPU), application specific integrated circuits (ASIC), digital signal processor (DSP) or graphics processing unit (GPU) hardware arranged homogenously or heterogeneously. The memory 284 may be but is not limited to a random access memory (RAM), read only memory (ROM), or other electronic, optical, magnetic or any other computer readable medium.
[0042] The sensing apparatus 210 may be configured to transmit the sensor data 202 to the controller 115 or the remote device 280 via short-range wireless protocols 203 and/or long-range wireless protocols 204. Short-range wireless protocols 203 may include but are not limited to Bluetooth, Wi-Fi, HaLow (801.11ah), zWave, ZigBee, or Wireless M-Bus. Using short-range wireless protocols 203, the sensing apparatus 210 is configured to transmit the sensor data 202 directly to the controller 115 or to a local gateway device 240 and the local gateway device 240 is configured to transmit the sensor data 202 to the remote device 280 through a network 250 or to the controller 115. The network 250 may be a computing network, such as, for example, a cloud computing network, cellular network, or any other computing network known to one of skill in the art. Using long-range wireless protocols 204, the sensing apparatus 210 may be configured to transmit the sensor data 202 to the remote device 280 through a network 250. Long-range wireless protocols 204 may include but are not limited to cellular, satellite, LTE (NB-IoT, CAT M1), LoRa, Satellite, Ingenu, or SigFox.
[0043] The sensing apparatus 210 may be configured to detect sensor data 202 including acceleration in any number of directions. In an embodiment, the sensing apparatus may detect sensor data 202 including accelerations 312 along three axes, an X axis, a Y axis, and a Z axis, as show in in FIG. 2. The X axis may be perpendicular to the doors 104 of the elevator car 103, as shown in FIG. 2. The Y axis may be parallel to the doors 104 of the elevator car 103, as shown in FIG. 2. The Z axis may be aligned vertically parallel with the elevator shaft 117 and the pull of gravity, as shown in FIG. 2. The acceleration data 312 may reveal vibratory signatures generated along the X-axis, the Y-axis, and the Z-axis.
[0044] FIG. 3 shows a possible installation location of the sensing apparatus 210 within the elevator system 101. The sensing apparatus 210 may include a magnet (not show) to removably attach to the elevator car 103. In the illustrated embodiment shown in FIG. 3, the sensing apparatus 210 may be installed on the door hanger 104a and/or the door 104 of the elevator system 101. It is understood that the sensing apparatus 210 may also be installed in other locations other than the door hanger 104a and the door 104 of the elevator system 101. It is also understood that multiple sensing apparatus 210 are illustrated in FIG. 3 to show various locations of the sensing apparatus 210 and the embodiments disclosed herein may include one or more sensing apparatus 210. In another embodiment, the sensing apparatus 210 may be attached to a door header 104e of a door 104 of the elevator car 103. In another embodiment, the sensing apparatus 210 may be located on a door header 104e proximate a top portion 104f of the elevator car 103. In another embodiment, the sensing apparatus 210 is installed elsewhere on the elevator car 103, such as, for example, directly on the door 104.
[0045] As shown in FIG. 3, the sensing apparatus 201 may be located on the elevator car 103 in the selected areas 106, as shown in FIG. 3. The doors 104 are operably connected to the door header 104e through a door hanger 104a located proximate a top portion 104b of the door 104. The door hanger 104a includes guide wheels 104c that allow the door 104 to slide open and closed along a guide rail 104d on the door header 104e. Advantageously, the door hanger 104a is an easy to access area to attach the sensing apparatus 210 because the door hanger 104a is accessible when the elevator car 103 is at landing 125 and the elevator door 104 is open. Thus, installation of the sensing apparatus 210 is possible without taking special measures to take control over the elevator car 103. For example, the additional safety of an emergency door stop to hold the elevator door 104 open is not necessary as door 104 opening at landing 125 is a normal operation mode. The door hanger 104a also provides ample clearance for the sensing apparatus 210 during operation of the elevator car 103, such as, for example, door 104 opening and closing. Due to the mounting location of the sensing apparatus 210 on the door hanger 104a, the sensing apparatus 210 may detect open and close motions (i.e., acceleration) of the door 104 of the elevator car 103 and a door at the landing 125. Additionally mounting the sensing apparatus 210 on the hanger 104a allows for recording of a ride quality of the elevator car 103.
[0046] FIG. 4 illustrates an example of a sensing apparatus 210 of FIGS. 2 and 3 in more detail. The sensing apparatus includes a controller 212, a plurality of sensors 217 in communication with the controller 212, a communication module 220 in communication with the controller 212, and a power source 222 electrically connected to the controller 212. The plurality of sensors 217 includes an inertial measurement unit (IMU) 218 and a pressure sensor 228. The IMU 218 comprises three accelerometers 229 and is configured to detect acceleration of the elevator car 103 and/or elevator car door 104, and to generate the acceleration data 312. The pressure sensor 228 (which may be, for example a pressure altimeter or a barometric altimeter) is configured to detect an atmospheric air pressure within the elevator hoistway 117, and to generate the pressure data 314. Both the IMU 218 and the pressure sensor 228 are in communication with the controller 212 of the sensing apparatus 210. It will be appreciated that while the pressure sensor 228 may be used to provide further information on elevator car 103 movement, it can also be omitted in some examples. In some examples, the plurality of sensors 217 may also include additional sensors such as a light sensor, a microphone, a humidity sensor, and a temperature sensor.
[0047] The power source 222 of the sensing apparatus 210 is configured to store and supply electrical power to the sensing apparatus 210. The power source 222 may include an energy storage system, such as a battery or a capacitor, or other appropriate energy storage system known in the art.
[0048] The communication module 220 is configured to allow the controller 212 of the sensing apparatus 210 to communicate with the remote device 280 and/or controller 115 through at least one of short-range wireless protocols 203 and long-range wireless protocols 204 as described above.
[0049] The controller 212 of the sensing apparatus 210 includes a processor 214 and a memory 216 comprising computer-executable instructions that, when executed by the processor 214, cause the processor 214 to perform various operations such as processing of the sensor data 202 collected by the IMU 218 and the pressure sensor 228 to determine information about the motion of the elevator car 103. The sensing apparatus 210 also comprises a buffer 227, configured to store a pre-set number of data entries.
[0050] FIG. 5 illustrates an example of a method of categorizing door motion based on sensor data. The method begins at step 500 in which sensor data is acquired from one or more sensors. The one or more sensors may be one accelerometer 229 or a set of accelerometers (e.g. IMU 218) which may include a set of three mutually orthogonal accelerometers, or it may include one or more of the additional sensors discussed above. In step 502 the sensor data that was acquired in step 500 is analysed to identify a first event and a second event within the data. The first event is the door 104 motion that is to be categorized by this process. The second event is another event that may be another door 104 motion event or may be an elevator car 103 motion event. Where the second event is another door 104 motion event, it may for example be a door 104 opening event or a door 104 closing event or a door 104 reversal event. Where the second event is a car 103 motion event, it may for example be a car 103 start event (leaving a landing 125) or a car 103 stop event (arriving at a landing 125). In step 504 the first event is categorized based on the sensor data for the first event and the sensor data for the second event. In this step the first event is categorized not only based on the sensor data acquired in respect of that first event, but also based on the sensor data acquired in respect of the second event. Therefore, the categorization is based on knowledge of some other system motion (which occur before or after the first event). Taking into account this additional sensor data for a second event means that the sensor data can be acquired at a lower rate (i.e. lower time resolution data) while still acquiring sufficient information to make an accurate categorization of the first event. The data that is acquired for the second event will in many cases be acquired as part of normal system operation anyway. Therefore, this system makes use of additional information that is already present, while allowing a low sampling rate to be used for the sensor data. It should be noted that not all sensor data from different sensors needs to be acquired at the same rate and can be selected according to the sensor and the needs of the system.
[0051] FIG. 6 shows in detail one example of a categorization process that can be used to categorize a door 104 motion. Starting at step 600, the process checks if this is the first door 104 motion since the car 103 stopped at a landing 125. If “Yes”, then in step 602 the door 104 motion event is categorized as a door opening event. This is based on the assumption that the door 104 is closed when the elevator car 103 comes to a stop at the landing 125 and therefore the next door 104 motion must be a door opening event. In this case, the second event is a car 103 motion event and the first event is categorized based on the first event (motion is detected) and the second event (car stop event detected). If step 600 concludes that the door motion is not the first motion after the car 103 has come to a stop (“No”) then the process proceeds to step 604 for further analysis. In step 604 the process checks if the door 104 motion signature matches a first door open signature. If “Yes”, then the process proceeds to step 608 in which the process checks if the last known door 104 state was “open”. If “Yes” then an error has occurred as a door 104 open event has apparently been detected when the door state was already thought to be open. Therefore in step 612 an error is noted. Additional processing may be performed to handle the error (an example is provided below). If the previous door state was not “open” (“No” from step 608) then the process proceeds to step 610 in which the door 104 motion event is categorized as a door open event. In this case the door 104 motion event (i.e. the first event) has been categorized based on the first event (door motion detected), based on the second event (the first open signature that it was compared against in step 604) and a previous system state (the door open state that was checked in step 608). Finally, if the comparison in step 604 between the door 104 motion event (first event) and the first door open signature (second event) is “No” then it is determined that the door 104 motion is not an opening event and therefore in step 606 the door 104 motion is categorized as either a door closing event or a door reversal event.
[0052] In the process of FIG. 6, no distinction is made between door closing events and door reversal events. This degree of categorization may be sufficient for diagnostic and monitoring purposes. However, if further separation of the closing and reversal events is required than further analysis can be performed. For example comparisons of the motion signature against known closing events or known reversal events may be made. However, in some examples the number of door closings can be determined based on data already available. For example the number of full door opening events and full door closing events should be equal. Alternatively, an event that was categorized in step 606 as either a door closing event or a door reversal event can be further categorized based on detecting that the next event is either a door 104 opening event (which can only occur if the doors 104 fully closed) or a car 103 start event (which can only occur if the doors 104 fully closed). In the first case, the further categorization has again been categorized based on two door 104 motion events (a closing/reversal event followed by an opening event) and in the second case, the further categorization has again been categorized based on a door 104 motion event and a car 103 motion event (a closing/reversal event followed by a car start event). In some examples, categorizing the door reversal events is the most important for characterizing the health of the door 104.
[0053] FIG. 7 shows another example of a categorization process. The process of FIG. 7 is similar to that of FIG. 6, but contains some additional steps. The steps that are the same as in FIG. 6 are labelled with the same reference numbers and will not be described again here. In the example process of FIG. 7, if the determination in step 600 is that the door 104 motion is not the first door 104 motion following an elevator car 103 stop event, then the process proceeds to step 700. In step 700 the process checks if the time since the last door 104 motion is greater than 6 seconds (although it will be appreciated that this time is given by way of example only and that any suitable time threshold could be used according to the particular elevator system being monitored). If the time since the last door 104 motion is greater than 6 seconds (“Yes” from step 700) then the process proceeds to step 702 in which the door 104 motion (i.e. the first event) is categorized as a door open event. This analysis is based on the system knowledge that the elevator door 104 does not normally remain open for 6 seconds at a time without attempting a close motion. Therefore if the door 104 has remained stationary for greater than 6 seconds, it may be inferred that the door 104 motion must be an opening event. In this case, the categorization has been based on two door motion events (the current door 104 motion event, i.e. the first event, and a time since the previous door 104 motion event, i.e. the second event). If the analysis in step 700 is “No” then the process proceeds to step 704 in which the process checks whether the last door state was set to “open” following a timer-based determination. If “Yes” then the process proceeds to step 706 in which the door 104 motion (i.e. the first event) is categorized as either a door closing event or a door reversal event. This categorization step is similar to the categorization in step 606, but in this case the categorization is made on the basis that a door open state was reliably determined after the previous motion. Therefore, it can now reliably be confirmed that the current motion is a non-opening event. As with step 606 discussed above, further processing may be performed to further categorize the closing events and the reversal events. If the determination in step 704 is “No” then the process proceeds to step 604 which then proceeds in the same way as was discussed above with reference to FIG. 6. It will be appreciated that in some examples steps 704 and 706 could be omitted as the door close/reversal should fail the signature check in step 604 and get counted at step 606. However, the identification following the timer is considered a more reliable determination and therefore gives a more trustworthy categorization. Therefore steps 704 and 706 provide more reliable categorization.
[0054] FIG. 8 shows an example of an algorithm which carries out the process according to the example of FIG. 7. The upper part of FIG. 8 shows how the algorithm moves between a door 104 stopped state 800 and a door 104 in motion state 802. Starting with the door stopped state 800, when door motion is detected (e.g via one or more accelerometer samples) then the flag door_motion_detected is set to True and the algorithm starts acquiring motion_samples which is an array of sensor data acquired from the one or more sensors. The door is then considered to be in the door in motion state 802. In this state 802, the algorithm continues to acquire motion_samples while the door_motion_detected flag remains True. When the door 104 stops moving, the door_motion_detected flag changes to False and the algorithm returns from door in motion state 802 to door stopped state 800 via the main algorithm which is set out as pseudo-code in the lower part of FIG. 8.
[0055] The main algorithm of FIG. 8 will now be described briefly. Firstly the flag door_motion_stopped is checked. This corresponds to the change of state from state 802 to state 800 in the upper part of the figure and is the trigger for the main algorithm to commence. The algorithm then checks if opening_signature is an empty array. The array opening_signature is a set of values derived from the motion_samples array that was acquired during an earlier door 104 opening event. This signature is ideally acquired from the first door 104 motion event following the elevator car 103 stopping at a landing 125 as this event is reliably determined to be an opening event. The signature (defined by the opening_signature array) is a set of values that characterize the motion and may include for example the direction of motion as determined by the accelerometer, the duration of the motion, the relative position of the minimum and maximum acceleration values in the data, etc. If the opening_signature array is empty then no such signature has yet been determined and therefore this must be the first door 104 motion following an elevator car 103 stop. Therefore, the opening_signature array is set to be equal to the motion_signature array which is the signature calculated for the current door 104 motion event (derived from the motion_samples array). In addition, the counter door_cycles is incremented by one to reflect that the first door 104 motion following an elevator car stop is categorized as a door open event as per step 602 of FIG. 7. Further, the two status flags just_opened and just_opened_first_time are set to True.
[0056] If the door motion was not the first since car stop then the algorithm next checks if the variable time_since_last_door_motion is greater than 6 seconds. This corresponds to the check in step 700 of FIG. 7 and if True the algorithm increments the counter door_cycles by one to reflect the categorization of a door open event in step 702 of FIG. 7. Additionally the flag just_opened is set to True to reflect the known door state as opened and the flag OpenByTimerMrk is set to True to reflect that the current door open state was determined by the timer.
[0057] If the time since last door motion was not greater than 6 seconds then the algorithm next checks if the OpenByTimerMrk is True corresponding to processing step 704 in FIG. 7. If it is then the flag OpenByTimerMrk can now be reset to False and a counter reversals is incremented by one to reflect that the door motion event is not a door opening event. Here it should be noted that the counter “reversals” is incremented if the current door motion is either a door closing event or a door reversal event. However, as discussed further below, the closing events will subsequently by removed by further categorization and thus the counter will end up reflecting only door reversal events. In this step, the flag just_opened is set to False to reflect that the door is not known to be in the open state (it could now be in a closed state following a close event or in an open state following a reversal event). Also, the just_opened_first_time flag is set to False.
[0058] If it is determined that the last motion state was not set by the timer then the algorithm next checks whether the motion_signature array for the current door 104 motion matches the opening_signature array determined at the start of the main algorithm when the first door motion after car stop was detected. This corresponds to the step 604 in FIG. 7. It may be noted that the is_matching comparison function need not require an exact match, but may instead allow for matching to within a certain degree, e.g. for the various values to be within certain tolerances or thresholds of each other. A check is also made that the flag just_opened_first_time is not set. The motion following the first door motion should not be determined as an opening event and therefore this check makes sure to avoid the following processing. This allows a special use of the is_matching( ) function which is not shown in the figures—as it is known that the is_matching( ) function should return false on the first motion following the first door opening, a return of true can be used to indicate a poor quality signature acquisition during the first opening motion. If such a poor quality signature is determined, an alternative signature, previously validated signature (e.g. from a previous run or from a different landing) can be used instead. In the case that motion_signature is determined to match opening_signature and the flag just_opened_first_time is not set, then the algorithm next checks if the flag just_opened is set. If the flag just_opened is not set then it is determined that the current motion represents an opening event following a non-opening event. An opening event can only happen after a closing event has taken place and therefore it may be assumed that a full closing event has occurred (and should have been counted by the reversals counter). Therefore, a check is made (for safety) that the reversals counter is greater than zero (which it should be) and then the reversals counter is decremented by one to remove the full closing event from the count. In addition, the counter door_cycles is incremented by one to reflect the categorization of the current motion as a door opening event. This corresponds to step 610 in FIG. 7. Additionally, the flag just_opened is set to True to reflect the known door state as opened.
[0059] If the door signatures matched following the is_matching comparison, but the flag just_opened was set to True then the algorithm determines that an error has occurred as a door opening signature has been found when the door state was already believed to be open. In this case something must have gone wrong with the algorithm or sensor data and some suitable action may be taken. In this example the door_cycles counter is incremented once out of every two times that this situation occurs to reflect that counting all of the openings would be an overestimate. This corresponds to step 612 in FIG. 7.
[0060] More specifically, although this error processing is not set out in detail in FIG. 8, one example is to operate as follows: The variable named TwoOpeningMrk evolves between the values 0 and 1 which each error detection. The first time the situation occurs, TwoOpeningMrk takes value 1 and the number of openings is not incremented. The next time the situation occurs, TwoOpeningMrk takes value 0 and the number of opening is incremented by one. Next time TwoOpeningMrk takes value 1 and the number of opening is not incremented, and so on. At the very end, when the car moves, if the flag just_open is True and TwoOpeningMark is 0, then the counter for the number of cycles is decremented. It will be appreciated that this is just one example of an error processing routine and that many alternatives exist.
[0061] Finally, if none of the above checks have been triggered, the final step is to categorize the door 104 motion as a closing event or reversal event. Thus, the reversals counter is incremented by one, the just_opened flag is set to False and the just_opened_first_time flag is set to False to represent that the door is not known to be in an open state. This corresponds to step 606 in FIG. 7.
[0062] Returning to the upper part of FIG. 8, following the return to the door stopped state 800, if the elevator car then starts to move, it can be assumed that a full door closing event has taken place. Therefore, the reversals counter is decremented by one to remove the door closing event that should have been counted earlier in the processing (after a confirmatory check that the reversals counter is indeed greater than zero).
[0063] Here it is also shown that when a determination is made that the car stopped moving, an initialisation of variables is performed to set the opening_signature array to empty, the motion_signature array to empty, the door_cycles counter to zero, the reversals counter to zero, the just_opened flag to False, the just_opened_first_time flag to False and the OpenByTimerMrk flag to False.
[0064] It will be appreciated by those skilled in the art that the disclosure has been illustrated by describing one or more specific examples thereof, but is not limited to these examples; many variations and modifications are possible, within the scope of the accompanying claims.
