CAN Interface (CanIf)

O CanIf é a camada independente de hardware entre drivers CAN ou transceivers e os módulos superiores de comunicação. Ele mapeia ordens de transmissão em Can_Write(), faz o buffering quando o hardware está ocupado e encaminha confirmações bem como recepções filtradas para callbacks configurados [SWS_CANIF_00318]. Ele controla modos de controller e transceiver por solicitação do CanSm e reporta de volta BusOff e mudanças de modo. Modos de canal de PDU comutam os caminhos de transmissão e recepção separadamente. A transmissão ocorre somente se o controller estiver em CAN_CS_STARTED e o caminho de transmissão estiver liberado [SWS_CANIF_00317].

mais ›

A CAN Interface (CanIf) assume todas as tarefas independentes de hardware da comunicação CAN. Entre elas estão ordens de transmissão, confirmações, indicações de recepção, notificações de erro, bem como o início e a parada de controllers CAN SWS CanIf p. 13. O CanIf acessa buffers de hardware exclusivamente por meio de serviços CanDrv [SWS_CANIF_00023]. Ele endereça controllers e transceivers de múltiplos drivers por meio de IDs abstratos [SWS_CANIF_00653]. Quais callbacks são chamados em PduR, CanNm, CanTp, CanSm ou EcuM é definido pela configuração [SWS_CANIF_00011] [SWS_CANIF_00724].

Diagrama de contexto: CanIf entre módulos superiores de comunicação, gerenciamento de modo e os drivers de controller e transceiver. Fontes: [SWS_CANIF_00012], [SWS_CANIF_00358], SWS CanIf p. 21

O EcuM inicializa o CanIf com CanIf_Init(). Depois disso, cada canal permanece em CANIF_OFFLINE [SWS_CANIF_00864], e até esse momento os serviços recusam chamadas com E_NOT_OK [SWS_CANIF_00661]. O início do controller via CanIf_SetControllerMode() é assíncrono. A conclusão é reportada por CanIf_ControllerModeIndication(), que o CanIf repassa ao CanSm [SWS_CANIF_00003] [SWS_CANIF_00711]. Somente depois disso CanIf_SetPduMode() aceita requisições [SWS_CANIF_00874]. Os modos de canal de PDU comutam os caminhos de transmissão e recepção separadamente. Eventos de controller como SLEEP, STOPPED ou BusOff os definem compulsoriamente [SWS_CANIF_00865] [SWS_CANIF_00866].

Diagrama de estados: os quatro modos de canal de PDU e suas transições por CanIf_SetPduMode() e eventos de controller. Fontes: [SWS_CANIF_00137], [SWS_CANIF_00866], SWS CanIf Fig. 7.8 p. 61

Durante a transmissão, CanIf_Transmit() chama Can_Write() [SWS_CANIF_00318]. Se o hardware estiver ocupado, o CanIf faz o buffering da L-PDU, caso um buffer esteja configurado [SWS_CANIF_00381]. Na próxima confirmação, ele envia a entrada de maior prioridade subsequentemente [SWS_CANIF_00668]. As L-PDUs recebidas passam por filtragem de software e verificação de comprimento antes de o CanIf encaminhá-las para <User_RxIndication> [SWS_CANIF_00389] [SWS_CANIF_00056].

Em caso de erro, um BusOff define o canal para CANIF_TX_OFFLINE e é reportado ao CanSm [SWS_CANIF_00724]. Na parada de um controller, o CanIf confirma todas as ordens de transmissão pendentes com E_NOT_OK [SWS_CANIF_00739]. Erros de parâmetros e de tempo de execução são enviados ao DET [SWS_CANIF_91006] [SWS_CANIF_91007].

mais ›

Papel: hub independente de hardware entre os drivers CAN e a pilha de comunicação

