Patent ID: 12236731

DETAILED DESCRIPTION

Now, exemplary embodiments of the invention will be described in further detail.

FIG.1is a schematic diagram of a diagnosis/maintenance system100or method101according to an exemplary embodiment of the invention. It will be noted that elements shown inFIG.1may be realized as physical instances of the diagnosis/maintenance system100, or steps of the diagnosis/maintenance method101, or both.

The system100or method101is for diagnosis/maintenance of an elevator110. There may be only one elevator in the system, but there may also be a multiplicity of elevators110. For distinguishing elevators110from each other, each elevator110is designated a unique number, herein exemplified as X1, X2, . . . , Xn. In other words, there are n elevators110in the system, with n being 1, 2, or more.

A remote monitoring unit111is for monitoring each elevator110through diagnosis and prognosis algorithms which will be described later, and is in contact with a service unit112. Even if only one service unit112is shown, more than one service unit112may be present. A device link113is for communication between the remote monitoring unit111and the elevator(s)110, and a service link114is for communication between the remote monitoring unit111and the service unit(s)112.

Each elevator110comprises a local control unit120, a drive control board121, and a motor drive122controlled by the drive control board121, for moving an elevator car or cabin (not shown). A control link123is for communication between the local control unit120and the drive control board121, and a drive link124is for connecting the drive control board121with the motor drive122. The motor drive122may e.g. be a frequency converter converting three-phase mains voltage/current into three-phase motor voltage/current of a hoisting motor of the elevator110, under control of the drive control board121. Even if only one drive control board121and one motor drive122are shown, an elevator may have more than one cars, and a car may have one or more hoisting motors. So each car may be assigned one or more motor drives122, and each motor drive122is assigned to one drive control board121. However, one drive control board121may be responsible for one or more motor drives122of one or more elevator cars. Individual elevators may have other control boards also. These control boards may be connected to local control unit12via a common LON data bus, for example. These control boards may include car control board disposed on elevator car and landing control boards disposed on separate landings.

In this exemplary embodiment, the service link114is based on a mobile communications protocol, the device link113is based on SAG, wherein any other wireless or wired communication protocol is possible, the control link123is based on LON or device protocol, and the drive link124is based on a KDSC, which is a Kone-specific drive protocol to interface with commercial drives. Alternatively, the protocol could be made of or comprise control pulses if IGBT transistors of a motor drive are used. Generally, any protocol, particularly serial communication protocol, is possible. It will be noted that any other useful protocol may be used as needed.

The drive control board121comprises a drive control130for executing MCU and DSP algorithms which per se are known in the art, for driving switches of the motor drive122, a KPI generation132, a CF generation133, a KPI sample limitation134, and an uplink interface135of the control link123.

There are many signals calculated in the motion control and torque control algorithms located in the drive control130. The drive control130therefore does see and handle many control values as it is controlling the motion of the hoisting machine and these signals can be used to evaluate condition of many system components. Many of these values are calculated either in real-time or after each travel and thus there would be lots of data generated if the values should be transferred to a remote server for analysis and maintenance purposes. A diagnostics framework has been developed to reduce data sent to a server and this framework shall be extended to a drive software as well. This specification describes what data is generated in a box marked with circles I, II, III for condition-based maintenance (CBM) purposes.

The signals calculated detected or generated in the drive control130are passed, as a plurality of raw data140, to the KPI generation132and CF generation133. The KPI generation132has algorithms which generate so-called “Key Performance Indicators” (KPI)141from the raw data140, and the CF generation133has algorithms which generate so-called “Condition files” (CF)143from the raw data140. A KPI141may have the following structure:

<KPI Sample141>

1) timestamp2) sample

A condition file143may have the following structure:

<Condition File (CF)143>

header (timestamp, source)data1, data22.123, 134.3452.278, 127.780. . .

It will be noted that numerical values in the condition file143above have no particular meaning in the context of the present invention and are purely by example. The condition file143is condition information in the sense of the invention, and the KPI sample141/142is a performance information in the sense of the invention. Here, both KPIs and CFs can be used as condition and performance signals.

