CAN Transport Layer (CanTp)

A CAN Transport Layer divide mensagens que não cabem em um frame CAN, controla o fluxo de dados via Flow Control e remonta segmentos recebidos de acordo com a ISO 15765-2 [SWS_CanTp_00033]. Ela está situada entre o PduR e o CanIf, não possui buffer próprio de dados úteis e copia dados de transmissão e recepção por segmentos por meio dos serviços de cópia da camada superior [SWS_CanTp_00298]. Ela finaliza cada transmissão aceita com uma notificação à camada superior: com sucesso via E_OK; em caso de timeout ou cancelamento, via E_NOT_OK. Tudo isso pressupõe CanTp_Init; a MainFunction cíclica monitora os timeouts.

mais ›

O CanTp é a CAN Transport Layer. Ele divide mensagens longas em frames CAN, controla o fluxo de dados e remonta segmentos recebidos; para isso, segue a ISO 15765-2, desde que a especificação não determine o contrário [SWS_CanTp_00033]. O módulo está situado entre o PduR e o CanIf e não possui buffer de dados úteis próprio. Ele copia os dados por segmentos por meio dos serviços de cópia da camada superior [SWS_CanTp_00298] [SWS_CanTp_00216].

Diagrama de contexto: as interfaces do CanTp para PduR, CanIf, gerenciamento de modo, escalonador e DET. Fontes: [SWS_CanTp_00216], SWS CanTp p. 17

Após a inicialização, o CanTp está em CANTP_OFF [SWS_CanTp_00168]. CanTp_Init com CanTp_ConfigType [SWS_CanTp_00208] coloca todas as conexões no estado de repouso [SWS_CanTp_00030]; depois disso, aplica-se CANTP_ON [SWS_CanTp_00170]. CanTp_Shutdown fecha todas as conexões sem notificar ninguém [SWS_CanTp_00202] [SWS_CanTp_00200]. Os canais de conexão operam de forma independente entre si com temporizadores próprios [SWS_CanTp_00122]. Se um canal de transmissão estiver ocupado, o CanTp rejeita novas solicitações com E_NOT_OK [SWS_CanTp_00123].

Na transmissão, CanTp_Transmit avalia apenas o comprimento (e, se aplicável, MetaData) [SWS_CanTp_00225]. Conforme o comprimento, segue um SF ou uma sessão segmentada [SWS_CanTp_00232]. Para cada segmento, o CanTp obtém os dados com PduR_CanTpCopyTxData [SWS_CanTp_00086] e aguarda por Flow Control após o FF e após cada bloco sob N_Bs [SWS_CanTp_00315]. Interpretação: a chamada apenas sinaliza a aceitação; o término da transferência ocorre de forma assíncrona via PduR_CanTpTxConfirmation [SWS_CanTp_00176] [SWS_CanTp_00204]. Pergunta (aberta)

Na recepção, o CanTp solicita primeiramente um buffer com PduR_CanTpStartOfReception [SWS_CanTp_00079]. Depois, copia cada CF com PduR_CanTpCopyRxData [SWS_CanTp_00269]. Se o buffer for escasso, o CanTp o consulta novamente em cada MainFunction e envia no máximo WFTmax FC(WAIT) [SWS_CanTp_00222] [SWS_CanTp_00223]. Ao final, ocorre PduR_CanTpRxIndication [SWS_CanTp_00084]. A CanTp_MainFunction cíclica monitora os timeouts [SWS_CanTp_00164].

Diagrama de sequência: recepção segmentada com negociação de buffer e Flow Control CTS/WAIT. Fontes: [SWS_CanTp_00269], [SWS_CanTp_00222], SWS CanTp p. 38

O CanTp trata erros de três maneiras. Ele reporta erros de desenvolvimento ao DET e retorna E_NOT_OK [SWS_CanTp_00294]. Erros de protocolo, como timeouts, abortam a sessão e vão para o PduR com E_NOT_OK [SWS_CanTp_00205] [SWS_CanTp_00311]. O mesmo se aplica a cancelamentos sob solicitação por meio dos serviços Cancel [SWS_CanTp_00255] [SWS_CanTp_00263]. Para IDs inválidos nos serviços Cancel, a R20-11 exige CANTP_E_PARAM_ID [SWS_CanTp_00254], enquanto releases mais recentes especificam outros códigos.

