WO2024004414A1

WO2024004414A1 - Information processing device

Info

Publication number: WO2024004414A1
Application number: PCT/JP2023/018300
Authority: WO
Inventors: 一樹本間
Original assignee: 日立Astemo株式会社
Priority date: 2022-06-27
Filing date: 2023-05-16
Publication date: 2024-01-04
Also published as: JP2024003654A

Abstract

This information processing device comprises: a task executing unit for executing a plurality of tasks; a cycle generating unit for generating a first trigger signal at a predetermined cycle; and a task execution management unit for receiving the first trigger signal and transmitting a second trigger signal to the task executing unit to instruct the commencement of execution of the plurality of tasks. The task execution management unit adjusts the transmission timing of the second trigger signal based on the execution status of the task executing unit.

Description

information processing equipment

TECHNICAL FIELD The present invention relates to an information processing device mounted on a vehicle, and particularly to an information processing device capable of adjusting activation timing of tasks executed at a constant cycle.

In an information processing device installed in a vehicle or the like, a task executed at a fixed cycle may not be completed within the predetermined cycle due to various factors. Additionally, in recent years, ECUs (Electronic Control Units) in automobiles have come to be implemented as Integrated ECUs, which are a type of virtual machine that integrates multiple ECUs, and with this, the number of tasks executed within the Integrated ECUs has increased. There is also an increasing trend, and the problem of task processing not being completed within a predetermined period as described above is becoming more prominent.

FIG. 1 is a block diagram showing the hardware configuration of a general information processing device. The information processing device (1) includes a ROM (Read Only Memory) (12), which is a storage device from which data can be read, a RAM (Random Access Memory) (13), which is a storage device from which data can be written and read, and data. It has a CPU (Central Processing Unit) (11) that calculates parameters necessary for vehicle control based on the above, and a communication module (10) that converts the calculation results into a communication protocol and transmits them.

Further, the information processing device (1) is, for example, a device that is mounted on a vehicle and controls the vehicle. However, the information processing device (1) may not be mounted on the vehicle, and may be a device that controls an object other than the vehicle.

The information processing device (1) is connected to an external server (15) via a communication path (14). The communication path (14) may physically include a plurality of communication buses, and the standards of each communication bus may be the same or different. Standards of these communication buses include CAN (registered trademark), LIN (registered trademark), FlexRay (registered trademark), and Ethernet (registered trademark).

The information processing device (1) receives data that has passed through the communication path (14). Then, in response to reception, the received data is developed in the RAM (13). Then, the CPU (11) performs calculations based on the written data in the RAM (13) and the read data in the ROM (12). Further, a program is pre-installed in the information processing device (1), and the CPU (11) executes the program, thereby making it possible to execute the processing described below.

Examples of the above-mentioned information processing device (1) include a map positioning unit (MPU) on an integrated ECU. The following delays may occur in the application executed by the MPU on a route that periodically receives driving data from various sensors installed in the vehicle. In other words, delays may occur between a container and a virtual machine due to task switching or interference with other containers, and in virtual I/O (Input/Output) between an application and a container, S/W (SoftWare) processing may occur. delays may occur. Here, a container is a computer virtualization method in which a part of a running operating system (OS) is separated and a dedicated area is prepared isolated from the rest, and software is run on that area. In container virtualization technology, it refers to an isolated area.

If the task does not end within a certain period (for example, 10 ms cycle) due to the effects of these delays, there is a possibility that the operation and output results of the MPU cannot be guaranteed.

Here, the configuration of the MPU and the processing executed in the conventional technology will be explained using FIGS. 11-14. FIG. 11 is a block diagram showing an example of the configuration of an MPU in the prior art. The MPU (100) has an RTOS (130), a timer (140), and an I/O (150), and executes task 1 (110), task 2 (111), and task 3 (112) at a certain period (for example, 10 ms). It is executed every time. Although the MPU (100) is depicted as a single information processing device in FIG. 11, the MPU (100) may be executed as one virtual machine on an Integrated ECU, for example. Note that although the information processing device according to the present invention, including the embodiments, will be explained using an MPU, which is one of the in-vehicle ECUs, as an example, the scope of application of the present invention is not limited to the in-vehicle MPU, and It is applicable to all ECUs that receive data and execute processing.

