Albert T. So
Scientific Advisor of IAEE and Academic Secretary of IAEE Hong Kong, China Branch

Article published in Elevatori Magazine issue No. 4/2024.

Comparison of energy performance of different lift systems has been a hot topic for decades since the concern was paid attention to. In the past, building owners installed energy meters inside the machine rooms to record the total energy consumption of a lift hourly, daily, monthly or even yearly. Even today, energy auditing still relies on this approach of absolute recording.

However, lifts differ significantly from one another, in terms of speed, capacity, travel and, most important, traffic conditions etc. The question is how all lifts could be fairly compared based on their performances.

So far, standards related to the energy efficiency of lift systems are mainly based on the measured energy consumption of a reference cycle in order to estimate the annual consumption by computer simulation (e.g. BS EN ISO 25745-1 and 25745-2) in Europe, or based on the measured energy consumption during a full-loaded rated-speed up-journey in Hong Kong (e.g. Code of Practice for Energy Efficiency of Building Services Installation of Hong Kong, BEC in short).

These methods are basically addressing one journey or one round trip, but not for ongoing and continuous monitoring. In particular, the benefits offered by an intelligent supervisory control or dispatcher system are not effectively taken care of in these standards, though a comprehensive computer simulation required by ISO 25745 may reflect something there.

The BEPI (benchmarking energy performance indicator) was first developed in 2004 (So A., Cheng G., Suen W. e Leung A., 2005, ʻElevator performance evaluation in two numbersʼ, Elevator World Vol. LIII, No. 1, January, pp. 102-105). Throughout the past two decades, simulations and experiments have been repeatedly conducted to show that this BEPI is effective in cross comparing the efficiency of different lift systems, irrespective of the travel, type of drive, rated speed and capacity etc.

And a pilot study was carried out to show how this concept could be implemented on an existing lift (So A., Lam K., Kong C., Chan J. e Wong J., 2022, ʻDevelopment of a benchmarking energy performance indicator (BEPI) monitor for existing traction lift systemsʼ, Energy & Buildings, doi.org/10.1016/j.enbuild.2022.112220).

The concept had been included as an emerging good engineering practice for normalization and monitoring of lift energy consumption in the Technical Guidelines of the BEC in the 2012, 2015 and 2018 editions. The basic definition of this BEPI, called <J/kg-m> measured in J/kg.m, is rather straight forward, resembling the MPG (miles per gallon) in the automobile industry and the COP (coefficient of performance) in the HVAC (Heating, Ventilation and Air Conditioning).

To evaluate this BEPI, four measurements are made instantaneously and continuously during daily operation:
i) energy consumed, in Joules, over a fixed and defined period of time, T, called the time window, say T = 7200 s or 2 hr long (the actual duration is flexible but once determined, it must be permanently fixed);
ii) mass of the in-car load, in kg, at any time within the time window;
iii) position of the car, say in metres above the pit, along the hoistway at any time within the time window (this is to measure the actual distance traveled by the car during a brake-tobrake-journey);
iv) the status of the brake for marking the commencement and end of a brake-to-brakejourney (BTBJ).

A BTBJ starts at the moment when the machine brake is released and ends at the moment when it is applied again. Within the time window, there are n + 1 number of BTBJs as shown in Figure 1, n varying between time windows. Any BTBJ falling on the border of a time window also belongs to that particular time window. Then, the BEPI of the kth time window is calculated by the following equation, bearing in mind that n varies with k.

ET(k) is the total energy consumed, in Joules, over the whole kth time window of T s long; wi(k) is the mass of in-car load, in kg, during the ith BTBJ within the kth time window; di(k) is the distance traveled by the car, in m, during the ith BTBJ within the kth time window, irrespective of the direction of travel. The time window is moving with an incremental interval, ΔT, say 15 minutes long (also flexible but fixed after being determined), as shown in Figure 1.

Only one value of BEPI represents the whole time window, usually at the middle of it, e.g. the one for time window from 9 am to 11 am is fixed at 10 am for that window. When the traffic is extremely low, within a time window, say in the midnight, the BEPI may get a very high value, which is misleading. A rule of thumb is to discard such BEPI of a particular time window when the ET(k) is lower than a threshold, say 1 kWh etc.

Such threshold could be the typical energy consumed by the lift which only performs one BTBJ within the whole time window.

Fig. 1 – Application of brake-to-brake-journeys (BTBJs).

As seen from the definition, the concept of BEPI is not only applicable to a single lift. It can also be extended to a bank of them; all lifts contribute their own BTBJs to the same time window and ET(k) is the total energy consumption of the whole system within that window. As revealed by the definition, an energy efficient motor drive could lower the ET(k) while an intelligent dispatcher could increase the product, wi(k)di(k), so that more passengers can be handled in one long journey. Both conditions lead to a lower value of the BEPI, the lower the better. By computer simulation (So A., Chan R., Kaczmarczyk S., 2018, ʻComputer simulation aided study of a real-time energy benchmarking parameter for lift systems under different traffic control schemesʼ, Transportation Systems in Buildings, Vol. 2, No. 1, doi.org/10.14234/tsib.v2i1.141) and limited experimental results in the past, it seems that a maximum value of 50 J/kg.m of either a daily or 5-working day weekly BEPI may indicate an energy efficient lift system, the lower the better.

When this concept is implemented in more operating systems and the database is getting bigger and bigger, this threshold value will be revisited.