JP7006451B2 - Electronic control device and multi-core allocation method - Google Patents

Description

The present disclosure relates to a core allocation method in an electronic control device including a multi-core CPU having a plurality of cores.

Patent Document 1 describes a technique in which an operating system (hereinafter referred to as an OS) incorporated in a microcomputer equipped with a multi-core CPU switches a method of assigning a task to a plurality of cores at the time of failure diagnosis. Specifically, the OS can switch each of the plurality of cores individually from one of the processing modes of Symmetric Multi-Processing (hereinafter, SMP) and Asymmetric Multi-Processing (hereinafter, AMP) to the other. SMP is an allocation method that dynamically allocates tasks according to the processing load of each core. AMP is an allocation method in which the tasks to be assigned to the core are fixedly determined.

Japanese Patent No. 5316128

For example, in the field of in-vehicle electronic control devices, the application of a technique for integrating the operations of a plurality of OSs by a hypervisor in a single computer system is advancing. However, the above-mentioned background technology relates to the control of the core allocation method in a system in which a single OS is embedded. In a computer system in which a plurality of OSs operating on a hypervisor are embedded, it is necessary to consider not only the control of the allocation method for a single OS but also the control of the allocation method among the plurality of OSs. Therefore, the above-mentioned background technology cannot be applied as it is to a computer system in which a plurality of OSs operating on a hypervisor are embedded.

For example, when one core is shared by a plurality of OSs, it is not enough to control the core allocation only for a single OS. That is, it is necessary to coordinately execute the method of allocating the core to a plurality of OSs by the hypervisor and the method of allocating the core to the tasks running on each OS.

In addition, when handling a task that requires AMP in an OS running on a hypervisor, it is necessary to statically fix the core used by the OS to which the relevant OS belongs. However, since the task may change its operation or stop state and the processing load may increase or decrease, the method of allocating the core at all times is to use the core when the task is stopped or the processing load is reduced. Unable to make effective use of free resources.

Further, it is conceivable that the processing load of the task of each OS increases or decreases depending on the state of the system such as the vehicle on which the electronic control system is mounted, not only at the time of failure diagnosis. Therefore, it is desired to realize an allocation method for effectively utilizing the resources of a plurality of cores by a plurality of OSs according to changes in the state of the system.

Therefore, one aspect of the present disclosure is preferably to provide a technique for effectively switching the core allocation method according to a situation in an electronic control device having a multi-core CPU and operating a plurality of OSs on the multi-core CPU. ..

The electronic control device (1) according to one aspect of the present disclosure includes a multi-core CPU (10) having a plurality of cores (11). On this multi-core CPU, a plurality of program systems (13, 14, 15) including an operating system and an application program running on the operating system are operated. This electronic control device includes a state acquisition unit (30), a storage unit (20), a first allocation unit (12), and a second allocation unit (131, 141, 151).

In addition, the reference numerals in parentheses described in this column and the scope of claims indicate the correspondence with the specific means described in the embodiment described later as one embodiment, and the technical scope of the present disclosure is defined. It is not limited.

The state acquisition unit is configured to acquire the state of the system on which the electronic control device is mounted. The storage unit is configured to store definition information. This definition information is information representing the core requirements that each program system should assign to each program system in order to execute a task for each specific state that can be acquired by the state acquisition unit.

The first allocation unit is configured to allocate the cores used by each program system to execute the tasks in order to enable the tasks of the plurality of program systems to be executed in parallel on the plurality of cores. In addition, the first allocation unit changes the core assigned to each program system according to the definition represented by the definition information stored in the storage unit according to the change in the state of the system acquired by the status acquisition unit. It is configured in. The second allocation unit is configured in the operating system of each program system to allocate one or more cores allocated by the first allocation unit to each one or a plurality of tasks executed by the program system.

According to the configuration as described above, it is possible to dynamically assign tasks by each OS to a plurality of cores in cooperation among a plurality of OSs according to the state of the system in which the electronic control device is mounted. By doing so, it becomes possible to effectively utilize the resources of each core against the increase / decrease in the processing load that may change depending on the state of the system.

