ISO 11783-5:2019

Tractors and machinery for agriculture and forestry - Serial control and communications data network - Part 5: Network management

This document describes the management of source addresses (SAs) for control functions (CFs) of electronic control units (ECUs), the association of addresses with the functional identification of a device and the detection and reporting of network-related errors. It also specifies procedures for initialization of network-connected ECUs.

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

Le présent document décrit la gestion des adresses sources (AS) pour les fonctions de commande (FC) des unités de commande électroniques (UCE), l'association des adresses à l'identification fonctionnelle d'un dispositif, et à la détection et la signalisation des erreurs liées au réseau. Elle spécifie également les processus d'initialisation et de réaction aux pannes d'électricité de courte durée, et les exigences minimales relatives aux UCE connectées au réseau.

General Information

• Status: Published
• Publication Date: 23-Jun-2019
• 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: 9093 - International Standard confirmed
• Start Date: 05-Dec-2024
• Completion Date: 13-Dec-2025

Relations

• Revises: ISO 11783-5:2011 - Tractors and machinery for agriculture and forestry - Serial control and communications data network - Part 5: Network management
• Effective Date: 19-Aug-2017

Overview

ISO 11783-5:2019 - part of the ISO 11783 series for tractors and machinery for agriculture and forestry - defines network management for the on-board serial control and communications data network. The standard specifies how electronic control units (ECUs) and their control functions (CFs) obtain and manage source addresses (SAs), how a device’s unique 64-bit NAME is used to associate identity with function, procedures for network initialization, and detection/reporting of network-related errors. ISO 11783-5 is harmonized with SAE J1939/81 and complements other ISO 11783 parts (physical and data link layers).

Key Topics and Requirements

• Address configuration capabilities
  • Non-configurable, self-configurable, service-configurable and command-configurable address types are defined and their behaviors specified.
  • Self-configurable CFs must select SAs (typically in the 128–247 range) and re-calculate them on conflicts.
• NAME (64-bit identifier)
  • Each CF must provide a unique 64-bit NAME that describes function and arbitration priority.
  • The NAME includes fields such as the self-configurable flag, industry group, device class and identity information.
• Address-claiming and arbitration
  • Procedures require CFs to claim an address before transmitting other messages; NAME and SA are transmitted in address-claim messages to associate identity and function.
  • Rules govern conflict resolution (higher-priority NAME wins) and reporting when a CF cannot claim an address.
• Network initialization
  • Sequences for acquiring a unique address, address claim requirements and what to do when a CF cannot obtain an address are specified.
• Network-error management
  • Detection and reporting mechanisms for network-related errors and procedures for NAME management (runtime changes) are included.

Applications and Who Uses It

• OEMs and system integrators designing tractor and agricultural machinery electronics to ensure interoperable on-board networks.
• ECU manufacturers implementing CFs that need to follow address claiming and NAME rules for predictable arbitration.
• Diagnostic and service-tool vendors providing tools for service-configurable and command-configurable address operations.
• Fleet managers and technicians ensuring reliable initialization, conflict resolution and error reporting on implement/tractor networks.
• Developers implementing ISO 11783-compatible firmware stacks or gateways between ISO 11783 and SAE J1939 systems.

Related Standards

• ISO 11783-1 - General standard for mobile data communication
• ISO 11783-2 - Physical layer (physical requirements moved here)
• ISO 11783-3 - Data link layer
• SAE J1939/81 - Related vehicle network and address-management practices

Keywords: ISO 11783-5, network management, tractors, agricultural ECUs, source address, NAME, address claiming, SAE J1939, CAN-based network.

Standards Content (Sample)

INTERNATIONAL ISO
STANDARD 11783-5
Third edition
2019-06
Tractors and machinery for
agriculture and forestry — Serial
control and communications data
network —
Part 5:
Network management
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
Reference number
©
ISO 2019
© ISO 2019
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 2019 – All rights reserved

Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Technical requirements . 2
4.1 General . 2
4.2 Address configuration capabilities . 2
4.2.1 General. 2
4.2.2 Non-configurable address . . 2
4.2.3 Self-configurable address . 3
4.2.4 Service-configurable address . 3
4.2.5 Command-configurable address . 3
4.3 NAME and address requirements . 3
4.3.1 General. 3
4.3.2 NAME . 3
4.3.3 Address. 6
4.4 Network-management procedures . 7
4.4.1 General. 7
4.4.2 Address-management messages and procedures . 7
4.4.3 NAME management message and procedures .10
4.4.4 Network-error management .19
4.5 Network initialization .20
4.5.1 Acquisition of a unique address.20
4.5.2 Address claim requirements .21
4.5.3 Other basic requirements for initialization .21
4.5.4 Message sequences .21
4.5.5 CF unable to obtain an address .26
Annex A (informative) Examples of NAME construction .28
Bibliography .30
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 on 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 the following
URL: 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 third edition cancels and replaces the second edition (ISO 11783-5:2011), which has been
technically revised.
The main changes compared to the previous edition are as follows.
— The physical requirements are moved to ISO 11783-2.
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.
iv © ISO 2019 – All rights reserved

Introduction
ISO 11783-1 to ISO 11783-14 specify a communications system for agricultural equipment based on
[4][5]
ISO 11898 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 agricultural 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. This document
[6]
is harmonized with SAE J 1939/81 . 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.
INTERNATIONAL STANDARD ISO 11783-5:2019(E)
Tractors and machinery for agriculture and forestry —
Serial control and communications data network —
Part 5:
Network management
1 Scope
This document describes the management of source addresses (SAs) for control functions (CFs) of
electronic control units (ECUs), the association of addresses with the functional identification of a
device and the detection and reporting of network-related errors. It also specifies procedures for
initialization of network-connected ECUs.
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-2, Tractors and machinery for agriculture and forestry — Serial control and communications
data network — Part 2: Physical layer
ISO 11783-3, Tractors and machinery for agriculture and forestry — Serial control and communications
data network — Part 3: Data link layer
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 11783-1 and the following 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/
3.1
current NAME
CF NAME that is transmitted in its address-claimed-message
3.2
NAME management
NM
method for changing the NAME of a CF at run time
3.3
pending NAME
NAME temporarily stored by a particular CF as the result of NAME management (3.2) messages received
from a qualified source
3.4
random transmit delay
RTxD
delay time calculated by multiplying a random number in the range 0 to 255 with 0,6 ms
Note 1 to entry: A seed to the random number generator can use the identity number in the NAME, or other
unique information within the CF.
4 Technical requirements
4.1 General
The network management specified in this document provides the definitions and procedures
necessary to uniquely identify CFs on the network, manages the assignment of addresses, and handles
network errors.
A CF’s ability to select an address depends on the CF’s address configuration capabilities as
described in 4.2.
Each CF shall be capable of providing its unique 64-bit NAME. The rules for creating this NAME,
associating it with an address and the ability or non-ability to change that address are specified in 4.3.
CFs shall successfully claim an address according to the procedures detailed in 4.4 prior to sending any
other messages on the network. Multiple CFs can work together to perform a function, provided each
CF claims its own address following the rules in 4.4.2.3.
If a CF cannot successfully claim an address, it shall report this to the network as described in 4.4.2.4.
Network initialization sequences associated with the address claiming process are described in 4.5.
This document no longer contains physical requirements. These requirements are included in
ISO 11783-2:2019.
4.2 Address configuration capabilities
4.2.1 General
Address configuration is the method by which a particular CF determines the SA, which it shall use for an
address claim. For the purposes of the address claim process, there are two basic address configuration
capabilities: non-configurable address and self-configurable address. These are distinguished by the
value in the "self-configurable address" field in the most significant bit position in the CF’s NAME.
CFs conforming to ISO 11783 shall be self-configurable address capable. Non-configurable address
capable CFs shall be tolerated on the network to allow compatibility with CFs conforming to the first
edition of this document (ISO 11783-5:2001) and CFs conforming to SAE J1939.
There are also two extended address configuration capabilities: command-configurable address and
service-configurable address. A CF may implement one or more of the extended address configuration
capabilities.
4.2.2 Non-configurable address
A non-configurable address CF cannot change its initial address during the address claim process. If
multiple non-configurable address CFs are claiming the same address then only the CF with the highest
priority NAME can obtain the address, the others shall announce their inability to claim an address.
The "self-configurable address" field is the most significant bit in the CF’s NAME and therefore a non-
configurable address CF always has higher priority than a self-configurable address CF. This implies
that a non-configurable address CF forces a self-configurable address CF to claim another address.
2 © ISO 2019 – All rights reserved

