WO2023166795A1 - エレベーターシステム及びファームウェア送信方法 - Google Patents

エレベーターシステム及びファームウェア送信方法 Download PDF

Info

Publication number
WO2023166795A1
WO2023166795A1 PCT/JP2022/043113 JP2022043113W WO2023166795A1 WO 2023166795 A1 WO2023166795 A1 WO 2023166795A1 JP 2022043113 W JP2022043113 W JP 2022043113W WO 2023166795 A1 WO2023166795 A1 WO 2023166795A1
Authority
WO
WIPO (PCT)
Prior art keywords
controller
sub
firmware
elevator
controllers
Prior art date
Application number
PCT/JP2022/043113
Other languages
English (en)
French (fr)
Inventor
英光 納谷
貴大 羽鳥
訓 鳥谷部
祐太 助川
Original Assignee
株式会社日立製作所
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 株式会社日立製作所 filed Critical 株式会社日立製作所
Publication of WO2023166795A1 publication Critical patent/WO2023166795A1/ja

Links

Images

Classifications

    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B66—HOISTING; LIFTING; HAULING
    • B66B—ELEVATORS; ESCALATORS OR MOVING WALKWAYS
    • B66B3/00—Applications of devices for indicating or signalling operating conditions of elevators
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B66—HOISTING; LIFTING; HAULING
    • B66B—ELEVATORS; ESCALATORS OR MOVING WALKWAYS
    • B66B5/00—Applications of checking, fault-correcting, or safety devices in elevators
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates

