Figure 4.3: Minimal state machine of a task

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Zustandsdiagramm (State Machine Diagram) nach AUTOSAR-Metamodell-Konvention zur Spezifikation des minimalen Task-Lebenszyklus.
• Architektur-Kontext: Definiert im AUTOSAR AP Technical Report on Operating System Tracing Interface (AUTOSAR_AP_TR_OperatingSystemTracingInterface, Document ID 1083, R23-11; referenziert via RS_OSI_00210).
• Funktionale Einordnung: Dient als normative Referenz-Zustandsmaschine für ARTI (AUTOSAR Run-Time Interface). Sie standardisiert die Trace-Punkte und Statusübergänge des OS-Schedulers auf der Adaptive Platform (POSIX-/RTOS-Ebene), um Scheduling-Vorgänge deterministisch für externe Timing- und Profiling-Tools observierbar zu machen.

2. Komponenten, Entitäten & Schnittstellen

• Entität:
  • Task: Kleinste schedulbare Ausführungseinheit des Betriebssystems (im Kontext der Adaptive Platform typischerweise ein POSIX-Thread/OS-Thread).
• Zustände (States & Pseudo-States):
  • Non-existent (Initialer Pseudozustand): Task ist dem Scheduler noch nicht bekannt bzw. Ressourcen sind nicht allokiert.
  • Ready: Task ist lauffähig, befindet sich in der Run-Queue des Schedulers und wartet auf CPU-Zuteilung.
  • Running: Task wird aktiv auf einem Prozessorkern ausgeführt.
  • Waiting: Task ist blockiert (wartet auf Synchronisationsobjekte, Events, I/O, Timer oder fremde Threads); nicht schedulbar.
  • Terminated (Endzustand): Task-Ausführung ist abgeschlossen, Deallokation der Thread-Ressourcen eingeleitet.
• Trace-Ereignisse / Trigger (ARTI-Schnittstellenpunkte):
  • Create, Schedule, Preempt, Wait, Release, Terminate.

3. Dynamisches Verhalten & Sequenzablauf

• Erzeugung & Einreihung:
  • Non-existent → Ready über Trigger Create: Task-Erzeugung (z. B. pthread_create()). Der Task wird initialisiert und direkt in die Ready-Queue eingereiht.
• Scheduling & Verdrängung (Hot-Path):
  • Ready → Running über Trigger Schedule: Der OS-Scheduler selektiert den Task und vollzieht den Context-Switch-In.
  • Running → Ready über Trigger Preempt: Verdrängung durch einen höherprioren Task oder Ablauf der Time-Slice-Periode (Context-Switch-Out).
  • Running → Running über Trigger Schedule (Self-Loop): Re-Scheduling auf demselben Core (z. B. Bestätigung des Zeitschlitzes, Prioritätsänderung zur Laufzeit oder Yield ohne Task-Wechsel).
• Blockierung & Entsperrung (Synchronisation):
  • Running → Waiting über Trigger Wait: Synchrone Blockade durch Aufruf blockierender Primitiven (z. B. Mutex, Semaphor, Condition Variable, Message Queue oder Sleep).
  • Waiting → Ready über Trigger Release: Asynchrones oder synchrones Erfüllen der Wartebedingung (Signal, Event, Semaphor-Freigabe). Wichtig: Kein direkter Übergang nach Running; der Task muss stets über Ready neu disponiert werden.
• Beendigung:
  • Running → Terminated über Trigger Terminate: Beendigung des Threads (z. B. pthread_exit() oder reguläres Verlassen der Startroutine).

4. Normative Relevanz & Entwickler-Hinweise

• ARTI-Adapter-Implementierung:
  • Betriebssystem- und Adapter-Entwickler müssen native Kernel- bzw. POSIX-Hooks strikt auf diesen Zustandsautomaten abbilden.
  • Ungültige Übergänge (z. B. Waiting → Running ohne dazwischenliegendes Release/Schedule) verletzen die ARTI-Konformität und führen zu Inkonsistenzen in Analyse-Tools (z. B. fehlerhafte Berechnungen der CPU-Last oder Blockadezeiten).
• Abstraktion proprietärer RTOS-Zustände:
  • Das Modell stellt die minimale gemeinsame Schnittstelle dar (Minimal state machine). Kernel-spezifische Zwischenzustände (z. B. Linux Uninterruptible Sleep/D-State, Zombie, QNX Reply-Blocked) müssen deterministisch in die Zustände Waiting oder Ready projiziert werden.
• Echtzeitanforderungen an Trace-Hooks:
  • Da die Trigger Schedule, Preempt und Release direkt im Dispatcher- und Interrupt-Kontext des Betriebssystems aufgerufen werden, müssen die entsprechenden Trace-Adapter lock-free, reentrant und mit minimalem Ausführungs-Overhead (Zero-Copy) implementiert sein, um Scheduling-Jitter zu verhindern.