Electronic control device, vehicle control method, and program

Abstract

In this electronic control device: a first software module provides a function for integrating external environment information about a host vehicle acquired by a plurality of sensors and estimating position information about a target present in the external environment; a second software module provides a function for generating a driving assistance plan for the host vehicle on the basis of the position information of the target as estimated by the first software module; and the first software module determines a second reference point serving as a reference for the position information of the target, on the basis of vehicle dimension information, determines second position information of the target for which the second reference point is the starting point, on the basis of first position information of the target in a coordinate system for which the first reference point is the point of origin, and provides the determined second position information to the second software module.

Description

[Technical Field]

[0001] The present invention relates to an electronic control device. [Background technology]

[0002] As vehicles become more multifunctional, the amount of software installed in on-board electronic control units is increasing, and the number of steps required to develop that software is also increasing.

[0003] The following prior art exists as background art in this technical field. Patent Document 1 (JP 2021-135807 A) describes a control unit having, as software configuration, an application layer in which an application for an in-vehicle device is implemented, a device driver, and a middleware layer that generates a communication path between the application and the device driver. The middleware layer describes an in-vehicle device control device that includes a physical quantity conversion module that converts physical quantity data included in data transmitted over the communication path in accordance with a predetermined conversion rule. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] Patent Publication No. 2021-135807 Summary of the Invention [Problem to be solved by the invention]

[0005] Patent Document 1 describes a method for reducing development man-hours by standardizing output values ​​according to predetermined rules based on differences in the characteristics of various sensors, and because there is no need to change the software itself by reviewing the rules even if the sensor changes, development man-hours can be reduced. However, the method described in Patent Document 1 does not take into account cases where the rules to be applied change depending on the vehicle dimensions, vehicle surrounding information, etc., because the rules are predetermined based on the sensor characteristics, etc. [Means for solving the problem]

[0006] A representative example of the invention disclosed in the present application is as follows: That is, an electronic control device includes a calculation unit that executes at least a first software module and a second software module, and a storage device connected to the calculation unit, wherein the storage device stores vehicle dimension information of a host vehicle, the first software module provides a function of integrating external environment information of the host vehicle acquired by a plurality of sensors to estimate position information of a target existing in the external environment, the second software module provides a function of generating a driving assistance plan for the host vehicle based on the position information of the target estimated by the first software module, and the first software module generates a driving assistance plan for the host vehicle based on the vehicle dimension information. The point on the body of the vehicle that is closest to the target. Establish a second reference point, The center of the rear axle is the center of the vehicle's movement. The present invention is characterized in that second position information of the target with the second reference point as a starting point is determined based on first position information in a coordinate system of the target with the first reference point as the origin, and the determined second position information is provided to the second software module. [Effects of the Invention]

[0007] According to one aspect of the present invention, it is possible to reduce the number of steps required to develop a vehicle control application. Problems, configurations, and effects other than those described above will become apparent from the following description of the embodiments. [Brief explanation of the drawings]

[0008] [Figure 1] 1 is a block diagram showing the configuration of an electronic control device according to a first embodiment of the present invention; [Figure 2] 10 is a flowchart of a process executed by a fusion application according to the first embodiment of the present invention. [Figure 3] FIG. 4 is a diagram showing a first reference point in the first embodiment of the present invention. [Figure 4] FIG. 10 is a diagram showing an example in which an AEB application is aware of vehicle dimension information when the present invention is not applied. [Figure 5]FIG. 10 is a diagram illustrating a state in which the AEB application does not take vehicle dimension information into consideration in the first embodiment of the present invention. [Figure 6] FIG. 10 is a diagram illustrating a method for determining a second reference point according to the first embodiment of the present invention. [Figure 7] FIG. 10 is a diagram showing a method for calculating a target position from a second reference point according to the first embodiment of the present invention. [Figure 8] FIG. 4 is a block diagram showing the configuration of an electronic control device according to a second embodiment of the present invention. [Figure 9] FIG. 10 is a block diagram showing the configuration of an electronic control device according to a third embodiment of the present invention. [Figure 10] FIG. 10 is a diagram showing vehicle dimension information according to a fourth embodiment of the present invention. [Figure 11] 10 is a flowchart of a process executed by a fusion application according to a fourth embodiment of the present invention. [Figure 12] 10 is a flowchart of a vehicle dimension information selection and acquisition process according to a fourth embodiment of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0009] Hereinafter, an embodiment of the present invention will be described with reference to the drawings.