It is a block diagram which shows the main structure of the electronic control apparatus of embodiment. It is a figure which shows an example of the function which each program system has. It is a figure which shows an example of the maximum processing amount of each program system. It is a figure which shows an example of the operation requirement of the task in the 1st system. It is a figure which shows an example of the operation requirement of the task in the 2nd system. It is a figure which shows an example of the operation requirement of the task in the 3rd system. It is a figure which shows an example of the definition of the core allocation method for each system. It is a flowchart which shows the procedure of a hypervisor processing. It is a flowchart which shows the procedure of OS processing. It is a figure which shows an example of the allocation system at the time of parking of a vehicle. It is a figure which shows an example of the allocation system at the time of stopping of a vehicle. It is a figure which shows an example of the allocation system at the time of traveling of a vehicle.

Hereinafter, exemplary embodiments of the present disclosure will be described with reference to the drawings. The present disclosure is not limited to the following embodiments, and can be implemented in various embodiments.
[Explanation of the configuration of the electronic control device]
The configuration of the electronic control device 1 of the embodiment will be described with reference to FIG. The electronic control device 1 is mounted on a vehicle such as an automobile, and performs information processing related to control of the equipment mounted on the vehicle and travel control such as out-of-vehicle communication and automatic driving. The electronic control device 1 is an information processing device mainly composed of a multi-core CPU 10, a semiconductor memory such as a RAM, ROM, and a flash memory (not shown), an input / output interface, and the like. Further, the electronic control device 1 includes a storage unit 20 and a vehicle state detection unit 30.

The electronic control device 1 is embodied by, for example, a microcontroller or the like in which functions as a computer system are integrated. The electronic control device 1 is realized by the multi-core CPU 10 executing a program stored in a substantial recording medium such as a ROM or a semiconductor memory.

The multi-core CPU 10 is an arithmetic unit in which a plurality of processor cores (hereinafter referred to as cores) are mounted in one package. As illustrated in FIG. 1, the multi-core CPU 10 has four cores 0 to 3 represented by reference numeral 11. Hereinafter, when these four cores 0 to 3 are described without distinction, they are referred to as core 11. When the four cores 0 to 3 are described separately, they are referred to as core 0, core 1, core 2, and core 3, respectively.

The multi-core CPU 10 is equipped with a hypervisor 12, a first system 13, a second system 14, and a third system 15 as components of functions realized by executing a program.

The hypervisor 12 is a control program that creates a plurality of virtual machines on the multi-core CPU 10 and operates them in parallel, and operates an OS on the created virtual machines. The hypervisor 12 executes scheduling for dynamically allocating cores used by each OS in order to enable a plurality of OSs to be executed in parallel on a plurality of cores. The procedure of the process executed by the hypervisor 12 will be described later.

The first to third systems represented by reference numerals 13, 14, and 15 include an OS running on a virtual machine formed by the hypervisor 12 and a plurality of tasks executed by an application program running on the OS. It is a program system. These first to third systems correspond to a plurality of program systems in the present disclosure. When the first to third systems are not particularly distinguished in the following description, they are simply referred to as a program system.

The first system 13 includes the OS 1 represented by the reference numeral 131, and m task 1_1, ... Task 1_m indicated by the reference numeral 132. The second system 14 includes the OS 2 represented by the reference numeral 141, and n tasks 2_1, ... Task 2_n indicated by the reference numeral 142. The third system 15 includes an OS 3 represented by reference numeral 151 and four tasks 3_1, task 3_2, task 3_3, and task 3_4 represented by reference numeral 142. When OS1 to 3 are not particularly distinguished in the following description, they are simply referred to as OS. When executing a plurality of tasks at the same time, the OS executes scheduling to allocate the resources of the core 11 allocated by the hypervisor 12 to the plurality of tasks so that they can operate independently of each other.

FIG. 2 shows an example of the functions that each program system is in charge of. As illustrated in FIG. 2, each task 132 of the first system 13 executes information processing related to navigation from the current location of the vehicle to the destination. Further, each task 142 related to the second system 14 executes information processing related to wireless communication for exchanging data with an external device. Further, each task 152 related to the third system 15 executes information processing related to automatic driving, which is a function of automatically performing a driving operation related to the running of the vehicle.

