Figure 9.114: Interfaces for File Transfer

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Strukturdiagramm / Komponenten- und Schnittstellendiagramm gemäß AUTOSAR Adaptive Platform Metamodell (AUTOSAR_AP_EXP_SWArchitecture).
• Funktionale Einordnung: Spezifikation der Interaktionsschnittstelle zwischen einer Adaptive Application und dem Functional Cluster Diagnostic Management (DM, Ausprägung: daemon-based). Es definiert den Service-Vertrag zur Abwicklung des UDS-Dienstes 0x38 (RequestFileTransfer) gemäß ISO 14229-1 im AUTOSAR Adaptive Stack.
• Architektonischer Zweck: Trennung von UDS-Protokollhandling (Sitzungsverwaltung, SecurityAccess, Transportprotokoll/DoIP im DM-Daemon) und eigentlichem Dateisystemzugriff (Persistenz, Lese-/Schreibrechte, Verzeichnisverwaltung in der zuständigen Adaptive Application).

2. Komponenten, Entitäten & Schnittstellen

• Komponenten / Akteure:
  • Adaptive Application: Anwendungs-SWC im User Space, die als Datei-Eigentümer (File-Handler) agiert und das Dateisystem anbindet.
  • «aapFunctionalCluster» Diagnostic Management (daemon-based): Zentraler Plattform-Daemon der Adaptive Platform für Diagnosekommunikation, der die Middleware-Infrastruktur für den Dateitransfer bereitstellt.
• Port-Interface:
  • «aapPortInterface, aapPlatformExtension» FileTransferService: Plattform-Interface zur standardisierten Dateiübertragung.
    • Lebenszyklus-Methoden:
      • + Offer(): Registriert die Service-Bereitschaft der Applikation beim DM-Daemon.
      • + StopOffer(): Meldet den Handler beim DM-Daemon ab (z. B. vor Zustandswechseln oder Termination).
    • Callback-Methoden («aapCallbackMethod»):
      • + RequestReadFile(): Initiiert das Auslesen einer Datei (Upload vom Steuergerät zum Tester via UDS 0x38 Subfunction ReadFile).
      • + RequestWriteFile(): Initiiert das Schreiben einer Datei (Download vom Tester zum Steuergerät via UDS 0x38 Subfunction AddFile / ReplaceFile).
      • + RequestResumeWriteFile(): Setzt einen zuvor abgebrochenen Schreibvorgang fort (Subfunction ResumeFile).
      • + DeleteFile(): Löscht eine Datei auf dem Dateisystem der AA (Subfunction DeleteFile).
      • + RequestReadDirectory(): Liest Verzeichnisinhalte bzw. Dateiattribute aus (Subfunction ReadDir).
• Beziehungen & Stereotypen:
  • Adaptive Application –«use»,\ «aapRequiredPort»→ FileTransferService: Die Applikation konsumiert das Interface über einen Required Port (RPortPrototype), um Callbacks für Dateitransfer-Operationen bereitzustellen und ihren Lebenszyklus zu steuern.
  • Diagnostic Management (daemon-based) ⇢ FileTransferService (geschlossene, leere Dreiecksspitze): UML-Schnittstellenrealisierung (Realization). Der DM-Daemon implementiert das Dispatching, die Pufferverwaltung und das Protokoll-Mapping gegen dieses Interface.

3. Dynamisches Verhalten & Sequenzablauf

1. Service-Registrierung:
   • Die Adaptive Application instanziiert den Service-Handler und ruft Offer() auf. Der DM-Daemon markiert die entsprechenden Dateipfade/Instanzen im Diagnose-Katalog als verfügbar.
2. UDS-Request-Verarbeitung (Tester → DM-Daemon):
   • Ein externer Tester sendet einen Diagnoserequest UDS Service 0x38 (RequestFileTransfer) via DoIP/SOME/IP an den DM-Daemon.
   • Der DM-Daemon validiert Session-Status, Security Access (Seed & Key) und Diagnoserechte.
3. Delegation an die Applikation (DM-Daemon → Callback):
   • Der Daemon dispatcht den Request über IPC an die passende Callback-Methode der AA (RequestReadFile(), RequestWriteFile(), etc.).
   • Die AA prüft lokale Ressourcen (Speicherplatz, POSIX-Dateirechte), öffnet den Dateideskriptor und gibt Status/Blockgrößen-Parameter zurück.
4. Datenübertragung & Abschluss:
   • Der sequentielle Datenblocktransfer (UDS 0x36 TransferData, 0x37 RequestTransferExit) wird über den DM-Daemon koordiniert und byteweise an die Datei übergeben bzw. aus ihr gelesen.
   • Tritt ein I/O-Fehler auf (z. B. Speicher voll, ungültiger Pfad), meldet die Callback-Methode ein ara::core::Result<..., ara::diag::DiagErrorDomain> zurück; der Daemon mappt dies auf standardisierte UDS Negative Response Codes (z. B. NRC 0x22 ConditionsNotCorrect, NRC 0x31 RequestOutOfRange oder NRC 0x72 GeneralProgrammingFailure).

4. Normative Relevanz & Entwickler-Hinweise

• API-Vertrag (ara::diag):
  • Callback-Methoden müssen nicht-blockierend bzw. asynchron ausgelegt sein (Rückgabetyp typischerweise ara::core::Future<...>), da synchrone POSIX-Dateisystemoperationen den Event-Loop des Diagnose-IPC blockieren würden.
  • Thread-Sicherheit: Callbacks können aus dem Kontext des Worker-Thread-Pools der Middleware aufgerufen werden.
• Manifest-Konfiguration (ARXML):
  • Deklaration eines DiagnosticPortInterface mit Zuordnung zu den entsprechenden UDS 0x38-Subfunktionen in den DiagnosticContribution-Modellen.
  • Mapping des RPortPrototype der Application auf den konkreten Service-Provider des Daemons über das Software-Cluster- bzw. Execution-Manifest.
• Security & Robustheit:
  • Pfad-Sanitization: Die Applikation ist selbst dafür verantwortlich, Path-Traversal-Angriffe (z. B. ../-Sequenzen) abzufangen, sofern der DM-Daemon relative Pfade ungefiltert weiterleitet.
  • Atomizität: Bei RequestWriteFile() und RequestResumeWriteFile() müssen Schreiboperationen crash-sicher implementiert werden (z. B. Schreiben in temporäre Dateien mit atomarem Rename nach TransferExit), um Dateikorruption bei Spannungsabfall zu verhindern.