4.2.3 Self-configurable address
A self-configurable address CF is one that can select its initial address based on proprietary algorithms,
and then claim that address. This CF, in cases of address conflict, is also able to re-calculate its address
and re-claim (unless all 120 of the addresses between 128 and 247 are used). The value in the "self-
configurable address" field in the NAME (see 4.3.2) indicates whether or not a CF has this capability.
The CF shall only change its initial address when it loses address arbitration, and it shall only use
addresses in the range 128 to 247 inclusive. But if the CFs function is one that has an assigned preferred
address, then it may also use the preferred address.
4.2.4 Service-configurable address
A service-configurable address CF is one whose source address can be changed in the field by a service
technician. The address can be altered by any one of a number of proprietary techniques or by using the
commanded-address message, while in a “service” mode of operation. A service tool may be used for
this operation.
4.2.5 Command-configurable address
A command-configurable address CF is one whose source address can be altered using the commanded-
address message. The change can take place at any time, without the intervention of a service tool or
the requirement of a special service mode of operation. It does require the presence on the network of a
CF that can send the appropriate command to cause the address change.
4.3 NAME and address requirements
4.3.1 General
A NAME is a 64-bit entity composed of fields defined in Table 1. Every CF transmitting messages on an
ISO 11783 network shall have a unique NAME. A CF’s NAME describes the function that a CF performs
and its numerical value is used in the arbitration for address (see Annex A for examples of NAMEs).
NAMEs are normally established during initial network configuration on a machine, or when a CF in an
ECU is added to an existing network.
An address is used on an ISO 11783 network to provide a unique message identifier and to determine a
message source which is known as a source address (SA). The procedures for address management in
the ISO 11783-5 protocol enable individual SAs to be associated with particular CFs (see 4.4.2). In the
case of an ECU that implements several CFs, a different address-configuration capability may exist for
each of the CFs and each CF shall claim a unique SA.
An address-claim message containing both a NAME and an SA is used to associate the two on
the network. The association of a unique NAME and address also associates the address with the
corresponding function. However, regardless of the SA with which it is associated, a NAME retains a
consistent definition.
4.3.2 NAME
Network integrators and ECU manufacturers shall ensure that each CF on a particular network has a
unique NAME not possessed by another CF on that network.
The relationship between the 64-bit value used for arbitration priority (see 4.5.3), the data bytes in the
address-claimed-message (see 4.4.2.3) and the NAME fields (Table 1) is shown in Figure 1.
Figure 1 — Structure of the 64-bit NAME
Table 1 — NAME fields
No.
Byte
a
Field SPN Definition of Byte ordering
no.
bits
Indicates whether a CF is self-configurable
Self-configur- Bit 8: Self-configurable
2844 (1) or not (0); shall always be known and 1
able address address
set to the appropriate value
Defined and assigned by ISO, identifies Bit 7 to bit 5: Industry
d
Industry group 2846 NAMEs associated with industries (such as 3 group (most significant
agricultural equipment) at bit 7)
Indicates occurrence of a particular device
Bit 4 to bit 1: Device class
Device class class in a connected network; definition
2843 4 instance (most signifi-
instance depends on industry group field contents
b
cant at bit 4)
(see Figure 1)
Defined and assigned by ISO, provides a
common NAME for a group of functions
within a connected network; when com- Bit 8 to bit 2: Device class
d
Device class 2842 7
bined with an industry group can be corre- (most significant at bit 8)
lated to a common NAME, such as “planter”
with “agricultural equipment”
Reserved Reserved for future definition by ISO 1 Bit 1: Reserved
Defined and assigned by ISO: when value
between 0 and 127, independent of any
other field for definition; when >127 and
<254, definition depends on device class; Bit 8 to bit 1: Function
d
Function 2841 8 6
when combined with industry group and (most significant at bit 8)
device class, can be correlated to a common
NAME for specific CF, though not implying
any specific capabilities
Bit 8 to bit 4: Function in-
Function in- Indicates specific occurrence of a function
2839 5 stance (most significant
stance on a particular device system of a network
at bit 8)
Indicates which of a group of ECUs associ- Bit 3 to bit 1: ECU (most
ECU instance 2840 3
ated with a given function is referenced significant at bit 3)
a
The byte ordering of the NAME fields is arranged so that the NAME can be treated as a number, consistent with
ISO 11783-7.
b
Bit 1 is the last of the data bits sent and closest to the cyclic redundancy code (CRC) in the message.
c
Bit 8 is the bit closest to the data length code (DLC) in the message.
d
See ISO 11783-1 for numerical values of industry groups, device classes, functions and manufacturer codes.
4 © ISO 2019 – All rights reserved

Table 1 (continued)
No.
Byte
a
Field SPN Definition of Byte ordering
no.
bits
Bit 8 to bit 1: Most
significant 8 bits of
manufacturer code (most
Assigned by committee (see ISO 11783-1),
significant at bit 8)
Manufacturer indicates manufacturer of ECU for which
2838 11
d
code the NAME is being referenced; independent
Bit 8 to bit 6: Least
of any other NAME field
significant 3 bits of
manufacturer code (most
significant at bit 8)
Bit 5 to bit 1: Most sig-
nificant 5 bits of identity
number (most significant
at bit 5)
Bit 8 to bit 1: Second byte
Identity number 2837 Assigned by the ECU manufacturer. 21 2 of identity number code
(most significant at bit 8)
Bit 8 to bit 1: Least sig-
nificant byte of identity
number (most significant
c
at bit 8)
a
The byte ordering of the NAME fields is arranged so that the NAME can be treated as a number, consistent with
ISO 11783-7.
b
Bit 1 is the last of the data bits sent and closest to the cyclic redundancy code (CRC) in the message.
c
Bit 8 is the bit closest to the data length code (DLC) in the message.
d
See ISO 11783-1 for numerical values of industry groups, device classes, functions and manufacturer codes.
Table 1 specifies the fields that comprise a NAME, listing them in order of priority, from the self-
configurable-address bit to the identity number’s least significant byte.
The reserved bit shall be set to zero.
Any instance field in the NAME can be changed and reconfigured when an ECU is installed, or where
there are multiple instances, on the network by the NAME management message (see 4.5.3).
An agreement can be reached, where appropriate, between the manufacturer and the system integrator
on the interpretation and use of function instances. For example, a manufacturer or other parts of
ISO 11873 may use the function instance to indicate position or special functionality of a CF.
EXAMPLE In the case of two engines and transmissions, agreement is reached that engine instance 0 be
physically connected to transmission instance 0, and engine instance 1 to transmission instance 1.
Where a function is managed by two separate ECUs, each attached to the same ISO 11783 network, the
ECU instance field should be set to 0 for the first ECU and to 1 for the second. The ECU manufacturer
shall ensure that the NAME is unique and non-varying when power is removed. Where all other fields
can be identical to the NAME of another CF, the NAME shall be made unique by setting the identity
number (such as a serial number or a data/time code on the product).
Figure 2 shows the relationships between the fields, as well as the dependence of the upper 128 functions
on device class and industry group, the dependence of identity number on manufacturer code, and the
independence of function 0 to function 127 from either industry group or device class. The number of
bits that each field comprises is noted above each field.
Figure 2 — NAME-field relationships and dependencies
4.3.3 Address
4.3.3.1 General
An address is a one-byte value identifying a particular CF on a network. The address of a CF is
incorporated into the CAN identifier of every message sent by that CF and is used to provide uniqueness
to messages that are sent by the CF. After initial power-up and when the network is operating, each CF
shall have a unique SA. An SA can be associated with a different CF after each power up of the network
and can also vary from one network connection to another network connection. The NAME, which is
associated with a source address, includes the identification of the function the CF performs and retains
this consistent definition regardless of the source address that the CF uses.
4.3.3.2 Preferred address
CFs can operate on an ISO 11783 network using an assigned preferred address. If the preferred address
has already been claimed, the CF shall either attempt to claim another SA, or send a cannot-claim-
source-address address message depending on the CF’s addressing capability and the availability of
an unused address. When the CF claims another address, this new address shall be stored as the initial
address to be used at all subsequent power-ups.
See ISO 11783-1 for a list of assigned preferred addresses.
A CF claiming a preferred address in the range 0 to 127 and 248 to 253 shall perform the function
defined for that preferred address and shall specify that function within its NAME.
The function performed by a CF shall never be deduced from the SA alone; only the CF’s NAME shall be
1)
used to establish the function .
4.3.3.3 Self-configurable address
ISO 11783 CFs that do not have an assigned preferred address or cannot claim their preferred address
shall claim an address in the range of 128 to 247. Since multiple CFs can be claiming addresses in this
1) The first edition of this document (ISO 11783-5:2001) did not enforce the address-to-function relation.
6 © ISO 2019 – All rights reserved