RTOS (130) is an abbreviation for "Real Time Operation System" and is a system that executes processing by a requested deadline. In recent years, they have been increasingly installed in devices that require real-time processing, particularly MPUs. The RTOS (130) further includes a task dispatcher (131) and an I/O driver (132). The task dispatcher (131) is one of the control function units included in the RTOS (130), and selects the task to be executed next from among multiple tasks in an executable state and allocates the right to use the CPU. Has a function. The I/O driver (132) includes input/output control, file system, network protocol, etc., and has functions to control access to various data.

The timer (140) stores a preset period for each task, and sends a trigger signal (141) indicating the timing to start the task to the task dispatcher (131) at the timing when the task should be started. Send. The timer (140) may be implemented in hardware or software, for example.

I/O (Input/Output) (150) is an interface for inputting and outputting data, and transmits and receives data between MPU (100) and external vehicle (160) via I/O (150). will be held.

All tasks are sequentially executed one by one in response to a start signal (121) from a task dispatcher (131), which is a task control device within the RTOS (130). When each task completes its execution, it uses a completion signal (122) to inform the task dispatcher (131) that its execution is complete.

In this specification, including the embodiments, the task dispatcher (131) responds to a trigger signal (141) generated by a timer (140) installed in the MPU (100) at regular intervals of, for example, every 10 ms. Based on this, tasks 1 to 3 are started at regular intervals. However, the number of tasks executed within one cycle is arbitrary, and tasks having different cycles may be executed.

In addition, in its processing, task 3 (112) transmits driving data (151) obtained in real time from the vehicle (160) to the communication path (133) from the I/O (150) and the I/O in the RTOS (130). It is assumed that execution is performed using the input value as an input value via the communication path (123) from the O driver (132).

FIGS. 12-13 show a time chart and a flowchart representing the processing in which each of tasks 1 to 3 is executed in the conventional technology.

As shown in the time chart of FIG. 12, the timer (140) generates a trigger signal (141) at a constant cycle. Here, as an example, it is set every 10 ms, but this period can be set arbitrarily. When the timer (140) generates a trigger signal (141) in the n-th period, the task dispatcher (131) goes into a busy state in response to it and sends task 1 (110), task 2 (111), and task 3 (112). They will start in order.

Specifically, first, the task dispatcher (131) sends a start signal (121a) to task 1 (110), and starts task 1 (110). Task 1 (110) starts processing in response to receiving the start signal (121a), and when the processing is completed, it sends a completion signal (122a) to the task dispatcher (131) to report that the processing has been completed. .

Next, the task dispatcher (131) sends a start signal (121b) to task 2 (111) and starts task 2 (111). Task 2 (111) starts processing in response to reception of the activation signal (121b), and when the processing is completed, sends a completion signal (122b) to the task dispatcher (131) to report that the processing has been completed. .

Furthermore, the task dispatcher (131) sends an activation signal (121c) to task 3 (112) to activate task 3 (112). Task 3 (112) starts processing in response to receiving the activation signal (121c), and when the processing is completed, it sends a completion signal (122c) to the task dispatcher (131) to report that the processing has been completed. . Here, as mentioned above, task 3 (112) uses running data (151) obtained in real time from the vehicle (160) as an input value, so running data (151) that arrives every 10 ms is required for its activation. It is. In this case, since the running data (151) is earlier than the activation timing of task 3 (112) (timing of reception of activation signal 121c), task 3 (112) immediately processes it at the timing of reception of activation signal (121c). can be started.

Finally, when the task dispatcher (131) receives a completion signal (122c) indicating completion of execution from task 3 (112), which is the last task to be executed within the n-th cycle, It is assumed that all tasks to be executed have been completed, and the busy state is canceled.

Similarly, the process is executed continuously in the (n+1)th period and the (n+2)th period.

FIG. 13 shows the above processing as a flowchart. First, in step S1301, the task dispatcher (131) receives a trigger signal (141) from the timer (140). In step S1302, a task is started in response to the reception, and in step S1303, when the processing of the task is completed, a completion signal is received from the task. In step S1304, it is determined whether the task that has sent the completion signal is the last task to be executed within the cycle, and if it is not the last task, the process returns to step S1302 and starts the next task, and if it is the last task, the next task is activated. End the process (cancel the busy state). The above is the processing executed by the conventionally used MPU (100).

