Quo vadis SAE J1939 standardization - CAN Newsletter Online

48 downloads 148 Views 2MB Size Report
within the SAE J1939 work- ing committee, such as the ... Status of SAE J1939 documents (September 2010) has forced .... CAN frame, J1939-21 spec- ifies two  ...

Standardization

Quo vadis SAE J1939 standardization Peter Fellmeth, Holger Söhnle (Vector Informatik)

D

ue to new application layer requirements, SAE is continuing to develop the J1939 standard, which is primarily used to network powertrains in commercial vehicles. However, optimizations and extensions 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 working committee, such as the planned introduction of the 500-kbit/s physical transmission layer and changes to network management. Moreover, it also explains ongoing efforts to standardize J1939 in Autosar Release 4 and WWH-OBD (world-wide harmonized onboard diagnostics) diagnostics. 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 creates a uniform foundation for communication between the electronic ECUs (electronic control unit) and op-

62

erates by the plug-and-play principle. The J1939 standard is an active standard that currently consists of 19 documents. The responsible 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 maximum 250-kbit/s bandwidth specified in the standard

Status of SAE J1939 documents (September 2010)

CAN Newsletter 1/2011

has forced commercial vehicle developers to work at the limits of performance [2]. From a communication perspective, development of the 500-kbit/s data transport layer is a long overdue step. European commercial vehicle producers in particular are seeking a final decision in the near future. The specification will be released in a separate document, J1939-14, and its key aspects are: X Twice the bit-rate, 500 kbit/s instead of 250 kbit/s X Use of shielded and unshielded cable as defined in [2] and [3] is still possible X Topology is essentially a bus that has branch lines with a max. length of 1 m. To connect diagnostic

Microcontrollers

Digital Signal Controllers

Analog Memory

RF & Wireless

Standardization

X

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 characteristic impedance of 120 Ÿ. Up to 30 nodes are possible.

The specification for the diagnostic plug [4] was adapted 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” diagnostic plug. A “Type II” plug is compatible with a “Type I” socket. Another change is that the “Type II” diagnostic socket defines pins previously used for SAE J1708/ J1587 as reserved. Consequently, a J1708-/J1587-network can no longer be addressed via a “Type II” diagnostic plug.

SAE gets serious about dynamics Changes are also being made in the area of Network Management [5]. For a long time now, the J1939-committee has been deliberating over ways to handle the short supply of permanently assigned ECU addresses. This is especially problematic for manufacturers

of sensors with a direct bus connection. The number of new devices is growing rapidly due to heightened exhaust emissions requirements and the addition of assistance systems. Many alternatives were proposed but then rejected. They ranged from a dedicated network for sensors to implementation of a new protocol – e.g. by using previously reserved data pages. Meanwhile, the fact was that SAE has not assigned any more new addresses. That was an unsatisfactory situation for ECU suppliers. Often, they did not know whether their product designs would have lasting value. In the latest version of Network Management, SAE recommends implementing “Address Arbitrary 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 address allocation that has always existed in the commercial vehicle field, but has never really been implemented or used before. In conjunction with Network Management, the newly added Name Management should be mentioned for the sake of completeness. This is a standardized interface for changing

Fig. 2: Layout of a 29-bit CAN-ID in J1939 networks specific components of the 64-bit device name. This might be necessary if the relevant function or measurement parameter is derived from the device name. So, the device name can be used to identify the position of an exhaust gas temperature 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 example, in a case where multiple ECUs of a network need to be assigned a new function simultaneously.

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

64

CAN Newsletter 1/2011

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 together The introduction of Autosar in the passenger car industry is ramping up quickly. Yet, there is also interest in exploiting the benefits of Autosar in commercial vehicle and the agricultural machine markets. However, the special requirements of these markets have not been a focus in the development of Autosar. Therefore, 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 contrast to the “dynamic” behavior of J1939. The Autosar architecture only allows fixed CAN-IDs (identifiers), i.e. there is a fixed allocation 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,

,).58DEVICEDRIVER AVAILABLE

You CAN get it Hardware & software for CAN bus applications…

3&$15RXWHU3UR XWHU3UR

3&$186%3UR

#ONÚGURABLEFOURCHANNEL LEFOURCHANNEL #!.ROUTERWITHDATA WITHDATA LOGGERINCLCONÚGURATION SOFTWARE

