Patent ID: 12228414

DETAILED DESCRIPTION

Again, in various embodiments, the present disclosure relates to a carbon emission optimized charging vehicle route planning system and methods that refine conventional vehicle route planning by considering and accounting for carbon emissions in the presentment and selection of available routes and locations of charging stations. In particular, charging stations (such as fast charging locations) are each mapped to associated utility grid locations and the emissions data (such as real-time emissions data, historical emissions data, and projected emissions data) for those grid locations are used to determine/forecast carbon emissions for each of the charging stations at the time the vehicle is projected to pass through and utilize the respective charging stations. As will be discussed in further detail below, this information is presented to a user (such as a vehicle operator), such as with determined routes for a trip between at least two points of interest, which of those routes would minimize carbon emissions, and which charging station would minimize the carbon emissions along each route to allow the user to select which route to follow and select which charging station to utilize.

FIG.1is a schematic illustration of one illustrative embodiment of a carbon emission optimized charging vehicle route planning system10of the present disclosure. In various embodiments, the vehicle route planning system10includes at least a vehicle140and one or more data sources30. The data sources30carbon emissions data for the associated utility grid locations of charging stations50. The charging stations50are adapted for charging a battery142, such as an arrangement of battery cells, of the vehicle140. In some embodiments, the charging stations50are equipped with one or more renewable energy sources55, such as solar panels, that are adapted to provide power for charging the vehicle140.

In embodiments, one of a cloud system100, a user device, or a combination thereof utilizes the carbon emissions data to determine carbon emissions for each of the charging stations at a time that the vehicle140is projected to pass through and utilize the charging stations50and is/are configured to optimize a vehicle route between at least two points of interest while minimizing the carbon emissions to produce the power consumed to charge the vehicle140while traveling on that vehicle route. In some embodiments, determining the carbon emissions for each of the charging stations50is further based on the one or more renewable energy sources55at the charging station50, such as, which percentage of the power provided by the one or more renewable energy sources55for charging vehicles140. In embodiments, the user device is one of a controller145of the vehicle140and a mobile device150. In some embodiments, the controller145is or part of any control system, infotainment system, and the like of the vehicle140; and the mobile device150is or part of a cellular phone, a tablet, a laptop, and the like. In various embodiments, the cloud system100, the user device, or the combination thereof utilizes data including the carbon emissions data associated with each charging station50, an SOC of the vehicle, projected power consumption/range of the vehicle140, and the like, to optimize carbon emissions for charging the vehicle140by providing both a route and a charging station50that will minimize the carbon emissions produced for the power consumed by the vehicle140.

In some embodiments, a data aggregation system40is utilized. The data aggregation system40is configured to obtain the carbon emissions data associated with the utility grid locations and provide carbon emissions data including one or more of real-time carbon emissions data, historical carbon emissions data, and carbon forecasted emissions data. In these embodiments, the cloud system100or the user device obtains the carbon emissions data from the data aggregation system40. In other embodiments, the cloud system100is configured to obtain the carbon emissions data associated with the utility grid locations from the data sources30and determine emissions data for each charging station50including one or more of real-time emissions data, historical emissions data, and forecasted emissions data for each charging station50. In embodiments, the emissions data is any of an amount of carbon emitted, a scaled score, such as a scale from clean emissions to dirty emissions, and the like. In some embodiments, the data sources30are the utility grid locations. In some embodiments, the cloud system100is also configured to obtain data for the one or more renewable energy sources55from each charging station50, such as power produced thereby, a percentage of power provided thereby to the charging station50, and the like. In some of these embodiments, the cloud system100is configured to combine the carbon emissions data for the utility grid locations with the renewable energy sources data to determine the emissions data for each charging station50.

In some embodiments, the cloud system100is configured to map each charging station50with a utility grid location to identify which utility grid location provides power thereto. In other embodiments, the data aggregation system40performs this function.FIG.2is a map200illustrating a snapshot of exemplary regional emissions intensity. Referring toFIG.2, regional utility grid location210,220,230,240,250has an emissions intensity based on how the power in the region is produced. In the map200illustrated inFIG.2the emissions intensity is highest in regional utility grid location210, followed by regional utility locations220and230. As such, charging the vehicle140at one of the charging stations50within regional utility grid location210will most likely result in a higher net effect in emissions as compared to charging the vehicle140at one of the charging stations50located in regional utility grid locations220and230. In some embodiments, other factors, such as trip deviations to reach each charging station50and projected power consumption of the vehicle for traveling on those trip deviations, and the like, are also considered in determining the net effect charging the vehicle140will have at each location. For example, different distances traveled, different elevation changes made, and the like, can affect the power consumed by the vehicle140while traveling to/from a charging station50.

