Patent Description:
Elevator control systems may consist of tens of control boards each having one or more processors and many sensors that can produce valuable information for Condition Based Maintenance (CBM). It is neither feasible nor valuable to send all the data processed in the system every <NUM> or the like, but some of the signals are valuable and provide good data for condition diagnosis and prognosis. Even by selecting the signals carefully it is not needed to see all the samples in second scale as typically the needed time for optimized maintenance is days/weeks.

In prior art, this technology is reflected by documents <CIT>, <CIT> and <CIT>. Document <CIT> for example shows a remote monitoring support system of this kind having a control board interconnected between a remote server computer and an elevator. To periodically monitor the operation of the elevator, the remote server computer rules instructions to the control board which then carries out said instructions. The control board in turn generates notification information each time it receives signals from the elevator components - and then each time, the control board transmits said information to the management server computer. Alternatively, the control board can decide to only transmit specific notification information.

It is therefore an object of the present invention to minimize data amount (=connectivity price) between the device and the server where fleet analytics is done. The object is solved by a method of claim <NUM> and a computer program product of claim <NUM>.

Further developments and advantageous embodiments are defined in the dependent claims.

The invention starts out from the idea that data amount could be minimized if the data is processed at the device.

Accordingly, an aspect of the invention is a method for diagnosis and/or maintenance of a transportation system, according to claim <NUM>.

In the aforementioned method, said control board may be implemented as a LON or drive node, and may communicate with the local control unit via LON or drive interfaces. Furthermore, said local control unit may communicate with the remote monitoring unit via SAG interfaces. The aforementioned protocols are widely used in elevator control. However, other protocols such as mobile (wireless) or wired other (PSTN, LAN) network protocols may be employed as needed or usual.

In the aforementioned method, the said maintenance information may be indicative of a certain kind and/or severity of failure or problem of the frequency converter. Other sources/targets than a frequency convertor are possible.

In the aforementioned method, the said established maintenance information may be transferred or made accessible to a remote maintenance center or a mobile service unit or the local control unit of the transportation device, depending on a kind and/or severity of failure or problem indicated by the maintenance information.

In the aforementioned method, motor current and motor voltage of an automatic door motor may be detected as said raw data, and a door friction may be generated as a performance information.

In the aforementioned method, said performance information may be buffered separately for each door on each floor of said transportation device.

In the aforementioned method, said statistics information may be calculated and buffered separately for each door on each floor of said transportation device.

In the aforementioned method, said transportation device may be selected from one of an elevator, an escalator, a moving walkway, a cablecar, a railway locomotive, a railcar, a roller coaster, a conveyor, a crane, a positioning unit, and combined systems of a plurality of single units of the same.

Another aspect of the invention is a computer-program according to claim <NUM>.

Other aspects, features and advantages of the invention will become apparent by the below description of exemplary embodiments alone or in cooperation with the appended drawings.

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

<FIG> is a schematic diagram of a diagnosis/maintenance system <NUM> or method <NUM> according to an exemplary embodiment of the invention. It will be noted that elements shown in <FIG> may be realized as physical instances of the diagnosis/maintenance system <NUM>, or steps of the diagnosis/maintenance method <NUM>, or both.

The system <NUM> or method <NUM> is for diagnosis/maintenance of an elevator <NUM>. There may be only one elevator in the system, but there may also be a multiplicity of elevators <NUM>. For distinguishing elevators <NUM> from each other, each elevator <NUM> is designated a unique number, herein exemplified as X1, X2,. In other words, there are n elevators <NUM> in the system, with n being <NUM>, <NUM>, or more.

A remote monitoring unit <NUM> is for monitoring each elevator <NUM> through diagnosis and prognosis algorithms which will be described later, and is in contact with a service unit <NUM>. Even if only one service unit <NUM> is shown, more than one service unit <NUM> may be present. A device link <NUM> is for communication between the remote monitoring unit <NUM> and the elevator(s) <NUM>, and a service link <NUM> is for communication between the remote monitoring unit <NUM> and the service unit(s) <NUM>.

