State of charge actuation for vehicles

Abstract

This disclosure provides "vehicle charging state actuation". A computer can be programmed to receive a first set of charging state data about a vehicle and a second set of charging state data about a residence associated with the vehicle. Based on the sets of charging state data, the computer can simulate the power consumption of the vehicle and the residence to generate a third set of charging state data. The computer can actuate at least one of the vehicle or the residence to charge according to the third set of charging state data.

Description

Technical Field

[0001] This disclosure relates to a technology for inducing at least one of a vehicle or residence to charge based on a set of charging status data. Background Technology

[0002] Vehicles typically include sensors for collecting data about the vehicle and / or its surrounding environment. In some examples, vehicle systems can use sensor data to actuate vehicle components based on data about objects around the vehicle. Vehicles may also include speakers to output sound. For example, vehicle speakers can output sound for occupants making phone calls, etc. Summary of the Invention

[0003] This document describes a technique for actuating at least one of a vehicle or a dwelling to charge based on a set of charging state data. A computer can receive a first set of charging state data regarding a vehicle and a second set of charging state data regarding a dwelling associated with the vehicle. Based on the sets of charging state data, the computer can simulate the power consumption of the vehicle and the dwelling to generate a third set of charging state data. The computer can actuate at least one of the vehicle or the dwelling to charge based on the third set of charging state data.

[0004] Therefore, this disclosure includes a system comprising a computer having a processor and a memory, the memory storing instructions executable by the processor to: receive a first set of charging state data regarding a vehicle; receive a second set of charging state data regarding a residence associated with the vehicle; simulate the power consumption of the vehicle and the residence based on the set of charging state data to generate a third set of charging state data; and actuate at least one of the vehicle or the residence to charge according to the third set of charging state data.

[0005] The first set of charging status data may include the vehicle charging schedule.

[0006] The second set of charging status data may include the residence's utility plans.

[0007] The group of charging status data may include user preferences.

[0008] The second set of charging status data may include the residence power consumption.

[0009] The first set of charging status data may include the vehicle's operating mode.

[0010] The set of charging status data may include the charge level to be transferred between the residence and the vehicle.

[0011] The instructions may also include instructions for performing the following operations: charging based on the third set of charging status data based on the determination of the user's preferences.

[0012] The third set of charging status data may include methods to optimize battery lifespan by interrupting charging.

[0013] The third set of charging status data may include selections from multiple preset charging programs.

[0014] Generating the third set of charging status data may include optimizing the estimate of monetary savings compared with the first set of charging status data and the second set of charging status data.

[0015] A method includes receiving a first set of charging state data about a vehicle, receiving a second set of charging state data about a residence associated with the vehicle, simulating the power consumption of the vehicle and the residence based on the charging state data to generate a third set of charging state data, and actuating at least one of the vehicle or the residence to charge according to the third set of charging state data.

[0016] The first set of charging status data may include the vehicle charging schedule.

[0017] The second set of charging status data may include the residence's utility plans.

[0018] The group of charging status data may include user preferences.

[0019] The second set of charging status data may include the residence power consumption.

[0020] The first set of charging status data may include the vehicle's operating mode.

[0021] The set of charging status data may include the charge level to be transferred between the residence and the vehicle.

[0022] The method may further include charging based on the determination of the user's preferences according to the third set of charging status data.

[0023] Generating a third set of charging status data can include optimizing battery lifespan by interrupting charging. Attached Figure Description

[0024] Figure 1 This is a block diagram illustrating an example vehicle system and a residential system.

[0025] Figures 2A to 2F This is a timeline showing an exemplary third set of charging status data.

[0026] Figure 3This is a process flowchart illustrating an exemplary process for actuating an entity to charge based on a set of charging state data. Detailed Implementation

[0027] Figure 1 This is a block diagram of a system including vehicle 100 and residence 110. Vehicle 100 can be any passenger or commercial vehicle, such as a sedan, truck, SUV, crossover, van, minivan, taxi, etc. Vehicle 100 is an electric vehicle, such as a BEV (battery electric vehicle), hybrid electric vehicle, PHEV (plug-in hybrid electric vehicle), etc. Vehicle 100 includes a traction battery 102, a vehicle computer 104, multiple components 106, and a communication module 108.

[0028] Vehicle 100 includes a vehicle computer 104 with memory including instructions executable by a processor of vehicle computer 104 to implement processes and operations as described herein. The memory of vehicle computer 104 includes one or more forms of computer-readable medium and stores instructions executable by vehicle computer 104 to perform various operations, including those disclosed herein. For example, vehicle computer 104 may be a general-purpose computer having a processor and memory as described above, and / or may include electronic control units (ECUs) or controllers for specific functions or a set of functions, and / or dedicated electronic circuitry including application-specific integrated circuits (ASICs) fabricated for specific operations (e.g., ASICs for processing and / or transmitting sensor data). In another example, vehicle computer 104 may include an FPGA (Field-Programmable Gate Array), which is fabricated as a user-configurable integrated circuit. Typically, hardware description languages ​​such as VHDL (Very High Speed ​​Integrated Circuit Hardware Description Language) are used in electronic design to describe digital and mixed-signal systems such as FPGAs and ASICs. For example, an ASIC is manufactured based on VHDL programming provided before manufacturing, while the logic components inside an FPGA can be configured based on VHDL programming (e.g., stored in memory electrically connected to the FPGA circuitry). In some examples, a combination of processor, ASIC, and / or FPGA circuitry can be included in vehicle computer 104. Vehicle computer 104 can be embodied as multiple computers coupled together.

[0029] The memory can be of any type (e.g., hard disk drive, solid-state drive, server, or any volatile or non-volatile media). The memory can be a separate device from the vehicle computer 104, and the vehicle computer 104 can retrieve data stored in the memory via a communication network in the vehicle 100 (e.g., via CAN bus, wireless network, etc.). Alternatively or additionally, the memory can be part of the vehicle computer 104 (e.g., as memory of the vehicle computer 104).

