Patent Description:
Vehicle systems often each include an ECU that operates computerized vehicle control equipment, in other words, an electronic control unit, and an in-vehicle network (local area network) that enables communication between a plurality of ECUs.

In recent years, a demand for realizing an automatic driving system that automatically carries a vehicle to a destination without the operation of a driver is increasing. The realization of an automatic driving system requires a high-accuracy outside recognition function, and a function of predicting surrounding environmental changes several seconds ahead to determine a traveling course, which requires a high operation load. Therefore, practical use of open source software (OSS) equipped with most-advanced algorithm is desired.

However, OSS is widely open to public, and thus there is also a case where in general quality is not high. Therefore, it is difficult to equip a system that requires high safety, such as an automotive control system, with OSS without any change. Accordingly, in preparation for an emergency, a method in which in a case where OSS occupies a CPU, other software is not influenced is desired.

For example, NPL <NUM> discloses performing a time division design in which an execution cycle of a system is determined, and a time zone of processing to be executed in the cycle is determined. This time zone is called a time window or a slot. At the time of system execution, specific processing is executed within the time of a specific time window according to the design. A unit of processing is a task or an interrupt process. When the specific processing does not end until the end time of the time window, it is basically determined that an error has occurred. Consequently, the processing is terminated. In this manner, according to NPL <NUM>, pieces of software to be executed in respective time windows are capable of realizing non-interference so as not to influence one another. Furthermore, PTL <NUM> discloses a control device for vehicles, wherein the control device refers to and updates data for each CPU while guaranteeing consistency of data by synchronization processing. Eventually, PTL <NUM> also discloses a vehicle control device.

However, according to NPL <NUM>, the interrupt process is also required to be assigned to a time window. Therefore, in such a case where an interrupt request occurs immediately after a time window for an interrupt process has ended, the interrupt process must be brought into a waiting state until series of processing assigned to the other time windows end, which leads to a decrease in responsiveness to an interrupt Basically, interrupt processes should often be immediately handled, and therefore lengthened waiting time is not preferable.

The present disclosure has been devised in consideration of such a situation, and provides technology for achieving both high responsiveness to an interrupt process and non-interference between control software.

In order to solve the above-described problem, the vehicle control device having the features of independent claim <NUM>. Furthermore, a vehicle system having features of co-independent claim <NUM> is provided. Preferred embodiments are claimed by the dependent claims.

Further features related to the present disclosure will become apparent from the statement of the present description and accompanying drawings. In addition, modes of the present disclosure are achieved and realized by elements, various combinations of elements, the detailed statements described below, and aspects of the appended claims. It should be noted that the statement of the present description is merely exemplary illustration, and does not intend to limit the scope or application of the claims of the present disclosure in any way.

With respect to the vehicle control device according to the present disclosure, a task operated in a time division on the basis of the time division is not influenced by processing of the other time divisions executed in the same core, and therefore non-interference can be ensured. In addition, inter-core communication updates shared data in the timing that does not refer to the shared data, and therefore non-interference can be ensured between cores too. Moreover, an interrupt process is executed by a means other than the time division, and therefore high responsiveness can be realized. This enables to achieve both high responsiveness to an interrupt process and non-interference between control software.

A vehicle control device according to the present disclosure executes time-driven scheduling and other scheduling algorithms in a multi-core environment, and performs inter-core communication in a non-interference manner between the scheduling algorithms, thereby achieving both high responsiveness to an interrupt request and non-interference between control software.

In the vehicle control device according to the present disclosure, a control application that is desired to be non-interference is executed by a core that is executed in a time division manner, and basic software that is desired to be highly responsive is executed by a core that is executed on the basis of a priority of a task. This enables to achieve both high responsiveness and non-interference. It should be noted that in the present description, time window is referred to as slot.

Embodiments of the present disclosure will be explained below with reference to the accompanying drawings. In the accompanying drawings, in some case, functionally the same components are denoted by the same reference numerals. It should be noted that although the accompanying drawings show specific embodiments and implementation examples conforming to the principles of the present disclosure, the accompanying drawings are presented for the understanding of the present disclosure, and are by no means used to limitedly construe the present disclosure.

The present embodiment is explained in detail sufficiently for those skilled in the art to carry out the present disclosure.

Further, the embodiments of the present disclosure may be implemented as software running on a general-purpose computer or may be implemented as dedicated hardware or a combination of software and hardware.

Incidentally, in the following explanation, kinds of information of the present disclosure are explained according to a "table" format. However, these kinds of information do not always have to be represented in a data structure by a table, and may be represented in a data structure of a list, a DB, a queue, or the like or other structures. Therefore, in order to indicate that the information does not depend on the data structure, in some case, "table," "list," "DB," "queue" and the like are simply referred to as "information".

In addition, when contents of the kinds of information are explained, expressions such as "identification information", "identifier", "appellation", "name" and "ID" can be used. These expressions can be interchanged.