FIG.3is a schematic illustration of one illustrative embodiment of a User Interface (UI)300highlighting a route map302for carbon optimization of the present disclosure. The UI300is presented to a user on a display of the user device, such as on a display of the controller145in the vehicle140or a display of the mobile device150. In some embodiments, information for the UI can be shared between the controller145and the mobile device150, such as being pushed from one to the other.

The UI300is configured to display the route map302illustrating a route310between at least two points of interest including a starting point illustrated by a starting point icon315, destination illustrated by a destination icon317, and one or more charging stations along the route310illustrated by a charging station icon350. In embodiments, the UI300is configured to identify the charging station350that optimizes carbon emissions, such as by minimizing an amount of carbon emissions discharged to produce the power used during travel of the vehicle140along the route310. In various embodiments, this identification is performed by distinguishing the charging station350with some type of demarcation320in the UI300or by removing other charging stations350from the route map302, and the like. In embodiments, the demarcation320is any of displaying the charging station icon350in a different color, a symbol being positioned on or adjacent to the charging station icon350, a border placed around the charging station icon350, and the like.

In some embodiments, the UI300is configured to display charging station information330for each charging station, such as adjacent to the associated charging station icon350. In some of these embodiments, the charging station information330includes emissions data, such as any of current emissions data, historical emissions data, and projected emissions data for a time that the vehicle140traveling on the route310is projected to arrive thereat. Other information, such as charging station availability, wait times, and the like, can also be displayed. In some embodiments, the charging station information330is always displayed. In other embodiments, the charging station information330is displayed upon selection of the respective charging station icon350or by activation of an option for the display thereof.

FIG.4is a schematic illustration of one illustrative embodiment of the UI300highlighting a route map302with thresholded deviations of routes311,312,313including a route311for carbon emission optimization of the present disclosure. In embodiments, one of the cloud system100, the user device (such as the controller145of the vehicle140or a mobile device150), or a combination thereof determines multiple deviations for traveling between the starting point and the destination. Once determined, the UI300is configured to display the routes311,312,313of those deviations therein. In embodiments, each of these deviations is thresholded to provide travel options to the user. For example, in the embodiment illustrated inFIG.4, the route311is thresholded to minimize carbon emissions, the route312is thresholded to minimize travel distance, and the route313is thresholded to minimize travel time. In some embodiments, other deviations are also presented in the UI300, such as routes that include one or more other points of interest, routes that consider projected wait times at the charging stations, or routes that include a hybrid of thresholds, such as travel time, charging time/wait time, distance, and carbon optimization.

In embodiments, upon receipt of a selection of one of the routes311,312,313, the UI300is configured to display only the route selected, such as the route310illustrated inFIG.3. In some of these embodiments, the UI300is configured to identify the charging station that will optimize carbon emissions by displaying the respective charging station icon350with the demarcation320. In some embodiments, the UI300is configured to receive a selection of a charging station icon350to identify which charging station the user intends to use to charge the vehicle140. In some of these embodiments, upon receipt of the selection, the vehicle route planning system10, such as via any combination of the user device, the cloud system100, and the charging station50reserve a charger at the charging station50for the vehicle140at a projected arrival time, such as an arrival window.

In some embodiments, the routes311,312,313are optimized with multiple points of interest over a multi-day trip. In these embodiments, the charging for the vehicle is optimized over the multiple days rather than the individual days.

In some embodiments, the charging is re-optimized during a trip to account for any changes in conditions in carbon emissions at any of the charging stations50, changes in the SOC of the battery142of the vehicle140, and the like. The re-optimization can be performed in real time, in intervals, and the like.

FIG.5is a flowchart of one illustrative embodiment of a method500for vehicle route planning to optimize carbon emissions by utility grids providing power for charging of an electric vehicle of the present disclosure. The method includes determining a route between points of interest that optimizes carbon emissions associated with charging a vehicle traveling on the route by analyzing carbon emissions data for utility grid locations associated with charging stations on the route to identify which charging station minimizes the carbon emissions at step502. The method also includes providing the route and the identified charging station to a user for navigation of the vehicle thereon at step504.

In embodiments of the method, providing the route and the identified charging station to the user includes presenting a route map to the user on a user interface that illustrates the route and demarks a charging station icon to identify the charging station that optimizes carbon emissions thereon. In embodiments of the method, the carbon emissions data includes at least one of real-time carbon emissions data, historical carbon emissions data, and projected carbon emissions data.

In embodiments of the method, identifying which charging station on the route minimizes the carbon emissions data is based on projecting the carbon emissions associated with the charging stations at a projected arrival time of the vehicle at each of the charging stations.

