7
D ue to new application layer requirements, SAE is continuing to de- velop the J1939 standard, which is primarily used to network powertrains in commercial vehicles. How- ever, optimizations and ex- tensions are being made in the other communication layers as well, right up to the physical transmission layer. This article summarizes the current state of discussions within the SAE J1939 work- ing committee, such as the planned introduction of the 500-kbit/s physical trans- mission layer and chang- es to network management. Moreover, it also explains ongoing efforts to standard- ize J1939 in Autosar Re- lease 4 and WWH-OBD (world-wide harmonized on- board diagnostics) diagnos- tics. Based on the CAN bus (high-speed CAN per ISO 11898), the SAE J1939 standard is used primarily to network the powertrain and chassis in commercial vehicles. The protocol cre- ates a uniform foundation for communication between the electronic ECUs (elec- tronic control unit) and op- erates by the plug-and-play principle. The J1939 stan- dard is an active standard that currently consists of 19 documents. The respon- sible SAE subcommittees generally meet four times a year to decide on changes and further developments. The current versions of the documents may be pur- chased either individually or together as a package in so-called “JPaks” from the SAE website [1]. More bandwidth For years now, the maxi- mum 250-kbit/s bandwidth specified in the standard Quo vadis SAE J1939 standardization Peter Fellmeth, Holger Söhnle (Vector Informatik) Status of SAE J1939 documents (September 2010) has forced commercial ve- hicle developers to work at the limits of performance [2]. From a communication perspective, development of the 500-kbit/s data trans- port layer is a long overdue step. European commercial vehicle producers in partic- ular are seeking a final de- cision in the near future. The specification will be re- leased in a separate docu- ment, J1939-14, and its key aspects are: Twice the bit-rate, 500 kbit/s instead of 250 kbit/s Use of shielded and un- shielded cable as de- fined in [2] and [3] is still possible Topology is essentially a bus that has branch lines with a max. length of 1 m. To connect diagnostic 62 CAN Newsletter 1/2011 Standardization

Quo vadis SAE J1939 - Semantic Scholar · CAN frame, J1939-21 spec-ifies two transport protocol (TP) variants. These are the broadcast announce message (BAM) variant and connection

  • Upload
    others

  • View
    14

  • Download
    0

Embed Size (px)

Citation preview

Page 1: Quo vadis SAE J1939 - Semantic Scholar · CAN frame, J1939-21 spec-ifies two transport protocol (TP) variants. These are the broadcast announce message (BAM) variant and connection

Due to new application layer requirements,

SAE is continuing to de-velop the J1939 standard, which is primarily used to network powertrains in commercial vehicles. How-ever, optimizations and ex-tensions are being made in the other communication layers as well, right up to the physical transmission layer. This article summarizes the current state of discussions within the SAE J1939 work-ing committee, such as the planned introduction of the 500-kbit/s physical trans-mission layer and chang-es to network management. Moreover, it also explains ongoing efforts to standard-ize J1939 in Autosar Re-lease 4 and WWH-OBD (world-wide harmonized on-board diagnostics) diagnos-tics.

Based on the CAN bus (high-speed CAN per ISO 11898), the SAE J1939 standard is used primarily to network the powertrain and chassis in commercial vehicles. The protocol cre-ates a uniform foundation for communication between the electronic ECUs (elec-tronic control unit) and op-

erates by the plug-and-play principle. The J1939 stan-dard is an active standard that currently consists of 19 documents. The respon-sible SAE subcommittees generally meet four times a year to decide on changes and further developments. The current versions of the documents may be pur-

chased either individually or together as a package in so-called “JPaks” from the SAE website [1].

More bandwidthFor years now, the maxi-mum 250-kbit/s bandwidth specified in the standard

Quo vadis SAE J1939standardization

Peter Fellmeth, Holger Söhnle (Vector Informatik)

Status of SAE J1939 documents (September 2010)

