ISO 17458-2:2013

Road vehicles — FlexRay communications system — Part 2: Data link layer specification

ISO 17458-2:2013 specifies the FlexRay communication protocol which is specified for a dependable automotive network. 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.

Véhicules routiers — Système de communications FlexRay — Partie 2: Spécification de la couche de liaison de données

General Information

• Status: Published
• Publication Date: 20-Jan-2013
• ICS: 43.040.15 - Car informatics. On board computer systems
• Technical Committee: ISO/TC 22/SC 31 - Data communication
• Drafting Committee: ISO/TC 22/SC 31/WG 3 - In-vehicle networks
• Current Stage: 9093 - International Standard confirmed
• Start Date: 02-Jul-2025
• Completion Date: 13-Dec-2025

Standards Content (Sample)

INTERNATIONAL ISO
STANDARD 17458-2
First edition
2013-02-01
Road vehicles— FlexRay
communications system —
Part 2:
Data link layer specification
Véhicules routiers — Système de communications FlexRay —
Partie 2: Spécification 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 [e-mail]
Web www.iso.org
Published in Switzerland
ii © ISO 2013 – All rights reserved

Contents Page
Foreword . v
Introduction . vi
1 Scope . 1
2 Normative references . 1
3 Terms, definitions, symbols and abbreviated terms . 1
3.1 Terms and definitions . 1
3.2 Symbols . 7
3.3 Abbreviated terms . 7
4 Document overview . 10
5 Conventions . 11
5.1 General . 11
5.2 Notational conventions . 11
5.3 SDL conventions . 12
5.4 Bit rates . 15
5.5 Roles of a node in a FlexRay cluster . 15
5.6 Synchronisation methods . 15
5.7 Network topology considerations . 19
5.8 Example node architecture. 24
6 Protocol operation control . 29
6.1 Principles. 29
6.2 Description . 31
6.3 The protocol operation control process . 37
7 Coding and Decoding . 59
7.1 Principles. 59
7.2 Description . 59
7.3 Coding and decoding process . 77
7.4 Bit strobing process . 96
7.5 Wakeup pattern decoding process . 99
8 Frame Format . 103
8.1 Overview . 103
8.2 FlexRay header segment (5 bytes) . 103
8.3 FlexRay payload segment (0 – 254 bytes) . 108
8.4 FlexRay trailer segment . 111
8.5 CRC calculation details . 111
9 Media Access Control . 113
9.1 Principles. 113
9.2 Description . 123
9.3 Media access control process . 126
10 Frame and Symbol processing . 143
10.1 Principles. 143
10.2 Description . 143
10.3 Frame and symbol processing process . 149
11 Wakeup and Startup . 161
11.1 General . 161
11.2 Cluster wakeup . 162
11.3 Communication startup and reintegration . 167
12 Clock synchronisation . 190
12.1 Introduction . 190
12.2 Time representation . 191
12.3 Synchronisation process . 193
12.4 Startup of the clock synchronisation . 200
12.5 Time measurement . 204
12.6 Correction term calculation . 208
12.7 Clock correction. 220
12.8 Sync frame configuration . 223
12.9 Time gateway interface . 225
13 Controller Host Interface . 226
13.1 Principles . 226
13.2 Description . 227
13.3 Interfaces . 228
Annex A (normative) System parameters . 268
A.1 Protocol constants . 268
A.2 Performance constants . 270
Annex B (normative) Configuration constraints . 271
B.1 General . 271
B.2 Bit rates . 271
B.3 Parameters . 272
B.4 Calculation of configuration parameters for nodes in a TT-D cluster . 281
B.5 Configuration of cluster synchronisation method and node synchronisation role . 334
B.6 Calculation of configuration parameters for nodes in a TT-L cluster . 335
B.7 Calculation of configuration parameters for nodes in a TT-E cluster . 336
Annex C (normative) Wakeup application notes . 345
C.1 Scope . 345
C.2 Wakeup initiation by the host . 345
C.3 Host reactions to status flags signalled by the communication controller. 348
C.4 Retransmission of wakeup patterns . 349
C.5 Transition to startup . 349
C.6 Wakeup during operation . 350
Bibliography . 352

