JP2007317089A - System, method and program for automatically updating software - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a system for automatically updating software which, when a plurality of versions of software exist, is capable of automatically selecting the most suitable version of the software without being restricted by the just previous version. <P>SOLUTION: The system has a start/stop managing application 103 for managing the start and stop of a function-based application 100 and the updates of software, the function-based application being executed by a computer device for managing the manufacture or inspection of products. The start/stop managing application 103 has a version selecting part 105 for selecting a particular version from a plurality of versions owned for the function-based application 100. <P>COPYRIGHT: (C)2008,JPO&INPIT

Description

  The present invention relates to a system for automatically updating software when a problem occurs in a computer apparatus, a method thereof, and a program used in the system.

Conventionally, when updating software, a new version of the software is obtained from the software provider and installed in the target personal computer. Here, as a method for obtaining a new version, acquisition by e-mail, downloading from a web server, acquisition by a medium such as a flexible disk or a CD-R (Compact Disk Recordable) can be mentioned.
The timing for installing a new version of the software is before the target application is started or after it is terminated, and after replacing the software, the computer device is restarted. Yes. Furthermore, as a procedure for distributing and updating software to be updated, there is a method of dynamically searching a database and automatically acquiring a new version of software (see, for example, Patent Document 1). Furthermore, some software of this type includes means for confirming the normal operation of the updated software, and if it is determined that an abnormality has occurred, the software is automatically returned to the version before the update (for example, , See Patent Document 2).
JP 2000-330778 A Japanese Patent Laid-Open No. 11-3214

However, this type of software automatic distribution system is based on the premise that a new version will be released in stages. Since the method of returning is taken, only the version of the software whose operation was confirmed immediately before can be returned when a failure occurs.
Here, as software used mainly for production facility equipment, a plurality of versions may be prepared and appropriate software may be selected as a countermeasure against a problem that is difficult to analyze as a problem. Furthermore, when there are a plurality of processing contents to be included in the version upgrade, these processes may not coexist as the same application. In such a case, multiple pieces of software to be updated are released at the same time, but the conventional automatic software distribution system automatically selects and installs the optimum version of software from these multiple software. I couldn't. In a production factory or the like, when a problem occurs, a system designer or the like is called each time to investigate the cause of the problem and restart the system, resulting in poor work efficiency.
The present invention has been made in view of such circumstances, and an object of the present invention is to make it possible to select a plurality of versions of software and automatically select an optimal version without being limited to the immediately preceding version. It is to let you choose.

The present invention for solving the above-mentioned problems is a means for storing a plurality of types of software having different versions of the software as update software when causing the computer apparatus to execute the software, and predetermined when the software is updated. A version selection unit that selects any one version from a plurality of versions according to priority, and a software update processing unit that updates the update software of the version selected by the version selection unit as execution software. Software automatic update system characterized by
In this automatic software update system, when updating software to be executed by a computer device, a specific version is selected from a plurality of versions prepared for the software. Then, the selected version of the file is updated as an execution file, and is executed by the computer device. The version is selected based on preset conditions or the like.

  According to the present invention, when updating software to be executed and operated by a computer apparatus, a plurality of candidates having different versions are prepared for the software, and updated to one version of software selected from these candidates. As a result, it is possible to execute a version of software that can operate most stably. In particular, stable operation is possible in a system that operates for 24 hours. In addition, when it is necessary to confirm the operation of a plurality of versions, it is possible to automatically perform such confirmation by setting the conditions of the version selection unit. In addition, when multiple computer devices that execute the same software are connected to the network, the optimum software is automatically updated based on the results of the specific computer device, so that version management is easy. Become.

The best mode for carrying out the invention will be described in detail with reference to the drawings.
FIG. 1 shows a system configuration of an automatic software update system according to a first embodiment of the present invention, and is a simplified block diagram of a software structure that is running on a computer device.
In a computer device to which this automatic software update system is applied, two software programs, that is, a function-specific application 100 and a start / stop management application 103 can be executed. The function-specific application 100 has a structure in which the function is divided into two, an A module 101 and a B module 102. The function-specific application 100 includes communication means such as socket communication, for example, and communicates information with the activation / deactivation management application 103.

  The start / stop management application 103 includes a communication calculation unit 104 that performs a start command, a stop command, a processing command, an error report reception, and the like for the function-specific application 100, a version selection unit 105 that selects an appropriate version at the time of update, A software update processing unit 106 that performs replacement processing with the version selected by the version selection unit 105, a startup procedure storage unit 107 that manages the startup procedure of the updated function-specific application 100, and a history for each version A version history storage unit 108, a program status recording unit 109 that stores information at the time of termination of the function-specific application 100, application software for each version, and module software required for the version of the application software And a storage unit 110. being 憶. The storage unit 110 may use a memory, a hard disk drive, or the like, and may be configured on the computer device side instead of an essential component of the activation / deactivation management application 103.

