Module information management system and module information management method

Abstract

This invention provides a module information management system and a module information management method, which can manage the information of multiple modules used in multiple processing units simultaneously. One embodiment of the module information management system includes: a terminal having a module version information storage unit (333) that stores version information of all module units (331) stored in the terminal, and a control unit (342) that reads version information of module units from the module version information storage unit (333) and sends it to an overall management unit (5); and an overall management unit having a version information database that manages version information of all module units (331) sent from multiple terminals.

Description

Technical Field

[0001] This invention relates to a module information management system and a module information management method. Background Technology

[0002] In recent years, the design of various processing units, such as those for elevators and other devices, has focused on combining multiple general-purpose modules that perform specific functions and can be applied to various processing units. This approach aims to achieve portability and scalability of modular software. Furthermore, various methods for managing information stored in such software across different terminals have been investigated.

[0003] For example, Patent Document 1 discloses a software query information management system that generates approved software query information, which is information that associates the regulatory ID corresponding to the equipment requirement specifications with the traceability information of the equipment installed in the vehicle, and information that associates one or more software IDs included in the traceability information. It also generates vehicle traceability information that associates the approved software query information with the traceability information.

[0004] Existing technical documents

[0005] Patent documents

[0006] Patent Document 1: Japanese Patent Application Publication No. 2021-196933 Summary of the Invention

[0007] The problem that the invention aims to solve

[0008] However, in the technology described in Patent Document 1, when the software constituting the function of the regulation is composed of a combination of multiple software programs, a software query number is assigned to the set of multiple software programs. Then, this software query number is managed in association with the regulation ID. That is, the technology described in Patent Document 1 does not consider the traceability of information regarding each software unit constituting the multiple software programs.

[0009] Therefore, in the case of updating the function of a module unit or correcting problems in a module when using a universal module in various processing units, it is difficult to investigate in which processing unit the object module was used in the technology described in Patent Document 1.

[0010] The present invention was derived with consideration of the above-mentioned situation, and the object of the present invention is to enable the management of information from multiple modules shared by multiple processing units in a unified manner.

[0011] Technical solutions for solving the problem

[0012] One aspect of the module information management system of the present invention includes multiple processing units having one or more module units that perform specific functions and can be shared among multiple processing units; and a management unit for managing information of the module units. The processing unit of one aspect of the module information management system of the present invention includes: a module version information storage unit that stores version information of all modules stored in the processing unit; and a first control unit that reads version information of module units from the module version information storage unit and sends it to the management unit, the management unit having a version information database for managing version information of all module units sent from the multiple processing units.

[0013] Invention Effects

[0014] According to at least one aspect of the present invention, information from multiple modules shared by multiple processing units can be managed simultaneously.

[0015] Other issues, structures, and effects not described above will become clear through the following description of the implementation methods. Attached Figure Description

[0016] Figure 1 This is a diagram illustrating a schematic structural example of a modular information management system according to one embodiment of the present invention.

[0017] Figure 2 This is a block diagram illustrating a structural example of a control system for a lobby terminal according to one embodiment of the present invention.

[0018] Figure 3 This is a block diagram illustrating an example of the hardware structure of a modular information management system comprising a lobby terminal, a SIM card control unit, and an overall management unit, according to one embodiment of the present invention.

[0019] Figure 4 This is a diagram illustrating an example of the structure of a version information storage unit within a module section of an embodiment of the present invention.

[0020] Figure 5 This is a diagram illustrating a structural example of a module version information storage unit within a peripheral device section according to an embodiment of the present invention.

[0021] Figure 6 This is a diagram illustrating an example of the structure of a version information storage unit for all processing units within a SIM card control unit according to one embodiment of the present invention.

[0022] Figure 7 This is a diagram illustrating an example of the structure of a version information database within the overall management unit of one embodiment of the present invention.

[0023] Figure 8 This is a diagram illustrating an example of the structure of the ROM database of the overall management unit according to one embodiment of the present invention.

[0024] Figure 9 This is a flowchart illustrating an example of the version read processing flow performed by the control unit of the overall management unit in one embodiment of the present invention.

[0025] Figure 10 This is a flowchart illustrating an example of the version reading process performed by the control unit of the SIM card control unit according to one embodiment of the present invention.

[0026] Figure 11 This is a flowchart illustrating an example of the version setting / version reading process in a lobby terminal according to one embodiment of the present invention.

[0027] Figure 12 This is a flowchart illustrating an example of the ROM data rewriting process performed by the overall management unit, the SIM card control unit, and the lobby terminal in one embodiment of the present invention. Detailed Implementation

[0028] Hereinafter, examples of methods for implementing the present invention (hereinafter referred to as "implementations") will be described with reference to the accompanying drawings. The present invention is not limited to these embodiments; the various values, etc., in the embodiments are merely examples. Furthermore, in this specification and the drawings, the same reference numerals are used for the same constituent elements or constituent elements that substantially have the same function, and repeated descriptions are omitted.

[0029] <Overview of the Module Information Management System>

[0030] First, refer to Figure 1 The structure of a module information management system according to one embodiment of the present invention will be described. Figure 1 This is a diagram illustrating a schematic structural example of a module information management system 100 according to one embodiment of the present invention.

[0031] like Figure 1 As shown, the modular information management system 100 includes a car section 1, an electric motor section 2, hall terminals 3_1 to 3_n (n is a natural number greater than 2), a first machine control section 4_1 to a third machine control section 4_3, and an overall management section 5.

