AUTOSAR Classic LIN

O cluster de módulos LIN Communication realiza a conexão padronizada de subsistemas de barramento LIN por meio dos módulos LinSM, LinIf, LinTrcv e Lin (SWS COMManager p. 19). Ele controla a transmissão de quadros baseada em schedule nos masters, bem como a avaliação reativa de cabeçalhos e o envio de dados nos slaves ([SWS_LinIf_91004], [SWS_Lin_00168]). Ao mesmo tempo, o cluster coordena a transição ordenada entre comunicação total e modo sleep, assim como o tratamento autônomo de erros através do sinal response_error ([SWS_LinIf_00763]).

mais ›

O cluster de módulos LIN Communication disponibiliza a implementação AUTOSAR completa do protocolo LIN e compreende o gerenciador de estados LinSM, a interface LinIf (incluindo o protocolo de transporte LinTp), o driver do transceptor LinTrcv e o driver MCAL Lin (SWS COMManager p. 19). Ele conecta sub-redes, sensores e atuadores à matriz de comunicação AUTOSAR e diferencia estritamente entre nós master com execução autônoma de schedules e nós slave de resposta puramente reativa ([SWS_LinIf_00197], [SWS_Lin_00272]).

Diagrama de arquitetura: arquitetura em camadas e relações de interface do cluster LIN entre serviços de comunicação, camada de abstração e MCAL. Fontes: SWS COMManager p. 19, AUTOSAR SWS LINInterface p. 133.

A transmissão de dados ocorre em ECUs master através do acionamento periódico do driver via Lin_SendFrame e subsequente consulta de status via Lin_GetStatus ([SWS_Lin_00168]). No slave, por outro lado, a detecção de um cabeçalho no driver resulta no callback síncrono LinIf_HeaderIndication ([SWS_LinIf_91004]). A interface decide com base no PID se deve receber, responder ou ignorar e confirma a conclusão através de LinIf_RxIndication ou LinIf_TxConfirmation ([SWS_LinIf_91005], [SWS_LinIf_91006]). O LinTp integrado processa mensagens de diagnóstico por meio de alternâncias automatizadas da tabela de schedule ([SWS_LinIf_00641]).

No ciclo de operação, LinSM coordena as transições de estado entre LINSM_NO_COM e LINSM_FULL_COM ([SWS_LinSM_00026], [SWS_LinSM_00032]). O despertar ocorre por pulso no barramento via Lin_Wakeup ([SWS_Lin_00169]). A transição para o modo sleep ocorre no master através do envio ativo de um quadro sleep, e no slave após a recepção do comando sleep ou em caso de inatividade do barramento (idle) via LinIf_GotoSleep, Lin_GoToSleepInternal e controle de sleep do transceptor ([SWS_LinSM_00231], [SWS_LinIf_00757]).

Diagrama de sequência: interação dos módulos BSW na entrada de um slave LIN no estado sleep após o sinal de sleep do barramento. Fontes: [SWS_LinSM_91000], [SWS_LinSM_00231], [SWS_LinIf_00757], AUTOSAR SWS LINStateManager p. 48.

Erros de comunicação são detectados nos slaves via LinIf_LinErrorIndication e reportados autonomamente ao master no sinal response_error ([SWS_LinIf_91007], [SWS_LinIf_00763]). Áreas de sincronização entre canais e separações estritas entre tarefas cíclicas (LinIf_MainFunction) e ISRs do driver asseguram a estabilidade do sistema ([SWS_LinIf_00384]).

mais ›

Arquitetura do sistema & papel do cluster de módulos

O cluster de módulos LIN Communication disponibiliza, na pilha de Basic Software do AUTOSAR Classic, a comunicação padronizada via Local Interconnect Network (LIN) em conformidade com a ISO 17987. Ele atua primariamente como um subsistema de barramento de baixo custo para a conexão de sensores e atuadores na rede do veículo (AUTOSAR FO Features p. 58). O cluster estende-se por várias camadas da arquitetura AUTOSAR: o LIN State Manager (LinSM) opera no nível dos Communication Services, a LIN Interface (LinIf), incluindo o protocolo de transporte integrado (LinTp), forma a Communication Abstraction, o LIN Transceiver Driver (LinTrcv) é parte da ECU Abstraction e o LIN Driver (Lin) reside como módulo próximo ao hardware no Microcontroller Abstraction Layer (MCAL) (SWS COMManager p. 19).

