open alliance automotive ethernet ecu test … alliance restriction level: public open alliance...

OPEN Alliance Automotive Ethernet ECU

Test Specification TC8 ECU and Network Test

Author & Company OPEN ALLIANCE TC8 Members

Title ECU and Network Test, Test Specification ECU

Version 1.0

Date January 15, 2016

Status Released

Restriction Level Public

Automotive Ethernet Test Specification for an ECU

OPEN Alliance

Restriction Level: Public OPEN Alliance Automotive Ethernet ECU Test Specification | Jan-16 2

Version Control of Document

Version Author Description Date

1.0 TC8 members First release 15.01.16

OPEN Alliance


Disclaimer

The OPEN Specifications (including any part thereof) are intended to be used as an information source to enable to manufacture and test products which comply with the OPEN Specifications. All OPEN Specifications are provided on as is basis and all warranties, either explicit or implied, are excluded unless mandatory under law. Accordingly, the OPEN Alliance Members who have contributed to the OPEN Specifications make no representations or warranties with regard to the OPEN Specifications or the information (including any software) contained therein, including any warranties of merchantability, fitness for purpose, or absence of third party rights and make no representations as to the accuracy or completeness of the OPEN Specifications or any information contained therein. The OPEN Alliance Members who have contributed to the OPEN Specifications will not be liable for any losses, costs, expenses or damages arising in any way out of use or reliance upon any OPEN Specification or any information therein. Nothing in this document operates to limit or exclude any liability for fraud or any other liability which is not permitted to be excluded or limited by operation of law. The material contained in OPEN Specifications is protected by copyright and may be subject to other types of Intellectual Property Rights. OPEN Specifications (or any part thereof) shall be distributed only among those bound by the confidentiality defined for the OPEN Specification and as announced in the OPEN Specification documents. The distribution of OPEN Specifications shall not operate as an assignment or license to any recipient of any OPEN Specification of any patents, registered designs, unregistered designs, trademarks, trade names or other rights as may subsist in or be contained in or reproduced in any OPEN Specification. The commercial exploitation of the material in this document may require such a license, and any and all liability arising out of use without such a license is excluded. OPEN Specification documents may be reproduced in electronic or paper form or utilized in order to achieve the Scope only. Reproduction or utilization for any other purposes as well as any modification of the Specification document, in any form or by any means, electronic or mechanical, including photocopying and microfilm, is explicitly excluded. Without prejudice to the foregoing, the OPEN Alliance Specifications have been developed for automotive applications only. They have neither been developed, nor tested for non-automotive applications. OPEN Alliance reserves the right to withdraw, modify, or replace any OPEN Specification at any time,

without notice.

OPEN Alliance


Contents 1 Introduction .......................................................................................................................................... 7

1.1 Overview ....................................................................................................................................... 7

1.2 Feedback ....................................................................................................................................... 7

1.3 References .................................................................................................................................... 8

1.4 Definition of Test Scopes .............................................................................................................. 8

1.4.1 Test Scope Automotive Ethernet .......................................................................................... 8

1.4.2 Test Scope TCP/IP Protocol Family ....................................................................................... 8

1.4.3 Test Scope Automotive Protocols ......................................................................................... 8

2 Test Scope Layer 1 of Automotive Ethernet ......................................................................................... 9

2.1 Interoperability Tests .................................................................................................................... 9

2.1.1 General .................................................................................................................................. 9

2.1.2 Link-up time .......................................................................................................................... 9

2.1.3 Signal Quality ...................................................................................................................... 14

2.1.4 Cable Diagnose .................................................................................................................... 19

2.2 PMA ............................................................................................................................................. 23

2.2.1 General ................................................................................................................................ 23

2.2.2 Transmitter Electrical Specifications ................................................................................... 23

2.2.3 Receiver Electrical Specifications ........................................................................................ 33

3 Test Scope Layer 2 of Automotive Ethernet ....................................................................................... 35

3.1 Overview & Requirements for ECU Automotive Ethernet Switch Testing Test Scope ............... 35

3.2 VLAN Testing ............................................................................................................................... 35

3.3 QoS Testing ................................................................................................................................. 41

3.4 General Switch Testing ............................................................................................................... 52

3.5 Ingress Filtering ........................................................................................................................... 59

3.6 Diagnostics .................................................................................................................................. 62

4 Test Scope TCP/IP Protocol Family ..................................................................................................... 65

4.1 Address Resolution Protocol (ARP) ............................................................................................. 65

4.1.1 General ................................................................................................................................ 65

4.1.2 Parameters used in the tests .............................................................................................. 66

4.1.3 Terminology used in Test Procedure .................................................................................. 67

OPEN Alliance


4.1.4 Test Cases ARP .................................................................................................................... 68

4.2 Internet Control Message Protocol Version 4 (ICMPv4) ........................................................... 115

4.2.1 General .............................................................................................................................. 115

4.2.2 Parameters used in the tests ............................................................................................ 116

4.2.3 Test cases ICMPv4 ............................................................................................................. 117

4.3 Internet Protocol Version 4 (IPv4) ............................................................................................ 142

4.3.1 General .............................................................................................................................. 142


4.3.3 IPv4 Test cases .................................................................................................................. 145

4.4 Dynamic configuration of IPv4 Link Local Address ................................................................... 204

4.4.1 General .............................................................................................................................. 204

4.4.2 Simulated topologies ........................................................................................................ 204

4.4.3 Required topology related configuration ......................................................................... 204

4.4.4 Coverage ........................................................................................................................... 205

4.4.5 Parameters/constants used in the tests ........................................................................... 205

4.4.6 Tests .................................................................................................................................. 207

4.5 User Datagram Protocol (UDP) ................................................................................................. 302

4.5.1 General .............................................................................................................................. 302




4.5.5 Tests .................................................................................................................................. 304

4.6 Dynamic Host configuration Protocol Version 4 (DHCPv4) Server ........................................... 357

4.6.1 General .............................................................................................................................. 357



4.6.4 Coverage ........................................................................................................................... 361

4.6.5 Parameters and constants used in the tests ..................................................................... 361

4.6.6 Tests .................................................................................................................................. 364

4.7 Dynamic Host configuration Protocol Version 4 (DHCPv4) Client ............................................ 460

4.7.1 General .............................................................................................................................. 460


OPEN Alliance



4.7.4 Coverage ........................................................................................................................... 464

4.7.5 Parameters and constants used in the tests ..................................................................... 464

4.7.6 Tests .................................................................................................................................. 467

4.8 Transmisison Control Protocol (TCP) ........................................................................................ 574

4.8.1 General .............................................................................................................................. 574




4.8.5 Upper Tester Procedures .................................................................................................. 575

4.8.6 Tests .................................................................................................................................. 576

5 Test Scope Automotive Protocols ..................................................................................................... 850

5.1 Scalable service-Oriented MiddlewarE over IP Protocol (SOME/IP) ........................................ 850

5.1.1 General .............................................................................................................................. 850


5.1.3 Terminology used in Test Procedure ................................................................................ 855

5.1.4 Test Cases SOME/IP Server ............................................................................................... 856

OPEN Alliance


1 Introduction

