CAN Driver (Can)

A função síncrona e não reentrante Can_Init inicializa todo o módulo do driver CAN, bem como as unidades de hardware associadas, de acordo com a configuração passada [SWS_Can_00223].

Utilização e contexto de chamada

A chamada de Can_Init é realizada obrigatoriamente pelo ECU State Manager durante a fase de inicialização da unidade de controle, antes mesmo que qualquer outra função do driver CAN possa ser chamada [SWS_Can_91012]. Como parâmetro, a função recebe através de Config um ponteiro para a configuração do driver (const Can_ConfigType*) e não retorna nenhum valor [SWS_Can_00223].

Escopo de inicialização e transições de estado

No âmbito da inicialização, a função define todos os registradores de hardware necessários e inicializa todos os controladores CAN AUTOSAR_SWS_CANDriver p. 33:

• Inicialização de variáveis estáticas e flags internas [SWS_Can_91012],
• Configuração de ajustes comuns para a unidade de hardware CAN completa [SWS_Can_91012],
• Configurações específicas do controlador para cada controlador CAN individual [SWS_Can_91012].

Através da chamada da função são disparadas transições de estado do hardware CAN AUTOSAR_SWS_CANDriver p. 10, onde Can_Init realiza a configuração de registradores para transferir os controladores para o estado básico previsto [SWS_Can_91010] AUTOSAR_SWS_CANDriver p. 36.

Simultaneidade e restrições

Como Can_Init é especificada como não reentrante, nenhuma chamada paralela ou repetida deve ocorrer durante uma inicialização em andamento [SWS_Can_00223]. Além disso, determinadas configurações globais da unidade de hardware só podem ser definidas dentro de Can_Init AUTOSAR_SWS_CANDriver p. 33.

A função Can_DeInit serve para a desinicialização do módulo do driver CAN ([SWS_Can_91002]). Ela possui a assinatura void Can_DeInit(void), não recebe parâmetros, não fornece valor de retorno e é executada de forma síncrona e não reentrante ([SWS_Can_91002]). A interface está disponível através do cabeçalho Can.h ([SWS_Can_91002]).

A chamada inicia uma transição de estado controlada por software (AUTOSAR_SWS_CANDriver p. 10; AUTOSAR_SWS_CANDriver p. 41). Nisso, Can_DeInit altera o estado do módulo (AUTOSAR_SWS_CANDriver p. 33) e redefine todos os controladores CAN (AUTOSAR_SWS_CANDriver p. 41).

Simultaneidade e restrições

Para a execução aplicam-se pré-condições rígidas e requisitos de ordem relativos aos estados do hardware e do módulo:

• O chamador deve assegurar que nenhum controlador CAN esteja em um estado inadmissível (AUTOSAR_SWS_CANDriver p. 61); presumivelmente, processos de comunicação ativos devem ser encerrados previamente. Pergunta Q-311343fa42add3a3 (aberta)
• Se o módulo CAN não estiver no estado inicial exigido no momento da chamada (AUTOSAR_SWS_CANDriver p. 41), a função reporta o erro CAN_E_TRANSITION (AUTOSAR_SWS_CANDriver p. 61).
• Da mesma forma, o erro CAN_E_TRANSITION é acionado se um controlador CAN permanecer em um estado que impeça a desinicialização (AUTOSAR_SWS_CANDriver p. 61). Interpretação: o driver provavelmente pressupõe um estado parado de todos os controladores antes da transição. Pergunta Q-435095949dafba5c (aberta)

Interação

O comportamento de erro e de transição reflete os fluxos consolidados do driver, segundo os quais transições de estado inválidas são interceptadas de forma uniforme ([SWS_Can_00441]).

A função Can_SetControllerMode (disponibilizada através de Can.h com o Service-ID 0x03) executa transições de estado disparadas por software da máquina de estados do controlador CAN ([SWS_Can_00230], AUTOSAR_SWS_CANDriver p. 35). Ela realiza os ajustes de registradores relativos ao hardware para provocar as transições entre os estados básicos do controlador UNINIT, STOPPED, STARTED e SLEEP ([SWS_Can_91010], AUTOSAR_SWS_CANDriver §7.3 «CAN Controller State Machine»).

Utilização e semântica