mais ›

Papel na pilha CAN: protocolo de transporte entre PduR e CanIf

O CanTp é a CAN Transport Layer. Ele divide mensagens que não cabem em um único frame CAN em segmentos, controla o fluxo de dados e remonta segmentos recebidos (SWS CanTp p. 24, SWS CanTp p. 17). A base é a ISO 15765-2: qualquer recomendação dessa norma se aplica, a menos que a especificação a exclua expressamente [SWS_CanTp_00033]. O CanTp executa segmentação e remontagem apenas no estado CANTP_ON [SWS_CanTp_00238].

Para cima, o CanTp disponibiliza os seguintes serviços ao PduR: CanTp_Transmit [SWS_CanTp_00212], CanTp_CancelTransmit [SWS_CanTp_00246] e CanTp_CancelReceive [SWS_CanTp_00257]. Ele próprio chama para cima PduR_CanTpStartOfReception, PduR_CanTpCopyRxData, PduR_CanTpCopyTxData, PduR_CanTpRxIndication e PduR_CanTpTxConfirmation, e para baixo CanIf_Transmit [SWS_CanTp_00216]. A camada inferior reporta frames recebidos via CanTp_RxIndication [SWS_CanTp_00078] e confirmações de transmissão via CanTp_TxConfirmation [SWS_CanTp_00076]. Ambas as funções devem poder ser chamadas em contexto de interrupção [SWS_CanTp_00235] [SWS_CanTp_00236]. Trechos de documentos mais recentes indicam como chamador o roteador de L-SDU (LSduR) (SWS CanTp p. 27). Já os requisitos da R20-11 referem-se à CAN Interface, como [SWS_CanTp_00031] e [SWS_CanTp_00335].

O CanTp não possui buffer próprio de dados úteis. Ele obtém os dados de transmissão diretamente na camada superior [SWS_CanTp_00298] e copia os dados recebidos imediatamente para a memória desta (SWS CanTp p. 35). Disso resultam períodos de bloqueio para a camada superior (SWS CanTp p. 35):

• Ela mantém o buffer de transmissão bloqueado assim que CanTp_Transmit retorna com E_OK, até que PduR_CanTpTxConfirmation chegue.
• Ela mantém o buffer de recepção bloqueado assim que fornecer BUFREQ_OK para PduR_CanTpStartOfReception, até que PduR_CanTpRxIndication chegue.

Diagrama de contexto: o CanTp fica entre o PduR e o CanIf. Ele é inicializado pelo gerenciamento de modo, acionado ciclicamente pelo escalonador e reporta erros ao DET. Fontes: [SWS_CanTp_00216], [SWS_CanTp_00217], [SWS_CanTp_00164], SWS CanTp p. 17, Mode Management Guide p. 54

Ciclo de vida: CANTP_OFF, CanTp_Init e canais de conexão independentes

O CanTp possui os estados CANTP_OFF e CANTP_ON [SWS_CanTp_00027]. Após a energização, o módulo está em CANTP_OFF [SWS_CanTp_00168]; somente nele a configuração post-build pode ser atualizada [SWS_CanTp_00169].

CanTp_Init recebe um ponteiro para CanTp_ConfigType [SWS_CanTp_00208] [SWS_CanTp_00340]. A função inicializa todas as variáveis globais e coloca cada conexão no estado de repouso CANTP_RX_WAIT ou CANTP_TX_WAIT [SWS_CanTp_00030]; depois disso, aplica-se CANTP_ON [SWS_CanTp_00170]. O ambiente deve chamar CanTp_Init antes de qualquer outra utilização [SWS_CanTp_00199]. No guia de gerenciamento de modo, uma regra do BswM assume essa chamada após NvM_ReadAll (Mode Management Guide p. 54). Uma nova chamada em CANTP_ON descarta todas as conexões em andamento e retorna ao estado de repouso [SWS_CanTp_00273] [SWS_CanTp_00111].

