Module information management system and module information management method.

Abstract

To provide a module information management system capable of managing information on multiple modules used in multiple processing units all at once.SOLUTION: A module information management system according to an aspect of the present invention includes: a terminal that has a module version information bulk storage unit 333 that stores version information of all module units 331 stored in the terminal, and a control unit 342 that reads a piece of version information of a module unit from the module version information bulk storage unit 333 to transmit the same to a general management unit 5; and the general management unit that has a version information database for managing all version information of the module unit 331 transmitted from multiple terminals.SELECTED DRAWING: Figure 2

Description

[Technical Field]

[0001] The present invention relates to a module information management system and a module information management method. [Background technology]

[0002] In recent years, it has become common to design each processing unit of a terminal, device, or other component of an elevator or other device by combining multiple types of general-purpose modules that realize specific functions and are applicable to various processing units. This is because designing processing units in this way improves the portability and scalability of software configured using modules. Various methods have been devised for managing information about software stored in various terminals in this way.

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

[0004] [Patent Document 1] Japanese Patent Publication No. 2021-196933 Summary of the Invention [Problem to be solved by the invention]

[0005] In the technology described in Patent Document 1, when software constituting the function of a regulation is composed of a combination of multiple pieces of software, a software reference number is assigned to each set of multiple pieces of software.The software reference number and the regulation ID are then associated and managed.In other words, the technology described in Patent Document 1 does not take into consideration the traceability of information on each piece of software constituting the multiple pieces of software.

[0006] Therefore, in a configuration in which a versatile module is used in various processing units, when updating functions on a module-by-module basis or correcting defects in a module, the technology described in Patent Document 1 makes it difficult to determine in which processing unit the target module is being used.

[0007] The present invention has been made in consideration of the above circumstances, and an object of the present invention is to enable the centralized management of information on multiple modules that are used in common in multiple processing units. [Means for solving the problem]

[0008] A module information management system according to one aspect of the present invention includes a plurality of processing units each having one or more types of module units that realize specific functions and can be used in common by the plurality of processing units, and a management unit that manages information about the module units.The processing units of the module information management system according to one aspect of the present invention include a module version information storage unit that stores version information about all modules stored in the processing units, and a first control unit that reads the version information about the module units from the module version information storage unit and transmits it to the management unit.The management unit stores a version information database that manages the version information about all module units transmitted from the plurality of processing units. a second control unit that controls updating of data in the module unit; and a processing unit control unit that controls operations of the plurality of processing units. Equipped with. The module unit includes a version information storage unit that stores its own version information, and stores its own version information in the version information storage unit at predetermined regular intervals. The first control unit reads the version information of the module unit from the version information storage unit at predetermined regular intervals and stores it in the module version information storage unit. When a version read command to read the version information of the module unit is received from the management unit, the first control unit reads the version information of the module unit specified in the version read command from the module version information storage unit and sends it to the management unit. The second control unit identifies the module unit whose data should be updated based on the version information of the module unit stored in the version information database, and sends a data rewrite command to the identified module unit. The processing unit control unit further includes a total processing unit version information storage unit that stores the version information of modules sent from all of the multiple processing units, and a third control unit that reads the version information of the module unit from the total processing unit version information storage unit and sends it to the management unit. [Effects of the Invention]

[0009] According to at least one aspect of the present invention, it becomes possible to collectively manage information on a plurality of modules that are commonly used in a plurality of processing units. Problems, configurations, and effects other than those described above will become apparent from the following description of the embodiments. [Brief explanation of the drawings]

[0010] [Figure 1] 1 is a diagram illustrating an example of a schematic configuration of a module information management system according to an embodiment of the present invention. [Figure 2] 2 is a block diagram showing an example of the configuration of a control system of a hall terminal according to one embodiment of the present invention; FIG. [Figure 3] 1 is a block diagram showing an example of the hardware configuration of a hall terminal, a machine control unit, and an overall management unit that constitute a module information management system according to one embodiment of the present invention. [Figure 4] FIG. 2 is a diagram illustrating an example of the configuration of a version information storage unit in a module unit according to an embodiment of the present invention. [Figure 5] FIG. 10 is a diagram illustrating an example of the configuration of a module version information collective storage unit in a peripheral unit according to an embodiment of the present invention. [Figure 6] 10 is a diagram illustrating an example of the configuration of an all-processing unit version information storage unit in the unit control unit according to one embodiment of the present invention. FIG. [Figure 7] FIG. 2 is a diagram illustrating an example of the configuration of a version information database in a general management unit according to an embodiment of the present invention. [Figure 8] FIG. 2 is a diagram showing an example of the configuration of a ROM database in an overall management unit according to an embodiment of the present invention. [Figure 9] 10 is a flowchart illustrating an example of a procedure for a version read process by a control unit of an overall management unit according to an embodiment of the present invention. [Figure 10] 10 is a flowchart illustrating an example of a procedure for a version read process by a control unit of a unit control unit according to an embodiment of the present invention. [Figure 11]10 is a flowchart showing an example of the procedure of version set processing and version read processing in a hall terminal according to one embodiment of the present invention. [Figure 12] 10 is a flowchart showing an example of the procedure for a ROM data rewrite process performed by a general management unit, a machine control unit, and a hall terminal according to one embodiment of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0011] Hereinafter, examples of modes for carrying out the present invention (hereinafter referred to as "embodiments") will be described with reference to the accompanying drawings. The present invention is not limited to the embodiments, and various numerical values ​​in the embodiments are merely examples. Furthermore, in this specification and drawings, identical components or components having substantially the same functions will be designated by the same reference numerals, and redundant explanations will be omitted.