In the present embodiment, it is assumed that the maximum processing amount, which is the maximum value of the information processing execution amount by each task, is different for each vehicle state (for example, parking, stopping, running) in each program system. FIG. 3 shows an example of the maximum processing amount of each program system. In FIG. 3, parking refers to, for example, a state in which the vehicle is stopped with the engine stopped. Stopping refers to a state in which the vehicle is stopped with the engine running and can immediately resume running. Traveling refers to the state in which the vehicle is traveling.

As illustrated in FIG. 3, when the vehicle is parked, the maximum processing amount of the first system 13 is 200, the maximum processing amount of the second system 14 is 100, and the maximum processing amount of the third system 15 is 100. .. When the vehicle is stopped, the maximum processing amount of the first system 13 is 150, the maximum processing amount of the second system 14 is 50, and the maximum processing amount of the third system 15 is 200. Further, when the vehicle is in a traveling state, the maximum processing amount of the first system 13 is 50, the maximum processing amount of the second system 14 is 50, and the maximum processing amount of the third system 15 is 300.

In the case of FIG. 3, the maximum processing amount that can be processed by one core 11 is 100. That is, when the maximum processing amount exceeds 100 in one program system, it is necessary to allocate the processing load of the task of the program system to a plurality of cores 11. Further, a plurality of program systems can share the one or a plurality of cores 11 within a range not exceeding the maximum processing amount of the one or a plurality of cores 11.

Next, the operation requirements of the tasks in the first system 13, the second system 14, and the third system 15 will be described with reference to FIGS. 4 to 6.
(Regarding the first system) As illustrated in FIG. 4, it is stipulated that tasks 1-11 to task 1_m of the first system 13 can all be operated by SMP in each vehicle state of parking, stopping, and running. .. That is, the OS 1 of the first system 13 can dynamically allocate the core 11 to each task according to the processing load, or can share the core 11 with another OS by time division. Alternatively, sharing of the core 11 by a plurality of program systems may be performed based on the priority set in each program system.

Further, since the maximum processing amount of the first system 13 is 200 when the vehicle state is parked, the number of cores 11 required to satisfy the maximum processing amount is two. Further, since the maximum processing amount of the first system 13 is 150 when the vehicle state is stopped, the number of cores 11 required to satisfy the maximum processing amount is two. Further, since the maximum processing amount of the first system 13 is 50 when the vehicle state is traveling, the number of cores 11 required to satisfy the maximum processing amount is one.

(Regarding the second system) As illustrated in FIG. 5, it is stipulated that tasks 2-1 to task 2_n of the second system 14 can all be operated by SMP in each vehicle state of parking, stopping, and running. .. That is, the OS 2 of the second system 14 can dynamically allocate the core 11 to those tasks according to the processing load of each task, or can share the core 11 with another OS by time division. Alternatively, the sharing of the core 11 by a plurality of program systems may be performed based on the priority set in each program system. Further, since the maximum processing amount of the second system 14 is 100 or less regardless of whether the vehicle is parked, stopped, or running, the number of cores 11 required to satisfy the maximum processing amount is one. be.

(Regarding the third system) As illustrated in FIG. 6, it is stipulated that tasks 3_3 and task 3_4 of the third system 15 can all be operated by SMP in each vehicle state of parking, stopping, and running. .. That is, the OS 3 of the third system 15 can dynamically allocate the core 11 to the tasks according to the processing load of the tasks 3_3 and the task 3_4.

On the other hand, task 3_1 does not operate when the vehicle state is parked or stopped, and it is stipulated that the operation by AMP is essential when the vehicle state is running. Therefore, the OS 3 of the third system 15 fixedly allocates a specific core 11 to the task 3_1 when the vehicle state is traveling. Further, it is stipulated that task 3_2 does not operate when the vehicle state is parked, and that operation by AMP is essential when the vehicle state is stopped or running. Therefore, the OS 3 of the third system 15 fixedly allocates a specific core 11 to the task 3_2 when the vehicle state is stopped or running.

