Elevator system and firmware transmission method

Abstract

The elevator system of the present invention has a main controller that generates a transmission order for a plurality of sub-controllers to transmit a firmware image based on an operating state of the elevator, and a sub-controller that has a higher transmission order priority transmits a data packet including the firmware image and the transmission order. The sub-controller having the higher transmission order priority receives the data packet from the main controller to update the firmware image, and transmits the data packet to a sub-controller having a second transmission order priority.

Description

Technical Field

[0001] This invention relates to elevator systems and firmware transmission methods. Background Technology

[0002] Traditionally, elevator systems consist of multiple controllers. Furthermore, a one-to-N structure update program system is known, where any one controller updates the programs of multiple controllers.

[0003] Patent document 1 describes that "the server publishes update data via a communication line to a predetermined representative elevator among multiple elevators, including differential information of the control program of the representative elevator before the update and the latest version of the control program to be updated. The representative elevator updates its own control program based on the update data received from the server, and sends the update data to the next elevator to be transmitted via the network in a predetermined transmission order."

[0004] Patent document 2 describes a method for "the transmission sequence control unit to calculate the elevator's stopping time based on the transmission time of the updated operation control program transmitted to multiple control devices via a channel and the rewriting time of the updated operation control program by multiple control devices, and to select the order in which the updated operation control program is transmitted to multiple control devices based on the calculated stopping time."

[0005] Existing technical documents

[0006] Patent documents

[0007] Patent Document 1: Japanese Patent No. 4963292

[0008] Patent Document 2: Japanese Patent No. 5072411 Summary of the Invention

[0009] The problem that the invention aims to solve

[0010] As described in Patent Document 1, when a representative elevator is predetermined and the transmission order of update data is predetermined, update data cannot be updated from elevators other than the representative elevator. When a malfunction occurs in the representative elevator, there may be situations where the processing load of the representative elevator is high, preventing data update processing. Furthermore, because update processing can only be performed in a predetermined order, the elevator can only complete the update processing when all elevators in the predetermined order are capable of performing update processing. For example, even if only one elevator malfunctions or is undergoing maintenance, and the control processing load is high, communication processing delays or interruptions may occur because update processing is not accepted.

[0011] Furthermore, Patent Document 2 describes a method for calculating the elevator's stopping time based on transmission and rewriting times. However, the program capacity, communication equipment performance, and storage device rewriting performance must meet pre-defined conditions. Similar to the technology described in Patent Document 1, there are situations where it is unsuitable for practical application.

[0012] The present invention was developed in view of the following situation, and its purpose is to change the order of firmware updates of the controller in accordance with the operating state of the elevator.

[0013] Technical solutions for solving the problem

[0014] The elevator system of the present invention has a main controller for sending firmware and a secondary controller for receiving firmware to update the firmware.

[0015] The main controller generates the firmware transmission order to multiple secondary controllers based on the elevator's operating status. For secondary controllers with higher transmission order, it sends first transmission data including the firmware and transmission order. The secondary controller with higher transmission order receives the first transmission data from the main controller to update its firmware, and sends the first transmission data to the secondary controller with second higher transmission order.

[0016] The effects of the invention

[0017] According to the present invention, since the firmware transmission order is generated based on the elevator's operating state, it is not necessary to predetermine the firmware transmission order.

[0018] Other issues, structures, and effects not described above will be explained through the following description of the implementation methods. Attached Figure Description

[0019] Figure 1 This is a diagram illustrating an example of the overall structure of an elevator system according to one embodiment of the present invention.

[0020] Figure 2 This is a block diagram illustrating an example of the hardware structure of a controller according to one embodiment of the present invention.

[0021] Figure 3 This is a block diagram illustrating a basic structural example of a data packet communication system including a master controller and a slave controller, according to one embodiment of the present invention.

[0022] Figure 4A This is a diagram illustrating an example of the internal structure of a data packet according to one embodiment of the present invention.

[0023] Figure 4B This is a diagram illustrating an example of a main controller and data packets generated in each sub-controller according to one embodiment of the present invention.

[0024] Figure 5This is a flowchart illustrating an example of normal communication processing in a data packet communication system according to one embodiment of the present invention.

[0025] Figure 6 This is a flowchart illustrating an example of the processing of a sub-controller according to one embodiment of the present invention.

[0026] Figure 7 This is a diagram illustrating an example of the data packet structure of an exception notification message according to one embodiment of the present invention.

[0027] Figure 8 This is a flowchart illustrating an example of how a secondary controller notifies of an abnormality in one embodiment of the present invention.

[0028] Figure 9 This is a flowchart illustrating an example of how a secondary controller handles exceptions when data packet transmission fails, according to one embodiment of the present invention.

[0029] Figure 10 This is a flowchart illustrating an example of a firmware update process that skips a secondary controller that has experienced a communication error, according to one embodiment of the present invention.

[0030] Figure 11 This is a block diagram illustrating an example of a tree structure consisting of an elevator controller and multiple floor controllers, representing one embodiment of the present invention.

[0031] Figure 12 This is a flowchart illustrating an example of a generation process corresponding to the order of elevator call registrations for a floor, as described in one embodiment of the present invention.

[0032] Figure 13 This is a flowchart illustrating an example of a generation process corresponding to the number of people staying on a floor, according to one embodiment of the present invention.

[0033] Figure 14 This is a block diagram illustrating an example of a tree structure consisting of a group management controller and multiple elevator controllers, representing one embodiment of the present invention.

[0034] Figure 15 This is a flowchart illustrating an example of a process for generating an order corresponding to the number of elevator call assignments, according to one embodiment of the present invention.

[0035] Figure 16 This is a block diagram illustrating an example of a tree structure consisting of a communication controller and multiple group management controllers, representing one embodiment of the present invention.

[0036] Figure 17 This is a flowchart illustrating an example of a generation process corresponding to the order of elevator call allocation numbers and allocation processing status, representing one embodiment of the present invention.

[0037] Figure 18 This is a flowchart illustrating an example of how a group management controller, according to one embodiment of the present invention, determines whether to restart in order to apply a firmware image.

[0038] Figure 19 This is a flowchart illustrating an example of how an elevator controller, according to one embodiment of the present invention, determines whether to restart in order to apply a firmware image.

[0039] Figure 20 This is a flowchart illustrating an example of the process by which a floor controller restarts in order to apply a firmware image, according to one embodiment of the present invention. Detailed Implementation

[0040] Hereinafter, an example of an elevator system and firmware transmission method for implementing the present invention will be described with reference to the accompanying drawings. In this specification and the drawings, elements having substantially the same function or structure are omitted from repeated description by using the same reference numerals. Furthermore, the present invention is not limited to the following embodiments.

[0041] [One implementation method]

[0042] Figure 1 This is a diagram illustrating an example of the overall structure of an elevator system 100 according to one embodiment of the present invention.

[0043] Figure 1 In order to simplify the description of the elevator system 100, the detailed components of one elevator 15 are shown in the illustration. The detailed components of other elevators 15 are omitted from the illustration.

[0044] In the elevator system 100, a central control unit 1 is provided, for example, to manage, monitor, and maintain multiple elevators 15. Additionally, the elevator system 100 includes 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.

[0045] Center 1 is connected to communication controller 3 via communication network 2, which is a closed-circuit network consisting of wired or wireless connections such as dedicated lines or public lines such as the Internet.

[0046] Communication controller 3 is responsible for communication between execution center 1 and the elevators for data transmission, remote operation, and remote maintenance. Communication controller 3 is connected to group management controller 4 via channel 17. Communication controller 3 controls communication between multiple group management controllers 4, which control the actions of multiple elevator controllers 5.

[0047] The group management controller 4 controls the actions of multiple elevator controllers 5 that control the movement of elevator 15. Therefore, the group management controller 4 combines multiple elevators 15 into an elevator group 18 for operation control. The group management controller 4 is connected to the multiple elevator controllers 5 via channel 16.

[0048] Elevator 15 includes elevator controller 5, car controller 10 and floor controller 11.

[0049] Elevator controller 5 controls the movement of elevator 15, providing users with vertical transportation services by controlling the up-and-down movement and stopping of car 7. To provide this service, elevator controller 5 controls motor 6, which acts as the main motor, to operate the movement of cable 9 connecting car 7 to counterweight 8. Elevator controller 5 is connected to one car controller 10 and multiple floor controllers 11 via channel 12.

