Lifting machine system and lifting machine control method

Abstract

To ensure that incident response for a lifting machine such as an elevator is carried out appropriately.SOLUTION: A lifting machine control system comprises an incident information acquisition unit 59 to acquire incident information about a lifting machine, a countermeasure confirmation unit 54 to confirm the countermeasure for the incident information acquired by the incident information acquisition unit 59, a renewal equipment determination unit 56 to determine renewal equipment of the lifting machine required for the incident countermeasure based on the countermeasure confirmed by the countermeasure confirmation unit 54, and a renewal period setting unit 58 to set the implementation period of the incident countermeasure for the renewal equipment based on the configuration information and the operating status of the lifting machine.SELECTED DRAWING: Figure 4

Description

[Technical Field]

[0001] The present invention relates to an elevator system and an elevator control method. [Background technology]

[0002] Control devices for elevators and other elevators are configured to communicate with control centers via telephone lines or dedicated lines, and computer-based control devices are susceptible to unauthorized attacks via the connected lines. Therefore, control devices for elevators and other elevators, like general computers, require incident prevention measures against unauthorized attacks. Patent Document 1 describes a technology for managing setting information for incident occurrence in an elevator. Patent Document 1 also describes a technology for calculating recommended settings for elevator setting information included in the elevator attribute information based on incident information and elevator attribute information. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Patent No. 5558194 Summary of the Invention [Problem to be solved by the invention]

[0004] According to the technology described in Patent Document 1, it is possible to provide an evaluation of parameters for incidents, that is, occurrence of failures, and to provide recommended parameter values. However, there are cases where incidents cannot be resolved by simply changing configuration information. For example, security incidents caused by external attacks cannot be resolved by simply changing configuration information. In the case of security incidents, there is a problem in that it is not possible to clearly identify the hardware or software related to the incident that needs to be corrected at the time the incident occurs.

[0005] Furthermore, the technology described in Patent Document 1 does not mention the timing of applying the recommended setting values ​​to elevator systems. Elevator systems are systems that operate continuously. For this reason, it is difficult to simultaneously apply a control program correction program, which is a countermeasure against an incident, to all elevator systems. Furthermore, elevators have a variety of optional functions to choose from, not just the number of floors, so even with standard control functions, the operation status of the function varies greatly depending on the installation and operating environment. Therefore, implementing incident countermeasures uniformly is likely to have a significant impact on the operating rate depending on the environment, especially the operational aspects.

[0006] In view of the above, an object of the present invention is to provide an elevator system and an elevator control method that can appropriately take measures against incidents in elevators and other elevators. [Means for solving the problem]

[0007] In order to solve the above problems, for example, the configurations described in the claims are adopted. The present application includes multiple means for solving the above-mentioned problems, and one example thereof is an elevator control system comprising an incident information acquisition unit that acquires incident information, a countermeasure confirmation unit that confirms countermeasures for the incident information acquired by the incident information acquisition unit, an update equipment determination unit that determines updated equipment of the elevator that requires incident countermeasures based on the countermeasures confirmed by the countermeasure confirmation unit, and an update timing setting unit that sets the timing for implementing incident countermeasures for the updated equipment based on the configuration information and operating status of the elevator. [Effects of the Invention]

[0008] According to the present invention, when an incident occurs in an elevator system, the parts related to the incident are extracted, corrective measures for the determined parts are determined, and the timing for applying the incident countermeasures can be determined based on the configuration information and operating status of the relevant elevator. Problems, configurations, and effects other than those described above will become apparent from the following description of the embodiments. [Brief explanation of the drawings]

[0009] [Figure 1] 1 is a diagram showing an example of the overall configuration of an elevator system according to an embodiment of the present invention. [Figure 2] FIG. 2 is a block diagram showing an example of the hardware configuration of a controller provided in the elevator system according to the embodiment of the present invention. [Figure 3] FIG. 2 is a diagram illustrating an example of a software configuration implemented in an elevator system according to an embodiment of the present invention. [Figure 4] 1 is a block diagram showing a functional configuration of an elevator system according to an embodiment of the present invention. [Figure 5] FIG. 10 is a diagram showing an example of incident information according to an embodiment of the present invention. [Figure 6] FIG. 2 is a diagram showing an example of a security database according to an embodiment of the present invention. [Figure 7] FIG. 10 is a diagram showing an example of a shipping product database according to an embodiment of the present invention. [Figure 8] 10 is a flowchart illustrating an example of an incident response process according to an embodiment of the present invention. [Figure 9] 10 is a flowchart illustrating an example of a category extraction process according to an embodiment of the present invention. [Figure 10] FIG. 10 is a diagram illustrating an example of an incident response state according to an embodiment of the present invention. [Figure 11] 10 is a flowchart illustrating an example of correspondence confirmation processing according to an embodiment of the present invention. [Figure 12] 10 is a flowchart illustrating an example of a device update determination process according to an embodiment of the present invention. [Figure 13] 10 is a flowchart illustrating an example of an update timing setting process according to an embodiment of the present invention. [Figure 14]FIG. 10 is a diagram showing an example of an update condition table according to an embodiment of the present invention. [Figure 15] 10 is a flowchart illustrating an example of a correction confirmation process according to an embodiment of the present invention. [Figure 16] FIG. 10 is a diagram showing an example of a correction confirmation state according to an embodiment of the present invention. [Figure 17] 4 is a flowchart showing an example of operation control processing (during normal operation) according to an embodiment of the present invention. [Figure 18] 4 is a flowchart showing an example of operation control processing (an example of processing when stopped late at night) according to an embodiment of the present invention. [Figure 19] 5 is a flowchart showing an example of operation control processing (when a date and time is specified) according to an embodiment of the present invention. [Figure 20] 10 is a flowchart showing an example of operation control processing (an example of processing at a specified date and time) according to an embodiment of the present invention. [Figure 21] FIG. 10 is a block diagram showing a functional configuration of an elevator control system according to a modified example of an embodiment of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0010] An elevator system and an elevator control method according to an embodiment of the present invention (hereinafter referred to as "this example") will be described below with reference to the accompanying drawings. In this example, an elevator system applied to an elevator will be described as an example of an elevator.

