Patent Description:
<CIT> discloses an operating mode for a vehicle determined according to respective control states of each of a plurality of vehicle subsystems that include braking, steering, and propulsion. The operating mode is one of manual control, partial manual control, and no manual control. A route for the vehicle is determined based in part on the operating mode.

<CIT> discloses a method for determining an ability of an autonomous vehicle to safely or robustly travel a road feature or a road segment or a route that is considered for the autonomous vehicle as of a time or range of times. The determination is made based on properties of the environment in which the autonomous vehicle travels.

Advantageous features of the invention are set out in the accompanying appended dependent claims.

While the concepts of the present disclosure are susceptible to various modifications and alternative forms, specific embodiments thereof have been shown by way of example in the drawings and will be described herein in detail.

Additionally, it should be appreciated that items included in a list in the form of "at least one of A, B, and C" can mean (A); (B); (C): (A and B); (A and C); (B and C); or (A, B, and C). Similarly, items listed in the form of "at least one of A, B, or C" can mean (A); (B); (C): (A and B); (A and C); (B and C); or (A, B, and C).

The disclosed embodiments may be implemented, in some cases, in hardware, firmware, software, or any combination thereof. The disclosed embodiments may also be implemented as instructions carried by or stored on one or more transitory or non-transitory machine-readable (e.g., computer-readable) storage media, which may be read and executed by one or more processors. A machine-readable storage medium may be embodied as any storage device, mechanism, or other physical structure for storing or transmitting information in a form readable by a machine (e.g., a volatile or non-volatile memory, a media disc, or other media device).

Referring now to <FIG>, in an illustrative embodiment, a system <NUM> for autonomous driving quality of service (QoS) determination and communication includes an advanced vehicle <NUM> that includes a vehicle computing device <NUM>. The vehicle computing device <NUM> may communicate with one or more external data services <NUM> over a network <NUM>. In use, as described further below, the vehicle computing device <NUM> determines multiple route segments for potential routes to a destination. The vehicle computing device <NUM> determines an autonomous driving quality of service (QoS) score for each route segment, which is based on the driving autonomy level achievable by the advanced vehicle <NUM> for each route segment. Based on the QoS scores, the vehicle computing device <NUM> determines a proposed route to the destination, which may be confirmed by the user. As the advanced vehicle <NUM> drives the route to the destination, the vehicle computing device <NUM> updates QoS scores and the proposed route. Thus, the system <NUM> may allow the user to select a route to a destination based on the autonomous driving level achievable for each route segment, which may improve the convenience and/or usability of the advanced vehicle <NUM>. The system <NUM> may further incorporate user preferences or other policies in route selection, which may further improve the autonomous driving experience for the user. In some embodiments, the system <NUM> may provide a guaranteed autonomous driving QoS for each route segment of a route, which may increase the feasibility or acceptability of autonomous driving for certain users, for example users who are incapable of driving.

The advanced vehicle <NUM> may be embodied as any type of car, truck, or other vehicle capable of performing one or more levels of vehicle automation, including driver assistance, partial automation, conditional automation, high automation, or full automation. For example, the advanced vehicle <NUM> may be capable of full autonomous driving from a starting position to a destination position, including full control of acceleration, steering, braking, collision avoidance, and other driving tasks of the advanced vehicle <NUM>. As another example, the advanced vehicle <NUM> may be capable of autonomously or semi-autonomously parallel parking the advanced vehicle <NUM> or other parking assist tasks. As another example, the advanced vehicle <NUM> may provide adaptive cruise control, automated collision avoidance, or other automated driver aids. The level of vehicle automation achievable by the advanced vehicle <NUM> for a particular route segment may depend on available map data, weather conditions, vehicle and sensor health, and/or other autonomous driving factors. Illustratively, the advanced vehicle <NUM> includes the vehicle computing device <NUM>, as well as one or more sensors <NUM> and a motor/actuator system <NUM>.

