Patent Description:
Elevator systems can be monitored in a number of ways in order to establish characteristics relating to the operational health of the elevator system. Some characteristics of particular interest are those relating to travel of the elevator car within the hoistway. Other characteristics of particular interest are those relating to operation of the elevator car door(s) while the elevator car is at a landing.

<CIT> describes a method of monitoring a conveyance system including: detecting a vibratory signature along a first axis about equivalent to a vibratory signature of a significant event and examining vibratory signatures for a secondary event along at least one of the first axis and a second axis of the conveyance apparatus for at least one of a selected time period after detection of the significant event and a selected time period before detection of the significant event.

<CIT> and <CIT> disclose systems in which a microphone can be used to obtain audio fingerprints. An algorithm can categorize which of the audio fingerprints are the elevator doors opening and closing.

According to a first aspect of this disclosure there is provided an elevator monitoring system according to claim <NUM>.

Categorizing the elevator door motion is useful for determining characteristics relating to the health of the elevator door system. For example, the number of times that the elevator car door has opened is a useful indicator of elevator system health (which can be used to indicate a need for maintenance). Additionally or alternatively, the number of times that the elevator car door has undergone a reversal motion is a useful indicator of elevator system health. A reversal motion is a closing motion which commenced, but did not finish, resulting in a re-opening of the elevator door.

Existing systems have used the duration of a detected door motion to categorize it based on the principle that a door reversal motion generally takes longer than a door opening or door closing motion. For example, in a door reversal motion the door will undergo a partial closing operation and a partial opening operation which together will generally be longer than an individual opening motion or an individual closing operation, e.g. where the reversal was caused by an obstruction between the doors when they were nearly fully closed. However, short door reversal operations can also occur, e.g. where an obstruction blocks the door very shortly after commencement of door closing. In such cases the duration of door motion may be less than a normal opening or closing operation and can be missed by analysis based purely on duration. By contrast, the system of this disclosure categorizes the elevator door motion based on both a first event and a second event in the sensor data. This improves the reliability of categorization by taking into account additional information indicative of the type of motion occurring in the elevator door. In particular, by using two separate events in the analysis, the system can base the categorization on events that happened before or after the elevator door motion event and which are thus indicative of the state of the system at the corresponding time.

The sensor(s) that are used in the elevator monitoring system may include any number of different sensors such as pressure sensors, light sensors, sound sensors, cameras, infrared detectors, load sensors, etc. In some examples the one or more sensors comprises an accelerometer and the controller is arranged to acquire accelerometer data. An accelerometer can be used to detect accelerations (including vibrations) in the system and these can be used to identify (amongst other things) movement of the elevator car doors. The one or more sensors may additionally comprise other sensors. For example, the one or more sensors may comprise a pressure sensor which may be used in the determination of the start and stop of vertical elevator car motion within the hoistway.

In some examples the controller is arranged to analyse the accelerometer data to identify the first event. In some examples the controller may be arranged to analyse the accelerometer data to identify the second event. In some examples the controller may be arranged to use other sensor data (e.g. pressure sensor data) to identify the second event.

In some examples identifying the first event comprises identifying a period of elevator door motion between two periods of the elevator door being stationary. Door motion tends to be represented by a continuous period of significant (i.e. relatively high) acceleration in the accelerometer data. Such continuous period of acceleration may be from a fully closed door state to a fully open door state (a normal opening motion), or it may be from a fully open door state to a fully closed door state (a normal closing motion), or it may be from a fully open door state to a partially open/closed door state and back to a fully open door state (a reversal motion).

In some examples the second event may be an event other than an elevator door motion event. In some examples the second event is an elevator car start or an elevator car stop event. An elevator car start event may be the departure of the elevator car from a landing. An elevator car stop event may be the arrival of the elevator car at a landing. Such information is useful in the categorization of elevator door motion events as it is known with a high degree of certainty that the first elevator door motion following an elevator car stop must be a door opening event. Likewise the last elevator door motion preceding an elevator car start must be a door closing event as the elevator car cannot depart with open doors.

