Elevator monitoring system

Abstract

An elevator monitoring system, comprising: one or more sensors; a controller arranged to: acquire sensor data from the one or more sensors; analyze the sensor data to identify a first event and a second event, the first event corresponding to elevator door movement; and classify the first event based on the sensor data for the first event and the second event. Classifying elevator door movement is useful for determining characteristics related to the health of an elevator door system. For example, the number of times an elevator car door has been opened is a useful indicator of the health of the elevator system (which indicator can be used to indicate the need for maintenance). Additionally or alternatively, the number of times an elevator car door has experienced a reverse movement is a useful indicator of the health of the elevator system. A reverse movement is a closing movement that is started but not completed, thereby causing the elevator door to reopen.

Description

Technical Field

[0001] The present disclosure generally relates to elevator monitoring systems. More particularly, the present disclosure relates to a monitoring system for monitoring the movement of elevator doors, particularly for classifying elevator car doors. Background Art

[0002] The elevator system can be monitored in a variety of ways in order to establish characteristics related to the operational health of the elevator system. Some characteristics of particular interest are those related to the travel of the elevator car within the hoistway. Other characteristics of particular interest are those related to the operation of the elevator car door(s) when the elevator car is at a landing. Summary of the invention

[0003] According to a first aspect of the present disclosure, there is provided an elevator monitoring system, comprising:

[0004] one or more sensors;

[0005] A controller arranged to:

[0006] acquiring sensor data from one or more sensors;

[0007] analyzing the sensor data to identify a first event and a second event, the first event corresponding to elevator door movement;

[0008] The first event is classified based on sensor data for the first event and the second event.

[0009] Classifying elevator door motion is useful for determining characteristics related to the health of an elevator door system. For example, the number of times an elevator car door has been opened is a useful indicator of the health of the elevator system (which can be used to indicate the need for maintenance). Additionally or alternatively, the number of times an elevator car door has experienced a reversal motion is a useful indicator of the health of the elevator system. A reversal motion is a closing motion that is started but not completed, thereby causing the elevator door to reopen.

[0010] Existing systems have used the duration of detected door motion to classify it based on the principle that door reversal motion typically takes longer than 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 typically be longer than a single opening motion or a single closing operation, such as where the reversal is caused by an obstacle between the doors when the doors are almost completely closed. However, short door reversal operations can also occur, such as where an obstacle blocks the door very shortly after the start of door closing. In such cases, the duration of the door motion may be less than a normal opening or closing operation and can be missed by an analysis based entirely on duration. In contrast, the system of the present disclosure classifies elevator door motion based on both a first event and a second event in the sensor data. This improves the reliability of the classification by taking into account additional information indicating the type of motion occurring in the elevator door. In particular, by using two independent events in the analysis, the system is able to base the classification on events occurring before or after the elevator door motion event, and the events are therefore indicative of the state of the system at the corresponding time.

[0011] The sensor(s) 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, one or more sensors include accelerometers, and the controller is arranged to acquire accelerometer data. Accelerometers can be used to detect accelerations (including vibrations) in the system, and these can be used to identify movement of elevator car doors (among other things). One or more sensors may also include other sensors. For example, one or more sensors may include a pressure sensor, which can be used in determining the start and stop of vertical elevator car movement within the hoistway.

[0012] In some examples, the controller is arranged to analyze the accelerometer data to identify the first event. In some examples, the controller may be arranged to analyze 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.