[0030] The vehicle computer 104 may include one or more of the components 106 programmed to operate the vehicle 100, such as a propulsion system (e.g., controlling the speed of the vehicle 100 by controlling one or more of an internal combustion engine, an electric motor, a hybrid engine, etc.), a steering system, interior and / or exterior lights, speakers, etc. Components 106 include any part of the vehicle 100 that draws power and can be actuated to perform some operation.

[0031] Vehicle computer 104 can be communicatively coupled to components 106 and communication module 108 in vehicle 100 via a communication network. Vehicle computer 104 is typically arranged for communication over a communication network, which may include buses in vehicle 100, such as Controller Area Network (CAN), and / or other wired and / or wireless mechanisms. Alternatively or additionally, where vehicle computer 104 actually comprises multiple devices, the communication network can be used for communication between the devices represented herein as vehicle computer 104.

[0032] Traction battery 102 stores energy that can be used by devices or components 106 in vehicle 100 and / or residence 110 that require power. Traction battery 102 can provide a high-voltage direct current (DC) output. A contactor module may include one or more contactors to isolate traction battery 102 from the high-voltage bus when open and to connect traction battery 102 to the high-voltage bus when closed. One or more power electronic modules (which may also be referred to as inverters or power modules) may be electrically coupled to the source voltage bus. The power electronic modules are electrically coupled to vehicle 100 and may be coupled to charging stations 112, 122, providing the ability to transfer energy bidirectionally between traction battery 102 and vehicle 100 and / or charging stations 112, 122. For example, traction battery 102 can provide DC voltage, while devices in residence 110 can operate with three-phase alternating current (AC). The power electronic modules can convert DC voltage to three-phase AC to operate the residence devices. Alternatively or additionally, the power electronic modules can convert three-phase AC from the residence device acting as a generator to a DC voltage compatible with traction battery 102. The traction battery 102 may be a high-voltage (HV) battery, comprising one or more battery cells linked together to power components 106 of the vehicle 100, such as a motor. For the purposes of this disclosure, "high voltage" is defined as at least 60 volts of direct current (DC) or at least 30 volts of alternating current (AC), and "low voltage" is defined as less than 60 volts of DC or less than 30 volts of AC. For example, the high-voltage DC current on the vehicle 100 may be approximately 400 volts, and the low-voltage DC current on the vehicle 100 may be 12 volts or 48 volts. The traction battery 102 may be rechargeable. For example, the traction battery 102 may include an electrolyte that allows ions to move between the anode and cathode during discharge and then return during recharging when connected to charging stations 112, 122.

[0033] In addition to providing power for propulsion, the traction battery 102 can also provide power to other vehicle components 106. The vehicle 100 may include a DC / DC converter module that converts the high-voltage DC output from a high-voltage bus to a low-voltage DC level compatible with low-voltage loads. Examples of low-voltage electrical loads could be cabin lighting or dashboard lighting, while high-voltage electrical loads could be fans, electric heating elements, and / or air conditioning compressors.

[0034] The traction battery 102 may have a state of charge (SOC) indicating the amount of charge stored in the traction battery 102. The traction battery 102 may include sensors, such as current sensors and voltage sensors. The outputs of both the current and voltage sensors of the traction battery 102 are provided to the vehicle computer 104. The vehicle controller 104 may be programmed to calculate the SOC based on the signals from the current and voltage sensors of the traction battery 102. Various techniques can be used to calculate the SOC. For example, ampere-hour integration can be implemented, where the current flowing through the traction battery 102 is integrated over time. The SOC can also be estimated based on the output of the voltage sensor of the traction battery 102. The specific techniques used may depend on the chemical composition and characteristics of the particular battery 102.

[0035] Residence 110 can be any structure including infrastructure for charging traction battery 102. Residence 110 includes home charging station 112, home computer 114, sensors 116, and home communication module 118. In the example given herein, residence 110 is a private residence belonging to the operator of vehicle 100. However, residence 110 can be a parking garage, workplace, public area, etc.

[0036] The traction battery 102 can be recharged by a power source such as charging stations 112 and 122. Charging stations 112 and 122 can be connected to an electrical outlet. An external power source can be electrically coupled to charging stations 112 and 122. Charging stations 112 and 122 can also be a distribution network or power grid 120, such as one provided by an electric utility company. Charging stations 112 and 122 provide circuitry and controls to manage energy transfer between the power grid 120 and vehicle 100. Charging stations 112 and 122 can provide DC or AC power to vehicle 100. Charging stations 112 and 122 can include charging connectors for insertion into a charging port on vehicle 100. The charging port can be any type of port configured to transfer power from charging stations 112 and 122 to vehicle 100. The charging port can be electrically coupled to a charging module or on-board power conversion module that can regulate the power supplied from charging stations 112 and 122 to provide appropriate voltage and current levels to the traction battery 102. The charging connector may have pins that mate with corresponding recesses in the charging port. Alternatively, various components described as electrically coupled or connected may use wireless inductive coupling or other contactless power transfer mechanisms to transfer power.

[0037] Charging stations 112 and 122 can be either a home charging station 112 or a public charging station 122. A home charging station 112 can be a personal charging station belonging to the operator of vehicle 100 and is configured to recharge or discharge the traction battery 102 when vehicle 100 is electrically connected to the home charging station 112. A public charging station 122 can be a charging station not owned by the operator of vehicle 100 (e.g., a charging station in a public parking garage).

[0038] As described in more detail below, the home charging station 112 can operate based on one or more algorithms stored in one or more computers 104, 114, 124.

[0039] Residence 110 may include a home computer 114. The home computer 114 may have memory including instructions executable by a processor of the home computer 114 to perform processes and operations as described herein. The memory of the home computer 114 may include one or more forms of computer-readable medium and stores instructions executable by the home computer 114 to perform various operations, as described above. The home computer 114 may be, for example, a personal computer. As another example, the home computer 114 may be one or more devices included in a home charging station 112.