iv © ISO 2013 – All rights reserved

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-2 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
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 synchronisation,
time synchronisation 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;
 Synchronisation 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 requirements for vehicle
communication systems implemented on a FlexRay data link.
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 [7], ISO 14229-4 [9];
 Presentation layer (layer 6), vehicle manufacturer specific;
 Session layer services (layer 5), specified in ISO°14229-2 [8];
 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.
vi © ISO 2013 – All rights reserved

Table 1 — FlexRay communications system specifications applicable to the OSI layers
Applicability OSI 7 layers FlexRay communications system Vehicle manufacturer
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.

INTERNATIONAL STANDARD ISO 17458-2:2013(E)

Road vehicles — FlexRay communications system — Part 2:
Data link layer specification
1 Scope
This part of ISO 17458 specifies the FlexRay communication protocol which is specified for a dependable
automotive network. 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
1)
frames during asynchronous transfer, single or multi-master clock synchronisation time synchronisation
2)
across multiple networks, error detection and signalling, and scalable fault tolerance .
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-1, Road vehicles — FlexRay communications system — Part 1: General information and use case
definition
3 Terms, definitions, symbols and abbreviated terms
3.1 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 17458-1 and the following apply.
3.1.1
application data
data produced and / or used by application tasks
NOTE In the automotive context the term 'signal' is often used for application data exchanged among tasks.
3.1.2
bus
communication system topology in which nodes are directly connected to a single, common communication
media (as opposed to connection through stars, gateways, etc.)
NOTE The term bus is also used to refer to the media itself.

1) Multi-master clock synchronisation refers to a synchronisation that is based on the clocks of several (three or more)
synchronisation masters or sync nodes.
2) Scalable fault tolerance refers to the ability of the FlexRay protocol to operate in configurations that provide various

degrees of fault tolerance (i.e., single or dual channel clusters, clusters with many or few sync nodes, etc.).
3.1.3
channel idle
condition on the physical transmission medium when no node is transmitting, as perceived by each individual
node in the network
NOTE The detection of channel idle occurs some time after all nodes have actually stopped transmitting (due to idle
detection times, channel effects, ringing, etc.).
3.1.4
clique
set of communication controllers having the same view of certain systems properties
EXAMPLE The global time value or the activity state of communication controllers.
3.1.5
cluster
communication system of multiple nodes connected via at least one communication channel directly (bus
topology), by active stars (star topology) or by a combination of bus and star connections (hybrid topologies)
NOTE Clusters can be coupled by gateways.
3.1.6
coldstart node
node capable of initiating the communication startup procedure on the cluster by sending startup frames
NOTE TT-D coldstart nodes, TT-L coldstart nodes, and TT-E coldstart nodes are all considered to be coldstart
nodes. By definition, all coldstart nodes are also sync nodes.
3.1.7
communication slot
interval of time during which access to a communication channel is granted exclusively to a specific node for
the transmission of a frame with a frame ID corresponding to the slot
NOTE FlexRay distinguishes between static communication slots and dynamic communication slots.
3.1.8
cycle-dependent slot assignment
method of assigning, for a given channel, an individual slot (identified by a specific slot number and a specific
cycle counter number) or a set of slots (identified by a specific slot number and a set of communication cycle
numbers) to a node
3.1.9
cycle-independent slot assignment
method of assigning, for a given channel, the set of all communication slots having a specific slot number to a
node (i.e., on the given channel, slots with the specific slot number are assigned to the node in all
communication cycles)
3.1.10
cycle number
positive integer used to identify a communication cycle
NOTE The cycle number of each communication cycle is one greater than the cycle number of the previous cycle,
except in cases where the previous cycle had the maximum cycle number value, in which case the cycle number has the
value of zero. The cycle number of the first cycle is, by definition, zero.
3.1.11
cycle time
time within the current communication cycle, expressed in units of macroticks
NOTE Cycle time is reset to zero at the beginning of each communication cycle.
2 © ISO 2013 – All rights reserved