1.1 Overview This ECU and Network Test Specification is designed to determine if a product conforms to specifications defined in OPEN Specifications or related requirements. This specification is a collection of all test cases which are recommend to be considered for automotive use and should be referred by car manufacturers within their quality control processes. Sucessful execution and passing all relevant tests gives a Device Under Test (DUT) a mimimum approval that the devices basic implementiations are done correctly. This Test specification document is grouped in several chapters oriented on the scopes: Automotive

Ethernet, TCP/IP Protocol Family and Automotive Protocols which are described in chapter 1.3.

Tests are organized and identified with distinct IDs that relate to their scopes, and a unique

enumeration. For every scope introduction chapters explain common requirements on the Device under

Test, the Test Setup and parameters used by the following tests.

1.2 Feedback Any feedback for correcting, improving or adding new content is welcome. We encourage to bring

forward this feedback in the regular meetings of the OPEN Alliance TC8. In case you are not an OPEN

Alliance member you can relay questions or feedback through the following contacts:

Company Name Email address

C&S Group [email protected]

IXIA NXP Rajeev Roy [email protected] Ruetz System Solutions GmbH

[email protected]

Spirent Communications Dirk Tempelman Fares Mokrani Stephan Pietsch

[email protected] [email protected] [email protected]

mailto:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]

OPEN Alliance


1.3 References

[1] C&S Group, BroadR-Reach Interoperability Test Suite - Interoperability Test Suite Specification v2.0,

OpenAlliance, 2014.

[2] OPEN Alliance BroadR-Reach (OABR) Physical Layer Transceiver Specification For Automotive

Applications V3.2, June 24th, 2014.

[3] C. Donahue and D. Estes, BroadR-Reach Physical Media Attachment Test Suite v2.0, OpenAlliance,

2014.

[4] B. Krber, Definitions for Communication Channel, 2.0 ed., OPEN Alliance, 2014.

1.4 Definition of Test Scopes

1.4.1 Test Scope Automotive Ethernet Scope Automotive Ethernet includes the following ISO/OSI layers:

Layer 1: Physical Layer OPEN Alliance BroadR-Reach (OABR)

Layer 2: Data Link Layer, e.g IEEE Ethernet MAC + VLAN (802.1Q), ARP

1.4.2 Test Scope TCP/IP Protocol Family Scope TCP/IP Protocol Family includes the following ISO/OSI layers:

Layer 3: Network Layer, e.g. IP, ICMP

Layer 4: Transport Layer, e.g. UDP, TCP, DHCP

1.4.3 Test Scope Automotive Protocols Scope Automotive Protocols includes the following ISO/OSI layer:

Layers 5-6-7: Application oriented layers, e.g. UDP-NM, SOME/IP, SD

OPEN Alliance


2 Test Scope Layer 1 of Automotive Ethernet

2.1 Interoperability Tests

2.1.1 General The following test specifications are adapted from [1] to fit the general requirements of an ECU.

2.1.2 Link-up time (based on OABR_L1_IOP_22 of [1])

3 test cycles:

Power on Golden Device

Power on ECU

Wake up ECU

OABR_LINKUP_01: Link-up time - Trigger: Power on Golden Device

Synopsis Shall ensure that the link is established within a given time without a high time

variation.

Prerequisites 1. The DUT is connected to a stable power supply. 2. The DUT must be operated in normal mode which means the DUT builds up the

link and sends any Ethernet messages. 3. The Test System provides special awake conditions for the DUT such as a wakeup

line or network management CAN messages if necessary. 4. If the DUT contains a switch all links have to be tested separately.

5. The mean start up time of the golden device is available:

Test setup The DUT must be connected to the golden device with opposite master/slave

configuration. The polarity of the communication channel must be correct. The power

supplies are controlled by the test system.

OPEN Alliance


Test system

DUT

(ECU) Golden Device

CMCCon

Low

Pass

Filter

PHY

Tx

Rx

mC

Con

Power

supply

Power

supply

tstop

tstart

Test

procedure

1. DUT shall be active and ready to build up link. Repeat Step 2 to Step 5 n=100times:

2. Power on golden device. tstart=tPowerOnGoldenDevice 3. Polling of golden devices status register. If link_control= active link: tstop=tActiveLink 4. Calculate the time tup between power on and link up: tup= tstop - tstart 5. Power off golden device. End of Repeat

6. Calculate as follows:

= 1

()

=1

= 1

1(() )

2

=1

tmin = min (())

tmax = max (())

Pass criteria 50 ms

tmin > 10 ms +

tmax < 200 ms +

Notes This test has to be performed for each port of the ECU, if it has a switch inside.

OPEN Alliance


OABR_LINKUP_02: Link-up time - Trigger: Power on ECU


variation.

Prerequisites 1. The Golden Device is connected to a stable power supply. 2. The Test System provides special awake conditions for the DUT such as a wakeup

line or network management CAN messages if necessary.

3. The manufacturer has to provide the mean start up time of the DUT: 1

4. of Golden Device

OPEN Alliance


Test

procedure

1. Golden Device shall be active and ready to build up link. Repeat Step 2 to Step 5 n=100times:

2. Power on DUT. tstart=tPowerOnECU 3. Polling of golden devices status register. If link_control= active link: tstop=tActiveLink 4. Calculate the time tup between power on and link up: tup= tstop - tstart 5. Power off DUT. End of Repeat


= 1

()

=1

= 1

1(() )

2

=1

tmin = min (())

tmax = max (())

Pass criteria 50 ms

tmin > 10 ms + 1

tmax < 200 + 1


OPEN Alliance


OABR_LINKUP_03: Link-up time - Trigger: Wake up ECU


variation.

Prerequisites 1. The DUT and the Golden Device are connected to a stable power supply. 2. The DUT must be operated in normal mode which means the DUT build up the link

and sends any Ethernet messages. 3. Wake up message is necessary. The Test System provides special awake conditions

for the DUT such as a wakeup line or network management CAN messages. 4. The manufacturer has to provide the value Isleep.

5. The manufacturer has to provide the mean wake up time of the DUT: 2

Test setup The DUT must be connected to the golden device with opposite master/slave

configuration. The polarity of the communication channel must be correct. The power

supplies are controlled by the test system.

Test system

DUT

(ECU) Golden Device

CMCCon

Low

Pass

Filter

PHY

Tx

Rx

mC

Con

Power

supply

tstop

tstart

Power

supply

Wakeup

Trigger

Test

procedure

1. DUT shall be in sleep mode and Golden Device shall be active and ready to build up link.

Repeat Step 2 to Step 5 n=100times:

2. Turn on Wake up signal for DUT. 3. tWakeUpECU if IDUT> Isleep , tstart=tWakeUpECU 4. Polling of Golden Devices status register. If link_control= active link: tstop=tActiveLink 5. Calculate the time tup between power on and link up: tup= tstop - tstart 6. Switch DUT to sleep mode. End of Repeat


OPEN Alliance


= 1

()

=1

= 1

1(() )

2

=1

tmin = min (())

tmax = max (())

Pass criteria 50 ms

tmin > 10 ms + 2

tmax < 200 + 2


OPEN Alliance


2.1.3 Signal Quality (based on OABR_L1_IOP_23 of [1])

OABR_SIGNAL_01: Indicated signal quality for channel with decreasing quality

