ISO 16845:2004

Road vehicles — Controller area network (CAN) — Conformance test plan

ISO 16845:2004 provides the methodology and abstract test suite necessary for checking the conformance of any CAN implementation of the CAN specified in ISO 11898-1.

Véhicules routiers — Gestionnaire de réseau de communication (CAN) — Plan d'essai de conformité

L'ISO 16845:2004 spécifie la méthodologie et la suite d'essais nécessaires à la vérification de la conformité de toute réalisation CAN aux spécifications CAN de l'ISO 11898-1.

General Information

• Status: Withdrawn
• Publication Date: 02-Mar-2004
• Withdrawal Date: 02-Mar-2004
• ICS: 43.040.15 - Car informatics. On board computer systems
• Technical Committee: ISO/TC 22/SC 31 - Data communication
• Drafting Committee: ISO/TC 22/SC 31/WG 3 - In-vehicle networks
• Current Stage: 9599 - Withdrawal of International Standard
• Completion Date: 26-Oct-2016

Relations

• Revised: ISO 16845-1:2016 - Road vehicles — Controller area network (CAN) conformance test plan — Part 1: Data link layer and physical signalling
• Effective Date: 27-Jul-2013

Standards Content (Sample)

INTERNATIONAL ISO
STANDARD 16845
First edition
2004-03-15

Road vehicles — Controller area network
(CAN) — Conformance test plan
Véhicules routiers — Gestionnaire de réseau de communication
(CAN) — Plan d'essai de conformité




Reference number
ISO 16845:2004(E)
©
ISO 2004

---------------------- Page: 1 ----------------------
ISO 16845:2004(E)
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.


©  ISO 2004
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 [e-mail]
Web www.iso.org
Published in Switzerland

ii © ISO 2004 – All rights reserved

---------------------- Page: 2 ----------------------
ISO 16845:2004(E)
Contents Page
Foreword. iv
1 Scope. 1
2 Normative references . 1
3 Terms and definitions. 1
4 Abbreviated terms. 4
5 General. 5
5.1 Architecture of the test plan (TP) . 5
5.2 TP organization . 7
5.3 Hierarchical structure of tests . 8
6 LT parameters . 9
6.1 Overview . 9
6.2 Description of parameters. 9
7 Test type 1, received frame type . 10
7.1 Test class 1, valid frame format . 10
7.2 Test class 2, error detection . 18
7.3 Test class 3, active error frame management. 22
7.4 Test class 4, overload frame management. 24
7.5 Test class 5, passive-error state and bus-off.26
7.6 Test class 6, error counter management.29
7.7 Test class 7, bit timing class. 37
8 Test type 2, transmitted frame. 42
8.1 Test class 1, valid frame format . 42
8.2 Test class 2, error detection . 47
8.3 Test class 3, active error frame management. 50
8.4 Test class 4, overload frame management. 52
8.5 Test class 5, passive-error state and bus-off.55
8.6 Test class 6, error counter management.62
8.7 Test class 7, bit timing. 71
9 Test type 3, bi-directional frame. 76
9.1 Test class 1, valid frame format . 76
9.2 Test class 2, error detection . 76
9.3 Test class 3, active error frame management. 76
9.4 Test class 4, overload frame management. 76
9.5 Test class 5, passive-error state and bus-off.76
9.6 Test class 6, error counter management.76
9.7 Test class 7, bit timing. 77

© ISO 2004 – All rights reserved iii

---------------------- Page: 3 ----------------------
ISO 16845:2004(E)
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies
(ISO member bodies). The work of preparing International Standards is normally carried out through ISO
technical committees. Each member body interested in a subject for which a technical committee has been
established has the right to be represented on that committee. International organizations, governmental and
non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the
International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
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.
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.
ISO 16845 was prepared by Technical Committee ISO/TC 22, Road vehicles, Subcommittee SC 3, Electrical
and electronic equipment.
iv © ISO 2004 – All rights reserved

---------------------- Page: 4 ----------------------
INTERNATIONAL STANDARD ISO 16845:2004(E)

Road vehicles — Controller area network (CAN) —
Conformance test plan
1 Scope
This International Standard provides the methodology and abstract test suite necessary for checking the
conformance of any CAN implementation of the CAN specified in ISO 11898-1.
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/IEC 9646-1:1994, Information technology  Open Systems interconnection  Conformance testing
methodology and framework  Part 1: General concepts
ISO 11898-1:2003, Road vehicles  Controller area network (CAN)  Part 1: Data link layer and physical
 
signalling
ISO 11898-2:2003, Road vehicles  Controller area network (CAN)  Part 2: High-speed medium access
unit
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1
ACK delimiter
second bit of the ACK field
3.2
ACK field
last field before the EOF, used for message validation
3.3
acknowledgement error
error condition of the transmitter when it does not detect a dominant bit on the ACK slot
3.4
ACK slot
first bit of the ACK field
3.5
active error flag
first field of an active error frame
3.6
active error frame
error frame that starts with an active (dominant) error flag
© ISO 2004 – All rights reserved 1

---------------------- Page: 5 ----------------------
ISO 16845:2004(E)
3.7
active state
state of a node when it can transmit an active error frame
3.8
arbitration field
field starting after the SOF bit and finished with the RTR bit
3.9
bit error
error condition encountered when the received bit does not correspond to the transmitted or expected bit
3.10
conformance testing
application of the test plan to an IUT
3.11
CRC delimiter
last bit of the CRC field
3.12
CRC error
error condition of a receiver when the received CRC code does not match the calculated CRC code
3.13
CRC field
field preceding the ACK field, consisting of the CRC code and the CRC delimiter
3.14
end of frame
last field of a data or remote frame before the intermission field
3.15
error delimiter
second field of an error frame
3.16
error flag
first field of an error frame
3.17
error frame
formatted sequence of bits indicating an error condition
3.18
form error
error condition encountered in a fixed form field
3.19
idle state
CAN bus state where no frame is started after intermission field
3.20
intermission field
field after EOF, error delimiter, or overload delimiter
3.21
lower tester
tester that supervises the test suite
2 © ISO 2004 – All rights reserved

