JP2021018475A - Electronic control apparatus - Google Patents

Abstract

To suppress increase of overhead resulting from exclusive control between processor cores.SOLUTION: An ECU 1 has processor cores 11, 12, 13, a RAM 21, and an MPU 15. The RAM 21 stores update data 31 to which each of the processor cores 11, 12, 13 can access for reading. The MPU 15 controls the processor cores 11, 12, 13 so that when the processor core 11 accesses to the update data 31, the processor cores 12, 13 should not access to the update data 31.SELECTED DRAWING: Figure 1

Description

The present disclosure relates to an electronic control device including a plurality of processor cores.

Patent Document 1 includes a first core, a second core, and a shared memory, and uses a hardware function such as DMA to directly copy the data of the second core to the shared memory, and the first core is transferred to the shared memory. An in-vehicle control device configured to access and acquire data is described. DMA is an abbreviation for Direct Memory Access.

Republished Patent No. 2017/056725

Exclusive control between processor cores is generally performed using a semaphore. However, when using a semaphore, the processor core on the accessing side must always use the interface for acquiring the semaphore and the interface for releasing the semaphore, which increases the overhead.

An object of the present disclosure is to suppress an increase in overhead due to exclusive control between processor cores.

One aspect of the present disclosure is an electronic control device (1) including a plurality of processor cores (11, 12, 13), a shared data storage unit (21, 14), and a memory protection unit (15).
The shared data storage unit is configured to store shared data (31, 71) that can be readably accessed by each of the plurality of processor cores.

The memory protection unit controls a plurality of processor cores so that when the specific processor core (11) is accessing the shared data, the other processor cores (12, 13) cannot access the shared data. It is composed. The specific processor core is one of a plurality of processor cores. The other processor core is a processor core other than the specific processor core.

In the electronic control device of the present disclosure configured in this way, the memory protection unit has a plurality of processors so that when a specific processor core is accessing the shared data, other processor cores cannot access the shared data. Control the core. That is, since the electronic control device of the present disclosure uses a memory protection unit instead of the semaphore, a special interface is not required on the accessing processor core side. Thereby, the electronic control device of the present disclosure can suppress an increase in overhead due to exclusive control between processor cores.

It is a block diagram which shows the structure of the ECU of 1st and 2nd Embodiment. It is a figure which shows the structure of the test block ID table. It is a flowchart which shows the initial setting process. It is a flowchart which shows a RAM test process. It is a flowchart which shows the access error processing. It is a sequence diagram which shows 1st specific example of access arbitration by MPU of 1st Embodiment. It is a sequence diagram which shows the 2nd specific example of the access arbitration by MPU of 1st Embodiment. It is a figure explaining exclusive control by a semaphore. It is a figure explaining exclusive control by the microcomputer of 1st Embodiment. It is a figure which shows the structure of a priority table. It is a flowchart which shows the 1st processor processing. It is a flowchart which shows the data reading process. It is a sequence diagram which shows the specific example of access arbitration by MPU of the 2nd Embodiment. It is a block diagram which shows the structure of the ECU of 3rd and 4th Embodiment. It is a sequence diagram which shows 1st specific example of execution access arbitration by MPU of 3rd Embodiment. It is a sequence diagram which shows the 2nd specific example of execution access arbitration by MPU of 3rd Embodiment. It is a sequence diagram which shows the specific example of execution access arbitration by MPU of 4th Embodiment.

[First Embodiment]
The first embodiment of the present disclosure will be described below together with the drawings.
As shown in FIG. 1, the electronic control device 1 (hereinafter, ECU 1) of the present embodiment includes a microcomputer 2 (hereinafter, microcomputer 2). ECU is an abbreviation for Electronic Control Unit.

The microcomputer 2 includes processor cores 11, 12, and 13, a ROM 14, a memory protection device 15 (hereinafter, MPU 15), a system bus 16, and RAMs 21, 22, and 23. MPU is an abbreviation for Memory Protection Unit.

Various functions of the microcomputer 2 are realized by the processor cores 11, 12, and 13 executing a program stored in a non-transitional substantive recording medium. In this example, ROM 14 corresponds to a non-transitional substantive recording medium in which a program is stored. In addition, by executing this program, the method corresponding to the program is executed. Note that some or all of the functions executed by the processor cores 11, 12, and 13 may be configured in hardware by one or a plurality of ICs or the like. Further, the number of microcomputers constituting the ECU 1 may be one or a plurality.

The processor cores 11, 12, and 13 include arithmetic units, registers, and the like for executing a program. The processor cores 11, 12, and 13 distribute and execute various control processes for controlling an engine (not shown).

The ROM 14 is a non-volatile memory in which data cannot be rewritten. The ROM 14 stores programs and the like executed by the processor cores 11, 12, and 13.
The MPU 15 controls writing and reading of data to the RAMs 21, 22, and 23.

The system bus 16 connects the processor cores 11, 12, 13, the ROM 14, the MPU 15, and the RAMs 21, 22, and 23 to each other so that data can be input and output.
The RAMs 21, 22, and 23 are volatile memories. The RAMs 21, 22, and 23 temporarily store the calculation results of the processor cores 11, 12, and 13, respectively.

The RAM 21 stores the update data 31 and the handshake data 41 and 51. The update data 31 is data that the processor core 11 exclusively updates. The handshake data 41 is data used when the processor core 12 accesses the update data 31. The handshake data 51 is data used when the processor core 13 accesses the update data 31.

The RAM 22 stores the update data 32 and the handshake data 42 and 52. The update data 32 is data that the processor core 12 exclusively updates. The handshake data 42 is data used when the processor core 11 accesses the update data 32. The handshake data 52 is data used when the processor core 13 accesses the update data 32.

The RAM 23 stores the update data 33 and the handshake data 43 and 53. The update data 33 is data that the processor core 13 exclusively updates. The handshake data 43 is data used when the processor core 11 accesses the update data 33. The handshake data 53 is data used when the processor core 12 accesses the update data 33.

The MPU 15 controls the processor cores 11, 12, and 13 so that only the processor core 11 can update the update data 31 of the RAM 21. Similarly, the MPU 15 controls the processor cores 11, 12, and 13 so that only the processor core 12 can update the update data 32 of the RAM 22. Further, the MPU 15 controls the processor cores 11, 12, and 13 so that only the processor core 13 can update the update data 33 of the RAM 23.

Further, the MPU 15 determines whether to allow or prohibit read access when the read access request to the RAMs 21, 22, and 23 is input from the processor cores 11, 12, and 13. Then, the MPU 15 outputs a read access permission notification when the read access is permitted, and a read access prohibition notification when the read access is prohibited, to the access request source.

Then, the processor cores 11, 12, and 13 determine whether or not to execute the read access based on the read access permission notification or the read access prohibition notification input from the MPU 15.

The ROM 14 also stores the test block ID table TB1. The test block ID table TB1 is referenced by the processor core 11 when the processor core 11 performs a RAM test on the RAM 21. As shown in FIG. 2, the test block ID table TB1 is a table that stores an ID number for identifying a plurality of test blocks and an address range of the test block corresponding to the ID number. In the test block ID table TB1 shown in FIG. 2, "1", "2", "3", "4", and "5" described in the left column of the table are ID numbers.