[0050] The car controller 10 opens and closes the car door in accordance with 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 the changes in the car status.

[0051] The floor controller 11 is configured for each floor that the elevator 15 moves up and down, and notifies the elevator controller 5 of the floor status. For example, the floor controller 11 monitors the operation of the up and down buttons 14 installed on each floor by users on each floor, and notifies the elevator controller 5 of the changes in floor status. There are also elevator systems that, instead of the up and down buttons 14, have a destination floor registration device that allows passengers to register their destination floor before boarding the elevator car.

[0052] like Figure 1 As shown and illustrated, the elevator system 100 is a multi-level hierarchical tree structure system in which multiple controllers are arranged in a 1-to-N configuration. Furthermore, when multiple controllers of the same type exist, it is possible to construct a tree structure by using any one of the controllers as the root and the remaining controllers as leaves.

[0053] Center 1 uses the firmware used in each controller as firmware image 31 (see below). Figure 3 The firmware is stored in a storage unit not shown. Center 1 can send firmware to any controller via communication network 2, channels 12, 16, 17 and various controllers connected to the channels.

[0054] The 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 output the firmware it holds to any connected controller by connecting to it. Therefore, the maintenance terminal 19 enables the controller connected to it to hold the firmware. In addition, the controller holding the firmware can update its own firmware or send the firmware to other controllers.

[0055] In addition, as methods for updating the firmware of each controller, there are cases of overall updates using the overall image of the firmware and cases of partial differential updates using differential images of the old and new firmware.

[0056] <Example of controller hardware structure>

[0057] Next, regarding the hardware structure of each controller 20 in the elevator system 100, refer to... Figure 2 This section describes the hardware structure of the computer used in the communication controller 3, group management controller 4, elevator controller 5, car controller 10, and floor controller 11. These are collectively referred to as controller 20.

[0058] Figure 2 This is a block diagram illustrating an example of the hardware structure of controller 20.

[0059] The controller 20 has an MPU (Micro Processing Unit) 22, a ROM (Read Only Memory) 23, a RAM (Random Access Memory) 24, and a communication interface 25, all connected to the system bus 21. Additionally, a CPU (Central Processing Unit) is a higher-level concept than the MPU as a computing device.

[0060] MPU22, ROM23, and RAM24 constitute the processing unit. In this embodiment, the binary data of the program code that implements the relevant functions is the firmware image 31 (see below). Figure 3 The program code is recorded in ROM23. MPU22 reads it from ROM23 and loads it into RAM24 to execute the program code. Alternatively, there is also a case where MPU22 directly reads the program code from ROM23 and executes it directly.

[0061] In RAM24, variables and parameters generated during the execution of processing in MPU22 are temporarily written, and these variables and parameters are read from MPU22 as appropriate.

[0062] Controller 20 can send and receive data among multiple controllers 20 via communication interface 25. Channels connecting the controllers 20 include, for example, multi-point serial communication devices such as RS-485, wired channels such as Ethernet (registered trademark) providing various topologies (LAN, WAN), and wireless channels such as RAN (Radio Area Network). Each controller 20 can, for example, send and receive data between devices via wireless or infrastructure wireless communication such as Wi-Fi (registered trademark).

[0063] Furthermore, to address the possibility of malfunctions when rewriting data to 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, while the new firmware image 31 is recorded in another ROM 23. Even if a malfunction occurs when rewriting the new firmware image 31 to the latter ROM 23, the current firmware image 31 is retained in the former ROM 23, allowing the system to recover. Additionally, when multiple ROMs 23 exist, the controller 20 selects the ROM 23 containing the required firmware image 31 for booting.

[0064] <Basic System Architecture of Main Controller and Sub-Controller>

[0065] Next, based on Figure 1 The implementation of the elevator system 100 shown will be described, and the basic system structure of the main controller and the auxiliary controller of the embodiment of the present invention will be explained.

[0066] Figure 3 This is a block diagram illustrating a basic structural example of a data packet communication system 200 including a main controller 30 and a secondary controller 40.

[0067] The data packet communication system 200 is one method of using an elevator system 100, which has a main controller 30 for sending firmware image 31 and a secondary controller 40 for receiving and updating firmware image 31. For example... Figure 1As shown, the elevator system 100 is a large-scale system with multiple controllers connected in a tree structure, where multiple controllers 1 to N are linked. Here, a data packet communication system 200 is described, in which one controller 20 is designated as the master controller 30 and N controllers 20 are designated as slave controllers 40. Furthermore, in the data packet communication system 200, controllers 20 on the same floor or different floors are configured as master-slave relationships. These master-slave relationships can exist not only on adjacent floors but also across one or more floors. For example, it is also possible to designate a group management controller 4 as the master controller 30 and multiple floor controllers 11 as slave controllers 40 across elevator controllers 5.

[0068] The main controller 30 generates a transmission order for firmware images 31 for multiple sub-controllers 40 in accordance with the operating state of elevator 15. Then, the main controller 30 transmits data packets 50, including the firmware images 31 and the transmission order, to the sub-controllers 40 with the highest transmission order. The main controller 30 is connected to the sub-controllers 40 via channel 37. Sub-controllers 40 that receive data packets 50 directly from the main controller 30 are mostly transmitted first in the transmission order.

[0069] However, if an anomaly occurs in the secondary controller 40 that receives data packet 50, the primary controller 30 may sometimes prioritize the next-order secondary controller 40 that received the anomaly in sending data packet 50. Thus, the primary controller 30 sends data packet 50 to the secondary controller 40 with the priority sending order, and the secondary controller 40 with the priority sending order is able to receive data packet 50. Alternatively, the secondary controller 40 that received data packet 50 sends data packet 50 to the secondary controller 40 with the second-highest priority sending order, so data packet 50 is transmitted among multiple secondary controllers 40. Therefore, compared to the case where the primary controller 30 simultaneously sends data packet 50 to multiple secondary controllers 40, it is possible to reliably send data packet 50 to each secondary controller 40.

[0070] The main controller 30 includes a firmware image 31, an image segmentation unit 32, an operating status acquisition unit 33, a sequence generation unit 34, a data packet generation unit 35, and a main communication unit 36.

[0071] Firmware image 31 is the physical entity of firmware. Firmware is an example of a program that controls the operation of controller 20. Firmware image 31 is stored in ROM 23 or similar files set in main controller 30.

[0072] Image segmentation unit 32 is used as an example of a firmware segmentation unit that segments the firmware image 31. Image segmentation unit 32 segments the firmware image 31, so the binary data 57 of the data packet 50 sent to the sub-controller 40 in each communication (see below) Figure 4A This reduces the amount of data. It can improve the communication efficiency of channel 37 between the main controller 30 and the secondary controller 40.

[0073] 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 and the call allocation status. The operation status acquisition unit 33 can acquire the operation status from the car controller 10, the floor controller 11, etc.

[0074] The sequence generation unit 34 generates the transmission order of the firmware image 31, segmented by the image segmentation unit 32, to the secondary controller 40, based on the operating status of the elevator 15 acquired by the operating status acquisition unit 33. Additionally, if the file size of the firmware image 31 is sufficiently small, there is a possibility that an unsegmented firmware image 31 may be sent to the secondary controller 40.

[0075] The data packet generation unit 35 (an example of the first transmission data generation unit) generates a data packet 50 for transmitting firmware image 31 to the slave controller 40 according to the transmission order generated by the sequence generation unit 34. The data packet 50 is used as an example of the first transmission data. (As described later...) Figure 4A As shown, the data packet generation unit 35 generates a data packet 50 that includes information identifying the sending source of the data packet 50, namely the main controller 30 (sending source 51), information identifying the sending destination of the data packet 50, namely the secondary controller 40 (sending destination 52), the sending order (sending order 53), the construction order of the segmented firmware image 31 (number 56), and the segmented firmware image 31 (binary data 57).

[0076] The main communication unit 36 ​​transmits the data packet 50 generated by the data packet generation unit 35 to the secondary controller 40, whose transmission order is generated first by the sequence generation unit 34.

[0077] The secondary controller 40, which has the highest transmission priority, receives data packets 50 from the primary controller 30 and updates the firmware image 31. The secondary controller 40, which has the second highest transmission priority, sends data packets 50 to the primary controller 30. The secondary controller 40 has a secondary communication unit 41, a data packet interpretation unit 42, a destination extraction unit 43, a data packet generation unit 44, an image construction unit 45, and a firmware image storage unit 46.