[0010] Example 1 FIG. 1 is a block diagram showing the configuration of an electronic control unit 10 according to a first embodiment of the present invention.

[0011] 1, an electronic control unit 10 of the first embodiment has a CPU 11, which is a calculation unit that executes programs, and a memory 12, which is a storage device that stores programs executed by the CPU 11 and data used in processing, and the CPU 11 and the memory 12 are connected to each other via an internal bus or an adapter. The electronic control unit 10 is exemplified as an ADAS ECU that provides an advanced driver assistance system, but may also be an AD ECU that provides autonomous driving.

[0012] The memory 12 stores a recognition application 13, an AEB application 14, middleware 15, and vehicle dimension information 17. The middleware 15 includes a fusion application 16. The middleware 15 is a group of applications that provide information to multiple applications (the AEB application 14, as well as vehicle control applications such as an ACC application and an LKS application, not shown). The vehicle dimension information 17 is information that indicates the position of the vehicle surface from a predetermined reference point on the vehicle (for example, a first reference point R1, which will be described later). The vehicle dimension information 17 is located outside the middleware 15, but may be included in the middleware 15.

[0013] The recognition application 13, the AEB application 14, the middleware 15, and the fusion application 16 are all software modules that can be executed by the CPU 11. To simplify the explanation, each software module or an internal processing step may be described as a subject, but it is the CPU 11 that executes the processing.

[0014] The electronic control unit 10 is connected to a plurality of sensors 20 that observe the interior and exterior of the vehicle and detect the operation of the vehicle, and an actuator 30 that controls the operation of the vehicle.

[0015] The sensor 20 is a general term for devices such as radar and cameras that acquire information inside and outside the vehicle and transmit it to the electronic control unit 10, and a plurality of sensors 20 are generally mounted on a vehicle. The actuators 30 are brakes, throttles, steering, etc. that operate in accordance with command signals from the electronic control unit 10. The actuators 30 control the hydraulic pressure supplied to the brake cylinders in accordance with command signals from the AEB application 14, for example.

[0016] The recognition application 13 is provided for each type of sensor 20, analyzes information acquired from the sensor 20, calculates target information indicating the type and position of targets such as surrounding vehicles, and transmits the calculated target information to the fusion application 16.

[0017] The fusion application 16 integrates the target information from the multiple recognition applications 13 to improve the accuracy of the position, etc., and then transmits the target information in response to a target information query from the AEB application 14. Note that the fusion application 16 may transmit the target information to the AEB application 14 regardless of the target information query from the AEB application 14.

[0018] The AEB application 14 determines from the target information whether there is a target that may collide with the vehicle, and if there is a target that may collide, provides a collision damage mitigation brake function that sends a stop command signal or an avoidance operation command signal to the actuator 30 (e.g., brake, throttle).

[0019] FIG. 2 is a flowchart of the process executed by the fusion application 16 of the first embodiment.

[0020] S101: The target information received from the plurality of recognition applications 13 is integrated and stored in the memory 12.

[0021] S102: A target information query from the AEB application 14 is accepted.

[0022] S103: Determine whether target information is stored in the memory 12. If target information is stored in the memory 12, proceed to step S104, and if target information is not stored in the memory 12, proceed to step S108.

[0023] S104: Vehicle dimension information 17 is acquired.

[0024] S105: Determine the second reference point R2. The method for determining the second reference point R2 will be described later with reference to FIG.