Next, the procedure of the initial setting process executed by the processor core 11 will be described. The initial setting process is a process started immediately after the processor core 11 is started.
When the initial setting process is executed, as shown in FIG. 3, the processor core 11 stores 1 in the block instruction value TestBlock provided in the RAM 21 in S10, and ends the initial setting process.

Next, the procedure of the RAM test process executed by the processor core 11 will be described. The RAM test process is a process that is started every time a preset execution cycle elapses. In the present embodiment, the execution cycle of the RAM test process is set to, for example, 10 ms.

When the RAM test process is executed, the processor core 11 first sets read prohibition for the processor cores 12 and 13 in S110 as shown in FIG. Specifically, the processor core 11 outputs a prohibition setting request for prohibiting read access from the processor cores 12 and 13 to the update data 31 of the RAM 21 to the MPU 15. When this prohibition setting request is input to the MPU 15, the MPU 15 prohibits read access from the processor cores 12 and 13 to the update data 31 of the RAM 21 to the memory protection setting register provided in the MPU 15 (hereinafter, read access). Prohibition) is set.

Next, in S120, the processor core 11 refers to the test block ID table TB1 stored in the ROM 14, and refers to the address range of the test block corresponding to the ID number corresponding to the value stored in the block instruction value TestBlock. To get.

Then, the processor core 11 executes a RAM test on the RAM 21 in S130 with respect to the address range acquired in S120. In the RAM test, the processor core 11 writes the inverted data obtained by inverting the value of the data read from the RAM 21 to the RAM 21, then reads the written written data, and whether the read inverted data matches the written data. The failure of the RAM 21 is diagnosed by determining whether or not it is. Then, the processor core 11 writes the original value to the RAM 21 after performing the diagnosis.

Next, in S140, the processor core 11 stores the added value obtained by adding 1 to the value stored in the block indicated value TestBlock in the block indicated value TestBlock.
Then, the processor core 11 determines in S150 whether or not "with read request" is set in the handshake data 41 and 51. Here, when "no read request" is set for the handshake data 41 and 51, the processor core 11 is a table in which the value stored in the block instruction value TestBlock is preset in S160. Determine if the number of blocks is larger than MaxBlock. In the present embodiment, the number of table blocks MaxBlock is set to 5.

Here, when the value stored in the block instruction value TestBlock is less than or equal to the number of table blocks MaxBlock, the processor core 11 shifts to S120. On the other hand, when the value stored in the block indicated value TestBlock is larger than the number of table blocks MaxBlock, the processor core 11 stores 1 in the block indicated value TestBlock in S170 and shifts to S180.

Further, in S150, when "Read request" is set for at least one of the handshake data 41 and 51, the processor core 11 shifts to S180.
Then, upon shifting to S180, the processor core 11 sets read permission for the processor cores 12 and 13. Specifically, the processor core 11 outputs a permission setting request for permitting read access from the processor cores 12 and 13 to the update data 31 of the RAM 21 to the MPU 15. When this permission setting request is input to the MPU 15, the MPU 15 permits the memory protection setting register provided in the MPU 15 to read access from the processor cores 12 and 13 to the update data 31 of the RAM 21 (hereinafter, read access). Allow) is set.

Further, the processor core 11 sets “no read request” for the handshake data 41 and 51 in S190, and ends the RAM test process.
Next, the procedure of access error processing executed by the processor core 12 will be described. The access error processing is a processing started when a read access prohibition notification is input from the MPU 15.

When the access error processing is executed, the processor core 12 first sets "read request" in the handshake data 41 in S310 as shown in FIG.
Then, the processor core 12 determines in S320 whether or not "read request" is set in the handshake data 41. Here, when "with read request" is set, the processor core 12 waits until "without read request" is set in the handshake data 41 by repeating the process of S320.

Then, when "no read request" is set in the handshake data 41, the processor core 12 performs the process in which the error occurred (that is, the process that caused the input read access prohibition notification) in S330. Go back and finish the access error processing.

Since the access error processing executed by the processor core 13 is the same as the access error processing executed by the processor core 12 except that the handshake data 41 is changed to the handshake data 51, detailed description thereof will be omitted.

The processor cores 12 and 13 also execute the initial setting process and the RAM test process.
The point that the initial setting process and the RAM test process of the processor core 12 targets the update data 32 of the RAM 22 and the handshake data 42 and 52 instead of the update data 31 and the handshake data 41 and 51 of the RAM 21 is the processor core 11. It is different from the initial setting process and RAM test process.

Similarly, the initial setting process and the RAM test process of the processor core 13 target the update data 33 of the RAM 23 and the handshake data 43 and 53 instead of the update data 31 and the handshake data 41 and 51 of the RAM 21. It is different from the initial setting process and RAM test process of the core 11.

The processor cores 11 and 13 execute the access error processing targeting the RAM 22 in the same manner as the processor cores 12 and 13 execute the access error processing targeting the RAM 21. Similarly, the processor cores 11 and 12 execute access error processing for the RAM 23.

Next, a first specific example of access arbitration by MPU 15 will be described.
As shown in FIG. 6, the processor core 11 first sets read access prohibition prohibiting read access from the processor cores 12 and 13 to the update data 31. The arrow L1 indicates that the processor core 11 outputs a prohibition setting request to the MPU 15.

Next, the processor core 11 updates the update data 31 as shown by the arrow L2. Then, as shown by the arrow L3, the processor core 11 sets the read access permission for permitting the read access from the processor cores 12 and 13 to the update data 31. The arrow L3 indicates that the processor core 11 outputs a permission setting request to the MPU 15.

After that, the processor core 12 outputs a read access request to the update data 31 to the MPU 15. The arrow L4 indicates that the processor core 12 is requesting read access to the update data 31.

Here, since the read access permission is set in the MPU 15, the MPU 15 outputs the read access permission notification to the processor core 12.
When the processor core 12 obtains the read access permission notification from the MPU 15, it accesses the update data 31 and reads the data from the update data 31. The arrow L5 indicates that the processor core 12 reads data from the update data 31.

Further, the processor core 13 outputs a read access request to the update data 31 to the MPU 15. The arrow L6 indicates that the processor core 13 is requesting read access to the update data 31.

Here, since the read access permission is set in the MPU 15, the MPU 15 outputs the read access permission notification to the processor core 13.
When the processor core 13 obtains the read access permission notification from the MPU 15, it accesses the update data 31 and reads the data from the update data 31. The arrow L7 indicates that the processor core 13 reads data from the update data 31.

Next, a second specific example of access arbitration by MPU 15 will be described.
As shown in FIG. 7, the processor core 11 first sets read access prohibition prohibiting read access from the processor cores 12 and 13 to the update data 31. The arrow L11 indicates that the processor core 11 outputs a prohibition setting request to the MPU 15.

