VEHICLE CONTROL DEVICE

Abstract

Vehicle control device for a vehicle, comprising: two processors (10, 20) for executing a program (31a, 31b) and with access to a first memory unit (32) for storing an execution history; a shared second memory unit (33, 41) which can be accessed jointly by the two processors (10, 20); wherein an exclusion control during the execution of the program (31a 31b) by the use of a semaphore or mutex ensures that the two processors (10, 20) which want to access common data in the common second memory unit (32) concurrently cannot access it at the same time; and wherein the first memory unit (32) stores an execution history according to each exclusion control, wherein the execution history contains data indicating which processor performed a semaphore acquisition operation or not, wherein Each processor is designed to perform the following actions during the execution of the program (31a 31b): to execute the semaphore acquisition process if the stored execution history indicates that the two processors performed the semaphore acquisition process; and Do not execute the semaphore acquisition process if the stored execution history indicates that the two processors did not execute the semaphore acquisition process.

Description

[0001] The present invention relates to a vehicle control device that is installed in a vehicle and includes several processors and a common storage unit for storing common data that can be accessed jointly by the several processors.

[0002] JP 2013-171 547 A discloses an example of the vehicle control devices described above.

[0003] JP 2013-171 547 A discloses a vehicle control device including multiple processors and a common memory unit that redundantly stores shared data, which can be accessed jointly by the multiple processors. To prevent accesses to the common memory unit from competing with each other, the vehicle control device 1 inputs a highest-priority interrupt signal to the processor that is not performing any data update processing.

[0004] However, since in JP 2013-171 547 A the interrupt is generated every time the shared data is updated, interruptions occur frequently when there is a large amount of shared data. Thus, a problem in JP 2013-171 547 A is that the interrupt for updating shared data delays other interrupts. Furthermore, in JP 2013-171 547 A, the processor load is also increased by the processing time required for, for example, instruction processing of the shared storage unit.

[0005] DE 10 2015 205 027 A1 discloses a data processing device comprising: data processing stages, each with a processing element, a stage memory, and an event controller; and an intermediate stage bus connecting the stages via an access point. External events and a process termination event are input into the controller to generate a task start event for the processing element, corresponding to the external events and the process termination event. Each access point has an access table that stores a data write history when the processing element writes data to memory in a memory access process. The processing element executes an event access process that indicates a memory access process termination after the processing element has terminated the memory access process to the memory via the access point.The access point executes a different event access process to input the process termination event into the control of another stage based on the data write history when the processing element executes the event access process.

[0006] In light of the foregoing, an object of the present invention is to provide a vehicle control device that reduces interruption delay and processor load. This object is achieved by a vehicle control device with the features of the respective independent claims. The dependent claims are directed to advantageous embodiments of the invention.

[0007] The vehicle control device according to the invention includes, among other things, the memory unit that stores the execution history, indicating which exclusion control was executed by which processor. Thus, the vehicle control device recognizes which processor executed each exclusion control. The exclusion control executed by multiple processors involves the possibility that the accesses of the multiple processors to the shared memory unit are likely to compete with each other. For this reason, the respective processors execute the exclusion controls that were executed by multiple processors. On the other hand, in the exclusion control that was not executed by multiple processors, the accesses of the multiple processors to the shared memory unit are unlikely to compete with each other.For this reason, the respective processors do not execute the exclusion controls that were performed by the multiple processors.

[0008] Therefore, if there is no possibility of the multiple processors' accesses to the shared memory unit competing with each other, the exclusion controls may be prevented from executing. This prevents the exclusion controls from being executed excessively. With the above configuration, the load on the processors can be reduced. Furthermore, the delay caused by interrupts affecting the exclusion controls can be reduced.

