Figure 9.4: Request Communication

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML 2.0 Sequenzdiagramm mit Zustandsinvarianten (State Invariants) und kombinierten Fragmenten (alt).
• Technischer Zweck: Spezifikation des standardisierten Kommunikationsaufbaus (Communication Request) und des Zustandswechsels von COMM_NO_COMMUNICATION nach COMM_FULL_COMMUNICATION im AUTOSAR Classic Communication Manager (ComM, SWS R4.0.3).
• Funktionale Einordnung: Koordination von Benutzeranforderungen (SWCs/RTE) und Diagnoseanforderungen (DCM) mit dem Bus State Manager (am Beispiel CanSM) und dem generischen Netzwerkmanagement (Nm).

2. Komponenten, Entitäten & Schnittstellen

• Module / Lifelines («module»):
  • EcuM: ECU State Manager (liefert systemische Freigaben wie Communication Allowed).
  • Dcm: Diagnostic Communication Manager (fordert Kommunikationskanäle für aktive Diagnose-Sessions an).
  • Rte: VFB/Runtime Environment (Transportlayer für SWC-Modusanfragen).
  • ComM: Communication Manager (Zentraler Moduskoordinator des Kommunikations-Subsystems).
  • Nm: Generic Network Management Interface (Abstraktionsebene für busspezifische NM-Stacks).
  • CanSM: CAN State Manager (Busspezifische Steuerung von Controller und Transceiver).
• Zustandsinvarianten (ComM Channel State Machine):
  • COMM_NO_COM_NO_PENDING_REQUEST: Ruhezustand; keine Kommunikation aktiv, keine Anforderung anhängig.
  • COMM_NO_COM_REQUEST_PENDING: Anforderung registriert, wartet auf Ausführungsbedingungen (Communication Allowed).
  • COMM_FULL_COM_NETWORK_REQUESTED: BusSM- und NM-Anfragen sind abgesetzt; ComM wartet auf Rückmeldungen.
• Schnittstellen / APIs:
  • ComM_RequestComMode(User, ComMode): Synchrone API für SWCs via RTE.
  • ComM_DCM_ActiveDiagnostic(NetworkHandle): Benachrichtigung durch das DCM bei aktiver Diagnose.
  • CanSM_RequestComMode(NetworkHandle, ComMode): Steuer-API an den Bus State Manager.
  • Nm_NetworkRequest(NetworkHandle): Aufforderung an den NM-Stack zum aktiven Wachhalten/Wachrufen des Netzwerks.
  • ComM_Nm_NetworkMode(Channel): Callback-Indikation des generic NM an den ComM über erreichten Netzwerkmodus.
  • ComM_BusSM_ModeIndication(Channel, ComMode): Asynchroner Bestätigungs-Callback des BusSM an den ComM.

3. Dynamisches Verhalten & Sequenzablauf

1. Initialzustand: Der betroffene Kanal befindet sich in COMM_NO_COM_NO_PENDING_REQUEST.
2. Trigger-Phase (alt Active start up):
   • Pfad [User request]: Ein Modusnutzer ruft via RTE synchron ComM_RequestComMode(User, COMM_FULL_COMMUNICATION) auf.
   • Pfad [Active diagnostic]: DCM signalisiert aktive Diagnose via ComM_DCM_ActiveDiagnostic(NetworkHandle).
   • Folge: Kanalzustand wechselt auf COMM_NO_COM_REQUEST_PENDING.
3. Synchronisation & Bus-Aktivierung:
   • ComM wartet intern, bis Communication Allowed == true signalisiert ist (via ComM_CommunicationAllowed(), typischerweise von EcuM/BswM).
   • ComM setzt synchronen Aufruf CanSM_RequestComMode(NetworkHandle, COMM_FULL_COMMUNICATION) ab; Rückgabewert ist E_OK.
   • Folge: Kanalzustand wechselt auf COMM_FULL_COM_NETWORK_REQUESTED.
4. Verzweigung nach Netzwerkmanagement-Konfiguration (alt NM Variant):
   • Variante [Full]: ComM ruft Nm_NetworkRequest(NetworkHandle) auf (Return: E_OK). Anschließend signalisiert das NM über den Callback ComM_Nm_NetworkMode(Channel) die Bereitschaft.
   • Variante [Passive]: Kein aktiver Sende-Request an NM. Sobald Busaktivität erkannt wird, meldet NM ComM_Nm_NetworkMode(Channel).
   • Variante [None/Light]: Kein aktiver NM-Stack konfiguriert. ComM startet den Mindestlaufzeit-Timer ComMTMinFullComModeDuration.
5. Abschluss Quittierung:
   • Sobald Hardware/Transceiver bereit sind, meldet CanSM den Moduswechsel asynchron über ComM_BusSM_ModeIndication(Channel, COMM_FULL_COMMUNICATION) an den ComM.

4. Normative Relevanz & Entwickler-Hinweise

• Asynchrones Entwurfsmuster: Die Anforderung via ComM_RequestComMode bzw. CanSM_RequestComMode bestätigt nur die Entgegennahme (E_OK), nicht den vollzogenen Moduswechsel. SWCs und BswM dürfen erst nach erfolgtem Mode-Switch-Event (ausgelöst durch ComM_BusSM_ModeIndication) von aktiver Übertragung ausgehen.
• Konfigurationsparameter ComMNmVariant:
  • Legt fest, welcher Zweig im Fragment alt NM Variant einkompiliert/ausgeführt wird (FULL, PASSIVE, LIGHT, NONE).
  • Für LIGHT und NONE ist die Parametrierung von ComMTMinFullComModeDuration essenziell, um schnelles Modus-Flattern (Chattering) zu verhindern.
• Fehlerquelle Bring-Up / Communication Allowed: Bleibt ComM_CommunicationAllowed nach dem Start aus (z. B. fehlende EcuM/BswM-Aktion nach Wake-up), verharrt der Kanal blockierend in COMM_NO_COM_REQUEST_PENDING, ohne dass ein Request an den BusSM (CanSM) abgesetzt wird.
• Bus-Agriostik: Der dargestellte Ablauf gilt spezifikationsgemäß identisch für LIN (LinSM), FlexRay (FrSM) und Ethernet (EthSM) unter Substitution der jeweiligen BusSM-Präfixe.