Systems and methods for remotely controlling data collection by a vehicle

System, methods, and other embodiments described herein relate to controlling a vehicle to selectively collect event data. In one embodiment, a method includes, in response to receiving a collection request from a remote server, identifying defined parameters from the collection request about which data is to be harvested from the vehicle. The defined parameters include at least a content parameter that indicates criteria for determining which data associated with the vehicle is to be collected. The method includes collecting, from one or more vehicle systems of the vehicle, event data as a function of the content parameter and discarding extraneous data that does not match the content parameter. The method includes providing the event data to fulfill the collection request.

TECHNICAL FIELD

The subject matter described herein relates in general to systems for collecting information from a vehicle and, more particularly, to remotely controlling which information is collected and reported by the vehicle.

BACKGROUND

As computing devices become integrated with different machines and aspects of daily living, more information also becomes available. By way of example, where previously information about operating characteristics of different vehicle systems may not have been available, now information is available from many different systems because of the integration of computing devices with the vehicle. However, coincident with the availability of information arises difficulties with managing the information. That is, as more information is collected, additional storage is needed for the information, which comes with associated costs both monetary and space-wise. Moreover, searching the large amounts of collected information for desired information can be computationally intensive.

SUMMARY

In one embodiment, example systems and methods relate to a manner of remotely controlling which data the vehicle collects. For example, in one embodiment, the vehicle is configured to receive instructions from a remote server about which data is to be collected and reported. Thus, when a particular type of data about, for example, a particular event or operation of a particular vehicle system is desired, a collection request is provided to the vehicle. The vehicle receives the collection request and configures one or more internal filters to selectively collect event data specified by the collection request while discarding other data. Subsequently, the vehicle can, for example, communicate the event data back to the requesting entity. In this way, collection of data can be focused to avoid excessive amounts of collected information that use extra storage and complicate identifying desired data.

In one embodiment, a collection system for collecting information from a vehicle is disclosed. The collection system includes one or more processors and a memory that is communicably coupled to the one or more processors. The memory stores a communication module that includes instructions that when executed by the one or more processors cause the one or more processors to, in response to receiving a collection request from a remote server, identify defined parameters from the collection request about which data is to be harvested from the vehicle. The defined parameters include at least a content parameter that indicates criteria for determining which data associated with the vehicle is to be collected. The memory stores a filter module including instructions that when executed by the one or more processors cause the one or more processors to collect, from one or more vehicle systems of the vehicle, event data as a function of the content parameter and discarding extraneous data that does not match the content parameter. The communication module includes instructions to provide the event data to fulfill the collection request.

In one embodiment, a non-transitory computer-readable medium is disclosed. The computer-readable medium stores instructions that when executed by one or more processors cause the one or more processors to perform the disclosed functions. The instructions include instructions to, in response to receiving a collection request from a remote server, identifying defined parameters from the collection request about which data is to be harvested from the vehicle. The defined parameters include at least a content parameter that indicates criteria for determining which data associated with the vehicle is to be collected. The instructions include instructions to collect, from one or more vehicle systems of the vehicle, event data as a function of the content parameter and discarding extraneous data that does not match the content parameter. The instructions include instructions to provide the event data to fulfill the collection request.

In one embodiment, a method of collecting information from a vehicle is disclosed. The method includes, in response to receiving a collection request from a remote server, identifying defined parameters from the collection request about which data is to be harvested from the vehicle. The defined parameters include at least a content parameter that indicates criteria for determining which data associated with the vehicle is to be collected. The method includes collecting, from one or more vehicle systems of the vehicle, event data as a function of the content parameter and discarding extraneous data that does not match the content parameter. The method includes providing the event data to fulfill the collection request.

DETAILED DESCRIPTION

Systems, methods and other embodiments associated with selectively collecting event data from a vehicle are disclosed. As mentioned previously, collecting information from a vehicle can be a complex task. In particular, isolating information from large amounts of available data that is generated by disparate systems and components can be complex. In general, this complexity may result from the vehicle generating large log files that indiscriminately include information without regard to a particular relevancy of that data. Thus, extraneous data is collected and stored among data that is pertinent to a particular event. Moreover, storing the data in this way can consume extra resources such as processing time and/or memory capacity. As an additional complexity, when information is to be collected from a plurality of vehicles, the complexity of isolating data about a particular event or component can be compounded because of a quantity of data that is to be searched/parsed to find the relevant data. Furthermore, when the data is not specifically labeled or otherwise marked the task can be further complicated.

