Vehicle data analysis based on differential privacy usage

Abstract

The invention provides vehicle data analysis based on differential privacy usage. Collecting and processing vehicle data with differential privacy are provided. A set of differential privacy settings corresponding to a user is received by a telematics control unit (TCU) of a vehicle, the differential privacy settings defining which sets of one or more vehicle signals are to be sent to a cloud server. The TCU captures a plurality of vehicle signals from a plurality of controllers and / or sensors of the vehicle. The TCU applies a filter to the vehicle signal in accordance with the differential privacy setting to generate a filtered signal. The filtered signal is encoded as a sparse signal. The sparse signal is transmitted from the vehicle to the cloud server for processing by an analytical model to determine a metric for the vehicle from the differential privacy setting of the user.

Description

Vehicle data analysis based on differential privacy Technical Field

[0001] The various aspects of this disclosure generally involve the use of differential privacy settings for vehicle-based data analysis. Background Technology

[0002] Connected vehicles can send data to cloud systems. Usage-based insurance (UBI) is a type of vehicle insurance where the premium burden depends on the driver's driving behavior. UBI devices can connect to the vehicle network via connectors, such as On-Board Diagnostics II (OBD-II) ports, to collect vehicle operating data and send it to a remote server for analysis. In other examples, the vehicle's Telematics Control Unit (TCU) can collect vehicle operating data and send it to a remote server for analysis.

[0003] An autoencoder is a type of artificial neural network used in unsupervised learning for data compression and feature extraction. An autoencoder consists of two main parts: an encoder that compresses the input data into a latent space representation, and a decoder that reconstructs the original data from this compressed form. Summary of the Invention

[0004] In one or more illustrative examples, a method for collecting and processing vehicle data with differential privacy includes: receiving by a controller of a vehicle a set of differential privacy settings corresponding to a user of the vehicle, the differential privacy settings defining which groups of one or more vehicle signals to be sent to a cloud server; capturing by the controller multiple vehicle signals from multiple controllers and / or sensors of the vehicle; applying filters to the vehicle signals by the controller according to the differential privacy settings to generate filtered signals; encoding the filtered signals into sparse signals; and transmitting the sparse signals from the vehicle to the cloud server for processing by an analysis model to determine metrics of the vehicle based on the user's differential privacy settings.

[0005] In one or more illustrative examples, the encoding of the filtered signal to the sparse signal includes using a latent space model comprising an encoder and a decoder, such that the encoding of the filtered signal to the sparse signal is performed using an encoder, as mounted on the vehicle.

[0006] In one or more illustrative examples, encoding the filtered signal into the sparse signal includes performing principal component analysis to reduce the dimensionality of the filtered signal by finding a subset of orthogonal components that capture the variance in the filtered signal.

[0007] In one or more illustrative examples, the method further includes using the vehicle's sensors to detect the presence of the user; and filtering the vehicle signal according to the differential privacy settings corresponding to the user whose presence was detected.

[0008] In one or more illustrative examples, the differential privacy setting includes a noise addition parameter, and the filter adds noise to the vehicle signal before encoding to enhance user privacy.

[0009] In one or more illustrative examples, the noise added by the filter is Gaussian noise, Laplace noise, or a reduction in the fidelity of the vehicle signal, and the amount of noise can be adjusted based on differential privacy settings.

[0010] In one or more illustrative examples, the method further includes displaying a set of user-selectable signal controls on a human-machine interface (HMI), each control corresponding to a different group of the one or more vehicle signals; and updating the differential privacy settings based on selections received from the user regarding which groups of the one or more vehicle signals to share with the cloud server.

[0011] In one or more illustrative examples, the method further includes providing on the HMI an indication of which groups of the one or more vehicle signals are associated with the metric generated by the analysis model, to help the user select the one or more vehicle signals to share.

[0012] In one or more illustrative examples, the method further includes receiving a message instructing a request to update user-selectable signal controls for the group, based on an analysis by the cloud server of the contribution of the one or more vehicle signals of the group to the metric.

[0013] In one or more illustrative examples, the analytical model determines metrics about vehicle maintenance.

[0014] In one or more illustrative examples, the analytical model determines a metric about insurance based on usage.

[0015] In one or more illustrative examples, a system for determining vehicle metrics using general signals includes: one or more computing devices of a cloud server, the one or more computing devices including non-transitory storage and a processor, the one or more computing devices being configured to: receive sparse signals from a plurality of vehicles corresponding to vehicle data captured by sensors and / or controllers of the vehicles, the sparse signals being filtered according to a differential privacy setting, the differential privacy setting defining which groups of one or more vehicle signals to be sent to the cloud server; have the cloud server apply an analysis model to the sparse signals to generate vehicle metrics; analyze the vehicle metrics to obtain the contribution of the group of one or more vehicle signals to the metrics; and send a message updating the group of one or more vehicle signals to the vehicles based on the cloud server's analysis of the contribution of the group of one or more vehicle signals to the metrics.

[0016] In one or more illustrative examples, one or more computing devices are also configured to transmit generated vehicle metrics to a metrics server in response to a client query for access by an insurance provider or vehicle service entity.

[0017] In one or more illustrative examples, the one or more computing devices are also configured to provide a set of user-selectable signal controls on the HMI, each control corresponding to a different group of the one or more vehicle signals; and to update the user's differential privacy settings based on the user's selection of which groups of the one or more vehicle signals to share with the cloud server.

[0018] In one or more illustrative examples, the one or more computing devices are also configured to provide on the HMI an indication of which groups of the one or more vehicle signals are associated with the metric generated by the analysis model, to help the user select the one or more vehicle signals to share.

[0019] In one or more illustrative examples, the sparse signal is encoded by an encoder using a latent space model that includes the encoder and the decoder, and the one or more computing devices are further configured to apply the sparse signal to the analysis model without using the decoder to decode the sparse signal.

[0020] In one or more illustrative examples, the sparse signal is encoded by performing principal component analysis to reduce the dimensionality of the vehicle data by finding a subset of orthogonal components that capture the variance in the vehicle data.

[0021] In one or more illustrative examples, a vehicle for collecting and processing vehicle data with differential privacy includes one or more sensors and / or controllers; and a processing controller communicating with the one or more sensors and / or controllers, the processing controller being configured to: receive a set of differential privacy settings corresponding to a user of the vehicle, the differential privacy settings defining which groups of one or more vehicle signals to send to a cloud server; capture multiple vehicle signals from the one or more sensors and / or controllers; use the one or more sensors and / or controllers to detect the presence of a user; apply a filter to the vehicle signals to generate a filtered signal according to the differential privacy settings corresponding to the user whose presence is detected; encode the filtered signal into a sparse signal by an encoder, such as one mounted on the vehicle, using a latent spatial model including the encoder and decoder; and transmit the sparse signal from the vehicle to the cloud server for processing by an analysis model to determine a metric of the vehicle based on the user's differential privacy settings.

