Rules based analysis of vehicle sensor data for actions

Techniques are described for determining and performing actions associated with a vehicle based on an analysis of sensor data that describes a state of component(s) of the vehicle. Sensor data is generated by sensor(s) on a vehicle and/or external to the vehicle. The sensor data is analyzed to determine a current state of vehicle component(s), such as whether a component is damaged or otherwise in need of repair or maintenance. The analysis of the sensor data may be performed by a rules engine that applies a set of rules indicating what action(s) are to be performed based on certain detected states of the vehicle component(s) indicated by the sensor data. The rule(s) may also indicate instances in which action(s) can be performed automatically or autonomously in response to detecting vehicle component state(s), or whether authorization is to be requested from an owner, operator, or other individual associated with the vehicle.

BACKGROUND

Maintaining a complex electrical and mechanical system, such as a vehicle, traditionally requires regular inspections, care, and vigilance, to ensure that the device is system is operating as expected or as designed. In many instances, if a minor problem in a vehicle goes undetected and/or uncorrected it can lead to a more serious, more expensive problem, or even lead to a harmful accident.

SUMMARY

Implementations of the present disclosure are generally directed to performing actions based on a detected state of vehicle component(s). More particularly, implementations of the present disclosure are directed to determining a current state of vehicle component(s) based on sensor data generated by sensor(s) in the vehicle and/or external to the vehicle, and applying a set of rule(s) to the state information and/or sensor data to determine action(s) to be performed, such as action(s) to address maintenance issues present in the vehicle component(s) as exhibited by the sensor data.

In general, innovative aspects of the subject matter described in this specification can be embodied in methods that includes operations of: receiving sensor data that is generated, at least in part, by at least one sensor incorporated into a vehicle, the sensor data describing a current state of at least one component of the vehicle; applying one or more rules to the sensor data to determine at least one action to be performed based at least partly on the current state of the at least one component, wherein the at least one action includes sending a communication to initiate a repair of the at least one component of the vehicle; performing the at least one action; and sending a notification to a user device of a user associated with the vehicle, the notification indicating that the at least one action has been performed.

Implementations can include one or more of the following features: the operations further include determining, based at least partly on the one or more rules, that the at least one action is to be performed automatically without an explicit re-authorization by the user associated with the vehicle; the at least one action is performed automatically; the operations further include determining, based at least partly on the one or more rules, that the at least one action is to be performed based on the explicit re-authorization by the user associated with the vehicle; the at least one action is performed in response to receiving the explicit re-authorization by the user; the one or more rules indicate that the at least one action is to be performed automatically, without the explicit re-authorization by the user, based on determining that a monetary value associated with the at least one action is less than a threshold amount; the sensor data further includes external sensor data that describes the vehicle, the external sensor data generated by at least one external sensor separate from the vehicle; the at least one action is performed in real time with respect to the receiving of the sensor data; the sensor data indicates damage to the at least one component of the vehicle; the at least one action includes communicating with at least one service provider to request service to address the damage; and/or determining that the at least one action is to be performed automatically without the explicit re-authorization by the user is further based on preference data specified by the user.

Other implementations of any of the above aspects include corresponding systems, apparatus, and computer programs that are configured to perform the actions of the methods, encoded on computer storage devices.

Implementations of the present disclosure provide one or more of the following technical advantages and/or improvements compared to traditional systems. Implementations provide for the determination and performance of action(s) to address issues identified in vehicle components, based on an analysis of sensor data that describes a state of the vehicle and/or its components. Because such actions can be performed automatically, without requiring additional user authorization, implementations avoid the expenditure of network bandwidth, processing power, storage space, active memory, and/or other computing resources that would be expended to communicate and request authorization, and process the authorization. Moreover, by responding more quickly to vehicle component issues based on analyzed sensor data, implementations more efficiently use such computing resources compared to previously available solutions that may cause greater expenditure of computing resources due to a delayed response to an issue.

DETAILED DESCRIPTION