The vehicle computing device <NUM> may be embodied as any type of computation or computer device capable of performing the functions described herein, including, without limitation, a computer, an electronic control unit (ECU), an in-vehicle infotainment (IVI) device, a multiprocessor system, a server, a rack-mounted server, a blade server, a laptop computer, a notebook computer, a network appliance, a web appliance, a distributed computing system, a processor-based system, and/or a consumer electronic device. As shown in <FIG>, the vehicle computing device <NUM> illustratively includes a processor <NUM>, an input/output subsystem <NUM>, a memory <NUM>, a data storage device <NUM>, and communication circuitry <NUM>. Of course, the vehicle computing device <NUM> may include other or additional components, such as those commonly found in a vehicle computer (e.g., various input/output devices), in other embodiments. Additionally, in some embodiments, one or more of the illustrative components may be incorporated in, or otherwise form a portion of, another component. For example, the memory <NUM>, or portions thereof, may be incorporated in the processor <NUM> in some embodiments.

The processor <NUM> may be embodied as any type of processor capable of performing the functions described herein. For example, the processor <NUM> may be embodied as a single or multi-core processor(s), digital signal processor, microcontroller, or other processor or processing/controlling circuit. Similarly, the memory <NUM> may be embodied as any type of volatile or non-volatile memory or data storage capable of performing the functions described herein. In operation, the memory <NUM> may store various data and software used during operation of the vehicle computing device <NUM> such as operating systems, applications, programs, libraries, and drivers. The memory <NUM> is communicatively coupled to the processor <NUM> via the I/O subsystem <NUM>, which may be embodied as circuitry and/or components to facilitate input/output operations with the processor <NUM>, the memory <NUM>, and other components of the vehicle computing device <NUM>. For example, the I/O subsystem <NUM> may be embodied as, or otherwise include, memory controller hubs, input/output control hubs, firmware devices, communication links (i.e., point-to-point links, bus links, wires, cables, light guides, printed circuit board traces, etc.) and/or other components and subsystems to facilitate the input/output operations. In some embodiments, the I/O subsystem <NUM> may form a portion of a system-on-a-chip (SoC) and be incorporated, along with the processor <NUM>, the memory <NUM>, and other components of the vehicle computing device <NUM>, on a single integrated circuit chip.

The data storage device <NUM> may be embodied as any type of device or devices configured for short-term or long-term storage of data such as, for example, memory devices and circuits, memory cards, hard disk drives, solid-state drives, or other data storage devices. The communication circuitry <NUM> of the vehicle computing device <NUM> may be embodied as any communication circuit, device, or collection thereof, capable of enabling communications between the vehicle computing device <NUM>, the data services <NUM>, and/or other remote devices over the network <NUM>. The communication circuitry <NUM> may be configured to use any one or more communication technology (e.g., wired or wireless communications) and associated protocols (e.g., Ethernet, Bluetooth®, Wi-Fi®, WiMAX, LTE, etc.) to effect such communication.

As shown, the vehicle computing device <NUM> also includes a display <NUM>, a location subsystem <NUM>, and one or more peripheral devices <NUM>. The display <NUM> of the vehicle computing device <NUM> may be embodied as any type of display capable of displaying digital information, such as a liquid crystal display (LCD), a light emitting diode (LED), a plasma display, a cathode ray tube (CRT), or other type of display device. As described further below, the display <NUM> may be used to present route information and other data to a user of the advanced vehicle <NUM>, and in some embodiments the display <NUM> may include a touchscreen or other input device to receive user input. Although illustrated as being included in the vehicle computing device <NUM>, it should be understood that in some embodiments the display <NUM> may be embodied as one or more separate components coupled to the vehicle computing device <NUM>, such as an instrument cluster, an in-vehicle infotainment (IVI) device, or another display in a cabin of the advanced vehicle <NUM>.