range, this type of CF shall be self-configurable address capable. This permits the address claim process
to provide unique addresses for each CF on the network.
Some addresses in the upper end of the self-configurable address range of 128 to 247, are defined as
preferred addresses for Industry Group 2 functions (see ISO 11783-1). These addresses are not locked
to the function, and they may be used by any self-configurable address capable CF. It is recommended
that CFs, which are forced to claim a new address, attempt to claim addresses in the lower region of
the self-configurable address range, and only if all addresses in the lower region are already claimed,
should the CF claim addresses in the preferred address region.
4.3.3.4 Initial address
At the time of production, the initial address (the address which the CF attempts to claim on power-up)
shall be set to the preferred address. The initial address for a CF may be reprogrammed in order to
permit configuration of the system.
Every time a CF with service-configurable, command-configurable or self-configurable address
capabilities is required to claim a new address, this new address shall be stored as the initial address to
be used at all subsequent power-ups. This also applies for CFs with assigned preferred addresses.
4.3.3.5 NULL address
The NULL address (254) shall only be used as source address, and is intended for use only within
network management communications, as specified in this document.
4.3.3.6 Global address
The Global address (255) shall only be used as destination address.
4.4 Network-management procedures
4.4.1 General
Network management procedures include the messages exchanged and actions taken by CFs to
collectively manage the network. Address and network-error management (see 4.4.2 and 4.4.4,
respectively) are the network-management protocol’s primary roles. With the exception of a limitation
on use of the NULL address, network-management messages have the same characteristics, and are
subject to the same requirements, as other ISO 11783 messages (for example, the request-for-address-
claimed message is the request PGN message specified in ISO 11783-3).
The NULL address (254) is only acceptable in a network management message’s SA field, and only if the
message is a request-for-address-claimed or a cannot-claim-source-address message.
4.4.2 Address-management messages and procedures
4.4.2.1 Address-management-message functions
The set of address-management messages as specified in Table 2 is used by CFs to:
— request a NAME and address used by another CF on the network (request-for-address-claimed
message);
— claim an address (address-claimed message);
— respond with the inability to claim an address (cannot-claim-source-address message);
— command another CF to assume a new address (commanded-address message).
Table 2 — Address-management messages
Data
Message PGN PF PS SA Data
length
Request-for-address-claimed (request
a b
59 904 234 DA SA 3 PGN 60928
PG)
Address-claimed 60 928 238 255 SA 8 NAME
Cannot-claim-source-address 60 928 238 255 254 8 NAME
c
Commanded-address 65 240 254 216 SA 9 NAME, new SA
a
See ISO 11783-3.
b
The SA is set to 254 if an address has not yet been claimed.
c
The commanded-address message is sent using the broadcast announce message (BAM) transport protocol.
4.4.2.2 Request-for-address-claimed message
The request-for-address-claimed message may be transmitted by any CF to request the NAME and
address of any other CF operating on the network. Upon its receipt, the receiving CF shall respond with
an address-claimed message containing its address and its NAME, while the CF that is not able to claim
an address shall respond with a cannot-claim-source-address message (see 4.4.2.3 for the procedure in
both cases). The exception to this requirement is the CF that has not yet attempted to claim an address,
which shall not send a cannot-claim-source-address message, nor, in fact, participate in any network
communications (except request-for-address-claimed), before attempting to claim an address.
The SA for a request-for-address-claimed message shall be the NULL address if the message is sent from
a CF that has not yet claimed an address.
A CF can transmit a request-for-address-claimed message either to the global destination address (255),
or to a particular address. In the first case, the CF can then determine the existence on the network of
another CF with a particular NAME by examining the responses to its message to the global destination
address, while in the second case, the initiating CF can interrogate the other to determine if the address
has already been claimed. The CF shall respond to its own request-for-address-claimed message if it is
sent to the Global address.
4.4.2.3 Address-claimed message
The address-claimed message shall be used by a CF to respond to a request-for-address-claimed
message and to claim an address on the network. If a CF receives an address-claimed message claiming
its own source address, it shall compare its own NAME with the one received and determine which
NAME has the higher priority, i.e. the lower numeric value. If it determines it has the higher priority, the
CF shall transmit an address-claimed message containing its NAME and address. If, however, it has the
lower priority, it shall either claim a new address or transmit a cannot-claim-source-address message
(see 4.4.2.4). A single parameter group number (PGN) is used for both the address-claimed and cannot-
claim-source-address messages.
Transmission repetition rate: As required
Data length: 8 bytes
Data page field: 0
PDU format field: 238
PDU specific field: 255 (Global address)
Default priority: 6
8 © ISO 2019 – All rights reserved

Parameter group number: 60928 (00EE00 )
Source address 0 to 253
Bytes 1 to 8 NAME
In order to successfully claim an address, the CF sending an address-claimed message shall not receive
a contending claim from another CF for at least 250 ms. A network interconnection unit shall not use
its own address in communications on the network until it has already successfully claimed an address
(forwarding messages between other ECUs is a special task of the network interconnection unit). (See
ISO 11783-4.) However, a network interconnection unit may forward messages before claiming its’ own
address.
4.4.2.4 Cannot-claim-source-address message
A cannot-claim-source-address message is transmitted (in response to a request-for-address-claimed
or address-claimed message) by any CF that cannot claim its initial address and does not have the self-
configurable address capability, or that has the self-configurable address capability but cannot claim an
address because none is available for use. Although the cannot-claim-source-address message has the
same PGN as the address-claimed message, its SA shall be the NULL address (254).
Transmission repetition rate: As response only
Data length: 8 bytes
Data page field: 0
PDU format field: 238
PDU specific field: 255 (Global address)
Default priority: 6
Parameter group number: 60928 (00EE00 )
Source address 254 (NULL address)
Bytes 1 to 8 NAME
A random transmit delay (RTxD) shall be inserted between the reception of a message triggering
the cannot-claim-source-address response and the sending of the response in order to minimize the
possibility of two such responses causing bus errors.
A CF that cannot claim an address shall send no message other than a cannot-claim-source-address or
request-for-address-claimed message.
A CF that cannot claim an address may continue to receive and process global messages (such as the
commanded-address message).
4.4.2.5 Commanded–address message
Support of the commanded-address message is optional. If the CF does not support the commanded-
address message the remainder of clause 4.4.2.5 shall be ignored.
This message can be used by one CF (for example, a network interconnection unit such as a bridge or a
service tool) to command another CF (thereafter known as the commanded CF) to use a particular SA.
If a CF receives a commanded-address message but is unable to change to the commanded SA, the CF
shall respond with an address claim claiming the CFs current SA. An operator or technician could then
modify the commanded CF’s SA by other means. The ECU manufacturer could prevent its product from
accepting commanded-address messages from any CF other than for example a bridge or service tool,
or demand a security-verification for its CF to accept such a message.
Transmission repetition rate: As required
Data length: 9 bytes
Data page field: 0
PDU format field: 254
PDU specific field: 216
Default priority: 6
Parameter group number: 65240 (00FED8 )
Bytes 1 to 8 NAME
Byte 9 Address assignment field (new SA)
When it accepts a commanded-address message, the commanded CF shall issue an address-
claimed message using the address specified in the commanded-address message as its new SA, the
requirements of 4.5.2 applies.
The commanded-address message shall contain 9 bytes of data and shall be sent to the Global address
(255) using the broadcast announce message (BAM) of the transport protocol (see ISO 11783-3).
Therefore, CFs designed to support the commanded-address message shall also support BAM.
4.4.3 NAME management message and procedures
4.4.3.1 General
A message to change fields of the NAME of a CF can be used when configuring a network containing CFs
with multiple instances of functions, ECUs or device classes. Changing the function of a generic ECU is
another possible use of this message. It can also be used when other methods of uniquely identifying
CFs are not available. This message can be used in conjunction with manual setup steps and/or with the
commanded-address method to accomplish the configuration of the network.
One CF (commanding CF) can command another CF (target CF) to use a given NAME by using the NAME
management message. This message can be used to instruct a target CF with a specific source address
to replace some fields of its NAME with newly specified values.
The primary use of this message is to set the instance fields in the NAME, but all of the NAME fields can
be modified by using this message except for the Identity Number field which is to remain unchanged
after initial manufacture.
It is optional for a CF to support the NAME management message. If the message is supported, the ECU
manufacturer may limit the use of the message by not accepting it from CFs other than e.g. service tools
or network interconnect units. ECU manufacturers may also require additional proprietary security
verification processes before accepting a NAME Management message. The ECU manufacturer may
further limit the use of the message by only accepting changes to a subset of the fields of the NAME,
such as the instance fields.
The CF commanding the changes to NAME fields shall correctly identify the source addresses of CFs
being changed prior to using this command. Commands are directed to source addresses.
10 © ISO 2019 – All rights reserved

