FlexRay AUTOSAR Transport Layer (FrArTp)

This service initializes all global variables of the Flex Ray AUTOSAR Transport Layer and sets all states to idle.

This service closes all pending transport protocol connections by simply stopping operation, frees all resources and stops the Fr Ar Tp Module

Requests transmission of a PDU.

Requests cancellation of an ongoing transmission of a PDU in a lower layer communication module.

Request to change a specific transport protocol parameter (e.g. block size).

Indication of a received PDU from a lower layer communication interface module.

The lower layer communication interface module confirms the transmission of a PDU, or the failure to transmit a PDU.

Schedules the Flex Ray TP. (Entry point for scheduling)

Returns the version information.

Requests cancellation of an ongoing reception of a PDU in a lower layer transport protocol module.

This is the base type for the configuration of the Flex Ray Transport Protocol. A pointer to an instance of this structure will be used in the initialization of the Flex Ray Transport Protocol. The outline of the structure is defined in chapter 10 Configuration Specification.

[SWS_FrArTp_00023] ⌈In an SF-I the PCI consists of only one byte. This byte is divided in two parts, called FT (Frame Type) and DL (Data Length). Both parts are 4 Bit long. The FT field is common to every frame type because it identifies the respective type.⌋ An SF-I looks as follows see Table 7.4 (address information header is not depicted) FT (4 Bit) DL (4 Bit) Data (1 - 7 Byte) Table 7.4: Single Frame ISO 15765-2

[SWS_FrArTp_00024] ⌈For ISO 15765-2 Single Frames the FT field shall be set to 0x0.⌋

[SWS_FrArTp_00025] ⌈The DL field states the amount of the actual data bytes, ac- cording to ISO 15765-2 the values 0x1 - 0x7 (0x6 in FRARTP_ISO6 mode) are valid, so in an ISO 15765-2 compliant connection the size of the associated N-PDU has to be, depending on the addressing mode, 10 (9) or 12 (11) Bytes long, since the SF has this length.⌋ Including address information, the length of an SF-I reaches from 4 Byte (1 Byte pay- load, 1 Byte addressing) to 12 Bytes. The actual frame length can be derived consid- ering the addressing mode and looking in the length statement of the corresponding PduInfoType struct in the configuration. Error Handling

DL field Incoming SF - I frames with an invalid DL value of 0x0 or higher than 0x7 (0x 6 in FRARTP_ISO6 mode ) shall be ignored. This shall also be done if a value arrives which is higher than the amount of payload that can be derived from the length statement of the corresponding PduInfoType struct in the configuration and the addressing mod e.

[SWS_FrArTp_00029] ⌈An SF-E allows using the whole possible FlexRay payload of 254 Bytes for an unsegmented transfer.⌋ An SF-E looks as depicted in the Table 7.5 FT (4 Bit) Res (4 Bit) DL (8 Bit) Data (Length Depending on configuration) Table 7.5: Single Frame Extended

[SWS_FrArTp_00030] ⌈The PCI of an SF-E consists of two bytes. The FT field is 4 Bit long; for an SF-E, it shall be set to 0x4. The following nibble is reserved; it shall be set to 0x0.⌋

[SWS_FrArTp_00031] ⌈The next byte is the DL field and states the amount of payload contained in the SF-E. Depending on the configuration of the addressing mode (1 Byte Layer or 2 Byte) and the length of the associated N-PDU, all values except 0x00 and above 0xFA (1 Byte addressing) or above 0xF8 (2 Byte addressing) are valid here.⌋ The minimum length of such a frame is 5 Byte (1 Byte addressing, 1 Byte payload), the maximum is 254 Byte (FlexRay limit according to [11]). The actual frame length can be derived considering the addressing mode and looking in the length statement of the corresponding PduInfoType struct. Error Handling

[SWS_FrArTp_00034] ⌈The FrArTp takes the decision whether a message has to be segmented based on the message length, the possibility (depending on per channel configuration) to use SF-E frames and the size of the assigned N-PDU. Therefore, to start the transfer of such a long message, a First Frame is used.⌋ Note: See section 7.4.1 for more details.