FIG. 14 shows a case in which a problem occurs in the prior art when the execution of a certain task is not completed within a predetermined 10 ms interval when each of the tasks 1 to 3 is executed. In FIG. 14, the processing within the nth period and the processing up to the execution of task 2 (111) within the (n+1)th period are the same as those in FIG.

Within the (n+1)th cycle, after receiving the completion signal (122b) from task 2 (111), the task dispatcher (131) sends a start signal (121c) to task 3 (112) to try to start it. Here, some abnormality occurs in the communication path (133, 123) between the vehicle (160) and task 3 (112), and the driving data (151) is transferred to task 3 (112) within the (n+1)th period. ) may not be obtained at the time when the activation signal (121c) indicating the timing to activate the activation signal (121c) is generated. In this case, task 3 (112) cannot immediately start its processing at the timing of receiving the start signal (121c), and task 3 (112) is also delayed by the delay (240) in receiving the driving data (151). 250). In that case, the completion of task 3 (112) may be delayed until after the start timing of the next (n+2)th cycle.

In the above state, since the timer (140) is programmed to generate the trigger signal (141) every 10ms, the (n+2)th cycle is started after 10ms have elapsed from the start of the (n+1)th cycle. A trigger signal (141) is generated. In response, the task dispatcher (131) attempts to start task 1 (110), task 2 (111), and task 3 (112) in order, but at this point, the Processing of task 3 (112) has not yet been completed, and the task dispatcher (131) remains in a busy state. On the other hand, the task dispatcher (131) attempts to put itself into a busy state in order to start task processing in the (n+2)th period in response to receiving the trigger signal from the timer (140). 131) will result in an inconsistency in the state.

Therefore, even if the completion of task 3 (112) is reported to the task dispatcher (131) at a later timing than originally expected, task 3 (112) in the (n+1)th period is completed at timing 230. The reception of the signal (122c) and the reception of the trigger signal (141) notifying the start of the (n+2)th period by the timer (140) overlap, and the task dispatcher (131) replaces the current busy state with the previous one. It is not possible to determine whether the task should be canceled because it corresponds to a series of task processing, or whether the busy state should be continued because it corresponds to the next series of task processing. Due to this inconsistency, the task dispatcher (131) may not be able to continue operating normally, or the processing of task 1 (110), task 2 (111), and task 3 (112) may not be able to continue correctly. Problems such as a decrease in the reliability of the content will occur.

In relation to the above technology, Patent Document 1 describes a technology for supporting a location search service, which includes a periodic trigger service and a configuration of an invention that performs a location search, and further includes: A technique is disclosed for correcting received information when it does not match stored information.

Japanese Patent Application Publication No. 2013-048444

As shown in the example of FIG. 14, if there is a task that is executed at a fixed period and requires the arrival of travel data (151) for its activation, the predetermined A case may occur in which the processing of a task is not completed within a certain period, and its completion is delayed until the next certain period, and the execution result of the entire task or the MPU (100) cannot be guaranteed. Note that such a delay in task completion is not limited to a delay in driving data (151); for example, if the MPU (100) running in a virtual machine on an Integrated ECU is running on another virtual machine on the same Integrated ECU, It is obvious that various factors can be assumed, such as disturbances caused by applications running on the computer.

The present invention has been made in view of the above-mentioned problems, and even if a task executed at a fixed cycle does not complete its processing within a predetermined cycle due to some reason, each task or the MPU as a whole can operate normally. The purpose of the present invention is to provide an information processing device that enables the continuation of

In order to achieve the above object, an information processing device according to the present invention includes a task execution unit that executes a plurality of tasks, a cycle generation unit that generates a first trigger signal at a predetermined cycle, and a first trigger signal. a task execution management section that receives the signal and transmits a second trigger signal instructing the task execution section to start execution of a plurality of tasks, and the task execution management section is configured to monitor the execution status of the task execution section. The transmission timing of the second trigger signal is adjusted accordingly.

