JP2021182173A - Vehicle control apparatus - Google Patents

Abstract

To provide a vehicle control apparatus capable of allocating a plurality of functions to a CPU in a well-balanced manner according to the conditions of a vehicle.SOLUTION: Processing S1 to S8 by a processing load management unit and processing by a processing execution unit are performed repeatedly, and execution cycles and execution priority of a collision damage reduction brake task and a false start suppression control task are adjusted. Thereby, calculation loads of each of functions are adjusted according to the conditions of a vehicle such as a vehicle speed such that a total calculation load of each of the functions is within a range of a tolerance calculation load of a CPU, and each of the functions are allocated to the CPU in a well-balanced manner.SELECTED DRAWING: Figure 4

Description

The present invention relates to a vehicle control device.

In recent years, as an autonomous vehicle, a vehicle control device that assists the driver's driving has been developed. For example, as a driving support function mounted on a vehicle control device, there is known a function of automatically traveling with the vehicle speed at the time of switch operation as the cruise set speed when the driver operates a predetermined switch while driving. Further, when it is difficult to avoid a collision with a preceding vehicle, a stopped vehicle, a falling object, etc. located in front of the vehicle, a function of automatically operating a brake to reduce damage at the time of a collision is known. However, in a vehicle control device equipped with these a plurality of functions, the processing load of the CPU of the vehicle control device becomes a problem as each function becomes bloated.

Patent Document 1 discloses a technique for suppressing unnecessary processing and power consumption by waking up only an application task related to the wake-up factor and not waking up another application task at the time of wake-up due to an external factor. Has been done.

Japanese Unexamined Patent Publication No. 2008-107914

However, in the technique described in Patent Document 1, control of the processing load of the entire CPU is not considered in a state where all application tasks are awakened, and a plurality of functions can be allocated to the CPU in a well-balanced manner. Can not.

In order to solve the above problems, the vehicle control device according to the present invention includes a control unit that controls a plurality of functions of the vehicle, and the required processing load of the plurality of functions differs depending on the state of the vehicle. The processing load of each function is adjusted according to the state of the vehicle so that the total processing load of the plurality of functions is within the allowable processing load of the CPU.

According to the present invention, a plurality of functions can be assigned to the CPU in a well-balanced manner according to the state of the vehicle.

It is a block diagram which shows the whole structure of a vehicle control device. It is a figure which shows the task which executes each function in 1st Embodiment. It is a processing load table which shows the relationship between the vehicle speed and the target processing load of each function in 1st Embodiment. It is a flowchart which shows the process by a process load management part. It is a figure which shows the relationship between the execution cycle and the execution priority. It is a flowchart which shows the process by a process execution part. It is a figure which shows the relationship between a vehicle speed and a processing load. It is a figure which shows the relationship between a vehicle speed and a processing load. It is a flowchart of the processing load management in 1st Embodiment. It is a figure which shows the task which executes each function in 2nd Embodiment. It is a figure explaining the detection of the obstacle at a short distance. It is a figure explaining the detection of the obstacle at a medium distance. It is a figure explaining the detection of the obstacle at a long distance. It is a processing load table which shows the relationship between the distance to the front obstacle and the target processing load of each function in 2nd Embodiment. It is a flowchart of processing load management in 2nd Embodiment. It is a figure which shows the task which executes each function in 3rd Embodiment. It is a figure explaining the route generation from a lane. It is a figure explaining the route generation from the preceding vehicle locus. It is a processing load table which shows the relationship between the recognition rate of a lane, the recognition rate of a preceding vehicle, and the target processing load of each function in 3rd Embodiment. It is a flowchart of the processing load management in 3rd Embodiment. It is a figure which shows the task which executes each function in 4th Embodiment. It is a figure explaining the driver who concentrates on driving. It is a figure explaining the driver who is not concentrating on driving. It is a processing load table which shows the relationship between the driver concentration state and the target processing load of each function in 4th Embodiment. It is a flowchart of the processing load management in 4th Embodiment. It is a figure which shows the task which executes each function in 5th Embodiment. It is a figure explaining the own vehicle traveling at a position approaching a curve. It is a figure explaining the own vehicle traveling on a curve. It is a figure explaining the own vehicle traveling at a position away from a curve. It is a processing load table which shows the relationship between the distance to a curve and the target processing load of each function in 5th Embodiment. It is a flowchart of the processing load management in 5th Embodiment. It is a figure explaining the own vehicle traveling in the central lane of a road. It is a figure explaining the own vehicle traveling in the right lane of a road. It is a figure explaining the own vehicle traveling in the left lane of a road. It is a figure which shows the task which executes each function in 6th Embodiment. 6 is a processing load table showing the relationship between the traveling lane and the target processing load of each function in the sixth embodiment. 6 is a flowchart of processing load management in the sixth embodiment.

Hereinafter, embodiments of the present invention will be described with reference to the drawings. In the present embodiment, an example of providing driving support for an automobile as a vehicle control device will be described. However, the present invention can also support the running of a moving body other than an automobile.

The vehicle control device 1 according to the present embodiment has a plurality of functions such as automatically driving the vehicle to a preset destination and providing driving support for avoiding the danger of the vehicle, as will be described in detail later. It includes a control unit (processing load measuring unit 121, processing load management unit 122, processing execution unit 123) to be controlled. The required calculation load differs depending on the state of the vehicle for the plurality of functions, and the control unit (processing load measurement unit 121, processing load management unit 122, processing execution unit 123) has the total calculation load of the plurality of functions as the allowable calculation of the CPU 120. The calculation load of each function is adjusted according to the state of the vehicle so as to be within the load range, and each function is allocated to the CPU in a well-balanced manner.

According to the vehicle control device 1 according to the present embodiment, since the processing load of each function can be arbitrarily controlled based on the state of the vehicle, the processing load of the entire function can also be controlled. Therefore, the processing load of the entire function can be reduced, and an inexpensive CPU with low processing performance can be selected.

The state of the vehicle referred to here includes not only the state related to the running of the vehicle such as the vehicle speed, but also the state outside the vehicle, the state of the driver, and the state of the road. The state outside the vehicle includes, for example, the distance to the preceding vehicle, the number of obstacles around the vehicle, and the visibility of the lane. The state of the driver is, for example, the degree of concentration of the driver on driving. As a road condition, for example, there is a curvature of a curve on the course.

[First Embodiment]
The first embodiment will be described with reference to FIGS. 1 to 9.
FIG. 1 is a block diagram showing an overall configuration of the vehicle control device 1. The vehicle control device 1 is provided in the vehicle 21 and supports the traveling of the vehicle 21. The vehicle control device 1 can automatically drive the vehicle 21 to a preset destination. The vehicle control device 1 can also control the vehicle by intervening in the operation of the driver in order to avoid a dangerous state of the vehicle. In the following description, the vehicle 21 provided with the vehicle control device 1 may be referred to as a own vehicle. Note that FIG. 1 shows an example in which the preceding vehicle 20 is traveling in front of the vehicle 21.

