AUTOSAR_SWS_COMManager
FIG-3aa656db6a0605fe
821 × 916 px
1 Release(s)
Figure 12: Request Communication
SHA-256 Inhalts-Fingerabdruck:
3aa656db6a0605fe1906b09990e75b372aff01b03358712045013bb89aae3bcf
✦
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_COMMUNICATIONnachCOMM_FULL_COMMUNICATIONim 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 (
ComMChannel 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
- Initialzustand: Der betroffene Kanal befindet sich in
COMM_NO_COM_NO_PENDING_REQUEST. - Trigger-Phase (
alt Active start up):- Pfad
[User request]: Ein Modusnutzer ruft via RTE synchronComM_RequestComMode(User, COMM_FULL_COMMUNICATION)auf. - Pfad
[Active diagnostic]: DCM signalisiert aktive Diagnose viaComM_DCM_ActiveDiagnostic(NetworkHandle). - Folge: Kanalzustand wechselt auf
COMM_NO_COM_REQUEST_PENDING.
- Pfad
- Synchronisation & Bus-Aktivierung:
- ComM wartet intern, bis
Communication Allowed == truesignalisiert ist (viaComM_CommunicationAllowed(), typischerweise vonEcuM/BswM). - ComM setzt synchronen Aufruf
CanSM_RequestComMode(NetworkHandle, COMM_FULL_COMMUNICATION)ab; Rückgabewert istE_OK. - Folge: Kanalzustand wechselt auf
COMM_FULL_COM_NETWORK_REQUESTED.
- ComM wartet intern, bis
- Verzweigung nach Netzwerkmanagement-Konfiguration (
alt NM Variant):- Variante
[Full]: ComM ruftNm_NetworkRequest(NetworkHandle)auf (Return:E_OK). Anschließend signalisiert das NM über den CallbackComM_Nm_NetworkMode(Channel)die Bereitschaft. - Variante
[Passive]: Kein aktiver Sende-Request an NM. Sobald Busaktivität erkannt wird, meldet NMComM_Nm_NetworkMode(Channel). - Variante
[None/Light]: Kein aktiver NM-Stack konfiguriert. ComM startet den Mindestlaufzeit-TimerComMTMinFullComModeDuration.
- Variante
- Abschluss Quittierung:
- Sobald Hardware/Transceiver bereit sind, meldet CanSM den Moduswechsel asynchron über
ComM_BusSM_ModeIndication(Channel, COMM_FULL_COMMUNICATION)an den ComM.
- Sobald Hardware/Transceiver bereit sind, meldet CanSM den Moduswechsel asynchron über
4. Normative Relevanz & Entwickler-Hinweise
- Asynchrones Entwurfsmuster: Die Anforderung via
ComM_RequestComModebzw.CanSM_RequestComModebestätigt nur die Entgegennahme (E_OK), nicht den vollzogenen Moduswechsel. SWCs und BswM dürfen erst nach erfolgtem Mode-Switch-Event (ausgelöst durchComM_BusSM_ModeIndication) von aktiver Übertragung ausgehen. - Konfigurationsparameter
ComMNmVariant:- Legt fest, welcher Zweig im Fragment
alt NM Varianteinkompiliert/ausgeführt wird (FULL,PASSIVE,LIGHT,NONE). - Für
LIGHTundNONEist die Parametrierung vonComMTMinFullComModeDurationessenziell, um schnelles Modus-Flattern (Chattering) zu verhindern.
- Legt fest, welcher Zweig im Fragment
- Fehlerquelle Bring-Up /
Communication Allowed: BleibtComM_CommunicationAllowednach dem Start aus (z. B. fehlende EcuM/BswM-Aktion nach Wake-up), verharrt der Kanal blockierend inCOMM_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.
Zugeordnete Anforderungen
Diese Angaben zeigt der Versions-Explorer.