Implementations of the present disclosure are directed to systems, devices, methods, and computer-readable media for determining and performing actions associated with a vehicle, based on an analysis of sensor data that describes a state of one or more components of the vehicle. Sensor data is generated by one or more sensors that are in, or on, a vehicle, such as an automobile. Sensor data may also be generated by sensor(s) that are external to the vehicle, such as camera, microphones, or other types of sensors that are in the vicinity of the vehicle or that are otherwise situated to collect sensor data that describes the vehicle. The sensor data may be analyzed to determine a current state of at least one component of the vehicle. For example, the sensor data can indicate that a component is damaged or otherwise in need of repair or maintenance. In some implementations, the analysis of the sensor data is performed by a rules engine that applies a set of rules to the sensor data, the rule(s) indicating what action(s) are to be performed based on certain detected states of the vehicle component(s), as indicated by the sensor data. The rule(s) may also indicate instances in which action(s) can be performed automatically or autonomously in response to detecting vehicle component state(s), or whether authorization is to be requested from an owner, operator, or other individual associated with the vehicle. After performing the action(s), either automatically in based on the granted authorization from the individual, the individual may be notified that the action(s) have been performed. In some instances, the action(s) performed also include the submission or initiation of insurance claims to at least partly pay the cost of repair, replacement, and/or maintenance of vehicle components that have been damaged.

Traditionally, repair, maintenance, insurance claims, and/or other actions are initiated by a user, such as an owner or operator of a vehicle that requires maintenance. This can be a burden to the user, and any delay in addressing a problem (either through procrastination or ignorance of the problem), can cause additional damage and greater expense to the user and/or their insurer. In the implementations described herein, a vehicle is equipped with sensor(s) (also described as sensor devices) that monitor the state of various components of the vehicle, and generate sensor data describing the state of component(s). In the event of an accident, mechanical or electrical malfunction, or other damage to the vehicle, the sensor data may be analyzed to determine the nature of the problem and identify one or more appropriate actions to be taken in response to the problem. The response action(s) may include sending a communication to request that a technician repair the issue, an insurance adjuster survey the scene, a drone, satellite, or fixed camera take pictures and gather data regarding the vehicle and its surroundings, and so forth. For example, in the case of a flat tire indicated in the sensor data, roadside assistance personnel can be dispatched to the location of the vehicle to repair or replace the tire. The user (e.g., owner, operator) can then be sent an automated notification about the claim initialization, or the claim initialization can begin automatically. A process may be launched to initiate the insurance claim and/or resolution process (e.g., immediately) following the incident. This would remove the burden from the user and provide faster resolution of the issue, thereby saving the user and their insurer time, money, and effort.

In some implementations, sensor data is collected and analyzed in real time, and/or the action(s) that are determined to be appropriate may be performed in real time with respect to the collection and/or analysis of the sensor data. For example, following an accident involving a vehicle, the sensor data may be collected and analyzed in real time (e.g., with respect to the incident), and action(s) may be identified and performed in real time. In accordance with implementations described herein, real time operations may include operations that can be automatically executed, without requiring human input and without any intentional delay, taking into account the processing limitations of the computing system(s) performing the operations and the time needed to perform the operations. The data, such as the sensor data describing the current state of the vehicle component(s), may be analyzed in real time with respect to the generation of the data by the sensor(s) and with respect to the transmission of the data to analysis computing device(s). For example, there may be no intentional delay between the collection of the data, the analysis of the data, the identification of action(s), and the performing of action(s), beyond the latency incurred in communicating the data over network(s) and performing the analysis operations on computing system(s).

FIG. 1depicts an example environment according to implementations of the present disclosure. As shown in the example ofFIG. 1, the environment may include one or more vehicles102. Although examples may describe the vehicle102as an automobile (e.g., car), implementations are not so limited. The vehicle102may include any form of conveyance, such as automobiles, trucks, recreational vehicles (RVs), motorcycles, scooters, military vehicles, trains, buses, watercraft (e.g., boats), submersible vehicles (e.g., submarines), heavier-than-air aircraft (e.g., airplanes), lighter-than-air aircraft (e.g., dirigibles), spacecraft, and so forth. The vehicle102may be powered by one or more motors or engines using any fuel. The vehicle102may also be a human-powered or animal-powered vehicle such as a bicycle, skateboard, rowboat, kayak, horse-drawn carriage, and so forth. The vehicle102may include various sensor(s)106that collect or otherwise generate sensor data108that describes the state of one or more components of the vehicle, such as engine components, electrical components, drive components, tires, body elements (e.g., panels, doors, windows, roof, bumpers, etc.), seats, and so forth. In some implementations, the vehicle may also include an in-vehicle computing device104, which is described below in more detail. The sensor data108generated by the sensor(s)106may be received by the device104, over one or more wired or wireless connections between the sensor(s)106and the device104. The device104may then send the sensor data108over one or more networks to one or more analysis computing devices110. The sensor data108may be communicated using one or more network interfaces (e.g., transceivers) incorporated into the device104. In some instances, the sensor data108may be communicated from the sensor(s)106to the analysis computing device(s)110without passing through the device104as an intermediary.

