User device vehicle charger strategy

Abstract

The invention provides a user device vehicle charger strategy. A consumption amount of energy required to charge a user device connected to a device port of a vehicle is estimated based on a state of charge (SoC) of a device battery of the user device. In response to an expected SoC of an LV battery of the vehicle exceeding a calibrated energy threshold amount of the LV battery after providing the consumption of energy, a connected user device is charged during a key-off. Otherwise, additional energy is generated to charge the connected user device using an engine start / stop schedule that defines the time to start the engine of the vehicle and the duration of the run time of the engine to ensure that the LV battery remains above the calibrated threshold amount of energy.

Description

Technical Field

[0001] Aspects of the present disclosure generally relate to strategies for charging a user device connected to a vehicle during key-off periods. Background Art

[0002] Vehicles can be used to charge various devices. These devices can include mobile phones or tablet computers. The devices can be connected to the vehicle's alternator and / or battery to receive power. This can be done, for example, using a wired Universal Serial Bus (USB) connection or a wireless charging pad. Summary of the Invention

[0003] In one or more illustrative examples, a vehicle for charging a user device includes: a device port configured to provide power from a low-voltage (LV) battery of the vehicle to a device battery of a connected user device; and one or more controllers. The one or more controllers are configured to estimate an energy consumption required to charge the connected user device based on a state of charge (SoC) of the device battery; charge the connected user device during key-off periods in response to an expected SoC of the LV battery exceeding a calibrated energy threshold amount of the LV battery after providing the energy consumption; and otherwise generate additional energy to charge the connected user device using an engine start / stop schedule that defines a duration of a time to start an engine of the vehicle and a running time of the engine, thereby ensuring that the LV battery remains above the calibrated energy threshold amount.

[0004] In one or more illustrative examples, a method for charging a user device is provided. An energy consumption required to charge the user device is estimated based on a state of charge (SoC) of a device battery of a user device connected to a device port of a vehicle. The connected user device is charged during key-off periods in response to an expected SoC of the LV battery of the vehicle exceeding a calibrated energy threshold amount of the LV battery after providing the energy consumption. Otherwise, additional energy is generated to charge the connected user device using an engine start / stop schedule that defines a duration of a time to start an engine of the vehicle and a running time of the engine, thereby ensuring that the LV battery remains above the calibrated energy threshold amount.

[0005] In one or more illustrative examples, a non-transitory computer-readable medium includes instructions for charging a user device, the instructions when executed by one or more controllers of a vehicle cause the one or more controllers to perform operations, the operations including estimating an energy consumption required to charge the user device based on a state of charge (SoC) of a device battery of the user device connected to a device port of the vehicle; charging the connected user device during key-off in response to an expected SoC of an LV battery of the vehicle exceeding a calibrated energy threshold amount after providing the energy consumption; charging the connected user device during key-off until the LV battery reaches the calibrated energy threshold amount in response to the expected SoC exceeding the calibrated energy threshold amount and the vehicle being authorized to start an engine of the vehicle; and otherwise generating additional energy to charge the connected user device using an engine start / stop schedule defining a duration of a time to start the engine of the vehicle and a running time of the engine, thereby ensuring that the LV battery remains above the calibrated energy threshold amount. BRIEF DESCRIPTION OF THE DRAWINGS

[0006] To better understand the present invention and to show how it may be carried out, embodiments of the present invention will now be described by way of non-limiting example only with reference to the accompanying drawings, in which:

[0007] Figure 1 An example portion of a vehicle configured to power a user device via a device port of the vehicle is shown;

[0008] Figure 2 Further details of the vehicle and the user device are shown;

[0009] Figure 3 An example of a vehicle display of a user interface for requesting user consent to activate the engine when the vehicle is in a closed mode is shown;

[0010] Figure 4 An example of a vehicle display of a user interface showing settings for charging a user device is shown;

[0011] Figure 5 An example process of operations of a vehicle controller for providing power to a user device via a device port is shown; and

[0012] Figure 6 An example computing device for use in charging a user device by a vehicle is shown. DETAILED DESCRIPTION

[0013] As needed, detailed embodiments of the present invention are disclosed herein; however, it should be understood that the disclosed embodiments are merely examples of the present invention that can be implemented in various forms and alternative forms. The drawings are not necessarily to scale; some features may be enlarged or minimized to show details of particular components. Accordingly, the specific structural and functional details disclosed herein are not to be construed as limiting, but merely as a representative basis for teaching one skilled in the art to employ the present invention in various ways.

[0014] Figure 1 An example portion of a vehicle 102 configured to power a user device 104 via a device port 106 of the vehicle 102 is shown. As shown, a first user device 104A is connected to a first device port 106A via a power connection 108A and a data connection 110A. Also shown, a second user device 104B is connected to a second device port 106B via a power connection 108B and a data connection 110B. The vehicle 102 may also include a human-machine interface (HMI) 112 to facilitate communication between the user and the vehicle 102. It should be noted that the types, locations, and quantities of the user devices 104 and the device ports 106 are merely examples, and more, fewer, or different types of user devices 104 and device ports 106 may be used.

[0015] The vehicle 102 may include various types of automobiles, crossover utility vehicles (CUVs), sport utility vehicles (SUVs), trucks, boats, airplanes, or other mobile machines for transporting people or goods. In some cases, the vehicle 102 may be powered by an internal combustion engine (ICE). As another possibility, the vehicle 102 may be a hybrid electric vehicle powered by both an internal combustion engine, a traction battery, and one or more electric motors. The hybrid vehicle 102 may appear in various forms, such as a series hybrid electric vehicle, a parallel hybrid electric vehicle, or a parallel / series hybrid electric vehicle. Since the type and configuration of the vehicle 102 can vary, the capabilities of the vehicle 102 can vary correspondingly. As some possibilities, the vehicle 102 may have different capabilities in terms of passenger capacity, towing capacity and payload, and storage capacity. For ownership, inventory, and other purposes, the vehicle 102 may be associated with a unique identifier (such as a vehicle identification number (VIN), a globally unique identifier (GUID), a customer or fleet account, etc.).

[0016] The user device 104 may include various bring-in devices that can be carried by the user into the vehicle 102. As some non-limiting possibilities, examples of such user devices 104 may include laptop computers, tablet devices, smart phones, smart rings or other wearable devices, personal digital assistants (PDAs), virtual reality (VR) headsets, smart speaker devices.

