ISO 11783-3:2018

Tractors and machinery for agriculture and forestry - Serial control and communications data network - Part 3: Data link layer

This document specifies the application, the network layer protocols and the mapping to the controller area network (CAN) data link layer protocol as specified in ISO 11898-1. The application layer specifies protocol data units (PDU), which can be mapped to Classical CAN data frames using the Classical Extended Frame Format (CEFF). For PDUs exceeding the length of the CEFF-formatted data frames, this document specifies transport layer protocols and the mapping to CEFF-formatted data frames.

Tracteurs et matériels agricoles et forestiers — Réseaux de commande et de communication de données en série — Partie 3: Couche liaison de données

Le présent document spécifie l'application, les protocoles de couche réseau et le mappage avec le protocole de couche de liaison de données CAN (controller area network) comme spécifié dans l'ISO 11898‑1. La couche d'application spécifie les unités de données de protocole (PDU), qui peuvent être mappées aux trames de données CAN classiques à l'aide du format CEFF (Classical Extended Frame Format). Pour les PDU dépassant la longueur des trames de données formatées CEFF, ce document spécifie les protocoles de la couche transport et le mappage aux trames de données formatées CEFF.

General Information

• Status: Published
• Publication Date: 01-Nov-2018
• ICS: 35.240.99 - IT applications in other fields
• ICS: 65.060.01 - Agricultural machines and equipment in general
• Technical Committee: ISO/TC 23/SC 19 - Agricultural electronics
• Drafting Committee: ISO/TC 23/SC 19/WG 1 - Applications and data interfaces
• Current Stage: 9092 - International Standard to be revised
• Start Date: 26-Jun-2024
• Completion Date: 13-Dec-2025

Relations

• Revised: ISO/FDIS 11783-3 - Tractors and machinery for agriculture and forestry - Serial control and communications data network - Part 3: Application layer, transport layer and network layer
• Effective Date: 29-Jun-2024
• Revises: ISO 11783-3:2014 - Tractors and machinery for agriculture and forestry - Serial control and communications data network - Part 3: Data link layer
• Effective Date: 23-Apr-2016

Overview

ISO 11783-3:2018 - "Tractors and machinery for agriculture and forestry - Serial control and communications data network - Part 3: Data link layer" defines how agricultural and forestry vehicle electronics map application- and network-layer messages onto the Controller Area Network (CAN) data link specified in ISO 11898-1. Part 3 specifies Protocol Data Units (PDUs), message frame formats using the Classical Extended Frame Format (CEFF), and transport-layer mechanisms for PDUs that exceed a single CAN frame. The 2018 fourth edition updates the mapping rules (notably excluding CAN FD usage) and refines transport behaviour (e.g., BAM.TP timing).

Key Topics

• Message frame format: Mapping ISO 11783 PDUs to CAN CEFF frames and support rules for identifier types.
• Protocol Data Unit (PDU): Structure and fields (priority, extended data page, data page, PDU format, PDU specific, source address, data field).
• PDU formats and Parameter Group Numbers (PGN): How PGNs identify message semantics and addressability.
• Message types: Command, Request, Broadcast/Response, Acknowledgement, Group function, Request2, Transfer and their handling rules.
• Transport protocols: Connection-mode transport protocol (TP) and Extended Transport Protocol (ETP) for multi-frame message segmentation, connection management, and reassembly.
• Bus access and arbitration: Priority-based access and contention resolution consistent with CAN arbitration.
• Error detection and timing: Requirements for robust communication, timeout/default response behavior and recommended scheduling.
• Address and PGN assignment: Criteria and processes for Source Address (SA) and PGN allocation.
• Informative annexes: Examples of receive routines, transport sequences, communication modes and bandwidth utilization.

Applications

ISO 11783-3 is essential for anyone building or integrating vehicle electronics for agricultural and forestry machinery. Typical users:

• ECU designers and firmware developers implementing CAN communications for tractors, implements and harvesters.
• System integrators and OEMs ensuring interoperability between control units from different suppliers.
• Test labs validating message formats, transport protocol conformance and network behavior.
• Telematics and precision agriculture solution providers that rely on standardized on-board data exchange.

Benefits include open interoperability, reuse of SAE J1939 concepts adapted for agriculture, and a standardized transport mechanism for larger messages.

Related Standards

• ISO 11783-1 (General standard for mobile data communication)
• ISO 11783-5 (Network management)
• ISO 11783-7 (Implement messages application layer)
• ISO 11898-1 (CAN data link layer and physical signalling)
• ISO 15765-2 (Diagnostic communication over CAN - transport protocol)

Keywords: ISO 11783-3, CEFF, CAN, ISO 11898-1, PDU, PGN, transport protocol, agricultural electronics, ECU interoperability, tractor data network.

Standards Content (Sample)

INTERNATIONAL ISO
STANDARD 11783-3
Fourth edition
2018-11
Tractors and machinery for
agriculture and forestry — Serial
control and communications data
network —
Part 3:
Data link layer
Tracteurs et matériels agricoles et forestiers — Réseaux de
commande et de communication de données en série —
Partie 3: Couche liaison de données
Reference number
©
ISO 2018
© ISO 2018
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting
on the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address
below or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: [phone]
Fax: [phone]
Email: [e-mail]
Website: www.iso.org
Published in Switzerland
ii © ISO 2018 – All rights reserved

Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 General description . 1
5 Technical requirements . 2
5.1 Message frame format . 2
5.1.1 General. 2
5.1.2 Message frame format according to ISO 11783 (ISO 11898-1 CEFF) . 2
5.1.3 Parameter group numbers (PGN) . 6
5.1.4 ISO 11783 support of ISO 11898-1 CBFF messages . 7
5.2 Protocol data unit (PDU) . 8
5.2.1 General. 8
5.2.2 Priority (P) . 8
5.2.3 Extended data page (EDP) . 8
5.2.4 Data page (DP) . 8
5.2.5 PDU format (PF) . 9
5.2.6 PDU Specific (PS) . 9
5.2.7 Source address (SA) .10
5.2.8 Data field .10
5.3 Protocol data unit (PDU) formats .11
5.3.1 General.11
5.3.2 PDU1 format .11
5.3.3 PDU2 format .12
5.4 Message types .13
5.4.1 General.13
5.4.2 Command .14
5.4.3 Request .14
5.4.4 Broadcast/Response .16
5.4.5 Acknowledgement .16
5.4.6 Group function .22
5.4.7 Request2 .24
5.4.8 Transfer .26
5.5 Message priority .27
5.6 Bus access .27
5.7 Contention-based arbitration.27
5.8 Error detection .28
5.9 Assignment process for SA and PGN .28
5.9.1 General.28
5.9.2 Address assignment criteria .28
5.9.3 Parameter group assignment criteria .29
5.9.4 Data field definition .29
5.10 Transport protocol functions .31
5.10.1 General.31
5.10.2 “Packetization” and reassembly .31
5.10.3 Transport Protocol — Connection management .32
5.10.4 Transport Protocol — Connection management messages (TP.CM) .34
5.10.5 Transport Protocol — Data Transfer messages (TP.DT) .38
5.10.6 Transport Protocol Connection constraints .39
5.11 Extended transport protocol functions .40
5.11.1 Overview .40
5.11.2 General.40
5.11.3 Message packets .40
5.11.4 Extended Transport Protocol — Connection Management .40
5.11.5 Extended Transport Protocol — Connection Management messages (ETP.CM) .42
5.11.6 Extended Transport Protocol — Data Transfer messages (ETP.DT) .45
5.11.7 Extended Transport Protocol — Connection constraints .45
5.12 PDU processing requirements .45
5.13 Application notes .46
5.13.1 High data rates .46
5.13.2 Request scheduling .46
5.13.3 Controller response time and timeout defaults .46
5.13.4 Required responses .47
5.13.5 Transmission of PGN to specific or global destinations .47
5.13.6 CTS number of packet recommendation.47
Annex A (informative) ISO 11783 PDU processing — Typical receive routine .48
Annex B (informative) Transport protocol transfer sequences — Examples of connection
mode data transfer .50
Annex C (informative) Communication mode examples .59
Annex D (informative) Network bandwidth utilization .61
Bibliography .62
iv © ISO 2018 – All rights reserved

Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.
ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of
electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the
different types of ISO documents should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www .iso .org/directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of
any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www .iso .org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to the
World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT) see www .iso
.org/iso/foreword .html.
This document was prepared by Technical Committee ISO/TC 23, Tractors and machinery for agriculture
and forestry, Subcommittee SC 19, Agricultural electronics.
This fourth edition cancels and replaces the third edition (ISO 11783-3:2014), which has been
technically revised. The main changes compared to the previous edition are as follows:
— updates wording with respect to ISO 11898-1 (exclude the usage of CAN Flexible Data Rate);
— allows BAM.TP to be sent with 10 ms;
— ACKNOWLEDGEMENT PG supports Extended Identifier Type when Request2 utilizes it.
A list of all parts in the ISO 11783 series can be found on the ISO website.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www .iso .org/members .html.
Introduction
ISO 11783 specifies a communications system for agricultural equipment based on the ISO 11898-1 CAN
1)
protocol. SAE J 1939 documents , on which parts of ISO 11783 are based, were developed jointly for use
in truck and bus applications and for construction and agriculture applications. Joint documents have
been completed to allow electronic units that meet the truck and bus SAE J 1939 specifications to be
used by agricultural and forestry equipment with minimal changes. General information on ISO 11783
can be found in ISO 11783-1.
The purpose of ISO 11783 is to provide an open, interconnected system for on-board electronic systems.
It is intended to enable electronic control units (ECUs) to communicate with each other, providing a
standardized system.
1) Society of automotive engineers.
vi © ISO 2018 – All rights reserved