CanTp_Shutdown fecha todas as conexões abertas, libera os recursos e define CANTP_OFF [SWS_CanTp_00202]. Nesse processo, o CanTp não notifica ninguém sobre transmissões abortadas [SWS_CanTp_00200] (SWS CanTp p. 58).

Em CANTP_ON, várias conexões são executadas simultaneamente [SWS_CanTp_00096]:

• Cada N-SDU é associada estaticamente a um canal de conexão. Cada canal possui temporizadores, buffers e uma máquina de estados próprios [SWS_CanTp_00121] [SWS_CanTp_00122].
• Os canais são visíveis apenas internamente [SWS_CanTp_00285]. A ferramenta de configuração determina a quantidade deles [SWS_CanTp_00289].
• Se um canal de transmissão estiver em CANTP_TX_PROCESSING, o CanTp rejeita novas solicitações via CanTp_Transmit com E_NOT_OK [SWS_CanTp_00123]. O mesmo se aplica a uma N-SDU que já esteja em uma sessão em andamento [SWS_CanTp_00206].
• Se várias N-SDUs compartilharem um canal e não houver canal livre disponível, o CanTp rejeita a transmissão ou aborta a recepção [SWS_CanTp_00288] (SWS CanTp p. 42).

Diagrama de estados: após CanTp_Init, os canais de recepção e de transmissão alternam independentemente entre WAIT e PROCESSING; CanTp_Shutdown conduz de volta para CANTP_OFF. Fontes: [SWS_CanTp_00027], [SWS_CanTp_00030], [SWS_CanTp_00170], [SWS_CanTp_00202], SWS CanTp p. 27

Transmissão: do CanTp_Transmit até a confirmação

CanTp_Transmit recebe TxPduId e PduInfoPtr [SWS_CanTp_00212]. Sem MetaData, o CanTp avalia apenas o comprimento total SduLength e não acessa o buffer de dados [SWS_CanTp_00225] [SWS_CanTp_00299]. Com MetaData, ele armazena adicionalmente a informação de endereçamento para todos os SF, FF e CF [SWS_CanTp_00334]. Se os dados couberem em uma N-PDU, o CanTp envia um SF; caso contrário, abre uma sessão de múltiplos frames [SWS_CanTp_00232] (SWS CanTp p. 60). O comprimento máximo de transmissão (TX_DL) decorre de PduLength no EcuC [SWS_CanTp_00354]. Interpretação: a chamada reporta de forma síncrona apenas se a solicitação foi aceita; a transferência propriamente dita ocorre de forma assíncrona [SWS_CanTp_00176]. Pergunta Q-b6d13590324e2906 (aberta) Após a aceitação, o CanTp reporta o término em qualquer caso via PduR_CanTpTxConfirmation [SWS_CanTp_00177] [SWS_CanTp_00204].

Para cada segmento (SF, FF, CF), o CanTp chama PduR_CanTpCopyTxData [SWS_CanTp_00086]; até a primeira chamada, o temporizador N_Cs fica em execução [SWS_CanTp_00167]. Se a camada superior retornar BUFREQ_E_BUSY, o CanTp tenta novamente mais tarde [SWS_CanTp_00184]. O CanTp sempre define o parâmetro de repetição como NULL, porque a ISO 15765-2 não prevê repetição [SWS_CanTp_00272].

Após o FF e após o último CF de cada bloco, o CanTp aguarda sob N_Bs por um frame de Flow Control [SWS_CanTp_00315]. Com ele, o receptor libera CFs adicionais ou os atrasa [SWS_CanTp_00282]. Se a sessão for concluída com sucesso, segue-se PduR_CanTpTxConfirmation com E_OK [SWS_CanTp_00090]. O mesmo fluxo pull é demonstrado pelo exemplo de 50 bytes (SWS CanTp p. 37) e pelo caminho de DCM para CanTp (SWS PduR p. 104).

