System and method for controlling module alarm wake-up

Abstract

The present disclosure provides "Systems and Methods for Controlling Module Alarm Wake-up". Methods and systems are provided for scheduling an alarm wake-up so that a control module of a vehicle wakes itself up when the vehicle is turned off in order to perform requested features including post-diagnostic run tasks and non-post-diagnostic run tasks. In one example, a method may include: during a shutdown event of the control module, asking multiple requested features for alarm wake-up times; receiving multiple alarm wake-up times from the multiple requested features; selecting one alarm wake-up time from the received multiple alarm wake-up times; and setting a timer for the selected alarm wake-up time. When the timer elapses at the selected alarm wake-up time, the control module is woken up and a run request is sent to each of the multiple requested features.

Description

Technical Field

[0001] This description generally relates to methods and systems for controlling a vehicle control module to self-wake up during a post-run period.

[0002] Background Art / Disclosure of the Invention

[0003] In the case of increasingly complex modern vehicles, vehicle control modules (e.g., powertrain control modules, engine control modules, transmission control modules, etc.) are often configured to self-wake up during a post-run period after the vehicle has been turned off to perform various features. The various features may include, for example, running diagnostics, uploading vehicle data (e.g., uploading to the cloud) or downloading control strategies and calibrations (e.g., from the cloud). Additionally, each of the various features may request a different wake-up time, which may complicate the control module wake-up strategy and result in missed wakes and / or unexpected wakes.

[0004] Other attempts to arbitrate multiple wake-up requests include using an alarm wake-up manager to schedule wake-up requests. An exemplary method is shown by Kurnik et al. in U.S. 9,390,569 B2. Therein, a method for a wake-up request manager is disclosed, which collects wake-up requests from in-vehicle vehicle subsystems, control modules, and / or processing tasks during a controller shutdown procedure to set the wake-up time of the controller. Priority is given to the nearest (in time) requested wake-up time, while other requested wake-up times are queued such that the controller will be woken up at all requested wake-up times.

[0005] However, the inventors herein have recognized potential problems with such systems. As an example, after the controller wakes up at a set time, especially when the scheduled feature is a diagnostic routine, conditions such as environmental conditions may not be optimal for performing the scheduled feature. For example, performing a diagnostic routine during sub-optimal conditions may increase the incidence of false fault detections. As another example, repeated wake-up events during a vehicle shutdown period may drain the vehicle's battery.

[0006] In one example, the problems described above can be solved by a method that includes: asking a first requested feature and a second requested feature for alarm wake-up times; selecting a first alarm wake-up time from the first requested feature and not selecting a second alarm wake-up time from the second requested feature; setting a timer for the first alarm wake-up time; and sending a run request to the first requested feature and the second requested feature after the timer elapses. In this way, both the first requested feature and the second requested feature can be executed during a single alarm wake-up (e.g., at the first alarm wake-up time).

[0007] As an example, the first request feature and the second request feature may be included in a control module of a vehicle. In response to the query, the first request feature and the second request feature may each determine their respective alarm wake-up times based on current vehicle conditions and their respective input conditions. The control module may be turned off (e.g., put in a sleep mode) after setting the timer and woken up when the timer elapses. After receiving a run request, the first request feature and the second request feature may each compare the current vehicle conditions with their respective input conditions. The first request feature may run in response to the input conditions of the first request feature being met and may not run in response to the input conditions of the first request feature not being met, regardless of whether the second request feature runs and whether its alarm wake-up time is selected. Similarly, the second request feature may run in response to the input conditions of the second request feature being met and may not run in response to the input conditions of the second request feature not being met, regardless of whether the first request feature runs and whether its alarm wake-up time is selected. Additionally, either of the first request feature or the second request feature that is not running may request a new alarm wake-up time. In this way, each of the first request feature and the second request feature may be executed only when their respective input conditions are met, enabling each feature to be executed when conditions are optimal and thereby reducing the incidence of false fault detection.

[0008] As another example, an alarm wake-up counter may be incremented after waking up the control module. After receiving a request for a new alarm wake-up time, if the count of the alarm wake-up counter is less than a threshold count, then the timer may be set only for the new alarm wake-up time. In this way, the vehicle battery will not be drained due to repeated alarm wake-ups.

[0009] It should be understood that the above summary is provided to introduce in a simplified form a series of concepts that are further described in the detailed description. This does not mean identifying the key or essential features of the claimed subject matter, the scope of which is uniquely defined by the claims that follow the detailed description. Additionally, the claimed subject matter is not limited to implementations that solve any of the above disadvantages or those described in any part of this disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] Figure 1 An exemplary vehicle propulsion system is schematically shown.

[0011] Figure 2A schematic depiction of a fuel system and an evaporative emissions system coupled to an engine system that may be included in a vehicle propulsion system is shown.

[0012] Figure 3 A block diagram showing a first example of an alarm wake-up system is shown.

[0013] Figure 4 A block diagram showing a second example of an alarm wake-up system is shown.

[0014] Figure 5 A flowchart showing an exemplary method for setting a control module alarm wake-up using an alarm wake-up system is shown.

[0015] Figure 6 A flowchart showing an exemplary method for operating a control module in an alarm wake-up mode in response to an alarm wake-up or in a nominal mode in response to a non-alarm wake-up is shown.

[0016] Figure 7 An example of foreshadowing for setting a timer to wake up a control module via an alarm wake-up system during a vehicle shutdown period and waking up the control module when the timer expires is depicted. DETAILED DESCRIPTION

[0017] The following description relates to systems and methods for waking up a control module of a vehicle system (e.g., an exemplary vehicle system shown in Figure 3 and Figure 4 ) using an alarm wake-up system (e.g., an exemplary alarm wake-up system shown in Figure 1 ) when the vehicle is turned off. By way of example, the alarm wake-up system may include: a request feature that requests an alarm wake-up time during a control module shutdown event; a wake-up manager that receives the requested alarm wake-up time from the request feature and selects an alarm wake-up time; and a timer that the wake-up manager sets for the selected alarm wake-up time according to, for example, an exemplary method of Figure 5 . The vehicle system may further include an evaporative emissions system, such as the evaporative emissions system shown in Figure 2 , and the request feature may include an engine-off evaporative emissions system diagnostic test. After the timer expires at the selected alarm wake-up time, the control module may be woken up while the vehicle is still turned off to execute the request feature, including the engine-off evaporative emissions system diagnostic test, in response to corresponding input conditions that satisfy the request feature, according to, for example, an exemplary method of Figure 6 . Figure 7An exemplary timeline is shown for setting an alarm wake-up time at a timer and waking up a control module to perform a requested feature after the timer elapses at the alarm wake-up time.

[0018] Figure 1 An exemplary vehicle system 100 is illustrated. The vehicle system 100 includes a fuel combustion engine 110 and a motor 120. As a non-limiting example, the engine 110 includes an internal combustion engine and the motor 120 includes an electric motor. The motor 120 may be configured to utilize or consume an energy source different from that of the engine 110. For example, the engine 110 may consume liquid fuel (e.g., gasoline) to produce an engine output, while the motor 120 may consume electrical energy to produce a motor output. Thus, a vehicle having the propulsion system 100 may be referred to as a hybrid electric vehicle (HEV).

[0019] The vehicle system 100 may utilize a variety of different operating modes depending on the operating conditions encountered by the vehicle propulsion system. Some of these modes may enable the engine 110 to be maintained in a shut-off state (e.g., set to a deactivated state), in which the combustion of fuel at the engine is aborted and the engine is in a stationary state. For example, under selected operating conditions, when the engine 110 is deactivated, the motor 120 may propel the vehicle via the drive wheels 130, as indicated by arrow 122.

[0020] During other operating conditions, the engine 110 may be set to a deactivated state (as described above), while the motor 120 may be operated to charge the energy storage device 150. For example, the motor 120 may receive wheel torque from the drive wheels 130, as indicated by arrow 122, and may convert the vehicle's kinetic energy into electrical energy for storage at the energy storage device 150, as indicated by arrow 124. This operation may be referred to as regenerative braking of the vehicle. Thus, the motor 120 may act as a generator in some instances. However, in other instances, the generator 160 may alternatively receive wheel torque from the drive wheels 130 and may convert the vehicle's kinetic energy into electrical energy for storage at the energy storage device 150, as indicated by arrow 162. As an additional example, the motor 120 may use the energy stored at the energy storage device 150 to rotate the engine 110 to start in a starting operation, as indicated by arrow 186. The energy storage device may include one or more batteries. For example, the energy storage device may include one or more traction batteries and / or one or more starting, lighting, and ignition (SLI) batteries.

[0021] During other operating conditions, the engine 110 can be operated by burning fuel received from the fuel system 140, as indicated by arrow 142. For example, when the motor 120 is disabled, the engine 110 can be operated to propel the vehicle via the drive wheels 130, as indicated by arrow 112. During other operating conditions, the engine 110 and the motor 120 can each be operated to propel the vehicle via the drive wheels 130, as indicated by arrows 112 and 122 respectively. A configuration in which the engine and the motor can selectively propel the vehicle can be referred to as a parallel type vehicle propulsion system. It should be noted that in some instances, the motor 120 can propel the vehicle via a first set of drive wheels, and the engine 110 can propel the vehicle via a second set of drive wheels.

[0022] In other instances, the vehicle system 100 can be configured as a series type vehicle propulsion system, whereby the engine does not directly propel the drive wheels. Instead, the engine 110 can be operated to supply power to the motor 120, which in turn can propel the vehicle via the drive wheels 130, as indicated by arrow 122. For example, during selected operating conditions, the engine 110 can drive the generator 160 as indicated by arrow 116, which in turn can supply electrical energy to one or more of the motors 120 as indicated by arrow 114 or to the energy storage device 150 as indicated by arrow 162. As another example, the engine 110 can be operated to drive the motor 120, which in turn can act as a generator to convert the engine output into electrical energy. The electrical energy can be stored at the energy storage device 150 (e.g.) for later use by the motor.

[0023] The fuel system 140 can include one or more fuel storage tanks 144 for storing fuel on the vehicle, one or more fuel pumps, and one or more fuel rails. For example, the fuel tank 144 can store one or more liquid fuels, including (but not limited to): gasoline, diesel, and ethanol fuel. In some instances, the fuel can be stored on the vehicle as a mixture of two or more different fuels. For example, the fuel tank 144 can be configured to store a mixture of gasoline and ethanol (e.g., E10, E85, etc.) or a mixture of gasoline and methanol (e.g., M10, M85, etc.), whereby these fuels or fuel mixtures can be delivered to the engine 110 as indicated by arrow 142. Other suitable fuels or fuel mixtures can be supplied to the engine 110, where they can be burned to produce an engine output (e.g., torque). The engine output can be used to propel the vehicle (as indicated by arrow 112), or to recharge the energy storage device 150 via the motor 120 or the generator 160. Additionally, in some instances, the fuel system 140 can be coupled to an evaporative emissions system, as will be described with respect to Figure 2 as described.

[0024] In some examples, the energy storage device 150 can be configured to store electrical energy, and the electrical energy can be supplied to other electrical loads (other than the motor) residing on the vehicle, including cabin heating and air conditioning, engine starting, headlights, cabin audio and video systems, etc. As a non-limiting example, the energy storage device 150 can include one or more storage batteries and / or capacitors.

[0025] The control system 190 can communicate with one or more of the engine 110, the motor 120, the fuel system 140, the energy storage device 150, and the generator 160. The control system 190 can receive sensed feedback information from one or more of the engine 110, the motor 120, the fuel system 140, the energy storage device 150, and the generator 160. In addition, the control system 190 can send control signals to one or more of the engine 110, the motor 120, the fuel system 140, the energy storage device 150, and the generator 160 in response to this sensed feedback. In addition, the control system 190 can include a plurality of control modules. Each of the plurality of control modules can include a microprocessor unit, input / output ports, an electronic storage medium for executable programs (e.g., executable instructions) and calibration values, such as a non-transitory read-only memory (ROM) chip, random access memory (RAM), keep-alive memory (KAM), and a data bus. The plurality of control modules can communicate with each other on a controller area network (CAN), as will be described further with respect to Figure 3 and Figure 4 further described.

[0026] The control system 190 can receive an indication of the output of the vehicle propulsion system requested by the vehicle operator 102. For example, the control system 190 can receive sensed feedback regarding the position of the pedal 192 from the pedal position sensor 194. The pedal 192 can schematically refer to a brake pedal and / or an accelerator pedal that the vehicle operator 102 can depress. In addition, in some examples, the control system 190 can communicate with a remote engine start receiver 195 (or transceiver) that receives a wireless signal 106 from a remote key 104 having a remote start button 105. In other examples (not shown), remote engine start can be initiated via a cellular phone or a smartphone-based system, where the user's phone sends data to a server and the server communicates with the vehicle to start the engine.

