FlexRay Transport Layer (FrTp)

FrTp transmits large messages between PduR and FrIf according to ISO 10681-2 ([SWS_FrTp_01005]). It segments and reassembles them, controls flow, and distributes bandwidth via shared Tx PDU pools. FrTp_Transmit only accepts a transmit request; the actual work is performed by the cyclic FrTp_MainFunction, which must run at least once per FlexRay cycle ([SWS_FrTp_01152]). Acknowledged and unacknowledged transmissions as well as messages of unknown length are supported. In case of protocol errors or invalid segmentation, FrTp aborts and reports E_NOT_OK to the PduR.

more ›

FrTp is the transport layer for FlexRay according to ISO 10681-2. Where the specification does not specify its own requirements, the module follows this standard ([SWS_FrTp_01005]). It splits large N-SDUs from the PduR into N-PDUs, forwards them to FrIf using FrIf_Transmit, and reassembles received frames ([SWS_FrTp_01050], FrTp SWS p. 19). Processing only takes place in state FRTP_ON, i.e., between FrTp_Init and FrTp_Shutdown ([SWS_FrTp_01032], [SWS_FrTp_01036]). FrTp_MainFunction must run at least once per FlexRay cycle ([SWS_FrTp_01152]).

Context diagram: FrTp between PduR and FrIf, controlled by EcuM and BSW scheduler. Sources: [SWS_FrTp_00577], FrTp SWS p. 21

Transmission always begins with FrTp_Transmit. The call only allocates a channel and sets TX_SDU_AVAILABLE ([SWS_FrTp_00136], [SWS_FrTp_01039]). The MainFunction handles the rest: it fetches the data via PduR_FrTpCopyTxData, allocates the first free pool PDU, and decides on segmentation ([SWS_FrTp_01045], [SWS_FrTp_01048]). In "Decoupled Buffer Access" mode, FrIf retrieves the data later via FrTp_TriggerTransmit ([SWS_FrTp_01060]). PduR_FrTpTxConfirmation follows after each accepted request ([SWS_FrTp_01058]).

Sequence diagram: Acceptance of the request, processing in the MainFunction, confirmation per N-PDU and finally to the PduR. Sources: FrTp SWS p. 44, [SWS_FrTp_01042]

Upon reception, FrTp checks RxPduId and addresses against the connection configuration ([SWS_FrTp_01069], [SWS_FrTp_01071]). For a new connection, it calls PduR_FrTpStartOfReception, copies the fragments upwards, and transmits FlowControl if required ([SWS_FrTp_01078], [SWS_FrTp_01080]). Six variants are supported: unsegmented or segmented, with or without acknowledgment, with known or unknown length ([SWS_FrTp_01007]–[SWS_FrTp_01012]). Multiple connections share Tx PDU pools and are served alternately ([SWS_FrTp_01020], [SWS_FrTp_01096]).

In the event of an error, FrTp aborts in three situations and reports E_NOT_OK to the PduR: in case of an invalid or aborting flow status and when segmentation is required on 1:n connections ([SWS_FrTp_01198], [SWS_FrTp_01208]). Runtime errors are FRTP_E_SEG_ERROR and FRTP_E_NO_CHANNEL. Timers and counters such as the FC.WAIT limit bound waiting times ([SWS_FrTp_01100], [SWS_FrTp_01114]). Ongoing transmissions can be aborted with FrTp_CancelTransmit and FrTp_CancelReceive ([SWS_FrTp_01116], [SWS_FrTp_01181]).

more ›

Role in the FlexRay Stack and Module State

FrTp is the FlexRay transport layer according to ISO 10681-2. Where the specification does not define its own requirements, the module follows this standard and supports its N-PDU formats ([SWS_FrTp_01005], [SWS_FrTp_01006]). Upwards, FrTp serves the PduR. The PduR starts transmissions with FrTp_Transmit, aborts them, or changes parameters. FrTp returns data and results via PduR_FrTpStartOfReception, PduR_FrTpCopyRxData, PduR_FrTpCopyTxData, PduR_FrTpRxIndication, and PduR_FrTpTxConfirmation (FrTp SWS p. 19). Downwards, FrTp passes N-PDUs with FrIf_Transmit ([SWS_FrTp_01050]). FrIf responds with FrTp_RxIndication, FrTp_TxConfirmation, and FrTp_TriggerTransmit (FrTp SWS p. 21). EcuM calls FrTp_Init and FrTp_Shutdown (FrTp SWS p. 19). The BSW scheduler calls FrTp_MainFunction ([SWS_FrTp_00162], FrTp SWS p. 81).