[0017] The device port 106 can be various types of electrical ports configured to provide power and / or data communication between the vehicle 102 and the user device 104. As some non-limiting examples, the device port 106 can be any one of a USB Type-A, USB Type-B, USB Mini, USB Micro, and / or USB Type-C port. In another example, the device port 106 can be a port. In still other examples, the device port 106 can include other types of ports, such as a 12V cigarette lighter port, a 120V electrical appliance port, etc.

[0018] A power connection 108 can be formed between the device port 106 of the vehicle 102 and the user device 104. The user device 104 can accordingly receive power via the power connection 108. The power connection 108 can supply direct current (DC) or alternating current (AC) power to the user device 104. For example, a cable can have a charging connector for insertion into the corresponding device port 106 of the vehicle 102 and a device power connector for connection to the port of the user device 104. Alternatively, the vehicle 102 can be configured to use wireless inductive coupling to form the power connection 108. This can be done to wirelessly transmit power to the user device 104 without a cable.

[0019] A data connection 110 can also be provided between the user device 104 and the vehicle 102. The data connection 110 can provide information communication between the user device 104 and the vehicle 102. In some examples, such as shown for the first user device 104A, the data connection 110 can be a wireless data connection 110A, such as a Wi-Fi connection, a Bluetooth connection, etc. In other examples, such as shown for the second user device 104B, the data connection 110 can be a wired data connection 110B, for example, through the same cable as the power connection 108. Other variations are possible, such as a combination of a wireless data connection 110 and wireless inductive charging.

[0020] The HMI 112 can include various displays, such as a screen in the center console of the passenger compartment of the vehicle 102. In some examples, the HMI 112 can also include one or more speakers for providing audio output to the user. The HMI 112 can also include facilities for receiving input, such as one or more buttons, controls, touchscreens, microphones, etc.

[0021] Figure 2Further details of the vehicle 102 and the user device 104 are shown. As shown, the vehicle 102 and the user device 104 can each include circuitry and controls to manage the energy transfer between the power source and the vehicle 102. Charging of the user device 104 can be controlled on the vehicle 102 side of the power connection 108 and the data connection 110 via the vehicle controller 202. Charging of the user device 104 can be controlled on the user device 104 side of the power connection and the wireless connection via the device controller 204. The vehicle controller 202 and the device controller 204 can be any of various types of computing devices, including one or more processors configured to execute computer instructions, and a storage medium on which computer-executable instructions and / or data can be maintained.

[0022] The device controller 204 can also be configured to communicate with other components of the vehicle 102 via the in-vehicle network 206. As some examples, the in-vehicle network 206 can include, but is not limited to, one or more of a controller area network (CAN), Ethernet, and a media-oriented system transport (MOST) bus. The in-vehicle network 206 can allow the device controller 204 to communicate with other vehicle systems such as one or more electronic control units (ECUs). The ECUs can include, but are not limited to, a body control module (BCM) 208, a powertrain control module (PCM) 210, and a global navigation satellite system (GNSS) controller 214.

[0023] The BCM 208 can be configured to connect to the vehicle controller 202 via the in-vehicle network 206 and monitor and control various electronic accessories in the body of the vehicle 102. As an example, the BCM 208 can be configured to control the central lock, electric windows, electric mirrors, and the device port 106 of the vehicle 102.

[0024] The PCM 210 can be configured to connect to the vehicle controller 202 via the in-vehicle network 206. The PCM 210 can monitor and control the operation of the engine 212 and the transmission, including the start, stop, or accessory (ACC) state of the vehicle 102. In the "start" state, the vehicle 102 can be in a ready or power mode, and accessory functions such as the radio can be available. In the "stop" state, the power capabilities of the vehicle 102 may be disconnected and unavailable without credentials. In the ACC state, the accessories of the vehicle 102 can be available, but the power capabilities of the vehicle 102 may be disconnected and unavailable.

[0025] The GNSS controller 214 can be configured to provide location services to the vehicle 102. In an example, the vehicle controller 202 can be configured to utilize the GNSS controller 214 to determine the location of the vehicle 102.

[0026] Vehicle 102 may also include a low voltage (LV) battery 216. The LV battery 216 can be used to provide power to start the engine 212 of the vehicle 102. The LV battery 216 can also be used to power the low voltage electronics of the vehicle 102 (such as various ECUs) (e.g., power the vehicle controller 202, BCM 208, PCM 210, GNSS controller 214, etc.). The LV battery 216 can also be used as a power source for the device port 106.

[0027] The user device 104 may include a device battery 218. The device battery 218 can be configured to power the device controller 204 and / or other components of the user device 104. Using the vehicle controller 202 and / or the device controller 204, the vehicle 102 and / or the user device 104 can be configured to manage the energy transfer between the LV battery 216 and the device battery 218.

[0028] The vehicle controller 202 can maintain settings 220 that describe various aspects of how to charge the device battery 218 from the LV battery 216. As an example, these settings 220 can define the SoC level for charging the device battery 218. These settings 220 can be configured using the HMI 112, as discussed in detail herein.

[0029] The vehicle 102 can implement a charger policy that keeps the device port 106 on for a predefined period of time after the key is turned off or until the battery drops below a predefined state of charge (SoC). Such a method may be acceptable for charging a user device 104 such as a phone. However, a more complete policy may be needed to accommodate charging a user device 104 with a greater power demand (such as a laptop computer) to support the vehicle 102 as an office policy.

[0030] Taking the use of the USB device port 106 as an example, currently available are 60W chargers with a 5A draw and 70W chargers with a 5.8A draw. Over five hours, the use of these two chargers will result in a power consumption of (5A + 5.8A) x 5 hours = 54Ah. For an ICE vehicle 102 with an LV battery 216 of 68Ah, even assuming the low voltage battery is fully charged, using this amount of power may result in a no-start situation. This estimate may be overly optimistic because the low voltage battery is typically charged to 80% SoC, rather than 100% SoC.

[0031] This document discusses enhanced methods for powering an incoming user device 104 via device port 106. During vehicle 102 key-off, the vehicle 102 can monitor the status of the device port 106 by determining whether the user device 104 is present. The monitoring can be based on the discharge current at the device port 106. The vehicle 102 can also use a position sensor, resistance-based measurements, an internal sensor suite (internal camera / radar), and / or a continuity check to monitor whether the user device 104 is inserted into the device port 106.

[0032] During key-off, a wired and / or wireless data connection 110 can be used to communicate with the connected user device 104 to determine the current SoC of the user device 104, as well as its battery size, maximum voltage, charging profile, etc. The vehicle 102 can use these inputs to estimate the total amount of energy required to charge the user device 104 to a desired SoC / energy level.

