FlexRay Transport Layer (FrTp)

O FrTp transmite mensagens grandes entre o PduR e o FrIf de acordo com a ISO 10681-2 ([SWS_FrTp_01005]). Ele as segmenta e remonta, controla o fluxo e distribui a largura de banda através de pools de Tx-PDUs compartilhados. FrTp_Transmit apenas aceita uma solicitação de transmissão; o trabalho real é realizado pela FrTp_MainFunction cíclica, que deve ser executada pelo menos uma vez por ciclo FlexRay ([SWS_FrTp_01152]). São suportadas transmissões com e sem confirmação, bem como mensagens de comprimento desconhecido. Em caso de erros de protocolo ou segmentação inadmissível, o FrTp é abortado e reporta E_NOT_OK ao PduR.

mais ›

O FrTp é a camada de transporte para o FlexRay de acordo com a ISO 10681-2. Onde a especificação não definir nada próprio, o módulo segue esta norma ([SWS_FrTp_01005]). Ele divide grandes N-SDUs do PduR em N-PDUs, as repassa para o FrIf com FrIf_Transmit e remonta os quadros recebidos ([SWS_FrTp_01050], FrTp SWS p. 19). O processamento ocorre apenas no estado FRTP_ON, ou seja, entre FrTp_Init e FrTp_Shutdown ([SWS_FrTp_01032], [SWS_FrTp_01036]). A FrTp_MainFunction deve ser executada pelo menos uma vez por ciclo FlexRay ([SWS_FrTp_01152]).

Diagrama de contexto: FrTp entre PduR e FrIf, controlado pelo EcuM e pelo escalonador BSW. Fontes: [SWS_FrTp_00577], FrTp SWS p. 21

A transmissão sempre começa com FrTp_Transmit. A chamada apenas ocupa um canal e define TX_SDU_AVAILABLE ([SWS_FrTp_00136], [SWS_FrTp_01039]). A MainFunction cuida do restante: ela busca os dados via PduR_FrTpCopyTxData, aloca a primeira PDU livre do pool e decide sobre a segmentação ([SWS_FrTp_01045], [SWS_FrTp_01048]). No modo «Decoupled Buffer Access», o FrIf busca os dados posteriormente via FrTp_TriggerTransmit ([SWS_FrTp_01060]). PduR_FrTpTxConfirmation segue após cada solicitação aceita ([SWS_FrTp_01058]).

Diagrama de sequência: aceitação da solicitação, processamento na MainFunction, confirmação por N-PDU e, ao final, para o PduR. Fontes: FrTp SWS p. 44, [SWS_FrTp_01042]

Na recepção, o FrTp verifica a RxPduId e os endereços em relação à configuração da conexão ([SWS_FrTp_01069], [SWS_FrTp_01071]). Em uma nova conexão, ele chama PduR_FrTpStartOfReception, copia os fragmentos para cima e envia FlowControl quando necessário ([SWS_FrTp_01078], [SWS_FrTp_01080]). São suportadas seis variantes: não segmentada ou segmentada, com ou sem confirmação, com comprimento conhecido ou desconhecido ([SWS_FrTp_01007]–[SWS_FrTp_01012]). Múltiplas conexões compartilham pools de Tx-PDUs e são atendidas alternadamente ([SWS_FrTp_01020], [SWS_FrTp_01096]).

Em caso de erro, o FrTp é abortado em três situações e reporta E_NOT_OK ao PduR: em caso de Flow Status inválido ou de cancelamento e quando houver necessidade de segmentação em conexões 1:n ([SWS_FrTp_01198], [SWS_FrTp_01208]). Erros de tempo de execução são FRTP_E_SEG_ERROR e FRTP_E_NO_CHANNEL. Temporizadores e contadores como o limite de FC.WAIT limitam os tempos de espera ([SWS_FrTp_01100], [SWS_FrTp_01114]). Transmissões em andamento podem ser canceladas com FrTp_CancelTransmit e FrTp_CancelReceive ([SWS_FrTp_01116], [SWS_FrTp_01181]).