[0011] [Example of overall elevator system configuration] Fig. 1 shows an example of the configuration of the elevator system of this example. In the example of Fig. 1, for the sake of simplicity, the configuration of one elevator 15 is shown, but multiple elevators 15 (multiple units) are installed. The elevator 15 is operated under the control of a group management controller 4 and an elevator controller 5 that constitute an elevator system. That is, the elevator controller 5 controls the motor 6 to control the movement of the rope 9 connecting the car 7 and the counterweight 8. The elevator controller 5 then realizes the up and down movement and stopping of the car 7, providing up and down movement services to users.

[0012] Furthermore, the elevator controller 5 is connected to one car controller 10 and multiple floor controllers 11 via a communication path 12. The communication path 12 is a 1-to-N or N-to-N (N is any integer) multi-drop communication device. The car controller 10 is connected to an operation panel 13 that manages the destination floor buttons and door open / close buttons installed inside the car 7. The car controller 10 monitors the operation status of the buttons by the user and reports the operation status to the elevator controller 5. The floor controller 11 also includes a destination floor reservation system that allows users to pre-register any major instead of the up and down buttons 14.

[0013] The group management controller 4 is connected to a plurality of elevator controllers 5 via a communication path 16. The communication path 16 is a 1:N multi-drop type communication device. A plurality of elevators 15 are grouped together as an elevator group 18, which is a controller that manages the operation.

[0014] The center 1 is connected to a communication controller 3 via a communication path 2. As the communication path 2, for example, a mobile closed circuit network such as a dedicated line or a public line such as the Internet is used. The communication controller 3 is a controller that handles communications between the center 1 and the elevator to send and receive data and to perform remote maintenance and remote operation. Some buildings require multiple elevator groups 18, so the communication controller 3 is connected to multiple group management controllers 14 via communication paths 17. The communication paths 17 are 1-to-N multi-drop communication devices.

[0015] The elevator system of this example also includes a maintenance terminal 20 for performing maintenance work on the controllers 3, 4, and 5 and the communication paths 12, 16, and 17. By connecting this maintenance terminal 20 to a maintenance port mounted on the board of the group management controller 4 and to the communication paths 12, 16, and 17, it is possible to operate the objects to be maintained. Furthermore, a management terminal 19 is connected to the communication path 17. The management terminal 19 is installed, for example, in the management department of a building in which an elevator system is installed, and manages the operation status of the elevators.

[0016] [Controller hardware configuration] FIG. 2 shows an example of the hardware configuration of each of the controllers 3, 4, 5, 10, and 11 shown in FIG. That is, the communication controller 3, the group management controller 4, the elevator controller 5, the car controller 10, and the floor controller 11 are configured as a calculator (computer). In FIG. 2, these are collectively referred to as a controller 30.

[0017] The controller 30 includes an MPU (Micro Processing Unit) 31, also known as a microcomputer, a ROM (Read Only Memory) 32, a RAM (Random Access Memory) 33, and a communication I / F 34, all of which are connected to a system bus 35. There is also an MCU (Micro Control Unit), which is similar to an MPU. A higher-level concept of an MCU and an MPU is a CPU (Central Processing Unit). Firmware 40, which is a binary image of program code that realizes each function of this example, is recorded in ROM 32. MPU 31 reads firmware 40 from ROM 32 and loads it into RAM 33, and the loaded program code is executed. Alternatively, firmware 40 may read the program code directly from ROM 32 and execute the program code as is. Variables, parameters, etc. that are generated during the execution of processing in the MPU 31 are temporarily written to the RAM 33, and these variables, parameters, etc. are read out from the MPU 31 as appropriate.

[0018] When a non-volatile RAM such as a non-volatile random access memory (NVRAM) is used as the RAM 33, data may be stored in the RAM 33. The controllers 30 use the communication interface 34 to send and receive data via a communication path (network) connecting the controllers together. As a communication path, for example, a multi-drop serial communication device such as RS-485 can be applied. Also, a LAN (Local Area Network) or WAN (Wide Area Network), which are wired communication paths that provide multiple topologies such as Ethernet (registered trademark), can also be applied as a communication path. Alternatively, a wireless communication path such as a RAN (Radio Area Network) or Wi-Fi (registered trademark), or an infrastructure wireless communication path can also be applied as a communication path. The network configuration using the communication paths described here is an example, and various network configurations can be applied to the system of this example.

