Elevator system and firmware transmission method

Abstract

To provide an elevator system capable of changing a controller order to update a firmware according to an elevator operating state.SOLUTION: A master controller 30 provided in an elevator system 100 generates a transmission order of a firm image 31 to multiple sub-controllers 40 according to an operational state of an elevator 15, and transmits a packet 50 including the firm image 31 and the transmission order to the sub-controller 40 with a higher transmission priority. The sub-controller 40 with a higher transmission priority receives the packet 50 from the master controller 30 to update the firm image 31, and transmits the packet 50 to the sub-controller 40 with a next transmission priority.SELECTED DRAWING: Figure 3

Description

[Technical field]

[0001] The present invention relates to an elevator system and a firmware transmission method. [Background technology]

[0002] Conventionally, an elevator system 100 is configured with a plurality of controllers. A system is known in which any one controller updates the programs of the plurality of controllers in a 1:N configuration.

[0003] Patent document 1 states that "the server distributes update data including difference information between the pre-update version of the control program on the representative elevator and the latest version of the control program to be updated to a predetermined representative elevator among multiple elevators via a communication line, and the representative elevator updates its own control program based on the update data received from the server and transmits the update data via the network to the elevator to which the data should be transferred next in accordance with a predetermined transfer order."

[0004] Patent document 2 states that "the transmission procedure control means calculates the elevator stop time from the transmission time required to transmit the update operation control program to the multiple control devices via the transmission path and the rewrite time required for the multiple control devices to rewrite it to the update operation control program, and selects the order in which to transmit the update operation control program to the multiple control devices based on the calculated stop time." [Prior art documents] [Patent documents]

[0005] [Patent Document 1] Patent No. 4963292 [Patent Document 2] Patent No. 5072411 Summary of the Invention [Problem to be solved by the invention]

[0006] As described in Patent Document 1, when one representative elevator is predefined and the transfer order of update data is predefined, update data cannot be updated from elevators other than the representative elevator. When a malfunction occurs in the representative elevator, data update processing may not be possible if the processing load of the representative elevator is high. Furthermore, since update processing can only be performed in a predefined order, an elevator can only complete update processing when all elevators in the predefined order are able to perform update processing. For example, even if only one elevator malfunctions or is undergoing maintenance, if the control processing is highly loaded, the elevator will not accept update processing, resulting in issues such as delays in communication processing or communication interruptions.

[0007] Patent Document 2 also describes a method for calculating the elevator stop time based on the transmission time and the rewrite time. However, the program capacity, communication device performance, and storage device rewrite performance must meet predetermined conditions. As with the technology described in Patent Document 1, this technology may not be suitable for actual operating conditions.

[0008] The present invention has been made in consideration of the above circumstances, and has an object to change the order in which controllers update firmware depending on the operating status of an elevator. [Means for solving the problem]

[0009] The elevator system according to the present invention includes a master controller that transmits firmware, and a sub-controller that receives the firmware and updates the firmware. The master controller generates a firmware transmission order for a plurality of sub-controllers according to the operation state of the elevator, and transmits first transmission data including the firmware and the transmission order to the sub-controller whose transmission order has priority. The sub-controller whose transmission order has priority receives the first transmission data from the master controller, updates the firmware, and transmits the first transmission data to the sub-controller whose transmission order has the next priority. Effect of the Invention

[0010] According to the present invention, the firmware transmission order is generated according to the elevator operation status, so there is no need to determine the firmware transmission order in advance. Problems, configurations and effects other than those described above will become apparent from the following description of the embodiments. [Brief description of the drawings]

[0011] [Figure 1] 1 is a diagram showing an example of the overall configuration of an elevator system according to an embodiment of the present invention; [Diagram 2] FIG. 2 is a block diagram showing an example of a hardware configuration of a controller according to an embodiment of the present invention. [Diagram 3] 1 is a block diagram showing an example of a basic configuration of a packet communication system including a master controller and a sub-controller according to an embodiment of the present invention. [Figure 4] Fig. 4A is a diagram showing an example of a basic configuration of a packet according to an embodiment of the present invention, Fig. 4B is a diagram showing an example of a packet generated by a master controller and each sub-controller; [Diagram 5] 10 is a flowchart illustrating an example of normal communication processing in the packet communication system according to an embodiment of the present invention. [Figure 6]10 is a flowchart illustrating an example of processing of a sub-controller according to an embodiment of the present invention. [Figure 7] 10 is a diagram illustrating an example of a packet configuration of an abnormality notification message according to an embodiment of the present invention. FIG. [Figure 8] 10 is a flowchart illustrating an example of a process in which a subcontroller according to an embodiment of the present invention notifies the occurrence of an abnormality. [Figure 9] 10 is a flowchart showing an example of an abnormality handling process performed by a sub-controller according to an embodiment of the present invention when packet transmission fails. [Figure 10] 11 is a flowchart illustrating an example of a process for skipping a subcontroller in which a communication error has occurred and continuing firmware image update processing according to an embodiment of the present invention. [Figure 11] FIG. 2 is a block diagram showing an example of a tree structure including an elevator controller and a plurality of floor controllers according to an embodiment of the present invention. [Figure 12] 13 is a flowchart illustrating an example of a process for generating a sequence according to the presence or absence of a call registration for a floor according to an embodiment of the present invention. [Figure 13] 13 is a flowchart illustrating an example of a process for generating an order according to the number of visitors on a floor according to an embodiment of the present invention. [Figure 14] FIG. 2 is a block diagram showing an example of a tree structure including a group management controller and a plurality of elevator controllers according to an embodiment of the present invention. [Figure 15] 10 is a flowchart illustrating an example of a process for generating a sequence according to the number of assigned elevator calls in accordance with an embodiment of the present invention. [Figure 16] 1 is a block diagram showing an example of a tree structure including a communication controller and a plurality of group management controllers according to an embodiment of the present invention. [Figure 17] 11 is a flowchart showing an example of a process for generating the number of calls to be assigned to an elevator and a sequence according to the status of the assignment process in one embodiment of the present invention. [Figure 18]10 is a flowchart illustrating an example of a process in which a group management controller according to an embodiment of the present invention determines whether to reboot in order to apply a firmware image. [Figure 19] 10 is a flowchart illustrating an example of a process in which an elevator controller according to an embodiment of the present invention determines whether to reboot in order to apply a firmware image. [Figure 20] 11 is a flowchart illustrating an example of a process in which a floor controller according to an embodiment of the present invention reboots to apply a firmware image. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0012] Hereinafter, an example of an elevator system and a firmware transmission method according to 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 denoted by the same reference numerals, and duplicated descriptions will be omitted. Note that the present invention is not limited to the following embodiment.

[0013] [One embodiment] FIG. 1 is a diagram showing an example of the overall configuration of an elevator system 100 according to one embodiment of the present invention. In FIG. 1, in order to simplify the explanation of the elevator system 100, detailed components of one elevator 15 are illustrated, and detailed components of the other elevators 15 are not illustrated.

[0014] The elevator system 100 has a center 1 that is installed, for example, remotely from the elevators 15 in order to manage a plurality of elevators 15, monitor operation, and perform maintenance. The elevator system 100 also has a communication controller 3, a group management controller 4, an elevator controller 5, a car controller 10, a floor controller 11, and a maintenance terminal 19.

[0015] The center 1 is connected to a communication controller 3 via a communication network 2, which may be a wired or wireless closed circuit network such as a dedicated line, or a public line such as the Internet. The communication controller 3 is a controller responsible for communications for performing data transfer, remote operation, and remote maintenance between the center 1 and the elevators. The communication controller 3 is connected to the group management controller 4 via a communication path 17. The communication controller 3 controls communications with multiple group management controllers 4 which control the operations of multiple elevator controllers 5.

[0016] The group management controller 4 controls the operation of multiple elevator controllers 5, which in turn control the operation of elevators 15. The group management controller 4 collectively controls the operation of the multiple elevators 15 as an elevator group 18. The group management controller 4 is connected to the multiple elevator controllers 5 via a communication path 16.

[0017] The elevator 15 includes an elevator controller 5, a car controller 10 and a floor controller 11.

[0018] The elevator controller 5 controls the operation of the elevator 15, and provides users with an up and down movement service by controlling the up and down movement and stopping of the car 7. To provide this service, the elevator controller 5 controls the motor 6, which is the main engine, to operate the movement of the rope 9 connecting the car 7 and the counterweight 8. The elevator controller 5 is connected to one car controller 10 and multiple floor controllers 11 via a communication path 12.

