Automated routing through electric vehicle charging stations

Abstract

To navigate the electric vehicle from an origin to a destination, the system identifies a plurality of charging stations between the origin and the destination and determines a navigation route requiring a minimum amount of time for the electric vehicle to travel from the origin to the destination via one or more of the charging stations, the determination including determining a nonlinear relationship between the amount of time and the amount of charge the EV receives during the amount of time.

Description

[Technical field]

[0001] FIELD OF THE DISCLOSURE This disclosure relates to navigation instructions, and more particularly, to generating navigation instructions for electric vehicles that require charging stations. [Background technology]

[0002] The background discussion provided herein is intended to generally present the context of the present disclosure. The work of the currently named inventors to the extent described in this background section, and aspects of the present specification that may not qualify as prior art at the time of filing, are not admitted expressly or impliedly as prior art to the present disclosure.

[0003] Electric vehicles (EVs) have numerous advantages over conventional vehicles with internal combustion engines. However, operating an EV also presents certain challenges for drivers, such as locating charging stations during long drives, especially in rural areas. Unlike gas stations, electric charging stations are relatively scarce. Furthermore, while gas stations offer standardized fuel and nozzle types, fast refueling, and predictable range for vehicles, different electric charging stations contain various equipment that is not always compatible with each vehicle, and different charging speeds can cause additional delays for EV drivers. Furthermore, the range of an EV depends on many external factors, such as the terrain, the route infrastructure (such as stop signs and traffic lights), and the ambient temperature. These factors make it difficult for EV drivers to make accurate trip plans. Summary of the Invention [Means for solving the problem]

[0004] The system of the present disclosure generates a navigation route for an electric vehicle (EV) from an origin to a destination such that the navigation route corresponds to the shortest time it takes for the EV to reach the destination with one or more stops at electric charging stations compared to other candidate routes the system may identify. To this end, the system determines a non-linear relationship between time and the amount of charge the charging station will transfer to the EV during this time, e.g., 10 minutes for 10% charge capacity, 20 minutes for 15% charge capacity, etc.

[0005] To prepare for efficient servicing of requests for navigation directions, the system can pre-compute a navigation graph in which charging stations define nodes and edges define paths between pairs of charging stations. The terms "node" and "vertex" are used interchangeably in this disclosure. More specifically, the system can build an initial highly connected graph with a number of connections between pairs of charging stations, determine a minimum spanning tree (MST) along which an electric vehicle can travel between the charging stations, and select a subset of the remaining edges of the highly connected graph to add to the MST to define the navigation graph. The system can base the selection of an edge that is not within the MST on whether the edge defines a path between pairs of charging stations that is significantly better than an indirect path along the MST, e.g., whether the path provides an improvement in time beyond a certain predefined threshold.

[0006] To account for the nonlinear dependency between charge amount and charging time, the system can generate a bipartite graph for the nodes representing the charging stations. One set of subnodes in the bipartite graph can represent the charge amount upon arrival at the charging station, another set of subnodes in the bipartite graph can represent the charge amount upon departure from the charging station, and edges represent the amount of time it takes to increase the charge amount. Thus, for example, a subnode representing a 20% charge level in the first set can be linked to a subnode representing an 80% charge level in the second set via an edge having a weight of 40 to represent a 40 minute delay.

[0007] When servicing a request to generate navigation directions from a start location S to a destination D, the system may add a node representing the start location S and a node representing the destination D to the pre-computed navigation graph. The system may connect each of these new nodes to up to X nodes in the pre-computed navigation graph. Each new connection may represent the shortest path to a corresponding charging station.

[0008] Additionally, in some implementations, the system determines or adjusts the non-linear relationship between the amount of time and the amount of charge, taking into account factors such as the type of EV, the type of equipment available at the charging station, and the age of the EV's battery (if the user chooses to provide this information to the system).

[0009] One aspect of these techniques is a method for navigating an electric vehicle from a starting location (or "origin") to a destination. The method is implemented using processing hardware, such as one or more processors configured to execute software instructions stored on a computer-readable medium. The method includes identifying a plurality of charging stations between the starting location and the destination, and determining a navigation route that requires a minimum amount of time for the EV to travel from the starting location to the destination via one or more of the plurality of charging stations, including determining a non-linear relationship between the amount of time and the amount of charge the EV receives during the amount of time.

[0010] Another aspect of these techniques is a computing system configured to implement the above methods. [Brief description of the drawings]