(based on OABR_L1_IOP_24 of [1])

Synopsis Shall ensure that the ECUs indicated signal quality decreases for a channel with

decreasing channel quality and that there is coherence between the SQI indicated

values on the ECU and the Golden device.


and sends any Ethernet messages. 3. The Test system allows varying and determining the quality of the communication

channel that connects the DUT and Golden Device. 4. DUT and Golden Device must be able to monitor the signal quality indicated by the

PHY. The DUTs information of the signal quality can be provided by an applicative Ethernet message, an UDS communication or another communication channel like CAN.

Test setup

Test system

DUT

(ECU)

Golden Device

CMCCon

Low

Pass

Filter

PHY

Tx

Rx

mC

Con

Power

supply

Rn

BR+

BR-

Rstart=Rend=

QGDQDUT

Test

procedure

1. Remove any artificial channel degradation, to ensure that the highest possible

signal quality is reached on both the DUT and Golden Device.

2. Read DUTs parameter SQI and Link Status.

3. Read Golden Device parameter SQI and Link Status.

4. Read the resistor value

5. Save the acquired information.

Degradation Step # SQI_DUT SQI_GD LinkStatus_DUT LinkStatus_GD R_channel

1 x% x% Up/Down Up/Down X[]

OPEN Alliance


n Rend

6. Increase artificial channel degradation on channel with a maximal step of 5 .

Repeat steps 2 to 6 until Channel quality is too low to establish a link.

Pass criteria Each test iteration shall be classified as passed, if all of the following condition(s) are

fulfilled.

Both devices show a decrement on the SQI value, allowing a maximal deviation of n%, where n% is the minimal step of the device with less resolution involved in the test set up.

DUT lost its link after indicating a SQI value of 40%


Notice that the DUT and the Golden Device could present different SQI scales. This fact

should be included in the test report.

OPEN Alliance


OABR_SIGNAL_02: Indicated signal quality for channel with increasing quality


Synopsis Shall ensure that the ECUs indicated signal quality increases for a channel with

increasing channel quality and that there is coherence between the SQI indicated

values on the ECU and the Golden device.


and sends any Ethernet messages. 3. The Test system allows varying and determining the quality of the communication

channel that connects the DUT and Golden Device. 4. DUT and Golden Device must be able to monitor the signal quality indicated by the

PHY. The DUTs information of the signal quality can be provided by an applicative Ethernet message, an UDS communication or another communication channel like CAN.

Test setup

Test system

DUT

(ECU)

Golden Device

CMCCon

Low

Pass

Filter

PHY

Tx

Rx

mC

Con

Power

supply

Rn

BR+

BR-

Rstart=Rend

QGDQDUT

Test

procedure

1. Start with the lowest possible quality of the communication channel with the identified resistor value Rend of the test 0.

2. Measurement of the signal quality of the DUT and Golden Device.

Degradation Step # SQI_DUT SQI_GD LinkStatus_DUT LinkStatus_GD R_channel

1 x% x% Up/Down Up/Down X[]

n Rend

3. Decrease artificial channel degradation on channel with a maximal step of 5 4. Repeat steps 2 and 3 until the channel quality reach 100%.

Pass criteria Each test iteration shall be classified as passed, if all of the following condition(s) are

OPEN Alliance


fulfilled.

Both devices show an increment on the SQI value, allowing a maximal deviation of n%, where n% is the minimal step of the device with less resolution involved in the test set up.

Link was not lost at a SQI value of > 40%


Notice that the DUT and the Golden Device could present different SQI scales. This fact

should be included in the test report.

OPEN Alliance


2.1.4 Cable diagnostics

OABR_CABLE_01: Cable diagnostics for ground detection

Synopsis Shall ensure that the ECUs cable diagnostic reliably detects a ground connection of one

or both of the bus lines.


and sends any Ethernet messages. 3. DUT must be able to detect any cable errors. This means the DUT have to trigger

the cable diagnostic features by itself and store it e.g. as DTC (Diagnostic Trouble Code). The result of DUTs cable diagnostic can be provided by an applicative Ethernet message, an UDS communication or another communication channel like CAN.

Test setup

Test system

DUT

(ECU)

Golden Device

CMCCon

Low

Pass

Filter

PHY

Tx

Rx

mC

Con

Power

supply

BR+

BR-

1 2

QCQC

1

QC

2

QC

21

QCGND GND

t t t t

Test

procedure

1. All DTCs or any other detected errors of the cable diagnostics of the DUT have to be deleted.

2. After the wait time t the test system requests all identified cable errors QC by the DUT.

3. The test system creates a cable error for a defined time terror. 4. After the wait time t the test system requests all identified cable errors QC by the

DUT. 5. Repeat step 1 to 4 for all error combinations (alternately BR+ and/or BR- connect to

GND).

Pass criteria Each test iteration shall be classified as passed, if the DUT reports all expected cable

errors.

Notes

OPEN Alliance


OABR_CABLE_02: Cable diagnostics for near and far end open


Synopsis Shall ensure that the ECUs cable diagnostic reliably detects an open of one or both of

the bus lines. The test shall be performed for both a near end open at the connector of

the DUT, and for a far end open at the connector of the Golden Device.




Test setup

Test system

Test system

DUT

(ECU)

Golden Device

Power

supply

BR+

BR-

1

2

QC

QC

1

QC

2

QC

t t t

Con CMCCon

Low

Pass

Filter

mCPHY

Rx

Tx

Near Open

Test system

DUT

(ECU)

Golden Device

Power

supply

BR+

BR-

1

2

QC

QC

1

QC

2

QC

t t t

Con CMCCon

Low

Pass

Filter

mCPHY

Rx

Tx

Far Open

Test

procedure

The following steps shall be applied to test near and far end open cable diagnostics




OPEN Alliance


DUT. 5. Repeat step 1 to 4 for all error combinations (alternately BR+ and/or BR- are open).

Pass criteria Each test iteration shall be classified as passed, if the DUT reports all expected cable

errors.

Notes The results shall be reported for each BroadR-Reach port available in the ECU.

OABR_CABLE_03: Cable diagnostics for near and far end short


Synopsis Shall ensure that the DUTs cable diagnostic reliably detects a short of the bus lines. The

test shall be performed for both a near end short at the connector of the DUT, and for a

far end short at the connector of the Golden Device.




Test setup

Test system

Test system

DUT

(ECU)

Golden Device

CMCCon

Low

Pass

Filter

PHY

Tx

Rx

mC

Con

Power

supply

BR+

BR-

1

QCQC

1

QC

Near Short

OPEN Alliance


Test system

DUT

(ECU)

Golden Device

CMCCon

Low

Pass

Filter

PHY

Tx

Rx

mC

Con

Power

supply

BR+

BR-

1

QCQC

1

QC

Far Short

Test

procedure

The following steps shall be applied to test near and far end short cable diagnostics




DUT. 5. Repeat step 1 to 4 for all error combinations (alternately BR+ connected to BR- at

connector of DUT/Golden Device).

Pass criteria Each test iteration shall be classified as passed, if the DUT reports a short between the

bus lines.

Notes The results shall be reported for each BroadR-Reach port available in the ECU.

OPEN Alliance


2.2 PMA

