Figure 9.117: Interfaces for the DoIP API (1 of 2)

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Komponenten- und Schnittstellendiagramm (AUTOSAR Adaptive Platform Metamodell).
• Technischer Zweck: Spezifikation der Interaktionsschnittstellen zwischen dem AUTOSAR Adaptive Functional Cluster Diagnostic Management (DM, daemon-basiert) und der plattform-/hardwarespezifischen Komponente DoIP Extension.
• Systemkontext: Entkopplung des standardisierten DoIP-Protokoll-Stacks (ISO 13400) im DM-Daemon von hardware- und fahrzeugspezifischen Treibern und Identifikationsmechanismen. Diagnostic Management tritt als Schnittstellen-Provider (Service-Realisierung) auf, während die DoIP Extension als Konsument («aapRequiredPort») angebunden ist und anwendungsspezifische Callbacks für Gruppenidentifikation (GID), Entitätsidentifikation (EID) und Aktivierungsleitungs-Management bereitstellt.

2. Komponenten, Entitäten & Schnittstellen

Komponenten & Stereotypen

• DoIP Extension (Component): Client- bzw. Consumer-Komponente für plattformspezifische DoIP-Erweiterungen. Verwendet die Schnittstellen über erforderliche Ports («aapRequiredPort», «use») und implementiert die plattformspezifischen Callback-Methoden.
• «aapFunctionalCluster» Diagnostic Management (daemon-based): Server- bzw. Provider-Komponente der AUTOSAR Adaptive Platform. Realisiert die drei DoIP-Schnittstellen (UML-Interface-Realization, gestrichelte Linie mit geschlossener hohler Dreiecksspitze) und steuert den DoIP-Kommunikationsablauf nach ISO 13400.

Schnittstellen («aapPortInterface, aapPlatformExtension»)

1. DoIPGroupIdentification:
   • Bereitstellung der Gruppen-Identifikation (GID) nach ISO 13400.
   • Lifecycle-Methoden: + Offer(), + StopOffer().
   • Callback-Methode:
     • «aapCallbackMethod» + GetGidStatus(): Liefert den aktuellen Synchronisations- und Validitätsstatus der GID an den DM-Daemon.
2. DoIPEntityIdentification:
   • Bereitstellung der DoIP-Entitäts-Identifikation (EID / Hardware-Identifikator) nach ISO 13400.
   • Lifecycle-Methoden: + Offer(), + StopOffer().
   • Callback-Methode:
     • «aapCallbackMethod» + GetEntityId(): Liefert die eindeutige EID für Vehicle Announcement und Identification Messages.
3. DoIPActivationLine:
   • Erfassung und Verwaltung der physikalischen DoIP-Aktivierungsleitung (ISO 13400-2, Pin 8).
   • Lifecycle-Methoden: + Offer(), + StopOffer().
   • Callback-Methoden («aapCallbackMethod»):
     • + GetActivationLineState(): Synchrone Abfrage des aktuellen logischen Leitungspegels (aktiv / inaktiv).
     • + GetNetworkInterfaceId(): Abfrage des zugeordneten IP-/Ethernet-Netzwerk-Interfaces.
     • + UpdateActivationLineState(): Übergabe asynchroner Pegelwechsel an den DM-Daemon.

3. Dynamisches Verhalten & Sequenzablauf

1. Service-Bereitstellung & Lifecycle:
   • Der Diagnostic Management-Daemon startet und realisiert die Schnittstellen DoIPGroupIdentification, DoIPEntityIdentification und DoIPActivationLine.
   • Die DoIP Extension bindet die Schnittstellen über «aapRequiredPort» ein und steuert deren Verfügbarkeit über Offer() bzw. StopOffer().
2. Parameter- & Identifikationsabfrage via Callbacks:
   • Zur Vorbereitung von Vehicle Announcement Messages (VAM) oder bei Diagnosestart fragt der DM-Daemon über die registrierten Callbacks GetGidStatus() den Gruppenstatus und über GetEntityId() die Entitäts-ID aus der DoIP Extension ab.
   • Über GetNetworkInterfaceId() ermittelt der DM das zugehörige Netzwerk-Interface und erfasst via GetActivationLineState() den aktuellen Zustand der Aktivierungsleitung.
3. Ereignisgesteuerte Aktivierungsleitungs-Aktualisierung:
   • Eine Pegeländerung an der physikalischen Aktivierungsleitung (z. B. Einstecken des externen Testers) wird von der DoIP Extension erfasst.
   • Die Extension meldet die Zustandsänderung über den Callback UpdateActivationLineState() an den DM-Daemon, welcher daraufhin die entsprechenden DoIP-Socket-Listener aktiviert oder deaktiviert.
4. De-Initialisierung:
   • Beendigung der Schnittstellennutzung über StopOffer(), Freigabe der Callback-Ressourcen und Beenden der DoIP-Verbindungen.

4. Normative Relevanz & Entwickler-Hinweise

• Architektur- & Metamodellumkehr (R25-11): Die Umkehrung der Realisierungs- und Nutzungsbeziehung kehrt die Client-Server-Rollen um: Diagnostic Management stellt nun das API-Gerüst bereit, während fahrzeugspezifische Erweiterungen über ein Callback-Modell («aapCallbackMethod») Daten zuliefern.
• Callback-Muster («aapCallbackMethod»): Die explizite Stereotypisierung fordert von Integratoren und Entwicklern der DoIP Extension die Bereitstellung synchroner bzw. asynchroner Rückruffunktionen, die vom DM-Daemon bei Bedarf aufgerufen werden.
• Erweiterung um ISO 13400 Entity Identification: Durch DoIPEntityIdentification (GetEntityId()) wird die EID-Erfassung formalisiert, was die Konformität zu standardisierten DoIP-Fahrzeugidentifikations- und Ankündigungssequenzen sicherstellt.
• Kompatibilität: Es liegt ein gravierender, nicht abwärtskompatibler API- und Modellierungsbruch gegenüber Release R24-11 vor, der Anpassungen im AUTOSAR-Modell (Port-Konfigurationen, Executable Manifests) sowie der C++-Implementierung der Extension erfordert.