WO2023166795A1 - Système d'ascenseur et procédé de transmission de micrologiciel - Google Patents

Système d'ascenseur et procédé de transmission de micrologiciel 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)
Japanese (ja)
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 株式会社日立製作所
Priority to CN202280077187.8A priority Critical patent/CN118284573A/zh
Publication of WO2023166795A1 publication Critical patent/WO2023166795A1/fr

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

Dans la présente invention, un dispositif de commande maître situé dans un système d'ascenseur génère un ordre de transmission pour une image de micrologiciel pour une pluralité de sous-dispositifs de commande en fonction d'un état de fonctionnement d'un ascenseur et transmet des paquets contenant l'image de micrologiciel et l'ordre de transmission à un sous-dispositif de commande priorisé dans l'ordre de transmission. Le sous-dispositif de commande priorisé dans l'ordre de transmission reçoit les paquets en provenance du dispositif de commande maître, met à jour l'image de micrologiciel, et transmet les paquets au sous-dispositif de commande priorisé ensuite dans l'ordre de transmission.
PCT/JP2022/043113 2022-03-01 2022-11-22 Système d'ascenseur et procédé de transmission de micrologiciel WO2023166795A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202280077187.8A CN118284573A (zh) 2022-03-01 2022-11-22 电梯***和固件发送方法

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 (fr) 2023-09-07

Family

ID=87883569

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2022/043113 WO2023166795A1 (fr) 2022-03-01 2022-11-22 Système d'ascenseur et procédé de transmission de micrologiciel

Country Status (3)

Country Link
JP (1) JP2023127066A (fr)
CN (1) CN118284573A (fr)
WO (1) WO2023166795A1 (fr)

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2007091330A1 (fr) * 2006-02-10 2007-08-16 Mitsubishi Denki Kabushiki Kaisha système de mise à jour à distance pour des programmes de commande d'ascenseur
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 (fr) * 2006-02-10 2007-08-16 Mitsubishi Denki Kabushiki Kaisha système de mise à jour à distance pour des programmes de commande d'ascenseur
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
CN118284573A (zh) 2024-07-02

Similar Documents

Publication Publication Date Title
JP4963292B2 (ja) エレベータ制御プログラムの遠隔更新システム
EP3502901B1 (fr) Procédé et appareil de surveillance et de reconstruction d'un plc défini par logiciel
CN104486394B (zh) 不中断业务软件升级方法及装置
CN108712994B (zh) 电梯***
CN102693153A (zh) 在静态分配和嵌入的软件结构上进行动态分配的方法
CN102190215A (zh) 电梯的控制装置
CN106209966A (zh) 管控端更新设备状态的方法、服务端的处理方法和装置
EP3542272A1 (fr) Systèmes et procédés pour fournir une architecture de système de notification
CN109960233A (zh) 用于自动配置在过程控制***中的更换现场设备的方法和设备
CN106790092A (zh) 远程过程调用服务端控制***及方法
JP4853883B2 (ja) エレベータ群管理システム
CN110521173A (zh) 虚拟网络***、vim、虚拟网络控制方法以及记录介质
WO2023166795A1 (fr) Système d'ascenseur et procédé de transmission de micrologiciel
CN102204234B (zh) 呼叫控制***、呼叫控制装置、终端装置以及呼叫控制方法
JP5473346B2 (ja) エレベータの群管理制御装置
CN107872404A (zh) 业务分片处理方法、装置及软件定义网络控制器
CN108243205A (zh) 一种用于控制云平台资源分配的方法、设备与***
US20030154472A1 (en) Installation server
CN113086783B (zh) 一种电梯群管制运行***及方法
CN116860382A (zh) 基于容器的微服务集群实现的方法及装置
CN114330974A (zh) 机器人调度方法、装置、电子设备和存储介质
JP2008182411A (ja) 情報配信プログラム、情報配信装置、情報配信方法
JP7423705B1 (ja) エレベータ制御システム
CN115448116A (zh) 一种电梯云控制***
CN109634749A (zh) 一种分布式统一调度方法及设备

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