IEC61375-2：列车通信网络一致性测试标准

5星 · 超过95%的资源需积分: 43 17 浏览量更新于2024-07-27 2 收藏 1.37MB PDF 举报

"IEC61375-2标准文档涉及列车通信网络中的一致性测试，主要关注电动铁路设备的列车总线系统，并提供了2007年首次发布的测试规范。该标准由国际电工委员会(IEC)发布，版权受保护，未经许可不得复制或网络分发。" IEC61375-2标准是国际电工委员会制定的一个关键规范，它专门针对列车通信网络的符合性测试。这个标准的第二部分（Part2）详细阐述了列车通信网络的一致性测试方法和要求，确保在电动铁路设备中使用的列车总线系统能够安全、可靠地运行。列车通信网络是现代铁路系统的核心组成部分，它允许列车上的各个子系统和设备之间进行高效的数据交换，包括控制指令、状态报告、故障诊断信息等。一致性测试是验证这些网络是否符合预设标准和规范的过程，以确保其性能、兼容性和互操作性。在IEC61375-2标准中，可能包括以下几个关键知识点： 1. **网络架构**：定义了列车通信网络的基本架构，包括总线拓扑、通信协议栈以及不同层次间的交互方式。 2. **协议规范**：详细描述了列车总线所采用的通信协议，如TCN（列车通信网络）的规范，这可能涉及到物理层、数据链路层、网络层等多个层次的详细规定。 3. **测试方法**：提供了一整套测试流程和测试用例，用于检查网络设备的兼容性、稳定性、响应时间和错误处理能力等关键性能指标。 4. **兼容性**：确保不同制造商的设备能在同一网络上协同工作，避免因设备间的不兼容导致的问题。 5. **故障恢复与冗余**：测试网络在硬件或软件故障情况下的恢复机制，以及冗余设计的验证，以保证系统的高可用性。 6. **安全标准**：考虑铁路应用的特殊性，可能包含对网络安全性和可靠性的额外要求，如防止未经授权的访问、数据完整性保护等。 7. **测试工具与设备**：规定了执行一致性测试所需的专业工具和设备，以及如何正确使用这些工具进行测试。 8. **文档和报告**：对于测试过程的记录和结果的报告，有明确的格式和内容要求，以供审查和认证。了解并遵循IEC61375-2标准对于铁路设备制造商和系统集成商至关重要，因为它确保了列车通信网络的高效运行，促进了全球铁路行业的技术进步和安全标准的统一。同时，对于监管机构和认证机构来说，此标准提供了评估和验证列车通信系统是否符合国际标准的依据。

– 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:

Provided by IHS under license with IEC

Not for Resale

No reproduction or networking permitted without license from IHS

--`,,```,,,,````-`-`,,`,,`,`,,`---

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.

Provided by IHS under license with IEC

Not for Resale

No reproduction or networking permitted without license from IHS

--`,,```,,,,````-`-`,,`,,`,`,,`---

– 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 satisfies particular requirements. Because of the

problems of exhaustiveness, the definite answers are gained at the expense of confining tests

to a narrow field.

The test architecture and test method will normally be chosen specifically for the requirements

to be tested, and need not be ones that are generally useful for other requirements. They may

even be ones that are regarded as being unacceptable for (standardised) abstract

conformance test suites, for example involving implementation-specific methods using, say,

the diagnostic and debugging facilities of the specific operating system.

The distinction between behaviour tests and conformance resolution tests may be illustrated

by the case of an event such as a reset. The behaviour tests may include only a representative

selection of conditions under which a reset might occur, and may fail to detect incorrect

behaviour in other circumstances. The conformance resolution tests would be confined to

conditions under which incorrect behaviour was already suspected to occur, and would confirm

whether or not the suspicions were correct.

Conformance resolution tests are appropriate:

a) for providing a yes/no answer in a strictly confined and previously identified situation (e.g.

during implementation development, to check whether a particular feature has been

correctly implemented, or during operational use, to investigate the cause of problems);

b) as a means for identifying and offering resolutions for deficiencies in a current

conformance test suite.

Conformance resolution tests are inappropriate

c) as a basis for judging whether or not an implementation conforms overall.

Conformance resolution tests are not standardised. As a by-product of conformance testing,

errors and deficiencies in protocol parts may be identified.

2.2.6 Interpretation of clauses/subclauses and statements

The TCN described in IEC 61375-1 is subject to a sort of interpretation to translate some

clauses/subclauses and requirements into realisable test suites. The complexity of most TCN

protocols makes exhaustive testing impractical on both technical and economic grounds. To

cope with a real implementation and extract from IEC 61375-1 all the relevant tests and some

criteria were used. The criteria were grouped according to their characteristics:

a) imperatives;

b) illustrative;

c) directives;

Provided by IHS under license with IEC

Not for Resale

No reproduction or networking permitted without license from IHS

--`,,```,,,,````-`-`,,`,,`,`,,`---

61375-2 © IEC:2007(E) – 17 –

