Mapping of J1939 to CAN FD

CAN FD

CiA members have mapped SAE’s J1939 application profile to the

CAN FD data link layer. The related CiA 602-2 specification will be
released soon.

T he J1939-21 application layer

specifies how to use the CAN-
ID and the protocol that transmits the
Parameter Groups (PG). The PGs and
the single parameters are described
in SAE J1939-71. Traditionally, the
J1939 application profile is mapped to
the Classical Extended Frame Format
(CEFF) data link layer protocol using
the 29-bit CAN-ID.
Some European OEMs (original Figure 1: The Multi-PDU as defined in CiA 602-2 can be mapped into 11-bit as
equipment manufacturer) of trucks need well as 29-bit CAN FD messages; the J1939 C-PDU contains one Parameter
more bandwidth on their CAN-based Group and a 32-bit header compliant with Autosar
in-vehicle networks. Additionally, they
require higher throughput when downloading software or The 11-bit CAN-ID provides the 8-bit SA and the 3-bit
uploading diagnostic data. For this reason, some CiA mem- Protocol Indicator (PI). The PI distinguishes between Multi-
bers have started to specify the mapping of J1939 messag- PDU container (Autosar compliant), Autosar CAN-NM (net-
es to CAN FD. It is intended to run the communication at work management), SAE address claiming, XCP (extend-
higher bit-rates (e.g. 2 Mbit/s) and to use the extended pay- ed calibration protocol), J1939 TP connection management
load of up to 64 byte. (TP.CM), J1939 TP data transfer (TP.DT), and TP extended
Another requirement of the OEMs is the compatibil- addressing functional as well as physical (both are defined
ity to Autosar. In order to allow a simple mapping of PGs in ISO 15765-2). The usage of 29-bit CAN-IDs is specified,
as defined in J1939-71, a Multi-PDU (process data unit) is too. However, this would eat some bandwidth due to the
used in the CiA 602-2 specification. Such a Multi-PDU can longer arbitration phase (about 20 bit-times not consider-
comprise several C-PDUs (Contained PDU). The C-PDU ing stuff-bits). For this approach, CiA needs to request ded-
combines a PG and a 4-byte (short) header as described in icated PDU 1s and PDU 2s from SAE, which is still on the
Autosar. A legacy PG is always 8 byte long. This means you “to do” list.
can map in maximum five traditional PGs into one 64-byte The usage of a security/safety trailer is indicated by
CAN FD data frame considering the header. In the future, the 3-bit TL (trailer length) sub-field. There may be no trail-
there may also be shorter and longer PGs, which gives the er, either a security or a safety trailer (32 bit or 64 bit), or a
user more mapping flexibility. Of course this approach is combined security/safety trailer (32 bit + 32 bit). These are
a compromise. It requires some protocol overhead: 4 byte placeholders, because the definition of security and safety
per C-PDU. protocols is not in the scope of CiA 602-2.
FD Base Frame Format (FBFF) as well as FD Extended The mapping of the BAM or CMDT protocols as speci-
Frame Format (FEFF) messages are supported. The 11-bit fied in J1939-21 into CEFF messages will not be changed,
CAN-ID has the benefit that the “slow” arbitration phase is meaning the DLC (data length code) is always 8. The
as short as possible. In both approaches, the CAN-ID con-
tains the J1939 source address (SA). The J1939 PDU for-
mat and the PDU specific are part of the Autosar PDU short
header. Consequently, ECUs (electronic control unit) need
to parse all messages. Normally, CAN acceptance hard-
ware filters cannot be used.
Besides the J1939-21 information (PDUF and PDUS),
the C-PDU header also comprises a 3-bit Type of Services
(TOS) field, a 3-bit information about the optional safety/
security “trailer”, and an 8-bit PG length indication (neces-
sary, when other than 8-byte PGs are used). With this infor-
mation, the receiver can interpret the received C-PDU. Figure 2: Test set-up for the proof of concept

30 CAN Newsletter 2/2016

mapping of these protocols to FBFF and FEFF messages is
under development. The idea is to extend the TP.DT frame
to 64 byte using 63 byte for the payload and one byte for a
sequence counter. The total message size would be 16065
byte (255 x 63 byte).

Proof of concept
CiA
CAN in Automation

The concept of CiA 602-2 has been proofed by Vector

and ZF. They simulated a traditional truck communica-
tion between ECUs. They opened the simulated J1939 16th international
CAN Conference
network, introduced a simulated CiA 602-2 network using
500 kbit/s in the arbitration phase and 2 Mbit/s in the data-
phase. The two bridges mapped the received J1939 mes-
sages into Multi-PDUs and sent them on the CAN FD
network and vice versa. The time waiting on J1939 mes- Historical City Hall, Nuremberg (DE),
sages was increased in order to optimize the mapping of March 7 - 8, 2017
C-PDUs. This improved the achieved protocol efficiency,
because most of the CAN FD messages used the maxi-
mum possible payload. On the other hand, when waiting
to long, there was some time-outs on the application level.
This straightforward implementation is not really opti-
Call for papers
mized by any means. It is just based on existing J1939
application software. The simulation was compared with CiA, the international users and
the results in a real truck: The J1939 network was opened, manufacturers group for CAN, will
two CAN FD bridges introduced, which communicated via organize the 16th iCC in Nuremberg (DE),
a real CAN FD network. The results were the same as the March 7 - 8, 2017 in conjunction with its
simulated ones. There was a throughput win of about 80 %.
25 years anniversary.
The busload decreased from above 50 % to less than 10 %.
Of course, not just the data-phase speed was increased Topics of the 16th international CAN
to 2 Mbit/s, the arbitration bit-rate was also doubled (from Conference (the term CAN includes
250 kbit/s to 500 kbit/s). Optimization regarding the periodic
CAN FD and classical CAN):
transmission, the length of PGs, and the usage of Change-
of-State triggering can additionally decrease the busload.

Summary and outlook

The CiA 602-2 specification will be released soon as a Draft

Standard Proposal (DSP). It can be used with unchanged
J1939 application software, just adding a small bridge pro-
gram mapping the PGs into Multi-PDUs. Additionally, the
CiA 602-2 protocol stack can also accelerate the down-
load of application software and calibration data as well
as the uploading of diagnostic information. The CiA 602-2
protocols can also be used for other J1939-based solu-
tions such as Isobus (ISO 11783 series) and NMEA 2000
(IEC 61162-3). In the “CAN 2020” seminars (free-of-charge
for CiA members), they are a topic, too.

Please submit your abstract (not more

than 200 words) before
September 16, 2016.
Author
The conference language is English.
Holger Zeltwanger
CAN in Automation
[email protected]
www.can-cia.org For more details please contact the CiA office at
[email protected]

www.can-cia.org