[0013] In some examples, identifying the first event includes identifying a period of elevator door motion between two periods of elevator door stationary. Door motion tends to be represented by consecutive periods of significant (i.e., high) acceleration in the accelerometer data. Such consecutive periods of acceleration may be from a fully closed door state to a fully open door state (normal open motion), or it may be from a fully open door state to a fully closed door state (normal closed 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 (reverse motion).

[0014] In some examples, the second event may be an event other than an elevator door movement event. In some examples, the second event is an elevator car start or elevator car stop event. An elevator car start event may be the elevator car departing from a landing. An elevator car stop event may be the elevator car arriving at a landing. Such information is useful in the classification of elevator door movement events because it is known with a high degree of certainty that the first elevator door movement after the elevator car stops must be a door opening event. Likewise, the last elevator door movement before the elevator car starts must be a door closing event because the elevator car cannot depart with an open door.

[0015] In some examples, the second event is an earlier elevator door movement event.Such information is useful because a comparison of one elevator door movement event with another elevator door movement event of a known class allows a match (or mismatch) of the class to be made.

[0016] In some examples, the second event is an earlier elevator door opening event. For example, by comparing the first event with the earlier door opening event, and establishing that the sensor data for the first event corresponds (to an appropriate degree) to 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 can 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, using an earlier door opening event as the second event is particularly convenient because, as described above, a door opening event can be identified with high reliability based on detecting an elevator car stop event and treating the first door movement event after the elevator car stop event as a door opening event. Thus, in some examples, the second event is the first elevator door opening event after the most recent elevator car stop event. It will be appreciated that the second event can be a different door opening event (i.e., in addition to one event after the most recent car stop event). For example, a door opening event immediately following an earlier (but not most recent) car stop event can also be used. This can be useful in situations where the sensor data indicates that the first elevator door movement after the car stop event has low quality and is therefore not ideal for future comparisons. In such cases, an earlier and higher quality door open event may be used. Such an earlier door open event may be from the same or a different landing, but ideally from the same landing, as the door motion signature may change between landings. It will be appreciated that the same principles apply where comparison is to be made with an earlier door closed event or an earlier door reverse event.

[0017] In some examples, the controller is arranged to classify the first event based on the correspondence of the sensor data for the first event and the sensor data for the second event. Determining the correspondence can take many different forms. For example, although a complete match of the sensor data for the two events may be required, the variability of the sensor data makes this aspect unattractive. Instead, the correspondence will generally be a certain degree of correspondence. Any appropriate matching algorithm can be used, which can allow for a certain degree of mismatch in the data while still ensuring that the overall correspondence is sufficient to give a high confidence that the two events belong to the same category. In some examples, the sensor data can be processed to generate a signature that indicates the type of motion, and the correspondence of the sensor data for the first event and the second event can include generating a signature for each event and comparing the signatures for correspondence. As an example only, some elements of a suitable signature may include the direction of the movement of the elevator door as determined by the accelerometer, the duration of the elevator door movement, and the relative time order of the minimum and maximum accelerations within the accelerometer data. In some examples, the signature may include one or more frequency components of the door motion data.

[0018] In some examples, classifying the first event includes at least one of: classifying the first event as a door open event; classifying the first event as a door closed event; and classifying the first event as a door reversal event. It will be appreciated that not all of these categories may always be used. For example, it may be sufficient to identify only door reversal events or only door open events or only door closed events. In some examples, the monitoring system uses open and reverse categories. In some examples, it may be determined that during a given landing stop, i.e., between an elevator car stop and the next elevator car start, the number of door closed events equals the number of door open events (which would be true if no errors were made in the classification).

[0019] In some examples, classifying the first event includes adjusting a counter corresponding to the category. The action of matching or not matching a set of criteria is equivalent to performing a classification, and the adjustment of the corresponding counter depending on that match or not matching is equivalent to recording or storing the classification. It will be appreciated that in other examples, the classification may be stored or recorded in other ways. For example, a list of detected events may be generated, each of which has an associated determined category. However, the use of counters to record events is sufficient for many analysis purposes, and the counter values ​​provide a simple and low data metric that can be transmitted to a monitoring station at low power and low cost.

[0020] In some examples, classifying 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 idle time that an elevator door can spend between a door open event and a door closed event is limited (i.e., the elevator door will always be indicated as closed after a predefined time period after the open event). In such cases, determining that the amount of time since the last door movement event has exceeded a threshold time period is a reliable indicator that the elevator door is currently in a closed state. In other words, where the first event and the second event are adjacent (in time) door movement events, the knowledge that the time between the first and second events exceeds the maximum door open idle time can be used to determine with high reliability that the first event (the most recent event) is a door open event. Thus, in some examples, the controller is arranged to classify the first event as a door open event when the second event precedes the first event by a predetermined amount of time.

[0021] In some examples, the classification of the first event is based on a previously determined state of the elevator door. For example, a full door closed event can be used to set the system state to "door closed". Similarly, a full door open event can be used to set the system state to "door open". It can be inferred that the next door movement after the "door closed" state must be a door open event. Similarly, it can be inferred that the next door movement after the "door open" state must be a door closed event or a door reversal event. Therefore, basing the classification of the first event on the previously determined state of the elevator door adds additional information and additional diagnostic capabilities. When the previous door state is combined with the analysis of the first event and the second event, errors in the analysis can also be determined. For example, if the door state indicates that the door is in an open state, and the first event also matches the second event (which is an earlier door open event), it can be determined that an error has occurred (the system detected two door open events in a row without detecting an intermediate door closed event), and appropriate processing can be implemented.

[0022] The analysis discussed in the present disclosure is particularly applicable to low-power systems that operate based on battery and / or energy harvesting power sources. This is the case in monitoring or diagnostic systems (e.g., condition-based maintenance systems) that do not have direct access to the elevator drive machinery and therefore must determine the elevator car and / or door motion separately. It is convenient for such systems to operate based on their own power source (battery or energy harvesting) because this makes them easier and faster to install, especially as a retrofit to older elevator systems. In addition, to facilitate installation, such systems conveniently communicate via wireless transmissions to avoid the need for hard-wired connections. Since such wireless transmissions are power intensive, it is highly desirable to minimize the amount of data to be transmitted. In addition, intensive signal processing for complex analysis consumes power, and it is also desirable to minimize processing in order to save power and extend battery life. Higher sampling rates of sensor data allow for more accurate analysis and determination of motion profiles. However, higher sampling rates consume more power, and processing larger resulting data sets can also consume more power. In the examples described herein, the analysis of door motion is sufficiently robust to operate at low sampling rates and corresponding small data sets. Thus, processing power is reduced while still maintaining high reliability for diagnosis and monitoring. In some examples, sensor data (e.g., accelerometer data) is acquired at a sampling rate of no more than 100 samples per second, or no more than 50 samples per second, or no more than 20 samples per second. It will of course be appreciated that the processing techniques described herein may also be applicable in situations where power and / or data transmission are not limiting factors, and thus in some examples, any desired sampling rate may be used.

[0023] As described above, in some examples, the elevator monitoring system is powered by a battery or energy harvesting system. The energy harvesting system may include, for example, an inductive charging system, or it may include a system based on heat, power, or wind. In some examples, the monitoring system is not connected to the mains power. With a battery or energy harvesting power supply system, low power operation becomes important, and therefore intensive processing volume, sensor sampling rate, and wireless transmission strength become important factors in achieving a suitably long operating life between services.

[0024] In some examples, the monitoring system is independent of the elevator system. As described above, this facilitates installation because no communication connection to the existing system controller is required. Thus, health monitoring can be implemented from a separate system and add a layer of safety on top of the fault detection and monitoring system within the elevator system itself.

[0025] 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 acquisition point 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, the data may be transmitted to a remote location for processing. The remote location may have different or less stringent power consumption constraints, and therefore may be able to perform more detailed and complex data analysis. The remote location may be a field gateway (i.e., at the same site as the elevator itself), or it may be at another remote site or in the cloud. In the case of local processing of data, the results (e.g., diagnostic metrics) may be transmitted directly to the field or to a remote or cloud-based monitoring station, or may be transmitted to such a monitoring system via a local gateway.

[0026] According to a second aspect of the present disclosure, there is provided a method for monitoring an elevator system, comprising:

[0027] acquiring sensor data from one or more sensors;

[0028] analyzing the sensor data to identify a first event and a second event, the first event corresponding to elevator door movement;

[0029] The first event is classified based on sensor data for the first event and the second event.

[0030] It will be appreciated that all of the optional or example features described above with respect to the monitoring system can also optionally be applied to this method of monitoring an elevator system. BRIEF DESCRIPTION OF THE DRAWINGS

[0031] Figure 1 is a schematic diagram of an elevator system according to an example of the present disclosure;

[0032] FIG. 2 is a diagram for use according to an example of the present disclosure Figure 1 Schematic diagram of a sensor system for an elevator system;

[0033] Figure 3 is used according to the example of the present disclosure Figure 1 and a schematic diagram of the location of a sensor system of the elevator system of FIG. 2 ;

[0034] Figure 4 is a schematic diagram of a sensing unit according to an example of the present disclosure;

[0035] Figure 5 Diagram showing the process used for elevator door monitoring;

[0036] Figure 6 is a flow chart of a first example of a door monitoring process;

[0037] Figure 7 is a flow chart of a second example of a door monitoring process; and

[0038] Figure 8 Shown for use with Figure 7 Similar gate monitoring process has an algorithm with pseudo code. DETAILED DESCRIPTION

[0039] Figure 1 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 the counterweight 105 are interconnected by the tension member 107. The tension member 107 may include or be configured as, for example, a rope, a steel cable, and / or a coated steel belt. 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 rail 109 relative to the counterweight 105 simultaneously and in opposite directions.

[0040] Tension member 107 engages machine 111, which is part of the overhead structure of elevator system 101. Machine 111 is configured to control movement between elevator car 103 and counterweight 105. Position reference system 113 can be mounted on a fixed portion of the top of elevator shaft 117 (e.g., on a support or rail), and can be configured to provide a position signal related to the position of elevator car 103 within elevator shaft 117. In other embodiments, position reference system 113 can be mounted directly to the moving components of machine 111, or can be located in other locations and / or configurations as known in the art. Position reference system 113 can be any device or mechanism for monitoring the position of an elevator car and / or counterweight, as known in the art. For example, without limitation, position reference system 113 can be an encoder, sensor, or other system, and can include rate sensing, absolute position sensing, etc., as will be appreciated by those skilled in the art.

[0041] As shown, the controller 115 is located in a controller room 121 of the elevator shaft 117 and is configured to control the 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 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 along the guide rails 109 in the elevator shaft 117, the elevator car 103 may stop at one or more landings 125 as controlled by the controller 115. Although shown in the controller room 121, those skilled 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.

[0042] 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 electric drive motor. The power source for the motor may be any power source (including the electrical grid), which (in combination with other components) is supplied to the motor. The machine 111 may include a traction sheave that imparts force to the tension member 107 to move the elevator car 103 within the elevator shaft 117.

[0043] Although shown and described using a roping system including tension members 107, elevator systems that use other methods and mechanisms for moving an elevator car within an elevator shaft may employ embodiments of the present disclosure. For example, embodiments may be used in ropeless elevator systems that use linear motors or pressure wheel propulsion to move the elevator car. Embodiments may also be used in ropeless elevator systems that use hydraulic lift to move the elevator car. Figure 1 These are non-limiting examples presented for illustrative and explanatory purposes only.

[0044] In other embodiments, the system includes a transport system that moves passengers between floors and / or along a single floor. Such transport systems may include escalators, people movers, etc. Accordingly, the embodiments described herein are not limited to systems such as Figure 1 In one example, the embodiments disclosed herein may be applicable to a transport system (such as elevator system 101) and a transport device of the transport system (such as elevator car 103 of elevator system 101). In another example, the embodiments disclosed herein may be applicable to a transport system (such as an escalator system) and a transport device of the transport system (such as a moving step of an escalator system).

[0045] Continue to refer to Figure 12, a view of a sensor system 200 including a sensing device 210 is illustrated in accordance with an embodiment of the present disclosure. The sensing device 210 is configured to detect sensor data 202 of the elevator car 103 and transmit the sensor data 202 to a remote device 280. The sensor data 202 may include, but is not limited to, pressure data 314, a vibration signature (i.e., vibrations over a period of time) or acceleration 312 and derivatives or integrals of the acceleration 312 of the elevator car 103, such as, for example, distance, velocity, jerk, jounce, snap, etc. The sensor data 202 may also include light, sound, humidity, and temperature or any other desired data parameter. The pressure data 314 may include the atmospheric air pressure within the elevator shaft 117. It should be appreciated that, although specific systems are defined separately in the schematic block diagram, each or any of the systems may be combined or separated in other ways via hardware and / or software. For example, the sensing device 210 may be a single sensor, or may be a plurality of independent sensors that are interconnected.

[0046] In an embodiment, the sensing device 210 is configured to transmit the sensor data 202 to the controller 115 of the elevator system 101 for processing, the sensor data 202 being raw and unprocessed. In another embodiment, the sensing device 210 is configured to process the sensor data 202 by a processing method (such as, for example, edge processing) before transmitting the sensor data 202 to the controller 115. In another embodiment, the sensing device 210 is configured to transmit the sensor data 202 to the remote system 280 for processing, the sensor data 202 being raw and unprocessed. In yet another embodiment, the sensing device 210 is configured to process the sensor data 202 by a processing method (such as, for example, edge processing) before transmitting the sensor data 202 to the remote device 280.

[0047] Processing of the sensor data 202 may reveal data such as, for example, number of elevator door openings / closings, elevator door times, vibrations, vibration signatures, number of elevator rides, elevator ride performance, elevator flight time, possible car positions (e.g., altitude, floor number), re-leveling events, falls back, elevator car 103 x, y acceleration at a certain position: (i.e., track topology), elevator car 103 x, y vibration signature at a certain position: (i.e., track topology), door performance at landing number, nudging events, vandalism events, emergency stops, etc.

[0048] Remote device 280 may be a computing device, such as, for example, a desktop, cloud-based computer, and / or a cloud-based artificial intelligence (AI) computing system. Remote device 280 may also be a computing device typically carried by a person, such as, for example, a smart phone, a PDA, a smart watch, a tablet, a laptop, etc. Remote device 280 may also be two separate devices that are synchronized together, such as, for example, a cellular phone and a desktop computer synchronized via an Internet connection.

[0049] The remote device 280 may be an electronic controller including a processor 282 and associated memory 284 including 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 a multi-processor system of any of a variety of possible architectures, including field programmable gate arrays (FPGAs), central processing units (CPUs), application specific integrated circuits (ASICs), digital signal processors (DSPs), or graphics processing unit (GPU) hardware (either homogeneous or heterogeneous arrangements). The memory 284 may be, but is not limited to, random access memory (RAM), read-only memory (ROM), or other electronic, optical, magnetic, or any other computer-readable medium.

[0050] The sensing device 210 may be configured to transmit sensor data 202 to the controller 115 or the remote device 280 via a short-range wireless protocol 203 and / or a long-range wireless protocol 204. The short-range wireless protocol 203 may include, but is not limited to, Bluetooth, Wi-Fi, HaLow (801.11ah), zWave, ZigBee, or wireless M-Bus. Using the short-range wireless protocol 203, the sensing device 210 is configured to transmit the sensor data 202 directly to the controller 115 or to the local gateway device 240, and the local gateway device 240 is configured to transmit the sensor data 202 to the remote device 280 or to the controller 115 through a network 250. The network 250 may be a computing network, such as, for example, a cloud computing network, a cellular network, or any other computing network known to those skilled in the art. Using the long-range wireless protocol 204, the sensing device 210 may be configured to transmit the sensor data 202 to the remote device 280 through the network 250. The long-range wireless protocol 204 may include, but is not limited to, cellular, satellite, LTE (NB-IoT, CAT M1), LoRa, Satellite, Ingenu, or SigFox.

[0051] The sensing device 210 may be configured to detect sensor data 202 including accelerations in any number of directions. In an embodiment, the sensing device may detect sensor data 202 including accelerations 312 along three axes (X, Y, and Z), as shown in FIG. 2 . The X-axis may be perpendicular to the door 104 of the elevator car 103, as shown in FIG. 2 . The Y-axis may be parallel to the door 104 of the elevator car 103, as shown in FIG. 2 . The Z-axis may be vertically aligned parallel to the elevator shaft 117 and gravity, as shown in FIG. 2 . The acceleration data 312 may exhibit vibration signatures generated along the X-axis, the Y-axis, and the Z-axis.

[0052] Figure 3 1 shows a possible installation location of a sensing device 210 within an elevator system 101. The sensing device 210 may include a magnet (not shown) for removably attaching to the elevator car 103. Figure 3 In the illustrated embodiment shown in , the sensing device 210 can be installed on the door hook 104a and / or the door 104 of the elevator system 101. It is understood that the sensing device 210 can also be installed in other locations besides the door hook 104a and the door 104 of the elevator system 101. It is also understood that multiple sensing devices 210 can be installed in Figure 3 104, and the embodiments disclosed herein may include one or more sensing devices 210. In another embodiment, the sensing device 210 may be attached to the lintel 104e of the door 104 of the elevator car 103. In another embodiment, the sensing device 210 may be located on the lintel 104e near the top 104f of the elevator car 103. In another embodiment, the sensing device 210 is mounted at other locations on the elevator car 103, such as, for example, directly on the door 104.

[0053] like Figure 3 As shown in FIG. , the sensing device 201 may be located in a selected area 106 on the elevator car 103, such as Figure 3. The door 104 is operably connected to the door lintel 104e by a door hook 104a, which is positioned close to the top 104b of the door 104. The door hook 104a includes a guide wheel 104c, which allows the door 104 to slide open and close along the guide rail 104d on the door lintel 104e. Advantageously, the door hook 104a is an easy to access area for attaching the sensing device 210, because the door hook 104a is accessible when the elevator car 103 is at the landing 125 and the elevator door 104 is open. Therefore, the installation of the sensing device 210 is possible without taking special measures to obtain control of the elevator car 103. For example, the additional safety of an emergency door stop to keep the elevator door 104 open is not necessary, because it is the normal operating mode for the door 104 to be open at the landing 125. The door hook 104a also provides ample clearance for the sensing device 210 during operation of the elevator car 103, such as, for example, the opening and closing of the door 104. Due to the mounting location of the sensing device 210 on the door hook 104a, the sensing device 210 can detect the opening and closing motion (i.e., acceleration) of the door 104 of the elevator car 103 and the door at the landing 125. In addition, mounting the sensing device 210 on the hook 104a allows for the recording of the ride quality of the elevator car 103.

[0054] Figure 4 More detailed illustration Figure 2 and Figure 3 314. The example of a sensing device 210 of FIG. 210 is shown. The sensing device 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 include an inertial measurement unit (IMU) 218 ​​and a pressure sensor 228. The IMU 218 includes three accelerometers 229 and is configured to detect the acceleration of the elevator car 103 and / or the elevator car door 104, and to generate acceleration data 312. The pressure sensor 228 (which may be, for example, a pressure altimeter or a barometric altimeter) is configured to detect the atmospheric air pressure within the elevator shaft 117, and to generate pressure data 314. Both the IMU 218 and the pressure sensor 228 communicate with the controller 212 of the sensing device 210. It will be appreciated that while the pressure sensor 228 may be used to provide additional information about the movement of the elevator car 103, it can also be omitted in some examples. In some examples, plurality of sensors 217 may also include additional sensors, such as light sensors, microphones, humidity sensors, and temperature sensors.

[0055] The power source 222 of the sensing device 210 is configured to store electrical power and supply it to the sensing device 210. The power source 222 may include an energy storage system, such as a battery or a capacitor, or other suitable energy storage system known in the art.

[0056] 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 the controller 115 via at least one of the short-range wireless protocol 203 and the long-range wireless protocol 204 as described above.

[0057] The controller 212 of the sensing device 210 includes a processor 214 and a memory 216 including computer executable instructions that, when executed by the processor 214, cause the processor 214 to perform various operations, such as processing the sensor data 202 collected by the IMU 218 and the pressure sensor 228 to determine information related to the movement of the elevator car 103. The sensing device 210 also includes a buffer 227 that is configured to store a preset number of data entries.

[0058] Figure 5An example of a method for classifying door motion based on sensor data is illustrated. The method begins at step 500, where sensor data is acquired from one or more sensors. The one or more sensors may be an accelerometer 229 or a set of accelerometers (e.g., IMU 218), the set of accelerometers may include a set of three mutually orthogonal accelerometers, or it may include one or more of the additional sensors described above. In step 502, the sensor data acquired in step 500 is analyzed to identify a first event and a second event within the data. The first event is the door 104 motion to be classified by this process. The second event is another event, which may be another door 104 motion event, or may be an elevator car 103 motion event. In the case where the second event is another door 104 motion event, it may be, for example, a door 104 open event or a door 104 closed event or a door 104 reverse event. In the case where the second event is a car 103 motion event, it may be, for example, 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 classified based on the sensor data for the first event and the sensor data for the second event. In this step, the first event is classified not only based on the sensor data acquired relative to the first event, but also based on the sensor data acquired relative to the second event. Therefore, the classification is based on the knowledge of some other system motion (the motion occurs before or after the first event). Considering this additional sensor data for the 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 for accurate classification of the first event. The data acquired for the second event will in many cases be acquired as part of normal system operation anyway. Therefore, this system takes advantage of the additional information that already exists 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 need to be acquired at the same rate, but can be selected according to the needs of the sensor and the system.

[0059] Figure 6An example of a classification process that can be used to classify door 104 motion is shown in detail. Starting at step 600, the process checks whether this is the first door 104 motion since the car 103 stopped at the landing 125. If "yes", then in step 602, the door 104 motion event is classified as a door open event. This is based on the assumption that the door 104 is closed when the elevator car 103 stops at the landing 125, and therefore the next door 104 motion must be a door open event. In this case, the second event is a car 103 motion event, and the first event is classified based on the first event (motion detected) and the second event (car stop event detected). If step 600 infers that the door motion is not the first motion after the car 103 has stopped ("no"), the process enters step 604 for further analysis. In step 604, the process checks whether the door 104 motion signature matches the first door open signature. If "yes", the process enters step 608, where the process checks whether the state of the last known door 104 is "open". If "yes", then an error has occurred because the door 104 opening event has obviously been detected when the door state is already considered to be open. Therefore, in step 612, the error is noted. Additional processing may be performed to handle the error (examples are provided below). If the previous door state was not "open" ("no" from step 608), the process enters step 610, where the door 104 motion event is classified as a door opening event. In this case, based on the first event (detection of door motion), based on the second event (the first opening signature to which it is compared in step 604) and the previous system state (the door opening state checked in step 608), the door 104 motion event (i.e., the first event) has been classified. Finally, if the comparison between the door 104 motion event (the first event) and the first door opening signature (the second event) in step 604 is "no", it is determined that the door 104 motion is not an opening event, and therefore in step 606, the door 104 motion is classified as a door closing event or a door reversal event.

[0060] exist Figure 6In the process of , no distinction is made between door closing events and door reversal events. This degree of classification may be sufficient for diagnostic and monitoring purposes. However, if further separation of closing and reversal events is required, further analysis can be performed. For example, a comparison of motion signatures for known closing events or known reversal events can be performed. However, in some examples, the number of door closures can be determined based on already available data. For example, the number of full door opening events and full door closing events should be equal. Alternatively, events classified as door closing events or door reversal events in step 606 can be further classified based on detecting that the next event is a door 104 opening event (the event can only occur when the door 104 is fully closed) or a car 103 start event (the event only occurs when the door 104 is fully closed). In the first case, the further classification has been classified again based on two door 104 motion events (closing / reversing event followed by opening event), and in the second case, the further classification has been classified again based on door 104 motion events and car 103 motion events (closing / reversing event followed by car start event). In some examples, classifying gate reversal events is most important for characterizing the health of gate 104 .

[0061] Figure 7 Another example of the classification process is shown. Figure 7 The process and Figure 6 The process is similar to , but includes some additional steps. Figure 6 The same steps as in the steps in are marked with the same reference numerals and will not be repeated here. Figure 7In the example process of , if it is determined in step 600 that the door 104 movement is not the first door 104 movement after the elevator car 103 stop event, the process proceeds to step 700. In step 700, the process checks whether the time since the last door 104 movement is greater than 6 seconds (but it will be appreciated that this time is given as an example only, and any appropriate time threshold may be used according to the specific elevator system being monitored). If the time since the last door 104 movement is greater than 6 seconds (from "yes" in step 700), the process proceeds to step 702, where the door 104 movement (i.e., the first event) is classified as a door opening event. This analysis is based on the following system knowledge: the elevator door 104 does not normally remain open for 6 seconds without attempting a closing movement. Therefore, if the door 104 remains stationary for more than 6 seconds, it can be inferred that the door 104 movement must be an opening event. In this case, the classification has been based on two door movement events (the current door 104 movement event (i.e., the first event), and the time since the previous door 104 movement event (i.e., the second event)). If the analysis in step 700 is "no", the process proceeds to step 704, where the process checks whether the last door state was set to "open" after the timer-based determination. If "yes", the process proceeds to step 706, where the door 104 movement (i.e., the first event) is classified as a door closing event or a door reversal event. This classification step is similar to the classification in step 606, but in this case, the classification is based on reliably determining the door open state after the previous movement. Therefore, it is now possible to reliably confirm that the current movement is a non-opening event. As with the above-mentioned step 606, further processing can be performed to further classify closing events and reversal events. If the determination in step 704 is "no", the process proceeds to step 604, which then proceeds as described with reference to the above. Figure 6 The same manner as described above is continued. It will be appreciated that in some examples, steps 704 and 706 may be omitted, as the door closure / reversal should not pass the signature check in step 604 and be counted at step 606. However, identification after the timer is considered a more reliable determination, and therefore gives a more reliable classification. Therefore, steps 704 and 706 provide a more reliable classification.

[0062] Figure 8 Show execution according to Figure 7 An example of the algorithm for the example process. Figure 8The upper portion of shows how the algorithm moves between the door 104 stopped state 800 and the door 104 in motion state 802. Starting in 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 begins acquiring motion_samples, which is an array of sensor data acquired from 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 the door in motion state 802 to the door stopped state 800 via the main algorithm, which is stated as Figure 8 The pseudo code in the lower part of .

[0063] We will now briefly describe Figure 8 The main algorithm of . First, check the flag door_motion_stopped. This corresponds to the change of state from state 802 to state 800 in the upper part of the figure, and is the trigger that starts the main algorithm. The algorithm then checks whether opening_signature is an empty array. The array opening_signature is a collection of values ​​derived from the motion_samples array, which is acquired during an earlier door 104 opening event. This signature is ideally acquired from the first door 104 motion event after the elevator car 103 stops at the landing 125, because this event is reliably determined as an opening event. The signature (defined by the opening_signature array) is a collection of values ​​that characterize the motion, and may include, for example, the direction of the 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, this signature has not yet been determined, and therefore this must be the first door 104 motion after the stop of the elevator car 103. Therefore, the opening_signature array is set 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 the first door 104 motion after the elevator car stops according to Figure 7The step 602 is classified as a door opening event. In addition, two status flags just_opened and just_opened_first_time are set to True.

[0064] If the door motion is not the first since the car stopped, the algorithm next checks whether the variable time_since_last_door_motion is greater than 6 seconds. This corresponds to Figure 7 The check in step 700 is performed, and if True, the algorithm increments the counter door_cycles by one to reflect the Figure 7 The classification of the door opening event in step 702. In addition, the flag just_opened is set to True to reflect the known door state as "open", and the flag OpenByTimerMrk is set to True to reflect that the current door opening state is determined by a timer.

[0065] If the time since the last door movement is not greater than 6 seconds, the algorithm next checks whether OpenByTimerMrk is True, which corresponds to Figure 7 704 in processing step 706. If so, the flag OpenByTimerMrk can now be reset to False, and the counter "reversals" incremented by one to reflect that the door motion event is not a door opening event. It should be noted here that if the current door motion is a door closing event or a door reversal event, the counter "reversals" is incremented. However, as discussed further below, closing events will be removed later by additional classifications, 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 may now be in the closed state after a closing event or in the open state after a reversal event). Also, the just_opened_first_time flag is set to False.