has forced commercial ve-hicle developers to work at the limits of performance [2]. From a communication perspective, development of the 500-kbit/s data trans-port layer is a long overdue step. European commercial vehicle producers in partic-ular are seeking a final de-cision in the near future. The specification will be re-leased in a separate docu-ment, J1939-14, and its key aspects are:

Twice the bit-rate, 500 kbit/s instead of 250 kbit/sUse of shielded and un-shielded cable as de-fined in [2] and [3] is still possibleTopology is essentially a bus that has branch lines with a max. length of 1 m. To connect diagnostic

62 CAN Newsletter 1/2011

Stan

dard

izat

ion

Page 2: Quo vadis SAE J1939 - Semantic Scholar · CAN frame, J1939-21 spec-ifies two transport protocol (TP) variants. These are the broadcast announce message (BAM) variant and connection

RF & Wireless

Mem

oryAnalog

Digital Signal

Controllers M

icrocontrollers

Page 3: Quo vadis SAE J1939 - Semantic Scholar · CAN frame, J1939-21 spec-ifies two transport protocol (TP) variants. These are the broadcast announce message (BAM) variant and connection

tools, a branch line (from the diagnostic socket to the diagnostic tool) with a length of 5 m may sometimes be used.The bus is terminated at both ends with a char-acteristic impedance of 120 . Up to 30 nodes are possible.

The specification for the di-agnostic plug [4] was adapt-ed to 500-kbit/s operation. In addition, a new “Type II” diagnostic socket is being used in the vehicle, which has a green color-coding, and its connector keying prevents use of the previous 250-kbit/s “Type I” diagnos-tic plug. A “Type II” plug is compatible with a “Type I” socket. Another change is that the “Type II” diagnos-tic socket defines pins pre-viously used for SAE J1708/J1587 as reserved. Conse-quently, a J1708-/J1587-net-work can no longer be ad-dressed via a “Type II” diag-nostic plug.

SAE gets serious about dynamicsChanges are also being made in the area of Network Management [5]. For a long time now, the J1939-com-mittee has been deliberat-ing over ways to handle the short supply of permanent-ly assigned ECU address-es. This is especially prob-lematic for manufacturers

of sensors with a direct bus connection. The number of new devices is growing rap-idly due to heightened ex-haust emissions require-ments and the addition of assistance systems. Many alternatives were proposed but then rejected. They ranged from a dedicated network for sensors to im-plementation of a new pro-tocol – e.g. by using previ-ously reserved data pages.

Meanwhile, the fact was that SAE has not as-signed any more new ad-dresses. That was an un-satisfactory situation for ECU suppliers. Often, they did not know whether their product designs would have lasting value. In the latest version of Network Manage-ment, SAE recommends im-plementing “Address Arbi-trary Capable” ECUs. These ECUs are able to compute their own addresses based on the momentary vehicle configuration – and indeed at runtime. Essentially, this approach aims to utilize the mechanism of dynamic ad-dress allocation that has always existed in the com-mercial vehicle field, but has never really been im-plemented or used before.

In conjunction with Net-work Management, the new-ly added Name Manage-ment should be mentioned for the sake of complete-ness. This is a standard-ized interface for changing

specific components of the 64-bit device name. This might be necessary if the relevant function or mea-surement parameter is de-rived from the device name. So, the device name can be used to identify the position of an exhaust gas tempera-ture sensor – upstream or downstream of the catalytic converter, on the right or left side of a dual-flow exhaust system. Changes can be made to multiple ECUs in sequence and activated at a specific point in time. This could be helpful, for exam-ple, in a case where multi-ple ECUs of a network need to be assigned a new func-tion simultaneously.

These changes in Network Management are supported in version 7.5 of Vector’s CANalyzer.J1939 analysis tool and its CA Noe. J1939 test tool.

Autosar and J1939 come closer togetherThe introduction of Auto-sar in the passenger car in-dustry is ramping up quick-ly. Yet, there is also interest in exploiting the benefits of Autosar in commercial ve-hicle and the agricultural machine markets. Howev-er, the special requirements of these markets have not been a focus in the devel-opment of Autosar. There-fore, the Autosar versions released so far have very limited potential in these markets. In particular, the requirements of SAE J1939 cannot be mapped to the current Autosar concept, or only in a very limited way.

