Figure 7.2: State Chart Diagram

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Zustandsdiagramm (State Machine Diagram / Statechart nach UML 2.x) mit hierarchischen Verbundzuständen (Composite States) und Pseudozuständen (Initial State, Choice).
• Technischer Zweck: Spezifikation des dezentralen, direkt koordinierten Netzwerkmanagement-Zustandsautomaten (AUTOSAR Adaptive Platform Network Management ara::nm bzw. generisches AUTOSAR NM-Zustandsmodell gemäß SWS_ANM_00005, SWS_ANM_00006, abgeleitet aus RS_Nm_00044).
• Funktionale Einordnung: Deterministische Koordination des synchronisierten Schlafenlegens und Aufweckens aller Cluster-Knoten über periodische NM-PDUs (Heartbeat-Prinzip). Stellt sicher, dass das Übertragungsmedium (CAN/FlexRay/Ethernet) nur aktiv bestromt und belegt wird, solange mindestens ein Knoten aktiven Kommunikationsbedarf signalisiert (Network requested).

2. Komponenten, Entitäten & Schnittstellen

• Top-Level-Modi & Zustände:
  • PowerOff: Initialer Pseudozustand vor Systemstart/Initialisierung.
  • Bus Sleep Mode: Ruhezustand; Netzwerk- und NM-Kommunikation sind gestoppt, Transceiver befinden sich im stromsparenden Standby/Sleep-Modus.
  • Prepare Bus Sleep Mode: Übergangszustand zur Beruhigung des Busses; keine eigene NM-PDU-Transmission, Warten auf Transceiver-Bereitschaft und Synchronisation.
  • Network Mode (Composite State): Aktiver Kommunikationsmodus mit PDU-Freigabe, unterteilt in drei Sub-Zustände:
    • RepeatMessageState: Initialer Sub-Zustand beim Eintritt in den Network Mode; dient der Knotenerkennung (Node Detection) und Cluster-Synchronisation via repetitiver NM-PDUs.
    • Nomral Operation State [sic, Normal Operation State]: Zustand mit aktivem lokalem Kommunikationsbedarf; zyklisches Senden und Empfangen von NM-PDUs.
    • Ready Sleep State: Zustand ohne lokalen Kommunikationsbedarf; passives Horchen auf externe NM-PDUs ohne eigene PDU-Transmission.
• Pseudozustände & Verzweigungen:
  • Choice-Pseudozustand am Eingang von Network Mode: Führt bei Eintritt immer deterministisch in den RepeatMessageState.
  • Choice-Pseudozustand am Ausgang des RepeatMessageState: Verzweigung abhängig von der Bedingung Network requested vs. Network released.
• Timer & Kontrollvariablen (Entitäten):
  • NM-Timeout timer: Cluster-Timeout zur Erkennung ausbleibender Netzwerkaktivität.
  • Repeat Message timer: Monoflop-Timer zur Begrenzung der Verweildauer im RepeatMessageState.
  • Wait Bus Sleep timer: Haltezeit zur Absicherung, dass alle Knoten transmissionsfrei sind, bevor der Bus-Sleep eingenommen wird.
  • Repeat Message Request Bit (CBV / Control Bit Vector): In NM-PDU transportiertes Steuerbit (Repeat Meassage Request Bit Indication [sic]) zur erzwungenen Cluster-Re-Synchronisation.
• Schnittstellen-Ereignisse (Triggers / Actions):
  • Lokale API-Anforderungen: Network requested (z. B. RequestNetwork()), Network released (z. B. ReleaseNetwork()).
  • Bus- und Treiber-Events: NM message received, NM message sent, NM-Timeout timer expired, Wait Bus Sleep timer expired, Repeat Message timer expired.

3. Dynamisches Verhalten & Sequenzablauf

1. Initialisierung:
   • Transition von PowerOff in Bus Sleep Mode.