---------------------- Page: 6 ----------------------
ISO 16845:2004(E)
3.22
overload delimiter
second field of an overload frame
3.23
overload flag
first field of an overload frame
3.24
overload frame
formatted sequence of bits indicating an overload condition
3.25
passive error flag
first part of a passive error frame
3.26
passive state
state of the device when the value of the REC or the TEC has reached the error passive limit
3.27
REC passive state
state of the device when the value of the REC has reached the error passive limit
3.28
recessive state
state of the CAN bus when no CAN node drives a dominant value on the line
3.29
stuff bit
bit inserted into the bit stream to increase the number of edges for synchronization purpose
3.30
stuff error
error condition encountered when an expected stuff bit is missing
3.31
suspend transmission field
waiting time added after the intermission field for an error passive transmitter, before it can start another
transmission
3.32
TEC passive state
state of the device when the value of the TEC has reached the error passive limit
3.33
test case
specificly numbered and named test in the test suite
3.34
test frame
CAN frame containing the test pattern specified
3.35
test suite
check of the behaviour of the IUT for particular parameters of the CAN specification
© ISO 2004 – All rights reserved 3

---------------------- Page: 7 ----------------------
ISO 16845:2004(E)
3.36
test type
specification of the direction of the test frames
EXAMPLE Specification of the behaviour of the IUT receiving and/or transmitting messages.
3.37
time quantum
elementary time unit of the CAN bit time derived from the oscillator clock and the prescaler
3.38
upper tester
tester that acts as an user of the IUT
4 Abbreviated terms
ACK Acknowledgement
BRP Bit rate prescaler
CAN Controller area network
CRC Cyclic redundancy check
CTRL Control
DLC Data length code
EOF End of frame
DIE Identifier extension bit
IDEN CAN identifier
IPT Information processing time
IUT Implementation under test
LLC Logical link control
LME Layer management entity
LT Lower tester
MAC Medium access control
MDI Medium dependent interface
NDATA Network data
NTQ Number of Time Quanta
PCO Point of control and observation
4 © ISO 2004 – All rights reserved

---------------------- Page: 8 ----------------------
ISO 16845:2004(E)
PLS Physical layer signalling
PMA Physical medium attachment
REC Receive error counter
RTR Remote transmission request
RX Receiver signal
SJW Re-Synchronization jump width
SLIO Serial linked input/output
SOF Start of frame
SRR Substitute remote request
TEC Transmit error counter
TP Test plan
TQ Time quantum
TSYS System clock time (of the IUT)
UT Upper tester
5 General
5.1 Architecture of the test plan (TP)
The architecture of the TP plan is as shown in Figure 1.
The TP is a specific application of ISO 9646-1 and is restricted to the single party testing mode. Since the
upper service boundary of a CAN implementation is not standardized and in some cases may not be observed
and controlled, because of an application specific behaviour embedded in this implementation, (e.g. CAN
SLIO), the TP shall rely either on the coordinated test method or the remote test method.
Depending on the test method applied, the TP shall involve up to three test functions:
 an LT operating in way similar to the CAN IUT, running test suite and granting test verdict;
 an UT acting as user of the IUT (IUT-dependant);
 a test management protocol between the IUT and the LT, consisting of test coordination procedures.
The last two functions are only applicable to the coordinated test procedure.
During testing, the LT may observe and control the standardized lower service boundary of the IUT (PCO)
through the two service primitives provided by the PLS sub-layer, i.e. PLS Data.indicate and PLS
Data.request, in most cases.
The environment that implements the TP is described in Figure 2.
© ISO 2004 – All rights reserved 5

---------------------- Page: 9 ----------------------
ISO 16845:2004(E)

Figure 1 — Architecture of the test plan

Figure 2 — CAN conformance TP environment
Using the network interface, the LT indicates to the UT the actions to be performed and the UT provides the
LT with information concerning the internal behaviour of the IUT.
In order to allow the LT and the UT to communicate, it is necessary to specify some test coordination
procedures between them. These procedures use the network to the exclusion of any other physical link. They
are used to set up the UT and to verify the test results.
6 © ISO 2004 – All rights reserved

---------------------- Page: 10 ----------------------
ISO 16845:2004(E)
5.2 TP organization
5.2.1 General organization
The LT verifies if the IUT complies with the MAC, LLC, and PLS sub-layers of the CAN specification. The LT
points out differences between what is expected according to the specification and the actual behaviour of the
IUT.
The test suites of the TP are independent of one another. Each test suite may be used to check the behaviour
of the IUT for a particular parameter of the CAN specification. Tests may be performed in sequence or
separately.
Tests requiring variations of individual parameters (identifier, number of data, etc.) shall be repeated for each
value of the parameter, these repetitions being known as elementary tests. A test including different
elementary tests is valid only if all tests are passed.
5.2.2 Test organization
5.2.2.1 Elementary tests
5.2.2.1.1 Description
Each elementary test shall consist of three states:
 set-up;
 test;
 verification.
At the PCO, these states involve interchanges of valid sequences of PLS service primitives [CAN frame(s)] or
invalid sequences of PLS primitives (invalid CAN frames or noise).
Before the first elementary test is started the IUT shall be initialized into the default state.
5.2.2.1.2 Set-up state
The set-up state is the state the IUT shall be in before entering the test state.
5.2.2.1.3 Test state
The test state is the part of the elementary test in which the parameter or protocol feature is checked. This
state needs one or several interchanges of frames, called test frames.
5.2.2.1.4 Verification state
The verification state is made up of the data-reading frames, which verify that the data have been handled in
accordance with the CAN specification.
For tests belonging to Classes 1 to 6 according to 5.3.3, the LT shall be able to detect the correct value of the
bit.
For bit timing tests (Class 7 according to 5.3.3), the LT shall be able to detect a faulty synchronization of one
time quantum.
5.2.2.2 Default state
The default state is characterized by the following default values:
 both REC and TEC shall be equal to 0;
 no pending transmission shall be present;
