JP2012198929A - Information processing device - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a program update method capable of restoring an operation at normal state even when update processing of a program has failed.SOLUTION: An information processing device comprises: an auxiliary storage device storing a program of a version at shipment from a factory and a program of a first version; a main storage device holding the program of the first version; and a CPU starting the program of the first version stored in the main storage device at power-on. If there is an error in the program of the first version stored in the main storage device and if the program of the first version stored in the main storage device has aborted operations for a predetermined number of times or more, the CPU loads the program of the first version stored in the auxiliary storage onto the main storage device. When loading of the program of the first version stored in the main storage device has failed for a predetermined number of times or more, the CPU loads the program of the version at shipment from the factory stored in the auxiliary storage device onto the main storage device.

Description

  The present invention relates to a program update process.

  An in-vehicle device or the like equipped with a car navigation system needs to update an application program such as map information in accordance with, for example, the establishment of a new road. For example, there are the following two methods for updating a program (hereinafter collectively referred to as a program) including an on-board unit operating system and application programs.

(1) Implementation of update processing by an expert A user who owns an on-vehicle device sends a hard disk (hereinafter referred to as HDD (Hard Dis) to the manufacturer.
kDrive)) or the vehicle-mounted device itself, and the manufacturer performs a program update process. Alternatively, it is a method in which a car sales agent is entrusted to a car dealer and the salesperson performs a program update process.

  In this method, since an expert performs a program update process, the procedure and means of the program update process can be freely implemented to some extent. For example, the following points can be given as the advantages in the execution of the update process by an expert.

  (1) It is possible to freely select a program to be updated from individual program update to update of all programs. (2) A dedicated connection device such as a jig used for program update processing can be used. It is also possible to disassemble the device and take out the storage medium. If you fail to update the program, you can start over. (3) Data backup can be taken. (4) It is also possible to return to the factory default by recovery.

  In addition to the above-described advantages of the program update process performed by an expert, for example, there are also the following drawbacks.

  (1) It takes time and effort for the user to send the vehicle-mounted device or HDD to the manufacturer, or to go to the dealer and leave the car. (2) The user cannot use the car navigation system while depositing the vehicle-mounted device, the HDD, or the automobile. (3) Work contents that can only be done by professionals, such as using dedicated jigs and disassembling equipment.

(2) Implementation of update process by user CD-ROM (Compact Disk-Read Only Memory) or DV
This is a method in which a user himself / herself executes an update process of a program using an update program stored in a D-ROM (digital Versatile disc) and other storage media. Alternatively, the update function is downloaded by communication with the outside using a communication function of a mobile phone or an in-vehicle device, and the user himself / herself executes the program update process. Advantages in the execution of the update process by the user include the following points, for example.

  (1) Since it can be carried out by the user himself / herself, there is no need to send the HDD to the manufacturer or leave the car at the store.

  In addition to the above advantages of the program update process performed by the user, there are also the following drawbacks.

  (2) Since the vehicle-mounted device does not have a return means, in the worst case, when the program update process fails, there is a possibility of being unable to start up. (2) When using a CD-ROM or DVD-ROM, it takes time to obtain them. (3) When the update program data is downloaded using the communication function of the mobile phone or the vehicle-mounted device, a communication amount such as a packet fee is generated. If the data to be downloaded is large, the communication fee will be high and it will take time.

  In the program update processing method by the user, a serious drawback is that there is a possibility that the program cannot be restored if the program update processing fails. As a cause of the failure of the program update process, for example, a power interruption during the program update process (such as turning off the accessory power supply of an automobile) can be considered.

  Therefore, there has been a demand for a program update method that allows a user to update a program and that has a return means when the update fails.

JP 2006-301960 A

  It is an object of the present invention to provide a program update method capable of returning to normal operation even when program update processing fails.

The present invention employs the following means in order to solve the above problems. That is, the program update device includes a first storage unit that stores the first version of the program,
A second storage unit that stores the second version of the program that is the same as or newer than the first version;
An acquisition unit that acquires a difference between the second version of the program and a third version of the program that is newer than the second version of the program;
The third version program is generated from the second version program stored in the second storage unit and the difference acquired by the acquisition unit, and the generated third version program is stored in the first version program. And an update unit stored in the storage unit.

  According to the present invention, the first version program stored in the first storage unit is updated to the third version program, while the second version program is held in the second storage unit. to continue. For example, in the step of generating the third version of the program or the step of storing the third version of the program in the first storage unit, the second version of the program is retained even when the power of the computer is cut off. Since it continues, it is possible to return using the second version of the program.

