System and method for performing over-the-air update to vehicle

Abstract

The present disclosure provides a system and method of performing an over-the-air update on a vehicle. A vehicle is disclosed that includes a battery, a memory, and a processor. The battery may provide power to the vehicle, and the memory may store historical vehicle information. The processor may determine that a software update is available for the vehicle. In response to determining that the software update may be available, the processor may determine, based on the historical vehicle information, an optimal time to initiate software update installation in the vehicle to optimize battery usage. The processor may also transmit an installation initiation notification to a server to install the software update at the optimal time.

Description

Technical Field

[0001] This disclosure relates to systems and methods for performing over-the-air updates to vehicles at the optimal time to optimize vehicle battery usage. Background Technology

[0002] Most modern vehicles have multiple components and modules that require software updates over time. These updates may be needed to fix bugs, upgrade existing software to newer versions, add new features, and so on. Updates can be performed via a physical connection at a vehicle dealership facility or remotely via over-the-air (OTA) downloads to servers. It is known that when a vehicle installs an OTA update or performs an OTA flash, it consumes energy from the vehicle's battery. A system and method are needed to optimize vehicle battery usage when a vehicle performs an OTA flash. Summary of the Invention

[0003] This disclosure describes a vehicle that can optimize vehicle battery usage when a software update is installed or an over-the-air (OTA) flash memory is performed. The vehicle can optimize battery usage so that when the vehicle user starts the vehicle after the OTA flash memory is complete or the software update is successful, the battery can effectively start the vehicle's engine.

[0004] It is understandable that when a vehicle performs an OTA flash, the vehicle battery may consume power or experience a drop in state of charge (SOC). When the vehicle is parked in a cold environment (rather than in an enclosed space), the battery may consume power or experience a further drop in SOC. The vehicle may perform one or more mitigation actions to ensure that the battery is effectively replenished or compensated for the amount / value of SOC "lost" due to the OTA flash operation and the cold environment, thereby enabling the battery to effectively start the vehicle engine when the user starts the vehicle after the OTA flash.

[0005] In some respects, the vehicle can first determine that a software update is available on the vehicle's servers. In response to determining that a software update is available, the vehicle can determine the optimal time to perform an OTA flash or install the software update on the vehicle based on historical vehicle usage information. In an exemplary aspect, the vehicle can determine the optimal time to perform an OTA flash as the duration during which the vehicle engine is expected to have residual heat from the vehicle's driving cycle, the duration during which the vehicle is expected to be connected to the cylinder block heater, and / or the duration during which the vehicle is expected to be parked in a closed parking space (determined based on historical vehicle usage patterns / information).

