KR20240096706A - Fleet data collection using a unified model to collect data from heterogeneous vehicles - Google Patents

Abstract

A system including one or more computing devices implements a vehicle information extraction service. The vehicle information extraction service allows customers to maintain a model of a fleet of vehicles and collect vehicle information from heterogeneous vehicles included in the fleet, and the vehicles are composed of different in-vehicle communication configurations. The vehicle information extraction service automatically generates scheme packets for data collection to be transmitted to heterogeneous vehicles and formats them according to the different in-vehicle communication configurations of the heterogeneous vehicles without the customer of the vehicle information extraction service having to consider these differences. do.

Description

Fleet data collection using a unified model to collect data from heterogeneous vehicles

Modern vehicles such as cars, trucks, motorcycles, etc. are often manufactured with electronic sensors and programmed with control algorithms that take inputs from these electronic sensors and determine various control actions to be taken for the vehicle or the systems implemented in the vehicle. Includes computer systems. Some vehicles can contain up to 70 of these electronic control units (ECUs) and 20-30 or more types of sensors. Additionally, modern vehicles increasingly rely on sensors that generate more data than their predecessors. For example, an autonomous, semi-autonomous, or self-driving vehicle may include multiple cameras, radar, LiDar sensors, audio microphones, etc. These sensors can generate significant amounts of data, for example 5-10 terabytes or more per hour. Transferring such large amounts of data to a separate service for data analysis is not a trivial problem.

Additionally, vehicle information may be in a format that requires decoding or access to vehicle specific configuration information. For example, the formats through which vehicles communicate may be specific to vehicle manufacturers and may require decoding of different in-vehicle communication formats depending on the configuration of these manufacturers. Moreover, in a fleet of heterogeneous vehicles using different signal formats, a common method of collecting data cannot be used for the fleet without taking into account the different signal formats and in-vehicle configurations.

1 illustrates that vehicles of different sensor signal formats, including a single fleet of vehicles, can be used for data collection and analysis by associating a number of decoder rules for different in-vehicle communication signal configurations with a vehicle model configuration, according to some embodiments. a vehicle information extraction service that enables information to be extracted from each of the vehicles based on the partition of the fleet, the number of vehicles within the partition, and inferences about objects in the vehicle environment determined based on previously collected vehicle information. exemplifies.
2 illustrates a more detailed view of a vehicle information extraction service, various parts thereof, and interactions that separate vehicle model configuration from vehicle-specific in-vehicle communication signal configuration, according to some embodiments.
3 is an example of using a vehicle signal catalog to collect data using a common data collection scheme across a fleet of heterogeneous vehicle models and having a hierarchical tree structure that allows a unified signal representation to be used, according to some embodiments. Illustrates a graphical view of a typical vehicle model configuration.
4 illustrates a more detailed view of the designer canvas and management console of a service user interface for a vehicle information extraction service, according to some embodiments.
5A illustrates a more detailed view of a fleet of vehicles that determines a data reduction factor to be applied to information extracted from vehicles in the fleet using a dynamic vehicle data extraction service, according to some embodiments. The service optimizes the amount of data extracted based on vehicle environment, vehicle movement, and vehicle density changes at different points in time due to various partitions.
5B illustrates a dynamic vehicle data extraction service that applies dynamic data reduction to multiple non-uniform partitions based on similarity of vehicle mobility patterns, according to some embodiments.
5C illustrates a dynamic vehicle data extraction service that applies dynamic data reduction to multiple non-uniform partitions in areas that overlap each other and are at different altitudes, where the overlapping partitions are located in the vehicle environment or other environments, according to some embodiments. It is determined based on environmental factors.
6 illustrates a logical block diagram illustrating the various components of a vehicle data extraction service, the interaction of the components with vehicle movement, and the impact of vehicle movement on the respective probability of data extraction, according to some embodiments. .
7 illustrates a flow diagram of operations performed by a vehicle information extraction service in connection with a transition from one partition of a vehicle to another, updated probabilities for data extraction and/or data reduction, according to some embodiments. Operations for determining whether a factor should be transmitted are illustrated.
8 illustrates a method for partitioning a map into regions, enabling illustration of region boundaries for multiple regions, and changing the resolution of the boundaries to vary the granularity and/or vehicle count per region, according to some embodiments. Illustrates an example map used in a vehicle data extraction service that enables
9 illustrates the effect of changing the resolution of an example map of a vehicle data extraction service that divides the map into grid regions to define boundaries of the regions, according to some embodiments.
10 illustrates a more detailed view of in-vehicle communication configurations of an example network stack of protocols used at different levels to communicate vehicle information over the vehicle's bus, according to some embodiments.
11 illustrates an example vehicle including multiple different buses that can be monitored for data extraction by a software application deployed by a vehicle information extraction service, according to some embodiments.
12 illustrates a more detailed view of a storage buffer that may be used by an application deployed by a vehicle information extraction service, where the storage buffer is stored when one or more triggering criteria are met, according to some embodiments. Apply a data reduction factor and store data from one or more preceding time points suitable for extraction.
13 illustrates that a vehicle information extraction service is used to apply data reduction to the amount of information to be extracted from vehicles in a fleet based on the partition criteria and the number of vehicles in the fleet within the partition, among other factors, according to some embodiments. Illustrating a flow chart of the operations performed.
14 allows a unified model to be created for a fleet of vehicles, automatically taking into account variations in in-vehicle communication configurations so that requested information specified in the model can be collected from heterogeneous fleets of vehicles, according to some embodiments. This illustrates a flow chart for implementing a modeling system in a vehicle information extraction service.
Figure 15 illustrates a block diagram illustrating an example computer system implementing some or all of the techniques described herein, according to some embodiments.
Although embodiments are described herein by way of example for some 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 form disclosed, but on the contrary, all modifications, equivalents, and alternatives falling within the spirit and scope as defined by the appended claims. It should be understood that it is intended to encompass alternatives and examples. Headings used herein are for organizational purposes only and are not intended to limit the scope of the description or claims. As used throughout this application, the word "may" is used in an idiomatic sense (i.e., having the potential) rather than in an essential sense (i.e., meaning to do). Similarly, the words “comprise,” “including,” and “including,” mean including but are not limited to.

Systems and methods described herein include techniques for implementing a vehicle information extraction service and implementing in-vehicle data monitoring and extraction using a software package generated by the vehicle information extraction service. As modern vehicles such as cars, trucks, motorcycles, etc. become more advanced, electronics are utilized for a variety of applications ranging from increasing the fuel efficiency of vehicles to enabling greater degrees of automation using artificial intelligence (AI). We are equipped with more and more sensors. Vehicles are generating exponentially more data with each new generation of vehicles, and are beginning to become not only mechanically distinct from one another, but increasingly by software. Moreover, the fastest-growing trends in the automotive industry often involve autonomous vehicles (AV), advanced driver assistance systems (ADAS), and electric vehicle technologies, all of which often consume more than two terabytes (TB) of data per hour. It employs a wide range of sensors to generate Additionally, the types of sensors we increasingly rely on often generate larger amounts of data. For example, modern vehicles increasingly rely on multiple high-resolution cameras, where a single high-resolution camera can generate data at speeds of more than 3,500 megabits per second. Despite advances in wireless technology, such as fifth generation (5G) technology standards for broadband cellular networks, the bandwidth for transmitting vehicle data poses significant limitations considering the large number of vehicles, each with an increasing number of sensors. . Additionally, the law of diminishing returns usually applies to large-scale data collections, where additional bytes of sensor information collected may have smaller values than previous bytes—transferring information from the vehicle to a remote service is expensive. In vehicles with barriers, these reduced values translate directly into waste. However, vehicle data may need to be continuously collected to operate the vehicle model as well as to continually build and improve it. However, reducing the redundant data involved will lower the cost of transporting and/or storing collected vehicle data. Because vehicles are not stationary and often change location, optimization of data transmission at a single vehicle edge device may not be sufficient and optimization at the vehicle fleet level may be required.

Optimization of data collection at a vehicle edge device for a fleet of vehicles can be achieved by considering the data collected as being collected from the fleet of vehicles as a whole rather than from individual vehicles. In the real world, vehicles often move in swarms or waves and interact with many aspects of the environment being structured and remaining the same, which means that sensors from the vehicles (e.g. in a swarm or wave) often overlap. obtain data. In some embodiments, a cluster or wave of vehicles may refer to vehicles that share common characteristics. For example, during the morning rush hour, sets of vehicles traveling in the same set of lanes heading in the same direction on a highway may move together as a conglomerate of vehicles. As another example, a set of vehicles accelerating from a rest position in response to red light changing to green may move together as a wave of vehicles. Many sets of sensor data collected from vehicles can be assumed to be redundant when considered as part of a swarm or wave of vehicles, and to avoid redundant data collection, a significant amount of this vehicle sensor data is sent to a data processing service. It can be omitted. This data reduction can reduce the load placed on the bandwidth of the network used by vehicles to report collected vehicle information and reduce the resources needed to store and process sensor data. For example, a cluster or wave of vehicles within or around the same geographic location and time period will each detect similar temperatures with a temperature sensor. Temperature data may be assumed to be redundant, and the data extraction service may require only a subset of vehicles in a swarm or wave to transmit temperature data. This optimization of vehicle data collection can be extended to other types of sensors, such as various ECU sensors, image sensors, etc. In some embodiments, the fleet of vehicles for which data collection will be applied may be specified by the customer and may include heterogeneous types of vehicles. In some embodiments, fleets may be defined based on criteria associated with vehicles such as “make,” “model,” etc. In some embodiments, members of a fleet may adjust as more makes or models are added or removed from the fleet.

In some embodiments, the geographic location of a 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. Additionally, in some embodiments, a vehicle may determine or update its location using local sensors and/or algorithms, such as using computer vision, LiDar, vehicle odometer, etc. In some embodiments, the disclosed systems may function properly without requiring specific location accuracy. For example, partitions can be formed based on positions relative to other vehicles and objects of interest, and will function properly even if actual location accuracy is not achieved by the system providing vehicle location information.

For example, a cluster or wave of vehicles traveling along a road may encounter many of the same or similar environmental objects, which may result in photos being captured that may be considered duplicates. Additionally, any vehicle that shows similar mobility patterns or faces similar environmental factors can be assumed to return a large number of duplicate data pieces. The vehicle information extraction service aggregates from various sources, including images or other information acquired by a fleet of vehicles, to make inferences about the environment and calculate the likelihood that vehicles within a particular partition of vehicles will return pieces of duplicate data. data can be used. To reduce the number of pieces of redundant data returned, a model of a fleet of vehicles can be created, and the density of vehicles in the fleet of that partition can be obtained to determine a reduction factor. This reduction factor can be communicated to the vehicle using the vehicle scheme packet. A 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 particular type of sensor data will be transmitted may differ between different types of sensors on a given vehicle and/or between different vehicles belonging to different vehicles. In some embodiments, a customer of a dynamic data extraction service may wish to collect data from a fleet of vehicles operated or managed by the customer. Additionally, in some embodiments, vehicles in a fleet may be partitioned into different partitions, in some embodiments, clusters or waves of each vehicle in a fleet and/or vehicles in another fleet participating in the dynamic data reduction and/or vehicle data extraction service. It can be determined based on behavior such as .

A vehicle data extraction service that allows modeling, collecting, and storing data from a fleet of vehicles configured with different in-vehicle communication formats may enable greater flexibility and capabilities for data collection. One challenge in extracting vehicle data from customer vehicles arises from different models of vehicles having different in-vehicle communication formats, creating barriers for vehicle data collection, model creation, and analysis. For example, in one vehicle speed information may be available in a vehicle model in which the vehicle's engine control unit (ECU) is connected via a Connected Area Network (CAN) bus, while in another vehicle the speed information may be available in a vehicle where the ECU is connected via Ethernet. It may be available in different models that are connected. In some embodiments, the disclosed vehicle data extraction service, which separates vehicle model configuration from in-vehicle communication signal configuration specific to individual vehicles, overcomes this problem.

Separating vehicle model configuration from in-vehicle communication signal configuration specific to individual vehicles also allows different users to work independently on different parts of the model, and unified signal representations can be used across a heterogeneous fleet of vehicle models. let it be For example, by separating the vehicle's signal format, expressed in model configuration, from the in-vehicle communication signal configuration expressed in the decoder rules of each type of vehicle, a single analysis application is possible regardless of vehicle model, which may have different decoder rules. This can be used. As used herein, “decoder rules” includes any rules related to the decoding of signals and may be used interchangeably with “decoding rules” and/or “signal decoding rules.” Additionally, a single workflow executed to apply a data collection configuration that defines rules for when and how to collect data from vehicles can be executed across a fleet of heterogeneous vehicle models in this service.