[0019] [Software configuration] FIG. 3 shows the configuration of firmware 40, which is software implemented in the controller 30 that constitutes the elevator system. The firmware 40 is broadly composed of a program 41 for the elevator controller 5 that controls the operation of the elevator 15, and an operating system 42 (OS) that manages and controls the hardware of the controller 30. It also comprises various libraries 43 used by the program 41, and device drivers 44 that allow the OS 42 to control any device.

[0020] The elevator control program 41 is composed of a standard program 45 for controlling the elevator 15, an option program 46 for option control, and an order program 47 for responding to different specifications for each shipped product. The elevator 15 standard program 45 is broadly classified into an operation control program 48 and a safety control program 49. These programs are modularized and subdivided according to the control content, etc. Managing the combination of these subdivided modules is called configuration management. In addition, a ROM monitor or simple task management may be used instead of an OS.

[0021] FIG. 4 shows the functional configuration of the elevator system from the viewpoint of the processing performed by the elevator system. The elevator 15 generates information related to a malfunction occurring in the equipment as incident information 50. The incident information acquisition unit 59 acquires the generated incident information 50. The incident information 50 includes at least information such as an error code determined when the firmware 40 of the controller 30 is designed, and the time when the malfunction occurred. The incident information 50 may also be created by a related party 51 such as a manager or maintenance staff member of the elevator 15 or a user of the elevator 15. The incident information 50 will be described in detail in FIG. 5.

[0022] The security database 60 is made up of a vulnerability information database 64 , a countermeasure information database 66 , and a security incident information database 62 . The vulnerability information database 64 manages vulnerability information 68 . The countermeasure information database 66 manages information related to countermeasures against vulnerabilities. The security incident information database 62 manages the relationship between vulnerabilities and countermeasures corresponding to the firmware 40, which is a collection of hardware and software of the controller 30 that constitutes the elevator 15.

[0023] Vulnerability information 68 includes two types: public information managed by a system such as CVSS (Common Vulnerability Scoring System), and private information specific to elevators 15. Vulnerability information 68 may also include a score indicating the severity of the vulnerability. The countermeasure information 66 includes information on correction codes, so-called patch codes, for reducing or eliminating the problem. If there is no patch code, the countermeasure information 66 may include, for example, workarounds and workaround procedures.

[0024] The shipped product database 70 is composed of an operation information database 72, a configuration information database 74, and a countermeasure schedule database 76. The operation information database 72 manages the operation status corresponding to the elevator 15 and the operation information transmitted from the elevator 15. The configuration information database 74 manages each of the components that make up the firmware 40, as explained with reference to FIG. The countermeasure schedule database 76 manages a schedule for implementing countermeasures corresponding to the incident information 50 in accordance with the operation information of each elevator 15 . Note that configuration management may also be performed for each piece of hardware that makes up the elevator system. The shipped product database 70 will be described in detail with reference to FIG.

[0025] The category extraction unit 52 extracts the incident information 50 . The countermeasure confirmation unit 54 extracts security incident information 62 from a security database 60 corresponding to the extracted hardware or software part. The security incident information 62 is also referred to as a security incident information database 62. For other information, the same symbols may be used for the database and the information. The security incident information 62 extracted from the security incident information database 62 is managed in the security database 60 in association with the vulnerability information 68 in the corresponding vulnerability information database 64 and the countermeasure information 66 in the countermeasure information database 66 that reduces or eliminates the vulnerability indicated by the vulnerability information 68.

[0026] The update device determination unit 56 determines a product corresponding to the product number from the configuration information database 74 of the shipped product database 70, which manages information on each individual product number. The processing performed by the update device determination unit 56 will be described with reference to FIG. 12. The update timing setting unit 58 sets the timing for applying countermeasures against vulnerabilities according to preset conditions. The processing by the update timing setting unit 58 will be described with reference to FIGS.

[0027] With the above configuration, security-related information is managed in the security database 60. Information related to shipped products is managed in the shipped product database 70. In this example, security information and shipped product information are managed in conjunction with each other, allowing appropriate security measures to be taken. In other words, by utilizing different information, such as shipped products with different internal configurations and shipped products with the same internal configuration but different operating conditions, elevator 15 can implement appropriate security measures for each elevator 15 at the appropriate time.

[0028] [Incident Information] FIG. 5 shows incident information 50 when a malfunction occurs. The incident information 50 is composed of a serial number 151 for organizing the occurrence of the malfunction, a product number 152 assigned to the elevator 15 and the internal controller, an error code 153 issued by the elevator system, an elevator status 154, and a category 155 indicating the location of the malfunction. The serial number 151 is a number issued when the incident information 50 arrives at the center 1.