Kinds of processing in the embodiments of the present disclosure are explained below using "program" as a subject (an operation entity). However, since the program is executed by a processor to perform set processing using a memory and a communication port (a communication control device), the processing may be explained using the processor as a subject. A part or all of the program may be realized by dedicated hardware or may be formed as a module.

According to a first embodiment, there is disclosed a multi-core equipped vehicle control device in which, for example, one core (for example, a core <NUM>) is caused to take charge of a task that should be executed by time division, and another core (for example, a core <NUM>) is caused to take charge of a task that should be executed not by time division. Here, for example, an interrupt process such as communication is mentioned as a task executed not by time division. More specifically, the core <NUM> executes a task that should be cyclically executed in a set slot. The core <NUM> executes a task (an interrupt process) that is not cyclically executed in an available slot. The first embodiment will be described below in detail.

<FIG> is a diagram illustrating a schematic configuration of the vehicle control device <NUM> according to the embodiment of the present disclosure.

The program area <NUM> of the memory <NUM> includes, as various programs, the core <NUM> initialization unit <NUM>, the slot synchronous processing timing setting unit <NUM>, the alarm processing unit <NUM>, the slot synchronous read processing unit <NUM>, the slot synchronous write processing unit <NUM>, the priority scheduling unit <NUM>, the transmission processing unit <NUM>, the reception interrupt processing unit <NUM>, the core <NUM> initialization unit <NUM>, the slot setting unit <NUM>, the sensor fusion unit <NUM>, the dynamic map generation unit <NUM>, the course generation unit <NUM>, and the time-driven scheduling unit <NUM>.

The core <NUM> initialization unit <NUM>, the slot synchronous processing timing setting unit <NUM>, the alarm processing unit <NUM>, the slot synchronous read processing unit <NUM>, the slot synchronous write processing unit <NUM>, the priority scheduling unit <NUM>, the transmission processing unit <NUM>, and the reception interrupt processing unit <NUM> are executed by the core 1_11. The slot setting unit <NUM>, the sensor fusion unit <NUM>, the dynamic map generation unit <NUM>, the course generation unit <NUM>, and the time-driven scheduling unit <NUM> are executed by the core 2_12. More specifically, the computation device (the core <NUM>) <NUM> and the computation device (the core <NUM>) <NUM> each read each program corresponding to processing in charge in a temporary buffer, and then execute each program by a processor such as a CPU (not illustrated).

The data storage area <NUM> stores the slot setting information <NUM>, the alarm setting information <NUM>, the task information <NUM>, outside recognition information <NUM>, course information <NUM>, state data (for example, error information) <NUM>, and map information <NUM>.

The input/output circuit <NUM> communicates with the outside (for example, various apparatuses, various sensors, and the like, that are connected to the vehicle control device <NUM>) through the in-vehicle network <NUM>, thereby setting the hardware timer <NUM>, and receiving an interrupt request from the hardware timer <NUM>.

(ii) The core <NUM> initialization unit <NUM> executes initialization processing for the computation device (core <NUM>) <NUM>. The slot synchronous processing timing setting unit <NUM> executes processing of adjusting the timing between communication processing executed by the core 1_11 and processing executed by the core 2_12 (for example, sensor fusion processing, dynamic map generation processing, and course generation processing are included). The alarm processing unit <NUM> executes processing of setting a timer in such a manner that an interrupt process is executed in the timing set by the slot synchronous processing timing setting unit <NUM>. The slot synchronous read processing unit <NUM> executes processing of reading predetermined data stored in the shared data buffer (the data storage area) <NUM> at the time set by the alarm processing unit <NUM>. The slot synchronous write processing unit <NUM> executes processing of writing predetermined data to the shared data buffer (the data storage area) <NUM> at the time set by the alarm processing unit <NUM>. The priority scheduling unit <NUM> executes processing of scheduling, on the basis of a priority, processing to be executed in an interrupt slot (an available slot) (including an interrupt process and time division processing). The transmission processing unit <NUM> executes processing of transmitting each data saved in the shared data buffer <NUM> to the core 2_12. The reception interrupt processing unit <NUM> executes processing of storing the outside recognition information <NUM> in a temporary buffer of the core 1_11 through the in-vehicle network <NUM>. It should be noted that the temporary buffer may be the temporary buffer of the core 2_12, or may be the temporary buffer in the memory <NUM> if the temporary buffer is provided in the memory <NUM>.

The core <NUM> initialization unit <NUM> executes initialization processing for the computation device (core <NUM>) <NUM>. The slot setting unit <NUM> reads the slot setting information <NUM> at the time of initialization processing, and then executes processing of recognizing a configuration of a slot. The sensor fusion unit <NUM> obtains external information by various sensors (for example, a camera and a radar), and executes processing of recognizing a forward state on the basis of each piece of external information. The dynamic map generation unit <NUM> executes processing of reflecting the forward state recognized by the sensor fusion unit <NUM> in the map information. The course generation unit <NUM> executes processing of determining an applicable course on the basis of information related to the forward state obtained by the sensor fusion unit <NUM>. The time-driven scheduling unit <NUM> executes processing of switching a slot.