[0066] If it is determined that the last motion state was not set by the timer, the algorithm next checks whether the motion_signature array for the current door 104 motion matches the opening_signature array determined at the beginning of the main algorithm when the first door motion after the car stopped was detected. This corresponds to Figure 7604 in the figure. It will be noted that the is_matching comparison function need not require an exact match, but may allow a match to within a certain degree, for example by having the various values ​​be within certain tolerances or thresholds of each other. A check is also made that the flag just_opened_first_time is not set. Movement after the first door movement should not be determined as an opening event, and therefore this check ensures that subsequent processing is avoided. This allows for special uses of the is_matching() function (not shown in the figures) - since it is known that the is_matching() function should return "false" for the first movement after the first door is opened, a "true" return can be used to indicate poor quality signature acquisition during the first opening movement. If such a poor quality signature is determined, an alternative signature can be used instead. ， That is, a previously verified signature (for example from a previous run or from a different floor station). In the event that motion_signature is determined to match opening_signature and the flag just_opened_first_time is not set, the algorithm next checks whether the flag just_opened is set. If the flag just_opened is not set, it is determined that the current motion represents an opening event following a non-opening event. An opening event can only occur after a closing event has occurred, and it can therefore be assumed that a full closing event has occurred (and should be counted by the reversals counter). Therefore, (for safety) it is checked that the reversals counter is greater than zero (which it should be), and then the reversals counter is decremented by one in order to remove the full closing event from the count. In addition, the counter door_cycles is incremented by one to reflect the classification of the current motion as a door opening event. This corresponds to Figure 7 In step 610. In addition, the flag just_opened is set to True to reflect the known door state as "open".