[0078] The secondary communication unit 41 is connected to the channel 37. This secondary communication unit 41 is used as an example of a second communication unit to receive data packets 50 from the main controller 30 or another secondary controller 40 that is the source of data packets 50 via the channel 37.

[0079] The data packet interpretation unit 42 is used as an example of a data interpretation unit that interprets the data packet 50 received by the sub-communication unit 41. The interpretation of the data packet 50 is the process of extracting data from the data packet 50 according to a prescribed data packet format and outputting the data to a prescribed output destination.

[0080] The segmented image data of the firmware image 31, interpreted by the data packet interpretation unit 42, is output to the image construction unit 45. Additionally, the interpretation result of the data packet 50 by the data packet interpretation unit 42 is output to the destination extraction unit 43.

[0081] The destination extraction unit 43 extracts the sub-controller 40 as the next destination for data packet 50 based on the transmission order interpreted by the data packet interpretation unit 42.

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

[0083] The image construction unit 45 is used as an example of a firmware construction unit that constructs the segmented firmware image 31 obtained from the data 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) for accumulating the segmented firmware image 31 received from the data packet interpretation unit 42. Then, when the segmented firmware image 31 is sufficiently accumulated in the buffer, the firmware image 31 is reconstructed.

[0084] 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. Multiple firmware images 31 can also be version-managed individually in the firmware image storage unit 46. Therefore, in the event of an update failure, it is possible to revert to the previous firmware image 31.

[0085] The firmware image 31 is transmitted by repeatedly processing each part of the sub-controller 40 and transmitting the firmware image 31 in a transmission sequence that is efficient and corresponds to the operating status of the elevator 15.

[0086] When the elevator system 100 is in standby mode, such as during late-night hours, the order of the controllers 20 has less impact on the update process. Therefore, the data packet generation unit 44 can use an ascending / descending order corresponding to the floor number, the order of the sequence numbers assigned to the controllers 20, or a random number to determine the order in which the data packets 50 are sent to the sub-controllers 40.

[0087] The relationship between the main controller 30 and the secondary controller 40 can also be determined by the user using the maintenance terminal 19. Alternatively, the controller that has downloaded the firmware image 31 from the maintenance terminal 19 can be designated as the main controller 30, and other controllers can be automatically designated as secondary controllers 40.

[0088] <Basic Structure of Data Packets>

[0089] Next, regarding Figure 3 The basic structure of the data packet 50 generated in the data packet communication system 200 shown uses... Figure 4A and Figure 4B Please provide an explanation.

[0090] Figure 4A and Figure 4B This is a diagram illustrating the basic structure of data packet 50.

[0091] Figure 4A This is a diagram illustrating an example of the internal structure of data packet 50.

[0092] The data packet 50 consists of data from the sending source 51, data from the sending destination 52, data from the sending order 53, image data 54 after dividing the firmware image 31, and verification data 55 used to confirm that the data in the data packet 50 is incomplete.

[0093] Image data 54 is used Figure 3 The image segmentation unit 32 shown divides the firmware image 31 into one of multiple image data. Therefore, the image data 54 consists of a number 56 indicating the build order after the firmware image 31 is segmented, and binary data 57 representing the entities of the segmented images. By defining the structure of the data packet 50 in this way, the main controller 30 and the sub-controllers 40 can send the firmware image 31 in the order generated by the sequence generation unit 34. Therefore, each sub-controller 40 can update the firmware image 31 in the order it is received.

[0094] Furthermore, the image data 54 or binary data 57 includes identification data indicating which of the following controllers—communication controller 3, group management controller 4, elevator controller 5, and floor controller 11—the firmware corresponds to. Thus, in the case of the main controller 30, the image building unit 45 installed in each controller can identify the firmware for other controllers based on the identification data.

[0095] Figure 4B This diagram illustrates a structural example of the data packet 50 generated by the main controller 30 and each of the sub-controllers 40. Here, we envision an elevator 15 installed in a four-story building. The main controller 30 corresponds to the elevator controller 5, and the sub-controllers 40 correspond to the floor controllers 11. Furthermore, it shows a case where the transmission sequence 53 is generated as floor 4-floor-floor-floor-floor-1. Here, the "1" stored in number 56 indicates the first binary data in the segmented firmware image 31.

[0096] The main controller 30 generates a data packet 50(1) that has its own ID number "0" set in the sending source 51, the initial ID number "4" set in the sending destination 52, and the sequence "2-3-1" after ID number "4" set in the sending sequence 53. Therefore, the data packet 50(1) is sent to the floor controller 11 of the first 4 floors in the sending sequence 53.

[0097] When the floor controller 11 on the 4th floor receives data packet 50(1), it generates data packet 50(2) which has its own ID number "4" set in the sending source 51, the initial ID number "2" set in the sending destination 52 for the sending order 53, and the sequence "3-1" set after ID number "2" in the sending order 53. Therefore, data packet 50(2) is sent to the floor controller 11 on the 2nd floor with the first sending order 53.

[0098] When the floor controller 11 on the second floor receives data packet 50(2), it generates data packet 50(3) which has its own ID number "2" set in the sending source 51, the initial ID number "3" set in the sending destination 52 for the sending order 53, and the sequence number "1" after ID number "3" set in the sending order 53. Therefore, data packet 50(3) is sent to the floor controller 11 on the third floor, which has the highest sending order 53.

[0099] When the floor controller 11 on the 3rd floor receives data packet 50(3), it generates data packet 50(4) which has its own ID number "3" set in the sending source 51, its initial ID number "1" set in the sending destination 52 for the sending order 53, and no sending order 53 set because it is the last in the sending order. Therefore, data packet 50(4) is sent to the floor controller 11 on the 1st floor, which has the first sending order 53.

[0100] By structuring the data packet 50 in such a way that the data packet 50 sent from the main controller 30 is sequentially sent via multiple sub-controllers 40 based on a sending order 53 corresponding to the operating state of the elevator 15. Therefore, the processing load on the main controller 30 can be reduced, and the sub-controllers 40 can also perform processing efficiently based on the operating state of the elevator 15. Furthermore, the communication method of this embodiment does not require network usage compared to broadcasting data packets simultaneously from the main controller 30 to multiple sub-controllers 40. Additionally, the main controller 30 can easily manage the allocation of the sending order of the firmware image 31.

[0101] Furthermore, when many controllers 20 are in standby mode, such as during periods of low usage late at night, the differences in the states of the controllers 20 determined by their operating status are minimal. Therefore, the transmission order 53 can simply be set to the ID order or floor number order of the controllers 20.

[0102] Alternatively, assuming direct communication between any secondary controller 40 and the main controller 30, an entry indicating the source of the data packet, equivalent to that of the main controller 30, can be appended to the data packet in addition to the sending source 51 and sending destination 52. Communication from the secondary controller 40 to the main controller 30 is, for example, to notify the main controller 30 of the operating status of the elevator 15 within the area managed by the secondary controller 40. Furthermore, communication from the secondary controller 40 to the main controller 30 is used for status notifications during normal operation of the elevator 15. It is also used to allow the secondary controller 40 to directly send fault information to the main controller 30 without having to go through multiple secondary controllers 40 in reverse.

[0103] <Communication Processing During Normal Hours>

[0104] Next, regarding Figure 3 The processing in the data packet communication system 200 shown (an example of a firmware transmission method) is referenced. Figure 5 The following flowcharts will provide further explanation.

[0105] Figure 5 This is a flowchart illustrating an example of normal communication processing in a data packet communication system 200. Figure 5 The process is illustrated in which the main controller 30 segments the firmware image 31 and sends data packets 50 in the order generated based on the operating state of the elevator 15, thereby publishing the firmware image 31 to all the sub-controllers 40.

[0106] First, the image partitioning unit 32 of the main controller 30 (reference) Figure 3The firmware image 31 is divided into segments suitable for communication (S1). When dividing the firmware image 31, the image segmentation unit 32 also generates ascending numbers 56 (see reference) to determine the segmentation order. Figure 4A Additionally, there are cases where the last segmented firmware image 31 is assigned a special end number. If the controller 20 receiving the data packet 50 shares this end number, the controller 20 can receive the last segment even if there are many segments of firmware image 31.

