Figure 7.1: Component view on Diagnostic Management

1. Diagrammtyp & Architektur-Kontext

Das Diagramm ist ein Architektur- und Komponentenüberblick der AUTOSAR Adaptive Platform für das funktionale Cluster Diagnostic Management (DM: DiagnosticManagement). Es illustriert die funktionale Schichtung zwischen Application Layer und UDS Transport Layer sowie die Zuordnung von Diagnoseservern zu konkreten Applikationen innerhalb modularer Software Cluster über standardisierte Diagnoseadressen.

2. Komponenten, Entitäten & Schnittstellen

Das Diagramm definiert folgende Komponenten, Entitäten und Schnittstellen:

• Software Cluster und Applikationen:
  • Software Cluster A umfasst die Entität Application A.
  • Software Cluster B umfasst zwei getrennte Entitäten: Application B.1 und Application B.2.
• Diagnostic Management (DM: DiagnosticManagement):
  • Beinhaltet im Application Layer den Diagnostic Server A (zugeordnet zu Cluster A via diagnostic Address_A) und den Diagnostic Server B (zugeordnet zu Cluster B via diagnostic Address_B). Die Clustergrenzen umschließen die jeweiligen Diagnoseserver visuell.
  • Beide Diagnoseserver sind über bidirektionale Schnittstellen mit den Applikationen ihres Clusters verbunden (Diagnostic Server A mit Application A; Diagnostic Server B separat mit Application B.1 und Application B.2).
  • Transport Protocol Manager: Zentrale Komponente unterhalb der Server, angebunden über dedizierte Kanäle je Diagnoseadresse.
• Schnittstellen und Transportschicht:
  • UDS Transport Protocol API: Horizontale Schnittstelle zwischen Transport Protocol Manager und den UDS-Transport-Handlern.
  • DoIP_TransportProtocolHandler: Liegt innerhalb von DM: DiagnosticManagement, ist bidirektional an die UDS Transport Protocol API gekoppelt und kommuniziert extern über Ethernet.
  • Custom_TransportProtocolHandler: Liegt außerhalb des Hauptblocks von DM: DiagnosticManagement, bindet an ein separates physikalisches Medium an und ist alternativ über eine gestrichelte Pfadverbindung (alternatively) an die UDS Transport Protocol API angebunden.

3. Dynamisches Verhalten & Sequenzablauf

Der Ablauf der Diagnosekommunikation gestaltet sich wie folgt:

1. Eingehende Diagnose-Frames treffen primär über Ethernet beim DoIP_TransportProtocolHandler ein (bzw. alternativ über einen externen Bus am Custom_TransportProtocolHandler).
2. Der Handler dekodiert die Transportschichtdaten und übergibt die Diagnosenachricht über die UDS Transport Protocol API an den Transport Protocol Manager.
3. Anhand der Zieladresse (diagnostic Address_A bzw. diagnostic Address_B) routet der Transport Protocol Manager die Anforderung selektiv an den adressierten Diagnostic Server A oder Diagnostic Server B.
4. Der adressierte Diagnoseserver leitet den Dienstaufruf an die Zielapplikation (Application A in Cluster A bzw. Application B.1 / Application B.2 in Cluster B) weiter.
5. Antworttelegramme werden von den Applikationen an den zuständigen Diagnoseserver übergeben, vom Transport Protocol Manager an den aktiven Transport-Handler vermittelt und über das entsprechende Netzwerk versendet.

4. Normative Relevanz & Entwickler-Hinweise

• Pro Software Cluster ist genau eine logische Diagnoseadresse definiert (diagnostic Address_A, diagnostic Address_B), über die der zugehörige Diagnoseserver adressiert wird.
• Ein Diagnoseserver kann mehrere Applikationen innerhalb desselben Software Clusters bedienen (Application B.1, Application B.2), wohingegen Software Cluster A eine 1:1-Zuordnung zeigt.
• Die UDS-Transportschicht unterstützt DoIP als integrierten Standard-Handler über Ethernet sowie optional/alternativ anbindbare Custom-Handler.
• Die strikte Adresstrennung entkoppelt Software Cluster auf Diagnoseebene und ermöglicht unabhängige Diagnosekontexte auf einer Adaptive-Plattform-Instanz.