The “static” approach of Autosar stands in con-trast to the “dynamic” be-havior of J1939. The Auto-sar architecture only allows fixed CAN-IDs (identifiers), i.e. there is a fixed alloca-tion between precisely one CAN-ID and one message layout. In contrast to this, a J1939-specific message layout is only allocated to a specific part of the CAN-ID,

Fig. 2: Layout of a 29-bit CAN-ID in J1939 networks

Fig. 3: Autosar basic software from Vector contains the two J1939 transport protocols BAM and CMDT

64 CAN Newsletter 1/2011

Stan

dard

izat

ion

Page 4: Quo vadis SAE J1939 - Semantic Scholar · CAN frame, J1939-21 spec-ifies two transport protocol (TP) variants. These are the broadcast announce message (BAM) variant and connection

You CAN get itHardware & software for CAN bus applications…

www.peak-system.com

Page 5: Quo vadis SAE J1939 - Semantic Scholar · CAN frame, J1939-21 spec-ifies two transport protocol (TP) variants. These are the broadcast announce message (BAM) variant and connection

known as the parameter group (PG). Some of the other components of the 29-bit CAN-ID are dynamic and not defined at the time of configuration. Such a dy-namic CAN-ID can be mod-eled in Autosar by creating a separate static CAN-ID for each combination of priori-ty, source address (SA) and destination address (DA) that can occur in a network.

When all nodes of a J1939 network are known, and node addresses are al-ready defined at the time of configuration, it is relatively easy to map J1939 PGs to Autosar: In case of such a static network, the ECU ad-dresses are fixed. There-fore source and destination addresses are fixed, and so it is possible to work with static CAN-IDs. To trans-mit data that is longer than the 8 bytes available in a CAN frame, J1939-21 spec-ifies two transport protocol (TP) variants. These are the broadcast announce message (BAM) variant and connection mode data transfer (CMDT; also known as RTS/CTS) variant. Both of them are already defined in Autosar release 4.0 and have been available since December 2009. Therefore, Autosar release 4.0 already covers the requirements of many European commer-cial vehicle producers.

More in-depth support of J1939 requirements is planned for the end of 2012 in Autosar release 4.1. The target group here includes European and some North American commercial ve-hicle OEMs (original equip-ment manufacturer).

The primary extended features being added to Au-tosar:

Support of multiple mes-sages with the same lay-out (the same parameter group)Network M anagement per SAE J1939/81 with-out dynamic NM, i.e. without AAC (arbitrary address capable)Responses to a request messageSupport for diagnostic services On-board diagnostics (WWH-OBD) via J1939

Together with large Euro-pean commercial vehicle

OEMs Vector actively par-ticipates in efforts to spec-ify these J1939 extensions for Autosar. Today, Vector already offers an Autosar solution with a J1939 ex-tension based on Autosar release 4.0. It will soon be used in production at one large European commer-cial vehicle OEM. The ex-tension for Autosar release 4.1 is currently in the devel-opment stage.

Vehicle diagnostics using WWH-OBDOBD is a diagnostic sys-tem standardized by ISO; one of its applications is to monitor systems related to exhaust emissions control. Over the course of time, re-gional standards were de-rived from this standard (e.g. ISO 15031), which have now been merged again into WWH-OBD. This standard was initiated by

the United Nations and doc-umented in its Global Tech-nical Regulation 5 (GTR 5). ISO 27145 represents the technical implementation of GTR 5. It establishes tech-nical constraints for WWH-OBD. WWH-OBD initially targets the commercial ve-hicle market, but eventual-ly it should be extended to other vehicle industries as well.