[0107] Next, the operating status acquisition unit 33 acquires the operating status of the elevator 15 (S2). Next, the sequence generation unit 34 generates a sequence for the secondary controllers 40 to communicate with the segmented firmware image 31 based on the operating status (S3). Next, the data packet generation unit 35 generates data packets 50 to be sent to the next secondary controller 40 according to the sequence generated by the sequence generation unit 34 (S4). Then, the main communication unit 36 ​​sends the generated data packets 50 sequentially to the next secondary controller 40 (S5).

[0108] The main communication unit 36 ​​confirms whether the transmission of data packet 50 was successful (S6). If the transmission of data packet 50 fails (S6 no), the main communication unit 36 ​​receives an exception notification from the secondary controller 40 (S7) and terminates this process. Furthermore, after a certain period of time, the main controller 30 re-executes this process to resend data packet 50.

[0109] On the other hand, if data packet 50 is successfully sent (yes in S6), the main communication unit 36 ​​checks whether there is a remaining portion after dividing the firmware image 31 (S8). If there is a remaining portion after dividing the firmware image 31 (yes in S8), the main controller 30 returns to step S1 and repeats the process. If there is no remaining portion (no in S8), the main controller 30 ends the process.

[0110] Next, regarding the processing of the secondary controller 40, refer to... Figure 6 Please provide an explanation.

[0111] Figure 6 This is a flowchart illustrating an example of the processing of the secondary controller 40.

[0112] First, the secondary communication unit 41 of the secondary controller 40 receives data packets 50 from the primary controller 30 or the previous secondary controller 40 in sequence (S11).

[0113] Next, the data packet interpretation unit 42 interprets the data packet 50 received by the sub-communication unit 41 (S12), identifying the sending source 51, sending destination 52, sending order 53, segmented image data 54, and check data 55. The processing of interpreting the data packet 50 in step S12 will be described later. Figure 8 Detailed examples are shown below.

[0114] Next, the destination extraction unit 43 extracts the next destination from the transmission order 53 identified by the data packet interpretation unit 42 (S13). Additionally, the image construction unit 45 sequentially constructs the firmware image 31 using the segmented image data 54 (S14). Steps S13 and S14 can be performed in parallel or sequentially.

[0115] Next, the destination extraction unit 43 checks whether there is a next destination for the segmented image data 54 according to the transmission order 53 (S15).

[0116] If a next destination exists (as in S15), the data packet generation unit 44 generates a data packet 50 that changes the destination 52 to the next sub-controller 40 (S16). The sub-communication unit 41 sends the generated data packet 50 to the next sub-controller 40 (S17) and confirms whether the transmission of the data packet 50 was successful (S18).

[0117] If data packet 50 fails to be sent (No in S18), the secondary controller 40 will proceed as described later. Figure 7 or Figure 10 The exception handling (S19) is shown below. Step S19 is described later. Figure 9 and Figure 10 The locations shown have different redirect destinations.

[0118] On the other hand, if the data packet 50 is successfully sent (yes in S18), or if it is determined in step S15 that there is no next sub-controller 40 to send the segmented image data 54 (no in S15), the data packet interpretation unit 42 confirms whether the image data 54 is the end of the firmware image 31 (S20).

[0119] If it is the end of firmware image 31 (yes in S20), the data packet interpretation unit 42 confirms that the image construction unit 45 has finished building firmware image 31, and the sub-controller 40 ends this process. On the other hand, if it is not the end of firmware image 31 (no in S20), the process returns to step S11, and the sub-controller 40 repeats the process.

[0120] Additionally, the secondary communication unit 41 can store the sending source 51 interpreted by the data packet interpretation unit 42 each time it receives a data packet 50 including the segmented image data 54. In this case, the secondary communication unit 41 can also communicate with the main controller 30 by communicating in reverse order of the data packets 50. For example, the secondary communication unit 41 can also notify the main controller 30 that a fault has occurred in the secondary controller 40.

[0121] pass Figure 5 and Figure 6 The processing flow shown allows the main controller 30 to update the firmware image 31 by sending data packets 50 only to the initial sub-controller 40 in the sequence corresponding to the operating state of the elevator 15, without needing to publish the firmware image 31 to all the sub-controllers 40 themselves. The sub-controllers 40 communicate and transmit the firmware image 31 to each other in the order generated by the main controller 30. In this way, the main controller 30 can update the firmware image 31 of all sub-controllers 40 by combining efficient communication processing.

[0122] Furthermore, if the firmware image 31 is small in size, or the data length of the differential image in the differential update is small, there may be cases where data packets 50 are transmitted without image segmentation. In this case, it is also possible to complete the processing between the main controller 30 and the slave controller 40 in a single communication.

[0123] <Notification and handling of communication anomalies>

[0124] Next, regarding the handling of the secondary controller 40 notifying the primary controller 30 of the communication anomaly, the following steps are taken: Figures 7-10 Please provide an explanation.

[0125] First, let's explain the structure of the exception notification message used in this process.

[0126] Figure 7 This is a diagram illustrating an example of the data packet structure for an exception notification message.

[0127] When a communication anomaly is detected upon receiving data packet 50, the secondary controller 40 sends an anomaly notification message to the source of data packet 50, i.e., the previous-level secondary controller 40.

[0128] The exception notification message is as follows: Figure 7 As shown, it consists of data from the sending source 51, data from the sending destination 52, data from the image data 54, and checksum data 55. Additionally, no data is stored in the sending sequence 53.

[0129] Then, the image data 54 consists of command 58 and command data 59 corresponding to command 58. In this embodiment, command 58 stores a "notification of an abnormality" command, and command data 59 stores the ID of the controller 20 that experienced the communication abnormality.

[0130] Figure 8 This is a flowchart illustrating an example of how the secondary controller 40 handles an exception notification. Here, it is explained... Figure 6 The detailed example of packet interpretation and processing shown in step S12 is as follows.

[0131] First, the data packet interpretation unit 42 of any controller 20 interprets the data packet 50 and confirms the data of transmission order 53 (S21). Next, the data packet interpretation unit 42 checks whether the ID of the destination sub-controller 40 is stored in the data of transmission order 53 according to the transmission order of data packet 50 (S22). If the ID of the sub-controller 40 is stored in the data of transmission order 53 according to the transmission order (S22), the process exits this stage and proceeds to the next stage. Figure 6 Step S13.

[0132] On the other hand, if the ID of the secondary controller 40 is not saved in the data of transmission sequence 53 according to the transmission order (No in S22), an anomaly occurs during the update of the firmware image 31 by the image building unit 45. In this case, the secondary communication unit 41 sends data including information about the anomaly to the main controller 30 in the reverse order of transmission. Therefore, the main controller 30 can immediately know about the anomaly that occurred in the secondary controller 40 and take measures such as instructing to stop sending data packets 50.

[0133] For example, the data packet interpretation unit 42 interprets the image data 54 according to the image data 54. Figure 7 The command 58 shown and the command data 59 corresponding to the command 58 are interpreted (S23). Then, the data packet interpretation unit 42 generates an exception notification message that sets the sending source 51 to the sub-controller 40 itself that performs this process and replaces the sending destination 52 with the sub-controller 40 that sent the data packet 50 before it (S24).

[0134] The secondary communication unit 41 of the secondary controller 40 sends an error notification message to the secondary controller 40 that was sent first in the transmission sequence (S25). Afterwards, the image building unit 45 deletes the previously built firmware image 31 (S26), ending the process. Therefore, no further processing is performed. Figure 6 The processing after steps S13 and S14.

[0135] pass Figure 8 The illustrated exception notification processing flow allows the secondary controller 40 to delete the firmware image 31 during processing when a communication exception occurs. Additionally, the secondary controller 40 can send an exception notification message to the primary controller 30.

[0136] <Communication handling during exceptions>

[0137] Next, for the handling of situations such as communication errors, the deletion of the image during construction by the secondary controller 40 after receiving data packet 50, and skipping the secondary controller 40 where a communication error occurred, the following steps are taken: Figure 9 and Figure 10 Please provide an explanation.

[0138] <First Anomaly Notification Handling>

[0139] Figure 9 This is a flowchart illustrating an example of exception handling performed by the secondary controller 40 when data packet 50 fails to be transmitted. In this exception handling, when data packet 50 fails to be transmitted, the secondary controller 40 deletes the image data 54 previously sent to the secondary controller 40 at the destination. Furthermore, the processing prior to step S17 is as follows... Figure 6 The description is general, so detailed explanations are omitted.

