LIN State Manager (LinSM)

El LIN State Manager traduce las peticiones de comunicación de ComM para cada red LIN en llamadas a LIN Interface. Notifica los estados resultantes LINSM_FULL_COM y LINSM_NO_COM a ComM y BswM [SWS_LinSM_00126]. Inicia directamente el despertar, el paso a reposo y, únicamente en el master, el cambio de la tabla de schedule, y supervisa las confirmaciones con temporizadores en LinSM_MainFunction. En el slave, el master determina el paso a reposo: solo LinSM_GotoSleepIndication desencadena LinIf_GotoSleep [SWS_LinSM_00231]. Si una transición falla, LinSM vuelve a notificar el estado anterior para que las capas superiores mantengan la consistencia.

más ›

El LIN State Manager es el bus state manager para LIN. A través de él, ComM solicita la capacidad de comunicación de una red (SWS ComM p. 19). Acepta las peticiones de modo mediante LinSM_RequestComMode [SWS_LinSM_00126]. Controla LinIf y notifica los estados a ComM y BswM [SWS_LinSM_00229]. Qué controlador LIN atiende a una red permanece oculto tras LinIf (SWS LinSM p. 28).

Diagrama de contexto: ComM y BswM controlan LinSM, LinSM controla LinIf, y LinIf responde mediante callbacks. Fuentes: [SWS_LinSM_00229], [SWS_LinSM_00138], SWS LinSM p. 28

Tras LinSM_Init, cada red se encuentra en LINSM_NO_COM [SWS_LinSM_00155]. En este proceso no se notifica a ComM ni a BswM (SWS LinSM p. 23). Solo se permite la comunicación en LINSM_FULL_COM. Al entrar en él, ComM y BswM reciben una notificación y se entra en el subestado LINSM_RUN_COMMUNICATION [SWS_LinSM_00301]. Para BswM solo son visibles LINSM_FULL_COM y LINSM_NO_COM [SWS_LinSM_00220].

Diagrama de estados: para cada red, LinSM conmuta entre LINSM_NO_COM y LINSM_FULL_COM mediante la confirmación de despertar y de paso a reposo. Fuentes: [SWS_LinSM_00155], [SWS_LinSM_00301], SWS LinSM p. 20

LinSM inicia el despertar y el paso a reposo directamente en la llamada. Supervisa las confirmaciones de LinIf con temporizadores en LinSM_MainFunction [SWS_LinSM_00156] (SWS LinSM p. 28). En el master, una solicitud de COMM_NO_COMMUNICATION conduce de inmediato a LinIf_GotoSleep [SWS_LinSM_00036]. En el slave solo se almacena [SWS_LinSM_00230]; únicamente LinSM_GotoSleepIndication activa el paso a reposo [SWS_LinSM_00231]. Un temporizador silence-after-wakeup retrasa nuevos intentos de despertar [SWS_LinSM_00237].

Los cambios de schedule solo existen en el master [SWS_LinSM_00241]. LinSM reenvía LinSM_ScheduleRequest directamente a LinIf y notifica el resultado mediante BswM_LinSM_CurrentSchedule (SWS LinSM p. 26). Para los errores se aplica lo siguiente:

• LinSM notifica los errores de desarrollo al DET, con los códigos de [SWS_LinSM_00053].
• La ausencia de un callback de LinIf se considera LINSM_E_CONFIRMATION_TIMEOUT [SWS_LinSM_00224].
• Tras una transición fallida, LinSM vuelve a fijar el estado anterior para que ComM y BswM estén informados de manera consistente [SWS_LinSM_00177].

más ›

Rol entre ComM, BswM y LIN Interface

El LIN State Manager (LinSM) es el bus state manager para LIN. Al igual que ocurre con los demás administradores de estado de bus, ComM solicita a través de él la capacidad de comunicación de una red (SWS ComM p. 19). La interfaz central de entrada para ello es LinSM_RequestComMode [SWS_LinSM_00126]. El modo actual lo proporciona LinSM_GetCurrentComMode [SWS_LinSM_00122]. LinSM opera exclusivamente a nivel de redes. Qué controlador LIN atiende a una red queda oculto por LinIf. Por lo tanto, las centralitas con múltiples controladores LIN distintos no afectan a LinSM (SWS LinSM p. 28).