[0012] <Outline of module information management system configuration> First, the configuration of a module information management system according to one embodiment of the present invention will be described with reference to Fig. 1. Fig. 1 is a diagram showing an example of the schematic configuration of a module information management system 100 according to one embodiment of the present invention.

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

[0014] The first to third machine control units 4_1 to 4_3 are connected to the overall management unit 5 via a network N made up of a public internet network or the like.

[0015] The car section 1 is an elevator car that moves up and down in a hoistway of a building (not shown). The motor section 2 is configured with a motor (both not shown) that drives a hoist that raises and lowers the car section 1, and the like. The hall terminals 3_1 to 3_n (an example of a processing unit) are terminals configured by a hall button 31 and an indicator 32 (both see FIG. 2) provided in the elevator hall (not shown), and a control system that controls them. In the following description, when there is no need to individually identify the hall terminals 3_1 to 3_n, they will be collectively referred to as hall terminal 3. The configuration of the control system of the hall terminal 3 will be described in detail with reference to the following FIG. 2.

[0016] In this embodiment, the hall terminal 3 includes the hall button 31 and the indicator 32, but the present invention is not limited to this. The hall terminal 3 may also include other terminals such as a speaker and a lamp.

[0017] [Unit control section] The first machine control unit 4_1 is a control device that controls the operations of the car unit 1, the motor unit 2, and the hall terminal 3. In this embodiment, an example is given in which three machine control units, namely, the first machine control unit 4_1 to the third machine control unit 4_3, are provided, but the present invention is not limited to this. The number of machine control units may be two or less, or may be four or more. In the following description, when it is not necessary to individually identify the first machine control unit 4_1 to the third machine control unit 4_3, they will be collectively referred to as the machine control unit 4 (an example of a processing unit control unit).

[0018] The first machine control unit 4_1 includes a communication unit 41, a 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 full processing unit version information storage unit 47, and a control unit 48.

[0019] The communication unit 41 controls the operation of communication between the car unit 1, the motor unit 2, and the hall terminal 3. The motor control unit 42 controls the operation of the motor unit 2 . The car control unit 43 controls the opening and closing operations of doors (not shown) of the car unit 1, and the operations of various terminals (not shown) (hereinafter also referred to as "car in-terminals", examples of processing units) provided inside the car unit 1. The car in-terminals include, for example, destination floor buttons, door opening and closing buttons, a display device, a speaker, and lighting (all not shown).

[0020] The hall terminal control unit 44 controls the operation of the hall terminal 3 . The communication unit 45 controls the operation of communication with the overall management unit 5 .

[0021] The ROM data storage unit 46 stores information (version information) about the version of each module unit 331 (see FIG. 2) used in each terminal managed by the unit control unit 4, and data (programs, hereinafter also referred to as ROM data) of each module unit 331. The module units 331 are modules that realize IO (Input Output) functions, IND (Indicate) functions, etc. in the terminal, and are designed with general-purpose specifications so that they can be commonly used in different types of terminals.

[0022] The ROM data storage unit 46 is configured, for example, with two surfaces, the first surface being used to store the (currently in use) ROM data before being rewritten with the rewrite ROM data, and the second surface being used to store the new version of ROM data after being rewritten with the rewrite ROM data. When a ROM rewrite command is sent from the overall management unit 5, a process is performed to switch the surface of the ROM data storage unit 46 from the first surface to the second surface. The configuration of the ROM data stored in the ROM data storage unit 46 will be described in detail with reference to FIG. 6 below.

[0023] The all-processing unit version information storage unit 47 collectively stores version information of each module unit possessed by each processing unit, such as the hall terminal 3, the in-car terminal, and the inverter terminal (not shown) that controls the motor unit 2. The configuration of the all-processing unit version information storage unit 47 will be described in detail later with reference to FIG. 6.

[0024] The control unit 48 (an example of a third control unit) controls the operation of each unit constituting the unit control unit 4. Furthermore, when a version read command is sent from the overall management unit 5, the control unit 48 sends a version read command to the hall terminal 3. The control unit 48 then updates the version information in the overall processing unit version information storage unit 47 with the version information of each module unit sent from the hall terminal 3 based on the command. This keeps the version information in the overall processing unit version information storage unit 47 up to date. Furthermore, the control unit 48 sends the version information of each module unit stored in the overall processing unit version information storage unit 47 to the overall management unit 5 via the communication unit 45. The processing by the control unit 48 will be described in detail with reference to FIG. 10, which will be described later.

[0025] [General management department] The overall management unit 5 (an example of a management unit) is provided, for example, in a monitoring center (not shown) installed in a remote location, and manages the version information of each module unit possessed by each processing unit such as the hall terminal 3 and the in-car terminal, and performs update processing of the version, etc. Furthermore, the overall management unit 5 controls the rewriting of ROM data of the module units, etc., based on the version information of each module unit possessed by each processing unit. The overall management unit 5 includes a version information database 51, a ROM database 52, a control unit 53, and an operation unit .

