Method and system for controlling engine starting

Abstract

Systems and methods for operating a hybrid powertrain of a vehicle including an engine and a motor / generator are described. The systems and methods can determine whether to generate an engine start request when the engine is stopped in response to current vehicle operating conditions and predicted vehicle operating conditions.

Description

TECHNICAL FIELD

[0001] This specification relates to methods and systems for operating a powertrain of a hybrid vehicle. The methods and systems may be particularly useful for hybrid vehicles that temporarily stop an engine of the powertrain to save fuel.

[0002] BACKGROUND AND SUMMARY

[0003] Hybrid vehicles may include an engine and an electric motor as propulsion sources. The engine may be stopped from time to time to save fuel. For example, if the vehicle is traveling downhill or if the driver demand torque is less than a threshold torque, the engine may be stopped to save fuel. If the driver demand increases or if the state of charge of the battery decreases to less than a threshold charge, the engine may be restarted to provide torque. However, since the driving state may change, the engine may be restarted and then stopped again after a few seconds due to a change in the driving state. Starting the engine for only a few seconds and then stopping the engine may reduce fuel economy, increase starter component degradation, and irritate vehicle occupants. Additionally, the benefits obtained by starting the engine, if any, may be very small. Therefore, it may be desirable to provide a method for improving the engine start decision-making process such that if starting the engine will provide little benefit, engine starting can be avoided, and at the same time, if starting the engine is expected to provide useful benefits, engine starting is allowed.

[0004] Herein, the inventors have recognized the above problems and have developed a method for operating a powertrain that includes: receiving data at a controller; adjusting a status of a first engine start request generated via a first control agent in response to the data; adjusting a status of a second engine start request generated via a second control agent in response to predicted vehicle conditions; and starting or not starting the engine in response to arbitration of the first engine start request and the second engine start request.

[0005] By providing two control agents that generate different engine start requests in response to current vehicle operating conditions and predicted vehicle conditions, a technical result of improved engine start decision-making can be provided. Via the improved decision-making process, the engine may not be started, or the engine may be started. The engine start decision may be made in response to the state of charge of the battery, propulsion motor torque, driver demand torque, and other conditions. The conditions may be evaluated by the first control agent and the second control agent, and then the control agents may request engine starting. An arbitration logic section ultimately determines whether to issue an engine start request and start the engine.

[0006] This specification can provide several advantages. For example, the method can reduce the number of engine starts and short operating periods. Additionally, the method can reduce the degradation of engine starting components. Furthermore, the method can be applied to different conditions that may be the basis for engine starting.

[0007] The above and other advantages and features of this specification will become apparent from the following detailed description, taken alone or in conjunction with the accompanying drawings.

[0008] It should be understood that the above Summary is provided to introduce in a simplified form some concepts that will be further described in the Detailed Description. This is not intended to identify key or essential features of the claimed subject matter, the scope of which is uniquely defined by the appended claims. Moreover, the claimed subject matter is not limited to embodiments that solve any disadvantages set forth above or in any part of this disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] The advantages described herein will be more fully understood by reading examples of embodiments herein referred to as the Detailed Description, taken alone or in reference to the accompanying drawings, in which:

[0010] Figure 1 is a schematic diagram of an engine;

[0011] Figure 2 is a schematic diagram of a hybrid vehicle powertrain;

[0012] Figure 3 shows an example powertrain operation sequence according to Figure 5 the method; and

[0013] Figures 4 to 8 shows a method applicable to different decision agents for determining whether to start the engine of a hybrid vehicle. DETAILED DESCRIPTION

[0014] This specification relates to operating the powertrain of a hybrid vehicle. The powertrain can include an engine and a motor. The engine and the motor can be selectively coupled or continuously coupled. Figure 1 An example engine for a hybrid vehicle is shown. The engine is shown as having a motor as part of the Figure 2 hybrid powertrain or power transmission system in Figure 3 . The hybrid powertrain can operate as shown in