The location subsystem <NUM> of the vehicle computing device <NUM> may be embodied as any type of circuit capable of determining the precise or approximate position of the vehicle computing device <NUM> and, thus, the advanced vehicle <NUM>. For example, the location subsystem <NUM> may be embodied as a global positioning system (GPS) receiver, capable of determining the precise coordinates of the vehicle computing device <NUM>. In other embodiments, the location subsystem <NUM> may triangulate or trilaterate the position of the vehicle computing device <NUM> using distances or angles to cellular network towers with known positions, provided by the communication circuitry <NUM>. In other embodiments, the location subsystem <NUM> may determine the approximate position of the vehicle computing device <NUM> based on association to wireless networks with known positions, using the communication circuitry <NUM>.

As described above, the advanced vehicle <NUM> also includes multiple sensors <NUM> and a motor/actuator system <NUM>. The sensors <NUM> may be embodied as any sensor or sensors capable of providing information about the position, nearby objects, or other attributes of the physical environment of the advanced vehicle <NUM> to the vehicle computing device <NUM>. For example, the sensors <NUM> may include ultrasound, infrared, or laser rangefinders, visible- or infrared-light cameras, three-dimensional LIDAR sensors, and/or RADAR sensors. In some embodiments, the sensors <NUM> may include short-range communications sensors capable of communication or identification of other advanced vehicles <NUM>, such as visible light communication sensors. The sensors <NUM> may also provide sensor health data or other diagnostic data to the vehicle computing device <NUM>.

The motor/actuator system <NUM> includes any control system capable of controlling movement of the advanced vehicle <NUM>. The motor/actuator system <NUM> may include motor controllers, actuators, traction motors, and/or any other components that control the acceleration, braking, and steering of the advanced vehicle <NUM>.

Each external data service <NUM> may be embodied as any computing device, or collection of computing devices, capable of providing information relevant to autonomous driving factors to the vehicle computing device <NUM>. As such, each external data service <NUM> may be embodied as a single server computing device or a collection of servers and associated devices. For example, in some embodiments, each external data service <NUM> may be embodied as a "virtual server" formed from multiple computing devices distributed across the network <NUM> and operating in a public or private cloud. Accordingly, although each external data service <NUM> is illustrated in <FIG> as embodied as a single server computing device, it should be appreciated that each external data service <NUM> may be embodied as multiple devices cooperating together to facilitate the functionality described below. As such, each external data service <NUM> may include components and features similar to the vehicle computing device <NUM>, such as a processor, I/O subsystem, memory, data storage, communication circuitry, and various peripheral devices, which are not illustrated in <FIG> for clarity of the present description.

As discussed in more detail below, the vehicle computing device <NUM>, the external data services <NUM>, and other components of the system <NUM> may be configured to transmit and receive data with each other and/or other devices of the system <NUM> over the network <NUM>. The network <NUM> may be embodied as any number of various wired and/or wireless networks. For example, the network <NUM> may be embodied as, or otherwise include, a wired or wireless local area network (LAN), a wired or wireless wide area network (WAN), a cellular network, and/or a publicly-accessible, global network such as the Internet. As such, the network <NUM> may include any number of additional devices, such as additional computers, routers, and switches, to facilitate communications among the devices of the system <NUM>.

Referring now to <FIG>, in an illustrative embodiment, the vehicle computing device <NUM> establishes an environment <NUM> during operation. The illustrative environment <NUM> includes a pathfinder <NUM>, a segment analyzer <NUM>, a path ranker <NUM>, a user interface <NUM>, and an in-trip updater <NUM>. The various components of the environment <NUM> may be embodied as hardware, firmware, software, or a combination thereof. As such, in some embodiments, one or more of the components of the environment <NUM> may be embodied as circuitry or collection of electrical devices (e.g., pathfinder circuitry <NUM>, segment analyzer circuitry <NUM>, path ranker circuitry <NUM>, user interface circuitry <NUM>, and/or in-trip updater circuitry <NUM>). It should be appreciated that, in such embodiments, one or more of the pathfinder circuitry <NUM>, the segment analyzer circuitry <NUM>, the path ranker circuitry <NUM>, the user interface circuitry <NUM>, and/or the in-trip updater circuitry <NUM> may form a portion of one or more of the processor <NUM>, the I/O subsystem <NUM>, and/or other components of the vehicle computing device <NUM>. Additionally, in some embodiments, one or more of the illustrative components may form a portion of another component and/or one or more of the illustrative components may be independent of one another.