According to the present invention, even if a task executed at a constant cycle does not complete its processing within a predetermined cycle due to some reason, it is possible to continue the normal operation of each task or the MPU as a whole.
Further features related to the invention will become apparent from the description herein and the accompanying drawings. Further, problems, configurations, and effects other than those described above will be made clear by the description of the following examples.

FIG. 1 is a block diagram showing the configuration of a general information processing device. FIG. 2 is a block diagram showing an example of the configuration of an MPU according to the present invention. FIG. 3 is a block diagram showing the configuration of a time keeper included in the MPU according to the present invention. 5 is a time chart showing processing executed by the MPU according to the present invention when there is no delay in receiving travel data. FIG. 3 is a sequence diagram showing an overview of processing executed within the MPU according to the present invention. Flowchart illustrating processing performed by a task dispatcher. 5 is a time chart showing processing executed by the MPU according to the present invention when there is a delay in receiving travel data. 2 is a flowchart showing the processing performed by the time keeper. 5 is a time chart showing processing executed by an MPU according to a modification of the present invention. 10 is a flowchart showing processing executed by the processing time keeper shown in FIG. 9; FIG. 1 is a block diagram showing an example of the configuration of a conventional MPU. 5 is a time chart showing an example of processing executed by a conventional MPU. 2 is a flowchart showing processing executed by a task dispatcher in a conventional MPU. FIG. 2 is a time chart for explaining problems that occur when there is a delay in receiving driving data when a conventional MPU is employed. FIG.

Embodiments of the present invention will be described below with reference to the drawings.
FIG. 2 is a block diagram showing the configuration of an MPU (100) according to an embodiment of the present invention. The MPU (100) according to this embodiment is similar to the conventional MPU in that it executes task 1 (110), task 2 (111), and task 3 (112) at predetermined intervals. The MPU (100) according to this embodiment differs from the conventional MPU (100) shown in FIG. 11 in that the RTOS (130) further includes a time keeper (300). The task dispatcher (131) in the conventional MPU (100) directly receives the trigger signal (141) indicating the task activation timing from the timer (140) and activates each task. , the trigger signal (141) from the timer (140) is sent to the time keeper (300), and the task dispatcher (131) receives each trigger signal (320) from the time keeper (300). Launch a task.

The time keeper (300) sends messages to the task dispatcher (131) based on a trigger signal (141) at regular intervals of, for example, every 10 ms, which is generated by a timer (140) installed in the MPU (100). The timing for activating tasks 1 to 3 at regular intervals is communicated by transmitting a trigger signal (320). The timer (140) may be implemented in hardware or software, for example.

A task dispatcher (131) starts each task 1 to 3 at regular intervals based on a trigger signal (320) from a time keeper (300) installed in the RTOS (130). The task dispatcher (131) also monitors the completion signal (122) coming from each task, and immediately sends a dispatcher completion signal (310) to the time keeper (300) when it confirms that all tasks have been completed. .

FIG. 3 shows an example of the configuration of the time keeper (300). The time keeper (300) includes a dispatcher completion signal holding register (301) that holds the dispatcher completion signal (310), and a timer request holding register (302) that holds the trigger signal (141) from the timer (140). , has an AND device (303) that generates a trigger signal (320) when both the output (304) of the dispatcher completion signal holding register (301) and the output (305) of the timer request holding register (302) become valid. . Further, the dispatcher completion signal holding register (301) and timer request holding register (302) are set so that their contents are cleared when the trigger signal (320) is output. Note that "holding the dispatcher completion signal (310) and trigger signal (141)" means, for example, that each register has a flag, and the flag is set to 1 in response to the reception of the signal, and when reset, the flag is set to 1. This is accomplished by setting the flag to 0.

FIG. 4 is a time chart showing the processing executed by the MPU (100) according to the present embodiment when there is no delay in receiving driving data. The time chart shown in FIG. 4 is the conventional time chart shown in FIG. 12 with processing by the time keeper (300) added, so only the processing related to the time keeper (300) will be described.

When the timer (140) generates a trigger signal (141) at a certain 10 ms period timing (for example, the start timing of the nth period), the time keeper (300) receives the trigger signal in the timer request holding register (302). Retains the information that came with it. Here, since the dispatcher completion signal holding register (301) of the time keeper (300) holds the completion signal as an initial value, the AND device (303) receives the trigger signal (141) from the timer (140). In response to this, a trigger signal (320) is sent to the task dispatcher (131), and at the same time, the dispatcher completion signal holding register (301) and timer request holding register (302) are cleared. In response to receiving the trigger signal (320), the task dispatcher (131) enters a busy state and sequentially starts task 1 (110), task 2 (111), and task 3 (112). This task activation process is the same as the conventional one.