mais ›

Papel na pilha FlexRay e estado do módulo

O FrTp é a camada de transporte FlexRay de acordo com a ISO 10681-2. Onde a especificação não definir nada próprio, o módulo segue esta norma e suporta seus formatos de N-PDU ([SWS_FrTp_01005], [SWS_FrTp_01006]). Para cima, o FrTp atende o PduR. O PduR inicia transmissões com FrTp_Transmit, as cancela ou altera parâmetros. O FrTp retorna dados e resultados via PduR_FrTpStartOfReception, PduR_FrTpCopyRxData, PduR_FrTpCopyTxData, PduR_FrTpRxIndication e PduR_FrTpTxConfirmation (FrTp SWS p. 19). Para baixo, o FrTp transfere N-PDUs com FrIf_Transmit ([SWS_FrTp_01050]). O FrIf responde com FrTp_RxIndication, FrTp_TxConfirmation e FrTp_TriggerTransmit (FrTp SWS p. 21). O EcuM chama FrTp_Init e FrTp_Shutdown (FrTp SWS p. 19). O escalonador BSW chama FrTp_MainFunction ([SWS_FrTp_00162], FrTp SWS p. 81).

Uma diferença entre as versões: versões posteriores inserem um roteador de L-SDU (LSduR) entre o FrTp e o FrIf (FrTp SWS p. 19). Para o R20-11, aplica-se a interface direta com o FrIf, conforme estabelecido por [SWS_FrTp_00577] e [SWS_FrTp_01050].

Diagrama de contexto: o FrTp localiza-se entre o PduR e o FrIf e é controlado pelo EcuM e pelo escalonador BSW. Fontes: FrTp SWS p. 19, FrTp SWS p. 21, [SWS_FrTp_00577]

O módulo reconhece dois estados, FRTP_OFF e FRTP_ON ([SWS_FrTp_01028]). Qual deles é válido é registrado pela variável de estado FrTpState ([SWS_FrTp_01029], [SWS_FrTp_01106]). Após a inicialização, o FrTp está em FRTP_OFF ([SWS_FrTp_01030]). Apenas um FrTp_Init bem-sucedido com ponteiro para FrTp_ConfigType comuta para FRTP_ON ([SWS_FrTp_01032], [SWS_FrTp_00147], [SWS_FrTp_01194]). A segmentação e a remontagem ocorrem apenas em FRTP_ON ([SWS_FrTp_01033]). FrTp_Shutdown encerra todas as conexões abertas simplesmente parando a operação. Ele libera os recursos e retorna para FRTP_OFF ([SWS_FrTp_00148], [SWS_FrTp_01036]).

Diagrama de estados: o FrTp processa dados apenas entre FrTp_Init e FrTp_Shutdown. Fontes: [SWS_FrTp_01030], [SWS_FrTp_01032], [SWS_FrTp_01036], FrTp SWS p. 38

FrTp_MainFunction escalona o módulo e é o ponto de entrada de todas as tarefas de processamento ([SWS_FrTp_00203], [SWS_FrTp_00580]). Ela deve ser executada pelo menos uma vez por ciclo FlexRay ([SWS_FrTp_01152]). Os callbacks, por outro lado, basicamente apenas definem flags: TX_SDU_AVAILABLE existe por canal ([SWS_FrTp_00415], [SWS_FrTp_00416]). RX_PDU_AVAILABLE existe por N-PDU recebível e é limpa após o processamento ([SWS_FrTp_00418], [SWS_FrTp_00421]).

Variantes de transmissão conforme a ISO 10681-2

O FrTp suporta seis sequências de quadros. Elas diferem em três aspectos: se a mensagem é segmentada, se o receptor confirma e se o comprimento é conhecido no início da transmissão (FrTp SWS p. 27, FrTp SWS p. 31):