A difference between the releases: Later versions place an L-SDU router (LSduR) between FrTp and FrIf (FrTp SWS p. 19). For R20-11, the direct interface to FrIf applies, as defined by [SWS_FrTp_00577] and [SWS_FrTp_01050].

Context diagram: FrTp is located between PduR and FrIf and is controlled by EcuM and BSW scheduler. Sources: FrTp SWS p. 19, FrTp SWS p. 21, [SWS_FrTp_00577]

The module knows two states, FRTP_OFF and FRTP_ON ([SWS_FrTp_01028]). Which one applies is recorded by the status variable FrTpState ([SWS_FrTp_01029], [SWS_FrTp_01106]). After power-on, FrTp is in FRTP_OFF ([SWS_FrTp_01030]). Only a successful FrTp_Init with a pointer to FrTp_ConfigType transitions to FRTP_ON ([SWS_FrTp_01032], [SWS_FrTp_00147], [SWS_FrTp_01194]). Segmentation and reassembly only run in FRTP_ON ([SWS_FrTp_01033]). FrTp_Shutdown terminates all open connections by simply stopping operation. It frees the resources and returns to FRTP_OFF ([SWS_FrTp_00148], [SWS_FrTp_01036]).

State diagram: FrTp processes data only between FrTp_Init and FrTp_Shutdown. Sources: [SWS_FrTp_01030], [SWS_FrTp_01032], [SWS_FrTp_01036], FrTp SWS p. 38

FrTp_MainFunction schedules the module and is the entry point for all processing tasks ([SWS_FrTp_00203], [SWS_FrTp_00580]). It must run at least once per FlexRay cycle ([SWS_FrTp_01152]). In contrast, the callbacks essentially only set flags: TX_SDU_AVAILABLE exists per channel ([SWS_FrTp_00415], [SWS_FrTp_00416]). RX_PDU_AVAILABLE exists per receivable N-PDU and is cleared after processing ([SWS_FrTp_00418], [SWS_FrTp_00421]).

Transmission Variants According to ISO 10681-2

FrTp supports six frame sequences. They differ in three points: whether the message is segmented, whether the receiver acknowledges, and whether the length is known at the start of transmission (FrTp SWS p. 27, FrTp SWS p. 31):

Variant	Characteristic frames	Reference
unsegmented, without acknowledgment, length known	STFU	[SWS_FrTp_01007]
unsegmented, with acknowledgment, length known	STFA → FC.ACK	[SWS_FrTp_01008]
segmented, without acknowledgment, length known	STFU, FC.CTS, CF, CFEOB, LF	[SWS_FrTp_01009]
segmented, with acknowledgment, length known	STFA, FC.CTS, CF, CFEOB, LF, FC.ACK	[SWS_FrTp_01010]
segmented, without acknowledgment, length unknown	as above, total length not until LF	[SWS_FrTp_01011], [SWS_FrTp_01067]
segmented, with acknowledgment, length unknown	as above, additionally FC.ACK	[SWS_FrTp_01012]

In the segmented, acknowledged variants, the FC.ACK likely follows after the LastFrame, completing the transfer. Question Q-f3c70b1506e2cde4 (open) This is an interpretation of the diagram texts, whose sequence is not unambiguous (FrTp SWS p. 29). The following diagram shows the segmented baseline case without acknowledgment.

Sequence diagram: The receiver enables each block via FC.CTS, and CFEOB completes a block. Sources: [SWS_FrTp_01009], FrTp SWS p. 28

Transmission with unknown length:

• It is enabled via a compiler switch ([SWS_FrTp_01062]).
• It is started with FrTp_Transmit and length 0 ([SWS_FrTp_01064], [SWS_FrTp_01043]).
• It terminates when the reported length parameter is 0 ([SWS_FrTp_01066]).
• The state is maintained by the flag TX_SDU_UNKNOWN_MSG_LENGTH per channel ([SWS_FrTp_01101], [SWS_FrTp_01102]).
• The receiver calls PduR_FrTpStartOfReception with expected length 0 ([SWS_FrTp_01184]).
• On a 1:n connection, FrTp_Transmit rejects such requests with E_NOT_OK and reports FRTP_E_SEG_ERROR ([SWS_FrTp_01187], FrTp SWS p. 47).

Connections, Channels, and PDU Pools

Each communication relationship is a dedicated FrTpConnection. Their number is post-build configurable ([SWS_FrTp_01014], [SWS_FrTp_01015]). Each connection has a module-wide unique address pair and a unique FRTP_SDUID ([SWS_FrTp_01017], [SWS_FrTp_01018]). Multiple connections can share a FrTpConnectionControl and a FrTpTxPduPool ([SWS_FrTp_01022], [SWS_FrTp_01020]). At runtime, multiple FrTpChannel operate in parallel; their number is defined by FrTpChanNum ([SWS_FrTp_00088], [SWS_FrTp_00228]). For transmission and reception, the channels alternate between "idle" and "busy" respectively ([SWS_FrTp_01117], [SWS_FrTp_01025]).

Context diagram: A half-duplex channel references a Tx and an Rx connection. Both reference control parameters and a Tx PDU pool. Sources: FrTp SWS p. 39, [SWS_FrTp_01020], [SWS_FrTp_01088]

Addresses:

• During transmission, FrTp adopts addresses from metadata SOURCE_ADDRESS_16 and TARGET_ADDRESS_16. Configured FrTpLa/FrTpRa take precedence here ([SWS_FrTp_01204], [SWS_FrTp_01205]).
• During reception, FrTp passes the addresses upwards as metadata. It uses the same addresses for FlowControl ([SWS_FrTp_01206]).

FrTp distributes bandwidth across the pools:

• The Tx N-PDUs of a pool are arranged in ascending network schedule order and may be of different lengths ([SWS_FrTp_01088], [SWS_FrTp_01089]).
• The TxPduPendingCounter of a channel counts unacknowledged N-PDUs ([SWS_FrTp_01091], [SWS_FrTp_01092]). A connection is only processed if it is 0 ([SWS_FrTp_01094]). This prevents Consecutive Frames from overtaking each other (FrTp SWS p. 61).
• Active connections take turns in sequence ([SWS_FrTp_01096]).
• Under bandwidth limitation, three rules apply: StartFrame and FlowControl are sent in the first PDU of the pool ([SWS_FrTp_01174], [SWS_FrTp_01177]). The transmitter uses only BC.MPPC PDUs ([SWS_FrTp_01175]). Pools may overlap ([SWS_FrTp_01176]).
• FrIf must schedule the PDUs of a connection in ascending order within a job (FrTp SWS p. 122).

Transmit Path: From FrTp_Transmit to PduR_FrTpTxConfirmation

Every transmission begins with FrTp_Transmit ([SWS_FrTp_00136], [SWS_FrTp_00149]). The call sets TX_SDU_AVAILABLE only if the TxPduId is valid and a channel is available ([SWS_FrTp_01039]). Otherwise, it terminates with E_NOT_OK. The same applies if a transmission is already in progress for the same address ([SWS_FrTp_01041], [SWS_FrTp_01200]).

The actual work is performed by FrTp_MainFunction:

1. It queries the available length via PduR_FrTpCopyTxData ([SWS_FrTp_01042]).
2. It allocates the first free FrTpTxPdu ([SWS_FrTp_01045]).
3. It decides on segmentation ([SWS_FrTp_01048]).
4. It copies data in PDU length ([SWS_FrTp_01123]).
5. It passes the N-PDU with the exact length to FrIf_Transmit ([SWS_FrTp_01051]).

FrTp SWS p. 44 shows the sequence.

Activity diagram: Decision between unsegmented and segmented transmission, including abortion on 1:n connections. Sources: [SWS_FrTp_01047], [SWS_FrTp_01048], [SWS_FrTp_01208], FrTp SWS p. 51

Important for throughput: If no PDU is available, FrTp defers the connection until the next MainFunction call ([SWS_FrTp_01047]).

