Figure 10: Reaction on a wake-up indicated by the ECU State Manager module

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML 2.0 Sequenzdiagramm mit kombinierten Fragmenten (alt), Status-Invarianten (Zustandsmarkern) sowie synchronen und asynchronen Service-Interaktionen.
• Technischer Zweck: Spezifikation des standardisierten Verhaltens des Communication Managers (ComM) beim Auftreten eines passiven Bus-Wakeups (extern induzierte Busaktivität) auf einem CAN-Netzwerkkanal gemäß AUTOSAR Classic Platform (SWS COMManager, R4.0.3, Kap. 9.2).
• Architektur-Einordnung: Koordination der System- und Kommunikationsdienste im AUTOSAR BSW-Schichtenmodell. Es definiert die Interaktionskaskade zwischen ECU State Manager (EcuM), Generic Network Management (Nm), CAN State Manager (CanSM) und dem ComM-Zustandsautomaten.

2. Komponenten, Entitäten & Schnittstellen

• Beteiligte Module (Lebenslinien):
  • «module» EcuM: ECU State Manager – signalisiert hardwarenahe Wakeup-Ereignisse (Transceiver/Controller).
  • «module» Dcm: Diagnostic Communication Manager – im passiven Wakeup passiv (keine Diagnoseanforderung aktiv).
  • «module» Rte: Runtime Environment – entkoppelt Applikation von BSW; bleibt unbeteiligt, da keine lokale SW-C-Kommunikationsanforderung vorliegt.
  • «module» ComM: Communication Manager – zentrale Vermittlungs- und Zustandsinstanz für Kommunikationskanäle.
  • «module» Nm: Network Management Interface – busunabhängige Abstraktionsschicht des Netzmanagements.
  • «module» CanSM: CAN State Manager – steuert den Kommunikationsmodus des CAN-Subsystems (Controller/Transceiver via CanIf).
• Zustandsinvariante Entitäten (ComM-Kanalzustände):
  • COMM_NO_COM_NO_PENDING_REQUEST: Kanal im stromsparenden Ruhezustand ohne anhängige Anforderung.
  • COMM_NO_COM_REQUEST_PENDING: Zwischenzustand nach Wakeup-Signal; Kanal wartet auf Freigabe (CommunicationAllowed).
  • COMM_FULL_COM_NETWORK_REQUESTED: Subzustand von COMM_FULL_COMMUNICATION; Vollkommunikation ausschließlich durch Netzwerk-Wakeup initiiert (kein lokaler User-Request).
• Schnittstellen & Datentypen:
  • NetworkHandleType: Kanal-Identifier (Channel, NetworkHandle).
  • ComM_ModeType: COMM_FULL_COMMUNICATION, COMM_NO_COMMUNICATION.
  • Std_ReturnType: Rückgabewert (E_OK, E_NOT_OK).
  • Nm_ReturnType: Spezifischer NM-Statuscode (NM_E_OK).

3. Dynamisches Verhalten & Sequenzablauf

1. Trigger & Wake-up Detection (alt Passive start up):
   • Das System befindet sich in COMM_NO_COM_NO_PENDING_REQUEST.
   • Einer von drei wechselseitig exklusiven Triggern weckt den Kanal auf:
     • ComM_EcuM_WakeUpIndication(NetworkHandleType): Wake-up durch Hardware-Interrupt via EcuM.
     • ComM_Nm_RestartIndication(NetworkHandleType): Busaktivität im Zustand Bus-Sleep via Nm.
     • ComM_Nm_NetworkStartIndication(NetworkHandleType): Empfang einer NM-PDU im Zustand Prepare Bus-Sleep via Nm.
2. Transition & Kommunikationsfreigabe:
   • ComM wechselt in den Zustand COMM_NO_COM_REQUEST_PENDING.
   • Guard Condition: Wait for CommunicationAllowed = True (wird über ComM_CommunicationAllowed() durch EcuM bzw. BswM gesetzt).
3. Modusanforderung an den Bus State Manager:
   • Synchroner Aufruf: CanSM_RequestComMode(NetworkHandle, COMM_FULL_COMMUNICATION) durch ComM.
   • Quittierung: CanSM liefert synchron E_OK zurück.
   • ComM wechselt in den Zustand COMM_FULL_COM_NETWORK_REQUESTED.
4. Verzweigung nach NM-Variante (alt NM Variant):
   • Pfad [Full/Passive] (ComMNmVariant == FULL | PASSIVE):
     • ComM ruft synchron Nm_PassiveStartUp(NetworkHandle) auf.
     • Nm quittiert mit NM_E_OK.
     • Nm signalisiert den Eintritt in den Netzwerkmodus asynchron via Callback ComM_Nm_NetworkMode(Channel).
   • Pfad [None/Light] (ComMNmVariant == NONE | LIGHT):
     • Da kein standardisiertes NM-Protokoll gefahren wird, startet ComM intern den Timer ComMTMinFullComModeDuration, um ein sofortiges Wiedereinschlafen des Kanals zu verhindern.
5. Asynchrone Modusbestätigung:
   • Sobald die CAN-Hardware vollständig hochgefahren ist, meldet CanSM die erfolgreiche Zustandsumschaltung asynchron an ComM via ComM_BusSM_ModeIndication(Channel, COMM_FULL_COMMUNICATION).

4. Normative Relevanz & Entwickler-Hinweise

• Konfiguration (ComMNmVariant & Timer):
  • Bei ComMNmVariant = NONE oder LIGHT ist der Parameter ComMTMinFullComModeDuration zwingend abzustimmen; er stellt die minimale Sende-/Empfangsbereitschaft sicher, bevor der Kanal wieder in den No-Com-Modus fallen darf.
  • Bei FULL oder PASSIVE steuert das NM-Timeout-Verhalten (CanNm) die Haltedauer des Busses.
• Blockade-Bedingung (CommunicationAllowed):
  • Erhält ComM nach einem Wakeup kein ComM_CommunicationAllowed(Channel, TRUE) (z. B. wegen fehlerhafter BswM-Regeln oder unvollständiger EcuM-Startup-Phasen), verbleibt der Kanal in COMM_NO_COM_REQUEST_PENDING. Es erfolgt kein CanSM_RequestComMode(), der Transceiver bleibt stumm.
• Asynchrone Bestätigungspflicht:
  • CanSM_RequestComMode() ist synchron nicht-blockierend (E_OK signalisiert nur die Annahme). Erst mit Eintreffen von ComM_BusSM_ModeIndication() gilt der Bus als physikalisch online.
• Protokollunabhängigkeit:
  • Das Sequenzmuster ist generisch für alle Bustechnologien identisch; bei LIN, FlexRay oder Ethernet substituieren LinSM, FrSM bzw. EthSM die CanSM-Aufrufe analog.