JP2003173260A - Remote program renewal system - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a remote program renewal system capable of increasing efficiency of renewal processing, and capable of securing flexibility of a system program stored in a flash memory on an incorporated apparatus. <P>SOLUTION: A renewal program 40 stored in the flash memory A104 forms a new system program by relinking an object file 10 and a renewal object file 302 on the basis of the renewal object file 302, link definition information 303, and load definition information 304 including a changing part of the system program transmitted via a communication network 200 by a remote host 300, and loads this new system program in a prescribed position. <P>COPYRIGHT: (C)2003,JPO

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to communication with an external host in a built-in device equipped with a nonvolatile storage medium such as a flash memory capable of electrically erasing and rewriting contents and an external communication interface. Via the module replacement part replacement or module reconfiguration function addition to the system program on the non-volatile storage medium,
The present invention relates to a program updating method for deleting.

[0002]

2. Description of the Related Art A control unit of a program in an embedded device is generally a task executed on a single address space. Therefore, the link unit of the system program is usually a batch, and static linking and loading are also performed in the system unit. Therefore, in the embedded device, the execution image of the system program is read in advance in ROMRead.
It is stored in Only Memory, and statically loaded on the main memory at startup and activated.

In recent years, a flash memory is often used as a ROM for storing such a system program. Since the content of the flash memory can be rewritten any number of times by using software in the embedded device, the stored system program can be flexibly updated.

On the other hand, in recent years, even in embedded devices, Jav
The a (registered trademark) execution environment is beginning to be installed. Jav
With a device equipped with a (registered trademark), an application program can be downloaded via a network, which makes it possible to add or update functions online. However, this is intended only for programs that run on the Java (registered trademark) execution environment, and the basic software portion that is premised on static linking or loading cannot be updated.

In a conventional embedded control device, a system program and a flash memory rewriting program are stored in a flash memory, and the flash memory rewriting program expanded on the main memory is input from an external storage device or a program creating device. Some receive a program and update a system program on the flash memory. For example, the microcomputer-embedded control device disclosed in Japanese Patent Laid-Open No. 9-69043 corresponds to this.

Next, the operation will be described. FIG. 37 is a block diagram of a conventional microcomputer-embedded control device. When a signal for instructing to update the system program P1 in the program storage means 2C is input from the input device 4 or the third input / output unit 8 constituting the control device C, it is stored in the program storage means 2C. The copy program P21 is first activated, and the rewrite program P2A also stored in the program storage means 2C is copied to the rewrite program area PA in the data storage means 3C. Then, the control calculation means 1 moves the execution of the program to the head of the rewriting program area PA and activates the rewriting program P2A.

The rewriting program P2A erases the contents of the program storage means 2C, and then the new system program input from the external storage device MA via the second input / output unit 7 or the third input / output unit 8 While accumulating the new system program input from the program creating device PS in the data storage means 3C, writing is performed in the area storing the system program P1 in the program storage means 2C.

As described above, after the rewriting program P2A for updating the system program P1 in the program storage means 2C is copied in the data storage means 3C,
Since the system program P1 is updated, the rewriting program P is stored in the program storage means 2C during this processing.
It is not necessary to secure an area for storing 2A, and the area in the program storage means 2C can be used freely.

[0009]

In the conventional microcomputer built-in control device, a new system is provided from the external storage device MA via the second input / output unit 7 or the program creating device PS via the third input / output unit 8. The system program P1 is updated by receiving the entire program. In this method, since the new system program is generated on another host in advance, the basic software part such as the OS can also be updated. However, the entire new system program must be transferred even if the functions in the system program are deleted or only a part of the system program is modified. Therefore, there is a problem that the program transfer time is long and the program update process cannot be performed flexibly and efficiently.

The present invention has been made to solve the above-mentioned problems, and a file system is formed in one of the nonvolatile storage media on an embedded device, and an object file group of a system program is previously formed in the file system. Is stored. When performing the program update process, the transfer file including the object file including the changed part, the link definition information, and the load definition information is transmitted to the embedded device side, and the embedded device is based on the link definition information and the load definition information. Relink and load the system program above. The purpose of this is to ensure the efficiency and flexibility of the program update process, improve maintainability such as handling software failures, and improve service by function evolution.

[0011]

SUMMARY OF THE INVENTION A first invention is an update object file including a changed part of a system program, and link definition information for relinking the update object file and an object file constituting the system program. And a remote computer for transmitting a transfer file configured by load definition information for loading a new system program via a communication network, the object file, the update object file, the link definition information, and A first flash memory in which load definition information is stored, the update object file of the transfer file in which the system program is stored and transmitted by the remote computer, the link definition information, and the load definition information are forwarded. A file management unit stored in the first flash memory, and the object file and the updated object file stored in the first flash memory are relinked based on the link definition information to generate a new system program. A second flash memory having an update program configured by a link processing unit and a load processing unit that loads the new system program at a predetermined position based on the load definition information is provided.

A second aspect of the present invention determines the validity of the file format or distribution source of the transfer file transmitted by the remote computer, and when the transfer file is valid, further updates the update object file of the transfer file and the link definition information. An update program having an update determination unit that determines the validity of the load definition information; and the update when the update determination unit determines that the update object file, the link definition information, and the load definition information are valid. The file management unit stores an object file, the link definition information, and the load definition information in the first flash memory.

A third aspect of the present invention is an update having a remote computer having an encryption processing unit for encrypting the transfer file and a decryption processing unit for decrypting the transfer file encrypted by the encryption processing unit. And a program.

According to a fourth aspect of the present invention, an update program having a file compression / expansion unit for compressing the update object file of the transfer file transmitted by the remote computer and expanding the compressed update object file, and the file. And a file management unit for storing the updated object file compressed by the compression / expansion unit in the first flash memory.

A fifth aspect of the present invention is a correspondence relationship between the link definition information provided with a link definition information identifier for identifying the object file for which the relinking process has been successful, the system program and an object file constituting the system program. And an update program having an object link table indicating that the object file that matches the link definition information identifier given to the link definition information is not entered in the object link table, the object given to the link definition information is And a link processing unit for adding the information of the object file having the link definition information identifier to the object link table.

According to a sixth aspect of the present invention, a remote computer for transmitting the link definition information via a communication network, and the first flash memory stored on the basis of the link definition information transmitted by the remote computer. And a link processing unit for relinking the object file to generate a new system program.

According to a seventh aspect of the invention, an update program having an object dependency relationship table showing a relationship between the object file and another object file dependent on the object file, and the first flash based on the object dependency table. The update determination unit determines whether or not there is a shortage of the object file stored in the memory, and when there is a shortage, an update determination unit that requests the remote computer to transfer the shortage of the object file.

An eighth invention provides an installation information table for storing installation information of device driver or middleware distribution software, and an installation information stored in the installation information table when installation information is requested by the remote computer. An update program including a main processing unit for transmitting to the remote computer.

A ninth aspect of the invention is a program save processing unit for saving the system program when the new system program is generated, and a program save area for saving the system program saved by the program save processing unit. Is provided with an update program.

A tenth invention comprises a third flash memory for storing an arbitrary system program generated in the past, wherein the second flash memory is a boot in which a start address of the arbitrary system program is stored. The load processing unit includes a selected base address, and the load processing unit, after generating the new system program, sets any system program generated in the past based on the load definition information to the third flash memory or the second flash. It is to be loaded into an arbitrary free area of the memory and the start address of the loaded arbitrary system program is stored in the boot selection base address.

An eleventh aspect of the present invention is an update program having a function selecting section for performing a function selecting process for reconfiguring the system program, and the link processing section, when the function selection by the function selecting section is correct. And a link processing unit that relinks the object file stored in the first flash memory based on the link definition information to generate a new system program.

A twelfth aspect of the present invention is a second flash having a transfer acceptance history table indicating whether or not the updated object file stored in the first flash memory has been used to generate the new system program. The memory, the update program, a first update processing unit for receiving the update object file transmitted by the remote computer, and the unused update program for generating the new system program in the transfer acceptance history table. When an updated object file exists, the object file stored in the first flash memory and the updated object file are relinked based on the link definition information to generate a new system program, and the new system program is generated. The load It is obtained by a patch having a second updating unit for loading a predetermined position on the basis of the definition information.