The vehicle102may be operated by a driver. The driver may include one or more individuals who operate, or travel within, the vehicle102. Although examples herein describe a driver of a car, implementations are not so limited. Accordingly, the driver may be any operator or occupant of a vehicle102, such as a pilot of an airplane, a sailor of a ship, a rider of a bicycle, and so forth. Although examples herein may describe the driver as a person, implementations are not so limited. In some implementations, the driver may include computer hardware and/or computer software component(s) that autonomously, or semi-autonomously, operate the vehicle102. For example, a human driver may be assisted by, or replaced by, an artificial intelligence, a robot, or any other combination of hardware and/or software component(s) configured to operate a vehicle102. In some examples, the driver may carry, wear, or otherwise be in proximity to a mobile device (e.g., the user device120) such as a smartphone, tablet computer, wearable computer, implanted computer, and so forth. In some instances, the mobile device may include any number of sensors that generate sensor data108describing the location, movement, orientation, or other status information regarding the mobile device. Such sensor data may be communicated to the analysis computing device(s)110, using one or more network interfaces (e.g., transceivers) of the mobile device.

In some implementations, the environment includes one or more external sensors. The external sensor(s) may be external from but in proximity to the vehicle102at one or more times, and may be configured to collect sensor data108regarding the location, speed, orientation, or other characteristics of the vehicle102. For example, external sensors may employ radar, sonar, infrared, radio-frequency identification sensors, or optical sensors to detect the presence of the vehicle102in proximity to the external sensor, and measure the vehicle's position, speed, acceleration, and orientation. External sensor(s) may also generate image(s) of the vehicle102, video of the vehicle102, audio data (e.g., sound recordings in the vicinity of the vehicle), information regarding the environment in proximity to the vehicle, such as weather conditions, road conditions, traffic conditions, and so forth. Such information may be communicated as sensor data108using one or more wired or wireless network interfaces (e.g., transceivers) that are incorporated into the external sensor(s) or that are communicatively coupled to the external sensor(s).

One or more sensors106in the vehicle102, sensors of the mobile device, and/or external sensor(s) may also collect sensor data108describing the state of component(s) of the vehicle102, and/or the operations of the vehicle102. The sensor data108may be dynamic data that describes a current (e.g., real time) state of the vehicle102and/or its components. Such state information may describe the structural integrity, operational state (e.g., functional, non-functional, etc.), and/or other characteristics of vehicle components. The state information may also describe the vehicle102as a whole with regard to its location, position, orientation, speed, acceleration, deceleration (e.g., braking), direction of travel, or other characteristics. In some implementations, the sensor data108includes movement data that indicates changes in one or more of the speed, the direction, or the orientation of the vehicle102. The orientation or direction of the vehicle102may include orientation or direction relative to any reference axis. Accordingly, orientation or direction may include yaw, pitch, roll, or other indications of orientation relative to any axis.

The sensor data108may also include location data that describes the location, or position, of the vehicle102. The location data may be determined using any technique, and may be determined to any degree of specificity. For example, the vehicle102and/or a mobile device therein may include location sensor(s), transceiver(s), other hardware component(s), or other software component(s) configured to determine the location of the vehicle102or mobile device using one or more of the following: an inertial navigation system, a dead-reckoning navigation system, a network positioning system, a radio position finding system, a satellite-based navigation system, an accelerometer system, a gyroscope system, and so forth. The satellite-based navigation system may include one or more of a Global Positioning System (GPS) receiver, a Globalnaya Navigatsionnaya Sputnikovaya Sistema (GLONASS) receiver, a Galileo receiver, an Indian Regional Navigational Satellite System, and so forth.

