ISO 11783-3:1998

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

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

La présente partie de l'ISO 11783 prescrit un réseau de commande et de communication de données en série pour tracteurs forestiers ou agricoles, ou instruments portés, semi-portés, remorqués ou automoteurs. Son but est de normaliser la méthode et le format de transfert des données entre capteurs, actionneurs, organes de commande, dispositifs de stockage de l'information et dispositifs d'affichage, que ces éléments soient montés ou intégrés au tracteur ou à l'instrument. La présente partie de l'ISO 11783 décrit la couche liaison de données «identificateur CAN à 29 bits».

General Information

• Status: Withdrawn
• Publication Date: 01-Jul-1998
• Withdrawal Date: 01-Jul-1998
• 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: 9599 - Withdrawal of International Standard
• Start Date: 01-Oct-2007
• Completion Date: 13-Dec-2025

Relations

• Revised: ISO 11783-3:2007 - Tractors and machinery for agriculture and forestry - Serial control and communications data network - Part 3: Data link layer
• Effective Date: 15-Apr-2008

Standards Content (Sample)

INTERNATIONAL ISO
STANDARD 11783-3
First edition
1998-07-01
Tractors and machinery for agriculture and
forestry — Serial control and
communications data network —
Part 3:
Data link layer
Tracteurs et machines agricoles et forestiers — Réseaux de commande et
de communication de données en série —
Partie 3: Couche liaison de données
A
Reference number
Contents Page
1 Scope . 1
2 General description . 1
3 Technical requirements . 1
3.1 Message frame format . 1
3.2 Protocol Data Unit (PDU) . 4
3.3 Protocol Data Unit (PDU) formats . 8
3.4 Message types . 9
3.5 Message priority . 12
3.6 Bus access . 12
3.7 Contention-based arbitration . 12
3.8 Error detection . 12
3.9 Assignment process for Source Addresses and
Parameter Group Numbers . 12
3.10 Transport protocol functions . 15
PDU processing requirements .
3.11 20
3.12 Application notes . 20
Annex A (normative) ISO 11783-specified PDU processing —
Typical receive routine . 22
Annex B (normative) Transport Protocol Transfer Sequences . 24
Annex C (informative) Communication Mode examples . 28
Annex D (informative) Bibliography . 29
©  ISO 1998
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced
or utilized in any form or by any means, electronic or mechanical, including photocopying and
microfilm, without permission in writing from the publisher.
International Organization for Standardization
Case postale 56 • CH-1211 Genève 20 • Switzerland
Internet [e-mail]
X.400 c=ch; a=400net; p=iso; o=isocs; s=central
Printed in Switzerland
ii
©
ISO ISO 11783-3:1998(E)
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.
Draft International Standards adopted by the technical committees are circulated to the member bodies for voting.
Publication as an International Standard requires approval by at least 75 % of the member bodies casting a vote.
International Standard ISO 11783-3 was prepared by Technical Committee ISO/TC 23, Tractors and machinery for
agriculture and forestry, Subcommittee SC 19, Agricultural electronics.
ISO 11783 consists of the following parts, under the general title Tractors and machinery for agriculture and
forestry — Serial control and communications data network:
— Part 1: General standard for mobile data communication
— Part 2: Physical layer
— Part 3: Data link layer
— Part 4: Network layer
— Part 5: Network management
— Part 6: Virtual terminal
— Part 7: Basic applications layer
— Part 8: Power train
— Part 9: Tractor ECU
— Part 10: Process data applications layer
— Part 11: Task controller and management information system data interchange
Annexes A and B form an integral part of this part of ISO 11783. Annexes C and D are for information only.
iii
©
Introduction
Parts 1 to 11 of ISO 11783 specify a communications system for agricultural equipment based on the CAN 2.0 B
protocol. SAE J 1939 documents, on which parts of ISO 11783 are also based, were developed jointly for use in
truck and bus applications and for construction and agriculture applications. Joint documents were 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.
The purpose of ISO 11783 is to provide an open interconnected system for on-board electronic systems. It is
intended to enable electronic units to communicate with each other providing a standardized system.
The International Organization for Standardization (ISO) draws attention to the fact that it is claimed that compliance
with this part of ISO 11783 may involve the use of a patent concerning the Controller Area Network (CAN) protocol
referred to throughout the document.
ISO takes no position concerning the evidence, validity and scope of this patent.
The holder of this patent has assured ISO that he is willing to negotiate licences under reasonable and non-
discriminatory terms and conditions with applicants (manufacturers of CAN devices) throughout the world. For this
purpose, the statement of the holder of this patent is registered with ISO. Information may be obtained from:
Robert Bosch GmbH
Wernerstraße 51
Postfach 30 02 20
D-70442 Stuttgart-Feuerbach
Germany
Attention is drawn to the possibility that some of the elements of this part of ISO 11783 may be the subject of
patents other than that identified above. ISO shall not be held responsible for identifying any and all such patent
rights.
iv
©
INTERNATIONAL STANDARD  ISO ISO 11783-3:1998(E)
Tractors and machinery for agriculture and forestry — Serial
control and communications data network —
Part 3:
Data link layer
1 Scope
This part of ISO 11783 specifies a serial data network for control and communications on forestry or agricultural
tractors, mounted, semi-mounted, towed or self-propelled implements. Its purpose is to standardize the method and
format of data transfer between sensor, actuators, control elements, information storage and display units whether
mounted or part of the tractor, or any implements. This part of ISO 11783 describes the CAN 29 Bit Identifier [5]
Data Link Layer [6].
2 General description
The data link layer enables the reliable transfer of data across the physical link. This consists of sending the CAN
data frame with the necessary synchronization, error control and flow control. The flow control is accomplished
through a consistent message frame format.
3 Technical requirements
3.1 Message frame format
The message frame format shall conform to the CAN requirements. The CAN specification referenced throughout
this document is CAN Specification version 2.0 B [5]. It should be noted that when there are differences between
the above-mentioned CAN specification and ISO 11783, ISO 11783 is the governing document.
The CAN document specifies, in an information routing related discussion, that controller addresses are not used.
While this is true for some applications of CAN, it is not true for ISO 11783. The definition of the network according
to ISO 11783 requires that controller addressing be used to prevent multiple controllers from using the same CAN
Identifier field. Many additional requirements are given in ISO 11783 that are not specified by CAN.
CAN 2.0 B specifies two message frame formats, Standard Frame and Extended Frame. "CAN 2.0 B compatibility"
implies that messages of both format can potentially be present on a single network, by using certain bit codings
which allow for the recognition of the different formats. ISO 11783 also accommodates both message frame
formats; however, ISO 11783 only defines a full strategy for standardized communications using the Extended
Frame format. All standard frame format messages are for proprietary use following the rules defined in this part of
ISO 11783.
Therefore, controllers according to ISO 11783 must use the Extended Frame format. Standard Frame format
messages can reside on the network, but only as described in this part of ISO 11783.
NOTE — Standard frame controllers do not respond to network management messages and will not be able to support the
strategy for standardized communications.
The 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 differ between the CAN Standard and CAN Extended Frame messages. CAN
©
Standard Frame messages, shown in "A", contain 11 Identifier bits in the arbitration field and CAN Extended Frame
messages, shown in "B", contain 29 Identifier bits in the arbitration field. ISO 11783 further defines the Identifier bits
in the arbitration field of the CAN message frame formats. These definitions are given in table 1.
A. CAN Standard Frame Format
CAN Data Frame
Maximum frame length with bit stuffing = 127 bits
Control
Arbitration
Data
Field
Field
Field
12 bits
8 bits
S
R I
ACK
DLC
Data Field
Identifier r CRC EOF
O T
D
Field
o
F 11 bits 4 bits 0 to 64 bits
15 bits 2 bits 7 bits
R E
Bit Stuffing
No bit stuffing
B. CAN Extended Frame Format
CAN Data Frame
Maximum frame length with bit stuffing = 150 bits
Arbitration Control
Data
Field
Field
Field
32 bits 8 bits
ACK
S Identifier R I Identifier R r r DLC Data Field CRC EOF
O Field
T D T 1 o
F
11 bits 18 bits 4 bits 0 to 64 bits 15 bits 2 bits 7 bits
R E R
Bit Stuffing
No bit stuffing
Figure 1 — CAN Data Frames
3.1.1 Message frame format according to ISO 11783 (CAN 2.0 B Extended Frame Format)
The CAN extended frame message, as shown in figure 1, encompasses a single Protocol Data Unit (PDU). PDUs
consists of seven pre-defined fields. These fields are assimilated from information provided by the application layer.
They are Priority, Reserved, Data Page, PDU Format, PDU Specific (which can be a destination address, Group
Extension, or proprietary), Source Address and Data Fields. They are then packaged into one or more CAN data
frames 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 should be recognised that some Parameter Group definitions require more than
one CAN data frame to send their information. Table 1 shows the arbitration and control fields of the 29 bit identifier
for CAN, 29 bit identifier for ISO 11783, 11 bit identifier for CAN, and the 11 bit identifier for ISO 11783. A complete
definition for each of the bit field assignments according to ISO 11783 is given in 3.3.
3.1.2 Parameter Group Number (PGN)
The Parameter Group Number is determined from the following constituent components: Reserved bit, Data Page
bit, PDU Format Field (8 bits), and Group Extension Field (8 bits). These 18 bits are used to establish the 24 bit
PGN. Whenever it is necessary to identify a Parameter Group in the data-field of a CAN data frame, it is expressed
in 24 bits with the most significant bits set to zero. See table 2 for an illustration of PGNs, their corresponding bits
and their conversion to a decimal number.
The procedure for the bit fields to be converted to Parameter Group Numbers is as follows. If the PDU Format (PF)
value is less than 240 (F0 ), then the lower byte of the PGN is set to zero.
©
ISO ISO 11783-3:1998(E)
NOTE — Not all 131 072 combinations (2 ) are available to be assigned as PGNs. Only a total of 8 670 combinations are
available for assignment (calculated as: 2 pages × [240 + (16 × 256)] = 8 670, using the conventions specified in this part of
ISO 11783).
Table 1 — Mapping of ISO 11783 into CAN's Arbitration and Control fields
29 bit identifiers 11 bit identifiers
1)
ISO 11783
Bit No. CAN ISO 11783 CAN
) )
SOF* SOF*
1 SOF SOF
2 ID 28 P 3 ID 11 P 3
3 ID 27 P 2 ID 10 P 2
4 ID 26 P 1 ID 9 P 1
5 ID 25 R 1 ID 8 SA 8
6 ID 24 DP ID 7 SA 7
7 ID 23 PF 8 ID 6 SA 6
8 ID 22 PF 7 ID 5 SA 5
9 ID 21 PF 6 ID 4 SA 4
10 ID 20 PF 5 ID 3 SA 3
11 ID 19 PF 4 ID 2 SA 2
12 ID 18 PF 3 ID 1 SA 1
) )
SRR* RTR*
13 SRR (r) RTR (x)
) )
IDE* IDE*
14 IDE (r) IDE (d)
)
R 0*
15 ID 17 PF 2 R 0
16 ID 16 PF 1 DLC 4 DLC 4
17 ID 15 PS 8 DLC 3 DLC 3
18 ID 14 PS 7 DLC 2 DLC 2
19 ID 13 PS 6 DLC 1 DLC 1
20 ID 12 PS 5
21 ID 11 PS 4
22 ID 10 PS 3
23 ID 9 PS 2
24 ID 8 PS 1
25 ID 7 SA 8
26 ID 6 SA 7
27 ID 5 SA 6
28 ID 4 SA 5
29 ID 3 SA 4
30 ID 2 SA 3
31 ID 1 SA 2
32 ID 0 SA 1
)
RTR*
33 RTR (x)
)
r 1*
34 r 1
)
r 0*
35 r 0
36 DLC 4 DLC 4
37 DLC 3 DLC 3
38 DLC 2 DLC 2
39 DLC 1 DLC 1
SOF Start of Frame Bit R# Reserved Bit #n according to ISO 11783
ID## Identifier Bit #n SA# Source Address Bit #n according to ISO 11783
SRR Substitute Remote Request DP Data Page according to ISO 11783
RTR Remote Transmission Request Bit PF# PDU Format Bit #n according to ISO 11783
IDE Identifier Extension Bit PS# PDU Specific Bit #n according to ISO 11783
r# CAN Reserved Bit #n (d) dominant bit
DLC# Data Length Code Bit #n (r) recessive bit
P# Priority Bit #n according to ISO 11783 (x) bit state dependent on message
*) CAN Defined Bit, Unchanged in ISO 11783.
1) Required format of proprietary 11 bit identifiers.
©
Key
PF PDU Format
R Reserved
DP Data Page
SA Source Address
PS PDU Specific
Figure 2 — Application of OSI Model according to ISO 11783
3.1.3 ISO 11783 support of CAN 2.0 B Standard Frame Format messages
It is recognised that controllers on the ISO 11783-specified network may support the CAN Standard Frame (11 bit
identifier) message format. Though these are not compatible with the message structure according to ISO 11783, a
minimum level of definition is given to accommodate the co-existence of the two formats. This minimum definition
allows controllers that use this format to avoid interfering with other controllers. CAN Standard Frame Format
messages are defined as being proprietary. As shown in 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 source address of the
PDU. Priority bits are described in 3.3.1. The source address is defined in the Source Address Table [2] or is
determined by the procedures outlined in the part of ISO 11783 which deals with network management [3].
NOTE — Incorrect bus arbitration could occur when two messages, one Standard Frame and one Extended Frame, access the
bus at the same time. The source address (SA) has a higher relative priority in the Standard Frame messages than in the
Extended Frame messages. The message with the 11 bit identifier (Standard Frame) could have a SA indicating a higher
priority than the reserved 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.
ISO 11783 only specifies a full strategy for standardized communications using the extended frame format.
Hardware conforming to CAN 2.0 A specification must not be used on the network, since these versions of
hardware do not allow the Extended Frame messages to be communicated.
3.2 Protocol Data Unit (PDU)
The Applications and/or Network Layer provides 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 key to each CAN Data Frame that
is sent. The protocol data unit (PDU) according to ISO 11783 shall consist of seven fields. These fields are Priority,
Reserved, Data Page, PDU Format, PDU Specific (which can be a destination address, Group Extension or
proprietary), Source Address and Data. These fields are then packaged into one or more CAN data frames and sent
over the physical media to other network controllers. There is only one PDU per CAN data frame.
©
ISO ISO 11783-3:1998(E)
NOTE — It should be recognised that some Parameter Group Number definitions will require more than one CAN data frame to
send the corresponding data.
Some of the CAN Data Frame fields have been 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. They include the SOF,
SRR, IDE, RTR, parts of the control field, CRC field, ACK field and the EOF field. These fields are defined by the
CAN protocol definition and were not modified for ISO 11783. The seven PDU fields are illustrated in figure 3. Each
of the fields within the PDU are defined in 3.2.1 to 3.2.7.
Table 2 — Parameter Group Number (PGN) examples
PGN constituent components PGN
Number of Cumulative ISO or
PGN (msb) PGN PGN
assignable number of manufacturer
PGs PGs assigned
Byte 1 Byte 2 Byte 3
DEC HEX
RDP PF PS
Bits8-3 Bit 2 Bit 1
0 0 0 0 0 0 000000 — — ISO
0 0 0 238 0 60928 00EE00 239 239 —
0 0 0 239 0 61184 00EF00 1 240 Manufacturer
0 0 0 240 0 61440 00F000 — — ISO
0 0 0 254 255 65279 00FEFF 3 840 4 080 —
0 0 0 255 0 65280 00FF00 — — Manufacturer
0 0 0 255 255 65535 00FFFF 256 4 336 —
0 0 1 0 0 65536 010000 — — ISO
0 0 1 239 0 126720 01EF00 240 4 576 —
0 0 1 240 0 126976 01F000 — — ISO
0 0 1 255 255 131071 01FFFF 4 096 8 672 —
Priority, R, DP, PF, PS, SA, Data Field
No. of Bits .3., .1., .1., .8., .8., .8., .64.
Key: R Reserved
DP Data Page
PF PDU Format
PS PDU Specific
SA Source Address
Figure 3 — Protocol Data Unit (PDU)
©
3.2.1 Priority (P)
Priority bits are used to optimize message latency for transmission onto the bus only. They should be globally
masked off by the receiver (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 default for all other informational, proprietary,
2 2
request and NACK messages is 6 (110 ). This permits the priority to be raised or lowered in the future as new
PGNs values are assigned and bus traffic changes. A recommended priority is assigned to each PGN when it is
added to the application layer documents.
3.2.2 Reserved bit (R)
This bit is currently reserved for use in a future International Standard. This reserved bit should not be confused
with the CAN reserved bits. All messages should set the ISO-specified reserved bit to ZERO on transmit. Future
definitions might possibly be expanding the PDU Format field, defining new PDU formats, expanding the Priority
field, or increasing the address space.
3.2.3 Data Page (DP)
The data page bit sets an auxiliary page of Parameter Group descriptions. Assignment of all Parameter Group
Numbers available in page zero are complete (filled) before the page one assignments are made (see 3.9 which
discusses PGN Assignments).
3.2.4 PDU Format (PF)
The PDU Format is an 8-bit field that determines the PDU format and is one of the fields used to determine the
Parameter Group Number assigned to the CAN data field. Parameter Group Numbers are used to identify or label
commands, data, some requests, acknowledgements and negative-acknowledgements. Parameter Group Numbers
identify or label information that may require one or more CAN data frames to communicate the information. If there
is more information than will fit in 8 data bytes, a multi-packet message needs to be sent. A Parameter Group
Number can represent one or more parameters, where a parameter is a piece of data such as engine rotations per
minute. Even though a Parameter Group Number label can be used for one parameter, it is recommended that
multiple parameters be grouped so that all 8 bytes of the data field are used.
The definition of two proprietary Parameter Group Numbers has been established allowing both PDU1 and PDU2
Formats to be used. The interpretation of the proprietary information will vary by manufacturer. For example, even
though two different engines may use the same source address, manufacturer "A's" proprietary communications will
most likely be different from manufacturer "B's".
3.2.5 PDU Specific (PS)
The PDU Specific field is an 8-bit field and its definition depends on the PDU format. Depending on the PDU format,
it can be a Destination Address or a Group Extension. See table 3.
Table 3 — Definition of a PDU Specific field
Format PDU Format field PDU Specific Field
PDU1 0 - 239 Destination Address
PDU2 240 - 255 Group Extension
3.2.5.1 Destination Address (DA)
This 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.
©
ISO ISO 11783-3:1998(E)
3.2.5.2 Group Extension (GE)
The Group Extension field, in conjunction with the four least significant bits of the PDU Format field, provide for
4 096 Parameter Groups per data page. These 4 096 Parameter Groups are only available using the Group
Extension Format PDU. In addition, 240 Parameter Groups are provided in each data page for use only in the
Destination Specific Format PDU. In total, 8 672 Parameter Groups are available to be defined using the two data
pages currently available.
NOTE — When the four most significant bits of the PDU Format field are set it indicates that the PS field is a Group Extension.
The total number of Parameter Group labels available can be calculated as follows:
[240 + (16 x 256)] × 2 = 8 672
where
240 = number of PDU Format field values available per data page (i.e. PDU1 Format);
16 = PDU Format values per Group Extension value (i.e. PDU2 Format only);
256 = number of possible Group Extension values (i.e. PDU2 Format only);
2 = number of Data Page states (both PDU Formats).
3.2.6 Source Address (SA)
The Source Address field is 8 bits long. There shall only be one controller on the network with a given source
address. Therefore, the source address field assures that the CAN identifier is unique, as required by CAN. Address
management and allocation and procedures to prevent duplication of source addresses are defined in a future
International Standard [3].
3.2.7 Data Field
3.2.7.1 Data from 0 to 8 bytes
When eight or less bytes of data are required for expressing a given Parameter Group, then all eight data bytes of
the CAN data frame can be used. It is generally recommended that eight bytes be allocated or reserved for all
Parameter Group Number assignments which are likely to expand in the future. This provides a means to add
parameters easily and not be incompatible with previous revisions which only define part of the data field. Once the
number of bytes of data associated with a Parameter Group Number is specified, it cannot be changed (nor can it
become multi-packet, unless originally defined as multi-packet). It is important to note that a given group function
(see 3.4.5) must use the same data field length because the CAN identifier is always identical, while the CAN data
field is used to convey the specific group subfunctions. These group functions require many different interpretations
based on the CAN data field.
3.2.7.2 Data from 9 to 1 785 bytes
When 9 to 1 785 data bytes are needed to express a given Parameter Group, the communication of this data is
done in multiple CAN Data Frames. Thus the term "multi-packet" is used to describe this type of Parameter Group
Number. The ”Transport Protocol Function” is used when more than one CAN data frame is required to send a
particular Parameter Group. The "Transport Protocol Function’s 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 CAN Data Frames (packets) containing the
packetized data. Additionally, the Transport Protocol Function provides flow control and handshaking capabilities for
destination-specific transfers (see 3.10).
All CAN data frames associated with a particular multi-packet response are required to 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 or a fixed number of packets. The Parameter Group Number 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 send
exceeds eight.
©
3.3 Protocol Data Unit (PDU) formats
The available PDU formats are illustrated in figure 4. Two PDU formats are defined; PDU1 Format
(PS = Destination Address) and PDU2 Format (PS = Group Extension). The PDU1 Format allows for direction of the
CAN Data Frame to a specific destination address (controller). The PDU2 Format can only communicate CAN Data
Frames that are not destination-specific. The creation of two separate PDU formats was established in order to
provide more possible Parameter Group Number combinations while still providing for destination-specific
communications. Proprietary Parameter Group definitions have been assigned so that both PDU formats are
available for proprietary communications. A standardized method was established for proprietary communications to
prevent possible conflicts in identifier usage.
The definition of two proprietary Parameter Group Numbers was established which allows both PDU1 and PDU2
Formats to be used. The interpretation of the proprietary information will vary by manufacturer. For example, engine
manufacturer "A's" proprietary communications will likely be different from engine manufacturer "B's" even though
they both use the same source address.
3.3.1 PDU1 Format
The PDU1 format allows for applicable Parameter Groups to be sent to either a specific or global destination(s). The
PDU Specific (PS) field contains a destination address (DA). PDU1 Format messages can be requested or sent as
unsolicited messages.
PDU1 Format messages are determined by the PDU Format (PF) field. When the PDU Format field value is 0 to
239 the message is PDU1 Format. The Format of the PDU1 message is illustrated in figure 4.
Parameter Groups requiring a destination (PDU1) and minimal latency start at PF = 0 and increment toward x (or
x1) (see table 5).
Parameter Groups requiring a destination where latency is not critical will start at PF = 239 and decrement toward x
(or x1) (see table 5).
A PF equal to 239 (reserved bit = 0 and data page bit = 0) is assigned for proprietary use. In this case the PDU
Specific (PS) field is a destination address (see 3.4.5). The PGN for Proprietary A is 61184.
PDU 1
Priority, R, DP, PF, PS(DA), SA, Data Field
No. of Bits .3., .1., .1., .8., .8., .8., .64.
PDU 2
Priority, R, DP, PF, PS(GE), SA, Data Field
No. of Bits .3., .1., .1., .8., .8., .8., .64.
Key: R Reserved
DP Data Page
PF PDU Format
PS PDU Specific
DA Destination Address
GE Group Extension
SA Source Address
Figure 4 — Available PDU Formats
©
ISO ISO 11783-3:1998(E)
3.3.2 PDU2 Format
This 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 PDU2 Format, at the time a PGN is assigned, prevents
that PGN from ever being able to be directed to a specific destination. The PDU Specific (PS) field contains a Group
Extension (GE).
PDU2 Format messages are defined to be those where the PDU Format (PF) value is equal to 240 to 255 (see
table 3). The format of the PDU2 message is illustrated in figure 4.
The Parameter Group Number of messages that are sent at fast update rates (generally less than 100 ms) start at
PF = 240 and increment towards y (or y1) (see table 5).
The Parameter Group Number 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 toward y (or y1) (see table 5).
A PF equal to 255 (reserved bit = 0 and data page bit = 0) is assigned for proprietary use. The PDU Specific field is
left to be defined and used by each manufacturer (see 3.4.5). The PGN for Proprietary B is 65280 to 65535.
3.4 Message types
There are five message types currently supported. These types are: Commands, Requests,
Broadcasts/Responses, Acknowledgement and Group Functions. The specific message type is recognised by its
assigned Parameter Group Number [2]. 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 Requests (RTR =1) is not available for use
according to ISO 11783.
3.4.1 Command
The Command message type categorises those Parameter Groups that command a specific or global destination
from a source. The destination is then supposed to take specific actions based on the reception of this command
message type. Both PDU1 (PS = Destination Address) and PDU2 Format (PS = Group Extension) messages can
be used for commands. Example command modes may include: "Transmission Control", "Address Request",
"Torque/Speed Control", etc.
3.4.2 Request
The Request message type, identified by the PGN, provides the capability to request information globally or from a
specific destination. Requests specific to one destination are known as destination-specific requests. The
information below assigns a Parameter Group Number to the "Request PGN" Parameter Group. The information is
in the same format as Parameter Group definitions given in ISO 11783.
Parameter Group Name: REQUEST PGN
Definition: Used to request a Parameter Group from a network controller.
Transmission Repetition Rate: Per User requirements, generally recommended that requests occur no
more than 2 or 3 times per second.
Data Length: 3 bytes
Data Page: 0
PDU Format: 234
PDU Specific field: Destination Address
Default Priority: 6
Parameter Group Number: 59904 (00EA00 )
Byte 1, 2, 3: Parameter Group Number being requested (see 3.1.2)
Table 4 gives two examples of how the Request PGN is used.
©
Table 4 — Request PGN examples
Use of the specified fields in PDU1 Format according to ISO 11783
Message
type
PF PS (DA) SA Data 1 Data 2 Data 3
1)
Global 234 255 SA 1 PGN PGN PGN msb
1)
Request (Responders) (Requester) lsb
1)
Specific 234 SA 2 SA 1 PGN PGN PGN msb
1)
Request (Responder) (Requester) lsb
1) Parameter Group Number in the data field is used to identify the information being requested.
A response is always required from a specified destination (not global), even if it is a NACK indicating that the
particular PGN value is not supported. A global request shall not be responded to with a NACK when a particular
PGN is not supported by a controller.
NOTE — Some PGNs are multi-packet, so several CAN Data Frames can occur for a single request.
3.4.3 Broadcast/Response
The Broadcast/Response message type can be an unsolicited broadcast of information from a controller or it can be
the response to a Command or a Request.
3.4.4 Acknowledgement
There are two forms of acknowledgement available. The first form is provided for by the CAN protocol. It consists of
an "in-frame" acknowledgement which confirms that a message is received by at least one controller. In addition,
messages are further acknowledged by the absence of CAN error frames. Their absence acknowledges that all
other powered and connected controllers received the message correctly.
The second form of acknowledgement, which is in the data field, is a response of a "normal broadcast" or "ACK" or
"NACK" to a specific command or request as provided for by an application layer. The type of acknowledgement
required for some Parameter Groups is defined in the applications layer.
Parameter Group Name: ACKNOWLEDGEMENT
Definition: The Acknowledgement PG is used to provide a handshake mechanism between
transmitting and receiving controllers.
Transmission Repetition Rate: Upon reception of a Parameter Group Number that requires this form of
acknowledgement.
Data Length: 8 bytes
Data Page: 0
PDU Format: 232
1)
PDU Specific field: Destination Address = Global (255)
Default Priority: 6
Parameter Group Number: 59392 (00E800 )
Data ranges for parameters used by this Message Type:
Control byte:
0 and 1 See definition below
2 to 255 Reserved for assignment in a future International Standard

