Method and device for drive damping using a vehicle-cloud-vehicle system

Abstract

Vehicle (31) comprising the following: an energy source; a gearbox (624); a clutch (618, 622) that selectively couples the energy source to the transmission (624); and at least one controller (704) programmed to (i) send route information, including road condition data of a road segment, to a remote facility, (ii) subsequently receive the road condition data from the remote facility, and (iii) modify a clutch pressure of the clutch (618, 622) based on the received road condition data.

Description

[0001] The present disclosure relates generally to a vehicle with a vehicle-cloud-vehicle system for drive damping in the vehicle.

[0002] Vehicle-to-consumer (V2C) communication systems feature a wireless communication device capable of transmitting data to and from a decentralized or remote location (i.e., the cloud). V2C systems are becoming increasingly prevalent as more communication technologies are integrated into vehicles. Infotainment systems are typically the only in-vehicle system to incorporate this type of external interaction with remote sources.

[0003] US 2010 / 0030437 A1 discloses a method for adapting the wiring diagram of an automatic transmission based on GPS / map data. DE 102009035103 A1 discloses a method for controlling a vehicle powertrain by monitoring map preview information. DE 10040423 A1 discloses a control device for an automatic transmission. DE 102007036794 A1 discloses a method for determining the driving strategy of a vehicle. EP 2057534 B1 discloses a traction control system for four-wheel / all-wheel drive vehicles. DE 102012214390 A1 discloses a method and devices for a vehicle-to-cloud-to-vehicle control system.

[0004] The implementation of V2C communication with powertrain components is largely unused. One reason for this is that internal control systems in the vehicle can operate in a real-time environment with extremely fast communication speeds, which is particularly important for the operation of powertrain components. Internet systems, on the other hand, often have independent databases and facilities that operate at slower speeds due to capacity limitations and the volume of data transmissions with other vehicles. Consequently, V2C communication systems typically operate on demand, unlike the continuous operation of internal control systems in the vehicle.

[0005] The object of the invention is to equip a vehicle comprising an energy source, a transmission and a clutch with V2C communication in such a way that the operation of the powertrain components is optimized to reduce drive disturbances.

[0006] According to one embodiment, a vehicle comprises a power source, a transmission, and a clutch that selectively couples the power source to the transmission. At least one controller is programmed to send route information, including road condition data, to a remote device. The at least one controller is further programmed to subsequently receive the road condition data from the remote device and modify the clutch pressure based on the received road condition data.

[0007] According to at least one embodiment, the travel route information also includes the vehicle's position.

[0008] According to at least one embodiment, the road condition data includes data received from a suspension system indicating the terrain of the road segment, data received from a braking system indicating brake usage during a journey across the road segment, and / or data indicating accelerator pedal usage during a journey across the road segment. Fig. Figure 1 represents an example of a vehicle data processing system; Fig. 2A represents an example of a vehicle computing system (VCS) communicating with the cloud; Fig. 2B represents another example of a VCS communicating with the cloud; Fig. Figure 3 is a flowchart of an example process for V2C cloud communication; Fig. Figure 4 is a flowchart of an exemplary process for obtaining route information when a vehicle operator has not entered a specific route; Fig. Figure 5 is a flowchart of an example process for predicting a route; Fig. Figure 6 shows a schematic diagram of a vehicle according to one embodiment; Fig. Figure 7 shows a diagram of a communication strategy between different vehicle components with controllers that communicate with the cloud; and Fig. Figure 8 is a flowchart of an exemplary procedure implemented by at least one controller, according to one embodiment.

[0009] Embodiments of the present disclosure are described herein. However, it is understood that the disclosed embodiments are merely examples and that other embodiments may take different and alternative forms. The figures are not necessarily to scale; some features may be exaggerated or minimized to show details of certain components. Consequently, specific structural and functional details disclosed herein should not be considered limiting, but merely as a representative basis for teaching a person skilled in the art the various uses of the present invention.As average persons skilled in the art will understand, various features illustrated and described with reference to any one of the figures can be combined with features illustrated in one or more other figures to produce embodiments not expressly illustrated or described. The combinations of illustrated features provide representative embodiments for typical applications. However, various combinations and modifications of the features, consistent with the teachings of this disclosure, may be desirable for certain applications or implementations.