[0009] The foregoing and further tasks, features and advantages of the present disclosure will become more apparent from the following detailed description in conjunction with the drawings. Fig. Figure 1 is a block diagram illustrating a schematic configuration of a vehicle control device according to a first embodiment. Fig. Figure 2 is a flowchart at the time of execution of a platform program according to the first embodiment. Fig. Figure 3 is a flowchart illustrating semaphore acquisition processing according to the first embodiment. Fig. Figure 4 is a flowchart illustrating a spinlock processing operation according to the first embodiment; Fig. Figure 5 is a flowchart illustrating semaphore release processing according to the first embodiment. Fig. Figure 6 is a diagram illustrating execution histories according to the first embodiment. Fig. Figure 7 is a diagram illustrating a relationship between each common storage unit and a semaphore according to the first embodiment. Fig. Figure 8 is a diagram illustrating a relationship between each common storage unit and a semaphore according to modification 1. Fig. Figure 9 is a diagram illustrating a relationship between each common storage unit and a semaphore according to modification 2. Fig. Figure 10 is a block diagram illustrating a schematic configuration of a vehicle control device according to a second embodiment.

[0010] The following describes embodiments with reference to the drawings. (First embodiment)

[0011] The present embodiment is directed towards a vehicle control device 100, which is located in Fig. Figure 1 illustrates the vehicle control device 100, which is installed in a vehicle and can be applied, for example, to an internal combustion engine control unit, a hybrid control unit, etc. The present embodiment illustrates, by way of example, the vehicle control device 100 applied to an internal combustion engine control unit.

[0012] The vehicle control device 100 can acquire detection signals from multiple sensors and performs a calculation to execute an optimal fuel injection according to the state of an internal combustion engine using the acquired detection signals. Fig. Figure 2 shows a crank angle sensor 210 as an example of the sensors. The vehicle control unit 100 is connected to various actuators. In Fig. Figure 1 shows an injector 220 as an example of the actuators. The vehicle control unit 100 outputs a control signal, representing a calculation result, to control the actuator, such as the injector 220. In this way, the vehicle control unit 100 controls the internal combustion engine.

[0013] The vehicle control unit 100 includes a microcomputer. Specifically, the vehicle control unit 100 includes a first core 10, a second core 20, a first memory unit 31, a second memory unit 32, a first shared memory unit 33, an input / output circuit 40, and a second shared memory unit 41. The first shared memory unit 33 and the second shared memory unit 41 are jointly accessible by the first core 10 and the second core 20, respectively. In the following description, the first shared memory unit 33 and the second shared memory unit 41 can be referred to collectively as the shared memory unit.

[0014] The first core 10 contains a first CPU 11, a first register 12, and a first memory 13. The first memory 13 stores a core ID of the first core 10, which is referred to as the first core ID. The first core ID provides information that specifies that the core is the first core 10; that is, identification information. The ID is short for identification.

[0015] Like the first core 10, the second core 20 contains a second CPU 21, a second register 22, and a second memory 23. A second core ID is, or corresponds to, identification information that specifies that the core is the second core 20. The first core ID and the second core ID are unique and provided separately.

[0016] As described above, the present embodiment uses the first core 10 and the second core 20 as multiple processors. However, the present embodiment is not limited to the configuration described above, but can include three or more cores. CPU is an abbreviation for Central Processing Unit.

[0017] The first core 10 and the second core 20 execute an application program and a platform program, respectively, performing computations and outputting the control signal through the input / output circuit 40 while accessing shared data stored in the shared memory unit. Both the first core 10 and the second core 20 execute the application program and the platform program while accessing the second memory unit 32. When each of the first core and the second core 20 accesses the second memory unit 32, each can perform actions such as obtaining and releasing the semaphore, updating a core execution history, and so on. In this way, the vehicle control device 100 performs core exclusion control using the semaphore. This is one example of core exclusion control, but it is not exhaustive.An exclusion control, such as a mutex (mutual exclusion), can be implemented. The core exclusion control is equivalent to an exclusion control.

[0018] In the following description, if there is no need to distinguish between the first core 10 and the second core 20, they can simply be referred to as cores. Similarly, if there is no need to distinguish between the first core ID and the second core ID, they can also simply be referred to as core IDs.