In some examples the second event is an earlier elevator door motion event. Such information is useful in that comparison of one elevator door motion event with another elevator door motion event of known category allows for a matching (or non-matching) of category to be made.

In some examples the second event is an earlier elevator door opening event. For example, by comparing the first event to an earlier door opening event and establishing that the sensor data for the first event corresponds to (to a suitable degree) the sensor data for the second event, it can be ascertained that the first event is also a door opening event. It will be appreciated that similar comparisons may also be made where the second event corresponds to a door closing event or where the second event corresponds to a door reversal event. However, it is particularly convenient to use an earlier door opening event as the second event because, as discussed above, door opening events can be identified with high reliability based on detecting an elevator car stop event and taking the first door motion event following the elevator car stop event as a door opening event. Thus in some examples, the second event is the first elevator door opening event following the most recent elevator car stop event. It will be appreciated that the second event may be a different door opening event (i.e. other than the one following the most recent car stop event). For example, a door open event immediately following an earlier (but not the most recent) car stop event could also be used. This may be useful where sensor data indicates that the first elevator door motion following the car stop event is of low quality and therefore not ideal for use in future comparisons. In such cases an earlier and higher quality door opening event may be used. Such earlier door opening event may be from the same or a different landing, but is ideally from the same landing as door motion signatures may vary between landings. It will be appreciated that the same principles apply where the comparison is to be made with an earlier door closing event or earlier door reversal event.

In some examples 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. Determining correspondence may take many different forms. For example, while an exact match of sensor data for the two events could be required, the variability in sensor data makes this unattractive. Instead, the correspondence will generally be a certain degree of correspondence. Any suitable matching algorithms may be used which can allow for some degree of mismatch in the data while still assuring overall correspondence sufficient to give a high confidence that the two events are of the same category. In some examples, the sensor data may be processed to generate a signature which is indicative of a type of motion and the correspondence of the sensor data for the first event and second event may comprise generating the signature for each event and comparing the signatures for correspondence. Purely by way of example, some elements of a suitable signature may comprise the direction of motion of the elevator door as determined by the accelerometer, the duration of elevator door motion, the relative time order of the minimum and maximum acceleration within the accelerometer data. In some examples the signature may comprise one or more frequency components of the door motion data.

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. It will be appreciated that it is not always necessary to use all of these categories. For example it may be sufficient to identify only the door reversal events, or only the door opening events or only the door closing events. In some examples, the monitoring system uses the opening and reversal categories. In some examples it may be determined that the number of door closing events is equal to the number of door opening events during a given landing stop, i.e. between an elevator car stop and the next elevator car start (which would be true if no errors are made in categorization).

In some examples categorizing the first event comprises adjusting a counter corresponding to a category. The act of matching or not matching a set of criteria amounts to the categorization being made and the adjustment of a corresponding counter dependent on that matching or not matching amounts to logging or storing the categorization. It will be appreciated that in other examples the categorization may be stored or logged in other ways. For example a list of detected events may be generated, each with an associated determined category. However, the use of a counter to log the events is sufficient for many analysis purposes and the counter value provides a simple and low data metric that can be transmitted at low power and low cost to a monitoring station.

In some examples categorizing the first event is based on an amount of time between the first event and the second event. For example, in some systems, the amount of time that an elevator door can spend idle between a door opening event and a door closing event is limited (i.e. the elevator doors will always be instructed to close after a predefined period of time following an opening event). In such cases, determining that the amount of time since the last door motion event has exceeded a threshold period of time is a reliable indicator that the elevator doors are currently in a closed state. In other words, where the first event and second event are adjacent (in time) door motion events, the knowledge that the time between first and second events exceeds the maximum door open idle time can be used to determine with high reliability that the first event (the more recent event) is a door opening event. Thus, in some examples 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.