Further, since the maximum processing amount of the third system 15 is 100 when the vehicle state is parked, the number of cores 11 required to satisfy the maximum processing amount is one. Further, since the maximum processing amount of the third system 15 is 200 when the vehicle state is stopped, the number of cores 11 required to satisfy the maximum processing amount is two. Further, since the maximum processing amount of the third system 15 is 300 when the vehicle state is traveling, the number of cores 11 required to satisfy the maximum processing amount is three.

Returning to the explanation of the block diagram of FIG. Definition information that defines the allocation method of the core 11 for each program system is stored in the storage unit 20 in advance. This definition information includes information representing the requirements of the core 11 that the hypervisor 12 should allocate to each program system according to the vehicle condition. The hypervisor 12 executes scheduling for dynamically allocating the core 11 to each program system based on the definition information stored in the storage unit 20.

The definition information is designed to meet the operating requirements of each program system exemplified in FIGS. 4 to 6. Specifically, the core 11 to be assigned to each program system so as to satisfy the restrictions on the availability of SMP and AMP in the task and the requirement for the required number of cores based on the maximum processing amount for all program systems for each vehicle state. Requirements are stipulated.

FIG. 7 shows an example of definition information satisfying the operation requirements exemplified in FIGS. 4 to 6. The definition information table exemplified in FIG. 7 describes information indicating which program system the four cores 0 to 3 are assigned to for each of the parked, stopped, and running vehicle states. In the example of FIG. 7, when the vehicle state is parked, the first system 13 occupies the core 0 and the core 1, the second system 14 occupies the core 2, and the third system 15 occupies the core 3. , The allocation method is defined. Further, the allocation method is defined so that the first system 13 and the second system 14 share the core 0 and the core 1 and the third system 15 occupies the core 2 and the core 3 when the vehicle state is stopped. Has been done. Further, the allocation method is defined so that the first system 13 and the second system 14 share the core 0 and the third system 15 occupies the core 1, the core 2 and the core 3 when the vehicle state is running. Has been done.

Returning to the explanation of the block diagram of FIG. The vehicle state detection unit 30 acquires information indicating the operating status of the vehicle from sensors, control devices, and the like mounted on the vehicle, and detects the current state of the vehicle based on the acquired information. Specifically, the vehicle state detection unit 30 detects a state such as parking, stopping, or running as a vehicle state. As a modification, the vehicle state detection unit 30 may be configured to detect a vehicle state such as when the vehicle is started or when the vehicle is stationary.

[Explanation of hypervisor processing]
The procedure of the process executed by the hypervisor 12 will be described with reference to the flowchart of FIG. This hypervisor process relates to a core 11 allocation method for each program system.

In S100, the hypervisor 12 determines whether or not the vehicle state has changed. S10
The vehicle states to be determined at 0 are parking, stopping, and running. The hypervisor 12 makes an affirmative determination when the vehicle state is different from the previous detection result based on the detection result by the vehicle state detection unit 30. If the vehicle state has not changed (S100: NO), the hypervisor 12 repeats the processing of S100. On the other hand, when the vehicle state changes (S100: YES), the hypervisor 12 shifts the processing to S102.

In S102, the hypervisor 12 notifies the program system that is currently using the core 11 that cannot be used in the vehicle state after the change of the instruction to stop the use of the core 11. Specifically, the hypervisor 12 refers to the definition information of the storage unit 20, and is different from the allocation method corresponding to the vehicle state before the change and the allocation method corresponding to the vehicle state after the change. Identify a program system that is currently using the core 11 that cannot be used in the vehicle state.

In S104, the hypervisor 12 determines whether or not the notification to the effect that the scheduling switching has been completed has been received from the OS notified in S102. If the switching completion notification has not been received (S104: NO), the hypervisor 12 repeats the processing of S104. On the other hand, when the notification of the completion of switching is received (S104: YES), the hypervisor 12 shifts the processing to S106.