[0022] In one or more illustrative examples, the differential privacy setting includes a noise addition parameter, and the filter adds noise to the vehicle signal before encoding to enhance user privacy.

[0023] In one or more illustrative examples, the noise added by the filter is Gaussian noise, Laplace noise, or a reduction in the fidelity of the vehicle signal, and the amount of noise can be adjusted based on differential privacy settings.

[0024] In one or more illustrative examples, the processing controller is also configured to display a set of user-selectable signal controls on the HMI, each control corresponding to a different group of the one or more vehicle signals; and to update the differential privacy settings based on selections received from the user regarding which groups of the one or more vehicle signals to share with the cloud server.

[0025] In one or more illustrative examples, the processing controller is also configured to provide on the HMI an indication of which groups of the one or more vehicle signals are associated with the metric generated by the analysis model, to help the user select the one or more vehicle signals to share.

[0026] In one or more illustrative examples, the processing controller is also configured to receive a message instructing a request to update the user-selectable signal controls for the group, based on the cloud server's analysis of the contribution of the one or more vehicle signals of the group to the metric. Attached Figure Description

[0027] Figure 1 illustrates an exemplary system for performing differential privacy using an autoencoder and user-specific settings; Figure 2 illustrates an exemplary autoencoder architecture for use in the system of Figure 1; Figure 3 illustrates an exemplary data flow of the operation of the system of Figure 1; Figure 4 illustrates an example of a human-machine interface (HMI) for configuring differential settings; Figure 5 illustrates an exemplary process for implementing the use of differential settings in data collection by a vehicle; Figure 6 illustrates an exemplary process for performing analysis of sparse signals by a cloud server; and Figure 7 illustrates an exemplary computing device for performing differential privacy using an autoencoder and user-specific settings. Detailed Implementation

[0028] Detailed embodiments of the invention are disclosed herein as needed; however, it should be understood that the disclosed embodiments are merely examples of the invention that can be embodied in various forms and alternative forms. The drawings are not necessarily drawn to scale; some features may be enlarged or minimized to show details of specific components. Therefore, the specific structural and functional details disclosed herein are not to be construed as limiting, but only as representative bases for teaching those skilled in the art to employ the invention in various ways.

[0029] This disclosure provides a method for incorporating differential privacy into the collection and analysis of usage-based insurance (UBI) data. The method utilizes differential privacy settings, where each vehicle identification number (VIN) registered in the data collection program is assigned specific privacy settings, allowing for customizable privacy protection based on individual preferences. The method can also leverage latent space models, such as variational autoencoders (VAEs) for encoding and decoding the data, to achieve efficient and accurate analysis while maintaining privacy. In some examples, the settings can be further based on local regulations and / or vehicle capabilities.

[0030] By implementing differential privacy at the core of the data collection process, the method ensures that each VIN has different levels of privacy settings, thereby protecting the vehicle owner's sensitive information. Different privacy levels can be based on a customer's choice of insurance products that may have different prices. In some examples, customer choices may affect product rates or other aspects. In some examples, the model itself can be used to suggest which customer choices to make to balance privacy and optimal outcomes. Further aspects of this disclosure are discussed in detail herein.

[0031] Figure 1 illustrates an exemplary system 100 for performing differential privacy using an automatic encoder and user-specific settings. System 100 includes one or more vehicles 102, each vehicle 102 including multiple controllers 104 and sensors 106. Each vehicle 102 also includes one or more vehicle buses 108 for communication between the controllers 104, sensors 106, and a telematics control unit (TCU) 110. The TCU 110 includes or otherwise accesses a modem 112 configured to facilitate communication via a communication network 114. The TCU 110 may include a processor 116 and a storage device 118. The TCU 110 can capture signals 122 and store them in the storage device 118. The storage device 118 may also maintain an event processing application 138 and an encoder 124. The event processing application 138 can use the encoder 124 to encode the signals 122 into a sparse signal 128 using differential settings 125, and can send the sparse signal 128 to a cloud server 120. Cloud server 120 can also be configured to perform vehicle data service 136, which uses one or more analytics models 132 to operate on sparse signal 128 to determine various metrics 134. In one example, metrics 134 can also be provided to metrics server 140 in response to client query 142 to quote insurance rates for vehicle 102 and / or to schedule maintenance for vehicle 102. It should be noted that system 100 is merely an example and a system 100 with more, fewer, or different components can be used. As one possibility, one or more analytics models 132 can run on vehicle 102, wherein such metrics 134 are provided to cloud server 120 and / or metrics server 140. As another possibility, the operations disclosed to be performed by TCU 110 can be performed wholly or partially by one or more other processing controllers, such as by a gateway controller acting as an intermediary facilitating communication between other controllers 104.

[0032] Vehicle 102 can be any type of automobile, crossover multi-purpose vehicle (CUV), sports multi-purpose vehicle (SUV), truck, recreational vehicle, boat, aircraft, or other mobile machine used for transporting people or goods. Such vehicle 102 can be human-driven or autonomous. In many cases, vehicle 102 can be powered by an engine. As another possibility, vehicle 102 can be a battery electric vehicle (BEV) powered by one or more electric motors. As another possibility, vehicle 102 can be a hybrid electric vehicle (HEV) powered by both an engine and one or more electric motors, such as a series hybrid electric vehicle (SHEV), a parallel hybrid electric vehicle (PHEV), or a parallel / series hybrid electric vehicle (PSHEV). Alternatively, vehicle 102 can be an autonomous vehicle (AV). The level of automation can vary between different levels of driver assistance technology and fully automated driverless vehicles. Because the type and configuration of vehicle 102 can vary, the capabilities of vehicle 102 can vary accordingly. As some other possibilities, vehicle 102 can have different capabilities in terms of passenger capacity, towing capacity and storage capacity. For ownership, inventory, and other purposes, vehicle 102 may be associated with a unique identifier (such as a VIN). It should be noted that while autonomous vehicle 102 is being used as an example of a traffic participant, other types of traffic participants, such as bicycles, motorcycles, and pedestrians, may be used alternatively or as alternatives.

[0033] Vehicle 102 may include multiple controllers 104 configured to perform and manage various vehicle 102 functions under the power of the vehicle battery and / or drivetrain. As shown, exemplary vehicle controllers 104 are represented as discrete controllers 104 (i.e., controllers 104A to 104G). However, vehicle controllers 104 may share physical hardware, firmware, and / or software, such that functionality from multiple controllers 104 can be integrally formed into a single controller 104, and functionality of various such controllers 104 can be distributed across multiple controllers 104.

