Figure 9.20: Interfaces for memory handling

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Klassendiagramm / Schnittstellenspezifikation (Realisierungsdiagramm für C++-APIs).
• Architektur-Kontext: AUTOSAR Adaptive Platform (AP), Functional Cluster Core (ara::core), Release R24-11.
• Technischer Zweck: Spezifikation der standardisierten, nativen C++-Schnittstellen zur deterministischen Speicherverwaltung (PMR – Polymorphic Memory Resources). Das Konzept adaptiert und kapselt Mechanismen gemäß ISO/IEC 14882 (C++17 std::pmr) für sicherheitsrelevante Fahrzeugsoftware, um dynamische Allokationen durch austauschbare, domänenspezifische Speicherressourcen (z. B. statische Puffer, Stack-Allokatoren, Pool-Ressourcen) kontrollierbar und echtzeitfähig zu gestalten.

2. Komponenten, Entitäten & Schnittstellen

Entitäten & Stereotypen

• «aapFunctionalCluster» Core: Der funktionale Kern-Cluster der Adaptive Platform, welcher grundlegende Typen, Fehlerbehandlungsmechanismen und systemnahe Abstraktionen für alle anderen Plattform- und Applikationsprozesse (ara::*) bereitstellt.
• Schnittstellenblöcke mit «aapAPI,aapNativeInterface»: Kennzeichnen native C++-Programmierschnittstellen (Header-basierte APIs unter dem Namespace ara::core bzw. Sub-Namespaces wie ara::core::memory / pmr), die direkt von Applikationen und Stacks eingebunden werden.

Dargestellte Schnittstellen & Methoden

1. Globale / Standard-Ressourcenfabriken (statischer Funktionsblock links):
   • + NewDeleteResource(): Liefert einen Zeiger auf die globale Standard-Speicherressource basierend auf globalem operator new / operator delete.
   • + NullMemoryResource(): Liefert eine Null-Speicherressource zurück; jeder Allokationsversuch führt deterministisch zu einem Speicherfehler (wichtig für Fail-Safe-Szenarien und statische Verifikation).
   • (Unterstrichene Methoden = statische freie C++-Funktionen).
2. Default-Ressourcenmanagement (statischer Funktionsblock Mitte):
   • + GetDefaultResource(): Liest die aktuell prozessweit gesetzte Standard-Speicherressource aus.
   • + SetDefaultResource(): Setzt die globale Default-Speicherressource um (z. B. auf einen deterministischen Fixed-Block- oder Monotonic-Buffer-Allocator während der Initialisierungsphase).
   • (Unterstrichene Methoden = statische freie C++-Funktionen).
3. PolymorphicAllocator (Klasse rechts):
   • Repräsentiert das generische Allokator-Template (ara::core::PolymorphicAllocator<T>), das die typisierten Container der Adaptive Platform (z. B. Vektoren, Maps, Strings) an die zugrundeliegende polymorphe Speicherressource bindet.
   • Methodeninventar:
     • Speicheranforderung/-freigabe: allocate(), allocate_bytes(), allocate_object(), deallocate(), deallocate_bytes(), deallocate_object().
     • Lebenszyklusmanagement: construct(), destroy(), new_object(), delete_object().
     • Metadaten & Container-Propagation: resource() (Liefert Zeiger auf die zugrundeliegende MemoryResource), select_on_container_copy_construction().

Beziehungen

• Interface Realization (gestrichelte Linie mit geschlossener, nicht ausgefüllter Pfeilspitze): Der Functional Cluster Core realisiert und exportiert alle drei nativen Schnittstellenkonfigurationen für darüberliegende Adaptive Applications (AAs) und Plattformdienste.

3. Dynamisches Verhalten & Sequenzablauf

• Initialisierungsphase:
  1. Vor dem Start zeitkritischer Threads/Routinen konfiguriert die Applikation mittels SetDefaultResource() einen deterministischen Allokator (z. B. vorab zugewiesener Heap-Bereich oder Paging-Pool).
  2. Alternativ instanziiert die Applikation einen spezifischen PolymorphicAllocator, der eine dedizierte lokale MemoryResource referenziert.
• Laufzeit-Allokationspfad (Synchron):
  1. Container oder Objekte rufen allocate() / allocate_bytes() auf dem Allokator auf.
  2. Der Allokator delegiert synchron an die hinterlegte polymorphe Ressource (resource()->allocate(...)).
  3. Bei statischen Sicherheitsprüfungen oder im Run-Flat-Modus verhindert NullMemoryResource(), dass unbemerkt dynamischer Heap-Speicher angefordert wird, indem Anfragen sofort deterministisch abgewiesen werden (std::bad_alloc bzw. AUTOSAR-Fehlerbehandlung).
• Destruktionspfad (Synchron):
  • Aufruf von destroy() / delete_object() zerstört Objekte in-place; anschließendes deallocate() gibt den Block an den Puffer zurück, ohne Kernel-Transitions (sofern Nicht-NewDeleteResource).

4. Normative Relevanz & Entwickler-Hinweise

• Echtzeit- und Safety-Restriktionen (ISO 26262 / ASIL-D):
  • Die Verwendung von NewDeleteResource() führt zu unvorhersehbaren Latenzen und Heap-Fragmentierung (Aufruf von System-malloc). Für ASIL-relevante Echtzeitpfade ist dies normativ verboten oder stark reglementiert.
  • Entwickler müssen stattdessen Arena-, Monotonic- oder Pool-Ressourcen über PolymorphicAllocator injizieren.
• ABI- und Typsicherheit:
  • PolymorphicAllocator entkoppelt den Container-Typ vom konkreten Allokations-Mechanismus zur Laufzeit. Verschiedene Container des gleichen Typs (ara::core::Vector<int>) bleiben binär- und typkompatibel zueinander, unabhängig davon, ob sie aus dem Stack oder aus einem geteilten Shared-Memory-Pool allokieren.
• Thread-Sicherheit:
  • Aufrufe von SetDefaultResource() sind nicht thread-sicher und dürfen ausschließlich sequentiell während der Initialisierungsphase des Prozesses vor dem Spawnen paralleler Threads ausgeführt werden.
• NullMemoryResource als Audit-Tool:
  • Vor dem Eintritt in die zyklische Ausführungsschleife kann SetDefaultResource(NullMemoryResource()) gesetzt werden, um versehentliche dynamische Allokationen im Produktivbetrieb hart zur Laufzeit abzufangen.