As shown in FIG. 1, the vehicle control device 1 includes an input device 11, an automatic driving control device 12, and an output device 13.
The input device 11 is a device for acquiring various information about the traveling environment. The input device 11 includes, for example, an outside vehicle environment acquisition unit 111, a traveling state acquisition unit 112, a physical condition acquisition unit 113, and a road information acquisition unit 114. The input device 11 is connected to the automatic driving control device 12, and is a general term for information acquired by the vehicle exterior environment acquisition unit 111, the traveling state acquisition unit 112, the physical condition acquisition unit 113, and the road information acquisition unit 114, respectively. Then, what is called vehicle state information is output to the automatic driving control device 12.

The vehicle outside environment acquisition unit 111 acquires information on the surrounding environment of the vehicle 21. The vehicle-mounted environment acquisition unit 111 uses, for example, an in-vehicle device such as a vehicle-to-vehicle communication device, a road-to-vehicle communication device, a camera, a 77 GHz radar, a 24 GHz radar, a short-distance rider, a long-distance rider, and a sonar sensor (all not shown). By processing the environmental condition information obtained from these devices, the vehicle outside environment acquisition unit 111 can acquire, for example, the position information, speed information, position information of obstacles on the course, and speed information of other vehicles. .. It is also possible to directly output the environmental status information before processing.

The vehicle exterior environment acquisition unit 111 includes a function of detecting a lane on the road and calculating a lane recognition rate mainly by using a sensor device such as a camera for acquiring image information. Further, the vehicle exterior environment acquisition unit 111 includes a function of detecting the preceding vehicle 20 and calculating the preceding vehicle recognition rate by using a sensor device that detects an object such as a camera, a radar, or a rider.

The traveling state acquisition unit 112 functions as a means for acquiring the traveling state of the own vehicle such as the position information, the traveling direction information, and the speed information of the vehicle 21, for example. As the traveling state acquisition unit 112, for example, a GPS (Global Positioning System), a gyro sensor, an acceleration sensor, a wheel speed sensor, or the like is used. GPS acquires the position information of the vehicle 21. The gyro sensor and the acceleration sensor acquire the traveling direction of the vehicle 21. The wheel speed sensor is attached to, for example, the wheel portion of the vehicle 21 and acquires the wheel speed of the vehicle 21.

The physical condition acquisition unit 113 functions as a means for acquiring the physical condition of the driver who manually drives the vehicle 21. As the physical condition acquisition unit 113, for example, a torque sensor attached to the shaft of the steering handle, a center of gravity sensor attached to the driver's seat, a driver monitor camera attached to the driver, and the like are used. The torque sensor detects the state in which the driver has let go of the steering wheel. The center of gravity sensor detects the posture of the driver. The driver monitor camera detects the driver's line of sight. As the physical condition acquisition unit 113, a biological information sensor that detects the driver's biological information such as the driver's electrocardiogram, heart rate, blood pressure, muscle movement (myoelectric potential), and sweating amount may be used. The biometric information sensor can be provided, for example, in the steering.

The road information acquisition unit 114 acquires, for example, road network information composed of nodes and links, traffic rule information, and traffic safety facility information. The road network information includes road structure information such as detailed node information (crossroads, T-junctions, etc.) and detailed link information (number of lanes, shape, etc.). Traffic rule information refers to a concept that includes not only traffic regulations but also traffic manners that are generally shared by the world. Traffic safety facility information refers to equipment such as traffic lights and road signs that are intended to be visually recognized by the driver for traffic safety. The road information acquisition unit 114 may acquire such information from a storage medium for storing the information as needed, or may acquire the information from a server on the network as needed.

The automatic driving control device 12 performs information processing related to traveling control. In addition to the CPU 120, the automatic operation control device 12 is mainly composed of a computer including a ROM and a RAM (not shown), and includes, for example, a processing load measuring unit 121, a processing load management unit 122, and a processing execution unit 123. The processing load measuring unit 121, the processing load management unit 122, and the processing execution unit 123 are collectively referred to as a control unit. The CPU 120 may be a single core or a multi-core.

The program shown in the flowchart described later can be executed by a computer equipped with a CPU 120, a memory, and the like. All processing or some processing may be realized by a hard logic circuit. Further, this program can be previously stored and provided in the storage medium of the vehicle control device 1. Alternatively, the program may be stored and provided in an independent storage medium, or the program may be recorded and stored in the storage medium of the vehicle control device 1 by a network line. It may be supplied as a computer-readable computer program product in various forms such as a data signal (carrier wave).

The automatic driving control device 12 calculates a control command value for controlling the running of the vehicle 21 based on various information input from the input device 11, and outputs the control command value to the output device 13. The control command value referred to here provides information to the driver via a display (meter, speaker, etc.) in addition to control information that changes the physical state such as driving / braking of the vehicle 21 via an actuator. Signal information is also included.

The processing load measuring unit 121 measures the processing load of the CPU 120 and each function. The processing load measurement unit 121 may use, for example, the processing load measurement function provided by the OS, or may use the processing load measurement variables uniquely woven into the program by the software developer.

The processing load management unit 122 manages the processing load of the function executed by the processing execution unit 123 based on the vehicle state information acquired from the input device 11.

The processing execution unit 123 uses the value acquired from the input device 11 to execute functions in automatic driving and driving support of the vehicle. Execution of the function referred to here means determining a control command value to be output to the output device 13. The process execution unit 123 drives a periodic execution task that executes the process of each function. Each cycle execution task executes the process registered in each cycle based on the execution cycle and execution priority set for each.

As shown in FIG. 1, the output device 13 includes a display output unit 131 and a travel control unit 132. The output device 13 is connected to the automatic driving control device 12, and receives a control command value output from the automatic driving control device 12 to control the display output unit 131 and the traveling control unit 132.

The display output unit 131 provides various information such as speed limit and lane departure warning to the occupants of the vehicle 21 including the driver. The display output unit 131 is, for example, an instrument panel, a display, a speaker, or the like arranged near the driver's seat of the vehicle 21. The display may be a head-up display. Alternatively, a mobile phone held by the occupant, a mobile information terminal including a so-called smartphone, a tablet-type personal computer, or the like may be used as a part or all of the display output unit 131.

The travel control unit 132 controls the travel of the vehicle 21 based on the control command value input from the automatic driving control device 12. The travel control unit 132 is composed of, for example, various actuators installed for changing the steering angle, acceleration / deceleration, and braking pressure of the vehicle 21, and a control unit (all not shown) for driving each of these actuators. ..

Examples of the actuator include a steering actuator that applies steering torque, an actuator that adjusts the opening degree of the throttle valve of the engine, a brake actuator that adjusts the brake oil pressure, and the like.

Next, the control of the processing load of the function in the automatic operation control device 12 will be described.
FIG. 2 is a diagram showing a task of executing each function in the first embodiment. This is an execution task driven by the processing execution unit 123 in one cycle. As shown in FIG. 2, the processing execution unit 123 according to the present embodiment drives a collision damage mitigation braking task F1 and an erroneous start suppression control task F2.