After each N-PDU, FrIf calls FrTp_TxConfirmation. This sets FrTpTxPdu to "idle" ([SWS_FrTp_01052], [SWS_FrTp_01054]). Channel and flag are released as soon as three conditions are met: all data transmitted, positively acknowledged, and, if configured, confirmed ([SWS_FrTp_01056], [SWS_FrTp_01057]). PduR_FrTpTxConfirmation follows after every accepted request, with E_OK only in case of success ([SWS_FrTp_01058]). Two buffer access types exist for transmission: "Immediate" and "Decoupled Buffer Access" ([SWS_FrTp_01084]). With "Decoupled", FrIf fetches the data later via FrTp_TriggerTransmit. This call copies address information, PCI, and payload into the provided buffer ([SWS_FrTp_01060], [SWS_FrTp_01061], FrTp SWS p. 50).

Sequence diagram: The request arrives synchronously and is processed asynchronously in the MainFunction; TriggerTransmit optionally follows (Decoupled). Sources: FrTp SWS p. 44, FrTp SWS p. 50, [SWS_FrTp_01058]

Receive Path and Reassembly

Reception begins with FrTp_RxIndication ([SWS_FrTp_00137]). FrTp processes an N-PDU only if two conditions are met ([SWS_FrTp_01069], [SWS_FrTp_01071]):

• The RxPduId is valid.
• The destination address matches FrTpLa and the source address matches FrTpRa.

Otherwise, the N-PDU is ignored ([SWS_FrTp_01072]). If no Rx channel is available, processing ends, and FrTp reports FRTP_E_NO_CHANNEL ([SWS_FrTp_01076], [SWS_FrTp_01186]). FrTp stores a StartFrame in a local buffer. This allows a gateway to process it correctly even in case of a temporary shortage of resources (FrTp SWS p. 56).

For a new connection, FrTp calls PduR_FrTpStartOfReception. The expected length as well as the content and size of the StartFrame are passed ([SWS_FrTp_01078], [SWS_FrTp_01193]). The R20-11 diagrams show where this call occurs in two variants: in FrTp_RxIndication (FrTp SWS p. 55) and in FrTp_MainFunction (FrTp SWS p. 86). R23-11 explicitly permits both (FrTp SWS p. 54).

Afterwards, FrTp copies the fragments via PduR_FrTpCopyRxData and transmits FlowControl where the protocol requires it ([SWS_FrTp_01138], [SWS_FrTp_01080]). It releases the channel once all data has been received and all FlowControls are confirmed ([SWS_FrTp_01081]). PduR_FrTpRxIndication always follows when PduR_FrTpStartOfReception was successful ([SWS_FrTp_01083]).

Sequence diagram: The callback checks and buffers; the MainFunction reassembles and sends FlowControl. Sources: FrTp SWS p. 55, [SWS_FrTp_01074], [SWS_FrTp_01083]

Cancellation and Runtime Parameters

Whether transmit cancellation is available is determined statically by FrTpTransmitCancellation; it is triggered with FrTp_CancelTransmit ([SWS_FrTp_01097], [SWS_FrTp_00384]). The effect depends on the progress:

• If the request is accepted but not yet started, the connection is released immediately. The receiver notices nothing ([SWS_FrTp_00385], FrTp SWS p. 63).
• If transmission is in progress, FrTp stops it with E_OK ([SWS_FrTp_01116]).
• E_NOT_OK follows if no connection is active or the last N-PDU of an unacknowledged transmission has already been passed to FrIf ([SWS_FrTp_01116]).

In the segmented case, a timeout expires at the receiver that terminates reception (FrTp SWS p. 59).

Sequence diagram: If the transmitter cancels an ongoing segmented transmission, the receiver terminates reception via timeout. Sources: [SWS_FrTp_01116], FrTp SWS p. 69

FrTp_CancelReceive cancels an ongoing reception if the RxPduId is valid and then returns E_OK ([SWS_FrTp_01181], [SWS_FrTp_01183]). In case of unsegmented reception or an ongoing LastFrame, the function rejects ([SWS_FrTp_01182]). FrTp_ChangeParameter changes the BandwidthControl values FrTpSCexp and FrTpMaxNbrOfNPduPerCycle at runtime ([SWS_FrTp_00242]). The bit layout corresponds to that of the FC(CTS) frame ([SWS_FrTp_01195]). The parameter identifier for this is TP_BC (ComStack Types p. 18). During ongoing reception, the change is rejected ([SWS_FrTp_01115]). After a successful change, the connection uses the new values ([SWS_FrTp_01156]).

