JP7618607B2 - Elevator system and firmware transmission method - Google Patents

Description

The present invention relates to an elevator system and a firmware transmission method.

Conventionally, an elevator system 100 is composed of multiple controllers. A system is known in which any one controller updates the programs of multiple controllers in a 1:N configuration.

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 one 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."

Patent document 2 states that "the transmission procedure control means calculates the elevator stop time from the transmission time for transmitting the update operation control program to the multiple control devices via the transmission path and the rewrite time 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."

Patent No. 4963292 Patent No. 5072411

As described in Patent Document 1, when one representative elevator is designated in advance and the transfer order of update data is determined in advance, update data cannot be updated from elevators other than the representative elevator. If 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, because update processing can only be performed in a predetermined order, an elevator can only complete update processing when all elevators in the designated order are able to perform the update processing. For example, even if only one elevator has a malfunction or is undergoing maintenance, if the control processing is under high load, the elevator will not accept the update processing, resulting in issues such as delays in communication processing or communication interruptions.

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

The present invention was made in consideration of these circumstances, and aims to change the order in which controllers update firmware depending on the elevator's operating status.

The elevator system according to the present invention comprises 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 operating 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.

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.

1 is a diagram showing an example of the overall configuration of an elevator system according to an embodiment of the present invention; FIG. 2 is a block diagram showing an example of a hardware configuration of a controller according to an embodiment of the present invention. 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. 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 an internal configuration of a packet, Fig. 4A is a diagram showing an example of a packet generated by a master controller and each sub-controller, 10 is a flowchart illustrating an example of normal communication processing in the packet communication system according to an embodiment of the present invention. 10 is a flowchart illustrating an example of processing of a sub-controller according to an embodiment of the present invention. 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. 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. 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. 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. 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. 13 is a flowchart illustrating an example of a process for generating a sequence according to the presence or absence of a call registration on a floor according to 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. 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. 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. 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. 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. 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. 10 is a flowchart illustrating an example of a process in which an elevator controller in one embodiment of the present invention determines whether to reboot in order to apply a firmware image. 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.

Below, 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.

[One embodiment]
FIG. 1 is a diagram showing an example of the overall configuration of an elevator system 100 according to an 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.

The elevator system 100 has a center 1 that is installed, for example, remotely from the elevators 15 to manage multiple elevators 15, monitor their 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.

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.

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 then controls the operation of 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.

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

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.

The car controller 10 opens and closes the car doors in response to the user's operation of the destination floor button and door open/close button 13 installed in the car 7, and notifies the elevator controller 5 of changes in the car status.

A floor controller 11 is provided for each floor on which the elevator 15 ascends and descends, and communicates 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 on each floor, and communicates 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, which allows passengers to register their destination floor before getting into the car.

As explained 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 configuration is arranged in multiple hierarchical stages. In addition, when there are multiple controllers of the same type, 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.

The center 1 stores the firmware used by each controller as a firmware image 31 (see FIG. 3 described later) in a storage unit (not shown). 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.

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 and output 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 send the firmware to other controllers.

The methods by which each controller updates firmware include a full update using a full firmware image, and a partial update using a difference image between the old and new firmware.

<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 controllers 20.

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, which are all connected to a system bus 21. Note that a CPU (Central Processing Unit) is a higher-level concept of a computing device similar to an MPU.

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 code that realizes each of the relevant functions, is recorded in the ROM 23, and the MPU 22 reads it from the ROM 23, loads it into the RAM 24, and executes the program code. The MPU 22 may also read the program code directly from the ROM 23 and execute the program code as is.

Variables, parameters, etc. that arise 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 by the MPU 22 as appropriate.

The controllers 20 can transmit and receive data between the multiple controllers 20 through the communication interface 25. The communication paths connecting the controllers 20 include, for example, 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 even a wireless communication path such as a Radio Area Network (RAN). The controllers 20 can transmit and receive data between devices, for example, wirelessly, such as Wi-Fi (registered trademark), or through infrastructure wireless communication.