<FIG> is a drawing illustrating a configuration example of the slot setting information <NUM> according to the present embodiment. The slot setting information <NUM> includes, as configuration items, a SID <NUM>, slot start time <NUM>, slot end time <NUM>, and a TID <NUM>.

The SID <NUM> is identification information (ID) that is capable of uniquely identifying/specifying a slot.

The slot start time <NUM> is information that indicates the start time of each slot in units of ms.

The slot end time <NUM> is information that indicates the end time of each slot in units of ms. It should be noted that in the present embodiment, although the time is represented in units of ms, the representation of the time is not limited to this.

The TID <NUM> is identification information (ID) that is capable of uniquely identifying/specifying a task to be executed. It should be noted that in the present embodiment, although only one task is assigned to one slot, the task assignment is not limited to this. For example, two or more tasks may be assigned to one slot.

In addition, in the present embodiment, a system cycle of <NUM> is assumed. In other words, when the time progresses up to <NUM>, the time returns to <NUM>. Here, although the system cycle is <NUM>, the system cycle is not limited to this. For example, the system cycle may be <NUM> or <NUM>. Moreover, the TID <NUM> having a value of "-" means an available slot.

In the present embodiment, available slot information is described in the slot setting information <NUM>. However, it is not always necessary to describe the available slot information in the slot setting information <NUM>. In such a case, an available slot can be searched for by checking the time to which a slot is not assigned, or a slot to which a task is not assigned, in a system cycle.

<FIG> is a drawing illustrating a configuration example of the alarm setting information <NUM> according to the present embodiment. The alarm setting information <NUM> includes, as configuration items, an AID <NUM>, an offset <NUM>, a cycle <NUM>, and a TID <NUM>.

The AID <NUM> is identification information (ID) that is capable of uniquely identifying/specifying an alarm. Here, the alarm is a service provided by an operating system. Processing in which a hardware timer interrupt is caused to occur at the specified time to execute a specific task is assumed.

The offset <NUM> is information that represents a deviation from the reference time of the alarm time. For example, an offset value of <NUM> represents the time advanced by <NUM> from <NUM>.

The cycle <NUM> represents a cycle in which an alarm is set again. For example, in a case where the offset is <NUM> and the cycle is <NUM>, a hardware timer interrupt occurs at <NUM> in a <NUM> cycle. This means that an alarm is set in such a manner that an alarm is generated in the <NUM> cycle.

The TID <NUM> indicates a task ID of a task executed by an alarm.

According to an example shown in <FIG> ms (when the SID <NUM> is <NUM>: refer to <FIG>), a task <NUM> (slot synchronous read processing) is subjected to interrupt processing; and at <NUM>, a task <NUM> (slot synchronous write processing) is subjected to interrupt processing.

<FIG> is a drawing illustrating a configuration example of the task information <NUM> according to the present embodiment. The task information <NUM> includes, as configuration information, a TID <NUM>, a core <NUM>, a cycle <NUM>, a priority <NUM>, and a task name <NUM>.

The TID <NUM> is task identification information (ID) that is capable of uniquely identifying/specifying a task.

The core <NUM> is identification information (ID) of a core that executes the target TID <NUM>. For example, if the core <NUM> has a value of <NUM>, this means that a task corresponding to the target TID <NUM> or an interrupt process is executed by the computation device (the core <NUM>) <NUM>.

The cycle <NUM> is information that indicates an execution cycle of a target task. A task having a number in the corresponding column is a cyclic task. A task having no cycle number is a task executed only at the time of initialization, an interrupt process started on receipt of an interrupt request, or a task or an interrupt process that is started by a specific timer interrupt. Incidentally, in the present embodiment, all of processes taken charge of by the core 2_12 are cyclic tasks (processes executed by time division), and processes taken charge of by the core 1_11 are interrupt processes with the exception of transmission processing.

The priority <NUM> is information that indicates a priority of a task or an interrupt process. In the present embodiment, it is indicated that the priority gets higher with the decrease in number. In a case where a plurality of tasks or interrupt processes are executed at the same time of day, the priority scheduling unit <NUM> executes one in which the priority <NUM> is higher. For example, in the case of a process to be executed by time division, it is not always necessary to set information of the priority <NUM>.

The task name <NUM> indicates a name of a task. It should be noted that as task names, core <NUM> initialization means the core <NUM> initialization unit <NUM>, transmission processing means the transmission processing unit <NUM>, reception interrupt processing means the reception interrupt processing unit <NUM>, slot synchronous read processing means the slot synchronous read processing unit <NUM>, slot synchronous write processing means the slot synchronous write processing unit <NUM>, core <NUM> initialization means the core <NUM> initialization unit <NUM>, sensor fusion means the sensor fusion unit <NUM>, dynamic map generation means the dynamic map generation unit <NUM>, and course generation means the course generation unit <NUM>.