ISO 27145 consists of six parts. The current doc-ument status is a Draft In-ternational Standard (DIS), and a final version is antic-ipated by the end of 2011. The first step was to estab-lish requirements for emis-sions control and diagnos-tic communications. This involved specifying the ve-hicle-side implementation, data access and OBD data. At this time, regional au-thorities are still defining limit and threshold values; harmonization will not occur until a later point in time.

For on-board diagnos-tics in commercial vehicles, the two CAN-based proto-cols “Diagnostics on CAN” (ISO 15765-4) and J1939-73 are widely being used to-day. To enable a cost-ef-fective transition to WWH-OBD, diagnostics over CAN will continue to be used at first. For the long term, di-agnostics over the Internet Protocol (DoIP) should also be possible, which would enable access that is either wired over Ethernet or wire-less.

Different than in the current OBD-II standard, WWH-OBD only utilizes services already defined as ISO 14229 Unified Diagnos-tic Services (UDS). No addi-tional OBD-specific servic-es are needed. Specifically, WWH-OBD requires sup-port of the UDS services.

Effective at the begin-ning of 2014, all newly regis-tered heavy-duty commer-cial vehicles must conform to Euro VI standards, and so they must have WWH-OBD diagnostic capabili-ty. Developments involving new types of vehicles must

Fig. 4: The WWH-OBD is specified in ISO 27145

Fig. 5: On-board diagnostics in commercial vehicles is implemented by CAN-based protocols

66 CAN Newsletter 1/2011

Stan

dard

izat

ion

Page 6: Quo vadis SAE J1939 - Semantic Scholar · CAN frame, J1939-21 spec-ifies two transport protocol (TP) variants. These are the broadcast announce message (BAM) variant and connection

!"## $%%&''()!"## %*+,-*#(!"## $%%&''()!"## %*+,-*#(

!"#!$%&'()*+,-./0)(1$234!-53#)&67(83".$291/1 :7;&6$()

1010

545-

CA

NC

AP

TUR

E-C

IA

< ='223($.>)37;3'1)1?3;(7@31/@%2)3.)&67(83$.$291/1&73$A0$.B)A3&(7'C2)1D77&/.>37;3B7@%2)E3191&)@1

< :'%%7(&37;3FGHIH3@'2&/%$B8)&3@)11$>)1?3#+4"JKLLL;$1&3%$B8)&3%(7&7B723$.A3FGHIH3A/$>.71&/B3@)11$>)1

< ='223FGHIH3A$&$C$1)36/&D3MN#3$.A3:M#3/A).&/;/)(1

< :/@%2)?3/.&'/&/0)3'1)(3/.&)(;$B)

< =2)E/C2)3A$&$3;276BD$(&1?36/&D3'.2/@/&)A;'.B&/7.3C27B813$.A3%76)(;'23;'.B&/7.1

< !'1&7@31B(/%&13;7(31%)B/$2/O)A3A$&$3@$./%'2$&/7.

< "%%C'/2A)(3P/O$(A3&73B()$&)3A/$>.71&/B3&7721

< ='223;)$&'()31)&3/.B2'A)A3,3.73)E&($3BD$(>)1

3523 Crosspoint, San Antonio, TX 78217 918.317.2615 www.cancapture.com/CA

QC1)(0)?3$.$29O)?3$.A31'%%2)@).&3A$&$3&($;;/B3/.3!"#3:91&)@136/&D3!"#!$%&'()*+R33=)$&'()13/.B2'A)S

Page 7: Quo vadis SAE J1939 - Semantic Scholar · CAN frame, J1939-21 spec-ifies two transport protocol (TP) variants. These are the broadcast announce message (BAM) variant and connection

Motor control kit. The motor control demonstra-tion kit for brushless DC motors by Renesas costs 119 Euro. It contains the RX62T micro-controller with on-chip CAN module and comes with the nec-essary circuit diagrams as well as the source code for control of brushless mo-tors. The user can thus choose between sensor-less algorithms and appli-cations with Hall sensors or encoders. The kit is pro-vided with a small 24-V BLDC motor.

www.renesas.com