The condition files143are directly passed to the uplink interface135to be communicated to the local control unit120, such as an elevator control unit. The KPIs141are passed to the KPI sample limitation134to generate a limited or selected KPI sample collection (KPI@Iid)142of the individual drive control board121. The selected KPI samples142are then passed to the uplink interface135to be communicated to the local control unit120.

The local control unit120has a downlink interface150of the control link123, an uplink interface151of the device link113, a KPI database152, a CF buffering153, a KPI sample buffering154, a KPI daily statistics calculation155, a KPI daily statistics buffering156, and a CF generation157. The local control unit120can produce KPIs also (“KPI generation algorithm”).

The downlink interface150is for exchanging data with the drive control board121, via the control link123. The uplink interface151is for exchanging data with the remote monitoring unit111, via the device link113.

The KPI database152is for storing individual KPI samples141or KPI collections142. The KPI database152may include a data structure including structured data relating to KPI samples and/or statistics, a memory area provided at the local control unit120for storing such data structure, and/or a process performing a database management method for managing such data structure.

The CF buffering153is for buffering condition files143passed from the drive control board121and other condition files143generated at the local control unit120itself, in a condition file stack164, and passing the same to the uplink interface151.

The KPI sample buffering154is for buffering selected KPI samples142passed from the drive control board121in a KPI sample stack163, and passing the same to the uplink interface151.

The KPI daily statistics calculation155is for calculating daily statistics files160from the selected KPI samples142passed from the drive control board121, and passing the same to the KPI daily statistics buffering156. A KPI daily statistics file160may have the following structure:

<KPI Daily Statistics File>

1) timestamp2) minimum3) maximum4) average5) standard deviation6) amount of samples

The KPI daily statistics buffering156is for buffering KPI daily statistics files160calculated in the KPI daily statistics calculation155, in a KPI daily statistics stack161and passing the same to the uplink interface151. The KPI daily statistics files160are statistics information in the sense of the invention. It will be noted that also CF daily statistics files (not shown) may contribute to statistics information in the sense of the invention.

The CF generation157is for generating further condition files143from raw data140handled within local control unit120. The generated condition files143are also passed to CF buffering153to be processed as described above.

The remote monitoring unit111has a downlink interface170of the device link113, a diagnosis and prognosis172, and an interface (not shown) of the service link114. The diagnosis and prognosis172receives selected KPI samples142, condition files143and KPI daily statistics files160from the downlink interface170, to be provided at device images180which are provided for each single elevator110identified by each one's respective unique number X1, X2, . . . , Xn. The selected KPI samples142are gathered at the KPI daily statistics stack161and/or at the KPI sample stack163. The latest KPI samples142can be fetched without being stacked. Each device image180includes an events and statistics history181, a KPI history182, a KPI statistics history183, and a raw data history184. It is seen that also raw data140may be passed via the links123,113to the remote monitoring unit111, even if not shown in the drawing. The diagnosis and prognosis section172has diagnosis and prognosis algorithms which apply diagnosis and prognosis processes to each device image's180data for generating a service needs report173relating to an elevator110if the diagnosis and prognosis processes conclude that a service is needed at the respective elevator110. The service needs report173is then passed to the mobile service unit112via service link114. Also, service visits at elevator sites (maintenance modules) may be scheduled and work tasks to be performed during the service visits may be selected at least partly based on diagnosis and prognosis processes.

The service unit112may comprise a service car190operated by a serviceman191, and comprises a communication device192such as a cellphone, car phone, smartphone, tablet, or the like. The service link114is established between the remote monitoring unit111and the communication device192of the service unit. If the service needs report173is received at the communication device192, an alert is given so that the serviceman191will take notice, read the service needs report173, and execute the service need at the elevator110the service needs report173directs to.