An aspect of the present invention provides an auxiliary storage device that stores a factory-installed version program and a first version of the program that is newer than the factory-installed version;
A main storage for holding the first version of the program loaded from the auxiliary storage;
A CPU that activates a first version of the program held in the main storage device when the power is turned on,
The CPU
When there is an error in the first version of the program held in the main storage device, and the first version of the program held in the main storage device operates a predetermined number of times before the power is turned on this time If the program is interrupted, the first version of the program stored in the auxiliary storage device is loaded into the main storage device,
If the first version of the program stored in the main storage device has failed to load more than a predetermined number of times before the power is turned on this time, the initial version program stored in the auxiliary storage device A version of the program is loaded into the main storage device.

  According to the present invention, even when an abnormality occurs in the first version of the program data loaded in the main storage device, the loading of the first version of the program from the auxiliary storage device is executed again to return to the normal state. Can return. Further, even when loading of the first version of the program from the auxiliary storage device fails, the device can be activated using the factory-installed version of the program. In this way, since the processing is performed in stages, the recovery processing can be performed more efficiently. Finally, the start-up of the apparatus is guaranteed by the version program at the time of factory shipment.

  According to the present invention, it is possible to provide a program update method capable of returning to a normal operation even when a program update process fails.

It is a figure which shows the structural example of a program update system. It is a figure which shows the operation example in the program update process of a program update system. It is a figure shown about the example of reset operation | movement when a power failure generate | occur | produces during a program update process. It is a figure shown about the example of reset operation | movement when a power failure generate | occur | produces during a program update process. It is a figure which shows the example of the value of the boot flag in FROM. It is a figure which shows the example of holding | maintenance of the recovery data of onboard equipment. It is a figure which shows the example of the flow of starting operation | movement at the time of normal. It is a figure which shows the example of a starting sequence. It is a figure which shows the example of the flow of the process performed by the sequence A at the time of abnormality. It is a figure which shows the processing flow of the sequence A at the time of abnormality. It is a figure which shows the process performed by the sequence B at the time of abnormality. It is a figure which shows the processing flow of the sequence B at the time of abnormality.

  Hereinafter, embodiments of the present invention will be described with reference to the drawings. The configuration of the following embodiment is an exemplification, and the present invention is not limited to the configuration of the embodiment.

<First Embodiment>
The program update method of the present invention holds two folders (hereinafter referred to as program folders) for storing the same program group in one storage medium of the device. In the program update process, the program group in one program folder is updated, and the program group in the other program folder is retained as a backup.

By executing the program update process alternately for the two program folders, one program folder can update the program group and hold the latest version of the program group. The other program folder can hold a version of the program group used until immediately before the update process. If the latest version of the program (updated program) does not work after the program update process, select the program folder that did not perform the program update process (as a backup) and start the program It becomes possible.

<Configuration example of program update system>
FIG. 1 is a diagram illustrating a configuration example of a program update system. The program update system includes an in-vehicle device 1 and a center C1 that holds an update program, for example, a server of a manufacturer.

  The center C1 is, for example, a server such as a manufacturer of a program installed in the vehicle-mounted device 1. The center C1 transmits program update information. The center C1 includes a version comparison unit C2. The version comparison unit C2 compares the version of the program installed in the vehicle-mounted device 1 with the latest version of the program held by the center C1, and generates difference data.

  The vehicle-mounted device 1 is a device including a car navigation system mounted on a user's automobile. The vehicle-mounted device 1 includes a mobile phone / DCM (Data Communication Module) 2, a master device 3, a slave device 4, and a deck 5.

The mobile phone / DCM2 is an interface that performs wireless communication with the external center C1.
Some on-vehicle devices equipped with a car navigation system connect to a mobile phone (with a dedicated cable or the like) and download the difference data of the program using the communication function of the mobile phone. There is also a model equipped with a communication device dedicated to the vehicle-mounted device called DCM. In FIG. 1, as a communication interface with the center C1, an interface with a mobile phone and DCM are collectively displayed as a mobile phone / DCM2.

The deck 5 is a device that reads program update data from an external storage medium such as a CD (Compact Disk) or a DVD (Digital Versatile Disc).

  The master device 3 includes at least one microcomputer (hereinafter referred to as “microcomputer”), and is a device that exists in the vehicle-mounted device 1 and plays a central role in organizing the slave devices 4. A control computer dedicated to the vehicle-mounted device such as the master device 3 may be referred to as an ECU (Electronic Control Unit).