Definitions

  • the present invention relates to an elevator system and a firmware transmission method.
  • elevator systems consist of multiple controllers.
  • a system is known in which the programs are updated in a one-to-N configuration, in which any one controller updates the programs of a plurality of controllers.
  • a server stores a pre-update version of a control program on the representative elevator and the latest version of the control program to be updated for one predetermined representative elevator among a plurality of elevators. Update data including difference information from the program is distributed via a communication line, and the representative elevator updates its own control program based on the update data received from the server, and transfers it to the next in accordance with a predetermined transfer order. Update data is sent over the network to elevators that should be updated.”
  • the transmission procedure control means includes a transmission time for transmitting an operation control program for updating to a plurality of control devices via a transmission path, and a rewrite for rewriting the operation control program for updating by the plurality of control devices. Calculate the stop time of the elevator from the time, and select the order of transmitting the operation control program for update to the plurality of control devices based on the calculated stop time.”
  • Patent Document 2 describes calculating the stop time of the elevator based on the transmission time and the rewriting time.
  • program capacity, communication device performance, and storage device rewrite performance must meet predetermined conditions. As with the technique described in Patent Literature 1, there were cases where it was not suitable for actual operational conditions.
  • the present invention has been made in view of this situation, and aims to change the order of controllers whose firmware is updated according to the operational status of the elevator.
  • An elevator system includes a master controller that transmits firmware, and sub-controllers that receive and update 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-controllers in which the transmission order is prioritized.
  • the sub-controller whose transmission order is given 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 is given next priority.
  • the firmware transmission order is generated according to the operating state of the elevator, it is not necessary to determine the firmware transmission order in advance. Problems, configurations, and effects other than those described above will be clarified by the following description of the embodiments.
  • FIG. 3 is a block diagram showing an example hardware configuration of a controller according to an embodiment of the present invention
  • 1 is a block diagram showing a basic configuration example of a packet communication system including a master controller and sub-controllers according to one embodiment of the present invention
  • FIG. 4 is a diagram showing an example internal configuration of a packet according to one embodiment of the present invention
  • FIG. 4 is a diagram showing an example of packets generated by the master controller and each sub-controller according to one embodiment of the present invention; 4 is a flow chart showing an example of normal communication processing of the packet communication system according to one embodiment of the present invention; 4 is a flow chart showing an example of processing of a sub-controller according to one embodiment of the present invention; FIG. 4 is a diagram showing a packet configuration example of an anomaly notification message according to one embodiment of the present invention; 4 is a flow chart showing an example of processing for notifying occurrence of an abnormality by a sub-controller according to an embodiment of the present invention; 4 is a flowchart showing an example of anomaly handling processing performed by a sub-controller according to an embodiment of the present invention when packet transmission fails.
  • FIG. 4 is a diagram showing an example of packets generated by the master controller and each sub-controller according to one embodiment of the present invention.
  • FIG. 10 is a flowchart showing an example of processing for skipping a sub-controller in which a communication error has occurred and continuing firmware image update processing according to an embodiment of the present invention
  • FIG. 1 is a block diagram showing an example of a tree structure composed of an elevator controller and a plurality of floor controllers according to an embodiment of the invention
  • 6 is a flow chart showing an example of a process for generating an order according to the presence or absence of call registration for a floor according to an embodiment of the present invention
  • 6 is a flowchart showing an example of processing for generating an order according to the number of people staying on a floor according to an embodiment of the present invention
  • 4 is a block diagram showing an example of a tree structure composed of a group supervisory controller and a plurality of elevator controllers according to an embodiment of the present invention
  • FIG. 6 is a flowchart showing an example of a process of generating an order according to the assigned number of elevator calls according to an embodiment of the present invention
  • 4 is a block diagram showing an example of a tree structure composed of a communication controller and a plurality of group supervisory controllers according to one embodiment of the present invention
  • FIG. 4 is a flow chart showing an example of the number of calls to be assigned to elevators and an example of a process of generating an order according to an assignment processing state according to an embodiment of the present invention
  • 7 is a flow chart showing an example of a process of determining restart for applying a firm image by the group supervisory controller according to one embodiment of the present invention.
  • FIG. 10 is a flow chart showing an example of a process of determining a restart for applying a firm image by an elevator controller according to an embodiment of the present invention
  • FIG. 4 is a flow chart showing an example of a process of restarting the floor controller to apply the firmware image according to one embodiment of the present invention
  • FIG. 1 is a diagram showing an overall configuration example of an elevator system 100 according to one embodiment of the present invention.
  • FIG. 1 in order to simplify the description of the elevator system 100, detailed constituent elements of one elevator 15 are illustrated, and illustration of detailed constituent elements of the other elevators 15 is omitted.
  • the elevator system 100 has, for example, a center 1 installed remotely from the elevators 15 to manage, monitor operation of, and maintain the elevators 15 .
  • the elevator system 100 also has a communication controller 3 , a group controller 4 , an elevator controller 5 , a car controller 10 , a floor controller 11 and a maintenance terminal 19 .
  • a center 1 is connected to a communication controller 3 via a communication network 2 which is 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 communication for executing data transfer, remote control and remote maintenance between the center 1 and elevators.
  • the communication controller 3 is connected to the group supervisory controller 4 via the communication path 17 .
  • a communication controller 3 controls communication with a plurality of group supervisory controllers 4 that control operations of a plurality of elevator controllers 5 .
  • the group management controller 4 controls the operations of a plurality of elevator controllers 5 that control the operations of the elevators 15 . Therefore, the group controller 4 collectively controls the operation of the plurality of elevators 15 as an elevator group 18 .
  • the group supervisory controller 4 is connected to a plurality of elevator controllers 5 via communication paths 16 .
  • the elevator 15 comprises 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 vertical movement services to users by controlling the vertical movement and stopping of the car 7. To provide this service, the elevator controller 5 controls the main motor 6 to manipulate 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 a plurality of floor controllers 11 via communication paths 12 .
  • the car controller 10 opens and closes the car door according to the user's operation of the destination floor button and the door open/close button 13 installed in the car 7, and notifies the elevator controller 5 of changes in the car situation. tell.
  • the floor controller 11 is provided for each floor that the elevator 15 ascends and descends, and communicates the status of the floor to the elevator controller 5. For example, the floor controller 11 monitors the operation status of the up/down button 14 installed on each floor by the user on each floor, and notifies the elevator controller 5 of changes in the status of the floor. Instead of the up and down buttons 14, some elevator systems have a destination floor registration device that allows passengers to register their destination floor before boarding the car.
  • the elevator system 100 is a system in which a tree structure in which a plurality of controllers are in a one-to-N configuration is layered in multiple stages. Further, when there are a plurality of controllers of the same type, it is possible to form a 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 holds firmware used in each controller as a firmware image 31 (see FIG. 3, which will be 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, 17, and various controllers connected to the communication paths.
  • the maintenance terminal 19 connected to the communication network 2 can copy the firmware from the center 1. After copying the firmware, the maintenance terminal 19 is connected to an arbitrary controller so that the firmware held by the maintenance terminal 19 can be output to the connected controller. Therefore, the maintenance terminal 19 can cause the controller connected to the maintenance terminal 19 to hold the firmware. Also, the controller holding the firmware can update its own firmware and transmit the firmware to other controllers.
  • FIG. 2 is a block diagram showing a hardware configuration example 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 connected to the system bus 21 .
  • MPU Micro Processing Unit
  • ROM Read Only Memory
  • RAM Random Access Memory
  • communication interface 25 which are connected to the system bus 21 .
  • CPU Central Processing Unit
  • CPU Central Processing Unit
  • the MPU 22, ROM 23, and RAM 24 constitute a processing unit.
  • the MPU 22 has a firmware image 31 (see FIG. 3 described later), which is binary data of program codes for realizing each function, recorded in the ROM 23 , read from the ROM 23 and loaded into the RAM 24 . and run the program code. Also, the MPU 22 may directly read the program code from the ROM 23 and execute the program code as it is.
  • Variables, parameters, etc. generated during execution of processing performed by the MPU 22 are temporarily written in the RAM 24, and these variables, parameters, etc. are read from the MPU 22 as appropriate.
  • the controllers 20 can transmit and receive data between multiple controllers 20 through the communication interface 25 .
  • a communication path connecting each controller 20 for example, a multi-drop type serial communication device such as RS-485, or a wired communication path providing multiple topologies such as Ethernet (registered trademark) LAN ( Local Area Network), WAN (Wide Area Network), and RAN (Radio Area Network), which is a wireless communication channel.
  • Each controller 20 can transmit and receive data of each controller between devices by, for example, wireless such as Wi-Fi (registered trademark) or infrastructure wireless communication.
  • the controller 20 is equipped with a plurality of ROMs 23 in order to deal with problems that occur when data is rewritten to the ROMs 23 .
  • the current firmware image 31 (an example of firmware) is recorded in the ROM 23 on one side, and the new firmware image 31 is recorded in the ROM 23 on the other side. Even if a problem occurs when the latter ROM 23 is rewritten with the new firmware image 31, the former ROM 23 still retains the current firmware image 31, so the current state can be restored. If there are multiple ROMs 23, the controller 20 selects and activates the ROM 23 in which the desired firmware image 31 is stored.
  • FIG. 3 is a block diagram showing a basic configuration example of the packet communication system 200 including the master controller 30 and the sub-controller 40. As shown in FIG.
  • the packet communication system 200 is one form of the elevator system 100 including the master controller 30 that transmits the firm image 31 and the sub-controller 40 that receives the firm image 31 and updates the firm image 31 .
  • the elevator system 100 is a large-scale system in which a tree structure in which a plurality of controllers are connected in a one-to-N relationship is multiplexed.
  • a packet communication system 200 having one controller 20 as a master controller 30 and N controllers 20 as sub-controllers 40 will be described.
  • controllers 20 in the same layer or different layers are in a relationship of master and sub.
  • the relationship between master and sub may span one or more hierarchies as well as adjacent hierarchies. For example, it is possible to use one group supervisory controller 4 as the master controller 30 and a plurality of floor controllers 11 as sub-controllers 40 straddling the elevator controller 5 .
  • the master controller 30 generates the transmission order of the firmware images 31 to the plurality of sub-controllers 40 according to the operating state of the elevator 15 . Then, the master controller 30 transmits the packet 50 including the firmware image 31 and the transmission order to the sub-controller 40 whose transmission order is prioritized. Master controller 30 is connected to sub-controller 40 via communication path 37 . The sub-controller 40 to which the packet 50 is directly transmitted from the master controller 30 often has the highest transmission order. However, if an abnormality occurs in the sub-controller 40 that receives the packet 50, the master controller 30 may preferentially transmit the packet 50 to the sub-controller 40 that is next in transmission order to the sub-controller 40 in which the abnormality has occurred. be.
  • the master controller 30 transmits the packet 50 to the sub-controller 40 whose transmission order is given priority, so that the sub-controller 40 whose transmission order is given priority can receive the packet 50 . Also, since the sub-controller 40 that received the packet 50 transmits the packet 50 to the sub-controller 40 that has the next highest priority in transmission order, the packet 50 is transferred to a plurality of sub-controllers 40 . Therefore, compared to the case where the master controller 30 simultaneously distributes the packet 50 to the plurality of sub-controllers 40, it is possible to reliably transmit the packet 50 to each sub-controller 40.
  • the master controller 30 includes a farm image 31, an image dividing section 32, an operation status acquiring section 33, a sequence generating section 34, a packet generating section 35, and a master communication section .
  • the firmware image 31 is the substance of the 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. Since the image dividing unit 32 divides the firm image 31, the data amount of the binary data 57 (see FIG. 4A described later) of the packet 50 transmitted to the sub-controller 40 in one communication is reduced. Communication efficiency of the communication path 37 between the master controller 30 and the sub-controller 40 can be improved.
  • the operation state acquisition unit 33 acquires the operation state of the elevator.
  • the operating state of the elevator 15 includes, for example, car state, call allocation state, and the like.
  • the operating state acquisition unit 33 can acquire operating states from the car controller 10, the floor controller 11, and the like.
  • the order generation unit 34 generates the transmission order of the sub-controllers 40 to which the farm image 31 divided by the image division unit 32 is to be sent, according to the operation state of the elevator 15 acquired by the operation state acquisition unit 33 . Note that if the file size of the firm image 31 is sufficiently small, the firm image 31 that is not divided may be sent to the sub-controller 40 .
  • 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 .
  • Packet 50 is used as an example of first transmission data.
  • the packet generator 35 generates information (source 51) identifying the master controller 30, which is the source of the packet 50, and information identifying the sub-controller 40, which is the destination of the packet 50. (destination 52), transmission order (transmission order 53), construction order (number 56) of divided firm image 31, and divided firm 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 having the highest transmission order generated by the order generation unit 34 .
  • the sub-controller 40 whose transmission order is prioritized receives the packet 50 from the master controller 30, updates the firmware image 31, and transmits the packet 50 to the sub-controller 40 whose transmission order is prioritized next.
  • the sub-controller 40 includes a sub-communication section 41 , a packet interpretation section 42 , a destination extraction section 43 , a packet generation section 44 , an image construction section 45 and a firmware image storage section 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 the packet 50 from the master controller 30 or another sub-controller 40 that is the transmission source of the packet 50 via the communication path 37 .
  • the packet interpreter 42 is used as an example of a data interpreter that interprets the packet 50 received by the sub communication unit 41 .
  • Interpretation of the packet 50 is a process of extracting data from the packet 50 according to a prescribed packet format and outputting the data to a predetermined output destination.
  • the divided image data of the firm image 31 interpreted by the packet interpretation unit 42 is output to the image construction unit 45 .
  • 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, which 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. be done.
  • the packet generating unit 44 generates a new sub-controller 40 based on the interpretation result of the packet 50 by the packet interpreting unit 42 and the transmission order of the remaining sub-controllers 40 that are destinations of the packet extracted by the destination extracting unit 43.
  • a packet 50 is generated.
  • the divided image data of the firm image 31 included in the packet 50 generated by the packet generation unit 44 is basically the divided image data of the firm image 31 included in the packet 50 received by the sub communication unit 41. is the same as
  • 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 image 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 firm images 31 received from the packet interpretation unit 42 . Then, when the divided firm image 31 is sufficiently stored in the buffer, the firm image 31 is reconstructed.
  • the firm image storage unit 46 stores the firm image 31 constructed by the image constructing unit 45 .
  • the firmware image 31 updated by the sub-controller 40 is read from the firmware image storage unit 46 .
  • a plurality of firmware images 31 may be generation-managed for each version in the firmware image storage unit 46 . Therefore, if the update fails, the previous firmware image 31 can be restored.
  • the firmware image 31 can be transmitted based on the efficient transmission order of the sub-controller 40 according to the operation status of the elevator 15.
  • the packet generator 44 determines the order in which the packets 50 are transmitted to the sub-controller 40 using ascending/descending order according to the number of floors, the order of the serial numbers assigned to the controller 20, or random numbers. may be determined by
  • the relationship between the master controller 30 and the sub-controller 40 may be determined by the user who uses the maintenance terminal 19. Alternatively, the controller to which the firmware image 31 is downloaded from the maintenance terminal 19 may be automatically determined as the master controller 30 and the other controllers as the sub-controllers 40 .
  • FIGS. 4A and 4B are diagrams showing a basic configuration example of the packet 50.
  • FIG. 4A and 4B are diagrams showing a basic configuration example of the packet 50.
  • FIG. 4A is a diagram showing an example internal configuration of the packet 50.
  • the packet 50 includes the data of the source 51 of the packet 50, the data of the destination 52 of the packet 50, the data of the transmission order 53 of the packet 50, the image data 54 obtained by dividing the firmware image 31, and the data error of the packet 50. and check data 55 for confirming matching.
  • the image data 54 is one of a plurality of image data obtained by dividing the firm image 31 by the image dividing unit 32 shown in FIG. Therefore, the image data 54 is composed of a number 56 indicating the construction order in which the firm image 31 is divided, and binary data 57 which is the entity of the divided image.
  • the master controller 30 and the sub-controllers 40 can transmit the firmware image 31 according to the order of the plurality of sub-controllers 40 generated by the order generation section 34 . Therefore, each sub-controller 40 can update the firmware image 31 in the order in which the firmware image 31 is received.
  • the image data 54 or binary data 57 includes identification data indicating which of the communication controller 3, group controller 4, elevator controller 5, and floor controller 11 the firmware corresponds to. Therefore, the image construction unit 45 installed in each controller when it is the master controller 30 can identify firmware for another controller by the identification data.
  • FIG. 4B is a diagram showing a configuration example of a packet 50 generated by the master controller 30 and each subcontroller 40.
  • FIG. Here, it is assumed that the elevator 15 is provided in a building with four floors.
  • a master controller 30 corresponds to the elevator controller 5 and a sub-controller 40 corresponds to the floor controller 11 .
  • a transmission order 53 is generated in the order of 4th floor-2nd floor-3rd floor-1st floor.
  • “1” stored in number 56 indicates that it is the first binary data in the divided firm image 31 .
  • the master controller 30 sets its own ID number "0" as the transmission source 51, sets the first ID number "4" in the transmission order 53 as the transmission destination 52, and sets the transmission order 53 after the ID number "4".
  • a packet 50(1) is generated in which the order "2-3-1" is set. Therefore, the packet 50(1) is transmitted to the floor controller 11 on the fourth floor whose transmission order 53 is first.
  • the floor controller 11 on the fourth floor When the floor controller 11 on the fourth floor receives the packet 50(1), it sets its own ID number "4" to the source 51 and sets the first ID number "2" of the transmission order 53 to the destination 52. , a packet 50(2) in which the transmission order 53 is set to the order "3-1" after the ID number "2". Therefore, the packet 50(2) is transmitted to the floor controller 11 on the second floor whose transmission order 53 is the first.
  • the floor controller 11 on the second floor When the floor controller 11 on the second floor receives the packet 50(2), it sets its own ID number "2" as the transmission source 51 and sets the first ID number "3" in the transmission order 53 as the transmission destination 52. , a packet 50(3) in which the transmission order 53 is set to the order "1" after the ID number "3". Therefore, the packet 50(3) is transmitted to the floor controller 11 on the third floor whose transmission order 53 is the first.
  • the floor controller 11 on the third floor When the floor controller 11 on the third floor receives the packet 50(3), it sets its own ID number “3” to the source 51 and sets the first ID number “1” of the transmission order 53 to the destination 52 . , generates a packet 50(4) in which the transmission order 53 is not set because it is the last in the transmission order. Therefore, the packet 50(4) is transmitted to the first floor floor controller 11 whose transmission order 53 is the first.
  • the packet 50 transmitted from the master controller 30 is transmitted through the plurality of sub-controllers 40 in order based on the transmission order 53 according to the operating state of the elevator 15. be done. Therefore, the processing load on the master controller 30 can be reduced, and the sub-controller 40 can also efficiently execute processing based on the operating state of the elevator 15 .
  • the communication method according to the present embodiment does not occupy a network as compared to broadcasting in which packets are distributed all at once from the master controller 30 to the plurality of sub-controllers 40 . Also, the master controller 30 can easily manage the allocation of the transmission order of the firmware image 31 .
  • the transmission order 53 may simply be in the order of the IDs of the controllers 20 or the order of the floor numbers.
  • any sub-controller 40 directly communicates with the master controller 30, in addition to the transmission source 51 and the transmission destination 52, the item of the transmission source of the packet corresponding to the master controller 30 is included in the packet.
  • Communication from the sub-controller 40 to the master controller 30 is performed, for example, to notify the master controller 30 of the operational status of the elevators 15 within the range managed by the sub-controller 40 .
  • communication from the sub-controller 40 to the master controller 30 is used for status notification during normal operation of the elevator 15 . It is also used by the sub-controller 40 to directly send fault information to the master controller 30 without tracing back through the plurality of sub-controllers 40 .
  • FIG. 5 is a flowchart showing an example of normal communication processing of the packet communication system 200.
  • FIG. 5 shows a process in which the master controller 30 distributes the firmware image 31 to all the sub-controllers 40 by dividing the firmware image 31 and transmitting the packets 50 in the order generated based on the operating state of the elevator 15. represent.
  • the image dividing unit 32 (see FIG. 3) of the master controller 30 divides the firm image 31 into sizes suitable for communication (S1).
  • the image dividing unit 32 also generates, for example, numbers 56 in ascending order (see FIG. 4A) so that the dividing order can be known.
  • the number of the last divided firmware image 31 may be a special termination number. If the controller 20 on the receiving side of the packet 50 shares this terminal number, the controller 20 can receive the packet to the end even if the number of divided firmware images 31 is large.
  • the operating state acquisition unit 33 acquires the operating state of the elevator 15 (S2).
  • the order generation unit 34 generates the order of the sub-controllers 40 to communicate the divided firmware image 31 based on the operation status (S3).
  • the packet generator 35 generates the packet 50 to be transmitted to the next sub-controller 40 according to the order generated by the order generator 34 (S4).
  • the master communication unit 36 transmits the generated packet 50 to the next sub-controller 40 in order (S5).
  • the master communication unit 36 confirms whether or not the packet 50 has been successfully transmitted (S6). If the transmission of the packet 50 fails (NO in S6), the master communication unit 36 receives an abnormality notification from the sub-controller 40 (S7), and then terminates this process. After a certain period of time, the master controller 30 re-executes this process in order to resend the packet 50 .
  • the master communication unit 36 confirms whether or not there is a remainder after dividing the firmware image 31 (S8). If there is a remainder after dividing the firmware image 31 (YES in S8), the master controller 30 returns to step S1 and repeats the process. If there is no remaining (NO in S8), the master controller 30 terminates this process.
  • FIG. 6 is a flowchart showing an example of processing by the sub-controller 40. As shown in FIG.
  • the sub-communication unit 41 of the sub-controller 40 receives the packet 50 from the master controller 30 or the previous sub-controller 40 (S11).
  • the packet interpretation unit 42 interprets the packet 50 received by the sub-communication unit 41 (S12), and interprets each of the source 51, destination 52, transmission order 53, divided image data 54, and check data 55. Identify.
  • a detailed example of the process of interpreting the packet 50 in step S12 is shown in FIG. 8, which will be described later.
  • the destination extraction unit 43 extracts the next destination from the transmission order 53 identified by the packet interpretation unit 42 (S13). Further, the image construction unit 45 sequentially constructs the firm image 31 from the divided image data 54 (S14).
  • the processing of steps S13 and S14 is parallel processing, but may be serial processing.
  • the destination extraction unit 43 checks whether or not there is a next destination to which the divided image data 54 are to be sent according to the transmission order 53 (S15).
  • the packet generator 44 If there is a next destination (YES in S15), the packet generator 44 generates a new packet 50 with the destination 52 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 confirms whether or not the transmission of the packet 50 was successful (S18).
  • Step S19 has different destinations as shown in FIGS. 9 and 10, which will be described later.
  • step S18 if the transmission of the packet 50 is successful (YES in S18), or if it is determined in step S15 that there is no next sub-controller 40 to which the divided image data 54 is to be sent (NO in S15), packet interpretation is performed.
  • the unit 42 confirms whether or not the image data 54 is the end of the firm image 31 (S20).
  • the sub-controller 40 ends this processing after the packet interpretation unit 42 confirms whether the construction of the firmware image 31 by the image construction unit 45 has ended. On the other hand, if it is not the end of the firmware image 31 (NO in S20), the process returns to step S11 and the sub-controller 40 repeats the process.
  • the sub-communication unit 41 may store the source 51 interpreted by the packet interpretation unit 42 every time it receives the packet 50 containing the divided image data 54 .
  • the sub-communication unit 41 can also communicate with the master controller 30 by communicating in reverse order of the packet 50 .
  • the sub-communication unit 41 can notify the master controller 30 of occurrence of a problem with the sub-controller 40 .
  • the master controller 30 simply transmits the packet 50 to the first sub-controller 40 in the order according to the operating state of the elevator 15, and the firmware image 31 is transferred to the plurality of sub-controllers 40.
  • the firmware image 31 can be updated without distributing it to all.
  • a plurality of sub-controllers 40 communicate the firmware image 31 to other sub-controllers 40 according to the order generated by the master controller 30 . In this manner, the master controller 30 can update the firmware images 31 of all the sub-controllers 40 by combining efficient communication processing.
  • the packet 50 may be communicated without image division. In this case, the processing of the master controller 30 and the sub-controller 40 may end with one communication.
  • FIG. 7 is a diagram showing a packet configuration example of an anomaly notification message.
  • the sub-controller 40 that has detected a communication abnormality when receiving the packet 50 transmits an abnormality notification message to the preceding sub-controller 40 that is the transmission source of the packet 50 .
  • this anomaly notification message is composed of source 51 data, destination 52 data, image data 54 data, and check data 55 . 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 this command 58 .
  • the command 58 stores an "abnormality occurrence notification command”
  • the command data 59 stores the ID of the controller 20 in which the communication error has occurred.
  • FIG. 8 is a flow chart showing an example of the process by which the sub-controller 40 notifies the occurrence of an abnormality.
  • the packet interpretation process shown in step S12 of FIG. 6 will be described.
  • the packet interpretation unit 42 of any controller 20 interprets the packet 50 and confirms the data in the transmission order 53 (S21).
  • the packet interpretation unit 42 checks whether or not the ID of the destination sub-controller 40 is stored in the data of the transmission order 53 in the transmission order of the packet 50 (S22). If the IDs of the sub-controllers 40 are stored in the data of the transmission order 53 in the transmission order (YES in S22), this processing is exited and the process proceeds to step S13 in FIG.
  • the sub-communication unit 41 transmits the data including the information about the abnormality to the master controller 30 in reverse order to the transmission order. Therefore, the master controller 30 can immediately recognize an abnormality that has occurred in the sub-controller 40 and can respond to an instruction such as stopping the transmission of the packet 50 .
  • 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 interpreting unit 42 generates an anomaly notification message in which the transmission source 51 is the sub-controller 40 itself that executes this processing, and the transmission destination 52 is the previous sub-controller 40 that transmitted the packet 50 ( S24).
  • the sub-communication unit 41 of the sub-controller 40 transmits the abnormality notification message to the sub-controller 40 whose transmission order is earlier (S25). After that, the image constructing section 45 deletes the firmware image 31 that has been constructed so far (S26), and terminates the process. Therefore, the processing after steps S13 and S14 in FIG. 6 is not performed.
  • the sub-controller 40 can delete the firmware image 31 that is being processed when a communication abnormality occurs. Also, the sub-controller 40 can notify the master controller 30 of an abnormality notification message.
  • FIG. 9 shows processing when the sub-controller 40 that received the packet 50 deletes the image in the middle of construction and skips the sub-controller 40 where the communication error occurred in the abnormal state where the communication error occurred.
  • FIG. 9 is a flowchart showing an example of anomaly handling processing performed by the sub-controller 40 when transmission of the packet 50 fails.
  • this abnormality handling process when the sub-controller 40 fails to transmit the packet 50, the process of deleting the image data 54 that has been transmitted to the destination sub-controller 40 is performed. Since the processing before step S17 is as shown in FIG. 6, detailed description thereof will be omitted.
  • the sub-communication unit 41 of any controller 20 transmits the generated packet 50 to the next controller 20 (S17).
  • Optional controllers 20 include, for example, the communication controller 3, the group controller 4, the elevator controller 5, the car controller 10, and the floor controller 11.
  • the sub communication unit 41 confirms whether or not the packet 50 has been successfully transmitted (S18).
  • the controller 20 proceeds to the processes after step S20 in FIG.
  • the sub-communication unit 41 transmits the data including the information about the abnormality to the master controller 30 in reverse order to the transmission order. Therefore, the master controller 30 can immediately recognize an abnormality that has occurred in the sub-controller 40 and can respond to an instruction such as stopping the transmission of the packet 50 . Further, the sub-controller 40 deletes the firmware image 31 constructed by the image construction unit 45 when an abnormality occurs during updating of the firmware image 31 . Therefore, the sub-controller 40 does not perform update processing using the incorrect firmware image 31 .
  • the packet generation unit 44 of the controller 20 generates an abnormality notification message packet 50 for notifying the previous controller 20 of the communication abnormality (S31).
  • the sub-communication unit 41 transmits the abnormality notification message packet 50 to the previous controller 20 (S32).
  • the image construction unit 45 then deletes the firmware image 31 that has been constructed so far (S33), and terminates this process.
  • FIG. 10 is a flow chart showing an example of processing for skipping the sub-controller 40 in which a communication error has occurred and continuing the update processing of the firmware image 31 .
  • the packet 50 is preferentially transmitted to the sub-controller 40 in which no communication error has occurred.
  • controller 20 is sub-controller 40 .
  • the sub-controller 40 receives data containing information about an abnormality that occurred during updating of the firmware image 31 from the sub-controller 40, which is the next destination of the packet 50, the sub-controller 40 transmits data containing information about the abnormality.
  • the packet 50 is transmitted to the subsequent sub-controller 40 by skipping the sub-controller 40 that has passed through.
  • step S16 Since the processing before step S16 is as shown in FIG. 6, detailed description thereof will be omitted.
  • the packet generation unit 44 of any controller 20 generates the packet 50 (S16), and the sub communication unit 41 transmits the packet 50 (S17). Next, the sub communication unit 41 confirms whether or not the packet 50 has been successfully transmitted (S18).
  • step S18 If the transmission of the packet 50 is successful (YES in S18), the controller 20 proceeds to the processing from step S20 in FIG. On the other hand, if the transmission of the packet 50 fails (NO in S18), the controller 20 performs an abnormality handling process in step S19.
  • the packet generation unit 44 of the controller 20 generates an abnormality notification message packet 50 for notifying the communication abnormality to the controller 20 that follows the controller 20 in which the communication abnormality has occurred (S41).
  • the command 58 is the "skip occurrence notification command”
  • the command data 59 is the "ID of the controller 20 in which the communication error has occurred”.
  • the sub-communication unit 41 transmits the abnormality notification message packet 50 to the controller 20 next in order to the controller 20 in which the communication abnormality has occurred (S42). Then, the image construction unit 45 updates the data to the transmission order 53 skipping the controller 20 that failed to transmit the packet 50 (S43), and proceeds to step S16.
  • the controller 20 After that, the controller 20 generates the packet 50 in step S16 based on the updated transmission order 53.
  • This packet 50 is for the controller 20 to retransmit the firmware image 31 to the skip destination controller 20 , and the destination of the packet 50 transmitted in step S ⁇ b>17 is the skip destination controller 20 .
  • the master controller 30 can continue to update the firmware image 31 for the sub-controller 40 even when a communication error occurs. Also, the sub-controller 40 can notify the master controller 30 of the information of the sub-controllers 40 skipped due to this communication abnormality. Therefore, the master controller 30 can update the firmware image 31 again for the sub-controllers 40 skipped by the processing flow shown in FIG.
  • the master controller 30 When the master controller 30 updates the firmware image 31 again, the master controller 30 needs to send the packet 50 with the command 58 as the "image erase command" to the sub-controller 40.
  • the image erase command is used by the master controller 30 to instruct the sub-controller 40 to erase the residual firm image 31 when the residual firm image 31 remains in the sub-controller 40 .
  • FIG. 11 is a block diagram showing an example of a tree structure composed of the elevator controller 5 and a plurality of floor controllers 11. As shown in FIG. 11
  • One elevator 15 has a tree structure in which one elevator controller 5 and floor controllers 11(1) to 11(M), which exist for the number M of floors, are connected by a communication path 12.
  • the firmware image 31 is downloaded from the upper group controller 4 to the elevator controller 5 .
  • the elevator controller 5 or the plurality of floor controllers 11 one in which the firmware image 31 is stored is the master controller 30 , and the other is the sub-controller 40 .
  • the elevator controller 5 becomes the master controller 30 and the floor controller 11 becomes the sub-controller 40 .
  • the master controller 30 transmits a packet 50 containing the transmission order to the sub-controller 40 , and the sub-controller 40 receiving the packet 50 updates the firmware image 31 .
  • the sub-controller 40 is not limited to one controller. update processing of the firmware image 31 can be performed.
  • any floor controller 11 may download the firmware image 31 via the elevator controller 5 .
  • one floor controller 11 becomes the master controller 30
  • the other floor controllers 11 and the elevator controller 5 become sub-controllers 40 .
  • the lower controller (floor controller 11) in the tree structure is the master controller 30, and the upper controller (elevator controller 5) is the sub-controller 40.
  • the floor controller 11 serving as the master controller 30 can acquire call registration information for each floor from the elevator controller 5 .
  • the elevator controller 5 can also acquire call registration information from each floor controller 11 . Therefore, according to the present embodiment, the packet communication system 200 can operate without being limited by the distinction between the upper level and the lower level of the tree structure.
  • controller 20 connected to the maintenance terminal 19 and having downloaded the firmware image 31 becomes the master controller 30
  • another controller 20 connected to the same segment as this controller 20 becomes the sub-controller 40
  • the other controllers 20 connected to the same segment are the group supervisory controller 4 when the master controller 30 is the communication controller 3 .
  • the master controller 30 is the group controller 4
  • it is the elevator controller 5 .
  • the master controller 30 is the elevator controller 5 , it is the car controller 10 and the floor controller 11 .
  • FIG. 12 is a flow chart showing an example of the order generation processing according to the presence or absence of floor call registration.
  • the elevator controller 5 used as the master controller 30 generates a transmission order according to the call registration status of each floor acquired as the operation status from the floor controller 11, and according to the status of the number of people staying on the floor, Rearrange the transmission order. Therefore, the transmission order is generated according to the processing load of the call registration of the floor controller 11 .
  • the firmware image 31 is updated in order from the floor controller 11 with the lowest load. It will be done.
  • the operation state acquisition unit 33 of the elevator controller 5 acquires call registration information for each floor from the floor controller 11 for each floor (S51). Next, the elevator controller 5 determines whether or not call registration information for all floors has been acquired (S52).
  • the order generation unit 34 of the elevator controller 5 rearranges the transmission order of the floor controllers 11 according to the acquired call registration information to obtain the transmission order. 53 data is generated (S53), and this process is terminated.
  • the transmission order is rearranged according to the presence or absence of call registration and the ascending order of call registration.
  • step S52 the elevator controller 5 returns to step S51 again, and repeats steps S51 and S52 until call registration information for all floors is acquired. Continue processing.
  • the order generation unit 34 generates the data of the transmission order 53 according to the allocation of the call registration information to the floor, so that the floor controllers 11 with no processing allocation are given the first order, and the floor controllers with many processing allocations. 11 in the following order, the firm images 31 can be applied. If the group controller 4 collectively manages the call registration information for each floor, the elevator controller 5 may collectively acquire the call registration information for each floor from the group controller 4 .
  • the order generating unit 34 can update the firm image 31 from the floor controller 11 to which processing is not assigned by setting the order of transmission of the firm image 31 to the order according to the operation information of the elevator 15 . Therefore, the elevator controller 5 can efficiently communicate update data. Also, since the elevator controller 5 applies the updated new firmware image 31 to the floor controller 11, the possibility of restarting the floor controller 11 immediately increases.
  • FIG. 13 is a flow chart showing an example of processing for generating an order according to the number of people staying on the floor.
  • the operation state acquisition unit 33 of the elevator controller 5 acquires the number of people staying on each floor from the other elevator controller 5 or the floor controller 11 on each floor (S61).
  • the elevator controller 5 confirms whether or not the number of people staying on all floors has been obtained (S62). If there is a floor for which the number of people staying has not been obtained (NO in S62), the elevator controller 5 returns to step S61 again and continues the processing of steps S61 and S62 until the number of people staying on all floors is obtained.
  • the order generator 34 of the elevator controller 5 rearranges the transmission order of the packets 50 to the floor controller 11 according to the number of visitors on each floor. (S63), the data of transmission order 53 is generated. After that, this process is terminated.
  • the order of transmission for sorting is, for example, ascending order of the number of people staying.
  • the floor controllers 11 that have sufficient processing capacity are placed first, and the floor controllers 11 that may have a large processing load are placed last.
  • a firm image 31 can be applied. If the group controller 4 collectively manages the number of visitors on each floor, the elevator controller 5 may acquire the number of visitors on each floor from the group controller 4 . Further, when the elevator controller 5 itself manages the number of people staying on each floor, the management data may be used.
  • the elevator controller 5 rearranges the order of transmission to the floor controller 11 according to the operation information of the elevator 15 (the number of people staying on each floor), thereby updating the firmware image 31 from the floor controller 11 with sufficient processing capacity. can. Therefore, the elevator controller 5 can efficiently transmit the update data of the firmware image 31 to the floor controller 11 . Also, the floor controller 11 that receives the update data of the firmware image 31 is more likely to be restarted immediately to apply the updated new firmware image 31 .
  • FIG. 14 is a block diagram showing an example of a tree structure composed of a group supervisory controller 4 and a plurality of elevator controllers 5.
  • the elevator group 18 shown in FIG. 1 includes one group controller 4 and a plurality of elevator controllers provided corresponding to an arbitrary number of elevators 15(1) to 15(M). 5 and
  • the master controller 30 transmits a packet 50 containing the transmission order to the sub-controller 40 , and the sub-controller 40 that receives the packet 50 updates the firmware image 31 .
  • the firmware image 31 is downloaded from the upper communication controller 3 to the group supervisory controller 4 .
  • the group supervisory controller 4 is the master controller 30 and the plurality of elevator controllers 5 are the sub-controllers 40 .
  • the update processing of the firmware image 31 of the sub-controller 40 is not limited to one controller. It is possible to do
  • An arbitrary elevator controller 5 may download the firmware image 31 via the group controller 4 .
  • one elevator controller 5 serves as the master controller 30
  • the other elevator controllers 5 and the group supervisory controller 4 serve as sub-controllers 40 .
  • one elevator controller 5 serving as the master controller 30 receives calls assigned to each elevator controller 5 from the group control controller 4 serving as the sub-controller 40 or other elevator controllers 5. number can be obtained.
  • the controller 20 connected to the maintenance terminal 19 and downloading the firmware image 31 becomes the master controller 30
  • the other controllers 20 connected to the same segment as this controller 20 become the sub-controllers 40 .
  • the elevator controller 5, the car controller 10, or the floor controller 11 is assumed as the controller 20 that downloaded the firmware image 31, for example.
  • FIG. 15 is a flow chart showing an example of the order generation process according to the assigned number of calls for the elevator 15 .
  • the order generating unit 34 of the master controller 30 generates a transmission order according to the state of allocation of calls to the plurality of elevators 15 acquired as the operation status. Therefore, the transmission order is generated according to the processing load of the elevator controller 5 .
  • the operation status acquisition unit 33 of the group controller 4 acquires the number of calls assigned to each elevator 15 (S71).
  • the order generation unit 34 of the group controller 4 rearranges the transmission order of the elevator controllers 5 according to the number of calls assigned to generate the data of the transmission order 53 (S72), and terminates this process.
  • the order of transmission shall be in ascending order of the assigned number of calls. As the number of calls assigned increases, the number of times the car 7 moves to, stops, and departs from the floor to which the call is assigned increases. Conversely, the smaller the assigned number of calls, the smaller the processing load on the elevator controller 5 . Also, the elevator controller 5 is more likely to stop, that is, transition to a standby state.
  • the order generation unit 34 of the group controller 4 sets the order of transmission of the firmware image 31 to the elevator controller 5 according to the operation state of the elevator 15, so that there is a margin for processing, or the queue is on standby immediately.
  • the firmware image 31 can be updated from the elevator controller 5 which is likely to be in the state. Therefore, the elevator controller 5 can efficiently communicate update data. Also, the group supervisory controller 4 is more likely to be able to restart the elevator controller 5 soon to apply the updated new firmware image 31 to the elevator controller 5 .
  • FIG. 16 is a block diagram showing an example of a tree structure composed of the communication controller 3 and a plurality of group controllers 4. As shown in FIG. Here, one communication controller 3 shown in FIG. 1 and a plurality of group supervisory controllers 4 provided corresponding to an arbitrary number of elevator groups 18(1) to 18(M) are shown. . Note that the values of M representing the number of controllers and groups shown in FIGS. 11, 14, and 16 may be different.
  • one of the communication controllers 3 or a plurality of group supervisory controllers 4 in which the firmware image 31 is stored is the master controller 30 and the others are the sub-controllers 40 .
  • the master controller 30 transmits a packet 50 containing the transmission order to the sub-controller 40
  • the sub-controller 40 that receives the packet 50 updates the firmware image 31 .
  • the firmware image 31 is downloaded from the upper communication controller 3 to the group supervisory controller 4 .
  • the communication controller 3 becomes the master controller 30 and the plurality of group supervisory controllers 4 become the sub-controllers 40 .
  • an arbitrary group supervisory controller 4 may download the firmware image 31 via the communication controller 3 .
  • one group supervisory controller 4 becomes the master controller 30
  • the other group supervisory controllers 4 and communication controllers 3 act as sub-controllers 40 .
  • the controller 20 connected to the maintenance terminal 19 and downloading the firmware image 31 becomes the master controller 30
  • the other controllers 20 connected to the same segment as this controller 20 become the sub-controllers 40 .
  • the communication controller 3 is assumed as the controller 20 that has downloaded the firmware image 31 .
  • the order generating unit 34 of the communication controller 3 determines the number of calls allocated to the plurality of group controllers 4 as a result of the allocation processing of the group controller 4, which is one of the operation states. 17, the process of generating the data of the transmission order 53 based on the assigned number of calls and the status of assignment processing will be described. Here, for this reason, the transmission order is generated according to the processing load due to the number of calls assigned to the group controller 4 .
  • FIG. 17 is a flow chart showing an example of the number of calls to be assigned to the elevator 15 and the order generation processing according to the assignment processing state.
  • the operation status acquisition unit 33 of the communication controller 3 acquires the number of calls assigned and the status of assignment processing from each group controller 4 (S81).
  • the operating state acquisition unit 33 confirms whether or not the call allocation number and the allocation processing state have been acquired from all the group controllers 4 (S82). If the information has not been obtained from all the group controllers 4 (NO in S82), the operation status acquisition unit 33 returns to step S81 and repeats acquisition of the call allocation number and allocation processing status.
  • the order generation unit 34 of the communication controller 3 selects group controllers according to the allocation number and the allocation processing state acquired by the operation state acquisition unit 33. 4 is rearranged to generate data with a transmission order of 53 (S83), and this processing ends.
  • Transmission order is sorted in ascending order of the presence or absence of call allocation processing and the number of allocations.
  • the group controller 4 that has completed the call allocation process has a margin in the processing load. Even if the group controller 4 has already completed the call allocation process, the group controller 4 with a larger number of call allocations has fewer options to allocate, so the processing load of the group controller 4 increases. unlikely. In other words, since there are few options to which calls can be assigned, the possibility that the processing load on the group controller 4 will increase is reduced.
  • the group controller 4 that is in the process of allocating a call has a greater processing load than the group controller 4 that has completed the allocation process. Even if the group controller 4 is in the process of assigning a call, the group controller 4 to which the number of assigned calls already assigned is smaller has more choices for future call assignment. load is likely to increase.
  • the order generation unit 34 generates the data of the transmission order 53 according to whether or not the call allocation process is performed and the number of call allocations, so that the group controller 4 that has completed the allocation process can be generated.
  • the firmware images 31 can be applied in the order of the first and the group controller 4 that is in process and has a small number of allocations and has a large processing load last.
  • the firmware image 31 can be efficiently updated from the group controller 4 that has sufficient processing time. Therefore, the communication controller 3 is more likely to restart the group controller 4 immediately in order to apply the updated new firmware image 31 to the group controller 4 .
  • FIG. 18 is a flow chart showing an example of a process of judging restart for application of the firmware image 31 by the group controller 4 .
  • the call assignment process is not executed when the update of the firmware image 31 for the group controller 4 is completed, the image construction unit 45 of the group controller 4 whose firmware image 31 has been updated is restarted. Start up. As a result, the group controller 4 is restarted during a time when there are no users in the elevator 15 managed by the group controller 4, which does not cause inconvenience to the users.
  • the group supervisory controller 4 acquires the execution state of the call assignment process (S91).
  • the group controller 4 confirms whether or not call allocation processing is being executed (S92). If the call allocation process is being executed (YES in S92), the process is terminated without restarting. After a certain period of time, the group controller 4 restarts the process from step S91. On the other hand, if the call assignment process is not being executed, that is, the call assignment process has been completed and the call has been assigned (NO in S92), the group controller 4 is restarted (S93), and this process ends. .
  • the group supervisory controller 4 can be restarted to apply the new firmware image 31 without securing a special mode or work time as in the maintenance mode. It becomes possible to
  • FIG. 19 is a flow chart showing an example of the process of judging restart for applying the firmware image 31 by the elevator controller 5 .
  • the image construction unit 45 of the elevator controller 5 accepts a new call for the elevator controller 5. on hold.
  • the image construction unit 45 of the elevator controller 5 restarts the elevator controller 5 when the safety state of the car can be confirmed after the car arrives at the destination floor. Therefore, the elevator controller 5 is restarted in the elevator 15 where no user is present, which does not inconvenience the user.
  • the elevator controller 5 acquires destination floor information, which is one of the operating states (S101). Next, the elevator controller 5 determines destination floor information (S102). If multiple destination floors are registered, the elevator 15 cannot be restarted because it is necessary to continue the operation. On the other hand, if one floor is registered as the destination floor or if 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 shifts to a mode in which new calls are not accepted, and performs processing such that, for example, a maintenance mode is set as an operation mode that can be restarted when the car 7 arrives at the destination floor.
  • a maintenance mode is set as an operation mode that can be restarted when the car 7 arrives at the destination floor.
  • the elevator controller 5 confirms whether or not the car 7 has arrived at the destination floor (S104), and determines whether or not 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 to continue confirming the arrival of the car 7.
  • the elevator controller 5 acquires the car status (S106). Next, the elevator controller 5 determines whether or not the acquired car state is a safe state for at least passengers (S107).
  • the safest condition is when there are no passengers in car 7 and the door is closed. If it is determined that the state is not safe (NO in S107), the elevator controller 5 terminates this process. After a certain period of time, the elevator controller 5 resumes processing from step S101. On the other hand, when it is determined that the state is safe (YES in S107), the elevator controller 5 restarts itself (S108) and terminates this process.
  • the elevator controller 5 restarts to apply the new firmware image 31 without securing a special mode or work time as in the maintenance mode. It becomes possible to
  • FIG. 20 is a flow chart showing an example of the process of rebooting the floor controller 11 to apply the firmware image 31 .
  • the floor controller 11 acquires the registration status of up and down calls (S111). Next, the floor controller 11 determines whether or not an up-down call is registered (S112). If there is an up/down call registered (YES in S112), the elevator 15 continues to operate and cannot be restarted. Therefore, this processing ends here, and the floor controller 11 restarts the processing from step S111 after a certain period of time.
  • the floor controller 11 can be rebooted to apply the new firmware image 31 without securing a special mode or work time as in the maintenance mode. It becomes possible to
  • each of the above-described embodiments is a detailed and specific description of the configuration of the device and system in order to explain the present invention in an easy-to-understand manner, and is not necessarily limited to those having all the configurations described.
  • the control lines and information lines indicate those considered necessary for explanation, and not all control lines and information lines are necessarily indicated on the product. In practice, it may be considered that almost all configurations are interconnected.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Indicating And Signalling Devices For Elevators (AREA)
  • Maintenance And Inspection Apparatuses For Elevators (AREA)
  • Stored Programmes (AREA)

Abstract

エレベーターシステムが備えるマスタコントローラは、エレベーターの運行状態に応じて、複数のサブコントローラに対するファームイメージの送信順番を生成し、送信順番が優先されるサブコントローラに対して、ファームイメージ及び送信順番を含むパケットを送信する。送信順番が優先されるサブコントローラは、マスタコントローラからパケットを受信してファームイメージの更新を行い、送信順番が次に優先されるサブコントローラにパケットを送信する。

Description

エレベーターシステム及びファームウェア送信方法
　本発明は、エレベーターシステム及びファームウェア送信方法に関する。
　従来、エレベーターシステムは、複数の制御コントローラから構成されている。そして、任意の１台の制御コントローラが、複数の制御コントローラのプログラムを更新する、１対Ｎの構成でプログラムが更新されるシステムが知られている。
　特許文献１には、「サーバは、複数のエレベーターの中の予め定められた１台の代表エレベーターに対して、代表エレベーター上にある更新前の版の制御プログラムと、更新すべき最新版の制御プログラムとの差分情報を含む更新データを通信回線を介して配信し、代表エレベーターは、サーバから受信した更新データに基づいて自己の制御プログラムを更新するとともに、予め定められた転送順番に従って次に転送すべきエレベーターに対して、更新データをネットワークを介して送信する」と記載されている。
　特許文献２には、「伝送手順制御手段は、伝送路を介して複数の制御装置へ更新用の運転制御プログラムを伝送する伝送時間と、複数の制御装置が更新用の運転制御プログラムに書き換える書換時間とからエレベーターの停止時間を算出し、算出した停止時間に基づいて複数の制御装置へ更新用の運転制御プログラムを伝送する順番を選択する」と記載されている。
特許第４９６３２９２号 特許第５０７２４１１号
　特許文献１に記載されているように、予め１台の代表エレベーターを定め、且つ予め更新データの転送順番を定めている場合、代表エレベーター以外のエレベーターから更新データを更新することはできない。代表エレベーターに不具合が発生すると、代表エレベーターの処理の負荷が高い場合等、データの更新処理を実施できない場合があった。さらに、予め定められた順番でしか更新処理を実行できないため、順番が決められた全てのエレベーターが更新処理を実行できる状態でしかエレベーターが更新処理を完遂することができなかった。例えば、１基のエレベーターのみが不具合発生や保守作業中であっても、制御処理が高負荷であると、更新処理を受け付けないため、通信処理に遅延又は通信遮断が起きる等の課題があった。
　また、特許文献２には、伝送時間と書換時間とに基づいてエレベーターの停止時間を算出することが記載されている。しかし、プログラム容量、通信デバイス性能、及び、記憶デバイス書換性能は、予め定められた条件に該当しなければならない。特許文献１に記載された技術と同じく、実際の運用状態に適していない場合もあった。
　本発明はこのような状況に鑑みて成されたものであり、エレベーターの運行状態に応じてファームウェアを更新するコントローラの順番を変更することを目的とする。
　本発明に係るエレベーターシステムは、ファームウェアを送信するマスタコントローラと、ファームウェアを受信してファームウェアを更新するサブコントローラとを備える。
マスタコントローラは、エレベーターの運行状態に応じて、複数のサブコントローラに対するファームウェアの送信順番を生成し、送信順番が優先されるサブコントローラに対して、ファームウェア及び送信順番を含む第１送信データを送信する。送信順番が優先されるサブコントローラは、マスタコントローラから第１送信データを受信してファームウェアの更新を行い、送信順番が次に優先されるサブコントローラに第１送信データを送信する。
　本発明によれば、エレベーターの運行状態に応じてファームウェアの送信順番を生成するため、予めファームウェアの送信順番を決める必要がない。
　上記した以外の課題、構成及び効果は、以下の実施形態の説明により明らかにされる。
本発明の一実施形態に係るエレベーターシステムの全体構成例を示す図である。 本発明の一実施形態に係るコントローラのハードウェア構成例を示すブロック図である。 本発明の一実施形態に係るマスタコントローラとサブコントローラを含むパケット通信システムの基本構成例を示すブロック図である。 本発明の一実施形態に係るパケットの内部構成例を示す図である。 本発明の一実施形態に係るマスタコントローラと、各サブコントローラとで生成されるパケットの例を示す図である。 本発明の一実施形態に係るパケット通信システムの正常通信処理の例を示すフローチャートである。 本発明の一実施形態に係るサブコントローラの処理の例を示すフローチャートである。 本発明の一実施形態に係る異常通知メッセージのパケット構成例を示す図である。 本発明の一実施形態に係るサブコントローラが異常の発生を通知する処理の例を示すフローチャートである。 本発明の一実施形態に係るサブコントローラがパケット送信の失敗時に行われる異常対応処理の一例を示すフローチャートである。 本発明の一実施形態に係る通信エラーが発生したサブコントローラをスキップして、ファームイメージの更新処理を継続する処理の例を示すフローチャートである。 本発明の一実施形態に係るエレベーターコントローラと、複数のフロアコントローラと、で構成されたツリー構造の例を示すブロック図である。 本発明の一実施形態に係るフロアの呼び登録の有無に応じた順番の生成処理の例を示すフローチャートである。 本発明の一実施形態に係るフロアの滞在人数に応じた順番の生成処理の例を示すフローチャートである。 本発明の一実施形態に係る群管理コントローラと、複数のエレベーターコントローラと、で構成されるツリー構造の例を示すブロック図である。 本発明の一実施形態に係るエレベーターの呼びの割当数に応じた順番の生成処理の例を示すフローチャートである。 本発明の一実施形態に係る通信コントローラと、複数の群管理コントローラと、で構成されるツリー構造の例を示すブロック図である。 本発明の一実施形態に係るエレベーターへの呼びの割当数と、割当処理状態に応じた順番の生成処理の例を示すフローチャートである。 本発明の一実施形態に係る群管理コントローラがファームイメージを適用するための再起動を判断する処理の例を示すフローチャートである。 本発明の一実施形態に係るエレベーターコントローラがファームイメージを適用するための再起動を判断する処理の例を示すフローチャートである。 本発明の一実施形態に係るフロアコントローラがファームイメージを適用するために再起動する処理の例を示すフローチャートである。
　以下、本発明を実施するための形態に係るエレベーターシステム及びファームウェア送信方法の一例について、添付図面を参照して説明する。本明細書及び図面において、実質的に同一の機能又は構成を有する構成要素については、同一の符号を付することにより重複する説明を省略する。なお、本発明は以下の実施形態に限定されるものではない。
［一実施形態］
　図１は、本発明の一実施形態に係るエレベーターシステム１００の全体構成例を示す図である。
　図１では、エレベーターシステム１００の説明を簡略化するために、１基のエレベーター１５の詳細な構成要素を図示しており、他のエレベーター１５については詳細な構成要素の図示を省略する。
　エレベーターシステム１００は、複数のエレベーター１５を管理し、運行を監視し、保守するために、例えば、エレベーター１５から遠隔に設置されているセンタ１を有する。また、エレベーターシステム１００は、通信コントローラ３、群管理コントローラ４、エレベーターコントローラ５、かごコントローラ１０、フロアコントローラ１１及び保守端末１９を有する。
　センタ１は、専用回線のような有線又は無線による閉回路網やインターネットのような公衆回線である通信網２を経由して通信コントローラ３に接続されている。
　通信コントローラ３は、センタ１とエレベーターとの間のデータ転送、遠隔操作及び遠隔保守を実行するための通信を担うコントローラである。通信コントローラ３は、通信路１７を介して、群管理コントローラ４に接続されている。通信コントローラ３は、複数のエレベーターコントローラ５の動作を制御する複数の群管理コントローラ４に対する通信を制御する。
　群管理コントローラ４は、エレベーター１５の動作を制御する複数のエレベーターコントローラ５の動作を制御する。そこで、群管理コントローラ４は、複数のエレベーター１５をエレベーターグループ１８としてまとめて運行制御する。群管理コントローラ４は、複数のエレベーターコントローラ５と、通信路１６を介して接続されている。
　エレベーター１５は、エレベーターコントローラ５、かごコントローラ１０及びフロアコントローラ１１を備える。
　エレベーターコントローラ５は、エレベーター１５の動作を制御しており、かご７の上下移動及び停止の制御を実現することで利用者に上下移動のサービスを提供する。このサービスを提供するため、エレベーターコントローラ５は、主機であるモーター６を制御して、かご７と、カウンターウェイト８と、を連結しているロープ９の動きを操作する。エレベーターコントローラ５は、１台のかごコントローラ１０と、複数のフロアコントローラ１１と、通信路１２を経由して接続されている。
　かごコントローラ１０は、かご７内に設置されている行先階ボタン及びドア開閉ボタン１３の、利用者による操作状況に対応して、かごドアの開閉動作を行い、エレベーターコントローラ５にかご状況の変化を伝える。
　フロアコントローラ１１は、エレベーター１５が昇降するフロアごとに設けられ、フロアの状況をエレベーターコントローラ５に伝える。例えば、フロアコントローラ１１は、各階床に設置される上下ボタン１４の、各階における利用者による操作状況を監視して、エレベーターコントローラ５にフロアの状況変化を伝える。上下ボタン１４の代わりに、乗客がかごへの乗車前に行先階を登録可能な行先階登録装置を具備するエレベーターシステムもある。
　図１を示して説明したように、エレベーターシステム１００は、複数のコントローラが１対Ｎ構成であるツリー構造が多段に階層化されたシステムである。また、同一種別のコントローラが複数存在する場合には、当該コントローラの任意の一台をツリー構造のルートとし、残りのコントローラをツリー構造のリーフとしてツリー構造を構成することも可能である。
　センタ１は、各コントローラで用いられるファームウェアをファームイメージ３１（後述する図３を参照）として不図示の記憶部に保持している。センタ１は、通信網２、通信路１２、１６、１７と、通信路に接続されている各種のコントローラと、を経由することにより、任意のコントローラにファームウェアを送信することが可能である。
　通信網２に接続される保守端末１９は、センタ１からファームウェアをコピーすることができる。保守端末１９は、ファームウェアをコピーした後、任意のコントローラに接続されることで、保守端末１９が保持するファームウェアを、接続したコントローラに出力可能である。このため、保守端末１９は、保守端末１９に接続したコントローラにファームウェアを保持させることができる。また、ファームウェアを保持したコントローラは、自身のファームウェアをアップデートしたり、他のコントローラにファームウェアを送信したりすることができる。
　なお、各コントローラがファームウェアを更新する方法としては、ファームウェアの全体イメージを用いた全体更新の場合と、新旧のファームウェアの差分イメージを用いて部分的に差分更新する場合と、がある。
＜コントローラのハードウェア構成例＞
　次に、エレベーターシステム１００が備える各コントローラ２０のハードウェア構成について、図２を参照して説明する。ここでは、通信コントローラ３、群管理コントローラ４，エレベーターコントローラ５、かごコントローラ１０，フロアコントローラ１１が備える計算機のハードウェア構成を説明する。これらを総称してコントローラ２０と呼ぶ。
　図２は、コントローラ２０のハードウェア構成例を示すブロック図である。
　コントローラ２０は、システムバス２１に、それぞれ接続されたＭＰＵ（Micro Processing Unit）２２、ＲＯＭ（Read Only Memory）２３、ＲＡＭ（Random Access Memory）２４、及び通信インタフェース２５を備える。なお、ＭＰＵに類する演算装置の上位概念としてＣＰＵ（Central Processing Unit）がある。
　ＭＰＵ２２、ＲＯＭ２３、ＲＡＭ２４は、処理部を構成する。ＭＰＵ２２は、本実施形態の形態で、係る各機能を実現するプログラムコードのバイナリデータであるファームイメージ３１（後述する図３を参照）はＲＯＭ２３に記録されており、ＲＯＭ２３からリードしてＲＡＭ２４にロードし、プログラムコードを実行する。また、ＭＰＵ２２は、プログラムコードをＲＯＭ２３から直接リードしてそのままプログラムコードを実行する場合もある。
　ＲＡＭ２４には、ＭＰＵ２２で行われる処理の実行途中で発生した変数やパラメータ等が一時的に書き込まれ、これらの変数及びパラメータ等がＭＰＵ２２から適宜読み出される。
　コントローラ２０は、通信インタフェース２５を通じて、複数のコントローラ２０間でデータを送受信することが可能である。各コントローラ２０間を接続する通信路として、例えば、ＲＳ－４８５のようなマルチドロップ形態のシリアル通信デバイスや、イーサネット（登録商標）のような複数のトポロジを提供する有線の通信路であるＬＡＮ（Local Area Network）、ＷＡＮ（Wide Area Network）、さらには無線の通信路であるＲＡＮ（Radio Area Network）がある。各コントローラ２０は、例えば、Ｗｉ－Ｆｉ（登録商標）のような無線や、インフラ無線通信によって、各コントローラのデータを装置間で送受信することが可能となる。
　なお、ＲＯＭ２３へのデータの書換時に生じる不具合に対処するために、コントローラ２０が複数のＲＯＭ２３を搭載する場合がある。この構成であれば、一方のＲＯＭ２３に現在のファームイメージ３１（ファームウェアの一例）が記録され、他方のＲＯＭ２３に新規のファームイメージ３１が記録される。後者のＲＯＭ２３に対する新規のファームイメージ３１の書換時に不具合が発生しても、前者のＲＯＭ２３には、現在のファームイメージ３１が残っているので、現状復帰が可能である。また、コントローラ２０は、ＲＯＭ２３が複数ある場合には、所望のファームイメージ３１が記憶されているＲＯＭ２３を選択して起動する。
＜マスタコントローラとサブコントローラの基本システム構成＞
　次に、図１に示したエレベーターシステム１００の実施形態に基づいて、本発明の実施形態に係るマスタコントローラとサブコントローラの基本システム構成について説明する。
　図３は、マスタコントローラ３０とサブコントローラ４０を含むパケット通信システム２００の基本構成例を示すブロック図である。
　パケット通信システム２００は、ファームイメージ３１を送信するマスタコントローラ３０と、ファームイメージ３１を受信してファームイメージ３１を更新するサブコントローラ４０とを備えるエレベーターシステム１００の一形態である。図１に示したように、エレベーターシステム１００は、複数のコントローラが１対Ｎで接続されるツリー構造が、多重に組み合わさっている大規模なシステムである。ここでは、１台のコントローラ２０をマスタコントローラ３０、Ｎ台のコントローラ２０をサブコントローラ４０としたパケット通信システム２００について説明する。また、パケット通信システム２００では、同階層、又は異なる階層のコントローラ２０をマスタとサブの関係としている。マスタとサブの関係は、隣接する階層だけでなく、一又は複数の階層をまたいでもよい。例えば、一つの群管理コントローラ４をマスタコントローラ３０とし、エレベーターコントローラ５をまたいで、複数のフロアコントローラ１１をサブコントローラ４０とすることも可能である。
　マスタコントローラ３０は、エレベーター１５の運行状態に応じて、複数のサブコントローラ４０に対するファームイメージ３１の送信順番を生成する。そして、マスタコントローラ３０は、送信順番が優先されるサブコントローラ４０に対して、ファームイメージ３１及び送信順番を含むパケット５０を送信する。マスタコントローラ３０は、通信路３７を介して、サブコントローラ４０に接続されている。マスタコントローラ３０からパケット５０が直接送信されるサブコントローラ４０は、送信順番が最先であることが多い。
　ただし、パケット５０を受信するサブコントローラ４０に異常が生じた場合、マスタコントローラ３０は、異常が生じたサブコントローラ４０の次の送信順番であるサブコントローラ４０を優先してパケット５０を送信することがある。このようにマスタコントローラ３０は、送信順番が優先されるサブコントローラ４０にパケット５０を送信するので、送信順番が優先されるサブコントローラ４０がパケット５０を受信できる。また、パケット５０を受信したサブコントローラ４０は、送信順番が次に優先されるサブコントローラ４０にパケット５０を送信するので、パケット５０が複数のサブコントローラ４０を転送されることとなる。このため、マスタコントローラ３０が複数のサブコントローラ４０にパケット５０を一斉配信する場合に比べて、各サブコントローラ４０にパケット５０を確実に送信することが可能となる。
　このマスタコントローラ３０は、ファームイメージ３１、イメージ分割部３２、運行状態取得部３３、順番生成部３４、パケット生成部３５及びマスタ通信部３６を備える。
　ファームイメージ３１は、ファームウェアの実体である。ファームウェアは、コントローラ２０の動作を制御するプログラムの一例である。ファームイメージ３１は、マスタコントローラ３０に設けられたＲＯＭ２３等に保存される。
　イメージ分割部３２は、ファームイメージ３１を分割するファームウェア分割部の一例として用いられる。イメージ分割部３２がファームイメージ３１を分割するため、１回当たりの通信でサブコントローラ４０に送信されるパケット５０のバイナリデータ５７（後述する図４Ａを参照）のデータ量が減少する。マスタコントローラ３０とサブコントローラ４０との間の通信路３７の通信効率を向上させることができる。
　運行状態取得部３３は、エレベーターの運行状態を取得する。エレベーター１５の運行状態は、例えば、かご状態、呼びの割当状態等を含む。運行状態取得部３３は、かごコントローラ１０、フロアコントローラ１１等から運行状態を取得できる。
　順番生成部３４は、イメージ分割部３２により分割されたファームイメージ３１の送信先であるサブコントローラ４０の送信順番を、運行状態取得部３３が取得したエレベーター１５の運行状態に応じて生成する。なお、ファームイメージ３１のファイルサイズが十分に小さい場合、分割されないファームイメージ３１がサブコントローラ４０に送信されることがある。
　パケット生成部３５（第１送信データ生成部の一例）は、順番生成部３４が生成した送信順番にしたがってマスタコントローラ３０がサブコントローラ４０にファームイメージ３１を送信するためのパケット５０を生成する。パケット５０は、第１送信データの一例として用いられる。後述する図４Ａに示すように、パケット生成部３５は、パケット５０の送信元であるマスタコントローラ３０を識別する情報（送信元５１）と、パケット５０の送信先であるサブコントローラ４０を識別する情報（送信先５２）と、送信順番（送信順番５３）と、分割されたファームイメージ３１の構築順番（番号５６）と、分割されたファームイメージ３１（バイナリデータ５７）とを含むパケット５０を生成する。
　マスタ通信部３６は、順番生成部３４により生成された送信順番が最先であるサブコントローラ４０に対して、パケット生成部３５により生成されたパケット５０を送信する。
　送信順番が優先されるサブコントローラ４０は、マスタコントローラ３０からパケット５０を受信してファームイメージ３１の更新を行い、送信順番が次に優先されるサブコントローラ４０にパケット５０を送信する。このサブコントローラ４０は、サブ通信部４１、パケット解釈部４２、送信先抽出部４３、パケット生成部４４、イメージ構築部４５及びファームイメージ記憶部４６を備える。
　サブ通信部４１は、通信路３７に接続されている。このサブ通信部４１は、通信路３７を介してマスタコントローラ３０、又はパケット５０の送信元である他のサブコントローラ４０からパケット５０を受信する第２通信部の一例として用いられる。
　パケット解釈部４２は、サブ通信部４１が受信したパケット５０を解釈するデータ解釈部の一例として用いられる。パケット５０の解釈は、規定のパケットフォーマットに従って、パケット５０からデータを取り出し、所定の出力先にデータを出力する処理である。
　パケット解釈部４２が解釈したファームイメージ３１の分割されたイメージデータは、イメージ構築部４５に出力される。また、パケット解釈部４２によるパケット５０の解釈結果は送信先抽出部４３に出力される。
　送信先抽出部４３は、パケット解釈部４２が解釈した送信順番に基づいて、パケット５０の次の送信先であるサブコントローラ４０を抽出する。
　パケット生成部４４は、パケット５０の次の送信先であるサブコントローラ４０にファームイメージ３１を送信するためのパケット５０（第２送信データの一例）を生成する第２送信データ生成部の一例として用いられる。例えば、パケット生成部４４は、パケット解釈部４２によるパケット５０の解釈結果と、送信先抽出部４３により抽出されたパケットの送信先である残りのサブコントローラ４０の送信順番とに基づいて、新たなパケット５０を生成する。パケット生成部４４が生成するパケット５０に含まれるファームイメージ３１の分割されたイメージデータは、基本的には、サブ通信部４１が受信したパケット５０に含まれる、ファームイメージ３１の分割されたイメージデータと同じである。パケット生成部４４によりパケット５０が生成されると、サブ通信部４１が、パケット５０に格納された送信順番に基づいて、次の送信先であるサブコントローラ４０にパケット５０を送信する。
　イメージ構築部４５は、パケット解釈部４２が解釈した、分割されたファームイメージ３１を構築順番に従って元のファームイメージ３１に構築するファームウェア構築部の一例として用いられる。イメージ構築部４５は、パケット解釈部４２から受け取った、分割されたファームイメージ３１を溜めるバッファ（不図示）を有する。そして、分割されたファームイメージ３１がバッファに十分溜まると、ファームイメージ３１を再構築する。
　ファームイメージ記憶部４６は、イメージ構築部４５により構築されたファームイメージ３１を記憶する。サブコントローラ４０が更新するファームイメージ３１は、ファームイメージ記憶部４６から読み出されたものである。ファームイメージ記憶部４６には、複数のファームイメージ３１がバージョンごとに世代管理されてもよい。このため、仮に更新が失敗した場合には、以前のファームイメージ３１に戻すことができる。
　サブコントローラ４０の各部の処理が繰り返し行われることで、エレベーター１５の運行状況に応じた効率のよいサブコントローラ４０の送信順番に基づいてファームイメージ３１の送信が実現される。
　運行状態が、例えば深夜時間帯のようにエレベーターシステム１００全体が待機状態である場合には、コントローラ２０の順番が更新処理に与える影響は少ない。このため、パケット生成部４４は、パケット５０がサブコントローラ４０に送信される順番を、階床数に応じた昇順／降順の順番、コントローラ２０に割り当てられているシリアル番号の順番、又は乱数を用いて決定してもよい。
　マスタコントローラ３０とサブコントローラ４０の関係は、保守端末１９を使用するユーザが決定してもよい。また、保守端末１９からファームイメージ３１をダウンロードしたコントローラをマスタコントローラ３０とし、他のコントローラをサブコントローラ４０として自動的に決定してもよい。
＜パケットの基本構成＞
　次に、図３に示したパケット通信システム２００において生成されるパケット５０の基本構成について図４Ａと図４Ｂを用いて説明する。
　図４Ａと図４Ｂは、パケット５０の基本構成例を示す図である。
　図４Ａは、パケット５０の内部構成例を示す図である。
　パケット５０は、パケット５０の送信元５１のデータと、パケット５０の送信先５２のデータと、パケット５０の送信順番５３のデータと、ファームイメージ３１を分割したイメージデータ５４と、パケット５０のデータ不整合を確認するためのチェックデータ５５と、から構成される。
　イメージデータ５４は、図３に示したイメージ分割部３２によってファームイメージ３１が分割された複数のイメージデータの一つである。このため、イメージデータ５４は、ファームイメージ３１が分割された構築順番を示す番号５６と、分割されたイメージの実体であるバイナリデータ５７と、から構成される。このようにパケット５０の構造を定義することにより、マスタコントローラ３０及びサブコントローラ４０は、順番生成部３４で生成された複数のサブコントローラ４０の順番通りにファームイメージ３１を送信できる。このため、各サブコントローラ４０は、ファームイメージ３１を受信した順番でファームイメージ３１を更新することができる。
　なお、イメージデータ５４又はバイナリデータ５７には、通信コントローラ３、群管理コントローラ４、エレベーターコントローラ５、フロアコントローラ１１のうち、どのコントローラに対応したファームウェアなのかを示す識別データが含まれている。よって、マスタコントローラ３０である場合に各コントローラに搭載されるイメージ構築部４５は、識別データによって、別のコントローラ向けのファームウェアを識別することが可能である。
　図４Ｂは、マスタコントローラ３０と、各サブコントローラ４０とによって生成されるパケット５０の構成例を示す図である。ここでは、４階床の建屋に設けられたエレベーター１５を想定する。マスタコントローラ３０がエレベーターコントローラ５に対応し、サブコントローラ４０がフロアコントローラ１１に対応する。そして、送信順番５３が、４階―２階―３階―１階の順番として生成された場合を示している。ここで、番号５６に格納される「１」は、分割されたファームイメージ３１のうち、１番目のバイナリデータであることを表している。
　マスタコントローラ３０は、送信元５１に自身のＩＤ番号「０」を設定し、送信先５２に送信順番５３の最初のＩＤ番号「４」を設定し、送信順番５３にＩＤ番号「４」より後の順番「２－３－１」を設定したパケット５０（１）を生成する。このため、送信順番５３が最先である４階のフロアコントローラ１１にパケット５０（１）が送信される。
　４階のフロアコントローラ１１は、パケット５０（１）を受信すると、送信元５１に自身のＩＤ番号「４」を設定し、送信先５２に送信順番５３の最初のＩＤ番号「２」を設定し、送信順番５３にＩＤ番号「２」より後の順番「３－１」を設定したパケット５０（２）を生成する。このため、送信順番５３が最先である２階のフロアコントローラ１１にパケット５０（２）が送信される。
　２階のフロアコントローラ１１は、パケット５０（２）を受信すると、送信元５１に自身のＩＤ番号「２」を設定し、送信先５２に送信順番５３の最初のＩＤ番号「３」を設定し、送信順番５３にＩＤ番号「３」より後の順番「１」を設定したパケット５０（３）を生成する。このため、送信順番５３が最先である３階のフロアコントローラ１１にパケット５０（３）が送信される。
　３階のフロアコントローラ１１は、パケット５０（３）を受信すると、送信元５１に自身のＩＤ番号「３」を設定し、送信先５２に送信順番５３の最初のＩＤ番号「１」を設定し、自身が送信順番の最後となるので送信順番５３を無設定にしたパケット５０（４）を生成する。このため、送信順番５３が最先である１階のフロアコントローラ１１にパケット５０（４）が送信される。
　パケット５０をこのような構造にすることで、マスタコントローラ３０から送信されたパケット５０が、エレベーター１５の運行状態に応じた送信順番５３に基づいて、複数のサブコントローラ４０を順番に経由して送信される。このため、マスタコントローラ３０の処理の負荷を軽減できるとともに、サブコントローラ４０もエレベーター１５の運行状態に基づいて効率よく処理を実行することが可能となる。また、本実施の形態に係る通信方法は、マスタコントローラ３０から複数のサブコントローラ４０にパケットを一斉配信するブロードキャストに比べてネットワークを占有しなくて済む。また、マスタコントローラ３０は、ファームイメージ３１の送信順番の割当てを管理しやすくなる。
　なお、多くのコントローラ２０が待機状態の場合、例えば利用が少ない深夜等の場合には、運転状態によるコントローラ２０の状態に差異が少ない。このため、送信順番５３を、単純に、コントローラ２０のＩＤ順に、またはフロア番号順にしても構わない。
　また、任意のサブコントローラ４０から、マスタコントローラ３０に直接通信することを想定した場合には、送信元５１と、送信先５２に加えて、マスタコントローラ３０に相当するパケットの送信源の項目をパケットに追加してもよい。サブコントローラ４０からマスタコントローラ３０への通信は、例えば、サブコントローラ４０が管理する範囲のエレベーター１５の運行状況をマスタコントローラ３０に通知するために行われる。また、サブコントローラ４０からマスタコントローラ３０への通信は、エレベーター１５の通常運転における状態通知に使われる。また、サブコントローラ４０が、複数のサブコントローラ４０を逆に辿らずに、マスタコントローラ３０に対して直接不具合情報を送るためにも使われる。
＜正常時の通信処理＞
　次に、図３に示したパケット通信システム２００における処理（ファームウェア送信方法の一例）について、図５以降のフローチャートを参照して説明する。
　図５は、パケット通信システム２００の正常通信処理の例を示すフローチャートである。図５は、マスタコントローラ３０が、ファームイメージ３１を分割し、エレベーター１５の運行状態に基づいて生成した順番でパケット５０を送信することで、全てのサブコントローラ４０にファームイメージ３１を配布する処理を表している。
　始めに、マスタコントローラ３０のイメージ分割部３２（図３参照）は、ファームイメージ３１を通信に適したサイズに分割する（Ｓ１）。イメージ分割部３２は、ファームイメージ３１を分割する時に、分割順が分かるように、例えば昇順とした番号５６（図４Ａ参照）も生成する。なお、最後の分割したファームイメージ３１の番号は特別な終端番号とする場合がある。この終端番号を、パケット５０の受信側のコントローラ２０が共有していれば、分割されたファームイメージ３１の個数が多くても、コントローラ２０が最後まで受信することができる。
　次に、運行状態取得部３３は、エレベーター１５の運行状態を取得する（Ｓ２）。次に、順番生成部３４は、運行状態に基づいて、分割されたファームイメージ３１を通信する、サブコントローラ４０の順番を生成する（Ｓ３）。次に、パケット生成部３５は、順番生成部３４により生成された順番に従って、次のサブコントローラ４０へ送信するパケット５０を生成する（Ｓ４）。そして、マスタ通信部３６は、生成されたパケット５０を、順番に従って、次のサブコントローラ４０に送信する（Ｓ５）。
　マスタ通信部３６は、パケット５０の送信が成功したか否かを確認する（Ｓ６）。パケット５０の送信が失敗した場合（Ｓ６のＮＯ）、マスタ通信部３６は、サブコントローラ４０からの異常通知を受信した後（Ｓ７）、本処理を終了する。なお、一定時間後、マスタコントローラ３０は、パケット５０を再送信するために、本処理を再実行する。
　一方、パケット５０の送信が成功した場合（Ｓ６のＹＥＳ）、マスタ通信部３６は、ファームイメージ３１を分割した残りが存在するか否かを確認する（Ｓ８）。ファームイメージ３１を分割した残りが有る場合には（Ｓ８のＹＥＳ）、マスタコントローラ３０は、ステップＳ１に戻って、処理を繰り返す。残りが無い場合には（Ｓ８のＮＯ）、マスタコントローラ３０は、本処理を終了する。
　次に、サブコントローラ４０の処理について、図６を参照して説明する。
　図６は、サブコントローラ４０の処理の例を示すフローチャートである。
　始めに、サブコントローラ４０のサブ通信部４１は、マスタコントローラ３０又は一つ前の順番のサブコントローラ４０からパケット５０を受信する（Ｓ１１）。
　次に、パケット解釈部４２は、サブ通信部４１が受信したパケット５０を解釈し（Ｓ１２）、送信元５１、送信先５２、送信順番５３、分割されたイメージデータ５４、チェックデータ５５のそれぞれを識別する。ステップＳ１２のパケット５０を解釈する処理は、後述する図８に詳細な例が示される。
　次に、送信先抽出部４３は、パケット解釈部４２が識別した送信順番５３から次の送信先を抽出する（Ｓ１３）。また、イメージ構築部４５は、分割されたイメージデータ５４からファームイメージ３１を順次構築する（Ｓ１４）。ステップＳ１３，Ｓ１４の処理は、並列処理としているが、逐次処理としてもよい。
　次に、送信先抽出部４３は、分割されたイメージデータ５４を送る次の送信先が存在するか否かを送信順番５３で確認する（Ｓ１５）。
　次の送信先が存在する場合（Ｓ１５のＹＥＳ）、パケット生成部４４は、新たに送信先５２を次のサブコントローラ４０に変更したパケット５０を生成する（Ｓ１６）。サブ通信部４１は、生成したパケット５０を次のサブコントローラ４０に送信し（Ｓ１７）、パケット５０の送信が成功したか否かを確認する（Ｓ１８）。
　パケット５０の送信が失敗した場合（Ｓ１８のＮＯ）、サブコントローラ４０は、後述する図７又は図１０に示す異常対応処理を行う（Ｓ１９）。ステップＳ１９は、後述する図９と図１０に示すように異なる行先がある。
　一方、パケット５０の送信が成功した場合（Ｓ１８のＹＥＳ）、又は、ステップＳ１５にて分割されたイメージデータ５４を送る次のサブコントローラ４０が存在しないと判定した場合（Ｓ１５のＮＯ）、パケット解釈部４２は、イメージデータ５４がファームイメージ３１の終端であるか否かを確認する（Ｓ２０）。
　ファームイメージ３１の終端であれば（Ｓ２０のＹＥＳ）、パケット解釈部４２がイメージ構築部４５によるファームイメージ３１の構築が終了したかを確認した後、サブコントローラ４０は、本処理を終了する。一方、ファームイメージ３１の終端でなければ（Ｓ２０のＮＯ）、ステップＳ１１に戻って、サブコントローラ４０が処理を繰り返す。
　なお、サブ通信部４１は、分割されたイメージデータ５４を含むパケット５０を受信する度に、パケット解釈部４２が解釈した送信元５１を記憶しておいてもよい。この場合、サブ通信部４１は、パケット５０の順番を逆に辿って通信することで、マスタコントローラ３０と、通信することも可能となる。例えば、サブ通信部４１は、サブコントローラ４０の不具合発生をマスタコントローラ３０に通知することも可能となる。
　図５と図６に示した処理フローにより、マスタコントローラ３０は、エレベーター１５の運行状態に応じた順番の最初のサブコントローラ４０にパケット５０を送信するだけで、ファームイメージ３１を複数のサブコントローラ４０全てに対して自ら配信することなく、ファームイメージ３１の更新が可能となる。複数のサブコントローラ４０は、マスタコントローラ３０が生成した順番に従って、他のサブコントローラ４０にファームイメージ３１を通信する。このようにマスタコントローラ３０は、効率の良い通信処理を組み合わせることで、全てのサブコントローラ４０のファームイメージ３１を更新することが可能となる。
　なお、ファームイメージ３１のサイズが小さい、又は差分アップデートで差分イメージのデータサイズが小さい場合には、イメージ分割せずにパケット５０を通信することがある。この場合、１回の通信でマスタコントローラ３０とサブコントローラ４０の処理が終了する場合もある。
＜通信異常の通知処理＞
　次に、通信異常が発生した時にサブコントローラ４０がマスタコントローラ３０に異常の発生を通知する処理について、図７～図１０を用いて説明する。
　始めに、本処理で用いられる異常通知メッセージの構成例を説明する。
　図７は、異常通知メッセージのパケット構成例を示す図である。
　パケット５０を受信した時に通信異常を検知したサブコントローラ４０は、パケット５０の送信元である前段のサブコントローラ４０に対して異常通知メッセージを送信する。
この異常通知メッセージは、図７に示すように、送信元５１のデータと、送信先５２のデータと、イメージデータ５４のデータと、チェックデータ５５とで構成される。なお、送信順番５３にはデータが記憶されない。
　そして、イメージデータ５４は、コマンド５８と、このコマンド５８に対応するコマンドデータ５９とで構成される。本実施形態においては、コマンド５８に「異常発生通知コマンド」が格納され、コマンドデータ５９には通信異常が発生したコントローラ２０のＩＤが格納される。
　図８は、サブコントローラ４０が異常の発生を通知する処理の例を示すフローチャートである。ここでは、図６のステップＳ１２に示したパケット解釈処理の詳細な例を説明する。
　始めに、任意のコントローラ２０のパケット解釈部４２は、パケット５０を解釈して、送信順番５３のデータを確認する（Ｓ２１）。次に、パケット解釈部４２は、送信順番５３のデータに送信先のサブコントローラ４０のＩＤが、パケット５０の送信順番で格納されているか否かを確認する（Ｓ２２）。送信順番５３のデータにサブコントローラ４０のＩＤが送信順番で格納されている場合（Ｓ２２のＹＥＳ）、本処理を抜けて、図６のステップＳ１３に移る。
　一方、送信順番５３のデータにサブコントローラ４０のＩＤが送信順番で格納されていない場合には（Ｓ２２のＮＯ）、イメージ構築部４５によるファームイメージ３１の更新途中に異常が発生している。この場合、サブ通信部４１は、異常に関する情報を含むデータを、送信順番とは逆順でマスタコントローラ３０に送信する。このため、マスタコントローラ３０は、サブコントローラ４０で発生した異常を直ちに把握し、パケット５０の送信停止等の指示等を対処できる。
　例えば、パケット解釈部４２は、イメージデータ５４から、図７に示したコマンド５８と、コマンド５８に対応したコマンドデータ５９を解釈する（Ｓ２３）。そして、パケット解釈部４２は、送信元５１を、本処理を実行するサブコントローラ４０自身とし、送信先５２を、パケット５０を送信した前のサブコントローラ４０とに置き換えた異常通知メッセージを生成する（Ｓ２４）。
　サブコントローラ４０のサブ通信部４１は、異常通知メッセージを、送信順番が前のサブコントローラ４０に送信する（Ｓ２５）。その後、イメージ構築部４５は、今までに構築してきたファームイメージ３１を消去して（Ｓ２６）、処理を終了する。このため、図６のステップＳ１３，Ｓ１４以降の処理は行われない。
　図８に示す異常通知の処理フローにより、サブコントローラ４０は、通信異常が発生した時には処理途中のファームイメージ３１を消去できる。また、サブコントローラ４０は、異常通知メッセージをマスタコントローラ３０に通知することができる。
＜異常時の通信処理＞
　次に、通信エラーが発生した異常時において、パケット５０を受信したサブコントローラ４０が構築途中のイメージを消去する場合と、通信エラーが発生したサブコントローラ４０をスキップする場合の各処理について、図９と図１０を用いて説明する。
＜第１の異常通知処理＞
　図９は、サブコントローラ４０がパケット５０送信の失敗時に行われる異常対応処理の一例を示すフローチャートである。この異常対応処理では、サブコントローラ４０が、パケット５０の送信失敗時に、これまで送信先のサブコントローラ４０に送信してきたイメージデータ５４を消去する処理が行われる。なお、ステップＳ１７より前の処理は、図６に示した通りであるため、詳細な説明を省略する。
　図６に示したように、任意のコントローラ２０のサブ通信部４１は、生成したパケット５０を次のコントローラ２０に送信する（Ｓ１７）。任意のコントローラ２０として、例えば、通信コントローラ３、群管理コントローラ４、エレベーターコントローラ５、かごコントローラ１０、フロアコントローラ１１がある。次に、サブ通信部４１は、パケット５０の送信が成功したか否かを確認する（Ｓ１８）。
　パケット５０の送信が成功した場合（Ｓ１８のＹＥＳ）、コントローラ２０は、図６のステップＳ２０以降の処理に移る。一方、パケット５０の送信が失敗した場合（Ｓ１８のＮＯ）、イメージ構築部４５によるファームイメージ３１の更新途中に異常が発生する。
この場合、サブ通信部４１は、異常に関する情報を含むデータを、送信順番とは逆順でマスタコントローラ３０に送信する。このため、マスタコントローラ３０は、サブコントローラ４０で発生した異常を直ちに把握し、パケット５０の送信停止等の指示等を対処できる。また、サブコントローラ４０は、ファームイメージ３１の更新途中に異常が発生した場合に、イメージ構築部４５が構築していたファームイメージ３１を消去する。このため、サブコントローラ４０では、不正確なファームイメージ３１による更新処理が行われない。
　例えば、コントローラ２０のパケット生成部４４は、前の順番のコントローラ２０に通信異常を通知するための異常通知メッセージのパケット５０を生成する（Ｓ３１）。次に、サブ通信部４１は、前の順番のコントローラ２０に異常通知メッセージのパケット５０を送信する（Ｓ３２）。そして、イメージ構築部４５は、これまでに構築してきたファームイメージ３１を消去し（Ｓ３３）、本処理を終了する。
＜第２の異常通知処理＞
　図１０は、通信エラーが発生したサブコントローラ４０をスキップして、ファームイメージ３１の更新処理を継続する処理の例を示すフローチャートである。この異常対応処理では、通信エラーが発生していないサブコントローラ４０に対して優先してパケット５０の送信が行われる。例えば、コントローラ２０がサブコントローラ４０であることを想定する。この場合、サブコントローラ４０は、パケット５０の次の送信先であるサブコントローラ４０からファームイメージ３１の更新途中に発生した異常に関する情報を含むデータを受信した場合に、異常に関する情報を含むデータを送信したサブコントローラ４０をスキップして、後続のサブコントローラ４０にパケット５０を送信する。この結果、異常が発生したサブコントローラ４０の更新処理を後回しにして、他のサブコントローラ４０の更新処理が先に行われる。このため、サブコントローラ４０の更新処理の完了率を早期に高めることができる。なお、ステップＳ１６より前の処理は、図６に示した通りであるため、詳細な説明を省略する。
　図６に示したように、任意のコントローラ２０のパケット生成部４４がパケット５０を生成し（Ｓ１６）、サブ通信部４１がパケット５０を送信する（Ｓ１７）。次に、サブ通信部４１は、パケット５０の送信が成功したか否かを確認する（Ｓ１８）。
　パケット５０の送信が成功した場合（Ｓ１８のＹＥＳ）、コントローラ２０は、図６のステップＳ２０以降の処理に移る。一方、パケット５０の送信が失敗した場合（Ｓ１８のＮＯ）、コントローラ２０は、ステップＳ１９の異常対応処理を行う。
　そこで、コントローラ２０のパケット生成部４４は、通信異常が発生したコントローラ２０の次の順番のコントローラ２０に通信異常を通知するための異常通知メッセージのパケット５０を生成する（Ｓ４１）。本処理では、コマンド５８が「スキップ発生通知コマンド」、コマンドデータ５９が「通信異常が発生したコントローラ２０のＩＤ」となる。
　次に、サブ通信部４１は、通信異常が発生したコントローラ２０の次の順番のコントローラ２０に異常通知メッセージのパケット５０を送信する（Ｓ４２）。そして、イメージ構築部４５は、パケット５０の送信に失敗したコントローラ２０をスキップした送信順番５３にデータを更新し（Ｓ４３）、ステップＳ１６に移る。
　その後、コントローラ２０は、更新した送信順番５３を基にステップＳ１６でパケット５０を生成する。このパケット５０は、コントローラ２０が、スキップ先のコントローラ２０に改めてファームイメージ３１を送信し直すものであり、ステップＳ１７で送信されるパケット５０の送信先は、スキップ先のコントローラ２０である。
　このような処理フローにより、通信異常の発生時においても、マスタコントローラ３０は、サブコントローラ４０に対するファームイメージ３１の更新を継続できる。また、サブコントローラ４０は、この通信異常によってスキップしたサブコントローラ４０の情報をマスタコントローラ３０に通知することができる。このため、マスタコントローラ３０は、図１０に示した処理フローによりスキップされたサブコントローラ４０に対して再度、ファームイメージ３１の更新を実行できる。
　なお、マスタコントローラ３０が再度、ファームイメージ３１の更新を実行する際には、マスタコントローラ３０からサブコントローラ４０に対して、コマンド５８を「イメージ消去コマンド」としたパケット５０を送る必要がある。イメージ消去コマンドは、サブコントローラ４０にファームイメージ３１の残骸が残っている場合、マスタコントローラ３０がサブコントローラ４０に対して、ファームイメージ３１の残骸の消去を指示するために用いられる。
［ツリー構造］
　次に、図１に示したエレベーターシステム１００からマスタコントローラ３０とサブコントローラ４０の関係となるコントローラを抽出した、様々なツリー構造について説明する。
＜エレベーターコントローラ＋フロアコントローラの構成＞
　まず、エレベーターコントローラ５と、複数のフロアコントローラ１１と、で構成されるツリー構造について、図１１を用いて説明する。
　図１１は、エレベーターコントローラ５と、複数のフロアコントローラ１１と、で構成されたツリー構造の例を示すブロック図である。
　１基のエレベーター１５は、一つのエレベーターコントローラ５と、階床数Ｍ分だけ存在するフロアコントローラ１１（１）～１１（Ｍ）とが、通信路１２で接続されたツリー構造である。
　上位の群管理コントローラ４からエレベーターコントローラ５にファームイメージ３１がダウンロードされた場合を想定する。そして、エレベーターコントローラ５又は複数のフロアコントローラ１１のうち、ファームイメージ３１が記憶されている一つがマスタコントローラ３０であり、他がサブコントローラ４０である構成とする。例えば、エレベーターコントローラ５がマスタコントローラ３０となり、フロアコントローラ１１がサブコントローラ４０となる。マスタコントローラ３０は、送信順番を含むパケット５０をサブコントローラ４０に送信し、パケット５０を受信したサブコントローラ４０は、ファームイメージ３１を更新する。このようにエレベーターコントローラ５と、複数のフロアコントローラ１１（１）～１１（Ｍ）とをマスタコントローラ３０とサブコントローラ４０の関係とすることで、一つのコントローラに限定されることなく、サブコントローラ４０のファームイメージ３１の更新処理を行うことが可能となる。
　なお、エレベーターコントローラ５を経由して、任意のフロアコントローラ１１がファームイメージ３１をダウンロードする場合がある。この場合には、一つのフロアコントローラ１１がマスタコントローラ３０となり、それ以外のフロアコントローラ１１及びエレベーターコントローラ５とがサブコントローラ４０となる。このような構成とした場合、ツリー構造の下位のコントローラ（フロアコントローラ１１）がマスタコントローラ３０、上位のコントローラ（エレベーターコントローラ５）がサブコントローラ４０となる。
このため、マスタコントローラ３０となるフロアコントローラ１１が、エレベーターコントローラ５から各フロアの呼び登録情報を取得できる。逆に、エレベーターコントローラ５が各フロアコントローラ１１から呼び登録情報を取得することもできる。このため、本実施の形態によれば、ツリー構造の上位、下位の区別による限定なく、パケット通信システム２００が動作することが可能となる。
　また、保守端末１９に接続されてファームイメージ３１をダウンロードしたコントローラ２０がマスタコントローラ３０となる場合、このコントローラ２０と同一セグメントに接続されている他のコントローラ２０がサブコントローラ４０となる。ここで、同一セグメントに接続されているその他のコントローラ２０とは、マスタコントローラ３０が通信コントローラ３の場合には、群管理コントローラ４である。また、マスタコントローラ３０が群管理コントローラ４の場合には、エレベーターコントローラ５である。また、マスタコントローラ３０がエレベーターコントローラ５の場合は、かごコントローラ１０及びフロアコントローラ１１である。
＜フロアの呼び登録の有無に応じた順番の生成処理＞
　次に、エレベーターコントローラ５が、運行状態の一つである各フロアにおける呼び登録を基にして、送信順番５３のデータを生成する処理について、図１２を用いて説明する。
　図１２は、フロアの呼び登録の有無に応じた順番の生成処理の例を示すフローチャートである。
　ここでは、マスタコントローラ３０として用いられるエレベーターコントローラ５は、フロアコントローラ１１から運行状態として取得した、各フロアの呼び登録の状況に応じて送信順番を生成し、フロアの滞在人数の状況に応じて、送信順番を並べ替える。このため、フロアコントローラ１１の呼び登録による処理の負荷に応じた送信順番が生成される。また、フロアの滞在人数の状況に応じてエレベーター１５のフロア毎の稼働状況が判明するので、フロアコントローラ１１への送信順番を並べ替えることで、負荷が低いフロアコントローラ１１から順にファームイメージ３１が更新されるようになる。
　始めに、エレベーターコントローラ５の運行状態取得部３３は、各フロアのフロアコントローラ１１から、各フロアの呼び登録情報を取得する（Ｓ５１）。次に、エレベーターコントローラ５は、全てのフロアの呼び登録情報を取得できたか否かを判断する（Ｓ５２）。
　全てのフロアの呼び登録情報を取得できた場合（Ｓ５２のＹＥＳ）、エレベーターコントローラ５の順番生成部３４は、取得された呼び登録情報に応じて、フロアコントローラ１１の送信順を並び替えて送信順番５３のデータを生成し（Ｓ５３）、本処理を終了する。送信順の並び替えは、呼び登録の有無、及び呼び登録の昇順とする。
　一方、呼び登録情報を取得できていないフロアが残っている場合（Ｓ５２のＮＯ）、エレベーターコントローラ５は、再びステップＳ５１に戻って、全てのフロアの呼び登録情報を取得するまでステップＳ５１，Ｓ５２の処理を続ける。
　ここで、呼び登録情報を取得できていないフロアでは、フロアコントローラ１１に処理が割り付けられていない。ここで、上下の呼びの一方に登録がある場合には、処理が割り当てられている。さらに、上下両方の呼びの登録がある場合には、処理の負荷が一番大きくなる。
　このため、順番生成部３４は、フロアへの呼び登録情報の割り当てに応じた送信順番５３のデータを生成することで、処理割り当ての無いフロアコントローラ１１を先の順番とし、処理割り当てが多いフロアコントローラ１１を後の順番としてファームイメージ３１を適用することができる。なお、群管理コントローラ４が各フロアの呼び登録情報を一括して管理している場合には、エレベーターコントローラ５が群管理コントローラ４から各フロアの呼び登録情報を一括して取得してもよい。
　また、順番生成部３４は、ファームイメージ３１の送信順を、エレベーター１５の運行情報に応じた順番にすることで、処理割り当ての無いフロアコントローラ１１からファームイメージ３１を更新できる。このため、エレベーターコントローラ５は、効率よく更新データを通信することが可能となる。また、エレベーターコントローラ５はフロアコントローラ１１に更新された新しいファームイメージ３１を適用するために、フロアコントローラ１１をすぐに再起動できる可能性が向上する。
＜各フロアの滞在人数に応じた順番の生成処理＞
　次に、エレベーターコントローラ５が、運行状態の一つである各フロアの滞在人数を基にして、送信順番５３のデータを生成する処理について、図１３を用いて説明する。ここで、滞在人数とは、各フロアにいると予想される人数である。かごからフロアに乗降した人数をフロアごとに算出することで滞在人数を求めることができる。
　図１３は、フロアの滞在人数に応じた順番の生成処理の例を示すフローチャートである。
　始めに、エレベーターコントローラ５の運行状態取得部３３は、他のエレベーターコントローラ５、又は各フロアのフロアコントローラ１１から、各フロアの滞在人数を取得する（Ｓ６１）。
　次に、エレベーターコントローラ５は、全フロアの滞在人数を取得したか否かを確認する（Ｓ６２）。滞在人数を取得できていないフロアが存在する場合（Ｓ６２のＮＯ）、エレベーターコントローラ５は、再びステップＳ６１に戻って、全てのフロアの滞在人数を取得するまでステップＳ６１，Ｓ６２の処理を続ける。
　一方、全フロアの滞在人数を取得できた場合（Ｓ６２のＹＥＳ）、エレベーターコントローラ５の順番生成部３４は、各フロアの滞在人数に応じて、フロアコントローラ１１へのパケット５０の送信順を並べ替えて（Ｓ６３）、送信順番５３のデータを生成する。その後、本処理を終了する。
　並べ替えの送信順は、例えば、滞在人数の昇順とする。滞在人数が多い方が、呼び発生の確率が高くなるので、処理の負荷が大きくなる可能性が高くなる。逆に滞在人数が少ないと、呼び発生の確率が低くなるので、処理に余裕がある可能性が高くなる。
　よって、この滞在人数に応じた送信順番５３のデータを生成することで、処理に余裕のあるフロアコントローラ１１を最初とし、処理の負荷が大きくなる可能性のあるフロアコントローラ１１を最後とする順番にファームイメージ３１を適用することができる。なお、各フロアの滞在人数を、群管理コントローラ４が一括して管理している場合には、エレベーターコントローラ５が群管理コントローラ４から各フロアの滞在人数を取得してもよい。また、エレベーターコントローラ５自身が各フロアの滞在人数を管理している場合には、その管理データを利用してもよい。
　このようにエレベーターコントローラ５は、エレベーター１５の運行情報（各フロアの滞在人数）に応じてフロアコントローラ１１への送信順を並べ替えることで、処理に余裕のあるフロアコントローラ１１からファームイメージ３１を更新できる。このため、エレベーターコントローラ５は、ファームイメージ３１の更新データをフロアコントローラ１１に効率よく送信することが可能となる。また、ファームイメージ３１の更新データを受信したフロアコントローラ１１は、更新された新しいファームイメージ３１を適用するために、すぐに再起動できる可能性が向上する。
＜群管理コントローラ＋エレベーターコントローラ＞
　次に、複数のエレベーター１５と、群管理コントローラ４とが通信路１６で接続されて構成されるツリー構造について、図１４を用いて説明する。
　図１４は、群管理コントローラ４と、複数のエレベーターコントローラ５と、で構成されるツリー構造の例を示すブロック図である。ここでは、図１に示したエレベーターグループ１８が、１台の群管理コントローラ４と、任意の数だけ存在するエレベーター１５（１）～１５（Ｍ）にそれぞれ対応して設けられた複数のエレベーターコントローラ５とを含んでいる。
　ここでは、群管理コントローラ４又は複数のエレベーターコントローラ５のうち、ファームイメージ３１が記憶されている一つがマスタコントローラ３０であり、他がサブコントローラ４０とする。この場合、マスタコントローラ３０が送信順番を含むパケット５０をサブコントローラ４０に送信し、パケット５０を受信したサブコントローラ４０がファームイメージ３１を更新する。
　そこで、上位の通信コントローラ３から群管理コントローラ４にファームイメージ３１がダウンロードされた場合を想定する。この場合には、群管理コントローラ４がマスタコントローラ３０となり、複数のエレベーターコントローラ５がサブコントローラ４０となる構成である。このように群管理コントローラ４と、複数のエレベーターコントローラ５とをマスタコントローラ３０とサブコントローラ４０の関係とすることで、一つのコントローラに限定されることなく、サブコントローラ４０のファームイメージ３１の更新処理を行うことが可能となる。
　なお、群管理コントローラ４を経由して、任意のエレベーターコントローラ５がファームイメージ３１をダウンロードする場合がある。この場合、一つのエレベーターコントローラ５がマスタコントローラ３０となり、それ以外のエレベーターコントローラ５及び群管理コントローラ４とがサブコントローラ４０となる構成である。本実施の形態に係る構成であれば、マスタコントローラ３０となる一つのエレベーターコントローラ５が、サブコントローラ４０となる群管理コントローラ４又は他のエレベーターコントローラ５から、各エレベーターコントローラ５に割り当てた呼びの呼び数を取得できる。
　また、保守端末１９に接続されてファームイメージ３１をダウンロードしたコントローラ２０がマスタコントローラ３０となる場合、このコントローラ２０と同一セグメントに接続されているその他のコントローラ２０がサブコントローラ４０となる。ここで、ファームイメージ３１をダウンロードしたコントローラ２０として、例えば、エレベーターコントローラ５、かごコントローラ１０、又はフロアコントローラ１１が想定される。
＜エレベーターの呼びの割当の有無及び大小に応じた順番の生成処理＞
　次に、群管理コントローラ４が、運行状態の一つであるエレベーター１５の呼びの割当数を基にして、送信順番５３のデータを生成する処理について、図１５を用いて説明する。
　図１５は、エレベーター１５の呼びの割当数に応じた順番の生成処理の例を示すフローチャートである。この処理では、マスタコントローラ３０の順番生成部３４は、運行状態として取得した、複数のエレベーター１５への呼びの割当の状況に応じて送信順番を生成する。このため、エレベーターコントローラ５の処理の負荷に応じた送信順番が生成される。
　始めに、群管理コントローラ４の運行状態取得部３３は、各エレベーター１５に割り当てられた呼びの割当数を取得する（Ｓ７１）。次に、群管理コントローラ４の順番生成部３４は、呼びの割当数に応じてエレベーターコントローラ５の送信順を並べ替えて送信順番５３のデータを生成し（Ｓ７２）、本処理を終了する。
　送信順の並べ替えは、呼びの割当数の昇順とする。呼びの割当数が多い方が、呼びの割り当てられたフロアへのかご７の移動、停止、出発の処理回数が多くなるので、エレベーターコントローラ５の処理の負荷も大きくなる可能性がある。逆に、呼びの割当数が少ない方が、エレベーターコントローラ５の処理の負荷が少ない。また、エレベーターコントローラ５が、停止つまり待機状態に遷移する可能性が高くなる。
　また、群管理コントローラ４の順番生成部３４は、エレベーターコントローラ５へのファームイメージ３１の送信順を、エレベーター１５の運行状態に応じた順番にすることで、処理に余裕がある、又は直近で待機状態になる可能性が高いエレベーターコントローラ５からファームイメージ３１を更新できる。このため、エレベーターコントローラ５は、効率よく更新データの通信が可能となる。また、群管理コントローラ４は、エレベーターコントローラ５に更新された新しいファームイメージ３１を適用するために、すぐにエレベーターコントローラ５を再起動できる可能性が向上する。
＜通信コントローラ＋群管理コントローラ＞
　次に、複数のエレベーターグループ１８と、通信コントローラ３とが通信路１７で接続されるツリー構造について、図１６を用いて説明する。
　図１６は、通信コントローラ３と、複数の群管理コントローラ４と、で構成されるツリー構造の例を示すブロック図である。ここでは、図１に示した１台の通信コントローラ３と、任意の数だけ存在するエレベーターグループ１８（１）～１８（Ｍ）にそれぞれ対応して設けられた複数の群管理コントローラ４とを示す。なお、図１１、図１４、図１６に示したコントローラ、グループの数を表すＭの値はそれぞれ異なってよい。
　この処理では、通信コントローラ３又は複数の群管理コントローラ４のうち、ファームイメージ３１が記憶されている一つがマスタコントローラ３０であり、他がサブコントローラ４０である。そして、マスタコントローラ３０が送信順番を含むパケット５０をサブコントローラ４０に送信し、パケット５０を受信したサブコントローラ４０がファームイメージ３１を更新する。このように通信コントローラ３と、複数の群管理コントローラ４とをマスタコントローラ３０とサブコントローラ４０の関係とすることで、一つのコントローラに限定されることなく、サブコントローラ４０のファームイメージ３１の更新処理を行うことが可能となる。
　そこで、上位の通信コントローラ３から群管理コントローラ４にファームイメージ３１がダウンロードされた場合を想定する。この場合には、通信コントローラ３がマスタコントローラ３０となり、複数の群管理コントローラ４がサブコントローラ４０となる構成になる。
　また、通信コントローラ３を経由して、任意の群管理コントローラ４がファームイメージ３１をダウンロードする場合がある。この場合には、一つの群管理コントローラ４がマスタコントローラ３０となり、それ以外の群管理コントローラ４及び通信コントローラ３がサブコントローラ４０となる構成になる。この構成とした場合、一つの群管理コントローラ４が通信コントローラ３及び他の群管理コントローラ４にファームイメージ３１を送信することも可能である。
　また、保守端末１９に接続されてファームイメージ３１をダウンロードしたコントローラ２０がマスタコントローラ３０となる場合、このコントローラ２０と同一セグメントに接続されているその他のコントローラ２０がサブコントローラ４０となる。ここで、ファームイメージ３１をダウンロードしたコントローラ２０として、例えば、通信コントローラ３が想定される。
＜群管理コントローラの割当数に応じた順番の生成処理＞
　次に、通信コントローラ３の順番生成部３４は、運行状態の一つである群管理コントローラ４の割当処理の結果である複数の群管理コントローラ４への呼びの割当回数の状況、つまりエレベーター１５への呼びの割当数と、割当処理状態とを元に、送信順番５３のデータを生成する処理について、図１７を用いて説明する。ここでは、このため、群管理コントローラ４への呼びの割当回数の状況による処理の負荷に応じた送信順番が生成される。
　図１７は、エレベーター１５への呼びの割当数と、割当処理状態に応じた順番の生成処理の例を示すフローチャートである。
　始めに、通信コントローラ３の運行状態取得部３３は、各群管理コントローラ４から呼びの割当数及び割当処理状態を取得する（Ｓ８１）。次に、運行状態取得部３３は、全ての群管理コントローラ４から呼びの割当数及び割当処理状態を取得したか否かを確認する（Ｓ８２）。全ての群管理コントローラ４から取得してない場合（Ｓ８２のＮＯ）、運行状態取得部３３は、ステップＳ８１に戻って、呼びの割当数及び割当処理状態の取得を繰り返す。
　一方、全ての群管理コントローラ４について取得した場合には（Ｓ８２のＹＥＳ）、通信コントローラ３の順番生成部３４は、運行状態取得部３３が取得した割当数及び割当処理状態に応じて群管理コントローラ４の送信順を並べ替えて送信順番５３のデータを生成し（Ｓ８３）、本処理を終了する。
　送信順の並べ替えは、呼びの割当処理の有無及び割当数の昇順とする。呼びの割当処理が終了した群管理コントローラ４は、処理の負荷に余裕がある。呼びの割り当て処理が終了している群管理コントローラ４であっても、呼びの割当数が多い群管理コントローラ４の方が、割当できる選択肢が少ないために、群管理コントローラ４の処理の負荷が増える可能性が低い。つまり、呼びが割当てられる選択肢が少ないので、群管理コントローラ４の処理の負荷が増加する可能性が低くなる。
　一方、呼びの割当処理中の群管理コントローラ４は、割当処理が終了した群管理コントローラ４よりも処理の負荷が大きい。呼びの割当処理中の群管理コントローラ４であっても、既に割り当てられた呼びの割当数が少ない群管理コントローラ４の方が、これから呼びが割当られる選択肢が多いために、群管理コントローラ４の処理の負荷が増える可能性が高い。
　このため、順番生成部３４は、呼びの割当処理か否かという点、及び呼びの割当数の大小に応じて送信順番５３のデータを生成することで、割当処理が終了した群管理コントローラ４を最初とし、処理中で且つ割当数が少ない処理の負荷の大きい群管理コントローラ４を最後とする順番にファームイメージ３１を適用することができる。
　このような運行情報に応じた順番にすることで、処理に余裕のある群管理コントローラ４からファームイメージ３１を効率よく更新できる。このため、通信コントローラ３は、更新された新しいファームイメージ３１を群管理コントローラ４に適用するために、すぐに群管理コントローラ４を再起動できる可能性が向上する。
＜各コントローラの再起動の処理＞
　次に、群管理コントローラ４、エレベーターコントローラ５、フロアコントローラ１１がそれぞれファームイメージ３１を適用するための再起動の処理について、図１８～図２０を用いて説明する。
＜群管理コントローラの再起動（割り当て済み）＞
　まず、群管理コントローラ４が、運行状態の一つである呼びの割当処理状態に応じて、更新されたファームイメージ３１を適用するために再起動する処理について、図１８を用いて説明する。
　図１８は、群管理コントローラ４がファームイメージ３１を適用するための再起動を判断する処理の例を示すフローチャートである。この処理では、群管理コントローラ４に対するファームイメージ３１の更新が完了した時点で呼びの割当処理が実行されていない場合に、ファームイメージ３１の更新が完了した群管理コントローラ４のイメージ構築部４５が再起動を実施する。このため、群管理コントローラ４が管理するエレベーター１５で利用者のいない時間帯に群管理コントローラ４が再起動されることとなり、利用者に不便を生じさせない。
　始めに、群管理コントローラ４は、呼びの割当処理の実行状態を取得する（Ｓ９１）。
群管理コントローラ４は、呼びの割当処理が実行中か否かを確認する（Ｓ９２）。呼びの割当処理が実行中であれば（Ｓ９２のＹＥＳ）、再起動は実行せず、本処理を終了する。
一定時間後、群管理コントローラ４は、ステップＳ９１から処理を再開する。一方、呼びの割当処理が実行中でない、すなわち呼びの割当処理が終了し、呼びが割当済みであれば（Ｓ９２のＮＯ）、群管理コントローラ４を再起動し（Ｓ９３）、本処理を終了する。
　このような処理により、群管理コントローラ４は、ファームイメージ３１を更新した際に、保守モードのように特別なモードや作業時間を確保することなく、新たなファームイメージ３１を適用するための再起動をすることが可能となる。
＜エレベーターコントローラの再起動（次回到着前に停止モードを予約）＞
　次に、エレベーターコントローラ５が、運行状態の一つである行先階情報に応じて、更新されたファームイメージ３１を適用するために再起動する処理について、図１９を用いて説明する。
　図１９は、エレベーターコントローラ５がファームイメージ３１を適用するための再起動を判断する処理の例を示すフローチャートである。この処理では、エレベーターコントローラ５のイメージ構築部４５が、エレベーターコントローラ５のファームイメージ３１の更新が完了した時点でエレベーター１５の行先階が登録された場合に、エレベーターコントローラ５の新たな呼びの受付を保留とする。そして、エレベーターコントローラ５のイメージ構築部４５は、行先階にかごが到着した後に、かごの安全状態を確認できた場合に、エレベーターコントローラ５の再起動を実施する。このため、利用者のいないエレベーター１５でエレベーターコントローラ５が再起動されることとなり、利用者に不便を生じさせない。
　始めに、エレベーターコントローラ５は、運行状態の一つである行先階情報を取得する（Ｓ１０１）。次に、エレベーターコントローラ５は、行先階情報を判定する（Ｓ１０２）。行先階が複数登録されている場合には、エレベーター１５の運行を継続する必要があるため再起動することはできない。一方、行先階に一つの階が登録されている、又は行先階が登録されていない場合には（Ｓ１０２のＮＯ）、エレベーターコントローラ５は、新たに呼びの登録が発生しないように呼び登録をマスクする（Ｓ１０３）。そこで、エレベーターコントローラ５は、新たな呼びを受け付けないモードに遷移すると共に、かご７が行先階に到着した際に再起動できる運行モードとして、例えば保守モードにするように処理する。
　次に、エレベーターコントローラ５は、かご７が行先階に到着したか否かを確認し（Ｓ１０４）、かご７が行先階に到着したか否かを判定する（Ｓ１０５）。かご７が行先階に到着していなければ（Ｓ１０５のＮＯ）、エレベーターコントローラ５は、ステップＳ１０４に戻ってかご７の到着の確認を継続する。
　一方、かご７が行先階に到着した場合には（Ｓ１０５のＹＥＳ）、エレベーターコントローラ５は、かご状態を取得する（Ｓ１０６）。次に、エレベーターコントローラ５は、取得したかご状態が、少なくとも乗客に対して安全な状態であるか否かを判定する（Ｓ１０７）。
　かご７に乗客が乗っておらず且つドアが閉じている状態が一番安全な状態である。安全状態でないと判定した場合（Ｓ１０７のＮＯ）、エレベーターコントローラ５は、本処理を終了する。一定時間後、エレベーターコントローラ５は、ステップＳ１０１から処理を再開する。一方、安全状態と判定した場合には（Ｓ１０７のＹＥＳ）、エレベーターコントローラ５は、自身の再起動を実行し（Ｓ１０８）、本処理を終了する。
　このような処理により、エレベーターコントローラ５は、ファームイメージ３１を更新した際に、保守モードのように特別なモードや作業時間を確保することなく、新たなファームイメージ３１を適用するための再起動をすることが可能となる。
＜フロアコントローラの再起動（呼び登録の確認）＞
　次に、フロアコントローラ１１が、運行状態の一つである上下呼びの登録に応じて、更新されたファームイメージ３１を適用するために再起動する処理について、図２０を用いて説明する。ここでは、フロアコントローラ１１のイメージ構築部４５が、フロアコントローラ１１のファームイメージ３１の更新が完了した時点で呼びの登録を確認し、呼びが登録されていない場合に、フロアコントローラ１１の再起動を実施する。このため、利用者のいないフロアでフロアコントローラ１１が再起動されることとなり、利用者に不便を生じさせない。
　図２０は、フロアコントローラ１１がファームイメージ３１を適用するために再起動する処理の例を示すフローチャートである。
　始めに、フロアコントローラ１１は、上下呼びの登録の状態を取得する（Ｓ１１１）。
次に、フロアコントローラ１１は、上下呼びの登録の有無を判定する（Ｓ１１２）。上下呼びの登録が有る場合（Ｓ１１２のＹＥＳ）、エレベーター１５の運転が継続しているので再起動できない。したがって、本処理はここで終了し、一定時間後、フロアコントローラ１１は、ステップＳ１１１から処理を再開する。
　一方、上下呼びの登録が無い場合（Ｓ１１２のＮＯ）、エレベーター１５の運行状態から当該フロアのフロアコントローラ１１が一時的に切り離された状態に相当するので、フロアコントローラ１１は、再起動を実行し（Ｓ１１３）、本処理を終了する。
　このような処理により、フロアコントローラ１１は、ファームイメージ３１を更新した際に、保守モードのように特別なモードや作業時間を確保することなく、新たなファームイメージ３１を適用するための再起動をすることが可能となる。
　なお、本発明は上述した各実施形態に限られるものではなく、請求の範囲に記載した本発明の要旨を逸脱しない限りその他種々の応用例、変形例を取り得ることは勿論である。
　例えば、上述した各実施形態は本発明を分かりやすく説明するために装置及びシステムの構成を詳細かつ具体的に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されない。また、ここで説明した実施形態の構成の一部を他の実施形態の構成に置き換えることは可能であり、さらにはある実施形態の構成に他の実施形態の構成を加えることも可能である。また、各実施形態の構成の一部について、他の構成の追加、削除、置換をすることも可能である。
　また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際には殆ど全ての構成が相互に接続されていると考えてもよい。
　１…センタ、３…通信コントローラ、４…群管理コントローラ、５…エレベーターコントローラ、１０…かごコントローラ、１１…フロアコントローラ、１８…エレベーターグループ、１９…保守端末、２０…コントローラ、３０…マスタコントローラ、３１…ファームイメージ、３２…イメージ分割部、３３…運行状態取得部、３４…順番生成部、３５…パケット生成部、３６…マスタ通信部、４０…サブコントローラ、４１…サブ通信部、４２…パケット解釈部、４３…送信先抽出部、４４…パケット生成部、４５…イメージ構築部、５０…パケット、１００…エレベーターシステム、２００…パケット通信システム

Claims (15)

  1. 　ファームウェアを送信するマスタコントローラと、前記ファームウェアを受信して前記ファームウェアを更新するサブコントローラとを備えるエレベーターシステムであって、
    　前記マスタコントローラは、前記エレベーターの運行状態に応じて、複数の前記サブコントローラに対する前記ファームウェアの送信順番を生成し、前記送信順番が優先される前記サブコントローラに対して、前記ファームウェア及び前記送信順番を含む第１送信データを送信し、
    　前記送信順番が優先される前記サブコントローラは、前記マスタコントローラから前記第１送信データを受信して前記ファームウェアの更新を行い、前記送信順番が次に優先される前記サブコントローラに前記第１送信データを送信する
    　エレベーターシステム。
  2. 　前記マスタコントローラは、
    　エレベーターの運行状態を取得する運行状態取得部と、
    　前記ファームウェアの送信先である前記サブコントローラの送信順番を前記運行状態に応じて生成する順番生成部と、
    　前記ファームウェアを分割するファームウェア分割部と、
    　前記送信順番にしたがって前記サブコントローラに前記ファームウェアを送信するための第１送信データを生成する第１送信データ生成部と、
    　前記送信順番が最先である前記サブコントローラに前記第１送信データを送信する第１通信部と、を備え、
    　前記第１送信データ生成部は、前記マスタコントローラを識別する情報と、前記サブコントローラを識別する情報と、前記送信順番と、分割された前記ファームウェアの構築順番と、分割された前記ファームウェアとを含む前記第１送信データを生成する
    　請求項１に記載のエレベーターシステム。
  3. 　前記サブコントローラは、前記マスタコントローラ、又は前記第１送信データの送信元である前記サブコントローラから前記第１送信データを受信する第２通信部と、
    　前記第１送信データを解釈するデータ解釈部と、
    　前記データ解釈部が解釈した、分割された前記ファームウェアを前記構築順番に従って元の前記ファームウェアに構築するファームウェア構築部と、
    　前記データ解釈部が解釈した、前記送信順番に基づいて、前記第１送信データの次の送信先である前記サブコントローラを抽出する送信先抽出部と、
    　前記第１送信データの次の送信先である前記サブコントローラに前記ファームウェアを送信するための第２送信データを生成する第２送信データ生成部と、を有し、
    　前記第２通信部は、前記第２送信データを次の送信先である前記サブコントローラに送信する
    　請求項２に記載のエレベーターシステム。
  4. 　前記ファームウェア構築部による前記ファームウェアの更新途中に異常が発生した場合に、前記第２通信部は、前記異常に関する情報を含むデータを、前記送信順番とは逆順で前記マスタコントローラに送信する
    　請求項３に記載のエレベーターシステム。
  5. 　前記ファームウェア構築部は、前記ファームウェアの更新途中に異常が発生した場合に、前記ファームウェア構築部が構築していた前記ファームウェアを消去する
    　請求項４に記載のエレベーターシステム。
  6. 　前記第２通信部は、前記第１送信データの次の送信先である前記サブコントローラから前記ファームウェアの更新途中に発生した異常に関する情報を含むデータを受信した場合に、前記異常に関する情報を含むデータを送信した前記サブコントローラをスキップして、後続の前記サブコントローラに前記第２送信データを送信する
    　請求項３に記載のエレベーターシステム。
  7. 　前記エレベーターの動作を制御するエレベーターコントローラと、
    　前記エレベーターが昇降するフロアごとに設けられ、前記フロアの状況を前記エレベーターコントローラに伝える複数のフロアコントローラと、を備え、
    　前記エレベーターコントローラ又は複数のフロアコントロ―ラのうち、前記ファームウェアが記憶されている一つがマスタコントローラであり、他がサブコントローラである場合に、前記マスタコントローラが前記送信順番を含む前記第１送信データを前記サブコントローラに送信し、前記第１送信データを受信した前記サブコントローラが前記ファームウェアを更新する
    　請求項３に記載のエレベーターシステム。
  8. 　前記マスタコントローラは、前記運行状態として取得した、各フロアの呼び登録の状況に応じて前記送信順番を生成し、前記フロアの滞在人数の状況に応じて、前記送信順番を並べ替える
    　請求項７に記載のエレベーターシステム。
  9. 　前記ファームウェア構築部は、前記フロアコントローラのファームウェアの更新が完了した時点で呼びの登録を確認し、呼びが登録されていない場合に、前記フロアコントローラの再起動を実施する
    　請求項７に記載のエレベーターシステム。
  10. 　前記エレベーターの動作を制御する複数のエレベーターコントローラの動作を制御する群管理コントローラと、
    　複数のエレベーターコントローラと、を備え、
    　前記群管理コントローラ又は複数のエレベーターコントロ―ラのうち、前記ファームウェアが記憶されている一つがマスタコントローラであり、他がサブコントローラである場合に、前記マスタコントローラが前記送信順番を含む前記第１送信データを前記サブコントローラに送信し、前記第１送信データを受信した前記サブコントローラが前記ファームウェアを更新する
    　請求項３に記載のエレベーターシステム。
  11. 　前記順番生成部は、前記運行状態として取得した、複数の前記エレベーターへの呼びの割当の状況に応じて前記送信順番を生成する
    　請求項１０に記載のエレベーターシステム。
  12. 　前記ファームウェア構築部は、前記エレベーターコントローラの前記ファームウェアの更新が完了した時点で前記エレベーターの行先階が登録された場合に、前記エレベーターコントローラの新たな呼びの受付を保留とし、前記行先階にかごが到着した後に、前記かごの安全状態を確認できた場合に、前記エレベーターコントローラが再起動を実施する
    　請求項１０に記載のエレベーターシステム。
  13. 　複数のエレベーターコントローラの動作を制御する複数の群管理コントローラに対する通信を制御する通信コントローラと、
    　複数の前記群管理コントローラと、を備え、
    　前記通信コントローラ又は複数の前記群管理コントロ―ラのうち、前記ファームウェアが記憶されている一つがマスタコントローラであり、他がサブコントローラである場合に、前記マスタコントローラが前記送信順番を含む前記第１送信データを前記サブコントローラに送信し、前記第１送信データを受信した前記サブコントローラが前記ファームウェアを更新する
    　請求項３に記載のエレベーターシステム。
  14. 　前記順番生成部は、前記運行状態として取得した、複数の前記群管理コントローラへの呼びの割当回数の状況に応じて前記送信順番を生成し、
    　前記ファームウェア構築部は、前記群管理コントローラに対する前記ファームウェアの更新が完了した時点で呼びの割当処理が実行されていない場合に、前記ファームウェアの更新が完了した群管理コントローラが再起動を実施する
    　請求項１３に記載のエレベーターシステム。
  15. 　ファームウェアを送信するマスタコントローラと、前記ファームウェアを受信して前記ファームウェアを更新するサブコントローラとを備えるエレベーターシステムで行われるファームウェア送信方法であって、
    　前記マスタコントローラが、前記エレベーターの運行状態に応じて、複数の前記サブコントローラに対する前記ファームウェアの送信順番を生成し、前記送信順番が優先される前記サブコントローラに対して、前記ファームウェア及び前記送信順番を含む第１送信データを送信する処理と、
    　前記送信順番が優先される前記サブコントローラは、前記マスタコントローラから前記第１送信データを受信して前記ファームウェアの更新を行い、前記送信順番が次に優先される前記サブコントローラに前記第１送信データを送信する処理と、を含む
    　ファームウェア送信方法。
PCT/JP2022/043113 2022-03-01 2022-11-22 エレベーターシステム及びファームウェア送信方法 WO2023166795A1 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2022-030614 2022-03-01
JP2022030614A JP2023127066A (ja) 2022-03-01 2022-03-01 エレベーターシステム及びファームウェア送信方法

Publications (1)

Publication Number Publication Date
WO2023166795A1 true WO2023166795A1 (ja) 2023-09-07

Family

ID=87883569

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2022/043113 WO2023166795A1 (ja) 2022-03-01 2022-11-22 エレベーターシステム及びファームウェア送信方法

Country Status (2)

Country Link
JP (1) JP2023127066A (ja)
WO (1) WO2023166795A1 (ja)

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2007091330A1 (ja) * 2006-02-10 2007-08-16 Mitsubishi Denki Kabushiki Kaisha エレベータ制御プログラムの遠隔更新システム
JP2008254885A (ja) * 2007-04-05 2008-10-23 Mitsubishi Electric Corp エレベータの制御システム
CN104973466A (zh) * 2015-05-25 2015-10-14 广州日滨科技发展有限公司 电梯控制程序的远程更新方法和***
JP2016143359A (ja) * 2015-02-05 2016-08-08 シャープ株式会社 電子機器及びファームウェア更新方法
JP2017186146A (ja) * 2016-04-08 2017-10-12 株式会社日立製作所 群管理エレベーター装置及び呼び登録装置の機能変更方法
US20200283266A1 (en) * 2017-10-27 2020-09-10 Inventio Ag Safety system for building-related passenger transportation system
JP2021130534A (ja) * 2020-02-19 2021-09-09 株式会社日立製作所 エレベーター制御装置及びエレベーター制御方法

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2007091330A1 (ja) * 2006-02-10 2007-08-16 Mitsubishi Denki Kabushiki Kaisha エレベータ制御プログラムの遠隔更新システム
JP2008254885A (ja) * 2007-04-05 2008-10-23 Mitsubishi Electric Corp エレベータの制御システム
JP2016143359A (ja) * 2015-02-05 2016-08-08 シャープ株式会社 電子機器及びファームウェア更新方法
CN104973466A (zh) * 2015-05-25 2015-10-14 广州日滨科技发展有限公司 电梯控制程序的远程更新方法和***
JP2017186146A (ja) * 2016-04-08 2017-10-12 株式会社日立製作所 群管理エレベーター装置及び呼び登録装置の機能変更方法
US20200283266A1 (en) * 2017-10-27 2020-09-10 Inventio Ag Safety system for building-related passenger transportation system
JP2021130534A (ja) * 2020-02-19 2021-09-09 株式会社日立製作所 エレベーター制御装置及びエレベーター制御方法

Also Published As

Publication number Publication date
JP2023127066A (ja) 2023-09-13

Similar Documents

Publication Publication Date Title
JP4963292B2 (ja) エレベータ制御プログラムの遠隔更新システム
EP3502901B1 (en) Method and apparatus for monitoring and reconstructing a software-defined plc
CN108712994B (zh) 电梯***
CN102693153A (zh) 在静态分配和嵌入的软件结构上进行动态分配的方法
CN102190215A (zh) 电梯的控制装置
CN106209966A (zh) 管控端更新设备状态的方法、服务端的处理方法和装置
EP3542272A1 (en) Systems and methods for providing a notification system architecture
CN104021078A (zh) 软件监控装置及方法
CN106790092A (zh) 远程过程调用服务端控制***及方法
JP4853883B2 (ja) エレベータ群管理システム
CN111274033A (zh) 一种资源部署方法、装置、服务器以及存储介质
CN110521173A (zh) 虚拟网络***、vim、虚拟网络控制方法以及记录介质
WO2023166795A1 (ja) エレベーターシステム及びファームウェア送信方法
CN102204234B (zh) 呼叫控制***、呼叫控制装置、终端装置以及呼叫控制方法
CN109960233A (zh) 用于自动配置在过程控制***中的更换现场设备的方法和设备
JP5473346B2 (ja) エレベータの群管理制御装置
CN118284573A (zh) 电梯***和固件发送方法
CN107872404A (zh) 业务分片处理方法、装置及软件定义网络控制器
CN108243205A (zh) 一种用于控制云平台资源分配的方法、设备与***
US20030154472A1 (en) Installation server
CN113086783B (zh) 一种电梯群管制运行***及方法
CN116860382A (zh) 基于容器的微服务集群实现的方法及装置
CN114644267A (zh) 双层电梯的组群管理控制装置以及组群管理控制方法
JP2008182411A (ja) 情報配信プログラム、情報配信装置、情報配信方法
JP7423705B1 (ja) エレベータ制御システム

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22929939

Country of ref document: EP

Kind code of ref document: A1