[0034] As some examples of non-limiting vehicle controllers 104: Powertrain controller 104A may be configured to provide control over engine operating components (e.g., idle speed control components, fuel delivery components, emission control components, etc.) and to monitor the status of such engine operating components (e.g., the status of engine codes); Body controller 104B may be configured to manage various powertrain control functions such as exterior lighting, interior lighting, keyless entry, remote start, and access point status verification (e.g., the closing status of the hood, doors, and / or trunk of vehicle 102); Radio transceiver controller 104C may be configured to communicate with key fobs, mobile devices, or other local... Vehicle 102 communicates with the device; autonomous controller 104D can be configured to provide commands to control the powertrain, steering or other aspects of vehicle 102; climate control management controller 104E can be configured to provide control over heating and cooling system components (e.g., compressor clutch, blower fan, temperature sensor, etc.); global navigation satellite system (GNSS) controller 104F can be configured to provide vehicle location information; and HMI controller 104G can be configured to receive user input via various buttons or other controls, and to provide the driver with vehicle status information, such as fuel level information, engine operating temperature information, and the current location of vehicle 102.

[0035] The controller 104 of vehicle 102 may utilize various sensors 106 to receive information about the surrounding environment of vehicle 102. In one example, these sensors 106 may include one or more of a camera (e.g., an advanced driver assistance system (ADAS) camera), an ultrasonic sensor, a radar system, and / or a lidar system.

[0036] One or more vehicle buses 108 may include various communication methods available between vehicle controllers 104 and between TCU 110 and vehicle controllers 104. As some non-limiting examples, vehicle bus 108 may include one or more of a vehicle controller local area network (CAN), an Ethernet network, and a media-oriented system transport (MOST) network.

[0037] TCU 110 may include network hardware configured to facilitate communication between vehicle controllers 104 and with other devices within system 100. For example, TCU 110 may include or otherwise access a modem 112 configured to facilitate communication over communication network 114. TCU 110 may be configured accordingly to communicate via various protocols, such as network protocols (e.g., Uu) with communication network 114. Additionally, TCU 110 may be configured to communicate via broadcast peer-to-peer protocols (e.g., PC5) to facilitate cellular vehicle-to-everything (C-V2X) communication with devices such as other vehicles 102. It should be noted that these protocols are merely examples, and different peer-to-peer and / or cellular technologies may be used.

[0038] TCU 110 may include various types of computing devices that support the execution of the functions of TCU 110 described herein. In one example, TCU 110 may include one or more processors 116 configured to execute computer instructions, and a storage medium 118 on which computer-executable instructions and / or data may be held. The computer-readable storage medium (also referred to as processor-readable medium or storage device 118) includes any non-transitory (e.g., tangible) medium involved in providing data (e.g., instructions) that can be read by a computer (e.g., by processor 116). Typically, processor 116 receives instructions and / or data, such as from storage device 118, into memory and uses the data to execute the instructions, thereby performing one or more processes, including one or more of the processes described herein. Computer-executable instructions may be compiled or interpreted from computer programs created using a variety of programming languages ​​and / or techniques, individually or in combination, including but not limited to: Java, C, C++, C#, Fortran, Pascal, Visual Basic, Python, JavaScript, Perl, etc.

[0039] TCU 110 can be configured to include one or more interfaces from which vehicle 102 information can be sent and received. This information can be sensed, recorded, and sent to one or more cloud servers 120. In one example, similar to TCU 110, cloud server 120 may also include one or more processors (not shown) configured to execute computer instructions, and storage media (not shown) on which computer-executable instructions and / or data can be maintained.

[0040] TCU 110 can be configured to facilitate the collection of vehicle signals 122 from vehicle controllers 104 connected to one or more vehicle buses 108. These may include, for example, ADAS signals generated by ADAS functions of vehicle 102. Although only a single vehicle bus 108 is shown, it should be noted that in many examples, multiple vehicle buses 108 are included, where typically a subset of controllers 104 are connected to each vehicle bus 108. Therefore, to access a given controller 104, TCU 110 can be configured to maintain a mapping of which vehicle buses 108 are connected to which controllers 104, and access the corresponding vehicle bus 108 for that particular controller 104 when communication with a controller 104 is desired.

[0041] As used herein, vehicle signal 122 (e.g., ADAS signal, etc.) may refer to various binary, multi-state, integer, floating-point, and / or continuous parameters that may be generated or otherwise produced by vehicle controller 104 and / or sensor 106. Signal 122 may include different unit types such as time-series data with different frequencies and event streams, and / or different object types such as floating-point, array, matrix, nested data types, etc. As some non-limiting examples, vehicle signal 122 may include one or more of the following: latitude, longitude, time, heading angle, speed, throttle position, braking state, steering angle, headlight state, wiper state, outside temperature, turn signal state, ambient temperature or other weather conditions, alert state, hands off steering wheel state, all-wheel drive (AWD) engagement state, forward object detection state, side object detection state, rear object detection state, etc.

[0042] The signals 122 present on vehicle 102 can vary based on the software and hardware versions of the controller 104 and / or sensor 106 of vehicle 102. Furthermore, different users of vehicle 102 may have different preferences regarding which signals 122 are shared with cloud server 120. Therefore, vehicle 102 can receive and maintain differential settings 125 including parameters such as privacy budgets, noise addition mechanisms, and data aggregation techniques to ensure that individual data points in signal 122 remain confidential and / or otherwise reflect user preferences. A unique set of differential settings 125 can be assigned to each vehicle 102 registered in the data collection program of cloud server 120 (e.g., according to VIN) based on user preferences and privacy requirements.

[0043] A simple approach could be to simply remove the specific input signal 122 associated with the personally identifiable information (PII) data from the data collection. However, this approach may provide limited data to perform the prediction of the metric 134. To better account for the differential setup 125, the TCU 110 and the cloud server 120 can coexist using an autoencoder architecture.

[0044] An autoencoder is a neural network designed to learn an efficient compressed representation of input data in an unsupervised manner. For example, an autoencoder can be trained to capture the most important features of signal 122 in a way that allows for accurate reconstruction of signal 122 from the compressed representation. This can be used for various purposes, such as denoising, privacy enhancement, sparse data reconstruction, data space transformation (specific to general), etc. For this purpose, an autoencoder includes two main components: an encoder 124 and a decoder 126. It should be noted that this is only an exemplary embodiment, but other embodiments are possible. As some other possibilities, variations of the autoencoder, such as variational, adversarial, denoising, stacked, conditional, and / or multimodal neural networks, can be used. In other examples, other architectures, such as transformer networks, statistical machine translation, or even recurrent neural networks (RNNs) with attention mechanisms, can be used.