A thirteenth invention comprises a removable flash memory for storing the object file, and the update program stores device information written in the object file when the removable flash memory is mounted. A device recognition unit for recognizing, and a security inspection unit for judging the validity of the removable flash memory mounted on the basis of the device information recognized by the device recognition unit.

[0024] A fourteenth invention comprises a removable smart card for storing the object file and the update program, and the link processing unit is stored in the first flash memory when the smart card is mounted. And re-linking the object file based on the link definition information to generate a new system program.

A fifteenth invention comprises relocation definition information for relocating the system program in consideration of a page boundary from the load definition information, and the embedded device relocates the system program based on the relocation definition information. It is to be placed.

[0026]

BEST MODE FOR CARRYING OUT THE INVENTION Embodiment 1. FIG. 1 is a configuration diagram of a remote program update system according to the first embodiment. In the figure, 100 is an embedded device, 101 is a CPU, 1
02 is a main memory, 103 is an external communication interface, 10
4 is a flash memory A for storing a system program, 105 is a flash memory B for storing an object file of a system program forming a file system, 106 is a system bus, 10
Is an object file of a system program stored in the flash memory B105, 20 is a system program that performs the original processing as the embedded device 100, and 30 is first when the embedded device 100 is powered on or restarted. A startup program to be started up, an update program 40 for updating the system program 20 stored in the flash memory A 104, 41 a main processing unit of the update program 40, 4
2 is a network communication processing unit, 43 is an update determination unit, 44
Is a file management unit for accessing the flash memory B105, 45 is a link processing unit, and 46 is a load processing unit.

Further, 200 is Ethernet (registered trademark), RS232C, USB (Universal S)
Wired communication such as initial Bus), or Bluetooth
communication network assuming wireless communication such as wireless communication with a mobile phone, 300 is a remote host assuming a personal computer or the like capable of communicating with the embedded device 100 via the communication network 200, and 301 is an HDD (Hard Disk Drive).
e) A storage device assuming the like, 302 is an update object file including a changed portion in the system program 20,
303 relinks the update object file 302,
That is, link definition information for reconfiguring, 304 for load definition information for loading the new system program 20, 305 for a client program for transmitting the update object file 302 to the embedded device 100 side, and 306 for an update object. File 302,
A transfer file generation unit 307 for generating a transfer file from the triple of the link definition information 303 and the load definition information 304 is a network communication processing unit.

Next, the operation will be described. First, in the normal operation mode of the embedded device 100, an explicit instruction by a user using the embedded device 100 or a remote host 3 capable of communicating with the embedded device 100.
00 based on a push-type instruction from the communication network 200, the system program 20 shifts to the update processing mode. Then, the startup program 3
After 0 restarts and initializes the hardware and the like, the update program 40 stored in the flash memory A 104 is expanded to a predetermined address in the main memory 102, and control is transferred to the start address of this program. .

FIG. 2 is a flow chart showing the processing operation of the update program 40. The processing on the update program 40 side in the update processing of the system program 20 will be described with reference to the drawings. First, in the update program 40, the main processing unit 41 sets its own network address in the external communication interface 103 in step S1, and then the network communication processing unit 42 in step S2.
At, the process waits for a connection request from the client program 305. In step S3, the client program 3
When the connection request from 05 arrives and the connection is established, the system waits to receive the transfer file.

When the transfer file is received, step S4
Then, the update judgment unit 43 checks the correctness of the transfer file format, distribution source, etc., and if the transfer file is not correct, notifies the client program 305 of the cause of error in step S5 and discards the received file. Then, the connection is disconnected and the program update process is stopped.

On the other hand, if the transfer file is valid in step S4, the transfer file is disassembled in step S6, and the validity of the version number and the like of the received triplet file is checked. Cancel the program update process. If the triple file is valid in step S6, the file management unit 44 decomposes the updated object file 30 in step S7.
2, link definition information 303, and load definition information 30
4 is stored in the file system in the flash memory B105.

Next, in step S8, the link processing unit 45 executes the object file 10 and the update object file 302 in the flash memory B105 via the file management unit 44 based on the link definition information 303.
Relink is executed to generate the new system program 20. In step S9, the load processing unit 46 uses the new system program 2 based on the load definition information 304.
0 is loaded in a predetermined position on the flash memory A104.

Thereafter, in step S10, the main processing unit 4
Returning to 1, the client program 305 is notified of normal termination, the connection is disconnected, and the processing is terminated. Finally, in step S11, the startup program 30
Then, the new system program 20 stored in the flash memory A104 is expanded to a predetermined address in the main memory 102, and the control is transferred to the start address of this program.

FIG. 3 is a flowchart showing the processing operation of the client program 305. The process of the client program 305 in the system program update process will be described with reference to the drawings. The remote host 300 is assumed to be a remote computer such as a personal computer as a cross development environment, and the initialization of the network interface and the setting of its own network address are completed when the host is started up. In the cross development environment, it is assumed that the source code base of the system program 20 is changed, the function is added, and the like, and a series of software development work such as generation of an execution module and function test is completed. Then, the update object file 302, the link definition information 303, and the load definition information 304 of the software to be updated this time are selected.

The client program 305 is application software that runs on the remote host 300. First, in step S100, the client program 305 requests the embedded device 100 side to shift to the update processing mode. Alternatively, embedded device 1
00, the remote host 300 indicates that the mode has been changed to the update processing mode when an explicit instruction is given by the user.
A system may be used in which the client program 305 on the remote host 300 starts processing upon notification to the user.

In step S101, the transfer file generator 3
At 06, a transfer file is generated from the triplet file. The actual format of the transfer file and the legitimacy information to be included in the transfer file are decided by the update program 40 side and the client program 305 side. In step S102, the network communication processing unit 307
At, the connection connection request is issued on the assumption that the update program 40 is in the connection waiting state.

When the connection with the update program 40 side is established in step S103, the transfer file transmission process is started. When the file transmission processing is completed in step S104, the update program 40 waits for notification of the update processing result. Finally, when the processing result is obtained in step S105, this is stored together with the identifier of the embedded device 100, the connection is disconnected, and the processing ends.

As described above, the client program 3
On the 05 side, the object file 30 including the changed part
2, link definition information 303, and load definition information 304
A transfer file consisting of
Since the system program 20 is re-linked and loaded on the embedded device 100 based on the link definition information 303 and the load definition information 304, the transfer file size (transfer data amount) in the program update process is transmitted. ) Can be significantly reduced. As a result, the program update process can be performed in a very short time as the network communication speed becomes faster (broadband).

Further, since a file system is formed in the flash memory B105 on the embedded device 100 and all the object files 10 for generating the system program 20 are stored in this, a matching of the update object file 302 is performed. The validity and correctness can be checked, and the program update process can be performed safely.
Furthermore, not only addition / change of functions but also unnecessary functions can be easily deleted by relinking, and the system program 20 in the embedded device 100 can be optimized and hardware resources can be effectively allocated.

Embodiment 2. In the first embodiment, the transfer file including the object file 302 including the changed portion, the link definition information 303, and the load definition information 304 is generated on the client program 305 side and transmitted to the update program 40 side. The client program 305 side encrypts the transfer file and transmits the encrypted transfer file, and the update program 40 side is newly provided with a decryption processing unit to decrypt the received transfer file. The morphology is shown.

FIG. 4 is a block diagram of a flash memory A104 according to the second embodiment which is a modification of FIG. In the figure, 47 is a decryption processing unit in the update program 40. FIG. 5 is a configuration diagram of the client program 305 according to the second embodiment which is a modification of FIG. In the figure, 308 is an encryption processing unit that encrypts a transfer file.

Next, the operation will be described. First, similarly to the initial operation in the first embodiment, it is assumed that the program update mode is entered and the update program 40 is activated.

FIG. 6 is a flowchart showing the processing operation of the update program 40 according to the second embodiment which is a modification of FIG. The processing of the update program 40 in the update processing of the system program 20 will be described with reference to the drawings. First, in the update program 40, the main processing unit 41 sets its own network address in the external communication interface 103 in step S1, and then the network communication processing unit 42 waits for a connection request from the client program 305 in step S2. .