1) The global destination address makes it possible to filter on one CAN identifier for all acknowledgement messages
©
ISO ISO 11783-3:1998(E)
Positive Acknowledgement:
Control byte: 0
Byte: 1 Control byte = 0, Positive Acknowledgement (ACK)
2-5 Reserved for assignment in a future International Standard, send each of these
bytes as ”FF ”
6-8 Parameter Group Number of requested information
Negative Acknowledgement:
Control byte: 1
Byte: 1 Control byte = 1, Negative Acknowledgement (NACK)
2-5 Reserved for assignment in a future International Standard, send each of these
bytes as ”FF ”
6-8 Parameter Group Number of requested information
3.4.5 Group Function
The Group Function message type is used for groups of special functions (e.g. proprietary functions, network
management functions, multi-packet transport functions etc.). Each group of functions is recognised by its assigned
PGN. The function itself is defined within the data structure. More detailed explanation of the group functions
proprietary and transport protocol will be given in the following subclauses. The proprietary group function provides
a means to transmit proprietary messages in a way that eliminates CAN Identifier usage conflicts between different
manufacturers. It also provides a means for receiving and distinguishing proprietary messages for use when
desired. Group Functions may need to provide their own request, ACK and/or NACK mechanisms.
A request using PGN 59904 (see 3.4.2) can be used to find out if specific Parameter Group of the message type,
Group Function, is supported. If it is supported then the responding controller will send the Acknowledgement PGN
with the control byte equal to zero, for Positive Acknowledgement. If it is not supported, the responding controller
will send the Acknowledgement PGN with the control byte set to one, for Negative Acknowledgement. The
remaining portions of the ISO 11783-specified PDU format and Parameter Group must be filled in appropriately (see
3.4.4)
Parameter Group Name: PROPRIETARY A
Definition: This proprietary PG uses the Destination Specific PDU Format allowing
manufacturers to direct their proprietary communications to a specific
destination controller. How the data field of this message is used is up to each
manufacturer. Use of proprietary messages is at the manufacturers discretion
with the constraint that significant percentages (2 % or more ) of system network
utilization must be avoided.
Transmission Repetition Rate: Per user requirements
Data Length: 0 to 8 bytes
Data Page: 0
PDU Format: 239
PDU Specific field: Destination Address
Default Priority: 6
Parameter Group Number: 61184 (00EF00 )
Byte: 1-8 Manufacturer-specific use
Data ranges for parameters used by this Group Function: None defined by ISO 11783
Parameter Group Name: PROPRIETARY B
Definition: This proprietary PG uses the PDU2 Format message allowing manufacturers to
define the PS (GE) field content as they desire. However, significant
percentages (2 % or more ) of system network utilization must be avoided. How
the PS (GE) and data fields of this message are used is up to each
manufacturer. The data length of these messages has been left up to each
manufacturer. Therefore, two manufacturers may use the same GE value and it
©
may very well have a different data length code. Receivers of this information
would need to differentiate between the two manufacturers.
Transmission Repetition Rate: Per user requirements
Data Length: 0 to 8 bytes
Data Page: 0
PDU Format: 255
PDU Specific field: Group Extension (manufacturer assigned)
Default Priority: 6
Parameter Group Number: 65280 to 65535 (00FF00 to 00FFFF )
16 16
Byte: 1-8 Manufacturer-defined usage
Data ranges for parameters
used by this Group Function: Manufacturer-defined usage will result in the Data Length Code being unique
per component supplier and source address. Caution should be used when
using the Proprietary B Parameter Group (PGN = 65280).
3.5 Message priority
The CAN data frame priority shall be according to CAN 2.0B. The value within the CAN identifier field determines
the message priority. A low value (0) has a high priority, while the largest CAN identifier has the lowest priority. The
assignment are identified in the application layer following the guidelines in 3.9 and as defined in [2].
3.6 Bus access
When the bus is free, any controller may begin transmitting a frame. If two or more controllers start to transmit
frames at the same time, the bus access conflict is resolved by contention-based arbitration using the CAN Data
Frame Identifier. The mechanism of arbitration ensures that neither information nor time is lost. The transmitter with
the frame of the highest priority gains bus access.
3.7 Contention-based arbitration
During arbitration, every transmitter compares the level of the bit transmitted with the level that is monitored on the
bus. If these levels are equal, the controller may continue to send. When a "recessive" level is sent and a
"dominant" level is monitored, that controller has lost arbitration and must withdraw without sending one more bit.
When a "dominant" level is sent and a "recessive" level is monitored that controller detects a bit error.
3.8 Error detection
The following measures are provided for detecting errors:
— monitoring (transmitters compare the bit levels to be transmitted with the bit level detected on the bus);
— bit Cyclic Redundancy Check (CRC);
— variable bit stuffing with a stuff width of 5;
— frame format check.
More detailed explanation regarding these error detection techniques is provided in the CAN 2.0 B specification [5].
3.9 Assignment process for Source Addresses and Parameter Group Numbers
The protocol data units that are available provide for two different formats, PDU1 and PDU2. Parameter Groups are
assigned specifically to use either PDU1 format or PDU2 format. Once assigned to a format the other is not
available for that Parameter Group. PDU1 format must be used anytime it is necessary to direct a Parameter Group
to a specific destination. The assignment of a Parameter Group should be done using the following characteristics:
©
ISO ISO 11783-3:1998(E)
priority, update rate, importance of the data in the packet to other network controllers, and length of the data
associated with the Parameter Group. In order to help with this assignment process, a request form has been
created which should be used when requesting new Source Addresses or Parameter Group Number
assignments [2].
Table 5 provides a template for assigning Parameter Group Numbers. Note that the priority column is used to
assign a default priority value for each PGN. The priority field should be programmable for each PGN value so that
network tuning can be performed by an OEM if necessary. Although any PGN can be requested, requests are
strongly discouraged for messages that are already periodically broadcast.
Messages should be assigned a Parameter Group Number which requires a destination only if it is a parameter
intended to directly control (command) one of several specific controllers. Otherwise a Parameter Group Number
should be selected without a destination so that any controller can have access to the parameters within the
message.
Source Addresses are assigned in a linear fashion without concerns for message priority, update rate, or
importance.
Parameter Group Numbers are assigned linearly to the various sections of table 5 based on the criteria provided on
the Parameter Group Number and Source Address Request form. Note that multi-packet messages are not
permitted when the repetition rate is greater than or equal to 10 Hz.
3.9.1 Address assignment criteria
The number of unassigned addresses according to ISO 11783 is limited and new address assignments must be
made efficiently. The maximum number of addresses assigned within the system cannot exceed 256. Additions to
the address definitions therefore must be limited to units that provide specific functions within the tractor or
implement. Examples of specific functions include the currently defined addresses for engine, transmission, brakes
and the fuel system. Functions proposed for new address assignments within the standard should have a scope
similar to currently defined addresses and should be useful to most ISO 11783 users.
3.9.2 Parameter Group assignment criteria
The number of available unassigned Parameter Groups according to ISO 11783 is limited when compared to the
large number that might be proposed for forestry or agricultural applications. The need for large numbers of
Parameter Groups is alleviated by features provided by ISO 11783. Three primary communication methods are
provided by ISO 11783 and appropriate use of each type allows effective use of the available Parameter Groups.
The three communications methods are:
— PDU1 Format (PS = Destination Address allowing destination specific communications);
— PDU2 Format (PS = Group Extension);
— Proprietary Communications using two pre-defined proprietary Parameter Group Numbers.
Each of the communications methods has an appropriate use. Destination specific Parameter Groups are needed
where the same message must be directed to one or another destination. A torque control message is defined in
ISO 11783 which may be sent to an engine. In the case of more than one engine, this message must be sent only
to the desired engine and a destination specific Parameter Group is needed and has been assigned. PDU2 Format
communications apply in several situations, including:
— messages sent from a single or multiple sources to a single destination;
— messages sent from a single or multiple sources to multiple destinations.
PDU2 communications cannot be used where a message must be sent to one or another destination and not to
both.
©
Table 5 —Parameter Group Number template according to ISO 11783
P DP PF PS Parameter Group Definition Multipacket PGN
0 0 DA PDU1 Format — less than 100 ms NA 000
0 1 DA | 256
...
|
↓
_______________________________
Boundary x
↑
... |
0 238 DA PDU1 Format — greater than 100 ms Allowed 60928
0 239 DA Proprietary — 61184
0 240 0 PDU2 Format — less than 100 ms NA 61440
0 240 0 | 61441
... |
↓
_______________________________
Boundary y
↑
...
0 254 254 | 65278
0 254 255 PDU2 Format — greater than 100 ms Yes 65279
0 255 un PDU2 Format — Proprietary — 65280 - 65535
1 0 DA PDU1 Format — less than 100 ms NA 65536
1 1 DA | 65792
... |
↓
_______________________________
Boundary x1
↑
...
1 238 DA PDU1 Format — greater than 100 ms 126464
1 239 DA PDU1 Format — greater than 100 ms Allowed 126720
1 240 0 PDU2 Format — less than 100 ms NA 126976
1 240 1 | 126977
... |
↓
_______________________________
Boundary y1
↑
...
1 255 253 |
1 255 254 PDU2 Format — greater than 100 ms Allowed 131070
1 255 255 PDU2 Format — greater than 100 ms Allowed 131071
Key
DP Data Page (1 bit) GE Group Extension (8 bits)
PF PDU Format (8 bits) P Priority
PS PDU Specific Field (8 bits) NA Not allowed
DA Destination Address (8 bits) un Undefined
PGN Parameter Group Number (3 bytes)
The third communications method defin
...

