2005-01-3604 OBD Communication Concepts for J1939 SystemsView Document

400 Commonwealth Drive, Warrendale, PA 15096-0001 U.S.A. Tel: (724) 776-4841 Fax: (724) 776-5760 Web: By mandate of the Engineering Meetings Board, this paper has been approved for SAE publication upon completion of a peer review process by a minimum of three (3) industry experts under the supervision of the session organizer.All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of SAE.For permission and licensing requests contact:SAE Permissions400 Commonwealth DriveWarrendale, PA 15096-0001-USAEmail: permissions@Fax: 724-772-3036Tel: 724-772-4028For multiple print copies contact:SAE Customer ServiceTel: 877-606-7323 (inside USA and Canada)Tel: 724-776-4970 (outside USA)Fax: 724-776-1615Email: CustomerService@ISSN 0148-7191Copyright © 2005 SAE InternationalPositions and opinions advanced in this paper are those of the author(s) and not necessarily those of SAE. The author is solely responsible for the content of the paper. A process is available by which discussions will be printed with the paper if it is published in SAE Transactions.Persons wishing to submit papers to be considered for presentation or publication by SAE should send the manuscript or a 300 word abstract of a proposed manuscript to: Secretary, Engineering Meetings Board, SAE. Printed in USAABSTRACTAs regulations for on-board diagnostics head toward the heavy-duty trucking industry, there are a variety of new communication concepts that will directly impact J1939 systems. ECUs on J1939 networks must support new standard diagnostic protocols and data. Vehicles must provide single-point access for concise OBD data sets that represent multiple ECUs. New technologies, such as wireless communication links, present completely new and different scenarios for diagnostic testing. Understanding these concepts and their implications is essential to designing a J1939 system that will integrate into the coming global OBD infrastructure. INTRODUCTIONThe transportation industry is steadily evolving into a global entity. Commercial vehicles using J1939 networks play a significant role in that global community and will continue to do so well into the next decade. In order to keep up with the coming demands of the global community, commercial vehicle networks will continue to evolve. This evolution will move to a higher level and go beyond the J1939 standards and OEM specifications driving progress within the vehicle today. Today, theJ1939 standard enables manufacturers of commercial vehicles to integrate electronic control units from different vendors into complete vehicle control networks. Tomorrow, new OBD networking technologies will enable manufacturers to integrate their commercial vehicles into the local, national and global infrastructures they must operate within.As the scope of integration moves from within the vehicle to the interface between the vehicle and the surrounding infrastructure, significant new players enter the picture. These organizations have responsibilities in the areas of public welfare, public infrastructure and technologies not previously applied in vehicular applications. The requirements and use cases these organizations bring to the vehicle can be met through new standards and applications for OBD communications. This paper presents an overview of the organizations driving the evolution in OBD, the new uses cases they present and the supporting technologies that will enable the evolution, with a focus on the aspects that are most likely to be new to developers of J1939 networks and control units.ORGANIZATIONS DRIVING EVOLUTION IN OBD COMMUNICATIONSBesides SAE, the organizations driving the evolution of OBD communications come from both government regulatory agencies and technical standards organizations. While each organization allows for different solutions, all organizations involved recognize that a single solution for all requirements is necessary for a variety of reasons – especially as a means of allowing system implementers to provide vehicles that can integrate into any local infrastructure. GOVERNMENT AGENCIESIn the United States, CARB (California Air Resources Board) and the EPA (Environmental Protection Agency) are long-time players and leaders in the area of OBD and emissions regulation. CARB and the EPA are extending their OBD requirements from passenger car vehicles to heavy-duty vehicles. US requirements for an OBD data link would allow heavy-duty diesel vehicles to meet OBD requirements via existing J1939 protocols and connectors supporting new monitors and data sets specifically designed for OBD.In Europe, the EU seeks a single solution that would support OBD for both light-duty and heavy-duty vehicles. While current solutions for J1939 and ISO15765 each meet EU requirements, a single common solution is sought. A new solution based on ISO15765 seems more likely as it would have less impact on the OBD requirements already in place for passenger car vehicles and appears to be more readily adapted to a J1939 network.At the global level, the United Nations seeks to define a Global Technical Regulation (GTR) that would start by defining OBD requirements for heavy-duty diesel applications, but would eventually expand to a single solution covering all OBD requirements for all vehicles. The GTR would start with the existing emissions-related diagnostics scope of OBD, but would later expand to2005-01-3604OBD Communication Concepts for J1939 SystemsMark JensenVector CANtech, Inc. Copyright © 2005 SAE Internationalinclude safety-critical systems. Besides covering the wired connection to the vehicle, the UN GTR requires a wireless connection that would enable OBD communications with vehicles in service on the road.TECHNICAL STANDARDS ORGANIZATIONSThe UN GTR tasked ISO with the responsibility of defining the OBD standard for World-Wide Harmonized On-Board Diagnostics. In response, ISO created an ad-hoc task force to create such a standard. The ad-hoc task force has been given a home in ISO Technical Committee 22 / Sub-committee 3 / Work Group 1 as Task Force 3 (ISO TC22/SC3/WG1/TF3). The task force has self-imposed a charter to meet the requirements of not just the UN GTR, but also CARB, US EPA and the EU and is working with all of these organizations to ensure proper coordination. The task force interacts directly with both the SAE Truck and Bus Council and the SAE Motor Vehicle Council to involve the heavy-duty and light-duty vehicle activities and theJ1939 community.The ISO WWH OBD task force expects to publish a new international standard for WWH-OBD communications in the coming years. The document will be an implementation specification defining the WWH-OBD use cases, a common data dictionary, a common message set, the wired physical connection, the wireless connection and conformance test requirements. At present, this activity is headed toward a solution based on ISO14229 and ISO15765. ISO14229, or Universal Diagnostic Services (UDS), is a general-purpose network-independent diagnostic protocol widely embraced by the passenger car industry. ISO14229 is currently only used for enhanced (non-legislated proprietary) diagnostics, but was built to support OBD as well and should prove sufficient for the job. ISO15765 defines, among other things, a standardized implementation of ISO14229 on CAN.A common OBD communication link that delivers performance capable of meeting expectations for the next ten years is not likely to be based on CAN alone. Solutions based on Ethernet, especially wireless Ethernet, have drawn IEEE into the vehicle networking community. ISO, SAE, IEEE, world governments, industry consortiums and transportation authorities are currently working together to define the DSRC (Dedicated Short Range Communication) standards for wireless vehicular communications. Various versions of DSRC are taking hold in different geographic regions.The US version of DSRC is known as WAVE (Wireless Access in the Vehicular Environment). IEEE 802.11p is the wireless Ethernet specification for WAVE. IEEE P1609 specifies the WAVE communications strategy, server requirements, client-server interface, message structure and security mechanisms. Supporting the WAVE activities is an SAE technical committee defining the DSRC message set and data dictionary in the new document J2735. Packing OBD messages for exchange through WAVE systems will be a key activity for this committee.Another version of DSRC aiming for a global standard is found in CALM (Continuous Air interface for Long and Medium distance). CALM is meant to cover all forms of wireless communications, including regional flavors of DSRC and cellular bands. CALM depends on an extended version of IEEE 802.11p that allows a broader and more flexible use of radio frequencies. CALM also specifies an open software architecture that provides standardized interfaces to numerous networking technologies, both wireless and wired.USE CASESThere are three commonly accepted use cases defining the scenarios future OBD systems must support.IN-SERVICE MONITORINGThis use case represents the highest level of integration with the surrounding infrastructure. Roadside wireless communication access points will interact with vehicles as they pass by. Likely locations for these wireless access points are the weigh stations and toll collection points already in place today. Future regulations could lead to access points along all roads, including urban surface streets.The exchange of in-service monitoring information is simple and concise. As a vehicle approaches a roadside access point, a wireless OBD communication link will be established. The vehicle will identify itself and provide a simple “Go/No-go” indication of its OBD status. A positive “Go” status would indicate the vehicle was in compliance with OBD regulations it was designed to meet. A negative “No-go” status would indicate that some OBD failure had been self-diagnosed by the vehicle and requires further inspection.INSPECTIONInspection involves a more detailed extraction of OBD data from the vehicle. Specific DTCs, DTC status, monitor status information and associated freeze frame data make up the inspection data set. This data must be presented as vehicle-level data and is not tied to specific ECUs.Inspection communications could occur through a traditional wired link or through a wireless link. The wireless scenario could be the resulting action taken by a roadside access point immediately after in-service monitoring detects a negative “No-go” status. Depending on local enforcement policies, the inspection data could be used to direct the vehicle operator to schedule service or to pull the vehicle off the road for handling by the local authorities. It is even conceivable that such a system could be used to automatically assess fines against the owner and/or operator of the vehicle.REPAIRRepair is the lowest level of integration with the infrastructure and is the same scenario seen today with typical diagnostic communication links. A vehicle is in a service garage for detailed diagnostics. ECU-level diagnostics are required along with working knowledge of the OBD monitors and tests. Wireless access may be helpful in this scenario, but traditional wired links are likely to be highly effective.FAULT MEMORYFault memory is the focus of OBD applications. 17 different US states use fault data alone as a means of diagnosing and testing vehicle emissions. New scenarios and regulations do not change that focus, but new specs are likely to change the structure of the fault data managed and reported by OBD ECUs.FAULT HIERARCHIESAll OBD DTCs will be categorized according to their significance with respect to emissions compliance. As the scope of OBD expands to cover safety-critical systems, these categories will be expanded to indicate significance with respect to a vehicle’s overall roadworthiness. Four fault categories have been defined in a hierarchy – a level for failures requiring legal penalties, a level for failures requiring repair, a level for failures generating operator warnings and a level for failures generating operator informational messages.A single DTC may support multiple levels of the hierarchy, but can exist at only one level at any point in time. Some DTCs might go immediately to the level requiring repairs and over time could be elevated to the level requiring a penalty. Other DTCs might start out at the level producing informational messages and over time could be elevated to higher levels.In order for these levels to produce the hierarchical effects intended, the vehicle operator must receive a simple and clear indication of the highest level fault present on the vehicle at any time. The malfunction indicator lamp (MIL) will provide this indication. MIL behavior will be tied directly to the highest level fault present on the vehicle. DTCs at the highest level might flash the MIL during normal operating conditions. DTCs at the next highest level might illuminate the MIL on solid at all times. Lower levels might flash the MIL for a period after start-up. Based on the MIL behavior, the vehicle operator could always know the roadworthiness of the vehicle with respect to the OBD requirements it was designed to meet.Where vehicle design requirements and local OBD legislation requirements are different, a potential problem arises. If the vehicle is taken into a region with different OBD requirements than those the vehicle was built to, the MIL behavior might not accurately inform the operator of the vehicle’s status with respect to local legislation. The vehicle operator must now understand the behavior of the MIL with respect to vehicle design requirements and also understand how those requirements do or do not satisfy local legislation. This is an error-prone situation at best. Smart OBD systems could use information from roadside access points to identify local requirements and modify MIL behavioral rules accordingly. However, this concept remains undefined and outside the scope of the current fault hierarchy concept.PERMANENT FAULTSPermanent faults are defined as DTCs with OBD monitors that have not passed since the last detected failure. A permanent fault can not be cleared or erased by a diagnostic test tool or a battery disconnect. A permanent DTC can only be set or cleared by the OBD monitor that determines the status of the fault. This is different than the concept of historical faults as permanent faults indicate only current and active failures as opposed to failures which may have occurred in the past but have since been resolved.Permanent DTCs enable an OBD test process that does not require the clearing and initialization of test monitors. Monitors will automatically set and clear permanent DTCs according to test results gathered during normal monitoring. If a repair to resolve an OBD failure is successful, the associated monitors will automatically detect the system is in working order and will clear the permanent DTC. Such a system eliminates the opportunity for operators to clear DTCs prior to inspection and momentarily give the deceptive appearance of a roadworthy vehicle. Repair processes may be streamlined as technicians need not clear and re-run tests for fault-free systems. Only those tests and monitors associated with failed systems need to run for the vehicle to be certified.FREEZE FRAME DATACurrent freeze frame data sets can include as much or as little data as a system implementer chooses to provide. Though diligence has current systems providing helpful freeze frame data, new regulations will require not just common standardized freeze frame data sets, but all data used by OBD monitors to be included in the freeze frame data for the DTCs the monitors detect. As a result, every freeze frame data set will begin with a minimum set of mandatory standard data values. Any additional values used by the OBD monitor will appear after the standard values.DTC HARMONIZATIONThere are several DTC formats widely used in emissions-related diagnostics today. The two leading candidates for use in WWH-OBD are the formats found in J1939 and ISO14229. Both are 24 bits in length and both are comprised of an identifier for the failed device and an identifier for the failure mode of the device. SAEJ1939 uses a 19-bit SPN and a 5-bit FMI to build a 24-bit DTC. ISO14229 uses a 16-bit root DTC and an 8-bit failure type byte (FTB) to build a 24-bit DTC. As both DTC formats are 24 bits in length, packaging either DTC format into a common message does not pose a technical challenge.Where the difficulty occurs is in the harmonization of the two fault sets. If a single solution is to be agreed upon, one format or the other must be selected and the data from both fault sets must be reconciled and combined into a single set of unique DTCs. Not only are there faults that have different representations in the two different formats, but a 19-bit SPN offers more device identifiers than a 16-bit root DTC and an 8-bit FTB offers more failure types than a 5-bit FMI. Some of these differences can only be resolved by abandoning part of one fault set to accommodate the fault format of the other. This task remains to be done and represents a significant future effort.DATA DICTIONARYFor any WWH-OBD solution to work, a data dictionary must be defined that encompasses all data standardized for OBD applications. Like with fault memory, new specs are likely to change the structure of the data managed and reported by OBD ECUsDATA IDENTIFIER HARMONIZATIONThere are several data identifier formats widely used in emissions-related diagnostics today. The two leading candidates for use in WWH-OBD are the formats found in J1939 and ISO14229. J1939 data identifiers are represented as 18-bit PGNs. ISO14429 data identifiers are represented as 16-bit Data Identifiers (DIDs). Note that the length of the identifier is not the same as the length of the data packet it represents. Both PGNs and DIDs can contain larger data packets. The identifier is the logical ID of the packet. Resolving this difference in identifier size is a difficult challenge yet to be resolved and with no clear solution.As the J1939 18-bit PGNs are longer than the ISO14229 16-bit DIDs, one might expect that ISO14229 could simply be extended to accommodate 18-bit (or 24-bit) data identifiers. This concept is being evaluated, but has some drawbacks. While PGNs appear in the CAN identifier in the header of a CAN frame, ISO14229 data identifiers appear in the data area of a CAN frame. Adding another byte to the ISO14229 data identifier uses a CAN frame byte currently available for data values. This increase in ratio of overhead to payload is undesirable and will lead to lower throughput.ODX – OPEN DATA EXCHANGE FORMATThe Open Data Exchange (ODX) format is a global initiative to define a common open diagnostic data exchange format. ODX is an XML-based format that offers significant new opportunities for different companies and organizations to exchange diagnostic data that can be read and written by commercial off-the-shelf tools.Originally proposed by the ASAM consortium for defining passenger car enhanced diagnostic data, ODX has been introduced into ISO and has found a home in the same work group as the WWH-OBD task force. It is the intent of the task force to define the WWH-OBD data dictionary in the ODX format.The ODX concept, especially as applied to OBD, tends to be confusing for the J1939 community. J1939 has always provided and supported a common standard data dictionary embraced by all commercial vehicle industry participants. A standardized and shared data dictionary eliminates the need for an open data exchange format. There is no significant use case for importing or exporting data that is already known to and implemented by any exchange partner.In the passenger car industry, diagnostic data is almost entirely proprietary. OBD data has been standardized, but represents only a small fraction of the diagnostic data supported by the typical vehicle which has many ECUs that have no emissions-related diagnostics. Exchanging diagnostic data between participants in the passenger car industry has long been a problem that ODX may be able to ease.Another advantage to the ODX concept is that it can eliminate tool dependencies on a standardized data dictionary. If OBD test tools can be driven by a plug-and-play database, changes in the standard data or proprietary data can be brought into service quickly and easily and without updating test tool software. PROTOCOLAs stated earlier, various aspects of J1939 and ISO14429/ISO15765 are the only serious candidates for the basis of any new harmonized OBD protocol supporting both light-duty passenger car vehicles and heavy-duty commercial vehicles. The differences between J1939 and ISO14229 on CAN are significant and need to be understood by all participants if a successful common solution is to be found. COMMUNICATION MODELJ1939 diagnostic messaging is done primarily through a broadcast model. An ECU will broadcast diagnostic information on the network as part of its normal operation. Other ECUs and any external test tools that might be listening can monitor the bus for most of the diagnostic information needed. Fault data is especially easy to acquire in this fashion.ISO14229 uses a request-response communication model for all diagnostic messaging. An ECU will never broadcast unsolicited diagnostic information and other ECUs have no requirement to monitor the network fordiagnostic data from other ECUs. Diagnostic information is only sent by an ECU when requested by a test device. The test device has traditionally been on off-board test tool, but recent network designs have tester functionality built into on-board ECUs that act as permanently attached test tools. The diagnostic exchange is a point-to-point conversation that must be initiated and paced by the tester. The tester is the client or master and the ECU being diagnosed is the server or slave.NETWORK ADDRESSINGOn a J1939 network, 29-bit CAN frame identifiers are used to indicate the data content of the frame and possibly also the transmitter and intended receiver. The addressing scheme and data payload formats are intertwined and are not intended to be separated. Passenger car networks use 11-bit, 29-bit or a mixture of both 11-bit and 29-bit CAN frame identifiers. The addressing scheme may conform to a standard similar to J1939 or may be proprietary. The addressing scheme and data payload formats are interdependent for normal operating messages, but not for diagnostic messages. ISO14229 is a network-independent design and has no knowledge of CAN or any CAN-based addressing scheme. The standard implementation of ISO14229 on CAN is specified in ISO15765. ISO15765 specifies both 11-bit and 29-bit addressing schemes that identify the messages as diagnostic messages, but does not indicate the exact format or nature of the data payload in the message. The content and format of the data payload is specified by ISO14229. The format of the data payload in an ISO14229 message can only be determined by examining the first byte or bytes of the data payload. The first byte of the message is the service identifier (SID). The SID will indicate the format of the remainder of the diagnostic message. This encoding of the data allows the diagnostic messages to work in any addressing scheme and naturally lends itself to a request-response communication model.It is important to note that while the J1939 network addressing scheme is incompatible with some passenger car CAN systems, the ISO15765 addressing scheme defines a means for seamlessly integrating ISO14229 messages into a J1939 network. This portability of ISO14229 makes it the current frontrunner for a new harmonized global OBD protocol serving both heavy-duty and light-duty vehicles.VOBD – VEHICLE OBDRepresenting the entire vehicle as a single OBD entity requires new functionality in the vehicle. This new functionality must allow test devices and compliance monitoring devices to identify the vehicle and gather the vehicle-wide OBD “Go/No-go” status in the minimum amount of time with the minimum amount of overhead. In order to meet this requirement, a vehicle OBD unit or VOBD is needed to manage the off-board communications.The VOBD will be a single access point providing the vehicle-wide status information in the in-service monitoring use case. The VOBD will act as a gateway allowing off-board testers to access the OBD services and data provided by the OBD ECUs in the repair use case. The VOBD may be a single access point, a gateway or some hybrid of the two in the inspection use case. The VOBD may even have diagnostic data of its own to report to off-board testers. The design and location of the VOBD will depend on the access provided to the wireless link and the J1939 network.The VOBD is not required to be a new ECU in the vehicle. Rather, it is expected that the VOBD will be implemented as a virtual software-only device that resides in an existing ECU, such as the engine control unit or the DSRC wireless unit.CONCLUSIONDiagnostic concepts are nearly identical between commercial vehicles using J1939 and passenger cars using CAN. Both systems are based on fault monitors and the supporting data they depend upon. The implementation of the diagnostic communication links are fundamentally different and pose a significant challenge to harmonize. The ISO WWH-OBD direction to build on the foundation provided by ISO14229 and ISO15765 represents a technical challenge coming to the J1939 community. The new use cases for supporting in-service monitoring, permanent faults, a vehicle-wide “Go/No-go” status indicator and wireless communications mean that OBD will no longer be about just emissions-related engine diagnostics. OBD will become more about integrating the vehicle as a whole into the public infrastructure it operates within. This strong tie to the infrastructure will mean expanding not just the OBD systems and technologies, but also the organizations that design and implement them. These organizations must support new interfaces to previously unrelated organizations that will have new and different points of view leading to new and different requirements. ACKNOWLEDGMENTSThe global OBD community is made up of many experts in the areas of vehicle diagnostics, vehicle communication technology, emissions-related legislation and standardization. These experts come from the organizations already referenced in this document and the companies that participate in the ground vehicle industries. Of special note for their expertise across all of these disciplines and their continuous support for the related standards development activities within both ISO and SAE are Mr. Gangolf Feiter and Mr. Richard Price. Their years of effort to harmonize the OBD standards and communities from the commercial vehicle and passenger car industries made possible the discussions that provided the foundation of this paper.CONTACTMark Jensen is the manager for diagnostic technologies at Vector CANtech, Inc. and is an active participant in the SAE and ISO committees for ground vehicle diagnostics and the SAE committee for the DSRC message sets and data dictionary.mailto:mark.jensen@(248)449-9290 x247Vector CANtech, Inc.Suite 550 39500 Orchard Hill PlaceNovi, MI 48375DEFINITIONS, ACRONYMS, ABBREVIATIONS CAN: Controller Area Network as defined by ISO11898 DID: Data Identifier used in ISO14229 protocol DSRC: Dedicated Short Range Communication; IEEE activity to deliver wireless networking to the vehicle environmentDTC: Diagnostic Trouble CodeFTB: Failure Type Byte; similar in nature to J1939 FMI GTR: Global Technical RegulationISO14229: ISO standard for a general-purpose network-independent ground vehicle diagnostic protocol; also known as Universal Diagnostic Services or UDSISO15765: ISO standard defining vehicle diagnostics on CAN, especially ISO14229ODX: Open Data Exchange; XML-based diagnostic data exchange formatUDS: see ISO14229WWH-OBD: World-Wide Harmonized On-Board Diagnostics。