[0006] In response to determining the optimal time to perform an OTA flash update, the vehicle can install and perform the software update at that optimal time. In some respects, the vehicle may seek / obtain confirmation from the user before installing the software update. Furthermore, the vehicle can perform an OTA flash update when the vehicle is ignited (i.e., when the vehicle's engine is off).

[0007] The vehicle can also measure / estimate the SOC drop (or "first SOC drop") that the battery may experience due to OTA flashing. In some aspects, the vehicle can measure the first SOC drop based on input obtained from the vehicle control unit. In other aspects, the vehicle can estimate the first SOC drop based on multiple parameters, including but not limited to the estimated time required to perform OTA flashing, the initial SOC of the battery before OTA flashing, battery health, battery life, etc. In an exemplary aspect, the estimated time required to perform OTA flashing may depend on the size of the software update file, the total number of vehicle components / modules performing OTA flashing, the transmission rate or network strength associated with the wireless network connecting the vehicle and the server, etc.

[0008] The vehicle can also estimate the expected vehicle start-up time based on historical vehicle usage patterns. In some aspects, the expected vehicle start-up time can be a future time when a user is expected to start the vehicle (e.g., use / drive the vehicle). In response to estimating the expected vehicle start-up time, the vehicle can estimate the expected ambient temperature at the expected vehicle start-up time based on weather condition information (which the vehicle can obtain from a server or the cloud).

[0009] The vehicle can also estimate the SOC drop (or "second SOC drop") that the battery may experience during the expected vehicle start-up time due to cold weather conditions, the vehicle being parked outdoors, and / or the first SOC drop exceeding a predefined SOC threshold. The vehicle can estimate the second SOC drop by correlating the expected ambient temperature with a table or mapping between multiple SOC drop values ​​and multiple ambient temperatures.

[0010] In response to determining / estimating the first and second SOC drops as described above, the vehicle can automatically start the vehicle engine to charge the vehicle battery to a certain SOC value / amount, which can be equal to the sum of the first and second SOC drops after the OTA flash operation is completed. Once the battery has been charged or the aforementioned SOC value / amount has been compensated, the vehicle can shut off the vehicle engine. In this way, when the user starts the vehicle at the expected vehicle start-up time, the vehicle ensures that the battery has sufficient SOC to start the vehicle engine.

[0011] This disclosure discloses a vehicle that can install and perform software updates at an optimal time to optimize vehicle battery usage. The vehicle can also automatically start the engine after an OTA (Over-The-Air) flash to compensate for the SOC drop caused by the OTA flash and the anticipated SOC drop experienced by the battery due to cold weather conditions. These mitigation actions / steps facilitate efficient battery start-up when the user starts the vehicle after an OTA flash.

[0012] These and other advantages of this disclosure are provided in detail herein. Attached Figure Description

[0013] Specific embodiments are illustrated with reference to the accompanying drawings. The same reference numerals may be used to indicate similar or identical items. Various embodiments may utilize elements and / or components other than those shown in the drawings, and some elements and / or components may not be present in various embodiments. Elements and / or components in the drawings are not necessarily drawn to scale. Throughout this disclosure, singular and plural terms may be used interchangeably, depending on the context.

[0014] Figure 1 The environment in which the techniques and structures for providing the systems and methods disclosed herein can be implemented is described.

[0015] Figure 2 A block diagram of a system for installing over-the-air (OTA) updates on a vehicle, according to this disclosure, is depicted.

[0016] Figure 3 An exemplary graph depicting the relationship between ambient temperature and time according to this disclosure is provided.

[0017] Figure 4A and Figure 4B A flowchart depicts an exemplary method for installing OTA updates on a vehicle according to this disclosure. Detailed Implementation

[0018] The present disclosure will be described more fully below with reference to the accompanying drawings, which illustrate exemplary embodiments of the present disclosure and are not intended to be limiting.

[0019] Figure 1An environment 100 is depicted in which the technologies and structures for providing the systems and methods disclosed herein can be implemented. Environment 100 may include a vehicle 102 and a server 104 (or remote computing device) that can be communicatively coupled to each other. Vehicle 102 may take the form of any passenger or commercial vehicle, such as a car, work vehicle, crossover, truck, van, minivan, taxi, bus, etc. Vehicle 102 may be a manually driven vehicle or may be configured to operate in a partially / fully autonomous mode. Furthermore, vehicle 102 may include any powertrain system, such as a gasoline engine or a hybrid system.

[0020] Vehicle 102 may include multiple components / modules that may require software updates over time. Examples of such components / modules include, but are not limited to, the powertrain, chassis system, advanced driver assistance systems (ADAS), infotainment system, etc. These updates may be needed to upgrade existing systems to newer versions, fix bugs, add new features / functions, etc.

[0021] Vehicle 102 can remotely obtain / download software update files from server 202 (or “over-the-air” (OTA) download), and can install and execute the software update files to perform software updates for vehicle components / modules. In this disclosure, the steps of obtaining, installing, and executing software update files in vehicle 102 are collectively referred to as performing an “OTA update” or “OTA flash” (or OTA flashing).

[0022] In some respects, when vehicle 102 performs OTA flash memory, vehicle 102 may consume power from the vehicle battery (in... Figure 2 The energy of the battery (240) is shown in the diagram. The amount of energy that the vehicle 102 can consume when performing an OTA flash can depend on several 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, the battery health condition, battery life, etc. In an exemplary aspect, the estimated time required to perform the OTA flash can depend on the size of the software update file, the total number of vehicle components / modules performing the OTA flash, the transmission rate or network strength associated with the wireless network connecting the vehicle 102 and the server 104, etc.

[0023] While smaller / shorter software updates may not consume much battery power, larger software updates or those requiring longer installation times can consume significant amounts of battery power and thus primarily drain the vehicle's battery. This can lead to a significant drop in the vehicle's State of Charge (SOC).

[0024] Vehicle 102 typically performs OTA flashing in key-off mode (i.e., when the vehicle engine is off). Therefore, if the vehicle battery experiences a significant drop in SOC due to OTA flashing, there is a possibility that a vehicle user (not shown) may be unable to turn the starter or start the vehicle engine when expecting to start and drive / use vehicle 102 after OTA flashing. The probability of this scenario is likely further increased if vehicle 102 is located in a geographical area with cold ambient temperatures (and if vehicle 102 is not parked in an enclosed space). It is known that the vehicle battery uses more electrical energy (or current) to turn the starter or start a “cold” vehicle engine compared to a relatively warm vehicle engine. Therefore, if vehicle 102 is located in a cold ambient environment, the vehicle battery may experience a drop in power, which could lead to a further decrease in battery SOC.

[0025] The combined drop in battery SOC caused by OTA flash memory and cold ambient conditions may adversely affect the probability of successful engine start-up or starting (when the user needs to start vehicle 102). To ensure that the user can successfully start the vehicle engine after OTA flash memory completion, vehicle 102 may perform one or more OTA flash memory pre- and post-flash mitigation actions, as briefly described below and combined later. Figure 2 Detailed description.

[0026] Vehicle 102 may first determine that an OTA update or new software update is available on server 104 for installation on vehicle 102. In response to this determination, vehicle 102 may determine the “optimal” time to perform OTA flash based on historical vehicle information or historical vehicle usage patterns / information (which may be stored in vehicle memory and / or server 104). In an exemplary aspect, historical vehicle information may include information associated with the following durations: the duration for which vehicle users typically drive vehicle 102, the duration for which the vehicle engine may have “residual” heat after a driving cycle (e.g., when vehicle 102 returns home after a long driving cycle), the duration for which vehicle 102 may be connected to the cylinder block heater, the duration for which vehicle 102 may be parked in an enclosed space (e.g., in a closed garage), etc.

[0027] In some respects, vehicle 102 can determine the optimal time to perform OTA flash memory within any of the aforementioned durations. It is understood that the aforementioned durations are those when the vehicle engine may be warmer than the ambient temperature. Vehicle 102 can choose the optimal time within these durations because if the vehicle engine is warm (compared to when the vehicle engine is cold or when vehicle 102 has been parked outside in cold ambient temperatures), the vehicle battery may not require significant additional energy to start or turn on the engine after the OTA flash memory.

[0028] In some respects, in response to determining the optimal time to perform OTA flash memory as described above, vehicle 102 may send a notification to the user device associated with the vehicle user (in... Figure 2 The vehicle 102 (shown as user device 204) transmits a confirmation notification. The confirmation notification may include information associated with the determined optimal time, allowing the user to confirm whether they accept or refuse to perform OTA flashing at the determined optimal time. When the user transmits a confirmation response via the user device, the vehicle 102 may perform OTA flashing at the determined optimal time. Alternatively, if the user does not accept the determined optimal time (e.g., if the user plans to use / drive vehicle 102 at the determined optimal time), the user may propose a different time for OTA flashing. Alternatively, the vehicle 102 may skip the step of seeking user confirmation and may directly perform OTA flashing at the determined optimal time.

[0029] At the optimal time, vehicle 102 can download, install, and execute software update files to perform a software update or OTA flash in vehicle 102. After the OTA flash is complete, vehicle 102 can perform one or more post-OTA mitigation actions / steps to optimize battery usage, as described below.

[0030] In response to determining that an OTA flash memory update is complete or the software update is successful, vehicle 102 can measure / estimate the decrease in vehicle battery SOC caused by the OTA flash memory update (e.g., "first SOC decrease"). In other words, in response to determining that an OTA flash memory update is complete, vehicle 102 can determine the battery energy or SOC that may have been depleted or consumed to perform the OTA flash memory update. In some aspects, vehicle 102 can directly base its calculations on data from the vehicle control unit (…). Figure 2The input obtained from the VCU (shown as VCU 210) is used to measure the first SOC drop. In this case, the vehicle 102 can first determine the initial battery SOC level before performing the OTA flash (i.e., the pre-OTA battery SOC level) based on the input obtained from the VCU, and then determine the real-time battery SOC level after the OTA flash is completed (i.e., the post-OTA battery SOC level). The vehicle 102 can determine the first SOC drop as the difference between the post-OTA battery SOC level and the pre-OTA battery SOC level.

[0031] In other respects, vehicle 102 can estimate the first SOC drop based on the aforementioned parameters. For example, vehicle 102 can estimate the first SOC drop based on parameters such as the estimated time required to perform OTA flash memory, the initial SOC level of the vehicle battery before OTA flash memory, battery health status, battery life, etc.

[0032] In response to determining a first SOC decrease as described above, in some aspects, vehicle 102 may compare the first SOC decrease with a predefined SOC decrease threshold. When vehicle 102 determines that the first SOC decrease is greater than the predefined SOC decrease threshold, vehicle 102 may perform one or more OTA post-mitigation actions / steps. In other words, when the vehicle battery may have experienced a significant decrease / depletion of its energy / SOC level, vehicle 102 may perform one or more OTA post-mitigation actions. In other aspects, vehicle 102 may skip this comparison step and may perform one or more OTA post-mitigation actions regardless of whether the first SOC decrease is greater than or less than the predefined SOC decrease threshold.

[0033] As part of the post-OTA mitigation actions, vehicle 102 can first determine the expected vehicle engine start time based on historical vehicle usage patterns (which may be part of the aforementioned historical vehicle information). Specifically, in this case, vehicle 102 can determine the estimated future time when the expected vehicle user will turn on or start the vehicle engine (e.g., drive or use vehicle 102) based on historical vehicle usage patterns. Additionally or alternatively, vehicle 102 can determine 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 input to vehicle 102 (e.g., to the vehicle's onboard computer) indicating that the user will begin the trip at 7:00 AM, vehicle 102 can determine the expected vehicle engine start time as 7:00 AM. In this case, vehicle 102 can also customize / optimize the vehicle's cabin temperature / climate before the scheduled trip start time (i.e., by 7:00 AM).

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

[0035] Vehicle 102 can also estimate the expected SOC drop (or "second SOC drop") in the vehicle battery due to the ambient temperature at the expected vehicle engine start time based on a mapping between multiple SOC drop values / levels and multiple different ambient temperatures. In some aspects, this mapping may be pre-stored in the vehicle memory and / or server 104. In response to estimating the second SOC drop, vehicle 102 may turn on or start the vehicle engine for a predetermined duration after OTA flash completion (while the vehicle engine may still be warm due to the vehicle's driving cycle or due to the vehicle-to-cylinder block heater connection), and charge the vehicle battery to compensate for the first SOC drop and the second SOC drop. Vehicle 102 may keep the vehicle engine on until the vehicle battery is charged to a SOC level / value equal to the sum of the first SOC drop and the second SOC drop. Thereafter, vehicle 102 may turn off the vehicle engine.

[0036] By recharging the vehicle battery to compensate for the first and second SOC drops after the OTA (Over-The-Air) update, vehicle 102 ensures that the vehicle battery has sufficient SOC to successfully start the vehicle engine when the vehicle user starts the engine at the expected engine start time (when the ambient temperature and engine may be cold). In this way, vehicle 102 compensates for battery consumption (or SOC loss) caused by OTA flash operation and cold environmental conditions, and thus helps to significantly reduce the probability of unsuccessful vehicle start-up after OTA flash operation.

[0037] The following is combined Figure 2 Describe the details of another vehicle, 102.

[0038] Vehicle 102 shall implement and / or perform the operations described herein in accordance with the owner's manual and safety guidelines. Furthermore, any actions taken by the vehicle user based on notifications provided by vehicle 102 shall comply with all rules specific to the location and operation of vehicle 102 (e.g., federal, state, national, city, etc.). Notifications provided by vehicle 102 shall be considered advice and shall be followed only in accordance with any rules specific to the location and operation of vehicle 102.

[0039] Figure 2 A block diagram of a system 200 for installing over-the-air (OTA) updates on a vehicle 102, according to this disclosure, is depicted. (In the description...) Figure 2 At that time, will refer to Figure 3 .

[0040] System 200 may include vehicles 102 communicatively coupled to each other via one or more networks 206, one or more servers 202 (or server 202, which may be the same as server 104 described above), and user devices 204. User devices 204 may be associated with vehicle users and may be, for example, mobile phones, laptops, tablets, smartwatches, or any other similar devices with communication capabilities. Servers 202 may be part of a cloud-based computing infrastructure and may be associated with and / or include a Telematics Service Delivery Network (SDN), which delivers services to vehicles 102 and other vehicles that may be part of a vehicle fleet. Figure 2 (Not shown in the image) provides digital data services.

[0041] In another aspect, server 202 can store historical vehicle information associated with vehicle 102 and can transmit historical vehicle information to vehicle 102 at a predefined frequency or when vehicle 102 requests to receive such information. Historical vehicle information may include, for example, information associated with the vehicle's driving and usage patterns, information associated with the duration for which a vehicle user may (i.e., typically based on historical data) drive vehicle 102, information associated with the duration for which the vehicle engine may (i.e., typically based on historical data) have residual heat from the vehicle's driving cycle, information associated with the duration for which vehicle 102 may (i.e., typically based on historical data) be connected to the cylinder block heater, information associated with the duration for which vehicle 102 may (typically based on historical data) be parked in a closed parking space, etc., as described above. Figure 1 As described.

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

[0043] When a software update becomes available for vehicle 102, server 202 may additionally store the software update file. In some respects, the vehicle manufacturer may provide the software update file to server 202 whenever a software update becomes available for one or more vehicle parts or modules. When server 202 receives an installation initiation notification from vehicle 102, server 202 may transfer the software update file to vehicle 102 (for execution on vehicle 102).

[0044] Network 206 illustrates an example communication infrastructure in which connected devices discussed in various embodiments of this disclosure may communicate. Network 206 may be and / or include the Internet, a private network, a public network, or other configurations operating using any one or more known communication protocols such as Transmission Control Protocol / Internet Protocol (TCP / IP), Bluetooth, etc. ® Bluetooth Low Energy (BLE), Wi-Fi based on the IEEE standard 802.11, Ultra Wideband (UWB), and cellular 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 5G, to name just a few.

[0045] Vehicle 102 may include multiple units, including but not limited to vehicle computer 208, vehicle control unit (VCU) 210, and OTA update unit 212 (or unit 212). VCU 210 may include multiple electronic control units (ECUs) 214 that communicate with vehicle computer 208.

[0046] In some respects, according to this disclosure, the vehicle computer 208 and / or unit 212 can be installed anywhere within the vehicle 102. Additionally, the vehicle computer 208 can operate as a functional part of unit 212. The vehicle computer 208 can be or include an electronic vehicle controller having one or more processors 216 and memory 218. Furthermore, unit 212 can be separate from the vehicle computer 208 (e.g., Figure 2 (as shown), or it can be integrated as part of the automotive computer 208.

[0047] Processor 216 can communicate with one or more memory devices (e.g., memory 218 and / or memory) of a corresponding computing system. Figure 2The processor 216 may communicate with one or more external databases (not shown). The processor 216 may utilize the memory 218 to store programs in code and / or store data to execute aspects of this disclosure. The memory 218 may be a non-transitory computer-readable medium or memory storing OTA update program code. The memory 218 may include any or a combination of volatile memory elements (e.g., dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), etc.) and may include any one or more non-volatile memory elements (e.g., erasable programmable read-only memory (EPROM), flash memory, electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), etc.).

[0048] In some respects, the VCU 210 may share a power bus with the vehicle computer 208 and may be configured and / or programmed to coordinate the systems of vehicle 102, connected servers (e.g., server 202), and other vehicles operating as part of a vehicle fleet. Figure 2 Data between (not shown in the image). VCU 210 may include or communicate with any combination of ECUs 214, such as Body Control Module (BCM) 220, Engine Control Module (ECM) 222, Transmission Control Module (TCM) 224, Telematics Control Unit (TCU) 226, Driver Assist Technology (DAT) Controller 228, etc.

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

[0050] In some respects, VCU 210 can control vehicle operation aspects and implement one or more instruction sets received from user equipment 204, one or more instruction sets stored in memory 218, including instructions that operate as part of unit 212.

[0051] TCU 226 can be configured and / or programmed to provide vehicle connectivity to wireless computing systems on and outside the vehicle 102, and may include a navigation (NAV) receiver 234 for receiving and processing GPS signals, a BLE module (BLEM) 236, a Wi-Fi transceiver, a UWB transceiver, and / or other wireless transceivers that can be configured for wireless communication (including cellular communication) between the vehicle 102 and other systems (e.g., user device 204, key fob, NFC device, etc.), computers, and modules. Figure 2 (Not shown in the image). NAV receiver 234 can be configured to determine the real-time geographical location of the vehicle. TCU 226 can communicate with ECU 214 via bus.

[0052] ECU 214 can control various aspects of vehicle operation and communication using inputs from the human driver, inputs from the autonomous vehicle controller, unit 212, and / or wireless signal inputs received from other connected devices (such as user device 204, server 202, etc.) via wireless connection.

[0053] The BCM 220 typically integrates sensors, vehicle performance indicators, and variable reactors associated with vehicle systems. It may also include processor-based power distribution circuitry that controls functions associated with the vehicle body, such as lights, windows, safety devices, cameras, fans, headlights, audio systems, speakers, wipers, door locks and entry controls, side mirrors, various comfort controls, and housings. The BCM 220 can also function as a gateway for bus and network interfaces to communicate with remote ECUs ( Figure 2 Interact with (not shown in the image).

[0054] The DAT controller 228 provides Level 1 to Level 3 automated driving and driver assistance functionality, which may include features such as active parking assist, vehicle reversing assist, and adaptive cruise control. The DAT controller 228 also provides various aspects of user and environmental inputs that can be used for user authentication.

[0055] In some respects, the vehicle computer 208 may connect to the infotainment system 238 (or the vehicle human-machine interface (HMI) 238). The infotainment system 238 may include a touchscreen interface portion and may include voice recognition features, and the ability to identify users based on facial recognition, voice recognition, fingerprint recognition, or other biometric methods. In other respects, the infotainment system 238 may also receive user commands / inputs via the touchscreen interface portion, and / or display notifications / recommendations, navigation maps, etc., on the touchscreen interface portion.

[0056] Vehicle 102 may also include a battery 240 that can provide power to one or more vehicle components. In some aspects, when the vehicle engine is started from idle or off, battery 240 can provide power / energy to start the vehicle engine.

[0057] The computing system architecture of the automotive computer 208, VCU 210, and / or unit 212 may omit certain computing modules. This should be easily understood. Figure 2 The computing environment depicted herein is an example of possible implementations according to this disclosure and should therefore not be considered limiting or exclusive.

[0058] Depending on some aspects, unit 212 may be integrated with and / or performed as part of ECU 214. Unit 212 may include transceiver 242, processor 244, and computer-readable storage 246, whether it is integrated with vehicle computer 208 or ECU 214, or whether it operates as a stand-alone computing system in vehicle 102.

[0059] Transceiver 242 can receive information / input from one or more external devices or systems (e.g., user device 204, server 202, etc.) via network 206. For example, transceiver 242 can receive historical vehicle information, mappings of multiple battery SOC drops to multiple ambient temperatures, software update files, etc., from server 202 via network 206. Furthermore, transceiver 242 can transmit notifications to external devices or systems. Additionally, transceiver 242 can receive information / input from vehicle 102 components (such as infotainment system 238, VCU 210, etc.). Furthermore, transceiver 242 can transmit notification / command signals to vehicle 102 components (such as VCU 210, vehicle engine, infotainment system 238, etc.).

[0060] Processor 244 and memory 246 may be the same as or similar to processor 216 and memory 218, respectively. In some aspects, processor 244 may utilize memory 246 to store programs in code form and / or store data to perform aspects according to this disclosure. Memory 246 may be a non-transitory computer-readable medium or memory storing OTA update program code. In some aspects, memory 246 may store historical vehicle information obtained by vehicle 102 from server 202, mappings of multiple battery SOC decline values ​​to multiple ambient temperatures, and software update files.

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

[0062] As an example, by using historical vehicle information (specifically, historical vehicle usage patterns), processor 244 can determine the optimal time when the vehicle engine is expected to have residual "waste" heat from the previous vehicle's driving cycle. For instance, if vehicle 102 is expected to arrive at the user's home at 6 PM after a long drive (determined based on historical vehicle information / vehicle usage patterns), processor 244 can determine that the optimal time to initiate a software update installation is 6:10 PM or 6:15 PM, when the vehicle engine may still be "warm" due to the vehicle's driving cycle. Choosing such a time to perform a software update installation or OTA flash helps processor 244 efficiently perform post-OTA mitigation actions / steps, which will be described later in the following description.

[0063] As another example, by using historical vehicle information, processor 244 can determine the optimal time as the time when the expected vehicle user will connect vehicle 102 to the cylinder block heater (which may cause the vehicle engine to warm up). Alternatively, processor 244 can obtain input from vehicle sensing system 232 and monitor the real-time vehicle engine coolant temperature based on the input from vehicle sensing system 232 (e.g., when vehicle 102 may be connected to the cylinder block heater). Processor 244 can also compare the real-time vehicle engine coolant temperature to a predefined coolant temperature threshold and determine the optimal time to initiate a software update installation / OTA flash is when the vehicle engine coolant temperature becomes higher than the predefined coolant temperature threshold. In other words, in this case, processor 244 can determine the optimal time as the time when the vehicle engine warms up.

[0064] As yet another example, by using historical vehicle information, processor 244 can determine the optimal time for vehicle 102 to be parked in an enclosed space (e.g., a closed parking lot, garage, etc.) where the temperature may be warmer than the outside ambient temperature (which may cause the vehicle engine to remain relatively warm).

[0065] In some respects, if the processor 244 is unable to determine the optimal time using the historical vehicle information described above, the processor 244 may transmit a notification to the user device 204 via the transceiver 242 requesting the vehicle user to park the vehicle 102 in a closed parking space.

[0066] In some aspects, in response to determining the optimal time as described above or in response to determining that the software update is available at server 202, processor 244 may transmit a user notification to user device 204 instructing the vehicle user that the software update is available for vehicle 102. In some aspects, the user notification may include information associated with the determined optimal time. The user can view the user notification and, if the user accepts the determined time of the OTA flash, can confirm the notification. In this case, processor 244 may obtain user confirmation from user device 204 in response to transmitting the user notification. In response to obtaining user confirmation, processor 244 may (via transceiver 242) transmit an installation initiation notification to server 202 to install the software update at the determined optimal time.

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

[0068] When server 202 receives an installation initiation notification from processor 244, server 202 can transmit the software update file to transceiver 242 / processor 244. Processor 244 can obtain the software update file from server 202 in response to the transmission of the installation initiation notification, and can cause vehicle 102 to install / perform the software update in response to obtaining the software update file. It is understood that, depending on the size of the software update file, OTA flashing may take several minutes to several seconds.

[0069] When vehicle 102 installs / performs a software update or when processor 244 performs an OTA flash, processor 244 can also estimate / measure the first SOC drop in battery 240. (As described above...) Figure 1As described, the first SOC drop may be associated with battery consumption or battery SOC decrease due to performing / installing a software update (or due to OTA flashing). In an exemplary aspect, when the software update installation or OTA flashing is completed, the processor 244 may measure the first SOC drop based on input obtained from the VCU 210. In this case, the processor 244 may obtain input associated with the real-time battery SOC before and after the OTA flashing and determine the first SOC drop as the difference between the battery SOC after the OTA and the battery SOC before the OTA.

[0070] In another exemplary aspect, processor 244 may estimate a first SOC drop based on "update information" associated with a software update. In this case, processor 244 may obtain the update information from server 202, one or more vehicle components (e.g., TCU 226), other vehicles, etc., via vehicle-to-vehicle (V2V) communication. The update information may include, for example, information associated with the total size of the software update file, the transmission rate associated with network 206, the initial battery SOC prior to the software update installation / OTA flash operation, battery health status, battery life, etc. Processor 244 may correlate the obtained update information with a data structure that includes mappings of multiple battery SOC drop values ​​to different parameters included in the update information to estimate the first SOC drop. The data structure described herein may be pre-stored in memory 246 and / or server 202, or may be generated by processor 244 itself by monitoring battery SOC drop values ​​over time when vehicle 102 performs OTA flash, or may be generated / provided by the vehicle manufacturer.

[0071] In some aspects, processor 244 may estimate the first SOC decrease based on the update information described above before or after the OTA flash operation. In an exemplary aspect, processor 244 may estimate the first SOC decrease based on update information even before determining the optimal time. In this case, processor 244 may estimate the first SOC decrease based on update information in response to determining that a software update is available on server 202, and may perform the steps described above for determining the optimal time when processor 244 determines that the first SOC decrease may be greater than the predefined SOC decrease threshold.

[0072] In response to estimating / measuring the first SOC drop using one of the methods described above, processor 244 may determine the expected vehicle engine start time based on historical vehicle usage patterns (which may be part of historical vehicle information) or based on pre-stored user input indicating when the user expects to drive vehicle 102. As combined above... Figure 1As described, the expected vehicle engine start time can be an estimated future time when the expected vehicle user turns on the starter or starts the vehicle engine (e.g., to drive or use vehicle 102). In some aspects, processor 244 can determine the expected vehicle engine start time in response to determining that a 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 completed. Furthermore, as described above... Figure 1 The processor 244 can determine the expected vehicle engine start time based on a pre-programmed trip start time that the vehicle user may have provided to the vehicle 102 in advance. For example, if the user has provided input to the vehicle 102 (e.g., to the vehicle's onboard computer) instructing the user to start the trip at 7:00 AM, the processor 244 can determine the expected vehicle engine start time as 7:00 AM. In this case, the processor 244 can also customize / optimize the vehicle's cabin temperature / climate before the scheduled trip start time (i.e., up to 7:00 AM).

[0073] In response to determining the expected vehicle engine start-up time, processor 244 can obtain weather condition information (or weather information) associated with the geographic area where vehicle 102 is located from server 202 or any cloud-based computing entity providing weather condition information. Processor 244 can also determine an estimated ambient temperature at the expected vehicle engine start-up time based on the obtained weather information. Processor 244 can then retrieve a mapping of multiple battery SOC drop values ​​or power consumption values ​​to multiple ambient temperatures from memory 246. As described above, the mapping may include a table having information associated with expected SOC drop or power drop in battery 240 due to cold weather at different ambient temperatures.

[0074] Processor 244 can correlate the estimated ambient temperature at the expected vehicle engine start time with a mapping to estimate a second SOC drop at the expected vehicle engine start time. As mentioned above, the second SOC drop can indicate a decrease in battery SOC / power due to cold ambient temperatures. In some respects, the second SOC drop can also depend on battery life (and / or battery health). For example, if battery 240 is older, the second SOC drop may be higher compared to the second SOC drop of a relatively newer battery (under the same ambient conditions / temperature).

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

[0076] In an additional or alternative manner, when battery 240 may have experienced or is expected to experience a significant first SOC drop, processor 244 may estimate the aforementioned second SOC drop. In this case, processor 244 may first compare the first SOC drop with a predefined SOC drop threshold, and may estimate the second SOC drop if processor 244 determines that the first SOC drop is greater than the predefined SOC drop threshold. It is understood that if battery 240 has experienced or is expected to experience a significant first SOC drop due to OTA flash memory, any further battery SOC loss due to cold weather conditions may significantly increase the chance that the vehicle engine will fail to start when the user attempts to start vehicle 102 (which may cause inconvenience to the user). To prevent this scenario from occurring, processor 244 may estimate the second SOC drop when the first SOC drop is likely to be quite large (or greater than the predefined SOC drop threshold).

[0077] In response to determining / estimating the first SOC drop and the second SOC drop as described above, processor 244 may perform one or more post-OTA mitigation actions to ensure that when the user attempts to start vehicle 102 at the expected vehicle engine start time, vehicle 102 successfully starts the engine. Specifically, in response to determining / estimating the first SOC drop and the second SOC drop, processor 244 may perform one or more post-OTA mitigation actions to ensure that when the user attempts to start vehicle 102 at the expected vehicle engine start time, battery 240 has regained or replenished the "lost" energy / SOC (due to OTA flash operation and cold weather conditions) that would enable battery 240 to successfully start the engine. Exemplary post-OTA mitigation actions are described below.

[0078] In some respects, processor 244 can turn on the vehicle engine for a predefined period of time after the software update installation / OTA flash memory is completed (while the vehicle engine may still be warm) and keep the vehicle engine on until battery 240 is charged to a SOC value equal to the sum of the first SOC drop and the second SOC drop. Processor 244 can also control the vehicle actuator output to a high charging rate to fully charge battery 240 or charge battery 240 to the aforementioned SOC value. This action can restore the same amount of charge / energy / SOC that battery 240 may lose due to OTA flash memory operation, as well as the SOC that battery 240 is expected to consume due to cold weather conditions before the expected vehicle start-up time. As an example, if battery 240 loses 15% of its SOC due to OTA flash memory operation, and is expected to effectively consume another 15% of its SOC / power due to cold weather conditions before the expected vehicle start-up time, processor 244 can turn on the vehicle engine to charge battery 240 by 30%. In this way, the battery 240 can have a higher SOC than the pre-OTA SOC level, which allows the battery 240 to successfully start / start the vehicle engine at the expected vehicle start-up time.

[0079] It is understood that restarting a warm vehicle engine after an OTA flash operation can result in less battery consumption and ensure successful vehicle engine start / start. The battery charging operation after an OTA flash, as described in this disclosure, is more advantageous than the conventional battery charging operation before an OTA flash. This is because the nature of the battery's actual SOC consumption is more deterministic after an OTA flash, and therefore more accurate. Charging or fully charging the battery before an OTA flash is less deterministic because the length of the OTA may vary and the SOC consumption may change accordingly.

[0080] In response to determining that the battery 240 has been charged to a SOC value equal to the sum of the first SOC drop and the second SOC drop (based on the input obtained from the VCU 210), the processor 244 may shut down the vehicle engine. Figure 3 An exemplary scenario is described in which the processor 244 performs OTA flash memory and turns the vehicle engine on / off.

[0081] Figure 3 An exemplary graph 300 depicts the relationship between time (shown on the X-axis) and ambient temperature (shown on the Y-axis). Figure 3In the exemplary scenario depicted, a user can park vehicle 102 at time "T1" when the ambient temperature is likely 18 degrees Fahrenheit. In response to the user parking vehicle 102 (or vehicle 102 entering the "key off" phase), processor 244 can perform an OTA flash operation at time "T2" when the ambient temperature is likely 15 degrees Fahrenheit. In some respects, the difference between "T2" and "T1" can be small, such that the vehicle engine may still be warm before time "T1" due to the vehicle's driving cycle (e.g., the vehicle engine coolant temperature is greater than 100 or 120 degrees Fahrenheit).

[0082] When the OTA flash memory completes, the processor 244 may initiate / start the vehicle engine at time "T3," which may immediately follow the OTA flash memory completion or occur within a short, predefined duration after the OTA flash memory completion. The processor 244 may keep the vehicle engine running until time "T4," at which point the battery 240 may be charged to an SOC amount / value equal to the sum of the first and second SOC drops. As described above, while the battery 240 is charging, the processor 244 may shut off the vehicle engine at time "T4."

[0083] The processor operation described above ensures that when the user starts the vehicle 102 at time “T5” (which could be the expected vehicle start time, and when the expected ambient weather is cold), the battery 240 has sufficient charge / SOC to successfully start the vehicle engine, and the user will not face any inconvenience.

[0084] Processor 244 can perform one or more additional actions to optimize vehicle performance. For example, when vehicle 102 is parked in a closed and sealed garage, and processor 244 automatically starts or cranks the vehicle engine to replenish the battery's state of charge (SOC), processor 244 can obtain input from vehicle sensor system 232 to determine whether the garage door is closed. In response to determining that the garage door is closed, processor 244 can transmit a command signal to the garage door computing device to automatically open the garage door when processor 244 starts the vehicle engine to replenish the battery's SOC. Once the battery's SOC has been replenished, processor 244 can shut off the vehicle engine and transmit a command signal to the garage door computing device to automatically close the garage door.

[0085] Furthermore, although the above description is in the context of the processor 244 replenishing battery charge / SOC when vehicle 102 is in cold ambient temperatures, this disclosure is not limited to such aspects. In an additional aspect, the processor 244 can determine, based on historical or deterministic vehicle information, whether vehicle 102 will be parked for an extended period in mild climates (i.e., holiday mode / airport parking for a week or longer). It is understood that even when the vehicle is not driven, the battery experiences parasitic power extraction. In the same situation, the processor 244 can automatically start the vehicle's engine to replenish the depleted battery SOC in a manner similar to that described above.

[0086] Furthermore, although the above description is set in the context of processor 244 replenishing battery charge / SOC due to OTA flash memory operation, this disclosure is not limited to such aspects. Processor 244 can perform a similar "battery replenishment" operation to compensate for battery charge / energy loss caused by post-key-off diagnostics typically performed by vehicle 102 after the user parks / turns off vehicle 102. It is understood that in most modern vehicles, post-key-off diagnostics are performed to check the status of multiple vehicle components / modules (e.g., lights, windows, communication modules, etc.). Such post-key-off diagnostics may consume battery energy / charge. Without departing from the scope of this disclosure, the principles / details / processes for replenishing battery charge / SOC as described herein can also be applied to compensate for battery energy loss caused by post-key-off diagnostics. In an exemplary aspect, if the drop in battery SOC may exceed a threshold, processor 244 can replenish the battery SOC consumed by the post-key-off diagnostics. Furthermore, in this case, processor 244 can replenish battery SOC when battery 240 may be aging and / or when vehicle 102 may be in a cold environment or parked for an extended period.

[0087] Figure 4A and Figure 4B A flowchart depicts an exemplary method 400 for installing an OTA update on a vehicle 102 according to this disclosure. Further description can be made with reference to the preceding figures. Figure 4A and 4B The following process is exemplary and is not limited to the steps described below. Furthermore, alternative embodiments may include more or fewer steps than shown or described herein, and may include these steps in a different order than that described in the following example embodiments.

[0088] Method 400 begins at step 402. At step 404, method 400 may include a determination by processor 244 whether an OTA (Over-The-Air) update is required. In other words, at step 404, processor 244 may determine whether a software update is available for vehicle 102 on server 202. If no software update is available, method 400 may proceed to step 406, at which point method 400 may terminate.

[0089] On the other hand, when processor 244 determines at step 404 that OTA is required, method 400 can move to step 408, where processor 244 can determine whether the vehicle engine is hot due to a driving cycle or whether vehicle 102 is connected to a cylinder block heater. In some aspects, processor 244 can execute step 408 at the aforementioned optimal time. In other aspects, processor 244 can execute step 408 whenever it determines that OTA is required.

[0090] When processor 244 determines that the vehicle engine is not hot and vehicle 102 is not connected to the cylinder block heater, method 400 may proceed to step 410. At step 410, processor 244 may transmit a user notification to user device 204 requesting the user to park vehicle 102 in an enclosed space. In response to the user parking vehicle 102 in an enclosed space, processor 244 may perform an OTA flash. Method 400 may then proceed to step 406.

[0091] On the other hand, when processor 244 determines at step 408 that the vehicle engine is hot or the vehicle 102 is connected to the cylinder block heater, method 400 can move to step 412. At step 412, when the engine may still be warm or when the vehicle 102 may be connected to the cylinder block heater, processor 244 may schedule / execute an OTA flash shortly after the vehicle key is turned off (or within a short, predefined duration). Then, at step 414, processor 244 may continuously check / monitor whether the OTA flash operation is complete.

[0092] When the OTA flash operation is complete, at step 416, processor 244 can measure / estimate the first SOC drop, as described above. At step 418, processor 244 can determine whether the first SOC drop is greater than a predefined SOC threshold. When processor 244 determines at step 418 that the first SOC drop is less than the predefined SOC threshold, method 400 can proceed to step 406.

[0093] On the other hand, in response to determining at step 418 that the first SOC drop is greater than a predefined SOC threshold, processor 244 may determine at 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, method 400 may proceed to step 406.

[0094] On the other hand, in response to determining that the estimated ambient temperature at the expected vehicle engine start time is less than 0 degrees and the vehicle 102 is parked outdoors, method 400 may proceed to step 422. At step 422, processor 244 may estimate / predict a second SOC drop, as described above. At step 424, processor 244 may automatically start the warmed vehicle engine. At step 426, processor 244 may continuously monitor whether battery 240 has been replenished with an SOC amount equal to the sum of the first and second SOC drops.

[0095] At step 428, when battery 240 has been replenished, processor 244 can stop the vehicle engine. Method 400 can then proceed to step 406 after step 428, at which step method 400 can stop.

[0096] In the foregoing disclosure, reference has been made to the accompanying drawings, which form a part of the foregoing disclosure, illustrating specific embodiments in which the present disclosure may be practiced. It should be understood that other implementations and structural changes may be made without departing from the scope of the present disclosure. References to “an embodiment,” “embodiment,” “example embodiment,” etc., in this specification indicate that the described embodiment may include specific features, structures, or characteristics, but each embodiment may not necessarily include said specific features, structures, or characteristics. Furthermore, such phrases do not necessarily refer to the same embodiment. Moreover, when features, structures, or characteristics are described in connection with embodiments, those skilled in the art will recognize such features, structures, or characteristics in conjunction with other embodiments, whether explicitly described or not.

[0097] Furthermore, where appropriate, the functions described herein may be performed by one or more of the following: hardware, software, firmware, digital components, or analog components. For example, one or more application-specific integrated circuits (ASICs) may be programmed to perform one or more of the systems and programs described herein. Certain terms are used throughout the specification and claims to refer to specific system components. As those skilled in the art will appreciate, components may be referred to by different names. This document is not intended to distinguish between components with different names but identical functions.

[0098] It should also be understood that the term "example" as used herein is intended to be non-exclusive and non-restrictive in nature. More specifically, the term "example" as used herein refers to one of several examples, and it should be understood that there is no undue emphasis or preference on the particular example described.

[0099] Computer-readable media (also known as processor-readable media) include any non-transitory (e.g., tangible) medium that contributes to providing data (e.g., instructions) that can be read by a computer (e.g., by the computer's processor). Such media can take many forms, including but not limited to non-volatile and volatile media. Computing devices may include computer-executable instructions, wherein the instructions can be executed by one or more computing devices (such as those listed above) and stored on a computer-readable medium.

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

[0101] Therefore, it should be understood that the above description is intended to be illustrative rather than restrictive. Many embodiments and applications beyond the examples provided will become apparent upon reading the above description. The scope should not be determined by reference to the above description, but rather by reference to the appended claims and the full scope of their equivalents. It is anticipated and expected that the techniques discussed herein will evolve in the future, and the disclosed systems and methods will be incorporated into such future embodiments. In conclusion, it should be understood that modifications and changes are possible with this application.

[0102] Unless explicitly indicated otherwise herein, all terms used in the claims are intended to be given their ordinary meaning as understood by one skilled in the art as described herein. Specifically, unless the claims explicitly limit the recitation to the contrary, the use of singular articles such as “a,” “the,” or “the” should be interpreted as one or more of the elements indicated by the recitation. Unless otherwise specifically stated or otherwise understood in the context of use, conditional language such as, in particular, “can,” “may,” “may,” or “may” is generally intended to express that some embodiments may include certain features, elements, and / or steps, while other embodiments may not include certain features, elements, and / or steps. Therefore, such conditional language is generally not intended to imply that one or more embodiments require each feature, element, and / or step in any way.

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

[0104] In one aspect of the invention, the historical vehicle information includes at least one of the following: information associated with the duration for which the vehicle engine may have residual heat from the vehicle's driving cycle, information associated with the duration for which the vehicle may be connected to a cylinder block heater, or information associated with the duration for which the vehicle may be parked in a closed parking space.

[0105] In one aspect of the invention, the method includes: obtaining the software update from the server in response to transmitting the installation initiation notification; installing the software update on the vehicle in response to obtaining the software update; estimating a first decrease in the battery state of charge (SOC) when the vehicle installs the software update; determining an expected vehicle engine start time based on historical vehicle usage patterns 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; correlating the estimated ambient temperature with a mapping between a plurality of battery SOC decrease values ​​and a plurality of ambient temperatures; and estimating a second decrease in the battery SOC at the expected vehicle engine start time based on the correlation.

[0106] In one aspect of the invention, the method includes: in response to estimating the first drop and the second drop, turning on a vehicle engine for a predefined duration after the software update installation is completed; and keeping the vehicle engine on until the battery is charged to a state of charge (SOC) value equal to the sum of the first drop and the second drop.

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

Claims

1. A vehicle comprising: A battery configured to provide power to the vehicle; A memory configured to store historical vehicle information; and Processor, the processor being configured to: It has been determined that the software update is available for the vehicle; In response to determining that the software update is available, the optimal time to initiate software update installation in the vehicle is determined based on the historical vehicle information to optimize battery usage; as well as Send an installation initiation notification to the server to install the software update at the optimal time.

2. The vehicle of claim 1, wherein the historical vehicle information includes at least one of the following: information associated with the duration for which the vehicle engine may have residual heat from the vehicle's driving cycle, information associated with the duration for which the vehicle may be connected to a cylinder block heater, or information associated with the duration for which the vehicle may be parked in a closed parking space.

3. The vehicle of claim 2, wherein the optimal time is within at least one of the following durations: the duration during which the vehicle engine may have residual heat from the vehicle's driving cycle, the duration during which the vehicle may be connected to the cylinder block heater, or the duration during which the vehicle may be parked in the enclosed parking space.

4. The vehicle of claim 1, further comprising a sensing system configured to provide input to the processor, wherein the processor is further configured to: The vehicle engine coolant temperature is monitored based on input obtained from the sensing system. Compare the vehicle engine coolant temperature with a predefined coolant temperature threshold; and The optimal time to initiate the software update installation is determined as the time when the vehicle engine coolant temperature becomes higher than the predefined coolant temperature threshold.

5. The vehicle of claim 1, wherein the processor is further configured to transmit a notification to the user device requesting the vehicle user to park the vehicle in a closed parking space when the processor is unable to determine the optimal time based on the historical vehicle information.

6. The vehicle of claim 1, wherein the processor is further configured to: The software update is obtained from the server in response to the transmission of the installation initiation notification; In response to receiving the software update, the vehicle installs the software update; and The first drop in battery state of charge (SOC) is estimated when the vehicle installs the software update.

7. The vehicle of claim 6, wherein the processor is further configured to: In response to determining that the software update is available, update information associated with the software update is obtained; and The first decrease is estimated based on the updated information.

8. The vehicle of claim 7, wherein the update information includes information associated with one or more of the following: the total size of the software update file, the transmission rate associated with the wireless network connection between the vehicle and the server, and the initial battery SOC and battery life prior to the software update installation.

9. The vehicle of claim 6, further comprising a vehicle control unit configured to provide input to the processor, wherein the processor is further configured to estimate the first drop based on input obtained from the vehicle control unit when the software update installation is complete.

10. The vehicle of claim 6, wherein the memory is further configured to store a plurality of battery SOC drop values ​​mapped to a plurality of ambient temperatures, and wherein the processor is further configured to: In response to determining that the software update is available, the expected vehicle engine start time is determined based on historical vehicle usage patterns; The estimated ambient temperature for the expected vehicle engine start-up time is determined based on weather information; The estimated ambient temperature is correlated with the mapping; as well as The second decrease in battery SOC is estimated based on the correlation at the expected vehicle engine start time.

11. The vehicle of claim 10, wherein the processor is further configured to determine that the vehicle is not parked in an enclosed space, and wherein when the processor determines that the vehicle is not parked in the enclosed space, the processor estimates the second descent.

12. The vehicle of claim 10, wherein the processor is further configured to compare the first drop with a predefined SOC drop threshold, and wherein when the processor determines that the first drop is greater than the predefined SOC drop threshold, the processor estimates the second drop.

13. The vehicle of claim 10, wherein the processor is further configured to: In response to the estimated first and second drops, the vehicle engine is switched on for a predefined duration after the software update installation is complete; and The vehicle engine is kept running until the battery is charged to a state of charge (SOC) value equal to the sum of the first and second drops.

14. The vehicle of claim 13, wherein the processor is further configured to: Determine the SOC value at which the battery is charged to be equal to the sum of the first decrease and the second decrease; and When the battery is charged to a SOC value equal to the sum of the first and second drops, the vehicle engine is shut off.

15. The vehicle of claim 1, wherein the processor is further configured to: Transmit a user notification to the user device indicating that the software update is available; and In response to transmitting the user notification, a user confirmation is obtained from the user device; and In response to receiving the user's confirmation, the installation initiation notification is transmitted to the server.

Images