It will be noted that any measured/determined parameters related to drive control of a motor drive122of a hoisting motor (not shown) of the elevator110may be raw data140, and a wide variety of parameters may be derived therefrom as key performance indicator (KPI) sample141/142or condition file143. Accordingly, any KPI samples141/142and any condition file143may be further processed as described above. In other words, daily statistics160may be generated, history data181-184may be collected to provide an image of each elevator110in the system, and diagnosis and prognosis algorithms may be applied, to generate a service need report173if a problem is predicted to likely occur soon.

It will be noted that no additional hardware is needed for these estimations but the condition files143and/or KPI samples141/142can be determined (estimated) using existing hardware. Already with existing software, several drive signals may be derived which may be useful as raw data140. The determined value(s) can be delivered to a data center (remote monitoring unit111) and used in a Condition Based (aka predictive) Maintenance (CBM) to optimize replacement and maintenance intervals so that full lifetime is used and no functional failures shall occur.

The remote monitoring unit111may be included in a cloud computing architecture or other distributed architecture. I.e., at least parts of diagnosis and prognosis172may be distributed, e.g., to a data analysis platform and a maintenance unit located at different computers in a cloud. The KPI daily statistics data160are sent e.g. on a daily basis to the data analysis platform which in turn generates trend information. Trend information may be generated such that a decreasing or increasing trend can be detected and a maintenance action can be triggered before failure of the elevator or any part of it takes place, which would prevent elevator operation. To this end, trend information may be sent to the maintenance unit for analyzation. If the maintenance unit detects that a maintenance action is needed, it generates either a maintenance instruction and passes it to the local control unit120in case maintenance can be executed by useful control signaling to the drive control130or others, or generates a service needs report173and passes it to service unit112as described above. In the present case, the service needs report173may contain useful information for the serviceman191regarding the location of the elevator110(X1, X2, . . . , Xn) and the kind and severity of the problem, optionally along with a service proposal or precise service instruction. Additional information on the data basis (related signals) may be made available on the telecommunication device192, e.g. by providing a direct link to the KPI database152or device image180.

In this manner, any parameter may be utilized for establishing a maintenance information indicating that a maintenance should be done on the transportation device (elevator)110.

FIG.2is a schematic diagram of a diagnosis/maintenance system200or method201according to an exemplary embodiment of the invention. It will further be noted that the diagnosis/maintenance system200or method201of this exemplary embodiment is a variation of the diagnosis/maintenance system100or diagnosis/maintenance method101of the previous exemplary embodiment. In the following, only differences or special options of this exemplary embodiment with respect to the previous exemplary embodiment are described in full while other features may be taken from the illustration and above description of the previous exemplary embodiment. In particular, any features shown and described in the context of the previous exemplary embodiment apply to this exemplary embodiment, and features shown and described in the context of this exemplary embodiment may be included in the previous exemplary embodiment. As above, elements shown inFIG.2may be realized as physical instances of the diagnosis/maintenance system, or steps of the diagnosis/maintenance method, or both. Contents of the device images180are omitted in this figure, for ease of illustration.

While the previous exemplary embodiment is focused on a drive control board121with drive control130for controlling a motor drive122of a hoisting motor (not shown), the control board121of the present exemplary embodiment is more general. I.e., the control board121may concern any function of the elevator110.

This makes clear that any measured/determined parameters of any controlled function of the elevator110may be raw data140, and a wide variety of parameters may be derived therefrom as key performance indicator (KPI) sample141/142or condition file143. Accordingly, any KPI samples141/142and any condition file143may be further processed as described above. In other words, daily statistics160may be generated, history data181-184may be collected to provide an image of each elevator110in the system, and diagnosis and prognosis algorithms may be applied, to generate a service need report173if a problem is predicted to likely occur soon.

Furthermore, in this embodiment, the local control unit120additionally comprises a KPI generation258which is formed like the KPI generation132of the control board121. This makes clear that KPI samples141/142, just like condition files143, may be generated at any place within the elevator110, be it at the local control unit120or any of the many control boards121.

The KPI attributes in KPI database152may have the following form:

<KPI Attributes/Database>

