Elevator system and communication packet analysis countermeasure method
The elevator system addresses the challenge of securing communication packets in multi-drop communications by using dynamic sequence generation, encryption, and operation mode masking, resulting in enhanced security and protection against unauthorized interference.
Patent Information
- Application Number
- JP2023184412
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- Filing Date
- 2023-10-27
- Publication Date
- 2025-05-13
AI Technical Summary
Existing elevator systems face challenges in securing communication packets in multi-drop communications, making it easy for unauthorized entities to decipher the communication sequence and interfere with the normal operation of the elevator control.
The elevator system employs a controller with a sequence generation unit, a protection data generation unit, and a protection data recovery unit to dynamically change the format of communication packets based on the elevator's operating state, encrypting both the header and payload sections, and applying an operation mode mask to the node ID to secure communication.
This configuration effectively makes it difficult to decipher communication packets in multi-drop communications, thereby enhancing the security of the elevator system and preventing unauthorized interference with its operation.
Smart Images

Figure 2025073520000001_ABST
Abstract
Description
[Technical field]
[0001] The present invention relates to an elevator system and a communication packet analysis countermeasure method. [Background technology]
[0002] Conventionally, a maintenance terminal that maintains the elevator is connected to an elevator system. In communication between the elevator system and the maintenance terminal, a communication packet that stores communication data is generated according to a predetermined data configuration. In addition, when a communication packet is transmitted, only the payload portion in which the communication data is stored is encrypted, and the header in which the address information of the sender and receiver is stored is transmitted without being encrypted. Such communication packets have insufficient defense capabilities in communication and are easily guessed. Therefore, for example, Patent Document 1 proposes a technology for obfuscating communication packets.
[0003] Patent document 1 states that "in order to prevent unauthorized reading of the data to be transmitted, the maintenance terminal and the elevator control system use the elevator status, etc. as common information and encode the data to be transmitted to obfuscate it," and that "the obfuscation processing unit performs conversion on the payload portion of the communication packet." [Prior art documents] [Patent documents]
[0004] [Patent Document 1] Patent Publication No. 2022-066665 Summary of the Invention [Problem to be solved by the invention]
[0005] As described above, a conventional technique has been proposed to encode the transmission target data (payload portion) of a communication packet transmitted between an elevator system and a maintenance terminal, and change the data structure of the payload portion of the communication packet. However, in one-to-one communication between an elevator system and a maintenance terminal, it is easy to decode the communication sequence, which is the procedure for exchanging data, by intercepting the data flowing on the communication path.
[0006] On the other hand, an elevator system is a distributed control system composed of multiple controllers, and may use a so-called multi-drop communication path that realizes 1-to-N or N-to-N communication. For example, standard communication methods for a multi-drop communication path include RS (Recommended Standards)-485 for serial communication and 10BASE5 for network communication. When multiple terminals are connected to a multi-drop communication path, there is a high possibility that communication packets will be intercepted. By intercepting or collecting communication packets, it is possible to decode the unencrypted header part (a structure part in which address information for transmission and reception is stored), the communication sequence of the entire elevator system, and the control processing cooperation between controllers. If the decoded communication sequence and communication data are used incorrectly, there is a possibility that the normal operation of the elevator control will be hindered. For this reason, a measure is required to make it difficult to decode communication packets in the multi-drop communication in an elevator system.
[0007] The present invention has been made in view of the above circumstances, and an object of the present invention is to make it difficult to decipher communication packets in multi-drop communication in an elevator system. [Means for solving the problem]
[0008] The present invention is an elevator system comprising an elevator and a plurality of control devices related to the operation control and maintenance of the elevator, the plurality of control devices being capable of communicating with each other, the control devices comprising: a sequence generation unit that generates sequence data for changing the format of communication packets to be sent to other control devices in accordance with the operating status of the elevator; a protected data generation unit that changes the format of the communication packets and encrypts them in accordance with the sequence data; and a protected data restoration unit that restores communication packets received from other control devices. Effect of the Invention
[0009] According to the present invention having the above configuration, it is possible to make it difficult to decipher communication packets in multi-drop communication in an elevator system. Problems, configurations and effects other than those described above will become apparent from the following description of the embodiments. [Brief description of the drawings]
[0010] [Figure 1] 1 is a diagram showing a configuration example of an elevator system according to an embodiment of the present invention; [Diagram 2] FIG. 2 is a block diagram showing an example of the hardware configuration of each control device of the elevator system according to one embodiment of the present invention. [Diagram 3] FIG. 2 is a block diagram showing an example of the functional configuration of each control device in the elevator system according to the embodiment of the present invention. [Figure 4] FIG. 10 is a diagram for explaining a format change of a communication packet in an elevator system according to an embodiment of the present invention. [Diagram 5] 5 is a flowchart showing a procedure of a communication packet transmission and reception process in a control device on a transmitting and receiving side of an elevator system according to an embodiment of the present invention. [Figure 6] 5 is a flowchart showing the procedure of data protection processing in a transmitting control device of the elevator system according to one embodiment of the present invention. [Figure 7]10 is a flowchart showing the procedure of data restoration processing in a receiving-side control device of an elevator system according to an embodiment of the present invention. [Figure 8] 5 is a flowchart showing a procedure of a node ID change process in a transmitting control device of an elevator system according to an embodiment of the present invention. [Figure 9] 10 is a flowchart showing a procedure of an operation mode determination process in a receiving-side control device of the elevator system according to one embodiment of the present invention. [Figure 10] 5 is a diagram showing an example of data in a communication feasibility determination table in each control device of the elevator system according to one embodiment of the present invention. FIG. [Figure 11] 10 is a flowchart showing a procedure of a communication feasibility determination process in a receiving side control device of an elevator system according to an embodiment of the present invention. [Figure 12] 11 shows an example of data in a communication refusal table in each control device of the elevator system according to one embodiment of the present invention. [Figure 13] 5 is a flowchart showing a procedure of a dummy transmission process in a receiving side control device of the elevator system according to one embodiment of the present invention. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0011] Hereinafter, an embodiment of the present invention will be described with reference to the accompanying drawings. In this specification and the drawings, components having substantially the same functions or configurations are designated by the same reference numerals, and redundant description will be omitted.
[0012] <One embodiment> [Elevator system configuration example] First, the configuration of an elevator system 100 according to an embodiment of the present invention will be described. The elevator system 100 includes elevators and a plurality of control devices related to elevator operation control and maintenance, and the plurality of control devices can communicate with each other. FIG. 1 is a diagram showing an example of the configuration of the elevator system 100 according to this embodiment. As shown in FIG. 1, the elevator system 100 includes a center device 1, a communication controller 3, a management terminal 20, an elevator group 18a and an elevator group 18b, and a maintenance terminal 50. The center device 1 and the communication controller 3 are connected via a communication path 2, which is a mobile closed circuit network such as a dedicated line or a public line such as the Internet. In addition, the communication controller 3 and the management terminal 20 are connected to a plurality of elevator groups (elevator group 18a and elevator group 18b) via a communication path 17. The communication path 17 is a communication path to which a multi-drop type communication device is applied. Although FIG. 1 shows an example in which elevator system 100 has two elevator groups, the present invention is not limited to this, and elevator system 100 may have only one elevator group or three or more elevator groups.
[0013] The center device 1 is a computer device that is installed in a remote center and performs remote maintenance, remote operation, etc. of each elevator group. The center device 1 issues instructions for remote maintenance, remote operation, etc. to a group management controller 4 (described later) of each elevator group via a communication path 2 and a communication controller 3.
[0014] The communication controller 3 is an example of a control device, and is a computer device that transmits and receives data between the center device 1 and the group management controllers 4 of each elevator group via a communication path 17. The hardware configuration of the communication controller 3 will be described in detail with reference to FIG. 2 below.
[0015] The control terminal 20 is an example of a control device, and is a computer device used by the manager of the elevator system 100 to perform various settings for the elevators of each elevator group and to monitor the operation status. The various settings performed in the control terminal 20 are transmitted to an elevator controller 5 (described later) via a communication path 17 and a group management controller 4 (described later) of each elevator group. The hardware configuration of the control terminal 20 will be described in detail with reference to FIG. 2 (described later).
[0016] The maintenance terminal 50 is an example of a control device, and is a computer device for performing maintenance work on each controller and each communication path of the elevator system 100. The maintenance terminal 50 is, for example, a maintenance port mounted on the board of each controller, or a terminal device for performing maintenance operations connected to each communication path. Here, each controller includes a communication controller 3, a group management controller 4, an elevator controller 5, a car controller 10, and a floor controller 11. Furthermore, each communication path includes a communication path 12, a communication path 16, and a communication path 17. The hardware configuration of the maintenance terminal 50 will be described in detail in FIG. 2 described later.
[0017] The elevator group 18a and the elevator group 18b have the same configuration, and in the following description, the elevator group 18a will be described as an example, and the description of the elevator group 18b will be omitted. As shown in FIG. 1, the elevator group 18a includes a group management controller 4 and a plurality of elevators (elevators 15a and 15b). The group management controller 4 is connected to the elevator controllers 5 of the elevators 15a and 15b via a communication path 16. The communication path 16 is a communication path to which a multi-drop communication device is applied, similar to the communication path 17. Note that, although FIG. 1 shows an example in which the elevator group includes two elevators, the present invention is not limited thereto, and the elevator group may include three or more elevators.
[0018] The group controller 4 is an example of a control device, and is a computer device that performs operation management of each elevator group. The hardware configuration of the group controller 4 will be described in detail with reference to FIG.
[0019] The elevators 15a and 15b have the same configuration, and in the following description, the elevator 15a will be taken as an example and a description of the elevator 15b will be omitted. As shown in Fig. 1, the elevator 15a has an elevator controller 5, a motor 6, a car 7, a counterweight 8, a car controller 10, a floor controller 11, and an up / down button 14. The car 7 and the counterweight 8 are wound around a hoist (not shown) with a built-in motor 6 by a rope 9 and suspended from a hoistway (not shown). The counterweight 8 is a weight for balancing.
[0020] The elevator controller 5 is an example of a control device, and is a computer device that controls the motor 6 to control the vertical movement of the car 7 driven by the motor 6. The elevator controller 5 and the above-mentioned group management controller 4 may be provided in the hoistway, or in a machine room (not shown) above the hoistway. The hardware configuration of the elevator controller 5 will be described in detail in FIG. 2 below.
[0021] The car controller 10 is an example of a control device, and is installed on the ceiling of the car 7 and connected to an operation panel 13 that manages destination floor buttons and door opening / closing buttons (not shown) in the car 7. The car controller 10 is a computer device that monitors the operation state of the operation panel 13 by a user and transmits the monitored operation state to the elevator controller 5 via a communication path 12. The communication path 12 is a communication path to which a multi-drop type communication device is applied, similar to the communication paths 16 and 17. Note that the car controller 10 is not limited to being installed on the ceiling of the car 7, and may be installed at any position of the car 7. Also, instead of the operation panel 13, the car controller 10 may transmit a destination floor registered in a destination floor reservation system (not shown) that can communicate with the elevator system 100 to the elevator controller 5 via the communication path 12. The hardware configuration of the car controller 10 will be described in detail with reference to FIG. 2 described later.
[0022] The floor controller 11 is an example of a control device, and is a computer device that is connected to the up and down buttons 14, monitors the operation state of the up and down buttons 14 by a user, and transmits the monitored operation state to the elevator controller 5 via the communication path 12. In addition, instead of the up and down buttons 14, the floor controller 11 may transmit to the elevator controller 5 via the communication path 12 a boarding floor and a destination floor registered in a destination floor reservation system (not shown) that can communicate with the elevator system 100. The hardware configuration of the floor controller 11 will be described in detail with reference to FIG. 2 below.
[0023] [Example of hardware configuration for each control device] Next, a description will be given of an example of the hardware configuration of each control device of the elevator system 100. Fig. 2 is a block diagram showing an example of the hardware configuration of each control device of the elevator system 100 according to this embodiment. The calculator 30 shown in Fig. 2 is an example of hardware used as a computer capable of operating as each control device of the elevator system 100.
[0024] The computer 30 includes a micro processing unit (MPU) 31, a read only memory (ROM) 32, a random access memory (RAM) 33, and a communication interface (IF) 34, all of which are connected to a bus 35.
[0025] The MPU 31 reads out the program code of the software that realizes the functions of each control device according to the present embodiment from the ROM 32, loads it into the RAM 33, and executes it. Variables, parameters, etc. generated during the arithmetic processing of the MPU 31 are temporarily written into the RAM 33, and these variables, parameters, etc. are read out by the MPU 31 as appropriate. Note that, instead of the MPU 31, an MCU (Micro Control Unit), a CPU (Central Processing Unit), etc. may be used. The calculator 30 may further include a non-volatile memory such as an NVRAM (Non-Volatile Random Access Memory), an HDD (Hard Disk Drive), or an SSD (Solid State Drive). In this case, the programs, data, etc. required for the MPU 31 to operate may be recorded in this non-volatile memory. In other words, the ROM 32 or the non-volatile memory is used as an example of a computer-readable non-transient recording medium that stores a program executed by a computer.
[0026] The communication IF35 may be, for example, a NIC (Network Interface Card), and various data can be transmitted and received between devices via a multi-drop serial communication device, a LAN (Local Area Network) connected to the terminal of the NIC, a WAN (Wide Area Network), a RAN (Radio Area Network) which is a wireless communication path, a dedicated line, etc.
[0027] [Example of functional configuration of each control device] Next, a functional configuration example of each controller of the elevator system 100 will be described. Fig. 3 is a block diagram showing a functional configuration example of each control device in the elevator system 100 according to this embodiment. Fig. 3 shows a communication configuration example in which a control device 40a on the transmitting side and a control device 40b on the receiving side are connected to a communication path 60. The control device 40a on the transmitting side and the control device 40b on the receiving side are each one of the control devices capable of communicating in the elevator system 100. The communication path 60 is one of the above-mentioned communication path 12, communication path 16, and communication path 17 depending on the control device to be connected.
[0028] The transmitting control device 40a has an elevator status confirmation unit 41a, a sequence generation unit 42a, a protected data generation unit 43a, a communication unit 44a, and a protected data restoration unit 45a. Each functional component of the transmitting control device 40a operates under the control of the MPU 31 described above.
[0029] The elevator status confirmation unit 41a checks the operation status of the elevators in the elevator system 100 at a predetermined cycle and outputs operation status data to the sequence generation unit 42a. Here, the elevator operation status data includes status data such as the stopped status of the car, the stopping floor of the car, the speed of the car, etc., or status data generated by combining these status data. In addition, the operation status data of the elevator system 100 may be generated based on data indicating the internal operation mode status of the transmitting control device 40a, etc.
[0030] The sequence generating unit 42a generates sequence data (see FIG. 4 described later) for changing the format of a communication packet to be transmitted to another control device (receiving control device 40b) according to elevator operation status data. The format of the communication packet has a header section and a payload section. The header section includes sender identification information, receiver identification information, and data size information, and the payload section includes communication data. The sequence generating unit 42a divides the payload section into a plurality of parts, and generates sequence data for changing the sender identification information, receiver identification information, data size information, and the arrangement order of the plurality of parts of the divided payload section, which are included in the format of the communication packet, according to the elevator operation status. The sequence generating unit 42a outputs the generated sequence data to the protection data generating unit 43a. The sequence generating unit 42a generates the sequence data based on, for example, preregistered information indicating a sequence associated with each operation status data. The sequence generating unit 42a may generate the sequence data using, for example, a logic for generating sequence data corresponding to each operation status data, which is prepared in advance.
[0031] The protected data generating unit 43a changes the format of the communication packet in accordance with the sequence data input from the sequence generating unit 42a, and encrypts the header and payload of the communication packet to generate protected data. The protected data generating unit 43a outputs the generated protected data to the communication unit 44a.
[0032] The communication unit 44a transmits and receives data (transmits and receives protected data) to and from another control device (the receiving control device 40b).
[0033] The protected data restoration unit 45a restores communication packets received from other control devices. Each control device can be either the receiving side or the transmitting side. When a control device becomes the receiving side, the protected data restoration unit 45 operates. On the other hand, when a control device becomes the transmitting side (in the case of the control device 40a on the transmitting side shown in FIG. 2), the protected data restoration unit 45a does not operate.
[0034] The receiving control device 40b has an elevator status confirmation unit 41b, a sequence generation unit 42b, a protected data generation unit 43b, a communication unit 44b, and a protected data restoration unit 45b. Each functional component of the receiving control device 40b operates under the control of the MPU 31 described above.
[0035] The communication unit 44b receives the protected communication format (protected data) from the communication unit 44a of the transmitting control device 40a via the communication path 60, and outputs it to the elevator status confirmation unit 41b and the protected data restoration unit 45b.
[0036] The elevator status checking unit 41b checks the elevator operation status at a predetermined period and outputs operation status data to the sequence generating unit 42b.
[0037] The sequence generating unit 42b generates sequence data (restoration sequence data) for restoring the format of the received communication packets according to the elevator operation status data, and outputs the generated sequence data to the protected data restoring unit 45b. The sequence generating unit 42b generates the restoration sequence data based on, for example, preregistered information indicating the sequence associated with each operation status data. The sequence generating unit 42b may also generate the restoration sequence data using, for example, a logic prepared in advance for generating restoration sequence data corresponding to each operation status data.
[0038] The protected data restoration unit 45b decrypts the received communication packets (protected data) and restores the communication packets in accordance with the restoration order data input from the order generation unit 42b.
[0039] When the control device becomes the transmitting side, the protection data generating unit 43b operates. On the other hand, when the control device becomes the receiving side (in the case of the control device 40b on the receiving side shown in FIG. 2), the protection data generating unit 43b does not operate.
[0040] Next, a change in the format of a communication packet in the control device 40a on the transmitting side of the elevator system 100 will be described. Fig. 4 is a diagram for explaining a change in the format of a communication packet in the elevator system 100 according to this embodiment. Fig. 4A is a diagram showing the original (before change) communication packet. Fig. 4B is a diagram showing sequence data generated by the sequence generation unit 42a of the control device 40a on the transmitting side. Fig. 4C is a diagram showing the communication packet after the format has been changed. Fig. 4D is a diagram showing an encrypted communication packet (protected data).
[0041] For example, as shown in FIG. 4A, the original communication packet F10 has a "Magic No." segment F11, a "sending ID" segment F12, a "receiving ID" segment F13, and a "data size" segment F14. The original communication packet F10 also has a "data area" segment F15 and a "check data" segment F16. The "sending ID" segment F12, the "receiving ID" segment F13, and the "data size" segment F14 are included in the header portion of the communication format. The "data area" segment F15 is included in the payload portion of the communication format.
[0042] The "magic number" segment F11 stores the identification information of the original communication packet F10. In the "transmission ID" segment F12, identification information (transmission side identification information) of the control device 40a on the transmission side, for example, an identification ID (Identification), is stored. In the "reception ID" segment F13, identification information (reception identification information) of the control device 40b on the receiving side, for example, an identification ID, is stored. The "data size" segment F14 stores the size of the communication data, that is, the size of the data stored in the "data area" segment F14. Segment F15 of the "data area" stores communication data. The "check data" segment F16 stores data for checking for inconsistencies in the communication packet, such as "1" indicating an inconsistency or "0" indicating a match.
[0043] The sequence data F20 shown in FIG. 4B is an example of sequence data generated by the sequence generation unit 42a. In order to obfuscate the communication data, the sequence generation unit 42a divides the payload portion into a plurality of parts. Then, the sequence generation unit 42a generates the sending side identification information, the receiving side identification information, the data size information, and sequence data for changing the arrangement order of the plurality of parts of the divided payload portion according to the operation state. In the example shown in FIG. 4B, the data (payload portion) stored in the segment F15 of the "data area" is divided into two parts (data A and data B). Data A and data B are, for example, the first half and the second half of the payload portion, respectively. Note that the payload portion is not limited to being divided into the first half and the second half, and may be divided into any number of parts, and each divided part may have a different size. Also, the sequence generation unit 42a generates the sequence data F20 in the order of "data A", "transmission ID", "size", "data B", and "reception ID", for example, as shown in FIG. 4B. Here, the size of each segment (F21 to F25) of the sequence data F20 is assumed to be a predetermined fixed size, but may be a variable size. Also, the order defined by the sequence data F20 is not limited to the order shown in Fig. 4B, but changes dynamically depending on the operating state.
[0044] Fig. 4C shows a communication packet F30 whose format has been changed in accordance with the sequence data F20 shown in Fig. 4B. The communication packet F30 is generated in the order of segment F11, segment F151, segment F12, segment F14, segment F152, segment F13, and segment F16. The divided data A and data B are stored in segment F151 and segment F152, respectively.
[0045] Furthermore, in order to make analysis of the communication packet even more difficult, the protected data generation unit 43a encrypts the format-changed communication packet F30 as shown in Fig. 4D. The sequence generation unit 42a encrypts segments F151, F12, F14, F152, and F13, i.e., the header and payload portions. Note that the "magic number" segment F11 and the "check data" segment F16 are not subject to sequence generation and encryption. In the case of 1-to-N communication, the "transmission ID" may be excluded from sequence generation and encryption.
[0046] [Transmitting and receiving communication packets] Next, the transmission and reception processing of communication packets in the control devices on the transmitting and receiving sides of the elevator system 100 will be described. Fig. 5 is a flowchart showing the procedure of the transmission and reception processing of communication packets in the control devices on the transmitting and receiving sides of the elevator system 100 according to this embodiment. Since the control of the elevator system 100 has a control period, the elevator status confirmation unit of each control device confirms the operation status of the elevator for each control period. The processing described below is executed for each control period.
[0047] First, the elevator status confirmation unit 41a of the transmitting control device 40a confirms the elevator operation status, and outputs the confirmed operation status data to the sequence generation unit 42a (step S10).
[0048] Next, the sequence generating unit 42a generates sequence data according to the operation status data input from the elevator status checking unit 41a (step S20). The sequence generating unit 42a also outputs the generated sequence data (see FIG. 4B) to the protection data generating unit 43a.
[0049] Next, the protected data generating unit 43a performs data protection processing according to the sequence data input from the sequence generating unit 42a (step S30). The protected data generating unit 43a also outputs the protected communication packet (protected data) to the communication unit 44a. The data protection processing will be described in detail later with reference to FIG. 6.
[0050] Next, the communication unit 44a transmits the protection data input from the protection data generation unit 43a and information indicating the control period in which the protection data was generated to the receiving control device 40b (step S40). After the process of step S40, the communication packet transmission process in the transmitting control device 40a ends.
[0051] Meanwhile, in the receiving control device 40b, the communication unit 44b receives the protection data and information indicating the control period in which the protection data was generated from the communication unit 44a of the transmitting control device 40a (step S50). In addition, the communication unit 44b outputs the received protection data to the protection data restoration unit 45b, and outputs information indicating the control period in which the protection data was generated to the elevator status confirmation unit 41b.
[0052] Next, the elevator status checking unit 41b extracts elevator operation status data checked in the control cycle based on the received information indicating the control cycle, and outputs the data to the sequence generating unit 42b (step S60).
[0053] Next, the sequence generating unit 42b generates restored sequence data based on the data for generating sequence data linked to the operation status data extracted by the elevator status checking unit 41b (step S70). Here, the restored sequence data is sequence data in the reverse order to the sequence data corresponding to the operation status data extracted by the elevator status checking unit 41b.
[0054] Next, the protected data restoration unit 45b performs a data restoration process on the received protected data (step S80). The data restoration process will be described in detail later with reference to Fig. 7. After the process of step S80, the reception process of the communication packet in the receiving control device 40b is completed.
[0055] [Data protection processing] Next, the data protection process in the protection data generating unit 43a of the control device 40a on the transmitting side will be described. Fig. 6 is a flowchart showing the procedure of the data protection process in the control device 40a on the transmitting side of the elevator system 100 according to this embodiment. The process described below is called and executed as a subroutine in step S30 of the communication packet transmission and reception process shown in Fig. 5.
[0056] First, the protection data generating unit 43a of the control device 40a on the transmitting side determines whether or not there is any unread sequence data (step S31).
[0057] In the process of step S31, if the protection data generating unit 43a determines that there is no unread sequence data (NO in step S31), it performs the process of step S35 described below.
[0058] On the other hand, in the processing of step S31, if the protection data generation unit 43a determines that there is sequence data that has not been read (YES in step S31), it sequentially reads the information stored in each segment (see FIG. 4B) that constitutes the sequence data (step S32).
[0059] Next, the protection data generating unit 43a reads data from the original communication packet (see FIG. 4A) based on the information stored in the segment of the read sequence data (step S33). For example, when the protection data generating unit 43a reads "data A" stored in segment F21 of sequence data F20 shown in FIG. 4B, the protection data generating unit 43a reads data corresponding to data A (the first half of the data area) from segment F15 of the original communication packet F10 shown in FIG. 4A.
[0060] Next, the protection data generator 43a adds the data read from the original communication packet to the protection data (step S34). After the process of step S34, the data protection process returns to the process of step S31, and the processes of steps S31 to S34 are repeatedly executed until reading of the sequential data is completed.
[0061] Next, if the result of step S31 is NO, the protection data generating unit 43a performs a node ID change process (step S35). Note that the node ID change process will be described in detail later with reference to FIG.
[0062] Next, the protected data generating unit 43a performs encryption (see FIG. 4D) on the header and payload of the communication packet (step S36). After the process of step S36, the data protection process ends.
[0063] [Data recovery process] 7 is a flowchart showing the procedure of data restoration processing in the receiving-side control device 40b of the elevator system 100 according to this embodiment. The processing described below is called and executed as a subroutine in step S80 of the communication packet transmission / reception processing shown in FIG.
[0064] First, the protected data restoration unit 45b of the receiving control device 40b decrypts the received communication packet (step S81).
[0065] Next, the protected data restoration unit 45b performs an operation mode determination process (step S82). Note that the operation mode determination process will be described in detail later with reference to FIG.
[0066] Next, the protected data restoration unit 45b performs a communication availability determination process (step S83). Note that the communication availability determination process will be described in detail later with reference to FIG.
[0067] Next, the protected data restoration unit 45b determines whether or not the determination result of the communication permission determination process is that communication is permitted (step S84).
[0068] In the process of step S84, if it is determined that the communication permission determination process does not result in communication permission (NO in step S84), the protected data restoration unit 45b rejects the communication (step S85).
[0069] On the other hand, in the process of step S84, if it is determined that the determination result of the communication permission determination process is communication permission (YES determination in step S84), the protected data restoration unit 45b performs the process of step S86. In the process of step S86, the protected data restoration unit 45b determines whether or not there is any restoration order data that has not been read, with respect to the order data (restoration order data) for restoring the data input from the order generation unit 42b.
[0070] In the process of step S86, if the protected data restoration unit 45b determines that unread restoration order data exists (YES in step S86), it sequentially reads the restoration order data (step S87).
[0071] Next, the protected data restoration unit 45b reads data from the received communication packet, that is, the protected data (see FIG. 4C), based on the read restoration order data (step S88).
[0072] Next, the protected data restoration unit 45b adds the data read from the received communication packet to the restored data (step S89). After the process of step S89, the data restoration process returns to the process of step S86, and the processes of steps S86 to S89 are repeatedly executed until reading of the restoration order data is completed.
[0073] On the other hand, in the process of step S86, if the protected data generating unit 43a determines that there is no unread restoration order data (NO in step S86), or after the process of step S85, the data restoration process ends.
[0074] In this embodiment, when each control device has multiple operating modes, the protection data generation unit 43a in the transmitting control device 40a changes the transmitting side identification information according to the operating mode of its own device and the operating mode of the designated receiving side control device 40b.
[0075] Here, it is assumed that the multiple operation modes of each control device of the elevator system 100 are a secure mode and a non-secure mode. When communication occurs between each control device, there are four communication patterns according to the operation modes of the transmitting control device 40a and the receiving control device 40b. The four communication patterns are secure / secure, secure / non-secure, non-secure / secure, and non-secure / non-secure, respectively.
[0076] In the elevator system 100, a node ID and an operation mode mask are provided to change the sending side identification information (transmission ID). The node ID is sending side identification information (transmission ID) that is provided according to each operation mode of the sending side control device 40a. When the sending side control device 40a operates in a secure mode, the protection data generation unit 43a applies a preregistered operation mode mask to the node ID corresponding to the secure mode to change the sending side identification information. When the sending side control device 40a operates in a non-secure mode, the protection data generation unit 43a does not apply the operation mode mask and does not change the sending side identification information.
[0077] On the other hand, in the receiving control device 40b, the protected data restoration unit 45b decrypts the received communication packet, checks the operation mode mask applied to the transmission side identification information of the decrypted communication packet, and determines the operation mode of the device itself based on the confirmed operation mode mask. For example, in the elevator system 100, it is assumed that a mask M1 is registered as an operation mode mask corresponding to the secure mode of the transmitting control device 40a and the non-secure mode of the receiving control device 40b. It is also assumed that a mask M2 is registered as an operation mode mask corresponding to the secure mode of the transmitting control device 40a and the secure mode of the receiving control device 40b. In this case, in the receiving control device 40b, when the protected data restoration unit 45b checks that the operation mode mask applied to the transmission ID of the communication packet is the mask M1, it determines the operation mode of the device itself to be the non-secure mode. When the protected data restoration unit 45b checks that the operation mode mask applied to the transmission ID of the communication packet is the mask M2, it determines the operation mode of the device itself to be the secure mode. Further, the protected data restoration unit 45b judges whether or not communication is possible based on the operation mode of the control device 40a on the transmission side, the determined operation mode of its own device, and a communication possibility judgment table (see FIG. 10 described later) registered in advance.
[0078] As described above, the control device 40a on the transmitting side can specify the operation mode of the control device 40b on the receiving side by applying an operation mode mask to the node ID. Also, the control device 40b on the receiving side can exclude unauthorized operation mode communications by only performing communications that are determined to be permitted based on the operation mode of the control device 40a on the transmitting side, its own specified operation mode, and a communication permission / prohibition determination table registered in advance.
[0079] [Node ID change process] 8 is a flowchart showing the procedure of a node ID change process in the transmitting control device 40a of the elevator system 100 according to this embodiment. The process described below is called and executed as a subroutine in step S35 shown in FIG.
[0080] First, the protected data generator 43a checks the current operation mode of the transmitting control device 40a (step S350). It is common for each control device to have a special register for holding the state of the operation mode, such as secure mode or non-secure mode. Alternatively, the state of the operation mode may be held by software installed in each control device.
[0081] In the process of step S350, if the protected data generating unit 43a confirms that the current operation mode of the transmitting control device 40a is the non-secure mode (if the non-secure mode is determined in step S350), the protected data generating unit 43a performs the process of step S352 described below.
[0082] On the other hand, in the process of step S350, when the protection data generating unit 43a confirms that the current operation mode of the transmitting control device 40a is the secure mode (in the case of secure determination in step S350), it applies the operation mode mask (step S351). In this process, the protection data generating unit 43a changes the transmission ID by, for example, performing an OR operation on the operation mode mask corresponding to the operation mode of its own device and the operation mode of the receiving control device 40b designated in advance, and the transmission ID (node ID). Note that the operation mode of the receiving control device 40b designated in advance is input (designated) by, for example, the manager of the elevator system 100 via the input device of the management terminal 20. In addition, the method of applying the operation mode mask is not limited to the OR operation, and may be another calculation method.
[0083] Next, the protected data generating unit 43a determines the transmission ID to which the operation mode mask is applied (step S352). After the process of step S352, the node ID change process ends.
[0084] [Operation mode determination process] 9 is a flowchart showing the procedure of the operation mode determination process in the receiving-side control device 40b of the elevator system 100 according to this embodiment. The process described below is called and executed as a subroutine in step S82 shown in FIG.
[0085] First, the protected data restoration unit 45b of the receiving control device 40b checks the operation mode mask applied to the transmission ID of the received communication packet (step S820). In this process, if the protected data generation unit 43a of the transmitting control device 40a applies the operation mode mask by OR operation, the protected data restoration unit 45b can obtain the operation mode mask applied to the transmission ID by performing AND operation on the transmission ID of the received communication packet.
[0086] Next, the protected data restoration unit 45b checks the operation mode of the receiving control device 40b that corresponds to the operation mode mask (step S821).
[0087] In the process of step S821, if the protected data restoration unit 45b confirms that the operation mode corresponding to the operation mode mask is the secure mode (if determined to be secure in step S821), it determines the secure mode as the operation mode (step S822).
[0088] On the other hand, in the process of step S821, if the protected data restoration unit 45b confirms that the operation mode corresponding to the operation mode mask is the non-secure mode (if the operation mode is determined to be non-secure in step S821), the operation mode is determined to be the non-secure mode (step S823). After the process of step S822 or step S823, the operation mode determination process ends.
[0089] In addition, in the elevator system 100, in conjunction with the above-mentioned node ID change process and operation mode determination process, a process for eliminating unauthorized operation mode communication is also performed. In each control device of the elevator system 100, a communication feasibility determination table T1 (see FIG. 10 described later) for determining whether communication is possible or not according to the respective operation modes of the transmitting control device 40a and the receiving control device 40b is registered in advance. The protected data restoration unit 45b of the receiving control device 40b performs a communication feasibility determination process (see FIG. 11 described later) based on the communication feasibility determination table T1.
[0090] 10 is a diagram showing an example of data in the communication feasibility determination table T1 in each control device of the elevator system 100 according to this embodiment. The communication feasibility determination table T1 stores information indicating whether communication is possible corresponding to the operation mode of the control device 40a on the transmitting side and the operation mode of the control device 40b on the receiving side.
[0091] As shown in FIG. 10, the communication feasibility determination table T1 has a column T11 of "group management controller", a column T12 of "elevator controller", a column T13 of "car controller", and a column T14 of "floor controller" corresponding to the transmitting side. Each of the columns T11 to T14 includes an "NS (non-secure)" column and an "S (secure)" column. The communication feasibility determination table T1 also has a column T15 of "group management controller", a column T16 of "elevator controller", a column T17 of "car controller", and a column T18 of "floor controller" corresponding to the receiving side. Each of the columns T15 to T18 includes an "S (secure)" row and an "NS (non-secure)" row. Each cell of the communication feasibility determination table T1 stores information indicating whether communication is possible or not corresponding to the operation state ("NS" or "S") of the control device 40a of the transmitting side corresponding to the column in which the cell is located, and the operation state of the control device 40b of the receiving side corresponding to the row in which the cell is located. The information indicating whether communication is possible or not includes, for example, "x" indicating that communication is not possible, "o" indicating that communication is possible, and "-" indicating that there is no communication between the controllers, as shown in the figure. Note that the display form of the information indicating whether communication is possible or not is not limited to "x", "o", "-", etc., and may be any display form.
[0092] As a specific example of communication permission determination, for example, communication from a car controller on the transmitting side to an elevator controller on the receiving side is permitted from both the operation modes of the car controller, "NS" and "S" (column T13), to the "NS" (column T16) of the elevator controller. On the other hand, communication from a floor controller on the transmitting side to an elevator controller on the receiving side is permitted from the "NS" (column T14) mode of the floor controller to the "NS" (column T16) mode of the elevator controller. Also, communication from the "S" mode of the floor controller to the "S" mode of the elevator controller is permitted. In other words, communication from a floor controller to an elevator controller is permitted only between the same modes. This is because, for example, communication from a floor controller operating in secure ("S") mode during maintenance work, etc. to an elevator controller operating in non-secure ("NS") mode during normal operation is not permitted. On the other hand, communication from the floor controller to the elevator controller is only permitted in the same mode because the floor controller, which manages input devices such as up and down buttons, does not need to operate in a mode different from that of the elevator controller.
[0093] [Communication availability determination process] Next, the communication feasibility determination process in the receiving control device 40b will be described. Fig. 11 is a flowchart showing the procedure of the communication feasibility determination process in the receiving control device 40b of the elevator system 100 according to this embodiment. The process described below is called and executed as a subroutine in step S83 shown in Fig. 7.
[0094] First, the protected data restoration unit 45b of the receiving control device 40b acquires the operation mode determined in the operation mode determination process of step S82 shown in FIG. 7 and the operation mode of the transmitting control device 40a (step S830).
[0095] Next, the protected data restoration unit 45b judges whether communication is possible based on the communication possibility judgment table T1, the acquired operation mode of the receiving control device 40b, and the operation mode of the transmitting control device 40a (step S831).
[0096] In the process of step S831, if it is determined that communication is permitted (determination of "yes" in step S831), the protected data restoration unit 45b permits the communication (step S832).
[0097] On the other hand, if the protected data restoration unit 45b determines in step S831 that communication is rejected (if the determination in step S831 is "No"), it records the operation mode (step S833). In this process, the protected data restoration unit 45b records the sending ID and receiving ID of the communication packet, the operation mode of the control device 40a on the sending side, and the operation mode of the control device 40b on the receiving side in a communication rejected table T2 (see FIG. 12) described later.
[0098] Next, the protected data restoration unit 45b rejects communication from the control device 40a on the transmitting side (step S834). After the process of step S832 or step S834, the communication permission determination process ends.
[0099] Fig. 12 shows an example of data in the communication refusal table T2 in each controller of the elevator system 100 according to this embodiment. As shown in Fig. 12, the communication refusal table T2 has a column T21 of "sending ID", a column T22 of "operation mode" corresponding to column T21, a column T23 of "receiving ID", and a column T24 of "operation mode" corresponding to column T23.
[0100] The "transmission ID" field T21 stores the transmission ID of the communication packet of the rejected communication. The "operation mode" column T22 stores information indicating the operation mode at the time of the control device 40a on the sending side of the rejected communication. The "reception ID" column T23 stores the reception ID of the communication packet of the rejected communication. The "operation mode" column T24 stores information indicating the operation mode at the time of the control device 40b on the receiving side of the rejected communication.
[0101] [Dummy transmission process] In this embodiment, in order to make the analysis of the communication packet more difficult, in the receiving control device 40b, the communication unit 44b transmits dummy data when it is determined that the receiving device is not the control device itself based on the receiving device identification information (receiving ID) of the received communication packet. Figure 13 is a flowchart showing the procedure of the dummy transmission process in the receiving control device 40b of the elevator system 100 according to this embodiment. The process described below may be executed, for example, after the process of step S50 shown in Figure 5, or may be executed as the process of step S50.
[0102] First, the communication unit 44b of the control device 40b on the receiving side receives a communication packet (step S500).
[0103] Next, the communication unit 44b determines whether the destination of the received communication packet is itself (its own device) (step S501).
[0104] In the process of step S501, when the communication unit 44b determines that the destination of the received communication packet is itself (in the case of "self" determination in step S501), normal processing is executed. Note that the normal processing is the processing of steps S60 to S80 shown in FIG. 5.
[0105] On the other hand, in the process of step S501, when the communication unit 44b determines that the destination of the received communication packet is not itself (its own device) (in the case of "other" determination in step S501), it determines whether or not to execute dummy transmission (step S502). In this process, for example, when the data reception frequency per unit time using random numbers exceeds a predetermined threshold, the communication unit 44b determines to execute dummy transmission, and step S502 is determined as YES. On the other hand, when the data reception frequency per unit time using random numbers is less than a predetermined threshold, the communication unit 44b determines not to execute dummy transmission, and step S502 is determined as NO. Note that the criterion for determining whether or not to execute dummy transmission may be determined based on, for example, the operating state of the elevator system 100. In this case, when the operating state of the elevator system 100 is a previously designated operating state for dummy transmission, the communication unit 44b determines to execute dummy transmission, and step S502 is determined as YES. On the other hand, when the operation state of the elevator system 100 is not a pre-specified operation state for dummy transmission, the communication unit 44b determines not to execute dummy transmission, and the determination in step S502 is NO. Here, the pre-specified operation state for dummy transmission is, for example, a car stopped state, a car accelerating / decelerating state, etc.
[0106] In the process of step S502, if the communication unit 44b determines not to execute dummy transmission (NO in step S502), normal processing is executed.
[0107] On the other hand, if it is determined in the process of step S502 that a dummy transmission is to be performed (YES in step S502), the communication unit 44b stores the transmission ID and reception ID of the received communication packet (step S503).
[0108] Next, the communication unit 44b continues to receive the communication packets (step S504).
[0109] Next, the communication unit 44b determines whether the transmission ID and reception ID of the continuously received communication packet match the stored transmission ID and reception ID (step S505).
[0110] In the process of step S505, if the communication unit 44b determines that the transmission ID and reception ID of the continuously received communication packet match the stored transmission ID and reception ID (YES determination in step S505), it executes transmission of dummy data (step S506). The dummy data is a communication packet that uses the stored transmission ID and reception ID, and the data area (payload section) may be any data (for example, random numbers). There is a transmission pattern for transmitting the dummy data in which the stored reception ID is used as the transmission ID of the dummy data, and the stored transmission ID is used as the reception ID of the dummy data. There is also a transmission pattern for transmitting the dummy data in which the ID of the control device 40b on the receiving side (the ID of the control device itself) is used as the transmission ID of the dummy data, and the stored transmission ID is used as the reception ID of the dummy data.
[0111] On the other hand, in the process of step S505, if the communication unit 44b determines that the transmission ID and reception ID of the continuously received communication packets do not match the stored transmission ID and reception ID (NO in step S505), the communication unit 44b performs the process of step S507. In the process of step S507, the communication unit 44b determines whether the number of times to check whether the transmission and reception IDs match is equal to or greater than a predetermined number registered in advance.
[0112] In the process of step S507, if the communication unit 44b determines that the number of times to check whether the transmission and reception IDs match is less than a predetermined number of times registered in advance (NO in step S507), the process returns to step S504.
[0113] On the other hand, in the processing of step S507, if the communication unit 44b determines that the number of times to check whether the transmission and reception IDs match is equal to or greater than a predetermined number registered in advance (if the judgment is YES in step S507), or after the processing of step S506, the dummy transmission processing is terminated.
[0114] [effect] As described above, in the elevator system 100 according to the present embodiment, in communication between the control devices including 1-to-N and N-to-N multi-drop communication, the control device 40a on the transmitting side dynamically generates sequence data according to the operation state of the elevator system 100. In addition, the control device 40a on the transmitting side changes the format of the communication packet based on the dynamic sequence data according to the operation state of the elevator system 100, and encrypts the communication packet including the payload section and the header section. In addition, the control device 40a on the transmitting side specifies the operation mode of the control device 40b on the receiving side by applying an operation mode mask to the node ID. Therefore, even if the communication packet is illegally intercepted in the multi-drop communication, the elevator system 100 according to the present embodiment can make it difficult to decipher the communication packet. In addition, the elevator system 100 according to the present embodiment can also specify the operation mode of the control device 40b on the receiving side.
[0115] On the other hand, the control device 40b on the receiving side of the elevator system 100 performs only communication that is determined to be permitted based on the operation mode of the control device 40a on the transmitting side, its own specified operation mode, and the communication permission determination table T1 registered in advance. Therefore, the elevator system 100 according to this embodiment can eliminate unauthorized operation mode communication. Furthermore, the control device 40b on the receiving side can make it difficult to analyze the control sequence between the control devices by performing dummy communication when it determines that the destination of the received communication packet is not its own device.
[0116] The present invention is not limited to the above-described embodiment, and various other applications and modifications are possible without departing from the gist of the present invention as set forth in the claims. For example, the above-described embodiment describes the configuration of the elevator system in detail and specifically in order to clearly explain the present invention, and is not necessarily limited to having all of the configurations described. In addition, it is possible to replace part of the configuration of the embodiment described here with the configuration of another embodiment, and further, it is possible to add the configuration of another embodiment to the configuration of one embodiment. In addition, it is also possible to add, delete, or replace part of the configuration of the embodiment with other configurations. In addition, the control lines and information lines shown are those that are considered necessary for the explanation, and not all control lines and information lines in the product are necessarily shown. In reality, it can be considered that almost all components are connected to each other.
[0117] In the above embodiment, an example has been described in which the operation mode of each control device has a non-secure mode and a secure mode, but the present invention is not limited to this, and the operation mode of each control device may be a mode other than the non-secure mode and the secure mode. For example, when the control device is the management terminal 20 or the maintenance terminal 50, the operation mode is an administrator mode, an operator mode, etc. [Explanation of symbols]
[0118] 1...center device, 3...communication controller, 4...group management controller, 5...elevator controller, 6...motor, 8...counterway, 9...rope, 10...car controller, 11...floor controller, 13...operation panel, 14...up and down buttons, 15a, 15b...elevator, 18a, 18b...elevator group, 20...management terminal, 40a, 40b...control device, 41a, 41b...elevator status confirmation unit, 42a, 42b...sequence generation unit, 43a, 43b...protection data generation unit, 44a, 44b...communication unit, 45a, 45b...protection data restoration unit, 50...maintenance terminal, 100...elevator system
Claims
1. An elevator system comprising an elevator and a plurality of control devices related to operation control and maintenance of the elevator, the plurality of control devices being capable of communicating with each other, The control device includes: a sequence generating unit that generates sequence data for changing a format of a communication packet to be transmitted to another control device according to an operating state of the elevator; a protected data generating unit that changes a format of the communication packet and performs encryption in accordance with the sequence data; A protected data restoration unit that restores a communication packet received from another control device. Elevator system.
2. The control device includes an elevator status confirmation unit that confirms the operation status at a predetermined cycle, and a communication unit that transmits and receives data between the elevator status confirmation unit and other control devices.
10. The elevator system of claim 1.
3. The protected data generating unit encrypts a header portion and a payload portion of the format of the communication packet.
10. The elevator system of claim 1.
4. the header portion includes sender identification information, receiver identification information, and data size information, and the payload portion includes communication data; In the control device on the transmitting side, the sequence generation unit divides the payload portion into a plurality of portions, and generates sequence data for changing the order of the transmission side identification information, the reception side identification information, the data size information, and the plurality of portions of the divided payload portion, which are included in the format of the communication packet, according to the operating state.
4. The elevator system of claim 3.
5. The controller has a plurality of operating modes; In the control device on the transmitting side, the protection data generating unit changes the transmitting side identification information by applying an operation mode mask for changing the transmitting side identification information according to the operation mode of the control device on the transmitting side and the operation mode of the control device on the designated receiving side.
5. The elevator system of claim 4.
6. In the control device on the receiving side, the protected data restoration unit decrypts the received communication packet, checks the operation mode mask applied to the sender identification information of the decrypted communication packet, and determines the operation mode of the control device itself based on the checked operation mode mask.
6. The elevator system of claim 5.
7. In the control device on the receiving side, the protected data restoration unit determines whether communication is possible based on the operation mode of the control device on the transmitting side, the determined operation mode of the control device itself, and a communication possibility determination table registered in advance.
7. The elevator system of claim 6.
8. The plurality of operating modes are a non-secure mode and a secure mode.
6. The elevator system of claim 5.
9. In the control device on the transmitting side, the protection data generation unit When the operation mode of the own device is the non-secure mode, the operation mode mask is not applied; When the operation mode of the own device is the secure mode, the operation mode mask is applied to change the sender identification information.
9. The elevator system of claim 8.
10. In the control device on the receiving side, the communication unit transmits dummy data when it is determined that the destination is not the control device itself based on the receiving side identification information of the received communication packet.
3. The elevator system of claim 2.
11. A communication packet analysis countermeasure method in an elevator system including an elevator and a plurality of control devices related to operation control and maintenance of the elevator, the plurality of control devices being capable of communicating with each other, comprising: generating sequence data for changing a format of a communication packet to be transmitted to another control device according to an operating state of the elevator; changing a format of the communication packet and encrypting the packet according to the sequence data; and restoring the communication packets received from the other control devices. Countermeasures against communication packet analysis.
Citation Information
Patent Citations
Method and elevator group configured for establishing a secure data communication between a plurality of controllers in each of a plurality of elevators of the elevator group
EP3626664A1
Data transmission system for elevator
JP2006151582A
Method for data transfer between automobile electronic control devices
JP2017050795A
Communication packet obfuscation device, elevator system, and communication packet obfuscation method
JP2022066665A
System and method to prevent the use of pirate products in an elevator control
US20140284143A1