[0140] like Figure 6 As shown, the sub-communication unit 41 of any controller 20 sends the generated data packet 50 to the next controller 20 (S17). Examples of any controller 20 include communication controller 3, group management controller 4, elevator controller 5, car controller 10, and floor controller 11. Next, the sub-communication unit 41 confirms whether the data packet 50 was successfully sent (S18).

[0141] If data packet 50 is successfully sent (as in S18), controller 20 transfers to... Figure 6 The processing after step S20. On the other hand, if the transmission of data packet 50 fails (No in S18), an error occurs during the update of firmware image 31 by image building unit 45.

[0142] In this case, the secondary communication unit 41 sends data including information about the anomaly to the main controller 30 in the reverse order of transmission. Therefore, the main controller 30 can immediately detect the anomaly occurring in the secondary controller 40 and take measures such as instructing it to stop sending data packets 50. Furthermore, if an anomaly occurs during the firmware image 31 update process, the secondary controller 40 deletes the firmware image 31 already built by the image building unit 45. Therefore, the secondary controller 40 will not use an incorrect firmware image 31 for update processing.

[0143] For example, the data packet generation unit 44 of the controller 20 generates a data packet 50 (S31) to notify the preceding controller 20 of a communication error. Next, the sub-communication unit 41 sends the data packet 50 containing the error notification message to the preceding controller 20 (S32). Then, the image building unit 45 deletes the previously built firmware image 31 (S33), ending the process.

[0144] <Second Anomaly Notification Handling>

[0145] Figure 10This is a flowchart illustrating an example of a process that skips the secondary controller 40 where a communication error occurred and continues the firmware image 31 update process. In this exception handling, data packet 50 is sent preferentially to the secondary controller 40 where no communication error occurred. For example, suppose controller 20 is the secondary controller 40. In this case, if the secondary controller 40 receives data including information about an exception that occurred during the firmware image 31 update from the secondary controller 40 that is the next destination for data packet 50, it skips the secondary controller 40 that sent the data including the exception information and sends data packet 50 to the subsequent secondary controller 40. As a result, the update process of the secondary controller 40 that experienced the exception can be delayed, and the update process of other secondary controllers 40 can be performed first. Therefore, the completion rate of the update process of the secondary controller 40 can be improved earlier. Furthermore, the processing before step S16 is as follows... Figure 6 The description is general, so detailed explanations are omitted.

[0146] like Figure 6 As shown, the data packet generation unit 44 of any controller 20 generates data packet 50 (S16), and the sub-communication unit 41 sends data packet 50 (S17). Next, the sub-communication unit 41 confirms whether the transmission of data packet 50 was successful (S18).

[0147] If data packet 50 is successfully sent (as in S18), controller 20 transfers to... Figure 6 The processing after step S20. On the other hand, if the transmission of data packet 50 fails (No in S18), the controller 20 performs the exception handling in step S19.

[0148] Therefore, the data packet generation unit 44 of the controller 20 generates a data packet 50 (S41) for notifying the next controller 20 in sequence of the communication failure of the communication failure. In this process, the command 58 is a "notification skip command" and the command data 59 is the "ID of the controller 20 that has experienced the communication failure".

[0149] Next, the sub-communication unit 41 sends a data packet 50 containing an error notification message to the next controller 20 that experienced a communication error (S42). Then, the image construction unit 45 updates the data to skip the sending order of the controller 20 that failed to send the data packet 50 (S43) and proceeds to step S16.

[0150] Subsequently, controller 20 generates data packet 50 in step S16 based on the updated transmission order 53. This data packet 50 is a data packet in which controller 20 retransmits firmware image 31 to controller 20 at the jump destination. The transmission destination of data packet 50 sent in step S17 is controller 20 at the jump destination.

[0151] Through this processing flow, even in the event of a communication anomaly, the main controller 30 can continue updating the firmware image 31 of the secondary controller 40. Furthermore, the secondary controller 40 can notify the main controller 30 of the information regarding the secondary controller 40 that was skipped due to the communication anomaly. Therefore, the main controller 30 can... Figure 10 The processing flow shown re-executes the firmware image 31 update for the skipped sub-controller 40.

[0152] Additionally, when the main controller 30 performs the firmware image 31 update again, it needs to send a data packet 50 to the secondary controller 40, setting command 58 to "delete image command". The delete image command is used to instruct the secondary controller 40 to delete the residual data of firmware image 31 if residual data of firmware image 31 remains in the secondary controller 40.

[0153] [Tree structure]

[0154] Next, regarding from Figure 1 The various tree structures of the controllers that form the relationship between the main controller 30 and the auxiliary controller 40 in the elevator system 100 shown are explained.

[0155] <Structure of elevator controller + floor controller>

[0156] First, for the tree structure consisting of elevator controller 5 and multiple floor controllers 11, using Figure 11 Please provide an explanation.

[0157] Figure 11 This is a block diagram illustrating an example of a tree structure consisting of an elevator controller 5 and multiple floor controllers 11.

[0158] An elevator 15 is a tree structure that connects an elevator controller 5 and floor controllers 11(1) to 11(M) corresponding to the number of floors M using channel 12.

[0159] Imagine a scenario where firmware image 31 is downloaded from a higher-level group management controller 4 to elevator controller 5. Furthermore, the structure is such that one controller storing firmware image 31 in elevator controller 5 or multiple floor controllers 11 is a main controller 30, and the others are secondary controllers 40. For example, elevator controller 5 acts as the main controller 30, and floor controllers 11 act as secondary controllers 40. The main controller 30 sends data packets 50, including the sending order, to the secondary controllers 40, and the secondary controllers 40 that receive data packets 50 update firmware image 31. By making elevator controller 5 and multiple floor controllers 11(1) to 11(M) a main controller 30 and a secondary controller 40 in this way, the firmware image 31 update process of the secondary controllers 40 can be performed without being limited to a single controller.

[0160] Additionally, there is a case where any floor controller 11 downloads firmware image 31 via elevator controller 5. In this case, one floor controller 11 acts as the master controller 30, and the other floor controllers 11 and elevator controller 5 act as slave controllers 40. With this structure, the lower-level controller (floor controller) 11 in the tree structure is the master controller 30, and the upper-level controller (elevator controller 5) is the slave controller 40.

[0161] Therefore, the floor controller 11, acting as the main controller 30, can obtain elevator call registration information for each floor from the elevator controller 5. Conversely, the elevator controller 5 can also obtain elevator call registration information from each floor controller 11. Therefore, according to this embodiment, the data packet communication system 200 can operate without being limited by the distinction between upper and lower levels in a tree structure.

[0162] Furthermore, when the controller 20 connected to the maintenance terminal 19 and having downloaded the firmware image 31 serves as the main controller 30, other controllers 20 connected to the same segment as this controller 20 serve as secondary controllers 40. Here, the other controllers 20 connected to the same segment are group management controllers 4 if the main controller 30 is a communication controller 3. Alternatively, if the main controller 30 is a group management controller 4, it is an elevator controller 5. Furthermore, if the main controller 30 is an elevator controller 5, it includes a car controller 10 and a floor controller 11.

[0163] <Generation and processing of the order corresponding to the existence of elevator call registration on different floors>

[0164] Next, for the processing of data generated by elevator controller 5 based on call registrations on each floor as one of the operating states, the following steps are taken: Figure 12 Please provide an explanation.

[0165] Figure 12This is a flowchart illustrating an example of the generation process corresponding to the order of elevator call registrations for different floors.

[0166] Here, the elevator controller 5, which serves as the main controller 30, generates a transmission order corresponding to the call registration status of each floor obtained from the floor controller 11 as it is in operation, and rearranges the transmission order according to the number of people staying on each floor. Therefore, a transmission order corresponding to the processing load of the call registrations on the floor controller 11 is generated. Furthermore, since the operating status of each floor of the elevator 15 is known according to the number of people staying on each floor, the firmware image 31 is updated sequentially from the floor controller 11 with the lowest load by rearranging the transmission order to the floor controller 11.

[0167] 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 the call registration information of all floors has been acquired (S52).

[0168] If all floor call registration information has been obtained (as in S52), the sequence generation unit 34 of the elevator controller 5 arranges the sending order of the floor controller 11 and generates the sending order 53 data (S53) in accordance with the obtained call registration information, and ends this process. The sending order is arranged according to whether there is a call registration and the ascending order of call registrations.