Therefore, in one embodiment, a collection system targets particular data for collection that is relevant to, for example, a particular collection request while discarding extraneous data that does not relate to the collection request. Moreover, a centralized remote server or other authority can direct a multiplicity of vehicles to collect data according to defined parameters. In this way, data that is relevant to a particular purpose can be aggregated while avoiding difficulties associated with storing and parsing large data sets that include irrelevant data in addition to the relevant data.

Referring toFIG. 1, an example of a vehicle100is illustrated. As used herein, a “vehicle” is any form of motorized transport. In one or more implementations, the vehicle100is an automobile. While arrangements will be described herein with respect to automobiles, it will be understood that embodiments are not limited to automobiles. In some implementations, the vehicle100may be any other form of motorized transport that, for example, benefits from selectively collecting event data as discussed herein.

The vehicle100also includes various elements. It will be understood that in various embodiments it may not be necessary for the vehicle100to have all of the elements shown inFIG. 1. The vehicle100can have any combination of the various elements shown inFIG. 1. Further, the vehicle100can have additional elements to those shown inFIG. 1. In some arrangements, the vehicle100may be implemented without one or more of the elements shown inFIG. 1. Further, while the various elements are shown as being located within the vehicle100inFIG. 1, it will be understood that one or more of these elements can be located external to the vehicle100. Further, the elements shown may be physically separated by large distances.

In either case, the vehicle100includes a collection system170that is implemented to perform methods and other functions as disclosed herein relating to selectively collecting event data within the vehicle100according to a collection request. The noted functions and methods will become more apparent with a further discussion of the figures.

With reference toFIG. 2, one embodiment of the collection system170ofFIG. 1is further illustrated. The collection system170is shown as including a processor110from the vehicle100ofFIG. 1. Accordingly, the processor110may be a part of the collection system170, the collection system170may include a separate processor from the processor110of the vehicle100, or the collection system170may access the processor110through a data bus or another communication path. In one embodiment, the collection system170includes a memory210that stores a communication module220and a filter module230. The memory210is a random-access memory (RAM), read-only memory (ROM), a hard-disk drive, a flash memory, or other suitable memory for storing the modules220and230. The modules220and230are, for example, computer-readable instructions that when executed by the processor110cause the processor110to perform the various functions disclosed herein.

Accordingly, in one embodiment, the communication module220generally includes instructions that function to control the processor110to identify defined parameters that indicate which data is to be collected from the vehicle100. In one implementation, the communication module220receives wireless communications through a wireless cellular connection or other communications link. By way of example, when an original equipment manufacturer (OEM) of the vehicle100wishes to collect information about a particular event, a remote server may generate a collection request that is communicated to the vehicle100. The collection request can include defined parameters indicating, for example, a content parameter and a trigger event. The content parameter defines attributes of data that is to be collected. For example, the content parameter can indicate a source of data (e.g., a particular sensor), a type of data (e.g., particular errors, etc.), and so on. Additionally, the trigger event can indicate an occurrence of an event related to the vehicle100that causes the collection system170to initiate data collection. Thus, the trigger event can include a geospatial boundary, a particular action (e.g., degree of braking), a particular timeframe (e.g., night vs. day, specific time, etc.), and so on.

Moreover, a form of the collection request can include a self-extracting software package, an XML file populated with the defined parameters, or another suitable means of conveying the defined parameters. In either case, the communication module220can initially identify the defined parameters from a wireless communication or other message source (e.g., physically inserted flash drive) of the collection request by parsing communication to extract the defined parameters. Alternatively, the communication module220can initiate the self-extracting software package to install within the vehicle100and/or configure one or more filters within the vehicle100to sniff for the event data250and store the event data250in a memory (e.g., memory210) as will be discussed in further detail subsequently.

