JP5010876B2 - In-vehicle terminal apparatus and program control method therefor - Google Patents

Description

  The present invention relates to an in-vehicle terminal device having a screen display function such as a car navigation system, and more particularly to a method for controlling a program that is installed and executed on the terminal device.

  In recent years, in an in-vehicle terminal device having a screen display function such as a car navigation (car navigation) device, as described in the following Patent Document 1, in consideration of safety, when driving a car, In-vehicle display devices that improve vehicle safety by forcibly prohibiting screen displays that may cause the user's attention, as well as simplifying work and reducing costs when attaching to vehicles, are already known. It has been.

  Further, in Patent Document 2 below, in such an in-vehicle terminal device, even when a program to be additionally installed is used during traveling, the operation of the program executed so far is hindered, or the display visibility is reduced. In order to prevent this from happening, a method for controlling the operation of a program executed on a terminal device in accordance with a change in the traveling state of the mounted vehicle is disclosed.

JP-A-6-99778 JP 2005-75314 A

  However, in the above-described prior art, in particular, in the method described in Patent Document 2, it is possible to stop the program operation and stop the screen display while the vehicle is running. The release of memory resources consumed by the image data used for the above is not considered. For this reason, when another program requests the use of the memory resource while the vehicle is running, there is a possibility that the allocation of the memory resource may fail and the execution of the program may be hindered.

  On the other hand, it is possible to develop a program that prohibits screen display while the vehicle is running and automatically releases memory resources while the vehicle is running. However, screen display is permitted when the vehicle is stopped. When the program displays the same screen again, it has been pointed out that the image data needs to be reloaded from the beginning, resulting in a slow processing speed. In this case, it is difficult to determine whether or not the memory resource for image data should be released during traveling. For this reason, in particular, screen display is prohibited according to the traveling state of the vehicle on which the terminal device is mounted. It was a problem in program development. In addition, since it is difficult to estimate the processing performance on the terminal side at the time of development of a program that is installed and executed on the terminal device, similarly, it is determined whether to implement a memory resource release process. Difficult to do.

  Therefore, the present invention has been achieved in view of the above-described problems in the prior art, and automatically releases image data consumption resources in accordance with a change in the state of a vehicle on which a terminal device is mounted. An object of the present invention is to propose a program execution environment that enables image data to be reloaded at high speed when redrawing an image.

  That is, in the present invention, in order to solve the above-described problem, in a program execution environment in which screen display is prohibited in accordance with a change in the state of the terminal device, when the screen display of the program is prohibited due to a change in the state of the terminal device, A plurality of loaded image data used by the program is concatenated into one image data, the concatenated image data is stored in an external storage device, and memory resources consumed by the loaded image data are released. When reloading image data, load the concatenated image data from the external storage device, restore the original image data from the concatenated image data, and redraw the image data in the program that displays the screen. Ask.

  More specifically, in the present invention, in order to achieve the above object, first, an in-vehicle terminal device mounted on a vehicle, which is at least an arithmetic device, a main storage device, an external storage device, and a display device. A state determination unit that monitors a change in the state of the device including the driving state of the vehicle, and a state on the terminal device according to the state change monitored by the state determination unit. A plurality of loaded image data used by the program operating in the above is connected to one connected image data, and stored in the external storage device, and according to the state change monitored by the state determination unit, An in-vehicle terminal provided with an image restoration unit that loads the linked image data from the external storage device and restores a plurality of loaded image data used by a program operating on the terminal device Location is provided.

  In the present invention, in the in-vehicle terminal device described above, after the plurality of loaded image data are connected to one connected image data, the occupied memory of the image data in the main storage device may be released. Preferably, or when the vehicle is running, the state determination unit instructs the image connecting unit to connect the connected image data, and when the vehicle is stopped, It is preferable to instruct the image restoration unit to restore the connected image data. Alternatively, the in-vehicle terminal device preferably further includes a communication device for communicating with an external network and acquiring necessary program data and image data. A navigation device is preferred.

  In addition, according to the present invention, in order to achieve the above object, it is an in-vehicle terminal device mounted on a vehicle, and includes at least an arithmetic device, a main storage device, an external storage device, and a display device. A program control method in an in-vehicle terminal device, wherein a plurality of loads used by a program operating on the terminal device according to the monitored state change is monitored. Concatenated the completed image data into one connected image data, store it in the external storage device, load the connected image data from the external storage device in response to the monitored state change, and on the terminal device A program control method is provided for an in-vehicle terminal device that restores a plurality of loaded image data used by an operating program.

  According to the present invention, in the program control method described above, after the plurality of loaded image data are connected to one connected image data and stored in the external storage device, the main storage device It is preferable to release the occupying memory of the image data, or when the vehicle is running, instruct to connect and store the connected image data, while when the vehicle is stopped, connect It is preferable to instruct restoration of image data. Furthermore, in the program control method described above, when the plurality of loaded image data are connected to one connected image data, the connected image stored together with the connected image data is stored together with the connected image data. It is preferable to create and store linked image information related to the data, and when restoring the plurality of loaded image data, the linked image data that is linked to the one image data and stored together with the linked image data It is preferable to restore the image by referring to the connected image information.

  As is apparent from the above, according to the present invention, for example, when the screen display of a program is prohibited due to a change in the state of the terminal device, the consumed memory resources of the image data used by the program are automatically released. In addition, since the resource can be used by another program, the execution of the other program is not hindered, and a plurality of loaded image data is linked to one image data and stored in an external storage device. Therefore, it is possible to speed up the image reloading process, that is, to release the image data consumption resource and execute the program that allows the image data to be reloaded at a high speed when the image is redrawn. It is possible to propose an environment.

  Embodiments of an image processing method according to the present invention will be described below in detail with reference to the accompanying drawings.

  FIG. 1 is a diagram showing a hardware configuration of an in-vehicle terminal device according to an embodiment of the present invention, that is, an internal configuration of a car navigation device. In this figure, reference numeral 101 denotes an arithmetic unit, reference numeral 102 denotes a main storage device, reference numeral 103 denotes a communication device, reference numeral 104 denotes a display device, and reference numeral 105 denotes an external storage device. The external storage device 105 is composed of, for example, a nonvolatile memory that stores program data and image data. The main storage device 102 is a storage device for storing program instructions and image data loaded from the external storage device 105, and is constituted by, for example, a volatile memory or a nonvolatile memory. Furthermore, the arithmetic device 101 is a device that acquires image data and program instructions loaded in the main storage device 102 and executes predetermined arithmetic processing. The communication device 103 is a device for communicating with an external network (not shown) and acquiring necessary program data and image data. The display device 104 is a device for displaying image data and character strings on the screen, and is configured by, for example, a CRT display or a liquid crystal display. These devices, in particular, the display device 104 are attached, for example, near the dashboard of an automobile.

  Next, attached FIG. 2 is a system configuration diagram of a car navigation device (terminal device) whose general internal configuration is shown above. First, as is apparent from the figure, the main storage device 102 constituting the terminal device includes a program execution environment 201 and an image display program 206.

  The program execution environment 201 is an execution environment for a program operating on the terminal device. As is apparent from the drawing, the program execution environment 201 includes a state determination unit 202, an image connection unit 203, an image restoration unit 204, and loaded image information 205. It is configured.

  The image display program 206 is a program that operates on the program execution environment 201 and has a function of outputting a screen to the display device 104 as indicated by an arrow in the figure. Loaded image data A207 and loaded image data B208 constituting the image display program 206 are stored in the main storage device 102 as image data A211 and image data B212 stored in the external storage device 105, respectively. It is loaded and displayed on the display device 104 by the image display program 206. However, in the present invention, the loaded image data is not limited to the above-described example (number), and does not indicate only a specific type of image data. That is, in the present invention, the number, size, and format of these image data are not particularly limited.

  On the other hand, the loaded image information 205 constituting the program execution environment 201 in the main storage device 102 stores information related to the loaded image data A207 and loaded image data B208 of the image display program 206. The linked image data 209 in the external storage device 105 is the image data A207 and the loaded image data B208 linked to one image data and stored on the external storage device 105. The linked image information 210 in the external storage device 105 stores information related to the linked image data 209 stored by being linked to the one image data. Further, the image data A 211 and image data B 212 in the external storage device 105 are image data used by the image display program 206 of the main storage device 102.

  Then, the state determination unit 202 that configures the program execution environment 201 described above monitors the state of the terminal device, and when the state change is detected, the image connection unit 203 or the image restoration unit 204 determines whether the state change is detected. Request processing. That is, the image connecting unit 203 refers to the loaded image information 205, acquires information about the loaded image data A207 and loaded image data B208 stored therein, and stores each loaded image data as one The image data is linked and stored on the external storage device 105 as linked image data 209. At this time, if the memory area on the main storage device 102 used by each loaded image data is unnecessary, it is released.

  On the other hand, the image restoration unit 204 requested to process refers to the connected image information 210 (FIG. 2), acquires information related to the connected image data 209 stored therein, and stores the connected image data 209 as a result. Loaded image data A207 and loaded image data B208 before connection are restored. After restoring the image data, the image display program 206 is requested to redraw the loaded image data A207 and loaded image data B208, thereby reproducing the screen displayed on the display device 104. To do.