[0019] The first memory unit 31 can, for example, use a ROM. Programs running in the first core 10 and the second core 20 are stored in the first memory unit 31. The programs are separated into the application program and the platform program. In other words, the application program and the platform program are stored in the first memory unit 31. The application program contains a program that calculates command values ​​for an internal combustion engine position and an injection quantity to inject fuel according to a vehicle condition, etc. The platform program contains a program to drive the input / output circuit 40 to inject the fuel with the target engine position and target injection quantity, for example, based on the command values ​​from the application program.

[0020] However, it is conceivable that, with regard to the programs stored in the first memory unit 31, for example, a supplier of vehicle control units develops the platform program and a vehicle manufacturer develops the application program. Typically, development items of the platform program are reused in several vehicle systems, but the application program may differ from vehicle system to vehicle system. For this reason, it is likely that the CPU allocation for executing the platform program will vary depending on the vehicle systems. In such a case, regardless of the type of CPU allocation to the platform program, there is a need to execute exclusion control (hereinafter referred to as core exclusion control) between the cores to avoid access concurrent access to the shared memory unit.

[0021] In particular, the platform program is configured to execute core exclusion control at all times when the shared memory unit is accessed. In other words, the platform program is configured to execute core exclusion control in accordance with all processing operations related to accessing the shared memory unit. It can be said that the platform program is fully equipped with core exclusion control. Furthermore, it can be said that the program includes multiple exclusion controls to suppress competing access attempts by the first core (10) and the second core (20) to the shared memory unit. However, the first core (10) and the second core (20) do not always access the shared memory unit at all times.

[0022] In a broader sense, it can be said that: the first memory unit 31 stores, as the programs to be executed by the first core 10 and the second core 20, a first program including the several core exclusion controls and a second program that differs from the first program.

[0023] The second memory unit 32 can, for example, use RAM. The semaphore and the core execution history are stored in the second memory unit 32. The second memory unit 32 is equivalent to one memory unit.

[0024] The semaphore is used for core exclusion control in a device including multiple cores and a shared memory unit, as is generally known. In particular, the semaphore is used in core exclusion control to prevent the accesses of the first core 10 and the second core 20 to the first shared memory unit 33 and the second shared memory unit 41 from competing with each other. Core exclusion control can be said to be a technology for ensuring that the time at which the first core 10 accesses the shared data and the time at which the second core 20 accesses the shared data do not coincide.

[0025] The semaphore has a release state (and an acquisition state). In particular, the semaphore specifies the kernel ID when it is acquired and while it is being released. For example, the second memory unit 32 contains information specifying a semaphore acquisition state or a semaphore release state, and further includes the kernel ID of the kernel acquiring the semaphore. Meanwhile, the information specifying the semaphore acquisition state or the semaphore release state, and the kernel ID of the kernel acquiring the semaphore, can be collectively referred to as the semaphore information. Thus, the semaphore stored in the second memory unit 32 corresponds to the semaphore information of the kernel acquiring the semaphore. Fig. 1 is described, semaphore information.

[0026] Additionally, the number of cores that acquire the semaphore is limited to one. For example, the core that acquires the semaphore is only one of the first core and one of the second core 20. In core exclusion control, the cores access the first shared memory unit 33 and the second shared memory unit 41 while referencing the semaphore, thus achieving exclusion between the cores. For example, the first core 10 accesses the first shared memory unit 33 with reference to the semaphore, while the second core 20 is forbidden from accessing the first shared memory unit 33 until the semaphore is released by the first core 10.

[0027] The number of semaphores can be one or more. Fig. Figure 7 illustrates a relationship between each common storage unit and the semaphore when a semaphore is provided. In other words, a semaphore X is shared by several common storage units. The present embodiment uses the vehicle control device 100, which has only the first common storage unit 33 and the second common storage unit 41, as the common storage units. However, in one illustration of the relationship between the common storage units and the semaphore, a third common storage unit is provided in addition to the first common storage unit 33 and the second common storage unit 41.

[0028] The core execution history is a space for storing the execution history of core exclusion controls during program execution; that is, the execution history of each processor that executed the core exclusion control. The core execution history can also be described as the history of semaphore acquisition processing execution. It can also be described as data indicating which core executed the semaphore acquisition process. Furthermore, the core execution history includes execution histories corresponding to the respective exclusion controls, indicating whether the core exclusion control was executed by the first core (10) and the second core (20).