[0019] The car controller 10 opens and closes the car doors in response to the operation by the user of the destination floor button and the door opening / closing button 13 installed in the car 7, and notifies the elevator controller 5 of changes in the car status.

[0020] A floor controller 11 is provided for each floor where the elevator 15 ascends and descends, and reports the floor status to the elevator controller 5. For example, the floor controller 11 monitors the operation status of the up and down buttons 14 installed on each floor by users at each floor, and reports changes in the floor status to the elevator controller 5. Some elevator systems are equipped with a destination floor registration device, instead of the up and down buttons 14, that allows passengers to register their destination floor before getting into the car.

[0021] As described with reference to Fig. 1, elevator system 100 is a system in which a tree structure in which multiple controllers are configured in a 1:N relationship is arranged in multiple hierarchical stages. In addition, when multiple controllers of the same type exist, it is also possible to configure the tree structure with any one of the controllers as the root of the tree structure and the remaining controllers as leaves of the tree structure.

[0022] The center 1 holds firmware used by each controller in a storage unit (not shown) as a firmware image 31 (see FIG. 3 described later). The center 1 can transmit firmware to any controller via the communication network 2, communication paths 12, 16, and 17, and various controllers connected to the communication paths.

[0023] A maintenance terminal 19 connected to the communication network 2 can copy firmware from the center 1. After copying the firmware, the maintenance terminal 19 can be connected to any controller, thereby outputting the firmware held by the maintenance terminal 19 to the connected controller. Therefore, the maintenance terminal 19 can cause the controller connected to the maintenance terminal 19 to hold the firmware. In addition, a controller that holds the firmware can update its own firmware or transmit the firmware to other controllers.

[0024] The method by which each controller updates firmware includes a full update using a full firmware image, and a partial difference update using a difference image between old and new firmware.

[0025] <Controller hardware configuration example> Next, the hardware configuration of each controller 20 provided in the elevator system 100 will be described with reference to Fig. 2. Here, the hardware configuration of the computers provided in the communication controller 3, the group management controller 4, the elevator controller 5, the car controller 10, and the floor controller 11 will be described. These are collectively referred to as the controller 20.

[0026] FIG. 2 is a block diagram showing an example of the hardware configuration of the controller 20. The controller 20 includes an MPU (Micro Processing Unit) 22, a ROM (Read Only Memory) 23, a RAM (Random Access Memory) 24, and a communication interface 25, all of which are connected to a system bus 21. Note that a CPU (Central Processing Unit) is a higher-level concept of a computing device similar to the MPU.

[0027] The MPU 22, ROM 23, and RAM 24 constitute a processing unit. In this embodiment, a firmware image 31 (see FIG. 3 described later) which is binary data of program codes for implementing each of the relevant functions is recorded in the ROM 23, and the MPU 22 reads the firmware image 31 from the ROM 23, loads it into the RAM 24, and executes the program codes. The MPU 22 may also directly read the program codes from the ROM 23 and execute the program codes as they are.

[0028] Variables, parameters, etc. that are generated during the execution of processing performed by the MPU 22 are temporarily written to the RAM 24, and these variables, parameters, etc. are read out from the MPU 22 as appropriate.

[0029] The controllers 20 can transmit and receive data between the multiple controllers 20 through the communication interface 25. Examples of communication paths connecting the controllers 20 include a multi-drop serial communication device such as RS-485, a wired communication path such as Ethernet (registered trademark) that provides multiple topologies, a Local Area Network (LAN), a Wide Area Network (WAN), and a wireless communication path such as a Radio Area Network (RAN). The controllers 20 can transmit and receive data between devices using wireless communication such as Wi-Fi (registered trademark) or infrastructure wireless communication.

[0030] In order to deal with problems that occur when data is rewritten to the ROM 23, the controller 20 may be equipped with a plurality of ROMs 23. In this configuration, the current firmware image 31 (one example of firmware) is recorded in one ROM 23, and a new firmware image 31 is recorded in the other ROM 23. Even if a problem occurs when rewriting the new firmware image 31 to the latter ROM 23, the current firmware image 31 remains in the former ROM 23, so that the current state can be restored. In addition, when there are a plurality of ROMs 23, the controller 20 selects the ROM 23 in which the desired firmware image 31 is stored and starts it up.

[0031] <Basic system configuration of master controller and sub-controller> Next, a basic system configuration of a master controller and a sub-controller according to an embodiment of the present invention will be described based on the embodiment of the elevator system 100 shown in FIG. FIG. 3 is a block diagram showing an example of a basic configuration of a packet communication system 200 including a master controller 30 and a sub-controller 40. As shown in FIG.

[0032] The packet communication system 200 is one form of the elevator system 100 including a master controller 30 that transmits a firmware image 31 and a sub-controller 40 that receives the firmware image 31 and updates the firmware image 31. As shown in FIG. 1, the elevator system 100 is a large-scale system in which a tree structure in which a plurality of controllers are connected in a 1:N ratio is multiplexed. Here, a packet communication system 200 in which one controller 20 is the master controller 30 and N controllers 20 are the sub-controllers 40 will be described. In addition, in the packet communication system 200, the controllers 20 in the same hierarchy or different hierarchy have a master-sub relationship. The master-sub relationship may be not only between adjacent hierarchies, but also across one or more hierarchies. For example, it is also possible to use one group management controller 4 as the master controller 30 and multiple floor controllers 11 as the sub-controllers 40 across the elevator controller 5.

[0033] The master controller 30 generates a transmission order of the firmware image 31 for the multiple sub-controllers 40 according to the operating state of the elevator 15. Then, the master controller 30 transmits a packet 50 including the firmware image 31 and the transmission order to the sub-controller 40 having the priority in the transmission order. The master controller 30 is connected to the sub-controllers 40 via a communication path 37. The sub-controller 40 to which the packet 50 is directly transmitted from the master controller 30 is often the first in the transmission order. However, if an abnormality occurs in the sub-controller 40 receiving the packet 50, the master controller 30 may transmit the packet 50 preferentially to the sub-controller 40 having the next transmission order after the abnormal sub-controller 40. In this way, the master controller 30 transmits the packet 50 to the sub-controller 40 having the priority in the transmission order, so that the sub-controller 40 having the priority in the transmission order can receive the packet 50. Also, the sub-controller 40 that receives the packet 50 transmits the packet 50 to the sub-controller 40 having the next priority in the transmission order, so that the packet 50 is transferred to multiple sub-controllers 40. Therefore, compared to the case where the master controller 30 distributes the packets 50 to a plurality of sub-controllers 40 all at once, it is possible to transmit the packets 50 to each sub-controller 40 reliably.

[0034] The master controller 30 includes a firmware image 31, an image dividing unit 32, an operation status acquiring unit 33, a sequence generating unit 34, a packet generating unit 35, and a master communication unit 36.

[0035] The firmware image 31 is an entity of firmware. Firmware is an example of a program that controls the operation of the controller 20. The firmware image 31 is stored in the ROM 23 or the like provided in the master controller 30.

[0036] The image dividing unit 32 is used as an example of a firmware dividing unit that divides the firmware image 31. Since the image dividing unit 32 divides the firmware image 31, the amount of binary data 57 (see FIG. 4A described later) of the packet 50 transmitted to the sub-controller 40 in each communication is reduced. The communication efficiency of the communication path 37 between the master controller 30 and the sub-controller 40 can be improved.

[0037] The operation status acquisition unit 33 acquires the operation status of the elevator. The operation status of the elevator 15 includes, for example, the car status, the call allocation status, etc. The operation status acquisition unit 33 can acquire the operation status from the car controller 10, the floor controller 11, etc.

[0038] The sequence generation unit 34 generates the transmission sequence of the sub-controller 40, which is the transmission destination of the firmware image 31 divided by the image division unit 32, according to the operation status of the elevator 15 acquired by the operation status acquisition unit 33. Note that if the file size of the firmware image 31 is sufficiently small, the firmware image 31 may be transmitted to the sub-controller 40 without being divided.

[0039] The packet generator 35 (an example of a first transmission data generator) generates a packet 50 for the master controller 30 to transmit the firmware image 31 to the sub-controller 40 according to the transmission order generated by the order generator 34. The packet 50 is used as an example of the first transmission data. As shown in FIG. 4 described later, the packet generator 35 generates the packet 50 including information (source 51) for identifying the master controller 30 that is the source of the packet 50, information (destination 52) for identifying the sub-controller 40 that is the destination of the packet 50, the transmission order (transmission order 53), the construction order (number 56) of the divided firmware image 31, and the divided firmware image 31 (binary data 57).

