KR20050028245A - Method and system of remote updating of the embedded software on the devices, working under linux operating system control - Google Patents

Abstract

A method for remotely updating embedded software loaded on a device using a Linux system from other device is provided to reliably update the embedded software in a remote place, and return to the past software in case that an update process is failed in an embedded system or an error is generated in the embedded system. A user side of the second device connects to an initial update web page offered from a web server of the device by using a web browser(S601). It is checked that the new software is present in an update server(S602). In the case that the new software is present, the update process for the corresponding software is advanced(S608). The final test for the newly updated software is performed(S610). In the case that the update is judged as successful based on a test result, new files of the updated software are copied to a spare folder and success of the update process is displayed on the web page(S615). In the case that the update is unsuccessful, the system is returned to the past system and failure of the update process is displayed(S620).

Description

Method and System of Remote Updating of the Embedded Software on the Devices, Working under Linux Operating System Control}

The present invention relates to a method for updating software operating based on an OS, and more particularly, to a method for remotely updating embedded software embedded in a device using a Linux system from another device. will be.

In recent years, many devices have been manufactured with a web server installed therein so that they can be remotely controlled by the Internet. If the web server complies with Internet industry standards, the user can access the interior of the device through any browser.

Manufacturers should design so that they can change network settings and other device settings remotely. One of the advanced ways to do this is to remotely update the system and application software of the target device, which can provide convenience for both users and manufacturers.

However, for devices with embedded software, the operating system and application software can be updated, and if the update fails, the method will return to the old version and if the update is completed, the system will operate properly due to an error in the update process. There are no countermeasures for not doing so. Therefore, there is a need to find a solution to the above problem in the field of embedded software.

The present invention was devised in view of the above problems, and an object thereof is to provide a reliable method for remotely updating any embedded software.

It is another object of the present invention to provide a method for returning to the past software when the update process fails or an error occurs in the embedded system.

In order to achieve the above object, the method of remotely updating the software of the first device embedded with embedded software according to the present invention from the second device connected to the first device and the Internet, at the user side of the second device A first step of accessing an initial update web page provided by a web server of the device using a web browser; A second step of checking whether new software exists in the update server; A third step of performing an update process for the corresponding software when the new software exists as a result of the checking; A fourth step of performing a final test on the newly updated software; And the fifth step of copying new files of the updated software to a spare folder if the update is successful, and indicating that the update process was successful on the web page, and the test result, the update is not successful. If not, the method returns to the existing system and includes a sixth step indicating that the update process has failed on the web page.

In order to achieve the above object, the second step is preferably performed by downloading the database file on the update server side and comparing it with the database file on the first device side.

The third step may include downloading a new file from the update server, decompressing the file, and copying it to a standard folder; Setting a value of a predetermined file to a value meaning that an update process is started; And reloading a new module using the new file copied to the standard folder, restarting the new daemon and the application, and performing an update.

The fifth step may include copying the new files to a spare folder; Setting a value of a predetermined file to a value meaning that the update process is finished; Deleting unnecessary temporary files created while performing the steps; And indicating to the user that the update process was successful on the web page.

The sixth step may include copying existing files stored in the spare folder into a standard folder; Reloading a new module using the file copied to the standard folder, and rolling back to an existing system by restarting a new daemon and application; Setting a value of a predetermined file to a value meaning that the update process is finished; And indicating to the user that the update process has failed on the web page.

In addition, if a system crash occurs after performing any one of the above steps, manually restarting the system of the second device after the crash occurs; Checking a value of a predetermined file indicating whether the update process is finished; If the value of the file is a value indicating that the update process is completed, performing the remaining booting process; Copying existing files stored in the spare folder to the standard folder if the value of the file indicates that the update process is not finished; Setting a value of the file to a value indicating that an update process is finished; And it is preferable to further include the step of proceeding to the other booting process.

Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings.

1 is a block diagram schematically showing the overall environment in which the present invention operates.

The invention works by the user passing a command through executable modules called web browsers 310 on the control device 300 side. The control device 300 is a separate device for remotely controlling a target device 200 having embedded software.

The web server 210 uses CGI or ASP to represent a dynamic web page. The dynamic web page represented in this way can be seen in the examples of FIGS. 4, 6, and 7. When CGI, ASP or other executable modules are called through a dynamic web page, the functions are executed within the web server.

The Linux operating system 220 is most commonly used as an OS of various kinds of embedded devices. Linux is an open source OS that is freely available for everyone to use and easy to improve. Linux is packaged and distributed, for example Red Hat, Slackware, SuSE, and Debian.