[0027] The energy storage device 150 can periodically receive electrical energy from a power source 180 that resides external to the vehicle (e.g., an external fixed power grid that is not part of the vehicle), as indicated by arrow 184. As a non-limiting example, the vehicle system 100 can be configured as a plug-in HEV, whereby electrical energy can be supplied from the power source 180 to the energy storage device 150 via an electrical power transmission cable 182. During a recharging operation of the energy storage device 150 from the power source 180, the electrical transmission cable 182 can electrically couple the energy storage device 150 and the power source 180. When operating the vehicle propulsion system to propel the vehicle, the electrical transmission cable 182 can be disconnected between the power source 180 and the energy storage device 150. The control system 190 can identify and / or control the amount of electrical energy stored at the energy storage device, which electrical energy can be referred to as the state of charge (SOC).

[0028] In other instances, the electrical power transmission cable 182 can be omitted, where electrical energy can be received wirelessly at the energy storage device 150 from the power source 180. By way of example, the energy storage device 150 can receive electrical energy from the power source 180 via one or more of electromagnetic induction, radio waves, and electromagnetic resonance. Thus, it should be understood that any suitable method can be used for recharging the energy storage device 150 from a power source that does not form part of the vehicle. In this manner, the motor 120 can propel the vehicle by utilizing an energy source other than the fuel utilized by the engine 110.

[0029] In other instances, the vehicle system 100 can include one or more solar cells 108 that operate to convert incident solar radiation into electrical energy. The one or more solar cells 108 are electrically coupled to the solar cell 30 via a charge controller 32. The solar cells 108 and the charge controller 32 operate to supply current to charge the solar cell 30. In this instance, the solar cell 30 is housed within the energy storage device 150 and is electrically coupled to the energy storage device, but in other configurations, the solar cell 30 can be electrically coupled to the energy storage device 150 while being housed separately. In other configurations, the solar cell 30 can be physically and electrically isolated from the energy storage device 150. The solar cell 30 can thus be configured to provide charge or receive charge from the energy storage device 150 depending on engine operating conditions, state of charge, and battery requirements. In some instances, the solar cell 30 can be configured to independently supply charge directly to vehicle actuators and devices. Additionally, in some instances, the charge controller 32 can be used to supply power directly to vehicle actuators and devices without first storing charge in the solar cell 30.

[0030] The solar cell 108 can be installed on any convenient outer surface of the vehicle, such as the roof, hood, trunk, etc. However, the solar cell 108 can alternatively or additionally be installed inside the vehicle, such as on the instrument panel or other passenger compartment surfaces near windows or interior lights. Generally, the solar cell operates to convert incident solar radiation into electrical energy. In some embodiments, the solar cell 108 can include a series of photovoltaic cells formed of an amorphous semiconductor material such as silicon. Additionally, individual photovoltaic cells can be interconnected to provide a constant flow of electrical energy to a common output cable 188 that electrically couples the solar cell 108 to the charge controller 32 and the solar cell 30. In this way, the solar cell 108 can generate electrical energy for propelling the vehicle or supplying power to one or more vehicle actuators and devices.

[0031] The fuel system 140 can periodically receive fuel from a fuel source residing outside the vehicle. As a non-limiting example, the vehicle system 100 can be refueled by receiving fuel via a fuel dispensing device 170, as indicated by arrow 172. In some instances, the fuel tank 144 can be configured to store the fuel received from the fuel dispensing device 170 until the fuel is supplied to the engine 110 for combustion. In some instances, the control system 190 can receive an indication of the level of fuel stored in the fuel tank 144 via a fuel level sensor. The level of fuel stored in the fuel tank 144 (e.g., identified by the fuel level sensor) can be communicated to the vehicle operator (e.g., via a fuel gauge or indicator in the vehicle instrument panel (e.g., message center) 196).

[0032] The vehicle system 100 can also include an ambient temperature / humidity sensor 198 and a roll stability control sensor (e.g., lateral and / or longitudinal and / or yaw rate sensors 199). The vehicle instrument panel 196 can include indicator lights and / or a text-based display in which messages are displayed to the operator. The vehicle instrument panel 196 can also include various input devices for receiving operator input, such as buttons, touchscreens, voice input / recognition, etc. For example, the vehicle instrument panel 196 can include a refuel button 197 that the vehicle operator can manually activate or press to initiate refueling.

[0033] The control system 190 may be communicatively coupled to other vehicles or infrastructure using appropriate communication technologies. For example, the control system 190 may be coupled to other vehicles or infrastructure via a wireless network 131, which may include Wi-Fi, Bluetooth, cellular service types, wireless data transfer protocols, and the like. The control system 190 may broadcast (and receive) information regarding vehicle data, vehicle diagnostics, traffic conditions, vehicle location information, vehicle operating procedures, etc. via vehicle-to-vehicle (V2V), vehicle-to-infrastructure-to-vehicle (V2I2V), and / or vehicle-to-infrastructure (V2I or V2X) technologies. The information exchanged between vehicles may be transmitted directly between vehicles or may be multi-hop. In some instances, longer range communication (e.g., WiMax) may be used to replace or in conjunction with V2V or V2I2V to extend the coverage area for several miles. In other instances, the vehicle control system 190 may be communicatively coupled to other vehicles or infrastructure via the wireless network 131 and the Internet (e.g., cloud).

[0034] The vehicle system 100 may also include an on-board navigation system 132 (e.g., Global Positioning System, GPS) with which the vehicle's operator may interact. The navigation system 132 may include one or more position sensors for assisting in estimating vehicle speed, vehicle altitude, vehicle location / position, etc. This information may additionally be used to infer engine operating parameters such as local barometric pressure. As discussed above, the control system 190 may further be configured to receive information via the Internet or other communication networks. The information received from the GPS may be cross-referenced with information available via the Internet to determine local weather conditions, local vehicle regulations, etc.

[0035] Next, Figure 2 Exemplary aspects of an engine system 208 including an engine 110 that may be coupled in a vehicle 100 are schematically illustrated. Refer to Figure 2 described with reference to Figure 1 Components having the same identification markings as the components described with reference to

[0036] The engine 110 is shown as having a plurality of cylinders 230. The engine 110 may include an engine intake system 223 and an engine exhaust system 225. The engine intake system 223 may include an intake throttle 262 fluidly coupled to an intake manifold 244 via an intake passage 242. Intake air may be delivered to the intake throttle 262 after passing through an air filter 252 coupled to the intake passage 242 upstream of the intake throttle 262. The engine exhaust system 225 includes an exhaust manifold 248 leading to an exhaust passage 235 that conveys exhaust to the atmosphere. The engine exhaust system 225 may include one or more emission control devices 270 mounted in a close-coupled position. The one or more emission control devices may include a three-way catalyst, a lean NOx trap, a selective catalytic reduction (SCR) catalyst, a particulate filter (e.g., a diesel particulate filter or a gasoline particulate filter), an oxidation catalyst, etc. As an example, one or more NOx sensors may be positioned upstream and / or downstream of the emission control device 270, for example, to measure the NOx conversion efficiency of the emission control device 270. It will be appreciated that other components may be included in the engine, such as various valves and sensors further described herein. In some embodiments in which the engine system 208 is a boosted engine system, the engine system may further include a boosting device, such as a turbocharger (not shown).

[0037] The engine system 208 is coupled to a fuel system 140 and an evaporative emission system 219. The fuel system 140 includes a fuel tank 144 coupled to a fuel pump 234 that supplies fuel to the engine 110 of the propulsion vehicle 100, as described above with respect to Figure 1 that described. The evaporative emission system 219 includes a fuel vapor storage canister 222. During a fuel tank refueling event, fuel may be pumped into the vehicle from an external source through a refueling port 284. A fuel level sensor 282 located in the fuel tank 144 may provide an indication of the fuel level (“fuel level input”) to a control module 302 of the control system 190. As depicted, the fuel level sensor 282 may include a float connected to a variable resistor. Alternatively, other types of fuel level sensors may be used.

[0038] The fuel pump 234 is configured to deliver pressurized fuel to a fuel injector of the engine 110, such as the exemplary fuel injector 266. One or more fuel injectors may be provided for each cylinder. For example, pressurized fuel may be delivered to the fuel injector 266 and additional fuel injectors via a fuel rail 267. It will be appreciated that the fuel system 140 may be a returnless fuel system, a return fuel system, or various other types of fuel systems. Vapors generated in the fuel tank 144 may be transported via a conduit 231 to the fuel vapor storage canister 222 for storage, and thereafter the fuel vapor may be drawn into the engine intake system 223.

[0039] The fuel vapor storage canister 222 is loaded with a suitable adsorbent 280 for temporarily trapping fuel vapors (including vaporized hydrocarbons), diurnal vapors, and / or running loss vapors generated during fuel tank refueling operations. In one example, the adsorbent 280 is activated carbon (e.g., carbon). Although a single fuel vapor storage canister 222 is shown, it will be appreciated that the fuel system 140 and the evaporative emissions system 219 may include any number of fuel vapor storage canisters. When a draw condition is met, such as when the fuel vapor storage canister is saturated, the vapors stored in the fuel vapor storage canister 222 may be drawn into the engine intake system 223 via a draw line 228 by opening a canister purge valve (CPV) 212, which may be a normally closed valve. In some examples, the canister purge valve 212 may be a solenoid valve, and the opening or closing of the valve is performed by actuating a canister purge solenoid.

[0040] The fuel vapor storage canister 222 may include a buffer 222a (or buffer zone), and each of the fuel vapor storage canister and the buffer includes an adsorbent. For example, the buffer 222a is shown stuffed with an adsorbent 280a. As shown, the volume of the buffer 222a may be less than the volume of the fuel vapor storage canister 222 (e.g., a fraction of the volume of the fuel vapor storage canister). The adsorbent 280a in the buffer 222a may be the same as or different from the adsorbent 280 in the fuel vapor storage canister (e.g., both may include charcoal). The buffer 222a may be positioned within the fuel vapor storage canister 222 such that during fuel vapor storage canister loading, fuel tank vapors are first absorbed within the buffer, and subsequently, when the buffer is saturated, other fuel tank vapors are absorbed within the fuel vapor storage canister. In contrast, during fuel vapor storage canister draw, fuel vapors are first desorbed from the fuel vapor storage canister (e.g., to a threshold amount), and then from the buffer. In other words, the loading and unloading of the buffer do not coincide with the loading and unloading of the fuel vapor storage canister. Thus, the effect of the fuel vapor storage canister buffer is to inhibit any fuel vapor peaks from flowing from the fuel tank to the fuel vapor storage canister, thereby reducing the likelihood of any fuel vapor peaks reaching the engine.

[0041] The fuel vapor storage canister 222 includes a vent 227 for transporting gas from the fuel vapor storage canister 222 to the atmosphere when storing fuel vapor from the fuel tank 144. When the stored fuel vapor is withdrawn into the engine intake passage 223 via the withdrawal line 228 and the canister withdrawal valve 212, the vent 227 can also allow fresh air to be drawn into the fuel vapor storage canister 222. Although this example shows a vent 227 in communication with fresh unheated air, various modifications can also be used. The vent 227 can include a canister vent valve (CVV) 214 to regulate the flow of air and vapor between the fuel vapor storage canister 222 and the atmosphere. When a vent valve is included, the vent valve can be a normally open valve such that air that has been stripped of fuel vapor after passing through the fuel vapor storage canister can be pushed out to the atmosphere (e.g., during refueling when the engine is off). Similarly, during a withdrawal operation (e.g., during fuel vapor storage canister regeneration and when the engine is running), the fuel vapor storage canister vent valve can be opened to allow a fresh air stream to remove the fuel vapor stored in the fuel vapor storage canister. In some examples, the canister vent valve 214 can be a solenoid valve, where the opening or closing of the valve is performed by actuating the canister vent solenoid. Specifically, the canister vent valve can be in an open position that closes when the canister vent solenoid is actuated.

[0042] The evaporative emission system 219 can also include a bleed air fuel vapor storage canister 211. Hydrocarbons desorbed from the fuel vapor storage canister 222 (also referred to hereinafter as the “main fuel vapor storage canister”) can be absorbed within the bleed air fuel vapor storage canister. The bleed air fuel vapor storage canister 211 can include an adsorbent 280b that is different from the adsorbent material included in the main fuel vapor storage canister 222. Alternatively, the adsorbent 280b in the bleed air fuel vapor storage canister 211 can be the same as the adsorbent 280 included in the main fuel vapor storage canister 222.

[0043] A hydrocarbon (HC) sensor 213 can be present in the evaporative emission system 219 to indicate the concentration of hydrocarbons in the vent 227. As illustrated, the hydrocarbon sensor 213 is positioned between the main fuel vapor storage canister 222 and the bleed air fuel vapor storage canister 211. The probe (e.g., sensing element) of the hydrocarbon sensor 213 is exposed to the fluid flow in the vent 227 and senses the hydrocarbon concentration of the fluid flow. In one example, the engine control system 190 can use the hydrocarbon sensor 213 to determine the passage of hydrocarbon vapor from the main fuel vapor storage canister 222.