[0169] On the other hand, if there are still floors for which elevator call registration information has not yet been obtained (No in S52), the elevator controller 5 returns to step S51 again and continues to process steps S51 and S52 until elevator call registration information for all floors is obtained.

[0170] Here, no processing is assigned to the floor controller 11 on floors where elevator call registration information has not yet been obtained. Processing is assigned when only one of the upward or downward elevator calls is registered. Furthermore, the processing load is highest when both upward and downward elevator call registrations are present.

[0171] Therefore, by generating data corresponding to the transmission order 53 for the allocation of call registration information for each floor, the sequence generation unit 34 can apply the firmware image 31 to prioritize floor controllers 11 that have not been allocated and prioritize floor controllers 11 that have been allocated more. Furthermore, when the group management controller 4 manages the call registration information for each floor together, the elevator controller 5 can also obtain the call registration information for each floor from the group management controller 4.

[0172] Furthermore, by setting the transmission order of the firmware image 31 to correspond to the operating information of the elevator 15, the sequence generation unit 34 can update the firmware image 31 starting from the floor controller 11, which has not yet been assigned processing. Therefore, the elevator controller 5 can efficiently and effectively transmit update data. In addition, the elevator controller 5 can increase the likelihood that the floor controller 11 can be restarted immediately after applying the updated firmware image 31 to it.

[0173] <Generation and processing of the order corresponding to the number of people staying on each floor>

[0174] Next, for the processing of data generated by elevator controller 5 based on the number of people staying on each floor as one of the operating states, the transmission sequence 53 is... Figure 13 To clarify, the number of passengers staying here is a predicted number of people located on each floor. The number of passengers staying can be determined by calculating the number of passengers moving between floors from the elevator car.

[0175] Figure 13 This is a flowchart illustrating an example of the generation process corresponding to the number of people staying on each floor.

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

[0177] Next, the elevator controller 5 checks whether the number of people staying on all floors has been obtained (S62). If there are floors where the number of people staying has not yet been obtained (No in S62), the elevator controller 5 returns to step S61 and continues to process steps S61 and S62 until the number of people staying on all floors is obtained.

[0178] On the other hand, if the number of people staying on all floors has been obtained (as in S62), the sequence generation unit 34 of the elevator controller 5 arranges the sending order of the data packets 50 to the floor controller 11 according to the number of people staying on each floor (S63), and generates the data for the sending order 53. Then the process ends.

[0179] The sending order can be set, for example, in ascending order of the number of people remaining in the queue. This is because a higher number of people remaining in the queue increases the probability of an elevator call, thus increasing the processing capacity. Conversely, a lower number of people remaining in the queue decreases the probability of an elevator call, thus increasing the likelihood of processing capacity being available.

[0180] Therefore, by generating data corresponding to the transmission order 53 of the number of people staying, the firmware image 31 can be applied in the order of setting the floor controller 11 with processing capacity spare first and the floor controller 11 with the possibility of heavy processing load last. Furthermore, when the group management controller 4 manages the number of people staying on each floor together, the elevator controller 5 can also obtain the number of people staying on each floor from the group management controller 4. Additionally, when the elevator controller 5 manages the number of people staying on each floor itself, it can also use this management data.

[0181] In this way, by arranging the transmission order of the elevator controller 5 to the floor controller 11 in accordance with the operating information of the elevator 15 (the number of people staying on each floor), the elevator controller 5 can update the firmware image 31 starting from the floor controller 11 where there is processing capacity. Therefore, the elevator controller 5 can efficiently send the firmware image 31 update data to the floor controller 11. In addition, the possibility of the floor controller 11, which has received the firmware image 31 update data, restarting immediately to apply the updated firmware image 31 is increased.

[0182] <Group Management Controller + Elevator Controller>

[0183] Next, for the tree structure formed by connecting multiple elevators 15 and group management controller 4 using channel 16, using Figure 14 Please provide an explanation.

[0184] Figure 14 This is a block diagram illustrating an example of a tree structure consisting of a group management controller 4 and multiple elevator controllers 5. Here, Figure 1 The elevator group 18 shown includes a group management controller 4 and multiple elevator controllers 5, each corresponding to any number of elevators 15(1) to 15(M).

[0185] Here, in the group management controller 4 or multiple elevator controllers 5, one of the controllers storing the firmware image 31 is the main controller 30, and the others are secondary controllers 40. In this case, the main controller 30 sends data packets 50, including the sending order, to the secondary controllers 40, and the secondary controllers 40 that receive the data packets 50 update the firmware image 31.

[0186] Therefore, consider the scenario where firmware image 31 is downloaded from the upper-level communication controller 3 to the group management controller 4. In this case, the group management controller 4 acts as the main controller 30, and the multiple elevator controllers 5 act as secondary controllers 40. By making the group management controller 4 and the multiple elevator controllers 5 a main controller 30 and a secondary controller 40, the firmware image 31 of the secondary controllers 40 can be updated without being limited to a single controller.

[0187] Additionally, there is a case where any elevator controller 5 downloads firmware image 31 via group management controller 4. In this case, there is a structure where one elevator controller 5 acts as the main controller 30, and the other elevator controllers 5 and group management controller 4 act as secondary controllers 40. If this is the structure of this embodiment, the elevator controller 5 acting as the main controller 30 can obtain the number of call requests assigned to each elevator controller 5 from the group management controller 4 acting as the secondary controller 40 or other elevator controllers 5.

[0188] In addition, if the controller 20 connected to the maintenance terminal 19 and having downloaded the firmware image 31 serves as the main controller 30, other controllers 20 connected to the same segment as this controller 20 serve as secondary controllers 40. Here, the controller 20 that has downloaded the firmware image 31 is conceived, for example, as the elevator controller 5, the car controller 10, or the floor controller 11.

[0189] <The generation and processing of elevator call assignments and their corresponding order>

[0190] Next, for the group management controller 4, the data for generating the transmission sequence 53 is generated based on the number of elevator call assignments for elevator 15, which is one of the operating states. Figure 15 Please provide an explanation.

[0191] Figure 15 This is a flowchart illustrating an example of a process for generating a sequence corresponding to the number of call assignments for elevator 15. In this process, the sequence generation unit 34 of the main controller 30 generates a transmission sequence corresponding to the status of call assignments for multiple elevators 15, which is obtained as the operating state. Therefore, a transmission sequence corresponding to the processing load of the elevator controller 5 is generated.

[0192] First, the operation status acquisition unit 33 of the group management controller 4 acquires the number of elevator calls allocated to each elevator 15 (S71). Next, the sequence generation unit 34 of the group management controller 4 arranges the sending order of the elevator controller 5 according to the number of elevator calls and generates the data for the sending order 53 (S72), thus ending this process.

[0193] The order of dispatching calls is in ascending order of the number of call assignments. When there are many call assignments, the elevator car 7 processes the movement, stopping, and departure of floors with assigned calls more times, thus potentially increasing the processing load on the elevator controller 5. Conversely, when there are fewer call assignments, the processing load on the elevator controller 5 is lower. Additionally, the likelihood of the elevator controller 5 switching to a stopped, standby state increases.

[0194] Furthermore, the sequence generation unit 34 of the group management controller 4 updates the firmware image 31 of the elevator controller 5 according to the order in which it is sent, corresponding to the operating state of the elevator 15. This allows it to update the firmware image 31 starting with the elevator controller 5, which has sufficient processing capacity or is more likely to have recently entered a standby state. Therefore, the elevator controller 5 can efficiently transmit update data. Additionally, the group management controller 4 can increase the likelihood that the elevator controller 5 can be restarted immediately after the updated firmware image 31 is applied.

[0195] <Communication Controller + Group Management Controller>

[0196] Next, for the tree structure that connects multiple elevator groups 18 to the communication controller 3 using channel 17, using Figure 16 Please provide an explanation.

[0197] Figure 16 This is a block diagram illustrating an example of a tree structure consisting of a communication controller 3 and multiple group management controllers 4. Here, it is shown... Figure 1 The diagram shows one communication controller 3 and multiple group management controllers 4, each corresponding to an arbitrary number of elevator groups 18(1) to 18(M). Additionally, it indicates... Figure 11 , Figure 14 , Figure 16 The value of M for the number of controllers and groups shown can be different.

