IEC 61375-2:2007

INTERNATIONAL IEC
STANDARD 61375-2
First edition
2007-04
Electric railway equipment –
Train bus –
Part 2:
Train communication network conformance testing
Reference number
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 IEC or IEC's member National Committee in the country of the requester.
If you have any questions about IEC copyright or have an enquiry about obtaining additional rights to this publication,
please contact the address below or your local IEC member National Committee for further information.

IEC Central Office
3, rue de Varembé
CH-1211 Geneva 20
Switzerland
Email: inmail@iec.ch
Web: www.iec.ch
About the IEC
The International Electrotechnical Commission (IEC) is the leading global organization that prepares and publishes
International Standards for all electrical, electronic and related technologies.

About IEC publications
The technical content of IEC publications is kept under constant review by the IEC. Please make sure that you have the
latest edition, a corrigenda or an amendment might have been published.
ƒ Catalogue of IEC publications: www.iec.ch/searchpub
The IEC on-line Catalogue enables you to search by a variety of criteria (reference number, text, technical committee,…).
It also gives information on projects, withdrawn and replaced publications.
ƒ IEC Just Published: www.iec.ch/online_news/justpub
Stay up to date on all new IEC publications. Just Published details twice a month all new publications released. Available
on-line and also by email.
ƒ Customer Service Centre: www.iec.ch/webstore/custserv
If you wish to give us your feedback on this publication or need further assistance, please visit the Customer Service
Centre FAQ or contact us:
Email: csc@iec.ch
Tel.: +41 22 919 02 11
Fax: +41 22 919 03 00
INTERNATIONAL IEC
STANDARD 61375-2
First edition
2007-04
Electric railway equipment –
Train bus –
Part 2:
Train communication network conformance testing

PRICE CODE
Commission Electrotechnique Internationale XH
International Electrotechnical Commission
МеждународнаяЭлектротехническаяКомиссия
For price, see current catalogue

– 2 – 61375-2 © IEC:2007(E)
CONTENTS
FOREWORD.6
INTRODUCTION.8

1 General .10
1.1 Scope.10
1.2 Normative references .10
1.3 Terms and definitions .10
2 Conformance test: approach, requirements and boundaries.10
2.1 The approach .10
2.2 Boundaries .14
2.3 Conformance assessment process outline.19
3 Conformance test of an MVB device .20
3.1 PICS .20
3.2 Test suites .31
4 Conformance test of a WTB node, WTB trunk cable, WTB jumper cables, WTB
extension cables.94
4.1 PICS .94
5 Conformance test of RTP .135
5.1 Ports and Traffic_Store .136
5.2 Dataset consistency .136
5.3 Port_Address .137
5.4 Link_Process_Data_Interface primitives .138
5.5 Messages services and protocols .138
6 Conformance test of a WTB-equipped vehicle .138
6.1 General .138
6.2 PICS .138
6.3 Test suites .141
6.4 MVB interoperability test .152
6.5 Application profile.152
6.6 Several nodes on the vehicle.152
7 Conformance test of NM .152

Annex A (normative)  Test laboratory role and client role .153
Annex B (informative)  Test instrumentation and dedicated test bed .160

Bibliography.169

Figure 1 – Application of the waveshaper.32
Figure 2 – ESD test layout .34
Figure 3 – ESD backplane section (double-line).35
Figure 4 – ESD connector arrangement .37
Figure 5 – ESD terminator connector test .38
Figure 6 – ESD waveform measurement .39
Figure 7 – Frame (ESD).40