For the collision damage mitigation braking task F1, the execution cycle, execution priority, and execution state are set as set values. Furthermore, the registered process is the process of collision damage mitigation brake. The execution cycle, execution priority, and execution state of the erroneous start suppression control task F2 are set as set values. Further, the registered process is a process of erroneous start suppression control. Here, the execution cycle indicates the execution cycle of each function, and the calculation load of the CPU 120 can be increased by shortening the execution cycle of the function. The execution priority indicates the execution priority of each function, and the calculation load of the CPU 120 can be increased by increasing the execution priority of the function. The execution status indicates a status such as "execution" or "execution completed".

Collision damage mitigation braking is a function that detects obstacles such as the preceding vehicle 20 and assists the brakes. When the vehicle speed of the vehicle 21 is high, the time until the vehicle collides with the preceding vehicle 20 is shortened, so that it is actively performed. Operate. In addition, erroneous start suppression control is a function that suppresses acceleration and assists braking when a strong depression of the accelerator is detected while detecting an obstacle, and is actively activated when the vehicle is stopped or the vehicle speed at the time of starting is slow. do.

FIG. 3 is a processing load table T1 showing the relationship between the vehicle speed and the target processing load of each function in the first embodiment. The processing load table T1 is stored in a memory (not shown) in the automatic operation control device 12. In the processing load table T1, the target processing load of the collision damage mitigation brake is 0 or more and less than 10 vehicle speed km / h, 10 or more and less than 30 vehicle speed km / h, and 30 or more vehicle speed km / h. It is divided into the case of h and is set to 15%, 15%, and 60% in each category, respectively. Further, when the target processing load of the false start suppression control is 0 or more and less than 10 vehicle speed km / h, 10 or more and less than 30 vehicle speed km / h, and 30 or more vehicle speed km / h. In each category, it is set to 50%, 10%, and 10%, respectively. The target processing load is based on the case where the maximum value of the processing load of the CPU 120 is 100%.

The target processing load of each function is a value set in advance by the designer, but at this time, it is desirable that the total of the target processing loads is set so as not to exceed the allowable processing load of the CPU 120. In FIG. 3, the total target processing load is 0 or more and less than 10 vehicle speed km / h, 10 or more and less than 30 vehicle speed km / h, and 30 or more vehicle speed km / h. It is set to 65%, 25%, and 70%, respectively. The total target processing load is also a value set in advance by the designer. The total target processing load may be set to 100% so as to make the best use of the performance of the CPU 120, or may be set to a value with a margin of 80%.

FIG. 4 is a flowchart showing processing by the processing load management unit 122. The processing load management unit 122 manages the processing load of each function by executing the processing shown in FIG.

In the process S1 shown in FIG. 4, the process load management unit 122 acquires the execution state of each function from the process execution unit 123. In the next process S2, it is determined whether or not the execution state of the function is "execution completed", and if it is "execution completed", the process proceeds to process S3. In the processing S3, the processing load management unit 122 acquires the current processing load of each function from the processing load measuring unit 121. If the execution state of the function is "execution" in the process S2, the process shown in FIG. 4 is terminated.

Next, in the process S4, the process load management unit 122 acquires the vehicle speed as the current state of the vehicle from the input device 11. Next, in the process S5, the target processing load of each function is calculated from the acquired vehicle speed. The processing load management unit 122 may map the target processing load of each function from the processing load table T1 shown in FIG. 3, or may calculate the target processing load as a function of the vehicle speed. After that, the process proceeds to process S6.

In processing S6, the processing load management unit 122 updates the execution cycle of each function shown in FIG. 2 based on the difference between the target processing load of each function and the current processing load. When the required processing load is higher than the current processing load, the processing load management unit 122 shortens the execution cycle of the collision damage mitigation brake, for example. On the contrary, when the required processing load is lower than the current processing load, the processing load management unit 122 lengthens, for example, the execution cycle of the collision damage mitigation brake.

Next, in the process S7, the process load management unit 122 updates the execution priority of the task shown in FIG. FIG. 5 is a diagram showing the relationship between the execution cycle and the execution priority. As shown in FIG. 5, the horizontal axis represents the execution cycle and the vertical axis represents the execution priority. In this example, the execution priority decreases as the execution cycle becomes longer. The execution priority may be set to a value calculated based on the execution cycle from the correspondence relationship between the execution cycle and the execution priority shown in FIG. Alternatively, the execution cycles of all tasks may be aggregated and the highest priority may be assigned in ascending order of execution cycle.

Next, in the process S8, the process load management unit 122 updates the execution state of the function to "waiting for execution" at the timing when the update of the execution cycle and the execution priority is completed.

FIG. 6 is a flowchart showing the processing by the processing execution unit 123.
In the process S9 shown in FIG. 6, the process execution unit 123 determines whether the elapsed time from the previous execution has reached the execution cycle or more. When it is determined that the execution cycle has been exceeded, the process proceeds to process S10, and the execution state of the function shown in FIG. 2 is updated to "execution". In the next process S11, the process registered in each task shown in FIG. 2 is executed. In the next process S12, the process execution unit 123 updates the execution state of the function to "execution completed" at the timing when the execution of the process is completed.

Processing S1 to processing S8 by the processing load management unit 122 shown in FIG. 4 and processing S12 from processing S9 by the processing execution unit 123 shown in FIG. 6 are repeatedly executed to perform collision damage mitigation braking task F1 and false start suppression control. Adjust the execution cycle and execution priority of task F2. As a result, the calculation load of each function is adjusted according to the state of the vehicle such as the vehicle speed so that the total calculation load of each function is within the allowable calculation load of the CPU 120, and each function is assigned to the CPU in a well-balanced manner.

FIG. 7 is a graph showing the relationship between the vehicle speed and the processing load when the processing load of each function is controlled according to the processing load table T1 shown in FIG. Up to a vehicle speed of 10 km / h, the processing load of the false start suppression control shown by the dotted line in FIG. 7 occupies a large part. When the vehicle speed is 30 km / h or more, the processing load of the collision damage mitigation brake shown by the alternate long and short dash line in FIG. 7 occupies a large part. The total processing load shown by the solid line in FIG. 7 does not exceed the allowable processing load of the CPU 120.

Further, FIG. 8 is a graph showing the relationship between the vehicle speed and the processing load. In the example shown in FIG. 8, the target processing load of each function is used as a function of the vehicle speed to calculate the target processing load in a more detailed stepwise manner. Then, the processing load of each function is controlled accordingly. As a result, the processing load of the collision damage mitigation brake shown by the alternate long and short dash line in FIG. 8 increases as the vehicle speed increases. Further, the processing load of the false start suppression control shown by the dotted line in FIG. 8 decreases as the vehicle speed increases. The total of both processing loads shown by the solid line in FIG. 8 does not exceed the allowable processing load of the CPU 120.

As shown in FIGS. 7 and 8, the processing by the processing load management unit 122 shown in FIG. 4 and the processing by the processing execution unit 123 shown in FIG. 6 increase the false start suppression control in the low speed range and the high speed range. On the contrary, since the processing load of the collision damage mitigation brake increases, the processing load of the CPU 120 can be smoothed.