[0067] If the door signature matches after the is_matching comparison, but the flag just_opened is set to True, the algorithm determines that an error has occurred because the door open signature was found when the door state was already considered open. In this case, something must have gone wrong with the algorithm or the sensor data, and some appropriate action can be taken. In this example, the door_cycles counter is incremented once every two times this condition occurs to reflect that counting all opens would be an overestimate. This corresponds to Figure 7 Step 612 in .

[0068] More specifically, although this error handling is Figure 8It is not set out in detail in , but an example operation is as follows: A variable called TwoOpeningMrk evolves between the values ​​0 and 1 (each with error checking). The first time this condition occurs, TwoOpeningMrk takes the value 1, and the number of openings is not incremented. The next time this condition occurs, TwoOpeningMrk takes the value 0, and the number of openings is incremented by one. The next time, TwoOpeningMrk takes the value 1, and the number of openings is not incremented, and so on. At the end, when the car moves, if the flag just_open is True and TwoOpeningMark is 0, a counter for the number of loops is decremented. It will be appreciated that this is just one example of an error handling routine, and that many alternatives exist.

[0069] Finally, if none of the above checks are triggered, the final step is to classify the door 104 motion as a closing event or a reverse event. Therefore, the reverse counter is incremented by one, the just_opened flag is set to False, and the just_opened_first_time is set to False to indicate that the door is not known to be in the open state. This corresponds to Figure 7 Step 606 in .

