Patent Description:
It is with respect to these and other general considerations that embodiments have been described. While relatively specific problems have been discussed, it should be understood that the embodiments should not be limited to solving the specific problems identified in the background. <CIT> describes an adaptive cruise control system for a motor vehicle that adapts a suitable starting behavior of the vehicle in accordance with different driving environments, including road gradient and traffic changes.

The invention generally relates to systems, methods, and computer readable storage media for providing automated launch torque generation. For example, aspects of the present invention include an automated virtual launch (AVL-TG) system that may operate to automatically generate launch torque for moving a vehicle during a stationary or low speed launch situation where torque is required.

In one aspect, a method for providing automated launch torque is provided. In an example embodiment, the method comprises: receiving an indication to generate a launch torque request indicating a virtual operator launch torque demand to move a vehicle operating in adaptive cruise control mode to a cruise control handover speed; receiving a first signal indicating the vehicle's weight and a second signal indicating the vehicle's grade; determining a pedal saturation value based on the vehicle's weight and the vehicle's grade; receiving a third signal indicating an engine speed; determining a pedal ramp rate for a dynamic application of the pedal saturation value based at least in part on the engine speed; determining launch torque demand based on the pedal saturation value and the pedal ramp rate; and transmitting to one or more powertrain components one or more communications regarding the launch torque demand according to the pedal ramp rate to cause the vehicle to be launched to the cruise control handover speed.

In another aspect, a system is provided that is configured to provide automated launch torque. In an example embodiment, the system comprises at least one processor; a memory storage device, operatively connected to the at least one processor and including instructions that, when executed by the at least one processor, are configured to: receive an indication to generate a launch torque request indicating a virtual operator launch torque demand to move a vehicle operating in adaptive cruise control mode to a minimum threshold speed; receive a first signal indicating the vehicle's weight and a second signal indicating the vehicle's grade; determine a pedal saturation value based on the vehicle's weight and the vehicle's grade; receive a third signal indicating an engine speed; determine a pedal ramp rate for a dynamic application of the pedal saturation value based at least in part on the engine speed; determine launch torque demand based on the pedal saturation value and the pedal ramp rate; and transmit to one or more powertrain components one or more communications regarding the launch torque demand according to the pedal ramp rate to cause the vehicle to be launched to the minimum threshold speed.

In another aspect, a vehicle is provided that is configured to provide automated launch torque. In an example embodiment, the vehicle comprises a powertrain, at least one axle, operatively connected to the powertrain, at least two wheels, operatively connected to the at least one axle, and a system according to the previous aspect, operatively connected to the powertrain.

Non-limiting and non-exhaustive examples are described with reference to the following figures:.

Aspects of the present invention are generally directed to systems, methods, and vehicles for providing automated launch torque generation. An automated virtual launch (AVL-TG) system may operate to automatically generate launch torque for moving a vehicle, e.g., during a stationary or low speed launch situation where torque is required.

The detailed description set forth below in connection with the appended drawings is an illustrative and non-limiting description of various embodiments of the disclosed subject matter. Wherever possible, the same reference numbers are used in the drawings and the following description to refer to the same or similar elements.

The following detailed description does not limit the present invention, but instead, the proper scope of the present invention is defined by the appended claims. Examples may take the form of a hardware implementation, or an entirely software implementation, or an implementation combining software and hardware aspects. The following detailed description is, therefore, not to be taken in a limiting sense.

The following description proceeds with reference to examples of systems and methods suitable for use in vehicles, such as Class <NUM> trucks. Although illustrative embodiments of the present invention will be described hereinafter with reference to vehicles, it will be appreciated that aspects of the present invention have wide application, and therefore, may be suitable for use with many types of vehicles, such as trucks, passenger vehicles, buses, commercial vehicles, light and medium duty vehicles, etc..

With reference now to <FIG> , an example vehicle <NUM> is illustrated within which aspects of the present invention can be implemented. For example, <FIG> includes a side view of the vehicle <NUM> further including a schematic view of various components that may be included in the vehicle <NUM> that may operate as part of implementing automated virtual launch torque generation. In some examples, the vehicle <NUM> may be a heavy-duty truck such as a part of a tractor-trailer combination, which may include the vehicle <NUM> having, what is sometimes referred to as, a fifth wheel by which a box-like, flat-bed, or tanker semi-trailer <NUM> (among other examples) may be attached for transporting cargo or the like. While the vehicle <NUM> is depicted as a truck in <FIG> , it should be appreciated that the present technology is applicable to any type of vehicle where automated virtual launch torque generation is desired.

As shown, the example vehicle <NUM> includes a powertrain <NUM> (shown schematically). The powertrain <NUM> may operate to generate power and to convert the power into movement. For example, the powertrain <NUM> may include a power source, such as an engine, and various components that operate to convert the engine's power into movement of the vehicle (e.g. the transmission, driveshafts, differential, and axles). The powertrain <NUM> may be one of various types of powertrains (e.g., diesel, hydrogen fuel cell, battery electric). In some examples, the vehicle's transmission may be configured to close a clutch based on a set of received input criteria. In an example implementation and as will be described in further detail below, the input criteria may include a torque demand signal generated by an automated virtual launch torque generation (AVL-TG) system <NUM> included in the vehicle <NUM>.