A chamada ocorre com o parâmetro Controller para a identificação do controlador CAN e Transition do tipo Can_ControllerStateType para a especificação da transição de estado desejada ([SWS_Can_00230]). O serviço é definido como assíncrono e não reentrante (Non Reentrant) ([SWS_Can_00230]). Um valor de retorno de E_OK confirma que a solicitação foi aceita; E_NOT_OK indica que a solicitação foi rejeitada e que existe um erro de desenvolvimento ([SWS_Can_00230], [SWS_Can_00441]).

Sequência e interação

Após a definição da configuração dos registradores, Can_SetControllerMode é finalizada (AUTOSAR_SWS_CANDriver p. 38). Como o módulo Can não armazena as mudanças de estado do hardware em si ([SWS_Can_91010]), presume-se que a função cíclica Can_Mainfunction_Mode assuma a conclusão assíncrona ou a verificação da transição iniciada por Can_SetControllerMode (AUTOSAR_SWS_CANDriver p. 38). Pergunta Q-03edb1b665a1624b (aberta)

A função síncrona e reentrante Can_DisableControllerInterrupts desativa todas as interrupções para um controlador CAN especificado ([SWS_Can_00231]). A passagem ocorre através do parâmetro Controller sem valor de retorno ([SWS_Can_00231]).

Em relação ao contexto de chamada e à concorrência, a função foi projetada para ser reentrante e suporta chamadas múltiplas (AUTOSAR_SWS_CANDriver §8.3 «Can_DisableControllerInterrupts»). Interpretação: Uma chamada múltipla provavelmente incrementa um contador interno de aninhamento, de modo que as interrupções só voltem a ser ativadas após um número correspondente de chamadas de liberação (AUTOSAR_SWS_CANDriver §8.3 «Can_DisableControllerInterrupts», AUTOSAR_SWS_CANDriver §8.3 «Can_DisableControllerInterrupts»). Pergunta Q-61be56207aa92ee0 (aberta)

No âmbito do tratamento de erros, a especificação exige o disparo do erro CAN_E_UNINIT caso o módulo do driver ainda não esteja inicializado no momento da chamada (AUTOSAR_SWS_CANDriver §8.3 «Can_DisableControllerInterrupts»). Além disso, a especificação requer o disparo de um outro erro (AUTOSAR_SWS_CANDriver §8.3 «Can_DisableControllerInterrupts»); presumivelmente, isso serve para a verificação de um identificador de controlador inválido. Pergunta (aberta)

Na interação dentro do driver CAN, a chamada serve para proteger seções críticas relativas ao controlador enquanto o controlador permanece ativo (AUTOSAR_SWS_CANDriver §7.5 «Interrupt handling»). Limpezas formais e alterações históricas de interface do driver estão documentadas nas notas de release ([SWS_Can_00441]).

A função síncrona e reentrante Can_EnableControllerInterrupts reativa todas as interrupções permitidas para o controlador CAN especificado através do parâmetro Controller ([SWS_Can_00232]). Ela não possui valor de retorno e é disponibilizada através do arquivo de cabeçalho Can.h ([SWS_Can_00232]).

Em relação ao fluxo, a função lê flags de controle do lado do software (AUTOSAR_SWS_CANDriver p. 65). Se as interrupções do controlador tiverem sido desativadas várias vezes anteriormente, Can_EnableControllerInterrupts deve ser chamada o mesmo número de vezes antes da liberação propriamente dita (AUTOSAR_SWS_CANDriver p. 65). Interpretação: O driver provavelmente gerencia seções de bloqueio aninhadas através de contadores ou flags internos, de modo que as interrupções de hardware só sejam reativadas após a compensação completa de todas as chamadas de desativação. Pergunta Q-6781f0fc9ad7d221 (aberta)

Se a função for chamada antes de o driver CAN ter sido inicializado corretamente, ela reporta o erro CAN_E_UNINIT (AUTOSAR_SWS_CANDriver p. 66). Isso deve ser tratado no contexto do driver como um Development-Error ([SWS_Can_00441]). Pergunta Q-efbbcf03a2589e4e (aberta) No estado não inicializado, a função não executa nenhuma outra ação no controlador (AUTOSAR_SWS_CANDriver p. 66).

