LIN State Manager (LinSM)

O LIN State Manager converte as solicitações de comunicação do ComM para cada rede LIN em chamadas ao LIN Interface. Ele reporta os estados resultantes LINSM_FULL_COM e LINSM_NO_COM ao ComM e ao BswM [SWS_LinSM_00126]. Ele inicia diretamente o despertar, a suspensão e, apenas no master, a mudança da tabela de schedule, monitorando as confirmações com temporizadores em LinSM_MainFunction. No slave, o master determina a suspensão: apenas LinSM_GotoSleepIndication aciona LinIf_GotoSleep [SWS_LinSM_00231]. Se uma transição falhar, o LinSM reporta novamente o estado anterior para que as camadas superiores permaneçam consistentes.

mais ›

O LIN State Manager é o bus state manager para o LIN. Por meio dele, o ComM solicita a capacidade de comunicação de uma rede (SWS ComM p. 19). Ele recebe pedidos de modo via LinSM_RequestComMode [SWS_LinSM_00126]. Ele controla o LinIf e reporta estados ao ComM e ao BswM [SWS_LinSM_00229]. Qual driver LIN atende a uma rede permanece oculto atrás do LinIf (SWS LinSM p. 28).

Diagrama de contexto: ComM e BswM controlam o LinSM, o LinSM controla o LinIf e o LinIf retorna respostas por meio de callbacks. Fontes: [SWS_LinSM_00229], [SWS_LinSM_00138], SWS LinSM p. 28

Após LinSM_Init, cada rede está em LINSM_NO_COM [SWS_LinSM_00155]. ComM e BswM não são notificados nesse processo (SWS LinSM p. 23). A comunicação só é permitida em LINSM_FULL_COM. Ao entrar, ComM e BswM recebem uma notificação, e o subestado LINSM_RUN_COMMUNICATION é introduzido [SWS_LinSM_00301]. Para o BswM, apenas LINSM_FULL_COM e LINSM_NO_COM são visíveis [SWS_LinSM_00220].

Diagrama de estados: Para cada rede, o LinSM alterna entre LINSM_NO_COM e LINSM_FULL_COM por meio de confirmação de despertar e suspensão. Fontes: [SWS_LinSM_00155], [SWS_LinSM_00301], SWS LinSM p. 20

O LinSM inicia o despertar e a suspensão diretamente na chamada. Ele monitora as confirmações do LinIf com temporizadores em LinSM_MainFunction [SWS_LinSM_00156] (SWS LinSM p. 28). No master, uma solicitação para COMM_NO_COMMUNICATION leva imediatamente a LinIf_GotoSleep [SWS_LinSM_00036]. No slave, ela é apenas armazenada [SWS_LinSM_00230]; somente LinSM_GotoSleepIndication aciona a suspensão [SWS_LinSM_00231]. Um temporizador silence-after-wakeup atrasa novas tentativas de despertar [SWS_LinSM_00237].

A mudança de schedule existe apenas no master [SWS_LinSM_00241]. O LinSM encaminha LinSM_ScheduleRequest diretamente para o LinIf e reporta o resultado via BswM_LinSM_CurrentSchedule (SWS LinSM p. 26). Para erros aplica-se o seguinte:

• O LinSM reporta erros de desenvolvimento ao DET, com os códigos de [SWS_LinSM_00053].
• A ausência de callback do LinIf é considerada como LINSM_E_CONFIRMATION_TIMEOUT [SWS_LinSM_00224].
• Após uma transição malsucedida, o LinSM define novamente o estado anterior para que ComM e BswM fiquem informados de forma consistente [SWS_LinSM_00177].

mais ›

Papel entre ComM, BswM e LIN Interface

O LIN State Manager (LinSM) é o bus state manager para o LIN. Assim como nos outros bus state managers, o ComM solicita por meio dele a capacidade de comunicação de uma rede (SWS ComM p. 19). A interface de entrada central para isso é LinSM_RequestComMode [SWS_LinSM_00126]. O modo atual é fornecido por LinSM_GetCurrentComMode [SWS_LinSM_00122]. O LinSM opera exclusivamente em redes. Qual driver LIN atende a uma rede é ocultado pelo LinIf. Por isso, ECUs com múltiplos drivers LIN diferentes não afetam o LinSM (SWS LinSM p. 28).