[0032] The control units 4_1 to 4_3 of Unit 1 and the overall management unit 5 are connected via a network N, such as the public Internet.

[0033] The car section 1 is the elevator car that moves up and down in the shaft of a building (not shown).

[0034] The motor unit 2 consists of an electric motor (not shown) that drives the traction machine that raises and lowers the car unit 1.

[0035] The lobby terminals 3_1 to 3_n (an example of a processing unit) consist of lobby buttons 31 and indicators 32 (both referenced in the diagram) installed in the elevator lobby (illustration omitted). Figure 2 The lobby terminals 3_1 to 3_n are terminals consisting of a lobby terminal and a control system that controls them. In the following description, unless it is necessary to individually identify each lobby terminal 3_1 to 3_n, they will be collectively referred to as lobby terminal 3. For the structure of the control system for lobby terminal 3, please refer to the following... Figure 2 Detailed explanation.

[0036] Furthermore, this embodiment exemplifies the use of a lobby terminal 3 including a lobby button 31 and an indicator 32, but the invention is not limited thereto. The lobby terminal 3 may also include other terminals such as speakers and lights.

[0037] [Machine Control Department]

[0038] The first machine control unit 4_1 is a control device that controls the operation of the car unit 1, the motor unit 2, and the hall terminal 3. In this embodiment, an example is given where three machine control units are provided: the first machine control unit 4_1 to the third machine control unit 4_3; however, the present invention is not limited to this. The number of machine control units can be two or less, or four or more. In the following description, without needing to individually identify the first machine control unit 4_1 to the third machine control unit 4_3, they are collectively referred to as the machine control unit 4 (an example of a processing unit control unit).

[0039] The No. 1 control unit 4_1 includes a communication unit 41, an electric motor control unit 42, a car control unit 43, a hall terminal control unit 44, a communication unit 45, a ROM (Read Only Memory) data storage unit 46, a version information storage unit for all processing units 47, and a control unit 48.

[0040] The communication unit 41 controls the communication between the car unit 1, the motor unit 2, and the hall terminal 3.

[0041] The motor control unit 42 controls the operation of the motor unit 2.

[0042] The car control unit 43 controls the opening and closing of doors (not shown) in the car section 1, as well as the operation of various terminals (not shown) installed inside the car section 1 (hereinafter referred to as an example of a processing unit of "in-car terminals"). In-car terminals include, for example, destination floor buttons, door opening / closing buttons, display devices, speakers, and lights (all omitted from illustration).

[0043] The lobby terminal control unit 44 controls the operation of the lobby terminal 3.

[0044] The communication department 45 controls the communication between the overall management department 5 and the communication operation.

[0045] The ROM data storage unit 46 stores the module units 331 used in each terminal that are managed by the serial number control unit 4 (see reference). Figure 2 The ROM contains version-related information (version information) and data (program, hereinafter also referred to as ROM data) of each module 331. Module 331 is a module that implements IO (Input Output) functions, IND (Indicate) functions, etc. in the terminal. It is designed with a universal specification so that it can be used in different types of terminals.

[0046] The ROM data storage unit 46, for example, consists of two sides. The first side stores the ROM data (currently in use) before it is rewritten using the rewritten ROM data, and the second side stores the new version of the ROM data after it has been rewritten using the rewritten ROM data. Then, when the overall management unit 5 sends a ROM rewrite command, a process is performed to switch the side of the ROM data storage unit 46 from the first side to the second side. Regarding the structure of the ROM data stored in the ROM data storage unit 46, please refer to the description below. Figure 6 Detailed explanation.

[0047] The version information storage unit 47 stores version information for each module of each processing unit, including the lobby terminal 3, the car terminal, and the inverter terminal (not shown) of the motor control unit 2. For the structure of the version information storage unit 47, please refer to the description below. Figure 6 Detailed explanation.

[0048] Control unit 48 (an example of a third control unit) controls the operations of each unit constituting the machine control unit 4. Furthermore, when a version read command is sent from the overall management unit 5, control unit 48 sends a version read command to the lobby terminal 3. Then, control unit 48 updates the version information in the all-processing unit version information storage unit 47 using the version information of each module unit sent from the lobby terminal 3 based on this command. Thus, the version information in the all-processing unit version information storage unit 47 remains up-to-date. Furthermore, control unit 48 sends the version information of each module unit stored in the all-processing unit version information storage unit 47 to the overall management unit 5 via communication unit 45. For details regarding the processing performed by control unit 48, please refer to the following description. Figure 10 Detailed explanation.

[0049] [Overall Management Department]

[0050] The overall management unit 5 (an example of a management unit) is located, for example, in a monitoring center (not shown) at a remote location. It manages the version information of each module in each processing unit, such as the lobby terminal 3 and the car terminal, and performs version updates. Furthermore, based on the version information of each module in each processing unit, the overall management unit 5 controls the rewriting of the ROM data of the modules.

[0051] The overall management department 5 includes a version information database 51, a ROM database 52, a control department 53, and an operation department 54.

[0052] Version information database 51 stores version information for all modules in the processing unit, including the lobby terminal 3 and the in-car terminal. The structure of version information database 51 will be described later. Figure 7 Detailed explanation.

[0053] The ROM database 52 stores the ROM data of each module. For the structure of the ROM database 52, please refer to the following description. Figure 8 Detailed explanation.

[0054] The control unit 53 (an example of the second control unit) performs version read processing when the execution time for version read periodic processing arrives, or when the user inputs a version read command or ROM rewrite command via the operation unit 54.

