10/1/2011 Telematics Discussion Day in the life of a hard braking - PDF document

10/1/2011 Telematics Discussion Day in the life of a hard braking incident Electronics of Usage Based Insurance 10 04 2011 Bob Mathe President and COO, Evogi Telematics Discussion Day in the life of a hard braking incident Quoting – Getting Devices in Cars Topography Ins Co I C RQI • 1996 or newer • Special issues, i.e., hybrids • 9 different OBDII protocols Compatibility VIN • data element support, e.g., VIN verify 85 – 90% • Device compatibility with product • real-time support, e.g., teen tracking • swerving and cornering , e.g., BBI Telematics Platform Devices 10/1/2011 2 1

10/1/2011 Telematics Discussion Day in the life of a hard braking incident Risk Evaluation and Discount – Using the Results Topography Discount calculation Ins Co Ins Co RQI Claims and Restatement individual data VIN Vehicle score of price Scoring Customer Equation Process Performance Performance Actuarial Telematics feedback Process Platform Historical data Devices 10/1/2011 3 Telematics Discussion Day in the life of a hard braking incident Telematics Platform Aggregation & Collection Consumption normalization R l Rules Policyholder Device 1 Gateway Rules Transactions Device 2 Actuary Rules Raw data BI analytics Gateway Rules Device 3 Product Manager Manager Business Objectives Process Objectives • Operational reports: QOS, functioning, etc. • Stable: without frequent failure • Product segment and pricing analysis • Reliable: same result with same event • DOI filing support • Flexible • Policyholder alerts and reports • Useful: right data • Right cost: affordable 2

10/1/2011 Telematics Discussion Day in the life of a hard braking incident Telematics Platform – Area for Discussion Collection Rules Policyholder Device 1 Gateway Rules Transactions Device 2 Actuary Rules Raw data BI analytics Gateway Rules Device 3 Product Manager 10/1/2011 5 Telematics Discussion Day in the life of a hard braking incident How do you recognize a hard brake? a. Source: GPS speed sampled at 10 Hz S GPS d l d t 10 H Device 1 b. Source: OBDII speed sampled at 1 Hz One or more event triggers Accelerometer sampled at 200 Hz on device (equation running on the device; velocity Device 2 vector needs to be normalized) Raw data transferred from GPS Granular /OBD/Accelerometer to gateway and Device 3 braking data rules engine decides 10/1/2011 6 3

10/1/2011 Telematics Discussion Day in the life of a hard braking incident What is a hard brake? Calculated change Measured Probable in speed force event - 88 mph per second 4g likely accident - 11 mph per second .5g very hard brake - 7 mph per second .32g hard brake 70 – 63 mph in 1 second is a hard brake 10/1/2011 7 Telematics Discussion Day in the life of a hard braking incident Summary - Key Issues Description of Activity Rules Inputs and outputs Device 1 Device differences Gateway Install orientation Acceleration equation (X, Y, Z axis) Device 2 Braking example Gateway Key Concepts Device 3 Acceleration and force Sampling versus transmission Accelerometer Accelerometer Threshold (events under threshold not recorded) Car protocols Device Car matchup TCP/IP v UDP transmission and timing 10/1/2011 8 4

10/1/2011 Telematics Discussion Day in the life of a hard braking incident Telematics Platform – Area for Discussion Aggregation & normalization Rules Policyholder Device 1 Gateway Rules Device 2 Transactions Actuary Rules Raw data BI analytics Device 3 Rules Gateway Product Manager 10/1/2011 9 Telematics Discussion Day in the life of a hard braking incident Does the quality of my braking data vary? HDOP HDOP .7 excellent 7 excellent a. Source: GPS S GPS 8 flag as suspect Device 1 b. Source: OBDII 20 discard Velocity vector accuracy: Accelerometer Device 2 + 5% for 90% of vehicles + 20% for remaining Both above Raw data transfer Device 3 Also for all …device self check 10/1/2011 10 5

10/1/2011 Telematics Discussion Day in the life of a hard braking incident What are typical process quality measures? • HDOP – horizontal dilution of precision HDOP horizontal dilution of precision • Signal strength - number of satellites fixed o Higher the number the greater the quality o Minimal 3 o No upper limit • Device self-check – issues during sampling g p g o High temp, humidity, vibration 10/1/2011 11 Telematics Discussion Day in the life of a hard braking incident Summary - Key Issues Rules Device 1 Gateway Rules Device 2 Rules Rules Device 3 Gateway Description of Activity Inputs and outputs Inputs and outputs QOS Compensation/normalization among devices Braking example Key Concepts Real-time requirement of data transmission HDOP Rules - aggregation Rules - normalization 10/1/2011 12 6

10/1/2011 Telematics Discussion Day in the life of a hard braking incident Telematics Platform – Area for Discussion Consumption Rules Policyholder Device 1 Rules Gateway Device 2 Transactions Actuary Rules Raw data BI analytics Rules Gateway Device 3 Product Product Manager 10/1/2011 13 Telematics Discussion Day in the life of a hard braking incident What problem are we trying to solve? Customer Alert Simple calculation - threshold exceeded Device 1: GPS or OBDII Stored on device Stored on device Event may or may not be real-time • Real-time versus memory page transactions Complex calculation - threshold exceeded Device 2: Accelerometer Stored on device Device variances create differences in results • Accelerometer vendor • Complex calculation to normalize velocity vector t • Complex calculation to measure event Event may or may not be real-time • Real-time versus memory page transactions Device 3: Raw Data Three options: GPS, OBDII or Accelerometer data Stream of data stored, not real-time Calculation on host 10/1/2011 14 7

10/1/2011 Telematics Discussion Day in the life of a hard braking incident Who needs the data and for what? And, what are the business rules? Number of hard brakes per trip (incidents relative to p p ( BBI product BBI product thresholds) element Example - 5 hard brakes, 2 very hard brakes, 0 possible accidents Extreme hard brake event with time stamp and latitude & Claims FNOL longitude feature S Second-by-second data with hard brake with time stamp d b d d t ith h d b k ith ti t Actuarial analysis and latitude longitude AND added road type, weather, school zone, posted speed limit, actual speed limit for every brake event Device design and rules dictates the type and amount of data collected. A brake event support different needs depending upon set-up. 10/1/2011 15 Telematics Discussion Day in the life of a hard braking incident Summary of Key Issues Description of Activity Policyholder: real time alerts, Policyholder Policyholder driving reports driving reports Actuary: accumulated data Product Manager: business performance, QOS Transactions Actuary Raw data Inputs and outputs BI analytics Device differences Braking example Product Key Concepts Manager Data structure S Sampling versus transmitting li t itti Real-time versus analytical 10/1/2011 16 8

10/1/2011 Telematics Discussion Day in the life of a hard braking incident A simple case… Facts: a vehicle approaches an intersection at 55 mph. on a rainy day. The driver sees crossing vehicle and locks brakes. Car slides 40 feet and hits obstructing car. Is the data used for calculating hard brake correct? Vehicle GPS Braking event identified Speed Distance Vehicle OBDII Wheels locked, speed zero Speed Distance G force Accelerometer Braking event identified Distance 10/1/2011 17 Telematics Discussion Day in the life of a hard braking incident Appendices 10/1/2011 18 9

10/1/2011 Appendix I Example Reports 10/1/2011 19 10/1/2011 20 10

10/1/2011 10/1/2011 21 10/1/2011 22 11