[0029] The categories 155 are divided into a controller category 200 and a configuration category 210 within the controller. The controller category 200 is divided into communication 201 corresponding to the communication controller 3, group management 202 corresponding to the group management controller 4, elevator 203 corresponding to the elevator 15, car 204 corresponding to the car controller 10, and floor 205 corresponding to the floor controller 11. The configuration category 210 is classified into 211 corresponding to the operation control program 48, safety control 212 corresponding to safety control, option 213 corresponding to the option, order 214 corresponding to the order, OS 215 corresponding to the OS, library 216 corresponding to the library, and device driver 127 corresponding to the device driver. All of this information is contained within the firmware 40.

[0030] By configuring the incident information 50 in this way, it is possible to aggregate information related to the elevator 15 that is necessary for investigating the cause of the malfunction, and it is also possible to associate it with the security incident information described below. The relationship between the error code 153 and the category 155 is managed in the security incident information database 62 described below. The incident information 50 may be generated by the elevator 15 or may be issued by a person associated with the elevator 51, such as a maintenance worker or a user. When the elevator 15 is operating independently, there is no connection to the center 1, and therefore the incident information 50 is issued by the latter person associated with the elevator 51.

[0031] [Security Database Configuration] FIG. 6 shows the structure of the security database 60. The vulnerability information database 64 in the security database 60 contains at least individual vulnerability numbers 80, category information 155 related to the vulnerability, and patches or workarounds / mitigation measures 81 that are countermeasures against the vulnerability. An example of the vulnerability number 80 is the CVE (Common Vulnerabilities and Exposures) (registered trademark) number managed by CVSS. It may also be a unique management number used by a product development department. A patch is code that fixes a vulnerability. Even if a vulnerability is recognized, a patch / workaround / mitigation 81 may not have been created. Patches / workarounds / mitigations 81 may be updated or regressed depending on the content of the countermeasure, and a version number corresponding to these changes is generally assigned.

[0032] The security incident information 62 in the database 60 includes at least a security incident number 82, an error code 153 output by the firmware 40, an elevator system status 154 associated with the error code 153, a category 154 related to the error code 153, and a countermeasure number 86 corresponding to the incident. The countermeasure information database 66 includes at least a countermeasure number 86, a vulnerability number 80, and a countermeasure history 89.

[0033] By configuring the security database 60 in this way, it becomes possible to unify and manage vulnerabilities and countermeasures, and the relationship between error codes and elevator system status as incidents using countermeasure information.

[0034] [Shipping product database configuration] FIG. 7 shows the configuration of the shipping product database 70. The shipping product database 70 is a database that manages product information 90 associated with each elevator. The operation information database 72 stores and manages dynamic information of the elevator 15, such as the current operation / stop status, car position, stopping floor number, number of people in the car, car door open / close status, etc. as operation information 100. The operation information database 72 also stores the number of times 101 that various control programs constituting the firmware 40 operate within a given period of time, and frequency information 102 of the control programs, such as high frequency / low frequency / unused, based on a predetermined standard.

[0035] The configuration information database 74 stores and manages various configuration information 110 of the elevator 15 for each shipped product. For example, the configuration information database 74 manages the configuration and version information 111 of the standard program 45 common to the programs of the elevator 15. It also manages the internal configuration and version information 112 of the operation control program 48. The configuration information database 74 also manages the internal configuration and version information 113 of the safety control program 49 . The configuration information database 74 also manages the configuration and version information 114 of the library 43 used by the program 41 of the elevator 15 . The configuration information database 74 also manages the internal configuration and version information 115 of the OS 42. It also manages the configuration and version information 116 of the device drivers 44 corresponding to the devices controlled by the OS 42.

[0036] The configuration information database 74 also manages order information 117 corresponding to the requests of each customer and option information 118 indicating the functions selected from the optional functions. Although a version number is assigned to each component in this example, this is not a limitation. For example, a version number may be assigned to the OS 42, library 43, and device driver 44 collectively. The countermeasure schedule database 76 stores and manages the countermeasure schedule information 120, which includes the timing 121 of vulnerability countermeasures for shipped products and the countermeasure implementation history 128. The countermeasure timing 121 can be either immediate 122, at the time of regular inspection 123, postponed to an arbitrary date and time 124, waiting if no countermeasure is available 126, or completed 127. Note that "immediately" 122 does not mean stopping elevator 15 immediately, but rather ensuring time to take measures safely while minimizing the impact on elevator 15 operation. The history 128 may be implemented as a list consisting of the date and time when the countermeasure was implemented and the version of the patch / avoidance / mitigation 81.

[0037] In this way, the shipped product database 70 makes it possible to grasp the operational status of the elevator 15 and manage the components that may cause security incidents, thereby making it possible to manage the scheduling and history of implementing countermeasures according to the operational status specific to the elevator.

[0038] [Incident response processing] 8 and 9 are flowcharts showing examples of response processing when a malfunction occurs. The examples in Fig. 8 and 9 are examples of processing when the incident is a known security incident and a countermeasure exists. 8, the center 1 receives the incident information 50 (step S10). Next, the category extraction unit 52 extracts the category information 155 from the incident information 50 (step S11). Then, the countermeasure confirmation unit 54 searches the security incident information database 62 for security incident information corresponding to the error code 153, the state information 154, and the category information 155 of the incident information 50 (step S12). The countermeasure confirmation unit 54 checks whether or not there is an incident through the search in step S12 (step S13).