1 relates a number of decoder rules with different in-vehicle communication signal configurations to a vehicle model configuration so that vehicles of different sensor signal formats that may comprise a single fleet of vehicles can be used for data collection and analysis, according to some embodiments. and/or illustrates a vehicle information extraction service that allows information to be extracted from each of the vehicles based on inferences based on the partition of the fleet, the number of vehicles in the partition, and inference of the vehicle environment. Extractions based on partition, vehicle count, and/or vehicle environment may have dynamic data reduction applied to the collected data such that redundant data collection is reduced.

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

In some embodiments, vehicle information extraction service 102 may include control plane 104, data storage 114, and data plane 112, as further discussed in FIG. 3. Control plane 104 allows customers 122a, 122n to register vehicles, model vehicles, and manage data collection workflows for a single vehicle or across a fleet. Data plane 112 serves as a processing pipeline for obtaining raw vehicle data, decoding the data, and storing and/or retrieving the vehicle data. In some embodiments, the various components of vehicle information extraction service 102 may be further partitioned into various subsystems with a distributed and/or separate format to independently manage the scalability and throughput requirements of the subsystems. there is. Data plane 112 also decodes extracted vehicle data 148 obtained from vehicles 142, 143, and 144 using constructs such as decoder rules and model constructs of various vehicles maintained by control plane 104. and can be enriched. In some embodiments, vehicle information extraction service 102 and various subsystems within vehicle information extraction service 102 may cause data plane 112 to respond to sudden bursts of traffic during events such as recovery from a power outage or processing error. (104) can be separated and maintained in different environments to prevent overwhelm. Customers 122a and 122n interact with control plane 104 to perform vehicle modeling, vehicle sensor testing, vehicle asset registration, vehicle fleet definition, and data collection scheme management through extraction service requests 118 and 120.

In some embodiments, control plane 104 may include a vehicle identification registry 110, a data collection scheme controller 108, and a service user interface 106 to perform extraction service requests 118. . Service user interface 106 may include a designer canvas and management console as further discussed in FIG. 4 . In some embodiments, customers may use the encoding format used to communicate vehicle information over the bus from customer-designed components (e.g., vehicle supplier and/or vehicle component supplier) and/or associated proprietary access credential files. Dictionary files describing the protocols and proprietary protocols can be provided. For example, customers 122a, 122n may provide extraction service requests 118, 120 containing decoder rules used to decode raw vehicle data into physical measurements, such as a CAN database (CAN DBC). It can be used to decode raw data from the vehicle's CAN bus frames into physical signals such as engine speed, radar amplitude, etc. In some embodiments, extraction service requests 118, 120 may include data collection schemes that define rules for collection of data from the fleet's vehicles. A data collection scheme may represent extraction criteria (also referred to herein as “data extraction criteria”) for vehicle sensor information, and may reduce and/or collect data by reducing redundant data, as further discussed in FIGS. 5A-5C. You can define rules that control optimization. Note that the decoder rules and data collection scheme, including the extraction criteria, are shown in Figure 1 as being part of the same system. However, in some embodiments, the decoder rules and data collection scheme may be used separately.

In some embodiments, vehicle identity registry 110 of control plane 104 provides a create, read, update, and delete (CRUD) application programming interface (API) for managing a registry of vehicle identities within a fleet. can do. The vehicle identification registry 110 may store a key value record having vehicle identification information (vehicle ID) as a key, vehicle manufacturer, vehicle model, and other vehicle attributes as values such as location, construction date, engine type, fuel type, etc. You can save them. Vehicle models created using a modeling service may also be associated in a similar tuple format. The vehicle identification registry 110 may facilitate rotation and revocation of vehicle identification certificates as well as change of ownership. In another embodiment, customers 122a, 122n may use their own certificate authority (CA) to onboard vehicles 142, 143, 144 in the fleet and manage vehicle identification certificate rotation and revocation. In some embodiments, control plane 104, 110 may authenticate certificates signed by the customer's CA. Vehicle identification registry 110 may also facilitate grouping of vehicles into fleets by customers 122a and 122n based on various criteria defined by certain fleet rules. Fleet rules may use any number and/or combination of vehicle attributes to group fleets of vehicles together. For example, a fleet rule can create a fleet of all vehicles in a specific geographic area, such as a city or state, or create a fleet that targets specific vehicle makes and models. The vehicle identification information registry 110 maintains the status of all of the various fleets as vehicles in the fleet are added, removed, or updated.

In some embodiments, data collection scheme controller 108 allows customers 122a, 122n to define and manage data collection schemes for a single vehicle or fleet of vehicles, and allows various vehicle data to be stored on in-vehicle computing device(s) 150. ) can be used to manage the conditions transmitted from. The data collection scheme controller 108 configures a vehicle configuration 146 that defines the rules the vehicles 142, 143, and 144 use to determine when, where, and how to transmit the various information collected by the various sensors. Generate data collection scheme packets containing The data collection scheme controller 108 then verifies the plan against the vehicle's model configuration and resolves conflicts across schemes based on customer-defined priorities. If it is determined that a vehicle scheme applies to the fleet, the data collection scheme controller 108 may operate in conjunction with the vehicle communication interface 180 to apply the scheme to the designated vehicles in the fleet. In some embodiments, details of a data reduction factor to reduce 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, data collection scheme controller 108 applies rate control to safely propagate the scheme across flits without errors due to increased propagation speed. Errors may be detected by monitoring health metrics published by in-vehicle computing device(s) 150 and/or by monitoring active vehicle connections between vehicles 142, 143, 144 and vehicle communication interface 180. You can. In some embodiments, a data collection scheme may be used to filter data from in-vehicle computing device(s) 150 (e.g., data reduction) based on vehicle attributes, such as vehicle engine type and other vehicle model parameters/attributes. You can define customized rules that perform . In some embodiments, vehicle scheme packets specify the cadence (e.g., every 5 minutes) at which one or more pieces of sensor data are transmitted, the schedule or duration (e.g., from the current time to 20 minutes), and a trigger event. (eg, the vehicle's critical braking speed or the vehicle's departure from the lane). In some embodiments, the trigger event may be a heartbeat and data propagation may occur continuously at a fixed cadence.

In some embodiments, decoder rules may be sent to vehicles via vehicle scheme packets and/or via a separate manifest/configuration. Decoder rules provide the parameters needed to decode sensor data, such as protocol name, bus standard (e.g. CAN bus standard), message ID, scale, offset, etc. for the message the sensor is multiplexing.

In some embodiments, decoder rules may be used by vehicle information extraction service 102 to decode signals as needed in a remote location, such as a cloud-based implementation. In another embodiment, the decoder rules are applied to the in-vehicle computing device 150 of the vehicle (or other vehicle edge device) to transmit the decoded signal to the vehicle information extraction service 102, rather than to the vehicle information extraction service 102. It can be applied. In some embodiments, a desired vehicle fleet may include heterogeneous types of vehicles, and the model configuration may include multiple decoder rules (if the decoding rules are different for the heterogeneous types). For example, decoder rule A 162, decoder rule B 163, and decoder rule C 164 may be sent to each vehicle 142, 143, and 144 with different signal semantics. In some embodiments, each set of decoder rules provides decoding rules for all signals in the model configuration. The model configuration and decoder rules may have a one-to-many relationship, where multiple decoder rules (e.g., decoder rules A 162, decoder rules B 163, and decoder rules C 164) ) can 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 vehicle of the vehicle.