[0044] One or more temperature sensors 215 may be coupled to and / or within the fuel vapor storage canister 222. When fuel vapor is absorbed by the adsorbent in the fuel vapor storage canister, heat (heat of absorption) is generated. Similarly, when fuel vapor is desorbed by the adsorbent in the fuel vapor storage canister, heat is consumed. In this manner, absorption and desorption of fuel vapor by the fuel vapor storage canister can be monitored and estimated based on temperature changes within the fuel vapor storage canister.

[0045] Since vehicle 100 is powered by engine system 208 during some conditions and by energy storage device 150 (shown in Figure 1 ), or since the engine is off when the vehicle is started and stationary (e.g., when vehicle 100 is a stop / start vehicle), the vehicle may have reduced engine operation time. While reduced engine operation time reduces the vehicle's total carbon emissions, it may also result in insufficient draw of fuel vapor from the evaporative emission system 219. To at least partially address this issue, a fuel tank isolation valve (FTIV) 236 may optionally be included in conduit 231 such that fuel tank 144 is coupled to fuel vapor storage canister 222 via the valve. During normal engine operation, FTIV 236 may remain closed to limit the amount of diurnal or "running loss" vapor directed from fuel tank 144 to fuel vapor storage canister 222. During refueling operations and selected draw conditions, FTIV 236 may be temporarily opened for a duration to direct fuel vapor from fuel tank 144 to fuel vapor storage canister 222. While the depicted example shows FTIV 236 positioned along conduit 231, in alternative embodiments, the isolation valve may be mounted on fuel tank 144.

[0046] One or more pressure sensors may be coupled to fuel system 140 and evaporative emission system 219, respectively, for providing estimates of fuel system pressure and evaporative emission system pressure. In Figure 2In the example described, the first pressure sensor 217 is directly coupled to the fuel tank 144, and the second pressure sensor 238 is coupled to the conduit 231 between the FTIV 236 and the fuel vapor storage canister 222. For example, the first pressure sensor 217 can be a fuel tank pressure transducer (FTPT) coupled to the fuel tank 144 for measuring the pressure of the fuel system 140, and the second pressure sensor 238 can measure the pressure of the evaporative emission system 219. In an alternative embodiment, the first pressure sensor 217 can be coupled between the fuel tank 144 and the fuel vapor storage canister 222, specifically between the fuel tank and the FTIV 236. In other embodiments, such as when the FTIV 236 is opened or omitted, a single pressure sensor can be included for measuring the fuel system pressure and the evaporative system pressure. In some instances, the control system 190 can infer and indicate unwanted evaporative emissions (e.g., unwanted hydrocarbon emissions) based on changes in the evaporative emission system pressure during an emission test, such as the emission test can be performed during a post-vehicle operation period, as further described below with respect to Figures 3 to 6 Further description.

[0047] One or more temperature sensors 221 can also be coupled to the fuel system 140 to provide an estimate of the fuel system temperature. In one example, the fuel system temperature is the fuel tank temperature, where the temperature sensor 221 is a fuel tank temperature sensor coupled to the fuel tank 144. Although the depicted example shows the temperature sensor 221 directly coupled to the fuel tank 144, in an alternative embodiment, the temperature sensor can be coupled between the fuel tank and the fuel vapor storage canister 222.

[0048] The control system 190 is shown as receiving information from a plurality of sensors 16 (various examples of the plurality of sensors are described herein) and sending control signals to a plurality of actuators 81 (various examples of the plurality of actuators are described herein). As an example, the sensors 16 may include an exhaust gas sensor 226 located upstream of the emission control device 270, a temperature sensor 232 coupled to the exhaust passage 235, a manifold absolute pressure (MAP) sensor 240 coupled to the intake manifold 244, an engine coolant temperature sensor 216 coupled to the engine coolant jacket of the engine 110, an FTPT 217, a second pressure sensor 238, a hydrocarbon sensor 213, a temperature sensor 221, and a pressure sensor 229 located downstream of the emission control device 270. Other sensors, such as additional pressure sensors, temperature sensors, air / fuel ratio sensors, and component sensors, may be coupled to various locations in the vehicle 100. For example, the control module 302 may obtain an estimate of the MAP or manifold vacuum (ManVac) from the MAP sensor 240. Alternatively, the MAP may be inferred from alternative engine operating conditions such as the mass air flow (MAF) measured by a MAF sensor (not shown) coupled to the intake manifold 244. As another example, the actuators 81 may include fuel injectors 266, FTIVs 236, purge valves 212, vent valves 214, fuel pumps 234, and throttles 262.

[0049] As described above with reference to Figure 1 what has been described, the control system 190 may further receive information about the location of the vehicle from an on-board GPS. The information received from the GPS may include vehicle speed, vehicle altitude, vehicle location, etc. This information may be used to infer engine operating parameters such as local barometric pressure. The control system 190 may further be configured to transmit or receive information via the Internet or other communication networks. The information received from the GPS may be cross-referenced with information available via the Internet to determine local weather conditions, local vehicle regulations, etc. The control system 190 may use the Internet to obtain updated software modules, which may be stored in non-transitory memory.

[0050] The control module 302 of the control system 190 may be configured as a conventional microcomputer, which includes a microprocessor unit, input / output ports, read-only memory, random access memory, keep-alive memory, a CAN bus, etc. The control module 302 may be configured as a powertrain control module (PCM), for example. The control module 302 may receive input data from various sensors, process the input data, and trigger the actuators in response to the processed input data based on instructions or codes corresponding to one or more routines programmed therein. In this regard Figure 5 andFigure 6 Describe an exemplary control routine.

[0051] In some instances, the control module 302 can be placed in a power reduction mode or a sleep mode, where the control module maintains only necessary functions and operates with lower battery consumption than in the corresponding wake mode. For example, the control module can be placed in the sleep mode after a vehicle cut-off event (e.g., a human driver removes the key from the vehicle, the key fob is outside the proximity of the vehicle, and / or otherwise commands the vehicle to be in an off / non-operating state, at which time the engine can be stopped from rotating and the electric propulsion device (if present) can be deactivated) in order to execute a diagnostic routine for a certain duration after the vehicle cut-off event, as further described with respect to Figure 5 and Figure 6 will be further described. The control module can have a wake-up input that allows the control module to return to the wake mode based on inputs received from one or more sensors. For example, opening the vehicle door can trigger a return to the wake mode. In other instances, the control module can be woken up to perform one or more post-run tasks, including diagnostic and non-diagnostic features. In this instance, the request feature of the control module can set a timer via an alarm wake-up system after the vehicle cut-off event and before the control module enters the sleep mode, such that the control module can be woken up before the vehicle is turned on to perform one or more post-run tasks, as further described herein. For example, when the timer expires, the circuit can wake up the control module to operate in the alarm wake-up mode. As a non-limiting example of a diagnostic feature that can be performed as a post-run task, the control module 302 can be configured to intermittently perform an evaporative emissions system diagnostic routine at vehicle shutdown to determine the presence or absence of unwanted evaporative emissions in the evaporative emissions system and / or the fuel system.

[0052] Next, Figure 3 illustrates a block diagram of a first instance of an alarm wake-up system 300 that can be included in a vehicle (e.g., Figure 1 and Figure 2 vehicle 100). The alarm wake-up system 300 includes, for example, a control module 302 that communicates with a body control module (BCM) 304 on a controller area network (CAN) 305, and the control module can be a powertrain control module (PCM), an engine control module (ECM), a transmission control module (TCM), etc. The control module 302 also includes a request feature 306, other features 308, a start / stop controller 310, a wake-up manager (WAKEM) 312, and an interface 314.

[0053] The request feature 306 includes software features, such as executable instructions stored in the memory of the control module, which may request a future wake-up time to perform their functions (e.g., by generating a request based on current vehicle conditions and input conditions and then sending the request to WAKEM 312). The request feature may include both diagnostic and non-diagnostic features. For example, diagnostic request features may include (but are not limited to) evaporative emission system diagnostics and / or NOx sensor diagnostic tests, as will be Figure 6 further described. In another example, non-diagnostic request features may include (but are not limited to) a low voltage set point manager for battery charging, a vehicle-to-vehicle communication module, and a vehicle-to-infrastructure communication module. The diagnostic request feature may be a feature that includes instructions stored in the memory for performing diagnostic operations of the vehicle and components of the vehicle for performing the diagnostic operations according to the instructions (e.g., sensors and actuators, such as the sensors and actuators Figure 1 and Figure 2 described). The feature may include instructions for performing the following operations: reading sensor values, determining parameters related to the sensor values, and generating a diagnostic indication and / or setting a diagnostic code stored in the memory based on the determination. As an example of the evaporative emission system diagnostics, which is a diagnostic request feature, the evaporative emission system diagnostics may include instructions stored in the memory for performing the following operations: determining the current engine coolant temperature (e.g., measured by an engine coolant temperature sensor); determining the desired engine coolant temperature based on the current engine coolant temperature; generating an alarm wake-up request based on the current engine coolant temperature and the desired engine coolant temperature; and sending the generated alarm wake-up request to WAKEM, as will be Figure 5 further described.

[0054] Other features 308 include features that may not request future wake-up times. The start / stop controller 310 maintains the power relay of the control module 302, thereby allowing the control module 302 to maintain power independent of the ignition state of the vehicle (e.g., "on", where power is supplied to the vehicle in response to driver demand and torque can be supplied to propel the vehicle; or "off", where no power is supplied to the vehicle and the vehicle cannot be propelled by torque). Thus, the start / stop controller 310 controls the power-on and power-off of the control module 302 by switching the power relay of the control module 302 to the "on" position (where the power circuit is complete, enabling electrical energy to be supplied to the control module 302) or the "off" position (where the power circuit is interrupted, preventing electrical energy from being supplied to the control module 302), respectively. The start / stop controller 310 can be a controller start / stop (CTSS) feature that includes instructions stored in a memory for (e.g.) managing the start-up and shut-down processes of the control module 302. WAKEM 312 arbitrates and schedules alarm wake-up requests from the requesting features, as will be further described below with respect to Figure 5 In an example of the alarm wake-up system 300, the alarm wake-up time determined by WAKEM 312 is set on the timer of the BCM 304. The control module 302 can communicate with the BCM 304 on the CAN 305 via the interface 314.

[0055] As Figure 3 shown, the requesting feature 306 communicates bidirectionally with the start / stop controller 310 and WAKEM 312. That is, the requesting feature 306 sends signals to the start / stop controller 310 and WAKEM 312 and receives signals from the start / stop controller 310 and WAKEM 312. In contrast, the other features 308 only send signals to the start / stop controller 310 and do not receive signals from the start / stop controller 310 at least within the alarm wake-up system 300. Additionally, the other features 308 do not communicate with WAKEM 312. WAKEM 312 also sends signals to the start / stop controller 310 and the interface 314 and receives signals from the start / stop controller 310 and the interface 314. The interface 314 sends signals to the start / stop controller 310 but does not receive signals from the start / stop controller 310 at least within the alarm wake-up system 300 (e.g., the start / stop controller 310 can send signals to the interface 314 in other systems). As mentioned above, the interface 314 (and thus the control module 302) communicates bidirectionally with the BCM 304 on the CAN 305. The specific signals transmitted and received within the alarm wake-up system 300 will be described with respect to Figure 5 and Figure 6 Specific signals transmitted and received within the alarm wake-up system 300 will be described with respect to

[0056] Next, Figure 4 A block diagram showing a second instance of the alarm wake-up system 400. Figure 3 and Figure 4 Components with the same numbers are functionally equivalent and may not be reintroduced. The alarm wake-up system 400 differs from the alarm wake-up system 300 in that the control module 302 includes a timer chip 316, and thus the alarm wake-up time determined by WAKEM 312 is set on the timer chip 316. Since the timer chip 316 is inside the PCM, the interface 314, BCM 304, and CAN 305 are not included in the alarm wake-up system 400. Therefore, WAKEM 312 communicates directly with the timer chip 316, sending and receiving signals, and the timer chip 316 sends the signals to the start / stop controller 310. As for Figure 3 the alarm wake-up system 300 of Figure 5 and Figure 6 the specific signals sent and received within the alarm wake-up system 400 will be described below with respect to

[0057] Turning first to Figure 5 , an exemplary method 500 for requesting, arbitrating, and scheduling control module alarm wake-up during a vehicle-off period is shown. The exemplary vehicle system of Figures 1 to 2 and Figure 3 and Figure 4 the exemplary alarm wake-up system of Figure 3 and Figure 4 will be used to describe method 500, but it should be understood that other systems may be used without departing from the scope of the present disclosure. For example, the request feature of the control module (e.g., Figures 1 to 4 the request feature 306 of the control module 302 of Figures 1 to 2 ) can request an alarm wake-up during a vehicle-off period in order to perform post-run tasks for a certain duration after the vehicle is turned off. The instructions for implementing method 500 and the remainder of the methods included herein can be executed by a control system (e.g.,

[0058] the control system 190 of Figures 1 to 2 ) based on instructions stored on one or more memories of the control system and in combination with signals received from sensors of the vehicle system, such as the sensors described above with reference to Figures 1 to 2 . The control system can adjust the operation of the vehicle system using actuators of the vehicle system according to the methods described below.Method 500 begins at 502 and includes determining whether to initiate a shutdown. For example, a shutdown may be initiated in response to the vehicle ignition switch moving to the off position. Moving the vehicle ignition switch to the off position (which may be referred to herein as a cutoff event) may initiate a cutoff period that continues until the vehicle ignition switch is moved to the on position. In another example, a shutdown may be initiated in response to the completion of an alarm wake-up during the cutoff period (and thus, not initiated by the cutoff event itself), as further described herein.