Next, the operation of this embodiment will be described.
First, an outline of the processing of the start / stop management application 103 will be described with reference to the flowchart of FIG. As shown in FIG. 2, the activation / deactivation management application 103 first performs an update process (step S201). When the system is continuously operated (N in step S202), the operation state of the function-specific application 100 is changed. A monitoring process is performed (step S203). If an update process is necessary (Y in step S204), the process returns to the update process in step S201 again. When the system is to be stopped (Y in step S202), an end process is performed (step S205).

The details of each of the above processes (steps S201 to S205) and the operation of the computer apparatus will be described with reference to the flowchart of FIG.
First, the OS (operating system) of the computer device is first activated (step S301). Next, the start / stop management application 103 is started (step S302). At this time, for example, if the start / stop management application 103 is set to be automatically started, such as OS startup registration, the start / stop management application 103 is automatically started.
When the activation / deactivation management application 103 is activated, the activation / deactivation management application 103 refers to the previous deactivation state stored in the program state recording unit 109 and updates the function-specific application 100 to the optimum version. Is performed (step S303). Details of the software update process will be described later.
Further, the activation / deactivation management application 103 executes the version of the software selected in the software update process in step S303 according to the procedure registered in the activation procedure storage unit 107, and activates the function-specific application 100 (Sstep S304). ). Steps S303 and S304 correspond to step S201 (update processing) in FIG.
If the system is normally terminated (Y in step S305), the function-specific application is terminated (step S312), the activation / deactivation management application is terminated (step S313), and the process is terminated. Step S312 and step S313 correspond to step 205 (end processing) in FIG.

On the other hand, if the system is not terminated (N in step S304), the operation process is started. Here, the operation processing is, for example, when the function-specific application 100 is an application used when inspecting a board in a production line, causing the computer apparatus to execute the function-specific application 100 and inspecting the board. It means to let you do. This operation process is repeated unless an error occurs.
On the other hand, if an error occurs during the execution of the operation process (Y in step S307), the operation log is saved in the program state recording unit 109 (step S308). The log at this time is for identifying the cause of the error, and is performed when a log that is always required during operation processing is saved. The processing from step S306 to step S308 corresponds to step S203 in FIG.

Then, the communication calculation unit 104 determines whether or not the function-specific application 100 needs to be restarted based on the type of error that has occurred (step S309).
If the related process cannot be terminated or interrupted, it is determined that restart is necessary and cannot be continued (N in step S309), and only the function-specific application 100 is terminated ( In step S310, the process returns to the software update process (step S303, the process proceeds from N in step S311). Furthermore, if the function-specific application 100 cannot be terminated normally or if an error cannot be guaranteed after the restart, the OS is restarted (Y in step S311). In this case, the process returns to the OS startup process in step S301. The processing from step S309 to step S311 corresponds to step S204 in FIG.

  The process from the occurrence of an error to the restart of the OS (steps S307 to S311, S301) may be a completely automatic process without intervention by the worker, or the operator's judgment is made using a GUI (Graphical User Interface) such as a dialog. It may be a necessary process. Then, switching between automatic processing and manual processing may be performed by setting the start / stop management application 103.

Further, details of the software update process shown in step S303 will be described with reference to the flowchart of FIG.
First, the necessity of software update is determined based on the cause of the error (step S401). In the case of an error other than a software defect that does not require updating (N in step S401), the processing here is terminated. The error that does not need to be updated includes, for example, an operation error of a hardware wafer that is hardware-controlled by the modules 101 and 102, or a case where the operator has normally terminated the computer device at the previous termination. It is done.
If it is determined that updating is required (Y in step S401), the number of retries is determined (step S402). The number of retries means the number of times that version of the software is executed. When the software is restarted due to a malfunction or the like, the number of retries is incremented by one. Until the number of retries reaches a predefined number (Y in step S402), the same version is restarted and executed without updating software. On the other hand, when the upper limit of the number of retries has been reached (N in step S402), the version selection unit 105 confirms whether there is an update reservation file (step S403). The update reservation file is a version file to be updated.

As a result of searching the update reservation file, if there is a version to be updated (Y in step S403), the presence or absence of an update order list is checked (step S404). The update order list is a list that defines which version is preferentially used as an update target when there are a plurality of versions to be updated. When the update order list exists (Y in step S404), the version selection unit 105 determines an update file according to this list (step S405). On the other hand, if the update order list does not exist (N in step S404), the version selection unit 105 determines a version to be updated by another method such as a file name of each version or a time stamp comparison (step S406). ).
When the version to be updated is determined, the software update processing unit 106 replaces the currently executed executable file with the update file of the version to be updated. Specifically, first, the active execution file is moved to the history folder (step S407). At this time, information indicating the version is added to the file name and renamed. Further, the update file of the version to be updated is moved to the execution folder, and the file name is renamed to make an executable file, that is, an executable file (step S408).

  On the other hand, if the update reservation file does not exist in the process of step S403, the presence / absence of a history file is checked (step S409). A history file is a file that stores information about versions that have been used in the past. If the history file does not exist (N in step S409), the process is terminated without updating. On the other hand, if an update file exists (Y in step S409), for example, the optimum version is selected from the average value of the time during which the normal operation has been performed in the past (step S410). If the version determined at this time is the same as the currently operated version (Y in step S411), the process here is terminated without updating, and the processes in steps S407 and S408 are performed only when the versions are different. To update the version of the function-specific application 100.