[SWS_FrArTp_00035] ⌈To enable compliance with ISO 15765-2 on the one hand and to allow messages longer than 212-1 Byte on the other hand, there are several types of First Frames.⌋ Not compliant to ISO 15765-2

[SWS_FrArTp_00036] ⌈It can be statically per channel configured, whether a First Frame can also start a segmented message in a 1:n connection.⌋ Layer

[SWS_FrArTp_00037] ⌈For a FF-I, the FT field shall be set to 0x1.⌋

DL field Incoming FF - I frames with DL = 0x000 shall be ignored. Moreover , if the DL value is lower than the possible (from the PDU size, the addressing type and the channel specific Long Messages switch derivable) payload of a SF, the frame shall also be ignored. If acknowledgment is configured, in all the cases above additionally an AF with a negative acknowledgement shall be sent back to the sender.

DL field If the FR_DL value is lower than the possible (from the PDU size and the addressing type derivable) payload of an SF, the frame shall be ignored. If acknowled gement is configured for the corresponding channel, an AF with a negative acknowledgement shall be sent back to the sender.

[SWS_FrArTp_00058] ⌈If no error occurred, an FF-x is followed by Consecutive Frames until the whole message is transmitted.⌋ Not compliant to ISO 15765-2

[SWS_FrArTp_00059] ⌈If configured for the specific channel, a Consecutive Frame can also appear in a 1:n connection.⌋

SN field If no acknowledgement is configured, then in case of a wrong SN, i. e. after SN x does not follow SN x+1, the transfer shall be aborted and within PduR_ FrArTp RxIndication the result E_NOT_OK shall be returned.If acknowledgment is configured, after the bloc k end , a negative acknowledgement shall take place and then the transfer shall be aborted as described above.If R etry is configured too, then the transfer shall not be aborted but the R etry shall take place (up to FrArTpMaxRn times ).

[SWS_FrArTp_00064] ⌈A Flow Control frame is used in segmented 1:1 connections. Thus, it cannot appear in a 1:n connection. It allows the receiver to send information to the sender. It is sent after reception of an FF-x and after the last CF of a block if no error occurred.⌋ Flow Control Frames consist of FT, FS, BS, and STmin fields as depicted in the Table

[SWS_FrArTp_00072] ⌈If acknowledgement is configured, every block of CFs is in the case of a positive acknowledgement acknowledged by an FC frame (as it is in unac- knowledged connections). Additionally an SF-x, the last block of CFs is acknowledged by an AF in 1:1 connections, and, in the case of a negative acknowledgement, also other blocks. This frame type cannot appear in a 1:n connection. This type of frame looks similar to an FC frame but it has an additional byte.⌋ Acknowledgement Frames consist of FT, FS, BS, STmin, ACK, and SN fields as de- picted in the Table 7.10 FT (4 Bit) FS (4 Bit) BS (8 Bit) STmin (8 Bit) ACK (4 Bit) SN (4 Bit) Table 7.10: Acknowledgement Frame Layout

[SWS_FrArTp_00073] ⌈An Acknowledgement frame only consists of Protocol Control Information. This frame is identified by the value 0x7 of the FT field.⌋

[SWS_FrArTp_00074] ⌈FS field is the same as in an FC frame.⌋

[SWS_FrArTp_00075] ⌈BS field can only be set to the values 0x01 to 0x10 due to the

[SWS_FrArTp_00082] ⌈A value of the FR_FT field higher than 0x7 shall always be ignored.⌋ Layer

[SWS_FrArTp_00083] FT Error Handling in ISO 15765-2 compliant channels/con- nections ⌈ TP Layer Status SF-I FF-I (1:1) CF (1:1) FC Other Segmented Transmit within this connection in progress If reception is in progress within the connection, see corresponding cell below. Otherwise, process the SF-I as start of a new reception. If reception is in progress within the connection, see corresponding cell below. Otherwise, process the FF-I as start of a new reception. If reception is in progress within the connection, see corresponding cell below. Otherwise, ignore it. If awaited then process, otherwise ignore it. Ignore Segmented Receive within this connection in progress Terminate the current reception, report a PduR_FrArTpRxIndication with the result E_NOT_OK and process the SF-I as the start of a new reception. Terminate the current reception, report a PduR_FrArTpRxIndication with the result E_NOT_OK and process the FF-I as the start of a new reception. If awaited then process, otherwise ignore If transmission is in progress within the connection, see corresponding cell above. Otherwise ignore it Ignore Idle Process the SF-I as the start of a new reception Process the FF-I as the start of a new reception Ignore Ignore Ignore ⌋ Otherwise, the behavior is explained below:

[SWS_FrArTp_00086] FF-x and CF frames ⌈If not explicitly configured by the param- eter FrArTpGrpSeg for the particular channel, a FF-x or CF in a 1:n connection shall be ignored.⌋

[SWS_FrArTp_00087] FC and AF frames ⌈These frame types are not allowed to appear in 1:n connections; thus, they shall be ignored in that case.⌋

[SWS_FrArTp_00094] ⌈The FrArTp shall be implemented to support both sending and receiving within one connection. So the same connection can be utilized for sending and receiving.⌋() To explain it more in detail, imagine a connection being in idle state. If now the call FrArTp_Transmit() occurs, the local peer becomes the sender in this connection (Source Address of TP frame = FrArTpLa, Target Address of TP frame = FrArTpRa). Otherwise, if an FrArTp_RxIndication() occurred for an N-PDU which is mapped on the N-SDU of this connection, it would become the receiver (Source Address of TP frame = FrArTpRa, Target Address of TP frame = FrArTpLa). This feature is intended for connections in which sometimes one peer has to send data and sometimes the other in order not to need two connections in this case.

If a transfer was cancelled by the call of Fr Ar Tp_CancelTransmit , PduR_Fr Ar TpTxConfirmation shall be called with E_NOT_OK.

[SWS_FrArTp_00104] Upstream requirements: SRS_Fr_05090 ⌈The FrArTp also supports the optional service for changing the parameters FrArTp- MaxBs and FrArTpStMin / FrArTpStMinGrpSeg mentioned in [6] via the API call FrArTp_ChangeParameter. A change is not possible during an ongoing reception and shall lead to the return value E_NOT_OK.⌋

[SWS_FrArTp_00105] ⌈Depending on the message length and configuration of the FrArTp, a segmented or an unsegmented transfer will take place.⌋()

[SWS_FrArTp_00106] ⌈At the sender side, this principle works as follows: 1. The PDU Router calls the service FrArTp_Transmit. 2. The FrArTp shall call PduR_FrArTpCopyTxData in order to get all the data bytes of the SF-x. retry.TpDataState shall be set to TP_CONFPENDING when Retry is enabled. ⌋

[SWS_FrArTp_00107] ⌈If PduR_FrArTpCopyTxData for the SF-x returns BUFREQ_- E_BUSY, the call shall be repeated until FrArTpTimeCs expires. When the return value is BUFREQ_E_NOT_OK or after FrArTpTimeCs expired, the transfer shall be aborted by calling PduR_FrArTpTxConfirmation with E_NOT_OK.⌋

[SWS_FrArTp_00108] ⌈At the receiver side, the principle works as follows: 1. LSduR calls the service FrArTp_RxIndication. 2. The FrArTp shall call PduR_FrArTpStartOfReception to prepare reception. 3. The FrArTp shall call PduR_FrArTpCopyRxData to forward SF data. ⌋

[SWS_FrArTp_00110] ⌈At the sender side, this principle works as follows: 1. The PDU Router calls the service FrArTp_Transmit. 2. The FrArTp shall call PduR_FrArTpCopyTxData in order to get the data bytes of the FF and following CFs. ⌋

[SWS_FrArTp_00111] ⌈When Retry is enabled, the TP sends the FF-x without data. After reception of an FC, the data for the first CF is acquired with retry.TpDataState set to TP_DATACONF. For the following CFs, retry.TpDataState shall be set to TP_CONFPENDING.⌋

[SWS_FrArTp_00114] ⌈At the receiver side, this principle works as follows: 1. LSduR calls the service FrArTp_RxIndication. 2. The FrArTp shall call PduR_FrArTpStartOfReception to prepare reception. 3. The FrArTp shall call PduR_FrArTpCopyRxData to forward FF and CF data. ⌋