[0040] The master communication unit 36 ​​transmits the packet 50 generated by the packet generation unit 35 to the sub-controller 40 that has the first priority in the transmission order generated by the order generation unit 34.

[0041] The sub-controller 40 having priority in the transmission order receives a packet 50 from the master controller 30, updates the firmware image 31, and transmits the packet 50 to the sub-controller 40 having the next priority in the transmission order. This sub-controller 40 includes a sub-communication unit 41, a packet interpretation unit 42, a destination extraction unit 43, a packet generation unit 44, an image construction unit 45, and a firmware image storage unit 46.

[0042] The sub-communication unit 41 is connected to the communication path 37. The sub-communication unit 41 is used as an example of a second communication unit that receives the packet 50 from the master controller 30 or another sub-controller 40 that is the source of the packet 50 via the communication path 37.

[0043] The packet interpretation unit 42 is used as an example of a data interpretation unit that interprets the packet 50 received by the sub-communication unit 41. The interpretation of the packet 50 is a process of extracting data from the packet 50 according to a specified packet format and outputting the data to a predetermined output destination. The divided image data of the firmware image 31 interpreted by the packet interpretation unit 42 is output to the image construction unit 45. In addition, the interpretation result of the packet 50 by the packet interpretation unit 42 is output to the destination extraction unit 43.

[0044] The destination extraction unit 43 extracts the sub-controller 40 that is the next destination of the packet 50 based on the transmission order interpreted by the packet interpretation unit 42 .

[0045] The packet generator 44 is used as an example of a second transmission data generator that generates a packet 50 (an example of second transmission data) for transmitting the firmware image 31 to the sub-controller 40 that is the next transmission destination of the packet 50. For example, the packet generator 44 generates a new packet 50 based on the interpretation result of the packet 50 by the packet interpreter 42 and the transmission order of the remaining sub-controllers 40 that are the transmission destinations of the packet extracted by the transmission destination extractor 43. The divided image data of the firmware image 31 included in the packet 50 generated by the packet generator 44 is basically the same as the divided image data of the firmware image 31 included in the packet 50 received by the sub-communication unit 41. When the packet generator 44 generates the packet 50, the sub-communication unit 41 transmits the packet 50 to the sub-controller 40 that is the next transmission destination based on the transmission order stored in the packet 50.

[0046] The image construction unit 45 is used as an example of a firmware construction unit that constructs the divided firmware images 31 interpreted by the packet interpretation unit 42 into the original firmware image 31 in accordance with the construction order. The image construction unit 45 has a buffer (not shown) that stores the divided firmware images 31 received from the packet interpretation unit 42. Then, when a sufficient amount of the divided firmware images 31 is stored in the buffer, the firmware image 31 is reconstructed.

[0047] The firmware image storage unit 46 stores the firmware image 31 constructed by the image construction unit 45. The firmware image 31 updated by the sub-controller 40 is read from the firmware image storage unit 46. The firmware image storage unit 46 may manage a plurality of firmware images 31 by generation for each version. Therefore, if an update fails, it is possible to revert to the previous firmware image 31.

[0048] By repeatedly performing processing in each part of the sub-controller 40, the firmware image 31 is transmitted based on the most efficient transmission order of the sub-controller 40 according to the operating status of the elevator 15.

[0049] When the elevator system 100 is in a standby state during a late night operation, for example, the order of the controllers 20 has little effect on the update process. For this reason, the packet generator 44 may determine the order in which the packets 50 are transmitted to the sub-controllers 40 by ascending / descending order according to the number of floors, the order of the serial numbers assigned to the controllers 20, or by using random numbers.

[0050] The relationship between the master controller 30 and the sub-controllers 40 may be determined by a user who uses the maintenance terminal 19. Alternatively, the controller that downloaded the firmware image 31 from the maintenance terminal 19 may be determined as the master controller 30, and the other controllers may be determined as the sub-controllers 40 automatically.

[0051] <Basic packet structure> Next, the basic structure of the packet 50 generated in the packet communication system 200 shown in FIG. 3 will be described with reference to FIG. FIG. 4 is a diagram showing an example of a basic structure of a packet 50. As shown in FIG.

[0052] FIG. 4A is a diagram showing an example of the internal structure of a packet 50. As shown in FIG. Packet 50 is composed of data of source 51 of packet 50, data of destination 52 of packet 50, data of transmission order 53 of packet 50, image data 54 divided from firmware image 31, and check data 55 for checking data inconsistency of packet 50.

[0053] The image data 54 is one of a plurality of image data obtained by dividing the firmware image 31 by the image dividing unit 32 shown in Fig. 3. Therefore, the image data 54 is composed of a number 56 indicating the construction order in which the firmware image 31 is divided, and binary data 57 which is the substance of the divided image. By defining the structure of the packet 50 in this manner, the master controller 30 and the sub-controllers 40 can transmit the firmware image 31 in the order of the plurality of sub-controllers 40 generated by the order generating unit 34. Therefore, each sub-controller 40 can update the firmware image 31 in the order in which it was received.

[0054] The image data 54 or the binary data 57 includes identification data indicating which of the communication controller 3, the group management controller 4, the elevator controller 5, and the floor controller 11 the firmware corresponds to. Therefore, when the controller is the master controller 30, the image construction unit 45 mounted in each controller can identify firmware intended for another controller by the identification data.

[0055] FIG. 4B is a diagram showing an example of the configuration of a packet 50 generated by the master controller 30 and each sub-controller 40. Here, an elevator 15 is assumed to be installed in a four-story building. The master controller 30 corresponds to the elevator controller 5, and the sub-controller 40 corresponds to the floor controller 11. In addition, a case is shown in which a transmission order 53 is generated in the order of 4th floor - 2nd floor - 3rd floor - 1st floor. Here, the "1" stored in the number 56 indicates that this is the first binary data of the divided firmware image 31.

[0056] The master controller 30 generates a packet 50(1) by setting its own ID number "0" in the source 51, setting the first ID number "4" in the transmission order 53 in the destination 52, and setting the order "2-3-1" after the ID number "4" in the transmission order 53. Therefore, the packet 50(1) is transmitted to the floor controller 11 on the fourth floor, which has the highest transmission order 53.

[0057] When the floor controller 11 on the fourth floor receives the packet 50(1), it sets its own ID number "4" in the source 51, sets the first ID number "2" in the transmission order 53 in the destination 52, and generates a packet 50(2) in which the transmission order 53 is set to "3-1", which is a number after the ID number "2". Therefore, the packet 50(2) is transmitted to the floor controller 11 on the second floor, which has the highest transmission order 53.

[0058] When the floor controller 11 on the second floor receives the packet 50(2), it sets its own ID number "2" in the source 51, sets the first ID number "3" in the transmission order 53 in the destination 52, and generates a packet 50(3) in which the transmission order 53 is set to "1", which is after the ID number "3". Therefore, the packet 50(3) is transmitted to the floor controller 11 on the third floor, which has the highest transmission order 53.

[0059] When the floor controller 11 on the third floor receives packet 50(3), it sets its own ID number "3" in source 51, sets the first ID number "1" in transmission order 53 in destination 52, and, because it is last in the transmission order, generates packet 50(4) with no transmission order 53. As a result, packet 50(4) is transmitted to the floor controller 11 on the first floor, which has the highest transmission order 53.

[0060] By structuring the packet 50 in this way, the packet 50 transmitted from the master controller 30 is transmitted through the multiple sub-controllers 40 in order based on a transmission order 53 according to the operation status of the elevator 15. This reduces the processing load on the master controller 30, and enables the sub-controllers 40 to efficiently execute processing based on the operation status of the elevator 15. Furthermore, the communication method according to this embodiment does not occupy the network as compared to broadcasting, in which packets are simultaneously distributed from the master controller 30 to the multiple sub-controllers 40. Furthermore, it becomes easier for the master controller 30 to manage the allocation of the transmission order of the firmware images 31.

[0061] In addition, when many controllers 20 are in standby state, for example, late at night when usage is low, there is little difference in the state of the controllers 20 depending on the operating state. For this reason, the transmission order 53 may be simply in order of the IDs of the controllers 20 or in order of the floor numbers.

