Vehicle-mounted information processing device, control method, and computer program product

Abstract

Provided are an in-vehicle information processing device, a control method, and a computer program, which can continue to execute an application program operating on an OS even during a restart of the OS. An in-vehicle information processing device according to the present embodiment is mounted on a vehicle and includes a control unit that controls a plurality of OSs (Operating System) operating on common hardware, determines whether the plurality of OSs need to be restarted, causes an application program operating on one of the OSs to operate on another of the OSs different from the one of the OSs in a case where it is determined that the one of the OSs needs to be restarted, restarts the one of the OSs, and causes the application program operating on the another of the OSs to operate on the one of the OSs after the restart is completed.

Description

TECHNICAL FIELD

[0001] The present disclosure relates to an in-vehicle information processing apparatus, a control method, and a computer program product that control a plurality of OSs (Operating Systems) that act on common hardware. BACKGROUND

[0002] In recent years, information processing apparatuses mounted on vehicles have become more functional and are capable of executing various applications. Furthermore, the in-vehicle information processing apparatuses are capable of causing a plurality of OSs to act in parallel, and sometimes are capable of causing a plurality of applications that act on different OSs to act in parallel. In the in-vehicle information processing apparatus, in a case where, for example, update processing of an OS is performed or a case where abnormal stop of an OS occurs, a need to perform a restart of the OS arises, and during the restart of the OS, an application that acts on the OS cannot act.

[0003] In Patent Literature 1, an information processing apparatus is proposed that causes a first OS and a second OS to operate in a virtualized environment, and in a case where a first application that causes a display mechanism to display an image acts on the first OS, in a case where it is detected that a restart of the first OS is necessary, causes a second application that displays a restart-time image to act on the second OS at least during a period until the restart of the first OS is completed.

[0004] PRIOR ART DOCUMENTS

[0005] PATENT LITERATURE

[0006] Patent Literature 1: International Publication No. 2013 / 132646 SUMMARY

[0007] PROBLEMS TO BE SOLVED BY THE INVENTION

[0008] The information processing apparatus described in Patent Literature 1 needs to prepare a second application that acts on a second OS separately from a first application that acts on a first OS for display, and there is a concern that a storage area such as a memory is wasted. Furthermore, the second application in Patent Literature 1 is a simplified version of the first application, and only a limited process can be executed during the restart of the first OS.

[0009] The present disclosure is made in view of this, and aims to provide an in-vehicle information processing apparatus, a control method, and a computer program that can be expected to continue an application that acts on an OS even during a restart of the OS.

[0010] MEANS FOR SOLVING THE PROBLEMS

[0011] The vehicle-mounted information processing device according to the present embodiment is mounted on a vehicle and includes a control unit that controls a plurality of OSs operating on common hardware, determines whether or not the plurality of OSs needs to be restarted, causes an application program operating on one of the OSs to operate on another OS different from the one OS when it is determined that the one OS needs to be restarted, restarts the one OS, and causes the application program operating on the other OS to operate on the one OS after the restart is completed.

[0012] The present application can be realized not only as a device including the control unit having the above-described features, but also as a method in which the features are processed as steps, or a computer program for causing a computer to execute the steps. It can be realized as a semiconductor integrated circuit that realizes part or all of the device, or as another device or system that includes the device.

[0013] Effects of Invention

[0014] According to the above, it is possible to continue execution of an application program operating on an OS even during restart of the OS. BRIEF DESCRIPTION OF DRAWINGS

[0015] Figure 1 is a schematic diagram showing one configuration example of a vehicle-mounted information processing system according to the present embodiment.

[0016] Figure 2 is a block diagram showing a configuration of a GW according to the present embodiment.

[0017] Figure 3 is a schematic diagram for explaining a software configuration of a GW according to the present embodiment.

[0018] Figure 4 is a schematic diagram showing one example of an application table of a GW.

[0019] Figure 5 is a schematic diagram for explaining a software configuration in which a GW according to the present embodiment performs restart of an OS.

[0020] Figure 6 is a flowchart showing a sequence of an OS restart process performed by a GW according to the present embodiment.

[0021] Figure 7 is a flowchart showing a sequence of an OS restart process performed by a GW according to the present embodiment.

[0022] Figure 8 is a flowchart showing a sequence of a standby process performed by a GW according to the present embodiment.

[0023] Figure 9 is a schematic diagram showing an example of an application table of a GW involved in a modification example. DETAILED DESCRIPTION

[0024] [Explanation of Embodiments of the Present Disclosure]

[0025] First, embodiments of the present disclosure are explained. At least a part of the following described embodiments can also be combined arbitrarily.

[0026] (1) A vehicle-mounted information processing device involved in the present embodiment is mounted on a vehicle and has a control section that controls a plurality of OSs that operate on common hardware, the control section determines whether or not the plurality of OSs need to be restarted, in a case where it is determined that one OS needs to be restarted, the control section causes an application program that operates on the one OS to operate on another OS different from the one OS, the control section restarts the one OS, and after the restart is completed, the control section causes the application program that operates on the another OS to operate on the one OS.

[0027] In the present embodiment, the vehicle-mounted information processing device has a control section that controls a plurality of OSs that operate on common hardware. The control section of the vehicle-mounted information processing device determines whether or not the plurality of OSs need to be restarted, in a case where it is determined that one OS needs to be restarted, the control section causes an application program that operates on the one OS to operate on another OS. Thereafter, the control section restarts the one OS, and after the restart is completed, the control section causes the application program that operates on the another OS to operate on the one OS. Thus, the vehicle-mounted information processing device can execute the same program as the application program that operates on the one OS on the another OS, and it is expected that the processing of the application program continues even during the restart of the one OS.

[0028] (2) Preferably, the control section causes the another OS to operate in parallel during the restart of the one OS.

[0029] In the present embodiment, the another OS is caused to operate in parallel during the restart of the one OS by the vehicle-mounted information processing device. Thus, the application program can be executed in parallel on the another OS during the restart of the one OS.

[0030] (3) Preferably, there is a storage section that temporarily stores an OS and an application program that operate, in a case where the control section causes an application program that operates on the one OS to operate on the another OS, the control section copies the application program stored in one storage area of the storage section used by the one OS to another storage area of the storage section used by the another OS, and after the restart of the one OS is completed, the control section deletes the application program copied to the another storage area.

