Design of an elevator IoT system based on WEN technology

1 Introduction

With the development of the national economy and the continuous advancement of urban modernization, high-rise residential buildings are becoming increasingly common in major cities. In these communities, elevators, as vertical transportation tools, have become an indispensable part of people's work and life. As the number of elevators increases, people are placing higher demands on their intelligent control and management. Generally, newly built large commercial and residential areas have established their own elevator control centers, but these monitored elevators only account for a small portion of the total elevator usage. Unmonitored elevators often experience prolonged entrapment, making comprehensive and effective elevator monitoring essential for the human-centered use of elevators. If, in the traditional way, separate elevator control systems are established for each unit or building, this would result in a significant waste of human and material resources. However, if a comprehensive elevator monitoring and management system is established for an entire city, the dispersed locations of elevators present challenges in data aggregation and transmission.

After investigation and comparison, the following problems were found in existing elevator IoT systems:

1. The system setup cost is high, and the local sensing nodes are expensive. For example, configuring and installing a GPRS module for each elevator main controller is costly.

2. The monitoring and management system has weak portability. The system's management system has a one-to-one correspondence with the local main control equipment, making it difficult to port. This increases the cost of secondary development and makes it unable to adapt to the frequent increase in field equipment and the replacement of equipment types. Therefore, the system's versatility and scalability need to be improved.

3. It cannot achieve real-time data exchange between all facilities across platforms and systems, and cannot realize cross-system management and control of equipment and facilities according to functional requirements.

4. The system's monitoring scope is limited, generally confined to a single community or region. Multi-regional elevator remote centralized monitoring and management systems have not yet emerged. Even with multi-regional monitoring, the method typically involves aggregating monitoring computer data from each region to the monitoring center via a network. This method requires additional computer and communication facilities, resulting in higher costs.

5. The system is limited to elevator monitoring functions and does not share data with elevator-related companies, so it is not a true elevator Internet of Things (IoT) system.

Therefore, it is imperative to design and develop a truly meaningful elevator Internet of Things (IoT) system that is low-cost, easy and flexible to network, and user-friendly.

2. Principles of Elevator Internet of Things System

In terms of data centralization and transmission, the elevator IoT based on WEN technology first collects elevator operating parameters through nodes, then forms a mesh network using WEN technology. The collected information is aggregated at a gateway, and the gateway data is delivered to the IoT server via GPRS or 3G, as shown in Figure 1. Each field site establishes a WEN personal area network. Leveraging the self-healing and routing capabilities of the WEN network, the stability of the local network is improved. All data from the local personal area networks is transmitted to the IoT server via GPRS or 3G, achieving distributed control and centralized management. Elevator-related companies can access the IoT platform data via the Internet with appropriate permissions, monitor elevator operating status, and follow a user-friendly emergency repair process when elevators malfunction. Data sharing functionality enables the elevator IoT system to share data with elevator supplier ERP systems, logistics company ERP systems, etc. The elevator IoT solution revolutionizes the traditional point-to-point transmission mode, achieving point-to-multipoint transmission, significantly reducing networking costs. Furthermore, the system is easily expandable; newly added devices can automatically join the network, saving secondary development costs.

Figure 1. Structure diagram of the elevator Internet of Things system

3. Elevator IoT Sensing Layer Design

3.1 Hardware Design

In the elevator Internet of Things (IoT) system, the sensing layer devices are divided into nodes, repeaters, gateways, debuggers, and protocol converters. The protocol converter is used to connect to main controllers from other manufacturers. Function list 1 is as follows:

Table 1 Elevator IoT Sensing Layer Equipment

Both the node and the gateway adopt a dual-CPU mode, with a main CPU and an RF CPU. The two work independently and interact with each other via UART, as shown in Figure 2.

Figure 2 Gateway hardware block diagram

3.2 Software Design

The system does not have high real-time requirements and belongs to non-preemptive task scheduling. Therefore, a polling task scheduling method is adopted. A task can consist of multiple events, and all event processing for the same task is completed by a unified event processing function.

The task event scheduling mechanism consists of two key arrays: an event flag array and a task function array. The event flag array stores the execution flags for each event within the same task; each element represents the execution flag for the corresponding event. Whether a task is executed in the current loop depends on its value; a non-zero value grants it a chance to execute, and the execution order depends on the task's priority. The task function array stores the entry address for each task. Only tasks recorded in the event flag array that require execution will be invoked in the current loop.

For the same task, multiple events may occur, requiring different event handling. For convenience, the event handling function for each task is implemented within a single event handling function. Then, based on the task number and the specific event number of that task, the event handling function for that task is called. Once the event handling function for that task is entered, the `events` parameter is used to determine which type of event has occurred, and the corresponding event handling function is then executed. Finally, the flag of the processed event is cleared. The main loop searches for the event flag of each task from the beginning of the task list, ensuring that events of higher-priority tasks are processed first. The processing process is shown in Figure 3 below.

Figure 3 Event handling process in the task system

3.3 Key Technologies

The IoT sensor layer's personal area network (PAN) wireless data transmission primarily utilizes unicast and broadcast methods. Broadcast is mainly used in gateways for PAN network management. The gateway periodically sends broadcast commands, specifying a starting address. Upon receiving the broadcast command, a node compares the specified address with its own address. If its own address is less than or equal to the specified address plus 5, the node encapsulates its own network parameter data packet and delivers it to the gateway in a point-to-point manner, using the received gateway network address as the destination address. The gateway's network parameter requests are designed as packets with starting addresses. This is because, with a large number of PAN nodes, if all nodes returned a broadcast request, it could potentially cause PAN wireless channel congestion. Data packets such as elevator basic status requested by the IoT platform and the node's broadcast request data could potentially be returned simultaneously. Furthermore, if all nodes return broadcast request data almost simultaneously, it can severely congest the single-channel data transmission, ultimately leading to packet loss.

