POWER CONSUMPTION

Abstract

To have information on power consumption of an elevator, escalator and/or a moving walkway, an apparatus-specific static power consumption model modelling power consumption and being parametrized with apparatus-specific parameter is used with a distance to travel, a time and a load determined from controller events to calculate and output a total power consumed.

Description

FIELD

The present invention relates to power consumption of an elevator or an escalator or a moving walkway.

BACKGROUND

The evolvement of networking between computers and measurement devices, especially different sensors, capable of communicating without user involvement, has enabled remote monitoring and remote metering, for example. A trend in remote metering is to measure individual sources. For example, in buildings power meters are installed to individual power consuming sources to measure their power consumption, thereby paving the way towards smart buildings. Elevators, escalators and moving walkways also play their part in the power consumption. However, power meters are rarely installed to them.

BRIEF DESCRIPTION

The scope of the invention is defined in the independent claims. Some embodiments are defined in the dependent claims.

According to an aspect there is provided a remote monitoring equipment for an apparatus, which is an elevator or an escalator or a moving walkway, the equipment comprising: a data storage comprising apparatus-specific static power consumption models, a static power consumption model modelling power consumption and being parametrized with apparatus-specific parameters; means for receiving controller events relating to the apparatus; means for determining from the controller events a distance to travel, a time and a load; means for calculating, using an apparatus-specific static power consumption model of the apparatus and the distance to travel, the time and the load, a total power consumed by the apparatus; and means for outputting the total power.

In an embodiment, the means for calculating are configured to calculate predictions of the total power and the means for outputting are configured to output the predictions of the total power.

In an embodiment, the equipment further comprises means for calculating energy consumption of the apparatus by integrating the total power over a time the energy consumption is to be determined and/or means for calculating a predicted energy consumption of the apparatus by integrating the predictions of the total power over a time for which the predictions are available.

In an embodiment, the equipment further comprises means for sending the total power and/or the predictions of the total power and/or the energy consumption and/or the predicted energy consumption to a building management system.

In an embodiment, the equipment further comprises means for detecting a peak or drop in the predictions and means for sending information on the peak or drop to a building management system for mitigating the change in the power consumption.

In an embodiment, the equipment further comprises means for storing to the data storage received controller events with time information.

In an embodiment, at least one of the apparatus-specific static power consumption models is a precalculated three dimensional matrix, the dimensions being a distance to travel, a load and a time.

In an embodiment, the apparatus-specific parameters include one or more of parameters from a group of parameters comprising a speed, an acceleration, a jerk, a travel distance between floors, a maximum travel distance, a nominal load, a roping, a rope type, a cable type, a motor resistance, a motor type, drive efficiency, and a drive type.

In an embodiment, the equipment further comprises at least one processor; and at least one memory including computer program code; the at least one memory and the computer program code being configured to, with the at least one processor, provide the means.

According to another aspect there is provided a computer implement method comprising: receiving controller events relating to an apparatus, which is an elevator or an escalator or a moving walkway; determining from the controller events a distance to travel, a time and a load; calculating, using an apparatus-specific static power consumption model of the apparatus, which models power consumption and has been parametrized with apparatus-specific parameters, and the distance to travel, the time and the load, a total power consumed by the apparatus; and outputting the total power.

In an embodiment, the method further comprises: calculating, using the apparatus-specific static power consumption model the distance to travel, the time and the load, predictions of the total power; and outputting the predictions of the total power.

In an embodiment, the method further comprises: calculating energy consumption by integrating the total power over a time the energy consumption is to be determined; and causing sending the energy consumption to a building management system.

In an embodiment, the method further comprises: calculating a predicted energy consumption of the apparatus by integrating the predictions of the total power over a time for which the predictions are available; and causing sending the energy consumption to the building management system.

In an embodiment, the method further comprises: detecting a peak or drop in the predictions; and causing sending information on the peak or drop to a building management system for mitigating the change in the power consumption.

In an embodiment, the method further comprises storing received controller events with time information.