FIG. 9 is a flowchart of processing load management in the first embodiment. The flowchart shown in FIG. 9 shows the processing executed by the processing load management unit 122. As a premise of this processing, as shown in FIG. 2, a collision damage mitigation braking task and a false start suppression control task are implemented in the processing execution unit 123, and the processing registered in each task is the execution cycle. , It is assumed that the execution is performed according to the execution priority. Further, it is assumed that the target processing load of each function is calculated by drawing a map from the vehicle speed and the processing load table T1 shown in FIG.

In the process S1A of FIG. 9, the process load management unit 122 executes the process load management of the collision damage mitigation brake according to the flowchart described with reference to FIG. After that, in the process S2A, the process load management of the erroneous start suppression control is similarly executed. Here, the processing load management of the collision damage mitigation brake is executed before the processing load management of the false start suppression control, but the processing load management of the false start suppression control is executed before the processing load management of the collision damage mitigation brake. You may.

Next, in the process S3A, the process load management unit 122 acquires the process load of the CPU 120. In the process S4A, the process load management unit 122 determines whether or not the process load of the CPU 120 exceeds the allowable process load. If the allowable processing load is exceeded, the process proceeds to process S5A, and the degenerate processing of the function is performed.

Examples of the degenerate process of the function in the process S5A include compensating the target processing load of each function to a low level, or putting the task to sleep to stop the execution of the process. Further, it may be stored in the non-volatile memory inside the automatic operation control device 12 that the degeneration process has been performed, or the display output unit 131 may notify the driver.

According to the first embodiment, the target processing load of the collision damage mitigation brake and the false start suppression control is set based on the vehicle speed, and the execution cycle and the execution priority of each function are adjusted so as to be the target processing load. By controlling the processing load, the processing load of the CPU 120 can be managed. Therefore, depending on the setting of the target processing load, the processing load of the CPU 120 can be reduced, and an inexpensive CPU 120 having low processing performance can be selected.

In the first embodiment, the collision damage mitigation brake is used as a function of detecting the vehicle speed as the state of the vehicle and increasing the calculation load when the vehicle speed is high, and the erroneous start is performed as a function of increasing the calculation load when the vehicle speed is slow. Suppression control has been described as an example. In addition, the vehicle speed is detected as the state of the vehicle, and when the vehicle speed is high, the calculation load of functions such as cruise control and lane keeping is increased, and when the vehicle speed is slow, the calculation of functions such as automatic parking and electric power steering is performed. The load may be increased.

[Second Embodiment]
A second embodiment will be described with reference to FIGS. 10 to 15. Since the overall configuration of the vehicle control device 1 described with reference to FIG. 1 in the first embodiment is the same in the second embodiment, the description thereof will be omitted. In this embodiment, the difference from the first embodiment will be mainly described.

FIG. 10 is a diagram showing a task of executing each function in the second embodiment. This is an execution task driven by the processing execution unit 123 in one cycle. As shown in FIG. 10, the process execution unit 123 according to the present embodiment has an obstacle recognition task F3 by a short-distance sensor, an obstacle recognition task F4 by a medium-range sensor, and an obstacle recognition task by a long-distance sensor. It is driving F5.

For the obstacle recognition task F3 by the short-distance sensor, the execution cycle, the execution priority, and the execution state are set as set values. Further, the registered process is obstacle recognition by a short-range sensor. For the obstacle recognition task F4 by the medium-range sensor, the execution cycle, the execution priority, and the execution state are set as set values. Further, the registered process is obstacle recognition by the medium range sensor. For the obstacle recognition task F5 by the long-distance sensor, the execution cycle, the execution priority, and the execution state are set as set values. Further, the registered process is obstacle recognition by a long-distance sensor.

FIG. 11 is a diagram simulating a state in which an obstacle in front of the own vehicle is recognized by using a short-distance sensor. Obstacle recognition by the short-distance sensor obtains and processes information such as short-distance rider and sonar sensor from the vehicle exterior environment acquisition unit 111, and obtains position information, speed information, acceleration information, etc. of obstacles in front of the own vehicle. It is a function to acquire. Obstacle recognition by the short-distance sensor needs to be actively activated when the distance between the own vehicle and the obstacle in front is, for example, a short distance of 0 m or more and less than 30 m, as shown in FIG.

FIG. 12 is a diagram simulating a state in which an obstacle in front of the own vehicle is recognized by using a medium-range sensor. For obstacle recognition by the medium-range sensor, for example, information such as a 24GHz radar and a camera is acquired and processed from the vehicle exterior environment acquisition unit 111, and the position information, speed information, acceleration information, etc. of the obstacle in front of the own vehicle are acquired. It is a function to do. Obstacle recognition by the medium-range sensor needs to be actively activated when the distance between the own vehicle and the obstacle in front is, for example, 30 m or more and less than 80 m, as shown in FIG.

FIG. 13 is a diagram simulating a state in which an obstacle in front of the own vehicle is recognized by using a long-distance sensor. Obstacle recognition by the long-distance sensor obtains and processes information such as 77GHz radar and ultra-distance rider from the outside environment acquisition unit 111, and processes the position information, speed information, acceleration information, etc. of the obstacle in front of the own vehicle. It is a function to acquire. Obstacle recognition by the long-distance sensor needs to be actively activated when the distance between the own vehicle and the obstacle in front is, for example, 80 m or more, as shown in FIG.

FIG. 14 is a processing load table T2 showing the relationship between the distance to the front obstacle and the target processing load of each function in the second embodiment. The target processing load of each function is a value set in advance by the designer, but at this time, it is desirable that the total of the target processing loads is set so as not to exceed the allowable processing load of the CPU 120. Further, the allowable processing load of the CPU 120 is also a value set in advance by the designer. The allowable processing load of the CPU 120 may be set to 100% so that the performance of the CPU 120 can be fully utilized, or a value with a margin of 80% may be set.

As shown in FIG. 14, the distance to the front obstacle is classified into a case of 0 m or more and less than 30 m, a case of 30 m or more and less than 80 m, and a case of 80 m or more. The target processing load for obstacle recognition by the short-distance sensor is set to 40%, 20%, and 10% according to the distance classification. The target processing load for obstacle recognition by the medium-range sensor is set to 20%, 40%, and 20% according to the distance classification. The target processing load for obstacle recognition by the long-distance sensor is set to 10%, 20%, and 40% according to the distance classification. The total target processing load is set to 70%, 80%, and 70%.

FIG. 15 is a flowchart of processing load management in the second embodiment. The flowchart shown in FIG. 15 shows the processing executed by the processing load management unit 122. As a premise of this processing, as shown in FIG. 10, the processing execution unit 123 has an obstacle recognition task F3 by a short-distance sensor, an obstacle recognition task F4 by a medium-range sensor, and an obstacle recognition task F5 by a long-distance sensor. Is implemented, and it is assumed that the processes registered in each task are executed according to the execution cycle and execution priority. Further, it is assumed that the target processing load of each function is calculated by drawing a map from the distance to the front obstacle shown in FIG. 11 and the processing load table T2.

