ISO 11783-5:2011
(Main)Tractors and machinery for agriculture and forestry - Serial control and communications data network - Part 5: Network management
Tractors and machinery for agriculture and forestry - Serial control and communications data network - Part 5: Network management
ISO 11783 as a whole specifies a serial data network for control and communications on forestry or agricultural tractors and mounted, semi-mounted, towed or self-propelled implements. Its purpose is to standardize the method and format of transfer of data between sensors, actuators, control elements and information storage and display units, whether mounted on, or part of, the tractor or implement. ISO 11783-5:2011 describes the management of source addresses for control functions 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, and minimum requirements, for initialization and response to brief power outages 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
L'ISO 11783 dans son ensemble spécifie un réseau de données en série pour la commande et les communications de tracteurs forestiers ou agricoles et les équipements portés, semi-portés, traînés ou automoteurs. Elle vise à normaliser la méthode et le format du transfert de données entre capteurs, actionneurs, dispositifs de commande, unités de stockage et d'affichage de données, que ces éléments soient montés sur le tracteur ou qu'ils fassent partie du tracteur ou de tout autre outil. L'ISO 11783-5:2011 décrit la gestion des adresses sources pour les fonctions de commande 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 des processus, et des exigences minimales, d'initialisation et de réaction aux pannes d'électricité de courte durée des UCE connectées au réseau.
General Information
Relations
Frequently Asked Questions
ISO 11783-5:2011 is a standard published by the International Organization for Standardization (ISO). Its full title is "Tractors and machinery for agriculture and forestry - Serial control and communications data network - Part 5: Network management". This standard covers: ISO 11783 as a whole specifies a serial data network for control and communications on forestry or agricultural tractors and mounted, semi-mounted, towed or self-propelled implements. Its purpose is to standardize the method and format of transfer of data between sensors, actuators, control elements and information storage and display units, whether mounted on, or part of, the tractor or implement. ISO 11783-5:2011 describes the management of source addresses for control functions 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, and minimum requirements, for initialization and response to brief power outages of network-connected ECUs.
ISO 11783 as a whole specifies a serial data network for control and communications on forestry or agricultural tractors and mounted, semi-mounted, towed or self-propelled implements. Its purpose is to standardize the method and format of transfer of data between sensors, actuators, control elements and information storage and display units, whether mounted on, or part of, the tractor or implement. ISO 11783-5:2011 describes the management of source addresses for control functions 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, and minimum requirements, for initialization and response to brief power outages of network-connected ECUs.
ISO 11783-5:2011 is classified under the following ICS (International Classification for Standards) categories: 35.240.99 - IT applications in other fields; 65.060.01 - Agricultural machines and equipment in general. The ICS classification helps identify the subject area and facilitates finding related standards.
ISO 11783-5:2011 has the following relationships with other standards: It is inter standard links to ISO 11783-5:2019, ISO 11783-5:2001. Understanding these relationships helps ensure you are using the most current and applicable version of the standard.
You can purchase ISO 11783-5:2011 directly from iTeh Standards. The document is available in PDF format and is delivered instantly after payment. Add the standard to your cart and complete the secure checkout process. iTeh Standards is an authorized distributor of ISO standards.
Standards Content (Sample)
INTERNATIONAL ISO
STANDARD 11783-5
Second edition
2011-04-01
Corrected version
2011-04-15
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 2011
© ISO 2011
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 either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO 2011 – All rights reserved
Contents Page
Foreword . iv
Introduction . v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 2
4 Technical requirements . 2
4.1 General . 2
4.2 Address configuration capabilities . 3
4.2.1 General . 3
4.2.2 Non-configurable address . 3
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 . 4
4.3.1 General . 4
4.3.2 NAME . 4
4.3.3 Address . 6
4.4 Network-management procedure . 7
4.4.1 General . 7
4.4.2 Address-management messages and procedures . 8
4.4.3 NAME management message and procedures . 10
4.4.4 Network-error management . 19
4.5 Network initialization . 19
4.5.1 Acquisition of a unique address . 19
4.5.2 Address claim requirements . 20
4.5.3 Other basic requirements for initialization . 20
4.5.4 Message sequences . 21
4.5.5 CF unable to obtain an address . 25
4.6 Physical requirements . 26
4.6.1 Reaction to power-supply voltage disturbances . 26
4.6.2 Network disruption during connection, disconnection or power-up . 26
Annex A (informative) Examples of NAME construction . 27
Bibliography . 29
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.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of technical committees is to prepare International Standards. 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.
ISO 11783-5 was prepared by Technical Committee ISO/TC 23, Tractors and machinery for agriculture and
forestry, Subcommittee SC 19, Agricultural electronics.
This second edition cancels and replaces the first edition (ISO 11783-5:2001), which has been technically
revised. It also incorporates the Technical Corrigendum ISO 11783-5:2001/Cor.1:2002.
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: Implement messages application layer
Part 8: Power train messages
Part 9: Tractor ECU
Part 10: Task controller and management information system data interchange
Part 11: Mobile data element dictionary
Part 12: Diagnostics services
Part 13: File server
Part 14: Sequence control
In this corrected version, a reference to Subclause 0 at the end of the sixth paragraph in 4.1 has been
replaced by a reference to Subclause 4.5.
iv © ISO 2011 – All rights reserved
Introduction
Parts 1 to 14 of ISO 11783 specify a communications system for agricultural equipment based on
[1] [2] [3]
ISO 11898-1 and ISO 11898-2 . SAE J1939 documents, on which parts of ISO 11783 are based, were
developed jointly for use in truck and bus applications and for construction and agriculture applications. Joint
documents were completed to allow electronic units that meet the truck and bus SAE J1939 specifications to
be used by agricultural and forestry equipment with minimal changes. This part of ISO 11783 is harmonized
[4]
with SAE J1939/81 . General information on ISO 11783 is to 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.
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 right has assured ISO that he is willing to negotiate licences under reasonable and
non-discriminatory terms and conditions with applicants throughout the world. In this respect, the statement of
the holder of this patent right is registered with ISO. Information may be obtained from:
Robert Bosch GmbH
Wernerstrasse 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
patent rights other than those identified above. ISO shall not be held responsible for identifying any or all such
patent rights.
INTERNATIONAL STANDARD ISO 11783-5:2011(E)
Tractors and machinery for agriculture and forestry — Serial
control and communications data network —
Part 5:
Network management
1 Scope
ISO 11783 as a whole specifies a serial data network for control and communications on forestry or
agricultural tractors and mounted, semi-mounted, towed or self-propelled implements. Its purpose is to
standardize the method and format of transfer of data between sensors, actuators, control elements and
information storage and display units, whether mounted on, or part of, the tractor or implement. This part of
ISO 11783 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, and minimum requirements, for
initialization and response to brief power outages of network-connected ECUs.
2 Normative references
The following referenced documents are indispensable for the application 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
ISO 11783-4, Tractors and machinery for agriculture and forestry — Serial control and communications data
network — Part 4: Network layer
ISO 11783-7, Tractors and machinery for agriculture and forestry — Serial control and communications data
network — Part 7: Implement messages application layer
ISO 11783-12, Tractors and machinery for agriculture and forestry — Serial control and communications data
network — Part 12: Diagnostics services
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 11783-1 and the following apply.
3.1
control function
CF
function that performs operations to complete a specific function on or within devices
NOTE A CF has one unique address on the network.
3.2
current NAME
CF NAME that is transmitted in its address-claimed message
3.3
NAME management
NM
method for changing the NAME of a CF at run time
3.4
pending NAME
NAME temporarily stored by a particular CF as the result of NAME management messages received from a
qualified source
3.5
random transmit delay
RTD
delay period calculated by multiplying a random number in the range 0 to 255 by 0,6 ms
NOTE A seed to the random number generator can use the identity number in the NAME, or other unique information
within the CF.
3.6
suspect parameter number
SPN
19-bit number used to identify a particular element, component, or parameter associated with a CF
NOTE Suspect parameter numbers are assigned to each individual parameter in a parameter group and to items that
are relevant to diagnostics, but are not a parameter in a parameter group.
4 Technical requirements
4.1 General
Network management for an ISO 11783 network provides the definitions and procedures necessary to
uniquely identify CFs on the network, manage the assignment of addresses and manage 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 giving the ability or non-ability to change that address are specified in 4.3.
CFs shall successfully claim an address in accordance with 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.
2 © ISO 2011 – All rights reserved
The inability to successfully claim an address in accordance with the procedure shall be handled and reported
to the network following a standard method detailed in 4.4.2.4.
Network initialization sequences associated with the address-claiming process are described in 4.5.
A set of physical requirements which extends the requirements of ISO 11783-2 is listed in 4.6.
Where timeouts are not otherwise specified, the timeout defaults defined in ISO 11783-3 apply.
4.2 Address configuration capabilities
4.2.1 General
Address configuration is the method by which a particular CF determines the SA it will use for an address
claim. For the purposes of the address-claiming 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 previous edition of this
part of ISO 11783 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-claiming 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.
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 the 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
protocol specified in this part of ISO 11783 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
can exist for each of the CFs and each CF shall claim a unique SA.
An address-claimed 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 will retain 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 (see Table 1) is shown in Figure 1.
Function
Self-configurable address
Industry group Function instance
Device class instance
ECU instance
Device class
Manufacturer code
Reserved
Identity number
64 1
64-bit NAME
1 3 1 4 1 7 1 1 8 1 5 1 3 1 11 1 21 1
8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1
Byte 8 Byte 7 Byte 6 Byte 5 Byte 4 Byte 3 Byte 2 Byte 1
NOTE The 64-bit value is sent with byte 1 first and byte 8 last when transmitted on the network.
Figure 1 — NAME bit fields in controller area network (CAN) message data bytes
4 © ISO 2011 – All rights reserved
Table 1 — NAME fields
No. of Byte
a
Field SPN Definition Byte ordering
bits No.
Indicates whether a CF is self-configurable (1) or not
Self-configurable
2844 (0); needs always to be known and set to the 1 Bit 8: Self-configurable address
address
appropriate value
Defined and assigned by ISO, identifies NAMEs
Bit 7 to bit 5: Industry group (most
b
Industry group 2846 associated with industries (e.g. agricultural 3 8
significant at bit 7)
equipment)
Indicates occurrence of a particular device class in a
Device class Bit 4 to bit 1: Device class instance
2843 connected network; definition depends on industry 4
c
instance (most significant at bit 4)
group field contents (see Figure 2)
Defined and assigned by ISO; provides a common
NAME for a group of functions within a connected
Bit 8 to bit 2: Device class (most
b
Device class 2842 network; when combined with an industry group, can 7
significant at bit 8)
be correlated to a common NAME, e.g. “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 but 254, definition depends on device
Bit 8 to bit 1: Function (most
b
Function 2841 class; when combined with industry group and 8 6
significant at bit 8)
device class, can be correlated to a common NAME
for specific CF, though not implying any specific
capabilities
Indicates specific occurrence of a function on a Bit 8 to bit 4: Function instance (most
Function instance 2839 5
particular device system of a network significant at bit 8)
Indicates which of a group of ECUs associated with Bit 3 to bit 1: ECU (most significant at
ECU instance 2840 3
a given function is referenced bit 3)
Bit 8 to bit 1: Most significant eight
4 bits of manufacturer code (most
Assigned by committee (see ISO 11783-1); indicates
significant at bit 8)
Manufacturer
2838 manufacturer of ECU for which the NAME is being 11
b
code
Bit 8 to bit 6: Least significant three
referenced; independent of any other NAME field
bits of manufacturer code (most
significant at bit 8)
Bit 5 to bit 1: Most significant five bits
of identity number (most significant at
bit 5)
Bit 8 to bit 1: Second byte of identity
Identity number 2837 Assigned by the ECU manufacturer 21 2 number code (most significant at
bit 8)
Bit 8 to bit 1: Least significant byte of
1 identity number (most significant at
d
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
See ISO 11783-1 for numerical values of industry groups, device classes, functions and manufacturer codes.
c
Bit 1 is the last of the data bits sent and closest to the cyclic redundancy code (CRC) in the message.
d
Bit 8 is the bit closest to the data length code (DLC) in the message.
Table 1 defines and 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 are identical to the NAME of another CF, the NAME shall be made unique by setting the
identity number (e.g. 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.
Fields assigned by ISO
Fields assigned by manufacturer
Independent
fields
1 3 7 11
0 0
7 21
4 7
Dependent
fields
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 controller area network (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 SA that the CF uses.
6 © ISO 2011 – All rights reserved
Self-configurable address
Industry group
Device class instance
Device class
Reserved
Function upper 128 Function lower 128
Function instance
ECU instance
Manufacturer code
Identity number
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-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 used
1)
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 range, this
type of CF shall be self-configurable-address-capable. This permits the address-claiming process to provide
unique addresses for each CF on the network.
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 to CFs with assigned preferred addresses.
4.3.3.5 NULL address
The NULL address (254) is only permitted in the source address field of the ISO 11783 message identifier and
is intended for use only within network management communications.
4.3.3.6 Global address
The global address (255) is only permitted in the destination address field of the ISO 11783 message identifier
and never in the source address field.
4.4 Network-management procedure
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 parameter
group number (PGN) message specified in ISO 11783-3].
1) The previous edition of ISO 11783-5 did not enforce the address-to-function relationship.
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 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
Message PGN PF PS SA Data length Data
a b
Request-for-address-claimed (request PGN) 59904 234 DA SA 3 PGN 60928
Address-claimed 60928 238 255 SA 8 NAME
Cannot-claim-source-address 60928 238 255 254 8 NAME
c
Commanded-address 65240 254 216 SA 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 can 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 a 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 a 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
8 © ISO 2011 – All rights reserved
source address, it shall compare its own NAME with the one received and determine which NAME has the
higher priority, i.e. the lower numerical value. If it determines that 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
Protocol data unit (PDU) format field: 238
PDU-specific field: 255 (global address)
Default priority: 6
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 a self-
configurable address capability, or that has a 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
Protocol data unit (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
An RTD 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 (e.g. 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 this subclause 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 (hereafter 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 CF's 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
Protocol data unit (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 shall apply.
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.
NOTE This is a new message in this second edition of this part of ISO 11783.
One CF (the commanding CF) can command another CF (the target CF) to use a given NAME by using the
NAME management message. This message can be used to instruct the 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 shall 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 interconnection units. ECU manufacturers might 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, e.g. 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 2011 – 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 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 sent either to the global address or to a destination-specific source address of
the CF to be modified.
As specified below, there are two main users and several uses of the message.
a) A commanding CF can
1) command a target CF to set a new pending NAME;
2) request the pending or current NAME from a target CF;
3) announce to one or more target CFs that they shall adopt their pending NAME;
4) request that a CF with a specified NAME transmit the address-claimed message with its current
NAME.
b) A target CF shall
1) respond to requests for its pending or current NAME;
2) acknowledge (ACK) or negatively acknowledge (NACK) a command to change its pending NAME;
3) adopt its pending NAME as the current NAME and claim its current NAME on the network;
4) 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
Protocol data unit (PDU) format field: 147
PDU-specific field: Depending on NM control mode:
— Mode 0: SA of target CF
— Modes 1-4: SA of commanding CF
— Modes 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
Cmd function NAME checksum / error code
Cmd self-configurable address
Cmd industry group Cmd function instance
Cmd device class instance Cmd ECU instance
Cmd manufacturer code
Cmd device class
Reserved NM ctrl mode Qualifier flag s
Reserved
1 3 1 4 1 7 1 1 8 1 5 1 3 1 11 1 1 4 1 1 1 1 1 1 1 1 1 8 1
8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1
Byte 8 Byte 7 Byte 6 Byte 5 Byte 4 Byte 3 Byte 2 Byte 1
Figure 3 — NAME management message data bytes
Table 3 — NAME management message parameters
Parameter used in No. of Byte
Parameter SPN Byte ordering
modes bits No.
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
5670 8 6 Bit 8 to bit 1
Commanded function
a
5669 5 Bit 8 to bit 4
Commanded function instance
a
5668 3 Bit 3 to bit 1
Commanded ECU instance
0, 1, 2, 3, 8
Bit 8 to bit 1
Most significant eight bits
a,b
Commanded manufacturer code 5667 11
Bit 8 to bit 6
Least significant three bits
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 2011 – 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 has 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 CF's original NAME truncated to the eight least significant bits.
Data length: 8 bits
Resolution: 1 bit
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. The code values are as follows:
0 Security not satisfied. Different SA for adopt pending than for 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 perf
...
NORME ISO
INTERNATIONALE 11783-5
Deuxième édition
2011-04-01
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 2011
DOCUMENT PROTÉGÉ PAR COPYRIGHT
© ISO 2011
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'ISO à l'adresse ci-après ou du comité membre de l'ISO dans le pays du demandeur.
ISO copyright office
Case postale 56 CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Publié en Suisse
ii © ISO 2011 – 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 . 2
4 Exigences techniques . 2
4.1 Généralités . 2
4.2 Capacités de configuration d'adresse . 3
4.2.1 Généralités . 3
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 . 4
4.3 Exigences concernant le NOM et l'adresse . 4
4.3.1 Généralités . 4
4.3.2 NOM . 4
4.3.3 Adresse . 7
4.4 Procédure de gestion de réseau . 8
4.4.1 Généralités . 8
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 . 20
4.5.1 Acquisition d'une adresse univoque . 20
4.5.2 Spécifications de la revendication d'adresse . 21
4.5.3 Autres spécifications 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
4.6 Exigences physiques . 28
4.6.1 Réaction aux perturbations de l'alimentation électrique . 28
4.6.2 Rupture du réseau lors de la connexion, de la déconnexion ou de la mise sous tension . 29
Annexe A (informative) Exemples de construction de NOM . 30
Bibliographie . 32
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 Normes internationales sont rédigées conformément aux règles données dans les Directives ISO/CEI,
Partie 2.
La tâche principale des comités techniques est d'élaborer les Normes internationales. 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.
L'ISO 11783-5 a été élaborée par le comité technique ISO/TC 23, Tracteurs et matériels agricoles et forestiers,
sous-comité SC 19, Électronique en agriculture.
Cette deuxième édition annule et remplace la première édition (ISO 11783-5:2001), qui a fait l'objet d'une
révision technique. Elle incorpore également le Rectificatif technique ISO 11783-5:2001/Cor.1:2002.
L'ISO 11783 comprend les parties suivantes, présentées sous le titre général 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
Partie 2: Couche physique
Partie 3: Couche liaison de données
Partie 4: Couche réseau
Partie 5: Gestion du réseau
Partie 6: Terminal virtuel
Partie 7: Couche d'application de base
Partie 8: Messages de gestion de la transmission (boîte de vitesses)
Partie 9: Unité de commande électronique du tracteur
Partie 10: Contrôleur de tâches et échange de données des systèmes d'information de gestion
Partie 11: Dictionnaire d'éléments de données mobiles
Partie 12: Services de diagnostic
Partie 13: Serveur de fichiers
Partie 14: Contrôle de séquence
La présente version française de l'ISO 11783-5 correspond à la version anglaise publiée le 2011-04-01 et
corrigée le 2011-04-15.
iv © ISO 2011 – Tous droits réservés
Introduction
Les parties 1 à 14 de l'ISO 11783 spécifient un système de communication destiné aux matériels agricoles
[1] [2] [3]
fondé sur l'ISO 11898-1 et l'ISO 11898-2 . Les documents SAE J1939 , sur lesquels les parties de
l'ISO 11783 sont fondées, ont été élaborés conjointement pour une utilisation dans des applications de
camions et de bus, ainsi que pour des applications de construction et d'agriculture. Les documents joints ont
été élaborés pour permettre l'utilisation, par des matériels agricoles et forestiers, d'unités électroniques
conformes aux spécifications SAE J1939 relatives aux camions et aux bus, sans que des modifications
majeures soient nécessaires. La présente partie de l'ISO 11783 est harmonisée avec les spécifications
[4]
SAE J1939/81 . Des informations générales sur l'ISO 11783 se trouvent 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, en
proposant un système normalisé.
L'Organisation internationale de normalisation (ISO) attire 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) traité dans ce document.
L'ISO ne prend pas position quant à la preuve, à la validité et à la portée de ces droits de propriété.
Le détenteur de ces droits de propriété a 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 des droits de propriété est enregistrée à l'ISO. Des informations peuvent
être demandées à:
Robert Bosch GmbH
Wernerstrasse 51
Postfach 30 02 20
D-70442 Stuttgart-Feuerbach
Allemagne
L'attention est d'autre part attiré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.
NORME INTERNATIONALE ISO 11783-5:2011(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
L'ISO 11783 dans son ensemble spécifie un réseau de données en série pour la commande et les
communications de tracteurs forestiers ou agricoles et les équipements portés, semi-portés, traînés ou
automoteurs. Elle vise à normaliser la méthode et le format du transfert de données entre capteurs,
actionneurs, dispositifs de commande, unités de stockage et d'affichage de données, que ces éléments soient
montés sur le tracteur ou qu'ils fassent partie du tracteur ou de tout autre outil. La présente partie de
l'ISO 11783 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 des processus, et des
exigences minimales, d'initialisation et de réaction aux pannes d'électricité de courte durée des UCE
connectées au réseau.
2 Références normatives
Les documents de référence suivants sont indispensables pour l'application 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
ISO 11783-4, Tracteurs et matériels agricoles et forestiers — Réseaux de commande et de communication de
données en série — Partie 4: Couche réseau
ISO 11783-7, Tracteurs et matériels agricoles et forestiers — Réseaux de commande et de communication de
données en série — Partie 7: Couche d'application de base
ISO 11783-12, Tracteurs et matériels agricoles et forestiers — Réseaux de commande et de communication
de données en série — Partie 12: Services de diagnostic
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.
3.1
fonction de commande
FC
fonction exécutant des opérations destinées à réaliser une fonction spécifique sur des dispositifs ou en leur
sein
NOTE Une FC possède une adresse univoque sur le réseau.
3.2
NOM courant
NOM de FC transmis dans son message de revendication d'adresse
3.3
gestion de NOM
GN
méthode pour changer le NOM d'une FC en cours d'exécution
3.4
NOM en attente
NOM mémorisé provisoirement par une FC particulière résultant de messages de gestion de NOM reçus
d'une source qualifiée
3.5
retard de transmission aléatoire
RTD
retard calculé en multipliant par 0,6 ms un nombre aléatoire compris entre 0 et 255
NOTE 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.
3.6
numéro de paramètre attendu
SPN
nombre de 19 bits utilisé pour identifier un élément, un composant ou un paramètre particulier associé à une
FC
NOTE Les numéros de paramètres attendus sont assignés à chacun des paramètres d'un groupe de paramètres et
aux éléments qui correspondent aux diagnostics mais qui ne constituent pas un paramètre d'un groupe de paramètres.
4 Exigences techniques
4.1 Généralités
La gestion d'un réseau ISO 11783 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.
2 © ISO 2011 – Tous droits réservés
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'inaptitude à réussir à revendiquer une adresse conformément à la procédure doit être traitée et rapportée au
réseau selon une méthode normalisée détaillée 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.
Un ensemble de caractéristiques physiques complétant les exigences de l'ISO 11783-2 est énuméré en 4.6.
Lorsque les temporisations ne sont pas spécifiées par ailleurs, les temporisations par défaut définies dans
l'ISO 11783-3 s'appliquent.
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 qu'elle utilisera 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 à l'édition précédente de la présente partie de l'ISO 11783 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.
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 spécifié dans la présente partie de l'ISO 11783 permettent
d'associer des adresses source individuelles à des FC particulières (voir 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.
Adresse auto-configurable Fonction
Groupe sectoriel Instance fonction
Instance UCE
Instance classe dispositifs
Classe dispositifs Code constructeur
Réservé Numéro d’identité
64 NOM de 64 bits 1
1 3114 7 1 1 8 115 1 3 11 1 21 1
8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1
Octet 8 Octet 7 Octet 6 Octet 5 Octet 4 Octet 3 Octet 2 Octet 1
NOTE La valeur de 64 bits est envoyée en commençant par l'octet 1 et en terminant par l'octet 8 lorsqu'elle est
transmise par le bus CAN.
Figure 1 — Champs des bits NOM dans les octets de données d'un message CAN
(controller area network)
4 © ISO 2011 – Tous droits réservés
Tableau 1 — Champs NOM
Nombre Nombre
a
Champ SPN Définition
Ordre des octets
de bits d'octets
Indique si une FC est auto-configurable (1) ou non
Adresse auto- Bit 8: Adresse auto-
2844 (0); doit nécessairement être connu et posséder la 1
configurable configurable
valeur appropriée
Défini sur la base des recommandations de l'ISO, Bit 7 à bit 5: Groupe
b
2846 indique les NOMS associés à un secteur d'activité 3 sectoriel (bit 7 de poids le
Groupe sectoriel
(par exemple «matériel agricole») plus fort)
Indique l'occurrence d'une classe dispositifs donnée
Bit 4 à bit 1: Instance
Instance classe au sein d'un réseau connecté; la définition dépend
classe dispositifs (bit 4 de
2843 4
dispositifs des contenus du champ du groupe sectoriel
c
poids le plus fort)
(voir Figure 2)
Défini sur la base des recommandations de l'ISO,
fournit un NOM commun à un groupe de fonctions
Bit 8 à bit 2: Classe
d'un réseau connecté; peut être lié à un NOM
b
2842 7 dispositifs (bit 8 de poids le
Classe dispositifs
commun en association avec le groupe sectoriel:
plus fort)
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 mais
< 254, sa définition dépend du champ classe Bit 8 à bit 1: Fonction (bit 8
b
Fonction 2841 8 6
dispositifs; allié aux champs groupe sectoriel et de poids le plus fort)
classe dispositifs, peut être lié à un NOM commun
de FC donnée et ne suppose aucune capacité
particulière
Bit 8 à bit 4: Instance
Indique l'occurrence particulière d'une fonction au
Instance fonction 2839 5 fonction (bit 8 de poids le
sein d'un même système de dispositifs d'un réseau
plus fort)
Indique l'UCE, parmi les différentes unités associées Bit 3 à bit 1: Instance UCE
Instance UCE 2840 3
à une fonction donnée, à laquelle il est fait référence (bit 3 de poids le plus fort)
Bit 8 à bit 1: Huit bits les
plus significatifs du code
constructeur (bit 8 de poids
Affecté par un comité (voir l'ISO 11783-1), indique
le plus fort)
Code
l'entreprise responsable de la production du module
2838 11
b
constructeur de commande électronique portant un NOM donné;
Bit 8 à bit 6: Trois bits les
ne dépend d'aucun autre champ du NOM
moins significatifs du code
constructeur (bit 8 de poids
le plus fort)
Bit 5 à bit 1: Cinq bits les
plus significatifs du numéro
d'identité (bit 5 de poids le
plus fort)
Bit 8 à bit 1: Second octet
2 du numéro d'identité (bit 8
Numéro d'identité 2837 Assigné par le fabricant de l'UCE 21
de poids le plus fort)
Bit 8 à bit 1: Octet le moins
significatif du numéro
d'identité (bit 8 de poids le
d
plus fort)
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
Voir l'ISO 11783-1 pour les valeurs numériques des groupes sectoriels, des classes dispositifs, des fonctions et des codes
constructeur.
c
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.
d
Le bit 8 est le bit le plus proche du DLC («data length code», code de longueur de données) dans le message.
Le Tableau 1 définit et 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 affecté à zéro.
Les champs instance du NOM peuvent être modifiés et reconfigurés, 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 11873 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 sont 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
dispositifs 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 dispositifs et groupe sectoriel. Le
nombre de bits de chaque champ est noté au-dessus de chaque champ.
Champs assignés par l’ISO
Champs assignés par le constructeur
Champs
indépendants
1 3 7 11
0 0
7 21
4 7
Champs
dépendants
Figure 2 — Dépendances des champs NOM
6 © ISO 2011 – Tous droits réservés
Adresse auto-configurable
Groupe sectoriel
Instance classe dispositifs
Classe dispositifs
Réservé
Fonction < 128
Fonction > 128
Instance fonction
Instance UCE
Code constructeur
Numéro d’identité
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 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 exécutée par une FC ne doit jamais être déterminée à partir de la seule adresse source: on ne
1)
doit utiliser que le NOM de la FC pour déterminer la fonction .
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.
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 peut être acceptée que dans le champ d'adresse source de l'identificateur de
message ISO 11783 et elle est destinée à être utilisée uniquement au sein des communications de gestion du
réseau.
1) L'édition précédente de l'ISO 11783-5 ne réglementait pas la relation adresse/fonction.
4.3.3.6 Adresse globale
L'adresse globale (255) ne peut être acceptée que dans le champ d'adresse destination de l'identificateur de
message ISO 11783, mais jamais dans le champ d'adresse source.
4.4 Procédure 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 (numéro de groupe de paramètres), 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
Longueur
Message PGN FP SP AS des Données
données
Demande de revendication d'adresse
a b
234 DA 3 PGN 60928
59904 AS
(demande PN)
Revendication d'adresse 60928 238 255 AS 8 NOM
Impossibilité de revendiquer une adresse 60928 238 255 254 8 NOM
c
Ordre d'adresse 65240 254 216 AS 9 NOM, nouvelle AS
a
Voir l'ISO 11783-3.
b
L'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.
8 © ISO 2011 – Tous droits réservés
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. Une 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 une 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.
L'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.
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 (voir 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.
Vitesse de répétition de la transmission: Au choix
Longueur des données: 8 octets
Champ page de données: 0
Champ format PDU («protocol data unit»): 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 to 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).
Vitesse de répétition de la transmission: Réponse seulement
Longueur des données: 8 octets
Champ page de données: 0
Champ format PDU («protocol data unit»): 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 to 8 NOM
Un RTD 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
(par exemple 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 présent paragraphe 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'adresse source 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.
Vitesse de répétition de la transmission: Au choix
Longueur des données: 9 octets
Champ page de données: 0
Champ format PDU («protocol data unit»): 254
Champ spécifique PDU: 216
Priorité par défaut: 6
)
Numéro de groupe de paramètres: 65240 (00FED8
Octets 1 to 8 NOM
Octet 9 Champ d'affectation d'adresse (nouvelle AS)
À 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 en 4.5.2 doivent s'appliquer.
10 © ISO 2011 – Tous droits réservés
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.
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.
NOTE Il s'agit d'un nouveau message dans cette deuxième édition de la présente partie de l'ISO 11783.
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
doit rester 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
...










Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...