In some embodiments, data collection scheme controller 108 may manage a signal catalog. The signal catalog may contain signal attributes used by OEMs across multiple models of their vehicles or sensors. The signal catalog may follow the Vehicle Signal Specification (VSS) naming guide and may be accessible using normalized names (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 of the data plane 104 can ensure that signal IDs are unique across the signal catalog. In some embodiments, customers 122a, 122n may create multiple signal catalogs. Multiple signal catalogs may contain signal properties that can be used to model different types of vehicles. For example, a catalog for cars, a catalog for trucks, a catalog for motorcycles, etc. may be created. A signal catalog for the same vehicle type may have a single catalog to represent all signals for a vehicle type, but in some embodiments, multiple signal catalogs may be used to represent different subsets of signals for the same vehicle type. You can. The term “subset” as used herein may not be limited to attributes of one vehicle type, but may include one, all, or any number of attributes from 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 discussed further in FIG. 2, the data collection scheme controller 108 of the data plane 104 controls the heterogeneous vehicles within the fleet through a workflow that applies the same data collection scheme when extracting data from the heterogeneous vehicles within the fleet. To enable a unified signal representation for the vehicle data extraction service 102 to collect data across the vehicle model configuration, a signal catalog and decoder rules may be used to manage the vehicle model configuration.

In some embodiments, data plane 112 supports receiving raw data from vehicles 142 , 143 , 144 and conveying various types of vehicle information, such as vehicle partition and vehicle status, to which vehicle belongs to data storage 114 . managed, where the information may be stored in the vehicle state table 186 and vehicle partition table 182, respectively. In-vehicle computing device(s) 150 can access data plane 112 via a client certificate authentication (e.g., X.509 certificate) and private key obtained when the vehicle is registered with vehicle identification registry 110. The connection with the vehicle information extraction service 102 can be authenticated using. In some embodiments, data plane 112 establishes a secure connection with each of the vehicles, such as vehicles 142, 143, and 144, to transmit software package 146 and receive extracted vehicle data 148. It includes a vehicle communication interface 180 configured to. In some embodiments, extracted raw data engine 184 may store extracted vehicle data 148 in a separate storage account of customer 122a, 122n, such as by a provider network that also implements vehicle information extraction service 102. It can be saved to the storage account of the provided storage service. For example, a customer may have an account with different services provided by a service provider network that also provides vehicle information extraction services. Accordingly, the customer can specify whether the extracted vehicle information will be delivered to the account as a predetermined service of the service provider network, such as an object-based storage service, an archive data storage service, a machine learning service, etc. Vehicle partition engine 188 of data plane 112 may use location information and or other sensor information from the fleet vehicles to determine which partition of the fleet each vehicle is associated with. 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 mobility patterns or similar environmental factors that can be assumed to result in redundant data collection. . This type of information can be used to partition fleets. In some embodiments, partitions may be determined based on geographic location and/or other factors. In some embodiments, the partition may be determined using two-dimensional factors, where the two dimensions are the spatial proximity of the vehicles and the temporal proximity of the spatial proximity. More specifically, it tells you how recently or how long vehicles have been close to each other. For example, partitions A and B may be determined based on geographic proximity in a given time window.

In some embodiments, partitions of a fleet may be determined based on proximity to various inferences made about the environment. For example, vehicle partition engine 188 may use aggregated data from vehicles 142, 143, and 144 to determine that semantically identified object 192 exists in the environment at a particular frequency. Based on proximity to identified object 192 and/or frequency of appearance of identified object 192, along with location and time proximity variables to other vehicles, vehicle 143 may be assigned to partition C. there is. In some embodiments, a vehicle may be part of multiple partitions of a fleet. For example, vehicle 143 may be part of partition A as well as partition C. Data collection probability engine 190 can then determine an appropriate data reduction factor for communicating with vehicles in specific areas via vehicle scheme packets. Data collection probability engine 190 may use a variety of different inferences drawn from the environment to calculate that vehicles within a given partition are likely to return duplicate data. In some embodiments, inferences may include inferences drawn from a list of vehicle detected objects identified using machine learning techniques, stationary, semi-stationary, or dynamic classification of detected objects, presence of an accident, etc.

In some embodiments, the model may be created on the service side of a data extraction service. The model determines the frequency of occurrence of certain types of objects in the environment for which data from vehicles will be collected/extracted, and how likely it is that a given vehicle or vehicle type exhibiting common vehicle behavior (e.g. moving in a pack or wave) will encounter the object. In addition to modeling temporal proximity, for example, how quickly a given vehicle is likely to encounter a given object. Based on these model parameters, the service side of the data extraction service can generate data reduction factors to be applied to vehicles belonging to each partition. In some embodiments, partitions may simply correspond to geographic areas. However, in the same or another embodiment, partitions may be based on both spatial and temporal dimensions. In some embodiments, partitions may be determined based on other factors. For example, a set of vehicles in geographic proximity and temporal proximity that exhibit common vehicle behavior, such as traveling at speeds that overlap the speed ranges of surrounding vehicles, may be grouped into a common partition. For example, such a partition may resemble a group of vehicles traveling at the same speed and close to each other at the same time on a stretch of interstate highway. In some embodiments, partitions may be dynamically updated based on changes in vehicle behavior. As another example, in some embodiments, common vehicle behaviors used to group vehicles into common partitions may be determined using an origin destination (OD) matrix estimation process. For example, this estimation process may identify groups of vehicles traveling toward the same destination or between the same origin and destination and group these vehicles into groups that will be used to form partitions. In some embodiments, the data extraction service may estimate origin destination flows for vehicles between sets of points and send data reduction probabilities to grouped vehicles, where the data reduction probabilities are based on the vehicle density and It is determined based on the estimated trajectory of the vehicle, along with other factors as described herein, such as the prevalence of objects of interest in the environment in which the vehicles are traveling according to the determined trajectory. In some embodiments, if the current updated model maintained on the service side of the vehicle data extraction service differs from a previous version of the model used to generate scheme packets transmitted to the fleet's vehicles by one or more thresholds, then the updated scheme packet may be issued to vehicles reflecting data reduction parameters according to the updated model.

In some embodiments, the data plane 112 of vehicle information extraction service 102 may further orchestrate the analysis and/or visualization to be performed on the extracted vehicle data 148. For example, extracted vehicle data can be compared to alarm triggers for alarms that cause notification to the customer. Additionally, the extracted vehicle information may be organized into visual graphics such as charts, graphs, or other user interface tools for presentation to customers. In some embodiments, the extracted vehicle information may be used to train an artificial intelligence (AI) model, or may be provided to a machine learning tool to optimize the vehicle's settings. Once authenticated, vehicles 142, 143, 144 may transmit data to vehicle information extraction service 102 using various publish-subscribe network protocols or other network protocols, such as the MQTT protocol, to transmit messages. In some embodiments, video frames acquired using one or more video/audio sensors 132 may be transmitted using encoded video formats, such as Advanced Video Coding, also known as H.264. In some embodiments, in-vehicle computing device(s) 150 may obtain temporary credentials to upload various sensor data. The data plane 112 can directly ingest the extracted raw vehicle data 148, after which the extracted raw data engine 184 configures the vehicle model to decode the raw extracted data into physical telemetry messages. You can use it. In some embodiments, the extracted raw vehicle data includes video frames, images, radar amplitude, temperature data, engine speed, and other information about the vehicle. In some embodiments, decoded telemetry data may be enriched with vehicle attributes and published to a time series database in data storage 114. Enrichment of vehicle data by associating vehicle properties allows a user to query vehicle data using the vehicle's properties and/or events of interest. In some embodiments, a unique object URL may be associated with a record containing vehicle data and may be published in a time series database.

In some embodiments, in-vehicle computing device 150 may implement a gateway for vehicle 126 or otherwise provide access to data transmitted over one or more buses of the vehicle, such as vehicle communication bus 138. It may be a component of the vehicle 126 having. In some embodiments, the vehicle's bus transmits multicast vehicle information transmitted from multiple components of the vehicle, such as electronic control unit 128 (ECU #1) and electronic control unit 130 (ECU #2). can do. Additionally, other components, such as physical sensors 136 and audio/visual sensors 132, may communicate vehicle information via vehicle communication bus 138. The vehicles 142, 143, and 144 of the fleet may include one or more position sensors 131 that can acquire 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. Location sensor 131 may obtain location information that is further processed by location module 154 of 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 partition of the fleet the vehicle belongs to. Vehicle scheme package 146 may be used by software application 152 running on in-vehicle computing device 150 to control vehicle 142 and determine conditions for transmitting its data. In some embodiments, software application 152 may access binary file storage 154 to access vehicle information transmitted over vehicle communication bus 138. In some embodiments, vehicle communications over a vehicle bus may be encoded by software application 152 and use a binary file and/or configuration file within the binary file storage to decode vehicle information transmitted over the encoded vehicle communications. can do. Bus traffic decoding and trigger monitoring module 156 may cause vehicle information, such as bus traffic, and/or other vehicle information, such as visual or audio data, to be stored in storage buffer 158. As described in more detail in FIG. 12 , a storage buffer may store vehicle information and other associated vehicle data that have been encoded and/or decoded for a plurality of prior time points in the past.

In some embodiments, trigger monitoring 160 provided by software application 152 determines whether the triggering criteria are met by determining whether one or more triggering criteria are met for data extraction provided by vehicle scheme packets. Bus traffic can be monitored to make decisions. In some embodiments, vehicle scheme packets may provide detection of movement to a new partition and/or geographic area as one such triggering criterion. For example, in Figure 1, movement of vehicle 142 from area A to area B may meet the triggering criteria. Software application 152 also includes a data reduction factor application 156 that retrieves one or more data reduction factors from vehicle scheme packets to determine the percentage at which specific sensor data should be acquired/collected for extraction after a triggering event. can do. For example, if the data reduction factor application 156 takes the data reduction factor and determines that the percentage of temperature sensor data to be transmitted upon fulfillment of the trigger is 50%, then the temperature sensor data transmitted by the flit may be reduced to, for example, the temperature sensor data transmitted. By reducing the frequency of , it will effectively be cut in half. In some embodiments, location module 154 may use location sensor 131 to determine the location of vehicle 142. If the triggering criteria are met, the packet generation module of the in-vehicle computing device 150 may generate one or more packets to be transmitted back to the vehicle information extraction service 102 as raw extracted vehicle data 148.

The data plane 112 can directly ingest the extracted raw vehicle data 148, and then the extracted raw data engine 184 uses the vehicle model configuration to decode the raw extracted data into physical telemetry messages. can do. In some embodiments, the extracted raw vehicle data may include video frames, images, radar amplitude, temperature data, engine speed, driver performance, and/or other information about the vehicle. In some embodiments, decoded telemetry data may be enriched with vehicle attributes and published to a time series database in data storage 114. Enrichment of vehicle data may allow a user to query the vehicle data using the vehicle's attributes and/or events of interest. In some embodiments, a unique object URL may be associated with a record containing vehicle data and may be published in a time series database.

In some embodiments, service user interface 104 may include a designer canvas and management console, as further discussed in FIG. 2. In some embodiments, customers may use the encoding format used to communicate vehicle information over the bus from customer-designed components (e.g., vehicle supplier and/or vehicle component supplier) and/or associated proprietary access credential files. Dictionary files describing the protocols and proprietary protocols can be provided. For example, customer 122a provides a service request 118 that includes a vehicle provision dictionary file and data extraction criteria for vehicle information formatted according to a vehicle provision dictionary. Additionally, customer 122n may provide a submission 120 that includes individual component supply dictionary files and data extraction criteria for vehicle information formatted according to the component supply dictionary. Note that the preliminary files and data extraction criteria are shown as part of the same submission in Figure 1. However, in some embodiments, data extraction criteria and dictionary files may be submitted separately.

Dictionary files and associated access credential files received from customers 122a and 122n may be stored in restricted access dictionary and credential store 106. Customer 122a's dictionary file/associated access credential file and customer 122n's dictionary file/associate access credential file may each be stored in separate physical or logical containers with limited access. For example, customer 122n may not be able to view customer 122a's dictionary file and may not be able to access the credential file, and vice versa.

2 illustrates a more detailed view of a vehicle information extraction service, various parts thereof, and interactions that separate vehicle model configuration from vehicle-specific in-vehicle communication signal configuration, according to some embodiments.

2, customer 122 may send an extract service request 118 to service user interface 106 to create a model of a fleet of vehicles. The extraction service request 118 includes information for the data collection scheme controller 108 to generate the signal catalog. The signal catalog can contain all signal attributes used by OEMs across all models of their vehicles or sensors. In some embodiments, a signal catalog may include a subset of signals, and the subset may include one or more signal attributes of various vehicle types in any combination. As discussed in Figure 1, the signal catalog may follow the Vehicle Signal Specification (VSS) naming guide and may be accessible only using its normalized names. 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. Data collection scheme controller 108 of data plane 104 can ensure that signal IDs are unique across the signal catalog. In some embodiments, customer 122 may create multiple signal catalogs that may contain signal attributes that may model different types of vehicles.

Once the signal catalog is created, data collection scheme controller 108 can use information obtained from extraction service requests 118 to create model configurations. A model configuration may be a set of signals selected from a signal catalog applicable to a particular vehicle model. For example, extraction service 112 may be given a sample signal catalog consisting of a branch for cruise control, a branch for combustion engines, and a branch for electric engines. When creating a model configuration for a vehicle that has cruise control but uses a combustion engine, the configuration will only include a cruise control branch and a combustion engine branch, without a branch for the electric engine. For different models of vehicles with electric engines 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 a signal catalog. In some embodiments, if there are signals in the signal catalog for which there are no decoder rules, these signals will be omitted from model construction. The vehicle model configuration can only include signals defined in the signal catalog. Figure 3 also illustrates the vehicle model configuration.

After the model configuration is created, decoder rules (e.g., decoder manifest or other configuration) for all vehicle sensors within the model configuration can be obtained for extract service request 118. Decoder rules may specify rules for decoding signals on an in-vehicle communication network and may enable customers to collect data from sensors listed in the model configuration. For example, the decoder rules may include CAN DBC for a specific model of vehicle, additional protocol-specific information for decoding in-vehicle signal formats (e.g., channel ID for signals providing CAN DBC), and CAN DBCs. It may contain a mapping file that maps given signal names to given signal names in the model configuration. In some embodiments, given a signal name defined in the model configuration, the decoder rules determine the sensor's It is possible to provide the parameters necessary to decode the information collected through.

In some embodiments, the decoder rules may be used by vehicle information extraction service 102 to decode the needed signals remotely, such as from a cloud-based location. In another embodiment, 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 signal 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 are different between vehicle types. In some embodiments, each set of decoder rules provides decoding rules for all signals in the model configuration. Model configuration and 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 ensures that the same signal semantics can be used for data collection and analysis regardless of the in-vehicle network topology and/or technology used in the vehicle. Moreover, this one-to-many relationship enables data collection across heterogeneous vehicles utilizing different signal formats. Once the decoding rules are provided by the decoder rules for all signals in the model configuration, the data collection scheme controller 108 generates the decoder rules and marks the model configuration as active.

In some embodiments, a customer network within a virtual private cloud (VPC) or on-premises network with access to the vehicle software application 152 and its gateway 201 can access private keys and clients via OEM Fleet Provisioning Management 208. Deploy a certificate (e.g. an X.509 certificate). Fleet inventory engine 206 may also obtain deployed private keys and certificates and synchronize vehicle dimensions, private keys and certificates with vehicle identification registry 110. Service user interface 106 then registers the vehicle to be modeled by identifying the decoder rules and model configuration with which this vehicle and the vehicle to be registered will be associated. Service user interface 106 provides values for static attributes present in the vehicle model configuration (eg, vehicle identification number (VIN), model, year, color, etc.).

Vehicle identification information registry 110 may create a fleet as a group or collection of vehicles collected together based on some common vehicle attributes. Vehicles can be created based on various vehicle attributes, such as a specific year or vehicle manufactured in a specific year, vehicle having a red color, vehicle fuel type, etc. Customer 122 may instruct, via service user interface 106, to create a fleet based on attributes available in the signal catalog. In some embodiments, fleet creation may involve a fleet creation query or filtering activity based on a number of attributes to create a fleet. Once a fleet is created, customer 122 can use the fleet to execute various workflows applying various data collection schemes. In some embodiments, vehicle identification registry 110 may automatically maintain and update the fleet without customer instructions as the collection of vehicles (collected together based on common vehicle attributes) changes. In some embodiments, when new vehicles are registered, vehicle identification registry 110 may automatically add the new vehicle to one or more fleets or partitions of the fleet, based on identified common vehicle attributes.

The data collection scheme controller 108 determines what data to collect from the vehicles, when to collect the data, and how frequently the data should be posted to the vehicle communication interface 180, as well as the total number of vehicles in the fleet within the same area. A variety of data collection schemes or configurations may be received from customers that dictate various different parameters to the vehicles, including data reduction factors that limit transmission to only a percentage of the time. In some embodiments, vehicle partition engine 188 may determine a data reduction factor using data collection probability engine 190 to limit vehicles within certain partitions from transmitting data. When creating a data collection scheme, the OEM or customer 122 can specify a subset of signals from the signal catalog that they wish to collect. In some embodiments, customer 122 may specify either a vehicle ID or a fleet ID for which the data collection scheme is to be transmitted. Vehicle communication interface 180 receives the data collection scheme and transmits it to the selected vehicle or fleet.

In some embodiments, as data is collected from various sensors on the vehicles according to a data collection scheme, the resulting raw data streams are transmitted to the vehicle communication interface 180 and the raw data is extracted from the raw data engine 184. It is decoded using In some embodiments, the raw extracted data engine 184 may use the vehicle model configuration to decode the raw extracted data into physical telemetry messages, which may be accessed by the customer using the service user interface 106. You can. In another embodiment, 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 streams include video frames, images, radar amplitude, temperature data, engine speed, driver performance, and other information about the vehicle. In some embodiments, decoded telemetry data (decoded using decoder rules by vehicle information extraction service 102 or the vehicle's software application 152) is enriched with vehicle attributes and stored in a data repository for analysis. It can be published in a time series database.

3 is an example of using a vehicle signal catalog to collect data using a common data collection scheme across a fleet of heterogeneous vehicle models and having a hierarchical tree structure that allows a unified signal representation to be used, according to some embodiments. Illustrative graphical view of a typical vehicle model configuration.

Vehicle model configuration 300 provides a serialized digital format of vehicle properties, sensors, actuators, and their relationships. The vehicle model configuration 300 is a hierarchical model that reflects the domain-based format of the latest vehicle network system and provides a format necessary to express the relationship between the ECU and sensors. For example, model configuration 300 includes all or a subset of signal types within a signal catalog. Signals provided by the signal catalog may be arranged in a hierarchical structure as shown in model configuration 300 and may include various signal types such as attribute, branch, sensor, and actuator. Model configuration includes ECU and Allows attachment to a domain.

In some embodiments, vehicle model configurations may be generated automatically from Automotive Open System Format (AUTOSAR) XML configuration files or ARXML, CAN DBC, or Field Bus Exchange Format (FibEx) files, or manually by the OEM or designer. can be written It can be further manipulated and updated after creation. In some embodiments, the model manifest may use the VSS format. The vehicle model configuration 300 may provide formats necessary to express the relationship between ECUs and sensors as a hierarchical model that reflects the domain-based format of a modern vehicle network system. For example, a query (352) in the vehicle model configuration (300) for “Drivetrain.Transmission.Speed” would return the signal “Speed” (336) under “Drivetrain” (332) and “Transmission” (334). Returns “Sensor” of the relevant type for . This allows the customer to specify the units and data types for the sensors needed for human-readable data exchange and define alert rules for the sensors.

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

In some embodiments, the service user interface of the vehicle information extraction service, such as service user interface 108, may include a designer canvas, such as designer canvas 402, and a management console, such as management console 410. In some embodiments, the designer canvas may enable a vehicle supplier's engineer or a customer engineer, such as a vehicle component supplier, to view digital twins containing data extracted from actual vehicles. The designer canvas can also allow engineers to modify the types of monitored/extracted data and/or triggering criteria for extracting data, including data reduction factors based on the number of vehicles in the partition. In some embodiments, Designer Canvas allows customer engineers to use their own enterprise credentials (e.g., issued to engineers by an enterprise customer) without requiring each engineer to have an account or credential for the vehicle information extraction service. credentials) can be used to log in to web applications. Using the web application, customer engineers can access, visualize and monitor vehicle data. Designer Canvas can also enable customers to build custom reporting or analytics, or integrate vehicle data into existing software environments. In some embodiments, web applications provided by the vehicle information extraction service may be pre-configured or easily configurable without requiring the customer to generate code for the web applications. In some embodiments, the management console for the vehicle information extraction service may provide additional features, allowing the customer to access the vehicle information extraction service, such as providing access to ownership dictionaries and creating additional digital twins. You can manage your account.

In some embodiments, a designer canvas, such as designer canvas 402, includes digital twin user interface 404, fleet user interface 406, and vehicle scheme user interface 408. Digital twin user interface 404 may enable a customer's engineers to view and interact with a digital twin for a given physical vehicle, where the digital twin includes near-real-time vehicle information extracted from the actual vehicle. Fleet user interface 406 may allow a customer's engineers to view and interface with a digital twin representing a class (or fleet) of vehicles. A fleet digital twin may contain aggregated data representing the near real-time status of classes of vehicles that match the fleet definition for the fleet. A fleet digital twin may include twins of vehicles belonging to various OEMs and may have different in-vehicle formats. Digital fleet twins can be created by using vehicle decoder rules and vehicle model configuration to combine various in-vehicle formats into a single fleet using a homogeneous vehicle signal format. Additionally, the digital twin user interface 404 and fleet user interface 406 may enable a customer's engineers to view and interact with historical data extracted from a real vehicle or a fleet of real vehicles. In some embodiments, a digital twin may be created for a vehicle using the designer canvas 402 before the actual vehicle is manufactured.

In some embodiments, designer canvas 402 may include a vehicle scheme user interface, such as vehicle scheme user interface 408. The vehicle scheme user interface 408 may allow a customer's engineer to provide/modify triggering criteria for extracting vehicle information as well as the types of vehicle information to be extracted from the vehicle or vehicles. For example, when troubleshooting a given system, an engineer can modify the data extraction through the vehicle scheme to include additional types of vehicle information to be extracted, such as data from subcomponents of the system that need to be troubleshooted. . The vehicle scheme user interface 408 may be used by an engineer to determine vehicle model configuration and the vehicle's respective decoder rules.

Management console 410 includes data extraction service account management 412 that can be used to manage a customer's account such as billing, contact information, etc. Additionally, management console 410 includes a digital twin for vehicle interface 414 and a fleet digital twin interface 416. These interfaces can be used by the customer to authorize additional digital twins to be created for either an individual vehicle or a fleet of vehicles. In some embodiments, a prompt in designer canvas 402 may cause a request to be queued for approval by the customer, where approval may cause digital twin interface 414 or fleet digital twin interface 416 to request additional digital twins. Create twins. Management console 410 includes a deployment interface 418 of management console 410 that allows generated binary files to be deployed to vehicles to be monitored. In some embodiments, a management console, such as management console 410, may further include a monitoring interface 420 for receiving and viewing extracted vehicle information. In some embodiments, the monitoring interface may also allow specification of monitoring parameters, such as alerts, to be triggered when certain thresholds are met in the extracted vehicle information. In some embodiments, binary files may be generated by vehicle information extraction service 102 and provided to the customer for deployment into the customer's vehicle.

The management console 410 includes an analysis interface 424 for defining the analysis to be performed on the extracted vehicle information, and a customer API interface 426 that allows the customer to specify analysis, alert, notification parameters, etc. do. Additionally, management console 410 includes a customer communication interface 422 configured to issue notifications to customers when certain alert thresholds are met in the extracted vehicle information. In some embodiments, management console 410 further includes a permissions and roles interface 432. This may allow the customer to define access roles for different types or classes of users (which could be employees of a vehicle component supplier or a vehicle supplier that is a customer 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 them to use new vehicle information extraction configurations, such as to delve deeper into the behavior of specific components of the vehicle. Roles may be provided to enable development.

Management console 410 includes an area interface 434 for determining the resolution of area boundaries and area boundaries that can be used to determine vehicle fleet partitions. As discussed further in Figure 8, region interface 434 can be used by a customer to change the resolution of region boundaries as well as to partition the map into grid regions with region unique identifiers defining the boundaries of the region. there is. Additionally, management console 410 includes a semantically indexed item interface 436 that defines types of semantically indexed items. Customers can use the semantically indexed item interface 436 to create static objects (e.g., traffic lights and street signs), semi-static objects (e.g., lane closures), and transient objects (e.g., bicycles or other vehicles). ), or any other classification of one or more specific objects. In some embodiments, indexed item interface 436 may be used to make inferences about the fleet's mobility patterns or other environmental factors, which may be used to determine the likelihood that data to be returned by a vehicle is duplicate data. Indexed item interface 436 may use aggregated data from a variety of sources, including images or other information obtained by vehicle interception. In some embodiments, the management console may include a data reduction factor interface 438 used by the customer to provide the probability of vehicle information to be extracted. For example, an engineer may specify a data extraction probability of a static object for a partition of vehicles around the static object to be 0.5 when the number of vehicles in the area is between 100 and 200 vehicles.

It should be noted that in some embodiments, the vehicle data extraction service may constrain partition definitions such that the resulting partitions have at least a threshold number of vehicles included in the partitions. For example, in some embodiments, a vehicle data extraction service may limit partitions to include at least a certain number of vehicles. Therefore, vehicle anonymity is maintained. For example, if the number of vehicles in a given partition is large enough, such as 20 vehicles, the collected vehicle information is sufficiently anonymized. Accordingly, if a partition definition containing fewer partitions than the minimum threshold number of vehicles is submitted by the customer, dynamic data reduction may be disabled by the vehicle data extraction service. Additionally, in some embodiments, updates to transmission probabilities may be disabled from being transmitted to vehicles in a fleet if there is not at least a threshold number of vehicles included within a given partition. In some embodiments, various thresholds may be used, such as 20 vehicles described above or other thresholds such as 5-10 vehicles. Additionally, service information identifying individual vehicles may not be collected on the cloud side or, if collected, may not be filtered from inclusion in the results of data collection.

5A-5C illustrate a dynamic vehicle data extraction service to determine a data reduction factor and optimize the amount of data extracted based on changes in vehicle densities at different times due to vehicle movement, according to some embodiments. Illustrating more detailed drawings of the fleet of vehicles in use.

In Figure 5A, a fleet of vehicles may be placed in various partitions. As discussed further in Figure 8, partitions A and B can be configured to be based on various geographic areas. However, as discussed further below, in some embodiments, partitions may have irregular shapes that are not constrained by geographic boundaries. In some embodiments, a given geographic area may include multiple partitions.

As shown in Figure 5A, the areas associated with partitions A and B (i.e., “Partition A” and “Partition B”) can be increased or decreased in size by the vehicle data extraction service and communicated to the vehicles. The nature of a partition can be changed, including the boundaries of the partition. In some embodiments, multiple partitions may be drawn based on proximity to certain inferences made about the vehicle environment. For example, partition C may include vehicles near a certain distance from the stationary object 508. In some embodiments, partition information may be communicated through a vehicle communication interface of a vehicle information extraction service. The vehicle data reduction service may maintain one or more partition information tables with corresponding partition information including information identifiers. In Figure 5A, the crossing of the boundary from one partition to another is based on geographic location, but various changes in the vehicle, such as proximity to an identified object, vehicle speed, etc., are taken into account when determining whether a vehicle is crossing a partition boundary. It can be.

In some embodiments, the vehicular environment may be represented as an overlay, for example on a geographic map, where the overlay includes identified objects in the vehicular environment based on previously collected vehicle information. For example, inferences about what objects are included in the vehicular environment may be derived from information collected from vehicles or other vehicles in a similar vehicular environment or location. In some embodiments, the distribution of certain types of objects may provide insight into the likely distribution of other types of objects. Accordingly, in some embodiments, the probabilities used for dynamic data reduction may also be based on inferences derived from the vehicle environment.

At T ₀ , there may be a certain number of vehicles in the fleet in partition A and partition B. Vehicle 1 (502), Vehicle 2 (504), and Vehicle 3 (506) are in the same vehicle fleet that transmits data to the vehicle data extraction service and may include various models with different OEMs as discussed in Figure 1. You can. At T ₀ , the number of vehicles in partition A and partition B is 12 and 3, respectively. The vehicle data extraction service may maintain one or more tables 508 containing information regarding data reduction factors/probabilities to return selected sensor information for partitions/vehicles within the partitions. Each of the partitions will contain vehicles that will receive a specific data reduction factor/probability that will change based on the number of vehicles within the partition if sufficient changes in vehicle counts should occur such that the model used for data reduction by the service is updated. You can. For example, as the number of vehicles within a partition increases, the concentration of vehicles within the partition may transmit an increased number of duplicate data. As the number of vehicles in a partition increases, the probability of transmitting selected sensor data may increase. On the other hand, as the number of vehicles within a partition decreases, the concentration of vehicles within that partition may decrease, such that the probability that select sensor data will be extracted to collect sufficient data for analysis may need to be increased. Additionally, the data reduction factor/probability may be based on the existence of various inferences made about the environment by the vehicle information extraction service. For example, based on environmental information, such as images detected by vehicles in a fleet, stationary objects 508, dynamic objects 510, and other inferences about partitions, the vehicle data extraction service can The number of objects of interest can be inferred. This heuristic can be used to determine the data reduction factor. For example, based on the total number of dynamic objects 510 near partition A or the number of stationary objects within partition B, the data reduction factor may be changed for each partition. Other heuristics may be used to determine the data reduction factor for a particular type of sensor data, such as vehicle movement patterns or the number of stop signs in an area or various other inferences about the vehicle environment. In some embodiments, inferences made about a partition, such as the existence of a dynamic object 510 or other objects, may be modified by a decay function, where objects have a lifetime for which they are likely to exist within the partition, and data reduction factors. The effects of objects on attenuate over time. For example, dynamic object 510 may exist at T ₀ but be removed at T ₁ .

In some embodiments, the probability may change in a dynamic manner based on changes in the number of vehicles or vehicle density of the partition or various heuristics. In some embodiments, updates of data coefficients may be sent to vehicles in a particular partition only after the total number of vehicles within the partition exceeds a certain threshold number of vehicles. The threshold number of vehicles may vary based on factors such as partition, fleet, type of sensor data, etc. Data reduction factor table 508 shows the sample threshold range required to send updates to the vehicle. Figure 5 shows the data extraction probability of selection data for partition B as 0.5 when the number of vehicles in the partition ranges from 0 to 5 vehicles, and when the number of vehicles in the partition ranges from 10 to 15 vehicles, The data extraction probability of the selected data for partition A is 0.3. In some embodiments, instead of a set probability for a range of vehicles, the probability may be different based on the number of vehicles within that partition. At T ₀ , vehicles 1 (502) and vehicle 2 (504) are shown moving from partition A to partition B, and when both vehicles cross the partition boundary at T ₁ , the vehicles receive location information or other relevant sensor information. It can be sent to a vehicle data extraction service. In some embodiments, the vehicle may transmit information identifying partition information in addition to the vehicle's location.

At T ₁ , the number of vehicles in partition A and partition B are 10 and 5, respectively, and the vehicle data extraction service generates one or more partition information tables as a result of the change in the number of vehicles in each partition A and B at T ₁ . can be updated. If the number of vehicles within a partition does not exceed the threshold required to send updates, a change in the number of vehicles may not trigger an update to the sensor data extraction probability within the fleet. As an example in Figure 5A, when the number of vehicles in a partition ranges from the minimum threshold for dynamic data reduction (greater than 1), the probability of data extraction of selected data for partition B is 0.5, for 5 vehicles and Since the total number of vehicles in the fleet in partition B remains in range, the probability remains the same. Note that in actual implementations, the number of vehicles could be much larger, such as 100s, 1,000s, 10,000s of vehicles, etc. However, for ease of illustration, fewer vehicles are used in FIGS. 5A-5C. Likewise, since the number of vehicles in the partition is in the range of 10 to 15, the data extraction probability of the selected data for partition A remains 0.3. At T ₁ , vehicle 3 is shown moving from partition A to partition B, and when the vehicle crosses the partition boundary at T 2 , vehicle 3 506 may transmit location information or other sensor information to a vehicle data extraction service. In some embodiments, the vehicle may transmit information identifying partition information in addition to the vehicle's location.

At T ₂ , the number of vehicles in partition A and partition B are 9 and 6, respectively, and the vehicle data extraction service may update one or more partition information tables with the resulting change in the number of vehicles in each partition A and B at T ₂ . You can. This change in the number of vehicles at T ₂ in both partitions A and B moved both partitions beyond a critical amount. For example, in Figure 5A, since the number of vehicles in partition B is in the range 6 to 10, the probability of data extraction of selected data for partition B is 0.4—which is the change from T ₁ , where the total number of vehicles is There was a minimum for data reduction to a range of 5. In Partition A, the total number of vehicles was reduced to 9, moving beyond the critical range from 10 to 15 to 5 to 9. Therefore, the data extraction probability of partition A increases to 0.4. In some embodiments, when there is a change in the data extraction probability of sensor data in a partition, a new vehicle scheme may be sent to vehicles in a fleet within that partition. For example, at T ₂ all vehicles in the fleet in partition A will receive a new vehicle scheme that communicates to each vehicle in partition A a new data reduction factor/data extraction probability of the sensor data.

5B illustrates vehicles using a dynamic vehicle data extraction service to optimize the amount of data extracted using multiple non-uniform partitions based on similarity of vehicle mobility patterns, according to some embodiments. For example, vehicle 3 (506) and vehicle 4 (514) may be traveling in the same direction or with similar mobility patterns (e.g., traveling at similar speeds, driving by identified objects, etc.). and, by contrast, can be placed in the same partition, partition D. Vehicle 5 516 may be traveling in the opposite direction and/or may be traveling with a different mobility pattern and may be placed in partition E, as discussed further in FIG. 8 . Partitions A and B may be configured to be based on various geographic areas, while partitions D and E may be based on environmental information and various inferences made about the environment. Areas associated with any of the partitions may be increased or decreased in size according to the vehicle data extraction service, and changes in the properties of the partitions, including the boundaries of the partitions, may be communicated to the vehicles. In some embodiments, multiple partitions may be drawn based on proximity to certain inferences made about the vehicle environment.

5C illustrates vehicles using a dynamic vehicle data extraction service to optimize the amount of data extracted using multiple non-uniform partitions in overlapping areas, but depending on the vehicle environment or other environmental factors, according to some embodiments. Based on this, we illustrate the amounts of data extracted from different partitions. 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 at different levels. For example, vehicle 6 (520) can travel on the upper level (overpass), while vehicle 7 (522) can travel on the lower level (underpass) of the bridge, and thus partitions such as partition F and partition G. Can be placed in different partitions. Geographical locations, nevertheless, they may be placed in different partitions due to other factors such as environmental differences or different speeds. In some embodiments, environments of special interest, such as underpasses, may be considered separate partitions.

6 illustrates a logical block diagram illustrating the various components of a vehicle data extraction service, the interaction of the components with vehicle movement, and the impact of vehicle movement on the probability of data extraction, according to some embodiments.

In this example, vehicle 126 of the fleet of vehicles transmitted location data 605 identifying the location of vehicle 126. In some embodiments, location data 605 may have been sent to the vehicle data extraction service through a triggering event, such as the intersection of a partition boundary as defined by the vehicle extraction service. In some embodiments, the location data may further include a unique partition identifier that specifies the partition to which the vehicle belongs. If the partition identifier is not specified in the location data 605, the vehicle extraction service 102 determines the partition identifier based on the location data 605, sends the information to the partition information table 603, and sends the location data ( Related vehicle information can be added to the partition identified in step 605). In some embodiments, extracted raw data engine 184 also configures vehicle partition table 182 to remove identified vehicles from previous partitions within which vehicle 126 was identified to match the vehicle's current location. will fix it

The vehicle partition engine 188 of the vehicle data extraction service may interact with the vehicle partition table 182 to perform additional queries and edits to the table. In some embodiments, vehicle partition engine 188 listens for vehicle add/remove 608 regarding partitions of the vehicle fleet to instruct vehicle partition engine 188 to increase the total number of vehicles in the corresponding partition. Vehicle partition engine 188 may determine the total number of vehicles in each partition and store this in vehicle partition table 182. In some embodiments, vehicle partition table 182 may maintain information regarding the total number of vehicles within each partition. As discussed in Figures 5A-5C, if the total number of vehicles in a partition changes beyond a threshold range, a new probability of data extraction/new data reduction factor is determined for that partition. In some embodiments, vehicle partition engine 188 may listen for updates 614 and determine that the total number of vehicles in a partition has increased/decreased as a vehicle enters or exits a partition, where the increase/decrease is within a threshold range. exceeds In response, vehicle partition engine 188 may create new entries in vehicle state table 186 or update existing entries to store the respective probabilities of data extraction that the vehicles should have after change 618. there is. In some embodiments, vehicle partition engine 188 may perform a query 616 of vehicle partition table 182 to identify all vehicles within a partition to send new probabilities. The vehicle state table 186 may then be used by the vehicle communication interface 180 to transmit new probabilities of data extraction or data reduction factors to relevant vehicles within the vehicle. In some embodiments, all vehicles in a partition belong to a fleet and may be transferred to a new vehicle scheme with changed probabilities for data extraction.

7 illustrates a flow diagram of operations performed by a vehicle information extraction service in connection with a transition from one partition of one or more vehicles to another partition, updated probabilities for data extraction, and/or Operations for determining whether a data reduction factor should be transmitted are illustrated.

At block 702, a default data reduction scheme is sent to the vehicles within the partition's fleet. The data reduction method may include information instructing the vehicle of signal data to collect and instruct the vehicle on events that trigger such collection. The data reduction method may also include a data reduction document based on the data replication level, where the data replication level is used to determine the probability for the data reduction method.

At block 704, the vehicle information extraction service receives location information for vehicles predicted to reside in partition G1 and/or predicted to leave partition G0 to join partition G1. The vehicle information extraction service may receive location information as discussed in FIG. 1 and determine a location estimate based on GPS information. In some embodiments, the location information may identify partition identification information in addition to location information. Location information may also include partition information for previous locations.

At block 706, the vehicle information extraction service updates the count for partition G1 and decrements 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 factor within partition G0 is updated. At block 712, the vehicle information extraction service determines whether a model change has been triggered such that the data reduction factor to be applied to the vehicles in partition G1 is updated. In some embodiments, the two blocks 708 and 712, checking whether a trigger has been reached, may be performed simultaneously. At block 710, if the trigger is met, the reduction factor is reduced for all vehicles in partition G0. In a similar manner, at block 714, if another trigger is met, the data reduction factor is incremented for all vehicles within partition G1.

8 illustrates an example map used in a vehicle data extraction service that partitions the map into grid geographic regions and allows changing the drawing and resolution of boundaries of multiple partitions, according to some embodiments.

In Figure 8, a geographic area 802 is shown, implementing a grid system in which the map is divided into partitions with specific boundaries. While latitude and longitude represent a single point, the grid system that divides the map allows the description of zones, which in some situations can correspond to partitions. Areas may be identified and organized by unique identifiers that define each area through a coordinate system that utilizes blocks of characters and lengths of identifiers. Some partitions may correspond to geographic area boundaries, while other partitions may fall within the boundaries of the geographic area. The partitions may not be parallelograms like the map grid shown, but may have non-uniform boundaries.

For example, Figure 8 shows a geographic area 802 identified by a lower resolution identifier 804 using the identifier “A2B2.” Figure 8 also shows the geographic area 802 further subdivided into six sub-partitions using higher resolution identifiers 806 such as "A1B2C1", "A1B2C2", and "A1B2C...". Each of the partitions is assigned a new identifier from its parent, starting with the same string and ending with a different letter, providing an efficient way to query whether a vehicle is in a border area of the map. Each of the partitions or sub-partitions may be used to construct various instances of information derived from a vehicle fleet or other sources, and may be used to construct various inferences about the partitions. For example, an inference can be made with partition “A1B2C3” as having a certain number of major highways and a certain percentage of more highways compared to partition “A1B2C5”. In another embodiment, specific objects may be detected and classified using machine learning techniques to determine a specific number of stationary signs within a partition. One or more of the various heuristics consisting of partitions may notify the vehicle data extraction service of the possibility of duplicate data and may be used to determine a data reduction factor.

5A-5C , in one embodiment, a vehicle in a fleet may transmit location data to a vehicle data extraction service, at which point the vehicle data extraction service may identify the partition to which the vehicle belongs; If the threshold is met, a new vehicle scheme containing a data reduction factor is to be sent to the vehicles of the fleet within the affected partition. In some embodiments, vehicles are configured such that the vehicle only transmits location information and/or partition information when the vehicle crosses a partition boundary at a particular resolution. For example, if a vehicle is set to bind to a low-resolution region, such as the low-resolution region identified by identifier 804, a change in vehicle partition will not trigger data to be transferred from “A1B2C1” to “A1B2C2”. However, if the vehicle is set to bind to a higher resolution, such as the higher resolution region identified by identifier 806, crossing the boundaries from "A1B2C1" to "A1B2C2" will cause the vehicle to send location information to the vehicle data extraction service. will trigger transmission to . 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 can also be divided into additional subpartitions. In some embodiments, different partitions may be created based on various collected vehicle environment information and may fall within multiple boundaries of a geographic area partition. The partitions may not be parallelograms like the map grid shown, but may have non-uniform boundaries. For example, partition “A1B2C7” 808 may have an uneven boundary spanning across multipole geographic partitions. In some embodiments, partitions may be based on vehicle environmental factors, such as vehicles moving in a particular direction or vehicles moving in a particular physical environment, such as a bridge. Partitions “A1B2C8” and “A1B2C9” show partitions spanning two different bridges.

In other embodiments, such as the use of Zone Improvement Plan (ZIP) codes or extended ZIP+4 codes to identify partition boundaries or other close area approaches that will reduce operational costs utilizing accurate GPS information instead of partitions. , other systems of geocoding for map partitions that do not rely on grid partitions can be used.

9 illustrates the effect of changing the resolution of an example map of a vehicle data extraction service that partitions the map into grid partitions to define the boundaries of the partitions, according to some embodiments.

Figure 9 shows geographic maps each divided into partitions, where the precision is set by the vehicle data extraction service and determines the partition boundaries that serve as triggers for the vehicle to transmit location data to the vehicle extraction service. . For example, if the precision of a vehicle's partition is set to 6 characters (702) with it initially located in partition "A1B2C5" (704), then from partition "A1B2C5" (704) to adjacent partition "A1B2C6" (710) When moving a vehicle, detection of movement outside the smaller partition will trigger the location to be transmitted. Detection of a change in vehicle 722's initial latitude/longitude to vehicle 724's current latitude/longitude will trigger the vehicle to transmit location information to the vehicle data extraction service. In another embodiment, vehicles within partition “A1B2C5” may be partitioned into non-uniform partition “A1B2C7” based on changes in various vehicle states, such as entering an underpass, entering within a certain proximity of an identified object, detecting a vehicle accident, etc. can be converted to

In some embodiments, the precision with which partition boundaries are determined may be modified. For example, the initial precision could be 6 characters 711 and correlated with the partition “A21B2C5”, such that the partition identifier is characterized by an identifier with 6 characters. When the partition precision threshold is changed 712 from 6 characters to 5 characters, the current partition associated with the vehicle's location (714 “A1B2C”) will be identified with the same precision. In some embodiments, the precision of the partitions of vehicles used may differ based on various factors such as vehicle identification, fleet, sensor data type, etc., all uniform to trigger location data transmission to the vehicle data extraction service. It may not be possible to use the same precision. Switching to a different precision may cause certain partitions with higher resolution, such as partitions "A1B2C7" and "A1B2C9", not to be taken into account.

10 illustrates a more detailed view of a network stack of protocols used at different levels to communicate vehicle information over the vehicle's bus, according to some embodiments.

In some embodiments, software application 152 may include multiple layers of the vehicle's network stack that enable access and decoding of communications transmitted over the vehicle's communication bus. For example, binary files included in the binary file storage of an in-vehicle computing device may represent access authentication information, protocols, and/or addresses used in vehicle hardware layer 1010. Additionally, the binary file may indicate access credentials, protocols, or ports used by the vehicle firmware layer 1008 and/or the in-vehicle hypervisor layer 1006. Additionally, the binary files may indicate the bus protocols used in bus layer 1004 and the customer's proprietary protocols and access credentials used in layer 1002. Vehicle information monitoring and extraction software application 152 may use these definitions and access credentials contained in the binary file to access and decode messages transmitted over encoded vehicle communication bus 1108. To transmit raw data, software application 152 may be provisioned with a vehicle identification certificate from a vehicle identification registry from the control plane of the vehicle information extraction service. Software application 152 may decode communication transmitted over the communication bus using rules for decoding as specified in decoder rules. In some embodiments, decoder rules are different between different models of vehicles and/or vehicles from different OEMs.

11 illustrates an example vehicle including multiple different buses that can be monitored for data extraction by a software application deployed by a vehicle information extraction service, according to some embodiments.

In some embodiments, a vehicle, such as vehicle 1126, may include multiple buses connected to gateway 202. For example, vehicle 1126 may have CAN bus #1 (1104), CAN bus #2 (1106), Ethernet/IP bus (1108), local interconnect (LIN) bus (1110), and FlexRay bus (1112). It includes a gateway 202 connected to. As shown in Figure 11, different types of vehicle information may be transmitted over different types of buses. In some embodiments, software application 152 may provide decoder rules or decoder configurations for decoding various vehicle attributes from vehicle module configurations into respective in-vehicle communication signals. For example, decoder rules can 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 can be sent to a vehicle data extraction service. .

12 illustrates a more detailed view of a storage buffer that may be used by an application deployed by a vehicle information extraction service, where the storage buffer determines a data reduction factor if one or more triggering criteria are met, according to some embodiments. Apply and store data from one or more preceding time points suitable for extraction.

As shown in Figure 12, in some embodiments, storage buffer 158 may store one or more types of data in one or more buffers. For example, storage buffer 158 includes time synchronized decoded sensor buffer 1202, other data buffer 1 1204, and other data buffer N 1206. Current data may be stored at time N. The next instant's data will be stored at time N-1, and when the next instant's time arrives it will be time N, and the data previously stored at time N will be at time N+1. In some embodiments, storage buffer 158 may store data for any number of time points (eg, N+X, where X is the number of time points being buffered). Additionally, 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.

In some embodiments, a global time stamp may be applied to vehicle information when stored in storage buffer 1202. Additionally, in some embodiments, the payload of data stored in the storage buffer 1202 may include, for example, a time stamp when a message containing the data was submitted to the encoded vehicle communication bus 138, or a physical sensor 136 ) may include timestamps associated with stored data generated by other components of the vehicle, such as a timestamp when the data was detected by ). Accordingly, in some embodiments, a piece of data may include a payload timestamp for when the data is sensed, e.g., at a physical sensor 136, and another payload for when the data is submitted to the encoded vehicle communication bus 138. There may be one or more time stamps, such as a time stamp, and another time stamp for when the data was received in storage buffer 158. In some embodiments, pieces of data stored in storage buffer 158 may be stored with more or fewer timestamps. Such timestamps may enable the exact format of the sequence of events within the vehicle to be recreated, for example, by software application 152 or by extracted data analysis and visualization module 114 of vehicle information extraction service 102. there is. In some embodiments, data reduction factor application 156 may select and filter data after the data is stored in storage buffer 158. For example, data reduction factor application 156 applies a data reduction factor and determines that the percentage of temperature data being filtered is 50%, and removes approximately half of the data stored in the buffer within a certain time frame with that data reduction factor. can do. In other embodiments, filtering of the data would occur before the data is stored in the buffer, and in the example of temperature data, 50% of the sensor data would not be stored. In another embodiment, all data would be stored in a storage buffer, but filtering would only occur in transmission of this data to the vehicle data extraction service, where only half of the data would be transmitted.