ECU calibration. Vector released the CANape 9.0 software tool for ECU cal-ibration. Its extended mea-surement functionality, in-creased diagnostic capa-bilities and integrated im-age processing simpli-fy optimization of ECU pa-rameters in all motor vehi-cles. In measuring and cal-ibrating ECUs, develop-ers will benefit from sup-port of the new ASAM measurement data format MDF 4.0. CANape can now write measurement files of any desired size, break-ing through the previous 4-GiB barrier. The provid-er has extended the tool’s data mining functions for

automatic and quick evalu-ation of large measurement data recordings. For model-based development of the DLL, a target is provided for Real-Time Workshop from The MathWorks.

www.vector.com

FMS simulator. Au Group Electronics released a new version of its FMS (fleet management system) sim-ulator. The updated tool now simulates all of the common signals defined by both FMS-standard and Bus FMS-standard. It re-flects the parameter up-dates defined by the lat-est FMS-standard 2.0 (Sep-tember 11, 2010). The tool can simulate up to 68 pa-rameters, five of which are modified for updated stan-dards (Ambient Air Tem-perature, Drive 1 Identifica-tion, Drive 2 Identification, Fuel Rate, Instantaneous Fuel Economy). Three new parameters are added for

FMS-Standard (PTO Drive Engagement, High Resolu-tion Fuel Consumption and Engine Load).

www.auelectronics.com

Rest bus simulation. TheSimBox by Telemotive sim-ulates the sending of CAN messages from a virtual ECU. These simulated de-vices could be power win-dows, ignition or a dim-ming sensor. The trans-fer of spontaneous or cycli-cal CAN messages is con-trolled by means of 24 pro-grammable buttons.

www.telemotive.de

Handheld analyzer. Peak introduced a CAN diagnos-tic tool, which measures bit-rates, busloads, and ter-mination resistance. The tool receives messages and transmits single or se-quences of CAN frames. The built-in 2-channel os-cilloscope supports trigger-ing on SOF or EOF. High-

Starter kit andtool news

speed, fault-tolerant, and single-wire transmission is supported.www.peak-system.de

Virtual device develop-ment. Port provides the youCAN development suite for virtual design of CANopen devices. It im-plements the CANopen protocol stack (NMT mas-ter/slave function) and due to the HAL (hardware ab-straction layer), the devel-oped CANopen software can be ported to the target hardware.

www.port.de

HIL simulator. The hard-ware-in-the-loop simula-tors by dSpace are used in the automotive industry (e.g. for the Touareg Hybrid by Volkswagen), and also by motion controller manu-facturers such as LTi. Use cases include CANopen protocol verification.

www.dspace.com

fulfill standards one year earlier by the beginning of 2013.

UDS services can be implemented with CANbed-ded communication soft-ware that also supports J1939, which is available from Vector and is practice-proven in many production implementations. Recently, a production-ready Autosar

solution has also become available for implementing WWH-OBD diagnostics via UDS.

The described devel-opments in the J1939 field show how the standard continues to be adapted to current requirements on a regular basis. The transfer, extension and modification of concepts from passenger

Fig. 6: The WWH-OBD uses the diagnostic services from UDS

car technology aim to make the development of J1939 ECUs more cost-effective. Vector, with its many years of networking expertise, is making a contribution by ac-tively participating in stan-dardization committees. In turn, developers of com-mercial vehicle electronics benefit from early imple-mentation of new standards

in embedded software and development tools. References:[1] http://standards.sae.org[2] “CAN and open protocols in commercial vehicles”, CAN Newsletter 3/2005, pg. 60[3] SAE, J1939-11, Physical layer, 250 kbits/s, Twisted shielded pair[4] SAE, J1939-15, Reduced physical layer, 250 kbits/s, Unshielded twisted pair (UTP)[5] SAE, J1939-13, Off-board diagnostic connector[6] SAE, J1939-81, Network management

[email protected]@vector.com

68 CAN Newsletter 1/2011

Soft

war

e/To

ol