Figure 7.15: Memory Usage.

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Strukturelles Speichermodell / Prozess-Adressraum-Layout (Memory-Accounting- und IPC-Interaktionsmodell).
• Architektur-Kontext: AUTOSAR Adaptive Platform (AP), Functional Cluster Execution Management (EM), Bereich Resource Management / Resource Limitation (Referenzen: RS_EM_00005, SWS_EM_02108; gültig für R22-11, R24-11, R25-11).
• Technischer Zweck: Definition der normativen Bilanzierungsgrenzen (Accounting Scope) für die Speicherüberwachung und -begrenzung von Adaptive-Prozessen. Das Diagramm stellt klar, welche Speicherbereiche direkt zum überwachten Ressourcenverbrauch eines Prozesses zählen und welche sekundären/indirekten Allokationen in Drittprozessen explizit ausgeschlossen sind.

2. Komponenten, Entitäten & Schnittstellen

• <<Process>> Process A, which should be limited:
  • Nutzer- bzw. Funktionsapplikation, deren Speicherverbrauch via Execution Management (Execution Manifest / ResourceGroup) limitiert werden soll.
  • Umfasster Adressraum (Address Space), der die bilanzierte Memory Usage bildet:
    • Text/Code: Ausführbare Programmsegmente (Read-Only/Executable).
    • Data: Initialisierte globale und statische Variablen.
    • BSS: Null-initialisierte globale und statische Variablen.
    • Heap: Dynamisch allokierter Heapspeicher (malloc, new).
    • Main Thread Stack & Stack_1 … Stack_n: Speicherbereiche aller Threads des Prozesses.
• <<Process>> Process B, which provides basic functionality (e.g. sockets, filesystem, …):
  • Plattform- bzw. Betriebssystemdienst (z. B. Daemon für Sockets, Dateisysteme, Treiberabstraktionen oder IPC-Router).
  • Besitzt einen identisch strukturierten eigenen Adressraum (Text/Code, Data, BSS, Heap, Thread-Stacks).
  • Beherbergt im eigenen Heap die Entität Process A Maintenance Data (Metadaten, Dateideskriptoren, Kernel-/Socket-Puffer, Verbindungstabellen, die exklusiv für Process A verwaltet werden).
• Schnittstellen & Relationen:
  • <<use>>, e.g. open() or socket() via IPC: Gerichtete Nutzungsbeziehung; Process A konsumiert Services von Process B über Inter-Process Communication (IPC / POSIX System Calls).
  • Memory Usage (Klammerung Process A): Fasst ausschließlich alle Segmente innerhalb des virtuellen Adressraums von Process A zusammen.
  • Rote Relation (Does not contain effects on other processes): Normative Abgrenzung; zeigt an, dass Process A Maintenance Data in Process B nicht zum bilanzierten Speicherbudget von Process A gerechnet wird.

3. Dynamisches Verhalten & Sequenzablauf

1. Dienstaufruf (IPC): Process A setzt synchrone oder asynchrone API-Calls ab (z. B. open(), socket(), Buffer-Requests), die über Betriebssystem-Sockets/IPC an Process B übermittelt werden.
2. Indirekte Allokation: Process B allokiert auf Anfrage im eigenen Adressraum (typischerweise im Heap) Speicher für Session- und Kontextdaten (Process A Maintenance Data).
3. Ressourcen-Monitoring:
   • Das Execution Management (bzw. das unterlagerte OS über z. B. Linux cgroups / memory.max oder QNX Memory Domains) überwacht strikt die physischen/virtuellen Seiten des Adressraums von Process A.
   • Der Speicheranstieg in Process B bleibt für das Quota von Process A unsichtbar.
4. Schwellwertverletzung / Abbruch:
   • Überschreitet Process A sein konfiguriertes Limit im eigenen Adressraum, greifen die im Manifest definierten Aktionen (z. B. OOM-Handling, Termination durch SIGKILL, Statusmeldung an EM/Platform Health Management).
   • Ein Ausufern der Process A Maintenance Data in Process B löst keinen Fehlerzustand in Process A aus, sondern gefährdet primär das Speicherbudget von Process B.

4. Normative Relevanz & Entwickler-Hinweise

• Konfigurationsgrenzen (SWS_EM_02108): Das im Execution Manifest per ResourceGroup / ResourceLimitation zugewiesene Speicherlimit beschränkt ausschließlich den residenten Adressraum des Zielprozesses (RSS / Virtual Memory).
• Implikationen für Plattform- & Service-Entwickler (Process B):
  • DoS-Schutz / Quota Enforcement auf Applikationsebene: Da EM Speicherallokationen durch Drittprozesse nicht rückwirkend Process A anlasten kann, müssen Server-Daemons (Process B) eigene Schutzmechanismen (z. B. maximale Anzahl Deskriptoren/Sockets pro Client, Pufferlimits) implementieren, um Erschöpfung des eigenen Heaps zu verhindern.
• Implikationen für Applikations-Entwickler (Process A):
  • Budgetierung: Zur Einhaltung der Ressourcenbudgets müssen Entwickler Code-, BSS-, Data-, Heap- sowie alle Thread-Stack-Größen (pthread_attr_setstacksize) dimensionieren.
  • Pufferallokation: Das Auslagern von Datenhaltung in Shared Services entlastet nominell das eigene Speicherbudget im EM-Monitoring, verlagert jedoch die Systemkomplexität auf IPC-Durchsatz und Plattformstabilität.