DEENESPTFRRUARHIKOZHNL
AUTOSAR_AP_EXP_SWArchitecture FIG-a15bccf4b248814c 364 × 213 px 1 Release(s)

Figure 9.18: Interfaces of Core

SHA-256 Inhalts-Fingerabdruck: a15bccf4b248814c1bc75bd7a73d8decd941c9e261014a3e65e1e2170abec935
✦ KI-generierte Bildanalyse & technische Beschreibung Modell: gemini-3.8-flash (via agy) · Rezept figure-series@1 · erstellt am 2026-10-08

1. Diagrammtyp & Architektur-Kontext

  • Diagrammtyp: UML-Klassendiagramm / Interface-Realization-Diagramm (Spezifikations-Metamodell der AUTOSAR Adaptive Platform).
  • Architektur-Kontext: AUTOSAR Adaptive Platform (AP), Release R21-11. Das Diagramm ordnet den fundamentalen Basisfunktionscluster Core (ara::core) und dessen native C++-Programmierschnittstellen (APIs) in die Gesamtarchitektur ein.
  • Technischer Zweck: Spezifikation der standardisierten Basisschnittstellen für das Lebenszyklus-Management der AP-Laufzeitumgebung eines Prozesses sowie für deterministisches Exception- und Terminierungs-Handling (Fail-Fast-Paradigma).

2. Komponenten, Entitäten & Schnittstellen

  • Komponenten / Entitäten:
    • Core (Stereotyp «aapFunctionalCluster»): Repräsentiert den Functional Cluster des Adaptive Core-Subsystems als ausführende Plattformkomponente (Komponentensymbol oben rechts).
  • Schnittstellen (Native Interfaces):
    • Core [Lifecycle] (Stereotyp «aapAPI,aapNativeInterface», im Diagramm als «aapAPI,aapNativeInterf...» trunkiert):
      • + Initialize() (unterstrichen = statische Funktion): Initialisiert die globale AP-Laufzeitumgebung des Prozesses.
      • + Deinitialize() (unterstrichen = statische Funktion): Baut die globale AP-Laufzeitumgebung sauber ab.
    • Core [Abort/Panic] (Stereotyp «aapAPI,aapNativeInterface»):
      • + Abort() (unterstrichen = statische Funktion): Löst die unumkehrbare, sofortige Terminierung des Prozesses aus.
      • + SetAbortHandler() (unterstrichen = statische Funktion): Registriert einen anwendungsspezifischen Callback vor der Terminierung.
  • Beziehungen:
    • Interface Realization: Gestrichelte Pfeile mit geschlossener, nicht ausgefüllter Dreiecksspitze vom Cluster Core zu den beiden Interface-Blöcken. Der Functional Cluster realisiert und exportiert die definierten statischen C++-Funktionssignaturen.

3. Dynamisches Verhalten & Sequenzablauf

  • Prozess-Bootstrap & Teardown (Lifecycle):
    1. Einstieg (main()): ara::core::Initialize() muss synchron als allererste AP-Aktion aufgerufen werden. Initialisiert Logging-Puffer, IPC-Handles, Tracing und clusterübergreifende Laufzeitstrukturen. Rückgabewert ist typischerweise ara::core::Result<void>.
    2. Regulärer Betrieb: Erst nach erfolgreichem Return von Initialize() dürfen andere funktionale Cluster (ara::com, ara::exec, ara::log, ara::per) instanziiert oder genutzt werden.
    3. Beendigung: Vor Verlassen von main() muss ara::core::Deinitialize() synchron aufgerufen werden. Schließt Ressourcen geordnet; nach Rückkehr ist jeder weitere AP-API-Aufruf undefiniertes Verhalten (UB).
  • Ausnahmezustand & Fatale Fehler (Abort-Pfad):
    1. Auslöser: Verletzung harter Preconditions, unhandled Contracts, expliziter Aufruf via ara::core::Abort(const char* text) oder Auspacken eines fehlerhaften ara::core::Result::Value() ohne Fehlerprüfung.
    2. Handler-Ausführung: Falls über ara::core::SetAbortHandler() ein Handler registriert wurde, wird dieser synchron im Kontext des fehlerhaften Threads aufgerufen (z. B. für Notfall-Flushing von Crash-Metadaten).
    3. Terminierung: Unmittelbarer Systemabbruch ohne C++ Stack Unwinding (std::abort() bzw. OS-Signal SIGABRT).

4. Normative Relevanz & Entwickler-Hinweise

  • C++-Sprachbindung & Namespace:
    • Voll qualifizierte Schnittstellen: ara::core::Initialize(), ara::core::Deinitialize(), ara::core::Abort(), ara::core::SetAbortHandler().
  • API-Vertrag & Nebenläufigkeit:
    • Initialize() und Deinitialize() sind nicht thread-sicher und dürfen ausschließlich sequenziell im Haupt-Thread (main) vor dem Spawnen weiterer Threads ausgeführt werden.
  • Deterministisches Fehlerparadigma (No-Exception Policy):
    • AUTOSAR Adaptive verbietet in sicherheitskritischen Bereichen C++-Exceptions (AUTOSAR C++14 Guideline A15-0-X). Fehler werden regulär über ara::core::Result<T, E> propagiert.
    • Nicht-behebbare Zustände münden zwingend in ara::core::Abort().
  • Einschränkungen für AbortHandler:
    • Der mit SetAbortHandler() gesetzte Callback darf unter keinen Umständen blockieren, dynamischen Heap-Speicher allozieren oder Exceptions werfen. Er muss reentrant bzw. async-signal-safe ausgelegt sein.

Versionsvergleich KI-generiert · gemini-3.8-flash (via agy)

R24-11 → R25-11 keine inhaltliche Änderung Vorgänger: FIG-2917d524dc7fa392

Keine inhaltlichen Änderungen erkennbar.

Zugeordnete Anforderungen

Diese Angaben zeigt der Versions-Explorer.

Aus dem Dokument extrahierter Text & Kontext

Beschriftungen im Schaubild:

«aapFunctionalCluster» | Core | «aapAPI,aapNativeInterf... | Core | + Deinitialize() + Initialize() | «aapAPI,aapNativeInterface» | Core | + Abort() + SetAbortHandler()

Vorkommen in AUTOSAR-Releases (1)

Release Dokument Seite Nr. Bildunterschrift im Dokument
R25-11 AUTOSAR_AP_EXP_SWArchitecture S. 60 9.18 Figure 9.18: Interfaces of Core