[0031] In the present embodiment, in a case where the in-vehicle information processing device causes an application program operating on one OS to operate on the other OS, the in-vehicle information processing device copies the application program stored in the storage area used by one OS to the storage area used by the other OS. After the restart of one OS is completed, the in-vehicle information processing device deletes the copied application program from the storage area of the other OS. Thus, the in-vehicle information processing device can copy the application program from the storage area of one OS and operate on the other OS, and thus does not need to separately prepare an application program operating on the other OS.

[0032] (4) Preferably, in a case where it is determined that the restart of one OS is required, the control section determines, from one or more application programs operating on one OS, an application program that should continue to operate during the restart of one OS, determines whether there is an other OS that can cause the application program determined to continue to operate to operate, determines whether there is free capacity to store the application program in an other storage area used by the other OS determined to be able to cause the application program to operate, and in a case where it is determined that there is free capacity, copies the application program to the other storage area.

[0033] In the present embodiment, the in-vehicle information processing device determines, from one or more application programs operating on one OS determined to require a restart, an application program that should continue to operate during the restart of one OS. The in-vehicle information processing device determines whether there is an other OS that can cause the application program that should continue to operate to operate. The in-vehicle information processing device determines whether there is free capacity to store the application program in a storage area of the other OS determined to be able to cause the application program to operate. In a case where it is determined that there is free capacity, the in-vehicle information processing device copies the application program to the storage area of the other OS and operates. Through these processes, the in-vehicle information processing device can expect the application program that should continue to operate to operate more reliably during the restart of one OS.

[0034] (5) Preferably, in a case where it is determined that there is no free capacity, the control section causes the restart of one OS to stand by.

[0035] In the present embodiment, in a case where there is no free capacity to store an application program in a storage area of the other OS, the in-vehicle information processing device stands by the restart of one OS in which the application program operates. Thus, it is possible to prevent the operation of the application program that should continue to operate from stopping.

[0036] (6) Preferably, the control section causes the one OS that stands by to restart after the ignition switch of the vehicle is switched from an on state to an off state.

[0037] In the present embodiment, in a case where the restart standby of the OS is made, the in-vehicle information processing device implements the restart of the OS after the ignition switch of the vehicle is switched from the on state to the off state. Thus, the in-vehicle information processing device can restart the OS at a stage where the user is highly likely to complete the use of the vehicle, that is, a stage where there is a high possibility that no problem will occur even if the processing of the application program is stopped.

[0038] (7) Preferably, in a case where it is determined that the other OS does not exist, the control section activates a substitute OS that becomes a substitute for the one OS, and causes the application program to operate on the substitute OS.

[0039] In the present embodiment, in a case where it is determined that the other OS that can cause the application program that should continue to operate to operate does not exist, the in-vehicle information processing device activates a substitute OS that becomes a substitute for the one OS that is restarted, and causes the application program to operate on the substitute OS. Thus, the in-vehicle information processing device can more reliably cause the application program that should continue to operate to operate.

[0040] (8) Preferably, the substitute OS is an OS that has a part of a plurality of functions possessed by the one OS.

[0041] In the present embodiment, the in-vehicle information processing device uses an OS that has a part of the functions of the one OS that is restarted as a substitute OS. Thus, compared to a case where an OS that has all the functions of the one OS is provided as a substitute OS, it is possible to reduce the amount of use of the storage area of the in-vehicle information processing device.

[0042] (9) Preferably, each application program is provided with a priority, and the control section determines the application program that should continue to operate during the restart of the one OS in accordance with the priority.

[0043] In the present embodiment, in accordance with the priority provided to the application program, the in-vehicle information processing device determines the application program that should continue to operate during the restart of the OS. Thus, the in-vehicle information processing device can cause, for example, an application program with a high priority to operate preferentially on the other OS.

[0044] (10) Preferably, the control section causes the plurality of OSs to operate in a virtual environment in which the hardware is virtualized.

[0045] In the present embodiment, the in-vehicle information processing device provides a virtual environment in which the hardware is virtualized, and causes the plurality of OSs to operate on the virtual environment. Thus, it is possible to expect an improvement in the versatility of the OSs that operate on the in-vehicle information processing device and an easy development, and the like.

[0046] (11) In the control method according to the present embodiment, a vehicle-mounted information processing apparatus mounted on a vehicle controls a plurality of OSs operating on common hardware, a control section of the vehicle-mounted information processing apparatus determines whether or not the plurality of OSs needs to be restarted, in a case where it is determined that one OS needs to be restarted, the control section of the vehicle-mounted information processing apparatus causes an application program operating on the one OS to operate on another OS different from the one OS, the control section of the vehicle-mounted information processing apparatus restarts the one OS, and after the restart is completed, the control section of the vehicle-mounted information processing apparatus causes the application program operating on the another OS to operate on the one OS.

[0047] In the present embodiment, as in the mode (1), it is possible to continue the processing of the application program even during the restart of the OS.

[0048] (12) The computer program according to the present embodiment causes a computer mounted on a vehicle to execute processing of controlling a plurality of OSs operating on common hardware, and causes the computer to execute processing of determining whether or not the plurality of OSs needs to be restarted, in a case where it is determined that one OS needs to be restarted, causing an application program operating on the one OS to operate on another OS different from the one OS, restarting the one OS, and after the restart is completed, causing the application program operating on the another OS to operate on the one OS.

[0049] In the present embodiment, as in the mode (1), it is possible to expect that the processing of the application program is continued even during the restart of the OS.

[0050] [Details of Embodiments of the Present Disclosure]

[0051] A specific example of a vehicle-mounted information processing system according to an embodiment of the present disclosure will be described below with reference to the drawings. The present disclosure is not limited to these examples, and is intended to be shown by the claims, including all modifications within the equivalent meaning and scope of the claims.

[0052] [Configuration of System]