Furthermore, the collection system170, in one embodiment, also includes the filter module230that generally includes instructions that function to control the processor110to collect event data250according to the defined parameters. In one embodiment, the filter module230configures and monitors multiple filters at different hook points within the vehicle systems140and/or sensor systems120in order to identify and collect information according to the defined parameters. Thus, the filter module230functions to acquire event data250that matches the defined parameters while excluding extraneous information that does not match the defined parameters.

Accordingly, in one embodiment, the collection system170includes the database240. The database240is, in one embodiment, an electronic data structure stored in the memory210or another data store and that is configured with routines that can be executed by the processor110for analyzing stored data, providing stored data, organizing stored data, and so on. Thus, in one embodiment, the database240stores data used/provided by the modules220and230in executing various functions. In one embodiment, the database240includes the event data250along with, for example, metadata that characterizes various aspects of the event data250. For example, the metadata can include location coordinates (e.g., longitude and latitude), relative map coordinates, time/date stamps from when the separate event data250are collected, and so on.

Additional aspects of selectively collecting the event data250according to remote collection requests will be discussed in relation toFIG. 3.FIG. 3illustrates a flowchart of a method300that is associated with selectively collecting and storing data. Method300will be discussed from the perspective of the collection system170ofFIGS. 1 and 2. While method300is discussed in combination with the collection system170, it should be appreciated that the method300is not limited to being implemented within the collection system170, but is instead one example of a system that may implement the method300.

At310, the communication module220monitors for a collection request. In one embodiment, the collection request is a communication issued by a remote server for controlling the vehicle100to collect particular event data250. For example, when an original equipment manufacturer (OEM) or other authorized entity wishes to collect information about a particular aspect of the vehicle100(e.g., emergency braking events), a collection request can be generated with defined parameters and communicated to at least the vehicle100to cause the vehicle100to monitor for the prescribed event data250. Therefore, at310, the communication module220monitors for the collection request by monitoring one or more communication networks (e.g., cellular, wifi, satellite, etc.) in order to identify when the collection request is provided. In further embodiments, the communication module220can monitor for the collection request via local ports (e.g., serial ports, USB ports, etc.) of the vehicle100as provided through a physical connection.

At320, the communication module220identifies the defined parameters from the collection request. In one embodiment, the communication module220parses the collection request to locate and retrieve the defined parameters. For example, the communication module220can parse the collection request to identify separate fields from which the communication module220can then extract the defined parameters. Alternatively, in an implementation where the collection request includes a software package or a self-extracting code, the communication module220can initiate the code to populate one or more filters of the vehicle100with the defined parameters and/or to execute on the processor100as part of the communication module220to monitor for the event data250.

As indicated previously, the defined parameters can include content parameters, one or more trigger events, and a termination event. In either case, the defined parameters include at least the content parameter that indicates criteria for determining which data associated with the vehicle is to be collected. The content parameters specify sources (e.g., sensors or systems) of the event data250, logical conditions (e.g., =, >, <, AND, XOR, etc.) for collecting the event data250, particular types (e.g., velocity, direction, position, etc.) of the event data250, formatting, and so on.

For example, in a broadest context, the content parameter can indicate to collect all available data from the vehicle100when the trigger event occurs. That is, the content parameter can simply specify to collect all data for a particular trigger event. By contrast, when specified in a narrower context, the content parameter can indicate to collect from a particular source (e.g., LIDAR sensor124), one or more conditions (e.g., a relative location from which data is desired such as in front of the vehicle100), and other conditions in addition to the occurrence of the trigger event. Thus, the event data250that is to be collected can be specified with a specific or general granularity depending on which data is desired.

Additionally, the defined parameters can further specify the trigger event and the termination event. The trigger event is, in one embodiment, an indicator of when to begin collecting the event data250according to the conditions specified by the content parameters. Thus, as will be explained further in relation to block340, the filter module230generally monitors one or more streams of data in the vehicle100to identify the occurrence of the trigger event. Moreover, the termination event, in one embodiment, specifies conditions used by the filter module230to determine when collection of the event data250is to cease after an occurrence of the trigger event. Further aspects of the termination event will be discussed in relation to block370.

