Figure 9.89: Interfaces for generic request handling

1. Diagrammtyp & Architektur-Kontext

UML-Klassendiagramm / Komponentendiagramm kombiniert mit tabellarischen Schnittstellendefinitionen im Kontext der AUTOSAR Adaptive Platform. Das Diagramm modelliert die Interaktion zwischen einer Adaptive Application und dem funktionalen Cluster Diagnostic Management (daemon-based) über Port-Schnittstellen zur Behandlung generischer Diagnoseanfragen sowie sicherheitsbezogener Zugriffe (SecurityAccess).

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 SecurityAccess:
  • Typ / Metamodell: Port interface, DiagnosticSecurityLevelInterface, kein generierter Code (Generated: No), Usage: Public API.
  • Operationen: CompareKey, GetSeed, Offer, StopOffer.
• 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 bindet an Monitor, Event, GenericDataIdentifier, GenericUDSService und GenericRoutine jeweils über «use» «aapRequiredPort» an.
  • Diagnostic Management bindet an GenericDataIdentifier, GenericUDSService und GenericRoutine über «use» «aapRequiredPort» sowie an Monitor und Event über Required-Port-Beziehungen an.

3. Dynamisches Verhalten & Sequenzablauf

Das Interaktionsmuster basiert auf Service-Orientierung, Sicherheitsfreigabe und Diagnosebenachrichtigung:

1. SecurityAccess-Ablauf: Über GetSeed wird ein kryptografischer Seed angefordert; CompareKey prüft den übermittelten Schlüssel und meldet den Ausgang der Anfrage zurück. Die Weiterleitung von SecurityAccess-Nachrichten wird über Offer und StopOffer gesteuert.
2. Validierungszyklus: Eingehende Diagnoseanfragen werden via Validate geprüft und mit Confirmation abgeschlossen.
3. Generische UDS-, Daten- und Routinenverarbeitung: HandleMessage() verarbeitet Nachrichten generisch; Read() und Write() manipulieren Daten-Identifier; Start(), Stop() und RequestResults() steuern Diagnoseroutinen.
4. Event- und Monitor-Verhalten: Zustandsabfragen (GetEventStatus, GetFaultDetectionCounter etc.) und Notifier steuern das Fehlermanagement.

4. Normative Relevanz & Entwickler-Hinweise

Sowohl SecurityAccess als auch ServiceValidation sind als Public API ohne Codegenerierung (Generated: No) definiert. Implementierungen müssen sicherstellen, dass Sicherheitsanfragen (Seed-Key-Verfahren) und Service-Validierungen vor der Weiterleitung an tiefere Applikationsschichten korrekt durch das Diagnostic Management autorisiert und gesteuert werden.