Entre las interfaces obligatorias se encuentran LinIf_GotoSleep y LinIf_ScheduleRequest hacia abajo, así como las notificaciones ComM_BusSM_ModeIndication, ComM_BusSM_BusSleepMode, BswM_LinSM_CurrentState y BswM_LinSM_CurrentSchedule hacia arriba [SWS_LinSM_00229] (SWS LinSM p. 41). LinSM llama a LinIf_Wakeup en la secuencia de despertar (SWS LinSM p. 27). Opcionalmente utiliza Det_ReportError y LinIf_SetTrcvMode [SWS_LinSM_00138]. LinIf responde mediante los siguientes callbacks:

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

[SWS_LinSM_00219] define los tipos importados tales como ComM_ModeType, NetworkHandleType y LinIf_SchHandleType.

Diagrama de contexto: LinSM actúa de intermediario entre ComM y BswM arriba y LinIf abajo; los controladores LIN permanecen ocultos tras LinIf. Fuentes: [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 red LIN, inicialización y parte cíclica

Durante el arranque, antes de cada llamada a la API, el estado de todo el módulo LINSM_UNINIT está activo (SWS LinSM p. 22). LinSM_Init es síncrona y no reentrante [SWS_LinSM_00155]. La función recibe un puntero a la configuración post-build del tipo específico de la implementación LinSM_ConfigType [SWS_LinSM_00221]. Después, cada red se encuentra en el subestado LINSM_NO_COM del superestado LINSM_INIT. LinSM_Init no notifica esta primera transición ni a ComM ni a BswM, ya que ComM aún no tiene por qué estar inicializado en ese momento (SWS LinSM p. 23). En el ejemplo de la guía de Mode Management, una regla de BswM llama a LinSM_Init(null) tras Lin_Init y LinIf_Init (Mode-Management-Guide p. 54).

En LINSM_NO_COM el bus permanece en silencio (SWS LinSM p. 23). Solo en LINSM_FULL_COM se permite comunicar en el bus, y cada red alcanza este estado de forma independiente de las demás. Al entrar se produce lo siguiente (SWS LinSM p. 23):

• ComM recibe un mensaje con COMM_FULL_COMMUNICATION, BswM un mensaje con LINSM_FULL_COM.
• Si LinSMTransceiverPassiveMode está configurado, LinSM activa el transceptor mediante LinIf_SetTrcvMode.
• Se accede al subestado LINSM_RUN_COMMUNICATION [SWS_LinSM_00301].

El subestado transitorio LINSM_GOTO_SLEEP cubre la espera de la confirmación de paso a reposo (SWS LinSM p. 20, SWS LinSM p. 21). Para BswM solo son visibles dos valores de LinSM_ModeType: LINSM_FULL_COM (0x01) y LINSM_NO_COM (0x02) [SWS_LinSM_00220].

La supervisión temporal se ejecuta en LinSM_MainFunction. Esta función periódica gestiona los temporizadores de los tiempos de espera de solicitud [SWS_LinSM_00156]. En ella también se ejecutan los temporizadores de confirmación de despertar, con un temporizador propio para cada red (SWS LinSM p. 28). En cambio, LinSM inicia las acciones de bus propiamente dichas directamente en la llamada y no espera al siguiente ciclo de la función principal [SWS_LinSM_00036] [SWS_LinSM_00231].

Diagrama de estados: para cada red, LinSM conmuta entre LINSM_NO_COM y LINSM_FULL_COM mediante la confirmación de despertar y de paso a reposo; LINSM_GOTO_SLEEP es solo un estado de espera. Fuentes: [SWS_LinSM_00155], [SWS_LinSM_00301], SWS LinSM p. 20, SWS LinSM p. 21, SWS LinSM p. 24

Despertar: de LINSM_NO_COM a LINSM_FULL_COM

Una red LIN se despierta cuando ComM solicita comunicación completa mediante LinSM_RequestComMode. Si otro nodo despierta el bus, no lo gestiona LinSM, sino EcuM; este caso también conduce a una solicitud por parte de ComM (SWS LinSM p. 27). LinSM llama entonces directamente a LinIf_Wakeup y restablece el contador para el número máximo de reintentos. Si LinIf ya está despierto, ignora la llamada. Antes de la llamada, LinSM inicia el temporizador de confirmación de despertar para el canal con LinSMConfirmationTimeout. Este valor debe ser 0 o un múltiplo entero del periodo de la función principal (SWS LinSM p. 28).

Si LinSM_WakeupConfirmation notifica success = TRUE, la red pasa a LINSM_FULL_COM [SWS_LinSM_00132]. En todos los demás casos, LinSM vuelve a fijar el estado anterior a la solicitud para que ComM y BswM reciban igualmente una indicación de modo (SWS LinSM p. 27). En el slave, LinIf solo confirma cuando recibe el primer encabezado LIN del master. Si el master no inicia la planificación (scheduling), la confirmación no se produce y actúa el timeout de LinSM (SWS LinIf p. 52).

Diagrama de secuencia: LinSM despierta la red inmediatamente en la llamada, pero el cambio de estado solo sigue con la confirmación asíncrona de LinIf. Fuentes: [SWS_LinSM_00126], [SWS_LinSM_00132], [SWS_LinSM_00224], SWS LinSM p. 42, SWS LinSM p. 27

Un segundo límite temporal es el temporizador silence-after-wakeup con LinSMSilenceAfterWakeupTimeout [SWS_LinSM_00235]. Mientras esté en marcha, LinSM retrasa una nueva llamada de LinIf_Wakeup, incluso si ComM solicita comunicación completa [SWS_LinSM_00237]. Tras su expiración, LinSM reinicia el proceso de despertar siempre que ComM continúe solicitando COMM_FULL_COMMUNICATION [SWS_LinSM_00236]. La condición que inicia el temporizador figura en un requisito que no está disponible aquí. Por tanto, no se describe.

Diagrama de actividades: una solicitud de comunicación completa finaliza, según el estado de los temporizadores y la retroalimentación, en LINSM_FULL_COM, en el estado anterior o en un timeout de confirmación. Fuentes: [SWS_LinSM_00237], [SWS_LinSM_00236], [SWS_LinSM_00224], SWS LinSM p. 27, SWS LinSM p. 28

Paso a reposo: el master solicita, el slave sigue al bus

La secuencia goto-sleep difiere entre master y slave. En ambos casos, LinSM notifica la entrada en el modo de no comunicación a BswM y ComM, incluso si se produjo un problema (SWS LinSM p. 24).

En el master se aplica lo siguiente:

• Si ComM solicita COMM_NO_COMMUNICATION en LINSM_FULL_COM, LinSM llama a LinIf_GotoSleep, que envía el comando goto-sleep [SWS_LinSM_10208].
• La llamada se realiza directamente [SWS_LinSM_00036]. En todos los demás casos se omite [SWS_LinSM_10209].
• La llamada solo está permitida en el subestado LINSM_RUN_COMMUNICATION (SWS LinSM p. 24).
• Si LinIf_GotoSleep devuelve E_NOT_OK, LinSM_RequestComMode también devuelve E_NOT_OK. Se vuelve a establecer el estado anterior para que ComM y BswM reciban una indicación [SWS_LinSM_00177].

A continuación, LinIf llama a LinSM_GotoSleepConfirmation [SWS_LinSM_00135]. Si LinSM se encuentra entonces en LINSM_FULL_COM/LINSM_GOTO_SLEEP, cambia a LINSM_NO_COM, independientemente del parámetro success. En cualquier otro estado ignora la confirmación (SWS LinSM p. 24). El esquema de la especificación inicia un temporizador antes de LinIf_GotoSleep y lo detiene tras la confirmación (SWS LinSM p. 47).

Diagrama de secuencias: En el master, ComM desencadena la transición a suspensión; LINSM_NO_COM solo se alcanza con la confirmación de suspensión, un E_NOT_OK de LinIf_GotoSleep da lugar a una nueva notificación del estado anterior. Fuentes: [SWS_LinSM_00036], [SWS_LinSM_00177], [SWS_LinSM_00135], SWS LinSM p. 47, SWS LinSM p. 24

En el slave, el master decide sobre la transición a suspensión. Si ComM solicita COMM_NO_COMMUNICATION en LINSM_FULL_COM, LinSM solo guarda la petición y devuelve E_OK [SWS_LinSM_00230]. LinIf notifica LinSM_GotoSleepIndication cuando se ha recibido un comando Goto-Sleep o se ha producido un timeout de bus inactivo [SWS_LinSM_91000]. Solo entonces LinSM llama directamente a LinIf_GotoSleep [SWS_LinSM_00231]. La forma de proceder depende de la petición guardada:

• Si se solicita COMM_NO_COMMUNICATION y LinIf_GotoSleep devuelve E_OK, ComM recibe el evento Bus-Sleep a través de ComM_BusSM_BusSleepMode [SWS_LinSM_00233].
• Si se solicita comunicación completa, LinSM reinicia el proceso de wakeup tras la confirmación de suspensión [SWS_LinSM_00234].

En LinIf, la secuencia del slave pone el controlador y, si es compatible, el transceptor en modo de suspensión (SWS LinIf p. 137).

Diagrama de secuencias: En el slave, la petición de suspensión de ComM solo se guarda; la transición a suspensión se desencadena mediante la indicación de LinIf. Fuentes: [SWS_LinSM_00230], [SWS_LinSM_00231], [SWS_LinSM_00233], [SWS_LinSM_00234], SWS LinSM p. 48, SWS LinSM p. 24

Cambiar tablas de schedule (solo master)

LinSM_ScheduleRequest [SWS_LinSM_00113] solo existe si al menos un canal está configurado como master [SWS_LinSM_00241]. Lo mismo se aplica a la callback LinSM_ScheduleRequestConfirmation [SWS_LinSM_00242]. La función asíncrona reenvía la solicitud directamente a LinIf_ScheduleRequest, sin pasar por la Main Function. Devuelve su valor de retorno a quien realiza la llamada (SWS LinSM p. 26). Quien realiza la llamada es BswM. Utiliza LinSMScheduleIndex como referencia simbólica, cuyo valor debe corresponder al valor en LinIf (SWS LinSM p. 52). Los cambios de schedule de diagnóstico del protocolo de transporte LIN también se gestionan a través de BswM y LinSM_ScheduleRequest (SWS LinIf p. 142).

LinSM notifica el resultado a través de BswM_LinSM_CurrentSchedule (SWS BswM p. 80). Qué schedule se notifica depende de la evolución (SWS LinSM p. 26):

• Si LinSM_ScheduleRequestConfirmation confirma [SWS_LinSM_00129] antes de que expire el temporizador, LinSM notifica el nuevo schedule.
• Si el temporizador ha expirado, notifica el schedule sin cambios.
• Si LinIf_ScheduleRequest devuelve E_NOT_OK, notifica el schedule anterior en la siguiente llamada a la Main Function.
• También notifica un cambio sin solicitud previa, como el cambio al schedule NULL que LinIf realiza durante la transición a suspensión.

Diagrama de secuencias: El cambio de schedule se reenvía directamente y se supervisa temporalmente; BswM obtiene en cada caso el schedule realmente válido. Fuentes: [SWS_LinSM_00113], [SWS_LinSM_00129], [SWS_LinSM_00156], SWS LinSM p. 26, SWS LinSM p. 48

Tipo de nodo, configuración y diferencias con releases posteriores

El parámetro LinSMNodeType determina si se aplica el comportamiento de master o slave para un canal. De ello depende si LinSM_ScheduleRequest, LinSM_ScheduleRequestConfirmation y LinSM_GotoSleepIndication están disponibles [SWS_LinSM_00241] [SWS_LinSM_00242] [SWS_LinSM_00243]. Los parámetros de temporización más importantes son LinSMConfirmationTimeout (SWS LinSM p. 28) y LinSMSilenceAfterWakeupTimeout [SWS_LinSM_00235]. Los contenedores LinSMSchedule hacen referencia a schedules de la configuración de LinIf (SWS LinSM p. 52). Las comprobaciones de DET dependen de LinSMDevErrorDetect [SWS_LinSM_00239].

Muchos pasajes del documento proceden de releases posteriores. Para R20-11, los requirements son determinantes y discrepan en algunos puntos:

• El segundo parámetro de LinSM_ScheduleRequest se denomina schedule en R20-11 y se describe como «Pointer to the new Schedule table», aunque su tipo sea LinIf_SchHandleType [SWS_LinSM_00113]. Con R22-11 se renombró (SWS LinSM p. 1, Release Overview p. 50); en R24-11 se denomina ScheduleTableIdx (SWS LinSM p. 34).
• En R20-11, LinSM_GetCurrentComMode tiene el Service-ID 0x11 [SWS_LinSM_00122] y LinSM_RequestComMode el Service-ID 0x12 [SWS_LinSM_00126]. Versiones posteriores indican 0x41 y 0x40 y solo permiten reentrancia para redes distintas (SWS LinSM p. 35, SWS LinSM p. 36).
• Las callbacks de ComM se denominan ComM_BusSM_… [SWS_LinSM_00233] en R20-11, y ComM_<Bus>SM_… en R25-11 (SWS LinSM p. 41).

Comportamiento en caso de error

[SWS_LinSM_00053] define los errores de desarrollo:

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

Con LinSMDevErrorDetect activo, las callbacks comprueban la red y la inicialización, como por ejemplo LinSM_GotoSleepIndication [SWS_LinSM_00239] [SWS_LinSM_00240]. Las callbacks no tienen valor de retorno, por lo que allí solo se emite la notificación DET (SWS LinSM p. 40, SWS LinSM p. 39). Las API con Std_ReturnType devuelven adicionalmente E_NOT_OK, por ejemplo en caso de red, modo o schedule no válidos o en el estado LINSM_UNINIT (SWS LinSM p. 36, SWS LinSM p. 34). Interpretación: Estas comprobaciones proceden de versiones a partir de R24-11 y es de suponer que se apliquen con el mismo contenido a R20-11. Llama la atención que la versión posterior también exija E_NOT_OK ante un puntero NULL para la API void LinSM_GetVersionInfo [SWS_LinSM_00117] (SWS LinSM p. 34). Pregunta Q-6b2d75dd286bdcb4 (abierta)

Como error de tiempo de ejecución se prevé LINSM_E_CONFIRMATION_TIMEOUT (0x00) para callbacks ausentes de LinIf [SWS_LinSM_00224]. Presumiblemente se notifica a través de Det_ReportRuntimeError, que las versiones posteriores listan como interfaz obligatoria (SWS LinSM p. 41). Pregunta Q-06b13a07d0d60152 (abierta) Funcionalmente, LinSM garantiza que ComM y BswM vean siempre un estado coherente:

• Tras un wakeup fallido, vuelve a establecer y notificar el estado anterior (SWS LinSM p. 27).
• En caso de E_NOT_OK de LinIf_GotoSleep, se aplica lo mismo [SWS_LinSM_00177].
• Una confirmación de suspensión conduce a LINSM_NO_COM incluso con success = FALSE (SWS LinSM p. 24).
• En caso de un cambio de schedule fallido, BswM recibe el schedule anterior o el que no ha sufrido modificaciones (SWS LinSM p. 26).

Más evidencia detallada

• Petición de modo de ComM y transición a suspensión en el master: [SWS_LinSM_00126], [SWS_LinSM_00036], [SWS_LinSM_10208], [SWS_LinSM_10209], [SWS_LinSM_00177].
• Transición a suspensión en el slave: [SWS_LinSM_91000], [SWS_LinSM_00230], [SWS_LinSM_00231], [SWS_LinSM_00233], [SWS_LinSM_00234]; además, la secuencia en SWS LinSM p. 24.
• Wakeup y supervisión temporal: [SWS_LinSM_00132], [SWS_LinSM_00235], [SWS_LinSM_00236], [SWS_LinSM_00237], SWS LinSM p. 28.
• Cambio de schedule: [SWS_LinSM_00113], [SWS_LinSM_00129], [SWS_LinSM_00241], [SWS_LinSM_00242].
• Inicialización, estados y tipos: [SWS_LinSM_00155], [SWS_LinSM_00156], [SWS_LinSM_00220], [SWS_LinSM_00221], [SWS_LinSM_00301]; notificación a BswM en SWS BswM p. 72.
• Códigos de error e interfaces: [SWS_LinSM_00053], [SWS_LinSM_00224], [SWS_LinSM_00229], [SWS_LinSM_00138], [SWS_LinSM_00219].
• Trazabilidad hacia los requisitos SRS y lista de requisitos no aplicables: SWS LinSM p. 18, SWS LinSM p. 55.