The user interface <NUM> is configured to receive a requested destination from a user of the vehicle computing device <NUM> (e.g., a driver, passenger, or other occupant of the advanced vehicle <NUM>). The user interface <NUM> may be further configured to display a proposed route to the user and to receive a selected route from the user in response to displaying the proposed route. The proposed route may be determined as described further below. The user interface <NUM> may be further configured to alert the user of a change in the autonomous quality of service score associated with an upcoming route segment during a trip by the advanced vehicle <NUM>.

The pathfinder <NUM> is configured to determine multiple route segments <NUM> of one or more routes to the destination. As described above, the destination may be requested by the user of the vehicle computing device <NUM>.

The segment analyzer <NUM> is configured to determine, for each of the route segments <NUM>, one or more associated autonomous driving factors <NUM>. Each autonomous driving factor <NUM> is a numeric value arranged to be indicative of an autonomy level achievable by the advanced vehicle <NUM> for the associated route segment <NUM> and may include high-definition map availability, weather conditions, road conditions, traffic conditions, sensor capabilities, sensor health, and/or other factors. The segment analyzer <NUM> is further configured to determine, for each route segment <NUM>, an autonomous quality of service (QoS) score <NUM> based on the associated autonomous driving factors <NUM>. Each autonomous QoS score <NUM> may be determined, for example, as a weighted average of the autonomous driving factors <NUM> associated with a route segment <NUM>.

The path ranker <NUM> is configured to rank multiple routes to the destination based on the autonomous QoS scores <NUM> associated with the route segments <NUM> of each route. The routes may be ranked based on one or more user policies <NUM>, which may include a predetermined threshold autonomous QoS score <NUM>, variation in autonomous QoS scores <NUM>, historic driving data of the user, total time of the route, total distance of the route, or other criteria associated with the route. The path ranker <NUM> is further configured to select a proposed route based on the ranking, which may be displayed by the user interface <NUM> as described above.

The in-trip updater <NUM> is configured to monitor the autonomous driving factors <NUM> for each of the route segments <NUM> during a trip by the advanced vehicle <NUM>. In response to changes in the autonomous driving factors <NUM>, the autonomous QoS scores <NUM> are updated, the ranking of the routes to the destination is updated, and a proposed re-routing is determined in response to updating the ranking.

Referring now to <FIG> and <FIG>, in use, the vehicle computing device <NUM> may execute a method <NUM> for autonomous vehicle QoS determination and communication. It should be appreciated that, in some embodiments, the operations of the method <NUM> may be performed by one or more components of the environment <NUM> of the vehicle computing device <NUM> as shown in <FIG>. The method <NUM> begins with block <NUM>, shown in <FIG>, in which the vehicle computing device <NUM> receives a requested destination from a user of the vehicle computing device <NUM> (e.g., a driver, passenger, or other occupant of the advanced vehicle <NUM>). The user may specify an address, a landmark, a business (e.g., restaurant, retail store, fueling/charging station, etc.), or other destination. The destination may be provided by the user with a touch screen, with voice input, or with any other input modality of the vehicle computing device <NUM>.

In block <NUM>, the vehicle computing device <NUM> determines route segments <NUM> for one or more routes to the destination. Each route segment <NUM> may represent a road, driveway, highway, intersection, interchange, road segment, or other part of a route to the destination. The vehicle computing device <NUM> determines multiple different routes to the destination. Certain route segments <NUM> may be shared between multiple routes to the destination. The routes may start at the current location of the advanced vehicle <NUM> or at another starting location. Illustrative routes and route segments <NUM> are shown in <FIG> and described below.