3.1.12
dynamic segment
portion of the communication cycle where the media access is controlled via a mini-slotting scheme
NOTE 1 During this segment access to the media is dynamically granted on a priority basis to nodes with data to
transmit.
NOTE 2 Also known as Flexible Time Division Multiple Access (FTDMA).
3.1.13
dynamic slot / dynamic communication slot
interval of time within the dynamic segment of the communication cycle consisting of one or more minislots
during which access to a communication channel is granted exclusively to a specific node for transmission of
a frame with a frame ID corresponding to the slot
NOTE In contrast to a static communication slot, the duration of a dynamic communication slot may vary depending
on the length of the frame. If no frame is sent, the duration of a dynamic communication slot equals that of one minislot.
3.1.14
frame
structure used by the communication system to exchange information within the system
NOTE A frame consists of a header segment, a payload segment and a trailer segment. The payload segment is
used to convey application data.
3.1.15
frame identifier
slot position in the static segment and priority in the dynamic segment
NOTE A lower identifier indicates a higher priority.
3.1.16
global time
combination of cycle counter and cycle time
3.1.17
Hamming distance
minimum distance (i.e., the number of bits which differ) between any two valid code words in a binary code
3.1.18
implementation dependent
behaviour that, subject to restrictions in the specification, may be chosen by an implementation designer.
Implementation dependent behaviour shall be described in detail in the documentation of an implementation
3.1.19
key slot
static slot that is used by a node to transmit sync and startup frames or the slot that is used to transmit when
the node is operating in key slot only mode.
3.1.20
macrotick
interval of time derived from the cluster-wide clock synchronisation algorithm
NOTE A macrotick consists of an integral number of microticks. The actual number of microticks in a given macrotick
is adjusted by the clock synchronisation algorithm. The macrotick represents the smallest granularity unit of the global
time.
3.1.21
microtick
interval of time derived directly from the CC's oscillator (possibly through the use of a prescaler)
NOTE The microtick is not affected by the clock synchronisation mechanisms, and is thus a node-local concept.
Different nodes can have microticks of different duration.
3.1.22
minislot
interval of time within the dynamic segment of the communication cycle that is of constant duration (in terms of
macroticks) and that is used by the synchronized FTDMA media access scheme to manage media arbitration
3.1.23
non-coldstart node
node that is not capable of initiating the communication startup procedure (i.e., does not transmit startup
frames)
3.1.24
non-sync node
node that is not configured to transmit sync frames.
3.1.25
non-synchronized operation
operation of a node when the node does not have a notion of FlexRay time, i.e., has no knowledge of slot
identifier, slot boundaries, cycle counter, or segment boundaries
3.1.26
network
combination of the communication channels that connect the nodes of a cluster
3.1.27
node
logical entity connected to the network that is capable of sending and / or receiving frames
3.1.28
null frame
frame that contains no usable data in the payload segment
NOTE A null frame is indicated by a bit in the header segment, and all data bytes in the payload segment are set to
zero.
3.1.29
physical communication link
inter-node connection through which signals are conveyed for the purpose of communication
NOTE All nodes connected to a given physical communication link share the same electrical or optical signals (i.e.,
they are not connected through repeaters, stars, gateways, etc.). Examples of a physical communication link include a bus
network or a point-to-point connection between a node and a star. A communication channel may be constructed by
combining one or more physical communication links together using stars.
3.1.30
precision
worst-case deviation between the corresponding macroticks of any two synchronized nodes in the cluster
3.1.31
slot
see communication slot
3.1.32
slot ID (identifier)
see slot number
4 © ISO 2013 – All rights reserved

