CN110799388B

CN110799388B - Electronic control device and control method for realizing safe parking lock

Info

Publication number: CN110799388B
Application number: CN201780089275.9A
Authority: CN
Inventors: 长冈孝浩
Original assignee: GKN Driveline International GmbH
Current assignee: GKN Automotive Ltd
Priority date: 2017-04-19
Filing date: 2017-04-19
Publication date: 2022-01-25
Anticipated expiration: 2037-04-19
Also published as: WO2018193533A1; JPWO2018193533A1; CN110799388A; JP6824391B2

Abstract

The electronic control device is connected to a power supply of the vehicle, and is connected to one or more other electronic control devices to control the parking lock in order to share information by communication. The electronic control device includes: a locking unit that locks the parking lock if it is detected that the power supply is turned off, the information includes a parking lock request, and the parking lock is not locked; and a parking lock detection unit that, if it is detected that the parking lock is locked, causes the information to include a parking lock completion notification.

Description

Electronic control device and control method for realizing safe parking lock

Technical Field

The following disclosure relates to an electronic control device and a control method for realizing a safe parking lock, and more particularly, to an electronic control device and a control method for safely bringing a vehicle into a parking lock state even when an error message is transmitted from another electronic control device.

Background

In a vehicle employing an automatic transmission in order to prevent an accidental movement of the vehicle during parking, the ignition can be normally turned off when the gear selector is brought into the parking position. In association with the control of the parking lock, for example, an Electronic Control Unit (ECU) of a higher rank first sends a parking lock request to lock the gear system (parking lock) to an ECU of a lower rank serving as the gear system, and then sends a stop request to stop all the ECUs. Since the parking lock is performed in advance, the vehicle should not move during and after the stop even if an external force is applied or the driver makes an erroneous operation.

Patent document 1 discloses a related technique.

Prior art documents

Patent document

Patent document 1: japanese laid-open patent publication No. 2009-30637

Disclosure of Invention

In consideration of further improvement in safety, there is still room for improvement in the above control. That is, when the ignition of the vehicle is turned off, in a state where the parking lock request cannot be received from the ECU on the upper level for some reason, if the ECU on the lower level is stopped, there is a possibility that a state where the parking lock is not performed occurs. For example, when the higher-level ECU malfunctions or when the communication bus is in a defective state, such a situation may occur. In these cases, it may be difficult for the driver to notice the malfunction.

The following disclosed apparatus and method have been made in view of the above problems.

According to one aspect, the electronic control device is connected to a power supply of the vehicle, and is connected to one or more other electronic control devices that control the parking lock in order to share information by communication. The electronic control device includes: a locking unit that locks the parking lock if it is detected that the power supply is turned off, the information includes a parking lock request, and the parking lock is not locked; and a parking lock detection unit that, if it is detected that the parking lock is locked, causes the information to include a parking lock completion notification.

According to another aspect, the electronic control device detects the state of the power supply and the parking lock of the vehicle, and shares information including at least one request with one or more other electronic control devices by communication. The method for controlling the parking lock, which is executed by the electronic control device, comprises the following steps: locking the parking lock if it is detected that the power supply is cut off, the information includes a parking lock request, and the parking lock is not locked; and detecting whether the parking lock is locked.

Drawings

Fig. 1 is a block diagram of a vehicle including an electronic control device according to the present embodiment.

Fig. 2 is a flowchart of control executed by the electronic control device of the present embodiment.

Fig. 3 is a flowchart showing a detailed process of performing the parking lock in fig. 2.

Fig. 4 is a flowchart showing a detailed process of releasing the parking lock in fig. 2.

Fig. 5 is a flowchart of control according to a modification executed when there is a request to release the parking lock.

Fig. 6 is a flowchart for stop control.

Fig. 7A is a flowchart of an example of the substitution of the portion indicated by the one-dot chain line in fig. 6.

Fig. 7B is a flowchart showing another example of the replacement of the portion shown by the one-dot chain line in fig. 6.

Detailed Description

Several exemplary embodiments will be described below with reference to the accompanying drawings.

Referring to fig. 1, a typical vehicle 1 includes, for example, an engine and a gear system including a transmission for transmitting torque from the engine to each axle, and includes a plurality of programmable Electronic Control Units (ECUs) for electronically controlling these respective portions. Each ECU includes a storage device that stores commands and data, and a microcontroller that can read the commands and data from the storage device and execute the commands.