The vehicle <NUM> may include a cruise control (CC) system. In some examples, the CC system is configured as an adaptive cruise control (ACC) system <NUM> that may operate to perform normal CC operations (e.g., maintain a selected (target cruise) speed of the vehicle <NUM> ) and may further operate to automatically adjust the speed of the vehicle <NUM> to maintain a safe distance from a preceding vehicle <NUM>. For example, without human intervention, the ACC system <NUM> may use various sensors <NUM> (e.g., radar sensors, laser sensors, cameras) to detect whether the vehicle <NUM> is approaching another vehicle ahead (e.g., preceding vehicle <NUM> ), to determine to automatically slow down the vehicle <NUM> from the target cruise speed to a lower speed or to a standstill to maintain a safe following distance, and to determine to automatically speed the vehicle <NUM> back up to the target cruise speed when traffic conditions allow.

According to an aspect, the vehicle <NUM> may include an AVL-TG system <NUM> that may interoperate with the ACC system <NUM> to generate torque requests that may be communicated to an interface for the powertrain <NUM> (herein referred to as a powertrain controller interface <NUM> ) for modulating the vehicle's speed during CC operation. As will be described in further detail below, in various examples, the AVL-TG system <NUM> may be operative or configured to generate launch torque requests for moving the vehicle <NUM> from a standstill or from a low speed where torque is required. The AVL-TG system <NUM> may be further configured to interoperate with other various existing systems installed on the vehicle <NUM> (e.g., antilock braking system (ABS), automated manual transmissions (AMTs), etc.,) such that the vehicle <NUM> can slow down and relaunch without driver input based on the actions of the preceding vehicle <NUM>. Example operations of the AVL-TG system <NUM> are described in further detail below with reference to <FIG>.

With reference now to <FIG> , an example operating environment is illustrated within which an example AVL-TG system <NUM> may operate. As shown, in some examples, the AVL-TG system <NUM> may operate in a vehicle electronic control unit (VECU) <NUM> of the vehicle <NUM>. For example, a VECU <NUM> including the AVL-TG system <NUM> may be operative or configured to house various CC related components that operate to automate the vehicle's torque (e.g., driving torque and retarding/braking torque) that may be generated by the vehicle's powertrain <NUM>. As used herein, the term "CC driving torque" may describe driving torque that may be requested by the ACC system <NUM> to automatically maintain or increase the speed of the vehicle <NUM> during CC and ACC operation, and the term "CC retarding torque" may describe torque that may be generated by an engine retarder or engine brake that may be requested by the ACC system <NUM> to automatically slow the vehicle <NUM> down during ACC operation. In some examples, the VECU <NUM> may be configured to generate requests (e.g., CC driving torque control requests and CC retarding torque control requests) that may be used to control the vehicle's powertrain <NUM> for automatically accelerating the vehicle <NUM> and slowing the vehicle <NUM>. As illustrated, the VECU <NUM> may be communicatively connected to the PCI <NUM><NUM> via an engine demand torque arbitrator (EDTA) <NUM> and a retarder control torque arbitrator (RCTA) <NUM> that may be included in the VECU <NUM>. For example, powertrain-related requests, such as CC driving torque control requests and CC retarding torque control requests, may be communicated to the PCI <NUM> for controlling the powertrain <NUM>.

As mentioned above with respect to <FIG> , the PCI <NUM><NUM> may operate as an interface for the powertrain <NUM>. For example, the PCI <NUM> may be operative or configured to receive powertrain-related requests from the VECU <NUM>, such as CC torque control requests and retarder torque control requests, and turn those requests into powertrain actions. The powertrain <NUM> may be one of a various types of powertrains, and the PCI <NUM><NUM> may operate as an intermediate layer between the VECU <NUM> (including the AVL-TG system <NUM> ) and the various types of powertrains. In some examples, a powertrain action may result in vehicle <NUM> motion (e.g., acceleration during normal CC and ACC operation to maintain a target cruise speed, launching from a stop or a low speed during a launch-on operation, or engine braking to slow the vehicle during normal ACC operation).

As shown, the AVL-TG system <NUM> may comprise a virtual tip-in VTI system, herein referred to as a VTI <NUM>, that may interoperate with the ACC system <NUM>. For example, the VTI <NUM> may be configured to interoperate with ACC torque generation architecture components (e.g., a cruise control speed controller (CC speed controller) <NUM>, a cruise control torque controller (CC torque controller) <NUM>, and a retarder control arbitrator <NUM> ). According to an aspect, during ACC operation, the VTI <NUM> may be configured to generate launch torque requests for moving the vehicle <NUM> from a standstill or from a low speed where torque is required. The launch torque requests may override normal CC torque demand that may be normally be determined by the CC torque controller <NUM>, such as to maintain a set CC cruise speed during regular CC operation. In some examples, the VTI <NUM> may track various ACC conditions and states to determine whether conditions are satisfied to generate CC launch torque and to determine a tip-in torque curve for providing launch torque comprising a dynamic pedal saturation level and ramp rate that may be configured to mimic the torque curve generated by a vehicle operator's pedal tip-in from a standstill or low speed.

In some examples, the tip-in torque curve determined by the VTI <NUM> may include a dynamic saturation value and a dynamic pedal saturation rate based on the vehicle weight and a current grade of the vehicle <NUM>. For example, a higher vehicle weight and/or grade may correspond with a quicker torque application. In some examples, the VTI <NUM> may be configured to generate launch torque requests when the actual speed of the vehicle <NUM> is below a minimum threshold level. In some examples, the minimum threshold level corresponds with a lower bound of a CC governor, and may sometimes be referred to herein as a CC handover speed, where torque demand control may be handed off between the VTI <NUM> and the CC torque controller <NUM>. For example, when the vehicle's actual speed reaches or exceeds the minimum threshold level, regular ACC torque operation may resume (e.g., the VTI <NUM> may discontinue generating and sending launch torque requests to the CC torque controller <NUM> ). Aspects associated with determining to generate a launch torque request and determining the tip-in torque curve for the launch torque demand are described in further detail below with reference to <FIG>.