A CAN Interface (CanIf) assume todas as tarefas independentes de hardware da comunicação CAN de uma ECU. Os drivers CAN subjacentes cuidam apenas de seu hardware concreto. O CanIf processa ordens de transmissão, confirmações de transmissão, indicações de recepção e notificações de erro, além de iniciar e parar controllers CAN SWS CanIf p. 13. Ele acessa buffers de hardware exclusivamente por meio de serviços do CanDrv [SWS_CANIF_00023]. Serviços de controle operam com um ControllerId abstrato, que numera sequencialmente a partir de 0 os controllers de todas as instâncias CanDrv [SWS_CANIF_00653]. Para transceivers, aplica-se o mesmo com o TransceiverId [SWS_CANIF_00655].

Para baixo, o CanIf consolida as APIs de vários drivers CanTrcv em uma interface uniforme, mas ele próprio não contém lógica de transceiver SWS CanIf p. 21. Mesmo com múltiplos CanDrvs, cada callback existe apenas uma vez. O CanIf reconhece o driver chamador pelo ControllerId em Can_HwType SWS CanIf p. 68.

Para cima, o CanIf chama callbacks configuráveis como <User_TxConfirmation> e <User_RxIndication> [SWS_CANIF_00011] [SWS_CANIF_00012]. A configuração define o receptor concreto, como PduR_CanIfRxIndication [SWS_CANIF_00442] ou CanTp_TxConfirmation [SWS_CANIF_00550]. O CanIf reporta BusOff e mudanças de modo ao CanSm ou a um CDD [SWS_CANIF_00724] [SWS_CANIF_00711]. Validações de wake-up são enviadas ao EcuM [SWS_CANIF_00563].

Diagrama de contexto: o CanIf intermedeia entre os módulos superiores de comunicação, o gerenciamento de modo (CanSm, EcuM) e os drivers para controllers e transceivers CAN. Notificações de erro, segurança e espelhamento vão para DET, IdsM e Mirror. Fontes: [SWS_CANIF_00011], [SWS_CANIF_00724], [SWS_CANIF_00358], [SWS_CANIF_00905], [SWS_CANIF_00913], SWS CanIf p. 13

O escopo funcional depende fortemente da configuração. CanIf_Init() lê dos contêineres de configuração, entre outros, o número de controllers e a atribuição dos HTHs/HRHs SWS CanIf p. 22. HTH e HRH são handles para objetos lógicos de transmissão e de recepção, respectivamente [SWS_CANIF_00291] [SWS_CANIF_00292]. Muitos serviços podem ser desativados via switches de pré-compilação, por exemplo, CanIf_ReadRxPduData() [SWS_CANIF_00330] ou CanIf_SetBaudrate() [SWS_CANIF_00871]. Se nenhum nome estiver configurado para um callback não obrigatório, a chamada é omitida SWS CanIf p. 133. <User_ControllerBusOff>, por outro lado, deve estar sempre configurado [SWS_CANIF_00524].

Da inicialização ao controller iniciado

O EcuM chama CanIf_Init() [SWS_CANIF_00001]. Com isso, o CanIf inicializa variáveis, flags e buffers [SWS_CANIF_00085], bem como todos os buffers de L-PDU de transmissão [SWS_CANIF_00387]. Cada canal inicia em CANIF_OFFLINE [SWS_CANIF_00864]. Em seguida, os controllers permanecem no modo STOPPED, no qual não se transmite nem se recebe. O EcuM inicializa CanDrv e CanTrcv separadamente SWS CanIf p. 40. Antes da inicialização, todos os serviços, exceto CanIf_Init() e CanIf_GetVersionInfo(), retornam E_NOT_OK [SWS_CANIF_00661]. Quem chama CanIf_DeInit() [SWS_CANIF_91002] deve garantir que nenhuma transmissão esteja mais em execução SWS CanIf p. 81.

A inicialização do controller ocorre de forma assíncrona. CanIf_SetControllerMode() [SWS_CANIF_00003] chama Can_SetControllerMode() [SWS_CANIF_00308]. O driver reporta a mudança realizada mais tarde com CanIf_ControllerModeIndication() [SWS_CANIF_00699], e o CanIf repassa a notificação ao CanSm [SWS_CANIF_00711]. Em operação de polling, Can_MainFunction_Mode() reconhece a mudança SWS CanIf p. 152. Somente em CAN_CS_STARTED CanIf_SetPduMode() aceita requisições [SWS_CANIF_00874].

