DEENESPTFRRUARHIKOZHNL
AUTOSAR_SWS_COMManager FIG-ca087d17aad45794 821 × 917 px 1 Release(s)

Figure 12: Request Communication

SHA-256 Inhalts-Fingerabdruck: ca087d17aad457942cbb33de7f85c702737df4f52d0ad3c5e96936f51374bd57
✦ KI-generierte Bildanalyse & technische Beschreibung Modell: gemini-3.8-flash (via agy) · Rezept figure-series@1 · erstellt am 2026-10-08

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.

Versionsvergleich KI-generiert · gemini-3.8-flash (via agy)

R4.1.3 → R4.2.2 keine inhaltliche Änderung Vorgänger: FIG-9637330d30b9cd87

Keine inhaltlichen Änderungen erkennbar.

R4.2.2 → R4.3.1 keine inhaltliche Änderung Nachfolger: FIG-2537fc8ebd2b5909

Keine inhaltlichen Änderungen erkennbar.

Zugeordnete Anforderungen

Diese Angaben zeigt der Versions-Explorer.

Erkannte Spezifikationsbelege & Anforderungen auf dieser Seite

Aus dem Dokument extrahierter Text & Kontext

Beschriftungen im Schaubild:

«module» | EcuM | «module» | Dcm | «module» | Rte | «module» | ComM | «module» | Nm | «module» | CanSM | alt Active start up | [User request] | [Active diagnostic] | Request COMM_FULL_COMMUNICATION | alt NM Variant | [Full] | [Passive] | [None/Light] | COMM_NO_COM_NO_PENDING_REQUEST | COMM_NO_COM_REQUEST_PENDING | COMM_FULL_COM_NETWORK_REQUESTED | ComM_RequestComMode(Std_ReturnType, ComM_UserHandleType, ComM_ModeType) | ComM_DCM_ActiveDiagnostic(NetworkHandleType) | Wait for Communication Allowed = true | CanSM_RequestComMode(NetworkHandle, ComM_Mode: =COMM_FULL_COMMUNICATION) | CanSM_RequestComMode(...)=E_OK | Nm_NetworkRequest(NetworkHandle) | NM_NetworkRequest(...)=E_OK | ComM_Nm_NetworkMode(Channel) | ComM_Nm_NetworkMode(...) | ComM_Nm_NetworkMode(Channel) | Start timer ComMTMinFullComModeDuration | ComM_BusSM_ModeIndication(Channel, ComMode: =COMM_FULL_COMMUNICATION)

Begleitender Spezifikationstext:

112 of 135 Document ID 079: AUTOSAR_SWS_COMManager - AUTOSAR confidential - 9.4 Communication request Figure 12 shows the possibilities to start COMM_FULL_COMMUNICATION on CAN. It can be either initiated if a user requests COMM_FULL_COMMUNICATION request or DCM indicates ComM_DCM_ActiveDiagnostic (see SWS_ComM_00873 ). The behaviour is equal for LIN, FlexRay and Ethernet just with different API names. «module» EcuM «module» Dcm «module» Rte «module» ComM «module» Nm «module» CanSM alt Active start up [User request] [Active diagnostic] Request COMM_FULL_COMMUNICATION alt NM Variant [Full] [Passive] [None/Light] COMM_NO_COM_NO_PENDING_REQUEST COMM_NO_COM_REQUEST_PENDING COMM_FULL_COM_NETWORK_REQUESTED ComM_RequestComMode(Std_ReturnType, ComM_UserHandleType, ComM_ModeType) ComM_DCM_ActiveDiagnostic(NetworkHandleType) Wait for Communication Allowed = true CanSM_RequestComMode(NetworkHandle, ComM_Mode: =COMM_FULL_COMMUNICATION) CanSM_RequestComMode(...)=E_OK Nm_NetworkRequest(NetworkHandle) NM_NetworkRequest(...)=E_OK ComM_Nm_NetworkMode(Channel) ComM_Nm_NetworkMode(...) ComM_Nm_NetworkMode(Channel) Start timer ComMTMinFullComModeDuration ComM_BusSM_ModeIndication(Channel, ComMode: =COMM_FULL_COMMUNICATION)

Vorkommen in AUTOSAR-Releases (1)

Release Dokument Seite Nr. Bildunterschrift im Dokument
R4.2.2 AUTOSAR_SWS_COMManager S. 112 12 Figure 12: Request Communication