[0011] [Figure 1] FIG. 1 is a block diagram of an example system in which techniques of the present disclosure for generating navigation routes for electric vehicles may be implemented. [Diagram 2] FIG. 1 illustrates an example navigation route that includes a “daisy chain” of electric charging stations generated in accordance with techniques of this disclosure. [Diagram 3] FIG. 2 illustrates an exemplary charging profile for an electric vehicle. [Figure 4] FIG. 2 shows a schematic diagram of the generation of a navigation route using a search-along-route (SAR) technique. [Diagram 5] FIG. 2 illustrates a schematic diagram of generating a navigation route using graph searching techniques. [Figure 6] 2 is a flow diagram of an example method for generating a navigation route for an EV via one or more charging stations using a connectivity graph that may be implemented in the system of FIG. 1 . [Figure 7A] FIG. 7 illustrates an exemplary generation of navigation according to the method of FIG. 6. [Figure 7B] FIG. 7 illustrates an exemplary generation of navigation according to the method of FIG. 6. [Figure 7C] FIG. 7 illustrates an exemplary generation of navigation according to the method of FIG. 6. [Figure 8] 2 is a flow diagram of an example method for pre-computing a graph based on multiple charging stations that may be implemented in the system of FIG. 1. [Figure 9] FIG. 2 illustrates an example graph fragment that the system of FIG. 1 can pre-compute. [Figure 10A] FIG. 9 illustrates an exemplary pre-computation for navigation according to the method of FIG. 8. [Figure 10B] FIG. 9 illustrates an exemplary pre-computation for navigation according to the method of FIG. 8. [Figure 10C] FIG. 9 illustrates an exemplary pre-computation for navigation according to the method of FIG. 8. [Figure 10D] FIG. 9 illustrates an exemplary pre-computation for navigation according to the method of FIG. 8. [Figure 11] FIG. 2 illustrates how the system of FIG. 1 generates a bipartite graph for nodes representing charging stations to represent various charges. [Figure 12A] 10A-10C show example user interface screens that the system of FIG. 1 can generate to provide a navigation route for an EV. [Figure 12B] 10A-10C show example user interface screens that the system of FIG. 1 can generate to provide a navigation route for an EV. [Figure 12C] 10A-10C show example user interface screens that the system of FIG. 1 can generate to provide a navigation route for an EV. [Figure 13] 2 is a flow diagram of an example method for generating a navigation route for an EV that may be implemented in the system of FIG. 1. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0012] Generally speaking, the system of the present disclosure efficiently generates navigation routes for electric vehicles (EVs) that pass through one or more electric charging stations. A system in which these techniques may be implemented is discussed with reference to Figure 1, various techniques for computing, pre-computing, and applying graphs to generate such routes are discussed with reference to Figures 2-10, and some example user interfaces (UIs) that the system can generate are discussed with reference to Figures 12A-12C.

[0013] 1, an example system 100 includes a client computing device 102 (also referred to herein as a “client device”) that is communicatively coupled to a navigation server 130 (also referred to herein as a “server 130”) via a network 120. Network 120 may generally include one or more wired and / or wireless communication links and may include, for example, a wide area network (WAN) such as the Internet, a local area network (LAN), a cellular network, or other suitable type of network.

[0014] The client device 102 may be a navigation module embedded within an EV. Alternatively, the client device 102 may be a portable device such as a smartphone, a tablet computer, a laptop computer, a wearable device such as smart glasses, or another suitable computing device. The client device 102 may include processing hardware, such as one or more processors (CPUs) 104, and a computer-readable non-transitory memory 106 that stores instructions that the one or more processors 104 may execute. The client device 102 may also include a global positioning system (GPU) module 112 or another suitable positioning module, a network interface 114, a user interface 116, and an input / output (I / O) interface 118. The client device 102 may also include components not shown in FIG. 1, such as a graphics processing unit (GPU).

[0015] Network interface 114 may include one or more communication interfaces, such as hardware, software, and / or firmware, to enable communication over a cellular network, a WiFi network, or any other suitable network, such as network 120. User interface 116 may include one or more input devices configured to receive user commands, such as a touch screen, keyboard, microphone, camera, and one or more output devices configured to provide visual, auditory, and / or tactile output, such as a touch screen or speaker. If client device 102 is incorporated within an EV, user interface 116 may include components of the vehicle's head unit. I / O interface 118 may include various additional I / O components that enable client device 102 to interact with such peripheral devices.

[0016] The memory 106 may be non-transitory memory and may include one or more suitable memory modules, such as random access memory (RAM), read only memory (ROM), flash memory, other types of persistent memory, etc. The memory 106 may store machine-readable instructions executable on one or more processors 104 and / or special processing units of the client device 102. The memory 106 also stores an operating system (OS) 110, which may be any suitable mobile or general-purpose OS. In addition, the memory may store one or more applications that communicate data over the network 120, including a navigation application 108. Communicating data may include transmitting data, receiving data, or both. The OS 110 may include application programming interface (API) functions that allow applications to access information from the GPS module 112 or other components of the client device 102. For example, the navigation application 108 may include instructions to call an API of the OS 110 to obtain the current geographic location of the client device 102.

[0017] The navigation application 108 can receive requests for navigation directions from a user, format and send these requests to the navigation server 130, and receive and display and / or speak navigation directions. In addition, the navigation application 108 can display interactive digital maps and provide various geographically located content, for example. Although FIG. 1 illustrates the navigation application 108 as a standalone application, the functionality of the navigation application 108 can also be provided in the form of an online service accessible via a web browser running on the client device 102, as a plug-in or extension for another software application running on the client device 102, and the like. The navigation application 108 can generally be provided in different versions for different respective operating systems. For example, the manufacturer of the client device 102 can provide a software development kit (SDK) that includes the navigation application 108 for the Android™ platform, another SDK for the iOS™ platform, and the like.

[0018] A navigation server 130 may be provided to receive and process requests for navigation directions from client devices 102 and other devices. The request may indicate that the request is specifically related to an EV rather than a conventional vehicle. The server 130 includes processing hardware, such as one or more processors 132, and memory 134, which may be tangible, non-transitory memory having one or more suitable memory modules, such as RAM, ROM, flash memory, other types of persistent memory, etc. The memory 134 stores instructions executable on the processor 132 that configure a routing engine 136 that may process requests for navigation directions and generate the requested navigation directions using data stored in various databases, such as databases 140-144, discussed below. As discussed below, the routing engine 136 may also pre-compute a navigation graph for an EV and apply the graph to a particular request to reduce response time. The instructions also configure a charging time calculation module 138 configured to determine a recommended amount of time that an EV should spend at a particular charging station.

[0019] Server 130 may be communicatively coupled to a database 140 that stores information regarding the charging stations. As discussed in more detail with reference to Figures 3 and 11, database 140 may store locations and profiles of the charging stations. In some implementations, database 140 may also store real-time data, such as the number of currently available ports or queue sizes, if applicable.

