Software Update System and Software Update Method

Abstract

To provide a technology capable of efficiently updating an elevator software.SOLUTION: A software update system updates the software of a control device to control an elevator. The control device comprises a memory to store the software and a control part to execute the software. The storage area of the memory is divided into multiple areas corresponding to control function category of the elevator. The software is stored in the corresponding area divided, based on the control function category. The control part identifies the control function category changed by the updating and rewrites selectively the corresponding area to changed control function when the software is updated.SELECTED DRAWING: Figure 1

Description

Technical Field

[0001] The present invention relates to an elevator software update system and software update.

Background Art

[0002] Conventionally, in order to update the software of an automatic passenger conveyance device such as an elevator, there is a technique described in Japanese Patent Application Laid-Open No. 2017-97880 (Patent Document 1). This publication states that "in a method of automatically updating a first control application included in a component of an automatic passenger conveyance device, the automatic passenger conveyance device is stopped from operating, a switch from the first control application to a second control application is performed, and an inspection operation after the switch of the second control application is performed to determine whether the automatic passenger conveyance device operates correctly in a state where the second control application is activated. If the automatic passenger conveyance device operates correctly in the inspection operation after the switch of the second control application, the automatic passenger conveyance device is operated."

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] In the conventional technology, even when performing a software update for a function that does not affect the operation, it was necessary to stop the elevator from operating and update the entire software. For this reason, the conventional software update of the elevator was not efficient.

[0005] Therefore, an object of the present invention is to provide a technology capable of efficiently updating the software of an elevator.

Means for Solving the Problem

[0006] To achieve the above object, one of the typical software update systems of the present invention is a software update system for updating the software of a control device that controls an elevator. The control device includes a memory that stores the software and a control unit that executes the software. The storage area of the memory is divided into a plurality of areas corresponding to the classification of the control functions of the elevator. The software is divided based on the classification of the control functions and stored in the corresponding areas. When the control unit executes the update of the software, it specifies the classification of the control functions changed by the update and selectively rewrites the area corresponding to the changed control functions. Also, one of the typical software update methods of the present invention is a software update method for updating the software of a control device that controls an elevator. The method includes steps of: the control device obtaining software for update; comparing the software for update with the existing software to confirm the changed control functions; specifying the classification of the changed control functions; and rewriting the existing software stored in the memory with the software for update. The storage area of the memory is divided into a plurality of areas corresponding to the classification of the control functions of the elevator. The existing software is divided based on the classification of the control functions and stored in the corresponding areas. When rewriting, the control device selectively rewrites the area corresponding to the changed control functions.

Advantages of the Invention

[0007] According to the present invention, a technology capable of efficiently updating the software of an elevator can be provided. Problems, configurations, and effects other than those described above will be clarified by the description of the following embodiments.

Brief Description of the Drawings

[0008]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Modes for Carrying Out the Invention

[0009] Hereinafter, examples will be described with reference to the drawings.

Examples

[0010] FIG. 1 is a configuration diagram of the software update system of Example 1. The software update system of Example 1 includes a database 10, a server 20, a network 30, a control device 40, and an elevator 60.

[0011] The elevator 60 has a car and a drive mechanism. The control device 40 controls the operation of the elevator 60. When a plurality of elevators 60 are installed in one building, a control device 40 is provided for each elevator 60.

[0012] The control device 40 is connected to the server 20 via the network 30. The server 20 registers and manages information about a plurality of control devices 40 in the database 10. The information of the control device 40 includes the model, software version, installation location, administrator, and the like.

[0013] In addition, the database 10 stores the software itself used by the control device 40. When there is new software applicable to the control device 40, the server 20 transmits the software to the control device 40 as software for update. The control device 40 executes software update by replacing the existing software that has been used so far with the software for update received from the server 20.

[0014] The control device 40 has a CPU (Central Processing Unit) 41, a RAM (Random Access Memory) 42, and a ROM (Read Only Memory) 43 inside. The ROM 43 is a non-volatile memory, and the RAM 42 is a volatile memory.