Diagrama de sequência: a solicitação de início é confirmada imediatamente, mas a mudança de modo é indicada apenas mais tarde. Em seguida, os caminhos de PDU podem ser liberados. Fontes: [SWS_CANIF_00308], [SWS_CANIF_00711], [SWS_CANIF_00874], SWS CanIf p. 156

Modos de canal de PDU: comutar caminhos de transmissão e de recepção separadamente

Cada canal de um controller possui um modo do tipo CanIf_PduModeType [SWS_CANIF_00137]. As camadas superiores o definem com CanIf_SetPduMode() e o leem com CanIf_GetPduMode() [SWS_CANIF_00008] [SWS_CANIF_00009]. Os modos detalhadamente SWS CanIf p. 58:

• CANIF_OFFLINE: ordens de transmissão são rejeitadas com E_NOT_OK e os buffers são esvaziados. Indicações e confirmações são suprimidas [SWS_CANIF_00073].
• CANIF_TX_OFFLINE: apenas o caminho de transmissão é bloqueado; a recepção permanece ativa [SWS_CANIF_00489].
• CANIF_TX_OFFLINE_ACTIVE: ordens de transmissão são confirmadas imediatamente, sem serem repassadas ao CanDrv [SWS_CANIF_00072].
• CANIF_ONLINE: transmissão e recepção estão plenamente ativas [SWS_CANIF_00075].

Eventos de controller definem compulsoriamente o modo de canal. CAN_CS_SLEEP leva a CANIF_OFFLINE [SWS_CANIF_00865]. CAN_CS_STOPPED e BusOff levam a CANIF_TX_OFFLINE [SWS_CANIF_00866].

Diagrama de estados: os quatro modos de canal de PDU com transições por CanIf_SetPduMode() e por eventos de controller. Os três modos restritos são agrupados em um superestado, como na especificação. Fontes: [SWS_CANIF_00864], [SWS_CANIF_00865], [SWS_CANIF_00866], [SWS_CANIF_00874], SWS CanIf Fig. 7.8 p. 61

Caminho de transmissão: CanIf_Transmit, buffering e Trigger Transmit

CanIf_Transmit() [SWS_CANIF_00005] determina o HTH e chama Can_Write(). O swPduHandle passado retorna mais tarde em CanIf_TxConfirmation() [SWS_CANIF_00318]. Antes disso, o CanIf define os dois bits mais significativos do CanId [SWS_CANIF_00243]. Se Can_Write() retornar E_OK, isso também se aplica à ordem de transmissão [SWS_CANIF_00162].

Uma ordem só é aceita sob estas condições:

• O controller está iniciado e o caminho de transmissão está online ou offline active [SWS_CANIF_00317].
• Com PnTxFilter ativo, passam apenas CanIfTxPduPnFilterPdus [SWS_CANIF_00750].
• Dados de comprimento excessivo são truncados com CanIfTxPduTruncation [SWS_CANIF_00894]; caso contrário, são rejeitados [SWS_CANIF_00900].

Passagens mais recentes de documentos mencionam adicionalmente CanXL_Write() SWS CanIf p. 87. Para o R20-11, apenas Can_Write() é normativo.

Diagrama de atividades: assim CanIf_Transmit() decide entre rejeição, confirmação simulada, transmissão direta e buffering. Interpretação: a ordem das verificações foi escolhida para fins de legibilidade. Fontes: [SWS_CANIF_00317], [SWS_CANIF_00382], [SWS_CANIF_00072], [SWS_CANIF_00381], [SWS_CANIF_00837], SWS CanIf Fig. 7.5 p. 51

Se Can_Write() reportar CAN_BUSY e CanIfPublicTxBuffering estiver ativo [SWS_CANIF_00063], o CanIf tenta fazer o buffering da L-PDU [SWS_CANIF_00381]. Isso pressupõe um tamanho de buffer maior que zero [SWS_CANIF_00835]. Se a mesma L-PDU já estiver no buffer, ela é sobrescrita [SWS_CANIF_00068]. Se o buffer estiver cheio, uma nova L-PDU é rejeitada com E_NOT_OK [SWS_CANIF_00837]. Uma L-PDU permanece sempre em apenas um lugar: no objeto de hardware ou no buffer do CanIf SWS CanIf p. 43.

