On-vehicle device, task allocation method, and task allocation program

Abstract

Provided is an on-vehicle device comprising: a detection unit that detects addition of an application to the on-vehicle device; a load situation acquisition unit that acquires a load situation of the on-vehicle device when the addition of the application is detected by the detection unit; an application information acquisition unit that acquires application information related to an additional application in which addition is detected by the detection unit; and an allocation unit that performs allocation processing for determining, from among a plurality of tasks having at least one of different priorities or different execution cycles, the task to be allocated to the additional application, on the basis of the load situation acquired by the load situation acquisition unit and the application information acquired by the application information acquisition unit.

Description

In-vehicle device, task assignment method, and task assignment program

[0001] This disclosure relates to an in-vehicle device, a task assignment method, and a task assignment program. This application claims priority based on Japanese Patent Application No. 2025-49196, filed on 25 March 2025, and incorporates all of its disclosures herein.

[0002] Patent document 1 (Japanese Unexamined Patent Publication No. 2024-47740) discloses the following technology. In other words, the electronic control device includes an arithmetic unit that performs predetermined arithmetic processing to periodically execute tasks, and a storage device accessible by the arithmetic unit, wherein the timing of data input and data output for the tasks is predetermined, and includes a time slot allocation information storage unit that stores time slot allocation information defining the execution timing of the tasks between the predetermined data input timing and data output timing, a task startup unit that starts the tasks according to the time slot allocation information, and a time slot allocation unit that stores information of the new tasks in the time slot allocation information storage unit according to the execution timing of the new tasks, wherein the time slot allocation unit receives input including information of the task that generates the data to be input to the new task, data flow request information including how many cycles ago the data generated by the task from the time slot in which the new task is started will be used, and time slot request information including information of the number of time slots required to execute the new task, searches for an available time slot to execute the new task based on the time slot allocation information, the data flow request information and the time slot request information, and updates the time slot allocation information to allocate the new task to the found available time slot.

[0003] Japanese Patent Publication No. 2024-47740, Japanese Patent Publication No. 2017-199266, Japanese Patent Publication No. 2011-198346

[0004] The in-vehicle device of the present disclosure is an in-vehicle device, comprising: a detection unit that detects addition of an application to the in-vehicle device; a load status acquisition unit that acquires a load status of the in-vehicle device when the addition of the application is detected by the detection unit; an application information acquisition unit that acquires application information about an added application, which is the application whose addition is detected by the detection unit; and an allocation unit that performs allocation processing for determining the task to be allocated to the added application from among a plurality of tasks differing in at least one of priority and execution cycle, based on the load status acquired by the load status acquisition unit and the application information acquired by the application information acquisition unit.

[0005] One aspect of the present disclosure can be implemented not only as an in-vehicle device including such a characteristic processing unit, but also as a semiconductor integrated circuit that implements part or all of the in-vehicle device, or as a system including the in-vehicle device.

[0006] Figure 1 is a diagram showing an example of the configuration of an in-vehicle system according to an embodiment of the present disclosure. Figure 2 is a diagram showing an example of the configuration of software used by an in-vehicle device according to an embodiment of the present disclosure. Figure 3 is a diagram illustrating an example of a task performed by an in-vehicle device according to an embodiment of the present disclosure. Figure 4 is a diagram showing the configuration of an in-vehicle device according to an embodiment of the present disclosure. Figure 5 is a diagram showing another example of the configuration of software used by an in-vehicle device according to an embodiment of the present disclosure. Figure 6 is a diagram illustrating an example of the process by which an in-vehicle device according to an embodiment of the present disclosure acquires its own load status. Figure 7 is a diagram illustrating another example of the process by which an in-vehicle device according to an embodiment of the present disclosure acquires its own load status. Figure 8 is a diagram showing an example of a load status table maintained by an in-vehicle device according to an embodiment of the present disclosure. Figure 9 is a diagram showing an example of a period table maintained by an in-vehicle device according to an embodiment of the present disclosure. Figure 10 is a diagram showing an example of a signature type table maintained by an in-vehicle device according to an embodiment of the present disclosure. Figure 11 is a diagram showing an example of a processing content table maintained by an in-vehicle device according to an embodiment of the present disclosure. Figure 12 is a diagram illustrating an example of an allocation process by an in-vehicle device according to an embodiment of the present disclosure. Figure 13 is a diagram illustrating another example of the allocation process by the in-vehicle device according to the embodiment of this disclosure. Figure 14 is a diagram illustrating another example of the allocation process by the in-vehicle device according to the embodiment of this disclosure. Figure 15 is a diagram illustrating another example of the allocation process by the in-vehicle device according to the embodiment of this disclosure. Figure 16 is a flowchart that defines an example of the operation procedure when the in-vehicle device according to the embodiment of this disclosure performs the allocation process.

[0007] Conventionally, technologies have been developed to prevent a decrease in the real-time performance of tasks performed by software installed in in-vehicle devices when that software is updated.

[0008] [Problems this disclosure aims to solve] The software of an in-vehicle device includes the OS (Operating System) and applications that provide various functions in the in-vehicle network. The OS is prepared with tasks, which are processes for executing applications. For example, multiple programs, such as the OS program and application programs, are compiled and stored in the memory of the in-vehicle device as a single binary data file.

[0009] In recent years, applications are sometimes added to in-vehicle systems after a vehicle has been shipped, at the request of the vehicle's user. However, once a program is compiled, the binary data cannot be modified. Therefore, it is conceivable to pre-configure tasks in the OS for additional applications in case of such additions. However, depending on the priority or execution cycle of these tasks, the real-time performance of both existing and newly added applications may be reduced.

[0010] This disclosure was made to solve the above-mentioned problems, and its purpose is to provide an in-vehicle device, a task assignment method, and a task assignment program that can provide application functions more stably in an in-vehicle network.

[0011] [Effects of this disclosure] According to this disclosure, application-based functions can be implemented more stably in in-vehicle networks.

[0012] [Description of Embodiments of the Disclosure] First, the contents of embodiments of the Disclosure will be listed and described. (1) An in-vehicle device according to an embodiment of the Disclosure is an in-vehicle device comprising: a detection unit for detecting the addition of an application to the in-vehicle device; a load status acquisition unit for acquiring the load status of the in-vehicle device when the addition of the application is detected by the detection unit; an application information acquisition unit for acquiring application information relating to the additional application which is the application detected to be added by the detection unit; and an assignment unit for performing an assignment process for determining which task to assign to the additional application from among a plurality of tasks which differ in priority and execution cycle, based on the load status acquired by the load status acquisition unit and the application information acquired by the application information acquisition unit.