Here, FIG. 5 shows an example of a file structure for performing the processing of step S407 and step S408.
The execution folder 500 is a folder for managing a version file currently being operated. The following files are stored in the execution folder 500. The execution file 501 is software that can be executed by the function-specific application 100 to be updated, and is, for example, “Application.exe”. The module 502 and the module 503 are modules that are attached to the execution file 501 and are necessary for executing the function-specific application. For example, they are “Module1.dll” and “Module2.dll”, respectively. The update history file 504 is a file that stores information when the execution file 501 is updated. For example, the update history file 504 includes “update history.txt”. The setting file 505 includes data for performing various settings in the execution file 501 and is, for example, “setting file.ini”. If the function-specific application 100 does not require the modules 502 and 503 and the setting file 505, these files are not stored in the execution folder 500. Further, the numbers of modules 502 and 503 and setting files 505 are not limited to those shown in FIG.

  The history folder 506 is a folder for managing version files that have been operated in the past, and a rename file created from the execution file before update when the processing in step S407 is executed is stored as a history file. In FIG. 5, a history file 507 corresponding to version 0.0.0.0 of the function-specific application 100 and a history file 508 corresponding to version 1.0.0.0 are stored. Various file names can be used as the renamed file name. For example, when the execution file 501 is “Application.exe”, the history file 507 is “Application-0.exe”. In addition, the history file 508 is “Application-1.exe”. Information regarding these history files 507 and 508 is stored in the update history file 504.

  The update reservation folder 509 is a folder for storing a new version update file (update reservation file) as an update file to be updated. FIG. 5 shows an example in which three versions are prepared as new versions. That is, the update order list file 510, for example, “update order list.txt” is a file that defines the update order of the update reservation files in the update reservation folder 509, and is referred to in step S404 of FIG. is there. The update reservation file 511 is, for example, a version 3.0.0.0 execution file (Application-3.exe), and the update reservation file 512 is a version 4.0.0.0 execution file (Application-4.exe). ), The update reservation file 513 is an execution file (Application-5.exe) of version 5.0.0.0. The update candidate file 514 is a module to be updated, for example, Module1. As an update candidate of dll, Module1-2. a module such as dll.

FIG. 6 shows an example of the format of the update history file 504.
As shown in FIG. 6, the update history file 504 is created in a text format. For example, file name data 600 is arranged on the first line. In the file name data 600, the name of the execution file such as “Appname = Application.exe” is defined.
Version data 601 describes version information of the software being executed.
Retry data 602, 603, and 604 record the normal operation time before each retry execution and the average operation time when retrying three times for each version. For example, the retry data 602 is “[0.0.0.0]”, ie, “0.0 = 0.0”, “001 = 5”, operates for 5 hours before the first retry, and “002 = 15 "indicates that the operation has been performed for 15 hours until the second retry, and" 003 = 10 "indicates that the operation has been performed for 10 hours until the third retry. Further, “Ave = 10”, that is, the average operation time of three times is 10 hours. The retry data 604 indicates the number of retries and the operation time of the 2.0.0.0 version. Since there is no data “003 =”, it can be seen that the third retry is being confirmed.

  Error data 605 indicates error information indicating the cause of the retry. The error data 605 has a code indicating the content of the error for each version and each retry. For this error information, as a criterion for selecting an optimum version from the history files 507 and 508 stored in the history folder 506, for example, a selection condition such as adopting a version in which a specific error has not occurred other than the operation time Used when provided.

