Figure 9.91: 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 daemon-basierten Funktionscluster Diagnostic Management 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 das Diagnosemanagement.
• Schnittstellenspezifikation ServiceValidation:
  • Typ / Metamodell: Port interface, DiagnosticServiceValidationInterface, kein generierter Code (Generated: No), Usage: Public API.
  • Operationen: Confirmation, Offer, StopOffer, Validate.
  • Im oberen Tabellenteil ist ein unbenanntes Fragment mit Offer und StopOffer enthalten.
• 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 bindet an alle fünf Port-Interfaces (Monitor, Event, GenericDataIdentifier, GenericUDSService, GenericRoutine) über «use» «aapRequiredPort» an.
  • Diagnostic Management bindet an GenericDataIdentifier, GenericUDSService und GenericRoutine über «use» «aapRequiredPort» sowie an Monitor und Event über Required-Port-Verbindungen an.

3. Dynamisches Verhalten & Sequenzablauf

Das Interaktionsmuster basiert auf Service-Orientierung und Zustandsbenachrichtigung:

1. Service-Registrierung und -Freigabe: Offer schaltet das Weiterleiten von Diagnoseanfragen aus dem Diagnostic Management frei, StopOffer sperrt es.
2. Validierungszyklus: Über Validate werden Diagnoseanfragen vor der Bearbeitung geprüft; nach Beendigung wird das Ergebnis per Confirmation gemeldet.
3. Generische UDS-, Daten- und Routinenverarbeitung: HandleMessage() dient der Bearbeitung generischer UDS-Nachrichten, Read() und Write() dem Zugriff auf Identifier, und Routinen werden über Start(), Stop() sowie RequestResults() geführt.
4. Event- und Monitor-Verhalten: Diagnose-Events und Monitor-Aktionen werden über Statusabfragen und Notifier synchronisiert.

4. Normative Relevanz & Entwickler-Hinweise

Die Schnittstelle ServiceValidation ist als Public API (Generated: No) definiert. Sie dient Applikationen dazu, Diagnoseanfragen zu validieren und Benachrichtigungen über deren Abschluss zu empfangen, gesteuert durch Offer- und StopOffer-Zustände.