In block <NUM>, the vehicle computing device <NUM> determines one or more autonomous driving factors <NUM> for each route segment <NUM>. Each autonomous driving factor <NUM> is indicative of an autonomy level achievable by the advanced vehicle <NUM> for that corresponding route segment <NUM>. According to the invention, the autonomous driving factors <NUM> are embodied as numeric values or other data corresponding to autonomy levels such as the autonomy levels specified by SAE International (e.g., numeric values <NUM> to <NUM> or scaled equivalents between <NUM> and <NUM>). The autonomous driving factors <NUM> may be determined based on diagnostic data, status data, or other data generated by the advanced vehicle <NUM> or based on data received from one or more external data services <NUM>.

In some embodiments, in block <NUM> the vehicle computing device <NUM> may determine high-definition map availability for each route segment <NUM>. Operating the advanced vehicle <NUM> at higher autonomy levels (e.g., partially autonomy, conditional autonomy, high autonomy, and/or full autonomy) may require high-definition or other detailed map data for the associated route segment <NUM>. Similarly, route segments <NUM> with less-detailed map data available may require user intervention and/or control of the advanced vehicle <NUM> and thus indicate a lower autonomy level. The vehicle computing device <NUM> may determine whether high-definition map data is available from an external data service <NUM> (e.g., a mapping server or other geographic information service) or otherwise accessible by the vehicle computing device <NUM>. The value of the autonomous driving factor <NUM> may be proportional to high-definition map availability for the corresponding route segment <NUM>.

In some embodiments, in block <NUM>, the vehicle computing device <NUM> may determine weather conditions for each route segment <NUM>. Operating the advanced vehicle <NUM> at higher autonomy levels (e.g., partially autonomy, conditional autonomy, high autonomy, and/or full autonomy) may be possible only in certain weather conditions. For example, sensor data quality produced by certain sensors <NUM> of the advanced vehicle <NUM> may depend on visibility, fog, rain, snow, or other weather conditions. As another example, the motor/actuator system <NUM> may require certain weather conditions to control motion of the advanced vehicle <NUM>. Thus, route segments <NUM> with certain weather conditions (e.g., poor visibility, rain, snow, or other conditions) may require user intervention and/or control of the advanced vehicle <NUM> and thus indicate a lower autonomy level. The vehicle computing device <NUM> may receive weather conditions data from an external data service <NUM> such as a weather server, from sensors <NUM> of the advanced vehicle <NUM>, and/or from other sources. The value of the autonomous driving factor <NUM> may be proportional to relative visibility, precipitation, or other weather conditions.

In some embodiments, in block <NUM> the vehicle computing device <NUM> may determine road and/or traffic conditions for each route segment <NUM>. For example, the vehicle computing device <NUM> may identify road closures, traffic hazards, road construction, traffic jams, congestion, or road and/or traffic conditions. The autonomy level associated with road and/or traffic conditions may depend on capabilities of the particular advanced vehicle <NUM>. For example, certain advanced vehicles <NUM> may require user intervention for route segments <NUM> with traffic hazards, road closures, or other road conditions. As another example, certain advanced vehicles <NUM> may provide full automation for route segments <NUM> with slow-speed traffic jams but require user control for route segments <NUM> with free-flowing traffic. The vehicle computing device <NUM> may receive the road and/or traffic conditions from a data service <NUM> such as a crowdsourced traffic data server or other data source.

In block <NUM>, the vehicle computing device <NUM> may determine vehicle capabilities and/or health, including sensor <NUM> availability. For example, operating the advanced vehicle <NUM> at higher autonomy levels (e.g., partially autonomy, conditional autonomy, high autonomy, and/or full autonomy) may require certain sensors <NUM> (e.g., camera, lidar, or other sensors) to be operating correctly. If certain sensors <NUM> are inoperable or otherwise unavailable, the advanced vehicle <NUM> may require user intervention or control. Thus, the value of the autonomous driving factor <NUM> may indicate full autonomy (e.g., level <NUM>) if the required sensors <NUM> are available and the lowest autonomy (e.g., level <NUM> or level <NUM>) if the required sensors <NUM> are not avaialable.