The number of ECUs of a typical vehicle is also several tens, but only six of the ECUs 11 to 21 are shown in fig. 1. The ECUs 11 to 21 read the states of the respective portions of the vehicle by various sensors and are connected to each other via a bus 31. The ECUs 11-21 communicate information or share information, for example, by communication via a so-called Control Area Network (CAN). The above information includes not only the read state but also requests to other ECUs, and each ECU controls each section using the information.

For example the gear system is provided with a parking lock 7 and a detection unit 9 for detecting its status, e.g. locked or unlocked. The actuator and detection unit 9 that drives the parking lock 7 is electrically connected to the parking lock ECU11, and the parking lock ECU11 controls the parking lock 7 based on the read information and a request from another ECU. The other ECUs, for example, ECU13 are connected to ignition switch 3, send requests to the respective ECUs in accordance with the state (on or off) of switch 3, and share the state of switch 3 with the other ECUs including ECU11 via bus 31. The

other ECUs

15, 19 monitor the rotation of the axles, gears, shafts to control gear systems, brakes, etc. The other ECU21 is connected to the console 5 provided with various indicators, performs various controls in response to the instructions of the driver, and presents the state to the driver.

These are limited examples and the control of the ECU involves many aspects. For example, the parking lock ECU11 may be able to directly read the state of the ignition switch 3 via the dedicated bus 33 without via the ECU13 and the general-purpose bus 31, or may be able to be directly connected to the switch 3.

The parking lock 7 is generally a mechanism configured to lock any one of the shafts of the gear system, independently of the side brake or the other brake corresponding to the side brake, and operates in cooperation with the gear selector being brought into the parking position. In the present specification and claims, a sentence "lock parking lock" is used as a meaning that the parking lock enters a state of locking the shaft.

The parking lock 7 includes, for example, a notched wheel or a parking gear on a shaft, a movable pawl that locks the wheel or the parking gear, and an actuator for driving the pawl. Instead of a wheel or a combination of a gear and pawl, a suitable latch mechanism or ratchet mechanism is also possible. The actuator is constituted by a combination of an electric motor and a cam mechanism, for example, but may be other driving mechanisms such as a hydraulic cylinder mechanism and a gear mechanism instead of this.

For example, the transmission can be provided with a parking lock 7, but alternatively also other gear mechanisms in the gear system can be provided with a parking lock 7. In addition, one vehicle may be provided with a plurality of parking locks.

For example, a mechanical switch or a contact or non-contact sensor for detecting the physical position of the object can be used in the detection unit 9, and when the parking lock 7 is a mechanism using a pawl, the switch or the sensor detects the position of the pawl. The parking lock ECU11 detects whether the parking lock is locked by electrically connecting with the above-described switch or sensor. Alternatively, the detection unit 9 may be a sensor that reads a current or a voltage applied to the actuator, in which case the detection unit 9 is not limited to being provided inside the transmission but may be provided outside the transmission, and particularly the ECU11 may include the detection unit 9. Alternatively, or in place of direct detection, the ECU11 may take the states of a plurality of switches, sensors, and/or actuators as variables, and use a combination of these variables to determine whether or not the parking lock 7 is locked.

Referring to fig. 2 in combination with fig. 1, the parking lock ECU11 performs control as follows when locking the parking lock 7.

The parking lock ECU11 reads the state of the parking lock 7 (for example, whether it is locked or unlocked) and the state of the power supply (for example, on when the voltage is high and off when the voltage is low) via the sensors, and stably and repeatedly communicates with other ECUs. The communicated information includes various requests such as a parking lock request, a stop request, and the like, and also includes a parking lock completion notification.

The state of the parking lock 7 read or inferred by the detection unit 9 is stored, for example, in the Act _ Position variable. The parking lock completion notification is stored in the Park _ Position variable, for example, in the form of a flag, which is sent from the ECU11 to other ECUs as a notification via communication and utilized there.

Requests to the ECU11 (e.g., park lock, shut down, etc.) are stored in the Request variable. The Request for parking lock and the Request for releasing are not limited to the Request from the ECU11, and the ECU11 may determine the state variables of the switches, sensors, actuators, and other devices from the line and store the state variables as Request variables. The state of the Power supply may be determined by the ECU11 based on the value of the applied Power supply voltage (on if the voltage is high, Off if the voltage is low), stored in the Power _ Off variable (on if 0, Off if 1, for example), or may be acquired from another ECU by communication.

The ECU11 determines whether or not the Power is on (whether or not the Power _ Off variable is 0), and when the Power is on, it then determines whether or not there is a parking lock Request (whether or not the Request variable is "parking"). When there is a parking lock request, the ECU11 determines the state of the parking lock 7, and when the parking lock 7 is locked (Act _ Position variable is "parking"), it does not perform any control on the parking lock 7 (already locked). If the parking lock 7 is not locked (Act _ Position variable is not "parking"), control is performed to lock the parking lock 7.