In step S3, when a connection request from the client program 305 arrives and a connection is established, a transfer file reception waiting state is entered. When the transfer file is received, the decryption processing unit 47 decrypts the transfer file in step S12. In step S4, the update determination unit 43 checks the legitimacy of the transfer file format, distribution source, etc. If the transfer file is not valid, the client program 305 is notified of the error factor in step S5, and the received file is received. Is discarded, the connection is disconnected, and the program update process is stopped.

On the other hand, if the transfer file is valid in step S4, the transfer file is disassembled in step S6, and the validity of the version number of the received triplet file is checked. Cancel the program update process. If the triple file is valid in step S6, the file management unit 44 decomposes the updated object file 30 in step S7.
2, link definition information 303, and load definition information 30
4 is stored in the file system in the flash memory B105. Subsequent processing after step S8 is the same as in the case of the first embodiment, and will be omitted.

FIG. 7 is a flowchart showing the processing operation of the client program 305. The process of the client program 305 in the system program update process will be described with reference to the drawings. First, step S10
0 means client program 305 is embedded device 1
It requests the 00 side to shift to the update processing mode. In step S101, the transfer file generation unit 306
A transfer file is generated from the triplet file. In step S106, the encryption processing unit 308 encrypts the generated transfer file.

Next, in step S102, the network communication processing unit 307 issues a connection connection request on the assumption that the update program 40 side is in a connection waiting state. When the connection with the update program 40 side is established in step S103, the transfer file transmission process is started. When the file transmission processing is completed in step S104, the update program 40 waits for notification of the update processing result. Finally, when the processing result is obtained in step S105, this is stored together with the identifier of the embedded device 100, the connection is disconnected, and the processing ends.

As described above, the client program 3
The encryption processing unit 308 is provided on the 05 side to encrypt and transfer the transfer file, and the decryption processing unit 47 is provided on the update program 40 side to decrypt the received transfer file. Even in the update process via the open network such as the Internet, it is possible to prevent the fraudulent act such as falsification of the update object file 10 and to safely perform the program update process.

Embodiment 3. In the second embodiment, the security is improved by encrypting the transfer file, but next, a new file compression / decompression unit is provided in the update program 40 to disassemble the transfer file. An embodiment of a program update process in which the created update object file 302 and the like are compressed and then stored in a file system will be described.

FIG. 8 is a block diagram of a flash memory A104 according to the third embodiment which is a modification of FIG. In the figure, numeral 48 indicates an update object file 30 in the file system formed in the flash memory B105.
It is a file compression / decompression unit that compresses / decompresses a file when storing or retrieving 2 or the like.

Next, the operation will be described. First, similarly to the initial operation in the first embodiment, it is assumed that the program update mode is entered and the update program 40 is activated.

FIG. 9 is a flow chart showing the processing operation of the update program 40 in the third embodiment modified from FIG. The processing of the update program 40 in the update processing of the system program 20 will be described with reference to the drawings. First, in the update program 40, the main processing unit 41 sets its own network address in the external communication interface 103 in step S1, and then the network communication processing unit 42 waits for a connection request from the client program 305 in step S2. .

In step S3, when a connection request from the client program 305 arrives and a connection is established, a transfer file reception waiting state is set. When the transfer file is received, the update determination unit 43 checks the validity of the transfer file format and distribution source in step S4. If the transfer file is not valid, the error factor is notified to the client program 305 side in step S5. At the same time, the received file is discarded, the connection is disconnected, and the program update process is stopped.

On the other hand, if the transfer file is valid in step S4, the transfer file is disassembled in step S6, and the validity of the version number of the received triplet file is checked. Cancel the program update process. If the triplet file is valid in step S6, the file compression / decompression unit 48 updates the update object file 302 in step S13.
Compress. In step S7, the file management unit 44 stores the compressed update object file 302, link definition information 303, and load definition information 304 in the file system in the flash memory B105.
In the case of the third embodiment, all the dependent object files 10 other than the update object file 302
Is also stored in the file system in a pre-compressed state.

Next, in step S14, the file compression / decompression unit 48 decompresses the object file 10 retrieved through the file management unit 44. Step S8
Then, in the link processing unit 45, based on the link definition information 303, relinking is executed from the object file 10 and the update object file 302 in the flash memory B 105 via the file management unit 44, and the new system program 20 is generated. In step S9, the load processing unit 46 loads the new system program 20 in a predetermined position on the flash memory A104 based on the load definition information 304.

Thereafter, in step S10, the main processing unit 4
Returning to 1, the client program 305 is notified of normal termination, the connection is disconnected, and the processing is terminated. Finally, in step S11, the startup program 30
Then, the new system program 20 stored in the flash memory A104 is expanded to a predetermined address in the main memory 102, and the control is transferred to the start address of this program.

As described above, since the file compression / decompression unit 48 is provided in the update program 40 to compress and store the update object file 302, a file system is formed for storing the object file 10. It is possible to secure a larger free space in the flash memory B105. As a result, it is possible to store a larger number of object files 10 that are not linked to the current system program 20 but can be re-linked by relinking. Further, the mounting capacity of the flash memory B105 can be suppressed small, and the applicability of the program updating system can be improved even for the embedded device 100 in which the restrictions on the mounted hardware resources are severe.

Fourth Embodiment In the third embodiment, the transferred update object file 302 is compressed and then stored in the file system so that the flash memory B105 can be effectively used. An embodiment of a program update process in which an object link table is newly provided and the link process of the system program 20 is performed based on this management information will be described.

FIG. 10 is a block diagram of a flash memory A104 according to the fourth embodiment which is a modification of FIG. In the figure, 49 is an object link table that manages the correspondence between each function in the system program 20 and the group of object files 10 constituting them.

FIG. 11 shows the object link table 4
It is a block diagram of FIG. In the figure, 50 is a link definition information identifier for identifying the link definition information 303 for which the relinking process has been successful so far, 51 is a link date, and 52 is a function identifier showing a list of functions included in each link definition information 303. A list, 53 is an object file name list showing a list of the object files 10 included in the link definition information 303, and 54 is an object link table entry composed of the four sets.

Next, the operation will be described. First, similarly to the initial operation in the first embodiment, it is assumed that the program update mode is entered and the update program 40 is activated.

FIG. 12 is a flow chart showing the processing operation after the storage processing of the update program 40 in the file system in the modified embodiment 4 of FIG. Figure 2
In the flowchart of the update program 40 shown in
The process up to the storage in the file system in step S7 is the same, and will be omitted. The process of storing the update program 40 in the file system in the update process of the system program 20 will be described with reference to the drawings.

First, in the update program 40, the link definition information 30 is set in the link processing unit 45 in step S8.
3, the re-linking is executed from the object file 10 and the updated object file 302 in the flash memory B105 via the file management unit 44 to generate the new system program 20. In step S15, the object link table 49 is searched. Step S
If the entry that matches the link definition information identifier 50 assigned to the current link definition information 303 is not found in 16, the object link table entry 54 is newly added in step S17, and the link definition information 3
The contents of the function identifier list 52 and the object file name list 53 described in No. 03 are copied.

On the other hand, in addition to the case where an entry matching the link definition information identifier 50 is found, step S18
The link date 51 is updated and set. Next, step S9
Then, the load processing unit 46 loads the new system program 20 at a predetermined position on the flash memory A 104 based on the load definition information 304. After that, in step S10, the process returns to the main processing unit 41, the client program 305 side is notified of the normal end, the connection is disconnected, and the process ends. Finally, in step S11, the control is transferred to the startup program 30, and the new system program 2 stored in the flash memory A104 is stored.
0 is expanded to a predetermined address on the main memory 102, and control is transferred to the start address of this program.

As described above, since the object link table 49 is provided in the update program 40 to store and manage the link update history, the list of currently linked functions can be obtained quickly and accurately. it can.
Further, by saving the past link history, it is possible to relink and load only on the embedded device 100 later.

