In modern society, elevators have become indispensable transportation equipment. Elevators make commuting in high-rise buildings much more convenient. The development of elevator control technology has mainly gone through three stages: relay control, microcomputer control, and fieldbus control. Compared with other fieldbuses, the CAN bus is the easiest to implement and the cheapest, which is why it is widely used in many fields. The CAN bus protocol is based on the Open Systems Interconnection (OSI) model of the International Organization for Standardization. As the underlying network for industrial control, the CAN bus can achieve a baud rate of up to 1 Mbps and a maximum distance of 10 km. Its short frame structure results in short data transmission time and a low probability of interference. Furthermore, the CAN bus protocol has good error detection measures, thus ensuring high reliability. Due to its security, real-time performance, ease of operation, and low cost, the CAN bus is very suitable for elevator communication. Currently, elevator shaft systems mainly use parallel communication, resulting in numerous up and down cables, making on-site installation and debugging relatively complicated. After adopting the CAN bus, a controller area network is formed through serial communication, using only four wires: two power lines, one signal transmission line, and one signal reception line. This enables communication of elevator call, internal selection, and display signals, and provides a convenient interface for further realizing multi-elevator group control, remote monitoring, and building automation. 1 System Composition and Hardware Design 1.1 Overall System Structure The system is based on a CAN bus multi-master structure, with the CAN bus controller 82526 and the bus transceiver PCA82C250 as the main components of the communication control module. A main controller, car controller, and hall controller are designed. A controller area network is formed through serial communication to realize communication of elevator call, internal selection, and display signals. However, with the emergence of high-rise buildings and the expansion of building areas, it is necessary to set up several elevators side by side to complete the vertical transportation task within the building. To achieve group control, the problem of interconnecting elevators arises, which requires a unified monitoring and scheduling microcomputer. Here, we use a 485 bus to realize communication between individual elevator main controllers and with the monitoring microcomputer. The structure of the elevator group control system is shown in Figure 1. [align=center]Figure 1. Structure Diagram of Elevator Group Control System[/align] 1.2 System Hardware Design In a single elevator control system, the main controller is responsible for acquiring signals from other controllers, outputting display signals, and controlling elevator operation. The car and hall controllers only need to acquire call signals, send them to the main controller via the CAN bus, and receive display signals from the main controller and output them. Therefore, the structure of the car and hall controllers is largely similar to and relatively simpler than that of the main controller. The hardware design is described below using the main controller (as shown in Figure 2) as an example. The elevator main controller CPU uses the AT89C51 microcontroller. The AT89C51 microcontroller is an enhanced microcontroller compatible with the 8X51 series microcontrollers, and it integrates 4K bytes of FlashROM. Since the main controller is the core of the elevator control system and bears the important task of controlling elevator operation, the programmed code is large. Therefore, it also needs external program data storage, typically using 2764 and 6264. In a single elevator control system, the main controller communicates with the car and hall controllers via the CAN bus. The CAN bus controller uses the Intel 82526 chip. The PCA82C250 serves as the CAN bus interface. The 82526 internally implements all data link layer functions in hardware; therefore, this part of the program only needs to read data from and write data to the 82526. Figure 3 shows the peripheral circuit wiring diagram of the CPU and the CAN/485 interface circuit. [align=center]Figure 3 Communication Interface Circuit Diagram[/align] In the main controller, because a large number of input points are required, we use the commonly used 8255 as the input/output interface chip. Considering the convenience of actual debugging and program modification, a keyboard display circuit is designed in the main controller. The core of this circuit uses the 8279 programmable interface chip, specifically designed for keyboard and display interfaces, and operates in scanning mode. Scan lines SL0~SL2 generate 8 scan signals through a 3-to-8 decoder. Furthermore, to solve problems caused by external interference, a watchdog circuit is added to the main controller to ensure that the system can return to normal operation in a timely manner when a fault occurs. 2 Communication Protocol This system adopts the CAN 2.0A standard. The biggest advantage of this protocol is that it eliminates the traditional station address encoding. Therefore, CAN does not have the concept of node addresses; instead, it encodes communication data blocks, supporting a data-centric communication mode. When the number of elevator floors changes, only the number of controller nodes needs to be added or removed on the bus, and the corresponding data frames need to be modified appropriately. 2.1 Data Frame A data frame (as shown in Figure 4) consists of seven parts: frame start, arbitration field, control field, data field, CRC sequence, ACK field, and frame end. The arbitration field includes a message identifier (11 bits) and a remote transmit request (RTR) bit; the control field consists of six bits, with the last four bits representing the data length code, indicating the number of data bytes, which is set to 2 here; each data frame contains two bytes, with the high byte indicating the specific floor number and the low byte being the control word. [align=center]Figure 4 Data Frame Composition[/align] 2.2 When the arbitration bus is idle, any node can send data, and other nodes can receive data. Point-to-point, point-to-multipoint, and global broadcast communication methods can be achieved simply by message filtering, without the need for dedicated scheduling. Message filtering is implemented here using a receive code register and a receive code mask register. When multiple bus controllers send messages simultaneously, arbitration is required to avoid conflicts. A non-destructive arbitration method is used to resolve conflicts. Non-destructive means that this arbitration method ensures no loss of information or time; it is achieved using the ID number in the bit-by-bit arbitration frame. As mentioned earlier, the arbitration field ID number uniquely identifies a node address. An RTR bit of 0 indicates a data frame, and 1 indicates a remote frame, with the latter having higher priority than the former. This 12-bit ID number represents the priority of the message; the smaller the number, the higher the priority. The non-destructive arbitration process can be illustrated with an example, as shown in Figure 5. At a certain moment, three nodes a, b, and c on the network simultaneously send information. The ID identifiers are sent in order from the most significant bit to the least significant bit, i.e., from ID.0 to ID.11. The network performs a bitwise AND operation after each character is sent. For example, after ID.6 is sent, the network performs the operation: 0∩1∩0＝0, so the information received by each node on the network is 0. The byte with ID.6 being 1 detects the difference between the received and sent information and stops sending. This causes the node with the lower priority (larger ID) to exit the transmission. This comparison continues until all IDs and RTRs are sent, leaving only node c on the network to continue sending information without needing to retransmit. 3 Program Design [align=center] Figure 5 CAN Conflict Arbitration Process[/align] The flowchart of the main controller program is shown in Figure 6. According to the actual operation requirements of the elevator, the main controller must communicate with the car and hall during the control period to collect the car and hall call signals, and complete the control of the elevator's running direction, current floor number, display, and mid-journey stop. Meanwhile, during elevator operation, the main controller also needs to collect and analyze various switch limit signals in the shaft to achieve accurate control of the elevator. During system debugging, the main controller should also be able to communicate with the PC to facilitate real-time system control. Therefore, the program design of the main controller should fully consider the organic combination of the above functions. [align=center] Figure 6 Main Controller Program Flowchart[/align] The program flowchart of the car and hall controllers is shown in Figure 7. Their functions are relatively simple: to collect call signals and send them to the main controller, receive display signals from the main controller and output them. [align=center] Figure 7 Car and Hall Controller Program Flowchart[/align] The parking control subroutine is mainly responsible for elevator parking and car door opening and closing control. First, the program outputs the parking control word. Then, the elevator door opens. Next, it checks whether the light curtain signal is truncated. If so, it waits; if not, it checks whether the elevator is overloaded. If overloaded, it alarms and waits; otherwise, it checks whether there is a door closing signal. If there is, the elevator door closes. If not, the door will automatically close after a delay and return to the main program. The program flowchart is shown in Figure 8. [align=center] Figure 8 Flowchart of the parking subroutine[/align] 4 Conclusion Based on CAN bus technology, the elevator monitoring system, which uses AT89C51 as the core and 82526 combined with PCA820250 chip, is used in practical applications. The main controller communicates with other main controllers through the CAN bus transceiver. After being used on two 8-story elevators, compared with the replacement PLC control system, the fault stop time is greatly shortened, the reliability is significantly improved, and the debugging and addition/reduction of content are relatively convenient, achieving the expected results. References: [1] Wu Kuanming, ed., CAN Bus Principles and Application System Design, Beijing, Beijing University of Aeronautics and Astronautics Press, 1996. [2] Li Enlin, Chen Binsheng, ed., 300 Examples of Microcomputer Interface Technology, Beijing, Machinery Industry Press, 2003.