[0015] The CPU 41 reads the software stored in the ROM 43, expands it in the RAM 42, and executes the expanded software, thereby operating as a control unit. Specifically, the CPU 41 operates as a reception unit 51, a difference confirmation unit 52, a data consistency unit 53, a transmission grasp unit 54, and a switching unit 55 regarding software update.

[0016] The reception unit 51 receives the software for update from the server 20. The difference confirmation unit 52 confirms the difference between the software for update and the existing software stored in the ROM 43. By performing this difference confirmation, it is possible to identify which control functions among the elevator control functions provided by the software are changed by the update.

[0017] When the data integration unit 53 receives software for update, it checks the integrity of the received software. Any method such as a checksum may be used for the integrity check. The transmission monitoring unit 54 performs a process of checking the data transmission state between the control device 40 and the server 20. The switching unit 55 rewrites the ROM 43 to switch the existing software to the software for update. The switching unit 55 can make the input reception of a predetermined switching trigger a condition for switching. The switching trigger is a signal input in a state where software update can be safely executed, such as stopping the operation of the elevator.

[0018] Figure 2 is an explanatory diagram of the software structure. The software of the control device 40 has an OS (Operating System) part, a standard part, a case - specific response part, and a local adjustment part. The reception unit 51, the difference confirmation unit 52, the data integration unit 53, the transmission monitoring unit 54, and the switching unit 55 shown in Figure 1 belong to the OS part.

[0019] The standard part provides standard functions that are commonly used in multiple elevators among the functions for controlling the operation of the elevator. The case - specific response part provides functions that are individually provided for each case or functions in which the functions of existing elevators are arranged specifically for each case among the functions for controlling the operation of the elevator. For example, changing the notification conditions of the elevator specifically for each case can be cited. The local adjustment part provides functions adjusted locally at the time of elevator installation.

[0020] Furthermore, the standard part is divided into an invariant part, an important variable part, and a variable part. The invariant part is a standard function that provides functions that are not expected to be changed by updates. For example, functions related to laws and functions certified by a third party at the time of delivery can be cited. The important variable part is a standard function that provides functions that require update in a state where the operation is stopped for ensuring safety, etc. For example, functions related to the raising and lowering of the car and the opening and closing of the doors are provided by the important variable part. The variable part is a standard function that provides functions that can be updated during operation. For example, functions related to notification to passengers are provided by the variable part. Thus, the control functions of the elevator can be classified into an OS section, an invariant section, a critically variable section, a variable section, a project response section, and a local adjustment section.

[0021] The storage area of ROM43 is divided into a plurality of areas corresponding to the classification of the elevator control functions. Then, the software is divided based on the classification of the control functions and stored in the corresponding areas.

[0022] FIG. 3 is an explanatory diagram of the areas of ROM43. In FIG. 3, ROM43 is divided into areas 71 to 76. Each area is defined by a starting address and an area size. Areas 71 to 76 are associated with the classification of the control functions. For example, area 71 is associated with the OS section. Area 72 is associated with the invariant section. Area 73 is associated with the critically variable section. Area 74 is associated with the variable section. Area 75 is associated with the project response section. Area 76 is associated with the local adjustment section.

[0023] Thus, since ROM43 is divided into a plurality of areas and the software is divided and stored in each area, an agreement is required for the transfer of data across areas. Therefore, a function management table for managing the addresses where each function is stored is provided. The function management table may simply hold each function. Or, a data manager in charge of the function management table may be provided, and each function may inquire of the data manager to identify the access destination.

[0024] FIG. 4 is an explanatory diagram of the function management table. In FIG. 4, the function management table manages the addresses of function A, function B, and function C. Function A is realized including the processing of function A itself, a data acquisition section, a data update section, and data.

[0025] The data update unit updates the data of Function A with the data provided from the outside. The processing of Function A is performed using the data of Function A and updates the data of Function A. The data acquisition unit acquires the data of Function A and provides it to the outside. Regarding these data update unit and data acquisition unit, they may be defined like functions to perform data acquisition and update. However, in order to maintain the implementation speed, an indirect table may be provided for the data, and in the program, it may be a method of directly accessing the data by pointer access.