Embodiment 5. In the fourth embodiment, the link update history relating to the link definition information 303 is stored and managed so that the functions constituting the system program 20 can be managed or reconfigured separately. An embodiment in which only the link definition information 303 is transferred without including the object file 302 will be described.

FIG. 13 is a configuration diagram of a transfer file in the fifth embodiment. In the figure, 55 is header information of the transfer file, and 56 is a part of the header information 55, which is a tag indicating the file type included in the succeeding part of the transfer file. In the case of the fifth embodiment, since there is only the link definition information 303, it is assumed that a flag to that effect is set in the tag 56.

Next, the operation will be described. First, similarly to the initial operation in the first embodiment, it is assumed that the program update mode is entered and the update program 40 is activated.

FIG. 14 is a flow chart showing the processing operation of the update program 40 in the fifth embodiment modified from FIG. The processing of the update program 40 in the update processing of the system program 20 will be described with reference to the drawings.
First, in the update program 40, the main processing unit 41 sets its own network address in the external communication interface 103 in step S1, and then the network communication processing unit 42 waits for a connection request from the client program 305 in step S2. .

In step S3, when the connection request from the client program 305 arrives and the connection is established, the reception of the transfer file is waited. When the transfer file is received, the update determination unit 43 checks the validity of the transfer file format and distribution source in step S4. If the transfer file is not valid, the error factor is notified to the client program 305 side in step S5. At the same time, the received file is discarded, the connection is disconnected, and the program update process is stopped.

On the other hand, if the transfer file is valid in step S4, the tag 56 in the header information 55 of the transfer file is referred to in step S19, and it is checked whether the subsequent file type is only the link definition information 303. . If it is not only the link definition information 303, step S
The legitimacy of the triple file received in 6 is checked, but the processing in this case is the same as in the case of the first embodiment, and a description thereof will be omitted. When the transfer file includes only the link definition information 303, the update determination unit 43 checks the validity of the link definition information 303 in step S20.

If all the object files 10 described in the link definition information 303 are not stored in the flash memory B105, it is determined that the relinking process is impossible and the program updating process is stopped.
If the legitimacy is confirmed, the link processing unit 4 in step S8.
In step 5, based on the link definition information 303, relinking is executed from the object file 10 in the flash memory B 105 via the file management unit 44 to generate the new system program 20. After this, step S9
Subsequent processing is the same as in the case of the first embodiment, and will be omitted.

As described above, the link definition information 30 does not include the update object file 302 in the transfer file.
Since only 3 is transferred, the transfer file size (transfer data amount) in the program update process can be significantly reduced. As a result, the reconfiguration of the system program 20 including the function deletion can be performed in a very short time.

Sixth Embodiment In the fifth embodiment, the transfer file does not include the update object file 302,
The system program 20 can be reconfigured by transferring only the link definition information 303. Next, a module dependency relationship table is newly provided in the update program 40, and the program update processing is performed based on this relationship information. An embodiment of a program update process for performing the above is shown.

FIG. 15 is a block diagram of a flash memory A104 in the sixth embodiment modified from FIG. In the figure, reference numeral 57 is an object dependency relationship table showing the relationship between the object file 10 constituting the system program 20 and another object file dependent on it.

FIG. 16 is a configuration diagram of the object dependency relationship table 57. In the figure, 58 is an object file name, 59 is a dependent object file name list showing a list of object files related to each object file, and 60 is an object dependency relationship table entry composed of the above group.

Next, the operation will be described. First, similarly to the initial operation in the first embodiment, it is assumed that the program update mode is entered and the update program 40 is activated.

FIG. 17 is a flow chart showing the processing operation of the update program 40 in the sixth embodiment modified from FIG. The processing of the update program 40 in the update processing of the system program 20 will be described with reference to the drawings.
First, in the update program 40, the main processing unit 41 sets its own network address in the external communication interface 103 in step S1, and then the network communication processing unit 42 waits for a connection request from the client program 305 in step S2. .

In step S3, when the connection request from the client program 305 arrives and the connection is established, the reception of the transfer file is waited. When the transfer file is received, the update determination unit 43 checks the validity of the transfer file format and distribution source in step S4. If the transfer file is not valid, the error factor is notified to the client program 305 side in step S5. At the same time, the received file is discarded, the connection is disconnected, and the program update process is stopped.

On the other hand, if the transfer file is valid in step S4, the transfer file is disassembled in step S6, and the validity of the version number of the received triplet file is checked. Cancel the program update process. Subsequently, in step S21, the update determination unit 43 causes the object dependency table 5
7, the dependency relation is checked from the dependent object file name list 59 for the object file name 58 entry for each object file 10 described in the link definition information 303.

In step S22, the flash memory B1
It is checked whether the object file 10 stored in 05 is insufficient, and if it is insufficient, step S
At 23, a transfer request for the additional object is issued to the client program 305.

If there is no shortage of object files in step S22, the updated object file 302 including the additional objects is stored in the flash memory B105 in the file management unit 44 in step S7.
Store in the file system inside. Subsequent processing after step S8 is the same as in the case of the first embodiment, and will be omitted.

As described above, since the object dependency table 57 is provided in the update program 40 to check the validity of the dependency between objects,
It is possible to ensure the safety of the program update process.
Further, since the additional transfer is automatically performed if there is a deficient object file 10, the convenience of the program update process can be improved.

Seventh Embodiment In the sixth embodiment, the correctness of the dependency relationship of each object file 10 described in the link definition information 303 in the transfer file is checked, and if there is an insufficient object file 10, an additional transfer is automatically requested. However, next, an embodiment of the program update process in which an installation information table is newly provided in the update program 40 so that the distribution software can be managed will be described.

FIG. 18 is a block diagram of a flash memory A104 according to the seventh embodiment which is a modification of FIG. In the figure, reference numeral 61 is an installation information table for storing and managing installation information of distribution software such as device drivers and middleware. FIG. 19 is a configuration diagram of the installation information table 61. In the figure, 62
Is the object name, 63 is the version number of the object, 64 is the update date, 65 is the link status flag indicating the link status of the object, and 66 is the installation information table entry composed of the above-mentioned four sets.

Next, the operation will be described. First, similarly to the initial operation in the first embodiment, it is assumed that the program update mode is entered and the update program 40 is activated.

FIG. 20 is a flow chart showing the processing operation of the update program 40 in the seventh embodiment modified from FIG. The processing of the update program 40 in the update processing of the system program 20 will be described with reference to the drawings.
First, in the update program 40, the main processing unit 41 sets its own network address in the external communication interface 103 in step S1, and then the network communication processing unit 42 waits for a connection request from the client program 305 in step S2. .

In step S3, when a connection request from the client program 305 arrives and a connection is established, the transfer file waits. When the transfer file is received, the update determination unit 43 checks the validity of the transfer file format and distribution source in step S4. If the transfer file is not valid, the error factor is notified to the client program 305 side in step S5. At the same time, the received file is discarded, the connection is disconnected, and the program update process is stopped.

On the other hand, if the transfer file is valid in step S4, the tag 56 in the header information 55 of the transfer file is referred to in step S24 to check whether the request is for software installation information instead of program update. If it is a request for installation information, step S
In 25, the main processing unit 41 returns the contents of the installation information table 61 to the client program 305 side, disconnects the connection, and ends the processing. If it is not a request for installation information, linking and loading of the new system program 20 are performed and the connection with the client program 305 is disconnected in steps S6 to S10, as in the first embodiment.

Then, in step S26, the main processing unit 4
In 1, add / modify installation information. An entry is newly added to the update object having no entry of the object name 62 in the installation information table 61. For a change object that already has an entry, the version number 63 and update date 64 entries are modified.

Also, for the object deleted from the link of the system program 20, the link status 65
Mark entries as unlinked. Finally, step S1
At 1, the control is transferred to the startup program 30, the new system program 20 stored in the flash memory A 104 is expanded to a predetermined address on the main memory 102, and the control is transferred to the start address of this program.

As described above, the installation information table 61 is provided in the update program 40, and the embedded device 1
Since the list of distribution software installed in the system program 20 on 00 is stored and managed and returned to the remote host side, the installation status of the distribution software supplied by the manufacturer or software vendor can be sent to the remote host. It is possible to manage billing and illegal installation for each distributed software.