INTERNATIONAL STANDARD ISO 11783-3:2018(E)
Tractors and machinery for agriculture and forestry —
Serial control and communications data network —
Part 3:
Data link layer
1 Scope
This document specifies the application, the network layer protocols and the mapping to the controller
area network (CAN) data link layer protocol as specified in ISO 11898-1. The application layer specifies
protocol data units (PDU), which can be mapped to Classical CAN data frames using the Classical
Extended Frame Format (CEFF). For PDUs exceeding the length of the CEFF-formatted data frames, this
document specifies transport layer protocols and the mapping to CEFF-formatted data frames.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ISO 11783-1, Tractors and machinery for agriculture and forestry — Serial control and communications
data network — Part 1: General standard for mobile data communication
ISO 11783-5, Tractors and machinery for agriculture and forestry — Serial control and communications
data network — Part 5: Network management
ISO 11783-7, Tractors and machinery for agriculture and forestry — Serial control and communications
data network — Part 7: Implement messages application layer
ISO 11898-1, Road vehicles — Controller area network (CAN) — Part 1: Data link layer and physical
signalling
ISO 15765-2, Road vehicles — Diagnostic communication over Controller Area Network (DoCAN) — Part 2:
Transport protocol and network layer services
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 11783-1 and ISO 11898-1 apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https: //www .iso .org/obp
— IEC Electropedia: available at http: //www .electropedia .org/
4 General description
The data link layer enables the reliable transfer of data across the physical link. This consists of sending
the CAN classical data frame with the necessary synchronization, sequence control, error control and
flow control. The flow control is accomplished through a consistent message frame format.
5 Technical requirements
5.1 Message frame format
5.1.1 General
The message frame format shall conform to the CAN requirements. The CAN specification referenced
throughout this document is specified in ISO 11898-1. When there are differences between the CAN
specification and this document, this document shall be the governing document.
The CAN document specifies, in an information-routing-related discussion, that control function
addresses are not used. While this is true for some applications of CAN, it is not true for ISO 11783.
The definition of the ISO 11783 network requires that control function addressing be used to prevent
multiple control functions from using the same CAN identifier field. Many additional requirements exist
in ISO 11783 that are not specified by CAN.
ISO 11898-1 specifies two classical frame formats: Classical Basic Frame Format (CBFF) and CEFF.
ISO 11898-1 compatibility implies that messages of both formats can potentially be present on a single
network, by using certain bit coding which allows for the recognition of the different formats. Up to this
point, ISO 11783 also accommodates both message frame formats. However, ISO 11783 only defines a
full strategy for standardized communications using the CEFF. All CBFF messages are for proprietary
use following the rules defined in this document. Any FD Frame Format shall not be used on the
ISO 11783 network.
ISO 11783 controllers shall therefore use the CEFF. CBFF messages may reside on the network, but only
in accordance with this document.
The classical CAN data frame is parsed into different bit fields, as shown in Figure 1. The number and
parsing of the bits in the arbitration and control field differs between the CBFF and CEFF messages.
CBFF messages, as shown in Figure 1 a), contain 11 identifier bits in the arbitration field, whereas the
arbitration field of CEFF messages, as shown in Figure 1 b), contain 29 identifier bits. ISO 11783 has
further defined the identifier bits in the arbitration field of the CAN message frame formats. These
definitions are given in Table 1.
5.1.2 Message frame format according to ISO 11783 (ISO 11898-1 CEFF)
The CEFF message, illustrated by Figure 1, encompasses a single protocol data unit (PDU). The PDU
consists of seven predefined fields, assimilated from information provided by the application layer:
— Priority;
— Extended Data Page (EDP);
— Data Page (DP);
— PDU Format (PF),
— PDU Specific (PS), which can be Destination Address (DA), Group Extension (GE) or proprietary;
— Source Address (SA);
— Data.
See 5.2 for a detailed description of each field and 5.3 for PDU formats.
2 © ISO 2018 – All rights reserved

a) Classical Base Frame Format (CBFF)
b) Classical Extended Frame Format (CEFF)
Figure 1 — Classical CAN data frames
The fields are then packaged into one classical CAN data frame and sent over the physical media to
other network controllers. The layers of the OSI model that ISO 11783 supports are shown in Figure 2.
It is possible that some parameter group definitions require more than one classical CAN data frame in
order to send their information.
Figure 2 — Application of OSI model according to ISO 11783
Table 1 shows the arbitration and control fields of the 29 bit identifier for CAN, 29 bit identifier for
ISO 11783 and 11 bit identifier for CAN, and the use of the 11 bit identifier on an ISO 11783 network.
A complete definition for each of the bit field assignments according to ISO 11783 is given in 5.3. In
ISO 11783, the CAN data frame data field is described as Bytes 1 to 8. Byte 1’s MSB (most significant
bit), Bit 8, is the first bit sent closest to the data length code (DLC). Byte 8’s LSB (least significant bit),
Bit 1, is the last of the data bits to be sent and is closest to the cyclic redundancy check (CRC) field. See
Figure 3.
When the extended data page (EDP) is equal to 1 and the data page (DP) is equal to 1, the CAN frame
is identified as an ISO 15765-2 formatted frame. ISO 15765-2 specifies diagnostic communication
4 © ISO 2018 – All rights reserved