2.2.1 General This chapter shall be used for evaluation of the Physical Layer of a 100BASE-T1 (OA BR) interface on ECU

level.

Except otherwise stated the measurements shall be conducted by room temperature (RT=23C5C).

Referenced specification

The tests shall be carried out based on the definitions of the related test specifications [2], [3] and [4].

2.2.2 Transmitter Electrical Specifications The following test cases specify the Requirements of the Transmitter Side (measurement point: MDI).

OABR_PMA_TX_01: Check the Transmitter Output Droop

(based on the Chapter 5.4.1 Transmitter Output Droop of [2])

Synopsis Shall ensure that the DUT respects the maximum Output Droop value for both: Positive

and Negative magnitude.

Prerequisites 1. The DUT is connected to a stable power supply. 2. Use Link Partner or an interface to commute the DUT in Test Mode (via BroadR-

Reach or Standard Ethernet or CAN) 3. DUT must be able to switch to Test Mode 1.

Test setup Figure 5-1 of [2]: Transmitter Test Fixture 1: Droop, Jitter

Test Setup shall be carried out with an Oscilloscope. Test

procedure

1. The DUT is in Test Mode 1 and sends Test Pattern continually. 2. Use a test fixture terminated with 100 Ohm. 3. Measure the Value Vpk and Vd (after 500ns after the initial peak). 4. Calculate the Droop =100*(Vd/Vpk)% 5. Report the Values of the Positive and Negative Magnitude.

Pass criteria Each test iteration shall be classified as passed, if the values of the Droop are according

to chapter 5.4.1 Transmitter Output Droop of [2].

Negative and positive droop [%] shall be < 45%.

Test

iterations

Accumulate min. 10 Samples to increase the Accuracy.

Notes

OPEN Alliance


OABR_PMA_TX_02: Check the Transmitter Timing Jitter in MASTER Mode

(based on the Chapter 5.4.3 Transmitter Timing Jitter of [2])

Synopsis Shall ensure that the DUT respects the maximum Jitter value according to chapter 5.4.3

Transmitter Timing Jitter of [2]) at the MDI output jitter JTXOUT.



Test setup Figure 5-1 of [2]): Transmitter Test Fixture 1: Droop, Jitter

Test Setup shall be carried out with an Oscilloscope. Test

procedure

1. The DUT is in Test Mode 2 and sends Test Pattern continually. 2. Use a test fixture terminated with 100 Ohm.

3. Measure the Value JTXOUT 4. Compute the Transmitter Timing Jitter. 5. Report the Value of the Transmitter Timing Jitter.

Pass criteria Each test iteration shall be classified as passed, if the Value of the MDI Transmitter

Timing Jitter is according to chapter 5.4.3 Transmitter Timing Jitter of [2].

The MDI Output Jitter shall be < 50ps

Test

iterations

Accumulate min. 10 Samples to increase the Accuracy.

Notes

OPEN Alliance


OABR_PMA_TX_03: Check Master Transmit Clock Frequency

(based on [3])

Synopsis Shall ensure that the DUT has a stable clock.

Prerequisites For an ECU which is configured as slave in the Network, the ECU shall be switched to

MASTER-mode in this test.

1. The DUT is connected to a stable power supply. 2. Use Link Partner or an interface to commute the DUT in Test Mode (via BroadR-


Test setup Figure 5-1 of [2]): Transmitter Test Fixture 1: Droop, Jitter Test Setup shall be carried out with an Oscilloscope and a Test fixture terminated by

100.

Test

procedure 1. Use a Test fixture as described in test setup

2. Measure the Value Master Transmit Clock Frequency

3. Report the result with a resolution that shows that no limit violation has been detected.

Pass criteria The transmit clock shall be 66 2/3 MHz 100 ppm for all temperatures.

Test

iterations

This test shall be conducted at all corner temperatures of the ECU

(e.g. -40C/RT/105C).

Notes As the Test is realized on three corner temperatures use test cable that not influence

the result .

The signal frequency generated from the Test Mode 2 is 33 1/3 MHz

According to this criteria the result could be measured on the clock delivered by the

PHY in test mode 2 and reported as in Mbits that is the double of the measured value.

OPEN Alliance


OABR_PMA_TX_04: Check the Transmitter Power Spectral Density (PSD)

(based on the Chapter 5.4.4 Transmitter Power Spectral Density (PSD)of [2])

Synopsis Shall ensure that the DUT respects Table 5.4 of [2]:Power Spectral Density Min & Max

Mask Definition. The PSD should be between the upper and the lower values specified

in the table.



Test setup Test Setup can be carried out with a Spectrum Analyzer or an Oscilloscope and a Test

fixture terminated by 100.

Figure 5-3 of [2]: Transmitter Test Fixture 3: PSD Mask

Test

procedure

1. The DUT in Test Mode 5 and sends Test Pattern continually. 2. Use a test fixture terminated with 100 Ohm. 3. Spectrum Analyzer or Oscilloscope captures the transmitted test pattern. 4. Spectrum Analyzer or Oscilloscope computes the PSD. 5. Report the Value of the PSD as a Screenshot or a diagram/plot with a resolution

that shows that no MASK Violation has been detected.

Pass criteria Each test iteration shall be classified as passed, if the Value of the PSD is according to

chapter 5.4.4 Transmitter Power Spectral Density (PSD) of [2], table 5-4.

Figure 5-6 of [2]: PSD Upper and Lower Limits

Test

iterations

The averaging function of the scope shall be set at least to 50 time.

Notes In case of using a spectrum analyzer a balun with differential input must be used.

PSD shall be measured in the frequency range of 1 MHz to 200 MHz.

OPEN Alliance


OABR_PMA_TX_05: Check the MDI return Loss

(based on the Chapter Chapter 7.1.3 Return Loss.)

Synopsis Shall ensure that the DUT respects the Return Loss Mask Definition.



Test setup Test Setup shall be carried out with a Network Analyzer.

ECU connector cable side

ECU

OA BR

RF connector (SMA)

Line impedance 50

Test fixture

GND

Connection ECU GND pin to ground plane of test fixture

VBAT Terminal power supply

Measurement reference plane

To achieve a high degree of reliability of measurement results the use of a specific test

fixture for the connection to the ECU connector MDI pins is required. A test fixture

according to the test setup and in line with definitions of [4] shall be used. The ground

pin(s) of the ECU shall be direct connected to the ground plane of the test fixture. If

possible the original harness connector shall be used. It shall be a fixed part of the test

fixture. The calibration reference plane is defined at the beginning of the harness

cennector on the test fixture.

The test and measurement settings are defined by [4] chapter 4.1 to 4.3.

Test

procedure

1. The DUT is in test mode 4 and sends Test Pattern continually [see note]. 2. Use a test fixture as described in the test setup. 3. Connect the MDI via the test fixtureto the Network Analyzer. 4. Measure the Value Return Loss (Sdd11) 5. Analyze the waveform. 6. Report the result with a resolution that shows: no limit Violation was detected.

Pass criteria Each test iteration shall be classified as passed, if the value of the MDI Return Loss is

according to chapter Chapter 7.1.3 Return Loss..

Test

iterations

No

OPEN Alliance


