Figure 1.1: Architecture Diagnostic Communication Management

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Schematisches Schichten- und Komponentenmodell (Blockarchitektur) der AUTOSAR Adaptive Platform (AP).
• Technischer Zweck: Darstellung der modularen, mehrstufigen Architektur des Diagnostic Communication Management (DCM) gemäß AUTOSAR_AP_SWS_Diagnostics.
• Funktionale Einordnung:
  • Trennung zwischen zentraler Netzwerkanbindung/Transportabstraktion (untere Ebene) und dezentralen, pro Software-Cluster (SWCL) instanziierten Diagnose-Server-Instanzen (obere Ebene).
  • Ermöglicht Multi-Client/Multi-Server-Diagnose auf POSIX-basierten Hochleistungs-Steuergeräten (HPCs) unter Berücksichtigung von getrennten Adressräumen, Update-Domänen (Software Clusters) und getrennten UDS-Zustandsmaschinen.

2. Komponenten, Entitäten & Schnittstellen

• Transport- und Busebene (Netzwerk-Ebene):
  • Ethernet: Physisches Übertragungsmedium.
  • DoIP (Diagnostic over IP) & Custom TP: Transportprotokoll-Treiber/Plugins zur Entkapselung von UDS-PDUs (z. B. DoIP nach ISO 13400 oder proprietäre Transportprotokolle).
  • Transport Layer API: Generische Abstraktionsschicht zur Entkopplung der Transportspezifika vom übergeordneten Routing.
• Zentraler Dispatcher:
  • Dispatching towards Diagnostic Server Instances: Zentrale Vermittlungskomponente; filtert und routet eingehende Diagnoseanfragen (basierend auf Target Address, DoIP Logical Address oder Tester-ID) an die jeweils zuständige Diagnose-Server-Instanz des adressierten Software-Clusters.
• Software Cluster (SWCL A, SWCL B) – Diagnose-Server-Instanzen:
  • Software Cluster: Unabhängig deploybare, startbare und aktualisierbare logische Funktionseinheiten (Update- und Ausführungseinheiten).
  • Jede Instanz beinhaltet autark:
    • Diagnostic Session Handling / Security Checks: Autonome Verwaltung von UDS-Sitzungszuständen (Standard, Extended, Programming Session gemäß ISO 14229-1) sowie Authentifizierungs- und Sicherheitsstufen (SecurityAccess 27, Service29 Authentication).
    • Request Dispatching: Lokaler Request-Router innerhalb des Clusters.
    • Internal Processing: Interne Bearbeitung von Standard-Services, die direkt vom Stack ohne Applikationsinteraktion bedient werden (z. B. 10 DiagnosticSessionControl,3E TesterPresent, Status-Rückgaben, NRC-Handling).
• Applikationsebene:
  • Diagnostic Application (A.1, A.2, B.1, B.2): Adaptive Applications, die über ara::diag-Schnittstellen angebunden sind.
  • Interaktionspfade:
    • Direkte Ausführung (Direct Dispatching): Weiterleitung applikationsspezifischer UDS-Services (z. B. 22 ReadDataByIdentifier,2E WriteDataByIdentifier, $31 RoutineControl) direkt vom lokalen Dispatcher an die Applikation (z. B. Pfad zu A.2, B.2).
    • Gekoppelte interne Verarbeitung (Internal Processing + App-Callback): Bearbeitung von Services im Stack mit Vor-/Nachbereitung durch die Applikation bzw. Abruf interner Zustände (z. B. Pfad über Internal Processing zu A.1, B.1).

3. Dynamisches Verhalten & Sequenzablauf

1. PDU-Empfang & Reassemblierung:
   • Diagnosetelegramm trifft via Ethernet ein. DoIP (oder Custom TP) übernimmt Verbindungsmanagement, Header-Validierung und Nachrichtenassemblierung.
2. Globales Dispatching (Transport Layer -> Server Instance):
   • Die PDU wird über die Transport Layer API an das globale Dispatching übergeben.
   • Anhand der logischen Zieladresse wird die Nachricht dem Ziel-Software-Cluster (Software Cluster A oder Software Cluster B) zugewiesen und per prozessübergreifender IPC an dessen Server-Instanz übergeben.
3. Session- & Security-Gatekeeping:
   • Validierung, ob der angeforderte Service (SID) und Subfunktion im aktuellen Zustand des Clusters zulässig sind.
   • Bei Verstoß: Sofortige Abweisung via NRC (z. B. 0x7E - SubFunctionNotSupportedInActiveSession, 0x33 - SecurityAccessDenied).
4. Lokales Routing & Verarbeitung:
   • Zweig 1 (Interner Service): Stack verarbeitet die Anfrage autark (Internal Processing) oder ruft registrierte Handler der Applikation synchron/asynchron auf.
   • Zweig 2 (Applikations-Service): Dispatcher serialisiert/leitet die Payload an die entsprechende Adaptive Application weiter (ara::diag::GenericDataIdentifier, ara::diag::Routine etc.).
5. Antwort-Aggregation & Response-Übertragung:
   • Applikationsergebnis oder interne Response wird formatiert, mit SID Response Identifier versehen, über den zentralen Transportpfad zurückgeführt und via DoIP an den externen Diagnosetester gesendet.

4. Normative Relevanz & Entwickler-Hinweise

• Zustandskapselung (Multi-Server-Konzept):
  • Jede Software-Cluster-Instanz kapselt ihre eigenen Diagnosezustände. Ein Session-Wechsel in Software Cluster A (z. B. Übergang in Extended Session) hat keine automatische Auswirkung auf Software Cluster B. Entwickler müssen clusterübergreifende Abhängigkeiten architektonisch gesondert behandeln.
• IPC- und Latenz-Overhead:
  • Das zweistufige Dispatching (Global -> Cluster -> Application) beinhaltet bis zu zwei Interprozess-Kommunikationsschritte (IPC). Für zeitkritische Diagnoseroutinen (31) oder High-Throughput-DIDs (22 / $36) müssen P2/P2*-Timer (P2ServerMax, P2*ServerMax) entsprechend großzügig konfiguriert oder asynchrone Pending-Mechanismen (NRC 0x78 - RequestCorrectlyReceived-ResponsePending) im Stack vorgesehen werden.
• Service-Instanziierung über ara::diag:
  • Applikationen binden sich als Service-Instanzen via Manifest (.arxml) an den lokalen DCM des Clusters. Es dürfen keine direkten Netzwerk- oder DoIP-Sockets auf Applikationsebene geöffnet werden.
• Custom TP-Erweiterbarkeit:
  • Die standardisierte Transport Layer API erlaubt die nahtlose Integration alternativer Transportprotokolle (z. B. PCIe-basiertes virtuelles TP, SOME/IP-TP oder CAN-FD über Gateway-Brücken), ohne den Session- oder Applikations-Layer modifizieren zu müssen.