over CAN (DoCAN). Therefore, the processing of this specific CAN frame format does not follow the
definitions specified in ISO 11783 and shall be in accordance with ISO 15765-2 (see 5.2.4).
Table 1 — Mapping of ISO 11783 into CAN arbitration and control fields
29 bit identifier 11 bit identifier
Bit number
b
CAN ISO 11783 CAN ISO 11783
a a
1 SOF SOF SOF SOF
2 ID28 P3 ID28 P3
3 ID27 P2 ID27 P2
4 ID26 P1 ID26 P1
a
5 ID25 EDP ID25 ID8
a
6 ID24 DP ID24 ID7
a
7 ID23 PF8 ID23 ID6
a
8 ID22 PF7 ID22 ID5
a
9 ID21 PF6 ID21 ID4
a
10 ID20 PF5 ID20 ID3
a
11 ID19 PF4 ID19 ID2
a
12 ID18 PF3 ID18 ID1
a a
13 SRR (r) SRR RTR (x) RTR (d)
a a
14 IDE (r) IDE IDE (d) IDE
a
15 ID17 PF2 FDF (d) FDF
16 ID16 PF1 DLC4 DLC4
17 ID15 PS8 DLC3 DLC3
18 ID14 PS7 DLC2 DLC2
19 ID13 PS6 DLC1 DLC1
20 ID12 PS5
21 ID11 PS4
22 ID10 PS3
23 ID9 PS2
24 ID8 PS1
25 ID7 SA8
26 ID6 SA7
27 ID5 SA6
28 ID4 SA5
29 ID3 SA4
30 ID2 SA3
31 ID1 SA2
32 ID0 SA1
a
33 RTR (x) RTR (d)
a
34 FDF (x) FDF (d)
a
35 r0 (d) r0
Table 1 (continued)
29 bit identifier 11 bit identifier
Bit number
b
CAN ISO 11783 CAN ISO 11783
36 DLC4 DLC4
37 DLC3 DLC3
38 DLC2 DLC2
39 DLC1 DLC1
SOF Start of Frame bit EDP Extended Data Page according to ISO 11783
Source Address bit number (#) according to
ID## Identifier bit number (#) SA#
ISO 11783
SRR Substitute Remote Request DP Data Page according to ISO 11783
PDU Format bit number (#) according to
RTR Remote Transmission Request bit PF#
ISO 11783
PDU Specific bit number (#) according to
IDE Identifier Extension bit PS#
ISO 11783
FDF FD Format Indicator (d) dominant bit
r# CAN reserved bit number (#) (r) recessive bit
DLC# Data Length Code bit number (#) (x) bit state dependent on message
P# Priority bit number (#) according to ISO 11783
a
CAN-defined bit, unchanged in ISO 11783.
b
Required format of proprietary 11 bit identifiers.
Figure 3 — Classical CAN data field
5.1.3 Parameter group numbers (PGN)
Whenever it is necessary to identify a parameter group in the data field of a classical CAN data frame,
this is expressed in 24 bit. The 24 bit value is sent the least significant byte (LSB) first (see Table 2), also
according to which the most significant byte (MSB) is sent third and the middle byte second and the
LSB first. The 24 bit PGN is determined from the following constituent components: 6 bit set to zero,
Extended Data Page bit, Data Page bit, PDU Format field (8 bit), and PDU Specific field (8 bit).
The procedure for the bit fields to be converted to PGN is as follows. The six MSB of the PGN are set
to zero. Then the Extended Data Page bit, Data Page bit and PDU Format field are copied into the next
10 bit. If the PF value is less than 240 (F0 ) then the LSB of the PGN is set to zero. Otherwise, it is set
6 © ISO 2018 – All rights reserved

to the value of the PS field. See Table 2 for an illustration of the PGN, their corresponding bits and their
conversion to a decimal number.
NOTE Not all 131 072 combinations (2 ) are available to be assigned as PGN. Only a total of
8 672 combinations are available for assignment {calculated as: 2 pages × [240 + (16 × 256)] = 8 672}, using the
conventions specified in this document. See ISO 11783-1 for the latest PGN assignments.
Table 2 — Parameter group number (PGN) examples
PGN constituent components PGN
PGN PGN (LSB)
PGN (MSB)
ISO-
Byte 2 Byte 3
Numbers of Cumulative
Byte 1
or
sent second sent first
assignable numbers of
sent third
manufacturer-
in CAN data in CAN data
Dec Hex
10 16
PGs PGs
in CAN data frame
assigned
frame frame
EDP DP PF PS
Bit
8–3
Bit 2 Bit 1 Bit 8–1 Bit 8–1
0 0 0 0 0 0 000000 ISO
239 239
0 0 0 238 0 60 928 00EE00
0 0 0 239 0 61 184 00EF00 1 240 MF
0 0 0 240 0 61 440 00F000 ISO
3 840
0 0 0 254 255 65 279 00FEFF 4 080
0 0 0 255 0 65 280 00FF00
256 MF
0 0 0 255 255 65 535 00FFFF 4 336
0 0 1 0 0 65 536 010000
0 0 1 238 0 126 464 01EE00 239 ISO
0 0 1 239 0 126 720 01EF00 240 4576 MF
0 0 1 240 0 126 976 01F000
4 096 ISO
0 0 1 255 255 131 071 01FFFF 8 672
5.1.4 ISO 11783 support of ISO 11898-1 CBFF messages
Controllers on the ISO 11783 network may support the CBFF (11 bit identifier) message format. Though
these are not compatible with the ISO 11783 message structure, to accommodate the co-existence of
the two formats, a minimum level of definition is given. This minimum definition allows controllers that
use this format to not interfere with other controllers. CBFF messages are defined as being proprietary.
In reference to Table 1, the 11 bit identifier field is parsed as follows: the three most significant bits
are used as priority bits; the eight least significant bits identify the SA of the PDU. Priority bits are
described in 5.2.2. The SA is described in 5.2.7.
Incorrect bus arbitration can occur when two messages, one base frame and one extended frame,
access the bus at the same time. The source address (SA) is a higher relative priority in the base frame
messages than in the extended frame messages. The message with an 11 bit identifier (base frame)
can have an SA indicating a higher priority than that of the Extended Data Page bit, Data Page bit and
PDU Format of the 29 bit identifier (extended frame) message. The three priority bits should be used to
achieve the correct bus arbitration.
IMPORTANT — ISO 11783 defines a full strategy for standardized communications using the
CEFF. Hardware that does not conform to ISO 11898-1 shall not be used on the network, since
these versions of hardware do not allow the CEFF messages to be communicated.
5.2 Protocol data unit (PDU)
5.2.1 General
The applications and/or network layer provide a string of information that is assimilated into a protocol
data unit. The protocol data unit provides a framework for organizing the information that is essential
to each classical CAN data frame sent. The protocol data unit (PDU) of the ISO 11783 network shall
consist of the seven fields listed in 5.1.2 and specified below. These fields shall then be packaged into
one or more classical CAN data frames and sent over the physical media to other network controllers.
There is only one PDU per classical CAN data frame.
NOTE Some PGN definitions require more than one classical CAN data frame for sending the
corresponding data.
Certain bits of the classical CAN data frame fields are left out of the PDU definition because they are
controlled entirely by the CAN specification and are invisible to all of the OSI layers above the data link
layer. These include the SOF, SRR, IDE, RTR, FDF, CRC, ACK and EOF fields, and parts of the control field.
They are defined by the CAN protocol definition and remain unmodified by ISO 11783.
The PDU fields (see Figure 4) are specified in 5.2.2 to 5.2.8.
Figure 4 — PDU fields
5.2.2 Priority (P)
Priority bits are used to optimize message latency for transmission onto the bus only. They should
be globally masked off by the receiving controller (ignored). The priority of any message can be set
from highest, 0 (000 ), to lowest, 7 (111 ). The default for all control oriented messages is 3 (011 ). The
2 2 2
default for all other informational, proprietary, request and NACK messages is 6 (110 ). This permits
the priority to be raised or lowered in the future as new PGN values are assigned and bus traffic
changes. A recommended priority is assigned to each PGN when it is added to the application layer
standards. However, the priority field should be reprogrammable to allow for network tuning by the
manufacturers if the need arises.
5.2.3 Extended data page (EDP)
The extended data page (EDP) bit is used in conjunction with the data page bit to determine the
structure of the CAN identifier of the classical CAN data frame. All ISO 11783 messages shall set the
extended data page bit to ZERO on transmit. (See Table 3 for the defined uses of the EDP and DP fields.)
It is possible that future definitions will expand the PDU Format field, defining new PDU formats,
expanding the priority field, or increasing the address space.
5.2.4 Data page (DP)
The data page (DP) bit is used in conjunction with the EDP bit to determine the structure of the CAN
identifier of the classical CAN data frame. With the EDP set to 0, the DP bit selects between page 0 and
page 1 of the PGN descriptions. See Table 3.
8 © ISO 2018 – All rights reserved

Table 3 — Definition of extended data page (EDP) and data page (DP) use
EDP DP
Bit 25 Bit 24
Description
CAN ID Bit 25 CAN ID Bit 24
0 0 ISO 11783 page 0 PGN
0 1 ISO 11783 page 1 PGN
1 0 ISO 11783 reserved
1 1 ISO 15765-2 defined PGN
NOTE The EDP and DP of the CAN 29 bit identifier being set to “11 ” identifies it as an ISO 15765-2 message.
This means that the remaining bits of the CAN identifier is not set up as specified by ISO 11783; CAN frames
following this format are not described in ISO 11783.
5.2.5 PDU format (PF)
PDU format (PF) is an 8 bit field that determines the PDU format and is one of the fields used to determine
the PGN assigned to the classical CAN data field. PGN are used to identify or label commands, data, some
requests, acknowledgements and negative acknowledgements, as well as for identifying or labelling
information that requires one or more classical CAN data frames to communicate the information. If
there is more information than can fit in eight data bytes, a multi-packet message is required to be sent.
If there are eight or less data bytes, then a single classical CAN data frame is used. A PGN can represent
one or more parameters, where a parameter is a piece of data such as engine rotations per minute.
Even though a PGN label can be used for one parameter, it is recommended that multiple parameters be
grouped so that all 8 byte of the data field are used.
The definition of two proprietary PGN allows both PDU1 and PDU2 formats to be used. The
interpretation of the proprietary information varies between manufacturers.
EXAMPLE Even though two different engines can use a common set of standard PGNs, it is probable that one
manufacturer’s proprietary communications will be different from another’s.
5.2.6 PDU Specific (PS)
The PDU specific (PS) field is an 8 bit field whose definition depends on its PDU format, which
determines whether it will be a DA or GE field. See Table 4.
Table 4 — Definition of PDU Specific (PS) field
PDU format PF PS
PDU1 0–239 Destination Address (DA)
PDU2 240–255 Group Extension (GE)
The DA field defines the specific address to which the message is being sent. Any other controller should
ignore this message. The global destination address (255) requires all controllers to listen and respond
accordingly as message recipients.
The GE field, in conjunction with the four least significant bits of the PF field, provides for
4 096 parameter groups per data page. These are only available using the GE format PDU (PDU2).
NOTE When the four most significant bits of the PDU format field are set, it indicates that the PS field is a
GE field.
In addition, 240 parameter groups are provided in each data page for use only in the destination-
specific format PDU (PDU1 format). In total, 8 672 parameter groups are available to be defined using
the two data pages currently available.
This total is calculated using Formula (1):
[240 + (16 × 256)] × 2 = 8 672 (1)
where
240 represents the number of PDU format field values available per data page (i.e. PDU1 format,
PS field = DA);
16 is the number of PDU format values per GE value (i.e. PDU2 format only);
256 is the number of possible GE values (i.e. PDU2 format only);
2 is the number of data page states (both PDU formats).
See also 5.3.
5.2.7 Source address (SA)
The source address (SA) field is 8 bit long. There shall only be one control function on the network with
a given source address.
NOTE For address management and allocation, and procedures to prevent duplication of SA, see ISO 11783-5.
5.2.8 Data field
5.2.8.1 Data from 0 to 8 byte
When eight or less bytes of data are required for expressing a given parameter group, then all eight
data bytes of the classical CAN data frame can be used. It is recommended that 8 byte be allocated
or reserved for all PGN assignments likely to expand in the future. This provides a means of adding
parameters easily and avoiding incompatibility with previous revisions that only define part of the data
field. Once the number of bytes of data associated with a PGN is specified, it cannot be changed (and
cannot become multi-packet either, unless originally defined as such). The CAN data length code (DLC)
is set to the defined parameter group “data length” value when it is 8 byte or less; otherwise, when the
PG data length is 9 byte or greater, the CAN DLC is set to 8. For example, the REQUEST PGN, 59 904, has
a PG data length of 3 byte, so the CAN DLC is set to 3. An individual group function (see 5.4.6) shall use
the same data field length because the CAN identifier is always identical; while the classical CAN data
field is used to convey the specific group subfunctions. These group functions require many different
interpretations based on the classical CAN data field.
5.2.8.2 Data greater than 8 byte
When more than 8 data bytes are needed to express a given parameter group, the communication of
these data are done in multiple classical CAN data frames. The term multi-packet is used to describe
this type of parameter group. A parameter group defined as being multi-packet capable, having less
than nine data bytes to transfer in a specific instance, shall be sent in a single classical CAN data frame
with the DLC set to 8. When a particular parameter group has nine or more data bytes to transfer,
then one of the transport protocol functions are used. The transport function connection management
capability is used to set up and close out the communication of the multi-packet parameter groups.
The transport protocol data transfer capability is used to communicate the data itself in a series of
classical CAN data frames (packets) containing the “packetized” data. Additionally, the transport
protocol function provides flow control and handshaking capabilities for destination-specific transfers
(see 5.10).
All classical CAN data frames associated with a particular multi-packet response shall have a DLC of
8. All unused data bytes are set to “Not Available”. The number of bytes per packet is fixed; however,
ISO 11783 defines multi-packet messages that have a variable and or fixed number of packets. The
10 © ISO 2018 – All rights reserved

PGN for active diagnostic codes is an example of a multi-packet message that has a variable number of
packets. Parameter groups that are defined as multi-packet only use the transport protocol when the
number of data bytes to be sent exceeds eight in number.
5.3 Protocol data unit (PDU) formats
5.3.1 General
The available PDU formats, illustrated in Figure 5, are defined as PDU1 (PS = DA) and PDU2 (PS = GE).
PDU1 allows for direction of the classical CAN data frame to a specific destination address (control
function); PDU2 only communicates classical CAN data frames that are not destination-specific. Two
separate PDU formats are created to provide more possible parameter group number combinations
while still providing for destination-specific communications. Proprietary parameter group definitions
are assigned so that both PDU formats can be used for proprietary communications. A standardized
method for proprietary communications is defined to prevent possible conflicts in identifier usage.
The definition of proprietary Parameter Group Numbers has been established allowing both PDU1 and
PDU2 Formats to be used. The interpretation of the proprietary information varies by manufacturer.
a) PDU1
b) PDU2
Figure 5 — Available PDU formats
5.3.2 PDU1 format
The PDU1 format provides for applicable parameter groups to be sent to either specific or global
destination(s). The PS field contains a DA.
PDU1 format messages can be requested or sent as unsolicited messages.
PDU1 format messages are determined by the PF field. When the value of that field is 0 to 239, the
message is in the PDU1 format. The format of the PDU1 message is illustrated by Figure 5. See also
Figure 6.
a
Currently, 2 × 240 = 480.
Figure 6 — PDU1 format
Parameter groups requiring a destination (PDU1) and minimal latency start at PF = 0 and increment
towards x (or x1).
Parameter groups requiring a destination where latency is not critical start at PF = 239 and decrement
towards x (or x1).
See Table 7.
A PF equal to 239 (Extended Data Page bit = 0 and Data Page bit = 0) is assigned for proprietary use. In
this case the PS field is a destination address (see 5.4.6). The PGN for Proprietary A is 61 184.
5.3.3 PDU2 format
The PDU2 format can only be used to communicate parameter groups as global messages. PDU2 format
messages can be requested or sent as unsolicited messages. Selection of the PDU2 format at the time a
PGN is assigned prevents that PGN from ever being able to be directed to a specific destination. The PS
field contains a GE.
PDU2 format messages are defined as being those where the PF value is equal to 240 to 255. The format
of the PDU2 message is illustrated by Figure 5. Also see Figure 7.
12 © ISO 2018 – All rights reserved

a
Currently, 2 × 16 × 256 = 8 192.
Figure 7 — PDU2 format
The PGN of messages that are sent at fast update rates (generally less than 100 ms) start at PF = 240
and increment towards y (or y1).
The PGN of messages that are only requested, sent on change, or are sent at slow update rates (generally
greater than 100 ms) start at PF = 254 and decrement towards y (or y1).
See Table 7.
A PF equal to 255 (Extended Data Page bit = 0 and Data Page bit = 0) is assigned for proprietary use.
The PS field is left to be defined and used by each manufacturer (see 5.4.6). The PGN for Proprietary B
covers the range 65 280 to 65 535.
5.4 Message types
5.4.1 General
There are five message types currently supported:
— Commands;
— Requests;
— Broadcasts/Responses;
— Acknowledgements;
— Group Functions.
The specific message type is recognized by its assigned PGN. The RTR bit (defined in the CAN protocol
for remote frames) is not to be used in the recessive state (logical 1). Therefore, Remote Transmission
Request (RTR = 1) is not available for use in the ISO 11783 network.
RTR was meant to “request” a specific CAN object by simply announcing its CAN identifier on the
network without any data bytes. Since ISO 11783 uses part of the CAN identifier for message priority
and part of it for source address, this mechanism will cause conflicts. A device is not allowed to send a
message with another device’s SA. A separate request mechanism exists in ISO 11783. See 5.4.3.
Multi-byte parameters that appear in the data field of a classical CAN data frame shall be placed LSB
first. Exceptions are noted where applicable (i.e. ASCII data). If a 2 byte parameter were to be placed in
Bytes 7 and 8 of the classical CAN data frame, the LSB would be placed in Byte 7 and the MSB in Byte 8.
5.4.2 Command
The command message type categorizes those parameter groups that command a specific or global
destination from a source. The dest
...

NORME ISO
INTERNATIONALE 11783-3
Quatrième édition
2018-11
Tracteurs et matériels agricoles et
forestiers — Réseaux de commande
et de communication de données en
série —
Partie 3:
Couche liaison de données
Tractors and machinery for agriculture and forestry — Serial control
and communications data network —
Part 3: Data link layer
Numéro de référence
©
ISO 2018
DOCUMENT PROTÉGÉ PAR COPYRIGHT
© ISO 2018
Tous droits réservés. Sauf prescription différente ou nécessité dans le contexte de sa mise en œuvre, aucune partie de cette
publication ne peut être reproduite ni utilisée sous quelque forme que ce soit et par aucun procédé, électronique ou mécanique,
y compris la photocopie, ou la diffusion sur l’internet ou sur un intranet, sans autorisation écrite préalable. Une autorisation peut
être demandée à l’ISO à l’adresse ci-après ou au comité membre de l’ISO dans le pays du demandeur.
ISO copyright office
Case postale 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Genève
Tél.: [phone]
Fax: [phone]
E-mail: [e-mail]
Web: www.iso.org
Publié en Suisse
ii © ISO 2018 – Tous droits réservés

Sommaire Page
Avant-propos .v
Introduction .vi
1 Domaine d’application . 1
2 Références normatives . 1
3 Termes et définitions . 1
4 Description générale . 2
5 Exigences techniques . 2
5.1 Format de la trame de message . 2
5.1.1 Généralités . 2
5.1.2 Format de trame de message conformément à l’ISO 11783 (format CEFF
de l’SO 11898-1). 2
5.1.3 Numéro de groupe de paramètres (PGN, parameter group numbers) . 6
5.1.4 Prise en charge par l’ISO 11783 de messages au format CBFF de l’ISO 11898-1 . 7
5.2 Unité de données de protocole (PDU) . 8
5.2.1 Généralités . 8
5.2.2 Priorité (P) . 8
5.2.3 Page de données étendue (EDP, extended data page) . 8
5.2.4 Page de données (DP, data page) . 9
5.2.5 Format PDU (PF, PDU format) . 9
5.2.6 Spécifique à la PDU (PS, PDU specific) . 9
5.2.7 Adresse source (SA, source address) .10
5.2.8 Champ de données .10
5.3 Formats des unités de données de protocole (PDU) .11
5.3.1 Généralités .11
5.3.2 Format PDU1 .12
5.3.3 Format PDU2 .13
5.4 Types de messages .14
5.4.1 Généralités .14
5.4.2 Commande .14
5.4.3 Demande .14
5.4.4 Diffusion/réponse.17
5.4.5 Accusé de réception .17
5.4.6 Fonction de groupe .22
5.4.7 Demande2 .25
5.4.8 Transfert . .26
5.5 Priorité des messages .28
5.6 Accès au bus .28
5.7 Arbitrage des conflits d’accès .28
5.8 Détection d’erreurs .28
5.9 Processus d’affectation des SA et des PGN.29
5.9.1 Généralités .29
5.9.2 Critères d’affectation d’adresse.29
5.9.3 Critères d’affectation d’un groupe de paramètres .30
5.9.4 Définition du champ de données .31
5.10 Fonctions de protocole de transport .31
5.10.1 Généralités .31
5.10.2 Mise en paquets et réassemblage .32
5.10.3 Protocole de transport — Gestion des connexions .33
5.10.4 Protocole de transport — Messages de gestion des connexions (TP.CM) .36
5.10.5 Protocole de transport — Messages de transfert de données (TP.DT) .40
5.10.6 Protocole de transport étendu — Contraintes relatives à la connexion .41
5.11 Fonctions de protocole de transport étendu .42
5.11.1 Vue d’ensemble .42
5.11.2 Généralités .42
5.11.3 Paquets de message .42
5.11.4 Protocole de transport étendu — Gestion des connexions .42
5.11.5 Protocole de transport étendu — Messages de gestion des connexions
(ETP.CM) . .44
5.11.6 Protocole de transport étendu — Messages de transfert de données (ETP.DT).48
5.11.7 Protocole de transport étendu — Contraintes relatives à la connexion .48
5.12 Exigences de traitement des PDU .49
5.13 Notes relatives à l’application .49
5.13.1 Débits élevés .49
5.13.2 Programmation des demandes .49
5.13.3 Temps de réponse des contrôleurs et défauts de temps morts .49
5.13.4 Réponses requises .50
5.13.5 Transmission de PGN à des destinations spécifiques ou globales .50
5.13.6 Recommandation relative au nombre de paquets CTS .50
Annexe A (informative) Traitement des PDU conformément à l’ISO 11783 — Sous-
programme type de réception .51
Annexe B (informative) Séquences de transfert du protocole de transport —Exemples de
transfert de données en mode connexion .53
Annexe C (informative) Exemples de modes de communication .62
Annexe D (informative) Utilisation de la bande passante du réseau .64
Bibliographie .65
iv © ISO 2018 – Tous droits réservés

Avant-propos
L'ISO (Organisation internationale de normalisation) est une fédération mondiale d'organismes
nationaux de normalisation (comités membres de l'ISO). L'élaboration des Normes internationales est
en général confiée aux comités techniques de l'ISO. Chaque comité membre intéressé par une étude
a le droit de faire partie du comité technique créé à cet effet. Les organisations internationales,
gouvernementales et non gouvernementales, en liaison avec l'ISO participent également aux travaux.
L'ISO collabore étroitement avec la Commission électrotechnique internationale (IEC) en ce qui
concerne la normalisation électrotechnique.
Les procédures utilisées pour élaborer le présent document et celles destinées à sa mise à jour sont
décrites dans les Directives ISO/IEC, Partie 1. Il convient, en particulier, de prendre note des différents
critères d'approbation requis pour les différents types de documents ISO. Le présent document a été
rédigé conformément aux règles de rédaction données dans les Directives ISO/IEC, Partie 2 (voir www
.iso .org/directives).
L'attention est attirée sur le fait que certains des éléments du présent document peuvent faire l'objet de
droits de propriété intellectuelle ou de droits analogues. L'ISO ne saurait être tenue pour responsable
de ne pas avoir identifié de tels droits de propriété et averti de leur existence. Les détails concernant
les références aux droits de propriété intellectuelle ou autres droits analogues identifiés lors de
l'élaboration du document sont indiqués dans l'Introduction et/ou dans la liste des déclarations de
brevets reçues par l'ISO (voir www .iso .org/brevets).
Les appellations commerciales éventuellement mentionnées dans le présent document sont données
pour information, par souci de commodité, à l’intention des utilisateurs et ne sauraient constituer un
engagement.
Pour une explication de la nature volontaire des normes, la signification des termes et expressions
spécifiques de l'ISO liés à l'évaluation de la conformité, ou pour toute information au sujet de l'adhésion
de l'ISO aux principes de l’Organisation mondiale du commerce (OMC) concernant les obstacles
techniques au commerce (OTC), voir www .iso .org/avant -propos.
Le présent document a été élaboré par le comité technique l'ISO/TC 23, Tracteurs et matériels agricoles
et forestiers, sous-comité SC 29, Électronique en agriculture.
Cette quatrième édition annule et remplace la troisième édition (ISO 11783-3:2014), qui a fait l'objet
d'une révision technique. Les principales modifications par rapport à l’édition précédente sont les
suivantes:
— mise à jour du texte en relation avec l’ISO 11898-1 (exclusion de l’utilisation du Taux de données
CAN Flexible);
— permet l’envoi de BAM.TP en 10 ms;
— ACCUSE DE RECEPTION PGN type d’identificateur étendu lorsque Demande2 l’utilise.
Une liste de toutes les parties de la série ISO 11783 se trouve sur le site Web de l’ISO.
Il convient que l’utilisateur adresse tout retour d’information ou toute question concernant le présent
document à l’organisme national de normalisation de son pays. Une liste exhaustive desdits organismes
se trouve à l’adresse www .iso .org/fr/members .html.
Introduction
L’ISO 11783 spécifie un système de communication destiné aux matériels agricoles fondé sur le protocole
1)
CAN de l’ISO 11898-1. Les documents SAE J 1939 sur lesquels certaines parties de l’ISO 11783 sont
fondées, ont été élaborés conjointement pour une utilisation dans des applications de camions et de
bus, ainsi que pour des applications de construction et d’agriculture. Des documents communs ont été
élaborés pour permettre l’utilisation, par des matériels agricoles et forestiers, d’unités électroniques
conformes aux spécifications SAE J 1939 relatives aux camions et aux bus, avec des modifications
mineures. Les informations d’ordre général concernant l’ISO 11783 peuvent être trouvées dans
l’ISO 11783-1.
L’objectif de l’ISO 11783 est de proposer un système ouvert pour les systèmes électroniques embarqués
interconnectés. Elle vise à permettre la communication entre unités de commande électroniques (UCE)
en proposant un système normalisé.
1) Society of Automotive Engineers, Warrendale, PA, USA.
vi © ISO 2018 – Tous droits réservés