[0013] This configuration allows for the assignment of tasks with appropriate priorities or execution cycles to in-vehicle devices when applications are added, based on the load status of the in-vehicle devices and the information related to those applications. This prevents the real-time performance of both existing and newly added applications from being compromised. Consequently, application-based functionality can be provided more stably within the in-vehicle network.

[0014] (2) In (1) above, the software used by the in-vehicle device may include an OS, the task may be a unit of processing performed by the OS, and the OS may have a plurality of tasks that can be assigned to the additional application.

[0015] In this way, by using information on the load status of the in-vehicle device and the additional application to determine which task to assign to the additional application from among the multiple tasks the OS has, it is possible to prevent delays in processing related to existing applications and additional applications that the OS executes.

[0016] (3) In (1) or (2) above, the assignment unit may perform the assignment process using first correspondence information that shows the correspondence between the task and the processing content of the additional application.

[0017] This configuration allows for the assignment of appropriate tasks according to the processing content of additional applications. Furthermore, candidate tasks to be assigned to additional applications can be easily selected using information that shows the correspondence between tasks and their processing content.

[0018] (4) In (3) above, the processing content in the correspondence relationship may include ADAS processing content, and the assignment unit may decide in the assignment process to assign the task with the highest priority to the additional application if the processing content of the additional application is ADAS processing content.

[0019] When ADAS-related functions are provided in an in-vehicle network, real-time performance is required, so ADAS-related functions have a higher priority than other functions. As described above, if the processing content of an additional application is ADAS processing content, assigning the highest priority task to the additional application can more reliably prevent a decrease in the real-time performance of ADAS-related functions.

[0020] (5) In any of (1) to (4) above, the assignment unit may perform the assignment process using second correspondence information that shows the correspondence between the task and the signature information relating to the signature attached to the additional application.

[0021] This configuration allows for the assignment of appropriate tasks to additional applications based on the signatures they are assigned. Furthermore, candidate tasks for assignment to additional applications can be easily selected using information that shows the correspondence between tasks and signature information.

[0022] (6) In (5) above, the signature information in the correspondence relationship may include the signature information of the developer of the application, and in the second correspondence information, the number of tasks that can be assigned to the additional application to which the developer's signature is attached may be greater than the number of tasks that can be assigned to the additional application to which a signature other than the developer's signature is attached.

[0023] For example, developers of additional applications often also develop the operating system and other components for the in-vehicle devices on which the additional application is installed. It is likely that they develop the additional application while understanding the load conditions of the in-vehicle devices. As described above, when the developer's signature is attached to the additional application, compared to when other signatures are attached to the additional application, there are more tasks that can be assigned to the additional application. This configuration provides a larger number of potential tasks that can prevent a decrease in the real-time performance of the additional application's functions, allowing for flexible determination of which tasks should be assigned to the additional application depending on the load conditions of the in-vehicle devices.

[0024] (7) In any of (1) to (6) above, the allocation unit may perform the allocation process using third correspondence information that indicates the correspondence between the task and the execution cycle of the application.

[0025] This configuration allows for the assignment of appropriate tasks according to the execution cycle of additional applications. Furthermore, candidate tasks for assignment to additional applications can be easily selected using information that shows the correspondence between tasks and their respective execution cycles.

[0026] (8) In any of (1) to (7) above, the allocation unit may perform the allocation process using fourth correspondence information that shows the correspondence between the task and the load status.

[0027] This configuration makes it easy to determine candidate tasks to assign to additional applications using information that shows the correspondence between tasks and the load status of the in-vehicle equipment.

[0028] (9) In any of (1) to (8) above, the application information may include information relating to the signature attached to the additional application.

[0029] This configuration allows for assigning tasks to additional applications with appropriate priorities or execution cycles, based on the load status of the in-vehicle equipment and the signatures assigned to those applications.

[0030] (10) In any of (1) to (9) above, the application information may include the processing content of the additional application, and the processing content may include the processing content of ADAS.

[0031] This configuration allows for the assignment of tasks with appropriate priority or execution cycles to additional applications, depending on the load status of the in-vehicle equipment and the processing content of the additional applications. Furthermore, if the processing content of the additional applications includes ADAS processing, assigning appropriate tasks, such as high-priority tasks, to the additional applications prevents a decrease in the real-time performance of ADAS-related functions.

[0032] (11) In any of (1) to (10) above, the execution cycle of the task may differ from one another among the multiple tasks, the load status acquisition unit may acquire the load status for each task, and the assignment unit may perform the assignment process based on each load status acquired by the load status acquisition unit and the application information acquired by the application information acquisition unit.

[0033] As described above, when the execution cycles of multiple candidate tasks to be assigned to an additional application differ from one another, a configuration that uses the load status and application information for each task to perform the assignment process allows for the assignment of a more appropriate task to the additional application.

[0034] (12) A task assignment method according to an embodiment of the present disclosure is a task assignment method for an in-vehicle device, comprising the steps of: detecting the addition of an application to the in-vehicle device;, if the addition of the application is detected, acquiring the load status of the in-vehicle device; acquiring application information relating to the additional application which is the application whose addition was detected; and performing an assignment process to determine which task to assign to the additional application from among a plurality of tasks that differ in at least one of priority and execution cycle, based on the acquired load status and application information.

[0035] This method allows for the assignment of tasks with appropriate priorities or execution cycles to in-vehicle devices when applications are added, based on the load status of the in-vehicle devices and the information contained within those applications. This prevents the real-time capabilities of both existing and newly added applications from being compromised. Consequently, application functionality can be provided more stably within the in-vehicle network.

[0036] (13) The task assignment program according to the embodiment of the present disclosure is a task assignment program used in an in-vehicle device, and is a program for causing a computer to function as: a detection unit that detects the addition of an application to the in-vehicle device; a load status acquisition unit that acquires the load status of the in-vehicle device when the addition of the application is detected by the detection unit; an application information acquisition unit that acquires application information relating to the additional application which is the application detected to be added by the detection unit; and an assignment unit that performs an assignment process to determine which task to assign to the additional application from among a plurality of tasks which differ in priority and execution cycle, based on the load status acquired by the load status acquisition unit and the application information acquired by the application information acquisition unit.

[0037] This configuration allows for the assignment of tasks with appropriate priorities or execution cycles to in-vehicle devices when applications are added, based on the load status of the in-vehicle devices and the information related to those applications. This prevents the real-time performance of both existing and newly added applications from being compromised. Consequently, application-based functionality can be provided more stably within the in-vehicle network.

