DEENESPTFRRUARHIKOZHNL
AUTOSAR_SWS_Diagnostics FIG-75326d793f5349d9 932 × 531 px 2 Release(s)

Figure 7.1: Component view on Diagnostic Management

SHA-256 Inhalts-Fingerabdruck: 75326d793f5349d9185b9e694d4a935295964bae21559cb6d53d4ac4de5d6f9e

Im Versions-Explorer öffnen

Kanonischer Bildausschnitt (144 DPI WebP, gerendert aus Original-Vektorgrafik) · nicht öffentlich, nur mit Anmeldung und Freigabe
✦ KI-generierte Bildanalyse & technische Beschreibung Modell: gemini-3.8-flash (via agy) · Rezept figure-series@1 · erstellt am 2026-10-08

1. Diagrammtyp & Architektur-Kontext

Das Diagramm ist ein Architektur- und Komponentenüberblick der AUTOSAR Adaptive Platform für das funktionale Cluster Diagnostic Management (DM). Es stellt die statische Schichten- und Modulstruktur des Diagnose-Stacks dar und verortet die Komponenten in zwei Hauptschichten: dem Application Layer und dem UDS Transport Layer. Gezeigt wird die Trennung zwischen anwendungsbezogenen Diagnose-Instanzen in separaten Software Clustern und den darunterliegenden Transportprotokoll-Mechanismen innerhalb des Diagnostic Managements.

2. Komponenten, Entitäten & Schnittstellen

Das Diagramm gliedert sich in externe Entitäten und interne Funktionseinheiten des Diagnostic Managements:

  • Externe Einheiten: Software Cluster A und Software Cluster B als getrennte logische Softwareeinheiten oberhalb des Diagnostic Managements.
  • Application Layer innerhalb Diagnostic Management: Enthält Diagnostic Server A und Diagnostic Server B, die jeweils einem der Software Cluster zugeordnet sind und über bidirektionale Pfeile mit ihnen interagieren. Darunter liegt der gemeinsame Transport Protocol Manager.
  • Schnittstelle: UDS Transport Protocol API als horizontale Schichtenschnittstelle zwischen dem Transport Protocol Manager und der Transportschicht.
  • UDS Transport Layer innerhalb Diagnostic Management: Beherbergt die Protokoll-Handler DoIP_TransportProtocolHandler und Custom_TransportProtocolHandler. Beide sind über die UDS Transport Protocol API angebunden und besitzen bidirektionale Schnittstellen zu ihren jeweiligen physikalischen Bus-/Netzwerkanbindungen (dargestellt als dicke horizontale Buslinien).

3. Dynamisches Verhalten & Sequenzablauf

Der Signal- und Datenfluss verläuft bidirektional über die Schichten:

  1. Diagnoseanfragen treffen über die physikalischen Netzwerkverbindungen bei einem der Transport-Handler (DoIP_TransportProtocolHandler oder Custom_TransportProtocolHandler) ein.
  2. Der jeweilige Handler übergibt die UDS-Nachrichten über die standardisierte UDS Transport Protocol API an den zentralen Transport Protocol Manager.
  3. Der Transport Protocol Manager routet die Diagnosebotschaften an den zuständigen Diagnoseserver (Diagnostic Server A oder Diagnostic Server B).
  4. Der Diagnoseserver leitet Diagnosedienste und -anfragen an die Applikationen des jeweiligen Software Cluster A bzw. Software Cluster B weiter.
  5. Diagnoseantworten nehmen den inversen Weg vom jeweiligen Software Cluster über Diagnoseserver, Transport Protocol Manager und Transport-Handler zurück auf das externe Kommunikationsnetz.

4. Normative Relevanz & Entwickler-Hinweise

  • Das Diagnostic Management unterstützt Multiserver-Topologien: Pro Software Cluster kann eine eigenständige Diagnoseserver-Instanz existieren.
  • Der Transport Protocol Manager fungiert als zentrale UDS-Routing- und Multiplexing-Instanz zwischen mehreren Transport-Handlern und mehreren Servern.
  • Entwickler von Transport-Handlern müssen sich an die UDS Transport Protocol API halten, um herstellerspezifische Protokolle (Custom_TransportProtocolHandler) oder Standardprotokolle (DoIP_TransportProtocolHandler) austauschbar einzubinden.
  • Die Diagnosekommunikation ist strikt auf UDS-basierte Transportprotokolle und Dienste ausgelegt.

Versionsvergleich KI-generiert · gemini-3.8-flash (via agy)

R18-10_R4.4.0_R1.5.0 → R19-03 normative Änderung Nachfolger: FIG-b34043968ebacaa2
  • Software Cluster A: Konkretisierung durch die Applikation Application A mit bidirektionaler Schnittstelle zu Diagnostic Server A.
  • Software Cluster B: Konkretisierung durch zwei Applikationen (Application B.1, Application B.2) mit jeweils eigener bidirektionaler Schnittstelle zu Diagnostic Server B.
  • Diagnostic Server A und Diagnostic Server B: Kennzeichnung der logischen Zuordnung zum jeweiligen Software Cluster mittels diagnostic Address_A bzw. diagnostic Address_B sowie Umrandung der Server durch die Clustergrenzen.
  • Diagnostic Management: Beschriftung von Diagnostic Management am oberen Rahmen zu vertikaler Randbeschriftung DM: DiagnosticManagement geändert.
  • Custom_TransportProtocolHandler: Aus dem Rahmen von DM: DiagnosticManagement nach außen verlagert; Anbindung an die UDS Transport Protocol API nun als gestrichelte Pfeillinie mit der Beschriftung alternatively dargestellt.
  • DoIP_TransportProtocolHandler: Physikalische Netzanbindung an Ethernet explizit als Ethernet beschriftet.
  • Schichtenmodell (rechter vertikaler Pfeil): Unterteilung in Application Layer und UDS Transport Layer visuell durch zwei getrennte Pfeilsegmente entkoppelt.

Zugeordnete Anforderungen

Diese Angaben zeigt der Versions-Explorer.

Erkannte Spezifikationsbelege & Anforderungen auf dieser Seite

SWS_DM_00315

Aus dem Dokument extrahierter Text & Kontext

Beschriftungen im Schaubild:

UDS Transport Protocol API | Transport Protocol Manager | DoIP_TransportProtocolHandler | Diagnostic Server A | Software Cluster A | Diagnostic Server B | Custom_TransportProtocolHandler | Diagnostic Management | UDS Transport Layer Application Layer | Software Cluster B

Vorkommen in AUTOSAR-Releases (3)

Release Dokument Seite Nr. Bildunterschrift im Dokument
R18-10_R4.4.0_R1.5.0 AUTOSAR_SWS_Diagnostics S. 24 7.1 Figure 7.1: Component view on Diagnostic Management
R18-10_R4.4.0_R1.5.0 AUTOSAR_SWS_Diagnostics S. 24 7.1 Figure 7.1: Component view on Diagnostic Management
R18-10-1 AUTOSAR_SWS_Diagnostics S. 24 7.1 Figure 7.1: Component view on Diagnostic Management