[0055] Version read periodic processing is a process performed periodically to read the version information of each module in each terminal. For example, it is performed periodically during idle time when no one is riding in the elevator car 1, or during maintenance. Specifically, version read processing involves sending a version read command to the queuing machine control unit 4 and updating the version information database 51 with the version information received in response to that command. By updating the version information database 51 at such periodic times, the version information in the version information database 51 remains up-to-date.

[0056] The version read command is an instruction input by the user who wants to know the version information of each module through the operation unit 54.

[0057] A ROM rewrite command is an instruction that instructs the rewriting of the module's ROM data when updating the module's version for purposes such as updating or eliminating problems. ROM rewrite commands are also sent during idle times when no one is riding in the elevator car section 1, or when performing maintenance.

[0058] The operation unit 54 is composed of, for example, a mouse, keyboard or touch sensor, and generates operation signals corresponding to the operation content input by the user and outputs them to the control unit 53.

[0059] [Lobby Terminal]

[0060] Next, refer to Figure 2 The structure of the control system for the lobby terminal 3 will be explained. Figure 2 This is a block diagram illustrating an example of the structure of the control system for lobby terminal 3. Additionally, in Figure 2 The example shown is the lobby terminal 3 as a terminal (processing unit), but other terminals such as the car terminal also have the same structure.

[0061] The lobby terminal 3 includes a peripheral equipment unit 33 and an overall control unit 34.

[0062] The peripheral equipment section 33 includes module A section 331A, module B section 331B, communication section 332, module version information storage section 333, and ROM data storage section 334.

[0063] Module A 331A provides the input / output (IO) function for the lobby button 31, and Module B 331B provides the indicator (IND) function for the indicator 32. The control systems of Module A 331A and Module B 331B have the same structure; therefore, only Module A 331A will be used as an example for explanation. In the following description, without needing to individually identify Module A 331A and Module B 331B, they will be collectively referred to as Module 331.

[0064] In addition, Figure 2 The example given is a lobby terminal 3 having two modules: module A 331A providing input / output functions for lobby buttons 31 and module B 331B providing display functions for indicators 32. However, the present invention is not limited to this. The lobby terminal 3 may have one (type) of modules or more than three.

[0065] The module 331 includes a function unit (IO) 3311A, a parameter storage unit 3312A, and a version information storage unit 3313A.

[0066] The functional unit (IO) 3311A is the main body of the module that provides input / output functions for the lobby button 31. When the scheduled execution time for version setting processing arrives, the functional unit (IO) 3311A reads its own version information from the unillustrated memory and saves (sets) it in the version information storage unit 3313A. The version setting periodic processing is a periodic process used to save the latest version information in the version information storage unit 3313A, and it is performed periodically during idle time or when performing maintenance. By updating the information in the version information storage unit 3313A based on this periodically executed processing, the version information in the version information storage unit 3313A remains up-to-date.

[0067] In the parameter storage unit 3312A, the storage function unit (IO) 3311A provides various parameters used when performing IO functions.

[0068] The version information storage unit 3313A stores version information of the module units of the functional unit (IO). That is, in this embodiment, multiple types of module units are used in a single terminal. Figure 2 In the example shown, where module A (331A) and module B (331B) are involved, version information for each of the multiple module sections 331 is managed individually within each module section 331. Furthermore, for example, if the type of module section stored in the terminal is changed during system application, the version information stored in the version information storage unit 3313 is also updated to the changed information.

[0069] In the following description, since it is not necessary to individually identify functional units 3311A and 3311B, they are collectively referred to as functional unit 3311. Similarly, since it is not necessary to individually identify parameter storage units 3312A and 3312B, they are collectively referred to as parameter storage unit 3312, and since it is not necessary to individually identify version information storage units 3313A and 3313B, they are collectively referred to as version information storage unit 3313.

[0070] The communication unit 332 controls the communication between the communication unit 341 of the overall control unit 34.

[0071] In the module version information storage unit 333 (an example of a module version information storage unit), the version information of module A 331A and the version information of module B 331B are stored. That is, the module version information storage unit 333 registers the version information of multiple modules together. For the structure of the module version information storage unit 333, please refer to the description below. Figure 5 Detailed explanation.

[0072] The ROM data storage unit 334 stores the ROM data of module A 331A and module B 331B. Like the ROM data storage unit 46 of the serial number control unit 4, the ROM data storage unit 334 consists of two sides. ROM data is written to the second side; when a ROM rewrite command is received from the serial number control unit 4, the side of the ROM data storage unit 334 is switched from the first side to the second side.

[0073] The overall control unit 34 includes a communication unit 341 and a control unit 342.

[0074] The communication unit 341 controls the communication operations between itself and the unit control unit 4, and controls the communication operations between itself and the communication unit 332 of the peripheral equipment unit 33.

[0075] When performing version read periodic processing or receiving version read commands or ROM rewrite commands sent from the overall management unit 5, the control unit 342 (an example of the first control unit) reads the version information of the target module from the module version information storage unit 333 and sends it to the serial unit control unit 4 via the communication unit 341. Additionally, when the control unit 342 sends a ROM rewrite command and ROM rewrite data from the overall management unit 5, it sends the ROM rewrite command and ROM rewrite data to module A unit 331A and module B unit 331B.