Variante	Quadros característicos	Referência
não segmentada, sem confirmação, comprimento conhecido	STFU	[SWS_FrTp_01007]
não segmentada, com confirmação, comprimento conhecido	STFA → FC.ACK	[SWS_FrTp_01008]
segmentada, sem confirmação, comprimento conhecido	STFU, FC.CTS, CF, CFEOB, LF	[SWS_FrTp_01009]
segmentada, com confirmação, comprimento conhecido	STFA, FC.CTS, CF, CFEOB, LF, FC.ACK	[SWS_FrTp_01010]
segmentada, sem confirmação, comprimento desconhecido	como acima, comprimento total apenas no LF	[SWS_FrTp_01011], [SWS_FrTp_01067]
segmentada, com confirmação, comprimento desconhecido	como acima, adicionalmente FC.ACK	[SWS_FrTp_01012]

Nas variantes segmentadas e confirmadas, o FC.ACK provavelmente deve seguir o LastFrame e concluir a transferência. Pergunta Q-f3c70b1506e2cde4 (aberta) Esta é uma interpretação das legendas das figuras, cuja ordem não é inequívoca (FrTp SWS p. 29). O diagrama a seguir mostra o caso básico segmentado sem confirmação.

Diagrama de sequência: o receptor libera cada bloco via FC.CTS, e o CFEOB conclui um bloco. Fontes: [SWS_FrTp_01009], FrTp SWS p. 28

Transmissão com comprimento desconhecido:

• Ela é ativada via chave de compilação ([SWS_FrTp_01062]).
• Ela é iniciada com FrTp_Transmit e o comprimento 0 ([SWS_FrTp_01064], [SWS_FrTp_01043]).
• Ela termina quando o parâmetro de comprimento reportado for 0 ([SWS_FrTp_01066]).
• O estado é mantido pela flag TX_SDU_UNKNOWN_MSG_LENGTH por canal ([SWS_FrTp_01101], [SWS_FrTp_01102]).
• O receptor chama PduR_FrTpStartOfReception com comprimento esperado 0 ([SWS_FrTp_01184]).
• Em uma conexão 1:n, FrTp_Transmit rejeita tais solicitações com E_NOT_OK e reporta FRTP_E_SEG_ERROR ([SWS_FrTp_01187], FrTp SWS p. 47).

Conexões, canais e pools de PDUs

Cada relação de comunicação é uma FrTpConnection própria. Sua quantidade é configurável em post-build ([SWS_FrTp_01014], [SWS_FrTp_01015]). Cada conexão possui um par de endereços exclusivo em todo o módulo e um FRTP_SDUID exclusivo ([SWS_FrTp_01017], [SWS_FrTp_01018]). Múltiplas conexões podem compartilhar uma FrTpConnectionControl e um FrTpTxPduPool ([SWS_FrTp_01022], [SWS_FrTp_01020]). Em tempo de execução, múltiplos FrTpChannel operam em paralelo; seu número é definido por FrTpChanNum ([SWS_FrTp_00088], [SWS_FrTp_00228]). Para envio e recepção, os canais alternam respectivamente entre «idle» e «busy» ([SWS_FrTp_01117], [SWS_FrTp_01025]).

Diagrama de contexto: um canal half-duplex referencia uma conexão Tx e uma conexão Rx. Ambas referenciam parâmetros de controle e um pool de Tx-PDUs. Fontes: FrTp SWS p. 39, [SWS_FrTp_01020], [SWS_FrTp_01088]

Endereços:

• Durante o envio, o FrTp adota endereços a partir dos metadados SOURCE_ADDRESS_16 e TARGET_ADDRESS_16. FrTpLa/FrTpRa configurados têm prioridade nisso ([SWS_FrTp_01204], [SWS_FrTp_01205]).
• Na recepção, o FrTp repassa os endereços para cima como metadados. Ele utiliza os mesmos endereços para FlowControl ([SWS_FrTp_01206]).

O FrTp distribui a largura de banda através dos pools:

• As Tx-N-PDUs de um pool estão em ordem crescente de escalonamento de rede e podem ter comprimentos diferentes ([SWS_FrTp_01088], [SWS_FrTp_01089]).
• O TxPduPendingCounter de um canal conta N-PDUs não confirmadas ([SWS_FrTp_01091], [SWS_FrTp_01092]). Uma conexão só é processada quando ele for 0 ([SWS_FrTp_01094]). Dessa forma, Consecutive Frames não podem se ultrapassar (FrTp SWS p. 61).
• Conexões ativas são atendidas alternadamente ([SWS_FrTp_01096]).
• Em caso de limitação de largura de banda, aplicam-se três regras: StartFrame e FlowControl vão na primeira PDU do pool ([SWS_FrTp_01174], [SWS_FrTp_01177]). O transmissor utiliza apenas BC.MPPC PDUs ([SWS_FrTp_01175]). Pools podem se sobrepor ([SWS_FrTp_01176]).
• O FrIf deve escalonar as PDUs de uma conexão em ordem crescente dentro de um job (FrTp SWS p. 122).

Caminho de transmissão: de FrTp_Transmit a PduR_FrTpTxConfirmation

Cada envio começa com FrTp_Transmit ([SWS_FrTp_00136], [SWS_FrTp_00149]). A chamada define TX_SDU_AVAILABLE apenas se a TxPduId for válida e um canal estiver livre ([SWS_FrTp_01039]). Caso contrário, ela termina com E_NOT_OK. O mesmo se aplica se já houver uma transmissão em andamento para o mesmo endereço ([SWS_FrTp_01041], [SWS_FrTp_01200]).

O trabalho real é feito pela FrTp_MainFunction:

1. Ela consulta o comprimento disponível via PduR_FrTpCopyTxData ([SWS_FrTp_01042]).
2. Ela aloca o primeiro FrTpTxPdu livre ([SWS_FrTp_01045]).
3. Ela decide sobre a segmentação ([SWS_FrTp_01048]).
4. Ela copia dados no comprimento da PDU ([SWS_FrTp_01123]).
5. Ela transfere a N-PDU com comprimento exato para FrIf_Transmit ([SWS_FrTp_01051]).

FrTp SWS p. 44 mostra a sequência.

Diagrama de atividades: decisão entre transmissão não segmentada e segmentada, incluindo cancelamento em conexões 1:n. Fontes: [SWS_FrTp_01047], [SWS_FrTp_01048], [SWS_FrTp_01208], FrTp SWS p. 51

Importante para o throughput: se nenhuma PDU estiver livre, o FrTp adia a conexão até a próxima chamada da MainFunction ([SWS_FrTp_01047]).

Após cada N-PDU, o FrIf chama FrTp_TxConfirmation. Isso define o FrTpTxPdu como «idle» ([SWS_FrTp_01052], [SWS_FrTp_01054]). O canal e a flag ficam livres assim que três condições forem atendidas: todos os dados enviados, confirmados positivamente e, se configurado, reconhecidos ([SWS_FrTp_01056], [SWS_FrTp_01057]). PduR_FrTpTxConfirmation ocorre após cada solicitação aceita, com E_OK apenas em caso de sucesso ([SWS_FrTp_01058]). Para a transmissão, existem dois tipos de acesso ao buffer: «Immediate» e «Decoupled Buffer Access» ([SWS_FrTp_01084]). Em «Decoupled», o FrIf busca os dados posteriormente via FrTp_TriggerTransmit. Esta chamada copia Address Information, PCI e dados úteis para o buffer fornecido ([SWS_FrTp_01060], [SWS_FrTp_01061], FrTp SWS p. 50).

Diagrama de sequência: a solicitação chega de forma síncrona e é processada de forma assíncrona na MainFunction; opcionalmente segue TriggerTransmit (Decoupled). Fontes: FrTp SWS p. 44, FrTp SWS p. 50, [SWS_FrTp_01058]

Caminho de recepção e remontagem

A recepção começa com FrTp_RxIndication ([SWS_FrTp_00137]). O FrTp processa uma N-PDU apenas se duas condições forem atendidas ([SWS_FrTp_01069], [SWS_FrTp_01071]):

• O RxPduId é válido.
• O endereço de destino corresponde a FrTpLa e o endereço de origem a FrTpRa.