As interfaces obrigatórias incluem LinIf_GotoSleep e LinIf_ScheduleRequest para baixo, bem como as notificações ComM_BusSM_ModeIndication, ComM_BusSM_BusSleepMode, BswM_LinSM_CurrentState e BswM_LinSM_CurrentSchedule para cima [SWS_LinSM_00229] (SWS LinSM p. 41). O LinSM chama LinIf_Wakeup durante o fluxo de despertar (SWS LinSM p. 27). Opcionalmente, ele utiliza Det_ReportError e LinIf_SetTrcvMode [SWS_LinSM_00138]. O LinIf responde por meio dos seguintes callbacks:

• LinSM_WakeupConfirmation [SWS_LinSM_00132]
• LinSM_GotoSleepConfirmation [SWS_LinSM_00135]
• LinSM_GotoSleepIndication [SWS_LinSM_91000]
• LinSM_ScheduleRequestConfirmation [SWS_LinSM_00129]

Os tipos importados, como ComM_ModeType, NetworkHandleType e LinIf_SchHandleType, são definidos por [SWS_LinSM_00219].

Diagrama de contexto: O LinSM intermedeia entre ComM e BswM acima e o LinIf abaixo; os drivers LIN permanecem ocultos atrás do LinIf. Fontes: [SWS_LinSM_00126], [SWS_LinSM_00229], [SWS_LinSM_00138], [SWS_LinSM_00156], SWS LinSM p. 28, Mode-Management-Guide p. 54

Modelo de estados por rede LIN, inicialização e parte cíclica

Na inicialização, antes de qualquer chamada de API, o estado LINSM_UNINIT em todo o módulo está ativo (SWS LinSM p. 22). LinSM_Init é síncrona e não reentrante [SWS_LinSM_00155]. A função recebe um ponteiro para a configuração post-build do tipo específico da implementação LinSM_ConfigType [SWS_LinSM_00221]. Depois disso, cada rede está no subestado LINSM_NO_COM do superestado LINSM_INIT. LinSM_Init não reporta esta primeira transição nem ao ComM nem ao BswM, porque o ComM ainda não precisa estar inicializado neste momento (SWS LinSM p. 23). No exemplo do guia de Mode Management, uma regra do BswM chama LinSM_Init(null) após Lin_Init e LinIf_Init (Mode-Management-Guide p. 54).

Em LINSM_NO_COM o barramento permanece silencioso (SWS LinSM p. 23). Apenas em LINSM_FULL_COM é permitido comunicar no barramento, e cada rede atinge esse estado independentemente das outras. Ao entrar, ocorre o seguinte (SWS LinSM p. 23):

• O ComM recebe uma notificação com COMM_FULL_COMMUNICATION, e o BswM uma notificação com LINSM_FULL_COM.
• Se LinSMTransceiverPassiveMode estiver configurado, o LinSM comuta o transceptor para ativo via LinIf_SetTrcvMode.
• O subestado LINSM_RUN_COMMUNICATION é introduzido [SWS_LinSM_00301].

O subestado temporário LINSM_GOTO_SLEEP faz a transição durante a espera pela confirmação de suspensão (SWS LinSM p. 20, SWS LinSM p. 21). Para o BswM, apenas dois valores de LinSM_ModeType são visíveis: LINSM_FULL_COM (0x01) e LINSM_NO_COM (0x02) [SWS_LinSM_00220].

O monitoramento temporal é executado em LinSM_MainFunction. Esta função periódica gerencia os temporizadores dos timeouts de solicitação [SWS_LinSM_00156]. Nela também operam os temporizadores de confirmação de despertar, com um temporizador dedicado para cada rede (SWS LinSM p. 28). Por outro lado, o LinSM inicia as ações de barramento propriamente ditas diretamente na chamada e não espera pelo próximo ciclo da main function [SWS_LinSM_00036] [SWS_LinSM_00231].

Diagrama de estados: Para cada rede, o LinSM alterna entre LINSM_NO_COM e LINSM_FULL_COM através de confirmação de despertar e suspensão; LINSM_GOTO_SLEEP é apenas um estado de espera. Fontes: [SWS_LinSM_00155], [SWS_LinSM_00301], SWS LinSM p. 20, SWS LinSM p. 21, SWS LinSM p. 24

Despertar: de LINSM_NO_COM para LINSM_FULL_COM