[0020] Server 130 may also be communicatively coupled to a database 142 that stores electric vehicle profiles. If the user indicates a desire to indicate the type of EV the user is driving (e.g., by operating a particular control on client device 102 or by installing a particular application), server 130 may attempt to better match charging stations to the user's EV and, in some cases, may alter the navigation route accordingly.

[0021] Additionally, the server 130 may be communicatively coupled to a map database 144 that stores schematic map data, photographic map data (e.g., street-side), and / or satellite map data. The map data may generally correspond to street and road information, terrain data, satellite imagery, information about public transportation routes, information about businesses or other points of interest (POIs), navigational data such as directions from various transportation modes, and the like. The server 130 may provide the map data in the form of map tiles to the client device 102, for example, to generate an interactive digital map.

[0022] Generally, server 130 may receive information related to the geographic location from any number of suitable databases, web services, etc. For example, server 130 may be coupled to a weather database (not shown) that includes current or average weather data in various geographic regions, a natural disaster database (not shown) that includes current or common natural disasters occurring in various geographic regions, and / or a traffic database that includes current or average vehicular and / or pedestrian traffic on roads, routes, or regions.

[0023] 2 illustrates an example navigation route 200 including a daisy chain of several electric charging stations that the routing engine 136 may generate in response to a request from the client device 102. The navigation route 200 may be understood as a directed graph starting at a node 202 corresponding to a starting point S and terminating at a node 204 corresponding to a destination D. The navigation route 200 includes an intermediate node 210 corresponding to a charging station, an intermediate node 212 corresponding to another charging station, and a user-added waypoint 214. An edge 220 between the node 202 and the node 210 defines a first travel segment, with travel time t s1 , and edge 222 between node 210 and node 212 defines a second travel segment, with travel time t s2 , and edge 224 between node 212 and node 214 defines a third travel segment, with travel time t s3 , and edge 224 between node 214 and node 204 defines the fourth and final travel segment, with travel time t s3 Additionally, nodes 210 and 212 are each associated with a charging time t c1 and t c2 Therefore, the overall travel time of the navigation route 200 is T total =t s1 +t s2 +t s3 +t s4 +t c1 +t c2 It is.

[0024] 3 illustrates an example charging profile graph 300 for an example EV. The routing engine 136 can generate a navigation route, such as route 200, by considering the non-linear relationship between the amount of charge and the amount of time required to transfer this amount to the EV's battery. According to an example profile 302 for a particular EV, the charging rate increases, for example, when the EV charges from 20% to 30%, or from 30% to 40%. However, the charging rate decreases, for example, when the EV charges from 50% to 60%, and decreases more rapidly when the EV charges from 90% to 100%. An example profile 304 for another EV shows a generally similar relationship between time and charging rate, but this EV achieves a lower maximum charging rate.

[0025] The routing engine 136 may store an indication of whether a charging station matches a particular profile for an EV (e.g., profiles 302, 304). Thus, the charging profile graph 300 may be understood to be applicable to charging stations as well as EVs.

[0026] Next, Fig. 4 illustrates a schematic of an iterative search along route (SAR) approach for adding charging stations to a navigation route that may be used by the system of Fig. 1 in some implementations. According to this approach, the routing engine 136 selects a navigation route 402 for an EV that traverses waypoints WP1, WP2, WP3, and WP4 (only a portion of the navigation route 402 is shown). These waypoints may represent, for example, where the vehicle turns from one road to another. The routing engine 136 generates the navigation route 402 based on the time or distance between the waypoints and selects this route from among other candidate routes that traverse the candidate waypoints in the diagram 400.

[0027] The routing engine 136 then picks a charging station near the end of the EV's range. For example, the routing engine 136 identifies charging station 420 near waypoint WP1 and charging station 422 near WP2. In both cases, the routing engine 136 limits the search for charging stations to a geographic area within distance d from the navigation route 402. In this case, the routing engine 136 determines that the charging station 422 is within the range of the EV traveling along the navigation route from 402, from the starting point or a previous charging station, and accordingly adds the charging station 422 to the navigation route 402. The routing engine 136 can then repeat these steps to locate the next charging station along the navigation route 402. For this purpose, the routing engine 136 can assume that the charging station 422 will receive a certain amount of charge (e.g., 80%).

[0028] The iterative SAR technique that routing engine 136 uses in this case is a semi-greedy algorithm and may therefore generate a sub-optimal solution (or in some cases fail to find a solution). Alternatively, routing engine 136 may represent the charging stations as nodes in a graph and implement a graph search technique, as discussed below.

[0029] Referring to FIG. 5 , graph 500 is highly connected (i.e., has many edges) to include many potential paths between charging stations, which are represented as nodes. The edges of graph 500 represent paths between pairs of charging stations, which can be of any complexity and include any suitable intermediate waypoints. FIG. 5 illustrates nodes that represent charging stations that are not compatible with a particular EV using shading to indicate that routing engine 136 can exclude these nodes when exploring a navigation route. Thus, for example, node 510 represents a charging station with a profile that generally matches the profile of the EV (see FIG. 3 ), while node 512 represents a charging station with a profile that does not sufficiently match the profile of the EV. As a more specific example, the profile of the charging station may not be able to provide a sufficiently high charging speed, or may include equipment that is simply not compatible due to differences in format, brand, etc.

[0030] In either case, the routing engine 136 can generate a navigation route 502 that traverses several charging stations that define a daisy chain. The routing engine 136 can use Dijkstra's algorithm or * Any suitable search algorithm may be used, such as a search algorithm. Exemplary graph construction techniques that may be used by the routing engine 136 are discussed below with reference to Figures 6A and 7A-7C, but first a brief discussion of the general requirements that the routing engine 136 may implement is provided.