The master device 3 includes a communication unit 31, a download selection unit 32, a version information collection unit 33, a program update unit 34, a slave communication unit 35, a HDD (Hard Disk Drive) 36, and a DRAM (Dynamic Random Access Memory).
y) 37 and FROM (Flash Read Only Memory) 38 are provided.

  The communication unit 31 (corresponding to “acquisition unit”) communicates with the mobile phone / DCM 2 or the deck 5. The communication unit 31 receives the update data through the mobile phone / DCM 2 or the deck 5 and stores it in the HDD 36.

  The download selection unit 32 selects whether to download update data from the mobile phone / DCM 2 or the deck 5. For example, the download selection unit 32 detects that a CD or DVD has been inserted into the deck 5 and selects to download update data from the deck 5.

  The version information collection unit 33 manages the version of the program installed in the current master device 3.

  The program update unit 34 (corresponding to an “update unit”) actually performs a program update process from the downloaded update data. Details of the program update unit 34 will be described later.

  The slave communication unit 35 is connected to the slave device 4 to perform communication. The master device 3 and the slave device 4 are connected by, for example, LAN (Local Area Network) wiring or bus connection.

  The HDD 36 is an auxiliary storage device that stores programs executed on the vehicle-mounted device 1 and related data. In FIG. 1, the master device 3 includes an HDD 36. The HDD 36 may be provided in the vehicle-mounted device 1 independently of the master device 2 and the slave device 4.

  The DRAM 37 is a main storage device. The DRAM 37 stores a loader program that loads a program stored in the HDD 36. The loader program develops program data stored in the HDD 36 on the DRAM 37 when a certain program is started.

  The FROM 38 is a nonvolatile storage device. The FROM 38 stores a boot program and a boot flag. The boot program is a program that stores a startup process when the vehicle-mounted device 1 is started up by turning on the power. The boot flag holds a flag indicating a program folder in which a program is loaded. Details will be described later.

  Each of the slave devices 4 performs a unique function. Examples of the slave device 4 include a digital TV device and a DVD playback device. The number of slave devices 4 provided varies depending on the specifications of the vehicle-mounted device 1.

  Among the slave devices 4, for example, when the amount of data to be handled is large, such as a digital television device, the load on one microcomputer increases, so a plurality of microcomputers may be provided. When the slave device 4 includes a plurality of microcomputers, one microcomputer among the plurality of microcomputers is divided into a parent microcomputer and the other microcomputers are divided into child microcomputers. The child microcomputer receives the update data from the master device through the parent microcomputer.

The slave device 4 has a device communication unit 41 1, a program update unit 412, and a version information collection unit 413 in common. In the slave device 4 having a plurality of microcomputers, the parent microcomputer has a device communication unit 411, a program update unit 412, and a version information collection unit 413. When the slave device 4 includes a plurality of microcomputers, each of the parent microcomputer and the child microcomputer includes a communication unit for communicating with each other. The child microcomputer includes a communication unit 421 and a program update unit 422 which are communication interfaces with the parent microcomputer.

  The device communication unit 411 is an interface connected to the master device 3. The device communication unit 411 is connected to the master device 3 by, for example, LAN wiring or bus connection.

The version information collection unit 413 manages version information of programs used by the parent microcomputer and the child microcomputer in the slave device 4. The version information collection unit 413 compares the update data of the program downloaded by the master device 3 with the version of the program executed by the slave device.

  The program update unit 412 and the program update unit 422 perform program update processing for each of the parent microcomputer and the child microcomputer of the slave device 4 from the update data downloaded by the master device 3. The program update unit 412 and the program update unit 422 will be described later.

  The communication unit 31, the download selection unit 32, the version information collection unit 33, the program update unit 34, and the slave communication unit 35 of the master device 3 are a CPU (Central Processing Unit) of the microcomputer included in the master device 3, and respective functional units. This is realized by an IC chip including a dedicated electronic circuit. The device communication unit 411, the program update units 412, 422, the version information collection unit 413, the communication units 414, 422 of the slave device 4 are a CPU of a parent microcomputer and a child microcomputer included in the slave device 4, an IC chip including an electronic circuit, etc. It is realized with.