[0029] As in Fig. Figure 6 illustrates that the core execution history includes execution histories for the corresponding first core 10 and second core 20, where 0 indicates that no execution history exists and 1 indicates that an execution history exists. In the example of Fig. The first core 10 has an execution history, while the second core 20 does not. The core execution history has a one-to-one relationship with the semaphore. In other words, as described above, if multiple semaphores are present, the core execution histories are provided according to the respective semaphores. The second storage unit 32 stores the multiple core execution histories.

[0030] If multiple semaphores exist, each of the multiple shared storage units must correspond to one semaphore. In other words, each of the multiple shared storage units has only one corresponding semaphore.

[0031] For example, illustrates Fig. 8. A relationship exists between each shared memory unit and the semaphore when two semaphores are provided. In this case, the first shared memory unit 33 corresponds only to semaphore X. The second shared memory unit 41 and the third shared memory unit correspond only to semaphore Y. Thus, when the first shared memory unit 33 is accessed, exclusion is performed by semaphore X. When the second shared memory unit 41 and the third shared memory unit are accessed, exclusion is performed by semaphore Y.

[0032] Fig. Figure 9 illustrates a relationship between each shared memory unit and the semaphore when three semaphores are provided. In this case, the first shared memory unit 33 corresponds only to semaphore X. The second shared memory unit corresponds only to semaphore Y. The third shared memory unit corresponds only to semaphore Z. Thus, when the first shared memory unit 33 is accessed, exclusion is performed by semaphore X. When the second shared memory unit 41 is accessed, exclusion is performed by semaphore Y. When the third shared memory unit is accessed, exclusion is performed by semaphore Z.

[0033] However, if the different semaphores X, Y, Z represent the corresponding storage units, as in Fig. As illustrated in Figure 9, it is difficult for the vehicle control device 100 to meet the limitation of memory unit resources. If a semaphore X is used for the multiple common memory units in the vehicle control device 100, as shown in Figure 9, the following applies: Fig. As illustrated in Figure 7, the probability of competition is high. Therefore, it is preferred that the vehicle control device 100, with its multiple common storage units and multiple semaphores, as shown in Figure 7, be configured with multiple storage units and multiple semaphores. Fig. Figure 8 illustrates that the vehicle control device 100 is equipped with such a device. In this case, the vehicle control device 100 can reduce the probability of competition while satisfying the resource constraint.

[0034] It is preferred that the execution history be stored in non-volatile memory. In other words, it is preferred that the second memory unit 32 be non-volatile memory. Thus, even if the vehicle ignition switch is off and the power supply to the vehicle control unit 10 is stopped, the vehicle control unit 100 retains the execution history.

[0035] Meanwhile, the first memory unit 31 and the second memory unit 32 can be managed with a series of addresses that represent a memory space. ROM is an abbreviation for "Read Only Memory." RAM is an abbreviation for "Random Access Memory."

[0036] The first shared memory unit 33 can, for example, use RAM. The first shared memory unit 33 is an area for storing data that needs to be updated and is accessed by the first core 10 and the second core 20. The first shared memory unit 33 contains shared data that is accessed by both the first core 10 and the second core 20.

[0037] The input / output circuit 40 is an interface for transmitting signals between the vehicle control unit 100 and sensors such as the crankshaft angle sensor 210, and between the vehicle control unit 100 and actuators such as the injector 220. The input / output circuit 40 includes the second common memory unit 41. The second common memory unit 41 can, for example, use a register. Since the second common memory unit 41 is essentially the same as the first common memory unit, its description is omitted.

[0038] As described above, the present embodiment uses the first common storage unit 33 and the second common storage unit 41 as the common storage units. However, this is not limiting. One common storage unit or more than two common storage units can be provided in other embodiments.