[0062] Furthermore, when it is assumed that any subcontroller 40 communicates directly with the master controller 30, an item indicating the source of the packet corresponding to the master controller 30 may be added to the packet in addition to the source 51 and destination 52. Communication from the subcontroller 40 to the master controller 30 is performed, for example, to notify the master controller 30 of the operation status of the elevators 15 within the range managed by the subcontroller 40. Communication from the subcontroller 40 to the master controller 30 is also used to notify the status of the elevators 15 during normal operation. It is also used for the subcontroller 40 to send malfunction information directly to the master controller 30 without tracing back through multiple subcontrollers 40.

[0063] <Normal communication process> Next, the process (one example of a firmware transmission method) in the packet communication system 200 shown in FIG. 3 will be described with reference to the flowcharts in FIG. 5 and subsequent figures. Fig. 5 is a flowchart showing an example of normal communication processing of the packet communication system 200. Fig. 5 shows a process in which the master controller 30 distributes the firmware image 31 to all the sub-controllers 40 by dividing the firmware image 31 and transmitting packets 50 in the order in which they were generated based on the operating status of the elevator 15.

[0064] First, the image division unit 32 (see FIG. 3) of the master controller 30 divides the firmware image 31 into sizes suitable for communication (S1). When dividing the firmware image 31, the image division unit 32 also generates a number 56 (see FIG. 4), for example in ascending order, so that the division order can be determined. Note that the number of the last divided firmware image 31 may be a special end number. If this end number is shared by the controller 20 on the receiving side of the packet 50, the controller 20 can receive all the divided firmware images 31 to the end, even if there are many of them.

[0065] Next, the operation status acquisition unit 33 acquires the operation status of the elevator 15 (S2). Next, the sequence generation unit 34 generates the sequence of the sub-controllers 40 that communicate the divided firmware images 31 based on the operation status (S3). Next, the packet generation unit 35 generates a packet 50 to be transmitted to the next sub-controller 40 according to the sequence generated by the sequence generation unit 34 (S4). Then, the master communication unit 36 ​​transmits the generated packet 50 to the next sub-controller 40 according to the sequence (S5).

[0066] The master communication unit 36 ​​checks whether the transmission of the packet 50 was successful (S6). If the transmission of the packet 50 has failed (NO in S6), the master communication unit 36 ​​ends this process after receiving an abnormality notification from the sub-controller 40 (S7). After a certain period of time, the master controller 30 re-executes this process to re-send the packet 50.

[0067] On the other hand, if the transmission of the packet 50 is successful (YES in S6), the master communication unit 36 ​​checks whether or not there is any remaining divided firmware image 31 (S8). If there is any remaining divided firmware image 31 (YES in S8), the master controller 30 returns to step S1 and repeats the process. If there is no remaining divided firmware image (NO in S8), the master controller 30 ends this process.

[0068] Next, the processing of the sub-controller 40 will be described with reference to FIG. FIG. 6 is a flowchart showing an example of the process of the sub-controller 40.

[0069] First, the sub-communication unit 41 of the sub-controller 40 receives a packet 50 from the master controller 30 or the immediately preceding sub-controller 40 (S11).

[0070] Next, the packet interpretation unit 42 interprets the packet 50 received by the sub-communication unit 41 (S12), and identifies the source 51, the destination 52, the transmission order 53, the divided image data 54, and the check data 55. A detailed example of the process of interpreting the packet 50 in step S12 is shown in Fig. 8, which will be described later.

[0071] Next, the destination extraction unit 43 extracts the next destination from the transmission order 53 identified by the packet interpretation unit 42 (S13). The image construction unit 45 also sequentially constructs the firmware image 31 from the divided image data 54 (S14). The processes of steps S13 and S14 are performed in parallel, but may be performed sequentially.

[0072] Next, destination extraction unit 43 checks in transmission order 53 whether or not there is a next destination to which divided image data 54 is to be sent (S15).

[0073] If a next destination exists (YES in S15), the packet generation unit 44 generates a packet 50 in which the destination 52 is changed to the next sub-controller 40 (S16). The sub-communication unit 41 transmits the generated packet 50 to the next sub-controller 40 (S17), and checks whether the transmission of the packet 50 was successful (S18).

[0074] If the transmission of the packet 50 fails (NO in S18), the sub-controller 40 performs an abnormality handling process (S19) shown in Fig. 7 or Fig. 10, which will be described later. Step S19 has different destinations as shown in Fig. 9 and Fig. 10, which will be described later.

[0075] On the other hand, if the transmission of the packet 50 is successful (YES in S18), or if it is determined in step S15 that there is no next sub-controller 40 to which the divided image data 54 can be sent (NO in S15), the packet interpretation unit 42 checks whether the image data 54 is the end of the firmware image 31 (S20).

[0076] If it is the end of the firmware image 31 (YES in S20), the packet interpretation unit 42 checks whether construction of the firmware image 31 by the image construction unit 45 has been completed, and then the sub-controller 40 ends this process. On the other hand, if it is not the end of the firmware image 31 (NO in S20), the process returns to step S11, and the sub-controller 40 repeats the process.

[0077] The sub-communication unit 41 may store the transmission source 51 interpreted by the packet interpretation unit 42 every time the sub-communication unit 41 receives a packet 50 including divided image data 54. In this case, the sub-communication unit 41 can communicate with the master controller 30 by tracing the order of the packets 50 in reverse. For example, the sub-communication unit 41 can notify the master controller 30 of the occurrence of a malfunction in the sub-controller 40.

[0078] 5 and 6, the master controller 30 can update the firmware image 31 without distributing the firmware image 31 to all of the sub-controllers 40 by itself, simply by sending a packet 50 to the first sub-controller 40 in the order according to the operation status of the elevator 15. The sub-controllers 40 communicate the firmware image 31 to the other sub-controllers 40 in the order generated by the master controller 30. In this way, the master controller 30 can update the firmware images 31 of all of the sub-controllers 40 by combining efficient communication processes.

[0079] In addition, when the size of the firmware image 31 is small, or when the data size of the differential image in the differential update is small, the packet 50 may be communicated without dividing the image. In this case, the processing of the master controller 30 and the sub-controller 40 may be completed in one communication.

[0080] <Notification of communication errors> Next, a process in which the sub-controller 40 notifies the master controller 30 of the occurrence of a communication abnormality when such an abnormality occurs will be described with reference to FIGS.

[0081] First, a configuration example of an abnormality notification message used in this process will be described. FIG. 7 is a diagram illustrating an example of a packet configuration of an abnormality notification message.

[0082] A sub-controller 40 that detects a communication abnormality when receiving a packet 50 transmits an abnormality notification message to the preceding sub-controller 40 that is the source of the packet 50. As shown in Fig. 7, this abnormality notification message is made up of data of the source 51, data of the destination 52, data of the image data 54, and check data 55. Note that no data is stored in the transmission order 53.

[0083] The image data 54 is composed of a command 58 and command data 59 corresponding to the command 58. In this embodiment, the command 58 stores an "abnormality occurrence notification command," and the command data 59 stores the ID of the controller 20 in which the communication abnormality has occurred.

[0084] 8 is a flowchart showing an example of a process in which the sub-controller 40 notifies the occurrence of an abnormality. Here, a detailed example of the packet interpretation process shown in step S12 in FIG.

[0085] First, the packet interpretation unit 42 of any controller 20 interprets the packet 50 and checks the data of the transmission order 53 (S21). Next, the packet interpretation unit 42 checks whether the ID of the sub-controller 40 of the transmission destination is stored in the data of the transmission order 53 in the transmission order of the packet 50 (S22). If the ID of the sub-controller 40 is stored in the data of the transmission order 53 in the transmission order (YES in S22), the process ends and proceeds to step S13 in FIG.

[0086] On the other hand, if the ID of the sub-controller 40 is not stored in the transmission order in the data of the transmission order 53 (NO in S22), an abnormality has occurred during the update of the firmware image 31 by the image construction unit 45. In this case, the sub-communication unit 41 transmits data including information about the abnormality to the master controller 30 in the reverse order of the transmission order. Therefore, the master controller 30 can immediately grasp the abnormality that has occurred in the sub-controller 40 and take action such as issuing an instruction to stop transmitting packets 50.

[0087] 7 and command data 59 corresponding to the command 58 from the image data 54 (S23).Then, the packet interpretation unit 42 generates an abnormality notification message in which the source 51 is the sub-controller 40 that executes this process itself and the destination 52 is replaced with the previous sub-controller 40 that transmitted the packet 50 (S24).

[0088] The sub-communication unit 41 of the sub-controller 40 transmits an abnormality notification message to the sub-controller 40 that is the first in the transmission order (S25). After that, the image construction unit 45 erases the firmware image 31 that has been constructed so far (S26) and ends the process. Therefore, the processes after steps S13 and S14 in FIG. 6 are not performed.