In some embodiments, the SOC of the battery of the vehicle is used to determine which charging stations are within range of the vehicle and only those charging stations are considered for the route, at least for the first charge of the vehicle traveling on a route that will require multiple charges to complete. In some embodiments where multiple charges are required to travel between two points of interest, the method includes determining how much to charge the battery at each location in order to minimize the carbon emissions associated with the charging of the battery, while ensuring sufficient charge is available to travel to the next charging station. For example, if a trip requires stopping at a first charging station and a second charging station and the first charging station has a higher emissions score than the second charging station, carbon emissions are optimized by limiting the charging of the battery to an amount needed for the vehicle to reach the second charging station and then performing a full charge of the battery at the second charging station. In some embodiments where multiple charges are required for the route, the method includes identifying a first charging station within range a range of the vehicle, based on a SOC of the battery, that optimizes the carbon emissions, identifying a second charging station that is within the range of the vehicle from the first charging station and optimizes carbon emissions, comparing the carbon emissions produced by the first charging station and the second charging station, and in response to the second charging station being associated with less carbon emissions than the first charging station, determining how much to charge the battery of the vehicle at the first charging station in order to reach the second charging station and recommending to the user how much to charge the battery at the first charging station.

In embodiments, the method further includes determining other routes between the points of interest based on other thresholds including routes that minimize travel time and travel distance. In some of these embodiments, the method yet further includes identifying which charging station on the routes that minimize travel time and travel distance minimizes the carbon emissions for charging the vehicle traveling on the routes that minimize travel time and travel distance.

In some embodiments, the method further includes mapping each of the charging stations to respective utility grid locations and obtaining the carbon emissions data for the utility grid locations. In some embodiments, the method yet further includes obtaining renewable energy data from each charging station that includes renewable energy sources and determining emissions data for each charging station utilizing the carbon emissions data and the renewable energy data.

In embodiments, the method, and any of the embodiments outlined above, is performed by a vehicle route planning system including a system chosen from one of the cloud system100, a user device, and a combination of the cloud system100and the user device. In some of these embodiments, the user device is one of the controller145of the vehicle140and the mobile device150.

FIG.6is a network diagram of the cloud system100for implementing various cloud-based services of the present disclosure, where applicable. The cloud system100includes one or more cloud nodes (CNs)102communicatively coupled to the Internet104or the like. In embodiments, the cloud nodes102are implemented as a server or other processing system110(as illustrated inFIG.7) or the like and are geographically diverse from one another, such as located at various data centers around the country or globe. Further, in some embodiments, the cloud system100includes one or more central authority (CA) nodes106, which similarly are implemented as the server110and are connected to the CNs102. For illustration purposes, the cloud system100connects to data sources30, a data aggregation system40, charging stations50, various individual's homes130, vehicles140, and mobile devices150, each of which communicatively couples to one of the CNs102. These locations30,40, and130, and devices140and150are shown for illustrative purposes, and those skilled in the art will recognize there are various access scenarios to the cloud system100, all of which are contemplated herein. The cloud system100can be a private cloud, a public cloud, a combination of a private cloud and a public cloud (hybrid cloud), or the like.

Again, the cloud system100provides any functionality through services, such as software-as-a-service (SaaS), platform-as-a-service, infrastructure-as-a-service, security-as-a-service, Virtual Network Functions (VNFs) in a Network Functions Virtualization (NFV) Infrastructure (NFVI), etc. to the charging stations50, the devices an individual's home130, the vehicles140, and the mobile devices150.

Cloud computing systems and methods abstract away physical servers, storage, networking, etc., and instead offer these as on-demand and elastic resources. The National Institute of Standards and Technology (NIST) provides a concise and specific definition which states cloud computing is a model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. Cloud computing differs from the classic client-server model by providing applications from a server that are executed and managed by a client's web browser or the like, with no installed client version of an application required. Centralization gives cloud service providers complete control over the versions of the browser-based and other applications provided to clients, which removes the need for version upgrades or license management on individual client computing devices. The phrase “software as a service” is sometimes used to describe application programs offered through cloud computing. A common shorthand for a provided cloud computing service (or even an aggregation of all existing cloud services) is “the cloud.” The cloud-based system100is illustrated herein as one example embodiment of a cloud-based system, and those of ordinary skill in the art will recognize the systems and methods described herein are not necessarily limited thereby.