Arquiteturalmente, o cluster diferencia estritamente entre nós master e slave. Um master LIN controla de forma autônoma o tráfego do barramento por meio de tabelas de schedule e gera todos os cabeçalhos, enquanto os slaves LIN respondem de maneira puramente reativa aos cabeçalhos recebidos ou avaliam sinais ([SWS_LinIf_00197], [SWS_Lin_00272]). Para tarefas de diagnóstico e transporte segundo a ISO 14229, a LIN Interface encapsula a funcionalidade de TP, que processa mensagens de diagnóstico segmentadas (Master Request Frame MRF e Slave Response Frame SRF) através do PduR e do DCM ([SWS_LinIf_00351], [SWS_LinIf_00629]). Externamente, o cluster interage intensamente com o Communication Manager (ComM), o Basic Software Mode Manager (BswM), o PDU Router (PduR) e o ECU State Manager (EcuM) (SWS COMManager p. 19).

Diagrama de arquitetura: arquitetura em camadas e relações de interface do cluster LIN entre serviços de comunicação, camada de abstração e MCAL. Fontes: SWS COMManager p. 19, AUTOSAR SWS LINInterface p. 133.

Interação e caminhos de interação entre os módulos

Os caminhos de interação no cluster diferem fundamentalmente dependendo do papel do nó. No master LIN, a LIN Interface inicia a execução da tabela de schedule ativa por meio de sua tarefa periódica. Para quadros de transmissão pendentes, LinIf busca os dados úteis através de mecanismos de trigger transmit da camada superior e repassa a estrutura Lin_PduType para o driver LIN via Lin_SendFrame ([SWS_Lin_00232], SWS LINInterface p. 37). O driver transmite o cabeçalho e os dados de forma não bloqueante ([SWS_Lin_00027]). Após o término do tempo máximo de execução do quadro, LinIf determina o resultado da transmissão através de Lin_GetStatus ([SWS_Lin_00168], SWS LINInterface p. 35). Em slots de recepção, LinIf busca os dados armazenados pelo driver no buffer e os encaminha para as camadas superiores ([SWS_Lin_00233]).

Em um slave LIN, o caminho de dados ocorre orientado a eventos: se o driver MCAL Lin detectar no hardware um cabeçalho válido de break, synch e PID, ele chama de forma síncrona o callback LinIf_HeaderIndication ([SWS_Lin_00280], [SWS_LinIf_91004]). A interface verifica o identificador protegido (PID) com base na tabela interna de PIDs ([SWS_LinIf_00816], [SWS_LinIf_00823]). Se for um quadro de transmissão, LinIf busca os dados úteis, configura o tipo de resposta para LIN_FRAMERESPONSE_TX e disponibiliza os dados ao driver no buffer ([SWS_Lin_00230]). Se o quadro estiver configurado como recepção, o driver relata o sucesso via LinIf_RxIndication após a recepção completa dos bytes ([SWS_LinIf_91005]), momento em que LinIf encaminha os dados para o PDU Router. Confirmações de respostas enviadas pelo slave ocorrem via LinIf_TxConfirmation ([SWS_LinIf_91006]).

Além disso, o controle do transceptor é encapsulado de forma transparente por meio da interface LIN: solicitações de modo como LinIf_SetTrcvMode são encaminhadas síncronamente pela interface para LinTrcv_SetOpMode ([SWS_LinIf_00544], [SWS_LinTrcv_00002]). Em transações de protocolo de transporte, LinTp controla, por meio de BswM_LinTp_RequestMode, a alternância direcionada da tabela de schedule do master entre modo de aplicação (LINTP_APPLICATIVE_SCHEDULE), solicitação de diagnóstico (LINTP_DIAG_REQUEST) e resposta de diagnóstico (LINTP_DIAG_RESPONSE) ([SWS_LinIf_00641], [SWS_LinIf_00642], [SWS_LinIf_00643]).

Diagrama de sequência: fluxo dinâmico de controle e de dados na indicação de cabeçalho, acionamento de transmissão e confirmação de recepção em um slave LIN. Fontes: [SWS_Lin_00280], [SWS_LinIf_91004], [SWS_LinIf_91005], AUTOSAR SWS LINInterface p. 133.

Sincronização, reentrância e contextos de tarefas