<Operation example of program update system>
FIG. 2 is a diagram illustrating an operation example in the program update process of the program update system. In FIG. 2, a case where the master device 3 executes the program update process will be described as an example. An update folder, a program folder A, and a program folder B are set in the HDD 36. The update folder stores files related to program updates. In the program folder A and the program folder B, all programs (hereinafter referred to as a program group) used by the master device 3 are stored. In FIG. 2, a program group of version 2 is stored in the program folder A, and a program group of version 1 older than the version of the program group stored in the program folder A is stored in the program folder B. Explain that it is.

  The program update unit 34 of the master device 3 creates a management file in the update folder of the HDD 36 (OP1). At this point, the management file is empty.

  The download selection unit 32 selects whether to download from the mobile phone / DCM 2 or to read the update data from the deck 5 and gives an instruction to the communication unit 41. The communication unit 41 selects the one instructed by the download selection unit 32 and downloads the difference data file (OP2). The downloaded difference data file is stored in the update folder of the HDD 36.

  The difference data is the difference data between the program held in the center C1 or an external storage medium such as a CD and a DVD and the program group of the latest version of the program group stored in the program folder A or the program folder B. . The version information collection unit 33 manages the versions of the program groups stored in the program folder A and the program folder B. When downloading difference data from the center C1 via the mobile phone / DCM2, the latest version among the versions managed by the version information collecting unit 33 is notified to the center C1, and the latest version of the program is updated in the center C1. Generate difference data. When acquiring differential data from an external storage medium such as a CD-ROM / DVD-ROM via the deck 5, the communication unit 31 has the latest version of the versions managed by the version information collection unit 33. Only the difference between the program and the version of the program stored in the external storage medium is read.

When the saving of the difference data file in the update folder is completed, the program update unit 34 records the downloaded difference data in the management file (OP3). The recording method to the management file is, for example, “Downloaded difference data in the management file”
Set "Differential data download flag".

  Next, the program update unit 34 divides the downloaded difference data file into difference data files for each module (OP4). When the program update unit 34 generates the difference data file for each module, the program update unit 34 records that the file has already been divided in the management file (OP5). As a recording method in the management file, for example, a “file division flag” indicating that the file has been divided in the management file is set.

  The program update unit 34 checks the boot flag in the FROM 38 and determines a program folder to be updated (OP6). The boot flag holds a flag indicating which of the program folder A or the program folder B is currently valid. For example, assume that the program folder A is currently valid. When the program folder A is currently valid, it indicates that the program group stored in the program folder A is the latest version of the program installed in the master device 3. Accordingly, when the program folder A is a currently valid folder in the boot flag, the program update unit 34 determines the program folder B that stores the older version of the program group as the update target folder.

  The program update unit 34 deletes all the files stored in the program folder B to be updated (OP7). The program update unit 34 newly generates a program file in the program folder B from the file in the program folder A that is not the update target and the difference data file (OP8). For example, a new file A is generated in the program folder B from the file A in the program folder A and the difference data file a. When the generation of the new file A is completed, the program update unit 34 records that the new file A has been generated in the management file (OP9).

Program update unit 34 repeats the processing from the file amount corresponding OP8 OP9 stored in the program folder A (OP10).

  When generation of new files is completed for all files stored in the program folder A, the program update unit 34 sets the effective program folder of the boot flag in the FROM 38 to the program folder B (OP11). The program update unit 34 records the updated boot flag in the management file (OP12).

  By preparing two program folders for storing the program group and updating only the program folder that stores the old version of the program group, it is possible to keep the operation-confirmed program folder used just before that as a backup. it can.

  3A and 3B are diagrams illustrating an example of a return operation in the case where a power interruption occurs during each process of OP1 to OP12 described in FIG. FIG. 3 shows the return operation of the program update process when the power of the vehicle-mounted device 1 (automobile accessory power supply) is turned off for some reason, the program update process is forcibly terminated, and then the vehicle-mounted device 1 is activated. .

