Figure 9.104: Common interfaces of Diagnostic Management (1 of 3)

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Klassendiagramm / Komponenten-Schnittstellendiagramm (AUTOSAR Adaptive Platform Architecture Model).
• Architektur-Kontext:
  • Funktionale Einordnung: Dargestellt ist die Client-Server-Interaktion zwischen einer Adaptive Application (Client) und dem Functional Cluster Diagnostic Management (DM, Server / Bereitsteller) innerhalb der AUTOSAR Adaptive Platform (AP).
  • Technischer Zweck: Spezifikation der allgemeinen standardisierten Diagnoseschnittstellen (Common Interfaces) für Session-/Security-Kontextverwaltung (Conversation) sowie Fehlerspeicher- und DTC-Statusabfragen/-steuerung (DTCInformation). Die Architektur zeigt die Trennung zwischen rein nativen C++-APIs («aapNativeInterface») und modellierten port-basierten Schnittstellen («aapPortInterface»).

2. Komponenten, Entitäten & Schnittstellen

Entitäten & Komponenten

• Adaptive Application (UML-Komponente): Konsumierender Prozess im POSIX-Anwenderraum, der Diagnoseinformationen abfragt oder steuert.
• Diagnostic Management (Stereotyp: «aapFunctionalCluster», Annotation: daemon-based): Plattform-Dienst/Daemon, der Diagnoseprotokoll-Stacks (DoIP, UDS via ISO 14229) und den Fehlerspeicher verwaltet.

Schnittstellen & Methoden

• Conversation (Stereotyp: «aapNativeInterface,aapAPI»):
  • Natur: Direkte native C++-Laufzeit-API (ohne Notwendigkeit eines modellierten Software-Ports im ARXML-Manifest).
  • Statische Factory-/Lookup-Methoden (unterstrichen):
    • GetAllConversations()
    • GetConversation(): Conversation
    • GetCurrentActiveConversations()
  • Instanz-Methoden (Status & Kontext):
    • GetActivityStatus()
    • GetConversationIdentifier()
    • GetDiagnosticSecurityLevel() / GetDiagnosticSecurityLevelShortName()
    • GetDiagnosticSession() / GetDiagnosticSessionShortName()
    • ResetToDefaultSession()
  • Instanz-Methoden (Asynchrone Notifier / Observer):
    • SetActivityNotifier()
    • SetDiagnosticSessionNotifier()
    • SetSecurityLevelNotifier()
• DTCInformation (Stereotyp: «aapAPI,aapPortInterface»):
  • Natur: Formale Port-Schnittstelle. Wird im Software-Design als R-Port der Applikation und P-Port des DM-Clusters instanziiert.
  • Methoden (Steuerung & Abfrage):
    • Clear(): Löschen von DTCs / Fehlerspeicherbereichen.
    • EnableControlDtc() / GetControlDTCStatus(): UDS Service 0x85 (ControlDTCSetting) Handhabung.
    • GetCurrentStatus(): Abfrage des UDS-DTC-Statusbytes.
    • GetEventMemoryOverflow(): Prüfung auf Pufferüberlauf im Event-Memory.
    • GetNumberOfStoredEntries(): Anzahl persistierter Einträge.
  • Methoden (Asynchrone Notifier / Callbacks):
    • SetControlDtcStatusNotifier()
    • SetDTCStatusChangedNotifier()
    • SetEventMemoryOverflowNotifier()
    • SetNumberOfStoredEntriesNotifier()
    • SetSnapshotRecordUpdatedNotifier()

Beziehungen & Abhängigkeiten

• Adaptive Application $\xrightarrow{\text{«use»}}$ Conversation: Direkte Abhängigkeit auf die native C++-Header-/Bibliotheksschnittstelle (ara::diag).
• Adaptive Application $\xrightarrow{\text{«use» «aapRequiredPort»}}$ DTCInformation: Port-basierte Dienstbindung (ara::com- bzw. IPC-vermittelte Bindung via Required Port).
• Diagnostic Management $\xhookrightarrow{\quad}$ Conversation & DTCInformation: Interface Realization; der Daemon implementiert beide Abstraktionen und stellt sie prozessübergreifend bereit.

3. Dynamisches Verhalten & Sequenzablauf

1. Konversations-Initialisierung & Sitzungsüberwachung (Conversation):
   • Die Applikation bindet sich über statische Methoden (GetConversation()) an eine aktive Diagnoseverbindung (Tester-Session).
   • Registrierung von Observer-Callbacks (SetDiagnosticSessionNotifier, SetSecurityLevelNotifier, SetActivityNotifier).
   • Bei UDS-Zustandsänderungen durch externe Diagnose-Tester (z. B. 0x10 DiagnosticSessionControl oder 0x27 SecurityAccess) feuert der Daemon asynchron die registrierten Callbacks der Applikation, um interne Sicherheitsfunktionen oder Betriebszustände freizuschalten.
   • ResetToDefaultSession() erlaubt es der Applikation, aktiv das Zurücksetzen in die Standarddiagnosesitzung anzufordern (z. B. bei Timeout oder sicherheitskritischem Systemzustand).
2. Fehlerspeicher-Abfrage und -Manipulation (DTCInformation):
   • Synchroner oder Future-basierter Aufruf von GetCurrentStatus() / GetNumberOfStoredEntries() zur zyklischen oder ereignisorientierten Fehlerprüfung.
   • Asynchrone Benachrichtigung bei Statuswechseln via SetDTCStatusChangedNotifier oder bei Pufferüberlauf via SetEventMemoryOverflowNotifier.
   • Nach Aufruf von Clear() stößt der DM-Daemon das Zurücksetzen der DTC-Statusmasken und das Löschen der Snapshot- bzw. Extended-Data-Records im Event-Memory an.

4. Normative Relevanz & Entwickler-Hinweise

• Schnittstellen-Paradigma («aapNativeInterface» vs. «aapPortInterface»):
  • Conversation ist API-zentriert: Im Manifest (ARXML) wird kein Port modelliert. Entwickler binden die Klassen direkt aus dem Namespace ara::diag::Conversation ein.
  • DTCInformation ist modelliert: Erfordert die Definition eines RPortPrototype mit passendem PortInterface im Application Manifest und Bindung an den DM-Dienst via Service Instance Manifest.
• Threading- und Reentrancy-Modell:
  • Die Notifier-Registrierungen (Set...Notifier()) registrieren std::function-Callables. Diese werden typischerweise im Thread-Kontext der zugrundeliegenden Middleware (ara::com / Daemon-Dispatcher-Worker-Thread) ausgeführt. Handler müssen thread-sicher, reentrant und nicht-blockierend ausgelegt sein.
• Return-Types & Fehlerbehandlung (ara::core::Result / ara::core::Future):
  • Methoden mit Latenz (z. B. Clear(), IPC-Abfragen zum Daemon) sind standardmäßig asynchron (ara::core::Future) oder liefern ara::core::Result<T> mit spezifischen DiagErrc-Fehlercodes (z. B. Busy, NotAllowedInCurrentSession/SecurityLevel).
• Daemon-Abhängigkeit:
  • Da Diagnostic Management als daemon-based annotiert ist, schlagen IPC-Aufrufe während des Bootvorgangs oder bei Daemon-Neustarts mit IPC-Verbindungsfehlern fehl. Ein robuster Startup-Handshake (Warten auf Cluster-Verfügbarkeit via Execution Management / Health Monitoring) ist zwingend erforderlich.