[0026] The version information database 51 stores version information of all module parts included in processing units such as the hall terminal 3 and the in-car terminal. The configuration of the version information database 51 will be described in detail later with reference to FIG. ROM data of each module unit is stored in the ROM database 52. The configuration of the ROM database 52 will be described in detail later with reference to FIG.

[0027] The control unit 53 (an example of a second control unit) performs the version read process when the time to execute the version read periodic process arrives, or when a version read command or a ROM rewrite command is input by the user via the operation unit 54.

[0028] The periodic version read process is a process that is executed periodically to read the version information of each module possessed by each terminal, for example, during idle times when no one is in the elevator car unit 1 or when maintenance is being performed. The version read process is a process that reads the version information of each module possessed by each terminal, and more specifically, a process that sends a version read command to the elevator control unit 4 and updates the information in the version information database 51 with the version information returned based on the command. By updating the information in the version information database 51 at such regular intervals, the version information in the version information database 51 is kept up to date.

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

[0030] The ROM rewrite command is a command to rewrite the ROM data of a module when a module version update is performed for the purpose of updating or resolving a malfunction, etc. The ROM rewrite command is also sent during idle times when no one is in the elevator car 1, or when maintenance is being performed.

[0031] The operation unit 54 is configured by, for example, a mouse, a keyboard, or a touch sensor, and generates an operation signal according to the operation content input by the user and outputs it to the control unit 53.

[0032] [Hall terminal] Next, the configuration of the control system of the hall terminal 3 will be described with reference to Fig. 2. Fig. 2 is a block diagram showing an example of the configuration of the control system of the hall terminal 3. Note that Fig. 2 illustrates the hall terminal 3 as an example of a terminal (processing unit), but other terminals such as an in-car terminal also have a similar configuration.

[0033] The hall terminal 3 includes a peripheral unit 33 and an overall control unit 34. The peripheral unit 33 includes a module A unit 331A, a module B unit 331B, a communication unit 332, a module version information collective storage unit 333, and a ROM data storage unit 334.

[0034] The module A unit 331A is a module that provides an input / output (IO: Input Output) function for the hall button 31, and the module B unit 331B is a module that provides a display (IND: Indicate) function for the indicator 32. Since the control system configurations of the module A unit 331A and the module B unit 331B are the same, only the module A unit 331A will be described as an example. In the following description, when there is no need to individually distinguish between the module A unit 331A and the module B unit 331B, they will be collectively referred to as the module unit 331.

[0035] 2 shows an example in which the hall terminal 3 has two modules, a module A section 331A that provides input / output functions for the hall button 31 and a module B section 331B that provides display functions for the indicator 32, but the present invention is not limited to this. The hall terminal 3 may have one (type) of module or three or more modules.

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

[0037] The functional unit (IO) 3311A is the main body of a module that provides input / output functions for the wheel button 31. When the time comes to execute the version set periodic process, the functional unit (IO) 3311A reads its own version information from a memory (not shown) and stores (sets) it in the version information storage unit 3313A. The version set periodic process is a periodic process for storing the latest version information in the version information storage unit 3313A, and is a process that is executed periodically, such as during idle time or when maintenance is performed. The information in the version information storage unit 3313A is updated based on the process executed at such periodic times, thereby keeping the version information in the version information storage unit 3313A up to date.

[0038] The parameter storage unit 3312A stores various parameters used by the function unit (IO) 3311A to provide the IO function.

[0039] The version information storage unit 3313A stores information about the version of the module unit of the functional unit (IO). That is, in this embodiment, even when a single terminal uses multiple types of module units (in the example shown in FIG. 2, module A unit 331A and module B unit 331B), version information for each of the multiple module units 331 is managed individually in each module unit 331. Note that, for example, if the type of module unit stored in the terminal is changed during operation of the system, the version information of the module unit managed in the version information storage unit 3313 is also updated to the information after the change.

[0040] In the following description, when there is no need to distinguish between functional units 3311A and 3311B individually, they are collectively referred to as functional unit 3311. Furthermore, when there is no need to distinguish between parameter storage units 3312A and 3312B individually, they are collectively referred to as parameter storage unit 3312, and when there is no need to distinguish between version information storage units 3313A and 3313B individually, they are collectively referred to as version information storage unit 3313.

[0041] The communication unit 332 controls the operation of communication with the communication unit 341 of the overall control unit 34. Module version information batch storage unit 333 (an example of a module version information storage unit) stores version information of module A unit 331A and version information of module B unit 331B. That is, information on the versions of a plurality of modules is registered collectively in module version information batch storage unit 333. The configuration of module version information batch storage unit 333 will be described in detail later with reference to FIG. 5.

[0042] The ROM data storage unit 334 stores the ROM data of the module A unit 331A and the module B unit 331B. The ROM data storage unit 334 is configured with two sides, similar to the ROM data storage unit 46 of the unit control unit 4. Rewrite ROM data is written to the second side, and when a ROM rewrite command is received from the unit control unit 4, the side of the ROM data storage unit 334 is switched from the first side to the second side.

[0043] The overall control unit 34 includes a communication unit 341 and a control unit 342 . The communication unit 341 controls communication operations with the car control unit 4 and with the communication unit 332 of the peripheral unit 33.