3.1.33
slot multiplexing
technique of assigning, for a given channel, slots having the same slot identifier to different nodes in different
communication cycles
3.1.34
slot number
number used to identify a specific slot within a communication cycle
3.1.35
star
device that allows information to be transferred from one physical communication link to one or more other
physical communication links
NOTE A star duplicates information present on one of its links to the other links connected to the star. A star can be
either passive or active. For the purposes of this specification, all usages of the term "star" are references to an active star
as described in ISO 17458-4.
3.1.36
startup frame
FlexRay frame whose header segment contains an indicator that integrating nodes may use timerelated
information from this frame for initialisation during the startup process
NOTE Startup frames are always also sync frames.
3.1.37
static slot / static communication slot
interval of time within the static segment of the communication cycle that is constant in terms of macroticks
and during which access to a communication channel is granted exclusively to a specific node for
transmission of a frame with a frame ID corresponding to the slot
NOTE Unlike a dynamic communication slot, each static communication slot contains a constant number of
macroticks regardless of whether or not a frame is sent in the slot.
3.1.38
static segment
portion of the communication cycle where the media access is controlled via a static Time Division Multiple
Access (TDMA) scheme
NOTE During this segment access to the media is determined solely by the progression of time.
3.1.39
sync frame
FlexRay frame whose header segment contains an indicator that the deviation measured between the frame's
arrival time and its expected arrival time should be used by the clock synchronisation algorithm
3.1.40
sync node
node configured to transmit sync frames
NOTE Coldstart nodes and TT-D non-coldstart sync nodes are considered to be sync nodes.
3.1.41
synchronized operation
operation of a node when the node has a notion of FlexRay time, i.e., has knowledge of slot identifier, slot
boundaries, cycle counter, and segment boundaries
3.1.42
time gateway
pair of nodes attached to different clusters connected by a time gateway interface
3.1.43
time gateway interface
interface used by a time gateway source node to provide timing information for a time gateway sink node
3.1.44
time gateway sink node
node configured as TT-E coldstart node, which is connected via a time gateway interface to a time gateway
source node
NOTE The time gateway sink node receives timing information from the time gateway source node.
3.1.45
time gateway source node
node connected via a time gateway interface to a time gateway sink node
NOTE The time gateway source node provides timing information for the time gateway sink node.
3.1.46
time sink cluster
cluster using the TT-E synchronisation method
NOTE The term emphasizes that the TT-E coldstart nodes of this cluster receive their timing from another cluster.
3.1.47
time source cluster
cluster that provides the timing information for a time sink cluster
3.1.48
transmission slot assignment list
structure identifying the set of all slots assigned to a node for transmission
3.1.49
TT-D cluster
cluster in which the clock synchronisation uses the TT-D synchronisation method
NOTE A TT-D cluster consists of two or more TT-D coldstart nodes, zero or more TT-D non-coldstart sync nodes
and, zero or more non-sync nodes.
3.1.50
TT-D coldstart node
coldstart node operating in a TT-D cluster
NOTE This node has only a single key slot and sends a startup / sync frame in the configured key slot in each cycle
on each configured channel.
3.1.51
TT-D non-coldstart sync node
node that is configured to transmit sync frames but is not capable of initiating the communication startup
procedure (i.e., does not send startup frames)
3.1.52
TT-D synchronisation method
method of clock synchronisation in which the clock synchronisation is derived in a distributed manner from two
or more sync nodes
NOTE Two or more coldstart nodes are required to start up a cluster using this synchronisation method.
3.1.53
TT-E cluster
cluster in which the clock synchronisation uses the TT-E synchronisation method
6 © ISO 2013 – All rights reserved