[SWS_FrArTp_00115] ⌈The block size used during reception is constant. The value is configured via FrArTpMaxBs, and can be changed via the API FrArTp_ChangePa- rameter.⌋ Layer

[SWS_FrArTp_00117] ⌈In case of failing to copy the received data, the remaining CFs of the current block shall be discarded. When the failure occured in the last block, and acknowledgement is enabled, an AF with a negative acknowledgement and FS = OVFLW shall be sent back to the sender. Otherwise, an FC with FS = OVFLW shall be sent back, but only if the initial call to PduR_FrTpStartOfReception returned BUFREQ_- E_OVFL.⌋

[SWS_FrArTp_00120] ⌈If acknowledgement with Retry is configured for the corre- sponding channel, no payload is sent within an FF-x if a segmented transfer takes place.⌋ This is necessary to retain backwards compatibility to the AUTOSAR release 3 FrTp on bus level.

[SWS_FrArTp_00121] ⌈If acknowledgment without Retry (or no acknowledgement) is configured, there are data bytes within an FF-x.⌋

Throughout this specification , many times the ignoring of frames is mentioned. Please note that an ignored frame does never affect a timer, i.e. never causes the restarting of a timer.

The only exception is at the receiver side when retry is configured and due to an errone ous frame an AF with negative acknowledgement is sent and therefore it is waited for the retry frame(s). In this case, the timer CR will be reset by the erroneous frame.

Module Header File Imported Type Com Stack_ Types Com Stack_ Types.h Buf Req _ Return Type Com Stack_ Types.h Pdu Id Type Com Stack_ Types.h Pdu Info Type Com Stack_ Types.h Pdu Length Type Com Stack_ Types.h Retry Info Type Com Stack_ Types.h T P Parameter Type Com Stack_ Types.h Tp Data State Type Std Std_ Types.h Std _ Return Type Std_ Types.h Std _ Version Info Type

Within this API , the upper layer module (called module) shall check whether the available data fits into the buffer size reported by Pdu Info Ptr - >Sdu Length. If it fits, it shall copy its data into the buffer provided by Pdu Info Ptr - >Sdu Data Ptr and update the length of the actual copied data in Pdu Info Ptr - >Sdu Length. If not, it returns E_ NOT_ OK without changing Pdu Info Ptr.

[SWS_FrArTp_00171] ⌈To achieve ISO 15765-2 compliance within a channel/connection, there are restrictions for some parameters. Those marked with a “*” are only relevant, if the features are compiled in (see section 10.2).⌋() These and those are explained in the table below: Parameter Allowed values FrArTpAckType (*) ‘FRARTP_NO’ FrArTpGrpSeg (*) false FrArTpTc (*) false FrArTpLm (*) ‘FRARTP_ISO’, ‘FRARTP_ISO6’ N-PDU length

Type of error Related error code Error value API service called while module is not initialized FRARTP_ E_ UNINIT 0x1 API service called with invalid pointer FRARTP_ E_ PARAM_ POINTER 0x2 API service called with invalid SDU or PDU ID FRARTP_ E_ INVALID_ PDU_ SDU_ ID 0x3 Invalid configuration set selection FRARTP_ E_ INIT_ FAILED 0x4

The FlexRay AUTOSAR Transport Layer provides full d uplex capabilities for PDU pools and connections.

Fr If _ Transmit Fr If.h Requests transmission of a PDU. Pdu R _ Fr Ar Tp - Copy Rx Data Pdu R_ Fr Ar Tp.h This function is called to provide the received data of an I - PDU segment (N - PDU) to the upper layer. Each call to this function provides the next part of the I - PDU data. The size of the remaining buffer is wr itten to the position indicated by buffer Size Ptr. Pdu R _ Fr Ar Tp - Copy Tx Data Pdu R_ Fr Ar Tp.h This function is called to acquire the transmit data of an I - PDU segment (N - PDU). Each call to this function provides the next part of the I - PDU data unles s retry - >Tp Data State is TP_ DATARETRY. In this case the function restarts to copy the data beginning at the offset from the current position indicated by retry - >Tx Tp Data Cnt. The size of the remaining data is written to the position indicated by availa ble Data Ptr. Pdu R _ Fr Ar Tp - Rx Indication Pdu R_ Fr Ar Tp.h Called after an I - PDU has been received via the TP API, the result indicates whether the transmission was successful or not. Pdu R _ Fr Ar Tp - Start Of - Pdu R_ Fr Ar Tp.h This functio n is called at the start of receiving an N - SDU. The N - SDU might be fragmented into multiple N - PDUs (FF with one or more Reception following CFs) or might consist of a single N - PDU (SF). The service shall provide the currently available maximum buffer size when invok ed with Tp Sdu Length equal to 0. Pdu R _ Fr Ar Tp - Tx Confirmation Pdu R_ Fr Ar Tp.h This function is called after the I - PDU has been transmitted on its network, the result indicates whether the transmission was successful or not.