A execução dentro do cluster de módulos é dividida entre contextos de tarefas cíclicas e níveis de interrupção próximos ao hardware. O núcleo do controle de fluxo cíclico na LIN Interface é a função programada LinIf_MainFunction_<LinIfChannel.ShortName>, que é obrigatoriamente instanciada de forma separada para cada canal LIN configurado ([SWS_LinIf_00384], [SWS_LinIf_00725]). Ela assume o avanço dos slots de schedule, as consultas de status ao driver e o tratamento de timeout do protocolo de transporte ([SWS_LinIf_00800], SWS LINInterface p. 119). Paralelamente a isso, LinSM_MainFunction gerencia os temporizadores de contagem regressiva e de confirmação para solicitações assíncronas de canal e de wakeup ([SWS_LinSM_00162], [SWS_LinSM_00159]).

Em contraste com o nível de tarefas, as rotinas de driver do módulo MCAL Lin são executadas no contexto de interrupção (ISR) na presença de um controlador controlado por interrupção ou de uma interface UART (AUTOSAR CP SWS LINDriver p. 53). Os callbacks LinIf_HeaderIndication, LinIf_RxIndication e LinIf_TxConfirmation são disparados sincronamente diretamente a partir desse contexto de ISR ([SWS_Lin_00280], [SWS_LinIf_91005], [SWS_LinIf_91006]). Isso exige uma proteção rigorosa de seções críticas (Exclusive Areas) na LIN Interface: chamadas de controle como LinIf_Transmit, LinIf_GotoSleep, LinIf_ScheduleRequest ou LinIf_Wakeup só podem modificar estruturas internas de canal de forma protegida contra acessos paralelos a partir da LinIf_MainFunction ou de callbacks de ISR (SWS LINInterface p. 119).

Em relação à reentrância, as funções de API dos módulos LinIf e LinSM são predominantemente reentrantes para canais ou redes diferentes, porém concebidas como não reentrantes para o mesmo canal ([SWS_LinSM_00126], [SWS_LinIf_00201], [SWS_LinIf_00204]). O mesmo se aplica aos serviços de driver em Lin (por exemplo, Lin_Wakeup, Lin_GoToSleepInternal), que precisam ser rigorosamente sincronizados por canal físico ([SWS_Lin_00167], [SWS_Lin_00169]). No caso de hardware UART simples sem FIFO de múltiplos bytes, o driver LIN armazena bytes temporariamente em buffer por software ([SWS_Lin_00026]), o que, interpretação: sob alta carga de barramento, deve levar a um aumento no volume de interrupções de CPU em nós slave. Pergunta Q-0d07d89d1ade6a01 (aberta)

Ciclos de vida típicos e modos de operação

Durante a inicialização do sistema, o BswM inicializa os módulos BSW em uma cadeia pré-definida: primeiro são inicializados os drivers básicos Lin_Init e LinTrcv_Init, seguidos por LinIf_Init, LinTp_Init e, por fim, LinSM_Init (ModemanagementGuide p. 54). LinIf_Init define por padrão o schedule de todos os canais master como NULL_SCHEDULE ([SWS_LinIf_00233]) e, nos slaves, carrega as tabelas de NAD e PID pré-configuradas ([SWS_LinIf_00767], [SWS_LinIf_00768]). LinSM inicia no estado LINSM_NO_COM, sem emitir callbacks para ComM ou BswM durante a inicialização ([SWS_LinSM_00026], [SWS_LinSM_00166]).

Se o ComM solicitar a liberação de comunicação via LinSM_RequestComMode(COMM_FULL_COMMUNICATION), LinSM aciona diretamente LinIf_Wakeup e inicia um temporizador de monitoramento ([SWS_LinSM_00047], [SWS_LinSM_00100]). LinIf transmite o pulso físico de wakeup no barramento via Lin_Wakeup ([SWS_LinIf_00205], [SWS_Lin_00043]). Se LinIf relatar o sucesso do processo de despertar via LinSM_WakeupConfirmation(success=TRUE), o estado muda para LINSM_FULL_COM ([SWS_LinSM_00049], [SWS_LinSM_00132]). Isso é sinalizado para ComM via ComM_BusSM_ModeIndication e para BswM via BswM_LinSM_CurrentState ([SWS_LinSM_00033], [SWS_LinSM_00192]). Nos slaves, o barramento só é considerado despertado com sucesso quando o master envia o primeiro cabeçalho LIN e este é recebido ([SWS_LinIf_00761], SWS LINStateManager p. 28).

