Figure 9.98: 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 I/O-Treibern (Aktivierungsleitung) und flottenweiten Identifikationsmechanismen (Group Identification / GID).

2. Komponenten, Entitäten & Schnittstellen

Komponenten & Stereotypen

• DoIP Extension (Component): Server- bzw. Provider-Komponente. Implementiert fahrzeugspezifische I/O- und Hardwareabstraktionen für DoIP. Realisiert beide Schnittstellen (dargestellt über UML-Interface-Realization, gestrichelte Linie mit hohler Dreiecksspitze).
• «aapFunctionalCluster» Diagnostic Management (daemon-based): Client- bzw. Consumer-Komponente der AUTOSAR Adaptive Platform. Konsumiert beide Schnittstellen über erforderliche Ports (gekennzeichnet via «aapRequiredPort» und «use»-Abhängigkeitspfeile).

Schnittstellen («aapPortInterface, aapPlatformExtension»)

1. DoIPGroupIdentification:
   • Schnittstelle zur Bereitstellung der Gruppen-Identifikation (GID) nach ISO 13400.
   • Methoden:
     • GetGidStatus(): Liefert den aktuellen Synchronisations- und Validitätsstatus der GID (z. B. synchronisiert / Default-GID).
     • Offer() / StopOffer(): Service-Lifecycle-Management zur Freigabe bzw. zum Entzug der Schnittstellenverfügbarkeit.
2. DoIPActivationLine:
   • Schnittstelle zur Erfassung und Verwaltung der physikalischen DoIP-Aktivierungsleitung (DoIP Activation Line / Pin 8 nach ISO 13400-2).
   • Methoden:
     • GetActivationLineState(): Synchrone Abfrage des aktuellen logischen Leitungspegels (aktiv / inaktiv).
     • GetNetworkInterfaceId(): Abfrage des zugeordneten IP-/Ethernet-Netzwerk-Interfaces (Binding zwischen Aktivierungsleitung und Netzwerkschnittstelle).
     • Offer() / StopOffer(): Service-Lifecycle-Management.
     • UpdateActivationLineState(): Benachrichtigung bzw. Übergabe eines veränderten Aktivierungsleitungszustands an den Stack.

3. Dynamisches Verhalten & Sequenzablauf

1. Service-Initialisierung:
   • Die DoIP Extension startet, initialisiert hardwarenahe GPIO-/Netzwerktreiber und publiziert ihre Ports via Offer().
   • Der Diagnostic Management-Daemon bindet die Services über seine «aapRequiredPort»-Instanzen.
2. Interface-Zuordnung & Baseline-Erfassung:
   • Der DM fragt initial über GetNetworkInterfaceId() die Hardwarebindung ab und liest mit GetActivationLineState() den Startzustand der Leitung ein.
   • Zeitgleich wird über GetGidStatus() der GID-Zustand für anstehende Vehicle Announcement Messages (VAM) abgerufen.
3. Ereignisgesteuerte Zustandsänderung (Aktivierungsleitung):
   • Ein Pegelwechsel an der physikalischen Aktivierungsleitung (z. B. Einstecken des externen Diagnose-Testers) triggert in der DoIP Extension einen Interrupt/Treiber-Event.
   • Die Extension meldet den neuen Zustand über UpdateActivationLineState() an den DM-Daemon.
   • Der DM aktiviert daraufhin die Socket-Listener (UDP Discovery / TCP Diagnostic Message Handler) auf dem ermittelten Interface.
4. De-Initialisierung:
   • Bei Shutdown oder Ausfall ruft die Extension StopOffer() auf; der DM schließt offene DoIP-Verbindungen kontrolliert.

4. Normative Relevanz & Entwickler-Hinweise

• Klassifikation als «aapPlatformExtension»:
  • Keine reine standardisierte Applikationsschnittstelle (ara::diag), sondern eine plattforminterne Integrationsschnittstelle. Die DoIP Extension ist typischerweise Tier-1-/Stack-spezifisch als Platform-Applikation oder Teil des Adaptive Platform Foundation Layer auszuführen.
• Hardware-Entprellung (Debouncing):
  • Gemäß ISO 13400-2 müssen Übergänge auf der DoIP-Aktivierungsleitung zeitlich entprellt werden (t_activation). Dieses Debouncing muss vollständig innerhalb der DoIP Extension gekapselt sein, bevor UpdateActivationLineState() aufgerufen wird.
• Multi-Interface-Fähigkeit:
  • Durch GetNetworkInterfaceId() unterstützt die Architektur Multi-Homed-ECUs mit mehreren physikalischen Diagnose-Ethernet-Ports; für jede Aktivierungsleitung ist eine separate Instanz bzw. Zuordnung erforderlich.
• IPC- / ara::com-Overhead:
  • Da der DM als Daemon läuft, erfolgt die Kommunikation über IPC (Inter-Process Communication). Zeitkritische Methodenaufrufe müssen nicht-blockierend implementiert werden, um den DoIP-Protokoll-Stack nicht zu blockieren.