[0038] Embodiments of this disclosure will be described below with reference to the drawings. In the drawings, the same or corresponding parts are denoted by the same reference numerals, and their descriptions will not be repeated. Furthermore, at least some of the embodiments described below may be combined in any way.

[0039] [In-vehicle device] Figure 1 is a diagram showing an example of the configuration of an in-vehicle system according to an embodiment of the present disclosure. Referring to Figure 1, the in-vehicle system 301 comprises a relay device 101 and a plurality of in-vehicle devices 201. The in-vehicle system 301 is mounted on a vehicle 1.

[0040] The in-vehicle equipment 201 includes an in-vehicle ECU (Electronic Control Unit), sensors, a navigation system, a human-machine interface, and cameras. The in-vehicle ECU includes an autonomous driving ECU, an engine ECU, a steering control ECU, and a TCU (Telematics Communication Unit).

[0041] In the example shown in Figure 1, the in-vehicle system 301 comprises a plurality of in-vehicle devices 201, namely in-vehicle devices 201A, 201B, and 201C.

[0042] The relay device 101 and the multiple in-vehicle devices 201 constitute an in-vehicle network 401. Each in-vehicle device 201 is connected to the relay device 101, for example, via an Ethernet® cable 51. The relay device 101 relays data transmitted and received between the in-vehicle devices 201.

[0043] It should be noted that the in-vehicle system 301 is not limited to a configuration including three in-vehicle devices 201, and may be configured to include one, two, or four or more in-vehicle devices 201.

[0044] Furthermore, the in-vehicle device 201 is not limited to a configuration connected to the relay device 101 via an Ethernet cable 51, and may be connected to the relay device 101 via a transmission line that complies with other communication standards such as CAN (Controller Area Network), CAN FD (CAN with Flexible Data rate), FlexRay (registered trademark), MOST (Media Oriented System Transport) (registered trademark), LIN (Local Interconnect Network), and CXPI (Clock Extension Peripheral Interface) (registered trademark).

[0045] The in-vehicle device 201 is, for example, a device compliant with the standard of AUTOSAR CP (AUTomotive Open System ARchitecture Classic Platform).

[0046] One or more applications 202 are installed in each in-vehicle device 201. In the example shown in FIG. 1, applications 202A and 202B are installed in the in-vehicle device 201A. An application 202C and an application 202D are installed in the in-vehicle device 201B and the in-vehicle device 201C, respectively.

[0047] For example, after the vehicle 1 is shipped, a new application 202 may be added to a certain in-vehicle device 201 in order to implement a service desired by a user such as the driver of the vehicle 1. Hereinafter, an application 202 newly added to a certain in-vehicle device 201 is also referred to as an "additional application", and an application 202 installed in the in-vehicle device 201 before the additional application is added is also referred to as an "existing application".

[0048] [In-vehicle Device] FIG. 2 is a diagram showing an example of the configuration of software used by the in-vehicle device according to the embodiment of the present disclosure.

[0049] Referring to Fig. 2, the software SW used by the in-vehicle device 201 includes one or more existing applications, an RTE (Run-time Environment) compliant with AUTOSAR CP, and an OS that is basic software.

[0050] In the example shown in Fig. 2, the binary data D includes a plurality of existing applications, which are existing application A and existing application B.

[0051] For example, the OS has a plurality of functions F. In the example shown in Fig. 2, the OS has functions F1, F2 and F3, which are the plurality of functions F.

[0052] For example, the program of an existing application, the program of the RTE, and the program of the OS are stored in the storage unit 15 in the state of a single piece of binary data.

[0053] Fig. 3 is a diagram for explaining an example of tasks executed by the in-vehicle device according to the embodiment of the present disclosure.

[0054] Referring to Fig. 3, the in-vehicle device 201 executes a plurality of tasks T. For example, a task T is a unit of processing executed by the OS of the in-vehicle device 201.

[0055] For example, the OS of the in-vehicle device 201 has a task T allocated to an existing application (hereinafter also referred to as "task T1"). In the example shown in Fig. 3, the OS has a plurality of tasks T1, which are tasks T11 and T12. Task T11 and task T12 are allocated to existing application A and existing application B, respectively.

[0056] Further, for example, the OS has a task T allocated to the function F provided by the OS (hereinafter also referred to as "task T2"). In the example shown in Fig. 3, the OS has a plurality of tasks T2, which are tasks T21 and T22. Task T21 is allocated to functions F1 and F2. Task T22 is allocated to function F3.

[0057] Each task T has a priority assigned to it. The priorities of tasks T11, T12, T21, and T22 are "medium," "low," "high," and "medium," respectively.

[0058] Furthermore, each task T has an execution period set. The execution periods for tasks T11, T12, T21, and T22 are "5ms," "10ms," "1ms," and "5ms," respectively. Hereafter, tasks T11, T12, T21, and T22 will be collectively referred to as existing tasks. Task T3, shown in Figure 3, will be described later.

[0059] If the in-vehicle device 201 has multiple cores (not shown), it can execute multiple tasks T in parallel. For example, if the in-vehicle device 201 executes multiple tasks T in parallel as shown in Figure 3, namely a task T with an execution period of "1 ms", a task T with an execution period of "5 ms", and a task T with an execution period of "10 ms", the number of cores in the in-vehicle device 201 is three or more.

[0060] On the other hand, if the in-vehicle device 201 has a single core, it cannot execute multiple tasks T in parallel. In this case, the in-vehicle device 201 executes the multiple tasks T in order from the task with the highest priority.

[0061] Figure 4 is a diagram showing the configuration of an in-vehicle device according to an embodiment of the present disclosure. Referring to Figure 4, the in-vehicle device 201 comprises a detection unit 11, a load status acquisition unit 12, an application information acquisition unit 13, an allocation unit 14, and a storage unit 15. Some or all of the detection unit 11, the load status acquisition unit 12, the application information acquisition unit 13, and the allocation unit 14 are implemented, for example, by a processing circuit (Circuitry) including one or more processors. The storage unit 15 is, for example, a non-volatile memory included in the processing circuit.

[0062] (Addition of Applications) Figure 5 shows another example of the configuration of software used by the in-vehicle device according to the embodiment of the present disclosure. The software SW shown in Figure 5 differs from the software SW shown in Figure 2 in that it further includes additional applications.

[0063] Referring to Figures 4 and 5, the detection unit 11 detects the addition of application 202 to its in-vehicle device 201.