At330, the communication module220configures one or more filters of the vehicle100with the defined parameters. In one embodiment, the filters are various access points into the vehicle systems140and the sensor systems120. For example, the filters can be application programming interface (API) hooks into various routines executing in the vehicle100, observation points of one or more data buses, routines that can access register values, and so on. In general, the filters function to access data produced by various systems/sensors of the vehicle100and to divert and/or copy the data according to the defined parameters. Thus, in one embodiment, any electronic information produced by or contained within the vehicle100can be accessed by the filters for purposes of collection as disclosed herein. Therefore, in an instance when the collection request includes a software package or other code that is to monitor the systems/sensors of the vehicle100, the filters can be directly controlled by the noted executing code in order to retrieve the event data250and/or the executing code can be integrated with the filters to provide access to the data. In either case, the communication module220uses the defined parameters from the collection request to configure the vehicle100to collect event data250.

At340, the filter module230monitors for a trigger event. In one embodiment, the trigger event defines a specific event in relation to the vehicle100for which data is to be collected. For example, the trigger event may indicate that event data250is to be collected whenever a brake pedal of the vehicle100is activated to a specified degree and at a certain rate so that emergency braking events can be collected. As a further example, the trigger event can specify a geographic area (e.g., bounding box specified by GPS coordinates), a particular roadway feature (e.g., stop sign, traffic light), a particular relationship with nearby objects (e.g., following another vehicle at certain speed, driving alongside another vehicle), a particular timeframe (e.g., rush hour, night or low-light conditions, etc.), or other conditions. In general, defining the trigger event can encompass any conditions occurring in relation to the vehicle100that are detectable by the filter module230through available electronic data/signals.

In either case, the filter module230monitors for the trigger event by, for example, scanning a data stream for information matching an occurrence of the trigger event. That is, in one embodiment, the filter module230monitors one or more data buses, interprocess communications channels, interrupt requests, registers, or other electronic sources to identify data that is indicative of the occurrence of the trigger event. The filter module230can continuously monitor for the trigger event and, once detected, can proceed to collect event data250as discussed at block350.

Furthermore, because a timing of when the trigger event will occur is unknown, the filter module230, in one embodiment, buffers data that matches the content parameter continuously even though the trigger event has not been detected. The filter module230continuously buffers the data in order to capture data from a time just before the trigger event. That is, for example, the filter module230can cycle data matching the content parameter through an incident buffer. In one embodiment, the filter module230stores this preliminary data from the vehicle100prior to detection of the trigger event for a defined period of time (e.g., one minute). Accordingly, the incident buffer can be a first-in first-out buffer that releases preliminary data older than the defined period while adding newly detected event data250. In this way, event data250is continuously cycled through the incident buffer and upon detecting the trigger event at340, event data250from before the occurrence of the trigger event is preserved so that a prior state can be reported along with data collected at350.

At350, the filter module230collects event data250from the vehicle100. In one embodiment, the filter module230collects the event data250from one or more vehicle systems140including the sensor system120. That is, upon detecting the occurrence of the trigger event, the filter module230collects data that matches the content parameters in a log, register, or other temporary storage. By way of example, when the trigger event is defined as an emergency braking event, the content parameter may specify to collect data about a trajectory of the vehicle100, a location of the vehicle100, the presence of other vehicles, a current state of the autonomous driving module160, and so on. Thus, the filter module230can collect data from telemetry systems of the vehicle100about current accelerator positions, steering wheel angles, data from a GPS about a current location, data from the LIDAR124and the radar123about nearby objects such as other vehicles, data from the autonomous driving module160about current decision and planning states, and so on.

Moreover, in one embodiment, the filter module230can activate one or more sensors of the sensor system120to acquire additional information that may not otherwise be generated by the vehicle100. For example, if the camera126is not presently active, then the filter module230can activate the camera to obtain additional data. Additionally, in an instance when the vehicle100is parked and turned off, the filter module230may activate a camera to obtain images of any nearby objects and so on. As another example, if the filter module230detects a high power draw when the vehicle100is in an off state, then the filter module230can activate one or more sensors to identify a source of the power draw. Furthermore, nominal data, which is characterized as interprocess communications, routine state information, and/or debugging information can also be collected. As a general matter, in one embodiment, any data that is accessible by the filter module230can be collected at350so long as the data matches the content parameter.