4.4.3.2 NAME management (NM) message
The NM message is used to manage the assignment of fields of the NAME of a CF during a configuration
of the network. The NM message contains 8 bytes of data and is sent as a PDU1 message. Depending
on the NM control mode, the message is either sent to the Global address or destination specific to the
source address of the CF to be modified.
As specified below there are two main users and several uses of the message.
1) A commanding CF can
a) command a target CF to set a new pending NAME;
b) request pending or current NAME from a target CF;
c) announce to one or more target CFs that they shall adopt their pending NAME;
d) request that a CF with a specified NAME transmit the address-claimed message with its
current NAME.
2) A target CF shall
a) respond to requests for pending or current NAME;
b) acknowledge (ACK) or negatively acknowledge (NACK) a command to change pending NAME;
c) adopt its pending NAME as the current NAME and claim its current NAME on the network;
d) send an address-claimed message in response to a request for a matching NAME.
The NM control mode Indicator is always sent in the least significant four bits of Byte 3 and indicates
how the NM message is being used. The other parameter fields are used for some modes but not all.
When not used for a specific mode, the unused fields should be set to all 1's. Fields used for each mode
are specified in Table 3 and in 4.4.3.3.
Transmission repetition rate: As required
Data length: 8 bytes
Data page field: 0
PDU format field: 147
PDU specific field: Depending on NM Control Mode:
— Mode 0: SA of the target CF
— Mode 1.4 ; SA of commanding CF
— Mode 5.7: SA of target CF, or the Global address (FF )
— Mode 8: The Global address (FF )
Default priority: 6
Parameter group number: 37632 (009300 )
Bytes 1 to 8 See Table 3 and Figure 3
Reserved and unused bit fields shall be set to all ‘1’s

Figure 3 — NAME management message data bytes
Table 3 — NAME management message parameters
No.
Parameter used Byte
Parameter SPN of Byte ordering
in modes no.
bits
a
Commanded self-configurable address 5674 1 Bit 8
a,b
Commanded industry group 5673 3 8 Bit 7 to bit 5
0, 1, 2, 3, 8
a
Commanded device class instance 5672 4 Bit 4 to bit 1
a,b
Commanded device class 5671 7 Bit 8 to bit 2
Reserved 1 Bit 1
a,b
Commanded function 5670 8 6 Bit 8 to bit 1
a
Commanded function instance 5669 5 Bit 8 to bit 4
a
Commanded ECU instance 5668 3 Bit 3 to bit 1
0, 1, 2, 3, 8
Bit 8 to bit 1
Most significant 8 bit
a,b
Commanded manufacturer code 5667 11
Bit 8 to bit 6
Least significant 3 bit
Reserved 1 Bit 5
NM Control Mode Indicator 5666 All modes 4 Bit 4 to bit 1
Self-configurable address capable qualifier flag 5665 1 Bit 8
Industry group qualifier flag 5664 1 Bit 7
Device class instance qualifier flag 5663 1 Bit 6
Device class qualifier flag 5662 1 Bit 5
0, 4, 8 2
Function qualifier flag 5661 1 Bit 4
Function instance qualifier flag 5660 1 Bit 3
ECU Instance qualifier flag 5659 1 Bit 2
Manufacturer code qualifier flag 5658 1 Bit 1
NAME checksum/Error code 5657 0, 4 8 1 Bit 8 to bit 1
a
These fields are populated if their corresponding qualifier flag is set to 0. If their qualifier flag is set to 1, the field is set
to all 1’s.
b
See ISO 11783-1 for numerical values of industry groups, device classes, functions and manufacturer codes.
12 © ISO 2019 – All rights reserved

4.4.3.3 NAME management (NM) message parameters
4.4.3.3.1 NAME checksum/Error code
When the NM Control Mode Indicator is set to Mode 0 “set pending NAME”. NAME checksum is used as
a check to ensure the NM message has been sent to the correct CF. It is a guard against the possibility
that the SA of the target CF having been claimed by another CF through the address arbitration process
since the commanding CF started the NAME change process. The NAME checksum byte shall contain
the arithmetic sum of the 8 bytes of the target CFs original NAME truncated to 8 least significant bits.
Data length: 8 bits
Resolution: N/A
Data range: 0 to 255
Type: Command
Suspect parameter number: 5657
When the NM Control Mode Indicator is set to Mode 4 NAME NACK, it represents an error code sent by
the target CF. Code values are as follows:
— 0 – Security not satisfied. Different SA for adopt pending than set pending.
— 1 – Item(s) not allowed to change. Set qualifier flag to 1 for disallowed items.
— 2 – Item conflict. Cannot perform function assigned, cannot perform as self-configurable-address-
capable, etc. Set qualifier flag to 1 for disallowed items.
— 3 – Checksum does not match.
— 4 – Pending NAME not set.
— 5 – Other.
— 6 – 254 – Reserved.
— 255 – Not available.
4.4.3.3.2 Qualifier flags
If the NM Control Mode Indicator is set to Mode 0 (set pending NAME), the qualifier flags are used to
indicate whether the corresponding fields in the pending NAME of the target CF shall be changed. If a
qualifier flag is set to “0”, the corresponding field in the pending NAME shall be set to the value in the
corresponding Commanded parameter in the NAME management message. If a qualifier flag is set to 1,
the corresponding field shall not be changed.
If the NM Control Mode Indicator is set to Mode 4 (NAME NACK), and the Error code is 1 or 2, then the
qualifier flags are used to indicate disallowed items. The target CF shall set the qualifier flag to 1 if the
corresponding parameter caused the error, and to 0 if it did not cause the error. For error codes other
than 1 and 2 this qualifier flag shall be set to 1.
If the NM Control Mode Indicator is set to Mode 8 (request NAME address claim), the qualifier flags are
used to indicate whether the corresponding commanded parameter shall be used by the target CF to
match the current NAME. If a flag is set to 0, the corresponding commanded parameter shall be used in
the NAME match. If a qualifier flag is set to “1”, the corresponding commanded parameter shall not be
used in the NAME match.
For all other NM Control Modes the qualifier flags are not applicable and shall all be set to 1.
Data length: 1 bit
Resolution: N/A
Data range: 0 to 1
Type: Command
Suspect parameter number: See Table 3
4.4.3.3.3 NM Control Mode Indicator
4.4.3.3.3.1 General
This four-bit parameter is used to define the purpose of the NM message as described in 4.4.3.3.3.2 to
4.4.3.3.3.11.
Data length: 4 bits
Resolution: N/A
Data range: 0 to 15
Type: Command
Suspect parameter number: 5666
4.4.3.3.3.2 Mode 0 — Set Pending NAME
This form of the message is the command to the target CF at the destination address in the CAN Identifier
to c
...

NORME ISO
INTERNATIONALE 11783-5
Troisième édition
2019-06
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
Tractors and machinery for agriculture and forestry — Serial control
and communications data network —
Part 5: Network management
Numéro de référence
©
ISO 2019
DOCUMENT PROTÉGÉ PAR COPYRIGHT
© ISO 2019
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 2019 – Tous droits réservés