Then, the processor core 11 starts executing the RAM test process. The rectangle SQ1 indicates that the processor core 11 is executing the RAM test process.
After the RAM test process is started, the processor core 12 outputs a read access request to the update data 31 to the MPU 15. The arrow L12 indicates that the processor core 12 is requesting read access to the update data 31.

Here, since the read access prohibition is set in the MPU 15, the MPU 15 outputs the read access prohibition notification to the processor core 12 as shown by the arrow L13.
When the processor core 12 obtains the read access prohibition notification from the MPU 15, the processor core 12 starts executing the access error processing, and first sets "read request" in the handshake data 41 as shown by the arrow L14.

After that, the processor core 12 confirms the handshake data 41 and waits until "no read request" is set in the handshake data 41, as shown by the rectangle SQ2 and the arrow L15.

On the other hand, the processor core 11 executes a RAM test on the update data 31 as shown by the arrow L16. Further, the processor core 11 determines whether or not “with read request” is set in the handshake data 41 and 51 as indicated by the arrow L17.

Here, since "read request" is set in the handshake data 41, the processor core 11 sets a read access permission for permitting read access from the processor cores 12 and 13 to the update data 31. The arrow L18 indicates that the processor core 11 outputs a permission setting request to the MPU 15.

Then, the processor core 11 sets “no read request” in the handshake data 41 as indicated by the arrow L19.
When "no read request" is set for the handshake data 41, the processor core 12 ends the access error processing and outputs a read access request to the update data 31 to the MPU 15. The arrow L20 indicates that the processor core 12 is requesting read access to the update data 31.

Here, since the read access permission is set in the MPU 15, the MPU 15 outputs the read access permission notification to the processor core 12.
When the processor core 12 obtains the read access permission notification from the MPU 15, it accesses the update data 31 and reads the data from the update data 31. The arrow L21 indicates that the processor core 12 reads data from the update data 31.

Further, the processor core 13 outputs a read access request to the update data 31 to the MPU 15. The arrow L22 indicates that the processor core 13 is requesting read access to the update data 31.

Here, since the read access permission is set in the MPU 15, the MPU 15 outputs the read access permission notification to the processor core 13.
When the processor core 13 obtains the read access permission notification from the MPU 15, it accesses the update data 31 and reads the data from the update data 31. The arrow L23 indicates that the processor core 13 reads data from the update data 31.

Next, exclusive control by the semaphore will be described. Although the microcomputer 2 does not have a semaphore, it will be described that the processor cores 11 and 12 acquire and release the semaphore in order to simplify the explanation of the semaphore.

As shown in FIG. 8, first, at time t0, the semaphore is released. Block B1 indicates the period during which the semaphore is released.
Then, at time t1, the processor core 11 acquires the semaphore, and the processor core 11 executes a RAM test on the test block having the ID number 1 between the time t1 and the time t2. Block B2 indicates the period during which the semaphore is acquired by the processor core 11. Block B3 indicates the period during which the RAM test is performed on the test block having the ID number 1.

The processor core 11 executes a RAM test on a test block having an ID number of 2 between time t2 and time t3. Block B4 indicates the period during which the RAM test is performed on the test block having the ID number 2.

The processor core 11 executes a RAM test on a test block having an ID number of 3 between time t3 and time t4. Block B5 indicates the period during which the RAM test is performed on the test block having the ID number 3.

The processor core 11 executes a RAM test on the test block having the ID number 4 between the time t4 and the time t5. Block B6 indicates the period during which the RAM test is performed on the test block having the ID number 4.

The processor core 11 executes a RAM test on the test block having the ID number 5 between the time t5 and the time t6. Block B7 indicates the period during which the RAM test is performed on the test block having the ID number 5.

When the RAM test for the test block having the ID number 5 is completed at time t6, the processor core 11 releases the semaphore.
The processor core 12 attempts to acquire a semaphore between time t1 and time t6 and fails. Block B8 indicates the period of time that the processor core 12 waits until it acquires the semaphore.

Then, at time t7, the processor core 12 acquires the semaphore, and the processor core 12 reads data from the update data 31 between the time t7 and the time t8. Block B9 indicates the period during which the semaphore is released. Block B10 indicates the period during which the semaphore is acquired by the processor core 12. Block B11 indicates a period during which the processor core 12 is reading data.

When the data reading is completed at time t8, the processor core 12 releases the semaphore. Block B12 indicates the period during which the semaphore is released.
Next, exclusive control by the microcomputer 2 of the present embodiment will be described.

As shown in FIG. 9, first, at time t20, the read access permission is set in the MPU 15. Block B21 indicates a period in which read access permission is set.
Then, at time t21, the processor core 11 outputs a prohibition setting request to the MPU 15. As a result, the MPU 15 sets read access prohibition. Then, the processor core 11 executes the RAM test on the test block having the ID number 1 until the time t22.

When the RAM test for the test block having the ID number 1 is completed, the processor core 11 outputs a permission setting request to the MPU 15. As a result, the MPU 15 sets the read access permission. Block B22 indicates the period during which the RAM test is performed on the test block having the ID number 1. Block B23 indicates a period in which read access prohibition is set.

The processor core 11 outputs a read access request to the MPU 15 between the time t21 and the time t22. However, since the read access prohibition is set in the MPU 15, the processor core 12 waits until the read access is permitted. Then, the processor core 12 outputs a read access request to the MPU 15 at time t23. At time t23, since the read access permission is set in the MPU 15, the processor core 12 reads data from the update data 31. Block B24 indicates a period of waiting until read access is granted. Block B25 indicates a period in which read access permission is set. Block B26 indicates a period during which the processor core 12 is reading data.

Then, the processor core 11 starts the RAM test on the test block having the ID number 2 at time t24. Further, the processor core 11 starts a RAM test on the test block having the ID number 3 at time t25. Block B27 indicates the period during which the RAM test is performed on the test block having the ID number 2.

The ECU 1 configured in this way includes processor cores 11, 12, and 13, a RAM 21, and an MPU 15.
The RAM 21 stores update data 31 that can be readably accessed by each of the processor cores 11, 12, and 13.

The MPU 15 controls the processor cores 11, 12 and 13 so that the processor cores 12 and 13 cannot access the update data 31 when the processor core 11 is accessing the update data 31.

In this way, in the ECU 1, the MPU 15 controls the processor cores 11, 12, 13 so that the processor cores 12, 13 cannot access the update data 31 when the processor core 11 is accessing the update data 31. To do. That is, since the ECU 1 uses the MPU 15 instead of the semaphore, a special interface is not required on the accessing processor core side. As a result, the ECU 1 can suppress an increase in overhead and an increase in program code due to exclusive control between processor cores.

Further, the ECU 1 does not need to be provided with a dedicated shared memory for exchanging data between the processor core 11 and the processor cores 12 and 13, and each of the processor cores 11, 12 and 13 directly accesses the RAM 21 to obtain the processor core. Data can be exchanged between 11 and the processor cores 12 and 13.

