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 zeigt die parallele Koexistenz von zwei Diagnosesträngen: dem klassischen UDS-basierten Diagnosepfad und dem serviceorientierten Diagnosepfad (SOVD - Service-Oriented Vehicle Diagnostics), aufgeteilt in Application Layer und Transport Layer.

2. Komponenten, Entitäten & Schnittstellen

Das Diagramm gliedert sich in folgende Entitäten und Schnittstellen:

• Software Cluster & Applikationen:
  • Software Cluster A mit Application A.
  • Software Cluster B mit Application B.1 und Application B.2.
• Diagnoseserver (Application Layer):
  • Diagnostic Server A und Diagnostic Server B, eingebettet in die Grenzen der jeweiligen Software Cluster.
  • Bidirektionale Anbindung an die zugehörigen Applikationen.
• Diagnose-Routing- und Management-Ebene:
  • Transport Protocol Manager: Zuständig für UDS-Routing, adressiert die Server über diagnostic Address_A und diagnostic Address_B.
  • SOVD API Handler: Zuständig für SOVD-Routing, adressiert die Server parallel über subcomponent_A und subcomponent_B.
• Transport- und Schnittstellenebene:
  • UDS Transport Protocol API: Horizontale Schnittstelle unterhalb des Transport Protocol Manager, linksbündig auf den UDS-Pfad begrenzt.
  • DoIP_TransportProtocolHandler: Bindet über die UDS Transport Protocol API an und ist mit Ethernet verbunden.
  • Custom_TransportProtocolHandler: Außerhalb des Kernrahmens angeordnet, über gestrichelte Linie (alternatively) an die UDS Transport Protocol API gekoppelt, mit eigener externer Busanbindung.
  • HTTP_Handler: Direkt unterhalb des SOVD API Handler angeordnet, bindet diesen bidirektional an und nutzt als externes Übertragungsmedium Ethernet.

3. Dynamisches Verhalten & Sequenzablauf

Das Ablaufverhalten unterstützt zwei parallele Diagnosepfade:

1. UDS-Pfad:
   • Diagnosepakete gelangen über Ethernet an den DoIP_TransportProtocolHandler (oder alternativ über einen Custom-Bus an den Custom_TransportProtocolHandler).
   • Übergabe über die UDS Transport Protocol API an den Transport Protocol Manager.
   • Adressbasiertes Weiterleiten über diagnostic Address_A bzw. diagnostic Address_B an den jeweiligen Diagnoseserver und Weitergabe an die Applikationen (Application A, Application B.1, Application B.2).
2. SOVD-Pfad:
   • REST/HTTP-basierte Diagnoseanfragen treffen über Ethernet beim HTTP_Handler ein.
   • Der HTTP_Handler kommuniziert direkt mit dem SOVD API Handler.
   • Der SOVD API Handler spricht über subkomponentenbasierte Adressierung (subcomponent_A bzw. subcomponent_B) gezielt Diagnostic Server A oder Diagnostic Server B an.
3. Der Rückkanal erfolgt jeweils symmetrisch über denselben Pfad zum externen Tester bzw. Diagnose-Client.

4. Normative Relevanz & Entwickler-Hinweise

• Das Diagnostic Management ist dual ausgelegt: Es unterstützt zeitgleich klassische UDS-Diagnose und moderne serviceorientierte Fahrzeugdiagnose (SOVD).
• Ethernet dient als gemeinsames physikalisches Übertragungsmedium sowohl für UDS via DoIP (DoIP_TransportProtocolHandler) als auch für SOVD via HTTP (HTTP_Handler).
• Auf Serverseite sind die Diagnoseserver hybrid ansprechbar: klassisch über UDS-Diagnoseadressen (diagnostic Address_X) und serviceorientiert über Subkomponentenbezeichner (subcomponent_X).
• Die UDS Transport Protocol API ist spezifisch für UDS-Transportprotokolle; der SOVD-Strang bindet den HTTP_Handler direkt an den SOVD API Handler an.