After the vehicle-mounted device 1 is restarted, if the management file in the update folder is in an initial state (empty), the program update unit 34 starts processing from OP1. If the contents of the management file are in the initial state, the management file generation process (OP1), differential data downloading (OP2), and the differential data downloaded to the management file are the states when the power failure occurs Is recorded (OP3). Alternatively, it is considered that it was during each process from OP1 to OP3. Therefore, when the contents of the management file are in the initial state, the program update unit 34 starts processing from OP1, and when there is a file in the middle of generation (management file, difference data file), it is temporarily being generated. Discard the file and regenerate it.

  If the contents of the management file record that the difference data has been downloaded, that is, if the “difference data download flag” is set, the program update unit 34 starts processing from OP4. In this case, as the state when the power interruption occurs, the difference data file is divided and the difference data file is generated for each module (OP4), and the difference data file generated for each module is recorded in the management file. (OP5). Alternatively, it is considered that it was at the time of transition of each process from OP3 to OP5. Therefore, when the contents of the management file record that the difference data has been downloaded, the program update unit 34 starts processing from OP4.

  If the contents of the management file record the difference data downloaded and the file divided, that is, if the "difference data download flag" and the "file divided flag" are set, program update The unit 34 starts processing from OP6. In this case, as a state when the power is cut off, the boot flag in the FROM 38 is being checked (OP6), all the files in the update target program folder are being deleted (OP7), and a new file is stored in the update target program folder. This is considered to be either during generation of OP (OP8) or recording of generation of a new file in the management file (OP9). Alternatively, it is considered that it was during the transition of each process from OP5 to OP9. Therefore, when the contents of the management file record that the difference data has been downloaded and the file has been divided, the program update unit 34 starts processing from OP6.

  When the contents of the management file record the difference data downloaded, the file divided, and the new file X generated (X: variable), that is, “difference data download flag” and “file divided already” When the “flag” and the “new file X generated flag” are set, the program update unit 34 starts processing from OP10. That is, the program update unit 34 starts processing from generation of a new file next to the new file X. In this case, it can be considered that the state when the power interruption occurred was either during the generation of a new file in the update target program folder or recording the generation of a new file in the management file. Therefore, when the contents of the management file are recorded that the difference data has been downloaded, the file has been divided, and the new file X has been generated, the program update unit 34 starts generating a new file of the file next to the file X. Start processing.

  When the contents of the management file record that the difference data has been downloaded, the file has been divided, and all the files have been generated, that is, the “difference data download flag”, the “file division completed flag”, and “ When the “new file X generated flag” is set for all files, the program update unit 34 refers to the boot flag in the FROM 38 and starts loading the program. In this case, as the state when the power interruption occurs, it is considered that either the valid folder of the boot flag in the FROM 38 is being updated (OP11), or the updated update of the boot flag is being recorded in the management file. . For this reason, when the contents of the management file record that the difference data has been downloaded, the files have been divided, and all the files have been generated, the program update unit 34 loads the program with reference to the contents of the boot flag.

  By managing the progress status of the program update process in the management file, even if the program update process is forcibly terminated due to a power failure or the like, the process forcibly terminated (expected) by referring to the management file You can resume from.

<Example of boot flag value>
FIG. 4 is a diagram illustrating an example of boot flag values in the FROM 38. For example, a boot flag is held for each program folder. That is, the boot flag A and the boot flag B are held in the FROM 38, thereby selecting a program folder to be loaded at the time of loading (indicating a valid program folder).

  FIG. 4 shows an example in which the boot flag A indicating the state of the program folder A and the boot flag B indicating the state of the program folder B are each composed of 16 bits. In FIG. 4, the value of each boot flag is expressed in hexadecimal. Each boot flag indicates “0x0000” is invalid and “0x0001” is valid. As a characteristic of the FROM 38, when the boot flag is rewritten (updated), it is necessary to invalidate the data of the boot flag once, so the data is cleared as “0xFFFF”. In FIG. 4, the update of the boot flag shows a case where the update of the program folder A is performed with priority over the update of the program folder B. The state transition of the boot flag A and the boot flag B is assumed to transition from the state 1 shown below to the state 5 through the states 2, 3, and 4 or from the state 5 to the state 1 through the states 6, 7, and 8.

  State 1 is a state in which the boot flag A is “0x0001” and the boot flag B is “0x0000”. That is, the program folder A is currently selected as a valid program file.

  State 2 is a state in which the boot flag A is “0xFFFF” and the boot flag B is “0x0000”. In this case, it indicates that the boot flag A is being rewritten and the value of the boot flag B indicates invalid, but in view of the fact that the boot flag A is being updated, the currently valid program folder Is determined to be the program folder B.

  State 3 is a state in which the boot flag A is “0x0000” and the boot flag B is “0x0000”. In this case, it indicates that both the boot flag A and the boot flag B are being updated, and in view of the transition period from the state 1 to the state 5, the program folder B is a valid program folder. to decide.

  State 4 is a state in which the boot flag A is “0x0000” and the boot flag B is “0xFFFF”. The boot flag B indicates that it is being rewritten. Considering that the boot flag A is preferentially updated, it is determined that the program folder B is a currently valid program folder.

  State 5 is a state in which the boot flag A is “0x0000” and the boot flag B is “0x0001”. In this case, the program folder A is invalid and the program folder B is valid.

  State 6 is a state in which the boot flag A is “0xFFFF” and the boot flag B is “0x0001”. The boot flag A is being rewritten, and in view of the transition from the state 5, it is determined that the program folder A is valid and the program folder B is invalid.

  The state 7 is a state in which the boot flag A is “0x0001” and the boot flag B is “0x0001”. In this case, it indicates that both the boot flag A and the boot flag B are being updated, and in view of the transition period from the state 5 to the state 1, the program folder A is a valid program folder. to decide.