In the process S1B of FIG. 15, the process load management unit 122 executes the process load management of obstacle recognition by the short-distance sensor according to the flowchart described with reference to FIG. At this time, in the process S4 shown in FIG. 4, the distance to the front obstacle is acquired as the current state of the vehicle. The distance to the front obstacle may be acquired from the vehicle outside environment acquisition unit 111, or may be acquired from the processing execution unit 123 that is executing each obstacle recognition function.

In the next process S2B, similarly, the process load management of obstacle recognition by the medium-range sensor is executed. Further, in the next processing S3B, similarly, the processing load management of obstacle recognition by the long-distance sensor is executed. The order from process S1B to process S3B does not matter.

Next, in the process S4B, the process load management unit 122 acquires the process load of the CPU 120. In the process S5B, the process load management unit 122 determines whether or not the process load of the CPU 120 exceeds the allowable process load. If the allowable processing load is exceeded, the process proceeds to process S6B to perform degenerate processing of the function. The degenerate process of the function is the same as that of the first embodiment.

According to the second embodiment, the target processing load of each function is set based on the distance to the front obstacle, the execution cycle and execution priority of each function are adjusted so as to be the target processing load, and the processing load is reached. By controlling the above, the processing load of the CPU 120 can be managed. Therefore, depending on the setting of the target processing load, the processing load of the CPU 120 can be reduced, and an inexpensive CPU 120 having low processing performance can be selected.

Further, also in the second embodiment, as described with reference to FIGS. 7 and 8, the total processing load of each function can be controlled so as not to exceed the allowable processing load of the CPU 120.

In the second embodiment, the function of detecting the distance to the front obstacle as the state of the vehicle and increasing the calculation load when the distance to the front obstacle is short, and the case where the distance to the front obstacle is long. Explained an example including a function to increase the calculation load. Then, when the distance to the front obstacle is short, the calculation load of the obstacle recognition function by the short-distance sensor is increased, and when the distance to the front obstacle is long, the obstacle recognition function by the long-distance sensor is increased. The case of increasing the calculation load was explained. In addition, the degree of congestion of the vehicle in front is detected as the state of the vehicle by a camera or the like, and when the degree of congestion is low, the calculation load of functions such as recognition of distant obstacles and improvement of riding comfort is increased, and the degree of congestion is high. In some cases, the computational load of functions such as recognition of near obstacles, route generation, and collision prevention may be increased.

[Third Embodiment]
A third embodiment will be described with reference to FIGS. 16 to 20. Since the overall configuration of the vehicle control device 1 described with reference to FIG. 1 in the first embodiment is the same in the third embodiment, the description thereof will be omitted. In this embodiment, the difference from the first embodiment will be mainly described.

FIG. 16 is a diagram showing a task of executing each function in the third embodiment. This is an execution task driven by the processing execution unit 123 in one cycle. As shown in FIG. 16, the process execution unit 123 according to the present embodiment drives a route generation task F6 from a lane (white line) and a route generation task F7 from a preceding vehicle locus.

For the route generation task F6 from the lane, the execution cycle, the execution priority, and the execution state are set as set values. Further, the registered process is a process of generating a route from a lane (white line). In addition, in this embodiment, a "lane" or a "white line" represents a lane boundary line (partition line) existing on the left and right of the traveling lane of the own vehicle. For the route generation task F7 from the preceding vehicle locus, the execution cycle, the execution priority, and the execution state are set as set values. Further, the registered process is a process of generating a route from the locus of the preceding vehicle.

FIG. 17 is a diagram simulating a lane that can be clearly seen from the front of the own vehicle and a preceding vehicle 20 that can be seen from a distance. Route generation from the lane is a function of generating a route from the lane for automatically driving the own vehicle. As shown in FIG. 17, when the lane recognition rate of 90% is the preceding vehicle recognition rate of 80% or more, it is necessary to actively operate the vehicle.

FIG. 18 is a diagram simulating a lane that appears to disappear from the front of the own vehicle and a preceding vehicle 20 that can be seen from a distance. Route generation from the locus of the preceding vehicle is a function of generating a route for automatically driving the own vehicle from the locus of the preceding vehicle. As shown in FIG. 18, when the lane recognition rate of 30% is less than the preceding vehicle recognition rate of 80%, it is necessary to actively operate the vehicle.

FIG. 19 is a processing load table T3 showing the relationship between the magnitude relationship between the lane recognition rate and the preceding vehicle recognition rate and the target processing load of each function as described above. The target processing load of each function is a value set in advance by the designer, but at this time, it is desirable that the total of the target processing loads is set so as not to exceed the allowable processing load of the CPU 120. Further, the allowable processing load of the CPU 120 is also a value set in advance by the designer. The allowable processing load of the CPU 120 may be set to 100% so that the performance of the CPU 120 can be fully utilized, or a value with a margin of 80% may be set.

As shown in FIG. 19, the lane recognition rate is classified into a case where the lane recognition rate is equal to or higher than the preceding vehicle recognition rate and a case where the lane recognition rate is less than or equal to the preceding vehicle recognition rate. The target processing load for route generation from the lane is set to 50% and 10% according to the classification. The target processing load for route generation from the preceding vehicle locus is set to 10% and 50% according to the classification. The total target processing load is set to 60% and 60%.

FIG. 20 is a flowchart of processing load management according to the third embodiment. The flowchart shown in FIG. 20 shows the processing executed by the processing load management unit 122. As a premise of this processing, as shown in FIG. 16, a route generation task F6 from the lane and a route generation task F7 from the preceding vehicle locus are implemented in the processing execution unit 123, and are registered in each task. It is assumed that the processing is executed according to the execution cycle and the execution priority. Further, the target processing load of each function is calculated by drawing a map from the processing load table T3 shown in FIG. 19 according to the lane recognition rate and the preceding vehicle recognition rate.

In the process S1C of FIG. 20, the process load management unit 122 executes the process load management of route generation from the lane according to the flowchart described with reference to FIG. In the next processing S2C, similarly, the processing load management of route generation from the preceding vehicle locus is executed. At this time, in the process S4 shown in FIG. 4, the lane recognition rate and the preceding vehicle recognition rate are acquired from the outside environment acquisition unit 111 as the current state of the vehicle, and their magnitudes are compared.

Next, in the process S3C, the process load management unit 122 acquires the process load of the CPU 120. In the processing S4C, the processing load management unit 122 determines whether or not the processing load of the CPU 120 exceeds the allowable processing load. If the allowable processing load is exceeded, the process proceeds to process S5C to perform degenerate processing of the function. The degenerate process of the function is the same as that of the first embodiment.

According to the third embodiment, the target processing load of each function is set based on the magnitude relationship between the lane recognition rate and the preceding vehicle recognition rate, and the execution cycle and execution priority of each function are set so as to be the target processing load. By adjusting and controlling the processing load, the processing load of the CPU 120 can be managed. Therefore, depending on the setting of the target processing load, the processing load of the CPU 120 can be reduced, and an inexpensive CPU 120 having low processing performance can be selected.

Further, also in the third embodiment, it is possible to control so that the total processing load of each function does not exceed the allowable processing load of the CPU 120.