[0039] The following describes operations of the vehicle control device 100 with reference to Fig. 2 to Fig. 5 described. The first core 10 and the second core 20 in the vehicle control device 100 carry out the in Fig. 2 to Fig. 5 illustrated processing.

[0040] First, the operations at the time of execution of the platform program are considered with regard to Fig. 2 described. In particular, this example describes the operations when accessing the shared memory unit under core exclusion control.

[0041] In step S10, semaphore acquisition processing is performed. When core exclusion control is executed, that is, when accessing the shared memory unit, each of the first core 10 and the second core 20 performs semaphore acquisition processing. Only one of the first core 10 and the second core 20 that is executing core exclusion control performs the semaphore acquisition processing. For example, when accessing the first shared memory unit 33, the first core 10 performs the semaphore acquisition processing. Specifically, the first core 10 is the first to invoke the semaphore acquisition processing and locks access to the first shared memory unit 33. In this case, since the second core 20 cannot acquire the semaphore, the second core 20 cannot access the first shared memory unit 33.

[0042] In step S12, the shared memory unit is accessed. One of the first core 10 and one of the second core 20, which acquired the semaphore in step S10, accesses the shared memory unit. For example, if the first core 10 acquired the semaphore, it accesses the first shared memory unit 33 and updates or references the data stored there. In this situation, since the second core 20 cannot acquire the semaphore, it cannot access the first shared memory unit 33. In step S14, semaphore release processing is performed. Either the first core 10 or the second core 20 can perform the semaphore release processing. Specifically, one of the first core 10 and one of the second core 20, which acquired the semaphore in step S10, releases the acquired semaphore.For example, when the first core 10 acquires the semaphore, it releases the semaphore after updating or referencing the data stored in the first shared memory unit 33. When the first core 10 releases the semaphore, the second core 20 is enabled to acquire it. Semaphore release processing can only be performed by the core that acquired the semaphore. Thus, if the first core 10 acquires the semaphore, semaphore release processing can only be performed by the first core.

[0043] The following describes an example of concurrent access to the shared memory unit by the first core 10 and the second core 20.

[0044] A first example is as follows. The first shared memory unit 33 is a RAM. The first core 10 measures time by incrementing a counter. The first core 10 accesses the first shared memory unit 33 and increments a counter value stored in the first shared memory unit 33 to measure the time. Based on the fulfillment of a certain condition, the second core 20 clears the counter and deletes the measurement time. Specifically, based on the fulfillment of a certain condition, the second core 20 accesses the first shared memory unit 33 and deletes the counter value stored in the first shared memory unit 33 to delete the measurement time.

[0045] In this example, when competition occurs, the counter is cleared by the second core 20 while the counter is incremented by the first core 10. In other words, the counter value of the first shared memory unit 33 is cleared by the second core 20 while the counter value is incremented by the first core 10. Consequently, the first core 10 incorrectly continues to measure time by incrementing the counter value without taking into account the clearing of the counter value by the second core 20. For this reason, when operating the counter, the first core 10 and the second core 20 execute core exclusion control to access the first shared memory unit 33.

[0046] Here is another example. The second shared memory unit 41 is a register. The first core 10 and the second core 20 set the output levels of multiple ports using values ​​from the second shared memory unit 41. Specifically, the first core 10 and the second core 20 can each independently operate the same second shared memory unit 41 to set the output levels of the multiple ports. When changing the output level of a particular port, each of the first core 10 and the second core 20 must read the current output setting state to change only one bit of the destination port, and then write data to the output levels of the multiple ports, changing only the bit of the destination port, so as not to change the output level of any other port.In this example, if accesses compete with each other, the first core 10 and the second core 20 can change the output levels of different ports in the second shared memory unit 41. If writes by the first core 10 and writes by the second core 20 interfere with each other, the output level updated by the respective core cannot be reflected. For this reason, when operating the second shared memory unit 41, each of the first core 10 and the second core 20 executes core exclusion control to access the second shared memory unit 41.

[0047] Next, semaphore acquisition processing will be discussed with reference to Fig. 3 described. The following applies, even if the description refers to the operations of the first kernel 10, the same applies to the operations of the second kernel 20.