In order to deal with problems that may occur when data is rewritten to the ROM 23, the controller 20 may be equipped with multiple ROMs 23. In this configuration, the current firmware image 31 (an 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, making it possible to restore the current state. Furthermore, when there are multiple ROMs 23, the controller 20 selects the ROM 23 in which the desired firmware image 31 is stored and starts it up.

<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.

The packet communication system 200 is one form of the elevator system 100 that includes 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 multiple 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, 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 elevator controllers 5.

The master controller 30 generates a transmission order of the firmware image 31 for the multiple subcontrollers 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 subcontroller 40 whose transmission order is to be prioritized. The master controller 30 is connected to the subcontrollers 40 via a communication path 37. The subcontroller 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 subcontroller 40 that receives the packet 50, the master controller 30 may transmit the packet 50 by giving priority to the subcontroller 40 whose transmission order is next to the abnormal subcontroller 40. In this way, the master controller 30 transmits the packet 50 to the subcontroller 40 whose transmission order is to be prioritized, so that the subcontroller 40 whose transmission order is to be prioritized can receive the packet 50. In addition, the subcontroller 40 that receives the packet 50 transmits the packet 50 to the subcontroller 40 whose transmission order is to be prioritized next, so that the packet 50 is transferred to multiple subcontrollers 40. This makes it possible to reliably transmit packets 50 to each sub-controller 40, compared to when the master controller 30 simultaneously distributes packets 50 to multiple sub-controllers 40.

This master controller 30 includes a firmware image 31, an image division unit 32, an operation status acquisition unit 33, a sequence generation unit 34, a packet generation unit 35, and a master communication unit 36.

The firmware image 31 is the actual 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.

The image dividing unit 32 is used as an example of a firmware dividing unit that divides the firmware image 31. Because 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 subcontroller 40 in each communication is reduced. The communication efficiency of the communication path 37 between the master controller 30 and the subcontroller 40 can be improved.

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.

The sequence generation unit 34 generates the transmission sequence of the sub-controller 40, which is the 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.

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 a packet 50 including information (source 51) identifying the master controller 30 that is the source of the packet 50, information (destination 52) 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).

The master communication unit 36 transmits the packet 50 generated by the packet generation unit 35 to the sub-controller 40 that has the earliest transmission order generated by the order generation unit 34.

The sub-controller 40 that has 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 that has 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.

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

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 specified 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.

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.

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

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 according to 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 has accumulated in the buffer, the firmware image 31 is reconstructed.

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 subcontroller 40 is read from the firmware image storage unit 46. The firmware image storage unit 46 may store multiple firmware images 31 in generation management for each version. Therefore, if an update fails, it is possible to revert to the previous firmware image 31.

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

When the elevator system 100 is in standby mode, such as during late night hours, 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 sent to the sub-controllers 40 using ascending/descending order based on the number of floors, the order of the serial numbers assigned to the controllers 20, or random numbers.

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

<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.

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 on the sender 51 of packet 50, data on the destination 52 of packet 50, data on the transmission order 53 of packet 50, image data 54 divided from firmware image 31, and check data 55 for checking for data inconsistencies in packet 50.

The image data 54 is one of the multiple image data into which the firmware image 31 is divided by the image division 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 actual entity of the divided image. By defining the structure of the packet 50 in this manner, the master controller 30 and the subcontrollers 40 can transmit the firmware image 31 in the order of the multiple subcontrollers 40 generated by the order generation unit 34. Therefore, each subcontroller 40 can update the firmware image 31 in the order in which it was received.

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

Figure 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, we consider an elevator 15 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 the transmission order 53 is generated as the order 4th floor - 2nd floor - 3rd floor - 1st floor. Here, the "1" stored in number 56 indicates that this is the first binary data of the divided firmware image 31.

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 53 to "2-3-1" after the ID number "4". As a result, the packet 50(1) is transmitted to the floor controller 11 on the fourth floor, which has the highest transmission order 53.

