Patent Description:
Escalator service contracts may rely heavily upon maintenance performed at regularly scheduled intervals. Despite scheduled maintenance, unplanned faults occur, leading to system downtime. Mechanics must identify faults, often without information related to faulted component or location. This lack of information may increase an occurrence and duration of system downtimes. <CIT> discloses a method and device for monitoring a passenger transport system using a detection device and a digital double.

According to a first aspect of the present invention, there is provided an escalator system as claimed in claim <NUM>.

In some embodiments, one or more of the slave sensors determines one or more of a physical state of the escalator, an operational state of the escalator, and a location of the fault condition along the escalator, and includes the determination in the slave sensor data; or the master sensor determines one or more of a physical state of the escalator, an operational state of the escalator, and a location of the fault condition along the escalator, and includes the determination in the data.

In some embodiments, the master sensor transmits the data to the escalator call center via a cloud service, and the cloud service determines from the data one or more of a physical state of the escalator, an operational state of the escalator, and a location of the fault condition along the escalator.

In some embodiments, the slave sensors transmit, as slave sensor data, raw or filtered sensor data; and/or the master sensor transmits, as the data, a raw form of the slave sensor data.

In some embodiments, the slave sensors transmit filtered sensor data as the slave sensor data, wherein the filtered sensor data is filtered to only include sensor data above and/or below predetermined peaks.

In some embodiments, the plurality of state sensors include one or more of an accelerometer, a strain gage, a video camera, and a microphone.

In some embodiments, the master sensor is configured to communicate with the slave sensors over a first network that is a wireless network and communicate with the escalator call center over a second network that differs from the first network.

According to a second aspect of the present invention, there is provided a method as claimed in claim <NUM>.

In some embodiments, the method includes one or more of the slave sensors determining one or more of a physical state of the escalator, an operational state of the escalator, and a location of the fault condition along the escalator, and includes the determination in the slave sensor data; or the master sensor determining one or more of a physical state of the escalator, an operational state of the escalator, and a location of the fault condition along the escalator, and includes the determination in the data.

In some embodiments, the method includes the master sensor transmitting the data to the escalator call center via a cloud service, and the cloud service determining from the data one or more of a physical state of the escalator, an operational state of the escalator, and a location of the fault condition along the escalator.

In some embodiments, the method includes the slave sensors transmitting, as slave sensor data, raw or filtered sensor data; and/or the master sensor transmitting, as the data, a raw form of the slave sensor data.

In some embodiments, the method includes the slave sensors transmitting filtered sensor data as the slave sensor data, wherein the filtered sensor data is filtered to only include sensor data above and/or below predetermined peaks.

In some embodiments, the method includes the master sensor communicating with the slave sensors over a first network that is a wireless network and communicating with the escalator call center over a second network that differs from the first network.

In the following an exemplary embodiment of the invention is described with reference to the enclosed figures.

<FIG> shows a schematic side view of a people conveyor, in particular an escalator 1a, comprising a plurality of treads <NUM> (steps 13a) interconnected to form an endless tread band 12a extending in a longitudinal conveyance direction between a lower landing 21a and an upper landing 21b. For clarity, only some of the treads <NUM>, in particular treads <NUM> in the conveyance portion 16a, are depicted in <FIG>. Further, not all treads <NUM> are denoted with reference signs.

In an upper turnaround portion 17a next to the upper landing 21a and in a lower turnaround portion 24a next to the lower landing 20a, the endless tread band 12a passes from a conveyance portion 16a extending between the upper and lower landings 21b, 21a into a return portion 18a, and vice versa.

The upper turnaround portion 17a is a driving portion and comprises a tension member drive system 25a. The tension member drive system 25a comprises a motor driving a drive shaft 42a via a transmission element 26a, particularly a toothed belt, a belt or a chain. The drive shaft 42a supports a drive wheel 32a, e.g. a toothed belt drive sheave, a traction sheave or a sprocket.

