Figure 9.6: Overview of Core

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Klassendiagramm / Schnittstellen-Realisierungsdiagramm (Component Realization).
• Architektur-Kontext: AUTOSAR Adaptive Platform (ARA – AUTOSAR Runtime for Adaptive Applications), Functional Cluster Core (ara::core).
• Funktionale Einordnung: Das Diagramm spezifiziert die basalen Lebenszyklus- und Prozesskontroll-Schnittstellen, die der Funktionscluster Core gegenüber Adaptive Applications bereitstellt. Core bildet das fundamentale Basismodul zur Initialisierung der ARA-Laufzeitumgebung innerhalb eines POSIX-OS-Prozesses sowie zur deterministischen Terminierung im Fehlerfall.

2. Komponenten, Entitäten & Schnittstellen

• Komponente:
  • Core: Zentrale Adaptive-Plattform-Komponente (gekennzeichnet durch das UML-Komponenten-Symbol). Implementiert die Basisinfrastruktur und Core-Typen (ara::core).
• Schnittstellen (Stereotyp «applicationInterface»):
  • Runtime Controller: Definiert den prozesslokalen Initialisierungslebenszyklus der Plattform.
    • + Initialize(): Initialisiert die zugrunde liegende ARA-Laufzeitumgebung und interne Plattformstrukturen.
    • + Deinitialize(): Gibt allokierte Plattformressourcen frei und fährt die Plattform-Subsysteme deterministisch herunter.
  • Process Termination: Definiert Mechanismen für den sofortigen, unkonditionierten Prozessabbruch bei fatalen Fehlern.
    • + Abort(): Löst die unmittelbare Beendigung des laufenden Prozesses aus (Notaus-/Panic-Mechanismus).
    • + SetAbortHandler(): Registriert eine benutzerdefinierte Hook-Funktion (AbortHandler), die vor dem endgültigen Prozessende ausgeführt wird.
• Beziehungen:
  • Gestrichelte Pfeile mit geschlossener, nicht ausgefüllter Spitze (UML-Interface-Realization): Die Komponente Core realisiert/implementiert sowohl Runtime Controller als auch Process Termination.

3. Dynamisches Verhalten & Sequenzablauf

• Initialisierungspfad (Normalbetrieb):
  1. Prozessstart (main()-Eintritt der Adaptive Application).
  2. Synchrone Ausführung von ara::core::Initialize().
  3. Erst nach erfolgreicher Rückkehr dürfen funktionale Cluster-APIs (z. B. ara::com, ara::exec, ara::log) aufgerufen werden.
• Deinitialisierungspfad (Regulärer Shutdown):
  1. Applikationslogik beendet funktionale Tätigkeiten (z. B. getriggert via Execution Management State Client / POSIX Signals wie SIGTERM).
  2. Alle Kommunikations- und Verarbeitungsinstanzen werden zerstört.
  3. Unmittelbar vor Rückkehr aus main(): Synchroner Aufruf von ara::core::Deinitialize().
• Abnormaler Pfad (Fehlerzustand / Termination):
  1. Optional während des Starts: Registrierung eines Callbacks via ara::core::SetAbortHandler().
  2. Tritt ein nicht behebbarer Fehler auf (Invariantenbruch, fehlgeschlagene Preconditions, ara::core::Abort() direkt aufgerufen oder via ara::core::Result::Value() auf fehlerhaftem Objekt):
  3. Core ruft den registrierten AbortHandler synchron auf.
  4. Unmittelbarer Prozessabbruch (ohne reguläres Stack Unwinding; POSIX std::abort() bzw. SIGABRT).

4. Normative Relevanz & Entwickler-Hinweise

• Spezifikationsbezug: Normiert in AUTOSAR_SWS_AdaptiveCore.
• Ausführungssemantik & Thread-Safety:
  • Initialize() und Deinitialize() sind sequenziell und nicht threadsicher; sie dürfen prozessweit genau einmal und strikt im Kontext des Haupt-Threads (main) aufgerufen werden.
  • Fehlendes Initialize() vor dem Zugriff auf beliebige ARA-Dienste führt zu undefiniertem Verhalten (UB).
• Restriktionen für den AbortHandler:
  • Der via SetAbortHandler() übergebene Handler darf nicht blockieren, keine weiteren Exceptions werfen und keine dynamischen Heap-Allokationen vornehmen (Gefahr von Deadlocks in korrumpierten Speicherzuständen). Er dient ausschließlich für minimales Notfall-Logging oder das synchrone Setzen von Crash-Metadaten vor der Terminierung.
• Paradigma: Unterstützt die Exception-freie C++14/17-Entwicklungsleitlinie von AUTOSAR Adaptive (Ersetzt Exceptions durch ara::core::Result und terminiert bei schwerwiegenden Vertragsverletzungen deterministisch via Abort()).