After determining the autonomous driving factors <NUM>, in block <NUM> the vehicle computing device <NUM> determines an autonomous driving quality of service (QoS) score for each route segment <NUM>. The QoS score may be embodied as a numeric value or other data corresponding to an autonomy level achievable by the advanced vehicle <NUM> for the corresponding route segment <NUM>. In some embodiments, each QoS score may be determined as a weighted average of the autonomous driving factors <NUM> associated with each route segment <NUM>. For example, a QoS score may be determined using Equation <NUM>, below. In Equation <NUM>, the QoS score Q is determined using as the sum of the n products of a vector of autonomous driving factors v and a vector of weights w. Illustratively, each autonomous driving factor vi may be a numeric value scaled from <NUM> to <NUM>, corresponding to autonomy level. The weights w sum to <NUM>. The value of each weight may be determined based on domain knowledge and the particular advanced vehicle <NUM>. For example, sensor health may be weighted more than high-definition map availability, and so on. Example calculations of the autonomous QoS score Q are described further below in connection with <FIG>.

In block <NUM>, the vehicle computing device <NUM> ranks candidate routes based on the autonomous QoS scores <NUM> of the route segments <NUM> of the route and any applicable user policies <NUM>. The user policies <NUM> may include any thresholds, preferences, or other criteria that may be evaluated to rank one potential route over another. In some embodiments, in block <NUM>, the vehicle computing device <NUM> may rank the routes based on autonomy level. For example, in some embodiments, the vehicle computing device <NUM> may rank a route according to an average autonomy level, a weighted average autonomy level, or another composite autonomy level determined based on the QoS scores <NUM> of the route segments <NUM> included in that route. As another example, vehicle computing device <NUM> may rank routes by comparing the QoS scores <NUM> of each route segments <NUM> to a threshold QoS score <NUM>. Continuing that example, the user may specified a minimum autonomy level <NUM> (conditional automation), in which example the vehicle computing device <NUM> may reject routes that include any route segment <NUM> with a QoS score <NUM> below level <NUM>. Similarly, in some embodiments, in block <NUM> the vehicle computing device <NUM> may rank the routes based on variation in autonomy level between the route segments <NUM>. For example, a user may prefer that the entire trip remain at the same autonomy level rather than switching between higher and lower autonomy levels for different route segments <NUM>.

In some embodiments, in block <NUM>, the vehicle computing device <NUM> may rank the routes based on historic driving data. For example, the vehicle computing device <NUM> may prefer routes that the user has driven in the past. In some embodiments, in block <NUM> the vehicle computing device <NUM> may rank the routes based on length or time of the route. For example, the vehicle computing device <NUM> may prefer routes that are shorter in time and/or distance.

It should be understood that in some embodiments, routes may be ranked by a weighted average or other combination of one or more user policies <NUM>, for example based on a combination of autonomy level, autonomy level variation, historic data, length of route, and/or time of route. The user may provide relative weighting factors for those criteria. In some embodiments, a ranking value for a route may be determined using Equation <NUM>, below. In Equation <NUM>, Qi is the QoS score of route segment <NUM> number i, Sl is the length of the route segment <NUM>, St is the total length of all route segments <NUM> in the route, F indicates the frequency of use of the route by the user, VRl indicates variation in autonomy level of the route, and td is the time to the destination for the route. The values W<NUM>, W<NUM>, W<NUM>, W<NUM>, and W<NUM> are weighting factors, which may be included in the user policies <NUM> or otherwise provided by the user.

In block <NUM>, shown in <FIG>, the vehicle computing device <NUM> displays a proposed route to the user. The proposed route may be, for example, the top-ranked route based on the ranking determined in block <NUM>. The proposed route may be displayed as a map on the display <NUM> or otherwise communicated to the user of the advanced vehicle <NUM>. In some embodiments, the vehicle computing device <NUM> may display the autonomous QoS score <NUM> for each route segment <NUM>, for example by displaying an autonomous driving level or other indication of the autonomous QoS score <NUM>.