[0048] In step S20, the core ID of the core performing the semaphore acquisition process is obtained. The first core (10) and the second core (20) can both obtain the core ID of the core performing the semaphore acquisition process. For example, if the first core (10) is performing the semaphore acquisition process, the first CPU (11) obtains the first core ID from the first memory (13).

[0049] In step S22, the execution history of the semaphore acquisition processing is updated. Each of the first core (10) and the second core (20) can access the results in Fig. Update the illustrated core execution history. For example, if the first core 10 performed semaphore acquisition processing in the flowchart of Fig. If the first core 10 has executed the execution history of the first core 10, it sets the execution history of the first core 10 to 1. In other words, if the core, which could be the first core 10 or the second core 20, performs the semaphore acquisition processing, the core sets a corresponding value in the core execution histories as a value indicating the presence of the execution history.

[0050] In particular, the program stored in the first storage unit 31 includes a procedure (step S20) to obtain the kernel ID of the kernel that performed the semaphore acquisition processing, and a procedure (step S22) to update the execution history according to the obtained kernel ID.

[0051] As described above, when the core (corresponding to an update unit), which can be any of the first core and the second core 20, has executed the core exclusion control, the core stores execution history information in the second memory unit 32, which links the executed core exclusion control to the core ID assigned to that core, thereby performing an execution history update (update unit). In other words, the update unit updates the core execution history according to which processor (any of the first core 10 and the second core 20) has executed the core exclusion control.

[0052] It may suffice for the vehicle control unit 100 to be able to update the core execution history of each core that performed the semaphore acquisition processing. Thus, step S20 can be skipped. In particular, the program stored in the first memory unit 31 does not need to include the procedure for obtaining the core ID to update the core execution history, but can include a procedure for updating the core execution history according to the core that performed the semaphore acquisition processing.

[0053] Step S24 determines whether the execution histories are available in the multiple cores. In other words, it determines whether there is a value indicating that the execution histories are present in the core execution history for both the first core (10) and the second core (20). If it is determined that the execution histories are available in both cores, the controller proceeds to step S26. If it is determined that the execution histories are not available in both cores, the processing of Fig. 3 completed. Although described later, each of the first core 10 and the second core 20 performs spinlock processing at step S26.

[0054] For example, if the value corresponding to the first core is 10 and the value corresponding to the second core is 20 and 1 in the core execution history, the first core determines that execution histories exist in the multiple cores, that is, it determines that spinlock processing is necessary, and the controller proceeds to step S26. If the value corresponding to the first core is 10 and the value corresponding to the second core is 0 in the execution history, the first core determines that execution histories do not exist in the multiple cores, determines that spinlock processing is not necessary, and completes the processing of Fig. 3. In other words, if at least one of the values ​​corresponding to the first core (10) and the value corresponding to the second core (20) in the core execution history is 0, the first core (10) and the second core (20) determine that the execution histories are not available in the multiple cores and complete the processing of Fig. 3.

[0055] Spinlock processing is implemented in step S26. Spinlock processing is described with reference to the flowchart of Fig. As described in section 4, the semaphore is acquired at step S30. Specifically, if the first core 10 and the second core 20 determine that the execution histories exist in multiple cores, the first core 10 and the second core 20 attempt to acquire the semaphore. For example, if the determination in the first core 10 at step S24 is YES, the first core 10 attempts to acquire the semaphore. For example, to prevent access to the first shared memory unit 33 from competing with that of the second core 20, the first core 10 attempts to acquire the semaphore. In this situation, when the semaphore is released, the first core 10 accesses the second memory unit 32, overwrites the semaphore release state to the semaphore acquisition state, and rewrites the core ID of the core acquiring the semaphore to the core ID of the first core 10. On the other hand, if the first nucleus 10 acquires the semaphore, the first nucleus 10 continues in this state.In other words, the semaphore acquisition state is maintained in the second memory unit 32, and the core ID of the core that acquires the semaphore is retained without rewriting. Furthermore, rewriting the semaphore release state to the semaphore acquisition state means that the semaphore information is rewritten from content indicating the semaphore release state to content indicating the semaphore acquisition state.

