Figure 7.1: Process - Task/Thread Model

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Strukturelles Hierarchie- und Ausführungsmodell (Process-Task/Thread Tree).
• Technischer Zweck & Einordnung: Spezifikation des Ausführungs- und Abstraktionsmodells im AUTOSAR Adaptive Platform (AP) Operating System Interface (ara::exec / OS). Das Diagramm definiert das fundamentale Mapping von OS-Instanzen auf geschützte Prozesse (Processes) sowie die Kapselung von leichtgewichtigen Ausführungseinheiten (Tasks/Threads, POSIX-Threads pthread) innerhalb dieser Prozesse.

2. Komponenten, Entitäten & Schnittstellen

• Entitäten:
  • OS (Operating System): Unterlagerter POSIX-konformer Echtzeit-Kernel der Adaptive Platform.
  • Process (Process 1, Process 3, Process 5, Process 10): Unabhängige Betriebssystem-Prozessinstanzen. Repräsentieren getrennte virtuelle Adressräume (MMU-Isolation, Ressourcenkontingente, User/Group-IDs).
  • Task / Thread (Task 1 … Task 10): Schedulbare Ausführungseinheiten (Threads) innerhalb des virtuellen Adressraums eines Prozesses.
• Beziehungen & Kardinalitäten:
  • OS → Process: 1 : N (Relation create Process). Das OS hostet und verwaltet mehrere isolierte Prozesse.
  • Process → Task/Thread: 1 : N bzw. 1 : 1 (Relation create Thread).
    • Multithreaded: Process 1 kapselt 5 Threads (Task 1, 2, 4, 6, 7); Process 5 kapselt 3 Threads (Task 5, 8, 9).
    • Single-Threaded: Process 3 (Task 3) und Process 10 (Task 10) kapseln jeweils genau einen Thread (Initial-/Main-Thread).
• Kopplung & Adressierung:
  • Threads innerhalb desselben Prozesses teilen sich globalen Speicher, Heap und Dateideskriptoren.
  • Prozesse sind gegeneinander vollständig memory-isoliert.

3. Dynamisches Verhalten & Sequenzablauf

1. Prozessinitialisierung (create Process):
   • Das OS bzw. das Execution Management (ara::exec) instanziiert Prozesse typischerweise via POSIX-Mechanismen (z. B. posix_spawn() / Loader-Instanziierung; fork() ist in sicherheitskritischen AP-POSIX-Profilen wie PSE51 restriktiert/untersagt).
2. Thread-Erzeugung (create Thread):
   • Nach Initialisierung des initialen Threads durch das OS erzeugt der jeweilige Prozess bei Bedarf weitere Threads via POSIX-Threading-API (pthread_create()).
3. Scheduling & Nebenläufigkeit:
   • Jeder Task wird vom OS-Scheduler als eigene Scheduling-Entity behandelt (präemptives Echtzeit-Scheduling, z. B. SCHED_FIFO oder SCHED_RR mit zugeordneter Priorität).
4. Synchronisation & Interprozesskommunikation:
   • Prozessintern: Synchronisation über pthread_mutex_*, pthread_cond_* oder atomare C++11/14/17-Primitive.
   • Prozessübergreifend: Kommunikation erfordert explizite IPC bzw. das AUTOSAR-Kommunikations-Framework (ara::com via Shared Memory oder Socket-Bindings).

4. Normative Relevanz & Entwickler-Hinweise

• POSIX-Schnittstellenprofil (PSE51/PSE52): Entwickler greifen für Threading auf standardisierte POSIX-C-APIs oder standardkonforme C++-Threading-Klassen (std::thread) zu, welche vom unterlagerten AP-OS unterstützt werden müssen.
• Konfiguration via Execution Manifest:
  • Prozessinstanziierung, CPU-Affinität (Core Pinning), Resource Groups, Scheduling-Policies (SCHED_FIFO, etc.) und Basis-Prioritäten werden deklarativ im Execution Manifest hinterlegt und durch ara::exec zur Startup-Phase umgesetzt.
• Safety & Determinismus (ISO 26262):
  • Dynamische Thread-Erzeugung zur Laufzeit nach der Startphase verletzt häufig deterministische Safety-Anforderungen. Thread-Pools und Task-Instanziierungen sollten in der Initialisierungsphase (kRunning) abgeschlossen sein.
  • Stack-Größen (pthread_attr_setstacksize) müssen zur Vermeidung von Stack-Overflows applikationsspezifisch vorkonfiguriert und überwacht werden.