[0198] In this process, among the communication controller 3 or multiple group management controllers 4, one that stores the firmware image 31 is the main controller 30, and the others are secondary controllers 40. Then, the main controller 30 sends a data packet 50, including the sending order, to the secondary controllers 40, and the secondary controllers 40 that receive the data packet 50 update the firmware image 31. By making the communication controller 3 and the multiple group management controllers 4 a main controller 30 and a secondary controller 40 in this way, the firmware image 31 update process of the secondary controllers 40 can be performed without being limited to a single controller.

[0199] Therefore, consider the scenario where firmware image 31 is downloaded from the higher-level communication controller 3 to the group management controller 4. In this case, the communication controller 3 acts as the main controller 30, and multiple group management controllers 4 act as secondary controllers 40.

[0200] Alternatively, there may be a case where any group management controller 4 downloads the firmware image 31 via the communication controller 3. In this case, there is a configuration where one group management controller 4 acts as the master controller 30, and the other group management controllers 4 and the communication controller 3 act as slave controllers 40. With this configuration, one group management controller 4 can also send the firmware image 31 to the communication controller 3 and other group management controllers 4.

[0201] Furthermore, if the controller 20 connected to the maintenance terminal 19 and having downloaded the firmware image 31 serves as the main controller 30, other controllers 20 connected to the same segment as this controller 20 serve as secondary controllers 40. Here, the controller 20 that has downloaded the firmware image 31 is, for example, envisioned as the communication controller 3.

[0202] <Generation process of the order corresponding to the allocation number of the group management controller>

[0203] Next, the sequence generation unit 34 of the communication controller 3 processes the data for generating the transmission sequence 53 based on the allocation processing results of the group management controller 4 as one of the operating states, namely, the status of the number of elevator call allocations for multiple group management controllers 4, that is, the number of elevator call allocations for elevator 15 and the allocation processing status. Figure 17 This will be explained. Therefore, a transmission order is generated here corresponding to the processing load determined by the number of times the elevator is assigned to the group management controller 4.

[0204] Figure 17 This is a flowchart illustrating an example of the generation process corresponding to the number of calls to elevator 15 and the order of the call processing status.

[0205] First, the operation status acquisition unit 33 of the communication controller 3 acquires the number of elevator calls and the allocation processing status from each group management controller 4 (S81). Next, the operation status acquisition unit 33 checks whether the number of elevator calls and the allocation processing status have been acquired from all group management controllers 4 (S82). If they have not been acquired from all group management controllers 4 (S82 no), the operation status acquisition unit 33 returns to step S81 and repeatedly acquires the number of elevator calls and the allocation processing status.

[0206] On the other hand, if all group management controllers 4 have been acquired (S82), the sequence generation unit 34 of the communication controller 3 arranges the sending order of the group management controllers 4 according to the allocation number and allocation processing status acquired by the operation status acquisition unit 33 and generates the data of the sending order 53 (S83), and ends this process.

[0207] The sending order is arranged in ascending order based on whether elevator call allocation processing has occurred and the number of allocations. Group management controller 4, having completed elevator call allocation processing, has spare capacity in terms of processing load. Even for group management controller 4 that has completed elevator call allocation processing, a group management controller 4 with a large number of elevator calls has fewer options to allocate, so the likelihood of an increase in the processing load of group management controller 4 is low. In other words, because there are fewer options for elevator calls to be allocated, the likelihood of an increase in the processing load of group management controller 4 is low.

[0208] On the other hand, the group management controller 4 in the elevator call allocation process has a larger processing load compared to the group management controller 4 after the allocation process has been completed. Even among the group management controller 4 in the elevator call allocation process, the group management controller 4 with fewer allocated elevator calls has more options for subsequent elevator call allocation, so the processing load of the group management controller 4 is more likely to increase.

[0209] Therefore, the sequence generation unit 34 generates data for the transmission sequence 53 in accordance with whether elevator call allocation processing is performed and the size of the number of elevator calls allocated. It can apply firmware image 31 in the order of setting the group management controller 4 whose allocation processing has been completed first and the group management controller 4 with a large processing load and a small number of allocations being processed last.

[0210] By setting the order in which the operation information is configured, the firmware image 31 can be updated efficiently, starting with the group management controller 4, which has sufficient processing capacity. Therefore, the possibility of the communication controller 3 immediately restarting the group management controller 4 in order to apply the updated firmware image 31 to the group management controller 4 is increased.

[0211] <Handling the restart of each controller>

[0212] Next, for the group management controller 4, elevator controller 5, and floor controller 11, the restart process of the application firmware image 31 is handled using... Figures 18-20 Please provide an explanation.

[0213] <Group Management Controller Restart (Assignment Completed)>

[0214] First, for the group management controller 4 and the call allocation processing state, which is one of the operating states, the process is restarted accordingly to apply the updated firmware image 31, using Figure 18 Please provide an explanation.

[0215] Figure 18 This is a flowchart illustrating an example of the process by which the group management controller 4 determines whether to restart in order to apply firmware image 31. In this process, if no elevator call allocation process is performed at the point when the update of firmware image 31 for the group management controller 4 is completed, the image building unit 45 of the group management controller 4, after the firmware image 31 update is completed, performs a restart. Therefore, the group management controller 4 restarts during periods when there are no users in the elevator 15 managed by the group management controller 4, without causing inconvenience to users.

[0216] First, the group management controller 4 obtains the execution status of the elevator call allocation process (S91).

[0217] Group management controller 4 checks whether elevator call allocation processing is in progress (S92). If elevator call allocation processing is in progress (yes in S92), a restart is not performed, and the process ends.

[0218] After a certain period of time, the group management controller 4 restarts processing from step S91. On the other hand, if the elevator call allocation process is not being performed, that is, the elevator call allocation process has been completed, or the elevator call allocation has been completed (No in S92), the group management controller 4 is restarted (S93), and the process ends.

[0219] Through this process, when updating the firmware image 31, the group management controller 4 can perform a reboot to apply the new firmware image 31 without needing to ensure a special mode or job time such as maintenance mode.

[0220] <Restarting the elevator controller (pre-scheduled stop mode before next arrival)>

[0221] Next, the process of restarting the elevator controller 5 in accordance with the destination floor information, which is one of the operating states, to apply the updated firmware image 31 is performed using... Figure 19 Please provide an explanation.

[0222] Figure 19 This is a flowchart illustrating an example of the process by which the elevator controller 5 determines whether to restart in order to apply firmware image 31. In this process, if the image building unit 45 of the elevator controller 5 has registered the destination floor of the elevator 15 at the point when the update of the firmware image 31 of the elevator controller 5 is completed, it temporarily suspends accepting new elevator calls. Then, after the car arrives at the destination floor and its safety status is confirmed, the image building unit 45 of the elevator controller 5 restarts the elevator controller 5. Therefore, restarting the elevator controller 5 in an elevator 15 without users will not cause inconvenience to the users.

[0223] First, the elevator controller 5 acquires the destination floor information, which is one of the operating states (S101). Next, the elevator controller 5 determines the destination floor information (S102). If multiple destination floors are registered, the elevator 15 cannot be restarted because it needs to continue operating. On the other hand, if only one destination floor is registered, or no destination floor is registered (S102: No), the elevator controller 5 blocks call registrations to prevent new call registrations (S103). Therefore, the elevator controller 5 switches to a mode that does not accept new calls and processes the operation in a mode that allows the car 7 to restart when it reaches the destination floor, such as a maintenance mode.

[0224] Next, the elevator controller 5 confirms whether the car 7 has reached the destination floor (S104) and determines whether the car 7 has reached the destination floor (S105). If the car 7 has not yet reached the destination floor (S105 no), the elevator controller 5 returns to step S104 to continue confirming the arrival of the car 7.

[0225] On the other hand, if the car 7 has reached the destination floor (as stated in S105), the elevator controller 5 acquires the car status (S106). Then, the elevator controller 5 determines whether the acquired car status is safe for passengers (S107).

[0226] The safest state is when there are no passengers in car 7 and the doors are closed. If the state is determined to be unsafe (No in S107), elevator controller 5 ends the process. After a certain period of time, elevator controller 5 restarts the process from step S101. On the other hand, if the state is determined to be safe (Yes in S107), elevator controller 5 performs its own restart (S108) and ends the process.