[0059] If the shutdown is not initiated, then method 500 proceeds to 504 and includes maintaining current operating parameters. For example, if the ignition switch is in the on position, the vehicle will remain on, with power supplied to each control module of the vehicle's control system. As another example, if operating in an alarm mode after an alarm wake-up, the control module may continue to operate in the alarm mode. After 504, method 500 ends.

[0060] If the shutdown is initiated, then method 500 proceeds to 506 and includes maintaining control module power and performing post-run tasks. For example, a start / stop controller (e.g., Figure 3 and Figure 4 the start / stop controller 310) may cause the power relay of the control module to be maintained in the "on" position, thereby enabling power (e.g., electrical energy) to be supplied from the vehicle's energy storage device (e.g., Figure 1 the energy storage device 150) to the control module. Additionally, once the shutdown is initiated, CAN (e.g., Figure 3 the CAN 305) may be switched to a listen mode so that other control modules that are not performing post-run tasks can be kept off (or turned off after completing their post-run tasks). Since there is no transmission on the CAN, less electrical energy may be consumed. Post-run tasks may include (e.g.) performing diagnostics, uploading vehicle data to the cloud, and downloading control strategies and calibrations from the cloud. These post-run tasks may be performed by features of the control module (e.g., Figure 3 and Figure 4 the other features 308). However, other post-run tasks may be performed for a certain duration after the vehicle cutoff event when conditions may be more favorable, as will be further described below. These other post-run tasks may be performed at a later time during the vehicle cutoff period by the request feature of the control module that is approved to request an alarm wake-up.

[0061] At 508, it is determined whether the post-run task is complete. When complete, each feature can (e.g.) set a "run_done" flag at the start / stop controller to indicate completion. The requested feature can also set the "run_done" flag at the start / stop controller if the requested feature has not yet performed its task, such that the requested feature can use a callback function to request an alarm wake-up, as will be further described below. In some instances, e.g., when operating in an alarm wake-up mode, the "run_done" flag can be kept set for another (non-requested) feature after wake-up. Thus, during the alarm wake-up mode, only the "run_done" flag of the requested feature can be considered. Once the start / stop controller has received the "run_done" flag from each feature (requested feature and other features), the start / stop controller can determine that the post-run task is complete. If not, then method 500 proceeds to 510 and includes continuing to execute the post-run task. In this way, the control module will not be shut down while the post-run task is being executed (e.g., the start / stop controller will maintain the power relay of the control module), thus allowing the post-run task to be completed.

[0062] Once the post-run task is complete (e.g., the start / stop controller receives the "run_done" flag from each feature), method 500 proceeds to 512 and includes signaling the Wake-up Manager (WAKEM) to ask the requested feature for the alarm wake-up time. The WAKEM (e.g., Figure 3 and Figure 4 the WAKEM 312) can ask the requested feature without asking other (non-requested) features, because the WAKEM may not be configured to transmit signals to or receive signals from other features. For example, in the case of receiving the "run_done" flag from each feature, the start / stop controller can transmit a signal to the WAKEM informing the WAKEM that all post-run tasks are complete and that the control module is ready to be shut down. In response to receiving the signal from the start / stop controller, the WAKEM can transmit a signal asking for the alarm wake-up time (in minutes) to the requested feature. For example, the WAKEM can signal the callback function of each requested feature such that each requested feature can determine whether to request an alarm wake-up (and the alarm wake-up time of the requested alarm wake-up), rather than the WAKEM itself storing instructions for determining whether to request an alarm wake-up for each requested feature. Additionally, because the alarm wake-up can be scheduled after start-off, the WAKEM can be inactive when the vehicle is on, but can be activated in response to receiving a signal from the start / stop controller.

[0063] At 513, method 500 includes determining an alarm wake-up time at each request feature based on current vehicle conditions and input conditions of the request features. For example, each request feature can input the current vehicle conditions into one or more look-up tables, algorithms, and / or maps that can take into account the input conditions of the request feature and output a zero or a non-zero alarm wake-up time greater than a minimum alarm wake-up time. The minimum alarm wake-up time can be a calibrated amount of time, such as 10 minutes, below which it may be more beneficial to keep the control module powered on and execute the feature (e.g., by removing its "run_done" flag from the start / stop controller) rather than power off the control module and wake up the control module again.

[0064] As an example, for instance when it is not indicated to execute a first request feature (e.g., based on the schedule of the first request feature, current vehicle conditions, expected vehicle conditions during a cut-off period, input conditions of the first request feature, etc.) during a vehicle cut-off period, the first request feature can determine not to request an alarm wake-up. Thus, the first request feature can determine an alarm wake-up time of zero. For example, the first request feature can determine not to request an alarm wake-up when the state of charge of the energy storage device is less than a threshold state of charge. The threshold state of charge can be a non-zero amount of charge, such as a percentage of the total charge capacity, below which the energy storage device may not be able to support or execute the request feature after waking up the control module in alarm mode. Thus, the threshold state of charge can be used as an input condition of the first request feature that is not satisfied when the state of charge is less than the threshold state of charge.

[0065] As another example, a second request feature can use an algorithm to determine a non-zero alarm wake-up time. For example, the second request feature can input the current ambient temperature, the current engine coolant temperature, and a desired engine coolant temperature (which can be, for example, an input condition of the second request feature) into the algorithm. The current ambient temperature can refer to the ambient temperature measured by an ambient temperature sensor (e.g., Figure 1 the ambient temperature / humidity sensor 198) at start-off (e.g., at 502). Similarly, the current engine coolant temperature can refer to the temperature at start-off and can be measured by an engine coolant temperature sensor (e.g., Figure 2The engine coolant temperature measured by the engine coolant temperature sensor 216). For example, the desired engine coolant temperature may be within a threshold of the ambient temperature. The threshold may be a non-zero temperature difference, such as 10 degrees. Thus, the second request feature may determine the desired engine coolant temperature based on the current ambient temperature and the threshold. The algorithm may use a temperature decay function, such as an exponential decay function, to determine the expected amount of time for the engine coolant temperature to reach the desired engine coolant temperature, and the expected amount of time may be output as an alarm wake-up time. For example, the exponential decay function may be: ECT desired = a × e (t / tc) , where ECT desired is the desired engine coolant temperature, a is the difference between the current engine coolant temperature and the current ambient coolant temperature, e is the mathematical constant representing the exponential function, t is time, and tc is the time constant determined by an empirical cooling curve and stored in the memory of the control module (e.g., stored in a lookup table). Additionally, in some instances, such as when the second request feature is an evaporative emissions system diagnosis, the exponential decay function may be multiplied by a fuel level normalizer (FLI): ECT desired = a × e (t / tc) × FLI. The fuel level normalizer takes into account the effect of the fuel level on the cooling rate of the fuel, as more fuel (e.g., a higher fuel level) cools more slowly than less fuel (e.g., a lower fuel level). For example, an evaporative emissions system diagnosis may input the current fuel level (e.g., measured by a fuel level sensor (e.g., Figure 2 the fuel level sensor 282)) into a lookup table and output the corresponding fuel level normalizer. Once a non-zero alarm wake-up time is determined, each request feature may transmit its alarm wake-up time to WAKEM.

[0066] At 514, it is determined whether at least one non-zero alarm wake-up time is received at WAKEM. For example, when each request feature determines and transmits a zero alarm wake-up time, if at least one non-zero alarm wake-up time is not received, then method 500 proceeds to 530 and includes shutting down the control module. For example, WAKEM will not set a timer to wake up the control module and will transmit a signal indicating that it has completed its task (e.g., by setting a "run_done" flag) to the start / stop controller. In response to receiving the signal from WAKEM, the start / stop controller may switch the power relay of the control module to the "off" position, such that power (e.g., electrical energy) is not supplied to the control module via the power relay and the control module enters a sleep mode. After 530, method 500 ends.

[0067] If at least one non-zero alarm wake-up time is received at WAKEM, then method 500 proceeds to 516 and includes determining whether the number of alarm wake-ups performed during the cut-off period is equal to a threshold. For example, shutdown may be initiated after waking up in alarm mode (e.g., at 502), as will be further described with respect to Figure 6 Figure 6 . Thus, one or more alarm wake-ups may have been performed during the cut-off period. An alarm wake-up counter may be maintained in non-volatile memory (e.g., KAM) to keep track of (e.g.) the number of times the control module has been woken up due to an alarm wake-up during the cut-off period. The alarm wake-up counter may be incremented each time the controller is woken up due to an alarm wake-up during the cut-off period, and the alarm wake-up counter may be cleared (e.g., reset to zero) in response to an on event. The threshold may also be stored in non-volatile memory and may be a calibrated non-zero number of alarm wake-ups that may be tolerated during the cut-off period (e.g., each operating cycle). Since each alarm wake-up draws current from the energy storage device, alarm wake-ups above the threshold may result in excessive current consumption. Additionally, in some instances, the energy storage device may not be charged during the cut-off period, which may last for a relatively short duration (e.g., several hours) or a relatively long duration (e.g., several weeks). If the cut-off period lasts for a relatively long duration and the number of alarm wake-ups is not limited to the threshold, then (e.g.) the charge state of the energy storage device may not be able to sustain the starting operation of the vehicle after an on event. Thus, the threshold may reduce the number of alarm wake-ups in order to limit the amount of current consumed between on events. In a non-limiting example, the threshold may be three alarm wake-ups per cut-off period.

[0068] If the number of alarm wake-ups performed during the cut-off period is not equal to the threshold (e.g., the number of alarm wake-ups is less than the threshold), then method 500 proceeds to 518 and includes selecting an alarm wake-up time at WAKEM. For example, WAKEM may compare each of the non-zero alarm wake-up times received from one or more requested features to determine which alarm wake-up to select based on a common characteristic of the received alarm wake-up times. For example, the common characteristic may be time, such as the amount of time before the requested alarm wake-up (e.g., shortest or longest), absolute time, relative time, the duration of the requested alarm wake-up (e.g., a request for a 5-minute wake-up event), or the time of day of the requested alarm wake-up. As an example, WAKEM may select the shortest (e.g., earliest) alarm wake-up time (e.g., in minutes).

[0069] At 520, method 500 includes transmitting a selected alarm wake-up time to a timer and storing the current Global Real Time (GRT). In one example, the timer is an internal timer chip of a control module, such as shown in Figure 4 the alarm wake-up system 400. WAKEM can directly transmit the selected alarm wake-up time to the internal timer chip. In another example, the timer is included in the BCM, such as shown in Figure 3 the alarm wake-up system 300. WAKEM can transmit the selected alarm wake-up time to an interface of the control module (e.g., Figure 3 interface 314), which can then transmit the selected alarm wake-up time on the CAN to the BCM. Upon receiving the selected alarm wake-up time, the timer can be set for the selected alarm wake-up time and the timer can start counting down (or start counting up from zero to the selected alarm wake-up time), such that the start of the countdown occurs at the stored GRT. For example, the stored GRT can be stored in a non-volatile memory of the control module, and the stored GRT can be used for alarm wake-up system diagnostics after wake-up, as described with respect to Figure 6 . Additionally, the timer can be a "always-on" component that remains operational regardless of the power-on or power-off state of the control module.

[0070] At 522, it is determined whether the timer is set. For example, determining whether the timer is set can include determining whether WAKEM has received an acknowledgement of the selected alarm wake-up time from the timer. If the timer is an internal timer chip, once the timer receives the selected alarm wake-up time and is set, the timer can directly transmit an acknowledgement of the selected alarm wake-up time to WAKEM, for example, by echoing the selected alarm wake-up time. If the timer is included in the BCM, the interface can read the BCM timer status on the CAN and transmit the BCM timer status to WAKEM as an acknowledgement.

