On-vehicle device, application test system, application test method, and program

JPWO2025197929A1Pending Publication Date: 2025-09-25
View PDF 0 Cites 0 Cited by

Patent Information

Authority / Receiving Office
JP · JP
Patent Type
Applications
Filing Date
2025-03-18
Publication Date
2025-09-25
Patent Text Reader

Abstract

A first processing part (53) executes an application on a real-time operating system. A second processing part (54) executes an application on a general-purpose operating system. When a development application, which is an application under development, and additional information associated with the development application are acquired from the outside, an application management part (72): determines, on the basis of the additional information, an execution destination, that is, whether to execute the development application on the first processing part or the second processing part; and causes, according to the result of the determination, the first processing part or the second processing part to execute the development application.
Need to check novelty before this filing date? Find Prior Art

Description

On-vehicle device, application test system, application test method, and program CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This international application claims priority based on Japanese Patent Application No. 2024-047023, filed with the Japan Patent Office on March 22, 2024, the entire contents of which are incorporated herein by reference.

[0002] The present disclosure relates to a technology for executing an application program distributed to a vehicle.

[0003] Japanese Patent Application Laid-Open No. 2003-124994 describes a technique for distributing an application program (hereinafter referred to as an app) to a vehicle and testing it in an environment where the app is actually installed.

[0004] US Patent Application Publication No. 2017 / 0132118

[0005] However, as a result of detailed consideration by the inventors, it was found that when an application under development is run in a real vehicle environment, it is not possible to flexibly change the placement of the application in the vehicle depending on the vehicle conditions, the development stage of the application, etc. Here, placement of the application means, when there are multiple pieces of hardware and multiple operating systems (hereinafter referred to as OS) on which the application is to be executed.

[0006] One aspect of the present disclosure provides a technique that allows easy selection of the placement of application programs in a vehicle.

[0007] One aspect of the present disclosure is an in-vehicle device comprising one or more first processing units, one or more second processing units, an acquisition unit, and an application management unit. The first processing unit is configured to execute an application on a real-time operating system. The second processing unit is configured to execute an application on a general-purpose operating system. The acquisition unit is configured to acquire a development application, which is an application under development, and additional information associated with the development application from outside the vehicle in which the in-vehicle device is mounted. The application management unit is configured to determine whether the development application should be executed by the first processing unit or the second processing unit based on the additional information, and to have the development application executed by the first processing unit or the second processing unit according to the result of the determination.

[0008] With this configuration, the developed application can be run on an appropriate operating system as intended by the creator of the additional information.

[0009] One aspect of the present disclosure is an application test system including an application storage unit, an in-vehicle device, and a log storage unit. The application storage unit stores a development application, which is an application under development to be executed in a vehicle. The in-vehicle device is mounted on the vehicle and configured to execute the development application obtained from the application storage unit. The log storage unit stores a processing log obtained by executing the development application from the in-vehicle device that has obtained the development application. The in-vehicle device includes one or more first processing units, one or more second processing units, an acquisition unit, an application management unit, and a data collection unit. The first processing unit is configured to execute the application on a real-time operating system. The second processing unit is configured to execute the application on a general-purpose operating system. The acquisition unit is configured to acquire the development application and additional information associated with the development application from the application storage unit. The application management unit is configured to determine whether the development application is to be executed by the first processing unit or the second processing unit based on the additional information, and to have the development application executed by the first processing unit or the second processing unit according to the determination result. The data collection unit is configured to store, in the log storage unit, a processing log obtained by the first processing unit and the second processing unit executing the developed application.

[0010] With this configuration, the developed application can be run on an appropriate operating system intended by the creator of the additional information, and processing logs obtained by executing the developed application can be collected.

[0011] One aspect of the present disclosure is a method for testing an application in an in-vehicle device, the in-vehicle device comprising: a first processing unit configured to execute the application on a real-time operating system; and a second unit configured to execute the application on a general-purpose operating system.

[0012] The method for testing an application includes obtaining a development application, which is an application under development, and additional information linked to the development application from outside the vehicle in which the on-board device is installed, determining whether the development application will be executed by a first processing unit or a second processing unit based on the additional information, and having the development application executed by the first processing unit and the second processing unit based on the result of the determination of the execution unit.

[0013] By implementing this method, it is possible to obtain the same effects as those of the above-mentioned in-vehicle device.

[0014] One aspect of the present disclosure is a program that causes a computer installed in a vehicle to function as one or more first processing units, one or more second processing units, an acquisition unit, and an application management unit. The first processing unit is configured to execute an application on a real-time operating system. The second processing unit is configured to execute an application on a general-purpose operating system. The acquisition unit is configured to acquire a development application, which is an application under development, and additional information associated with the development application from outside the vehicle. The application management unit is configured to determine whether the development application should be executed by the first processing unit or the second processing unit based on the additional information, and to cause the development application to be executed by the first processing unit or the second processing unit according to the result of the determination.

[0015] By executing such a program, it is possible to obtain the same effects as the above-mentioned in-vehicle device.

[0016] 1 is a block diagram showing the configuration of an application test system. FIG. 2 is a block diagram showing the configuration of a center. FIG. 3 is a block diagram showing the configuration of a data collection device. FIG. 4 is a block diagram showing the configuration of an in-vehicle system. FIG. 5 is a block diagram showing the functional configuration of a computer system in a first embodiment. FIG. 6 is a flowchart of an execution destination determination process. FIG. 7 is a flowchart of a GPOS application startup process. FIG. 8 is a flowchart of an RTOS application startup process. FIG. 9 is a block diagram showing the functional configuration of a computer system in a second embodiment. FIG. 10 is a main part of a flowchart of an application startup process. FIG. 11 is a part of a flowchart of an application startup process. FIG. 12 is a block diagram showing the functional configuration of a computer system in a third embodiment. FIG. 13 is a flowchart of an execution destination determination process. FIG. 14 is a block diagram showing another example configuration of a computer system.

[0017] Hereinafter, embodiments of the present disclosure will be described with reference to the drawings.

[0018] [1. First Embodiment] [1-1. Configuration] An application test system 1 shown in FIG. 1 includes a plurality of data collection devices 2 that can access a cloud via a wide area wireless communication network NW, and a center 3 provided by the cloud.

[0019] The data collection device 2 is mounted on a vehicle and has a function of performing data communication with the center 3. Hereinafter, the vehicle on which the data collection device 2 is mounted will be referred to as the host vehicle.

[0020] The center 3 has a function of performing data communication with a plurality of data collection devices 2 via the wide area wireless communication network NW.

[0021] The center 3 distributes an application program under development (hereinafter, a developed application) to be executed by the data collection device 2 to one or more data collection devices 2. The data collection device 2 executes the developed application distributed from the center 3 in shadow mode, collects various data obtained by executing the developed application as a processing log, and uploads the collected processing log to the center 3.

[0022] Shadow mode is a mechanism that allows an app to run without being activated in the actual vehicle. Activation means that the actual vehicle control is performed based on the processing results of the app.

[0023] As shown in FIG. 2, the center 3 includes a control unit 31 , a communication unit 32 , and a storage unit 33 .

