Figure 9.111: Interfaces for Upload and Download

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Komponenten- und Schnittstellendiagramm (AUTOSAR Adaptive Platform Architekturmodell).
• Technischer Zweck: Spezifikation der Service-Schnittstellen für blockbasierte Datentransfers (ISO 14229-1 UDS Services: 0x34 RequestDownload, 0x35 RequestUpload, 0x36 TransferData, 0x37 RequestTransferExit) im Adaptive Platform Functional Cluster Diagnostic Management (DM).
• Architektur-Einordnung:
  • Das Schaubild visualisiert die invertierte Service-Architektur zwischen Plattform-Daemon (Diagnostic Management, daemon-based) und Anwendungslogik (Diagnostic Application innerhalb einer Adaptive Application).
  • Der Plattform-Daemon stellt die Port-Interfaces DownloadService und UploadService bereit (Interface-Realisierung). Die Diagnostic Application bindet diese als Client über Required Ports («aapRequiredPort», «use») an und registriert Callback-Methoden für die UDS-Transferabwicklung.

2. Komponenten, Entitäten & Schnittstellen

• Komponenten / Akteure:
  • Adaptive Application / Diagnostic Application: Applikativer Container bzw. Diagnose-Software-Komponente, die als Service-Konsument (Client) agiert und Callback-Handler für die Diagnoseabwicklung bereitstellt.
  • «aapFunctionalCluster» Diagnostic Management (daemon-based): Plattform-Dienstkomponente der Adaptive Platform, die als Service-Provider auftritt, externe UDS-Sessions terminiert und Anwendungs-Callbacks aufruft.
• Schnittstellen (Port Interfaces):
  • DownloadService («aapPortInterface»):
    • Offer() / StopOffer(): Reguläre Methoden zur Registrierung und Deregistrierung der anwendungsseitigen Callbacks beim Daemon.
    • «aapCallbackMethod» DownloadData(): Callback zur Entgegennahme übertragener Nutzdatenblöcke (UDS Service 0x36).
    • «aapCallbackMethod» RequestDownload(): Callback zur Validierung von Adresse, Datenformat und Übertragungslänge (UDS Service 0x34).
    • «aapCallbackMethod» RequestDownloadExit(): Callback zur finalen Verifikation und Beendigung des Downloads (UDS Service 0x37).
  • UploadService («aapPortInterface»):
    • Offer() / StopOffer(): Reguläre Methoden zur Lifecycle-Steuerung der anwendungsseitigen Upload-Bereitschaft am Daemon.
    • «aapCallbackMethod» RequestUpload(): Callback zur Initiierung des Auslesens von Speicherbereichen (UDS Service 0x35).
    • «aapCallbackMethod» RequestUploadExit(): Callback zum geordneten Abschluss des Uploads (UDS Service 0x37).
    • «aapCallbackMethod» UploadData(): Callback zur Bereitstellung des jeweils nächsten Datenblocks (UDS Service 0x36).
• Beziehungen & Stereotypen:
  • Diagnostic Application nutzt die Schnittstellen über «aapRequiredPort» mit «use»-Abhängigkeit.
  • Diagnostic Management realisiert die Schnittstellen (Interface-Realisierung, gestrichelte Pfeile mit geschlossener Dreiecksspitze vom Daemon zur jeweiligen Schnittstelle).

3. Dynamisches Verhalten & Sequenzablauf

1. Initialisierung & Callback-Registrierung:
   • Die Diagnostic Application ruft als Client Offer() auf ihrem «aapRequiredPort» für DownloadService bzw. UploadService auf und übergibt bzw. registriert dadurch die Implementierungen der «aapCallbackMethod»-Operationen beim Diagnostic Management-Daemon.
2. Transfer-Initialisierung:
   • Nach Eingang eines UDS-Requests 0x34 (RequestDownload) bzw. 0x35 (RequestUpload) ruft der Daemon den registrierten Callback RequestDownload() bzw. RequestUpload() der Applikation auf.
   • Die Applikation verifiziert Speicherparameter und Zugriffsrechte und liefert die Verhandlungsdaten (z. B. maximale Blocklänge) oder UDS NRCs zurück.
3. Zyklischer Datentransfer (0x36 TransferData):
   • Beim Download ruft der Daemon für jeden eingehenden Block den Callback DownloadData() an der Applikation auf.
   • Beim Upload fordert der Daemon über den Callback UploadData() den nächsten zu übertragenden Datenblock von der Applikation an.
4. Transfer-Abschluss (0x37 RequestTransferExit):
   • Der Daemon signalisiert das Transferende über den Aufruf von RequestDownloadExit() bzw. RequestUploadExit(), woraufhin die Applikation Integritätsprüfungen vornimmt.
5. Deregistrierung:
   • Durch Aufruf von StopOffer() am Required Port hebt die Applikation ihre Callback-Registrierung beim Daemon wieder auf.

4. Normative Relevanz & Entwickler-Hinweise

• Normative Relevanz: Die Modellierung in R25-11 führt einen grundlegenden Paradigmenwechsel ein: Der Daemon ist Provider der Services, während die Applikation als Consumer («aapRequiredPort») agiert. Diagnoseoperationen sind explizit als «aapCallbackMethod» typisiert.
• Architekturmuster (Callback-Pattern): Das vorherige P-Port-Muster der Applikation wird durch ein Callback-Muster ersetzt. Dadurch steuert der Daemon das Lifecycle- und Schnittstellen-Management, während die Applikation lediglich spezifische Callback-Handler implementieren und via Offer() registrieren muss.
• Entwickler-Hinweise:
  • Applikationsentwickler implementieren keine Server-Skelette für den Port mehr, sondern instanziieren Client-Proxys und registrieren Callbacks für RequestDownload/RequestUpload, DownloadData/UploadData sowie die Exit-Routinen.
  • Aufrufe von Offer() und StopOffer() erfolgen aktiv durch den Client zur Bindung bzw. Trennung der Callbacks an den Plattform-Daemon.
  • Asynchrone Ausführungen und Thread-Sicherheit der Callbacks im Kontext des Diagnostic Management Clusters müssen beachtet werden.