[0064] More specifically, the detection unit 11 detects an additional application 202 if another application 202, different from the existing application, is installed on its in-vehicle device 201.

[0065] The detection unit 11 then outputs detection result information indicating that an additional application has been detected to the load status acquisition unit 12 and the application information acquisition unit 13.

[0066] (Load Status Acquisition Unit) When the detection unit 11 detects the addition of an application 202, the load status acquisition unit 12 acquires the load status of its own in-vehicle device 201. More specifically, for example, the load status acquisition unit 12 acquires the load status of each of a plurality of tasks T whose execution cycles P are different from each other.

[0067] (a1) When the in-vehicle device 201 has multiple cores, Figure 6 is a diagram illustrating an example of the process by which the in-vehicle device according to the embodiment of the present disclosure acquires its own load status. Figure 6 shows a case in which the in-vehicle device 201 having three or more cores acquires its own load status.

[0068] Referring to Figure 6, for example, if the on-board device 201 has three or more cores, the load status acquisition unit 12 acquires the load L1 for each core.

[0069] More specifically, the load status acquisition unit 12 calculates the load L1 of each core using a predetermined calculation formula C1 if its on-board device 201 has three or more cores.

[0070] For example, the memory unit 15 stores the following equation (1), which is calculation formula C1: L1 = (E / P) × 100 ... (1)

[0071] In equation (1), P is the execution cycle of task T. E is the time required for the OS to execute task T per cycle (hereinafter also referred to as "task processing time"). The unit of load L1 is percent.

[0072] In the example shown in Figure 6, the task processing time E for task T with an execution period P of "1 ms" is "0.4 ms". The task processing time E for task T with an execution period P of "5 ms" is "2.0 ms". The task processing time E for task T with an execution period P of "10 ms" is "1.0 ms". In Figure 6 and Figure 7 described later, task T with an execution period P of "1 ms", task T with an execution period P of "5 ms", and task T with an execution period P of "10 ms" are also referred to as task Ta, task Tb, and task Tc, respectively.

[0073] For example, if the in-vehicle device 201 has multiple cores, the memory unit 15 stores multiple execution cycles P in the in-vehicle device 201 before the additional application is added, and multiple task processing times E corresponding to each of the multiple execution cycles P.

[0074] When the load status acquisition unit 12 receives detection result information from the detection unit 11, it acquires multiple execution cycles P and multiple task processing times E from the storage unit 15.

[0075] The load status acquisition unit 12 then calculates the load L1 for each core by substituting the execution period P and task processing time E corresponding to that core into equation (1).

[0076] In the example shown in Figure 6, the load L1 of the core executing task Ta with an execution period P of "1 ms" is "40%". The load L1 of the core executing task Tb with an execution period P of "5 ms" is "40%". The load L1 of the core executing task Tc with an execution period P of "10 ms" is "10%".

[0077] (a2) When the in-vehicle device 201 has one core, Figure 7 is a diagram illustrating another example of the process by which the in-vehicle device according to the embodiment of the present disclosure acquires its own load status. Figure 7 shows the case in which the in-vehicle device 201 having one core acquires its own load status.

[0078] Referring to Figure 7, the load status acquisition unit 12 calculates the load L2 when the OS executes task T for each execution period P, assuming that its in-vehicle device 201 has one core.

[0079] More specifically, the load status acquisition unit 12 calculates the load L2 for each execution period P of task T using a predetermined calculation formula C2, if its own in-vehicle device 201 has one core.

[0080] For example, the memory unit 15 stores the following equation (2), which is calculation formula C2: L2 = ((E + W) / P) × 100 ... (2)

[0081] In equation (2), L, D, and P are the same as L, D, and P in equation (1), respectively. W is the total waiting time that the OS waits for in one cycle of task T when executing task T (hereinafter also referred to as "total waiting time"). The unit of load L2 is percent.

[0082] In the example shown in Figure 7, the processing times E for each task—Ta with an execution period P of 1 ms, Tb with an execution period P of 5 ms, and Tc with an execution period P of 10 ms—are the same as in Figure 6.

[0083] Furthermore, in the example shown in Figure 7, the priorities of task Ta, task Tb, and task Tc are "high," "medium," and "low," respectively. In this case, the OS executes tasks Ta, Tb, and Tc in this order. Therefore, for example, while task Ta is executing, the OS waits for the execution of tasks Tb and Tc. That is, the total waiting time W for task Ta is "zero" seconds. Note that in the example shown in Figure 7, the waiting time for each task T is indicated by a hatched rectangle.

[0084] When the OS finishes executing task Ta, it executes task Tb, which has a "medium" priority, during the period from the time task Ta finishes until the next time task Ta is to start.

[0085] Specifically, in the example shown in Figure 7, the task processing time E for task Ta and the task processing time E for task Tb are "0.4 ms" and "2.0 ms," respectively. In this case, the OS waits for 0.4 seconds after starting the execution of task Ta for task Tb to begin, and then performs a process to execute a portion of task Tb during the period between the end of task Ta's execution and the start of task Ta's execution. The OS repeats this process until the entire execution of task Tb is completed. In the example shown in Figure 7, the timing at which the OS finishes the execution of task Tb in the first cycle is "3.6" seconds after the start of task Ta's execution in the first cycle. The total waiting time W for task Tb is "1.6 ms."

[0086] Additionally, when neither Task Ta nor Task Tb is running, the OS executes Task Tc, which has a "low" priority.

[0087] Specifically, in the example shown in Figure 7, the task processing time E for task Tc is "1.0 ms". For example, the OS waits for the execution of task Tc to finish until the execution of task Tb in the first cycle is complete. Then, the OS executes a portion of task Tc during the period from "3.6 seconds" when task Tb finishes execution until "4 seconds" when task Ta begins execution.

[0088] Then, when the timing of "4 seconds" to start executing task Ta arrives, the OS starts executing task Ta and waits for the execution of task Tc to begin. When the OS finishes executing task Ta, it executes the remainder of task Tc during the period from "4.4 seconds" after the completion of task Ta until the next timing of "5 seconds" when task Ta will start executing again. In this case, the timing when the OS finishes executing task Tc in the first cycle is "5.0" seconds after the start of the execution of task Ta in the first cycle. The total waiting time W for task Tc is "4.0 ms".

[0089] Referring again to Figure 4, for example, if its in-vehicle device 201 has one core, the memory unit 15 stores multiple execution cycles P and multiple task processing times E, as well as multiple total waiting times W corresponding to each of the multiple execution cycles P.

