Richard Peters, Jim Nickerson

Peters Research Ltd

This paper was presented at The 10th Symposium on Lift & Escalator Technology (CIBSE Lifts Group, The University of Northampton and LEIA) (2019).  This web version © Peters Research Ltd 2019.

Keywords: IoT, monitoring, management, protocols, interface

Abstract. This paper addresses the challenges of developing a Lift and Escalator Management (LEM) System for owners and property management companies that operate multiple sites with lift and escalator equipment from multiple vendors. The requirements of people managing lifts and escalators are different to those supplying and maintaining the equipment. Sometimes this can create conflicts of interest. With the absence of a popular open standard, extracting information from modern lift and escalator controllers can be complex. A solution proposed accepts data over RS232, RS485, CAN, Ethernet and volt-free. Once an interface is in place, data needs to be transferred securely over the internet. For reliability, a wired internet connection is preferred, although mobile broadband is possible where there is coverage. Wired connections over secure company networks require special solutions to minimise blocking of data by firewalls. Users now expect a modern interface working on any web browser on computers, tablets and phones. The volume of data collected is enormous, requiring management and analysis to provide useful user feedback. Any equipment installed on site needs to be maintenance free to avoid excessive ongoing costs.

1 Introduction

The authors’ research in lift and escalator monitoring (LEM) originally arose from the need to verify the operation of lift dispatcher design, and for traffic research to support traffic analysis and simulation.  

Lift dispatchers, even if designed with simulation, need to be verified in the real-world using monitoring data.  Simulation passengers behave as they are told, and simulated lifts do not break down; the real world is different so new dispatchers need scrutiny when they are first put into service.  Smith  & Peters [1] discuss logging every destination call and lift movement, re-playing every lift and passenger movement in simulation software so that performance parameters such as time to destination can be compared with simulated results for the same traffic profile. Some of the things learnt from this work, completed as part of a dispatcher verification process, were that:

1. company IT networks are increasingly secure and opening ports to communicating with a server over the internet for off-site processing of the data is seen as a risk
2. lift maintenance companies and their personnel, quite reasonably, are nervous about the client having such detailed information about their performance in keeping the lifts operating and responding quickly to problems
3. lifts can incorrectly report that they are in service when they are not.

Another LEM application is for traffic research.  Researchers have proposed a range of methods  for extrapolating passenger demand, even with collective control, which could be applied if LEM was ubiquitous and data was shared [2] [3] [4]. It is not, and consequently traffic design guidance including CIBSE Guide D [5] still bases many design recommendations on traffic data which has had to be collected manually.  To improve traffic design further, more traffic data, collected automatically, needs to be available.  

Most major lift suppliers now offer remote monitoring systems.  They are ideal if you have lifts from just company X and are happy with the service from company X.  Data available is typically presented in plots which is of minimal value to researchers who need a log of every event (lift movement, door operation, etc.).  They are less ideal when lift maintenance companies are not performing as they are effectively writing their own reports.  Finally, where companies manage lifts in different buildings with a range of equipment from multiple suppliers, they need a LEM system which can monitor their whole estate.

This is the context in which the authors began to develop a LEM solution. The initial market sector chosen was building owners and property management companies that operate multiple sites with lift and escalator equipment from multiple vendors.  This paper provides an overview of the authors’ experience of working on current projects in this sector, interfacing with most of the major lift manufacturers and a wide range of independents.

2 Client requirements

A manufacturer’s monitoring system could potentially report the part number of a failed component, and perhaps even order a replacement.  Someone managing an estate has different requirements, e.g.

1. to be messaged if a lift goes out of service, or goes into a special mode, e.g. car top control
2. to be able to see if the lifts are in use (floor position and door operation)
3. to be able to respond to a report from the public or staff that a lift is out of service remotely by inserting a call to see if the lift moves
4. to have historical data, e.g. what % of the year has the lift been in service, the number of lifts movements, etc.

Of course, much more data could be collected.  But this basic information, in most instances, is enough to manage an estate.  

Other requirements have included the monitoring of escalators, and outputs to third party systems to trigger a security control room response.

3 Talking to lifts and escalators

The ISO Open System Interconnection (OSI) model is a useful paradigm for assessing different protocols which are divided into layers.  It has an abstract model of networking (seven-layered model) and set of specific protocols. More practically, Transmission Control Protocol/Internet Protocol (TCP/IP) is a suite of communication protocols to interconnect network devices on private networks and the internet.  Some vendors now offer a TCP/IP connection which addresses the making a connection, but the applications on either side of the ethernet cable still need to know how to talk to each other.

CIBSE Guide D [6] discusses initiatives from supporters of the philosophy of open architecture and interoperability.  There are many competing “standards” including BACnet, LonWorks, Modbus, KNX and CANopen.  In reality every supplier has a different approach and even if they use the same communications standard, the implementation is different.  