Behavior in the event of an error

Development errors are specified in [SWS_FrTp_01201]:

• FRTP_E_UNINIT: Call without initialization; excluded are FrTp_Init and FrTp_GetVersionInfo.
• FRTP_E_PARAM_POINTER: NULL pointer.
• FRTP_E_INVALID_PDU_SDU_ID: Invalid SDU or PDU ID.
• FRTP_E_INVALID_PARAMETER: Invalid parameter.
• FRTP_E_UMSG_LENGTH_ERROR: Unknown length without appropriate configuration ([SWS_FrTp_01134]).
• an error code for a failed initialization.

The APIs check IDs and pointers and, in case of errors, return E_NOT_OK where they have a return value ([SWS_FrTp_01139], [SWS_FrTp_01145], [SWS_FrTp_01147]). Runtime errors are FRTP_E_SEG_ERROR (0x05) and FRTP_E_NO_CHANNEL (0x07). They are routed via Det_ReportRuntimeError ([SWS_FrTp_01208], [SWS_FrTp_00577]).

In three cases, the transmitter aborts and reports PduR_FrTpTxConfirmation with E_NOT_OK:

• A FlowControl has an invalid flow status or OVFLW/ABT ([SWS_FrTp_01198]).
• ACK_RET points to a position outside the buffer ([SWS_FrTp_01199]).
• A 1:n connection would have to be segmented (FrTp SWS p. 51).

A FrTp_TxConfirmation with E_NOT_OK releases the channel on both sides ([SWS_FrTp_01056], [SWS_FrTp_01081]). The flag RX_ERROR remembers a reception error until FlowControl may be sent. After the reaction (retry, negative acknowledgment, or cancellation), it is cleared ([SWS_FrTp_00429], [SWS_FrTp_00430]). On 1:n connections, there is neither acknowledgment nor retry ([SWS_FrTp_00598]).

Timers and timeouts follow the tables in the specification ([SWS_FrTp_01099], [SWS_FrTp_01100], FrTp SWS p. 67). The configuration must comply with the following conditions:

• FRTP_TIMEOUT_BS > FRTP_TIME_BR + FRTP_TIME_AR ([SWS_FrTp_00599])
• FRTP_TIMEOUT_CR > FRTP_TIME_CS + FRTP_TIME_AS ([SWS_FrTp_01153])
• a bound for the separation cycle exponent ([SWS_FrTp_00180])

If the PduR returns BUFREQ_E_BUSY during transmission, FrTp retries up to FrTpTimeCs times ([SWS_FrTp_01196]). The counters are limited ([SWS_FrTp_01105], [SWS_FrTp_01114]). What happens upon reaching a limit is specified by [SWS_FrTp_01113]; the associated table is not available here. If the receiver lacks a buffer, it sends FC.WAIT. The number of these frames is limited by FrTpMaxFCWait (FrTp SWS p. 69).

Sequence diagram: If the buffer is missing, the receiver sends FC.WAIT until the counter limit takes effect; afterwards, FC.CTS resumes transmission. Sources: [SWS_FrTp_01105], [SWS_FrTp_01114], FrTp SWS p. 70

Further detailed evidence

• Lifecycle and scheduling: [SWS_FrTp_01028], [SWS_FrTp_01152], FrTp SWS p. 88.
• Protocol variants: [SWS_FrTp_01007] to [SWS_FrTp_01012] with the diagrams starting at FrTp SWS p. 27.
• Transmit path and confirmation: [SWS_FrTp_01042], [SWS_FrTp_01058], FrTp SWS p. 85.
• Receive path: [SWS_FrTp_01078], [SWS_FrTp_01083].
• Bandwidth and pools: [SWS_FrTp_01096], [SWS_FrTp_01175], FrTp SWS p. 60, FrTp SWS p. 134.
• Retry scenarios (API retry versus PDU retry): FrTp SWS p. 106.
• Error catalog: [SWS_FrTp_01201], [SWS_FrTp_01208].