[0010] Fig. Figure 1 presents an exemplary block topology for a vehicle-based computing system (VCS) 1 for a vehicle 31. An example of such a vehicle-based computing system 1 is the SYNC system manufactured by THE FORD MOTOR COMPANY. A vehicle equipped with a vehicle-based computing system may include a visual front-end interface 4 located within the vehicle. The user may also be able to interact with the interface, for example, if it is equipped with a touchscreen. In another illustrative embodiment, interaction occurs through keystrokes, acoustic speech, and speech synthesis.

[0011] In the Fig. In the illustrative embodiment shown in Figure 1, a processor 3 controls at least part of the operation of the vehicle-based data processing system. The processor 3 provided in the vehicle 31 enables the onboard processing of instructions and routines. Furthermore, the processor 3 is connected to both a non-permanent memory 5 and a permanent memory 7. In this illustrative embodiment, the non-permanent memory 5 is random access memory (RAM), and the permanent memory 7 is a hard disk drive (HDD) or flash memory.

[0012] The processor 3 is also provided with a number of different inputs that allow the user to establish a connection with the processor 3. In this illustrative embodiment, a microphone 29, an auxiliary input 25 (for an input 33), a USB input 23, a GPS input 24, and a BLUETOOTH input 15 are all provided. An input selector 51 is also provided to allow the user to switch between different inputs. An input to both the microphone and the auxiliary input is converted from analog to digital by a converter 27 before being routed to the processor 3. Although not shown, numerous vehicle components and auxiliary components can communicate with the VCS 1 using a vehicle network (such as—but not limited to—a CAN bus) to route data to and from the VCS 1 (or components thereof).

[0013] Outputs to the system can include, but are not limited to, an optical display 4 and a speaker 13 or a stereo system output. The speaker 13 is connected to an amplifier 11 and receives its signal from the processor 3 through a digital-to-analog converter 9. Output can also be made to a remote BLUETOOTH device, such as a PND 54, or a USB device, such as a vehicle navigation device 60, along the bidirectional data streams shown at 19 and 21, respectively.

[0014] In an illustrative embodiment, the system 1 uses the BLUETOOTH transceiver 15 to communicate with a user's nomadic device 53 (e.g., mobile phone, smartphone, PDA, or any other device with wireless remote network connectivity) 17. The nomadic device can then be used to communicate with a network 61 outside the vehicle 31, for example, by communicating 55 with a cell tower 57 59. In some embodiments, the tower 57 can be a WiFi access point.

[0015] An example of communication between the nomadic device and the BLUETOOTH transceiver is represented by signal 14.

[0016] Pairing a nomadic device 53 and the BLUETOOTH transceiver 15 can be instructed by pressing a key 52 or a similar input.

[0017] Accordingly, CPU 3 is instructed to pair the onboard BLUETOOTH transceiver with a BLUETOOTH transceiver in a nomadic device.

[0018] Data can be transmitted between the CPU 3 and the network 61 using, for example, a data plan, data-over-voice, or DTMF tones associated with the nomadic device 53. Alternatively, it may be desirable to integrate an onboard modem 63 with an antenna 18 to transmit data between the CPU 3 and the network 61 via the voice band 16. The nomadic device 53 can then be used to communicate with a network 61 outside the vehicle 31, for example, by means of a communication 55 with a mobile phone mast 57 59. In some embodiments, the modem 63 can establish a communication 20 with the mast 57 to communicate with the network 61. As a non-limiting example, the modem 63 can be a USB mobile modem, and the communication 20 can be a mobile phone communication.

[0019] In an illustrative embodiment, the processor is equipped with an operating system that includes an API for communicating with modem application software. The modem application software can access an embedded module or firmware on the Bluetooth transceiver to establish wireless communication with a remote Bluetooth transceiver (such as one found in a mobile device). Bluetooth is a subset of the IEEE 802 PAN protocols (PAN = personal area network). IEEE 802 LAN protocols (LAN = local area network) include Wi-Fi and have considerable cross-functionality with IEEE 802 PAN. Both are suitable for wireless communication within a vehicle. Other communication methods that can be used in this area include free-space optical communication (such as IrDA) and non-standard consumer IR protocols.