Sommaire Page
Avant-propos .iv
Introduction .v
1 Domaine d'application . 1
2 Références normatives . 1
3 Termes et définitions . 1
4 Exigences techniques . 2
4.1 Généralités . 2
4.2 Capacités de configuration d'adresse . 2
4.2.1 Généralités . 2
4.2.2 Adresse non configurable . 3
4.2.3 Adresse auto-configurable . 3
4.2.4 Adresse configurable par maintenance . 3
4.2.5 Adresse configurable sur ordre . 3
4.3 Exigences concernant le NOM et l'adresse . 3
4.3.1 Généralités . 3
4.3.2 NOM . 4
4.3.3 Adresse . 6
4.4 Procédures de gestion de réseau . 7
4.4.1 Généralités . 7
4.4.2 Messages et procédures de gestion d'adresse . 8
4.4.3 Message et procédures de gestion de NOM .11
4.4.4 Gestion d'erreurs de réseau .20
4.5 Initialisation du réseau .21
4.5.1 Acquisition d'une adresse univoque .21
4.5.2 Exigences de la revendication d'adresse .22
4.5.3 Autres exigences de base concernant l'initialisation .22
4.5.4 Séquences de messages .23
4.5.5 Incapacité d'une FC à obtenir une adresse .28
Annexe A (informative) Exemples de construction de NOM .29
Bibliographie .31
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 le lien suivant: www .iso .org/iso/fr/avant -propos .html.
Le présent document a été élaboré par le comité technique [ou comité de projet] ISO/TC 23, Tracteurs et
matériels agricoles et forestiers, sous-comité SC 19, Électronique en agriculture.
Cette troisième édition annule et remplace la deuxième édition (ISO 11783-5:2011), qui a fait l’objet
d’une révision technique.
Les principales modifications par rapport à l’édition précédente sont les suivantes:
— les exigences relative à la couche physique sont déplacées dans l’ISO 11783-2.
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.
iv © ISO 2019 – Tous droits réservés

Introduction
Les ISO 11783-1 à ISO 11783-14 spécifient un système de communication destiné aux matériels
agricoles, fondé sur le protocole de l'ISO 11898.[4][5] Les documents SAE J 1939, sur lesquels certaines
parties de l’ISO 11783 se basent, 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, sur 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 minimales. Le présent document est harmonisé avec le document
SAE J 1939/81.[6] Des informations générales sur l’ISO 11783 peuvent se trouver 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é.
NORME INTERNATIONALE ISO 11783-5:2019(F)
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
1 Domaine d'application
Le présent document décrit la gestion des adresses sources (AS) pour les fonctions de commande (FC)
des unités de commande électroniques (UCE), l'association des adresses à l'identification fonctionnelle
d'un dispositif, et à la détection et la signalisation des erreurs liées au réseau. Elle spécifie également
les processus d'initialisation et de réaction aux pannes d'électricité de courte durée, et les exigences
minimales relatives aux UCE connectées au réseau.
2 Références normatives
Les documents suivants sont cités dans le texte de sorte qu'ils 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-2, Tracteurs et matériels agricoles et forestiers — Réseaux de commande et de communication
de données en série — Partie 2: Couche physique
ISO 11783-3, 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
3 Termes et définitions
Pour les besoins du présent document, les termes et définitions donnés dans l’ISO 11783-1 ainsi que les
suivants 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/
3.1
NOM courant
NOM de FC transmis dans son message de revendication d'adresse
3.2
gestion de NOM
GN
méthode pour changer le NOM d'une FC en cours d'exécution
3.3
NOM en attente
NOM mémorisé provisoirement par une FC particulière résultant de messages de gestion de NOM (3.2)
reçus d'une source qualifiée
3.4
retard de transmission aléatoire
RTxD
retard calculé en multipliant un nombre aléatoire compris entre 0 et 255 par 0,6 ms
Note 1 à l'article: La base du générateur de nombres aléatoires peut utiliser le numéro d'identité du NOM ou
d'autres données propres dans la FC.
4 Exigences techniques
4.1 Généralités
La gestion d'un réseau spécifié dans le présent document fournit les définitions et les modes opératoires
nécessaires pour identifier les FC du réseau de manière univoque, gérer l'affectation des adresses et
traiter les erreurs du réseau.
L'aptitude d'une FC à sélectionner une adresse dépend de ses possibilités de configuration d'adresse,
comme décrit en 4.2.
Chaque FC doit être capable de fournir son propre NOM sur 64 bits. Les règles de création de ce NOM, son
association avec une adresse et l'aptitude ou l'inaptitude à modifier cette adresse sont spécifiées en 4.3.
Avant d'envoyer tout autre message sur le réseau, les FC doivent parvenir à revendiquer une adresse
conformément aux procédures détaillées en 4.4. Plusieurs FC peuvent agir en même temps pour
exécuter une fonction, à condition que chaque FC revendique sa propre adresse en suivant les règles en
4.4.2.3.
L'Si une FC ne peut réussir à revendiquer une adresse, elle doit le rapporter au réseau comme décrit en
4.4.2.4.
Les séquences d'initialisation du réseau associées au processus de revendication d'adresse sont
décrites en 4.5.
Le présent document ne contient plus l'ensemble d'exigences physiques. Ces exigences ont été intégrées
dans l’ISO 11783-2:2019.
4.2 Capacités de configuration d'adresse
4.2.1 Généralités
La configuration d'adresse est la méthode au moyen de laquelle une FC particulière détermine l'adresse
source (AS) qu'elle doit utiliser pour la revendication d'adresse. Pour les besoins du processus de
revendication d'adresse, il existe deux capacités de configuration d'adresse de base: adresse non
configurable et adresse auto-configurable. Elles se distinguent par la valeur du champ «Adresse auto-
configurable» dans la position du bit le plus significatif du NOM de la FC.
Les FC conformes à l'ISO 11783 doivent avoir la capacité d'adresse auto-configurable. Les FC ayant la
capacité d'adresse non configurable doivent être tolérées sur le réseau afin d'assurer la compatibilité
avec les FC conformes la première édition du présent document (ISO 11783-5:2001) et les FC conformes
à SAE J1939.
Il existe également deux capacités de configuration d'adresse étendue: adresse configurable sur ordre
et adresse configurable par maintenance. Une FC peut mettre en œuvre une ou plusieurs des capacités
de configuration d'adresse étendue.
2 © ISO 2019 – Tous droits réservés