The control of locking the parking lock 7 is illustrated in fig. 3. That is, to lock the parking lock 7, the ECU11 applies current to the actuator and drives the actuator. Next, the ECU11 determines whether the parking lock 7 is locked by the detection means 9, and repeatedly applies a current to the actuator if the parking lock 7 is not locked. If the lock is confirmed, the control returns to the original state.

Referring back to fig. 2, if the determination of whether or not there is a parking lock Request is "no", the ECU11 can determine again whether or not there is a Request to release the parking lock (whether or not the Request variable is not "parking"). When there is a request to release the parking lock, the ECU11 determines the state of the parking lock 7, and performs control to release the locking of the parking lock 7 when the parking lock 7 is not locked (Act _ Position variable is not "parking"), but the parking lock 7 is locked (Act _ Position variable is "parking").

Alternatively, the control at this time can be modified as shown in fig. 5. That is, the ECU11 determines whether or not there is a Request to release the parking lock (whether or not the Request variable is not "parking") again, determines whether or not there is a parking lock completion notification (whether or not the value of the Park _ Position variable is 1), and if both are positive (yes in the drawing), then the ECU11 determines the state of the parking lock 7, and if the vehicle lock 7 is not locked (the Act _ Position variable is not "parking"), does not perform any control on the parking lock 7, but if the parking lock 7 is locked (the Act _ Position variable is "parking"), performs control to release the locking of the parking lock 7. On the other hand, if there is no request to release the parking lock or no notification of completion of the parking lock, the ECU11 returns the control to the original state without any operation of the parking lock 7.

The control of releasing the lock of the parking lock 7 is illustrated in fig. 4. That is, to unlock the parking lock 7, the ECU11 applies a current to the actuator and drives the actuator. Next, the ECU11 determines whether the parking lock 7 is unlocked by the detection means 9, and repeatedly applies a current to the actuator if the parking lock 7 is not unlocked. If the unlocking is confirmed, the control is returned to the original state.

Referring back to fig. 2, even when the ECU11 determines that the Power supply is Off (Power _ Off variable is 1), the parking lock 7 is controlled based on whether or not there is a parking lock request and whether or not the parking lock 7 is locked, in the same manner as described above. In this case, if there is no parking lock request, the ECU11 returns the control to the original state without any operation of the parking lock 7. When the parking lock request is made, the control of the parking lock 7 is continued, a flag, for example, 1 is set for the Park _ Position variable, and the control is returned to the original state. This variable is shared by other ECUs through communication as described above, and is used to notify the other ECUs of completion of parking lock.

Referring to fig. 6, the other ECU (for example, ECU13) or two or more other ECUs that control the stop operation stop each ECU as follows.

This ECU also reads the state (on or off) of the ignition switch 3 via a sensor, and stably repeats communication with other ECUs. The state of the ignition switch is stored in the IGN variable, for example. The parking lock completion notification is stored in the Park _ Position variable, for example, in the form of a flag, and the ECU acquires the variable in advance through communication, for example.

The ECU determines whether or not the ignition switch 3 is Off, and if not Off (the IGN variable is not Off), sets the Power _ Off variable to 0, and returns the control to the original state. This is shared by the ECU11 through communication, and is used for control by the ECU11 described above. Alternatively, as described above, the ECU11 can directly read the state of the ignition switch 3. When the ignition switch 3 is Off (the IGN variable is "Off"), the Power _ Off variable is set to 1, and it is determined whether or not the stop condition is satisfied (the process surrounded by the one-dot chain line in fig. 6).

Whether or not the shutdown condition is satisfied can be judged most simply by whether or not there is a shutdown Request (whether or not the Request variable is "shutdown"). If the stop condition is not satisfied, no processing is performed, and the control is returned to the original state. That is, the vehicle 1 is maintained in a state in which the running can be continued. When the stop condition is satisfied, the control is shifted to the parking lock and the stop control as described later.

Whether or not the stop condition is satisfied can be modified as shown in fig. 7A. That is, it is first determined whether CAN communication is in a defective state ("failure"), and it is determined whether a shutdown request is present only if the CAN communication is not in a "failure". In the case of "failure", the control is shifted to parking lock and shutdown control regardless of the presence or absence of a shutdown request.

