SYSTEMS AND METHODS FOR PERFORMING AN UPDATE ON A VEHICLE VIA AN AERIAL INTERFACE

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.

Description

AREA OF TECHNOLOGY

[0001] 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

[0002] 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

[0003] 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.

[0004] 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.

[0005] 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).

[0006] 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).

[0007] 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 obtained 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.As one 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 for which the OTA flash is performed, the transmission rate or network strength associated with a wireless network connecting the vehicle and the server, and / or similar factors.

[0008] 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).

[0009] 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.

[0010] 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 value / amount that may be the sum of the first and second SOC drops after the OTA flash process is complete. The vehicle can then turn off the engine once the battery is charged or balanced by the SOC value / amount described above. This ensures that the battery has sufficient SOC to start the engine when the user starts the vehicle at the expected start time.

[0011] The present disclosure reveals a vehicle that can install and execute a software update at an optimal time in such a way as to optimize vehicle battery usage. The vehicle can furthermore automatically start the vehicle engine after an OTA flash to compensate for the state of charge (SOC) drop caused by the OTA flash and the SOC drop the battery is expected to experience due to cold ambient weather conditions. These mitigation measures / steps can enable the battery to effectively start the vehicle engine when the user starts the vehicle after an OTA flash.

[0012] These and other benefits of the present revelation are provided in detail in this document. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] The detailed description is set forth with reference to the accompanying drawings. The use of the same reference numerals may indicate similar or identical elements. Different embodiments may use different elements and / or components than those illustrated in the drawings, and some elements and / or components may not be present in different embodiments. The elements and / or components in the figures are not necessarily drawn to scale. Throughout this disclosure, singular and plural expressions may be used interchangeably depending on the context. Fig. Figure 1 depicts an environment in which techniques and structures for providing the systems and procedures disclosed herein may be implemented. Fig. Figure 2 shows a block diagram of a system for installing an update on a vehicle over an air interface (OTA) according to the present disclosure. Fig. Figure 3 shows an exemplary diagram between ambient temperature and time according to the present disclosure. Fig. 4A and Fig. Figure 4B shows a flowchart of an exemplary procedure for installing an OTA update on a vehicle according to the present disclosure. DETAILED DESCRIPTION

[0014] The disclosure is described in more detail below in this document with reference to the accompanying drawings, which show exemplary embodiments of the disclosure, and is not intended to be restrictive.

[0015] Fig. Figure 1 represents an environment 100 in which techniques and structures for providing the systems and procedures disclosed herein can be implemented. The environment 100 can include a vehicle 102 and a server 104 (or a remote computing device), which can be communicatively coupled. The vehicle 102 can take the form of any passenger or commercial vehicle, such as a car, a work vehicle, a crossover vehicle, a truck, a van, a minivan, a taxi, a bus, etc. The vehicle 102 can be manually driven or configured to operate in a semi- or fully autonomous mode. Furthermore, the vehicle 102 can include any powertrain, such as a gasoline engine or a hybrid system.

[0016] The Vehicle 102 may contain a variety of components / modules that may require software updates over time. Examples of such components / modules include, but are not limited to, a powertrain system, a chassis system, a driver assistance system (DAS), an infotainment system, and / or similar components. Updates may be necessary to upgrade existing systems to newer versions, correct bugs, add new features / functionality, and so on.

[0017] The vehicle 102 can remotely obtain / download a software update file (or "over an air interface" (OTA)) from the server 202 and can install and execute the software update file to perform the software update for the vehicle components / modules. In this disclosure, the steps of obtaining, installing, and executing the software update file in the vehicle 102 are collectively referred to as performing an "OTA update" or an "OTA flash" (or OTA flashing).