[0026] Regarding Function B as well as Function A, processing, a data acquisition unit, a data update unit, and data are included. The data acquisition unit and data update unit of each function specify the access destination by referring to the function management table. Therefore, the data exchange between functions can be realized.

[0027] Figure 5 is a flowchart of the control device of the first embodiment. First, the reception unit 51 determines whether it has received the ROM data which is the data of the software for update (step S101). If it has not received the ROM data (step S101; No), the process ends as it is.

[0028] If it has received the ROM data (step S101; Yes), the transmission grasping unit 54 checks the transmission state and determines whether the communication has been completed (step S102). If the communication has not been completed (step S102; No), step S102 is repeated. If the communication has been completed (step S102; Yes), the data matching unit 53 checks the consistency (step S103).

[0029] If the consistency cannot be confirmed (step S103; No), the process ends as it is. If the consistency can be confirmed (step S103; Yes), the difference confirmation unit 52 performs the difference confirmation. By this difference confirmation, it is possible to specify which control functions among the elevator control functions provided by the software are changed by the update.

[0030] If the part to be changed is an invariant part of the standard part (step S105; Yes), the update is not possible. Therefore, the switching unit 55 discards the communication data (step S106) and ends the process.

[0031] If the part to be changed is not an invariant part (step S105; Yes) and is an important variable part (step S107; Yes), the switching unit 55 selects the area of the important variable part as the object to be rewritten (step S109).

[0032] If the part to be changed is not an important variable part (step S107; Yes) and is a case - handling part (step S108; Yes), the switching unit 55 selects the area of the case - handling part as the object to be rewritten (step S110).

[0033] After step S109 or step S110, the switching unit 55 updates the sub - ROM by writing the received ROM data into the sub - ROM (step S111). The sub - ROM is, for example, a non - volatile memory similar to ROM43 and is provided for backup.

[0034] After step S111, the switching unit 55 determines whether it has received an input of a switching trigger (step S112). If it has not received an input of a switching trigger (step S112; No), it repeats step S112 to wait for an input of a switching trigger. When it receives an input of a switching trigger (step S112; Yes), the switching unit 55 updates by rewriting ROM43, which is the main ROM (step S113) and ends the process.

[0035] If the part to be changed is not an important variable part (step S107; Yes) and is not a case - handling part (step S108; No), the switching unit 55 selects the area of the variable part as the object to be rewritten (step S114). Then, it updates by rewriting ROM43, which is the main ROM (step S115) and ends the process.

Example

[0036] The software update system of Example 2 has a function for the control device to perform an operation test. FIG. 6 is a configuration diagram of the software update system of Example 2. As shown in FIG. 6, the control device 40a of Example 2 is different from Example 1 in that the CPU 41 further realizes the functions of the target area determination unit 56, the target test determination unit 57, and the virtual test execution unit 58. Since the other configurations and operations are the same as those of Example 1, the same reference numerals are assigned to the same components and the description thereof is omitted.

[0037] The target area determination unit 56 determines the area where the control function changed by the update is stored. The target test determination unit 57 determines the area affected by the control function changed by the update. The affected area includes the area where the control function changed by the update is stored and the area where the operation and data change due to the changed control function. The virtual test execution unit 58 performs a virtual operation test on the area affected by the update. The switching unit 55 executes the update after confirming that it operates normally by the virtual operation test.

[0038] FIG. 7 is an explanatory diagram of the range of the operation test. For example, when the function A belonging to the important variable part is changed by the update and the important variable part and the case correspondence part are related to the operation of the function A, the virtual test execution unit 58 executes tests A-1 and A-2 for the important variable part and test TA-1 for the case correspondence part. Similarly, when the function B belonging to the variable part is changed by the update and the case correspondence part and the on-site adjustment part are related to the operation of the function B, the virtual test execution unit 58 executes test B-1 for the variable part, test TB-1 for the case correspondence part, and test TB-2 for the on-site adjustment part.