In this way, by connecting a plurality of loaded image data into one, it is possible to speed up the loading process when reloading the connected image data. The following factors can be cited as factors that increase the processing speed.
・ Reduction of disk input / output times ・ Reduction of image header analysis time ・ Reduction of color conversion time (The color model of each image data can be unified with the color model of the terminal device side)
・ Reduction of function calls (number of method calls) called during image decoding

  These details will be described with reference to the following examples.

  A first embodiment of the present invention will be described in detail with reference to FIGS.

  First, FIG. 3 is a diagram showing a sequence of the image loading process, and the processes between the image display program 206, the program execution environment 201, and the external storage device 105 described above are performed as time passes. It is indicated by the axis extending to

  As is clear from the figure, when the image execution processing request 201 is received from the image display program 206, the program execution environment 201 transmits an image data read request 302 to the external storage device 105, whereby the external storage device The image data stored on 105 is loaded. When the program execution environment 201 finishes loading the image data, the program execution environment 201 adds information about the loaded image to the loaded image information 205 (see FIG. 2) (that is, the load in FIG. 3). Finished image information update processing 303), and the processing ends. By such processing, the program execution environment 201 can reliably manage information regarding the currently loaded image. Here, the update processing 303 of the loaded image information 205 may be executed in parallel with the image data loading processing, or by analyzing the header portion of the image data, prior to the image loading processing. May be executed.

  Next, FIG. 4 attached is a diagram showing an example of the data configuration of the loaded image information 205 constituting the program execution environment 201. Here, “image ID” 401, “total number of pixels” 402, and “pointer to image data” 403 are defined as the data structure, however, the loaded image data can be uniquely identified. Any information may be used, and the present invention is not limited to this.

  In the data configuration of the loaded image information 205, the “image ID” 401 is a character string or a numerical value that can uniquely identify the image data, and the “total number of pixels” 402 is the number of vertical pixels of the image data. The “pointer to image data” 403 is an address on the main storage device 102 where the image data is expanded. Here, since the number of bits per pixel of the loaded image data differs for each terminal device, it is not included in this loaded image information 205. Further, the image connecting unit 203 of the program execution environment 201 performs image data connecting processing based on the loaded image information 205.

  Next, FIG. 5 attached is a flowchart showing the detailed contents of the state determination process executed by the state determination unit 202 constituting the program execution environment 201. The state determination unit 202 monitors the state of the terminal device or the program, and starts the process when a state change is notified by the occurrence of an event or an interrupt. As is apparent from the figure, in step 501, it is determined whether or not the image connection process is to be executed. If the result is that the image connection process is to be executed ("YES"), step 502 described below is performed. Proceed to On the other hand, if the state is not to be executed (“NO”), the process proceeds to step 506. Here, as an example of a state in which this image connection processing is to be executed, the following can be cited.