[0089] 7, the sub-controller 40 can erase the firmware image 31 in the middle of processing when a communication abnormality occurs. Also, the sub-controller 40 can notify the master controller 30 of an abnormality notification message.

[0090] <Communication processing during abnormality> Next, using Figures 9 and 10, we will explain the processes that are performed when a sub-controller 40 that receives a packet 50 erases the image that is being constructed in the event of an abnormality in which a communication error occurs, and when the sub-controller 40 in which a communication error has occurred is skipped.

[0091] <First abnormality notification process> Fig. 9 is a flow chart showing an example of anomaly handling process performed when the sub-controller 40 fails to transmit the packet 50. In this anomaly handling process, when the sub-controller 40 fails to transmit the packet 50, the sub-controller 40 deletes the image data 54 that has been transmitted to the destination sub-controller 40. Note that the process before step S17 is as shown in Fig. 6, and therefore a detailed description thereof will be omitted.

[0092] 6, the sub-communication unit 41 of the arbitrary controller 20 transmits the generated packet 50 to the next controller 20 (S17). The arbitrary controller 20 may be, for example, the communication controller 3, the group management controller 4, the elevator controller 5, the car controller 10, or the floor controller 11. Next, the sub-communication unit 41 checks whether the transmission of the packet 50 has been successful (S18).

[0093] If the transmission of the packet 50 is successful (YES in S18), the controller 20 proceeds to the process of step S20 and subsequent steps in FIG. 6. On the other hand, if the transmission of the packet 50 fails (NO in S18), an abnormality occurs during the update of the firmware image 31 by the image construction unit 45. In this case, the sub-communication unit 41 transmits data including information about the abnormality to the master controller 30 in the reverse order of the transmission order. This allows the master controller 30 to immediately grasp the abnormality that has occurred in the sub-controller 40 and to take action such as issuing an instruction to stop the transmission of the packet 50. Furthermore, if an abnormality occurs during the update of the firmware image 31, the sub-controller 40 erases the firmware image 31 that the image construction unit 45 has constructed. This prevents the sub-controller 40 from performing an update process using an inaccurate firmware image 31.

[0094] For example, the packet generation unit 44 of the controller 20 generates an abnormality notification message packet 50 for notifying the previous controller 20 of a communication abnormality (S31). Next, the sub-communication unit 41 transmits the abnormality notification message packet 50 to the previous controller 20 (S32). Then, the image construction unit 45 erases the firmware image 31 that has been constructed so far (S33), and ends this process.

[0095] <Second abnormality notification process> FIG. 10 is a flowchart showing an example of a process for skipping the sub-controller 40 in which a communication error has occurred and continuing the update process of the firmware image 31. In this abnormality handling process, the transmission of the packet 50 is preferentially performed to the sub-controller 40 in which no communication error has occurred. For example, it is assumed that the controller 20 is the sub-controller 40. In this case, when the sub-controller 40 receives data including information about an abnormality that has occurred during the update of the firmware image 31 from the sub-controller 40 that is the next destination of the packet 50, the sub-controller 40 skips the sub-controller 40 that has transmitted the data including information about the abnormality and transmits the packet 50 to the subsequent sub-controller 40. As a result, the update process of the sub-controller 40 in which the abnormality has occurred is postponed, and the update process of the other sub-controllers 40 is performed first. Therefore, the completion rate of the update process of the sub-controllers 40 can be increased early. Note that the process before step S16 is as shown in FIG. 6, and therefore a detailed description will be omitted.

[0096] 6, the packet generation unit 44 of any controller 20 generates a packet 50 (S16), and the sub-communication unit 41 transmits the packet 50 (S17). Next, the sub-communication unit 41 checks whether the transmission of the packet 50 was successful (S18).

[0097] If the transmission of the packet 50 is successful (YES in S18), the controller 20 proceeds to the process of step S20 and subsequent steps in Fig. 6. On the other hand, if the transmission of the packet 50 has failed (NO in S18), the controller 20 performs an abnormality handling process in step S19.

[0098] Therefore, the packet generator 44 of the controller 20 generates an abnormality notification message packet 50 for notifying the controller 20 next in order to the controller 20 in which the communication abnormality occurred of the communication abnormality (S41). In this process, the command 58 is a "skip occurrence notification command" and the command data 59 is the "ID of the controller 20 in which the communication abnormality occurred."

[0099] Next, the sub-communication unit 41 transmits an abnormality notification message packet 50 to the controller 20 next in order to the controller 20 in which the communication abnormality occurred (S42). Then, the image construction unit 45 updates the data to a transmission order 53 that skips the controller 20 that failed to transmit the packet 50 (S43), and proceeds to step S16.

[0100] Thereafter, the controller 20 generates a packet 50 in step S16 based on the updated transmission order 53. This packet 50 is used by the controller 20 to resend the firmware image 31 to the skip destination controller 20, and the destination of the packet 50 sent in step S17 is the skip destination controller 20.

[0101] With this process flow, even when a communication abnormality occurs, the master controller 30 can continue updating the firmware image 31 for the sub-controller 40. Furthermore, the sub-controller 40 can notify the master controller 30 of information on the sub-controller 40 that was skipped due to this communication abnormality. Therefore, the master controller 30 can again update the firmware image 31 for the sub-controller 40 that was skipped by the process flow shown in FIG.

[0102] When the master controller 30 updates the firmware image 31 again, the master controller 30 must send a packet 50 with a command 58 set as an “image deletion command” to the sub-controller 40. The image deletion command is used by the master controller 30 to instruct the sub-controller 40 to delete the remnants of the firmware image 31 if any remain in the sub-controller 40.

[0103] [Tree Structure] Next, various tree structures in which controllers having a relationship between the master controller 30 and the sub-controller 40 are extracted from the elevator system 100 shown in FIG. 1 will be described.

[0104] <Elevator controller + floor controller configuration> First, a tree structure formed by the elevator controller 5 and a plurality of floor controllers 11 will be described with reference to FIG. FIG. 11 is a block diagram showing an example of a tree structure made up of an elevator controller 5 and a plurality of floor controllers 11.

[0105] One elevator 15 has a tree structure in which one elevator controller 5 and floor controllers 11(1) to 11(M) that exist for the number M of floors are connected by communication paths 12.

[0106] Assume that a firmware image 31 is downloaded from a higher-level group management controller 4 to an elevator controller 5. Then, among the elevator controller 5 or the multiple floor controllers 11, one in which the firmware image 31 is stored is a master controller 30, and the others are sub-controllers 40. For example, the elevator controller 5 is the master controller 30, and the floor controller 11 is the sub-controller 40. The master controller 30 transmits a packet 50 including a transmission order to the sub-controller 40, and the sub-controller 40 that receives the packet 50 updates the firmware image 31. In this way, by making the elevator controller 5 and the multiple floor controllers 11(1) to 11(M) into a relationship of the master controller 30 and the sub-controller 40, it becomes possible to perform an update process of the firmware image 31 of the sub-controller 40 without being limited to one controller.

[0107] In addition, there is a case where an arbitrary floor controller 11 downloads the firmware image 31 via the elevator controller 5. In this case, one floor controller 11 becomes the master controller 30, and the other floor controllers 11 and the elevator controller 5 become the sub-controllers 40. In such a configuration, the lower controller (floor controller 11) in the tree structure becomes the master controller 30, and the upper controller (elevator controller 5) becomes the sub-controller 40. Therefore, the floor controller 11 that becomes the master controller 30 can obtain the call registration information of each floor from the elevator controller 5. Conversely, the elevator controller 5 can also obtain the call registration information from each floor controller 11. Therefore, according to this embodiment, the packet communication system 200 can operate without being limited by the distinction between the upper and lower parts of the tree structure.

[0108] Furthermore, when the controller 20 that is connected to the maintenance terminal 19 and has downloaded the firmware image 31 becomes the master controller 30, the other controllers 20 connected to the same segment as this controller 20 become sub-controllers 40. Here, the other controllers 20 connected to the same segment are the group management controller 4 when the master controller 30 is the communication controller 3, the elevator controller 5 when the master controller 30 is the group management controller 4, and the car controller 10 and floor controller 11 when the master controller 30 is the elevator controller 5.

[0109] <Generating the order according to whether or not there are calls registered on the floor> Next, a process in which the elevator controller 5 generates data of the transmission order 53 based on the call registration at each floor, which is one of the operation states, will be described with reference to FIG. FIG. 12 is a flowchart showing an example of a process for generating an order depending on the presence or absence of call registration for a floor.

