Figure 7: Schedule Table switch

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Sequenzdiagramm (Interaktionsdiagramm).
• Architektur-Kontext: AUTOSAR Classic Platform (Release 4.0.3), Kommunikations- und Modusmanagement-Stack.
• Technischer Zweck: Spezifikation des asynchronen Umschaltvorgangs für LIN-Schedule-Tabellen (Schedule Table switch). Das Diagramm definiert das Zusammenspiel zwischen dem Basic Software Mode Manager (BswM), dem LIN State Manager (LinSM) und dem LIN Interface (LinIf) inklusive Bestätigungsschleife und Timeout-Überwachung.

2. Komponenten, Entitäten & Schnittstellen

Beteiligte Module (Lifelines)

• «module» BswM: System-/Modus-Koordinator; fordert Fahrplanwechsel an und konsumiert den bestätigten Status zur Modusauswertung.
• «module» LinSM: Abstraktions- und Überwachungsschicht für LIN-Netzwerke; validiert den Modus, startet Timeout-Timer und vermittelt zwischen BswM und LinIf.
• «module» LinIf: Hardwarenahe Schnittstelle; steuert den LIN-Treiber und wickelt den tatsächlichen Slot-Wechsel im LIN-Frame-Header/Schedule-Zyklus ab.

Schnittstellen & Signaturen

• LinSM_ScheduleRequest(NetworkHandleType network, LinIf_SchHandleType schedule) : Std_ReturnType
  • Synchroner Service-Aufruf von BswM an LinSM zur Anforderung einer neuen Schedule-Tabelle.
• LinIf_ScheduleRequest(NetworkHandleType network, LinIf_SchHandleType schedule) : Std_ReturnType
  • Synchroner Weiterleitungsaufruf von LinSM an LinIf.
• LinSM_ScheduleRequestConfirmation(NetworkHandleType network, LinIf_SchHandleType schedule) : void
  • Asynchroner Callback von LinIf an LinSM, sobald der Master den Tabellenwechsel auf dem Bus (meist am Ende des aktuellen Slots oder Zyklus) vollzogen hat.
• BswM_LinSM_CurrentSchedule(NetworkHandleType network, LinIf_SchHandleType schedule) : void
  • Modus-Indikation von LinSM an BswM zur Aktualisierung der BswM-Mode-Arbitration.

3. Dynamisches Verhalten & Sequenzablauf

1. Trigger & Request-Phase (synchron):
   • BswM initiiert den Wechsel auf new_schedule via LinSM_ScheduleRequest().
   • LinSM ruft direkt downstream LinIf_ScheduleRequest() auf.
   • LinIf quittiert die Annahme der Anforderung synchron mit E_OK an LinSM.
2. Timer-Start & Entkopplung:
   • Nach erfolgreichem LinIf_ScheduleRequest() startet LinSM lokal die Überwachungszeit (start_timer() → LinSMConfirmationTimeout).
   • LinSM kehrt synchron mit Rückgabewert an BswM zurück. Der eigentliche Buswechsel erfolgt zeitversetzt.
3. Bestätigungsphase (asynchron):
   • Sobald LinIf den Wechsel vollzogen hat, erfolgt der Callback LinSM_ScheduleRequestConfirmation(network, schedule) an LinSM.
   • LinSM stoppt den laufenden Timeout-Timer (stop_timer()).
4. Modus-Meldung:
   • LinSM meldet den aktiven Fahrplan über BswM_LinSM_CurrentSchedule() an BswM.
   • BswM aktualisiert seine internen Zustandsregeln; der Kontrollfluss kehrt über LinSM zurück zu LinIf.

4. Normative Relevanz & Entwickler-Hinweise

• Asynchrones Protokollverhalten: Ein Tabellenwechsel auf LIN erfolgt nie ad hoc mitten im Frame. LinIf_ScheduleRequest registriert den Wunsch; erst am Ende des laufenden Slots/Frames bzw. Schedule-Zyklus aktiviert der LIN-Master-Task die neue Tabelle.
• Timeout-Supervision (LinSMConfirmationTimeout):
  • Tritt kein LinSM_ScheduleRequestConfirmation() innerhalb der konfigurierten Zeitspanne auf, läuft der Timer ab.
  • Konsequenz bei Timeout: LinSM meldet einen Fehler (Det/Dem LINSM_E_CONFIRMATION_TIMEOUT) und BswM wird nicht positiv über den Tabellenwechsel informiert.
• Konfigurationsaspekte:
  • LinSMConfirmationTimeout muss in LinSM größer parametriert werden als die maximale Dauer des längsten LIN-Frames bzw. Schedule-Slots des Zielclusters plus Task-Jitter.
  • Schedule-IDs (LinIf_SchHandleType) müssen zwischen BswM-Regeln, LinSM-Konfiguration und LinIf-Tabellenkonsistenz 1:1 gemappt sein.
• Reentrancy & Kontext:
  • LinSM_ScheduleRequest wird im Kontext des aufrufenden Tasks (typischerweise BswM-Task) ausgeführt.
  • LinSM_ScheduleRequestConfirmation wird typischerweise aus dem zyklischen Task der LinIf_MainFunction oder dem LIN-Treiber-ISR aufgerufen. Reentrancy-Schutz auf den Kanalzuständen im LinSM ist zwingend einzuhalten.