Figure 4.31: Modeling of DiagnosticDoIpTriggerVehicleAnnouncementPortMapping to indicate the existence of a handler to trigger the DoIP Vehicle Announcement

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: Metamodell-Ausschnitt / UML-Klassendiagramm der AUTOSAR Adaptive Platform (AP) Execution & Diagnostic Manifest Specification (M2-Metamodellebene).
• Architektur-Kontext: AUTOSAR Adaptive Platform, Funktionscluster Diagnostic Management (DM) im Zusammenspiel mit dem DoIP-Daemon (ISO 13400-2) und dem Execution Management.
• Funktionaler Zweck: Modellierung der Bindung zwischen einem anwendungsspezifischen Port und dem DoIP-Protokollstack. Das Metamodellelement DiagnosticDoIpTriggerVehicleAnnouncementPortMapping deklariert die Existenz eines Handlers, über den eine Applikation den Versand von DoIP-Fahrzeugankündigungsnachrichten (Vehicle Announcement Messages, VAM via UDP) gezielt anfordern und steuern kann, anstatt diesen rein stack-intern/autark abzuwickeln.

2. Komponenten, Entitäten & Schnittstellen

Metaklassen der Service- und Port-Definition (Schnittstellenebene)

• PortInterface (generalisiert ARElement, AtpBlueprint, AtpBlueprintable, AtpType): Abstrakte Basisklasse aller Schnittstellenbeschreibungen im Metamodell.
• DiagnosticPortInterface (Spezialisierung von PortInterface): Spezialisierte Basisklasse für diagnosebezogene Schnittstellen.
• DiagnosticDoIPTriggerVehicleAnnouncementInterface (Spezialisierung von DiagnosticPortInterface): Normierte Serviceschnittstelle zur Übermittlung des Triggers für die DoIP Vehicle Announcement an den DoIP-Daemon.
• RPortPrototype (Spezialisierung von AbstractRequiredPortPrototype): Repräsentiert den anfordernden Port einer Softwarekomponente innerhalb eines Executables.
  • Beziehung zu PortInterface: +requiredInterface (Kardinalität 0..1, Rolle {redefines atpType}, Stereotyp «isOfType»). Typisiert den Port mit der konkreten Trigger-Schnittstelle.

Metaklassen des Ausführungskontexts

• Process (Spezialisierung von AbstractExecutionContext): Repräsentiert den instanziierten Betriebssystemprozess auf einer Machine.
• ProcessDesign (Spezialisierung von ARElement): Entwurfszeit-Abstraktion des Prozesses.
  • Assoziation: Process verweist über +design (0..1) auf das zugehörige ProcessDesign.

Metaklassen des Diagnose- und Port-Mappings

• DiagnosticMapping (Spezialisierung von DiagnosticCommonElement): Basisklasse für Zuordnungen im Diagnose-Manifest.
• DiagnosticSwMapping (Spezialisierung von DiagnosticMapping): Bildet Diagnoseelemente auf Software-Artefakte ab.
• AbstractDoIpPortMapping (abstrakte Spezialisierung von DiagnosticSwMapping): Gemeinsame Basisklasse für DoIP-spezifische Port-Mappings.
  • Assoziation +process (0..1, Stereotyp «atpSplitable»): Referenziert das ProcessDesign.
  • Assoziation +rPortPrototypeInExecutable (0..1, Stereotyp «atpUriDef,instanceRef»): Typisierte Instanzreferenz auf den konkreten RPortPrototype im Kontext des Executables.
• DiagnosticDoIpTriggerVehicleAnnouncementPortMapping (konkrete Spezialisierung von AbstractDoIpPortMapping): Spezifisches Mapping-Element, das dem Generator/Stack explizit anzeigt, dass ein externer Auslöse-Handler für DoIP Vehicle Announcements vorhanden und angebunden ist.

3. Dynamisches Verhalten & Sequenzablauf

1. Generierungs- und Startphase:
   • Der Manifest-Compiler erkennt über das Vorhandensein von DiagnosticDoIpTriggerVehicleAnnouncementPortMapping, dass die DoIP-Vehicle-Announcement nicht rein autonom durch den DoIP-Stack ausgelöst werden soll.
   • Entsprechende Service-Skelette/Proxies (ara::com bzw. DM-interne IPC-Kopplung) werden generiert und zur Laufzeit zwischen dem DoIP-Daemon und dem Prozess initialisiert.
2. Trigger-Auslösung (Laufzeit):
   • Die anbindende Applikation ermittelt systemspezifische Vorbedingungen (z. B. IP-Adressbezug via DHCP abgeschlossen, Netzwerkstatus stabil, Transition des Fahrzeugzustands).
   • Die Applikation ruft die entsprechende Triggermethode am RPortPrototype auf.
3. Protokollverarbeitung & Emission:
   • Der DoIP-Daemon empfängt den Aufruf synchron oder asynchron über den bereitgestellten Port.
   • Gemäß ISO 13400-2 / SWS_DM_00815 assembliert der DoIP-Daemon das DoIP Vehicle Announcement / Identification Response Message-Paket (Payload: VIN, logische Adresse, EID, GID, ggf. Status) und versendet dieses via UDP-Broadcast (Port 13400) über die konfigurierten IP-Netzwerkschnittstellen.

4. Normative Relevanz & Entwickler-Hinweise

• Normative Referenzen:
  • TPS_MANI_01463: Definiert die Semantik und Metamodell-Struktur des DiagnosticDoIpTriggerVehicleAnnouncementPortMapping.
  • SWS_DM_00815: Beschreibt die funktionale Anforderung an den Diagnostic Management Daemon, bei Vorhandensein eines entsprechenden Handlers den Versand von Vehicle Announcements extern steuern zu lassen.
  • RS_MANI_00005, RS_MANI_00061: Allgemeine Anforderungen an Modellierbarkeit und Verknüpfung von Diagnose-Ports im Manifest.
• Entwickler- & Konfigurations-Hinweise:
  • Applikationsentwickler: Müssen einen Software-Component-Typ mit einem RPortPrototype deklarieren, der auf DiagnosticDoIPTriggerVehicleAnnouncementInterface typisiert ist, und die Service-Instanz im Execution Manifest dem Ziel-Prozess zuordnen.
  • Integrator / Manifest-Autor: Das Element DiagnosticDoIpTriggerVehicleAnnouncementPortMapping ist erforderlich, um die Instanzreferenz (instanceRef) auf den RPortPrototype innerhalb des jeweiligen Executables (+rPortPrototypeInExecutable) und den zugehörigen ProcessDesign-Kontext aufzulösen.
  • Stack-Verhalten bei Fehlen des Mappings: Existiert kein DiagnosticDoIpTriggerVehicleAnnouncementPortMapping, greift die standardmäßige DoIP-Stack-Strategie (automatischer Versand nach Initialisierung/Link-Up gemäß den im Diagnostic Manifest hinterlegten Default-Timern). Ist das Mapping definiert, wird der automatische Default-Trigger deaktiviert bzw. an den Handler gekoppelt.