NOTE A TT-E cluster consists of one or more TT-E Coldstart nodes and zero or more non-sync nodes.
3.1.54
TT-E coldstart node
coldstart node operating in a TT-E cluster
NOTE This node has two key slots and sends startup / sync frames in both configured key slots in each cycle on
each configured channel. A TT-E coldstart node is a time gateway sink (i.e., is configured for external synchronisation)
and bases its timebase on the clock sync information derived from the time source cluster as delivered by the time
gateway interface.
3.1.55
TT-E synchronisation method
method of clock synchronisation in which the clock synchronisation is derived directly from the clock
synchronisation of another FlexRay cluster
NOTE In this method a single coldstart node is capable of starting up the cluster.
3.1.56
TT-L cluster
cluster in which the clock synchronisation uses the TT-L synchronisation method
NOTE A TT-L cluster consists of one TT-L Coldstart node and one or more non-sync nodes.
3.1.57
TT-L coldstart node
coldstart node operating in a TT-L cluster
NOTE This node has two key slots and sends startup / sync frames in both configured key slots in each cycle on
each configured channel.
3.1.58
TT-L synchronisation method
method of clock synchronisation in which the clock synchronisation is derived from the local clock of a single
sync node, and in which a single coldstart node starts up the cluster
3.2 Symbols
Summation symbol, a large upright capital Sigma
∑
Element, lower-case epsilon
∈
For all (given any), universal quantifier symbol, a turned "A"
∀
3.3 Abbreviated terms
μs Microsecond
μT Microtick
AP Action Point
BD Bus Driver
BIST Built-In Self Test
BITSTRB Bit Strobing Process
BSS Byte Start Sequence
CAS Collision Avoidance Symbol
CC Communication Controller
CE Communication Element
CHI Controller Host Interface
CHIRP Channel Idle Recognition Point
CODEC Coding and Decoding Process
CRC Cyclic Redundancy Code
CSP Clock Synchronisation Process
CSS Clock Synchronisation Startup Process
DTS Dynamic Trailing Sequence
ECU Electronic Control Unit, same as node
EMI Electromagnetic Interference
ERRN Error Not signal
FES Frame End Sequence
FIFO First In First Out
FSP Frame and Symbol Processing
FSS Frame Start Sequence
FTDMA Flexible Time Division Multiple Access
FTM Fault-Tolerant Midpoint
ID Identifier
INH1 Inhibit signal
MAC Media Access Control Process
MT Macrotick
MTG Macrotick Generation Process
MTS Media Access Test Symbol
NIT Network Idle Time
NM Network Management
POC Protocol Operation Control
RxD Receive data signal from bus driver
8 © ISO 2013 – All rights reserved

SDL Specification and Description Language
SPI Serial Peripheral Interface
STBN Standby Not signal
SW Symbol Window
sync synchronisation
TDMA Time Division Multiple Access
TRP Time Reference Point
TSS Transmission Start Sequence
TT-D Time-Triggered Local Distributed
TT-E Time-Triggered External
TT-L Time-Triggered Local Master
TxD Transmit Data signal from CC
TxEN Transmit Data Enable Not signal from CC
WUDOP Wakeup During Operation Pattern
WUP Wakeup Pattern
WUPDEC Wakeup Pattern Decoding Process
WUS Wakeup Symbol
4 Document overview
Figure 1 illustrates the document references.

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
Specification and subset manufacturer
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
communications system
OSI Layer 2
– Data link layer
– Data link layer
Data Link
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
10 © ISO 2013 – All rights reserved

5 Conventions
5.1 General
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).
5.2 Notational conventions
5.2.1 Parameter prefix conventions
The following is a list of parameter prefix conventions:
 ::= [] Name;
 ::= a | c | v | g | p | z;
 ::= d | s;