According to a further aspect there is provided a computer program product comprising program instructions which, when the program is executed by a computing device, cause the computing device to carry out at least: determining, in receiving controller events relating to an apparatus, which is an elevator or an escalator or a moving walkway; from the controller events a distance to travel, a time and a load; calculating, using an apparatus-specific static power consumption model of the apparatus, which models power consumption and has been parametrized with apparatus-specific parameters, and the distance to travel, the time and the load, a total power consumed by the apparatus; and outputting the total power one.

According to another aspect there is provided a computer-readable storage medium storing one or more instructions which, when executed by one or more processors, cause an apparatus to carry out at least determining, in receiving controller events relating to an apparatus, which is an elevator or an escalator or a moving walkway; from the controller events a distance to travel, a time and a load; calculating, using an apparatus-specific static power consumption model of the apparatus, which models power consumption and has been parametrized with apparatus-specific parameters, and the distance to travel, the time and the load, a total power consumed by the apparatus; and outputting the total power one.

One or more examples of implementations are set forth in more detail in the accompanying drawings and the description below. Other features will be apparent from the description and drawings, and from the claims.

BRIEF DESCRIPTION OF DRAWINGS

In the following, example embodiments will be described in greater detail with reference to the attached drawings, in which

FIG. 1 illustrate exemplified remote monitoring system;

FIG. 2 illustrates an exemplified static power consumption model;

FIGS. 3 to 6 illustrate different example functionalities; and

FIG. 7 is a schematic block diagram.

DETAILED DESCRIPTION OF SOME EMBODIMENTS

The following embodiments are only presented as examples. Although the specification may refer to “an”, “one”, or “some” embodiment(s) and/or example(s) in several locations of the text, this does not necessarily mean that each reference is made to the same embodiment(s) or example(s), or that a particular feature only applies to a single embodiment and/or example. Single features of different embodiments and/or examples may also be combined to provide other embodiments and/or examples. Manners of device management and remote metering develop constantly and hence the used terms should be understood as not limiting. Further, although terms including ordinal numbers or alphabets, such as “first”, “second”, “A”, “B”, etc., may be used for describing various elements, the elements are not restricted by the terms. The terms are used merely for the purpose of distinguishing an element from other elements. For example, a first element could be termed a second element, and similarly, a second element could be also termed a first element without departing from the scope of the present disclosure. Consequently, all terms and expressions should be interpreted broadly, and they are intended to describe, not to restrict, the invention.

In the examples described below elevator is used as an example of any apparatus that is or has a frame fixedly mounted to a building and that may transport people and/or goods between two points in the building, and the examples cover any such apparatus. Examples of such apparatuses include an elevator, an escalator and a moving walkway.

FIG. 1 illustrates a highly simplified elevator remote monitoring system. The general devices, elements and functions of elevator systems, details of which also depend on the actual type of an elevator system, are known to those skilled in the art, so that a detailed description thereof is omitted herein. Concepts called cloud computing and/or virtualization may be used as well for remote monitoring. The virtualization may allow a single physical computing device to host one or more instances of virtual machines that appear and operate as independent computing devices, so that a single physical computing device can create, maintain, delete, or otherwise manage virtual machines in a dynamic manner. It is also possible that device operations will be distributed among a plurality of servers, nodes, devices or hosts. In cloud computing, network devices (devices belonging to a network), computing devices and/or storage devices provide shared resources. Some other technology advancements, such as Software-Defined Networking (SDN), may cause one or more of the functionalities described below to be migrated to any corresponding abstraction or apparatus or device.

The remote monitoring system 101 may comprise one or more monitoring equipment 110, with different interfaces (not shown separately in FIG. 1) towards controllers 121, a controller controlling one or more elevators in buildings 120 and towards other devices/systems, likes building management systems (BMS) 130, and one or more user interfaces providing monitor and manipulation possibilities remotely and/or on the site via user devices 113. The way (network technology used, protocols used etc.) how the monitoring equipment 110 communicates with the controllers 121 and with the other devices 130 bears no significance, any known or future technology/protocol may be used, and hence there is no need to describe it in more detail herein.