NORME INTERNATIONALE ISO 11783-3:2018(F)
Tracteurs et matériels agricoles et forestiers — Réseaux de
commande et de communication de données en série —
Partie 3:
Couche liaison de données
1 Domaine d’application
Le présent document spécifie l'application, les protocoles de couche réseau et le mappage avec le
protocole de couche de liaison de données CAN (controller area network) comme spécifié dans
l’ISO 11898‑1. La couche d'application spécifie les unités de données de protocole (PDU), qui peuvent
être mappées aux trames de données CAN classiques à l'aide du format CEFF (Classical Extended Frame
Format). Pour les PDU dépassant la longueur des trames de données formatées CEFF, ce document
spécifie les protocoles de la couche transport et le mappage aux trames de données formatées CEFF.
2 Références normatives
Les documents suivants cités dans le texte constituent, pour tout ou partie de leur contenu, des
exigences du présent document. Pour les références datées, seule l’édition citée s’applique. Pour les
références non datées, la dernière édition du document de référence s'applique (y compris les éventuels
amendements).
ISO 11783-1, Tracteurs et matériels agricoles et forestiers — Réseaux de commande et de communication
de données en série — Partie 1: Système normalisé général pour les communications de données avec les
équipements mobiles
ISO 11783-5, Tracteurs et matériels agricoles et forestiers — Réseaux de commande et de communication
de données en série — Partie 5: Gestion du réseau
ISO 11783-7, Tracteurs et matériels agricoles et forestiers — Réseaux de commande et de communication
de données en série — Partie 7: Couche d'application de base
ISO 11898-1, Véhicules routiers — Gestionnaire de réseau de communication (CAN) — Partie 1: Couche
liaison de données et signalisation physique
ISO 15765-2, Véhicules routiers — Communication de diagnostic sur gest ionnaire de réseau de
communication (DoCAN) — Partie 2: Protocole de transport et services de la couche réseau
3 Termes et définitions
Pour les besoins du présent document, les termes et définitions de l’ISO 11783‑1 et
l’ISO 11898-1 s’appliquent.
L'ISO et l'IEC tiennent à jour des bases de données terminologiques destinées à être utilisées en
normalisation, consultables aux adresses suivantes:
— ISO Online browsing platform: disponible à l'adresse https: //www .iso .org/obp
— IEC Electropedia: disponible à l'adresse http: //www .electropedia .org/
4 Description générale
La couche liaison de données assure le transfert fiable de données par la liaison physique. Cela consiste à
émettre la trame de données CAN classique avec la synchronisation, le contrôle de séquence, le contrôle
d’erreur et le contrôle de flux nécessaires. Le contrôle de flux est accompli par un format cohérent de la
trame de message.
5 Exigences techniques
5.1 Format de la trame de message
5.1.1 Généralités
Le format de la trame du message doit être conforme aux exigences CAN. La spécification CAN à
laquelle il est fait référence dans le présent document est donnée dans l’ISO 11898-1. Lorsqu’il existe
des différences entre la spécification CAN et le présent document, le présent document doit constituer
le document directeur.
Le document CAN spécifie, dans une discussion relative à l’acheminement de l’information, que
les adresses des fonctions de contrôle ne sont pas utilisées. Bien que cela soit vrai pour certaines
applications du CAN, cela n’est pas vrai pour l’ISO 11783. La définition du réseau selon l’ISO 11783 exige
qu’un adressage des fonctions de contrôle soit utilisé pour éviter que plusieurs fonctions de contrôle
utilisent le même champ d’identificateur CAN. Plusieurs autres exigences spécifiées dans l’ISO 11783 ne
le sont pas par le CAN.
L’ISO 11898‑1 spécifie deux formats de trame classique: le Format de trame classique de base (CBFF)
et CEFF. La compatibilité à l’ISO 11898-1 implique que des messages des deux formats puissent être
potentiellement présents sur un seul réseau, en utilisant certains codages binaires permettant de
reconnaître les différents formats. À cet égard, l’ISO 11783 offre également des possibilités d’adaptation
aux deux formats de trame de message mais l’ISO 11783 ne définit une stratégie complète que pour les
communications normalisées utilisant le format CEFF. Tous les messages au format CBFF sont destinés
à une utilisation exclusive selon les règles définies dans le présent document. Aucun format de trame
FD ne doit être utilisé sur le réseau de l’ISO 11783.
En conséquence, les contrôleurs conformes à l’ISO 11783 doivent utiliser le format CEFF. Les messages
au format CBFF peuvent demeurer sur le réseau, mais uniquement conformément à le présent document.
La trame de données CAN classique est répartie en différents champs binaires, comme illustré à
la Figure 1. Le nombre et la répartition des bits dans les champs d’arbitrage et de contrôle diffèrent
entre les messages au format CBFF et ceux au format CEFF. Les messages au format CBFF, illustrés à
la Figure 1 a), contiennent 11 bits identificateurs dans le champ d’arbitrage, alors que les messages au
format CEFF, illustrés à la Figure 1 b), contiennent 29 bits identificateurs dans le champ d’arbitrage.
L’ISO 11783 a complété la définition des bits identificateurs dans le champ d’arbitrage des formats de
trame de message CAN. Ces définitions sont données dans le Tableau 1.
5.1.2 Format de trame de message conformément à l’ISO 11783 (format CEFF de l’SO 11898-1)
Le message au format CEFF, illustré à la Figure 1, contient une seule unité de données de protocole
(PDU, protocol data unit). Les PDU sont composées de sept champs prédéfinis remplis à l’aide des
informations fournies par la couche application:
— Priorité;
— page de données étendue (EDP, extended data page);
— page de données (DP, data page);
— format PDU (PF, PDU format);
2 © ISO 2018 – Tous droits réservés