[0015] Reference Figure 1 is made to, an internal combustion engine 10 (which includes a plurality of cylinders, one of which is shown in Figure 1is controlled by an electronic engine controller 12 as shown. Engine 10 consists of a cylinder head 35 and a cylinder block 33, which includes combustion chambers 30 and cylinder walls 32. A piston 36 is located within the cylinder and reciprocates by being connected to a crankshaft 40. A flywheel 97 and a ring gear 99 are coupled to the crankshaft 40. A starter 96 (e.g., a low voltage (operating at a voltage less than 30 volts) motor) includes a pinion shaft 98 and a pinion 95. The pinion shaft 98 can selectively advance the pinion 95 to engage the ring gear 99. The starter 96 can be directly mounted to the front or the rear of the engine. In some examples, the starter 96 can selectively supply torque to the crankshaft 40 via a belt or a chain. In one example, the starter 96 is in a basic state when not engaged to the engine crankshaft. The combustion chambers 30 are shown to be in communication with an intake manifold 44 and an exhaust manifold 48 via respective intake valves 52 and exhaust valves 54. Each intake and exhaust valve can be operated by an intake cam 51 and an exhaust cam 53. The position of the intake cam 51 can be determined by an intake cam sensor 55. The position of the exhaust cam 53 can be determined by an exhaust cam sensor 57. The intake valve 52 can be selectively enabled and disabled by a valve actuation device 59. The exhaust valve 54 can be selectively enabled and disabled by a valve actuation device 58. The valve actuation devices 58 and 59 can be electromechanical devices.

[0016] A fuel injector 66 is shown to be arranged to inject fuel directly into the cylinder 30, which is known to those skilled in the art as direct injection. The fuel injector 66 delivers liquid fuel in proportion to the pulse width from the controller 12. The fuel is delivered to the fuel injector 66 by a fuel system (not shown) including a fuel tank, a fuel pump, and a fuel rail (not shown). In one example, a high-pressure dual-stage fuel system can be used to generate a higher fuel pressure.

[0017] In addition, the intake manifold 44 is shown to be in communication with a turbocharger compressor 162 and an engine air intake 42. In other examples, the compressor 162 can be a supercharger compressor. A shaft 161 mechanically couples a turbocharger turbine 164 to the turbocharger compressor 162. An optional electronic throttle 62 adjusts the position of a throttle plate 64 to control the airflow from the compressor 162 to the intake manifold 44. The pressure in the plenum chamber 45 can be referred to as the throttle inlet pressure because the inlet of the throttle 62 is within the plenum chamber 45. The throttle outlet is in the intake manifold 44. In some examples, the throttle 62 and the throttle plate 64 can be disposed between the intake valve 52 and the intake manifold 44 such that the throttle 62 is an intake port throttle. A compressor recirculation valve 47 can be selectively adjusted to multiple positions between fully open and fully closed. A wastegate 163 can be adjusted via the controller 12 to allow the exhaust to selectively bypass the turbine 164, thereby controlling the speed of the compressor 162. An air cleaner 43 cleans the air entering the engine air intake 42.

[0018] The distributorless ignition system 88 provides an ignition spark to the combustion chamber 30 via the spark plugs 92 in response to the controller 12. A universal exhaust gas oxygen (UEGO) sensor 126 is shown coupled to the exhaust manifold 48 upstream of the catalytic converter 70. Alternatively, a two-state exhaust gas oxygen sensor may replace the UEGO sensor 126.

[0019] In one example, the converter 70 may include multiple catalyst bricks. In another example, multiple emission control devices (each with multiple bricks) may be used. In one example, the converter 70 may be a three-way type catalyst.

[0020] The controller 12 is shown in Figure 1 as a conventional microcomputer that includes: a microprocessor unit 102, an input / output port 104, a read-only memory 106 (e.g., non-transitory memory), a random access memory 108, a keep-alive memory 110, and a conventional data bus. The controller 12 is shown as receiving various signals from sensors coupled to the engine 10 in addition to those previously discussed, including: engine coolant temperature (ECT) from a temperature sensor 112 coupled to the coolant jacket 114; a position sensor 134 coupled to the accelerator pedal 130 for sensing the force applied by a human foot 132; a position sensor 154 coupled to the brake pedal 150 for sensing the force applied by a human foot 152; a measurement of the engine manifold pressure (MAP) from a pressure sensor 122 coupled to the intake manifold 44; the engine position from a Hall effect sensor 118 sensing the position of the crankshaft 40; a measurement of the air mass entering the engine from a sensor 120; and a measurement of the throttle position from a sensor 68. Atmospheric pressure may also be sensed (by a sensor not shown) for processing by the controller 12. In a preferred aspect of the present specification, the engine position sensor 118 generates a predetermined number of equally spaced pulses each time the crankshaft rotates, from which the engine speed (RPM) can be determined.

[0021] During operation, each cylinder within the engine 10 typically undergoes a four-stroke cycle: the cycle includes an intake stroke, a compression stroke, an expansion stroke, and an exhaust stroke. During the intake stroke, generally speaking, the exhaust valve 54 is closed and the intake valve 52 is open. Air is introduced into the combustion chamber 30 via the intake manifold 44, and the piston 36 moves to the bottom of the cylinder to increase the volume within the combustion chamber 30. The position of the piston 36 near the bottom of the cylinder and at the end of its stroke (e.g., when the combustion chamber 30 is at its maximum volume) is typically referred to by those skilled in the art as bottom dead center (BDC).

[0022] During the compression stroke, the intake valve 52 and the exhaust valve 54 are closed. The piston 36 moves toward the cylinder head to compress the air within the combustion chamber 30. The point at which the piston 36 is at the end of its stroke and closest to the cylinder head (e.g., when the combustion chamber 30 is at its minimum volume) is commonly referred to by those skilled in the art as top dead center (TDC). During a process hereinafter referred to as injection, fuel is introduced into the combustion chamber. During a process hereinafter referred to as ignition, the injected fuel is ignited by a known ignition device such as a spark plug 92, resulting in combustion.

[0023] During the expansion stroke, the expanding gases push the piston 36 back to BDC. The crankshaft 40 converts the piston motion into rotational torque of the rotating shaft. Finally, during the exhaust stroke, the exhaust valve 54 opens to release the burned air-fuel mixture into the exhaust manifold 48, and the piston returns to TDC. It should be noted that the above is shown only as an example, and the intake and exhaust valve opening and / or closing timings can vary, such as to provide positive or negative valve overlap, late intake valve closing, or various other examples.

[0024] Figure 2 is a block diagram of a vehicle 225 including a powertrain or driveline 200. Figure 2 The powertrain of Figure 1 includes the engine 10 shown in. The powertrain 200 is shown as including a vehicle system controller 255, an engine controller 12, a motor controller 252, a transmission controller 254, an energy storage device controller 253, and a brake controller 250. The controllers can communicate via a controller area network (CAN) 299. Each of the controllers can provide information to the other controllers, such as torque output limits (e.g., the torque output of a control device or component is not exceeded), torque input limits (e.g., the torque input to a control device or component is not exceeded), the torque output of a control device, sensor and actuator data, diagnostic information (e.g., information about a degraded transmission, information about a degraded engine, information about a degraded motor, information about a degraded brake). Additionally, the vehicle system controller 255 can provide commands to the engine controller 12, the motor controller 252, the transmission controller 254, and the brake controller 250 to achieve driver input requests and other requests based on vehicle operating conditions.

[0025] For example, in response to the driver releasing the accelerator pedal and the vehicle speed, the vehicle system controller 255 can request a desired wheel torque or wheel power level to provide a desired vehicle deceleration rate. The desired wheel torque can be provided by the vehicle system controller 255, which requests a first braking torque from the motor controller 252 and a second braking torque from the brake controller 250, the first torque and the second torque providing the desired braking torque at the wheel 216.

[0026] In other examples, the partitioning of the control of the powertrain device can be partitioned in a Figure 2 different manner than that shown. For example, a single controller can replace the vehicle system controller 255, the engine controller 12, the motor controller 252, the transmission controller 254, and the brake controller 250. Alternatively, the vehicle system controller 255 and the engine controller 12 can be a single unit, while the motor controller 252, the transmission controller 254, and the brake controller 250 are separate controllers.

[0027] In this example, the powertrain 200 can be powered by the engine 10 and the motor 240. In other examples, the engine 10 can be omitted. The engine 10 can be started with the Figure 1 engine starting system shown or via an integrated starter / generator (ISG) 240 also known as a motor / generator. The ISG 240 (e.g., a high-voltage (operating at a voltage greater than 30 volts) motor) can also be referred to as a motor, a motor, and / or a generator. In addition, the torque of the engine 10 can be adjusted via torque actuators 204 such as fuel injectors, throttles, etc.

[0028] The engine output torque can be transmitted to the input or first side of the powertrain disconnect clutch 235 through the dual mass flywheel 215. The disconnect clutch 236 can be electrically actuated or hydraulically actuated. The downstream or second side 234 of the disconnect clutch 236 is shown to be mechanically coupled to the ISG input shaft 237.

[0029] The ISG 240 can be operated to provide torque to the powertrain 200 or convert powertrain torque into electrical energy for storage in the electrical energy storage device 275 in a regenerative mode. The ISG 240 is in electrical communication with the energy storage device 275. The ISG 240 has a higher output torque capacity than Figure 1 the starter 96 shown. In addition, the ISG 240 directly drives the powertrain 200 or is directly driven by the powertrain 200. There is no belt, gear, or chain connecting the ISG 240 to the powertrain 200. Instead, the ISG 240 rotates at the same rate as the powertrain 200. The electrical energy storage device 275 (e.g., a high-voltage battery or power source) can be a battery, a capacitor, or an inductor. The downstream side of the ISG 240 is mechanically coupled to the impeller 285 of the torque converter 206 via the shaft 241. The upstream side of the ISG 240 is mechanically coupled to the disconnect clutch 236. The ISG 240 can provide positive or negative torque to the powertrain 200 by operating as a motor or a generator as indicated by the motor controller 252.

[0030] The torque converter 206 includes a turbine 286 to output torque to the input shaft 270. The input shaft 270 mechanically couples the torque converter 206 to the automatic transmission 208. The torque converter 206 also includes a torque converter bypass lock-up clutch 212 (TCC). When the TCC is locked, torque is directly transmitted from the impeller 285 to the turbine 286. The TCC is electrically operated by the controller 12. Alternatively, the TCC can be hydraulically locked. In one example, the torque converter can be referred to as a component of the transmission.

[0031] When the torque converter lock-up clutch 212 is fully disengaged, the torque converter 206 transmits engine torque to the automatic transmission 208 through fluid transfer between the torque converter turbine 286 and the torque converter impeller 285, thereby achieving torque multiplication. In contrast, when the torque converter lock-up clutch 212 is fully engaged, the engine output torque is directly transmitted to the input shaft (not shown) of the transmission 208 via the torque converter clutch. Alternatively, the torque converter lock-up clutch 212 can be partially engaged, enabling adjustment of the amount of torque directly transmitted to the transmission. The transmission controller 254 can be configured to adjust the amount of torque transmitted by the torque converter 212 by responding to various engine operating conditions or adjusting the torque converter lock-up clutch according to a driver-based engine operation request.

[0032] The automatic transmission 208 includes gear clutches (e.g., gears 1 - 10) 211 and a forward clutch 210. The automatic transmission 208 is a stepped transmission. The gear clutches 211 and the forward clutch 210 can be selectively engaged to change the ratio of the actual total revolutions of the input shaft 270 to the actual total revolutions of the wheels 216. The gear clutches 211 can be engaged or disengaged by adjusting the fluid supplied to the clutches via the shift control solenoid valve 209. Torque output from the automatic transmission 208 can also be transmitted to the wheels 216 via the output shaft 260 to propel the vehicle. Specifically, the automatic transmission 208 can transmit input drive torque at the input shaft 270 in response to vehicle driving conditions before transmitting the output drive torque to the wheels 216. The transmission controller 254 selectively enables or engages the TCC 212, the gear clutches 211, and the forward clutch 210. The transmission controller also selectively deactivates or disengages the TCC 212, the gear clutches 211, and the forward clutch 210.

[0033] In addition, a frictional wheel brake 218 can be engaged to apply a frictional force to the wheel 216. In one example, the frictional wheel brake 218 can be engaged in response to the driver pressing his foot on a brake pedal (not shown) and / or in response to an instruction within the brake controller 250. Additionally, the brake controller 250 can apply the brake 218 in response to information and / or requests made by the vehicle system controller 255. Similarly, the frictional force to the wheel 216 can be reduced by disengaging the wheel brake 218 in response to the driver releasing his foot from the brake pedal, brake controller instructions, and / or vehicle system controller instructions and / or information. For example, the vehicle brake can apply a frictional force to the wheel 216 via the controller 250 as part of an automated engine stop process.

[0034] In response to a request to accelerate the vehicle 225, the vehicle system controller can obtain a driver demand torque or power request from an accelerator pedal or other device. The vehicle system controller 255 then allocates a portion of the requested driver demand torque to the engine and the remaining portion to the ISG. The vehicle system controller 255 requests engine torque from the engine controller 12 and ISG torque from the motor controller 252. If the ISG torque plus the engine torque is less than the transmission input torque limit (e.g., does not exceed a threshold), the torque is delivered to the torque converter 206, and then the torque converter delivers at least a portion of the requested torque to the transmission input shaft 270. The transmission controller 254 selectively locks the torque converter clutch 212 and engages gears via the gear clutches 211 in response to a shift schedule and a TCC lock-up schedule that can be based on the input shaft torque and the vehicle speed. In some cases, when it may be desirable to charge the electrical energy storage device 275, a charging torque (e.g., negative ISG torque) can be requested while there is a non-zero driver demand torque. The vehicle system controller 255 can request an increase in engine torque to exceed the charging torque and thus meet the driver demand torque.

[0035] In response to a request to decelerate the vehicle 225 and provide regenerative braking, the vehicle system controller may provide a negative desired wheel torque based on vehicle speed and brake pedal position. The vehicle system controller 255 then allocates a portion of the negative desired wheel torque to the ISG 240 (e.g., the desired powertrain wheel torque) and allocates the remaining portion to the friction brake 218 (e.g., the desired friction brake wheel torque). Additionally, the vehicle system controller may notify the transmission controller 254 that the vehicle is in regenerative braking mode, such that the transmission controller 254 changes the gear 211 based on a unique shift schedule to improve regenerative efficiency. The ISG 240 provides negative torque to the transmission input shaft 270, but the negative torque provided by the ISG 240 may be limited by the transmission controller 254, which outputs a transmission input shaft negative torque limit (e.g., not exceeding a threshold). Additionally, the negative torque of the ISG 240 may be limited by the vehicle system controller 255 or the motor controller 252 based on the operating conditions of the electrical energy storage device 275 (e.g., constrained to be less than a threshold negative torque). Any portion of the desired negative wheel torque that may not be provided by the ISG 240 may be allocated to the friction brake 218 due to transmission or ISG limits, such that the desired wheel torque is provided by a combination of negative wheel torque from the friction brake 218 and the ISG 240.

[0036] Accordingly, the torque control of various powertrain components can be supervised by the vehicle system controller 255, where local torque control of the engine 10, transmission 208, motor 240, and brake 218 is provided via the engine controller 12, motor controller 252, transmission controller 254, and brake controller 250.

[0037] As an example, engine torque output can be controlled by controlling a combination of throttle opening and / or valve timing, valve lift, and boost of a turbocharged or supercharged engine, adjusting spark timing, fuel pulse width, fuel pulse timing, and / or air charge. In the case of a diesel engine, the controller 12 can control engine torque output by controlling a combination of fuel pulse width, fuel pulse timing, and air charge. In all cases, engine control can be performed on a cylinder-by-cylinder basis to control engine torque output.

[0038] The motor controller 252 can control the torque output and electrical energy generation from the ISG 240 by adjusting the current flowing into and out of the field winding and / or armature winding of the ISG, as is known in the art.

[0039] The transmission controller 254 receives the transmission input shaft position via the position sensor 271. The transmission controller 254 can convert the transmission input shaft position into an input shaft speed by differentiating the signal from the position sensor 271 or by counting a plurality of known angular distance pulses within a predetermined time interval. The transmission controller 254 can receive the transmission output shaft torque from the torque sensor 272. Alternatively, the sensor 272 can be a position sensor or a torque and position sensor. If the sensor 272 is a position sensor, the controller 254 can count the shaft position pulses within a predetermined time interval to determine the transmission output shaft speed. The transmission controller 254 can also differentiate the transmission output shaft speed to determine the transmission output shaft acceleration.

[0040] The brake controller 250 receives wheel speed information via the wheel speed sensors 221 and receives a brake request from the vehicle system controller 255. The brake controller 250 can also receive brake pedal position information directly or from the Figure 1 shown brake pedal sensor 154. The brake controller 250 can provide braking in response to a wheel torque command from the vehicle system controller 255. The brake controller 250 can also provide anti-skid and vehicle stability braking to improve vehicle braking and stability. Thus, the brake controller 250 can provide the vehicle system controller 255 with a wheel torque limit (e.g., not exceeding a threshold negative wheel torque) such that negative ISG torque does not cause the wheel torque limit to be exceeded. For example, if the controller 250 issues a negative wheel torque limit of 50 N-m, the ISG torque is adjusted to provide less than 50 N-m (e.g., 49 N-m) of negative torque at the wheel, including considering the transmission gear ratio.

[0041] Therefore, Figure 1 and Figure 2The system provides a system that includes: an engine; a motor / generator selectively coupled to the engine; and a controller that includes executable instructions stored in a non-transitory memory to generate a first engine start request via a first control agent in response to a current vehicle operating condition, instructions to generate a second engine start request via a second control agent in response to a predicted vehicle operating condition, and instructions to start or not start the engine in response to the first engine start request and the second engine start request. The system further includes additional instructions to predict vehicle speed and driver demand torque via the second control agent. The system further includes additional instructions to determine the time when a condition is met, the condition being the basis for generating the second engine start request. The system includes a case where the second engine start request is further generated based on a desired minimum engine run time. The system includes a case where the engine is stopped when the first engine start request and the second engine start request are generated. The system includes a case where the engine is started when both the first engine start request and the second engine start request are concurrently asserted. The system includes a case where no engine request is generated when both the first engine start request and the second engine start request are not concurrently asserted.

[0042] Now referring to Figure 3 , an example graph of a vehicle operation sequence is shown. The operation sequence can be performed in conjunction with the system of Figure 1 and Figure 2 and the method of Figures 4 to 8 . The vertical lines at times T0 to T3 represent times of interest during the sequence. Figure 3 The graphs in

[0043] are time aligned and occur simultaneously. Figure 3 The first graph from the

[0044] top is a graph of battery state of charge (SOC) versus time. Trace 302 represents the actual battery SOC. Trace 306 represents the predicted battery SOC via the second agent, and trace 304 represents the predicted battery SOC via the first agent. The vertical axis represents the battery state of charge and the battery state of charge increases in the direction of the vertical axis arrow. The horizontal axis represents time and time increases from the left side to the right side of the graph. Horizontal line 350 represents the maximum battery SOC limit or threshold. Horizontal line 352 represents the upper battery SOC threshold. Horizontal line 354 represents the lower battery SOC limit or lower threshold. Horizontal line 356 represents the minimum battery SOC threshold. Figure 3The second graph from the top is a graph of vehicle speed versus time. Trace 308 represents the actual vehicle speed. Trace 310 represents the predicted vehicle speed. The vertical axis represents vehicle speed and vehicle speed increases in the direction of the vertical axis arrow. The horizontal axis represents time and time increases from the left side to the right side of the graph.

[0045] From Figure 3 The third graph from the top is a graph of the status of the engine pull-up (EPU) command (CMD) or engine start request versus time. Trace 312 represents the engine pull-up command as determined via the first agent. The vertical axis represents the status of the engine pull-up command as determined via the first agent, and the engine pull-up command is in effect when trace 312 is at a higher level near the vertical axis arrow. When trace 312 is at a lower level near the horizontal axis, the engine pull-up command as determined via the first agent is not in effect. The horizontal axis represents time and time increases from the left side to the right side of the graph.

[0046] From Figure 3 The fourth graph from the top is a graph of the status of the engine pull-up (EPU) command (CMD) or engine start request versus time. Trace 314 represents the engine pull-up command as determined via the second agent. The vertical axis represents the status of the engine pull-up command as determined via the second agent, and the engine pull-up command is in effect when trace 314 is at a higher level near the vertical axis arrow. When trace 314 is at a lower level near the horizontal axis, the engine pull-up command as determined via the second agent is not in effect. The horizontal axis represents time and time increases from the left side to the right side of the graph.

[0047] From Figure 3 The fifth graph from the top is a graph of the status of the actual engine pull-up (EPU) command (CMD) or engine start request versus time. Trace 316 represents the engine pull-up command used by the controller to start or not start the engine. The status of trace 316 indicates whether the engine should actually be started, while traces 312 and 314 are variable states that ultimately determine the status of trace 316. The vertical axis represents the engine pull-up command status based on which the engine is started or not started. The engine pull-up command status is in effect when trace 316 is at a higher level near the vertical axis arrow. When trace 316 is at a lower level near the horizontal axis, the engine pull-up command is not in effect. The horizontal axis represents time and time increases from the left side to the right side of the graph.

[0048] At time T0, the engine stops, as indicated by the actual EPU state being at a lower level, and the battery SOC is between threshold 354 and threshold 352. The vehicle speed is at an intermediate level, and the first and second agents do not request EPU or engine start. Between time T0 and time T1, the battery SOC increases and the vehicle speed increases. The first agent and the second agent do not request EPU. Additionally, the actual EPU is not requested.

[0049] At time T1, the battery SOC starts to decrease and the vehicle speed increases. The first agent and the second agent do not request EPU. Between time T1 and time T2, the battery SOC continues to decrease and the vehicle speed continues to increase. The first agent and the second agent do not request EPU. Additionally, the actual EPU is not requested.

[0050] At time T2, the battery SOC is less than threshold 354, so the first agent requests EPU. However, since the second agent predicts that the battery SOC will increase between time T2 and time T3 (as shown by trace 306), the second agent does not request EPU. Based on the current vehicle condition, the first agent estimates that the battery SOC will decrease to threshold level 356 at time T3. The predicted vehicle speed decreases at time T2, as shown by trace 310. Even though the first agent requests EPU, the actual EPU is not requested because the second agent indicates that EPU is not needed. This sequence ends at time T2, but the parameters including the predicted vehicle speed and the predicted battery SOC are predicted up to time T3.

[0051] Now refer to Figure 4 , a high - level block diagram showing a method for determining whether an EPU should occur. Figure 4 The method of Figures 5 to 8 is a general version of the method shown in Figures 4 to 8 The method of Figure 1 and Figure 2 can be included as executable instructions stored in the non - transitory memory of the system of Figures 4 to 8 and Figure 1 and Figure 2 The method of Figure 1 and Figure 2 can operate in conjunction with the systems of Figures 4 to 8 to receive data and adjust actuators for physical or real - world control of the systems of

[0052] Method 400 includes two control agents. At 404, a first control agent (e.g., a segment or module of control code or executable instructions stored in a controller non-transitory memory) determines whether an EPU request should be initiated or adopted based on the current vehicle operating conditions. The current vehicle operating conditions can include, but are not limited to, battery SOC, battery discharge power, maximum motor torque, current motor torque, driver demand torque, and battery charge and discharge thresholds or limits. If the first control agent determines that an EPU is needed, at 406 it transmits the EPU request to the arbiter segment. An EPU request from the first control agent can be indicated by setting a variable in the memory to a value of 1. When the value of the variable in the memory is 0, the EPU request from the first control agent is not in effect.

[0053] At 402, a second control agent (e.g., a segment or module of control code or executable instructions stored in a controller non-transitory memory) determines whether an EPU request should be initiated or adopted based on the predicted vehicle operating conditions. The predicted vehicle operating conditions can include, but are not limited to, battery SOC, vehicle speed, driver demand power, and the future time at which a predicted event will occur. The second control agent predicts the vehicle operating conditions and, if the conditions in response to the predicted vehicle operating conditions do not meet a predetermined criterion, requests an EPU or engine start. If the second agent determines that an EPU is needed, it transmits the EPU request to the arbiter at 406. An EPU request from the second control agent can be indicated by setting a variable in the memory to a value of 1. When the value of the variable in the memory is 0, the EPU request from the second control agent is not in effect.

[0054] At 406, the arbiter determines whether an actual EPU should be requested in response to the EPU requests provided by the first and second agents. In one example, when the logical "AND" product of the value of the variable representing the EPU request from the first agent and the value of the variable representing the EPU request from the second agent is a value of 1, the arbiter issues an actual EPU to start the engine according to it. Otherwise, the arbiter does not issue an actual EPU request. When the EPU request is in effect, the engine is started. When the EPU request is not in effect, the engine is not started.

[0055] Therefore, the actual EPU request is based on the current condition EPU request from the first control agent and the predicted condition EPU request from the second control agent. In response to the value of the actual EPU request, the engine is started or not started. For example, when the actual EPU request value is 1, the engine is started. When the actual EPU request value is 0, the engine is not started.

[0056] Now refer to Figure 5 , a method for determining whether to start the engine or perform an engine pull-up is shown. Figure 5 The method of Figure 1 andFigure 2 are included by executable instructions in the non-transitory memory of the system. Additionally, Figures 4 to 8 The method can work in conjunction with Figure 1 and Figure 2 the system to receive data and adjust the actuator for physical or real-world control Figure 1 and Figure 2 the system. Figure 5 The method determines whether to request or not request the EPU in response to the battery SOC.

[0057] At 502, a second agent (e.g., a control code segment or module) predicts the vehicle speed. In one example, method 500 predicts the vehicle speed based on the driving route of the vehicle and the speed limit along the driving route. For example, if the vehicle is traveling on a road with a speed limit of 100 kilometers (km) / hr for the next 30 km, method 500 can estimate that for the next 30 km, the vehicle speed will be 100 km / hr. Additionally, method 500 can use traffic data and road condition data to adjust the predicted vehicle speed. For example, if the vehicle is traveling at 100 km / hr, but method 500 receives real-time traffic data indicating that road construction on the road where the vehicle is traveling has slowed the vehicle speed to 30 km / hr at a location 10 km ahead of the vehicle, then it can be predicted that for the next 9 km, the vehicle speed will be 100 km / hr and then slow down to 30 km / hr within the specified distance. Method 500 can adjust the predicted vehicle speed in response to real-time traffic data, vehicle-to-vehicle communication data, and vehicle-to-infrastructure data. Additionally, if the driving record of the vehicle driver is 5 km / hr less than the marked speed limit, method 500 can adjust the predicted vehicle speed in response to the driver's past record. The predicted vehicle speed can be stored as a variable V_pre(t) as a function of future time. Method 500 proceeds to 504.

[0058] At 504, the second agent predicts the driver demand power as a function of future time Pdd_pre(t). The driver demand power is predicted via the following equation:

[0059]

[0060] or

[0061]

[0062] Where Pdd_pre(t) is the predicted driver demand power as a function of future time, m is the vehicle mass, v is the vehicle speed, ρ is the air density, cd is the vehicle drag coefficient, A is the frontal projected area of the vehicle, sin and cos are trigonometric functions, θ is the road angle, t is a specific moment and the predicted driver demand power can be determined over a time period represented as a vector (starting from the current time and ending at a predetermined future time), and g is the gravitational coefficient. The driver demand power can be predicted for the entire driving path or a predetermined distance (e.g., 10 km). Method 500 proceeds to 506.

[0063] At 506, method 500 predicts the battery SOC. In one example, method 500 predicts the battery SOC by recognizing that the battery power source is the power source in response to the predicted driver demand power. Method 500 estimates the state of charge of the battery over a period of time that can be represented in vector form. The state of charge of the battery at a specific moment can be determined via the following equation:

[0064] Pbatt(t) = Pdd_pre(t)

[0065] Pbatt(t) = VI(t) = (Voc - RI)I(t)

[0066] Where

[0067] such that Pbatt = (Voc - RQa)Qa = VocQa - RQ 2 a 2

[0068]

[0069]

[0070] where R is the internal battery resistance, I is the battery current, Voc is the battery open - circuit voltage, Q is the battery charge capacity, SOC is the state of charge of the battery as determined based on the predicted vehicle speed and the predicted driver demand power, t0 is the initial time, and t is the current time. SOC(t) can be determined for each time increment in the time vector describing future time. Method 500 proceeds to 508.

[0071] At 508, method 500 determines whether the following condition is satisfied:

[0072] SOC_pre(t_remainder) >= SOC_low + SOC_off

[0073] Where SOC_pre is the predicted battery SOC, t_margin is the amount of time in the time margin determined at 554, SOC_low is the lower bound or threshold of the desired battery SoC operating range (e.g., the value below which the battery does not discharge), and SOC_off is the offset relative to the SOC lower bound (e.g., 2%). If the predicted battery SOC at time t_margin is greater than or equal to the battery charge state threshold SOC_low + SOC_off, the answer is yes and method 500 proceeds to 510. Otherwise, the answer is no and method 500 proceeds to 512.

[0074] At 510, the second agent does not request the EPU by setting the value of the variable AG2_EPUD_cmd equal to the value 0. Thus, when the predicted battery SOC is not low, the EPU is not requested. Method 500 proceeds to 514.

[0075] At 512, the second agent requests the EPU by setting the value of the variable AG2_EPUD_cmd to the value 1 (e.g., the second agent requests the EPU). Thus, when the predicted battery SOC is low, the EPU is requested. Method 500 proceeds to 514.

[0076] At 550, method 500 and the first control agent monitor the battery SOC. The SOC can be monitored by sensing the battery voltage and current. Method 500 proceeds to 552.

[0077] At 552, method 500 determines whether to request the EPU. In one example, if the following conditions are met, method 500 determines to request the EPU:

[0078] SOC <= SOC_low + cal1

[0079] Where SOC_low is the battery SoC lower threshold as described above, and cal1 is an adjustable offset value. Thus, if the battery SOC is less than the battery SOC lower threshold + the adjustable offset value, method 500 requests the EPU. If the battery SOC is not less than the battery SOC lower threshold + the adjustable offset value, method 500 does not request the EPU. Method 500 proceeds to 554.

[0080] At 554, method 500 determines the time margin. The time margin can be determined via the following equation:

[0081]

[0082] Where t_margin is the margin time, SOC_low is the lower threshold of the battery SOC as described above, SOC_min is the minimum battery SOC below which the battery is not allowed to discharge, and where d(SOC1) / dt is the derivative of the battery SOC averaged over the current time or a previous time window (e.g., from t1 to t2). Thus, the time t_margin is the amount of time it takes for the battery to discharge from the lower threshold of the battery SOC to the minimum battery SOC threshold at the current SOC change rate. The first agent can provide the time t_margin to the second agent. Method 500 proceeds to 514.

[0083] At 514, method 500 arbitrates between the presence or absence of a request from the first agent for the EPU and the presence or absence of a request from the second agent for the EPU. Specifically, if the logical "AND" performed on the variables AG1_EPUD_cmd and variable AG2_EPUD_cmd yields a value of 1, the answer is yes and method 500 proceeds to 516. Otherwise, the answer is no and method 500 proceeds to 518. In some examples, if the SOC is equal to or less than the SOC minimum threshold, method 500 may also proceed to 514.

[0084] At 518, method 500 adjusts the value of EPUD_cmd to a no-request state and does not request engine start or pull-up. No request from the SOC monitoring control code indicates that the engine will not be started via this control code segment. However, an EPU request can be generated via other control code segments, and the engine can be started in response to that request. Method 500 exits.

[0085] At 516, method 500 adjusts the value of EPUD_cmd to a value of 1 or on, and actually requests engine start or pull-up. The engine is started in response to the actual request to start the engine. Method 500 proceeds to exit.

[0086] Thus, method 500 includes two agents that can separately request engine pull-up or start. Method 500 actually requests engine start, and the engine starts in response to the first agent and the second agent simultaneously and contemporaneously requesting engine start. In this way, the engine can be started when engine start is more likely to provide useful benefits.

[0087] Now referring to Figure 6 , a method for determining whether to start the engine or perform an engine pull-up is shown. Figure 6 The method of Figure 1 and Figure 2 can be included as executable instructions in the non-transitory memory of the system of Figures 4 to 8 and Figure 1 and Figure 2The system operates in conjunction to receive data and adjust the actuator for physical or real-world control Figure 1 and Figure 2 the system of Figure 6 The method determines whether to request or not request the EPU in response to the battery discharge power buffer (e.g., the numerical difference between the battery discharge power level that should not be exceeded and the amount of electrical power supplied to meet the driver demand power and the electrical power for starting the engine).

[0088] At 602, a second agent (e.g., a control code segment or module) predicts the vehicle speed. In one example, method 600 predicts the vehicle speed based on the vehicle's driving route and the speed limit along the driving route. Additionally, method 600 can use traffic data and road condition data to adjust the predicted vehicle speed. Method 600 can adjust the predicted vehicle speed in response to real-time traffic data, vehicle-to-vehicle communication data, and vehicle-to-infrastructure data. Additionally, if the vehicle driver's driving record is 5 km / hr less than the posted speed limit, method 600 can adjust the predicted vehicle speed in response to the driver's past record. The predicted vehicle speed can be stored as a variable V_pre(t) as a function of future time. Method 600 proceeds to 604.

[0089] At 604, the second agent predicts the driver demand power as a function of future time Pdd_pre(t), as described at Figure 5 504 of

[0090] In addition, method 600 determines the amount of power reserved for engine starting. In one example, the amount of power reserved for engine starting can be determined by referencing or indexing a table of functions of empirically determined power amounts required to crank and start the engine. The table or function can be referenced via the engine temperature and time since the most recent engine stop. The predicted driver demand power and the amount of power reserved for engine starting are added together and stored in the variable Pbat_dispotpre(t). Method 600 proceeds to 606.

[0090] At 606, method 600 identifies future times at which the following condition is continuously satisfied within a predetermined time period (e.g., 5 seconds) to ensure that the condition is not transient but persistent:

[0091] abs(Pbat_dislim - Pbat_dispotpre(t)) > cal3

[0092] Where Pbat_dislim is the battery power discharge limit determined at 650 (e.g., the maximum power amount that can be discharged from the battery in the next half second) or the upper threshold of the battery discharge power, abs is the absolute value, and Pbat_dispotpre(t) is the sum of the predicted driver demand power and the power amount reserved for engine starting. Method 600 can evaluate the conditions within a predetermined amount of future time by applying the predicted driver demand to determine whether the conditions are met within a predetermined future time (e.g., 2 minutes from the current time). After determining the future time when the above conditions are met, method 600 proceeds to 608.

[0093] At 608, method 600 determines whether the following condition is met:

[0094] (T - t0) <= t_minEngRun + cal4

[0095] Where T is the future time when the condition of step 606 is met, t0 is the current time, t_minEngRun is the minimum desired engine run time (e.g., it may be desired that the engine runs for at least 3 minutes), and cal4 is a predetermined adjustable time (e.g., 30 seconds), which is an offset relative to t_minEngRun. If (T - t0) is less than or equal to t_minEngRun, this means that the battery power consumption will or is predicted to immediately decrease after the EPU, so the answer is yes and method 600 proceeds to 610. Otherwise, the answer is no and method 600 proceeds to 612.

[0096] At 610, the second agent does not request the EPU by setting the value of the variable AG2_EPUD_cmd to be equal to the value 0. Therefore, when the predicted battery discharge power buffer is always greater than a predetermined value (e.g., (T - t0) <= t_minEngRun + cal4) immediately following engine starting, the EPU is not requested. Method 600 proceeds to 614.

[0097] At 612, the second agent requests the EPU by setting the value of the variable AG2_EPUD_cmd to the value 1 (e.g., the second agent requests the EPU). Therefore, when the predicted battery discharge power buffer only becomes always greater than a predetermined value (e.g., (T - t0) > t_minEngRun + cal4) a long time after engine starting, the EPU is requested. Method 600 proceeds to 614.

[0098] At 650, method 600 and the first control agent monitor the first battery discharge power limit. In one example, the battery discharge power limit is empirically determined or pre-calculated and stored in a table or function. The table or function can be referenced or indexed via the battery SOC and battery temperature. The table or function outputs the first battery discharge power limit value (e.g., Pbat_dislim). Additionally, method 600 determines the driver demand power and the amount of engine power reserved for engine starting. In one example, method 600 determines the driver demand power based on the accelerator pedal position and vehicle speed. Specifically, the accelerator pedal position and vehicle speed index or reference a table of empirically determined values that store the driver demand power and the table outputs the driver demand power. The amount of power reserved for engine starting can be determined by referencing or indexing a table of a function of the empirically determined amount of power required to crank and start the engine. The table or function can be referenced via the engine temperature and time since the last engine stop. The amount of power reserved for engine starting and the driver demand power are added together and stored in the memory as the variable Pbat_dischgpot. Method 600 proceeds to 652.

[0099] At 652, method 600 determines whether an EPU is requested. In one example, if the following conditions are met, method 600 determines that an EPU is requested:

[0100] abs(Pbat_dislim - Pbat_dischgpot) <= cal2

[0101] where Pbat_dislim is the battery discharge limit for engine starting, abs is the absolute value of (arg), Pbat_dischgpot is the sum of the driver demand power and the power reserved for starting the engine, and cal2 is a predetermined value. Thus, if the battery discharge power buffer is less than cal2, method 600 requests the EPU. If the battery discharge power buffer is not less than cal2, method 600 does not request the EPU. Method 600 proceeds to 614.

[0102] At 614, method 600 arbitrates between the presence or absence of a request for the EPU by the first agent and the presence or absence of a request for the EPU by the second agent. Specifically, if the logical "AND" performed on the variables AG1_EPUD_cmd and AG2_EPUD_cmd yields a value of 1, the answer is yes and method 600 proceeds to 616. Otherwise, the answer is no and method 600 proceeds to 618.

[0103] At 618, method 600 adjusts the value of EPUD_cmd to the no-request state and does not request engine start or pull-up. No request from the battery discharge power buffer monitoring control code indicates that the engine will not be started via this control code segment. However, an EPU request can be generated via other control code segments, and the engine can be started in response to that request. Method 600 exits.

[0104] At 616, method 600 adjusts the value of EPUD_cmd to value 1 or proceed, and actually requests engine start or pull-up. The engine is started in response to the actual request to start the engine. Method 600 proceeds to exit.

[0105] Thus, method 600 includes two agents that can separately request engine pull-up or start. Method 600 actually requests engine start, and the engine starts in response to the first agent and the second agent simultaneously and contemporaneously requesting engine start. In this way, the engine can be started when engine start is more likely to provide useful benefits.

[0106] Now refer to Figure 7 , a method for determining whether to start the engine or perform an engine pull-up is shown. Figure 7 The method of Figure 1 and Figure 2 can be included as executable instructions stored in the non-transitory memory of the system of Figures 4 to 8 and Figure 1 and Figure 2 The method of Figure 1 and Figure 2 The system of Figure 7 The method of

[0107] At 702, a second agent (e.g., a control code segment or module) predicts the vehicle speed. In one example, method 700 predicts the vehicle speed based on the vehicle's driving route and the speed limit along the driving route. Additionally, method 700 can use traffic data and road condition data to adjust the predicted vehicle speed. Method 700 can adjust the predicted vehicle speed in response to real-time traffic data, vehicle-to-vehicle communication data, and vehicle-to-infrastructure data. Additionally, if the vehicle driver's driving record is 5 km / hr less than the posted speed limit, method 700 can adjust the predicted vehicle speed in response to the driver's past record. The predicted vehicle speed can be stored as a variable V_pre(t) as a function of future time. Method 700 proceeds to 704.

[0108] At 704, a second agent predicts the driver demand power as a function of future time Pdd_pre(t), as described at Figure 5 504. Additionally, method 700 determines the amount of motor torque (e.g., predicted motor torque) to meet the predicted driver demand power. Motor torque can be provided by the starter / generator 340 shown at Figure 2 . In one example, method 700 determines the predicted motor torque by the following equation:

[0109]

[0110]

[0111]

[0112] where P mtr is the predicted power provided by the motor, Pdd_pre(t) is the predicted driver demand power, Tq whl is the wheel torque, v is the predicted vehicle speed, R is the tire radius, TqMtrpre is the predicted motor torque, and rt is the torque ratio between the wheel and the motor. Method 700 proceeds to 706.

[0113] At 706, method 700 identifies future times when the absolute value of the predicted motor torque buffer (e.g., Tq_MtrMax – TqMtrPre) is greater than a predetermined value (cal6) that is always met within a predetermined amount of time:

[0114] abs(Tq_MtrMax - TqMtrpre) > cal6

[0115] where Tq_MtrMax is the maximum allowable motor torque, TqMtrpre is the motor torque predicted from 704, and cal6 is a predetermined torque amount. Method 700 can evaluate the condition within a predetermined amount of future time by applying the predicted motor torque to determine if the condition is met within a predetermined future time (e.g., 2 minutes from the current time). After determining the future time when the above condition is met, method 700 proceeds to 708.

[0116] At 708, method 700 determines if the following condition is met:

[0117] (T - t0) <= t_minEngRun + cal7

[0118] where T is the future time when the condition of step 706 is met, t0 is the current time, t_minEngRun is the minimum desired engine run time (e.g., it may be desired for the engine to run for at least 3 minutes), and cal7 is a predetermined adjustable time (e.g., 30 seconds), which is an offset relative to t_minEngRun. If (T - t0) is less than or equal to t_minEngRun, this means that the motor torque request will or is predicted to drop immediately after the EPU, so the answer is yes and method 700 proceeds to 710. Otherwise, the answer is no and method 700 proceeds to 712.

[0119] At 710, the second agent does not request the EPU by setting the value of the variable AG2_EPUD_cmd to be equal to the value 0. Thus, if so commanded, the EPU is not requested when the predicted motor torque buffer is greater than the threshold immediately after engine start. Method 700 proceeds to 714.

[0120] At 712, the second agent requests the EPU by setting the value of the variable AG2_EPUD_cmd to the value 1 (e.g., the second agent requests the EPU). Thus, the EPU is requested when the commanded predicted motor torque buffer is greater than the threshold long after engine start. Method 700 proceeds to 714.

[0121] At 750, method 700 and the first control agent monitor the maximum motor torque and the motor torque to meet the driver demand torque. In one example, the maximum motor torque threshold is empirically determined or pre-calculated and stored in a table or function. The table or function can be referenced or indexed via the battery SOC and the motor temperature. The table or function outputs the maximum motor torque (e.g., Tq_MtrMax, the maximum torque amount that can be output from the motor) or the upper threshold of the motor torque. Additionally, method 700 determines the motor torque to meet the driver demand power. In one example, the motor torque can be determined by referencing or indexing a table or function of motor torque values via the current supplied to the motor and the motor speed. The table outputs the motor torque to meet the driver demand (e.g., TqMtrDD). Method 700 proceeds to 752.

[0122] At 752, method 700 determines whether to request the EPU. In one example, if the following condition is met, method 700 determines to request the EPU:

[0123] abs(Tq_MtrMax - TqMtrDD) <= cal5

[0124] Where Tq_MtrMax is the maximum motor torque threshold, TqMtrDD is the motor torque to meet the driver's demand, abs is the absolute value of (arg), and cal5 is a predetermined value. Thus, if the motor torque buffer is less than cal5, method 700 requests the EPU. If the motor torque buffer is not less than cal5, method 700 does not request the EPU. Method 700 proceeds to 714.

[0125] At 714, method 700 arbitrates between the presence or absence of a request for the EPU from a first agent and the presence or absence of a request for the EPU from a second agent. Specifically, if the logical "AND" performed on the variables AG1_EPUD_cmd and variable AG2_EPUD_cmd yields a value of 1, the answer is yes and method 700 proceeds to 716. Otherwise, the answer is no and method 700 proceeds to 718.

[0126] At 718, method 700 adjusts the value of EPUD_cmd to a no-request state and does not request engine start or pull-up. No request from the motor torque buffer code indicates that the engine will not be started via this control code segment. However, an EPU request can be generated via other control code segments, and the engine can be started in response to that request. Method 700 exits.

[0127] At 716, method 700 adjusts the value of EPUD_cmd to a value of 1 or go-ahead, and actually requests engine start or pull-up. The engine is started in response to an actual request to start the engine. Method 700 proceeds to exit.

[0128] Thus, method 700 includes two agents that can separately request engine pull-up or start in response to motor torque limitations. Method 700 actually requests engine start, and the engine starts in response to the first agent and the second agent simultaneously and contemporaneously requesting engine start due to motor torque limitations. In this way, the engine can be started when starting the engine is more likely to provide useful benefits.

[0129] Now refer to Figure 8 , a method for determining whether to start the engine or perform an engine pull-up is shown. Figure 8 The method of Figure 1 and Figure 2 can be included as executable instructions in the non-transitory memory of the system of Figures 4 to 8 and Figure 1 and Figure 2 The method of Figure 1 and Figure 2 can operate in conjunction with the system of Figure 8The method determines to request or not to request the EPU in response to the battery discharge limit or the upper threshold.

[0130] At 802, a second agent (e.g., a control code segment or module) predicts the vehicle speed. In one example, method 800 predicts the vehicle speed based on the vehicle's driving route and the speed limit along the driving route. Additionally, method 800 may use traffic data and road condition data to adjust the predicted vehicle speed. Method 800 may adjust the predicted vehicle speed in response to real-time traffic data, vehicle-to-vehicle communication data, and vehicle-to-infrastructure data. Additionally, if the vehicle driver's driving record is 5 km / hr less than the posted speed limit, method 800 may adjust the predicted vehicle speed in response to the driver's past record. The predicted vehicle speed may be stored as a variable V_pre(t) as a function of future time. Method 800 proceeds to 804.

[0131] At 804, the second agent predicts the driver demand power as a function of future time Pdd_pre(t), as described at Figure 5 504. Method 800 proceeds to 806.

[0132] At 806, method 800 identifies future times at which the following condition is continuously satisfied within a predetermined time period:

[0133] Pdd_pre(t) < cal9

[0134] where cal9 is a predetermined driver demand power. Method 800 may evaluate the condition within a predetermined amount of future time by applying the predicted driver demand to determine whether the condition is satisfied within a predetermined future time (e.g., 2 minutes from the current time). After determining the future time at which the above condition is satisfied, method 800 proceeds to 808.

[0135] At 808, method 800 determines whether the following condition is satisfied:

[0136] (T - t0) <= t_minEngRun + cal10

[0137] where T is the time at which the condition of step 806 is satisfied, t0 is the current time, t_minEngRun is the minimum desired engine run time (e.g., it may be desired for the engine to run for at least 3 minutes), and cal10 is a predetermined adjustable time (e.g., 30 seconds), which is an offset relative to t_minEngRun. If (T - t0) is less than or equal to t_minEngRun, this means that the battery power consumption will or is predicted to immediately drop after the EPU, and thus, the answer is yes and method 800 proceeds to 810. Otherwise, the answer is no and method 800 proceeds to 812.

[0138] At 810, the second agent does not request the EPU by setting the value of the variable AG2_EPUD_cmd to be equal to the value 0. Thus, if so commanded, when the predicted battery discharge is less than the threshold immediately after engine start, the EPU is not requested. Method 800 proceeds to 814.

[0139] At 812, the second agent requests the EPU by setting the value of the variable AG2_EPUD_cmd to the value 1 (e.g., the second agent requests the EPU). Thus, if so commanded, when the predicted battery discharge power is greater than the threshold immediately after engine start, the EPU is requested. Method 800 proceeds to 814.

[0140] At 850, method 800 and the first control agent monitor the second battery discharge power limit (e.g., the upper threshold that should not be exceeded for the vehicle driving condition). In one example, the battery discharge power limit is empirically determined or pre-calculated and stored in a table or function. The table or function can be referenced or indexed via the battery SOC and the battery temperature. The table or function outputs the battery discharge power limit value (e.g., Pbat_dislim2). Method 800 proceeds to 852.

[0141] At 852, method 800 determines whether to request the EPU. In one example, if the following condition is met, method 800 determines to request the EPU:

[0142] abs(Pbat_dislim2)<=cal8

[0143] where Pbat_dislim2 is the battery discharge limit for vehicle propulsion, abs is the absolute value of (arg), and cal8 is a predetermined value. Thus, if the battery discharge limit is less than or equal to cal8, method 800 requests the EPU. If the battery discharge limit is not less than cal8, method 800 does not request the EPU. Method 800 proceeds to 814.

[0144] At 814, method 800 arbitrates between the presence or absence of a request for the EPU from the first agent and the presence or absence of a request for the EPU from the second agent. Specifically, if the logical "AND" performed on the variable AG1_EPUD_cmd and the variable AG2_EPUD_cmd yields the value 1, the answer is yes and method 800 proceeds to 816. Otherwise, the answer is no and method 800 proceeds to 818.

[0145] At 818, method 800 adjusts the value of EPUD_cmd to the no-request state and does not request engine start or pull-up. No request from the battery discharge limit monitoring control code indicates that the engine will not be started via this control code segment. However, an EPU request can be generated via other control code segments, and the engine can be started in response to that request. Method 800 exits.

[0146] At 816, method 800 adjusts the value of EPUD_cmd to value 1 or proceed and actually requests engine start or pull-up. The engine is started in response to the actual request to start the engine. Method 800 advances to exit.

[0147] Thus, method 800 includes two agents that can separately request engine pull-up or start. Method 800 actually requests engine start, and the engine starts in response to the first agent and the second agent simultaneously and synchronously requesting engine start due to the battery discharge condition.

[0148] Figures 4 to 8 The method provides a powertrain operation method that includes: receiving data at a controller; adjusting the state of a first engine start request generated via a first control agent in response to the data; adjusting the state of a second engine start request generated via a second control agent in response to a predicted vehicle condition; and starting or not starting the engine in response to arbitration of the first engine start request and the second engine start request. The method includes the case where the first control agent is a first module of executable instructions stored in the memory of the controller. The method includes the case where the second control agent is a second module of executable instructions stored in the memory of the controller. The method includes the case where the arbitration includes performing a logical AND operation of the first engine start request and the second engine start request. The method includes the case where the engine is started when the logical AND operation produces a value of 1. The method includes the case where no engine start request is generated when the logical AND operation produces a value of 0. The method includes the case where the first engine start request is based on the current vehicle operating condition. The method includes the case where the second engine start request is based on a predicted vehicle condition.

[0149] Figures 4 to 8The method provides a method for operating a powertrain system, the method comprising: receiving data at a controller; monitoring a first control parameter and generating a first engine start request via a first control agent in response to the first control parameter; predicting a value of a second control parameter and generating a second engine start request via a second control agent in response to the predicted value; and starting or not starting the engine in response to the first engine start request and the second engine start request. The method includes the case of starting the engine in response to the first engine start request being effective and the second engine start request being effective. The method includes the case where the first control parameter is the state of charge of the battery and the second control parameter is a predicted value of the state of charge of the battery based on a predicted driver demand power. The method includes the case where the first control parameter is a battery discharge threshold and the second control parameter is the time at which a predetermined condition occurs. The method includes the case where the first control parameter is an upper threshold of motor torque.

[0150] Note that the example control and estimation routines included herein can be used with a variety of engine and / or vehicle system configurations. The control methods and routines disclosed herein can be stored as executable instructions in a non-transitory memory and can be executed by a control system including a controller in conjunction with a variety of sensors, actuators, and other engine hardware. The particular routines described herein can represent one or more of any number of processing strategies, such as event-driven, interrupt-driven, multi-tasking, multi-threading, etc. As such, the various actions, operations, and / or functions shown can be executed in the order shown, in parallel, or in some cases omitted. Also, the order of processing is not necessarily required to implement the features and advantages of the example embodiments described herein, but is provided for ease of illustration and description. One or more of the actions, operations, and / or functions shown can be repeatedly executed according to the particular strategy used. Additionally, at least a portion of the actions, operations, and / or functions described can be graphically represented as code to be programmed into the non-transitory memory of a computer-readable storage medium for a control system. When the described actions are executed by executing instructions in a system including a combination of various engine hardware components and one or more controllers, the control actions can also transform the operating state of one or more sensors or actuators in the physical world.

[0151] This concludes the description of the specification. Reading this specification by those skilled in the art will suggest many changes and modifications without departing from the spirit and scope of this specification. For example, I3, I4, I5, V6, V8, V10, and V12 engines operating in natural gas, gasoline, diesel, or alternative fuel configurations can benefit from this specification.

[0152] According to the present invention, there is provided a method for operating a power transmission system, the method having: receiving data at a controller; adjusting a status of a first engine start request generated via a first control agent in response to the data; adjusting a status of a second engine start request generated via a second control agent in response to a predicted vehicle condition; and starting or not starting an engine in response to arbitration of the first engine start request and the second engine start request.

[0153] According to one embodiment, the first control agent is a first module of executable instructions stored in a memory of the controller.

[0154] According to one embodiment, the second control agent is a second module of executable instructions stored in a memory of the controller.

[0155] According to one embodiment, the arbitration includes performing a logical "AND" operation on the first engine start request and the second engine start request.

[0156] According to one embodiment, when the logical "AND" operation results in a value of 1, the engine is started.

[0157] According to one embodiment, when the logical "AND" operation results in a value of 0, no engine start request is generated.

[0158] According to one embodiment, the first engine start request is based on a current vehicle operating condition.

[0159] According to one embodiment, the second engine start request is based on a predicted vehicle operating condition.

[0160] According to the present invention, there is provided a method for operating a power transmission system, the method having: receiving data at a controller; monitoring a first control parameter and generating a first engine start request via a first control agent in response to the first control parameter; predicting a value of a second control parameter and generating a second engine start request via a second control agent in response to the predicted value; and starting or not starting an engine in response to the first engine start request and the second engine start request.

[0161] According to one embodiment, the engine is started in response to the first engine start request being effective and the second engine start request being effective, and wherein the first control parameter is a battery discharge threshold.

[0162] According to one embodiment, the first control parameter is a state of charge of the battery, and wherein the second control parameter is a predicted value of the state of charge of the battery based on a predicted driver demand power.

[0163] According to one embodiment, the first control parameter is a battery discharge power buffer, and wherein the second control parameter is a time at which a predetermined condition occurs.

[0164] According to one embodiment, the first control parameter is a motor torque buffer, and wherein the second control parameter is the time at which a predetermined condition occurs.

[0165] According to the present invention, there is provided a system having: an engine; a motor / generator selectively coupled to the engine; and a controller including executable instructions stored in a non-transitory memory to generate a first engine start request via a first control agent in response to a current vehicle condition, instructions to generate a second engine start request via a second control agent in response to a predicted vehicle condition, and instructions to start or not start the engine in response to the first engine start request and the second engine start request.

[0166] According to one embodiment, the above invention is further characterized by having additional instructions to predict vehicle speed and driver demand torque via the second control agent.

[0167] According to one embodiment, the above invention is further characterized by having additional instructions to determine the time at which a condition is met, the condition being the basis for generating the second engine start request.

[0168] According to one embodiment, the second engine start request is further generated based on a desired minimum engine run time.

[0169] According to one embodiment, when the first engine start request and the second engine start request are generated, the engine stops.

[0170] According to one embodiment, when both the first engine start request and the second engine start request are in effect simultaneously, the engine is started.

[0171] According to one embodiment, when the first engine start request and the second engine start request are not in effect simultaneously, no engine request is generated.

Claims

1. A method for operating a power transmission system, comprising: Receive data at a controller; Adjust the status of a first engine start request generated in response to the data via a first control agent, wherein the data for generating the first engine start request includes one of the following: battery SOC, battery discharge power, maximum motor torque, current motor torque, driver demand torque, and battery charge and discharge thresholds or limits; Adjust the status of a second engine start request generated in response to predicted vehicle conditions via a second control agent, wherein the predicted vehicle conditions include one of the following: battery SOC, vehicle speed, driver demand power; and Start or not start the engine in response to arbitration of the first engine start request and the second engine start request.

2. The method according to claim 1, wherein the first control agent is a first module of executable instructions stored in the memory of the controller.

3. The method according to claim 2, wherein the second control agent is a second module of executable instructions stored in the memory of the controller.

4. The method according to claim 2, wherein the arbitration includes performing a logical "AND" operation on the first engine start request and the second engine start request.

5. The method according to claim 4, wherein when the logical "AND" operation produces a value of 1, the engine is started.

6. The method according to claim 4, wherein when the logical "AND" operation produces a value of 0, no engine start request is generated.

7. The method according to claim 1, wherein the first engine start request is based on the current vehicle operating conditions.

8. The method according to claim 7, wherein the second engine start request is based on predicted vehicle operating conditions.

9. A system for a vehicle, comprising: Engine; A motor / generator selectively coupled to the engine; And A controller including executable instructions stored in a non-transitory memory to generate a first engine start request in response to current vehicle operating conditions via a first control agent, instructions to generate a second engine start request in response to predicted vehicle conditions via a second control agent, and instructions to start or not start the engine in response to the first engine start request and the second engine start request, wherein the current vehicle operating conditions include one of the following: battery SOC, battery discharge power, maximum motor torque, current motor torque, driver demand torque, and battery charge and discharge thresholds or limits; the predicted vehicle conditions include one of the following: battery SOC, vehicle speed, driver demand power.

10. The system for a vehicle according to claim 9, further comprising additional instructions for predicting vehicle speed and driver demand torque via the second control agent.

11. The system for a vehicle according to claim 10, further comprising additional instructions for determining the time when a condition is met, the condition being the basis for generating the second engine start request.

12. The system for a vehicle according to claim 11, wherein the second engine start request is further generated based on a desired minimum engine run time.

13. The system for a vehicle according to claim 9, wherein when the first engine start request and the second engine start request are generated, the engine stops.

14. The system for a vehicle according to claim 9, wherein the engine is started when both the first engine start request and the second engine start request are in effect simultaneously.

15. The system for a vehicle according to claim 14, wherein no engine request is generated when the first engine start request and the second engine start request are not in effect simultaneously.

Images