© ISO 2004 – All rights reserved 7

---------------------- Page: 11 ----------------------
ISO 16845:2004(E)
 IUT shall be in idle state;
 PLS data.indicate and PLS data.request shall be recessive.
After the end of each elementary test, the default state shall be applied.
5.3 Hierarchical structure of tests
5.3.1 Overview
The tests are grouped in categories in order to aid planning, development, understanding or execution of each
test. Three levels of categories are specified test types, test classes and test cases.
5.3.2 Test types
Test types specify the direction of the frames. There are three types:
 Type 1, received frame, includes all tests evaluating the behaviour of the IUT for data frames and
remote frames received by the IUT;
 Type 2, transmitted frame, includes all tests evaluating the behaviour of the IUT for data frames and
remote frames transmitted by the IUT;
 Type 3, bi-directional frame, includes all tests with data frames or remote frames both received and
transmitted by the IUT.
5.3.3 Test classes
Each of the three test types given in 5.3.2 is divided into seven classes, grouping tests:
 Class 1, valid frame format, includes the tests involving only error free data or remote frames;
 Class 2, error detection, includes the tests that corrupt data or remote frames, which are used to check
correct error detection by the IUT;
 Class 3, active error frame management, includes the tests verifying the IUT correct management of
error-free and of corrupted active error frames;
 Class 4, overload frame management, includes the tests verifying the IUT correct management of
error-free and of corrupted overload frames;
 Class 5, passive error state and bus-off, includes the tests verifying the IUT behaviour during passive
error state and bus-off state;
 Class 6, error counter management, includes the tests verifying the correct management of the TEC
and REC by the IUT in both active and passive error state;
 Class 7, bit timing, includes the tests verifying the correct management of bit timing by the IUT, and
shall be applied only to those components performing recessive to dominant edge synchronization — if
the dominant to recessive edge synchronization exists, it shall be disabled.
5.3.4 Test cases
Each and every basic entry of the test list is intended for checking a particular parameter of the harmonized
CAN specification in the IUT.
Each test case is specified by a number and a particular name in order to differentiate the test cases and to
easily summarize the goal of the test case. Some test cases may be subdivided into elementary tests that are
repetitions of the test case for several values of the parameter tested.
8 © ISO 2004 – All rights reserved

---------------------- Page: 12 ----------------------
ISO 16845:2004(E)
6 LT parameters
6.1 Overview
The CAN specification allows several IUT implementations. Consequently, the LT shall be provided with
parameters in order to indicate which kind of IUT is to be tested. These parameters are classified in two
categories:
 communication parameters, specifying which tests can be executed for the IUT, and which test method
shall be applied;
 application parameters, which specifies the features of the frames used for each test case selected
according to the previous parameters.
NOTE LT applies to IUT performing only recessive to dominant edge synchronization and operating in single
sampling mode.
6.2 Description of parameters
6.2.1 Communication parameters
6.2.1.1 Categories of communication parameter
Communication parameters are subdivided in three categories: implementation, timing and NDATA
parameters.
6.2.1.2 Implementation parameters
Implementation parameters dependant on the IUT shall be specified in order to allow the LT to fit on the IUT.
These implementation parameters are as follows.
a) CAN_VERSION indicates the version implemented in the IUT and may take three values.
A: IUT handes 11 bit identifiers.
B: IUT handles 11 and 29 bit identifiers.
BP: IUT handes 11 identifiers and tolerates 29 bit identifiers.
b) Open/specific, which indicates whether the IUT is open regarding the application layers or includes a
specific application, and may be of two types.
OPEN: open IUT allowing the test coordination procedure to be implemented in an UT.
These IUT shall be tested with the coordinated test method according to ISO 9646-1.
SPECIFIC: IUT that can be tested only with the help of a specific configuration procedure.
These IUT shall be tested with the remote test method according to ISO 9646-1.
6.2.1.3 Timing parameters
The LT also requires that some timing parameters be in accordance with the IUT and the UT characteristics.
These parameters are as follows.
a) Timeout indicates the minimum duration time for which the LT shall wait in order to respect the following
three conditions.
 The UT shall have enough time to put the IUT into the set-up state.
© ISO 2004 – All rights reserved 9

---------------------- Page: 13 ----------------------
ISO 16845:2004(E)
 The IUT shall have enough time to transmit a response frame after a remote frame.
 The LT shall consider an optional additional waiting time after the end of the minimum bus-off
recovery sequence before the IUT enters error active state again.
b) TSYS indicates the duration of the IUT system clock (clock used as input of the prescaler).
×
c) BRP indicates the value of the prescaler (the duration of a TQ is T = TSYS BRP).
Q
d) NTQ indicates the number of time quanta per bit.
e) Phase_Seg2 indicates the number of time quanta for the phase buffer segment 2.
f) SJW indicates the number of time quanta for the re-synchronization jump width. In all tests, the re-
synchronization jump width shall be programmed to its full range, up to its maximum value which is the
minimum of Phase_Seg1 and 4 TQ.
g) IPT indicates the information processing time.
h) IUT delay time shall be considered for bit timing class tests. It indicates the time difference between the
response of the IUT and the response of an ideal IUT (without internal delays) to an edge causing
synchronization. The IUT delay time is the sum of the IUT input and output delay time periods, measured
according to ISO 11898-2.
6.2.1.4 NDATA parameter, a set of DLC values which an IUT accepts for data exchange with higher
layers.
6.2.2 Application parameters
Except for tests for which a particular profile of application parameters is specified by the TP, the content of
the application parameters used during the test shall be chosen by the user.
7 Test type 1, received frame type
7.1 Test class 1, valid frame format
7.1.1 Identifier and number of data in standard format
7.1.1.1 Purpose and limits of test case
This test case is applicable to CAN_VERSION ∈ {A, B, BP}.
It is used to verify the behaviour of the IUT when receiving a correct data frame with different identifiers and
different numbers of data bytes in a standard format frame.
Tested identifiers: ∈ [000h, 7EFh] ∪ [7F0h, 7FFh],
Tested number of data bytes: ∈ [0, 8]
7.1.1.2 Test case organization
Test case organization shall be in accordance with Table 1.
10 © ISO 2004 – All rights reserved