[0033] The vehicle 102 can check the state of the SoC of the LV battery 216 to determine whether the vehicle 102 is capable of supplying energy to support powering the device port 106 to charge the user device 104. For example, the vehicle 102 can subtract the requested power from the current SoC of the LV battery 216 to determine the expected SoC of the LV battery 216 after performing the power supply. If the expected SoC is below the calibrated energy threshold amount of the LV battery 216, the vehicle 102 may lack sufficient power reserves to perform the charging. If so, the vehicle 102 can determine that it may be necessary to start the engine 212 to generate additional power. The vehicle 102 can determine how long the engine 212 will need to run to charge the LV battery 216 and / or the device battery 218 to the desired level. This information indicating when to start the engine 212 and how long the engine 212 runs during key-off can be referred to as the engine start / stop schedule 222. This determination can be based on the amount of energy required to charge the user device 104.

[0034] Whether to charge the detected user device 104 and how much to charge the user device 104 can be specified by the user in the settings 220 of the vehicle 102.

[0035] Figure 3 An example of the vehicle 102 displaying a user interface 300 is shown, which shows the settings 220 for charging the user device 104. The user interface 300 can be displayed on the host unit of the vehicle 102 or other HMI 112. In other examples, the user interface 300 can alternatively be displayed to one or the other of the user devices 104 (e.g., a smart phone associated with a user account corresponding to the vehicle 102).

[0036] As shown, the user interface 300 includes a category list 302 of one or more content screens to be displayed in the main screen area 306 of the HMI 112. As some examples, the category list 302 may include an audio screen from which audio configuration can be performed, a phone screen from which call services can be utilized, a navigation screen from which map and route selection can be performed, a favorites screen from which items marked as favorites can be easily accessed, an application screen from which installed applications can be invoked, a settings screen from which the backlight or other general settings of the HMI 112 can be accessed, and a features screen showing the features of the vehicle 102. The user interface 300 may also include a general information area 304 in which time, current temperature, and other information can always remain visible to the user regardless of the specific screen or application active in the main screen area 306.

[0037] The user interface 300 provides a list of devices 308 of connections to user devices 104 connected to the vehicle 102. For each of the user devices 104, the list of connected devices 308 may indicate the name 310 of the user device 104, the charging status 312 of the user device 104, and a settings indication 314 for charging the user device 104. To adjust the settings 220, the user can select the corresponding icon for the user device 104. The list of connected devices 308 may also include an entry for the LV battery 216 to allow the user to view the current SoC of the LV battery 216 and adjust the settings 220 for charging the LV battery 216.

[0038] The name 310 of the user device 104 may correspond to the name set for the user device 104 during pairing. The charging status 312 may indicate information describing the charge state of the user device 104 and / or information regarding charging of the user device 104 by the vehicle 102 (e.g., whether the user device 104 is charging, whether any settings 220 are related to the charging rate, timing, etc. of the vehicle 102 charging the user device 104, etc.).

[0039] In the example shown, the user devices 104 are shown as being detected by the vehicle 102. The first user device 104 is a phone, where the name 310 is "Jason's Phone", the charging status 312 is 50%, and the settings 220 indicate charging the device to full SoC. The second user device 104 is a laptop computer, where the name 310 is Laptop L1, the charging status 312 is 23% and decreasing (e.g., indicating use), and the settings 220 indicate charging the device to at least 50% SoC.

[0040] The setting indicator 314, when selected, allows the user to configure aspects of charging of the user device 104. This can include options such as when to start / stop charging the user device 104, e.g., based on the time of day, remaining power on the user device 104, remaining power on the vehicle 102, etc. Once set, this information can be saved to the settings 220 accordingly.

[0041] The user interface 400 may also include a return control 316 which, when selected, allows the user to return to the previous screen with which the user has interacted. In the illustrated example, the return control 316 may allow the user to return to the previous screen with which the user has interacted.

[0042] The vehicle 102 may also determine whether the vehicle 102 is authorized to start its engine 212 during key-off based on monitoring the current operating state of the vehicle 102. Depending on the presence and quality of signals such as the fuel level and location of the vehicle 102, the vehicle 102 may select that user input is required to confirm that the engine 212 can be started. The vehicle 102 may also determine the GNSS position of the vehicle 102, determine whether it is on public or private property, and refer to local guidelines regarding the policy for starting to start the engine 212 to determine whether the vehicle 102 can start the engine 212 based on the location. In some cases, the vehicle 102 may require user consent to allow starting the engine 212 in the off mode.

[0043] Figure 4 An example of the vehicle 102 displaying the user interface 400 for requesting user consent to activate the engine 212 when the vehicle 102 is in the off mode is shown. In the example, the user interface 400 may be displayed to the HMI 112 of the vehicle 102. It should be noted that in other examples, a similar interface (e.g., including the consent prompt 402) may alternatively be displayed to one of the user devices 104 or another user device 104 (e.g., a smart phone associated with the user account corresponding to the vehicle 102).

[0044] The consent prompt 402 can be overlaid on the user interface 400. The consent prompt 402 can include a title 404 indicating that a device charging alert is being displayed. The consent prompt 402 can also include message text 406 that indicates that there is a user device 104 at the device port 106 of the vehicle 102 and that it may be necessary to run the engine 212 to ensure that the user device 104 remains powered when the vehicle 102 is turned off. The consent prompt 402 can also include: a permit control 408 that, when selected by the user, grants the vehicle 102 the ability to start the engine 212 during the off mode; and a deny control 410 that, when selected by the user, prevents the vehicle 102 from starting the engine 212 during the off mode. The consent prompt 402 can also include a settings control 412 that, when selected, allows the configuration of settings 220 for charging the user device 104. For example, in response to the selection of the settings control 412, the user interface 300 can be displayed.

[0045] The consent prompt 402 can be displayed in various situations, such as when the vehicle 102 is in a position where user consent to start the engine 212 is required, when the fuel level of the vehicle 102 is below a predefined threshold level, and so on.

[0046] Figure 5 An example process 500 of the operation of the vehicle controller 202 for providing power to the user device 104 via the device port 106 is shown. In the example, the process 500 can be performed using the vehicle controller 202 and other components of the vehicle 102, as discussed in detail with respect to Figures 1 to 2 By using the process 500, a charger strategy can be implemented for the vehicle 102 that coordinates the power usage of the device port 106 in the vehicle 102 with the user device 104 being powered and / or charged, the state of the LV battery 216 of the vehicle 102, the ability of the vehicle 102 to start the engine 212, and the future route of the vehicle 102.