[0076] in addition, Figure 1 and Figure 2 The example shown illustrates a modular information management system 100 comprising multiple elevator control units 4 and multiple terminals including a lobby terminal 3, but the present invention is not limited thereto. For example, if there is only one elevator unit, the modular information management system may also be structured without the ROM data storage unit 46 and the overall processing unit version information storage unit 47 within the elevator control unit 4. In this case, the overall management unit 5 and the lobby terminal 3 can directly exchange information.

[0077] Specifically, when the overall management unit 5 sends a version read command, the control unit 342 of the lobby terminal 3 can send the version information of each module unit read from the module version information storage unit 333 to the overall management unit 5 via the communication unit 341.

[0078] <Example of computer hardware architecture>

[0079] Next, for the implementation Figure 1 The hardware structure of each device of the control system function of the modular information management system 100 shown is referenced. Figure 3 Please provide an explanation.

[0080] Figure 3 This is a block diagram illustrating an example of the hardware structure of the lobby terminal 3, the machine control unit 4, and the overall management unit 5 that constitute the modular information management system 100. Figure 3 The computer 200 shown is hardware used as a so-called computer.

[0081] The computer 200 includes a CPU (Central Processing Unit) 201, a ROM (Read Only Memory) 202, a RAM (Random Access Memory) 203, a display unit 204, an operation input unit 205, non-volatile memory 206, and a communication interface 207, all connected to the bus B.

[0082] CPU 201 reads the program code of the software implementing the functions of this embodiment from ROM 202, deploys it to RAM 203, and executes it. Alternatively, computer 200 may replace CPU 201 with a processing device such as MPU (Micro-Processing Unit). Variables and parameters generated during the computation process are temporarily written to RAM 203.

[0083] The functions of the control unit 53 of the overall management unit 5, the control unit 48 of the machine control unit 4, the control unit 342 of the overall control unit 34 of the lobby terminal 3, and the functional unit 3311 of the module unit 331 are implemented by the CPU 201 reading the corresponding program code from the ROM 202, deploying it to the RAM 203, and executing it.

[0084] The display unit 204 is, for example, a monitor composed of an LCD (Liquid Crystal Display) or the like, which displays the results of processing performed by the computer 20.

[0085] The operation input unit 205, for example, consists of a keyboard, mouse, touch sensor, etc., and generates operation signals corresponding to the user's operation and supplies them to the CPU 201. The functions of the operation unit 54 of the overall management unit 5 are implemented by the operation input unit 205.

[0086] Alternatively, the display unit 204 and the operation input unit 205 can be integrated into a touch panel. Alternatively, the computer 200 may also be configured without the display unit 204 and the operation input unit 205.

[0087] As non-volatile storage 206, it can use, for example, HDD (Hard Disk Drive), SSD (Solid State Drive), floppy disk, optical disk, magneto-optical disk, CD-ROM, CD-R, non-volatile memory card, etc. In addition to the OS (Operating System) and various parameters, this non-volatile storage 206 also records programs used to enable the computer 200 to function. Furthermore, programs can be stored in ROM 202.

[0088] The program is stored in the form of program code that the computer can read, and the CPU 201 executes the actions that conform to the program code one by one. That is, ROM 202 or non-volatile memory 206 is used as an example of a computer-readable, non-temporary recording medium that stores a program executed by the computer.

[0089] The functions of the version information database 51 of the overall management department 5, the ROM database 52, the ROM data storage unit 46 of the serial number control department 4, the version information storage unit 47 of the entire processing department, the module version information storage unit 333 of the lobby terminal 3, the ROM data storage unit 334, the parameter storage unit 3312 of the module department 331, and the version information storage unit 3313 are all implemented by non-volatile storage 206 or ROM 202.

[0090] As a communication interface 207, for example using a NIC (Network Interface Card), it can send and receive various data with external devices via a network or communication line. The functions of the communication unit 45 of the unit control unit 4, the communication unit 341 of the overall control unit 34 of the lobby terminal 3, and the communication unit 332 of the peripheral equipment unit 33 of the lobby terminal 3 are all implemented by the communication interface 207.

[0091] <Structure of the version information storage section within the module>

[0092] Next, refer to Figure 4 The structure of the version information storage unit 3313 within module 331 will be explained. Figure 4 This is a diagram illustrating an example of the structure of the version information storage unit 3313 within module 331. Figure 4 Example of the structure of version information storage unit 3313A is shown in section A. Figure 4 Example of the structure of version information storage unit 3313B is shown in B.

[0093] Figure 4 The version information storage unit 3313A shown in section A has a content field F1, an address field F2, and a data field F3. In the content field F1, the stored information represents the version information of module A 331A and the update date and time of that version as an item. Specifically, it stores the text "Version of module A" and "Update date and time of module A".

[0094] The address field F2 stores the address information of module A 331A, including its version information and the update date and time.

[0095] Data field F3 stores version information and data indicating the update date and time of the version.

[0096] For example, in the first record of the version information storage unit 3313A, the data "32H'0001_0000" which stores the version information of module A unit 331A at address "H'00" is shown. In addition, in the second record, the data "32H'2022_0513" which stores the update date and time of the version at address "H'01" is shown.

[0097] Figure 4 The version information storage unit 3313B shown in Figure B also has the content field F11, address field F12, and data field F13. The meanings of these fields are the same as those in Figure B. Figure 4 The version information storage unit 3313A shown in A is the same, so its description is omitted here.

[0098] For example, in the first record of the version information storage unit 3313B, the data "32H'0002_0000" which stores the version information of module B unit 331B at address "H'00" is shown. In addition, in the second record, the data "32H'2022_0513" which stores the update date and time of the version information at address "H'01" is shown.