The drive shaft 42a drivingly engages an endless tread drive tension member 15a. The endless tread drive tension member 15a may be a belt, particularly a toothed belt, or a chain. The endless tread drive tension member 15a is drivingly coupled to the treads <NUM> and thereby drives the treads <NUM> to travel along the endless path of the tread band 12a. The endless tread drive tension member 15a is endless and thus extends along a closed loop. The endless tread drive tension member 15a is in engagement with, and driven by, the drive wheel 32a supported by the drive shaft 42a.

The lower turnaround portion 24a comprises a turnaround element 36a, e.g. an idler wheel or an idler sprocket attached to a turnaround shaft <NUM>. The turnaround element 36a engages with the endless tread drive tension member 15a to guide the endless tread drive tension member 15a from the conveyance portion 16a to the return portion 18a.

In a tension portion 34a the endless tread drive tension member 15a engages a tension shaft 35a having a tension element, e.g. an idler sprocket or an idler wheel. The tension element is configured to adjust tension of the endless tread drive tension member 15a while traveling along its endless path, such that wear of the endless tread drive tension member 15a is reduced. For example, the tension portion 34a may be positioned in the return portion 18a.

In further embodiments, the tension portion 34a may be located in the upper and/or lower turnaround portions 17a, 24a. In such case, the upper/lower turnaround shaft may also provide the function of the tension shaft.

Alternatively, the turnaround portion 24a next to the lower landing 21a may be the driving portion.

The people conveyor 1a further comprises a brake 31a which is configured for braking movement of the endless tread band 12a. The brake 31a is depicted as a separate component of the tension member drive system 25a in <FIG>. The brake 31a, however, may be integrated with another component of the tension member drive system 25a. For example, the brake 31a may engage with the drive wheel 32a or the drive shaft 42a.

Balustrades 4a supporting moving handrails 6a extend parallel to the conveyance portion 16a. The balustrades 4a are each supported by a separate truss 39a. Only one of the balustrades 4a, and the trusses 39a are visible in the side view shown in <FIG>. The trusses 39a are connected to each other by one or more crossbeams <NUM> forming a connecting structure. The crossbeams <NUM> may comprise different profiles, for example, a rectangular, a triangular, or a circular profile. The crossbeams <NUM> are fixed to the trusses 39a by a detachable connection, such as by at least one bolt or screw, or by a fixed connection, such as by at least one weld. The crossbeams <NUM> are positioned under the endless tread band 12a and the endless tread drive tension member 15a. This allows easy removal of the endless tread drive tension member 15a during maintenance or repair, since the endless tread drive tension member 15a does not have to be opened.

Turning to <FIG>, the disclosed embodiments provide an escalator system <NUM> that is able to predict imminent faults and localize faults that occur, reducing maintenance times per fault and, for example, allowing a contractor to perform maintenance as needed.

The escalator system <NUM> includes a plurality of state sensors <NUM> on the escalator steps 13a of the escalator 1a that wirelessly communicate with each other to predict and localize imminent component failure. It is to be appreciated that the sensors <NUM> may be installed on every step, every other step, every third step, etc., that is, at any desired frequency. The state sensors <NUM> may include accelerometers, strain gages, video cameras, and microphones to record data. That is, the state sensors <NUM> are utilized to determine the physical and operational state of the escalator 1a.

The state sensors <NUM> of the escalator system <NUM> include a master sensor (or master pack) <NUM> and slave sensors (or slave sensor packs) 180a, 180b (the slave sensors are referred to generally as <NUM>). The slave sensors <NUM> are distributed on different ones of the escalator steps 13a1, 13a2 (the escalator steps are referred to generally as 13a). The master sensor <NUM> may (according to a non-claimed example) be located on one of the escalator steps 13a3 (as shown) or, according to an embodiment of the claimed invention, may be secured to a fixed location on or near the escalator 1a. The state sensors <NUM> may communicate among each other using a first network <NUM> that is a wireless network such as a personal area network (including but not limited to Bluetooth Wifi, Zigbee, Zwave) or similar networks.

