Figure 9.84: Interfaces for generic request handling

1. Diagrammtyp & Architektur-Kontext

UML-Klassendiagramm / Komponentendiagramm kombiniert mit einer tabellarischen Schnittstellendefinition im Kontext der AUTOSAR Adaptive Platform. Das Diagramm modelliert die Interaktion zwischen einer Adaptive Application und dem funktionalen Cluster Diagnostic Management (daemon-based) über standardisierte Port-Schnittstellen zur generischen Anfrageverarbeitung und Diagnoseüberwachung.

2. Komponenten, Entitäten & Schnittstellen

Das Diagramm umfasst folgende Kernentitäten:

• Adaptive Application: Komponenteninstanz, die Diagnose- und Service-Schnittstellen konsumiert bzw. anbietet.
• «aapFunctionalCluster» Diagnostic Management: Daemon-basierter Funktionscluster für die Diagnoseverwaltung.
• Schnittstellenspezifikation ServiceValidation:
  • Typ / Metamodell: Port interface, DiagnosticServiceValidationInterface, kein generierter Code (Generated: No), Usage: Public API.
  • Operationen: Confirmation, Offer, StopOffer, Validate.
• Modellierte Port-Interfaces:
  • «aapPortInterface,a...» Monitor: Operationen Offer(), ReportMonitorAction(), StopOffer().
  • «aapPortInterface,aapAPI» Event: Operationen GetDebouncingStatus(), GetDTCNumber(), GetEventStatus(), GetFaultDetectionCounter(), GetLatchedWIRStatus(), GetTestComplete(), SetEventStatusChangedNotifier(), SetLatchedWIRStatus().
  • «aapPortInterface,aap...» GenericDataIdentifier: Operationen Offer(), Read(), StopOffer(), Write().
  • «aapPortInterface,aap...» GenericUDSService: Operationen HandleMessage(), Offer(), StopOffer().
  • «aapPortInterface,aap...» GenericRoutine: Operationen Offer(), RequestResults(), Start(), Stop(), StopOffer().
• Port-Beziehungen:
  • Adaptive Application nutzt Monitor, GenericDataIdentifier, GenericUDSService und GenericRoutine jeweils über «use» «aapRequiredPort».
  • Diagnostic Management bindet an GenericDataIdentifier, GenericUDSService und GenericRoutine über «use» «aapRequiredPort» sowie an Monitor über eine Required-Port-Beziehung an.
  • Das Interface Event wird von beiden Komponenten über gerichtete Assoziationen referenziert.

3. Dynamisches Verhalten & Sequenzablauf

Das Interaktionsmuster basiert auf Service-Orientierung und Zustandsbenachrichtigung:

1. Service-Registrierung und -Freigabe: Mittels Offer() signalisieren Komponenten dem Diagnostic Management die Bereitschaft zur Weiterleitung und Verarbeitung von Diagnoseanfragen. Mit StopOffer() wird diese Weiterleitung deaktiviert.
2. Validierungszyklus: Über Validate werden eingehende Diagnoseanfragen geprüft, und nach Abschluss der Bearbeitung meldet Confirmation das Ergebnis zurück.
3. Generische UDS- und Identifier-Verarbeitung: HandleMessage() dient der direkten Verarbeitung generischer UDS-Nachrichten, während Read() und Write() auf spezifische Daten-Identifier zugreifen.
4. Routinensteuerung: Start(), Stop() und RequestResults() steuern die Ausführung von Diagnose-Routinen.
5. Event- und Monitor-Verhalten: Statusabfragen (GetEventStatus, GetFaultDetectionCounter etc.) und Notifier (SetEventStatusChangedNotifier) ermöglichen die kontinuierliche Zustands- und Entprellüberwachung.

4. Normative Relevanz & Entwickler-Hinweise

Die Schnittstellen sind als Public API deklariert und stellen die funktionale Schnittstelle zwischen Applikation und Diagnostic Management dar. Nicht generierte Port-Interfaces (Generated: No) erfordern die manuelle oder standardkonforme Bereitstellung entsprechender Dienst-Endpunkte und Methodenrümpfe durch die Applikation bzw. den Stack. Die Methoden Offer und StopOffer regeln den dynamischen Lebenszyklus des Nachrichten-Routings im Daemon.