2. Aufwecken / Netzanforderung:
   • Tritt Network requested im Bus Sleep Mode oder Prepare Bus Sleep Mode auf, erfolgt der sofortige Übergang in den Network Mode.
   • Eintrittsaktion: Start von NM-Timeout timer und Repeat Message timer; Aktivierung des Sub-Zustands RepeatMessageState.
3. Phase im RepeatMessageState:
   • Zyklischer Ablauf: Bei NM-Timeout timer expired erfolgt ein Neustart (Start NM-Timeout timer) und PDU-Versand.
   • Empfang (NM message received) oder Versand (NM message sent) einer NM-PDU re-triggert den NM-Timeout timer global im Network Mode.
   • Nach Ablauf des Repeat Message timer:
     • Ist Network requested aktiv → Wechsel in Normal Operation State.
     • Ist Network released aktiv → Wechsel in Ready Sleep State.
4. Betrieb im Normal Operation State:
   • Periodische Re-Triggerung des NM-Timeout timer bei Timeout.
   • Gibt die Applikation das Netzwerk frei (Network released), wechselt die State Machine asynchron in Ready Sleep State.
   • Empfang einer NM-PDU mit gesetztem Repeat Message Request Bit erzwingt den Rücksprung in RepeatMessageState unter Start des Repeat Message timer.
5. Abschaltpfad (Dezentraler Sleep-Konsens):
   • Im Ready Sleep State sendet der Knoten keine eigenen NM-PDUs mehr.
   • Wird erneut lokaler Bedarf gemeldet (Network requested), erfolgt der direkte Rücksprung nach Normal Operation State.
   • Bleiben fremde NM-PDUs über die Zeitspanne des NM-Timeout timer aus (NM-Timeout timer expired), wird der Network Mode verlassen:
     • Transition in Prepare Bus Sleep Mode.
     • Transition-Action: Start Wait Bus Sleep timer.
   • Läuft der Wait Bus Sleep timer ohne Neu-Anforderung (Network requested) ab (Wait Bus Sleep timer expired), wechselt der Automat in den Bus Sleep Mode. Transceiver-Standby wird initiiert.

4. Normative Relevanz & Entwickler-Hinweise

• Timing-Restriktionen & Parametrierung:
  • Das Verhältnis der Timer muss strikt konfiguriert sein: $T_{\text{NM\_MessageCycle}} < T_{\text{NM\_Timeout}} < T_{\text{WaitBusSleep}}$.
  • T_NM_Timeout muss Jitter, Sendeverzögerungen und CAN-Arbitrierungstoleranzen abdecken, um verfrühte Bus-Sleep-Übergänge zu verhindern.
  • T_WaitBusSleep muss clusterweit auf allen ECUs identisch parametriert sein, um asynchrones Wiedereinschlafen bzw. Teilnetz-Desynchronisationen zu vermeiden.
• IPDUM- & Com-Kopplung (BswM / State Management):
  • Im Normal Operation State und RepeatMessageState sind die anwendungsbezogenen Kommunikationspfade (Com Tx/Rx) aktiv geschaltet.
  • Beim Eintritt in Prepare Bus Sleep Mode müssen alle Applikations-PDUs (Tx) über die Kommunikationsschichten gesperrt werden, um ein parasitäres Wiederaufwecken des Busses durch Applikationsnachrichten zu unterbinden.
• Vermeidung von Endlosschleifen:
  • Ein fehlerhaft gesetztes Repeat Message Request Bit eines defekten Knotens auf dem Bus ("Babbling Node") kann alle Teilnehmer dauerhaft im RepeatMessageState binden. Treiber- und Stack-Implementierer müssen RMR-Filter und Plausibilitätsprüfungen vorsehen.
• API-Verhalten:
  • Aufrufe von ReleaseNetwork() schalten den Zustand nicht sofort inaktiv, sondern delegieren das Abschalten an das Auslaufen des NM-Timeout timer im Ready Sleep State. Applikationscode darf nach ReleaseNetwork() keine sofortige Bus-Inaktivität voraussetzen.