— spécifique PDU (PS, PDU specific), qui peut être une adresse de destination (DA, destination address),
une extension de groupe (GE, group extension) ou une exclusivité;
— adresse source (SA, source address);
— données.
Voir en 5.2 pour une description détaillée de chaque champ, et en 5.3 pour les formats PDU.
a) Format de trame classique de base (CBFF)
b) Format de trame classique étendue (CEFF)
Figure 1 — Trames de données CAN classiques
Ces champs sont ensuite regroupés dans une trame de données CAN classique et transmis sur le
support physique à d’autres contrôleurs du réseau. Les couches du modèle OSI que l’ISO 11783 prend en
charge sont illustrées à la Figure 2. Il est possible que certaines définitions de groupes de paramètres
nécessitent plusieurs trames de données CAN classiques pour transmettre leurs informations.
Figure 2 — Application du modèle OSI conformément à l’ISO 11783
Le Tableau 1 indique les champs d’arbitrage et de contrôle de l’identificateur à 29 bits pour CAN, de
l’identificateur à 29 bits pour l’ISO 11783, de l’identificateur à 11 bits pour CAN et l’utilisation de
4 © ISO 2018 – Tous droits réservés

l’identificateur à 11 bits pour un réseau ISO 11783. Une définition complète de chacune des affectations
de champs de bits conformément à l’ISO 11783 est donnée en 5.3. Dans l’ISO 11783, le champ de trame
de données CAN se compose des octets 1 à 8. Le bit 8, ou bit le plus significatif (MSB, most significant
bit) de l’octet 1, est le premier bit transmis le plus proche du code de longueur de données (DLC, data
length code). Le bit 1, ou bit le moins significatif (LSB, least significant bit) de l’octet 8, est le dernier des
bits de données transmis et est le plus proche du champ de contrôle de redondance cyclique (CRC, cyclic
redundancy check). Voir la Figure 3.
Lorsque l’EDP et la DP sont égales à 1, la trame CAN est identifiée comme une trame au format
ISO 15765‑2. L’ISO 15765‑2 spécifie la communication de diagnostic sur gestionnaire de réseau de
communication (DoCAN). Par conséquent, le traitement de ce format de trame particulier ne correspond
pas aux définitions spécifiées dans l’ISO 11783 et il doit être conforme à l’ISO 15765‑2 (voir 5.2.4).
Tableau 1 — Correspondance entre l’ISO 11783 et les champs d’arbitrage et de contrôle CAN
Identificateurs à 29 bits Identificateurs à 11 bits
Bit n°
b
CAN ISO 11783 CAN ISO 11783
a a
1 SOF SOF SOF SOF
2 ID28 P3 ID28 P3
3 ID27 P2 ID27 P2
4 ID26 P1 ID26 P1
a
5 ID25 EDP ID25 ID8
a
6 ID24 DP ID24 ID7
a
7 ID23 PF8 ID23 ID6
a
8 ID22 PF7 ID22 ID5
a
9 ID21 PF6 ID21 ID4
a
10 ID20 PF5 ID20 ID3
a
11 ID19 PF4 ID19 ID2
a
12 ID18 PF3 ID18 ID1
a a
13 SRR (r) SRR RTR (x) RTR (d)
a a
14 IDE (r) IDE IDE (d) IDE
a
15 ID17 PF2 FDF (d) FDF
16 ID16 PF1 DLC4 DLC4
17 ID15 PS8 DLC3 DLC3
18 ID14 PS7 DLC2 DLC2
19 ID13 PS6 DLC1 DLC1
20 ID12 PS5
21 ID11 PS4
22 ID10 PS3
23 ID9 PS2
24 ID8 PS1
25 ID7 SA8
26 ID6 SA7
27 ID5 SA6
28 ID4 SA5
29 ID3 SA4
30 ID2 SA3
31 ID1 SA2
32 ID0 SA1
Tableau 1 (suite)
Identificateurs à 29 bits Identificateurs à 11 bits
Bit n°
b
CAN ISO 11783 CAN ISO 11783
a
33 RTR (x) RTR (d)
a
34 FDF (x) FDF (d)
a
35 r0 (d) r0
36 DLC4 DLC4
37 DLC3 DLC3
38 DLC2 DLC2
39 DLC1 DLC1
Page de données étendue, conformément à
SOF Bit de début de la trame EDP
l’ISO 11783
Bit d’adresse source n° #, conformément à
ID## Identificateur du bit n° # SA#
l’ISO 11783
SRR Demande à distance de remplacement DP Page de données, conformément à l’ISO 11783
Bit de format PDU n° #, conformément à
RTR Bit de demande de télétransmission PF#
l’ISO 11783
Bit spécifique PDU n° #, conformément à
IDE Bit d’extension d’identificateur PS#
l’ISO 11783
FDF Indicateur de format FD (d) Bit dominant
r# Bit réservé CAN n° # (r) Bit récessif
Bit de code de longueur de données, n° # (x) État binaire dépendant du message
DLD#
P# Bit de priorité n° #, conformément à l’ISO 11783
a
Bit défini dans CAN, inchangé dans l’ISO 11783.
b
Format requis pour identificateurs d’exclusivité à 11 bits.