The monitoring equipment 110 comprises one or more devices 111 configured to run one or more applications to monitor and possibly manage elevators, using possibly information in a data storage 112, as is known in the art. To support elevator-specific power consumption estimation, the device 111 comprises a power calculator unit 111-1 and the data storage 112 stores one or more elevator-specific static power consumption models 112-1. There may be one model per elevator or there may be models per elevator, for example a model per a speed or speed range the elevator can move, and/or a model per a different acceleration of the elevator, just to list some non-limiting examples. Further, in case the elevator comprises several cars, and/or there is a group of elevators the same model for cars in one elevator and different models for different elevators in the group may be used. It should be appreciated that the power calculator unit 111-1, or part of its functionality described below, with corresponding elevator-specific one or more static power consumption models, may be integrated to a device comprising the elevator controller 121 and/or to the building management system 130.

The data storage 112 may store also other information, for example events 112-2 (controller events) received from a controller 121 with corresponding time information. The time information may be a time stamp. Naturally, the data storage 112 may store other information, not illustrated herein. The data story age 112 may be any kind of conventional or future data repository, including distributed and centralized storing of data, managed by any suitable management system forming part of the device management. An example of distributed storing includes a cloud-based storage in a cloud environment (which may be a public cloud, a community cloud, a private cloud, or a hybrid cloud, for example). Cloud storage services may be accessed through a co-located cloud computer service, a web service application programming interface (API) or by applications that utilize API, such as cloud desktop storage, a cloud storage gateway or Web-based content management systems. However, the implementation of the data storage, the manner how data is stored, retrieved and updated, and the location where the data are stored are irrelevant to the invention.

A static power consumption model 112-1 may be a power profile comprising pre-calculated values, an example without values being shown in FIG. 1, or a power model for calculating in real-time power consumption values, an example being shown in FIG. 2.

The power profile 112-1 illustrated in FIG. 1 is a 3-dimensional matrix, the dimensions being a distance to travel (D), load (Q) and time (t). A pre-calculated power consumption value 112-11 can be obtained (retrieved) using index values for the dimensions. In the illustrated example, each distance to travel, in number of floors, has 151 load-specific power sub-profiles which are 90 seconds long. In other words, in the illustrated example there is a sub-profile for each load percentage of a rated load. The same time index values and load index values can be used for various elevators, but the distance to travel index values depend on the building and the location of the elevator in the building. However, the number of load-specific power sub-profiles and/or their length. i.e. the load index values and time index values, may vary from power-profile 112-1 to power profile, and even within a power-profile between different distance to travel indexes.

The different values in the power profile have been pre-calculated using a static power consumption model, which has been parameterized using elevator-specific parameters. However, there is no need to use precalculated values but the elevator-specific static power consumption model may be used to obtain power consumption values. FIG. 2 illustrates an example of a static power consumption model.

Referring to FIG. 2, a static power consumption model 200 of an elevator may be composed of different power consumption units (parts), based on different power consuming parts (devices) of the elevator. A power consumption unit has a set of unit-specific static parameters and contributes to the total power consumption 270 of the elevator. In the illustrated example, the power consumption model 200 comprises a ride generator unit 210 with parameter set 1 for power consumption calculations, a hoisting unit 220 with parameter set 2 for power consumption calculations, a motor unit 230 with parameter set 3 for power consumption calculations, a drive unit 240 with parameter set 4 for power consumption calculations, a transformer unit 250 with parameter set 5 for power consumption calculations, and a unit 260 for other power consuming parts, such as lighting, fans, controller, elevator doors, etc. with parameter set 6 for power consumption calculations. It should be appreciated that any other division to units may be used, including no division.

The granularity of the parametrization using static parameters depends on available data and accuracy requirements. A non-limiting list of examples of static parameters usable in the parametrization include speed, acceleration, jerk, travel distance between floors, maximum travel distance, nominal load, roping, rope type, cable type, motor resistance, motor type (model), drive efficiency, drive type (model) etc. It should be appreciated that the amount of parameters used in the parametrization may be quite big. For a manufacturer of the elevator, the parameters are easily available, thanks to the data obtained during manufacturing process, whereas parametrizing an elevator manufactured by someone else may require on-site measurements. Nevertheless, it is possible to define parameterized static power consumption models also for elevators that have been in use many years.