[0025] S106: Calculate the position of the target from the second reference point R2. The method for calculating the target position will be described later with reference to FIG.

[0026] S107: The calculated target information is transmitted to the AEB application 14.

[0027] S108: If the target information is not stored in the memory 12, a target absence is transmitted to the AEB application 14.

[0028] FIG. 3 is a diagram showing the first reference point R1 in the first embodiment.

[0029] 3, in the first embodiment, the first reference point R1 is the rear axle center as exemplified in ISO 23150, and target information is expressed with the first reference point (rear axle center) R1 as the origin. In a typical front-wheel steering vehicle, the rear axle center is the center of vehicle movement.

[0030] FIG. 6 is a diagram showing a method for determining the second reference point R2 in step S104.

[0031] The intersection of a first line L1 connecting the first reference point R1 and the target position (xt1, yt1) with the vehicle surface is calculated and designated as a second reference point R2 (xb1, yb1). The position of the intersection on the vehicle surface is determined by determining the direction of the first line L1 relative to the first reference point R1, and searching for the intersection of the first line L1 with the vehicle outline in that direction from the vehicle dimension information 17. As a result, the second reference point becomes the point on the vehicle body that is closest to the target.

[0032] FIG. 7 is a diagram showing a method for calculating the target position from the second reference point R2 in step S106.

[0033] When the reference point is changed while keeping the Cartesian coordinate system, the position of the target from the second reference point R2 can be calculated by the following formula using the second reference point R2 (xb1, yb1). xtb1,ytb1=(xt1-xb1,yt1-yb1)

[0034] When the Cartesian coordinate system is transformed into a polar coordinate system with the second reference point R2 as the origin, the position of the target from the second reference point R2 can be calculated using the second reference point R2 (xb1, yb1) by the following equation: Distance:dtb1=(xtb1 2 +ytb1 2 ) 1 / 2 Angle: θtb1=arctan(xtb1 / ytb1)

[0035] FIG. 4 is a diagram showing an example in which the AEB application 14 is aware of the vehicle dimension information 17 when the present invention is not applied.

[0036] When the AEB application 14 receives position information of a target with the first reference point R1 as the origin, the AEB application 14 needs vehicle dimension information 17 of the host vehicle to subtract the distance from the first reference point R1 to the surface of the host vehicle.

[0037] FIG. 5 is a diagram showing a state in which the AEB application 14 does not take into account the vehicle dimension information 17 in the first embodiment.

[0038] 6 and 7, the fusion application 16 in the middleware aggregates the calculation processing for calculating the angle and distance from the second reference point R2 on the surface of the vehicle, and the fusion application 16 passes the position information of the target relative to the second reference point R2 to the AEB application 14, eliminating the need for the AEB application 14 to be aware of the vehicle dimension information 17. Therefore, it is not necessary to redevelop the AEB application 14 when the vehicle dimension information 17 is changed, thereby reducing the number of development steps.

[0039] Note that the target information passed to the AEB application 14 may remain in the Cartesian coordinate system or may be converted to a polar coordinate system, as shown in FIG. 7 . Converting to a polar coordinate system eliminates the need for the AEB application 14 to calculate the angle and distance to the target, simplifying processing and reducing the man-hours required for developing the AEB application 14. Meanwhile, because all target position information passed from the fusion application 16 to the AEB application 14 is expressed in a polar coordinate system, the processing load on the fusion application 16 increases. However, if target position information expressed in a polar coordinate system is provided to multiple applications (such as the AEB application 14, an ACC application, and an LKS application (not shown)), the processing load on the electronic control device 10 as a whole can be reduced compared to converting position information from the Cartesian coordinate system to the polar coordinate system in each application.

[0040] <Example 2> Next, a second embodiment of the present invention will be described. In the second embodiment, the AEB application 14 of the first embodiment is replaced with an ACC application 18, and the electronic control unit 10 provides an auto cruise control function that maintains the traveling speed of the host vehicle at a set speed. Note that in the second embodiment, differences from the first embodiment will be mainly described, and descriptions of the same configurations and procedures as the first embodiment will be omitted.