FIG. 5 is a sequence diagram showing an overview of the above processing executed within the MPU (100) according to this embodiment. As shown in FIG. 5, first, in step 501, the timer (140) generates a trigger signal at the start timing of each cycle and transmits it to the time keeper (300). In

steps

502 and 503, the time keeper (300) clears the contents of the dispatcher completion signal holding register (301) and the timer request holding register (302), and also informs the task dispatcher (131) of the startup timing of each task. A trigger signal (320) notifying the user is transmitted. In step 504, the task dispatcher (131) sequentially activates tasks, and in step 505, receives a completion signal (122) from the task executed last within the period. The task dispatcher (131) sends a dispatcher completion signal (310) to the time keeper (300) in step 506 in response to receiving the last completion signal. In step 507, the time keeper (300) holds the dispatcher completion signal (310) in the dispatcher completion signal holding register (301) and waits until receiving the next trigger signal (141) from the timer (140).

Next, the process executed by the task dispatcher (131) in this embodiment will be explained using the flowchart of FIG. 6. In the flowchart of FIG. 6, step S601 is added in addition to the process executed by the conventional task dispatcher (131) shown in FIG. Further, the trigger signal received in step S1301 is not the trigger signal (141) from the timer (140) but the trigger signal (320) from the time keeper (300).

When the task dispatcher (131) in this embodiment determines in step S1304 that processing of all tasks to be executed within the period has been completed, it generates a dispatcher completion signal (310) and sends the time keeper (300) Send to. The time keeper (300) accordingly holds this signal in the dispatcher completion signal holding register (301) as described above.

FIG. 7 shows a time chart representing the process executed by the MPU (100) according to the present embodiment when a delay in receiving driving data occurs. In FIG. 7, it is assumed that reception of travel data (151) is delayed in the (n+1)th cycle.

The processing within the n-th period is the same as that in FIG. 4 in which there is no delay in receiving driving data, and the task dispatcher (131) sequentially starts tasks 1 to 3, and receives a completion signal from the last task 3 (112). (122c), it sends a dispatcher complete signal (310) to the time keeper (300). The time keeper (300) holds the reception information in the dispatcher completion signal holding register (301) upon reception.

Then, the timer (140) generates a trigger signal (141) at the start timing of the (n+1)th period following the nth period, and transmits it to the time keeper (300). Then, the time keeper (300) holds the arrival of the trigger signal in the timer request holding register (302). As mentioned above, the dispatcher completion signal holding register (301) of the time keeper (300) is in a state of holding completion, so the AND unit (303) sends the trigger signal (320) to the task dispatcher (131) and at the same time Clear the dispatcher completion signal holding register (301) and timer request holding register (302). In response, the task dispatcher (131) goes into a busy state and starts task 1 (110), task 2 (111), and task 3 (112) in order.

After receiving the completion signal (122b) from task 2 (111), the task dispatcher (131) sends a start signal (121c) to start task 3 (112) to task 3 (112), and (112). However, as described above, in FIG. 7, there is a delay (240) in receiving the travel data (151) during the (n+1)th cycle.

Even if the execution of task 3 (112) in the (n+1)th cycle is not completed, the time counter in the timer (140) continues to operate, so that the timer (140) generates a trigger signal (141) for starting processing in the (n+2)th period, and transmits it to the time keeper (300). The time keeper (300) holds information that the trigger signal (141) has arrived in a timer request holding register (302) in response to receiving the signal. However, since the task dispatcher (131) has not received the completion signal (122c) from task 3 (112) at this point, it has not sent the dispatcher completion signal (310) to the time keeper (300). Therefore, the dispatcher completion signal holding register (301) of the time keeper (300) does not hold reception information of the dispatcher completion signal (310). Therefore, the signal generation conditions of the AND device (303) are not satisfied, and the generation of the trigger signal (320) by the time keeper (300) is put on hold.