---------------------- Page: 14 ----------------------
ISO 16845:2004(E)
Table 1 — Identifier and number of data in standard format — Test case organization
State Description
Set-up No action required, the IUT is left in the default state.
Test A single test frame is used for each elementary test.
The IUT shall not generate any error flag during the test.
Verification The IUT shall acknowledge the test frame.
The data received by the IUT during the test state shall match the data sent in the test frame.

7.1.2 Identifier and number of data in extended format — Test case 1
7.1.2.1 Purpose and limits of this test case
This test case is applicable to CAN_VERSION ∈ {B}.
It is used to verify the behaviour of the IUT when receiving a correct data frame with different identifiers and
different numbers of data bytes in a extended format frame.
Tested identifiers: ∈ [00000000, 1FFFFFFFh]
Tested number of data bytes: ∈ [0, 8]
7.1.2.2 Test case organization
Test case organization shall be as shown in Table 2.
Table 2 — Identifier and number of data in extended format — Test case 1 organization
State Description
Set-up No action required, the IUT is left in the default state.
Test A single test frame is used for each elementary test.
The IUT shall not generate any error flag during the test.
Verification The IUT shall acknowledge the test frame.
The data received by the IUT during the test state shall match the data sent in the test frame.

7.1.3 Identifier and number of data in extended format — Test case 2
7.1.3.1 Purpose and limits of this test case
This test is applicable to CAN_VERSION ∈ {BP}.
It is used to verify the behaviour of the IUT when receiving a correct data frame with different identifiers and
different numbers of data bytes in a extended format frame.
Tested identifiers: ∈ [00000000, 1FFFFFFFh]
Tested number of data bytes: ∈ [0, 8]
7.1.3.2 Test case organization
Test case organization shall be in accordance with Table 3.
© ISO 2004 – All rights reserved 11

---------------------- Page: 15 ----------------------
ISO 16845:2004(E)
Table 3 — Identifier and number of data in extended format — Test case 2 organization
State Description
Set-up No action required, the IUT is left in the default state.
Test A single test frame is used for each elementary test.
The IUT shall not generate any error flag during the test.
Verification
The IUT shall acknowledge the test frame.

7.1.4 Acceptance of non-nominal r1, r0 combination in standard format
7.1.4.1 Purpose and limits of this test case
This test is applicable to CAN_VERSION ∈ {A}.
Its purpose is to verify that the IUT accepts the non-nominal value of «r1, r0» bits in a valid standard frame.
Three (3) values shall be tested, as given in Table 4.
Table 4 — Values of r1 and r0 bits
r1 r0
1 1
1 0
0 1

7.1.4.2 Test case organization
Test case organization shall be in accordance with Table 5.
Table 5 — Acceptance of non-nominal r1, r0 combination in standard format — Test case organization
State Description
Set-up No action required, the IUT is left in the default state.
Test A single test frame is used for each of the three elementary tests.
The IUT shall not generate any error flag during the test.
Verification The IUT shall acknowledge the test frame.
The data received by the IUT during the test state shall match the data sent in the test frame.

7.1.5 Acceptance of non-nominal IDE, r0 combination in standard format
7.1.5.1 Purpose and limits of test case
This test is applicable to CAN_VERSION ∈ {B, BP}.
Its purpose is to verify that the IUT accepts the non-nominal value of the IDE and r0 bits in a valid standard
frame.
One (1) value shall be tested as specified in Table 6.
12 © ISO 2004 – All rights reserved

---------------------- Page: 16 ----------------------
ISO 16845:2004(E)
Table 6 — Non-nominal IDE
IDE r0
0 1

7.1.5.2 Test case organization
Test case organization shall be in accordance with Table 7.
Table 7 — Acceptance of non-nominal IDE, r0 combination in standard format —
Test case organization
State Description
Set-up No action required, the IUT
...

NORME ISO
INTERNATIONALE 16845
Première édition
2004-03-15


Véhicules routiers — Gestionnaire de
réseau de communication (CAN) — Plan
d'essai de conformité
Road vehicles — Controller area network (CAN) — Conformance test
plan




Numéro de référence
ISO 16845:2004(F)
©
ISO 2004

---------------------- Page: 1 ----------------------
ISO 16845:2004(F)
PDF – Exonération de responsabilité
Le présent fichier PDF peut contenir des polices de caractères intégrées. Conformément aux conditions de licence d'Adobe, ce fichier
peut être imprimé ou visualisé, mais ne doit pas être modifié à moins que l'ordinateur employé à cet effet ne bénéficie d'une licence
autorisant l'utilisation de ces polices et que celles-ci y soient installées. Lors du téléchargement de ce fichier, les parties concernées
acceptent de fait la responsabilité de ne pas enfreindre les conditions de licence d'Adobe. Le Secrétariat central de l'ISO décline toute
responsabilité en la matière.
Adobe est une marque déposée d'Adobe Systems Incorporated.
Les détails relatifs aux produits logiciels utilisés pour la création du présent fichier PDF sont disponibles dans la rubrique General Info
du fichier; les paramètres de création PDF ont été optimisés pour l'impression. Toutes les mesures ont été prises pour garantir
l'exploitation de ce fichier par les comités membres de l'ISO. Dans le cas peu probable où surviendrait un problème d'utilisation,
veuillez en informer le Secrétariat central à l'adresse donnée ci-dessous.


©  ISO 2004
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 [e-mail]
Web www.iso.org
Publié en Suisse

ii © ISO 2004 – Tous droits réservés