[0110] Here, the elevator controller 5 used as the master controller 30 generates a transmission order according to the call registration status of each floor obtained from the floor controller 11 as the operation status, and rearranges the transmission order according to the number of people on each floor. Therefore, a transmission order is generated according to the processing load due to call registration on the floor controller 11. Also, since the operation status of each floor of the elevator 15 is known according to the number of people on each floor, rearranging the transmission order to the floor controller 11 allows the firmware image 31 to be updated in order starting from the floor controller 11 with the lowest load.

[0111] First, the operation status acquisition unit 33 of the elevator controller 5 acquires the call registration information of each floor from the floor controller 11 of each floor (S51). Next, the elevator controller 5 determines whether or not the call registration information of all floors has been acquired (S52).

[0112] If the call registration information for all floors has been acquired (YES in S52), the sequence generation unit 34 of the elevator controller 5 rearranges the transmission sequence of the floor controllers 11 in accordance with the acquired call registration information to generate data for the transmission sequence 53 (S53), and ends this process. The transmission sequence is rearranged according to the presence or absence of call registration, and in ascending order of the call registration.

[0113] On the other hand, if there are any floors for which call registration information has not been acquired (NO in S52), the elevator controller 5 returns to step S51 again and continues the processing of steps S51 and S52 until the call registration information of all floors is acquired.

[0114] Here, for floors for which call registration information has not been acquired, no processing is assigned to the floor controller 11. Here, processing is assigned when either up or down calls are registered. Furthermore, when both up and down calls are registered, the processing load is the largest.

[0115] For this reason, the sequence generation unit 34 generates data of the transmission sequence 53 according to the allocation of call registration information to floors, so that the floor controller 11 with no processing allocation is placed first in the sequence and the floor controller 11 with many processing allocations is placed later in the sequence, thereby applying the firm image 31. Note that, if the group management controller 4 collectively manages the call registration information of each floor, the elevator controller 5 may collectively acquire the call registration information of each floor from the group management controller 4.

[0116] Furthermore, the sequence generation unit 34 can update the firmware image 31 from a floor controller 11 that is not assigned a process by setting the transmission order of the firmware image 31 according to the operation information of the elevator 15. This allows the elevator controller 5 to communicate update data efficiently. Furthermore, the elevator controller 5 applies the updated new firmware image 31 to the floor controller 11, improving the possibility that the floor controller 11 can be restarted immediately.

[0117] <Generating order according to the number of people staying on each floor> Next, the process in which the elevator controller 5 generates data for the transmission order 53 based on the number of people on each floor, which is one of the operation states, will be described with reference to Fig. 13. Here, the number of people on each floor is the number of people expected to be on each floor. The number of people on each floor can be found by calculating the number of people who got on and off the car at each floor. FIG. 13 is a flowchart showing an example of a process for generating an order according to the number of people visiting a floor.

[0118] First, the operation status acquisition unit 33 of the elevator controller 5 acquires the number of people staying on each floor from the other elevator controllers 5 or the floor controllers 11 of each floor (S61).

[0119] Next, the elevator controller 5 checks whether the number of visitors on all floors has been acquired (S62). If there is a floor for which the number of visitors has not been acquired (NO in S62), the elevator controller 5 returns to step S61 again and continues the processing of steps S61 and S62 until the number of visitors on all floors has been acquired.

[0120] On the other hand, if the number of people visiting all floors can be obtained (YES in S62), the sequence generation unit 34 of the elevator controller 5 rearranges the transmission sequence of the packets 50 to the floor controller 11 according to the number of people visiting each floor (S63), and generates data of the transmission sequence 53. After that, this process ends.

[0121] The order of transmission of the rearrangement is, for example, ascending order of the number of visitors. The greater the number of visitors, the higher the probability of a call occurring, and the greater the possibility of a large processing load. Conversely, the smaller the number of visitors, the lower the probability of a call occurring, and the greater the possibility of there being room for processing.

[0122] Therefore, by generating data of the transmission order 53 according to the number of visitors, the firmware image 31 can be applied in an order that places the floor controller 11 with processing capacity at the beginning and the floor controller 11 with the possibility of a large processing load at the end. Note that, if the group management controller 4 collectively manages the number of visitors on each floor, the elevator controller 5 may obtain the number of visitors on each floor from the group management controller 4. Also, if the elevator controller 5 itself manages the number of visitors on each floor, that management data may be used.

[0123] In this way, the elevator controller 5 rearranges the order of transmission to the floor controllers 11 according to the operation information of the elevator 15 (the number of people staying on each floor), so that the firmware image 31 can be updated starting from the floor controller 11 that has the most processing capacity. This allows the elevator controller 5 to efficiently transmit update data for the firmware image 31 to the floor controller 11. In addition, the floor controller 11 that receives the update data for the firmware image 31 is more likely to be able to immediately restart in order to apply the new updated firmware image 31.

[0124] <Group management controller + elevator controller> Next, a tree structure formed by connecting a plurality of elevators 15 and group management controller 4 via communication paths 16 will be described with reference to FIG. Fig. 14 is a block diagram showing an example of a tree structure made up of a group management controller 4 and multiple elevator controllers 5. Here, elevator group 18 shown in Fig. 1 includes one group management controller 4 and multiple elevator controllers 5 provided corresponding to an arbitrary number of elevators 15(1) to 15(M), respectively.

[0125] Here, of the group management controller 4 or the multiple elevator controllers 5, one in which the firmware image 31 is stored is the master controller 30, and the others are sub-controllers 40. In this case, the master controller 30 transmits a packet 50 including a transmission order to the sub-controller 40, and the sub-controller 40 that receives the packet 50 updates the firmware image 31.

[0126] Therefore, let us consider a case where a firmware image 31 is downloaded from a higher-level communication controller 3 to a group management controller 4. In this case, the group management controller 4 becomes a master controller 30, and the multiple elevator controllers 5 become sub-controllers 40. By configuring the group management controller 4 and the multiple elevator controllers 5 in this manner as a master controller 30 and sub-controller 40, it becomes possible to perform update processing of the firmware image 31 of the sub-controller 40, without being limited to a single controller.

[0127] Incidentally, there are cases where any elevator controller 5 downloads the firmware image 31 via the group controller 4. In this case, one elevator controller 5 serves as the master controller 30, and the other elevator controllers 5 and the group controller 4 serve as sub-controllers 40. With the configuration according to this embodiment, one elevator controller 5 serving as the master controller 30 can obtain the number of calls assigned to each elevator controller 5 from the group controller 4 serving as the sub-controller 40 or another elevator controller 5.

[0128] Furthermore, when the controller 20 that is connected to the maintenance terminal 19 and has downloaded the firmware image 31 becomes the master controller 30, the other controllers 20 that are connected to the same segment as this controller 20 become sub-controllers 40. Here, the controller 20 that has downloaded the firmware image 31 is assumed to be, for example, the elevator controller 5, the car controller 10, or the floor controller 11.

[0129] <Processing for generating order according to whether elevator calls are assigned and their size> Next, the process in which the group controller 4 generates data of the transmission order 53 based on the number of calls allocated to the elevator 15, which is one of the operation states, will be described with reference to FIG. 15 is a flowchart showing an example of a process for generating a transmission order according to the number of calls assigned to the elevator 15. In this process, the sequence generation unit 34 of the master controller 30 generates a transmission order according to the status of call assignment to the multiple elevators 15, acquired as the operation status. Therefore, a transmission order is generated according to the processing load of the elevator controller 5.

[0130] First, the operation status acquisition unit 33 of the group management controller 4 acquires the number of calls assigned to each elevator 15 (S71). Next, the sequence generation unit 34 of the group management controller 4 rearranges the transmission order of the elevator controllers 5 according to the number of calls assigned to generate data of the transmission sequence 53 (S72), and ends this process.

[0131] The transmission order is sorted in ascending order of the number of calls assigned. The greater the number of calls assigned, the greater the number of times the car 7 moves to, stops at, and departs from floors to which calls are assigned, and this may increase the processing load on the elevator controller 5. Conversely, the smaller the number of calls assigned, the less the processing load on the elevator controller 5. Also, the elevator controller 5 is more likely to stop, i.e. transition to a standby state.