<FIG> is an operation explanatory drawing illustrating an outline of overall processing according to the present embodiment. In <FIG>, a solid line indicates a flow of data, and a dotted line indicates a flow of execution of processing.

When a system is started up, the core <NUM> initialization unit <NUM> of the core 1_11 is first executed. Next, the core <NUM> initialization unit <NUM> of the core 2_12 and the slot synchronous processing timing setting unit <NUM> are executed.

The slot synchronous processing timing setting unit <NUM> refers to the slot setting information <NUM> to detect an available slot. Subsequently, the slot synchronous processing timing setting unit <NUM> saves task contents in the alarm setting information <NUM> in such a manner that a process (task) that is desired to be executed can be executed at the time of the detected available slot, and then calls the alarm processing unit <NUM>.

The alarm processing unit <NUM> sets the time in the hardware timer <NUM> in such a manner that a specific process is executed at the time described in the alarm setting information <NUM>.

The priority scheduling unit <NUM> executes a task to be executed by the core 1_11, or an interrupt process, on the basis of a priority. Processing to be executed by the core 1_11 corresponds to the transmission processing unit <NUM>, the reception interrupt processing unit <NUM>, the slot synchronous read processing unit <NUM>, and the slot synchronous write processing unit <NUM>. Incidentally, since requests of all interrupt processes are not always made, interrupt requests that are being issued at that point of time, and processes (time division processes) that should be cyclically executed, are scheduled on the basis of priorities. If no interrupt request is made, only transmission processing that is cyclically executed is scheduled.

The slot synchronous read processing unit <NUM> and the slot synchronous write processing unit <NUM> are started by the hardware timer <NUM> set by the alarm processing unit <NUM>. The priority scheduling unit <NUM> executes processes thereof on the basis of the priority <NUM> described in the task information <NUM>.

The core <NUM> initialization unit <NUM> of the core 2_12 calls the slot setting unit <NUM>. The slot setting unit <NUM> performs settings of the hardware timer <NUM> in such a manner that the time-driven scheduling unit <NUM> is executed on the basis of the slot setting information <NUM>.

The time-driven scheduling unit <NUM> is started by the hardware timer <NUM>, and executes a process corresponding to a slot. In the present embodiment, the sensor fusion unit <NUM>, the dynamic map generation unit <NUM>, and the course generation unit <NUM> are executed by the time-driven scheduling unit <NUM>.

The operation of each processing unit shown in <FIG> will be described in detail below.

<FIG> is a flowchart illustrating processing contents of the core <NUM> initialization unit <NUM> according to the present embodiment. Here, processing contents are explained using the core <NUM> initialization unit <NUM> as an operation entity. However, since the core <NUM> initialization unit <NUM> is a program executed by the core 1_11, the core 1_11 or a processor included in the core 1_11 may be used as an operation entity. The same applies to the slot synchronous read processing unit <NUM>, the slot synchronous write processing unit <NUM>, the priority scheduling unit <NUM>, the transmission processing unit <NUM>, and the reception interrupt processing unit <NUM> described below.

The core <NUM> initialization unit <NUM> starts the core 2_12.

The core <NUM> initialization unit <NUM> initializes software executed by the core 1_11, and a microcomputer register associated therewith.

The core <NUM> initialization unit <NUM> calls the slot synchronous processing timing setting unit <NUM> so as to perform start settings of a process to be executed in synchronization with a slot. Further details of step <NUM> will be explained in <FIG>.

<FIG> is a flowchart illustrating, in detail, processing (step <NUM>) by the slot synchronous processing timing setting unit <NUM>. Since this processing is included in the initialization processing, the processing is executed only once at the time of initialization.

The slot synchronous processing timing setting unit <NUM> detects an available slot from the slot setting information <NUM>. For example, in the present embodiment, a slot, the SID <NUM> of which is <NUM>, has no registered task in the TID <NUM>, and therefore it is shown that the slot is an available slot. In the present embodiment, although an obvious available slot is clearly shown in the slot setting information <NUM>, an available slot is not limited to this. For example, the time of a slot in which no task is executed is calculated from a system cycle, and from information of the SID <NUM> from <NUM> to <NUM>, and the slot may be determined to be an available slot.

In order to start a task corresponding to a slot at the time of the available slot, the slot synchronous processing timing setting unit <NUM> calls the alarm processing unit <NUM> with the task ID corresponding to the start time of the available slot used as an argument, and causes the alarm processing unit <NUM> to execute time setting processing.

<FIG> is a flowchart illustrating, in detail, processing (step <NUM>) by the alarm processing unit <NUM>.

The alarm processing unit <NUM> sets the time in the hardware timer <NUM> in such a manner that the task ID corresponding to the time, which is the argument, starts.

<FIG> is a flowchart illustrating, in detail, processing by the slot synchronous read processing unit <NUM>.