[0031] For the graph to be suitable for identifying a navigation route for a particular EV, each potentially selectable node must define a charging station suitable for the EV. As indicated above, the routing engine 136 can determine compatibility between EVs and charging stations to eliminate incompatible nodes from the graph. In some implementations, the routing engine 136 further eliminates charging stations that do not meet certain reliability score requirements. The routing engine 136 can determine the reliability score based on, for example, driver feedback.

[0032] Another requirement that the routing engine 136 may implement is to find the fastest route between charging stations. When generating these routes as edges in the graph 500, the routing engine 136 may enforce an upper limit (e.g., 500 km) on how far each station (node) may extend. When determining edge weights (representing expected energy usage), the routing engine 136 may consider changes in elevation and other terrain characteristics, speed limits, road types, etc. In some implementations, the routing engine 136 may dynamically adjust edge weights depending on weather conditions, since the performance of EVs is generally more variable with weather compared to vehicles with internal combustion engines.

[0033] Additionally, when searching for a navigation route, the routing engine 136 can apply user-specified preferences, such as, for example, "avoid highways." Other examples of conditions or user preferences include generating "energy-conscious" environmentally friendly routes (i.e., "eco-routes") to optimize energy consumption. The routing engine 136 in this case can seek to avoid hills, elevation changes, or more generally, certain types of routes.

[0034] For each charging station, the routing engine 136 can estimate the charging time as the "cost" of stopping at the charging station. As discussed with reference to Fig. 11, charging time varies greatly with charge amount (unlike a traditional gas station where the time difference between a half-tank and a full tank is negligible), and furthermore, as shown in Fig. 3, the relationship between charging time and charge amount is generally nonlinear. If the routing engine 136 is aware of multiple charging ports at a charging station, the routing engine 136 can rely on the fastest port for the calculation.

[0035] Furthermore, when generating a navigation route, the routing engine 136 may estimate the amount of charge the EV should receive by considering the next edge of the graph that the EV traverses. For example, the routing engine 136 may determine that the EV should charge to 60% at a particular charging station even though the charging speed is relatively slow, between 50% and 60%, because the navigation route that the next edge includes is relatively long. In another case, the routing engine 136 may determine that the EV should only charge 40% to avoid a slower charging speed, because the next edge that includes the navigation route is relatively short.

[0036] Overall, the routing engine 136 may seek to minimize the total travel time as well as the total charging time. trip =min(Σsegment_time i +Σcharge_time j ) (Formula 1)

[0037] In some implementations, the routing engine 136 enforces a requirement that the EV reach each station at a certain minimum battery level (e.g., 15%). A user can manually set this level, for example, via the UI of the client device 102, or the routing engine 136 can automatically select and enforce the minimum battery level. In another implementation, a user indicates to the system of FIG. 1 a willingness to share certain information about past trips, and the routing engine 136 uses machine learning techniques to automatically infer the user's preference for minimum battery levels.

[0038] The routing engine 136 in some implementations also checks real-time data to dynamically update the navigation directly. For example, the routing engine 136 may check the real-time availability of charging ports and, in response to determining that a part is not available at a charging station, attempt to find an alternative route through another charging station or recommend that the EV not stop at a charging station and proceed directly to the next charging station along the navigation route.

[0039] 6, the routing engine 136 may implement a method 600 for generating a navigation route between an origin and a destination using a graph in which charging stations define the nodes and paths between charging stations define the edges. The method 600 begins at block 602, where the routing engine 136 builds a graph of related (e.g., compatible, meeting a reliability score) charging stations. FIG. 7A illustrates an example graph 700 that the routing engine 136 may build at block 602. Depending on the implementation, the routing engine 136 may build the graph 700 in real-time or may pre-compute the graph 700 to more quickly facilitate subsequent generation of the navigation route. In either case, the graph 700 includes nodes 702A, 702B, etc. interconnected by edges 704A, 704B, etc. The routing engine 136 builds the graph 700, in some cases, by reducing the highly connected ones to an MST and a set of additional edges that provide a certain level of improvement to the route, as discussed in more detail below.

[0040] In block 604, the routing engine 136 generates nodes representing origins and destinations and connects these nodes to the graph. The origins and destinations do not have to correspond to charging stations, and therefore temporary nodes can be defined. As shown in FIG. 7B, temporary node 710 can be proximate to node 702, and temporary node 712 can be proximate to nodes 702C, 702D, and 702E. Node 710 in this example can correspond to the origin, and node 712 can correspond to the destination. To connect nodes 710 and 712 to the graph 700, the routing engine 136 can impose certain restrictions based on time or distance, for example, these temporary nodes can be connected to all nodes of the graph 700 of trips within X miles or Y minutes.

[0041] In block 606, the routing engine 136 applies graph search techniques to find a navigation route from the origin to the destination. For example, as shown in FIG. 7C, the routing engine 136 generates a path that starts at temporary node 710, proceeds (via a temporary edge) to node 702A, and proceeds through graph nodes 702F and 702C to temporary node 712.

[0042] Generally speaking, building a graph in real time is a * For the problem, the number of calls to the path generating function is D = B (B * ) d (Formula 2) where B is the branching coefficient and B * A * is the "effective" branching factor when using a heuristic, d, which is the depth (or the number of charging stops required for the optimal route). We use a branching factor of 1000 (e.g., an average of 5000 charging stations in a circle of radius 500 km) and a heuristic that optimistically eliminates 99% of the options (B * =50), for the most common use case involving a single charging stop, the routing engine 136 would require approximately 250,000 calls to the function that generates the route, for two stops, approximately 12.5 million calls would be required, etc. Thus, it is often impractical for the routing engine 136 to route to a navigation graph (e.g., graph 500 or 700) in real time without resorting to at least some precomputation and caching.