State 8 is a state in which the boot flag A is “0x0001” and the boot flag B is “0xFFFF”. The boot flag B indicates that it is being rewritten. Considering that the boot flag A is preferentially updated, it is determined that the program folder A is a currently valid program folder.

  When the vehicle-mounted device 1 is activated, the boot flag value is rewritten to the value of the state 5 when the value of the boot flag is from the state 2 to the state 4, and is reactivated to the value of the state 1 when the value of the state 6 to the state 8.

<Example of startup sequence>
When the program update process is completed, the vehicle-mounted device 1, the master device 3, or each slave device 4 is restarted, and a process of loading the updated latest version of the program is executed. At this time, even if the program update process is successful, there is a possibility that an abnormality occurs in the loading process of the updated latest version of the program. Possible causes of such abnormal loading of the program include a bug in the update program, and bit corruption when the update program is loaded onto the DRAM 37. In such an in-vehicle device 1 of the first embodiment, the recovery data is held in the HDD 36 as a means for returning when the updated program is not activated.

  FIG. 5 is a diagram illustrating an example of holding recovery data of the vehicle-mounted device 1. The HDD 36 holds a loader folder and a recovery folder. The loader folder stores a loader program that executes loading processing. In the recovery folder, a recovery program and a factory default program of each device (master device, slave device) are stored. The recovery program is a program that executes recovery processing.

<< Example of normal startup operation flow >>
FIG. 6 is a diagram illustrating an example of the flow of the startup operation at the normal time. FIG. 6 illustrates a case where the vehicle-mounted device 1 is turned on and the master device 3 executes a startup sequence including the slave device 4. When the power is supplied to the vehicle-mounted device 1 or the master device 3, the master device 3 starts a boot program stored in the FROM 38 (OP21). The CPU of the device that executes the boot program detects an error of the application program loaded in the DRAM 37 (OP22).

  The error check of the application program is performed by detecting an error by checksum, checking the number of occurrences of abnormal reset, and checking the number of occurrences of abnormal loading. An abnormal reset may be reset spontaneously if there is a bug in the application program. The number of abnormal resets is the number of times that the application program has been reset by this time, which is recorded as a log. The abnormal loading means that the process of copying the application program stored in the HDD 36 to the DRAM 37 fails. The number of abnormal loadings is the number of times abnormal loading has occurred before this activation.

  If there is no abnormality in the error check of the application program, then the application program loaded in the DRAM 37 is executed (OP23).

  When normal, the CPU does not refer to the program folder stored in the HDD 36 and starts up using the data of the application program loaded in the DRAM 37.

<< Example of operation at startup when an error occurs >>
FIG. 7 is a diagram illustrating an example of a startup sequence. FIG. 7 also illustrates a case where the master device 3 performs a startup sequence, as in FIG.

  When the vehicle-mounted device 1 or the master device 3 is powered on (or restarted), the boot program stored in the FROM 38 is started (OP31).

  The CPU of the master device 3 checks the abnormal reset count X of the application program recorded in the log (OP32). It is confirmed whether or not the abnormal reset count X of the application program is a value equal to or greater than a preset predetermined count. If the number X of abnormal resets of the application is a value equal to or greater than the predetermined number (OP32: Y), the process moves to an abnormal sequence A (OP38). The abnormal sequence A will be described later.

  If the abnormal reset count X of the application program is a value smaller than a predetermined value (OP32: N), it is determined whether or not the abnormal loading count Y is a value greater than or equal to a preset predetermined count (OP33). When the abnormal loading number Y is a value equal to or larger than the predetermined number (OP33: Y), the process proceeds to the abnormal sequence B (OP37). The abnormal sequence B will be described later.

  When the abnormal loading number Y of the application program is smaller than the predetermined number (OP33: N), the checksum is confirmed (OP34). If there is an abnormality in the checksum (OP34: Y), the processing moves to the sequence A at the time of abnormality (OP38). If there is no abnormality in the checksum (OP34: N), the application program is started (OP35).

  The CPU monitors the occurrence of an abnormal reset of the application program. When the abnormal reset occurs (OP36), the CPU adds 1 to the abnormal reset count X and records the occurrence of the abnormal reset (OP39).