When the floor controller 11 on the fourth floor receives 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 packet 50(2) with the order "3-1" after ID number "2" in the transmission order 53. As a result, packet 50(2) is transmitted to the floor controller 11 on the second floor, which has the highest transmission order 53.

When the floor controller 11 on the second floor receives 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 packet 50(3) with the transmission order 53 set to "1" after the ID number "3". As a result, packet 50(3) is transmitted to the floor controller 11 on the third floor, which has the highest transmission order 53.

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 in transmission order 53 "1" in destination 52, and generates packet 50(4) with no transmission order 53 set because it is the last in the transmission order. Therefore, packet 50(4) is transmitted to the floor controller 11 on the first floor, which has the highest transmission order 53.

By structuring the packet 50 in this way, the packet 50 sent from the master controller 30 is sent through the multiple sub-controllers 40 in order based on a transmission order 53 according to the operating status of the elevator 15. This reduces the processing load on the master controller 30, and also enables the sub-controllers 40 to efficiently execute processing based on the operating status of the elevator 15. Furthermore, the communication method according to this embodiment does not occupy the network as much as broadcasting, which distributes packets from the master controller 30 to multiple sub-controllers 40 all at once. Furthermore, it becomes easier for the master controller 30 to manage the allocation of the transmission order of the firmware image 31.

When many controllers 20 are in standby mode, 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 simply be in order of the IDs of the controllers 20 or in order of the floor numbers.

In addition, when it is assumed that any subcontroller 40 will communicate 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 operating status of the elevators 15 within the range managed by the subcontroller 40. Communication from the subcontroller 40 to the master controller 30 is 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.

<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 processing in which the master controller 30 divides the firmware image 31 and distributes the firmware image 31 to all the sub-controllers 40 by transmitting packets 50 in the order in which they were generated based on the operating status of the elevator 15.

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 terminal number. If this terminal 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 a large number of them.

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 sent to the next sub-controller 40 according to the sequence generated by the sequence generation unit 34 (S4). Then, the master communication unit 36 sends the generated packet 50 to the next sub-controller 40 according to the sequence (S5).

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 resend the packet 50.

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.

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.

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).

Next, the packet interpretation unit 42 interprets the packet 50 received by the sub-communication unit 41 (S12) and identifies the sender 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.

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 parallel processes, but may be sequential processes.

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

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).

If the transmission of packet 50 fails (NO in S18), the subcontroller 40 performs an abnormality response process (S19) as 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.

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 subcontroller 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).

If it is the end of the firmware image 31 (YES in S20), the packet interpretation unit 42 checks whether the image construction unit 45 has finished constructing the firmware image 31, and then the subcontroller 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 subcontroller 40 repeats the process.

The sub-communication unit 41 may store the sender 51 interpreted by the packet interpretation unit 42 each time it 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 communicating in reverse order of the packets 50. For example, the sub-communication unit 41 can notify the master controller 30 of the occurrence of a malfunction in the sub-controller 40.

The process flows shown in Figures 5 and 6 allow the master controller 30 to update the firmware image 31 without distributing the firmware image 31 to all of the subcontrollers 40 itself, simply by sending a packet 50 to the first subcontroller 40 in the order according to the operating status of the elevator 15. The subcontrollers 40 communicate the firmware image 31 to the other subcontrollers 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 subcontrollers 40 by combining efficient communication processes.

Note that if the size of the firmware image 31 is small, or if the data size of the differential image in a 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.

<Communication abnormality notification process>
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.

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.

When a subcontroller 40 detects a communication abnormality when it receives a packet 50, it sends an abnormality notification message to the preceding subcontroller 40 that is the source of the packet 50. As shown in FIG. 7, this abnormality notification message is composed of data for the source 51, data for the destination 52, data for the image data 54, and check data 55. Note that no data is stored in the transmission order 53.

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 notification command," and the command data 59 stores the ID of the controller 20 in which the communication abnormality occurred.

