Figure 9.109: Interfaces required by Diagnostic Management from external components

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Komponentendiagramm / Schnittstellen-Abhängigkeitsdiagramm der AUTOSAR Adaptive Platform (AP).
• Architektur-Kontext: Spezifiziert die externe Abhängigkeit des Functional Clusters Diagnostic Management (DM) in einer daemon-basierten Implementierungsausprägung gemäß AUTOSAR_EXP_SWArchitecture (R21-11).
• Funktionaler Zweck: Modellierung der Koppelung zwischen dem Diagnose-Daemon (primär zuständig für UDS- und DoIP-Handling gemäß ISO 13400 / ISO 14229) und dem darunterliegenden Netzwerk-Subsystem zur PDU-Übertragung über IP-basierte Fahrzeug-Bussysteme (Ethernet).

2. Komponenten, Entitäten & Schnittstellen

• Komponenten & Stereotypen:
  • Diagnostic Management daemon-based [«aapFunctionalCluster»]: Zentraler Plattform-Daemon der Adaptive Platform für On-Board- und Off-Board-Diagnoseabwicklung, Fehlergedächtnisverwaltung (Event Memory) und Diagnose-Sessions.
  • TCP/IP Stack [«aapInternal»]: Interne Schnittstelle bzw. Subsystem-Abstraktion für IP-, TCP- und UDP-Kommunikation. Trägt das Stereotyp «aapInternal», da es sich nicht um eine standardisierte ara::com-Serviceschnittstelle handelt, sondern um plattforminterne Core-Funktionalität.
  • Operating System [UML-Komponente]: Zugrundeliegendes POSIX-konformes Betriebssystem der Adaptive Platform Execution Management Umgebung.
• Beziehungen & Abhängigkeiten:
  • «use» (Usage Dependency): Diagnostic Management daemon-based → TCP/IP Stack. Der Diagnose-Daemon nutzt die Transportprotokoll-Schnittstellen für den DoIP-Transportkanal (TCP für Diagnose-Payload/Steuerung, UDP für Vehicle Identification und Alive-Check).
  • Realisierung (Interface Realization): Operating System ⇢ TCP/IP Stack (gestrichelte Linie mit geschlossener, nicht ausgefüllter Dreiecksspitze). Das POSIX-kompatible Betriebssystem implementiert den TCP/IP-Stack und stellt ihn über native OS-Primitive bereit.

3. Dynamisches Verhalten & Sequenzablauf

Das Diagramm definiert eine statische Struktur. Aus der statischen Bindung resultiert zur Laufzeit folgendes Kommunikationsmuster:

1. Initialisierung & Socket-Setup: Der DM-Daemon erzeugt während der Initialisierung über die OS-Socket-Schnittstelle UDP-Sockets für DoIP-Discovery (Port 13400) und bindet einen TCP-Listener-Socket an Port 13400 (socket(), setsockopt(), bind(), listen()).
2. Vehicle Announcement / Identification: Asynchroner Versand und Empfang von DoIP-Nachrichten über UDP.
3. Verbindungsaufbau (DoIP TCP Session): Eingehende Verbindungsanfragen eines externen Diagnose-Testers werden vom OS-Stack terminiert; der DM-Daemon akzeptiert die Verbindung (accept()) und weist sie einer logischen DiagnosticConversation zu.
4. Synchrones/Asynchrones I/O-Multiplexing: Der Daemon überwacht Socket-Deskriptoren über OS-Polling-Mechanismen (z. B. epoll, poll oder select). Eingehende DoIP-Nachrichten (Routing Activation, Diagnostic Message) werden synchron aus dem OS-Socket-Buffer gelesen, geparst und intern verarbeitet.
5. Session-Terminierung & Fehlerbehandlung: Socket-Schließungen oder TCP-Timeouts führen zum deterministischen Abbau des aktiven Diagnosekanals und Rücksetzen des DoIP-Zustandsautomaten.

4. Normative Relevanz & Entwickler-Hinweise

• OS-Anforderungen & Profile: Das Ziel-Betriebssystem muss zwingend Netzwerk-Socket-APIs bereitstellen (POSIX.1-2008 bzw. PSE52/PSE53 Socket API; sys/socket.h, netinet/in.h, arpa/inet.h). Ein reines Minimalprofil ohne Netzwerk-Stack (z. B. Minimal-PSE51) reicht für DoIP-fähige Instanzen des DM nicht aus.
• Keine ara::com-Kopplung für Transport: Die Anbindung an den TCP/IP-Stack erfolgt explizit nicht via Service-Oriented Communication (ara::com / SOME/IP), sondern direkt über BSD/POSIX-Sockets des OS, da DoIP auf standardisierten Raw-TCP/UDP-Ports operiert.
• Sicherheits- & Rechteverwaltung (Security / Access Control): Der DM-Daemon-Prozess benötigt im Manifest (Execution Management Execution Manifest) und in den OS-Sicherheitsrichtlinien (z. B. SELinux, AppArmor, POSIX Capabilities wie CAP_NET_BIND_SERVICE) ausreichende Privilegien, um Low-Ports (Standard-DoIP-Port 13400) zu binden.
• Puffer-Dimensionierung: Bei Software-Update-Szenarien via DoIP (UDS Service 0x34 / 0x36 / 0x37) sind die OS-Socket-Buffer (SO_RCVBUF, SO_SNDBUF) sowie IP-Fragmentierungspuffer architektonisch so auszulegen, dass PDU-Drops bei hohen Übertragungsraten vermieden werden.