The slot synchronous read processing unit <NUM> is started by the hardware timer <NUM>, and replicates the course information <NUM> stored in the shared data buffer (the data storage area) <NUM> to a temporary buffer of the core 1_11. The course information <NUM> is generated by the core 2_12 (the course generation unit <NUM>), and is stored in the shared data buffer <NUM>. Subsequently, the core 1_11 outputs the course information <NUM> that has been taken into the temporary buffer to the in-vehicle network <NUM> by transmission processing. It should be noted that the temporary buffer may be the temporary buffer of the core 2_12, or may be the temporary buffer in the memory <NUM> if the temporary buffer is provided in the memory <NUM>.

<FIG> is a flowchart illustrating, in detail, processing by the slot synchronous write processing unit <NUM>.

The slot synchronous write processing unit <NUM> is started by the hardware timer <NUM>, and stores the outside recognition information <NUM> saved in a temporary buffer of the core 1_11 in the shared data buffer (data storage area) <NUM>. In other words, although the outside recognition information (sensing data) <NUM> is obtained by various sensors (a camera and a radar: not illustrated), this information is obtained through the in-vehicle network <NUM>, is written to the temporary buffer of the core 1_11, and is then stored in the shared data buffer <NUM>.

<FIG> is a flowchart illustrating, in detail, processing by the priority scheduling unit <NUM>.

The priority scheduling unit <NUM> determines a schedule of a task to be executed on the basis of the priority <NUM> of the task information <NUM>, and instructs a corresponding processing unit (for example, in the case of transmission processing, the transmission processing unit <NUM>, and in the case of reception interrupt processing, the reception interrupt processing unit <NUM>, etc.) to carry out the execution in such a manner that each processing is executed on the basis of the schedule.

<FIG> is a flowchart illustrating, in detail, processing by the transmission processing unit <NUM>.

The transmission processing unit <NUM> transmits the course information <NUM> currently saved in the temporary buffer of the core 1_11 to the outside (for example, other ECUs or inspection devices, etc.) of the vehicle control device <NUM> through the in-vehicle network <NUM>.

The transmission processing unit <NUM> transmits the state data <NUM> currently saved in the temporary buffer of the core 1_11 to the outside (for example, other ECUs or inspection devices, etc.) of the vehicle control device <NUM> through the in-vehicle network <NUM>.

<FIG> is a flowchart illustrating, in detail, processing by the reception interrupt processing unit <NUM>.

The reception interrupt processing unit <NUM> copies the outside recognition information <NUM> from a mail box of the in-vehicle network <NUM> (for example, CAN) to the temporary buffer of the core 1_11. At this point of time, the reception interrupt processing unit <NUM> gives, to the outside recognition information <NUM>, information (time stamp) of the time at which copying has been carried out, before storing the outside recognition information <NUM> in the temporary buffer. The information of the time is used by the sensor fusion unit <NUM>. It should be noted that the temporary buffer may be the temporary buffer of the core 2_12, or may be the temporary buffer in the memory <NUM> if the temporary buffer is provided in the memory <NUM>.

Taking the sensor fusion unit <NUM> as an example, an obtainment time axis of the outside recognition information <NUM> obtained by a camera or a radar differs from a processing time axis of the sensor fusion unit <NUM>. However, performing computation without aligning the different time axes to each other results in existence of two vehicles, and therefore it is necessary to align the outside time axis to the inside time axis. Accordingly, a time stamp is given when the outside recognition information <NUM> is received, which enables to treat information as data on the same time axis.

<FIG> is a flowchart illustrating, in detail, processing by the core <NUM> initialization unit <NUM>. Here, processing contents are explained using the core <NUM> initialization unit <NUM> as an operation entity. However, since the core <NUM> initialization unit <NUM> is a program executed by the core 2_12, the core 2_12 or a processor included in the core 2_12 may be used as an operation entity. The same applies to the sensor fusion unit <NUM>, the dynamic map generation unit <NUM>, the course generation unit <NUM>, and the time-driven scheduling unit <NUM> described below.

The core <NUM> initialization unit <NUM> initializes software used by the core <NUM>, and a microcomputer register related thereto.

In order to set a slot, the core <NUM> initialization unit <NUM> calls the slot setting unit <NUM>, and instructs the slot setting unit <NUM> to execute slot setting processing.

<FIG> is a flowchart illustrating, in detail, processing by the slot setting unit <NUM>. Since this processing is included in the initialization processing, the processing is executed only once at the time of initialization.

On the basis of the slot setting information <NUM>, the slot setting unit <NUM> sets, in the hardware timer <NUM>, the time at which the first slot is executed.

<FIG> is a flowchart illustrating, in detail, processing by the sensor fusion unit <NUM>.

The sensor fusion unit <NUM> is started in synchronization with a corresponding slot, reads the outside recognition information <NUM> stored in the shared data buffer <NUM>, and increases the accuracy of the outside recognition information on the basis of a fusion algorithm. In other words, the detection accuracy is enhanced by using a plurality of kinds of information obtained by a plurality of sensors such as a camera (that is suitable for recognizing a size of an object), and a radar (that is suitable for recognizing a distance from the object).