Once the parametrization of the static power consumption model has been ended, the static power consumption model can be used in real-time to calculate the total power consumption, or to pre-calculate the values for the elevator-specific power profile by simulating different control events. In both cases the input 202 to the model is based on a controller event. The controller event may indicate a start floor, a stop floor, a load weighing measurement result, and/or a moving state. The moving state indicates an operating mode, example of which include accelerating, nominal speed, decelerating, releveling, and standing, the operating mode also indicating a door state, which may be opening doors, doors open, closing doors and doors closed. For escalators or moving walkways the control event may be escalator/walkway speed and passenger count. The inputted control event 202 passes through the units, each unit outputting 201-1, 201-2, 201-3, 201-4, 201-5, 201-6 its power consumption (which may be zero), the sum of which is then outputted as a total power consumption.

FIG. 3 is a flow chart illustrating an example functionality of the power calculator unit when the model illustrated in FIG. 2 is used.

Referring to FIG. 3, when a controller event of an elevator is received (step 301: yes), the received controller event with event time information indicating when the event happened is stored in step 302 temporarily. The stored information may be used to synchronize the outputted total power consumption with a real-time clock, for example.

A distance to travel, which may be called a trip, a load and a moving state is determined in step 303 based on the received controller event. For example, the distance to travel may be calculated based on a start floor and a stop floor, and if none is present, the distance to travel is zero. The load in the controller event may be used as such, or the load may be divided by the rated load to obtain percentage of the rated load and if there is no load, the previous load value of the elevator is used. The moving state is determined based on the operating mode in the controller event and if there is no change in the operating mode, the previous moving state of the elevator is used.

The determined distance to travel, load and moving state are then inputted in step 304 to a static power consumption model which is specific for the elevator, and the total power calculated by the static power consumption model is outputted in step 305, for example to be displayed on a screen and/or to be used as an input to the building management system. Then the process continues to step 301 monitor, whether a controller event of the elevator is received. If not (step 301: no), the same total power as in step 305 is outputted in step 306, and the process continues to step 301 to monitor, whether a controller event of the elevator is received. Hence, the outputted total power is a time series vector.

FIG. 4 is a flow chart illustrating an example functionality of the power calculator unit when the model illustrated in FIG. 1 is used with an elevator having one car. In the illustrated example only few control events are used, for the sake of clarity of explaining, and it is assumed that the car is standing at a floor denoted by K, and that after the car is moving towards a floor X, it may stop at floor R which is between floors K and X, if such a call is received and accepted by the controller. Further, in the illustrated example the elevator-specific static power consumption model is based on an average floor height for that specific elevator, and uses as the distance to travel the number of floors to travel. It should be appreciated that if there are uneven floor-to-floor heights and it is considered that use of the average height does not provide accurate enough predications, a set of static power consumption models taking into account the different floor-to-floor heights could be created and read based on values of FloorStop and FloorStart.

Referring to FIG. 4, the elevator (i.e. the car in the elevator) stands (in step 400) at a floor K, until a controller event indicating a call to a floor X is received (step 401: yes). In response to the controller event “call to the floor X”, time index t for the 3-D matrix is set in step 402 to be n, wherein n indicates a length of a prediction time. The value of n may be received as a user input or a preset value may be used. For example n could be 30 indicating that the prediction time is 30 seconds. If no prediction are outputted n is zero. Further, a distance to travel index D and a car load Q is determined in step 402.

The distance to travel index value D may be determined using the following algorithm:

D=FloorStop−FloorStart

If D<0:

• • D=|D|−1

Else:

• • D=D+Number of floors−2

wherein

FloorStop is in the example of FIG. 4 the floor X

FloorStart is in the example of FIG. 4 the floor K

For example, with a 16-floor building and with the above algorithm downward travels are in D index values 0 . . . 14, and upwards travels are in D index values 15 . . . 29

The car load Q may be determined using the following formula:

Q=Q _current −Q _min-load

or

Q=0, if Q_current−Q_min-load<0

wherein

Q_current=current car load reading

Q_min-load=calculated observed minimum value of the car load