To address the range of interface possibilities a custom LEM interface board was developed which would accept all the widely used communication formats. The board has Ethernet, USB, two CAN channels, five RS 485, plus one RS 232 or RS 485 channel, see Figure 1. An SD card is used to store information.  Because this is a low powered board without moving parts, it can be expected to run for 20+ years without maintenance; at the time of writing there have been no in-service board failures since the original installation in 2014.

With the hardware in place, the biggest challenge is protocols.  Quite reasonably, lift companies prefer to sell their own monitoring solutions, so are reluctant to share their protocols unless agreed as part of the contract specification and protected by non-disclosure agreements. A number of confidentiality agreements have been signed in order to gain access to proprietary protocols.  These have generally been obtained when specific clauses for the monitoring system have been included in a new lift or modernisation specification.  With the right interface, all the lifts and escalators in a major development can be connected with a single interface board.

Upgrading an existing lift controller to add a LEM interface is possible, but typically more expensive to achieve; a recent quotation to add the inputs and outputs necessary to a controller was almost two thousand pounds per lift.  This assumes discrete (volt-free) inputs, which then have to be converted into a digital format before being received by the LEM interface board, see Figure 2.  Further custom interface boards are being developed to reduce the cost of accepting discrete inputs.

Figure 1 LEM interface board

Figure 2 LEM board with discrete inputs

A more cost-effective approach for existing (and sometimes new) installations is to interface with an existing indicator network already connected to the controller.  To this end, LEM interfaces with two populator indicator suppliers [7] [8] have been developed, see Figure 3.  This opens the possibility of a low-cost interface to a vast array of lift controllers where non-proprietary indicators have already been installed.  Not every preferred input and output is available via an indicator network, e.g. the lift position and availability status would normally be reported to the indicator, but it would not be known if the lift was on car top control or had broken down.  The LEM board communicates directly with the indicator network board [7] [8] using RS485.

Figure 3 Indicator network interfaces

It is also practical to implement connection free interfaces using an accelerometer to determine floor position [9].  Lack of movement could be used to infer a lift is out of service for maintenance or breakdown.

4 Central monitoring and control

Historically, lift and escalator monitoring systems provided by manufacturers have had dedicated local networks.  Some systems have provided remote access, see Figure 4.  

The trend from local monitoring servers to cloud based services in Building Automation Systems is also reflected in lift and escalator monitoring systems systems.  With a cloud based system, no equipment other than the interface board is needed on site,  In the system discussed in this paper the LEM board communicates directly to the server which reports via web pages, see Figure 5.

To address security issues discussed in section 1(i), the LEM board talks to a server only using Hyper Text Transfer Protocol Secure (HTTPS), which is the protocol used by a web browser.  This avoids the need to configure firewalls and open specific ports; if the internet connection provided can view a web page, it can talk to the LEM board.

When connected via Ethernet locally, the LEM board displays an internal web page for an engineer who can make changes in configuration and review current status, see Figure 6.  The board software may be updated from a local PC via Ethernet or from a web server via remote control, allowing for offsite software development and debugging. Remote download of software updates has been a major benefit; the alternative is debugging software interfaces in lift motor rooms and escalator pits, often out of hours in order to minimise the disruption to building operations.

 Figure 4 Traditional LEM schematic using a dedicated network

Figure 5 Cloud based LEM schematic

Figure 6 Internal display for LEM board

The raw communication messages with each board can be viewed on the server application, see Figure 7.

Figure 7 Messages from a LEM board displayed on server

User displays on phones, tablets, laptops and other internet enabled devices are presented in animated graphical form, see Figure 8.  The green N indicates normal operation.  The lift position and door states are shown with the current floor mnemonic overwritten on the lift graphic.  The green and red arrows allow terminal floor buttons to be selected on a touch screen device, or with a mouse. A door re-open button allows the doors to be cycled. 

Figure 8 Animated presentation of lift and escalator status

Multiple groups of lifts and escalators are brought together on a static display with colour changes to indicate if a lift or escalator is not in normal service, see Figure 9.

Figure 9 Cloud based LEM schematic

Alerts are programmable so that any change of state, e.g. normal to out of service or inspection service can trigger an alert email.

5 Conclusion

A frustrated engineer in 1995 [10] presented a paper at a CIBSE Open Forum Meeting on Remote Monitoring.  Why was it necessary to have three pieces of proprietary software to dial up three different manufacturers’ lift systems?  Why would the lift industry not adopt a common protocol so that there could be integrated LEM systems for the benefit of their clients?  