13 illustrates operations performed by a vehicle information extraction service that optimizes the amount of information to be extracted from vehicles based on the partition criteria and the number of vehicles in the fleet of vehicles within the partition, among other factors, according to some embodiments. Illustrate the flow chart.

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

At block 1304, the vehicle information extraction service receives one or more vehicle information packets provided by each vehicle in the fleet, each packet of the one or more vehicle information packets including information used to identify each partition.

At block 1306, the vehicle information extraction service determines the total number of vehicles in the fleet located in each of the partitions.

At block 1308, the vehicle information extraction service determines one or more data reduction factors to be applied to vehicles in each of the partitions based on the respective total number of vehicles in each of the partitions, wherein the one or more data reduction factors are predetermined. It includes a probability that a given vehicle in a fleet within each partition has non-redundant vehicle information compared to other vehicles among the vehicles in the fleet within each given partition.

At block 1310, the vehicle information extraction service transmits one or more vehicle scheme packets to the fleet's vehicles in each of the one or more partitions. In some embodiments, vehicle scheme packets may include information identifying one or more types of requested vehicle information to be extracted and a corresponding data reduction factor to be applied.

At block 1312, the vehicle information extraction service receives one or more types of requested vehicle information from a portion of the fleet's vehicles located in a given partition according to a data reduction factor.