The slave sensors <NUM> communicate with the master sensor <NUM>. The master sensor <NUM> is secured to a fixed location on or near the escalator. Communications between the master <NUM> and slave sensors <NUM> may be substantially constant or the master sensor <NUM> may communicate with individual ones of the slave sensors <NUM> that are within a predetermined distance of the master sensor <NUM>. The step-sensor pairings may be mapped, for example, from hardware addresses of the sensors. Thus, if a sensor senses an issue, the location of the issue may be readily determined.

The master sensor <NUM> may be configured for edge computing and include computer circuitry <NUM>, including memory <NUM> and a processor <NUM>. As shown in block 2B1 in <FIG>, the slave sensors (or slave nodes) <NUM> may measure data and communicate measured slave sensor data to the master sensor (or master node) <NUM>.

As shown in block 2B2, the master sensor <NUM> may receive the slave sensor data via the first <NUM>, processes the slave sensor data to obtain master sensor data and transmit the master sensor data to an escalator call center <NUM> via a second network <NUM>. The second network <NUM> may be a wireless network, such as cellular or satellite network. Alternatively, a landline connection may be utilized for at least a portion of the second network.

In addition, or as an alternate, the slave sensors <NUM> may also perform at least some on-board processing/analysis. For example, the slave sensors <NUM> may perform relatively basic tasks such as filtering sensor data and transmit high and/or low filtered data to the master sensor <NUM>. In some embodiments the slave sensors <NUM> may perform an analysis of failures based on the sensor data, e.g., utilizing edge computing.

That is, the master sensor <NUM> is capable of saving fault data, performing data analytics (such as stress/strain and statistical analytics) on sensor signals received from the slave sensors <NUM>. In addition, the master sensor data may, for example, identify the occurrence of a fault condition, include shut-down instructions, and include a service all request. In one embodiment, the master sensor <NUM> may transmit all of the master sensor data to a cloud service <NUM>. For simplicity, the cloud service will be referred to as the cloud. As shown in block 2B3, the escalator call center <NUM> may receive the master sensor data and dispatch service. The master sensor <NUM> is configured to initiate a service call to the escalator call center <NUM>, directly or through the cloud <NUM>, e.g., via the second network <NUM> which is a cellular network or similar network.

With the state sensors <NUM> networked with each other, faults may be identified and localized (e.g., a location may be pinpointed) by performing data analytics on the slave sensor data. Faults are inferred by the master sensor <NUM> using sensor latency, e.g., using differing response times of the state sensors. Further, the processed data may be used by the master sensor <NUM> to determine if there is an overloading type fault condition on the escalator 1a, and to initiate an urgent stop before actual damage to the escalator system <NUM> is accrued. Utilizing the state sensors <NUM>, the master sensor <NUM> may perform prognostics and health management, and condition based maintenance (CBM) on components.

Data analytics, including machine learning, may be performed on the master sensor <NUM> by using performance data from field or staged tests and measurements (empirically obtained) and simulations (analytically obtained) and their combination to infer a component state (e.g., component load paths, stress/strain states, and operational modes). The result is a health estimation for a greater number of components than may be instrumented, and/or a more thorough estimation on components utilizing less instrumentation.

In one embodiment, the empirically obtained data may be organized in look-up charts relating component loading, stress and strain. In one embodiment, the analytics may be based on, for example, a finite element analysis. The charts may be stored on, and analysis may be performed at, the master sensor <NUM>, in real time, upon receiving slave sensor data.

The disclosed embodiments may also be utilized to infer conditions among different escalators without having to instrument each of the escalators. For example, after a disturbance such as an earthquake, the instrumentation readings on the escalator 1a equipped with the state sensors <NUM> may be used to identify issues that may occur on each of the escalators in a same bank, building or geographic region.

Benefits of the disclosed embodiments include real-time prognostics and diagnostics of components, leveraging of sensor data and diagnostics to reduce regularly scheduled maintenance, reducing on-site mechanic time and failed component rates, the ability to identify at a localized level a failed component, and the ability for an escalator 1a to self-shutdown, by operation of the master sensor <NUM>, when an overloading type fault condition or other unacceptable condition occurs. Tracked data may be used to enhance future escalator designs for better performance/longer component life.