[0071] If WAKEM does not receive confirmation of the selected alarm wake-up time from the timer, it can be determined that the timer is not set, and method 500 proceeds to 524. At 524, method 500 includes warning that the requested feature has not scheduled an alarm wake-up. Each of the requested features that have requested a non-zero alarm wake-up time can then decide whether to execute the feature, as indicated at 526. For example, each of the requested features can clear its "run_done" flag at the start / stop controller to prevent the control module from being turned off when the control module determines whether to execute the feature, such as by requesting a post-run latch at the start / stop controller to keep the control module power relay circuit closed, thereby maintaining power to the control module. Determining whether to execute the feature can include, for example, determining whether the input conditions of the feature are met by comparing the current vehicle conditions with the input conditions. While the start / stop controller maintains power to the control module, each of the requested features can continue to compare the current vehicle conditions with their input conditions. For example, when the requested feature is an evaporative emissions system diagnosis, the evaporative emissions system diagnosis can continue to compare the engine coolant temperature with the ambient temperature to determine whether the engine coolant temperature is within a threshold (as defined above at 513), while maintaining power to the control module via a post-run latch at the start / stop controller. The evaporative emissions system diagnosis can then be executed in response to the input conditions being met, such as with respect to Figure 6 which is further described in 634. Thus, executing the feature at 526 includes operating when the input conditions of the corresponding requested feature are met, the requested feature making a determination that the input conditions are met (e.g., based on sensor output), and executing the feature (e.g., based on signals sent to actuators of the vehicle).

[0072] If, for example, the requested feature determines not to perform the feature when the input conditions are not met, then the feature may optionally set a Diagnostic Trouble Code (DTC) indicating that the feature may not be performed, as indicated at 528. For example, when the battery charge state drops below a threshold charge state (e.g., as defined at 513), the requested feature may determine not to perform the feature while keeping the control module powered on and monitoring the current vehicle conditions relative to its input conditions. As an example, the requested feature may set the DTC each time it cannot perform (or complete) the feature. As another example, the requested feature may set the DTC after a calibratable number of attempts, in cases where the feature cannot be performed beyond the calibratable number of attempts. For example, each time the requested feature unsuccessfully attempts to perform the feature, the requested feature may increment a counter, and set the DTC once the counter reaches the calibratable number. The counter may be reset once the feature has been performed. After performing the feature, setting the diagnostic code or recording the attempt, each requested feature may reset its "run_done" flag at the start / stop controller to indicate completion. Method 500 may then proceed to 530 to turn off the control module, as described above.

[0073] Returning to 516, if the number of alarm wakes that have been performed during the cut-off period is equal to the threshold, then method 500 proceeds to 524 and includes warning that the requested feature has not scheduled an alarm wake, as described above. Thus, each requested feature may determine whether to perform its feature before turning off the control module and waking the control module without an alarm wake.

[0074] Returning to 522, if, for example, it is determined that the timer has been set by receiving confirmation of the selected alarm wake time from the timer via WAKEM, then method 500 proceeds to 532 and includes turning off the control module until the timer elapses. For example, as described at 530, the control module may be turned off and maintained in a sleep mode until the timer elapses. When the timer elapses (e.g., the timer counts down or up to zero), the control module may be woken in alarm mode, as will be described with respect to Figure 6 as described. After 532, method 500 ends.

[0075] Next, Figure 6 An exemplary method 600 is shown for waking a vehicle control module (e.g., Figures 2 to 4 control module 302) (e.g., PCM) of FIG. in alarm mode during a vehicle cut-off period in response to an alarm wake or in nominal mode in response to a non-alarm wake. For example, the vehicle control module may be configured with an alarm wake system (e.g., Figure 3the alarm wake-up system 300 or Figure 4 the alarm wake-up system 400) to set a timer to wake up the control module during a vehicle-off period to perform post-run tasks. As described with respect to Figure 5 one or more request features (e.g., Figure 3 and Figure 4 request feature 306) may request an alarm wake-up and schedule the alarm wake-up via WAKEM (e.g., Figure 3 and Figure 4 WAKEM 312). After waking up, the control module may perform a different set of actions based on whether it is an alarm wake-up or a non-alarm wake-up, as described below. Additionally, the control module may perform diagnostics to determine if the alarm wake-up system is operating nominally.

[0076] Method 600 begins at 602 and includes determining if there is an alarm wake-up. An alarm wake-up may exist if the control module is woken up in response to the expiration of a timer (e.g., by counting up or down to a set alarm wake-up time). The timer may be an internal timer chip of the control module, such as shown in Figure 4 the alarm wake-up system 400 (e.g., timer chip 316), or may be included in the BCM, such as shown in Figure 3 the alarm wake-up system 300 (e.g., BCM 304). For example, when the timer expires, a signal may be sent from the timer to the start / stop controller (e.g., Figure 3 and Figure 4 start / stop controller 310). The signal may also include a wake-up reason (e.g., alarm wake-up versus non-alarm wake-up). If the timer is an internal timer chip, the timer chip may communicate directly with the start / stop controller. If the timer is included in the BCM, the BCM may trigger a hard-wired wake-up line to the control module and transmit the wake-up reason on the CAN (e.g., Figure 3 CAN 305). An interface of the control module (e.g., Figure 3 interface 314) may receive the wake-up reason from the CAN, and the interface may then transmit the wake-up reason to the start / stop controller. When there is a non-alarm wake-up, e.g., when the control module is woken up by an input other than the expiration of the timer, there may be no alarm wake-up. For example, a non-alarm wake-up may be triggered by opening a vehicle door, pressing the brake pedal, or an on event (e.g., via insertion of the ignition key, remote key, pressing the remote start button, or the ignition switch being in any position other than "off"). The start / stop controller may transmit the wake-up reason to the request feature and / or wake-up manager.

[0077] If there is no alarm wake-up, then the control module can be operated in a nominal mode, and method 600 proceeds to 604 and includes determining whether an alarm wake-up has been lost. For example, if an alarm wake-up time was set (e.g., according to Figure 5 method 500), the timer elapsed, and the control module was not awakened in response to the timer elapsing, then it can be determined that the alarm wake-up has been lost, for example, based on the elapsed time at wake-up (e.g., the difference between the GRT at wake-up and the GRT stored when the timer was set, further described below at 620) and the set alarm wake-up time. For example, timer degradation may result in a lost alarm wake-up due to, for example, a timer reset or a too-slow downcount. As another example, if a higher-priority wake-up (e.g., due to a power-on event) is active when the timer elapses, then the alarm wake-up may be lost. As another example, if the timer is included in the BCM (e.g., as shown for Figure 3 alarm wake-up system 300), then the alarm wake-up may be lost due to a circuit fault on the hardwired wake-up line controlled by the BCM or a power loss to the BCM, which causes the timer to lose the ability to keep time of the elapsed time.

[0078] If the alarm wake-up has been lost, then method 600 proceeds to 605 and includes indicating that the alarm wake-up system has degraded. Indicating that the alarm wake-up system has degraded can include setting a corresponding diagnostic trouble code (DTC) in the memory of the control module. Indicating that the alarm wake-up system has degraded can also include illuminating a malfunction indicator lamp (MIL) on, for example, the vehicle's instrument panel (e.g., in Figure 1 vehicle instrument panel 196) to warn the vehicle operator to service the vehicle. Method 600 can then proceed to 608 and perform a nominal start-up procedure. The nominal start-up procedure can include filling the vehicle's fuel rail, as indicated at 610, and actuating the vehicle's valves to determine the end-stop positions, as indicated at 612. For example, filling the fuel rail (e.g., Figure 2 fuel rail 267) can include actuating a fuel pump (e.g., Figure 2 fuel pump 234) to deliver fuel from a fuel tank (e.g., Figure 1 and Figure 2 fuel tank 144) to the fuel rail until the fuel in the fuel rail is at or above a threshold pressure and air has been drawn from the fuel rail. Additionally, filling the fuel rail can include not actuating the fuel injectors (e.g., Figure 2The fuel injector 266) is such that fuel is not delivered to the engine cylinder. By filling the fuel rail, the fuel injector can be prepared to deliver pressurized fuel during a start operation of the engine. Actuating the valves of the vehicle to determine the end stop positions can include sending control signals to each valve to command each valve to be fully closed and / or fully open and receiving feedback regarding the position of each valve, for example, via corresponding position sensors. For example, the end stop positions of some valves can vary in response to temperature and other conditions. By determining the end stop positions during start-up, the valves can be more accurately controlled when driving the vehicle. For example, the throttle (e.g., Figure 2 the throttle 262) can be commanded to reach a first end stop position, such as a fully closed position, and the position is measured by the throttle position sensor. The control module can compare the measured first end stop position with the commanded position and, for example, adjust the gain of the throttle position sensor if the commanded position is different from the measured position (e.g., by a threshold). Subsequently, the process can be repeated for a second end stop position, such as a fully open position.

[0079] Returning to 604, if the alarm wake-up has not been lost, then method 600 proceeds to 606 and includes determining whether the alarm wake-up is scheduled. For example, if the alarm wake-up system has scheduled an alarm wake-up (e.g., according to Figure 5 method 500) and there is still a non-zero amount of time left on the timer, then it can be determined that the alarm wake-up is scheduled. If the alarm wake-up is scheduled, then method 600 proceeds to 607 and includes clearing the timer. By clearing the timer, the timer can be set for a new alarm wake-up time in response to one or more request features requesting a non-zero alarm wake-up time after subsequent control module shutdown. Method 600 proceeds to 608 and includes performing the nominal start-up procedure as described above.

[0080] Returning to 606, if the alarm wake-up is not scheduled, then method 600 proceeds to 608 and includes performing the nominal start-up procedure as described above. Thus, the nominal start-up procedure will be performed whenever the control module is awakened in response to a non-alarm wake-up, regardless of whether the alarm wake-up has been scheduled and / or lost. After 608, method 600 ends.

[0081] Return to 602. If there is an alarm wake-up, then, for example, in response to the expiration of a timer, the control module may operate in an alarm mode, and method 600 proceeds to 614 and includes performing an alarm mode startup routine. The alarm mode startup routine may include priming the fuel rail, as indicated at 616, and not actuating the valve to determine the end stop position, as indicated at 618. By priming the fuel rail, as described at 610, the vehicle may be ready for ignition if the ignition state of the vehicle changes while in the alarm mode. By not actuating the valve to determine the end stop position, energy is conserved if the ignition state of the vehicle does not change while in the alarm mode.

[0082] At 620, method 600 includes comparing the set alarm wake-up time with the difference between the GRT at wake-up and the GRT at the time the timer was set. For example, WAKEM may perform a timer accuracy check during each alarm wake-up by comparing the set alarm wake-up time (e.g., an amount of time in minutes) with the amount of time that has elapsed (e.g., a duration), which may be equal to the difference between the GRT at wake-up and the GRT stored at the time the timer was set (e.g., in minutes).

[0083] At 622, it is determined whether an alarm wake-up occurs at the set alarm wake-up time. For example, if the amount of time that has elapsed is within a threshold range centered on the set alarm wake-up time, it may be determined that an alarm wake-up has occurred at the set alarm wake-up time. The threshold range may be a non-zero amount of time corresponding to the tolerance limit of the timer. The tolerance limit may refer to the maximum amount of time by which the actual wake-up time (e.g., the amount of time that has elapsed) may differ (in the positive or negative direction) from the set alarm wake-up time and still be considered to have occurred as required. For example, the threshold range may be bounded by a first higher threshold set at an amount of time greater than the set alarm wake-up time and a second lower threshold set at an amount of time less than the set alarm wake-up time.

[0084] If the alarm wake-up does not occur at the set alarm wake-up time (e.g., the amount of time that has elapsed is not within the threshold range), then method 600 proceeds to 624 and includes indicating a timer degradation. In one instance, the timer may be counting down too fast, resulting in the amount of time that has elapsed being less than the second lower threshold. In another instance, the timer may be counting down too slow, resulting in the amount of time that has elapsed being greater than the first higher threshold. Indicating a timer degradation may include setting a corresponding DTC in the memory of the control module. Indicating a timer degradation may also include illuminating the MIL, for example, on the vehicle's instrument panel, to warn the vehicle operator to service the vehicle.

[0085] If an alarm wake-up occurs at the set alarm wake-up time (e.g., the amount of time elapsed is within a threshold range), then method 600 proceeds to 626 and includes indicating that the timer has passed. The indication that the timer has passed can be stored, for example, in the memory of the control module.

[0086] At 628, method 600 includes clearing the timer. For example, after performing a timer accuracy check, it may not be beneficial to save the timer value for the current alarm wake-up. By clearing the timer, the timer can be set for a new alarm wake-up time in response to one or more request features requesting a non-zero alarm wake-up time after the subsequent control module is turned off.