Eighth Embodiment In the seventh embodiment, the list of installed distribution software is managed and returned to the remote host side so that the accounting of each distribution software can be managed. An embodiment of a program update process in which a new program save section and a program save area are newly provided so that the old system program can be restored later is shown.

FIG. 21 is a block diagram of a flash memory A104 according to the eighth embodiment modified from FIG. In the figure, 67 is a program save processing unit that saves and restores the old system program 20, and 68 is a program save area for saving the old system program 20.

Next, the operation will be described. First, similarly to the initial operation in the first embodiment, it is assumed that the program update mode is entered and the update program 40 is activated.

FIG. 22 is a flowchart showing the processing operation after the link processing of the update program 40 in the eighth embodiment modified from FIG. The link process of the update program 40 and the subsequent processes in the update process of the system program 20 will be described with reference to the drawings. First, update program 40
Then, after linking the new system program 20 in step S8, the program save processor 6 is linked in step S27.
In 7, the old system program 20 is saved in the program save area 68.

In step S9, the load processing unit 46 loads the new system program 20 in a predetermined position on the flash memory A104 based on the load definition information 304. After this, in step S10, the main processing unit 4
Returning to 1, the client program 305 is notified of normal termination, the connection is disconnected, and the processing is terminated.

Next, in step S11, the control is transferred to the startup program 30, and the flash memory A104
The new system program 20 stored in the main memory 1
02 is expanded to a predetermined address, and control is transferred to the start address of this program. Finally, if the restart of the new system program 20 fails in step S28, the control is transferred to the startup program 30 again, and step S
At 29, the old system program 20 is restarted from the program save area 68.

As described above, the program save processing unit 67 and the program save area 68 are provided in the update program 40, and when the new system program 20 fails to start, the saved old system program 20 is automatically deleted. Since the process is returned to, it is possible to improve the reliability associated with the program update process.

Ninth Embodiment In the eighth embodiment, if the restart of the new system program 20 fails, the saved old system program 20 can be automatically restored. However, next boot selection is newly made in the update program 40. An embodiment of a program update process in which a system address to be restarted can be switched by providing a base address will be described.

FIG. 23 is a block diagram of a flash memory A104 and a new flash memory C according to the ninth embodiment modified from FIG. In the figure, 107 is a new third flash memory C, 69 is an arbitrary system program N, and 70 is a boot selection base address for storing the start address of the system program to be booted when restarted. Here, the arbitrary system program N is a system program generated in the past, and in this case, it is stored in the flash memory C107.

Next, the operation will be described. First, similarly to the initial operation in the first embodiment, it is assumed that the program update mode is entered and the update program 40 is activated.

FIG. 24 is a flowchart showing the processing operation after the link processing of the update program 40 in the embodiment 9 in which FIG. 2 is modified. The link process of the update program 40 and the subsequent processes in the update process of the system program 20 will be described with reference to the drawings. First, update program 40
Then, after linking the new system program 20 in step S8, in step S9, the load processing unit 46 loads the system program N69 into any free area on the flash memory A104 or flash memory C107 based on the load definition information 304. .

In step S30, the top address of the load destination is stored in the boot selection base address 70. afterwards,
In step S10, the connection with the client program 305 is disconnected. Finally, in step S11, control is transferred to the startup program 30, the system program N69 designated by the boot selection base address 70 is expanded to a predetermined address on the main memory 102, and control is transferred to the start address of this program. Note that the arbitrary system program N69 can be started by rewriting the boot selection base address 70 at another timing and means.

As described above, the system program N69
Flash memory A104 and flash memory C10
7, the boot selection base address 70 is provided, and the system program to be restarted can be switched. Therefore, a plurality of system programs 20 are held according to the free space of the flash memory. As a result, the flexibility of replacing the system program can be improved.

Embodiment 10. FIG. In the ninth embodiment, the new system program 20 is loaded in an arbitrary free area of the flash memory C107 or the like so that the system program N69 to be activated can be switched, but next, a mobile phone or a PDA (Personal Digital).
In the embedded device 100 having a user interface such as Assistance), a function selecting unit is newly provided in the update program 40 so that the system program can be reconfigured only on the embedded device 100 without transferring the update object file 302. An embodiment of the program updating process is shown.

FIG. 25 shows a modification of the first embodiment shown in FIG.
FIG. 3 is a configuration diagram of an embedded device 100 in 0. In the figure, 108 is a user interface of the embedded device,
Reference numeral 72 denotes a function selection unit that performs a function selection process for reconfiguring the system program 20 by a user operation.

Next, the operation will be described. FIG. 26 shows an update program 4 according to the tenth embodiment which is a modification of FIG.
It is a flowchart which shows the processing operation of 0. The processing of the update program 40 in the update processing of the system program 20 will be described with reference to the drawings. In the present embodiment, it is assumed that the update program 40 operates in the normal operation mode instead of shifting to the program update mode by restarting the startup program 30 as in the initial operation in the first embodiment.

First, in the update program 40, the function selection section 72 receives the function selection by the user operation via the user interface 108 in step S31. In step S32, all the object files 10 corresponding to the selected function are stored in the flash memory B10.
If it is not stored in 5, the relinking process is determined to be impossible, and a linking process error is displayed in step S33 to notify the user. Further, in step S34, an inquiry is made as to whether or not to perform the function selection again. If the function selection is not continued, the update program 40 is terminated, and if it is continued, the process returns to step S31 to accept the function selection again.

On the other hand, if it is confirmed in step S32 that the function selection is correct, in step S8 the link processing unit 45
In step S 2, based on the link definition information 303, relinking is executed from the object file 10 in the flash memory B 105 via the file management unit 44 to generate the new system program 20. Then, in step S35, the function selecting unit 72 displays that the link processing has been normally completed to notify the user.

In step S9, the load processing unit 46 loads the system program N69 into any free area on the flash memory A104 or flash memory C107 based on the load definition information 304. In step S30, the top address of the load destination is stored in the boot selection base address 70. Finally, in step S11, the control is transferred to the startup program 30, the system program N69 designated by the boot selection base address 70 is expanded to a predetermined address on the main memory 102,
Control is transferred to the start address of this program.

As described above, the user interface 10
8 has a built-in device 100 that does not involve transfer of the update object file 302.
Since the program can be reconfigured only by the above, the function can be customized for each embedded device 100. As a result, when the unnecessary function is deleted, the flash memory A10 storing the system program 20.
It is possible to secure a larger free space of 4 and to allocate the free space to a data storage area for a user, a data file downloaded separately, an address book, and the like.

Eleventh Embodiment In the tenth embodiment, in the embedded device 100 having the user interface 108, the system program 2 is executed only on the embedded device 100 without transferring the update object file 302.
However, in the program update processing, the embedded object 100 is divided into a task that performs transfer acceptance processing of the update object file 302 and a task that performs link and load processing.
An embodiment of a program update process that automatically accepts the transfer of the update object file 302 during the normal operation mode will be described.

FIG. 27 shows a modified embodiment 1 of FIG.
3 is a configuration diagram of a flash memory A104 and a new flash memory C107 in FIG. In the figure, reference numeral 73 indicates the update object file 3 in the program update process.
The update program A, which is an update processing unit for performing the transfer acceptance processing of 02, is a link in the program update processing,
An update program B, which is an update processing unit that performs load processing,
75 is the update object file 30 stored in the flash memory B105 by the update program A73.
3 is a transfer acceptance history table showing a second transfer acceptance history.

FIG. 28 shows the transfer acceptance history table 75.
It is a block diagram of. In the figure, 76 is a link definition information identifier for identifying the transferred link definition information 303, 77 is a transfer acceptance date, 78 is an updated object file name list, 79 is a fixed time or embedded device 100.
In the standby state, the link processing execution condition indicating the timing of the next start, 80 is a link processed flag indicating whether the link processing has been executed after the transfer is accepted, 81 is a transfer acceptance history composed of the above five It is a table entry.