The web server 210 is separate software that operates based on the Linux driving system 220. The web server 210 used in the present embodiment can use GoAhead WebServer ^{TM of} GoAhead Software, which is well known as an embedded web server. The web server is an open source program that runs on a Linux system and is designed according to Internet industry standards. Therefore, it supports Active Server Page (ASP), common gateway interface (CGI), etc. to implement dynamic web pages. The communication between the web server 210 and the web browser 310 is made through Hypertext Transfer Protocol (HTTP).

The web server 210 checks whether there is a new file to update from an external update server 100, and if there is a new file, stores it in the repository 230 and uses the stored file to install software of the target device. You can update it.

2 is a flowchart illustrating a process performed in a web server during the operation of the present invention.

First, a user accesses a web server 210 in a target device 200 and displays an initial update page in a web browser (S601). If authentication is required to access the web server 210, a window as shown in FIG. 3 appears asking for a user ID and password. When the user enters a valid user ID and password, the initial update page appears in the web browser.

The initial update page may be configured as shown in FIG. 4. In this screen, the user inputs an IP address of the update server, enters a user ID and password for accessing the update server, and then presses the OK button. In step S602, it is checked whether new software exists. The checking method may be a method of downloading each file from the database of the update server 100 and comparing the file with the corresponding file in the database of the target device. Specifically, the update server and target device each have a database file that contains information about their software. As a result, it can be known whether new software exists by downloading the database file on the update server side and comparing it with the database file on the target device side. Upon successful update at the target device, the contents of the database file on the target device side are rewritten with new entries. 5 shows an example of such a database file.

If it is determined that no new software exists in the update server as a result of the check (No in S603), the whole process is terminated as it is. If it is determined that new software exists (YES in S603), a web page showing a list of new software is displayed. In the method for constructing the web page, the database file on the update server side and the database file on the target device side need to be compared and output to the web page only for software having different versions. FIG. 6 is a web page showing a list of such software. For each file, the name of the software, the version information, the directory information where the software is to be stored, and the instructions performed by each software are shown in a table. Appear.

The web page allows the user to decide whether to install new software. Pressing the “cancel” button on the web page completes the entire process without installing any new software. On the other hand, when the ＇install＇ button is pressed, the web server 210 downloads a new file from the update server 100 to the database 230 of the target device 200. If the downloaded file is a compressed file, after decompression, it is copied to a standard folder (S606).

Next, set the value of 〈state〉 to 1 (S607). This value means that the update process begins. Then, an update process is performed (S608). The update process includes reloading new modules and restarting new daemons and applications.

While performing the update process or after completing the update process, it is determined whether the system is crushed (S609), and if a system crash occurs, the process of FIG. 8 is performed.

If a system crash does not occur, a final test is performed on the new file (S610). As a result of the test performance, if the system operates normally, the final test result is 'success', and if it does not operate normally, 'fail'.

If the result is "success" (YES in S611), a new file is copied to a reserved folder (S612). And set 세팅 state ＇to 0 (S613). This value means that the update process has ended. Thereafter, unnecessary temporary files generated through the process are deleted (S614), and a message indicating that the update process is “success” is output to the web page (S615).

On the other hand, if the determination result of the S611 is "fail (meaning that the update has failed, but the system is not stopped)" ＇should rollback to the previous version of the software. Looking at such a rollback process, first copy the existing files from the spare folder to the standard folder (S616). Next, the module is reloaded and the daemon and the application are restarted (S617). The state '＇' is set to a value indicating that the update process is completed, that is, 0 (S618). Thereafter, unnecessary temporary files are deleted (S619). A message indicating that the update process is “fail” is output on the web page (S620).

An example of a web page showing a process of downloading a new file, a process of decompressing a downloaded file, and a process of copying the decompressed file to a standard folder is shown in FIG. In addition, FIG. 7 illustrates a process of reloading newly installed modules for the final test in S610, and a message indicating whether the test result is successful.

8 is a flowchart illustrating a process performed in the Linux system when a system crash occurs during the operation of the present invention. If a system crash occurs, first, the system of the target device 200 is manually restarted (S801). Next, initialization of the system is started by mounting the root file system (S802). In operation S803, a value of “state”, which is the content of a file stored in a predetermined directory, is checked. If the value of 〈state〉 is not 1 (No in S804), it may simply perform the remaining booting process (S809).

However, if the value of 'state' is 1 (YES in S804), a rollback to the previous version of the software should be performed. Looking at the rollback process, first, the existing file is copied from the spare folder to the standard folder (S805). Then, the state value is set to 0 (S806). And delete unnecessary temporary files (S807).

Thereafter, the rest of the booting process is performed (S808). Reloading the module and restarting the daemon and application are included in the booting process and do not need to be executed separately.