---------------------- Page: 2 ----------------------
ISO 16845:2004(F)
Sommaire Page
Avant-propos. iv
1 Domaine d'application. 1
2 Références normatives. 1
3 Termes et définitions . 1
4 Termes abrégés. 4
5 Généralités. 5
5.1 Architecture du plan d'essai (TP). 5
5.2 Organisation du TP . 7
5.3 Structure hiérarchique des essais . 8
6 Paramètres du LT. 9
6.1 Généralités. 9
6.2 Description des paramètres. 9
7 Type d’essai 1, de trame reçue. 11
7.1 Classe d’essai 1, de format de trame valide.11
7.2 Classe d'essai 2, de détection d'erreurs. 19
7.3 Classe d'essai 3, de gestion des trames d'erreur active . 24
7.4 Classe d'essai 4, de gestion des trames de surcharge. 26
7.5 Classe d'essai 5, d'état d'erreur passive et bus désactivé. 28
7.6 Classe d'essai 6, de gestion des compteurs d'erreurs . 32
7.7 Classe d'essai 7, de synchronisation des bits. 41
8 Type d’essai 2, de trame transmise . 46
8.1 Classe d’essai 1, de format de trame valide.46
8.2 Classe d’essai 2, de détection d'erreurs. 51
8.3 Classe d’essai 3, de gestion des trames d'erreur active . 54
8.4 Classe d’essai 4, de gestion des trames de surcharge . 56
8.5 Classe d’essai 5, d'état d'erreur passive et bus désactivé. 59
8.6 Classe d’essai 6, de gestion des compteurs d'erreurs. 66
8.7 Classe d’essai 7, de synchronisation des bits . 76
9 Type d’essai 3, de trame bidirectionnelle. 81
9.1 Classe d’essai 1, de format de trame valide.81
9.2 Classe d’essai 2, de détection d'erreurs. 81
9.3 Classe d’essai 3, de gestion des trames d'erreur active . 81
9.4 Classe d’essai 4, de gestion des trames de surcharge . 81
9.5 Classe d’essai 5, d'état d'erreur passive et bus désactivé. 81
9.6 Classe d’essai 6, de gestion des compteurs d'erreurs. 81
9.7 Classe d’essai 7, de synchronisation des bits . 82

© ISO 2004 – Tous droits réservés iii

---------------------- Page: 3 ----------------------
ISO 16845:2004(F)
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'attention est appelé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.
L'ISO 16845 a été élaborée par le comité technique ISO/TC 22, Véhicules routiers, sous-comité SC 3,
Équipement électrique et électronique.
iv © ISO 2004 – Tous droits réservés

---------------------- Page: 4 ----------------------
NORME INTERNATIONALE ISO 16845:2004(F)

Véhicules routiers — Gestionnaire de réseau de communication
(CAN) — Plan d'essai de conformité
1 Domaine d'application
La présente Norme internationale spécifie la méthodologie et la suite d'essais nécessaires à la vérification de
la conformité de toute réalisation CAN aux spécifications CAN de l’ISO 11898-1.
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/CEI 9646-1:1994, Technologies de l'information — Interconnexion de systèmes ouverts (OSI) — Cadre
général et méthodologie des tests de conformité — Partie 1: Concepts généraux
ISO 11898-1:2003, Véhicules routiers — Gestionnaire de réseau de communication (CAN) — Partie 1:
Couche liaison de données et signalisation physique
ISO 11898-2:2003, Véhicules routiers — Gestionnaire de réseau de communication (CAN) — Partie 2: Unité
d'accès au support à haute vitesse
3 Termes et définitions
Pour les besoins du présent document, les termes et définitions suivants s'appliquent.
3.1
délimiteur ACK
deuxième bit du champ ACK
3.2
champ ACK
dernier champ avant l'EOF, utilisé pour la validation du message
3.3
erreur d'accusé de réception
condition d'erreur du transmetteur lorsqu'il ne détecte pas de bit dominant sur le créneau temporel ACK
3.4
créneau temporel ACK
premier bit du champ ACK
3.5
indicateur d'erreur active
premier champ d'une trame d'erreur active
© ISO 2004 – Tous droits réservés 1

---------------------- Page: 5 ----------------------
ISO 16845:2004(F)
3.6
trame d'erreur active
trame d'erreur commençant par un indicateur d'erreur active (dominant)
3.7
état actif
état d’un nœud qui peut transmettre une trame d'erreur active
3.8
champ arbitrage
champ commençant après le bit SOF et se terminant par le bit RTR
3.9
erreur de bit
condition d'erreur rencontrée lorsque le bit reçu ne correspond pas au bit transmis ou au bit attendu
3.10
essai de conformité
application du plan d'essai à une IUT
3.11
délimiteur CRC
dernier bit du champ CRC
3.12
erreur CRC
condition d'erreur d'un récepteur lorsque le code CRC reçu ne correspond pas au code CRC calculé
3.13
champ CRC
champ qui précède le champ ACK et qui est formé par le code CRC et le délimiteur CRC
3.14
fin de trame
dernier champ d'une trame de données ou d'une trame distante avant le champ intermission
3.15
délimiteur d'erreur
deuxième champ d'une trame d'erreur
3.16
indicateur d'erreur
premier champ d'une trame d'erreur
3.17
trame d'erreur
séquence formatée de bits indiquant une condition d'erreur
3.18
erreur de format
condition d'erreur présente dans un champ à format prédéfini
3.19
état de repos
état du bus CAN lorsque aucune trame ne commence après le champ intermission
3.20
champ intermission
champ qui suit l'EOF, le délimiteur d'erreur ou le délimiteur de surcharge
2 © ISO 2004 – Tous droits réservés