<FIG> is a flowchart illustrating, in detail, processing by the dynamic map generation unit <NUM>.

The dynamic map generation unit <NUM> is started in synchronization with a corresponding slot. The dynamic map generation unit <NUM> maps position information of an object, which is indicated by the outside recognition information <NUM>, to the map information <NUM> so as to enable understanding of the properties and distance of the object, the predicted operation thereof, and the like.

<FIG> is a flowchart illustrating, in detail, processing by the course generation unit <NUM>.

The course generation unit <NUM> is started in synchronization with a corresponding slot. The course generation unit <NUM> generates a traveling course of an own vehicle on the basis of dynamic map information generated by the dynamic map generation unit <NUM>, and then saves the traveling course in the course information <NUM> of the shared data buffer <NUM>.

<FIG> is a flowchart illustrating, in detail, processing by the time-driven scheduling unit <NUM>.

The time-driven scheduling unit <NUM> determines whether or not a current task executed in the slot is still being executed at a point of time at which the slot to be checked ends. In a case where the task has ended (in the case of Yes in step <NUM>), the processing proceeds to step <NUM>. In a case where the task is still being executed (in the case of No, in step <NUM>), the processing proceeds to step <NUM>.

The time-driven scheduling unit <NUM> instructs a corresponding processing unit (for example, the course generation unit <NUM>, etc.) to execute a task that should be started at the current time.

The time-driven scheduling unit <NUM> stores error information in the state data <NUM> of the shared data buffer <NUM>, and causes a target task to restart (recover). The timing of restarting can be, for example, the start time of the corresponding slot in the next cycle.

In the present embodiment, in a case where the task is still being executed when the slot ends, error information is saved, and the task that is being executed is restarted. However, the method is not limited to this. For example, merely forcibly terminating the task also suffices. Alternatively, after the error information is saved, the task may be continuously executed in the next slot. Moreover, the task may be continuously executed in the next slot without saving the error information. This method is used when one task is executed over a plurality of slots.

The time-driven scheduling unit <NUM> sets, in the hardware timer <NUM>, the time at which the next slot is executed.

<FIG> is a timing chart illustrating the timing of each processing executed by the vehicle control device <NUM> according to the present embodiment. In <FIG>, arrows each indicate a flow of data, and are only partially shown for convenience of explanation.

The outside recognition information <NUM> received through the in-vehicle network <NUM> is received by the reception interrupt processing unit <NUM> of TID:<NUM> (T2: interrupt process), and is saved in the temporary buffer (the temporary buffer in the core 1_11, the temporary buffer in the core 2_12 or the temporary buffer in the memory <NUM>).

The slot synchronous write processing unit <NUM> of TID:<NUM> is started in an available slot, and copies the outside recognition information <NUM> from the temporary buffer to the shared data buffer <NUM>.

The outside recognition information <NUM> is processed by the sensor fusion unit <NUM> of TID:<NUM>, and the computation result is referred to by the dynamic map generation unit <NUM> of TID:<NUM>. In addition, the course generation unit <NUM> of TID:<NUM> saves the course information <NUM> in the shared data buffer <NUM> on the basis of dynamic map information.

The slot synchronous read processing unit <NUM> of TID:<NUM> copies the course information <NUM> stored in the shared data buffer <NUM> to the temporary buffer of the core 1_11.

In addition, in the transmission processing of TID:<NUM>, the transmission processing unit <NUM> transmits the course information <NUM> to other ECUs or inspection devices through the in-vehicle network <NUM>. It should be noted that although the course information <NUM> is directly saved from the core 2_12 in the shared data buffer <NUM> in the present embodiment, the method is not limited to this. For example, the course information <NUM> may be saved in the shared data buffer <NUM> after the course information <NUM> is saved in a temporary saving buffer of the core 2_12 once.

In the first embodiment, time division is realized by time-driven scheduling. However, a method for realizing time division is not limited to the time-driven scheduling. For example, even in the case of priority scheduling, time division can be realized by executing processing so as to avoid overlapping, and by increasing a priority of slot processing to ensure that the processing is executed without fail. By using the start time of a slot as an offset of a task, by defining a size of the slot as a dead line, and by providing a task execution monitoring function of monitoring them, a task that has not ended can be detected at the time of slotting.

For example, <FIG> is a drawing illustrating a configuration example (modified example) of the task information <NUM> used when time division is executed according to priority scheduling even by the core 2_12. In addition, <FIG> is a drawing illustrating a configuration example (modified example) of the alarm setting information <NUM> based on the task setting information <NUM>.

In the task information <NUM> shown in <FIG>, a higher priority (priority <NUM>) in comparison with TID:<NUM> to <NUM> in the task information <NUM> (refer to <FIG>) is newly set. In addition, the start time of a slot is set in an offset <NUM>, and a size of the slot is set in a dead line <NUM>. As described above, information of the dead line <NUM> is used when a slot is set.