[Fourth Embodiment]
A fourth embodiment will be described with reference to FIGS. 21 to 25. Since the overall configuration of the vehicle control device 1 described with reference to FIG. 1 in the first embodiment is the same in the fourth embodiment, the description thereof will be omitted. In this embodiment, the difference from the first embodiment will be mainly described.

FIG. 21 is a diagram showing a task for executing each function in the fourth embodiment. This is an execution task driven by the processing execution unit 123 in one cycle. As shown in FIG. 21, the process execution unit 123 according to the present embodiment drives the driver concentration monitoring task F8 and the driver concentration warning task F9.

For the driver concentration monitoring task F8, the execution cycle, the execution priority, and the execution state are set as set values. Further, the registered process is a driver concentration monitoring process. For the driver concentration warning task F9, the execution cycle, the execution priority, and the execution state are set as set values. Further, the registered process is a driver concentration warning process.

FIG. 22 is a diagram simulating a driver who is concentrating on driving. The driver concentration monitoring function acquires and processes information such as a camera for acquiring a driver's face image, an electrostatic sensor of the steering wheel, and a torque sensor from the physical condition acquisition unit 113, and processes the driver. It is a function to estimate the line of sight and the state of letting go of the driver and acquire the concentration state of the driver. As shown in FIG. 22, when the driver is in a concentrated state, it is necessary to quickly detect that the driver transitions to the non-concentrated state, and therefore it is necessary to actively activate the driver concentration monitoring function.

FIG. 23 is a diagram simulating a driver who is not concentrating on driving. The driver concentration warning function is a function that outputs a warning message or a warning sound from an output device such as a meter or a speaker of the display output unit 131 so that the driver can concentrate on driving. As shown in FIG. 23, when the driver is in a decentralized state, it is necessary to actively activate the driver concentration warning function in order to immediately transition the driver to the concentrated state.

FIG. 24 is a processing load table T4 showing the relationship between the driver concentration state and the target processing load of each function as described above. The target processing load of each function is a value set in advance by the designer, but at this time, it is desirable that the total of the target processing loads is set so as not to exceed the allowable processing load of the CPU 120. Further, the allowable processing load of the CPU 120 is also a value set in advance by the designer. The allowable processing load of the CPU 120 may be set to 100% so that the performance of the CPU 120 can be fully utilized, or a value with a margin of 80% may be set.

As shown in FIG. 24, the driver is classified into a concentrated state and a non-concentrated state. The target processing load for driver concentration monitoring is set to 30% and 10% according to the classification. The target processing load of the driver concentration warning is set to 5% and 20% according to the classification. The total target processing load is set to 35% and 30%.

FIG. 25 is a flowchart of processing load management according to the fourth embodiment. The flowchart shown in FIG. 25 shows the processing executed by the processing load management unit 122. As a premise of this process, as shown in FIG. 21, a driver concentration monitoring task F8 and a driver concentration warning task F9 are implemented in the process execution unit 123, and the processes registered in each task are implemented. , It is assumed that it is executed according to its execution cycle and execution priority. Further, it is assumed that the target processing load of each function is calculated by drawing a map from the processing load table T4 shown in FIG. 24 according to the driver concentration state.

In the process S1D of FIG. 25, the process load management unit 122 executes the process load management of the driver concentration monitoring according to the flowchart described with reference to FIG. In the next processing S2D, similarly, the processing load management of the driver concentration warning is executed. At this time, in the process S4 shown in FIG. 4, the driver's concentration state is acquired from the driver concentration monitoring function executed by the process execution unit 123 as the current state of the vehicle.

Next, in the process S3D, the process load management unit 122 acquires the process load of the CPU 120. In the processing S4D, the processing load management unit 122 determines whether or not the processing load of the CPU 120 exceeds the allowable processing load. If the allowable processing load is exceeded, the process proceeds to the processing S5D, and the degenerate processing of the function is performed. The degenerate process of the function is the same as that of the first embodiment.

According to the fourth embodiment, the target processing load of each function is set based on the concentration state of the driver, the execution cycle and the execution priority of each function are adjusted so as to be the target processing load, and the processing load is set. By controlling, the processing load of the CPU 120 can be managed. Therefore, depending on the setting of the target processing load, the processing load of the CPU 120 can be reduced, and an inexpensive CPU 120 having low processing performance can be selected.

Further, also in the fourth embodiment, it is possible to control so that the total processing load of each function does not exceed the allowable processing load of the CPU 120.

[Fifth Embodiment]
A fifth embodiment will be described with reference to FIGS. 26 to 31. Since the overall configuration of the vehicle control device 1 described with reference to FIG. 1 in the first embodiment is the same in the fifth embodiment, the description thereof will be omitted. In this embodiment, the difference from the first embodiment will be mainly described.

FIG. 26 is a diagram showing a task for executing each function in the fifth embodiment. This is an execution task driven by the processing execution unit 123 in one cycle. As shown in FIG. 26, the process execution unit 123 according to the present embodiment drives the curve front deceleration task F10 and the lane keeping support task F11.

The execution cycle, execution priority, and execution state of the pre-curve deceleration task F10 are set as set values. Further, the registered process is a process of deceleration before the curve. For the lane keeping support task F11, an execution cycle, an execution priority, and an execution state are set as set values. Furthermore, the registered process is a lane keeping support process.

FIG. 27 is a diagram simulating the own vehicle approaching a curve. The pre-curve deceleration function is a driving load reduction function that supports the deceleration operation of the driver before entering the curve based on the road information in front obtained from the road information acquisition unit 114. As shown in FIG. 27, when the own vehicle is approaching a curve, it is necessary to actively activate the pre-curve deceleration function.

FIG. 28 is a diagram simulating the own vehicle traveling on a curve. The lane keeping support function is a function that acquires lane information from the outside environment acquisition unit 111, controls steering so that the own vehicle does not deviate from the lane, and assists in maintaining the lane. As shown in FIG. 28, when the own vehicle is traveling on a curve, it is necessary to actively activate the lane keeping support function.

FIG. 29 is a diagram simulating the own vehicle traveling on a straight road away from a curve. At this time, it is not necessary to actively operate the deceleration function before the curve and the lane keeping support function.

FIG. 30 is a processing load table T4 showing the relationship between the distance to the curve and the target processing load of each function as described above. The target processing load of each function is a value set in advance by the designer, but at this time, it is desirable that the total of the target processing loads is set so as not to exceed the allowable processing load of the CPU 120. Further, the allowable processing load of the CPU 120 is also a value set in advance by the designer. The allowable processing load of the CPU 120 may be set to 100% so that the performance of the CPU 120 can be fully utilized, or a value with a margin of 80% may be set.

The distance to the curve and the processing load table T5 shown in FIG. 30 are classified into the case where the distance to the curve is 500 m or more, the case where the distance is 50 m or more and less than 500 m, and the case where the distance to the curve is less than 50 m or the curve is in progress. .. The target processing load of the pre-curve deceleration function is set to 5%, 50%, and 15% according to each category. The target processing load of the lane keeping support function is set to 5%, 5%, and 60% according to each category. The total target processing load is set to 10%, 55%, and 75%.