[0053] Figure 1 is a schematic view showing a configuration example of a vehicle-mounted information processing system according to the present embodiment. The vehicle-mounted information processing system according to the present embodiment is a system in which a GW (Gateway) 2 and a plurality of ECUs 3 mounted on a vehicle 1 communicate via a plurality of communication lines, and these plurality of vehicle-mounted devices cooperate to perform various information processing related to travel control of the vehicle 1 and the like. In the example shown in the drawing, four ECUs 3 are connected to the GW 2 via separate communication lines. The GW 2 performs processing of relaying transmission and reception of messages between the communication lines, whereby the four ECUs 3 can transmit and receive messages to and from each other via the communication lines and the GW 2.

[0054] Also, the in-vehicle information processing system is provided with a wireless communication device 5 that performs wireless communication with the outside of the vehicle 1. The wireless communication device 5 is able to perform transmission and reception of messages with a server device provided outside the vehicle 1 or a smartphone or the like held by a user, for example, by performing wireless communication using a portable telephone communication network or a wireless LAN (Local Area Network) or the like. The wireless communication device 5 is connected to the GW 2 via a communication line. The GW 2 is able to perform transmission and reception of messages with a server device or the like outside the vehicle 1 via the wireless communication device 5. Also, the ECU 3 is able to perform transmission and reception of messages with a server device or the like outside the vehicle 1 via the GW 2 and the wireless communication device 5 by relaying communication between the ECU 3 and the wireless communication device 5 through the GW 2.

[0055] An IG signal from an IG (ignition) switch 6 provided to the vehicle 1 is input to the GW 2. The GW 2 is able to perform determination of the state of the vehicle 1, for example, determination of whether or not there is a possibility of the vehicle 1 traveling, based on the input IG signal. Also, determination of the state of the vehicle 1 can be performed based on various information such as the speed, acceleration, number of revolutions of the engine, state of the shift lever, or state of access of the vehicle 1, rather than the IG signal from the IG switch 6. In the GW 2, information necessary for determination of the state of the vehicle 1 is input directly or indirectly via communication.

[0056] The GW 2 operates by executing a plurality of application programs in order to perform various processes such as relay processing of messages and control processing of the vehicle 1. In the execution of the application programs, an OS is required to perform execution management of the programs and management of hardware resources and the like. The GW 2 according to the present embodiment causes a plurality of OSs to operate, whereby the plurality of application programs developed for different OSs can operate by one device. Also, the GW 2 causes a plurality of application programs to operate on each of the plurality of OSs while causing the plurality of OSs to operate in parallel. The GW 2 is able to cause the plurality of OSs and the plurality of application programs to operate in substantially parallel by, for example, switching and executing the plurality of OSs and the plurality of application programs by time division. Also, in the case where the GW 2 is provided with a plurality of arithmetic processing devices such as CPUs (Central Processing Units) or MPUs (Micro-Processing Units), the plurality of OSs and the plurality of application programs can actually operate in parallel by the plurality of arithmetic processing devices.

[0057] Software such as an application program and an OS is updated (update processing) for correction of a failure or addition of a new function, or the like. The GW 2 performs communication with a predetermined server device via the wireless communication device 5 to acquire software for update, and replaces software stored in a secondary storage device such as a flash memory or a hard disk to perform update. In the case where, for example, update of an OS is performed, the GW 2 needs to perform restart of the OS after completion of replacement of the software. Further, among the main causes of restart of the OS, not only the above-mentioned update but also various main causes such as a case where a certain failure occurs, or the like.

[0058] Conventionally, in the case where restart of an OS is performed, one or a plurality of application programs operating on the OS cannot operate until completion of the restart. The GW 2 according to the present embodiment can continue operation of an application program that should continue to operate without stopping operation in conjunction with restart of the OS even during the restart of the OS. Further, the present embodiment is exemplified by the GW 2, but the same technology is applicable to the ECU 3 or various in-vehicle information processing devices other than the same.

[0059] Figure 2 Fig. 1 is a block diagram showing a configuration of the GW 2 according to the present embodiment. The GW 2 according to the present embodiment is configured to include a control section (processor) 21, a primary storage section (memory) 22, a secondary storage section (memory) 23, and a plurality of communication sections (radio transceiver) 24, and the like. The control section 21 is configured to use an arithmetic processing device such as a CPU or an MPU. The control section 21 is able to perform various processing by executing a program stored in the secondary storage section 23 by reading out the program to the primary storage section 22.

[0060] The primary storage section 22 is configured to use a memory element such as an SRAM (Static Random Access Memory) or a DRAM (Dynamic Random Access Memory). The primary storage section 22 is a storage section having a smaller storage capacity than the secondary storage section 23 but in which the control section 21 is able to perform read and write of data at a higher speed than in the secondary storage section 23. The primary storage section 22 is set to a volatile storage section in the present embodiment, but can be set to a non-volatile storage section.

[0061] The secondary storage section 23 is configured using, for example, a nonvolatile memory element such as a flash memory or an EEPROM (Electrically Erasable Programmable Read Only Memory), or a magnetic storage device such as a hard disk. The secondary storage section 23 stores various programs executed by the control section 21 and various data required for processing by the control section 21. In the present embodiment, the secondary storage section 23 stores a program 23a executed by the control section 21 and an application table 23b having information on application programs.

[0062] The GW 2 according to the present embodiment realizes a hierarchical storage mechanism, so-called memory hierarchy, by two storage sections of the primary storage section 22 and the secondary storage section 23. In a case where the control section 21 of the GW 2 executes the program 23a, the program 23a stored in the secondary storage section 23 is read out to the primary storage section 22, and the program 23a stored in the primary storage section 22 is read out by the control section 21 and executed. In the present embodiment, the control section 21 performs various processing such as management of application programs based on an OS, control of the vehicle 1 based on the application programs, and management of the OS and the application programs, by executing the program 23a.