14 allows a unified model to be created for a fleet of vehicles, automatically taking into account variations in in-vehicle communication configurations so that requested information specified in the model can be collected from heterogeneous fleets of vehicles, according to some embodiments. This illustrates a flow chart for implementing a modeling system in a vehicle information extraction service.

At block 1402, the vehicle information extraction service provides a decoder with decoding parameters and/or in-vehicle communication signal configurations and formats to collect vehicle signal information from a plurality of types of vehicles using different in-vehicle communication signal configurations or formats. Fill out the manifest. Decoding parameters and/or in-vehicle communication signal configurations and formats may be retrieved by vehicle information extraction services from vehicle OEMs, Tier 1 suppliers, or other component suppliers. In some embodiments, OEMs that are customers of the vehicle information extraction service may provide this information as part of onboarding with the vehicle information extraction service. In some embodiments, this information may be stored by the vehicle information extraction service, such that customers of the vehicle information extraction service may have access to decoding parameters and/or details of in-vehicle communication signal configurations and formats. I can't.

At block 1404, the vehicle information extraction service provides an interface for creating a model for vehicle information to be collected from vehicles containing different in-vehicle communication signal configurations or formats. For example, a customer of a vehicle information extraction service can use the interface to specify a model for data collection from vehicles with different in-vehicle communication configurations.