[0041] FIG. 8 is a block diagram showing the configuration of an electronic control unit 10 according to the second embodiment.

[0042] 8, unlike Fig. 1, the memory 12 stores the ACC application 18. Furthermore, the middleware 15 is a group of applications that provide information to multiple applications (in addition to the ACC application 18, vehicle control applications such as an AEB application and an LKS application, which are not shown).

[0043] In the second embodiment, the fusion application 16 transmits target information in response to a target information query from the ACC application 18. Note that the fusion application 16 may transmit target information to the ACC application 18 regardless of the target information query from the ACC application 18.

[0044] The ACC application 18 provides an auto cruise control function that maintains the vehicle's driving speed at a set speed, determines the distance to the preceding vehicle in the vehicle's driving lane from target information, and sends a deceleration command signal to an actuator 30 (e.g., brake, throttle) when the preceding vehicle approaches.

[0045] 6 and 7, the fusion application 16 calculates the angle and distance from the second reference point R2 on the surface of the vehicle and passes the position information of the target relative to the second reference point R2 to the ACC application 18, eliminating the need for the ACC application 18 to be aware of the vehicle dimension information 17. This eliminates the need to redevelop the ACC application 18 when the vehicle dimension information 17 is changed, thereby reducing the number of development steps.

[0046] Example 3 Next, a third embodiment of the present invention will be described. In the third embodiment, the AEB application 14 of the first embodiment is replaced with an LKS application 19, and the electronic control unit 10 provides a lane keep assist function that keeps the host vehicle in its driving lane. Note that in the third embodiment, differences from the first embodiment will be mainly described, and descriptions of the same configurations and procedures as the first embodiment will be omitted.

[0047] FIG. 9 is a block diagram showing the configuration of an electronic control unit 10 according to the third embodiment.

[0048] 9, unlike Fig. 1, the memory 12 stores an LKS application 19. Furthermore, the middleware 15 includes a fusion application 16. The middleware 15 is a group of applications that provide information to multiple applications (including the LKS application 19, and vehicle control applications such as an AEB application and an ACC application, which are not shown).

[0049] In the third embodiment, the fusion application 16 integrates target information from multiple recognition applications 13 to improve the accuracy of the position, etc., and then transmits the target information in response to a target information query from the LKS application 19. Note that the fusion application 16 may transmit target information to the LKS application 19 regardless of the target information query from the LKS application 19.

[0050] The LKS application 19 determines the distance between the vehicle and lane markings in the vehicle's driving lane from the target information, and provides a lane keeping assist function that keeps the vehicle in the lane it is traveling in. The LKS application 19 also determines the vehicle's driving position in the lane, taking into consideration that a sufficient lateral distance can be maintained between the vehicle and vehicles traveling alongside, oncoming vehicles, and obstacles. The LKS application 19 then sends a control command signal to an actuator 30 (e.g., a steering wheel) to steer the vehicle to the determined driving position.

[0051] 6 and 7, the fusion application 16 calculates the angle and distance from the second reference point R2 on the surface of the vehicle and passes position information of targets (particularly white lines, vehicles traveling parallel to the vehicle, and oncoming vehicles) relative to the second reference point R2 to the LKS application 19. This eliminates the need for the LKS application 19 to be aware of the vehicle dimension information 17 (particularly the vehicle width). This eliminates the need to redevelop the AEB application 14 when the vehicle dimension information 17 is changed, thereby reducing the number of development steps.

[0052] Example 4 Next, a fourth embodiment of the present invention will be described. In the fourth embodiment, a plurality of pieces of vehicle dimension information 17 are switched depending on conditions. In the fourth embodiment, differences from the first embodiment will be mainly described, and descriptions of the same configurations and procedures as the first embodiment will be omitted.