Diagrama de sequência: o CanTp solicita os dados por segmentos ao PduR, aguarda por Flow Control após o FF e após cada bloco e confirma ao final com E_OK. Fontes: [SWS_CanTp_00212], [SWS_CanTp_00086], [SWS_CanTp_00315], [SWS_CanTp_00090], SWS CanTp p. 73

Recepção: negociação de buffer, Flow Control e remontagem

A cada SF ou FF recebido, o CanTp reporta o início da recepção com PduR_CanTpStartOfReception [SWS_CanTp_00079]. O tamanho do buffer disponível retorna por meio de um parâmetro de saída e pode ser menor que a N-SDU [SWS_CanTp_00080]. Em caso de FF, o CanTp inicia previamente o temporizador N_Br [SWS_CanTp_00166]. Ele envia o Flow Control apenas quando o resultado estiver disponível; o conteúdo deste depende desse resultado [SWS_CanTp_00064] [SWS_CanTp_00277]. Todos os FCs de uma sessão de recepção contêm os mesmos valores para BS e STmin [SWS_CanTp_00067]. Um FC segue sempre após BS Consecutive Frames [SWS_CanTp_00278].

Após cada CF, o CanTp entrega os dados úteis com PduR_CanTpCopyRxData e obtém o buffer restante [SWS_CanTp_00269]. No CAN 2.0, são seis ou sete bytes por CF. Se o buffer restante após o último CF de um bloco não for suficiente para o próximo bloco, o CanTp inicia o temporizador N_Br [SWS_CanTp_00325] [SWS_CanTp_00082]. Enquanto esse temporizador estiver em execução:

• o CanTp consulta o buffer em cada execução da MainFunction, com comprimento 0 e NULL_PTR [SWS_CanTp_00222];
• o CanTp envia no máximo WFTmax FC(WAIT) consecutivos [SWS_CanTp_00223] (SWS CanTp p. 38).

Quando a sessão termina, seja com sucesso ou não, o CanTp chama PduR_CanTpRxIndication [SWS_CanTp_00084]. Com e sem padding, o CanTp repassa para cima apenas os bytes de dados efetivamente utilizados [SWS_CanTp_00116].

Diagrama de sequência: recepção segmentada com negociação de buffer, Flow Control em blocos e fase de espera com buffer escasso. Fontes: [SWS_CanTp_00079], [SWS_CanTp_00269], [SWS_CanTp_00222], [SWS_CanTp_00084], SWS CanTp p. 76

Diagrama de atividades: assim o CanTp decide para um SF ou FF recebido com base no estado do canal e no resultado de PduR_CanTpStartOfReception. Fontes: [SWS_CanTp_00124], [SWS_CanTp_00337], [SWS_CanTp_00081], [SWS_CanTp_00318], [SWS_CanTp_00353], SWS CanTp p. 67

Endereçamento, MetaData e padding

O endereçamento funcional (1:n) é permitido apenas para SF [SWS_CanTp_00092]. O CanTp rejeita uma sessão segmentada por meio de um identificador funcional e reporta CANTP_E_INVALID_TATYPE [SWS_CanTp_00093] (SWS CanTp p. 39). No Extended Addressing ou Mixed Addressing, o CanTp determina a N-SDU a partir de N_TA ou N_AE no primeiro byte de dados [SWS_CanTp_00095] [SWS_CanTp_00284] [SWS_CanTp_00283]. Para a atribuição dos identificadores, aplica-se (SWS CanTp p. 44):

• Cada NSduId é associado a exatamente um LSduId [SWS_CanTp_00035].
• O LSduId de um FC identifica exatamente um NSduId juntamente com N_TA ou N_AE [SWS_CanTp_00094].
• Múltiplas N-SDUs só podem referenciar a mesma N-PDU no Extended/Mixed Addressing ou com MetaData [SWS_CanTp_00328].