[0090] When the load status acquisition unit 12 receives detection result information from the detection unit 11, it acquires multiple execution cycles P, multiple task processing times E, and multiple total waiting times W from the storage unit 15.

[0091] The load status acquisition unit 12 then calculates the load L2 by substituting the execution period P, the corresponding task processing time E, and the total waiting time W into equation (2) for each execution period P.

[0092] In the example shown in Figure 7, the OS load L2 when task Ta is executed is "40%". When task Tb is executed, the OS load L2 is "72%". When task Tc is executed, the OS load L2 is "50%". Hereafter, load L1 and load L2 will also be referred to as load L.

[0093] Referring again to Figure 4, when the load status acquisition unit 12 acquires the load status of its own in-vehicle device 201, it outputs load information indicating the said load status to the allocation unit 14.

[0094] More specifically, for example, when the load status acquisition unit 12 calculates multiple loads L, it outputs information indicating the pair of the multiple loads L and the multiple execution cycles P corresponding to each of the multiple loads L to the assignment unit 14 as load information.

[0095] (Acquisition of application information) The application information acquisition unit 13 acquires application information related to the additional application.

[0096] For example, application information includes at least one of the following: the execution period R of the additional application in the specifications of the additional application, signature information relating to the signature attached to the additional application, and the processing content of the additional application. Here, application information is assumed to include at least one of the execution period of the additional application, signature information, and the processing content of the additional application.

[0097] The signatures attached to the additional application include the signature of the developer who developed the in-vehicle device 201 on which the additional application is installed, and the signature of the manufacturer of the vehicle 1. The manufacturer is, for example, an OEM (Original Equipment Manufacturer).

[0098] For example, the processing content of the additional application may include the processing content of ADAS (Advanced Driving Assistant System), the processing content of IVI (In-Vehicle Information), and the processing content of the vehicle 1 body system.

[0099] The ADAS processing involves assisting the driving of vehicle 1 using measurement results from various sensors such as LiDAR (Light Detection and Ranging). The IVI processing involves audio playback and display of road information. The body system processing involves controlling the air conditioning and power windows of vehicle 1. The content of task T executed by the OS of the in-vehicle device 201 is the same as the processing content of application 202, or a subdivision of the processing content of application 202.

[0100] When the application information acquisition unit 13 receives detection result information from the detection unit 11, it outputs a request notification to the additional application indicating that it requests application information.

[0101] When an additional application receives a request notification from the application information acquisition unit 13, it outputs its own application information to the application information acquisition unit 13.

[0102] The application information acquisition unit 13 outputs the application information received from the additional application to the assignment unit 14.

[0103] (Tasks for additional applications) Referring again to Figure 3, the OS has multiple tasks T (hereinafter also referred to as "task T3") that can be assigned to additional applications. In the example shown in Figure 3, the OS has multiple tasks T3, which are tasks T31, T32, and T33.

[0104] Each task T3 has a priority assigned to it. The priorities of tasks T31, T32, and T33 are "high," "medium," and "low," respectively.

[0105] Furthermore, each task T3 has an execution period Q set. The execution period Q for task T31, task T32, and task T33 are "1 ms", "5 ms", and "10 ms", respectively.

[0106] In other words, in the example shown in Figure 3, both the priority and execution period Q are different among the multiple tasks T3. Alternatively, either the priority or the execution period Q may be different among the multiple tasks T3, while the other is the same.

[0107] (Assignment Unit) Referring again to Figure 4, the assignment unit 14 performs an assignment process to determine which task T3 to assign to the additional application from among a plurality of tasks T3 that differ from each other in both priority and execution cycle, based on the load status acquired by the load status acquisition unit 12 and the application information acquired by the application information acquisition unit 13.

[0108] <Load Status Table> Figure 8 shows an example of a load status table held by an in-vehicle device according to the embodiment of this disclosure.

[0109] Referring to Figures 4 and 8, the storage unit 15 stores a load status table U1 that shows the correspondence between task T3, the execution cycle P of an existing task, and the load status. The load status table U1 is an example of the fourth correspondence information.

[0110] In the load status table U1 shown in Figure 8, the condition for assigning "Task T31" to the additional application is that the load L of an existing task with an execution period P of "1 ms" is less than 30%. The condition for assigning "Task T32" to the additional application is that the load L of an existing task with an execution period P of "5 ms" is less than 80%. For example, if the load L of an existing task with an execution period P of "1 ms" is 30% or more, and the load L of an existing task with an execution period P of "5 ms" is 80% or more, then the task T3 that can be assigned to the additional application is "Task T33".

[0111] <Periodic Table> Figure 9 shows an example of a periodic table held by an in-vehicle device according to the embodiment of this disclosure.

[0112] Referring to Figures 4 and 9, the storage unit 15 stores a period table U2 that shows the correspondence between task T3, the execution period Q of task T3, and the execution period R of the additional application in the specifications of the additional application. The period table U2 is an example of third correspondence information.

[0113] In the periodic table U2, if the execution period R in the specifications of the additional application is "less than 5 ms", the task T3 that can be assigned to the additional application is "Task T31" with an execution period Q of "1 ms". If the execution period R in the specifications of the additional application is "5 ms or more and less than 10 ms", the task T3 that can be assigned to the additional application is "Task T31" or "Task T32" with an execution period Q of "5 ms". If the execution period R in the specifications of the additional application is "10 ms or more", the task T3 that can be assigned to the additional application is "Task T31", "Task T32", or "Task T33" with an execution period Q of "10 ms".

[0114] <Signature Type Table> Figure 10 shows an example of a signature type table held by an in-vehicle device according to an embodiment of the present disclosure.

[0115] Referring to Figures 4 and 10, the storage unit 15 stores a signature type table U3 that shows the correspondence between task T3, the priority of task T3, and the signature information related to the signature attached to the additional application. The signature type table U3 is an example of second correspondence information.

[0116] In the signature type table U3 shown in Figure 10, the tasks T3 that can be assigned to an additional application with a developer signature are "Task T31", "Task T32", or "Task T33". The tasks T3 that can be assigned to an additional application with an OEM signature are "Task T31" or "Task T32". The task T3 that can be assigned to an additional application with a signature other than the developer signature or the OEM signature is "Task T33". In other words, the number of tasks T3 Ma that can be assigned to an additional application with a developer signature is greater than the number of tasks T3 Mb that can be assigned to an additional application with an OEM signature, and the number of tasks T3 Mc that can be assigned to an additional application with the other signature.

[0117] <Processing Content Table> Figure 11 shows an example of a processing content table held by an in-vehicle device according to an embodiment of the present disclosure.

