Systems and methods for implementing dynamic vehicle data extraction services

Abstract

A system including one or more computing devices implements a vehicle information extraction service. The vehicle information extraction service enables a customer to optimize the amount of relevant vehicle sensor information extracted from a vehicle by reducing instances of redundant data collection. The vehicle information extraction service additionally or alternatively enables a customer to maintain a model of a fleet of vehicles, determine the number of vehicles in the fleet in a particular section, and calculate a data reduction factor to filter out sensor data. The vehicle information extraction service communicates the reduction factor to vehicles in a geographic region using a vehicle scheme to indicate to the vehicles the probability that the vehicles will transmit a particular type of sensor data.

Description

[Background technology]

[0001] Modern vehicles, such as cars, trucks, and motorcycles, are often manufactured with electronic sensors and include computer systems programmed with control algorithms that receive input from these sensors and determine various control actions to be taken for the vehicle or its systems. Some vehicles may contain as many as 70 such electronic control units (ECUs) and 20–30 sensor modalities. Furthermore, modern vehicles are increasingly dependent on sensors that generate more data than previous vehicles. For example, autonomous, semi-autonomous, or self-driving vehicles may include multiple cameras, radar, LIDAR sensors, and audio microphones. These sensors can generate large amounts of data, such as 5–10 terabytes per hour. Sending such large amounts of data to another service for data analysis presents significant challenges.

[0002] Additionally, the vehicle information may be in a format that must be decoded or that requires vehicle-specific configuration information to be accessed. For example, the format in which the vehicles communicate may be specific to the vehicle manufacturer, and different on-board communication formats may need to be decoded depending on the configuration of those manufacturers. Furthermore, with a heterogeneous fleet of vehicles that utilize different signaling formats, a common method of collecting data for the fleet cannot be used without taking into account the different signaling formats and on-board configurations. [Brief explanation of the drawings]

[0003] [Figure 1] Some embodiments illustrate a vehicle information extraction service that associates multiple decoder rules for different on-board communication signal configurations with a vehicle model configuration, thereby enabling vehicles with different sensor signal formats to be configured into a single fleet of vehicles and used for data collection and analysis, and / or extracting information from each vehicle based on the fleet's partition, the number of vehicles in the partition, and inferences about objects in the vehicle's environment determined based on previously collected vehicle information. [Figure 2] 1 illustrates a more detailed view of a vehicle information extraction service, its various parts, and interactions that separate vehicle model configuration from vehicle-specific on-board communication signal configuration, according to some embodiments. [Figure 3] FIG. 1 illustrates a graphical representation of an exemplary vehicle model configuration having a hierarchical tree structure that uses a vehicle signal catalog to enable the use of unified signal representations when collecting data using a common data collection scheme across a heterogeneous fleet of vehicle models, according to some embodiments. [Figure 4] 1 illustrates a more detailed view of the designer canvas and management console of the service user interface for the vehicle information extraction service, according to some embodiments. [Figure 5A] In some embodiments, a dynamic vehicle data extraction service is used to determine a data reduction factor and apply it to the information extracted from the vehicles in the fleet, where the dynamic vehicle data extraction service shows a more detailed view of the vehicle fleet that optimizes the amount of data extracted based on the vehicle environment, vehicle movement, and changes in vehicle density at various times due to different segments. [Figure 5B] 1 illustrates a dynamic vehicle data extraction service that applies dynamic data reduction for multiple non-uniform segments based on similarity of vehicle movement patterns, according to some embodiments. [Figure 5C] 1 illustrates a dynamic vehicle data extraction service that applies dynamic data reduction to multiple, non-uniform sections of overlapping areas at different elevations based on the vehicle environment or other environmental factors, according to some embodiments, to determine overlapping sections. [Figure 6] FIG. 1 illustrates a logical block diagram illustrating various components of a vehicle data extraction service, their interactions with vehicle movement, and the effect of vehicle movement on the respective probabilities of data extraction, according to some embodiments. [Figure 7]1 illustrates a flowchart of operations performed by a vehicle information extraction service regarding a vehicle transition from one section to another, according to some embodiments, illustrating operations for determining whether updated probabilities and / or data reduction factors for data extraction should be sent. [Figure 8] 1 illustrates an exemplary map used by a vehicle data extraction service that divides a map into geographic regions, draws boundaries for multiple parcels, and allows for varying resolution of the boundaries to vary the granularity and / or number of vehicles per region, according to some embodiments. [Figure 9] 10 illustrates the effect of changing the resolution of a sample map of a vehicle data extraction service that divides the map into gridded regions and defines the boundaries of the regions, according to some embodiments. [Figure 10] FIG. 1 illustrates a more detailed view of an in-vehicle communication configuration of an exemplary network stack of protocols used at different levels to communicate vehicle information over the vehicle's bus, according to some embodiments. [Figure 11] 1 illustrates an exemplary vehicle with multiple different buses that may be monitored for data extraction by a software application deployed by a vehicle information extraction service, according to some embodiments. [Figure 12] 1 shows a more detailed view of a storage buffer that may be used by an application deployed by a vehicle information extraction service, according to some embodiments, where the storage buffer applies a data reduction factor and stores data from one or more prior moments that are eligible for extraction when one or more trigger criteria are met. [Figure 13] 1 illustrates a flowchart of operations performed by a vehicle information extraction service that applies data reduction to an amount of information extracted from a fleet of vehicles based, among other things, on segment criteria and the number of vehicles in the fleet on the segment, according to some embodiments. [Figure 14]1 illustrates a flowchart for implementing a modeling system in a vehicle information extraction service that enables generating a unified model for a fleet of vehicles and automatically accounting for variations in on-board communication configurations to collect requested information specified in the model from a heterogeneous fleet of vehicles, according to some embodiments. [Figure 15] 1 shows a block diagram illustrating an exemplary computer system that may implement some or all of the techniques described herein, according to some embodiments. DETAILED DESCRIPTION OF THE INVENTION

[0004] While embodiments are described herein by way of example in several embodiments and illustrative drawings, those skilled in the art will recognize that the embodiments are not limited to the described embodiments or drawings. The drawings and detailed description thereof are not intended to limit the embodiments to the particular forms disclosed; on the contrary, the intent is to cover all modifications, equivalents, and alternatives falling within the spirit and scope defined by the appended claims. The headings used herein are for organizational purposes only and are not meant to be used to limit the scope of the description and claims. As used throughout this application, the term "may" is used in the permissive sense (i.e., meaning having the potential to), rather than in the required sense (i.e., meaning necessary). Similarly, the terms "include," "including," and "includes" mean including, but not limited to,

[0005] Systems and methods described herein include techniques for implementing a vehicle information extraction service and for implementing on-board data monitoring and extraction using software packages generated by the vehicle information extraction service. As modern vehicles, such as cars, trucks, and motorcycles, become more sophisticated, they are increasingly equipped with electronic sensors used for a variety of purposes, from improving vehicle fuel efficiency to increasing degrees of automation using artificial intelligence (AI). With each new vehicle generation, vehicles are generating exponentially more data, and they are beginning to differentiate from each other not only mechanically but also increasingly through software. Furthermore, the fastest-growing trends in the automotive industry often involve autonomous vehicle (AV), advanced driver assistance systems (ADAS), and electric vehicle technologies, all of which employ various sensors that frequently generate more than 2 terabytes (TB) of data per hour. Furthermore, the types of sensors increasingly relied upon often generate large amounts of data. For example, modern vehicles increasingly rely on multiple high-resolution cameras, with a single high-resolution camera capable of generating data at rates exceeding 3,500 megabits per second. Despite advances in wireless technology, such as the fifth-generation (5G) technology standard for broadband cellular networks, the sheer number of vehicles, each equipped with an increasing number of sensors, creates significant limitations on bandwidth for transmitting vehicle data. Furthermore, the law of diminishing returns often applies to such large-scale data collection, with each additional byte of collected sensor information being less valuable than the previous byte—a reduction in value that translates directly to waste in vehicles where there are cost barriers to transferring information from the vehicle to a remote service. However, continuous collection of vehicle data may be necessary not only for operations but also to continue building and improving vehicle models. However, reducing the associated redundant data reduces the cost of transporting and / or storing collected vehicle data. Because vehicles are not stationary and frequently change location, optimizing data transmission at a single vehicle edge device may not be sufficient and optimization at the fleet level may be necessary.

[0006] Optimization of data collection at edge devices of a fleet of vehicles may be achieved by considering the collected data as collected from the entire fleet of vehicles, rather than from individual vehicles. In the real world, vehicles often travel in platoons or waves, interacting with many aspects of a structured and unchanging environment, resulting in sensors from the vehicles (e.g., platoons or waves) acquiring data that is frequently redundant. In some embodiments, a platoon or wave of vehicles may refer to vehicles that share a common characteristic. For example, during morning rush hour, a series of vehicles traveling in a series of lanes heading in the same direction on a highway may travel together as a vehicle platoon. As another example, a series of vehicles accelerating from a stopped position in response to a red light turning green may travel together as a vehicle wave. When considered as part of a platoon or wave of vehicles, many sets of sensor data collected from the vehicles may be estimated to be redundant, and a significant amount of this vehicle sensor data may be omitted from transmission to a data processing service to avoid redundant data collection. This data reduction may reduce the strain on network bandwidth used by vehicles to report collected vehicle information and may reduce resources required for storing and processing sensor data. For example, a platoon or wave of vehicles at or around the same geographic location and time period may each detect similar temperatures with their temperature sensors. The temperature data may be assumed to be redundant, and the data extraction service may only require a subset of vehicles in the platoon or wave to transmit temperature data. This optimization of vehicle data collection may be extended to other types of sensors, such as various ECU sensors, image sensors, etc. In some embodiments, the vehicle fleet to which data collection applies may be specified by the customer and may include heterogeneous vehicle types. In some embodiments, the fleet may be defined based on criteria associated with the vehicles, such as "make," "model," etc. In some embodiments, the fleet membership may be adjusted as more makes or models are added or removed from the fleet.

[0007] In some embodiments, the geographic location of the vehicle may be determined in various ways. For example, in some embodiments, a global positioning system (GPS) may be used, or a global navigation satellite system (GNSS) may be used. Also, in some embodiments, the vehicle may determine or update its location using local sensors and / or algorithms, such as using computer vision, LIDAR, vehicle odometry, etc. In some embodiments, the disclosed system may function properly without requiring specific location accuracy. For example, segments may be formed based on the location of other vehicles or objects and function properly even if actual location accuracy is not achieved by the system providing the vehicle's location information.

[0008] For example, a platoon or wave of vehicles traveling along a road may encounter many of the same or similar environmental objects, resulting in the acquisition of photographs that may be considered redundant. Furthermore, any vehicles exhibiting similar movement patterns or encountering similar environmental factors may be expected to return a large amount of redundant data. The vehicle information extraction service may use aggregated data from various sources, including images or other information acquired by the fleet, to make inferences about the environment and calculate the likelihood that a vehicle in a particular segment of the vehicle will return redundant data. To reduce the number of redundant data returned, a model of the fleet may be generated and the density of vehicles in the fleet in that segment may be obtained to determine a reduction factor. This reduction factor may be communicated to the vehicle using a vehicle scheme packet. The vehicle scheme packet may indicate to a given vehicle the probability that the given vehicle will transmit a particular type of sensor data. The reduction factor / probability that a given type of sensor data will be transmitted may differ between various types of sensors on a given vehicle and / or between different vehicles belonging to different fleets. In some embodiments, a customer of a dynamic data extraction service may desire to collect data from a fleet of vehicles that the customer drives or manages. Additionally, in some embodiments, groups of vehicles may belong to different segments, which in some embodiments may be determined based on the platoon-like or wave-like behavior of each vehicle in the group and / or other vehicles in other groups participating in the dynamic data reduction and / or vehicle data extraction service.

[0009] Vehicle data extraction services that enable modeling, collection, and storage of data for fleets of vehicles configured with various in-vehicle communication formats can enable additional flexibility and functionality in data collection. One challenge in extracting vehicle data from a customer fleet arises from different models of vehicles having different in-vehicle communication formats, creating barriers to vehicle data collection, model generation, and analysis. For example, in one vehicle, speed information may be available on a vehicle model where the vehicle's engine control unit (ECU) is connected via a connected area network (CAN) bus, while in another vehicle, speed information may be available on a different model where the ECU is connected via Ethernet. In some embodiments, the disclosed vehicle data extraction service overcomes this challenge by separating vehicle model configuration from the in-vehicle communication signal configuration specific to each individual vehicle.

[0010] Furthermore, separating vehicle model configuration from onboard communication signal configuration specific to individual vehicles allows different users to work independently on different parts of the model and allows for the use of unified signal representations across a heterogeneous fleet of vehicle models. For example, separating the vehicle's signal format, represented by the model configuration, from the onboard communication signal configuration, represented by the decoder rules for each type of vehicle, allows a single analysis application, regardless of vehicle model, to be used, which may have different decoder rules. As used herein, "decoder rules" include any rules involved in decoding signals and may be used interchangeably with "decoding rules" and / or "signal decoding rules." Furthermore, a single workflow executed to apply a data collection configuration, which defines rules regarding when and how to collect data from vehicles, may be executed across a heterogeneous fleet of vehicle models within such a service.