Turning to <FIG>, a flowchart shows a method of monitoring an escalator system <NUM>. As shown in block <NUM>, the method includes receiving, by the master sensor <NUM> of the state sensors <NUM>, slave sensor data from slave sensors <NUM> of the state sensors <NUM>. The slave sensor data may be raw or processed data. As indicated, the slave sensors <NUM> are secured to different ones of escalator steps 13a of the escalator 1a. The master sensor <NUM> is in a fixed location on or near the escalator 1a. As indicated, the state sensors <NUM> may include one or more of an accelerometer, a strain gage, a video camera, and a microphone.

As shown in block <NUM>, the method may also include transmitting, by the master sensor <NUM>, an alert to the escalator call center <NUM> upon detecting the occurrence of a fault condition from the slave sensor data. In one embodiment, the master sensor <NUM> may transmit raw data to the escalator call center <NUM>.

As shown in block <NUM>, the method may also include one or more of the slave sensors <NUM> determining one or more of a physical state of the escalator 1a, an operational state of the escalator 1a, and a location of a fault along the escalator 1a, and including the determination in the slave sensor data. In addition, or as an alternative, as shown in block <NUM>, the method may also include the master sensor <NUM> determining one or more of a physical state of the escalator 1a, an operational state of the escalator 1a, and a location of a fault along the escalator 1a, and including the determination in the data.

As shown in block <NUM>, the method may also include the master sensor <NUM> transiting the data to the escalator call center <NUM> via a cloud service <NUM>. As shown in block <NUM>, the method may include the cloud service <NUM> determining from the data one or more of a physical state of the escalator 1a, an operational state of the escalator 1a, and a location of a fault along the escalator 1a.

As shown in block <NUM>, the method may include the slave sensors <NUM> transmitting, as the slave sensor data, raw or filtered sensor data. As shown in block <NUM>, the method may include the master sensor <NUM> transmitting, as the data, a raw form of the slave sensor data that it received from the slave sensors <NUM>. As shown in block <NUM>, the method may include the slave sensors <NUM> transmitting filtered sensor data as the slave sensor data. In one embodiment, the filtered sensor data is filtered to only include sensor data above and/or below predetermined peaks, e.g., such as provided through hardware or software bandpass filtering.

As indicated, the master sensor <NUM> is secured to a fixed location on or near the escalator 1a. As shown in block <NUM>, the method may include the master sensor <NUM> communicating with individual ones of the slave sensors <NUM> that are within a predetermined distance of the master sensor <NUM>. As shown in block <NUM>, the method also includes determining, by the master sensor <NUM>, from sensor latency in transmissions from the slave sensors <NUM> the occurrence of the fault condition.

As shown in block <NUM>, the method may also include communicating, by the master sensor <NUM>, with the slave sensors over a first network <NUM> that is a wireless network. As shown in block <NUM>, the method may also include communicating, by the master sensor <NUM>, with the escalator call center <NUM> over a second network <NUM> that differs from the first network <NUM>. As indicated, the first network <NUM> may be a personal area network and the second network <NUM> may be a cellular network.

Claim 1:
An escalator system (<NUM>) comprising:
escalator steps (13a); and
a plurality of state sensors (<NUM>) including a master sensor (<NUM>) and slave sensors (<NUM>), wherein the master sensor (<NUM>) is secured to a fixed location on or near the escalator and communicates with individual ones of the slave sensors (<NUM>) that are within a predetermined distance of the master sensor (<NUM>), wherein the slave sensors (<NUM>) are secured to different ones of the escalator steps (13a), wherein the master sensor (<NUM>) is configured to:
receive slave sensor data from the slave sensors (<NUM>); and
characterized in that the master sensor (<NUM>) is further configured to:
transmit data to an escalator call center (<NUM>) upon detecting an occurrence of a fault condition from the slave sensor data; and
determine from sensor latency in transmissions from the slave sensors (<NUM>) the occurrence of the fault condition.