[0039] If there is corresponding security incident information in step S13 (YES in step S13), the update device determination unit 56 determines the target elevator 15 (step S13). Then, the update time setting unit 58 determines the update time according to each target elevator 15 (step S14).

[0040] Furthermore, if there is no corresponding security incident information in step S13 (NO in step S13), the update device determination unit 56 registers the security incident information in the security incident information database 62 (step S15). In this case, the update device determination unit 56 assigns a new vulnerability number 80 and updates the vulnerability information database 64 with the patch / workaround / mitigation measures 81 left empty. Thereafter, in step S14, the update time setting unit 58 determines the update time according to each of the target elevators 15.

[0041] FIG. 9 shows the processing of the category extraction unit 52. The category extraction unit 52 searches the security incident information database 62 for the error code 153 written in the incident information 50 (step S16), and determines whether or not the error code 153 is present (step S17). If there is an error code 153 in step S17 (YES in step S17), the category extraction unit 52 searches for a category 155 having the error code 153 (step S18) and determines whether or not there is a category 155 (step S19).

[0042] If category 155 exists in step S19 (YES in step S19), category extraction unit 52 extracts and stores category 153 (step S20). If there is no category 155 in step S19 (NO in step S19), the category extraction unit 52 ends the extraction of categories. Also, if the error code 153 is not listed in the incident information 50 in step S17 (NO in step S17), or if the error code 153 does not exist even after searching, the category extraction unit 52 stores the category 154 listed in the incident information 50 (step S21) and terminates the extraction process.

[0043] By using this incident response flow, when a security incident occurs, the category extraction unit 52 can respond by classifying the vulnerability into three cases: a known vulnerability for which a countermeasure is available, a known vulnerability for which a countermeasure is not available, and an unknown vulnerability.

[0044] [Incident response example (known: fix available)] Figure 10 shows an example of incident response when a malfunction occurs and there is a solution available. The example in Fig. 10 shows a case where there are three elevators 15, namely, elevators A, B, and C. In Fig. 10, a, b, and c after the reference symbols indicate information on elevators A, B, and C, respectively.

[0045] FIG. 10A shows a state in which the update time has been set. The frequency information 102 of each elevator 15 in the operation information database 72 is set to high frequency 102a, unused 102b, and low frequency 102c. Here, for example, it is assumed that the correspondence between the frequency information 102 and the update timing 121 is set in advance. The countermeasure timing information 121 for each elevator 15 in the countermeasure schedule database 76 is set to immediate 121a, postponement 121b, and regular inspection 121c. According to such countermeasure timing information 121, immediate 121 implementation of countermeasures on Unit A is the fastest.

[0046] Figure 10B shows the state of Unit A at the time when the immediate 121a measure was applied. Since the countermeasure application was immediately implemented for Unit A, the countermeasure timing information 121a becomes "Done" 126a. As the countermeasure implementation history information 128a, "Immediate" 122a is recorded. Countermeasure timing information 121 for machine B maintains postponement 124b. Also, since countermeasures have not been implemented, history information 128b is empty (-). Similarly, the countermeasure timing information 121c for Unit C maintains the periodic inspection 123c. Also, since no countermeasures have been implemented, the history information 128c is empty (-).

[0047] FIG. 10C shows the situation when the same security incident occurs (recurs). Since this is the state after immediate application, the countermeasure timing information 121 for each elevator 15 is "Completed" 127a for Unit A, "Postponed" 124b for Unit B, and "Regular Inspection" 123c for Unit C. Therefore, in order to apply countermeasures to elevators 15 to which countermeasures have not been applied, the countermeasure timing information 121b of elevator B is reset to immediate 122b. Similarly, the countermeasure timing information 121c of elevator C is reset to immediate 126c.

[0048] [Countermeasure confirmation process] FIG. 11 is a flowchart showing a process for checking whether or not there is a solution when a problem occurs. First, the countermeasure confirmation unit 54 searches the security incident information database 62 for security incident information corresponding to the category 155 and the error code 153 (step S30), and determines whether or not there are any search results (step S31). If the search result exists in step S31 (YES in step S31), the countermeasure confirmation unit 54 searches the countermeasure information database 66 based on the countermeasure number 86 of the search result (step S32) and determines whether or not there is countermeasure information (step S33).If the countermeasure information exists in step S33 (YES in step S33), the countermeasure confirmation unit 54 searches the vulnerability information database 64 based on the vulnerability number 80 of the search result (step S34) and determines whether or not there is vulnerability information (step S35).

[0049] If vulnerability information is found in step S35 (YES in step S35), the countermeasure confirmation unit 54 compares the original category 154 with the search result category 154 (step S36) and determines whether they match (step S37). If the comparison result in step S37 shows a match (YES in step S37), the countermeasure confirmation unit 54 checks whether a patch / avoidance / mitigation measure 81 is saved (step S38). If there is no information or no match in steps S31, S33, S35, and S37 (NO in steps S31, S33, S35, and S37), the countermeasure confirmation unit 54 ends the countermeasure confirmation process.

[0050] By performing this countermeasure confirmation process, when a security incident occurs, the countermeasure confirmation unit 54 can confirm the vulnerability information corresponding to the security incident and whether or not countermeasures have been taken for that information.