By removing the calculated observed minimum value of the car load the fact that a large portion of the travels of the car occur with an empty, or near empty car, can be taken into account. Further, by using the calculated observed minimum value instead of the absolute minimum value, effect of anomalies and outliers is limited. The observed minimum value of the car may be calculated periodically, for example once a day, once a week, etc, or it may calculated each time the car load value Q is needed. The value may be calculated in numerous ways. For example, it may be a value at the threshold of the smallest percentile (1%) of past current car load readings of the last week/working days in the last week. In another example, a median value of 21 smallest past current car load readings of the last week/working days in the last week, could be used. It should be appreciated that the above are mere examples, and different ways can be used. Further, if there is not enough past car load readings to calculate the observed minimum value reliable, the previous value may used, and zero could be used as the initial value.

Number of floors indicates between how many floors the elevator may travel. Usually, but not necessarily, it is the same as the number of floors in the part of the building the elevator is. The number of floors may be a hardcoded parameter, or calculated from the number of time rows in the power profile. For example, the size of the power profile illustrated in FIG. 1 is [2×(Number of floors−1)×90, 151], wherefrom the Number of floors can be obtained by dividing the total number of time index rows in the power profile by 180 and adding to the result 1. Still a further possibility is to observe a maximum value of actual position and use average height of floors.

When the index values/value ranges to time t, distance to travel D, and load Q have been determined, values are obtained (retrieved) in step 403 from the power profile. In other words, using the distance to travel and the load, values with time indexes from zero to t value set in step 402 are obtained in step 403.

When a controller event indicating that the elevator started moving (step 404: yes) is received, latest n+1 values are outputted in step 405, and the value of t is increased by one in step 406. The it is checked in step 407, whether the value of t is bigger than the maximum value of index t (t-max) in the power profile. If not (step 407: no), then a next power consumption value is obtained in step 48 from the power profile using the value of t, and the distance to travel D and the load Q, the latter two being defined in step 402. Then it is checked in step 409 whether one second has lapsed after step 405 was performed. This is just to ensure that if the power consumption is outputted second by second, the outputting follows the time. Naturally the check can be adjusted according to the intended output rate, for example 30 seconds by 30 seconds, or minute by minute.

When the one second has lapsed (step 409: yes), the process outputs in step 504 the latest n+1 power consumption values (meaning that the oldest one is not any more outputted but the one obtained in step 408, or determined in step 410 is outputted).

If the value of t is bigger than the maximum value of index t (t-max) in the power profile (step 407: yes), then the power consumption value obtained using the maximum value of index t is used in step 410 as a next power consumption value and the process proceeds to step 409 to check whether the one second has lapsed.

In the meantime, while monitoring whether the one second has lapsed, it is also monitored in step 411 whether a controller event indicating that the elevator stops at floor X is received, or in step 412 whether a controller event indicating that the elevator stops at floor R is received.

If the control event indicates that the elevator has stopped at floor X (step 411: yes), the power consumption value obtained using the maximum value of index t (t-max) is outputted in step 413 every second (and the elevator is standing at floor X so the process is again at step 400, even though the floor is different). In another implementation, the process described in steps 405 to 410 is repeated. In other words, in the implementation the outputted power values are updated as if the car is moving. In a further implementation, for example if the car have energy saving modes for different standby modes, after T seconds from the stop, the outputted power value (newest outputted power value) could be changed to another value.

If the control event indicates that the elevator has stopped at floor R (step 412: yes), outputting values within time index range t-n to is stopped in step 415, a new distance to travel is determined, using floor R as the start floor, in step 415 and a new load may be determined in step 415. Then values are obtained (retrieved) in step 416 using time range t-n to t, the newly calculated distance to travel, and the newly calculated load Q. In this example, it is assumed, for the sake of clarity that t is still below the maximum value of the index t. If not, then value obtained using the maximum value of the index t is used for all values having t above the maximum value of the index t. Then the process returns to step 404 to when a controller event indicating that the elevator started moving (step 404: yes) is received, and the latest n+1 values are outputted in step 405, the latest n+1 values comprising the last outputted value in step 415.

Implementing the above example to other control events is a straightforward for a person skilled in the art.