[0024] The control unit 31 is an electronic control device mainly composed of a microcomputer including a CPU 311, a ROM 312, a RAM 313, etc. Various functions of the microcomputer are realized by the CPU 311 executing a program stored in a non-transitory tangible recording medium. In this example, the ROM 312 corresponds to the non-transitory tangible recording medium storing the program. Furthermore, the execution of this program executes a method corresponding to the program. Note that some or all of the functions executed by the CPU 311 may be configured as hardware using one or more ICs, etc. Furthermore, the number of microcomputers constituting the control unit 31 may be one or more.

[0025] The communication unit 32 performs data communication with a plurality of data collection devices 2 via the wide area wireless communication network NW.

[0026] The storage unit 33 is a storage device for storing various data, and includes an application DB 331 and a processing log DB 332.

[0027] The application DB 331 stores developed applications to be distributed to the data collection device 2. The application DB 331 may also store additional information associated with each developed application. The additional information is information used to specify the location of the developed application. The location of the developed application indicates where the developed application is to be executed (hereinafter, the execution destination). The additional information may be, for example, information indicating the attributes of the developed application (hereinafter, attribute information). The attribute information may be, for example, information indicating the progress of the developed application. In this embodiment, a developed application that is in the final stage of development and is close to release is referred to as a beta version, and a developed application that is in a non-final stage before the final stage and requires time to be released is referred to as an alpha version. Hereinafter, an alpha version developed application will be referred to as an alpha version application, and a beta version developed application will be referred to as a beta version application. The additional information may be information specifying the type of OS on which the developed application will be executed (hereinafter, specification information). The type of OS may include a real-time operating system (hereinafter, RTOS) and a general-purpose operating system (hereinafter, GPOS). Furthermore, the additional information may include resource information indicating the amount of resources required to execute the developed application (hereinafter referred to as the required resource amount), etc. The required resource amount may include the CPU utilization rate, memory usage, etc.

[0028] The processing log DB 332 stores processing logs relating to developed applications that are uploaded from the data collection devices 2 to which the developed applications have been distributed.

[0029] The CPU 311 of the control unit 31 executes at least an application distribution process and a data collection process. The application distribution process is a process of distributing a developed application and additional information stored in the application DB 331 to a specified data collection device 2 in accordance with an external instruction, etc. The data collection process is a process of storing a processing log uploaded from the data collection device 2 in the processing log DB 332.

[0030] As shown in FIG. 3 , the data collection device 2 includes a control unit 11 , a vehicle interface (hereinafter referred to as vehicle I / F) 12 , a communication unit 13 , and a storage unit 14 .

[0031] The control unit 11 includes a CPU 21 , a ROM 22 , and a RAM 23 .

[0032] The CPU 21 is a multi-core processor having multiple core processors.

[0033] The various functions of the CPU 21 are realized by the CPU 21 executing a program stored in a non-transitory physical recording medium. In this example, the ROM 22, RAM 23, and storage unit 24 correspond to the non-transitory physical recording medium that stores the program. Furthermore, the execution of this program executes a method corresponding to the program. Note that some or all of the functions realized by the CPU 21 may be realized by hardware such as at least one IC.

[0034] The control unit 11 may be configured using an SoC (System on a Chip) in which some or all of the functions required for system operation are implemented on a single semiconductor chip. The number of SoCs that make up the control unit 11 may be one or more.

[0035] The vehicle I / F 12 is an input / output circuit for transmitting and receiving signals between the data collection device 2 and other electronic control devices, sensors, etc. The vehicle I / F 12 may include, for example, a power supply voltage input port, a general-purpose input / output port, a CAN communication port, an Ethernet communication port, a wireless LAN communication port, a short-range wireless communication port, a GPS communication port, and a camera communication port. CAN is an abbreviation for Controller Area Network. Ethernet is a registered trademark.

[0036] The power supply voltage input port is connected to a battery of the host vehicle that serves as the power source for the data collection device 2. A power supply voltage is input to the power supply voltage input port.

[0037] The CAN communication port is a port for transmitting and receiving data in accordance with the CAN communication protocol, and the Ethernet communication port is a port for transmitting and receiving data based on the Ethernet communication protocol.

[0038] The CAN communication port and the Ethernet communication port are connected to other electronic control units mounted on the vehicle, so that the data collection device 2 can transmit and receive communication frames to and from the other electronic control units.

[0039] The wireless LAN communication port is a port for transmitting and receiving data via a wireless LAN. The short-range wireless communication port is a port for transmitting and receiving data using short-range wireless communication technology such as Bluetooth. Bluetooth is a registered trademark. The wireless LAN communication port and the short-range wireless communication port can be connected to a communication control device, and the data collection device 2 transmits and receives data to and from other electronic control devices via the communication control device connected to the port.

[0040] The GPS communication port is a port to which a device equipped with a GPS is connected. The data collection device 2 controls the GPS via the GPS communication port.

[0041] The camera communication port is a port to which a camera mounted on the vehicle is connected. The camera is configured to capture images of at least one of the surroundings and the interior of the vehicle. The data collection device 2 controls the camera via the camera communication port.

[0042] In addition to this, various devices such as a device for performing machine learning or a monitor can be connected to the general-purpose input / output port of the vehicle I / F 12.

[0043] The communication unit 13 accesses the wide area wireless communication network NW by wireless communication according to a communication standard such as LTE, and performs data communication with a center 3 provided in the cloud via the wide area wireless communication network NW. The communication unit 13 may be connected to the data collection device 2 via the vehicle I / F 12. In this case, the communication unit 13 may be an external vehicle communication device 240 described later.

[0044] The storage unit 14 is a storage device for storing various data. The storage unit 14 may be configured in part or in whole using a data-rewritable non-volatile memory such as a flash memory. The storage unit 14 may include multiple types of storage devices with different standards, such as an eMMC 141 and an SSD 142. Different types of storage devices may be used depending on the application. eMMC stands for embedded Multi Media Card. SSD stands for Solid State Drive.

[0045] 4, the data collection device 2 is connected to an in-vehicle system 4 of the host vehicle via the vehicle I / F 12. The in-vehicle system 4 includes one ECU 210, multiple ECUs 220, multiple ECUs 230, an external communication device 240, and an internal communication network 250. ECU is an abbreviation for Electronic Control Unit.

[0046] The ECU 210 controls a plurality of ECUs 220 to realize coordinated control of the entire vehicle. For example, the ECU 220 is provided for each domain divided according to the vehicle's functions, and mainly controls a plurality of ECUs 230 present in that domain. Each ECU 220 is connected to its subordinate ECUs 230 via a lower-layer network (e.g., CAN) provided individually. The ECU 220 has a function of centrally managing access rights and the like for the subordinate ECUs 230 and authenticating users, etc. The domains are, for example, the powertrain, body, chassis, and cockpit.

[0047] The ECUs 230 connected to the ECUs 220 belonging to the powertrain domain include, for example, an ECU 230 that controls the engine, an ECU 230 that controls the motor, and an ECU 230 that controls the battery.

