Michael St. Denis, Robert Budd, Revecorp Inc. I/M Solutions May 2015 Virginia Beach, Virginia

 What is a trigger?  Data needed for I/M fraud detection analyses  Data triggers  Real time  Post processing  Methods to focus enforcement  Simulators – Vehicle, catalyst, other Revecorp Inc.

 CA Bureau of Automotive Repair began with collection of data on floppies – which created the desire to get data in real time – which lead to the first VID in CA for the first triggers  Triggers are indication of potential fraud  Would be great to have an enforcement person observe every inspection, but this is impractical  The goal is to help focus limited enforcement resources  What them to be automated and indicate areas needing attention  What problems are there?  Some are subjective – Fail rates vary by location  They are not perfect - Computer swaps common with taxis  Can be difficult to use for enforcement unless you get a smart judge  Remember – Number of inspections matters to conserve resources – don’t target the small fish Revecorp Inc.

 General triggers such as time of day  Original triggers were for idle/ASM/gas cap testing  Idle/ASM/gas cap testing triggers are more qualitative / subjective  OBDII Triggers  Electronic quantitative data from the vehicle (“Fingerprint”)  Not subjective and therefore will better identify potential fraud  Provide solid data for enforcement to follow up on  Can be used to block fraudulent tests (real time triggers) or identify them after the fact (for enforcement action)  Equipment triggers  Still many gas analyzers and dynamometers in use  Triggers could lengthen time between costly calibrations  Triggers (statistical process control) can be used to predict maintenance issues so they can be preempted to avoid down time Revecorp Inc.

 Inspections may be appear improper if vehicle data is not validated and incorrect data is recorded  VIN should be decoded for every test as opposed to just using previous test data ▪ Previous test record could have been fraudulent – inspector changed data to change test ▪ Registration data is notoriously inaccurate – much of it, starting with the VIN – is keyed in manually and reported verbally  Critical fields to validate include: ▪ VIN – Pass check digit check, known VIN stem, support e-VIN ▪ Model year ▪ Fuel type ▪ Gross vehicle weight rating (GVWR)  BAR DAD meticulous data validation is necessary – especially with multiple vendors  Record emissions concentration data, test duration, time Revecorp Inc.

 Time of day of the test  Test duration  Pass / fail rates by item  Pass / fail rates by station, inspector, inspectors at a station  Abort rate  Gas cap not testable rate  Emissions concentrations (all gases)  Dynamometer not testable rate (AWD / 4WD)  VIN entry method  Off line / on line  Sticker info  Data changes (if allowed) Revecorp Inc.

 OBDII data to collect for comparison  Which readiness monitors are supported (1996 – 2004)  Communications protocol (1996 – 2007)  Electronic VIN – Supported, incorrectly reported and matches entered VIN (2000 +)  PID count (how to count?), PID mask  PCM ID (which of many?)  Calibration ID (2002 +)  Calibration Verification Number (2002 +)  Data should be compared to  Previous inspection data (could have been fraudulent)  VIN decoder reference table by VIN stem Revecorp Inc.

 Inspection data can be checked against reference VIN Decoded data  Check VIN, model year, fuel, GVWR  Check OBDII data against VIN decoded OBDII fingerprint  Tailpipe very difficult to evaluate in real time  Real time test blocking versus after the fact  Centralized ▪ Real time should be required – Halt the test and get a manager to review the vehicle, etc. before continuing  Decentralized ▪ Most programs cannot tolerate stopping inspections ▪ Some programs doing real time test interruptions ▪ Could refer motorists to “referee” stations to clear up discrepancy ▪ Could mark data in real time with a flag for review – go visit station Revecorp Inc.

 Pass/fail ratios by station or inspector  Have to use logic for station type (dealerships)  Location can matter so may need to be compared to other stations in the same zip code  Failure rate by item – visual catalyst fail rate very low  Time of day of the inspection  Test duration  Time between failing and then passing inspection  Which items are failed the most  Rate of pass after fail at another station  Off-line rate  Manual VIN entry Revecorp Inc.

 Tailpipe inspections  Repeated emission rates  Unexpected emission rates  Test emission rates versus network average emission rates  Rates by pollutant versus model year or even vehicle  Other  Gas cap adapter not available  Not dyno testable  OBDII rates  Non-communication rate  Not ready rate Revecorp Inc.

 Rank order individual triggers by station or inspector  Rank order all stations, where are they on a 0 – 100 scale of all stations ▪ E-VIN does not match percentile 80% ▪ Time between tests percentile 90% ▪ Pass rate percentile 85%  If there is a particular problem, can focus on the worst station or inspector  For overall enforcement, weigh individual triggers  Can weight those more important (e-VIN mismatch) higher  If all above were weighted the same, weighted percentile is 85%  Choose to focus enforcement on top XX% of stations  This all can be done overnight each night Revecorp Inc.

 Can you detect simulators?  What is the real rate of motorists using simulators?  Catalyst functionality simulators  What about shops using OBDII (vehicle) simulators  What would be the best way to make an “always pass” device?  “Man in the middle” device between scan tool and car  Connects to end of scan tool cable  Allows almost all messages through  If MIL status is called for, always respond with MIL off  If a supported readiness monitor status is requested it is always reported as ready  This would be very difficult to detect  Are stations tampering with their scan tools or OBDII data? Revecorp Inc.

 I believe a few limited triggers will catch most fraud – Bad actors are easier to catch then to get rid of  Programs should be designed to include the proper data for performing triggers analyses  The remote OBDII guidance document and many agencies have suggestions as to how the data should be recorded – it would be great if all programs used the same data  A large obstacle to using reference data is naming conventions - use of VIN based reference data solve this  Use of a VIN decoder which can provide reference data such as GVWR and fuel type can prevent fraud  There is an EPA report available that documents what is in this presentation – I can provide it if you are interested. The report ranks triggers value and provides very detailed info. Revecorp Inc.

 To solve the naming convention issue we recommend NCIC  We have been discussing distribution of recall data with several groups and they would like IM programs to provide this data to motorists. Many times the second or later owner does not receive important safety recall data. VINterpreter has data on recall compliance by VIN, both emissions and safety data, which is always up to date  We have a database of hundreds of million of data records. The data are used to improve vehicle fingerprints to prevent fraud. Please consider sharing you IM data with us.  We have an Android version of the VINterpreter VIN decoder available for free to anyone interested to check individual data - just ask and we will provide you access Revecorp Inc.

Contacts: Revecorp Inc. Michael St. Denis, Robert Budd 5732 Lonetree Blvd Rocklin CA (916) Revecorp Inc.