[0043] To service requests for navigation directions more quickly, the routing engine 136 in some implementations pre-computes the navigation graph according to the method 700 of FIG.

[0044] In block 802, the routing engine 136 builds an initial highly connected graph that interconnects a number of nodes that represent charging stations. The routing engine 136 then generates a minimum spanning tree (MST) based on the highly connected graph. Generally speaking, an MST (also known as a minimum weight spanning tree) is a subset of edges of a connected undirected graph such that all nodes are connected without cycles. If the edges have respective weights, the MST also provides the minimum possible total weight of the edges.

[0045] For example, referring to FIG. 10A, a highly connected graph 1000 includes nodes 1002A, 1002B, ... 10002K and edges between these nodes, such as edge 1004AB interconnecting nodes 1002A and 1002B, and edge 1004BC interconnecting nodes 1002 and 1002C. Each of the edges 1004AB, 1004BC, etc., can have a weight that represents one or more of the following metrics: the amount of energy required to travel between the nodes in a particular direction, the amount of time required, the distance between the nodes, etc. Note that the energy consumption may not be the same for travel in the opposite direction between the two nodes. For example, charging station S1 may be located at a higher elevation than charging station S2, and an EV will require less energy to travel from S1 to S2 compared to traveling from S2 to S1. Additionally, edges 1004AB, 1004BC, etc., can represent potentially complex paths of multiple segments. Thus, nodes 1002A, 1002B, etc., differ in at least this respect from travel waypoints of navigation instructions.

[0046] The MST 1010 in this example interconnects nodes 1002A and 1000C via edge 1004AC and excludes all other paths between nodes 1002A and 1002C as a result of the definition of the MST. The MST 1010 further interconnects nodes 1002B and 1002C via edge 1004BC, interconnects nodes 1002C and 1002D via edge 1004CD, etc. The MSG 1010 excludes most edges of the graph 1000, such as, for example, 1006AB. Figure 10 shows the excluded edges using dashed lines.

[0047] Referring back to FIG. 8, the routing engine 136 then selects a threshold for adding edges from the underlying connected graph to the MST. If a path between two nodes improves the MST path between the same two nodes by at least the threshold, the routing engine 136 may add one or more edges of the improved path to the MST. The threshold may be expressed in relative terms as a percentage of improvement (e.g., a 10% improvement in time or energy) or in absolute terms (e.g., an improvement of only 10 minutes or 1% of battery). Then, in block 806, the routing engine 136 adds edges that meet the threshold criteria obtained in block 804. The routing engine 136 filters out other edges of the underlying graph in block 810.

[0048] 10B, routing engine 136 may determine that edge 1006EH, interconnecting nodes 1002E and 1002H, has a weight of 60. A path between the same two nodes along the MST includes edge 10004BE, having weight 20, edge 1004BC, having weight 30, and edge 1004CH, having weight 50, for a total weight of 100. If routing engine 136 applies a threshold of 1.1, the improvement of 60 over 100 is large enough for routing engine 136 to add edge 1006EH to the MST as part of defining the navigation graph.

[0049] On the other hand, referring to FIG. 10C, the routing engine 136 may determine that edge 1006AH, having a weight of 79, provides only a 1.25% improvement along the path between nodes 1002A and 1002H along the MST (which includes edges 1004AC and 1004CH, which have a total weight of 80), and so excludes edge 1006AH from the navigation graph.

[0050] 10D illustrates a navigation graph 1020 that the routing engine 1036 can construct based on the graph 1000. The navigation graph 1020 includes the entire MST 1010, as well as some, but not all, of the edges of the graph 1000 that were excluded from the MST 1010. The navigation graph 1020 has fewer edges than that graph 1000, thus simplifying the task of generating navigation routes between origins and destinations. Referring back to FIGS. 7A-7C, the navigation graph 1020 can operate as the graph 700 to which the routing engine can temporarily add nodes representing origins and destinations.

[0051] In addition to reducing the time required for the routing engine 136 to process a request for navigation directions, the navigation graph 1020 requires less memory than the underlying highly connected graph 700. We now briefly consider an exemplary storage of the navigation graph 1020 or a similar navigation graph.

[0052] 9, the graph fragment 900 may be a portion of the graph 1020 or 700. The graph fragment 900 includes nodes 902, 904, and 906 that represent charging stations, and edges that interconnect nodes 902 and 906, as well as 904 and 906. The server 130 stores a profile record 910 for each node. The record 910 may indicate, for example, a relationship between time and charge amount (see FIG. 3). In some implementations discussed with reference to FIG. 11, the record 910 may store a bipartite graph to represent these dependencies. Additionally, the record may indicate real-time data such as hardware compatibility, number of ports, current occupancy, etc., at the charging station.

[0053] For each edge in the navigation graph, the server 130 may store a route description record 912 that includes waypoint data for waypoints 920, 922, etc., and road segment information 914 for the road segments between pairs of waypoints. The road segment information 914 may indicate distance, change in elevation, etc.

[0054] 11, a diagram 1100 illustrates how the routing engine 136 can generate a bipartite graph for the nodes that represent charging stations. For example, by replacing the nodes in the navigation 700 or 1020 with a bipartite graph, the routing engine 136 can generate a bipartite graph based on Dijkstra's or A * Graph exploration techniques such as can be applied directly to the resulting graph.