[0039] Here, for the operation test, input conditions and output conditions are defined in advance, and test conditions are set for each function. A virtual data area for test operation is provided, and by using the input conditions and output conditions of the data area, Function A is operated, and the obtained output result is compared with the output conditions to check for consistency. If it matches the preset output conditions, it is considered to be operating properly; if not, it is considered inoperable and judged as an error. Specifically, when Function A is defined as a function, the input arguments are set with specific values as the preset input conditions. In the case of a function without arguments, in the data update section defined in the function, input conditions are defined such that data is updated to the necessary instances as the preset input conditions. The output conditions are the return value of the function under the input conditions, or the data obtained by the data acquisition section from the necessary instances, and the output conditions are defined by specifying what values the data will take.

[0040] In addition to the method of providing a virtual data area for test operation, the operation test may also be carried out by actually switching to the test mode and defining the results of operating the actual elevator as the output conditions. In this case, during a time period when normal people do not ride, the elevator is disconnected from automatic operation and set to a mode where it does not respond to the buttons at the landing. Then, in order to avoid riding with any potential users of the elevator, a notice indicating that it is in the test mode is always left on the display inside the elevator. Also, when a user is detected based on the load, a notice indicating that it is in the test mode and prompting the user to get off is announced via voice or on the display.

[0041] For the actual test, input conditions and output conditions are defined such that the target function becomes effective, and virtual hard inputs are set. For example, when checking the function of responding to the landing buttons, the input conditions are the input of the landing buttons on any floor and waiting for the elevator on any floor, and the output conditions are that the elevator travels from the waiting floor to that floor and the doors open within a preset time (e.g., within 10 seconds) after arriving at that floor.

[0042] Furthermore, the operation test is assumed to separate the important variable parts and the test items activated by the variable parts. Specifically, referring to the data values obtained from the functions and executing the tests up to those of other functions shall be provided in the important variable parts. In the variable parts, only the tests of the own function shall be executed.

[0043] FIG. 8 is a flowchart of the control device according to the second embodiment. The flowchart of FIG. 8 is different from FIG. 5 in that steps S201 to S203 are added. Since the other steps are the same as those in FIG. 5, the same steps are denoted by the same reference numerals and the description thereof is omitted.

[0044] Step S201 is a step to be executed when the change target is an important variable part (step S107; Yes). In step S201, the test execution unit 58 executes a virtual test for the related area of the standard part, and then proceeds to step S109.

[0045] Step S202 is a step to be executed when the change target is the case handling part (step S108; Yes). In step S202, the test execution unit 58 executes a virtual test for the case handling part, and then proceeds to step S110.

[0046] Step S203 is a step to be executed when the change target is not the case handling part (step S108; No). In step S203, the test execution unit 58 executes a virtual test for the variable part, and then proceeds to step S110.

Embodiment

[0047] The software update system according to the third embodiment provides the server with a function of performing an operation test. FIG. 9 is a configuration diagram of the software update system according to the third embodiment. As shown in FIG. 9, the server 20b according to the second embodiment is different from the first embodiment in that it includes an object area discrimination unit 21, an object test discrimination unit 22, and a virtual test execution unit 23.

[0048] The target area discrimination unit 21 operates in the same manner as the target area discrimination unit 56 of the second embodiment. The target test discrimination unit 22 operates in the same manner as the target test discrimination unit 22 of the second embodiment. The virtual test execution unit 23 operates in the same manner as the virtual test execution unit 58 of the second embodiment. The control device 40b has the same configuration as the control device 40 of the first embodiment, but its operation is different.

[0049] FIG. 10 is a flowchart of the server of the third embodiment. First, the server 20b acquires ROM data, which is software data for update, from the database 10 (step S301).

[0050] If the changed part is an invariant part of the standard part (step S302; Yes), the virtual test execution unit 23 performs a virtual test on the related area of the standard part (step S303). Then, the server 20b notifies the target ROM data that there is a change in the invariant part as the notification content (step S304), and proceeds to step S313.