Further, the processor core 11 sets the MPU 15 to read access prohibition which prohibits read access to the update data 31 from the processor cores 12 and 13 within the period when the processor core 11 accesses the update data 31. Further, the processor core 11 sets the MPU 15 to a read access permission that allows read access to the update data 31 from the processor cores 12 and 13 within a period in which the processor core 11 does not access the update data 31.

When data update is performed by a specific processor core, normally, even if data writing from other processor cores is prohibited, data reading is not prohibited. This is because reading data does not affect writing data.

On the other hand, the ECU 1 intentionally prohibits reading data from other processor cores, so that the MPU 15 is used to detect an intended read access request. Usually, the MPU is used to detect unintended unauthorized access. By using the MPU 15 to detect the intended access, the ECU 1 can reduce the overhead that always occurs at each access when the semaphore is used.

Further, the RAM 21 of the ECU 1 is used for handshaking between the processor cores 11, 12, and 13, and the handshake data 41, 51, which can be readably and updated by each of the processor cores 11, 12, and 13, respectively. Remember.

If the processor cores 12 and 13 output a read access request to the update data 31 to the MPU 15 within the period in which the processor core 11 accesses the update data 31, the MPU 15 notifies the processor cores 12 and 13 of the read access prohibition. Output.

When the processor cores 12 and 13 each acquire the read access prohibition notification from the MPU 15, the handshake data 41 and 51 used for the handshake between the processor core 11 and the processor cores 12 and 13 have a read access request. Set "Read request" to indicate.

The processor cores 12 and 13 move to the update data 31 when the handshake data 41 and 51 change from the state in which "with read request" is set to the state in which "without read request" is set, respectively. The read access request of is output to the MPU 15 again.

The processor core 11 repeatedly confirms the handshake data 41, 51 every time the RAM test for one test block is completed within the period in which the processor core 11 is accessing the update data 31, and the handshake data 41, 51. Judges whether or not "Read request" is set in.

When the processor core 11 determines that the handshake data 41 and 51 are set to "read request", the processor core 11 interrupts the RAM test and sets the MPU 15 to read access permission.

When the processor core 11 determines that "with read request" is set for the handshake data 41 and 51, the processor core 11 displays "no read request" indicating that there is no read access request for the handshake data 41 and 51. Set.

As a result, when the processor core 11 detects the read access request from the processor cores 12 and 13, the ECU 1 interrupts the RAM test and causes the processor cores 12 and 13 to execute read access to the update data 31. Can be done. Therefore, the ECU 1 can shorten the time for the processor cores 12 and 13 to wait for read access to the update data 31, and can improve the processing efficiency of the processor cores 12 and 13.

In the embodiment described above, the ECU 1 corresponds to an electronic control device, the RAM 21 corresponds to a shared data storage unit, and the MPU 15 corresponds to a memory protection unit.
Further, the update data 31 corresponds to shared data, the processor core 11 corresponds to a specific processor core, and the processor cores 12 and 13 correspond to other processor cores.

Further, S110 corresponds to processing as a prohibition setting unit, S180 corresponds to processing as a permission setting unit, read access prohibition corresponds to access prohibition, and read access permission corresponds to access permission.

Further, the RAM 21 corresponds to the handshake storage unit, the output of the read access prohibition notification corresponds to the memory access violation processing, S310 corresponds to the processing as the setting unit, and S320 and S330 correspond to the processing as the re-access unit. However, "with read request" corresponds to having access request.

Further, S150 corresponds to the processing as the request judgment unit and the interruption unit, S190 corresponds to the processing as the non-setting unit, and "the RAM test for one test block is completed" corresponds to the confirmation condition, and the RAM The test corresponds to access processing, and "no read request" corresponds to no access request.

[Second Embodiment]
The second embodiment of the present disclosure will be described below together with the drawings. In the second embodiment, a part different from the first embodiment will be described. The same reference numerals are given to common configurations.

The ECU 1 of the second embodiment is different from the first embodiment in that the priority table TB2 and the first processor process and the data read process are added.
The ROM 14 stores the priority table TB2. As shown in FIG. 10, the priority table TB2 is a table that stores the processor core numbers for identifying the processor cores 11, 12, and 13 and the priorities corresponding to the processor core numbers. The processor core numbers "1", "2", and "3" correspond to the processor cores 11, 12, and 13, respectively. In the priority table TB2 shown in FIG. 10, the priority of the processor core 11 is set to “high”, the priority of the processor core 12 is set to “medium”, and the priority of the processor core 13 is set to “low”.

Next, the procedure of the first processor processing executed by the processor core 11 will be described. The first processor process is a process that is started every time a preset execution cycle elapses. In the present embodiment, the execution cycle of the first processor processing is set to, for example, 10 ms. The first processor process is a process for sequentially executing N divided processes (hereinafter, divided processes). N is an integer of 2 or more.

When the first processor processing is executed, as shown in FIG. 11, the processor core 11 first sets read prohibition for the processor cores 12 and 13 in S410 in the same manner as in S110.

Further, the processor core 11 stores 1 in the processing instruction value i provided in the RAM 21 in S420.
Then, the processor core 11 executes the i-th division process in S430. Further, in S440, the processor core 11 stores the added value obtained by adding 1 to the value stored in the processing instruction value i in the processing instruction value i.

Next, the processor core 11 confirms the handshake data 41 and 51 in S450.
Then, the processor core 11 determines in S460 whether or not "with read request" is set for at least one of the handshake data 41 and 51. Here, when "no read request" is set for the handshake data 41 and 51, the processor core 11 divides the data 41 and 51 in which the value stored in the processing instruction value i is preset in S470. It is determined whether or not the number of processes is larger than N.

Here, when the value stored in the processing instruction value i is the number of division processes N or less, the processor core 11 shifts to S430. On the other hand, when the value stored in the processing instruction value i is larger than the number of division processes, the processor core 11 sets the read permission for the processor cores 12 and 13 in S480 in the same manner as in S180, and sets the read permission. 1 Terminates processor processing.

Further, in S460, when "Read request" is set in at least one of the handshake data 41 and 51, the processor core 11 refers to the priority table TB2 in S490.

Then, in S500, the processor core 11 sets read permission for the processor core having the highest priority among the processor cores corresponding to the handshake data for which "read request is made" is set. For example, when the processor cores corresponding to the handshake data for which "with read request" is set are the processor cores 12 and 13, the processor core 11 sets the read permission for the processor core 12.

Further, the processor core 11 sets "no read request" for the handshake data for the processor core having the highest priority among the processor cores corresponding to the handshake data for which "read request is present" is set in S510. Then, the first processor processing is terminated.

Next, the procedure of the data reading process executed by the processor core 12 will be described. The data read process is a process started when a data read request to the update data 31 occurs in the processor core 12.

When the data read process is executed, the processor core 12 first performs data read access in S610 as shown in FIG. Specifically, the processor core 12 outputs a read access request to the update data 31 to the MPU 15.

Then, the processor core 12 determines in S620 whether or not there is an access error. Specifically, the processor core 12 determines that there is an access error when the read access prohibition notification is acquired from the MPU 15, and determines that there is no access error when the read access permission notification is acquired from the MPU 15.