Moreover, in the alarm setting information <NUM> shown in <FIG>, AID:<NUM> to <NUM> are added in comparison with the alarm setting information <NUM> (refer to <FIG>) according to the first embodiment.

As described above, the priority scheduling processing enables to realize time division processing.

In the first embodiment, the slot setting information <NUM> (refer to <FIG>) is given. However, the slot setting information may be calculated from the task information when the system is started up. <FIG> is a drawing illustrating the task information <NUM> that includes information of the worst-case execution time (WCET: the longest time required to execute a specific task) of a task according to a modified example. In <FIG>, WCET of tasks having TID:<NUM> to <NUM> respectively are known. Therefore, a slot size is determined so as not to exceed the WCET, and a slot is shifted so as to prevent slots from overlap each other, thereby enabling to automatically generate slot setting information. For example, the core 1_11 or the core 2_12 determines a slot size in such a manner that the slot size becomes a value equivalent to the worst-case execution time + a margin (for example, <NUM>), and continues processing with the slot size fixed to the value. However, in such a case where the worst-case execution time is changed due to, for example, a change of algorithm or the like, a slot size may be set again after restarting the system.

In the first embodiment, the core 1_11 takes charge of the replication processing from the shared data buffer (data storage area) <NUM> to the temporary buffer of the core 1_11. However, a core that takes charge of the replication processing is not limited to the core 1_11. For example, the core 2_12 may carry out the replication processing in an available slot.

In the first embodiment, the core 1_11 stores data saved in the temporary buffer of the core 1_11 in the shared data buffer. However, a core that carries out data storing processing is not limited to the core 1_11. For example, the core 2_12 may carry out the data storing processing in an available slot.

In the first embodiment, in a core that executes time division processing, one task is assigned to one slot. However, the number of slots to which one task is assigned is not limited to one. For example, one task may be assigned to a plurality of slots in a system cycle. In this case, it is necessary to assign a task in a system cycle in such a manner that an executed task does not exceed the last slot. In a case where a task exceeds the last slot, the processing results in an error (a processing time error). In addition, through the in-vehicle network <NUM>, the error is transmitted (notified of) to other control devices (ECU), output devices (for example, a monitor, a meter, etc.), inspection devices or the like, which are connected to the vehicle control device <NUM>.

In the first embodiment, in a core that executes time division processing, one task is assigned to one slot. However, the number of slots to which one task is assigned is not limited to one. For example, a plurality of tasks may be assigned in a slot to which time division processing is assigned, so as to execute processing by priority scheduling.

In the first embodiment, the same hardware timer <NUM> is referred to. Therefore, the time can be synchronized between multiple cores. However, a time synchronization method is not limited to this method.

In the first embodiment, a task is not executed in an available slot. However, a method is not limited to this. Processing is allowed in an available slot so long as write or read processing between cores does not occur in the available slot. Therefore, for example, microcomputer diagnostic processing, or control software that refers to data in the same core to output the result of calculation, may be executed.

While one core is reading data from the shared data buffer <NUM> (while read processing is performed), if another core writes data to the shared data buffer <NUM> by write processing, the data in the shared data buffer <NUM> is changed. Therefore, there is a possibility that read processing will not be properly executed (the read processing is brought into a state in which a bug has occurred in the data). Therefore, in a case where a slot is defined as an available slot, it is essential that the shared data buffer <NUM> is not accessed.

Incidentally, the available slot is a slot to which no time division process is assigned. However, even if a time division process is assigned to a slot, the slot may be treated as an available slot so long as no process in which read processing and write processing are executed is assigned to the shared data buffer <NUM>.

In the first embodiment, only one available slot is provided in a system cycle. However, the number of available slots provided in the system cycle is not limited to one. For example, two or more available slots may be provided.

In the first embodiment, writing and reading of data shared between cores are performed in an available slot. However, a method is not limited to this. Writing and reading of data shared between cores may be performed by finding an available time in units of data accesses, each of which is smaller than a slot, or may be performed over a plurality of slots.

In the first embodiment, the timing in which write processing or read processing is executed for data shared between cores is managed by the hardware timer <NUM>. However, the management of the timing is not limited to this. For example, a timing instruction of data shared between cores may be given from a core of time division.

Since the same hardware timer <NUM> is referred to, the time can be synchronized between multiple cores. However, a time synchronization method is not limited to this method. For example, two hardware timers may be provided so as to synchronize the hardware timers with each other when the system is started up.