In some examples categorizing the first event is based on a previously determined state of the elevator door. For example, a full door closing event may be used to set a system state to "door closed". Likewise a full door opening event may be used to set a system state to "door open". It can be inferred that the next door motion following a "door closed" state must be a door open event. Likewise it can be inferred that the next door motion following a "door open" state must be either a door closing event or a door reversal event. Therefore basing categorization of the first event on a previously determined state of the elevator door adds additional information and additional diagnostic capability. When the previous door state is combined with the analysis of the first event and second event, errors in the analysis can also be determined. For example, if a door state indicates that door is in an open state and the first event also matches a second event which was an earlier door open event then it can be determined that an error has occurred (the system has detected two door opening events in a row, without detecting an intervening door closing event) and suitable processing can be effected.

The analysis discussed in this disclosure is particularly applicable to low power systems which operate on a battery and/or energy harvesting power source. This is the case in monitoring or diagnostic systems (e.g. condition based maintenance systems) which do not have direct access to the elevator drive machinery and which must therefore determine the elevator car and/or door motions independently. It is convenient for such systems to operate on their own power source (battery or energy harvesting) as this makes them much easier and quicker to install, especially as a retrofit on older elevator systems. In addition, for ease of installation such systems conveniently communicate via wireless transmission so as to avoid the need for hard-wired connections. As such wireless transmissions are power intensive, minimising the amount of data to be transmitted is highly desirable. Additionally, intensive signal processing for complex analysis consumes power and it is also desirable to minimise processing in order to conserve power and extend battery life. Higher sampling rates of sensor data allow more accurate analysis and determination of motion profiles. However, higher sampling rates consume more power and also processing the larger resulting data sets can consume more power. In the examples described here, the analysis of door motion is sufficiently robust to operate on low sample rates and correspondingly small data sets. Therefore the processing power is reduced while still maintaining high reliability of diagnostics and monitoring. In some examples the sensor data (e.g. accelerometer data) is acquired at a sample rate of no more than <NUM> samples per second, or no more than <NUM> samples per second, or no more than <NUM> samples per second. Of course it will be appreciated that the processing techniques described here may also be applied in cases where power and/or data transmission are not limiting factors and therefore in some examples any desired sampling rate may be used.

As discussed above, in some examples the elevator monitoring system is powered by a battery or energy harvesting system. An energy harvesting system may for example comprise an inductive charging system or it may comprise a thermal, kinetic or wind-based system. In some examples the monitoring system is not connected to mains power. With battery or energy harvesting powered systems, low power operation becomes very important and therefore the amount of intensive processing, the sensor sampling rates and wireless transmission strengths become important factors in achieving a suitably long operational lifetime between servicing.

In some examples the monitoring system is independent from the elevator system. As discussed above, this facilitates installation as no communicative connections to the existing system controllers are required. Health monitoring can thereby be achieved from an independent system and adds a layer of safety on top of the fault detection and monitoring systems within the elevator system itself.

It will be appreciated that the monitoring system may be designed to process data at any of a number of different points within the system. In some examples data is processed locally on a monitoring device that is mounted to the elevator car (e.g. to the elevator car door). Processing data locally at the point of acquisition reduces the amount of wireless data transmission and therefore reduces power consumption, but also increases the power consumed in processing the data. In other examples data may be transmitted to a remote location for processing. The remote location may have different or less strict power consumption limitations and may therefore be capable of performing more detailed and complex data analysis. The remote location may be an on-site gateway (i.e. on the same site as the elevator itself) or it may be on another remote site or in the cloud. Where data is processed locally, the results (e.g. diagnostic metrics) may be transmitted either directly to an on-site or remote or cloud based monitoring station or may be transmitted to such a monitoring system via a local gateway.

According to a second aspect of the present disclosure, there is provided a method of monitoring an elevator system according to claim <NUM>.

It will be appreciated that all of the optional or example features discussed above in relation to the monitoring system can equally optionally apply to this method of monitoring an elevator system.

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. <FIG> is merely a nonlimiting example presented for illustrative and explanatory purposes.

In one example, embodiments disclosed herein may be applicable to conveyance systems such as an elevator system <NUM> and a conveyance apparatus of the conveyance system such as an elevator car <NUM> of the elevator system <NUM>. 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.