Figure 3 — Champ de données CAN classique
5.1.3 Numéro de groupe de paramètres (PGN, parameter group numbers)
Chaque fois qu’il est nécessaire d’identifier un groupe de paramètres dans le champ de données
d’une trame classique de données CAN, il est exprimé en 24 bits. La valeur de 24 bits est transmise
avec l’octet le moins significatif en premier (voir le Tableau 2, qui indique également que l’octet le plus
significatif [MSB, most significant byte] est transmis en troisième, l’octet médian en second et l’octet le
moins significatif [LSB, least significant byte] en premier). Le PGN à 24 bits est déterminé à l’aide des
composants suivants: 6 bits mis à zéro, bit de page de données étendue, bit de page de données, champ
de format PDU (8 bits) et champ spécifique PDU (8 bits).
6 © ISO 2018 – Tous droits réservés

Le mode opératoire de conversion des champs de bits en PGN est le suivant. Les six bits les plus
significatifs du PGN sont mis à zéro. Puis le bit de page de données étendue, le bit de page de données et
le champ de format PDU sont copiés dans les 10 bits suivants. Si la valeur du format PDU est inférieure
à 240 (F0 ), l’octet le moins significatif du PGN est mis à zéro. Sinon, il est mis à la valeur du champ PS.
Voir le Tableau 2 pour une illustration des PGN, de leurs bits correspondants et de leur conversion en un
nombre décimal.
NOTE Les 131 072 combinaisons (2 ) ne peuvent pas toutes être affectées comme PGN. Seules
8 672 combinaisons sont disponibles pour l’affectation (calculées de la manière suivante: 2 pages × [240 +
(16 × 256)] = 8 672, en appliquant les conventions spécifiées dans le présent document. Voir l’ISO 11783‑1 pour
les dernières affectations de PGN.
Table 2 — Exemples de numéros de groupes de paramètres (PGN)
Composants du PGN PGN
PGN PGN (LSB)
PGN (MSB)
Octet 2 Octet 3
Octet 1 Affecté par ISO
transmis en transmis en
transmis en troi- Nombres de ou
deuxième premier Nombre de
sième PG affec- constructeur
dans la dans la trame PG cumulés
Dec Hex
10 16
dans la trame de tables (MF, manufac-
trame de de données
données CAN turer)
données CAN CAN
EDP DP PF PS
Bits
8–3
Bit 2 Bit 1 Bits 8–1 Bits 8–1
0 0 0 0 0 0 000000 ISO
239 239
0 0 0 238 0 60 928 00EE00
0 0 0 239 0 61 184 00EF00 1 240 MF
0 0 0 240 0 61 440 00F000 ISO
3 840
0 0 0 254 255 65 279 00FEFF 4 080
0 0 0 255 0 65 280 00FF00
256 MF
0 0 0 255 255 65 535 00FFFF 4 336
0 0 1 0 0 65 536 010000
0 0 1 238 0 126 464 01EE00 239 ISO
0 0 1 239 0 126 720 01EF00 240 4576 MF
0 0 1 240 0 126 976 01F000
4 096 ISO
0 0 1 255 255 131 071 01FFFF 8 672
5.1.4 Prise en charge par l’ISO 11783 de messages au format CBFF de l’ISO 11898-1
Les contrôleurs du réseau ISO 11783 peuvent prendre en charge le format de messages CBFF
(identificateur à 11 bits). Bien que ce format ne soit pas compatible avec la structure de message
conforme à l’ISO 11783, un niveau minimal de définition est donné pour s’adapter à la coexistence
des deux formats. Cette définition minimale permet aux contrôleurs qui utilisent ce format de ne pas
interférer avec d’autres contrôleurs. Les messages au format CBFF sont définis comme étant exclusifs.
En se reportant au Tableau 1, le champ de l’identificateur à 11 bits est analysé de la manière suivante:
les trois bits les plus significatifs sont utilisés comme des bits de priorité, et les huit bits les moins
significatifs identifient l’adresse source de la PDU. Les bits de priorité sont décrits en 5.2.2. La SA est
décrite en 5.2.7.
Un arbitrage incorrect des accès au bus peut se produire lorsque deux messages, un à trame standard
et l’autre à trame étendue, accèdent simultanément au bus. La SA a une priorité relative plus élevée
dans les messages à trame standard que dans les messages à trame étendue. Le message contenant
l’identificateur à 11 bits (trame standard) peut avoir une SA indiquant une priorité plus élevée que le bit
de page de données étendue, le bit de page de données ou le format PDU du message à identificateur à
29 bits (trame étendue). Il convient d’utiliser les trois bits de priorité pour obtenir un arbitrage correct
des accès au bus.
IMPORTANT — L’ISO 11783 définit une stratégie complète pour les communications normalisées
utilisant le format CEFF. Le matériel non conforme à l’ISO 11898-1 ne doit pas être utilisé dans le
réseau, ces versions de matériel ne permettant pas la transmission de messages de format CEFF.
5.2 Unité de données de protocole (PDU)
5.2.1 Généralités
Les applications et/ou la couche réseau fournissent une chaîne d’informations qui est assimilée dans
une PDU. La PDU fournit un cadre permettant d’organiser les informations et servant de clé à chaque
trame de données CAN classique émise. L’unité de données de protocole (PDU) du réseau ISO 11783
doit être composée de sept champs répertoriés en 5.1.2 et spécifiés ci‑dessous. Ces champs doivent être
ensuite regroupés dans une ou plusieurs trames de données CAN classiques et transmis sur le support
physique à d’autres contrôleurs du réseau. Il n’y a qu’une PDU par trame de données CAN classique.
NOTE Certaines définitions de PGN nécessitent plusieurs trames de données CAN classiques pour
transmettre les données correspondantes.
Certains bits des champs de la trame de données CAN classique ont été exclus de la définition de la
PDU, parce qu’ils sont entièrement contrôlés par la spécification CAN et sont invisibles par toutes
les couches OSI situées au-dessus de la couche liaison de données. Ils comprennent les champs SOF
(début de la trame, start of frame), SRR (demande à distance de remplacement, substitute remote
request), IDE (extension d’identificateur, identifier extension), RTR (demande de télétransmission,
remote transmission request), FDF (indicateur de format FD, FD Format Indicator), CRC (contrôle de
redondance cyclique, cyclic redundancy check), ACK (accusé de réception, acknowledgement) et EOF
(fin de la trame, end of frame) et des parties du champ de contrôle. Ces champs sont déterminés par la
définition du protocole CAN et n’ont pas été modifiés par l’ISO 11783.
Les champs de la PDU (voir la Figure 4) sont spécifiés de 5.2.2 à 5.2.8.
Figure 4 — Champs de la PDU
5.2.2 Priorité (P)
Les bits de priorité sont utilisés pour optimiser le temps de latence du message pour une transmission
sur bus uniquement. Il convient qu’ils soient globalement masqués (ignorés) par le contrôleur récepteur.
La priorité d’un message peut être fixée de la priorité la plus élevée, 0 (000 ), à la plus faible, 7 (111 ). La
2 2
valeur par défaut pour tous les messages orientés contrôle est 3 (011 ). La valeur par défaut pour tous les
autres messages, informatifs, d’exclusivité, de demande d’accès et de NACK (negative acknowledgement,
accusé de réception négatif), est 6 (110 ). Cela permet d’augmenter ou d’abaisser ultérieurement la
priorité, au fur et à mesure que de nouvelles valeurs de PGN sont affectées et que le trafic du bus varie.
Une priorité recommandée est affectée à chaque PGN lorsqu’il est ajouté aux documents de la couche
application. Il convient toutefois que le champ «priorité» soit reprogrammable de sorte que l’accord du
réseau puisse, si nécessaire, être effectué par le constructeur.
5.2.3 Page de données étendue (EDP, extended data page)
Le bit de Page de données étendue (EDP) est utilisé conjointement au bit de page de données pour
déterminer la structure de l’identificateur CAN de la trame de données CAN classique. Tous les messages
8 © ISO 2018 – Tous droits réservés

ISO 11783 doivent mettre le bit de page de données étendue à ZÉRO au moment de la transmission.
(Voir le Tableau 3 qui indique les utilisations définies des champs EDP et DP.) Les définitions ultérieures
pourraient éventuellement comprendre l’extension du champ de format PDU, la définition de nouveaux
formats PDU, l’extension du champ de priorité ou l’augmentation de l’espace adresse.
5.2.4 Page de données (DP, data page)
Le bit de Page de données (DP) est utilisé conjointement au bit EDP pour déterminer la structure de
l’identificateur CAN de la trame de données CAN classique. Le bit EDP étant mis à 0, le bit DP sélectionne
la page 0 ou la page 1 des descriptions du PGN. Voir le Tableau 3.
Table 3 — Définition pour l’utilisation de la page de données étendue (EDP) et de la page de
données (DP)
EDP DP
Bit 25 Bit 24
Description
ID 25 bits CAN ID 24 bits CAN
0 0 PGN page 0 selon l’ISO 11783
0 1 PGN page 1 selon l’ISO 11783
1 0 Réservé à l’ISO 11783
PGN défini selon
1 1
l’ISO 15765-2
NOTE Les bits EDP et DP de l’identificateur à 29 bits CAN sont définis sur «11 » ce qui permet de l’identifier
comme un message conforme à l’ISO 15765‑3. Cela signifie que les bits restants CAN ne sont pas réglés comme le
spécifie l’ISO 11783; les trames CAN conformes à ce format ne sont pas décrites dans l’ISO 11783.
5.2.5 Format PDU (PF, PDU format)
Le format PDU (PF) est un champ à 8 bits qui détermine le format de la PDU et constitue l’un des champs
utilisés pour déterminer le PGN affecté au champ de données CAN classique. Les PGN sont utilisés
pour identifier ou pour affecter une étiquette aux commandes, aux données, à certaines demandes,
aux accusés de réception positifs et aux accusés de réception négatifs, ainsi que pour identifier ou
affecter une étiquette à des informations pouvant nécessiter une ou plusieurs trames de données CAN
classiques pour transmettre l’information. Si la quantité d’information dépasse 8 octets, un message à
plusieurs paquets doit être transmis. Si la quantité d’information est égale à 8 octets d’information ou
moins, une seule trame de données CAN classique est utilisée. Un PGN peut représenter un ou plusieurs
paramètres, un paramètre étant un élément d’information comme le nombre de rotations par minute
d’un moteur. Même si l’étiquette d’un PGN peut être utilisée pour un seul paramètre, il est recommandé
de regrouper plusieurs paramètres de sorte que les 8 octets du champ de données soient utilisés.
La définition de deux PGN exclusifs permet l’utilisation des formats PDU1 et PDU2. L’interprétation des
informations exclusives varie selon le constructeur.
EXAMPLE Même si deux moteurs différents peuvent utiliser un ensemble commun de PGN normalisés,
les communications propres à un constructeur seront très probablement différentes de celles d’un autre
constructeur.
5.2.6 Spécifique à la PDU (PS, PDU specific)
Le champ spécifique à la PDU est un champ à 8 bits dont la définition dépend du format de la PDU. Ce
format détermine s’il s’agit d’une adresse de destination (DA) ou d’une extension de groupe (GE). Voir le
Tableau 4.
Table 4 — Définition du champ spécifique à la PDU (PS)
Format PDU PF PS
PDU1 0–239 Adresse de destination (DA)
PDU2 240-255 Extension de groupe (GE)
Le champ DA définit l’adresse spécifique à laquelle le message est envoyé. Il convient que tout autre
contrôleur ignore ce message. L’adresse de destination globale (255) nécessite que tous les contrôleurs
écoutent et répondent en conséquence, en tant que destinataires du message.
Le champ GE, associé aux quatre bits les moins significatifs du champ de format PDU, assure
4 096 groupes de paramètres par page de données. Ces groupes de paramètres ne sont disponibles
qu’en utilisant le format PDU avec extension de groupe (format PDU2).
NOTE Lorsque les quatre bits les plus significatifs du champ de format PDU sont fixés, cela signifie que le
champ PS est un champ de GE.
En outre, 240 groupes de paramètres sont réservés dans chaque page de données à une utilisation dans
le format PDU à destination spécifique (format PDU1). Au total, 8 672 groupes de paramètres peuvent
être définis en utilisant les deux pages de données actuellement disponibles.
Ce nombre total est calculé en utilisant la Formule (1):
[240 + (16 × 256)] × 2 = 8 672 (1)
où
240 sente le nombre de valeurs de champs de format PDU disponibles par page de données (c’est-
à‑dire format PDU1, champ PS = DA);
16 est le nombre de valeurs de format PDU par valeur de GE (c’est-à-dire format PDU2 uniquement);
256 est le nombre de valeurs d’extension de groupe possibles (c’est-à-dire format PDU2 uniquement);
2 est le nombre d’états de la page de données (les deux formats PDU).
Voir également 5.3.
5.2.7 Adresse source (SA, source address)
La longueur du champ Adresse source (SA) est de 8 bits. Il ne doit y avoir qu’une seule fonction de
contrôle sur le réseau avec une SA donnée.
NOTE La gestion et l’affectation des adresses, ainsi que les modes opératoires empêchant la duplication de
SA, sont détaillés dans l’ISO 11783-5.
5.2.8 Champ de données
5.2.8.1 Données comprises entre 0 et 8 octets
Lorsque huit octets d’information ou moins sont requis pour exprimer un groupe de paramètres
donné, tous les huit octets d’information de la trame CAN classique peuvent alors être utilisés. Il est
recommandé que huit octets soient affectés ou réservés pour toutes les affectations de PGN susceptibles
d’être étendues ultérieurement. Cette procédure fournit un moyen d’ajouter facilement des paramètres
et d’éviter l’incompatibilité avec des révisions antérieures qui définissent uniquement une partie
du champ de données. Une fois que le nombre d’octets d’information associés à un PGN est spécifié,
il ne peut plus être modifié (ni devenir à paquets multiples, à moins qu’il n’ait été défini comme tel à
l’origine). Le DLC du CAN est mis sur la valeur définie «longueur des données» du groupe de paramètres
lorsqu’il y a 8 octets ou moins; sinon, lorsque la longueur des données du groupe de paramètres est
10 © ISO 2018 – Tous droits réservés

de 9 ou plus, le DLC du CAN est mis à 8. Par exemple, la DEMANDE DE PGN, 59 904, a une longueur de
données de groupe de paramètres de 3, le DLC du CAN est donc défini sur 3. Une fonction de groupe
individuel (voir en 5.4.6) doit utiliser la même longueur de champ de données parce que l’identificateur
CAN est toujours identique alors que le champ de données CAN classique est utilisé pour véhiculer les
sous‑fonctions spécifiques du groupe. Ces fonctions de groupe nécessitent plusieurs interprétations
différentes fondées sur le champ de données CAN classique.
5.2.8.2 Données plus grandes que 8 octets
Lorsque le nombre d’octets d’information requis pour exprimer un groupe de paramètres donné est
supérieur à 8, la communication de ces données est effectuée par des trames de données CAN classiques
multiples. Le terme paquets multiples est utilisé pour décrire ce type de groupe de paramètres. Un
groupe de paramètres défini comme étant un paquet multiple, ayant moins de neuf octets de données
à transférer dans une instance spécifique, doit être transmis dans une seule trame de données CAN
classique, le DLC étant mis à 8. Lorsqu’un groupe de paramètres particulier a neuf octets de données ou
plus à transférer, alors l’une des fonctions de transport protocole de transport est utilisée. La capacité
de gestion des connexions de la fonction de protocole de transport est utilisée pour établir et arrêter la
transmission des groupes de paramètres à paquets multiples. La capacité de transfert de données du
protocole de transport est utilisée pour transmettre les données elles-mêmes en une série de trames
(paquets) classiques de données CAN contenant les données mises en paquets. Par ailleurs, la fonction
de protocole de transport assure un contrôle de flux et offre des capacités d’établissement d’une liaison
pour des transferts à destination spécifique (voir en 5.10).
Toutes les trames de données CAN classiques associées à une réponse à paquets multiples particulière
doivent avoir un DLC de 8. Tous les octets d’information non utilisé
...