[0063] Further, in the program 23a, various programs such as a program of an OS and an application program are included, and further, a program that manages the actions of the OS and the application program is included. Figure 2 The program 23a can be written in the secondary storage section 23, for example, in a manufacturing stage of the GW 2. Further, for example, the program 23a can be transmitted by a remote server device or the like, and the GW 2 can acquire the program 23a by communication with the server device and write it in the secondary storage section 23. Further, it can be that, for example, the program 23a recorded in a recording medium 99 such as a memory card or an optical disk is read out by the GW 2 and stored in the secondary storage section 23. Further, it can be that, for example, the program 23a recorded in the recording medium 99 is read out by a writing device and written in the secondary storage section 23 of the GW 2. The program 23a can be provided in a manner of transmission via a network, or can be provided in a manner of recording in the recording medium 99. The various programs such as the OS and the application program included in the program 23a can be provided collectively, or can be provided in different methods respectively.

[0064] The application table 23b of the secondary storage section 23 stores a table of information on the application program executed by the GW 2. The GW 2 is able to determine which application program should continue to operate at the time of restart of the OS and the like based on the information stored in the application table 23b. The detailed configuration of the application table 23b will be described later. The application table 23b is created in advance by, for example, the developer of the present system or the like and stored in the secondary storage section 23. The application table 23b can be provided together with the program 23a or separately from the program 23a. In the case where the update of the OS or the application program included in the program 23a and the like is performed, the content of the application table 23b can also be updated.

[0065] The communication lines are connected to the plurality of communication sections 24, respectively, and perform transmission and reception of messages between the in-vehicle devices such as the ECU 3 or the wireless communication device 5 via the communication lines. In the present embodiment, the communication section 24 performs transmission and reception of messages in accordance with the communication specification of, for example, Ethernet (registered trademark). The communication section 24 can be configured using, for example, an IC (Integrated Circuit) of an Ethernet PHY (physical layer) or the like. Note that the communication specification used by the communication section 24 is not limited to Ethernet, and various communication specifications such as CAN (Controller Area Network) or FlexRay can be employed. The communication section 24 performs message transmission by outputting data supplied from the control section 21 to the communication line as an electric signal. Further, the communication section 24 acquires the electric signal on the communication line by sampling the potential of the communication line, converts the electric signal on the communication line into digital data, and supplies the converted data to the control section 21 as a received message.

[0066] In the present embodiment, the GW 2 reads out and executes the program 23a stored in the secondary storage section 23 by the control section 21, and the restart determination section 21a, the OS control section 21b, the application control section 21c, and the like are realized as functional sections of software in the control section 21. The restart determination section 21a performs processing to determine whether or not the restart is necessary for the OS that is operating. The restart determination section 21a performs, for example, update processing of the OS, and is able to determine that the restart of the OS is necessary in the case where the processing is completed. Further, the main reason for the restart of the OS is not limited to the update.

[0067] The OS control section 21b performs processing to manage the OS executed by the GW 2. The OS control section 21b performs control of the start, stop, restart, and update of the OS and the like. Further, in the present embodiment, the OS control section 21b performs processing to start a substitute OS for the OS at the time of restart of the OS.

[0068] The application control section 21c performs processing to manage the application programs executed in the GW 2. In the present embodiment, the application control section 21c determines, from among the application programs operating on the restarted OS, the application programs that should continue to operate during the restart of the OS based on the application table 23b of the secondary storage section 23. The application control section 21c executes the application programs that should continue to operate on an OS different from the restarted OS, and executes the application programs on the original OS after the restart is completed.

[0069] <application program control processing>

[0070] Figure 3 is a diagram for explaining the software configuration of the GW 2 according to the present embodiment. The GW 2 according to the present embodiment is executed by the control section 21 reading out the program 23a stored in the secondary storage section 23 to the primary storage section 22, and realizes the software configuration shown in Figure 3 . Figure 3 The hardware of the control section 21 and the primary storage section 22, etc. represents resources of the hardware. The GW 2 according to the present embodiment provides a virtual environment in which the hardware is virtualized to the OS. The virtual environment provides an interface assuming a predetermined virtual hardware configuration to the OS, regardless of the actual hardware configuration, etc. The virtual environment converts commands, etc. from the OS into commands suitable for the actual hardware to control the hardware. By interposing the virtual environment between the OS and the hardware, the same OS and application programs can be executed for other GW 2 having a different hardware configuration. The program for realizing the virtual environment can be generated for each hardware configuration.

[0071] In the GW 2 according to the present embodiment, in the normal operating state, for example, two OSs of the OS 1 and the OS 2 operate on the virtual environment. Also, for example, three application programs of the application 1 to the application 3 operate on the OS 1, and one application program of the application 4 operates on the OS 2. Also, in the present embodiment, the OS to which "OS 1" is attached as identification information is simply referred to as the OS 1, and the OS to which "OS 2" is attached as identification information is simply referred to as the OS 2. Similarly, the application program to which "application 1" is attached as identification information is simply referred to as the application 1, the application program to which "application 2" is attached is simply referred to as the application 2, and the application program to which "application 3" is attached is simply referred to as the application 3.

[0072] For example, in the case where the control section 21 of the GW 2 is an arithmetic processing device of a single processor or a single core, etc., the applications 1 to 4 operate in parallel by time division switching. Also, for example, in the case where the control section 21 of the GW 2 is an arithmetic processing device of a multi-processor or a multi-core, etc., the applications 1 to 4 operate in parallel at the same time. The difference in the hardware configuration is absorbed by the virtual environment, and thus the OSs 1 and 2 and the applications 1 to 4 operate regardless of the actual hardware configuration.

[0073] The two OSs 1, 2 of the GW 2 of the present embodiment can be, for example, OSs of different kinds such as Linux (registered trademark) and Windows (registered trademark), or can be, for example, different versions of the same kind of OS. The applications 1 to 4 can be, for example, application programs dedicated to the respective OSs, or can be, for example, application programs common to the plurality of OSs.

[0074] The GW 2 of the present embodiment reads out the OSs and the application programs stored as the programs 23a in the secondary storage 23 to the primary storage 22, and the control section 21 reads out and executes the OSs and the application programs stored in the primary storage 22. When the GW 2 executes the OSs by reading out the OSs from the secondary storage 23 to the primary storage 22, a storage area of a predetermined size of the primary storage 22 is allocated to each OS. In Figure 3 In the example shown in FIG. 8, the storage areas allocated to the OSs are shown by dotted-line rectangles. Each OS uses the storage area allocated to itself and cannot access the storage area allocated to the other OS.