[0047] At operation 502, the vehicle 102 determines whether to monitor the vehicle 102 for the user device 104. In the example, a monitoring period can be initiated in response to the key-off of the vehicle 102. The monitoring period can be performed within a predefined time period after the key-off. If the monitoring period is initiated and not expired, control proceeds to operation 504. However, if the user device 104 is not detected during the monitoring period, the vehicle 102 can turn off the power to the device port 106, and the process 500 ends.

[0048] At operation 504, vehicle 102 monitors device port 106 for the presence of user device 104. The monitoring can be performed when vehicle 102 is in the off state. During the time when vehicle 102 is off, vehicle 102 can monitor the status of device port 106 by determining whether there is a discharge current at device port 106. If so, it can be inferred that user device 104 is connected.

[0049] Other methods can be used additionally or alternatively to monitor device port 106 for the presence of user device 104. As some examples, vehicle 102 can use position sensors, resistance-based measurements, an internal sensor suite of vehicle 102 (e.g., internal cameras and / or radar sensors for occupant detection, drowsiness determination, etc.), and continuity checks to monitor whether user device 104 is plugged into device port 106.

[0050] At operation 506, vehicle 102 determines whether one or more user devices 104 are present. If not, control returns to operation 502. If user device 104 is detected, vehicle 102 can proceed to operation 508 to determine the SoC of user device 104.

[0051] At operation 508, vehicle 102 collects information about user device 104. In an example, vehicle 102 can utilize data connection 110 with each user device 104 to communicate with user device 104 to receive the size, maximum voltage, charging profile, current SoC, etc. of device battery 218 in each of user devices 104.

[0052] If information about the SoC of user device 104 cannot be provided because user device 104 cannot communicate with vehicle 102, vehicle 102 can alternatively use other sensors (such as an internal camera) to identify the type of user device 104. Or, vehicle 102 can receive user input via HMI 112 to determine the expected maximum energy amount for charging user device 104 based on battery size guidelines and / or estimates (e.g., assuming device battery 218 is at a low initial SoC).

[0053] Note that collecting information about the user device 104 can include collecting information over time to identify usage trends of the user device 104. For example, the vehicle 102 can continue to monitor the SoC of the user device 104 over a period of time to identify usage and / or power consumption on the user device 104. If the SoC of the user device 104 decreases, for example, due to the use of the user device 104, the vehicle 102 can determine to maintain the SoC of the user device 104. The vehicle 102 can also monitor device usage via the vehicle 102's internal camera by other methods (such as Wi-Fi usage, mouse movement) to determine whether the user device 104 is still in use. It is worth noting that this determination can be independent of whether there are occupants in the vehicle 102, because the user device 104 may be operating, which may require the vehicle 102 to provide power via the device port 106 even if no user is present.

[0054] At operation 510, the vehicle 102 determines the energy requirements of the user device 104. In an example, the vehicle 102 can use the information collected at operation 508 to sum the total amount of energy required to charge all user devices 104 to a desired SoC and / or energy level. This value can be referred to as the energy consumption.

[0055] For example, if the SoC of one of the user devices 104 is below the user input calibration threshold of that user device 104, the vehicle 102 can determine that the user device 104 needs to be charged. The energy consumption can be determined as the amount of energy required to bring the user device 104 to a predefined power level (e.g., fully charged, meet or exceed the user input calibration threshold, meet or exceed another threshold, etc.). In another example, if the SoC of the user device 104 is above the threshold, but the power is decreasing or otherwise being used, the vehicle 102 can further consider the energy draw rate to determine the amount of energy required to meet the threshold.

[0056] In some examples, the charging SoC can be defined in the settings 220 of the vehicle 102. The settings 220 can indicate the desired SoC for each of the different user devices 104. These SoCs can then be used to determine the amount of energy required for each connected user device 104.

[0057] At operation 512, the vehicle 102 determines whether the user device 104 needs to be charged. For example, if the energy requirement determined at operation 510 is zero, the control can return to operation 502. This can occur, for example, if the SoC of each of the user devices 104 is above the user input calibration threshold and it is not being used and / or there is no discharge current over a period of time. If the monitoring period has passed once returning to operation 502, the process 500 ends.

[0058] At operation 514, vehicle 102 determines, via BCM 208, the SoC of LV battery 216 of vehicle 102. This can be used to determine whether LV battery 216 is capable of supplying the energy required to support powering device port 106 to charge user device 104.

[0059] Vehicle 102 can determine the expected SoC of LV battery 216 by subtracting the SoC of LV battery 216 determined at operation 514 from the consumed energy determined at operation 510. If the expected SoC drops below a calibrated minimum threshold SoC or results in a net change in SoC (depth of discharge) higher than a calibrated threshold, it may be necessary to start engine 212. In an example, the threshold can be set to ensure that vehicle 102 can be restarted. If so, control proceeds to operation 516.

[0060] At operation 516, vehicle 102 monitors the operating state of vehicle 102. This can include monitoring the fuel level of vehicle 102, and / or monitoring the position of vehicle 102. These aspects can be monitored to determine whether starting engine 212 is permitted and / or whether user input is required to confirm that vehicle 102 is in an open space and / or in accordance with local guidelines before starting engine 212.

[0061] For example, vehicle 102 can monitor the fuel level of vehicle 102 via PCM 210. This monitoring can include ensuring that idling vehicle 102 to charge LV battery 216 and / or user device 104 does not cause vehicle 102 to drop below a predefined fuel level (e.g., defined in gallons, percentage of capacity, remaining range, etc.). In another example, vehicle 102 can monitor the SoC of LV battery 216 to ensure that a calibrated minimum energy threshold amount is retained in LV battery 216. This can be done to confirm that LV battery 216 is capable of restarting engine 212.

[0062] Vehicle 102 can also monitor its position via GNSS controller 214. For example, vehicle 102 can determine whether vehicle 102 is located in an enclosed space. This determination can be made based on various methods, such as by comparing the GNSS position received from GNSS controller 214 with a geofence indicating an enclosed space, via user input, and / or via the sensor suite of vehicle 102 to determine that vehicle 102 is within an enclosed area (e.g., via image recognition of an image captured by vehicle 102). Vehicle 102 can use the GNSS position of vehicle 102 to determine whether vehicle 102 is on public or private property and can refer to local guidelines regarding the strategy for starting engine 212 of vehicle 102 to determine whether starting the vehicle's engine 212 is permitted based on the position of vehicle 102.