<< Sequence A at Abnormality >>
FIG. 8 is a diagram illustrating an example of a flow of processing executed when the sequence A at the time of abnormality, that is, when the number X of abnormal resets is a value greater than or equal to a predetermined number and when the checksum is abnormal. FIG. 9 is a diagram illustrating a processing flow of the sequence A at the time of abnormality. FIG. 8 and FIG. 9 show the same processing with the same reference numerals.

  If the abnormal reset count X is a value greater than or equal to the predetermined count and if the checksum is abnormal, the loader program loaded in the DRAM 37 is loaded again from the loader folder of the HDD 36 (OP41). Next, the loaded loader program is activated (OP42).

  In accordance with the activated loader program, the CPU checks the boot flag in the FROM 38 to obtain a currently valid program folder (OP43). The CPU reloads the application program from the currently valid program folder stored in the HDD 36 (OP44).

  If an abnormality occurs during loading of the application program (OP45: Y), 1 is added to the abnormal loading count Y, and the occurrence of abnormal loading is recorded (OP46). Thereafter, the system is restarted and the process shown in FIG. 7 is executed again (OP47).

  Even when loading of the application program is successful (OP45: N), the application program is restarted and the processing shown in FIG. 7 is executed again (OP47).

<< Sequence B at Abnormality >>
FIG. 10 is a diagram illustrating a process executed when the abnormal sequence B, that is, when the abnormal loading count Y is equal to or greater than a predetermined count. FIG. 11 is a diagram illustrating a processing flow of the sequence B at the time of abnormality. 10 and 11 show the same processing with the same reference numerals.

  When the abnormal loading number Y is a value equal to or larger than the predetermined number, first, a caution for inquiring whether or not to execute the recovery process is displayed to the user of the vehicle-mounted device 1 (OP51). The displayed caution is a content that asks the user to confirm the execution of the recovery process, such as “Cannot start due to program file error. Are you sure you want to restore the factory settings? (YES / NO)”. .

  The user inputs the caution display (OP52). When the user selects to execute the recovery process (OP53: Y), the CPU loads the recovery program from the recovery file in the HDD 36 (OP54). The loaded recovery file is activated (OP55), and a factory-shipped application program is loaded from the recovery folder of the HDD 36 (OP56). Thereafter, the system is restarted and the process shown in FIG. 7 is executed again (OP57).

  If the user does not select the execution of the recovery process (OP53: N), a caution to restart is displayed (OP58). The caution displayed at this time is, for example, a content for confirming the restart to the user, such as “Restart the system”. Thereafter, the system is restarted and the process shown in FIG. 7 is executed again (OP57).

<Operational effects of the first embodiment>
When two program folders for storing programs are held and program update processing is performed, only one of them is updated. Keep the other as a backup. As a result, even if the process is forcibly terminated due to a power interruption or the like during the program update process, the data of the program whose original operation is guaranteed is not lost.

  In the program update process, the progress status is recorded in the management file, so that even if the program update process is forcibly terminated due to a power failure or the like, the process can be resumed from the next process after the completion recorded in the management file. . Therefore, it is not necessary to restart the program update process from the beginning, and time can be saved.

  The master device 3 also downloads the update program for the slave device 4 at once. When the program update process of the slave device 4 is performed, a dedicated jig may be required. However, since the program update window is integrated into the master device 3, the user can perform the program update process of the slave device 4 without a dedicated jig.

  When downloading the update program from the center C1, only the difference data between the program held by the vehicle-mounted device 1 and the new version of the program held by the center C1 is downloaded. As a result, the amount of communication between the center C1 and the vehicle-mounted device 1 can be reduced, and the time for downloading data can be shortened. In the case of pay-as-you-go communication such as packet communication, the amount of communication can be reduced.

  At the time of activation, the activation method is determined by checking three types of parameters such as the checksum of the application program in the DRAM, the number of abnormal resets, and the number of abnormal loadings. As a result, recovery can be executed in stages, which is efficient. In addition, since all the programs in the factory shipment state are stored in the recovery folder, it is possible to finally perform a full recovery to the factory shipment state, and the startup is guaranteed.

  According to the first embodiment, even if the user himself can perform the program update process and cannot be started due to interruption of the program update process or failure of the program update process, the normal state is obtained. Can return.

<Modification>
Two management files, such as program files, may be prepared and duplicated. For example, when the program update process is started, a copy of the management file A in the update folder is generated. A copy file of the management file A is defined as a management file B. The management file A is held as it is, and the management file B is updated in the program update process. When the program update process is completed, the management file A is deleted. By doing so, the management file A can be retained as a backup even when the power is cut off during the program update process, so that the contents of the management file can be prevented from being lost.