[0075] Further, when the GW 2 reads out the application programs stored in the secondary storage 23 to the primary storage 22, the read-out application programs are stored in the storage area allocated to the OS that manages the application programs. In Figure 3 In the example shown in FIG. 8, the applications 1 to 3 are stored in the storage area of the OS 1, and the application 4 is stored in the storage area of the OS 2.

[0076] Figure 4 FIG. 9 is a diagram showing an example of an application table 23b of the GW 2. The application table 23b of the present embodiment stores the OS ID as identification information for identifying the OS, the application information on the application programs, and the necessary function information indicating the functions of the OS required for executing the application programs in correspondence. The application information includes the application ID as identification information for identifying the application program, the data size of the application program, and the possibility of stopping the application program at the time of OS restart. The necessary function information includes the kind of the kernel of the OS required for executing the application program, whether the driver A to C is required, whether the library A, B is required, and the data size of the necessary function. In the present example, as shown in Figure 3 As shown in FIG. 8, the GW 2 is configured to make the two OSs 1, 2 operate, make the applications 1 to 3 operate on the OS 1, and make the application 4 operate on the OS 2, and the configuration example of the application table 23b is shown.

[0077] In the illustrated application table 23b, the data amount of the program of the application 1 that operates on the OS 1 at the time of normal operation is 5 MB (megabytes), and the stop operation at the time of the restart of the OS 1 is set to be impossible (prohibited). Further, the application 1 can operate regardless of either of the kernels of the OS 1 and the OS 2, and requires the drivers A, C and the library B, and the data amount of the program with respect to these necessary functions is 30 MB.

[0078] Likewise, the data amount of the program of the application 2 that operates on the OS 1 at the time of normal operation is 3 MB, and the stop operation at the time of the restart of the OS 1 is set to be impossible. Further, the application 2 can operate only in the kernel of the OS 1, and requires the drivers B and the libraries A, B, and the data amount of the program with respect to these necessary functions is 20 MB.

[0079] The data amount of the program of the application 3 that operates on the OS 1 at the time of normal operation is 10 MB, and is set to be possible (permitted) to stop the operation at the time of the restart of the OS 1. Further, the application 3 can operate only in the kernel of the OS 1, and requires the drivers A, B, C and the libraries A, B, and the data amount of the program with respect to these necessary functions is 50 MB.

[0080] The data amount of the program of the application 4 that operates on the OS 2 at the time of normal operation is 5 MB, and is set to be possible to stop the operation at the time of the restart of the OS 2. Further, the application 4 can operate in either of the kernels of the OS 1 and the OS 2, and requires the drivers A, C and the library B, and the data amount of the program with respect to these necessary functions is 30 MB.

[0081] Figure 5 is a diagram for explaining a software configuration in the case where the GW 2 performs the restart of the OS 1 according to the present embodiment. In the case where, for example, the update completion of the OS 1 is generated and the necessity of the restart is generated, the GW 2 refers to the application table 23b stored in the secondary storage section 23, and determines the application programs that are impossible to stop during the restart, that is, the application programs that should continue the operation, among the applications 1 to 3 that operate on the OS 1. In this example, the applications 1 and 2 that operate on the OS 1 are set to be impossible to stop.

[0082] The application 1 in this example, among the application programs that are impossible to stop, is able to operate on the OS 2. The GW 2 acquires the free capacity of the storage area of the OS 2, and determines whether 5 MB, which is the data amount required to make the application 1 operate, can be ensured in the storage area of the OS 2. In the case where the free capacity of the storage area of the OS 2 is 5 MB or more, the GW 2 copies the application 1 stored in the storage area of the OS 1 to the storage area of the OS 2. At this time, the GW 2 copies not only the program code of the application 1 but also the data (for example, the values stored in the variables) that the application 1 uses for the processing at the time. After that, the GW 2 switches the operation from the application 1 on the OS 1 to the application 1 on the OS 2.

[0083] The application 2 in the non-stoppable application program in this example acts only on the OS 1. The GW 2 refers to the application table 23B to determine the functions of the OS required for the operation of the application 2. In this example, the kernel of the OS 1, the driver B, and the libraries A and B are required. The GW 2 acquires the free capacity of the primary storage section 22 and determines whether 3 MB as the data amount of the application 2 and 20 MB as the data amount of the functions required for the operation of the application 2 can be secured in the available area of the primary storage section 22. In the case where the free capacity of the primary storage section 22 is 23 MB or more, the GW 2 first generates a simple OS 1 that extracts the necessary functions (the kernel of the OS 1, the driver B, and the libraries A and B in this example) from the OS 1, causes the simple OS 1 to start and operate on the virtual environment. Further, the simple OS 1 can be identical to the OS 1. Next, the GW 2 copies the application 2 stored in the storage area of the OS 1 to the storage area of the simple OS 1 and switches the operation from the application 2 on the OS 1 to the application 2 on the simple OS 1.

[0084] In the case where the free capacity of the storage area of the OS 2 is not sufficient for the application 1 or in the case where the free capacity of the primary storage section 22 is not sufficient for the simple OS 1 and the application 2, the GW 2 cannot cause the applications 1 and 2 to operate during the restart of the OS 1, and thus stands by without restarting the OS 1. In this case, the GW 2 can restart the OS 1 if the IG switch 6 of the vehicle 1 is in the off state. If the IG switch 6 of the vehicle 1 is in the on state, the GW 2 restarts the OS 1 if the IG switch 6 is switched from the on state to the off state. Further, in the case where the OS 1 is restarted with the IG switch 6 in the off state, the GW 2 can stop the applications 1 and 2 from operating and restart the OS 1 without continuing the operation of the applications 1 and 2 as described above.

[0085] After the restart of the OS 1 is completed, the GW 2 causes the application 1 operating on the OS 2 and the application 2 operating on the simple OS 1 to operate on the restarted OS 1. At this time, the GW 2 copies the application 1 from the storage area of the OS 2 to the storage area of the OS 1 and switches the operation from the application 1 on the OS 2 to the application 1 on the OS 1. Similarly, the GW 2 copies the application 2 from the storage area of the simple OS 1 to the storage area of the OS 1 and switches the operation from the application 2 on the simple OS 1 to the application 2 on the OS 1. Further, the GW 2 causes the application 3 stopped from operating in conjunction with the restart of the OS 1 to start and operate.

