Figure 9.115: Interfaces for the UDS Transportlayer API (1 of 2)

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Klassendiagramm / Komponenten-Schnittstellendiagramm der AUTOSAR Adaptive Platform (AP).
• Architektur-Kontext: Spezifikation der UDS Transport Layer API innerhalb des Functional Clusters Diagnostic Management (DM) (AUTOSAR_EXP_SWArchitecture, Kapitel Diagnostic Management, Release R25-11).
• Technischer Zweck: Entkopplung des Diagnose-Kerns (DM-Daemon) von transportspezifischen Protokoll-Implementierungen (z. B. DoIP, UDS-over-CAN/FR via ISO-TP). Diagnostic Management tritt als Schnittstellen-Provider (Service-Realisierung) auf, während die austauschbare UDS Transportlayer Extension als Konsument angebunden ist und über ein standardisiertes Callback-Modell («aapCallbackMethod») in den Diagnose-Ablauf eingebunden wird.

2. Komponenten, Entitäten & Schnittstellen

Entitäten & Stereotypen

• «aapFunctionalCluster» Diagnostic Management (daemon-based):
  • Der zentrale Diagnose-Daemon der Adaptive Platform. Er realisiert die Schnittstellen UdsTransportProtocolHandler und UdsTransportProtocolMgr (Interface Realization: gestrichelte Linien mit hohler Dreiecksspitze) und fungiert als Provider der Plattform-Schnittstellen.
• UDS Transportlayer Extension (UML-Komponente):
  • Protokollspezifische Erweiterungskomponente (Plugin/Treiber), die ein konkretes Transportprotokoll kapselt. Sie konsumiert beide Schnittstellen über Abhängigkeitsbeziehungen («use»).
• «aapNativeInterface, aapPlatformExtension» UdsTransportProtocolHandler:
  • Steuerungsschnittstelle des Transport-Handlers, deren Methoden als Callbacks deklariert sind:
    • Methoden-Stereotyp: «aapCallbackMethod»
    • + GetHandlerID(): Liefert die eindeutige ID des Handlers.
    • + GetPeriodicHandler(): Referenz auf Handler für periodische UDS-Botschaften (z. B. Service 0x2A).
    • + Initialize() / + Start() / + Stop(): Lifecycle-Management des Protokoll-Stacks.
    • + NotifyReestablishment(): Aufforderung zur Wiederherstellung eines abgerissenen Kommunikationskanals.
    • + Transmit(): Anforderung zur Übertragung einer UDS-Nachricht über den Transportkanal.
• «aapNativeInterface, aapPlatformExtension» UdsTransportProtocolMgr:
  • Callback- und Event-Schnittstelle des Diagnose-Managers:
    • Methoden-Stereotyp: «aapCallbackMethod»
    • + ChannelReestablished(): Quittierung einer erfolgreichen Kanalwiederherstellung.
    • + HandleMessage(): Übergabe der vollständig assemblierten Botschaft an den DM.
    • + HandlerStopped(): Quittierung des kontrollierten Stopp-Vorgangs.
    • + IndicateMessage(): Signalisiert den Empfang einer Diagnoseanfrage (Header-Parsing / Pufferallokation).
    • + NotifyMessageFailure(): Fehlersignalisierung bei Sende-/Empfangsabbrüchen.
    • + PeriodicTransmitConfirmation(): Asynchrone Sendebestätigung für periodische Nachrichten.
    • + TransmitConfirmation(): Asynchrone Sendebestätigung.

Beziehungen & Abhängigkeiten

• Interface Realization: Diagnostic Management implementiert bzw. realisiert die beiden Plattform-Schnittstellen UdsTransportProtocolHandler und UdsTransportProtocolMgr.
• «use»-Abhängigkeiten: UDS Transportlayer Extension greift über gerichtete Abhängigkeitspfeile («use») auf beide Schnittstellen zu.

3. Dynamisches Verhalten & Sequenzablauf

Lifecycle & Initialisierung

1. Bereitstellung: Diagnostic Management startet als Daemon und realisiert die Schnittstellen UdsTransportProtocolHandler und UdsTransportProtocolMgr.
2. Lifecycle-Steuerung: Die UDS Transportlayer Extension nutzt die Schnittstellen, wobei Initialisierungs- und Kontrollroutinen (Initialize(), Start()) über die als «aapCallbackMethod» annotierten Methoden aufgerufen bzw. registriert werden.
3. Shutdown: Bei Beendigung wird Stop() aufgerufen und der kontrollierte Shutdown durch HandlerStopped() quittiert.

Nachrichtenübertragung & Empfangspfad (Rx/Tx)

1. Empfangspfad (Rx):
   • Eintreffende Transport-PDUs führen zum Aufruf von IndicateMessage() zur Pufferreservierung und Protokollprüfung.
   • Nach vollständiger Reassemblierung übergibt die Extension die Diagnosenachricht mittels HandleMessage() an den DM-Daemon.
2. Sendepfad (Tx):
   • Die Übertragung von Diagnosenachrichten wird über Transmit() initiiert.
   • Nach erfolgreichem Senden auf dem Bus bestätigt der Stack den Versand via TransmitConfirmation() bzw. PeriodicTransmitConfirmation().
   • Bei Abbrüchen oder Verbindungsverlust erfolgt die Fehlermeldung via NotifyMessageFailure(), gefolgt von Verbindungsreparaturzyklen (NotifyReestablishment(), ChannelReestablished()).

4. Normative Relevanz & Entwickler-Hinweise

• Normative Architekturumkehr (R25-11): Die Realisierungs- und Nutzungsbeziehungen zwischen dem Functional Cluster Diagnostic Management und der UDS Transportlayer Extension wurden fundamental invertiert. Diagnostic Management tritt nun formal als Realisierer beider nativer Plattform-Schnittstellen auf, während die Extension diese via «use» bindet.
• Explizite Methodendeklaration («aapCallbackMethod»): Sämtliche Methoden in UdsTransportProtocolHandler und UdsTransportProtocolMgr sind nun mit dem Stereotyp «aapCallbackMethod» versehen. Dies formalisiert das asynchrone Callout-/Callback-Modell zwischen dem Daemon und der Transporterweiterung auf Metamodellebene.
• Entwickler- & Integrationsrelevanz:
  • Plugin-Treiber und Erweiterungen für UDS-Transportprotokolle (z. B. DoIP-, CAN- oder FlexRay-Transport-Layer) müssen an die umgekehrte Rollenverteilung angepasst werden.
  • Generierte C++-Bindings und Interface-Header spiegeln die «aapCallbackMethod»-Semantik wider, was eine Anpassung von Signaturen, Registrierungsmechanismen oder Interface-Implementierungen in bestehenden AP-Stacks erforderlich macht.
  • Das Diagramm besitzt bindenden, normativen Charakter für die Architektur nativer AP-Plattform-Erweiterungen.