[0118] Referring to Figures 4 and 11, the storage unit 15 stores a processing content table U4 that shows the correspondence between task T3, the priority of task T3, and the processing content of the additional application. The processing content table U4 is an example of first correspondence information.

[0119] In the processing content table U4 shown in Figure 11, the task T3 that can be assigned to an additional application whose processing content is "ADAS" is "Task T31" with a priority of "High". The task T3 that can be assigned to an additional application whose processing content is "IVI" is "Task T31" or "Task T32" with a priority of "Medium". The task T3 that can be assigned to an additional application whose processing content is "Body System" is "Task T31", "Task T32", or "Task T33" with a priority of "Low".

[0120] For example, the load status table U1, the periodic table U2, the signature type table U3, and the processing content table U4 are registered in the storage unit 15 by the vehicle dealer or the like when an additional application is installed on the in-vehicle device 201.

[0121] <Assignment Processing> For example, the assignment unit 14 performs assignment processing using the load status table U1 and one of the periodic table U2, signature type table U3, and processing content table U4 stored in the storage unit 15.

[0122] (b1) Example 1 Figure 12 is a diagram illustrating an example of allocation processing by an in-vehicle device according to an embodiment of the present disclosure.

[0123] Referring to Figures 4 and 12, the allocation unit 14 receives load information from the load status acquisition unit 12 and application information including the execution period R in the specifications of the additional application (hereinafter also referred to as "application information G1") from the application information acquisition unit 13, and then performs allocation processing using the load status table U1 and the period table U2.

[0124] More specifically, when the allocation unit 14 receives load information from the load status acquisition unit 12, it refers to the load status table U1 in the storage unit 15 and determines whether a task T3 with the same execution period Q as the execution period P of an existing task indicated by the load information can be assigned to an additional application.

[0125] In the example shown in Figure 12, the load L when the OS executes an existing task with an execution cycle P of "1 ms", the load L when executing an existing task with an execution cycle P of "5 ms", and the load L when executing an existing task with an execution cycle P of "10 ms" are "25%", "40%", and "10%", respectively. In this case, the allocation unit 14 determines that it is possible to assign "Task T31", "Task T32", or "Task T33" to the additional application.

[0126] Furthermore, when the allocation unit 14 receives application information G1 from the application information acquisition unit 13, it refers to the periodic table U2 in the storage unit 15 to determine which task T3 can be assigned to the additional application.

[0127] In the example shown in Figure 12, the execution period R in the specifications of the additional application, as indicated by the application information G1, is "5 ms or more and less than 10 ms". In this case, the allocation unit 14 determines that it is possible to assign "Task T31" or "Task T32" to the additional application by referring to the period table U2 in the storage unit 15.

[0128] The allocation unit 14 identifies the task T3 to be assigned to the additional application by comprehensively considering the judgment result of task T3 using the load status table U1 and the judgment result of task T3 using the periodic table U2.

[0129] More specifically, for example, the allocation unit 14 identifies the task T3 that is common to both the task T3 determination result using the load status table U1 and the task T3 determination result using the periodic table U2, and which has the highest priority, as the task T3 to be assigned to the additional application.

[0130] In the example shown in Figure 12, the tasks T3 that are common to both the task T3 determination results using the load status table U1 and the task T3 determination results using the periodic table U2 are "Task T31" and "Task T32". Here, the priority of "Task T31" is higher than the priority of "Task T32". In this case, the allocation unit 14 identifies "Task T31" as the task T3 to be assigned to the additional application.

[0131] Furthermore, if there is one task T3 that is common to both the task T3 determination result using the load status table U1 and the task T3 determination result using the periodic table U2, the allocation unit 14 identifies that task T3 as the task T3 to be assigned to the additional application.

[0132] (b2) Example 2 Figure 13 is a diagram illustrating another example of allocation processing by an in-vehicle device according to an embodiment of the present disclosure.

[0133] Referring to Figures 5 and 13, the allocation unit 14 receives load information from the load status acquisition unit 12 and application information including signature information (hereinafter also referred to as "application information G2") from the application information acquisition unit 13, and then performs allocation processing using the load status table U1 and the signature type table U3.

[0134] In the example shown in Figure 13, the load L for each execution cycle P value, as indicated by the load information, is the same as in Figure 12. That is, in the example shown in Figure 13, the allocation unit 14 determines that "Task T31", "Task T32", or "Task T33" can be assigned to the additional application.

[0135] When the allocation unit 14 receives application information G2 from the application information acquisition unit 13, it refers to the signature type table U3 in the storage unit 15 to determine which task T3 can be assigned to the additional application.

[0136] In the example shown in Figure 13, the application information G2 includes information about the "developer's" signature as signature information. In this case, the allocation unit 14 determines that it is possible to assign "Task T31", "Task T32", or "Task T33" by referring to the signature type table U3 in the storage unit 15.

[0137] The allocation unit 14 identifies the task T3 to be assigned to the additional application by comprehensively considering the judgment result of task T3 using the load status table U1 and the judgment result of task T3 using the periodic table U2.

[0138] More specifically, the allocation unit 14 identifies the task T3 that is common to both the task T3 determination results using the load status table U1 and the task T3 determination results using the periodic table U2, and which has the highest priority, as the task T3 to be assigned to the additional application.

[0139] In the example shown in Figure 13, the tasks T3 that are common to both the task T3 determination results using the load status table U1 and the task T3 determination results using the periodic table U2 are "Task T31", "Task T32", and "Task T33". Here, the priority of "Task T31" is higher than the priorities of "Task T32" and "Task T33". In this case, the allocation unit 14 identifies "Task T31" as the task T3 to be assigned to the additional application.

[0140] (b3) Example 3 Figure 14 is a diagram illustrating another example of allocation processing by an in-vehicle device according to an embodiment of the present disclosure.

[0141] Referring to Figures 5 and 14, the allocation unit 14 receives load information from the load status acquisition unit 12 and application information including the processing details of the additional application (hereinafter also referred to as "application information G3") from the application information acquisition unit 13, and then performs allocation processing using the load status table U1 and the processing details table U4.

[0142] In the example shown in Figure 14, the load L for each execution cycle P value, as indicated by the load information, is the same as in Figure 12. That is, in the example shown in Figure 14, the allocation unit 14 determines that "Task T31", "Task T32", or "Task T33" can be assigned to the additional application.

[0143] When the allocation unit 14 receives application information G3 from the application information acquisition unit 13, it refers to the processing content table U4 in the storage unit 15 to determine which task T3 can be assigned to the additional application.