[0020] In another embodiment, the nomadic device 53 includes a modem for voice-band or broadband data communication. In the data-over-voice embodiment, a technique known as frequency-division multiplexing (FDM) can be implemented, allowing the operator of the nomadic device to speak over the device while data is being transmitted. At other times, when the operator is not using the device, the data transmission can utilize the entire bandwidth (in one example, 300 Hz to 3.4 kHz). Although FDM may be common and still used for analog cellular communication between the vehicle and the internet, it has been largely superseded by hybrid code-domain multiple access (CDMA), time-domain multiple access (TDMA), and space-domain multiple access (SDMA) techniques for digital cellular communication.These are all ITU-IMT-2000 compliant (3G-compliant) standards, and they offer data transmission speeds of up to 2 MB / s for stationary or walking users and 385 KB / s for users in a moving vehicle. 3G standards are now being replaced by IMT-Advanced (4G), which offers 100 MB / s for users in a vehicle and 1 GB / s for stationary users.

[0021] If the user has a data plan associated with the nomadic device, it is possible that the data plan allows for broadband transmission, and the system could utilize a much wider bandwidth (thereby accelerating data transmission). In yet another embodiment, the nomadic device 53 is replaced by a cellular communication device (not shown) installed on the vehicle 31. In yet another embodiment, the nomadic device 53 can be a wireless LAN device (LAN = local area network) capable of communicating via, for example (and without limitation), an 802.11g network (i.e., WiFi) or a WiMAX network.

[0022] In one embodiment, incoming data can be routed through the nomadic device 53 via a data-over-voice connection or a data plan, through the on-board Bluetooth transceiver, and into the vehicle's processor 3. In the case of certain temporary data, for example, the data can be stored on the HDD or another storage medium 7 until the data is no longer needed.

[0023] Additional sources that can connect to the vehicle include a personal navigation device 54 with, for example, a USB connection 56 and / or an antenna 58, a vehicle navigation device 60 with a USB connection 62 or other connection, an on-board GPS device 24, or a remote navigation system (not shown) with connectivity to the network 61. USB is one of a class of serial networking protocols. IEEE 1394 (FireWire), EIA (Electronics Industry Association) serial protocols, IEEE 1284 (Centronics Port), S / PDIF (Sony / Philips Digital Interconnect Format), and USB-IF (USB Implementers Forum) form the backbone of serial device-to-device standards. Most of these protocols can be implemented for either electrical or optical communication.

[0024] Furthermore, the CPU 3 can communicate with a variety of other assistive devices 65. These devices can be connected via a wireless connection 67 or a wired connection 69. The assistive devices 65 can include, but are not limited to, personal media players, wireless health devices, portable computers, and the like.

[0025] Alternatively, or in addition, the CPU 3 can be connected to a vehicle-based wireless router 73 using, for example, a WiFi transceiver 71. This could allow the CPU to connect to remote networks within range of the local router 73.

[0026] In addition to exemplary operations performed by a vehicle data processing system located in a vehicle, in certain embodiments the exemplary operations may be performed by a data processing system in communication with a vehicle data processing system. Such a system may include, but is not limited to, a wireless device (e.g., and without limitation, a mobile phone) or a remote data processing system (e.g., and without limitation, a server) connected by the wireless device. Collectively, such systems may be referred to as vehicle-associated computing systems (VACS). In certain embodiments, specific components of the VACS may perform certain parts of an operation, depending on the specific implementation of the system.By way of example, and not as a limitation, if an operation involves a step of sending or receiving information with a paired wireless device, it is likely that the wireless device will not perform the operation, since the wireless device would not "send and receive" information with itself. An average person will understand when it is inappropriate to apply a particular VACS to a given solution. In all solutions, consideration is given to the possibility that at least the vehicle computing system (VCS) located in the vehicle itself can perform the exemplary operations.

[0027] In the illustrative embodiments, an on-board vehicle cloud implementation (V2C implementation) is introduced. The V2C communicates with a powertrain in the same way as other electronic control units (ECUs) using local communication channels, such as—but not limited to—a CAN bus. The V2C can also communicate with cloud-based data processing services via cellular communication channels. In at least one embodiment, the V2C is more than a simple relay; it actively processes and transforms data from one system to feed into another and can perform fault handling.

[0028] Fig. Figure 2A shows an example of a vehicle computing system (VCS) communicating with the cloud. In this example, a vehicle 280 has both a vehicle-to-cloud (V2C) system 282 and a powertrain control system 284 embedded within it. The V2C system allows the driver to request remote computations from the cloud. In this illustrative example, the remote computation might involve, for instance, a planned destination as predicted by a prediction process running in a cloud-based remote processing instance 286. In this example, the prediction process might utilize one or more remote resources, such as a database 290 or other cloud-based data resources 288. The prediction process is described in terms of the Fig. 4 and Fig. 5. Described in more detail. Due to its two-way communication with the cloud, the system can also be described as a vehicle-cloud-vehicle system.