NORME ISO
INTERNATIONALE 11783-3
Première édition
1998-07-01
Tracteurs et machines 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
A
Numéro de référence
Sommaire
1 Domaine d'application.1
2 Description générale .1
3 Exigences techniques .1
3.1 Format de la trame de message .1
3.2 Unité de données de protocole (PDU) .4
3.3 Formats d'unités de données de protocole (PDU) .8
3.4 Type de messages.9
3.5 Priorité des messages.13
3.6 Accès au bus.14
3.7 Arbitrage des conflits d'accès.14
3.8 Détection d'erreurs .14
3.9 Processus d'affectation des adresses source et des numéros de groupe de paramètres.14
3.10 Fonctions de protocole de transport.17
3.11 Exigences de traitement des PDU.23
3.12 Notes relatives à l'application .23
Annexe A (normative) Traitement des PDU conformément à l’ISO 11783 — Sous-programme type de
réception.25
Annexe B (normative) Séquences de transfert du protocole de transport .26
Annexe C (informative) Exemples de modes de communication.30
Annexe D (informative) Bibliographie .32
©  ISO 1998
Droits de reproduction réservés. Sauf prescription différente, 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 et les microfilms, sans l'accord écrit de l'éditeur.
Organisation internationale de normalisation
Case postale 56 • CH-1211 Genève 20 • Suisse
Internet [e-mail]
X.400 c=ch; a=400net; p=iso; o=isocs; s=central
Imprimé en Suisse
ii
© ISO
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 (CEI) en ce qui concerne la normalisation électrotechnique.
Les projets de Normes internationales adoptés par les comités techniques sont soumis aux comités membres pour
vote. Leur publication comme Normes internationales requiert l'approbation de 75 % au moins des comités
membres votants.
La Norme internationale ISO 11783-3 a été élaborée par le comité technique ISO/TC 23, Tracteurs et machines
agricoles et forestiers, sous-comité SC 19, Électronique en agriculture.
L'ISO 11783 comprend les parties suivantes, présentées sous le titre général Tracteurs et machines 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
 Partie 2: Couche physique
 Partie 3: Couche liaison de données
 Partie 4: Couche pour le réseau
 Partie 5: Gestion du réseau
 Partie 6: Terminal virtuel
 Partie 7: Couche d'applications de base
 Partie 8: Groupe motopropulseur
 Partie 9: Interface de contrôle commande tracteur
 Partie 10: Couche de traitement de données
 Partie 11: Contrôleur de tâches et système et gestion pour échange de données