Next, the operation will be described. FIG. 29 shows an update program A according to the eleventh embodiment which is a modification of FIG.
It is a flowchart which shows the processing operation of 73. The processing of the update program A73 in the update processing of the system program 20 will be described with reference to the drawings. The update program A73 exists as one resident task in the system program 20 and is activated at the time of system initialization.

First, in step S1, the main processing unit 41 sets its own network address in the external communication interface 103, and then in step S2, the network communication processing unit 42 waits for a connection request from the client program 305. In step S3, when a connection request from the client program 305 arrives and a connection is established, a transfer file reception waiting state is entered. When the transfer file is received, the update determination unit 43 checks the validity of the transfer file format and distribution source in step S4. If the transfer file is not valid, the error factor is notified to the client program 305 side in step S5. At the same time, the received file is discarded, the connection is disconnected, and the program update process is stopped.

On the other hand, if the transfer file is valid in step S4, the transfer file is disassembled in step S6, and the validity of the version number of the received triplet file is checked. Cancel the program update process. If it is valid in step S6, in the file management unit 44 in step S7, the decomposed update object file 302, the link definition information 303,
And load definition information 304 in the flash memory B10
Stored in the file system in 5.

In step S36, the transfer acceptance history table entry 81 is added, the link processing execution condition 79 is set, and the link processing completed flag 80 entry is marked with no link processing. Finally, in step S10, the process returns to the main processing unit 41, and the client program 305
Side is notified of normal termination, the connection is disconnected, and the processing ends. The processing up to this point is a processing of receiving the update object file 302 once, and the process returns to step S3 to wait for a connection request from the client program 305.

FIG. 30 shows an eleventh embodiment in which FIG. 2 is modified.
14 is a flowchart showing the processing operation of the update program B74 in FIG. Using the figure, the system program 20
The process of the update program B74 in the update process of is described. The update program B74 exists as one task in the system program 20 and is started at the time of system initialization.

First, when the update program B74 is activated, the link processing unit 45 causes the link processing completion flag 8 in the transfer acceptance history table 75 in step S37.
Search for 0 and check if there is an entry marked as not processed. If there is such an entry, in step S38, the link processing execution condition 79 in the transfer acceptance history table 75 is referred to, and it is determined whether the link processing needs to be performed immediately.

If there is no entry for which link processing has not been performed in step S37, or if there is no need to perform link processing immediately in step S38, the update program B is updated in step S39.
74 is put in a standby state. At this time, the link processing execution condition 7
If 9 is set, next update program B74
Set the time to wake up.

On the other hand, if the link processing is to be performed immediately in step S38, the link processing section 45 in step S8 uses the file management section 4 based on the link definition information 303.
The relinking is executed from the object file 10 and the update object file 302 in the flash memory B105 via 4 to generate the new system program 20.

Next, in step S9, the load processing unit 46 loads the new system program 20 in a predetermined position on the flash memory A104 based on the load definition information 304. Finally, in step S11, the control is transferred to the startup program 30, and the flash memory A
The new system program 20 stored in 104 is expanded to a predetermined address on the main memory 102, and control is transferred to the start address of this program.

As described above, in the program update processing, the transfer acceptance processing of the update object file 302 and the link and load processing are divided into tasks, and the former transfer acceptance processing of the update object file 302 is configured as a resident task. Embedded device 1
00 in the steady operation mode, that is, while the new system program is being generated and the new system program is being loaded, the modified object file 302 is sent from the remote host 300 side.
Can be received by push type. As a result, even if the embedded device 100 side does not explicitly request the program update process, it is possible to replace the fault-repair version object of the system program 20 and add or update the service function.

Twelfth Embodiment In the eleventh embodiment, transfer acceptance processing of the update object file 302,
By dividing the link and load processing and dividing it into tasks,
Change object file 30 from the remote host 300 side
However, the object file 10 stored in the file system on the flash memory B105 up to now is not mounted, and it can be dynamically distributed like a compact flash (registered trademark). An embodiment of a program update process in which a removable flash memory is stored in a file system and the new system program 20 is linked and loaded when the flash memory is installed will be described.

FIG. 31 shows a modified embodiment 12 of FIG.
3 is a configuration diagram of a flash memory A104 and a new removable flash memory in FIG. In the figure, 109
Is a dynamically removable flash memory, 76 is a device recognition unit in the update program 40, and 77 is a security inspection unit in the update program 40. The removable flash memory 109 forms a file system, and the object file 10 provided by the manufacturer or vendor is installed in advance.

Next, the operation will be described. 32 shows an update program 4 according to the twelfth embodiment, which is a modification of FIG.
It is a flowchart which shows the processing operation of 0. The processing of the update program 40 in the update processing of the system program 20 will be described with reference to the drawings. In this embodiment, unlike the initial operation in the first embodiment, the program is not changed to the program update mode by restarting the startup program 30, but is updated as one resident task in the system program 20 in the normal operation mode. It is assumed that the program 40 operates.

First, in the update program 40, the device recognition section 76 is in a standby state until the removable flash memory 109 is attached in step S40.
When the removable flash memory 109 is mounted, the device is recognized and the file system is mounted in step S41 so that the object file 10 in the removable flash memory 109 can be accessed.

In step S42, the security inspection unit 77
In step (2), it is checked whether or not the attached removable flash memory 109 includes the object file 10 based on the device information written in a predetermined position in the removable flash memory 109. If it is not justified, it will be immediately discontinued.

On the other hand, if the validity is determined, step S
After linking the new system program 20 in the link processing unit 45 in step 8, the load processing unit 4 in step S9.
In 6, the new system program is loaded as a system program N69 in the free area on the flash memory A104 based on the load definition information 304. In step S30, the top address of the load destination is stored in the boot selection base address 70. In step S43, the device recognition unit 76 causes the removable flash memory 109
Unmount the.

Finally, in step S11, the control is transferred to the start-up program 30, the system program N69 designated by the boot selection base address 70 is expanded to a predetermined address on the main memory 102, and the start address of this program is controlled. Transfer.

As described above, when the dynamically attachable / detachable flash memory 109 is attached, the system program is updated based on the object file 10 stored therein. The program update process can be performed without installing a memory resource such as the flash memory B105 in the embedded device 100 in advance. As a result, the embedded device 10
It is possible to replace the installed software, sell the distributed software, and the like separately from the hardware of 0, and promote the distribution of the software.

Thirteenth Embodiment In the twelfth embodiment, the flash memory B storing the object file 10
When the dynamically attachable / detachable flash memory 109 is mounted without mounting 105, the system file is updated from the object file 10 stored therein. 10 shows an embodiment of program update processing in which the update program 40 and the update program 40 are dynamically mounted on a removable smart card, and when the smart card is installed, the update program 40 is used to perform linking and loading.

FIG. 33 shows a thirteenth embodiment in which FIG. 2 is modified.
2 is a configuration diagram of a flash memory A104 and a new smart card in FIG. In the figure, 110 is a smart card on which the object file 10 and the update program 40 are installed, and 78 is a flash memory D that is in the smart card 78 and forms a file system to store the object file 10. The smart card is a small IC card that has a CPU, a main memory, an I / O device, etc., and can execute a program by itself.

Next, the operation will be described. FIG. 34 shows an update program 4 according to the thirteenth embodiment which is a modification of FIG.
It is a flowchart which shows the processing operation of 0. The processing of the update program 40 in the update processing of the system program 20 will be described with reference to the drawings. In the present embodiment, it is assumed that the embedded device 100 side is in the normal operation mode.

First, when the smart card 110 is attached to the embedded device 100, the update program 40 is activated, the link processing unit 45 links the new system program 20 in step S8, and then the load processing unit 46 in step S9. At, the new system program is loaded as a system program N69 in a predetermined area on the flash memory A104 based on the load definition information 304.

In step S30, the top address of the load destination is stored in the boot selection base address 70. Then, in step S44, the smart card 110 is removed. In response to this, control is transferred to the startup program 30 in step S11, the system program N69 specified by the boot selection base address 70 is expanded to a predetermined address in the main memory 102, and control is performed at the start address of this program. Transfer.