Further, FIG. 7 shows an example of the format of the update order list file 510 shown in FIG.
In the update order list file 510, the names of the files are defined in descending order of priority. The first line indicates the first priority data 700, and “Update1 = Application-3.exe”, that is, Application-3. . It is defined that exe is the executable file with the highest priority. Hereinafter, the second priority data 701 in the second row is “Update2 = Application-4.exe”, and it is defined that this executable file is the version with the second highest priority. The third priority data 702 in the third row is “Update3 = Application-5.exe, Module1-2.dll”, the execution file with the lowest priority, and a module that is upgraded with this execution file as a set And are defined. As described above, two or more files can be simultaneously upgraded as a version upgrade target.

According to this embodiment, when causing a computer device to execute the function-specific application 100 and controlling the production device and the inspection device, the computer device executes the start / stop management application 103, whereby the function-specific application 100 is executed. The activation / deactivation management application 103 updates the update file (history files 507, 508, update) stored in the history folder 506 or the update reservation folder 509 when a problem caused by the function-specific application 100 occurs. Since the optimum file is automatically determined from the reserved files 511 to 514) and the function-specific application 100 is operated using such an update file as an execution file, the optimal execution file is automatically selected from a plurality of candidates. Can be selected To become. Therefore, the computer apparatus can be operated stably. In addition, stable operation is possible even in a system that operates for 24 hours.
Furthermore, since the update history file 504 stores the average operation time for each version and the contents of errors, a more stable execution file can be selected when multiple versions are used multiple times. It becomes possible, and it becomes possible to operate a production apparatus etc. stably. Here, when testing a new version of an executable file, the update order list file 510 is created, and if the priority order is determined, the update can be performed in this order. Files can be used preferentially, and problems can be overcome quickly.

A second embodiment of the present invention will be described in detail with reference to the drawings. In addition, the same code | symbol is attached | subjected to the component same as 1st Embodiment. In addition, overlapping explanation is omitted.
As shown in FIG. 8, a total of four personal computers including three computer devices 800, 801, and 802 and a server 803 are connected to each other via a switching hub 804. Each of the computer devices 800 to 802 is used for controlling a production device or an inspection device. Further, the function-specific application 100 and the start / stop management application 103 in the first embodiment are installed and executed in each of the computer devices 800 to 802.

  Here, in this software automatic update system, only the activation / deactivation management application 103 installed in the computer apparatus 800 has a function capable of deploying the optimum version to other computer apparatuses 801 and 802. This function is, for example, a function for operating a preset period without any trouble and copying a version for which stable operation is confirmed to the other computer devices 801 and 802.

The expansion processing in this embodiment will be described using the flowchart of FIG.
First, it is confirmed that a specific version can be operated for a preset time (step S901). If the start / stop management application 103 of the computer device 800 is set to be deployed to other computer devices 801 and 802 (Y in step S902), the computer devices 801 and 802 for which version deployment is scheduled. The update reservation folder 509 (see FIG. 5) copies the file currently being executed by the computer apparatus 800 as a version file to be updated (step S903).
Further, the activation / deactivation management application 103 of the computer device 801 checks whether or not it is registered in the server 803 (step S904). If registration is necessary (Y in step S905), the file in operation is also copied to the update folder of the server 803 (step S805), and the process here ends.

Further, when the network is constructed in this way, update files (for example, update reservation files 511 to 514 in FIG. 5) can be placed in the server 803. Processing of the computer device 800 in this case will be described with reference to FIG.
For example, when the start / stop management application 103 operating on the computer device 801 performs update processing of the application operated on the computer device 801, the presence or absence of an update file in the server 803 is checked (step S1001), and the update file is found. In that case (Y in step S1002), the file is copied to its own update reservation folder 509 (see FIG. 5) (step S1003). This process may be performed at an arbitrary timing by periodically executing a program for checking the server 803.