[0132] Furthermore, the sequence generation unit 34 of the group management controller 4 sets the order in which the firmware images 31 are sent to the elevator controllers 5 according to the operation status of the elevators 15, thereby making it possible to update the firmware image 31 starting from the elevator controller 5 that has spare processing capacity or is likely to enter a standby state soon. This allows the elevator controller 5 to communicate update data efficiently. Furthermore, the group management controller 4 is more likely to be able to immediately restart the elevator controller 5 in order to apply the updated new firmware image 31 to the elevator controller 5.

[0133] <Communication controller + group management controller> Next, a tree structure in which a plurality of elevator groups 18 and communication controller 3 are connected via communication paths 17 will be described with reference to FIG. Fig. 16 is a block diagram showing an example of a tree structure made up of a communication controller 3 and multiple group management controllers 4. Here, there is shown one communication controller 3 shown in Fig. 1, and multiple group management controllers 4 provided corresponding to any number of elevator groups 18(1) to 18(M). Note that the value of M, which indicates the number of controllers and groups, shown in Figs. 11, 14, and 16 may be different.

[0134] In this process, of the communication controller 3 or the multiple group management controllers 4, one in which a firmware image 31 is stored is the master controller 30, and the others are sub-controllers 40. The master controller 30 then transmits a packet 50 including a transmission order to the sub-controller 40, and the sub-controller 40 that receives the packet 50 updates the firmware image 31. By thus configuring the communication controller 3 and the multiple group management controllers 4 as the master controller 30 and the sub-controller 40, it becomes possible to perform update processing of the firmware image 31 of the sub-controller 40 without being limited to one controller.

[0135] Therefore, assume that a firmware image 31 is downloaded from a higher-level communication controller 3 to a group management controller 4. In this case, the communication controller 3 becomes the master controller 30, and the multiple group management controllers 4 become sub-controllers 40.

[0136] Further, there is a case where any group management controller 4 downloads the firmware image 31 via the communication controller 3. In this case, one group management controller 4 becomes the master controller 30, and the other group management controllers 4 and the communication controllers 3 become sub-controllers 40. With this configuration, it is also possible for one group management controller 4 to transmit the firmware image 31 to the communication controller 3 and the other group management controllers 4.

[0137] Furthermore, when the controller 20 that is connected to the maintenance terminal 19 and has downloaded the firmware image 31 becomes the master controller 30, the other controllers 20 that are connected to the same segment as this controller 20 become sub-controllers 40. Here, the controller 20 that has downloaded the firmware image 31 is assumed to be, for example, the communication controller 3.

[0138] <Generating sequence according to the number of group management controllers assigned> Next, the process in which the sequence generation unit 34 of the communication controller 3 generates data of the transmission sequence 53 based on the status of the number of calls assigned to a plurality of group management controllers 4, which is the result of the assignment process of the group management controller 4, which is one of the operation states, that is, the number of calls assigned to the elevators 15, and the assignment process state, will be described with reference to Fig. 17. For this reason, here, a transmission sequence is generated according to the processing load due to the status of the number of calls assigned to the group management controller 4. FIG. 17 is a flowchart showing an example of a process for generating the number of calls to be assigned to the elevator 15 and an order according to the status of the assignment process.

[0139] First, the operation status acquisition unit 33 of the communication controller 3 acquires the number of call allocations and the allocation processing status from each group management controller 4 (S81). Next, the operation status acquisition unit 33 checks whether the number of call allocations and the allocation processing status have been acquired from all group management controllers 4 (S82). If the number of call allocations and the allocation processing status have not been acquired from all group management controllers 4 (NO in S82), the operation status acquisition unit 33 returns to step S81 and repeats acquisition of the number of call allocations and the allocation processing status.

[0140] On the other hand, if the information has been acquired for all group management controllers 4 (YES in S82), the sequence generation unit 34 of the communication controller 3 rearranges the transmission sequence of the group management controllers 4 in accordance with the number of allocations and the allocation processing status acquired by the operation status acquisition unit 33 to generate data for the transmission sequence 53 (S83), and then terminates this process.

[0141] The transmission order is sorted in ascending order based on whether or not a call has been assigned and the number of assignments. A group management controller 4 for which call assignment processing has been completed has a margin of processing load. Even for a group management controller 4 for which call assignment processing has been completed, a group management controller 4 with a large number of call assignments has fewer options to assign, and is therefore less likely to have an increase in the processing load of the group management controller 4. In other words, because there are fewer options to which calls can be assigned, there is less possibility that the processing load of the group management controller 4 will increase.

[0142] On the other hand, a group management controller 4 in the process of allocating calls has a larger processing load than a group management controller 4 that has completed the allocation process. Even for a group management controller 4 in the process of allocating calls, a group management controller 4 with a smaller number of already allocated calls has more options for future call allocations, and therefore is more likely to have an increased processing load on the group management controller 4.

[0143] For this reason, the sequence generation unit 34 generates data for the transmission sequence 53 depending on whether or not a call is being assigned and on the number of calls assigned, so that the firmware images 31 can be applied in an order that places the group management controller 4 that has completed the assignment process first and the group management controller 4 that is currently processing, has a small number of assignments, and has a heavy processing load last.

[0144] By following this order according to the operation information, the group management controller 4 that has the processing capacity can efficiently update the firmware image 31. This increases the possibility that the communication controller 3 can immediately restart the group management controller 4 in order to apply the updated new firmware image 31 to the group management controller 4.

[0145] <Restart process for each controller> Next, the restart processing for the group management controller 4, the elevator controller 5, and the floor controller 11 to apply the firmware image 31 will be described with reference to Figs.

[0146] <Restart group management controller (allocated)> First, the process of restarting the group management controller 4 to apply the updated firmware image 31 in accordance with the call allocation processing state, which is one of the operation states, will be described with reference to FIG. 18 is a flowchart showing an example of a process in which the group management controller 4 determines whether to restart in order to apply the firmware image 31. In this process, if a call allocation process is not being executed at the time when the update of the firmware image 31 for the group management controller 4 is completed, the image construction unit 45 of the group management controller 4 for which the update of the firmware image 31 has been completed performs the restart. Therefore, the group management controller 4 is restarted during a time period when there are no users in the elevators 15 managed by the group management controller 4, which does not cause inconvenience to users.

[0147] First, the group management controller 4 acquires the execution status of the call allocation process (S91). The group management controller 4 checks whether the call allocation process is in progress or not (S92). If the call allocation process is in progress (YES in S92), restart is not performed and this process ends. After a certain period of time, the group management controller 4 resumes the process from step S91. On the other hand, if the call allocation process is not in progress, that is, if the call allocation process has ended and the call has been assigned (NO in S92), the group management controller 4 is restarted (S93) and this process ends.

[0148] By this processing, when the group management controller 4 updates the firmware image 31, it becomes possible to reboot the group management controller 4 to apply the new firmware image 31 without having to reserve a special mode or work time, such as a maintenance mode.

[0149] <Restart elevator controller (reserve stop mode before next arrival)> Next, the process in which the elevator controller 5 restarts to apply the updated firmware image 31 in accordance with destination floor information, which is one of the operation states, will be described with reference to FIG. Fig. 19 is a flowchart showing an example of a process in which the elevator controller 5 determines whether to restart the elevator 15 to apply the firmware image 31. In this process, the image construction unit 45 of the elevator controller 5 suspends the acceptance of new calls from the elevator controller 5 if the destination floor of the elevator 15 is registered at the time when the update of the firmware image 31 of the elevator controller 5 is completed. Then, the image construction unit 45 of the elevator controller 5 restarts the elevator controller 5 if the safety state of the elevator car is confirmed after the elevator car arrives at the destination floor. Therefore, the elevator controller 5 is restarted in an elevator 15 with no passengers, which does not cause inconvenience to the passengers.

[0150] First, the elevator controller 5 acquires destination floor information, which is one of the operation states (S101). Next, the elevator controller 5 judges the destination floor information (S102). If multiple destination floors are registered, the elevator 15 must continue to operate and cannot be restarted. On the other hand, if one floor is registered as the destination floor or no destination floor is registered (NO in S102), the elevator controller 5 masks the call registration so that no new call registration occurs (S103). Therefore, the elevator controller 5 transitions to a mode that does not accept new calls, and processes to enter, for example, a maintenance mode as an operation mode that can be restarted when the car 7 arrives at the destination floor.

[0151] Next, the elevator controller 5 checks whether the car 7 has arrived at the destination floor (S104) and determines whether the car 7 has arrived at the destination floor (S105). If the car 7 has not arrived at the destination floor (NO in S105), the elevator controller 5 returns to step S104 and continues checking the arrival of the car 7.