[0044] The control unit 342 (an example of a first control unit) reads the version information of the target module from the module version information batch storage unit 333 when performing periodic version read processing or when receiving a version read command or a ROM rewrite command sent from the overall management unit 5, and controls transmission of the read version information to the unit control unit 4 via the communication unit 341. Furthermore, when a ROM rewrite command and ROM rewrite data are sent from the overall management unit 5, the control unit 342 transmits the ROM rewrite command and ROM rewrite data to the module A unit 331A and the module B unit 331B.

[0045] 1 and 2, the module information management system 100 includes multiple elevator control units 4 and multiple terminals including the hall terminal 3, but the present invention is not limited to this. For example, if there is only one elevator, the module information management system may be configured without the ROM data storage unit 46 and overall processing unit version information storage unit 47 in the elevator control unit 4. In this case, the overall management unit 5 and the hall terminal 3 can directly exchange information.

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

[0047] <Example of computer hardware configuration> Next, the hardware configuration of each device for realizing the functions of the control system of the module information management system 100 shown in FIG. 1 will be described with reference to FIG.

[0048] 3 is a block diagram showing an example of the hardware configuration of the hall terminal 3, the machine control unit 4, and the overall management unit 5 that make up the module information management system 100. The calculator 200 shown in FIG. 3 is hardware used as a so-called computer.

[0049] 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, a non-volatile storage 206, and a communication interface 207, each of which is connected to a bus B.

[0050] The CPU 201 reads out program code of software that realizes each function according to this embodiment from the ROM 202, expands it in the RAM 203, and executes it. Note that the computer 200 may include a processing device such as an MPU (Micro-Processing Unit) instead of the CPU 201. Variables, parameters, etc. that are generated during the calculation process are temporarily written to the RAM 203.

[0051] Each function 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 hall terminal 3, and the functional unit 3311 of the module unit 331 is realized by the CPU 201 reading the corresponding program code from the ROM 202, expanding it into the RAM 203, and executing it.

[0052] The display unit 204 is, for example, a monitor configured with an LCD (Liquid Crystal Display) or the like, and displays the results of processing performed by the computer 20, etc. The operation input unit 205 is configured with, for example, a keyboard, a mouse, a touch sensor, etc., and generates an operation signal according to an operation by a user and supplies it to the CPU 201. The function of the operation unit 54 of the overall management unit 5 is realized by the operation input unit 205.

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

[0054] The nonvolatile storage 206 may be, for example, a hard disk drive (HDD), a solid state drive (SSD), a flexible disk, an optical disk, a magneto-optical disk, a CD-ROM, a CD-R, or a nonvolatile memory card. In addition to an operating system (OS) and various parameters, programs for operating the computer 200 are recorded in the nonvolatile storage 206. The programs may be stored in the ROM 202.

[0055] The program is stored in the form of a computer-readable program code, and the CPU 201 sequentially executes operations in accordance with the program code. In other words, the ROM 202 or the non-volatile storage 206 is used as an example of a computer-readable non-transitory recording medium that stores a program to be executed by a computer.

[0056] The functions of the version information database 51, ROM database 52 of the overall management unit 5, the ROM data storage unit 46 of the machine control unit 4, the overall processing unit version information storage unit 47, the module version information collective storage unit 333, ROM data storage unit 334, the parameter storage unit 3312 of the module unit 331, and the version information storage unit 3313 are realized by non-volatile storage 206 or ROM 202.

[0057] The communication interface 207 may be, for example, a network interface card (NIC), and can transmit and receive various data to and from external devices via a network or communication line. The functions of the communication unit 45 of the machine control unit 4, the communication unit 341 of the overall control unit 34 of the hall terminal 3, and the communication unit 332 of the peripheral unit 33 of the hall terminal 3 are realized by the communication interface 207.

[0058] <Configuration of version information storage section in module section> Next, the configuration of version information storage unit 3313 in module unit 331 will be described with reference to Fig. 4. Fig. 4 is a diagram showing an example of the configuration of version information storage unit 3313 in module unit 331. Fig. 4A shows an example of the configuration of version information storage unit 3313A, and Fig. 4B shows an example of the configuration of version information storage unit 3313B.

[0059] 4A has a content field F1, an address field F2, and a data field F3. The information stored in content field F1 includes items such as version information of module A part 331A and text indicating the update date and time of that version. Specifically, the text "version of module A part" and "update date and time of module A part" are stored.

[0060] The address field F2 stores information about the address where the version information of the module A part 331A and the update date and time of the version are stored. The data field F3 stores data on version information and data indicating the update date and time of the version.

[0061] For example, the first record in version information storage section 3313A indicates that "32H'0001_0000", which is version information data for module A section 331A, is stored at address "H'00". The second record indicates that "32H'2022_0513", which is data indicating the version update date and time, is stored at address "H'01".

[0062] Similarly, version information storage unit 3313B shown in Fig. 4B has a content field F11, an address field F12, and a data field F13. The meanings of these fields are the same as those of version information storage unit 3313A shown in Fig. 4A, so a description of these fields will be omitted here.

[0063] For example, the first record in version information storage unit 3313B indicates that "32H'0002_0000", which is version information data for module B unit 331B, is stored at address "H'00". The second record indicates that "32H'2022_0513", which is data indicating the update date and time of the version information, is stored at address "H'01".

[0064] In other words, the hall terminal 3 realizes its functions by combining a module A section 331A and a module B section 331B, but in this embodiment, the version information of each individual module section is managed in each parameter storage section 3312, rather than the information on the combination of the two module sections.