Uso e comportamento

A função síncrona Can_CheckWakeup verifica, para um determinado controlador CAN, se um evento de wake-up foi detectado ([SWS_Can_00360], AUTOSAR_SWS_CANDriver p. 48, AUTOSAR_SWS_CANDriver p. 67). Ela está disponível através do arquivo de cabeçalho Can.h e possui o ID de serviço 0x0b ([SWS_Can_00360]).

• Parâmetro: Controller (in) designa o identificador do controlador CAN cujo estado deve ser verificado quanto a um wake-up ([SWS_Can_00360]).
• Valor de retorno: Retorna Std_ReturnType. O valor de retorno E_OK sinaliza que a chamada da API foi aceita, enquanto E_NOT_OK indica a rejeição ([SWS_Can_00360]).
• Simultaneidade: A função é definida como não reentrante (Non Reentrant) ([SWS_Can_00360]).

Configuração e tratamento de erros

A disponibilidade da função é configurável em tempo de pré-compilação; o serviço Can_CheckWakeup pode ser incluído no código ou removido dele por meio disso (AUTOSAR_SWS_CANDriver p. 67, AUTOSAR_SWS_CANDriver p. 97). Se a função for chamada antes que o driver CAN tenha sido inicializado, ela reporta o erro CAN_E_UNINIT (AUTOSAR_SWS_CANDriver p. 67).

Interação

A chamada de Can_CheckWakeup é normalmente disparada pela CAN Interface (AUTOSAR_SWS_CANDriver p. 48). No caso de um evento de wake-up no barramento, CanIf_CheckWakeup pode ser chamado durante o processamento de EcuM_CheckWakeup (AUTOSAR_SWS_CANInterface §7.18.4.1 «Wake-up detection»). De acordo com [SWS_CANIF_00395], CanIf consulta aqui, via Can_CheckWakeup() ou CanTrcv_CheckWakeup(), qual dispositivo de hardware concreto acionou o wake-up do barramento (AUTOSAR_SWS_CANInterface p. 55).

Utilização e semântica

A função Can_Write é chamada sincronicamente pelo módulo CanIf para passar uma mensagem CAN para transmissão ao driver CAN (CanDrv) ([SWS_Can_00233]). O chamador passa dois parâmetros:

• Hth: handle de transmissão de hardware, que define o objeto de transmissão a ser utilizado e determina implicitamente o controlador, já que os números de handle são unívocos dentro de uma unidade de hardware ([SWS_Can_00233]).
• PduInfo: ponteiro para uma estrutura com dados úteis de SDU, comprimento de dados e identificador CAN ([SWS_Can_00233]).

Antes do envio, a função verifica o objeto de transmissão de hardware endereçado (SWS_CANDriver p. 73) e protege o swPduHandle transmitido (SWS_CANDriver p. 43). Por meio do valor de retorno do tipo Std_ReturnType (SRS_BSWGeneral §5.2.3.6 «Types and keywords»), o E_OK sinaliza a aceitação da solicitação, enquanto CAN_BUSY indica que nenhum buffer de transmissão de hardware está disponível ([SWS_Can_00233], SWS_CANDriver p. 51).

Tratamento de erros

Se ocorrer um erro de desenvolvimento durante a execução, a função retorna E_NOT_OK ([SWS_Can_00233], [SWS_Can_00441]). Interpretação: códigos de erro DET específicos não são mencionados explicitamente no extrato disponível; no entanto, handles incorretos ou ponteiros inválidos provavelmente levam ao retorno de E_NOT_OK. Pergunta Q-ca947a7e0e4fd7d6 (aberta)

Simultaneidade e restrições

Can_Write é especificado como reentrante ou thread-safe ([SWS_Can_00233], SWS_CANDriver p. 49). Se uma chamada preemptiva não puder ser executada de forma reentrante pelo lado do driver, isso também será informado ao CanIf por meio do valor de retorno CAN_BUSY ([SWS_Can_00233]). O chamador deve garantir que a memória da PDU permaneça válida e inalterada até o retorno da chamada da função (SWS_CANDriver p. 45).

Interação

Por meio de [SWS_Can_00416], é transmitido na chamada de qual tipo de PDU se trata (SWS_CANDriver p. 51), com o driver suportando a transmissão até o comprimento máximo de PDU (SWS_CANDriver p. 52).