Det _ Report Error Det.h Service to report development errors.

[SWS_FrArTp_00221] ⌈When a new reception is initiated by the reception of a FF or SF, the TP checks for the availability of the associated channel and then calls PduR_FrArTpStartOfReception to inform the upper layer of the expected message size, and to retrieve information about the currently available buffer. With this call, the FrArTp provides the total size of the received data (SDU), and the data and size of the FF or SF to the upper layer. When this call succeeds, the connection is set to established, and PduR_FrArTpCopyRxData is called to provide the payload of the frame to the upper layer. ⌋()

[SWS_FrArTp_00224] ⌈If development error detection is enabled the function FrArTp_CancelReceive shall check the validity of FrArTpRxSduId parameter.⌋

[SWS_FrArTp_00226] ⌈The FrArTp shall abort the reception of the current N-SDU if the service FrArTp_CancelReceive provides a valid FrArTpRxSduId.⌋

[SWS_FrArTp_00227] ⌈The FrArTp shall reject the request for receive cancellation by returning E_NOT_OK when • the cancelled connection is not active, or when • the FrArTp has already received the last frame of an unacknowledged connection, or when • the FrArTp has already provided the final AF of an acknowledged connection. ⌋

If the Fr Ar Tp_CancelReceive service has been successfully executed, the Fr Ar Tp shall call the PduR_Fr Ar TpRxIndication with E_NOT_OK.

[SWS_FrArTp_00230] ⌈When a new transmission is initiated by the call of FrArTp_Transmit, the TP checks for the availability of the associated channel, and sets the connection to established. Then the TP calls PduR_FrArTpCopyTxData to acquire the data for the SF or FF and following CFs.⌋()

[SWS_FrArTp_00232] ⌈The API function PduR_FrArTpCopyTxData has a parameter named retry, which is a pointer to a structure of type RetryInfoType. When Retry is disabled, retry shall always be set to NULL. Otherwise, the different values of retry.TpDataState shall be used to handle retries.⌋()

[SWS_FrArTp_00233] ⌈If Retry is enabled, the SF-x shall be sent again after reception of a negative AF. The FrArTp shall finish the transfer after reception of a positive AF by the call to PduR_FrArTpTxConfirmation with E_OK.⌋

[SWS_FrArTp_00234] ⌈When Retry is enabled, after reception of a negative AF, the last block must be retransmitted. To achieve this, the data for the first CF of the block is acquired with retry.TpDataState set to TP_DATARETRY while retry.TxTpDataCnt contains the size of the previously sent block in bytes. The buffer of the last block in the upper layer is only freed after reception of a positive AF by the call to PduR_FrArTpTxConfirmation with E_OK .⌋

When a transmissio n is still in progress, Fr Ar Tp_CancelTransmit shall return E_OK, and the transmission shall be stopped. When a connection is not active, or when the last N - PDU of a transmission without acknowledgement has already been forwarded to the FrIf, Fr Ar Tp_CancelT ransmit shall return E_NOT_OK.

The figure be low shows the layout of a FF - I: Figure 17 : First Frame ISO 15765 - 2

The layout of FF - E is shown below: Figure 18 : First Frame Extended

As shown below, Consecutive Frames consist of one byte PCI and th e payload. Figure 19 : Consecutive Frame

The layout of FC is shown below: Figure 20 : Flow Control frame

The layout of FC is shown below: Figure 21 : Acknowledgement Frame

