CN110214344B

CN110214344B - Vehicle management system

Info

Publication number: CN110214344B
Application number: CN201780084481.0A
Authority: CN
Inventors: S·C·珀佩尔; N·G·莱特温; S·J·凯利
Original assignee: Uber Technologies Inc
Current assignee: Uatc Co ltd
Priority date: 2016-12-14
Filing date: 2017-12-12
Publication date: 2020-11-27
Anticipated expiration: 2037-12-12
Also published as: SG10201911787YA; WO2018111877A1; CA3047095A1; SG10201911758YA; JP6945630B2; EP4116945A1; CN110214344A; JP2020502667A; JP2022002115A; EP3555866A1; SG10201911769UA; EP3555866B1; JP7139505B2

Abstract

The invention provides a system, a method and a vehicle for stopping the service of the vehicle. In one example embodiment, a method comprises: data indicative of one or more parameters associated with an autonomously driven vehicle is obtained by one or more computing devices onboard the autonomously driven vehicle. The autonomous driving vehicle is configured to provide a vehicle service to one or more users of the vehicle service. The method comprises the following steps: determining, by the computing device, based at least in part on the one or more parameters associated with the autonomous-driven vehicle, that there is a fault associated with the autonomous-driven vehicle. The method comprises the following steps: determining, by the computing device, one or more actions to be performed by the autonomous-driving vehicle based at least in part on the presence of the fault. The method comprises the following steps: performing, by the computing device, one or more of the actions to bring the autonomous-driving vehicle out of service based at least in part on the fault.

Description

Vehicle management system

Technical Field

The present invention relates generally to addressing failures of autonomous vehicles

Background

Autonomous driving vehicles may sense their surroundings and determine their location based on information associated with their surroundings through the use of various sensor devices. This may allow an autonomous vehicle to navigate without human intervention and in some cases even completely omit the use of a human driver. However, the lack of on-site human supervision can potentially reduce the chances of addressing problems associated with autonomously driven vehicles. While an autonomous-driven vehicle may be monitored by a remote tracking system, such monitoring may suffer from potential communication delays.

Disclosure of Invention

Aspects and advantages of embodiments of the present invention will be set forth in part in the description which follows and, in part, may be learned from the description or may be learned by practice of the embodiments.

One example aspect of the invention relates to a computer-implemented method of out-of-service a vehicle. The method comprises the following steps: data indicative of one or more parameters associated with an autonomously driven vehicle is obtained by one or more computing devices onboard the autonomously driven vehicle. The autonomous driving vehicle is configured to provide a vehicle service to one or more users of the vehicle service. The method comprises the following steps: determining, by the one or more computing devices, that there is a fault associated with the autonomous-driving vehicle based at least in part on the one or more parameters associated with the autonomous-driving vehicle. The method comprises the following steps: determining, by the one or more computing devices, one or more actions to be performed by the autonomous driving vehicle based at least in part on the presence of the fault. The method comprises the following steps: performing, by the one or more computing devices, one or more of the actions to bring the autonomous-driven vehicle out of service based at least in part on the fault.

Another example aspect of the invention relates to a computing system for out-of-service vehicles. The system comprises: one or more processors onboard the autonomous-driven vehicle. The system comprises: one or more memory devices onboard the autonomous driving vehicle. The one or more memory devices store instructions that, when executed by the one or more processors, cause the one or more processors to perform operations. The operations include: data indicative of one or more parameters associated with the autonomous-driven vehicle is obtained. The autonomous driving vehicle is configured to provide vehicle services to one or more users of the vehicle services. The autonomous-driving vehicle is associated with a status indicating that the autonomous-driving vehicle is available or unavailable to provide the vehicle service. The operations include: determining that there is a fault associated with the autonomous-driven vehicle based, at least in part, on a comparison of the one or more parameters associated with the autonomous-driven vehicle to one or more thresholds. The operations include: determining one or more actions to be performed by the autonomous driving vehicle based at least in part on the presence of the fault. At least one of the actions includes adjusting the state associated with the autonomous-driving vehicle. The operations include: adjusting the status associated with the autonomous-driven vehicle based at least in part on the fault to indicate that the autonomous-driven vehicle is unavailable for the vehicle service.

Yet another example aspect of the invention relates to an autonomous-driving vehicle. The autonomous-driving vehicle includes: one or more systems onboard the autonomous-driven vehicle; and one or more processors onboard the autonomous vehicle. The autonomous-driving vehicle includes: one or more memory devices onboard the autonomous driving vehicle. The one or more memory devices store instructions that, when executed by the one or more processors, cause the one or more processors to perform operations. The operations include: data indicative of one or more parameters associated with the autonomous-driven vehicle is obtained. At least a portion of the data is provided by one or more of the systems onboard the autonomous-driven vehicle. The autonomous-driving vehicle is included in a plurality of vehicles associated with a service provider, and the autonomous-driving vehicle is configured to provide vehicle services of the service provider to one or more users. The operations include: determining that there is a fault associated with the autonomous-driven vehicle based, at least in part, on the one or more parameters associated with the autonomous-driven vehicle. The operations include: performing one or more actions to bring the vehicle out of service based at least in part on the fault such that the autonomous-driving vehicle is unavailable to provide the vehicle service.

One example aspect of the invention relates to a computer-implemented method of stopping motion of a vehicle. The method comprises the following steps: data indicative of one or more parameters associated with an autonomously driven vehicle is obtained by one or more computing devices onboard the autonomously driven vehicle. The autonomous driving vehicle is configured to provide vehicle services to one or more users of the vehicle services. The method comprises the following steps: determining, by the one or more computing devices, that there is a fault associated with the autonomous-driving vehicle based at least in part on the one or more parameters associated with the autonomous-driving vehicle. The method comprises the following steps: determining, by the one or more computing devices, one or more actions to be performed by the autonomous driving vehicle based at least in part on the presence of the fault. At least one of the actions includes stopping motion of the autonomous driving vehicle. The method comprises the following steps: providing, by the one or more computing devices, one or more control command signals to one or more of the systems onboard the autonomous driving vehicle to facilitate stopping the motion of the autonomous driving vehicle in response to the presence of the fault.

Another example aspect of this invention relates to a computing system for stopping motion of a vehicle. The system comprises: one or more processors onboard the autonomous-driven vehicle. The system comprises: one or more memory devices onboard the autonomous driving vehicle. The one or more memory devices store instructions that, when executed by the one or more processors, cause the one or more processors to perform operations. The operations include: data indicative of one or more parameters associated with the autonomous-driven vehicle is obtained. The autonomous driving vehicle is configured to provide a vehicle service to one or more users of the vehicle service. The operations include: determining that there is a fault associated with the autonomous-driven vehicle based, at least in part, on the one or more parameters associated with the autonomous-driven vehicle. The operations include: determining one or more actions to be performed by the autonomous driving vehicle based at least in part on the fault. At least one of the actions includes stopping motion of the autonomous driving vehicle. The operations include: providing one or more control command signals to one or more of the systems onboard the autonomous driving vehicle to facilitate stopping the motion of the autonomous driving vehicle in response to the presence of the fault.

Yet another example aspect of the invention relates to an autonomous-driving vehicle. The autonomous-driving vehicle includes: one or more systems onboard the autonomous-driven vehicle and one or more processors onboard the autonomous-driven vehicle. The autonomous-driving vehicle includes: one or more memory devices onboard the autonomous driving vehicle. The one or more memory devices store instructions that, when executed by the one or more processors, cause the one or more processors to perform operations. The operations include: data indicative of one or more parameters associated with the autonomous-driven vehicle is obtained. At least a portion of the data indicative of the one or more parameters is provided via one or more of the systems onboard the autonomous-driven vehicle. The autonomous driving vehicle is configured to provide a vehicle service to one or more users of the vehicle service. The operations include: determining that there is a fault associated with the autonomous-driven vehicle based, at least in part, on the one or more parameters associated with the autonomous-driven vehicle. The operations include: determining one or more actions to be performed by the autonomous driving vehicle based at least in part on the fault. The operations include: providing one or more control command signals to one or more of the systems onboard the autonomous driving vehicle to perform one or more of the actions to facilitate stopping motion of the autonomous driving vehicle in response to the presence of the fault.

Other example aspects of this disclosure relate to systems, methods, vehicles, apparatuses, tangible, non-transitory computer-readable media, user interfaces, and memory devices for resolving vehicle faults.

These and other features, aspects, and advantages of the various embodiments will become better understood with reference to the following description and appended claims. The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments of the invention and together with the description, serve to explain the relevant principles.

Drawings

A detailed discussion of embodiments directed to one of ordinary skill in the art is set forth in the specification, which makes reference to the appended drawings, in which:

FIG. 1 depicts an example system according to an example embodiment of the invention;

FIG. 2 illustrates representations of example vehicle parameters and thresholds according to an example embodiment of the invention;

FIG. 3 illustrates a representation of an example service location according to an example embodiment of the invention;

FIG. 4 illustrates a representation of an example vehicle in a driving lane, according to an example embodiment of the invention;

FIG. 5 illustrates a representation of an example vehicle outside of a driving lane, according to an example embodiment of the invention;

FIG. 6 illustrates an example user interface displayed via a display device according to an example embodiment of the present disclosure;

FIG. 7 depicts a flow diagram of an example method of out-of-service a vehicle, according to an example embodiment of the invention;

FIG. 8 depicts a flow diagram of an example method of determining a threshold value, according to an example embodiment of the invention;

FIG. 9 depicts a flow diagram of an example method of stopping motion of a vehicle, according to an example embodiment of the invention; and

FIG. 10 depicts example components of an example system according to an example embodiment of the invention.

Detailed Description

Reference will now be made in detail to the embodiments, one or more examples of which are illustrated in the figures. Each example is provided by way of explanation of the embodiments, not limitation of the invention. Indeed, it will be apparent to those skilled in the art that various modifications and variations can be made to the embodiments without departing from the scope or spirit of the invention. For example, features illustrated or described as part of one embodiment can be used on or in conjunction with another embodiment to yield yet a further embodiment. It is therefore intended that the present aspects cover such modifications and variations.