61375-2 © IEC:2007(E) – 3 –
Figure 8 – Measurement of insertion loss.42
Figure 9 – EMD transmitter heavy load circuit .42
Figure 10 – EMD transmitter light test circuit.43
Figure 11 – Example of pulse waveform at EMD transmitter.44
Figure 12 – EMD transmitter idling test circuit .45
Figure 13 – Signal with end delimiter .45
Figure 14 – Example of end delimiter for EMD medium .45
Figure 15 – Example of test hardware implementation .56
Figure 16 – F_code + Address .60
Figure 17 – Concept of message data testing .67
Figure 18 – Model of the relation between TE and IUT for message data testing.67
Figure 19 – Relation between TE and IUT in case of test of IUT as caller .68
Figure 20 – Packet formats (transport layer body).69
Figure 21 – Test message task of IUT.70
Figure 22 – Caller timeout identification .73
Figure 23 – Nesting address with 0x83 .79
Figure 24 – Block diagram of a line.85
Figure 25 – Frames in test RP-1.2 .86
Figure 26 – Inter-frame spacing .86
Figure 27 – Pulse distortion .88
Figure 28 – Frame with out-of-place transition .88
Figure 29 – Frames in test RP-1.4 .89
Figure 30 – Insertion loss measurement.104
Figure 31 – Measurement of the input resistance .105
Figure 32 – End setting measurement setup 1 .105
Figure 33 – End setting measurement setup 2 .106
Figure 34 – Switches measurement setup 1 .107
Figure 35 – Direct attachment switches measurements Fixture 1 .107
Figure 36 – Indirect attachment switches measurements Fixture 1.108
Figure 37 – Transmitter fixtures .109
Figure 38 – Transmitter output signal.110
Figure 39 – Intermediate transmitted noise test fixture .110
Figure 40 – End node transmitted noise test fixture.111
Figure 41 – Signal and idling at transmitter .112
Figure 42 – RF resistor example .113
Figure 43 – Short-circuit test Fixture 1 .113
Figure 44 – Receiver signal envelope .115
Figure 45 – Receiver edge distortion.116
Figure 46 – Example of relay switch logic diagram for line A.119
Figure 47 – WTB orientation .122
Figure 48 – Line switch identification in position P01 .123
Figure 49 – Line switch identification in position P10 .123
Figure 50 – Line switch identification in position P32 .123

– 4 – 61375-2 © IEC:2007(E)
Figure 51 – Test suite identifier TTS1 .124
Figure 52 – Test suite identifier TTS2 .125
Figure 53 – Test suite identifier TTS3 .126
Figure 54 – Line resistance.143
Figure 55 – Crosstalk.144
Figure 56 – Propagation delay and attenuation .145
Figure 57 – Coach tester nodes .150
Figure B.1 – Hardware test bed architecture .161
Figure B.2 – Test bed configuration MRTB1.162
Figure B.3 – Test bed configuration MRTB2.162
Figure B.4 – Coach tester architecture.163
Figure B.5 – Configuration of the coach tester .167
Figure B.6 – WTB line redundancy switch-over .168

Table 1 – Document structure .9
Table 2 – Continuance indication .17
Table 3 – Weak statements.18
Table 4 – Relation to interoperability.19
Table 5 – Relation to performance test .19
Table 6 – ESD basic interconnection tests .33
Table 7 – EMD basic interconnection tests.33
Table 8 – Measurement idle.35
Table 9 – Measurement with load for minimum current.36
Table 10 – Measurement with load for maximum current.36
Table 11 – Measurement with load for overcurrent.36
Table 12 – Pin assignment for the ESD connector .37
Table 13 – ESD measurements pin to pin .38
Table 14 – Event poll strategy.71
Table 15 – Abbreviations .75
Table 16 – Addressing type.76
Table 17 – Test function directory.78
Table 18 – Test station directory.78
Table 19 – Nesting address .79
Table 20 – Read_Memory and Write_Memory sequence.81
Table 21 – Configuration of periodic data in BA .91
Table 22 – Configuration of periodic ports in CU-1 .92
Table 23 – Configuration of periodic ports in CU-2 .93
Table 24 – WTB pin to pin measurement.108
Table 25 – Fault tolerance parameters.112
Table 26 – Frequency sinusoidal signal .117
Table 27 – WTB devices configuration .120
Table 28 – TNM agent services.121

61375-2 © IEC:2007(E) – 5 –
Table 29 – Test suite .123

– 6 – 61375-2 © IEC:2007(E)
INTERNATIONAL ELECTROTECHNICAL COMMISSION
____________
ELECTRIC RAILWAY EQUIPMENT –
TRAIN BUS –
Part 2: Train communication network conformance testing