Table 2 defines the parameter .
Table 2 — Definition of parameter
Naming Information type Description
convention
a Auxiliary Auxiliary parameter used in the definition or derivation of other parameters
parameter or in the derivation of constraints.
c Protocol constant Values used to define characteristics or limits of the protocol. These values
are fixed for the protocol and cannot be changed.
v Node variable Values that vary depending on time, events, etc.
g Cluster parameter Parameter that shall have the same value in all nodes in a cluster, is
initialized in the POC:default config state, and can only be changed while in
the POC:config state.
p Node parameter Parameter that may have different values in different nodes in the cluster, is
initialized in the POC:default config state, and can only be changed while in
the POC:config state.
z Local SDL process Variables used in SDL processes to facilitate accurate representation of the
variable necessary algorithmic behaviour. Their scope is local to the process where
they are declared and their existence in any particular implementation is not
mandated by the protocol.
Table 3 defines the parameter .
Table 3 — Definition of parameter
Naming Information type Description
convention
d Time duration Value (variable, parameter, etc.) describing a time duration, the time
between two points in time.
s Set Set of values (variables, parameters, etc.).

5.2.2 Text coding
Throughout the text several types of items are highlighted through the use of an italicized font.
Parameters, constants and variables are highlighted in italics. An example is the parameter gdStaticSlot. This
convention is not used within SDL diagrams, as it is assumed that such information is obvious. The meaning
of the prefixes of parameters, constants, and variables is described in 5.2.1.
SDL states are also highlighted in italics. An example is the SDL state POC:normal active. This highlighting
convention is not used within SDL diagrams. Further notational conventions related to SDL states are
described in 5.3.2.
SDL signals are also highlighted in italics. An example is the SDL signal CHIRP on A. This convention is not
used within the SDL diagrams themselves as the fact that an item is an input or output signal should be
obvious.
5.2.3 Implementation dependent behaviour
While this specification defines the required behaviour of a FlexRay implementation in many respects, there
are various decisions on the particulars of an implementation that, for flexibility reasons, are left up to the
implementation designers. This specification defines the term "implementation dependent" to have the
following meaning:
 a behaviour (or a parameter or characterization of a behaviour, such as a default value) that, subject to
restrictions contained in this specification, may be chosen by an implementation designer;
 implementation dependent behaviour may vary from implementation to implementation, but the specific
behaviour shall be described in detail in the documentation of the implementation.
5.3 SDL conventions
5.3.1 General
The FlexRay protocol mechanisms described in this specification are presented using a graphical method
loosely based on the Specification and Description Language (SDL) technique described in [10]. The intent of
this description is not to provide a complete executable SDL model of the protocol mechanisms, but rather to
present a reasonably unambiguous description of the mechanisms and their interactions. This description is
intended to be read by humans, not by machines, and in many cases the description is optimized for
understandability rather than exact syntactic correctness.
The SDL descriptions in this specification are behavioural descriptions, not requirements on a particular
method of implementation. In many cases the method of description was chosen for ease of understanding
rather than efficiency of implementation. An actual implementation should have the same behaviour as the
SDL description, but it need not have the same underlying structure or mechanisms.
Several SDL diagrams have textual descriptions intended to assist the reader in understanding the behaviour
depicted in the SDL diagrams. Some technical details are intentionally omitted from these explanations.
Unless specifically mentioned, the behaviour depicted in the SDL diagrams takes precedence over any textual
description.
In SDL, transitions between states, and any processing that takes place along the paths involving these
transitions, is assumed to take place in zero time. The descriptions of the protocol mechanisms rely on this
zero time assumption to specify the proper behaviour of an implementation. Transitions and processing in a
real implementation will not take place in zero time. The implementation designer shall comprehend any
discrepancy between the implicit zero time assumption in the SDL description and the actual time taken in the
chosen implementation technology and ensure that the implementation's behaviour is consistent with the
behaviour described in the SDL.
12 © ISO 2013 – All rights reserved

5.3.2 SDL notational conventions
States that exist within the various SDL processes are shown with the state symbol shaded in light gray.
These states are named with all lowercase letters. Acronyms or proper nouns that appear in a state name are
capitalized as appropriate. Examples include the states "wait for sync frame" and "wait for CE start".
SDL states that are referenced in the text are prefixed with an identification of the SDL process in which they
are located (for example, the state POC:normal active refers to the "normal active" state in the POC process).
This convention is not used within the S
...