Example aspects of this disclosure relate to stopping and/or out-of-service an autonomously driven vehicle based on detecting a fault associated with the vehicle. For example, a service provider may provide vehicle services to multiple users using a fleet of vehicles. A service provider may be an entity that organizes, coordinates, manages, etc., vehicle services (e.g., transportation, courier, delivery, and/or other services) for users. The fleet may include, for example, autonomous vehicles that may drive, navigate, operate, etc., with minimal and/or no interaction from human drivers, as will be further described. The service provider may coordinate autonomous driving of the vehicle to provide the service provider's vehicle services. An autonomously driven vehicle may include a vehicle computing system that may monitor one or more parameters associated with the vehicle. For example, a vehicle computing system may monitor the fuel level, charge level, engine condition, tire pressure, available data storage in an on-board memory device, and/or other health and maintenance data of an autonomous driving vehicle. The vehicle computing system may determine whether a fault associated with the vehicle exists based at least in part on the one or more parameters. For example, the vehicle computing system may determine that the fuel level of the vehicle is too low because it is below the fuel threshold. Additionally or alternatively, a current user of the vehicle may provide user input via the user device indicating that a fault (e.g., smoke inside the vehicle, an emergency user health issue) exists. To address such faults, the vehicle computing system may cause the vehicle to stop servicing itself (e.g., travel to a service station) and/or stop motion of the vehicle (e.g., for roadside service). In this manner, aspects of the present invention may allow an on-board computing system of a vehicle to locally resolve a fault associated with the vehicle.

More particularly, the computing system of the autonomous-driven vehicle may include a plurality of systems located onboard the autonomous-driven vehicle. For example, an autonomously driven vehicle may include one or more data acquisition systems (e.g., sensors, image capture devices), autonomous systems (e.g., for controlling autonomous navigation), one or more human interface systems (e.g., physical interface buttons, a user interface displayed via a display device), and so forth. One or more computing devices of a vehicle computing system (e.g., of a fault detection system) may communicate with such a system to obtain data indicative of one or more parameters associated with a vehicle. As indicated above, the parameters may include, for example, fuel level of the autonomous driving vehicle, charge level, engine condition, tire pressure, conditions associated with the interior of the vehicle, conditions associated with the exterior of the vehicle (e.g., damage), available data storage in the on-board memory device, and/or other health and repair data. In some implementations, the parameter can be indicative of a user input and/or can be related to a user of the vehicle. For example, the vehicle computing system may obtain (e.g., via a human-machine interface) data indicative of user input reporting a fault (e.g., smoke in the interior, user panic attack).

The vehicle computing system may be configured to determine that there is a fault associated with the vehicle. For example, in some embodiments, the vehicle computing system may determine that a fault exists based at least in part on a comparison of one or more of the parameters to one or more thresholds. In some implementations, the threshold may be a static preset threshold. For example, the vehicle computing system may be configured to determine that there is a fault associated with the vehicle engine when the engine temperature exceeds a preset temperature threshold.

In some implementations, the threshold may be a dynamic threshold that may be adjusted by the vehicle computing system in real-time and/or near real-time. For example, a vehicle computing system may be configured to monitor parameters of a vehicle such that an autonomous-driving vehicle is always able to travel to and reach a service location (e.g., a service stop). To do so, the vehicle computing system may obtain data indicative of a geographic location of one or more service locations.

In some implementations, the vehicle computing system can select an appropriate repair location based at least in part on the characteristics of the fault and/or the characteristics of the repair location. For example, the vehicle computing system may select an engine repair station for engine failures and/or a computer repair station for computer-based failures. The vehicle computing system may determine a travel route to at least one of the repair locations (e.g., the most appropriate location) and one or more travel factors (e.g., traffic, weather, construction) associated with the travel route to the repair location. The vehicle computing system may determine, in real-time and/or near real-time, the necessary levels of parameters (e.g., fuel, charge of the energy storage device, available data storage device) needed by the autonomous driving vehicle to traverse the travel route and reach the selected service location. The vehicle computing system may set thresholds to reflect these necessary levels to ensure that the vehicle can reach the service location.

As an example, for autonomous navigation, the data acquisition system may continuously obtain data (e.g., image data) associated with the surroundings of the vehicle. Such data may be used by the autonomous system of the vehicle to navigate the vehicle according to signs, lane markings, etc. while avoiding animals, objects, etc. When the data acquisition system acquires the data, the data is stored in a memory device onboard the autonomous vehicle. Thus, the vehicle computing system may determine, in real-time and/or near real-time, a threshold amount of available data storage needed for autonomous navigation of the vehicle to the service location based at least in part on the travel route and/or travel factors. The vehicle computing system may detect that a fault (e.g., lower data storage availability) exists if the amount of available data storage in the on-board memory device approaches and/or falls below a threshold.

In some embodiments, the vehicle computing system may determine an operating state of the vehicle based at least in part on the fault. The operating state may indicate whether the autonomous-driving vehicle is appropriate to provide vehicle services to one or more users. For example, the operating state may indicate that the vehicle is eligible to continue providing vehicle services to one or more current users. Thus, the vehicle may stop itself from service after completing provision of vehicle service (e.g., transporting the current occupant to its destination location), traveling to a service location, and so forth. In some embodiments, the operating state may indicate that the vehicle is not suitable for providing vehicle services. Thus, the vehicle computing system may deny any service requests and continue to resolve the vehicle fault.

The vehicle computing system may determine one or more actions to help resolve the vehicle fault. For example, in some implementations, at least one of the actions can include taking the vehicle out of service, such that the vehicle is not available to provide vehicle services of the service provider. For example, an autonomously driven vehicle may be associated with a state that indicates that the autonomously driven vehicle is available or unavailable to provide vehicle services. The vehicle computing system may adjust a state associated with the autonomous-driven vehicle in response to detecting the fault to indicate that the autonomous-driven vehicle is unavailable to provide vehicle services. As an example, the vehicle computing system may communicate with a remote operating computing system of a service provider to report a fault, indicate that the vehicle is unavailable to provide vehicle services, and the like. In some implementations, the operating computing system can remove vehicles from a service queue associated with providing vehicle services and/or otherwise remove vehicles from a pool of vehicles identified as being available for providing vehicle services to a user. As such, the vehicle will not be assigned to (and/or will not accept assignment to) the user requesting vehicle services from the service provider. The vehicle computing system may also or alternatively provide one or more control command signals to one or more of the onboard systems of the vehicle (e.g., autonomous systems) to cause the vehicle to travel to and arrive at a service location (e.g., to resolve the fault).

In some implementations, at least one of the actions may include stopping motion of the autonomous driving vehicle. The vehicle computing system may provide one or more control command signals to one or more of the onboard systems of the vehicle to perform such action(s). As an example, a vehicle computing system may communicate with a human machine interface to obtain data indicative of user input (e.g., provided via a user device in the interior of the vehicle). The user input may indicate a fault, such as the presence of smoke and/or fire in the interior of the vehicle (and/or a request to stop the vehicle). The vehicle computing system may determine, based at least in part on this user input, that there is a fault and that the fault is severe (due to the fault type (e.g., smoke, fire), its associated location (e.g., interior of the vehicle), and/or other characteristics). The vehicle computing system may thus determine that it is appropriate to stop the vehicle.

The vehicle computing system may determine a stopping location of the autonomous driving vehicle based at least in part on a fault associated with the vehicle and one or more travel conditions (e.g., heading, speed, location, geographic location, road structure, or the like). For example, where the fault is severe and the vehicle is traveling on a road without shoulders, the vehicle computing system may select a stop position in the current driving lane of the vehicle. However, where the vehicle is traveling in a right lane of a shouldered highway, the vehicle computing system may select a stop location outside the current driving lane (e.g., on the shoulder). The vehicle computing system may send one or more control command signals (e.g., to an autonomous system, a braking system) to slow the vehicle to a stop position (e.g., inside or outside the current driving lane). In this way, the vehicle computing system may control the stop time and location of the vehicle.