d) options;

e) weak phrases.

The following subclauses describe the criteria.

2.2.6.1 Imperatives

Imperatives are those words and phrases commanding that something shall be provided and

are classified as mandatory. They are:

a) shall – dictates the provision of a functional capability;

b) must or must not – establishes performance requirements or constraints;

c) is required to – is a specification statement written in the passive voice;

d) are applicable – includes, by reference, standards or other documentation as an addition

to the requirements being specified;

e) responsible for – is a requirement written for architectures already defined. As an

example, " In extended reply delay applications, the master is responsible for spacing the

master frames so that the minimum time to transmit to a slave frame and the following

master frame is greater than T_safe..";

f) will – is generally used to cite things that the operational or development environment are

to provide to the capability being specified. For example, " If it was a strong master, it will

signal its demoting to all nodes and it will remain in control of the bus as a weak master

until a strong node is appointed";

g) should – when it is used, the specification statement is considered to be very weak. For

example, " Devices supporting the message data capability should have a device address

smaller than 256.".

Continuance

Phrases that follow an imperative and introduce the specification of requirements at a lower

level, for a supplemental requirement count.

a) as follows,

b) below,

c) following,

d) in particular,

e) listed,

f) support.

Phrases that introduces temporal indication, that may lead to definite or indefinite actions, or

enumerative that may lead to infinite test cases.

Table 2 – Continuance indication

Statement Example

1 for each A PV_Set identifies a set of variables belonging to the same dataset, including for each

variable the Memory_Address where it should be copied to (or from), and including for the

whole dataset the Freshness_Time.)

2 while While sending BD packets, the producer filters incoming BR packets and starts

retransmission after insertion of a transmission pause (PAUSE_TMO in addition to the

normal SEND_TMO)

The requirement containing temporal or enumerative is tested with a finite time or finite

sample.

Provided by IHS under license with IEC

Not for Resale

No reproduction or networking permitted without license from IHS

--`,,```,,,,````-`-`,,`,,`,`,,`---

2.2.6.2 Illustrative

This is information within the requirements document. The data and information pointed to by

illustrative strengthens the document's specification statements and whenever possible is used

as sample category input for the test. Namely:

a) figure;

b) table;

c) for example;

d) note.

2.2.6.3 Options

Options is the category of words that give the developer latitude in satisfying the specification

statements that contain them. This category clearly forms the basis for the option statements

declaration into the PICS. However, those requirements containing such a category of words

loosen the specification, increase the risk of non-interoperability, and widen the tests sets.

a) can (Example: Gateways with Bus_Administrator capability can synchronise the busses.);

b) may (Example: Class 5 devices may offer the Bus_Administrator capability.);

c) optionally (Example: The User_Programmable capability is optional.);

d) exclusion (Example: while the IUT is naming the nodes, one node responds to the naming

frame but not to the status request, or sends a wrong naming response frame).

Options shall drive the PICS production.

2.2.6.4 Weak statements

Weak statements are apt to cause uncertainty leaving room for multiple interpretations, such

wording provides a basis for expanding a requirement or adding future requirements. For the

extent of testing, this category generates test with test cases chosen among a representative

set of samples. However, by no means such sets fully represent all significant cases foreseen

by the clause under test. They are:

Table 3 – Weak statements

Phrases with Example

adequate The transmitter and the receiver connector shall be adequately identified,

preferably:

• light grey for the transmitter;

• dark grey for the receive.

be able to The link layer as well as the application shall be able to access a port consistently,

i.e. write or read all its data in one indivisible operation

be capable A device with double-line attachment shall be capable of being attached to both a

single-line or to a double-line EMD segment, as shown in Figure 56

effective The entity which effectively accesses the objects in each layer is called the Layer

Management Entity, or LME

normal While sending BD packets, the producer filters incoming BR packets and starts

retransmission after insertion of a transmission pause (PAUSE_TMO in addition to

the normal SEND_TMO.

provide for The Application Layer for Variables (AVI) shall provide for Cluster access the

following primitives, illustrated in Figure 14 and specified in the following

subclauses

Provided by IHS under license with IEC

Not for Resale

No reproduction or networking permitted without license from IHS

--`,,```,,,,````-`-`,,`,,`,`,,`---

剩余171页未读，继续阅读

fricyzju

粉丝: 5
资源: 10

IEC61375-2：列车通信网络一致性测试标准

车辆TCN网络通信协议IEC61375-2-3标准解析

IEC61375-2-3铁路通信协议标准详细解析

IEC 61375-2-3: 2015列车通信网络(TCN)规范

IEC61375-2-RTP-PD.rar_61375_IEC_IEC61375-2

iec61375-2-3_ed1.0_en.rar_IEC_IEC61375_IEC61375-2_iec61375-2-3_t

IEC 61375-2-5-2014

IEC 61375-2-3-2015

IEC61375-2-3-2015

IEC61375-2-RTP-PD

IEC 61375-2-3-2015-EN

最新资源