[0086] Further, the GW2 deletes the application 1 stored in the storage area of the OS 2 and the simple OS 1 stored in the one-time storage section 22 and the application 2 stored in the storage area of the simple OS 1 after the restart of the OS 1 is completed and the applications 1, 2 on the OS 1 start to act. Further, in the present embodiment, the deletion of the information such as the program and the data stored in the one-time storage section 22 includes not only the case where the area storing the information is initialized to the initial value such as all "0" but also the case where the storage area is managed in such a manner that other information can be written to the area storing the information.

[0087] <flowchart>

[0088] Figure 6 and Figure 7 is a flowchart showing the sequence of the OS restart processing by the GW2 according to the present embodiment. The restart determination section 21a of the control section 21 of the GW2 according to the present embodiment determines whether or not the restart is required for one or more OSs in operation (step S1). In the case where it is determined that the restart is not required for all the OSs (S1: No), the restart determination section 21a stands by until the restart of the OS is required.

[0089] In the case where it is determined that the restart is required for at least one OS (S1: Yes), the application control section 21c of the control section 21 refers to the application table 23b (step S2). The application control section 21c determines, based on the application table 23b, whether or not there is an application program that cannot be stopped during the restart of the OS among the application programs in operation at that time (step S3). In the case where there is no application program that cannot be stopped (S3: No), the OS control section 21b of the control section 21 performs the restart for the OS for which the restart is required (step S4), and ends the processing.

[0090] In the case where there is an application program that cannot be stopped (S3: Yes), the application control section 21c selects one application program that is set as the processing target from one or more application programs that cannot be stopped (step S5). The application control section 21c determines, based on the application table 23b, whether or not the application program selected in step S5 can act on the other OS (step S6). In the case where it is possible for the other OS to act (S6: Yes), the application control section 21c acquires the free capacity of the storage area of the other OS (step S7). The application control section 21c compares the free capacity acquired in step S7 and the capacity required for the act of the application program that is the processing target, and determines whether or not the free capacity is the necessary capacity or more (step S8). In the case where the free capacity does not satisfy the necessary capacity (S8: No), the control section 21 stands by for the restart of the OS (step S9), and ends the processing.

[0091] In a case where the free capacity is equal to or more than the necessary capacity (S8: YES), the application control section 21c copies the application program of the processing target from the storage area of the restarted OS to the storage area of the other OS (step S10). The application control section 21c determines whether or not the copying to the other OS is completed for all the non-stop application programs (step Sll). In a case where the copying is not completed for all the non-stop application programs (Sll: NO), the application control section 21c returns the processing to step S5, and selects another application program to perform the same processing. In a case where the copying is completed for all the non-stop application programs (Sll: YES), the application control section 21c proceeds to step S18.

[0092] Further, the application control section 21c acquires the free capacity of the one-time storage section 22 in a case where it is determined that the application program selected at step S5 cannot operate in the other OS (S6: NO) (step S12). The application control section 21c compares the free capacity acquired at step S12 with the capacity required for the operation of the application program of the processing target and the simple OS that causes the operation thereof, and determines whether or not the free capacity is equal to or more than the necessary capacity (step S13). In a case where the free capacity does not satisfy the necessary capacity (S13: NO), the control section 21 causes the OS to stand by for the restart (step S14), and ends the processing.

[0093] In a case where the free capacity is equal to or more than the necessary capacity (S14: YES), the OS control section 21b generates and starts the simple OS that extracts the function required for the operation of the application program from the restarted OS (step S15). The application control section 21c copies the application program of the processing target from the storage area of the restarted OS to the storage area of the simple OS started at step S15 (step S16). The application control section 21c determines whether or not the copying to the other OS (simple OS) is completed for all the non-stop application programs (step S17). In a case where the copying is not completed for all the non-stop application programs (S17: NO), the application control section 21c returns the processing to step S5, and selects another application program to perform the same processing. In a case where the copying is completed for all the non-stop application programs (S17: YES), the application control section 21c proceeds to step S18.

[0094] The application control section 21c starts the application program copied at steps S10 and S16 (step S18). The application control section 21c performs switching from the application program operating on the restarted OS to the application program started at step S18 (step S19). The OS control section 21b restarts the OS requiring restart (step S20). After the restart of the OS is completed, the application program temporarily operating on the other OS or the simple OS is copied and started to the storage area of the restarted OS, and switching from the application program operating on the other OS or the simple OS to the application program of the restarted OS is performed (step S21). The application control section 21c deletes the application program temporarily copied to the storage area of the other OS and the simple OS (step S22), and ends the process.

[0095] Figure 8 is a flowchart showing the sequence of standby processing performed by the GW 2 according to the present embodiment. The control section 21 of the GW 2 according to the present embodiment starts the process of the flowchart shown in Figure 7 at step S9 or S14 in which the restart of the OS is on standby. The control section 21 starts the process of the flowchart shown in Figure 8 . The control section 21 acquires an IG signal supplied from the IG switch 6 of the vehicle 1 (step S31). The control section 21 determines whether the IG switch 6 is in an off state on the basis of the acquired IG signal (step S32). In the case where the IG switch 6 is in an on state (S32: No), the control section 21 returns the process to step S31 to put the restart of the OS on standby until the IG switch 6 is switched from the on state to the off state. In the case where the IG switch 6 is in the off state (S32: Yes), the OS control section 21b of the control section 21 restarts the OS on standby (step S33), and ends the process.

[0096] <Summary>

[0097] The GW 2 according to the present embodiment having the above-described configuration controls a plurality of OSs operating on common hardware. The GW 2 determines whether the plurality of OSs require restart, and in the case where it is determined that one OS requires restart, causes an application program operating on the one OS to operate on the other OS. Thereafter, the GW 2 restarts the one OS, and after the restart is completed, causes the application program operating on the other OS to operate on the one OS. Thus, the GW 2 can execute the application program operating on the one OS on the other OS, and can continue the processing of the application program even during the restart of the one OS.