---------------------- Page: 6 ----------------------
ISO 16845:2004(F)
3.21
testeur inférieur
testeur qui supervise la suite d'essais
3.22
délimiteur de surcharge
deuxième champ d'une trame de surcharge
3.23
indicateur de surcharge
premier champ d'une trame de surcharge
3.24
trame de surcharge
séquence formatée de bits indiquant une condition de surcharge
3.25
indicateur d'erreur passive
première partie d'une trame d'erreur passive
3.26
état passif
état d’un dispositif lorsque la valeur du REC ou du TEC a atteint la limite du passif d'erreur
3.27
état passif du REC
état d’un dispositif lorsque la valeur du REC a atteint la limite du passif d'erreur
3.28
état récessif
état d’un bus CAN lorsque aucun nœud du CAN ne contrôle une valeur dominante sur la ligne
3.29
bit de bourrage
bit spécifique inséré dans le flux de bits pour augmenter le nombre de fronts dans un but de synchronisation
3.30
erreur de bourrage
condition d'erreur rencontrée lorsqu'il manque un bit de bourrage attendu
3.31
champ suspendre la transmission
temps d'attente ajouté après le champ intermission d'un transmetteur en passif d'erreur avant qu'il puisse
commencer une autre transmission
3.32
état passif du TEC
état d’un dispositif lorsque la valeur du TEC a atteint la limite du passif d'erreur
3.33
cas d'essai
essai défini par un numéro et par un nom spécifiques dans la suite d’essais
3.34
trame d'essai
trame du CAN contenant le modèle d'essai spécifié
© ISO 2004 – Tous droits réservés 3

---------------------- Page: 7 ----------------------
ISO 16845:2004(F)
3.35
suite d'essais
suite des essais réalisés permettant de vérifier le comportement de l'IUT pour des paramètres particuliers de
la spécification CAN
3.36
type d'essais
spécification de la direction des trames d'essai
EXEMPLE Spécification du comportement de l'IUT quand elle reçoit et/ou transmet des messages.
3.37
quantum de temps
durée élémentaire du débit binaire du CAN dérivée de l'horloge oscillateur et du précalibreur
3.38
testeur supérieur
testeur qui agit comme un utilisateur de l'IUT
4 Termes abrégés
ACK accusé de réception (Acknowledgment)
BRP précalibreur de taux de bits (Bit rate prescaler)
CAN gestionnaire de réseau de communication (Controller area network)
CRC contrôle de redondance cyclique (Cyclic redundancy check)
CTRL commande (Control)
DLC code de longueur de données (Data length code)
EOF fin de trame (End of frame)
IDE bit d’extension identifiant (Identifier extension bit)
IDEN identifiant CAN (CAN identifier)
IPT temps de traitement des informations (Information processing time)
IUT réalisation soumise à l’essai (Implementation under test)
LLC contrôle de liaison logique (Logical link control)
LME entité de gestion de couches (Layer management entity)
LT testeur inférieur (Lower tester)
MAC commande d'accès à une couche (Medium access control)
MDI interface dépendante du support (Medium dependent interface)
NDATA données du réseau (Network data)
NTQ nombre de quanta de temps (Number of time quanta)
PCO point de contrôle et d'observation (Point of control and observation)
4 © ISO 2004 – Tous droits réservés

---------------------- Page: 8 ----------------------
ISO 16845:2004(F)
PLS signalisation de couche physique (Physical layer signalling)
PMA raccordement du support physique (Physical medium attachment)
REC compteur d'erreurs de réception (Receive error counter)
RTR demande de transmission distante (Remote transmission request)
RX signal du récepteur (Receiver signal)
SJW largeur du saut de nouvelle synchronisation (Re-synchronisation jump width)
SLIO entrée/sortie série liée (Serial linked input/output)
SOF début de trame (Start of frame)
SRR demande distante de remplacement (Substitute remote request)
TEC compteur d'erreurs de transmission (Transmit error counter)
TP plan d'essai (Test plan)
TQ quanta de temps (Time quanta)
TSYS durée de l'horloge système de l'IUT (System clock time)
UT testeur supérieur (Upper tester)
5 Généralités
5.1 Architecture du plan d'essai (TP)
L'architecture du TP est indiquée à la Figure 1.
Le TP est une application spécifique de l’ISO 9646-1 limitée au mode d'essai de partie unique. Dans la
mesure où la frontière de service supérieure d'une réalisation CAN n'est pas normalisée et peut, dans certains
cas, ne pas être observée ni contrôlée en raison d'un comportement spécifique de l'application intégrée dans
ladite réalisation (par exemple une SLIO du CAN) le TP doit utiliser soit la «méthode d’essai coordonnée»,
soit la «méthode d’essai distante».
En fonction de la méthode d'essai appliquée, le TP doit comprendre jusqu'à trois fonctions d'essai:
 un LT dont le fonctionnement est très semblable à celui de la réalisation CAN soumise à l’essai (IUT); il
exécute la suite d'essais et rend un verdict pour l'essai;
 un UT agissant comme utilisateur de l'IUT (dépendant de l'IUT);
 un protocole de gestion de l'essai entre l'IUT et le LT, consistant en des procédures de coordination des
essais.
Les deux dernières fonctions ne sont applicables qu'à la méthode d'essai coordonnée.
Au cours de l'exécution de l'essai, le LT peut observer et contrôler la frontière de service inférieur normalisée
de l'IUT (PCO) par l'intermédiaire des deux procédures de base de service fournies par la sous-couche de
signalisation physique du CAN, à savoir, PLS-Data.indicate (indication de données) et PLS-Data.request
(demande de données), dans la plupart des cas.
L'environnement qui met en œuvre le TP est décrit à la Figure 2.
© ISO 2004 – Tous droits réservés 5

---------------------- Page: 9 ----------------------
ISO 16845:2004(F)
À l'aide de l'interface du réseau, le LT indique à l'UT les actions à accomplir et l'UT fournit au LT les
informations concernant le comportement interne de l'IUT.
Pour permettre les communications entre le LT et l'UT, il est nécessaire de spécifier certaines procédures de
coordination d'essai entre eux. Ces procédures utilisent le réseau à l'exclusion de toute autre liaison physique.
Elles servent à configurer l'UT et à vérifier les résultats de l'essai.

Figure 1 — Architecture du plan d'essai

Figure 2 — Environnement du TP de conformité
6 © ISO 2004 – Tous droits réservés

