Vehicle control method and vehicle control system

Abstract

Provided is a vehicle control method using a vehicle control system comprising: a first control device that controls the operation of a first on-vehicle instrument; a second control device that controls the operation of a second on-vehicle instrument; and a third control device that transmits control signals to the first control device and the second control device. In this method, upon receiving a request for software update to either the first control device or the second control device, the third control device transmits a first control signal including a control operation suspension instruction and a software update execution command to an update-receiving device, which is a device that undergoes software update out of the first control device and the second control device, and transmits a second control signal including an operation command for a period during which the control operation of the update-receiving device is stopped to a non-update-receiving device, which is not an update-receiving device. The update-receiving device executes the software update after stopping the control operation on the basis of the first control signal, and the non-update-receiving device controls the operation of the on-vehicle instrument to be controlled on the basis of the second control signal.

Description

Vehicle control method and vehicle control system

[0001] The present invention relates to a vehicle control method and a vehicle control system.

[0002] As a means for updating software stored in the read-only memory (ROM) of a controller installed in a vehicle, an update function using wireless network communication, known as FOTA (Firmware Over The Air), is known. Generally, to safely update software, it is necessary to stop the functions of the controller to be updated. However, if the controller to be updated controls equipment related to the vehicle's operation, a problem arises in that the vehicle cannot be operated during the update. To solve this problem, JP2022-149527A discloses a system that includes a first storage unit that stores a first program for executing a first function of software, and a second storage unit that stores an alternative function that replaces all of the first function and a second program for executing a second function, and that controls the vehicle using the alternative function and the second function when updating the first program.

[0003] However, the system described in the above document has a problem in that it is necessary to redundantly provide a second program that is used only when updating software, and a second storage unit that stores the second program.

[0004] In view of the above, an object of the present invention is to enable software updates while a vehicle is running, without providing redundant programs or storage units.

[0005] According to one aspect of the present invention, there is provided a vehicle control method for a vehicle control system including a first control device that controls the operation of a first in-vehicle device, a second control device that controls the operation of a second in-vehicle device, and a third control device that transmits control signals to the first and second control devices. In this method, when the third control device receives a software update request for either the first or second control device, it transmits a first control signal to an update target device of the first or second control device that is the target of the software update, the first control signal including a control operation stop command and a software update execution command, and transmits a second control signal to a non-update target device that is not the update target device, the second control signal including an operation command for the update target device to stop its control operation while the update target device stops its control operation based on the first control signal, and executes the software update on the non-update target device.

[0006] Fig. 1 is a schematic diagram showing an example of a system configuration of an electric vehicle. Fig. 2 is a diagram showing the hardware configuration of a front controller. Fig. 3 is a diagram showing the hardware configuration of a rear controller. Fig. 4 is a flowchart showing the basic operation of software update control. Fig. 5 is a flowchart showing a control routine for software update control according to a first embodiment. Fig. 6 is a flowchart showing a control routine for software update control according to a second embodiment.

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

[0008] [First Embodiment] (I. System Configuration) Fig. 1 is a schematic diagram showing an example of the system configuration of an electric vehicle 10. In this embodiment, an electric vehicle 10 equipped with independent motors (electric motors) at the front and rear will be described as an example. That is, the electric vehicle 10 is a four-wheel drive vehicle in which the front wheels 22 and the rear wheels 32 are each driven by a different motor. The electric vehicle 10 includes a front-wheel drive system 11, a rear-wheel drive system 12, a battery 13, a vehicle control unit 14 as a third control device, and a FOTA control unit 17.

[0009] The front-wheel drive system 11 is a system that drives front wheels 22 using a front motor 21 as a first on-board device. In addition to the front motor 21 and the front wheels 22, the front-wheel drive system 11 also includes a front controller 15 as a first control device, a front inverter 23, a rotation sensor 24, a current sensor 25, and the like.