[0055] As shown in FIG. 11, the server 130 may represent the node 1102 as a bipartite graph 1110 having a set of input subnodes 1120 and a set of output subnodes 1122. Each of the subnodes 1120 is coupled to one or more subnodes 1122. The input subnodes and the output subnodes represent a particular state of charge. Edges between subnodes corresponding to the same state of charge have a weight of zero, e.g., an EV that enters a charging station with 60% charge and leaves the charging station with the same amount of charge is estimated to spend zero minutes at the charging station. Thus, if the routing engine 136 determines that the EV should travel past the charging station without stopping (e.g., because the EV has enough charge of 60% along the particular navigation route and can comfortably reach the next charging station), the routing engine 136 may select the path 1130 through the bipartite graph 1110. Meanwhile, the routing engine 136 may determine that the EV will reach the charging station represented by the node 1104 with 20% charge. According to bipartite graph 1112, which may have a similar structure to bipartite graph 1110, but where the weights of the edges between subnodes are not necessarily the same, a link between an input subnode representing a 20% charge and an output subnode representing an 80% charge has a weight of 45. Routing engine 136 may, for example, select path 1140 in this case because the next edge in the navigation graph is longer.

[0056] 12A-12C next show some example UI screens that the system of FIG. 1 may generate to provide a navigation route for an EV. For example, navigation application 108 may present these UI screens to a user via user interface 116. Navigation application 108 may generate these screens using data received from navigation server 130, for example.

[0057] Referring initially to FIG. 12A , the navigation application 108 may present a UI screen 1200A, for example, on a portable device or via a vehicle's head unit. The UI screen 1200A includes a graphic 1210 for a navigation route between a particular starting location, indicated by icon 1214, and a destination, indicated by icon 1216. The UI screen 1200A may apply different colors, shading, or other visual effects to the graphic 1210 to indicate different charge states along the route. Thus, segment 1220 may indicate a large amount of charge remaining, segment 1222 may indicate a smaller amount of charge remaining, and segment 1224 may indicate even less charge remaining. Segment 1226 may indicate no charge remaining. A warning icon 1230 may indicate approximately where the EV is expected to run out of charge.

[0058] The UI screen 1200A may also include an interactive window 1212A in which the navigation application 108 provides information about the destination, recommendations 1240 for adding a charging stop, an interactive control 1240 through which the user can request that the routing engine 136 add a charging station to the navigation route, and another interactive control 1242 through which the user can request navigation directions without adding a charging station.

[0059] Depending on the implementation, the routing engine 136 may generate the navigation route represented by the graphic 1210 without taking into account the charging stations, for example, using the techniques discussed above, or to provide the same navigation route that the routing engine 136 provides to a conventional vehicle.

[0060] 12B, a user may request that the routing engine 136 add a charging station to the navigation route. The navigation application 108 may present a UI screen 1200B in which a window 1212B provides an indication that a compatible charging stop has been identified and added to the navigation route.

[0061] 12C shows a UI screen 1200C after generating a navigation route that includes a daisy chain of charging stations. The UI screen 1200C can include a window 1212C that includes an overview of the navigation route. For example, the window 1212C can show, for each charging stop, the name of the charging station, the time the EV should spend at the charging station, and the amount of charge the EV should have when it leaves the charging station. The UI screen 1200C can update the graphic 1210 to include visual representations 1250 and 1252 of the charging stations. In some implementations, the navigation application 108 can also update the graphic 1210 to show that there is sufficient charge for all segments.

[0062] For further clarity, FIG. 13 illustrates a flow diagram 1300 of an example method for routing engine 136 (or, in some implementations, navigation application 108) to generate a navigation route for an EV. In block 1302, routing engine 136 may identify charging stations located between an origin and a destination. As discussed above, routing engine 136 may use a navigation graph, such as graph 700 or 1020.

[0063] In block 1304, the routing engine 136 may determine respective nonlinear relationships between charging times and charge amounts for the charging stations. The routing engine 136 may represent these nonlinear relationships (see FIG. 3) as a bipartite graph, for example, as discussed above with reference to FIG.

[0064] In block 1306, the routing engine 136 may determine a navigation route between the origin and the destination, where the navigation route traverses one or more charging stations. As discussed above with reference to Figures 7A-7C, the routing engine 136 may generate temporary nodes for the origin and destination.

[0065] Additional Considerations The following additional considerations apply to the foregoing discussion. Throughout this specification, multiple instances may implement components, operations, or structures that are described as a single instance. Although individual operations of one or more methods are illustrated and described as separate operations, one or more of the individual operations may be performed simultaneously, and the operations do not require being performed in the order illustrated. Structures and functions presented as separate components in an exemplary configuration may be implemented as combined structures or components. Similarly, structures and functions presented as single components may be implemented as separate components. These and other variations, modifications, additions, and improvements fall within the scope of the subject matter of this disclosure.

[0066] In addition, certain embodiments are described herein as including logic, or some components, modules, or mechanisms. A module may constitute either a software module (e.g., code stored on a machine-readable medium) or a hardware module. A hardware module is a tangible unit that can perform certain operations and may be configured or arranged in a certain manner. In an exemplary embodiment, one or more computer systems (e.g., standalone, client, or server computer systems), or one or more hardware modules of a computer system (e.g., a processor or group of processors), may be configured as a hardware module that operates by software (e.g., an application or application portion) to perform certain operations described herein.

[0067] In various embodiments, a hardware module may be implemented mechanically or electronically. For example, a hardware module may comprise dedicated circuitry or logic that is permanently configured (e.g., as a dedicated processor, such as a field programmable gate array (FPGA) or application specific integrated circuit (ASIC)) to perform certain operations. A hardware module may also comprise programmable logic or circuitry that is temporarily configured by software to perform certain operations (e.g., as embodied within a general-purpose processor or other programmable processor). It will be appreciated that the decision to implement a hardware module mechanically, in dedicated permanently configured circuitry, or in temporarily configured (e.g., configured by software) circuitry may be driven by cost and time considerations.