As described above, the VTI <NUM> may interoperate with various ACC torque generation architecture components. For example, the CC speed controller <NUM> may operate to receive CC command information from a switch control switch arbitrator (SCSA) <NUM>, which may include CC on/off information, a target cruise speed setting, following distance level selection information, other CC switch information, retarder switch input, brake pedal input, and the like. The CC speed controller <NUM> may further operate to receive actual vehicle speed information from a sensor <NUM> included in the vehicle <NUM>, such as a vehicle speed sensor that may operate to transmit vehicle speed information to the VECU <NUM>. The CC speed controller <NUM> may further operate to determine a CC target cruise speed for regular CC operation based on the received information. The CC speed controller <NUM> may further operate to provide CC state information to other components. For example, the CC speed controller <NUM> may communicate the CC target cruise speed to the CC torque controller <NUM>. In some implementations, the CC target speed may be utilized as an input by the CC torque controller <NUM> for determining CC driving torque demand for the powertrain <NUM>. In some examples, the VTI <NUM> may be configured to communicate with the CC speed controller <NUM>. For example, when the VTI <NUM> determines that the vehicle speed has reached the CC handover speed, the VTI <NUM> may be configured to output a signal to the CC speed controller <NUM> that may operate as a virtual CC resume signal to hand over CC torque demand control to the CC torque controller <NUM>.

The CC torque controller <NUM> is illustrative of a software module, system, or device that may be operative or configured to determine a driving torque demand for CC operation. For example, the CC torque controller <NUM> may operate to determine CC torque demand that may be requested for moving the vehicle <NUM> during normal CC operation. In some examples, the CC torque controller <NUM> may be configured to receive ACC torque limit signals. For example, various sensors <NUM> that the ACC system <NUM> may utilize may sense a preceding vehicle <NUM>, and an ACC torque limiter <NUM> included in the ACC system <NUM> may provide a signal to the CC torque controller <NUM> associated with a torque limit to prevent the vehicle <NUM> from encroaching a predetermined safe following distance from the preceding vehicle <NUM>. In some examples, the torque limit signal may be used by the CC torque controller <NUM> to limit a CC driving torque demand and/or a launch torque demand determined by the VTI <NUM>.

In some examples, various conditions may be checked by the VTI <NUM>, and when satisfied, may trigger the VTI <NUM> to transition into a launch-on or launch-active state, where the VTI <NUM> may determine a launch torque demand and generate a launch torque request that may be sent to the CC torque controller <NUM>. As will be described in further detail below, the launch torque demand may be based on a tip-in torque curve with a dynamic pedal saturation level and dynamic pedal ramp rate. The CC torque controller <NUM> may be configured to receive the launch torque request from the VTI <NUM>. In some implementations, the CC torque controller <NUM> may be configured to bypass determining CC torque demand when the VTI <NUM> is in a launch-on/active state and to include the received launch torque request in a CC driving torque demand request that may be communicated to the EDTA <NUM>.

In some examples, the EDTA <NUM> may be operative or configured to receive driving torque demand requests from the CC torque controller <NUM> and arbitrate the received requests for generating a final CC driving torque control request that may be communicated to the PCI <NUM> for performing an associated powertrain action. In some examples, the final CC driving torque control request may include a dynamic launch torque demand generated by the VTI <NUM>.

In some examples, the transmission included in the powertrain <NUM> may be configured to receive a vehicle operator's torque demand to initiate a clutch closure for a launch. Accordingly, the AVL-TG system <NUM> may operate to generate and output a virtual vehicle operator launch torque demand that may mimic an actual vehicle operator torque demand. Accordingly, the transmission may receive a torque control request that includes the virtual vehicle operator launch torque demand generated by the AVL-TG system <NUM>, and may respond to the request, and properly close the clutch, as if the request were being generated by an actual vehicle operator.

With reference still to <FIG> , in some examples, the VTI <NUM> may be in communication with the retarder control arbitrator <NUM>. For example, the VTI <NUM> may be configured to communicate a signal to the retarder control arbitrator <NUM> when the VTI <NUM> is in a launch-on or launch-active state. This signal may be referred to herein as a launch-active state signal. The launch-active state signal may operate to prevent the powertrain <NUM> from performing engine retarding functions during the launch-active state. For example, when in the launch-active state, the VTI <NUM> may communicate a launch torque request to the CC torque controller <NUM> to move the vehicle <NUM> from a standstill or low speed, and may further communicate a launch-active state signal to the retarder control arbitrator <NUM>.

In some examples, the retarder control arbitrator <NUM> may be communicatively connected to the RCTA <NUM>. For example, the retarder control arbitrator <NUM> may operate as an engine retarder controller configured to determine CC retarding torque demand. In some examples, the RCTA <NUM> may be configured to arbitrate received CC retarding torque demand requests and signals (e.g., ACC torque control signals) for generating a final CC retarding torque control request that may be communicated to the PCI <NUM> for performing an associated engine braking-related powertrain action. For example, the RCTA <NUM> may receive an ACC torque control signal from an ACC torque controller <NUM>. According to one example, the ACC torque control signal be a signal to turn the engine retarder on or a signal to turn the engine retarder off, which may be arbitrated with other ACC retarding torque requests and signals received by the RCTA <NUM> for generating final CC retarding torque control requests that are sent to the PCI <NUM><NUM>.