In the above-mentioned pending state, the execution of task 3 (112), which had been delayed within the (n+1)th period, is completed, and the task dispatcher (131) sends the dispatcher completion signal (310) to the time keeper (300). Continue until sent. As a result, the period (260) from the timing assumed as the start point of the (n+2)th period until the time keeper (300) receives the dispatcher completion signal (310) is the start of the (n+2)th period. This becomes a "suppression period" in which the generation of the trigger signal (141) that notifies the timing is put on hold.

When the task dispatcher (131) sends a dispatcher completion signal (310) to the time keeper (300) in response to receiving the completion signal (122c) from task 3 (112), the time keeper (300) The signal is held in the dispatcher completion signal holding register (301). Then, since the ON condition of the AND device (303) is satisfied, the time keeper (300) sends the trigger signal (320) notifying the start of the (n+2)th period to the task dispatcher (131) and at the same time sends the dispatcher completion signal. Clear the holding register (301) and timer request holding register (302). In response, the task dispatcher (131) goes into a busy state and starts task 1 (110), task 2 (111), and task 3 (112) in order. Thereafter, task 1 (110), task 2 (111), and task 3 (112) are processed according to the same flow as described above.

The process executed by the time keeper (300) in the embodiment described above will be explained using the flowchart of FIG. 8. First, in step S801, the time keeper (300) receives a trigger signal (141) from the timer (140) that notifies the start timing of a certain period. In step S802, the time keeper (300) refers to the dispatcher completion signal holding register (301) and determines whether the reception of the dispatcher completion signal (310) is held. If it is not held, it remains on standby; if it is held, the process moves to step S803, generates a trigger signal (320), and notifies the task dispatcher (131) of the start of processing.

As explained above, according to the present embodiment, even if the execution of a certain task is not completed within the expected execution cycle, the time keeper (300) keeps track of the task until the execution of all tasks is completed. - By suspending the generation of the trigger signal (320) that notifies the dispatcher (131) of the start of processing, even if the trigger signal (141) that notifies the start of the next cycle is received from the timer (140); The task dispatcher (131) can continue to operate normally, and the processing of task 1 (110), task 2 (111), and task 3 (112) can also continue correctly.

Next, processing executed by the MPU (100) according to a modification of the present invention will be described using FIGS. 9-10. FIG. 9 is a time chart showing the processing executed by the MPU (100) according to the modification, and FIG. 10 is a flowchart showing the processing executed by the time keeper (300).

In the embodiment described above, it is possible to solve the problem caused by the generation of a trigger signal that notifies the start of the next cycle when execution of a certain task is not completed within the expected cycle. was aimed at. On the other hand, in a modified example, when the period until all task execution is completed within one cycle is shorter than a predetermined period, the start of the next cycle is brought forward to improve CPU utilization efficiency. This is the purpose.

Specifically, as shown in FIG. 9, for example, in the n-th period, the time keeper (300) receives the dispatcher completion signal (310) from the task dispatcher (131), and from the time the time keeper (300) receives the dispatcher completion signal (310) from the timer (140). A cycle period period (270) is measured, which is the time until the trigger signal (141) notifying the start of the (n+1) cycle is received. This can be measured, for example, by providing a time counter in each of the dispatcher completion signal holding register (301) and the timer request holding register (302), and obtaining the difference between the reception times.

The time keeper (300) compares the period until the execution of tasks 1-3 is completed with a predetermined period within the n-th cycle, and determines whether the period until the execution of tasks 1-3 is completed is the predetermined period. , the timer (140) is instructed to advance the start of the (n+2)th cycle by the shortened time (280). This can be determined by comparing the cycle period (270) with the difference between one cycle (10 ms in FIG. 9) and the predetermined period.

In the above, the predetermined period to be compared with the period until the execution of tasks 1-3 is completed is set within a range that does not cause the problem when the execution of the task is not completed within the period described above, It can be predetermined in consideration of the travel data reception interval, the worst execution time of each task, etc.