[0070] Back to Figure 8 , after returning to the door stop state 800, if the elevator car then starts moving, it can be assumed that a full door closing event has occurred. Therefore, the reverse counter is decremented by one to remove the door closing event that should have been counted previously in the process (after a confirmation check that the reverse counter is actually greater than zero).

[0071] It is also shown here that when it is determined that the car has stopped moving, initialization of the variables is performed so that the opening_signature array is set to empty, the motion_signature array is set to empty, the door_cycles counter is set to zero, the reverse counter is set to zero, the just_opened flag is set to False, the just_opened_first_time flag is set to False, and the OpenByTimerMrk flag is set to False.

[0072] It will be appreciated by those skilled in the art that the present disclosure has been illustrated by describing one or more specific examples thereof, but that the present disclosure is not limited to these examples; many variations and modifications are possible within the scope of the appended claims.

Claims

1. An elevator monitoring system, comprising: one or more sensors; A controller arranged to: acquiring sensor data from the one or more sensors; analyzing the sensor data to identify a first event and a second event, the first event corresponding to elevator door movement; classifying the first event based on sensor data for the first event and the second event, Wherein, classifying the first event comprises at least one of the following: classifying the first event as a door opening event; classifying the first event as a door closing event; and The first event is classified as a gate reversal event.