[0087] At 630, method 600 includes transmitting a run request to each of the request features. For example, the start / stop controller can transmit a run request to the request features when the start / stop controller transmits a wake-up reason (e.g., alarm wake-up). After receiving the run request, each request feature can start evaluating its input conditions. For example, each request feature among one or more request features can evaluate its input conditions independently of other request features and regardless of whether the requested alarm wake-up time is the set alarm wake-up time (e.g., selected by WAKEM at Figure 5 518). As described above, the request features can include diagnostic features and non-diagnostic features. As a first example, the input conditions for initiating an evaporative emission system diagnostic test for an engine shutdown can include an engine coolant temperature less than a threshold engine coolant temperature and a fuel tank pressure (e.g., measured by Figure 1 FTPT 217) less than a threshold pressure. For example, the threshold engine coolant temperature can be a non-zero temperature value indicating that the engine is not warm, and the threshold pressure can be a non-zero pressure value indicating that the fuel tank is substantially not pressurized. As a second example, the input conditions for a NOx sensor diagnostic test can include an exhaust gas temperature (e.g., measured by Figure 2 the exhaust gas temperature sensor 232) less than a threshold exhaust gas temperature and an oxygen concentration (e.g., measured by Figure 2 the exhaust gas sensor 226) within a threshold range. In some instances, the threshold exhaust gas temperature and the threshold range can be determined based on environmental conditions such that when the exhaust gas temperature is less than the threshold exhaust gas temperature and the oxygen concentration is within the threshold range, it can be determined that the vehicle's exhaust system (e.g., Figure 2The exhaust system 225) is under ambient conditions. The input conditions for the NOx sensor diagnostic test can also include that the ambient pressure is within a threshold pressure range and the ambient temperature is within a threshold temperature range. As a third example, the input conditions for a low voltage set point manager for maintaining the charge of a low voltage battery (e.g., a 12V battery) can include that the voltage of the low voltage battery is less than a threshold voltage. The threshold voltage can refer to a non-zero voltage value below which the low voltage battery may not be able to provide sufficient electrical energy to various vehicle loads (e.g., vehicle lights, vehicle heating and cooling systems). When the vehicle is a PHEV, the input conditions for the low voltage set point manager can also include that the vehicle is disconnected from an external power source for a threshold duration. The threshold duration can refer to a non-zero duration, for example, when the vehicle has not been operated (e.g., turned on) for a long time (e.g., several days or weeks).

[0088] At 632, it is determined whether the input conditions for a requested feature are satisfied. For example, each requested feature among one or more requested features can be independently determined whether its input conditions are satisfied by comparing the current vehicle conditions (e.g., measured by one or more sensors or inferred based on available data) with its input conditions.

[0089] If the input conditions for a requested feature are satisfied, then method 600 proceeds to 634 and includes executing the feature. As a first example, if the input conditions for an engine-off evaporative emission system diagnostic test are satisfied (e.g., the engine coolant temperature is less than a threshold engine coolant temperature and the fuel tank pressure is less than a threshold pressure), then the engine-off evaporative emission system diagnostic test can be executed. Executing the engine-off evaporative emission system diagnostic test can include commanding the canister purge valve to close (e.g., Figure 2The filter canister vent valve 214) seals the evaporative emission system and the fuel system and monitors the fuel tank pressure for a certain duration. As a second example, if the input conditions for the NOx sensor diagnostic test are met (e.g., the exhaust gas temperature is less than the threshold exhaust gas temperature and the oxygen concentration is within the threshold range), then the NOx sensor diagnostic test can be performed. The NOx sensor diagnostic test can include controlling the current / voltage within the NOx sensor; using the NOx sensor to measure NOx; and comparing the measured NOx with the stored reference value. The requested features can be performed in parallel (e.g., simultaneously) or serially (e.g., one after another). After each requested feature is performed, the requested feature can set its "run_done" flag at the start / stop controller to indicate that its task is complete. Additionally, although not explicitly stated, if a non-alarm wake-up occurs at any point while the control module is operating in alarm mode, then the control module can transition to nominal mode and execute the nominal startup procedure. If any of the requested features are performing their tasks at that time, they can determine whether to end their tasks or abort their tasks and reschedule based on the current vehicle conditions and their input conditions.

[0090] If the input conditions for the requested feature are not met, then method 600 proceeds to 636 and includes not performing the feature and continuing to monitor the input conditions. In one example, the requested feature can set its "run_done" flag at the start / stop controller while continuing to monitor its input conditions. In this way, the requested feature can continue to monitor its input conditions while other features are performing their tasks. By setting the "run_done" flag, the feature can avoid continuously monitoring the input conditions indefinitely, which would prevent the control module from being shut down again and depleting the vehicle's energy storage device, and there is no need to define a maximum duration for monitoring the input conditions.

[0091] At 638, it is determined whether the post-run task is complete. Each of one or more requested features may, for example, set a "run_done" flag at the start / stop controller to indicate completion, or may set the "run_done" flag while continuing to monitor input conditions, as described above. While operating in the alarm wake-up mode, only the "run_done" flag of the requested features may be considered, since the "run_done" flags of other (e.g., non-requested) features may be kept set or set immediately after waking up in the alarm mode. Additionally, after waking up, a requested feature that did not request a non-zero alarm wake-up time may immediately set its "run_done" flag at the start / stop controller. Once the start / stop controller has received the "run_done" flag from all requested features, it may determine that the post-run task is complete. If not, then method 600 returns to 632 and includes determining whether the input conditions of the requested features are met. In this way, the control module will not be shut down while the post-run task is being executed (e.g., the start / stop controller will maintain the power relay of the control module), thus allowing the post-run task to be completed.

[0092] If the post-run task is complete, then method 600 proceeds to 640 and includes signaling WAKEM to ask the requested features for a new alarm wake-up time, as described with respect to Figure 5 For example, in the case of receiving the "run_done" flag from each requested feature, the start / stop controller may transmit a signal to WAKEM informing WAKEM that all post-run tasks are complete and it is ready to shut down the control module. In response to receiving the signal from the start / stop controller, WAKEM may transmit a signal asking for the alarm wake-up time (in minutes) to the requested features. In this way, WAKEM may ask the requested features for alarm wake-up requests during each control module shutdown event. For example, a requested feature that does not meet the input conditions may request a new alarm wake-up time in order to perform its task when the conditions are better during the vehicle cut-off period. As an illustrative example, if a first requested feature has requested an alarm wake-up of 300 minutes and a second requested feature has requested an alarm wake-up of 90 minutes, then a timer may have been set for 90 minutes (e.g., at Figure 5 520 of method 500). When the control module wakes up after 90 minutes, the input conditions of the first requested feature may not be met (e.g., at 632). Therefore, the first requested feature may request a new alarm wake-up time. After 640, method 600 ends.

[0093] In this manner, the requested features can perform their respective tasks when their corresponding input conditions are met, thereby avoiding sub-optimal conditions and increasing system robustness. If the requested feature is a diagnostic routine, avoiding sub-optimal conditions can, for example, reduce the incidence of false fault detection.

[0094] Thus, in one example, the method can include determining an alarm wake-up and, in response to the alarm wake-up, performing an alarm mode startup procedure and sending a run request to the requested feature; and determining a non-alarm wake-up (which can be other than an alarm wake-up) and, in response to the non-alarm wake-up, performing a nominal startup procedure without sending a run request to the requested feature. By way of example, the nominal startup procedure includes filling the fuel rail of the vehicle's fuel system and determining the end-stop position of the valves of the vehicle, and the alarm mode startup procedure includes filling the fuel rail but not determining the end-stop position of the valves. In some examples, filling the fuel rail occurs during or at the time of the alarm mode startup procedure and during or at the time of the nominal startup procedure. Additionally, in some examples, determining the end-stop position of the valves occurs during or at the time of the nominal startup procedure and when there is no alarm wake-up. In some examples, sending a run request to the requested feature occurs during or at the time of the alarm mode startup procedure and / or when there is no non-alarm wake-up.

[0095] In addition, instructions stored in the memory of the control module can include determining an alarm wake-up in response to a timer expiration and triggering a wake-up line of the control module, and determining a non-alarm wake-up in response to a door half-open signal, a remote start signal, or an ignition switch signal. For example, instructions stored on the memory can include differentiating between the alarm wake-up and the non-alarm wake-up based on whether the timer has triggered the wake-up line of the control module, and in response to the differentiation, performing one or more of the following: filling a fuel rail, sending a run request to a requested feature, and actuating a valve to determine an end stop position. In response to the alarm wake-up or the non-alarm wake-up, the control module can fill the fuel rail by instructions for sending a signal to a fuel pump of the fuel system. In response to the alarm wake-up and not in response to the non-alarm wake-up, the control module can transmit a run request to the requested feature by instructions stored in the memory for sending a signal to each of the requested features. In response to the alarm wake-up and not in response to the non-alarm wake-up, the control module can determine a valve end stop position by instructions for sending a corresponding signal to a valve of the vehicle. For example, the control module can include instructions for the following operations: sending a signal to a throttle to actuate the throttle to a first end stop position; receiving a signal regarding the position of the throttle from a throttle position sensor when the throttle is in the first end stop position; actuating the throttle to a second end stop position; and receiving a signal regarding the position of the throttle from the throttle position sensor when the throttle is in the second end stop position. In some instances, the method can include determining whether to perform one or more of each of the following based on a determination of whether there is an alarm wake-up and a determination of whether there is a non-alarm wake-up: filling a fuel rail; determining an end stop position of a valve; and sending a run request to a requested feature. When any control module wakes up, there must be one of the alarm wake-up and the non-alarm wake-up.

[0096] As illustrated in the examples herein, the method for operating and performing an action in response to a determination of an alarm wakeup can include operating in an alarm mode (e.g., with the control module on and the vehicle off), determining whether a condition exists (e.g., based on a timer elapsing and triggering a wakeup circuit of the control module), and performing an action in response to the existence of the condition; and operating in the absence of an alarm wakeup, determining the absence of the alarm wakeup, and performing a different action in response to the absence of the alarm wakeup. For example, in response to the alarm wakeup and while operating in the alarm mode, the method can include executing an alarm mode startup procedure and transmitting a run request to a request feature. In response to a non-alarm wakeup and while operating in the nominal mode, the method can include executing a nominal startup procedure without transmitting a run request to the request feature.