Additionally, it should be noted that while the filter module230is generally discussed as collecting data at350by copying or otherwise storing data that matches the content parameters, one aspect of the collecting at350is to discard or otherwise not store data that does not match the content parameter. Because storing all available data without regard to whether the data matches the content parameters can overflow allocated storage and/or generally complicate collection of the desired event data250, extraneous data that does not match the content parameters is discarded or simply ignored. In this way, the filter module230can isolate desired data to selectively collect the event data250while avoiding collecting excessive information that complicates determining which data is relevant to the collection request.

At360, the filter module230stores the event data250. In one embodiment, the filter module230stores collected event data250in a local memory (e.g., memory210or database240). For example, in one embodiment, the filter module230can initially store event data in a buffer or temporary register and then transfer the event data250to a non-volatile memory to, for example, protect against losing the event data should a power failure occur. Moreover, as part of storing the event data250as discussed at block360, the filter module230can format the event data250at360. For example, the filter module230can format the event data250into a standardized or defined format using XML or another markup language to annotate the event data250. Additionally, the filter module230can compress or otherwise prepare the event data250to minimize bandwidth when communicating the collected data250subsequently.

At370, the communication module220provides the event data250to fulfill the collection request. In one embodiment, the communication module220wirelessly communicates the event data250using a same connection from which the collection request was received. Thus, the communication module220can communicate the event data250to the remote server from which the collection request was received.

Additionally, in one embodiment, the communication module220communicates the event data250according to a termination parameter that specifies when to stop collecting the event data for the trigger event. For example, the communication module220can communicate the event data250after a period of time designated by the termination parameter, according to a quantity of the event data250that has been collected, when a communication connection (e.g., wifi) is available, or according to another suitable termination parameter. In either case, the communication module220generally provides the event data250to an OEM or other requesting source which, for example, aggregates event data from a plurality of vehicles. Thus, the requesting source can accumulate data that has been collected according to the defined parameters from the plurality of vehicles in order to generate a specific data set to, for example, train a machine learning algorithm or otherwise analyze particular aspects of specific events. Consequently, the specified event data250is selectively collected without complications from storing extraneous data.

As a further example,FIG. 4illustrates a schematic of an intersection400that is a four-way stop. As illustrated, a central source410, which is an OEM or other requesting entity, can provide a collection request wirelessly to the vehicle100. Moreover, the central source410may also provide the same or a similar collection request to vehicles420and430. Thus, the requesting entity410can cause a plurality of vehicles to selectively collect event data in order to aggregate information about a particular set of defined parameters instead of, for example, attempting to locate the same event data among a large data set. That is, the collection request provides the entity410with a mechanism to acquire targeted data without a need to search through or otherwise delineate a relevancy of data that is mixed together in a large data set.

Moreover, the entity410can provide the collection request in different formats according to, in one embodiment, configurations of the particular vehicles. That is, because of differences in capabilities between vehicles as a result of different manufacture dates, different available sensors, different included systems, and so on, the entity410can provide the collection request in a form that is suited to the particular vehicle. As one example, the entity can provide a first collection request to the vehicle420using a defined XML document format with the defined parameters populating annotated fields. By contrast, the entity410can provides a second collection request to the vehicle430as a self-extracting segment of code that when executed by the vehicle430populates various filters and/or a filter module230with the defined parameters. In either case, the collection request is provided by the central entity410either directly or through a distributed network of remote servers to inform the various vehicles about which data to collect.

Continuing with the discussion ofFIG. 4, when the vehicle100receives the collection request, the communication module220configures the various filters and other collecting components of the vehicle100so that event data is collected according to the collection request. For purposes of illustration, consider that the collection request specifies a trigger event being the vehicle100encountering a four-way stop. In various embodiments, the trigger event can be specified in several different ways. For example, the collection request may specify a particular four-way stop (e.g., intersection400) using GPS coordinates, may specify a set of four-way stops using a list of GPS coordinates, may specify a type of intersection generically, and so on. Moreover, the collection request may specify particular additional attributes as part of the trigger event such as a presence of other vehicles, time of day and so on.