(IGH SPEED53" INTERFACEWITHGALVANIC WITHGALVANIC FORCONNECTINGUP ISOLATIONFORCONNECTINGUP AND,).BUSSES TO#!.AND,).BUSSES

3&$1'LDJ 3&

3&$13&,([SUHVV

3&$1*356/LQN

#!.INTERFACEFOR0#) %XPRESSSYSTEMS!VAILABLE AS CHANNEL  CHANNEL ANDOPTO ISOLATEDVERSION

$EVELOPMENTPLATFORM WITH#!. '03 AND'023 )NTERPRETATIONOF/"$   &-3 $4#/ #I!†

0#!. $IAGISAHANDHELD#!.BUSDIAGNOSTICSUNIT4HENEW 0# MODELOFFERSENHANCEDFUNCTIONALITY MO #LEAR#!.TRAFÚCREPRESENTATIONINLISTS CONÚGURABLE SYMBOLICREPRESENTATIONOFRECEIVEDMESSAGES 4RANSMISSIONOFINDIVIDUAL#!.FRAMESOR#!.FRAMELISTS "UILT IN CHANNELOSCILLOSCOPEFORDETAILEDANALYSISOF THEDIFFERENTIAL#!.SIGNALORANOPTIONALEXTERNALSIGNAL  TRIGGERINGBY#!.)$SOROTHEREVENTS "ITRATEDETECTION BUSLOADANDTERMINATIONMEASUREMENT 7INDOWS†SOFTWAREFOREASYDEVICECONÚGURATIONAND TRANSMITLISTDEÚNITION UPLOADVIA53"CONNECTION 3TORAGEOFDIAGNOSTICRESULTS#36 "-0 ONANINTERNAL '"MASSSTORAGE53"DEVICE

3&$1([SUHVV&DUG

3&$13&,([SUHVV

#!.INTERFACEFOR%XPRESS #ARDSLOTS!VAILABLEAS  CHANNEL  CHANNEL AND OPTO ISOLATEDVERSION

#!.INTERFACEFOR0#) %XPRESSSLOTS!VAILABLE AS CHANNEL  CHANNEL ANDOPTO ISOLATEDVERSION

4HEUNIVERSALTOOLFORDEVELOPINGANDMONITORING#!. NETWORKS %XTENSIVEUSERINTERFACEIMPROVEMENTS&ILEMANAGE MENTVIAPROJECTS CONÚGURATIONOFALLELEMENTSWITHTHE PROPERTYEDITOR ANDWINDOWARRANGEMENTUSINGTABS 3IMULTANEOUSCONNECTIONSWITHMULTIPLENETWORKS#!. INTERFACESOFTHESAMEHARDWARETYPE #ONÚGURABLESYMBOLICMESSAGEREPRESENTATION $ATALOGGINGWITHTRACERSANDTHE CHANNEL,INE7RITER 6"3CRIPTINTERFACEFORTHECREATIONOFMACROS &UNCTIONALITYUPGRADESWITHADD INSEG-!DD IN 5SERINTERFACELANGUAGEIN%NGLISHOR'ERMAN

3&$1F3&, #!.INTERFACEFORC0#) SLOTS!VAILABLEAS  CHANNELAND CHANNEL OPTO ISOLATEDVERSIONS

www.peak-system.com /TTO 2OEHM 3TRq$ARMSTADT'ERMANY 0HONE  q&AX  q% MAILINFO PEAK SYSTEMCOM

7 RX DN WK U H H Z D VD LQ HE OR O H WH V RN V UQ LWH D SD D I W U W WLR RU Q H QD UV O

3&$1([SORUHU

Standardization

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 dynamic CAN-ID can be modeled in Autosar by creating a separate static CAN-ID for each combination of priority, 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 already 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 addresses are fixed. Therefore source and destination addresses are fixed, and so it is possible to work with static CAN-IDs. To transmit data that is longer than the 8 bytes available in a CAN frame, J1939-21 specifies 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 commercial vehicle producers.

Fig. 4: The WWH-OBD is specified in ISO 27145 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 vehicle OEMs (original equipment manufacturer). The primary extended features being added to Autosar: X Support of multiple messages with the same layout (the same parameter group) X Network M anagement per SAE J1939/81 without dynamic NM, i.e. without AAC (arbitrary address capable) X Responses to a request message X Support for diagnostic services X On-board diagnostics (WWH-OBD) via J1939 Together with large European commercial vehicle

OEMs Vector actively participates in efforts to specify these J1939 extensions for Autosar. Today, Vector already offers an Autosar solution with a J1939 extension based on Autosar release 4.0. It will soon be used in production at one large European commercial vehicle OEM. The extension for Autosar release 4.1 is currently in the development stage.

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

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

66

CAN Newsletter 1/2011

the United Nations and documented in its Global Technical Regulation 5 (GTR 5). ISO 27145 represents the technical implementation of GTR 5. It establishes technical constraints for WWHOBD. WWH-OBD initially targets the commercial vehicle market, but eventually it should be extended to other vehicle industries as well. ISO 27145 consists of six parts. The current document status is a Draft International Standard (DIS), and a final version is anticipated by the end of 2011. The first step was to establish requirements for emissions control and diagnostic communications. This involved specifying the vehicle-side implementation, data access and OBD data. At this time, regional authorities are still defining limit and threshold values; harmonization will not occur until a later point in time. For on-board diagnostics in commercial vehicles, the two CAN-based protocols “Diagnostics on CAN” (ISO 15765-4) and J1939-73 are widely being used today. To enable a cost-effective transition to WWHOBD, diagnostics over CAN will continue to be used at first. For the long term, diagnostics over the Internet Protocol (DoIP) should also be possible, which would enable access that is either wired over Ethernet or wireless. Different than in the current OBD-II standard, WWH-OBD only utilizes services already defined as ISO 14229 Unified Diagnostic Services (UDS). No additional OBD-specific services are needed. Specifically, WWH-OBD requires support of the UDS services. Effective at the beginning of 2014, all newly registered heavy-duty commercial vehicles must conform to Euro VI standards, and so they must have WWHOBD diagnostic capability. Developments involving new types of vehicles must

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

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

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

< ='223($.>)37;3'1)1?3;([email protected]/@%2)3.)&67(83$.$291/1

< =2)E/C2)3A$&$3;276BD$(&1?36/&D3'.2/@/&)A

< :'%%7(&37;[email protected]'2&/%$B8)[email protected])11$>)1?3#+4"JKLLL

< !'[email protected](/%&13;7(31%)B/$2/O)A3A$&$3

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

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

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

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

;$1&3%$B8)&3%(7&7B723$.A3FGHIH3A/$>.71&/[email protected])11$>)1

;'.B&/7.3C27B813$.A3%76)(;'23;'.B&/7.1 @$./%'2$&/7.

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

1010545-CANCAPTURE-CIA

&73$A0$.B)A3&(7'C2)1D77&/.>37;[email protected]%2)E3191&)@1

Software/Tool

in embedded software and development tools.

Fig. 6: The WWH-OBD uses the diagnostic services from UDS fulfill standards one year earlier by the beginning of 2013. UDS services can be implemented with CANbedded communication software that also supports J1939, which is available from Vector and is practiceproven in many production implementations. Recently, a production-ready Autosar

solution has also become available for implementing WWH-OBD diagnostics via UDS. The described developments 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

Motor control kit. The motor control demonstration 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 necessary circuit diagrams as well as the source code for control of brushless motors. The user can thus choose between sensorless algorithms and applications with Hall sensors or encoders. The kit is provided with a small 24-V BLDC motor. www.renesas.com

automatic and quick evaluation of large measurement data recordings. For modelbased development of the DLL, a target is provided for Real-Time Workshop from The MathWorks. www.vector.com

ECU calibration. Vector released the CANape 9.0 software tool for ECU calibration. Its extended measurement functionality, increased diagnostic capabilities and integrated image processing simplify optimization of ECU parameters in all motor vehicles. In measuring and calibrating ECUs, developers will benefit from support of the new ASAM measurement data format MDF 4.0. CANape can now write measurement files of any desired size, breaking through the previous 4-GiB barrier. The provider has extended the tool’s data mining functions for

FMS simulator. Au Group Electronics released a new version of its FMS (fleet management system) simulator. The updated tool now simulates all of the common signals defined by both FMS-standard and Bus FMS-standard. It reflects the parameter updates defined by the latest FMS-standard 2.0 (September 11, 2010). The tool can simulate up to 68 parameters, five of which are modified for updated standards (Ambient Air Temperature, Drive 1 Identification, Drive 2 Identification, Fuel Rate, Instantaneous Fuel Economy). Three new parameters are added for

68

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 actively participating in standardization committees. In turn, developers of commercial vehicle electronics benefit from early implementation of new standards

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] [email protected]

Starter kit and tool news FMS-Standard (PTO Drive Engagement, High Resolution Fuel Consumption and Engine Load). www.auelectronics.com

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

Rest bus simulation. The SimBox by Telemotive simulates the sending of CAN messages from a virtual ECU. These simulated devices could be power windows, ignition or a dimming sensor. The transfer of spontaneous or cyclical CAN messages is controlled by means of 24 programmable buttons. www.telemotive.de

Virtual device development. Port provides the youCAN development suite for virtual design of CANopen devices. It implements the CANopen protocol stack (NMT master/slave function) and due to the HAL (hardware abstraction layer), the developed CANopen software can be ported to the target hardware. www.port.de

Handheld analyzer. Peak introduced a CAN diagnostic tool, which measures bitrates, busloads, and termination resistance. The tool receives messages and transmits single or sequences of CAN frames. The built-in 2-channel oscilloscope supports triggering on SOF or EOF. High-

HIL simulator. The hardware-in-the-loop simulators by dSpace are used in the automotive industry (e.g. for the Touareg Hybrid by Volkswagen), and also by motion controller manufacturers such as LTi. Use cases include CANopen protocol verification. www.dspace.com

CAN Newsletter 1/2011