FOREWORD
1) The International Electrotechnical Commission (IEC) is a worldwide organization for standardization comprising
all national electrotechnical committees (IEC National Committees). The object of IEC is to promote international
co-operation on all questions concerning standardization in the electrical and electronic fields. To this end and
in addition to other activities, IEC publishes International Standards, Technical Specifications, Technical
Reports, Publicly Available Specifications (PAS) and Guides (hereafter referred to as “IEC Publication(s)”). Their
preparation is entrusted to technical committees; any IEC National Committee interested in the subject dealt
with may participate in this preparatory work. International, governmental and non-governmental organizations
liaising with the IEC also participate in this preparation. IEC collaborates closely with the International
Organization for Standardization (ISO) in accordance with conditions determined by agreement between the two
organizations.
2) The formal decisions or agreements of IEC on technical matters express, as nearly as possible, an international
consensus of opinion on the relevant subjects since each technical committee has representation from all
interested IEC National Committees.
3) IEC Publications have the form of recommendations for international use and are accepted by IEC National
Committees in that sense. While all reasonable efforts are made to ensure that the technical content of IEC
Publications is accurate, IEC cannot be held responsible for the way in which they are used or for any
misinterpretation by any end user.
4) In order to promote international uniformity, IEC National Committees undertake to apply IEC Publications
transparently to the maximum extent possible in their national and regional publications. Any divergence
between any IEC Publication and the corresponding national or regional publication shall be clearly indicated in
the latter.
5) IEC provides no marking procedure to indicate its approval and cannot be rendered responsible for any
equipment declared to be in conformity with an IEC Publication.
6) All users should ensure that they have the latest edition of this publication.
7) No liability shall attach to IEC or its directors, employees, servants or agents including individual experts and
members of its technical committees and IEC National Committees for any personal injury, property damage or
other damage of any nature whatsoever, whether direct or indirect, or for costs (including legal fees) and
expenses arising out of the publication, use of, or reliance upon, this IEC Publication or any other IEC
Publications.
8) Attention is drawn to the Normative references cited in this publication. Use of the referenced publications is
indispensable for the correct application of this publication.
9) Attention is drawn to the possibility that some of the elements of this IEC Publication may be the subject of
patent rights. IEC shall not be held responsible for identifying any or all such patent rights.
International Standard IEC 61375-2 has been prepared by IEC technical committee 9:
Electrical equipment and systems for railways.
This standard is to be read in conjunction with IEC 61375-1, second edition.
The text of this standard is based on the following documents:
FDIS Report on voting
9/1014/FDIS 9/1034/RVD
Full information on the voting for the approval of this standard can be found in the report on
voting indicated in the above table.
This publication has been drafted in accordance with the ISO/IEC Directives, Part 2.

61375-2 © IEC:2007(E) – 7 –
A list of all parts of IEC 61375 series, published under the general title Electric railway
equipment – Train bus can be found on the IEC website.
The committee has decided that the contents of this publication will remain unchanged until
the maintenance result date indicated on the IEC web site under "http://webstore.iec.ch" in the
data related to the specific publication. At this date, the publication will be
• reconfirmed,
• withdrawn,
• replaced by a revised edition, or
• amended.
Following the decision of the committee, some parts of the text and some figures of this
publication are copied from the IEC 61375-1 for keeping the maximum of clarity.
A bilingual version of this standard may be issued at a later date.