4.2.2 Adresse non configurable
Une FC à adresse non configurable ne peut pas modifier son adresse initiale durant le processus de
revendication d'adresse. Si plusieurs FC à adresse non configurable revendiquent la même adresse,
seule la FC ayant le NOM de plus haute priorité peut alors obtenir l'adresse; les autres doivent déclarer
leur inaptitude à revendiquer une adresse.
Le champ «Adresse auto-configurable» est le bit le plus significatif du NOM de la FC et une FC à adresse
non configurable a donc toujours une priorité supérieure à celle d'une FC à adresse auto-configurable.
Cela a pour conséquence qu'une FC à adresse non configurable oblige une FC à adresse auto-configurable
à revendiquer une autre adresse.
4.2.3 Adresse auto-configurable
Une FC à adresse auto-configurable est une FC qui peut choisir son adresse initiale en se basant sur des
algorithmes propriétaires et qui peut ensuite revendiquer cette adresse. En cas de conflit d'adresse,
cette FC est également capable de recalculer son adresse et de la revendiquer à nouveau (sauf si
l'ensemble des 120 adresses comprises entre 128 et 247 sont utilisées). La valeur située dans le champ
«Adresse auto-configurable» du NOM (voir 4.3.2) indique si une FC possède ou non cette capacité.
La FC ne doit changer son adresse initiale que lorsqu'elle a perdu l'arbitrage d'adresse et elle ne doit
utiliser que les adresses comprises entre 128 et 247, ces valeurs incluses. Cependant, si la fonction de FC
est une fonction ayant une adresse préférentielle affectée, elle peut alors utiliser l'adresse préférentielle.
4.2.4 Adresse configurable par maintenance
Une FC à adresse configurable par maintenance est une FC dont l'adresse source peut être modifiée
sur place par un technicien de maintenance. L'adresse peut être modifiée au moyen d'une technique
quelconque parmi un certain nombre de techniques propriétaires ou en utilisant le Message d'ordre
d'adresse, dans le mode de fonctionnement de «maintenance». Pour effectuer cette opération, on peut
utiliser un outil de maintenance.
4.2.5 Adresse configurable sur ordre
Une FC à adresse configurable sur ordre est une FC dont l'adresse source peut être modifiée en utilisant
le Message d'ordre d'adresse. La modification peut s'effectuer à tout moment, sans intervention d'outil
de maintenance et sans nécessiter un mode spécial de fonctionnement de maintenance. Elle nécessite
la présence sur le réseau d'une FC qui peut envoyer une commande appropriée pour provoquer le
changement d'adresse.
4.3 Exigences concernant le NOM et l'adresse
4.3.1 Généralités
Un NOM est une entité de 64 bits constituée de champs définis dans le Tableau 1. Chaque FC transmettant
des messages sur un réseau ISO 11783 doit avoir un NOM univoque. Le NOM d'une FC décrit la fonction
exécutée par cette FC et sa valeur numérique est utilisée en cas d'arbitrage d'adresse (voir à l'Annexe A
des exemples de NOMS). Les NOMS sont normalement établis pendant la configuration initiale du réseau
sur une machine, ou quand une FC d'une UCE est ajoutée à un réseau existant.
Une adresse sert, dans un réseau ISO 11783, à fournir un identifiant unique pour chaque message et
à permettre d'identifier l'origine d'un message dont on sait qu'il s'agit d'une adresse source (AS). Les
procédures de gestion des adresses du protocole de l’ISO 11783-5 permettent d'associer des adresses
source individuelles à des FC particulières (4.4.2). Si une UCE met en œuvre plusieurs FC, une capacité
de configuration d'adresse différente peut exister pour chacune des FC et chaque FC doit revendiquer
une AS univoque.
Un message de revendication d'adresse, contenant à la fois un NOM et une AS, est utilisé pour les
associer sur le réseau. L'association d'une adresse et d'un NOM univoque permet en outre d'associer
une adresse à la fonction correspondante. Cependant, quelle que soit l’AS à laquelle il est associé, le NOM
garde la même définition.
4.3.2 NOM
Les constructeurs d'UCE et les intégrateurs de réseau doivent veiller au caractère unique du NOM de
chaque FC sur un réseau donné.
La relation entre la valeur de 64 bits utilisée pour la priorité d'arbitrage (voir 4.5.3), les octets de
données dans le message de revendication d'adresse (voir 4.4.2.3) et les champs NOM (voir Tableau 1)
est indiquée à la Figure 1.
Figure 1 — Champs des bits NOM dans les octets de données d'un message CAN
Tableau 1 — Champs NOM
Nombre
Nombre
a
Champ SPN Définition d'oc- Ordre des octets
de bits
tets
Indique si une FC est auto-configurable (1) ou non
Adresse auto-confi- Bit 8: Adresse auto-configu-
2844 (0); doit nécessairement être connu et posséder la 1
gurable rable
valeur appropriée
Défini sur la base des recommandations de l'ISO,
Bit 7 à bit 5: Groupe sectoriel
d
Groupe sectoriel 2846 indique les NOMS associés à un secteur d'activité 3
8 (le plus significatif au bit 7)
(par exemple «matériel agricole»)
Indique l'occurrence d'une classe de dispositif
Bit 4 à bit 1: Instance de classe
Instance de classe de donnée au sein d'un réseau connecté; la définition
2843 4 de dispositif (le plus significa-
dispositif dépend des contenus du champ du groupe sectoriel
b
tif au bit 4)
(voir Figure 1)
Défini sur la base des recommandations de l'ISO,
fournit un NOM commun à un groupe de fonc-
tions d'un réseau connecté; peut être lié à un NOM Bit 8 à bit 2: Classe de disposi-
d
Classe de dispositif 2842 7
commun en association avec le groupe sectoriel: tif (le plus significatif au bit 8)
par exemple «planteuse» pour le groupe sectoriel
«matériel agricole»
Réservé Réservé pour une définition ultérieure par l'ISO 1 Bit 1: Réservé
Défini sur la base des recommandations de l'ISO: s'il
est compris entre 0 et 127, sa définition ne dépend
pas des autres champs; s'il est > 127 et < 254, sa
Bit 8 à bit 1: Fonction (le plus
d
Fonction 2841 définition dépend du champ classe de dispositif; allié 8 6
significatif au bit 8)
aux champs groupe sectoriel et classe de dispositif,
peut être lié à un NOM commun de FC donnée et ne
suppose aucune capacité particulière
Bit 8 à bit 4: Instance de
Indique l'occurrence particulière d'une fonction au
Instance fonction 2839 5 fonction (le plus significatif
sein d'un même système de dispositifs d'un réseau
au bit 8)
Indique l'UCE, parmi les différentes unités associées Bit 3 à bit 1: UCE (le plus signi-
Instance d’UCE 2840 3
à une fonction donnée, à laquelle il est fait référence ficatif au bit 3)
4 © ISO 2019 – Tous droits réservés

Tableau 1 (suite)
Nombre
Nombre
a
Champ SPN Définition d'oc- Ordre des octets
de bits
tets
Bit 8 à bit 1: 8 bits les plus signi-
4 ficatifs du code constructeur
Affecté par un comité (voir l'ISO 11783-1), indique
(le plus significatif au bit 8)
l'entreprise responsable de la production du module
d
Code constructeur 2838 11
Bit 8 à bit 6: 3 bits les
de commande électronique portant un NOM donné;
moins significatifs du code
ne dépend d'aucun autre champ du NOM
constructeur (le plus signifi-
catif au bit 8)
Bit 5 à bit 1: 5 bits les plus
significatifs du numéro
d'identité (le plus significatif
au bit 5)
Bit 8 à bit 1: Second octet du
Numéro d'identité 2837 Assigné par le fabricant de l'UCE. 21
2 numéro d'identité (le plus
significatif au bit 8)
Bit 8 à bit 1: Octet le moins si-
1 gnificatif du numéro d'identité
c
(le plus significatif au bit 8)
a
L'ordre des octets des champs NOM est conçu pour permettre de traiter le NOM en tant que nombre, conformément à l'ISO 11783-7.
b
Le bit 1 est le dernier bit de données transmis; il s'agit du bit le plus proche du CRC («cyclic redundancy code», code de redondance
cyclique) dans le message.
c
Le bit 8 est le bit le plus proche du DLC («data length code», code de longueur de données) dans le message.
d
Voir l'ISO 11783-1 pour les valeurs numériques des groupes sectoriels, des classes dispositifs, des fonctions et des codes constructeur.
Le Tableau 1 spécifie les champs qui comprennent un NOM; il les énumère par ordre de priorité, à partir
du bit de l'adresse auto-configurable jusqu'à l'octet le moins significatif du numéro d'identité.
Le bit réservé doit être mis à zéro.
Chaque champ instance du NOM peut être modifié et reconfiguré de manière à permettre une
configuration correcte en cas d'installation d'une UCE, ou dans le cas où plusieurs instances sont
susceptibles de coexister sur le réseau et ce, au moyen du message de gestion de NOM (voir 4.5.3).
Un accord sur l'interprétation et l'utilisation des instances de fonction peut, s'il y a lieu, se révéler
nécessaire entre constructeurs et intégrateurs. Par exemple, un fabricant ou d'autres parties de
l'ISO 11783 peuvent utiliser l'instance de fonction pour indiquer la position ou une fonctionnalité
spéciale d'une FC.
EXEMPLE Dans le cas d'un équipement comprenant deux moteurs et deux transmissions, il peut être
nécessaire de relier physiquement l'instance moteur 0 à l'instance transmission 0 et l'instance moteur 1 à
l'instance transmission 1.
Dans le cas d'une fonction gérée par deux UCE distinctes, toutes les deux reliées à un même réseau
ISO 11783, il convient d'affecter la valeur 0 à la première UCE et la valeur 1 à la seconde unité dans
le champ instance UCE. Le constructeur de l'UCE doit s'assurer que le NOM est univoque et qu'il est
préservé en cas d'arrêt du courant. Lorsque tous les autres champs peuvent être identiques au NOM
d'une autre FC, le NOM doit être rendu univoque en fixant le numéro d'identité (par exemple un numéro
de série ou un code d'horodatage sur le produit).
La Figure 2 illustre les dépendances des fonctions égales ou supérieures à 128 vis-à-vis des champs
classe de dispositif et groupe sectoriel, ainsi que les dépendances des numéros d'identité vis-à-vis du
champ code constructeur; les fonctions 0 à 127 sont indépendantes des champs classe de dispositif et
groupe sectoriel. Le nombre de bits de chaque champ est noté au-dessus de chaque champ.
Figure 2 — Dépendances des champs NOM
4.3.3 Adresse
4.3.3.1 Généralités
Une adresse est une valeur d'un octet identifiant une FC particulière sur un réseau. L'adresse d'une FC
est incorporée dans l'identificateur CAN de chaque message envoyé par cette FC et elle sert à assurer
l'unicité des messages qui sont envoyés par la FC. Après mise sous tension initiale et lorsque le réseau
est fonctionnel, chaque FC doit avoir une AS univoque. Une AS peut être associée à une FC différente
après chaque mise sous tension du réseau et elle peut également varier d'une connexion de réseau à une
autre. Le NOM, qui est associé à une adresse source, comporte l'identification de la fonction exécutée
par la FC et conserve cette définition cohérente, quelle que soit l’AS utilisée par la FC.
4.3.3.2 Adresse préférentielle
Les FC peuvent fonctionner sur un réseau ISO 11783 en utilisant une adresse préférentielle affectée.
Si l'adresse préférentielle a déjà été revendiquée, la FC doit essayer de revendiquer une autre AS ou
envoyer un message d'impossibilité de revendiquer une adresse source en fonction de la capacité
d'adressage de la FC et de la disponibilité d'une adresse inutilisée. Lorsque la FC revendique une autre
adresse, cette nouvelle adresse doit être mémorisée comme adresse initiale à utiliser pour toutes les
mises sous tension ultérieures.
Voir l'ISO 11783-1 pour une liste d'adresses préférentielles affectées.
Une FC revendiquant une adresse préférentielle comprise entre 0 et 127 et entre 248 et 253 doit
exécuter la fonction définie pour cette adresse préférentielle et elle doit spécifier cette fonction dans
son NOM.
La fonction exercée par une FC ne doit jamais être déduite de la seule AS; seul le NOM de la FC doit être
1)
utilisé pour établir la fonction .
1) La première édition du présent document (ISO 11783-5:2001) ne réglementait pas la relation adresse/fonction.
6 © ISO 2019 – Tous droits réservés