[0011] 1 illustrates a vehicle information extraction service, according to some embodiments, that associates multiple decoder rules with different on-board communication signal configurations with a vehicle model configuration, thereby enabling vehicles with different sensor signal formats to be configured into a single vehicle fleet and used for data collection and analysis, and / or extracting information from each vehicle based on inferences based on the fleet's partition, the number of vehicles in the partition, and the vehicle environment. Extraction based on partition, vehicle number, and / or vehicle environment may enable dynamic data reduction to be applied to collected data, such that redundant data collection is reduced.

[0012] System 100 includes a vehicle information extraction service 102 and a network 116 connected to vehicles 142, 143, and 144. Vehicles 142, 143, and 144 may be included in a single fleet, but they may be configured using heterogeneous vehicle signal formats. In some embodiments, network 116 may be connected to any number of vehicles, and the heterogeneity of the fleet may result from vehicles belonging to different original equipment manufacturers (OEMs). In other embodiments, the vehicles may have a uniform vehicle signal format. Additionally, customers 122a-122n are connected to the vehicle information extraction service via network 116. In some embodiments, customers 122a-122n may be vehicle suppliers or vehicle component suppliers (e.g., vehicle original equipment manufacturers (OEMs) and / or suppliers of row 1, row 2, or row 3 parts). Network 116 may be a direct connection to a service provider network hosting vehicle information extraction service 102, or a private or public network, such as an Internet connection. Additionally, the network 116 may be a wireless network, such as a cellular network, a Wi-Fi network, or other wireless network.

[0013] In some embodiments, the vehicle information extraction service 102 may include a control plane 104, data storage 114, and a data plane 112, as further described in FIG. 3 . The control plane 104 enables customers 122a, 122n to register vehicles, model vehicles, and manage data collection workflows for a single vehicle or across a fleet of vehicles. The data plane 112 serves as a processing pipeline for raw vehicle data ingestion, data decoding, and vehicle data storage and / or retrieval. In some embodiments, the various components of the vehicle information extraction service 102 may be further divided into various subsystems having distributed and / or decoupled formats to independently manage the scalability and throughput requirements of the subsystems. The data plane 112 may further decode and enrich the extracted vehicle data 148 obtained from the vehicles 142, 143, 144 using configurations, such as various vehicle model configurations and decoder rules, maintained by the control plane 104. In some embodiments, the vehicle information extraction service 102 and various subsystems therein may be separated and maintained in different environments to prevent the data plane 112 from overwhelming the control plane 104 with sudden bursts of traffic in events such as recovery from a power outage or processing error. Customers 122a, 122n interact with the control plane 104 through extraction service requests 118, 120 to perform vehicle modeling, vehicle sensor testing, vehicle asset registration, vehicle fleet definition, and data collection scheme management.

[0014] In some embodiments, the control plane 104 may include a vehicle identification registry 110, a data collection scheme controller 108, and a service user interface 106 for executing extraction service requests 118. The service user interface 106 may include a designer canvas and an administration console, as further described in FIG. 4 . In some embodiments, a customer (e.g., a vehicle supplier and / or vehicle component supplier) may provide a dictionary file describing proprietary protocols and encoding formats used to communicate vehicle information over the bus from components designed by the customer, and / or an associated proprietary access credentials file. For example, a customer 122a, 122n may submit extraction service requests 118, 120 that include decoder rules used to decode raw vehicle data into physical measurements; e.g., a CAN database (CAN DBC) can be used to decode raw data from a vehicle's CAN bus frame into physical signals such as engine speed, radar amplitude, etc. In some embodiments, the extraction service requests 118, 120 may include a data collection scheme that defines rules for collecting data from a fleet of vehicles. The data collection scheme indicates the extraction criteria for vehicle sensor information (also referred to herein as "data extraction criteria") and may define rules governing data reduction and / or collection optimization through the reduction of redundant data, as further described in Figures 5A-5C. Note that the data collection scheme, including the decoder rules and extraction criteria, is shown in Figure 1 as part of the same system. However, in some embodiments, the decoder rules and the data collection scheme may be used separately.

[0015] In some embodiments, the vehicle identification registry 110 of the control plane 104 may provide a create, read, update, and delete (CRUD) application programming interface (API) for managing a registry of vehicle identities in a fleet. The vehicle identification registry 110 may store key-value records with the vehicle's identity (vehicle ID) as the key and tuples of vehicle make, vehicle model, and other vehicle attributes as values, such as location, build date, engine type, and fuel type. Vehicle models generated using modeling services may also be associated in a similar tuple format. The vehicle identification registry 110 may facilitate changes of ownership as well as the rotation and revocation of vehicle identification certificates. In other embodiments, customers 122a, 122n may use their own certificate authorities (CAs) to onboard fleet vehicles 142, 143, 144 and manage the rotation and revocation of vehicle identification certificates. In some embodiments, the control planes 104, 110 may authenticate certificates signed by the customer's CA. The vehicle identification registry 110 may further facilitate grouping of vehicles into fleets based on various criteria as specified by fleet rules provided by the customers 122a, 122n. A fleet rule may use any number and / or combination of vehicle attributes to group vehicles together. For example, a fleet rule may create a fleet of all vehicles within a particular geographic area, such as a city or state, or create a fleet targeted to a particular vehicle make and model. The vehicle identification registry 110 maintains all of the state of the various fleets as vehicles are added, removed, or updated in the fleet.