In block <NUM>, the vehicle computing device <NUM> receives a route selection from the user. For example, the user may accept the proposed route or indicate that the proposed route is not acceptable. The vehicle computing device <NUM> may receive the route selection with a touch screen, voice input, or any other available input modality of the vehicle computing device <NUM>. In block <NUM>, the vehicle computing device <NUM> determines whether a route has been selected by the user. If so, the method <NUM> advances to block <NUM>, described below. If no route has been selected, the method <NUM> branches to block <NUM>, in which the vehicle computing device <NUM> may propose an alternate route to the user. For example, the vehicle computing device <NUM> may select the next-highest-ranked route based on the ranking determined in block <NUM> or another route determined by the vehicle computing device <NUM>. After proposing the alternate route, the method <NUM> loops back to block <NUM> to display the proposed alternate route to the user and receive a user selection. If no routes remain or a route is otherwise not selected, the vehicle computing device <NUM> may halt the method <NUM>, indicate an error, or otherwise stop the current user interaction.

Referring back to block <NUM>, if the user selects a route, the method <NUM> advances to block <NUM>, in which the vehicle computing device <NUM> displays the selected route to the user. The route may be displayed as a map on the display <NUM> or otherwise communicated to the user of the advanced vehicle <NUM>. In some embodiments, the vehicle computing device <NUM> may display the autonomous QoS score <NUM> for each route segment <NUM>, for example by displaying an autonomous driving level or other indication of the autonomous QoS score <NUM>.

In block <NUM>, the advanced vehicle <NUM> drives the selected route using an available autonomy level. The available autonomy level depends on the route segment <NUM> currently being driven by the advanced vehicle <NUM>. As described above, the autonomy level may be any level of vehicle automation, including driver assistance, partial automation, conditional automation, high automation, or full automation. The autonomous driving features of the advanced vehicle <NUM> may be controlled by the vehicle computing device <NUM>, the motor/actuator system <NUM>, and/or other control systems of the advanced vehicle <NUM>. In some embodiments, in block <NUM> the vehicle computing device <NUM> may notify the user of changes in autonomy level. For example, the vehicle computing device <NUM> may provide advanced warning to the user when the advanced vehicle <NUM> nears a route segment <NUM> with a reduced autonomous QoS score <NUM> as compared to the current route segment <NUM>. The vehicle computing device <NUM> may notify the user with the display <NUM>, a voice alert, or any other user interface modality.

In block <NUM>, the vehicle computing device <NUM> monitors for updated autonomous driving factors <NUM>. The vehicle computing device <NUM> may monitor for updated diagnostic data, status data, or other data generated by the advanced vehicle <NUM> or for updated data received from one or more external data services <NUM>. For example, the vehicle computing device <NUM> may monitor for updated high-definition map availability data, updated weather condition data, or updated road or traffic condition data. As another example, the vehicle computing device <NUM> may monitor for updated vehicle capability and/or health data, including updated sensor <NUM> availability data. In block <NUM>, the vehicle computing device <NUM> determines whether the autonomous driving factors <NUM> have been updated. If not, the method <NUM> loops back to block <NUM> to continue driving the selected route. If the autonomous driving factors <NUM> have been updated, the method <NUM> loops back to block <NUM>, shown in <FIG>, to update the autonomous QoS scores <NUM> based on the updated autonomous driving factors <NUM>. If the autonomous QoS scores <NUM> change, the vehicle computing device <NUM> re-ranks potential routes to the destination and proposes an updated route to the user as described above. The vehicle computing device <NUM> may continue driving the route and monitoring for updated autonomous driving factors <NUM> until the advanced vehicle <NUM> reaches the destination or otherwise ends the current trip.

Referring now to <FIG>, diagram <NUM> illustrates potential routes and route segments <NUM> for an illustrative trip in an advanced vehicle <NUM>. The diagram <NUM> shows a starting position <NUM>, labeled node A, and a destination <NUM>, labeled node F. Nodes B through E represent intersections, waypoints, addresses, or other positions between the starting position <NUM> and the destination <NUM>. Each of those nodes is connected by a route segment <NUM>, which are illustratively labeled segments s<NUM> through s<NUM>.