Accordingly, as the vehicle100approaches the intersection400, the filter module230detects the intersection400using vision, GPS coordinates, or another means. Furthermore, if specified, the filter module230can also detect the presence of vehicles420and430as a factor for determining whether the trigger event is satisfied. Thus, upon the occurrence of the trigger event in relation to the intersection400, the filter module230initiates collection of the event data250according to the content parameter. As an example in relation to the intersection400, the filter module230can collect point cloud data from the LIDAR sensor124(e.g., object tracks and classifications), radar data from the radar sensor123, telemetry data, brake pedal data, steering wheel data, accelerator pedal data, and so on. In general, as previously indicated, the data collected by the filter module230can be any data that is accessible to the filter module230and as specified by the content parameters from the collection request.

In either case, the filter module230collects the event data as the vehicle100travels through the intersection400. In one embodiment, the vehicle100ceases collecting the event data250according to a termination event such as when the vehicle100exits an area proximate to the intersection400. Thereafter, the communication module220can communicate the event data250back to the central entity410using the same connection on which the collection request was received. Alternatively, the vehicle100may store the event data250until connected via a physical cable, when connected to a home WIFI, until the event data250is downloaded to a removable storage device (e.g., flash drive) and so on. In either case, the event data250is provided back to a remote server of the entity410so that the event data250can be further used by the entity410. In this way, collection of data from an auto is improved to avoid large data sets that include extraneous information.

FIG. 1will now be discussed in full detail as an example environment within which the system and methods disclosed herein may operate. In some instances, the vehicle100is configured to switch selectively between an autonomous mode, one or more semi-autonomous operational modes, and/or a manual mode. Such switching can be implemented in a suitable manner, now known or later developed. “Manual mode” means that all of or a majority of the navigation and/or maneuvering of the vehicle is performed according to inputs received from a user (e.g., human driver). In one or more arrangements, the vehicle100can be a conventional vehicle that is configured to operate in only a manual mode.

In one or more arrangement, the map data116can include one or more terrain maps117. The terrain map(s)117can include information about the ground, terrain, roads, surfaces, and/or other features of one or more geographic areas. The terrain map(s)117can include elevation data in the one or more geographic areas. The map data116can be high quality and/or highly detailed. The terrain map(s)117can define one or more ground surfaces, which can include paved roads, unpaved roads, land, and other things that define a ground surface.

As an example, in one or more arrangements, the sensor system120can include one or more radar sensors123, one or more LIDAR sensors124, one or more sonar sensors125, and/or one or more cameras126. In one or more arrangements, the one or more cameras126can be high dynamic range (HDR) cameras or infrared (IR) cameras.

The vehicle100can include an input system130. An “input system” includes any device, component, system, element or arrangement or groups thereof that enable information/data to be entered into a machine. The input system130can receive an input from a vehicle passenger (e.g. a driver or a passenger). The vehicle100can include an output system135. An “output system” includes any device, component, or arrangement or groups thereof that enable information/data to be presented to a vehicle passenger (e.g. a person, a vehicle passenger, etc.).

The processor(s)110, the collection system170, and/or the autonomous driving module(s)160may be operable to control the navigation and/or maneuvering of the vehicle100by controlling one or more of the vehicle systems140and/or components thereof. For instance, when operating in an autonomous mode, the processor(s)110, the collection system170, and/or the autonomous driving module(s)160can control the direction and/or speed of the vehicle100. The processor(s)110, the collection system170, and/or the autonomous driving module(s)160can cause the vehicle100to accelerate (e.g., by increasing the supply of fuel provided to the engine), decelerate (e.g., by decreasing the supply of fuel to the engine and/or by applying brakes) and/or change direction (e.g., by turning the front two wheels). In one embodiment, the collection system170can collect data about control signals from the processor100and the autonomous driving module160that cause the vehicle to accelerate, decelerate, and perform other various maneuvers and/or why the autonomous driving module160induced the maneuvers. As used herein, “cause” or “causing” means to make, force, compel, direct, command, instruct, and/or enable an event or action to occur or at least be in a state where such event or action may occur, either in a direct or indirect manner.