The sensor data108may also include other information, such as telematics data, that describes the vehicle102and/or its components. For example, the sensor data108may include information regarding the condition of the vehicle102, such as the odometer reading, fuel efficiency, current status of fuel or other fluids, temperature, weight, number of wheels, tire condition, drive train condition, and so forth. The sensor data108may also indicate dynamic road conditions, such as whether the road is icy, wet, or dry, banked or not banked, flat, inclined, and so forth.

The sensor data108may be communicated over one or more wired or wireless networks to one or more analysis computing devices110. In some implementations, the sensor data108may be received at the in-vehicle computing device104, communicated over one or more wired or wireless connections with the sensor(s)106, and transmitted by the device104to the analysis computing device(s)110. In some implementations, a mobile device may be connected to a communications port in the vehicle102, and the mobile device may receive sensor data108in the form of onboard diagnostics (OBD) and/or telematics data from vehicle sensor(s), device104, and/or other in-vehicle systems. Such sensor data108may then be communicated to the analysis computing device(s)110from the mobile device over a cell network or other suitable wireless network. In some implementations, the device104may include a wireless transceiver that communicates sensor data108to the analysis computing device(s)110. The mobile device, device104, and/or external sensor(s) may communicate sensor data108to the analysis computing device(s)110directly or via one or more intermediary device(s). In some implementations, the mobile device may generate and send telematics data that is determined independently of onboard systems of the vehicle102, and which may be described as mobile-only telematics data. For example, the mobile device may generate information regarding the location, orientation, speed, and/or acceleration of the vehicle102based on the determined location, orientation, speed, and/or acceleration of the mobile device as determined using sensors (e.g., gyroscopic sensors, accelerometers, location sensing technology, etc.) included in the mobile device. The mobile device collecting such data may be a computing device such as a smartphone, tablet computer, and so forth. The mobile device collecting the data may also be a stand-alone device (e.g., dongle) that includes various sensor device(s) and wireless transceiver for transmitting the collected sensor data. Such a stand-alone device may be headless, e.g., lacking a user interface of its own. The stand-alone device may connect to a port in the vehicle102and/or on the device104to receive power and/or data from various vehicle systems.

In some implementations, a user (e.g., driver) may receive reward(s) for agreeing to provide sensor data108from the device104, sensor(s)106, mobile device, and/or vehicle102to the analysis computing device(s)110. For example, the user may be given a monetary reward, discount on premiums, points redeemable toward purchase of products or services, discounted insurance premiums, and/or other types of value.

The analysis computing device(s)110may execute one or more analysis modules112that are configured (e.g., as software) to analyze the sensor data108and determine action(s)116to be performed based on a detected state of the vehicle and/or vehicle component(s), as indicated in the sensor data108. In some implementations, the analysis module(s)112include a rules engine114that applies a set of rule(s)128to the sensor data108to determine action(s)116to be performed.

The rule(s)126may also indicate conditions under which action(s)116can be performed automatically, or whether user authorization is required prior to performing the action(s)116. For example, the rule(s)126may indicate that maintenance may be performed without explicit re-authorization (e.g., in this instance) by the user for those repairs or maintenance that has an associated cost below a threshold amount (e.g., less than $100). The user, in such instances, may have previously agreed to such rule(s) when registering or signing up for the service, and/or when opting in to agree to the collection and analysis of the sensor data108, and the user may not be subsequently asked to authorize particular instances of repair and/or maintenance when the rule(s)126indicate that such repair and/or maintenance can be performed without explicit re-authorization by the user. The rule(s)126may also indicate particular types or categories of repair and/or maintenance that may be performed without the user's explicit re-authorization. For example, tire repairs, battery replacements, and so forth may be performed without explicit re-authorization by the user. In some examples, the action(s)116may include sending a communication over one or more networks to instruct an autonomous, or semi-autonomous repair vehicle to travel to the location of the vehicle to automatically initiate a repair of damaged components, and/or to automatically transport maintenance personnel to the vehicle to perform the repair.

In instances where explicit authorization is indicated in the rule(s)126, a message may be sent to the user and displayed in an application122executing on the user device120of the user (e.g., the owner and/or operator of the vehicle102). In some examples, the user device120may be the mobile device that is in the vehicle102, as described above. User device120may include other computing device(s) operated by the user. User device(s)120may include any suitable type of computing device, including but not limited to personal computers, desktop computers, laptop computers, tablet computers, notebook computers, smartphones, personal data assistants (PDAs), wearable computers, implanted computers, server computers, cloud computing (e.g., distributed computing) devices, onboard vehicle computers, and so forth. On receiving the request for authorization, the user may use the application122to authorize (or not authorize) the action(s)116. The action(s)116may then be performed in response to the user authorization.