In S106, the hypervisor 12 refers to the definition information of the storage unit 20, and changes the scheduling for allocating the core 11 to the OS of each program system according to the allocation method corresponding to the changed vehicle state. In the next S108, the hypervisor 12 gives an instruction to the program system that has a core 11 that can be newly used in the changed vehicle state, to the program system that the core 11 can be used. Notice. Specifically, the hypervisor 12 refers to the definition information of the storage unit 20, and is different from the allocation method corresponding to the vehicle state before the change and the allocation method corresponding to the vehicle state after the change. Identify a programming system that has a core 11 that is newly available in the vehicle state.

In S110, the hypervisor 12 determines whether or not the notification to the effect that the scheduling switching has been completed has been received from the OS notified in S108. When the notification of the completion of switching has not been received (S110: NO), the hypervisor 12 repeats the process of S110. On the other hand, when the notification of the completion of switching is received (S110: YES), the hypervisor 12 returns the process to S100.

[Explanation of OS processing]
The procedure of the process executed by the OS of each program system will be described with reference to the flowchart of FIG. This OS process relates to a core 11 allocation method for tasks of each program system.

In S200, the OS determines whether or not the notification has been received from the hypervisor 12. This notification is a notification transmitted in S102 or S108 of the hypervisor processing described above (see FIG. 8). When the notification is not received from the hypervisor 12 (S200: NO), the OS repeats the process of S200. On the other hand, when the notification is received from the hypervisor 12 (S200: YES), the OS shifts the processing to S202.

In S202, the OS changes the scheduling for allocating the core 11 to the running task according to the notification received from the hypervisor 12. Specifically, when the hypervisor 12 receives a notification to stop using the specific core 11, the OS temporarily stops the process of the task assigned to the specific core 11 and relates to the process. Data is saved from the core 11. Other available cores 11 for stopped tasks
And restart the process. Further, when the hypervisor 12 receives a notification instructing the newly available core 11, the OS changes the scheduling for each task so that the running task can use the newly available core 11. .. In S204, the OS notifies the hypervisor 12 that the scheduling switching has been completed. After S204, the OS returns the process to S200.

[Specific example of allocation method]
A specific example of the core 11 allocation method for each vehicle state will be described with reference to FIGS. 10 to 12.

(At the time of parking) FIG. 10 shows an example of the allocation method of the core 11 when the vehicle state is parked. As illustrated in FIG. 10, when parked, the hypervisor 12 allocates core 0 and core 1 to the first system 13. The first system 13 occupies the assigned core 0 and core 1. The OS1 of the first system 13 allocates the resources of the core 0 and the core 1 to the tasks 1-11 to 1_m in operation according to the operation mode of the SMP.

Further, the hypervisor 12 allocates the core 2 to the second system 14. The second system 14 occupies the assigned core 2. The OS 2 of the second system 14 allocates the resources of the core 2 to the running tasks 2_1 to 2_n according to the operation mode of the SMP.

Further, the hypervisor 12 allocates the core 3 to the third system 15. The third system 15 occupies the assigned core 3. The OS 3 of the third system 15 allocates the resources of the core 3 to the running tasks 3_3 and 3_4 according to the operation mode of the SMP.

(At the time of stop) FIG. 11 shows an example of the allocation method of the core 11 when the vehicle state is stopped. As illustrated in FIG. 11, when stopped, the hypervisor 12 allocates core 0 and core 1 to the first system 13 and the second system 14. The first system 13 and the second system 14 share the assigned core 0 and core 1 in a time division manner. The OS1 of the first system 13 allocates the resources of the core 0 and the core 1 to the tasks 1-11 to 1_m in operation according to the operation mode of the SMP. Similarly, the OS 2 of the second system 14 allocates the resources of the core 0 and the core 1 to the tasks 2_1 to 2_n in operation according to the operation mode of the SMP.

Further, the hypervisor 12 allocates the core 2 and the core 3 to the third system 15. The third system 15 occupies the assigned cores 2 and 3. The OS 3 of the third system 15 allocates the resources of the core 2 to the task 3_2 in operation according to the operation mode of the AMP. Further, the OS 3 of the third system 15 allocates the resources of the core 3 to the running tasks 3_3 and 3_4 according to the operation mode of the SMP.