[0040] Residence 110 may include various sensors 116. Sensors 116 are devices that acquire one or more measurements of one or more physical phenomena. Some sensors 116 detect objects, such as radar sensors, scanning laser rangefinders, light detection and ranging (LiDAR) devices, pressure sensors, and image processing sensors (such as cameras). Home computer 114 can receive data from sensors 116 and determine the position of vehicle 100 based on the sensor data. As an example, home computer 114 can receive a specific weight from pressure sensor 116 and image data from image sensor 116, and home computer 114 can determine the presence of vehicle 100 in residence 110 by feeding the specific weight and the image data using a stored algorithm.

[0041] As described above, charging stations 112 and 122 can be electrically connected to power grid 120, which provides consumers with electricity as supplied by an electric utility company (e.g., a distribution network). Power grid 120 is a power supply network from source to endpoint (including power plants, substations, power lines, etc.).

[0042] Computers 104 and 114 can communicate remotely with remote server 126 (e.g., via communication modules 108 and 118). Remote server 126 may be supported by remote computer 124. Remote computer 124 may be, for example, one or more computers. Remote computer 124 can provide instructions to vehicle computer 104 and home computer 114 via server 126.

[0043] The following steps can be performed by vehicle computer 104, home computer 114, and / or remote computer 124, which will be collectively referred to as computers 104, 114, and 124. Computers 104, 114, and 124 can receive a first set of charging state data from vehicle 100 and a second set of charging state data from residence 110. Computers 104, 114, and 124 can input the first and second sets of charging state data into an algorithm to output a third set of charging state data. This algorithm is referred to herein as the "charging algorithm." The charging algorithm performs operations considering historical parking data of vehicle 100, the expected SOC of traction battery 102, utility plans, power consumption of electrical installations in residence 110, user preferences, etc. The operation of the charging algorithm will be described in further detail below. The data that can be included in the first and second sets of charging state data and input into the charging algorithm will be described sequentially.

[0044] Computers 104, 114, and 124 can receive a first set of charging status data about vehicle 100. The first set of charging status data may include the vehicle charging schedule, the operating mode of vehicle 100, user preferences, and the level of charge to be transferred between residence 110 and vehicle 100, each of which will be described in turn below.

[0045] The first set of charging status data includes the vehicle charging schedule. The vehicle charging schedule indicates the time periods during which vehicle 100 connects to charging stations 112, 122 and recharges (e.g., to prepare for further travel) or discharges (e.g., to provide charge to residential electrical installations) the traction battery 102. The charging schedule can be specified by the operator of vehicle 100 to computers 104, 114, 124 and / or predicted by computers 104, 114, 124 based on historical vehicle data, confidence levels of upcoming charging periods weighted by the time of day, etc. In other words, it can be assumed that the vehicle charging schedule in the first set of charging data matches historical data. Computers 104, 114, 124 can aggregate and analyze historical data by inputting data into algorithms stored at one or more computers 104, 114, 124 to reveal patterns associated with charging and use, and thereby determine the most likely charging schedule for vehicle 100.