[0063] At operation 518, vehicle 102 determines whether engine 212 needs to be started. For example, if vehicle 102 is in a position that allows engine 212 to start, and / or the fuel level is sufficient for vehicle 102 to idle engine 212 without losing the required driving range, vehicle 102 may determine to execute the engine 212 state. If so, control proceeds to operation 520. If not, control proceeds to operation 522.

[0064] At operation 520, vehicle 102 constructs an engine start / stop schedule 222. This engine start / stop schedule 222 may include how long engine 212 is to be turned on and when to turn on engine 212.

[0065] Regarding the amount of time to run engine 212, based on the amount of energy required and the amount of net energy generated into LV battery 216 via the alternator of engine 212 when engine 212 is on, vehicle 102 may determine the amount of time engine 212 needs to run to fill the deficiency of the available SoC. In some examples, the settings 220 of vehicle 102 may define the maximum amount of running time for engine 212 to generate additional energy.

[0066] In some examples, if LV battery 216 is at a low SoC, the amount of time to run engine 212 may be increased to additionally charge LV battery 216 to a higher SoC to obtain the additional benefit of refreshing LV battery 216, because an extended idle cycle may exceed additional starts that will be needed later. Also, charging LV battery 216 to a higher SoC may provide a buffer in the power budget for charging user device 104. Or, if the weather is cold, additional engine 212 running time may be preferred to ensure that vehicle 102 does not get too cold, and / or to increase the additional power budget to ensure that vehicle 102 can start.

[0067] In another example, vehicle 102 may determine the expected driving time and / or the expected engine 212 on time during the next route, and / or whether the next driving opportunity is a short trip or a longer trip that allows user device 104 to be charged. For example, vehicle 102 may use artificial intelligence (AI) or machine learning (ML) to determine the length of the next trip based on the user's historical use of vehicle 102. The historical use for identifying patterns may include the historical changes in the starting and destination positions of vehicle 102 over time, date, season, etc., and include other factors such as detected occupants, detected user device 104, etc., which may be related to shorter or longer trips. The determination of the expected length of the trip may be used to increase or decrease the amount of time to run engine 212. For example, if only a short trip is expected, the running time may be longer than the case where a longer trip is activated.

[0068] Regarding when to start the engine 212, the vehicle 102 can determine the timing based on factors such as the expected time the vehicle 102 expects to remain in the current position, the expected driving time and / or the expected engine 212 start time during the next route of the vehicle 102, whether the next driving opportunity is a short trip or a longer trip, and the time since the last use of the engine 212.

[0069] For example, if the engine 212 has recently run and is already hot, the engine 212 may operate more efficiently if restarted soon after. If so, the vehicle 102 can determine to start the engine 212 immediately rather than waiting for the engine 212 to cool and become less efficient. Or, if the engine 212 is cold and the SoC of the LV battery 216 is high, the start of the engine 212 in the engine start / stop schedule 222 can be set later in time. This can be advantageous because the user can return to the vehicle 102 and manually start the vehicle before the scheduled start time in the engine start / stop schedule 222, thus avoiding an additional engine 212 start.

[0070] In another example, the vehicle 102 can determine the expected time the user is away from the vehicle 102. This can be inferred by analyzing the historical usage patterns of the vehicle 102 and / or user input. For example, similar to as described above, the vehicle 102 can use ML techniques to determine the expected time at the stop position. Again, this can be advantageous because the user can return to the vehicle 102 and manually start the vehicle before the start time, thus avoiding an additional engine 212 start.

[0071] At operation 522, the vehicle 102 determines whether user confirmation is required to allow starting the engine 212. For example, if the location of the vehicle 102 is subject to local guidelines that require the vehicle 102 to confirm before starting the engine 212, control goes to operation 524 to receive the confirmation. Or, if it is determined that the location of the vehicle 102 may be indoors, control goes to operation 524 to receive the confirmation. Or, if the settings 220 of the vehicle 102 require the vehicle 102 to confirm before starting the engine 212, control proceeds to operation 524. Or, if the settings 220 define the maximum amount of running time for the engine 212 to generate additional energy, confirmation may be required to override this maximum and / or to warn the user that the full amount of energy expected for charging the user device 104 is not available.

[0072] At operation 524, the vehicle 102 displays an interface for confirming charging of the user device 104. This interface can be used to receive consent to activate the engine 212 when the vehicle 102 is off. An example of such an interface is the one above regarding Figure 3The user interface 300 under discussion. In some examples, the vehicle 102 displays an interface for confirming settings 220 for changing the user device 104. An example of such an interface is the user interface 400 discussed above, which can also be activated by pressing the settings control 318 that agrees to the user interface 300. Figure 4 The user interface 400 under discussion, which can also be activated by pressing the settings control 318 that agrees to the user interface 300.

[0073] At operation 526, the vehicle 102 determines whether consent is received. If the user provides consent to activate the engine 212, for example, by selecting the allow control 408, the control proceeds to operation 528 to execute the engine start / stop schedule 222 for the determined engine 212 start, and then proceeds to operation 530 to charge the user device 104 via the device port 106. The vehicle 102 can charge the user device 104 according to the approved settings 220 accordingly. If consent is not received, the process 500 ends without charging the user device 104.

[0074] Variations of the process 500 are possible. In an example, if the vehicle 102 identifies that the user device 104 is connected to the vehicle 102 when traveling to a specific location, the vehicle 102 can pre - charge the LV battery 216 to a higher set point / SoC to allow for a large initial buffer.

[0075] In another example, if the engine 212 is expected to be required for charging, the vehicle 102 can offer the customer the option of the engine 212 operating to charge the user device 104 based on different user device 104 SoC levels or the amount of time it takes to charge the user device 104. For example, for illustrative purposes only, the HMI 112 can indicate that charging the user device 104 for thirty minutes may require X minutes of engine 212 runtime, Y gallons of fuel, etc. Alternatively, the HMI 112 can indicate that charging the user device 104 to 80% SoC may require Z minutes of engine 212 runtime. For example, in terms of engine idle time, 12V SoC, the SoC of the user device 104, etc., the customer can be notified of the implications of the presented solution via the HMI 112. If there are multiple possibilities, the customer can use the HMI 112 to indicate their choice from the presented information.

[0076] In another example, the HMI 112 can present the option of charging the user device 104 as much as possible without starting the engine 212 (for example, where factors such as depth of discharge / LV battery 216 SoC / LV battery 216 discharge capacity can be limiting factors).

[0077] In another example, vehicle 102 may delay starting engine 212 or delay charging the device after engine 212 starts until engine 212 operates in a more efficient state to reduce stress on LV battery 216.