In the present embodiment, the link processing is performed by the update program 40 when the smart card 110 is attached. However, the link processing is separately performed and only the load processing is automatically performed when the smart card 110 is attached. It is also possible to do. Furthermore, a PHS (Personal Handyphone) is installed on the smart card.
e System), mobile phone, wireless LAN, Blue
If the communication module / hardware such as tooth is installed, the update object file 302 is downloaded from the remote host 300 via this communication module, and linked and loaded using the update program 40 on the smart card 110. By performing processing,
Program update processing can also be performed.

As described above, when the dynamically attachable / detachable smart card 110 is installed, the update program 40 installed on this card is activated to update the system program. The program update process can be performed without installing the hardware resource or the update program for the program update process in the embedded device 100 in advance. As a result, the installed software can be replaced and the distributed software can be sold separately from the hardware of the embedded device 100, and the distribution of the software can be promoted. Further, the smart card equipped with the communication module hardware can function as a remote software update device by itself.

Fourteenth Embodiment In the thirteenth embodiment, the flash memory B storing the object file 10
When the dynamically attachable / detachable smart card 110 is mounted without mounting 105, the object file 10 and the update program 40 stored therein are used to update the system program. However, next, in the embedded device 100 equipped with the hardware that supports the memory protection mechanism, the relocation definition information defining the protection policy for each program or each task is provided, and the relocation on the memory is considered. An embodiment of a program update process is shown.

FIG. 35 shows a modified embodiment 14 of FIG.
3 is a configuration diagram of a flash memory A104 in FIG. In the figure, 79 is rearrangement definition information for rearranging the load definition information in consideration of page boundaries and the like.

Next, the operation will be described. First, similarly to the initial operation in the first embodiment, it is assumed that the program update mode is entered and the update program 40 is activated.

FIG. 36 shows a modified embodiment 14 of FIG.
5 is a flowchart showing a processing operation after the link processing of the update program 40 in FIG. In the flowchart of the update program 40 shown in FIG. 2, the process up to the linking process of step S8 is the same, and therefore will be omitted. Using the figure,
The link process of the update program 40 in the update process of the system program 20 and subsequent steps will be described.

First, in the update program 40, the relocation definition information 7 is set in the load processing unit 46 in step S45.
Based on No. 9, the rearrangement is performed from the information described in the load definition information 304 in consideration of page boundary and the like. Step S9
Then, the new system program 20 is stored in the flash memory
Load in place on 04.

Thereafter, in step S10, the main processing unit 4
Returning to 1, the client program 305 is notified of normal termination, the connection is disconnected, and the processing is terminated. Finally, in step S11, the startup program 30
Then, the new system program 20 stored in the flash memory A104 is expanded to a predetermined address in the main memory 102, and the control is transferred to the start address of this program.

As described above, in the embedded device 100 equipped with the hardware supporting the memory protection mechanism, the rearrangement is performed in consideration of the page boundary and the like, so that the functional configuration of the new system program is changed. Even in this case, the system program 20 can be relocated safely. This makes it possible to maintain the reliability of the updated software and ensure the analyticity in the event of a failure.

[0148]

Since the present invention is constructed as described above, it has the following effects.

In the first invention, the update program stored in the flash memory is based on the update object file including the changed portion of the system program transmitted by the remote computer through the communication network, the link definition information and the load definition information. By relinking the object file with the updated object file to generate a new system program and loading this new system program at a predetermined position, the transfer data amount in the program update process can be significantly reduced. The program update process can be performed in a very short time

In the second invention, the file format of the transfer file transmitted by the remote computer or the correctness of the distribution source is judged, and when the transfer file is updated, the update object file of the transfer file, the link definition information and the load definition information Since the validity of the update object file, the link definition information, and the load definition information can be checked by determining the validity, the program update process can be performed safely.

In the third invention, the transfer file encrypted by the encryption processing unit is transmitted by the remote computer, and the encrypted transfer file is decrypted by the update program to tamper with the update object file, etc. Since it is possible to prevent the fraudulent activity, it is possible to safely perform the program update process.

In the fourth aspect of the present invention, the free space of the flash memory can be secured by compressing the update object file of the transfer file transmitted by the remote computer and expanding the compressed update object file.

In the fifth invention, the link processing unit, when the object file that matches the link definition information identifier given to the link definition information is not entered in the object link table, the link definition given to the link definition information. By adding the information of the object file of the information identifier to the object link table, the link update history can be saved and managed, and the list of linked functions can be obtained quickly and accurately.

In the sixth invention, the link processing unit relinks the object file stored in the first flash memory based on the link definition information transmitted by the remote computer to generate a new system program. The amount of transfer data in the program update process can be greatly reduced.

In the seventh invention, is there a shortage of object files stored in the first flash memory based on the object dependency relationship table showing the relationship between the object file and another object file that depends on this object file? It is possible to check the validity of the dependency between objects by determining whether or not there is a shortage and requesting the transfer of the insufficient object file to the remote computer, thus ensuring the safety of the program update process. be able to.

According to the eighth aspect of the invention, when the remote computer requests installation information, the installation information of the device driver or middleware distribution software stored in the installation information table is transmitted to the remote computer to install the distribution software. Since the situation can be grasped by the remote computer, it is possible to manage billing and illegal installation for each distributed software.

In the ninth invention, the system program is saved in the program save area when the new system program is generated, so that when the new system program fails to start, the saved old system program is automatically saved. The reliability of the program update process can be improved because the process is returned to.

In the tenth invention, after the load processing section generates a new system program, an arbitrary system program generated in the past based on the load definition information is stored in the third flash memory or the second flash memory. By loading to the free space and storing the start address of this loaded system program in the boot selection base address, multiple system programs can be held according to the free space of the flash memory. The flexibility of program replacement can be improved.

According to the eleventh aspect, when the function selection by the function selection unit for performing the function selection processing for reconstructing the system program is correct, the object file stored in the first flash memory is stored based on the link definition information. By relinking and generating the system program, the program can be reconfigured only on the flash memory, so that the function can be customized for each embedded device in which the flash memory is mounted.

In the twelfth aspect of the invention, the update program includes a first update processing unit for receiving the update object file transmitted by the remote computer, and an unused program for generating a new system program in the transfer acceptance history table. When the update object file exists, the new system program is generated by relinking the object file stored in the first flash memory and the update object file based on the link definition information,
A new system program is generated by loading the new system program at a predetermined position based on the load definition information, and while the new system program is being loaded,
The modified object file can be delivered from the remote computer side.

According to the thirteenth invention, when the removable flash memory is mounted, the device information described in the object file is recognized, and based on the recognized device information, the validity of the mounted removable flash memory is verified. By determining the sex, it is possible to update the program without installing memory resources in the flash memory in advance.

In the fourteenth invention, when the smart card is installed, the object file is relinked based on the link definition information stored in the first flash memory to generate the new system program, thereby performing the program update process. The program update process can be performed without pre-installing the hardware resources and the update program for.

In the fifteenth invention, the system program is relocated based on the relocation definition information in which the page boundary is taken into consideration from the load definition information, so that the system program can be relocated safely. it can.

[Brief description of drawings]

FIG. 1 is a configuration diagram of a remote program updating system according to a first embodiment.

FIG. 2 is a flowchart showing a processing operation of an update program 40 according to the first embodiment.

FIG. 3 is a flowchart showing a processing operation of a client program 305 according to the first embodiment.

FIG. 4 shows a flash memory A1 according to the second embodiment.
The block diagram of 04.

FIG. 5 is a configuration diagram of a client program 305 according to the second embodiment.

FIG. 6 is a flowchart showing the processing operation of an update program 40 according to the second embodiment.

FIG. 7 is a flowchart showing a processing operation of a client program 305 according to the second embodiment.

FIG. 8 shows a flash memory A1 according to the third embodiment.
The block diagram of 04.

FIG. 9 is a flowchart showing the processing operation of an update program 40 according to the third embodiment.

FIG. 10 shows a flash memory A according to the fourth embodiment.
The block diagram of 104.

FIG. 11 is a configuration diagram of an object link table 49 according to the fourth embodiment.