Each elevator <NUM> comprises a local control unit <NUM>, a drive control board <NUM>, and a motor drive <NUM> controlled by the drive control board <NUM>, for moving an elevator car or cabin (not shown). A control link <NUM> is for communication between the local control unit <NUM> and the drive control board <NUM>, and a drive link <NUM> is for connecting the drive control board <NUM> with the motor drive <NUM>. The motor drive <NUM> may e.g. be a frequency converter converting three-phase mains voltage/current into three-phase motor voltage/current of a hoisting motor of the elevator <NUM>, under control of the drive control board <NUM>. Even if only one drive control board <NUM> and one motor drive <NUM> are 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 drives <NUM>, and each motor drive <NUM> is assigned to one drive control board <NUM>. However, one drive control board <NUM> may be responsible for one or more motor drives <NUM> of one or more elevator cars. Individual elevators may have other control boards also. These control boards may be connected to local control unit <NUM> via 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 link <NUM> is based on a mobile communications protocol, the device link <NUM> is based on SAG, wherein any other wireless or wired communication protocol is possible, the control link <NUM> is based on LON or device protocol, and the drive link <NUM> is 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 board <NUM> comprises a drive control <NUM> for executing MCU and DSP algorithms which per se are known in the art, for driving switches of the motor drive <NUM>, a KPI generation <NUM>, a CF generation <NUM>, a KPI sample limitation <NUM>, and an uplink interface <NUM> of the control link <NUM>.

There are many signals calculated in the motion control and torque control algorithms located in the drive control <NUM>. The drive control <NUM> therefore 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 control <NUM> are passed, as a plurality of raw data <NUM>, to the KPI generation <NUM> and CF generation <NUM>. The KPI generation <NUM> has algorithms which generate so-called "Key Performance Indicators" (KPI) <NUM> from the raw data <NUM>, and the CF generation <NUM> has algorithms which generate so-called "Condition files" (CF) <NUM> from the raw data <NUM>. A KPI <NUM> may have the following structure:.

A condition file <NUM> may have the following structure:.

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

The condition files <NUM> are directly passed to the uplink interface <NUM> to be communicated to the local control unit <NUM>, such as an elevator control unit. The KPIs <NUM> are passed to the KPI sample limitation <NUM> to generate a limited or selected KPI sample collection (KPI@Iid) <NUM> of the individual drive control board <NUM>. The selected KPI samples <NUM> are then passed to the uplink interface <NUM> to be communicated to the local control unit <NUM>.

The local control unit <NUM> has a downlink interface <NUM> of the control link <NUM>, an uplink interface <NUM> of the device link <NUM>, a KPI database <NUM>, a CF buffering <NUM>, a KPI sample buffering <NUM>, a KPI daily statistics calculation <NUM>, a KPI daily statistics buffering <NUM>, and a CF generation <NUM>. The local control unit <NUM> can produce KPIs also ("KPI generation algorithm").

The downlink interface <NUM> is for exchanging data with the drive control board <NUM>, via the control link <NUM>. The uplink interface <NUM> is for exchanging data with the remote monitoring unit <NUM>, via the device link <NUM>.

The KPI database <NUM> is for storing individual KPI samples <NUM> or KPI collections <NUM>. The KPI database <NUM> may include a data structure including structured data relating to KPI samples and/or statistics, a memory area provided at the local control unit <NUM> for storing such data structure, and/or a process performing a database management method for managing such data structure.

The CF buffering <NUM> is for buffering condition files <NUM> passed from the drive control board <NUM> and other condition files <NUM> generated at the local control unit <NUM> itself, in a condition file stack <NUM>, and passing the same to the uplink interface <NUM>.

The KPI sample buffering <NUM> is for buffering selected KPI samples <NUM> passed from the drive control board <NUM> in a KPI sample stack <NUM>, and passing the same to the uplink interface <NUM>.

The KPI daily statistics calculation <NUM> is for calculating daily statistics files <NUM> from the selected KPI samples <NUM> passed from the drive control board <NUM>, and passing the same to the KPI daily statistics buffering <NUM>. A KPI daily statistics file <NUM> may have the following structure:.

The KPI daily statistics buffering <NUM> is for buffering KPI daily statistics files <NUM> calculated in the KPI daily statistics calculation <NUM>, in a KPI daily statistics stack <NUM> and passing the same to the uplink interface <NUM>. The KPI daily statistics files <NUM> are 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 generation <NUM> is for generating further condition files <NUM> from raw data <NUM> handled within local control unit <NUM>. The generated condition files <NUM> are also passed to CF buffering <NUM> to be processed as described above.