Almost a quarter of a century later, it is still challenging to collect data from multiple sites with lift and escalator equipment from multiple vendors and amalgamate the results to present everything on a signal platform.  But it is possible.  Adoption of standard or open communications protocols is not a popular cause within the lift and escalator industry.  Understandably, many lift manufacturers are wary of standard protocols as apart from commercial considerations, the integrity of systems may fall outside their control.  But it does seem an awful waste of the industry’s time and clients’ money to have so many different communication methods and proprietary protocols.  The authors have invested heavily in TCP/IP communication in the vertical transportation domain and are open to cooperation with others who share the goal of open communications protocols.

Although discrete (volt-free relay) interfaces are ubiquitous and relatively simple to implement, they rely on moving parts and connections that can come loose.  With a large building, there could be 1000s of relays which could be replaced by a single digital connection linked to a single LEM board.

The indicator interface route does provide a low-cost route to implementation. Not all the inputs/outputs required by clients managing an estate are available, but with some basic artificial intelligence, some issues can be inferred, e.g. breakdown or a maintenance mode when a lift is not moving regularly at times when it is normally, even though the rest of the lift group is.

Likewise, accelerometers have been demonstrated to be an effective connection diagnostic tool and can be installed without direct connection to the controller.  Again, not all the inputs/outputs required by clients managing an estate are available, but the cost benefit is such that it is a solution worth considering.  Connecting the accelerometer to the internet is possible, but a retrofit is likely to require use of a wireless connection.

In all cases, to fit and forget, a wire is always more reliable than wireless.  Although mobile broadband and wireless connections are available, it is wise to extend the building ethernet network to every lift motor room, escalator pit and lift cab when specifying a new job or refurbishment.

Although the LEM graphical displays are attractive to watch and detailed event logs are of interest to researchers, the main value to clients managing an estate is knowing immediately that a lift or escalator has broken down.  In a shopping centre or transport terminal, escalators breaking down are a hazard and can take a considerable time to be reported to maintenance staff.  In an office building, during traffic surveys it has become apparent that lifts are regularly out of service and no-one knows there is a problem.

Lift maintenance companies and personnel are understandably wary of third-party cloud-based monitoring systems.  However, in a world where devices from different vendors are increasing being connected to the internet and each other, the application of this technology is inevitable for the lift and escalator industry.  LEM will highlight companies and personnel that deliver a good service. Recognising this can only help support a rise in standards.

REFERENCES

1. R. Smith and R. Peters, “Analysis of Elevator Performance and Passenger Demand with Destination Control,” in Elevator Technology 17, Proceedings of ELEVCON, Thessaloniki, 2008. 
2. R. Peters, P. Mehta and J. Haddon, “Lift Passenger Traffic Patterns: Applications, Current Knowledge and Measurement,” in Elevator Technology 7, Proceedings of ELEVCON, Barcelona, 1996. 
3. A.-S. L, “New Concepts in Lift Traffic Analysis: The Inverse S-P (I-S-P) Method,” in Elevator Technology 4, Proceedings ELEVCON, Amsterdam, 1992. 
4. R. Basagoiti, M. Beamurgia, . R. Peters and S. Kaczmarczyk, “Passenger Flow Pattern Learning Based on Trip Counting in Elevator Systems Combined with Real-Time Information,” in Proceedings of The 3rd Symposium on Lift & Escalator Technology, Northampton, 2013. 
5. CIBSE, “CIBSE Guide D: 2015, Chapter 3 and 4,” London, Chartered Institution of Building Service Engineers, 2015. 
6. CIBSE, CIBSE Guide D: 2015, Chapter 14, London: Chartered Institution of Building Service Engineers, 2015. 
7. Electronics, CE, [Online]. Available: http://www.ceelectronics.co.uk.
8. Drucegrove Ltd, [Online]. Available: http://www.drucegrove.com/.
9. A. Peters and R. Peters, “Logging and Analysis of Lift Journeys Using an Accelerometer,” in Proceedings of 10th Symposium on Lift & Escalator Technologies, Northampton, 2019. 
10. R. Peters, “Remote Monitoring: What we want – a consultant/researcher viewpoint,” in CIBSE Remote Monitoring of Lifts Open Forum, London, 1995. 

BIOGRAPHICAL DETAILS

Richard Peters has a degree in Electrical Engineering and a Doctorate for research in Vertical Transportation. He is a director of Peters Research Ltd and a Visiting Professor at the University of Northampton.  He has been awarded Fellowship of the Institution of Engineering and Technology, and of the Chartered Institution of Building Services Engineers. Dr Peters is the author of Elevate, elevator traffic analysis and simulation software.

Jim Nickerson has been working with Peters Research as a Software Engineer Consultant since 2009.   He joined Peters Research to support the development of Elevate traffic analysis and simulation software, and currently leads the development of the Elevate Live lift and escalator management software.  Previously he worked for ThyssenKrupp Elevator and DigiMetric Inc where he developed a range of lift component and monitoring products.