[0065] <Configuration of module version information batch storage section in peripheral section> Next, the configuration of the module version information batch storage unit 333 in the peripheral unit 33 will be described with reference to Fig. 5. Fig. 5 is a diagram showing an example of the configuration of the module version information batch storage unit 333 in the peripheral unit 33.

[0066] 5, module version information batch storage unit 333 has a content field F21, an address field F22, and a data field F23. The meanings of these fields are the same as those in version information storage unit 3313A shown in FIG. 4A, so a description of these fields will be omitted here.

[0067] Information relating to the version of module A section 331A and information relating to the version of module B section 331B are stored together in module version information batch storage section 333. For example, the first record in module version information batch storage section 333 indicates that "32H'0001_0000", which is version information data for module A section 331A, is stored at address "H'00" of module A section 331A. Furthermore, the second record indicates that "32H'2022_0513", which is data indicating the update date and time of the version information, is stored at address "H'01" of module A section 331A.

[0068] <Configuration of the version information storage unit for all processing units in the unit control unit> Next, the configuration of the all processing unit version information storage unit 47 in the machine control unit 4 will be described with reference to Fig. 6. Fig. 6 is a diagram showing an example of the configuration of the all processing unit version information storage unit 47 in the machine control unit 4.

[0069] 6, the full processing unit version information storage unit 47 has a content field F31, an address field F32, and a data field F33. The meanings of these fields are the same as those in the version information storage unit 3313A shown in FIG. 4A, so a description of these fields will be omitted here.

[0070] The all-processing unit version information storage unit 47 stores information relating to the versions of all terminals (processing units) connected to the car control unit 4. Specifically, the all-processing unit version information storage unit 47 collectively stores information relating to the versions of each module of the hall terminal 3, the in-car terminal (not shown), and the inverter terminal (not shown) that controls the motor unit 2, which are controlled by the car control unit 4.

[0071] For example, the storage section for "hall terminal" information in the total processing unit version information storage section 47 stores information regarding the versions of each module stored in all hall terminals from hall terminal 3_2 (not shown) to hall terminal 3_n (see Figure 1), along with the information stored in the module version information collective storage section 333 shown in Figure 5.

[0072] In addition, the storage section for information on the "in-car terminal" of the full processing unit version information storage section 47 stores information on each version of the module A section 331A and module B section 331B stored in the in-car terminal, and the storage section for information on the "inverter terminal" stores information on the version of the module C section 331C (not shown) stored in the inverter terminal.

[0073] <Configuration of the version information database in the General Management Department> Next, the configuration of the version information database 51 in the overall management unit 5 will be described with reference to Fig. 7. Fig. 7 is a diagram showing an example of the configuration of the version information database 51 in the overall management unit 5.

[0074] 7, version information database 51 in overall management unit 5 has a content field F41, an address field F42, and a data field F43. The meanings of these fields are the same as those in version information storage unit 3313A shown in FIG. 4A, so a description of these fields will be omitted here.

[0075] The version information database 51 stores version information of all modules stored in all terminals controlled by the first machine control unit 4_1. Specifically, the version information database 51 stores information (addresses and data) about the versions of each module (modules A to X) stored in each of the hall terminals 3_1 to 3_n controlled by the first machine control unit 4_1.

[0076] The version information database 51 also stores information (addresses and data) about the versions of each module (module A and B) stored in the car terminal controlled by the first car control unit 4_1. The version information database 51 also stores information (addresses and data) about the versions of each module (module C) stored in the inverter terminal controlled by the first car control unit 4_1.

[0077] In addition, although details are not shown in the version information database 51, information regarding the versions of all modules stored in all terminals controlled by the second unit control unit 4_2, and information regarding the versions of all modules stored in all terminals controlled by the third unit control unit 4_3 are also stored.

[0078] <Configuration of ROM database within the General Management Department> Next, the configuration of the ROM database 52 in the overall management unit 5 will be described with reference to Fig. 8. Fig. 8 is a diagram showing an example of the configuration of the ROM database 52 in the overall management unit 5.

[0079] As shown in FIG. 8, the ROM database 52 in the overall management unit 5 has the following fields: a content field F51, a version field F52, and a data field F53.

[0080] The contents field F51 stores the names of all modules (module A section 331A to module X section (not shown)) managed by the module information management system 100. The version field F52 stores information on the version of the module. The fields of the data field F53 store data (ROM data) for each version of the module.

[0081] <Version read processing by the overall management department> Next, the version read process by the overall management unit 5 will be described with reference to Fig. 9. Fig. 9 is a flowchart showing an example of the procedure for the version read process by the control unit 53 of the overall management unit 5.

[0082] First, the control unit 53 (see FIG. 1) of the overall management unit 5 determines whether or not the timing for executing the periodic version read process has arrived (step S1). As described above, the periodic version read process is a process that is executed periodically to acquire version information of each module possessed by each terminal (processing unit), for example, during idle time when no one is riding in the elevator car unit 1 or when maintenance is being performed.

[0083] If it is determined in step S1 that it is not time to execute the version read periodic process (if the determination in step S1 is NO), the control unit 53 determines whether a version read command is present (input) (step S2). The version read command is a command input via the operation unit 54 (see FIG. 1) by a user who wants to obtain version information of each module.