---------------------- Page: 10 ----------------------
ISO 16845:2004(F)
5.2 Organisation du TP
5.2.1 Organisation générale
Le LT vérifie si l'IUT est conforme aux sous-couches MAC, LLC et PLS de la spécification CAN. Le LT révèle
les différences entre ce qui est attendu en fonction de la spécification et le comportement réel de l'IUT.
Les suites d'essais du TP sont indépendantes les unes des autres. Chaque suite d'essais vérifie le
comportement de l'IUT en fonction d'un paramètre particulier de la spécification CAN. Les cas d'essai peuvent
être exécutés les uns après les autres dans n'importe quel ordre ou individuellement.
Les cas d'essai qui demandent la variation de paramètres individuels (identifiant, nombre de données, etc.)
doivent être répétés pour chaque valeur du paramètre. Chaque répétition est appelée essai élémentaire. Un
cas d'essai incluant différents essais élémentaires n'est valide que si tous les essais réussissent.
5.2.2 Organisation des cas d'essai
5.2.2.1 Essais élémentaires
5.2.2.1.1 Description
Chaque essai élémentaire se compose de trois états:
 état de configuration;
 état d'essai;
 état de vérification.
Au PCO, ces états mettent en jeu des échanges de séquences valides de procédures de base de services
PLS [trame(s) CAN] ou de séquences invalides de procédures de base PLS (trames CAN invalides ou bruit).
Avant de commencer le premier essai élémentaire, l'IUT doit être initialisée dans l'état par défaut.
5.2.2.1.2 État de configuration
L'état de configuration est l'état dans lequel doit se trouver l'IUT avant d'entrer dans l'état d'essai.
5.2.2.1.3 État d'essai
C'est la partie de l'essai élémentaire pendant laquelle la caractéristique du protocole ou le paramètre sont
effectivement vérifiés. Cet état nécessite un ou plusieurs échanges ou trames. Ces trames sont appelées
trames d'essai.
5.2.2.1.4 État de vérification
L'état de vérification se compose des trames de lecture des données qui vérifient que les données ont été
traitées conformément à la spécification CAN.
Pour les essais appartenant aux classes d'essai 1 à 6, conformes à 5.3.3, le LT doit être capable de détecter
la valeur correcte du bit.
Pour les essais de synchronisation de bit (classe 7, conforme à 5.3.3), le LT doit être capable de détecter une
synchronisation défectueuse d'un TQ.
© ISO 2004 – Tous droits réservés 7

---------------------- Page: 11 ----------------------
ISO 16845:2004(F)
5.2.2.2 État par défaut
L'état par défaut est caractérisé par les valeurs par défaut suivantes:
 le REC et le TEC doivent être tous les deux égaux à 0;
 il ne doit pas y avoir de transmission en attente;
 l'IUT doit être dans l'état de repos;
 PLS-Data.indicate et PLS-Data.request doivent être récessives.
L'état par défaut doit être appliqué après la fin de chaque essai élémentaire.
5.3 Structure hiérarchique des essais
5.3.1 Généralités
Tous les essais définis dans le TP sont groupés en catégories pour faciliter la planification, le développement,
la compréhension et l'exécution de chaque essai. Il existe trois niveaux de catégories: les types d'essais, les
classes d'essais et les cas d'essais.
5.3.2 Types d'essais
Les types d'essai définissent la direction des trames. Il existe trois types d'essais:
 Type 1, de trame reçue: inclut tous les essais évaluant le comportement de l'IUT pour les trames de
données et les trames distantes reçues par l'IUT. Voir l'Article 7.
 Type 2, de trame transmise: inclut tous les essais évaluant le comportement de l'IUT pour les trames de
données et les trames distantes transmises par l'IUT. Voir l'Article 8.
 Type 3, de trame bidirectionnelle: inclut tous les essais avec des trames de données et des trames
distantes soit reçues, soit transmises par l'IUT. Voir l'Article 9.
5.3.3 Classes d'essais
Chacun des trois types d'essais spécifiés en 5.3.2 est subdivisé en les sept classes d’essais suivantes qui
regroupent les essais.
 Classe 1, de format de trame valide: inclut les essais qui ne concernent que des trames de données ou
des trames distantes ne comportant pas d'erreur.
 Classe 2, de détection d'erreurs: inclut les essais qui corrompent les trames de données ou les trames
distantes. Ces essais vérifient que l'IUT détecte correctement les erreurs.
 Classe 3, de gestion des trames d'erreur active: inclut les essais vérifiant que l'IUT gère correctement
les trames d'erreur active sans erreur et corrompues.
 Classe 4, de gestion des trames de surcharge: inclut les essais vérifiant que l'IUT gère correctement
les trames de surcharge sans erreur et corrompues.
 Classe 5, d'état d'erreur passive et bus désactivé: inclut les essais vérifiant le comportement de l'IUT
dans un état d'erreur passive et de bus désactivé.
 Classe 6, de gestion des compteurs d'erreurs: inclut les essais vérifiant la gestion correcte du TEC et
du REC par l'IUT dans l'état d'erreur active et dans l'état d'erreur passive.
8 © ISO 2004 – Tous droits réservés

---------------------- Page: 12 ----------------------
ISO 16845:2004(F)
 Classe 7, de synchronisation des bits: inclut les essais vérifiant que l'IUT gère correctement la
synchronisation des bits. Cette classe d'essais ne doit être appliquée qu'aux composants qui n'effectuent
qu'une synchronisation par front passant de récessif à dominant (si la synchronisation par front passant
de dominant à récessif existe, elle doit être désactivée).
5.3.4 Cas d'essais
Toute rubrique individuelle de la liste d'essais est destinée à vérifier un paramètre particulier de la
spécification CAN harmonisée dans l'IUT.
Chaque cas d'essai est défini par un numéro spécifique et par un nom particulier permettant de les
différencier et de résumer facilement leur objectif. Certains cas d'essais peuvent être subdivisés en essais
élémentaires qui consistent en des répétitions du cas d'essai avec plusieurs valeurs du paramètre à vérifier.
6 Paramètres du LT
6.1 Généralités
La spécification CAN permet plusieurs réalisations de l'IUT. Par conséquent, l'utilisateur doit fournir au LT les
paramètres qui indiquent quelle sorte d'IUT va être soumise à l’essai. Ces paramètres peuvent être classés
en les deux catégories suivantes.
 Paramètres de communication: ils spécifient quels essais peuvent être exécutés pour l'IUT et quelle