Em CanIf_TxConfirmation() [SWS_CANIF_00007], o CanIf notifica o usuário responsável via <User_TxConfirmation> com E_OK [SWS_CANIF_00383]. Na mesma chamada, ele verifica os buffers do HTH liberado [SWS_CANIF_00386]. Ele entrega a entrada em espera com a maior prioridade para Can_Write() [SWS_CANIF_00668] [SWS_CANIF_00070]. Em caso de E_OK, ele remove a entrada imediatamente do buffer [SWS_CANIF_00183]. Passagens de documentos mais recentes denominam o callback como LSduR_CanIfTxConfirmation() SWS CanIf p. 157. No R20-11, aplica-se <User_TxConfirmation>.

Diagrama de sequência: com o hardware ocupado, a L-PDU é colocada em buffer. A confirmação de uma ordem anterior dispara subsequentemente o reenvio a partir do buffer. Fontes: [SWS_CANIF_00381], [SWS_CANIF_00386], [SWS_CANIF_00668], [SWS_CANIF_00183], SWS CanIf p. 138, SWS CanIf p. 143

No caso de Triggered Transmission, o usuário não entrega dados, mas sim um SduDataPtr NULL [SWS_CANIF_00882]. Se o hardware estiver livre, o driver obtém os dados via CanIf_TriggerTransmit() [SWS_CANIF_00883]. O CanIf encaminha a chamada para <User_TriggerTransmit> e retorna seu resultado [SWS_CANIF_00885]. Se o hardware estiver ocupado, o CanIf faz o buffering apenas do transmit request [SWS_CANIF_00881]. O CanId de L-PDUs dinâmicas pode ser alterado com CanIf_SetDynamicTxId() [SWS_CANIF_00189]. Como alternativa, ele provém dos MetaData [SWS_CANIF_00855] SWS CanIf p. 34.

Diagrama de sequência: no Trigger Transmit, o driver busca os dados junto ao usuário somente quando o objeto de hardware estiver livre. Fontes: [SWS_CANIF_00882], [SWS_CANIF_00885], [SWS_CANIF_00881], SWS CanIf Fig. 9.6 p. 137

Caminho de recepção: filtrar, verificar comprimento, encaminhar

Após uma recepção, o driver chama CanIf_RxIndication() com Mailbox e dados [SWS_CANIF_00006]. O processamento ocorre em três etapas:

• Filtro de software: para HRHs BasicCAN, o CanIf filtra por software [SWS_CANIF_00663] SWS CanIf p. 39. Uma rejeição encerra o processamento [SWS_CANIF_00389].
• Verificação de comprimento: ela segue, se configurada [SWS_CANIF_00390], e aceita pelo menos o comprimento configurado [SWS_CANIF_00026].
• Encaminhamento: L-PDUs aceitas vão para o <User_RxIndication> configurado [SWS_CANIF_00056] [SWS_CANIF_00135]. No caso de L-SDUs dinâmicas, o CanId vai parar em CAN_ID_32 [SWS_CANIF_00848].

Diagrama de atividades: filtro de software e verificação de comprimento decidem se uma L-PDU recebida é indicada. Efeitos colaterais dependentes de configuração são representados em paralelo. Fontes: [SWS_CANIF_00421], [SWS_CANIF_00389], [SWS_CANIF_00168], [SWS_CANIF_00199], [SWS_CANIF_00392], SWS CanIf Fig. 7.6 p. 51

