Patent Application
20210171320
The prevent invention relates generally to escalator-monitoring. More particularly, the present invention relates to a device and methods for detecting/alerting unsafe operation and users, detecting running state/events, notifying unsafe/abnormal occurrences, providing the state to a requester and sending detected data to computing/IoT cloud(s). Some of its functions, such as detecting usage and users' heights, can also be used other fields demanding head/height counting.
Escalators are commonly operated in subway stations, shopping malls, airports, office buildings, hotels, casinos, sports facilities and many other types of venues. However their accidents occur thousands times each year in US alone, often resulting in serious injuries. The reasons for the accidents vary but many accidents involving injury can be attributed to their property owners, maintenance companies and manufacturers. The most common theories of liability in escalator accidents are product liability and negligence. One of the most effective preventions is that every user hold their escalator handrails when using. Not holding handrail is prone to fall and dangerous, not only for the first faller, but may also trigger a “domino effect” of falls. Escalator-related lawsuits/litigations have occurred. However, it is not uncommon that some of the users do not hold their handrails. For this purpose, devices which can detect the not-hold-handrail users and alert the users to hold the handrail before any loss of balance can occur are needed.
Next, escalators' abnormal/unsafe events, such as “Jerky movements”, “Sudden acceleration”, “Sudden deceleration”, “Reversing direction”, “Missing stair step(s)”, unexpected stops, occur once a while. Another of the most effective preventions is to find/fix any unsafe/abnormal occurrences at the earliest. However, most escalators had been outsourced and have nobody on their sites to monitor, plus some of the event occurrences can hardly be observed/identified instantly, let alone to report/fix them. For this purpose, devices which can detect/identify the events and notify needed personnel, such as maintenance and/or traffic-control, the event occurrences automatically, fast and cost-effectively are needed, but absent.
Next, many organizations, such as public transportation, charities and third parties, provide subsidized low-fee or free door-to-door transportation services for special groups, such as those who use walking sticks. Many of them are able to use public transportation themselves if escalators at transferring stations are running properly. For this purpose, devices which can receive and provide by replying the escalators' state to requests from the groups of users/providers/systems via internet/intranet can greatly reduce the users' waiting time and the providers' operational costs (by Max capitalizing existing systems), are needed, but absent.
Next, uploading by sending big data of operation and usage, such as operation state, abnormal/unsafe occurrences, running direction, lane/side-precise numbers of users and their heights, number of not-hold-handrail users, number of requests for the operation state, to computing/IoT cloud in real time for being archived, managed and consumed therein can ease and open up new ways to improve, such as planning, operating and manufacturing. For this purpose, devices which can detect/collect/upload the big data to computing/IoT cloud(s) for archiving/managing/consuming automatically, in real time are needed, but absent.
Additionally, dual-lane escalators, typically, have their standing users on one side and walking users on the other side. Even users on single-lane escalators may not be in the mid of their two sides all the time. These cause uneven wear-out and need being repaired at very high costs in a long run. Analogously to vehicular tire rotation, the uneven wear-out can be simply avoided by reversing direction after a certain time period. This can be done at most sites, since their escalators are in pairs and running in opposite directions at the same time. In order to achieving this, numbers of users and/or their body heights/groups in each escalator lane/side need being tracked to assist determining their usage-dependent direction-reversing times.
Previous inventions have described passenger counting, however, these are designed specifically for purposes of U.S. Pat. No. 9,569,902B2 “Passenger counter” for a vehicle/elevator and U.S. Pat. No. 20080212099A1 “Method for counting people passing through a gate”, may be useful for this purpose. But it's not clear if they can count/provide numbers of standing/walking users precise to each running/stopped escalator lane/side. They surely differ from the present invention, such as below:
Heretofore, an escalator-monitoring/operable device and methods for
NOTE: For simplicity of illustration, WI-FI®, Ethernet®, Internet, electric power supply, PCB (Printed Circuit Board), AD convertor, memory ICs, resistors, capacitors, housing/enclosure, support/stand, nuts, bolts and industry hardware are not depicted as they are known to those with skill in the art. When they are shown, it is purely for illustrative purposes and not intended to capture all embodiments of the invention disclosed.
The accompanying drawings, which are incorporated in and constitute a part of the specification, illustrate a preferred embodiment of the invention and, together with a general description given above and the detailed description of the preferred embodiment given below, serve to explain the principles of the invention.
Embodiments of the present invention comprise an operable device and methods for monitoring escalators. Embodiments of the device basically comprise:
one or more sensing device(s)/sensor(s) installed above an escalator, said sensors, which collectively detect the escalator's operation (escalator-sensor) and its users' hands/wrists/arms (arm-sensor), both sensors detect height change in distance between the escalator's stair step/user and the sensor(s) at a time;
one or more processing device(s) which comprise processor(s) or a computer integrated with the processor, a memory, an IO and IoT device, coupled to each one of said sensors to receive data therefrom;
a non-transitory computer readable storage medium which comprises a memory and is used for storing program and data for access by the program being executed on the processor/computer;
an IO device or the IO integrated in the processor/computer, coupled to said processor/computer, to input, output therein data, one or more signals;
an IoT device or the IoT integrated in the processor/computer, coupled to said processor/computer to send out one or emails, transmit therein data/message computing clouds and/or at least one MQTT publisher over private and/or public internet/intranet; and
one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the processor/computer, the one or more programs including instructions and/or functional blocks (nodes) and/or (FPGA/CPLD) descriptors for:
acquiring data from said escalator-sensors and arm-sensors, wherein to receive data therefrom;
acquiring the data;
analyzing the data to determine escalator/user data, flags of escalator/user data, cycle range, cycle times, cycle times' inequality/ratio, sums of absolute delta consecutive escalator step heights, groups of consecutive user data, utilizing the processing device;
identifying a predetermined state/(abnormal/unsafe) event and usage of the escalator, and the user's height in order to alert/notify/reply/upload, based on the analyzing, utilizing the processing device, the state/event, such as: detecting not-hold-handrail users, operation state: normal (“running”), abnormal occurrences (“Jerky movements”, “Sudden acceleration”, “Sudden deceleration”, “Missing stair step”, “Reversing direction”, “Stopped”), receiving/replying a request for the state and uploading the detected data to computing/IoT cloud(s) at a system preset interval;
alerting the not-hold-handrail user, based on the identifying, utilizing the processing device and the IO device, including: outputting one or more signals to trigger/activate external device/circuit to alert the not-hold-handrail user;
notifying the event occurrence(s), based on the identifying, utilizing the processor(s) and the IoT device, including: sending email(s) to notify the escalator's maintenance and/or traffic-control personnel when any abnormal event has occurred;
receiving/replying a request for the state, based on the identifying, utilizing the processor(s) and the IoT device, including: receiving the request and replying by sending the identified state to the request via internet/intranet; and uploading, based on the identifying, utilizing the processor and the IoT device, including: sending the identified data to one or more computing/IoT cloud(s) via internet/intranet at a system preset interval, such as every 3 minutes.
It should be appreciated that the device described above is only one example of an escalator-monitoring/operable device, and that the device may have more or fewer components, may combine two or more components, or may have a different configuration or arrangement of the components. The various components may be implemented in hardware, software or a combination of hardware and software, including one or more signal processing and/or application specific integrated circuits. For example, depending on types of sensors used, analog or digital, AD converter(s) need being used to connect/convert analog sensors' output before transmitting to the processor/computer, but no need for digital sensors.
The types of the processor/computer can be traditional instruction, such as a single board IoT computer Raspberry Pi™, as well as FPGA (Field Programmable Gate Array)/CPLD (Complex Programmable Logic Device). FPGA/CPLD can be programmed into application-specific state machines, counters, logic operators, IOs and interfaces by descriptors (e.g. a Flip/Flop cell) in HDL (Hardware Description Language), such as VHDL™, Verilog™. Multiple processors, including FPGA/CPLD, can optionally used to divide tasks/functions for the invention. NODE-RED™, software supported by the Raspberry Pi™, offers drag & drop functional blocks (nodes). Some of the blocks (nodes) only need being configured to function, such as IoT block for sending data to clouds, email block for sending emails, while some can be programmed by instructions, such as JavaScript™ block to program in Javascript™, GPIO block to input/output 10 signals.
The form of the one or more programs can be any combinations of instructions (e.g. Raspberry Pi™/JavaScript™), functional blocks (e.g. Raspberry Pi™/NODE-RED™) and descriptors (e.g. FPGA/CPLD, HDL).
The advantages of using embodiments of the device/methods are many, such as below listed:
The terms and phrases as indicated in quotes (“ ”) in this section are intended to have the meaning ascribed to them in this Terminology section applied to them throughout this document including the claims unless clearly indicated otherwise in context. Further, as applicable, the stated definitions are to apply, regardless of the word or phrase's case, to the singular and plural variations of the defined word or phrase.
The term “or” as used in this specification and the appended claims is not meant to be exclusive rather the term is inclusive meaning: either or both.
References in the specification to “one embodiment”, “an embodiment”, “an alternative embodiment” and similar phrases mean that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least an embodiment of the invention. The appearances of the phrase “in one embodiment” in various places in the specification are not necessarily all meant to refer to the same embodiment.
The term “couple” or “coupled” as used in this specification and the appended claims refers to either an indirect or direct connection between the identified elements, components or objects. Often the manner of the coupling will be related specifically to the manner in which the two coupled elements interact. Directional and/or relationary terms such as, but not limited to, left, right, top, bottom, vertical, horizontal, upward, downward, back, front and lateral are relative to each other and are dependent on the specific orientation of an applicable element or article, and are used accordingly to aid in the description of the various embodiments and are not necessarily intended to be construed as limiting.
Reference will now be made in detail to embodiments, examples of which are illustrated in the accompanying drawings. In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the present invention. However, it will be apparent to one of ordinary skill in the art that the present invention may be practiced without these specific details. In other instances, well-known methods, procedures, components, circuits, and networks have not been described in detail so as not to unnecessarily obscure aspects of the embodiments.
As applicable, the terms “about” and “generally” as used herein unless otherwise indicated mean a margin of ±20%. Also, as applicable, the term “substantially” as used herein unless otherwise indicated means a margin of ±10%. Concerning angular measurements, “about” or “generally” refer to ±10 degrees and “substantially” refers to ±5.0 degrees unless otherwise indicated. It is to be appreciated that not all uses of the above terms are quantifiable such that the referenced ranges can be applied.
Exemplary embodiments of the device including many variations and uses thereof are illustrated in
Attention is now directed towards basic structure and components of an escalator are illustrated in
Attention is now directed towards an escalator's “Moving Components” as illustrated in
One of 3 dimensions of the optimal locations, generally between 3rd to 5th steps from its upper and lower entrances/exits, can be found by following method steps:
A directly sensed height of using this configuration is the distance from the sensor to top of an object underneath, i.e. not its actual height. For example, if a sensor is at 2.5 meter above the escalator, a 1.73-meter user will be measured as 2.5-1.73=0.77 meters instead of 1.73 meters, if measuring error is ignored. Actual Height can be converted by following:
Actual Height=Sensor's height−Sensed distance
For simplifying/intuitive description purpose, use “Height-converted” as Actual Height thereafter, although sensed one can do the same.
The other dimensions of escalator-sensors 9 with sensing paths 13 and arm-sensors 12 with sensing paths 13 are illustrated for single-lane escalator in
Arm-sensors are typically near the escalator-sensors, horizontal distance L1 from their nearest handrails, typically between a few to tens of cm as illustrated in
Both of the escalator-sensors and the arm-sensors are installed by an individual or an entity at the locations determined by the 3 dimensions described. They can be installed on single and/or both sides of the escalator, regardless single or double lanes.
The escalator-sensors and arm-sensors for the invention, generally, have resolution less than 3 cm, frequency response more than 24 Hz and sensing distance more than 2.5 meters.
Some of the suitable sensors for the invention are
In this installation configuration as illustrated in
The disadvantage of this: there may be a small “dead window” without escalator data when users are passing through all the sensors (for escalator and arm) at the same time, It can detect the escalator when a gap and/or lack of the user under any of the sensors. This is not a problem for this type of application since its probability/duration is small and short, besides the 2nd exemplary can overcome it.
Finding how users act/behave on escalators, such as stand, stand on single step, stand on 2-consecutive steps, walk, is also useful, since sensed data and their waveforms contain/show these differences.
Adapting IoT computer Raspberry Pi™ to implement/execute the flowcharts/algorithms illustrated in
Alternatively adding a FPGA/CPLD to take over some of Raspberry Pi™ tasks for this implementation, such as detection, counting and IO data/signal, by implemented FPGA/CPLD state machines, counters, inputting data from sensors, outputting 10 signals to externally, can also be done. But communication between them (the Raspberry Pi™ and the FPGA/CPLD) is needed. The communication can be implemented in many ways, such as via I2C and/or SPI interfaces in both of them. I2C and SPI are already provided and ready to use in a Raspberry Pi™ and commonly used in FPGA/CPLD as well.
The methods/algorithms can be executed in parallel and simultaneously, such as flowcharts/algorithms illustrated in
The attributes/thresholds used are defined/re-outlined thereafter:
V1, a constant number, refers to the lowest height of an escalator floor step at the sensing position illustrated in
V2, a constant number, refers to the highest height of an escalator floor step at sensing position illustrated in
T1, a constant number, refers to the periodic cycle time from V1 to V2 as illustrated in
T2, a constant number, refers to the periodic cycle time from V2 to V1 as illustrated in
VPH, a constant number, refer to Minimum body height as a threshold. A realistic value, such as toddler's 70 cm and/or its equivalent digital one is a good to use. It is much greater than Maximum step height V2, for example about 8 cm. Thresholds, such as VPH, are used to detect/determine/validate data class belonging to (e.g. escalator or body) and signal/Flag of body passing. For example, detect/flag by comparing the data received from the sensors to the VPH, if greater or equal to the Minimum body height (WPH), then body data and/or body passing, otherwise if less or equal to the Maximum step height (≤V2 and ≥V1), then escalator data, if less than V1, means missing stair step(s) occurred.
VAH, a constant number, refers to Minimum arm height as a threshold, generally, about handrail height. VAH is higher than Maximum step height V2 and used to detect/determine/validate data and signal/Flag of arm passing. For example, detect by comparing the data received from the arm-sensors to the VAH, if greater or equal to the Minimum arm height (≥VAH), then valid arm data and/or arm passing.
Max number, a constant number (used in
List of the Invention's Methods/Algorithms/Rules
List of in-Response-to Actions of the Invention's Methods/Rules
The analyzing of the Method/operations further comprising:
Attention now directed towards flowchart/algorithm for detecting escalator operation state is illustrated in
Scenario 1 running (without user passing)
Scenario 2 stopped
Scenario 3 user passing
Now walking through scenario 1 running detection, in steps S1-S18
S1: after power-up start to clear all counters/variables (flags) used, go S2;
S2: get an input data from an escalator-sensor, go S3;
S3: compare if the input data is (Yes) escalator data, go S4;
S4: compare if the data (No) equal to last escalator data, go S5;
S5: compare if the data is Minimum step height V1: (Yes) go S6, otherwise go S2 to get next input data; using V1 instead of =V1 for noise/fluctuation concern;
S6: clear/start counter to count expected T1 cycle and go S7;
S7: get an input data, increase number of input counter, calculate ΣΔL=sum of absolute data difference of between this input and last one and go S8;
S8: compare if the input is escalator data: (Yes) go S9, otherwise go S2;
S9: compare if the new data equal to previous one, (No) go S10, otherwise S23;
S10: compare if the new data equal to Maximum step V2, (Yes) expected T1 cycle ended and go S11, otherwise go back S7 to continue expected T1;
S11: save ΣΔL, number of input data for T1, go S12
S12: compare if the actual calculated match expected in T1:
If ΣΔL differs vertical range (V2-V1) over allowed tolerance, mean abnormal “Jerky Movements” happed during T1 cycle and go S21/S22 to check if needs re/notifying the abnormal occurrence via email, otherwise go S2;
If number of input data saved differs number of input data in T1 at sampling rate/clock used over allowed tolerance, mean abnormal “Sudden Acceleration or Deceleration” happened in T1 cycle, go S21/S22 to check if needs re/notifying the abnormal occurrence via email, otherwise go S2.
If ΣΔL and number of input data match, mean normal/running so far, go S13 for expected T2
S13: get an input data, increase number of input counter, calculate ΣΔL and go S14;
S14: compare if the input is escalator data: (Yes) go S15, otherwise go S2;
S15: compare if the new data equal to previous one, (No) go S16, otherwise S25;
S16: compare if the data is Minimum step height V1: (Yes) expected T2 ended and go S17, otherwise go S13 to continue the expected T2;
S17: save ΣΔL, number of input data for T2, clear counter, go S18
S18: compare if the actual calculated match expected in T2:
If ΣΔL differs vertical range (V2-V1) over allowed tolerance, mean abnormal “Jerky Movements” happened during T2 cycle and go S21/S22 to check if needs re/notifying the abnormal occurrence via email, otherwise go S2;
If number of input data saved differs number of input data in T2 at sampling rate/clock used over allowed tolerance, mean abnormal “Sudden Acceleration or Deceleration” happened in T2 cycle, go S21/S22 to check if needs re/notifying the abnormal occurrence via email, otherwise go S2;
If either ratio T1(number of input data)/T2(number of input data) and/or their length relationship differs the ones in previous cycle over allowed tolerance, mean abnormal “Sudden Reversing Direction” occurred, go S21/S22 to check if needs re/notifying the abnormal occurrence via email, otherwise go S2;
If all (ΣΔL, number of input data, T1/T2) match, mean normal/running, go S2. Now walking through scenario 2 stopped detection under 3 conditions (redundant steps omitted):
Condition 1 “Stopped” detected before start T1 cycle in steps [S1-4, S19-22]
S4: compare if the data (Yes) equal to last escalator data, go S19;
S19: increase same-value counter by 1 and go S20;
S20: compare if the same-value counter more than Max number (number of counts/input data in one cycle T1+T2 at sampling rate/clock) over allowed tolerance, mean abnormal “Stopped” occurred, go S21/S22 to check if needs re/notifying the abnormal occurrence via email, otherwise go S2;
Condition 2 “Stopped” detected during T1 cycle in steps [S1-9, S23-24, S21-22]
S9: compare if the new data equal to previous one, (Yes) go S23, otherwise S10;
S23: increase same-value counter by 1 and go S24;
S24: compare if the same-value counter more than Max number (number of counts/input data in one cycle T1+T2 at sampling rate/clock) over allowed tolerance, (Yes) mean abnormal “Stopped” occurred, go S21/S22 to check if needs re/notifying the abnormal occurrence via email, otherwise go S2.
Condition 3 “Stopped” detected during T2 cycle in steps [S1-15, S25-26, S21-22]
S15: compare if the new data equal to previous one, (Yes) go S25;
S25: increase same-value counter by 1 and go S26;
S26: compare if the same-value counter more than Max number (number of counts/input data in one cycle T1+T2 at sampling rate/clock) over allowed tolerance, (Yes) mean abnormal “Stopped” occurred, go S21/S22 to check if needs re/notifying the abnormal occurrence via email, otherwise go S2.
Now walking through scenario 3 detected body data/passing under 3 conditions:
Condition 1 body data detected before start T1 cycle in steps S1-3
S3: compare if the input data is (No) escalator data, leaves the current body data for simultaneous flowchart/algorithm in
Condition 2 body data detected during T1 cycle in steps in steps S1-8
S8: compare if the input data is (No) escalator data, leaves the current body data for simultaneous flowchart/algorithm in
Condition 3 body data detected during T2 cycle in steps in steps S1-14
S14: compare if the input data is (No) escalator data, leaves the current body data for simultaneous flowchart/algorithm in
Attention: NODE-RED email block (node) used in step S22 needs being configured before executing, such as set email's recipients, subject containing the detailed abnormal message and reporting escalator's address.
Determining/flagging a body passing in steps S1-7:
S1: after power-up start to clear all counters/variables (flags), set VPH, go S2;
S2: get an input data from an escalator-sensor, go S3;
S3: compare if the input data is (Yes) body data, go S4, otherwise go S2;
S4: Set body passing Flag=True, Body Height=input data, go S5;
S5: get an input data from escalator-sensor, go S6
S6: compare if the input data is body data, (Yes) go S7, otherwise the body passed and go S8;
S7: update Body Height with the input if bigger, go S5;
Determining/sending detected data to cloud in S8-10:
S8: Set body passing Flag=False, Increase number of user counter by 1, append the Body Height in buffer, go S9;
S9: compare if time to send data to cloud, (Yes) go S10, otherwise go S2;
S10: send (selected/detected) data to cloud by via NODE-RED IoT block, go S2; Attention: NODE-RED IoT block/(node) used in step S10 is IBM™ Bluemix cloud, other clouds such as Amazon™, MQTT also can be used. The IoT block (node) needs being configured before using, such as IP, data type.
S1: after power-up start to clear all counters/variables (flags), set VAH, go S2;
S2: set arm passing Flag=False, go S3
S3: get an input data from an arm-sensor, go S4;
S4: compare if the input data is valid arm data, (Yes) go S5, otherwise go S2;
S5: Set arm passing Flag=True, go S6;
S6: get an input data from the arm-sensor, go S7
S7: compare if the input data is valid arm data, (Yes) go S6, otherwise arm passed and go S2;
S1: after power-up start to clear all counters/variables (flags), go S2;
S2: check if body or arm passing, (Yes) go S3, otherwise in S2;
S3: set counter=equivalent count of one cycle (one step passing) time (T1+T2) and start counting down, go S4;
The counter is used for timer purpose and covers the scenarios of a user standing on one and 2 steps.
S4: check if arm passing, (Yes) body data, go S5, otherwise body passing go S7;
S5: check if body passing starts, (Yes) go S6, otherwise in S5;
S6: check if body passed; (Yes) go S2, otherwise in S6;
S7: check if arm passing starts, (Yes) go S8, otherwise body passing goes S9;
S8: check both body and arm passed, (Yes) go S2, otherwise in S8;
S9: check if the counter (timer) runs out, (Yes) this is not-hold-handrail user and go S10, otherwise go S7;
S10: output (via NODE-RED GPIO block, or alternatively FPGA/CPLD 10) one or more signals to activate external circuit(s) to alert the not-hold-handrail user then go S2. The external circuits alert/remind, such as voice, visual light-up, holding handrail immediately for its own safety. The external technology is available and adaptable for the invention, but does not belong to the invention.
Following the linked tutorials can help/guarantee to function, since my prototypes function and are available upon request.
One version of a second embodiment of escalator-monitoring/operable device is best illustrated in
Attention is now directed towards an alternative position to install escalator-sensor 9 is illustrated in
The escalator-sensor is distance sensor or integrated with distance sensor and installed/mounted to a support surface of a vertical post attached to the ground or a wall bracket and focusing/sensing side of the stair step 2 and a gap between the stair steps. The escalator-sensor, generally, has resolution less than 0.5 meters, frequency response more than 24 Hz and sensing distance more than 0.5 meters. Adjust the position of the sensor if necessary to ensure sensing side of passing step/gap and get waveform similar to that illustrated in
V3, a constant number, refers to the nearest distance from the escalator-sensor to a passing-by step side in front sensing position illustrated in
V4, a constant number, refers to the farthest distance from the escalator-sensor to a passing-by step gap in front sensing position illustrated in
T3, a constant number, refers to the periodic cycle time from V3 to V4 as illustrated in
T4, a constant number, refers to the periodic cycle time from V4 to V3 as illustrated in
This embodiment's methods/algorithms/rules are similar but much simpler than those of first embodiment. For example, determine “running”, “stopped” and “Sudden acceleration or deceleration” can be implemented by detecting/comparing the escalator data with the known periodic cycle times and range values (T3, T4, V3, V4) as illustrated in
No need to determine escalator vs. body data, since there is no user/body interruption for this configuration as illustrated in
Directions can be detected by adding another sensor side by side and comparing their phase difference (quadrature) which linked to one of known directions. The detected quadrature phase change mean escalator direction change.
List Analyzing of the (2nd) Embodiment Methods/Algorithms/Rules
Pros and Cons of this (2nd) Embodiment
Pros:
immune to passenger passing;
ease the sensors' resolution/sensing distance specs, so more suitable ones to use;
more simple method/algorithm of detecting “running”, “stopped”, “Sudden acceleration or deceleration”
Cons:
need accessing to escalator underneath (truss) to install/maintain; need escalator-sensors installed above the escalator to assist for not-hold-handrail detection.
While the alternative embodiment illustrated in
Exemplary Methods of monitoring one or more escalators New and useful exemplary, including computer-implemented, methods of monitoring one or more escalators is disclosed herein. It is to be understood that the first and second embodiment escalator-monitoring/operable devices can be used in conjunction with the exemplary methods.
The exemplary method of monitoring one or more escalators using at least one escalator-monitoring/operable device and/or one or more non-transitory computer readable storage mediums storing program(s) being executed by the device(s) to perform, typically comprises:
acquiring data from the distance device(s)/sensor(s);
analyzing the data, including: classifying/flagging/storing/separating the data into escalator or user data, calculating/storing the escalator data's cycle range/times, sums of absolute delta consecutive escalator step heights ΣΔL, groups of consecutive user data;
identifying state/events, usage, users' heights, based on the analyzing; and alerting, notifying, receiving/replying, uploading, based on the identifying.
The identifying of the methods/algorithms/rules, including:
List of in-response-to operations of the methods, based on the identifying, including:
The analyzing of the methods, including:
An Exemplary Method of making escalator-monitoring/operable Devices A new and useful exemplary method of making embodiments of the escalator-monitoring/operable device is additionally disclosed herein. It is to be understood that the first and second embodiment of escalator-monitoring/operable device can be made with this exemplary method of making escalator-monitoring/operable devices.
The exemplary method of making an escalator-monitoring/operable device typically comprises:
Installing the escalator-sensor at the optimal locations decided by 3-dimension disclosed and the arm-sensor at locations decided by 3-dimension specified by an individual or an entity;
Next, when making an escalator-monitoring/operable device, better using threshold ranges/hysteresis with leeway/tolerance instead of absolute values, such as V1, V2, V3, V4, T1, T2, T3, T4, to implement the invention's detecting/comparing. This copes data fluctuations better. For example, comparing if equal to V2 (if =V2),
use if [>(V2−ΔV2_Min) and <(V2+ΔV2_Max)] instead if =V2,
ΔV2_Min refer to V2 unbalanced hysteresis's Minimum leeway/tolerance offset;
ΔV2_Max refer to V2 unbalanced hysteresis's Maximum leeway/tolerance offset;
Alternatively use ΔV2 to replace ΔV2_Min and ΔV2_Max for balanced hysteresis leeway/tolerance;
Further, validating or fine-tuning the optimal locations' periodic cycle times (T1, T2), cycle variation range (V1, V2) and their (allowable) tolerances on an installed final-use device, then to set/calibrate them in one or more programs if necessary.
It is to be appreciated that the method of making escalator-monitoring/operable devices is merely exemplary. Variations of this method can be used to make different embodiments of the escalator-monitoring device as would be apparent to one of ordinary skill given the benefit of this disclosure.
The various embodiments and variations thereof, illustrated in the accompanying figures and/or described above, are merely exemplary and are not meant to limit the scope of the invention. It is to be appreciated that numerous other variations of the invention have been contemplated, as would be obvious to one of ordinary skill in the art, given the benefit of this disclosure.
For example, in embodiments of distance sensors are used for an escalator-monitoring/operable device. Other type sensors, such as some of speed/velocity sensors, they actually integrate/incorporate one or more distance sensors to measure distance and derive speed/velocity. Sensors which integrate distance sensors can alternatively be used for the invention. Since both escalator sensor and arm-sensor can detect stair steps of the escalator, so can their data be used for identifying the escalator's state/event regardless their installation locations. The device/method can reliably identify the users regardless standing, walking on running or stopped escalator. The device/method can use only one sensor (escalator-sensor) when not-hold-handrail detection (arm-sensor) is not needed. It is to be further appreciated that various embodiments of the escalator-monitoring/operable device can comprise non-distance sensors which integrating distance sensors such as, but not limited to, speed/velocity sensors. Moreover, in some variations reduced number of body height groups is preferred to the actual body height.
In yet another alternative embodiment, the escalator-monitoring/operable device can comprise: a FPGA/CPLD and IoT computer.
All variations disclosed in this application are intended and contemplated to be within the spirit and scope of the invention.