FIG.7is a block diagram of a server or other processing system110, which may be used in the cloud-based system100(FIG.6), in other systems, or stand-alone, such as in the vehicle itself. For example, the CNs102(FIG.6) and the central authority nodes106(FIG.6) may be formed as one or more of the servers110. In embodiments, the server110is a digital computer that, in terms of hardware architecture, generally includes a processor112, input/output (I/O) interfaces114, a network interface116, a data store118, and memory120. It should be appreciated by those of ordinary skill in the art thatFIG.7depicts the server or other processing system110in an oversimplified manner, and a practical embodiment may include additional components and suitably configured processing logic to support known or conventional operating features that are not described in detail herein. The components (112,114,116,118, and120) are communicatively coupled via a local interface122. The local interface122may be, for example, but is not limited to, one or more buses or other wired or wireless connections, as is known in the art. The local interface122may have additional elements, which are omitted for simplicity, such as controllers, buffers (caches), drivers, repeaters, and receivers, among many others, to enable communications. Further, the local interface122may include address, control, and/or data connections to enable appropriate communications among the aforementioned components.

The processor112is a hardware device for executing software instructions. The processor112may be any custom made or commercially available processor, a central processing unit (CPU), an auxiliary processor among several processors associated with the server110, a semiconductor-based microprocessor (in the form of a microchip or chipset), or generally any device for executing software instructions. When the server110is in operation, the processor112is configured to execute software stored within the memory120, to communicate data to and from the memory120, and to generally control operations of the server110pursuant to the software instructions. The I/O interfaces114may be used to receive user input from and/or for providing system output to one or more devices or components.

The network interface116may be used to enable the server110to communicate on a network, such as the Internet114(FIG.6). The network interface116may include, for example, an Ethernet card or adapter (e.g., 10BaseT, Fast Ethernet, Gigabit Ethernet, or 10GbE) or a Wireless Local Area Network (WLAN) card or adapter (e.g., 802.11a/b/g/n/ac). The network interface116may include address, control, and/or data connections to enable appropriate communications on the network. A data store118may be used to store data. The data store118may include any of volatile memory elements (e.g., random access memory (RAM, such as DRAM, SRAM, SDRAM, and the like)), nonvolatile memory elements (e.g., ROM, hard drive, tape, CDROM, and the like), and combinations thereof. Moreover, the data store118may incorporate electronic, magnetic, optical, and/or other types of storage media. In one example, the data store118may be located internal to the server110, such as, for example, an internal hard drive connected to the local interface122in the server110. Additionally, in another embodiment, the data store118may be located external to the server110such as, for example, an external hard drive connected to the I/O interfaces114(e.g., a SCSI or USB connection). In a further embodiment, the data store118may be connected to the server110through a network, such as, for example, a network-attached file server.

In embodiments, the memory120may include any of volatile memory elements (e.g., random access memory (RAM, such as DRAM, SRAM, SDRAM, etc.)), nonvolatile memory elements (e.g., ROM, hard drive, tape, CDROM, etc.), and combinations thereof. Moreover, the memory120may incorporate electronic, magnetic, optical, and/or other types of storage media. Note that the memory120may have a distributed architecture, where various components are situated remotely from one another but can be accessed by the processor112. The software in memory120may include one or more software programs, each of which includes an ordered listing of executable instructions for implementing logical functions. The software in the memory120includes a suitable operating system (O/S)124and one or more programs126. The operating system124essentially controls the execution of other computer programs, such as the one or more programs126, and provides scheduling, input-output control, file and data management, memory management, and communication control and related services. The one or more programs126may be configured to implement the various processes, algorithms, methods, techniques, etc. described herein.

It will be appreciated that some embodiments described herein may include one or more generic or specialized processors (“one or more processors”) such as microprocessors; central processing units (CPUs); digital signal processors (DSPs); customized processors such as network processors (NPs) or network processing units (NPUs), graphics processing units (GPUs), or the like; field programmable gate arrays (FPGAs); and the like along with unique stored program instructions (including both software and firmware) for control thereof to implement, in conjunction with certain non-processor circuits, some, most, or all of the functions of the methods and/or systems described herein. Alternatively, some or all functions may be implemented by a state machine that has no stored program instructions, or in one or more application-specific integrated circuits (ASICs), in which each function or some combinations of certain of the functions are implemented as custom logic or circuitry. Of course, a combination of the aforementioned approaches may be used. For some of the embodiments described herein, a corresponding device in hardware and optionally with software, firmware, and a combination thereof can be referred to as “circuitry configured or adapted to,” “logic configured or adapted to,” etc. perform a set of operations, steps, methods, processes, algorithms, functions, techniques, etc. on digital and/or analog signals as described herein for the various embodiments.