– 8 – 61375-2 © IEC:2007(E)
INTRODUCTION
TCN is an International Standard with the aim of defining interfaces so as to achieve plug-in
compatibility:
a) between equipment located in different vehicles, and
b) between equipment and devices located within the same vehicle.
One of the key success factors for deployment of any technology is the standardisation and
the ensuring interoperability among various implementations. To facilitate interoperability a
conformance test should be implemented.
In this part of IEC 61375, the TCN hierarchical structure deals with two levels of busses:
a) the train bus called the Wire Train Bus (WTB);
b) the vehicle bus called the Multifunction Vehicle Bus (MVB).
No other busses are taken into consideration even though they are foreseen by IEC 61375-1,
see the note below.
WTB and MVB share the same real-time protocols, which offer two communication services:
a) process variables, a distributed, real-time database, periodically refreshed through
broadcasting;
b) messages, transmitted on demand either as:
0. unicast messages (point-to-point) or/and
1. multicast messages.
WTB and MVB share a common network management, which allows debugging,
commissioning and maintenance over the network.
NOTE TCN states that several vehicle busses may apply, provided that such busses are able to provide the
services of Real_Time Protocols. However, this part of IEC 61375 is focused on MVB as vehicle bus, even if the
conformance test may apply to other busses, the exact conformance test should be derived upon.
This standard is structured into 7 clauses and 2 annexes.
The clauses and annexes are listed and briefly described in the Table 1.

61375-2 © IEC:2007(E) – 9 –
Table 1 – Document structure
Clause/sections Description
1. General This clause describes the scope of this standard and
introduces basic terms and abbreviations not reported in
IEC 61375-1.
2. Conformance test: approach, This clause is an overview of the methods of TCN
requirements and boundaries implementation verification that are available to the
developer and regulatory personnel.
Supplies information concerning the ICS and IXITpPro-
forma(s).
3. Conformance test of an MVB device This clause covers all tests on MVB devices that are
grouped by classes, from Class 0 up to Class 4. The main
contents are:
the MVB PICS and PIXIT;
the MVB test suites;
the MVB test procedures.
4. Conformance test of a WTB device Contents: All tests on WTB are classified by nodes related
to WTB itself and MVB only. The main contents are:
the WTB PICS and PIXIT;
the WTB test suites;
the WTB test procedures.
5 Conformance test of RTP This clause lists the tests covered in Clauses 3 and 4
fulfilling the real time protocol.
6. Conformance test of a WTB- This clause covers the Physical Layer while the Services
equipped vehicle given by the WTB node are covered by the previous
clauses. Application profiles are covered by other bodies,
like UIC for profile UIC 556.
7 Conformance test of NM Partially covered by Clauses 3 and 4. Remaining parts are
not covered.
Annex A – Test laboratory role and This annex is normative.
client role
Annex B – Test instrumentation and This annex is informative.
dedicated test bed
– 10 – 61375-2 © IEC:2007(E)
ELECTRIC RAILWAY EQUIPMENT –
TRAIN BUS –
Part 2: Train communication network conformance testing

1 General
1.1 Scope
This part of IEC 61375 applies to all equipment and devices implemented according to
IEC 61375-1, i.e. it covers the procedures to be applied to such equipment and devices when
the conformance should be proven.
The applicability of this standard to a TCN implementation allows for individual conformance
checking of the implementation itself and is a pre-requisite for further interoperability checking
between different TCN implementations.
NOTE 1 For a definition of TCN implementation see 1.3.
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.
IEC 60571:Electronic equipment used on rail vehicles
IEC 60807, Rectangular connectors for frequencies below 3 MHz
IEC 61375-1: 2007, Electric railway equipment – Train bus – Part 1: Train communication
network
ISO/IEC 9646-1:1994, Information technology – Open Systems Interconnection – Conformance
testing methodology and framework – Part 1: General concepts (Also available as ITU-T
Recommendation X.290 (1995))
ISO/IEC 9646-7:1994, Information technology – Open Systems Interconnection –Conformance
testing methodology and framework – Part 7: Implementation Conformance Statements (Also
available as ITU-T Recommendation X.296 (1995))
UIC 556, Information transmission in trains (train bus)
1.3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/IEC 9646-1 and
IEC 61375-1 apply.
2 Conformance test: approach, requirements and boundaries
2.1 The approach
This standard specifies a general methodology for testing the conformance to the TCN
protocol standard of products in which the standard is claimed to be implemented.
This standard is organised into clauses structured into different phases of the conformance
testing process, these phases being characterised by the following roles:

61375-2 © IEC:2007(E) – 11 –
a) the specification of abstract test suites for particular TCN protocols according to ISO/IEC
9646-1;
b) the derivation of executable test suites and associated testing tools according to ISO/IEC
9646-7;
Annex A specifies the rules on clients and laboratory specifying:
c) the role of a client of a test laboratory, having an implementation of TCN protocols to be
tested;
d) the operation of conformance testing, culminating in the production of a conformance test
report which gives the results in terms of the test suite(s) used and the relevant
documentation produced.
In all clauses of this standard, the scope is limited in order to meet the following objectives:
e) to achieve an adequate level of confidence in the tests as a guide to conformance;
f) to achieve comparability between the results of the corresponding tests applied in different
places at different times;
g) to facilitate communication between the parties responsible for the roles described above.
Each objective involves the framework for development of TCN test suites, as listed
hereinafter:
h) how they should relate to the various types of conformance requirement;
i) the types of test to be standardised and the types not needing standardisation;
j) the criteria for selecting tests for inclusion in a conformance test suite;
k) the notation to be used for defining tests;
l) the structure of a test suite.
Certification, an administrative procedure which may follow conformance testing, is outside the
scope of this standard.
Requirements for procurement and contracts are outside the scope of this standard.
2.1.1 Requirements
2.1.1.1 General
In the context of TCN, a real system is said to exhibit conformance if it complies with the
requirements of applicable TCN standard clauses in its communication with a reference
system, i.e. the tester.
A TCN standard is a set of interrelated clauses which, together, define behaviour of TCN
systems in their communication. Conformance of an IUT will, therefore, be expressed at two
levels, conformance to each individual clause, and conformance to the set of clauses.
The following clauses define the conformance requirements and classify them according to
attributes and into feasible groups. Attributes and grouping are defined from the general point
of view with reference to a TCN specification itself and from the IUT point of view. In the
second case, the requirement shall be declared in the appropriate PICS and PIXIT.
2.1.1.2 Conformance requirements
The conformance requirements can be:
a) mandatory requirements: these are to be observed in all cases;
b) conditional requirements: these are to be observed if the conditions, set out in the clause,
apply;
– 12 – 61375-2 © IEC:2007(E)
c) options: these can be selected to suit the implementation, provided that any requirements
applicable to the option are observed.
TCN essential functionality are mandatory requirements; additional functionality can be either
conditional or optional requirements.
Furthermore, conformance requirements in a Part can be stated:
d) positively: they state what shall be done;
e) negatively (prohibitions): they state what shall not be done.
Finally, conformance requirements fall into two groups:
f) static conformance requirements;
g) dynamic conformance requirements;
these are discussed in 2.1.1.3 and 2.1.1.4, respectively.
2.1.1.3 Static conformance requirements
To facilitate interoperability static conformance requirements define the allowed minimum
capabilities of an implementation. These requirements may be at a broad level, such as the
grouping of functional units and options into protocol classes, or at a detailed level, such as a
range of values that have to be supported for specific parameters of timers.
Static conformance requirements and options in TCN parts can be of two varieties:
a) those which determine the capabilities to be included in the implementation of the
particular protocol;
b) those which determine multi-layer dependencies, for example those which place
constraints on the capabilities of the underlying layers of the system in which the protocol
implementation resides. These are likely to be found in upper layer parts (e.g. network
management vs real time protocols).
All capabilities not explicitly stated as static conformance requirements are to be regarded as
optional.
2.1.1.4 Dynamic conformance requirements
Dynamic conformance requirements are all those requirements (and options) which determine
what observable behaviour is permitted by the relevant TCN part in instances of
communication. They form the bulk of each TCN protocol document. They define the set of
allowable behaviours of an implementation or real system. This set defines the maximum
capability that a conforming implementation or real system can have within the terms of the
TCN protocol document.
A system exhibits dynamic conformance in an instance of communication if its behaviour is a
member of the set of all behaviours permitted by the relevant TCN protocol part in a way which
is consistent with the PICS.
2.1.1.4.1 A conforming system
A conforming system or implementation is one which is shown to satisfy both static and
dynamic conformance requirements, consistent with the capabilities stated in the PICS, for
each protocol declared in the system conformance statement.
2.1.1.4.2 Interoperability and conformance
The primary purpose of conformance testing is to increase the probability that different
implementations are able to inter-operate.

