Figure 5.2: Interfaces required by Operating System Interface

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Komponentendiagramm / Schnittstellen-Abhängigkeitsdiagramm.
• Funktionale Einordnung & Zweck: Das Diagramm spezifiziert die architekturelle Schnittstellenabhängigkeit des Functional Clusters Operating System Interface (OSI) gemäß AUTOSAR_AP_SWS_OperatingSystemInterface (Kapitel 5.2, R23-11/R24-11). Es dokumentiert die strikt vertikale Bindung nach unten: Der Cluster hat keinerlei funktionale Anforderungen oder Abhängigkeiten zu anderen Functional Clustern der AUTOSAR Adaptive Platform (vgl. Tabelle 5.2: „No required interfaces“), sondern stützt sich ausschließlich auf die standardisierten Low-Level-Dienste des unterlagernden Host-Betriebssystems.

2. Komponenten, Entitäten & Schnittstellen

• Komponenten & Entitäten:
  • «aapFunctionalCluster» Operating System Interface: Der funktionale Cluster der AUTOSAR Adaptive Platform (AP), der das Betriebssystem-Interface normiert und standardisierte Schnittstellen für Prozesse und Plattform bereitstellt.
  • Operating System: Das zugrunde liegende Host-Echtzeitbetriebssystem (RTOS / OS-Kernel, z. B. Linux mit PREEMPT_RT, QNX Neutrino, PikeOS, VxWorks).
  • «aapInternal» Single-Process POSIX API: Ein internes Schnittstellenelement der Plattformarchitektur. Es repräsentiert die normative Teilmenge von POSIX-Systemaufrufen (orientiert an IEEE Std 1003.13 / Subsets wie PSE51 Single-Process), die innerhalb eines einzelnen Prozesskontexts ausgeführt werden.
• Beziehungen:
  • Nutzungsbeziehung («use» Dependency): Gerichtete gestrichelte Pfeillinie von Operating System Interface auf Single-Process POSIX API. Der Cluster konsumiert diese Programmierschnittstelle zur Laufzeit.
  • Schnittstellenrealisierung (Interface Realization): Gestrichelte Linie mit geschlossener, nicht ausgefüllter Dreiecksspitze von Operating System zur Schnittstelle Single-Process POSIX API. Das Host-Betriebssystem bzw. dessen C-Runtime-Bibliothek (libc/libpthread) implementiert und exponiert diese API.

3. Dynamisches Verhalten & Sequenzablauf

• Interaktionsmuster: Statisches Strukturmodell ohne sequenzielle Trigger. Zur Laufzeit erfolgt die Interaktion über synchrone In-Process-Funktionsaufrufe (Direct C-APIs / Wrapper) und Trap-/Syscall-Mechanismen in den Kernel-Space.
• Signal- & Fehlerpfade:
  • Das OS signalisiert Status und Fehler über klassische POSIX-Fehlersemantik (Rückgabewert ungleich 0 bzw. -1 mit Setzen von errno im Thread-Local-Storage).
  • Bei blockierenden OS-Primitives (z. B. Semaphoren, Mutexe, Condvars) erfolgt die Thread-Zustandsverwaltung direkt durch den OS-Scheduler ohne Beteiligung übergeordneter AP-Cluster.
• Autonomie: Da keine horizontalen Callbacks oder Inter-Cluster-Kommunikationspfade (z. B. zu Execution Management oder Diagnostics) im Diagramm verankert sind, agiert das Subsystem rein reaktiv auf API-Aufrufe innerhalb des Applikations-/Prozess-Threads.

4. Normative Relevanz & Entwickler-Hinweise

• OS-/BSP-Integratoren & Plattform-Entwickler:
  • Das gewählte RTOS muss mindestens das in der Spezifikation definierte POSIX-Subset vollständig und echtzeitfähig implementieren (u. a. POSIX-Threads pthread_*, Clocks/Timers clock_*, Signals, Scheduling-Attribute SCHED_FIFO/SCHED_RR).
  • Die Realisierung der Single-Process POSIX API erfordert Prozessisolation (Memory Protection via MMU); APIs, die Multi-Process-Management erzwingen (wie unkontrolliertes fork()/exec() im unprivilegierten Applikationskontext), sind in diesem Scope restriktiert.
• Stack- & Applikations-Entwickler:
  • Keine Cluster-Kopplung: Der OSI-Stack kann autark gebootet und initialisiert werden, ohne dass andere Adaptive-Services laufen müssen (kein Deadlock-Potential bei Initialisierungsreihenfolgen).
  • API-Vertrag: Entwickler innerhalb des Single-Process-Modells dürfen sich ausschließlich auf die genormten POSIX-Signaturen verlassen; proprietäre OS-Erweiterungen (nicht-standardisierte Syscalls) verletzen die Konformität und Portabilität von Adaptive Applications.