Figure 1.2: Diagnostic Managers external dependencies

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: Informelles Komponenten- und Abhängigkeitsdiagramm (Functional Architecture / External Dependencies Diagram) der AUTOSAR Adaptive Platform (AP).
• Funktionaler Zweck: Dokumentiert die Systemgrenzen, externen Kopplungen und Abhängigkeiten des Functional Clusters Diagnostic Management (ara::diag) zu Adaptive Applications, Nachbar-Clustern, Basisinfrastruktur (POSIX/Netzwerk) und den zugrunde liegenden Modellierungsmanifesten.
• Architektur-Einordnung: In der AUTOSAR Adaptive Platform läuft der Diagnostic Manager typischerweise als eigenständiger Prozess (Platform Application). Er agiert als Bindeglied zwischen externen Diagnosetestern (über Ethernet/DoIP) und der internen Software-Architektur (Adaptive Applications und Systemdienste).

2. Komponenten, Entitäten & Schnittstellen

• Diagnostic Manager (Zentraler Cluster):
  • DEM / DCM (Diagnostic Event Manager / Diagnostic Communication Manager): Konsolidierte Diagnoseschicht. Verarbeitet ISO-14229-1 (UDS)-Services, verwaltet Fehlerspeicher (DTCs, Status-Bits, Freeze Frames, Extended Data) und steuert Diagnosesitzungen sowie Sicherheitslevel.
  • TP (Transport Protocol): Netzwerknahe Schicht zur Protokollsegmentierung und -terminierung; auf AP-Systemen primär als DoIP (Diagnostics over IP, ISO 13400-2) implementiert.
  • API on ARA::Com (Schnittstellenadapter): Adaptionsschicht, die die standardisierten C++-APIs (ara::diag) über Interprozesskommunikation (IPC via ara::com) für verteilte Applikationen bereitstellt.
• Application (Adaptive Application):
  • Applikationsprozess, der als Diagnose-Provider dient (Bereitstellung von DIDs via DataIdentifier, Ausführung von RoutineControl, Event-Reporting für DTCs via DiagnosticEvent).
• Dependencies to Functional Clusters (Plattformdienste):
  • Statemanger (ara::sm): Entgegennahme und Ausführung von Reset- und Moduswechselanforderungen (z. B. UDS-Service 0x11 ECUReset oder UDS 0x28 CommunicationControl).
  • Executionmanager (ara::exec): Lebenszyklusüberwachung, Anbindung an Execution State Reporting und Funktionsgruppen-Statuswechsel.
  • Updatemanager (ara::ucm): Abwicklung software- und firmwarebezogener Diagnosedienste (UDS Services 0x34 RequestDownload, 0x36 TransferData, 0x37 RequestTransferExit) zur Koordination von Software-Updates.
  • Persistency (ara::per): Nichtflüchtige Speicherung von Diagnosedaten (DTC-Status, Snapshot-Daten, Fehlerspeicherhistorie) über Key-Value- oder File-Storage-Mechanismen.
  • Security (ara::crypto / IAM): Authentifizierung und Autorisierung externer Tester (UDS 0x29 Authentication, 0x27 SecurityAccess), kryptografische Zertifikatsvalidierung sowie Policy-Durchsetzung über Identity and Access Management.
• Konfigurationsmanifeste (ARXML-Artefakte):
  • Application Manifest: Definiert die Port-Schnittstellen, Prozess-Instanziierungen und das ara::com-Service-Mapping der Applikation.
  • DEXT (Diagnostic Extract, ASAM MCD-2 D / ODX-Äquivalent): Spezifiziert UDS-Services, DIDs, DTCs, Entprellalgorithmen, Read/Write-Zugriffsrechte und Snapshot-Parameter.
  • **Maschine Manifest (sic, Machine Manifest):** Konfiguriert die Hardware- und Netzwerktopologie (z. B. IP-Adressen, TCP/UDP-Ports für DoIP-Endpunkte) der Zielmaschine.
• Plattform-Basis:
  • Network / POSIX: Bereitstellung des Betriebssystem-Sockets (z. B. BSD Sockets für DoIP auf Port 13400) und der Multithreading-/IPC-Primitive gemäß POSIX PSE51/PSE52.

3. Dynamisches Verhalten & Sequenzablauf

Obwohl das Diagramm statische Abhängigkeiten zeigt, definiert die Architektur folgende dynamische Pfade:

1. Externe Diagnoseanforderung (Tester → Application):
   • Diagnose-Frame trifft via Network / POSIX-Socket beim TP (DoIP) ein.
   • TP validiert den DoIP-Header und übergibt die UDS-Nutzlast an DEM/DCM.
   • DEM/DCM prüft über Security (IAM/Crypto) Zugriffsrechte und aktive Sitzung.
   • Bei service- oder datenspezifischen Anfragen (z. B. ReadDataByIdentifier 0x22) dispatcht DEM/DCM über API on ARA::Com einen asynchronen IPC-Call an die Ziel-Application.
   • Die Application antwortet via ara::core::Future/ara::core::Result; DEM/DCM generiert die UDS-Response und sendet sie über TP zurück.
2. Internes Event-Reporting (Application → Fehlerspeicher):
   • Application meldet Fehlerzustand via ara::diag::DiagnosticEvent::SetEventStatus().
   • IPC-Übertragung an DEM/DCM; Ausführung der Fehlerentprellung (Debouncing).
   • Bei Statusübergang zu confirmed erfolgt das Erfassen von Freeze Frames und das synchrone/asynchrone Persistieren via Persistency (ara::per).
3. Systemzustandsmodifikation (Tester → System):
   • Eintreffen einer UDS-Steueranforderung (0x11 oder Update-Sequenz 0x34).
   • DEM/DCM delegiert an Statemanger (Systemneustart/State Transition) bzw. Updatemanager (UCM-Paketverarbeitung).

4. Normative Relevanz & Entwickler-Hinweise

• Asynchrone API-Semantik (ara::core::Future): Da Aufrufe zwischen DEM/DCM und Application zwingend über IPC (API on ARA::Com) laufen, dürfen Applikations-Handler (z. B. für DIDs oder RoutineControls) nicht blockieren. Entwickler müssen mit asynchronen Return-Types und strikten Timeouts (UDS P2/P2* Timer) arbeiten, um ein Session-Timeout zu verhindern.
• Manifest-Konsistenz (DEXT vs. Manifests): Das DEXT definiert Diagnoseobjekte normativ, während das Machine Manifest Netzwerkressourcen (DoIP-Sockets) und das Application Manifest die Kommunikations-Bindings bindet. Diskrepanzen zwischen DEXT (z. B. erwartete DID-Byte-Länge) und der C++-Implementierung führen zu Serialisierungsfehlern in der ara::com-Schicht.
• Persistenz-Zyklen & Wearout: Schreibzugriffe auf ara::per für DTC-Statusbits müssen hinsichtlich Flash-Haltbarkeit (Endurance) und Crash-Sicherheit konfiguriert werden; Logging- und Entprellstrategien sollten im DEXT restriktiv gewählt werden.
• Port-Isolation & Firewalling: Da TP direkt auf POSIX-Netzwerk-Sockets aufsetzt, muss das Routing (DoIP TCP/UDP Port 13400) im Machine Manifest und der POSIX-Firewall strikt auf autorisierte Interfaces (z. B. Diagnosestecker, interner Switched-Ethernet-Port) beschränkt werden.