In either scenario, if explicit re-authorization is indicated or not indicated by the rule(s)124, following performance of the action(s)116, a notification118may be sent to notify the user that action(s) have been performed. The notification118may be presented in the application122(e.g., a mobile app executing on the user device120).

In some instances, the determination of action(s)116to be performed, and/or the determination whether explicit re-authorization is to be sought prior to performing action(s)116, may be further controlled by preference data124specified by the user through the application122or otherwise. For example, the user may specify preferences for the threshold amount, below which action(s)116may be performed automatically without explicit re-authorization. The user may also specify the types of actions that may be performed without explicit re-authorization, such as tire repairs, window repairs, dead battery replacements, and so forth.

For example, the sensor data108may indicate that a tire on the vehicle as below threshold air pressure (e.g., below the recommended operating pressure for the particular equipped tires). Instead of the user finding out later and having to deal with the issue themselves, as would be the case with previously available solutions, the in-vehicle device104can send the sensor data108to the analysis computing device(s)110, which analyze the data, identify the problem, and (e.g., automatically) perform an action116to correct the issue, such as dispatching maintenance personnel to the location of the vehicle102(e.g., as indicated in the sensor data108) to put air in the tire, examine the tire for damage, replace the tire, and so forth. Accordingly, implementations enable an automated concierge service to assist the user in maintaining their vehicle. Other damage situations that may be addressed include, but are not limited to, light malfunctions, window damage, low fluid levels or replacement, dents or other body damage, low or dead battery, air filter replacements, and so forth. Actions may also include determining the covered loss under an insurance policy and (e.g., automatically) initiating a claim for damage following an accident or other incident. Action(s) may also include identifying and contacting a repair shop to handle repairs to the vehicle. In some instances, the system may negotiate for repair cost, on behalf of the user, with repair shops (e.g., to get the best possible deal for the user).

As described above, the rule(s)126can set parameters for damage amounts and indicate whether action(s)116can be performed automatically for a cost within a certain range. Rule(s)126may also specify the action(s)116to be performed, and whether such action(s)116can be performed automatically, based on other parameters such as location of the vehicle, time of day, day of the week, and so forth. For example, automated maintenance action(s)116may be permitted between 8:00 a.m. and 6:00 p.m., but authorization can be sought outside that range of times.

The analysis module(s)112may analyze the sensor data108to determine an extent of damage to vehicle components, a particular nature of the damage and/or malfunction of components, and so forth. The sensor data108can also be analyzed to determine a cause of the damage, and/or to determine whether the damage is covered under an insurance policy. In some implementations, a suitable machine learning technique may be applied to determine the state of the components based on the sensor data108, the nature of damage to component(s), and/or the appropriate action(s) to be performed. External sensor data, such as data from traffic cameras, ambient sound detectors (e.g., microphones), security cameras, drones, satellites, data from other vehicles, and so forth, may be used to identify cause of damage, such as whether the damage was caused by an accident with another vehicle, vandalism, the driver's own negligence, and so forth.

In some instances, action(s)116performed in real time may include actions to address serious issues regarding the vehicle, such as issues preventing the normal use or operation of the vehicle. Alternatively, less urgent problems may be addressed later, e.g., through scheduled maintenance visits. Accordingly, action(s) may include scheduling an appointment with a service provider, and informing the user of the scheduled appointment (e.g., to check fluid levels, engine tune-up, etc.). In this way, the system may operate as a virtual personal assistant for the user, to keep track of maintenance issues and/or a maintenance schedule for the vehicle, such as manufacturer-recommended maintenance, regular service checks, government-mandated inspections, and/or other issues.