Alternatively, in any of the above examples, instead of determining whether or not there is a stop request, it may be determined whether or not the vehicle 1 is stopped. Fig. 7B is referred to as a modification of fig. 7A. The Vehicle Speed is stored in the Vehicle _ Speed variable, and the Position of the gear selector (for example, P in the case of the parking Position) is stored in the Shift _ Position variable, and is shared with other ECUs by communication. For example, when the vehicle speed is less than a certain threshold value (Xkph), or the gear selector is in the parking position, or any condition is satisfied, it can be determined that the vehicle 1 is stopped, and it can be determined that the stop condition is satisfied. According to the above modification, even if a request is erroneously received from another ECU, the ECU11 can autonomously determine the stop condition without being affected by the request.

Referring back to fig. 6, according to any of the above examples, when the stop condition is satisfied, the control is shifted to parking lock and stop. That is, first, the ECU13 determines whether the ECU11 has completed the parking lock according to the Park _ Position variable shared through communication. Upon completion (Park _ Position variable is 1), the ECU13 moves to stop control.

In a case where the ECU13 cannot confirm completion of the parking lock, a parking lock request is issued to the ECU11 in order to execute the parking lock. That is, for example, the Request variable is set to "park" and CAN communication is executed. The ECU11 responds with the parking lock 7 being locked and the parking lock being completed (the Park _ Position variable is 1) in accordance with the procedure described above. The ECU13 determines whether the parking lock is completed, and repeats the CAN communication until completion. In the case where the parking lock is completed (the Park _ Position variable is 1), the ECU13 will request a purge.

In the stop control, the ECU11 normally clears each variable (e.g., the Park _ Position variable and the Power _ Off variable) to execute the stop.

As can be understood from the above, the ECU11 autonomously makes a judgment to lock the parking lock 7, independent of a stop request sent from another ECU. Even if another ECU erroneously transmits a stop request or CAN communication is in a defective state, the vehicle CAN be reliably locked in parking without being affected by the error. Further, since the control described above necessarily precedes the stop, the parked vehicle does not move accidentally, as in the prior art. Since the control is performed mainly using information that CAN be received through normal CAN communication, additional information and devices are not required, and thus the above-described device or method CAN be directly replaced with an existing device or method. In addition, the parking lock can be reliably performed when there is a request for the parking lock, and in the case where this is not the case, the parking lock is not performed, and even if the lock is erroneously released, the operation of the vehicle is not hindered.

Although several embodiments have been described, modifications and variations of the embodiments can be made based on the disclosure.

Industrial applicability

The invention provides an electronic control device and a control method for autonomously executing parking lock regardless of a bad communication state.

Claims

1. An electronic control device connected to a power source of a vehicle and connected to one or more other electronic control devices for sharing information by communication to control a parking lock,

it is characterized in that the preparation method is characterized in that,

the electronic control device includes:

a locking unit that locks the parking lock if it is detected that the power supply is turned off, the information includes a parking lock request, and the parking lock is not locked; and

and a parking lock detection unit that, if it is detected that the parking lock is locked, causes the information to include a parking lock completion notification.

2. The electronic control device according to claim 1,

the electronic control device further includes a second locking unit configured to lock the parking lock when it is detected that the power supply is not turned off, the information includes the parking lock request, and the parking lock is not locked.

3. The electronic control device according to claim 1 or 2,

the electronic control device further includes a release unit configured to release the parking lock when it is detected that the power supply is not turned off, the information does not include the parking lock request, and the parking lock is locked.

4. The electronic control device according to claim 1 or 2,

the electronic control device further includes a release unit configured to release the parking lock when it is detected that the information includes a parking lock release request and the parking lock is locked.

5. A method for controlling a parking lock, which is executed by an electronic control device that detects the power source of a vehicle and the state of the parking lock and shares information including at least one request with one or more other electronic control devices through communication,

it is characterized in that the preparation method is characterized in that,

the method for controlling the parking lock comprises the following steps:

locking the parking lock if it is detected that the power supply is cut off, the information includes a parking lock request, and the parking lock is not locked; and

detecting whether the parking lock is locked.

6. The method of controlling a parking lock according to claim 5,

the method for controlling the parking lock further comprises the following steps:

locking the parking lock if it is detected that the parking lock is not locked when the power is not cut off and the information includes the parking lock request.

7. The method of controlling a parking lock according to claim 5 or 6,

and if it is detected that the power supply is not cut off, the information does not include the parking lock request, and the parking lock is locked, releasing the parking lock.

8. The method of controlling a parking lock according to claim 5 or 6,

and if the information is detected to contain a parking lock releasing request and the parking lock is locked, releasing the parking lock.