At block 1406, the vehicle information extraction service creates a vehicle model configuration that includes signal attributes for vehicle information to be extracted from the vehicle based on inputs received at the interface from the customer.

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

At block 1410, the vehicle information extraction service transmits 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, wherein the data collection scheme includes data extraction criteria for vehicle sensor information. And, vehicle sensor information is identified using the signal properties of the vehicle model.

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

Although not specifically shown in FIG. 14 , in some embodiments, the vehicle information extraction service may further apply data reduction factors when collecting requested vehicle information from a vehicle, as described with respect to FIG. 13 .

Exemplary Computer System

Any of the various computer systems may be a vehicle information extraction service, a software application/package deployed on the vehicle from the vehicle information extraction service, a provider network implementing the vehicle extraction service, an operating system within the vehicle or device, or any other of the figures. May contain components. For example, Figure 15 illustrates a block diagram illustrating an example computer system implementing some or all of the techniques described herein, according to some embodiments. In various embodiments, a vehicle information extraction service, a deployed software package, a provider network implementing the vehicle information extraction service and other cloud services, an operating system within a vehicle or device, or any other component of FIGS. 1-14. Each may include one or more computer systems 1500, such as those illustrated in FIG. 15 .

In the illustrated embodiment, computer system 1500 includes one or more processors 1510 coupled to system memory 1520 via input/output (I/O) interface 1530. Computer system 1500 further includes a network interface 1540 coupled to I/O interface 1530. In some embodiments, computer system 1500 may be an example of servers implementing enterprise logic or downloadable applications, while in other embodiments servers may include fewer or different elements than computer system 1500. .

In various embodiments, computing device 1500 may be a uniprocessor system comprising one processor, or a multiprocessor system comprising multiple processors 1510A-1510N (e.g., 2, 4, 8, or other suitable number). It could be a system. Processors 1510A-1510N may include any suitable processors capable of executing instructions. For example, in various embodiments, processors 1510A-1510N may be processors implementing any of a variety of instruction set formats (ISAs), such as x86, PowerPC, SPARC, or MIPS ISAs, or any other suitable ISA. You can. In some embodiments, processors 1510A-1510N may include specialized processors, such as graphics processing units (GPUs), application specific integrated circuits (ASICs), and the like. In multiprocessor systems, each processor 1510A-1510N may typically, but not necessarily, implement the same ISA.

System memory 1520 may be configured to store program instructions and data accessible by processor(s) 1510A-1510N. In various embodiments, system memory 1520 uses any suitable memory technology, such as static random access memory (SRAM), synchronous dynamic RAM (SDRAM), non-volatile/Flash-type memory, or any other type of memory. This can be implemented. In the illustrated embodiment, program instructions and data implementing one or more desired functions, such as the methods, techniques, and data described above, are stored in the system as code (i.e., program instructions) 1525 and data 1535. It is shown as stored in memory 1520.