[0084] If it is determined in step S2 that there is no version read command (if step S2 is determined to be NO), the control unit 53 determines whether a ROM rewrite command is present (input) (step S3). As described above, the ROM rewrite command is a command that instructs the rewriting of the ROM data of the module unit when a version update of the module unit is performed for the purpose of updating or resolving a malfunction. The ROM rewrite command is also transmitted during idle times when no one is in the elevator car unit 1, or when maintenance is being performed.

[0085] If it is determined in step S3 that there is no version read command (if step S3 is determined as NO), the control unit 53 returns to step S1 to make another determination. On the other hand, if any of steps S1, S2, and S3 is determined as YES, the control unit 53 transmits a version read command to the unit control unit 4 that controls the terminal that is the target of the version read periodic process, the version read command, or the ROM rewrite command (step S4).

[0086] Next, the control unit 53 determines whether or not it has received the version information of the module unit from any of the unit control units 4 that sent the version read command in step S4 (step S5). If it is determined in step S5 that the version information has not been received (if step S5 returns NO), the control unit 53 continues making the determination in step S5.

[0087] On the other hand, if it is determined in step S5 that the version information has been received (if the determination in step S5 is YES), the control unit 53 updates the information in the version information database 51 (see FIG. 1) with the version information received in step S5 (step S6). Next, the control unit 53 determines whether or not the version information has been received from all target unit control units 4 (step S7).

[0088] If it is determined in step S7 that version information has not been received from all of the target machine control units 4 (if step S7 is a NO determination), the control unit 53 returns to step S4 and performs the process. On the other hand, if it is determined in step S7 that version information has been received from all of the target machine control units 4 (if step S7 is a YES determination), the version read process by the overall management unit 5 ends.

[0089] <Version read processing by unit control unit> Next, the version read process by the unit control unit 4 will be described with reference to Fig. 10. Fig. 10 is a flowchart showing an example of the procedure of the version read process by the control unit 48 of the unit control unit 4 (see Fig. 2).

[0090] First, the control unit 48 of the unit control unit 4 (see FIG. 1) determines whether or not it is time to execute the version read periodic process (step S11). If it is determined in step S11 that it is not time to execute the version read periodic process (if the determination in step S11 is NO), the control unit 48 determines whether or not a version read command has been issued (whether it has been sent from the overall management unit 5) (step S12). If it is determined in step S12 that there is no version read command (if the determination in step S12 is NO), the control unit 48 returns to step S11 and makes another determination.

[0091] On the other hand, if the determination is YES in either step S11 or step S12, the control unit 48 transmits a version read command to the terminal that is the target of the version read periodic process or the version read command (step S13).

[0092] Next, the control unit 48 determines whether or not the version information of the module has been received from the terminal that transmitted the version read command in step S13 (step S14). If it is determined in step S14 that the version information has not been received (if the determination in step S14 is NO), the control unit 48 continues the determination in step S14.

[0093] On the other hand, if it is determined in step S14 that the version information has been received (if the determination in step S14 is YES), the control unit 48 updates the information in the all-processing unit version information storage unit 47 (see FIG. 1) with the version information received in step S14 (step S15).

[0094] Next, if the control unit 48 determines in step S12 that a version read command has been issued, i.e., if it has received a version read command, it transmits the information stored in the total processing unit version information storage unit 47 to the overall management unit 5 via the communication unit 45 (step S16).

[0095] Next, the control unit 48 determines whether or not version information has been received from all of the target terminals (step S17). If it is determined in step S17 that version information has not been received from all of the target terminals (if the determination in step S17 is NO), the control unit 48 returns to step S13 and performs the process. On the other hand, if it is determined in step S17 that version information has been received from all of the target terminals (if the determination in step S17 is YES), the version read process by the unit control unit 4 ends.

[0096] <Version set processing and read processing at hall terminals> Next, the version set processing and version read processing in the hall terminal 3 will be described with reference to Fig. 11. Fig. 11 is a flowchart showing an example of the procedure for the version set processing and version read processing in the hall terminal 3. Note that Fig. 11 gives an example in which the terminal (processing unit) that performs the version set processing and version read processing is the hall terminal 3, but these processes are also performed in other terminals such as an in-car terminal and an inverter terminal (neither of which are shown).

[0097] First, each functional unit 3311 (see FIG. 2) in each module unit 331 of the hall terminal 3 determines whether or not it is time to execute the version set periodic process (step S21). If it is determined in step S21 that it is time to execute the version set periodic process (if step S21 returns a YES), each functional unit 3311 reads its own version information from a memory (not shown) and sets (stores) the information in the version information storage unit 3313 (step S22). After processing step S22, the version set process by the hall terminal 3 ends.

[0098] On the other hand, if it is determined in step S21 that it is not the time to execute the version set periodic process (if step S21 is judged as NO), the control unit 342 of the hall terminal 3 determines whether the time to execute the version read periodic process has arrived (step S23).If it is determined in step S23 that it is the time to execute the version read periodic process (if step S23 is judged as 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).

[0099] Next, the control unit 342 determines whether or not version information has been received from any of the module units 331 (step S25). If it is determined in step S25 that version information has not been received (if the determination in step S25 is NO), the control unit 342 continues the determination in step S25. On the other hand, if it is determined in step S25 that version information has been received (if the determination in step S25 is YES), the control unit 342 updates the information in the module version information collective storage unit 333 with the received version information (step S26).