[0048] The ECUs 230 connected to the ECU 220 belonging to the body domain include, for example, an ECU 230 that controls an air conditioner, an ECU 230 that controls doors, etc. The ECUs 230 connected to the ECU 220 belonging to the chassis domain include, for example, an ECU 230 that controls a brake, an ECU 230 that controls steering, etc.

[0049] The ECUs 230 connected to the ECU 220 belonging to the cockpit domain include, for example, an ECU 230 that controls the display of meters and navigation, and an ECU 230 that controls input devices operated by the vehicle occupants.

[0050] The exterior-vehicle communication device 240 performs data communication with a communication device outside the vehicle (e.g., a cloud server) via the wide-area wireless communication network NW. The in-vehicle communication network 250 includes a CAN FD and an Ethernet. CAN FD stands for CAN with Flexible Data Rate. The CAN FD connects the ECU 210 to each ECU 220 and the exterior-vehicle communication device 240 via a bus. The Ethernet individually connects the ECU 210 to each ECU 220 and the exterior-vehicle communication device 240.

[0051] The ECU 210 is an electronic control device mainly composed of a microcomputer including a CPU 210a, a ROM 210b, a RAM 210c, etc. Various functions of the microcomputer are realized by the CPU 210a executing a program stored in a non-transitory tangible recording medium. In this example, the ROM 210b corresponds to the non-transitory tangible recording medium storing the program. Furthermore, the execution of this program executes a method corresponding to the program. Note that some or all of the functions executed by the CPU 210a may be configured as hardware using one or more ICs, etc. Furthermore, the number of microcomputers constituting the ECU 210 may be one or more.

[0052] Like the ECU 210, the ECU 220, the ECU 230, and the exterior-vehicle communication device 240 are all electronic control devices mainly configured with a microcomputer including a CPU, ROM, RAM, etc. Furthermore, the number of microcomputers constituting the ECU 220, the ECU 230, and the exterior-vehicle communication device 240 may be one or more. The ECU 220 is an ECU that controls one or more ECUs 230, and the ECU 210 is an ECU that controls one or more ECUs 220 or controls all ECUs 220, 230 of the vehicle including the exterior-vehicle communication device 240. The data collection device 2 is connected to the ECU 210 via the vehicle I / F 12 so as to enable data communication with the ECU 210. That is, the data collection device 2 receives information from the ECUs 210, 220, and 230 via the ECU 210.

[0053] Furthermore, the data collecting device 2 transmits requests relating to vehicle control to the ECU 210 and to the ECUs 220 and 230 via the ECU 210 .

[0054] [1-2. Functional Configuration] The CPU 21 belonging to the control unit 11 of the data collection device 2 executes programs stored in the ROM 22 or the storage unit 14, or programs loaded into the RAM 23. The functional configuration of the computer system 5 realized in the data collection device 2 by the CPU 21 executing the programs will be described with reference to FIG.

[0055] The computer system 5 includes a storage device 50, a SoC 51, a hypervisor 52, a first unit 53, and a second unit 54.

[0056] 5 shows that the control unit 11 is configured with one SoC 51. Also, a storage device 50 represents all storage devices that make up the storage unit 14, and the SoC 51 can access all areas of the storage device 50.

[0057] The hypervisor 52 is software for generating virtual machines that run on the SoC 51 without requiring a host OS and for operating the generated virtual machines. The first unit 53 and the second unit 54 are virtual machines that run on the hypervisor 52. The hypervisor 52 allocates core processors of the CPU 21 as resources available to the first unit 53 and the second unit 54. In this embodiment, the hypervisor 52 allocates a fixed number of core processors, such as M core processors to the first unit 53 and N core processors to the second unit 54, where M and N are positive integers.

[0058] The first unit 53 includes an RTOS 61. Applications that perform processes requiring real-time performance, such as vehicle driving control, are executed on the RTOS 61. The applications that run on the RTOS 61 may be pre-installed or may be downloaded and installed from an external source, such as the center 3, of the vehicle. An application that is already installed on the RTOS 61 is referred to as an existing application 63. A beta application 64 distributed by the center 3 is executed on the RTOS 61. While one existing application 63 and one beta application 64 are shown in FIG. 5 , one or both of the existing application 63 and one or both of the beta application 64 may be omitted, or two or more of either or both may be present.

[0059] The first unit 53 includes an RT priority management unit 62. The RT priority management unit 62 is one of the functions realized by software running on the RTOS 61. The RT priority management unit 62 manages the execution priorities of existing applications 63 and beta applications 64 installed on the RTOS 61, and controls the execution of each application based on management information.

[0060] The second unit 54 includes a GPOS 71. For example, Linux may be used as the GPOS 71. Linux is a registered trademark. Applications that mainly perform processing with low real-time requirements, such as processing for providing services to users, are executed on the GPOS 71. The applications that run on the GPOS 71 may be pre-installed or may be downloaded and installed from the center 3 or the like.

[0061] The second unit 54 includes an OTA control unit 72 , a data collection unit 73 , a resource management unit 74 , and a container unit 75 as functions realized by software running on the GPOS 71 .

[0062] The OTA control unit 72 downloads apps to be run on the RTOS 61 and GPOS 71 and performs processes such as determining the execution destination via the communication unit 13 provided in the data collection device 2 or the external communication device 240 provided in the vehicle.

[0063] The data collection unit 73 collects various data related to the vehicle via the vehicle I / F 12 and executes a process of uploading the data to the center 3. The data collected by the data collection unit 73 may include operation logs of apps running on the RTOS 61 and the GPOS 71.

[0064] The resource management unit 74 manages resources allocated to the container unit 75 operating on the GPOS 71. Specifically, the resource management unit 74 determines, based on the load on the container unit 75, how many of the N core processors allocated to the second unit 54 by the hypervisor 52 are to be allocated to processing the container unit 75.

[0065] The container unit 75 includes a container engine 81. An application 831 running on the container engine 81 is container-virtualized and packaged together with an independent operating environment 832 required to execute the application. The packaged application 831 and operating environment 832 are referred to as a container 83. In this embodiment, the alpha application 831 is containerized. The operating environment 832 is an operating environment realized by a development device used to develop the application, and may include libraries, frameworks, and the like used by the alpha application 831. The containerized alpha application 831 runs using the GPOS 71, which is the host OS. In other words, each container 83 runs without using a guest OS.

[0066] The alpha version application 831 packaged in the container 83 together with the operating environment 832 can be run on the vehicle's computer system 5 as is, without modifying the underlying software. The underlying software is software that is required to absorb differences in the operating environments of the development device and the vehicle's computer system 5 when running a developed application directly on the OS without using a container.

[0067] The alpha version application 831 is distributed from the center 3 to the vehicle in the form of a container 83 including an operating environment 832, and is set to be executed on the container unit 75 running on the GPOS 71.

[0068] The container unit 75 includes a container priority management unit 82. The container priority management unit 82 is one of the functions realized by software running on the container engine 81. The container priority management unit 82 manages the execution priority of each container 83 running on the container engine 81, and controls the execution of each container 83 based on management information.