In this embodiment, in a system that has a plurality of computer devices 800 to 802 connected to a network, and that is operated by causing the computer devices 800 to 802 to execute the same function-specific application 100, the performance of one computer device is achieved. Versions that can be operated stably based on the above, and that can be executed on other computer devices by deploying this version of the executable file to other computer devices Can be operated. Therefore, even a large-scale production factory can be operated efficiently and stably. Also, the administrator's labor can be saved.
Furthermore, since the update folder of the server 803 is checked and necessary files are copied to the own update reservation folder 509, it is possible to test by simply uploading a new version of the file from a remote location, Work efficiency is improved.
Other operations and effects are the same as those in the first embodiment.

The present invention can be widely applied without being limited to the above-described embodiments.
For example, the start / stop management application 103 may allow the administrator to set conditions for selecting an update target, the priority order of a new file and a file with an operation record, and the like. In this case, the start / stop management application 103 may display a GUI that facilitates condition setting on the monitor.
Further, in the processing of step S1001 shown in FIG. 10, the start / stop management application 103 may check the server 803 every time the computer devices 800 to 802 restart the OS. Alternatively, the server 803 may be checked every time the start / stop management application 103 operates for a certain period of time.

3 may be performed when the function-specific application 100 ends, that is, after step S310 is executed. When the computer apparatus has been stably operated until the previous time, such an operation state can be prioritized.
Furthermore, each computer apparatus may have a plurality of types of function-specific applications 100, and a plurality of function-specific applications 100 may be executed selectively or simultaneously. In this case, the start / stop management application 103 executes the process for each function-specific application 100.

It is a block diagram which shows the outline of the software automatic update system in embodiment of this invention. It is a flowchart which shows the outline | summary of a process of a start / stop management application. It is a flowchart which shows the process of a software automatic update system. It is a flowchart which shows the detail of a process of step S303 of FIG. It is a figure which shows an example of the file structure for performing the process of step S407 and step S408 shown in FIG. It is a figure which shows an example of the format of an update history file. It is a figure which shows an example of a format of an update order file. It is a figure explaining the software automatic update system in case a some computer apparatus is network-connected. FIG. 9 is a flowchart showing a deployment process when updating software in the software automatic update system shown in FIG. 8. FIG. 9 is a flowchart illustrating a case where update processing is performed based on a file stored in a server in the software automatic update system illustrated in FIG. 8.

Explanation of symbols

100 Application by function (software, program)
103 Start / stop management application (program)
104 communication calculation unit 105 version selection unit 106 software update processing unit 109 program state storage unit 110 storage unit 507, 508 history file (update software)
511, 512, 513, 514 Reservation reservation file (update software)
800, 801, 802 computer apparatus

Claims (10)

  When operating the software on a computer device, means for storing a plurality of types of software with different versions of the software as update software, and when updating the software, any one of a plurality of versions is determined according to a predetermined priority order. An automatic software update system, comprising: a version selection unit that selects one version; and a software update processing unit that updates the update software of the version selected by the version selection unit as operation software.   The automatic software update system according to claim 1, wherein the plurality of versions include a version currently in operation, a version having an operation record in the past, and a new version having no operation record.   The automatic software update system according to claim 2, wherein the version selection unit is configured to select a version to be updated according to a priority order set for a new version.   When a malfunction occurs in the software that is currently in operation, it has a status recording unit that stores information indicating the contents of the malfunction and an operation time until the malfunction occurs in association with the version of the software The software automatic update system according to claim 2.   5. The automatic software update system according to claim 2, wherein the version selection unit is configured to determine a version to be automatically updated by comparing operation results of the versions. 6.   6. The software automatic update according to claim 1, further comprising: a program for starting and stopping the computer device; and one or more pieces of the software that can be started by the program. system.   The automatic software update system according to claim 6, wherein the update timing is when the software is started or finished.   When the updated version of the updated software operates normally for a preset time, the updated software has a communication calculation unit that transmits the updated software to another computer device that operates the same software. The software automatic update system according to any one of claims 1 to 6. When updating software that runs on a computer device,
Selecting any version of the update software from a plurality of different versions of update software stored in a storage device as the software update target; and
Extracting the selected version of the update software and updating the update software as software that causes the computer device to operate;
A method for automatically updating software. Selecting a version of the update software from a plurality of different versions of update software stored in a storage device as an update target of software operated on a computer device;
Extracting the selected version of the update software, and updating the update software as software operated on the computer device;
Is executed by the computer apparatus.

Images