[0098] Further, the GW 2 according to the present embodiment causes the other OS to operate in parallel during the restart of the one OS. Thus, the GW 2 can cause the application program to be executed in parallel on the other OS during the restart of the one OS.

[0099] Further, the GW 2 according to the present embodiment copies an application stored in a storage area used by one OS to a storage area used by another OS, in a case where the application operating on one OS is caused to operate on another OS. The GW 2 deletes the copied application from the storage area of another OS after completion of the restart of one OS. Thus, the GW 2 can copy the application from the storage area of one OS and cause the application to operate on another OS, and thus it is not necessary to separately prepare an application that operates on another OS.

[0100] Further, the GW 2 according to the present embodiment determines an application that should continue to operate during the restart of one OS, from one or more applications operating on one OS determined to require a restart. The GW 2 determines whether there is another OS that can cause the application that should continue to operate to operate. The GW 2 determines whether there is free capacity to store the application in a storage area of another OS determined to be able to cause the application to operate. In a case where it is determined that there is free capacity, the GW 2 causes the application to operate by copying the application to the storage area of another OS. Through these processes, it is expected that the GW 2 can more reliably cause the application that should continue to operate to operate during the restart of one OS.

[0101] Further, the GW 2 according to the present embodiment stands by the restart of one OS in which the application operates, in a case where there is no free capacity to store the application in the storage area of another OS. Thus, it is possible to prevent the application that should continue to operate from stopping.

[0102] Further, the GW 2 according to the present embodiment restarts one OS in a case where the restart of one OS is standing by, after the IG switch 6 of the vehicle 1 is switched from the on state to the off state. Thus, the GW 2 can restart one OS at a stage where it is highly likely that the user has completed use of the vehicle 1, that is, a stage where it is highly likely that there will be no problem even if the processing of the application stops.

[0103] Further, the GW 2 according to the present embodiment starts a substitute OS (simple OS) that has a function of one OS that is to be restarted, in a case where it is determined that there is no other OS that can cause the application that should continue to operate to operate, and causes the application to operate on the substitute OS. Thus, the GW 2 can more reliably cause the application that should continue to operate to operate.

[0104] Further, the GW 2 according to the present embodiment uses a simple OS that has a part of the function of one OS that is to be restarted, as a substitute OS. Thus, compared to a case where an OS that has all the functions of one OS is provided as a substitute OS, it is possible to reduce the amount of use of the storage area of the GW 2.

[0105] Further, the GW 2 according to the present embodiment provides a virtual environment in which hardware is virtualized to the OS, and causes a plurality of OSs to operate on the virtual environment. Thus, it is expected that the versatility of the OSs operating on the GW 2 is improved, and development is facilitated, and the like.

[0106] Further, in the present embodiment, a configuration in which a separate storage area is allocated to each of the plurality of OSs is assumed, but the present embodiment is not limited thereto. For example, a configuration in which one storage area is shared by the plurality of OSs can also be assumed, and in this case, the application program is not duplicated, and thus the application program can be caused to operate on the other OS. Further, in the present embodiment, the software to be restarted is assumed to be an OS, but the present embodiment is not limited thereto, and can be, for example, an interpreter or a VM (Virtual Machine), or the like, or can be basic software that provides an execution environment for an application program.

[0107] (Modified Example)

[0108] Figure 9 Fig. 23B is a diagram showing an example of an application table 23b of the GW 2 according to the modified example. Figure 9 The application table 23b according to the modified example shown in Fig. 23B is provided with information of "priority" for each application program, instead of the "stop possibility" of the application table 23b shown in Fig. 23A. Figure 4 In the present example, the priority is set in three stages of 1 to 3, and priority 1 is assumed to be the highest priority.

[0109] The GW 2 according to the modified example judges the application program of priority 1 to be an application program that is not stopped at the time of OS restart, and causes the application program to operate on the other OS. In a case where the application program of priority 1 cannot be caused to operate on the other OS, the GW 2 stands by for the restart of the OS. That is, the application program of priority 1 is handled in the same manner as the application program for which the stop possibility is set to be impossible in the application table 23b shown in Fig. 23A. Figure 4

[0110] The GW 2 according to the modified example judges the application program of priority 2 to continue operating at the time of OS restart, as long as possible. The GW 2 first prepares for execution on the other OS, such as duplication, of the application program of priority 1, and then determines whether the application program of priority 2 can be caused to operate on the other OS. In a case where there is sufficient space in the storage area of the other OS, or in a case where the application program of priority 2 can be caused to operate on the other OS, the GW 2 causes the application program of priority 2 to be duplicated to the storage area of the other OS and operate. Even in a case where the application program of priority 2 cannot be caused to operate on the other OS, the GW 2 performs the restart of the OS.

[0111] The GW 2 according to the modified example judges the application program of priority 3 to be an application program that does not need to continue operating at the time of OS restart. That is, the application program of priority 3 is handled in the same manner as the application program for which the stop possibility is set to be impossible in the application table 23b shown in Fig. 23A.​Figure 4 The application programs in which the stopability setting in Table 23b shown in FIG. 23b can be set to possible are handled in the same manner. Among them, GW2 can continue the action during the OS restart as long as the action of the other OS is possible for the application program of priority 3.

[0112] The GW2 involved in the modification example of the above configuration determines the application program that should continue the action during the OS restart according to the priority set to the application program. Thereby, GW2 can, for example, cause the application program of high priority to act preferentially on the other OS.

[0113] Each device in the in-vehicle information processing system is provided with a computer configured of a microprocessor, a ROM, a RAM, and the like. The operation processing section of the microprocessor or the like can read and execute a computer program of part or all of each step of the time chart or flowchart shown in FIG. 25 from the storage section such as the ROM, the RAM, and the like. The computer programs of the plurality of devices can be installed from an external server device or the like, respectively. In addition, the computer programs of the plurality of devices are circulated in a state of being stored in a recording medium such as a CD-ROM, a DVD-ROM, a semiconductor memory, and the like, respectively. Figures 6-8 The operation processing section of the microprocessor or the like can read and execute a computer program of part or all of each step of the time chart or flowchart shown in FIG. 25 from the storage section such as the ROM, the RAM, and the like. The computer programs of the plurality of devices can be installed from an external server device or the like, respectively. In addition, the computer programs of the plurality of devices are circulated in a state of being stored in a recording medium such as a CD-ROM, a DVD-ROM, a semiconductor memory, and the like, respectively.