FIG. 31 is a flowchart of processing load management according to the fifth embodiment. The flowchart shown in FIG. 31 shows the processing executed by the processing load management unit 122. As a premise of this processing, as shown in FIG. 26, a curve front deceleration task F10 and a lane keeping support task F11 are implemented in the processing execution unit 123, and the processing registered in each task is the execution cycle. , It is assumed that the execution is performed according to the execution priority. Further, the target processing load of each function is calculated by drawing a map according to the distance from the processing load table T5 shown in FIG. 30 to the curve.

In the process S1E of FIG. 31, the process load management unit 122 executes the process load management of deceleration before the curve according to the flowchart described with reference to FIG. In the next processing S2E, similarly, the processing load management of the lane keeping support is executed. At this time, in the process S4 shown in FIG. 4, the distance from the road information acquisition unit 114 to the curve is acquired as the current state of the vehicle.

Next, in the process S3E, the process load management unit 122 acquires the process load of the CPU 120. In the process S4E, the process load management unit 122 determines whether or not the process load of the CPU 120 exceeds the allowable process load. If the allowable processing load is exceeded, the process proceeds to processing S5E, and the function reduction processing is performed. The degenerate process of the function is the same as that of the first embodiment.

According to the fifth embodiment, the target processing load of each function is set based on the distance to the curve, the execution cycle and execution priority of each function are adjusted so as to be the target processing load, and the processing load is controlled. By doing so, the processing load of the CPU 120 can be managed. Therefore, depending on the setting of the target processing load, the processing load of the CPU 120 can be reduced, and an inexpensive CPU 120 having low processing performance can be selected.

Further, also in the fifth embodiment, it is possible to control so that the total processing load of each function does not exceed the allowable processing load of the CPU 120.

[Sixth Embodiment]
A sixth embodiment will be described with reference to FIGS. 32 to 37. Since the overall configuration of the vehicle control device 1 described with reference to FIG. 1 in the first embodiment is the same in the sixth embodiment, the description thereof will be omitted. In this embodiment, the difference from the first embodiment will be mainly described.

FIG. 32 is a diagram illustrating the own vehicle 21 traveling in the central lane L2 of a road having three lanes. FIG. 33 is a diagram illustrating the own vehicle 21 traveling in the right lane L3 of a road having three lanes. FIG. 34 is a diagram illustrating the own vehicle 21 traveling in the left lane L1 of a road having three lanes. As shown in FIGS. 32, 33, and 34, here, the detection area 301 is set in the front FE, the rear BE, the right RE, and the left LE with the own vehicle 21 as the center. The size of the detection area 301 is set based on the maximum detection distance and the detection range of each sensor. In FIGS. 32 to 34, the detection area 301 is set according to each traveling lane as described later. In this case, the detectable obstacle in the detection area 301 is represented by a white square in the detection area 301. Undetectable obstacles outside are indicated by black squares.

FIG. 35 is a diagram showing a task for executing each function in the sixth embodiment. This is an execution task driven by the processing execution unit 123 in one cycle. As shown in FIG. 35, the processing execution unit 123 according to the present embodiment drives an obstacle detection task F12 in the front region, an obstacle detection task F13 in the right side region, and an obstacle detection task F14 in the left side region. ing.

The obstacle detection task F12 in the front area has a detection area and an execution state set as set values, and the registered process is obstacle detection in the front area. Here, the detection area is the area of the front area that can be detected, and the number of calculation repetitions in one cycle is set in proportion to this area. The obstacle detection task F13 in the right side region has a detection area and an execution state set as set values, and the registered process is obstacle detection in the right side region. Here, the detection area is the area of the right side area that can be detected, and the number of calculation repetitions in one cycle is set in proportion to this area. The obstacle detection task F14 in the left side region has a detection area and an execution state set as set values, and the registered process is obstacle detection in the left side region. Here, the detection area is the area of the left side area that can be detected, and the number of calculation repetitions in one cycle is set in proportion to this area.

The obstacle detection function in the front area is a function for detecting the presence or absence of an obstacle existing in the front area of the own vehicle based on sensor information such as a camera, a millimeter wave radar, or a radar mounted in front of the vehicle.

The obstacle detection function in the left side area detects the presence or absence of obstacles in the left side area of the own vehicle based on sensor information such as a camera, millimeter wave radar, radar, and sonar sensor mounted on the left side of the vehicle. It is a function to do.

The obstacle detection function in the right side area detects the presence or absence of obstacles in the right side area of the own vehicle based on sensor information such as a camera, millimeter wave radar, radar, and sonar sensor mounted on the right side of the vehicle. It is a function to do.

As shown in FIGS. 32, 33, and 34, each obstacle detection function is performed only on obstacles existing inside the detection area 301 according to the traveling lane. Further, each obstacle detection function comprehensively searches the detection area 301 to determine the presence or absence of an obstacle. That is, the larger the area of the detection area 301, the larger the number of repetitions in one detection process, and the higher the processing load of each obstacle detection function. Therefore, the processing load management unit 122 controls the processing load of each obstacle detection function by adjusting the area of the detection area in each obstacle detection function. Specifically, it is controlled so as to be the target processing load of each function based on the traveling lane and the processing load table T6 shown in FIG.

The processing load table T6 showing the relationship between the traveling lane shown in FIG. 36 and the target processing load of each function is classified into traveling in the center lane, traveling in the left lane, and traveling in the right lane as the driving type. Will be done. The target processing load for obstacle detection in the front area is set to 35%, 35%, and 35% according to each category. The target processing load for obstacle detection in the right area is set to 20%, 35%, and 5% according to each category. The target processing load for obstacle detection in the left area is set to 20%, 5%, and 35% according to each category. The total target processing load is set to 75%, 75%, and 75%.

FIG. 37 is a flowchart of processing load management according to the sixth embodiment. The flowchart shown in FIG. 37 shows the processing executed by the processing load management unit 122. As a premise of this processing, as shown in FIG. 35, an obstacle detection task F12 in the front area, an obstacle detection task F13 in the right side area, and an obstacle detection task F14 in the left side area are implemented in the processing execution unit 123. It is assumed that the processes registered in each task are executed so as to search the detection area. Further, the target processing load of each function is calculated by drawing a map from the traveling lane and the processing load table T6 shown in FIG. 36 according to the traveling lane.

In the process S1F of FIG. 37, the process load management unit 122 executes the process load management of obstacle detection in the front region according to the flowchart described with reference to FIG. In the sixth embodiment, instead of the processes S6 and S7 shown in the flowchart described with reference to FIG. 4, the detection process is repeatedly executed according to the area of the detection area. The area of the detection area at this time corresponds to the target processing load of the processing load table T6 shown in FIG. In the next processing S2F, similarly, the processing load management for obstacle detection in the right side region is executed. Further, in the next processing S2F, similarly, the processing load management for obstacle detection in the left side region is executed. At this time, in the process S4 shown in FIG. 4, the traveling lane of the own vehicle 21 is acquired from the vehicle outside environment acquisition unit 111 as the current state of the vehicle.