[0045] Figure 2 illustrates an exemplary auto encoder architecture 200 for use in system 100. As shown in Figure 2, and continuing to refer to Figure 1, signal 122 is received as input to the auto encoder architecture 200. Signal 122 can be processed by filter 202 using user differential settings 125 to generate a filtered signal 206, which can then be applied to encoder 124. Encoder 124 can be mounted to vehicle 102 and can convert the representation of filtered signal 206 into a sparse signal 128. Sparse signal 128 can be transmitted from vehicle 102 to cloud server 120. If needed, sparse signal 128 can be converted into a settings-saving signal 130 by decoder 126 corresponding to encoder 124. Sparse signal 128 can also be processed by one or more analysis models 132 on cloud server 120 to generate metric 134.

[0046] Filter 202 can be configured to remove information from signals 122 according to the needs of the user of vehicle 102. In one example, a user may choose to allow all signals 122 of vehicle 102 to be processed by cloud server 120. In another example, another user may choose to allow only a subset of signals 122. For example, one user may prefer to allow signals 122 such as steering wheel input, speed, lane, etc., while another user may prefer to avoid some of those signals 122, such as providing speed but not steering wheel input (further details regarding the configuration of differential setting 125 are discussed with reference to Figure 4). It should be noted that in some examples, the receiver of signal 122 can use differential setting 125 to distinguish between signals 122 selected as unavailable and signals 122 that are unavailable due to hardware problems on vehicle 102.

[0047] Filter 202 can also be configured to add noise to signal 122 as another method for maintaining user privacy. For example, noise can be introduced by adding or simply reducing the fidelity and / or frequency of signal 122 associated with the user using Gaussian noise, Laplace noise, etc. This can be used for various signals, such as position, velocity, etc.

[0048] It should be noted that filter 202 can also perform other filtering operations as a signal level filter (e.g., Kalman filter, particle filter) and / or generate sensor fusion output. One or more of these operations can be optional and user-configurable. These user preferences can be stored in the differential settings 125 of vehicle 102, which can be applied to signal 122 by filter 202 to generate filtered signal 206.

[0049] Encoder 124 is a neural network that receives filtered signals 206 and compresses them into smaller, lower-dimensional representations called the latent space. This latent space captures the essential features of the filtered signals 206 while discarding less important information, thus allowing for a more compact representation. The output of encoder 124 is referred to herein as sparse signal 128.

[0050] Decoder 126 is another neural network that obtains the latent representation (e.g., sparse signal 128) from encoder 124 and attempts to reconstruct the original signal 122 from the sparse signal 128. Decoder 126 reverses the encoding process, thereby expanding the compressed latent space back to the dimensions of the original data.

[0051] A training process can be performed on the autoencoder to minimize the difference between the raw signal 122 input to encoder 124 and the set-preserved signal 130 output from decoder 126. This can be achieved using a loss function (such as mean squared error) or another suitable function (such as a domain-specific loss function). Thus, the autoencoder can learn to compress the data into a smaller form that can later be reconstructed with minimal information loss. Furthermore, the autoencoder can also perform denoising of signal 122 to address potentially corrupted data by learning to reconstruct a clean version of the data from its noisy version. Monitoring the loss metric of the denoised autoencoder can also be used during training or potentially on a vehicle as a robustness check of the autoencoder's translation. Additionally, the potential output of encoder 124 or decoder 126 can be used for the purposes of metric 134 computation.

[0052] Referring back to Figure 1, the analysis model 132 can be any of various machine learning models trained to determine metric 134 based on signal 122 (here, sparse signal 128). In one example, the analysis model 132 can be configured to infer metric 134 related to vehicle 102 based on training the analysis model 132 with known results from sparse signal 128 from vehicle 102. In one example, the analysis model 132 can be trained on maintenance data of vehicle 102 based on sparse signal 128 data to allow the analysis model 132 to determine metric 134 regarding possible maintenance required for vehicle 102. In another example, the analysis model 132 can be trained on insurance data of vehicle 102 based on sparse signal 128 data to allow the analysis model 132 to determine metric 134 regarding possible accidents that may occur due to how vehicle 102 is driven.

[0053] System 100 may also include one or more measurement servers 140, which are configured to access cloud server 120 via communication network 114. Using the vehicle data service 136 of cloud server 120, the one or more measurement servers 140 may be configured to perform client queries 142 on measurements 134 to obtain various information, such as to prepare insurance quotes for vehicle 102 and / or to schedule maintenance for vehicle 102.

[0054] Figure 3 illustrates an exemplary data flow 300 of the operation of system 100. As shown, HMI 302 provides the user with the ability to interact with and configure differential settings 125. Through this interface, the user can input settings 304 to update their privacy preferences, thereby configuring the number and types of signals 122 that system 100 can share and process. With these differential settings 125 input, vehicle 102 can utilize its sensors 106 to use presence detection 306 to detect the presence of a user in or around vehicle 102, thereby ensuring that the applied differential settings 125 correspond to the user. Any changes made by system 100 to signals 122 are transmitted to HMI 302, thereby ensuring that data collection and privacy protection measures are always aligned with the user's differential settings 125 and the available signals 122.

[0055] The user represents an entity that interacts with vehicle 102, such as an individual, driver, owner, fleet manager, etc. This entity can control the differential settings 125 associated with the set of signals 122 from vehicle 102, thereby enabling the user to customize the differential privacy level applied to the signals 122.

[0056] HMI 302 refers to an interface that allows a user to interact with system 100. HMI 302 can be implemented as a dashboard, touchscreen, or any other user interface in vehicle 102. In another example, HMI 302 can be implemented as an application installed on a user's mobile device (such as a smartphone). In yet another example, HMI 302 can be implemented as a web interface (e.g., hosted by cloud server 120) and accessed via a web browser executed by the user's device.

[0057] Regardless of the implementation method, HMI 302 can provide users with an interface in which they can enter settings 304 and / or update their differential settings 125, view the status of system 100, view metrics 134 and / or otherwise adjust and view other features of system 100.

[0058] Differential settings 125 can be provided to vehicle 102 by HMI 302. In a fleet example, differential settings 125 can be sent from HMI 302 to vehicles 102 of the managed fleet via communication network 114. In a user example, differential settings 125 can be sent from HMI 302 to vehicles 102 associated with user accounts configured by HMI 302. Differential settings 125 can be received, for example, using TCU 110 of vehicle 102 and can be maintained to storage device 118 of vehicle 102.

[0059] Vehicle 102 can also be configured to use presence detection 306 to identify which users are present in or near vehicle 102. In one example, presence detection 306 may use one or more sensors 106 of vehicle 102 (such as cameras) to identify the presence of users. In another example, vehicle 102 may use wireless signals from a user's device to identify the presence of a user (such as the use of a user's mobile phone, key device, or key fob).

[0060] The event processing application 138 uses filter 202 to create a filtered signal 206 from signal 122 using the detected user's differential settings 125. These sparse signals 128 are then sent to cloud server 120 via communication network 114 using TCU 110.