Further, when a power interruption or the like occurs during the update of the management file B, for example, an appropriate management file can be selected when the process is resumed by making the following determination.
(1) When the management file A exists and the management file B does not exist, the management file A is referred to.
(2) When the management file A and the management file B exist, the management file A is referred to and the management file B is deleted.
(3) When the management file A does not exist and the management file B exists, the management file B is referred to.

  In the first embodiment, the process of updating the program group stored in the program folder collectively has been described. Alternatively, individual programs can be updated. When updating by designating individual programs, the program stored in the valid program folder indicated by the boot flag is updated. When the update is completed, it is recorded in the management file that the updated program has been updated.

  In the first embodiment, the program in the factory shipment state is loaded from the recovery folder in the abnormal sequence B. Alternatively, in the abnormal sequence B, the boot flag may be checked, and a program folder that is not currently valid, that is, an old version program with an operation record before update may be loaded.

  Further, in the first embodiment, the case where the master device 3 performs the program update process and the recovery process of each slave device 4 has been described. The present invention is not limited to this, and the program update process and the recovery process may be performed in each slave device 4 for the application program used by itself.

<Others>
Regarding the above embodiment, the following additional notes are disclosed.
(Appendix 1)
A first storage for storing a first version of the program;
A second storage for storing a second version of the program that is the same as or newer than the first version;
An acquisition unit that acquires a difference between the second version program and a third version program that is newer than the second version program;
The third version program is generated from the second version program stored in the second storage unit and the difference acquired by the acquisition unit, and the generated third version program is stored in the first version program. A program update apparatus comprising: an update unit stored in a storage unit.
(Appendix 2)
A storage unit that holds information indicating whether to use a program stored in the first storage unit or the second storage unit;
The update unit generates the third version program from the acquired difference and the second version program stored in the second storage unit, and the generated third version program 2. The program according to claim 1, wherein the information stored in the storage unit is updated to information indicating that the program stored in the first storage unit is to be used when stored in the first storage unit. Update device.
(Appendix 3)
Management information indicating completion of processing is stored for each of the processing for obtaining the difference, the processing for generating the third version program, and the processing for storing the generated third program in the first storage unit. A management information storage unit;
When the update unit completes the process of acquiring the difference, the process of generating the third version of the program, and the process of storing the generated third program in the first storage unit The management information indicating the completion of the processing is stored in the management information storage unit, and when the previous series of processing is interrupted, the processing is completed based on the management information stored in the management information storage unit. The program update apparatus according to claim 1, wherein the program update apparatus executes a process not shown.
(Appendix 4)
A first storage for storing a first version of the program;
A second storage unit that stores a second version of a program that is the same as or newer than the first version;
Obtaining a difference between the second version of the program and a third version of the program that is newer than the second version;
Generating the third version of the program from the second version of the program stored in the second storage and the acquired difference;
Deleting the first version of the program stored in the first storage unit and storing the generated third version of the program in the first storage unit.
(Appendix 5)
An auxiliary storage device storing a factory-shipped version program and a first-version program that is newer than the factory-shipped version;
A main storage for holding the first version of the program loaded from the auxiliary storage;
A CPU that activates a first version of the program held in the main storage device when the power is turned on,
The CPU
When there is an error in the first version of the program held in the main storage device, and the first version of the program held in the main storage device operates a predetermined number of times before the power is turned on this time If the program is interrupted, the first version of the program stored in the auxiliary storage device is loaded into the main storage device,
If the first version of the program stored in the main storage device has failed to load more than a predetermined number of times before the power is turned on this time, the initial version program stored in the auxiliary storage device An information processing apparatus for loading a version program into the main storage device.

1 Onboard equipment 2 Mobile phone / DCM
3 Master device 4 Slave device 5 Deck 31 Communication unit 32 Download selection unit 33 Version information collection unit 34 Program update unit 35 Slave communication unit 36 HDD
37 DRAM
38 FROM
41 parent microcomputer 42 child microcomputer 411 device communication unit 412 program update unit 413 version information collection unit 414 communication unit 421 communication unit 422 program update unit

Claims (1)

An auxiliary storage device storing a factory-shipped version program and a first-version program that is newer than the factory-shipped version;
A main storage for holding the first version of the program loaded from the auxiliary storage;
A CPU that activates a first version of the program held in the main storage device when the power is turned on,
The CPU
When there is an error in the first version of the program held in the main storage device, and the first version of the program held in the main storage device operates a predetermined number of times before the power is turned on this time If the program is interrupted, the first version of the program stored in the auxiliary storage device is loaded into the main storage device,
If the first version of the program stored in the main storage device has failed to load more than a predetermined number of times before the power is turned on this time, the initial version program stored in the auxiliary storage device An information processing apparatus for loading a version program into the main storage device.

Images