Notes Instead of the TestMode, the OA BR transceiver can be configured for active mode and

shall be set to mode TX off or Scrambler off (no output signal generated by

transceiver) if available.

MDI Return Loss shall be measured in the frequency range of 1 MHz to 200 MHz.

OABR_PMA_TX_06: Check MDI Mode conversion

(based on [4])

Synopsis The tests shall be carried out based on the definitions of the related test specifications

[4].

Shall ensure that the DUT front end respects the appropriate symmetry requirements.

Prerequisites 1.The DUT is connected to a stable power supply.

2.Use Link Partner or an interface to commute the DUT in Test Mode (via BroadR-Reach or Standard Ethernet or CAN)

3.DUT must be able to switch to Test Mode 4 .

4. DUT shall be set to mode TX off or Scrambler off (no output signal generated by

transceiver). It is also possible to test with completely unpowered ECU. In this case it

shall be agreed by OEM.

Test setup


ECU

OA BR

RF connector (SMA)

Line impedance 50

Test fixture

GND






according to Fehler! Verweisquelle konnte nicht gefunden werden. test setup and in

line with definitions of [4] shall be used. The ground pin(s) of the ECU shall be direct

OPEN Alliance


connected to the ground plane of the test fixture. If possible the original harness

connector shall be used. It shall be a fixed part of the test fixture. The calibration

reference plane is defined at the beginning of the harness connector on the test fixture.

Additionally the used test fixture shall fulfill the limit for fixture self-conversion

according to the diagram of the test setup while the test fixture is not connected to the

ECU (terminal left open).


Limit for ECU fixture self-conversion

Test

procedure

1. Use a test fixture as described in the test setup. 2. Connect the MDI via the test fixture to the Network Analyzer.

3. Measure the Value Mode Conversion (Sdc22) 4. Analyze the waveform. 5. Report the Screenshot with a resolution that shows: no limit Violation was

detected.

Pass criteria For evaluation of MDI mode conversion measurements in the frequency range of 1 MHz

to 1 GHz are required. The following limit shall be fulfilled.

-80

-70

-60

-50

-40

-30

-20

-10

0

1 10 100 1000

Limit TCL ECU Test fixture

[dB]

[MHz]

f [MHz] TCL [dB]

1 - 7020 - 70200 - 50

MDI Mode conversion / OA BroadRReachItem: Requirment for ECU test fixture

Sdc11 / Transverse Conversion Loss (TCL)

Comment:

ECU terminal of test jig is left open for evaluation!

OPEN Alliance


Test

iterations

No

Notes

OABR_PMA_TX_07: Check MDI Common Mode emission

(based on)

Synopsis Shall ensure that the DUT front end is not emitting common mode signal.



Test setup


ECU

OA BR

RF connector (SMA)

Line impedance 50

Test fixture

GND


R=50 +/- 0.1%





-80

-70

-60

-50

-40

-30

-20

-10

0

1 10 100 1000

Limit

[dB]

[MHz]

f [MHz] TCL [dB]

1 - 6022 - 60100 - 47200 - 37

MDI Mode conversion / OA BroadRReachItem: Sdc11 / Transverse Conversion Loss (TCL)

OPEN Alliance


according to the test setup and in line with definitions of [4] shall be used. The ground

pin(s) of the ECU shall be direct connected to the ground plane of the test fixture. If

possible the original harness connector shall be used. It shall be a fixed part of the test

fixture. The calibration reference plane is defined at the beginning of the harness

connector on the test fixture.

Additionally to these definitions the used test fixture shall fulfill the limit for fixture self-

conversion according to the diagram of test setup 0 while the test fixture is not

connected to the ECU (terminal left open). The 50 Ohm resistors on the test fixture shall

be realized by RF resistor types with an accuracy of in minimum 0.1%.

The ECU shall be in an active powered state. The OA BR transceiver is configured for test

mode 5 [2]. The RF connector of the test fixture shall be connected to a RF analyzer

according to [4]. The settings for the RF analyzer are given in the table as follows.

Measuring equipment Spectrum analyzer Measuring receiver

Measurement unit dBV

Detector Peak

Frequency range 1 to 200 MHz

Resolution bandwidth (RBW) 10 kHz 9 kHz

Video bandwidth (VBW) > 3 x RBW -

Numbers of passes 10 (max hold) -

Measurement time per step - 100 ms

Frequency sweep time 20 s -

Frequency step width - 0.4 x RBW


Test

procedure

1. The DUT in Test Mode 5 and sends Test Pattern continually. 2. Use a test fixture as described in the test setup 3. Spectrum Analyzer, Measurement Receiver or Oscilloscope captures the

transmitted common mode emission spectrum 4. Report the value of the common mode emission with a resolution that shows that

no mask violation has been detected.

Pass criteria For evaluation of MDI mode conversion measurements in the frequency range of 1 MHz

to 200 MHz are required. The following limit shall be fulfilled. (Limit t.b.d.)

OPEN Alliance


Test

iterations

No

-10

0

10

20

30

40

50

60

70

80

1 10 100

Limit

[dBV]

[MHz]

f [MHz] CME [dBV]

1 2470 24

MDI Common mode emission / OA BroadRReachItem: RF common mode votlage

OPEN Alliance


2.2.3 Receiver Electrical Specifications The following test cases specify the Requirements of the Receiver Side (measurement point: MDI). The

following test cases are only for Switch ECUs.

OABR_PMA_RX_01: Check the Receiver Differential Input Signals

(based on [2] Chapter 5.1.1 Receive Differential Input Signals)

Synopsys Shall ensure that the DUTs respect the Bit Error Rate Test specified. The BER should be

less than 10-10 at typical symbol transmission rate: 66+2/3 MHz

Prerequisites 1. The DUT is connected to a stable power supply. 2. The DUT must be operated in normal mode which means the DUT build up the link. 3. Use a Test Center to generate and analyze Packet Error Rate (PER). 4. Use a Worst Case Channel of 15m.

Test setup No figure

Test

procedure

1. Test Center sends to DUT Packets with size 64 bytes continually with 100% load. 2. Test Center analyzes the Packet Loss 3. Report the Values of the PER. Repeat Steps 1 to 3 with Packet size 1518 bytes.

Pass criteria Each test shall be classified as passed, if the Value of the BER is lower than 10-10

Test

iterations

No

Notes

OPEN Alliance


OABR_PMA_RX_02: Check the Receiver Frequency Tolerance

(based on [2] Chapter 5.1.1 Receive Differential Input Signals)

Synopsys Shall ensure that the DUTs respect the Bit Error Rate Test specified. The BER should be less than 10-10 at symbol transmission rate minimum: 66+2/3 MHz - 100ppm and at symbol transmission rate maximum: 66+2/3 MHz + 100ppm

Prerequisites 1. The DUT is connected to a stable power supply. 2. The DUT must be operated in normal mode which means the DUT build up the link. 3. Use a Test Center to generate and analyze Packet Error Rate (PER). 4. Use a Worst Case Channel of 15m.

Test setup No figure

Test

procedure

