Figure 9.3: Deployment Overview of Diagnostics

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Architekturschichten- und Deployment-Diagramm (High-Level Deployment Overview) im Kontext der AUTOSAR Adaptive Platform (AP).
• Technischer Zweck: Darstellung der Bereitstellung und Entkopplung des Functional Clusters Diagnostics (ara::diag). Das Diagramm illustriert die Vermittler- und Serverrolle des zentralen Diagnostic Managers (DM) zwischen externen Testern (Diagnostic Client) und softwaredefinierten Applikationen (App1–App3) über zwei parallele Protokollstapel (UDS via DoIP und SOVD via HTTP).

2. Komponenten, Entitäten & Schnittstellen

• Adaptive Platform (Execution Environment / Machine):
  • Adaptive Applications (App1, App2, App3): Unabhängige POSIX-Betriebssystemprozesse im User Space, die als funktionale Diagnosedienstleister fungieren (Bereitstellung von DIDs, Routinen, Data Identifiers, Monitor-Objekten für Fehlerspeicher).
  • ARA-Grenze (AUTOSAR Runtime for Adaptive Applications): Schichtenabstraktion via C++ API-Schnittstellen (ara::diag), dargestellt über Assembly-Konnektoren (Lollipop/Socket).
    • Ports/Interfaces: Repräsentieren typisierte ara::diag-Dienste (z. B. DiagnosticService, GenericDataIdentifier, Routine, SecurityAccessService, Monitor).
  • Diagnostic Manager (Functional Cluster): Zentraler Plattform-Daemon/Server innerhalb von ARA. Terminiert Diagnoseprotokolle, verwaltet Diagnosezustände (Session, Security Level) und übernimmt das Routing/Dispatching an die zuständigen Applikationen.
  • Network Layer (Transport- und Netzwerkschicht):
    • UDS über DoIP: Klassischer Pfad gemäß ISO 14229-1 (UDS) getunnelt über ISO 13400-2 (Diagnostic over IP / TCP/UDP).
    • SOVD über HTTP: Serviceorientierter Pfad gemäß ASAM SOVD (Service-Oriented Vehicle Diagnostics) / ISO 18571 über HTTP/HTTPS (RESTful API, JSON-Payloads, WebSockets).
• Diagnostic Client (Akteur / Externes System): Externer oder On-Board-Diagnosetester (z. B. Werkstatttester, Over-the-Air-/Cloud-Backend, Flottenmanagement-Client).

3. Dynamisches Verhalten & Sequenzablauf

1. Request Ingress & Transport-Terminierung:
   • Der Diagnostic Client initiiert eine Diagnoseanforderung entweder binär kodiert als UDS-PDU via DoIP oder als HTTP-REST-Aufruf (z. B. GET /sovd/v1/components/...) via TCP/TLS.
   • Der Diagnostic Manager nimmt die Verbindung auf dem jeweiligen Port (z. B. TCP 13400 für DoIP; TCP 80/443 für HTTP) im Network Layer an.
2. Protokolldekodierung & Security-Gate:
   • DM validiert Routing-Aktivierung, TLS-Zertifikate/Tokens (SOVD) bzw. Seed & Key / Security-Level (UDS).
   • Prüft Berechtigungen sowie den aktuellen Session-Zustand (z. B. Default, Extended, Programming Session).
3. Dispatching via Inter-Process Communication (IPC):
   • Anhand des Diagnostic Extract (DEXT) mappt der DM den Identifier (DID, RID) oder den SOVD-URI-Pfad auf die zuständige AdaptiveApplication (App1..App3).
   • Asynchroner Aufruf des entsprechenden C++-API-Handlers der Applikation über platform-internes IPC.
4. Response Aggregation & Egress:
   • Die Applikation liefert die Daten via ara::core::Future/Promise oder Callback an den DM zurück.
   • Der DM formatiert die Nutzlast in die entsprechende Response (UDS Positive/Negative Response Message bzw. HTTP-Statuscode mit JSON-Body) und sendet sie an den Client zurück.

4. Normative Relevanz & Entwickler-Hinweise

• Vollständige Transport-Transparenz für Applikations-Entwickler:
  • Applikationen binden ausschließlich gegen die abstrakten C++-Schnittstellen von ara::diag.
  • Entwickler implementieren weder DoIP-Sockets noch HTTP/REST-Endpunkte. Ein Service-Handler (z. B. für einen Messwert) wird transparent bedient, unabhängig davon, ob die Anfrage via UDS oder SOVD eingeht.
• Asynchrone API-Verträge:
  • ara::diag-Schnittstellen fordern nicht-blockierende Implementierungen. Operationen müssen mit ara::core::Future/Promise arbeiten, um ein Blockieren des IPC-Event-Loops im DM zu verhindern.
• Anforderungen an Stack-/Plattform-Entwickler:
  • Der DM muss als Multithreaded-Daemon ausgelegt sein, der DoIP-Handler (Routing Activation, Alive Check) und einen integrierten Webserver/HTTP-Stack für SOVD parallel betreiben kann.
  • Das Session- und Security-Management muss zentral im DM konsolidiert sein, damit konkurrierende Anfragen (DoIP vs. SOVD) deterministisch arbitriert werden.
• Modellierung & Deployment (Manifest/DEXT):
  • Bindung zwischen Applikations-Ports und Diagnose-Entitäten erfolgt deklarativ im AUTOSAR-ARXML-Modell.
  • Zur Kompilierzeit/Generierungszeit werden die Skeleton-/Proxy-Artefakte für die IPC-Kommunikation zwischen Applikation und DM aus dem Modell erzeugt.