V s + FrArTpTimeCs + ( FrArTpTimeoutAs * FrArTpMaxAs ) + V E < FrArTpTimeoutCr

STmin field The invalid values of this parameter range from 0x80 to 0xF0 and from 0xFA to 0xFF. If such a value is received , the value 0x7F shall be taken instead.

BS field The value 0x00 and all values higher than 0x10 shall cause the abortion of the transfer and PduR_ FrArTp TxConfirmation shall be called with the result E_NOT_OK . If additionally Retry is configured, such values shall not lead to the abortion of the transfer . Instead, the frame shall be ignored .

STmin field The invalid values of this pa rameter range from 0x80 to 0xF0 and from 0xFA to 0xFF. If such a value is received, the value 0x7F shall be taken instead.

ACK field Values higher than 0x1 are invalid and shall cause the abortion of the transfer and PduR_ FrArTp TxCo nfirmation shall be called with the result E_NOT_OK . If additionally Retry is configured, such values shall not lead to the abortion of the transfer . Instead, the frame shall be ignored .

SN field If a frame arrives that contains a n SN of a CF that has not been transmitted within the block, e.g . block size is 10 and this field has value 12, the transfer shall be aborted and PduR_ FrArTp TxConfirmation shall be called with the result E_NOT_OK . If additionally R etry is configured, the tra nsfer shall not be aborted . Instead, the frame shall be ignored .

General If for the channel no acknowledgement is configured, this frame type shall be ignored. In an unsegmented acknowledged transfer, the expected value for the fields BS, STmin , and SN is 0x0. Other values shall be tolerated.

FS field with Acknowledgement In case an AF with negative acknowledgement and FS = OVFLW arrives in an unsegmented acknowledged transfer or at the end of an segmented acknowledged transfer at the sender, regardless of Retry being c onfigured or not, the transfer shall be aborted and PduR_FrArTpTxConfirmation shall be called with the result E_NOT_OK .

AF frame If no acknowledgement is activated , this frame shall be ignored. Otherwise , on the receiver side or in idle state, these frames shall be ignored, too.

[SWS_FrArTp_00253] ⌈If acknowledgement is configured: In case of failing to copy the received data (either BUFREQ_E_NOT_OK or BUFREQ_E_OVFL was returned, or the available buffer is too small), an AF with a negative acknowledgement and FS = OVFLW is sent back to the sender.⌋ Layer

When the FrArTp frame does not requi re the whole length of its N - PDU ( in a SingleFrame, a First Frame , o r the last Consecutive Frame in a transfer), the remaining space (bits) in the N - PDU shall be set to 0.

[SWS_FrArTp_00256] ⌈To achieve an even distribution of PDUs to all currently trans- mitting and/or receiving connections associated with a PDU pool, the PDUs of this pool shall be assigned to active connections using round robin scheduling. A connec- tion that is currently receiving and transmitting may claim two PDUs in one round of the assignment: one for the FC, and one for an SF/FF/CF.⌋

[SWS_FrArTp_00257] ⌈The scheduling shall be executed in the context of the main function, and shall start with the connection where the scheduling stopped in the pre- vious cycle.⌋

[SWS_FrArTp_00258] ⌈Each PDU assignment cycle shall start with the prioritized PDUs. In this phase, PDUs are only assigned to active connections with prioritized PDUs, until their needs are satisfied. Afterwards, PDU assignment continues for all active connections.⌋

[SWS_FrArTp_00259] ⌈It must be ensured that the last PDU of a PDU pool within a FlexRay cycle is always used by the scheduling.⌋

[SWS_FrArTp_00260] ⌈If not all PDUs of the pool are used, the positions of the un- used PDUs are not relevant; gaps are allowed in any place.⌋

[SWS_FrArTp_00262] ⌈No state machine shall be used for the reception of an SF- x. When the corresponding connection is free, the single frame shall be forwarded immediately by calling PduR_FrArTpStartOfReception and, upon successful return of this function, PduRFrArTpCopyRxData and PduR_FrArTpRxIndication.⌋ The behavior in case of unsuccessful reception is described in [SWS_FrArTp_00298] and [SWS_FrArTp_00289].