2. The elevator monitoring system according to claim 1, wherein: The one or more sensors include an accelerometer, and the controller is arranged to acquire accelerometer data.

3. The elevator monitoring system according to claim 2, wherein: The controller is arranged to analyse the accelerometer data to identify the first event.

4. The elevator monitoring system according to claim 3, wherein: Identifying the first event includes identifying a period of elevator door movement between two periods in which the elevator doors are stationary.

5. The elevator monitoring system according to any one of claims 1 to 4, wherein: The second event is an elevator car start or an elevator car stop event.

6. The elevator monitoring system according to any one of claims 1 to 4, wherein: The second event is an earlier elevator door movement event.

7. The elevator monitoring system according to claim 6, wherein: The second event is an earlier elevator door opening event.

8. The elevator monitoring system according to claim 7, wherein: The second event is the first elevator door opening event following a most recent elevator car stopping event.

9. The elevator monitoring system according to claim 6, wherein: The controller is arranged to classify the first event based on a correspondence of sensor data for the first event and sensor data for the second event.

10. The elevator monitoring system according to any one of claims 1 to 4, wherein: Classifying the first event includes adjusting a counter corresponding to the category.

11. The elevator monitoring system according to any one of claims 1 to 4, wherein: Categorizing the first event is based on an amount of time between the first event and the second event.

12. The elevator monitoring system according to claim 11, wherein: When the second event precedes the first event by a predetermined amount of time, the controller is arranged to classify the first event as a door opening event.

13. The elevator monitoring system according to any one of claims 1 to 4, wherein: Classifying the first event is based on a previously determined state of the elevator door.

14. A method for monitoring an elevator system, comprising: acquiring sensor data from one or more sensors; analyzing the sensor data to identify a first event and a second event, the first event corresponding to elevator door movement; classifying the first event based on sensor data for the first event and the second event, Wherein, classifying the first event comprises at least one of the following: classifying the first event as a door opening event; classifying the first event as a door closing event; and The first event is classified as a gate reversal event.

Images