Next, in the process S4F, the process load management unit 122 acquires the process load of the CPU 120. In the processing S5F, the processing load management unit 122 determines whether or not the processing load of the CPU 120 exceeds the allowable processing load. If the allowable processing load is exceeded, the process proceeds to process S6F to perform degenerate processing of the function. The degenerate process of the function is the same as that of the first embodiment.

According to the sixth embodiment, the target processing load of each function is set based on the traveling lane of the own vehicle, and the detection area of each function is adjusted so as to be the target processing load, so that one cycle of each function can be obtained. The processing load of the CPU 120 can be managed by adjusting the number of repetitions required for each search and controlling the processing load of the CPU 120 accordingly. Therefore, depending on the setting of the target processing load, the processing load of the CPU 120 can be reduced, and an inexpensive CPU 120 having low processing performance can be selected.

Further, also in the sixth embodiment, it is possible to control so that the total processing load of each function does not exceed the allowable processing load of the CPU 120.

According to the embodiment described above, the following effects can be obtained.
(1) The vehicle control device 1 includes a control unit (processing load measuring unit 121, processing load management unit 122, processing execution unit 123) that controls a plurality of functions of the vehicle, and the plurality of functions are required depending on the state of the vehicle. The calculation load is different, and the control unit (processing load measurement unit 121, processing load management unit 122, processing execution unit 123) has a vehicle so that the total calculation load of a plurality of functions is within the allowable calculation load of the CPU 120. Adjust the calculation load of each function according to the state of. As a result, a plurality of functions can be assigned to the CPU in a well-balanced manner according to the state of the vehicle.

(Modification example)
The present invention can be implemented by modifying the first to sixth embodiments described above as follows.
(1) In the first to sixth embodiments, the CPU 120 may be a single core or a multi-core. When the CPU 120 is multi-core, for example, a function of increasing the calculation load when the vehicle speed is high and a function of increasing the calculation load when the vehicle speed is slow are assigned to one core. Further, to one of the other cores, for example, a function of increasing the calculation load when the distance to the front obstacle is short and a function of increasing the calculation load when the distance to the front obstacle is long are assigned. Hereinafter, each function is similarly assigned to each core of the multi-core. As a result, even if the CPU 120 is multi-core, a plurality of functions can be assigned in a well-balanced manner.

The present invention is not limited to the above-described embodiment, and other embodiments considered within the scope of the technical idea of the present invention are also included within the scope of the present invention as long as the features of the present invention are not impaired. .. Further, the configuration may be a combination of the above-described embodiments.

1 Vehicle control device 11 Input device 111 External environment acquisition unit 112 Driving state acquisition unit 113 Physical condition acquisition unit 114 Road information acquisition unit 12 Automatic driving control device 120 CPU
121 Processing load measurement unit 122 Processing load management unit 123 Processing execution unit 13 Output device 131 Display output unit 132 Travel control unit

Claims (18)

A control unit that controls a plurality of functions of the vehicle is provided, and the required calculation load differs depending on the state of the vehicle. The control unit has a total calculation load of the plurality of functions as an allowable calculation load of the CPU. A vehicle control device that adjusts the computational load of each function according to the condition of the vehicle so that it is within the range. In the control unit, at least one of the plurality of functions has a higher calculation load than the other functions under predetermined conditions, and the other functions have the allowable calculation of the control unit under the predetermined conditions. The vehicle control device according to claim 1, wherein the calculation load is lower than that of the one function so as to be within the load range. The vehicle control device according to claim 1, wherein the control unit is changed so as to increase the calculation load by shortening the execution cycle of the function. The vehicle control device according to claim 1, wherein the control unit is changed so as to increase the calculation load by increasing the number of calculation repetitions in one cycle of the function. The vehicle control device according to claim 1, wherein the control unit is changed so as to increase the calculation load by increasing the execution priority of the function. The vehicle control device according to claim 4, wherein the number of repetitions of the calculation is defined by the area of the detection area of the obstacle. The state of the vehicle is a vehicle speed, and the plurality of functions include a function of increasing a calculation load when the vehicle speed is high and a function of increasing a calculation load when the vehicle speed is slow. Vehicle control device. The function of increasing the calculation load when the vehicle speed is high is at least one function of collision mitigation braking, cruise control, and lane keeping, and the function of increasing the calculation load when the vehicle speed is slow is the false start suppression control. The vehicle control device according to claim 7, which is at least one function of automatic parking and electric power steering. The state of the vehicle is the distance to the front obstacle, and the plurality of functions are a function to increase the calculation load when the distance to the front obstacle is short and a function to increase the calculation load when the distance to the front obstacle is long. The vehicle control device according to claim 1, further comprising a function of increasing a calculation load. The function of increasing the calculation load when the distance to the front obstacle is short is the function of obstacle recognition by the short-distance sensor, and the function of increasing the calculation load when the distance to the front obstacle is long. Is the vehicle control device according to claim 9, which is a function of obstacle recognition by a long-distance sensor. The state of the vehicle is the degree of recognition of the lane, and the plurality of functions include a function of increasing the calculation load when the degree of recognition of the lane is low and a function of increasing the calculation load when the degree of recognition of the lane is high. , The vehicle control device according to claim 1. The function of increasing the calculation load when the recognition degree of the lane is low is a function of generating a route from the preceding vehicle trajectory, and the function of increasing the calculation load when the recognition degree of the lane is high is the function of increasing the calculation load. The vehicle control device according to claim 11, which is a function of generating a route from the vehicle. The state of the vehicle is the level of concentration of the driver, and the plurality of functions are a function of increasing the calculation load when the concentration of the driver is low and a calculation load when the concentration of the driver is high. The vehicle control device according to claim 1, further comprising a function of increasing the height. The function of increasing the calculation load when the driver's concentration is low is the function of monitoring the driver's concentration, and the function of increasing the calculation load when the driver's concentration is high is The vehicle control device according to claim 13, which is a function of the driver's concentration warning. The state of the vehicle is the distance from the vehicle to the curve, and the plurality of functions have a function of increasing the calculation load when the distance to the curve is long and a function of increasing the calculation load when the distance to the curve is short. The vehicle control device according to claim 1, wherein the vehicle control device includes the function of the vehicle. The function to increase the calculation load when the distance from the vehicle to the curve is long is the function of deceleration before the curve, and the function to increase the calculation load when the distance from the vehicle to the curve is short is the function of lane keeping support. The vehicle control device according to claim 15, which is a function. The state of the vehicle is the traveling lane of the vehicle, and the plurality of functions are a function of increasing the calculation load when the vehicle is traveling in the left lane and a function of increasing the calculation load when the vehicle is traveling in the right lane. The vehicle control device according to claim 1, further comprising a function of increasing a calculation load. The function of increasing the calculation load when the vehicle is traveling in the left lane is a function of detecting an obstacle in the right side region, and increases the calculation load when the vehicle is traveling in the right lane. The vehicle control device according to claim 17, wherein the function is an obstacle detection function in the left side region.

Images