[0227] With this processing, when updating the firmware image 31, the elevator controller 5 can perform a reboot to apply the new firmware image 31 without needing to ensure a special mode or operation time such as maintenance mode.

[0228] <Restarting the floor controller (confirming call registration)>

[0229] Next, the process of restarting the floor controller 11 and the registration of up and down calls as one of the operating states in order to apply the updated firmware image 31 is performed using... Figure 20 Here's an explanation. The image building unit 45 of the floor controller 11 checks the registration of elevator calls at the point when the firmware image 31 of the floor controller 11 is updated. If no elevator call is registered, the floor controller 11 is restarted. Therefore, restarting the floor controller 11 on floors without users will not inconvenience the users.

[0230] Figure 20 This is a flowchart illustrating an example of the process by which the floor controller 11 restarts in order to apply firmware image 31.

[0231] First, the floor controller 11 obtains the registration status of up and down elevator calls (S111).

[0232] Next, the floor controller 11 determines whether there are any registered up or down calls (S112). If there are registered up or down calls (yes in S112), the elevator 15 cannot be restarted because it continues to operate. Thus, this process ends here, and after a certain period of time, the floor controller 11 restarts the process from step S111.

[0233] On the other hand, if there is no registration of up or down calls (S112 no), it is equivalent to temporarily separating the floor controller 11 of that floor from the running state of the elevator 15, so the floor controller 11 performs a restart (S113) and ends the process.

[0234] With this processing, when updating the firmware image 31, the floor controller 11 can perform a reboot to apply the new firmware image 31 without ensuring a special mode or operation time such as maintenance mode.

[0235] Furthermore, the present invention is not limited to the above-described embodiments. Various other applications and modifications may be adopted as long as they do not depart from the spirit of the present invention as described in the claims.

[0236] For example, the structures of the apparatus and system described in detail above are for the purpose of easily understanding and illustrating the present invention, and are not limited to having all the structures described. Furthermore, a portion of the structure of the embodiments described herein can be replaced with the structure of other embodiments, and it is also possible to add structures of other embodiments to the structure of a certain embodiment. Additionally, for a portion of the structure of each embodiment, other structures can be added, deleted, or replaced.

[0237] In addition, the control lines and information lines shown are those deemed necessary for the description, but do not necessarily represent all control lines and information lines on the product. In fact, it can be assumed that almost all structures are interconnected.

[0238] Explanation of reference numerals in the attached figures

[0239] 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…Main Controller, 31…Firmware Image, 32…Image Segmentation Unit, 33…Operating Status Acquisition Unit, 34…Sequence Generation Unit, 35…Data Packet Generation Unit, 36…Main Communication Unit, 40…Secondary Controller, 41…Secondary Communication Unit, 42…Data Packet Interpretation Unit, 43…Destination Extraction Unit, 44…Data Packet Generation Unit, 45…Image Construction Unit, 50…Data Packet, 100…Elevator System, 200…Data Packet Communication System.

Claims

1. An elevator system comprising a main controller for sending firmware and a secondary controller for receiving the firmware to update the firmware, characterized in that: The main controller generates a sending order for sending the firmware to multiple sub-controllers based on the elevator's operating status. For the sub-controller with the highest sending order, first sending data including the firmware and the sending order is sent. The secondary controller with priority in transmission order receives the first transmission data from the primary controller to update the firmware, and then sends the first transmission data to the secondary controller with second priority in transmission order.

2. The elevator system as described in claim 1, characterized in that: The main controller includes: The elevator's operating status is acquired by the operating status acquisition unit. The sequence generation unit generates the transmission sequence of the sub-controller, which is the transmission destination of the firmware, based on the operating state; A firmware segmentation portion that divides the firmware; A first transmission data generation unit generates first transmission data for transmitting the firmware to the sub-controller according to the transmission order; and The first communication unit sends the first transmission data to the secondary controller that is first in the transmission sequence. The first transmission data generation unit generates the first transmission data, which includes information for identifying the main controller, information for identifying the secondary controller, the transmission order, the construction order of the segmented firmware, and the segmented firmware.

3. The elevator system as described in claim 2, characterized in that: The secondary controller includes: The second communication unit receives the first transmission data from the main controller or the sub-controller that serves as the transmission source of the first transmission data; The data interpretation section interprets the first transmitted data; The firmware building unit builds the segmented firmware, which has been interpreted by the data interpretation unit, into the original firmware according to the building order. A destination extraction unit, which extracts the sub-controller as the next destination for the first transmitted data based on the transmission order obtained from the interpretation of the data interpretation unit; and The second transmission data generation unit generates second transmission data for sending the firmware to the sub-controller, which is the next transmission destination of the first transmission data. The second communication unit sends the second transmission data to the sub-controller, which is the next transmission destination.

4. The elevator system as described in claim 3, characterized in that: If an error occurs during the firmware update process by the firmware building unit, the second communication unit sends data including information about the error to the main controller in the reverse order of the transmission.

5. The elevator system as described in claim 4, characterized in that: If an error occurs during the firmware update process, the firmware built by the firmware building unit will be deleted.

6. The elevator system as described in claim 3, characterized in that: If the second communication unit receives data including information about an anomaly that occurred during the firmware update from the sub-controller, which is the next destination of the first transmission data, it skips the sub-controller from which the data including the information about the anomaly is transmitted, and instead transmits the second transmission data to the subsequent sub-controller.

7. The elevator system as described in claim 3, characterized in that, include: An elevator controller that controls the movement of the elevator; and Multiple floor controllers are installed on each floor where the elevator moves up and down, and these controllers notify the elevator controller of the status of each floor. In the case where one of the elevator controllers and multiple floor controllers storing the firmware is used as the main controller and the other controllers are used as secondary controllers, the main controller sends the first transmission data including the transmission order to the secondary controllers, and the secondary controllers that receive the first transmission data update the firmware.

8. The elevator system as described in claim 7, characterized in that: The main controller generates the dispatch order based on the elevator call registration status of each floor as obtained as the operating state, and rearranges the dispatch order based on the number of people staying on each floor.

9. The elevator system as described in claim 7, characterized in that: The firmware building unit confirms elevator call registration when the firmware update of the floor controller is completed, and restarts the floor controller if no elevator call is registered.

10. The elevator system as described in claim 3, characterized in that, include: A group management controller that controls the actions of multiple elevator controllers that control the actions of the elevator; and Multiple elevator controllers, In the case where one of the group management controllers and multiple elevator controllers storing the firmware is used as the main controller and the other controllers are used as secondary controllers, the main controller sends the first transmission data including the transmission order to the secondary controllers, and the secondary controllers that receive the first transmission data update the firmware.

11. The elevator system as described in claim 10, characterized in that: The sequence generation unit generates the sending sequence based on the call allocation status of the multiple elevators obtained as the operating state.

12. The elevator system as described in claim 10, characterized in that: If the firmware building unit registers the destination floor of the elevator when the firmware update of the elevator controller is completed, it temporarily stops the elevator controller from accepting new calls. After the car arrives at the destination floor and the safety status of the car is confirmed, the elevator controller restarts.

13. The elevator system as described in claim 3, characterized in that, include: A communication controller that controls the communication between multiple group management controllers that control the actions of multiple elevator controllers. and Multiple group management controllers, In the case where one of the communication controllers and multiple group management controllers storing the firmware is used as the master controller and the other controllers are used as slave controllers, the master controller sends the first transmission data including the transmission order to the slave controllers, and the slave controllers that receive the first transmission data update the firmware.

14. The elevator system as described in claim 13, characterized in that: The sequence generation unit generates the sending sequence based on the number of times elevator calls are allocated to the multiple group management controllers, which is obtained as the operating state. If the firmware building unit does not perform elevator call allocation processing when the firmware update of the group management controller is completed, the group management controller whose firmware update has been completed shall be restarted.

15. A firmware transmission method performed in an elevator system having a main controller for transmitting firmware and a secondary controller for receiving the firmware to update the firmware, characterized in that, include: The main controller generates a sending order for sending the firmware to multiple sub-controllers based on the elevator's operating status, and processes the sending of first sending data, including the firmware and the sending order, to the sub-controller with the priority of the sending order. and The secondary controller with priority in transmission order receives the first transmission data from the primary controller to update the firmware, and processes the transmission of the first transmission data to the secondary controller with second priority in transmission order.

Images