Figure 5: LinSM State Machine (slave node)

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Hierarchischer UML-Zustandsautomat (Hierarchical State Machine / Statechart Diagram).
• Architektur-Einordnung:
  • Teil des AUTOSAR Classic Platform Communication Stacks (Com-Stack), spezifiziert in AUTOSAR_SWS_LINStateManager.
  • Das Diagramm definiert den Lebenszyklus und die Betriebsmodi des LIN State Managers (LinSM) exklusiv für LIN-Slave-Knoten (Slave Node).
  • Funktionale Abgrenzung zum Master-Knoten: Ein LIN-Slave besitzt kein Schedule-Table-Management. Seine Zustandsmaschine beschränkt sich auf das Hochfahren des Stacks, die Freigabe des Kommunikationskanals und das Abhandeln des Sleep-Modus auf Veranlassung des LIN-Masters bzw. des Busses.

2. Komponenten, Entitäten & Schnittstellen

• Hierarchische Zustände (States):
  • LINSM_UNINIT: Modulweiter Zustand vor Ausführung der Basisinitialisierung.
  • LINSM_INIT: Modulweiter übergeordneter Verbundzustand (Composite State), aktiv nach erfolgreicher Initialisierung.
  • LINSM_NO_COM: Subzustand je LIN-Netzwerkkanal. Keine Buskommunikation; Transceiver und Controller befinden sich im Standby/Sleep.
  • LINSM_FULL_COM: Verbundzustand für aktive Kommunikation (Sub-States: LINSM_RUN_COMMUNICATION, LINSM_GOTO_SLEEP).
  • LINSM_RUN_COMMUNICATION: Regulärer Betriebsmodus; Senden/Empfangen von LIN-Frames aktiv.
  • LINSM_GOTO_SLEEP: Transitorischer Subzustand; Warten auf Bestätigung des Einschlafvorgangs durch die untergelagerten Treiber.
• Schnittstellen & Interaktionspartner (APIs & Callbacks):
  • Obere Schicht (ComM / BswM):
    • Modus-Anforderungen über LinSM_RequestComMode(network, mode) (repräsentiert durch Bedingung reqComMode == FULL_COM).
    • Zustandsrückmeldungen an BswM/ComM (BswM_LinSM_CurrentState, ComM_BusSM_ModeIndication).
  • Untere Schicht (LinIf):
    • LinIf_GotoSleep(network): Synchrone Service-Anforderung zur Einleitung des Sleep-Modus auf dem LIN-Treiber/Transceiver.
    • LinSM_GotoSleepIndication(network): Asynchroner Callback des LinIf bei Empfang eines Sleep-Command-Frames (Master-Request-Frame 0x3C mit Sleep-Payload).
    • LinSM_GotoSleepConfirmation(network, success): Bestätigungs-Callback des LinIf nach erfolgtem Bus-Sleep/Transceiver-Standby.
    • LinSM_WakeupConfirmation(network, success): Callback des LinIf nach erfolgreichem Bus-Wakeup bzw. Transceiver-Aktivierung.
  • System Control (EcuM):
    • LinSM_Init(ConfigPtr): Synchrone Initialisierungsfunktion.
• Kardinalitäten & Instanziierung:
  • Modul-Ebene: Singleton (LINSM_UNINIT → LINSM_INIT).
  • Netzwerk-Ebene: 1..n Instanzen für [For each LIN network] parallel innerhalb von LINSM_INIT. Jeder konfigurierte LIN-Kanal besitzt eine eigene Instanz des Kanal-Zustandsautomaten (LINSM_NO_COM, LINSM_FULL_COM).

3. Dynamisches Verhalten & Sequenzablauf

1. Initialisierungsphase (SWS_LinSM_00022):
   • Trigger: LinSM_Init().
   • Transition: LINSM_UNINIT → LINSM_INIT.
   • Für jeden konfigurierten LIN-Kanal erfolgt initial der Übergang in LINSM_NO_COM.
2. Aktivierung der Kommunikation (NO_COM → FULL_COM):
   • Voraussetzung: Der Kommunikationsmodus FULL_COM wurde angefordert (reqComMode == FULL_COM).
   • Trigger: Asynchroner Empfang des Callbacks LinSM_WakeupConfirmation() durch den LinIf (ausgelöst durch Wakeup-Frame auf dem Bus oder lokalen Wakeup).
   • Transition: LINSM_NO_COM → LINSM_FULL_COM → Initial-Transition direkt nach LINSM_RUN_COMMUNICATION.
3. Einschlafen auf Master-Anforderung (RUN_COMMUNICATION → GOTO_SLEEP, SWS_LinSM_00161):
   • Trigger: LinIf detektiert einen Sleep-Mode-Frame auf dem Bus und ruft LinSM_GotoSleepIndication(network) auf.
   • Guard-Bedingung: Aufruf von LinIf_GotoSleep(network) == E_OK.
   • Transition: Bei erfolgreichem Aufruf wechselt der Kanal in LINSM_GOTO_SLEEP.
   • Fehlerfall: Liefert LinIf_GotoSleep() nicht E_OK, verbleibt der Automat in LINSM_RUN_COMMUNICATION.
4. Abschluss des Sleep-Vorgangs (GOTO_SLEEP → NO_COM):
   • Trigger: Asynchroner Callback LinSM_GotoSleepConfirmation(network).
   • Transition: LINSM_GOTO_SLEEP verlässt LINSM_FULL_COM zurück nach LINSM_NO_COM.
   • Folgeaktion: Meldung des Zustandswechsels an ComM via ComM_BusSM_ModeIndication(network, COMM_NO_COMMUNICATION).

4. Normative Relevanz & Entwickler-Hinweise

• Kanalunabhängigkeit: Der LinSM muss reentrant ausgelegt sein. Mehrere LIN-Cluster laufen zustandsmäßig vollständig entkoppelt voneinander.
• Keine Schedule-Tabellen-Verwaltung: Im Gegensatz zum LIN-Master (LinSM_ScheduleRequest, Sub-States wie LINSM_GOTO_SLEEP mit internen Retry-Timern für Master-Sleep-Commands) reagiert der Slave rein reaktiv auf Bus-Events (LinSM_GotoSleepIndication). Es dürfen in Slave-Konfigurationen keine Schedule-Tabellen konfiguriert oder referenziert werden (LinSMNodeType == LINSM_SLAVE_NODE).
• Asynchrone Bestätigungslogik & Timeouts:
  • Der Zustand LINSM_GOTO_SLEEP darf nicht blockierend sein.
  • Entwickler müssen das konfigurierbare Timeout LinSMConfirmationTimeout beachten: Bleibt LinSM_GotoSleepConfirmation() nach LinIf_GotoSleep() aus, muss das Modul den Fehler an das DEM (LINSM_E_CONFIRMATION_TIMEOUT) melden und eine Fehlerbehandlung einleiten.
• Schnittstellenintegrität (DET-Prüfung):
  • Eingehende Callbacks (LinSM_GotoSleepIndication, LinSM_GotoSleepConfirmation, LinSM_WakeupConfirmation) in ungültigen Zuständen (z. B. Confirmation in LINSM_UNINIT oder LINSM_NO_COM) müssen abgewiesen und bei aktivem DET mit LINSM_E_UNINIT bzw. Fehlern zur Laufzeit gemeldet werden.