[0099] That is, the lobby terminal 3 realizes its function through the combination of module A 331A and module B 331B. However, in this embodiment, the information of the combination of the two module parts is not managed, but the version information of each module part is managed in its respective parameter storage unit 3312.

[0100] <The structure of the department that stores module version information within the peripheral equipment department>

[0101] Next, refer to Figure 5 The structure of the module version information storage unit 333 within the peripheral equipment unit 33 will be explained. Figure 5 This is a diagram illustrating a structural example of the module version information storage unit 333 within the peripheral equipment unit 33.

[0102] like Figure 5 As shown, the module version information storage unit 333 has three fields: content field F21, address field F22, and data field F23. The meaning of each field is as follows: Figure 4 The version information storage unit 3313A shown in A is the same, so its description is omitted here.

[0103] In the module version information storage unit 333, version information for module A 331A and version information for module B 331B are stored together. For example, in the first record of the module version information storage unit 333, the data "32H'0001_0000" indicating the version information of module A 331A is stored at address "H'00" of module A 331A is shown. In addition, in the second record, the data "32H'2022_0513" indicating the update date and time of the version information is stored at address "H'01" of module A 331A is shown.

[0104] <Structure of the entire processing unit and version information storage unit within the machine control unit>

[0105] Next, refer to Figure 6 The structure of the version information storage unit 47 for all processing units within the machine control unit 4 will be explained. Figure 6 This is a diagram illustrating the structure of the version information storage unit 47, which represents all processing units within the signal control unit 4.

[0106] like Figure 6 As shown, the version information storage unit 47 of the entire processing unit has a content field F31, an address field F32, and a data field F33. The meaning of each field is as follows: Figure 4 The version information storage unit 3313A shown in A is the same, so its description is omitted here.

[0107] The version information storage unit 47 stores information related to the versions of all terminals (processing units) connected to the machine control unit 4. Specifically, the version information storage unit 47 also stores information related to the versions of each module of the objects controlled by the machine control unit 4, namely the lobby terminal 3, the car terminal (not shown), and the inverter terminal (not shown) of the motor control unit 2.

[0108] For example, in the storage unit of the "hall terminal" information in the total processing unit version information storage unit 47, and... Figure 5 The module version information shown is saved together with the information saved in the storage unit 333 and stored together with the information in the lobby terminal 3_2 (illustration omitted) to lobby terminal 3_n (see reference). Figure 1 The information related to the version of each module is stored in all the lobby terminals.

[0109] In addition, in the "Car Terminal" information storage unit of the entire processing unit version information storage unit 47, information related to each version of module A 331A and module B 331B stored in the car terminal is stored, and in the "Inverter Terminal" information storage unit, information related to the version of module C 331C (not shown) stored in the inverter terminal is stored.

[0110] <Structure of the Version Information Database within the Overall Management Department>

[0111] Next, refer to Figure 7 The structure of the version information database 51 within the overall management department 5 is explained. Figure 7 This is a diagram illustrating the structure of the version information database 51 within the overall management department 5.

[0112] like Figure 7 As shown, the version information database 51 within the overall management department 5 has three fields: content field F41, address field F42, and data field F43. The meaning of each field is as follows: Figure 4 The version information storage unit 3313A shown in A is the same, so its description is omitted here.

[0113] Version information database 51 stores version information for all modules stored in all terminals controlled by the No. 1 control unit 4_1. Specifically, version information database 51 stores information (address and data) related to the version of each module (module A to module X) stored in the lobby terminals 3_1 to 3_n controlled by the No. 1 control unit 4_1.

[0114] In addition, the version information database 51 stores version-related information (addresses and data) of each module (modules A and B) stored in the car terminal controlled by the No. 1 control unit 4_1. Furthermore, the version information database 51 stores version-related information (addresses and data) of each module (module C) stored in the inverter terminal controlled by the No. 1 control unit 4_1.

[0115] In addition, although detailed illustrations are omitted, the version information database 51 also stores the version-related information of all modules stored in all terminals controlled by the No. 2 control unit 4_2 and the version-related information of all modules stored in all terminals controlled by the No. 3 control unit 4_3.

[0116] <Structure of the ROM database within the overall management department>

[0117] Next, refer to Figure 8 The structure of the ROM database 52 within the overall management department 5 will be explained. Figure 8 This is a diagram showing an example of the structure of the ROM database 52 within the overall management department 5.

[0118] like Figure 8 As shown, the ROM database 52 within the overall management unit 5 has a content field F51, a version field F52, and a data field F53.

[0119] The content field F51 stores the names of all modules (Module A 331A to Module X (illustration omitted)) managed by the module information management system 100. The version field F52 stores the module version information. The data fields F53 store the data (ROM data) for each version of the module.

[0120] <Version reading processing performed by the Overall Management Department>

[0121] Next, refer to Figure 9 This section explains the version reading process performed by the Overall Management Department 5. Figure 9 This is a flowchart illustrating an example of the version read processing flow performed by the control unit 53 of the overall management unit 5.

[0122] First, the control section 53 of the overall management department 5 (reference) Figure 1 (Step S1) Determine whether the execution time for the version read periodic processing has arrived. The version read periodic processing is a process that is executed periodically as described above in order to obtain the version information of each module possessed by each terminal (processing unit). For example, it is a process that is executed periodically during idle time when no one is riding in the elevator car section 1, or when maintenance is performed.

