Search

DE-102025145384-A1 - SYSTEMS AND METHODS FOR PERFORMING AN UPDATE ON A VEHICLE VIA AN AERIAL INTERFACE

DE102025145384A1DE 102025145384 A1DE102025145384 A1DE 102025145384A1DE-102025145384-A1

Abstract

A vehicle is disclosed that includes a battery, memory, and a processor. The battery can provide power to the vehicle, and the memory can store historical vehicle information. The processor can determine that a software update may be available for the vehicle. In response to this determination, the processor can use the historical vehicle information to determine an optimal time to initiate a software update installation in the vehicle to optimize battery usage. The processor can further transmit an installation initiation notification to a server to install the software update at the optimal time.

Inventors

  • Tyler Nicholas Rogers
  • AED M DUDAR

Assignees

  • FORD GLOBAL TECHNOLOGIES, LLC

Dates

Publication Date
20260513
Application Date
20251104
Priority Date
20241113

Claims (15)

  1. Vehicle, comprising: a battery configured to provide power to the vehicle; memory configured to store historical vehicle information; and a processor configured to: determine that a software update is available for the vehicle; determine, in response to the determination that the software update is available and based on historical vehicle information, an optimal time to initiate a software update installation in the vehicle to optimize battery usage; and transmit an installation initiation notification to a server to install the software update at the optimal time.
  2. Vehicle after Claim 1 , wherein the historical vehicle information includes at least one of the following: information associated with periods of time during which a vehicle engine is likely to have residual heat from driving cycles of the vehicle; information associated with periods of time during which the vehicle is likely to be connected to a block heater; or information associated with periods of time during which the vehicle is likely to be parked in an enclosed parking space.
  3. Vehicle after Claim 2 , wherein the optimal time is within at least one of the periods during which the vehicle engine is likely to have residual heat from driving cycles of the vehicle, the periods during which the vehicle is likely to be connected to the block heater, or the periods during which the vehicle is likely to be parked in the enclosed parking space.
  4. Vehicle after Claim 1 , further comprising a sensor system configured to provide inputs to the processor, wherein the processor is further configured to: monitor a vehicle engine coolant temperature based on inputs obtained from the sensor system; compare the vehicle engine coolant temperature with a predefined coolant temperature threshold; and determine the optimal time to initiate the software update installation as a time when the vehicle engine coolant temperature becomes greater than the predefined coolant temperature threshold.
  5. Vehicle after Claim 1 , wherein the processor is further configured to transmit a notification to a user device prompting a vehicle user to park the vehicle in an enclosed parking space if the processor is unable to determine the optimal time based on historical vehicle information.
  6. Vehicle after Claim 1 , wherein the processor is further configured to: obtain the software update from the server in response to the transmission of the installation initiation notification; cause the vehicle to install the software update in response to obtaining the software update; and estimate an initial drop in battery state of charge (SOC) when the vehicle installs the software update.
  7. Vehicle after Claim 6 , wherein the processor is further configured to: obtain update information associated with the software update in response to determining that the software update is available; and estimate the initial drop based on the update information.
  8. Vehicle after Claim 7 , wherein the update information includes information associated with one or more of the following: the total size of a software update file, a transfer rate associated with a wireless network connection between the vehicle and the server, an initial battery SOC prior to software update installation, and a battery age.
  9. Vehicle after Claim 6 , further comprising a vehicle control unit configured to provide inputs to the processor, wherein the processor is further configured to estimate the initial drop based on inputs obtained from the vehicle control unit when the software update installation is complete.
  10. Vehicle after Claim 6 , wherein the memory is further configured to store a mapping of a variety of battery SOC drop values to a variety of ambient temperatures, and wherein the processor is further configured to: determine an expected vehicle engine start time based on a historical vehicle usage pattern in response to determining that the software update is available; determine an estimated ambient temperature at the expected vehicle engine start time based on weather information; correlate the estimated ambient temperature with the mapping; and estimate a second drop in battery SOC at the expected vehicle engine start time based on the correlation.
  11. Vehicle after Claim 10 , wherein the processor is further configured to determine that the vehicle is not parked in an enclosed space, and wherein the processor estimates the second drop when the processor determines that the vehicle is not parked in the enclosed space.
  12. Vehicle after Claim 10 , wherein the processor is further configured to compare the first drop with a predefined SOC drop threshold, and wherein the processor estimates the second drop if the processor determines that the first drop is greater than the predefined SOC drop threshold.
  13. Vehicle after Claim 10 , wherein the processor is further configured to: switch a vehicle engine to ON within a predefined time period after completion of the software update installation in response to the estimation of the first drop and the second drop; and cause the vehicle engine to remain in an ON state until the battery is charged by a SOC value equal to the sum of the first drop and the second drop.
  14. Vehicle after Claim 13 , wherein the processor is further configured to: determine that the battery is charged by the SOC value which is the sum of the first drop and the second drop; and switch the vehicle engine OFF when the battery is charged by the SOC value which is the sum of the first drop and the second drop.
  15. Vehicle after Claim 1 , wherein the processor is further configured to: transmit a user notification to a user device indicating that the software update is available; and obtain a user acknowledgment from the user device in response to the transmission of the user notification; and transmit the installation initiation notification to the server in response to obtaining the user acknowledgment.