[0051] [Update device determination process] FIG. 12 is a flowchart showing the process of determining a device to be updated by applying a countermeasure when a problem occurs. First, the update equipment determination unit 56 searches the configuration information database 74 for an elevator 15 and an internal controller with product number 52 that is configuration information 110 that matches the configuration category 210 of the incident information 50 (step S40), and determines whether or not they exist (step S41). If it is determined in step S41 that there is a search result (YES in step S41), the update device determination unit 56 stores the corresponding product number 52 in, for example, a search result list (step S42). If it is determined in step S41 that there is no search result (NO in step S41), the update device determination process ends.

[0052] By executing such an update device determination process, when a security incident occurs, the update device determination unit 56 can extract the shipped product related to the security incident.

[0053] [Update time setting process] The flowchart in FIG. 13 and the update condition table in FIG. 14 show the process of determining the update timing of the update target device selected in the eleventh embodiment when a malfunction occurs. When a device is determined in the process shown in FIG. 12, the update time setting unit 58 searches for update conditions from the update condition table 130 (FIG. 14) according to the category of the corresponding device (step S50).

[0054] 14, conditions are set for each category in the update table 130. Update conditions are set for each of options 137, orders 138, operation control 132, safety control 131, library 134, OS 135, and device driver 136. The options 137, orders 138, operation control 132, and safety control 131 are independently developed, and conditions are evaluated according to predetermined error codes, frequency thresholds, and number thresholds.

[0055] Additionally, a category that requires immediate countermeasures for a function is designated as immediate. In this example, safety control 131, which is related to safety, is designated as immediate. Since the library 134, OS 135, and device driver 136 may be commercially available products or may be developed by a third party such as open source, the severity information from the CVE mentioned above can be used. In this case, condition evaluation based on severity in addition to frequency threshold and number threshold is possible.

[0056] 13, the update timing setting unit 58 evaluates the update conditions that are the search results (step S51). Then, the update timing setting unit 58 updates the countermeasure schedule database 76 based on the evaluation result (step S52).

[0057] Note that when the system of this example is operated by the elevator 15 alone, it is not connected to the center 1, and therefore the update time setting unit 58 cannot check the operation status. In this case, the update time setting unit 58 determines the update time using a separate update condition table 140. The update condition table 140 indicates any component of the elevator 15 by combining the controller category 200 and the configuration category 210 described in FIG. 5. The update condition table 140 then selects a predetermined update time, for example, immediate or regular inspection, in accordance with the error code 53 associated with the component. In the elevator system of this example, the condition settings described so far are merely examples, and other setting conditions may be used. In other words, it is preferable to set the update timing according to the operating status of the equipment to be updated, the importance of the equipment to be updated, and the seriousness of the incident, but depending on the conditions, any of these requirements may be omitted. In this way, by combining the category of the elevator 15's components and the error code assigned to the components, it is possible to set the update timing according to the configuration and operating status of each elevator 15.

[0058] [Correction confirmation process] FIG. 15 is a flowchart showing an example of processing when the creation of countermeasures against vulnerabilities according to the present invention is completed. The countermeasure confirmation unit 54 registers the created countermeasure, that is, the patch / workaround / mitigation measure 81, in the vulnerability information database 64 and updates the database (step S60). Then, the countermeasure confirmation unit 54 searches the countermeasure information database 66 for the countermeasure number 86 corresponding to the updated vulnerability number 80 (step S61).

[0059] Furthermore, the countermeasure confirmation unit 54 searches the countermeasure schedule database 76 for countermeasure schedule information 120 corresponding to the countermeasure number 86 (step S62), and determines whether or not it exists (step S63). If there is a search result in step S63 (YES in step S63), the countermeasure confirmation unit 54 confirms that the countermeasure timing 121 of the countermeasure schedule information 120 is standby (step S64). Then, the update time setting unit 58 performs the update time setting process already explained, resets the update time (step S65), and returns to the countermeasure schedule number search in step S62. Furthermore, if there is no search result in step S63 (NO in step S63), the countermeasure confirmation unit 54 ends the correction confirmation process.

[0060] By executing such a correction confirmation process, the update timing setting unit 58 can reset the update timing for cases that have been put on hold because no countermeasures for vulnerabilities exist, according to the configuration and operating status of each elevator, once the countermeasures have been created.

[0061] [Edit confirmation status] Figure 16 shows an example of the correction confirmation state. Similar to the example in Figure 10, the example in Figure 16 shows a case where there are three elevators 15, A, B, and C, and the a, b, and c after the symbols indicate information about A, B, and C, respectively. FIG. 16A shows a state in which a countermeasure against a certain vulnerability has not yet been decided. The frequency information 102 of each elevator 15 in the operation information database 72 is high frequency 102a, unused 102b, and unused 102c. The countermeasure timing information 121 of each elevator 15 in the countermeasure schedule database 76 is standby 126 because there is no countermeasure.