With reference now to <FIG> , an illustration of an example state machine diagram <NUM> is provided showing an example general logic flow that may be implemented by the VTI <NUM> according to an embodiment. For example, the VTI <NUM> may include a state machine for determining when to transition into various states, including a launch-active state where virtual operator launch torque demand may be determined and a launch torque request may be generated for generating launch torque to move the vehicle <NUM> from a standstill or low speed. In each state <NUM>, <NUM>, <NUM>, <NUM>, <NUM> of the state machine, the VTI <NUM> may be configured to evaluate certain inputs, wherein when those inputs satisfy certain conditions, the VTI <NUM> may operate to transition into the associated state. Example inputs that may be evaluated by the VTI <NUM> include, but are not limited to: a calibration to determine whether the VTI <NUM> exists on the vehicle <NUM> and/or whether the VTI switch is enabled, engine speed, vehicle weight, engine reference torque, CC state, driver's pedal position, vehicle speed, nominal friction and estimated parasitic torque losses, ACC resume command, ACC pause command, ACC disable command, ACC control mode, transmission current gear, transmission requested gear, brake pedal switch status, and vehicle current grade value. For example, the various inputs may be received from various sensors <NUM> included in the vehicle <NUM>.

As shown, in some examples, the VTI <NUM> may initially operate in an inactive/standby state <NUM>, where the CC function may not be enabled or engaged.

In another example and as indicated by circled numeral <NUM>, a fourth set of conditions may be satisfied that may cause the VTI <NUM> to transition from the standstill/ready-to-launch state <NUM> to the launch-on/active state <NUM>. As described above, in the launch-on/active state <NUM>, the VTI <NUM> may generate a launch torque request to move the vehicle <NUM> from a standstill or low speed. In one example, the low speed includes any speed below one of ten miles per hour, below five miles per hour, below two miles per hour, or below one mile per hour. In one example implementation, the VTI <NUM> may be configured to determine to transition from the standstill/ready-to-launch state <NUM> to the launch-on/active state <NUM> based on signals indicating: the forward drive gear is active and a cruise resume command is received. For example, when traffic conditions allow, the vehicle <NUM> may automatically resume acceleration up to the target cruise speed from a standstill.

In some examples, when the VTI <NUM> is in the launch-on/active state <NUM>, various sets of inputs may be evaluated for determining whether to transition to another state. For example, and as indicated by circled numeral <NUM>, a fifth set of conditions may be satisfied that may cause the VTI <NUM> to transition from the launch-on/active state <NUM> back to the regular CC state <NUM>. In one example implementation, the VTI <NUM> may be configured to determine to transition from the launch-on/active state <NUM> back to the regular CC state <NUM> based on signals indicating: the vehicle speed is at or above the CC handover speed (i.e., the minimum threshold value) and no cruise control related errors are detected. For example, an indication that the vehicle <NUM> has reached the CC handover speed may operate at least in part to signal to the VTI <NUM> to hand control back over to the CC torque controller <NUM> for CC torque demand. In some examples, the VTI <NUM> may be configured to provide a seamless handover to the CC torque controller <NUM>. For example, the VTI <NUM> may operate to provide a signal to the CC speed controller <NUM>, which may operate as a virtual CC resume signal. Further the VTI <NUM> may continue to generate launch torque requests for a predetermined number of cycles (e.g., n cycles) beyond when VTI launch-on state is active to reduce or eliminate a gap in the CC torque demand being requested by the AVL-TG system <NUM> (e.g., between the VTI <NUM> stopping and the CC torque controller <NUM> starting back up for normal CC operation).

In some examples, and as indicated by circled numeral <NUM>, a sixth set of conditions may cause the VTI <NUM> to transition from the regular CC state <NUM> to the launch-on/active state <NUM>, where launch torque demand may be generated by the VTI <NUM>. According to one example, the sixth set of conditions may include a signal indicating the vehicle speed is less than the CC handover speed. For example, the ACC system <NUM> may be operating to slow the vehicle <NUM> to a low speed without the engine retarder, and when the vehicle speed falls below the CC handover speed, the VTI <NUM> may transition to the launch-on/active state <NUM>.

In some examples, the vehicle operator may activate the brakes (e.g., depress a brake pedal), which may cause the ACC system <NUM> to be disabled. Accordingly, as indicated by circled numerals <NUM>, <NUM>, <NUM>, and <NUM> a signal indicating an application of vehicle operator brakes may cause the VTI <NUM> to exit out of the regular CC state <NUM>, standstill/ready-to-launch state <NUM>, launch-on/active state <NUM>, or ACC braking state <NUM> to the inactive/standby state <NUM>.

In some examples, the VTI <NUM> may transition to the ACC braking state <NUM> when the engine braking system (also referred to herein as an engine retarder) is activated by the ACC system <NUM>. As indicated by circled numerals <NUM> and <NUM>, a signal indicating the ACC-initiated engine brake request may cause the VTI <NUM> to transition from the regular CC state <NUM> or the launch-on/active state <NUM> to the ACC braking state <NUM>. For example, in the ACC braking state <NUM>, a CC retarding torque control request may be generated and communicated to the PCI <NUM>.