The remote monitoring unit <NUM> has a downlink interface <NUM> of the device link <NUM>, a diagnosis and prognosis <NUM>, and an interface (not shown) of the service link <NUM>. The diagnosis and prognosis <NUM> receives selected KPI samples <NUM>, condition files <NUM> and KPI daily statistics files <NUM> from the downlink interface <NUM>, to be provided at device images <NUM> which are provided for each single elevator <NUM> identified by each one's respective unique number X1, X2,. The selected KPI samples <NUM> are gathered at the KPI daily statistics stack <NUM> and/or at the KPI sample stack <NUM>. The latest KPI samples <NUM> can be fetched without being stacked. Each device image <NUM> includes an events and statistics history <NUM>, a KPI history <NUM>, a KPI statistics history <NUM>, and a raw data history <NUM>. It is seen that also raw data <NUM> may be passed via the links <NUM>, <NUM> to the remote monitoring unit <NUM>, even if not shown in the drawing. The diagnosis and prognosis section <NUM> has diagnosis and prognosis algorithms which apply diagnosis and prognosis processes to each device image's <NUM> data for generating a service needs report <NUM> relating to an elevator <NUM> if the diagnosis and prognosis processes conclude that a service is needed at the respective elevator <NUM>. The service needs report <NUM> is then passed to the mobile service unit <NUM> via service link <NUM>. 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 unit <NUM> may comprise a service car <NUM> operated by a serviceman <NUM>, and comprises a communication device <NUM> such as a cellphone, car phone, smartphone, tablet, or the like. The service link <NUM> is established between the remote monitoring unit <NUM> and the communication device <NUM> of the service unit. If the service needs report <NUM> is received at the communication device <NUM>, an alert is given so that the serviceman <NUM> will take notice, read the service needs report <NUM>, and execute the service need at the elevator <NUM> the service needs report <NUM> directs to.

It will be noted that any measured/determined parameters related to drive control of a motor drive <NUM> of a hoisting motor (not shown) of the elevator <NUM> may be raw data <NUM>, and a wide variety of parameters may be derived therefrom as key performance indicator (KPI) sample <NUM>/<NUM> or condition file <NUM>. Accordingly, any KPI samples <NUM>/<NUM> and any condition file <NUM> may be further processed as described above. In other words, daily statistics <NUM> may be generated, history data <NUM>-<NUM> may be collected to provide an image of each elevator <NUM> in the system, and diagnosis and prognosis algorithms are applied, to generate a service need report <NUM> if a problem is predicted to likely occur soon.

It will be noted that no additional hardware is needed for these estimations but the condition files <NUM> and /or KPI samples <NUM>/<NUM> can be determined (estimated) using existing hardware. Already with existing software, several drive signals may be derived which may be useful as raw data <NUM>. The determined value(s) can be delivered to a data center (remote monitoring unit <NUM>) 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 unit <NUM> is included in a cloud computing architecture or other distributed architecture. , at least parts of diagnosis and prognosis <NUM> are distributed, e.g., to a data analysis platform and a maintenance unit located at different computers in a cloud. The KPI daily statistics data <NUM> are sent e.g. on a daily basis to the data analysis platform which in turn generates trend information. Trend information is 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 unit <NUM> in case maintenance can be executed by useful control signaling to the drive control <NUM> or others, or generates a service needs report <NUM> and passes it to service unit <NUM> as described above. In the present case, the service needs report <NUM> may contain useful information for the serviceman <NUM> regarding the location of the elevator <NUM> (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 device <NUM>, e.g. by providing a direct link to the KPI database <NUM> or device image <NUM>.

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) <NUM>.

<FIG> is a schematic diagram of a diagnosis/maintenance system <NUM> or method <NUM> according to an exemplary embodiment of the invention. It will further be noted that the diagnosis/maintenance system <NUM> or method <NUM> of this exemplary embodiment is a variation of the diagnosis/maintenance system <NUM> or diagnosis/maintenance method <NUM> of 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 in <FIG> may be realized as physical instances of the diagnosis/maintenance system, or steps of the diagnosis/maintenance method, or both. Contents of the device images <NUM> are omitted in this figure, for ease of illustration.

While the previous exemplary embodiment is focused on a drive control board <NUM> with drive control <NUM> for controlling a motor drive <NUM> of a hoisting motor (not shown), the control board <NUM> of the present exemplary embodiment is more general. , the control board <NUM> may concern any function of the elevator <NUM>.

This makes clear that any measured/determined parameters of any controlled function of the elevator <NUM> may be raw data <NUM>, and a wide variety of parameters may be derived therefrom as key performance indicator (KPI) sample <NUM>/<NUM> or condition file <NUM>. Accordingly, any KPI samples <NUM>/<NUM> and any condition file <NUM> may be further processed as described above. In other words, daily statistics <NUM> may be generated, history data <NUM>-<NUM> may be collected to provide an image of each elevator <NUM> in the system, and diagnosis and prognosis algorithms may be applied, to generate a service need report <NUM> if a problem is predicted to likely occur soon.

Furthermore, in this embodiment, the local control unit <NUM> additionally comprises a KPI generation <NUM> which is formed like the KPI generation <NUM> of the control board <NUM>. This makes clear that KPI samples <NUM>/<NUM>, just like condition files <NUM>, may be generated at any place within the elevator <NUM>, be it at the local control unit <NUM> or any of the many control boards <NUM>.