4.3.3.3 Adresse auto-configurable
Les FC de l'ISO 11783 n'ayant pas une adresse préférentielle affectée ou ne pouvant pas revendiquer leur
adresse préférentielle doivent revendiquer une adresse comprise entre 128 et 247. Puisque plusieurs FC
peuvent revendiquer des adresses dans cette plage, ce type de FC doit avoir la capacité d'adresse auto-
configurable. Cela permet au processus de revendication d'adresse de fournir une adresse univoque à
chaque FC du réseau.
Certaines adresses dans la plage supérieure d'adresses auto-configurables comprise entre 128 et
247, sont définies comme adresses préférentielles pour les fonctions du groupe sectoriel 2 (voir
l’ISO 11783-1). Ces adresses ne sont pas verrouillées à la fonction, et elles peuvent être utilisées par
n'importe quelle FC ayant la capacité d'avoir une adresse auto-configurable. Il est recommandé que les
FC, qui sont forcées de revendiquer une nouvelle adresse, tentent de revendiquer des adresses dans la
région inférieure de la plage d'adresses auto-configurables, et seulement si toutes les adresses dans
la région inférieure sont déjà revendiquées, les FC doivent revendiquer des adresses dans la région
d'adresses préférentielle.
4.3.3.4 Adresse initiale
Au moment de la fabrication, l'adresse initiale (adresse que tente d'obtenir la FC à la mise sous tension)
doit être fixée à l'adresse préférentielle. L'adresse initiale d'une FC peut être reprogrammée pour
pouvoir configurer le système.
À chaque fois qu'une FC ayant les capacités d'adresse configurable par maintenance, d'adresse
configurable sur ordre ou d'adresse auto-configurable doit revendiquer une nouvelle adresse, cette
nouvelle adresse doit être mémorisée comme adresse initiale. Celle-ci doit être utilisée pour toutes
les mises sous tension ultérieures. Cela s'applique également aux FC avec des adresses préférentielles
affectées.
4.3.3.5 Adresse NULLE
L'adresse NULLE (254) ne doit être utilisée comme adresse source et elle est destinée à être utilisée
uniquement au sein des communications de gestion du réseau, comme spécifié dans le présent
document.
4.3.3.6 Adresse globale
L'adresse globale (255) ne doit être utilisée que dans l'adresse de destination.
4.4 Procédures de gestion de réseau
4.4.1 Généralités
Les procédures de gestion de réseau comprennent les messages échangés et les actions entreprises
individuellement par les FC en vue de gérer collectivement le réseau. La gestion des adresses et celle
des erreurs de réseau (voir 4.4.2 et 4.4.4, respectivement) sont les principales fonctions du protocole
de gestion de réseau. À l'exception de la limitation d'utilisation de l'adresse NULLE, les messages de
gestion de réseau possèdent les mêmes caractéristiques et sont soumis aux mêmes exigences que les
autres messages ISO 11783 [par exemple le message de demande de revendication d'adresse est un
message de demande de PGN, spécifié dans l'ISO 11783-3].
L'adresse NULLE (254) ne peut être acceptée que dans le champ AS d'un message de gestion de réseau
et seulement si le message est un message de demande de revendication d'adresse ou un message
d'impossibilité de revendiquer une adresse source.
4.4.2 Messages et procédures de gestion d'adresse
4.4.2.1 Fonctions de messages de gestion d'adresse
Le jeu de messages de gestion d'adresse spécifié dans le Tableau 2 est utilisé par les FC pour:
— demander une adresse et un NOM utilisé par une autre FC du réseau (message de demande de
revendication d'adresse);
— revendiquer une adresse (message de revendication d'adresse);
— annoncer l'incapacité à revendiquer une adresse (message d'impossibilité de revendiquer une
adresse source);
— ordonner à une autre FC de changer d'adresse (message d'ordre d'adresse).
Tableau 2 — Messages de gestion d'adresse
Lon-
gueur
Message PGN PF PS AS des Données
don-
nées
Demande de revendication d'adresse
a b
59 904 234 AD AS 3 PGN 60928
(demande PN)
Revendication d'adresse 60 928 238 255 AS 8 NOM
Impossibilité de revendiquer une
60 928 238 255 254 8 NOM
adresse
c
Ordre d'adresse 65 240 254 216 AS 9 NOM, nouvelle AS
a
Voir l’ISO 11783-3.
b
La AS est fixée à 254 si aucune adresse n'a encore été revendiquée.
c
Le message d'ordre d'adresse est transmis par le BAM («broadcast announce mode») du protocole du transport.
4.4.2.2 Message de demande de revendication d'adresse
Le message de demande de revendication d'adresse peut être transmis par toute FC pour demander
les NOM et adresse de toute autre FC fonctionnant sur le réseau. À réception d'un tel message, la FC
réceptrice doit transmettre un message de revendication d'adresse contenant son adresse et son
NOM; la FC ne pouvant revendiquer une adresse doit répondre par un message d'impossibilité de
revendiquer une adresse source (voir 4.4.2.3 pour la procédure dans les deux cas). L'exception à cette
exigence concerne la FC n'ayant pas encore tenté de revendiquer une adresse, FC qui ne doit pas émettre
de message d'impossibilité de revendiquer une adresse source, ni participer aux communications du
réseau (à l'exception d'une demande de revendication d'adresse), avant d'avoir tenté de revendiquer
une adresse.
La AS d'un message de demande de revendication d'adresse doit être l'adresse NULLE si le message est
émis par une FC n'ayant pas encore revendiqué d'adresse.
Une FC peut transmettre un message de demande de revendication d'adresse soit à l'adresse de
destination globale (255), soit à une adresse particulière. Dans le premier cas, la FC peut alors
déterminer l'existence sur le réseau d'une autre FC avec un NOM particulier, en examinant les réponses
à son message à l'adresse de destination globale, alors que dans le deuxième cas, la FC qui commence
peut interroger l'autre pour déterminer si l'adresse a déjà été revendiquée. La FC doit répondre à son
message de demande de revendication d'adresse s'il est envoyé à l'adresse globale.
8 © ISO 2019 – Tous droits réservés

4.4.2.3 Message de revendication d'adresse
Le message de revendication d'adresse doit être utilisé par une FC pour répondre à un message de
demande de revendication d'adresse et pour revendiquer une adresse sur le réseau. Si une FC reçoit
un message de revendication d'adresse portant sur sa propre adresse, elle doit comparer le NOM du
message de revendication d'adresse à son propre NOM, afin de déterminer lequel des deux noms possède
le plus haut degré de priorité, c'est-à-dire la valeur numérique la plus faible. Si le NOM de la FC recevant
le message de revendication d'adresse possède un plus haut degré de priorité, la FC doit émettre un
message de revendication d'adresse contenant son NOM et son adresse. Si le NOM de la FC recevant le
message de revendication d'adresse possède un plus bas degré de priorité, la FC doit revendiquer une
autre adresse ou émettre un message d'impossibilité de revendiquer une adresse source (4.4.2.4). Le
même numéro de groupe de paramètres (PGN) sert pour les messages de revendication d'adresse et
pour les messages d'impossibilité de revendiquer une adresse source.
Fréquence de répétition de la transmission: Comme demandé
Longueur des données: 8 octets
Champ de page de données: 0
Champ de format PDU: 238
Champ spécifique PDU: 255 (Adresse globale)
Priorité par défaut: 6
Numéro de groupe de paramètres: 60928 (00EE00 )
Adresse source 0 à 253
Octets 1 à 8 NOM
Afin que la revendication d'adresse soit réussie, la FC qui envoie un message de revendication d'adresse
ne doit pas recevoir une revendication concurrente d'une autre FC pendant au moins 250 ms. Une
unité d'interconnexion réseau ne doit pas utiliser son adresse lors de communications de réseau,
tant que sa revendication d'adresse n'a pas abouti (les messages provenant d'autres UCE constituent
un cas particulier pour les unités d'interconnexion réseau) (voir l'ISO 11783-4). Toutefois, les unités
d'interconnexion réseau peuvent émettre des messages avant que leur revendication d'adresse
n'aboutisse.
4.4.2.4 Message d'impossibilité de revendiquer une adresse
En réponse à un message de demande de revendication d'adresse ou à un message de revendication
d'adresse, un message d'impossibilité de revendiquer une adresse source est transmis par toute FC qui
ne peut pas revendiquer son adresse initiale et n'a pas la capacité d'auto-configurer une adresse, ou qui
a la capacité d'auto-configurer une adresse mais ne peut pas revendiquer une adresse parce qu'aucune
adresse n'est disponible pour être utilisée. Bien que le même PGN soit utilisé pour les messages de
revendication d'adresse et pour les messages d'impossibilité de revendiquer une adresse source, l’AS
des messages d'impossibilité de revendiquer une adresse source doit être l'adresse nulle (254).
Fréquence de répétition de la transmission: En réponse uniquement
Longueur des données: 8 octets
Champ de page de données: 0
Champ de format PDU: 238
Champ spécifique PDU: 255 (Adresse globale)
Priorité par défaut: 6
Numéro de groupe de paramètres: 60928 (00EE00 )
Adresse source 254 (Adresse NULLE)
Octets 1 à 8 NOM
Un délai de transmission aléatoire (RTxD) doit être inséré entre la réception d'un message provoquant
une réponse et l'émission d'une réponse d'impossibilité de revendiquer une adresse source, ce délai
visant à réduire au minimum le risque de voir deux messages d'impossibilité de revendiquer une
adresse source provoquer des erreurs de bus.
Une FC ne pouvant pas revendiquer d'adresse ne doit pas émettre d'autre message que le message
d'impossibilité de revendiquer une adresse ou de demande de revendication d'adresse.
Une FC ne pouvant pas revendiquer une adresse peut continuer à recevoir et à traiter les messages
globaux (tel que le message d'ordre d'adresse).
4.4.2.5 Message d'ordre d'adresse
La prise en charge du message d'ordre d'adresse est facultative. Si la FC ne prend pas en charge le
message d'ordre d'adresse, le reste du paragraphe 4.4.2.5 doit être ignoré.
Ce message peut être utilisé par une FC (par exemple une unité d'interconnexion réseau telle qu'un
pont, ou un outil de maintenance) pour commander à une autre FC (appelée ci-après «FC commandée»)
d'utiliser une AS donnée. Si une FC reçoit un message d'ordre d'adresse mais qu'elle est incapable de
modifier l’AS commandée, la FC doit répondre avec une adresse revendiquant l’AS de la FC en cours.
Un opérateur ou un technicien peut alors modifier l’AS de la FC commandée par d'autres moyens. Le
constructeur d'UCE peut empêcher son produit d'accepter des messages d'ordre d'adresse provenant de
FC autres qu'un pont ou un outil de maintenance, par exemple, ou il peut demander une vérification de
sécurité pour que sa FC accepte un tel message.
Fréquence de répétition de la transmission: Comme demandé
Longueur des données: 9 octets
Champ de page de données: 0
Champ de format PDU: 254
Champ spécifique PDU: 216
Priorité par défaut: 6
Numéro de groupe de paramètres: 65240 (00FED8 )
Octets 1 à 8 NOM
Octets 9 Champ d'affectation d'adresse (nou-
velle AS)
Lors de l'acceptation du message d'ordre d'adresse, la FC commandée doit émettre un message de
revendication d'adresse, en indiquant comme AS la nouvelle adresse spécifiée dans le message d'ordre
d'adresse, les exigences de 4.5.2 s’appliquent.
Les messages d'ordre d'adresse doivent comprendre 9 octets de données; ils doivent être transmis à
l'Adresse globale (255) en mode BAM («broadcast announce mode») du protocole de transport (voir
l’ISO 11783-3). Par conséquent, les FC conçues pour utiliser les messages d'ordre d'adresse doivent
également utiliser le mode BAM.
10 © ISO 2019 – Tous droits réservés

4.4.3 Message et procédures de gestion de NOM
4.4.3.1 Généralités
Un message de modification des champs du NOM d'une FC peut être utilisé en configurant un réseau
contenant des FC comportant plusieurs instances de fonctions, des UCE ou des classes de dispositifs. Le
changement de la fonction d'une UCE générique est une autre utilisation possible de ce message. Il peut
également être utilisé lorsque d'autres méthodes d'identification unique des FC sont indisponibles. Ce
message peut être utilisé conjointement avec les étapes de paramétrage manuel et/ou avec la méthode
d'ordre d'adresse pour effectuer la configuration du réseau.
Une FC (la FC de commande) peut ordonner à une autre FC (la FC cible) d'utiliser un NOM donné en
utilisant le message de gestion de NOM. Ce message peut servir à demander à une FC cible ayant une
adresse source spécifique de remplacer certains champs de son NOM par des valeurs nouvellement
spécifiées.
La principale utilisation de ce message est de déterminer les champs d'instance dans le NOM, mais
tous les champs de NOM peuvent être modifiés en utilisant ce message à l'exception du champ Numéro
d'identité qui reste inchangé après fabrication initiale.
La prise en charge par une FC du message de gestion du NOM est facultative. Si le message est pris en
charge, le fabricant de l'UCE peut limiter l'utilisation du message en ne l'acceptant pas de la part de FC
autres que, par exemple, les outils de maintenance ou les unités d'interconnexion réseau. Les fabricants
d'UCE peuvent également exiger des processus propriétaires complémentaires de vérification de
sécurité avant d'accepter un message de Gestion de NOM. Le fabricant d'UCE peut encore limiter
l'utilisation du message en acceptant uniquement les modifications sur un sous-ensemble des champs
du NOM, par exemple les champs d'instance.
La FC commandant les changements des champs de NOM doit identifier correctement les adresses
source des FC modifiées avant d'utiliser cette commande. Les commandes sont dirigées vers les
adresses source.
4.4.3.2 Message de Gestion de NOM (GN)
Le message de GN est utilisé pour gérer l'affectation des champs du NOM d'une FC lors de la configuration
du réseau. Le message de GN contient 8 octets de données et il est envoyé sous la forme d'un message
PDU1. En fonction du mode de commande de GN, le message est envoyé à l'Adresse globale ou à une
destination spécifique à l'adresse source de la FC à modifier.
Comme spécifié ci-dessous, le message possède plusieurs utilisations et deux utilisateurs principaux.
1) Une FC de commande peut
a) ordonner à une FC cible de fixer un nouveau NOM en attente;
b) demander le NOM en attente ou en cours à une FC cible;
c) annoncer à une ou plusieurs FC cible qu'elles doivent adopter leur NOM en attente;
d) demander à une FC avec un NOM spécifié de transmettre le message de revendication d'adresse
avec son NOM courant.
2) Une FC cible doit
a) répondre aux demandes de NOM en attente ou courant;
b) acquitter ou ne pas acquitter une commande de modification du NOM en attente;
c) adopter son NOM en attente comme NOM courant et revendiquer son NOM courant sur le réseau;
d) envoyer un message de revendication d'adresse en réponse à une demande pour un NOM
correspondant.
L'Indicateur de mode de commande de GN est toujours envoyé dans les quatre bits les moins significatifs
de l'Octet 3 et il indique la façon dont le message de GN est utilisé. Les autres champs des paramètres
sont utilisés pour certains modes, mais pas pour tous. Lorsqu'ils ne sont pas utilisés pour un mode
spécifique, il convient que tous les champs inutilisés soient mis à 1. Les champs utilisés pour chaque
mode sont spécifiés dans le Tableau 3 et au paragraphe 4.4.3.3.
Fréquence de répétition de la transmission: Comme demandé
Longueur des données: 8 octets
Champ de page de données: 0
Champ de format PDU: 147
Champ spécifique PDU: Fonction du Mode de Commande de GN:
— Mode 0 AS de la FC cible
— Mode 1.4 AS de la FC de com-
mande
— Mode
...