Figure 8 is a flowchart showing an example of the process in which the subcontroller 40 notifies the occurrence of an abnormality. Here, a detailed example of the packet interpretation process shown in step S12 of Figure 6 is described.

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 data of the transmission order 53 stores the ID of the sub-controller 40 of the transmission destination in the transmission order of the packet 50 (S22). If the data of the transmission order 53 stores the ID of the sub-controller 40 in the transmission order (YES in S22), this process is terminated and the process proceeds to step S13 in FIG. 6.

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 while the image construction unit 45 was updating the firmware image 31. 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.

For example, the packet interpretation unit 42 interprets the command 58 shown in FIG. 7 and the 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 subcontroller 40 that executes this process itself, and the destination 52 is replaced with the previous subcontroller 40 that sent the packet 50 (S24).

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

The abnormality notification processing flow shown in FIG. 7 allows the subcontroller 40 to erase the firmware image 31 in the middle of processing when a communication abnormality occurs. The subcontroller 40 can also notify the master controller 30 of an abnormality notification message.

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

<First abnormality notification process>
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 erases 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.

As shown in FIG. 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, a communication controller 3, a group management controller 4, an elevator controller 5, a car controller 10, or a floor controller 11. Next, the sub-communication unit 41 checks whether the transmission of the packet 50 was successful (S18).

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 transmitting 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.

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 up to that point (S33), and ends this process.

<Second abnormality notification process>
FIG. 10 is a flowchart showing an example of a process for skipping the subcontroller 40 in which a communication error has occurred and continuing the update process of the firmware image 31. In this abnormality handling process, the packet 50 is transmitted preferentially to the subcontroller 40 in which no communication error has occurred. For example, it is assumed that the controller 20 is the subcontroller 40. In this case, when the subcontroller 40 receives data including information about an abnormality that has occurred during the update of the firmware image 31 from the subcontroller 40 that is the next destination of the packet 50, the subcontroller 40 skips the subcontroller 40 that transmitted the data including information about the abnormality and transmits the packet 50 to the subsequent subcontroller 40. As a result, the update process of the subcontroller 40 in which the abnormality has occurred is postponed, and the update process of the other subcontrollers 40 is performed first. Therefore, the completion rate of the update process of the subcontroller 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.

As shown in FIG. 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).

If the transmission of 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 packet 50 is unsuccessful (NO in S18), the controller 20 performs the abnormality response process of step S19.

The packet generator 44 of the controller 20 then generates an abnormality notification message packet 50 to notify the controller 20 next in line 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."

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). The image construction unit 45 then 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.

Then, in step S16, the controller 20 generates a packet 50 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.

This process flow allows the master controller 30 to continue updating the firmware image 31 for the sub-controller 40 even when a communication abnormality occurs. The sub-controller 40 can also notify the master controller 30 of information about the sub-controller 40 that was skipped due to this communication abnormality. Therefore, the master controller 30 can re-execute updating of the firmware image 31 for the sub-controller 40 that was skipped by the process flow shown in FIG. 10.

When the master controller 30 updates the firmware image 31 again, the master controller 30 must send a packet 50 with command 58 set as an "image erase command" to the subcontroller 40. The image erase command is used by the master controller 30 to instruct the subcontroller 40 to erase the remnants of the firmware image 31 if any remnants of the firmware image 31 remain in the subcontroller 40.

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

<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.

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

Assume that the firmware image 31 is downloaded from the upper group management controller 4 to the 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 the master controller 30, and the others are the 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 the 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 master controller 30 and sub-controller 40 relationship, it becomes possible to perform the update process of the firmware image 31 of the sub-controller 40 without being limited to one controller.

In addition, there are cases 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 higher 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.

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. Also, when the master controller 30 is the group management controller 4, they are the elevator controller 5. Also, when the master controller 30 is the elevator controller 5, they are the car controller 10 and the floor controller 11.

<Processing for generating order according to presence or absence of call registration on 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. 12.
FIG. 12 is a flowchart showing an example of a process for generating an order according to the presence or absence of call registration for a floor.

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 operating status of each floor of the elevator 15 is determined 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.

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

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 according to 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 call registration.

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