Caso contrário, a N-PDU é ignorada ([SWS_FrTp_01072]). Se nenhum canal Rx estiver livre, o processamento termina e o FrTp reporta FRTP_E_NO_CHANNEL ([SWS_FrTp_01076], [SWS_FrTp_01186]). O FrTp armazena um StartFrame em um buffer local. Assim, um gateway pode processá-lo corretamente mesmo em caso de escassez temporária de recursos (FrTp SWS p. 56).

Em uma nova conexão, o FrTp chama PduR_FrTpStartOfReception. São passados o comprimento esperado, bem como o conteúdo e o tamanho do StartFrame ([SWS_FrTp_01078], [SWS_FrTp_01193]). Os diagramas do R20-11 mostram duas variantes de onde essa chamada ocorre: em FrTp_RxIndication (FrTp SWS p. 55) e em FrTp_MainFunction (FrTp SWS p. 86). O R23-11 permite expressamente ambas (FrTp SWS p. 54).

Depois disso, o FrTp copia os fragmentos via PduR_FrTpCopyRxData e envia FlowControl onde o protocolo exigir ([SWS_FrTp_01138], [SWS_FrTp_01080]). Ele libera o canal quando todos os dados tiverem sido recebidos e todos os FlowControls tiverem sido confirmados ([SWS_FrTp_01081]). PduR_FrTpRxIndication sempre se segue quando PduR_FrTpStartOfReception tiver sido bem-sucedido ([SWS_FrTp_01083]).

Diagrama de sequência: o callback verifica e armazena em buffer, a MainFunction remonta e envia FlowControl. Fontes: FrTp SWS p. 55, [SWS_FrTp_01074], [SWS_FrTp_01083]

Cancelamento e parâmetros de tempo de execução

A disponibilidade de cancelamento de transmissão é definida estaticamente por FrTpTransmitCancellation; ele é disparado com FrTp_CancelTransmit ([SWS_FrTp_01097], [SWS_FrTp_00384]). O efeito depende do progresso:

• Se a solicitação foi aceita, mas ainda não iniciada, a conexão é liberada imediatamente. O receptor não percebe nada ([SWS_FrTp_00385], FrTp SWS p. 63).
• Se a transmissão estiver em andamento, o FrTp a interrompe com E_OK ([SWS_FrTp_01116]).
• E_NOT_OK ocorre se nenhuma conexão estiver ativa ou se a última N-PDU de uma transmissão não confirmada já tiver sido entregue ao FrIf ([SWS_FrTp_01116]).

No caso segmentado, um timeout expira no receptor, encerrando a recepção (FrTp SWS p. 59).

Diagrama de sequência: se o transmissor cancelar uma transmissão segmentada em andamento, o receptor encerra a recepção por timeout. Fontes: [SWS_FrTp_01116], FrTp SWS p. 69

FrTp_CancelReceive cancela uma recepção em andamento se a RxPduId for válida e, então, retorna E_OK ([SWS_FrTp_01181], [SWS_FrTp_01183]). Em recepção não segmentada ou com LastFrame em andamento, a função rejeita ([SWS_FrTp_01182]). FrTp_ChangeParameter altera os valores de BandwidthControl FrTpSCexp e FrTpMaxNbrOfNPduPerCycle em tempo de execução ([SWS_FrTp_00242]). O layout de bits corresponde ao do quadro FC(CTS) ([SWS_FrTp_01195]). O identificador de parâmetro para isso é TP_BC (ComStack Types p. 18). Durante uma recepção em andamento, a alteração é rejeitada ([SWS_FrTp_01115]). Após alteração bem-sucedida, a conexão utiliza os novos valores ([SWS_FrTp_01156]).

Comportamento em caso de erro

Os erros de desenvolvimento estão definidos em [SWS_FrTp_01201]:

• FRTP_E_UNINIT: chamada sem inicialização; excetuam-se FrTp_Init e FrTp_GetVersionInfo.
• FRTP_E_PARAM_POINTER: ponteiro NULL.
• FRTP_E_INVALID_PDU_SDU_ID: ID de SDU ou PDU inválido.
• FRTP_E_INVALID_PARAMETER: parâmetro inválido.
• FRTP_E_UMSG_LENGTH_ERROR: comprimento desconhecido sem configuração correspondente ([SWS_FrTp_01134]).
• um código de erro para uma inicialização malsucedida.

As APIs verificam IDs e ponteiros e retornam E_NOT_OK em caso de erros, onde possuem um valor de retorno ([SWS_FrTp_01139], [SWS_FrTp_01145], [SWS_FrTp_01147]). Erros de tempo de execução são FRTP_E_SEG_ERROR (0x05) e FRTP_E_NO_CHANNEL (0x07). Eles são enviados via Det_ReportRuntimeError ([SWS_FrTp_01208], [SWS_FrTp_00577]).

Em três casos, o transmissor aborta e reporta PduR_FrTpTxConfirmation com E_NOT_OK:

• Um FlowControl possui Flow Status inválido ou OVFLW/ABT ([SWS_FrTp_01198]).
• ACK_RET aponta para uma posição fora do buffer ([SWS_FrTp_01199]).
• Uma conexão 1:n precisaria ser segmentada (FrTp SWS p. 51).

Uma FrTp_TxConfirmation com E_NOT_OK libera o canal em ambos os lados ([SWS_FrTp_01056], [SWS_FrTp_01081]). A flag RX_ERROR memoriza um erro de recepção até que o envio de FlowControl seja permitido. Após a reação (retry, confirmação negativa ou cancelamento), ela é limpa ([SWS_FrTp_00429], [SWS_FrTp_00430]). Em conexões 1:n, não há confirmação nem retry ([SWS_FrTp_00598]).

Temporizadores e timeouts seguem as tabelas da especificação ([SWS_FrTp_01099], [SWS_FrTp_01100], FrTp SWS p. 67). A configuração deve cumprir as seguintes condições:

• FRTP_TIMEOUT_BS > FRTP_TIME_BR + FRTP_TIME_AR ([SWS_FrTp_00599])
• FRTP_TIMEOUT_CR > FRTP_TIME_CS + FRTP_TIME_AS ([SWS_FrTp_01153])
• um limite para o expoente do ciclo de separação ([SWS_FrTp_00180])

Se o PduR retornar BUFREQ_E_BUSY durante o envio, o FrTp tenta novamente até FrTpTimeCs vezes ([SWS_FrTp_01196]). Os contadores são limitados ([SWS_FrTp_01105], [SWS_FrTp_01114]). O que acontece ao atingir um limite é definido por [SWS_FrTp_01113]; a tabela correspondente não está disponível aqui. Se faltar um buffer ao receptor, ele envia FC.WAIT. O número desses quadros é limitado por FrTpMaxFCWait (FrTp SWS p. 69).

Diagrama de sequência: na ausência do buffer, o receptor envia FC.WAIT até atingir o limite do contador; depois disso, o FC.CTS retoma a transmissão. Fontes: [SWS_FrTp_01105], [SWS_FrTp_01114], FrTp SWS p. 70

Evidências mais detalhadas

• Ciclo de vida e escalonamento: [SWS_FrTp_01028], [SWS_FrTp_01152], FrTp SWS p. 88.
• Variantes de protocolo: [SWS_FrTp_01007] a [SWS_FrTp_01012] com os diagramas a partir de FrTp SWS p. 27.
• Caminho de transmissão e confirmação: [SWS_FrTp_01042], [SWS_FrTp_01058], FrTp SWS p. 85.
• Caminho de recepção: [SWS_FrTp_01078], [SWS_FrTp_01083].
• Largura de banda e pools: [SWS_FrTp_01096], [SWS_FrTp_01175], FrTp SWS p. 60, FrTp SWS p. 134.
• Cenários de retry (repetição de API vs. repetição de PDU): FrTp SWS p. 106.
• Catálogo de erros: [SWS_FrTp_01201], [SWS_FrTp_01208].