[0144] In the example shown in Figure 14, application information G3 includes the processing details of "ADAS" as the processing details of the additional application. In this case, the allocation unit 14 determines that "Task T31" can be allocated by referring to the processing details table U4 in the storage unit 15.

[0145] The allocation unit 14 identifies the task T3 to be assigned to the additional application by comprehensively considering the judgment result of task T3 using the load status table U1 and the judgment result of task T3 using the processing content table U4.

[0146] More specifically, for example, the allocation unit 14 identifies the task T3 that is common to both the task T3 determination result using the load status table U1 and the task T3 determination result using the processing content table U4, and which has the highest priority, as the task T3 to be assigned to the additional application.

[0147] In the example shown in Figure 14, the task T3 that is common to both the determination result of task T3 using the load status table U1 and the determination result of task T3 using the periodic table U2 is "task T31". In this case, the allocation unit 14 identifies "task T31" as the task T3 to be assigned to the additional application.

[0148] (b4) Example 4 Figure 15 is a diagram illustrating another example of allocation processing by an in-vehicle device according to an embodiment of the present disclosure. Figure 15 shows a case in which the allocation unit 14 in the in-vehicle device 201 performs allocation processing using the load status table U1 and the processing content table U4 in the storage unit 15.

[0149] In the example shown in Figure 15, the load L when the OS executes an existing task with an execution cycle P of "1 ms", and the load L when the OS executes an existing task with an execution cycle P of "5 ms", are "40%" and "80%", respectively, which is different from the example shown in Figure 14. In this case, the allocation unit 14 determines that "Task T31" or "Task T32" cannot be assigned to the additional application, and determines that "Task T33" can be assigned to the additional application.

[0150] Furthermore, in the example shown in Figure 15, the processing content included in application information G3 is the processing content of "ADAS," similar to the example shown in Figure 14. In this case, the allocation unit 14 determines that "Task T32" and "Task T33" cannot be assigned to the additional application, and determines that "Task T31" can be assigned to the additional application. In other words, in the example shown in Figure 15, there is no common Task T3 between the determination result of Task T3 using the load status table U1 and the determination result of Task T3 using the processing content table U4.

[0151] If there are no common tasks T3s between the task T3 determination results using the load status table U1 and the task T3 determination results using the processing content table U4, the allocation unit 14 obtains priority information indicating the priority of each of the multiple processes N for the OS to execute the additional application.

[0152] For example, priority information is registered in the storage unit 15 by the vehicle dealer or the like when an additional application is installed on the in-vehicle device 201.

[0153] For example, the allocation unit 14 performs the allocation process based on the load status of its own in-vehicle device 201 acquired by the load status acquisition unit 12, the application information acquired by the application information acquisition unit 13, and the acquired priority information.

[0154] More specifically, if there are no common tasks T3s between the task T3 determination results using the load status table U1 and the task T3 determination results using the processing content table U4, the allocation unit 14 obtains priority information from the storage unit 15.

[0155] When the allocation unit 14 obtains priority information, it refers to the priority information to confirm the priority of each of the multiple processes N that the OS uses to execute additional applications, as indicated by the priority information.

[0156] In the example shown in Figure 15, the multiple processes N that the OS uses to execute the additional application are processes N1 and N2. Process N2 has a higher priority than process N1.

[0157] The allocation unit 14 then assigns a plurality of tasks T3 with different priorities, namely task T33 which is task T3 determined using the load status table U1, and task T31 which is task T3 determined using the processing content table U4, to a plurality of processes N.

[0158] Specifically, the allocation unit 14 assigns task T3, which has a higher priority, to process N2. The allocation unit 14 also assigns task T3, which has a lower priority, to process N1. In the example shown in Figure 15, the allocation unit 14 assigns "task T31" and "task T33" to processes N2 and N1, respectively.

[0159] [Operation Flow] Next, the operation flow of the in-vehicle device according to the embodiment of this disclosure will be explained with reference to the drawings.

[0160] Figure 16 is a flowchart illustrating an example of the operation procedure when an in-vehicle device according to an embodiment of the present disclosure performs an allocation process.

[0161] Referring to Figure 16, first, the in-vehicle device 201 waits for the addition of application 202 to itself (NO in step ST101), and when it detects the addition of application 202 (YES in step ST101), it acquires its own load status (step ST202).

[0162] Next, the in-vehicle device 201 acquires application information regarding the additional application 202, which has been detected as an additional application (step ST103). Steps ST102 and ST103 may be executed in any order or in parallel.

[0163] Next, the in-vehicle device 201 acquires its own load status and application information, and then, based on the acquired load status and application information, performs an assignment process to determine which task T3 to assign to the additional application from among a plurality of tasks T3 (step ST104).

[0164] Next, once the in-vehicle device 201 has completed the allocation process, it waits for the addition of a new application 202 to itself (NO in step ST101).

[0165] In the in-vehicle system 301 according to the embodiment of this disclosure, the in-vehicle device 201 is configured to assign task T3, which has the highest priority, to the additional application in the assignment process when the processing content of the additional application is ADAS processing content, but it is not limited to this. The in-vehicle device 201 may also be configured to assign task T3, which has the highest priority, to the additional application in the assignment process when the processing content of the additional application is processing content other than ADAS processing content.

[0166] Furthermore, in the in-vehicle system 301 according to the embodiment of this disclosure, the number of tasks T3 Ma that can be assigned to additional applications bearing the developer's signature in the signature type table U3 stored in the storage unit 15 of the in-vehicle device 201 is greater than, but not limited to, the number of tasks T3 that can be assigned to additional applications bearing signatures other than the developer's signature, specifically, the OEM's signature, etc. For example, in the signature type table U3, the number Ma and the number of tasks T3 that can be assigned to additional applications bearing the OEM's signature Mb may be the same, and the number of tasks T3 Mc that can be assigned to additional applications bearing signatures other than the developer and the OEM may be less than the number Ma and the number Mb.

[0167] Furthermore, in the in-vehicle system 301 according to the embodiment of this disclosure, the in-vehicle device 201 is configured to acquire application information including the execution period R, signature information, or processing content of the additional application in the specifications of the additional application, but is not limited to this. The application information of the in-vehicle device 201 may also include other content besides the execution period R, signature information, and processing content. In this case, the in-vehicle device 201 performs the assignment process using a correspondence table that shows the correspondence between task T3 and the other content. That is, the in-vehicle device 201 may perform the assignment process using tables other than the period table U2, signature type table U3, and processing content table U4.