To placate a current user of an autonomously driven vehicle, a vehicle computing system may coordinate one or more communications with the current user. For example, the vehicle computing system may notify the user of the fault via a display device (e.g., of a tablet computer associated with the vehicle, of the current user's mobile phone). This may provide the user with contextual information about why the vehicle stopped. In some embodiments, the vehicle computing system may request a human operator (e.g., associated with a service provider) to communicate with a current user of the vehicle. If desired, the vehicle computing system can request that a different vehicle be assigned to provide vehicle services to the user. Further, if possible, the vehicle computing system may request a field repair to the autonomous vehicle, contact an emergency agency (e.g., an ambulance), and/or cause the autonomous vehicle to travel to a repair location.

The systems and methods described herein may provide several technical effects and benefits. For example, the vehicle computing system may monitor vehicle parameters locally (e.g., onboard the vehicle) and determine that a fault exists. Further, the autonomous vehicle can diagnose and resolve the fault without having to communicate with a service provider's remotely operated computing system. This may allow the autonomous driving vehicle to avoid potential latency issues that may arise when communicating with a remote computing device (e.g., due to poor network connectivity, data upload/download). The autonomous-driven vehicle may also avoid potential latency issues that may arise from the remote computing device processing multiple vehicle fault diagnosis requests (e.g., in the order in which the requests are received).

Furthermore, by addressing vehicle faults onboard an autonomous vehicle, the systems and methods of the present invention may limit the allocation of processing and storage resources to operate the computing system required for such analysis. The saved resources may be allocated to other functions of operating the computing system, such as processing of service requests, vehicle routing, and the like. In this manner, the systems and methods according to example aspects of the invention have the technical effect of providing a computationally efficient method of saving computing resources for other functions while addressing vehicle failures.

The system and method of the present invention also provide improvements in vehicle computing technology, such as autonomous driving vehicle computing technology. For example, the methods and systems enable vehicle technology to locally detect and resolve faults associated with autonomously driven vehicles. For example, the systems and methods may allow one or more computing devices onboard an autonomous-driven vehicle to obtain data indicative of one or more parameters associated with the autonomous-driven vehicle, determine that a fault associated with the autonomous-driven vehicle exists based at least in part on the one or more parameters, and determine one or more actions to be performed by the autonomous-driven vehicle based at least in part on the existence of the fault. In some embodiments, a computing device onboard an autonomous-driven vehicle may perform one or more of the actions to bring the vehicle out of service based at least in part on the fault such that the vehicle is unavailable to provide vehicle service. In some implementations, a computing device onboard the autonomous vehicle may provide one or more control command signals to one or more of the systems onboard the autonomous vehicle to perform one or more of the actions to facilitate stopping motion of the autonomous vehicle. Thus, the systems and methods of the present disclosure may improve the ability of a vehicle computing system to address a fault associated with a vehicle. For example, the systems and methods may improve vehicle computing systems by reducing the computational response time for resolving a determined fault (e.g., by avoiding the aforementioned latency issues of remote computing devices). This may improve the safety of the user of the vehicle. Further, by reducing the dependency of the vehicle computing system on the remote computing device, the systems and methods of the present invention can relieve stress on the vehicle's communication interfaces, bandwidth usage, network traffic, and the like.

Further, the systems and methods of the present disclosure may improve the ability of a vehicle computing system to ensure that a vehicle may reach a service location. For example, the systems and methods may allow one or more computing devices onboard a vehicle to obtain data indicative of a repair location (e.g., including a geographic location thereof), determine a route of travel to the repair location, obtain data indicative of one or more travel conditions associated with the route of travel, and determine one or more thresholds in real-time based at least in part on the route of travel and the travel conditions. The threshold may indicate one or more necessary levels of one or more parameters (e.g., fuel level, charge level, available data storage) required for the autonomous driving vehicle to traverse the travel route and reach the service location. In this manner, the systems and methods may improve the ability of the vehicle computing system to determine whether and when it is appropriate for the vehicle to travel to the service location. Thus, the vehicle computing system may better avoid vehicle malfunction, damage, and the like.

Referring now to the drawings, example embodiments of the invention will be discussed in further detail. FIG. 1 depicts an example system 100 according to an example embodiment of the invention. The system 100 may include a vehicle 102 and an operating computing system 104. The operating computing system 104 may be associated with a service provider that provides one or more vehicle services to a plurality of users via a pair of vehicles including, for example, the vehicle 102. The vehicle services may include transportation services (e.g., ride-sharing services), courier services, delivery services, and/or other types of services.

The operating computing system 104 may include a number of components for performing various operations and functions. For example, the operating computing system 104 may include and/or be otherwise associated with one or more remote computing devices that are remote from the vehicle 102. The one or more computing devices may include one or more processors and one or more memory devices. The one or more memory devices may store instructions that, when executed by the one or more processors, cause the one or more processors to perform operations and functions (e.g., for a service provider)

For example, the operating computing system 104 can be configured to monitor and communicate with the vehicle 102 and/or its user to coordinate vehicle services provided by the vehicle 102. To do so, the operating computing system 104 may manage a service queue 106 that pairs a vehicle (e.g., 102) with one or more users to provide the users with one or more vehicle services of a service provider. The vehicle 102 may be included in a plurality of vehicles 103 (e.g., a fleet of vehicles) associated with a service provider. Each vehicle of the plurality of vehicles 103 may be configured to provide vehicle services of a service provider.

The service queue 106 can identify at least a subset of the plurality of vehicles 103 associated with the service provider that are available to provide vehicle services. The service queue 106 may comprise data structures that may be stored in a medium, such as a cache and/or other memory resources. The service queue 106 can be an aggregation of data items, some of which can be used to identify particular vehicles that are available to provide vehicle services. A selection process may be associated with the service queue 106 in order to pair one or more users with vehicles that may provide the vehicle service requested by the user. The service queue 106 may be different from a maintenance queue used, for example, to coordinate maintenance of vehicles in a fleet (e.g., at a service station).

In some embodiments, the operating computing system 104 may not use a service queue to pair vehicles to users of the vehicle service. For example, the vehicles may be included in a library of vehicles that are deemed available for providing vehicle services. Vehicles from the vehicle library may be selected to provide vehicle services to the user based at least in part on one or more factors (e.g., location, vehicle type, vehicle heading). Thus, in some embodiments, the operating computing system 104 may not select the vehicle 102 to provide vehicle services based on the order/location of the vehicle in the service queue.

The vehicle 102 may be associated with a state 105 indicating that the vehicle 102 is available or unavailable to provide vehicle services. Other vehicles in the plurality of vehicles 103 may also be associated with similar respective states. The vehicle 102 can be considered available to provide vehicle services when the vehicle 102 accepts and/or receives one or more requests and/or assignments to provide vehicle services to one or more users. In some implementations, the vehicle 102 can be considered available to provide vehicle services when the vehicle 102 is in the service queue 106 and/or actively accepts requests and/or assignments from the operating computing system 104. The vehicle 102 can be considered unavailable to provide vehicle services when the vehicle 102 does not accept one or more requests and/or assignments to provide vehicle services to one or more users. For example, the vehicle 102 can be considered unavailable to provide vehicle services when the vehicle 102 is not in the service queue 106 and/or does not accept requests and/or assignments from the operating computing system 104 to provide vehicle services to one or more users. As will be further described herein, the vehicle 102 can be configured to adjust the state 105 associated with the vehicle 102 such that the vehicle 102 can make itself available and/or unavailable to provide vehicle services to a user. The indication, record, and/or other data indicative of the status 105 can be stored locally in one or more memory devices of the vehicle 102. Additionally or alternatively, the vehicle 102 can provide data indicative of the state 105 to the operating computing system 104, which can store the indication, record, and/or other data indicative of the state 105 in one or more memory devices associated with the operating computing system 104 (e.g., remote from the vehicle).

The operating computing system 104 may communicate with the vehicle 102 via one or more communication networks. The communication network may include various wired and/or wireless communication mechanisms (e.g., cellular, wireless, satellite, microwave, and/or radio frequency) and/or any desired network topology. For example, the network may include a local area network (e.g., an intranet), a wide area network (e.g., the internet), a wireless LAN network (e.g., via Wi-Fi), a cellular network, a SATCOM network, a VHF network, an HF network, a WiMAX-based network, and/or any other suitable communication network (or combination thereof) for transmitting data to and/or from the vehicle 102.

The vehicle 102 may be an earth-based vehicle (e.g., an automobile), an aircraft, and/or another type of vehicle. The vehicle 102 may be an autonomous driving vehicle that may drive, navigate, operate, etc., with minimal and/or no interaction from a human driver. The autonomous-driving vehicle 102 may be configured to operate in one or more modes, such as, for example, a fully autonomous mode of operation, a semi-autonomous mode of operation, a park mode, a sleep mode, and so forth. A fully autonomous (e.g., self-driving) mode of operation may be a mode of operation in which the vehicle 102 may provide driving and navigation operations with minimal and/or no interaction from a human driver in the vehicle. The semi-autonomous mode of operation may be a mode of operation in which the vehicle 102 may operate with some interaction from a human driver in the vehicle. The park and/or sleep modes may be used between operating modes when the vehicle 102 waits to provide subsequent vehicle services, recharge between operating modes, and the like.

The vehicle 102 may include a vehicle computing system 108. The vehicle computing system 108 may include various components for performing various operations and functions. For example, the vehicle computing system 108 may include one or more computing devices 110 onboard the vehicle 102. The computing device 110 may include one or more processors and one or more memory devices, each of which is onboard the vehicle 102. The one or more memory devices may store instructions that, when executed on the one or more processors, cause the one or more processors to perform operations and functions, such as operations and functions to bring the vehicle 102 out of service, stop motion of the vehicle 102, address vehicle faults, and the like, as described herein.

The computing device 110 may implement and/or be otherwise associated with various other systems onboard the vehicle 102, including various other systems onboard the vehicle 102. The computing device 110 may be configured to communicate with these other on-board systems of the vehicle 102. For example, the computing device 110 may be configured to communicate with one or more data acquisition systems 112, autonomous systems 114 (e.g., including navigation systems), one or more control systems 116, one or more human interface systems 118, other vehicle systems 120, and/or communication systems 122. The computing device 110 may be configured to communicate with these systems via a network 124. The network 124 may include a combination of one or more data buses (e.g., Controller Area Network (CAN)), on-board diagnostic connectors (e.g., OBD-II), and/or wired and/or wireless communication links. The computing devices 110 and/or other on-board systems may send and/or receive data, messages, signals, etc. between each other via the network 124.

The data acquisition system 112 may include various devices configured to acquire data associated with the vehicle 102. This may include data associated with one or more of a system of the vehicle (e.g., health data), an interior of the vehicle, an exterior of the vehicle, a surrounding environment of the vehicle, a vehicle user, and the like. The data acquisition system 112 may include, for example, one or more image capture devices 126. The image capture device 126 may include one or more cameras, light detection and ranging (or radar) devices (LIDAR systems), two-dimensional image capture devices, three-dimensional image capture devices, still image capture devices, dynamic (e.g., rotating) image capture devices, video capture devices (e.g., video recorders), lane detectors, scanners, optical readers, electric eyes, and/or other suitable types of image capture devices. The image capture device 126 may be positioned in the interior and/or on the exterior of the vehicle 102. The one or more image capture devices 126 may be configured to acquire image data to be used for operation of the vehicle 102 in the autonomous mode. For example, the image capture device 126 may acquire image data to allow the vehicle 102 to implement one or more machine vision techniques (e.g., to detect objects in the surrounding environment).

Additionally or alternatively, the data acquisition system 112 may include one or more sensors 128. The sensors 128 may include shock sensors, motion sensors, pressure sensors, temperature sensors, humidity sensors, RADAR, sonar, radio, mid-range and long-range sensors (e.g., for obtaining information associated with the surroundings of the vehicle), Global Positioning System (GPS) equipment, proximity sensors, and/or any other type of sensor for obtaining data indicative of parameters associated with the vehicle 102 and/or related to the operation of the vehicle 102. The data acquisition system 112 may include one or more sensors 128 dedicated to obtaining data associated with a particular aspect of the vehicle 102, such as the vehicle's fuel tanks, engines, cargo tanks, wipers, etc. The sensors 128 may also or alternatively include sensors associated with one or more mechanical and/or electrical components of the vehicle 102. For example, one or more of the sensors 128 may be configured to detect whether a vehicle door, trunk, gas cap, etc., is in an open or closed position. In some embodiments, the data acquired by the sensors 128 may help detect other vehicles and/or objects, road conditions (e.g., curves, potholes, dips, bumps, grade changes), measure distances between the vehicle 102 and other vehicles and/or objects, and so forth.

The vehicle computing system 108 may also be configured to obtain map data. For example, a computing device of a vehicle (e.g., within the autonomous system 114) may be configured to receive map data from one or more remote computing devices. This may include a computing device operating computing system 104 and/or one or more other remote computing devices 130 (e.g., associated with a geographic mapping service provider). The map data may include two-dimensional and/or three-dimensional geographic map data associated with an area in which the vehicle was, is now, is expected to be, and/or will travel.

The data acquired from the data acquisition system 112, map data, and/or other data may be stored in one or more memory devices on the vehicle 102. On-board memory devices may have limited storage capacity. As such, data stored in a memory device may need to be periodically removed, deleted, and/or downloaded to another memory device (e.g., a service provider's database). The computing device 110 may be configured to monitor the memory devices and/or otherwise communicate with the associated processor to determine how many data storage devices are available in the one or more memory devices. Additionally or alternatively, one or more of the other on-board systems (e.g., autonomous system 114) may be configured to access data stored in one or more memory devices.

The autonomous system 114 may be configured to allow the vehicle 102 to operate in an autonomous mode. For example, the autonomous system 114 may obtain data associated with the vehicle 102 (e.g., obtained by the data acquisition system 112). The autonomous system 114 may also obtain map data. The autonomous system 114 can control various functions of the vehicle 102 to implement the autonomous mode based at least in part on the acquired data associated with the vehicle 102 and/or map data. For example, the autonomous system 114 may include various models to perceive road features, signs and/or objects, people, animals, etc., based on the data acquired by the data acquisition system 112, map data, and/or other data. In some implementations, the autonomous system 114 may include a machine learning model that uses data acquired by the data acquisition system 112, map data, and/or other data to help operate the autonomous driving vehicle. Further, the acquired data may help detect other vehicles and/or objects, road conditions (e.g., curves, potholes, depressions, bumps, grade changes, or the like), measure distances between the vehicle 102 and other vehicles or objects, and the like. The autonomous system 114 may be configured to predict the location and/or movement (or lack thereof) of such elements (e.g., using one or more odometry techniques). The autonomous system 114 may be configured to plan the motion of the vehicle 102 based at least in part on such predictions. The autonomous system 114 may implement the planned movement to properly navigate the vehicle 102 with minimal or no human intervention. For example, the autonomous system 114 may include a navigation system configured to guide the vehicle 102 to a destination location. The autonomous system 114 may adjust the operation of the vehicle speed, acceleration, deceleration, heading, and/or other components to operate in an autonomous mode to travel to this destination location.

The autonomous system 114 may determine the location and/or route of the vehicle 102 in real-time and/or near real-time. For example, using the acquired data, the autonomous system 114 may calculate one or more different potential routes (e.g., every second). The autonomous system 114 can then select which route to take and cause the vehicle 102 to navigate accordingly. As an example, the autonomous system 114 may calculate one or more different straight-line paths (e.g., including some of the different portions of the current lane), one or more lane change paths, one or more turn paths, and/or one or more stop paths. The vehicle 102 can select a route based at least in part on the acquired data, current traffic factors, travel conditions associated with the vehicle 102, and the like. In some implementations, different weights may be applied to different criteria when selecting a path. Once selected, the autonomous system 114 can cause the vehicle 102 to travel according to the selected path.

One or more control systems 116 of the vehicle 102 may be configured to control one or more aspects of the vehicle 102. For example, the control system 116 may control one or more access points of the vehicle 102. The access point may include features such as vehicle door locks, trunk locks, hood locks, tank access, latches, and/or other mechanical access features that may be adjusted between one or more states, positions, etc. For example, the control system 116 may be configured to control an access point (e.g., a door lock) to adjust the access point between a first state (e.g., a locked position) and a second state (e.g., an unlocked position). Additionally or alternatively, the control system 116 may be configured to control one or more other electrical characteristics of the vehicle 102 that may be adjusted between one or more states. For example, the control system 116 may be configured to control one or more electrical features (e.g., hazard lights, microphones) to adjust the features between a first state (e.g., off) and a second state (e.g., on). The control system 116 can also control the motion (e.g., heading, speed, braking, acceleration) of the vehicle 102. The control system 116 may receive signals from the autonomous system 114 indicative of the appropriate/planned movement of the vehicle 102.

The human interface system 118 can be configured to allow interaction between a user (e.g., a human), the vehicle 102 (e.g., the vehicle computing system 108), and/or a third party (e.g., an operator associated with a service provider). The human interface system 118 may include a variety of interfaces for a user to input information and/or receive information from the vehicle computing system 108. For example, the human interface system 118 may include a graphical user interface, a direct manipulation interface, a web-based user interface, a touch user interface, a careful user interface, a conversational and/or voice interface (e.g., via text message, chat robot), a conversational interface agent, an Interactive Voice Response (IVR) system, a gesture interface, and/or other types of interfaces. The human interface system 118 may include one or more input devices (e.g., touch screen, keypad, touch pad, knobs, buttons, sliders, switches, mouse, gyroscope, microphone, other hardware interfaces) configured to receive user input. The human machine interface 118 may also include one or more output devices (e.g., display devices, speakers, lights) that receive and output data associated with the interface.

The other vehicle systems 120 may be configured to control and/or monitor other aspects of the vehicle 102. For example, the other vehicle systems 120 may include software update monitors, engine control units, transmission control units, on-board memory devices, and the like. The computing device 110 may be configured to communicate with other vehicle systems 120 to receive data and/or send one or more signals. As an example, the software update monitor may provide data to the computing device 110 indicating the current state of software running on one or more of the on-board systems and/or whether the respective system requires a software update.

The communication system 122 may be configured to allow the vehicle computing system 108 (and its computing device 110) to communicate with other computing devices. In some implementations, the vehicle computing system 108 can communicate with one or more user devices via a network using the communication system 122. In some embodiments, the communication system 122 may allow the computing device 110 to communicate with one or more of the systems onboard the vehicle 102. The vehicle computing system 108 may communicate with the operating computing system 104 and/or one or more other remote computing devices 130 over a network (e.g., via one or more wireless signal connections) using the communication system 122. The communication system 122 can include any suitable components for interfacing with one or more networks, including, for example, a transmitter, receiver, port, controller, antenna, or other suitable component that can facilitate communication with one or more remote computing devices remote from the vehicle 102.

A computing device 110 onboard the vehicle 102 may obtain data 132 indicative of one or more parameters associated with the vehicle 102. The parameters may include information associated with the vehicle 102, the vehicle computing system 108, one or more of the onboard systems, etc., such as health and maintenance information. For example, the one or more parameters may include fuel level, engine condition, tire pressure, conditions associated with the interior of the vehicle, conditions associated with the exterior of the vehicle, mileage, time to next service, time since last service, available data storage in an on-board memory device, charge of an energy storage device in the vehicle 102, current software state, required software updates, and/or other health and service data of the vehicle 102.

At least a portion of the data 132 indicative of the parameter may be provided via one or more of the systems onboard the vehicle 102. Computing device 110 may be configured to request data 132 from the on-board system as planned and/or as needed. In some implementations, one or more of the on-board systems may be configured to provide data 132 indicative of one or more parameters to the computing device 110 (e.g., periodically, continuously, on-demand). As an example, the data acquisition system 112 may provide a parameter indicative of a fuel level of the vehicle and/or a charge in a vehicle energy storage device. In some implementations, one or more of the parameters may be indicative of user input. For example, the human machine interface 118 can receive user input 150 (e.g., via a user interface displayed on a display device in the interior of the vehicle). The human machine interface 118 may provide data indicative of the user input 150 to the computing device 110. In some implementations, a user device 137 associated with the user 136 can receive the user input 150 and can provide data indicative of the user input 150 to the computing device 110. Computing device 110 may obtain data indicative of user input 150 from user device 137 (e.g., via wireless communication).

The computing device 110 may be configured to determine that there is a fault 134 associated with the vehicle 102 based at least in part on one or more parameters associated with the vehicle 102. The fault 134 can be a condition associated with the vehicle 102 (and its users) that is or is potentially unsafe, problematic, abnormal, disruptive, etc., to the vehicle 102 and/or one or more users 136 (e.g., current, assigned, potential users) of the vehicle 102. In some implementations, the fault 134 can be associated with the vehicle 102 because it is a fault of a component of the vehicle 102 (and/or a user 136 of the vehicle) that is not based on objects, animals, humans, etc. detected in the surrounding environment of the vehicle. In some implementations, the fault 134 may be a condition that needs to be addressed to prevent and/or mitigate injury to the vehicle 102 and/or its user 136.

The computing device 110 may be configured to determine one or more characteristics 138 of the fault 134. For example, the vehicle 102 may determine the type of fault (e.g., fuel will run out), the location of the fault (e.g., fuel tank), the time at which the fault occurred and/or the determination of the fault, its potential impact on the vehicle 102 and/or the user 136, and/or other characteristics associated with the fault 134.

In some implementations, the computing device 110 may be configured to determine that there is a fault 134 associated with the vehicle 102 based at least in part on a comparison of one or more parameters associated with the vehicle 102 to one or more thresholds. For example, fig. 2 illustrates a graphical representation 200 of vehicle parameters 202A-C and thresholds 204A-C, according to an example embodiment of the disclosure. FIG. 2 shows certain parameters and thresholds for purposes of example and discussion and they are not meant to be limiting. It should be understood by one of ordinary skill in the art that the parameters and thresholds shown and discussed herein may include fewer, additional, different, and/or modified parameters and/or thresholds than shown and discussed.

As shown, the parameters 202A-C may reflect a variety of information associated with the vehicle 102. For example, the parameters 202A-C may include at least one parameter 202A indicative of a fuel level of the vehicle 102, at least one parameter 202B indicative of a charge of an energy storage device on the vehicle 102, and/or at least one parameter 202C indicative of an amount of available data storage devices in one or more memory devices on board the vehicle 102. The parameters 202A-C may indicate the current levels of those respective features of the vehicle 102.

The thresholds 204A-C may indicate particular threshold levels for the parameters 202A-C. For example, the thresholds 202A-C may include a fuel level threshold 204A, a charge amount threshold 204B, and a threshold 204C indicative of a threshold amount of available data storage. The thresholds 204A-C may be set by the operating computing system 104, the vehicle 102, and/or individual persons/entities associated with the vehicle 102 and/or the service provider. In some implementations, one or more of the thresholds 204A-C may be static thresholds (e.g., constant thresholds that do not change). In some implementations, one or more of the thresholds may be dynamic thresholds (e.g., may change) and/or may be determined in real-time and/or near real-time. For example, the computing device 110 may be configured to determine (e.g., in real-time and/or near real-time) one or more thresholds 204A-C such that the vehicle 102 may always travel to and arrive at a service location (e.g., to resolve a fault).

FIG. 3 illustrates a graphical representation 300 of a plurality of service locations 302A-C according to an example embodiment of the invention. Computing device 110 on vehicle 102 may obtain data indicative of a plurality of service locations 302A-C. The data may be obtained via one or more remote computing devices (e.g., 104, 130) remote from the vehicle 102. The data may indicate one or more characteristics 304 of each of the repair locations 302A-C of the plurality of repair locations 302A-C. For example, the data indicative of repair locations 302A-C may indicate at least geographic locations 306A-C of respective repair locations 302A-C. Additionally or alternatively, the characteristics 304 of the service locations may include their names, types of services provided, other characteristics, hours of business, availability to provide services to the vehicle 102 (e.g., outstanding orders, current reservations), and/or other characteristics associated with the respective service locations 302A-C. In some implementations, the computing device 110 on the vehicle 102 may be configured to identify one or more repair locations 302A-C from the plurality of repair locations 302A-C based at least in part on the one or more characteristics 304 of the repair locations 302A-C. As an example, the computing device 110 may identify repair locations 302A-C that are currently open and/or have repair availability proximate to the current location 308 of the vehicle 102.

The computing device 110 may be configured to determine travel routes 310A-C to the service locations 302A-C. In some implementations, computing device 110 may determine a respective travel route to each of respective repair locations 302A-C. In some implementations, computing device 110 may determine one or more routes of travel to one or more of service locations 302A-C. Travel routes 310A-C may be routes from the current location 308 (and/or future location) of the vehicle 102 to the geographic locations 306A-C of the respective service locations 302A-C. The vehicle 102 may be configured to travel (e.g., autonomously navigate) along travel routes 310A-C to reach the service locations 302A-C. Further, the computing device 110 may be configured to determine one or more travel factors 312 (e.g., current traffic, historical traffic patterns, weather, construction, other conditions) associated with the respective travel routes 310A-C.

The computing device 110 may be configured to determine (e.g., in real-time) the thresholds 204A-C based at least in part on the travel routes 310A-C and the one or more travel factors 312. For example, the computing device 110 may determine how much fuel, charge, and/or data is needed to reach the service location 302C. Such a service location 302C may be the service location and/or the most appropriate location closest to the current location 308 of the vehicle 102 based at least in part on one or more of the characteristics 304 of the service location 302C (e.g., an open and available service location). Computing device 110 may determine (e.g., in real-time and/or near real-time) one or more of thresholds 204A-C such that the thresholds indicate one or more requisite levels of one or more of parameters 202A-C needed for vehicle 102 to travel to and reach service location 302C.

The computing device 110 may be configured to determine that a fault 134 exists using the dynamic real-time threshold. For example, the vehicle 102 may include one or more image capture devices 126 configured to acquire image data (e.g., associated with the surroundings of the vehicle) to be used for operation of the vehicle 102 in the autonomous mode. Such image data may be used by the autonomous system 114 to navigate the vehicle 102 according to signs, lane markings, and the like. When the image capture device 126 acquires image data, the image data may be stored in one or more memory devices onboard the vehicle 102. The computing device 110 may obtain data indicative of the parameter 202C associated with the memory device. For example, the parameter 202C may indicate an amount of available data storage in one or more of the memory devices onboard the vehicle 102. Thus, the computing device 110 may determine the threshold 204C indicative of the threshold amount of available data storage in real-time and/or near real-time based at least in part on the travel route 310C to the service location 302C and/or travel factors 312 (e.g., traffic) associated with the travel route 310C. The threshold amount of available data storage may be based at least in part on the amount of data storage needed for the vehicle 102 to travel to and reach the geographic location 306C of the service location 302C (e.g., via the travel route 310C, given the travel factor 312). In the event that the amount of available data storage in the on-board memory device approaches and/or falls below threshold 204C, computing system 110 may determine that there is a fault associated with storing the image data (e.g., lower data storage availability). In this way, the computing device 110 may ensure that the vehicle 102 may travel to at least the service location 302C in the event of a failure.

In some embodiments, the thresholds 204A-C may change based at least in part on the location of the vehicle 102. For example, as the location of the vehicle 102 changes, the service location closest to the vehicle 102 may also change. As such, the computing device 110 may adjust the thresholds 204A-C as the position of the vehicle changes to ensure that the vehicle 102 may travel at least to the nearest (and/or most appropriate) service location in the event of a failure.

Returning to fig. 1, in some implementations, the computing device 110 may be configured to determine a severity 140 of the fault 134 based at least in part on one or more characteristics 138 of the fault 134 (e.g., with respect to the type of vehicle, potential risk, location). For example, given a fault type and potential risk to the vehicle 102 and/or a user 136 of the vehicle 102, the computing device 110 may determine that the severity 140 of the fault (e.g., window jam) is low. In another example, given a fault type (e.g., smoke, fire), its associated location (e.g., interior of a vehicle), and/or other characteristics, the computing device 110 may determine that the severity 140 of the fault (e.g., fire in the interior of the vehicle) is high. In this way, given the severity of the fault, the vehicle computing system 108 may improve its ability to take appropriate measures to address the fault.

The computing device 110 may be configured to determine an operating state 142 of the vehicle 102 based at least in part on the severity of the fault 140. The operating state 142 may indicate whether the vehicle 102 is eligible to provide vehicle services to one or more users 136. For example, the operational status 142 may indicate that the vehicle 102 is eligible to provide vehicle services (e.g., for minor faults, window jams) to one or more users 136 of the vehicle 102. In some embodiments, the operational status 142 can indicate that the vehicle 102 can provide vehicle services to the current user 136 of the vehicle 102 (e.g., transporting the occupant to a destination location). In some embodiments, the operating state 142 can indicate that the vehicle 102 can selectively provide vehicle services to a user of the vehicle 102. For example, the vehicle 102 may provide shipping services to users traveling in the direction of the service location and/or may deny providing shipping services to users traveling away from the service location. In some implementations, the operational status 142 can indicate that the vehicle 102 is not suitable for providing vehicle services to one or more users 136 (e.g., for more serious faults).

The computing device 110 may be configured to determine one or more actions to be performed by the vehicle 102 based at least in part on the presence of the fault 134. For example, the computing device 110 may perform one or more of the actions to bring the vehicle 102 out of service based at least in part on the fault 134. When out of service, the vehicle 102 is unavailable to provide one or more vehicle services (e.g., of a service provider).

For example, one or more of the actions may include adjusting a state 105 associated with the vehicle 102. The computing device 110 may adjust the state 105 associated with the vehicle 102 based at least in part on the fault 134 to indicate that the vehicle 102 is unavailable to provide vehicle services. To do so, the computing device 110 may adjust the indication, record, and/or other data associated with the state 105 to indicate that the vehicle 102 is not available to provide vehicle services. The computing device 110 can provide data 143 to one or more remote computing devices (e.g., 104, 130) remote from the vehicle 102 indicating that the vehicle 102 is not available to provide vehicle services (e.g., transportation, courier, delivery) and/or indicating that the vehicle 102 will be removed from the service queue 106 associated with the vehicle services. In some implementations, the data 143 may indicate one or more characteristics of the fault 134.

The operating computing system 104 can remove the vehicle 102 from the service queue 106 (and/or the library of available vehicles) associated with the vehicle service. Additionally or alternatively, the operating computing system 104 can adjust the indication, record, and/or other data associated with the state 105 to indicate that the vehicle 102 is not available to provide vehicle services. A computing device associated with a service provider (e.g., that operates the computing system 104) may not provide one or more requests for vehicle services (e.g., a delivery user) to the vehicle 102 when the vehicle 102 stops service and/or when a state 105 associated with the vehicle 102 indicates that the vehicle 102 is unavailable to provide vehicle services. Additionally or alternatively, the vehicle 102 can not accept and/or receive a request for vehicle services when the vehicle 102 is out of service and/or the state 105 associated with the vehicle 102 indicates that the vehicle 102 is unavailable to provide vehicle services. Thus, the vehicle 102 will not be assigned to (and/or will not accept assignment to) users requesting vehicle services from the service provider. Thus, the vehicle 102 may bring itself out of service in response to determining that the fault 134 exists.

The actions may also or alternatively include a variety of other tasks that the vehicle 102 may perform based at least in part on the fault 134. For example, the action may include sending data to the operating computing system 104, traveling to and arriving at the repair location 302C (e.g., via the travel route 310C), contacting the repair location 302C (e.g., to notify of an estimated arrival time, enter a repair queue) to activate a reserved data storage device, power resources, and so forth. In some implementations, the computing device 110 may provide one or more control command signals 144 to one or more of the systems onboard the vehicle 102 to perform one or more of the actions.

In some implementations, the computing device 110 can determine the one or more actions based at least in part on the operating state 142 of the vehicle 102. For example, the operational status 142 may indicate that the vehicle 102 is not suitable for providing vehicle services due to the fault 134. Thus, the vehicle computing system 102 can deny any service requests and continue to resolve the fault 134. In some implementations, to address the fault, the computing device 110 may provide one or more control command signals 144 to one or more of the systems (e.g., navigation systems) on the vehicle 102 to cause the vehicle 102 to travel to and reach the service location 302C.

In another example, the operational status 142 can indicate that the vehicle 102 is eligible to provide vehicle services to one or more current users 136 of the vehicle 102 (e.g., due to minor malfunction, window jam). One or more of the systems on the vehicle 102 (e.g., the autonomous system 114) may perform one or more of the actions (e.g., navigation actions) to cause the vehicle 102 to complete vehicle services provided to the one or more current users 136 (e.g., to send users of a ride-sharing service to a destination location) before traveling to the service location 302C (e.g., to repair a stuck window). The vehicle 102 may complete vehicle service before or after bringing the vehicle 102 out of service. For example, the computing device 110 may adjust the state 105 associated with the vehicle 102 before or after sending the user to the destination location to indicate that the autonomous driving vehicle is not available to provide vehicle services.

In yet another example, the operating state 142 may indicate that the vehicle 102 may selectively provide vehicle services to the user 136 such that the vehicle 102 still travels to the service location 302C while providing vehicle services. One or more of the on-board systems may perform actions such that the vehicle 102 only accepts service requests that may cause the vehicle 102 to travel at least substantially in the direction of the service location 302C and/or rejects service requests that may cause the vehicle 102 to travel away from the service location 302C. In this manner, the vehicle 102 may still proceed to resolve the fault 134 without having to use its resources.

The vehicle 102 may travel to and arrive at the service location 302C to resolve the fault. In some implementations, the computing device 110 can cause the vehicle 102 to enter a service mode. The service mode may allow a service worker (e.g., a computer technician, a vehicle repairman) to provide service to the vehicle 102 to address the fault.

In some implementations, at least one of the actions can include stopping the motion of the vehicle 102. The one or more actions may include, for example, applying brakes of the vehicle 102, changing the vehicle position (e.g., parking the vehicle at the shoulder of a road, in the middle of a road), activating a hazard warning light, inflating an airbag, unlocking the doors once the vehicle is locked, etc. In some implementations, the computing device 110 may determine one or more actions based at least in part on the severity 140 associated with the fault 134, as described herein. The computing device 110 may provide one or more control command signals 148 to one or more of the systems onboard the vehicle 102 to perform one or more of the actions to facilitate stopping the motion of the vehicle 102 in response to the presence of the fault 134.

As an example, the computing device 110 may communicate with one or more of the human interface systems 118 to obtain data 132 indicative of one or more parameters. The parameters may include data indicative of user input 150 associated with the fault 134. For example, the user 136 of the vehicle 102 can provide user input via one or more interfaces (e.g., user interface, physical interface) of the human interface system 118 and/or via a user device 137 associated with the user 136. The user input 150 may indicate the presence of a fire in the interior of the vehicle, smoke emitted from the engine of the vehicle, etc. Additionally or alternatively, the user input 150 may indicate a user-initiated request to stop the vehicle 102 (e.g., due to a user panic attack).

The computing device 110 may determine that a fire, smoke, user problem, etc., is present based at least in part on the user input 150. The computing device 110 may determine one or more actions to be performed by the vehicle 102 based at least in part on the fault 134. For example, the computing device 110 may determine that the vehicle 102 should decelerate to a stop position so that smoke, fire, user's problems, etc. can be properly addressed.

Fig. 4 illustrates a representation 400 of the vehicle 102 in a driving lane 402, according to an example embodiment of the invention. The vehicle 102 may travel (e.g., in an autonomous mode) according to the motion 404 (e.g., a velocity vector). The motion 404 of the vehicle 102 may be controlled by systems onboard the vehicle 102 (e.g., autonomous system 114, control system 116). The vehicle 102 may travel according to the motion 404 while providing vehicle services (e.g., transportation services) to one or more users 136.

One or more of the onboard systems of the vehicle 102 may be configured to determine a stopping location of the vehicle 102 based at least in part on a fault associated with the vehicle 102 (e.g., its characteristics 138) and one or more travel conditions 405. The travel condition 405 may include a vehicle heading, speed, location, geographic location, road/lane structure, surrounding environment (e.g., buildings, objects, people), and so forth. For example, as indicated above, the autonomous system 114 may continuously calculate different paths of the vehicle 102 (e.g., based on differently weighted criteria). Upon detecting the presence of the fault 134, the autonomous system 114 may change the weights such that the autonomous system 114 may take a path based at least in part on the presence of the fault 134.

For example, as shown in fig. 4, the stop position of the vehicle 102 may be located in a driving lane 402 (e.g., a current driving lane) of the vehicle 102. The system (e.g., autonomous system, brake control system) may cause the vehicle 102 to reach a stop location 406 in the driving lane when the severity 140 of the fault 134 is high. In some implementations, as shown in the representation 500 of fig. 5, the stop position 502 of the vehicle 102 may be outside of the driving lane 402 (e.g., the current driving lane) of the vehicle 102. For example, the vehicle 102 may be in a stop position 502 on the shoulder of a roadway, a central isolation zone, etc., when the vehicle 102 has sufficient time to reach such position.

The computing device 110 may provide one or more control command signals 148 to one or more of the systems onboard the vehicle 102 to facilitate stopping the motion 404 of the vehicle 102 in response to the presence of the fault 104. In some embodiments, to facilitate stopping 404 the motion of the vehicle 102, one or more systems onboard the vehicle 102 (e.g., autonomous systems, braking systems) may cause at least a change in direction of the vehicle 102 such that the vehicle 102 may reach a selected stopping location (e.g., 406, 502). One or more systems on the vehicle 102 may also cause the vehicle 102 to decelerate at least until the vehicle 102 is in a stopped position (e.g., 406, 502).

Returning to fig. 4, in some embodiments, the rate of deceleration 408 of the vehicle 102 may be based at least in part on the severity 140 associated with the fault 134. For more serious faults (e.g., a fire, a crash in the vehicle), the deceleration rate 408 may be higher. This may occur when the vehicle 102 may not have time to exit the travel lane 402. For less severe faults (e.g., engine smoke) where the vehicle 102 may have time to exit the driving lane 402, the deceleration rate 408 may be lower. Thus, the vehicle computing system 108 may be improved to locally determine and select the stopping location of the vehicle 102 and the manner in which the vehicle 102 reaches the stopping location. Thus, the vehicle computing system 108 may locally adjust its actions according to the environment of the fault. As indicated above, this may improve user security while reducing potential latency issues. In some embodiments, one or more systems onboard the vehicle 102 may determine the deceleration time delay 409. The deceleration time delay 409 may indicate a time period that delays the vehicle 102 from beginning to decelerate and/or a time period before the vehicle 102 reaches a stop position. For example, the vehicle 102 may travel through an intersection. One or more systems onboard the vehicle 102 may determine that the vehicle 102 should delay the deceleration of the vehicle 102 until after the vehicle 102 has left the intersection (e.g., so that the vehicle 102 does not reach a stop position in the intersection).

Returning to fig. 1, in some implementations, the at least one action may include communicating with one or more remote computing devices to help resolve the fault 134. For example, the computing device 110 may send data 152 indicative of a request for confirmation of the presence of the fault 134 to one or more remote computing devices remote from the vehicle 102 (e.g., to the operating computing system 104). For example, where the user reports the fault 134 (e.g., via the user input 150), the computing device 110 may request that a human operator of the service provider confirm that the fault 134 exists (e.g., by reviewing images of the interior of the vehicle). In the event that the fault 134 is not confirmed or is not authentic, the service provider may penalize the user (e.g., a user who is repeatedly dishonest) for error reporting. This may include monetary penalties, lowering user ratings, and/or other types of penalties applied to the user's account, profile, etc.

Additionally or alternatively, the computing device 110 may provide data 153 indicating repairs to the vehicle 102. The data 153 can be provided to one or more remote computing devices remote from the vehicle 102. For example, the computing device 110 may provide the data 153 to the operating computing system 104, requesting the service provider to deploy a repair crew to the vehicle 102 (e.g., to make roadside repairs). The computing device 110 may also or alternatively request deployment of an emergency agency (e.g., an ambulance) to the vehicle 102.

In some implementations, one or more of the actions may include requesting a different vehicle to provide vehicle services to one or more users 136. For example, in the event that the vehicle 102 is not in a position to provide vehicle services to the current user 136, the computing device 110 may request that a different vehicle 170 be assigned to the user 136. The computing device 110 can provide data 154 indicative of requests for different vehicles 170 to the operating computing system 104 to provide vehicle services to one or more users 136. Thus, the operating computing system 104 may assign different vehicles 170 to the user 136. Then, the different vehicle 170 travels to the user 136 to provide vehicle services accordingly.

As indicated above, to placate the current user 136 of the vehicle 102, the computing device 110 may coordinate one or more communications with the user. In some implementations, the computing device 110 can provide data 156 indicative of a request by a human operator (e.g., associated with a service provider, a critical service) to communicate with the current user 136 of the vehicle 102. The human operator may communicate with the current user 136 via at least one of a display device and an audio output device (e.g., a speaker) associated with the vehicle 102. In this way, the computing device 110 may provide assistance to a user who may be in need, surprised, confused, depressed, etc.

In some implementations, the one or more actions may include notifying one or more users of the fault 134. The computing device 110 may provide the user 136 with contextual information associated with the fault 134 and/or a reason for the vehicle 102 to take certain actions (e.g., stop, travel to a service location). For example, fig. 6 illustrates an example user interface 600 displayed via one or more display devices 602, according to an example embodiment of this disclosure. The display device 602 may be associated with a user device 137 associated with the user 136 (e.g., a mobile phone) and/or with the human interface system 118 (e.g., a tablet computer in a vehicle). User interface 600 may be configured to receive various data from user 136 and/or present various data to user 136. For example, the computing device 110 may provide, via a display of the one or more display devices 602, the data 604 indicating that the fault 134 exists and/or the one or more characteristics 138 of the fault 134.

In some implementations, the user interface 600 may include user interface elements 606 that are displayed via the display device 602. The user 136 can interact with the element 606 to provide a user-initiated request to stop the vehicle 102 (e.g., due to a health issue of the user). The computing device 110 may obtain a parameter indicative of this user input. The computing device 110 may provide for display data 608 indicative of the request to stop the vehicle 102 (e.g., via the one or more display devices 602).

Fig. 7 depicts a flow diagram of an example method 700 of out-of-service a vehicle, according to an example embodiment of the invention. One or more portions of method 700 may be implemented by one or more computing devices, such as, for example, computing device 110 shown in fig. 1 and 10. Further, one or more portions of method 700 may be implemented as an algorithm on a hardware component of a device described herein (e.g., as in fig. 1 and 10), for example, to bring a vehicle out of service. Fig. 7 depicts elements performed in a particular order for purposes of illustration and discussion. Using the disclosure provided herein, it will be understood by one of ordinary skill in the art that elements of any of the methods discussed herein (e.g., of fig. 7-9) may be adapted, rearranged, expanded, omitted, combined, and/or modified in various ways without departing from the scope of the invention.

At (702), the method 700 may include obtaining data indicative of one or more parameters. For example, one or more computing devices 110 onboard the vehicle 102 may obtain data 132 indicative of one or more parameters (e.g., 202A-C) associated with the vehicle 102. The parameters 202A-C may reflect various information associated with the vehicle 102, as described herein. For example, the parameters 202A-C may include at least one parameter 202A indicative of a fuel level of the vehicle 102, at least one parameter 202B indicative of a charge level of an energy storage device onboard the vehicle 102, and/or at least one parameter 202C indicative of an available data storage device quantity (e.g., in one or more onboard memory devices) onboard the vehicle 102.

As described herein, the vehicle 102 associated with the data indicative of the one or more parameters obtained at (702) may be an autonomous driving vehicle configured to provide vehicle services (e.g., transportation, courier, delivery, or the like of a service provider) to one or more users 136 of the vehicle services. For example, the vehicle 102 may be included in a plurality of vehicles 103 associated with a service provider (e.g., in a fleet). The vehicle 102 can be associated with a state 105 that indicates whether the vehicle 102 is available or unavailable to provide vehicle services. For example, the status 105 can indicate whether the vehicle 102 is available to accept service requests and/or whether it is desired to accept service requests. In some embodiments, the vehicle 102 can be paired with one or more users 136 via a service queue 106 associated with a service provider of the vehicle service, as described above. The service queue 106 can identify at least a subset of the plurality of vehicles 103 that are available to provide vehicle services.

At (704), method 700 may include determining that a fault exists. For example, the computing device 110 may determine that the fault 134 associated with the vehicle 102 exists based at least in part on one or more parameters 202A-C associated with the vehicle 102. For example, the computing device 110 can compare at least one of the parameters associated with the vehicle 102 (e.g., 202C) to a threshold (e.g., 204C).

Fig. 8 depicts a flow diagram of an example method 800 of determining a threshold value, according to an example embodiment of the invention. One or more portions of method 800 may be implemented by one or more computing devices, such as, for example, computing device 110 and/or system 104 shown in fig. 1 and 10. Further, one or more portions of method 800 may be implemented as an algorithm on a hardware component of a device described herein (e.g., as in fig. 1 and 10) to determine a threshold, for example. Fig. 8 depicts elements performed in a particular order for purposes of illustration and discussion. Using the disclosure provided herein, it will be understood by one of ordinary skill in the art that elements of any of the methods discussed herein may be adapted, rearranged, expanded, omitted, combined, and/or modified in various ways without departing from the scope of the invention.

At (802), method 800 may include obtaining data indicative of one or more repair locations. For example, computing device 110 may obtain data indicative of one or more service locations 302A-C. The data indicative of repair locations 302A-C may indicate at least a geographic location (e.g., 306A-C) of each of the respective repair locations 302A-C. The data obtained at (802) may indicate one or more characteristics 304 for each of service locations 302A-C.

At (804), the method 800 may include selecting a service location. For example, computing device 110 may select at least one of the repair locations (e.g., 302C) based at least in part on one or more characteristics 304 of repair location 302C (and/or other repair locations) and/or geographic location 306C. As described herein, this may include the nearest service location from the vehicle, an open service location, and the like. At (806), the computing device 110 may determine the travel route 310C to the (selected) repair location 302C based at least in part on the geographic location 306C of the repair location 302C and/or the location (e.g., current, future, destination) of the vehicle 102. Further, at (808), the computing device 110 may obtain data for one or more travel factors 312 associated with the travel route 310C. As described herein, the travel factors 312 may include current traffic, historical traffic patterns, predicted traffic, weather, construction, and/or other conditions associated with the respective travel route 310C.

At (810), the method 800 may include determining one or more thresholds. For example, the computing device 110 may determine the thresholds 204A-C in real-time and/or near real-time based at least in part on the route of travel 310C and the one or more travel factors 312. The thresholds 204A-C may indicate a requisite degree of at least one parameter 202A-C required for the vehicle 102 to traverse the travel route 310C and reach the geographic location 306C of the service location 302C. For example, threshold 204C may indicate an amount of data storage needed for vehicle 102 to travel to and reach geographic location 306C of service location 302C (e.g., via travel route 310C, given travel factors 312).

Returning to fig. 7, at (706), method 700 may include determining one or more actions to be performed by the vehicle. The computing device 110 may determine one or more actions to be performed by the vehicle 102 based at least in part on the presence of the fault 134 determined at (704).

In some embodiments, the action may be determined at (706) based at least in part on the operating state 142 of the vehicle 102. For example, the computing device 110 may determine the severity 140 of the fault 134 based at least in part on one or more characteristics of the fault 134. The computing device 110 may determine an operating state 142 of the vehicle 102 based at least in part on the severity 140 of the fault 134. The operating state 142 can indicate whether the vehicle 102 is eligible to provide vehicle services to the user 136. The computing device 110 may determine the one or more actions based at least in part on the operating state 142 of the vehicle 102. For example, the operating status 142 can indicate that the vehicle 102 is eligible to provide vehicle services to one or more users (e.g., current occupants) of the vehicle 102. As such, the action may indicate that the vehicle 102 will complete vehicle services currently provided to one or more current users before, for example, taking the vehicle out of service.

In some embodiments, the operational status 142 can indicate that the vehicle 102 is not suitable for providing vehicle services. As such, the action determined at (706) may indicate that the vehicle 102 is to stop providing vehicle services to one or more current users. To do so, the vehicle 102 may decelerate to a stop position, as described herein.

At least one of the actions determined at (706) may include the vehicle 102 traveling to and arriving at the service location 302C. Thus, in some implementations, at (710), the computing device 110 may provide the one or more control command signals 144 to one or more systems onboard the vehicle 102 (e.g., autonomous system 114) to cause the vehicle 102 to travel to and reach the service location 302C. The system on the vehicle 102 may navigate the vehicle 102 (e.g., in a fully autonomous mode) to the service location 302C so that the fault 134 may be resolved.

At (708), the computing device 110 may perform one or more of the acts to bring the vehicle 102 out of service, such that the vehicle 102 is unavailable to provide vehicle services (e.g., of a service provider). In some implementations, at least one of the actions can include adjusting a state 105 associated with the vehicle 102. The computing device 110 may adjust a state 150 associated with the vehicle 102 based at least in part on the presence of the fault 134 to indicate that the vehicle 102 is unavailable to provide vehicle services. In some implementations, the computing device 110 can perform one or more of the actions to take the vehicle 102 out of service based at least in part on the fault by removing the vehicle 102 from the service queue 106 associated with the vehicle 102 and/or otherwise making the vehicle 102 unavailable to provide vehicle service. For example, the computing device 110 can provide data indicating that the vehicle 102 is unavailable to provide vehicle services to one or more remote computing devices (e.g., operating the computing system 104) remote from the vehicle 102. The vehicle 102 can be removed from the service queue 106 associated with the vehicle service and/or otherwise marked as unavailable. As described herein, the vehicle 102 can not accept requests for vehicle services when the vehicle 102 stops service and/or the state 105 associated with the vehicle 102 indicates that the vehicle 102 is unavailable to provide vehicle services. Thus, the vehicle computing system 108 may self-diagnose the vehicle fault and take action to resolve the fault without intervention.

Fig. 9 depicts a flow diagram of an example method 900 of stopping motion of a vehicle, according to an example embodiment of the invention. One or more portions of method 900 may be implemented by one or more computing devices, such as, for example, computing device 110 shown in fig. 1 and 10. Further, one or more portions of method 900 may be implemented as an algorithm on a hardware component of a device described herein (e.g., as in fig. 1 and 10). Fig. 9 depicts elements performed in a particular order for purposes of illustration and discussion. Using the disclosure provided herein, it will be understood by one of ordinary skill in the art that elements of any of the methods discussed herein may be adapted, rearranged, expanded, omitted, combined, and/or modified in various ways without departing from the scope of the invention.

At (902), the method 900 may include obtaining data indicative of one or more parameters. As described herein, the computing device 110 may obtain data 132 indicative of one or more parameters (e.g., 202A-C) associated with the vehicle 102. In some implementations, the one or more parameters may include data indicative of user input 150 associated with the fault 134 (e.g., smoke in the vehicle). At (904), the computing device 110 may determine that there is a fault 134 associated with the vehicle 102 based at least in part on the one or more parameters 202A-C associated with the vehicle 102. Further, at (906), the computing device 110 may determine one or more actions to be performed by the vehicle 102 based at least in part on the presence of the fault 134, as described herein.

At least one of the actions determined at (906) may include stopping the motion 404 of the vehicle 102. Accordingly, at (908), the computing device 110 may provide one or more control command signals 148 to one or more of the systems onboard the vehicle 102 to facilitate stopping the motion 404 of the vehicle 102 in response to the presence of the fault 134. For example, to facilitate stopping the motion 404 of the vehicle 102, one or more of the onboard systems (e.g., the autonomous system 114) may determine at least one of a stopping location (e.g., 406, 502), a deceleration rate 408, and a deceleration time delay 409 of the vehicle 102 based at least in part on the fault 134 associated with the vehicle 102 and one or more travel conditions 405 (e.g., heading, speed, location, ambient environment), as described herein. In some embodiments, the stop position may be in the current driving lane 402 of the vehicle 102. In some embodiments, the stop position may be outside the current driving lane 402 of the vehicle 102.

Further, one or more of the on-board systems may cause at least one of the vehicles 102 to decelerate until the vehicle 102 is in a stopped position (e.g., 406, 502). As described herein, the computing device 220 may determine the severity 140 of the fault 134 based at least in part on the one or more characteristics 138 of the fault 134. The computing device 110 may determine one or more of the actions at (906) based at least in part on the severity 140 of the fault 134. For example, the deceleration rate 408 of the vehicle 102 may be based at least in part on the severity 140 associated with the fault 134.

In some implementations, at least one of the actions determined at (906) can include confirming that there is a fault 134. For example, at (910), method 900 may include sending data indicating a request for confirmation of the failure. The computing device 110 may send data 152 indicative of the request for confirmation of the presence of the fault 134 to one or more remote computing devices remote from the vehicle 102 (e.g., to the operating computing system 104). As an example, where the user 136 reports the fault 134 (e.g., via the user input 150), the computing device 110 may request a human operator of the service provider to confirm that the fault 134 exists (e.g., by reviewing images of the interior of the vehicle).

In some implementations, at least one of the actions determined at (906) can include taking the vehicle 102 out of service. For example, at (912), the computing device 110 may adjust the status 105 associated with the vehicle 102 to indicate that the vehicle 102 is unavailable to provide vehicle services. In this manner, the vehicle 102 may be prevented from being assigned to any other service request before the fault 134 is resolved.

In some implementations, one or more of the actions determined at (906) may include notifying one or more of the users 136 of the fault 134. For example, at (914), method 900 may include notifying one or more users of the presence of fault 134. The computing device 110 may provide, via a display of the one or more display devices 602, data 604 indicative of the presence of the fault 134 and/or the one or more characteristics 138 of the fault 134 (e.g., as shown, for example, in fig. 6). In this manner, the vehicle 102 can provide the user with contextual information regarding the fault 134.

In some implementations, one or more of the actions determined at (906) may include facilitating communication with user 136. For example, at (916), method 900 may include sending data indicative of a request for a human operator to communicate with a current user. The computing device may provide data 156 indicating that a human operator (e.g., associated with a service provider, emergency services) is requested to communicate with the current user 136 of the vehicle 102. The human operator may communicate with the current user 136 (e.g., to placate the user) via at least one of a display device and an audio output device (e.g., a speaker) associated with the vehicle 102.

In some implementations, one or more of the actions may include requesting a different vehicle 170 to provide vehicle services to one or more users 136. For example, at (918), the computing device 110 can provide data 153 (e.g., to one or more remote computing devices associated with a service provider) indicative of a request for a different vehicle 170 to provide vehicle services to one or more users 136, as described herein.

In some implementations, one or more of the actions determined at (906) can include requesting maintenance of the vehicle 102. For example, at (920), the computing device 110 may provide the data 152 indicating a request for service to the vehicle 102. The data 152 can be provided to one or more remote computing devices remote from the vehicle 102. For example, the computing device 110 may provide the data 152 to the operating computing system 104, requesting the service provider to deploy a repair crew to the vehicle 102 (e.g., to make roadside repairs). The computing device 110 may also or alternatively request deployment of a critical institution (e.g., an ambulance) to the vehicle 102.

Fig. 10 depicts an example system 1000 according to an example embodiment of the invention. The system 1000 may include an operating computing system 104, a vehicle computing system 108 (e.g., located on the vehicle 102), and one or more user devices 137. The operating computing system 104, the vehicle computing system 108, and the one or more user devices 137 may be configured to communicate via one or more networks, such as the networks described herein.

The vehicle computing system 108 may include one or more computing devices 110. The computing device 110 may include one or more processors 1004 onboard the vehicle 102 and one or more memory devices 1006 onboard the vehicle 102. The one or more processors 1004 may be any suitable processing device, such as a microprocessor, microcontroller, integrated circuit, Application Specific Integrated Circuit (ASIC), Digital Signal Processor (DSP), Field Programmable Gate Array (FPGA), logic device, one or more Central Processing Units (CPUs), Graphics Processing Unit (GPU), processing unit that performs other specialized computations, etc. The processor may be a single processor or multiple processors operatively and/or selectively connected. Memory device 1006 can include one or more non-transitory computer-readable storage media, such as RAM, ROM, EEPROM, EPROM, flash memory devices, a disk, the like, and/or combinations thereof.

The memory device 1006 may store information that is accessible by the one or more processors 1004. For example, the memory device 1006 onboard the vehicle 102 may include computer-readable instructions 1008 that are executable by the one or more processors 1004. The instructions 1008 may be software written in any suitable programming language or may be implemented in hardware. Additionally or alternatively, the instructions 1008 may be executed in logically and/or physically separate threads on the processors 1004. The instructions 1008 may be any set of instructions that, when executed by the one or more processors 1004, cause the one or more processors 1004 to perform operations.

For example, the memory device 1006 on the vehicle 102 may store instructions 1008 that, when executed by the one or more processors 1004 onboard the vehicle, cause the one or more processors 1004 to perform operations such as any of: the operation and function of computing device 110 or for which computing device 110 is configured (as described herein); operations for taking the vehicle out of service, determining a threshold, and stopping the motion of the vehicle (e.g., one or more portions of the

methods

700, 800, 900); and/or any other operation or function for addressing a vehicle fault (as described herein).

The one or more memory devices 1006 may store data 1010 that may be retrieved, manipulated, created, and/or stored by the one or more processors 1010. The data 1010 may include, for example, data associated with the vehicle 102, data acquired by the data acquisition system 112, map data, data associated with a fault, data associated with user input, data associated with one or more action and/or control command signals, data associated with a user, and/or other data or information. Data 1010 may be stored in one or more databases. One or more databases may be split such that they are positioned in multiple locations onboard the vehicle 102. In some implementations, the computing device 110 can obtain data from one or more memory devices remote from the vehicle 102.

The computing device 110 may also include a communication interface 1012 for communicating with one or more other systems onboard the vehicle 102 (e.g., over the network 1002). Communication interface 1012 may include any suitable components for interfacing with one or more networks, including, for example, a transmitter, receiver, port, controller, antenna, or other suitable hardware and/or software.

The vehicle computing system 108 may also include one or more input devices 1014 and/or one or more output devices 1016. Input devices 1014 and/or output devices 1016 may be included within and/or otherwise associated with a human interface system. The input device 1014 may include, for example, hardware for receiving information from a user, such as a touch screen, touch pad, mouse, data input keys, speaker, microphone suitable for voice recognition, and the like. The output devices 1016 may include one or more display devices (e.g., display screen, CRT, LCD) and/or one or more audio output devices 1016 (e.g., speakers). A display device and/or an audio output device may be used to facilitate communication with a user. For example, a human operator (e.g., associated with a service provider) may communicate with a current user of the vehicle 102 via at least one of a display device and an audio output device.

User device 137 may be various types of computing devices. For example, the user device 137 may include a phone, a smart phone, a tablet computer, a Personal Digital Assistant (PDA), a laptop computer, a computerized watch (e.g., a smart watch), computerized glasses, computerized headwear, other types of wearable computing devices, a gaming system, a media player, an electronic book reader, and/or other types of computing devices. User device 137 may be associated with a user (e.g., 136). The user device 137 described herein may also represent a user device that may be included in a human interface system of the vehicle 102.

User device 137 may include one or more input devices 1018 and/or one or more output devices 1020. The input device 1018 may include, for example, hardware for receiving information from a user, such as a touch screen, touch pad, mouse, data input keys, speaker, microphone suitable for voice recognition, and so forth. The output device 1020 may include hardware for providing content for display. For example, the output device 1020 may include a display device (e.g., display screen, CRT, LCD), which may include the hardware of a user interface.

The techniques discussed herein make reference to computing devices, databases, software applications, and other computer-based systems, as well as to actions taken and information sent to and from such systems. One of ordinary skill in the art will recognize that the inherent flexibility of a computer-based system allows for a wide variety of possible configurations, combinations, and divisions of tasks and functionality between and among components. For example, the computer-implemented processes discussed herein may be implemented using a single computing device or multiple computing devices working in combination. The database and applications may be implemented on a single system or distributed across multiple systems. The distributed components may operate sequentially or in parallel.

Further, the computing tasks discussed herein that are performed at a computing device remote from the vehicle (e.g., operating a computing system and its associated computing device) may instead be performed at the vehicle (e.g., via the vehicle computing system). Such a configuration may be implemented without departing from the scope of the present invention.

While the present subject matter has been described in detail with respect to specific example embodiments and methods thereof, it will be appreciated that those skilled in the art, upon attaining an understanding of the foregoing, may readily produce alterations to, modifications of, and equivalents to such embodiments. Accordingly, it should be readily apparent to those of ordinary skill in the art that the scope of the present invention is by way of example rather than by way of limitation, and that the present invention does not preclude inclusion of such modifications, variations and/or additions to the present subject matter.

Claims

1. A computer-implemented method of out-of-service a vehicle, comprising:

obtaining, by one or more computing devices onboard an autonomous-driven vehicle, data indicative of one or more parameters associated with the autonomous-driven vehicle;

determining, by the one or more computing devices, based at least in part on the one or more parameters associated with the autonomous-driven vehicle, that there is a fault associated with the autonomous-driven vehicle;

determining, by the one or more computing devices, that the autonomous driving vehicle is not suitable to provide transportation services for one or more users based at least in part on the presence of the fault; and

in response to determining that the autonomous-driven vehicle is not suitable for providing the transport service for the one or more users, providing, by the one or more computing devices, data to one or more remote computing devices remote from the autonomous-driven vehicle indicating that the autonomous-driven vehicle is to be removed from a library of vehicles identified as being available for providing the transport service for the one or more users.

2. The computer-implemented method of claim 1, wherein the one or more remote computing devices are configured to remove the autonomous driving vehicle from a library of vehicles marked as available to provide the transportation service for the one or more users.

3. The computer-implemented method of claim 1, further comprising:

responsive to determining that the autonomous-driven vehicle is not suitable for providing the transport service for the one or more users, rejecting, by the one or more computing devices, a service request associated with the transport service for the one or more users.

4. The computer-implemented method of claim 1, wherein determining that the autonomous driving vehicle is not suitable to provide the transportation service for the one or more users based at least in part on the presence of the fault comprises:

determining, by the one or more computing devices, a severity of the fault based at least in part on one or more characteristics of the fault;

determining, by the one or more computing devices, an operational status of the autonomous-driven vehicle based at least in part on the severity of the fault, wherein the operational status indicates whether the autonomous-driven vehicle is eligible for the one or more users to provide the transportation service.

5. The computer-implemented method of claim 4, wherein the operational status indicates that the autonomous driving vehicle is not suitable for providing the transportation service to the one or more users.

6. The computer-implemented method of claim 4, wherein the operational status indicates that the autonomous-driven vehicle is eligible to complete provision of the transport service for the one or more users before communicating that the autonomous-driven vehicle is unavailable to provide the transport service.

7. The computer-implemented method of claim 4, wherein determining a severity of the fault is based at least in part on a potential impact of the fault on the one or more users of the transportation service.

8. The computer-implemented method of claim 1, further comprising:

controlling, by the one or more computing devices, the autonomous-driven vehicle to travel to and reach a service location.

9. The computer-implemented method of claim 1, further comprising:

in response to determining that the autonomous-driven vehicle is not suitable for providing the transport service to the one or more users, providing, by the one or more computing devices, data to one or more remote computing devices indicating a request by a different vehicle to provide the transport service to a current user of the autonomous-driven vehicle.

10. The computer-implemented method of claim 1, further comprising:

in response to determining that the autonomous-driven vehicle is not suitable for providing the transportation service to the one or more users, providing, by the one or more computing devices, data to one or more remote computing devices indicating a request for a human operator associated with the one or more remote computing devices to communicate with a current user of the autonomous-driven vehicle.

11. A computing system for out-of-service vehicles, the system comprising:

one or more processors onboard the autonomous-driven vehicle; and

one or more memory devices onboard the autonomous-driven vehicle, the one or more memory devices storing instructions that, when executed by the one or more processors, cause the one or more processors to perform operations comprising:

obtaining data indicative of one or more parameters associated with the autonomous-driven vehicle;

determining that there is a fault associated with the autonomous-driven vehicle based, at least in part, on a comparison of the one or more parameters associated with the autonomous-driven vehicle to one or more thresholds;

determining that the autonomous driving vehicle is not suitable to provide transportation services for one or more users based at least in part on the presence of the fault; and

in response to determining that the autonomous-driven vehicle is not suitable for providing the transport service for the one or more users, providing, to one or more remote computing devices remote from the autonomous-driven vehicle, data indicating that the autonomous-driven vehicle is to be removed from a service queue associated with the transport service for the one or more users.

12. The computing system of claim 11, wherein the autonomous driving vehicle does not accept a request for the transport service for the one or more users when the autonomous driving vehicle is not available to provide the transport service for the one or more users.

13. The computing system of claim 11, wherein the operations further comprise:

providing one or more control command signals to one or more systems onboard the autonomous-driven vehicle to cause the autonomous-driven vehicle to initiate travel to a service location.

14. The computing system of claim 11, wherein at least one of the parameters is indicative of an amount of available data storage onboard the autonomous-driven vehicle.

15. The computing system of claim 14, wherein at least one threshold indicates a threshold amount of available data storage.

16. An autonomous-driving vehicle, comprising:

one or more systems;

one or more processors; and

one or more memory devices that store instructions that, when executed by the one or more processors, cause the one or more processors to perform operations comprising:

obtaining data indicative of one or more parameters associated with the autonomous-driven vehicle, wherein at least a portion of the data is provided by one or more of the systems onboard the autonomous-driven vehicle;

determining that there is a fault associated with the autonomous-driven vehicle based, at least in part, on the one or more parameters associated with the autonomous-driven vehicle;

in response to determining that the autonomous-driven vehicle is not suitable for providing the transport service for the one or more users, providing, to one or more remote computing devices remote from the autonomous-driven vehicle, data indicating that the autonomous-driven vehicle is to be removed from a library of vehicles identified as being available for providing the transport service for the one or more users.

17. The autonomous-driven vehicle of claim 16, wherein the autonomous-driven vehicle is included in a plurality of vehicles associated with a service provider.

18. The autonomous-driven vehicle of claim 17, wherein the one or more remote computing devices are associated with the service provider.

19. The autonomous-driven vehicle of claim 18, wherein the one or more remote computing devices do not provide a request to the autonomous-driven vehicle for the transport service of the one or more users when the autonomous-driven vehicle is unavailable to provide the transport service for the one or more users.

20. The autonomous-driven vehicle of claim 16, wherein the one or more systems onboard the autonomous-driven vehicle comprise one or more image capture devices configured to acquire image data to be used for operation of the autonomous-driven vehicle, and wherein the fault is associated with storing the image data.