Utilização e contexto de chamada

A interface de call-out configurável <LPDU_CalloutName> é chamada opcionalmente pelo módulo CAN AUTOSAR a cada recepção de uma L-PDU (SWS_CANDriver §8.4.1 «Call-out function»). A declaração da função é disponibilizada através do arquivo de cabeçalho Can_Externals.h ([SWS_Can_00443]). O nome real da função é configurado de forma específica para o projeto ([SWS_Can_00443]).

Como parâmetros de entrada são passados o handle de recepção de hardware Hrh, o identificador CanId, o comprimento dos dados CanDataLegth bem como um ponteiro para os dados úteis CanSduPtr ([SWS_Can_00443]).

Filtragem e valor de retorno

A função fornece um valor boolean. Se o call-out retornar false, a L-PDU recebida não deve ser processada posteriormente ([SWS_Can_00444]). Interpretação: Se a chamada fornecer true, o encaminhamento regular da L-PDU para as camadas superiores deve ocorrer. Pergunta Q-e96e75e93881c3af (aberta)

Simultaneidade e restrições

A função é provida com a ID de serviço 0x20 e especificada como assíncrona (Asynchronous), bem como não reentrante (Non Reentrant) ([SWS_Can_00443]). Como ela é não reentrante, não devem ocorrer chamadas paralelas no mesmo contexto.

A função Can_MainFunction_Write executa o polling cíclico de confirmações de envio (TX-Confirmation), desde que o parâmetro CAN_TX_PROCESSING esteja configurado para POLLING [SWS_Can_00225], AUTOSAR SWS CAN Driver §7 «Scheduled functions». Ela não tem parâmetros (void Can_MainFunction_Write(void)), possui o Service-ID 0x01 e é disponibilizada através do arquivo de cabeçalho SchM_Can.h para o escalonador [SWS_Can_00225]. Através de chaves de configuração, a função pode ser ativada ou desativada para o processamento da transmissão de PDU AUTOSAR SWS CAN Driver §10 «CanMainFunctionWrite».

Se nenhum polling for utilizado no sistema para operações de envio, Can_MainFunction_Write deve, de acordo com a especificação, ser implementada como um define vazio AUTOSAR SWS CAN Driver §7 «Scheduled functions». Isso deve evitar overhead desnecessário do escalonador em sistemas puramente controlados por interrupção. Pergunta Q-2152a35397130945 (aberta)

Na interação com Can_MainFunction_Read e Can_MainFunction_BusOff, a rotina forma a interface cíclica do driver para o SchM AUTOSAR SWS CAN Driver §7 «Scheduled functions». O processamento de confirmação ocorre diretamente no recurso de hardware ou no contexto de Can_MainFunction_Write, dependendo do modo AUTOSAR SWS CAN Driver §7 «Hardware Resources». A chamada concreta e o mapeamento baseiam-se nos respectivos elementos referenciados AUTOSAR SWS CAN Driver §10 «CanMainFunctionWrite», AUTOSAR SWS CAN Driver §10 «Call Context», suportados por um processamento de Tx relativo ao controlador [SWS_Can_00441].

A função Can_MainFunction_Read serve para a consulta cíclica (polling) de mensagens de recepção CAN ([SWS_Can_00226]). Ela possui a assinatura void Can_MainFunction_Read (void) com o Service-ID 0x08 e é disponibilizada através do arquivo de cabeçalho SchM_Can.h para o controle de fluxo ([SWS_Can_00226]).

Utilização e configuração

A função executa o polling de indicações de RX quando o parâmetro de configuração CAN_RX_PROCESSING está ajustado para POLLING ([SWS_Can_00226]). No sistema, esse processamento pode ser configurado por controlador ([SWS_Can_00441]). Se nenhum polling for utilizado no driver CAN, Can_MainFunction_Read pode ser definida como uma macro vazia (AUTOSAR_SWS_CANDriver p. 77).

Simultaneidade e restrições

A chamada ocorre periodicamente no contexto do escalonador de acordo com o período de trigger parametrizado (AUTOSAR_SWS_CANDriver p. 22). Condições estritas se aplicam à execução:

• A função não pode ser interrompida por si mesma (AUTOSAR_SWS_CANDriver p. 47).
• Em geral, funções principais CAN como Can_MainFunction_Read não podem ser interrompidas (AUTOSAR_SWS_CANDriver p. 49), a fim de assegurar o acesso consistente aos recursos de driver e de hardware no modo de polling (AUTOSAR_SWS_CANDriver p. 46).

Interpretação: O intervalo de chamada configurado da tarefa provavelmente deve ser dimensionado de modo que uma fase de processamento esteja sempre concluída antes do início do próximo ciclo, uma vez que a reentrância é inadmissível (AUTOSAR_SWS_CANDriver p. 47). Pergunta Q-1f2fa9db14970b12 (aberta)

A função principal planejada Can_MainFunction_BusOff serve para o polling cíclico de eventos de bus-off dos controladores CAN, desde que estes estejam estaticamente configurados para polling [SWS_Can_00227], [SWS_Can_00109]. Ela possui a assinatura void Can_MainFunction_BusOff(void), não recebe parâmetros, não retorna valor e é disponibilizada através do cabeçalho SchM_Can.h para o controle de fluxo [SWS_Can_00227].

Utilização e interação

Eventos de hardware podem ser capturados no driver CAN ou por interrupção ou por polling de flags de status correspondentes, sendo que a configuração da consulta depende do hardware [SWS_Can_00099]. O driver também pode ser configurado de modo a dispensar completamente interrupções [SWS_Can_00007]. Se nenhum polling for utilizado em todo o sistema, o módulo Can pode implementar a função como uma macro vazia [SWS_Can_00183].

Se um evento de bus-off for detectado em Can_MainFunction_BusOff através de bits de status, o módulo realiza os ajustes de registradores necessários – por exemplo, para evitar uma recuperação automática de hardware SWS_CANDriver §7.3 «CAN Controller State Machine», [SWS_Can_91010]. Em seguida, o módulo notifica a camada superior CanIf através do callback associado, no qual ocorre a mudança de estado de software do controlador SWS_CANDriver §7.3 «CAN Controller State Machine».

Contexto de chamada e restrições

Na operação por polling, o contexto de chamada da notificação de callback não é a ISR, mas a tarefa executora de Can_MainFunction_BusOff; no entanto, todas as funções de callback devem ser implementadas como se fossem chamadas a partir do contexto de ISR SWS_CANDriver §7.9 «Notification concept». Em relação à reentrância, o payload não contém indicações explícitas; presumivelmente a função não é reentrante, pois acessa registradores e estados globais do controlador. Pergunta Q-38fcd72c40ce3e66 (aberta)

A função principal Can_MainFunction_Wakeup executa o polling cíclico de eventos de wake-up que estão estaticamente configurados para polling ([SWS_Can_00228]). A função possui a assinatura void Can_MainFunction_Wakeup(void), não recebe parâmetros, não retorna valor e é disponibilizada através do cabeçalho SchM_Can.h para o Schedule Manager (AUTOSAR_SWS_CANDriver p. 79). O período de execução da função é configurado em segundos (AUTOSAR_SWS_CANDriver p. 92).

No âmbito da máquina de estados do controlador CAN (SWS_CANDriver §7.3 «CAN Controller State Machine»), eventos externos de wake-up de hardware podem ser sinalizados, em vez de interrupções, através de um bit de status que é consultado em Can_MainFunction_Wakeup ([SWS_Can_91010]). Além disso, em transições de estado, a função faz polling de uma flag correspondente do registrador de status CAN até que esta sinalize a efetivação da alteração ([SWS_Can_00370]). Após uma mudança de estado bem-sucedida, o driver CAN reporta o novo estado à CAN Interface com a função de callback CanIf_ControllerModeIndication, em relação à CanIf ControllerId abstrata ([SWS_Can_00370]).

Em termos de configuração e uso de recursos, a API Can_MainFunction_Wakeup() pode ser ativada ou desativada para o tratamento de eventos de wake-up (AUTOSAR_SWS_CANDriver p. 97). Se nenhum polling for utilizado para eventos de wake-up na ECU, Can_MainFunction_Wakeup pode ser definida como uma macro vazia (AUTOSAR_SWS_CANDriver p. 79).

