Patent Application
20220335821
This disclosure relates to methods and systems for streaming data from a very large number of vehicles to a remote data repository and generating data products based on the streaming data.
Nowadays, there is a large amount of data streamed from automobiles and other vehicles, and this data is used for various purposes, such as for providing traffic conditions of roads. In many scenarios, vehicles are configured to transmit or stream the same data continuously or periodically to a remote location, such as a remote server.
However, it has been discovered that the streams of data being sent from the vehicle to a remote location often contain unused or superfluous data and that, in some instances, while these streams of data may include the data needed for certain data products, they do not include certain data desired to be included in or needed for other data products.
According to one aspect of the disclosure, there is provided a data product system for generating and providing a data product using data supplied by a multitude of vehicles. Each vehicle has vehicle electronics that include: a plurality of vehicle subsystems each providing data; and a communications subsystem having a wireless communications device and being connected within the vehicle electronics such that the data from the vehicle subsystems is accessible by the communications subsystem, wherein the communications subsystem is configured to: (i) generate a first data stream having data accessed from the vehicle subsystems and transmit the first data stream to a remote data repository; (ii) in response to receiving a streaming data change request, modify the first data stream into a second data stream that excludes identified surplus data contained in the first data stream and includes additional data that is not contained in the first data stream; and (iii) transmit the second data stream to the remote data repository in place of the first data stream. The data product system is remote from the multitude of vehicles and includes one or more electronic processors and memory storing computer instructions, and wherein the data product system is configured so that, when the computer instructions are executed by the one or more electronic processors, the data product system: (i) generates a first data product using first repository data that is received from the remote data repository and that includes, or is at least in part based on, one or more data items that are contained in the first data streams received from at least some of the multitude of vehicles; (ii) determines data absent from the first data streams that is needed to generate a second data product; (iii) identifies surplus data having one or more data items contained in the first data stream for which the first data product can be generated using the first data streams from a first subset of the multitude of vehicles; (iv) initiates the streaming data change request to a second, different subset of the multitude of vehicles, wherein the streaming data change request specifies the surplus data and additional data needed to generate the second data product; (v) generates the second data product once the additional data begins to be received by the remote data repository, wherein the second data product is generated using second repository data that is received from the remote data repository and that includes, or is at least in part based on, the additional data; and (vi) provides the first data product to at least one third party computing device and provides the second data product to the same and/or another third party computing device.
According to various embodiments, the data product system may further include any one of the following features or any technically-feasible combination of some or all of the following features:
According to yet another aspect of the disclosure, there is provided a method of generating and providing a data product using data supplied by a multitude of vehicles. The method includes: generating a first data product using first repository data that is received from a remote data repository and that includes, or is at least in part based on, one or more data items that are contained in first data streams received from at least some of the multitude of vehicles; determining data absent from the first data streams that is needed to generate a second data product; identifying surplus data comprising one or more data items contained in the first data stream for which the first data product can be generated using the first data streams from a first subset of a multitude of vehicles; initiating a streaming data change request to a second, different subset of the multitude of vehicles, wherein the streaming data change request specifies the surplus data and additional data needed to generate the second data product; generating the second data product once the additional data begins to be received by the remote data repository, wherein the second data product is generated using second repository data that is received from the remote data repository and that includes, or is at least in part based on, the additional data; and providing the first data product to at least one third party computing device and providing the second data product to the same and/or another third party computing device.
According to various embodiments, the method may further include any one of the following features or any technically-feasible combination of some or all of the following features:
According to yet another aspect of the disclosure, there is provided a data product system for generating and providing a data product using data supplied by a multitude of vehicles. The data product system is remote from the multitude of vehicles and comprises one or more electronic processors and memory storing computer instructions, and wherein the data product system is configured so that, when the computer instructions are executed by the one or more electronic processors, the data product system: generates a first data product using first repository data that is received from a remote data repository and that includes, or is at least in part based on, one or more data items that are contained in first data streams received from at least some of the multitude of vehicles; determines data absent from the first data streams that is needed to generate a second data product; identifies surplus data comprising one or more data items contained in the first data streams for which the first data product can be generated using the first data streams from a first subset of the multitude of vehicles; initiates a streaming data change request to a second, different subset of the multitude of vehicles, wherein the streaming data change request specifies the surplus data and additional data needed to generate the second data product; generates the second data product once the additional data begins to be received by the remote data repository, wherein the second data product is generated using second repository data that is received from the remote data repository and that includes, or is at least in part based on, the additional data; and provides the first data product to at least one third party computing device and provides the second data product to the same and/or another third party computing device
According to various embodiments, with respect to the data product system, each of the multitude of vehicles is a vehicle having vehicle electronics that include: a plurality of vehicle subsystems each providing data; and a communications subsystem having a wireless communications device and being connected within the vehicle electronics such that the data from the vehicle subsystems is accessible by the communications subsystem, wherein the communications subsystem is configured to: generate a first data stream comprising data accessed from the vehicle subsystems and transmit the first data stream to the remote data repository; in response to receiving the streaming data change request, modify the first data stream into a second data stream that excludes identified surplus data contained in the first data stream and includes the additional data; and transmit the second data stream to the remote data repository in place of the first data stream.
Preferred exemplary embodiments will hereinafter be described in conjunction with the appended drawings, wherein like designations denote like elements, and wherein:
The system and method described herein enables a first data stream that is transmitted to a remote data repository to be dynamically modified so as to support the data needs of various data products in a manner that helps minimize the total volume of data transmission and storage required. This is particularly useful for connected vehicles that are configured to capture various data as data items from a variety of mostly in-vehicle data sources, including, for example, image data from cameras, wheel speed data from wheel speed sensors, global navigation satellite system (GNSS) data from a GNSS receiver, other sensor data, as well as driver inputs and settings, etc. The connected vehicles are able to package and transmit at least some of this data to a remote data repository for storage. The collection of this data in real time from a multitude of vehicles (e.g., thousands or millions of vehicles) provides a great deal of information that can be used to create different data products such as those having real time traffic, weather conditions (e.g., based on windshield wiper operation), and diagnostic information organized by make and model for various vehicle manufacturers (OEMs).
However, it has been discovered that the streams of data being sent from the vehicle to the data repository often contain unused or superfluous data, referred to herein as “surplus data”. Additionally, it has been discovered that, in some instances, this data stream, while providing the data needed to produce a first data product, does not include certain data items that are desired or needed for a particular second data product. The systems and methods provided herein enable dynamic modification of vehicle electronics so as to cause the vehicle electronics to alter the first data stream into a modified or second data stream that omits the surplus data and/or that includes desired data that is not streamed as a part of the first data stream. This permits the data product system to obtain from the data repository that data needed to produce the second data product. And, by selectively commanding only some of the multitude of vehicles to switch to providing this modified data stream, the system can continue to produce the first data product from one subset of the multitude of vehicles, while also producing the second data product from a second subset of the multitude of vehicles. Furthermore, this approach is scalable such that it can be used to create third, fourth, etc. data products, some or all of which may be created simultaneously, and if needed, in real time.
According to one embodiment, a system is provided that includes a data product system having one or more electronic processors and memory storing computer instructions. In such an embodiment, the data product system is configured so that, when the computer instructions are executed by the one or more electronic processors, the data product system: generates a first data product using first repository data that is received from the remote data repository and that includes, or is at least in part based on, one or more data items that are contained in the first data streams received from at least some of the multitude of vehicles; determines data absent from the first data streams that are needed to generate a second data product; identifies surplus data comprising one or more data items contained in the first data stream for which the first data product can be generated using the first data streams from a first subset of the multitude of vehicles; initiates the streaming data change request to a second, different subset of the multitude of vehicles, wherein the streaming data change request specifies the surplus data and additional data items needed to generate the second data product; generates the second data product once the additional data items begin to be received by the remote data repository, wherein the second data product is generated using second repository data that is received from the remote data repository and that includes, or is at least in part based on, the additional data items; and provide the first data product to at least one third party computing device and sends the second data product to the same and/or another third party computing device. In some embodiments, the first and second subsets of vehicles may be disjoint sets; i.e., none of the multitude of vehicles are in both subsets. In other embodiments, the sets may be joint; i.e., at least some of the vehicles in one subset are also in the other subset.
In accordance with at least some embodiments, the plurality of vehicles each have vehicle electronics that include a plurality of vehicle subsystems each providing data and a communications subsystem having a wireless communications device. The communications subsystem is connected within the vehicle electronics such that the data from the vehicle subsystems is accessible by the communications subsystem, and the communications subsystem is configured to: generate a first data stream comprising data accessed from the vehicle subsystems and transmit the first data stream to a remote data repository; in response to receiving a streaming data change request, modify the first data stream into a second data stream that excludes identified surplus data contained in the first data stream and includes additional data that is not contained in the first data stream; and transmit the second data stream to the remote data repository in place of the first data stream.
The surplus data may comprise specific data items from the first data stream that are not needed at the moment for any data product, or possibly not currently needed for any purpose at all, and can be excluded from the second (modified) data streams coming from the second subset of vehicles. Alternatively or additionally, the surplus data may comprise data supplied in the first data stream at a frequency in excess of that needed to produce the first data product, such that the streaming data change request may specify a longer period between occurrences of the data item in the stream, thereby lowering the total data transmission volume such that the additional data items needed for the second data product may be included with minimal or no increase to the total volume of data transmitted. In this way the data product system achieves increased efficiency in operation—by enabling it to generate additional data products without a concomitant increase in the total data volume transmitted from the vehicles individually and as a group.
In a like manner, the additional data needed for the second data product may comprise particular data items not contained at all in the first data stream, and/or may comprise existing data items in the first data stream for which a higher frequency of updates are needed. As examples, in the event of adverse weather that might affect drivability of roads in a particular geographic region (e.g., snow/sleet/ice accumulation from a storm), data not normally transmitted in the first data stream might be needed or desired to generate a (second) data product that provides more accurate/targeted information concerning driving conditions. This may include data items not normally sent concerning operator inputs such as windshield wiper activation, window defrost activation, climate control (e.g., max defrost fan) settings, selected vehicle gear/transmission settings. Alternatively or additionally, this may include data items that are included in the first data stream, but at a rate that is less than desired or needed for the second data product, such as transmission system data (e.g., wheel slip) or lateral accelerations (e.g., indicative of sliding). Some or all of this additional data may be identified in the data stream change request so that they are included in the second (modified) data stream in place of at least some of the surplus data that was being sent in the original (first) data stream.
As used herein, the following terms have the definitions given. A “data item” is an individual piece of data of any data source type, having more than one possible value and that is implemented in any useful form, such as a number, character string, one or more bits (e.g., a flag/Boolean, a string or array of binary data or bytes), etc. A “data stream” is a continuous, periodic, or intermittent transmission of at least one data item for which the data values might vary between successive transmissions of the data item. A “data source” is a particular originator of data at any suitable level of abstraction, and examples of a data source include, for example, transducers and other sensors, processor-based modules and in-vehicle computer-readable memories, devices such as vehicles and portable connected devices (PCDs) (e.g., smartphones), data repositories, and facilities such as centralized servers. A “data source type” is a generic/subgeneric classification for data that may be included in a data stream from the vehicle based on the type of data source.
In one embodiment, data from a vehicle may be divided into two generic classifications: determined data and inputted data. Determined data is data originating from a vehicle subsystem, and inputted data is data originating from a vehicle occupant or an external source, such as a user or another vehicle. Determined data may include the subgeneric classifications of measured (or sensor) data, calculated data, lookup data, and metadata. Inputted data may include the subgeneric classifications of dynamic input data (e.g., driver inputs during a journey), configuration data (e.g., vehicle settings), and externally-source data (e.g., data from other vehicles, roadside equipment, a remote facility or server). The preceding two generic and seven subgeneric data source types are intended to encompass all possible data that can be provided in a data stream from a particular vehicle, but do not need to be considered mutually exclusive of each other. Examples of measured (or sensor) data includes speed, heading, acceleration, deceleration, and battery voltage. Examples of calculated data includes location as calculated by a GNSS receiver, seat occupancy, and battery state of charge. Examples of lookup data include diagnostic trouble codes (DTCs), calibration data, average battery voltage or state of charge, and other data obtained from a lookup table that is stored in memory. Examples of metadata include driver aggressiveness classification, transmission state, and battery system health. Examples of dynamic input data include windshield wiper activation/selection, stability control setting, accelerator and brake pedal inputs, steering inputs, radio volume, and headlight setting. Examples of configuration data include automatic rain sensing, touring/sport mode, max/min startup volume settings, and auto brightness headlights.
With reference now to
The land network 24 may be a conventional land-based telecommunications network that is connected to one or more landline telephones and connects the wireless carrier system 26 to the data product system 12, the OEM data lake 21, and the OEM gateway 22. For example, the land network 24 may include a public switched telephone network (PSTN) such as that used to provide hardwired telephony, packet-switched data communications, and the Internet infrastructure. One or more segments of the land network 24 could be implemented through the use of a standard wired network, a fiber or other optical network, a cable network, power lines, other wireless networks such as wireless local area networks (WLANs), or networks providing broadband wireless access (BWA), or any combination thereof.
The wireless carrier system 26 may be any suitable cellular telephone system. The wireless carrier system 26 is shown as including a cellular tower 28; however, the wireless carrier system 26 may include additional cellular towers as well as one or more of the following components (e.g., depending on the cellular technology): base transceiver stations, mobile switching centers, base station controllers, evolved nodes (e.g., eNodeBs), mobility management entities (MMEs), serving and PGN gateways, etc., as well as any other networking components used to connect the wireless carrier system 26 with the land network 24 or to connect the wireless carrier system 26 with user equipment (UEs, e.g., which may include telematics equipment in the vehicles 14), all of which is indicated generally at 30. The wireless carrier system 26 may implement any suitable communications technology, including for example GSM/GPRS technology, CDMA or CDMA2000 technology, LTE technology, etc. In general, the wireless carrier system 26, its components, the arrangement of its components, the interaction between the components, etc. is generally known in the art.
The remote data repository 20 is used to store data received from the vehicles 14. For example, the vehicles 14 may each be configured to transmit a first data stream to the remote data repository 20 via the wireless carrier system 26 and the land network 24, and the remote data repository 20, upon receiving the first data stream, may store the data of the first data stream. The remote data repository 20 is shown as a part of the data product system 12, which may be owned and operated by an independent commercial partner of one or more of the vehicle original equipment manufacturers (OEMs). In other embodiments, the data repository may be any publicly or privately accessible aggregation of stored data, which can be structured or unstructured data and which is accessible over a global communications network such as the internet. For example, as optionally shown in
In some embodiments, the OEM may provide the data product system 12 with direct access to the vehicles; for example, by enabling direct streaming of the first and second data streams to the product system 12, rather than via the OEM gateway 22 (and optional OEM data lake 21). This may be done by providing the data product system the necessary credentials and access to the vehicles' communications system 104, and techniques for doing that will be known to those skilled in the art. Also, although the discussion herein oftentimes refers to transmitting the first data stream and the second data stream to the remote data repository 20, it should be appreciated that, in other embodiments, either or both of the first data stream and the second data stream may be transmitted to the OEM data lake 21 (or other OEM data repository) and accessed by the data product system 12.
The OEM gateway 22 is a computer system that operates as an interface between the vehicles 14 and the data product system 12. The OEM gateway 22 may be operated, managed, owned, and/or controlled (collectively “managed”) by an OEM. The OEM gateway 22 may be implemented as computer instructions that are executed by one or more computers or computing devices. In one embodiment, the OEM gateway 22 is configured to receive streaming data change proposals from the data product system 12 and to determine whether to grant or forward those requests to one or more of the vehicles 14. For example, a streaming data change proposal may be received at the OEM gateway 22 from the data product system 12. In response, the OEM gateway 22 may determine whether to generate and/or send a streaming data change request to the subset of vehicles so as to cause the subset of vehicles to modify a data stream, such as for modifying the first data stream that is provided to the remote data repository 20. The OEM gateway 22 may implement certain rules or logic to determine whether a particular request from the data product system 12 should or should not be granted, such as whether the requested change would cause data used for other systems/applications to not be a part of the stream or whether the requested change would cause a reduction in performance to a level below a predetermined threshold amount or cause an increase in cost to an amount above a predetermine threshold amount.
The data product system 12 is a centralized or distributed computer system that is used to generate one or more data products having data from the remote data repository 20. In at least some embodiments, the data product system 12 is operated, managed, owned, and/or controlled by a data product party, which is a party that is separate than the OEM that manages the OEM gateway 22. The data product system 12 is shown as including the remote data repository 20 as well as a computing device 34 having an electronic processor 36 and computer-readable memory 38. As used herein an “electronic processor” is a physical processing device that operates under electrical power to execute computer instructions. These computer instructions are stored on the computer-readable memory 38 which is accessible by the electronic processor 36 so that the electronic processor 36 may execute the computer instructions stored on the memory 38. Although the data product system 12 is illustrated as including a single computing device 34, it should be appreciated that, in other embodiments, the data product system 12 includes a plurality of computing devices 34, each of which has an electronic processor and memory. Moreover, in at least some embodiments, the data product system 12 may be provisioned across numerous instances and the functionality described herein as being carried out by the data product system 12 may be carried out in a distributed fashion, such as by one or more computing devices that may or may not be co-located with one another. Additionally, it should be appreciated that the computer instructions of the data product system 12 may be stored on one or more memories and/or executed by one or more electronic processors, even though
The plurality of vehicles 14 includes at least the first vehicle 16 and the second vehicle 18, each of which is depicted in the illustrated embodiment as a passenger car, but it should be appreciated that any other vehicle including motorcycles, trucks, sports utility vehicles (SUVs), recreational vehicles (RVs), other vehicles or mobility devices that can be used on a roadway or sidewalk, boats, other marine vessels, planes, unmanned aerial vehicles (UAVs), other aerial vehicles, etc., can also be used. Although
With reference to
The vehicle electronics 100 includes a plurality of vehicle subsystems 102, a communications subsystem 104 having an onboard computer 106 and a wireless communications device 108, and a communications network 110. The plurality of vehicle subsystems 102 is shown as including a first vehicle subsystem 112, a second vehicle subsystem 114, and a third vehicle subsystem 116; however, it should be appreciated that, in other embodiments, the plurality of vehicle subsystems 102 may include any suitable number of vehicle subsystems. In one embodiment, the first vehicle subsystem 112 is a vehicle positioning subsystem that is used to determine a global navigation satellite system (GNSS) position of the vehicle, such as a geographical positioning system (GPS) position that includes a latitudinal and longitudinal coordinate pair. The second vehicle subsystem 114, at least according to one embodiment, may be a body computer, and the third vehicle subsystem 116 may be an engine controller. Of course, any vehicle subsystem that provides data over the vehicle's bus (e.g., over communications network 110) or that otherwise provides data accessible by the communications subsystem 104 may be used as a data source for data items sent to the remote data repository.
The communications subsystem 104 includes the wireless communications device 108 and is connected within the vehicle electronics 100 such that the data from the vehicle subsystems 102 is accessible by the communications subsystem 104. The communications subsystem 104 is also shown as including the onboard computer 106, which may be used to carry out various processing of the communications subsystem 104, such as that which is described below as being a part of method 400 (
The onboard computer 106 includes an electronic processor 118 and memory 120 having in-vehicle computer instructions. The memory 120 is operatively coupled to the electronic processor 118 so that the electronic processor 118 may access contents of the memory 120, including the in-vehicle computer instructions. The electronic processor 118 is configured to execute the in-vehicle computer instructions, which, in at least one embodiment, cause the method 400 (
The wireless communications device 108 is used to provide remote network connectivity to the vehicle electronics 100. The wireless communications device 108 is illustrated as including a cellular chipset 122 and a short range wireless communication (SRWC) circuit 124. However, in other embodiments, the wireless communications device 108 may include only one of a cellular chipset 122 and a SRWC circuit 124. Long-range or remote data communications may be carried out by the wireless communications device 108, such as for purposes of transmitting streaming data to the remote data repository 20. The cellular chipset 122 may be used to provide internet connectivity to the vehicle electronics 100 through establishing communications with the cellular tower 28 of the wireless carrier system 26.
The SRWC circuit 124 enables the vehicle to send and receive wireless messages using one or more SRWC technologies, such as Wi-Fi™, Bluetooth™, IEEE 802.11p, other vehicle to infrastructure (V2I) communications, vehicle to vehicle (V2V) communications, other vehicle to everything (V2X) communications, etc. In one embodiment, the SRWC circuit 124 may be used to connect to a wireless access point hosted by another device, such as a wireless communication device included as a part of roadside equipment or a wireless router located at a vehicle user's residence, which may then provide internet or remote network connectivity. For example, the SRWC circuit 124 may transmit data from the vehicle to the remote data repository via a Wi-Fi™ connection between the wireless communications device 108 and a wireless router/modem, which is then connected to the internet, such as by way of land network 24.
The communications network 110 is an in-vehicle communications network that communicatively couples two or more components or subsystems of the vehicle electronics 100 to each other so that the two or more components may carry out communications. In the illustrated embodiment of
In one embodiment, the onboard computer 106 is configured to obtain certain data communicated over the communications network 110 and, in a particular embodiment, to obtain certain data provided over one or more hardwired communication network busses. The onboard computer 106 may be initially configured to obtain data items that are used to form the first data stream that is transmitted from the vehicle electronics 100 to the remote data repository 20 using the wireless communications device 108. As will be described in more detail below, each of the vehicles 14 may obtain data that is then streamed to the remote data repository 20 as a data stream. As used herein, reference to a particular data set, such as the first data set or second data set, refers to a corresponding collection of data from the vehicles 14 as a whole and not to data items of a single vehicle or subset of vehicles, unless otherwise specified or indicated.
In one embodiment, the onboard computer 106 stores one or more data models that are used to indicate one or more data items that are to be included in a data stream. In some embodiments, any one or more of the data models may also include information indicating data streaming parameters, such as the frequency with which the data items are to be captured and/or streamed. The data model(s) may be stored in the memory 120 and accessed by the electronic processor 118, such as during execution of the in-vehicle computer instructions. The “first data model” refers to a data model that is used to specify the data items that are included as a part of the first data stream, and the “second data model” refers to a data model that is not the first data model and that is used to specify the data items that are included as a part of the second data stream. In at least some embodiments, the first data model is specified as a part of an initial configuration or provisioning process of the vehicle electronics 100, such as at the time of manufacture of the vehicle or initial sale/lease of the vehicle. In such embodiments, the first data model may be referred to as an initial data model and the first data stream may be referred to as an initial data stream. Moreover, in some embodiments, the first data model is specified by an OEM of the vehicle as a result of its own volition (i.e., not as a result of a request by a third party) and, in such an embodiment, the first data model may be referred to as an OEM-provisioned data model and the first data stream may be referred to as an OEM-provisioned data stream.
Any one or more of the electronic processors discussed herein may be implemented as any suitable electronic hardware that is capable of processing computer instructions and may be selected based on the application in which it is to be used. Examples of types of electronic processors that may be used include central processing units (CPUs), graphics processing units (GPUs), field-programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), microprocessors, microcontrollers, etc. Any one or more of the non-transitory, computer-readable memory discussed herein may be implemented as any suitable type of memory that is capable of storing data or information in a non-volatile manner and in an electronic form so that the stored data or information is consumable by the electronic processor. The memory may be any a variety of different electronic memory types and may be selected based on the application in which it is to be used. Examples of types of memory that may be used include including magnetic or optical disc drives, ROM (read-only memory), solid-state drives (SSDs) (including other solid-state storage such as solid-state hybrid drives (SSHDs)), other types of flash memory, hard disk drives (HDDs), non-volatile random access memory (NVRAM), etc. It should be appreciated that the computers or computing devices may include other memory, such as volatile RAM that is used by the electronic processor, and/or may include multiple electronic processors.
With reference to
The first request handler 210 is a part of the communications subsystem 104 and is used to handle requests received from the OEM gateway 22 and, in particular, to handle streaming data change requests received at the vehicle electronics 100. Although
The data selection unit 212 is a part of the communications subsystem 104 and is used to select which data items are to be included as a part of a data stream that is streamed from the vehicle electronics 100 to the remote data repository 20. The data selection unit 212 is configured to, in response to a streaming data change request being received (and/or approved) at the vehicle electronics 100, modify a data stream, such as modifying the first data stream to exclude identified surplus data and to include one or more other data items that are not contained in the first data stream. In one embodiment, the data selection unit 212 is used to select a data model that is to be used to indicate which data items are to be included in the modified or second data stream.
Each of the first request handler 210 and the data selection unit 212 may be implemented as executable computer instructions that, when executed by one or more electronic processors of the communications subsystem 104 (e.g., the electronic processor 118 of the onboard computer 106), cause the communications subsystem 104 to carry out the functionality described herein as being attributed to the first request handler 210 or the data selection 212, respectively. Specifically, for example, the vehicle electronics 100 may include first request handler computer instructions that, when executed, cause the functionality attributed to the first request handler 210 to be carried out.
As is also shown in
The data product generator 220 is shown as including the sufficiency module 222, which is used to identify surplus data. The surplus data may comprise one or more data items contained in the first data stream for which the first data product can be generated using the first data stream from a first subset of the plurality of vehicles—that is, the surplus data includes data item(s) that are a part of the first data stream, but that do not need to be received from each of the vehicles providing the first data stream because, for example, obtaining and storing these data item(s) is unnecessary or superfluous. For example, when there are 10,000 vehicles in a particular geographical region that are each sending traffic-related information as a part of the first data stream, it may be determined that the traffic-related information need not be received from each of the 10,000 vehicles, but that the traffic-related information should be received from only 2,000 of the 10,000 vehicles since such information from 2,000 vehicles is sufficient and such information from the other 8,000 vehicles is not needed or redundant. In such an instance, the first subset of vehicles corresponds to the 2,000 vehicles and the remaining 8,000 vehicles corresponds to a second subset of vehicles. In this example, the surplus data includes those data items that provide the traffic-related information. The sufficiency module 222 is shown in
In one embodiment, in addition to identifying the surplus data, the sufficiency module 222, or other portion of the data product system 12, may determine vehicle selection data that specifies a subset of vehicles. The vehicle selection data may include vehicle selection parameters or vehicle identification data. The vehicle selection parameters are parameters used to specify a subset of vehicles without uniquely identifying any of the vehicles in the subset of vehicles, and the vehicle identification data is data or information uniquely specifying each vehicle of a subset of vehicles.
The second request handler 224 is a part of the data product system 12 and is communicatively coupled to the sufficiency module 222. The second request handler 224 is responsive to identification of the surplus data and to data product request data. In one embodiment, the second request handler 224 receives data identifying the data items of the surplus data and the vehicle selection data from the sufficiency module 222. The data product request data may be data indicating one or more data items that are to be included in a data product that is requested by the data product customer 200, such as the second data product. The data product request data may be provided to the second request handler 224 directly from the data product customer 200, such as through an application programming interface (API), or may be provided from the data product customer 200 to a person of the party managing the data product system 12. In the latter case, the person may input the data product request data into the data product system 12 such that it is accessible by the second request handler 224.
The communications handler 226 is used to initiate a streaming data change request to the second subset of vehicles, where the streaming data change request specifies one or more other data items needed to generate the second data product. In at least some embodiments, the streaming data change request further specifies the surplus data or the data items of the first data stream that are no longer needed to be transmitted from the second subset of vehicles. The communications handler 226 may initiate the streaming data change request directly by sending the streaming data change request to the second subset of vehicles, or may initiate the streaming data change request by sending a streaming data change proposal to the OEM gateway 22, which then, based on the streaming data change proposal, sends the streaming data change request to the second subset of vehicles. The streaming data change request or the streaming data change proposal may be compiled by the communications handler 226 into one or more electronic messages, which are then sent to the OEM gateway 22 or the second subset of vehicles.
Each of the data product generator 220, the sufficiency module 22, the second request handler 224, and the communications handler 226 may be implemented as executable computer instructions that, when executed by one or more electronic processors of the data product system 12 (e.g., the electronic processor 36 of the computing device 34), cause the data product system 12 to carry out the functionality described herein as being attributed to the data product generator 220, the sufficiency module 22, the second request handler 224, and the communications handler 226, respectively. Specifically, for example, the data product system 12 may include data product generator computer instructions that, when executed, cause the functionality attributed to the data product generator 220 to be carried out.
In one example, the first data product is responsive to a generalized set of vehicle data in the first data stream and supports a first data product, such as generalized traffic intelligence information about vehicle road speeds, road densities, parking densities, travel times between major points, etc. The data product system 12 may, in response to an external weather forecast data, provide a request for enhanced environmental sensor information from a subset of vehicles in a designated geographical area. The second request handler 224 arbitrates this request by considering whether the designated geographical area has sufficient density of connected vehicles to send a request through the communications handler 226 to reassign a subset of the vehicles in the designated geographical area to send the enhanced environmental sensor data in lieu of at least some of the first data stream. Alternatively, the arbitration by the second request handler 224 may attach a relative weight to consider the importance or priority of the request. The OEM gateway 22 sends the responsive communications to the appropriate vehicle subset of connected vehicles 14. In an example, the data for the second data stream is already available on a vehicle data bus and accessible by the communications subsystem 104. The data selection unit 212 executes instructions directing the communications subsystem 104 to read the enhanced environmental sensor data from the vehicle data bus for transmission as the second data stream, which is sent using the wireless communications device 108. In an example, the enhanced environmental data may be processed, interpreted, normalized, or subject to other operations the results of which are included in the transmission of the second data stream along with or in lieu of the raw vehicle data bus data. Through the process described above, a subset of the connected vehicles in the designated geographic area begin to transmit a second data stream that traverses communications channels as described above to the data product system 12, which uses the data to provide a weather-based data product.
In another example, the data product system 12 may request data in response to an external request from a supplier of modules that were installed by one or more vehicle original equipment manufacturers into at least a portion of the vehicles 14. This request may be for output, performance, or diagnostic data produced by or related to the modules from the supplier. This request may come from an external interface into system 12 or may come from a data product module within the data product system 12 responsive to a prior data product purchase arrangement between the operator of the data product system 12 and the supplier. As described above, the second request handler 224 arbitrates this request, including selecting a vehicle set or a vehicle criteria that can provide the data meeting the request, and sends the required communications through the communications handler 226. The OEM gateway 22 sends the responsive communications to the appropriate subset of vehicles 14. In this example a subset of the vehicles begin to transmit the second data stream that contains the module output, performance, and/or diagnostic data. This data stream traverses communications channels as described above to the data product system 12, which uses the data to provide a module performance data product to the supplier. The supplier may utilize this data for a variety of purposes, including, for example, to determine the performance of the module, determine whether a group of modules could benefit from a software update, or to support a service associated with the module. An advantage of this example is the potential for suppliers of vehicle components to request information about components already in production, which can be satisfied through data products added to the data product system 12.
With reference to
The method 300 begins with step 310, wherein a first data product is generated using first repository data that is received from the remote data repository. The first repository data includes, or is at least in part based on, one or more data items that are contained in the first data streams received from at least some of the multitude of vehicles. In one embodiment, the data product generator 220 obtains data that was stored at the remote data repository 20 as a result of the first data stream from the multitude of vehicles and then processes the obtained data to generate the first data product. In another embodiment, the data that was stored at the remote data repository 20 as a result of the first data stream may first be processed, such as for calculating analytics describing the data, by another device or system before it is received at the data product generator 220. Once the first data product is assembled or otherwise generated, the first data product may be provided to the data product customer 200, such as through electronically transmitting the first data product to a computing device used by the data product customer 200 or by making the first data product available to the data product customer 200, such as by sending a download URL to the data product customer 200 that enables the data product customer 200 to download the first data product. The method 300 continues to step 320.
In step 320, one or more other data items are determined as being absent from the first data stream and needed to generate a second data product. In at least some embodiments, the second data product includes data derived or otherwise obtained from at least one data item that is not included or used to generate the first data product. In one embodiment, the second request handler 224 of the data product system 12 may receive data product request data that indicates one or more data items needed to generate the second data product. As discussed above, the data product request data may be received directly from the data product customer 200, such as through use of an API, or may be entered into or otherwise provided to the data product system 12 by a person at the direction or request of the data product customer 200. The method 300 continues to step 330.
In step 330, surplus data is identified, wherein the surplus data comprises one or more data items contained in the first data stream for which the first data product can be generated using the first data stream from a first subset of the multitude of vehicles. In one embodiment, the data product system 12 obtains information concerning a first data set, which is data stored in the remote data repository 20 as a result of the first data stream from the multitude of vehicles 14. This information, which describes the first data set and may be referred to as first data set information, may include portions of the first data set or access information concerning the first data set. The access information refers to information indicating whether certain data of the first data set has been accessed after it has been initially stored at the remote data repository 20. For example, the remote data repository 20 may keep an ongoing access log that logs when and what data is accessed.
In another embodiment, the identification of surplus data may be made without having to access data of the first data set, but, instead, based on whether the system predicts or anticipates that certain data being streamed to the remote data repository 20 is not or will not be needed. For example, the data product system 12 may be configured to determine that there is or will be surplus data stored at the remote data repository 20 if the first data stream continues unmodified based on, for example, the fact that a particular geographical region includes (or is predicted to include at a particular time) a high density of vehicles that are reporting traffic-related information. In such a scenario, the data product system 12 may be configured to determine that data being streamed, or that will be streamed (if the first data stream is left unmodified), to the remote data repository 20 includes surplus data simply because historically this has been true under these above-described circumstances.
In addition to determining whether data stored in a remote data repository includes surplus data, the data product system 12 may also determine or identify the second subset of vehicles, which are those vehicles that no longer need (or will no longer need) to transmit the surplus data. For example, in one instance and according to one embodiment, it may be determined that traffic-related information, such as the vehicle location over time, may not be needed for a set of vehicles of a particular geographical region because that geographical region includes a very dense distribution of vehicles, such as may be the case in a heavily populated urban center. In such an instance, the data product system 12 may select one or more vehicles that are to forgo sending the traffic-related information as a part of the first data stream and the identity of these particular vehicles may be represented by vehicle selection data that is generated by the data product system 12. In another embodiment, the data product system 12 may identify vehicle selection parameters that are then included as a part of the vehicle selection data and, in one embodiment, these vehicle selection parameters may be included in lieu of (or in addition to) the vehicle identification data. In such embodiments, the OEM gateway 22 (or other system) may identify one or more particular vehicles based on the vehicle selection parameters received from the data product system 12. The method 300 continues to step 340.
In step 340, a streaming data change request to a second subset of the multitude of vehicles is initiated. The streaming data change request specifies the one or more other data items needed to generate the second data product and the surplus data. In at least one embodiment, this step is performed by the communications handler 226 of the data product system 12. In some embodiments, this step is performed by sending a streaming data change proposal to the OEM gateway 22 and, in such embodiments, the streaming data change proposal may specify the one or more other data items needed to generate the second data product and the surplus data. Also, in at least some of such embodiments, the OEM gateway 22 may be configured so that, when the streaming data change proposal is received, the OEM gateway 22 determines whether to accept the proposal and, if so, generates and transmits a streaming data change request to the second subset of vehicles. In another embodiment, the communications handler 226 (or other portion of the data product system 12) generates and sends the streaming data change request to the second subset of vehicles without having to first send the streaming data change proposal (or other related information) to the OEM gateway 22. The method 300 then continues to step 350.
In at least some embodiments, a method of modifying a data stream and sending the data stream, as modified, to a remote data repository may be carried out by each of the second subset of vehicles, such as the method 400 (
In step 350, the second data product is generated using second repository data that is received from the remote data repository. The second repository data includes, or is at least in part based on, the one or more other data items once the one or more other data items begin to be received by the remote data repository. This step may be carried out in the same or a similar manner as step 310, except that second repository data is used to generate the second data product. The method 300 continues to step 360.
In step 360, the first data product and the second data product are provided to at least one third party computing device (e.g., a third party's server, data repository, client device, or portable connected device). In one embodiment, the first data product and second data product are provided to the same third party computing device, such as for purposes of providing both data products to a single customer. In another embodiment, the first data product may be sent or otherwise provided to a first third party computing device associated with a first data product customer, and the second data product may be sent or otherwise provided to a second third party computing device associated with a second data product customer that is different than the first data product customer. In one embodiment, the data product system 12 transmit the data products to the third party computing device or, in another embodiment, the data product system 12 provides a download link to the third party computing device that is usable to access and download the data products. The method 300 then ends.
With reference to
The method 400 begins with step 410, wherein first data stream is generated and transmitted to a remote data repository. The first data stream comprises data accessed from the vehicle subsystems. The data selection unit 212 may be used to indicate which data items to include as a part of the first data stream. For example, in one embodiment, a first data model indicating one or more data items to be included in the first data stream may be provided by the data selection unit 212. The communications subsystem 104, such as through use of the onboard computer 106, may then obtain the data items from one or more of the plurality of vehicle subsystems 102 and transmit the obtained data items to the remote data repository 20. The method 400 continues to step 420.
In step 420, the first data stream is modified into a second data stream that excludes identified surplus data contained in the first data stream and includes one or more other data items that are not contained in the first data stream. As mentioned above, this step may be carried out in response to receiving a streaming data change request, such as the streaming data request described above in the method 300 (
In step 430, the second data stream is transmitted to the remote data repository in place of the first data stream. After the first data stream is modified into the second data stream, the communications subsystem 104 may then begin to generate the second data stream and then transmit the second data stream to the remote data repository 20, at least according to some embodiments. The second data stream, which includes the other data items that are/were not contained in the first data stream, is transmitted instead of the first data stream. The method 400 then ends.
It is to be understood that the foregoing description is of one or more embodiments of the invention. The invention is not limited to the particular embodiment(s) disclosed herein, but rather is defined solely by the claims below. Furthermore, the statements contained in the foregoing description relate to the disclosed embodiment(s) and are not to be construed as limitations on the scope of the invention or on the definition of terms used in the claims, except where a term or phrase is expressly defined above. Various other embodiments and various changes and modifications to the disclosed embodiment(s) will become apparent to those skilled in the art.
As used in this specification and claims, the terms “e.g.,” “for example,” “for instance,” “such as,” and “like,” and the verbs “comprising,” “having,” “including,” and their other verb forms, when used in conjunction with a listing of one or more components or other items, are each to be construed as open-ended, meaning that the listing is not to be considered as excluding other, additional components or items. Other terms are to be construed using their broadest reasonable meaning unless they are used in a context that requires a different interpretation. In addition, the term “and/or” is to be construed as an inclusive OR. Therefore, for example, the phrase “A, B, and/or C” is to be interpreted as covering all of the following: “A”; “B”; “C”; “A and B”; “A and C”; “B and C”; and “A, B, and C.”
| Number | Date | Country | |
|---|---|---|---|
| 63176171 | Apr 2021 | US |
