ISO 10681-2:2010
(Main)Road vehicles — Communication on FlexRay — Part 2: Communication layer services
Road vehicles — Communication on FlexRay — Part 2: Communication layer services
ISO 10681-2:2010 specifies the requirements for a communication protocol tailored to meet the requirements of FlexRay-based vehicle network systems as specified in the FlexRay Communications Systems Protocol Specification. As the communication protocol combines the network-layer and transport-layer functionality (OSI layers 3 and 4), this document does not explicitly distinguish between these layer services. The technical features of this communication protocol are as follows: transmit messages with known data length; transmit messages with unknown but finite data length; additional acknowledgement with retry mechanism; routing data on the fly; support of dynamic frame length.
Véhicules routiers — Communication par FlexRay — Partie 2: Services de la couche de communication
General Information
Standards Content (Sample)
INTERNATIONAL ISO
STANDARD 10681-2
First edition
2010-06-15
Road vehicles — Communication on
FlexRay —
Part 2:
Communication layer services
Véhicules routiers — Communication par FlexRay —
Partie 2: Services de la couche de communication
Reference number
ISO 10681-2:2010(E)
©
ISO 2010
---------------------- Page: 1 ----------------------
ISO 10681-2:2010(E)
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.
COPYRIGHT PROTECTED DOCUMENT
© ISO 2010
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 2010 – All rights reserved
---------------------- Page: 2 ----------------------
ISO 10681-2:2010(E)
Contents Page
Foreword. iv
Introduction . v
1 Scope . 1
2 Normative references . 1
3 Terms, definitions, symbols and abbreviated terms. 2
4 Conventions . 4
5 Communication layer overview. 4
6 Communication layer services. 10
7 Communication layer protocol. 22
8 Data link layer usage . 48
Annex A (informative) Implementation examples . 58
Bibliography . 64
© ISO 2010 – All rights reserved iii
---------------------- Page: 3 ----------------------
ISO 10681-2:2010(E)
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 10681-2 was prepared by Technical Committee ISO/TC 22, Road vehicles, Subcommittee SC 3,
Electrical and electronic equipment.
ISO 10681 consists of the following parts, under the general title Road vehicles — Communication on
FlexRay:
⎯ Part 1: General information and use case definition
⎯ Part 2: Communication layer services
iv © ISO 2010 – All rights reserved
---------------------- Page: 4 ----------------------
ISO 10681-2:2010(E)
Introduction
This part of ISO 10681 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 (see
example in Table 1). When mapped on this model, this part of ISO 10681 incorporates the network layer
(layer 3) and the transport layer (layer 4) services as communication layer services.
Table 1 — Example of enhanced diagnostic specifications according to the OSI layers
Applicability OSI layers Vehicle manufacturer enhanced diagnostics
Application layer ISO 14229-1
Presentation layer N/A
Session layer ISO 14229-2
Seven layers
according to
Transport layer ISO 10681-2
ISO/IEC 7498-1
Network layer
and
ISO/IEC 10731
Data link layer FlexRay Communications Systems Protocol
Specification
Physical layer FlexRay Communications System Electrical
Physical Layer Specification
© ISO 2010 – All rights reserved v
---------------------- Page: 5 ----------------------
INTERNATIONAL STANDARD ISO 10681-2:2010(E)
Road vehicles — Communication on FlexRay —
Part 2:
Communication layer services
1 Scope
This part of ISO 10681 specifies the requirements for a communication protocol tailored to meet the
requirements of FlexRay-based vehicle network systems as specified in the FlexRay Communications
Systems Protocol Specification. As the communication protocol combines the network layer and transport
layer functionality (OSI layers 3 and 4), this part of ISO 10681 does not explicitly distinguish between these
layer services.
The technical features of this communication protocol are as follows:
⎯ transmit messages with known data length;
⎯ transmit messages with unknown but finite data length;
⎯ additional acknowledgement with retry mechanism;
⎯ routing data on the fly;
⎯ support of dynamic frame length.
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/IEC 7498-1, Information technology — Open Systems Interconnection — Basic Reference Model: The
Basic Model
ISO 7498-2, Information processing systems — Open Systems Interconnection — Basic Reference Model —
Part 2: Security Architecture
ISO/IEC 7498-3, Information technology — Open Systems Interconnection — Basic Reference Model:
Naming and addressing
ISO/IEC 7498-4, Information processing systems — Open Systems Interconnection — Basic Reference
Model — Part 4: Management framework
ISO/IEC 10731, Information technology — Open Systems Interconnection — Basic Reference Model —
Conventions for the definition of OSI services
© ISO 2010 – All rights reserved 1
---------------------- Page: 6 ----------------------
ISO 10681-2:2010(E)
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/IEC 7498-1, ISO 7498-2,
ISO/IEC 7498-3 and ISO/IEC 7498-4 and the following apply.
3.1.1
communication layer
CL
layer that includes the network layer (layer 3) and the transport layer (layer 4)
3.1.2
protocol data unit
PDU
〈layered system〉 data unit that is specified in the protocol of a given layer
NOTE The protocol data unit contains user data of that layer and possible protocol control information. The protocol
data unit of layer X is the service data unit of its lower layer (X − 1).
3.1.3
service data unit
SDU
〈layered system〉 set of data that is sent by a user of the service in a given layer
NOTE It is transmitted to a peer service user with no semantic change.
3.2 Abbreviated terms
For the purposes of this document, the following abbreviated terms apply.
ABT abort
ACK acknowledge
BC bandwidth control
BfS buffer size
BP byte position
C_AI communication address information
C_Ar communication layer timing parameter A receiver
C_As communication layer timing parameter A sender
C_Br communication layer timing parameter B receiver
C_Bs communication layer timing parameter B sender
C_Cr communication layer timing parameter C receiver
C_Cs communication layer timing parameter C sender
C_CT communication type
C_Data communication layer data transfer service name
C_PCI communication protocol control information
C_SA communication source address
C_TA communication target address
2 © ISO 2010 – All rights reserved
---------------------- Page: 7 ----------------------
ISO 10681-2:2010(E)
C_TAType communication target address type
CF consecutive frame
CL communication layer
COMM communication
CTS continue to send
C_PDU communication layer protocol data unit
C_SDU communication layer service data unit
DLL data link layer
ECU electronic control unit
EOB end of block
FC flow control
FIFO first in first out
FPL frame payload length
FR FlexRay
FS flow status
Ind indication
LF last frame
L_PDU data link layer protocol data unit
max maximum
ML message length
MNPC maximum numbers of PDUs per cycle
N/A not applicable
N_PDU network protocol data unit
NUM number
OVFLW overflow
PDU protocol data unit
pLatestTx latest point of transmission
Req request
RET retry
RX receive
SCexp separation cycle exponent
SDU service data unit
SN sequence number
STF start frame
STFA start frame acknowledged
STFU start frame unacknowledged
© ISO 2010 – All rights reserved 3
---------------------- Page: 8 ----------------------
ISO 10681-2:2010(E)
UNEXP unexpected
UNUM unsigned numeric
TX transmission
WFT wait frame transmission
WT wait
3.3 Symbols
Σ summation
≠ not equal
4 Conventions
ISO 10681 is based on the conventions discussed in the OSI Services Conventions (ISO/IEC 10731:1994) as
they apply for diagnostic services.
5 Communication layer overview
5.1 General
This clause describes the overall functionality of the communication layer. This part of ISO 10681 specifies an
unacknowledged and acknowledged communication layer protocol for the exchange of data with known or
unknown length between network nodes, e.g. from ECU to ECU, or between a diagnostic tester equipment
and an ECU. If the data to be transferred do not fit into a single L_PDU, a segmentation method is provided.
In order to describe the function of the communication layer, services provided to upper layers and the internal
operation of the communication layer have to be considered.
5.2 Services provided by communication layer to upper layers
The service interface defines a set of services that are needed to access the functions offered by the
communication layer, i.e. transmission/reception of data and setting of protocol parameters.
Four types of services are defined.
a) Communication services
These services, of which the following are defined, enable the transfer of up to 64 kbytes of data.
1) C_Data.request
This service is used to request the transfer of data. If necessary, the communication layer segments
the data.
2) C_Data_STF.indication
This service is used to signal the beginning of a segmented message reception to the upper layer.
3) C_Data.indication
This service is used to provide received data to the upper layer.
4 © ISO 2010 – All rights reserved
---------------------- Page: 9 ----------------------
ISO 10681-2:2010(E)
4) C_Data.confirm
This service confirms to the upper layer that the requested service has been carried out (successfully
or not).
b) Protocol parameter setting services
These services, of which the following are defined, enable the dynamic setting of protocol parameters.
1) C_ChangeParameter.request
This service is used to request the dynamic setting of specific internal parameters.
2) C_ChangeParameter.confirm
This service confirms to the upper layer that the request to change a specific parameter has been
carried out (successfully or not).
3) C_GetParameter.request
This service is used to request the value of a communication layer parameter for a given connection.
4) C_GetParameter.confirm
This service is used to return the value of a communication layer parameter for a given connection.
c) Status services
1) C_GetStatus.request
This service is used to request the status of a transfer of data (transmit/receive).
2) C_GetStatus.confirm
This service confirms to the upper layer the status of the transfer of data (transmit/receive).
d) Transmission control services
C_Cancel.request
This service is used to request cancellation of an ongoing message transmission. This request can
only be issued by the sender of a message, after the message transmission has been started via a
C_Data.request service primitive.
5.3 Internal operation of communication layer
5.3.1 General
The internal operation of the communication layer provides the following methods for segmentation,
transmission with flow control, and reassembly:
⎯ transmission of a message with a known message length;
⎯ transmission of a message with an unknown but finite message length;
⎯ acknowledgement of the transmission with a retry mechanism.
© ISO 2010 – All rights reserved 5
---------------------- Page: 10 ----------------------
ISO 10681-2:2010(E)
The main purpose of the communication layer is to perform a transfer of a message that might or might not fit
in a single FlexRay frame. Messages which do not fit into a single FlexRay frame are segmented into multiple
parts, where each can be transmitted in a FlexRay frame.
5.3.2 Rules
The communication layer establishes certain rules for an ongoing transmission/reception, which are briefly
described here for better understanding of the examples given in 5.3.3. For details on certain frames and their
usage, see 7.4.
⎯ Segmented messages are always concluded with a LastFrame. This frame might include the last bytes of
the message if they did not fit completely into the previous ConsecutiveFrame.
⎯ An acknowledged message transmission that is started with a StartFrame_ACK is always concluded by
the receiver with a FlowControl_ACK after the reception of the last frame of the message, which can
either be a single StartFrame or a LastFrame (in the case of a multiframe transmission).
⎯ The request to acknowledge the reception of a block of ConsecutiveFrames via the
ConsecutiveFrame_EOB shall always be confirmed by the receiver with a FlowControl frame which
indicates the status of the reception (CTS, WAIT, etc.).
⎯ In the case of an unknown message length transmission, the upper layer of the sender either
asynchronously or synchronously provides data during the ongoing message transmission via the
C_Data.request service primitive.
⎯ In the case of a known message length transmission where the amount of data fits into a single STF and
is completely available for transmission, a LastFrame will not be transmitted.
⎯ Functional requests are transmitted as unsegmented and unacknowledged messages. Any other format
will be ignored by the communication layer (no error will be communicated).
⎯ If an STFU payload length is greater than the possible payload in an STFU, then the frame shall be
ignored by the receiver.
5.3.3 Message sequence charts
All examples given assume a communication between the sender and the receiver on a single subnet, not
taking into account communication over gateways.
Figure 1 shows an example of an unsegmented unacknowledged message transmission with a known
message length.
Figure 1 — Example of unsegmented unacknowledged message (known message length)
6 © ISO 2010 – All rights reserved
---------------------- Page: 11 ----------------------
ISO 10681-2:2010(E)
Figure 2 shows an example of an unsegmented acknowledged message transmission with a known message
length.
Figure 2 — Example of unsegmented acknowledged message (known message length)
Figure 3 shows an example of a segmented unacknowledged message transmission with a known message
length.
Figure 3 — Example of segmented unacknowledged message (known message length)
© ISO 2010 – All rights reserved 7
---------------------- Page: 12 ----------------------
ISO 10681-2:2010(E)
Figure 4 shows an example of a segmented acknowledged message transmission with a known message
length.
Figure 4 — Example of segmented acknowledged message (known message length)
8 © ISO 2010 – All rights reserved
---------------------- Page: 13 ----------------------
ISO 10681-2:2010(E)
Figure 5 shows an example of a segmented unacknowledged message transmission with an unknown
message length.
Figure 5 — Example of segmented unacknowledged message (unknown message length)
© ISO 2010 – All rights reserved 9
---------------------- Page: 14 ----------------------
ISO 10681-2:2010(E)
Figure 6 shows an example of a segmented acknowledged message transmission with an unknown message
length.
Figure 6 — Example of segmented acknowledged message (unknown message length)
6 Communication layer services
6.1 General
All communication layer services have the same general structure. To define the services, three types of
service primitives are specified:
⎯ a service request primitive, used by upper layers to pass control information and the data required to be
transmitted to the communication layer;
⎯ a service indication primitive, used by the communication layer to pass status information and the
received data to upper layers;
⎯ a service confirmation primitive used by the communication layer to pass status information to upper
layers.
10 © ISO 2010 – All rights reserved
---------------------- Page: 15 ----------------------
ISO 10681-2:2010(E)
This service specification only specifies a set of service primitives that are independent of any
1)
implementation . It does not specify an application programming interface.
All communication layer services have the same general format. Service primitives are written in the form:
service_name.type (
parameter A,
parameter B,
parameter C,
...
)
where “service_name” is the name of the service. For C_Data, “type” indicates the type of the service primitive,
and “parameter A, parameter B, parameter C, .” are the C_SDU presented as a list of values passed by the
service primitive.
6.2 Specification of communication layer service primitives
6.2.1 C_Data.request
The service primitive requests transmission of with number of bytes from the
sender to the receiver peer entities identified by the address information in C_SA, C_TA, C_TAtype (see 6.3
for parameter definitions). Furthermore, is supported in order to distinguish between an
acknowledged and an unacknowledged data transfer. For the support of an unknown message length
transmission, an indication of the number of bytes is provided.
Each time the C_Data.request service is called, the communication layer shall signal the completion (or
failure) of the message transmission to the service user by means of the issuing of a C_Data.confirm service
call:
C_Data.request (
C_SA,
C_TA,
C_TAtype,
C_CT,
,
,
)
6.2.2 C_Data.confirm
The C_Data.confirm service is issued by the communication layer. The service primitive confirms the
completion of a C_Data.request service identified by the address information in C_SA, C_TA and C_TAtype.
The parameter provides the status of the service request (see 6.3 for parameter definitions).
C_Data.confirm (
C_SA,
C_TA,
C_TAtype,
)
1) Annex A includes a detailed example on how the different scenarios of buffer resources in the sender and receiver are
handled. Those examples make use of the service primitives as they would be API functions to describe the required
behavior.
© ISO 2010 – All rights reserved 11
---------------------- Page: 16 ----------------------
ISO 10681-2:2010(E)
6.2.3 C_Data_STF.indication
The C_Data_STF.indication service is issued by the communication layer. The service primitive indicates to
the upper layer the arrival of a start frame (STF) of a segmented message received from a peer protocol entity,
identified by the address information in C_SA, C_TA and C_TAtype (see 6.3 for parameter definitions). This
indication shall take place upon reception of the start frame (STF) of a segmented message.
C_Data_STF.indication (
C_SA,
C_TA,
C_TAtype,
)
The C_Data_STF.indication service shall always be followed by a C_Data.indication service call from the
communication layer, indicating the completion (or failure) of the message reception.
A C_Data_STF.indication service call shall only be issued by the communication layer if a correct start frame
(STF) message segment has been received.
If the communication layer detects an error in a start frame (STF), then the message is ignored by the
communication layer and no C_Data_STF.indication shall be issued to the upper layer.
6.2.4 C_Data.indication
The C_Data.indication service is issued by the communication layer. The service primitive indicates
events and delivers with bytes received from a peer protocol entity
identified by the address information in C_SA, C_TA and C_TAtype to the upper layer (see 6.3 for parameter
definitions).
The parameters and are only valid if equals C_OK.
C_Data.indication (
C_SA,
C_TA,
C_TAtype,
,
)
The C_Data.indication service call is issued after the reception of a single start frame (STF) that includes the
complete message (unsegmented message) or as an indication of the completion (or failure) of a segmented
message reception.
If the communication layer detects any type of error in a single start frame (STF), then the message shall be
ignored by the communication layer and no C_Data.indication shall be issued to the adjacent upper layer.
6.2.5 C_ChangeParameter.request
The service primitive is used to request the change of an internal parameter’s value on the local protocol entity
identified by the address information in C_SA, C_TA and C_TAtype. The is assigned to
the (see 6.3 for parameter definitions).
A parameter change is always possible, except after reception of the start frame (C_Data_STF.indication) and
until the end of the reception of the corresponding message (C_Data.indication).
12 © ISO 2010 – All rights reserved
---------------------- Page: 17 ----------------------
ISO 10681-2:2010(E)
C_ChangeParameter.request (
C_SA,
C_TA,
C_TAtype,
,
)
This is an optional service that can be replaced by implementation of fixed parameter values.
6.2.6 C_ChangeParameter.confirm
The service primitive confirms the completion of a C_ChangeParameter.request service applying to a
message identified by the address information in C_SA, C_TA and C_TAtype (see 6.3 for parameter
definitions).
C_ChangeParameter.confirm (
C_SA,
C_TA,
C_TAtype
)
6.2.7 C_GetParameter.request
The service primitive is used to request the configured internal parameter’s value on the local protocol entity
identified by the address information in C_SA, C_TA and C_TAtype (see 6.3 for parameter definitions). A
parameter read is always possible.
C_GetParameter.request (
C_SA,
C_TA,
C_TAtype
)
This is an optional service that can be replaced by implementation of fixed parameter values.
6.2.8 C_GetParameter.confirm
The service primitive confirms the completion of a C_GetParameter.request service applying to a message
identified by the address information in C_SA, C_TA and C_TAtype (see 6.3 for parameter definitions).
C_GetParameter.confirm (
C_SA,
C_TA,
C_TAtype
)
© ISO 2010 – All rights reserved 13
---------------------- Page: 18 ----------------------
ISO 10681-2:2010(E)
6.2.9 C_GetStatus.request
The service primitive requests status of an ongoing communication is identified by the address information in
C_SA, C_TA and C_TAtype (see 6.3 for parameter definitions).
C_GetStatus.request (
C_SA,
C_TA,
C_TAtype
)
6.2.10 C_GetStatus.confirm
The C_GetStatus.confirm service is issued by the communication layer. The service primitive confirms the
completion of a C_GetStatus.request service identified by the address information in C_SA, C_TA and
C_TAtype. The parameter provides the status of the ongoing communication (see 6.3 for
parameter definitions).
C_GetStatus.confirm (
C_SA,
C_TA,
C_TAtype
)
6.2.11 C_Cancel.request
The service primitive requests cancellation of an ongoing transmission is identified by the address information
in C_SA, C_TA and C_TAtype (see 6.3 for parameter definitions).
C_Cancel.request (
C_SA,
C_TA,
C_TAtype)
There is no confirmation service primitive defined. If a new transmission is issued via C_Data.request before
the C_Cancel.request has been served completely, the upper layer will receive a C_Data.confirm with
C_Result = C_TX_ON.
6.3 Service data unit specification
6.3.1 C_AI, Address Information
6.3.1.1 C_AI description
These parameters refer to addressing information. As a whole, the C_AI parameters are used to identify the
source address (C_SA) and target address (C_TA) of message senders and recipients. See Table 2.
Table 2 — C_AI format
Byte 1 Byte 2 Byte 3 Byte 4
15 0 15 0
C_TA C_SA
14 © ISO 2010 – All rights reserved
---------------------- Page: 19 ----------------------
ISO 10681-2:2010(E)
6.3.1.2 C_SA, Communication Source Address
Type: 16 bit unsigned integer value
Range: 0000 to FFFF hex
Description: The C_SA parameter shall be used to encode the sending communication layer protocol entity.
NOTE The communication layer uses this parameter to identify corresponding C_PDUs, but neither modifies it nor
defines values for the C_SA.
6.3.1.3 C_TA, Communication Target Address
Type: 16 bit unsigned integer value
Range: 0000 to FFFF hex
Description: The C_TA parameter shall be used to encode the receiving communication layer protocol entity.
NOTE The communication layer uses this parameter to identify corresponding C_PDUs, but does neither modify it
nor define values for the C_TA.
6.3.1.4 C_TAtype, Communication Target Address type
Type: enumeration
Range: physical, functional
Description: The parameter C_TAtype is a configuration attribute to the C_TA parameter and implicitly part of
C_TA. It shall be used to encode the communication model used by the communicating peer entities of the
communication layer. Two communication models are specified: 1-to-1 communication, called “physical
addressing” (unicast), and 1-to-n communication, called “functional addressing” (multicast/broadcast).
⎯ Physical addressing (1-to-1 communication – unicast) shall be supported for all types of communication
layer messages (unsegmented and segmented).
⎯ Functional addressing (1-to-n communication – multicast/broadcast) shall only be supported for
unsegmented, unacknowledged, known message length communication messages.
6.3.1.5 C_CT, Communication Type
Type: enumeration
Range: unacknowledged, acknowledged
Description: The C_CT parameter shall be used to specify the type of communication to be performed from a
sender perspective. The parameter is implicitly configured within C_SA and C_TA.
6.3.2
Type: enumeration
Range: C_OK, C_MOREDATA, C_TIMEOUT_A, C_TIMEOUT_Bs, C_TIMEOUT_Cr, C_WRONG_SN,
C_ML_MISMATCH, C_INVALID_FS, C_UNEXP_PDU, C_WFT_OVRN, C_ABORT, C_CANCEL,
C_WRONG_BP, C_BUFFER_OVFLW, C_ERROR
© ISO 2010 – All rights reserved 15
---------------------- Page: 20 ----------------------
ISO 10681-2:2010(E)
Description: This parameter contains the status relating to the outcome of a service execution. If two or more
errors are discovered at the same time, then the communication layer entity shall use the first parameter value
found in this list in the error indication to the upper layers.
NOTE Table 3 implicitly defines the priority of the result value evaluati
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.