Utilização e funcionamento

A função principal agendada Can_MainFunction_Mode ([SWS_Can_00368]) realiza o polling de transições de estado dos controladores CAN. Ela não possui parâmetros de passagem nem valor de retorno (void Can_MainFunction_Mode(void), ID de serviço 0x0c) e é declarada através do cabeçalho SchM_Can.h SWS_CANDriver §8.5.1.5 «Can_MainFunction_Mode».

A função é chamada continuamente de forma cíclica (AUTOSAR_SWS_CANInterface p. 143). Ela verifica o hardware quanto à alteração do modo de um controlador CAN. Caso seja detectada uma alteração, a interface CAN é notificada por meio da chamada de CanIf_ControllerModeIndication(Controller, ControllerMode).

Monitoramento assíncrono de modo

Se uma alteração de modo tiver sido solicitada anteriormente via Can_SetControllerMode() e essa chamada retornar com sucesso para CanIf, Can_MainFunction_Mode reconhece a transição de estado concluída do hardware do controlador. Em seguida, ela informa CanIf de forma assíncrona mediante CanIf_ControllerModeIndication sobre o novo estado, como por exemplo CAN_CS_STARTED AUTOSAR_SWS_CANInterface p. 144.

Contexto de chamada e condições de contorno

Devido à disponibilização através de SchM_Can.h e à definição como Scheduled Function, a chamada periódica provavelmente ocorre por meio do BSW Scheduler. Pergunta Q-42edbc2aa591e8d7 (aberta) Não são definidos no payload códigos de erro específicos ou etapas de desenvolvimento para esta função.

O tipo de enumeração Can_ErrorStateType de Can_GeneralTypes.h descreve os estados de falha e de operação de um controlador CAN [SWS_Can_91003]. Ele mapeia o comportamento do controlador no barramento CAN através de três estados SWS_CANDriver §8.2.7 «Can_ErrorStateType»:

• CAN_ERRORSTATE_ACTIVE: o controlador CAN participa plenamente da comunicação do barramento [SWS_Can_91003].
• CAN_ERRORSTATE_PASSIVE: o controlador CAN participa da comunicação, mas não envia mais quadros de erro ativos (Error Frames) [SWS_Can_91003].
• CAN_ERRORSTATE_BUSOFF: o controlador CAN está isolado do barramento em decorrência de erros de transmissão graves e não participa mais da comunicação [SWS_Can_91003].

Em tempo de execução, o estado é consultado através do serviço síncrono de driver Can_GetControllerErrorState [SWS_Can_91004]. O parâmetro de saída ErrorStatePtr deste recebe o valor determinado. A função de nível superior CanIf_GetControllerErrorState na CAN Interface AUTOSAR_SWS_CANInterface p. 78 «CanIf_GetControllerErrorState» também utiliza a mesma assinatura. Com relação à simultaneidade, aplica-se que Can_GetControllerErrorState é especificado como não reentrante para o mesmo ControllerId [SWS_Can_91004].

Em caso de erro, Can_GetControllerErrorState fornece o valor de retorno E_NOT_OK e, no caso de consulta bem-sucedida, E_OK [SWS_Can_91004]. Com a detecção de desenvolvimento (DET) ativada, uma chamada antes da inicialização do driver leva ao erro CAN_E_UNINIT [SWS_Can_91005]. Um ControllerId inválido dispara o erro de desenvolvimento CAN_E_PARAM_CONTROLLER [SWS_Can_91006], e a passagem de um ponteiro nulo para ErrorStatePtr é rejeitada com um erro de desenvolvimento [SWS_Can_91007].

Interpretação: o chamador provavelmente deve alocar a área de memória para ErrorStatePtr sob sua própria responsabilidade, uma vez que a interface trata o ponteiro como parâmetro puramente de saída e exclui ponteiros nulos via erro de desenvolvimento. Pergunta Q-5c907c21bcb50893 (aberta)

O tipo de enumeração Can_ControllerStateType define os estados fundamentais de operação de um controlador CAN: CAN_CS_UNINIT, CAN_CS_STARTED, CAN_CS_STOPPED e CAN_CS_SLEEP [SWS_Can_91013]. O tipo é utilizado transversalmente entre módulos para o controle de estados guiado por software da máquina de estados do controlador CAN [SWS_Can_00017].