If the AR timer ( FrArTpTimeou tAr ) expires, depending on the value of FrArTpMaxAr , sending shall be retried (because of still remaining attempts) or the transmission shall be aborted , and within PduR_ FrArTp RxIndication the result E_NOT_OK shall be returned.

If th e BS timer ( FrArTpTimeoutBs ) expires, the transmission shall be aborted , and within PduR_ FrArTp TxConfirmation the result E_NOT_OK shall be returned.

If the CR timer ( FrArTpTimeoutCr ) expires, the transmission shall be aborted , and wi thin PduR_ FrArTp RxIndication, the result E_NOT_OK shall be returned. If previously in the current block a sequence error oc c urred, this error shall be reported at the block end in PduR_ FrArTp RxIndication .

If the CR timer ( FrArTpTimeoutCr ) expires, an AF with negative acknowledgement shall be sent, the transmission shall be aborted , and within PduR_ FrArTp RxIndication, the result E_NOT_OK shall be returned. If previously in the current b lock a sequence error oc c urred, this error sha ll be reported at the block end in PduR_ FrArTp RxIndication .

If the BS timer ( FrArTpTimeoutBs ) expires, the sender shall retransmit the whole block up to FrArTpMaxRn times. After that, the transmission shall be aborted , and within PduR_ FrArTp TxConfirmation the result E_NOT_OK shall be returned.

If the CR timer ( FrArTpTimeoutCr ) expires, the receiver shall send an AF with negative acknowledgement and the sequence number of the missed CF. This shall be done up to FrArTpMaxRn times. After that, the transmission shall be aborted , and within PduR_ FrArTp RxIndication, the result E_NOT_OK shall be returned. If previously in t he current block a sequence error oc c urred, this error shall be reported at the block end in PduR_ FrArTp RxIndication .

If an AF arrives when it is expected, the action is as described in section 7.2.1.3 and in section error handling of section 7.3.6 .

If a non - faulty AF with positive acknowledgement arrives during a block, it shall be ignored.

If a non - faulty AF with negative acknowledgement arrives during a block, it shall be processed depending on the activation of the Retry mecha nism. If no R etry is configured the transfer shall be aborted. Otherwise , the AF shall be processed, i.e. starting with the stated sequence number the R etry shall take place.

If a faulty AF arrives during a block, it shall be ignored .

If a request is pending but the transmission has n ot been started, the FrArTp shall immediately call PduR_FrArTpTxConfirmation and free the connection .

If the transmission already has been started, the FrArTp shall immediately call PduR_Fr Ar TpTxConfirmation, and remember that the N - PDUs that have already been allocated for this connection cannot be used again before they have been confirmed. When requested via TriggerTransmit, the pending N - PDUs shall either be transferred to the FrIf as if they had not been canceled, or E_NOT_OK sha ll be returned .

If a channel references one PDU of a certain direction (received or transmitted) that is also referenced by another channel, both channels must reference exactly the same set of PDUs for this direction. This restriction ensures the pool semantics of referenced PDUs.

All PDUs of a PDU pool must have the same size, and all channels that reference these PDUs must have the same addressing type.

In the set of connections that are associated with a PDU pool, no two connections have the same address information, not even with reversed addresses.

The number of prioritized PDUs of all connections associated with a P DU pool must be less than the number of PDUs in the pool; otherwise, a set of active prioritized connections can lead to timeout in other connections.

If no transmit request is pending for the corresponding connection, there is nothing to do.

In case of a timeout of timer AS or AR, the behavior shall be as mentioned in section 7.4.7.2 .

In case of a timeout of timer AS, AR or BS, the behavior shall be as mentioned in section 7.4.7.2 .

If the AS timer ( FrArTpTimeoutAs ) expires, depending on the value of FrArTpMaxAs , sending shall be retried (because of still remaining attempts) or the transmission shall be aborted , and within PduR_ FrArTp TxConfirmation the result E_NOT_OK shall be returned.