[0029] Fig. Figure 2B shows another example of an illustrative V2C system. In this illustrative example, the V2C communicates with a sample cloud computing resource capable of cloud-based processing. In this example, the cloud computing resource can perform any requested computation.

[0030] The cloud data processing resource can, for example, without restriction, use one or more optimization algorithms 296 provided by an original equipment manufacturer (OEM). These algorithms can be stored and / or updated from an on-premises database 298, which the OEM updates as needed. The data processing resource 292 can also access data from the cloud 294 as needed to complete the calculation.

[0031] Fig. Figure 3 illustrates a process for V2C cloud communication in relation to powertrain control. Although the illustrative examples focus on powertrain control, cloud computing can be used similarly to optimize other vehicle systems.

[0032] In this illustrative example, a driver first activates a function 301 that requires or uses cloud-based optimization. In this particular example, the function relates to powertrain optimization. Because powertrain optimization can require numerous and intensive calculations, in this example, the calculations are performed externally to the vehicle in the cloud and forwarded to the V2C system. This also allows the computing system to easily access cloud-based data resources, such as—but not limited to—topographic maps, weather data systems, and so on.

[0033] Once the function is enabled, the V2C can initiate a connection to the internet (303) to connect to a process for performing a desired calculation. In this example, the V2C uploads context-relevant information (305). For example, with regard to a powertrain calculation, it might be useful to know the vehicle's position and planned route. Other data might also be useful, and the data can vary depending on the calculations being performed.

[0034] Next, in this embodiment, a requested cloud-based computation is created (or referenced if it has already been created and stored) 307. In this illustrative example, the computation relates to the strategy requested by the V2C. The computation may also require vehicle state / status inputs from the V2C, which can be uploaded by the vehicle 309. Next, in this process, the cloud-based algorithm produces a higher-level control directive 311. This is a general powertrain strategy, but in this example, it could not be directly fed to the powertrain.

[0035] This directive is sent to the V2C 313 and will provide a powertrain control strategy. Because the V2C has access to the current powertrain state at all times (as opposed to having to forward this information to the cloud), it is better positioned to determine precisely when and if the strategy should be implemented. Deviations from a route can also change the state and desirability of the strategy, and the V2C is equipped to respond better to such changes due to the forwarding time. The strategy can be provided to the cloud in a command language; however, the user experience, at least with regard to current transmission speeds, dropped packets, and latency, can be better served by leaving the translation to the V2C.

[0036] Once the V2C has the higher directives, it can generate control signals for use by the powertrain and send them to the powertrain 315. These signals can be quickly received and acted upon by the powertrain and can also be adapted to changing road / vehicle conditions. In this embodiment, the process then checks to ensure that the function is still enabled. For example, if the torque converter lock-up clutch is locked—without restriction—it may be preferable to allow the clutch to slip based on the road conditions. If the function is disabled, 323 in this embodiment, the process interrupts and terminates the execution of the commands.

[0037] If the function is still activated, it is also possible that the vehicle's state has changed considerably 319. For example, the vehicle may have left the known route or taken a new route – without restriction. Alternatively or additionally, a new function may have been used, or the context of a function may have changed (e.g., – without restriction – the lock-up clutch has been disengaged and has started to slip). If such a change in context has occurred 321, a new session and a new control strategy may be required.

[0038] If no change in state occurs, the V2C can upload new data to the cloud in an effort to maintain constant updates to the control directives. This rapid, dynamic updating enables, among other things, more efficient fuel consumption. It would also be possible, for example, to maintain a single control strategy and stick with it for an extended period; however, with cloud access available, the more dynamically the data can be updated, the easier it will be to ensure that the strategy is as close to optimum as possible.

[0039] Fig. Figure 4 shows an illustrative example of a process for obtaining route information when the user has not entered a specific route. This illustrative example uses a prediction process. The prediction process considers one or more factors relating to the user's current state (e.g., without limitation, time of day, current location, etc.). Based at least in part on information matches relating to the considered factors, the system can attempt to predict or guess where the user plans to travel.