-Immediately after the program startup process is completed-When the screen saver is started-Immediately after the image data drawing process is completed-After a certain period of time (periodic execution)
・ When screen interruption from other programs ・ When screen display is restricted

  The above-described states are examples, and in the present invention, the contents of the state determination process by the state determination unit 202 are not limited to these. Further, the state determination unit 202 can execute the image connection process at an arbitrary timing. However, the timing of the start of the image connection process does not affect the present invention.

  Next, in the process of step 502, it is checked whether or not a loaded image exists. As a result, if it is determined that a loaded image exists (“YES”), the process proceeds to step 503. On the other hand, if it is determined that no loaded image exists (“NO”), the series of processing ends. Note that whether or not there is a loaded image in this determination process is determined by referring to the data of the loaded image information 205.

  Next, step 503 is processing for performing image connection. This image connection process is executed by the image connection unit 203 (see FIG. 2). Details of this image connection processing will be described later. Step 504 is a process for checking whether or not the memory area on the main storage device 102 is releasable. As a result, if the memory can be released (“YES”), the process proceeds to step 505. On the other hand, if the memory is not releasable (“NO”), the series of processing is terminated. Here, the state in which the memory can be released is a state in which the loaded image data is not used. For example, a state in which screen display is prohibited, a screen interruption from another program, a screen saver activation, etc. For example, The above step 505 is a memory release process, and the memory resource area occupied by the loaded image is released.

  Next, when it is determined in step 501 that the image connection process should not be executed (“NO”), in step 506, it is checked whether or not the image can be restored. As a result, if the image can be restored (“YES”), the process further proceeds to step 507 described below. On the other hand, if the image is not in a recoverable state (“NO”), the series of processes is terminated. Here, examples of the state where the image can be restored include the following states.