[0018] In some aspects, the vehicle can draw 102% energy from a vehicle battery (in Fig. 2 (represented as a battery 240) when the vehicle 102 performs the OTA flash. The amount of energy that the vehicle 102 may consume while the OTA flash is being performed can depend on a variety of parameters, including, but not limited to, the estimated time required to perform the OTA flash, the initial state of charge (SOC) of the vehicle battery before the OTA flash, battery health conditions, battery age, and / or the like. For example, the estimated time required to perform the OTA flash may depend on the size of the software update file, the total number of vehicle components / modules being flashed, the data rate or network strength associated with any wireless network connecting the vehicle 102 and the server 104, and / or the like.

[0019] While smaller / shorter software updates may not consume much battery power, larger software updates or those requiring a longer installation time can consume significant battery power, thus severely discharging the vehicle battery. This can lead to a substantial drop in the vehicle battery's state of charge (SOC).

[0020] Vehicle 102 typically performs the OTA flash in a mode with the ignition off, i.e., when the vehicle engine is switched off. Therefore, if there is a significant drop in state of charge (SOC) at the vehicle battery due to the OTA flash, a scenario may occur where a vehicle user (not shown) might be unable to start or start the vehicle engine if the user intends to start and drive / use Vehicle 102 after it has performed the OTA flash. The likelihood of such a scenario occurring may be further increased if Vehicle 102 is located in a geographic area with a cold ambient temperature (and if Vehicle 102 is not parked in an enclosed space).As is well known, a vehicle battery uses more electrical energy (or current) to start a "cold" vehicle engine than a relatively warm one. Therefore, the vehicle battery can experience a drop in performance when the vehicle is in a cold environment, which can lead to a further decrease in the battery's state of charge (SOC).

[0021] The combined drop in battery state of charge (SOC) due to the over-the-air (OTA) flash and the cold environment can adversely affect the likelihood of successfully cranking or starting the vehicle's engine (if the user requires the Vehicle 102 to start). To ensure that the user is able to successfully crank or start the vehicle's engine after the OTA flash is complete, the Vehicle 102 may perform one or more pre- and post-OTA flash mitigation measures, as briefly described below and further detailed in the following sections. Fig. 2 described in detail.

[0022] Vehicle 102 can first determine that an over-the-air (OTA) update or a new software update may be available on server 104 for installation on vehicle 102. In response to such a determination, vehicle 102 can determine an "optimal" time to perform the OTA flash based on historical vehicle information or historical vehicle usage patterns / information (which may be stored in a vehicle memory and / or on server 104). For example, the historical vehicle information may include information related to the duration of time the vehicle user typically drives vehicle 102, the duration of time the vehicle engine is likely to have "residual heat" after the vehicle's driving cycles (e.g.,are associated with the durations when the vehicle 102 returns home after long driving cycles), the durations during which the vehicle 102 is likely to be connected to a block heater, the durations during which the vehicle 102 is likely to be parked in an enclosed space (e.g. in an enclosed garage), etc.

[0023] In some aspects, the vehicle 102 can determine that the optimal time to perform the OTA flash lies within any of the time periods described above. It is understood that the time periods described above are those periods during which the vehicle engine can be warmer than the ambient temperature. The vehicle 102 can decide that the optimal time lies within these periods because the vehicle battery may not require significant additional energy to start or fire up the vehicle engine after the OTA flash if the vehicle engine is warm (compared to a time when the vehicle engine is cold or the vehicle 102 is parked outdoors in a cold ambient temperature).

[0024] In some aspects, the vehicle 102 can, in response to determining the optimal time to perform the OTA flash as described above, send a confirmation notification to a user device (in Fig. 2 (represented as a user device 204) is transmitted, which is associated with the vehicle user. The confirmation notification can include information associated with the specified optimal time, allowing the user to confirm whether they accept or reject the OTA flashing being performed at that specific optimal time. The vehicle 102 can perform the OTA flash at the specified optimal time if the user transmits an confirmation response via the user device. Alternatively, the user can suggest a different time for the OTA flash if they do not accept the specified optimal time (e.g., if they plan to use / drive the vehicle 102 at the specified optimal time).Alternatively, the vehicle 102 can skip this step of obtaining user confirmation and can perform the OTA flash directly at the specified optimal time.

[0025] At the optimal time, the Vehicle 102 can download, install, and run the software update file to perform the software update or OTA flash. After the OTA flash is complete, the Vehicle 102 can perform one or more post-OTA mitigation actions / steps to optimize battery usage, as described below.

[0026] In response to determining that the OTA flash is complete or the software update is successful, the Vehicle 102 can measure / estimate a drop in the vehicle battery's state of charge (e.g., an "initial SOC drop") due to the OTA flash. In other words, in response to determining that the OTA flash is complete, the Vehicle 102 can determine the battery energy or SOC that may have been discharged or consumed to perform the OTA flash. In some aspects, the Vehicle 102 can directly measure the initial SOC drop based on inputs from a vehicle control unit (in the vehicle's electronic control unit). Fig. 2 (represented as a VCU 210). In this case, the vehicle 102 can first determine an initial battery SOC level before performing the OTA flash (i.e., battery SOC level before OTA) and then a real-time battery SOC level after completion of the OTA flash (i.e., post-OTA battery SOC level) based on the inputs obtained from the VCU. The vehicle 102 can determine the initial SOC drop as the difference between the post-OTA and pre-OTA battery SOC levels.

[0027] In other aspects, the Vehicle 102 can estimate the initial state of charge (SOC) drop based on the parameters described above. For example, the Vehicle 102 can estimate the initial SOC drop based on parameters such as the estimated time required to perform the over-the-air (OTA) flash, the initial SOC level of the vehicle battery before the OTA flash, battery health conditions, battery age, and / or similar factors.

[0028] In response to determining the initial state of charge (SOC) drop, as described above, the vehicle 102 may, in some aspects, compare the initial SOC drop to a predefined SOC drop threshold. The vehicle 102 may implement one or more post-OTA mitigation actions / steps if it determines that the initial SOC drop is greater than the predefined SOC drop threshold. In other words, the vehicle 102 may implement one or more post-OTA mitigation actions if the vehicle battery may have experienced a significant drop / consumption of energy / SOC level. In other aspects, the vehicle 102 may skip this comparison step and implement one or more post-OTA mitigation actions / steps regardless of whether the initial SOC drop is greater or less than the predefined SOC drop threshold.

[0029] As part of the post-OTA mitigation measures, Vehicle 102 can initially determine an expected vehicle engine start time based on a historical vehicle usage pattern (which may be part of the historical vehicle information described above). Specifically, in this case, Vehicle 102 can determine, based on the historical vehicle usage pattern, an estimated future time at which the vehicle user is expected to start or switch on the vehicle engine, for example, to drive or use Vehicle 102. In additional or alternative aspects, Vehicle 102 can determine the expected vehicle engine start time based on a pre-programmed drive start time that the vehicle user may have provided to Vehicle 102 in advance. For example, if the user provides an input to Vehicle 102 (e.g.,If the vehicle has provided information (in the vehicle's onboard computer) indicating that the user will begin a journey at 7:00 AM, the vehicle 102 can determine the expected vehicle engine start time as 7:00 AM. In this case, the vehicle 102 can also adjust / optimize the vehicle's interior temperature / climate before the planned journey start time (i.e., by 7:00 AM).

[0030] In response to determining the expected vehicle start time, vehicle 102 can estimate an expected ambient temperature at the expected vehicle start time based on weather condition information that vehicle 102 can obtain from server 202 or the cloud.

[0031] The Vehicle 102 can further estimate an expected state of charge (SOC) drop (or a "second SOC drop") in the vehicle battery due to ambient temperature at the expected vehicle engine start time, based on a mapping between a variety of SOC drop values / levels and a variety of different ambient temperatures. In some aspects, this mapping may be pre-stored in the vehicle memory and / or on the Server 104. In response to the estimated second SOC drop, the Vehicle 102 can turn on or start the vehicle engine within a predetermined time after the OTA flash is complete (if the vehicle engine is still warm, possibly due to the vehicle's driving cycle or connection to the block heater) and initiate charging of the vehicle battery to replenish the first and second SOC drops.Vehicle 102 can keep the vehicle engine in the ON state until the vehicle battery is charged to a state of charge (SOC) level equal to the sum of the first and second SOC drops. After that, Vehicle 102 can switch the vehicle engine to OFF.

[0032] By ensuring the vehicle battery is recharged to compensate for the initial and subsequent state of charge (SOC) drops following the OTA update, the Vehicle 102 ensures that when the vehicle user attempts to start the engine at the expected start time (when the ambient temperature and engine may be cold), the battery has sufficient SOC to successfully start the engine. In this way, the Vehicle 102 offsets the battery consumption (or loss of SOC) due to the OTA flash process and the cold ambient conditions, thus significantly reducing the likelihood of a failed start after the OTA flash.

[0033] Further details of vehicle 102 are listed below in conjunction with Fig. 2 described.

[0034] The Vehicle 102 implements and / or carries out operations as described herein in accordance with the user manual and safety guidelines. Furthermore, any action taken by the vehicle user based on notifications provided by the Vehicle 102 should comply with all regulations specific to the location and operation of the Vehicle 102 (e.g., federal, state, country, city, etc.). The notifications provided by the Vehicle 102 should be treated as suggestions and followed only in accordance with any regulations specific to the location and operation of the Vehicle 102.

[0035] Fig. Figure 2 depicts a block diagram of a system 200 for installing an update over the air (OTA) on the vehicle 102 according to the present disclosure. During the description of Fig. 2 will be on Fig. 3. Referenced.

[0036] The system 200 can include the vehicle 102, one or more servers 202 (or a server 202 that can be the same as the server 104 described above), and a user device 204, which are communicatively coupled to one or more networks 206. The user device 204 can be associated with the vehicle user and can be, for example, a mobile phone, a laptop, a tablet, a smartwatch, or any other similar device with communication capabilities. The server 202 can be part of a cloud-based computing infrastructure and can be associated with and / or include a telematics service delivery network (SDN) that provides the vehicle 102 and other vehicles (in Fig. 2 (not shown), which may be part of a vehicle fleet, provides digital data services.

[0037] In other aspects, the server 202 can store historical vehicle information associated with vehicle 102 and can transmit the historical vehicle information to vehicle 102 at a predefined frequency or when vehicle 102 requests to receive such information.The historical vehicle information may include, for example, information associated with the vehicle's driving and usage patterns, information associated with the durations during which the vehicle user is likely to drive the vehicle 102 (i.e., typically based on historical data), information associated with the durations during which the vehicle engine is likely to have residual heat from the vehicle's driving cycles (i.e., typically based on historical data), information associated with the durations during which the vehicle 102 is likely to be connected to a block heater (i.e., typically based on historical data), information associated with the durations during which the vehicle 102 is likely to be parked in an enclosed parking space (i.e., typically based on historical data), and / or the like, as described above in conjunction with . Fig. 1 described, include.

[0038] The Server 202 can also store a mapping of a variety of battery SOC drop values ​​or power consumption values ​​to a variety of ambient temperatures. For example, the Server 202 can store a mapping or table showing that the vehicle battery typically has an effective SOC drop or power drop of 0% when the ambient temperature (at a location where the vehicle 102 is located) is 80 degrees Fahrenheit, 15% when the ambient temperature is 60 degrees Fahrenheit, 30% when the ambient temperature is 40 degrees Fahrenheit, 35% when the ambient temperature is 32 degrees Fahrenheit, 60% when the ambient temperature is 0 degrees Fahrenheit, 75% at an ambient temperature of -20 degrees Fahrenheit, and / or the like.Server 202 can transmit this mapping / table to vehicle 102 at a predefined frequency or when vehicle 102 requests to receive the mapping.

[0039] Server 202 can additionally store a software update file if a software update may be available for vehicle 102. In some cases, a vehicle manufacturer can provide the software update file to Server 202 if the software update may be available for one or more vehicle components or modules. Server 202 can transfer the software update file to vehicle 102 (for execution on vehicle 102) when Server 202 receives an installation initiation notification from vehicle 102.

[0040] The network(s) 206 illustrate(s) an exemplary communication infrastructure in which the connected devices discussed in various embodiments of this disclosure can communicate. The network(s) 206 may be and / or include the Internet, a private network, a public network, or another configuration operating using one or more of any known communication protocols, such as Transmission Control Protocol / Internet Protocol (TCP / IP), Bluetooth, or similar technologies. ®Bluetooth Low Energy (BLE), Wi-Fi based on the Institute of Electrical and Electronics Engineers (IEEE) standard 802.11, Ultra Wideband (UWB) and mobile communication technologies such as Time Division Multiple Access (TDMA), Code Division Multiple Access (CDMA), High-Speed ​​Packet Access (HSPDA), Long-Term Evolution (LTE), Global System for Mobile Communications (GSM) and Fifth Generation (5G), to name a few examples.

[0041] The vehicle 102 can include a variety of units, including, but not limited to, a vehicle computer 208, a vehicle control unit (VCU) 210, and an OTA update unit 212 (or unit 212). The VCU 210 can include a variety of electronic control units (ECUs) 214, which communicate with the vehicle computer 208.

[0042] In some aspects, the vehicle computer 208 and / or the unit 212 can be installed at any location in the vehicle 102 in accordance with the disclosure. Furthermore, the vehicle computer 208 can be operated as a functional component of the unit 212. The vehicle computer 208 can be or include an electronic vehicle control unit comprising one or more processor(s) 216 and a memory 218. In addition, the unit 212 can be separate from the vehicle computer 208 (as in Fig. 2 shown) or integrated as part of the vehicle computer 208.

[0043] The processor(s) 216 can communicate with one or more storage devices connected to the respective computing systems (e.g., the memory 218 and / or one or more external databases located in Fig. (2 not shown) are in communication. The processor(s) 216 can / can use the memory 218 to store programs as code and / or to store data for performing aspects according to the disclosure. The memory 218 can be a persistent computer-readable medium or persistent computer-readable memory on which an OTA update program code is stored. The memory 218 can include any or a combination of volatile memory elements (e.g., dynamic random-access memory (DRAM), synchronous dynamic random-access memory (SDRAM), etc.) and can include any or more non-volatile memory elements (e.g., erasable programmable read-only memory (EPROM), flash memory, electronically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), etc.).

[0044] According to some aspects, the VCU 210 can share a power bus with the vehicle computer 208 and can be configured and / or programmed to transmit data between systems of the vehicle 102, connected servers (e.g., the server(s) 202), and other vehicles (in Fig. 2 (not shown), which are operated as part of a vehicle fleet. The VCU 210 can include or communicate with any combination of the ECUs 214, such as a Body Control Module (BCM) 220, an Engine Control Module (ECM) 222, a Transmission Control Module (TCM) 224, a Telematics Control Unit (TCU) 226, a Driver Assistance Technologies (DAT) 228, etc.

[0045] The VCU 210 may also include and / or communicate with a Vehicle Perception System (VPS) 230, which has connectivity to and / or controls one or more vehicle sensor systems 232. The vehicle sensor system 232 may include one or more vehicle sensors, including, but not limited to, a radio detection and ranging (radar) sensor configured to detect and locate objects inside and outside the vehicle 102 using radio waves, seat belt buckle sensors, seat area sensors, a light detection and ranging (lidar) sensor, door sensors, proximity sensors, temperature sensors, wheel sensors, ambient weather sensors, ambient light sensors, vehicle interior and exterior cameras, one or more rain sensors, a humidity sensor, a tire pressure sensor, ultrasonic sensors, etc.In some aspects, the vehicle sensor system 232 can measure the vehicle engine coolant temperature with a predefined frequency.

[0046] In some aspects, the VCU 210 can control operational aspects of the vehicle and implement one or more instruction sets received from the user device 204 from one or more instruction sets stored in the memory 218, which include instructions that are operational as part of the unit 212.

[0047] The TCU 226 can be configured and / or programmed to provide vehicle connectivity with wireless computing systems inside and outside the vehicle 102, and can include a navigation (NAV) receiver 234 for receiving and processing a GPS signal, a BLE module (BLEM) 236, a WLAN transceiver, a UWB transceiver and / or other wireless transceivers (in Fig. 2 (not shown) include components that can be configured for wireless communication (including cellular communication) between the vehicle 102 and other systems (e.g., the user device 204, a radio key, an NFC device, etc.), computers, and modules. The NAV receiver 234 can be configured to determine the vehicle's real-time geolocation. The TCU 226 can communicate with the ECUs 214 via a bus.

[0048] The ECUs 214 can control aspects of vehicle operation and communication using inputs from human drivers, inputs from a controller of an autonomous vehicle, the unit 212 and / or via wireless signal inputs received via the wireless link(s) from other connected devices, such as, among others, the user device 204, the server(s) 202.

[0049] The BCM 220 generally integrates sensors, vehicle performance indicators, and variable throttles associated with vehicle systems. It may include processor-based power distribution circuits that control body-related functions such as lights, windows, security, camera(s), fans, headlights, audio system(s), speakers, windshield wipers, door locks and access control, mirrors, various comfort controls, body panels, and the like. The BCM 220 can also operate as a gateway for bus and network interfaces to communicate with remote ECUs (in Fig. 2 not shown) to interact.

[0050] The DAT 228 controller can provide Level 1 to Level 3 automated driving and driver assistance functionality, which may include, for example, active parking assistance, reverse parking assistance, and adaptive cruise control, among other features. The DAT 228 controller can also provide aspects of user and environmental input that can be used for user authentication.

[0051] In some aspects, the vehicle computer 208 can connect to an infotainment system 238 (or a human-machine interface (MMS) 238 of the vehicle). The infotainment system 238 can include a touchscreen interface section and can include voice recognition features and biometric identification capabilities that can identify users based on facial recognition, voice recognition, fingerprint identification, or other biological identification methods. In other aspects, the infotainment system 238 can also be configured to receive user instructions / inputs via the touchscreen interface section and / or to display notifications / recommendations, navigation maps, etc., on the touchscreen interface section.

[0052] The vehicle 102 may also include a battery 240, which can provide power to one or more vehicle components. In some aspects, the battery 240 can provide power / energy to start the vehicle engine when the vehicle engine is started from an idle or OFF state.

[0053] In the computer system architecture of the vehicle computer 208, the VCU 210 and / or the unit 212, certain computing modules may be omitted. It goes without saying that the in Fig. The computing environment shown in Figure 2 is an example of a possible implementation according to the present disclosure and should therefore not be considered restrictive or exclusive.

[0054] According to some aspects, the unit 212 can be integrated into the ECUs 214 and / or implemented as part of them. Regardless of whether it is integrated into the vehicle computer 208 or the ECUs 214, or operated as an independent computing system in the vehicle 102, the unit 212 can include a transceiver 242, a processor 244, and computer-readable memory 246.

[0055] The transceiver 242 can receive information / input from one or more external devices or systems, such as the user device 204, the server(s) 202, and / or the like, via the network 206. For example, the transceiver 242 can receive historical vehicle information, the mapping of a variety of battery SOC drop values ​​to a variety of ambient temperatures, the software update file, and / or the like from the server 202 via the network 206. Furthermore, the transceiver 242 can transmit notifications to the external devices or systems. In addition, the transceiver 242 can receive information / input from components of the vehicle 102, such as the infotainment system 238, the VCU 210, and / or the like. Furthermore, the transmitter / receiver 242 can send notifications / command signals to the components of the vehicle 102, such as the VCU 210, the vehicle engine, the infotainment system 238, etc., transmitted.

[0056] The processor 244 and the memory 246 can be the same as or similar to the processor 216 and the memory 218, respectively. In some aspects, the processor 244 can use the memory 246 to store programs as code and / or data for performing aspects in accordance with the disclosure. The memory 246 can be a persistent, computer-readable medium or persistent, computer-readable memory on which the OTA update program code is stored. In some aspects, the memory 246 can store the historical vehicle information, the mapping of a variety of battery SOC dropout values ​​to a variety of ambient temperatures, and the software update file that the vehicle 102 obtains from the server 202.

[0057] During operation, the processor 244 can first determine that the software update for the vehicle 102 may be available on the server 202. In some aspects, the processor 244 can determine that the software update may be available on the server 202 based on an update availability notification that the vehicle 102 may receive from the server 202 when the server 202 has the software update for the vehicle 102. In response to determining that the software update may be available for the vehicle 102, the processor 244 can determine an optimal time to initiate a software update installation in the vehicle 102 in order to optimize the use of the battery 240 based on historical vehicle information (which may be stored in the memory 246, as described above).

[0058] As an example, processor 244, using historical vehicle information (especially the historical vehicle usage pattern), can determine the optimal time as a time when the vehicle engine is expected to have residual heat from a previous driving cycle. For example, if vehicle 102 is expected to arrive at the user's home at 6:00 PM after a long drive (determined based on historical vehicle information / historical vehicle usage pattern), processor 244 can determine the optimal time to initiate the software update installation as 6:10 PM or 6:15 PM, when the vehicle engine may still be warm due to the vehicle's driving cycle.Selecting such a time to perform the software update installation or OTA flash allows the 244 processor to efficiently perform the post-OTA mitigation measures / steps described later in the description below.

[0059] As another example, using historical vehicle information, processor 244 can determine the optimal time as the point at which the vehicle user is expected to connect vehicle 102 to a block heater (which can cause the vehicle engine to warm up). Furthermore, processor 244 can receive input from the vehicle sensor system 232 and monitor a real-time vehicle engine coolant temperature based on the input received from the vehicle sensor system 232 (e.g., when vehicle 102 can be connected to the block heater).The Processor 244 can also compare the real-time vehicle engine coolant temperature with a predefined coolant temperature threshold and determine the optimal time to initiate the software update installation / OTA flash as the point at which the vehicle engine coolant temperature exceeds the predefined coolant temperature threshold. In other words, the Processor 244 can determine the optimal time in this case as the point at which the vehicle engine warms up.

[0060] As yet another example, using historical vehicle information, processor 244 can determine the optimal time as a time when vehicle 102 can be parked in an enclosed space (e.g., an enclosed parking structure, a garage, etc.) where the temperature may be warmer than the ambient temperature outside (which may result in the vehicle engine remaining relatively warm).

[0061] In some aspects, if the processor 244 is unable to determine the optimal time using the historical vehicle information as described above, it can transmit a notification to the user device 204 via the transmitter-receiver 242, requesting the vehicle user to park the vehicle 102 in an enclosed parking space.

[0062] In response to determining the optimal time, as described above, or in response to determining that the software update may be available on server 202, processor 244 may, in some aspects, transmit a user notification to user device 204, informing the vehicle user that the software update for vehicle 102 is available. In some aspects, the user notification may include information associated with the determined optimal time. The user may view the user notification and may acknowledge the notification if the user accepts the determined time for the OTA flash. In this case, processor 244 may obtain user acknowledgment from user device 204 in response to the transmission of the user notification.In response to receiving user confirmation, the processor 244 (via the send-receiver 242) can transmit an installation initiation notification to the server 202 to install the software update at the specified optimal time.

[0063] In some aspects, the user can select a different time for the OTA flash in response to receiving the user notification on the user device 204 if the user does not accept the specified optimal time (e.g., if the user plans to use / drive the vehicle 102 at the specified optimal time). In other aspects, in response to determining the optimal time, the processor 244 can skip this step of obtaining user confirmation and can transmit the installation initiation notification directly to the server 202 to install the software update at the specified optimal time.

[0064] Server 202 can transmit the software update file to receiver 242 / processor 244 when server 202 receives the installation initiation notification from processor 244. Processor 244 can then retrieve the software update file from server 202 in response to the transmission of the installation initiation notification and, upon receiving the software update file, can instruct vehicle 102 to install / execute the software update. It is understood that the OTA flash can take anywhere from a few minutes to several minutes, depending on the size of the software update file.

[0065] The processor 244 can also estimate / measure the first SOC drop in the battery 240 when the vehicle 102 installs / performs the software update or when the processor 244 performs the OTA flash. As above in conjunction with Fig. As described in section 1, the initial SOC drop can be associated with battery consumption or the battery SOC drop caused by the execution / installation of the software update (or caused by OTA flashing). In one exemplary aspect, the processor 244 can measure the initial SOC drop based on inputs received from the VCU 210 once the software update installation or OTA flash is complete. In this case, the processor 244 can obtain the inputs associated with the real-time battery SOC before and after the OTA flash and determine the initial SOC drop as the difference between the battery SOC after OTA and the battery SOC before OTA.

[0066] In another exemplary aspect, the processor 244 can estimate the initial SOC depletion based on "update information" associated with the software update. In this case, the processor 244 can obtain the update information from the server 202, one or more vehicle components (e.g., the TCU 226), other vehicles via vehicle-to-vehicle (V2V) communication, and / or the like. The update information can include, for example, information associated with the total size of the software update file, a transfer rate associated with the network 206, an initial battery SOC before the software update installation / OTA flash operation, the battery health, the battery age, and / or the like.The processor 244 can correlate the obtained update information with a data structure that maps a variety of battery SOC drop values ​​to the different parameters included in the update information in order to estimate the initial SOC drop. The data structure described here can be pre-stored in memory 246 and / or server 202, or it can be generated by the processor 244 itself by monitoring battery SOC drop values ​​over time when the vehicle 102 performs an OTA flash, or it can be generated / provided by the vehicle manufacturer.

[0067] In some aspects, Processor 244 can estimate the first SOC drop based on the update information described above as either before or after the OTA flash operation. In one exemplary aspect, Processor 244 can estimate the first SOC drop based on the update information even before the optimal timing is determined. In this case, Processor 244 can estimate the first SOC drop based on the update information in response to determining that the software update is available on Server 202 and can perform the optimal timing step described above if Processor 244 determines that the first SOC drop might be greater than the predefined SOC drop threshold.

[0068] In response to the estimation / measurement of the initial state of charge (SOC) drop using one of the methods described above, the processor 244 can determine the expected vehicle engine start time based on a historical vehicle usage pattern (which may be part of the historical vehicle information) or based on a pre-stored user input indicating when the user intends to drive the vehicle 102. As described above in conjunction with Fig. As described in section 1, the expected vehicle engine start time can be an estimated future time at which the vehicle user is expected to start or turn on the vehicle engine, for example, to drive or use the vehicle 102. In some aspects, processor 244 can determine the expected vehicle engine start time in response to determining that the software update is available on server 202. In other aspects, processor 244 can determine the expected vehicle engine start time when the OTA flash is complete. Furthermore, as described above in conjunction with Fig. As described in section 1, processor 244 determines the expected vehicle engine start time based on a pre-programmed trip start time that the vehicle user may have provided to vehicle 102 in advance. For example, if the user has provided an input to vehicle 102 (e.g., to the vehicle's onboard computer) indicating that the user will begin a trip at 7:00 AM, processor 244 can determine the expected vehicle engine start time to be 7:00 AM. In this case, processor 244 can also adjust / optimize the vehicle's interior temperature / climate before the scheduled trip start time (i.e., by 7:00 AM).

[0069] In response to determining the expected vehicle engine start time, the processor 244 can obtain weather condition information (or weather information) associated with a geographic area where the vehicle 102 is located from the server 202 or any cloud-based computing unit that provides weather condition information. The processor 244 can further determine an estimated ambient temperature at the expected vehicle engine start time based on the obtained weather information. The processor 244 can then retrieve from memory 246 the mapping of a variety of battery state of charge (SOC) dropout values ​​or power consumption values ​​to a variety of ambient temperatures.As described above, the mapping may include a table containing information associated with an expected SOC drop or performance drop in battery 240 due to cold weather at different ambient temperatures.

[0070] Processor 244 can correlate the estimated ambient temperature with the expected vehicle engine start time to estimate the second state of charge (SOC) drop in the battery at that time. As described above, the second SOC drop can indicate the decrease in battery SOC / battery performance due to the cold ambient temperature. In some aspects, the second SOC drop may also depend on the battery's age (and / or battery health). For example, if the battery 240 is old, the second SOC drop may be higher compared to a relatively newer battery (under the same ambient conditions / temperature).

[0071] In some aspects, the processor 244 can estimate the second SOC drop, as described above, when the vehicle is parked outdoors and not in an enclosed space. In this case, the processor 244 can first determine, based on inputs obtained from the vehicle sensor system 232, that the vehicle 102 is not parked in an enclosed space, and can then estimate the second SOC drop. It is understood that if the vehicle 102 is parked in an enclosed space, it may not be exposed to cold ambient temperatures, and therefore the battery 240 may not experience a significant drop in battery SOC due to cold weather conditions (and thus the second SOC drop is expected to be close to zero).

[0072] In additional or alternative aspects, the processor 244 can estimate the second SOC drop described above if the battery 240 may have experienced, or is expected to experience, a significant first SOC drop. In this case, the processor 244 can first compare the first SOC drop with the predefined SOC drop threshold and can estimate the second SOC drop if the processor 244 determines that the first SOC drop is greater than the predefined SOC drop threshold.It is understood that if the battery 240 has experienced, or is expected to experience, a significant initial state of charge (SOC) drop due to the OTA flash, any further battery SOC loss due to cold ambient weather conditions could significantly increase the likelihood of the vehicle engine failing to start when the user attempts to start the vehicle 102 (which could cause inconvenience for the user). To prevent such a scenario from occurring, the processor 244 can estimate the second SOC drop if the first SOC drop is potentially significant (or greater than the predefined SOC drop threshold).

[0073] In response to the determination / estimation of the first and second SOC drops, as described above, the processor 244 can perform one or more post-OTA mitigation measures to ensure that the vehicle 102 successfully starts its engine when the user attempts to start the vehicle 102 at the expected engine start time. Specifically, in response to the determination / estimation of the first and second SOC drops, the processor 244 can perform one or more post-OTA mitigation measures to ensure that the battery 240 has recovered or replenished the energy / SOC that was "lost" (due to the OTA flash operation and cold weather conditions), thus enabling the battery 240 to successfully start the vehicle engine when the user attempts to start the vehicle 102 at the expected engine start time.An example of a post-OTA mitigation measure is described below.

[0074] In some aspects, within a predefined timeframe after the software update installation / OTA flash is complete (while the vehicle engine may still be warm), the processor 244 can switch the vehicle engine ON and keep it running until the battery 240 is charged to a state of charge (SOC) equal to the sum of the first and second SOC drops. The processor 244 can also control a vehicle actuator output to a high charging rate to replenish the battery 240 or charge it to the SOC level described above. This action restores the same amount of charge / energy / SOC that the battery 240 may have lost due to the OTA flash process, as well as the SOC that the battery 240 is expected to consume due to cold weather conditions until the anticipated vehicle start time.As an example, if battery 240 has lost 15% state of charge (SOC) due to the over-the-air (OTA) flash process and is expected to effectively consume another 15% SOC / power by the expected vehicle start time due to cold weather conditions, processor 244 can switch the vehicle engine on to charge battery 240 by 30%. This allows battery 240 to have a SOC above its pre-OTA SOC level, enabling it to successfully start the vehicle engine at the expected start time.

[0075] It is understood that restarting a warm vehicle engine after the OTA flash process can lead to lower battery consumption (240) and ensure successful engine starting. The post-OTA flash battery charging process, as described in this disclosure, is more advantageous than the conventional pre-OTA flash battery charging process. This is because the post-OTA flash battery charging is more deterministic and therefore more accurate with respect to the nature of the actual battery state of charge (SOC) consumption. Topping up or charging a battery before the OTA flash is less deterministic, as the length of the OTA can vary, and consequently, the SOC consumption can also vary.

[0076] In response to determining that battery 240 is charged by the SOC value equal to the sum of the first SOC drop and the second SOC drop (based on the inputs received from VCU 210), processor 244 can switch the vehicle engine off. An example scenario illustrating the operation of processor 244 to perform the OTA flash and switch the vehicle engine on / off is shown in Fig. 3 shown.

[0077] Fig. Figure 3 shows an example diagram 300 between time (represented on the x-axis) and ambient temperature (represented on the y-axis). In the example scenario, which is shown in Fig. As shown in Figure 3, the user can park vehicle 102 at time "T1," when the ambient temperature may be 18 degrees Fahrenheit. In response to the user parking vehicle 102 (or vehicle 102 entering an "ignition off" phase), processor 244 can perform the OTA flash operation at time "T2," when the ambient temperature may be 15 degrees Fahrenheit. In some aspects, the difference between "T2" and "T1" may be small, so the vehicle engine may still be warm due to the vehicle's driving cycle prior to time "T1" (e.g., with a vehicle engine coolant temperature above 100 or 120 degrees Fahrenheit).

[0078] Once the OTA flash is complete, the processor 244 can start the vehicle's engine at time "T3," which may be immediately after the OTA flash is complete or within a short, predefined period afterward. The processor 244 can keep the vehicle's engine running until time "T4," at which point the battery 240 may be charged by the amount of state of charge (SOC) equal to the sum of the first and second SOC drops. The processor 244 can then turn the vehicle's engine off at time "T4" if the battery 240 is charged as described above.

[0079] The processor operation described above ensures that when the user starts the vehicle 102 at a time “T5” (which may be the expected vehicle start time and when the weather in the surrounding area is expected to be cold), the battery 240 has sufficient charge / SOC to successfully start the vehicle engine and so that the user does not experience any inconvenience.

[0080] The processor 244 can perform one or more additional actions to optimize vehicle performance. For example, if the vehicle 102 is parked in an enclosed and closed garage, the processor 244, when it automatically starts or runs the vehicle engine to replenish the battery state of charge (SOC), can receive input from the vehicle sensor system 232 to determine whether the garage door is closed. In response to the determination that the garage door is closed, the processor 244 can send a command signal to a garage door opener to automatically open the garage door when it starts the vehicle engine to replenish the battery SOC. Once the battery SOC is replenished, the processor 244 can turn off the vehicle engine and send a command signal to the garage door opener to automatically close the garage door.

[0081] Furthermore, although the foregoing description is presented in the context of the processor 244 replenishing the battery charge / SOC when the vehicle 102 is in cold ambient temperatures, the present disclosure is not limited to this aspect. In additional aspects, the processor 244 can determine, based on historical or deterministic vehicle information, whether the vehicle 102 will be parked in a temperate climate for an extended period (e.g., vacation mode / parking at the airport for a week or more). It is understood that batteries are subject to parasitic power consumption even when the vehicles are not being driven. In this case as well, the processor 244 can automatically start the vehicle engine in a manner similar to that described above in order to replenish the depleted battery SOC.

[0082] Furthermore, although the foregoing description is given in the context of the processor 244 replenishing the battery charge / SOC due to the OTA flash operation, the present disclosure is not limited to such an aspect. The processor 244 can perform a similar "battery replenishment" operation to compensate for battery charge / energy loss as a result of post-ignition diagnostics, which the vehicle 102 typically performs after the user has parked / switched the vehicle 102 off. It is understood that in most modern vehicles, post-ignition diagnostics are performed to check the status of several vehicle components / modules (e.g., lights, windows, communication modules, etc.). Such post-ignition diagnostics can consume battery energy / charge.The principles / details / processes of recharging the battery charge / SOC, as described in this disclosure, can also be applied to compensate for battery energy loss due to diagnostics after the ignition is switched off, without deviating from the scope of this disclosure. In one exemplary aspect, the processor 244 can recharge the battery SOC consumed due to diagnostics after the ignition is switched off if the drop in battery SOC is potentially greater than a threshold. Furthermore, in this case, the processor 244 can recharge the battery SOC if the battery 240 is potentially aged and / or if the vehicle 102 is potentially in a cold environment or has been parked for a long time.

[0083] The Fig. 4A and Fig. Figure 4B shows a flowchart of an exemplary method 400 for installing an OTA update on the vehicle 102 according to the present disclosure. Fig. 4A and Fig. 4B may be described with continued reference to the preceding figures. The following process is exemplary and is not limited to the steps described below. Furthermore, alternative embodiments may include more or fewer steps than are shown or described in this document, and these steps may be performed in a sequence that differs from the sequence described in the following exemplary embodiments.

[0084] Procedure 400 starts at step 402. At step 404, procedure 400 can determine, via processor 244, whether the OTA update is required. In other words, at step 404, processor 244 can determine whether the software update is available on server 202 for vehicle 102. If no software update is available, procedure 400 can proceed to step 406, where it can end.

[0085] If, however, processor 244 determines at step 404 that the OTA is required, procedure 400 can proceed to step 408, where processor 244 can determine whether the vehicle engine is warm due to a driving cycle or whether the vehicle 102 is connected to a block heater. In some aspects, processor 244 can perform step 408 at the optimal time described above. In other aspects, processor 244 can perform step 408 whenever processor 244 determines that the OTA is required.

[0086] Procedure 400 can proceed to step 410 if processor 244 determines that the vehicle engine is not warm and vehicle 102 is not connected to a block heater. In step 410, processor 244 can transmit a user notification to user device 204, prompting the user to park vehicle 102 in an enclosed space. In response to the user parking vehicle 102 in the enclosed space, processor 244 can perform the OTA flash. Procedure 400 can then proceed to step 406.

[0087] Otherwise, procedure 400 can proceed to step 412 if, at step 408, processor 244 determines that the vehicle engine is warm or that vehicle 102 is connected to a block heater. At step 412, processor 244 can schedule / execute the OTA flash shortly (or within a short predefined time) after the vehicle's ignition is switched off, when the engine might still be warm or when vehicle 102 might be connected to the block heater. Processor 244 can then, at step 414, continuously check / monitor whether the OTA flash operation has completed.

[0088] Once the OTA flash process is complete, processor 244 can measure / estimate the first SOC drop at step 416, as described above. At step 418, processor 244 can determine if the first SOC drop is greater than the predefined SOC threshold. Procedure 400 can proceed to step 406 if processor 244 determines at step 418 that the first SOC drop is less than the predefined SOC threshold.

[0089] Otherwise, in response to determining in step 418 that the initial SOC drop is greater than the predefined SOC threshold, processor 244 can determine in step 420 whether the estimated ambient temperature at the expected vehicle engine start time is less than 0 degrees Fahrenheit (or any other predefined temperature threshold) and whether vehicle 102 is parked outdoors (i.e., not in an enclosed space). If either of these conditions is not met, procedure 400 can proceed to step 406.

[0090] Otherwise, in response to determining that the estimated ambient temperature at the expected vehicle engine start time is less than 0 degrees and that the vehicle 102 is parked outdoors, procedure 400 can proceed to step 422. In step 422, processor 244 can estimate / predict the second SOC drop, as described above. In step 424, processor 244 can automatically start the warm vehicle engine. In step 426, processor 244 can continuously monitor whether battery 240 has been replenished with a SOC amount equal to the sum of the first SOC drop and the second SOC drop.

[0091] At step 428, processor 244 can stop the vehicle's engine if battery 240 is recharged. After step 428, procedure 400 can proceed to step 406, at which point procedure 400 can stop.

[0092] The preceding disclosure refers to the accompanying drawings, which form part thereof and illustrate specific implementations in which the present disclosure can be practically implemented. It is understood that other implementations may be used and structural modifications made without deviating from the scope of the present disclosure. References in the description to "an embodiment," "an exemplary embodiment," etc., indicate that the described embodiment may include a specific feature, structure, or property, but not every embodiment necessarily includes that specific feature, structure, or property. Furthermore, such formulations do not necessarily refer to the same embodiment.Furthermore, if a feature, structure or property is described in connection with an embodiment, the person skilled in the art will recognize such a feature, structure or property in connection with other embodiments, whether this is expressly described or not.

[0093] Furthermore, the functions described in this document may be performed in one or more hardware, software, firmware, digital components, or analog components. For example, one or more application-specific integrated circuits (ASICs) may be programmed to execute one or more of the systems and procedures described in this document. Certain terms used throughout this description and in the claims refer to specific system components. It is obvious to a person skilled in the art that the components may be designated by other names. This document does not distinguish between components that differ in name but do not differentiate in function.

[0094] It is also understood that the word "example," as used in this document, is not intended to be exclusive or restrictive. In particular, the word "example," as used in this document, indicates one of several examples, and it is understood that no undue emphasis or preference is placed on the specific example described.

[0095] A computer-readable medium (also called a processor-readable medium) comprises any non-transient (e.g., physical) medium involved in providing data (e.g., instructions) that can be read by a computer (e.g., by a computer's processor). Such a medium can take many forms, including non-volatile and volatile media. Computing devices can contain computer-executable instructions, which can be executed by one or more computing devices, such as those listed above, and can be stored on a computer-readable medium.

[0096] With regard to the processes, systems, procedures, heuristics, etc., described in this document, it is understood that although the steps of such processes, etc., have been described as occurring according to a specific, ordered sequence, such processes could be implemented in practice, with the described steps being carried out in a sequence that differs from the sequence described in this document. Furthermore, it is understood that certain steps could be carried out simultaneously, that other steps could be added, or that certain steps described in this document could be omitted. In other words, the descriptions of processes in this document serve the purpose of illustrating various embodiments and should in no way be interpreted as limiting the patent claims.

[0097] Accordingly, it is understood that the foregoing description is intended to be illustrative and not limiting. Many other embodiments and applications beyond the examples provided will become apparent from reading the preceding description. The scope should not be determined by reference to the foregoing description, but instead by reference to the attached claims, together with the full scope of equivalents to which these claims entitle. It is expected and intended that there will be future developments in the technologies discussed in this document and that the disclosed systems and methods will be incorporated into such future embodiments. Overall, it is understood that the application may be modified and varied.

[0098] All terms used in the claims shall have their general meanings as known to a person skilled in the art in the field of the technologies described herein, unless expressly stated otherwise herein. In particular, the use of singular articles such as "a," "an," "the," "a," "a," etc., shall be understood to refer to one or more of the elements mentioned, unless a claim expressly limits this. Phrases expressing conditional relationships, such as "may," "could," "may," or "could," are generally intended to convey that certain embodiments may include certain features, elements, and / or steps, whereas other embodiments may not include them, unless specifically stated otherwise or the context makes it clear otherwise.Therefore, such formulations, which express conditional relationships, should generally not imply that features, elements and / or steps are required in any way for one or more embodiments.

[0099] According to the present invention, a method comprises: determining, by a processor, that a software update is available for a vehicle; determining, by the processor and based on historical vehicle information, an optimal time to initiate a software update installation in the vehicle in order to optimize vehicle battery usage in response to the determination that the software update is available; and transmitting, by the processor, an installation initiation notification to a server in order to install the software update at the optimal time.

[0100] In one aspect of the invention, 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.

[0101] In one aspect of the invention, the method includes: obtaining the software update from the server in response to the transmission of the installation initiation notification; causing the vehicle to install the software update in response to obtaining the software update; estimating an initial drop in the battery state of charge (SOC) when the vehicle installs the software update; determining an expected vehicle engine start time based on a historical vehicle usage pattern in response to determining that the software update is available; determining an estimated ambient temperature at the expected vehicle engine start time based on weather information; and correlating the estimated ambient temperature with a mapping of a plurality of battery SOC drop values ​​to a plurality of ambient temperatures.and estimating a second drop in battery state of charge (SOC) at the expected vehicle engine start time based on the correlation.

[0102] In one aspect of the invention, the method includes: switching 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 and second waste; and causing 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 and second waste.

[0103] According to the present invention, a durable, computer-readable storage medium is provided which has instructions stored thereon which, when executed by a processor, cause the processor to: determine that a software update is available for a vehicle; determine, based on historical vehicle information, an optimal time to initiate a software update installation in the vehicle in order to optimize vehicle battery usage in response to the determination that the software update is available; and transmit an installation initiation notification to a server to install the software update at the optimal time.

Claims

[1] Vehicle, comprising: a battery configured to provide power to the vehicle; a 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 in order to optimize battery usage; and Transmitting an installation initiation notification to a server to install the software update at the optimal time. [2] Vehicle according to claim 1, wherein the historical vehicle information includes at least one of the following: information associated with time periods in which a vehicle engine is likely to have residual heat from driving cycles of the vehicle; information associated with time periods in which the vehicle is likely to be connected to a block heater; or information associated with time periods in which the vehicle is likely to be parked in an enclosed parking space. [3] Vehicle according to 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 according to claim 1, further comprising a sensor system configured to provide inputs to the processor, wherein the processor is further configured to: Monitoring a vehicle engine coolant temperature based on inputs obtained from the sensor system; Comparing the vehicle engine coolant temperature with a predefined coolant temperature threshold; and Determining the optimal time to initiate the software update installation as a time when the vehicle engine coolant temperature exceeds the predefined coolant temperature threshold. [5] Vehicle according to 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 when the processor is unable to determine the optimal time based on historical vehicle information. [6] Vehicle according to claim 1, wherein the processor is further configured to: Obtaining the software update from the server in response to the transmission of the installation initiation notification; Causing the vehicle to install the software update in response to obtaining the software update; and Estimating the initial drop in battery state of charge (SOC) when the vehicle installs the software update. [7] Vehicle according to claim 6, wherein the processor is further configured to: Obtaining update information associated with the software update in response to determining that the software update is available; and Estimating the initial waste based on the update information. [8] Vehicle according to claim 7, wherein the update information includes information associated with one or more of the following: the total size of a software update file, the transfer rate associated with a wireless network connection between the vehicle and the server, the initial battery SOC prior to software update installation, and the battery age. [9] Vehicle according to claim 6, further comprising a vehicle control unit configured to provide inputs to the processor, wherein the processor is further configured to estimate the first drop based on inputs obtained from the vehicle control unit when the software update installation is complete. [10] Vehicle according to claim 6, wherein the memory is further configured to store a mapping of a plurality of battery SOC waste values ​​to a plurality of ambient temperatures, and wherein the processor is further configured to: Determining an expected vehicle engine start time based on a historical vehicle usage pattern in response to determining that the software update is available; Determining an estimated ambient temperature at the expected vehicle engine start time based on weather information; Correlate the estimated ambient temperature with the assignment; and Estimating a second drop in battery SOC at the expected vehicle engine start time based on correlation. [11] Vehicle according to 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 according to 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 according to claim 10, wherein the processor is further configured to: Switching a vehicle engine ON within a predefined time period after completion of the software update installation in response to the estimation of the first and second waste; and To cause the vehicle engine to remain in an ON state until the battery is charged to a SOC value equal to the sum of the first drop and the second drop. [14] Vehicle according to claim 13, wherein the processor is further configured to: Determine that the battery is charged to the SOC value, which is the sum of the first drop and the second drop; and Switching the vehicle engine to OFF when the battery is charged by the SOC value, which corresponds to the sum of the first drop and the second drop. [15] Vehicle according to claim 1, wherein the processor is further configured to: Transmitting a user notification to a user device indicating that the software update is available; and Obtaining user acknowledgment from the user device in response to the transmission of the user notification; and Transmitting the installation initiation notification to the server in response to receiving user confirmation.

Images