[0056] Step S32 determines whether the semaphore acquisition is successful. For example, after attempts to acquire the semaphore, the first core 10 acknowledges the memory contents in the second memory unit 32 and determines whether the semaphore acquisition is successful based on whether the core ID of the core acquiring the semaphore matches the core ID of the first core 10. If the first core 10 determines that the core ID matches that of the first core 32, it determines that the semaphore acquisition is successful, and the controller completes the processing. Fig. 4. If the first core 10 determines that the core ID does not match that of the first core 10, it determines that semaphore acquisition is unsuccessful, and control returns to step S30. The first core 10 repeats steps S30 and S32 until the core ID matches that of the first core 10. In other words, the core performing spinlock processing determines that semaphore acquisition is successful if it determines that the semaphore will not be acquired by the other core, and determines that semaphore acquisition is unsuccessful if it determines that the semaphore will be acquired by the other core. In this example, semaphore acquisition is performed automatically until the semaphore state is confirmed and the semaphore is rewritten, so that the other core's processing cannot be interrupted during a processing sequence.

[0057] As described above, if the determination at step S24 is YES, the first core 10 and the second core 20 execute the core exclusion control that was executed by both the first core 10 and the second core from the multiple exclusion controls. However, if the determination at step S24 is NO, the first core 10 and the second core 20 do not execute the core exclusion control that was executed by both the first core 10 and the second core from the stored multiple exclusion controls.

[0058] Next, the operations of a semaphore share processing system with regard to Fig. 5 described.

[0059] Step S40 determines whether the execution histories are available in the multiple cores. In other words, it determines whether there are values ​​indicating that the execution histories for both the first core (10) and the second core (20) are present in the core execution history updated in step S22. If it is determined that the execution histories are available in both cores, the controller proceeds to step S42. If it is determined that the execution histories are not available in both cores, processing is halted. Fig. Step 4 is completed. For example, if the value corresponding to the first core (10) is 1 and the value corresponding to the second core (20) is 1 in the core execution history, the first core determines that the execution histories are available in the multiple cores, and the controller proceeds to step S42. In step S42, the semaphore is released. For example, the first core (10) accesses the second memory unit (32) and overwrites the semaphore acquisition state to the semaphore release state. In other words, the first core (10) overwrites the semaphore information from a state indicating the semaphore acquisition state to a state indicating the semaphore release state. In this way, the core that acquired the semaphore overwrites the memory contents of the second memory unit (32) to the state indicating the semaphore release state in order to release the semaphore.

[0060] As described above, the vehicle control unit 100 includes the second memory unit 32 for storing the execution histories, which indicate whether the respective core exclusion controls were executed by the first core 10 and the second core 20. Thus, the vehicle control unit 100 is configured to detect which core executed which of the respective core exclusion controls. In the core exclusion control executed by the first core 10 and the second core 20, accesses to the shared memory unit by the first core 10 and the second core 20 are likely to compete with each other. For this reason, the first core 10 and the second core 20 execute the core exclusion control that was executed by both of them from among the multiple stored core exclusion controls.On the other hand, in the core exclusion control not executed by the first core 10 and the second core 20, there can be no possibility of the accesses of the first core 10 and the second core 20 to the shared memory unit competing with each other. For this reason, the first core 10 and the second core 20 execute the core exclusion control not executed by both the first core 10 and the second core 20 from among the stored multiple exclusion controls.

[0061] Thus, if there is no possibility that the accesses of the first core 10 and the second core 20 to the shared memory unit will compete with each other, the vehicle control device 100 can prevent the core exclusion controls from being executed. Therefore, the vehicle control device 100 can prevent the core exclusion controls from being executed excessively. With the above configuration, the vehicle control device 100 is expected to reduce core load. For this reason, the vehicle control device 100 simply satisfies the core load resource constraint. As described above, the vehicle control device 100 can use an internal combustion engine control device as an example. Typically, the internal combustion engine control device performs control with serious real-time requirements.In this respect, since the vehicle control device 100 can prevent the core exclusion control from being executed excessively often, even when real-time requirements are critical and the interrupt to execute the core exclusion control is performed, the delay due to the interrupt can be reduced.