[0010] The front motor 21 is, for example, a three-phase AC synchronous motor that generates driving force using AC power input from the front inverter 23 and transmits the driving force to the front wheels 22 via the front reduction gear 26 and the drive shaft 27. That is, the output torque of the front motor 21 generates torque (driving force) on the front wheels 22. Furthermore, when the electric vehicle 10 is traveling, the front motor 21 generates regenerative driving force (so-called regenerative torque) when its drive shaft is rotated by the front wheels 22. This allows the front motor 21 to recover the kinetic energy of the electric vehicle 10 as electrical energy.

[0011] The front wheels 22 are drive wheels disposed at the front of the electric vehicle 10. The front wheels 22 are connected to the front motor 21 via a front reduction gear 26 and a drive shaft 27.

[0012] The front inverter 23 includes, for example, two pairs of switching elements for each phase of the front motor 21. The front inverter 23 turns these switching elements on and off in response to a PWM (Pulse Width Modulation) signal input from the front controller 15. As a result, the front inverter 23 converts DC power supplied from the battery 13 into AC power, and supplies a desired current to the front motor 21 to drive the front motor 21. The switching elements constituting the front inverter 23 are, for example, power semiconductor elements such as insulated gate bipolar transistors (IGBTs) and metal oxide semiconductor field effect transistors (MOS-FETs). During regenerative control, the front inverter 23 converts AC power generated by the front motor 21 into DC power and inputs it to the battery 13.

[0013] The rotation sensor 24 detects the front rotor phase αf. The front rotor phase αf corresponds to the rotor phase α of the front motor 21, i.e., the electrical angle [rad] of the front motor 21. The rotation sensor 24 is, for example, a resolver or an encoder. The detected front rotor phase αf is input to the vehicle control unit 14.