At this point, for floors where call registration information has not been acquired, no processing is assigned to the floor controller 11. Here, processing is assigned when there is registration for either up or down calls. Furthermore, when there are registrations for both up and down calls, the processing load is the heaviest.

Therefore, the sequence generation unit 34 generates data on the transmission sequence 53 according to the allocation of call registration information to floors, and can apply the firmware image 31 so that floor controllers 11 with no processing allocations are placed first and floor controllers 11 with many processing allocations are placed later. 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.

The sequence generation unit 34 also sets the order of transmission of the firmware images 31 according to the operation information of the elevator 15, thereby enabling the firmware images 31 to be updated from floor controllers 11 that are not assigned a process. 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.

<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 have 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.

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

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 and continues the processing of steps S61 and S62 until the number of visitors on all floors has been acquired.

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

The order in which the data is sorted and sent is, for example, ascending order of the number of visitors. The greater the number of visitors, the higher the probability of calls occurring, and the greater the likelihood of the processing load being heavy. Conversely, the smaller the number of visitors, the lower the probability of calls occurring, and the greater the likelihood that there will be spare processing capacity.

Therefore, by generating data for the transmission order 53 according to this 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 number of visitors on each floor is collectively managed by the group management controller 4, 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.

In this way, the elevator controller 5 can rearrange the order of transmission to the floor controllers 11 according to the elevator 15 operation information (the number of people on each floor), thereby updating the firmware image 31 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. Furthermore, the floor controller 11 that receives the update data for the firmware image 31 is more likely to be able to restart immediately in order to apply the new updated firmware image 31.

<Group management controller + elevator controller>
Next, a tree structure formed by connecting a plurality of elevators 15 and the 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 controller 4 and multiple elevator controllers 5. Here, the elevator group 18 shown in Fig. 1 includes one group controller 4 and multiple elevator controllers 5 provided corresponding to any number of elevators 15(1) to 15(M), respectively.

Here, of the group management controller 4 or 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 the transmission order to the sub-controller 40, and the sub-controller 40 that receives the packet 50 updates the firmware image 31.

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 the 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.

In addition, any elevator controller 5 may download the firmware image 31 via the group controller 4. In this case, one elevator controller 5 becomes the master controller 30, and the other elevator controllers 5 and the group controller 4 become sub-controllers 40. In the configuration according to this embodiment, one elevator controller 5 that becomes the master controller 30 can obtain the number of calls assigned to each elevator controller 5 from the group controller 4 or other elevator controllers 5 that become the sub-controllers 40.

In addition, 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.

<Processing for generating order according to the presence or absence of elevator call assignment and the size of the call>
Next, the process in which the group controller 4 generates data on the transmission order 53 based on the number of calls assigned 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.

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 sequence of the elevator controllers 5 according to the number of calls assigned, generates data for the transmission sequence 53 (S72), and ends this process.

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 result in a greater 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.

In addition, 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, so that the firmware image 31 can be updated from the elevator controller 5 that has processing capacity or is likely to enter a standby state soon. This allows the elevator controller 5 to communicate update data efficiently. In addition, 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.

<Communication controller + group management controller>
Next, a tree structure in which a plurality of elevator groups 18 and the 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 values of M, which indicate the number of controllers and groups, shown in Figs. 11, 14, and 16 may be different.

In this process, of the communication controller 3 or multiple group management controllers 4, one in which the 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 the 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 forming the relationship between the communication controller 3 and multiple group management controllers 4 as the master controller 30 and the sub-controller 40, it becomes possible to perform the update process of the firmware image 31 of the sub-controller 40 without being limited to a single controller.

Let us now 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 communication controller 3 becomes the master controller 30, and multiple group management controllers 4 become sub-controllers 40.

In addition, any group management controller 4 may download 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 controller 3 become sub-controllers 40. In 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.

In addition, 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.

<Processing for generating order according to the number of assigned group management controllers>
Next, the process in which the sequence generation unit 34 of the communication controller 3 generates data for 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 a sequence according to the status of the assignment process.

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 the acquisition of the number of call allocations and the allocation processing status.