[0062] As described above, the platform program is configured so that the core exclusion control is executed in conjunction with all processing operations for accessing the shared memory unit. However, the vehicle control unit 100 does not execute the core exclusion control that has not been executed by both the first core 10 and the second core 20 among the stored multiple core exclusion controls. Therefore, even in the platform program configured to execute the core exclusion control completely, if there is no possibility of conflicting accesses to the shared memory unit by the first core 10 and the second core 20, the vehicle control unit 100 may prevent the core exclusion control from being executed.

[0063] The design can be modified in different ways. (Second embodiment)

[0064] Since a vehicle control device 100a according to a second embodiment is similar in many respects to the vehicle control device 100 according to the first embodiments, mainly differences from the vehicle control device 100 are described. As in Fig. As illustrated in Figure 10, the vehicle control device 100a differs from the vehicle control device 100 in that the second storage unit 32 is replaced by an exclusion controller 32a. Furthermore, the vehicle control device 100a differs from the vehicle control device 100 in the processing contents of a first core 10 and a second core 20.

[0065] The exclusion control unit 32a contains semaphore information and a core execution history. Exclusion control 32a is equivalent to a storage unit. Exclusion control 32a manages the core execution history instead of the first core 10 and the second core 20. In other words, if the first core 10... Fig. To execute the illustrated semaphore acquisition processing 3, exclusion control 32a updates the core execution history in step S22.

[0066] In this way, the exclusion control unit 32a determines the core that executed the core exclusion control. The exclusion control unit 32a stores information that links the executed core exclusion control to the core ID of the core that executed it, as the execution history. For example, if the first core 10 executed a specific core exclusion control, the exclusion control unit 32a stores the information linking that specific core exclusion control to the first core ID as the execution history.

[0067] Additionally, the exclusion control unit 32a can rewrite the semaphore information instead of the first core 10 and the second core 20. In this case, if the first core 10 performs the spinlock processing in Fig. When step 4 is executed, the exclusion control unit 32a rewrites the semaphore release state to the semaphore acquisition state and rewrites the core ID of the core acquiring the semaphore to the core ID of the first core 10. However, as above, if the semaphore is acquired at step S30, the exclusion control unit 32a does not rewrite the semaphore information. When the first core 10 performs the semaphore release processing of Fig. When step 5 is executed, the exclusion control unit 32a rewrites the semaphore acquisition state to the semaphore release state.

[0068] The vehicle control device 100a can achieve the same advantages as the vehicle control device 100.

Claims

[1] Vehicle control device for a vehicle, comprising: two processors (10, 20) for executing a program (31a, 31b) and having access to a first memory unit (32) for storing an execution history; a common second memory unit (33, 41) which can be accessed jointly by the two processors (10, 20); wherein an exclusion control during the execution of the program (31a 31b) by the use of a semaphore or mutex ensures that the two processors (10, 20) which concurrently want to access common data in the common second memory unit (32) cannot access it at the same time; and wherein the first storage unit (32) stores an execution history corresponding to each exclusion control, the execution history including data indicating which processor has or has not executed a semaphore acquisition processing, wherein each processor, when executing the program (31a 31b), is designed to: execute the semaphore acquisition processing if the stored execution history indicates that the two processors have executed the semaphore acquisition processing; and not to execute the semaphore acquisition processing if the stored execution history indicates that the two processors have not executed the semaphore acquisition processing. [2] A vehicle control device according to claim 1, wherein the two processors (10, 20) manage the execution history. [3] The vehicle control device according to claim 1, wherein an exclusion control unit (32a) has the storage unit for storing the execution history and manages the execution history. [4] A vehicle control device according to any one of the preceding claims, wherein the program is separated into an application program and a platform program. [5] A vehicle control device according to any preceding claim, wherein the execution history is stored in a non-volatile memory of the storage unit.

Images