[0040] First, the process checks if a route has been entered by the user (401). If the user has entered a route, no prediction is needed, so the process can simply use the entered route (403).

[0041] If no route has been entered, the process can attempt to predict one (405). Since the process may not know definitively where the user intends to travel, if the prediction attempt is successful (407), the process can confirm a predicted destination (409). If the user agrees (411), the process can use a route to the predicted destination as a route to travel (413). If the user does not agree, the process can attempt another prediction, discarding the first prediction from the set of possible destinations.

[0042] In at least one illustrative example, data recording devices can log the usage of a vehicle. While logging usage, they can also record times, weather data, other environmental data, travel dates, etc. Once sufficient data has been collected for a particular vehicle, predictive route planning can be implemented. Fig. Figure 5 shows an illustrative example of a prediction process.

[0043] In the Fig. In the example shown, one or more driver data blocks stored in a database are accessed. As noted, this data may have been collected over time and stored in relation to a vehicle or even a specific driver.

[0044] Element 503 of Fig. Figure 5 shows some illustrative, non-restrictive examples of factors that can be considered when determining a likely route. In this example, the process checks if a current time is known (511), and if so, the process will include the time in the prediction (513) by, for example, determining where the driver or vehicle usually travels at that known time. In this example, the process also checks if a vehicle position is known (515). If the position is known, the process can include the position in a prediction (517). For example, if it is 6:00 AM and the user's home location is [location omitted], and it is a weekday, there is a good chance that the vehicle might be going to work, school, etc. Other factors not shown can also be considered.

[0045] In another example involving different factors, it is common for people not to always travel to the same places, for example, on weekends. However, if someone usually goes to the cinema every Sunday when it rains, getting into the vehicle on a rainy Sunday afternoon can generate a prediction that the vehicle is going to the cinema. By taking into account a variety of geographical, temporal, and / or environmental factors, suitable predictions of destinations can be made. This also allows a user to utilize systems such as the capabilities of the present invention without having to input a destination each time a vehicle is used.

[0046] Route planning generation methods, as in the Fig. 4 and Fig. As described in section 5, these systems enable the vehicle to retrieve information about the road conditions of upcoming roads. For example, based on the upcoming route, the vehicle can determine whether the roads ahead are gravel, windy, uneven, level, etc. Based on this knowledge and other factors discussed, the vehicle can prepare for the upcoming road conditions by initiating actions in the vehicle's powertrain or drive system before reaching the specified road condition. Further details of embodiments of such a system are described in section 5. Fig. 6 - 7 discussed.

[0047] With reference to Fig. Figure 6 is a schematic diagram of an example of a hybrid vehicle 610 in which the VCS 1 can be used. The vehicle 610 has a motor 612 and an electric machine, which is located in the Fig. The embodiment shown in Figure 6 is a motor generator (MG) 614, which can alternatively be a traction motor. The MG 614 is configured to transmit torque to the motor 612 or to the vehicle wheels 616.

[0048] The MG 614 is connected to the engine 612 using a first clutch 618, also known as a release clutch or the upstream clutch. A second clutch 622, also known as a launch clutch or the downstream clutch, connects the MG 614 to a transmission 624, and all input torque to the transmission 624 flows through the launch clutch 622. Although the clutches 618 and 622 are described and illustrated as hydraulic clutches, other types of clutches, such as electromechanical clutches, can also be used. Alternatively, the clutch 622 can be a torque converter lock-up clutch connected to a torque converter 623, as described below. The downstream clutch 622 therefore refers to various clutch devices for the vehicle 610, including a traditional clutch and a torque converter lock-up clutch.This configuration can use an otherwise conventional stepped automatic transmission with a torque converter and is sometimes referred to as a modular hybrid transmission configuration.

[0049] The output shaft of the motor 612 is connected to the release clutch 618, which in turn is connected to the input shaft for the motor 614. The output shaft of the motor 614 is connected to the starting clutch 622, which in turn is connected to the transmission 624. The various components of the vehicle 10 are positioned sequentially in series. The starting clutch 622 connects the vehicle's power units to the drive unit 626, which includes the transmission 624, a differential 628, and vehicle wheels 616 and their connecting components. In other embodiments, the method described herein can be applied to a hybrid vehicle with different system architectures.