[0069] Since alpha application 831 needs to be repeatedly tested in an actual vehicle and the program improved based on the test results, it is provided in a containerized form together with an operating environment 832 of a development device so that it can be easily installed in an actual vehicle. Beta application 64 is provided in a form in which undercarriage software and the like are also built in so that it can operate in the same environment as in actual use.

[0070] [1-3. Processing] The data collection device 2 executes a download process, an execution destination determination process, and an application startup process. In the download process, the developed application is downloaded from the center 3 via the communication unit 13 and stored in a storage area (hereinafter referred to as the download area) prepared in advance in the storage device 50. The developed application here refers to the container 83 in which the alpha application 831 is packaged, and the beta application 64. The developed application may be downloaded together with additional information associated with the developed application. As described above, the additional information includes at least one of specification information and attribute information. The additional information may further include resource information.

[0071] [1-3-1. Determining Execution Destination] The execution destination determination process executed by the OTA control unit 72 will be described using the flowchart in Fig. 6. The execution destination determination process determines the execution destination of a developed application stored in a download area by a download process so that the developed application is executed on an OS determined based on additional information.

[0072] When the execution destination determination process is started, in S110, the OTA control unit 72 reads the additional information downloaded together with the developed application.

[0073] In S120, if attribute information is indicated as additional information, the OTA control unit 72 determines whether the attribute of the developed application indicates that it is an alpha version. Furthermore, if designation information is indicated as additional information, the OTA control unit 72 determines whether GPOS is designated as the OS running the developed application. If the attribute information indicates that it is an alpha version, or if the designation information specifies GPOS, the OTA control unit 72 determines that the downloaded developed application is a container 83 in which an alpha version application 831 is packaged, and proceeds to S130. If the attribute information indicates that it is a beta version rather than an alpha version, or if the designation information specifies RTOS rather than GPOS, the OTA control unit 72 determines that the downloaded developed application is a beta version application 64, and proceeds to S160.

[0074] In S130, the OTA control unit 72 determines the second unit 54 as the execution destination of the downloaded developed application, and instructs the resource management unit 74 to adjust the allocation of resources to the container unit 75.

[0075] The resource management unit 74 that has received the instruction compares the amount of required resources indicated in the resource information included in the additional information with the amount of resources allocated to the container unit 75, and if it is necessary to change the resource allocation for the container unit 75, makes the change. Specifically, it changes the number of core processors that are allocated to processing the container unit 75.

[0076] In S140, the OTA control unit 72 instructs the container priority management unit 82 to change the execution priority of the container 83 executed on the container engine 81. That is, the container 83 to be newly executed (i.e., the α version application 831) is added to the management information indicating the execution priority.

[0077] In S150, the OTA control unit 72 stores the container 83 including the alpha application 831 in the memory area (i.e., part of the storage device 50) allocated for the GPOS 71 by the hypervisor 52. Furthermore, the OTA control unit 72 installs the alpha application 831 so that it can be executed in the container unit 75 running on the GPOS 71, and then ends the process.

[0078] In S160, the OTA control unit 72 determines that the downloaded developed application is to be executed on the first unit 53, and instructs the RT priority management unit 62 to change the execution priority of the application to be executed on the RTOS 61. In other words, the beta application 64 to be newly executed is added to the management information indicating the execution priority.

[0079] In S170, the OTA control unit 72 stores the beta application 64 in the memory area (i.e., part of the storage device 50) allocated to the RTOS 61 by the hypervisor 52. Furthermore, the OTA control unit 72 installs the beta application 64 so that it can be executed on the RTOS 61, and then ends the process.

[0080] 7, the GPOS application startup process executed by the container engine 81 running on the GPOS 71 will be described. The GPOS application startup process is initiated when a specified user operation is performed on the vehicle (for example, turning on the ignition).

[0081] When the GPOS application startup process begins, the container engine 81 determines in S210 whether or not there is a container (hereinafter, "start-target container") installed to run on the GPOS 71. If the container engine 81 determines that there is a start-target container, it proceeds to S220. If the container engine 81 determines that there is no start-target container, it proceeds to S270.

[0082] In S220, the container engine 81 selects the container to be started that has the highest execution priority from among the unprocessed containers to be started that have not yet undergone the processes in S230 to S260 (described later). Hereinafter, the container to be started selected in S220 will be referred to as the selected container.

[0083] In S230, the container engine 81 reads the usage status of the resources allocated to the container unit 75 from the resource management unit 74.

[0084] In S240, the container engine 81 determines, based on the resource usage status read in S230 and the resource information included in the additional information of the selected container, whether the selected container can be executed in the container unit 75. If the container engine 81 determines that the selected container is executable, it proceeds to S260, and if it determines that the selected container is not executable, it proceeds to S250.

[0085] In S250, the container engine 81 sends an execution-impossible notification indicating that the selected container cannot be executed, for example, to the provider of the selected container, and returns the process to S210.

[0086] In S260, the container engine 81 starts the alpha application 831 packaged in the selected container so that it is executed in shadow mode, and the process proceeds to S270. The alpha application 831 executed in shadow mode is not activated, and provides various data obtained by executing the application as a processing log to the data collection unit 73. The data collected as the processing log may include control command values ​​for the vehicle, determination results based on data acquired from the vehicle, and the like.

[0087] In S270, the container engine 81 determines whether the ignition is turned off, and if the ignition is turned off, ends the process, but if the ignition is not turned off, returns the process to S210. Note that the determination of whether to end the process is not limited to turning off the ignition, and may be based on other user operations.

[0088] Next, the RTOS application startup process executed by the RTOS 61 will be described with reference to the flowchart of Fig. 8. The RTOS application startup process is started, for example, when the ignition of the vehicle is turned on.

[0089] When the RTOS application startup process starts, the RTOS 61 determines in S310 whether or not there is a developed application (hereinafter, “startup target application”) installed to run on the RTOS 61. If the RTOS 61 determines that there is a startup target application, it proceeds to S320. If the RTOS 61 determines that there is no startup target application, it proceeds to S370. The startup target applications include the existing application 63 and the beta application 64 installed in the installation process.

[0090] In S320, the RTOS 61 selects the application to be launched with the highest execution priority from among the applications to be launched that have not yet been processed in S330 to S360 (described later). Hereinafter, the application to be launched selected in S320 will be referred to as the selected application.

[0091] In S330, the RTOS 61 reads the usage status of the resources allocated to the RTOS 61.

[0092] In S340, the RTOS 61 determines whether the selected application can be executed based on the resource usage status read in S330 and the resource information included in the additional information of the selected application. If the RTOS 61 determines that the selected application can be executed, the process proceeds to S360. If the RTOS 61 determines that the selected application cannot be executed, the process proceeds to S350.

[0093] In S350, the RTOS 61 sends an execution impossibility notice indicating that the selected application cannot be executed to, for example, the provider of the selected application, and returns the process to S310.

[0094] In S360, the RTOS 61 launches the selected application and proceeds to S370. If the selected application is the beta application 64, it is executed in shadow mode. The beta application 64 executed in shadow mode is not activated, and various data obtained by executing the application is provided to the data collection unit 73 as a processing log. The data collected as the processing log may include control command values ​​for the vehicle, determination results based on data acquired from the vehicle, and the like, as in the case of the alpha application 831.