A descida para o modo sleep (Go-to-Sleep) difere substancialmente: em um master, a solicitação COMM_NO_COMMUNICATION resulta na chamada de LinIf_GotoSleep ([SWS_LinSM_00036], [SWS_LinSM_10208]). LinIf instrui o driver, via Lin_GoToSleep, a enviar um quadro padronizado de Go-to-Sleep no barramento ([SWS_Lin_00166], [SWS_Lin_00089]). Em um slave, por outro lado, a interface recebe o comando de Go-to-Sleep ou detecta um timeout de inatividade do barramento e informa LinSM via LinSM_GotoSleepIndication ([SWS_LinSM_91000]). LinSM chama então de forma síncrona LinIf_GotoSleep ([SWS_LinSM_00231]). A interface comuta o driver localmente para o estado LIN_CH_SLEEP via Lin_GoToSleepInternal ([SWS_LinIf_00757], [SWS_Lin_00095]) e coloca o transceptor em estado de sleep via LinIf_SetTrcvMode(LINTRCV_TRCV_MODE_SLEEP) ([SWS_LinIf_00544], AUTOSAR CP SWS LINInterface p. 137). Após a confirmação LinSM_GotoSleepConfirmation, LinSM muda finalmente para LINSM_NO_COM ([SWS_LinSM_00046], [SWS_LinSM_00233]).

Diagrama de sequência: interação dos módulos BSW na entrada de um slave LIN no estado sleep após o sinal de sleep do barramento. Fontes: [SWS_LinSM_91000], [SWS_LinSM_00231], [SWS_LinIf_00757], AUTOSAR SWS LINStateManager p. 48.

Tratamento de erros, rastreamento pelo DET e degradação

O cluster possui um conceito de diagnóstico e detecção de erros em múltiplos níveis. Erros de desenvolvimento são registrados através do Default Error Tracer (Det): parâmetros inválidos de canal ou rede são reportados por LIN_E_INVALID_CHANNEL ([SWS_Lin_00259]), LINIF_E_NONEXISTENT_CHANNEL ([SWS_LinIf_00539]) ou LINSM_E_NONEXISTENT_NETWORK ([SWS_LinSM_00127]). Chamadas a módulos não inicializados resultam em LIN_E_UNINIT, LINIF_E_UNINIT ou LINSM_E_UNINIT ([SWS_Lin_00258], [SWS_LinSM_00128]). Erros de transceptor, como números de rede inválidos, reportam LINTRCV_E_INVALID_LIN_NETWORK ao DET ([SWS_LinTrcv_00145]).

Falhas de comunicação que ocorrem durante a operação são classificadas como erros de tempo de execução: a interface define LINIF_E_RESPONSE no caso de quadros defeituosos e LINIF_E_NC_NO_RESPONSE na ausência de respostas a solicitações de configuração de nós ([SWS_LinIf_00729]). Erros físicos de barramento e protocolo (erros de enquadramento, erros de checksum, erros de monitoramento de bit) são reportados pelo driver MCAL no slave através de LinIf_LinErrorIndication com o status Lin_SlaveErrorType ([SWS_LinIf_91007], [SWS_Lin_91140]). Em nós master, Lin_GetStatus fornece códigos de erro detalhados como LIN_TX_HEADER_ERROR, LIN_TX_ERROR ou LIN_RX_ERROR para a interface ([SWS_Lin_00168], [SWS_Lin_00233]).

Um mecanismo central de erro para slaves LIN é o sinal padronizado response_error. A interface LIN gerencia esse sinal de 1 bit de forma autônoma: caso ocorra um erro de transmissão, LinIf define o bit, o qual é transmitido ao master no próximo quadro incondicional de transmissão ([SWS_LinIf_00763], SWS LINInterface p. 58). Após a transmissão bem-sucedida do quadro, LinIf limpa o flag automaticamente ([SWS_LinIf_00747]). No canal de diagnóstico, LinTp monitora janelas de tempo de protocolo rigorosas: caso N-PDUs não cheguem, os temporizadores $N_{As}$ e $N_{Cr}$ abortam a transação de forma definida e reportam E_NOT_OK ao PDU Router ([SWS_LinIf_00799], [SWS_LinIf_00804], [SWS_LinIf_00806]). Se faltar capacidade de buffer no PDU Router, a interface interrompe a recepção e comuta a tabela de schedule do master de volta para a operação de aplicação ([SWS_LinIf_00676], [SWS_LinIf_00792]).