1. Set symbol transmission rate at test Center to minimum: 66+2/3 MHz - 100ppm 2. Test Center sends to DUT Packets with size 64 bytes continually with 100% load. 3. Test Center analyzes the Packet Loss 4. Report the Values of the PER. 5. Repeat Steps 2 to 4 with Packet size 1518 bytes. 6. Set symbol transmission rate at test Center to maximum: 66+2/3 MHz + 100ppm 7. Test Center sends to DUT Packets with size 64 bytes continually with 100% load. 8. Test Center analyzes the Packet Loss 9. Report the Values of the PER. 10. Repeat Steps 7 to 9 with Packet size 1518 bytes.

Pass criteria Each test shall be classified as passed, if the Value of the BER is lower than 10-10

Test

iterations

No

Notes

OPEN Alliance


3 Test Scope Layer 2 of Automotive Ethernet

3.1 Overview & Requirements for ECU Automotive Ethernet Switch Testing

Test Scope The tests in this scope validate the behavior of the Automotive Ethernet Switch within the ECU. The

Automotive Ethernet Switch is an entity that includes the switch silicon hardware and any additional

hardware, firmware, and software needed to meets the requirements for a MAC bridge set forth in

the IEEE 802.1 standards.

Any reference to DUT in this test scope refers to the logical Automotive Ethernet Switch including

any software or configuration done in an MCU or CPU. The test device shall include both externally

connected hardware/software as well as software running on any MCU / CPU on the ECU that is

connected to the Automotive Ethernet Switch via an Automotive Ethernet Port.

The tests in this test scope are designed to test that the Automotive Ethernet Switch entity is

configured & operating correctly as per the ECU configuration, but assume that the functionality of the

switch silicon, PHYs, or other components has been verified elsewhere.

The test cases are grouped by functional areas. Only those functional areas and test cases that are

applicable to a given ECU need to be tested. The configuration of each ECU (including the switch

configuration) should be used to determine which test cases are applicable.

OPEN Alliance


3.2 VLAN Testing

SWITCH_VLAN_01: VLAN Unicast Traffic Forwarding

Synopsys The test shall ensure that the switch is able to forward the traffic for unidentified MACs

in presence of line rate traffic, and drop the traffic received from un-configured VLANs.

Prerequisites The DUT shall be operated in normal mode, i.e. the switch is configured and ready to receive/forward Ethernet frames.

The DUT shall be capable of responding to Echo-Request message with Echo-Reply message on some or all of its ports.

Test setup All available (external) ports of the DUT are connected to the test system.

Test Input

Parameters

1. Switch port Valid Source/Destination MAC Addresses are configured in either of these ways:

a. read from the ECU Configuration file, if configured/available b. MAC Addresses identified for testing purpose

2. Valid VLANs are read from the ECU Configuration File, if available.

Test

Procedure

1. Create the test topology as shown in the Setup. 2. On each test port, iterate through each VLAN, source MAC, and destination MAC,

and transmit Echo Request packets for each combination. 3. Verify that for each valid combination of destination MAC and VLAN, an Echo Reply

is received on the test device port that sent the Echo-Request packet. 4. Verify that for each invalid VLAN or each invalid MAC/VLAN combination, the Echo-

Request packet is dropped on the receiving ECU Switch Port. 5. Verify that for each combination of invalid destination MAC and valid VLAN, the

Echo-Request is forwarded to each test device port belonging to that VLAN except the source port of Echo-Request.

Pass criteria The DUT traffic counters match the expected test device traffic counters for each

OPEN Alliance


combination of VLAN, Source MAC and Destination MAC.

Test

iterations

The test shall be repeated for each combination of ingress and egress ports for all the

combinations of:

Source MAC Addresses

Destination MAC Addresses

4094 VLANs (exclude reserved VIDs 0 and 4095) per port and VLAN untagged

Notes Test derived from switch requirement VLAN01 and VLAN02: The switch shall support

VLAN handling according to IEEE 802.1Q. The switch shall support at least x different

VLAN-IDs which can be chosen freely from the entire range of all available 4095 VLAN-

IDs.

OPEN Alliance


SWITCH_VLAN_02: VLAN Broadcast Traffic Forwarding

Synopsys The test shall ensure that the switch is able to successfully forward the broadcast traffic

from all configured VLANs in presence of line rate traffic, and drop the traffic received

from un-configured VLANs.


The DUT shall be capable of handling ARP request on some or all of its ports.


Test Input

Parameters

Source MAC Addresses are configured in either of these ways: read from the ECU Configuration file, if configured/available

MAC Addresses identified for testing purpose

Source IP Addresses are configured in either of these ways: read from the ECU Configuration file, if configured/available

IP Addresses identified for testing purpose

Destination IP Addresses are configured in either of these ways: read from the ECU Configuration file, if configured/available

IP Addresses identified for testing purpose

VLANs are read from the ECU Configuration File, if available.

Test 1. Create the test topology as shown in the Setup.

OPEN Alliance


Procedure

2. On each test port, iterate through each VLAN, source MAC, source IP and destination IP, and transmit ARP Request packets for each combination.

3. Verify that for each valid combination of destination IP and VLAN, an ARP Reply is received on the test device port that sent the ARP Request packet.

4. Verify that for each invalid VLAN, the ARP Request packet is dropped on the receiving ECU Switch Port.

5. Verify that for each combination of invalid destination IP and valid VLAN, the ARP Request is forwarded to each test device port belonging to that VLAN except the source port of ARP Request.

Pass criteria The DUT traffic counters match the expected test device traffic counters for each

combination of VLAN, Source MAC, Source IP and Destination IP.

Test

iterations

The test shall be repeated for each combination of ingress and egress ports for all the

combinations of:

Source MAC Addresses

Source IP Addresses

Destination IP Addresses

4094 VLANs (exclude reserved VIDs 0 and 4095) per port and VLAN untagged




IDs.

OPEN Alliance


SWITCH_VLAN_03: VLAN Multicast Traffic Forwarding

Synopsys The test shall ensure that the switch is able to forward multicast packets based on the

DUT configuration.


The DUT shall be capable of forwarding multicast message on all the ports belonging to a specific VLAN.


Test Input

Parameters

Source MAC Addresses are configured in either of these ways: o read from the ECU Configuration file, if configured/available o MAC Addresses identified for testing purpose

Source IP Addresses are configured in either of these ways: o read from the ECU Configuration file, if configured/available o IP Addresses identified for testing purpose

Destination Multicast IP Addresses o read from the ECU Configuration file, if configured/available o Multicast IP Addresses identified for testing purpose

Destination MAC Address is the multicast MAC derived from the multicast Destination IP

4094 VLANs (excluding reserved VLAN IDs 0 and 4095) per port and VLAN untagged

Frame size varies with each test cycle

OPEN Alliance


Bandwidth varies with each test cycle

Test

Procedure

1. Create the test topology as shown in the Setup. 2. Configure the test ports acting as Hosts to send join for the destination

multicast groups. 3. Verify that the test ports acting as Hosts are receiving queries and the test port

acting as Querier is receiving join/leave messages. 4. On test port acting as IGMP Querier, iterate through each VLAN, source MAC,

source IP and destination multicast IP (destination MAC is derived from destination IP), and transmit multicast IP traffic for each combination.