(During running) FIG. 12 shows an example of the allocation method of the core 11 when the vehicle state is running. As illustrated in FIG. 12, the hypervisor 12 allocates core 0 to the first system 13 and the second system 14 during traveling. The first system 13 and the second system 14 share the assigned core 0 in a time division manner. The OS1 of the first system 13 allocates the resource of the core 0 to the running tasks 1-11 to 1_m according to the operation mode of the SMP. Similarly, the OS 2 of the second system 14 allocates the resource of the core 0 to the running tasks 2_1 to 2_n according to the operation mode of the SMP.

Further, the hypervisor 12 allocates the core 1, the core 2, and the core 3 to the third system 15. The third system 15 occupies the assigned core 1, core 2, and core 3. The OS 3 of the third system 15 allocates the resource of the core 1 to the task 3_1 in operation according to the operation mode of the AMP. Further, the OS 3 of the third system 15 allocates the resource of the core 2 to the task 3_2 in operation according to the operation mode of the AMP. Further, the OS 3 of the third system 15 allocates the resources of the core 3 to the running tasks 3_3 and 3_4 according to the operation mode of the SMP.

[effect]
According to the electronic control device 1 of the embodiment, the following effects are obtained.
Tasks by each OS can be dynamically assigned to each core 11 in cooperation between OSs 1 to 3 according to the state of the vehicle on which the electronic control device 1 is mounted. By doing so, it becomes possible to effectively utilize the resources of the core 11 against the increase / decrease in the processing load that may change depending on the state of the vehicle.

For example, for tasks that require AMP, cores can be assigned as AMPs in any state, while core resources can be passed to other OSs in a system state where the processing load is low. Become. Further, for tasks capable of SMP, the resources of the core 11 can be effectively utilized by sharing the core 11 among a plurality of OSs.

In the hypervisor processing exemplified in FIG. 8, the hypervisor 12 stops the use of the core 11 that is currently in use for the core 11 that cannot be used in S102 before changing the scheduling in S106. Can be made to. By doing so, the notified OS can safely transfer the data of the task running on the core 11 from the core 11 before the core 11 becomes unusable due to the change of the schedule ring. can.

Further, in the hypervisor processing exemplified in FIG. 8, after changing the scheduling in S106, the hypervisor 12 notifies the OS having the core 11 newly available in S108 of the permission to use the core 11. can do. By doing so, it is possible to start using the core 11 after the notified OS can operate on the core 11.

[Correspondence with the configuration described in the claims]
The correspondence between each configuration of the embodiment and the configuration described in the claims is as follows.
The vehicle state detection unit 30 corresponds to a state acquisition unit. The hypervisor 12 corresponds to the first allocation unit. OS1 (131), OS2 (141), and OS3 (151) correspond to the second allocation unit.

[Modification example]
In the above-described embodiment, the case where the hypervisor 12 changes the scheduling of the allocation of the core 11 according to the vehicle state of parking, stopping, and running has been described. Not limited to the above-described embodiment, for example, the hypervisor 12 may be configured to change the scheduling of the allocation of the core 11 with respect to the vehicle state such as the start-up time and the steady state. In that case, in the definition information exemplified in FIG. 7, the item of the allocation method in the vehicle state at the time of starting or at the steady state is described. Further, in the hypervisor processing S100 exemplified in FIG. 8, the vehicle state at the time of starting or at the steady state is included in the determination target.

Further, in the above-described embodiment, the case where the electronic control device 1 is mounted on a vehicle such as an automobile has been described. Not limited to the above-described embodiment, the electronic control device according to the present disclosure may be applied to, for example, a vehicle such as an aircraft, a railroad, or a ship, or an electronic device other than a vehicle such as a mobile phone.

The function of one component in each of the above embodiments may be shared by a plurality of components, or the function of the plurality of components may be exerted by one component. Further, a part of the configuration of each of the above embodiments may be omitted. Further, at least a part of the configuration of each of the above embodiments may be added or substituted with respect to the configuration of the other embodiments. In addition, all aspects included in the technical idea specified from the wording described in the claims are embodiments of the present disclosure.