Description

AREA OF TECHNOLOGY The present disclosure relates to systems and methods for performing an update on a vehicle via an air interface at an optimal time in order to optimize vehicle battery usage. GENERAL STATE OF THE ART Most modern vehicles have a variety of components and modules that require software updates over time. These updates may be necessary to fix bugs, upgrade existing software to newer versions, add new functionality, and/or for other purposes. Updates can be performed via a physical connection at a vehicle dealership or remotely over-the-air (OTA) via a server. It is well known that energy is consumed from the vehicle's battery when the vehicle installs OTA updates or performs an OTA flash. A system and procedure are needed to optimize battery usage during an OTA flash. SUMMARY The present disclosure describes a vehicle that can optimize vehicle battery usage when the vehicle installs a software update or performs an over-the-air (OTA) flashing. The vehicle can optimize battery usage such that the battery can efficiently start the vehicle's engine when a user starts the vehicle after the OTA flash is complete or the software update has been successfully performed. It is understood that a vehicle battery may consume power or experience a drop in state of charge (SOC) when the vehicle performs the OTA flash. The battery may also consume power or experience a drop in SOC if the vehicle is parked in a cold environment (and not in an enclosed space). The vehicle may implement one or more mitigation measures to ensure that the battery is effectively replenished or that the amount/value of SOC "lost" due to the OTA flash process and the cold environment is compensated for, thus enabling the battery to effectively start the vehicle's engine when the user starts the vehicle after the OTA flash. In some aspects, the vehicle can first determine that a software update may be available on a server for the vehicle. In response to this determination, the vehicle can use historical vehicle usage information to determine an optimal time to perform the over-the-air (OTA) flash or install the software update on the vehicle. For example, the vehicle can determine that the optimal time to perform the OTA flash is within a period during which the vehicle's engine is expected to have residual heat from a driving cycle, a period during which the vehicle is expected to be connected to a block heater, and/or a period during which the vehicle is expected to be parked in an enclosed parking space (determined based on historical vehicle usage patterns/information). In response to determining the optimal time to perform the OTA flash, the vehicle can install and execute the software update at that precise time. In some cases, the vehicle may request user confirmation before installing the software update. Furthermore, the vehicle can perform the OTA flash even when the ignition is off (i.e., when the engine is off). The vehicle can also measure/estimate a state of charge (SOC) drop (or "initial SOC drop") that the battery may experience as a result of the over-the-air (OTA) flash. In some aspects, the vehicle can measure the initial SOC drop based on inputs received from a vehicle control unit. In other aspects, the vehicle can estimate the initial SOC drop based on a variety of parameters, including, but not limited to, the estimated time required to perform the OTA flash, the battery's initial SOC before the OTA flash, battery health conditions, battery age, and/or similar factors. For example, the estimated time required to perform the OTA flash may depend on the size of a software update file, the total number of vehicle components/modules being flashed, a data rate or network strength associated with a wireless network connecting the vehicle and the server, and/or similar factors. The vehicle can also estimate an expected vehicle start time based on historical vehicle usage patterns. In some aspects, the expected vehicle start time can be a future point in time when the user is expected to start the vehicle (e.g., use/drive the vehicle). In response to estimating the expected vehicle start time, the vehicle can estimate an expected ambient temperature at that time based on weather condition information (which the vehicle can obtain from the server or the cloud). The vehicle can also estimate a state of charge (SOC) drop (or a "second SOC drop") that the battery may experience at the expected vehicle start time due to cold weather conditions, if the vehicle is parked outdoors, and/or if the first SOC drop is greater than a predefined SOC threshold. The vehicle can estimate the second SOC drop by correlating the expected ambient temperature with a table or by mapping between a variety of SOC drop values and a variety of ambient temperatures. In response to the determination/estimation of the first and second SOC drops, as described above, the vehicle can automatically start the engine to charge the battery by an SOC val