[0078] In another example, the priority of charging of user device 104 may be specified by the user to enable / disable the feature, e.g., always charge when possible or selectively charge to reduce fuel consumption and / or extend battery life.

[0079] In another example, settings 220 may define multiple different SoC charging thresholds for each user device 104. For example, if vehicle 102 is expected to be driven soon, it may charge the device to a first SoC and wait until vehicle 102 is driven until charging to a second SoC. The SoC may be defined by the user or may be based on the charging time of the device and the expected driving time.

[0080] In another example, if the SoC of LV battery 216 is high and can support charging of user device 104 and / or operation for an extended period (e.g., at least one hour), then vehicle 102 may defer any engine 212 start in hopes of allowing the user to return to drive vehicle 102 away. The threshold time for deferring engine 212 start may be modified in settings 220.

[0081] In another example, if the total engine 212 run time is above a predefined threshold, then vehicle 102 may communicate the engine 212 run time to the user to enable the user to make a decision on whether to charge user device 104 to a lower level or limit the run time of engine 212.

[0082] In another example, if starting engine 212 is required to charge user device 104, then vehicle 102 may select when to start engine 212 to minimize the number of starts of engine 212 and / or the total engine 212 run time and minimize the number of cold starts of engine 212. If engine 212 is already warm and LV battery 216 has a low charge and / or can be charged to a higher level, or if LV battery 216 has a degraded health and / or minimal discharge capacity (e.g., due to cold weather for example), then vehicle 102 may start engine 212 and charge LV battery 216 and user device 104 simultaneously. In many examples, it may be preferable to extend the idle time before turning off engine 212 and it is more recommended than restarting later.

[0083] In another example, the LV battery 216 can also be charged to a SoC higher than normal. For example, if 80% is the default value for the LV battery 216, the LV battery 216 can be charged to a higher SoC, such as 85% or 90%, because the user device 104 will consume this excess SoC to charge its device battery 218.

[0084] Figure 6 An example computing device 602 for use in charging a user device 104 in a vehicle 102 is shown. Refer to Figure 6 And refer to Figures 1 to 5 , the vehicle 102, the user device 104, the HMI 112, the vehicle controller 202, the device controller 204, the BCM 208, and the PCM 210 generally include computer-executable instructions, where the instructions can be executed by one or more computing devices 602. The computer-executable instructions can be compiled or interpreted according to computer programs created using various programming languages and / or technologies, which alone or in combination include but are not limited to Java TM , C, C++, C#, Visual Basic, JavaScript, Python, JavaScript, Perl, etc. Generally speaking, a processor (e.g., a microprocessor) receives instructions, for example, from a memory, a computer-readable medium, etc., and executes these instructions, thereby performing one or more processes, including one or more of the processes described herein. Such instructions and other data (such as signals transmitted through the data connection 110 and settings 220 for charging the user device 104) can be stored and transmitted using various computer-readable media.

[0085] As shown, the computing device 602 can include a processor 604, which is operatively connected to a storage device 606, a network device 608, an output device 610, and an input device 612. It should be noted that this is only an example, and a computing device 602 with more, fewer, or different components can be used.

[0086] The processor 604 may include one or more integrated circuits that implement the functionality of a central processing unit (CPU) and / or a graphics processing unit (GPU). In some examples, the processor 604 is a system-on-chip that integrates the functionality of the CPU and GPU. The SoC may optionally include other components (such as, for example, the storage device 606 and the network device 608) into a single integrated device. In other examples, the CPU and GPU are connected to each other via a peripheral connection device (such as, Peripheral Component Interconnect (PCI) Express) or another suitable peripheral data connection. In one example, the CPU is a commercially available central processing device that implements an instruction set, such as one of the x86, ARM, Power, or Microprocessor without Interlocked Pipeline Stages (MIPS) instruction set families.

[0087] Regardless of the details, during operation, the processor 604 executes stored program instructions retrieved from the storage device 606. The stored program instructions accordingly include software that controls the operation of the processor 604 to perform the operations described herein. The storage device 606 may include both non-volatile memory and volatile memory devices. The non-volatile memory includes solid-state memory, such as NAND flash memory, magnetic and optical storage media, or any other suitable data storage device that retains data when the system is deactivated or loses power. The volatile memory includes static and dynamic random access memory (RAM) that stores program instructions and data during the operation of the system 100.

[0088] The GPU may include hardware and software for displaying at least two-dimensional (2D) and optionally three-dimensional (3D) graphics to the output device 610. The output device 610 may include a graphics or visual display device, such as an electronic display screen, a projector, a printer, or any other suitable device that reproduces a graphical display. As another example, the output device 610 may include an audio device, such as speakers or headphones. As yet another example, the output device 610 may include a tactile device, such as a mechanically raiseable device that, in one example, may be configured to display Braille or another physical output that can be touched to provide information to the user.

[0089] The input device 612 may include any of a variety of devices that enable the computing device 602 to receive control input from a user. Examples of suitable input devices 612 for receiving human-machine interface input may include a keyboard, a mouse, a trackball, a touch screen, a microphone, a graphics tablet, and the like.

[0090] The network devices 608 may each include any of a variety of devices that enable the described components to send and / or receive data over a network from an external device. Examples of suitable network devices 608 include Ethernet interfaces, Wi-Fi transceivers, cellular transceivers, or Bluetooth or Bluetooth Low Energy (BLE) transceivers, or other network adapters or peripheral interconnect devices that receive data from another computer or external data storage device, which may be useful for receiving large amounts of data in an efficient manner.

[0091] Regarding the processes, systems, methods, heuristics, etc. described herein, it should be understood that although the steps of such processes, etc. have been described as occurring in accordance with a certain ordered sequence, such processes may be practiced by performing the described steps in a different order than that described herein. It should also be understood that certain steps may be performed simultaneously, other steps may be added, or certain steps described herein may be omitted. In other words, the description of the processes herein is provided for the purpose of illustrating particular embodiments and should in no way be construed as limiting the claims.

[0092] Accordingly, it should be understood that the above description is intended to be illustrative and not restrictive. Many embodiments and applications other than the examples provided will be apparent upon reading the above description. The scope should not be determined with reference to the above description, but rather should be determined with reference to the appended claims and the entire scope of equivalents to which such claims are entitled. It is expected and anticipated that the technologies discussed herein will evolve in the future, and the disclosed systems and methods will be incorporated into such future embodiments. In summary, it should be understood that this application is capable of modification and variation.