As described above, each route segment <NUM> may be associated with multiple autonomous driving factors <NUM>. Those autonomous driving factors <NUM> may be processed using Equation <NUM>, above, to determine an autonomous QoS score <NUM> for each route segment <NUM>. Table <NUM>, shown below, illustrates example autonomous driving factors <NUM> and resulting QoS scores <NUM> for the illustrative route segments <NUM> shown in <FIG>. In Table <NUM>, factor v<NUM> indicates high-definition map availability, factor v<NUM> indicates GPS availability, factor v<NUM> indicates sensor health, factor v<NUM> indicates road conditions, factor v<NUM> indicates weather conditions, and factor v<NUM> indicates traffic conditions. As shown, each factor v<NUM> through v<NUM> is scaled from <NUM> to <NUM>, corresponding to potential autonomous driving levels. Of course, in other embodiments, the factors v<NUM> through v<NUM> may be embodied as different values and/or scales, such as floating point values from <NUM> (corresponding to autonomous level <NUM>) to <NUM> (corresponding autonomous level <NUM>). Weights w<NUM> through w<NUM> correspond to factors v<NUM> through v<NUM> and are determined based on domain knowledge and the particular advanced vehicle <NUM>. The autonomous QoS scores Q for each segment s<NUM> through s<NUM> are determined using Equation <NUM> as described above and are illustratively rounded to the nearest integer value. As shown, illustrative segments s<NUM>, s<NUM>, s<NUM>, and s<NUM> have autonomous QoS scores Q corresponding to autonomous driving level <NUM>, segment s<NUM> has autonomous QoS score Q corresponding to autonomous driving level <NUM>, and segment s<NUM> autonomous QoS score Q corresponding to autonomous driving level <NUM>.

Referring now to <FIG>, diagram <NUM> illustrates one potential route <NUM> from the starting position <NUM> to the destination <NUM>. As shown, the route <NUM> includes route segments s<NUM>, s<NUM>, and s<NUM>. The route <NUM> may be selected, for example, as the path with the shortest distance and/or drive time between the starting position <NUM> to the destination <NUM>. However, note that segment s<NUM> has an autonomous QoS score <NUM> equivalent to autonomous driving level <NUM>, and thus the advanced vehicle <NUM> may require increased user supervision/intervention while driving that segment.

Referring now to <FIG>, diagram <NUM> illustrates another potential route <NUM> from the starting position <NUM> to the destination <NUM>. As shown, the route <NUM> includes route segments s<NUM>, s<NUM>, s<NUM>, s<NUM>, and s<NUM>. The route <NUM> may be selected, for example, based on a user policy <NUM> that defines a minimum acceptable autonomous QoS score <NUM>. As shown, every segment of the route <NUM> has an autonomous QoS score <NUM> greater than or equal to autonomous driving level <NUM>. Thus, the advanced vehicle <NUM> may drive the entire route <NUM> without changing to autonomous driving level <NUM>.

Claim 1:
A computing device (<NUM>) for autonomous driving route selection, the computing device comprising:
a pathfinder (<NUM>) configured to determine a plurality of route segments of a plurality of routes to a destination;
a segment analyzer (<NUM>) configured to determine, for each of the plurality of route segments, one or more autonomous driving factors associated with the route segment, wherein each autonomous driving factor is a numeric value arranged to be indicative of a driving autonomy level achievable by a vehicle on the associated route segment, and to determine, for each of the plurality of route segments, an autonomous quality of service score based on the associated one or more autonomous driving factors;
characterized in that the computing device further comprises:
an in-trip updater (<NUM>) configured to monitor the one or more autonomous driving factors for each of the plurality of route segments during a trip by the vehicle; and
a path ranker (<NUM>),
wherein the segment analyzer is further configured to update, for each of the plurality of route segments, the autonomous quality of service score based on the associated one or more autonomous driving factors, in response to monitoring of the one or more autonomous driving factors; and
wherein the path ranker is configured to rank the plurality of routes based on the autonomous quality of service scores associated with the plurality of route segments, in response to updating of the autonomous quality of service score; and to select a proposed re-routing from the ranked plurality of routes.