méthode d'essai doit être appliquée.
 Paramètres d'application: ils spécifient les caractéristiques des trames utilisées pour chaque cas
d'essai sélectionné en fonction des paramètres de communication.
NOTE Le LT s'applique aux IUT qui effectuent uniquement une synchronisation par front passant de récessif à
dominant et qui fonctionnent en mode d'échantillonnage simple.
6.2 Description des paramètres
6.2.1 Paramètres de communication
6.2.1.1 Catégories des paramètres de communication
Les paramètres de communication sont subdivisés en trois catégories: paramètres de la réalisation,
paramètres de synchronisation et paramètres NDATA.
6.2.1.2 Paramètres de la réalisation
Certains paramètres dépendant de l'IUT doivent être spécifiés par l'utilisateur pour permettre au LT de
s'adapter à l'IUT. Ces paramètres sont les suivants.
a) CAN_VERSION (version du CAN): indique la version installée dans l'IUT. Ce paramètre peut prendre
les trois valeurs suivantes.
A: l'IUT accepte les identifiants à 11 bits.
B: l'IUT accepte les identifiants à 11 et 29 bits.
BP: l'IUT accepte les identifiants à 11 bits et tolère les identifiants à 29 bits.
b) open/specific (ouvert/spécifique): indique si l'IUT est ouverte en ce qui concerne les couches
d'application ou si elle inclut une application spécifique. Ce paramètre peut prendre les deux valeurs
suivantes.
© ISO 2004 – Tous droits réservés 9

---------------------- Page: 13 ----------------------
ISO 16845:2004(F)
OPEN (ouvert): l’IUT est ouverte, permettant la réalisation de la procédure de coordination
des essais dans un UT.
Ces IUT doivent être vérifiées selon la méthode d’essai coordonnée de
l’ISO 9646-1.
SPECIFIC (spécifique): l'IUT ne peut être vérifiée qu'à l'aide d'une procédure de configuration
spécifique.
Ces IUT doivent être vérifiées selon la méthode d’essai distante de
l’ISO 9646-1.
6.2.1.3 Paramètres de synchronisation
Le LT a également besoin que certains paramètres de synchronisation s'accordent à l'IUT et aux
caractéristiques de l'UT. Ces paramètres sont les suivants.
a) Timeout (temps imparti): indique la durée minimale pendant laquelle le LT doit attendre pour respecter
les trois conditions suivantes.
 L'UT doit disposer de suffisamment de temps pour mettre l'IUT dans l'état de configuration.
 L’IUT doit disposer de suffisamment de temps pour transmettre une trame de réponse après une
trame distante.
 Le LT doit envisager une durée d'attente supplémentaire optionnelle après la fin de la séquence
minimale de récupération de bus désactivé avant que l'IUT n'entre de nouveau dans l'état actif
d'erreur.
b) TSYS: indique la durée de l'horloge système de l'IUT (horloge utilisée comme entrée du précalibreur).
c) BRP: indique la valeur du précalibreur (la durée d'un TQ est T = TSYS × BRP).
Q
d) NTQ: indique le nombre de quanta de temps par bit.
e) Phase_Seg2: indique le nombre de quanta de temps pour la phase «segment tampon 2».
f) SJW: indique le nombre de quanta de temps pour la largeur du saut de nouvelle synchronisation. Dans
tous les essais, la largeur du saut de nouvelle synchronisation doit être programmée pour toute son
étendue, jusqu'à sa valeur maximale qui est le minimum de Phase_Seg1 et de 4 T .
Q
g) IPT: indique le temps de traitement des informations.
h) Temps d’attente de l’IUT: ce paramètre doit être pris en compte lors des essais de la classe de
synchronisation des bits. Il indique la différence de temps entre la réponse de l’IUT et la réponse d’une
IUT idéale (sans temps d’attente internes) à un front générant une synchronisation. Le temps d’attente de
l’IUT est la somme du temps d’attente en entrée de l’IUT et du temps d’attente en sortie de l’IUT, il est
mesuré conformément à l'ISO 11898-2.
6.2.1.4 Paramètre NDATA
Ce paramètre est un ensemble de valeurs de DLC acceptées par une IUT pour les échanges de données
avec les couches supérieures.
6.2.2 Les paramètres d'application
À l'exception des cas d'essai pour lesquels un profil particulier de paramètres d’application est défini par le TP,
le contenu des paramètres d’application utilisés pendant les cas d'essai doit être choisi par l'utilisateur.
10 © ISO 2004 – Tous droits réservés

---------------------- Page: 14 ----------------------
ISO 16845:2004(F)
7 Type d’essai 1, de trame reçue
7.1 Classe d’essai 1, de format de trame valide
7.1.1 Identifiant et nombre d’octets de données en format standard
7.1.1.1 Objectif et limites du cas d’essai
Ce cas d’essai est applicable à CAN_VERSION ∈ {A, B, BP}.
Il vérifie le comportement de l'IUT lorsqu'elle reçoit une trame de données correcte avec des identifiants
différents et des nombres d'octets de données différents dans une trame de format standard.
Identifiants vérifiés: ∈ [000h, 7EFh] ∪ [7F0h, 7FFh]
Nombre d'octets de données vérifiés: ∈ [0, 8]
7.1.1.2 Organisation du cas d'essai
L’organisation du cas d'essai doit être conforme au Tableau 1.
Tableau 1 — Identifiant et nombre d’octets de données en format standard —
Organisation du cas d'essai
État Description
Configuration Aucune action requise, l'IUT est laissée dans l'état par défaut.
Essai Une trame d'essai unique est utilisée pour chaqu
...