[0053] FIG. 10 is a diagram showing the vehicle dimension information 17 of the fourth embodiment.

[0054] The vehicle dimension information 17 in the fourth embodiment includes multiple pieces of vehicle dimension information (first vehicle dimension information 17A, second vehicle dimension information 17B). The first vehicle dimension information 17A is used in the first embodiment and is selected in the fourth embodiment when conditions are not adverse. The second vehicle dimension information 17B adopts a larger margin than the first vehicle dimension information 17A, resulting in larger dimensions. For example, the first vehicle dimension information 17A represents the actual vehicle dimensions, and the second vehicle dimension information 17B adds a predetermined length of margin around the actual vehicle dimensions, resulting in vehicle dimensions larger than the first vehicle dimension information 17A. In the fourth embodiment, a second reference point R2 is located on a figure defined by the second vehicle dimension information 17B.

[0055] FIG. 11 is a flowchart of the process executed by the fusion application 16 of the fourth embodiment.

[0056] Unlike FIG. 2, FIG. 11 includes S109 instead of S104.

[0057] S109: Select and acquire the vehicle dimension information 17. The vehicle dimension information selection and acquisition process will be described later with reference to FIG.

[0058] FIG. 12 is a flowchart of the vehicle dimension information selection and acquisition process of the fourth embodiment shown in S109 in FIG.

[0059] S1091: Determine whether the conditions are adverse. Adverse conditions include those caused by the surrounding environment (nighttime, heavy rain, backlight, surrounding traffic volume) and those caused by the vehicle state (sensor failure, vehicle speed, load weight, etc.), which affect sensor performance and vehicle maneuverability. For example, the conditions are determined to be adverse if a redundant sensor fails, if sensor performance deteriorates due to nighttime, heavy rain, backlight, etc., if the vehicle is heavily loaded and braking performance and steering performance deteriorate, if the vehicle speed is high and the braking distance is long, if traffic volume is high and the number of targets to be recognized increases, making it difficult to recognize some targets due to an increase in processing load, or if traffic volume is high and the vehicle and targets come close to each other, reducing the time to control the vehicle.

[0060] S1092: If it is determined that the conditions are bad, select the second vehicle dimension information 17B.

[0061] S1093: If it is determined that the conditions are not bad, the first vehicle dimension information 17A is selected.

[0062] S1094: The vehicle dimension information 17 (either the selected first vehicle dimension information 17A or the selected second vehicle dimension information 17B) is acquired.

[0063] As a modification of the fourth embodiment, an example of changing the vehicle dimension information 17 will be shown. When parts that change the vehicle dimensions are installed, the vehicle dimension information 17 is changed to a larger value by the size of the installed parts. For example, when a front guard or overfenders are installed as optional parts, the first vehicle dimension information 17A can be changed to second vehicle dimension information 17B that is larger by the size of the front guard. In this way, even if modifications that change the vehicle dimensions are made after the vehicle is shipped from the factory, the appropriate vehicle dimension information 17 can be set.

[0064] As described above, in the fourth embodiment, under adverse conditions, the second vehicle dimension information 17B, which is larger than the first vehicle dimension information 17A, is selected to correct the vehicle dimension information 17, which allows for more leeway in vehicle control and improves ride comfort while ensuring safety. For example, the AEB brake can be activated earlier to avoid sudden braking.

[0065] The present invention is not limited to the above-described embodiments, but includes various modifications and equivalent configurations within the spirit of the appended claims. For example, the above-described embodiments have been described in detail to clearly explain the present invention, and the present invention is not necessarily limited to configurations including all of the described configurations. Furthermore, part of the configuration of one embodiment may be replaced with the configuration of another embodiment. Furthermore, the configuration of another embodiment may be added to the configuration of one embodiment. Furthermore, part of the configuration of each embodiment may be added, deleted, or replaced with other configurations.