[0061] Cloud server 120 utilizes vehicle data service 136 to generate metric 134 using sparse signal 128. In one example, vehicle data service 136 may utilize one or more analysis models 132. For example, insurance analysis model 132 may be used to generate insurance-related metric 134, and / or maintenance analysis model 132 may be used to generate maintenance-related metric 134. Because metric 134 is determined using sparse signal 128 based on filtered signal 206, the fidelity of the input to analysis model 132 is ensured, while also taking into account the differential settings 125 of the detected user.

[0062] In some cases, metric 134 can indicate a change in sparse signal 128. For example, based on identified trends, anomalies, or areas of improvement, vehicle data service 136 can adjust its data collection strategy, focusing on the most relevant sensors 106, signals 122, or conditions to improve future data quality and relevance. If so, these signal updates 308 can be provided to HMI 302 to allow the user to update differential settings 125 for new signals 122.

[0063] Figure 4 illustrates an example 400 of HMI 302 for configuring differential settings 125. In example 400, HMI 302 provides a header 402 indicating how HMI 302 is used to configure differential settings 125. HMI 302 also shows a set of signal controls 404 for a list or set of signals 122 that can be selected or deselected for use by the analysis model 132 of vehicle data service 136.

[0064] For example, signal control 404 may include one or more of the following: signal control 404 for selecting the use of driver identification signal 122, signal control 404 for selecting the use of oil change indicator, signal control 404 for selecting the use of turn signal, signal control 404 for selecting the use of cruise control, signal control 404 for selecting the use of position signal 122 indicating the position of vehicle 102, signal control 404 for selecting the use of semi-autonomous driving signal 122, signal control 404 for selecting the use of pedal use signal 122, signal control 404 for selecting the use of seat belt use signal 122, and / or signal control 404 for selecting the use of driver status monitoring signal 122. It should be noted that these are merely examples, and more, fewer, and different sets or categories of signals 122 may be used with signal control 404.

[0065] In some examples, additional information about the signals 122 that can be selected using signal control 404 can be provided. For example, HMI 302 can provide indications of which signals are considered well-related to the metric 134 of a given analysis model 132. In one example, signals 122 predefined as well-related to the resulting metric 134 generated by analysis model 132 can be provided with indications showing that importance (e.g., next to the selector section of the corresponding signal control 404). It is worth noting that these signals 122 may differ for different analysis models 132. This feature allows users to better measure whether providing this information to vehicle data service 136 is useful to the user.

[0066] As another example, HMI 302 can provide information about the expected privacy effects of allowing the use of certain signals 122. This can be shown in addition to information about which signals 122 are useful to the analysis model 132, allowing the user to balance these two aspects. In some examples, if discounts are offered to the user, such as good driving discounts, the signals 122 that can be used to allow the user to be eligible to receive those discounts can also be shown in HMI 302. For example, icons indicating that discounts may be available can be shown next to the signal control 404 that engages those signals 122.

[0067] Figure 5 illustrates an exemplary process 500 for implementing the use of differential settings 125 in data collection by vehicle 102. In one example, process 500 may be performed by vehicle 102 communicating with cloud server 120 via communication network 114.

[0068] At operation 502, the user and / or vehicle 102 registers with the cloud server 120. In one example, the user may provide the cloud server 120 with his or her biometrics, telephone identifier, or other identifiable information. This information may be used by vehicle 102 (or multiple vehicles 102, if a fleet) to identify the user's presence.

[0069] At operation 504, vehicle 102 receives differential settings 125 to be used to supply filtered signal 206 from vehicle 102 to cloud server 120. In one example, a user can access HMI 302 to input his or her preferences for the collection of signal 122. As shown in Figure 3, vehicle 102's TCU 110 can receive differential settings 125 from HMI 302 via communication network 114. Alternatively, if HMI 302 is provided by vehicle 102 itself, differential settings 125 can be stored in vehicle 102 (and optionally sent to cloud server 120 for storage). Changes to differential settings 125 made from devices other than vehicle 102 can also be synchronized back to vehicle 102 from cloud server 120. Sending signal 122 from vehicle 102 to cloud server 120 may accordingly require the user to opt in to use data collection and analysis model 132. An exemplary HMI 302 is shown in Figure 4. In another example, the updated settings can be received from the cloud server 120 from the vehicle 102, for example, based on changes in the signal 122 expected to be used by the analysis model 132.

[0070] At operation 506, vehicle 102 performs presence detection 306 to detect the presence of a user. In a simple example, presence detection 306 may utilize one or more sensors 106 of vehicle 102 (such as cameras) to identify the presence of the driver. In another example, vehicle 102 may utilize wireless signals from the user's device to identify the presence of the driver (such as the use of the driver's mobile phone, i.e., key device or key fob). Based on the detection of the driver's presence, vehicle 102 may activate differential setting 125 of vehicle 102 to process signals 122 from controller 104 and / or sensors 106 of vehicle 102.