[0095] In S370, the RTOS 61 determines whether the ignition is turned off, and if the ignition is turned off, the process ends, but if the ignition is not turned off, the process returns to S310. Note that the determination of whether to end the process is not limited to turning off the ignition, and may be based on other user operations.

[0096] [1-3. Correspondence of Terms] The data collection device 2 and the computer system 5 of the present embodiment correspond to the in-vehicle device of the present disclosure. The first unit 53 of the present embodiment corresponds to the first processing unit of the present disclosure, and the second unit 54 corresponds to the second processing unit. The communication unit 13 of the present embodiment corresponds to the acquisition unit of the present disclosure, and the OTA control unit 72 corresponds to the application management unit of the present disclosure. The application DB 331 of the present embodiment corresponds to the application storage unit of the present disclosure, and the processing log DB 332 corresponds to the log storage unit of the present disclosure.

[0097] [1-4. Effects] According to the first embodiment described above in detail, the following effects are achieved.

[0098] (1a) In the computer system 5, the RTOS 61 or the GPOS 71 is used to execute the downloaded application, based on the additional information associated with the application, and the application is installed according to the determination. Each OS starts the application, which has been installed so that it can be executed on its own OS, and executes it in shadow mode.

[0099] Therefore, the computer system 5 allows the developed application to run on an appropriate OS as intended by the creator of the additional information (for example, the creator of the application).

[0100] (1b) In the computer system 5, the alpha application 831 is executed on the GPOS 71, and the beta application is executed on the RTOS 61. Moreover, the alpha application 831 is provided in the form of a container 83 packaged together with the operating environment of the development device. Therefore, with the computer system 5, the alpha application 831 developed using the development device can be easily tested in a vehicle.

[0101] (1c) In the computer system 5, only the beta application 64 is executed directly on the RTOS 61, which is the actual operating environment, without using the container 83, so that the underlying software for ensuring consistency with the actual operating environment only needs to be created when testing the beta application 64. Therefore, the computer system 5 can reduce the effort required to create and modify the underlying software.

[0102] [2. Second Embodiment] [2-1. Differences from the First Embodiment] The second embodiment has the same basic configuration as the first embodiment, so differences will be described below. Note that the same reference numerals as in the first embodiment indicate the same configuration, and the preceding description will be referred to.

[0103] In the second embodiment, the functional configuration of a computer system 5a implemented by a data collection device 2 differs from that of the first embodiment. Also, in the second embodiment, the method and timing for determining the execution destination of a developed application differ from those of the first embodiment.

[0104] 9, the computer system 5a includes a storage device 50, an SoC 51, a hypervisor 52, a first unit 53, a second unit 54a, and a third unit 55. In other words, compared to the computer system 5 of the first embodiment, the configuration of the second unit 54a is partially different, and further, a third unit 55 is added.

[0105] The second unit 54a includes an OTA control unit 72, a data collection unit 73, a resource management unit 74, a container unit 75, and an overall resource management unit 76. That is, compared to the second unit 54 of the first embodiment, the overall resource management unit 76 is added.

[0106] The overall resource manager 76 is one of the functions realized by software running on the GPOS 71 of the second unit 54 a. The overall resource manager 76 has a function of managing the applications executed by the first unit 53, the second unit 54 a, and the third unit 55, and the resources used by the units 53, 54 a, and 55 as a whole.

[0107] The third unit 55 includes a GPOS 71, a resource management unit 74, and a container unit 75. That is, compared to the second unit 54 of the first embodiment, the third unit 55 does not include the OTA control unit 72 and the data collection unit 73.

[0108] That is, the computer system 5 a is configured so that the execution location of the α version application 831 running on the GPOS 71 can be selected from two locations, the second unit 54 a and the third unit 55 .

[0109] [2-3. Processing] Next, the application launch process executed by the OTA control unit 72 will be described with reference to the flowcharts of Figures 10 and 11. The OTA control unit 72 executes the download process in the same manner as in the first embodiment. By executing the download process, the developed application and additional information are stored in the download area of ​​the storage device 50.

[0110] The application startup process collectively executes processes corresponding to the installation process, GPOS application startup process, and RTOS application startup process in the first embodiment when the IG is turned on.

[0111] When the application activation process starts, the OTA control unit 72 determines in S410 whether or not a developed application has been downloaded to the download area. If a developed application is present, the OTA control unit 72 proceeds to S420. If no developed application is present, the OTA control unit 72 proceeds to S560.

[0112] In S420, the OTA control unit 72 selects one of the developed applications that have not yet been processed in S430 to S550 (described later). The selection method may be arbitrary, or some priority order may be set and the application may be selected according to the set priority order. Hereinafter, the developed application selected in S420 will be referred to as the selected application.

[0113] In S430, the OTA control unit 72 reads additional information associated with the selected application.

[0114] In S440, the OTA control unit 72 determines whether the selected application is the alpha application 831 executed by the container unit 75. If the OTA control unit 72 determines that the selected application is the alpha application 831, the process proceeds to S450. If the OTA control unit 72 determines that the selected application is not the alpha application 831 but the beta application 64 executed on the RTOS 61, the process proceeds to S520.

[0115] For example, if the designation information included in the additional information is GPOS or if the attribute information is alpha, it may be determined that the application is the alpha application 831 that runs on the container unit 75 (i.e., on the GPOS). Also, if the designation information included in the additional information is RTOS or if the attribute information is beta, it may be determined that the application is not the alpha application 831 but the beta application 64 that runs on the RTOS.

[0116] In S450, the OTA control unit 72 inquires of the overall resource management unit 76 whether the container unit 75 of the second unit 54a has resources capable of executing the selected application (i.e., the container 83 in which the α version application 831 is packaged). If the OTA control unit 72 determines as a result of the inquiry that the resources are available, it proceeds to S470, and if it determines that the resources are not available, it proceeds to S460.

[0117] In S460, the OTA control unit 72 inquires of the overall resource management unit 76 whether or not the container unit 75 of the third unit 55 has resources capable of executing the selected application. If the OTA control unit 72 determines as a result of the inquiry that the resources are available, it proceeds to S490, and if it determines that the resources are not available, it proceeds to S510.

[0118] In S470, the OTA control unit 72 determines that the downloaded developed application will be executed in the second unit 54a, and instructs the resource management unit 74 of the second unit 54a to allocate resources necessary for executing the selected application.

[0119] Upon receiving the instruction, the resource management section 74 of the second unit 54a allocates a portion of the resources available to the container unit 75 of the second unit 54a for execution of the selected application in accordance with the resource information included in the additional information.

[0120] In S480, the OTA control unit 72 stores the selected application (i.e., the container 83 in which the α application 831 is packaged) in the memory area allocated to the GPOS 71 of the second unit 54a by the hypervisor 52. Furthermore, the OTA control unit 72 installs the α application 831 so that it is executable in the container unit 75 operating on the GPOS 71 of the second unit 54a, starts the installed α application 831, and proceeds to S560.

[0121] In S490, the OTA control unit 72 determines that the downloaded developed application will be executed in the third unit 55, and instructs the resource management unit 74 of the third unit 55 to allocate resources necessary for executing the selected application.