[0062] FIG. 16B shows the updated state of the countermeasure schedule when the countermeasure has been finalized. The frequency information 102 for each elevator 15 in the operation information database 72 is high frequency 102c, unused 102b, and low frequency 102c, and elevator 15 of elevator C is an example that changed from unused to low frequency 102c due to the operation of the vulnerable target during the period until the countermeasures were completed. As a result, the countermeasure timing 121 becomes immediate 121a, postponed 121b, and regular inspection 121c. In this way, when the creation of countermeasures against vulnerabilities is completed, the countermeasure schedule database 76 can be updated promptly.

[0063] [Example of traffic control] Next, the process of adjusting the operation control of the elevator 15 based on the countermeasure schedule information 120 will be described with reference to Figs. 17 to 20. This process of adjusting the operation control of the elevator 15 is executed, for example, by the group management controller 4 based on the countermeasure schedule information 120 created on the center 1 side. Instead of the group management controller 4, the process may be executed by an individual elevator controller 5.

[0064] FIG. 17 is a flowchart showing an example of a case where an update is performed immediately. The example of FIG. 17 shows a process for quickly applying a countermeasure when the countermeasure timing 121 in the countermeasure schedule information 120 is set to immediate 122. First, the group management controller 4 executes operation prediction for the target elevator 15 (step S70). Then, the group management controller 4 secures an update time for applying a patch 81 as a countermeasure based on the prediction result of operation in the near future (step S71). For example, the group management controller 4 reserves an update time slot from a time slot predicted to have few elevators 15 in operation or when the elevators 15 are stopped. The update time for applying the patch 81 includes the time required to download the patch 81 and the time required to reflect the patch 81 in the firmware 40. Then, the group management controller 4 determines whether or not the time for taking measures has been secured (step S72).

[0065] If the update time is secured in step S72 (YES in step S72), the group management controller 4 or the elevator controller 5 downloads a patch 81 as a countermeasure (step S73). The elevator 15 temporarily suspends operation when the update time period arrives (step S74). Then, the group management controller 4 or the elevator controller 5 applies the downloaded countermeasure (step S75). The elevator 15 resumes operation after the countermeasure is completed (step S76).

[0066] Furthermore, if the update time cannot be secured in step S72 (NO in step S72), the group management controller 4 determines whether the number of retries is within a preset number and whether retries are permitted (step S77). If the number of retries is within the permitted number in step S77 ("permitted" in step S77), the group management controller 4 waits for a preset time (step S78), and the group management controller 4 returns to the processing of step S70.

[0067] In step S77, if the number of retries exceeds the permitted number ("exceeded" in step S77), the group management controller 4 changes the setting to postponement and ends the processing (step S79). In this case, the setting is postponed to late night, for example.

[0068] By performing such processing, when Immediate 122 is set, the group management controller 4 can implement countermeasures against vulnerabilities that minimize the impact on the operation of the elevator 15. Furthermore, if it is not possible to secure time for the update during normal operation, the group management controller 4 can deal with situations in which it is not possible to perform the update during the day by postponing it to late at night when operation is essentially stopped.

[0069] FIG. 18 is a flowchart showing an example of a case where the update is performed at a set time (here, late at night). The group management controller 4 downloads a patch 81 as a countermeasure at a preset late-night time period (step S80). Then, the group controller 4 checks the stopped state of the elevators 15 (step S81) and determines whether or not the elevators 15 are stopped (step S82).

[0070] When it is determined in step S82 that the elevator is stopped (YES in step S82), the group management controller 4 applies the patch 81 downloaded in step S80 (step S84). When the application of the countermeasure is completed, the group management controller 4 resumes the operation of the corresponding elevator 15 (step S85). Furthermore, when it is determined in step S82 that the device is in operation (NO in step S82), the group management controller 4 waits for a preset time (step S83) and repeats the process from step S81.

[0071] FIG. 19 is a flowchart showing an example of a case where an update is performed by specifying a date and time. First, the center 1 specifies the date and time for applying the countermeasures (step S90). This date and time for applying the countermeasures may be remotely set from the management terminal 19. When the date and time for applying the countermeasure is set, the group management controller 4 reserves and secures the corresponding date and time as the update work time in the operation process (step S91), and determines whether the reservation was successful (step S92). If the reservation is successful in step S92 (YES in step S92), the group management controller 4 or the elevator controller 5 downloads the patch 81 as a countermeasure (step S93). Furthermore, if the securing is not successful in step S92 (NO in step S92), the group management controller 4 updates the countermeasure schedule as a regular inspection (step S94).

[0072] In this way, when the secured date and time arrives, the group management controller 4 temporarily suspends the operation of the elevators 15 (step S95) and applies the patch 81 (step S96). Then, when the application of the countermeasures is completed, the group management controller 4 resumes the operation of the elevators 15 (step S96). By performing such an update timing adjustment process, even if immediate application is not possible, it is possible to ensure application during late night hours instead. Also, even if the desired date and time cannot be secured, it is possible to ensure application during regular inspection instead. During regular inspection, countermeasures are implemented by maintenance personnel using the maintenance terminal 20.

[0073] [Variations] The embodiment examples described so far have been described in detail to clearly explain the present invention, and are not necessarily limited to those having all of the configurations described.

[0074] For example, the vulnerability-related target inference process may be performed by applying generation AI (Artificial Intelligence). An example of the configuration for this case is shown in Fig. 21. In Fig. 21, the category extraction unit 52 and the countermeasure confirmation unit 54 in the configuration of the elevator system shown in Fig. 4 are replaced with a security countermeasure generation AI execution unit 200.