[0114] The embodiments disclosed this time illustrate the application in all points, and should be considered as non-limiting. The scope of the disclosure is not the above meaning, and is intended to be shown by the claims, including all modifications within the equivalent meaning and scope of the claims.

[0115] Explanation of Reference Signs

[0116] 1 vehicle

[0117] 2 GW

[0118] 3 ECU

[0119] 5 wireless communication device

[0120] 6 IG switch

[0121] 21 control section

[0122] 21a restart determination section

[0123] 21b OS control section

[0124] 21c application control section

[0125] 22 primary storage section

[0126] 23 secondary storage section

[0127] 23a program

[0128] 23b application table

[0129] 24 communication section.

Claims

1. An in-vehicle information processing apparatus mounted on a vehicle and including a control unit that controls a plurality of OSs operating on a common hardware, the OSs being operating systems, wherein the in-vehicle information processing apparatus includes a storage unit that temporarily stores the operating OSs and application programs, the control unit determines whether the plurality of OSs need to be restarted, in a case where it is determined that one OS needs to be restarted, the control unit causes an application program operating on the one OS to operate on another OS different from the one OS, in a case where the application program operating on the one OS is caused to operate on the other OS, the control unit copies the application program stored in one storage area of the storage unit used by the one OS to another storage area of the storage unit used by the other OS, the control unit restarts the one OS, after the restart is completed, the control unit causes the application program operating on the other OS to operate on the one OS.

2. The in-vehicle information processing apparatus according to claim 1, wherein the control unit causes the other OS to operate concurrently during the restart of the one OS.

3. The in-vehicle information processing apparatus according to claim 1, wherein the control unit deletes the application program copied to the other storage area after the restart of the one OS is completed.

4. The in-vehicle information processing apparatus according to claim 2, wherein the control unit deletes the application program copied to the other storage area after the restart of the one OS is completed.

5. The in-vehicle information processing apparatus according to claim 3, wherein in a case where it is determined that the one OS needs to be restarted, the control unit determines, from one or more application programs operating on the one OS, an application program that should continue to operate during the restart of the one OS, the control unit determines whether there is another OS that can cause the application program determined to be the application program that should continue to operate to operate, the control unit determines whether there is free capacity in another storage area used by the other OS determined to be the other OS that can cause the application program to operate to store the application program, in a case where it is determined that there is free capacity, the control unit copies the application program to the other storage area.

6. The in-vehicle information processing apparatus according to claim 4, wherein in a case where it is determined that the one OS needs to be restarted, the control unit determines, from one or more application programs operating on the one OS, an application program that should continue to operate during the restart of the one OS, the control unit determines whether there is another OS that can cause the application program determined to be the application program that should continue to operate to operate, the control unit determines whether there is free capacity in another storage area used by the other OS determined to be the other OS that can cause the application program to operate to store the application program, in a case where it is determined that there is free capacity, the control unit copies the application program to the other storage area.

7. The in-vehicle information processing apparatus according to claim 5, wherein ​ ​ ​ ​ ​ ​ In a case where it is determined that the free capacity does not exist, the control section causes the one OS to stand by for restart.

8. The in-vehicle information processing apparatus according to claim 6, wherein In a case where it is determined that the free capacity does not exist, the control section causes the one OS to stand by for restart.

9. The in-vehicle information processing apparatus according to claim 7, wherein The control section causes the one OS that stands by to restart after the ignition switch of the vehicle is switched from the on state to the off state.

10. The in-vehicle information processing apparatus according to claim 8, wherein The control section causes the one OS that stands by to restart after the ignition switch of the vehicle is switched from the on state to the off state.

11. The in-vehicle information processing apparatus according to any one of claims 3 to 10, wherein In a case where it is determined that the other OS does not exist, the control section starts a substitute OS that becomes a substitute for the one OS, The control section causes the application program to act on the substitute OS.

12. The in-vehicle information processing apparatus according to claim 11, wherein The substitute OS is an OS that has a part of a plurality of functions possessed by the one OS.

13. The in-vehicle information processing apparatus according to any one of claims 3 to 10, wherein Each application program is provided with a priority, The control section determines, based on the priority, an application program that should continue to act during restart of the one OS.

14. The in-vehicle information processing apparatus according to any one of claims 1 to 10, wherein The control section causes the plurality of OSs to act in a virtual environment in which the hardware is virtualized.

15. A control method of controlling, by an in-vehicle information processing apparatus mounted on a vehicle, a plurality of OSs that act on common hardware, The in-vehicle information processing apparatus is provided with a storage section that temporarily stores an acting OS and an application program, The control method includes the following steps: A control section of the in-vehicle information processing apparatus determines whether the plurality of OSs need to be restarted, In a case where it is determined that one OS needs to be restarted, the control section of the in-vehicle information processing apparatus causes an application program that acts on the one OS to act on another OS different from the one OS, In a case where the application program that acts on the one OS is caused to act on the other OS, the control section copies the application program stored in one storage area of the storage section used by the one OS to another storage area of the storage section used by the other OS, The control section of the in-vehicle information processing apparatus restarts the one OS, After the restart is completed, the control section of the in-vehicle information processing apparatus causes the application program that acts on the other OS to act on the one OS.

16. A computer program product including a computer program that, when executed, causes a computer mounted on a vehicle to execute processing of controlling a plurality of OSs that act on common hardware, The computer program causes the computer provided with a storage section that temporarily stores an acting OS and an application program to execute the following processing: determining whether the plurality of OSs need to be rebooted; in a case where it is determined that one of the OSs needs to be rebooted, causing an application program operating on the one OS to operate on another OS different from the one OS; in a case where the application program operating on the one OS is caused to operate on the other OS, the control section copying the application program stored in one storage area of the storage section used by the one OS to another storage area of the storage section used by the other OS, rebooting the one OS; after the rebooting is completed, causing the application program operating on the other OS to operate on the one OS.

Images