In one embodiment, the I/O interface 1530 includes a network interface 1540 or other peripheral interfaces to connect the device to the processors 1510A-1510N, system memory 1520, and any peripheral devices. /O Can be configured to steer traffic. In some embodiments, I/O interface 1530 is suitable for receiving data signals from one component (e.g., system memory 1520) for use by another component (e.g., processor 1510). You can perform any protocol, timing, or other data conversions necessary to convert to format. In some embodiments, I/O interface 1530 may be configured to connect devices via various types of peripheral buses, such as, for example, the Peripheral Component Interconnect (PCI) bus standard or a variant of the Universal Serial Bus (USB) standard. This may include support for: In some embodiments, I/O interface 1530 may include support for devices attached via an automotive CAN bus, etc. In some embodiments, the functionality of I/O interface 1530 may be split into two or more separate components, such as a north bridge and a south bridge, for example. Additionally, in some embodiments, some or all of the functionality of I/O interface 1530, such as an interface to system memory 1520, may be integrated directly into processors 1510A-1510N.

Network interface 1540 may be configured to allow data to be exchanged between computing device 1500 and other devices 1560 associated with the network or networks 1550. In various embodiments, network interface 1540 may communicate over any suitable types of conventional data networks, wired or wireless, such as, for example, Ethernet networks, cellular networks, Bluetooth networks, Wi-Fi networks, ultra-wideband networks, etc. can support. Additionally, network interface 1540 may be configured to connect to telephony/telephony networks such as analog voice networks or digital fiber communications networks, storage area networks such as Fiber Channel SANs, or any other suitable type of network and/or Communication can be supported through protocols.

In some embodiments, system memory 1520 is computer readable (i.e., computer accessible) configured to store program instructions and data as described above for implementing embodiments of corresponding methods, systems, and apparatus. ) It may be an example of a medium. However, in other embodiments, program instructions and/or data may be received, transmitted, or stored on different types of computer-readable media. Generally speaking, computer-readable media includes non-transitory storage or memory media such as magnetic or optical media, such as disks or DVDs/CDs, that are coupled to computing device 1500 via I/O interface 1530. can do. One or more non-transitory computer-readable storage media may include any volatile or non-volatile media such as RAM (e.g., SDRAM, DDR SDRAM, RDRAM, SRAM, etc.), ROM, etc., which may be stored in computing device 1500. may be included as system memory 1520 or other types of memory in some embodiments. Furthermore, computer-readable media may include transmission media or communications media such as signals that may be implemented over a network and/or wireless link, such as electrical, electromagnetic, or digital signals, which may be implemented via network interface 1540. there is. For example, portions or all of the number of computing devices illustrated in Figure 15 may be used to implement the functionality described in various embodiments; For example, software components running on a variety of different devices and servers may cooperate to provide functionality. In some embodiments, portions of the described functionality may be implemented using storage devices, network devices, or various types of computer systems. The term “computing device” when used herein refers to at least all of these types of devices and is not limited to these types of devices.

Embodiments of the present disclosure can be described considering the following provisions:

Article 1. A system for implementing a vehicle information extraction service,

Comprising one or more computing devices, wherein the one or more computing devices:

generate a vehicle model that organizes a subset of signal properties of a plurality of signal properties according to a first request received from a customer of the vehicle information extraction service;

transmitting each signal decoding rule of the plurality of signal decoding rules for decoding signal properties of the vehicle model into in-vehicle communication signals to vehicles in the vehicle fleet;

transmitting a data collection scheme to each vehicle in the fleet in accordance with a second request received from a customer of the vehicle information extraction service, wherein the data collection scheme includes data extraction criteria for vehicle sensor information and a sub-process of signal attributes of the vehicle model; Identify vehicle sensor information using sets ―; and

A system configured to receive vehicle data from each vehicle in a fleet, extracted from each vehicle according to a data collection scheme decoded using signal decoding rules.

Clause 2. The clause 1 of clause 1, wherein the fleet of vehicles includes vehicles having different in-vehicle communication signal configurations, and transmitting the respective signal decoding rules to the vehicles in the fleet determines which of the different in-vehicle communication signal configurations the vehicle has. The system is based on whether each signal decoding rule is used.

Clause 3. The clauses of clause 1 or clause 2, wherein the one or more computing devices further:

Receive signal properties of each sensor of the plurality of sensors from manufacturers or suppliers for the plurality of vehicles, the plurality of vehicles comprising vehicles having different in-vehicle communication signal configurations; and

A system, wherein the system is configured to generate a signal catalog that organizes signal properties into a unified signal representation, on which the signal configuration of the vehicle model is based.

Clause 4. The system of clause 3, wherein the signal configuration of the vehicle model is such that decoding rules for mapping vehicle-specific signal names to respective signal properties in the signal catalog omit signals that are not in the signal catalog.

Clause 5. The clause 4 of Clause 4, wherein the one or more computing devices further:

configured to receive, from a manufacturer or supplier, a plurality of sensor-specific signal decoding rules for decoding signals corresponding to signal properties of a signal catalog corresponding to each signal property name of the plurality of signal property names, the sensor-specific signal decoding rule The system enables decoding signals formatted according to the in-vehicle communication signal formats of each of the vehicles of the fleet.

Clause 6. As a method:

generating a vehicle model that organizes a subset of signal properties of a plurality of signal properties for a fleet of vehicles;

Transmitting each signal decoding rule of a plurality of signal decoding rules for decoding signal properties included in the vehicle model to vehicles in the fleet, the transmitted decoding rules enabling decoding of in-vehicle communication signals;

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 signal properties of the vehicle model; and

A method comprising receiving vehicle data extracted from each vehicle according to a data collection scheme decoded using transmitted signal decoding rules from each vehicle in the fleet.

Clause 7. The clause 6 of clause 6, wherein the fleet of vehicles includes vehicles having different in-vehicle communication signal configurations, and transmitting the respective signal decoding rules to the vehicles in the fleet requires that each of the vehicles have different in-vehicle communication signal configurations. The method is based on which in-vehicle communication signal configuration is used.

Article 8. In Article 7:

Receiving signal properties of each sensor of the plurality of sensors from manufacturers or suppliers of the plurality of vehicles, the plurality of vehicles comprising vehicles having different in-vehicle communication signal configurations; and

The method further comprising generating a signal catalog organizing the signal properties into a unified signal representation, on which the signal configuration of the vehicle model is based.

Clause 9. The method of clause 7, wherein the signal configuration of the vehicle model is such that decoding rules for mapping vehicle-specific signal names to respective signal properties in the signal catalog omit signals that are not in the signal catalog.

Article 10. In Article 6:

Receiving, from a vehicle manufacturer or supplier, a plurality of sensor-specific signal decoding rules for decoding signals corresponding to signal properties of a signal catalog corresponding to each signal property name of the plurality of signal property names, wherein the sensor The method wherein specific signal decoding rules enable decoding signals formatted according to the in-vehicle communication signal formats of each of the vehicles in the fleet.

Article 11. In any one of Articles 6 to 10:

The method further includes decoding vehicle data extracted from each vehicle using signal decoding rules, wherein the received vehicle data is decoded from binary resources into sensor signal values.

Article 12. In Article 11:

Associating sensor signal values with one or more vehicle attributes of the vehicle from which vehicle data was extracted; and

The method further comprising posting sensor signal values to a time series database.

Clause 13. The method of any one of clauses 6 through 12, wherein the vehicle sensor information:

camera data;

LiDar data;

electronic control unit (ECU) data; or

A method comprising one or more of synthetic sensor data.

Clause 14. The method of any of clauses 6-13, wherein the signal attributes include static attributes associated with a particular vehicle, including unique vehicle Id, vehicle brand, body type, and vehicle engine model. .

Clause 15. The method of any one of clauses 6 to 14, wherein the data collection scheme further includes information identifying vehicle sensor information to be extracted in response to a data reduction factor, wherein the data reduction factor is a vehicle sensor information to be extracted in response to a data reduction factor. A method based on the total number of vehicles in a fleet, based on an inference of the vehicle environment of the fleet, and wherein the extracted data is extracted only from a portion of the fleet.

Clause 16. One or more non-transitory computer-readable storage media, storing program instructions that, when executed on or across one or more computing vehicles, cause the one or more computing vehicles to implement a vehicle information extraction service, the vehicle Information extraction services:

generating a vehicle model that organizes a subset of signal properties of a plurality of signal properties;

transmitting each signal decoding rule of a plurality of signal decoding rules for decoding signal properties of a vehicle model into in-vehicle communication signals to vehicles in a vehicle fleet;

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 signal properties of the vehicle model; and

One or more non-transitory computer-readable storage media, the method comprising receiving vehicle data extracted from each vehicle according to a data collection scheme decoded using signal decoding rules from each vehicle in the fleet.

Clause 17. The clause 16 of Clause 16, wherein the instructions, when executed on or across one or more processors, further cause the Vehicle Information Extraction Service to:

Implementing the step of decoding vehicle data extracted from each vehicle in a fleet using signal decoding rules, wherein the received vehicle data is decoded into sensor signal values from an in-vehicle format. storage media.

Clause 18. The clause 17 of Clause 17, wherein the instructions, when executed on or across one or more processors, further cause the Vehicle Information Extraction Service to:

Associating a predetermined sensor signal value with one or more vehicle attributes of a vehicle from which vehicle data was extracted; and

One or more non-transitory computer-readable storage media that implements the step of posting sensor signal values to a time series database.

Clause 19. The method of any of clauses 16 through 18, wherein the vehicle sensor information:

camera data;

LiDar data;

electronic control unit (ECU) data; or

One or more non-transitory computer-readable storage media comprising one or more of synthetic sensor data.

Clause 20. The clause of any of clauses 16 to 19, wherein the signal attributes include static attributes associated with a particular vehicle, including unique vehicle Id, vehicle brand, body type, or vehicle engine model. Any of the above non-transitory computer-readable storage media.

Article 21. A system for implementing a vehicle information extraction service,

Comprising one or more computing devices, wherein the one or more computing devices:

receive, from a customer of a vehicle information extraction service, a request for one or more types of vehicle information to be extracted from a fleet of vehicles;

Receive one or more vehicle information packets provided by each vehicle in the fleet, each packet of the one or more vehicle information packets including information used to identify respective partitions;

determine the total number of vehicles in each of the partitions;

determining one or more data reduction factors to be applied to vehicles in each of the partitions based on the respective total number of vehicles in each of the partitions, wherein the one or more data reduction factors determine the number of vehicles in a fleet in each of the partitions; Includes the probability of having non-redundant vehicle information compared to other vehicles among the vehicles in the fleet within each predetermined partition -;

Sending one or more vehicle scheme packets to one or more of the vehicles in the fleet, wherein the vehicle scheme packets include information identifying one or more types of requested vehicle information to be extracted, and one or more corresponding data reduction factors for the one or more partitions to be applied. Contains -; and

A system, wherein the system is configured to receive one or more types of requested vehicle information from only a portion of the vehicles in a fleet located within each partition of the one or more partitions according to one or more data reduction factors.

Clause 22. The clause 21 of Clause 21, wherein the one or more computing devices further:

It is configured to infer the vehicle environment for vehicles in a predetermined partition based on the received vehicle information, and the vehicle environment includes a vehicle detection object identified through machine learning algorithms,

The system wherein a data reduction factor is also determined based on the inferred vehicle environment for each partition.

Clause 23. The clause 22 of Clause 22, wherein the one or more computing devices further:

A system configured to classify detected objects as static objects, semi-static objects, or dynamic objects using a machine learning algorithm.

Clause 24. The clause of clause 22 or clause 23, wherein the one or more computing devices further:

Configured to modify the inferred vehicle environment according to a decay function,

A system wherein a data reduction factor is determined based on the inferred vehicle environment modified by each attenuation function.

Article 25. In any one of Articles 21 to 24:

Partitions are the respective locations of each vehicle indicated in one or more vehicle information packets received, and

A system wherein the determination is made based on the temporal proximity of each vehicle being located in close proximity to each other.

Article 26. As a method:

Receiving a request for one or more types of vehicle information to be extracted from a fleet of vehicles;

Receiving one or more vehicle information packets provided by each vehicle in the fleet, each packet of the one or more vehicle information packets including information used to identify respective partitions;

determining the total number of vehicles in a given partition among each partition;

determining a data reduction factor to be applied to vehicles in a given partition among the partitions based on the total number of vehicles in the given partition;