FIG. 12 is an update program 40 according to the fourth embodiment.
5 is a flowchart showing the processing operation after the storage processing in the file system.

FIG. 13 is a configuration diagram of a transfer file according to the fifth embodiment.

FIG. 14 is an update program 40 according to the fifth embodiment.
3 is a flowchart showing the processing operation of FIG.

FIG. 15 shows a flash memory A according to the sixth embodiment.
The block diagram of 104.

FIG. 16 is a configuration diagram of an object dependency relationship table 57 according to the sixth embodiment.

FIG. 17 is an update program 40 according to the sixth embodiment.
3 is a flowchart showing the processing operation of FIG.

FIG. 18 shows a flash memory A according to the seventh embodiment.
The block diagram of 104.

FIG. 19 is a configuration diagram of an installation information table 61 according to the seventh embodiment.

FIG. 20 is an update program 40 according to the seventh embodiment.
3 is a flowchart showing the processing operation of FIG.

FIG. 21 shows a flash memory A according to the eighth embodiment.
The block diagram of 104.

FIG. 22 is an update program 40 according to the eighth embodiment.
5 is a flowchart showing the processing operation after the link processing of FIG.

FIG. 23 shows a flash memory A according to the ninth embodiment.
10 is a configuration diagram of 104 and a new flash memory C. FIG.

FIG. 24 is an update program 40 according to the ninth embodiment.
5 is a flowchart showing the processing operation after the link processing of FIG.

FIG. 25 shows the embedded device 10 according to the tenth embodiment.
The block diagram of 0.

FIG. 26 is an update program 4 according to the tenth embodiment.
The flowchart which shows the processing operation of 0.

FIG. 27 is a configuration diagram of a flash memory A104 and a new flash memory C107 according to the eleventh embodiment.

FIG. 28 is a configuration diagram of a transfer acceptance history table 75 according to the eleventh embodiment.

FIG. 29 is an update program A according to the eleventh embodiment.
The flowchart which shows the processing operation of 73.

FIG. 30 is an update program B according to the eleventh embodiment.
The flowchart which shows the processing operation of 74.

FIG. 31 is a configuration diagram of a flash memory A104 and a new removable flash memory 109 according to the twelfth embodiment.

FIG. 32 is an update program 4 according to the twelfth embodiment.
The flowchart which shows the processing operation of 0.

FIG. 33 is a configuration diagram of a flash memory A104 and a new smart card according to the thirteenth embodiment.

FIG. 34 is an update program 4 according to the thirteenth embodiment.
The flowchart which shows the processing operation of 0.

FIG. 35 is a configuration diagram of a flash memory A104 according to the fourteenth embodiment.

FIG. 36 is an update program 4 according to the fourteenth embodiment
The flowchart which shows the process operation after the link process of 0.

FIG. 37 is a configuration diagram of a conventional microcomputer-embedded control device.

[Explanation of symbols]

10 object file, 20 system program, 30 startup program, 40 update program, 41 main processing unit, 42 network communication processing unit, 43 update determination unit, 44 file management unit, 4
5 link processing unit, 46 load processing unit, 100 embedded device, 101 CPU, 102 main memory, 103
External communication interface, 104 flash memory A, 105 flash memory B, 106 system bus.

Claims (15)

[Claims] 1. An update object file including a changed portion of a system program, link definition information for relinking the update object file and an object file constituting the system program, and a new system program for loading. A remote computer for transmitting a transfer file configured by load definition information via a communication network; a first object storing the object file, the updated object file, the link definition information, and the load definition information; Flash memory, the system program is stored, and the update object file of the transfer file transmitted by the remote computer, the link definition information, and the load definition information are stored in the first flash memory. File management unit and the first on the basis of the link definition information
A link processing unit that relinks the object file and the updated object file stored in the flash memory to generate a new system program, and loads the new system program at a predetermined position based on the load definition information. A second flash memory having an update program configured by a load processing unit, and a remote program update system. 2. The update program determines the legitimacy of the file format or distribution source of the transfer file transmitted by the remote computer, and when it is legitimate, the update object file and the link definition information of the transfer file are further determined. And an update determination unit that determines the validity of the load definition information, and the file management unit determines that the update object file, the link definition information, and the load definition information are valid by the update determination unit. 2. The remote program update system according to claim 1, wherein the update object file, the link definition information, and the load definition information are stored in the first flash memory at times. 3. The remote computer comprises an encryption processing unit for encrypting the transfer file, and the update program decrypts the transfer file encrypted by the encryption processing unit. The remote program update system according to claim 1, further comprising: 4. The update program includes a file compression / expansion unit that compresses the update object file of the transfer file transmitted by the remote computer and expands the compressed update object file. Stores the updated object file compressed by the file compression / expansion unit in the first flash memory.
The described remote program update system. 5. The link definition information is provided with a link definition information identifier for identifying the object file for which relinking has succeeded, and the update program includes the system program and an object file constituting the system program. An object link table showing a correspondence relationship is provided, and the link processing unit, when the object file matching the link definition information identifier given to the link definition information is not entered in the object link table, the link definition information 3. The remote program updating system according to claim 2, wherein the information of the object file of the link definition information identifier given to the object is added to the object link table. 6. The remote computer transmits the link definition information via a communication network, and the link processing unit stores the link definition information in the first flash memory based on the link definition information transmitted by the remote computer. 3. The remote program update system according to claim 2, wherein the stored object files are relinked to generate a new system program. 7. The update program includes an object dependency relationship table that indicates a relationship between the object file and another object file that depends on the object file, and the update determination unit uses the object dependency relationship table based on the object dependency relationship table. 3. The method according to claim 2, wherein it is determined whether or not the object file stored in the first flash memory is insufficient, and when the object file is insufficient, the remote computer is requested to transfer the insufficient object file. Remote program update system. 8. The update program includes an installation information table for storing installation information of device driver or middleware distribution software, and installation information stored in the installation information table when installation information is requested by the remote computer. 3. The remote program updating system according to claim 2, further comprising: a main processing unit that transmits to the remote computer. 9. The update program includes a program save processing unit that saves the system program when the new system program is generated, and a program save area that saves the system program saved by the program save processing unit. The remote program updating system according to claim 2, further comprising: 10. A third flash memory for storing an arbitrary system program generated in the past, wherein the second flash memory has a boot selection base address in which a start address of the arbitrary system program is stored. The load processing unit may generate, after generating the new system program, an arbitrary system program generated in the past based on the load definition information in the third flash memory or the second flash memory. 3. The remote program update system according to claim 2, wherein the remote program update system is loaded in an empty area and the start address of the loaded arbitrary system program is stored in the boot selection base address. 11. The update program includes a function selection unit that performs a function selection process for reconfiguring the system program, and the link processing unit, when the function selection by the function selection unit is correct, the link definition. 3. The remote program updating system according to claim 2, wherein the object file stored in the first flash memory is relinked based on the information to generate a new system program. 12. The second flash memory comprises a transfer acceptance history table indicating whether or not the updated object file stored in the first flash memory was used to generate the new system program. The update program includes a first update processing unit that receives the update object file transmitted by the remote computer, and the unused update object for generating the new system program in the transfer acceptance history table. When the file exists, the object file stored in the first flash memory and the updated object file are relinked based on the link definition information to generate a new system program, and the new system program is stored in the new system program. Load definition information Remote program update system according to claim 2, characterized in that and a second updating unit for loading a predetermined position on the basis. 13. A device recognition device, comprising: a removable flash memory for storing the object file, wherein the update program recognizes device information written in the object file when the removable flash memory is installed. 3. The security check unit according to claim 2, further comprising: a security check unit configured to determine the validity of the removable flash memory attached based on the device information recognized by the device recognition unit. Remote program update system. 14. A removable smart card for storing the object file and an update program, wherein the link processing unit stores the link definition stored in the first flash memory when the smart card is attached. The remote program updating system according to claim 2, wherein the object file is relinked based on the information to generate a new system program. 15. The apparatus includes relocation definition information for relocating the system program in consideration of a page boundary from the load definition information, wherein the embedded device relocates the system program based on the relocation definition information. Claim 2 characterized by the above-mentioned.
The described remote program update system.