[0050] In some embodiments, the transmission 624 is an automatic transmission and is connected to the drive wheels 616 in a conventional manner and may include a differential 628. The vehicle 610 is also provided with a pair of non-driven wheels; however, in alternative embodiments, a transfer case and a second differential can be used to positively drive all vehicle wheels.

[0051] As previously described, the downstream clutch 622 in various embodiments of the vehicle 610 is a lock-up clutch connected to a torque converter 23. The input from the MG 614 is the impeller side of the torque converter 623, and the output from the torque converter 623 to the transmission 624 is the turbine side of the torque converter 623. The torque converter 623 transmits torque using its fluid coupling, and torque multiplication can occur depending on the degree of slip between the impeller side and the turbine side.

[0052] The torque converter 623 exhibits torque multiplication effects when certain differential rotational speeds exist across the torque converter 623. During torque multiplication, the output torque of the torque converter is greater than the input torque due to the torque multiplication effect across the torque converter 623. For example, torque multiplication occurs when the vehicle 610 is started from a standstill and the input shaft to the torque converter 623 begins to rotate, while the output shaft from the torque converter 623 is still at rest or has just begun to rotate.

[0053] The lock-up clutch or bypass clutch 622 for the torque converter 623 can be selectively engaged to create a mechanical or frictional connection between the impeller side and the turbine side for direct torque transmission. The bypass clutch 622 can be allowed to slip and / or be opened to control the amount of torque transmitted by the torque converter 623. The torque converter 623 may also additionally include a mechanical lock-up clutch or freewheel clutch.

[0054] The lock-up clutch 622 is used to disengage the torque converter, so that the input torque and output torque for the downstream torque converter 623 are equal, and the input speed and output speed are equal across the torque converter 623. A locked clutch eliminates slippage and drive inefficiency across the torque converter 623, for example, when the speed ratio across the torque converter is higher than approximately 0.8, and can improve the fuel efficiency of the vehicle 10.

[0055] The MG 614 communicates with a battery 632. The battery 632 can be a high-current battery. The MG 614 can be configured to charge the battery 632 in a regeneration mode when, for example, the vehicle's power output exceeds the driver's needs due to regenerative braking or the like. The MG 614 can also be arranged in a generator configuration to moderate the amount of torque supplied by the motor 612 to the drive 626. In one example, the battery 632 is configured to connect to an external power grid, such as a plug-in hybrid electric vehicle (PHEV) with the capability to recharge the battery from an electrical grid that supplies power to a wall socket at a charging station.

[0056] The MG 614 and the clutches 618, 622 can be located within a motor-generator housing 634, which may be integrated into a housing for the transmission 624, or alternatively in a separate housing within the vehicle 610. The transmission 624 has a gearbox to provide different gear ratios for the vehicle 610. The gearbox of the transmission 624 can include clutches and planetary gear sets or other arrangements of clutches and gear trains known in the art. In alternative embodiments, the transmission 624 is a continuously variable transmission (CVT) or a mechanical automatic transmission. The transmission 624 can be a six-speed automatic transmission, another type of geared automatic transmission, or another type of drive transmission known in the art.

[0057] Various controllers can be provided anywhere in the vehicle 610. For example, a transmission control unit (TCU) 636 controls and operates the transmission 624 in a shift schedule, such as a production shift schedule, connecting and disconnecting elements in the gearbox to control the gear ratio between the transmission output and the transmission input. The TCU 636 can also control the gearbox 614, the clutches 618 and 622, and any other components in the motor-generator housing 634. An engine control unit (ECU) 638 is configured to control the operation of the engine 612. A vehicle system controller (VHC) 640 transmits data between the TCU 636 and the ECU 638 and also communicates with various vehicle sensors. These control units and other controllers can be collectively referred to as one or more controllers in a control system 642.Some or all of the controllers may be connected via a Controller Area Network (CAN) or another system. The control system 642 can be configured to control the operation of the various components of the gearbox 624, the motor-generator unit 634, the clutches 618 and 622, and the motor 612 under any number of different conditions.

[0058] For the purposes of this disclosure, it is understood that the in Fig. The vehicle 610 shown in Figure 6 is not limiting. Embodiments of the present disclosure can, for example, be applied to other hybrid arrangements as well as non-hybrid vehicles in which a torque converter lock-up clutch is used.