The rule(s)126may indicate when and/or if the notifications118are to be sent to the user, including when authorization is to be sought from the user prior to performing the action(s)116. Rule(s)126may indicate whether notification is to be provided before, during, and/or after the action(s), and/or the parties to be notified (e.g., the driver, owner, driver's parents, etc.),

In the example ofFIG. 1, the analysis of the sensor data108, determination of action(s)116to be performed, requests for authorization, notifications, and/or other operations are performed on the analysis computing device(s)110. Alternatively, at least a portion of the processing may be performed by the in-vehicle device104.

In some implementations, the in-vehicle device104is a vehicle computer that may include an on-board diagnostics (OBD) port. The computer may also include, and/or communicate with, one or more vehicle telematics sensors and/or component sensor(s) as described above. The computer may operate as a data collection device that is connected to the vehicle102via an OBD port connector that is connected to the OBD port to receive telematics data (e.g., sensor data108) and/or other information generated by the telematics sensor(s) and/or other sensor(s)106. Such information may be communicated to the data collection device over the OBD port.

In some implementations, the device104includes a central processing unit (CPU), a (e.g., satellite-based) navigation system receiver, at least one accelerometer, at least one orientation sensor, a memory, a UI, and at least one (e.g., wireless) network interface. The CPU may communicate with the other elements of the device104to facilitate the operation of the device104. The CPU may be configured to process data received from one or more of the navigation system receiver, the accelerometer(s), the orientation sensor(s), or the OBD port connector. Data processing may include receiving sensor data108from one or more of the sensor(s)106, the navigation system receiver, the accelerometer(s), the orientation sensor(s), or the OBD port connector, and communicating the sensor data108to the analysis computing device(s)110using the network interface(s). In some implementations, the CPU may analyze the sensor data108to determine action(s) and/or perform action(s) in addition to, or instead of, such operations being performed on the analysis computing device(s)110. The sensor data108may be communicated, over one or more networks, using any communication protocol or in any format. In some examples, the sensor data108may be compressed, encrypted, or both prior to communication over networks and/or storage.

The navigation system receiver may include an antenna and associated signal processing circuitry for receiving signals from global navigation satellite system (GNSS) satellites, and determining the location of the device104based on the signals. GNSS satellites may be, for example, GPS, GLONASS, Galileo, or Beidou satellites which send time and orbital data which the device104may use to calculate its location. In some implementations, the CPU calculates the location of the data collection device200using the data received by the navigation system receiver. The CPU may retrieve location data from the navigation system receiver at set time intervals. The CPU may send the location data to the memory along with a timestamp (e.g., time and/or date) indicating when the data collection device was at the location. In some implementations, the navigation system receiver may be component of a separate navigation device used by the driver for obtaining driving directions or location information. In such examples, the navigation system receiver transmits data to the device104though a wired connection or a wireless connection, e.g., BlueTooth or Wi-Fi.

The accelerometer(s) may include any device that measures (e.g., proper) acceleration. Data collected from an accelerometer(s) may include or be used for determining the g-force, acceleration, deceleration, orientation, shock, vibration, jerk, velocity, speed, and/or position of the device104or vehicle102. In some examples, acceleration data describing the acceleration or deceleration of the vehicle102may be collected from other systems of the vehicle102, such as the brakes or accelerator systems of the vehicle102, or from onboard telematics devices that collect information from the brakes or acceleration systems.

The orientation sensor(s) may include any device that measures the orientation of the device104, or the vehicle102, relative to any reference axis. Orientation sensor(s) may measure yaw, pitch, or roll. Orientation sensor(s) may also include a compass or other device that measures the direction of the device104, or the vehicle102, with respect to a magnetic field such as the Earth's magnetic field. In some examples, orientation sensor(s) include one or more gyroscope-based sensors that detect change in orientation relative to one or more axes.

The sensor data108from one or more of the sensor(s)106, the OBD port connector, the navigation system receiver, the accelerometer(s), or the orientation sensor(s) may be received by the CPU. The CPU may collect data at intervals, or continuously, and store the data in the memory of the device104. Each data element may be associated with a timestamp and/or a location stamp indicating a location where the data was collected.

The device104may include network interface(s) for sending collected sensor data108to the analysis computing device(s)110via one or more wired or wireless networks. The device104may also be configured to communicate with the driver or a passenger via its UI, visually, through speech output, or otherwise. The UI may include output components, such as a display, speakers, or haptic output component(s). The UI may also include input components, such as a touch screen, keyboard, or audio input device (e.g., microphone). In some implementations, the UI may receive and present data such as vehicle diagnostics data, or sensor data108. In some implementations, the device104may operate as a navigation device that can calculate and display a route to a destination specified by the driver.

Although examples herein may describe the driver or operator of a vehicle as a human driver, implementations are not limited to such scenarios. In some instances, the vehicle102may be operated by an artificial intelligence (AI), such that the vehicle102is autonomous, semi-autonomous, and/or driverless. In such instances, the action(s) performed may include sending instructions to the vehicle102to cause the vehicle102to move itself to a particular location for maintenance, such as a repair shop or maintenance bay. Action(s) may also include sending instructions to cause the vehicle102to remain at its current location until a repair vehicle and/or personnel arrive to address the problem that is exhibited in the sensor data108.

FIG. 2depicts an example format for a rule set126for determining actions116, according to implementations of the present disclosure. As shown in the example ofFIG. 2, the rule(s)126may include any suitable number of rules. Each rule may specify one or more conditions202, and one or more action(s)204to be performed if such condition(s)202are satisfied. A rule may also include an authorization flag206, indicating whether the user's explicit re-authorization is required to perform the action(s)204, or whether the action(s)204can be performed automatically if the condition(s)202are satisfied. A condition may be a value or range of values corresponding to a particular measured parameter included in the sensor data. For example, a condition may be that the tire pressure for any of the tires on the vehicle is below a threshold pressure value, and/or outside the recommendation range of operating pressure for the currently equipped tires. A condition may also be the presence of a particular issue in a component. For example, a condition may be that the sensor data indicates a chip in the windshield, a dent in a body panel, a dent in a bumper, the presence of an electrical short in the vehicle's electrical system, a detected fire in the engine, and so forth. Conditions may be arranged as a Boolean combination of multiple conditions, such as A and (B or C).

FIG. 3depicts a flow diagram of an example process for determining and performing actions116based on vehicle sensor data108, according to implementations of the present disclosure. Operations of the process may be performed by one or more of the analysis module(s)112, the rules engine114, the application122, and/or other software module(s) executing on the analysis computing device(s)110, the in-vehicle computing device104, the user device120, and/or elsewhere.

The sensor data106is received (302), describing a (e.g., current) state of the vehicle102and/or components of the vehicle102. The sensor data106is analyzed (304) to determine action(s)116to be performed. In some implementations, this analysis includes applying rule(s)126to determine suitable action(s)116. In some implementations, preference data124is accessed (306).

Based on applying the rule(s)126and/or preference data124to the sensor data106, a determination is made (308) whether explicit re-authorization is required from the user prior to performing the determined action(s)116. If not, the action(s)116are performed (310). If explicit re-authorization is required, the authorization is requested (312) from the user. If authorization is received (314), the action(s) are performed (310). If not, the action(s) are not performed (316). After performing the action(s), either automatically or based on the user authorization, the user may be notified (318) that the action(s) have been performed, as described above.

FIG. 4depicts an example computing system, according to implementations of the present disclosure. The system400may be used for any of the operations described with respect to the various implementations discussed herein. For example, the system400may be included, at least in part, in one or more of the in-vehicle computing device104, the user device120, the analysis computing device(s)110, and/or other computing devices or systems described herein. The system400may include one or more processors410, a memory420, one or more storage devices430, and one or more input/output (I/O) devices450controllable via one or more I/O interfaces440. The various components410,420,430,440, or450may be interconnected via at least one system bus460, which may enable the transfer of data between the various modules and components of the system400.

The processor(s)410may be configured to process instructions for execution within the system400. The processor(s)410may include single-threaded processor(s), multi-threaded processor(s), or both. The processor(s)410may be configured to process instructions stored in the memory420or on the storage device(s)430. The processor(s)410may include hardware-based processor(s) each including one or more cores. The processor(s)410may include general purpose processor(s), special purpose processor(s), or both.

The memory420may store information within the system400. In some implementations, the memory420includes one or more computer-readable media. The memory420may include any number of volatile memory units, any number of non-volatile memory units, or both volatile and non-volatile memory units. The memory420may include read-only memory, random access memory, or both. In some examples, the memory420may be employed as active or physical memory by one or more executing software modules.

The storage device(s)430may be configured to provide (e.g., persistent) mass storage for the system400. In some implementations, the storage device(s)430may include one or more computer-readable media. For example, the storage device(s)430may include a floppy disk device, a hard disk device, an optical disk device, or a tape device. The storage device(s)430may include read-only memory, random access memory, or both. The storage device(s)430may include one or more of an internal hard drive, an external hard drive, or a removable drive.

One or both of the memory420or the storage device(s)430may include one or more computer-readable storage media (CRSM). The CRSM may include one or more of an electronic storage medium, a magnetic storage medium, an optical storage medium, a magneto-optical storage medium, a quantum storage medium, a mechanical computer storage medium, and so forth. The CRSM may provide storage of computer-readable instructions describing data structures, processes, applications, programs, other modules, or other data for the operation of the system400. In some implementations, the CRSM may include a data store that provides storage of computer-readable instructions or other information in a non-transitory format. The CRSM may be incorporated into the system400or may be external with respect to the system400. The CRSM may include read-only memory, random access memory, or both. One or more CRSM suitable for tangibly embodying computer program instructions and data may include any type of non-volatile memory, including but not limited to: semiconductor memory devices, such as EPROM, EEPROM, and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks. In some examples, the processor(s)410and the memory420may be supplemented by, or incorporated into, one or more application-specific integrated circuits (ASICs).

The system400may include one or more I/O devices450. The I/O device(s)450may include one or more input devices such as a keyboard, a mouse, a pen, a game controller, a touch input device, an audio input device (e.g., a microphone), a gestural input device, a haptic input device, an image or video capture device (e.g., a camera), or other devices. In some examples, the I/O device(s)450may also include one or more output devices such as a display, LED(s), an audio output device (e.g., a speaker), a printer, a haptic output device, and so forth. The I/O device(s)450may be physically incorporated in one or more computing devices of the system400, or may be external with respect to one or more computing devices of the system400.

The system400may include one or more I/O interfaces440to enable components or modules of the system400to control, interface with, or otherwise communicate with the I/O device(s)450. The I/O interface(s)440may enable information to be transferred in or out of the system400, or between components of the system400, through serial communication, parallel communication, or other types of communication. For example, the I/O interface(s)440may comply with a version of the RS-232 standard for serial ports, or with a version of the IEEE 1284 standard for parallel ports. As another example, the I/O interface(s)440may be configured to provide a connection over Universal Serial Bus (USB) or Ethernet. In some examples, the I/O interface(s)440may be configured to provide a serial connection that is compliant with a version of the IEEE 1394 standard.

The I/O interface(s)440may also include one or more network interfaces that enable communications between computing devices in the system400, or between the system400and other network-connected computing systems. The network interface(s) may include one or more network interface controllers (NICs) or other types of transceiver devices configured to send and receive communications over one or more networks using any network protocol.

Computing devices of the system400may communicate with one another, or with other computing devices, using one or more networks. Such networks may include public networks such as the internet, private networks such as an institutional or personal intranet, or any combination of private and public networks. The networks may include any type of wired or wireless network, including but not limited to local area networks (LANs), wide area networks (WANs), wireless WANs (WWANs), wireless LANs (WLANs), mobile communications networks (e.g., 3G, 4G, Edge, etc.), and so forth. In some implementations, the communications between computing devices may be encrypted or otherwise secured. For example, communications may employ one or more public or private cryptographic keys, ciphers, digital certificates, or other credentials supported by a security protocol, such as any version of the Secure Sockets Layer (SSL) or the Transport Layer Security (TLS) protocol.

The system400may include any number of computing devices of any type. The computing device(s) may include, but are not limited to: a personal computer, a smartphone, a tablet computer, a wearable computer, an implanted computer, a mobile gaming device, an electronic book reader, an automotive computer, a desktop computer, a laptop computer, a notebook computer, a game console, a home entertainment device, a network computer, a server computer, a mainframe computer, a distributed computing device (e.g., a cloud computing device), a microcomputer, a system on a chip (SoC), a system in a package (SiP), and so forth. Although examples herein may describe computing device(s) as physical device(s), implementations are not so limited. In some examples, a computing device may include one or more of a virtual computing environment, a hypervisor, an emulation, or a virtual machine executing on one or more physical computing devices. In some examples, two or more computing devices may include a cluster, cloud, farm, or other grouping of multiple devices that coordinate operations to provide load balancing, failover support, parallel processing capabilities, shared storage resources, shared networking capabilities, or other aspects.