The KPI attributes in KPI database <NUM> may have the following form:.

<FIG> is a schematic diagram of a diagnosis/maintenance system <NUM> or method <NUM> according to an exemplary embodiment of the invention. It will further be noted that the diagnosis/maintenance system <NUM> or method <NUM> of this exemplary embodiment is a variation of the diagnosis/maintenance system <NUM> or diagnosis/maintenance method <NUM> of 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 in <FIG> may be realized as physical instances of the diagnosis/maintenance system, or steps of the diagnosis/maintenance method, or both. Contents of the device images <NUM> are 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 door <NUM> is operated by the "Door operator" which has an electrical motor <NUM> that moves the door panels in the car when the elevator <NUM> lands to a floor <NUM> and the door <NUM> is opened. Some (but not all) failure modes of the door <NUM> lead to an increase in the friction F of the door, as the door <NUM> is being moved. As the increased friction F can be extracted from the electrical signals (motor current, motor voltage) produced by the drive <NUM> controlling the motor <NUM> via door motor link <NUM>, which may be in the form of power cables, as raw data <NUM>, it is possible to calculate a KPI <NUM> called "friction (F)", e.g., a door friction "F@after door closed", then after KPI sample limitation <NUM> a KPI sample collection "F@every Iid" <NUM> is provided, and by using the framework, this KPI <NUM>/<NUM> is further processed at the elevator <NUM> (local control unit <NUM>) and the server (remote monitoring unit <NUM>). Here, if a service need is foreseen, a service needs report <NUM> may be generated which may e.g. have the content seen in <FIG>.

As the server algorithm <NUM> can 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 KPIs <NUM>/<NUM> can 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 KPI <NUM>/<NUM> are buffered for each floor <NUM> and door <NUM> in order to localize the fault correctly, as shown in <FIG>. Likewise, KPI daily statistics are calculated and buffered for each floor <NUM> and door <NUM>. The KPI database <NUM> may assume the form as seen in <FIG>.

For example, a metro station in India with two landings is taken. There are hundreds or thousands door friction estimate condition KPI samples <NUM> every day which are processed in the elevator <NUM> to five figures (minimum, maximum, average, standard deviation and sample count) every <NUM> hours and sent to the server <NUM> for fleet/device analytics. The Diagnostics Framework utilizes existing communication network in the elevator <NUM> and 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:.

In addition, the internal communication links in the elevator <NUM> (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 generation <NUM> for condition based maintenance purposes. This is shortly discussed in the following.

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 unit <NUM> via control link <NUM> utilizing 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 systems <NUM> under maintenance contract, sent to a cloud computing system <NUM> and analyzed. On the basis of the analysis, need for component replace is forecasted and corresponding maintenance actions <NUM> are 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.

Claim 1:
Method for diagnosis and/or maintenance of a transportation system in view of optimizing replacement and maintenance intervals so that full lifetime is used and no functional failures shall occur, said transportation system having at least one transportation device and a remote monitoring unit (<NUM>) being remote from said transportation device, said transportation device having a control board (<NUM>) for controlling and/or monitoring a function of said transportation device, and a local control unit (<NUM>) for controlling and/or monitoring said control board (<NUM>), said method comprising:
- detecting raw data (<NUM>) connected to said at least one function at said control board and/or said local control unit;
- generating condition information and/or performance information based on said raw data at said control board and/or said local control unit;
- calculating statistics information based on said condition information and/or performance information at said local control unit;
- buffering said condition information and/or performance information and/or statistics information at said local control unit (<NUM>);
- transmitting said condition information and/or performance information and/or statistics information to said remote monitoring unit (<NUM>), at predetermined and/or adaptive time intervals;
- processing said condition information and/or performance information and/or statistics information at said remote monitoring unit (<NUM>) as being included in a cloud computing architecture, for establishing a service need condition and to provide an image of the at least one transportation device in the system, wherein diagnosis and prognosis algorithms are applied to generate a service need report (<NUM>) if a problem is predicted to likely occur soon, wherein parts of diagnosis and prognosis (<NUM>) are distributed to a data analysis platform and a maintenance unit located at different computers in the cloud, wherein daily statistics data (<NUM>) are sent to the data analysis platform which in turn generates trend information to detect a decreasing or increasing trend and a maintenance action is triggered before failure of the transportation device or any part of it takes place, which would prevent transportation operation; and
- transmitting said service need condition selectively to the local control unit and/or a mobile service unit (<NUM>).