5. Verify that for each valid combination of source IP, destination IP and VLAN, the IP multicast traffic is correctly replicated only on those test ports that have receivers for the IGMP Group (identified by destination multicast IP). Note: The ECU switch can be a pure/hybrid L2 switch and in that case multicast forwarding will be enabled either by IGMP snooping or static multicast forwarding entries.

6. Verify that for each invalid VLAN, the IP multicast packet is dropped on the receiving ECU Switch Port.

7. Verify that for each combination of invalid destination multicast IP and valid VLAN, the IP traffic is not forwarded.

Pass criteria DUT traffic counters match the expected test device traffic counters for each

combination of VLAN, Source MAC, Source IP and Destination IP.

Test

iterations

Repeat steps 4 through 7 for each frame size and bandwidth that needs to be tested.




IDs.

OPEN Alliance


3.3 QoS Testing

SWITCH_QOS_01: VLAN Priority

Synopsys The test shall ensure that the switch is able to forward VLAN Priority tagged packets and

meet the latency and jitter limits.


The DUT shall be capable of forwarding VLAN and Priority tagged messages on all the ports.

Each test device port shall be able to generate and monitor VLAN and Priority tagged traffic streams for the entire valid range of VLAN (0-4094) and Priority (0-7).

Note: VLAN 0 is a special case. The packet is tagged with VLAN ID 0 so that the packet can be priority tagged. Usually the switch receiving these packets will strip the VLAN header and forward the packets based on VLAN priority.

The test device shall make these statistics available for each valid/allowed combination of VLAN and VLAN Priority:

o Frames/Bytes transmit/receive rate and traffic loss o Min/Max/Avg latency and jitter of the frames

Test setup All available (external) ports of the DUT are connected to the test system. The topology shown here is using three ports, but the test can be run with two ports or more than three ports as well.

Test Input

Parameters

Switch port Valid Source/Destination MAC Addresses are configured in either of these ways: a. read from the ECU Configuration file, if configured/available b. MAC Addresses identified for testing purpose

OPEN Alliance


Valid VLANs and VLAN Priorities are read from the ECU Configuration File, if available.

Test

Procedure

1. Create the test topology as shown in the Setup. 2. On each test device port (source port), iterate through each valid/allowed

source MAC, VLAN and VLAN Priority combination. For each such combination, send traffic towards each valid/allowed destination MAC on other test device ports (destination ports) that are connected to the ECU external ports.

3. Send, Capture and monitor the traffic on all the test device ports participating in the test.

Pass criteria 1. Verify that for each valid combination of VLAN and VLAN Priority "Packets

Received = Packets Expected and there is no traffic loss for all the

valid/allowed VLANs and VLAN Priorities.

2. Verify that for each VLAN Priority the packets are received within the expected

latency and jitter defined for that priority i.e. high priority traffic incurs less

latency and jitter compared to low priority traffic.

Test

iterations

Repeat steps 1 through 3 for different frame sizes and bandwidth including line rate to validate operation under different expected conditions.

Notes Test derived from switch requirement QOS-01 and QOS-02: The switch shall support

priority based quality of service according to IEEE 802.1Q. The switch shall support at

least x different level of priority.

OPEN Alliance


SWITCH_QOS_02: Strict Priority Algorithm

Synopsys The test shall ensure that the switch is able to forward VLAN and Priority tagged packets

using strict priority algorithm.


The DUT shall be capable of forwarding VLAN and Priority tagged message on all the ports using Strict Priority Algorithm.

The test device shall consist of two traffic generator ports and one traffic monitor port.

The traffic generator port shall be capable of generating VLAN and Priority tagged traffic streams for the entire valid range of VLAN (0-4094) and Priority (0-7).

Note: VLAN 0 is a special case. The packet is tagged with VLAN ID 0 so that the packet can be priority tagged. Usually the switch receiving these packets will strip the VLAN header and forward the packets based on VLAN priority.


o Frames/Bytes transmit/receive rate and traffic loss


Test Input

Parameters


OPEN Alliance



Test

Procedure

1. Create the test topology as shown in the Setup. 2. Iterate through all the valid VLAN IDs and configure test device Port P1 to send

100% of the line rate traffic towards test device Port P3. The VLAN priority shall not be the lowest allowed/configured VLAN Priority for the VLAN ID chosen.

Note: The VLAN Priority may not follow numerical order in terms of priority on many switches. For example, VLAN Priority 2 and 3 are higher in priority compared to other VLAN Priorities on AVB enabled switches.

3. Iterate through all the valid VLAN IDs and configure test device Port P2 to send 100% of the line rate traffic towards test device Port P3. The VLAN priority shall be lesser than the VLAN Priority configured on Port 1 for the corresponding VLAN ID.

4. Send traffic from test device traffic generator ports (P1 and P2) at the same time.

5. Capture and monitor the traffic on test device traffic receiver port (P3).

6. Repeat the steps above for all the allowed/valid VLAN IDs and VLAN Priorities such that the VLAN priority configured in step#2 is always greater than the VLAN priority configured in step#3.

Pass criteria 1. Verify that only the traffic sent from test device Port P1 is received on test

device Port P3 i.e. only the higher priority traffic is received and the traffic sent

from test device Port P2 is not received on test device Port P3.

2. Verify that there is no loss for the traffic sent from test device Port P1 i.e. high

priority traffic does not incur any loss.

Test

iterations

Repeat for each external DUT port that supports Strict Priority Algorithm.

Notes Test derived from switch requirement QOS-04: The switch shall support strict priority scheduling for each egress port.

OPEN Alliance


SWITCH_QOS_03: Weighted Round Robin Algorithm

Synopsys The test shall ensure that the switch is able to forward VLAN and Priority tagged packets

using Weighted Round Robin algorithm.


The DUT shall be capable of forwarding VLAN and Priority tagged message on all the ports using Weighted Round Robin Algorithm.

The test device consists of two traffic generator ports and one traffic monitor port.





Test Input

Parameters



Test 1. Create the test topology as shown in the Setup. 2. Configure Sender Port P1 to send 33% of the line rate traffic towards Receiver

OPEN Alliance


Procedure

Port P3. The traffic priority can be any allowed/configured VLAN Priority on the DUT.

3. Configure Sender Port P2 to send 66% of the line rate traffic towards Receiver Port P3. The traffic priority can be any allowed/configured VLAN Priority on the DUT and shall be greater than the priority configured in step#2.

4. Send traffic from sender ports at the same time.

5. Capture and monitor the traffic on the receiver port.