It should be appreciated that the value of load Q may be kept as a constant during the car travel, determined in the beginning, since the model takes into account the effect of the shifting net mass, which is affected by the compensation rope, for example. Further, advancing the time variable t as described above, takes care of the syncing of the power demand versus the movement of the car, and hence there is no need to monitor control events indicating the position of the elevator in the shaft. In case the elevator comprises several cars, and/or there is a group of elevators, the outputted power consumption values are a sum of the several cars and/or the group.

As can be seen from the above examples, accurate enough estimations of actual power consumption are obtained using the elevator-specific static power consumption models, without installing separate power meters to different part of the elevator. The outputted power consumption values may be integrated over time to obtain energy consumption (as power P is time derivate of energy E, i.e. P=dE/dt).

A further advantage, compared to installed power meters measuring current power consumption, is that it is possible to obtain predictions of the power consumption with the static power consumption model. FIGS. 5 and 6 illustrate examples how the outputted predictions can be used. The functionality may be performed by the power calculator unit, or by another unit receiving outputs from the power calculator unit.

Referring to FIG. 5, a power consumption value for the current time and predictions of the power consumption value are received in step 501, and one or both of them are used in step 501 to calculate energy consumption of the apparatus by integrating the total power over a time the energy consumption is to be determined, using also past values, and/or to calculate predicted energy consumption of the apparatus by integrating the predictions of the total power over a time for which the predictions are available. Naturally any other time interval may be used as well. For example the time interval may contain a certain number of past power consumption values and a certain number of predicted power consumption values (not necessarily all available). Then sending the calculated information, or part of it, to the building management system (BMS) is caused in step 503, and the steps are repeated. Hence, the building management system have all information for managing energy consumption, for example. The information sent in step 503 may comprise the energy consumption and/or the predicted energy consumption. Further, the information sent in step 503 may comprise the total power and/or the predictions.

Referring to FIG. 6, a power consumption value for the current time and predictions of the power consumption value are received in step 601, and the evenness of the power consumption is determined in step 602 from the predictions. If the evenness does not indicate a power consumption peak or a drop in the power consumption (step 603: no), the process continues to step 601 to receive the power consumption values.

If the evenness indicates a power consumption peak or a drop in the power consumption (step 603: yes), sending information on the peak or on the drop to the building management system (BMS) is caused in step 604, where after the process continues to step 602 to receive the power consumption values.

The building management system can utilise the information on the peak or on the drop to control other power consumptions loads in the building in order to mitigate the effect of the power peaks or utilise the drops. Short peaks in the power demand of an elevator (elevator system) may be dozens of times as high as the average demand, and to mitigate these peaks the building automation system needs information in advance.

The steps, messages and related functions described above in FIGS. 2 to 6 are in no absolute chronological order, and some of the steps may be performed simultaneously or in an order differing from the given one. Other functions can also be executed between the steps/points or within the steps/points. Some of the steps/points or part of the steps/points can also be left out or replaced by a corresponding step or part of the step.

The techniques described herein may be implemented by various means so that an apparatus/equipment implementing one or more functions/operations described above with an embodiment/example, for example by means of any of FIGS. 1 to 6 and any combination thereof, comprises not only prior art means, but also means for implementing the one or more functions/operations of a corresponding functionality described with an embodiment, for example by means of any of FIGS. 1 to 6 and any combination thereof, and it may comprise separate means for each separate function/operation, or means may be configured to perform two or more functions/operations. For example, one or more of the means and/or a power calculator unit, or any corresponding unit, for one or more functions/operations described above may be software and/or software-hardware and/or hardware and/or firmware components (recorded indelibly on a medium such as read-only-memory or embodied in hard-wired computer circuitry) or combinations thereof. Software codes may be stored in any suitable, processor/computer-readable data storage medium(s) or memory unit(s) or article(s) of manufacture and executed by one or more processors/computers, hardware (one or more apparatuses), firmware (one or more apparatuses), software (one or more modules), or combinations thereof. For a firmware or software, implementation can be through modules (e.g., procedures, functions, and so on) that perform the functions described herein.

FIG. 7 is a simplified block diagram illustrating some units for an apparatus (device, equipment) 700 comprising the power calculator unit, or any corresponding unit or sub-units, or configured otherwise to perform at least some functionality described above, for example by means of any of FIGS. 1 to 6 and any combination thereof, or some of the functionalities if functionalities are distributed in the future. In the illustrated example, the apparatus 700 comprises one or more interface (IF) entities 701, such as one or more user interfaces, one or more processing entities 702 connected to various interface entities 701 and to one or more memories 704.