Referring now to <FIG>, with continued referenced to <FIG>, a view of a sensor system <NUM> including a sensing apparatus <NUM> is illustrated, according to an embodiment of the present disclosure. The sensing apparatus <NUM> is configured to detect sensor data <NUM> of the elevator car <NUM> and transmit the sensor data <NUM> to a remote device <NUM>. Sensor data <NUM> may include but is not limited to pressure data <NUM>, vibratory signatures (i.e., vibrations over a period of time) or accelerations <NUM> and derivatives or integrals of accelerations <NUM> of the elevator car <NUM>, such as, for example, distance, velocity, jerk, jounce, snap. etc. Sensor data <NUM> may also include light, sound, humidity, and temperature, or any other desired data parameter. The pressure data <NUM> may include atmospheric air pressure within the elevator shaft <NUM>. 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 <NUM> may be a single sensor or may be multiple separate sensors that are interconnected.

In an embodiment, the sensing apparatus <NUM> is configured to transmit sensor data <NUM> that is raw and unprocessed to the controller <NUM> of the elevator system <NUM> for processing. In another embodiment, the sensing apparatus <NUM> is configured to process the sensor data <NUM> prior to transmitting the sensor data <NUM> to the controller <NUM> through a processing method, such as, for example, edge processing. In another embodiment, the sensing apparatus <NUM> is configured to transmit sensor data <NUM> that is raw and unprocessed to a remote system <NUM> for processing. In yet another embodiment, the sensing apparatus <NUM> is configured to process the sensor data <NUM> prior to transmitting the sensor data <NUM> to the remote device <NUM> through a processing method, such as, for example, edge processing.

The processing of the sensor data <NUM> 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 <NUM> x, y acceleration at a position: (i.e., rail topology), elevator car <NUM> x, y vibration signatures at a position: (i.e., rail topology), door performance at a landing number, nudging event, vandalism events, emergency stops, etc..

The remote device <NUM> 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 <NUM> 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 <NUM> 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.

The remote device <NUM> may be an electronic controller including a processor <NUM> and an associated memory <NUM> comprising computer-executable instructions that, when executed by the processor <NUM>, cause the processor <NUM> to perform various operations. The processor <NUM> 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 <NUM> 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.

The sensing apparatus <NUM> may be configured to transmit the sensor data <NUM> to the controller <NUM> or the remote device <NUM> via short-range wireless protocols <NUM> and/or long-range wireless protocols <NUM>. Short-range wireless protocols <NUM> may include but are not limited to Bluetooth, Wi-Fi, HaLow (<NUM>. 11ah), zWave, ZigBee, or Wireless M-Bus. Using short-range wireless protocols <NUM>, the sensing apparatus <NUM> is configured to transmit the sensor data <NUM> directly to the controller <NUM> or to a local gateway device <NUM> and the local gateway device <NUM> is configured to transmit the sensor data <NUM> to the remote device <NUM> through a network <NUM> or to the controller <NUM>. The network <NUM> 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 <NUM>, the sensing apparatus <NUM> may be configured to transmit the sensor data <NUM> to the remote device <NUM> through a network <NUM>. Long-range wireless protocols <NUM> may include but are not limited to cellular, satellite, LTE (NB-loT, CAT M1), LoRa, Satellite, Ingenu, or SigFox.

The sensing apparatus <NUM> may be configured to detect sensor data <NUM> including acceleration in any number of directions. In an embodiment, the sensing apparatus may detect sensor data <NUM> including accelerations <NUM> along three axes, an X axis, a Y axis, and a Z axis, as show in in <FIG>. The X axis may be perpendicular to the doors <NUM> of the elevator car <NUM>, as shown in <FIG>. The Y axis may be parallel to the doors <NUM> of the elevator car <NUM>, as shown in <FIG>. The Z axis may be aligned vertically parallel with the elevator shaft <NUM> and the pull of gravity, as shown in <FIG>. The acceleration data <NUM> may reveal vibratory signatures generated along the X-axis, the Y-axis, and the Z-axis.

