Figure 9.103: 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 R22-11).
• Technischer Zweck: Entkopplung des Diagnose-Kerns (DM-Daemon) von transportspezifischen Protokoll-Implementierungen (z. B. DoIP, UDS-over-CAN/FR via ISO-TP). Die Schnittstellen definieren den bidirektionalen Vertrag für austauschbare Transport-Plugins (UDS Transportlayer Extension).

2. Komponenten, Entitäten & Schnittstellen

Entitäten & Stereotypen

• «aapFunctionalCluster» Diagnostic Management (daemon-based):
  • Der zentrale Diagnose-Daemon der Adaptive Platform, zuständig für UDS-Session-Handling, Service-Dispatcher und Routing.
• UDS Transportlayer Extension (UML-Komponente):
  • Protokollspezifische Erweiterungskomponente (Plugin/Treiber), die ein konkretes Transportprotokoll kapselt.
• «aapNativeInterface, aapPlatformExtension» UdsTransportProtocolHandler:
  • Steuerungsschnittstelle des Transport-Handlers, aufgerufen durch den DM-Daemon:
    • 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, aufgerufen durch den Transport-Handler:
    • IndicateMessage(): Signalisiert den Empfang einer Diagnoseanfrage (Header-Parsing / Pufferallokation).
    • HandleMessage(): Übergabe der vollständig assemblierten Botschaft an den DM.
    • TransmitConfirmation() / PeriodicTransmitConfirmation(): Asynchrone Sendebestätigung.
    • NotifyMessageFailure(): Fehlersignalisierung bei Sende-/Empfangsabbrüchen.
    • ChannelReestablished(): Quittierung einer erfolgreichen Kanalwiederherstellung.
    • HandlerStopped(): Quittierung des kontrollierten Stopp-Vorgangs.

Beziehungen & Abhängigkeiten

• «use»-Abhängigkeiten: Diagnostic Management greift aktiv über «use» auf beide Schnittstellen zu:
  • Steuernd auf UdsTransportProtocolHandler (Downlink).
  • Empfangend/verwaltend auf UdsTransportProtocolMgr (Uplink/Callback-Kontext).
• Interface Realization: UDS Transportlayer Extension implementiert bzw. bindet die beiden nativen Plattform-Schnittstellen (UdsTransportProtocolHandler und UdsTransportProtocolMgr).

3. Dynamisches Verhalten & Sequenzablauf

Lifecycle & Initialisierung

1. Start: DM ruft Initialize() und anschließend Start() auf dem UdsTransportProtocolHandler auf.
2. Stop: Bei Shutdown oder Reinitialisierung triggert der DM Stop(); der Handler schließt offene Verbindungen und bestätigt den Zustand asynchron via HandlerStopped().

Empfangspfad (Rx)

1. Puffer-Allokation: Eingehende PDU am Socket/Bus triggert UdsTransportProtocolMgr::IndicateMessage(). Der DM prüft Session-Status, Adressierung und reserviert Message-Puffer.
2. Verarbeitung: Nach vollständigem Reassembly übergibt der Handler die Nutzlast via HandleMessage().

Sendepfad (Tx)

1. Request: DM initiiert die Übertragung einer UDS-Response über UdsTransportProtocolHandler::Transmit().
2. Confirmation: Nach physischer Leitungsübertragung meldet der Handler den Erfolg via TransmitConfirmation() (bzw. PeriodicTransmitConfirmation()).
3. Abbruch: Tritt ein Socket-/Bus-Fehler auf, wird NotifyMessageFailure() aufgerufen; der DM bricht den Diagnose-Zyklus ab und setzt Timeouts zurück.

Kanal-Wiederherstellung (Reestablishment)

• Bei Verbindungsabriss (z. B. TCP-Reset im DoIP-Stack) fordert der DM via NotifyReestablishment() einen Neuaufbau an. Nach erfolgreichem Handshake quittiert der Handler über ChannelReestablished().

4. Normative Relevanz & Entwickler-Hinweise

• API-Klassifikation (aapPlatformExtension): Keine standardisierte Anwendungs-API für Adaptive Applications (ara::diag), sondern eine plattforminterne C++-Schnittstelle zur Stack-Erweiterung. Zielgruppe sind Platform- und Stack-Integratoren.
• Speicher- und Lebensdauermanagement:
  • Transmit() arbeitet streng asynchron: Der vom DM übergebene Puffer darf vom Transport-Plugin erst nach Auslösen von TransmitConfirmation() oder NotifyMessageFailure() freigegeben/recycelt werden.
  • Zero-Copy-Strategien erfordern strikte Einhaltung der Allokationsphase zwischen IndicateMessage() und HandleMessage().
• Threading- & Reentrancy-Modell:
  • Methoden des UdsTransportProtocolMgr werden typischerweise aus dem Kontext von Worker-Threads oder I/O-Event-Loops (z. B. epoll bei DoIP) aufgerufen. Implementierungen müssen thread-safe gegen den DM-Kern synchronisiert sein.
• Fehlerbehandlung: Abweichend von Classic AUTOSAR (keine Det/Dem-Kopplung) erfolgt das Reporting typischerweise über C++-Exceptions bzw. standardisierte ara::core::Result / ara::core::ErrorCode-Mechanismen.