On the other hand, if the data 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 according to 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 ends this process.

The transmission order is sorted in ascending order according to 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 therefore is less likely to have an increased processing load on 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 on the group management controller 4 will increase.

On the other hand, a group management controller 4 in the process of allocating calls has a greater 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 experience an increase in the processing load of the group management controller 4.

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 the number of calls assigned, so that the firmware image 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 and has a large processing load with a small number of assignments last.

By following this order according to the operation information, the firmware image 31 can be updated efficiently from the group management controller 4 that has processing capacity. This increases the likelihood 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.

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

<Restarting group management controller (allocated)>
First, the process in which the group management controller 4 restarts itself 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.

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 running or not (S92). If the call allocation process is running (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 running, 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.

By performing this process, when the firmware image 31 is updated, the group management controller 4 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.

<Restarting the elevator controller (reserving stop mode before the next arrival)>
Next, the process in which the elevator controller 5 restarts itself 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. 19.
19 is a flowchart showing an example of a process in which the elevator controller 5 determines whether to restart the elevator 15 in order 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 15 can be confirmed after the elevator car has arrived at the destination floor. As a result, the elevator controller 5 is restarted in an elevator 15 that has no users, which does not cause inconvenience to users.

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 cannot be restarted because it is necessary to continue operating. 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.

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 for the arrival of the car 7.

On the other hand, if 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 the acquired car state is at least a safe state for passengers (S107).

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.

By performing this process, 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.

<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.

First, the floor controller 11 acquires the status of up/down call registration (S111). Next, the floor controller 11 determines whether 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.

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 ends this process.

By performing this process, when the firmware image 31 is updated, the floor controller 11 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.

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.

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...subcontroller, 41...subcommunication 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 (15)

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. 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 has the first order of transmission,
2. The elevator system according to claim 1, wherein the first transmission data generation unit generates the first transmission data including information identifying the master controller, information identifying the sub-controller, the transmission order, a construction order of the divided firmware, and the divided firmware. 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 elevator system according to claim 2 , wherein the second communication unit transmits the second transmission data to the sub-controller which is a next transmission destination. 4. The elevator system according to claim 3, wherein when an abnormality occurs during updating of the firmware by the firmware construction unit, the second communication unit transmits data including information regarding the abnormality to the master controller in a reverse order to the transmission order. The elevator system according to claim 4 , wherein the firmware construction unit erases the firmware that the firmware construction unit has constructed when an abnormality occurs during the firmware update. The elevator system according to claim 3, wherein when the second communication unit receives data including information regarding an abnormality that occurred during the firmware update from the subcontroller that is the next destination of the first transmission data, the second communication unit skips the subcontroller that transmitted the data including information regarding the abnormality and transmits the second transmission data to the subsequent subcontroller. 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;
4. The elevator system according to claim 3, wherein, 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 receiving the first transmission data updates the firmware. 8. The elevator system according to claim 7, wherein the master controller generates the transmission order according to a call registration status for each floor acquired as the operation status, and rearranges the transmission order according to a status of a number of people staying on the floor. The elevator system according to claim 7, wherein the firmware construction unit checks whether a call has been registered when the firmware update of the floor controller is completed, and if no call has been registered, restarts the floor controller. 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;
4. The elevator system according to claim 3, wherein, 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 receiving the first transmission data updates the firmware. The elevator system according to claim 10, wherein the sequence generation unit generates the transmission sequence according to a situation of call allocation to the plurality of elevators acquired as the operation status. 11. The elevator system according to claim 10, wherein the firmware construction unit suspends acceptance of new calls by the elevator controller when a destination floor of the elevator is registered at the time when updating of the firmware of the elevator controller is completed, and when a safety condition of the car can be confirmed after the car arrives at the destination floor, the elevator controller performs a restart. 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,
4. The elevator system according to claim 3, wherein when one of the communication controller or the plurality of group control 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 receiving the first transmission data updates the firmware. 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 elevator system according to claim 13, wherein 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. 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 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.

Images