[0123] In step S1, if it is determined that the execution time for the version read periodic processing is not appropriate (if step S1 determines otherwise), the control unit 53 determines whether a version read instruction has been received (inputted) (step S2). The version read instruction is given by a user who wants to obtain version information for each module via the operation unit 54 (see reference). Figure 1 The input command.

[0124] In step S2, if it is determined that no version read command has been received (if step S2 determines no), the control unit 53 determines whether a ROM rewrite command has been received (inputted) (step S3). The ROM rewrite command is, as described above, an instruction to rewrite the ROM data of the module unit when updating the module unit's version for purposes such as updating or eliminating problems. The ROM rewrite command is also sent during idle time when no one is riding in the elevator car unit 1 or when maintenance is being performed.

[0125] In step S3, if it is determined that no version read command has been received (if step S3 determines no), the control unit 53 returns to step S1 for judgment. On the other hand, if any of steps S1, S2, and S3 determines yes, the control unit 53 sends a version read command to the SIM card control unit 4 of the terminal that is the target of version read periodic processing, version read command, or ROM rewrite command (step S4).

[0126] Next, the control unit 53 determines whether the version information from the module unit has been received by the control unit 4 of the serial number that sent the version read command in step S4 (step S5). If it is determined in step S5 that no version information has been received (if step S5 determines no), the control unit 53 continues to perform the determination in step S5.

[0127] On the other hand, in step S5, if it is determined that version information has been received (if step S5 determines yes), the control unit 53 uses the version information received in step S5 to update the version information database 51 (refer to...). Figure 1 The information is updated (step S6). Next, the control unit 53 determines whether version information has been received from the control unit 4 for all serial numbers of the object (step S7).

[0128] In step S7, if it is determined that no version information has been received from the All Numbers Control Unit 4 of the target device (if step S7 determines no), the control unit 53 returns to step S4 for processing. On the other hand, if it is determined in step S7 that version information has been received from the All Numbers Control Unit 4 of the target device (if step S7 determines yes), the version reading process performed by the overall management unit 5 ends.

[0129] <Version reading processing performed by the machine control department>

[0130] Next, refer to Figure 10 The version reading process performed by the serial number control unit 4 will be explained. Figure 10 This refers to the control unit 48 of the signal machine control unit 4 (reference). Figure 2 A flowchart illustrating an example of the version read processing flow.

[0131] First, the control unit 48 of the machine control unit 4 (reference) Figure 1 Step S11: Determine if the execution time for the version read periodic processing has arrived. If, in step S11, it is determined that the execution time for the version read periodic processing has not arrived (if step S11 determines no), the control unit 48 determines whether a version read instruction has been received (sent from the overall management unit 5) (step S12). If, in step S12, it is determined that no version read instruction has been received (if step S12 determines no), the control unit 48 returns to step S11 for further determination.

[0132] On the other hand, if both steps S11 and S12 are determined to be yes, the control unit 48 sends a version read instruction to the terminal that is the target of the version read periodic processing or version read instruction (step S13).

[0133] Next, the control unit 48 determines whether the module's version information has been received from the terminal that sent the version read command in step S13 (step 14). If it is determined in step S14 that no version information has been received (if step S14 determines no), the control unit 48 continues to perform the determination in step S14.

[0134] On the other hand, in step S14, if it is determined that version information has been received (if step S14 determines yes), the control unit 48 uses the version information received in step S14 to save the version information of all processing units in the version information storage unit 47 (see reference). Figure 1 Information update (step S15).

[0135] Next, if the control unit 48 determines in step S12 that a version read command has been received, that is, if a version read command has been received, it will send the information stored in the version information storage unit 47 of all processing units to the overall management unit 5 via the communication unit 45 (step S16).

[0136] Next, the control unit 48 determines whether version information has been received from all terminals of the target (step S17). If, in step S17, it is determined that version information has not been received from all terminals of the target (if step S17 determines no), the control unit 48 returns to step S13 for processing. On the other hand, if, in step S17, it is determined that version information has been received from all terminals of the target (if step S17 determines yes), the version reading process performed by the SIM card control unit 4 ends.

[0137] <Version setting processing / read processing in the lobby terminal>

[0138] Next, refer to Figure 11 This section explains the version setting / version reading process in lobby terminal 3. Figure 11 This is a flowchart illustrating an example of the version setting / version reading process in lobby terminal 3. Additionally, Figure 11 The example given is that the terminal (processing unit) that performs version setting / version reading is the lobby terminal 3, but these processes are also performed in other terminals such as the car terminal and the inverter terminal (both omitted from the illustration).

[0139] First, the functional units 3311 within each module 331 of the lobby terminal 3 (refer to...) Figure 2Step S21: Determine if the time for the periodic version setting process has arrived. If, in step S21, it is determined that the time for the periodic version setting process has arrived (if step S21 determines yes), each functional unit 3311 reads its own version information from a memory not shown in the diagram, and sets (saves) this information in the version information storage unit 3313 (step S22). After step S22, the version setting process performed by the lobby terminal 3 ends.

[0140] On the other hand, if in step S21 it is determined that it is not the execution opportunity for the version setting periodic processing (if step S21 determines no), the control unit 342 of the lobby terminal 3 determines whether the execution opportunity for the version read periodic processing has arrived (step S23). If in step S23 it is determined that it is the execution opportunity for the version read periodic processing (if step S23 determines yes), the control unit 342 sends a version read command to the target module unit 331 via the communication unit 341 and the communication unit 332 (step S24).