Os valores são aplicados nos seguintes contextos:

• Solicitação de estado: Em Can_SetControllerMode, o tipo serve como valor de transição (parâmetro Transition) para a solicitação assíncrona de um novo estado de operação [SWS_Can_00230]; de forma correspondente a isso, existe CanIf_SetControllerMode AUTOSAR_SWS_CANInterface §- «CanIf_SetControllerMode». O driver repassa a solicitação para o hardware do controlador, sendo que a alteração real de estado entra em vigor imediatamente ou após alguns milissegundos AUTOSAR_SWS_CANInterface §- «Can_SetControllerMode». Uma transição para CAN_CS_STARTED também aciona uma reinicialização do controlador [SWS_Can_00384].
• Consulta de status: Através de Can_GetControllerMode, o estado atual pode ser consultado de forma síncrona por meio do ponteiro de saída ControllerModePtr [SWS_Can_91014], [SWS_Can_91015] (de forma análoga em CanIf_GetControllerMode AUTOSAR_SWS_CANInterface §- «CanIf_GetControllerMode»).
• Indicação de estado: Após a mudança concluída, callbacks como CanSM_ControllerModeIndication [SWS_CanSM_00396], CanIf_ControllerModeIndication AUTOSAR_SWS_CANInterface §- «CanIf_ControllerModeIndication» bem como callbacks de usuário AUTOSAR_SWS_CANInterface §- «User_ControllerModeIndication» notificam camadas superiores de forma síncrona sobre o novo modo do controlador.

Quanto à simultaneidade e ao tratamento de erros, aplica-se: as funções de driver Can_SetControllerMode e Can_GetControllerMode são não reentrantes [SWS_Can_00230], [SWS_Can_91014]. Em caso de chamada de Can_GetControllerMode antes da inicialização do driver, o erro de desenvolvimento CAN_E_UNINIT é reportado e E_NOT_OK é retornado [SWS_Can_91016]. A função de callback CanSM_ControllerModeIndication é reentrante para diferentes controladores e reporta um ID de controlador não configurado com CANSM_E_PARAM_CONTROLLER ao DET [SWS_CanSM_00396], [SWS_CanSM_00397].

O tipo de enumeração Can_ErrorType define um superconjunto padronizado de causas de erros CAN que o hardware CAN típico pode registrar e reportar para camadas superiores [SWS_Can_91021]. Ele é disponibilizado através do arquivo de cabeçalho Can_GeneralTypes.h SWS_CANDriver §8.2.9 «Can_ErrorType».

Como a enumeração é concebida como um superconjunto, nem todo controlador CAN suporta obrigatoriamente todos os valores especificados [SWS_Can_91021]. Entre os estados de erro definidos estão:

• Erros de bit no monitoramento do barramento (CAN_ERROR_BIT_MONITORING1, CAN_ERROR_BIT_MONITORING0 ou, de forma resumida, CAN_ERROR_BIT),
• Erros de confirmação (CAN_ERROR_CHECK_ACK_FAILED, CAN_ERROR_ACK_DELIMITER),
• Perda de arbitragem do transmissor (CAN_ERROR_ARBITRATION_LOST),
• Estados de sobrecarga devido a buffers de recepção cheios (CAN_ERROR_OVERLOAD),
• Violações de formato e de bit stuffing (CAN_ERROR_CHECK_FORM_FAILED, CAN_ERROR_CHECK_STUFFING_FAILED),
• Erros de CRC (CAN_ERROR_CHECK_CRC_FAILED), bem como
• um bloqueio permanente do barramento em nível dominante (CAN_ERROR_BUS_LOCK) SWS_CANDriver §8.2.9 «Can_ErrorType».

Na interação dos módulos BSW, o tipo serve como parâmetro da função de callback CanIf_ErrorNotification para o repasse de erros de controlador para a CAN Interface AUTOSAR_SWS_CANInterface §8.x «CanIf_ErrorNotification». O valor passado deve corresponder ao estado de erro detectado pelo hardware subjacente AUTOSAR_SWS_CANDriver §7.x «Error Notification». Pergunta Q-d23c45dd3b23ec71 (aberta)