The one or more interface entities 701 are entities for receiving and transmitting information, such as communication interfaces comprising hardware and/or software for realizing communication connectivity according to one or more communication protocols, or for realizing data storing and fetching, or for providing user interaction via one or more user interfaces. The one or more user interfaces may be any kind of a user interface, for example a screen, a keypad, or an integrated display device or external display device.

A processing entity 702 is capable to perform calculations and configured to implement at least the power calculator unit, or any corresponding unit or sub-units, described herein, or at least part of functionalities/operations described above, for example by means of any of FIGS. 1 to 6 and any combination thereof, with corresponding algorithms 703 stored in the memory 704. The entity 702 may include one or more processors, controllers, control units, micro-controllers, etc. configurable to carry out embodiments/examples/implementations or operations described above, for example by means of any of FIGS. 1 to 6 and any combination thereof. Generally a processor is a central processing unit, but the processor may be an additional operation processor or a multicore processor or a microprocessor.

A memory 704 is usable for storing a computer program code required for the power calculator unit, or any corresponding unit or sub-units, or for one or more functionalities/operations described above, for example by means of any of FIGS. 1 to 6 and any combination thereof, i.e. the algorithms for implementing the functionality/operations described above by means of any of FIGS. 1 to 6 and any combination thereof. The memory 704 may also be usable for storing, at least temporarily other possible information, like the received controller events with corresponding time information, or one or more elevator-specific power consumption models.

As a summary, the power calculator unit or corresponding sub-units and/or algorithms for functions/operations described herein, for example by means of means of any of FIGS. 1 to 6 and any combination thereof, may be configured as a computer or a processor, or a microprocessor, such as a single-chip computer element, or as a chipset, or one or more logic gates including at least a memory for providing storage area used for arithmetic operation and an operation processor for executing the arithmetic operation. Each or some or one of the units/sub-units and/or algorithms for functions/operations described above, for example by means of means of any of FIGS. 1 to 6 and any combination thereof, may comprise one or more computer processors, application-specific integrated circuits (ASIC), digital signal processors (DSP), digital signal processing devices (DSPD), programmable logic devices (PLD), field-programmable gate arrays (FPGA), graphics processing units (GPU) and/or other hardware components that have been programmed and/or will be programmed by downloading computer program code (one or more algorithms) in such a way to carry out one or more functions of one or more embodiments/examples.

An embodiment provides a computer program embodied on any client-readable distribution/data storage medium or memory unit(s) or article(s) of manufacture, comprising program instructions executable by one or more processors/computers, which instructions, when loaded into an apparatus (device, equipment), constitute the power calculator unit, or any corresponding unit, or an entity providing corresponding functionality, or at least part of the corresponding functionality. Programs, also called program products, including software routines, program snippets constituting “program libraries”, applets and macros, can be stored in any medium, including non-transitory computer readable storage medium, and may be downloaded into an apparatus. In other words, each or some or one of the converters/units and/or the algorithms for one or more functions/operations described above, for example by means of any of FIGS. 1 to 6 and any combination thereof, may be an element that comprises one or more arithmetic logic units, a number of special registers and control circuits.

Even though the invention has been described above with reference to examples according to the accompanying drawings, it is clear that the invention is not restricted thereto but can be modified in several ways within the scope of the appended claims. Therefore, all words and expressions should be interpreted broadly and they are intended to illustrate, not to restrict, the embodiment. It will be obvious to a person skilled in the art that, as technology advances, the inventive concept can be implemented in various ways. Further, it is clear to a person skilled in the art that the described embodiments may, but are not required to, be combined with other embodiments in various ways.

Claims

1. A remote monitoring equipment for an apparatus, which is an elevator or an escalator or a moving walkway, the equipment comprising: a data storage comprising apparatus-specific static power consumption models, a static power consumption model modelling power consumption and being parametrized with apparatus-specific parameters;means for receiving controller events relating to the apparatus;means for determining from the controller events a distance to travel, a time and a load;means for calculating, using an apparatus-specific static power consumption model of the apparatus and the distance to travel, the time and the load, a total power consumed by the apparatus; andmeans for outputting the total power.