-When the screen saver is finished-When the screen interrupt from another program is released-When the screen display restriction is released Note that the above state is an example. In the present invention, the contents of the state determination processing by the state determination unit 202 are limited to these. It is not a thing. The state determination unit 202 can execute the image restoration process at an arbitrary timing. However, the start timing of the image restoration process does not affect the present invention.

  Step 507 is a process for checking whether or not a connected image exists. As a result, if it is determined that a connected image exists (“YES”), the process further proceeds to step 508. On the other hand, if it is determined that there is no connected image (“NO”), the series of processing ends. Here, it is determined whether or not there is a connected image in step 507 by referring to the connected image information 210 (FIG. 2). Further, the above step 508 is an image restoration process. Specifically, this image restoration process is executed by the image restoration unit 204 (FIG. 2). However, details of this image restoration processing will be described later.

  The above is the details of the state determination processing by the state determination unit 202 in the program execution environment 201 shown in FIG.

  Next, details of the image connection processing by the image connection unit 203 in the program execution environment 201 will be described with reference to the flowchart of FIG.

  In this image connection process, first, in step 601, loaded image information 205 (FIG. 2) is read. In step 602, the loaded loaded image information 205 is analyzed to determine whether a loaded image exists. As a result, if it is determined that a loaded image exists (“YES”), the process proceeds to step 603 below. On the other hand, if it is determined that no loaded image exists (“NO”), the process proceeds to step 608.

  Here, the above-mentioned step 603 is the read processing of the loaded image data. The loaded image data is read by referring to the “pointer to image data” 403 (FIG. 4) of the loaded image information 205. In step 604, the loaded loaded image data is connected to one image data. Here, the concatenation process in step 604 can be executed, for example, by simply joining pixel data arrays. However, any format may be used as long as the restoration is possible, for example, an image header, for example. The image data itself including may be concatenated. Note that the information related to the connected image data is stored by updating the connected image information 210 (FIG. 2) in the subsequent step 605. Details of the linked image information 210 will be described later. In step 606, the loaded image information 205 is updated. Specifically, the information regarding the images connected in this step is deleted from the loaded image information 205. In step 607, the updated loaded image information 205 is checked again, and then the process returns to step 602. That is, the above process is repeated until it is determined in the above-described determination step 602 that there is no loaded image (“NO”).

  Next, when it is determined in the determination step 602 that no loaded image exists (“NO”), first, in step 608, the linked image information 210 created in the above-described processing is stored in the external storage. Output on device 105 (FIG. 2). Thereafter, in step 609, the linked image data 209 is further output to the external storage device 105. As a result, the linked image data 209 that can be restored by the image restoration unit 204 is stored in the external storage device 105.

  Next, FIG. 7 attached is a diagram showing a data configuration of the above-described linked image information 210, which is configured by data representing information related to the linked images. Here, as the information related to the linked images, FIG. , “Image ID” 701, “Width” 702 of the image, “Height” 703 of the image, and “Offset” 704 are defined. However, this information may be any information that can uniquely identify the image data linked to the linked image data 209, and it will be apparent to those skilled in the art that the information is not limited to the above example. In addition, for example, when there is metadata related to linked image data, the metadata can also be included here.

  In the above data configuration, “image ID” 701 is a character string or numerical value that can uniquely identify the linked image data, and “width” 702 of the image is the number of pixels next to the linked image data. The “height” 703 of the image is the number of vertical pixels of the concatenated image data, and the “offset” 704 is the amount of offset from the first pixel of the concatenated image data. That is, by referring to these pieces of information (data), the image restoration unit 204 can restore the linked image data.

  Next, an image restoration process by the image restoration unit 204 will be described with reference to the attached flowchart of FIG.

  First, in step 801, the linked image data 209 is read from the external storage device 105 (FIG. 2). Next, in step 802, the linked image information 210 is read from the external storage device 105 (FIG. 2). After that, in step 803, it is checked whether or not linked image data exists by analyzing the read linked image information 210. As a result, if image data exists (“YES”), the process proceeds to step 804. On the other hand, if there is no image data (“NO”), the process proceeds to step 808.

  First, if image data exists (“YES”), in step 804, memory is allocated to the restored image data. Next, in step 805, the original image data is restored from the read linked image data 209. At this time, the processing refers to, for example, the linked image information 210, and specifies the “offset” and the number of pixels of the linked image data (that is, the “width” 702 and “height” 703 of the image). It is done by doing. Subsequently, in step 806, when the metadata of the image linked to the linked image information 210 (FIG. 7) is stored, the metadata is set to the restored image data. In step 807, it is checked whether there is image data to be restored next by analyzing the connected image information 210, and the process returns to the determination step 803 again. That is, the above-described image data restoration processing is repeated until it is determined that there is no image data (“NO”) in the connected image data.

  On the other hand, after the restoration of the image data, if it is determined in the determination step 803 that the connected image data does not exist (“NO”), in step 808, the image display program 206 (FIG. 2) is re-executed. A drawing process request is made. According to the above processing, the original image data can be restored from the linked image data 209, so that the restored image can be redisplayed on the display device 104.

  Further, an in-vehicle terminal device according to the second embodiment of the present invention will be described below. FIG. 9 attached here shows a system configuration when a Java virtual machine (Java is a registered trademark) is mounted on an in-vehicle terminal such as a car navigation system and the program control method according to the present invention is applied.

  In the figure, a Java virtual machine 904 is an execution environment of a Java program 905 executed on the in-vehicle terminal 901, and corresponds to the program execution environment 201 shown in FIG. The in-vehicle terminal 901 includes a hard disk device (HDD) 902 corresponding to the external storage device 105 and the display device 104, and further travels through a CAN (Control Area Network) 909 which is an in-vehicle network. The sensor information can be acquired from the state sensor 903.

  In the configuration described above, the Java program 905 is a program for displaying a screen on the display device 104, and this corresponds to the image display program in FIG. The Java program 905 is prohibited from being displayed on the screen while the vehicle is running from the viewpoint of safety. As a method for prohibiting this screen display, the Java virtual machine 904 obtains a traveling state from the traveling state sensor 903, and as a result, if it is determined that the vehicle is traveling, the use of the graphic API 908 is prohibited. Or by means.

  In the figure, an Image object A906 and an Image object B907 are obtained by loading the image data A211 and the image data B212 stored on the HDD 902 onto the main storage device 102, and are already loaded in FIG. This corresponds to image data A207 and loaded image data B208. The graphic API 908 is an API group related to screen display provided to the Java program 905 by the Java virtual machine 904.

  In a general Java implementation, the Java program 905 sends a drawing request for the Image object A 906 and the Image object B 907 to the Java virtual machine 904 through the graphic API 908. Then, the image data A 211 and image data B 212 stored on the HDD 902 are loaded onto the main storage device 102 and stored in the Image object A 906 and the Image object B 907. The Java virtual machine 904 can acquire information of loaded image data by holding reference information to the loaded Image object A 906 and Image object B 907. Therefore, the reference table that stores the reference information for the Image object A 906 and the Image object B 907 corresponds to the loaded image information 205 in FIG.

  Next, the state determination unit 202 in the Java virtual machine 904 whose configuration has been described above acquires the traveling state of the vehicle from the traveling state sensor 903 through the CAN 909. As a result, when the vehicle is traveling, The image connection unit 203 is requested to perform image data connection processing. As a result, the image concatenation unit 203 obtains the pixel data arrays of the Image object A 906 and the Image object B 907, concatenates them into one array, performs a decoding process again, and stores it as the concatenated image data 209 on the HDD 902. At the same time, the connected image information 210 stores the file names of the image data A211 and the image data B212 as the image ID 701, as shown in FIG. 7, and further, the width 702, height 703, and The offset 704 from the first pixel of the connected image data 209 is stored. Then, when this image connection process is completed, the Java virtual machine 904 releases the resources consumed by the Image object A 906 and the Image object B 907.

  On the other hand, as a result of the state determination unit 202 of the Java virtual machine 904 acquiring the traveling state of the vehicle from the traveling state sensor 903 through the CAN 909, when the vehicle is stopped, the image restoration unit 204 restores the image data. Request processing. As a result, the image restoration unit 204 loads the linked image data 209 stored above from the HDD 902, and at the same time, the offset 704, the width 702 and the height 703 of the image data stored in the linked image information 210, and the image ID 701. Thus, the objects corresponding to the original Image object A906 and Image object B907 are restored. Finally, by requesting the Java program 905 to redraw the image data, the screen before running can be redrawn on the display device 104.

  As described above, the embodiment of the present invention has been described in detail including the example of the mounting method of the Java virtual machine 904. However, the present invention is not limited to this, and the same function is realized. If possible, it will be apparent that it is within the scope of the inventive idea of the present invention.