Les annexes A et B font partie intégrante de la présente partie de l’ISO 11783. Les annexes C et D sont données
uniquement à titre d'information.
iii
© ISO
Introduction
Les 11 parties de l'ISO 11783 prescrivent un système de communication pour les équipements agricoles fondé sur
le protocole CAN 2.0 B. Les documents SAE J 1939, sur lesquels certaines parties de l’ISO 11783 sont également
fondées, ont été développés conjointement pour une utilisation dans des applications pour camions et autobus et
pour des applications dans la construction et l'agriculture. Les documents communs ont été élaborés pour
permettre l'utilisation, moyennant des modifications minimales, d'appareils électroniques conformes aux exigences
de la norme SAE J 1939 relatives aux camions et autobus, dans les équipements agricoles et forestiers.
L'objet de l'ISO 11783 est de fournir un système ouvert interconnecté pour les systèmes électroniques de bord. Elle
a pour but de permettre à des appareils électroniques de communiquer entre eux en fournissant un système
normalisé.
L’Organisation internationale de normalisation (ISO) appelle l’attention sur le fait qu’il est déclaré que la conformité
avec les dispositions de la présente partie de l’ISO 11783 peut impliquer l’utilisation d’un brevet intéressant le
protocole CAN (Controller Area Network) dont il est question dans tout le document.
L’ISO ne prend pas position quant à la preuve, à la validité, à la portée de ces droits de propriété.
Le détenteur de ces droits de propriété à donné l’assurance à l’ISO qu’il consent à négocier des licences avec des
demandeurs du monde entier, à des termes et conditions raisonnables et non discriminatoires. À ce propos, la
déclaration du détenteur de ces droits de propriété est enregistrée à l’ISO. Des informations peuvent être
demandées à:
Robert Bosch GmbH
Wernerstraße 51
Postfach 30 02 20
D-70442 Stuttgart-Feuerbach
Allemagne
L’attention est d’autre part appelée sur le fait que certains des éléments de la présente partie de l’ISO 11783
peuvent faire l’objet de droits de propriété autres que ceux qui ont été mentionnés ci-dessus. L’ISO ne saurait être
tenue pour responsable de l’identification de ces droits de propriété en tout ou partie.
iv
NORME INTERNATIONALE  © ISO ISO 11783-3:1998(F)
Tracteurs et machines 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
La présente partie de l’ISO 11783 prescrit un réseau de commande et de communication de données en série pour
tracteurs forestiers ou agricoles, ou instruments portés, semi-portés, remorqués ou automoteurs. Son but est de
normaliser la méthode et le format de transfert des données entre capteurs, actionneurs, organes de commande,
dispositifs de stockage de l'information et dispositifs d'affichage, que ces éléments soient montés ou intégrés au
[6]
tracteur ou à l’instrument. La présente partie de l’ISO 11783 décrit la couche liaison de données «identificateur
[5]
CAN à 29 bits» .
2 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 CAN avec la synchronisation, 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.
3 Exigences techniques
3.1 Format de la trame de message
Le format de la trame du message doit être conforme aux exigences CAN. La spécification CAN à laquelle il est fait
[5]
référence dans tout ce document est la spécification CAN 2.0 B . Il convient de noter que lorsqu'il existe des
différences entre la spécification CAN mentionnée ci-dessus et l'ISO 11783, cette dernière constituera le document
directeur.
Le document CAN spécifie, dans une discussion relative à l'acheminement de l'information, que les adresses des
contrôleurs 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 contrôleurs soit utilisé pour
éviter que plusieurs contrôleurs 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.
La publication CAN 2.0 B contient la spécification de deux formats de trame de message, la trame standard et la
trame étendue. La compatibilité CAN 2.0 B implique que des messages des deux formats puissent être
potentiellement présents sur un seul réseau, en utilisant des 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 elle ne définit une stratégie complète que pour les communications normalisées utilisant le format
de trame étendue. Tous les messages à format de trame standard sont destinés à une utilisation exclusive selon
les règles définies dans la présente partie de l’ISO 11783.
En conséquence, les contrôleurs conformes à l’ISO 11783 doivent utiliser le format de trame étendue. Les
messages à format de trame standard peuvent demeurer sur le réseau, mais uniquement comme décrit dans la
présente partie de l’ISO 11783.
© ISO
NOTE — Les contrôleurs de trame standard ne répondent pas aux messages de gestion du réseau et ne seront pas en
mesure de prendre en charge la stratégie pour des communications normalisées.
La trame de données CAN est divisée en plusieurs champs de bits (voir figure 1). Le nombre et la répartition des
bits dans les champs d'arbitrage et de contrôle diffèrent entre les messages à trame CAN standard et les messages
à trame CAN étendue. Les messages à trame CAN standard, illustrés à la figure 1 a), contiennent 11 bits
identificateurs dans le champ d'arbitrage alors que les messages à trame CAN étendue, 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.
3.1.1 Format de trame de message conforme à l’ISO 11783 (format de trame étendue CAN 2.0 B)
Le message à trame CAN étendue, tel qu'illustré à la figure 1, contient une seule unité de données de protocole
(PDU). Les PDU sont composées de sept champs prédéfinis. Ces champs sont remplis à l'aide des informations
fournies par la couche application. Ces champs sont les suivants: champ de priorité, champ réservé, champ de
page de données, champ de format PDU, champ spécifique PDU (qui peut être une adresse de destination, une
extension de groupe ou une exclusivité), champ d'adresse source et champ de données. Ces champs doivent être
ensuite regroupés dans une ou plusieurs trames de données CAN 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
convient de reconnaître que certaines définitions de groupes de paramètres nécessitent plusieurs trames de
données CAN pour transmettre leurs informations. 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 de l'identificateur à 11 bits pour l'ISO 11783. Une définition complète de chacune des affectations de
champs de bits conformes à l’ISO 11783 est donnée en 3.3.
Trame de données CAN
Longueur maximale de la trame avec garnissage binaire = 127 bits
Champ
Champ Champ de
d'arbitrage de contrôle données
12 bits 8 bits
R I
S Champ
DLC
Champ de données
Identificateur r CRC EOF
O T D
ACK
o
11 bits 4 bits
0 à 64 bits
15 bits 2 bits 7 bits
F R E
Bourrage binaire Sans bourrage binaire
a)  Format de la trame normale CAN
Trame de données CAN
Longueur maximale de trame avec garnissage binaire = 150 bits
Champ de Champ de
Champ
d'arbitrage contrôle
données
32 bits
8 bits
Champ
S Identificateur R I R r r DLC Champ de données EOF
Identificateur CRC
O ACK
T D T 1 o
F
11 bits 18 bits 4 bits 0 à 64 bits 15 bits 7 bits
R E R 2 bits
Bourrage binaire Sans bourrage binaire
b)  Format de la trame étendue CAN
Figure 1 — Trames de données CAN
© ISO
Tableau 1 — Correspondance entre l'ISO 11783 et les champs d'arbitrage et de contrôle CAN
Identificateurs à 29 bits Identificateurs à 11 bits
1)
Bit n° CAN ISO 11783 CAN
ISO 11783
) )
1 SOF SOF
SOF* SOF*
2 ID 28 P 3 ID 11 P 3
3 ID 27 P 2 ID 10 P 2
4 ID 26 P 1 ID 9 P 1
5 ID 25 R 1 ID 8 SA 8
6 ID 24 DP ID 7 SA 7
7 ID 23 PF 8 ID 6 SA 6
8 ID 22 PF 7 ID 5 SA 5
9 ID 21 PF 6 ID 4 SA 4
10 ID 20 PF 5 ID 3 SA 3
11 ID 19 PF 4 ID 2 SA 2
12 ID 18 PF 3 ID 1 SA 1
) )
13 SRR (r) RTR (x)
SRR* RTR*
14 IDE (r) ) IDE (d) )
IDE* IDE*
)
15 ID 17 PF 2 R 0
R 0*
16 ID 16 PF 1 DLC 4 DLC 4
17 ID 15 PS 8 DLC 3 DLC 3
18 ID 14 PS 7 DLC 2 DLC 2
19 ID 13 PS 6 DLC 1 DLC 1
20 ID 12 PS 5
21 ID 11 PS 4
22 ID 10 PS 3
23 ID 9 PS 2
24 ID 8 PS 1
25 ID 7 SA 8
26 ID 6 SA 7
27 ID 5 SA 6
28 ID 4 SA 5
29 ID 3 SA 4
30 ID 2 SA 3
31 ID 1 SA 2
32 ID 0 SA 1
)
33 RTR (x)
RTR*
)
34 r 1
r 1*
)
35 r 0
r 0*
36 DLC 4 DLC 4
37 DLC 3 DLC 3
38 DLC 2 DLC 2
39 DLC 1 DLC 1
SOF Bit de début de la trame R# Bit réservé conforme à l’ISO 11783 n° n
ID## Identificateur du bit n° n SA# Bit d'adresse source conforme à l’ISO 11783 n° n
SRR Demande à distance de remplacement DP Page de données conforme à l’ISO 11783 n° n
RTR Bit de demande de télétransmission PF# Bit de format PDU conforme à l’ISO 11783 n° n
IDE Bit d'extension d'identificateur PS# Bit spécifique PDU conforme à l’ISO 11783 n° n
r# Bit réservé CAN n° n (d) Bit dominant
DLC# Bit de code de longueur de données n° n (r) Bit récessif
P# Bit de priorité conforme à l’ISO 11783 n° n (x) État binaire dépendant du message
*) Bit défini dans CAN, inchangé dans l'ISO 11783.
1) Format requis pour identificateurs d'exclusivité à 11 bits.
© ISO
Noeud 1
Noeud 5
Application
Application (Priorité, R, DP, PF, PS, SA, données) (Priorité, R, DP, PF, PS, SA, données)
Réseau
Réseau
Liaison de données
Liaison de données
Un ou plusieurs PDU Un ou plusieurs PDU
Contrôle de liaison logique (LLC)
Contrôle de liaison logique (LLC)
Contrôle d'accès au
Contrôle d'accès au
Un ou plusieurs Un ou plusieurs
messages CAN
support (MAC) support (MAC)
messages CAN
Physique
Physique
Légende
PF Format PDU
R Réservé
DP Page de données
SA Adresse source
PS Spécifique à la PDU
Figure 2 — Application du modèle OSI par l'ISO 11783
3.1.2 Numéro de groupe de paramètres (PGN)
Le numéro de groupe de paramètres (PGN) est déterminé à l'aide des composants suivants: bit réservé, bit de
page de données, champ de format PDU (8 bits) et champ d'extension de groupe (8 bits). Ces 18 bits sont utilisés
pour définir le PGN à 24 bits. Chaque fois qu'il est nécessaire d'identifier un groupe de paramètres dans le champ
de données d'une trame de données CAN, il est exprimé en 24 bits, les bits les plus significatifs étant mis à zéro.
Se reporter au tableau 2 pour une illustration des PGN, de leurs bits correspondants et de leur conversion en un
nombre décimal.
La procédure de conversion des champs de bits en PGN est la suivante. Si la valeur du format PDU (PF) est
inférieure à 240 (F0 ), l'octet inférieur du PGN est mis à zéro.
NOTE — Les 131 072 combinaisons (2 ) ne peuvent pas toutes être affectées comme PGN. Seules 8 670 combinaisons
sont disponibles pour l'affectation (calculées de la manière suivante: 2 pages · [240 + (16 · 256)] = 8 670 en appliquant les
conventions spécifiées dans la présente partie de l’ISO 11783).
3.1.3 Prise en charge par l'ISO 11783 de messages à format de trame standard CAN 2.0 B
Il est reconnu que les contrôleurs du réseau ISO 11783 peuvent prendre en charge un format de message à trame
CAN standard (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 à format de trame CAN standard 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.
[2]
Les bits de priorité sont décrits en 3.3.1. L'adresse source est définie dans le tableau des adresses sources ou
[3]
est déterminée par des procédures décrites dans la partie de l’ISO 11783 relative à la gestion de réseau .
© ISO
NOTE — Un arbitrage incorrect des accès au bus pourrait se produire lorsque deux messages, un à trame standard et l'autre
à trame étendue, accèdent simultanément au bus. L'adresse source (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)
pourrait avoir une SA indiquant une priorité plus élevée que le bit réservé, 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.
L'ISO 11783 ne définit une stratégie complète que pour les communications normalisées utilisant le format à trame
étendue. Le matériel conforme à la spécification CAN 2.0 A ne doit pas être utilisé dans le réseau, parce que ces
versions de matériel ne permettent pas la transmission de messages à trame étendue.
3.2 Unité de données de protocole (PDU)
Les applications et/ou la couche réseau fournissent une chaîne d'informations qui sont assimilées dans une unité
de données de protocole (PDU). L'unité de données de protocole fournit un cadre permettant d'organiser les
informations et servant de clé à chaque trame de données CAN émise. L'unité de données de protocole conforme à
l’ISO 11783 doit être composée de sept champs, à savoir champ de priorité, champ réservé, champ de page de
données, champ de format PDU, champ PDU spécifique (qui peut être une adresse de destination, une extension
de groupe ou une exclusivité), champ d'adresse source et champ de données. Ces champs sont ensuite regroupés
dans une ou plusieurs trames de données CAN 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.
NOTE — Il convient de savoir que certaines définitions de numéro de groupe de paramètres nécessiteront plusieurs trames
de données CAN pour transmettre les données correspondantes.
Certains champs de la trame de données CAN 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 identificateurs SOF, SRR, IDE, RTR, des parties du champ de
contrôle, le champ CRC, le champ ACK et le champ EOF. Ces champs sont déterminés par la définition du
protocole CAN et n'ont pas été modifiés pour l'ISO 11783. Les sept champs de la PDU sont illustrés à la figure 3.
Chacun des champs de la PDU est défini de 3.2.1 à 3.2.7.
Tableau 2 — Exemples de numéros de groupes de paramètres (PGN)
Composants du PGN PGN
PGN (msb) PGN PGN
Nombre Nombre
Octet 1 Octet 2 Octet 3 de PG cumulé Affecté par
R DP PF PS Décimal Hexadécimal affectables de PG
Bits Bit 2 Bit 1
8 à 3
0 0 0 0 0 0 000000 — — ISO
0 0 0 238 0 60928 00EE00 239 239 —
0 0 0 239 0 61184 00EF00 1 240 Constructeur
0 0 0 240 0 61440 00F000 — — ISO
0 0 0 254 255 65279 00FEFF 3 840 4 080 —
0 0 0 255 0 65280 00FF00 — — Constructeur
0 0 0 255 255 65535 00FFFF 256 4 336 —
0 0 1 0 0 65536 010000 — — ISO
0 0 1 239 0 126720 01EF00 240 4 576 —
0 0 1 240 0 126976 01F000 — — ISO
0 0 1 255 255 131071 01FFFF 4 096 8 672 —
© ISO
Priorité, R, DP, PF, PS, SA, Champ de
données
Nombre de bits .3., .1., .1., .8., .8., .8., .64.
Légende
R Réservé
DP Page de données
PF Format PDU
PS Spécifique à la PDU
SA Adresse source
Figure 3 — Unité de données de protocole (PDU)
3.2.1 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 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 valeur par défaut pour tous les
2 2
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 NACK, est 6 (110 ). Cela permet d'augmenter ou d'abaisser ultérieurement la
priorité au fur et à mesure que des valeurs de PGN sont affectés 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.
3.2.2 Bit réservé (R)
Ce bit est actuellement réservé en vue d'une utilisation dans une Norme internationale ultérieure. Il convient de ne
pas confondre ce bit réservé avec les bits réservés CAN. Il convient que tous les messages mettent le bit réservé
ISO à zéro au moment de la transmission. 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.
3.2.3 Page de données (DP)
Le bit de page de données détermine une page auxiliaire de descriptions de groupe de paramètres. L'affectation de
tous les numéros de groupes de paramètres disponibles dans la page 0 doit être achevée (remplie) avant que les
affectations de la page 1 soient effectuées (voir 3.9 qui traite des affectations de PGN).
3.2.4 Format PDU (PF)
Le format PDU 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 numéro de groupe de paramètres (PGN) affecté au champ de données CAN. Les PGN doivent être
utilisés pour identifier ou 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. Les PGN identifient ou affectent une étiquette à des
informations pouvant nécessiter une ou plusieurs trames de données CAN pour transmettre l'information. Si la
quantité d'information dépasse 8 octets, un message à plusieurs paquets devra être transmis. Un PGN peut
représenter un ou plusieurs paramètres, un paramètre étant un élément d'information comme, par exemple, la
vitesse de rotation d'un moteur. Même si l'étiquette de PGN peut être utilisée pour un seul paramètre, il est
recommandé de regrouper plusieurs paramètres de telle sorte que les 8 octets du champ de données soient
utilisés.
La définition de deux PGN exclusifs a été établie afin de permettre l'utilisation des formats PDU1 et PDU2.
L'interprétation des informations exclusives varie selon le constructeur. Par exemple, même si deux moteurs
différents peuvent utiliser la même adresse source, les communications propres au constructeur A seront très
probablement différentes de celles du constructeur B.
© ISO
3.2.5 Spécifique à la PDU (PS)
Le champ spécifique à la PDU est un champ à 8 bits dont la définition dépend du format de la PDU. Selon le format
de la PDU, il peut s'agir d'une adresse de destination ou d'une extension de groupe. Voir le tableau 3.
Tableau 3 — Définition du champ spécifique à la PDU
Format Valeur du champ de format PDU Champ spécifique à la PDU
PDU1 0 à 239 Adresse de destination
PDU2 240 à 255 Extension de groupe
3.2.5.1 Adresse de destination (DA)
Ce champ 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.
3.2.5.2 Extension de groupe (GE)
Le champ d'extension de groupe, 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 4 096 groupes de paramètres ne sont disponibles qu'en
utilisant le format PDU avec extension de groupe. 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. Au total, 8 672 groupes de
paramètres peuvent être définis en utilisant les deux pages de données actuellement disponibles.
NOTE — Lorsque les quatre bits les plus significatifs du champ de format PDU sont fixés, cela signifie que le champ PS est
une extension de groupe.
Le nombre total d'étiquettes de groupes de paramètres disponibles peut être calculé de la manière suivante:
[240 + (16 x 256)] · 2 = 8 672
où
240 est le nombre de valeurs de champs de format PDU disponibles par page de données (c'est-à-dire
format PDU1);
16 est le nombre de valeurs de format PDU par valeur d'extension de groupe (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).
3.2.6 Adresse source (SA)
La longueur du champ d'adresse source est de huit bits. Il ne doit y avoir qu'un seul contrôleur sur le réseau avec
une adresse source donnée. En conséquence, le champ d'adresse de source assure que l'identificateur CAN est
unique, comme requis par le CAN. La gestion et l'affectation des adresses ainsi que les procédures empêchant la
[3]
duplication et l'affectation d'adresses sources seront détaillées dans une future Norme internationale .
3.2.7 Champ de données
3.2.7.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é, les huit
octets d'information de la trame CAN peuvent alors être utilisés. Il est généralement recommandé que huit octets
soient affectés ou réservés pour toutes les affectations de numéro de groupe de paramètres (PGN) susceptibles
© ISO
d'être étendues ultérieurement. Cette procédure fournit un moyen d'ajouter facilement des paramètres et n'est pas
incompatible avec les 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). Il est important de noter qu'une fonction de
groupe donnée (voir 3.4.5) 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 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.
3.2.7.2 Données comprises entre 9 et 1 785 octets
Lorsque le nombre d'octets d'information requis pour exprimer un groupe de paramètres donné est compris entre 9
et 1 785, la communication de ces données est effectuée par des trames CAN multiples. En conséquence, le terme
«paquets multiples» est utilisé pour décrire ce type de PGN. Lorsque plusieurs trames de données CAN sont
requises pour envoyer un groupe de paramètres donné, la fonction de 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) 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 3.10).
Toutes les trames de données CAN associées à une réponse donnée à paquets multiples sont requises pour avoir
un DLC de 8. Tous les octets d'information non utilisés sont mis à «non disponible». Le nombre d'octets par paquet
est fixe; cependant l'ISO 11783 définit des messages à paquets multiples qui ont un nombre variable ou fixe de
paquets. Le PGN pour les codes de diagnostic actifs est un exemple de message à paquets multiples ayant un
nombre variable de paquets. Les groupes de paramètres qui sont définis comme des groupes à paquets multiples
n'utilisent le protocole de transport que lorsque le nombre d'octets d'information à transmettre est supérieur à huit.
3.3 Formats d'unités de données de protocole (PDU)
Les formats de PDU disponibles sont illustrés à la figure 4. Deux formats de PDU sont définis: le format PDU1
(PS = adresse de destination) et le format PDU2 (PS = extension de groupe). Le format PDU1 permet de diriger la
trame de données CAN vers une adresse spécifique de destination (contrôleur). Le format PDU2 ne peut
transmettre que des trames de données CAN n'ayant pas de destination spécifique. La création de deux formats
distincts de PDU a été établie afin d'offrir un plus grand nombre de combinaisons possibles de numéros de groupes
de paramètres tout en assurant toujours les communications à destination spécifique. Les définitions des groupes
de paramètres exclusifs ont été affectées de telle sorte que les deux formats de PDU soient disponibles pour des
communications exclusives. Une méthode normalisée a été déterminée pour les communications exclusives afin
d'éviter tout conflit éventuel dans l'usage des identificateurs.
La définition de deux PGN exclusifs a été établie afin de permettre l'utilisation des formats PDU1 et PDU2.
L'interprétation des informations exclusives varie selon le constructeur. Par exemple, même si deux moteurs
différents peuvent utiliser la même adresse source, les communications propres au constructeur A seront très
probablement différentes de celles du constructeur B.
3.3.1 Format PDU1
Le format PDU1 permet d'envoyer les groupes de paramètres concernés vers une (des) destination(s) spécifique(s)
ou globale(s). Le champ spécifique à la PDU (PS) contient une adresse de destination (DA). Les messages au
format PDU1 peuvent être demandés ou envoyés comme des avertissements.
Les messages au format PDU1 sont déterminés par le champ de format PDU (PF). Lorsque la valeur du champ de
format PDU est comprise entre 0 et 239, le message est au format PDU1. Le format du message PDU1 est illustré
à la figure 4.
Les groupes de paramètres nécessitant une destination (PDU1) et un temps minimal de latence commencent à
PF = 0 et augmentent par incréments vers x (ou x1) (voir tableau 5).
© ISO
Les groupes de paramètres nécessitant une destination et pour lesquels le temps de latence n'est pas critique
commencent à PF = 239 et diminuent par incréments vers x (ou x1) (voir tableau 5).
Un PF égal à 239 (bit réservé = 0 et bit de page de données = 0) est affecté pour un usage exclusif. Dans ce cas, le
champ spécifique PDU (PS) est une adresse de destination (voir 3.4.5). Le PGN propre au constructeur A est
61184.
PDU1
Priorité, R, DP, PF, PS(DA), SA, Champ de
données
Nombre de bits .3., .1., .1., .8., .8., .8., .64.
PDU2
Priorité, R, DP, PF, PS(GE), SA, Champ de
données
Nombre de bits .3., .1., .1., .8., .8., .8., .64.
Légende
R Réservé SA Adresse source
DP Page de données DA Adresse de destination
PF Format PDU GE Extension de groupe
PS Spécifique à la PDU
Figure 4 — Formats de PDU disponibles
3.3.2 Format PDU2
Le format PDU2 ne peut être utilisé que pour transmettre des groupes de paramètres sous forme de messages
généraux. Les messages au format PDU2 peuvent être demandés ou envoyés comme des avertissements. Le
choix du format PDU2, au moment où le PGN est affecté, interdit toute possibilité de diriger le PGN vers une
destination spécifique. Le champ spécifique PDU (PS) contient une extension de groupe (GE).
Les messages au format PDU2 sont définis comme étant ceux dans lesquels la valeur du format PDU (PF) est
comprise entre 240 et 255 (voir tableau 3). Le format du message PDU2 est illustré à la figure 4.
Le PGN des messages qui sont transmis à des cadences de mise à jour élevées (généralement inférieures à
100 ms) commence à PF = 240 et augmente par incrément vers y (ou y1) (voir tableau 5).
Le PGN des messages qui sont uniquement demandés, envoyés lors d'une modification ou qui sont envoyés à des
cadences de mise à jour faibles (généralement supérieures à 100 ms) commence à PF = 254 et diminue par
incréments vers y (ou y1) (voir tableau 5).
Un PF égal à 255 (bit réservé = 0 et bit de page de données = 0) est affecté pour un usage exclusif. Le champ
spécifique PDU est laissé afin d'être défini et utilisé par chaque constructeur (voir 3.4.5). Le PGN propre au
constructeur B est compris entre 65280 et 65535.
3.4 Type de messages
Cinq types de messages sont actuellement pris en charge. Ces types sont: commandes, demandes,
diffusions/réponses, accusé de réception et fonctions de groupe. Le type spécifique de message est identifié par le
© ISO
[2]
PGN qui lui est affecté . Le bit RTR (défini dans le protocole CAN pour des trames de requête à distance) ne doit
pas être utilisé à l'état récessif (1 logique). En conséquence, les demandes de télétransmission (RTR = 1) ne sont
pas disponibles pour un usage conformément à l’ISO 11783.
3.4.1 Commande
Ce type de message classe en catégories les groupes de paramètres qui commandent une destination spécifique
ou globale à partir d'une source. Le destinataire est ensuite censé effectuer des actions spécifiques fondées sur la
réception de ce type de message de commande. Des messages au format PDU1 (PS = adresse de destination) et
PDU2 (PS = extension de groupe) peuvent être utilisés pour les commandes. Les modes de commande peuvent
par exemple comprendre «Contrôle de transmission», «Demande d'adresse», «Contrôle de couple/vitesse», etc.
3.4.2 Demande
Ce type de message, identifié par le PGN, fournit la capacité de demander une information globalement ou à une
destination spécifique. Les demandes spécifiques à une destination sont connues sous le nom de demandes à une
destination spécifique. L'exemple d'information ci-après affecte un PGN au groupe de paramètres «Demande
PGN». L'information est dans le même format que les définitions des groupes de paramètres donnés dans
l'ISO 11783.
Nom du groupe de paramètres: Demande de PGN
Définition: Utilisé pour demander un groupe de paramètres à un contrôleur de
réseau.
Fréquence de répétition de transmission: Selon les exigences de l'utilisateur; il est généralement
recommandé que les demandes ne se produisent pas plus de deux
ou trois fois par seconde.
Longueur des données: 3 octets
Page de données: 0
Format PDU: 234
Champ spécifique PDU: Adresse de destination
Priorité par défaut: 6
Numéro de groupe de paramètres: 59904 (00EA00 )
Octet 1, 2, 3: Numéro de groupe de paramètres demandé (voir 3.1.2)
Le tableau 4 contient deux exemples montrant comment utiliser la demande de PGN.
Tableau 4 — Exemples de demandes de PGN
Utilisation des champs spécifiés dans un format PDU1 selon l'ISO 11783
Type de message
PF PS (DA) SA Donnée 1 Donnée 2 Donnée 3
1) 1)
Demande globale 234 255 (émetteur SA 1 PGN
PGN lsb PGN msb
de réponse) (demandeur)
1) 1)
Demande spécifique 234 SA 2 (émetteur SA 1 PGN
PGN lsb PGN msb
de réponse) (demandeur)
1) Le PGN dans le champ de données est utilisé pour identifier les informations demandées.
lsb = bit le moins significatif;
msb = bit le plus significatif
© ISO
Une destination spécifiée (non globale) doit toujours fournir une réponse, même s'il s'agit d'un accusé de réception
négatif (NACK) indiquant que la valeur de PGN concernée n'est pas prise en charge. La réponse à une demande
globale ne doit pas être un accusé de réception négatif (NACK) lorsque le PGN concerné n'est pas pris en charge
par un contrôleur.
NOTE — Certains PGN sont en plusieurs paquets, de telle sorte que plusieurs trames de données CAN peuvent apparaître
pour une seule demande.
3.4.3 Diffusion/réponse
Ce type de message peut être la diffusion non sollicitée d'informations par un contrôleur ou peut être la réponse à
une commande ou une demande.
3.4.4 Accusé de réception
Il existe deux formes d'accusé de réception disponibles. La première forme est assurée par le protocole CAN. Elle
consiste en un accusé de réception interne à la trame qui confirme qu'un message est reçu par au moins un
contrôleur. Par ailleurs, un autre accusé de réception est fourni par l'absence de trames d'erreur CAN. Leur
absence confirme que tous les contrôleurs alimentés et connectés ont reçu le message correctement.
La deuxième forme d'accusé de réception, qui se trouve dans le champ de données, est une réponse de diffusion
normale, ACK ou NACK à une commande ou demande spécifique, telle qu'assurée par une couche application. Le
type d'accusé de réception requis pour certains groupes de paramètres doit être défini dans la couche application.
Nom du groupe de paramètres: Accusé de réception
Définition: Le PG d'accusé de réception est utilisé pour fournir un mécanisme
d'établissement de liaison entre les contrôleurs émetteur et
récepteur.
Fréquence de répétition de transmission: À réception d'un PGN qui nécessite cette forme d'accusé de
réception.
Longueur des données: 8 octets
Page de données: 0
Format PDU: 232
1)
Champ spécifique PDU:
Adresse de destination = globale (255)
Priorité par défaut: 6
Numéro de groupe de paramètres: 59392 (00E800 )
Gammes de données pour les paramètres utilisés par ce type de message:
Octet de contrôle:
0 et 1 Voir définition ci-après
2 à 255 Réservé pour affectation dans une future Norme internationale

