Split Sensing OBD Cap and Smartphone Data Fusion
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current insurance data collection systems require expensive devices and recurring cellular data transport costs, making them cost-prohibitive for insurance companies, and fail to accurately assess driver behavior, which affects premium accuracy.
Innovation Solution
The 'Split Sensing' system uses an On-Board Diagnostics (OBD) device to record data and transmit it to a client computing device, which then combines and transmits the data to a backend server, reducing hardware and cellular costs, and enhances data accuracy by incorporating additional data from the client device, allowing for more precise driver behavior tracking and fraud detection.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If expensive OBD devices with cellular capabilities are used for data collection, then data collection capability is improved, but hardware cost and cellular data transport cost increase significantly
Solution Approach 1:
The system divides the data collection function into two segments: a simple OBD cap that collects vehicle data and a client computing device (smartphone) that collects user behavior data. This segmentation allows each component to be simpler and cheaper while maintaining overall system capability.
Solution Approach 2:
The client computing device serves multiple functions: it acts as a data collection point for OBD data, collects additional sensor data from the vehicle interior, stores data locally, and transmits combined data to the server. This multi-functionality eliminates the need for expensive dedicated hardware with cellular capabilities.
2Reliability
If OBD cap transmits data directly to backend server via cellular network, then data transmission is reliable, but recurring cellular data transport costs increase
Solution Approach 1:
The client computing device acts as an intermediary between the OBD cap and the backend server. It receives OBD data, combines it with locally collected data, and transmits the combined dataset to the server, eliminating the need for the OBD cap to have cellular capabilities.
Solution Approach 2:
The system creates a local copy of the data collection and transmission functionality in the client computing device. The phone stores OBD data and sensor data locally before transmission, copying the essential functions of a dedicated telematics device while using existing consumer hardware.
3Quantity of substance
If only OBD cap data is collected, then hardware expense is reduced, but data accuracy for driver behavior assessment decreases
Solution Approach 1:
The system merges two data sources: OBD cap data (vehicle metrics) and client device sensor data (interior acoustic, light, temperature sensors). This combination provides a more complete picture of driver behavior and vehicle conditions, improving assessment accuracy while keeping hardware costs low.
Solution Approach 2:
The client computing device serves as an intermediary that enriches the OBD data with additional contextual information from interior sensors. This mediation process combines complementary data types to achieve better measurement precision without adding expensive hardware to the OBD cap itself.
Data Source
AI summary
Client side and server side methods for combining data originating from an On Board Diagnostics (OBD) cap with data originating from a client computing device are presented. The method includes receiving, from a client computing device via a computer network, a plurality of OBD cap data originating from an OBD cap and receiving, from the client computing device via the computer network, a plurality of client computing device data originating from the client computing device. The method also includes selecting, at a processor, a first data parameter from the plurality of OBD cap data and selecting, at the processor, a second data parameter from the plurality of client computing device data. The method further includes analyzing, at the processor, the first data parameter and the second data parameter and flagging, at the processor, an insurance account associated with the OBD device as a result of the analysis.