[0168] Furthermore, in the in-vehicle system 301 according to the embodiment of this disclosure, both the priority and execution cycle Q differ among a plurality of candidate tasks T3 to be assigned to an additional application, and the in-vehicle device 201 acquires the load status when executing each of the plurality of tasks T3 and performs assignment processing based on each load status and the application information of the additional application, but the system is not limited to this. Among the plurality of tasks T3, either the priority or the execution cycle Q may differ from each other, while the other may be the same.

[0169] Furthermore, in the in-vehicle system 301 according to the embodiment of this disclosure, task T3 assigned to an additional application by the in-vehicle device 201 is defined as a unit of processing executed by the OS, but this is not limited to that. Task T3 may be a unit of processing executed by software other than the OS.

[0170] The embodiments described above should be considered in all respects to be illustrative and not restrictive. The scope of the present invention is indicated by the claims rather than the above description, and all modifications within the meaning and scope of the claims are intended to be included.

[0171] Each process (each function) in the above-described embodiment is implemented by a processing circuit including one or more processors. The processing circuit may consist of an integrated circuit, etc., which combines one or more memories, various analog circuits, and various digital circuits in addition to the one or more processors. The one or more memories store programs (instructions) that cause the one or more processors to execute each of the above processes. The one or more processors may execute each of the above processes according to the programs read from the one or more memories, or they may execute each of the above processes according to logic circuits that have been designed in advance to execute each of the above processes. The above-mentioned processor may be various processors suitable for computer control, such as a CPU (Central Processing Unit), GPU (Graphics Processing Unit), DSP (Digital Signal Processor), FPGA (Field Programmable Gate Array), and ASIC (Application Specific Integrated Circuit). Furthermore, multiple physically separated processors may cooperate with each other to perform the above-mentioned processes. For example, processors installed in multiple physically separated computers may cooperate with each other via a network such as a LAN (Local Area Network), WAN (Wide Area Network), and the Internet to perform the above-mentioned processes. The above program may be installed on the above memory via the above network from an external server device, or it may be distributed on a recording medium such as a CD-ROM (Compact Disc Read Only Memory), DVD-ROM (Digital Versatile Disc Read Only Memory), or semiconductor memory, and then installed on the above memory from the above recording medium.

[0172] The above description includes the following features: [Addendum 1] An in-vehicle device comprising a processing circuit, wherein the processing circuit detects the addition of an application to the in-vehicle device, and when the addition of an application is detected, acquires the load status of the in-vehicle device, acquires application information relating to the additional application which is the application that was detected to be added, and performs an assignment process to determine which task to assign to the additional application from among a plurality of tasks which differ in at least one of priority and execution cycle, based on the acquired load status and application information.

[0173] 1 Vehicle 11 Detection unit 12 Load status acquisition unit 13 Application information acquisition unit 14 Assignment unit 15 Storage unit 51 Ethernet cable 101 In-vehicle relay device 201 In-vehicle device 301 In-vehicle system 401 In-vehicle network Tb1 Load status table Tb2 Period table Tb3 Signature type table Tb4 Processing content table

Claims

1. An in-vehicle device comprising: a detection unit for detecting the addition of an application to the in-vehicle device; a load status acquisition unit for acquiring the load status of the in-vehicle device when the addition of the application is detected by the detection unit; an application information acquisition unit for acquiring application information relating to the additional application which is the application detected as added by the detection unit; and an assignment unit for performing an assignment process to determine which task to assign to the additional application from among a plurality of tasks having different priorities and execution cycles, based on the load status acquired by the load status acquisition unit and the application information acquired by the application information acquisition unit.

2. The in-vehicle device according to claim 1, wherein the software used by the in-vehicle device includes an OS, the task is a unit of processing performed by the OS, and the OS has the plurality of tasks that can be assigned to the additional application.

3. The in-vehicle device according to claim 1 or claim 2, wherein the assignment unit performs the assignment process using first correspondence information that indicates the correspondence between the task and the processing content of the additional application.

4. The in-vehicle device according to claim 3, wherein the processing content in the correspondence relationship includes the processing content of ADAS, and the assignment unit, when the processing content of the additional application is the processing content of ADAS, decides in the assignment process to assign the task with the highest priority to the additional application.

5. The in-vehicle device according to any one of claims 1 to 4, wherein the assignment unit performs the assignment process using second correspondence information that indicates the correspondence between the task and the signature information relating to the signature attached to the additional application.

6. The in-vehicle device according to claim 5, wherein the signature information in the correspondence includes the signature information of the developer of the application, and in the second correspondence information, the number of tasks that can be assigned to the additional application to which the developer's signature is attached is greater than the number of tasks that can be assigned to the additional application to which a signature other than the developer's signature is attached.

7. The in-vehicle device according to any one of claims 1 to 6, wherein the allocation unit performs the allocation process using third correspondence information indicating the correspondence between the task and the execution cycle of the application.

8. The in-vehicle device according to any one of claims 1 to 7, wherein the assignment unit performs the assignment process using fourth correspondence information indicating the correspondence between the task and the load status.

9. The in-vehicle device according to any one of claims 1 to 8, wherein the application information includes information relating to a signature assigned to the additional application.

10. The in-vehicle device according to any one of claims 1 to 9, wherein the application information includes the processing content of the additional application, and the processing content may include the processing content of ADAS.

11. The in-vehicle device according to any one of claims 1 to 10, wherein the execution cycle of the tasks differs from one another among the plurality of tasks, the load status acquisition unit acquires the load status for each task, and the assignment unit performs the assignment process based on each load status acquired by the load status acquisition unit and the application information acquired by the application information acquisition unit.

12. A task assignment method for an in-vehicle device, comprising: detecting the addition of an application to the in-vehicle device;, if the addition of the application is detected, acquiring the load status of the in-vehicle device; acquiring application information relating to the additional application which is the application whose addition was detected; and performing an assignment process to determine which task to assign to the additional application from among a plurality of tasks that differ in at least one of priority and execution cycle, based on the acquired load status and application information.

13. A task assignment program used in an in-vehicle device, for causing a computer to function as: a detection unit that detects the addition of an application to the in-vehicle device; a load status acquisition unit that acquires the load status of the in-vehicle device when the addition of the application is detected by the detection unit; an application information acquisition unit that acquires application information relating to the additional application which is the application detected as added by the detection unit; and an assignment unit that performs an assignment process to determine which task to assign to the additional application from among a plurality of tasks that differ in at least one of priority and execution cycle, based on the load status acquired by the load status acquisition unit and the application information acquired by the application information acquisition unit.

Images