Fleet data collection using integrated models to collect data from heterogeneous vehicles

Abstract

A system including one or more computing devices implements a vehicle information extraction service. The vehicle information extraction service enables a customer to maintain a model of a fleet of vehicles and collect vehicle information from heterogeneous vehicles in the fleet, the vehicles being configured with different on-board communication configurations. The vehicle information extraction service automatically generates scheme packets for data collection to be sent to the heterogeneous vehicles, formatted according to the different on-board communication configurations of each of the heterogeneous vehicles, without the customer of the vehicle information extraction service having to account for these differences.

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 inputs from such electronic sensors and determine various control actions to be performed on the vehicle or systems implemented in the vehicle. Some vehicles may include as many as 70 such electronic control units (ECUs), and 20-30 sensor modalities, etc. Furthermore, modern vehicles are increasingly dependent on sensors that generate more data than previous vehicles. For example, an autonomous, semi-autonomous, or self-driving vehicle may include multiple cameras, radar, LIDAR sensors, voice microphones, etc. Such sensors may generate large amounts of data, such as 5-10 terabytes per hour. Sending such large amounts of data to another service for data analysis creates significant problems.

[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 in-vehicle communication formats may need to be decoded depending on the configuration of those manufacturers. Additionally, with a heterogeneous fleet of vehicles that utilize different signal formats, a common method of collecting data for the fleet without taking into account the different signal formats and in-vehicle configurations cannot be used. [Brief description 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 vehicle fleet and used for data collection and analysis, and / or to extract information from each vehicle based on the fleet section, the number of vehicles in the fleet, and inferences about objects in the vehicle's environment determined based on previously collected vehicle information. [Diagram 2] 1 illustrates a more detailed diagram of a vehicle information extraction service, its various parts, and the interactions that separate vehicle model configuration from vehicle-specific on-board communication signal configuration, according to some embodiments. [Diagram 3] FIG. 1 illustrates a graphical illustration of an example 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 fleet of heterogeneous 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 a 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 optimizes the amount of data extracted based on the vehicle environment, vehicle movements, and changes in vehicle density at various times due to different segments, showing a more detailed view of the vehicle fleet. [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 segments of overlapping areas at different elevations based on the vehicle environment or other environmental factors, in accordance with some embodiments, to determine overlapping segments. [Figure 6] FIG. 1 illustrates a logical block diagram illustrating various components of a vehicle data extraction service, the interactions of the components 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 in relation to a vehicle transition from one section to another, according to some embodiments, illustrating operations for determining whether updated probabilities for data extraction and / or data reduction factors should be sent. [Figure 8] FIG. 1 illustrates an example 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 allow for different granularity and / or vehicle counts per region, according to some embodiments. [Figure 9] 1 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. 2 illustrates a more detailed diagram of an in-vehicle communication configuration of an example 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 example 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 illustrates a more detailed diagram of a storage buffer that may be used by an application deployed by a vehicle information extraction service, according to some embodiments, which 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 on, among other things, 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 generation of a unified model for a fleet of vehicles and automatically accounts 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. [Figure 15] 1 shows a block diagram illustrating an example computer system that may implement some or all of the techniques described herein, according to some embodiments. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0004] Although the 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 disclosed forms, but on the contrary, the intent is to cover all modifications, equivalents, and alternatives that are 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 an permissive sense (i.e., meaning having the potential to), rather than in a required sense (i.e., meaning necessary). Similarly, the terms "include," "including," and "includes" mean including, but not limited to.

[0005] The 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 that are utilized for a variety of applications ranging from improving the vehicle's fuel efficiency to increasing the degree of high automation using artificial intelligence (AI). Vehicles are not only beginning to be differentiated from each other mechanically, but also increasingly through software, with each new vehicle generation generating exponentially more data. Furthermore, the fastest growing trends in the automotive industry often involve autonomous vehicle (AV), advanced driver assistance system (ADAS), and electric vehicle technologies, all of which employ a variety of sensors that frequently generate more than 2 terabytes (TB) of data per hour. Furthermore, the types of sensors that are increasingly being relied upon often generate large amounts of data. For example, modern vehicles are increasingly relying 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 bandwidth for transferring vehicular data creates significant limitations given the large number of vehicles in existence, each equipped with an increasing number of sensors. Furthermore, the law of diminishing returns often applies to such large-scale data collection, where each additional byte of collected sensor information may be 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, there may be a need to continuously collect vehicle data to continue to build and improve vehicle models, as well as to operate. 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 transfer at a single vehicular 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 move in platoons or waves, interacting with many aspects of the 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, a set of vehicles traveling in a set of lanes heading in the same direction on a highway during morning rush hour may move together as a platoon of vehicles. As another example, a set of vehicles accelerating from a stopped position in response to a red light turning green may move together as a wave of vehicles. When considered as part of a platoon or wave of vehicles, many sets of sensor data collected from the vehicles may be presumed to be redundant, and a significant amount of this vehicle sensor data may be omitted from transmission to the data processing service to avoid redundant data collection. This reduction in data may reduce the strain on network bandwidth used by vehicles to report collected vehicle information and may reduce resources required for sensor data storage and processing. For example, a platoon or wave of vehicles at or around the same geographic location and time period may each detect similar temperatures at a temperature sensor. 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 fleet to which the data collection applies may be specified by the customer and may include heterogeneous types of vehicles. In some embodiments, the fleet may be defined based on criteria associated with the vehicles, such as "make," "model," etc. In some embodiments, as more makes or models are added or removed from the fleet, the fleet members may be adjusted.

[0007] In some embodiments, the geographic location of the vehicle may be determined in a variety of 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 a specific location accuracy. For example, segments may be formed based on relative positions to 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 moving along a road may encounter many of the same or similar environmental objects, resulting in the acquisition of photos that may be considered redundant. Furthermore, any vehicle exhibiting similar movement patterns or encountering similar environmental factors may be assumed to return a large number of redundant data. The vehicle information extraction service may use aggregated data from various sources, including images or other information acquired by the fleet of vehicles, 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 of vehicles may be generated and the density of vehicles in the fleet of vehicles in that segment may be obtained to determine a reduction factor. This reduction factor may be communicated to the vehicles 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 groups. In some embodiments, a customer of the dynamic data extraction service may wish to collect data from a fleet of vehicles that the customer drives or manages. Additionally, in some embodiments, fleets of vehicles may belong to different sections, which in some embodiments may be determined based on the platoon-like or wave-like behavior of each vehicle in the fleet and / or other vehicles in other fleets participating in the dynamic data reduction and / or vehicle data extraction service.

[0009] Further flexibility and capabilities of data collection may be enabled by vehicle data extraction services that allow for modeling, collection, and storage of data for fleets of vehicles configured with various in-vehicle communication formats. One issue 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 services overcome this issue by separating the vehicle model configuration from the in-vehicle communication signal configuration specific to an individual vehicle.

[0010] Furthermore, separating the vehicle model configuration from the on-board communication signal configuration specific to an individual vehicle allows different users to work independently on different parts of the model and allows for the use of a unified signal representation across a heterogeneous vehicle model fleet. For example, separating the vehicle's signal format, represented by the model configuration, and the on-board communication signal configuration, represented by the decoder rules for each type of vehicle, allows for a single analysis application to be used regardless of vehicle model, 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 the data collection configuration, which defines the rules regarding when and how to collect data from the vehicles, may be executed across a heterogeneous vehicle model fleet within such a service.

[0011] 1 illustrates a vehicle information extraction service that, according to some embodiments, associates multiple decoder rules having 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 made available for data collection and analysis, and / or to extract information from each vehicle based on inferences based on the fleet's section, the number of vehicles in the fleet, and the vehicle environment. Extraction based on the section, number of vehicles, and / or vehicle environment may enable dynamic data reduction to be applied to the collected data, such that redundant data collection is reduced.

[0012] The system 100 includes a vehicle information extraction service 102 and a network 116 connected to vehicles 142, 143, and 144. The vehicles 142, 143, and 144 may be included in a single fleet, but they are configured using a heterogeneous vehicle signal format. In some embodiments, the 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 the network 116. In some embodiments, the 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). The network 116 may be a private or public network, such as a direct connection to a service provider network hosting the vehicle information extraction service 102, or an Internet connection. Furthermore, 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, a 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 across a single vehicle or 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 the extraction service request 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 may provide a dictionary file describing a proprietary protocol and encoding format used to communicate vehicle information over the bus from components designed by the customer (e.g., vehicle supplier and / or vehicle component supplier), and / or an associated proprietary access credential file. For example, a customer 122a, 122n may submit an extraction service request 118, 120 that includes 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 request 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 optimization of collection through 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 the identities of the vehicles in the 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, fuel type, etc. Vehicle models generated using the modeling service may also be associated in a similar tuple format. The vehicle identification registry 110 may facilitate the rotation and revocation of vehicle identification certificates as well as changes of ownership. In other embodiments, the customer 122a, 122n may use its own certificate authority (CA) to on-board the fleet's vehicles 142, 143, 144 and manage the rotation and revocation of vehicle identification certificates. In some embodiments, the control plane 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. Fleet rules 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 the state of all 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 are 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 that the vehicles 142, 143, 144 use 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 model configuration and resolves conflicts between schemes based on customer-defined priorities. If a vehicle scheme is determined to apply to the 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 the 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 speed 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 on-board 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 on-board 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 how often (e.g., every 5 minutes), a schedule or period (e.g., 20 minutes from the current time) and a trigger event (e.g., a threshold braking speed of the vehicle, or a departure of the vehicle from its lane) the one or more sensor data are transmitted.In some embodiments, the trigger event is a heartbeat and data propagation may occur continuously at a constant rhythm.

[0017] In some embodiments, the 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 the required signals at a remote location, such as a cloud-based implementation. In other embodiments, the decoder rules may be applied at the on-board computing device 150 of the vehicle (or other vehicle edge device) rather than at the vehicle information extraction service 102, and send the decoded signals to the vehicle information extraction service 102. In some embodiments, the desired fleet of vehicles may include vehicles of different types, and the model configuration may include multiple decoder rules (where the rules for decoding are different for each different 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 with different signal semantics. In some embodiments, each set of decoder rules results in 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 (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. A 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 the signal ID is 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 may be used to model different types of vehicles. For example, one may generate a catalog for cars, a catalog for trucks, a catalog for motorcycles, etc. A signal catalog for the same vehicle type may have a single catalog that represents all signals of that vehicle type, but 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 may manage vehicle model configurations using signal catalogs and decoder rules to enable a unified signal representation for the vehicle data extraction service 102 to collect data across heterogeneous vehicles in a fleet via a workflow that applies the same data collection scheme when extracting data from heterogeneous vehicles in the fleet.

[0020] In some embodiments, the data plane 112 manages the receipt of raw data from the 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 the data storage 114, which may be stored in a vehicle status table 186 and a vehicle compartment table 182, respectively. The in-vehicle computing device(s) 150 may use the data plane 112 to authenticate a connection with the 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 the vehicle identification registry 110. In some embodiments, the data plane 112 includes a vehicle communication interface 180 configured to establish a secure connection with each vehicle, such as the vehicles 142, 143, 144, to transmit the software package 146 and receive the extracted vehicle data 148. In some embodiments, the extraction raw data engine 184 may store the extracted vehicle data 148 in a separate storage account of the customer 122a, 122n, such as a storage account of a storage service provided by a provider network that also implements the vehicle information extraction service 102. For example, a customer may have accounts for various services provided by a service provider network that also provides the vehicle information extraction service. Thus, the customer may specify whether the extracted vehicle information is delivered to the account using a particular service of the service provider network, such as an object-based storage service, an archival data storage service, a machine learning service, etc. The vehicle partition engine 188 of the data plane 112 may utilize location information and / or other sensor information from the fleet of vehicles to determine which partition of the fleet each vehicle is associated with. The vehicle partition engine 188 may utilize 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, the zones may be determined using two dimensional factors, the two dimensions being the spatial proximity of the vehicles and the temporal proximity of the spatial proximity, or more simply, how recently or how long ago the vehicles were in close proximity to each other. For example, zones A and B may be determined based on their geographical proximity within a certain time frame.

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

[0022] In some embodiments, the model may be generated at the service side of the data extraction service. The model may model the frequency of occurrence of a particular type of object in the environment where the data is collected / extracted from the vehicle, along with a model of how likely a given vehicle or vehicle type exhibiting common vehicle behavior (such as moving in a platoon or wave) 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 service side of the data extraction service may generate a data reduction factor to be applied to the vehicles belonging to each partition. In some embodiments, the partition may simply correspond to a geographical area. However, in the same or other embodiments, the partition may be based on both spatial and temporal dimensions. In some embodiments, the partition may be determined based on other factors. For example, a set of vehicles that are geographically close to each other, are also close in time, and exhibit common vehicle behavior, such as traveling at speeds that overlap the speed range of surrounding vehicles, may be grouped into a common partition. For example, such a partition may resemble a group of vehicles traveling close to each other at the same speed on an interstate at the same time. In some embodiments, the partition may be dynamically updated based on changes in vehicle behavior. As another example, in some embodiments, the common vehicle behaviors used to group vehicles into a common segment 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, the data extraction service may estimate the origin-destination flows 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 in conjunction with other factors described herein, such as the density of vehicles in the segment and the prevalence of objects in the environment in which the vehicles travel according to the determined trajectories.In some embodiments, if a currently updated model maintained at 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 the 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 the vehicle's settings. Once authenticated, the vehicles 142, 143, 144 may send data and forward messages to the vehicle information extraction service 102 using various publish-subscribe network protocols 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 that includes 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 the data storage 114. Enhancing 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 sensor 136 and the acoustic / visual sensor 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 location of the vehicle. 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 area in which the vehicle is currently located. This location information and / or other sensor information may be used to determine which section of the fleet the vehicle falls into. The vehicle scheme package 146 may be used by software applications 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 applications 152 may access binary file storage 154 to access vehicle information transmitted over the vehicle communication bus 138. In some embodiments, the vehicle communications over the vehicle bus may be encoded by the software applications 152 and may use binary files and / or configuration files in the binary file storage to decode the vehicle information transmitted over the encoded vehicle communications. 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 further detail in FIG. 12, the storage buffer may store encoded and / or decoded vehicle information and other related vehicle data for multiple prior moments in the past.

[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 vehicle scheme packets are met to determine whether the trigger criteria are met. In some embodiments, the vehicle scheme packets may provide detection of movement to a new section and / or geographic area as one such trigger criteria. For example, in FIG. 1, the 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 packets to determine the percentage of particular sensor data to 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 the trigger is 50%, the temperature sensor data transmitted by the fleet is effectively reduced by half, for example, by reducing the frequency of transmission of temperature data. In some embodiments, location module 154 may determine the location of vehicle 142 using location sensor 131. 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 that includes 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 that includes 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 a proprietary protocol and encoding format used to communicate vehicle information from components designed by the customer (e.g., vehicle supplier and / or vehicle component supplier) over the bus, and / or an associated proprietary access credential file. For example, a customer 122a 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, a customer 122n 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 the data extraction criteria are shown as part of the same submission. However, in some embodiments, the data extraction criteria and the 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 the restricted access dictionary and credential storage 106. The dictionary files / associated access credential files of customer 122a and the dictionary files / associated access credential files of 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 the dictionary files and access the credential files of customer 122a, and vice versa.

[0029] FIG. 2 shows a more detailed view of the vehicle information extraction service, its various parts, and the 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 send 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 of the data plane 104 may ensure that the signal ID is unique across the signal catalog. In some embodiments, the customer 122 may create any of multiple signal catalogs that 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 given 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 will only include a cruise control branch and an internal combustion engine branch, but not a branch for the electric engine. For another vehicle model that has an electric engine and cruise control, the model configuration will include a cruise control branch and a 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. FIG. 3 further illustrates a vehicle model configuration.

[0032] After the model configuration is created, decoder rules (e.g., a decoder manifest or other configuration) for all vehicle sensors in the model configuration may be obtained for an extraction service request 118. The decoder rules may specify rules for decoding signals of an in-vehicle communication network to enable a customer to collect data from sensors listed in the model configuration. For example, the decoder rules may include the CAN DBC of a particular vehicle model, additional protocol-specific information for decoding the in-vehicle signal format (e.g., channel ID of the signal resulting 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 to which the sensor is multiplexed), scale, offset, etc.

[0033] In some embodiments, the decoder rules may be used by the vehicle information extraction service 102 to decode the required 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, there may be heterogeneous types of vehicles, and the model configuration may include multiple decoder rules if the rules for decoding differ between vehicle types. In some embodiments, each set of decoder rules results in 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 allows data collection across a heterogeneous fleet of vehicles using different signal formats. Once the decoder rules result in 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, the 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., 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 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 ​​of 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 generate fleets as collections or groups of vehicles grouped together based on certain common vehicle attributes. Fleets may be generated based on various vehicle attributes such as vehicles manufactured in a particular year or range of years, vehicles with the color red, vehicle fuel type, etc. The customer 122 may instruct via the service user interface 106 to create a fleet based on attributes available in the signal catalog. In some embodiments, the creation of the 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 parcels 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 what data to collect from the vehicles, when to collect the data, and how often to expose the data to the vehicle communication interface 180, as well as various other parameters including a data reduction factor that restricts vehicles in a fleet to only transmit a certain percentage of the time based on the total number of vehicles in the same area. In some embodiments, the vehicle compartment engine 188 may determine the data reduction factor using a data collection probability engine 190 that restricts vehicles in a particular compartment from transmitting data. When creating a data collection scheme, the OEM or customer 122 may specify a subset of signals from the signal catalog that they wish to collect. In some embodiments, the customer 122 may specify either a vehicle ID or a fleet ID to which the data collection scheme is to be transmitted. The vehicle communication interface 180 receives the data collection scheme and transmits it to the selected vehicles or fleet.

[0037] In some embodiments, once data is collected from the vehicle's various sensors according to the data collection scheme, the resulting raw data stream is sent to the vehicle communication interface 180, where the raw data is decoded using the extracted raw data engine 184. In some embodiments, the extracted raw data engine 184 may use the 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 that includes 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 data storage time series database for analysis.

[0038] FIG. 3 illustrates a graphical representation of an example 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 fleet of heterogeneous vehicle models, in accordance with some embodiments.

[0039] The vehicle model configuration 300 provides a serialized digital format of the vehicle's attributes, sensors, actuators, and their relationships. The vehicle model configuration 300 provides the format required 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, the model configuration 300 includes all or a subset of the signal types of the signal catalog. The signals provided by the signal catalog may be arranged in a hierarchical structure as shown in the model configuration 300 and may include various signal types such as attributes, branches, sensors, and actuators. The model configuration allows for the attachment of static attributes to ECUs and domains such as "VIN" 306, "Model" 308, and "Brand" 330 that facilitate the creation of a fleet 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 created manually 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 necessary format to represent the relationship between ECUs and sensors as a hierarchical model that reflects the domain-based format of modern vehicle network systems. For example, a query 352 of "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 the customer to specify the sensor units and data types required for human-readable data exchange and 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 enable a customer engineer, such as an engineer at a vehicle supplier or a vehicle component supplier, to view a digital twin that includes data extracted from a real-world vehicle. Using the designer canvas may also enable the engineer to modify the type of data being 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 enable a customer engineer to log into a web application using their own corporate credentials (e.g., credentials issued to the engineer by the corporate customer) without requiring each engineer to have an account or credentials with the vehicle information extraction service. Using the web application, the customer's engineers may be able to access, visualize, and monitor vehicle data. The designer canvas may also enable a customer to build custom reports or analyses or incorporate vehicle data into an existing software environment. 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 enable 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 enable 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 near real-time conditions of a class of vehicles that match the fleet definition for a 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 the 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 enable a customer's engineers to view and interact with historical data extracted from a real vehicle or a real fleet of vehicles. In some embodiments, the 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, the designer canvas 402 may include a vehicle scheme user interface, such as a vehicle scheme user interface 408. The vehicle scheme user interface 408 may enable a customer's engineer to effect / change the type 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, the 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. The vehicle scheme user interface 408 may be used by the engineer 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 may 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 may use these interfaces to authorize the creation of additional digital twins for individual vehicles or fleets of vehicles. In some embodiments, a prompt at the designer canvas 402 may cause a request to be queued for approval by the customer, which will result in the digital twin interface 414 or fleet digital twin interface 416 creating additional digital twins. The management console 410 includes a deployment interface 418 of the management console 410 that may cause the generated binary file to be deployed to monitored vehicles. In some embodiments, a management console such as the management console 410 may further include a monitoring interface 420 for receiving and viewing the extracted vehicle information. In some embodiments, the monitoring interface may also allow the specification of monitoring parameters, such as alarms that are triggered when certain thresholds are met in the extracted vehicle information. In some embodiments, the binary file may 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, alarms, 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 (which 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 the use of pre-configured vehicle information extraction configurations, while other users may be assigned roles that allow the development of new vehicle information extraction configurations, such as looking deeper into the operation of certain components of the vehicle.

[0047] The management console 410 includes a region interface 434 that determines region boundaries and region boundary resolution that may be used to determine vehicle fleet segments. As further described in FIG. 8, the region interface 434 may be used by a customer to divide the map into grid regions with region-specific identifiers that define the region boundaries, as well as to change the region boundary resolution. Additionally, the management console 410 includes a semantically indexed item interface 436 that defines the types of items that are semantically indexed. 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 regarding movement patterns or other environmental factors of a fleet, which may be used to determine the likelihood that a vehicle is redundant data, thereby causing data to be returned. The indexed item interface 436 may use data aggregated from various sources, including images or other information captured by a fleet of vehicles. In some embodiments, the management console may include a data reduction factor interface 438 that is used by the customer to present the probability of vehicle information being extracted. For example, an engineer may specify a probability of data extraction of a stationary object relative to a patch of vehicles around a stationary object of 0.5 when the number of vehicles in an area is in the range of 100-200.

[0048] It should be noted that in some embodiments, the vehicle data extraction service may restrict the definition of a partition such that the resulting partition has at least a threshold number of vehicles included in the 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, the anonymity of the vehicles 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, dynamic data reduction may be disabled by the vehicle data extraction service once a partition definition is submitted by the customer that results in a partition partition comprised of less than a minimum threshold number of vehicles. Additionally, 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 discussed above, or other thresholds such as 5-10 vehicles. Additionally, on the cloud side of the service, information that personally identifies an individual vehicle may not be collected, or if collected, may be filtered out from being included in the results of the data collection.

[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, in accordance with 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 areas associated with parcels A and B (i.e., “Plot A” and “Plot B”) may be expanded or contracted in size by the vehicle data extraction service and changes in the nature of the parcel, including its boundaries, may be communicated to the vehicle. In some embodiments, multiple parcels may be drawn based on proximity to certain 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, the 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 that include corresponding parcel information including information identifiers. In FIG. 5A, the crossing of a boundary from one parcel to another parcel is based on geographic location, and various changes in the vehicle, such as proximity to identified objects, vehicle speed, or other, may be considered in 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 for dynamic data reduction may be further based on inferences drawn from the vehicle environment.

[0053] In T0, where there may be a certain number of vehicles in a group in section A and section B, vehicle 1 502, vehicle 2 504, and vehicle 3 506 are in the same group of vehicles sending data to the vehicle data extraction service, which may include various models with different OEMs as described in FIG. 1. In T0, the number of vehicles in section A and section B is 12 and 3, respectively. The vehicle data extraction service may maintain one or more tables 508 that include information regarding the data reduction factor / probability of returning selected sensor information for a section / vehicles in the section. Each section may include vehicles receiving a certain data reduction factor / probability that changes based on the number of vehicles in the section if a sufficient change in the number of vehicles occurs such that the model used to reduce data by the service is updated. For example, an increase in the number of vehicles in a section may increase the number of redundant data sent due to the concentration of vehicles in the section. An increase in the number of vehicles in a section may increase the probability that selected sensor data is sent. On the other hand, a decrease in the number of vehicles in a section may decrease the concentration of vehicles in the section, and therefore the probability that selected sensor data is extracted may need to be increased to collect enough data for analysis. Additionally, the data reduction coefficients / probabilities may be based on the presence of various inferences made by the vehicle information extraction service about the environment. For example, the vehicle data extraction service may infer about the collection of objects in the parcel where the vehicle is present based on environmental information such as images detected by the fleet of vehicles, the presence of stationary objects 508, dynamic objects 510, and other inferences made about the parcel. These inferences may be used to determine the data reduction coefficient. For example, the data reduction coefficient may be modified for each parcel based on the total number of dynamic objects 510 near parcel A, or the number of stationary objects in parcel B. Other inferences such as the vehicle movement patterns or the number of traffic lights in the area, or various other inferences about the vehicle environment may be used to determine the data reduction coefficient for a particular type of sensor data. In some embodiments, inferences made about the parcel, such as the presence of dynamic objects 510 or other objects, may be modified by a decay function that has the lifespan that the object may be present in the parcel and the effect of the object 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 dynamically change 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 change based on factors such as the section, the group, and the type of sensor data. Data reduction factor table 508 shows sample threshold ranges required to send updates to vehicles. Figure 5 shows that if the number of vehicles in the section ranges from 0 to 5, the data extraction probability for the selected data of section B is 0.5, and if the number of vehicles in the section ranges from 10 to 15, the data extraction probability for the selected data of section A is 0.3. In some embodiments, instead of a probability set 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, and 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 the vehicle's location.

[0055] At T1, the number of vehicles in Section A and Section B is 10 and 5, 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 at T1 for each section A and B. If the number of vehicles in a section does not exceed the threshold amount required for sending an update, the change in the number of vehicles may not trigger an update of the probability of sensor data extraction in the group. As an example, in FIG. 5A, when the number of vehicles in a section ranges from the minimum threshold of dynamic data reduction (greater than 1) to 5, the probability of data extraction of the selected data of Section B is 0.5, and the probability remains the same, since the total number of vehicles in the group of Section B remains within the range. It should be noted that in an actual implementation, the number of vehicles may be much larger, such as hundreds, thousands, or tens of thousands. However, for ease of explanation, a smaller number of vehicles are used in FIGS. 5A-5C. Similarly, the data extraction probability of the selected data of Section A remains 0.3, since the number of vehicles in the section ranges from 10 to 15. At T1, vehicle 3 is shown moving from section A to section B, and at T2, as the vehicle crosses the section 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 section information in addition to the vehicle's location.

[0056] At T2, the number of vehicles in Section A and Section B are 9 and 6, respectively, and the vehicle data extraction service may update one or more section information tables, resulting in a change in the number of vehicles at T2 for each section A and B. This change in the number of vehicles at T2 in both Section A and Section B causes both sections to exceed the threshold amount. For example, in FIG. 5A, the data extraction probability of Section B's selected data is 0.4 because the number of vehicles in Section B is in the range of 6-10. This is a change from T1, where the total number of vehicles was at a minimum with 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-9 from 10-15. Thus, the data extraction probability of Section A increases to 0.4. In some embodiments, if there is a change in the probability of data extraction of sensor data in a section, a new vehicle scheme may be sent to the vehicles in the group in that section. For example, all vehicles in Section A's group at T2 receive a new vehicle scheme that communicates the new data reduction factor / probability of data extraction of sensor data to each vehicle in Section A.

[0057] FIG. 5B illustrates a vehicle using a dynamic vehicle data extraction service to optimize the amount of data extracted 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 travel in the same direction or with similar movement patterns (e.g., moving at a similar speed, being moved by an identified object, etc.) and may be located in the same partition, partition D. In contrast, vehicle 5 516 may travel in the opposite direction and / or with a different movement pattern and may be located in partition E. As further illustrated in FIG. 8, partitions A and B may be configured based on various geographic regions, while partitions D and E may be based on environmental information and various inferences made regarding 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 the 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 regarding 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 in an overlapping area but 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 may be in the same geographic area, but may be at 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 differences in the environment or other factors such as differences in speed. 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, the interaction of the components 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 that identifies 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 crossing 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 the information to the partition information table 603 and adds the vehicle information associated with the partition identified in the location data 605. In some embodiments, the extracted raw data engine 184 further modifies the vehicle partition table 182 to remove the identified vehicle from the previous partition in which the vehicle 126 was identified to be located and 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 to vehicle addition / removal 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 Figures 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 to updates 614 and determine that the total number of vehicles in a partition has increased / decreased as vehicles enter and exit the partition, where the increase / decrease exceeds a threshold range. In response, the vehicle partition engine 188 may create a new entry or update an existing entry in the vehicle state table 186 to store the respective probabilities of data extraction that the vehicles should have after the change 618. In some embodiments, the vehicle partition engine 188 may query 616 the vehicle partition table 182 to identify all vehicles in the partition and send the new probabilities. The vehicle state table 186 may then be used by the vehicle communication interface 180 to send the new probabilities of data extraction or data reduction factors to relevant vehicles in the group. In some embodiments, a new vehicle schema with updated probabilities and / or data reduction factors may be sent to all vehicles in the group that are in the partition and whose probabilities of data extraction have been changed.

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

[0063] At block 702, a default data reduction scheme is sent to the 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 of 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] At 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 the 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] At block 706, the vehicle information extraction service updates the count for partition G1 and decreases the count for partition G0. At block 708, the vehicle information extraction service determines whether a data reduction model update has been triggered such that the data reduction coefficients in partition G0 are updated. At block 712, the vehicle information extraction service determines whether a model change has been triggered such that the data reduction coefficients applied to the vehicles in partition G1 are updated. In some embodiments, the two blocks (708 and 712) that check whether a trigger has been reached may be executed simultaneously. At block 710, if the trigger is met, the reduction coefficients for all vehicles in partition G0 are decreased. Similarly, at block 714, if another trigger is met, the data reduction coefficients for all vehicles in partition G1 are increased.

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

[0067] In FIG. 8, a geographical region 802 is shown in which a grid system is implemented in which the map is divided into sections with specific boundaries. While latitude and longitude represent a point, the grid system dividing the map may allow for describing areas that may correspond to sections in some circumstances. The areas 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 sections may correspond to the boundaries of the geographical region, while other sections may fall within the boundaries of the geographical region. The sections may not be parallelograms like the illustrated map grid, but may have uneven boundaries.

[0068] For example, FIG. 8 shows a geographic region 802 identified by a low-resolution identifier 804 using the identifier "A2B2". FIG. 8 further shows that the geographic region 802 is further subdivided into six sub-divisions using high-resolution identifiers 806 such as "A1B2C1", "A1B2C2", and "A1B2C...". Each division is assigned a new identifier that starts with the same character string from its parent and ends with a different character, which provides an efficient way to query whether a vehicle is within the bounded area of ​​the map. Each of the divisions or sub-divisions 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 division. For example, division "A1B2C3" may be inferred to have a certain number of miles of major highways and a certain percentage more miles of highways compared to division "A1B2C5". In other embodiments, machine learning techniques may be used to detect and classify certain objects and determine a certain number of stop signs within a division. One or more of the various inferences made from the partition may inform the vehicle data extraction service of potential redundant data and may be used to determine a data reduction factor.

[0069] As discussed in Figures 5A-5C, in one embodiment, the vehicles of the fleet may transmit location data to the vehicle data extraction service, at which point the vehicle data extraction service may identify the partition to which the vehicle belongs and, if a threshold is met, may transmit a new vehicle scheme, including a data reduction factor, to the fleet of vehicles in the affected partition. In some embodiments, the vehicles are configured to transmit location information and / or partition information only when the vehicles cross partition boundaries at a particular resolution. For example, if the vehicles are configured to bind to a low resolution region, such as the low resolution region identified by identifier 804, a change in the vehicle partition from "A1B2C1" to "A1B2C2" will not trigger the transmission of data. However, if the vehicles are 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 vehicles to transmit location information to the vehicle data extraction service. In some embodiments, the locations where partitions may be drawn may be determined by various inferences made by the vehicle information extraction service. For example, partition A1B2C6 may be further divided into sub-partitions. 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 area 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 moving in a particular direction, or a vehicle moving through a particular physical environment, such as a bridge. Segments "A1B2C8" and "A1B2C9" show 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 in place 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 geographical map divided into sections, with the accuracy set by the vehicle data extraction service to determine section boundaries that act as triggers for the vehicle to send location data to the vehicle extraction service. For example, if the vehicle is initially located in section “A1B2C5” 704 and the vehicle section accuracy is set to 6 characters 702, then when the vehicle moves from section “A1B2C5” 704 to the adjacent section “A1B2C6” 710, the detection of movement outside the small section triggers the transmission of location information. When a change is detected from the vehicle’s initial latitude / longitude 722 to the vehicle’s current latitude / longitude 724, the vehicle is triggered to send location information to the vehicle data extraction service. In other embodiments, the 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 particular proximity of an identified object, or detecting a vehicle accident.

[0073] In some embodiments, the precision with which the partition boundaries are determined may be changed. For example, an initial precision may be 6 characters 711 to correlate to partition "A21B2C5" such that the partition identifier is characterized by a 6 character identifier. If the partition precision threshold is changed from 6 characters to 5 characters 712, the current partition 714 "A1B2C" associated with the vehicle's location will be identified with the same precision. In some embodiments, the precision of the vehicle partitions used may vary based on various factors such as vehicle identification, fleet, type of sensor data, etc., 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 partitions with high resolution such as partitions "A1B2C7" and "A1B2C9" not being considered.

[0074] FIG. 10 shows a more detailed view 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, the software application 152 may include multiple layers of the vehicle's network stack that allow it to access and decode communications transmitted over the vehicle's communication bus. For example, a binary file included in the binary file storage of the onboard computing device may indicate the access credentials, protocols, and / or addresses used in the vehicle hardware layer 1010. Additionally, the binary file may indicate the access credentials, protocols, or ports used in the vehicle firmware layer 1008 and / or the vehicle hypervisor layer 1006. Additionally, the binary file may indicate the bus protocol used in the bus layer 1004 and the customer's proprietary protocols and access credentials used in layer 1002. The vehicle information monitoring and extraction software application 152 may use these definitions and access the authentication information included in the binary file to access and decode messages transmitted over the encoded vehicle communication bus 1108. To transmit raw data, the software application 152 may include a vehicle identification certificate from the vehicle identification registry from the control plane of the vehicle information extraction service. The software application 152 may use the rules of decoding described in the decoder rules to decode the communications transmitted over the communication bus. In some embodiments, the decoder rules vary between different models of vehicles and / or between vehicles of different OEMs.

[0076] FIG. 11 illustrates an example 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 to decode various vehicle attributes from the vehicle module configuration into respective on-board communication signals. For example, there are decoder rules that may be used to decode raw vehicle data from various CAN buses, Ethernet / IP buses, LIN, etc. into physical signals such as engine speed, radar amplitude, etc. that 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, which 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 decoded sensor buffer 1202, other data buffer 1 (1204), and other data buffer N (1206) synchronized in time. 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 the storage buffer 1202. Also, in some embodiments, the payload of the data stored in the storage buffer 1202 may include timestamps associated with the stored data generated by other components of the vehicle, such as a timestamp of when a message containing the data was sent to the encoded vehicle communication bus 138, or the time the data was sensed, such as by the physical sensor 136. Thus, in some embodiments, the data may have multiple timestamps associated with it, such as a payload timestamp of when the data was sensed by the physical sensor 136, another payload timestamp of when the data was sent to the encoded vehicle communication bus 138, and another timestamp of when the data was received at the storage buffer 158. In some embodiments, the data stored in the storage buffer 158 may be stored with more or fewer timestamps. Such timestamps may enable, for example, the software application 152 or the extracted data analysis and visualization module 114 of the vehicle information extraction service 102 to reconstruct the exact form of a sequence of events in the vehicle. In some embodiments, the data reduction factor application 156 may select and filter out the data after it is stored in the storage buffer 158. For example, the data reduction factor application 156 applies a data reduction factor to determine that the percentage of temperature data to be filtered is 50% and uses that data reduction factor to remove approximately half of the data stored in the buffer during 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 illustrates 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 vehicle 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 including information used to identify a respective section.

[0084] In block 1306, the vehicle information extraction service determines the total number of vehicles in the fleet that are 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 partition based on the total number of respective vehicles in each partition, the one or more data reduction factors including a probability that a given vehicle of the group in the given respective partition has non-redundant vehicle information compared to other vehicles of the group in the given respective partition.

[0086] At 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 the requested type or types of vehicle information to be extracted and the corresponding data reduction factor 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 on 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 generation of a unified model for a fleet of vehicles, in accordance with some embodiments, and enables requested information specified in the model to be collected from a heterogeneous fleet of vehicles, automatically accounting for variations in on-board communication configurations.

[0089] At 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, the column 1 supplier, or other parts suppliers. In some embodiments, an OEM that is a customer of the vehicle information extraction service may bring such information as part of onboarding the vehicle extraction service. In some embodiments, such information is stored by the vehicle information extraction service and the customer of the vehicle information extraction service does not 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 the 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] In 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, where the data collection scheme includes data extraction criteria for the vehicle sensor information and identifies the vehicle sensor information using the signal attributes of the vehicle model.

[0094] At block 1412, the vehicle information extraction service receives from each vehicle in the fleet vehicle data extracted from each vehicle according to the data collection scheme decoded using the 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 applications / packages deployed from the vehicle information extraction service to the vehicle, the provider network implementing the vehicle information extraction service, the vehicle or device operating system, or any other component of any of the above figures. For example, FIG. 15 illustrates a block diagram showing an example computer system implementing some or all of the techniques described herein, according to some embodiments. In various embodiments, the vehicle information extraction service, the deployed software packages, 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 figures 1-14 may each include one or more computer systems 1500 as shown in FIG. 15.

[0097] In the embodiment shown, computer system 1500 includes one or more processors 1510 connected to a system memory 1520 via an 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 implementing 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, the 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). The processors 1510A-1510N may be any suitable processor capable of executing instructions. For example, in various embodiments, the processors 1510A-1510N may be processors implementing any of a variety of instruction set formats (ISAs), such as the x86, PowerPC, SPARC, or MIPS-ISA, or any other suitable ISA. In some embodiments, the processors 1510A-1510N may include specialized processors, such as graphics processing units (GPUs), application specific integrated circuits (ASICs), and the like. In a multiprocessor system, each of the 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 implementing 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 in the device, including network interface 1540 or other peripheral interfaces. In some embodiments, I / O interface 1530 may perform any necessary protocol conversions, timing conversions, or other data conversions 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, for example, 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, for example, 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 communications over any suitable wired or wireless general data network, such as, for example, a type of Ethernet network, a cellular network, a Bluetooth network, a Wi-Fi network, an ultra-wideband network, etc. Additionally, network interface 1540 may support communications 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, the system memory 1520 may be an embodiment of a computer-readable (i.e., computer-accessible) medium configured to store program instructions and data as described above for implementing the corresponding method, system, and apparatus embodiments. However, in other embodiments, the program instructions and / or data may be received, transmitted, or stored on different types of computer-readable media. Generally speaking, the computer-readable medium may include a non-transitory storage medium or memory medium, such as a magnetic or optical medium, e.g., a disk or DVD / CD, coupled to the computing device 1500 via the I / O interface 1530. The one or more non-transitory computer-readable storage media may also include any volatile or non-volatile medium, such as RAM (e.g., SDRAM, DDR SDRAM, RDRAM, SRAM, etc.), ROM, etc., that may be included in some embodiments of the computing device 1500 as the system memory 1520 or another type of memory. Additionally, the computer-readable medium may include a transmission medium or a signal, such as an electrical signal, an electromagnetic signal, or a digital signal, transmitted over a communication medium, such as a network and / or a wireless link, such as may be implemented via the network interface 1540. Some or all of the computing devices as shown in FIG. 15 may be used in various embodiments to implement the described functionality, e.g., 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 provisions.

[0104] Clause 1. 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 to a vehicle of the fleet each of a plurality of signal decoding rules for decoding signal attributes of the vehicle model into an on-board communication signal; sending a data collection scheme to each of the vehicles 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 is configured to receive from each vehicle of the fleet vehicle data extracted from the each vehicle according to the data collection scheme decoded using the signal decoding rules.

[0105] Clause 2. The system of clause 1, 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.

[0106] Clause 3. The one or more computing devices receiving the signal attributes of respective ones 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; The system of claim 1 or 2, 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.

[0107] Clause 4. The system of clause 3, 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 of the signal catalog.

[0108] Clause 5. The one or more computing devices The system described in clause 4 is 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 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 group.

[0109] Clause 6. 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 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.

[0110] Clause 7. The method of clause 6, 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.

[0111] Clause 8. 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; 8. The method of claim 7, 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.

[0112] Clause 9. The method of clause 7, 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.

[0113] Clause 10. The method of clause 6, 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 decoding of signals formatted according to an on-board communication signal format of each of the vehicles of the group.

[0114] Clause 11. A method according to any one of clauses 6 to 10, 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 to a sensor signal value.

[0115] Clause 12. Associating the sensor signal values ​​with one or more vehicle attributes of the vehicle from which the vehicle data was extracted; 12. The method of claim 11, further comprising publishing the sensor signal values ​​to a time series database.

[0116] Clause 13. The vehicle sensor information Camera data, LiDAR data, Electronic Control Unit (ECU) data, or 13. The method of any one of clauses 6 to 12, comprising one or more of:

[0117] Clause 14. The method of any one of clauses 6 to 13, wherein the signal attributes include static characteristics associated with a particular vehicle, including a unique vehicle ID, a vehicle brand, a body type of the vehicle, and an engine model of the vehicle.

[0118] Clause 15. The method of any one of clauses 6 to 14, wherein the data collection scheme further includes 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 of the collection of vehicles, and the extracted data being extracted from only a portion of the collection of vehicles.

[0119] Clause 16. When executed on or between one or more computing vehicles, said one or more computing vehicles may generating a vehicle model compiling a subset of signal attributes of the plurality of signal attributes; transmitting to a vehicle of the fleet each of a plurality of signal decoding rules for decoding signal attributes of the vehicle model into an on-board communication signal; transmitting a data collection scheme to each of the vehicles 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 the signal attributes of the vehicle model; and receiving, from each vehicle of the fleet, vehicle data extracted from the each vehicle according to the data collection scheme that is decoded using the signal decoding rules.

[0120] Clause 17. When the instructions are executed on or between the one or more processors, the instructions further provide the vehicle information extraction service with: The one or more non-transitory computer-readable storage media described in clause 16, 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 a sensor signal value.

[0121] Clause 18. When the instructions are executed on or between the one or more processors, the instructions further provide the vehicle information extraction service with: Associating a given sensor signal value with one or more vehicle attributes of the vehicle from which the vehicle data was extracted; 20. The one or more non-transitory computer-readable storage media of clause 17, implementing the steps of: publishing the sensor signal values ​​to a time series database.

[0122] Clause 19. The vehicle sensor information Camera data, LiDAR data, Electronic Control Unit (ECU) data, or 19. One or more non-transitory computer-readable storage media according to any one of clauses 16 to 18, comprising one or more of:

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

[0124] Clause 21. 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 carried by respective vehicles of 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 the vehicles in each of the partitions based on the respective total number of vehicles in each of the partitions, the one or more data reduction factors including a probability that a given vehicle of the group in a given respective partition has non-redundant vehicle information compared to others of the vehicles of the group in the given respective partition; transmitting one or more vehicle scheme packets to one or more of the vehicles in the fleet, 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 the 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 of the fleet located in each of the one or more compartments in accordance with the one or more data reduction factors; The system comprising:

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

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

[0127] Clause 24. The one or more computing devices Modifying the inferred vehicle environment according to a decay function; 24. The system of claim 22 or 23, further configured to determine the data reduction factor based on the inferred vehicle environment modified by the respective decay function.

[0128] Clause 25. The partition is determined based on a position of each of the respective vehicles indicated in the received one or more vehicle information packets; 25. A system according to any one of clauses 21 to 24, wherein temporal proximity is in which the respective vehicles are located in close proximity to each other.

[0129] Clause 26. 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 carried by respective vehicles of 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 a 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 that are located in the given section according to the data reduction factor; The method comprising:

[0130] Clause 27. Further comprising: inferring a vehicle environment for a vehicle 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; 27. The method of claim 26, wherein the data reduction factor is further determined based on the inferred vehicle environment for the given segment.

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

[0132] Clause 29. The method further includes modifying the inferred vehicle environment by a respective damping function of stationary objects, semi-stationary objects, or dynamic objects; 29. The method of claim 27 or claim 28, wherein the data reduction factor is further based on the inferred vehicle environment modified by the respective attenuation functions of stationary objects, semi-stationary objects, or dynamic objects.

[0133] Clause 30. The partition is determined based on a position of each of the respective vehicles indicated in the received one or more vehicle information packets; 30. The method of any one of clauses 26 to 29, wherein temporal proximity is in which the respective vehicles are located in close proximity to each other.

[0134] Clause 31. Receiving another vehicle information packet provided by a second one of the vehicles of 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; 30. The method of any one of clauses 26 to 29, 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.

[0135] Clause 32. Determining a second data reduction factor to be applied to the vehicles in the given section based on an updated version of the total number of the vehicles in the given section that exceeds the model update threshold, the second data reduction factor including a second probability that each one of the vehicles in the group in the given section will have non-redundant vehicle information compared to other ones of the vehicles in the group in the given section; The method of any one of clauses 26 to 31, 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.

[0136] Clause 33. A method according to any one of clauses 26 to 32, wherein the fleet of vehicles includes vehicles which have selected a data reduction setting for information extraction.

[0137] Clause 34. Determining a second data reduction factor to be applied to each vehicle of a second group of vehicles based on a total number of vehicles of the group and a second group included in the given section, the second data reduction factor comprising a second probability that a given vehicle of the second group that is in the given section will have non-redundant vehicle information compared to others of the vehicles of the first group or the second group that are included in the given section; The method of any one of clauses 26 to 33, 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.

[0138] Clause 13. The one or more types of vehicle information extracted from the vehicle fleet are Camera data, LiDAR data, Electronic Control Unit (ECU) data, or 35. The method of any one of clauses 26 to 34, comprising one or more of:

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

[0140] Clause 37. The one or more vehicle scheme packets instruct the vehicle to store the vehicle information in a vehicle data storage during a period in which 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; 36. The method of any one of clauses 26 to 35, 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.

[0141] Clause 38. A method according to any one of clauses 26 to 37, wherein the vehicles of the fleet include vehicles having different in-vehicle 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 in-vehicle communication architectures.

[0142] Clause 39. When executed on or between one or more computing vehicles, the one or more computing vehicles are 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 carried 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 a corresponding data reduction factor to be applied; and receiving the requested one or more types of vehicle information from only a portion of the vehicles of the fleet located in the given section according to the data reduction factor.

[0143] Clause 40. When executed on or between said one or more processors, said one or more processors are The one or more non-transitory computer-accessible storage media described in clause 39, storing further program instructions implementing: 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 factor being further determined based on the vehicle environment.

[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 of the methods may be changed, and various elements may be added, rearranged, combined, omitted, modified, etc. For example, in one embodiment, the methods may be implemented by a computer system including a processor executing program instructions stored in a computer-readable storage medium coupled to the processor. The program instructions may be configured to implement the functions described herein (e.g., functions of data transfer tools, various services, databases, devices and / or other communication devices, etc.).

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

[0146] Various embodiments may further include receiving, transmitting, or storing instructions and / or data executed in accordance with the above 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, and transmission media or signals, such as electrical, electromagnetic, or digital signals conveyed over a communication 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, 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 to a vehicle of the fleet each of a plurality of signal decoding rules for decoding signal attributes of the vehicle model into an on-board communication signal; Transmitting a data collection scheme to each of the vehicles 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 one or more computing devices configured to receive from each vehicle of the fleet vehicle data extracted from the each vehicle according to the data collection scheme decoded using the signal decoding rules; The system comprising:

2. 2. The system of claim 1, 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 a respective one of the vehicles uses.

3. The one or more computing devices include receiving the signal attributes of respective ones 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; The system of claim 1 or claim 2, 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.

4. The system of claim 3 , wherein the signal configuration of the vehicle model omits signals for which no decoding rule exists in the signal catalog for mapping a vehicle-specific signal name to the respective signal attribute in the signal catalog.

5. The one or more computing devices include 5. The system of claim 4, 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 of the signal catalog corresponding to respective ones of a plurality of signal attribute names, the sensor-specific signal decoding rules enabling decoding of signals formatted according to an on-board communication signal format of each of the vehicles in the fleet.

6. 1. 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 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 vehicle data from each vehicle of the fleet, the vehicle data extracted from each vehicle according to the data collection scheme, the vehicle data being decoded using the transmitted signal decoding rule; The method comprising:

7. 7. The method of claim 6, 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 a respective one of the vehicles uses.

8. 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; 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; The method of claim 7 further comprising:

9. 9. The method of claim 7 or 8, 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.

10. 10. The method of claim 6, 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 that correspond to respective ones of a plurality of signal attribute names, the sensor-specific signal decoding rules enabling decoding of signals formatted according to an on-board communication signal format of each of the vehicles in the fleet.

11. 11. The method of claim 6, further comprising: decoding the vehicle data extracted from the respective vehicle using the signal decoding rules, wherein the received vehicle data is decoded from a binary resource to a sensor signal value.

12. Associating the sensor signal values ​​with one or more vehicle attributes of the vehicle from which the vehicle data was extracted; The method of claim 11 , further comprising publishing the sensor signal values ​​to a time series database.

13. The vehicle sensor information includes: Camera data, LiDar data, Electronic Control Unit (ECU) data, or The method of claim 6 , further comprising one or more of the following:

14. The method of claim 6 , wherein the signal attributes include static characteristics associated with a particular vehicle, including a unique vehicle ID, a vehicle brand, a body type of the vehicle, and an engine model of the vehicle.

15. 15. The method of claim 6, 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 set of vehicles in a given geographical area and on an inference of a vehicle environment of the set of vehicles, and the extracted data being extracted from only a portion of the set of vehicles.

Images