[0093] All terms used in the claims are intended to be given their broadest reasonable construction and their ordinary meaning as understood by one of ordinary skill in the art of the technologies described herein, unless an explicit contrary indication is given herein. Specifically, unless the claims recite an express limitation to the contrary, the use of singular articles such as "a," "the," "said," etc. should be construed to recite one or more of the indicated elements.

[0094] A summary of the present disclosure is provided to allow the reader to quickly ascertain the nature of the technical disclosure. It should be understood that the summary will not be used to interpret or limit the scope or meaning of the claims. Additionally, in the foregoing detailed description, it can be seen that for the purpose of streamlining the present disclosure, various features are grouped together in various embodiments. This method of the present disclosure should not be construed as reflecting an intention that the claimed embodiments require more features than are expressly recited in each claim. Rather, as reflected in the appended claims, the inventive subject matter lies in less than all of the features of a single disclosed embodiment. Accordingly, the appended claims are hereby incorporated into the detailed description, where each claim stands on its own as a separately claimed subject matter.

[0095] Although the above describes exemplary embodiments, these embodiments are not intended to describe all possible forms of the present disclosure. Rather, the words used in this specification are descriptive words rather than restrictive words, and it should be understood that various changes can be made without departing from the spirit and scope of the present disclosure. Additionally, the features of various embodiments can be combined to form other embodiments of the present disclosure.

[0096] According to the present invention, there is provided a vehicle for charging a user device, the vehicle having: a device port configured to supply power from a low-voltage (LV) battery of the vehicle to a device battery of a connected user device; and one or more controllers configured to estimate an energy consumption required to charge the connected user device based on a state of charge (SoC) of the device battery; charge the connected user device during key-off in response to an expected SoC of the LV battery exceeding a calibrated energy threshold amount after providing the energy consumption; and otherwise generate additional energy to charge the connected user device using an engine start / stop schedule defining a time to start an engine of the vehicle and a duration of operation of the engine, thereby ensuring that the LV battery remains above the calibrated energy threshold amount.

[0097] According to one embodiment, the one or more controllers are further configured to charge the connected user device during key-off until the LV battery reaches the calibrated energy threshold amount in response to the expected SoC exceeding the calibrated energy threshold amount and the vehicle being unable to start the engine.

[0098] According to one embodiment, the one or more controllers are further configured to display a consent prompt on a human-machine interface (HMI) to confirm permission for the engine to run for the duration of the operation time in response to the duration of the operation time of the engine exceeding a predefined threshold time amount.

[0099] According to one embodiment, the one or more controllers are further configured to determine the presence of the connected user device by monitoring a discharge current at the device port.

[0100] According to one embodiment, the one or more controllers are configured to receive information indicating the SoC of the device battery through a data connection between the connected user device and the one or more controllers.

[0101] According to one embodiment, one or more controllers are further configured to: determine the position of the vehicle using a Global Navigation Satellite System (GNSS) controller; display a consent prompt to a Human Machine Interface (HMI) in response to the position requiring user input to confirm that the vehicle can be remotely started during key-off; and utilize an engine start / stop schedule in response to receiving permission to start the engine during key-off via the consent prompt.

[0102] According to one embodiment, one or more controllers are further configured to: detect the presence of a connected user device during key-on of the vehicle; and charge the LV battery to a SoC level that exceeds the default key-off SoC of the LV battery to increase the expected SoC of the LV battery during key-off.

[0103] According to one embodiment, one or more controllers are further configured to: postpone the start time of an engine start / stop schedule until a predefined minimum time period from key-off in response to an expected future trip of the vehicle.

[0104] According to one embodiment, one or more controllers are further configured to display a settings interface to the HMI, the settings interface allowing configuration of one or more of the following: the start time of the engine for an engine start / stop schedule; the run time of the engine for an engine start / stop schedule; the SoC for charging a connected user device; or the SoC for charging the LV battery.

[0105] According to one embodiment, the settings interface further includes an option to charge the connected user device as much as possible without starting the engine.

[0106] According to one embodiment, one or more controllers are further configured to: display multiple options in an engine start / stop schedule to the HMI, each option indicating a different device SoC level or amount of time for charging a connected user device; receive a selection of one of the multiple options; and charge the connected user device using the engine start / stop schedule based on the selected option of the multiple options.

[0107] According to the present invention, a method for charging a user device includes: estimating an energy consumption required to charge a connected user device based on a state of charge (SoC) of a device battery of the user device connected to a device port of a vehicle; charging the connected user device during key-off in response to an expected SoC of an LV battery of the vehicle exceeding a calibrated energy threshold amount after providing the energy consumption; and otherwise generating additional energy to charge the connected user device by using an engine start / stop schedule defining a time to start an engine of the vehicle and a duration of operation of the engine, thereby ensuring that the LV battery remains above the calibrated energy threshold amount.

[0108] In one aspect of the present invention, the method includes: charging the connected user device during key-off until the LV battery reaches the calibrated energy threshold amount in response to the expected SoC exceeding the calibrated energy threshold amount and the vehicle being unable to start the engine.

[0109] In one aspect of the present invention, the method includes: displaying a consent prompt to a human-machine interface (HMI) to confirm permission to run the engine for the duration of the operation time in response to the duration of the operation time of the engine exceeding a predefined threshold time amount.

[0110] In one aspect of the present invention, the method includes one or more of the following: determining the presence of a connected user device by monitoring a discharge current at the device port; determining the presence of the connected user device via a data connection to the connected user device connected to the device port; and / or receiving information indicating the SoC of the device battery via the data connection.

[0111] In one aspect of the present invention, the method includes: using a global navigation satellite system (GNSS) controller to determine a location of the vehicle; displaying a consent prompt to a human-machine interface (HMI) in response to the location requiring user input to confirm that the vehicle can be remotely started during key-off; and utilizing the engine start / stop schedule in response to receiving permission to start the engine during key-off via the consent prompt.

[0112] In one aspect of the present invention, the method includes: detecting the presence of a connected user device during key-on of the vehicle; and charging the LV battery to an SoC level exceeding a default key-off SoC of the LV battery to increase the expected SoC of the LV battery during key-off.

[0113] In one aspect of the present invention, the method includes: displaying a settings interface to an HMI, the settings interface allowing configuration of one or more of the following: a starting time of an engine for an engine start / stop schedule; an operating time of the engine for the engine start / stop schedule; a SoC for charging a connected user device; a SoC for charging an LV battery; and / or an option to charge a connected user device as much as possible without starting the engine.