2. A remote monitoring equipment as claimed in claim 1, wherein the means for calculating are configured to calculate predictions of the total power and the means for outputting are configured to output the predictions of the total power.

3. A remote monitoring equipment as claimed in claim 1, wherein the equipment further comprises means for calculating energy consumption of the apparatus by integrating the total power over a time the energy consumption is to be determined and/or means for calculating a predicted energy consumption of the apparatus by integrating the predictions of the total power over a time for which the predictions are available.

4. A remote monitoring equipment as claimed in claim 1, wherein the equipment further comprises means for sending the total power and/or the predictions of the total power and/or the energy consumption and/or the predicted energy consumption to a building management system.

5. A remote monitoring equipment as claimed in claim 2, wherein the equipment further comprises means for detecting a peak or drop in the predictions and means for sending information on the peak or drop to a building management system for mitigating the change in the power consumption.

6. A remote monitoring equipment as claimed in claim 1, wherein the equipment further comprises means for storing to the data storage received controller events with time information.

7. A remote monitoring equipment as claimed in claim 1, wherein at least one of the apparatus-specific static power consumption models is a precalculated three dimensional matrix, the dimensions being a distance to travel, a load and a time.

8. A remote monitoring equipment as claimed in claim 1, wherein the apparatus-specific parameters include one or more of parameters from a group of parameters comprising a speed, an acceleration, a jerk, a travel distance between floors, a maximum travel distance, a nominal load, a roping, a rope type, a cable type, a motor resistance, a motor type, drive efficiency, and a drive type.

9. A remote monitoring equipment as claimed in claim 1, the remote monitoring equipment further comprising at least one processor; and at least one memory including computer program code; the at least one memory and the computer program code being configured to, with the at least one processor, provide the means.

10. A computer implement method comprising: receiving controller events relating to an apparatus, which is an elevator or an escalator or a moving walkway;determining from the controller events a distance to travel, a time and a load;calculating, using an apparatus-specific static power consumption model of the apparatus, which models power consumption and has been parametrized with apparatus-specific parameters, and the distance to travel, the time and the load, a total power consumed by the apparatus; andoutputting the total power.

11. A computer implement method as claimed in claim 10, further comprising: calculating, using the apparatus-specific static power consumption model the distance to travel, the time and the load, predictions of the total power; andoutputting the predictions of the total power.

12. A computer implemented method as claimed in claim 10, the method further comprising: calculating energy consumption by integrating the total power over a time the energy consumption is to be determined; andcausing sending the energy consumption to a building management system.

13. A computer implemented method as claimed in claim 11, the method further comprising: calculating a predicted energy consumption of the apparatus by integrating the predictions of the total power over a time for which the predictions are available; andcausing sending the energy consumption to the building management system.

14. A computer implemented method as claimed in claim 11, the method further comprising: detecting a peak or drop in the predictions; andcausing sending information on the peak or drop to a building management system for mitigating the change in the power consumption.

15. A computer implemented method as claimed in claim 10, further comprising storing received controller events with time information.

16. A computer program product comprising program instructions which, when the program is executed by a computing device, cause the computing device to carry out at least one of the methods as claimed in claim 10.

17. A non-transitory computer-readable storage medium storing one or more instructions which, when executed by one or more processors, cause an apparatus to carry out at least one of the methods as claimed in claim 10.

18. A remote monitoring equipment as claimed in claim 2, wherein the equipment further comprises means for calculating energy consumption of the apparatus by integrating the total power over a time the energy consumption is to be determined and/or means for calculating a predicted energy consumption of the apparatus by integrating the predictions of the total power over a time for which the predictions are available.

19. A remote monitoring equipment as claimed in claim 2, wherein the equipment further comprises means for sending the total power and/or the predictions of the total power and/or the energy consumption and/or the predicted energy consumption to a building management system.

20. A remote monitoring equipment as claimed in claim 3, wherein the equipment further comprises means for sending the total power and/or the predictions of the total power and/or the energy consumption and/or the predicted energy consumption to a building management system.