[0122] Upon receiving the instruction, the resource management section 74 of the third unit 55 allocates a portion of the resources available to the container unit 75 of the third unit 55 for execution of the selected application in accordance with the resource information included in the additional information.

[0123] In S500, the OTA control unit 72 stores the selected application (i.e., the container 83 in which the alpha application 831 is packaged) in the memory area allocated to the GPOS 71 of the third unit 55 by the hypervisor 52. Furthermore, the OTA control unit 72 installs the alpha application 831 so that it is executable in the container unit 75 operating on the GPOS 71 of the third unit 55, starts the installed alpha application 831, and proceeds to S560.

[0124] In S510, the OTA control unit 72 sends an execution impossibility notification indicating that the selected application cannot be executed to, for example, the provider of the selected application, and then proceeds to S560.

[0125] In S520, the OTA control unit 72 inquires of the overall resource management unit 76 whether or not the RTOS 61 has resources capable of executing the selected application (i.e., the beta application 64). If the OTA control unit 72 determines as a result of the inquiry that the resources are available, it proceeds to S530, and if it determines that the resources are not available, it proceeds to S550.

[0126] In S530, OTA control unit 72 determines that the downloaded developed application will be executed on first unit 53, and instructs RTOS 61 to allocate resources necessary for executing the selected application.

[0127] Upon receiving the instruction, the RTOS 61 allocates a portion of the resources available to the RTOS 61 for execution of the selected application, for example, in accordance with the resource information included in the additional information.

[0128] In S540, the OTA control unit 72 stores the selected application (i.e., the beta application 64) in the memory area allocated to the RTOS 61 by the hypervisor 52. Furthermore, the OTA control unit 72 installs the beta application 64 so that it is executable on the RTOS 61, starts the installed beta application 64, and proceeds to S560.

[0129] In S550, the OTA control unit 72 sends an execution impossibility notification indicating that the selected application cannot be executed to, for example, the provider of the selected application, and then proceeds to S560.

[0130] In S560, the OTA control unit 72 determines whether the ignition is turned off, and if the ignition is turned off, ends the process, but if not, returns the process to S410. Note that the determination of whether to end the process is not limited to turning off the ignition, and may be based on other user operations.

[0131] [2-3. Correspondence of Terminology] The first unit 53 of this embodiment corresponds to the first processing unit of the present disclosure, and the second unit 54a and the third unit 55 correspond to the second processing unit of the present disclosure.

[0132] [2-4. Effects] According to the second embodiment described above in detail, in addition to the effects (1a) to (1c) of the first embodiment described above, the following effects are also achieved.

[0133] (2a) In computer system 5a, the installation destination of a developed application is determined when the developed application is launched. Therefore, for a developed application that can be installed on multiple OSs (i.e., alpha application 831 in this embodiment), the installation destination can be flexibly changed depending on the resource usage status at the time.

[0134] [3. Third Embodiment] [3-1. Differences from First Embodiment] The third embodiment has the same basic configuration as the first embodiment, so differences will be described below. Note that the same reference numerals as in the first embodiment indicate the same configuration, and the preceding description will be referred to.

[0135] In the third embodiment, the functional configuration of a computer system 5b implemented by a data collection device 2 differs from that of the first embodiment. Also, in the third embodiment, the processing content when determining the execution destination of a developed application and when starting the application differs from that of the first embodiment.

[0136] 12, the computer system 5b includes storage devices 50 and 57, SoCs 51 and 58, hypervisors 52 and 59, a first unit 53, a second unit 54a, a third unit 55, and a fourth unit 56.

[0137] 12 shows that the control unit 11 is configured with two SoCs 51 and 58, each of which is provided with its own dedicated storage device 50, 57. The SoC 51 is configured to be able to access the storage device 50, and the SoC 58 is configured to be able to access the storage device 57.

[0138] The hypervisor 52 runs on the SoC 51 and includes a first unit 53 and a second unit 54 a as virtual machines running on the hypervisor 52 .

[0139] The functional configuration of the first unit 53 has been described in the first embodiment, and the functional configuration of the second unit 54a has been described in the second embodiment, so a description thereof will be omitted here.

[0140] The hypervisor 59 runs on the SoC 58 and includes a third unit 55 and a fourth unit 56 as virtual machines running on the hypervisor 59 .

[0141] The functional configuration of the fourth unit 56 is the same as that of the first unit 53, and the functional configuration of the third unit 55 has been explained in the second embodiment, so explanation thereof will be omitted here.

[0142] That is, in computer system 5b, multiple OSs run on each of multiple SoCs 51 and 58. The execution location of alpha application 831 running on GPOS 71 can be selected from two locations: second unit 54a and third unit 55. The execution location of beta application 64 running on RTOS 61 can be selected from two locations: first unit 53 and fourth unit 56.

[0143] The eMMC 141 of the storage unit 14 has a first storage area and a second storage area, and the SSD 142 has a third storage area and a fourth storage area. Here, the first storage area of ​​the eMMC 141 and the third storage area of ​​the SSD 142 belong to the storage device 50, and the second storage area of ​​the eMMC 141 and the fourth storage area of ​​the SSD 142 belong to the storage device 57.

[0144] [3-3. Processing] Next, the installation process executed by the OTA control unit 72, which replaces the installation process described in the first embodiment using the flowchart of FIG. 6, will be described using the flowchart of FIG. 13. The OTA control unit 72 executes the download process in the same manner as in the first embodiment. By executing the download process, the developed application and additional information are stored in the download area of ​​the storage device 50. The execution destination determination process is executed following the download process each time the download process is performed. Hereinafter, the developed application stored in the download area is referred to as the target application.

[0145] When the execution destination determination process is started, in S610, the OTA control unit 72 reads additional information associated with the target application from the download area.

[0146] In S620, the OTA control unit 72 determines whether the target application is the alpha application 831 executed in the container unit 75. If the OTA control unit 72 determines that the target application is the alpha application 831, the process proceeds to S630. If the OTA control unit 72 determines that the target application is not the alpha application 831 but the beta application 64 executed on the RTOS 61, the process proceeds to S660. The specific method of the determination in S620 is the same as the process in S440 described in the second embodiment.

[0147] In S630, the OTA control unit 72 determines whether the target application is suitable for execution on the GPOS 71 of the second unit 54a, i.e., whether it is suitable for execution in the container unit 75 of the second unit 54a. If it is determined that the target application is suitable for execution on the GPOS 71 of the second unit 54a, the process proceeds to S640. If it is determined that the target application is not suitable for execution on the GPOS 71 of the second unit 54a, the process proceeds to S650.

[0148] The determination of whether execution on the GPOS 71 of the second unit 54a is suitable may be made by inquiring of the resource status of the two GPOSs 71 of the second unit 54a and the third unit 55 to the overall resource manager 76. For example, the second unit 54a may be determined to be suitable for execution if the resources allocated to the second unit 54a are sufficient to execute the target application. Alternatively, the second unit 54a may be determined to be suitable for execution if the second unit 54a has a larger margin of resources available for executing the target application than the third unit 55.