Here, when there is an access error, the processor core 12 sets "read request" in the handshake data 41 in S630.
Then, the processor core 12 determines in S640 whether or not "read request" is set in the handshake data 41. Here, when "with read request" is set, the processor core 12 waits until "no read request" is set in the handshake data 41 by repeating the process of S640.

Then, when "no read request" is set in the handshake data 41, the process proceeds to S650.
If there is no access error in S620, the process proceeds to S650.

Then, when shifting to S650, the processor core 12 accesses the update data 31 and reads data from the update data 31.
Then, the processor core 12 confirms the handshake data 51 in S660.

Then, the processor core 11 determines in S670 whether or not "read request" is set in the handshake data 51. Here, when "no read request" is set for the handshake data 51, the processor core 12 sets read permission for the processor core 13 in S680, and ends the data read process.

Further, in S670, when "Read request" is set in the handshake data 51, the processor core 12 refers to the priority table TB2 in S690.
Then, in S700, the processor core 12 sets read permission for the processor core having the highest priority among the processor cores corresponding to the handshake data for which "read request is present" is set. For example, when the processor core corresponding to the handshake data for which "with read request" is set is the processor core 13, the processor core 12 sets read permission for the processor core 13.

Further, the processor core 12 sets "no read request" for the handshake data for the processor core having the highest priority among the processor cores corresponding to the handshake data for which "read request is present" is set in S710. Then, the data reading process is terminated.

Since the data reading process executed by the processor core 13 is the same as the data reading process executed by the processor core 12 except that the handshake data 41 is changed to the handshake data 51, detailed description thereof will be omitted.

Next, a specific example of access arbitration by the MPU 15 of the second embodiment will be described.
As shown in FIG. 13, the processor core 11 first sets read access prohibition prohibiting read access from the processor cores 12 and 13 to the update data 31. The arrow L31 indicates that the processor core 11 outputs a prohibition setting request to the MPU 15.

Then, the processor core 11 starts the sequential execution of N division processes. The quadrangle SQ3 indicates that the processor core 11 is sequentially executing N division processes.
After the sequential execution of the N division processes is started, the processor core 12 outputs a read access request to the update data 31 to the MPU 15. The arrow L32 indicates that the processor core 12 is requesting read access to the update data 31.

Here, since the read access prohibition is set in the MPU 15, the MPU 15 outputs the read access prohibition notification to the processor core 12 as shown by the arrow L33.
When the processor core 12 obtains the read access prohibition notification from the MPU 15, the processor core 12 sets "read request" in the handshake data 41 as indicated by the arrow L34.

After that, the processor core 12 confirms the handshake data 41 and waits until "no read request" is set in the handshake data 41, as shown by the rectangle SQ4 and the arrow L35.

Further, the processor core 13 outputs a read access request to the update data 31 to the MPU 15. The arrow L36 indicates that the processor core 13 is requesting read access to the update data 31.

Here, since the read access prohibition is set in the MPU 15, the MPU 15 outputs the read access prohibition notification to the processor core 13 as shown by the arrow L37.
When the processor core 13 acquires the read access prohibition notification from the MPU 15, the processor core 13 sets “read request available” in the handshake data 51 as indicated by the arrow L38.

After that, the processor core 13 confirms the handshake data 51 and waits until "no read request" is set in the handshake data 51, as shown by the rectangle SQ5 and the arrow L39.

On the other hand, the processor core 11 sequentially executes N division processes and updates the data of the update data 31 as indicated by the arrow L40. Further, the processor core 11 determines whether or not "read request" is set in the handshake data 41 and 51 as indicated by the arrow L41.

Here, since "read request" is set for the handshake data 41 and 51, the processor core 11 refers to the priority table TB2 stored in the ROM 14 as shown by the arrow L42.

Then, the processor core 11 sets a read access permission for permitting read access from the processor core 12 having the highest priority among the processor cores 12 and 13. The arrow L43 indicates that the processor core 11 outputs the permission setting request of the processor core 12 to the MPU 15.

Then, the processor core 11 sets “no read request” in the handshake data 41 as indicated by the arrow L44.
When "no read request" is set for the handshake data 41, the processor core 12 outputs a read access request to the update data 31 to the MPU 15. Arrow L45 indicates that the processor core 12 is requesting read access to the update data 31.

Here, since the read access permission is set in the MPU 15, the MPU 15 outputs the read access permission notification to the processor core 12.
When the processor core 12 obtains the read access permission notification from the MPU 15, it accesses the update data 31 and reads the data from the update data 31. Arrow L46 indicates that the processor core 12 reads data from the update data 31.

Here, since the handshake data 51 is set to "read request", the processor core 12 refers to the priority table TB2 stored in the ROM 14 as shown by the arrow L47.

Then, the processor core 12 sets a read access permission for permitting read access from the processor core 13. The arrow L48 indicates that the processor core 12 outputs the permission setting request of the processor core 13 to the MPU 15.

Then, the processor core 11 sets “no read request” in the handshake data 51 as indicated by the arrow L49.
When "no read request" is set for the handshake data 51, the processor core 13 outputs a read access request to the update data 31 to the MPU 15. The arrow L50 indicates that the processor core 13 is requesting read access to the update data 31.

Here, since the read access permission is set in the MPU 15, the MPU 15 outputs the read access permission notification to the processor core 13.
When the processor core 13 obtains the read access permission notification from the MPU 15, it accesses the update data 31 and reads the data from the update data 31. The arrow L51 indicates that the processor core 13 reads data from the update data 31.

The ECU 1 configured in this way includes a priority table TB2 in which priorities are set for each of the processor cores 11, 12, and 13.
Then, the processor core 11 sets the MPU 15 to read access permission for the processor core 12 having the highest priority among the processor cores 12 and 13 that output the read access request to the MPU 15 based on the priority table TB2.

Further, the processor core 11 sets "no read request" for the handshake data 41 used for handshaking between the processor core 11 and the processor core 12.
As a result, the ECU 1 can allow the processor core 12 having a high priority to access the update data 31 in preference to the processor core 13 having a low priority. As a result, the ECU 1 can suppress the occurrence of a situation in which the execution of the high-priority process is delayed due to the execution of the low-priority process, and the responsiveness of the ECU 1 can be improved.

In the embodiment described above, S410 corresponds to the process as the prohibition setting unit, and S480 corresponds to the process as the permission setting unit.
Further, S630 corresponds to the process as the set unit, and S640 corresponds to the process as the re-access unit.

Further, S460 corresponds to the processing as the request determination unit, S460, S490, and S500 correspond to the processing as the interruption unit, and S510 corresponds to the processing as the non-setting unit.
"The end of one division process" corresponds to the confirmation condition, and the division process corresponds to the access process.

[Third Embodiment]
The third embodiment of the present disclosure will be described below together with the drawings. In the third embodiment, a part different from the first embodiment will be described. The same reference numerals are given to common configurations.