[0152] On the other hand, when the car 7 has arrived at the destination floor (YES in S105), the elevator controller 5 acquires the car state (S106). Next, the elevator controller 5 determines whether or not the acquired car state is at least a safe state for passengers (S107).

[0153] The safest state is when there are no passengers in the car 7 and the doors are closed. If it is determined that the state is not safe (NO in S107), the elevator controller 5 ends this process. After a certain period of time, the elevator controller 5 resumes the process from step S101. On the other hand, if it is determined that the state is safe (YES in S107), the elevator controller 5 restarts itself (S108) and ends this process.

[0154] Through this processing, when the firmware image 31 is updated, the elevator controller 5 can be restarted to apply the new firmware image 31 without having to set aside a special mode or work time, such as a maintenance mode.

[0155] <Restarting the floor controller (checking call registration)> Next, the process of restarting the floor controller 11 to apply the updated firmware image 31 in response to the registration of an up / down call, which is one of the operation states, will be described with reference to Fig. 20. Here, the image construction unit 45 of the floor controller 11 checks the call registration at the time when the update of the firmware image 31 of the floor controller 11 is completed, and restarts the floor controller 11 if the call is not registered. Therefore, the floor controller 11 is restarted on a floor where there are no users, which does not cause inconvenience to the users. FIG. 20 is a flowchart showing an example of a process in which the floor controller 11 is rebooted to apply the firmware image 31.

[0156] First, the floor controller 11 acquires the state of up / down call registration (S111). Next, the floor controller 11 judges whether or not up / down calls are registered (S112). If up / down calls are registered (YES in S112), the elevator 15 is still operating and cannot be restarted. Therefore, this process ends here, and after a certain period of time, the floor controller 11 resumes the process from step S111.

[0157] On the other hand, if no up or down calls are registered (NO in S112), this corresponds to a state in which the floor controller 11 for that floor is temporarily disconnected from the operation state of the elevator 15, so the floor controller 11 executes a restart (S113) and terminates this process.

[0158] By this processing, when the firmware image 31 is updated, the floor controller 11 can be restarted to apply the new firmware image 31 without having to reserve a special mode or work time such as a maintenance mode.

[0159] It should be noted that the present invention is not limited to the above-described embodiments, 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-mentioned embodiments have described the configuration of the device and system in detail and specifically in order to explain the present invention in an easily understandable manner, and are not necessarily limited to those having all of the configurations described. In addition, it is possible to replace a part of the configuration of the embodiment described here with the configuration of another embodiment, and it is also 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 a part of the configuration of each embodiment with another configuration. 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. [Explanation of symbols]

[0160] 1...center, 3...communication controller, 4...group management controller, 5...elevator controller, 10...car controller, 11...floor controller, 18...elevator group, 19...maintenance terminal, 20...controller, 30...master controller, 31...firm image, 32...image division unit, 33...operation status acquisition unit, 34...sequence generation unit, 35...packet generation unit, 36...master communication unit, 40...sub-controller, 41...sub-communication unit, 42...packet interpretation unit, 43...destination extraction unit, 44...packet generation unit, 45...image construction unit, 50...packet, 100...elevator system, 200...packet communication system

Claims

1. An elevator system comprising a master controller that transmits firmware and a sub-controller that receives the firmware and updates the firmware, the master controller generates a transmission order of the firmware for the plurality of sub-controllers according to an operation state of the elevator, and transmits first transmission data including the firmware and the transmission order to the sub-controller having a priority in the transmission order; The sub-controller having the priority in the transmission order receives the first transmission data from the master controller, updates the firmware, and transmits the first transmission data to the sub-controller having the next priority in the transmission order. Elevator system.

2. The master controller: an operation status acquisition unit for acquiring an operation status of the elevator; an order generating unit that generates an order of transmission of the firmware to the sub-controllers to which the firmware is to be transmitted in accordance with the operating state; a firmware division unit that divides the firmware; a first transmission data generating unit that generates first transmission data for transmitting the firmware to the sub-controller in accordance with the transmission order; a first communication unit that transmits the first transmission data to the sub-controller that is first in the transmission order; The first transmission data generating unit generates the first transmission data including information for identifying the master controller, information for identifying the sub-controller, the transmission order, a construction order of the divided firmware, and the divided firmware.

2. The elevator system of claim 1.

3. a second communication unit that receives the first transmission data from the master controller or the sub-controller that is a source of the first transmission data; a data interpretation unit that interprets the first transmission data; a firmware construction unit that constructs the divided firmware interpreted by the data interpretation unit into the original firmware in accordance with the construction order; a destination extraction unit that extracts the sub-controller that is a next destination of the first transmission data based on the transmission order interpreted by the data interpretation unit; a second transmission data generating unit that generates second transmission data for transmitting the firmware to the sub-controller that is a next destination of the first transmission data, The second communication unit transmits the second transmission data to the sub-controller which is a next transmission destination.

3. The elevator system of claim 2.

4. When an abnormality occurs during the update of the firmware by the firmware construction unit, the second communication unit transmits data including information about the abnormality to the master controller in a reverse order to the transmission order.

4. The elevator system of claim 3.

5. The firmware construction unit erases the firmware that the firmware construction unit has constructed when an abnormality occurs during the firmware update.

5. The elevator system of claim 4.

6. When the second communication unit receives data including information regarding an abnormality that has occurred during the update of the firmware from the sub-controller that is a next destination of the first transmission data, the second communication unit skips the sub-controller that has transmitted the data including information regarding the abnormality and transmits the second transmission data to the subsequent sub-controller.

4. The elevator system of claim 3.

7. An elevator controller for controlling the operation of the elevator; a plurality of floor controllers provided for each floor on which the elevator ascends and descends, and which notify the elevator controller of the status of the floor; When one of the elevator controller or a plurality of floor controllers in which the firmware is stored is a master controller and the others are sub-controllers, the master controller transmits the first transmission data including the transmission order to the sub-controller, and the sub-controller that receives the first transmission data updates the firmware.

4. The elevator system of claim 3.

8. The master controller generates the transmission order according to the call registration status of each floor acquired as the operation status, and rearranges the transmission order according to the status of the number of people staying on the floor.

8. The elevator system of claim 7.

9. The firmware construction unit checks whether a call has been registered when the firmware update of the floor controller is completed, and if the call has not been registered, restarts the floor controller.

8. The elevator system of claim 7.

10. A group management controller that controls the operation of a plurality of elevator controllers that control the operation of the elevator; a plurality of elevator controllers; When one of the group management controller or a plurality of elevator controllers in which the firmware is stored is a master controller and the others are sub-controllers, the master controller transmits the first transmission data including the transmission order to the sub-controller, and the sub-controller that receives the first transmission data updates the firmware.

4. The elevator system of claim 3.

11. The sequence generation unit generates the transmission sequence according to a situation of assignment of calls to the plurality of elevators acquired as the operation status.

11. The elevator system of claim 10.

12. When the destination floor of the elevator is registered at the time when the firmware construction unit completes updating of the firmware of the elevator controller, the firmware construction unit suspends the acceptance of a new call by the elevator controller, and when the safety state of the elevator car is confirmed after the elevator car arrives at the destination floor, the elevator controller performs a restart.

11. The elevator system of claim 10.

13. a communication controller that controls communications with a plurality of group management controllers that control operations of a plurality of elevator controllers; A plurality of the group management controllers, When one of the communication controller or the plurality of group management controllers in which the firmware is stored is a master controller and the others are sub-controllers, the master controller transmits the first transmission data including the transmission order to the sub-controller, and the sub-controller that receives the first transmission data updates the firmware.

4. The elevator system of claim 3.

14. the sequence generation unit generates the transmission sequence in accordance with a status of a number of times that calls are assigned to the plurality of group management controllers, the status being acquired as the operation status; The firmware construction unit restarts the group management controller for which the firmware update has been completed if a call allocation process is not being executed at the time when the firmware update for the group management controller is completed.

14. The elevator system of claim 13.

15. A firmware transmission method performed in an elevator system including a master controller that transmits firmware and a sub-controller that receives the firmware and updates the firmware, comprising: a process in which the master controller generates a transmission order of the firmware for the plurality of sub-controllers according to the operation state of the elevator, and transmits first transmission data including the firmware and the transmission order to the sub-controller having a priority in the transmission order; the sub-controller having the priority in the transmission order receives the first transmission data from the master controller, updates the firmware, and transmits the first transmission data to the sub-controller having the next priority in the transmission order. Firmware transmission method.

Images