ISO 17458-3:2013
(Main)Road vehicles — FlexRay communications system — Part 3: Data link layer conformance test specification
Road vehicles — FlexRay communications system — Part 3: Data link layer conformance test specification
ISO 17458-3:2013 specifies the FlexRay protocol conformance test. This test verifies the conformance of FlexRay communication controllers with respect to ISO 17458-2. Some testability requirements are given and are applicable for FlexRay communication controllers to pass the conformance test.
Véhicules routiers — Système de communications FlexRay — Partie 3: Spécification d'essai de conformité de la couche de liaison de données
General Information
Standards Content (Sample)
INTERNATIONAL ISO
STANDARD 17458-3
First edition
2013-02-01
Road vehicles— FlexRay
communications system —
Part 3:
Data link layer conformance test
specification
Véhicules routiers — Système de communications FlexRay —
Partie 3: Spécification d'essai de conformité de la couche de liaison de
données
Reference number
©
ISO 2013
© ISO 2013
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO 2013 – All rights reserved
Contents Page
Foreword . iv
Introduction . v
1 Scope . 1
2 Normative references . 1
3 Terms, definitions, symbols and abbreviated terms . 1
3.1 Terms and definitions . 1
3.2 Symbols . 1
3.3 Abbreviated terms . 2
3.4 Functions. 4
4 Conventions . 4
5 Document overview . 5
6 General . 6
6.1 Test architecture . 6
6.2 Test implementation . 7
6.3 Internal RxDelay . 9
6.4 Analog delays . 9
6.5 Accepted deviations . 10
6.6 Testability requirements . 11
6.7 Test execution . 14
7 Conformance test cases . 16
7.1 General statements and test case structure. 16
7.2 Receive data . 23
7.3 CHI . 125
7.4 Clock synchronisation . 440
7.5 Wakeup . 530
7.6 Startup . 568
7.7 Miscellaneous . 672
7.8 Optional TT-E feature . 820
7.9 Preambles . 846
8 Configuration . 854
8.1 Basic configuration . 854
8.2 Standard modifications . 859
9 Static test cases . 861
9.1 Electrical interface . 861
9.2 Protocol parameter . 861
Annex A (normative) Technical data for the electrical interface of a FlexRay Communication
Controller V3.0 . 862
Annex B (normative) Technical data for the protocol parameter of a FlexRay Communication
Controller V3.0 . 864
Bibliography . 865
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies
(ISO member bodies). The work of preparing International Standards is normally carried out through ISO
technical committees. Each member body interested in a subject for which a technical committee has been
established has the right to be represented on that committee. International organizations, governmental and
non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the
International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of technical committees is to prepare International Standards. Draft International Standards
adopted by the technical committees are circulated to the member bodies for voting. Publication as an
International Standard requires approval by at least 75 % of the member bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO shall not be held responsible for identifying any or all such patent rights.
ISO 17458-3 was prepared by Technical Committee ISO/TC 22, Road vehicles, Subcommittee SC 3,
Electrical and electronic equipment.
ISO 17458 consists of the following parts, under the general title Road vehicles — FlexRay communications
system:
Part 1: General information and use case definition
Part 2: Data link layer specification
Part 3: Data link layer conformance test specification
Part 4: Electrical physical layer specification
Part 5: Electrical physical layer conformance test specification
iv © ISO 2013 – All rights reserved
Introduction
The FlexRay communications system is an automotive focused high speed network and was developed with
several main objectives which were defined beyond the capabilities of established standardized bus systems
like CAN and some other proprietary bus systems. Some of the basic characteristics of the FlexRay protocol
are synchronous and asynchronous frame transfer, guaranteed frame latency and jitter during synchronous
transfer, prioritization of frames during asynchronous transfer, single or multi-master clock synchronization,
time synchronization across multiple networks, error detection and signalling, and scalable fault tolerance.
The FlexRay communications system is defined for advanced automotive control applications. It serves as a
communication infrastructure for future generation high-speed control applications in vehicles by providing:
A message exchange service that provides deterministic cycle based message transport;
Synchronization service that provides a common time base to all nodes;
Start-up service that provides an autonomous start-up procedure;
Error management service that provides error handling and error signalling;
Wakeup service that addresses the power management needs.
Since start of development the automotive industry world wide supported the specification development. The
FlexRay communications system has been successfully implemented in production vehicles today.
The ISO 17458 series specifies the use cases, the communication protocol and physical layer requirements of
an in-vehicle communication network called "FlexRay communications system".
This part of ISO 17458 has been established in order to define the protocol conformance test case
requirements.
To achieve this, it is based on the Open Systems Interconnection (OSI) Basic Reference Model specified in
ISO/IEC 7498-1 and ISO/IEC 10731, which structures communication systems into seven layers. When
mapped on this model, the protocol and physical layer requirements specified by ISO 17458 are broken into:
Diagnostic services (layer 7), specified in ISO 14229-1 [14], ISO 14229-4 [16];
Presentation layer (layer 6), vehicle manufacturer specific;
Session layer services (layer 5), specified in ISO°14229-2 [15];
Transport layer services (layer 4), specified in ISO 10681-2 [5];
Network layer services (layer 3), specified in ISO 10681-2 [5];
Data link layer (layer 2), specified in ISO 17458-2, ISO 17458-3;
Physical layer (layer 1), specified in ISO 17458-4, ISO 17458-5;
in accordance with Table 1.
Table 1 — FlexRay communications system specifications applicable to the OSI layers
ISO 17458 FlexRay Vehicle manufacturer
Applicability OSI 7 layers
communications system enhanced diagnostics
Application (layer 7) vehicle manufacturer specific ISO 14229-1, ISO 14229-4
Presentation (layer 6) vehicle manufacturer specific vehicle manufacturer specific
Seven layer
Session (layer 5) vehicle manufacturer specific ISO 14229-2
according to
ISO 7498-1
Transport (layer 4) vehicle manufacturer specific
and
ISO 10681-2
ISO/IEC
Network (layer 3) vehicle manufacturer specific
Data link (layer 2) ISO 17458-2, ISO 17458-3
Physical (layer 1) ISO 17458-4, ISO 17458-5
Table 1 shows ISO 17458 Parts 2 – 5 being the common standards for the OSI layers 1 and 2 for the FlexRay
communications system and the vehicle manufacturer enhanced diagnostics.
The FlexRay communications system column shows vehicle manufacturer specific definitions for OSI layers
3 – 7.
The vehicle manufacturer enhanced diagnostics column shows application layer services covered by
ISO 14229-4 which have been defined in compliance with diagnostic services established in ISO 14229-1, but
are not limited to use only with them. ISO 14229-4 is also compatible with most diagnostic services defined in
national standards or vehicle manufacturer's specifications. The presentation layer is defined vehicle
manufacturer specific. The session layer services are covered by ISO 14229-2. The transport protocol and
network layer services are specified in ISO 10681.
vi © ISO 2013 – All rights reserved
INTERNATIONAL STANDARD ISO 17458-3:2013(E)
Road vehicles — FlexRay communications system — Part 3:
Data link layer conformance test specification
1 Scope
This part of ISO 17458 specifies the FlexRay protocol conformance test. This test verifies the conformance of
FlexRay communication controllers with respect to ISO 17458-2.
Some testability requirements are given in 6.2.2.3 and 6.6 and are applicable for FlexRay communication
controllers to pass the conformance test
2 Normative references
The following referenced documents are indispensable for the application of this document. For dated
references, only the edition cited applies. For undated references, the latest edition of the referenced
document (including any amendments) applies.
ISO 17458-2, Road vehicles — FlexRay communications system — Part 2: Data link layer specification
ISO 17458-4, Road vehicles — FlexRay communications system — Part 4: Electrical physical layer
specification
3 Terms, definitions, symbols and abbreviated terms
3.1 Terms and definitions
For the purposes of this document, the terms and definitions defined in ISO 17458-2 and ISO 17458-4 apply.
3.2 Symbols
delta
∆
Element, lower-case epsilon
∈
ξ Xsi
µT microtick
σT gdSampleClockPeriod (= Sampletick)
modification of cycle length due to calculated rate correction (equal to zRateCorrection, used in
t
RC
figures of "Clock synchronisation")
modification of cycle length due to calculated offset correction (equal to zOffsetCorrection,
t
OC
used in figures of "Clock synchronisation")
φ , φ analogue delays (see 6.4 )
Rx Tx
ξ, ξ allowed deviation from theoretical results due to LT-IUT jitter (see 6.5)
IUT
3.3 Abbreviated terms
BC basic configuration
BD bus driver
BSS byte start sequence
CAS collision avoidance symbol
CC communication controller
CE communication element
CHI controller host interface
CHIRP channel idle recognition point
CRC cyclic redundancy code
DC dual channel
DTS dynamic trailing sequence
FES frame end sequence
FIFO first in first out
FPGA field programmable gate array
FSS frame start sequence
ID identifier
IP intellectual property
IUT implementation under test
LT lower tester
MT macrotick
MTS media access test symbol
NIT network idle time
NM network management
PE protocol engine
POC protocol operation control
RTL register transfer level
2 © ISO 2013 – All rights reserved
RxD receive data signal from bus driver
SC single channel
TE test execution
TSS transmission start sequence
TT-D time triggered distributed
TT-E time triggered external
TxD transmit data signal from CC
TxEN transmit data enable not signal from CC
UT upper tester
WUDOP wakeup during operation pattern
WUP wakeup pattern
WUS wakeup symbol
POC states:
C POC:config
CSCC POC:coldstart consistency check
CSCR POC:coldstart collision resolution
CSG POC:coldstart gap
CSJ POC:coldstart join
CSL POC:coldstart listen
DC POC:default config
H POC:halt
ICC POC:integration consistency check
ICSC POC:integration coldstart check
IL POC:integration listen
IS POC:initialize schedule
NA POC:normal active
NP POC:normal passive
R POC:ready
3.4 Functions
TruncateTowardsZero: function returns the integer part of a number without its fractional digits
(= sign(x) * floor(|x|))
4 Conventions
ISO 17458 are based on the conventions specified in the OSI Service Conventions (ISO/IEC 10731) as they
apply for physical and data link layer (protocol).
4 © ISO 2013 – All rights reserved
5 Document overview
Figure 1 depicts the FlexRay document reference according to OSI model.
ISO 17458-1
FlexRay communications
system - General
information and
use case definition
Vehicle Manufacturer
Enhanced Diagnostics
specific
ISO 14229-1 UDS Vehicle
ISO 14229-4
subset manufacturer
Specification and
OSI Layer 7
UDSonFR
requirements specific
Application
Vehicle Vehicle
manufacturer manufacturer
OSI Layer 6
specific specific
Presentation
ISO 14229-2 UDS ISO 14229-2 UDS Vehicle
1 : 1
Session layer Session layer manufacturer
OSI Layer 5
services services specific
Session
Standardized Service Primitive Interface
FlexRay communications system
Vehicle
manufacturer
OSI Layer 4
specific
Transport
ISO 10681-2
Communication on
FlexRay –
Communication
layer services
Vehicle
manufacturer
OSI Layer 3
specific
Network
ISO 17458-3
ISO 17458-2
FlexRay
FlexRay
communications system
OSI Layer 2
communications system
– Data link layer
Data Link
– Data link layer
conformance test
specification
specification
ISO 17458-5
ISO 17458-4
FlexRay
FlexRay
communications system
communications system
OSI Layer 1
- Electrical physical
- Electrical physical
Physical
layer conformance test
layer specification
specification
Figure 1 — FlexRay document reference according to OSI model
6 General
6.1 Test architecture
This part of ISO 17458 is based on a test architecture as shown in Figure 2, which follows the ISO 9646
standard. The implementation under test (IUT) is the FlexRay CC. The upper tester (UT) is connected to the
FlexRay controller host interface (CHI) of the IUT and the CHI is device specific. The lower tester (LT) is
connected to the FlexRay physical layer interface of the IUT and ISO 17458-4 describes this interface. The
test coordination procedure controls the UT and the LT.
In a hardware-based test environment (see 6.2.2), the FlexRay CC can be an “embedded” FlexRay CC
meaning that CC is embedded in a microcontroller. In this case, the CHI (i.e., the upper tester interface) is
between the embedded FlexRay CC and the microcontroller and in order to get access to the CHI, the upper
tester may be partly distributed to the microcontroller.
The test architecture shown in Figure 2 is suitable for testing one FlexRay CC.
Upper Tester
Test Coordination
CC
IUT
Procedure
Lower Tester
Figure 2 — Standard test architecture
6 © ISO 2013 – All rights reserved
There are some optional test cases in this part of ISO 17458 which tests the optional TT-E feature by using a
pair of FlexRay CCs, namely a source CC and a sink CC, which are connected via the time gateway interface.
Here, the IUT is the pair of connected FlexRay CCs. To test the TT-E feature, the test architecture as shown in
Figure 3 is proposed. The upper tester and lower tester are connected to both FlexRay CCs and the test
coordination procedure controls the upper and lower tester.
Upper Tester
Upper Tester
Test Coordination
IUT Source CC Sink CC
Procedure
Time Gateway
Interface
Lower Tester
Lower Tester
Figure 3 — Test architecture for the TT-E option
6.2 Test implementation
6.2.1 General
The test cases and the proposed test architecture of this specification can be either implemented in a
hardware-based environment or in a simulation-based environment. In the following, both environments are
described.
6.2.2 Hardware-based test implementation
6.2.2.1 IUT
In a hardware-based test implementation, the IUT is a physical device. The IUT can be either a standalone
FlexRay CC, an embedded FlexRay CC, or a FlexRay CC programmed in an FPGA. For testing the optional
TT-E feature, the IUT consists of a pair of connected FlexRay CCs.
6.2.2.2 Lower tester
The electrical characteristics of the lower tester shall follow the electrical characteristics of the interface
between the FlexRay CC and the FlexRay Bus Driver on the Bus Driver side. This interface is described in
ISO 17458-4. The requirements on the lower tester in a hardware-based test environment, including the
electrical characteristics, are listed in Table 2. It is not advised to use any extra circuits (e.g., level
shifters) between the IUT's FlexRay CC and the lower tester.
Table 2 — Requirements on the lower tester in a hardware-based test environment
Relevant Parameter name used in
Description Min Max Unit
signal ISO 17458-4
Input capacitance TxD, TxEN C_BDTxD - 10 pF
Threshold for detecting logical high TxD, TxEN uBDLogic_1 - 60 %
Threshold for detecting logical low TxD, TxEN uBDLogic_0 40 - %
Voltage reference for logical high and low TxD, TxEN, uVDIG same as IUT V
RxD
Sample Rate TxD, TxEN N/A 160 - MHz
Asymmetry RxD see ISO 17458-4: measured at - 2 ns
50 % uVDIG and 25 pF load
Sum of rise and fall time @ 15 pF load RxD dBDRxDR15 + dBDRxDF15 - 13 ns
Difference of rise and fall time @ 15 pF load RxD | dBDRxDR15 – dBDRxDF15 | - 5 ns
Sum of rise and fall time @ 25 pF load RxD dBDRxDR25 + dBDRxDF25 - 16,5 ns
Difference of rise and fall time @ 25 pF load RxD | dBDRxDR25 – dBDRxDF25 | - 5 ns
Frequency of FlexRay clock, provided to IUT clk N/A - 80 MHz
Precision of FlexRay clock, provided to IUT clk N/A - 500 ppm
6.2.2.3 Clock synchronisation
Several test cases require the synchronisation between the IUT and the test environment such that random
clock deviations can be excluded and the occurrence time of a sampletick can be determined within one
sampletick accuracy.
Therefore it is required that the LT provides a clock signal (called “FlexRay clock”) to the IUT. The LT shall use
the FlexRay clock as a basis for FlexRay bus stimuli of the RxD signal and for sampling the TxD and TxEN
signals. The IUT shall also use the FlexRay clock for FlexRay transmission and reception. Existing PLLs in the
IUT need to be bypassed or programmed not to multiply. If the IUT uses an own clock source or an active PLL,
then there might be the risk of failing some test cases.
Some requirements on the FlexRay clock signal are listed in Table 2. In addition, those frequencies shall be
supported, which can be derived from 80 MHz by integer division. The FlexRay clock shall run continuously in
order to be able to test embedded FlexRay CCs, where the FlexRay clock signal is also used to for clocking
the host microcontroller.
6.2.3 Simulation-based test implementation
In a simulation-based test implementation, the IUT is described in a hardware description language typically
on register transfer level (RTL), e.g., in SystemVerilog code or VHDL code. The IUT is a FlexRay CC,
including message buffers and FIFO. For testing the optional TT-E feature, the IUT consists of a pair of
connected FlexRay CCs. The test environment (upper tester, lower tester, and test coordination procedure)
and the test cases exist as software only. Executing a test case in a simulation-based test implementation
means to load all necessary parts (IUT, test environment, test case) in an RTL simulator and then to run the
simulation.
In the simulation-based test implementation, the clocks of the IUT and the LT have no deviation from the
nominal frequency and also have no jitter. Therefore, no requirements on the clock synchronisation between
the LT and the IUT (as listed in 6.2.2.3 for the hardware-based test implementation) are given for the
8 © ISO 2013 – All rights reserved
simulation-based test implementation. However, ξ and ξ (see 6.5) have to be considered in the simulation-
IUT
based test implementation.
6.3 Internal RxDelay
The parameter adInternalRxDelay is implementation specific and has an allowed range between 1 and
4 sampleticks ISO 17458-4. All basic configurations (see clause 8) assume adInternalRxDelay to be
4 sampleticks. In order to compensate between the implementation specific value of adInternalRxDelay and
the assumed value of 4 sampleticks, a delay compensation shall be integrated in the RxD signal between the
LT and the IUT. The delay compensation shall have a delay of 4-dt [sampleticks], and dt is the IUT's actual
value of adInternalRxDelay. The delay compensation shall be applied in the hardware-based test
implementation and in the simulation-based test implementation. Figure 4 gives an example how to implement
the delay compensation in a hardware-based test implementation.
Please note that in the test cases, the time interval between IUT's frame and LT's frame are measured at the
test points marked in Figure 4. Therefore the delay compensation is not to be considered in test steps like “It is
verified (LT) that the interval between the IUT's frames in slot 1 and LT's frame slot 2 is x µT.”.
Figure 4 depicts the proposal for compensation of adInternalRxDelay in a hardware-based test
implementation.
TestPoints for
Measurement
TxD
TxEN
LT IUT
M
RxD
U
X
FF FF
FF
Sample
IUT’s actual
Clock adInternalRx
Delay
Delay Compensation
Figure 4 — Proposal for compensation of adInternalRxDelay in a hardware-based test implementation
6.4 Analog delays
Analog delays of the IUT appear in the signal paths between the physical pads of the device and the flip flops
of the FlexRay CC. In ISO 17458-4, the analog delays are captured in the following parameters: dCCRxD01,
dCCRxD10, dCCTxD01, dCCTxD10, dCCTxEN10 or dCCTxEN01. In this conformance test specification, the
following two analog delays are defined: φ is the analog delay on the reception path, and φ is the analog
Rx Tx
delay on the transmission path. In the hardware-based test implementation, the analog delays are determined
as follows:
φ ∈ [ 0; max{dCCRxD01, dCCRxD10} ]
Rx
φ ∈ [ 0; max{dCCTxD01, dCCTxD10, dCCTxEN10, dCCTxEN01} ]
Tx
Here, the parameters dCCRxD01, dCCRxD10, dCCTxD01, dCCTxD10, dCCTxEN10 or dCCTxEN01 have the
maximal values as defined in ISO 17458-4.
In the simulation-based test environment, there are no physical pads but only the FlexRay CC itself simulated.
Therefore, the analog delays can be set to 0 here:
φ = 0
Rx
φ = 0
Tx
6.5 Accepted deviations
Despite the synchronisation of the IUT and the test environment described in 6.5 there is a remaining
deviation between the LT and the IUT. A sample point at the LT does not necessarily cause a sample point at
the IUT at the same moment since the clock signal stemming from the test environment can be delayed within
the IUT due to the clock tree. Due to this we have to assume that the IUT's sample point occurs anywhere
within two sample points of the LT and could also have a small amount of jitter.
Figure 5 depicts the shift of IUT sampletick relative to LT's signal.
Sync Edge End Edge
Signal is 4 sample ticks long
LT signal
Perfect IUT
Sample ticks
8 1 2 3 4 5 6 7 8 1
Worst IUT
Sample ticks
1 2 3 4 5 6 7 8 1
The signal can now be seen as 3, 4 or 5 samples if minimal jitter exists:
8 1 2 3 4 5 6 7 8 1
=> 3 samples
1 2 3 4 5 6 7 8 1
=> 5 samples
Figure 5 — Shift of IUT sampletick relative to LT's signal
Figure 5 shows that in the worst case this can lead to a situation where the IUT samples directly on the edges
of the LT's signal. In that case even a small amount of jitter can cause a 4 sample signal of the LT to be seen
as a 5 sample signal (line 3 of Figure 5) or a 3 sample signal (line 4 of Figure 5) by the IUT. This of course has
consequences for the precision test cases can achieve and also on the results of the IUT's clock
synchronisation algorithm.
The imprecision seen in Figure 5 prevents exact testing of the bit strobing point. Sending a 4 sample long
pattern can, as has been shown, either be seen at the bit strobing point (sample point 5) or not. Similarly a 5
10 © ISO 2013 – All rights reserved
sample long pattern could not be seen at the bit strobing point. Thus 4 and 5 sample long LOW patterns can
not be used to verify if bit strobing correctly happens at sample 5.
Similar the clock synchronisation mechanism of FlexRay can be disturbed by this sample point deviations and
cause a slight de-synchronisation of IUT and test environment. Figure 5 shows that a sync edge which arrives
at the same time as a sampletick can either be seen already by this sampletick (line 4) or only by the next one
(line 3). If this happens to the FSS/BSS sync edge, the time reference point of the frame shifts (see
ISO 17458-2 Figure "Time reference point definitions"). If due to jitter this time reference point shifts into
different directions in consecutive cycles, the IUT will erroneously determine the need to correct its macrotick
clock rate and phase (=offset). This means that all higher level events (e.g. slot starts, cycle starts, .) that
depend on macroticks can be slightly unaligned between IUT and test environment. This has to be taken into
account in the test cases.
To address the deviations introduced by the unaligned FlexRay clock correction mechanism, ξ is introduced,
IUT
with the allowed range of:
ξ ∈[-6;5]µT
IUT
ξ expresses the range of deviation that can be introduced in signals coming from the IUT to the LT as well
IUT
as the status variables related to clock correction sent from the IUT to the UT. The maximum tolerances for
IUT signals and clock correction related variables as seen by the LT and UT shall be limited to. The test
environment and setup shall minimize those tolerances as much as possible. Please note that ξ is only a
IUT
valid deviation if the FlexRay clock correction is involved in the measurement in question. For example it is not
to be applied to tests of the decoder or to tests within the WAKEUP period.
In addition, the LT introduces a deviation when measuring due to the granularity of measurements as well as
some inherent inexactness. Thus every time measurement of the IUT by the LT is assumed to have a possible
deviation of:
ξ∈[-1;1]µT
ξ is to be added as tolerance to each traffic measurement at the IUT's interface to the LT.
6.6 Testability requirements
6.6.1 General
Since ISO 17458-2 lacks some requirements which are necessary for defining precise test cases (e.g., CHI
delays), this subclause specifies such testability requirements.
NOTE subclause 6.2.2.3 also gives a testability requirement in a hardware-based test implementation. A FlexRay CC,
which does not meet the testability requirements, runs the risk of failing the test cases.
6.6.2 CHI delay constraints
ISO 17458-2 states for the controller host interface (CHI) that “due to implementation constraints the CHI may
add product specific delays for data or control signals exchanged between the host and the protocol engine”.
The maximum value of some CHI delays are to be known for testing a FlexRay CC. Therefore, Table 3
specifies the necessary maximum values and the maximum values are based on the time t at which the
event / the variable change happens in the protocol engine. It is assumed that if a host requests one of these
values from the CHI anywhere between (t + Max. delay) and the earliest visibility time of the next change of
the value, the host will receive the correct value.
NOTE the delay values in Table 3 do not include the time required to transfer the data from the CHI to the host. They
define the earliest point in time when a host might access the data and is guaranteed to receive the updated value in
1)
response. It is expected that the CHI transfers the requested data immediately with no delay except that inherent in the
CHI-host interface (e.g. due to round trip times, bandwidth restrictions, parallel ongoing transfers, .). Should the
underlying value changes during the transfer (e.g. during the transfer of payload a new frame arrives for the slot) it is the
task of the CHI to ensure the atomicity of the transfer.
In order to be able to pass the test cases of this specification, the CHI delays of a FlexRay CC shall follow the
maximum values and it is highly recommended that the delays are much below the maximum values.
Table 3 — Maximum delay allowed to occur in the CHI
Parameter as defined
Earliest visible Maximum delay in CHI Remarks
in ISO 17458-2
Thus for testing purposes it can not be
CHI commands like 2 000 μT after command assumed that the PE will react
NA
RUN, ALL_SLOTS… submission according to the new state until the
delay has passed.
Several state changes are defined to
earliest allowed happen sometime within the NIT. For
Protocol operation 500 μT after latest allowed
state change these earliest and latest allowed state
control status state change time in PE
time change time differ (typically to beginning
and end of NIT).
Wakeup and startup
at state change 500 μT after state change ---
status
The repeated consecutive reads are not
½ MT, minimum 20 μT, after guaranteed, i.e. reading at macrotick x
vMacrotick at macrotick
macrotick and then immediately again does not
guarantee a result of x or x + 1.
vCycleCounter at cycle start 500 μT after cycle start ---
at slot start or 50 μT after PE slot counter
vSlotCounter A/B ---
segment start change
vInterimRateCorrection
at NIT start 500 μT after end of cycle ---
vInterimOffsetCorrection
sync frame overflow: 500 μT
after slot or segment boundary;
pLatestTx: 500 μT after
at event
various error indicators dynamic segment end; ---
occurrence
transmission across boundary:
500 μT after slot or segment
boundary
Synchronisation frame 10 MT after the start of offset
start of NIT for non TT-E coldstart nodes
status correction phase
1 µT before cycle
Startup frame status 10 MT after start of cycle for TT-E coldstart nodes only
start
10 MT after the start of offset
Startup frame status start of NIT ---
correction phase
Symbol window status at symbol 500 µT after symbol window
---
vSS window end end
at NIT end (=
NIT status vSS start of next 500 µT after start of cycle ---
cycle)
1) However if there is a transfer delay greater than a given verification window, the access time shall be considered by
the UT.
12 © ISO 2013 – All rights reserved
Parameter as defined
Earliest visible Maximum delay in CHI Remarks
in ISO 17458-2
This could mean that it is not checkable
for empty dynamic slots. But this is not
Aggregated channel at each slot and
500 μT after each boundary necessary for the conformance test as
status segment end
that only checks this value during the
NIT.
Dynamic segment at dynamic 500 μT after dynamic segment
---
status segment end end
2 * gdStaticSlot for static slots
at slot end / or 2 000 μT for dynamic slots, Definition is to keep it in accordance
Transmit buffer status
segment end counting from the slot boundary with payload.
at the end of the respective slot
2 * gdStaticSlot for static slots
at slot end / or 2 000 μT for dynamic slots,
Slot status data ---
segment end counting from the slot boundary
at the end of the respective slot
2 000 µT is provided for the dynamic
segment where slots can become as
2 * gdStaticSlot for frames short as 2 MT, the duration of 2 static
received in the static segment slots is used to scale the available time
at complete
or 2 000 μT for frames received according to the payload length used.
Frame contents data (valid!) frame
in the dynamic segment, Counting from the end of the slot
arrival
counting from the slot boundary means, that e.g. the payload of a valid
following the valid frame frame arriving in slot 1 could be
accessed the earliest after the end of
slot 3.
at slot and
segment end on 2 000 μT after complete arrival
Queued receive buffers ---
complete arrival of a valid frame
of a valid frame
at event
Interrupt service 100 µT after event occurrence ---
occurrence
at each update
Accrued network 500 µT after each update (see
(see ---
management vector ISO 17458-2)
ISO 17458-2)
6.6.3 Consequences for interpretation of test steps
The upper limits of the CHI delays of Table 3 are used in the test cases explicitly to determine the earliest
point in time a change of a CHI parameter can be checked / verified by the UT and the earliest point in time
the LT can expect the IUT to show appropriate behaviour due to commands from the UT.
In several test cases, esp. in the preambles, the UT issues several CHI commands in short sequence, mostly
to configure the IUT. In order to reduce the runtime of the test cases, the upper limits of the CHI delays are not
explicitly stated here, but it is assumed that the UT takes care of the CHI delays and delays any further
commands to the IUT until the first one was executed.
In the beginning of each test case the IUT is reset by the UT. In this situation it is the responsibility of the test
environment to ensure that the IUT has completed its reset before further actions are performed.
6.6.4 Special handling of vMacrotick counter
The delay specification for vMacrotick given above results in a 20 µT window for reading the counter in case
the macrotick length is configured as 40 µT. But additionally the IUT's macrotick can shift around the LT's
macrotick by up to ξ µT with ξ ∈ [-6;5] (for definition of ξ see 6.5). As such the validity window shrinks
IUT IUT IUT
by 11 µT, requiring the UT to hit a 9 µT window to read the vMacrotick counter correctly in all circumstances, a
non-trivial task.
To ease this problem, additional information about the delay and the jitter for accessing the vMacrotick counter
shall be provided. For example, the additional information could be “the vMacrotick counter is valid at the CHI
from 5 µT after the IUT's macrotick to 2 µT after the next IUT's macrotick”. For a macrotick length of 40 µT this
results in a validity window of 37 µT, which, after reduction for ξ , provides the UT with a 26 µT window.
IUT
6.7 Test execution
6.7.1 Single channel CC
For a single channel CC all test cases with “SC” applicability and all test cases “SC, DC” applicability shall be
executed in two runs: one run with pChannels = A and one run with pChannels = B. Subclause 7.1 gives more
details on the “applicability” label per test case.
Total number of test cases for a single channel CC: 391 (this is the sum of 5 "SC" test cases and 386 "SC,
DC" test cases).
6.7.2 Dual channel CC
For a dual channel CC, all test cases with “DC” applicability and all test cases with “SC, DC” applicability shall
be executed in one run with pChannels = A&B. In addition, all test cases with “SC” applicability and all test
cases with “SC, DC” applicability shall be executed in two runs: one run with pChannels = A and one run with
pChannels = B.
Total number of test cases for a dual channel CC: 420 (this is the sum of 5 "SC" test cases, 386 "SC, DC" test
cases, and 29 "DC" test cases).
6.7.3 Optional TT-E feature
TT-E stands for time triggered external synchronisation method. To test the optional TT-E feature requires a
pair of CCs, which are connected by the time gateway interface. One CC is the time gateway source, the other
CC is the time gateway sink. See clause 6 and Figure 3. Each CC can be either a single channel or a dual
channel implementation. If a pair of connected CCs claims to support the TT-E option, all test cases with “TT-
E” applicability shall be executed.
Total number of test cases for the TT-E option: 12
All other test cases shall be executed for each of the two CCs according to 6.7.1 and 6.7.2.
Depending on whether the source and sink CC is a single channel or a dual channel CC, Table 4 gives the
required runs of the TT-E test cases and the corresponding set “pChannels “of configurations of the
Source,Sink
parameter pChannels for both CCs. For example, only row 1 in Table 4 has to be considered if both CCs are
single channel CCs, only row 4 has to be considered of both CCs are dual channel CCs. Notation used for the
set pChannels :“(pChannels for Source:CC, pChannels for Sink:CC)”. For example “(A,A&B)” means
Source,Sink
that the source CC is set to single channel mode with pChannels=A and the sink CC is set to dual channel
mode with pChannels=A&B.
14 © ISO 2013 – All rights reserved
Table 4 — Configurations of pChannels for both CCs, depending on whether each CC (Source and
Sink) is a single channel or a dual channel one
Number of runs of the “TT-E” tests and the set of configurations for
Row Source CC Sink CC
pChannels
1 single channel single Four runs with pChannels = {(A,A),(A,B),(B,A),(B,B)}
Source,Sink
channel
2 single channel dual channel Six runs with pChannels = {(A,A),(A,B),(B,A),(B,B),(A,A&B),(B,A&B)}
Source,Sink
3 dual channel single Six runs with pChannels = {(A,A),(A,B),(B,A),(B,B),(A&B,A),(A&B,B)}
Source,Sink
channel
4 dual channel dual channel Nine runs with pChannels =
Source,Sink
{(A,A),(A,B),(B,A),(B,B),(A,A&B),(B,A&B),(A&B,A),(A&B,B),(A&B,A&B)}
NOTE The following statement is valid for both CCs (source and sink CC): If the CC is a dual channel CC and it is set
to single channel mode (pChannels=A or pChannels=B), the not configured channel shall be tested for inactivity. If
pChannels=A, channel B is “not configured”; if pChannels=B, channel A is “not configured.”
6.7.4 Requirements on clock synchronisation and wakeup
The following shall be considered in dual channel test execution (i.e., if pChannels = A&B):
All test cases specified in 7.4 shall be executed in three instances: in instance 1 the LT simulates its
frames on channel A, in instance 2 the LT simulates its frames on channel B, and in instance 3 the LT
simulates its frames on both channels.
All test cases specified in 7.5 shall be executed twice, first with pWakeupChannel = A and second with
pWakeupChannel = B.
Exceptions to this and additional instructions in dual channel test executions are specified per test case and at
the beginning of 7.4 and 7.5.
6.7.5 Basic configurations
All test cases, which are to be executed according to 6.7.1 through 6.7.3, shall be executed with all five basic
configurations 1a, 1b, 2a, 2b, and 3. The five basic configurations represent the combination of mandatory bit
rates and microtick lengths.
Table 5 holds the simplified five basic configurations and Clause 8 lists the basic configurations in detail with
all relevant parameters.
Table 5 — Simplified basic configurations: bit rates and microtick lengths
Basic Configuration 1a 1b 2a 2b 3
Bit Rate [Mbit/s] 10 10 5 5 2,5
pdMicrotick [µs] 0,025 0,0125 0,025 0,05 0,05
6.7.6 Modifications, variants, instances
A test case can have modifications of the basic configurations, va
...
INTERNATIONAL ISO
STANDARD 17458-3
First edition
2013-02-01
Road vehicles — FlexRay
communications system —
Part 3:
Data link layer conformance test
specification
Véhicules routiers — Système de communications FlexRay —
Partie 3: Spécification d'essai de conformité de la couche de liaison de
données
Reference number
©
ISO 2013
This CD-ROM contains the publication ISO 17458-3:2013 in portable document format (PDF), which can be
viewed using Adobe® Acrobat® Reader.
Adobe and Acrobat are trademarks of Adobe Systems Incorporated.
© ISO 2013
All rights reserved. Unless required for installation or otherwise specified, no part of this CD-ROM may be reproduced, stored in a retrieval
system or transmitted in any form or by any means without prior permission from ISO. Requests for permission to reproduce this product
should be addressed to
ISO copyright office Case postale 56 CH-1211 Geneva 20 Switzerland
Internet copyright@iso.org
Reproduction may be subject to royalty payments or a licensing agreement.
Violators may be prosecuted.
Published in Switzerland
ii © ISO 2013 – All rights reserved
Installation
If this publication has been packaged as a zipped file, do NOT open the file from the CD-ROM, but copy it to
the desired location in your local environment. Once the
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...