Figure 7.3: ApApplicationError - Model View

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Objektdiagramm / Metamodell-Instanzschaubild (M1-Modellebene) gemäß AUTOSAR Adaptive Platform (AP).
• Technischer Zweck & Einordnung: Veranschaulicht die modellgetriebene Spezifikation von Anwendungsfehlern (ApApplicationError) für serviceorientierte Kommunikation (ara::com) in der Spezifikation AUTOSAR_AP_SWS_LanguageBindingForModeledAPdatatypes. Das Diagramm definiert, wie ClientServerOperations innerhalb von ServiceInterfaces über direkte Referenzen und wiederverwendbare Fehlermengen (ApApplicationErrorSet) mit konkreten Fehlern verknüpft und deren Domänen (ApApplicationErrorDomain) zugeordnet werden.

2. Komponenten, Entitäten & Schnittstellen

Entitäten und Attribute

• ServiceInterface (M1-Instanzen: ifA, ifB): Definiert die Serviceschnittstelle für Proxy/Skeleton-Generierung. Enthält Operationen vom Typ ClientServerOperation.
• ClientServerOperation (Instanzen: ReadX, WriteX, ReadY): Repräsentiert RPC-Methoden.
  • Attribut: fireAndForget = false (zwingende Voraussetzung für Application Errors; asynchrone Einweg-Kommunikation unterstützt keine Fehlerrückmeldung).
  • Rollen/Referenzen:
    • possibleApErrorSet: Referenz auf ApApplicationErrorSet [0..*].
    • possibleApError: Direkte Referenz auf ApApplicationError [0..*].
• ApApplicationErrorSet (Instanzen: errSetV, errSetX, errSetY, errSetZ): Wiederverwendbarer Aggregationscontainer für Fehlermengen.
  • errSetV: aggregiert E_FOO, E_BAR (im Diagramm unreferenziert; demonstriert Entkopplung).
  • errSetX: aggregiert E_BAZ, E_CUX, E_UNKNOWN.
  • errSetY: aggregiert E_CUX, E_UNKNOWN.
  • errSetZ: aggregiert E_UNKNOWN, E_FILEDESC.
• ApApplicationError (Instanzen: E_FOO, E_BAR, E_BAZ, E_CUX, E_UNKNOWN, E_FILEDESC): Konkreter fachlicher Fehler.
  • Attribute: shortName (Bezeichner), errorCode (numerischer Integer-Code, z. B. 1, 2, 100, 101).
  • Assoziation: Verweist strikt n:1 auf genau eine ApApplicationErrorDomain.
• ApApplicationErrorDomain (Instanzen: domM, domN, domP): Definiert den Fehlerbereich (Namespace) analog zu ara::core::ErrorDomain.
  • Attribute: shortName (Domänenname), value (eindeutiger 64-Bit-Domänenbezeichner: domM = 1, domN = 5, domP = 17).

Beziehungen & Kardinalitäten

• Operation → Error: Sowohl direkt (n:m via possibleApError) als auch indirekt über Sets (n:m via possibleApErrorSet) möglich.
• Redundanz/Überlappung: Eine Operation darf denselben Fehler sowohl direkt als auch über ein Set referenzieren (z. B. ifA::ReadX referenziert E_UNKNOWN direkt und via errSetX; ifB::ReadY bindet E_UNKNOWN und E_FILEDESC direkt ein, obwohl errSetX ebenfalls referenziert ist).
• Multi-Domain-Fehler pro Operation: Eine Operation kann Fehler aus mehreren Domänen zurückgeben (z. B. wirft ifB::ReadY Fehler aus domN und domP).

3. Dynamisches Verhalten & Sequenzablauf (falls zutreffend)

• Modellierungscharakter: Reines Struktur- und Zuordnungsmodell. Zur Laufzeit steuert dieses Gefüge das Fehlerverhalten in ara::com:
  1. Aufruf: Client ruft Methode via Proxy asynchron/synchron auf (ara::core::Future<Output> / ara::core::Result<Output, ara::core::ErrorCode>).
  2. Fehlerfall: Der Server-Skeleton bricht die Ausführung ab und retourniert einen ara::core::ErrorCode.
  3. Identifikation: Der Fehlercode setzt sich zur Laufzeit aus dem 64-Bit-Wert der ApApplicationErrorDomain (value) und dem 32-Bit-errorCode des konkreten ApApplicationError zusammen.
  4. Auswertung: Der Client prüft über die generierten Fehler-Enums und Domain-Instanzen (ara::core::ErrorDomain), welcher fachliche Fehler vorliegt.

4. Normative Relevanz & Entwickler-Hinweise

• SWS_LBAP_00050 (Generierung von Error Domains): Für jede ApApplicationErrorDomain generiert der AP-Code-Generator eine konkrete Subklasse von ara::core::ErrorDomain mit dem modellierten 64-Bit-value (z. B. DomMErrorDomain mit ID 1).
• SWS_LBAP_00052 (Generierung von Error-Code-Enums): Für die in einer Domäne definierten ApApplicationErrors wird ein scoped Enum (z. B. enum class Errc : ara::core::ErrorDomain::CodeType) generiert, dessen Enumeratoren den shortNames und Werten aus errorCode entsprechen.
• Deduplizierungspflicht für Tool-Vendors: Code-Generatoren müssen die effektive Fehlermenge pro Operation als Vereinigungsmenge aus direkten Referenzen (possibleApError) und indirekten Mengen (possibleApErrorSet) bilden. Mehrfachreferenzen (wie bei ifA::ReadX) müssen idempotent aufgelöst werden.
• Restriktionen für Applikationsentwickler:
  • Eine Operation mit fireAndForget = true darf weder possibleApError noch possibleApErrorSet definieren.
  • Der Skeleton-Entwickler darf ausschließlich Fehler zurückgeben, die für die jeweilige ClientServerOperation modelliert wurden, da Serialisierungs- und Kommunikations-Bindings (z. B. SOME/IP) nur deklarierte Application Errors im Protokoll-Header transportieren und validieren.