[0046] The first set of charging status data includes the operating modes of vehicle 100. Operating modes include the state of charge (SOC) of the traction battery 102 when vehicle 100 is connected to charging stations 112 and 122, and the SOC when vehicle 100 is disconnected from charging stations 112 and 122 to allow vehicle 100 to reach its destination. Similar to determining the charging schedule of vehicle 100 based on historical data, computers 104, 114, and 124 can predict the operating modes of vehicle 100 based on historical data. In other words, it can be assumed that the operating modes in the first set of charging data match historical data. For example, computers 104, 114, and 124 can determine the operating modes based on historical data indicating that at a specific time on a specific day during a specific period of a week, vehicle 100 was disconnected from charging stations 112 and 122 when its SOC was within 10% of 80%, and subsequently reconnected to charging stations 112 and 122 when its SOC was within 10% of 30%. In addition, computers 104, 114, and 124 can determine the operating mode of vehicle 100 based on data input from the operator (e.g., specifying the operator's vehicle 100 usage schedule).

[0047] The first set of charging state data includes user preferences. In addition to the operator input described above, the operator can also specify preferences to computers 104, 114, and 124. User preferences include, for example, a minimum SOC (e.g., 40%) that should always be maintained after being reached when connected to charging stations 112 and 122. As another example, the operator can specify that the traction battery 102 can discharge only to residence 110 at specific times of the day.

[0048] The first set of charging state data includes the charge level to be transferred between residence 110 and vehicle 100. As described above, traction battery 102 can be recharged by public charging station 122 and discharged to home charging station 112 to provide charge to electrical installations in residence 110, thereby reducing the electricity consumption of residence 110 from the utility provider. As an example, computers 104, 114, 124 can determine, based on the operating mode of vehicle 100, that vehicle 100 requires at least 40% SOC to reach its destination (e.g., an office building on a weekday morning). In such an example, computers 104, 114, 124 can discharge traction battery 102 to 40% SOC. As another example, as described above, an operator can specify a minimum or maximum SOC to computers 104, 114, 124.

[0049] Computers 104, 114, and 124 can receive a second set of charging state data regarding the residence 110 associated with the vehicle 100. This second set of charging state data may include the residence 110's utility schedule, the residence 110's power consumption, and the charge level to be transferred between the residence 110 and the vehicle 100, each of which will be described in turn below.

[0050] The second set of charging status data includes the utility plans for residence 110. That is, computers 104, 114, and 124 can store data about the utility plans for residence 110, such as the provider, planned power outages, and pricing. As described further below, computers 104, 114, and 124 can use this data to determine a more cost-effective plan for residence 110.

[0051] The second set of charging status data includes the power consumption of residence 110. Computers 104, 114, and 124 can receive data from residence 110 (e.g., from metering software) that measures the power consumption (e.g., in watts) of all electrical devices in residence 110. For example, computers 104, 114, and 124 can communicate remotely with charge-consuming devices that can be connected to the electrical panel of residence 110. Computers 104, 114, and 124 can determine the consumption pattern of residence 110 based on the relative level of power consumption throughout the day.

[0052] The second set of charging state data includes the charge level to be transferred between residence 110 and vehicle 100. That is, based on user input and / or other charging state data (such as minimum SOC requirement or power consumption of residence 110), computers 104, 114, and 124 can determine the charge level to be discharged from traction battery 102 to residence 110 via home charging station 112. For example, computers 104, 114, and 124 can discharge battery 102 until it reaches 40% SOC (e.g., the minimum SOC required for vehicle 100 to perform a planned trip). As another example, computers 104, 114, and 124 can discharge traction battery 102 when power consumption of residence 110 is within a threshold consumption range. The threshold consumption range can be specified by an operator or stored in instructions in the memory of computers 104, 114, and 124. The threshold consumption range allows traction battery 102 to discharge when residence 110 is consuming a relatively low amount of charge. For example, if residence 110 consumes an average of 1,000 watts of power per hour, the threshold could be 500 watts per hour, such that when the consumption of residence 110 drops below 500 watts per hour, the traction battery 102 discharges.

[0053] Based on the first and second sets of charging status data, computers 104, 114, and 124 can simulate the electricity consumption of vehicle 100 and residence 110 to generate a third set of charging status data. That is, computers 104, 114, and 124 can use the first and second sets of charging status data as input to run the simulation. The simulation can take into account the first and second sets of charging status data (e.g., utility plans, customer preferences, vehicle operating modes, etc.) and output the third set of charging status data based on the first and second sets. The third set of charging status data defines how to charge and / or discharge vehicle 100 and / or residence 110 based on the optimization of the first and second sets of charging status data by the ICA, and is proposed by computers 104, 114, and 124 to the user for adoption as a vehicle schedule. In other words, computers 104, 114, and 124 can run simulations to generate a third set of charging status data that proposes various plans to the user. As described throughout this document, the simulation can output a third set of charging status data, which recommends utility plans, subscription services, charging schedules, etc. In some examples used herein, the charging algorithm optimizes the third set of charging status data based on the price-effectiveness of electricity consumption at residence 110.

[0054] Figure 2 illustrates an exemplary timeline simulation based on a first set of charging state data and a second set of charging state data. Figure 2 shows a simulation 200 including a predicted charging schedule 205 and a virtual model 210, which incorporates a third set of charging state data. Simulation 200 is based on the first and second sets of charging state data. The predicted charging schedule 205 is determined by computers 104, 114, and 124 to model the predicted driving and charging schedule of vehicle 100 based on historical data. The virtual model 210 represents real-time data of vehicle 100 adjusted according to the simulation run by computers 104, 114, and 124 (e.g., vehicle 100 may disconnect from home charging station 112 before the time predicted by predicted charging schedule 205). For example, if predicted charging schedule 205 predicts that vehicle 100 will be parked until a specified time and vehicle 100 actually begins its journey at an earlier time, the virtual model 210 is updated to reflect the deviation from predicted schedule 205 by depicting the parking time ending at the departure time. Figure 2A The first iteration of simulation 200 is depicted, in which actual data from the vehicle is represented as virtual model 210. Figures 2B to 2FFurther updates to simulation 200 are depicted, in which virtual model 210 has deviated from the predicted charging schedule 205 in simulation 200. Discharging periods are represented by dark shaded boxes, and charging periods are represented by boxes with diagonal lines. Periods in which vehicle 100 is inserted into one of charging stations 112, 122 and is neither charged nor discharged are represented by unshaded boxes.

[0055] Computers 104, 114, and 124 may store triggers that prompt them to update the simulation 200. A trigger can be any event that allows checking the accuracy of the simulation 200. In the example used herein, the triggers are vehicle 100 connecting to charging station 112 and vehicle 100 disconnecting from charging station 112. When vehicle 100 connects to charging station 112, computers 104, 114, and 124 determine a third set of charging state data via ICA, as will be described in further detail below. When vehicle 100 disconnects from charging station 112, computers 104, 114, and 124 update the simulation 200 via a charging algorithm based on vehicle 100's adherence to the third set of charging state data. Thus, for example, if vehicle 100 connects to home charging station 112 with a SOC of 60% and has a planned trip requiring 60% SOC over four hours, simulation 200 may recommend discharging to the minimum required SOC (e.g., 30%) and charging back to at least 60%. Computers 104, 114, and 124 can also adjust simulation 200 based on the charging time of traction battery 102. For example, computers 104, 114, and 124 can calculate the time required to recharge traction battery 102 from the minimum required SOC to 60% and allocate time in simulation 200 to allow for recharging. Furthermore, if traction battery 102 discharges to the minimum required SOC in a shorter amount of time than in the first simulation (e.g., due to higher residence 110 power consumption), computers 104, 114, and 124 can update simulation 200 to recommend a longer charging period, allowing traction battery 102 to have an SOC higher than 60%.

[0056] As described above, computers 104, 114, and 124 can run simulation 200 based on a first set of state-of-charge data and a second set of state-of-charge data to output a third set of state-of-charge data (e.g., a proposed power consumption plan). Computers 104, 114, and 124 can generate the third set of state-of-charge data from the simulation via a charging algorithm. The charging algorithm may be an algorithm referencing one or more lookup tables regarding how the traction battery 102 should be charged and how the charging power of the traction battery 102 should be allocated. In at least one embodiment, outgoing charging power is allocated between the traction battery 102 and the residence 110 based on a configuration specified in an applicable lookup table. In various embodiments, multiple lookup tables are simultaneously applicable to the third set of state-of-charge data. In other embodiments, some (but not all) lookup tables are applicable to the third set of state-of-charge data. The user can optionally specify whether some or all lookup tables should be actively used in the third set of state-of-charge data.

[0057] The lookup table can be pre-stored by computers 104, 114, and 124. The lookup table specifies how simulation 200 should be run based on the first and second sets of state-of-charge data. Computers 104, 114, and 124 can also store instructions specifying various potential third sets of state-of-charge data to be propagated through simulation 200 based on various scenarios. For example, computers 104, 114, and 124 can store instructions for running simulation 200 and propagating potential third sets of state-of-charge data based on potential use of a specific preset charging procedure and also based on extending the lifespan of the traction battery 102. In such an example, computers 104, 114, and 124 can generate third sets of state-of-charge data that recommend the use of a preset charging procedure and recommend values ​​for parameters that will increase the lifespan of the traction battery 102.

[0058] As an example, Table 1 depicts a lookup table that specifies the minimum time slot to be allocated for recharging the traction battery 102. This time corresponds to the amount of charge required to recharge the battery 102 from its current SOC to a desired SOC. Therefore, if the battery 102 is discharged to 50% and requires 90% SOC (e.g., for a planned trip or according to user preference), computers 104, 114, and 124 can allocate time to charge to 40% SOC.

[0059]

[0060] Table 1

[0061] The charging algorithm can utilize Table 1 and other lookup tables to determine the simulation 200. For example, if vehicle 100 has a trip planned as a result of operating mode or input by the user, computers 104, 114, and 124 can determine the minimum SOC required for the trip based on global navigation data and the known location of public charging stations 122, and allocate a recharging time for simulation 200 sufficient to achieve the minimum SOC while still providing discharge power to residence 110. The charging algorithm can interrupt the discharge of traction battery 102 based on the minimum required SOC and the time required to charge to the required SOC. For example, if vehicle 100 triggers simulation 200 with 50% SOC and is allowed to discharge to 30%, and has a planned trip where vehicle 100 requires 90% SOC (e.g., a 60% difference), computers 104, 114, and 124 can refer to Table 1 and set simulation 200 such that traction battery 102 discharges until 4 hours before the trip, and then begins recharging. As another example, if the power consumption of residence 110 is low enough that the SOC of traction battery 102 remains at 50% for 4 hours before the trip, computers 104, 114, and 124 can extend the discharge time because the time required to charge from 50% SOC to 60% SOC is reduced. Furthermore, even while traction battery 102 is discharging, computers 104, 114, and 124 can continuously calculate the time required to recharge to the desired SOC. If computers 104, 114, and 124 determine that the SOC of battery 102 has dropped to a point where any further drop would result in insufficient time to recharge to the desired SOC level, computers 104, 114, and 124 can adjust simulation 200 to stop discharging and begin recharging.

[0062] Computers 104, 114, and 124 can utilize charging algorithms to optimize the charging schedule of traction battery 102 based on the power consumption of residence 110. For example, the charging algorithm can refer to the aforementioned lookup table, which specifies outputs for certain inputs. Some lookup tables can accept the outputs of other tables as inputs (e.g., a lookup table specifying how long discharge is allowed can take the time required to charge battery 102 to a specific SOC as input). The charging algorithm can determine a third set of state-of-charge data based on one or more objectives. These objectives can be prioritized to include: achieving a user-specified minimum SOC, achieving the minimum SOC required for a planned trip, maximizing discharge, and extending battery life. Computers 104, 114, and 124 can receive a first set of state-of-charge data and a second set of state-of-charge data as inputs, and utilize the charging algorithm and lookup tables to determine a simulation 200 that maintains the SOC of traction battery 102 above a minimum specified SOC, achieves the minimum SOC required for a planned trip when the planned trip is set to start, maximizes discharge after ensuring the first two objectives are met, and extends battery life.

[0063] The third set of charging status data may include a selection of preset charging programs from multiple preset charging programs. These preset charging programs may be set by a utility company, the manufacturer of vehicle 100, or a fleet operator. Each preset charging program may define the charging rate for vehicle 100, the amount of charging allocated to vehicle 100, and / or charging pricing. Pricing may include pricing based on time of day, charging frequency or quantity, a flat rate, etc. Simulation can optimize the third set of charging status data by selecting the optimal preset charging program from the preset programs. The optimal preset charging program may be best in terms of pricing, keeping vehicle 100 charged according to user preferences, and extending the lifespan of the traction battery 102. Computers 104, 114, and 124 may register users to the preset charging programs selected by the utility company, manufacturer, or fleet operator. Preset charging programs may be subscription-based. Registering a user to a selected preset charging program may include unregistering the user from a previously selected preset charging program.

[0064] Alternatively or additionally, the third set of state-of-charge data may include adjustments to any or all data points of the first and second sets of state-of-charge data. For example, the third set of state-of-charge data may include values ​​of parameters that define the charging and / or discharging of vehicle 100 and / or residence 110. These parameters may include the minimum and maximum permissible state of charge of vehicle 100, preferred charging and preferred discharging times, discharge limits (e.g., daily or weekly), etc.

[0065] The third set of charging state data includes the charge level to be transferred between residence 110 and vehicle 100 (e.g., as part of a preset charging program or as a parameter). That is, the charging algorithm can determine how much charge is discharged from traction battery 102 to residence 110 and how much charge is supplied from residence 110 to traction battery 102 via home charging station 112. The charging algorithm can calculate the charge level to be transferred based on data from the first and second sets of data, including the absolute minimum SOC to be maintained on traction battery 102, operating mode (e.g., planned trip of vehicle 100), minimum SOC required for vehicle 100 to complete the planned trip, and user preferences (e.g., a specific SOC specified by the user, threshold consumption of residence 110 before traction battery 102 discharges, etc.). When traction battery 102 is connected to home charging station 112, the charging algorithm can prevent traction battery 102 from discharging in scenarios where traction battery 102 has a SOC below the specified minimum SOC. For example, if the user specifies to maintain a minimum SOC of 30% and the traction battery 102 has a SOC of 20%, then computers 104, 114, 124 can simulate and actuate home charging station 112 to charge the traction battery 102 to 30% or higher, without simulating or actuating any further discharge (e.g., to prevent redundant charge exchange between vehicle 100 and residence 110).

[0066] The third set of charging state data includes user preferences (e.g., as parameters). As described above, computers 104, 114, and 124 can receive user input and adjust simulation 200 based on the user input. For example, the user can specify a minimum SOC that the traction battery 102 must maintain at a specific time (e.g., the traction battery 102 is specified to maintain at least 30% SOC during the period from 20:00 to 7:00). As further mentioned above, the charging algorithm can prioritize objectives and determine simulation 200 based on the relative priority of the objectives. Maintaining the specified minimum charge level could be the highest priority objective, followed by maintaining sufficient charge for the planned trip, etc. If vehicle 100 connects to home charging station 112 when its SOC is below the specified minimum, computers 104, 114, and 124 can recommend charging the traction battery 102 to the minimum SOC in simulation 200.

[0067] Generating a third set of charging state data includes optimizing the lifespan of battery 102 by interrupting charging. Maintaining the SOC between 20% and 80% can extend the lifespan of battery 102. Computers 104, 114, and 124 can adjust the charging algorithm to extend the lifespan of the traction battery 102 based on stored instructions or user input authorizing computers 104, 114, and 124 to do so. In an exemplary scenario where computer 104, 114, and 124 require user approval, if the user approves computer 104, 114, and 124 to adjust the charging algorithm to extend the lifespan of the traction battery 102, then computer 104, 114, and 124 can prioritize the goal of extending the traction battery's lifespan over other goals. In such an example, computer 104, 114, and 124 can determine simulation 200 such that a global minimum SOC and a global maximum SOC optimize the lifespan of battery 102 specified by stored instructions (e.g., a minimum of 20% and a maximum of 80%). Additionally, computers 104, 114, and 124 can adjust the global minimum SOC and global maximum SOC based on the planned trip. For example, if the duration of the planned trip is less than a specified length (e.g., 40 miles), computers 104, 114, and 124 can reduce the maximum SOC by a specified amount stored in memory (e.g., 60% instead of 80%).

[0068] Generating the third set of state-of-charge data may include optimizing the estimate of monetary savings compared to the first and second sets of state-of-charge data. Based on data from the first and second sets of state-of-charge data, including residence 110 consumption, utility plans, vehicle 100 operating patterns (e.g., how much additional SOC (if any) the traction battery 102 receives from public charging station 122 during a trip, which can then be discharged back to residence 110), computers 104, 114, and 124 may determine simulation 200 to optimize the user's savings. For example, if the vehicle 100's operating pattern indicates (e.g., as determined by computers 104, 114, and 124 based on historical data) that the vehicle 100 will travel to a location with public charging station 122 on a specific date, computers 104, 114, and 124 may adjust simulation 200 to reduce charging time at home charging station 112 relative to the length of time the vehicle 100 spends at public charging station 122. As another example, computers 104, 114, and 124 can request permission from the operator to prioritize price over maintaining a minimum charge level, and thus discharge a larger portion of the SOC to residence 110. As yet another example, computers 104, 114, and 124 can select the most affordable preset charging program from a preset charging program.

[0069] Computers 104, 114, and 124 are programmed to actuate one or both of residence 110 and / or vehicle 100 to charge based on the third set of charging state data. For example, computers 104, 114, and 124 may actuate vehicle 100 to charge at a charging rate and within an allocated charging time or amount specified by a selected preset charging plan. As another example, computers 104, 114, and 124 may actuate vehicle 100 to charge according to parameters such as charging to the maximum permissible state of charge or starting at a preferred charging time. Computers 104, 114, and 124 may actuate residence 110 and / or vehicle 100 based on stored permissions, or may request permissions from a user. In an example where computers 104, 114, and 124 are capable of or permitted to actuate residence 110 and / or vehicle 100, computers 104, 114, and 124 may discharge from traction battery 102 to residence 110 at a time specified in simulation 200 and interrupt charging of traction battery 102 at a time specified in simulation 200. As described above, computers 104, 114, and 124 may additionally adjust the maximum or minimum SOC of traction battery 102.

[0070] Computers 104, 114, and 124 can actuate the traction battery 102 to charge based on the third set of charging state data, determined by overriding user preferences. Computers 104, 114, and 124 can store permissions (e.g., from the development stage) in memory to overridden user preferences in a specified scenario where computers 104, 114, and 124 determine to do so. For example, computers 104, 114, and 124 can store a user preference to overridden the traction battery 102 to have a minimum SOC of 100%. Instead, computers 104, 114, and 124 can overridden that preference and treat the minimum SOC as 80% to extend the lifespan of the battery 102. Computers 104, 114, and 124 can, for example, overridden user preferences where the user has previously permitted computers 104, 114, and 124 to do so (e.g., by subscribing to the aforementioned service plan).

[0071] Figure 2AAn exemplary simulation 200 (based on the first and second data sets as described above) is shown, including a predicted charging schedule 205 and a virtual model 210. Computers 104, 114, and 124 predict the schedule of vehicle 100 based on the first data set and propagate the predicted charging schedule 205. The predicted charging schedule 205 predicts that from T1 until time T2, the vehicle will discharge 20% of its SOC, then recharge 40% until T4 and remain in standby until T5, at which point vehicle 100 is used by the operator and consumes 20% of its SOC (e.g., -20% of expected charge). Simulation 200 further predicts that at time T6, the traction battery 102 will discharge 30% of its SOC until T7 and remain in standby until T8, at which point the traction battery 102 will recharge 40%. At T9, vehicle 100 will remain in standby until T10, at which point vehicle 100 will be used and experience -25% of expected charge. At T11, vehicle 100 returns to home charging station 112 and remains on standby until it discharges to 30% SOC until T12, at which point the predicted charging schedule 205 ends. Virtual model 210 shows that by T4, the user deviates from the predicted charging schedule 205 because only 16% SOC was discharged between T1 and T2, and there is only enough time from T3 to T4 to recharge to 30%, at which point the vehicle disconnects from charging station 112. Therefore, computers 104, 114, and 124 propagate virtual model 210.

[0072] Figure 2B It shows Figure 2A This continues, with users deviating further from the predicted charging schedule by 205. Besides... Figure 2A Beyond the deviation between T1 and T4 shown, at T7, vehicle 100 returns to home charging station 112 having consumed 30% of its SOC, instead of the 20% predicted by the predicted charging schedule 205. Vehicle 100's insertion into home charging station 112 is triggered (as described above), causing computers 104, 114, and 124 to adjust simulation 200. At T7, based on virtual model 210 and the first and second data sets, the computers adjust predicted charging schedule 205 to predict no discharge at T6, instead remaining in standby from T7 to T8 before charging. At T8, the computers adjust predicted charging schedule 205 to predict that the traction battery 102 will recharge by 45% of its SOC until T9 while vehicle 100 is in standby, instead of the originally predicted 40% SOC recharge. At T10, vehicle 100 is used and is predicted to consume 25% of its SOC until T11, at which point vehicle 100 returns to home charging station 112. At T12, the traction battery 102 discharges to 30% SOC until T13, at which point the vehicle 100 is ready and the predicted charging schedule 205 ends.

[0073] Figure 2C It shows Figure 2A and Figure 2B The process continues. Vehicle 100 returns to home charging station 112 at T7 and begins recharging at T8. However, the actual data represented in the virtual model 210 deviates again from the predicted charging schedule 205, as vehicle 100 only recharges to 30% SOC instead of the predicted 45%. Computers 104, 114, and 124 await the next trigger.

[0074] Figure 2D It shows Figures 2A to 2C Further, vehicle 100 returns to home charging station 112 at T9, having consumed 70% of its SOC instead of the predicted 25%. Therefore, computers 104, 114, and 124 update the predicted charging schedule 205 so that at T9, vehicle 100 is predicted to recharge by 50% of its SOC before being put on standby from T10 to T11, after which the vehicle will discharge 40% of its SOC from T11 to T12 to T13.

[0075] Figure 2E It shows Figures 2A to 2D This continues further. Vehicle 100 disconnects from home charging station 112 after T13, while maintaining the predicted charging schedule 205 between T9 and T13.

[0076] Figure 2F It shows Figures 2A to 2E The process continues. The timeline has progressed to the end of the predicted charging schedule. Then, computers 104, 114, and 124 propagate a virtual model 210 representing the actual data of vehicle 100. Computers 104, 114, and 124 may use additional data from the third data set described above to propagate the virtual model 210.

[0077] Example process

[0078] Figure 3This is a flowchart illustrating an exemplary process 300 for actuating residence 110 and / or vehicle 100 based on a third set of charging state data generated by simulation 200. The memories of computers 104, 114, and 124 store executable instructions for performing the steps of process 300, and / or can be programmed using structures such as those mentioned above. As a general overview of process 300, computers 104, 114, and 124 detect vehicle 100. In response to detecting vehicle 100, computers 104, 114, and 124 receive a first set of charging state data, receive a second set of charging state data, simulate power consumption, generate a third set of charging state data, and determine whether computers 104, 114, and 124 have the authority to actuate vehicle 100 and / or residence 110. In response to computers 104, 114, and 124 having the authority to actuate vehicle 100 and / or residence 110, computers 104, 114, and 124 actuate vehicle 100 and / or residence 110. As long as computers 104, 114, and 124 remain on, process 300 can continue.

[0079] The process begins in box 310, where computers 104, 114, and 124 detect whether a triggering event has occurred, as described above. In the example of Figure 2, the triggering event is that vehicle 100 connects to home charging station 112. In response to the occurrence of the triggering event, process 300 proceeds to box 315. Otherwise, process 300 proceeds to decision box 345.

[0080] In box 315, computers 104, 114, and 124 receive a first set of charging status data from vehicle 100, as described above.

[0081] Next, in box 320, computers 104, 114, and 124 receive a second set of charging status data from residence 110, as described above.

[0082] Next, in box 325, computers 104, 114, and 124 simulate the power consumption of residence 110 based on the second set of charging status data, as described above.

[0083] Next, in box 330, computers 104, 114, and 124 generate a third set of charging state data based on the first and second sets of charging state data, as described above. Computers 104, 114, and 124 can utilize a charging algorithm that prioritizes various targets and thus produces different outputs.

[0084] Next, in decision box 335, computers 104, 114, and 124 determine whether they have the authority to actuate residence 110 and / or vehicle 100 to charge based on the third set of charging status data, as described above. The authority may be pre-stored by computers 104, 114, and 124 or granted by an operator. Alternatively, the authority may appear as part of a preset charging procedure. If computers 104, 114, and 124 have the authority, process 300 continues to box 340. Otherwise, the process continues to decision box 345.

[0085] In box 340, computers 104, 114, and 124 actuate residence 110 and / or vehicle 100 to charge or discharge based on the third set of charging status data, as described above. After box 340, process 300 proceeds to decision box 345.

[0086] In decision box 345, computers 104, 114, and 124 determine whether to continue process 300. For example, computers 104, 114, and 124 may determine the next twenty-four hours of simulation 200 and stop operation until the triggering event occurs as described above. In response to the triggering event, process 300 returns to box 310. Otherwise, process 300 ends.

[0087] Computing devices such as those discussed herein typically each include commands that can be executed by one or more computing devices, such as those identified above, and used to carry out blocks or steps of the processes described above. For example, the process blocks discussed above can be embodied as computer-executable commands.

[0088] Computer-executable commands can be compiled or interpreted by computer programs created using a variety of programming languages ​​and / or technologies, including but not limited to single or combined forms of the following: Java™, C, C++, Python, Julia, SCALA, Visual Basic, JavaScript, Perl, HTML, etc. Typically, a processor (i.e., a microprocessor) receives (i.e., from memory, computer-readable media, etc.) commands and executes these commands, thereby performing one or more processes, including those described herein. Such commands and other data may be stored in files and transferred using a variety of computer-readable media. Files in a computing device are typically collections of data stored on computer-readable media such as storage media, random access memory, etc.

[0089] Computer-readable media (also known as processor-readable media) include any non-transitory (i.e., tangible) medium that contributes to providing data (i.e., instructions) that can be read by a computer (i.e., by the computer's processor). Such media can take many forms, including but not limited to non-volatile and volatile media. Instructions can be transmitted via one or more transmission media, including optical fibers, wires, wireless communications, and internals that constitute a system bus coupled to the computer's processor. Common forms of computer-readable media include, for example, RAM, PROM, EPROM, FLASH-EEPROM, any other memory chip or magnetic tape, or any other medium from which a computer can read.

[0090] Unless otherwise expressly indicated herein, all terms used in the claims are intended to be given the ordinary and common meaning as understood by those skilled in the art. In particular, unless the claim statement expressly limits it 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 statement.

[0091] In the accompanying drawings, the same reference numerals indicate the same elements. Furthermore, some or all of these elements may be changed. Regarding the media, processes, systems, methods, etc., described herein, it should be understood that although the steps of such processes, etc., are described as occurring in a specific sequence, such processes can be practiced by performing the described steps in an order other 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 certain embodiments and should in no way be construed as limiting the claimed invention.

[0092] The use of “in response to,” “based on,” and “after determining” in this document indicates a causal relationship, not just a temporal one. Unless otherwise expressly stated, “based on” or “in response to” may mean at least partially based on or at least partially in response to.

[0093] Examples are contemplated herein. Any example embodiments or features described herein are not necessarily to be construed as preferred or advantageous over other embodiments or features. Furthermore, the example embodiments described herein are not intended to be limiting. It should be readily understood that certain aspects of the disclosed systems and methods can be arranged and combined in a variety of different configurations, all of which are contemplated herein. Additionally, the specific arrangements shown in the figures should not be considered limiting. It should be understood that other embodiments may include more or fewer of each element shown in a given figure. Additionally, some of the shown elements may be combined or omitted. Furthermore, exemplary embodiments may include elements not shown in the figures.

[0094] This disclosure has been described in an illustrative manner, and it should be understood that the terminology used is intended to be descriptive and not restrictive. In light of the foregoing teachings, many modifications and variations of this disclosure are possible, and this disclosure may be practiced in ways other than those specifically described. The adjectives “first,” “second,” and “third” are used throughout this document as identifiers and are not intended to indicate importance, order, or quantity. The operations, systems, and methods described herein should always be implemented and / or performed in accordance with applicable user manuals and / or safety guidelines.

[0095] According to the present invention, a system is provided, the system comprising a computer having a processor and a memory, the memory storing instructions executable by the processor to: receive a first set of charging state data regarding a vehicle; receive a second set of charging state data regarding a residence associated with the vehicle; simulate the power consumption of the vehicle and the residence based on the set of charging state data to generate a third set of charging state data; and actuate at least one of the vehicle or the residence to charge according to the third set of charging state data.

[0096] According to an embodiment, the first set of charging status data includes the vehicle charging schedule.

[0097] According to an embodiment, the second set of charging status data includes the residential utility plan.

[0098] According to an embodiment, the group charging status data includes user preferences.

[0099] According to an embodiment, the second set of charging status data includes the residence power consumption.

[0100] According to an embodiment, the first set of charging status data includes the vehicle's operating mode.

[0101] According to an embodiment, the group of charging status data includes the charge level to be transferred between the residence and the vehicle.

[0102] According to an embodiment, the instructions further include instructions for performing the following operations: charging based on the third set of charging status data based on the determination of the user's preferences.

[0103] According to an embodiment, generating the third set of charging status data includes optimizing battery lifespan by interrupting the charging process.

[0104] According to an embodiment, the third set of charging status data includes a subscription service for an energy consumption plan.

[0105] According to an embodiment, generating the third set of charging state data includes optimizing the estimate of monetary savings compared with the first set of charging state data and the second set of charging state data.

[0106] According to the present invention, a method includes: receiving a first set of charging state data regarding a vehicle; receiving a second set of charging state data regarding a residence associated with the vehicle; simulating the power consumption of the vehicle and the residence based on the set of charging state data to generate a third set of charging state data; and actuating at least one of the vehicle or the residence to charge according to the third set of charging state data.

[0107] In one aspect of the invention, the first set of charging status data includes a vehicle charging schedule.

[0108] In one aspect of the invention, the second set of charging status data includes the utility plans for the residence.

[0109] In one aspect of the invention, the group charging status data includes user preferences.

[0110] In one aspect of the invention, the second set of charging state data includes residence power consumption.

[0111] In one aspect of the invention, the first set of charging status data includes the operating mode of the vehicle.

[0112] In one aspect of the invention, the group of charging state data includes the charge level to be transferred between the residence and the vehicle.

[0113] In one aspect of the invention, the method includes charging based on the third set of charging state data, determined by overdrive user preferences.

[0114] In one aspect of the invention, generating the third set of state-of-charge data includes optimizing battery life by interrupting the charging process.

Claims

1. A method comprising: Receive the first set of charging status data about the vehicle; Receive a second set of charging status data regarding the residence associated with the vehicle; Based on the aforementioned set of charging status data, the electricity consumption of the vehicle and the residence is simulated to generate a third set of charging status data; as well as The third set of charging status data is used to actuate at least one of the vehicle or the residence to charge.

2. The method of claim 1, wherein the first set of charging status data includes a vehicle charging schedule.

3. The method of claim 1, wherein the second set of charging status data includes the utility plan of the residence.

4. The method of claim 1, wherein the group charging status data includes user preferences.

5. The method of claim 1, wherein the second set of charging state data includes residential power consumption.

6. The method of claim 1, wherein the first set of charging status data includes the operating mode of the vehicle.

7. The method of claim 1, wherein the group charging state data includes the charge level to be transferred between the residence and the vehicle.

8. The method of claim 1, further comprising charging based on the determination of the user's preferences according to the third set of charging status data.

9. The method of claim 1, wherein generating the third set of state-of-charge data includes optimizing battery life by interrupting the charging process.

10. The method of claim 1, wherein the third set of charging status data includes selection from a plurality of preset charging programs.

11. The method of claim 1, wherein generating the third set of charging state data includes optimizing the estimate of monetary savings compared with the first set of charging state data and the second set of charging state data.

12. A computer programmed to perform the method as described in any one of claims 1 to 11.

13. A vehicle comprising a computer programmed to perform the method as described in any one of claims 1 to 11.

Images