[0100] Next, the control unit 342 determines whether or not it has received the version information of all module units 331 (step S27). If it is determined in step S27 that it has not received the version information of all modules (if the result of step S27 is NO), the control unit 342 returns to step S24 and performs processing. On the other hand, if it is determined in step S27 that it has received the version information from all module units 331 (if the result of step S27 is YES), the version read periodic processing by the hall terminal 3 ends.

[0101] If it is determined in step S23 that it is not the timing to execute the version read periodic process (if the determination in step S23 is NO), the control unit 342 determines whether or not a version read command has been received (whether or not a version read command has been received from the unit control unit 4) (step S28). If it is determined in step S28 that a version read command has not been received (if the determination in step S28 is NO), the control unit 342 returns to step S21 and continues making determinations.

[0102] On the other hand, if it is determined in step S28 that a version read command has been received (step S28 is determined to be YES), the control unit 342 reads (reads out) the version information of the module unit instructed to read the version in the version read command from the module version information batch storage unit 333 (step S29). Next, the control unit 342 transmits the read version information to the unit control unit 4 via the communication unit 341 (step S30). After processing in step S30, the version read process by the hall terminal 3 ends.

[0103] In this embodiment, the version information of each module part is stored in a lump in the module version information lump storage unit 333 of the hall terminal 3, so that the control unit 342 of the hall terminal 3 can instantly read the version information of each module part when the version read periodic process is executed or when a version read command is received.

[0104] Also, when only the version information of a specific module unit 331 is to be acquired during troubleshooting or maintenance, if the user designates a module in the version read command, the control unit 342 that has received the version read command reads the version information of the target module unit 331 from the module version information batch storage unit 333 and transmits it to the overall management unit 5 via the unit control unit 4.

[0105] Therefore, in this embodiment, even when one module unit 331 is used in a plurality of different terminals or when a plurality of module units 331 are used in combination in one terminal, the user can quickly and appropriately acquire the information on the version of the desired module. That is, according to this embodiment, the traceability of the version information of the general-purpose module units commonly used in a plurality of terminals can be improved.

[0106] Also, in this embodiment, for example, even when the combination of modules applied to the terminal is changed during operation, the user can appropriately acquire the version information of the module unit by issuing a version read command targeting the desired module unit.

[0107] <ROM Data Rewriting Process> Next, referring to FIG. 12, the ROM data rewriting process by the overall management unit 5, the unit control unit 4, and the hall terminal 3 will be described. FIG. 12 is a flowchart showing an example of the procedure of the ROM data rewriting process by the overall management unit 5, the unit control unit 4, and the hall terminal 3. In FIG. 12, an example in which the terminal (processing unit) that performs the ROM data rewriting process is the hall terminal 3 is given, but it is assumed that each of these processes is also performed in other terminals such as the car inner terminal and the inverter terminal.

[0108] First, the control unit 53 (see FIG. 1) of the overall management unit 5 stores rewritten ROM data in the ROM database 52 (step S41). The rewritten ROM data is ROM data in which a defect in the module unit 331 has been corrected, or the latest upgraded ROM data. The processing of step S41 is performed based on, for example, a user's operation on the operation unit 54.