[0059] As previously described, it can be advantageous for the lock-up clutch 622 to be locked as often as possible for various reasons, including fuel efficiency. However, the TCU 636 can command the lock-up clutch 622 to slip in order to meet the torque demands of the vehicle's driver. In the Fig. In the hybrid vehicle shown in Figure 6, for example, when the motor 612 is deactivated, the torque of the MG 614 alone must meet the requirement. In these and other situations, the TCU 636 can command the lock-up clutch to slip in order to increase the torque delivered to the transmission 624 in order to meet the requirements.

[0060] According to embodiments of the present disclosure, the TCU 636 can command the lock-up clutch 622 to slip for various other reasons. For example, slipping the lock-up clutch 622 during changes in road type (e.g., from paved to gravel) smooths the transition between road types by dampening drive disturbances. By using data obtained from the cloud, the TCU 636 can command the lock-up clutch 622 to slip in anticipation of future road conditions (or allow the lock-up clutch 622 to slip when it would not otherwise do so).

[0061] Fig. Figure 7 shows a system in which the vehicle communicates with the data cloud 702 to anticipate future road conditions and provide preventive drive control based on upcoming driving conditions. As previously described, a controller 704, such as the V2C 282 or the VSC 640, communicates (bidirectional communication) with the data cloud 702. The controller 704 communicates with the GPS unit 24 according to the previously described procedure to determine the vehicle's position. The controller 704 can also communicate with a road category estimation system 706, a vehicle-mounted camera 708, and a radar / sonar device 710 on the vehicle. Driver inputs, such as an accelerator pedal request, a brake pedal request, etc., can also be sent to the controller 704, for example, from the VSC 640.During the journey, the controller 704 can send information received from one or more of these devices 24, 706, 708, 710, 712 to indicate classification, curves, changes in road conditions or types, etc.

[0062] During a future trip along previously traveled routes, data can be pulled from the 702 data cloud to estimate future road conditions based on data previously sent to the 702 data cloud. Based on this received data, the 704 controller can estimate future road conditions. For example, the 704 controller can anticipate a change from a paved road to a gravel road at a specific location based on data previously sent to the 702 data cloud during an earlier trip.

[0063] Based on anticipated road conditions, the VSC 640 can modify components in the vehicle. As previously described, an MG 614, an engine 612, a transmission 624, a lock-up clutch 622, and other powertrain components can be provided in the vehicle and controlled by a powertrain torque controller 714 and / or a transmission / clutch controller 716. Similarly, a chassis / brake controller can control vehicle brakes 720, shock absorbers or a suspension system 722, active engine mounts 724, etc. The VSC 640 can modify the state of these and other various components in the vehicle based on anticipated road conditions.

[0064] The torque converter lock-up clutch 622 can, for example, be allowed to slip during the transition from one road condition to another. This allows the vehicle to anticipate the road terrain and dampen or attenuate disturbances that would otherwise be felt in the vehicle. By removing the direct connection between the output of the gearbox 614 and the input of the transmission 624, disturbances in the road acting on the wheels 616 are not completely converted into disturbances in the gearbox 614, but rather are attenuated and absorbed by the torque converter 623 when the lock-up clutch 622 slips.If the lock-up clutch 622 slips, the VSC 640 or another controller can adjust the torque at the input to the gearbox 624 to compensate for the torque that was not fully transmitted through the slipping clutch to meet the driver's request. For the in . Fig. In the hybrid vehicle shown in Figure 6, for example, the controller can adjust the torque output from the engine and / or the MG such that the transmission drive torque generally corresponds to the combined torque from the engine and the MG to meet the driver's requirements while the lock-up clutch 622 is slipping.

[0065] In other examples, the vehicle's brakes 720, shock absorbers 722, or engine mounts 724 can be adjusted in anticipation of upcoming road conditions. Conditions for activating any of these devices can be relaxed, for instance, as the vehicle approaches a point on the road, allowing the devices to act more quickly or react more effectively when the change in road conditions actually occurs at that point. Similarly, the accelerator and / or brake pedal demands can be filtered at a reduced or increased rate in response to the upcoming road conditions, thus modifying the reaction time within which the vehicle accelerates or decelerates when it arrives at the road condition.

[0066] Fig.Figure 8 shows a flowchart illustrating a process used by at least one controller to communicate with the cloud and optimize drive components based on cloud data.

[0067] In the 802 protocol, the vehicle sends data to the cloud during a journey. The data sent to the cloud can include route information such as position, road condition data (e.g., uneven, flat, gravel, etc.), date, time, and other such information, as described previously by the methods outlined above.