The present disclosure can also be realized in various forms such as a system having the above-mentioned electronic control device 1 as a constituent requirement, a program for operating a computer as the electronic control device 1, a substantive recording medium on which this program is recorded, and the like. ..

1 ... Electronic control device, 10 ... Multi-core CPU, 11 ... Core, 12 ... Hypervisor, 13 ... First system, 131 ... OS1, 132 ... Task, 14 ... Second system, 141 ... OS2, 143 ... Task, 15 ... Third system, 151 ... OS3, 152 ... Task, 20 ... Storage unit, 30 ... Vehicle state detection unit.

Claims (9)

A multi-core CPU (10) having a plurality of cores (11) is provided, and a plurality of program systems (13, 14, 15) including an operating system and an application program operating on the operating system operate on the multi-core CPU. An electronic control device (1) configured to perform
A state acquisition unit (30) configured to acquire the state of the system on which the electronic control device is mounted, and a state acquisition unit (30).
A storage unit configured to store definition information, which is information representing the core requirements to be assigned to each program system in order for each program system to execute a task, for each specific state that can be acquired by the state acquisition unit. (20) and
In order to enable the tasks of the plurality of program systems to be executed in parallel on the plurality of cores, a first allocation unit (12) configured to allocate the cores used by each program system to execute the tasks, and
In the operating system of each program system, a second allocation unit (131, 141, 1) configured to allocate one or more cores allocated by the first allocation unit to each one or a plurality of tasks executed by the program system. With 151)
The first allocation unit changes the core assigned to each program system according to the definition represented by the definition information stored in the storage unit according to the change in the state of the system acquired by the status acquisition unit. Is configured to
Electronic control device. Based on the definition information, the core used by a certain program system in the state before the change is used by the program system in the state after the change in response to the change in the state of the system acquired by the state acquisition unit. If it becomes unavailable,
First, in the operating system of the program system, the second allocation unit stops the assignment of tasks to the cores that cannot be used in the changed state.
After that, the first allocation unit is configured to allocate cores to each program system.
The electronic control device according to claim 1. In response to a change in the state of the system acquired by the state acquisition unit, based on the definition information, the program system uses a core that is not used in the state before the change by the program system in the state after the change. If available,
First, the first allocation unit allocates a core to each program system.
Subsequently, in the operating system of the program system where there is a newly available core, the second allocation unit is configured to allocate the core to a task.
The electronic control device according to claim 1 or 2. The definition information is a core allocation method so as to tolerate the processing load that may occur in each specific state in each program system and to satisfy the restrictions on the usage mode of the core in each specific state in each program system. Is stipulated,
The electronic control device according to any one of claims 1 to 3. When the first allocation unit allocates a core to a single program system, the single program system is configured to occupy the core.
The electronic control device according to any one of claims 1 to 4. When the first allocation unit allocates a core to a plurality of program systems, the plurality of program systems are configured to share the core.
The electronic control device according to any one of claims 1 to 5. The system on which the electronic control device is mounted is a vehicle.
The state acquisition unit is configured to acquire information representing the operating state of the vehicle.
The electronic control device according to any one of claims 1 to 6. The operating state of the vehicle acquired by the state acquisition unit includes at least one of a state at the time of starting, parking, stopping, and running.
The electronic control device according to claim 7. A multi-core CPU having a plurality of cores is executed on the multi-core CPU in an electronic control device configured to operate a plurality of program systems including an operating system and an application program running on the operating system. It ’s a multi-core allocation method.
Acquires the state of the system in which the electronic control device is mounted, and obtains the status.
In order to enable the tasks of the plurality of program systems to be executed in parallel on the plurality of cores, the cores used by each program system to execute the tasks are assigned.
For each specific state that can be acquired, each program system is assigned to each program system according to changes in the state of the system according to definition information that represents the core requirements that should be assigned to each program system in order to execute a task. Change the core,
In the operating system of each program system, one or more cores to be assigned are assigned to each of one or more tasks performed by the program system.
Multi-core allocation method.

Images