As shown in FIG. 14, the ECU 1 of the third embodiment is for controlling the peripheral device 17, the point where the peripheral devices 17 are added, the points where the RAMs 21, 22, and 23 are omitted and the RAM 26 is added, and the peripheral device 17. The point that the ROM 14 stores the peripheral device control program 71 is different from the first embodiment.

The peripheral device 17 and the RAM 26 are connected to the system bus 16.
The peripheral device 17 outputs a PWM signal to the actuator 4 according to the instructions from the processor cores 11, 12, and 13. PWM is an abbreviation for Pulse Width Modulation. In this embodiment, the actuator 4 is an electronic throttle.

The RAM 26 stores handshake data 61, 62, 63. The handshake data 61 is data in which the presence / absence of an execution request of the peripheral device control program 71 by the processor core 11 is set. The handshake data 62 is data in which the presence / absence of an execution request of the peripheral device control program 71 by the processor core 12 is set. The handshake data 63 is data in which the presence / absence of an execution request of the peripheral device control program 71 by the processor core 13 is set.

Further, in the ECU 1 of the third embodiment, the following first and second differences are different from those of the first embodiment in terms of data access.
The first difference is that the processor cores 11, 12, and 13 access the peripheral device control program 71 of the ROM 14 instead of accessing the update data 31 of the RAM 21. The second difference is that the processor cores 12 and 13 access the handshake data 62 and 63 of the RAM 26 instead of accessing the handshake data 41 and 51 of the RAM 21.

As described above, since the ECU 1 of the third embodiment is similar to the first embodiment in terms of data access, the description of the processing procedure using the flowchart is omitted.
Next, a first specific example of execution access arbitration by MPU 15 will be described.

As shown in FIG. 15, the processor core 11 first sets the execution access prohibition that prohibits the execution access from the processor cores 12 and 13 to the peripheral device control program 71. The arrow L61 indicates that the processor core 11 outputs a prohibition setting request to the MPU 15.

Next, the processor core 11 fetches the peripheral device control program 71 from the ROM 14, as shown by the arrow L62. Then, the processor core 11 executes control to output a PWM signal to the actuator 4 as shown by an arrow L63. Further, as shown by the arrow L64, the processor core 11 sets the execution access permission for permitting the execution access from the processor cores 12 and 13 to the peripheral device control program 71. The arrow L64 indicates that the processor core 11 outputs a permission setting request to the MPU 15.

After that, the processor core 12 outputs a fetch request to the peripheral device control program 71 to the MPU 15. The arrow L65 indicates that the processor core 12 is requesting a fetch to the peripheral device control program 71.

Here, since the execution access permission is set in the MPU 15, the MPU 15 outputs the execution access permission notification to the processor core 12.
When the processor core 12 obtains the execution access permission notification from the MPU 15, the processor core 12 accesses the ROM 14, fetches the peripheral device control program 71, and executes a control to output a PWM signal to the actuator 4 as shown by an arrow L66.

Further, the processor core 13 outputs a fetch request to the peripheral device control program 71 to the MPU 15. The arrow L67 indicates that the processor core 13 is requesting a fetch to the peripheral device control program 71.

Here, since the execution access permission is set in the MPU 15, the MPU 15 outputs the execution access permission notification to the processor core 13.
When the processor core 13 obtains the execution access permission notification from the MPU 15, the processor core 13 accesses the ROM 14, fetches the peripheral device control program 71, and executes a control to output a PWM signal to the actuator 4 as shown by an arrow L68.

Next, a second specific example of execution access arbitration by MPU 15 will be described.
As shown in FIG. 16, the processor core 11 first sets the execution access prohibition that prohibits the execution access from the processor cores 12 and 13 to the peripheral device control program 71. The arrow L71 indicates that the processor core 11 outputs a prohibition setting request to the MPU 15.

Then, the processor core 11 starts executing the actuator control process for controlling the actuator 4.
After the actuator control process is started, the processor core 12 outputs a fetch request to the peripheral device control program 71 to the MPU 15. The arrow L72 indicates that the processor core 12 is requesting a fetch to the peripheral device control program 71.

Here, since the execution access prohibition is set in the MPU 15, the MPU 15 outputs the execution access prohibition notification to the processor core 12 as shown by the arrow L73.
When the processor core 12 obtains the execution access prohibition notification from the MPU 15, the processor core 12 sets “execution access requested” in the handshake data 62 as indicated by the arrow L74.

After that, the processor core 12 confirms the handshake data 62 and waits until “no execution access request” is set in the handshake data 62, as shown by the rectangle SQ7 and the arrow L75.

On the other hand, when the execution of the actuator control process is started, the processor core 11 repeats the processes indicated by the arrows L76, L77, L78, and L80 in the quadrangle SQ6. The arrow L76 is a process for diagnosing the actuator 4. The arrow L77 is a process of fetching the peripheral device control program 71 from the ROM 14. The arrow L78 is a process of outputting an output instruction value to the peripheral device 17. The arrow L80 is a process for confirming the handshake data 61, 62, 63.

When the peripheral device 17 acquires the output instruction value from the processor core 11, it outputs a PWM signal to the actuator 4 as shown by the arrow L79.
Then, when "execution access requested" is set in the handshake data 62, the processor core 11 sets an execution access permission for permitting execution access from the processor cores 12 and 13 to the peripheral device control program 71. The arrow L81 indicates that the processor core 11 outputs a permission setting request to the MPU 15.

Further, the processor core 11 sets “no execution access request” in the handshake data 62 as indicated by the arrow L82.
When "no execution access request" is set in the handshake data 62, the processor core 12 outputs a fetch request to the peripheral device control program 71 to the MPU 15. The arrow L83 indicates that the processor core 12 is requesting a fetch to the peripheral device control program 71.

Here, since the execution access permission is set in the MPU 15, the MPU 15 outputs the execution access permission notification to the processor core 12.
When the processor core 12 obtains the execution access permission notification from the MPU 15, the processor core 12 accesses the ROM 14, fetches the peripheral device control program 71, and outputs an output instruction value to the peripheral device 17 as shown by the arrow L84.

When the peripheral device 17 acquires the output instruction value from the processor core 12, it outputs a PWM signal to the actuator 4 as shown by the arrow L85.
The ECU 1 configured in this way includes processor cores 11, 12, and 13, a ROM 14, and an MPU 15.

The ROM 14 stores a peripheral device control program 71 that can be readably accessed by each of the processor cores 11, 12, and 13.
The MPU 15 controls the processor cores 11, 12, 13 so that the processor cores 12 and 13 cannot access the peripheral device control program 71 when the processor core 11 is accessing the peripheral device control program 71.

As described above, in the ECU 1, the processor cores 11 and 12 prevent the processor cores 12 and 13 from accessing the peripheral device control program 71 when the processor core 11 is accessing the peripheral device control program 71. , 13 is controlled. That is, since the ECU 1 uses the MPU 15 instead of the semaphore, a special interface is not required on the accessing processor core side. As a result, the ECU 1 can suppress an increase in overhead and an increase in program code due to exclusive control between processor cores.