Conexões genéricas operam com MetaData. O CanTp armazena a informação de endereçamento de SF ou FF [SWS_CanTp_00330], repassa-a para PduR_CanTpStartOfReception [SWS_CanTp_00331] e verifica os CFs subsequentes contra ela [SWS_CanTp_00333]. Se o canal já estiver em recepção, o CanTp ignora um SF ou FF adicional com MetaData [SWS_CanTp_00337].

O padding é ativado por N-SDU (SWS CanTp p. 43). O valor de preenchimento é CANTP_PADDING_BYTE [SWS_CanTp_00059]. Para frames com no máximo 8 bytes de carga útil, aplica-se:

• Com Rx-Padding, o CanTp aceita SF e o último CF apenas com 8 bytes [SWS_CanTp_00344] e envia FCs com 8 bytes [SWS_CanTp_00347].
• Com Tx-Padding, o CanTp preenche SF e o último CF até 8 bytes [SWS_CanTp_00348].

Se um comprimento de transmissão não corresponder a nenhum DLC válido, o CanTp preenche até o próximo valor válido mais alto [SWS_CanTp_00351]. O CanTp deriva o comprimento de recepção RX_DL a partir do primeiro CAN_DL recebido [SWS_CanTp_00350].

Monitoramento de tempo, parâmetros de tempo de execução e cancelamento sob solicitação

CanTp_MainFunction [SWS_CanTp_00213] é chamado ciclicamente. Ele monitora N_As, N_Bs, N_Cs, N_Ar, N_Br, N_Cr bem como STmin [SWS_CanTp_00164] (SWS CanTp p. 63). Seu ciclo baseia-se em CanTpMainFunctionPeriod [SWS_CanTp_00300]. Esse valor deve corresponder ao tempo de ciclo da task chamadora (SWS CanTp p. 77). Como exemplo, a análise de temporização cita uma task de 5 ms (TR Timing Analysis p. 117).

Dois serviços acessam em tempo de execução os parâmetros de recepção BS e STmin de uma N-SDU: CanTp_ChangeParameter os modifica [SWS_CanTp_00302], CanTp_ReadParameter os lê [SWS_CanTp_00323]. Ambos existem apenas se CanTpChangeParameterApi = TRUE (SWS CanTp p. 61). BS é apenas um valor máximo que o CanTp pode ficar abaixo por razões de buffer [SWS_CanTp_00091]. Entre o FF e o último CF de uma sessão de recepção em andamento, o CanTp rejeita qualquer alteração com E_NOT_OK [SWS_CanTp_00303] [SWS_CanTp_00304]. Em conexões genéricas, uma alteração se aplica a todas [SWS_CanTp_00338].

Transmissões em andamento podem ser canceladas mediante solicitação:

• Transmissão: a função é ativada estaticamente via CanTpTc [SWS_CanTp_00242] e disparada com CanTp_CancelTransmit [SWS_CanTp_00274]. Em E_OK, o CanTp cancela a transmissão [SWS_CanTp_00243] [SWS_CanTp_00256] e relata PduR_CanTpTxConfirmation com E_NOT_OK [SWS_CanTp_00255]. No lado oposto, isso leva a um timeout (SWS CanTp p. 26).
• Recepção: CanTp_CancelReceive encerra uma recepção iniciada com FF [SWS_CanTp_00261] e relata PduR_CanTpRxIndication com E_NOT_OK [SWS_CanTp_00263]. No caso de um SF ou quando resta apenas o último CF pendente, o CanTp rejeita o cancelamento [SWS_CanTp_00262] (SWS CanTp p. 60).

Comportamento em caso de erro

Erros de desenvolvimento. Se a detecção estiver ativa, o CanTp relata o erro ao DET e retorna E_NOT_OK [SWS_CanTp_00294] [SWS_CanTp_00217] (SWS CanTp p. 49). Os códigos são definidos por [SWS_CanTp_00293]. Casos típicos:

• CANTP_E_UNINIT: uma função diferente de CanTp_GetVersionInfo é usada antes de CanTp_Init [SWS_CanTp_00031].
• CANTP_E_PARAM_POINTER: um ponteiro é NULL [SWS_CanTp_00319] [SWS_CanTp_00321] [SWS_CanTp_00322].
• CANTP_E_PARAM_ID: CanTp_ReadParameter recebe parâmetros inválidos [SWS_CanTp_00324].