[0071] In another example, presence detection 306 can utilize one or more sensors 106 of vehicle 102 (such as cameras or key fobs) to identify the presence of a specific user. In another example, vehicle 102 can utilize wireless signals from a user's device to identify the user's presence (such as the use of a specific user's mobile phone, i.e., key device or key fob). Based on the detection of a user, vehicle 102 can activate the user's differential setting 125 for processing signals 122 from the controller 104 and / or sensors 106 of vehicle 102.

[0072] At operation 508, vehicle 102 transforms signal 122 into a sparse signal 128 according to differential setting 125. For example, signal 122 is collected from various sensors 106 and controllers 104 of vehicle 102, including cameras, light detection and ranging (LIDAR), radio detection and ranging (RADAR), and other relevant inputs. Other relevant inputs may also include processed signals such as sensor fusion, time before vehicle 102 arrives at a detected object, etc. This data is rich in information about the environment, performance, and driver behavior of vehicle 102, thus laying the foundation for subsequent operations. While signal 122 is being collected, it can be normalized to ensure consistency and reliability across different sensor types and software versions, making it ready for further processing. Once captured, signal 122 is processed by filter 202 according to differential setting 125 to provide only the information expected by the user. In some examples, filter 202 may additionally add noise to signal 122 to increase the privacy of data collection. In one example, the filtered signal 206 can then be provided to the encoder 124 of the autoencoder architecture 200 to produce a sparse signal 128. An exemplary method for filtering signal 122 and transforming it into a sparse signal 128 is illustrated in detail in Figure 2. In another example, encoding the filtered signal 206 into a sparse signal 128 includes performing principal component analysis to reduce the dimensionality of the filtered signal 206 by finding a subset of orthogonal components that capture the variance in the filtered signal 206.

[0073] At operation 510, vehicle 102 sends sparse signal 128 to cloud server 120. In one example, as shown in Figure 3, vehicle 102's TCU 110 can send sparse signal 128 to cloud server 120 via communication network 114. After operation 510, control proceeds to operation 504 to determine if updated differential settings 125 are available.

[0074] Figure 6 illustrates an exemplary process 600 for analyzing sparse signal 128 by cloud server 120. In one example, process 600 may be performed by cloud server 120 communicating with vehicle 102 via communication network 114.

[0075] At operation 602, cloud server 120 receives sparse signal 128. For example, sparse signal 128 can be received when sending at operation 510.

[0076] At operation 604, cloud server 120 uses one or more analytics models 132 to process sparse signal 128. For example, sparse signal 128 generated by an autoencoder is used to generate metric 134 through analytics model 132. Analytics model 132 can interpret the characteristics of sparse signal 128 to generate insights into vehicle wear, driver behavior, and / or other applications. By using sparse signal 128 generated based on differential settings 125, system 100 ensures user privacy while also keeping metric 134 consistent and comparable. Furthermore, in doing so, analytics model 132 may not need to be retrained for each different privacy setting of signal 122. Additionally, in some implementations, analytics model 132 may be aware of differential settings 125 in order to know which signals 122 are masked.

[0077] At operation 606, cloud server 120 sends metric 134 to metric server 140. In one example, one or more metric servers 140 may be configured to perform client query 142 on metric 134 to obtain various information, such as to prepare an insurance quote for vehicle 102 and / or to schedule maintenance for vehicle 102.

[0078] At operation 608, cloud server 120 determines whether to update signal 122. For example, based on trends, anomalies, or changes in the data distribution of the collected signal 122, cloud server 120 may adjust its data collection strategy. This may include, for example, updating sparse signal 128 that will be received for use by analysis model 132. This updating approach enhances future cycles of data collection, resulting in more accurate and reliable analysis of signal 122.

[0079] As an example, cloud server 120 can determine that one or more sparse signals 128 are irrelevant to the computation of results from one or more analysis models 132 being used by the user. In one example, this can be achieved by providing sparse signals 128 to analysis model 132 using a leave-one-out strategy and identifying the results in metric 134. If metric 134 is the same with or without the sparse signals 128 omitted from the input, the omitted sparse signals 128 are likely less relevant. However, if metric 134 is different, those sparse signals 128 are likely more relevant. Based on this analysis, cloud server 120 can recommend less relevant signals 122 and can suggest removing those signals 122 from signal control 404.

[0080] Based on this same analysis, cloud server 120 can suggest using certain sparse signals 128 that are not sent to some users to improve the accuracy of metric 134. In this case, cloud server 120 can recommend that users add certain sparse signals 128 that are currently disabled in HMI 302.

[0081] At operation 610, cloud server 120 updates HMI 302. For example, the recommendations determined at operation 608 can be provided to HMI 302 as signal update 308. Additionally, a message can be sent to the user (e.g., as an email sent to the user's mobile device, sent to vehicle 102 to be displayed to the user, etc.) to notify the user that a potential update to differential settings 125 should be considered.

[0082] At operation 612, cloud server 120 updates differential settings 125 of vehicle 102. For example, a user can use HMI 302 to update differential settings 125, as discussed above regarding operation 504. These updated differential settings 125 can be received by cloud server 120. After operation 612, process 600 returns to operation 602.

[0083] Variations of the process are possible. For example, dimensionality reduction and feature engineering techniques (such as manifold learning) can use features that are less of an interest to engineers to produce varying latent dimensions. In some examples, the disclosed methods can be used to provide feature engineering and dimensionality reduction in a repeatable manner.

[0084] In another example, differential setting 125 can be used for data collection in other scenarios. As one possibility, data collection can be performed on ADAS event data. This event data can be analyzed to improve ADAS performance, such as for edge cases where little data is available. In this case, the user can allow data collection as long as some signals are masked (e.g., not focusing on road signals but allowing collection of other signals). This approach allows for fine-tuning of privacy policies for vehicle 102 data collection, rather than a binary all-or-nothing approach.

[0085] Figure 7 illustrates an exemplary computing device 702 for determining vehicle metrics 134 using sparse signal 128. Referring to Figure 7 and Figures 1 through 6, vehicle 102, controller 104, sensor 106, TCU 110, and cloud server 120 can be examples of such computing device 702. The computing device 702 typically includes computer-executable instructions, such as instructions for vehicle data services 136 and event processing applications 138, which can be executed by one or more computing devices 702. The computer-executable instructions can be compiled or interpreted according to computer programs created using various programming languages ​​and / or techniques, individually or in combination including but not limited to Java™, C, C++, C#, Visual Basic, JavaScript, Python, Perl, etc. Generally, a processor (e.g., a microprocessor) receives instructions, for example, from memory, a computer-readable medium, etc., and executes these instructions to perform one or more processes, including one or more of the processes described herein. Such instructions and other data (such as signal 122, encoder 124, differential settings 125, decoder 126, sparse signal 128, setting save signal 130, analysis model 132, metric 134, etc.) can be stored and transmitted using various computer-readable media.

[0086] As shown in the figure, computing device 702 may include processor 704, which is operatively connected to storage device 706, network device 708, output device 710, and input device 712. It should be noted that this is merely an example, and computing device 702 with more, fewer, or different components may be used.

[0087] Processor 704 may include one or more integrated circuits that implement the functionality of a central processing unit (CPU) and / or a graphics processing unit (GPU). In some examples, processor 704 is a system-on-a-chip (SoC) that integrates the functionality of a CPU and a GPU. The SoC may optionally include other components, such as, for example, a storage device 706 and a network device 708, into a single integrated device. In other examples, the CPU and GPU are connected to each other via peripheral connectivity devices, such as Peripheral Component Interconnect (PCI) or another suitable peripheral data connection. In one example, the CPU is a commercially available central processing unit that implements an instruction set, such as one of the x86, ARM, Power, or MIPS microprocessor instruction set families without interlocking pipelines.

[0088] Regardless of the details, during operation, processor 704 executes stored program instructions retrieved from storage device 706. The stored program instructions accordingly include software that controls the operation of processor 704 to perform the operations described herein. Storage device 706 may include both non-volatile memory devices and volatile memory devices. Non-volatile memory includes solid-state memory, such as NAND flash memory, magnetic and optical storage media, or any other suitable data storage device that retains data when the system is disabled or loses power. Volatile memory includes static and dynamic random access memory (RAM) that stores program instructions and data during operation of system 100.

[0089] The GPU may include hardware and software for displaying at least two-dimensional (2D) and optionally three-dimensional (3D) graphics to the output device 710. The output device 710 may include a graphics or visual display device, such as an electronic display screen, projector, printer, or any other suitable device for reproducing a graphic display. As another example, the output device 710 may include an audio device, such as a speaker or headphones. As yet another example, the output device 710 may include a tactile device, such as a mechanically elevable device, which in one example may be configured to display Braille or another physical output element that can be touched to provide information to a user.

[0090] The input device 712 may include any of a variety of devices that enable the computing device 702 to receive control input from a user. Examples of suitable input devices 712 for receiving human-machine interface input may include a keyboard, mouse, trackball, touch screen, microphone, graphics tablet, etc.

[0091] Network device 708 may each include any of a variety of means that enable the described components to send and / or receive data from external devices via a network. Examples of suitable network devices 708 include an Ethernet interface, a Wi-Fi transceiver, a cellular transceiver, or a Bluetooth or Bluetooth Low Energy (BLE) transceiver, or other network adapters or peripheral interconnects that may be useful for receiving large datasets in an efficient manner.

[0092] Regarding the processes, systems, methods, heuristics, etc., described herein, it should be understood that although the steps of such processes, etc., are described as occurring according to an ordered sequence, such processes can be practiced using the described steps performed in a different order than that described herein. It should also be understood that some steps may be performed simultaneously, other steps may be added, or some steps described herein may be omitted. In other words, the description of processes herein is provided for the purpose of illustrating specific embodiments and should in no way be construed as limiting the claims.

[0093] Therefore, it should be understood that the above description is intended to be illustrative rather than restrictive. Many embodiments and applications beyond the examples provided will become apparent upon reading the above description. The scope should not be determined by reference to the above description, but rather by reference to the appended claims and the full scope of their equivalents. Future developments in the techniques discussed herein are anticipated and expected, and the disclosed systems and methods will be incorporated into such future embodiments. In conclusion, it should be understood that modifications and changes are possible with this application.

[0094] All terms used in the claims are intended to give their broadest reasonable structure and their general meaning as would be understood by one of skill in the art described herein, unless explicitly indicated otherwise herein. Specifically, unless the claims explicitly limit the recitation to the contrary, the use of singular articles such as “a,” “the,” or “the” should be interpreted as referring to one or more of the elements indicated by the recitation.

[0095] An abstract of this disclosure is provided to allow the reader to quickly determine the nature of this technical disclosure. It should be understood that the abstract is not intended to interpret or limit the scope or meaning of the claims. Furthermore, as can be seen in the foregoing detailed description, various features are grouped together in various embodiments for the purpose of making the disclosure fluent. This approach of the disclosure should not be construed as reflecting an intention to require more features than expressly stated in each claim. Rather, as reflected in the appended claims, the inventive subject matter lies in fewer than all features of a single disclosed embodiment. Therefore, the appended claims are hereby incorporated into the detailed description, wherein each claim is itself a separately claimed subject matter.

[0096] Although exemplary embodiments have been described above, these embodiments are not intended to describe all possible forms of this disclosure. Rather, the terminology used herein is descriptive rather than restrictive, and it should be understood that various changes may be made without departing from the spirit and scope of this disclosure. Furthermore, features of various embodiments may be combined to form other embodiments of this disclosure.

[0097] According to the present invention, a method for collecting and processing vehicle data with differential privacy includes: receiving by a controller of a vehicle a set of differential privacy settings corresponding to a user of the vehicle, the differential privacy settings defining which groups of one or more vehicle signals to be sent to a cloud server; capturing by the controller multiple vehicle signals from multiple controllers and / or sensors of the vehicle; applying a filter to the vehicle signals by the controller according to the differential privacy settings to generate a filtered signal; encoding the filtered signal into a sparse signal; and transmitting the sparse signal from the vehicle to the cloud server for processing by an analysis model to determine a metric of the vehicle according to the user's differential privacy settings.

[0098] In one aspect of the invention, the encoding of the filtered signal to the sparse signal includes using a latent space model comprising an encoder and a decoder, such that the encoding of the filtered signal to the sparse signal is performed using an encoder, such as that mounted on the vehicle.

[0099] In one aspect of the invention, encoding the filtered signal into the sparse signal includes performing principal component analysis to reduce the dimensionality of the filtered signal by finding a subset of orthogonal components that capture the variance in the filtered signal.

[0100] In one aspect of the invention, the method includes: using the vehicle's sensors to detect the presence of the user; and filtering the vehicle signal according to the differential privacy setting corresponding to the user whose presence was detected.

[0101] In one aspect of the invention, the differential privacy setting includes a noise addition parameter, and the filter adds noise to the vehicle signal before encoding to enhance user privacy.

[0102] In one aspect of the invention, the noise added by the filter is Gaussian noise, Laplace noise, or a reduction in the fidelity of the vehicle signal, and the amount of the noise can be adjusted based on the differential privacy setting.

[0103] In one aspect of the invention, the method includes: displaying a set of user-selectable signal controls on a human-machine interface (HMI), each control corresponding to a different group of the one or more vehicle signals; and updating the differential privacy settings based on selections received from the user regarding which groups of the one or more vehicle signals to share with the cloud server.

[0104] In one aspect of the invention, the method includes providing on the HMI an indication of which groups of the one or more vehicle signals are associated with the metric generated by the analysis model, to help the user select the one or more vehicle signals to share.

[0105] In one aspect of the invention, the method includes: receiving a message indicating a request to update user-selectable signal controls for the group, based on an analysis by the cloud server of the contribution of one or more vehicle signals of the group to the metric.

[0106] In one aspect of the invention, the analytical model determines metrics related to vehicle maintenance.

[0107] In one aspect of the invention, the analytical model determines a metric regarding insurance based on usage.

[0108] According to the present invention, a system for determining vehicle metrics using general signals is provided, comprising: one or more computing devices of a cloud server, the one or more computing devices including non-transitory storage and a processor, the one or more computing devices being configured to: receive sparse signals from a plurality of vehicles corresponding to vehicle data captured by sensors and / or controllers of the vehicles, the sparse signals being filtered according to a differential privacy setting, the differential privacy setting defining which groups of one or more vehicle signals to be sent to the cloud server; have the cloud server apply an analysis model to the sparse signals to generate vehicle metrics; analyze the vehicle metrics to obtain the contribution of the group of one or more vehicle signals to the metrics; and send a message updating the group of one or more vehicle signals to the vehicles based on the cloud server's analysis of the contribution of the group of one or more vehicle signals to the metrics.

[0109] According to an embodiment, one or more computing devices are further configured to transmit generated vehicle metrics to a metrics server in response to a client query for access by an insurance provider or vehicle service entity.

[0110] According to an embodiment, the one or more computing devices are further configured to: provide a set of user-selectable signal controls on the HMI, each control corresponding to a different group of the one or more vehicle signals; and update the user's differential privacy settings based on the user's selection of which groups of the one or more vehicle signals to share with the cloud server.

[0111] According to an embodiment, the one or more computing devices are further configured to provide on the HMI an indication of which groups of the one or more vehicle signals are associated with the metric generated by the analysis model, to help the user select the one or more vehicle signals to share.

[0112] According to an embodiment, the sparse signal is encoded by an encoder using a latent space model that includes the encoder and a decoder, and the one or more computing devices are further configured to apply the sparse signal to the analysis model without using the decoder to decode the sparse signal.

[0113] According to an embodiment, the sparse signal is encoded by performing principal component analysis to reduce the dimensionality of the vehicle data by finding a subset of orthogonal components that capture the variance in the vehicle data.

[0114] According to the present invention, a vehicle for collecting and processing vehicle data with differential privacy is provided, comprising: one or more sensors and / or controllers; and a processing controller communicating with the one or more sensors and / or controllers, the processing controller being configured to: receive a set of differential privacy settings corresponding to a user of the vehicle, the differential privacy settings defining which sets of one or more vehicle signals to be sent to a cloud server; capture multiple vehicle signals from the one or more sensors and / or controllers; use the one or more sensors and / or controllers to detect the presence of a user; apply a filter to the vehicle signals to generate a filtered signal according to the differential privacy settings corresponding to the user whose presence is detected; encode the filtered signal into a sparse signal by an encoder, such as one mounted on the vehicle, using a latent spatial model including the encoder and decoder; and transmit the sparse signal from the vehicle to the cloud server for processing by an analysis model to determine a metric of the vehicle according to the differential privacy settings of the user.

[0115] According to an embodiment, the differential privacy setting includes a noise addition parameter, and the filter adds noise to the vehicle signal before encoding to enhance user privacy.

[0116] According to an embodiment, the noise added by the filter is Gaussian noise, Laplace noise, or a reduction in the fidelity of the vehicle signal, and the amount of noise can be adjusted based on the differential privacy settings.

[0117] According to an embodiment, the processing controller is further configured to: display a set of user-selectable signal controls on the HMI, each control corresponding to a different group of the one or more vehicle signals; and update the differential privacy settings based on the user's selection of which groups of the one or more vehicle signals to share with the cloud server.

[0118] According to an embodiment, the processing controller is also configured to provide on the HMI an indication of which groups of the one or more vehicle signals are associated with the metric generated by the analysis model, to help the user select the one or more vehicle signals to share.

[0119] According to an embodiment, the processing controller is further configured to receive a message indicating a request to update the user-selectable signal controls for the group, based on the cloud server's analysis of the contribution of the one or more vehicle signals of the group to the metric.

Claims

1. A method for collecting and processing vehicle data with differential privacy, comprising: The vehicle's controller receives a set of differential privacy settings corresponding to the user of the vehicle, the differential privacy settings defining which groups of one or more vehicle signals to send to the cloud server; The controller captures multiple vehicle signals from multiple controllers and / or sensors of the vehicle; the controller applies a filter to the vehicle signals according to the differential privacy setting to generate a filtered signal; The filtered signal is encoded into a sparse signal; The sparse signal is transmitted from the vehicle to the cloud server for analysis model processing to determine the vehicle's metric based on the user's differential privacy settings.

2. The method of claim 1, wherein the encoding of the filtered signal to the sparse signal comprises using a latent space model including an encoder and a decoder, such that the encoding of the filtered signal to the sparse signal is performed using the encoder, as mounted on the vehicle.

3. The method of claim 1, wherein encoding the filtered signal into the sparse signal includes performing principal component analysis to reduce the dimensionality of the filtered signal by finding a subset of orthogonal components that capture the variance in the filtered signal.

4. The method of claim 1, further comprising: The presence of the user is detected using the vehicle's sensors; And the vehicle signal is filtered according to the differential privacy setting corresponding to the user whose presence is detected.

5. The method of claim 1, wherein the differential privacy setting includes a noise addition parameter, and the filter adds noise to the vehicle signal before encoding to enhance user privacy.

6. The method of claim 5, wherein the noise added by the filter is Gaussian noise, Laplace noise, or a reduction in the fidelity of the vehicle signal, and the amount of noise can be adjusted based on the differential privacy setting.

7. The method of claim 1, further comprising: A set of user-selectable signal controls is displayed on the human-machine interface (HMI), each control corresponding to one or more vehicle signals from a different group; And update the differential privacy settings based on the user's selection of which groups of vehicle signals to share with the cloud server.

8. The method of claim 7, further comprising providing on the HMI an indication of which groups of the one or more vehicle signals are associated with the metric generated by the analysis model, to assist the user in selecting the one or more vehicle signals to share.

9. The method of claim 7, further comprising: The cloud server receives a message instructing the user to update the selectable signal controls for the group based on its analysis of the contribution of one or more vehicle signals of the group to the metric.

10. The method of claim 1, wherein the analytical model determines the metric regarding vehicle maintenance.

11. The method of claim 1, wherein the analytical model determines the metric regarding insurance usage.

12. A system for determining vehicle measurements using a common signal, comprising: One or more computing devices of a cloud server, the one or more computing devices including a non-transitory storage device and a processor, the one or more computing devices being configured to: receive sparse signals from a plurality of vehicles corresponding to vehicle data captured by sensors and / or controllers of the vehicles, the sparse signals being filtered according to a differential privacy setting, the differential privacy setting defining which groups of one or more vehicle signals to be sent to the cloud server; The cloud server applies the analysis model to the sparse signal to generate vehicle metrics; the vehicle metrics are analyzed to obtain the contribution of one or more vehicle signals from the group to the metrics; And based on the cloud server's analysis of the contribution of the one or more vehicle signals of the group to the metric, send a message to the vehicle updating the one or more vehicle signals of the group.

13. The system of claim 12, wherein the one or more computing devices are further configured to transmit generated vehicle metrics to a metrics server in response to a client query for access by an insurance provider or vehicle service entity.

14. The system of claim 12, wherein the one or more computing devices are further configured to: provide on an HMI a set of user-selectable signal controls, each control corresponding to a different group of the one or more vehicle signals; update the user's differential privacy settings based on a selection received from the user of which groups of the one or more vehicle signals to share with the cloud server; and provide on the HMI an indication of which groups of the one or more vehicle signals are associated with the metric generated by the analysis model to assist the user in selecting which groups of the one or more vehicle signals to share.

15. The system of claim 12, wherein one or more of the following are used: the sparse signal is encoded by an encoder using a latent space model including the encoder and a decoder, and the one or more computing devices are further configured to apply the sparse signal to the analysis model without using the decoder to decode the sparse signal; and the sparse signal is encoded by performing principal component analysis to reduce the dimensionality of the vehicle data by finding a subset of orthogonal components that capture the variance in the vehicle data.

Images