Further, the ECU 1 suppresses that when the processes are not synchronized between the processor cores 11, 12, and 13, the processor cores 11, 12, and 13 simultaneously access the peripheral device 17 and cause a malfunction in the peripheral device 17. be able to. Further, the ECU 1 can realize a rapid transfer of the usage right of the peripheral device 17 between the processor cores 11, 12, and 13, and improves the reliability and responsiveness of the system composed of the ECU 1 and the actuator 4. be able to.

Further, the processor core 11 sets the MPU 15 to the execution access prohibition prohibiting the execution access to the peripheral device control program 71 from the processor cores 12 and 13 within the period in which the processor core 11 accesses the peripheral device control program 71. .. Further, the processor core 11 sets the MPU 15 to an execution permission that allows execution access to the peripheral device control program 71 from the processor cores 12 and 13 within a period in which the processor core 11 does not access the peripheral device control program 71. ..

In this way, the ECU 1 intentionally prohibits execution access from other processor cores, so that the MPU 15 is used for detecting an intended execution access request. As a result, the ECU 1 can reduce the overhead that is always generated every time the semaphore is used.

Further, the RAM 26 of the ECU 1 is used for handshaking between the processor cores 11, 12, and 13, and the handshake data 62, 63, which can be read and updated by each of the processor cores 11, 12, and 13, respectively. Remember.

If the processor cores 12 and 13 output a fetch request to the peripheral device control program 71 to the MPU 15 within the period in which the processor core 11 accesses the peripheral device control program 71, the MPU 15 executes execution access to the processor cores 12 and 13. Output a prohibition notification.

When each of the processor cores 12 and 13 acquires the execution access prohibition notification from the MPU 15, it is determined that the handshake data 62 and 63 used for the handshake between the processor core 11 and the processor cores 12 and 13 have an execution access request. Set "Execution access request" to indicate.

The processor cores 12 and 13, respectively, are peripheral devices when the handshake data 62 and 63 change from the state in which "execution access request is present" to the state in which "execution access request is not set". The fetch request to the control program 71 is output to the MPU 15 again.

The processor core 11 repeatedly confirms the handshake data 62 and 63 every time the process of outputting the output instruction value to the peripheral device 17 is completed within the period in which the processor core 11 is accessing the peripheral device control program 71. It is determined whether or not "execution access request" is set in the handshake data 62 and 63.

When the processor core 11 determines that "execution access request" is set in the handshake data 62 and 63, the processor core 11 fetches the peripheral device control program 71 and outputs an output instruction value to the peripheral device 17. Suspend and set MPU15 to execute permission.

When the processor core 11 determines that the handshake data 62 and 63 are set to "read request", the processor core 11 indicates that the handshake data 62 and 63 do not have an execution access request "no execution access request". To set.

As a result, when the processor core 11 detects the execution access request from the processor cores 12 and 13, the ECU 1 interrupts the process of fetching the peripheral device control program 71 and outputting the output instruction value to the peripheral device 17. , Processor cores 12 and 13 can be made to execute execution access to the peripheral device control program 71. Therefore, the ECU 1 can shorten the time for the processor cores 12 and 13 to wait for the execution access to the peripheral device control program 71, and can improve the processing efficiency of the processor cores 12 and 13.

In the embodiment described above, the ROM 14 corresponds to the shared data storage unit, the peripheral device control program 71 corresponds to the shared data, and the RAM 26 corresponds to the handshake storage unit.
In addition, execution access prohibition corresponds to access prohibition, and execution access permission corresponds to access permission.

Further, the RAM 26 corresponds to a handshake storage unit, the output of the execution access prohibition notification corresponds to the memory access violation processing, and "with execution access request" corresponds to having an access request.

Further, "the process of outputting the output instruction value to the peripheral device 17 is completed" corresponds to the confirmation condition, and "the process of fetching the peripheral device control program 71 and outputting the output instruction value to the peripheral device 17" is an access. Corresponds to processing, and "no execution access request" corresponds to no access request.

[Fourth Embodiment]
The fourth embodiment of the present disclosure will be described below together with the drawings. In the fourth embodiment, a part different from the third embodiment will be described. The same reference numerals are given to common configurations.

The ECU 1 of the fourth embodiment is different from the third embodiment in that the priority table TB2 shown in the second embodiment is stored in the ROM 14.
Next, a specific example of execution access arbitration by the MPU 15 of the fourth embodiment will be described.

As shown in FIG. 17, the processor core 11 first sets the execution access prohibition that prohibits the execution access from the processor cores 12 and 13 to the peripheral device control program 71. The arrow L91 indicates that the processor core 11 outputs a prohibition setting request to the MPU 15.

Then, the processor core 11 starts executing the actuator control process for controlling the actuator 4.
After the actuator control process is started, the processor core 12 outputs a fetch request to the peripheral device control program 71 to the MPU 15. The arrow L92 indicates that the processor core 12 is requesting a fetch to the peripheral device control program 71.

Here, since the execution access prohibition is set in the MPU 15, the MPU 15 outputs the execution access prohibition notification to the processor core 12 as shown by the arrow L93.
When the processor core 12 receives the execution access prohibition notification from the MPU 15, the processor core 12 sets “execution access requested” in the handshake data 62 as indicated by the arrow L94.

After that, the processor core 12 confirms the handshake data 62 and waits until “no execution access request” is set in the handshake data 62, as indicated by the rectangle SQ9 and the arrow L95.

Further, the processor core 13 outputs a fetch request to the peripheral device control program 71 to the MPU 15 after the actuator control process is started. The arrow L96 indicates that the processor core 13 is requesting a fetch to the peripheral device control program 71.

Here, since the execution access prohibition is set in the MPU 15, the MPU 15 outputs the execution access prohibition notification to the processor core 13 as shown by the arrow L97.
When the processor core 13 receives the execution access prohibition notification from the MPU 15, the processor core 13 sets “execution access requested” in the handshake data 63 as indicated by the arrow L98.

After that, the processor core 13 confirms the handshake data 63 and waits until "no execution access request" is set in the handshake data 63, as shown by the rectangle SQ10 and the arrow L99.

On the other hand, when the execution of the actuator control process is started, the processor core 11 repeats the process indicated by the arrows L100, L101, and L102 in the quadrangle SQ8. The arrow L100 is a process of fetching the peripheral device control program 71 from the ROM 14. The arrow L101 is a process of outputting a PWM signal to the actuator 4. The arrow L102 is a process for confirming the handshake data 61, 62, 63.

Then, when "execution access request" is set in the handshake data 62, the priority table TB2 stored in the ROM 14 is referred to as shown by the arrow L103.

Next, the processor core 11 sets the execution access permission for permitting the execution access from the processor core 12 to the peripheral device control program 71. The arrow L104 indicates that the processor core 11 outputs a permission setting request to the MPU 15.

Further, the processor core 11 sets “no execution access request” in the handshake data 62 as indicated by the arrow L105.
When "no execution access request" is set in the handshake data 62, the processor core 12 outputs a fetch request to the peripheral device control program 71 to the MPU 15. The arrow L106 indicates that the processor core 12 is requesting a fetch to the peripheral device control program 71.