Divergência entre os releases: para um PduId inválido nos serviços de cancelamento, o R20-11 exige CANTP_E_PARAM_ID [SWS_CanTp_00254] [SWS_CanTp_00260]. Trechos de documentos mais recentes citam, em vez disso, CANTP_E_INVALID_TX_ID ou CANTP_E_INVALID_RX_ID (SWS CanTp p. 59). Para o R20-11, aplica-se o requisito.

Erros de tempo de execução. Eles são enviados ao Default Error Tracer [SWS_CanTp_00352]:

• CANTP_E_PADDING: um frame é muito curto, apesar do padding [SWS_CanTp_00345] [SWS_CanTp_00346] [SWS_CanTp_00349].
• CANTP_E_OPER_NOT_SUPPORTED: um cancelamento afeta uma N-SDU sem transmissão em andamento [SWS_CanTp_00254].
• Para erros de protocolo, o trecho do documento cita adicionalmente CANTP_E_COM, CANTP_E_RX_COM e CANTP_E_TX_COM (SWS CanTp p. 52).

Erros de protocolo. Eles encerram a sessão com E_NOT_OK para a camada superior [SWS_CanTp_00205]:

• Lado de transmissão (notificação via PduR_CanTpTxConfirmation): falta de dados ao copiar [SWS_CanTp_00087], expiração de N_Cs [SWS_CanTp_00280], N_As [SWS_CanTp_00310] ou N_Bs [SWS_CanTp_00316], FC com OVFLW ou FS inválido [SWS_CanTp_00309] [SWS_CanTp_00317]. Após N_As, a N-PDU permanece bloqueada até que a TxConfirmation chegue [SWS_CanTp_00075].
• Lado de recepção (notificação via PduR_CanTpRxIndication): expiração de N_Ar [SWS_CanTp_00311] ou N_Cr [SWS_CanTp_00313], cópia rejeitada [SWS_CanTp_00271].
• Cancelamento sem notificação: se PduR_CanTpStartOfReception retornar BUFREQ_E_NOT_OK, o CanTp cancela; não se seguem FC nem indicação [SWS_CanTp_00081].
• N-PDUs inesperadas são tratadas pelo CanTp de acordo com uma tabela [SWS_CanTp_00057] (SWS CanTp p. 45).

O PduR encaminha a confirmação negativa para o usuário, por exemplo, para o DCM, que então cuida da recuperação (Error Description p. 29, Error Description p. 28). Erros de produção são tratados pelo DEM via FiM [SWS_CanTp_00291].

Diagrama de atividades: todas as causas de cancelamento resultam, para cada direção, em uma notificação negativa ao PduR. Fontes: [SWS_CanTp_00205], [SWS_CanTp_00343], [SWS_CanTp_00355], [SWS_CanTp_00342], [SWS_CanTp_00223], [SWS_CanTp_00084], Error Description p. 28

Evidências mais detalhadas

• Ciclo de vida e canais: [SWS_CanTp_00027], [SWS_CanTp_00030], [SWS_CanTp_00122]; máquina de estados em SWS CanTp p. 27.
• Transmissão: [SWS_CanTp_00212], [SWS_CanTp_00086], [SWS_CanTp_00204]; sequência de exemplo em SWS CanTp p. 37.
• Recepção e buffers: [SWS_CanTp_00079], [SWS_CanTp_00222]; exemplo de 49 bytes em SWS CanTp p. 38.
• Monitoramento de tempo: [SWS_CanTp_00164], [SWS_CanTp_00300].
• Endereçamento e padding: [SWS_CanTp_00092], [SWS_CanTp_00330], [SWS_CanTp_00344]; contexto em SWS CanTp p. 43.
• Códigos de erro: [SWS_CanTp_00293] (erros de desenvolvimento), [SWS_CanTp_00352] (erros de tempo de execução); tabela de N-PDUs inesperadas em [SWS_CanTp_00057].