<FIG> shows a possible installation location of the sensing apparatus <NUM> within the elevator system <NUM>. The sensing apparatus <NUM> may include a magnet (not show) to removably attach to the elevator car <NUM>. In the illustrated embodiment shown in <FIG>, the sensing apparatus <NUM> may be installed on the door hanger 104a and/or the door <NUM> of the elevator system <NUM>. It is understood that the sensing apparatus <NUM> may also be installed in other locations other than the door hanger 104a and the door <NUM> of the elevator system <NUM>. It is also understood that multiple sensing apparatus <NUM> are illustrated in <FIG> to show various locations of the sensing apparatus <NUM> and the embodiments disclosed herein may include one or more sensing apparatus <NUM>. In another embodiment, the sensing apparatus <NUM> may be attached to a door header 104e of a door <NUM> of the elevator car <NUM>. In another embodiment, the sensing apparatus <NUM> may be located on a door header 104e proximate a top portion 104f of the elevator car <NUM>. In another embodiment, the sensing apparatus <NUM> is installed elsewhere on the elevator car <NUM>, such as, for example, directly on the door <NUM>.

As shown in <FIG>, the sensing apparatus <NUM> may be located on the elevator car <NUM> in the selected areas <NUM>, as shown in <FIG>. The doors <NUM> are operably connected to the door header 104e through a door hanger 104a located proximate a top portion 104b of the door <NUM>. The door hanger 104a includes guide wheels 104c that allow the door <NUM> 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 <NUM> because the door hanger 104a is accessible when the elevator car <NUM> is at landing <NUM> and the elevator door <NUM> is open. Thus, installation of the sensing apparatus <NUM> is possible without taking special measures to take control over the elevator car <NUM>. For example, the additional safety of an emergency door stop to hold the elevator door <NUM> open is not necessary as door <NUM> opening at landing <NUM> is a normal operation mode. The door hanger 104a also provides ample clearance for the sensing apparatus <NUM> during operation of the elevator car <NUM>, such as, for example, door <NUM> opening and closing. Due to the mounting location of the sensing apparatus <NUM> on the door hanger 104a, the sensing apparatus <NUM> may detect open and close motions (i.e., acceleration) of the door <NUM> of the elevator car <NUM> and a door at the landing <NUM>. Additionally mounting the sensing apparatus <NUM> on the hanger 104a allows for recording of a ride quality of the elevator car <NUM>.

<FIG> illustrates an example of a sensing apparatus <NUM> of <FIG> in more detail. The sensing apparatus includes a controller <NUM>, a plurality of sensors <NUM> in communication with the controller <NUM>, a communication module <NUM> in communication with the controller <NUM>, and a power source <NUM> electrically connected to the controller <NUM>. The plurality of sensors <NUM> includes an inertial measurement unit (IMU) <NUM> and a pressure sensor <NUM>. The IMU <NUM> comprises three accelerometers <NUM> and is configured to detect acceleration of the elevator car <NUM> and/or elevator car door <NUM>, and to generate the acceleration data <NUM>. The pressure sensor <NUM> (which may be, for example a pressure altimeter or a barometric altimeter) is configured to detect an atmospheric air pressure within the elevator hoistway <NUM>, and to generate the pressure data <NUM>. Both the IMU <NUM> and the pressure sensor <NUM> are in communication with the controller <NUM> of the sensing apparatus <NUM>. It will be appreciated that while the pressure sensor <NUM> may be used to provide further information on elevator car <NUM> movement, it can also be omitted in some examples. In some examples, the plurality of sensors <NUM> may also include additional sensors such as a light sensor, a microphone, a humidity sensor, and a temperature sensor.

The power source <NUM> of the sensing apparatus <NUM> is configured to store and supply electrical power to the sensing apparatus <NUM>. The power source <NUM> may include an energy storage system, such as a battery or a capacitor, or other appropriate energy storage system known in the art.

The communication module <NUM> is configured to allow the controller <NUM> of the sensing apparatus <NUM> to communicate with the remote device <NUM> and/or controller <NUM> through at least one of short-range wireless protocols <NUM> and long-range wireless protocols <NUM> as described above.