In some examples, the VTI <NUM> may operate to evaluate various sets of inputs for determining whether to transition from the ACC braking state <NUM> to another state. In one example and as indicated by circled numeral <NUM>, the VTI <NUM> may transition from the ACC braking state <NUM> to the regular CC state <NUM> if, at the end of braking, the vehicle speed is at or above the CC handover speed. In another example and as indicated by circled numeral <NUM>, the VTI <NUM> may transition from the ACC braking state <NUM> to the launch-on/active state <NUM> if, at the end of braking, the vehicle speed is below the CC handover speed. In another example and as indicated by circled numeral <NUM>, the VTI <NUM> may transition from the ACC braking state <NUM> to the standstill/ready-to-launch state <NUM> if, at the end of braking, the vehicle is at a standstill. As can be appreciated, in other example implementations, the VTI <NUM> may operate to evaluate additional or alternative inputs. Further, additional or alternative conditions may be satisfied to cause the VTI <NUM> to transition from one state to another state. Moreover, in some examples, the conditions and values associated with the conditions may be configurable.

With reference now to <FIG> , the VTI <NUM> is described in further detail. According to an aspect, various inputs may be received by the VTI <NUM>, which may be used to determine the launch torque demand. For example and as shown, a signal indicating the weight of the vehicle <NUM> (i.e., vehicle weight <NUM> ) and a signal indicating the pitch angle or grade of the vehicle <NUM> (i.e., vehicle grade <NUM> may be received as inputs by the VTI <NUM>. According to one example, the vehicle weight <NUM> signal may be received from a sensor <NUM> included in the vehicle <NUM>, such as a weight sensor that may operate to transmit vehicle load information from, for example, a load bearing axle, to the VECU <NUM>. According to another example, the vehicle grade <NUM> signal may be received from another sensor <NUM> included in the vehicle <NUM>, such as an incline sensor or accelerometer that may operate to transmit vehicle grade information to the VECU <NUM>. The vehicle weight <NUM> and the vehicle grade <NUM> may be input into a first table, referred to herein as a pedal saturation table <NUM> , to generate a pedal saturation value <NUM> (e.g., a pedal position percentage) based on the inputs. For example, the pedal saturation value <NUM> may correspond with a percentage of saturation of the vehicle operator's accelerator pedal to move the vehicle <NUM> from its current speed and position up to the CC handover speed.

The pedal saturation value <NUM> may be input into a second table, referred to herein as a pedal ramp rate table <NUM>, to determine a pedal ramp rate <NUM> to reach the pedal saturation value <NUM> based on the vehicle weight <NUM>, the vehicle grade <NUM>, and engine speed <NUM>. For example, the engine speed <NUM> signal may be received from a sensor <NUM> included in the vehicle <NUM>, such as an engine speed sensor that may operate to transmit engine rotational speed information to the VECU <NUM>. In some examples, the pedal saturation may be dynamically applied up to a determined maximum pedal saturation value based on the pedal ramp rate <NUM>, representing a tip-in torque curve configured to mimic a torque curve generated by a vehicle operator's acceleration pedal tip-in.

The tables (e.g., the saturation table <NUM> and the ramp rate table <NUM> ) may represent the pedal saturation values and ramp rates corresponding to launching the vehicle <NUM> at various vehicle weight <NUM> and vehicle grade <NUM> combinations. For example, the vehicle <NUM> launching on a steep hill may accelerate differently than it would on a flatter grade. Further, when the vehicle <NUM> has a heavier load, it may accelerate differently than it would with a lighter load. Further still, various combinations thereof may cause the vehicle <NUM> to accelerate differently. In some examples, the values included in the saturation table <NUM> and the ramp rate table <NUM> may be determined based on a mathematical model. In other examples, the values included in the saturation table <NUM> and the ramp rate table <NUM> may be determined based on a machine learning algorithm that may be trained to learn the various pedal saturation values and ramp rates corresponding to launching the vehicle <NUM> at various vehicle weight <NUM> and vehicle grade <NUM> combinations. For example, the machine learning algorithm may be trained to learn a vehicle operator's pedal tip-in behaviors associated with launching the vehicle <NUM> from a standstill or from a low speed.

In some examples, the launch torque can be adjusted to allow for vehicle operator selection of an aggressiveness of the launch. For example, a selector (e.g., user interface control, user interface display menu option, switch) may be included in the vehicle <NUM> that the vehicle operator may be enabled to use to select a desired level of launch aggressiveness (referred to in <FIG> as a launch aggression setting <NUM> ), wherein a less-aggressive launch may describe a smoother launch with a lower pedal ramp rate, and a more-aggressive launch may describe a faster launch with a higher pedal ramp rate. In some examples, different levels of launch aggressiveness may correspond with different multipliers that may be applied to the values included in the ramp rate table <NUM> to correspondingly adjust the pedal ramp rate and, thus, the tip-in torque curve. As should be appreciated, in a situation where a preceding vehicle <NUM> is sensed within a predetermined distance in front of the vehicle <NUM>, an ACC torque limit signal may be communicated to the CC torque controller <NUM>, which may limit the requested torque demand to prevent the vehicle <NUM> from launching into the preceding vehicle <NUM>.

In some examples, the determined pedal saturation value <NUM> and pedal ramp rate <NUM> may be input into a pedal map <NUM>. For example, the pedal saturation value <NUM> may be provided as a pedal position associated with a percentage of saturation of the vehicle operator accelerator pedal. The pedal map <NUM> may include a dynamic lookup table that, based on the received inputs, may be used to translate the pedal position (i.e., pedal saturation value <NUM> ) and pedal ramp rate <NUM> to a torque demand percent <NUM>. For example, the pedal map may include pedal position translation information comprising relationships between pedal positions and torque demand associated with the vehicle's particular powertrain <NUM>. For example, various types of powertrains <NUM> may have different pedal map information. Accordingly, the pedal map <NUM> may have calibratable values that can be adjusted depending on the powertrain <NUM> operating to create the torque.

In some examples, the launch torque demand may further be translated from a percent into a value (i.e., a launch torque value <NUM> ). For example, various systems included in the vehicle <NUM> may understand torque as an actual value. Accordingly, a torque translation table <NUM> may be used to translate the torque demand percent <NUM> into a launch torque value <NUM> that may be communicated to the CC torque controller <NUM> in one or more launch torque requests <NUM> at a rate that the transmission may be configured to expect from being received from the vehicle operator accelerator pedal. According to an aspect, the dynamically saturated and dynamic pedal ramp rate launch torque request(s) <NUM> may mimic the vehicle operator's throttle application at a standstill or low speed.

With reference now to <FIG> , an example virtual operator launch torque demand <NUM> (illustrated as a dotted line) generated by the VTI <NUM> is shown graphed in comparison with an example regular torque demand <NUM> that may be generated without utilizing aspects of the present invention (illustrated as a solid line). In the illustrated example, the VTI launch torque demand <NUM> may be determined based on the pedal saturation table <NUM> and the pedal map <NUM>, wherein the launch torque may be dynamically applied and distributed over time <NUM> based on the pedal ramp rate table <NUM> and, if present, a vehicle operator-selected launch aggression setting <NUM>. For example, the illustrated virtual operator launch torque demand <NUM> is shown in percent format <NUM> (e.g., rather than in a value format that may be transmitted to the CC torque controller <NUM> ). As shown, the virtual operator launch torque demand <NUM> may change dynamically throughout the launch based on the translation values included in the pedal map <NUM> and the engine speed <NUM>.

Further as shown, the virtual operator launch torque demand <NUM> generated by the VTI <NUM> may be configured to mimic a human vehicle operator's pedal tip-in. For example, the transmission may be configured to close the clutch based on vehicle operator demand torque values received at an appropriate rate, and may successfully operate to close the clutch when the received launch torque demand <NUM> mimics an expected or human vehicle operator generated torque request. As shown, the regular torque demand <NUM> may include a square wave action <NUM> that may represent a large amount of torque that may be applied abruptly, which may create an uncomfortable vehicle response and harsh feeling driver-off performance. In comparison, the virtual operator launch torque demand <NUM> generated by the VTI <NUM> may include a dynamic pedal ramp rate <NUM>, which may successfully close the clutch and allow the vehicle <NUM> to launch smoothly. Accordingly, implementation of the VTI <NUM> may help satisfy customer expectations of a quality vehicle <NUM>.

With reference now to <FIG> , a flow diagram is shown depicting general stages of an example method <NUM> for providing automated launch torque generation. For example, the operations included in <FIG> may include example operations that may be performed by the VTI <NUM> when the VTI <NUM> receives signals that cause the VTI <NUM> to transition into the launch-on/active state <NUM> and further into the regular CC state <NUM>. At OPERATION <NUM>, an indication to generate a launch torque request may be received. For example, with reference back to the example state machine diagram <NUM> illustrated in <FIG> , and as indicated by circled numerals <NUM>, <NUM>, and <NUM>, various input signals may be evaluated for determining whether a set of conditions are satisfied to transition from a current state to the launch-on/active state <NUM>.

In one example scenario, the ACC system <NUM> may initially be operating in regular CC mode, wherein sensed traffic conditions may cause the ACC system <NUM> to slow the vehicle <NUM> to a standstill or to a low speed to maintain a safe following distance from a preceding vehicle <NUM>. When the ACC system <NUM> is operating in the regular CC mode, the VTI <NUM> may be configured to correspondingly operate in the regular CC state <NUM>. In some examples, depending on various vehicle conditions, such as the vehicle speed and whether the engine retarder system is requested to slow down the vehicle <NUM>, the VTI <NUM> may operate to remain in the regular CC state <NUM> or to transition from the regular CC state <NUM> to the standstill/ready-to-launch state <NUM> or to the ACC braking state <NUM>. When traffic conditions allow, as determined by various sensors <NUM>, a determination may be made that a set of conditions may be satisfied that may cause the VTI <NUM> to transition from the regular CC state <NUM>, the standstill/ready-to-launch state <NUM>, or the ACC braking state <NUM> to the launch-on/active state <NUM>, where launch torque may be generated to move the vehicle <NUM> from a standstill or low speed to the preset CC handover speed.

At OPERATION <NUM>, a pedal saturation value <NUM> (e.g., pedal position percentage) may be determined. For example, the vehicle weight <NUM> and the vehicle grade <NUM> may be used as inputs in the pedal saturation table <NUM> for determining the pedal saturation value <NUM>. Further, the pedal ramp rate <NUM> may be determined. For example, the pedal saturation value <NUM> and engine speed <NUM> may be input into the pedal ramp rate table <NUM> for determining the pedal ramp rate <NUM>. In some examples, the pedal ramp rate <NUM> may be adjusted based on a vehicle operator-selected launch aggression setting <NUM>.

At OPERATION <NUM>, the determined pedal saturation value <NUM> and pedal ramp rate <NUM> may be input into the pedal map <NUM> associated with the vehicle powertrain <NUM> for determining the launch torque demand. For example, the output of the pedal map <NUM> may include a torque demand percent <NUM>. The torque demand percent <NUM> may be input into a torque translation table <NUM> that may be used to translate the torque demand percent <NUM> into a launch torque value <NUM> that may be understood by other vehicle system components, such as by the PCI <NUM> for controlling the powertrain <NUM>.

At OPERATION <NUM>, one or more launch torque requests <NUM> may be communicated to the CC torque controller <NUM> based on the determined launch torque value <NUM> and pedal ramp rate <NUM>. For example, the one or more launch torque requests <NUM> may include dynamic launch torque demand values <NUM> that may be distributed over time based on the pedal ramp rate <NUM> such that the launch torque request mimics a human vehicle operator's pedal tip-in and may successfully allow the clutch to close. Example operations that may be performed by the CC torque controller <NUM> in an example method <NUM> of providing automated launch torque generation is described below with reference to <FIG>.

At OPERATION <NUM>, a notification of the launch-on/active state <NUM> of the VTI <NUM> may be communicated to the retarder control arbitrator <NUM> to prevent the powertrain <NUM> from performing engine braking functions during the launch.

At OPERATION <NUM>, an indication to transition from the launch-on/active state <NUM> to the regular CC state <NUM> may be received. For example, when a set of conditions may be determined to be satisfied, the VTI <NUM> may transition from the launch-on/active state <NUM> to the regular CC state <NUM>. In one example, the set of conditions may include an indication that the vehicle speed has reached the CC handover speed.

At OPERATION <NUM>, a signal that the VTI <NUM> is transitioning to the regular CC state <NUM> may be sent to the CC speed controller <NUM>. For example, the signal may be received as a virtual CC resume signal that may indicate that the VTI <NUM> is discontinuing generating CC launch torque demand requests and that the CC torque controller <NUM> will be handling the CC torque demand requests.

At OPERATION <NUM>, launch torque requests <NUM> may continue to be generated by the VTI <NUM> for n cycles. For example, the VTI <NUM> may be configured to provide a seamless handover to the CC torque controller <NUM>, and may operate to generate launch torque requests for n cycles beyond when VTI launch-on state is active to reduce or eliminate a gap in the CC torque demand being requested by the AVL-TG system <NUM>.

At OPERATION <NUM>, CC torque demand control may be handed over to the CC torque controller <NUM>. For example, the VTI <NUM> may discontinue generating launch torque requests to mimic the vehicle driver's pedal tip-in, and CC torque demand output by the CC torque controller <NUM> may be determined by the CC torque controller <NUM>.

With reference now to <FIG> , a flow diagram is shown depicting general stages of an example method <NUM> for providing automated launch torque generation. For example, the operations included in <FIG> may include example operations that may be performed by the CC torque controller <NUM> as part of generating torque demand requests for CC operation. At DECISION OPERATION <NUM>, a determination may be made as to whether a launch torque request <NUM> has been received from the VTI <NUM>. For example, the VTI <NUM> may generate launch torque requests <NUM> when the vehicle speed is below the CC handover speed. According to one example, the one or more launch torque requests <NUM> generated at OPERATION <NUM> in <FIG> may be received by the CC torque controller <NUM>. When a VTI launch torque request <NUM> is received, it may be included (OPERATION <NUM> ) in a torque demand request that may be communicated to the EDTA <NUM>.

At OPERATION <NUM>, a CC torque demand value may be determined by the CC torque controller <NUM> to maintain a target cruise speed. For example, a target cruise speed may be set, which may be communicated to the CC torque controller <NUM> by the CC speed controller <NUM> and used to determine the CC torque demand.

At DECISION OPERATION <NUM>, a determination may be made as to whether an ACC torque limit signal may be received from the ACC torque limiter <NUM>. For example, the ACC torque limit signal may be based on the ACC system <NUM> receiving a signal associated with a distance from a preceding vehicle <NUM>. For example, the ACC torque limit may be used to limit torque demand to prevent the vehicle <NUM> from encroaching a predetermined safe following distance from the preceding vehicle <NUM> and possibly colliding into the preceding vehicle <NUM>. When an ACC torque limit signal is received, at OPERATION <NUM>, the ACC torque limit may be applied as a limit to the CC torque demand determined by the CC torque controller <NUM> or, if received, the launch torque demand request received from the VTI <NUM>.

At OPERATION <NUM>, a CC driving torque demand request may be sent to the EDTA <NUM>. For example, the CC driving torque demand request may include the CC torque demand determined by the CC torque controller <NUM> or, if received, the launch torque demand determined by the VTI <NUM>. In some examples, received torque demand requests may be arbitrated by the EDTA <NUM>. A final CC driving torque demand request may be generated by the EDTA <NUM> and communicated to the PCI <NUM> for performing an associated powertrain action. In some examples, such as when launch torque demand is generated by the VTI <NUM>, the associated powertrain action is a smooth launch from a standstill or a low speed.

<FIG> is a block diagram of an illustrative computing device <NUM> appropriate for use in accordance with embodiments of the present invention. The description below is applicable to the VECU <NUM>, servers, personal computers, mobile phones, smart phones, tablet computers, embedded computing devices, and other currently available or yet-to-be-developed devices that may be used in accordance with embodiments of the present invention.

In its most basic configuration, the computing device <NUM> includes at least one processor <NUM> and a system memory <NUM> connected by a communication bus <NUM>. Depending on the exact configuration and type of device, the system memory <NUM> may be volatile or nonvolatile memory, such as read-only memory ("ROM"), random access memory ("RAM"), EEPROM, flash memory, or other memory technology. Those of ordinary skill in the art and others will recognize that system memory <NUM> typically stores data or program modules that are immediately accessible to or currently being operated on by the processor <NUM>. In this regard, the processor <NUM> may serve as a computational center of the computing device <NUM> by supporting the execution of instructions. According to one example, the system memory <NUM> may store one or more components of the AVL-TG system <NUM>.

As further illustrated in <FIG> , the computing device <NUM> may include a network interface <NUM> comprising one or more components for communicating with other devices over a network. Embodiments of the present invention may access basic services that utilize the network interface <NUM> to perform communications using common network protocols. The network interface <NUM> may also include a wireless network interface configured to communicate via one or more wireless communication protocols, such as WiFi, <NUM>, <NUM>, <NUM>, LTE, WiMAX, Bluetooth, or the like.

In the illustrative embodiment depicted in <FIG> , the computing device <NUM> also includes a storage medium <NUM>. However, services may be accessed using a computing device that does not include means for persisting data to a local storage medium. Therefore, the storage medium <NUM> depicted in <FIG> is optional. In any event, the storage medium <NUM> may be volatile or nonvolatile, removable or non-removable, implemented using any technology capable of storing information such as, but not limited to, a hard drive, solid state drive, CD-ROM, DVD, or other disk storage, magnetic tape, magnetic disk storage, or the like.

As used herein, the term "computer-readable medium" includes volatile and nonvolatile and removable and non-removable media implemented in any method or technology capable of storing information, such as computer-readable instructions, data structures, program modules, or other data. In this regard, the system memory <NUM> and storage medium <NUM> depicted in <FIG> are examples of computer-readable media.

For ease of illustration and because it is not important for an understanding of the claimed subject matter, <FIG> does not show some of the typical components of many computing devices. In this regard, the computing device <NUM> may include input devices, such as a keyboard, keypad, mouse, trackball, microphone, video camera, touchpad, touchscreen, electronic pen, stylus, or the like. Such input devices may be coupled to the computing device <NUM> by wired or wireless connections including RF, infrared, serial, parallel, Bluetooth, USB, or other suitable connection protocols using wireless or physical connections.

In any of the described examples, data can be captured by input devices and transmitted or stored for future processing. The processing may include encoding data streams, which can be subsequently decoded for presentation by output devices. Media data can be captured by multimedia input devices and stored by saving media data streams as files on a computer-readable storage medium (e.g., in memory or persistent storage on a client device, server, administrator device, or some other device). Input devices can be separate from and communicatively coupled to computing device <NUM> (e.g., a client device), or can be integral components of the computing device <NUM>. In some embodiments, multiple input devices may be combined into a single, multifunction input device (e.g., a video camera with an integrated microphone). The computing device <NUM> may also include output devices such as a display, speakers, printer, etc. The output devices may include video output devices such as a display or touchscreen. The output devices also may include audio output devices such as external speakers or earphones. The output devices can be separate from and communicatively coupled to the computing device <NUM>, or can be integral components of the computing device <NUM>. Input functionality and output functionality may be integrated into the same input/output device (e.g., a touchscreen). Any suitable input device, output device, or combined input/output device either currently known or developed in the future may be used with described systems.

In general, functionality of computing devices described herein may be implemented in computing logic embodied in hardware or software instructions, which can be written in a programming language, such as C, C++, COBOL, JAVA™ , PHP, Perl, HTML, CSS, JavaScript, VBScript, ASPX, Microsoft. NET™ languages such as C#, or the like. Computing logic may be compiled into executable programs or written in interpreted programming languages. Generally, functionality described herein can be implemented as logic modules that can be duplicated to provide greater processing capability, merged with other modules, or divided into sub-modules. The computing logic can be stored in any type of computer-readable medium (e.g., a non-transitory medium such as a memory or storage medium) or computer storage device and be stored on and executed by one or more general-purpose or special-purpose processors, thus creating a special-purpose computing device configured to provide functionality described herein.

Many alternatives to the systems and devices described herein are possible. For example, individual modules or subsystems can be separated into additional modules or subsystems or combined into fewer modules or subsystems. As another example, modules or subsystems can be omitted or supplemented with other modules or subsystems. As another example, functions that are indicated as being performed by a particular device, module, or subsystem may instead be performed by one or more other devices, modules, or subsystems. Although some examples in the present invention include descriptions of devices comprising specific hardware components in specific arrangements, techniques and tools described herein can be modified to accommodate different hardware components, combinations, or arrangements. Further, although some examples in the present invention include descriptions of specific usage scenarios, techniques and tools described herein can be modified to accommodate different usage scenarios. Functionality that is described as being implemented in software can instead be implemented in hardware, or vice versa.

Claim 1:
A system (<NUM>) for providing automated launch torque, the system comprising:
at least one processor (<NUM>);
a memory storage device (<NUM>, <NUM>), operatively connected to the at least one processor and including instructions that, when executed by the at least one processor, are configured to cause the system to:
receive (<NUM>) an indication to generate a launch torque request (<NUM>) indicating a virtual operator launch torque demand to move a vehicle operating in adaptive cruise control mode to a minimum threshold speed;
receive (<NUM>) a first signal (<NUM>) indicating the vehicle's weight and a second signal (<NUM>) indicating the vehicle's grade;
determine (<NUM>) a pedal saturation value (<NUM>) based on the vehicle's weight and the vehicle's grade;
receive (<NUM>) a third signal (<NUM>) indicating an engine speed;
determine (<NUM>) a pedal ramp rate (<NUM>) for a dynamic application of the pedal saturation value based at least in part on the engine speed;
determine (<NUM>) launch torque demand (<NUM>) based on the pedal saturation value and the pedal ramp rate; and
transmit (<NUM>) to one or more powertrain components one or more communications regarding the launch torque demand according to the pedal ramp rate to cause the vehicle to be launched to the minimum threshold speed.