[0114] In one aspect of the present invention, the method includes: displaying, to an HMI, a plurality of options in an engine start / stop schedule, each option indicating a different device SoC level or amount of time for charging a connected user device; receiving a selection of one of the plurality of options; and charging the connected user device using the engine start / stop schedule based on the selected option of the plurality of options.

[0115] According to the present invention, there is provided a non-transitory computer-readable medium having instructions for charging a user device, the instructions, when executed by one or more controllers of a vehicle, causing the one or more controllers to perform operations including: a consumption amount of energy required to charge the user device based on a state of charge (SoC) of a device battery of the user device connected to a device port of the vehicle; charging the connected user device during key-off in response to an expected SoC of an LV battery of the vehicle exceeding a calibrated energy threshold amount of the LV battery after providing the consumption amount of energy; charging the connected user device during key-off until the LV battery reaches the calibrated energy threshold amount in response to the expected SoC exceeding the calibrated energy threshold amount and the vehicle not being authorized to start an engine of the vehicle; and otherwise generating additional energy to charge the connected user device using an engine start / stop schedule defining a duration of a time to start the engine of the vehicle and an operating time of the engine, thereby ensuring that the LV battery remains above the calibrated energy threshold amount.

Claims

1. A vehicle for charging a user device, comprising: a device port configured to provide power from a low voltage (LV) battery of the vehicle to a device battery of a connected user device; as well as One or more controllers, the one or more controllers being configured to: estimating an amount of energy consumption required to charge the connected user device based on a state of charge (SoC) of a battery of the device; charging the connected user device during key-off in response to an expected SoC of the LV battery exceeding a calibrated threshold amount of energy of the LV battery after providing the consumed amount of energy; and Otherwise additional energy is generated to charge the connected user device using an engine start / stop schedule that defines when to start the vehicle's engine and the duration of the engine's run time, thereby ensuring that the LV battery remains above the calibrated energy threshold amount.

2. A vehicle as described in claim 1, wherein the one or more controllers are further configured to charge the connected user device during a key-off period until the LV battery reaches the calibrated energy threshold amount in response to the expected SoC exceeding the calibrated energy threshold amount and the vehicle is unable to start the engine.

3. A vehicle as described in claim 1, wherein the one or more controllers are further configured to: in response to the duration of the engine's running time exceeding a predefined threshold time amount, display a consent prompt to a human-machine interface (HMI) to confirm that the engine is allowed to run for the duration of the running time.

4. The system of claim 1, wherein the one or more controllers are further configured to do one or more of the following: determining the presence of the connected user device by monitoring the discharge current at the device port; and / or Information indicative of the SoC of the device battery is received via a data connection between the connected user device and the one or more controllers.

5. The vehicle of claim 1, wherein the one or more controllers are further configured to: determining a position of the vehicle using a global navigation satellite system (GNSS) controller; In response to the location requiring user input to confirm that the vehicle can be remotely started during key-off, displaying a consent prompt to a human machine interface (HMI); and The engine start / stop schedule is utilized in response to receiving permission to start the engine during a key-off period via the consent prompt.

6. The vehicle of claim 1, wherein the one or more controllers are further configured to: detecting the presence of the connected user device during key-on of the vehicle; and The LV battery is charged to a SoC level that exceeds a default key-off SoC of the LV battery to increase the expected SoC of the LV battery during a key-off period.

7. The vehicle of claim 1, wherein the one or more controllers are further configured to: Responsive to an expected future travel of the vehicle, a start time of the engine start / stop schedule is postponed until a predefined minimum time period from key-off.

8. The vehicle of claim 1 , wherein the one or more controllers are further configured to display a settings interface to the HMI, the settings interface allowing configuration of one or more of the following: a start time of the engine for the engine start / stop schedule; an operating time of the engine for the engine start / stop schedule; a SoC for charging the connected user device; or A SoC for charging the LV battery. The settings interface also optionally includes an option to charge as much of the connected user device as possible without starting the engine.

9. The vehicle of claim 1, wherein the one or more controllers are further configured to: displaying a plurality of options in the engine start / stop schedule to an HMI, each option indicating a different device SoC level or amount of time to charge the connected user device; receiving a selection of one of the plurality of options; and The connected user device is charged using the engine start / stop schedule based on a selected option from the plurality of options.

10. A method for charging a user device, comprising: estimating a consumption amount of energy required to charge a user device connected to a device port of a vehicle based on a state of charge (SoC) of a device battery of the user device; charging the connected user device during key-off in response to an expected SoC of a LV battery of the vehicle exceeding a calibrated threshold amount of energy of the LV battery after providing the consumed amount of energy; as well as Otherwise additional energy is generated to charge the connected user device using an engine start / stop schedule that defines when to start the vehicle's engine and the duration of the engine's run time, thereby ensuring that the LV battery remains above the calibrated energy threshold amount.

11. The method of claim 10, further comprising: In response to the expected SoC exceeding the calibrated energy threshold amount and the vehicle being unable to start the engine, charging the connected user device during a key-off period until the LV battery reaches the calibrated energy threshold amount.

12. The method of claim 10, further comprising one or more of the following: in response to the duration of the run time of the engine exceeding a predefined threshold amount of time, displaying a consent prompt to a human machine interface (HMI) to confirm permission to operate the engine for the duration of the run time; determining the presence of the connected user device by monitoring a discharge current at a port of the device; determining a presence of the connected user device via a data connection with the connected user device connected to the device port; and / or Information indicative of the SoC of the device battery is received over the data connection.

13. The method of claim 10, further comprising: determining a position of the vehicle using a global navigation satellite system (GNSS) controller; displaying a consent prompt to a human machine interface (HMI) in response to the location requiring user input to confirm that the vehicle can be remotely started during a key-off period; as well as The engine start / stop schedule is utilized in response to receiving permission to start the engine during a key-off period via the consent prompt.

14. The method of claim 10, further comprising: detecting the presence of the connected user device during key-on of the vehicle; as well as The LV battery is charged to a SoC level that exceeds a default key-off SoC of the LV battery to increase the expected SoC of the LV battery during a key-off period.

15. The method of claim 10, further comprising displaying a settings interface to the HMI, the settings interface allowing configuration of one or more of the following: a start time of the engine for the engine start / stop schedule; an operating time of the engine for the engine start / stop schedule; a SoC for charging the connected user device; a SoC for charging the LV battery; an option to charge as much of the connected user device as possible without starting the engine; and / or A plurality of options in the engine start / stop schedule, each option indicating a different device SoC level or amount of time to charge the connected user device.

Images