The controller <NUM> of the sensing apparatus <NUM> includes a processor <NUM> and a memory <NUM> comprising computer-executable instructions that, when executed by the processor <NUM>, cause the processor <NUM> to perform various operations such as processing of the sensor data <NUM> collected by the IMU <NUM> and the pressure sensor <NUM> to determine information about the motion of the elevator car <NUM>. The sensing apparatus <NUM> also comprises a buffer <NUM>, configured to store a pre-set number of data entries.

<FIG> illustrates an example of a method of categorizing door motion based on sensor data. The method begins at step <NUM> in which sensor data is acquired from one or more sensors. The one or more sensors may be one accelerometer <NUM> or a set of accelerometers (e.g. IMU <NUM>) 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 <NUM> the sensor data that was acquired in step <NUM> is analysed to identify a first event and a second event within the data. The first event is the door <NUM> motion that is to be categorized by this process. The second event is another event that may be another door <NUM> motion event or may be an elevator car <NUM> motion event. Where the second event is another door <NUM> motion event, it may for example be a door <NUM> opening event or a door <NUM> closing event or a door <NUM> reversal event. Where the second event is a car <NUM> motion event, it may for example be a car <NUM> start event (leaving a landing <NUM>) or a car <NUM> stop event (arriving at a landing <NUM>). In step <NUM> 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.

<FIG> shows in detail one example of a categorization process that can be used to categorize a door <NUM> motion. Starting at step <NUM>, the process checks if this is the first door <NUM> motion since the car <NUM> stopped at a landing <NUM>. If "Yes", then in step <NUM> the door <NUM> motion event is categorized as a door opening event. This is based on the assumption that the door <NUM> is closed when the elevator car <NUM> comes to a stop at the landing <NUM> and therefore the next door <NUM> motion must be a door opening event. In this case, the second event is a car <NUM> 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 <NUM> concludes that the door motion is not the first motion after the car <NUM> has come to a stop ("No") then the process proceeds to step <NUM> for further analysis. In step <NUM> the process checks if the door <NUM> motion signature matches a first door open signature. If "Yes", then the process proceeds to step <NUM> in which the process checks if the last known door <NUM> state was "open". If "Yes" then an error has occurred as a door <NUM> open event has apparently been detected when the door state was already thought to be open. Therefore in step <NUM> 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 <NUM>) then the process proceeds to step <NUM> in which the door <NUM> motion event is categorized as a door open event. In this case the door <NUM> 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 <NUM>) and a previous system state (the door open state that was checked in step <NUM>). Finally, if the comparison in step <NUM> between the door <NUM> motion event (first event) and the first door open signature (second event) is "No" then it is determined that the door <NUM> motion is not an opening event and therefore in step <NUM> the door <NUM> motion is categorized as either a door closing event or a door reversal event.

In the process of <FIG>, 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 <NUM> 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 <NUM> opening event (which can only occur if the doors <NUM> fully closed) or a car <NUM> start event (which can only occur if the doors <NUM> fully closed). In the first case, the further categorization has again been categorized based on two door <NUM> 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 <NUM> motion event and a car <NUM> 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 <NUM>.

<FIG> shows another example of a categorization process. The process of <FIG> is similar to that of <FIG>, but contains some additional steps. The steps that are the same as in <FIG> are labelled with the same reference numbers and will not be described again here. In the example process of <FIG>, if the determination in step <NUM> is that the door <NUM> motion is not the first door <NUM> motion following an elevator car <NUM> stop event, then the process proceeds to step <NUM>. In step <NUM> the process checks if the time since the last door <NUM> motion is greater than <NUM> 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 <NUM> motion is greater than <NUM> seconds ("Yes" from step <NUM>) then the process proceeds to step <NUM> in which the door <NUM> 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 <NUM> does not normally remain open for <NUM> seconds at a time without attempting a close motion. Therefore if the door <NUM> has remained stationary for greater than <NUM> seconds, it may be inferred that the door <NUM> motion must be an opening event. In this case, the categorization has been based on two door motion events (the current door <NUM> motion event, i.e. the first event, and a time since the previous door <NUM> motion event, i.e. the second event). If the analysis in step <NUM> is "No" then the process proceeds to step <NUM> 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 <NUM> in which the door <NUM> 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 <NUM>, 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 <NUM> discussed above, further processing may be performed to further categorize the closing events and the reversal events. If the determination in step <NUM> is "No" then the process proceeds to step <NUM> which then proceeds in the same way as was discussed above with reference to <FIG>. It will be appreciated that in some examples steps <NUM> and <NUM> could be omitted as the door close/reversal should fail the signature check in step <NUM> and get counted at step <NUM>. However, the identification following the timer is considered a more reliable determination and therefore gives a more trustworthy categorization. Therefore steps <NUM> and <NUM> provide more reliable categorization.