61375-2 © IEC:2007(E) – 13 –
Successful interoperability of two or more real open systems is more likely to be achieved if
they all conform to the same subset of a TCN part, or to the same selection of TCN parts, than
if they do not.
To prepare two or more systems to successfully inter-operate, it is recommended that a
comparison is made of the system conformance statements and PICSs of these systems.
If there is more than one version of a relevant TCN part indicated in the PICSs, the differences
between the versions need to be identified and their implications for consideration, including
their use in combination with other parts.
While conformance is a necessary condition, it is not on its own a sufficient condition to
guarantee interoperability capability. Even if two implementations conform to the same TCN
protocol part, they may fail to interoperate because of factors outside the scope of this
standard.
Trial interoperability is recommended to detect these factors. Further information to assist
interoperability between two systems can be obtained by extending the PICS comparison to
other relevant information, including test reports and PIXIT. The comparison can focus on:
a) additional mechanisms claimed to work around known ambiguities or deficiencies not yet
corrected in the TCN standard or in peer real systems, for example solution of multi-layer
problems;
b) selection of free options which are not taken into account in the static conformance
requirements of the TCN parts;
c) the existence of timers not specified in the TCN parts and their associated values.
NOTE The comparison can be made between two individual systems, between two or more types of product, or,
for the PICS comparison only, between two or more specifications for procurement, permissions to connect, etc.

2.1.2 Requirements declaration statements for an IUT
2.1.2.1 Protocol implementation conformance statement (PICS)
To evaluate the conformance of a particular implementation, it is necessary to have a
statement of the capabilities and options which have been implemented, and any features
which have been omitted, so that the implementation can be tested for conformance against
relevant requirements, and against those requirements only. Such a statement is called a
Protocol Implementation Conformance Statement (PICS).
In a PICS there should be a distinction between the following categories of information which it
may contain:
a) information related to the mandatory, optional and conditional static conformance
requirements of the protocol itself;
b) information related to the mandatory, optional and conditional static conformance
requirements for multi-layer dependencies.
If a set of interrelated TCN protocol has been implemented in a system, a PICS is needed for
each protocol. A system conformance statement will also be necessary, summarising all
protocols in the system for each of which a distinct PICS is provided.
2.1.2.2 Protocol implementation extra information for testing (PIXIT)
In order to test a protocol implementation, the test laboratory will require information relating to
the IUT and its testing environment in addition to that provided by the PICS. This "Protocol

– 14 – 61375-2 © IEC:2007(E)
Implementation eXtra Information for Testing" (PIXIT) will be provided by the client submitting
the implementation for testing, as a result of consultation with the test laboratory.
The PIXIT may contain the following information:
a) information needed by the test laboratory in order to be able to run the appropriate test
suite on the specific system (e.g. information related to the test method to be used to run
the test cases, addressing information);
b) information already mentioned in the PICS and which needs to be made precise (e.g. a
timer value range which is declared as a parameter in the PICS should be specified in the
PIXIT);
c) information to help determine which capabilities stated in the PICS as being supported are
testable and which are untestable;
d) other administrative matters (e.g. the IUT identifier, reference to the related PICS).
The PIXIT should not conflict with the appropriate PICS.
The abstract test suite specifier, test implementor and test laboratory will all contribute to the
development of the PIXIT pro-forma.
2.2 Boundaries
2.2.1 General
Conformance testing as discussed in this standard is focused on testing for conformance to
TCN clauses as they are specified in IEC 61375-1 (second edition).
In principle, the objective of conformance testing is to establish whether the implementation
being tested conforms to the specification in the relevant clause. Practical limitations make it
impossible to be exhaustive, and economic considerations may restrict testing still further.
Therefore, this standard distinguishes four types of testing, according to the extent to which
they provide an indication of conformance:
a) basic interconnection tests, which provide prima facie evidence that an IUT conforms;
b) capability tests, which check that the observable capabilities of the IUT are in accordance
with the static conformance requirements and the capabilities claimed in the PICS;
c) behaviour tests, which endeavour to provide testing which is as comprehensive as possible
over the full range of dynamic conformance requirements within the capabilities of the IUT;
d) conformance resolution tests, which probe in depth the conformance of an IUT to particular
requirements, to provide a definite yes/no answer and diagnostic information in relation to
specific conformance issues; such tests are not covered by this standard.
Tests a), b), c) and d) are foreseen in A.6.3 of IEC 61375-1, and are described in detail by the
following subclauses.
Relations to interoperability and performance are hereinafter considered and defined to clarify
their boundaries.
2.2.2 Basic interconnection tests
Basic interconnection tests provide limited testing of an IUT to establish that there is sufficient
conformance for interconnection to be possible, without trying to perform thorough testing.
2.2.2.1 Applicability of basic interconnection tests
Basic interconnection tests are appropriate:

61375-2 © IEC:2007(E) – 15 –
a) for detecting severe cases of non-conformance;
b) as a preliminary filter before undertaking more costly tests;
c) to give a prima facie indication that an implementation which has passed full conformance
tests in one environment still conforms in a new environment (e.g. before testing an (N)-
implementation, to check that a tested (N – 1)-implementation has not undergone any
severe change due to being linked to the (N)-implementation);
d) for use by users of implementations, to determine whether the implementations appear to
be usable for communication with other conforming implementations, for example as a
preliminary to data interchange.
Basic interconnection tests are inappropriate:
e) as a basis for claims of conformance by the supplier of an implementation;
f) as a means of arbitration to determine causes for communications failure.
Basic interconnection tests are standardised a subset of a conformance test suite (including
capability and behaviour tests). They can be used on their own or together with a conformance
test suite. The existence and execution of basic interconnection tests are optional.
2.2.3 Capability tests
Capability tests provide limited testing of each of the static conformance requirements in a
Part, to ascertain what capabilities of the IUT can be observed and to check that those
observable capabilities are valid with respect to the static conformance requirements and the
PICS.
2.2.3.1 Applicability of capability tests
Capability tests are appropriate:
a) to check as far as possible the consistency of the PICS with the IUT;
b) as a preliminary filter before undertaking more in-depth and costly testing;
c) to check that the capabilities of the IUT are consistent with the static conformance
requirements;
d) to enable efficient selection of behaviour tests to be made for a particular IUT;
e) when taken together with behaviour tests, as a basis for claims of conformance.
Capability tests are inappropriate:
f) on their own, as a basis for claims of conformance by the supplier of an implementation;
g) for testing in detail the behaviour associated with each capability which has been
implemented or not implemented;
h) for resolution of problems experienced during live usage or where other tests indicate
possible non-conformance even though the capability tests have been satisfied.
Capability tests are standardised within a conformance test suite. They can either be
separated into their own test group(s) or merged with the behaviour tests.
2.2.4 Behaviour tests
Behaviour tests test an implementation as thoroughly as is practical, over the full range of
dynamic conformance requirements specified in a Part. Since the number of possible
combinations of events and timing of events is infinite, such testing cannot be exhaustive.
There is a further limitation, namely that these tests are designed to be run collectively in a
single test environment, so that any faults which are difficult or impossible to detect in that
environment are likely to be missed. Therefore, it is possible that a non-conforming
implementation passes the conformance test suite; one aim of the test suite design is to
minimise the number of times that this occurs.

– 16 – 61375-2 © IEC:2007(E)
Behaviour tests with capability tests are the basis for the conformance assessment process.
Behaviour tests are inappropriate:
a) for resolution of problems experienced during live usage or where other tests indicate
possible non-conformance even though the behaviour tests have been satisfied.
Behaviour tests are standardised as the bulk of a conformance test suite.
NOTE Behaviour tests include tests for valid behaviour by the IUT in response to valid, inopportune and
syntactically invalid protocol behaviour by the real tester. This includes testing the rejection by the IUT of attempts
to use features (capabilities) which are stated in the PICS as being not implemented. Thus, capability tests do not
need to include tests for capabilities omitted from the PICS.
2.2.5 Conformance resolution tests
Conformance resolution tests provide diagnostic answers, as near to definitive as possible, to
the resolution of whether an implementation satisfi
...