It is a block diagram which shows the hardware constitutions of the vehicle-mounted terminal device which becomes one embodiment of this invention. It is a system block diagram which shows the system configuration | structure in the hardware constitutions of the said vehicle-mounted terminal device. It is a sequence diagram which shows the sequence of the image load process in the said vehicle-mounted terminal device. It is a figure which shows the specific example of the loaded image information in the said vehicle-mounted terminal device. It is a flowchart figure which shows the content of the state determination process performed by the state determination part of the program execution environment in the said vehicle-mounted terminal device. It is a flowchart figure which shows the content of the image connection process performed by the image connection part of the said program execution environment. It is a figure which shows the specific example of the connection image information in the said vehicle-mounted terminal device. It is a flowchart figure which shows the content of the image restoration process performed by the image restoration part of the said program execution environment. It is a figure which shows the system configuration at the time of mounting a Java virtual machine in the vehicle-mounted terminal which becomes other embodiment of this invention.

Explanation of symbols

DESCRIPTION OF SYMBOLS 101 ... Arithmetic apparatus 102 ... Main storage apparatus 103 ... Communication apparatus 104 ... Display apparatus 105 ... External storage apparatus 201 ... Program execution environment 202 ... State determination part 203 ... Image connection part 204 ... Image restoration part 205 ... Loaded image information 206 ... Image display program 207... Loaded image data A
208: Loaded image data B
209 ... Concatenated image data 210 ... Concatenated image information 211 ... Image data A
212 Image data B.