[0141] Next, the control unit 342 determines whether version information has been received from a certain module unit 331 (step S25). If, in step S25, it is determined that no version information has been received (if step S25 determines no), the control unit 342 continues with the determination in step S25. On the other hand, if, in step S25, it is determined that version information has been received (if step S25 determines yes), the control unit 342 updates the information of the module version information storage unit 333 using the received version information (step S26).

[0142] Next, the control unit 342 determines whether version information from all module units 331 has been received (step S27). If, in step S27, it is determined that version information from all modules has not been received (if step S27 determines no), the control unit 342 returns to step S24 for processing. On the other hand, if, in step S27, it is determined that version information has been received from all module units 331 (if step S27 determines yes), the version reading periodic processing performed by the lobby terminal 3 ends.

[0143] In step S23, if it is determined that the execution time for the version read periodic processing is not right (if step S23 determines no), the control unit 342 determines whether a version read instruction has been received (received from the serial number control unit 4) (step S28). In step S28, if it is determined that no version read instruction has been received (if step S28 determines no), the control unit 342 returns to step S21 to continue the determination.

[0144] On the other hand, in step S28, if it is determined that a version read command has been received (if step S28 determines yes), the control unit 342 reads the version information of the module unit that was instructed to perform version read in the version read command from the module version information storage unit 333 (step S29). Then, the control unit 342 sends the read version information to the SIM card control unit 4 via the communication unit 341 (step S30). After the processing in step S30, the version read processing performed by the lobby terminal 3 ends.

[0145] In this embodiment, the version information of each module is stored together in the module version information storage unit 333 of the lobby terminal 3. Therefore, when performing version read periodic processing or receiving version read instructions, the control unit 342 of the lobby terminal 3 can immediately read the version information of each module.

[0146] In addition, when dealing with faults or performing maintenance, if the user wants to obtain only the version information of a specific module 331, the control unit 342 that receives the version read command reads the version information of the target module 331 from the module version information storage unit 333 and sends it to the overall management unit 5 via the machine control unit 4.

[0147] Therefore, in this embodiment, even when a module 331 is used in multiple different terminals, or when multiple module 331s are used in combination in one terminal, the user can quickly and appropriately obtain the version information of the required module. That is, according to this embodiment, the traceability of version information of a common module commonly used in multiple terminals can be improved.

[0148] In addition, in this embodiment, for example, if the combination of modules used in the terminal is changed during the application, the user can also obtain the version information of the module by issuing a version read command targeting the required module.

[0149] <ROM Data Rewriting Processing>

[0150] Next, refer to Figure 12 The ROM data rewriting process performed by the overall management department 5, the machine control department 4, and the lobby terminal 3 is explained. Figure 12 This is a flowchart illustrating an example of the ROM data rewriting process performed by the Overall Management Department 5, Unit Control Department 4, and Gateway Terminal 3. Additionally, Figure 12 The example given is the lobby terminal 3, which performs ROM data rewriting processing. However, this processing is also performed in other terminals such as the car terminal and the inverter terminal.

[0151] First, the control section 53 of the overall management department 5 (reference) Figure 1 The rewritten ROM data is saved in the ROM database 52 (step S41). The rewritten ROM data is either the ROM data after correcting the problem in module 331, or the latest ROM data after a version upgrade. The processing in step S41 is performed, for example, based on the user's operation on operation unit 54.

[0152] Next, the operation unit 54 issues a ROM rewrite command to the control unit 53 based on the user's operation (step S42). Next, the control unit 53 searches the ROM database 52 based on the ROM rewrite command issued by the operation unit 54 (step S43). Next, the control unit 53 searches the version information database 51 based on the version information shown in the ROM rewrite command, thereby determining the module unit 331 to be subject to ROM rewrite processing (step S44).

[0153] In this embodiment, the version information database 51 stores all version information of each module used in each terminal. Therefore, even when multiple modules are used in combination in a terminal, the control unit 53 can appropriately obtain the required version information of the module by searching the version information database 51.

[0154] Next, the control unit 53 sends ROM rewrite data to the SIM card control unit 4 of the terminal that controls the module unit 331 with the ROM rewrite target (step S45). Next, the control unit 53 sends a ROM rewrite command to the SIM card control unit 4 with the target (step S46).

[0155] Next, the control unit 53, targeting all module units 331 that are the objects of the ROM rewrite instruction, determines whether steps S45 and S46 have been performed (step S47). If, in step S47, it is determined that the processing of all module units 331 has not ended (if step S47 is determined to be no), the control unit 53 returns to step S45 to continue processing. Conversely, if, in step S47, it is determined that the processing of all module units 331 has ended (if step S47 is determined to be yes), the control unit 53 terminates the ROM data rewrite process.

[0156] When the rewrite ROM data is sent from the control unit 53 to the serial number control unit 4 in step S45, the communication unit 45 of the serial number control unit 4 (see reference) Figure 1 ) Receive the rewritten ROM data (step S51). Next, the control unit 48 of the serial number control unit 4 (refer to...) Figure 1 For the second side of the ROM data storage section 46, which consists of two sides, the ROM data received in step S51 is used to rewrite it (step S52).

[0157] Next, the control unit 48 sends ROM rewrite data to the lobby terminal 3 (processing unit) to which the data is to be rewritten (step S53). Next, the communication unit 45 of the unit control unit 4 receives the ROM rewrite instruction from the overall management unit 5 (step S54). Next, the control unit 48 switches the face of the ROM data storage unit 46 from the first face currently being referenced to the second face that was rewritten in step S52 (step S55).