Moreover, some embodiments may include a non-transitory computer-readable medium having computer-readable code stored thereon for programming a computer, server, appliance, device, processor, circuit, etc. each of which may include a processor to perform functions as described and claimed herein. Examples of such computer-readable mediums include, but are not limited to, a hard disk, an optical storage device, a magnetic storage device, a Read-Only Memory (ROM), a Programmable Read-Only Memory (PROM), an Erasable Programmable Read-Only Memory (EPROM), an Electrically Erasable Programmable Read-Only Memory (EEPROM), flash memory, and the like. When stored in the non-transitory computer-readable medium, software can include instructions executable by a processor or device (e.g., any type of programmable circuitry or logic) that, in response to such execution, cause a processor or the device to perform a set of operations, steps, methods, processes, algorithms, functions, techniques, etc. as described herein for the various embodiments.

FIG.8is a block diagram of a user device160, which may be used in the cloud system100(FIG.6), as part of a network, or stand-alone. In embodiments, the user device160is one of a controller145in a vehicle or a mobile device150, such as a smartphone, a tablet, a smartwatch, a laptop, etc. The user device160can be a digital device that, in terms of hardware architecture, generally includes a processor162, I/O interfaces164, a radio166, a data store168, and memory170. It should be appreciated by those of ordinary skill in the art thatFIG.8depicts the user device160in an oversimplified manner, and a practical embodiment may include additional components and suitably configured processing logic to support known or conventional operating features that are not described in detail herein. The components (162,164,166,168, and170) are communicatively coupled via a local interface172. The local interface172can be, for example, but is not limited to, one or more buses or other wired or wireless connections, as is known in the art. The local interface172can have additional elements, which are omitted for simplicity, such as controllers, buffers (caches), drivers, repeaters, and receivers, among many others, to enable communications. Further, the local interface172may include address, control, and/or data connections to enable appropriate communications among the aforementioned components.

The processor162is a hardware device for executing software instructions. In embodiments, the processor162is any custom made or commercially available processor, a CPU, an auxiliary processor among several processors associated with the user device160, a semiconductor-based microprocessor (in the form of a microchip or chipset), or generally any device for executing software instructions. When the user device160is in operation, the processor162is configured to execute software stored within the memory170, to communicate data to and from the memory170, and to generally control operations of the user device160pursuant to the software instructions. In an embodiment, the processor162may include a mobile optimized processor such as optimized for power consumption and mobile applications. In embodiments, the I/O interfaces164are used to receive user input from and/or for providing system output and includes a touch screen display. User input can be provided via, for example, a user interface on a touch screen display (such as UI300), a keypad, a scroll ball, a scroll bar, buttons, and the like. System output can be provided via a display device such as a liquid crystal display (LCD), touch screen, and the like.

The radio166enables wireless communication to an external access device or network. Any number of suitable wireless data communication protocols, techniques, or methodologies can be supported by the radio166, including any protocols for wireless communication. The data store168may be used to store data. The data store168may include any of volatile memory elements (e.g., random access memory (RAM, such as DRAM, SRAM, SDRAM, and the like)), nonvolatile memory elements (e.g., ROM, hard drive, tape, CDROM, and the like), and combinations thereof. Moreover, the data store308may incorporate electronic, magnetic, optical, and/or other types of storage media.

Again, in embodiments, the memory170includes any of volatile memory elements (e.g., random access memory (RAM, such as DRAM, SRAM, SDRAM, etc.)), nonvolatile memory elements (e.g., ROM, hard drive, etc.), and combinations thereof. Moreover, the memory170may incorporate electronic, magnetic, optical, and/or other types of storage media. Note that the memory170may have a distributed architecture, where various components are situated remotely from one another, but can be accessed by the processor162. The software in memory170can include one or more software programs, each of which includes an ordered listing of executable instructions for implementing logical functions. In the example ofFIG.8, the software in the memory170includes a suitable operating system174and programs176. The operating system174essentially controls the execution of other computer programs and provides scheduling, input-output control, file and data management, memory management, and communication control and related services. The programs176may include various applications, add-ons, etc. configured to provide end user functionality with the user device160. For example, example programs176may include, but not limited to, a web browser, social networking applications, streaming media applications, games, mapping and location applications, electronic mail applications, financial applications, and the like. In a typical example, the end-user typically uses one or more of the programs176along with a network, such as the cloud system100(FIG.6).

Although the present disclosure is illustrated and described herein with reference to illustrative embodiments and specific examples thereof, it will be readily apparent to those of ordinary skill in the art that other embodiments and examples may perform similar functions and/or achieve like results. All such equivalent embodiments and examples are within the spirit and scope of the present disclosure, are contemplated thereby, and are intended to be covered by the following non-limiting claims for all purposes.