1. I/M Solutions 2011 Training Forum for Jurisdictions May 17, 2011 SAE J1699-2 Recommended Practice Overview Bob Gruszczynski, OBD Specialist Volkswagen of America Audi of America SAE E/E Diagnostics Vice-Chair

2. 2 J1699-2 Scan Tool Validation What is it? Document title  Test Cases For OBD-II Scan Tools and I/M Test Equipment Scope  To define test cases for the OBD-II interface on external test equipment (such as an OBD-II Scan Tool, I/M Tester, etc.) which can be used to verify compliance with the applicable standards such as SAE J1978 and SAE J1979 for Passenger Cars, Light-Duty Trucks, and Medium-Duty Vehicles and Engines (OBD II)

3. 3 J1699-2 Current Status n Document format and outline have been agreed by the group. This will be circulated among interested parties for comment. n Initialization test scenarios have been selected and implemented for first ballot. n SAE Information Report to be issued regarding initialization anomalies. New SAE Project – J1699-4 as of March 2011. n ETI, scan tool and I/M manufacturers, and OEM’s providing testing scenarios based on field experience. n First ballot expected this year.

4. 4 J1699-2 – Why? n SAE J1699-3 Vehicle OBD II Compliance Test Cases Recommended Practice was written at the request of California ARB to be used as part of vehicle OBD PVE (j)(1) testing. n ARB has legislated that for 2005 MY and newer vehicles OEM’s must conduct testing according to J1699-3. n Successful completion of a J1699-3 test indicates that the vehicle is capable of correct OBD communications.

5. J1699-2 – Why?

7. 7 n All three valid K-line protocol init sequences are shown on slide 1 (only one is allowed per vehicle) o Protocol-Decision for 5 baud is done via KeyBytes n The red line indicates the path taken by the tool in case of 5 baud init and ISO14230 KeyBytes. o red path A to B to “request (9141-2)“ is not ISO compliant n The red path from C to D appears to represent a new init attempt by the tester and can be handled by a vehicle only supporting 5 baud init in two different ways: o ignore the fast init sequence and respond to the 14230-request within 5 sec ( KWP diagnostic session via 5 baud init still open) o stops the running diagnostic session (opened by successful 5-baud init) due to erroneous request and/or next init attempt - recognize new init by the first falling edge (fast init) - no response because fast init not supported n In case the vehicle supports fast init : o does not answer during 5 baud init attempt o responds to the following fast init correctly J1699-2 – Why?

8. 8 Some CAN vehicles from several manufacturers appear to not return VIN or CalID. ISO 15765-4 is the CAN Standard that relates to emission- related systems and states (Table 7): ParameterNameValueDescription N_WFT max WaitFrame Transmission 0No FlowControl wait frames are allowed for legislated OBD. The FlowControl frame sent by the external test equipment following the FirstFrame of an ECU response message shall contain the FlowStatus FS set to 0 (ClearToSend), which forces the ECU to start immediately after the reception of the FlowControl frame with the transmission of the ConsecutiveFrame(s). BSBlockSize0A single FlowControl frame shall be transmitted by the external test equipment for the duration of a segmented message transfer. This unique FlowControl frame shall follow the FirstFrame of an ECU response message. ST min SeparationTi me 0This value allows the ECU to send ConsecutiveFrames, following the FlowControl frame sent by the external test equipment, as fast as possible. If a reduced implementation of the ISO 15765-2 network layer is done in a legislated-OBD ECU, covering only the above listed FlowControl frame parameter values (BS, STmin), then any FlowControl frame received during legislated-OBD communication and using different FlowControl frame parameter values as defined in this table shall be ignored by the receiving legislated-OBD ECU (treated as an unknown network layer protocol data unit).

9. 9 n Differing exemptions by state:  2-6 year new vehicle exemption.  Change of ownership requirements. n K-Line protocols have been called “dead protocols”  Some ISO 9141 vehicles just entering I/M (Calif. diesel program).  Most ISO 14230 vehicles just entering I/M (2004, 2005 MY). n CAN/ISO 15765 will have a long life. (M. McCarthy – ARB) n J1699-2 testing will identify known issues like those listed above, and can prevent new issues from reaching the field. n State I/M programs and other tool purchasers can specify J1699-2 testing as part of requirements for new equipment. J1699-2 – Why?

10. 10 J1699-2 – Why? n Conceptually, if a scan tool or I/M tool successfully completes SAE J1699-2 testing, it should most likely be capable of correct OBD communications. n Therefore, if a vehicle passes J1699-3 and a tool passes J1699-2, there should be no issue with communications. n Communications rates should approach 100%.

11. 11 n Main item is to reduce OBD communications issues. n Tool manufacturers can use J1699-2 as part of internal validation testing. n State I/M programs and other tool purchasers can specify J1699-2 testing as part of requirements for new equipment. Future Usage

12. 12 n States starting to look into methods of performing fraud detection and prevention. n Service $01 data not reliable due to older SAE J1979 implementations (diesel monitor data reported as gasoline). n Service $09 and possible Service $06 data currently not reliable due to inconsistencies in multi-frame data handling with CAN protocol. n Standardized testing utilizing SAE J1699-2 can help to insure data integrity. Future Usage

13. 13 Conclusions  No matter how well written, developers and users will make misinterpretations of SAE Recommended Practices and ISO Standards.  OBD Communications issues are still a significant issue in the field.  Communications issues can be greatly reduced.  SAE J1699-2 compliance can be a way to alleviate issues.  Fraud detection and prevention strategies can be enhanced by use of SAE J1699-2.

14. 14 THE END Thank you for your attention! robert.gruszczynski@vw.com