[0068] During a later travel period, the controller at 804 determines whether the vehicle is near a location where data was previously sent to the cloud. In one embodiment, the vehicle is in continuous communication with the cloud or another remote facility, with the remote facility and / or the controller continuously checking position data to determine whether the vehicle is traveling a previously traveled route.

[0069] If the vehicle is traveling on a previously traveled route, the controller receives the route information from the cloud at 806. The controller and / or the cloud can then determine at 808 whether any upcoming road segment along the traveled route will change. For example, the controller can determine whether an uneven road surface lies ahead based on data about vehicle vibrations previously sent to the cloud.

[0070] If a change in the condition of an upcoming road segment is anticipated, the controller can modify a drivetrain component in anticipation of that segment. For example, the controller might allow the torque converter lock-up clutch to slip as the vehicle travels over the upcoming segment, even if it would not normally permit such slippage. This allows for immediate damping of drivetrain disturbances when the vehicle encounters irregularities in the road segment. In another example, the controller might command the lock-up clutch to slip while traveling over the segment, thus damping any disturbances in the drivetrain. Other modifications to drivetrain components are considered as described above, such as modifying the shock absorbers, brakes, or active engine mounts.

[0071] The processes, methods, or algorithms disclosed herein may be assigned to or implemented by a processing device, controller, or computer, which may contain any existing programmable electronic control unit or dedicated electronic control unit. Similarly, the processes, methods, or algorithms may be stored as data and instructions executable by a controller or computer in many forms, including, but not limited to, information permanently stored on non-writable storage media such as ROM devices, or information modifiably stored on writable storage media such as floppy disks, magnetic tapes, CDs, RAM devices, and other magnetic or optical media. The processes, methods, or algorithms may also be implemented in a software-executable object.Alternatively, the processes, procedures or algorithms can be embodied completely or partially using suitable hardware components, such as application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), state machines, controllers or other hardware components or devices, or a combination of hardware, software and firmware components.

[0072] Although exemplary embodiments are described above, it is not intended that these embodiments describe all possible forms encompassed by the claims. The words used in the specification are descriptive rather than limiting, and it is understood that various modifications may be made without altering the meaning and scope of the disclosure. As previously described, the features of different embodiments may be combined to form further embodiments of the invention that are not expressly described or illustrated.While various embodiments may have been described as providing advantages or being preferable over other embodiments or implementations of the prior art with respect to one or more desired characteristics, those skilled in the art recognize that a compromise may be made with respect to one or more features or characteristics in order to achieve desired overall system attributes, which depend on the specific application and implementation. These attributes may include, but are not limited to, cost, strength, durability, life-cycle costs, marketability, appearance, packaging, size, operability, weight, manufacturability, ease of installation, etc.As such, embodiments that have been described as less desirable than other embodiments or implementations of the prior art with respect to one or more characteristics are not outside the scope of protection of the disclosure and may be desirable for certain applications.

Claims

[1] Vehicle (31) comprising the following: an energy source; a gearbox (624); a clutch (618, 622) that selectively couples the energy source to the transmission (624); and at least one controller (704) programmed to (i) send route information, including road condition data of a road segment, to a remote facility, (ii) subsequently receive the road condition data from the remote facility, and (iii) modify a clutch pressure of the clutch (618, 622) based on the received road condition data. [2] Vehicle (31) according to claim 1, further comprising a torque converter (632) which is selectively coupled to the energy source, wherein the coupling (618, 622) is a converter lock-up clutch. [3] Vehicle (31) according to claim 1, wherein the energy source includes an electric machine which is selectively coupled to a motor (612) by means of a second coupling (622). [4] Vehicle (31) according to claim 1, further comprising a motor (612), wherein the energy source includes the motor (612) and / or an electric traction motor. [5] Vehicle (31) according to claim 1, wherein the road condition data includes data received by a suspension system (722) during a previous journey over the road segment. [6] Vehicle (31) according to claim 1, wherein the road condition data includes data received from a braking system indicating brake usage during a previous journey over the road segment. [7] Vehicle (31) according to claim 1, wherein the road condition data includes data indicating the use of the accelerator pedal during a previous journey over the road segment. [8] Vehicle (31) according to claim 1, wherein the at least one controller (704) is further programmed to increase the power output of the energy source in response to the modification of the clutch pressure.

Images