9A shows a standard Linux root directory structure. Linux root directory structure according to the present invention is configured as shown in Figure 9b. The shape of the spare directory is the same as that of the standard directory, and the files inside it are the same. You should create a directory where you have copied all the usual folders in the root directory. For example, the '/ bin' folder contains common user commnads, and the '/ sbin' folder contains administrative commands. The lib folder contains loadable moduls. The full path to each of these modules will be something like lib / modules / xx.xx.xx-xx / drivers / .. The usr folder contains daemons (actual path is / usr / sbin). The files in the folder can be updated, and if a normal update is made, respective folders identical to the folder, for example, '/ bin1', '/ sbin1', '/ lib1', and '/ usr1' are generated, respectively. The same files as in the standard folder are copied into the folder of.

Fig. 9C shows a directory structure in which a 〈state〉 file is recorded at a predetermined position of the system. The 〈state〉 file is a flag file that checks whether the previous update process was successful. This check process is performed when the system is booted. The 〈state〉 file may have one of two values. Among the values that the 'state' file may have, '1' means that the previous update is not correct, and '0' means that the previous update is correct.

As such, the command to check the state value of 〈state〉 at system boot is recorded in an initialization startup script that operates at system boot. For example, in Red Hat Linux, the script file is /etc/rc.d/rc.sysinit. If the value of the "state" file is "1", you must copy the previous version of the software from the spare folder to the standard folder. The value is then changed to '0' and the subsequent boot process continues.

Although embodiments of the present invention have been described above with reference to the accompanying drawings, those skilled in the art to which the present invention pertains may implement the present invention in other specific forms without changing the technical spirit or essential features thereof. I can understand that. Therefore, it should be understood that the embodiments described above are exemplary in all respects and not restrictive. The scope of the present invention is indicated by the scope of the following claims rather than the detailed description, and all changes or modifications derived from the meaning and scope of the claims and the equivalent concept are included in the scope of the present invention. Should be interpreted.

According to the present invention, various software in the embedded system can be updated remotely. Such software may include Loadable modules, administrative commands, common user commands, daemons, and other application software.

According to the present invention, when the update process fails in an embedded system or when an incompatible software is installed in a Linux system, the user can return to the old software, and even if the system itself is stopped, the user can return to the old software. .

1 is a block diagram schematically illustrating the overall environment in which the present invention operates.

2 is a flowchart illustrating a process performed in a web server during the operation of the present invention.

3 shows a window requesting authentication for accessing a web server.

4 shows an initial update web page displayed when a web server is connected.

5 shows the format of a database file.

6 shows a web page displaying a list of updatable software.

7 shows a web page showing the update process to the user.

8 is a flowchart illustrating a process performed in the Linux system when a system crash occurs during the operation of the present invention.

9A shows a standard Linux root directory structure.

9b illustrates a Linux root directory structure in accordance with the present invention.

Fig. 9C is a diagram showing a directory structure in which a 〈state〉 file is recorded at a predetermined position of the system.

Claims (6)

A method of remotely updating software of a first device incorporating embedded software in a second device connected to the first device and the Internet, A first step of accessing an initial updated web page provided by a web server of the device by using a web browser on a user side of the second device; A second step of checking whether new software exists in the update server; A third step of performing an update process for the corresponding software when the new software exists as a result of the checking; A fourth step of performing a final test on the newly updated software; A fifth step of copying new files of the updated software to a spare folder if the update is successful, and indicating that the update process was successful on a web page; And And if the update is not successful, returning to the existing system and displaying a failed update process on the web page. The method of claim 1, wherein the second step Downloading the database file on the update server side and comparing the database file on the first device side to remotely update embedded software. The method of claim 1, wherein the third step Downloading a new file from the update server, decompressing it, and copying it to a standard folder; Setting a value of a predetermined file to a value meaning that an update process is started; And Reloading a new module using a new file copied to the standard folder, restarting a new daemon and application, and performing an update. The method of claim 1, wherein the fifth step Copying the new files to a spare folder; Setting a value of a predetermined file to a value meaning that the update process is finished; Deleting unnecessary temporary files created while performing the steps; And A method of remotely updating embedded software, comprising: indicating to a web page that the update process was successful to the user. The method of claim 1, wherein the sixth step Copying the existing files stored in the spare folder to the standard folder; Reloading a new module using the file copied to the standard folder, and rolling back to an existing system by restarting a new daemon and application; Setting a value of a predetermined file to a value meaning that the update process is finished; And And indicating to the user that the update process has failed on the web page. The method of claim 1, wherein if a system crash occurs after performing any one of the above steps, Manually restarting the system of the second device; Checking a value of a predetermined file indicating whether the update process is finished; If the value of the file is a value indicating that the update process is completed, performing the remaining booting process; Copying existing files stored in the spare folder to the standard folder if the value of the file indicates that the update process is not finished; Setting a value of the file to a value indicating that an update process is finished; And Remotely updating the embedded software, characterized in that it further comprises the step of proceeding to the other boot process.