[0051] If the changed part is not an invariant part (step S302; No) and is an important variable part (step S305; Yes), the virtual test execution unit 23 performs a virtual test on the related area of the standard part (step S306). Then, the server 20b notifies the target ROM data that there is a change in the important variable part as the notification content (step S307), and proceeds to step S313.

[0052] If the changed part is not an important variable part (step S305; No) and is a case response part (step S308; Yes), the virtual test execution unit 23 performs a virtual test on the related area of the case response part (step S309). Then, the server 20b notifies the target ROM data that there is a change in the case response part as the notification content (step S310), and proceeds to step S313.

[0053] If the part to be changed is not the case response section (step S308; No), the virtual test execution unit 23 performs a virtual test on the related area of the variable part (step S311). After that, the server 20b notifies the target ROM data that there is a change in the variable part as the notification content (step S312), and proceeds to step S313.

[0054] In step S313, the change function determined as the notification content is notified to the control device 40b. After that, upon receiving a notification from the control device 40b that the transmission preparation of the main ROM is completed (step S314), data for updating the main ROM is transmitted to the control device 40b (step S315), and the process ends.

[0055] FIG. 11 is a flowchart of the control device according to the third embodiment. First, the reception unit 51 determines whether or not it has received ROM data, which is software data for update (step S401). If it has not received the ROM data (step S401; No), the process ends as it is.

[0056] If it has received the ROM data (step S401; Yes), the transmission grasp unit 54 checks the transmission status and determines whether or not the communication has been completed (step S402). If the communication has not been completed (step S402; No), step S402 is repeated. If the communication has been completed (step S402; Yes), the data matching unit 53 checks the integrity (step S403).

[0057] If the integrity cannot be confirmed (step S403; No), the process ends as it is. If the integrity can be confirmed (step S403; Yes), the switching unit 55 updates the sub-ROM by writing the received ROM data to the sub-ROM (step S404).

[0058] After step S404, the switching unit 55 determines whether it has received an input of a switching trigger (step S405). If it has not received an input of a switching trigger (step S405; No), it repeats step S405 to wait for an input of a switching trigger. When it has received an input of a switching trigger (step S405; Yes), the switching unit 55 performs an update by rewriting the ROM 43 which is the main ROM (step S406), and ends the process. The switching trigger may be a switching command from the server 20 to the control device 40, or may be either a switch provided in the control device 40 by a local maintenance staff or a method of manually switching by a specific operation. Also, rewriting the ROM 43 which is the main ROM generally involves performing a software reset after detecting the trigger and starting up from the initial operation. Therefore, it takes time until normal operation after the reset. At that time, since the use of the elevator becomes temporarily unavailable, not only detecting the trigger but also a method of performing switching according to the operating status of the elevator may be used. For example, it is a case such as a time zone when no one uses it like late at night, a service request from the elevator landing for the operation mode, or when the operation mode such as after 3 minutes have passed in a non-response state after the allocation to the specified destination floor in the car is completed.

[0059] As described above, the system disclosed in the embodiment is a software update system for updating the software of the control device 40 that controls the elevator. The control device 40 includes a ROM 43 which is a memory for storing the software, and a CPU 41 as a control unit for executing the software. The storage area of the memory is divided into a plurality of areas corresponding to the classification of the control functions of the elevator, and the software is divided based on the classification of the control functions and stored in the corresponding areas. When the control unit executes the software update, it specifies the classification of the control functions changed by the update, and selectively rewrites the area corresponding to the changed control functions. With such a configuration and operation, the elevator software can be updated by a function to be updated without stopping the operation, and efficient update can be realized.

[0060] Further, according to the disclosed system, the classification of the control functions includes an invariant part that is a standard function commonly used in a plurality of elevators and for which no change is assumed, an important variable part that is the standard function and requires update in a stopped state of operation, a variable part that is the standard function and can be updated during operation, and a case response part that is a function provided corresponding to each elevator individually. It includes. Then, the control unit executes rewriting of an area corresponding to the important variable part, the variable part, and / or the case response part on the condition that an input of a predetermined switching trigger is received. Therefore, regarding the important variable part and the case response part that may affect the safety of operation, reception of a trigger indicating that the operation has stopped is set as a condition for update, and the variable part can be updated during operation.