1sthandle1stKPI ID+type (KPI/CF)1stKPI sample/CF buffer size1stKPI daily statistics buffer size1stKPI sample limitation1stKPI source2ndhandle2ndKPI ID+type (KPI/CF)2ndKPI sample/CF buffer size2ndKPI daily statistics buffer size2ndKPI sample limitation2ndKPI sourceetc. . . .NULL=next unused handle

FIG.3is a schematic diagram of a diagnosis/maintenance system300or method301according to an exemplary embodiment of the invention. It will further be noted that the diagnosis/maintenance system300or method301of this exemplary embodiment is a variation of the diagnosis/maintenance system200or diagnosis/maintenance method201of the previous exemplary embodiment. In the following, only differences or special options of this exemplary embodiment with respect to the previous exemplary embodiment are described in full while other features may be taken from the illustration and above description of the previous exemplary embodiment. In particular, any features shown and described in the context of the previous exemplary embodiment apply to this exemplary embodiment, and features shown and described in the context of this exemplary embodiment may be included in the previous exemplary embodiment. As above, elements shown inFIG.3may be realized as physical instances of the diagnosis/maintenance system, or steps of the diagnosis/maintenance method, or both. Contents of the device images180are again omitted in this figure, for ease of illustration.

While the previous exemplary embodiment is more general, the present exemplary embodiment is focused on a specific example. A car door326is operated by the “Door operator” which has an electrical motor327that moves the door panels in the car when the elevator110lands to a floor325and the door326is opened. Some (but not all) failure modes of the door326lead to an increase in the friction F of the door, as the door326is being moved. As the increased friction F can be extracted from the electrical signals (motor current, motor voltage) produced by the drive322controlling the motor327via door motor link328, which may be in the form of power cables, as raw data140, it is possible to calculate a KPI141called “friction (F)”, e.g., a door friction “F@after door closed”, then after KPI sample limitation134a KPI sample collection “F@every Iid”142is provided, and by using the framework, this KPI141/142is further processed at the elevator110(local control unit120) and the server (remote monitoring unit111). Here, if a service need is foreseen, a service needs report173may be generated which may e.g. have the content seen inFIG.3.

As the server algorithm172can utilize the whole fleet (i.e. all the elevators X1, X2, . . . , Xn under service that has the framework available) information, more precise prediction models can be developed and elevator specific KPIs141/142can be used to generate a service need which prevents call-out or optimizes service needs. As there are typically many doors and floors in an elevator, the KPI141/142are buffered for each floor325and door326in order to localize the fault correctly, as shown inFIG.3. Likewise, KPI daily statistics are calculated and buffered for each floor325and door326. The KPI database152may assume the form as seen inFIG.3.

For example, a metro station in India with two landings is taken. There are hundreds or thousands door friction estimate condition KPI samples141every day which are processed in the elevator110to five figures (minimum, maximum, average, standard deviation and sample count) every 24 hours and sent to the server111for fleet/device analytics. The Diagnostics Framework utilizes existing communication network in the elevator110and can be thus implemented with the software only.

The Diagnostics Framework can be extended in the future by adding new sensor boards to the existing LON network. The Diagnostics Framework, which may be in the form of the elevator's internal communication network, includes also algorithms to collect samples from signals in the drive using a “datalogger”, which may be the CF. Similar framework can be built into escalators and automatic doors or any other kind of transportation device.

Advantageously, condition data can be produced in a control board in the elevator system utilizing existing communication networks, the data is “zipped” to reduce connectivity costs, and the framework can be extended in the future to support coming diagnostics solutions and new sensor boards.

In summary, the condition diagnostics framework consists of two parts, the elevator and the server side. The elevator side includes:KPI generation algorithms132,258that produce wanted KPI samples141/142from raw data140. These algorithms can be located either on the local control unit/board120(258) or on a LON node/drive control board121(132) connected to the local control unit120KPI daily statistics calculation155KPI buffering154to get recent KPI values, not just the daily statisticsCF generation133,157either on the local control unit/board120(258) or on a LON node/drive control board121(132) connected to the local control unit120, and CF buffering153in the local control unit/board120.KPI database152which holds KPI/CF related information