Here, since the execution access permission is set in the MPU 15, the MPU 15 outputs the execution access permission notification to the processor core 12.
When the processor core 12 obtains the execution access permission notification from the MPU 15, the processor core 12 accesses the ROM 14, fetches the peripheral device control program 71, and outputs a PWM signal to the actuator 4 as shown by the arrow L107.

Then, the processor core 12 refers to the priority table TB2 stored in the ROM 14 as shown by the arrow L108.
Next, the processor core 12 sets the execution access permission for permitting the execution access from the processor core 13 to the peripheral device control program 71. The arrow L109 indicates that the processor core 11 outputs a permission setting request to the MPU 15.

Further, the processor core 12 sets “no execution access request” in the handshake data 63 as indicated by the arrow L110.
When "no execution access request" is set in the handshake data 63, the processor core 13 outputs a fetch request to the peripheral device control program 71 to the MPU 15. The arrow L111 indicates that the processor core 13 is requesting a fetch to the peripheral device control program 71.

Here, since the execution access permission is set in the MPU 15, the MPU 15 outputs the execution access permission notification to the processor core 13.
When the processor core 13 acquires the execution access permission notification from the MPU 15, it accesses the ROM 14, fetches the peripheral device control program 71, and outputs a PWM signal to the actuator 4 as shown by the arrow L112.

The ECU 1 configured in this way includes a priority table TB2 in which priorities are set for each of the processor cores 11, 12, and 13.
Then, the processor core 11 sets the MPU 15 to execute permission for the processor core 12 having the highest priority among the processor cores 12 and 13 that output the fetch request to the MPU 15 based on the priority table TB2.

Further, the processor core 11 sets "no execution access request" in the handshake data 62 used for handshaking between the processor core 11 and the processor core 12.

As a result, the ECU 1 can allow the processor core 12 having a high priority to access the peripheral device control program 71 in preference to the processor core 13 having a low priority. As a result, the ECU 1 can suppress the occurrence of a situation in which the execution of the high-priority process is delayed due to the execution of the low-priority process, and the responsiveness of the ECU 1 can be improved.

Although one embodiment of the present disclosure has been described above, the present disclosure is not limited to the above embodiment, and can be implemented in various modifications.
The ECU 1 and its method described in the present disclosure are realized by a dedicated computer provided by configuring a processor and memory programmed to perform one or more functions embodied by a computer program. You may. Alternatively, the ECU 1 and its method described in the present disclosure may be realized by a dedicated computer provided by configuring the processor with one or more dedicated hardware logic circuits. Alternatively, the ECU 1 and its method described in the present disclosure are configured by a combination of a processor and memory programmed to perform one or more functions and a processor composed of one or more hardware logic circuits. It may be realized by one or more dedicated computers. The computer program may also be stored on a computer-readable non-transitional tangible recording medium as an instruction executed by the computer. The method for realizing the functions of each part included in the ECU 1 does not necessarily include software, and all the functions may be realized by using one or a plurality of hardware.

A plurality of functions possessed by one component in the above embodiment may be realized by a plurality of components, or one function possessed by one component may be realized by a plurality of components. Further, a plurality of functions possessed by the plurality of components may be realized by one component, or one function realized by the plurality of components may be realized by one component. Further, a part of the configuration of the above embodiment may be omitted. In addition, at least a part of the configuration of the above embodiment may be added or replaced with the configuration of the other above embodiment.

In addition to the above-mentioned ECU 1, various systems such as a system having the ECU 1 as a component, a program for operating a computer as the ECU 1, a non-transitional actual recording medium such as a semiconductor memory in which this program is recorded, and an access control method are used. The present disclosure can also be realized in the form.

1 ... ECU, 11, 12, 13 ... Processor core, 14 ... ROM, 15 ... MPU, 21 ... RAM, 31 ... Update data, 71 ... Peripheral device control program

Claims (5)

With multiple processor cores (11, 12, 13),
Shared data storage units (21, 14) configured to store shared data that can be readably accessed by each of the plurality of processor cores.
The processor core of one of the plurality of processor cores is designated as the specific processor core (11), the processor cores other than the specific processor core are designated as other processor cores (12, 13), and the specific processor core is the shared data. An electronic control device (15) including a memory protection unit (15) configured to control a plurality of the processor cores so that the other processor cores cannot access the shared data when accessing the data. 1). The electronic control device according to claim 1.
The specific processor core is
A prohibition setting unit configured to set the memory protection unit to an access prohibition that prohibits access to the shared data from the other processor core within the period during which the specific processor core accesses the shared data. S110, S410) and
A permission setting unit configured to set the memory protection unit to a permission permission to allow access to the shared data from the other processor core within a period in which the specific processor core does not access the shared data. An electronic control device including S180, S480). The electronic control device according to claim 2.
To store handshake data (41, 51, 62, 63) that is used for handshaking between the plurality of processor cores and that each of the plurality of processor cores can access readable and updatable. Equipped with a configured handshake storage unit (21, 26)
If the other processor core attempts to access the shared data within the period in which the specific processor core accesses the shared data, the memory protection unit performs memory access violation processing for the other processor core. Run and
The other processor core is
Indicates that there is an access request for the violation target handshake data, which is the handshake data used for the handshake between the specific processor core and the other processor core when the memory access violation processing is targeted. Yes setting units (S310, S630) configured to set access request presence,
When the violation target handshake data changes from the state in which the access request is set to the state in which the access request is not set, which indicates that there is no access request, the access to the shared data is performed again. It is equipped with re-access units (S320, S330, S640) configured to try.
The specific processor core is
Within the period during which the specific processor core is accessing the shared data, the violation target handshake data is repeatedly confirmed every time a preset confirmation condition is satisfied, and the violation target handshake data has the access request. The request determination unit (S150, S460) configured to determine whether or not is set, and
When the request determination unit determines that the access request is set for the violation target handshake data, the access process for the specific processor core to access the shared data is interrupted, and the permission setting unit is notified. , The interruption unit (S150, S460, S490, S500) configured to set the memory protection unit to the access permission, and
When the request determination unit determines that the access request is set in the violation target handshake data, the non-setting unit configured to set the access request non-existence in the violation target handshake data. An electronic control device including (S190, S510). The electronic control device according to any one of claims 1 to 3.
The process of accessing the shared data by the specific processor core is an electronic control device which is a test of reading data from the shared data and further writing data to the shared data. The electronic control device according to claim 3.
It has a priority table (TB2) in which priorities are set for each of the plurality of processor cores.
Based on the priority table, the interruption unit (S460, S490, S500) attaches the memory protection unit to the permission setting unit among the plurality of other processor cores that have attempted to access the shared data. The permission is set for the high priority processor core which is the other processor core having the highest priority.
The non-setting unit (S510) is an electronic control device that sets no access request to the violation target handshake data used for handshaking between the specific processor core and the high priority processor core.

Images