[0066] Furthermore, the aforementioned configurations, functions, processing units, processing means, etc. may be realized in part or in whole in hardware, for example by designing them as integrated circuits, or may be realized in software by a processor interpreting and executing a program that realizes each function.

[0067] Information such as programs, tables, and files that realize each function can be stored in a storage device such as a memory, a hard disk, or an SSD (Solid State Drive), or in a recording medium such as an IC card, an SD card, or a DVD.

[0068] In addition, the control lines and information lines shown are those that are considered necessary for the explanation, and do not necessarily show all the control lines and information lines that are necessary for implementation. In reality, it can be considered that almost all components are interconnected. [Explanation of symbols]

[0069] 10 Electronic control device 11 CPU 12 Memory 13 Recognition Applications 14 AEB Application 15 Middleware 16 Fusion Applications 17, 17A, 17B Second vehicle dimension information 18 ACC Applications 19 LKS Applications 20 sensors 30 Actuator

Claims

1. An electronic control device, a computing device that executes at least a first software module and a second software module, and a storage device connected to the computing device; the storage device stores vehicle dimension information of the host vehicle; the first software module provides a function of integrating external information of the host vehicle acquired by a plurality of sensors and estimating position information of a target existing in the external world; the second software module provides a function of generating a driving assistance plan for the host vehicle based on the position information of the target estimated by the first software module; The first software module: determining a second reference point that is a point on the body of the host vehicle that is closest to the target based on the vehicle dimension information; determining second position information of the target with the second reference point as a starting point based on first position information in a coordinate system of the target with the first reference point being the center of the rear axle, which is the center of vehicle movement, as the origin; and an electronic control unit that provides the determined second position information to the second software module.

2. An electronic control device as described in claim 1, The electronic control device, wherein the second position information is expressed in a polar coordinate system by a distance and an angle from the second reference point.

3. An electronic control device as described in claim 1, The vehicle dimension information is changeable in the electronic control device.

4. An electronic control device as claimed in claim 1, The first software module is an electronic control device that selects the vehicle dimension information based on at least one of the state of the host vehicle and an external environment.

5. An electronic control device as claimed in claim 1, the first software module is middleware that provides the second location information to a plurality of the second software modules; The second software module is an electronic control device that is a vehicle control application that controls the running of the host vehicle.

6. An electronic control device as claimed in claim 1, The second software module is an electronic control device that is a software module that provides an auto cruise control function, a collision mitigation braking function, or a lane keeping assist function.

7. A vehicle control method executed by an electronic control device, comprising: the electronic control device includes a computing device that executes at least a first software module and a second software module, and a storage device connected to the computing device; the storage device stores vehicle dimension information of the host vehicle; the first software module provides a function of integrating external information of the host vehicle acquired by a plurality of sensors and estimating position information of a target existing in the external world; the second software module provides a function of generating a driving assistance plan for the host vehicle based on the position information of the target estimated by the first software module; The vehicle control method includes: a step in which the first software module determines a second reference point, which is a point on the body of the host vehicle that is closest to the target, based on the vehicle dimension information; a step in which the first software module determines second position information of the target with the second reference point as a starting point based on first position information in a coordinate system of the target with the first reference point being the center of the rear axle, which is the center of vehicle movement, as the origin; and providing the determined second position information to the second software module.

8. A program constituting a first software module executed by an electronic control unit, the electronic control device has a calculation unit that executes a program and a storage device connected to the calculation unit, the storage device stores vehicle dimension information of the host vehicle; The program The present invention provides a function of integrating external information of the host vehicle acquired by a plurality of sensors and estimating position information of a target existing in the external world, determining a second reference point, which is a point on the body of the host vehicle that is closest to the target, based on the vehicle dimension information; a step of determining second position information of the target with the second reference point as a starting point based on first position information in a coordinate system of the target with the first reference point being the center of the rear axle, which is the center of vehicle movement, as the origin; and a procedure for providing the determined second position information to a second software module that generates a driving assistance plan for the host vehicle.

Images