Sending one or more vehicle scheme packets to vehicles in a fleet within a given partition, wherein the vehicle scheme packet includes information identifying one or more types of requested vehicle information to be extracted, and a corresponding data reduction factor to be applied for the given partition. Contains -; and

A method comprising receiving one or more types of requested vehicle information from only a portion of the vehicles in a fleet located within a given partition according to a data reduction factor.

Article 27. In Article 26:

further comprising inferring a vehicle environment for vehicles in a given partition based on received vehicle information for the given partition, wherein the vehicle environment includes a vehicle detection object identified through machine learning algorithms,

wherein a data reduction factor is also determined based on the inferred vehicle environment for a given partition.

Article 28. In Article 27:

Further comprising classifying objects detected by the vehicle as static, semi-static, or dynamic objects,

The method wherein the data reduction factor is further determined based on whether the objects in the inferred vehicle environment for a given partition are static, semi-static, or dynamic objects.

Article 29. In Article 27 or Article 28:

Further comprising modifying the vehicle environment inferred by the respective attenuation functions for the static object, semi-static object, or dynamic object,

The method wherein the data reduction factor is also based on the inferred vehicle environment modified by the respective attenuation functions for the static object, semi-static object, or dynamic object.

Article 30. In any one of Articles 26 to 29:

Partitions are the respective locations of each vehicle indicated in one or more vehicle information packets received, and

The method is determined based on the time proximity of each vehicle being located close to each other.

Article 31. In any one of Articles 26 to 29:

Receiving another vehicle information packet provided by a second one of the vehicles in the fleet, the other vehicle information packet being provided at least in part due to the second vehicle meeting one or more criteria for inclusion within a given partition;

updating the total number of vehicles in a fleet within a given partition based on the inclusion of the second vehicle within the given partition; and

The method further comprising transmitting the previously determined data reduction factor for the given partition to the second vehicle if the second total number of vehicles in the given partition does not exceed the model update threshold level.

Article 32. In any one of Articles 26 to 31:

determining a second data reduction factor to be applied to vehicles in a given partition based on the updated version of the total number of vehicles in the given partition exceeding a model update threshold, wherein the second data reduction factor is determined by the fleets in the given partition. includes a second probability that each vehicle of the vehicles has non-redundant vehicle information when compared to other vehicles among the vehicles of the fleet within a given partition; and

Sending a Other Vehicle Scheme Packet to vehicles in a fleet within a given partition, the Other Vehicle Scheme Packet comprising information identifying one or more types of requested vehicle information to be extracted, and a corresponding second data reduction factor to be applied. - A method further comprising:

Clause 33. The method of any of clauses 26-32, wherein the fleet of vehicles includes vehicles that have participated in a data reduction setup for information extraction.

Article 34. In any one of Articles 26 to 33,

determining a second data reduction factor to be applied to each vehicle in the second fleet of vehicles based on the fleet included in the given partition and the total number of vehicles for the second fleet, where the second data reduction factor is the first data reduction factor in the given partition. comprising a second probability that a given vehicle in fleet 2 will have non-redundant vehicle information compared to other vehicles among the vehicles in the first or second fleet included within the given partition; and

Sending one or more second vehicle scheme packets to vehicles of a second fleet within a given partition, wherein the second vehicle scheme packets include information identifying one or more types of requested vehicle information to be extracted, and corresponding second vehicle information to be applied. A method further comprising: comprising a data reduction factor.

Clause 13. The method of any one of clauses 26 through 34, wherein one or more types of vehicle information to be extracted from a fleet of vehicles are:

camera data;

LiDar data;

electronic control unit (ECU) data; or

One or more non-transitory computer-readable storage media comprising one or more of synthetic sensor data.

Article 36. In any one of Articles 26 to 35:

The one or more vehicle scheme packets instruct the vehicles to store vehicle information in a vehicle data storage for a period of time when the bandwidth of the network connection through which the vehicle information is to be transmitted does not meet the bandwidth threshold,

Wherein vehicle scheme packets instruct the vehicle to store a reduced version of vehicle information reduced according to a data reduction factor.

Article 37. In any one of Articles 26 to 35:

The one or more vehicle scheme packets instruct the vehicles to store vehicle information in a vehicle data storage for a period of time when the bandwidth of the network connection through which the vehicle information is to be transmitted does not meet the bandwidth threshold,

Vehicle scheme packets instruct the vehicle to store vehicle information without applying a data reduction factor, and

Wherein the data reduction factor is applied when preparing to transmit stored vehicle information in response to determining that the network connection meets a bandwidth threshold.

Clause 38. The method of any of clauses 26 through 37, wherein the vehicles in the fleet comprise vehicles with different in-vehicle communication architectures, and the request for one or more types of vehicle information to be extracted from the fleet of vehicles includes the different in-vehicle communication architectures. Method, formatted differently for in-vehicle communication architectures.

Clause 39. One or more non-transitory computer-readable storage media, storing program instructions that, when executed on or across one or more computing vehicles, cause the one or more computing vehicles to implement a vehicle information extraction service, the vehicle Information extraction services:

Receiving a request for one or more types of vehicle information to be extracted from a fleet of vehicles;

Receiving one or more vehicle information packets provided by each vehicle in the fleet, each information packet including information used to identify each partition;

determining each total number of vehicles within one or more of the partitions;

determining a data reduction factor to be applied to vehicles in a given partition among the partitions based on the total number of vehicles in the given partition;

Sending one or more vehicle scheme packets to vehicles in a fleet within a given partition, wherein the vehicle scheme packets include information identifying one or more types of requested vehicle information to be extracted, and a corresponding data reduction factor to be applied; and

One or more non-transitory computer-readable storage media, comprising receiving one or more types of requested vehicle information from only a portion of the vehicles of a fleet located within a given partition according to a data reduction factor.

Clause 40. One or more non-transitory computer-accessible storage media as described in Clause 39, storing additional program instructions that, when executed on or across one or more processors, cause the one or more processors to:

The vehicle environment for vehicles in a given partition is inferred based on the received vehicle information for the given partition, where the received vehicle environment includes vehicle detection objects identified through a machine learning algorithm, and based on the vehicle environment One or more non-transitory computer accessible storage media, wherein a data reduction factor is also determined.

The various methods as illustrated in the drawings and described herein represent example embodiments of the methods. Methods may be implemented manually, in software, hardware, or a combination thereof. The order of any method may be changed, and various elements may be added, reordered, combined, omitted, altered, etc. For example, in one embodiment, the methods may be implemented by a computer system comprising processor-executable program instructions stored on a computer-readable storage medium coupled to a processor. Program instructions may be configured to implement the functionality described herein (e.g., the functionality of a data transfer tool, various services, databases, devices and/or other communication devices, etc.).

Various modifications and changes may be made as will be apparent to those skilled in the art to benefit from the present invention. It is intended to cover all such modifications and variations, and accordingly, to treat the foregoing description in an illustrative rather than a restrictive sense.

Various embodiments may further include receiving, transmitting, or storing instructions and/or data implemented in accordance with the foregoing description on a computer-accessible medium. Generally speaking, computer accessible media refers to storage or memory media such as magnetic or optical media such as disks or DVD/CD-ROMs, volatile or non-volatile media such as RAM (e.g. SDRAM, DDR, RDRAM, SRAM, etc.), ROM, etc., as well as signals transmitted through transmission or communication media such as networks and/or wireless links, such as electrical, electromagnetic, or digital signals.

Claims (15)

A system for implementing a vehicle information extraction service,
Includes one or more computing devices,
The one or more computing devices:
generate a vehicle model that organizes a subset of signal properties of a plurality of signal properties according to a first request received from a customer of the vehicle information extraction service;
transmitting respective signal decoding rules of a plurality of signal decoding rules for decoding signal properties of the vehicle model into in-vehicle communication signals to vehicles of the vehicle fleet;
transmitting a data collection scheme to each vehicle in the fleet according to a second request received from a customer of the vehicle information extraction service, wherein the data collection scheme includes data extraction criteria for vehicle sensor information, and identifying the vehicle sensor information using a subset of the signal properties; and
The system is configured to receive vehicle data extracted from each vehicle according to the data collection scheme decoded using the signal decoding rules from each vehicle in the fleet. 2. The method of claim 1, wherein the fleet of vehicles comprises vehicles with different in-vehicle communication signal configurations, and transmitting respective signal decoding rules to the vehicles in the fleet causes each of the vehicles to have different in-vehicle communication signal configurations. The system is based on which of the in-vehicle communication signal configurations are used. 3. The method of claim 1 or 2, wherein the one or more computing devices further:
Receive the signal properties of each sensor of the plurality of sensors from manufacturers or suppliers for the plurality of vehicles, the plurality of vehicles comprising vehicles having different in-vehicle communication signal configurations; and
A system, wherein the system is configured to generate a signal catalog organizing the signal properties into a unified signal representation, wherein the signal configuration of the vehicle model is based on the signal catalog. 4. The system of claim 3, wherein the signal configuration of the vehicle model omits signals for which the signal catalog does not have decoding rules for mapping vehicle-specific signal names to respective signal properties in the signal catalog. 5. The method of claim 4, wherein the one or more computing devices further:
configured to receive, from the manufacturer or the supplier, a plurality of sensor-specific signal decoding rules for decoding signals corresponding to signal properties of the signal catalog corresponding to each signal property name of the plurality of signal property names, wherein the sensor The system wherein specific signal decoding rules enable decoding signals formatted according to the in-vehicle communication signal formats of each of the vehicles in the fleet. As a method,
generating a vehicle model that organizes a subset of signal properties of a plurality of signal properties for a fleet of vehicles;
Transmitting each signal decoding rule of a plurality of signal decoding rules for decoding signal properties included in the vehicle model to vehicles in the fleet, wherein the transmitted decoding rules enable decoding of in-vehicle communication signals. ;
Transmitting a data collection scheme to each vehicle in the fleet, wherein the data collection scheme includes data extraction criteria for vehicle sensor information, and identifies the vehicle sensor information using a subset of signal properties of the vehicle model. Ham -; and
Receiving vehicle data extracted from each vehicle according to the data collection scheme decoded using transmitted signal decoding rules from each vehicle in the fleet. 7. The method of claim 6, wherein the fleet of vehicles includes vehicles having different in-vehicle communication signal configurations, and transmitting respective signal decoding rules to the vehicles in the fleet comprises vehicles having different in-vehicle communication signal configurations. A method based on which of the in-vehicle communication signal configurations are used. In clause 7,
Receiving the signal properties of each sensor of the plurality of sensors from manufacturers or suppliers of the plurality of vehicles, the plurality of vehicles comprising vehicles having different in-vehicle communication signal configurations; and
The method further comprising generating a signal catalog organizing the signal properties into a unified signal representation, wherein the signal configuration of the vehicle model is based on the signal catalog. 9. The method of claim 7 or 8, wherein the signal configuration of the vehicle model omits a signal for which decoding rules for mapping vehicle-specific signal names to respective signal properties of the signal catalog are not present in the signal catalog. In,method. According to any one of claims 6 to 9,
Receiving, from a vehicle manufacturer or supplier, a plurality of sensor-specific signal decoding rules for decoding signals corresponding to signal properties of the signal catalog corresponding to each signal property name of the plurality of signal property names, wherein the sensor specific signal decoding rules enable decoding signals formatted according to in-vehicle communication signal formats for each of the vehicles in the fleet. According to any one of claims 6 to 10,
Decoding the vehicle data extracted from each vehicle using the signal decoding rules, wherein the received vehicle data is decoded from binary resources into sensor signal values. According to clause 11,
associating the sensor signal values with one or more vehicle attributes of the vehicle from which the vehicle data was extracted; and
The method further comprising posting the sensor signal values to a time series database. The method of any one of claims 6 to 12, wherein the vehicle sensor information is:
camera data;
LiDar data;
electronic control unit (ECU) data; or
A method comprising one or more of synthetic sensor data. 14. The method of any one of claims 6 to 13, wherein the signal properties include static properties associated with a particular vehicle including unique vehicle Id, vehicle brand, body type, and vehicle engine model. 15. The method of any one of claims 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, wherein the data reduction factor is within a predetermined geographical area. A method based on the total number of vehicles in a vehicle fleet, and based on an inference of the vehicle environment of the vehicle fleet, wherein the extracted data is extracted from only a portion of the vehicle fleet.

Images