[0109] Next, the operation unit 54 issues a ROM rewrite command to the control unit 53 based on an operation by the user (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 indicated in the ROM rewrite command, thereby determining the module unit 331 to be subjected to the ROM rewrite process (step S44).

[0110] In this embodiment, all version information of each module used in each terminal is stored in the version information database 51. Therefore, even if a terminal uses a combination of multiple modules, the control unit 53 can search the version information database 51 to appropriately obtain the version information of the desired module.

[0111] Next, the control unit 53 transmits the rewrite ROM data to the unit control unit 4 that controls the terminal equipped with the module unit 331 whose ROM is to be rewritten (step S45). Next, the control unit 53 transmits a ROM rewrite command to the unit control unit 4 (step S46).

[0112] Next, the control unit 53 determines whether or not the processes of steps S45 and S46 have been performed on all module units 331 that are targets of rewriting in response to the ROM rewrite command (step S47). If it is determined in step S47 that the processes have not been completed for all module units 331 (if the determination in step S47 is NO), the control unit 53 returns to step S45 and continues the process. On the other hand, if it is determined in step S47 that the processes have been completed for all module units 331 (if the determination in step S47 is YES), the control unit 53 ends the ROM data rewrite process.

[0113] When the rewrite ROM data is sent from the control unit 53 to the unit control unit 4 in step S45, the communication unit 45 (see FIG. 1) of the unit control unit 4 receives the rewrite ROM data (step S51). Next, the control unit 48 (see FIG. 1) of the unit control unit 4 rewrites the second surface of the ROM data storage unit 46, which is composed of two surfaces, with the rewrite ROM data received in step S51 (step S52).

[0114] Next, the control unit 48 transmits the rewrite ROM data to the hall terminal 3 (processing unit) to be rewritten (step S53). Next, the communication unit 45 of the machine control unit 4 receives a ROM rewrite command from the overall management unit 5 (step S54). Next, the control unit 48 switches the surface of the ROM data storage unit 46 from the first surface currently being referenced to the second surface rewritten in step S52 (step S55).

[0115] Next, the control unit 48 transmits a ROM rewrite command to the hall terminal 3 to be rewritten via the communication unit 41 (step S56). After the process of step S56, the ROM data rewrite process by the machine control unit 4 ends.

[0116] In step S53, when the rewrite ROM data is transmitted from the machine control unit 4 to the terminal, the communication unit 341 (see FIG. 2) of the hall terminal 3 receives the rewrite ROM data (step S61). Next, the control unit 342 of the hall terminal 3 rewrites the second side of the ROM data storage unit 334, which is composed of two sides, with the rewrite ROM data received in step S61 (step S62).

[0117] Next, the communication unit 341 of the hall terminal 3 receives a ROM rewrite command from the machine control unit 4 (step S63). Next, the control unit 342 switches the surface of the ROM data storage unit 334 from the first surface currently being referenced to the second surface rewritten in step S62 (step S64). After processing step S64, the ROM data rewrite process by the hall terminal 3 ends.

[0118] 12, the hall terminal 3 can immediately refer to the information on the second side to which the rewritten ROM data has been written upon receiving the ROM rewrite command, eliminating the need to perform control such as stopping the operation of the elevator until the processing is complete. Therefore, according to this embodiment, the downtime of the elevator can be minimized.

[0119] Furthermore, for example, the above-described embodiments provide detailed and specific descriptions of the configurations of the devices and systems in order to clearly explain the present invention, and are not necessarily limited to those having all of the configurations described.

[0120] 1 and 2, the control lines or information lines indicated by solid lines, single arrows, and double arrows are those considered necessary for explanation, and do not necessarily represent all control lines or information lines in the product. In reality, it can be considered that almost all components are interconnected.

[0121] Furthermore, in this specification, processing steps describing chronological processing include not only processing that is performed chronologically in the order described, but also processing that is not necessarily performed chronologically but is performed in parallel or individually (for example, parallel processing or processing by objects).

[0122] Furthermore, each of the components of the module information management system according to an embodiment of the present disclosure may be implemented in any hardware as long as the respective hardware can transmit and receive information to and from each other via a network. Furthermore, the processing performed by a certain processing unit may be realized by a single piece of hardware, or may be realized by distributed processing using multiple pieces of hardware. [Explanation of symbols]

[0123] 1...car unit, 2...motor unit, 3...hall terminal, 4...unit control unit, 5...overall management unit, 33...peripheral unit, 34...overall control unit, 46...ROM data storage unit, 47...overall processing unit version information storage unit, 48...control unit, 51...version information database, 52...ROM database, 53...control unit, 54...operation unit, 100...module information management system, 331...module unit, 333...module version information collective storage unit, 334...ROM data storage unit, 341...communication unit, 342...control unit

Claims

1. A module information management system including: a plurality of processing units each having one or more types of module units that realize specific functions and can be used in common by a plurality of processing units; and a management unit that manages information about the module units, The processing unit a module version information storage unit that stores version information of all the modules stored in the processing unit; a first control unit that reads the version information of the module unit from the module version information storage unit and transmits the version information to the management unit; the management unit includes a version information database that manages version information of all of the module units transmitted from the plurality of processing units, a second control unit that controls updating of data in the module units, and a processing unit control unit that controls operations of the plurality of processing units; the module unit includes a version information storage unit that stores its own version information, and stores its own version information in the version information storage unit at predetermined regular intervals; the first control unit reads version information of the module unit from the version information storage unit at predetermined regular intervals and stores the read version information in the module version information storage unit, and when receiving a version read command to read the version information of the module unit from the management unit, reads the version information of the module unit specified in the version read command from the module version information storage unit and transmits the version information to the management unit; the second control unit identifies the module unit whose data should be updated based on the version information of the module unit stored in the version information database, and transmits a data rewrite command to the identified module unit; The processing unit control unit a total processing unit version information storage unit that stores version information of the modules transmitted from all of the plurality of processing units; a third control unit that reads the version information of the module unit from the all-processing unit version information storage unit and transmits the version information to the management unit. Module information management system.

2. A module information management method using a module information management system including a plurality of processing units having one or more types of module units that realize specific functions and can be used in common by the plurality of processing units, and a management unit that manages information about the module units, The processing unit a module version information storage unit that stores version information of all the modules stored in the processing unit; a first control unit that reads the version information of the module unit from the module version information storage unit and transmits the version information to the management unit; the management unit includes a version information database that manages version information of all of the module units transmitted from the plurality of processing units, a second control unit that controls updating of data in the module units, and a processing unit control unit that controls operations of the plurality of processing units; the module unit includes a version information storage unit for storing its own version information, a step in which the module unit stores its own version information in the version information storage unit at predetermined regular intervals; a step in which the first control unit reads out the version information of the module unit from the version information storage unit at a predetermined regular timing and stores the read out version information of the module unit in the module version information storage unit; a step in which, when the first control unit receives a version read command to read version information of the module unit from the management unit, the first control unit reads version information of the module unit specified in the version read command from the module version information storage unit and transmits the version information to the management unit; the second control unit specifying the module unit whose data should be updated based on the version information of the module unit stored in the version information database, and transmitting a data rewrite command to the specified module unit; The processing unit control unit a total processing unit version information storage unit that stores version information of the modules transmitted from all of the plurality of processing units; a third control unit that reads the version information of the module unit from the all-processing unit version information storage unit and transmits the version information to the management unit. Module information management method.

Images