[0061] Further, according to the disclosed system, the control unit determines an area in which a control function changed by the update is stored, determines an area affected by the control function changed by the update, and performs an operation test on the affected area and then executes the update. With such a configuration and operation, an operation test can be efficiently performed before the update.

[0062] Further, according to the disclosed system, the system further includes a server 20 connected to the control device 40 via a network and transmitting software for update to the control device, and the control device 40 identifies the classification of the control function changed by the update by checking the difference between the software for update received from the server 20 and the existing software. According to such a configuration and operation, it is possible to efficiently check the difference between the software for update received from the server and the existing software.

[0063] Further, according to the disclosed system, the server is further provided which is connected to the control device 40 via a network and transmits the software for update to the control device 40. The server 20 determines the control function to be changed by the update, determines the area affected by the changed control function, performs an operation test on the affected area, and then transmits the software for update to the control device 40. According to such a configuration and operation, it is possible to perform an update after confirming the operation of the software without imposing a load on the control device 40.

[0064] Note that the present invention is not limited to the above embodiments and includes various modifications. For example, the above-described embodiments have been described in detail for easy understanding of the present invention and are not necessarily limited to those having all the configurations described. Further, not only deletion of such a configuration is possible, but also replacement and addition of configurations are possible. As an example, when there are a plurality of control devices 40 in a building, a gateway device may be provided between the server 20 and the plurality of control devices 40. If the gateway device is configured to receive and hold the software for update from the server 20 and appropriately transmit it to the plurality of control devices 40, the load on the server 20 and the network 30 can be reduced.

[0065] In the case where the device to be updated is the control device described above, a method of directly communicating with the control device from the server 20 and transmitting the ROM data in binary can be considered. However, if another device is the target, it is conceivable to directly communicate from the server 20 to the control device 40, transmit the ROM data of the target device in binary, and transmit data from the control device 40 to the target device. At that time, a management ID is provided in the communication data to associate it with the target device, and the control device 40 determines that it is the target device. Regarding the integrity check of the ROM, the integrity check is performed based on the transmitted data and, for example, thumb management, data size, etc., and update communication for the target device is performed.

[0066] Regarding the sub-control device, communication with the control device 40 is always executed, and update communication is executed by either of the following two methods.

[0067] <Method 1> This is a method of performing update communication using the free area of the communication packet without stopping the constant communication. This takes into account the free status of the constant communication, divides the ROM data according to the free status of the communication, and transmits the ROM data. For data division, within the range that can be transmitted during the time zone ensuring the ACK / NACK return time from the data transmission of the control device 40 to the sub-control device, the target data is transmitted. As a result, update transmission can be performed without stopping the normal use of the device.

[0068] <Method 2> Stop the constant communication and temporarily stop the use of the target device. Stopping the communication for using the normal device and only transmitting the ROM data for update has the merit that the transmission completion time of the target data is earlier than that of Method 1.

[0069] Through the communication process to the sub-control device executed by any of the above, data transmission from the server 20 to the sub-control device via the control device 40 becomes possible. After that, software update becomes possible according to the update method described above.

[0070] The switching trigger is set by the transmission data from the control device 40 being transmitted successfully, receiving a signal indicating that the switching preparation of the sub-control device is complete, and receiving a switching command from the control device 40 to the sub-control device. Here, the command transmission timing of the control device 40 is, for example, during a time period when no one uses it such as late at night, when the operation mode is a service request from the elevator landing, or when the car has been assigned to the designated destination floor and no response has been received for 3 minutes. Also, the command transmission timing may be changed for each sub-control device. For example, for the control device of the in-car display and the landing buttons, for the in-car display, a switching command may be issued at the timing when the in-car display is used for energy-saving control, and for the control device of the landing buttons, since they exist on each floor, switching may be performed according to the demand of each floor, or simply switched when the time period when the elevator is not used arrives. By doing so, by adopting respective switching methods and communication methods suitable for the uses of each sub-control device and performing updates, it becomes possible to add new functions and improve conventional functions without impairing usability as much as possible.