Uma rede LIN é acordada quando o ComM solicita comunicação completa via LinSM_RequestComMode. Se outro nó acordar o barramento, isso não é tratado pelo LinSM, mas sim pelo EcuM; esse caso também resulta em uma solicitação por parte do ComM (SWS LinSM p. 27). O LinSM chama então diretamente LinIf_Wakeup e reinicializa o contador para o número máximo de repetições. Se o LinIf já estiver acordado, ele ignora a chamada. Antes da chamada, o LinSM inicia o temporizador de confirmação de despertar para o canal com LinSMConfirmationTimeout. Esse valor deve ser 0 ou um múltiplo inteiro do período da main function (SWS LinSM p. 28).

Se LinSM_WakeupConfirmation reportar success = TRUE, a rede transita para LINSM_FULL_COM [SWS_LinSM_00132]. Em todos os outros casos, o LinSM define novamente o estado anterior à requisição, para que ComM e BswM recebam mesmo assim uma indicação de modo (SWS LinSM p. 27). No Slave, o LinIf só confirma quando recebe o primeiro cabeçalho LIN do Master. Se o Master não iniciar o scheduling, a confirmação não ocorre e o timeout do LinSM é acionado (SWS LinIf p. 52).

Diagrama de sequência: o LinSM acorda a rede imediatamente na chamada; no entanto, a mudança de estado só se segue com a confirmação assíncrona do LinIf. Fontes: [SWS_LinSM_00126], [SWS_LinSM_00132], [SWS_LinSM_00224], SWS LinSM p. 42, SWS LinSM p. 27

Um segundo limite temporal é o temporizador Silence-after-Wakeup com LinSMSilenceAfterWakeupTimeout [SWS_LinSM_00235]. Enquanto estiver em execução, o LinSM atrasa uma nova chamada de LinIf_Wakeup, mesmo que ComM solicite comunicação total [SWS_LinSM_00237]. Após a sua expiração, o LinSM reinicia o processo de wakeup, desde que ComM continue a solicitar COMM_FULL_COMMUNICATION [SWS_LinSM_00236]. A condição que inicia o temporizador consta de um requisito que não está disponível aqui. Portanto, não é descrita.

Diagrama de atividades: uma requisição de comunicação total termina, dependendo da situação do temporizador e do feedback, em LINSM_FULL_COM, no estado anterior ou em um timeout de confirmação. Fontes: [SWS_LinSM_00237], [SWS_LinSM_00236], [SWS_LinSM_00224], SWS LinSM p. 27, SWS LinSM p. 28

Ir para o modo sleep: o Master solicita, o Slave segue o barramento

O fluxo de Goto-Sleep difere entre Master e Slave. Em ambos os casos, o LinSM reporta a entrada no modo No-Communication ao BswM e ao ComM, mesmo que tenha ocorrido um problema (SWS LinSM p. 24).

Para o Master aplica-se:

• Se ComM solicitar COMM_NO_COMMUNICATION em LINSM_FULL_COM, o LinSM chama LinIf_GotoSleep, que envia o comando Goto-Sleep [SWS_LinSM_10208].
• A chamada ocorre diretamente [SWS_LinSM_00036]. Em todos os outros casos, ela é omitida [SWS_LinSM_10209].
• A chamada só é permitida no subestado LINSM_RUN_COMMUNICATION (SWS LinSM p. 24).
• Se LinIf_GotoSleep retornar E_NOT_OK, LinSM_RequestComMode também retorna E_NOT_OK. O estado anterior é definido novamente para que ComM e BswM recebam uma indicação [SWS_LinSM_00177].

Em seguida, o LinIf chama LinSM_GotoSleepConfirmation [SWS_LinSM_00135]. Se o LinSM estiver então em LINSM_FULL_COM/LINSM_GOTO_SLEEP, ele transita para LINSM_NO_COM, independentemente do parâmetro success. Em qualquer outro estado, ele ignora a confirmação (SWS LinSM p. 24). O diagrama da especificação inicia um temporizador antes de LinIf_GotoSleep e para-o após a confirmação (SWS LinSM p. 47).

Diagrama de sequência: no Master, o ComM dispara o processo de sleep; LINSM_NO_COM só é atingido com a confirmação de sleep, e um E_NOT_OK de LinIf_GotoSleep leva à nova notificação do estado anterior. Fontes: [SWS_LinSM_00036], [SWS_LinSM_00177], [SWS_LinSM_00135], SWS LinSM p. 47, SWS LinSM p. 24