6. Repeat steps 2 through 5 for all valid/allowed VLAN IDs (VLAN ID >= 1 and VLAN ID

OPEN Alliance


SWITCH_QOS_04: VLAN Priority Overwrite Based on Ingress Priority

Synopsys The test shall ensure that the switch is able to overwrite the VLAN Priority with a

different VLAN Priority. If the packet is not VLAN-tagged, an 802.1Q VLAN Header with

default VLAN-ID and VLAN Priority will be added to the Ethernet Header.


The DUT shall be capable of forwarding VLAN and Priority tagged message on all the ports.

The test device consisting of at least one traffic generator port and at least one traffic monitor port.




The traffic monitor shall be able to compare the received VLAN Priority with the transmitted VLAN Priority.


Test Input

Parameters



Test

Procedure

1. Create the test topology as shown in the setup. 2. Configure test device port P1 to send multiple traffic streams for all the VLAN

priorities that are valid/allowed on the switch.

3. Configure test device port P2 to receive the traffic on another port.

OPEN Alliance


4. Send traffic from test device port P1.

5. Capture and monitor on test device port P2 that the traffic priority is remapped as per the priority re-mapping table.

6. Repeat above steps for all valid/allowed VLAN IDs (VLAN ID >= 1 and VLAN ID

OPEN Alliance


SWITCH_QOS_05: VLAN Priority Overwrite Based on Ingress Port

Synopsys The test shall ensure that the switch is able to overwrite the VLAN Priority with a

different VLAN Priority based on the ingress port. If the packet is not VLAN-tagged, an

802.1Q VLAN Header with default VLAN-ID and VLAN Priority will be added to the

Ethernet Header.


The DUT shall be capable of forwarding VLAN and Priority tagged message on all the ports.

The test device shall consist of two traffic generator ports and one traffic monitor port.




The traffic monitor shall be able to compare the received VLAN Priority with the transmitted VLAN Priority.

Test setup All available (external) ports of the DUT are connected to the test system. The topology shown here is using three ports, but the test can be run with more than three ports as well.

Test Input

Parameters


Valid VLANs and VLAN Priorities are read from the ECU Configuration File, if

OPEN Alliance


available.

Test

Procedure

1. Create the test topology as shown in the setup. 2. For each test device sender port, iterate through all the VLAN priorities that are

valid/allowed on the switch, and configure at least one traffic stream for each combination.

3. Send traffic from the test device sender ports.

4. Capture and monitor traffic on the receiver port and verify that the traffic priority is remapped as per the priority re-mapping table.

5. Repeat above steps for all valid/allowed VLAN IDs (VLAN ID >= 1 and VLAN ID

OPEN Alliance


3.4 General Switch Testing

SWITCH_GENERAL_01: Non-blocking Architecture

(Test derived from switch requirement GEN01: The switch shall use a non-blocking architecture.)

Synopsys The test shall ensure that the switch uses a non-blocking architecture, i.e. the switch is

capable of processing and forwarding all incoming data under full communication load

(i.e. full-duplex communication on all ports simultaneously).

Prerequisite

s

The DUT shall be operated in normal mode, i.e. the switch is configured and ready to

receive/forward Ethernet frames.


Test

Procedure

The test is executed in four test instances (a) (d).

The test system increases the communication traffic from 0 % to 100 % bus load.

(a) On all ports consecutively, with minimum frame length (b) On all ports consecutively, with maximum frame length (c) On all ports simultaneously, with minimum frame length (d) On all ports simultaneously, with maximum frame length

The bus load is increased in steps of 1 % per second.

With a given bandwidth of bitsPerSecond bit/s (e.g. 100 Mbit/s), the maximum number of

frames for a single link can be calculated by taking the Ethernet frame length including

the preamble and the minimum inter-frame gap into account:

= floor (

(8 + 14 + [] + 4 + 12) 8)

Number of frames with minimum payload length (46 byte):

= floor (

672)

Number of frames with maximum payload length (1500 byte):

= floor (

12304)

Pass criteria Verify that all frames transmitted by the test system are forwarded correctly and that no

frame is dropped by the switch during the runtime of test.

OPEN Alliance


Test

iterations

The test shall be repeated for each combination of ingress and egress ports.

Notes The maximum number of frames for 100 Mbit/s:

= 148809

= 8127

SWITCH_GENERAL_02: Store and Forward Operation

(Derived from requirement: GEN 02: The switch shall operate as store and forward switch.)

Synopsys The test shall ensure that the switch operates as a store and forward switch, i.e. the

switch shall store an incoming frame and wait until its complete reception and

syntactical verification (CRC check) before forwarding the frame.

Prerequisites The DUT shall be operated in normal mode, i.e. the switch is configured and ready to



Test

procedure

The test is executed in 8 test instances (1) (8).

The test system transmits a frame with a combination of the following characteristics:

Frame has

Minimum frame length (46 byte payload)

Maximum frame length (1500 byte payload)

Destination MAC address is

Already known to the switch

Unknown to the switch

Frame has

Valid CRC

Invalid CRC (last CRC bit flipped)

OPEN Alliance


The 6 characteristics result in 8 combinations that are tested in separate test instances:

(1) Minimum frame length, known MAC, valid CRC

(2) Maximum frame length, known MAC, valid CRC

(3) Minimum frame length, unknown MAC, valid CRC

(4) Maximum frame length, unknown MAC, valid CRC

(5) Minimum frame length, known MAC, invalid CRC

(6) Maximum frame length, known MAC, invalid CRC

(7) Minimum frame length, unknown MAC, invalid CRC

(8) Maximum frame length, unknown MAC, invalid CRC

Test instances (1) (4): Measure time tDelay between the end of the last CRC bit of the

incoming frame and the beginning of the first preamble bit of the corresponding

forwarded frame.

The frame transmission is repeated 100 times.

Pass criteria Test instances (1) (4): Verify that tDelay has a positive value, i.e. the transmission of the forwarded frame does not begin before the incoming frame was completely received by the switch. Verify that all frames are forwarded correctly and that no frame is dropped by the switch.

Test instances (3) (4): Verify that the frame forwarded or dropped according to the switch configuration regarding the handling of frames with unknown destination MAC addresses.

Test instances (5) (8): Verify that a frame with invalid CRC is dropped by the switch

and that no part of the frame is forwarded to any port.

Test

iterations

The test shall be repeated for each combination of ingress and egress switch ports.

Notes

OPEN Alliance


SWITCH_GENERAL_03: Jumbo Frames

(Derived from requirement: GEN 08: The switch may support jumbo frames. If supported it should be

possible to turn this off.)

Synopsys The test shall ensure that the switch forwards jumbo frames (i.e. frames with a payload

larger than 1500 byte) correctly if jumbo frames are supported and the feature is

enabled. If jumbo frames are not supported or the feature is disabled the switch shall

drop jumbo frames.

Prerequisites The DUT shall be operated in normal mode, i.e. the switch is configured and ready to


Only one of the test instances (a) or (b) is executed, depending on the capabilities and

the configuration of the switch.

(a) The switch supports jumbo frames and the feature is enabled (b) The switch does not support frames or the feature is disabled

For test instance (a) the manufacturer has to provide the maximum supported frame

size maxSupportedFrameSize.

The maximum number of supported payload bytes is

maxSupportedPayloadSize = maxSupportedFrameSize 18 bytes

For test instance (b) maxSupportedPayloadSize is set to 1500 bytes (according to

IEEE 802.3).


Test

procedure

The test system transmits multiple consecutive frames with alternating payload length

in pairs of one frame with a maximum regular payload length of 1500 byte (according to

IEEE 802.3) and one jumbo frame with increasing payload length.

The first jumbo frame is transmitted with a payload length of 1501 byte.

The n-th jumbo frame is transmitted with a payload length of 1500 + n byte.

The last jumbo frame is transmitted with a payload length of 65535 byte.

Pass criteria Verify that all frames with a payload length smaller or equal to maxSupportedPayloadSize are fo

open alliance automotive ethernet ecu test … alliance restriction level: public open alliance...

Documents