[0068] Thus, the term hardware should be understood to encompass tangible entities that are physically configured, permanently configured (e.g., wired), or temporarily configured (e.g., programmed) to operate in a particular manner or to perform particular operations described herein. Considering embodiments in which hardware modules are temporarily configured (e.g., programmed), each of the hardware modules need not be configured or instantiated at any one time. For example, if the hardware modules comprise a general-purpose processor configured using software, the general-purpose processor may be configured as different hardware modules at different times. Thus, the software may, for example, configure the processor to configure a particular hardware module at one time and a different hardware module at a different time.

[0069] Hardware and software modules can provide information to and receive information from other hardware and / or software modules. Thus, the described hardware modules can be considered to be communicatively coupled. When multiple such hardware or software modules are present simultaneously, communication can be achieved through signal transmission (e.g., by appropriate circuits and buses) connecting the hardware or software modules. In embodiments in which multiple hardware or software modules are configured or instantiated at different times, communication between such hardware or software modules can be achieved, for example, through storage and retrieval of information in a memory structure that can be accessed by multiple hardware or software modules. For example, one hardware or software module can perform an operation and store the output of that operation in a communicatively coupled memory device. An additional hardware or software module can then access the memory device at a later time to retrieve and process the stored output. Hardware and software modules can also initiate communication with input or output devices and operate on resources (e.g., collections of information).

[0070] Various operations of the example methods described herein may be performed, at least in part, by one or more processors that are temporarily or permanently configured (e.g., by software) to perform the associated operations. Whether temporarily or permanently configured, such processors may constitute processor-implemented modules that operate to perform one or more operations or functions. Modules referred to herein may comprise processor-implemented modules in some example embodiments.

[0071] Similarly, the methods or routines described herein may be at least partially processor-implemented. For example, at least some of the operations of a method may be performed by one or more processors or processor-implemented hardware modules. The execution of a particular operation may reside within a single machine, but may also be distributed among one or more processors deployed across several machines. In some exemplary embodiments, a processor may be located in a single location (e.g., in a home environment, in an office environment, or as a server farm), while in other embodiments, a processor may be distributed across several locations.

[0072] The one or more processors may also operate to support execution of related operations in a "cloud computing" environment or as SaaS. For example, as indicated above, at least some of the operations may be performed by a group of computers (as examples of machines that include a processor), and these operations are accessible over a network (e.g., the Internet) and via one or more appropriate interfaces (e.g., APIs).

[0073] Execution of certain operations may reside within a single machine, but may also be distributed among one or more processors spread across several machines. In some exemplary embodiments, one or more processors or processor-implemented modules may be located in a single geographic location (e.g., in a home environment, in an office environment, or in a server farm). In other exemplary embodiments, one or more processors or processor-implemented modules may be distributed across several geographic locations.

[0074] Some portions of this specification are presented in terms of algorithms or symbolic representations of operations on data stored in a machine memory (e.g., a computer memory) as bits or binary digital signals. These algorithms or symbolic representations are examples of techniques used by those skilled in the data processing arts to convey the substance of their work to others skilled in the art. As used herein, an "algorithm" or "routine" is a self-consistent sequence of operations or similar processes leading to a desired result. In this context, algorithms, routines, and operations involve physical manipulations of physical quantities. Typically, although not necessarily, such quantities may take the form of electrical, magnetic, or optical signals capable of being stored, accessed, transferred, combined, compared, or otherwise manipulated by a machine. It is sometimes convenient, primarily for reasons of common usage, to refer to such signals using words such as "data," "content," "bits," "values," "elements," "symbols," "characters," "terms," ​​"numbers," "digits," and the like. However, these words are merely convenient labels and should be associated with the appropriate physical quantities.

[0075] Unless otherwise noted, discussions herein using words such as "processing," "computing," "calculating," "determining," "presenting," "displaying," and the like may refer to the actions or processing of a machine (e.g., a computer) that manipulates or transforms data represented as physical (e.g., electronic, magnetic, or optical) quantities in one or more memories (e.g., volatile memory, non-volatile memory, or a combination thereof), registers, or other machine components that receive, store, transmit, or display information.

[0076] As used herein, any reference to "one embodiment" or "an embodiment" means that a particular element, feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. The appearances of the phrase "in one embodiment" in various places in this specification do not necessarily all refer to the same embodiment.

[0077] Some embodiments may be described using the terms "coupled" and "connected," along with their derivatives. For example, some embodiments may be described using the term "coupled" to indicate that two or more elements are in direct physical or electrical contact. However, the term "coupled" may also mean that two or more elements are not in direct contact with each other, but still co-operate or interact with each other. The embodiments are not limited in this context.

[0078] As used herein, "comprises," "comprising," "including," "including," "having," "having," or any other variation thereof, is intended to cover a non-exclusive inclusion. For example, a process, method, article, or apparatus that includes a list of elements is not necessarily limited to only those elements, but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Furthermore, unless expressly stated to the contrary, "or" refers to an inclusive or, not an exclusive or. For example, a condition A or B is satisfied by any one of the following: A is true (or present) and B is false (or absent), A is false (or absent) and B is true (or present), and both A and B are true (or present).

[0079] In addition, the use of "a" or "an" is used to describe elements and components of the embodiments herein. This is done merely for convenience and to give a general sense of the description. The description should be read to include one or at least one, and the singular also includes the plural, unless it is clear that it is meant otherwise.

[0080] Upon reading this disclosure, those skilled in the art will understand further alternative structural and functional designs for generating a navigation route for an ele according to the principles disclosed herein. Thus, although specific embodiments and applications have been illustrated and described, it should be understood that the disclosed embodiments are not limited to the precise structures and components disclosed herein. Various modifications, changes, and variations that are apparent to those skilled in the art may be made in the arrangement, operation, and details of the methods and apparatus disclosed herein without departing from the spirit and scope defined in the appended claims. [Explanation of symbols]