No Slave, o Master decide sobre a transição para sleep. Se ComM solicitar COMM_NO_COMMUNICATION em LINSM_FULL_COM, o LinSM apenas armazena a solicitação e retorna E_OK [SWS_LinSM_00230]. O LinIf reporta LinSM_GotoSleepIndication quando um comando Goto-Sleep foi recebido ou quando ocorreu um timeout de bus idle [SWS_LinSM_91000]. Só então o LinSM chama diretamente LinIf_GotoSleep [SWS_LinSM_00231]. Como o processo prossegue depende da solicitação armazenada:

• Se COMM_NO_COMMUNICATION estiver solicitado e LinIf_GotoSleep retornar E_OK, o ComM toma conhecimento do evento de bus sleep através de ComM_BusSM_BusSleepMode [SWS_LinSM_00233].
• Se comunicação total estiver solicitada, o LinSM reinicia o processo de wakeup após a confirmação de sleep [SWS_LinSM_00234].

No LinIf, o fluxo do Slave coloca o controlador e, se suportado, o transceptor em modo sleep (SWS LinIf p. 137).

Diagrama de sequência: no Slave, a solicitação de sleep do ComM é apenas armazenada; o processo de sleep é disparado pela indicação do LinIf. Fontes: [SWS_LinSM_00230], [SWS_LinSM_00231], [SWS_LinSM_00233], [SWS_LinSM_00234], SWS LinSM p. 48, SWS LinSM p. 24

Trocar tabelas de schedule (apenas Master)

LinSM_ScheduleRequest [SWS_LinSM_00113] só existe se pelo menos um canal estiver configurado como Master [SWS_LinSM_00241]. O mesmo se aplica ao callback LinSM_ScheduleRequestConfirmation [SWS_LinSM_00242]. A função assíncrona encaminha a requisição diretamente para LinIf_ScheduleRequest, sem passar pela Main Function. Ela devolve o valor de retorno desta ao chamador (SWS LinSM p. 26). O chamador é o BswM. Ele utiliza LinSMScheduleIndex como referência simbólica cujo valor deve corresponder ao valor no LinIf (SWS LinSM p. 52). As trocas de schedule de diagnóstico do protocolo de transporte LIN também ocorrem via BswM e LinSM_ScheduleRequest (SWS LinIf p. 142).

O LinSM reporta o resultado através de BswM_LinSM_CurrentSchedule (SWS BswM p. 80). Qual schedule é reportado depende do decurso (SWS LinSM p. 26):

• Se LinSM_ScheduleRequestConfirmation [SWS_LinSM_00129] confirmar antes da expiração do temporizador, o LinSM reporta o novo schedule.
• Se o temporizador tiver expirado, ele reporta o schedule inalterado.
• Se LinIf_ScheduleRequest retornar E_NOT_OK, ele reporta o schedule anterior na próxima chamada da Main Function.
• Ele também reporta uma troca sem solicitação prévia, como a mudança para o schedule NULL realizada pelo LinIf durante a transição para sleep.

Diagrama de sequência: a troca de schedule é repassada diretamente e monitorada por temporizador; em qualquer desfecho, o BswM toma conhecimento do schedule efetivamente válido. Fontes: [SWS_LinSM_00113], [SWS_LinSM_00129], [SWS_LinSM_00156], SWS LinSM p. 26, SWS LinSM p. 48

Tipo de nó, configuração e diferenças em relação a releases posteriores

O parâmetro LinSMNodeType define se o comportamento de Master ou Slave se aplica a um canal. Disso depende se LinSM_ScheduleRequest, LinSM_ScheduleRequestConfirmation e LinSM_GotoSleepIndication estão disponíveis [SWS_LinSM_00241] [SWS_LinSM_00242] [SWS_LinSM_00243]. Os parâmetros temporais mais importantes são LinSMConfirmationTimeout (SWS LinSM p. 28) e LinSMSilenceAfterWakeupTimeout [SWS_LinSM_00235]. Os contêineres LinSMSchedule referenciam schedules da configuração do LinIf (SWS LinSM p. 52). As verificações de DET dependem de LinSMDevErrorDetect [SWS_LinSM_00239].

Muitas passagens do documento provêm de releases posteriores. Para o R20-11, os Requirements são determinantes e, em alguns pontos, divergem:

• O segundo parâmetro de LinSM_ScheduleRequest chama-se schedule no R20-11 e é descrito como “Pointer to the new Schedule table”, embora seu tipo seja LinIf_SchHandleType [SWS_LinSM_00113]. Com o R22-11, ele foi renomeado (SWS LinSM p. 1, Release Overview p. 50); no R24-11, chama-se ScheduleTableIdx (SWS LinSM p. 34).
• No R20-11, LinSM_GetCurrentComMode tem o Service-ID 0x11 [SWS_LinSM_00122] e LinSM_RequestComMode tem o Service-ID 0x12 [SWS_LinSM_00126]. Versões posteriores indicam 0x41 e 0x40 e permitem reentrância apenas para redes diferentes (SWS LinSM p. 35, SWS LinSM p. 36).
• Os callbacks do ComM chamam-se ComM_BusSM_… [SWS_LinSM_00233] no R20-11 e ComM_<Bus>SM_… no R25-11 (SWS LinSM p. 41).

Comportamento em caso de erro

[SWS_LinSM_00053] define os erros de desenvolvimento:

• LINSM_E_UNINIT (0x00)
• LINSM_E_NONEXISTENT_NETWORK (0x20)
• LINSM_E_PARAMETER (0x30)
• LINSM_E_PARAM_POINTER (0x40)
• LINSM_E_INIT_FAILED (0x50)

Com LinSMDevErrorDetect ativo, os callbacks verificam a rede e a inicialização, como por exemplo LinSM_GotoSleepIndication [SWS_LinSM_00239] [SWS_LinSM_00240]. Os callbacks não possuem valor de retorno, portanto a ação limita-se à notificação DET (SWS LinSM p. 40, SWS LinSM p. 39). APIs com Std_ReturnType retornam adicionalmente E_NOT_OK, por exemplo em caso de rede, modo ou schedule inválidos ou no estado LINSM_UNINIT (SWS LinSM p. 36, SWS LinSM p. 34). Interpretação: estas verificações provêm de versões a partir do R24-11 e devem ser aplicáveis com teor idêntico para o R20-11. Chama a atenção o fato de a versão posterior exigir E_NOT_OK em caso de ponteiro NULL também para a API void LinSM_GetVersionInfo [SWS_LinSM_00117] (SWS LinSM p. 34). Pergunta Q-6b2d75dd286bdcb4 (aberta)

Como erro de runtime, está previsto LINSM_E_CONFIRMATION_TIMEOUT (0x00) para a ausência de callbacks do LinIf [SWS_LinSM_00224]. Presumivelmente, ele é reportado através de Det_ReportRuntimeError, que versões posteriores listam como interface obrigatória (SWS LinSM p. 41). Pergunta Q-06b13a07d0d60152 (aberta) Funcionalmente, o LinSM garante que ComM e BswM vejam sempre um estado consistente:

• Após um wakeup com falha, ele define e reporta novamente o estado anterior (SWS LinSM p. 27).
• Em caso de E_NOT_OK de LinIf_GotoSleep, aplica-se o mesmo [SWS_LinSM_00177].
• Uma confirmação de sleep leva a LINSM_NO_COM mesmo com success = FALSE (SWS LinSM p. 24).
• Em caso de troca de schedule malsucedida, o BswM recebe o schedule anterior ou inalterado (SWS LinSM p. 26).

Evidências mais detalhadas

• Desejo de modo do ComM e transição para sleep no Master: [SWS_LinSM_00126], [SWS_LinSM_00036], [SWS_LinSM_10208], [SWS_LinSM_10209], [SWS_LinSM_00177].
• Transição para sleep no Slave: [SWS_LinSM_91000], [SWS_LinSM_00230], [SWS_LinSM_00231], [SWS_LinSM_00233], [SWS_LinSM_00234]; além disso, o fluxo em SWS LinSM p. 24.
• Wakeup e monitoramento temporal: [SWS_LinSM_00132], [SWS_LinSM_00235], [SWS_LinSM_00236], [SWS_LinSM_00237], SWS LinSM p. 28.
• Troca de schedule: [SWS_LinSM_00113], [SWS_LinSM_00129], [SWS_LinSM_00241], [SWS_LinSM_00242].
• Inicialização, estados e tipos: [SWS_LinSM_00155], [SWS_LinSM_00156], [SWS_LinSM_00220], [SWS_LinSM_00221], [SWS_LinSM_00301]; notificação ao BswM em SWS BswM p. 72.
• Códigos de erro e interfaces: [SWS_LinSM_00053], [SWS_LinSM_00224], [SWS_LinSM_00229], [SWS_LinSM_00138], [SWS_LinSM_00219].
• Rastreabilidade para requisitos SRS e lista de requisitos não aplicáveis: SWS LinSM p. 18, SWS LinSM p. 55.