[0158] Next, the control unit 48 sends a ROM rewrite command to the lobby terminal 3, the target of the rewrite, via the communication unit 41 (step S56). After the processing of step S56, the ROM data rewrite process performed by the unit control unit 4 ends.

[0159] In step S53, when the ROM rewrite data is sent from the SIM card control unit 4 to the terminal, the communication unit 341 of the lobby terminal 3 (reference) Figure 2 ) Receive rewritten ROM data (step S61). Next, the control unit 342 of the lobby terminal 3 rewrites the second side of the ROM data storage unit 334, which consists of two sides, with the rewritten ROM data received in step S61 (step S62).

[0160] Next, the communication unit 341 of the lobby terminal 3 receives a ROM rewrite instruction from the unit control unit 4 (step S63). Then, the control unit 342 switches the face of the ROM data storage unit 334 from the currently referenced first face to the second face that was rewritten in step S62 (step S64). After the processing in step S64, the ROM data rewrite process performed by the lobby terminal 3 ends.

[0161] By conducting Figure 12 As shown in the process, when the lobby terminal 3 receives the ROM rewrite command, it can immediately refer to the information on the second side where the rewritten ROM data has been written, thus eliminating the need for control measures such as stopping the elevator's operation until the process is complete. Therefore, according to this embodiment, the elevator's non-operation time can be minimized.

[0162] Furthermore, for example, the above embodiments have described the structure of the apparatus and system in detail for the purpose of easily understanding the present invention, and are not limited to having all the structures described.

[0163] in addition, Figure 1 and Figure 2 The control lines or information lines indicated by solid lines, single arrows, and double arrows show what is deemed necessary for the description, but do not necessarily represent all control lines and information lines on the product. In fact, it can be assumed that almost all structures are interconnected.

[0164] Furthermore, the processing steps described in this specification include not only processing performed sequentially in the described order, but also processing that is not performed sequentially, but is executed in parallel or individually (e.g., parallel processing or processing using objects).

[0165] Furthermore, each component of the modular information management system according to one embodiment of this specification can be implemented in any hardware, provided that each piece of hardware can send and receive information via a network. Additionally, a process performed by a single processing unit can be implemented using a single piece of hardware, or it can be implemented through distributed processing by multiple pieces of hardware.

[0166] Explanation of reference numerals in the attached figures

[0167] 1…Car Section, 2…Motor Section, 3…Hall Terminal, 4…Unit 1 Control Section, 5…Overall Management Section, 33…Peripheral Equipment Section, 34…Overall Control Section, 46…ROM Data Storage Section, 47…Version Information Storage Section for All Processing Sections, 48…Control Section, 51…Version Information Database, 52…ROM Database, 53…Control Section, 54…Operation Section, 100…Module Information Management System, 331…Module Section, 333…Module Version Information Storage Section, 334…ROM Data Storage Section, 341…Communication Section, 342…Control Section.

Claims

1. A modular information management system, comprising multiple processing units having one or more modular units that perform specific functions and can be shared among multiple processing units; The module information management system, which includes a management department for managing information about the module units, is characterized by: The processing unit includes: A module version information storage unit that stores version information of all the modules stored in the processing unit; and The module version information is read from the module version information storage unit and sent to the first control unit of the management unit. The management unit includes a version information database that manages version information of all the module units sent from the multiple processing units, a second control unit that controls data updates of the module units, and a processing unit control unit that controls the actions of the multiple processing units. The module has a version information storage unit that stores its own version information. At predetermined periodic intervals, the module stores its own version information in this version information storage unit. At predetermined periodic intervals, the first control unit reads the version information of the module from the version information storage unit and stores it in the module version information storage unit. Upon receiving a version read instruction from the management unit to read the version information of the module, the first control unit reads the version information of the module specified in the version read instruction from the module version information storage unit and sends it to the management unit. The second control unit determines the module whose data needs to be updated based on the version information of the module stored in the version information database, and sends a data rewrite command to the determined module. The processing unit control unit includes: A version information storage unit for all processing units that stores version information of the modules sent from all of the multiple processing units; and The third control unit reads the version information of the module unit from the version information storage unit of all processing units and sends it to the management unit.

2. A module information management method for a module information management system, wherein the module information management system includes multiple processing units that have specific functions and can be shared in multiple processing units; The module information management method, which includes a management department for managing the information of the module units, is characterized by: The processing unit includes: A module version information storage unit that stores version information of all the modules stored in the processing unit; and The module version information is read from the module version information storage unit and sent to the first control unit of the management unit. The management unit includes a version information database that manages version information of all the module units sent from the plurality of processing units, a second control unit that controls data updates of the module units, and a processing unit control unit that controls the actions of the plurality of processing units. The module has a version information storage unit that stores its own version information. The module information management method includes: The module saves its version information in the version information storage unit at a predetermined periodic time. The first control unit reads the version information of the module from the version information storage unit and saves it in the module version information storage unit at a predetermined periodic time. The first control unit, upon receiving a version read instruction from the management unit to read the version information of the module unit, reads the version information of the module unit specified in the version read instruction from the module version information storage unit and sends it to the management unit; and The second control unit determines the module whose data needs to be updated based on the version information of the module stored in the version information database, and sends a data rewrite instruction to the determined module. The processing unit control unit includes: A version information storage unit for all processing units that stores version information of the modules sent from all of the multiple processing units; and The third control unit reads the version information of the module unit from the version information storage unit of all processing units and sends it to the management unit.

Images