The server side includes:Diagnosis and prognosis algorithms172that generate service needs and reports173to the service technician191

In addition, the internal communication links in the elevator110(LON interface and drive interface) and the communication between the elevator and the server (SAG interface) are needed to get data to the server.

It will easily be seen that a similar monitoring system may be utilized for analysis of other data also. There are many signals calculated in the motion control and torque control algorithms located in the drive. A frequency converter's software e.g. sees many control values as it is controlling the motion of the hoisting machine and these signals can be used to evaluate a condition of many system components. Many of these values are calculated either in real-time or after each travel and thus there would be lots of data generated if the values should be transferred to the server for analysis purposes. A diagnostics framework has been developed to reduce data sent to a server and this framework is extended to drive software as well. Many data may be generated in KPI generation132for condition based maintenance purposes. This is shortly discussed in the following.

<Motor Temperature>

The temperature [° C.] of the hoisting motor may be low-pass filtered and handled as a condition KPI. This could be used to estimate the condition of the cooling system of the hoisting motor as the dirt reduces heat transfer capacity.

Drive software measures the temperature of hoisting motor when the motor is equipped with NTC temperature measurement sensors This value may be transferred to local control unit120via control link123utilizing diagnostics framework routine for KPI transfer after the drive has switched to non-running state (output power stage not active).

It is to be considered that a load profile may change over the time and hard to separate cooling system condition from normal variation.

It is seen from the above that considerable amount of data may be collected from elevators or other transportation systems110under maintenance contract, sent to a cloud computing system111and analyzed. On the basis of the analysis, need for component replace is forecasted and corresponding maintenance actions173are scheduled already before any component failures, which might stop elevator operation. So a more fluent and customer-friendly elevator diagnosis/maintenance user experience is achieved.

Even if the invention was described above based on elevators, as a matter of example, the invention is applicable to any transportation system using an electric motor for moving a moving part of the transportation system. The moving part may be a cabin of an elevator, a car of a roller coaster, a moving stairway or walkway, a locomotive of a railway, or others.

It is to be noted that the monitoring interval may be other than daily, i.e., may be shorter such as twice daily, hourly, or less such as even after every run, or may be longer such as twice weekly, weekly, monthly, or more.

A technical feature or several technical features which has/have been disclosed with respect to a single or several embodiments discussed herein before, e. g. the service car190inFIG.1may be present also in another embodiment e. g. when maintenance is carried out by using mechanical brake signals as a condition/performance information except it is/they are specified not to be present or it is impossible for it/them to be present for technical reasons.

LIST OF REFERENCE SIGNS

100Diagnosis/maintenance system101Diagnosis/maintenance method110Transportation device (e.g., elevator)111Remote monitoring unit (cloud computing system)112Service unit113Device link114Service link120Local control unit121Drive control board122Motor drive (frequency converter)123Control link124Drive link130Drive control (Existing MCU & DSP algorithms)132KPI generation133CF generation134KPI sample limitation135Uplink interface140Raw data141Key performance indicator (KPI)142KPI sample143Condition file (CF)150Downlink interface151Uplink interface152KPI database153CF buffering154KPI sample buffering155KPI daily statistics calculation156KPI daily statistics buffering157CF generation160KPI daily statistics file161KPI daily statistics stack163KPI sample stack164CF stack170Downlink interface171Communication link172Diagnosis & prognosis173Service needs report180Device images181Events & statistics history182KPI history183KPI statistics history184Raw data history190Service car191Serviceman192Communication device200Diagnosis/maintenance system201Diagnosis/maintenance method258KPI generation algorithm300Diagnosis/maintenance system301Diagnosis/maintenance method322Door drive324Door motor drive link325Floor326Door327Door motor328Door motor link339Downlink interfaceF Door frictionKPI Key performance indicatorX1, X2, Xn Elevators (transportation devices)