Explanation of Signs

[0071] 10: Database, 20: Server, 21: Target Area Discrimination Unit, 22: Target Test Discrimination Unit, 23: Virtual Test Execution Unit, 30: Network, 40: Control Device, 41: CPU, 42: RAM, 43: ROM, 51: Receiver, 52: Difference Confirmation Unit, 53: Data Integration Unit, 54: Transmission Grasping Unit, 55: Switching Unit, 56: Target Area Discrimination Unit, 57: Target Test Discrimination Unit, 58: Virtual Test Execution Unit, 60: Elevator, 71 - 76: Areas

Claims

1. A software update system for updating the software of a control device that controls an elevator, wherein the control device includes a memory that stores the software, and a control unit that executes the software, wherein the storage area of the memory is divided into a plurality of areas corresponding to classifications of the control functions of the elevator, and the software is divided based on the classifications of the control functions and stored in the corresponding areas, wherein when the control unit executes an update of the software, the control unit identifies the classification of the control function changed by the update and selectively rewrites the area corresponding to the changed control function, wherein the classifications of the control functions include an invariant part that is a standard function commonly used in a plurality of elevators and for which no change is assumed, an important variable part that is the standard function and requires updating in a stopped state of operation, a variable part that is the standard function and can be updated during operation, and includes a software update system characterized by the above.

2. The software update system according to claim 1, wherein the classifications of the control functions include a case response part that is a function provided corresponding to each elevator individually, wherein the control unit executes rewriting of the area corresponding to the important variable part, the variable part, and / or the case response part on the condition that an input of a predetermined switching trigger is received, a software update system characterized by the above.

3. The software update system according to claim 1, wherein the control unit determines the area in which the control function changed by the update is stored, determines the area affected by the control function changed by the update, performs an operation test on the affected area, and then executes the update, a software update system characterized by the above.

4. The software update system according to claim 1, further comprising a server connected to the control device via a network and transmitting software for update to the control device, wherein the control device identifies the classification of the control function changed by the update by checking the difference between the software for update received from the server and the existing software. a software update system characterized by the above.

5. A software update system according to claim 1, further comprising a server connected to the control device via a network and transmitting software for update to the control device, wherein the server determines a control function to be changed by the update, determines an area affected by the changed control function, performs an operation test on the affected area, and then transmits the software for update to the control device. A software update system characterized by the above.

6. A software update method for updating software of a control device that controls an elevator, wherein the control device acquires software for update, compares the software for update with the existing software to confirm a control function to be changed, identifies a classification of the changed control function, rewrites the existing software stored in the memory with the software for update, including wherein the storage area of the memory is divided into a plurality of areas corresponding to classifications of the control functions of the elevator, and the existing software is divided based on the classification of the control functions and stored in the corresponding areas, wherein the control device selectively rewrites the area corresponding to the changed control function during the rewriting, wherein the classification of the control functions includes an invariant part that is a standard function commonly used in a plurality of elevators and for which no change is assumed, an important variable part that is the standard function and requires update in a stopped state, a variable part that is the standard function and can be updated during operation, and is characterized by the above.

7. A software update system according to claim 1, wherein the control device includes sub-control devices suitable for respective applications, and software update of the sub-control devices is performed via the control device, and a communication method and a switching method suitable for the applications of the sub-control devices are selected and executed.

8. A software update system according to claim 7, The sub-control device is managed by the control device with a target ID, and the target ROM data is given the ID. The control device updates the target sub-control device according to the ID. A software update system characterized by this.

9. The software update system according to claim 7, wherein The communication method is implemented by either transmitting the software data for the update without stopping the constant communication or by stopping the constant communication and transmitting the software data for the update. A software update system characterized by this.

Images