[0075] To explain the configuration in Figure 21, the security countermeasure generation AI execution unit 200 takes vulnerability information 64, security incident information 62, and countermeasure information 66 managed by the security database 60, and configuration information 74 managed by the shipped product database 70 as input, and accumulates the learning results in the large-scale language model 210, thereby making it possible to learn the association between incidents and vulnerabilities. By using the trained large-scale language model 210, the security countermeasure generation AI execution unit 200 receives incident information 50 that has occurred as input and generates information related to security incident information 62 that corresponds to the incident.

[0076] In addition, by learning the operation information 72 of each elevator 15 managed by the shipped product database 70 as input to the security measures generation AI execution unit 200, it is also possible to generate the update time according to the operation status, which corresponds to the update time setting unit 58. Based on the information generated by the security countermeasure generation AI execution unit 200, the update device determination unit 56 determines the devices to be updated, as in Figure 4, and the update time setting unit 58 sets the update time according to the configuration and operation information of each device to be updated.

[0077] In this way, the security countermeasure generation AI execution unit 200 accumulates the learning results in the large-scale language model 210, making it possible to automatically and appropriately determine vulnerabilities and countermeasure methods corresponding to the incident information 50 that has occurred.

[0078] Furthermore, although the above-described embodiment is applied to an elevator system, the present invention can also be applied to systems for elevators other than elevators.

[0079] In addition, in the configuration diagrams shown in Figures 1, 2, 4, 21, etc., only control lines and information lines that are considered necessary for explanation are shown, and not all control lines and information lines in the product are necessarily shown. In reality, it can be assumed that almost all components are interconnected. In addition, the processing flows shown in the flowcharts in Figures 8, 9, 11, 12, 13, 15, 17, 18, 19, and 20 are also examples, and as long as the processing results are the same, the order of some of the processing may be changed or multiple processes may be executed simultaneously. In addition, in the above-described embodiment, the system shown in FIG. 4 is configured by executing a program configured as shown in FIG. 3. However, in this case, the program may be stored in a storage device within the computer system, or may be stored in an external memory, an IC card, an SD card, an optical disk, or other recording medium and transferred. [Explanation of symbols]

[0080] 1...Center, 2...Communication path, 3...Communication controller, 4...Group management controller, 5...Elevator controller, 6...Motor, 8...Counterweight, 9...Rope, 10...Controller, 11...Floor controller, 12...Communication path, 13...Error code, 13...Operation panel, 14...Group management controller, 14...Up / down buttons, 15...Elevator, 16, 17...Communication path, 18...Elevator group, 19...Management terminal, 20...Maintenance terminal, 30...Controller, 31...MPU, 32...ROM, 33...RAM, 34...Communication interface, 35...System bus, 40...Firmware, 41...Program, 42...Operating system, 43...Library, 44...Device driver, 45...Standard program, 46...Optional program, 47...Order program, 48...Operation control program, 49...Safety control program, 50...Incident information, 52...Category extraction unit, 54...Countermeasure confirmation unit, 56...Update device determination unit, 58...Update time setting unit, 59...Incident information acquisition unit, 60...Security database, 62...Security incident information database (security incident information), 64...Vulnerability information database (vulnerability information), 66...Countermeasure information database (countermeasure information), 70...Shipping product database, 72...Operation information database, 74...Configuration information database, 76...Countermeasure schedule database, 78...Countermeasure schedule database, 200...Security countermeasure generation AI execution unit, 210...Large-scale language model

Claims

1. an incident information acquisition unit that acquires incident information about the elevator; a countermeasure confirmation unit that confirms a countermeasure for the incident information acquired by the incident information acquisition unit; an update device determination unit that determines an update device of an elevator that requires an incident countermeasure based on the countermeasure confirmed by the countermeasure confirmation unit; an update timing setting unit that sets the timing for implementing incident countermeasures for the updated device based on the configuration information and operating status of the elevator. Elevator system.

2. The update timing setting unit sets the timing for implementing an incident countermeasure in accordance with the operating status of the update device, the importance of the update device, and the seriousness of the incident. The elevator system of claim 1 .

3. The update timing setting unit sets the implementation timing of the incident countermeasure to either late night hours or at the time of regular inspection. The elevator system of claim 2 .

4. When the update timing setting unit sets the timing of implementing measures to immediate application, the unit controls the system of the elevator so as to ensure time for implementing the measures. The elevator system of claim 1 .

5. The countermeasure confirmation unit causes a large-scale language model to learn and accumulate information about the association between incidents and vulnerabilities, and performs analysis using the learned large-scale language model to infer vulnerability-related targets. The elevator system of claim 1 .

6. an incident information acquisition process for acquiring incident information; a countermeasure confirmation process for confirming a countermeasure for the incident information acquired by the incident information acquisition process; an update device determination process for determining an update device of the elevator that requires an incident countermeasure based on the countermeasure confirmed by the countermeasure confirmation process; and an update timing setting process for setting the timing for implementing incident countermeasures for the updated device based on the configuration information and operating status of the elevator. Elevator control method.

Images