1)  L'adresse de destination globale rend possible un filtrage sur un identificateur CAN de tous les messages d'accusé de
réception.
© ISO
Accusé de réception positif:
Octet de contrôle: 0
Octet:  1 Octet de contrôle = 0, accusé de réception positif (ACK)
2 à 5 Réservé pour affectation dans une future Norme internationale,
envoyer chacun de ces octets comme FF
6 à 8 PGN de l'information demandée
Accusé de réception négatif:
Octet de contrôle: 1
Octet:  1 Octet de contrôle = 1, accusé de réception négatif (NACK)
2 à 5 Réservé pour affectation dans une future Norme internationale,
envoyer chacun de ces octets comme FF
6 à 8 PGN de l'information demandée
3.4.5 Fonction de groupe
Ce type de message est utilisé pour des groupes de fonctions spéciales (par exemple fonctions exclusives,
fonctions de gestion du réseau, fonctions de transport à paquets multiples, etc.). Chaque groupe de fonctions est
reconnu par le PGN qui lui est affecté. La fonction elle-même est définie dans la structure de données. De plus
amples explications sur l'exclusivité des fonctions de groupe et le protocole de transport sont données dans les
paragraphes qui suivent. La fonction d'exclusivité d'un groupe fournit un moyen de transmettre des messages
exclusifs en éliminant les conflits d'usage d'identificateurs CAN entre différents constructeurs. Elle fournit également
un moyen de recevoir et de distinguer des messages exclusifs lorsque leur utilisation est souhaitée. Il peut s'avérer
nécessaire pour les fonctions de groupe d'assurer leurs propres mécanismes de demande, ACK et/ou NACK.
Une demande utilisant PGN 59904 (voir 3.4.2) peut être utilisée pour rechercher si un groupe spécifique de
paramètres du type de message fonction de groupe, est pris en charge. S'il est pris en charge, le contrôleur qui
émet la réponse transmettra le PGN d'accusé de réception avec un octet de contrôle égal à zéro, pour signifier un
accusé de réception positif. S'il n'est pas pris en charge, le contrôleur qui émet la réponse transmettra le PGN
d'accusé de réception avec un octet de contrôle mis à un, pour signifier un accusé de réception négatif. Les autres
parties du format de PDU conformes à l’ISO 11783 et du groupe de paramètres doivent être complétées de
manière appropriée (voir 3.4.4)
Nom du groupe de paramètres: Propre au constructeur A
Définition: Le PG d'exclusivité utilise le format PDU à destination spécifique
permettant aux constructeurs de transmettre leurs communications
exclusives vers un contrôleur de destination spécifique. La manière
dont le champ de données de ce message est utilisé dépend de
chaque constructeur. L'utilisation de messages exclusifs est laissée
à la discrétion des constructeurs sous réserve d'éviter d'utiliser des
pourcentages importants (2 % ou plus) du réseau système.
Fréquence de répétition de transmission: Selon les exigences de l'utilisateur
Longueur des données: 0 à 8 octets
Page de données: 0
Format de la PDU: 239
© ISO
Champ spécifique PDU: Adresse de destination
Priorité par défaut: 6
Numéro de groupe de paramètres: 61184 (00EF00 )
Octet:
1 à 8 Usage spécifique au constructeur
Gammes de données pour les Aucune définie dans l'ISO 11783
paramètres utilisés par cette fonction
de groupe:
Nom du groupe de paramètres: Propre au constructeur B
Définition: Ce PG d'exclusivité utilise le message au format PDU2 permettant
aux constructeurs de définir le contenu du champ PS (GE) comme
ils le souhaitent. Toutefois, l'utilisation de pourcentages importants
(2 % ou plus) du réseau système doit être évitée. La manière dont
les champs PS (GE) et de données de ce message sont utilisés
dépend de chaque constructeur. La longueur des données de ces
messages est laissée au choix de chaque constructeur. Par
conséquent, deux constructeurs peuvent utiliser la même valeur de
PG, celle-ci pouvant très bien présenter un code de longueur de
données différent. Il convient que les récepteurs de ces
informations fassent la différence entre les deux constructeurs.
Fréquence de répétition de transmission: Selon les exigences de l'utilisateur
Longueur des données: 0 à 8 octets
Page de données: 0
Format PDU: 255
Ch
...