[0149] In S640, the OTA control unit 72 determines that the target application will be executed on the second unit 54a, selects the storage device 51 (e.g., the first storage area of ​​eMMC 141) prepared for the GPOS 71 of the second unit 54a as the storage destination for the target application, and proceeds to S690.

[0150] In S650, the OTA control unit 72 determines that the target application will be executed on the third unit 55, sets the storage device 58 (e.g., the second storage area of ​​eMMC 141) prepared for the GPOS 71 of the third unit 55 as the storage destination for the target application, and proceeds to S690.

[0151] In S660, the OTA control unit 72 determines whether the target application is suitable for execution on the RTOS 61 of the first unit 53. If it is determined that the target application is suitable for execution on the RTOS 61 of the first unit 53, the process proceeds to S670. If it is determined that the target application is not suitable for execution on the RTOS 61 of the first unit 53, the process proceeds to S680.

[0152] The determination of whether execution on the RTOS 71 of the first unit 53 is suitable may be made by inquiring of the resource status of the two RTOSs 61 in the first unit 53 and the fourth unit 56 to the overall resource manager 76. For example, it may be determined that the target application is suitable for execution if the resources available in the first unit 53 are sufficient to execute the target application. Alternatively, it may be determined that the target application is suitable for execution if the first unit 53 has a larger margin of resources available for execution of the target application than the fourth unit 56.

[0153] In S670, the OTA control unit 72 determines that the target application will be executed on the first unit 53, selects the storage device 51 (e.g., the third storage area of ​​SSD 142) prepared for the RTOS 61 of the first unit 53 as the storage destination for the target application, and proceeds to S690.

[0154] In S680, the OTA control unit 72 determines that the target application will be executed on the fourth unit 56, sets the storage device 58 (for example, the fourth storage area of ​​SSD 142) prepared for the RTOS 61 of the fourth unit 56 as the storage destination for the target application, and proceeds to S690.

[0155] That is, by the processing of S640, S650, S670, and S680, the alpha application 831 executed on the GPOS 71 is set to be stored in the eMMC 141, and the beta application 64 running on the RTOS 61 is set to be stored in the SSD 142.

[0156] In S690, the OTA control unit 72 instructs the overall resource manager 76 to update the overall resource information. Specifically, the resource management information indicating the resource allocation status of each OS is updated according to the execution destination determined in S640 to S680. The overall resource manager 76 outputs instructions to the resource manager 74 of the second unit 54a, the resource manager 74 of the third unit 55, the RTOS 61 of the first unit 53, and the RTOS 61 of the fourth unit 56, etc., to make changes in accordance with the resource management information.

[0157] In S700, the OTA control unit 72 stores the target application in the storage devices 50 and 57 (i.e., the storage areas of the eMMC 141 and the SSD 142) selected as the storage destinations for the target application, and then ends the process.

[0158] Each OS in the first to fourth units 53, 54a, 55, and 56 installs the developed application stored in the storage area associated with the OS at the timing of a specified user operation so that the developed application can be executed by the OS. Furthermore, each OS launches the installed developed application and executes it in shadow mode. Note that when launching the developed application, whether or not to launch it may be determined based on the resource usage status of each OS.

[0159] [3-3. Correspondence of Terminology] The first unit 53 and the fourth unit 56 of the present embodiment correspond to the first processing unit of the present disclosure, and the second unit 54a and the third unit 55 correspond to the second processing unit of the present disclosure.

[0160] [3-4. Effects] According to the third embodiment described above in detail, in addition to the effects (1b) and (1c) of the first embodiment described above, the following effects are also achieved.

[0161] (3a) In the computer system 5b, the GPOS 71 or the RTOS 61 is selected as the execution destination according to the additional information, and further, depending on the resource status available to each OS, it is determined which of the OSs of the same type is to be the execution destination.

[0162] Therefore, with computer system 5b, a developed application can be run on an appropriate type of OS as intended by the creator of the additional information (e.g., the creator of the application), and on an OS appropriate for the resources available to each OS. Furthermore, the processing load of the developed application can be prevented from being concentrated on a specific OS.

[0163] [4. Other Embodiments] Although the embodiments of the present disclosure have been described above, the present disclosure is not limited to the above-described embodiments and can be implemented in various modifications.

[0164] (4a) In the first embodiment, the execution destination determination process includes installation so that the application under development can be executed at the determined execution destination. However, the execution destination determination process may be configured to determine the execution destination and then install the application before launching it. Furthermore, the downloaded application may be installed without being moved from the storage area where it was downloaded.

[0165] (4b) When multiple SoCs 51 and 58 exist, as in the third embodiment, the additional information may include not only information specifying the OS to be installed, but also information specifying the SoC to be installed.

[0166] (4c) In the third embodiment, the two SoCs 52 and 58 are configured to have different accessible storage devices 51 and 57, respectively. However, they may also be configured to have access to a common storage device 51, as in the computer system 5c shown in FIG. 14.

[0167] (4d) In the first embodiment, one virtual machine using RTOS 61 (i.e., first unit 53) and one virtual machine using GPOS 71 (i.e., second unit 54) are provided on one SoC. In the second embodiment, one virtual machine using RTOS 61 (i.e., first unit 53) and two virtual machines using GPOS 71 (i.e., second unit 54a and third unit 55) are provided on one SoC. Multiple virtual machines using RTOS 61 may be provided on one SoC, and three or more virtual machines using GPOS 71 may be provided on one SoC. Also, multiple virtual machines using RTOS 61 alone or multiple virtual machines using GPOS 71 alone may be provided on one SoC.

[0168] (4e) In the third embodiment, a configuration is illustrated in which each of the two SoCs 51 and 58 is provided with one virtual machine using the RTOS 61 and one virtual machine using the GPOS 71. The configuration is not limited to this example, and the number of virtual machines using the RTOS 61 and the number of virtual machines using the GPOS 71 provided on each SoC can be any number.

[0169] (4f) Multiple functions possessed by one component in the above embodiments may be realized by multiple components, or one function possessed by one component may be realized by multiple components. Also, multiple functions possessed by multiple components may be realized by one component, or one function realized by multiple components may be realized by one component. Also, part of the configuration of the above embodiments may be omitted. Also, at least part of the configuration of the above embodiments may be added to or substituted for the configuration of another of the above embodiments.

[0170] (4g) In addition to the data collection device 2 as the above-mentioned in-vehicle device, it may also be realized as a system including the in-vehicle device as a component, a program for causing a computer to function as the in-vehicle device, a non-transient physical recording medium such as a semiconductor memory on which this program is recorded, etc.

[0171] [5. Technical Ideas Disclosed in the Present Specification] [Item 1] An in-vehicle device comprising: one or more first processing units (53, 56) configured to execute an application on a real-time operating system; one or more second processing units (54, 54a, 55) configured to execute an application on a general-purpose operating system; an acquisition unit (13) configured to acquire a development application that is an application under development and additional information linked to the development application from outside the vehicle in which the in-vehicle device is mounted; and an application management unit (72) configured to determine whether the development application should be executed by the first processing unit or the second processing unit based on the additional information, and to have the development application executed by the first processing unit and the second processing unit according to the result of the determination.