[0097] Now turn Figure 7 , showing a control module for setting a timer to wake up the vehicle during a shut-off period (e.g., Figure 3 and Figure 4 302) to perform one or more post-operation tasks. For example, a timeline 700 may be used that includes WAKEM (e.g., Figure 3 and Figure 4 WAKEM 312) and startup / shutdown controllers (e.g., Figure 3 and Figure 4 The alarm clock wakes up the system (e.g., Figure 3 Alarm wake-up system 300 or Figure 2 The timer is set using the alarm wake-up system 400. The vehicle ignition status is shown in graph 702, the control module mode is shown in graph 704, the start / stop controller mode is shown in graph 706, the WAKEM status is shown in graph 708, an indication of other feature completion is shown in graph 710, an indication of requested feature completion is shown in graph 712, the timer status is shown in graph 714, an indication of whether the input condition of the first requested feature is satisfied is shown in graph 716, and an indication of whether the input condition of the second requested feature is satisfied is shown in graph 718.

[0098] For all of the above graphs, the horizontal axis represents time, where time increases along the horizontal axis from left to right. The vertical axis represents each of the marked parameters. For graph 702, the vertical axis represents whether the ignition is in the "on" position or the "off" position. For graph 704, the vertical axis represents whether the control module is in a wake mode in which the control module consumes a relatively large amount of electrical energy or a sleep mode in which the control module consumes a relatively small amount of electrical energy. For graph 706, the vertical axis represents whether the start / stop controller is in a normal operation mode (e.g., when the vehicle is started (e.g., when the ignition switch is in the on position)), a post-run operation mode (e.g., where the start / stop controller maintains the power relay of the control module when the characteristics of the control module perform post-run tasks when the ignition switch is in the off position), or off (e.g., after the control module is turned off and when the ignition switch is in the off position). For graph 708, the vertical axis represents whether WAKEM is "active" (e.g., transmitting and receiving signals) or "inactive" (e.g., not transmitting or receiving signals). For graphs 710 and 712, the vertical axis represents whether the completion of other features and requested features is indicated respectively ("yes" or "no"). Additionally, in the example of timeline 700, "other features" may refer to one or more features that may not have requested an alarm wake-up, and the indication of completion may refer to the "run_done" flag of all one or more other features being set, but each of the one or more other features may individually set its "run_done" flag. Similarly, "requested features" may refer to one or more features that may have requested an alarm wake-up, and the indication of completion may refer to the "run_done" flag of all one or more requested features being set, but each of the one or more requested features may individually set its "run_done" flag. For graph 714, the vertical axis represents whether the timer is "on" (e.g., set for a non-zero alarm wake-up time) or "off" (e.g., not set for a non-zero alarm wake-up time). For graphs 716 and 718, the vertical axis represents whether the input conditions for a first requested feature and a second requested feature are satisfied ("yes") or not satisfied ("no") respectively. Although two requested features are shown in the example of timeline 700, other examples may have more or fewer requested features.

[0099] Before time t1, the vehicle is started, where the ignition is in the on position (graph 702). In the case of vehicle start, the control module is in a wake state (graph 704), and the start / stop controller is in a normal operation mode (graph 706). Additionally, in the case of vehicle start, WAKEM is inactive (graph 708), and the timer is off (graph 714).

[0100] At time t1, the ignition switches to the off position (graph 702). In response to the off event, the start / stop controller transitions to the post-run mode (graph 706) to maintain the power relay of the control module so that the control module remains in the wake mode (graph 704). Additionally, other features (e.g., Figure 3 and Figure 4 other feature 308) and requested features (e.g., Figure 3 and Figure 4 requested feature 306) begin to perform their post-run tasks. The other features end their post-run tasks between time t1 and time t2, and thus, all "run_done" flags (e.g., at the start / stop controller) are set between time t1 and time t2, as indicated by the indication of the completion of the other features between time t1 and time t2 (graph 710). The input conditions of the first requested feature (graph 716) and the input conditions of the second requested feature (graph 718) are not satisfied. Therefore, the first requested feature and the second requested feature are not executed, but both the first requested feature and the second requested feature set their "run_done" flags so that they can request an alarm wake-up (e.g., using the callback function). At time t2, all "run_done" flags of the requested features are set, and thus the completion of the requested features is indicated (graph 712).

[0101] At time t2, in response to the other features and the requested features indicating completion (e.g., all "run_done" flags are set), WAKEM is activated (graph 708). For example, WAKEM can be activated in response to a signal from the start / stop controller. When active, WAKEM asks the requested features for the alarm wake-up time. After receiving the alarm wake-up time from the requested features, WAKEM selects the alarm wake-up time based on common characteristics of the alarm wake-up time, e.g., based on the requested amount of time, and at time t3, a timer is set for the selected alarm wake-up time. For example, WAKEM can set the timer for a certain duration (e.g., indicated by d1 in timeline 700). Thus, the timer is turned on (graph 714) and can start counting up and down during the duration. As described herein, the timer can be an internal chip of the control module or a timer of the BCM communicatively coupled to the control module (e.g., via CAN).

[0102] After receiving confirmation from the timer indicating that the selected alarm wake-up time has been set, WAKEM stores the global real-time in non-volatile memory, transmits an indication that it has completed scheduling the alarm wake-up to the start / stop controller (e.g., by setting the "run_done" flag), and at time t4, transitions back to the inactive state (graph 708). Additionally, at time t4, in response to receiving the indication from WAKEM, the start / stop controller shuts down the control module, for example, by switching the power relay of the control module to the "off" state. Thus, the control module transitions to the sleep mode at time t4 (graph 704). During the short duration after shutting down the control module between time t4 and time t5, the start / stop controller transitions to the "off" mode. Additionally, when the control module is in the sleep mode, the "run_done" flag of other features (graph 710) and the "run_done" flag of the request feature (graph 712) can be cleared. In another example, the "run_done" flag can be maintained, for example, when the "run_done" flag is stored in non-volatile memory.

[0103] At time t5, in response to the timer elapsing, the control module switches to the wake-up mode (graph 704) and the start / stop controller transitions to the post-run mode (graph 706). For example, the control module can be operated in the alarm mode when the control module is in the wake-up mode in response to the timer elapsing (e.g., alarm wake-up). WAKEM becomes active (graph 708) and compares the set timer duration indicated by d1 with the elapsed duration between the stored global real-time at time t3 when the timer was set and the current global real-time (e.g., at time t5). Dashed line 722a represents the first higher threshold (e.g., in the positive time direction from the end of d1), and dashed line 722b represents the second lower threshold (e.g., in the negative time direction from the end of d1). The time between the first higher threshold and the second lower threshold is within the threshold range relative to the set timer duration d1. As shown in graph 714, the elapsed duration between time t3 and time t5 is within the threshold range relative to the set timer duration d1, and thus WAKEM can determine that the timer passes the threshold accuracy check. Additionally, the start / stop controller can transmit a run request to the first request feature and the second request feature, and the first request feature and the second request feature can each evaluate the current vehicle conditions relative to their respective input conditions. Additionally, at time t5, the other features immediately set their "run_done" flags (graph 710) because the other features may not run when the control module is operating in the alarm mode.

[0104] At time t6, the input conditions for the second request feature are satisfied (graph 718). Accordingly, the second request feature is executed. However, at time t6, the input conditions for the first request feature are not satisfied (graph 716). The first request feature is not executed, and instead, the first request feature sets its "run_done" flag and continues to check its input conditions when the second request feature (and any other request features whose input conditions are satisfied) is executed.

[0105] At time t7, the second request feature completes its task and sets its "run_done" flag. After the second request feature is executed, the input conditions for the second request feature are no longer satisfied (graph 718). In addition, at time t7, all request features have set their "run_done" flags, and thus, the completion of the request features is indicated (graph 712). In response, WAKEM is activated (graph 708) and asks the request features again for the alarm wake-up time. After receiving the new alarm wake-up time from the request features, WAKEM selects the new alarm wake-up time, and at time t8, sets a timer for the new alarm wake-up time (graph 714). However, in other instances, if a threshold number of alarm wakes have been executed during the cut-off period, then WAKEM will not set a timer, and the request features will determine whether to execute their features or set a DTC, as described with respect to Figure 5 As described. After receiving confirmation from the timer indicating that a new alarm wake-up time has been set, WAKEM indicates to the start / stop controller that it has completed scheduling the alarm wake-up (e.g., by setting a "run_done" flag), and at time t9, returns to the inactive state (graph 708). In addition, at time t9, in response to receiving the indication from WAKEM, the start / stop controller shuts down the control module (graph 704) by, for example, switching the power relay of the control module to the "off" position to transition the control module to the sleep mode. After a short duration after time t9 and after shutting down the control module, the start / stop controller transitions to the "off" mode.

[0106] In this way, an alarm wake-up system including a wake-up manager (WAKEM) can arbitrate multiple alarm wake-up requests for requested features scheduled to execute during a post-vehicle-operation period (e.g., during a cut-off period) from a control module. Specifically, WAKEM can prioritize one of the multiple received alarm wake-up times from the requested features and set a timer for the selected alarm wake-up time before the control module shuts down. By scheduling a single alarm wake-up, conflicting, missed, and unexpected alarm wake-ups can be avoided, thereby increasing the robustness of the alarm wake-up system. After the control module is woken up by the expiration of the timer, all requested features can determine whether their respective input conditions are met, regardless of the alarm wake-up times requested by each feature. Each requested feature can be executed in response to its input conditions being met, after which the control module is shut down again. If the input conditions of the requested feature are not met, then if the number of alarm wake-ups during the cut-off period is less than a threshold count, the requested feature can request a new alarm wake-up time after the initial control module shutdown. By only executing requested features that can include diagnostic and non-diagnostic features, false fault detections can be reduced, for example, when the input conditions are met. Additionally, by limiting the number of alarm wake-ups during the cut-off period to the threshold count, vehicle battery consumption during the cut-off period can be reduced.

[0107] The technical effect of using a wake-up manager to schedule vehicle control module alarm wake-up requests from multiple requested features and only execute each requested feature after the alarm wake-up in response to input conditions being met is that alarm wake-up scheduling is simplified and each requested feature is executed when the conditions are optimal, thereby reducing false fault detections.

[0108] As a first example, a method includes: querying a first request feature and a second request feature for an alarm wake-up time; selecting a first alarm wake-up time from the first request feature and not selecting a second alarm wake-up time from the second request feature; setting a timer for the first alarm wake-up time; and sending a run request to the first request feature and the second request feature after the timer elapses. In the foregoing example, additionally or optionally, the request features are included in a control module of a vehicle, and the control module wakes up in response to the timer elapsing when the vehicle is turned off. In any or all of the foregoing examples, additionally or optionally, querying the first request feature and the second request feature for the alarm wake-up time is based on the start of the control module being turned off, and the control module is turned off after setting the timer. In any or all of the foregoing examples, additionally or optionally, the first request feature determines the first alarm wake-up time based on current vehicle conditions and input conditions of the first request feature, and the second request feature determines the second alarm wake-up time based on current vehicle conditions and input conditions of the second request feature. In any or all of the foregoing examples, additionally or optionally, after receiving the run request, each of the first request feature and the second request feature operates based on the input conditions of the respective request feature and current vehicle conditions. In any or all of the foregoing examples, the method additionally or optionally further includes operating in the case where the current vehicle conditions satisfy the input conditions of at least one of the first request feature and the second request feature; and in response to the current vehicle conditions satisfying the input conditions of at least one of the first request feature and the second request feature, operating at least one of the first request feature and the second request feature. In any or all of the foregoing examples, the method additionally or optionally further includes operating in the case where the current vehicle conditions satisfy the input conditions of at least one of the first request feature and the second request feature; and in response to the current vehicle conditions not satisfying the input conditions of at least one of the first request feature and the second request feature, not operating at least one of the first request feature and the second request feature. In any or all of the foregoing examples, additionally or optionally, each of the first request feature and the second request feature indicates completion based on a determination of ending its operation. In any or all of the foregoing examples, additionally or optionally, the start of the control module being turned off is based on at least one of the following: a vehicle cut-off state, and each of a first request feature completion state and a second request feature completion state.In any or all of the foregoing examples, the method additionally or optionally further includes, after the timer has elapsed from the first wake-up time, clearing the timer; incrementing an alarm wake-up counter; and setting the timer for a new wake-up time based on the count of the alarm wake-up counter and a subsequent control module shutdown start.

[0109] As another example, a method includes: operating a control module of a vehicle in an alarm mode in response to an alarm wake-up, the alarm wake-up occurring when the vehicle's ignition is in the off position; and operating the control module in a nominal mode in response to a non-alarm wake-up. In the foregoing example, additionally or optionally, the alarm wake-up is triggered by the expiration of a set timer, and the non-alarm wake-up is triggered by at least one of: a vehicle door half-open signal, a vehicle turn-on event, a vehicle remote start request, and the vehicle's brake pedal being depressed. In any or all of the foregoing examples, additionally or optionally, the control module executes a nominal start-up procedure when operating in the nominal mode, the nominal start-up procedure including filling the vehicle's fuel rail and actuating one or more valves to determine the end-stop positions of the one or more valves. In any or all of the foregoing examples, additionally or optionally, the control module executes an alarm mode start-up procedure when operating in the alarm mode, the alarm mode start-up procedure including filling the vehicle's fuel rail and not actuating the one or more valves. In any or all of the foregoing examples, additionally or optionally, operating in the alarm mode further includes performing post-run tasks, the post-run tasks including diagnostic and non-diagnostic tasks performed by a feature empowered to schedule the alarm wake-up.

[0110] As another example, a system for a vehicle includes: an engine system including an engine configured to propel the vehicle by burning air and fuel; a fuel system including a fuel tank for storing the fuel; an evaporative emissions system in fluid communication with the fuel system and an intake of the engine; a control system including a plurality of control modules communicatively coupled on a controller area network; a first control module of the plurality of control modules, the first control module including an alarm wake-up system and storing instructions in a non-transitory memory, the instructions when executed causing the first control module to: during a shutdown event, when an alarm wake-up count is less than a threshold count, schedule an alarm wake-up via the alarm wake-up system before transitioning to a sleep mode; and when the alarm wake-up count equals the threshold count, transition to the sleep mode without scheduling the alarm wake-up. In the foregoing example, additionally or optionally, the alarm wake-up system includes a wake-up manager, a timer, a start / stop controller, a plurality of request features, and a plurality of non-request features. In any or all of the foregoing examples, additionally or optionally, the wake-up manager receives alarm wake-up times from the plurality of request features but not from the plurality of non-request features, the wake-up manager selects one alarm wake-up time from the received alarm wake-up times, and the wake-up manager sets the timer for the selected one alarm wake-up time. In any or all of the foregoing examples, additionally or optionally, the start / stop controller maintains a power relay of the control module in an "on" position when the alarm wake-up is being scheduled, and switches the power relay of the control module to an "off" position after the timer has elapsed. In any or all of the foregoing examples, additionally or optionally, the plurality of request features includes an engine-off evaporative emissions system diagnostic test, and the first control module stores other instructions in the non-transitory memory, the other instructions when executed causing the first control module to: transition from the sleep mode to an alarm wake-up mode in response to the timer elapsing; transmit a run request to each of the plurality of request features but not to the non-request features via the start / stop controller; perform the engine-off evaporative emissions system diagnostic test in response to input conditions of the engine-off evaporative emissions system diagnostic test; and request a new alarm wake-up time for the engine-off evaporative emissions system diagnostic test via the wake-up manager in response to the input conditions of the engine-off evaporative emissions system diagnostic test not being met.

[0111] In another representation, a method includes: querying a first request feature and a second request feature for an alarm wake-up time; selecting a wake-up time from the first request feature based on criteria other than the queried time and not selecting a wake-up time from the second request feature; and running the first request feature and the second request feature based on the selected wake-up time of the first requested feature. In the foregoing example, additionally or optionally, the request features are included in a control module of a vehicle, and the control module wakes up in response to the selected wake-up time determined by a timer set for the selected wake-up time when the vehicle is turned off. In any or all of the foregoing examples, additionally or optionally, the first request feature determines a first wake-up time based on current vehicle conditions and input conditions of the first request feature, and the second request feature determines a second wake-up time based on current vehicle conditions and input conditions of the second request feature, and the first wake-up time is the selected wake-up time. In any or all of the foregoing examples, additionally or optionally, one of the first request feature and the second request feature is an evaporative emissions system diagnosis. In any or all of the foregoing examples, additionally or optionally, one of the first request feature and the second request feature is a nitrogen oxide sensor diagnostic test. In any or all of the foregoing examples, additionally or optionally, one of the first request feature and the second request feature is a low voltage set point manager. In any or all of the foregoing examples, additionally or optionally, running the first request feature and the second request feature includes transmitting a run request to each of the first request feature and the second request feature after a timer set for the selected wake-up time has elapsed. In any or all of the foregoing examples, additionally or optionally, running the first request feature and the second request feature further includes each of the first request feature and the second request feature running independently based on the current vehicle conditions and corresponding input conditions. In any or all of the foregoing examples, the method additionally or optionally further includes each of the first request feature and the second request feature independently indicating completion based on a determination to end its run. In any or all of the foregoing examples, the method additionally or optionally further includes querying the first request feature and the second request feature for a new alarm wake-up time based on the completion status of each of the first request feature and the second request feature.

[0112] In another alternative representation, a method for a vehicle includes operating in one of an alarm mode and a nominal mode based on at least one of a timer state and an ignition state of the vehicle. In any or all of the foregoing instances, the method additionally or optionally further includes the timer elapsing and the ignition state indicating an off state of the vehicle; and in response to the timer elapsing and the off state of the vehicle, operating in the alarm mode. In any or all of the foregoing instances, the method additionally or optionally further includes the ignition state indicating a start state of the vehicle; and in response to the start state of the vehicle, operating in the nominal mode. In any or all of the foregoing instances, the timer is set during a shutdown event of a control module of the vehicle. In any or all of the foregoing instances, the time set on the timer is based on vehicle conditions and input conditions of requested features during the shutdown event. In any or all of the foregoing instances, additionally or optionally, operating in the alarm mode includes priming a fuel rail of the vehicle during startup. In any or all of the foregoing instances, additionally or optionally, operating in the nominal mode includes priming the fuel rail of the vehicle during startup and actuating one or more valves.

[0113] It should be noted that the exemplary control and estimation routines included herein can be used for various 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 combination of a controller with various sensors, actuators, and other engine hardware. The specific 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. Accordingly, the various actions, operations, and / or functions illustrated can be performed in the sequence illustrated, in parallel, or in some cases omitted. Similarly, the processing order is not necessarily required to achieve the features and advantages of the exemplary embodiments described herein, but is provided for ease of illustration and description. One or more of the actions, operations, and / or functions illustrated can be repeatedly executed according to the particular strategy used. Further, the actions, operations, and / or functions described can clearly represent code to be programmed into the non-transitory memory of a computer-readable storage medium for an engine control system, where the described actions are implemented by executing the instructions in a system including a combination of various engine hardware components and an electronic controller.

[0114] It will be appreciated that the configurations and routines disclosed herein are exemplary in nature and these specific embodiments should not be viewed in a limiting sense as numerous variations are possible. For example, the above techniques can be applied to V-6, I-4, I-6, V-12, opposed 4-cylinder, and other engine types. The subject matter of the present disclosure includes all novel and non-obvious combinations and sub-combinations of the various systems and configurations and other features, functions, and / or properties disclosed herein.

[0115] The appended claims particularly point out certain combinations and sub-combinations regarded as novel and non-obvious. These claims may refer to an "element" or a "first element" or the equivalent thereof. Such claims are to be understood as including the incorporation of one or more such elements, neither requiring nor precluding two or more such elements. Other combinations and sub-combinations of the disclosed features, functions, elements, and / or properties are claimed by amending the claims or presenting new claims in this or a related application. Such claims, whether broader, narrower, equal, or different in scope from the original claims, are also regarded as included within the subject matter of the present disclosure.

[0116] According to the present invention, a method includes: querying a first requested feature and a second requested feature for an alarm wake-up time; selecting a first alarm wake-up time from the first requested feature and not selecting a second alarm wake-up time from the second requested feature; setting a timer for the first alarm wake-up time; and sending a run request to the first requested feature and the second requested feature after the timer elapses.

[0117] According to an embodiment, the requested features are included in a control module of a vehicle, and the control module wakes up in response to the timer elapsing when the vehicle is turned off.

[0118] According to an embodiment, querying the first requested feature and the second requested feature for the alarm wake-up time is based on the start of the control module being turned off, and the control module is turned off after setting the timer.

[0119] According to an embodiment, the first requested feature determines the first alarm wake-up time based on current vehicle conditions and input conditions of the first requested feature, and the second requested feature determines the second alarm wake-up time based on current vehicle conditions and input conditions of the second requested feature.

[0120] According to an embodiment, after receiving the run request, each of the first requested feature and the second requested feature operates based on the input conditions of the respective requested feature and current vehicle conditions.

[0121] According to an embodiment, the present invention is further characterized in that it operates when the current vehicle conditions meet the input conditions of at least one of the first request feature and the second request feature; and in response to the current vehicle conditions meeting the input conditions of at least one of the first request feature and the second request feature, runs at least one of the first request feature and the second request feature.

[0122] According to an embodiment, the present invention is further characterized in that it operates when the current vehicle conditions do not meet the input conditions of at least one of the first request feature and the second request feature; and in response to the current vehicle conditions not meeting the input conditions of at least one of the first request feature and the second request feature, does not run at least one of the first request feature and the second request feature.

[0123] According to an embodiment, each of the first request feature and the second request feature indicates completion based on a determination to end its operation.

[0124] According to an embodiment, the start of the control module shutdown is based on at least one of the following: the vehicle cut-off state, and each of the first request feature completion state and the second request feature completion state.

[0125] According to an embodiment, the present invention is further characterized in that after the timer elapses from the first wake-up time, the timer is cleared; the alarm wake-up counter is incremented; and the timer is set for a new wake-up time based on the count of the alarm wake-up counter and a subsequent start of the control module shutdown.

[0126] According to the present invention, a method includes: operating a control module of a vehicle in an alarm mode in response to an alarm wake-up, the alarm wake-up occurring when the ignition of the vehicle is in the off position; and operating the control module in a nominal mode in response to a non-alarm wake-up.

[0127] According to an embodiment, the alarm wake-up is triggered by the elapse of a set timer, and the non-alarm wake-up is triggered by at least one of the following: a vehicle door half-open signal, a vehicle turn-on event, a vehicle remote start request, and the vehicle's brake pedal being depressed.

[0128] According to an embodiment, the control module executes a nominal start-up procedure when operating in the nominal mode, the nominal start-up procedure including filling the vehicle's fuel rail and actuating one or more valves to determine the end stop positions of the one or more valves.

[0129] According to an embodiment, when operating in the alarm mode, the control module executes an alarm mode startup procedure, which includes filling the fuel rail of the vehicle and not actuating the one or more valves.

[0130] According to an embodiment, operating in the alarm mode further includes performing post-run tasks, which include diagnostic and non-diagnostic tasks performed by features empowered to schedule the alarm wake-up.

[0131] According to the present invention, there is provided a system for a vehicle, the system having: an engine system including an engine configured to propel the vehicle by combusting air and fuel; a fuel system including a fuel tank for storing the fuel; an evaporative emission system in fluid communication with the fuel system and an intake of the engine; a control system including a plurality of control modules communicatively coupled on a controller area network; a first control module of the plurality of control modules, the first control module including an alarm wake-up system and storing instructions in a non-transitory memory, the instructions when executed causing the first control module to: during a shutdown event, when an alarm wake-up count is less than a threshold count, schedule an alarm wake-up via the alarm wake-up system before transitioning to a sleep mode; when the alarm wake-up count is equal to the threshold count, transition to the sleep mode without scheduling the alarm wake-up.

[0132] According to an embodiment, the alarm wake-up system includes a wake-up manager, a timer, a start / stop controller, a plurality of request features, and a plurality of non-request features.

[0133] According to an embodiment, the wake-up manager receives alarm wake-up times from the plurality of request features rather than from the plurality of non-request features, the wake-up manager selects one alarm wake-up time from the received alarm wake-up times, and the wake-up manager sets the timer for the selected one alarm wake-up time.

[0134] According to an embodiment, the start / stop controller keeps the power relay of the control module in the "on" position when the alarm wake-up is being scheduled, and switches the power relay of the control module to the "off" position after the timer has elapsed.

[0135] According to an embodiment, the plurality of requested features includes an engine-off evaporative emissions system diagnostic test, and the first control module stores other instructions in a non-transitory memory, the other instructions which when executed cause the first control module to: transition from the sleep mode to an alarm wake-up mode in response to the expiration of the timer; transmit a run request to each of the plurality of requested features via the start / stop controller without transmitting to the non-requested features; execute the engine-off evaporative emissions system diagnostic test in response to meeting the input conditions of the engine-off evaporative emissions system diagnostic test; and request a new alarm wake-up time for the engine-off evaporative emissions system diagnostic test via the wake-up manager in response to not meeting the input conditions of the engine-off evaporative emissions system diagnostic test.

Claims

1. A method for a vehicle, the method comprising: In response to a cut-off event of the vehicle and before the control module of the vehicle is turned off, query a first requested feature and a second requested feature for an alarm wake-up time; Select a first alarm wake-up time from the first requested feature and not select a second alarm wake-up time from the second requested feature; Before the control module is turned off, set a timer for the first alarm wake-up time; and After the timer elapses at the first alarm wake-up time, wake up the control module and send a run request to the first requested feature and the second requested feature.

2. The method according to claim 1, wherein the first requested feature and the second requested feature are included in the control module, and the control module wakes up in response to the timer elapsing when the vehicle is turned off.

3. The method according to claim 2, wherein the control module is turned off after setting the timer.

4. The method according to claim 3, wherein the first requested feature determines the first alarm wake-up time based on current vehicle conditions and input conditions of the first requested feature, and the second requested feature determines the second alarm wake-up time based on the current vehicle conditions and input conditions of the second requested feature.

5. The method according to claim 4, wherein after receiving the run request, each of the first requested feature and the second requested feature operates based on input conditions of the respective requested feature and current vehicle conditions.

6. The method according to claim 5, the method further comprising: Operating when the current vehicle conditions satisfy the input conditions of at least one of the first requested feature and the second requested feature; And In response to the current vehicle conditions satisfying the input conditions of at least one of the first requested feature and the second requested feature, operating at least one of the first requested feature and the second requested feature.

7. The method according to claim 5, the method further comprising: Operating when the current vehicle conditions do not satisfy the input conditions of at least one of the first requested feature and the second requested feature; And In response to the current vehicle conditions not satisfying the input conditions of at least one of the first requested feature and the second requested feature, not operating at least one of the first requested feature and the second requested feature.

8. The method according to claim 5, wherein each of the first requested feature and the second requested feature indicates completion based on a determination to end its operation.

9. The method according to claim 6, wherein the start of turning off the control module is based on at least one of: a vehicle cut-off state, and each of a first requested feature completion state and a second requested feature completion state.

10. The method according to claim 9, the method further comprising: After the timer elapses at the first alarm wake-up time, Clear the timer; Increment an alarm wake-up counter; and Set the timer for a new wake-up time based on the count of the alarm wake-up counter and subsequent start of control module shutdown.

11. A system for a vehicle, the system comprising: An engine system including an engine configured to propel the vehicle by combusting air and fuel; A fuel system including a fuel tank for storing the fuel; An evaporative emissions system in fluid communication with the fuel system and an intake of the engine; A control system including a plurality of control modules communicatively coupled on a controller area network; A first control module of the plurality of control modules, the first control module including an alarm wake-up system and storing instructions in a non-transitory memory, the instructions when executed causing the first control module to: During a shutdown event, When the alarm wake-up count is less than a threshold count, schedule an alarm wake-up via the alarm wake-up system before transitioning to a sleep mode; and When the alarm wake-up count equals the threshold count, transition to the sleep mode without scheduling the alarm wake-up.

12. The system of claim 11, wherein the alarm wake-up system includes a wake-up manager, a timer, a start / stop controller, a plurality of requested features, and a plurality of non-requested features.

13. The system of claim 12, wherein the wake-up manager receives an alarm wake-up time from the plurality of requested features but not from the plurality of non-requested features, the wake-up manager selects an alarm wake-up time from the received alarm wake-up times, and the wake-up manager sets the timer for the selected alarm wake-up time.

14. The system of claim 13, wherein the start / stop controller maintains a power relay of the control module in an "on" position when the alarm wake-up is being scheduled, and switches the power relay of the control module to an "off" position after the timer has been set.

15. The system of claim 14, wherein the plurality of requested features includes an engine-off evaporative emissions system diagnostic test, and the first control module stores other instructions in a non-transitory memory, the other instructions when executed causing the first control module to: Transition from the sleep mode to an alarm wake-up mode in response to the timer elapsing; Transmit a run request to each of the plurality of requested features via the start / stop controller and not to the non-requested features; Execute the engine-off evaporative emissions system diagnostic test in response to input conditions for the engine-off evaporative emissions system diagnostic test being met; and Request a new alarm wake-up time for the engine-off evaporative emissions system diagnostic test via the wake-up manager in response to the input conditions for the engine-off evaporative emissions system diagnostic test not being met.

Images