Since repeater installation does not require setting node numbers, a unique identifier for the repeater is needed. A unique first physical address is used, and an identification algorithm yields a two-byte repeater identifier. At the end of a broadcast cycle, the gateway finds the next non-zero identifier from the repeater management array, and broadcasts it to the repeater. Upon receiving this command, the repeater extracts the identifier value carried in the data packet and compares it to its own identifier. If it matches its own identifier, the wireless reset counter is set; otherwise, the wireless reset counter is decremented by 1.

(1) Broadcast data transmission method

Data transmission from a single point to all nodes in the network must, of course, be within the specified radio frequency distance. Gateway data is transmitted via the WEN network to all nodes that have joined the network, with the destination network address being 0xfffc (excluding dormant nodes), and may be forwarded via routing.

(2) Unicast data transmission method

In other words, point-to-point communication allows you to specify the network address of the target node when delivering data, unless it is a neighboring node (the radio frequency distance between the nodes is within the set radio frequency radius). When nodes communicate, route detection is triggered first. If point-to-point communication is confirmed, a single attempt requires a three-way handshake. During this process, a new route detection may be initialized. If the previous route is broken, unicast data transmission can be forwarded through the route. This function can be specified programmatically.

The gateway requests elevator basic status commands, gateway requests node restart commands, node returns basic status request commands, node fault proactive reporting commands, and elevator entrapment commands are all sent in unicast form.

WEN is an asynchronous protocol, allowing any node to send and receive data simultaneously. The nature of WEN inherently makes data packet transmission latency difficult to predict. Therefore, system design must consider a data packet latency of approximately 10ms at each level. When data transmission is retried or route detection is required, the latency will be even longer. For example, route detection requires broadcasting throughout the network, and responding nodes must wait for the detection results. As shown in Figure 4, data transmission from node A to node B requires four hops. After sending the data packet, A must wait at least 40ms to receive the data. If acknowledgment is needed, it will take 80ms for node A to receive the data returned by node B.

Figure 4 shows the delay diagram of WEN data packets.

Therefore, the application design needs to be compatible with a certain range of latency. If the personal area network channel is relatively clean, the data packet length will not have a significant impact on the latency, because random waiting time can make the transmission time delay less noticeable. However, when the data channel is particularly noisy, the length of the data packet will inevitably lead to more retries, which will increase the latency.

Therefore, a good way to ensure signal stability is to shorten the data packet length as much as possible. This method can not only shorten communication delay, but also reduce bandwidth usage. Of course, in the case of large data volume, increasing the data packet length is the best way to shorten the number of transmissions, but in most cases, it is necessary to consider shortening the data packet length as much as possible.

The protocol defined on the elevator IoT platform fully considers the impact of data packet length on network latency. Therefore, the defined sending and receiving protocols are relatively short. In the data block part of the protocol, escape sequences are used instead of ASCII codes to keep the data packet length within 15 bytes as much as possible.

4 IoT Platform

After the data from the sensor layer's individual area networks (INNs) is aggregated at the gateway, it needs to be transmitted to the IoT server via a Data Transfer Unit (DTU). The IoT platform is designed with a B/S architecture, with each INN configured with one DTU. Each DTU has a specific identifier, and all DTUs are connected to a server with a designated domain name, forming a TCP connection. The IoT platform manages a corresponding elevator area on-site using these DTUs as units.

The IoT platform offers menu options for elevator monitoring, fault handling, fault analysis, elevator archives, elevator maintenance, and emergency elevator repair, as shown in Figure 5. Client users access designated functional modules based on their permissions. Detailed data on all connected elevators is recorded on the platform, including basic parameters such as the model of the controlled equipment, the manufacturing date, manufacturer name, and installation date of traction machines, door operators, etc., as well as platform-statistical parameters such as the failure rate of equipment from a particular manufacturer and annual inspection reminders. The backend database is partially open to elevator manufacturers and purchasers, enabling data sharing. Purchasers (such as elevator sales companies or property management companies) can use the elevator procurement function within the elevator IoT system to place orders directly with elevator manufacturers on the platform. They can not only place and order complete elevators and elevator parts online, but also query the production and delivery status of complete elevators and parts. The elevator IoT system is equipped with intelligent elevator performance analysis and statistics functions. All elevator operation data in the networked elevators is stored in the backend database, including the number of runs and fault numbers uploaded through the elevator controller, and the number of faults, failure rate, and fault descriptions statistically analyzed by software on the elevator IoT system. The management platform offers a query function, allowing customers to access historical elevator operation data from the network, providing a basis for their selection. Order placement and ordering functions are implemented using database technology. Triggers are configured in the database to send procurement information to the elevator equipment supplier's procurement platform, and order execution status information can be sent back to the database. Leveraging the client/server architecture of SQL Server database, seamless interaction between the IoT platform and the elevator equipment supplier's ERP system is achieved.

Figure 5 IoT Platform

5. Conclusion

WEN, with its advantages of low power consumption, low cost, and low complexity, and by adopting all the advantages specified by the robust wireless physical layer of IEEE 802.15.4, while adding safeguards for logical networks and network security, has been widely applied in various fields such as data acquisition, wireless industrial control, automotive automation, remote network control, and home and building automation. This paper applies WEN technology to elevator IoT. Leveraging the advantages of WEN and fully considering the specific characteristics of elevator use and operation, an elevator IoT based on WEN technology has been designed. Thanks to its low cost, strong practicality, and stability, it has been installed and used on construction sites throughout the country. The launch of the IoT platform provides maintenance units, property management companies, and government agencies with a convenient means to monitor elevators, improving the safety and standardization of elevator use.