[0172] [Item 2] The in-vehicle device according to Item 1, wherein the additional information includes designation information that designates a type of operating system to be used to execute the developed application, and the application management unit is configured to determine the execution destination in accordance with the designation information.

[0173] [Item 3] The in-vehicle device according to item 1 or 2, wherein the additional information includes attribute information indicating attributes of the developed application, and the application management unit is configured to determine the execution destination in accordance with the attribute information.

[0174] [Item 4] The in-vehicle device according to Item 3, wherein the second processing unit includes a container engine that runs on the general-purpose operating system, the attribute information is information indicating a development progress status, whether the development is in the final stage or a non-final stage before the final stage, the developed application whose progress status is indicated to be in the non-final stage by the attribute information is packaged into a container together with an operating environment realized on a development device used for developing the developed application, and the application management unit is configured to run the container on the container engine of the second processing unit when the attribute information indicates that the progress status is in the non-final stage.

[0175] [Item 5] The in-vehicle device according to any one of items 1 to 4, wherein the application management unit is configured to determine an execution destination for the developed application acquired by the acquisition unit each time the developed application is acquired, and to launch the developed application whose execution destination has been determined at the timing of a specified user operation on the vehicle.

[0176] [Item 6] The in-vehicle device according to any one of items 1 to 4, wherein the application management unit is configured to determine the execution destination of the developed application acquired by the acquisition unit at the timing of a specified user operation on the vehicle, and start the developed application.

[0177] [Item 7] The in-vehicle device according to any one of items 1 to 6, wherein the additional information includes a required resource amount that is an amount of resources required to execute the developed application, and when there are multiple first processing units or second processing units that are candidates for the execution destination, the application management unit is configured to determine the execution destination in accordance with the status of resources allocated to the candidates and the required resource amount.

[0178] [Item 8] An in-vehicle device according to any one of items 1 to 7, wherein the additional information includes a required resource amount, which is the amount of resources required to execute the developed application, and the first processing unit and the second processing unit are configured to determine whether or not to launch the developed application when the developed application is launched, based on the usage status of resources allocated to each processing unit and the required resource amount.

[0179] [Item 9] The in-vehicle device according to any one of items 1 to 8, wherein the first processing unit and the second processing unit are configured to execute the developed application in shadow mode.

[0180] [Item 10] The in-vehicle device according to any one of items 1 to 9, further comprising a data collection unit (73) configured to store a processing log obtained by the first processing unit and the second processing unit executing the developed application in a log storage unit provided outside the vehicle.

Claims

1. An in-vehicle device comprising: one or more first processing units (53, 56) configured to execute an application on a real-time operating system; one or more second processing units (54, 54a, 55) configured to execute an application on a general-purpose operating system; an acquisition unit (13) configured to acquire a development application, which is an application under development, and additional information linked to the development application from outside the vehicle in which the in-vehicle device is mounted; and an application management unit (72) configured to determine whether the development application should be executed by the first processing unit or the second processing unit based on the additional information, and to have the development application executed by the first processing unit and the second processing unit according to the result of the determination.

2. An in-vehicle device according to claim 1, wherein the additional information includes designation information that designates the type of operating system to be used to execute the developed application, and the application management unit is configured to determine the execution destination in accordance with the designation information.

3. An in-vehicle device according to claim 1, wherein the additional information includes attribute information indicating attributes of the developed application, and the application management unit is configured to determine the execution destination in accordance with the attribute information.

4. An in-vehicle device according to claim 3, wherein the second processing unit is provided with a container engine that operates on the general-purpose operating system, the attribute information is information indicating the progress of development, whether the development is in the final stage or a non-final stage before the final stage, the development application whose progress is indicated to be in the non-final stage by the attribute information is packaged in a container together with an operating environment realized on the development device used to develop the development application, and the application management unit is configured to operate the container on the container engine of the second processing unit when the attribute information indicates that the progress is in the non-final stage.

5. An in-vehicle device according to claim 1, wherein the application management unit is configured to determine the execution destination of the developed application acquired by the acquisition unit each time the developed application is acquired, and to launch the developed application whose execution destination has been determined at the timing of a specified user operation on the vehicle.

6. An in-vehicle device according to claim 1, wherein the application management unit is configured to determine the execution destination of the developed application acquired by the acquisition unit and launch it at the timing of a specified user operation on the vehicle.

7. An in-vehicle device according to claim 1, wherein the additional information includes a required resource amount, which is the amount of resources required to execute the developed application, and the application management unit is configured to determine the execution destination in accordance with the status of resources allocated to the candidates and the required resource amount when there are multiple first processing units or second processing units that are candidates for the execution destination.

8. An in-vehicle device according to claim 1, wherein the additional information includes a required resource amount, which is the amount of resources required to execute the developed application, and the first processing unit and the second processing unit are configured to determine whether or not to launch the developed application when it is launched, based on the usage status of the resources allocated to each processing unit and the required resource amount.

9. The in-vehicle device according to claim 1, wherein the first processing unit and the second processing unit are configured to execute the developed application in shadow mode.

10. An in-vehicle device according to claim 1, further comprising a data collection unit (73) configured to store processing logs obtained by the first processing unit and the second processing unit executing the developed application in a log storage unit provided outside the vehicle.

11. An application storage unit (331) that stores a development application, which is an application under development; an in-vehicle device (2) that is mounted on a vehicle and configured to execute the development application acquired from the application storage unit; and a log storage unit (332) that stores a processing log obtained by executing the development application from the in-vehicle device that acquired the development application, wherein the in-vehicle device comprises: one or more first processing units (53, 56) configured to execute an application on a real-time operating system; one or more second processing units (54, 54a, 55) configured to execute an application on a general-purpose operating system; an acquisition unit (13) configured to acquire the development application and additional information linked to the development application from the application storage unit; and an application management unit (72) configured to determine whether the development application should be executed by the first processing unit or the second processing unit based on the additional information, and to have the development application executed by the first processing unit and the second processing unit according to the result of the determination. a data collection unit (73) configured to store the processing log obtained by the first processing unit and the second processing unit executing the developed application in the log storage unit.

12. A method for testing an application in an in-vehicle device having a first processing unit configured to execute an application on a real-time operating system and a second unit configured to execute an application on a general-purpose operating system, the method including: acquiring a development application, which is an application under development, and additional information associated with the development application from outside the vehicle in which the in-vehicle device is installed; determining whether the development application will be executed by the first processing unit or the second processing unit according to the additional information; and having the development application executed by the first processing unit and the second processing unit according to the result of the determination of the execution location.

13. A program for causing a computer mounted on a vehicle to function as: one or more first processing units (53, 56) configured to execute applications on a real-time operating system; one or more second processing units (54, 54a, 55) configured to execute applications on a general-purpose operating system; an acquisition unit (13) configured to acquire, from outside the vehicle, a development application that is an application under development and additional information linked to the development application; and an application management unit (72) configured to determine whether the development application should be executed by the first processing unit or the second processing unit based on the additional information, and to have the development application executed by the first processing unit and the second processing unit according to the result of the decision.