[0016] In some embodiments, the data collection scheme controller 108 may enable a customer 122a, 122n to define and manage data collection schemes for a single vehicle or a fleet of vehicles and to manage the conditions under which various vehicle data is transmitted from the on-board computing device(s) 150. The data collection scheme controller 108 generates a data collection scheme packet that includes a vehicle configuration 146 that defines the rules used by the vehicles 142, 143, 144 to determine when, where, and how to transmit various information collected by their various sensors. The data collection scheme controller 108 then validates the schemes against the vehicle's model configuration and resolves conflicts between schemes based on customer-defined priorities. If a vehicle scheme is determined to apply to a fleet, the data collection scheme controller 108 may apply the scheme to the specified fleet of vehicles in conjunction with the vehicle communication interface 180. In some embodiments, details of a data reduction factor for reducing redundant data may be determined by the customer 122a, 122n and applied to the vehicle scheme using the data collection scheme controller 108. In some embodiments, the data collection scheme controller 108 applies rate control to safely propagate the scheme throughout the fleet without errors due to increased propagation speed. Errors may be detected by monitoring health metrics exposed by the onboard computing device(s) 150 and / or by monitoring active vehicle connections between the vehicles 142, 143, 144 and the vehicle communication interface 180. In some embodiments, the data collection scheme may define customized rules for filtering data (e.g., performing data reduction) at the onboard computing device(s) 150 based on vehicle attributes, such as the vehicle's engine type and other vehicle model parameters / attributes. In some embodiments, the vehicle scheme packet may further specify the frequency (e.g., every 5 minutes), schedule or period (e.g., 20 minutes from the current time) at which one or more sensor data are transmitted, and a trigger event (e.g., a threshold vehicle braking speed or a vehicle's departure from its lane).In some embodiments, the trigger event is a heartbeat and data propagation may occur continuously at a regular rhythm.

[0017] In some embodiments, decoder rules may be sent to the vehicle via a vehicle scheme packet and / or via a separate manifest / configuration. The decoder rules provide the parameters required to decode the sensor data, such as the protocol name, bus standard (e.g., the CAN bus standard), message ID for messages the sensor is multiplexed into, scale, offset, etc.

[0018] In some embodiments, the decoder rules may be used by the vehicle information extraction service 102 to decode desired signals at a remote location, such as a cloud-based implementation. In other embodiments, the decoder rules may be applied at the onboard computing device 150 of a vehicle (or other vehicle edge device) rather than at the vehicle information extraction service 102, and the decoded signals may be sent to the vehicle information extraction service 102. In some embodiments, the desired fleet of vehicles may include heterogeneous types of vehicles, and the model configuration may include multiple decoder rules (where the rules for decoding are different for each heterogeneous type). For example, decoder rule A 162, decoder rule B 163, and decoder rule C 164 may be sent to each vehicle 142, 143, 144, each with different signal semantics. In some embodiments, each set of decoder rules provides decoding rules for all signals in the model configuration. The model configuration and decoder rules may have a one-to-many relationship, where multiple decoder rules (e.g., decoder rule A 162, decoder rule B 163, and decoder rule C 164) may be associated with a single model configuration. This one-to-many relationship allows the same signal semantics to be used for data collection and analysis regardless of the in-vehicle network topology and / or technology used in a given fleet of vehicles.

[0019] In some embodiments, the data collection scheme controller 108 may manage a signal catalog. The signal catalog may contain signal attributes that an OEM uses across multiple models of vehicles or sensors. The signal catalog may follow the Vehicle Signal Specification (VSS) naming guide and may be accessible using a qualified name (e.g., Vehicle.Powertrain.CombustionEngine.FuelType). There may be one unique path per signal in the signal catalog, and in some embodiments, the data collection scheme controller 108 may assign a unique signal ID to the signal. The data collection scheme controller 108 in the data plane 104 may ensure that signal IDs are unique across the signal catalog. In some embodiments, a customer 122a, 122n may create multiple signal catalogs. Multiple signal catalogs may contain signal attributes that can be used to model different types of vehicles. For example, a customer may create a catalog for cars, a catalog for trucks, a catalog for motorcycles, etc. While the same vehicle type may have a single catalog representing all signals of that vehicle type, in some embodiments, multiple signal catalogs may be used to represent different subsets of signals for the same vehicle type. The term "subset," as used herein, is not limited to attributes of one vehicle type, but may include one, all, or any number of attributes of any number of types. Additionally, as used herein, a "subset" may include all attributes of a given vehicle type, or only a portion of the available attributes of a given vehicle type. As further described in FIG. 2 , the data collection scheme controller 108 of the data plane 104 manages vehicle model configuration using signal catalogs and decoder rules to enable uniform signal representation for the vehicle data extraction service 102 to collect data across heterogeneous vehicles in a fleet through a workflow that applies the same data collection scheme when extracting data from heterogeneous vehicles in the fleet.

[0020] In some embodiments, data plane 112 manages the receipt of raw data from vehicles 142, 143, 144 and the distribution of various types of vehicle information, such as the vehicle's status and the vehicle compartment to which the vehicle belongs, to data storage 114, which information may be stored in vehicle status table 186 and vehicle compartment table 182, respectively. In-vehicle computing device(s) 150 may use data plane 112 to authenticate a connection with vehicle information extraction service 102 via client certificate authentication (e.g., an X.509 certificate) and a private key obtained when the vehicle is registered through vehicle identification registry 110. In some embodiments, data plane 112 includes a vehicle communication interface 180 configured to establish a secure connection with each vehicle, such as vehicles 142, 143, 144, to send software package 146 and receive extracted vehicle data 148. In some embodiments, the extracted raw data engine 184 may store the extracted vehicle data 148 in a separate storage account for the customer 122a, 122n, such as a storage account for a storage service offered by a provider network that also implements the vehicle information extraction service 102. For example, a customer may have accounts for various services offered by a service provider network that also offers the vehicle information extraction service. Thus, the customer may specify whether to deliver the extracted vehicle information to their account using a particular service of the service provider network, such as an object-based storage service, an archival data storage service, or a machine learning service. The vehicle partition engine 188 of the data plane 112 may use location information and / or other sensor information from the fleet to determine which partition of the fleet each vehicle is associated with. The vehicle partition engine 188 may use any number of types of information describing the environment in which the fleet is located to determine / infer similar vehicle movement patterns or similar environmental factors that may be assumed to result in redundant data collection. Such types of information may be used to divide the fleet. In some embodiments, partitions may be determined based on geographic location and / or other factors.In some embodiments, a segment may be determined using two dimensions: the spatial proximity of vehicles and the temporal proximity of the spatial proximity. More specifically, how recently or over what period of time the vehicles were in proximity to each other. For example, segments A and B may be determined based on their geographic proximity within a particular time frame.

[0021] In some embodiments, the segments of a fleet may be determined based on proximity to various inferences made about the environment. For example, vehicle segmentation engine 188 may use aggregated data from vehicles 142, 143, and 144 to determine that semantically identified object 192 is present in the environment with some frequency. Vehicle 143 may be assigned to segment C based on variables such as proximity to identified object 192 and / or frequency of occurrence of identified object 192, as well as location and time proximity to other vehicles. In some embodiments, a vehicle may be part of multiple segments of a fleet. For example, vehicle 143 may be part of segment A as well as segment C. Data collection probability engine 190 may then determine an appropriate data reduction factor to communicate to vehicles in a particular region through vehicle scheme packets. Data collection probability engine 190 may use various other inferences derived from the environment to calculate the likelihood that vehicles in a given segment are likely to return redundant data. In some embodiments, the inferences may include inferences drawn from a list of identified vehicle targets using machine learning techniques, target classification as stationary, semi-stationary, or dynamic, the presence of an accident, etc.

[0022] In some embodiments, a model may be generated by the data extraction service. The model may model the frequency of occurrence of a particular type of object in the environment in which data is collected / extracted from vehicles, along with a model of the probability that a given vehicle or vehicle type exhibiting common vehicle behaviors (such as platooning or wave movement) will encounter the object, along with temporal proximity, e.g., how soon a given vehicle is likely to encounter a particular object. Based on these model parameters, the data extraction service may generate a data reduction factor to be applied to vehicles belonging to each segment. In some embodiments, a segment may simply correspond to a geographic region. However, in the same or other embodiments, a segment may be based on both spatial and temporal dimensions. In some embodiments, a segment may be determined based on other factors. For example, a set of vehicles that are geographically close to each other, temporally close, and exhibit common vehicle behaviors, such as traveling at speeds that overlap the speed range of surrounding vehicles, may be grouped into a common segment. For example, such a segment may resemble a group of vehicles traveling closely together at the same speed on an interstate highway at the same time. In some embodiments, segments may be dynamically updated based on changes in vehicle behavior. As another example, in some embodiments, common vehicle behaviors used to group vehicles into common segments may be determined using an origin-destination (OD) matrix estimation process. For example, such an estimation process may be used to identify groups of vehicles traveling toward or between the same destination and group such vehicles into groups to form segments. In some embodiments, a data extraction service may estimate the origin-destination flow of vehicles between a set of points and send data reduction probabilities to the grouped vehicles, where the data reduction probabilities are determined based on the estimated trajectories of the vehicles and other factors described herein, such as the vehicle density within the segment and the prevalence of target objects in the environment through which the vehicles travel according to the determined trajectories.In some embodiments, if a currently updated model maintained on the service side of the vehicle data extraction service differs from a previous version of the model used to generate a scheme packet to be sent to the fleet of vehicles by more than one or more threshold amounts, a scheme packet may be issued to the vehicle reflecting data reduction parameters according to the updated model.

[0023] In some embodiments, the data plane 112 of the vehicle information extraction service 102 may further orchestrate analysis and / or visualization performed on the extracted vehicle data 148. For example, the extracted vehicle data may be compared to alarm triggers for alarms to be notified to the customer. The extracted vehicle information may also be organized into visual graphics, such as charts, graphs, or other user interface tools, for presentation to the customer. In some embodiments, the extracted vehicle information may be used to train artificial intelligence (AI) models or fed to machine learning tools to optimize vehicle settings. Once authenticated, the vehicles 142, 143, 144 may send data and transfer messages to the vehicle information extraction service 102 using various publish-subscribe or other network protocols, such as the MQTT protocol. In some embodiments, video frames captured using one or more video / audio sensors 132 may be transmitted using an encoded video format, such as Advanced Video Coding, also known as H.264. In some embodiments, the in-vehicle computing device(s) 150 may obtain temporary authentication information to upload various sensor data. The data plane 112 may directly ingest the extracted raw vehicle data 148, after which the extracted raw data engine 184 may use the vehicle model configuration to decode the extracted raw data into physical telemetry messages. In some embodiments, the extracted raw vehicle data may be a binary resource containing data such as video frames, images, radar amplitude, temperature data, engine speed, and other information about the vehicle. In some embodiments, the decoded telemetry data may be enriched with vehicle attributes and published to a time series database in data storage 114. Enriching the vehicle data by associating vehicle attributes allows users to query the vehicle data using vehicle and / or event of interest attributes. In some embodiments, a unique object URL may be associated with a record containing vehicle data and published to the time series database.

[0024] In some embodiments, the in-vehicle computing device 150 may implement a gateway for the vehicle 126 or may otherwise be a component of the vehicle 126 that has access to data transmitted over one or more buses of the vehicle, such as the vehicle communication bus 138. In some embodiments, the vehicle buses may transmit multicast vehicle information transmitted from multiple components of the vehicle, such as the electronic control unit 128 (ECU#1) and the electronic control unit 130 (ECU#2). Additionally, other components, such as the physical sensors 136 and the acoustic / visual sensors 132, may communicate vehicle information over the vehicle communication bus 138. The fleet of vehicles 142, 143, 144 may include one or more location sensors 131 that can obtain the vehicle's location. In some embodiments, the location sensor may be a global positioning system (GPS) using cellular, wireless passive, satellite, and other types of GPS systems. The location sensor 131 may obtain location information that is further processed by the location module 154 of the in-vehicle computing device 150 to determine the region in which the vehicle is currently located. This location information and / or other sensor information may be used to determine which segment of the fleet the vehicle falls into. The vehicle scheme package 146 may be used by a software application 152 executing on the on-board computing device 150 to control the vehicle 142 and determine conditions for transmitting its data. In some embodiments, the software application 152 may access binary file storage 154 to access vehicle information transmitted over the vehicle communication bus 138. In some embodiments, vehicle communications over the vehicle bus may be encoded by the software application 152, and the software application 152 may decode the vehicle information transmitted over the encoded vehicle communications using binary files and / or configuration files in the binary file storage. The bus traffic decoding and trigger monitoring module 156 may further store vehicle information, such as bus traffic and / or other vehicle information, such as visual or audio data, in a storage buffer 158.As described in more detail in FIG. 12, the storage buffer may store encoded and / or decoded vehicle information and other related vehicle data for multiple previous moments in time.

[0025] In some embodiments, trigger monitoring 160 provided by software application 152 monitors bus traffic to determine whether one or more trigger criteria for data extraction provided by a vehicle scheme packet are met to determine whether the trigger criteria are met. In some embodiments, the vehicle scheme packet may provide detection of movement to a new section and / or geographic area as one such trigger criteria. For example, in FIG. 1, movement of vehicle 142 from area A to area B may satisfy the trigger criteria. Software application 152 may further include a data reduction factor application 156 that retrieves one or more data reduction factors from the vehicle scheme packet to determine the rate at which particular sensor data should be acquired / collected for extraction after a trigger event. For example, if data reduction factor application 156 retrieves a data reduction factor and determines that the percentage of temperature sensor data to be transmitted upon fulfillment of a trigger is 50%, the temperature sensor data transmitted by the fleet is effectively reduced in half, for example, by reducing the frequency of transmitting temperature data. In some embodiments, location module 154 may use location sensor 131 to determine the location of vehicle 142. If the trigger criteria are met, the packet generation module of the in-vehicle computing device 150 may generate one or more packets that are sent back to the vehicle information extraction service 102 as raw extracted vehicle data 148.

[0026] The data plane 112 may directly ingest the extracted raw vehicle data 148, after which the extracted raw data engine 184 may use the vehicle model configuration to decode the extracted raw data into physical telemetry messages. In some embodiments, the extracted raw vehicle data may be a binary resource containing data such as video frames, images, radar amplitude, temperature data, engine speed, driver performance, and / or other information about the vehicle. In some embodiments, the decoded telemetry data may be enriched with vehicle attributes and published to a time series database in the data storage 114. Enriching the vehicle data may allow users to query the vehicle data using vehicle and / or event of interest attributes. In some embodiments, a unique object URL may be associated with a record containing vehicle data and published to the time series database.

[0027] In some embodiments, the service user interface 104 may include a designer canvas and an administration console, as further described in FIG. 2 . In some embodiments, a customer may provide a dictionary file describing proprietary protocols and encoding formats used to communicate vehicle information over the bus from components designed by the customer (e.g., vehicle suppliers and / or vehicle component suppliers), and / or an associated proprietary access credential file. For example, customer 122 a may provide a service request 118 that includes a vehicle supplier dictionary file and data extraction criteria for vehicle information formatted according to the vehicle supplier dictionary. Additionally, customer 122 n may provide a submission 120 that includes a separate component supplier dictionary file and data extraction criteria for vehicle information formatted according to the component supplier dictionary. Note that in FIG. 1 , the dictionary file and data extraction criteria are shown as part of the same submission. However, in some embodiments, the data extraction criteria and dictionary file may be submitted separately.

[0028] The dictionary files and associated access credential files received from customers 122a and 122n may be stored in restricted access dictionary and credential storage 106. The dictionary files / associated access credential files for customer 122a and the dictionary files / associated access credential files for customer 122n may each be stored in separate physical or logical containers with restricted access. For example, customer 122n may not be able to view customer 122a's dictionary files or access credential files, and vice versa.

[0029] FIG. 2 shows a more detailed view of the vehicle information extraction service, its various parts, and interactions that separate vehicle model configuration from vehicle-specific on-board communication signal configuration, according to some embodiments.

[0030] In FIG. 2 , a customer 122 may submit an extraction service request 118 to the service user interface 106 to create a model of a vehicle fleet. The extraction service request 118 includes information for the data collection scheme controller 108 to generate a signal catalog. The signal catalog may include all of the signal attributes that an OEM uses across all models of vehicles or sensors. In some embodiments, the signal catalog may include a subset of signals, which may include one or more signal attributes for various vehicle types in any combination. As described in FIG. 1 , the signal catalog may follow the Vehicle Signal Specification (VSS) naming guide and may only be accessible using a qualified name. In some embodiments, there may be only one unique path per signal in the signal catalog, and in some embodiments, the data collection scheme controller 108 may assign a unique signal ID to the signal. The data collection scheme controller 108 in the data plane 104 may ensure that the signal ID is unique across the entire signal catalog. In some embodiments, the customer 122 may create multiple signal catalogs, which may include signal attributes that may model different types of vehicles.

[0031] Once the signal catalog is generated, the data collection scheme controller 108 may generate a model configuration using information obtained from the extraction service request 118. A model configuration may be a collection of signals selected from the signal catalog that are applicable to that particular vehicle model. For example, the extraction service 112 may be provided with a sample signal catalog organized with a branch for cruise control, a branch for the internal combustion engine, and a branch for the electric engine. If generating a model configuration for a vehicle that has cruise control but uses an internal combustion engine, the configuration may include only the cruise control branch and the internal combustion engine branch, but not the electric engine branch. For another vehicle model that has an electric engine and cruise control, the model configuration may include the cruise control branch and the battery branch. In some embodiments, a model configuration may be created from all signals in the signal catalog. In some embodiments, if there are signals in the signal catalog that do not have a decoder rule, those signals are excluded from the model configuration. A vehicle model configuration may include only signals defined in the signal catalog. Figure 3 further illustrates a vehicle model configuration.

[0032] After a model configuration is created, decoder rules (e.g., decoder manifests or other configurations) for all vehicle sensors in the model configuration can be retrieved in response to an extraction service request 118. The decoder rules may specify rules for decoding signals of an in-vehicle communication network, allowing a customer to collect data from the sensors listed in the model configuration. For example, the decoder rules may include the CAN DBC for a particular vehicle model, additional protocol-specific information for decoding the in-vehicle signal format (e.g., the channel ID of the signal that results in the CAN DBC), and a mapping file that maps the signal names provided in the CAN DBC to the signal names provided in the model configuration. In some embodiments, given the signal names defined in the model configuration, the decoder rules may provide the parameters necessary to decode the information collected via the sensors, including the protocol name (e.g., CAN), message ID (for the message the sensor is multiplexed into), scale, offset, etc.

[0033] In some embodiments, the decoder rules may be used by the vehicle information extraction service 102 to decode the necessary signals remotely, such as at a cloud-based location. In other embodiments, the decoder rules may be sent to a software application 152 on the vehicle (or other vehicle edge device) and used by the software application to send the decoded signals to the vehicle information extraction service 102. In some embodiments, heterogeneous types of vehicles may exist, and if the rules for decoding differ between vehicle types, the model configuration may include multiple decoder rules. In some embodiments, each set of decoder rules provides a decoding rule for every signal in the model configuration. The model configuration and the decoder rules may have a one-to-many relationship, where multiple decoder rules may be associated with a single model configuration. This one-to-many relationship allows the same signal semantics to be used for data collection and analysis, regardless of the in-vehicle network topology and / or the technology used in the vehicles. Furthermore, this one-to-many relationship enables data collection across a heterogeneous fleet of vehicles using different signal formats. Once the decoder rules provide a decoding rule for every signal in the model configuration, the data collection scheme controller 108 generates the decoder rules and marks the model configuration as active.

[0034] In some embodiments, a customer network in a virtual private cloud (VPC) or on-premise network with access to the vehicle software application 152 and its gateway 201 deploys a private key and client certificate (e.g., an X.509 certificate) through the OEM fleet provisioning management 208. The fleet inventory engine 206 may further retrieve the deployed private key and certificate and synchronize the vehicle's dimensions, private key, and certificate with the vehicle identification registry 110. The service user interface 106 then registers the vehicle to be modeled by identifying the model configuration with which the vehicle is associated and the decoder rules with which the registered vehicle is associated. The service user interface 106 presents values ​​for static attributes present in the vehicle model configuration (e.g., vehicle identification number (VIN), model, year, color, etc.).

[0035] The vehicle identification registry 110 may create fleets as collections or groups of vehicles grouped together based on certain common vehicle attributes. Fleets may be created based on various vehicle attributes, such as vehicles manufactured in a particular year or range of years, vehicles with the color red, or vehicle fuel type. A customer 122 may instruct via the service user interface 106 to create a fleet based on attributes available in the traffic light catalog. In some embodiments, creating a fleet may include a fleet creation query or filtering activity based on multiple attributes to create the fleet. Once the fleet is created, the customer 122 may use the fleet to execute various workflows that apply various data collection schemes. In some embodiments, the vehicle identification registry 110 may automatically maintain and update the fleet without customer instruction as the collection of vehicles (grouped together based on common vehicle attributes) changes. In some embodiments, as new vehicles are registered, the vehicle identification registry 110 may automatically add the new vehicle to one or more fleets or vehicle blocks based on the identified common vehicle attributes.

[0036] The data collection scheme controller 108 may receive from the customer various data collection schemes or configurations that instruct the vehicles on what data to collect from the vehicles, when to collect the data, and how often to publish the data to the vehicle communication interface 180, as well as various other parameters, including a data reduction factor that limits vehicles in a fleet to transmitting only a certain percentage of the time based on the total number of vehicles in the same area. In some embodiments, the vehicle zone engine 188 may determine the data reduction factor using a data collection probability engine 190 that limits vehicles in a particular zone from transmitting data. When creating a data collection scheme, the OEM or customer 122 can specify a subset of signals from a signal catalog that they want to collect. In some embodiments, the customer 122 may specify either a vehicle ID or a fleet ID to which the data collection scheme will be sent. The vehicle communication interface 180 receives the data collection scheme and sends it to the selected vehicles or fleet.

[0037] In some embodiments, once data is collected from the vehicle's various sensors according to a data collection scheme, the resulting raw data stream is sent to the vehicle communication interface 180, which decodes the raw data using the extracted raw data engine 184. In some embodiments, the extracted raw data engine 184 may use a vehicle model configuration to decode the extracted raw data into physical telemetry messages, which may be accessible to the customer using the service user interface 106. In other embodiments, the collected data may be physical telemetry messages decoded by the vehicle (or other vehicle edge device) using decoder rules. In some embodiments, the extracted raw data stream may be a binary resource containing data such as video frames, images, radar amplitude, temperature data, engine speed, driver performance, and other information about the vehicle. In some embodiments, the decoded telemetry data (decoded using decoder rules by the vehicle information extraction service 102 or the vehicle's software application 152) may be enriched with vehicle attributes and published to a time-series database for data storage for analysis.

[0038] FIG. 3 illustrates a graphical representation of an exemplary vehicle model configuration having a hierarchical tree structure that uses a vehicle signal catalog and enables the use of unified signal representations when collecting data using a common data collection scheme across a heterogeneous fleet of vehicle models, according to some embodiments.

[0039] Vehicle model configuration 300 provides a serialized digital representation of vehicle attributes, sensors, actuators, and their relationships. Vehicle model configuration 300 provides the format necessary to represent the relationships between ECUs and sensors as a hierarchical model that reflects the domain-based format of modern vehicle network systems. For example, model configuration 300 includes all or a subset of the signal types in a signal catalog. The signals provided by the signal catalog may be arranged in a hierarchical structure as shown in model configuration 300 and may include various signal types, such as attributes, branches, sensors, and actuators. Model configuration enables the attachment of static attributes to ECUs and domains, such as “VIN” 306, “Model” 308, and “Brand” 330, which facilitates the creation of fleets based on the fleet rules described in FIG. 2 .

[0040] In some embodiments, the vehicle model configuration may be automatically generated from an Automotive Open Systems Format (AUTOSAR) XML configuration file, or an ArXML, CAN DBC, or Fieldbus Exchange Format (FibEx) file, or may be manually created by an OEM or designer. It can be further manipulated and updated after creation. In some embodiments, the model manifest may utilize the VSS format. The vehicle model configuration 300 may provide the format needed to represent the relationships between ECUs and sensors as a hierarchical model that reflects the domain-based format of modern vehicle network systems. For example, a query 352 for "Drivetrain.Transmission.Speed" in the vehicle model configuration 300 returns the associated type "sensor" for the signal "speed" 336 under "drivetrain" 332 and "transmission" 334. This allows customers to specify sensor units and data types needed for human-readable data exchange and the definition of sensor alarm rules.

[0041] FIG. 4 shows a more detailed view of the designer canvas and management console of the service user interface for the vehicle information extraction service, according to some embodiments.

[0042] In some embodiments, a service user interface of a vehicle information extraction service, such as service user interface 108, may include a designer canvas, such as designer canvas 402, and an administration console, such as administration console 410. In some embodiments, the designer canvas may allow customer engineers, such as engineers at a vehicle supplier or vehicle component supplier, to view a digital twin containing data extracted from real-world vehicles. Using the designer canvas may also allow engineers to modify the type of data monitored / extracted and / or trigger criteria for data extraction, including a data reduction factor based on the number of vehicles in a lot. In some embodiments, the designer canvas may allow customer engineers to log in to a web application using their own corporate credentials (e.g., credentials issued to them by a corporate customer) without requiring each engineer to have an account or credentials with the vehicle information extraction service. Using the web application, customer engineers may be able to access, visualize, and monitor vehicle data. The designer canvas may also allow customers to build custom reports or analyses or incorporate vehicle data into their existing software environments. In some embodiments, the web application provided by the vehicle information extraction service may be pre-configured or easily configurable without the customer having to generate code for the web application. In some embodiments, the management console for the vehicle information extraction service may provide additional functionality and may further enable customers to manage their accounts with the vehicle information extraction service, such as providing access to custom dictionaries, creating additional digital twins, etc.

[0043] In some embodiments, a designer canvas, such as designer canvas 402, includes a digital twin user interface 404, a fleet user interface 406, and a vehicle scheme user interface 408. The digital twin user interface 404 may allow a customer's engineers to view and interact with a digital twin of a given real-world vehicle, where the digital twin contains near-real-time vehicle information extracted from the real-world vehicle. The fleet user interface 406 may allow a customer's engineers to view and interface with a digital twin representing a class (or fleet) of vehicles. The fleet digital twin may contain aggregated data representing the near-real-time state of a vehicle class that matches the fleet definition for the fleet. The fleet digital twin may include twins of vehicles belonging to different OEMs and may have different on-board formats. The digital fleet twin may be generated by combining various on-board formats into a single fleet using a uniform vehicle signal format using vehicle decoder rules and vehicle model configurations. Additionally, the digital twin user interface 404 and the fleet user interface 406 may allow a customer's engineers to view and interact with historical data extracted from an actual vehicle or an actual fleet of vehicles. In some embodiments, designer canvas 402 may be used to create a digital twin for a vehicle before the real-world vehicle is built.

[0044] In some embodiments, designer canvas 402 may include a vehicle scheme user interface, such as vehicle scheme user interface 408. Vehicle scheme user interface 408 may enable a customer's engineer to provide / modify the types of vehicle information extracted from a vehicle or fleet of vehicles and the trigger criteria for extracting the vehicle information. For example, when troubleshooting a particular system, an engineer may modify the data extraction via the vehicle scheme to include additional types of vehicle information to extract, such as data from subcomponents of the system that require troubleshooting. Vehicle scheme user interface 408 may be used by a technician to determine the vehicle model configuration and respective decoder rules for the vehicle.

[0045] The management console 410 includes a data extraction service account management 412 that can be used to manage the customer's account, such as billing, contact information, etc. Additionally, the management console 410 includes a digital twin for vehicle interface 414 and a fleet digital twin interface 416. Customers can use these interfaces to approve the creation of additional digital twins for individual vehicles or fleets of vehicles. In some embodiments, a prompt in the designer canvas 402 can cause a request to be queued for approval by the customer, which then causes the digital twin interface 414 or fleet digital twin interface 416 to create the additional digital twin. The management console 410 includes a deployment interface 418 for the management console 410 that can deploy generated binary files to monitored vehicles. In some embodiments, a management console such as the management console 410 can further include a monitoring interface 420 for receiving and viewing extracted vehicle information. In some embodiments, the monitoring interface can also allow for the specification of monitoring parameters, such as alarms that are triggered when certain thresholds are met in the extracted vehicle information. In some embodiments, binary files can be generated by the vehicle information extraction service 102 and presented to the customer for deployment to the customer's vehicles.

[0046] The management console 410 includes an analytics interface 424 for defining analytics to be performed on the extracted vehicle information, and a customer API interface 426 that allows the customer to specify analytics, alarm, notification parameters, etc. Additionally, the management console 410 includes a customer communication interface 422 configured to issue notifications to the customer when certain alarm thresholds are met in the extracted vehicle information. In some embodiments, the management console 410 further includes a permissions and roles interface 432 that may allow the customer to define access roles for different types or classes of users (who may be employees of vehicle suppliers or vehicle component suppliers that are customers of the vehicle information extraction service). For example, some users may be assigned roles that only allow them to use pre-configured vehicle information extraction configurations, while other users may be assigned roles that allow them to develop new vehicle information extraction configurations, such as diving deeper into the operation of specific vehicle components.

[0047] The management console 410 includes a region interface 434 that determines region boundaries and the resolution of the region boundaries that may be used to determine vehicle fleet segments. As further described in Figure 8, the region interface 434 can be used by the customer to divide the map into grid regions with region-specific identifiers that define the boundaries of the regions, as well as to change the resolution of the region boundaries. Additionally, the management console 410 includes a semantically indexed item interface 436 that defines the types of semantically indexed items. A customer may use the semantically indexed item interface 436 to identify classifications of detected visual objects, such as stationary objects (e.g., traffic lights and road signs), semi-stationary objects (e.g., objects that may change but are infrequent, e.g., lane closures), transient objects (e.g., bicycles and other vehicles), or any other classification of one or more specific objects. In some embodiments, the indexed item interface 436 may be used to make inferences about movement patterns or other environmental factors of a fleet, which may be used to determine the likelihood that data is returned by a vehicle as redundant data. The indexed item interface 436 may use data aggregated from various sources, including images or other information acquired by a fleet of vehicles. In some embodiments, the management console may include a data reduction factor interface 438 used by a customer to present the probability of vehicle information being extracted. For example, an engineer may specify a probability of stationary object data extraction of 0.5 relative to a patch of vehicles surrounding a stationary object when the number of vehicles in an area is in the range of 100-200.

[0048] Note that in some embodiments, the vehicle data extraction service may restrict the definition of a partition so that the resulting partition has at least a threshold number of vehicles contained within that partition. For example, in some embodiments, the vehicle data extraction service may restrict the partition to include at least a certain number of vehicles. Thus, vehicle anonymity is maintained. For example, if the number of vehicles in a given partition is large enough, e.g., 20 vehicles, the collected vehicle information will be sufficiently anonymous. Thus, if a customer submits a partition definition that results in a partition partition consisting of less than a minimum threshold number of vehicles, the vehicle data extraction service may disable dynamic data reduction. Furthermore, in some embodiments, if a given partition does not include at least a threshold number of vehicles, transmission probability updates may be disabled from being sent to the fleet. In some embodiments, various thresholds may be used, such as 20 vehicles as described above, or other thresholds, such as 5-10 vehicles. Furthermore, on the cloud side of the service, information that personally identifies individual vehicles may not be collected, or if collected, may be filtered so that it is not included in the data collection results.

[0049] 5A-5C show a more detailed view of a fleet of vehicles using a dynamic vehicle data extraction service to determine a data reduction factor to optimize the amount of data extracted based on changes in vehicle density at various times due to vehicle movement, according to some embodiments.

[0050] In Figure 5A, the fleet of vehicles may be located in various zones. As further described in Figure 8, zones A and B may be configured based on various geographic regions. However, as further described below, in some embodiments, zones may have irregular shapes that are not limited by geographic boundaries. In some embodiments, a given geographic region may include multiple zones.

[0051] As shown in FIG. 5A , the regions associated with parcels A and B (i.e., “Parcel A” and “Parcel B”) may expand or contract in size depending on the vehicle data extraction service and changes in the properties of the parcel, including its boundaries, and may be communicated to the vehicle. In some embodiments, multiple parcels may be drawn based on proximity to specific inferences made about the vehicle environment. For example, parcel C may surround a nearby vehicle at a certain distance from a stationary object 508. In some embodiments, parcel information may be communicated through a vehicle communication interface of the vehicle information extraction service. The vehicle data reduction service may maintain one or more parcel information tables containing corresponding parcel information, including information identifiers. In FIG. 5A , the crossing of a boundary from one parcel to another is based on geographic location, and various changes in the vehicle, such as proximity to identified objects, vehicle speed, or other, may be considered when determining whether the vehicle is crossing a parcel boundary.

[0052] In some embodiments, the vehicle environment may be represented, for example, as an overlay on a geographic map, with the overlay including objects identified within the vehicle environment based on previously collected vehicle information. For example, inferences about what objects are contained in the vehicle environment may be drawn from information collected from the vehicle or other vehicles in similar vehicle environments or locations. In some embodiments, the prevalence of a particular type of object may provide insight into the possible prevalence of another type of object. Thus, in some embodiments, the probabilities used in dynamic data reduction may be further based on inferences drawn from the vehicle environment.

[0053] At T0, there may be a certain number of vehicles in Zone A and Zone B. Vehicle 1 502, Vehicle 2 504, and Vehicle 3 506 are in the same vehicle group sending data to the vehicle data extraction service, which may include various models with different OEMs, as described in FIG. 1. At T0, the number of vehicles in Zone A and Zone B is 12 and 3, respectively. The vehicle data extraction service may maintain one or more tables 508 containing information about the data reduction factors / probabilities of returning selected sensor information for a zone / vehicle within the zone. Each zone may include vehicles receiving a certain data reduction factor / probability that changes based on the number of vehicles within the zone if a sufficient change in the number of vehicles occurs such that the model used for data reduction by the service is updated. For example, an increase in the number of vehicles within the zone may increase the number of redundant data sent due to the concentration of vehicles within the zone. An increase in the number of vehicles within the zone may increase the probability that selected sensor data is sent. On the other hand, a decrease in the number of vehicles within the zone may decrease the concentration of vehicles within the zone, which may require an increase in the probability that selected sensor data is extracted to collect sufficient data for analysis. Additionally, the data reduction coefficients / probabilities may be based on the presence of various inferences made about the environment by the vehicle information extraction service. For example, the vehicle data extraction service may infer the collection of objects in a segment where a vehicle resides based on environmental information, such as images detected by vehicles in the fleet, the presence of stationary objects 508, dynamic objects 510, and other inferences made about the segment. These inferences may be used to determine the data reduction coefficients. For example, the data reduction coefficients may be modified for each segment based on the total number of dynamic objects 510 near segment A or the number of stationary objects in segment B. Other inferences, such as vehicle movement patterns or the number of traffic lights in an area, or various other inferences about the vehicle environment, may be used to determine the data reduction coefficients for specific types of sensor data. In some embodiments, inferences made about a segment, such as the presence of dynamic objects 510 or other objects, may be modified by a decay function that accounts for the lifetime that an object may be present in the segment and the object's effect on the data reduction coefficient decay over time. For example, a dynamic object 510 may be present at T0 but removed at T1.

[0054] In some embodiments, the probability may change dynamically based on changes in the number of vehicles, vehicle density in the section, or various inferences. In some embodiments, data factor updates may be sent to vehicles in a particular section only after the total number of vehicles in the section exceeds a certain threshold number of vehicles. The threshold number of vehicles may vary based on factors such as the section, fleet, and type of sensor data. The data reduction factor table 508 shows the sample threshold range required to send an update to a vehicle. Figure 5 shows that when the number of vehicles in the section ranges from 0 to 5, the data extraction probability for selected data in section B is 0.5, and when the number of vehicles in the section ranges from 10 to 15, the data extraction probability for selected data in section A is 0.3. In some embodiments, instead of a set probability for a range of vehicles, the probability may vary based on the number of vehicles in the section. At T0, vehicle 1 502 and vehicle 2 504 are shown moving from section A to section B. When the two vehicles cross the section boundary at T1, the vehicles may send location information or other relevant sensor information to the vehicle data extraction service. In some embodiments, the vehicles may send information identifying the section information in addition to their location.

[0055] At T1, the number of vehicles in Section A and Section B is 10 and 5, respectively. The vehicle data extraction service updates one or more section information tables, which may result in changes to the number of vehicles in each of Sections A and B at T1. If the number of vehicles in a section does not exceed the threshold amount required to send an update, the change in the number of vehicles may not trigger an update to the probability of sensor data extraction within the group. For example, in FIG. 5A, when the number of vehicles in a section ranges from the minimum dynamic data reduction threshold (greater than 1) to 5, the probability of data extraction for the selected data of Section B remains the same because the total number of vehicles in Section B's group remains within the range. Note that in an actual implementation, the number of vehicles may be much larger, such as hundreds, thousands, or tens of thousands. However, for simplicity, a smaller number of vehicles is used in FIGS. 5A-5C. Similarly, the probability of data extraction for the selected data of Section A remains 0.3 because the number of vehicles in the section ranges from 10 to 15. At T1, vehicle 3 is shown moving from zone A to zone B, and at T2, as the vehicle crosses the zone boundary, vehicle 3 506 may transmit location information or other sensor information to the vehicle data extraction service. In some embodiments, the vehicle may transmit information identifying the zone information in addition to the vehicle's location.

[0056] At T2, the number of vehicles in Section A and Section B is 9 and 6, respectively, and the vehicle data extraction service updates one or more section information tables, which may result in a change in the number of vehicles in each of Sections A and B at T2. This change in the number of vehicles in both Section A and Section B at T2 causes both sections to exceed the threshold amount. For example, in FIG. 5A , the data extraction probability for Section B's selected data is 0.4 because the number of vehicles in Section B is in the range of 6 to 10. This is a change from T1, when the total number of vehicles was at its minimum with a data reduction to the range of 5. In Section A, the total number of vehicles has decreased to 9, exceeding the threshold range of 5 to 9 from 10 to 15. Therefore, the data extraction probability for Section A increases to 0.4. In some embodiments, if there is a change in the data extraction probability for sensor data within a section, a new vehicle scheme may be sent to the vehicles in the group within that section. For example, all vehicles in Section A's group at T2 receive a new vehicle scheme that communicates a new data reduction factor / probability of data extraction for sensor data to each vehicle in Section A.

[0057] FIG. 5B illustrates vehicles using a dynamic vehicle data extraction service to optimize the amount of extracted data using multiple non-uniform partitions based on the similarity of vehicle movement patterns, according to some embodiments. For example, vehicle 3 506 and vehicle 4 514 may be moving in the same direction or with similar movement patterns (e.g., moving at a similar speed, being moved by identified objects, etc.) and may be placed in the same partition, partition D. In contrast, vehicle 5 516 may be traveling in the opposite direction and / or with a different movement pattern and may be placed in partition E. As further shown in FIG. 8, partitions A and B may be configured based on different geographic regions, while partitions D and E may be based on environmental information and various inferences made about the environment. The area associated with any of the partitions may expand or contract in size depending on the vehicle data extraction service, and changes in the nature of the partition, including its boundaries, may be communicated to the vehicle. In some embodiments, multiple partitions may be drawn based on the vehicle's proximity to certain inferences made about the environment.

[0058] FIG. 5C illustrates vehicles using a dynamic vehicle data extraction service to optimize the amount of extracted data using multiple, non-uniform partitions within overlapping areas but in different partitions based on the vehicle environment or other environmental factors, according to some embodiments. For example, vehicle 6 520 and vehicle 7 522 may be traveling in the same direction and in the same geographic area, but may be on different levels. For example, vehicle 6 520 may be traveling on the upper level (overpass), while vehicle 7 522 may be traveling on the lower level (underpass) of a bridge, and thus may be located in different partitions, such as partition F and partition G. Even if two vehicles have similar directions or geographic locations, they may be located in different partitions due to environmental differences or other factors, such as speed differences. In some embodiments, environments of special interest, such as underpasses, may be considered separate partitions.

[0059] FIG. 6 illustrates a logical block diagram illustrating various components of a vehicle data extraction service, their interactions with vehicle movement, and the effect of vehicle movement on the probability of data extraction, according to some embodiments.

[0060] In this example, a vehicle 126 in the fleet of vehicles has transmitted location data 605 identifying the location of the vehicle 126. In some embodiments, the location data 605 may have been transmitted to the vehicle data extraction service through a trigger event, such as the crossing of a partition boundary defined by the vehicle extraction service. In some embodiments, the location data may further include a unique partition identifier that specifies the partition in which the vehicle is located. If no partition identifier is specified in the location data 605, the vehicle extraction service 102 determines the partition identifier based on the location data 605 and transmits that information to the partition information table 603, adding vehicle information associated with the partition identified in the location data 605. In some embodiments, the extracted raw data engine 184 also modifies the vehicle partition table 182 to remove the identified vehicle from any previous partitions in which the vehicle 126 was identified to match the vehicle's current location.

[0061] The vehicle data extraction service's vehicle partition engine 188 may interact with the vehicle partition table 182 to perform further queries and edits on the table. In some embodiments, the vehicle partition engine 188 listens for vehicle additions / deletions 608 for partitions of the vehicle fleet, which instructs the vehicle partition engine 188 to increase the total number of vehicles in the corresponding partition. The vehicle partition engine 188 may determine the total number of vehicles in each partition and store them in the vehicle partition table 182. In some embodiments, the vehicle partition table 182 may maintain information regarding the total number of vehicles in each partition. As discussed in FIGS. 5A-5C , if the total number of vehicles in a partition changes beyond a threshold range, a new data extraction probability / new data reduction factor is determined for that partition. In some embodiments, the vehicle partition engine 188 may listen for updates 614 and determine that the total number of vehicles in a partition has increased / decreased as vehicles enter or exit the partition, where the increase / decrease exceeds a threshold range. In response, vehicle partition engine 188 may create a new entry or update an existing entry in vehicle state table 186 to store the respective probabilities of data extraction that the vehicles should have after the change 618. In some embodiments, vehicle partition engine 188 may query 616 vehicle partition table 182 to identify all vehicles in the partition and send the new probabilities. Vehicle state table 186 may then be used by vehicle communication interface 180 to send the new probabilities of data extraction or data reduction factors to relevant vehicles in the fleet. In some embodiments, a new vehicle schema with updated probabilities and / or data reduction factors may be sent to all vehicles in the fleet that belong to the partition and whose probabilities of data extraction have changed.

[0062] FIG. 7 illustrates a flowchart of operations performed by a vehicle information extraction service in connection with the transition of one or more vehicles from one section to another, according to some embodiments, and illustrates operations for determining whether updated probabilities and / or data reduction factors for data extraction should be sent.

[0063] At block 702, a default data reduction scheme is transmitted to vehicles in the group of segments. The data reduction scheme may include information instructing the vehicles to collect signal data and information instructing the vehicles on events that trigger such collection. The data reduction scheme may further include data reduction documentation based on data redundancy levels, which are used to determine the probability of the data reduction method.

[0064] In block 704, the vehicle information extraction service receives location information for vehicles predicted to be in segment G1 and / or predicted to leave segment G0 and join segment G1. The vehicle information extraction service may receive the location information and determine a location prediction based on GPS information, as discussed in FIG. 1. In some embodiments, the location information may identify segment identification information in addition to the location information. The location information may further include segment information of a previous location.

[0065] In block 706, the vehicle information extraction service updates the count for segment G1 and decreases the count for segment G0. In block 708, the vehicle information extraction service determines whether a data reduction model update has been triggered so that the data reduction coefficients in segment G0 are updated. In block 712, the vehicle information extraction service determines whether a model change has been triggered so that the data reduction coefficients applied to vehicles in segment G1 are updated. In some embodiments, the two blocks (708 and 712) that check whether a trigger has been reached may execute simultaneously. In block 710, if the trigger is met, the reduction coefficients for all vehicles in segment G0 are decreased. Similarly, in block 714, if another trigger is met, the data reduction coefficients for all vehicles in segment G1 are increased.

[0066] FIG. 8 illustrates an example map used by a vehicle data extraction service that divides a map into gridded geographic regions, allows plot boundaries to be drawn, and enables boundary resolution to be changed, according to some embodiments.

[0067] FIG. 8 illustrates a geographic region 802 that implements a grid system in which a map is divided into regions with specific boundaries. While latitude and longitude represent a point, the grid system that divides the map may allow for the description of areas that may correspond to regions in some circumstances. Regions may be identified and organized by unique identifiers that define their respective regions through a geocoding system that utilizes blocks of characters and the length of the identifier. Some regions may correspond to the boundaries of the geographic region, while other regions may fall within the boundaries of the geographic region. Regions may not be parallelograms like the illustrated map grid, but may have uneven boundaries.

[0068] For example, FIG. 8 illustrates a geographic region 802 identified by a low-resolution identifier 804 using the identifier "A2B2." FIG. 8 further illustrates that the geographic region 802 is further subdivided into six sub-regions using high-resolution identifiers 806, such as "A1B2C1," "A1B2C2," and "A1B2C...." Each region is assigned a new identifier that begins with the same character string from its parent and ends with a different character, providing an efficient way to query whether a vehicle is within the bounded region of the map. Each region or sub-region may be used to organize various instances of information obtained from a fleet of vehicles or other sources and may be used to organize various inferences about the region. For example, region "A1B2C3" may be inferred to have a certain number of miles of major highways and a certain percentage more miles of highways compared to region "A1B2C5." In other embodiments, machine learning techniques may be used to detect and classify specific objects and determine a certain number of stop signs within a region. One or more of the various inferences made from the partitions may inform the vehicle data extraction service of potential redundant data, which may be used to determine a data reduction factor.

[0069] As discussed in FIGS. 5A-5C, in one embodiment, vehicles in a fleet may transmit location data to a vehicle data extraction service, at which point the vehicle data extraction service may identify the segment to which the vehicle belongs and, if a threshold is met, transmit a new vehicle scheme, including a data reduction factor, to the fleet of vehicles in the affected segment. In some embodiments, a vehicle may be configured to transmit location and / or segment information only when the vehicle crosses a segment boundary at a particular resolution. For example, if a vehicle is configured to bind to a low-resolution region, such as the low-resolution region identified by identifier 804, a change in vehicle segment from "A1B2C1" to "A1B2C2" will not trigger the transmission of data. However, if a vehicle is configured to bind to a higher resolution region, such as the high-resolution region identified by identifier 806, crossing this boundary from "A1B2C1" to "A1B2C2" will trigger the vehicle to transmit location information to the vehicle data extraction service. In some embodiments, the location at which a segment may be drawn may be determined by various inferences made by the vehicle information extraction service. For example, segment A1B2C6 may be further divided into sub-segments. In some embodiments, other segments may be generated based on various collected vehicle environment information and may be contained within multiple boundaries of the geographic region segment. The segments may not be parallelograms like the illustrated map grid, but may have uneven boundaries. For example, segment "A1B2C7" 808 may have uneven boundaries that span multiple polar geographic segments. In some embodiments, segments may be based on vehicle environment factors, such as a vehicle traveling in a particular direction or a vehicle traveling through a particular physical environment, such as a bridge. Segments "A1B2C8" and "A1B2C9" represent segments that span two different bridges.

[0070] Other embodiments may use other systems for geocoding map parcels that do not rely on gridded parcels, such as using Zoning Improvement Plan (ZIP) codes or Extended ZIP+4 codes to identify parcel boundaries, or other proximity area approaches that utilize precise GPS information instead of parcels to reduce operational costs.

[0071] FIG. 9 illustrates the effect of changing the resolution of a sample map of a vehicle data extraction service that divides the map into gridded sections and defines the boundaries of the sections, according to some embodiments.

[0072] FIG. 9 illustrates a geographic map divided into sections, each with a precision set by the vehicle data extraction service to determine section boundaries that act as triggers for the vehicle to transmit location data to the vehicle extraction service. For example, if a vehicle is initially located in section “A1B2C5” 704 and the vehicle’s section precision is set to 6 characters 702, then as the vehicle moves from section “A1B2C5” 704 to the adjacent section “A1B2C6” 710, detecting movement outside the smaller section triggers the transmission of location information. A change from the vehicle’s initial latitude / longitude 722 to the vehicle’s current latitude / longitude 724 triggers the vehicle to transmit location information to the vehicle data extraction service. In other embodiments, a vehicle in section “A1B2C5” may transition to non-uniform section “A1B2C7” based on various changes in vehicle conditions, such as entering an underpass, entering a specific proximity of an identified object, or detecting a vehicle accident.

[0073] In some embodiments, the precision with which segment boundaries are determined may be changed. For example, the initial precision may be six characters 711 to correlate to segment "A21B2C5," such that the segment identifier is characterized by a six-character identifier. If the segment precision threshold is changed from six characters to five characters 712, the current segment 714 associated with the vehicle's location, "A1B2C," will be identified with the same precision. In some embodiments, the precision of vehicle segments used may vary based on various factors, such as vehicle identification, fleet, and type of sensor data, and may not all use a uniform precision when triggering the transmission of location data to the vehicle data extraction service. Moving to a different precision may result in certain high-resolution segments, such as segments "A1B2C7" and "A1B2C9," not being considered.

[0074] FIG. 10 shows a more detailed diagram of the network stack of protocols used at different levels to communicate vehicle information over the vehicle's bus, according to some embodiments.

[0075] In some embodiments, software application 152 may include multiple layers of the vehicle's network stack that enable it to access and decode communications transmitted over the vehicle's communication bus. For example, a binary file contained in the binary file storage of the onboard computing device may indicate access credentials, protocols, and / or addresses used in vehicle hardware layer 1010. Further, the binary file may indicate access credentials, protocols, or ports used in vehicle firmware layer 1008 and / or vehicle hypervisor layer 1006. Further, the binary file may indicate the bus protocol used in bus layer 1004 and the customer's proprietary protocol and access credentials used in layer 1002. Vehicle information monitoring and extraction software application 152 may use these definitions and access the authentication information contained in the binary file to access and decode messages transmitted over the encoded vehicle communication bus 1108. To transmit raw data, software application 152 may include a vehicle identification certificate from a vehicle identification registry from the vehicle information extraction service's control plane. Software application 152 may decode communications transmitted over the communication bus using the decoding rules described in the decoder rules. In some embodiments, the decoder rules vary between different models of vehicles and / or between vehicles from different OEMs.

[0076] FIG. 11 illustrates an exemplary vehicle with multiple different buses that may be monitored for data extraction by a software application deployed by a vehicle information extraction service, according to some embodiments.

[0077] In some embodiments, a vehicle, such as vehicle 1126, may include multiple buses connected to gateway 202. For example, vehicle 1126 includes gateway 202 connected to CAN bus #1 (1104), CAN bus #2 (1106), Ethernet / IP bus 1108, local interconnect (LIN) bus 1110, and FlexRay bus 1112. As shown in FIG. 11 , different types of vehicle information may be transmitted over different types of buses. In some embodiments, software application 152 may provide decoder rules or decoder configurations for decoding various vehicle attributes from the vehicle module configuration into respective on-board communication signals. For example, decoder rules may be used to decode raw vehicle data from various CAN buses, Ethernet / IP buses, LIN buses, etc. into physical signals such as engine speed, radar amplitude, etc., which may be sent to a vehicle data extraction service.

[0078] FIG. 12 shows a more detailed view of a storage buffer that may be used by an application deployed by a vehicle information extraction service, according to some embodiments, where the storage buffer applies a data reduction factor and stores data from one or more prior moments that are eligible for extraction when one or more trigger criteria are met.

[0079] As shown in FIG. 12 , in some embodiments, storage buffer 158 may store multiple types of data in multiple buffers. For example, storage buffer 158 includes a time-synchronized decoded sensor buffer 1202, other data buffer 1 (1204), and other data buffer N (1206). Current data may be stored at time N. Data for the next moment in time is stored at time N−1, and when the next moment in time arrives, it becomes time N, and data previously stored at time N becomes time N+1. In some embodiments, storage buffer 158 may store data for any number of moments in time (e.g., N+X, where X is the number of moments buffered). Also, in some embodiments, X may be different for different types of vehicle information, such that some types of vehicle information are buffered for longer periods of time than other types of vehicle information.

[0080] In some embodiments, a global timestamp may be applied to the vehicle information when it is stored in storage buffer 1202. Also, in some embodiments, the payload of the data stored in storage buffer 1202 may include timestamps associated with the stored data generated by other components of the vehicle, such as a timestamp when a message containing the data was sent to encoded vehicle communication bus 138, or the time the data was sensed, such as by physical sensor 136. Thus, in some embodiments, data may have multiple timestamps associated with it, such as a payload timestamp when the data was sensed by physical sensor 136, another payload timestamp when the data was sent to encoded vehicle communication bus 138, and another timestamp when the data was received by storage buffer 158. In some embodiments, data stored in storage buffer 158 may be stored with more or fewer timestamps. Such timestamps may enable, for example, software application 152 or extracted data analysis and visualization module 114 of vehicle information extraction service 102 to reconstruct the exact sequence of events within the vehicle. In some embodiments, data reduction factor application 156 may select and filter out data after it is stored in storage buffer 158. For example, the data reduction factor application 156 may apply a data reduction factor to determine that 50% of the temperature data should be filtered, and use that data reduction factor to remove approximately half of the data stored in the buffer within a particular time frame. In other embodiments, the filtering of the data occurs before the data is stored in the buffer, so in the temperature data example, 50% of the sensor data is not stored. In other embodiments, all data is stored in the storage buffer, but filtering occurs only when sending this data to the vehicle data extraction service, so that only half of the data is sent.

[0081] FIG. 13 shows a flowchart of operations performed by a vehicle information extraction service that optimizes the amount of information extracted from vehicles based on, among other things, segment criteria and the number of vehicles in the segment's fleet, according to some embodiments.

[0082] At block 1302, the vehicle information extraction service receives a request from a customer of the vehicle information extraction service for one or more types of vehicle information to be extracted from a fleet of vehicles.

[0083] At block 1304, the vehicle information extraction service receives one or more vehicle information packets provided by each vehicle in the group, each of the one or more vehicle information packets containing information used to identify a respective segment.

[0084] In block 1306, the vehicle information extraction service determines the total number of vehicles in the fleet located in each of the sections.

[0085] In block 1308, the vehicle information extraction service determines one or more data reduction factors to be applied to the vehicles in each section based on the total number of respective vehicles in each section, the one or more data reduction factors including the probability that a given vehicle in the group in the given respective section has non-redundant vehicle information compared to other vehicles in the group in the given respective section.

[0086] In block 1310, the vehicle information extraction service sends one or more vehicle schema packets to vehicles in each of the one or more groups of sections. In some embodiments, the vehicle schema packets may include information identifying one or more requested types of vehicle information to be extracted and corresponding data reduction factors to be applied.

[0087] At block 1312, the vehicle information extraction service receives the requested type or types of vehicle information from only a portion of the fleet of vehicles located in the given segment according to a data reduction factor.

[0088] FIG. 14 illustrates a flowchart for implementing a modeling system in a vehicle information extraction service that enables generating a unified model for a fleet of vehicles and automatically accounting for variations in on-board communication configurations to enable collection of requested information specified in the model from a heterogeneous fleet of vehicles, according to some embodiments.

[0089] In block 1402, the vehicle information extraction service populates the decoder manifest with decoding parameters and / or on-board communication signal configurations and formats for collecting vehicle signal information from multiple types of vehicles using different on-board communication signal configurations or formats. The decoding parameters and / or on-board communication signal configurations and formats may be revised by the vehicle information extraction service from the vehicle OEM, a column 1 supplier, or other parts supplier. In some embodiments, an OEM that is a customer of the vehicle information extraction service may provide such information as part of onboarding the vehicle extraction service. In some embodiments, such information is stored by the vehicle information extraction service, and customers of the vehicle information extraction service no longer have access to the details of the decoding parameters and / or on-board communication signal configurations and formats.

[0090] In block 1404, the vehicle information extraction service provides an interface for generating a model of vehicle information collected from a fleet of vehicles that include different on-board communication signal configurations or formats. For example, a customer of the vehicle information extraction service may use the interface to specify a data collection model from a fleet of vehicles having different on-board communication configurations.

[0091] At block 1406, the vehicle information extraction service generates a vehicle model configuration including signal attributes of the vehicle information extracted from the fleet based on input received at the interface from the customer.

[0092] In block 1408, the vehicle information extraction service transmits signal decoding rules specific to each in-vehicle communication configuration to the fleet of vehicles, where the vehicle-specific signal decoding rules are selected based on the vehicle model and the decoder manifest.

[0093] At block 1410, the vehicle information extraction service sends a data collection scheme to each vehicle in the fleet according to a second request received from a customer of the vehicle information extraction service, the data collection scheme including data extraction criteria for the vehicle sensor information and identifying the vehicle sensor information using signal attributes of the vehicle model.

[0094] At block 1412, the vehicle information extraction service receives vehicle data from each vehicle in the fleet extracted from each vehicle according to the data collection scheme decoded using signal decoding rules.

[0095] Although not specifically shown in FIG. 14 , in some embodiments, the vehicle information extraction service may further apply a data reduction factor when collecting requested vehicle information from the fleet, as described with respect to FIG. 13 . Exemplary Computer System

[0096] Any of a variety of computer systems may be configured to implement processes associated with the vehicle information extraction service, the software application / package deployed from the vehicle information extraction service to the vehicle, the provider network implementing the vehicle extraction service, the vehicle or device operating system, or any other component of the above-described figures. For example, FIG. 15 shows a block diagram illustrating an exemplary computer system that implements some or all of the techniques described herein, according to some embodiments. In various embodiments, the vehicle information extraction service, the deployed software package, the provider network implementing the vehicle information extraction service and other cloud services, the vehicle or device operating system, or any other component of any of the above-described figures may each include one or more computer systems 1500 as shown in FIG. 15.

[0097] In the illustrated embodiment, computer system 1500 includes one or more processors 1510 connected to system memory 1520 via input / output (I / O) interface 1530. Computer system 1500 further includes a network interface 1540 connected to I / O interface 1530. In some embodiments, computer system 1500 may illustrate a server that implements enterprise logic or downloadable applications, although in other embodiments, a server may include more, fewer, or different elements than computer system 1500.

[0098] In various embodiments, computing device 1500 may be a uniprocessor system including one processor, or a multiprocessor system including several processors 1510A-1510N (e.g., two, four, eight, or another suitable number). Processors 1510A-1510N may be any suitable processor capable of executing instructions. For example, in various embodiments, processors 1510A-1510N may implement any of a variety of instruction set formats (ISAs), such as the x86, PowerPC, SPARC, or MIPS ISAs, or any other suitable ISA. In some embodiments, processors 1510A-1510N may include specialized processors, such as graphics processing units (GPUs), application-specific integrated circuits (ASICs), etc. In a multiprocessor system, each of processors 1510A-1510N may typically, but not necessarily, implement the same ISA.

[0099] The system memory 1520 may be configured to store program instructions and data accessible by the processor(s) 1510A-1510N. In various embodiments, the system memory 1520 may be implemented using any suitable memory technology, such as static random access memory (SRAM), simultaneous dynamic RAM (SDRAM), non-volatile / flash-type memory, or any other type of memory. In the illustrated embodiment, the program instructions and data that implement one or more desired functions, such as the methods, techniques, and data described above, are shown stored in the system memory 1520 as code (i.e., program instructions) 1525 and data 1535.

[0100] In one embodiment, I / O interface 1530 may be configured to coordinate I / O traffic between processors 1510A-1510N, system memory 1520, and any peripheral devices within the device, including network interface 1540 or other peripheral interfaces. In some embodiments, I / O interface 1530 may perform any necessary protocol conversion, timing conversion, or other data conversion to convert data signals from one component (e.g., system memory 1520) into a format suitable for use by another component (e.g., processor 1510). In some embodiments, I / O interface 1530 may include support for devices attached via various types of peripheral buses, such as variations of the Peripheral Component Interconnect (PCI) bus standard or the Universal Serial Bus (USB) standard. In some embodiments, I / O interface 1530 may include support for devices connected via an in-vehicle CAN bus. In some embodiments, the functionality of I / O interface 1530 may be split into two or more separate components, such as a northbridge and a southbridge. Also, in some embodiments, some or all of the functionality of I / O interface 1530, such as the interface to system memory 1520, may be incorporated directly into processors 1510A-1510N.

[0101] Network interface 1540 may be configured to allow data to be exchanged between computing device 1500 and other devices 1560 associated with network or networks 1550. In various embodiments, network interface 1540 may support communication over any suitable wired or wireless general data network, such as, for example, an Ethernet network type, a cellular network, a Bluetooth network, a Wi-Fi network, an ultra-wideband network, etc. Additionally, network interface 1540 may support communication over a telecommunications / telephony network, such as an analog voice network or a digital fiber communications network, over a storage area network, such as a Fibre Channel SAN, or over any other suitable type of network and / or protocol.

[0102] In some embodiments, system memory 1520 may be one embodiment of a computer-readable (i.e., computer-accessible) medium configured to store program instructions and data, such as those described above, for implementing corresponding method, system, and apparatus embodiments. However, in other embodiments, program instructions and / or data may be received, sent, or stored on different types of computer-readable media. Generally speaking, computer-readable media may include non-transitory storage or memory media, such as magnetic or optical media, e.g., disks or DVDs / CDs, coupled to computing device 1500 via I / O interface 1530. One or more non-transitory computer-readable storage media may also include any volatile or non-volatile media, such as RAM (e.g., SDRAM, DDR SDRAM, RDRAM, SRAM, etc.), ROM, etc., that may be included in some embodiments of computing device 1500 as system memory 1520 or another type of memory. Additionally, computer-readable media may include transmission media or signals, such as electrical, electromagnetic, or digital signals, transmitted over a communication medium, such as a network and / or a wireless link, such as may be implemented via network interface 1540. 15 may be used to implement the described functionality, in various embodiments; for example, software components executing on various different devices and servers may cooperate to provide the functionality. In some embodiments, some of the described functionality may be implemented using storage devices, network devices, or various types of computer systems. The term "computing device," as used herein, refers to at least all of these types of devices, but is not limited to these types of devices.

[0103] Embodiments of the present disclosure can be described in light of the following clauses.

[0104] Clause 1. A system for implementing a vehicle information extraction service, comprising: one or more computing devices, receiving a request from a customer of the vehicle information extraction service to extract one or more types of vehicle information from a fleet of vehicles; receiving one or more vehicle information packets provided by each vehicle in the group, each of the one or more vehicle information packets including information used to identify a respective segment; determining a total number of vehicles in each of said sections; determining one or more data reduction factors to be applied to vehicles in each of the sections based on the respective total number of vehicles in each of the sections, the one or more data reduction factors comprising a probability that a given vehicle of the group in a given respective section has non-redundant vehicle information compared to others of the vehicles of the group in the given respective section; transmitting one or more vehicle scheme packets to one or more of the vehicles in the group, the vehicle scheme packets including information identifying the requested one or more types of vehicle information to be extracted and one or more corresponding data reduction factors for one or more segments to be applied; the computing device configured to receive the requested one or more types of vehicle information from only a portion of the vehicles in the group located in each of the one or more sections according to the one or more data reduction factors.

[0105] Clause 2. said one or more computing devices inferring a vehicle environment for a vehicle in a given segment based on the received vehicle information, the vehicle environment including vehicle-detected objects identified via a machine learning algorithm; 10. The system of claim 1, further configured to determine the data reduction factor based on an inferred vehicle environment for each segment.

[0106] Clause 3. said one or more computing devices 3. The system of claim 2, further configured to classify the detected objects as stationary, semi-stationary, or dynamic using a machine learning algorithm.

[0107] Clause 4. said one or more computing devices modifying the inferred vehicle environment according to a decay function; 4. The system of claim 2 or claim 3, further configured to determine the data reduction factor based on the inferred vehicle environment modified by the respective decay function.

[0108] Clause 5. The segment is determined based on the respective positions of the respective vehicles indicated in the received one or more vehicle information packets; 5. The system of any one of clauses 1 to 4, wherein temporal proximity is in which the respective vehicles are located close to each other.

[0109] Clause 6. A method comprising: receiving a request for one or more types of vehicle information to be extracted from a fleet of vehicles; receiving one or more vehicle information packets provided by each vehicle in the group, each of the one or more vehicle information packets including information used to identify a respective segment; determining a total number of vehicles in a given one of said respective sections; determining a data reduction factor to be applied to vehicles in said given one of said sections based on the total number of vehicles in said given section; transmitting one or more vehicle scheme packets to the group of vehicles in the given segment, the vehicle scheme packets including information identifying the requested one or more types of vehicle information to be extracted and the corresponding data reduction factor to be applied to the given segment; receiving the requested type or types of vehicle information from only a portion of the vehicles in the fleet located in the given section according to the data reduction factor.

[0110] Clause 7. Further comprising: inferring a vehicle environment for a vehicle located in the given segment based on the received vehicle information for the given segment, the vehicle environment including vehicle-detected objects identified via a machine learning algorithm; 7. The method of claim 6, wherein the data reduction factor is further determined based on the inferred vehicle environment for the given segment.

[0111] Clause 8. further comprising classifying the vehicle-detected object as a stationary object, a semi-stationary object, or a dynamic object; 8. The method of claim 7, wherein the data reduction factor is further determined based on whether objects in the inferred vehicle environment of the given segment are stationary, semi-stationary, or dynamic objects.

[0112] Clause 9. Further comprising: modifying the inferred vehicle environment by a respective damping function for stationary, semi-stationary, or dynamic objects; 9. The method of claim 7 or 8, wherein the data reduction factor is further based on the inferred vehicle environment modified by the respective attenuation functions of stationary, semi-stationary, or dynamic objects.

[0113] Clause 10. The segment is determined based on the respective positions of the respective vehicles indicated in the received one or more vehicle information packets; 10. The method of any one of clauses 6 to 9, wherein temporal proximity is in which the respective vehicles are located close to each other.

[0114] Clause 11. Receiving another vehicle information packet contributed by a second one of said vehicles in said group, said other vehicle information packet contributed at least in part because said second vehicle satisfies one or more criteria for inclusion in said given segment; updating the total number of vehicles in the group that are in the given section based on the inclusion of the second vehicle in the given section; The method of any one of clauses 6 to 9, further comprising: if the second total number of vehicles in the given section does not exceed a model update threshold level, transmitting the data reduction factor previously determined for the given section to the second vehicle.

[0115] Clause 12. Determining a second data reduction factor to be applied to vehicles in the given section based on an updated version of the total number of vehicles in the given section that exceeds the model update threshold, wherein the second data reduction factor includes a second probability that each one of the vehicles in the group in the given section will have non-redundant vehicle information compared to others of the vehicles in the group in the given section; 12. The method of any one of clauses 6 to 11, further comprising: transmitting an other vehicle scheme packet to the group of vehicles in the given section, the other vehicle scheme packet including information identifying the requested one or more types of vehicle information to be extracted and a corresponding second data reduction factor to be applied.

[0116] Clause 13. The method of any one of clauses 6 to 12, wherein the fleet of vehicles includes vehicles that have selected a data reduction setting for information extraction.

[0117] Clause 14. Determining a second data reduction factor to be applied to each vehicle in a second group of vehicles based on the total number of vehicles in the group and the second group included in the given section, wherein the second data reduction factor comprises a second probability that a given vehicle in the second group that is in the given section will have non-redundant vehicle information compared to others of the vehicles in the first group or the second group that are included in the given section; 14. The method of any one of clauses 6 to 13, further comprising: transmitting one or more second vehicle scheme packets to the second group of vehicles in the given section, the second vehicle scheme packets including information identifying the requested one or more types of vehicle information to be extracted and a second corresponding data reduction factor to be applied.

[0118] Clause 15. The one or more types of vehicle information extracted from the fleet of vehicles: Camera data, LiDAR data, Electronic Control Unit (ECU) data, or 15. The method of any one of clauses 6 to 14, including one or more of:

[0119] Clause 16. The one or more vehicle scheme packets instruct the vehicle to store the vehicle information in vehicle data storage during periods when the bandwidth of the network connection over which the vehicle information is transmitted does not meet a bandwidth threshold; 16. The method of any one of clauses 6 to 15, wherein the vehicle scheme packet instructs the vehicle to store a reduced version of the vehicle information reduced according to the data reduction factor.

[0120] Clause 17. The one or more vehicle scheme packets instruct the vehicle to store the vehicle information in vehicle data storage during periods when the bandwidth of the network connection over which the vehicle information is transmitted does not meet a bandwidth threshold; the vehicle scheme packet instructs the vehicle to store the vehicle information without applying the data reduction factor; 16. The method of any one of clauses 6 to 15, wherein the data reduction factor is applied when preparing to transmit the stored vehicle information in response to determining that the network connection meets the bandwidth threshold.

[0121] Clause 18. The method of any one of clauses 6 to 17, wherein the vehicles of the fleet include vehicles having different on-board communication architectures, and the request for one or more types of vehicle information to be extracted from the fleet of vehicles is formatted differently for the different on-board communication architectures.

[0122] Clause 19. When executed on or among one or more computing vehicles, on said one or more computing vehicles: receiving a request for one or more types of vehicle information to be extracted from a fleet of vehicles; receiving one or more vehicle information packets provided by each vehicle in the group, each vehicle information packet including information used to identify a respective segment; determining a total number of respective vehicles in one or more of said respective sections; determining a data reduction factor to be applied to vehicles in a given one of the sections based on the total number of vehicles in the given section; transmitting one or more vehicle scheme packets to the group of vehicles in the given section, the vehicle scheme packets including information identifying the requested one or more types of vehicle information to be extracted and corresponding data reduction factors to be applied; and receiving the requested one or more types of vehicle information from only a portion of the vehicles of the group located in the given section according to the data reduction factor.

[0123] Clause 20. When executed on or among said one or more processors, causes said one or more processors to: The one or more non-transitory computer-accessible storage media described in clause 19, storing further program instructions that implement the following: inferring a vehicle environment for a vehicle in the given section based on the received vehicle information for the given section, the received vehicle environment including vehicle-detected objects identified by a machine learning algorithm, and the data reduction coefficient being further determined based on the vehicle environment.

[0124] Clause 21. A system for implementing a vehicle information extraction service, comprising: one or more computing devices, generating a vehicle model compiling a subset of signal attributes of a plurality of signal attributes according to a first request received from a customer of the vehicle information extraction service; transmitting each of a plurality of signal decoding rules to a vehicle of the fleet of vehicles for decoding the signal attributes of the vehicle model into an on-board communication signal; transmitting a data collection scheme to each vehicle in the fleet according to a second request received from a customer of the vehicle information extraction service, the data collection scheme including data extraction criteria for vehicle sensor information, and identifying the vehicle sensor information using the subset of the signal attributes of the vehicle model; the computing device configured to receive from each vehicle of the fleet vehicle data extracted from each vehicle according to the data collection scheme decoded using the signal decoding rule.

[0125] Clause 22. The system of clause 21, wherein the fleet of vehicles includes vehicles having different on-board communication signal configurations, and transmitting respective signal decoding rules to the vehicles of the fleet is based on which of the different on-board communication signal configurations each of the vehicles uses.

[0126] Clause 23. The one or more computing devices receiving the signal attributes of each of a plurality of sensors from a manufacturer or supplier of a plurality of vehicles, the plurality of vehicles including vehicles having different on-board communication signal configurations; 23. The system of claim 21 or 22, further configured to generate a signal catalogue that organizes the signal attributes into an integrated signal representation, and wherein a signal configuration of the vehicle model is based on the signal catalogue.

[0127] Clause 24. The system of clause 23, wherein the signal configuration of the vehicle model omits signals for which no decoding rule exists in the signal catalog for mapping vehicle-specific signal names to the respective signal attributes in the signal catalog.

[0128] Clause 25. The one or more computing devices 25. The system of claim 24, further configured to receive from the manufacturer or supplier a plurality of sensor-specific signal decoding rules for decoding signals corresponding to the signal attributes in the signal catalog that correspond to respective ones of a plurality of signal attribute names, the sensor-specific signal decoding rules enabling signal decoding formatted in accordance with an on-board communication signal format for each of the vehicles in the group.

[0129] Clause 26. A method comprising: generating a vehicle model that organizes a subset of signal attributes of a plurality of signal attributes for a fleet of vehicles; transmitting, to the fleet of vehicles, each signal decoding rule of a plurality of signal decoding rules for decoding signal attributes included in the vehicle model, the transmitted decoding rule enabling decoding of an on-board communication signal; transmitting a data collection scheme to each vehicle in the fleet, the data collection scheme including data extraction criteria for vehicle sensor information and identifying the vehicle sensor information using a subset of the signal attributes of the vehicle model; receiving from each vehicle of the fleet vehicle data extracted from each vehicle according to the data collection scheme decoded using the transmitted signal decoding rule.

[0130] Clause 27. The method of clause 26, wherein the fleet of vehicles includes vehicles having different on-board communication signal configurations, and transmitting respective signal decoding rules to the vehicles of the fleet is based on which of the different on-board communication signal configurations each of the vehicles uses.

[0131] Clause 28. Receiving the signal attributes of each of a plurality of sensors from a manufacturer or supplier of a plurality of vehicles, the plurality of vehicles including vehicles having different on-board communication signal configurations; 28. The method of clause 27, further comprising: generating a signal catalog that organizes the signal attributes into an integrated signal representation, wherein a signal configuration of the vehicle model is based on the signal catalog.

[0132] Clause 29. The method of clause 27, wherein the signal configuration of the vehicle model omits signals for which no decoding rule exists in the signal catalogue for mapping vehicle-specific signal names to the respective signal attributes of the signal catalogue.

[0133] Clause 30. The method of clause 26, further comprising receiving, from a vehicle manufacturer or supplier, a plurality of sensor-specific signal decoding rules for decoding signals corresponding to the signal attributes of the signal catalog corresponding to respective ones of a plurality of signal attribute names, the sensor-specific signal decoding rules enabling signal decoding formatted in accordance with an on-board communication signal format of each of the vehicles in the fleet.

[0134] Clause 31. The method of any one of clauses 26 to 30, further comprising decoding the vehicle data extracted from each vehicle using the signal decoding rules, wherein the received vehicle data is decoded from a binary resource into a sensor signal value.

[0135] Clause 32. Associating said sensor signal values ​​with one or more vehicle attributes of said vehicle from which said vehicle data was extracted; 32. The method of clause 31, further comprising publishing the sensor signal values ​​to a time series database.

[0136] Clause 33. The vehicle sensor information Camera data, LiDAR data, Electronic Control Unit (ECU) data, or 33. The method of any one of clauses 26 to 32, including one or more of:

[0137] Clause 34. The method of any one of clauses 26 to 33, wherein the signal attributes include static characteristics associated with a particular vehicle, including a unique vehicle ID, a vehicle brand, a vehicle body type, and a vehicle engine model.

[0138] Clause 35. The method of any one of clauses 26 to 34, wherein the data collection scheme further comprises information identifying the vehicle sensor information to be extracted corresponding to a data reduction factor, the data reduction factor being based on a total number of vehicles in a collection of vehicles in a given geographical area and on an inference of a vehicle environment for the collection of vehicles, and the extracted data being extracted from only a portion of the collection of vehicles.

[0139] Clause 36. When executed on or among one or more computing vehicles, said one or more computing vehicles: generating a vehicle model that organizes a subset of signal attributes of the plurality of signal attributes; transmitting each of a plurality of signal decoding rules to a vehicle of the fleet of vehicles for decoding the signal attributes of the vehicle model into an on-board communication signal; transmitting a data collection scheme to each vehicle in the fleet, the data collection scheme including data extraction criteria for vehicle sensor information, and identifying the vehicle sensor information using the subset of signal attributes of the vehicle model; and receiving, from each vehicle of the fleet, vehicle data extracted from the respective vehicle according to the data collection scheme that is decoded using the signal decoding rules.

[0140] Clause 37. When the instructions are executed on or among the one or more processors, the instructions further cause the vehicle information extraction service to: one or more non-transitory computer-readable storage media as described in clause 36, implementing the steps of: decoding the vehicle data extracted from each vehicle in the group using the signal decoding rules, and the received vehicle data being decoded from an on-board format into sensor signal values.

[0141] Clause 38. When the instructions are executed on or among the one or more processors, the instructions further cause the vehicle information extraction service to: Associating a given sensor signal value with one or more vehicle attributes of the vehicle from which the vehicle data was extracted; and publishing the sensor signal values ​​to a time series database.

[0142] Clause 39. The vehicle sensor information Camera data, LiDAR data, Electronic Control Unit (ECU) data, or 39. One or more non-transitory computer-readable storage media of any one of clauses 36 to 38 containing one or more of the synthetic sensor data.

[0143] Clause 40. The one or more non-transitory computer-readable storage media of any one of clauses 36 to 39, wherein the signal attributes include static characteristics associated with a particular vehicle, including a unique vehicle ID, a vehicle brand, a vehicle body type, or a vehicle engine model.

[0144] The various methods illustrated in the figures and described herein represent illustrative embodiments of the methods. The methods may be implemented manually, in software, hardware, or a combination thereof. The order of any method may be changed, and various elements may be added, rearranged, combined, omitted, modified, etc. For example, in one embodiment, the methods may be performed by a computer system including a processor executing program instructions stored on a computer-readable storage medium coupled to the processor. The program instructions may be configured to implement functionality described herein (e.g., functionality of data transfer tools, various services, databases, devices, and / or other communication devices, etc.).

[0145] Various modifications and variations may be made, as will be apparent to those skilled in the art having the benefit of this disclosure. All such modifications and variations are intended to be included and the above description is therefore to be considered in an illustrative rather than a limiting sense.

[0146] Various embodiments may further include receiving, sending, or storing instructions and / or data executed in accordance with the foregoing description of computer-accessible media. Generally, computer-accessible media may include storage media or memory media, such as magnetic or optical media, e.g., disks or DVDs / CD-ROMs, volatile or non-volatile media, such as RAM (e.g., SDRAM, DDR, RDRAM, SRAM, etc.), ROM, etc., and transmission media or signals, such as electrical, electromagnetic, or digital signals conveyed over a communications medium, such as a network and / or wireless link.

Claims

1. 1. A system for implementing a vehicle information extraction service, comprising: One or more computing devices, receiving a request from a customer of the vehicle information extraction service to extract one or more types of vehicle information from a fleet of vehicles; receiving one or more vehicle information packets provided by each vehicle in the group, each of the one or more vehicle information packets including information used to identify a respective segment; determining the total number of vehicles in a given one of said respective sections; determining one or more data reduction factors to be applied to vehicles in said each of said sections based on said total number of vehicles in a given one of said sections; transmitting one or more vehicle scheme packets to one or more vehicles of the group of vehicles in the given section, the vehicle scheme packets including information identifying the requested one or more types of vehicle information to be extracted, one or more trigger criteria, and one or more corresponding data reduction factors to be applied to the given section; trigger monitoring modules of the one or more vehicles determining whether bus traffic of the one or more vehicles has satisfied the one or more trigger criteria resulting in a trigger event; and the one or more data reduction factors being used to determine a proportion of the trigger event for which sensor data included in the extracted vehicle information is transmitted; the computing device configured to receive the requested one or more types of vehicle information from only a portion of the vehicles of the group located in the given section according to the one or more data reduction factors.

2. the one or more computing devices; inferring a vehicle environment for a vehicle in the given segment based on the received vehicle information, the vehicle environment including vehicle-detected objects identified via a machine learning algorithm; The system of claim 1 , further configured to further determine the data reduction factor based on an inferred vehicle environment for the given segment.

3. the one or more computing devices; The system of claim 2 , further configured to classify the detected objects as stationary, semi-stationary, or dynamic using a machine learning algorithm.

4. the one or more computing devices; modifying the inferred vehicle environment according to a decay function; The system of claim 2 or claim 3, further configured to determine the data reduction factor based on the inferred vehicle environment modified by the respective decay function.

5. the location of each of the vehicles indicated in the received one or more vehicle information packets; the temporal proximity of the respective vehicles to one another; and The system of claim 1 , wherein the determination is based on:

6. 1. A method comprising: receiving a request for one or more types of vehicle information to be extracted from a fleet of vehicles; receiving one or more vehicle information packets provided by each vehicle in the group, each of the one or more vehicle information packets including information used to identify a respective segment; determining a total number of vehicles in a given one of said respective sections; determining a data reduction factor to be applied to vehicles in said given one of said sections based on the total number of vehicles in said given section; transmitting one or more vehicle scheme packets to the group of vehicles in the given section; receiving the requested type or types of vehicle information from only a portion of the vehicles in the fleet located in the given section according to the data reduction factor; The vehicle scheme packet includes information identifying the requested one or more types of vehicle information to be extracted, one or more trigger criteria, and the corresponding data reduction factor to be applied to the given segment, and a trigger monitoring module of the vehicles in the group determines whether bus traffic of each vehicle in the group has satisfied the one or more trigger criteria that result in a trigger event, and the data reduction factor is used to determine the proportion of the trigger event for which sensor data included in the extracted vehicle information is transmitted. method.

7. the location of each of the vehicles indicated in the received one or more vehicle information packets; The method of claim 6 , wherein the vehicle location is determined based on a temporal proximity of the respective vehicles to one another.

8. receiving another vehicle information packet provided by a second one of the vehicles in the group, the other vehicle information packet being provided at least in part because the second vehicle satisfies one or more criteria for inclusion in the given segment; updating the total number of vehicles in the group that are in the given section based on the inclusion of the second vehicle in the given section; 8. The method of claim 7, further comprising: if the updated total number of vehicles in the given segment does not exceed a model update threshold level, transmitting the data reduction factor previously determined for the given segment to the second vehicle.

9. determining a second data reduction factor to be applied to vehicles in the given segment based on an updated version of the total number of vehicles in the given segment that exceed the model update threshold level; transmitting an other vehicle scheme packet to the vehicles of the group in the given section; 9. The method of claim 8, wherein the second data reduction factor is used to determine another proportion of the trigger events for which the sensor data is transmitted, and the other vehicle scheme packet includes information identifying the requested one or more types of vehicle information to be extracted, the trigger criteria, and a corresponding second data reduction factor to be applied.

10. The method of any one of claims 6 to 8, wherein the fleet of vehicles includes vehicles that have elected to participate in vehicle information extraction.

11. determining a second data reduction factor to be applied to each vehicle in a second group of vehicles based on the total number of vehicles in the group and a second group included in the given section; transmitting one or more second vehicle scheme packets to the second group of vehicles in the given section; 9. The method of claim 6, wherein the second data reduction factor is used to determine another proportion of the trigger events for which the sensor data is transmitted, and the second vehicle scheme packet includes information identifying the requested one or more types of vehicle information to be extracted, the trigger criteria, and a second corresponding data reduction factor to be applied.

12. The one or more types of vehicle information extracted from the vehicle fleet, Camera data, LiDar data, Electronic control unit (ECU) data 9. The method of claim 6, comprising one or more of:

13. the one or more vehicle scheme packets instruct the vehicle to store the vehicle information in vehicle data storage during periods when the bandwidth of a network connection over which the vehicle information is transmitted does not meet a bandwidth threshold; 9. The method of claim 6, wherein the vehicle scheme packet instructs the vehicle to store a reduced version of the vehicle information reduced according to the data reduction factor.

14. the one or more vehicle scheme packets instruct the vehicle to store the vehicle information in vehicle data storage during periods when the bandwidth of a network connection over which the vehicle information is transmitted does not meet a bandwidth threshold; the vehicle scheme packet instructs the vehicle to store the vehicle information without applying the data reduction factor; 9. The method of claim 6, wherein the data reduction factor is applied when preparing to transmit the stored vehicle information in response to determining that the network connection meets the bandwidth threshold.

15. 9. The method of claim 6, wherein the fleet of vehicles includes vehicles having different on-board communication architectures, and the request for one or more types of vehicle information to be extracted from the fleet of vehicles is formatted differently for the different on-board communication architectures.

Images