Complementarmente, o CanIf oferece serviços de consulta. CanIf_ReadRxPduData() lê dados de um buffer de recepção próprio [SWS_CANIF_00194] [SWS_CANIF_00198], mas não é destinado à recepção por faixa (range reception) [SWS_CANIF_00329]. CanIf_ReadTxNotifStatus() e CanIf_ReadRxNotifStatus() redefinem o status durante a leitura [SWS_CANIF_00393] [SWS_CANIF_00394]. Este «read-and-consume» assegura que pelo menos um evento ocorreu desde a última chamada SWS CanIf p. 55. CanIf_GetTxConfirmationState() agrupa as confirmações de um controller inteiro [SWS_CANIF_00734].

Transceiver, Wake-up e Partial Networking

O CanIf encaminha os serviços de transceiver diretamente ao driver CanTrcv. CanIf_SetTrcvMode() chama CanTrcv_SetOpMode() [SWS_CANIF_00358], CanIf_GetTrcvMode() chama CanTrcv_GetOpMode() [SWS_CANIF_00363]. O CanIf repassa mudanças de modo do transceiver ao CanSm [SWS_CANIF_00712].

Para o wake-up, CanIf_CheckWakeup() consulta os controllers e transceivers quanto à fonte de wake-up [SWS_CANIF_00395] SWS CanIf p. 56. Para validação, o CanIf armazena a primeira recepção válida de um controller iniciado [SWS_CANIF_00286]. CanIf_CheckValidation() a reporta, então, via <User_ValidateWakeupEvent> [SWS_CANIF_00179].

Se o Partial Networking estiver ativo, um PnTxFilter sobrepõe uma camada adicional sobre os modos de canal para cada controller [SWS_CANIF_00747]. Ele é ativado em CAN_CS_SLEEP [SWS_CANIF_00749] e desativado novamente com a primeira confirmação ou indicação [SWS_CANIF_00751] [SWS_CANIF_00896] SWS CanIf p. 70.

Comportamento em caso de erro

BusOff: o driver reporta o erro com CanIf_ControllerBusOff() [SWS_CANIF_00218]. O CanIf define então o canal como CANIF_TX_OFFLINE [SWS_CANIF_00866] e reporta o BusOff ao CanSm [SWS_CANIF_00724] SWS CanIf Fig. 9.11 p. 147. A recuperação é controlada pelo CanSm via CanIf_SetControllerMode() SWS CanIf p. 160.

Diagrama de sequência: fluxo desde o reconhecimento de BusOff, passando pela notificação ao CanSm, até o reinício do controller. Fontes: [SWS_CANIF_00218], [SWS_CANIF_00866], [SWS_CANIF_00724], [SWS_CANIF_00918], SWS CanIf p. 154, SWS CanIf p. 160

Controller parado: ao entrar em CAN_CS_STOPPED, o CanIf esvazia os buffers de transmissão [SWS_CANIF_00485]. Ele confirma todas as ordens de transmissão pendentes com E_NOT_OK [SWS_CANIF_00739]. Dessa forma, cada PDU aceita recebe uma confirmação, positiva ou negativa SWS CanIf p. 54.

Notificações de erro: o CanIf reporta parâmetros inválidos como erros de desenvolvimento, por exemplo, CANIF_E_PARAM_CONTROLLERID [SWS_CANIF_00311] [SWS_CANIF_91006]. Erros de tempo de execução incluem, entre outros, CANIF_E_INVALID_DATA_LENGTH [SWS_CANIF_00168] e CANIF_E_STOPPED [SWS_CANIF_00382] [SWS_CANIF_91007]. Uma ordem de transmissão perdida reflete-se apenas no valor de retorno ou na ausência de confirmação Error Description p. 22. Eventos de segurança como CANIF_SEV_ERRORSTATE_PASSIVE são reportados pelo CanIf ao IdsM [SWS_CANIF_00913] [SWS_CANIF_00917].

Evidências mais detalhadas

• Inicialização e ciclo de vida: [SWS_CANIF_00001], [SWS_CANIF_00661], SWS CanIf p. 40
• Caminho de transmissão e buffering: [SWS_CANIF_00318], [SWS_CANIF_00836], SWS CanIf p. 46
• Cadeia de recepção: [SWS_CANIF_00415], SWS CanIf p. 50
• Callbacks configuráveis: [SWS_CANIF_00532], SWS CanIf p. 133