<FIG> shows an example of an algorithm which carries out the process according to the example of <FIG>. The upper part of <FIG> shows how the algorithm moves between a door <NUM> stopped state <NUM> and a door <NUM> in motion state <NUM>. Starting with the door stopped state <NUM>, 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 <NUM>. In this state <NUM>, the algorithm continues to acquire motion_samples while the door_motion_detected flag remains True. When the door <NUM> stops moving, the door_motion_detected flag changes to False and the algorithm returns from door in motion state <NUM> to door stopped state <NUM> via the main algorithm which is set out as pseudo-code in the lower part of <FIG>.

The main algorithm of <FIG> will now be described briefly. Firstly the flag door_motion_stopped is checked. This corresponds to the change of state from state <NUM> to state <NUM> 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 <NUM> opening event. This signature is ideally acquired from the first door <NUM> motion event following the elevator car <NUM> stopping at a landing <NUM> 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 <NUM> motion following an elevator car <NUM> 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 <NUM> motion event (derived from the motion_samples array). In addition, the counter door_cycles is incremented by one to reflect that the first door <NUM> motion following an elevator car stop is categorized as a door open event as per step <NUM> of <FIG>. Further, the two status flags just_opened and just_opened_first_time are set to True.

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 <NUM> seconds. This corresponds to the check in step <NUM> of <FIG> and if True the algorithm increments the counter door_cycles by one to reflect the categorization of a door open event in step <NUM> of <FIG>. 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.

If the time since last door motion was not greater than <NUM> seconds then the algorithm next checks if the OpenByTimerMrk is True corresponding to processing step <NUM> in <FIG>. 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.

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 <NUM> 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 <NUM> in <FIG>. 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 <NUM> in <FIG>. Additionally, the flag just_opened is set to True to reflect the known door state as opened.

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 <NUM> in <FIG>.

More specifically, although this error processing is not set out in detail in <FIG>, one example is to operate as follows: The variable named TwoOpeningMrk evolves between the values <NUM> and <NUM> which each error detection. The first time the situation occurs, TwoOpeningMrk takes value <NUM> and the number of openings is not incremented. The next time the situation occurs, TwoOpeningMrk takes value <NUM> and the number of opening is incremented by one. Next time TwoOpeningMrk takes value <NUM> 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 <NUM>, 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.

Finally, if none of the above checks have been triggered, the final step is to categorize the door <NUM> 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 <NUM> in <FIG>.

Returning to the upper part of <FIG>, following the return to the door stopped state <NUM>, 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).

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.

Claim 1:
An elevator monitoring system, comprising:
one or more sensors (<NUM>, <NUM>, <NUM>, <NUM>);
a controller (<NUM>; <NUM>; <NUM>) arranged to:
acquire (<NUM>) sensor data (<NUM>; <NUM>, <NUM>) from the one or more sensors;
analyse the sensor data to identify (<NUM>) a first event and a second event, the first event corresponding to an elevator door (<NUM>) motion;
characterised in that the controller (<NUM>; <NUM>; <NUM>) is further arranged to categorize the first event (<NUM>) based on the sensor data for the first event and the second event; and
further characterised in that categorizing (<NUM>) the first event comprises at least one of:
categorizing the first event as a door (<NUM>) open event;
categorizing the first event as a door close event; and
categorizing the first event as a door reversal event.