FIG. 10 is a flowchart showing the processing executed by the time keeper (300) in this modification. First, in step S1001, the time keeper (300) receives a dispatcher completion signal (310) from the task dispatcher (131). In step S1002, a trigger signal (141) notifying the start of the next cycle is received from the time keeper (300). The time keeper (300) then measures the cyclic period (270) as described above, and in step S1003 compares it with a threshold value corresponding to a predetermined period set in advance, and determines whether the cyclic period (270) is less than the threshold value. If it is long, it is determined that there is enough time from completion of execution of all tasks within one cycle until the start of the next cycle, and in step S1004, the time keeper (300) is instructed to perform the next cycle. A signal instructing to shorten the generation cycle of the trigger signal (141) notifying the start is transmitted.

According to the modification described above, if there is a margin between the completion of execution of all tasks within one cycle and the start of the next cycle, by advancing the cycle start timing, the idle time during which the CPU does not operate can be reduced. This makes it possible to reduce the number of CPUs, improve the efficiency of CPU usage, and expect faster task execution.

According to the embodiments of the present invention described above, the following effects are achieved.
(1) The information processing device according to the present invention includes a task execution unit that executes a plurality of tasks, a cycle generation unit that generates a first trigger signal at a predetermined cycle, and a task execution unit that receives the first trigger signal and a task execution management section that transmits a second trigger signal instructing the execution section to start execution of a plurality of tasks; the task execution management section transmits a second trigger signal according to the execution status of the task execution section; Adjust the trigger signal transmission timing.

With the above configuration, even if a task executed at a constant cycle does not complete its processing within a predetermined cycle due to some reason, each task or the MPU as a whole can continue to operate normally.

(2) If the period until the task execution unit completes execution of multiple tasks within a cycle is shorter than a predetermined period, the task execution management unit sends the first trigger signal to the cycle generation unit. Sends an instruction signal to shorten the generation cycle. This makes it possible to reduce the idle time during which the CPU does not operate, improves the efficiency of CPU usage, and can be expected to speed up task execution.

(3) The task execution unit transmits an execution completion signal to the task execution management unit when execution of all the multiple tasks within the cycle is completed, and the task execution management unit sends the first trigger signal. After receiving the trigger signal, a second trigger signal is transmitted on condition that the execution completion signal is received. As a result, the time keeper (300) suspends the generation of the trigger signal (320) that notifies the task dispatcher (131) of the start of processing until the execution of all tasks is completed. Even when the task dispatcher (131) receives a trigger signal (141) notifying the start of the next cycle, it is possible to continue operating normally.

In this embodiment, the operation in a map information processing unit (MPU) is explained as an example, but this is not limited to the MPU, and can be applied to general systems that perform periodic processing at regular intervals, for example. Conceivable. Further, the information processing system does not necessarily have to be an actual machine, and as mentioned above, it can be applied to, for example, an MPU built on an integrated ECU or an information processing system in general.

Note that the present invention is not limited to the above embodiments, and various modifications are possible. For example, the above embodiments have been described in detail to explain the present invention in an easy-to-understand manner, and the present invention is not necessarily limited to embodiments having all the configurations described. Furthermore, it is possible to replace a part of the configuration of one embodiment with the configuration of another embodiment. Further, it is also possible to add the configuration of another embodiment to the configuration of one embodiment. Further, it is possible to delete a part of the configuration of each embodiment, or add or replace other configurations.

100: MPU (information processing unit) 131: Task dispatcher (task execution unit) 140: Timer (cycle generation unit) 300: Time keeper (task execution management unit)

Claims

a task execution unit that executes multiple tasks;
a cycle generation unit that generates a first trigger signal at a predetermined cycle;
a task execution management unit that receives the first trigger signal and transmits a second trigger signal that instructs the task execution unit to start executing the plurality of tasks;
The task execution management unit adjusts the transmission timing of the second trigger signal according to the execution status of the task execution unit.
An information processing device characterized by:
The information processing device according to claim 1,
If the period until the task execution unit completes execution of the plurality of tasks within the cycle is shorter than a predetermined period,
The task execution management unit transmits an instruction signal to the cycle generation unit to shorten the cycle of generating the first trigger signal.
An information processing device characterized by:
The information processing device according to claim 1,
The task execution unit transmits an execution completion signal to the task execution management unit when execution of all of the plurality of tasks within the period is completed,
After receiving the first trigger signal, the task execution management unit transmits the second trigger signal on condition that the execution completion signal is received.
An information processing device characterized by: