Figure 9.107: Interfaces for request handling

1. Diagrammtyp & Architektur-Kontext

UML-Komponenten- und Schnittstellendiagramm im Kontext der AUTOSAR Adaptive Platform (ARA). Es visualisiert die Port-Schnittstellen und Abhängigkeiten für das Request-Handling zwischen einer Anwendungsinstanz (Adaptive Application) und dem daemon-basierten Plattform-Cluster Diagnostic Management («aapFunctionalCluster»).

2. Komponenten, Entitäten & Schnittstellen

• Adaptive Application: Applikationskomponente der Adaptive Platform, die als Service-Konsument über Client-/Required-Ports («use», «aapRequiredPort») auf Diagnose-Schnittstellen zugreift.
• Diagnostic Management («aapFunctionalCluster», Annotation daemon-based): Funktionaler Plattform-Cluster der AUTOSAR Adaptive Platform, der als Service-Provider fungiert und die drei Port-Schnittstellen implementiert (InterfaceRealization).
• Condition («aapAPI,aapPortInterface»): Port-Interface zur Abfrage und Steuerung von Diagnosefreigabebedingungen (z. B. Spannungs- oder Betriebsfreigaben).
  • + GetCondition(): Ermittelt den aktuellen Freigabestatus einer Diagnosebedingung.
  • + SetCondition(): Setzt den Status der Diagnosebedingung im Diagnostic Management.
• OperationCycle («aapAPI,aapPortInterface»): Port-Interface zur Steuerung und Überwachung von Diagnose-Betriebszyklen (z. B. Driving- oder Ignition-Cycle).
  • + GetOperationCycle(): Liest den aktuellen Zustand des Betriebszyklus aus.
  • + SetNotifier(): Registriert Benachrichtigungs-Callbacks für Zustandsänderungen des Zyklus.
  • + SetOperationCycle(): Schaltet den Zustand des Betriebszyklus um.
• Indicator («aapAPI,aapPortInterface»): Port-Interface zur Abfrage und Überwachung von Diagnose-Warnanzeigen (z. B. MIL).
  • + GetIndicator(): Fragt den Status eines Indikators ab.
  • + SetNotifier(): Registriert Benachrichtigungs-Callbacks bei Statusänderungen des Indikators.

3. Dynamisches Verhalten & Sequenzablauf

Die Adaptive Application kommuniziert über typisierte Port-Schnittstellen mit dem Diagnostic Management Daemon:

1. Zustandsabfrage: Mittels synchroner oder asynchroner Methodenaufrufe von GetCondition(), GetOperationCycle() oder GetIndicator() ruft die Applikation Statusinformationen aus dem Cluster ab.
2. Steuerung / Meldung: Über SetCondition() und SetOperationCycle() meldet die Applikation Zustandsübergänge (z. B. Erfüllung von Bedingungen, Start/Stopp eines Betriebszyklus) an das Diagnostic Management, welches daraufhin interne Entprellungen, Zähler und Qualifikationslogiken anpasst.
3. Ereignisgesteuerte Notifizierung: Über SetNotifier() registriert die Applikation Callback-Mechanismen, sodass Statusänderungen von Betriebszyklen oder Warnindikatoren durch das Diagnostic Management ereignisbasiert gemeldet werden, ohne dass aktives Polling erforderlich ist.

4. Normative Relevanz & Entwickler-Hinweise

Die dargestellten Schnittstellen basieren auf den normativen Spezifikationen der AUTOSAR Adaptive Platform (insbesondere SWS Diagnostic Management):

• Daemon-Architektur: Die Kennzeichnung daemon-based verdeutlicht, dass das Diagnostic Management als eigenständiger Prozess/Daemon ausgeführt wird; Interaktionen erfolgen über Inter-Process Communication (IPC).
• Entwickler-Hinweise:
  • Im Systementwurf (ARXML) müssen auf Seiten der Applikation RPortPrototype-Elemente modelliert werden, die über Port-Interfaces (Condition, OperationCycle, Indicator) an die korrespondierenden PPortPrototype-Instanzen des Diagnostic-Management-Daemons gebunden werden.
  • Zur Vermeidung unnötiger IPC-Last bei Zustandsänderungen von Indikatoren und Betriebszyklen ist die Registrierung via SetNotifier() dem wiederholten zyklischen Polling via Get*() vorzuziehen.
  • Aufrufe unterliegen den Fehlermechanismen der Plattform (ara::core::Result / Exceptions).