[0014] The current sensor 25 detects the current value (i ｕｆ , i ｖｆ , i ｗｆ These current values ​​are input to the vehicle control unit 14.

[0015] The front wheel drive system 11 also includes other sensors (for example, wheel rotation sensors (not shown)). The wheel rotation sensors are sensors that detect the rotation speeds of the left and right front wheels 22.

[0016] The rear-wheel drive system 12 is a system that drives rear wheels 32 by a rear motor 31 serving as a second on-board device, and is configured symmetrically to the front-wheel drive system 11. Therefore, in addition to the rear motor 31 and rear wheels 32, the rear-wheel drive system 12 includes a rear controller 16 serving as a second control device, a rear inverter 33, a rotation sensor 34, a current sensor 35, a rear reduction gear 36, a drive shaft 37, etc. These components that make up the rear-wheel drive system 12 function in the same way as the components of the front-wheel drive system 11. In other words, the rear wheels 32 are drive wheels located at the rear of the electric vehicle 10. The rotation sensor 34 detects the rotor phase α of the rear-wheel drive system 12. The current sensor 35 detects the value of current flowing through each phase of the rear motor 31.

[0017] The battery 13 is provided in common to the front wheel drive system 11 and the rear wheel drive system 12, and discharges power to drive the front motor 21 and the rear motor 31. During regenerative control, the battery 13 is charged by the regenerative power generated by the front motor 21 and the rear motor 31.

[0018] The vehicle control unit 14 is a control device for the electric vehicle 10. The vehicle control unit 14 acquires various vehicle variable signals as digital signals and generates PWM signals for controlling the front motor 21 and the rear motor 31 based on these vehicle variables. The vehicle control unit 14 then transmits the generated PWM signals to the front controller 15 and the rear controller 16, respectively. For example, the vehicle control unit 14 calculates a torque command value (hereinafter also referred to as a torque command value) for the total torque generated by the front motor 21 and the rear motor 31 and a driving force distribution between the front motor 21 and the rear motor 31 based on an accelerator pedal position and a vehicle speed, which will be described later. Then, based on the torque command value and the driving force distribution, the vehicle control unit 14 calculates a front torque command signal, which is a torque command value for the front controller 15, and a rear torque command signal, which is a torque command value for the rear controller 16, and transmits these signals to the front controller 15 and the rear controller 16.

[0019] Vehicle variables are parameters that represent the control state of the electric vehicle 10, etc. The vehicle control unit 14 acquires, for example, accelerator opening θ and vehicle speed as vehicle variables. The accelerator opening θ is a parameter that represents the amount of operation of an accelerator pedal (not shown) by the driver. The accelerator opening θ, vehicle speed, and other vehicle variables can be detected appropriately as needed by sensors (not shown). The vehicle control unit 14 may acquire the vehicle variables directly from sensors, etc., or may acquire some or all of the vehicle variables from the front controller 15, the rear controller 16, or another controller (computer) (not shown).

[0020] The vehicle control unit 14, the front controller 15, the rear controller 16, and the FOTA control unit 17 are each composed of one or more microcomputers equipped with a central processing unit (CPU), a read-only memory (ROM), a random access memory (RAM), and an input / output interface (I / O interface).

[0021] The front controller 15 controls the front motor 21 by controlling the power conversion in the front inverter 23 based on the received front command signal. The rear controller 16 controls the rear motor 31 by controlling the power conversion in the rear inverter 33 based on the received rear command signal. The front controller 15 and the rear controller 16 are equipped with software for performing the above controls.

[0022] The FOTA control unit 17 controls updating of the software installed in the front controller 15 or the rear controller 16 with new software obtained from an external FOTA server 40 via a communication means such as a wireless network.

[0023] 2 and 3 are diagrams showing the hardware configurations of the front controller 15 and the rear controller 16, respectively.

[0024] The front controller 15 comprises a CPU 15A, a first ROM 15B, and a second ROM 15C. The first ROM 15B stores software for controlling the front motor 21. The second ROM 15C stores new software transmitted from the FOTA control unit 17 when FOTA is executed. This new software is written to the first ROM 15B when a rewrite operation is performed. The CPU 15A executes the software stored in the first ROM 15B.

[0025] The rear controller 16 includes a CPU 16A, a first ROM 16B, and a second ROM 16C, similar to the front controller 15. The functions of these components are also similar to those of the front controller 15.

[0026] (II. Software Update Control)

[0027] Next, the software update control for rewriting the software in the front controller 15 and the rear controller 16 with the above-mentioned new software will be described with reference to Figures 4 and 5. In the following description, it is assumed that the front controller 15 is a device to be updated and the rear controller 16 is a device not to be updated. If the front controller 15 is a device not to be updated and the rear controller 16 is a device to be updated, the control content is the same except that the front controller 15 and the rear controller 16 are swapped. It is also possible that both the front controller 15 and the rear controller 16 are devices to be updated, in which case the update will be performed in order from the device for which the update data described below was downloaded first.

[0028] Fig. 4 is a flowchart showing the basic operation of the software update control, and Fig. 5 is a flowchart showing the control routine of the software update control according to this embodiment.

[0029] First, the flowchart of FIG. 4 will be described.

[0030] In step S100, the FOTA control unit 17 downloads new software (update data in the figure) from the FOTA server 40 via wireless network communication or the like, and transmits it to the front controller 15. The front controller 15 writes the received software data to the second ROM 15C in parallel with executing the main control. The main control here refers to torque control of the front motor 21 based on a torque command value from the vehicle control unit 14.

[0031] In step S110, when the data writing to the second ROM 15C is completed, the FOTA control unit 17 transmits a software rewrite request to the vehicle control unit 14.

[0032] In step S120, the vehicle control unit 14 transmits a control signal (first control signal) including a request to stop main control and a request to rewrite the software to the front controller 15, and upon receiving this, the front controller 15 stops main control.

[0033] In step S130, when the main control is stopped, that is, when the software is ready to be rewritten, the front controller 15 rewrites the originally stored software with the software stored in the second ROM 15C. When this rewriting is complete, the front controller 15 notifies the FOTA control unit 17 of the completion. Note that this notification may also be sent to the vehicle control unit 14.

[0034] In step S140, the vehicle control unit 14 requests the front controller 15 to resume the main control, and the front controller 15 responds by resuming the main control.

[0035] The above is the basic content of software update control. However, in the above software update control, the main control is stopped while the first ROM 15B is being rewritten, and therefore the front motor 21 cannot generate torque. That is, of the front motor 21 and rear motor 31 that are cooperatively controlled based on the torque command value and driving force distribution calculated by the vehicle control unit 14, the front motor 21 is stopped. Therefore, if software update control is executed while the vehicle is running, torque will decrease as the front motor 21 is stopped, and drivability will be impaired. On the other hand, drivability will not be impaired if the vehicle is stopped, but convenience will be impaired because the update is only possible while the vehicle is stopped.

[0036] Therefore, in this embodiment, in order to achieve both the above-mentioned drivability and convenience, the flowchart shown in FIG. 5 is executed.

[0037] Steps S200, S210, S220, and S230 in Fig. 5 are similar to steps S100, S110, S120, and S130 in Fig. 4, and therefore will not be described further. The following description will focus on steps S214 and S240, which are different from Fig. 4.

[0038] In step S214, the vehicle control unit 14 transmits a second control signal to the rear controller 16 as an operation command while the front controller 15 is stopped. The operation command while the front controller 15 is stopped is an operation command to maintain the same driving state as when the front controller 15 is operating, even while the front controller 15 is stopped. In the present embodiment, this command is to have the rear controller 16 alone execute main control of the entire vehicle. This command causes the electric vehicle 10, which normally runs in four-wheel drive, to run in two-wheel drive during the software update.

[0039] In step S240, when the vehicle control unit 14 receives a notification from the FOTA control unit 17 or the front controller 15 that the software rewriting has been completed, it resumes the main control of the front controller 15 and resumes cooperative control with the rear controller 16.

[0040] 5, the electric vehicle 10 switches from four-wheel drive to two-wheel drive during the software rewrite operation. That is, the total torque, which is the sum of the torque generated in the front motor 21 and the rear motor 31 based on the driving force distribution calculated by the vehicle control unit 14, is generated by the rear motor 31 alone.

[0041] Since the front controller 15 and rear controller 16 control the torque of the front motor 21 and the rear motor 31 based on the front torque command signal and the rear torque command signal, respectively, when the vehicle is switched to two-wheel drive, only the magnitude of the rear torque command signal changes. In other words, the program used for cooperative control can be used to support two-wheel drive, so there is no need to provide a special program just for software rewriting. When the vehicle is switched to two-wheel drive, the torque allocated to the front motor 21 is switched to the allocation to the rear motor 31, causing a sudden increase in the torque value of the rear torque command signal. To prevent this sudden change in the rear torque command signal from being erroneously diagnosed as a malfunction, the rear controller 16 is made to recognize that it is performing main control alone in step S214.

[0042] In the above embodiment, the electric vehicle 10 is described as a four-wheel drive vehicle, but this is not limiting. For example, the electric vehicle 10 may be a multi-wheel drive vehicle in which both or either of the front-wheel drive system 11 and the rear-wheel drive system 12 have two or more axles.

[0043] As described above, this embodiment provides a vehicle control method using a vehicle control system including a first control device (front controller 15) that controls the operation of a first on-board device (front motor 21), a second control device (rear controller 16) that controls the operation of a second on-board device (rear motor 31), and a third control device (vehicle control unit 14) that transmits control signals to the first control device and the float 2 control device. In this method, when the third control device receives a software update request for either the first control device or the second control device, it transmits a first control signal including a control operation stop command and a software update execution command to the update target device of the first or second control device that is the target of the software update, and transmits a second control signal including an operation command while the update target device has stopped its control operation to the non-update target device. The update target device stops its control operation based on the first control signal and then performs a software update, and the non-update target device controls the operation of the on-board device that is the target of the control based on the second control signal. This eliminates the need for redundant programs or memory units, since the non-update target devices can continue to use their original programs even during software rewriting. Furthermore, even when the update target device is stopped, the non-update target device maintains the same operating state as when the update target device is operating.

[0044] In this embodiment, the first in-vehicle device is a device related to the running of the vehicle, and the second in-vehicle device is a device related to the running of the vehicle but different from the first in-vehicle device, thereby making it possible to update the software of the update target device without interfering with the running of the vehicle.

[0045] In this embodiment, the vehicle (electric vehicle 10) is a multi-wheel drive vehicle, the first on-board device is a drive system for one of the drive wheels, and the second on-board device is a drive system for a drive wheel different from the first on-board device. More specifically, the vehicle is a four-wheel drive vehicle, the first on-board device is a drive system (front motor 21) for the front wheels 22, and the second on-board device is a drive system (rear motor 31) for the rear wheels 32. This allows software updates to be performed while the vehicle is traveling. Note that being able to perform software updates while the vehicle is traveling not only improves convenience but is also desirable from a security perspective. That is, it is desirable to perform security authentication when updating software, and it is desirable to perform security authentication not only when downloading update data but also when rewriting. For example, in a system that does not allow software updates while the vehicle is traveling, software updates cannot be performed in locations where the network is disconnected, such as underground parking lots, even when the vehicle is parked, or updates are performed without security authentication. However, the system of this embodiment allows software updates to be performed while avoiding locations where the network is disconnected, i.e., locations where security authentication is not possible.

[0046] Second Embodiment A second embodiment will be described with reference to Fig. 6. The difference between this embodiment and the first embodiment is the control routine for software update control. The following description will focus on this difference.

[0047] 6 is a flowchart of software update control according to this embodiment. Step S312 is a process unique to this embodiment, and the other steps S300, S310, and S314-S340 are the same as steps S200, S210, and S214-S240 in FIG. 5, respectively, and therefore will not be described again.

[0048] In step S312, when the vehicle control unit 14 receives a software rewrite request, it determines whether the first ROM 15B is in a rewritable state, and if it is rewritable, it proceeds to the processing of step S314, and if not, it ends this routine.

[0049] The first ROM 15B being rewritable means that the rear controller 16 can execute main control independently. Therefore, for example, the rear controller 16 is determined to be in a rewritable state when it is not currently executing software update control or the like. Furthermore, depending on the performance of the rear motor 31, when a large torque is required, such as during acceleration on a highway, the rear motor 31 alone may not be able to meet the required torque. Therefore, if it is estimated, for example, based on vehicle position information or surrounding conditions, that the rear motor 31 alone may not be able to meet the required torque, it may be determined that the first ROM 15B is not rewritable.

[0050] By performing the process of step S312, it is possible to avoid a situation in which, for example, a torque corresponding to a requested torque cannot be generated after starting rewriting of the front controller 15, causing a stall or vehicle stop. In other words, it is possible to update the software while ensuring driving performance and safety performance.

[0051] As described above, in this embodiment, when the third control device (vehicle control unit 14) receives a software update request, it determines whether the update target device (front controller 15) is in a state where the update is possible, and if it determines that the update is possible, it transmits a first control signal to the update target device (front controller 15) and a second control signal to the non-update target device (rear controller 16). This makes it possible to update the software while ensuring driving performance and safety performance. Furthermore, when update software is received from both the front controller 15 and the rear controller 16, it is possible to avoid a situation where both controllers start updating at the same time, resulting in a vehicle becoming unable to drive.

[0052] [Modification] Next, a modification of the first embodiment will be described. This modification also falls within the scope of the present invention, just like the first embodiment.

[0053] In the first embodiment, the downloaded update data is stored in the second ROM 15C, and the software in the first ROM 15B is rewritten with the update data while the main control is stopped. In other words, the main control of the front controller 15 is always executed by the software stored in the first ROM 15B.

[0054] In contrast, in this modified example, the first ROM 15B is not rewritten, and after cooperative control is resumed, the main control of the front controller 15 is performed by the software stored in the second ROM 15C. In other words, while the main control of the front controller 15 is stopped, the software used for main control is switched from that stored in the first ROM 15B to that stored in the second ROM 15C. Then, at the time of the next software update, the downloaded update data is stored in the first ROM 15B, and the above-mentioned switching from the second ROM 15C to the first ROM 15B is performed, and the above-mentioned switching is repeated for subsequent software updates.

[0055] This eliminates the need to rewrite the software, and only switching between the first ROM 15B and the second ROM 15C is required, thereby reducing the time during which the main control of the front controller 15 is stopped.

[0056] This modification can also be applied to the second embodiment in the same manner.

[0057] In the above-described first embodiment, second embodiment, and modified example, the on-board devices are described as the front motor 21 and rear motor 31 of a four-wheel drive vehicle. However, this is not limiting. The on-board devices may be any devices related to vehicle driving. More specifically, the on-board devices may be devices related to vehicle driving, are normally controlled in a coordinated manner, and stopping one of them does not pose a problem in terms of driving performance or safety. For example, if a driving assistance system or an autonomous driving system includes a radar and a camera, these may be used as the first and second on-board devices. Both the radar and the camera are devices that detect obstacles and other vehicles around the vehicle and are involved in vehicle driving, such as automatic braking control and adaptive cruise control. To take advantage of the respective characteristics of the radar and the camera, autonomous driving control or driving assistance control is performed based on a comprehensive judgment using the detection signals from both devices. However, the execution of the autonomous driving control or driving assistance control is not affected by the use of only one of the radar and the camera. In addition, both systems transmit detection signals to an autonomous driving control unit (hereinafter also referred to as AD C / U) or a driving assistance control unit (hereinafter also referred to as ADAS C / U) via a SoC (System on a chip). The AD C / U or ADAS C / U executes autonomous driving control or driving assistance control based on the transmitted signals. In other words, the SoCs of the radar and camera correspond to the first and second control devices, and the AD C / U or ADAS C / U corresponds to the third control device.

[0058] Although the embodiments of the present invention have been described above, the above embodiments merely illustrate some of the application examples of the present invention, and it is not intended that the technical scope of the present invention be limited to the specific configurations of the above embodiments.

Claims

1. A vehicle control method using a vehicle control system having a first control device that controls the operation of a first in-vehicle device, a second control device that controls the operation of a second in-vehicle device, and a third control device that transmits control signals to the first control device and the second control device, wherein, upon receiving a request for a software update for either the first control device or the second control device, the third control device transmits a first control signal to an update target device of the first control device or the second control device that is the target of the software update, the first control signal including a control operation stop command and a command to execute the software update, and transmits a second control signal to a non-update target device that is not the update target device, the second control signal including an operation command for the update target device to stop its control operation while it is stopping its control operation, the update target device stops its control operation based on the first control signal and then executes the software update, and the non-update target device controls the operation of the in-vehicle device that is the target of the control based on the second control signal.

2. A vehicle control method according to claim 1, wherein the first in-vehicle device is a device related to the running of the vehicle, and the second in-vehicle device is a device related to the running of the vehicle but different from the first in-vehicle device.

3. A vehicle control method according to claim 2, wherein the vehicle is a multi-wheel drive vehicle, the first vehicle-mounted device is a drive system for one of the drive wheels, and the second vehicle-mounted device is a drive system for a drive wheel different from the first vehicle-mounted device.

4. A vehicle control method according to claim 3, wherein the vehicle is a four-wheel drive vehicle, the first vehicle-mounted device is a front-wheel drive system, and the second vehicle-mounted device is a rear-wheel drive system.

5. A vehicle control method as described in claim 1, wherein, upon receiving the software update request, the third control device determines whether the update target device is in an updatable state, and if it determines that the update is possible, transmits the first control signal to the update target device and transmits the second control signal to the non-update target device.

6. A vehicle control system having a first control device that controls the operation of a first in-vehicle device, a second control device that controls the operation of a second in-vehicle device, and a third control device that transmits control signals to the first control device and the second control device, wherein the third control device, upon receiving a request for a software update for either the first control device or the second control device, is programmed to: transmit a first control signal including a control operation stop command and a command to execute the software update to an update target device of the first control device or the second control device that is the target of the software update; and transmit a second control signal to a non-update target device that is not the update target device, including an operation command for while the update target device has stopped its control operation; the update target device is programmed to stop its control operation based on the first control signal and then execute the software update; and the non-update target device is programmed to control the operation of the in-vehicle device that is the target of the control based on the second control signal.

Images