Claims (2)

An in-vehicle terminal device mounted on a vehicle, comprising at least an arithmetic device, a main storage device, an external storage device, and a display device, further comprising:
A state determination unit, an image connection unit, and an image restoration unit;
The state determination unit monitors the state change of the device including the driving state of the vehicle, and when the vehicle is running, instructs the image connection unit to connect and store the loaded image data, On the other hand, when the vehicle is stopped, the image restoration unit is instructed to restore the connected image data,
In the case of the instruction to connect and store the loaded image data, the image connecting unit connects a plurality of loaded image data used by a program operating on the terminal device to one connected image data, and Memorize it in a storage device,
In the case of an instruction to restore the linked image data, the image restoration unit loads the linked image data from the external storage device and restores a plurality of loaded image data used by a program operating on the terminal device. vehicle terminal, wherein the to Turkey. An in-vehicle terminal device mounted on a vehicle, at least a program control method in an in-vehicle terminal device comprising an arithmetic device, a main storage device, an external storage device, and a display device,
Changes in the state of the device including the driving state of the vehicle are monitored, and when the vehicle is running, the linked image data is instructed to be stored and stored. On the other hand, when the vehicle is stopped, the connected image is displayed. Instruct to restore data,
In the case of the instruction to link and store the loaded image data, a plurality of loaded image data used by a program operating on the terminal device is linked to one linked image data, and stored in the external storage device,
In the case of the instruction to restore the linked image data, the linked image data is loaded from the external storage device, and a plurality of loaded image data used by a program operating on the terminal device is restored. Program control method for in-vehicle terminal device.

Images