SF - x, FF - x, CF/CF2 and FC frames The behavior shall be as depicted in Table 3 (also for 1:n connections). The ignoring of an FF - E shall be according to the value of FrArTpLm . Regarding CF and CF2 frames there is a special error handling in case Retry is con figured (otherwise CF2 frames are ignored): If the sender starts a block with another frame than expected, i.e. CF instead of CF2 or CF2 instead of CF, then the sender is doing a Retry that has not been requested by the receiver (maybe bec ause of lo sing th e FC - CTS frame on the bus). Therefore, the receiver always has to remember the old block size and send another FC - CTS at the end of this retransmitted block. Errors in the unnecessarily retransmitted block shall be ignored.

FS field In a segmented transfer, all val ues higher than 0x2 shall lead to the abortion of the transfer and PduR_ FrArTp TxConfirmation shall be called with the result E_NOT_OK . If additionally Retry is configured, such values shall not lead to the abortion of the transfer . Instead, the frame shall be ignored .

FS field If acknowledgment with R etry is configured, instead of abortion of the transfer, the frame shall be ignored.

DL field If this field contains the value 0x00 or, depending on the addressing mode, a value higher than 0xFA or higher than 0xF8, the SF - E shall be ignored. If acknowledgement is configured, additionally an AF with a negative acknowledgement shall be sent back to the sender.

General If messages longer than allowed by ISO 15765 - 2 are not configured ( FrArTpLm ) for the corresponding channel, this frame shall be ignored. This shall also be done if a value arrives which is higher than the amount of payload that can be derived from the length statement of the corresponding P du Info Type s truct and the addressing mode or if a value different from 0x0 arrives in the reserved nibble. If acknowledgement is configured, additionally an AF with a negative acknowledgement shall be sent back to the sender in the cases above.

If the available buffer reported by PduR_FrArTpStartOfReception is too small for the SF - x, or if PduR_FrArTpCopyRxData for the SF - x returns BUFREQ_E_NOT_OK , the FrArTp shall abort the transfer and call PduR_FrArTpRxIndication with E_NOT_OK .

If development error detection is enabled, all APIs with a parameter containing an SDU or a PDU identifier shall check the identifier an d raise the development error FRARTP_E_INVALID_PDU_SDU_ID when the identifier has not been configured.

If PduR_FrArTpCopyTxData returns BUFREQ_E_NOT_OK or when FrArTpTimeCs expired , the transfer s hall be aborted by calling PduR_FrArTpTxConfirmation with E_NOT_OK .

[SWS_FrArTp_00294] ⌈If Retry is not enabled, and PduR_FrArTpStartOfReception returns an available buffer size that is too small for the FF-x, FrArTp shall abort the transfer and call PduR_FrArTpRxIndication with E_NOT_OK.⌋

If PduR_FrArTpCopyRxData returns BUFREQ_E_NOT_OK , or when FrArTpMaxWft expired , the transfer shall be aborted and PduR_FrArTpRxIndication shall be called with E_NOT_OK .

If PduR_FrArTpCopy TxData for the FF - x (Retry not configured) or any of the CFs returns BUFREQ_E_BUSY , the call shall be repeated until FrArTpTimeCs expires .

If PduR_FrArTpCopyRxData for the FF - x (Retry not enabled ) or f or the last CF of a block (independent of Retry configuration) returns a n available buffer size that is not large enough for the next block , PduR_FrArTpCopyRxData shall be call ed repeated ly with info.SduLength equal to 0 until the available buffer is large enough. The calls shall be repeated until FrArTpTimeBr expires .

If PduR_FrArTpStartOfReception for the SF - x returns BUFREQ_E_NOT_OK or BUFREQ_E_OVFL , the transfer shall be aborted immediately without calling PduR_FrArTpRxIndication .

The DL field contains the length of the whole message. Due to the 12 b it length of this fi eld, messages up to 2 12 - 1 Bytes can be transferred.

If Retry is e nabled, and PduR_FrArTpStartOfReception returns an available buffer size that is too small for the first block, FrArTp shall call PduR_FrArTpCopyRxData with info.SduLength equal to 0 until the available buffer is large enough for the first block . The calls shall be repeated until FrArTpTimeBr expires.

When FrArTpTimeBr expires during calls to PduR_FrArTpCopyRxData with info.SduLen gth equal to 0, a WAIT frame (FC frame with FS = WT) shall be sent, and the retry phase shall start again, but at most FrArTpMaxWft times .