[0081] 100 Systems 102 Client computing device, client device 104 Processor (CPU), Processor 106 Computer-readable non-transitory memory 108 Navigation Applications 110 Operating System (OS), OS 112 Global Positioning System (GPU) module, GPS module 114 Network Interface 116 User Interface 118 Input / Output (I / O) Interface 120 Network 130 Navigation Server, Server 132 processors 134 Memory 136 Routing Engine 138 Charging time calculation module 140 Databases 141 Database 142 Database 143 Database 144 Databases, map databases 200 Navigation Route 202 nodes 204 nodes 210 intermediate nodes, nodes 212 intermediate nodes, nodes 214 User added waypoints, nodes 220 Edge 222 Edge 224 Edge 300 Charging Profile Graph 302 Profile 304 Profile 400 Figures 402 Navigation Route 420 Charging Station 422 Charging Station 500 graphs 502 Navigation Route 510 nodes 512 nodes 700 Graphs, Navigation 702 nodes 702A Node 702B Node 702C Node 702D Node 702E Node 702F Node 704A Edge 704B Edge 710 Temporary Node, Node 712 Temporary Node, Node 900 Graph Fragments 902 nodes 904 nodes 906 nodes 910 Profile Record, Record 912 Route description record 914 Road Segment Information 920 Waypoints 922 waypoints 1000 Highly Connected Graphs, Graphs 1002A Node 1002B Node 1002C Node 1002D Node 1002E node 1002H node 1004AB Edge 1004AC Edge 1004BC Edge 1004CD Edge 1004CH Edge 1006AB Edge 1006AH Edge 1006EH Edge 1010 MST, MSG 1020 Navigation graph, navigation 1036 Routing Engine 1100 Drawings 1102 Node 1104 Node 1110 Bipartite graphs 1112 Bipartite graphs 1120 Input subnode, subnode 1122 Output subnode, subnode 1130 Route 1140 Route 1200A UI screen 1200B UI screen 1200C UI screen 1210 Graphics 1212A Interactive Window 1212B Window 1212C Window 1214 Icons 1216 Icons 1220 Segments 1222 Segments 1224 Segments 1226 Segments 1230 Warning Icon 1240 Recommendations, Interactive Control 1242 Interactive Control 1250 Visual Representation 1252 Visual Representation 10002K nodes 10004BE Edge

Claims

1. 1. A method, executed by one or more processors, for navigating an electric vehicle (EV) from an origin to a destination, the method comprising: determining a non-linear relationship between an amount of time and an amount of charge the EV receives during the amount of time, the non-linear relationship being based on a charging profile that defines a charging rate as a function of charge of the EV; identifying a number of charging stations between the origin and the destination; (i) traveling from the origin to the destination via one or more of the plurality of charging stations; (ii) charging at each of the one or more of the plurality of charging stations, wherein the EV receives an amount of charge based on the nonlinear relationship determined during an amount of time spent at each of the one or more of the plurality of charging stations. determining a navigation route requiring a minimum amount of time for the EV to A method comprising:

2. determining the navigation route, constructing a navigation graph in which at least some of the plurality of charging stations define respective nodes and routes between the nodes define edges, the navigation graph being used to determine the navigation route; 2. The method of claim 1, comprising:

3. constructing the navigation graph, constructing a connected graph, where each of the plurality of charging stations represents a respective node, with N edges interconnecting a plurality of the nodes; identifying a minimum spanning tree (MST) of the connected graph using the weights of each edge, the weights being associated with traversals along corresponding edges; adding an edge that directly connects two of the nodes of the MST based on a comparison between (a) the weight of the edge and (b) the sum of the weights of each of the edges on a path along the MST between the two nodes; Including, The method of claim 2.

4. For at least some of the plurality of nodes, a first set of subnodes representing an amount of charge upon entry to the charging station; a second set of subnodes representing a charge upon exiting the charging station; defining an amount of time that an edge between a subnode in the first set and a subnode in the second set is associated with a corresponding increase in charge; generating a corresponding representation of the charging station as a bipartite graph to describe the charging station as a nonlinear function; 4. The method of claim 2 or 3, further comprising:

5. The method of claim 2 , wherein constructing the navigation graph comprises selecting a charging station within the plurality of charging stations that is compatible with the EV.

6. 6. The method of claim 2, wherein constructing the navigation graph comprises excluding from the navigation graph charging stations that (i) are incompatible with the EV and / or (ii) cannot provide a sufficiently high charging speed.

7. The method of claim 2, further comprising the step of pre-calculating the navigation graph before receiving a request for navigation instructions for the EV.

8. generating a first node representing the starting point; creating a second node representing the destination; connecting the first node and the second node to the navigation graph; 7. The method of claim 2, further comprising:

9. The step of determining a navigation route includes: * A method according to any one of claims 2 to 8, comprising applying a search algorithm to the navigation graph.

10. providing an option for the user to select an environmentally friendly route; determining the navigation route includes generating the environmentally friendly route that optimizes energy consumption; 10. The method according to any one of claims 1 to 9.

11. The method of claim 10 , wherein generating the environmentally friendly route includes avoiding changes in elevation.

12. 11. The method of claim 10, further comprising: generating a user interface screen, the user interface screen including segments dividing the navigation route into portions, the segments comprising applying levels of highlighting to various segments according to a predicted battery state of charge for the segments.

13. receiving real-time data indicative of port availability at one or more of the plurality of charging stations; automatically updating the navigation route taking into account the received real-time data; 11. The method of claim 10, further comprising:

14. 1. A system comprising: one or more processors; a computer-readable storage medium storing instructions that, when executed by the one or more processors, cause the system to perform a method according to any one of claims 1 to 13; A system comprising:

Images