The core <NUM> generates data (for example, track information) by predetermined computation. During a time period during which the core <NUM> does not refer to the generated data, the core <NUM> stores the generated data in the shared data buffer as shared data, and then updates the shared data (the operation entity of updating may be the core <NUM>). In addition, the core <NUM> replicates the shared data at the time at which the core <NUM> does not refer to the shared data, and stores the replicated shared data in the temporary buffer area (the operation entity of replication may be the core <NUM>). Configuring the vehicle control device in such a manner enables to execute an interrupt process at the time at which the shared data is not referred to by time division processing (processing that should be cyclically executed (for example, the sensor fusion processing, the dynamic map generation processing, the course generation processing, etc.)). Consequently, the shared data is never rewritten during time division processing. Accordingly, the reliability of the result of the time division processing can be ensured. Incidentally, as the time period during which the core <NUM> does not refer to the shared data, a time period to which time division processing to be executed is not assigned (available slot), a time period during which control processing that does not refer to the shared data is executed (available time in a slot to which time division processing is assigned), or a time period during which microcomputer diagnostic processing is executed, can be mentioned.

With respect to a plurality of tasks executed by an interrupt process, the core <NUM> schedules the execution of each task on the basis of a priority given to each task. This enables to reliably execute an important interrupt process.

When the end time of a slot to which a task subjected to time division processing is assigned is reached, in a case where a task that should end in the slot has not ended, the core <NUM> brings the task that has not ended into a standby state. Subsequently, the core <NUM> causes the task that has not ended to restart in a slot in the next cycle. In this case, an error may be notified. Alternatively, the core <NUM> may cause the task not to restart but to merely end. By configuring the vehicle control device in such a manner, even if a process executed by time division takes the operation time longer than expected at the time of design, with the result that there occurs a situation in which a process does not end within the slot time, the abnormality can be detected, and only the target process can be restarted or ended. In addition, as the result, no influence is exerted on other processes executed by time division. Therefore, the vehicle control device is suitable for an automatic driving system that requires high reliability.

(ii) The present disclosure can also be realized by a software program code that realizes the functions of the embodiments. In this case, a storage medium having the program code recorded therein is provided to a system or a device, and the program code stored in the storage medium is read by a computer (or CPU or MPU) in the system or device. In this case, the functions of the embodiments are realized by the program code per se that has been read from the storage medium, and the program code per se and the storage medium having the same stored therein constitute the present disclosure. As a storage medium that supplies such a program code, for example, a flexible disk, a CD-ROM, a DVD-ROM, a hard disk, an optical disk, a magneto-optical disk, a CD-R, a magnetic tape, a nonvolatile memory card, a ROM or the like is used.

In addition, some or all of the actual processes may be performed by an OS (operating system) and the like running on a computer in accordance with program code instructions, so that the functions of the embodiments can be realized by the processes. Moreover, the program code read from the storage medium may be written to a memory in a computer, and subsequently some or all of the actual processes may be performed by the CPU and the like of the computer in accordance with the program code instructions, so that the functions of the above-described embodiments can be realized by the processes.

Further, a software program code for realizing the function of an embodiment may be delivered via a network, and stored in a storage means, such as a hard disk or memory of a system or device, or in a storage medium such as a CD-RW or a CD-R. At the time of use, the program code stored in the storage means or the storage medium may be read and executed by a computer (or CPU or MPU) in the system or device.

Finally, it is necessary to understand that the processes and technologies described herein are not inherently related to a particular device, and may be implemented by any appropriate combination of components. Further, various general-purpose devices can be used in accordance with the teachings described herein. It may prove beneficial at times to construct a dedicated device to execute the method steps described herein. In addition, various inventions can be formed by appropriate combinations of a plurality of constituent elements disclosed in the embodiments. For example, some of the constituent elements indicated in an embodiment may be deleted. Further, constituent elements from different embodiments may be appropriately combined. While the present disclosure has been described with reference to specific examples, the examples are not intended to limit the invention but are illustrative in all aspects. Those skilled in the present field will recognize that there are a number of combinations of hardware, software, and firmware appropriate for implementing the present disclosure. For example, the described software may be implemented by a wide range of programs or script languages, such as assembler, C/C++, perl, Shell, PHP, and Java (registered trademark).

Claim 1:
A vehicle control device (<NUM>) comprising:
a storage device configured to store various programs for controlling a vehicle; a plurality of computation devices that include a first computation device (<NUM>) and a second computation device (<NUM>), and that read a program from the storage device and execute the program, and
a storage device that stores shared data calculated by the second computation device (<NUM>), wherein
the storage device configured to store various programs for controlling the vehicle includes a first type of computation processing program executed not by time division, and a second type of computation processing program executed by time division,
the first computation device (<NUM>) is configured to execute the first type of computation processing program, and
the second computation device (<NUM>) is configured to execute the second type of computation processing program wherein
in a time period during which the second computation device (<NUM>) does not refer to the shared data, the first computation device (<NUM>) updates the shared data,
the time period during which the second computation device (<NUM>) does not refer to the shared data is a time period to which the second type of computation processing to be executed is not assigned, a time period during which control processing that does not refer to the shared data is executed, or a time period during which microcomputer diagnostic processing is executed, and wherein
when an end time of a slot to which a task subjected to time division processing is assigned is reached, in a case where a task that should end in the slot has not ended, the second computation device (<NUM>) is configured to bring the task that has not ended into a standby state.