Figure 9.24: Interfaces required by Operating System Interface

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Komponentendiagramm / Schnittstellen-Abhängigkeitsdiagramm (Strukturdiagramm).
• Architektur-Kontext: AUTOSAR Adaptive Platform (AP), Spezifikation AUTOSAR_EXP_SWArchitecture (Release R21-11).
• Technischer Zweck: Definition der strukturellen Kopplung zwischen dem Adaptive-Platform-Basisfunktionsblock Operating System Interface und dem zugrundeliegenden Host-Betriebssystem über eine standardisierte, restriktive POSIX-Systemschnittstelle (Single-Process POSIX API).

2. Komponenten, Entitäten & Schnittstellen

• Entitäten & Stereotypen:
  • «aapFunctionalCluster» Operating System Interface: Repräsentiert den standardisierten funktionalen Cluster der Adaptive Platform Foundation, der OS-Abstraktionen und Plattformdienste kapselt.
  • «aapInternal» Single-Process POSIX API: Plattform-interne Schnittstelle (Interface). Definiert das von AUTOSAR AP vorgegebene POSIX-Subset (abgeleitet aus IEEE 1003.13 PSE51 mit Anpassungen/Restriktionen für Threading, Timing und Speicherverwaltung).
  • Operating System: Das reale Träger-Betriebssystem bzw. RTOS (z. B. Linux, QNX Neutrino, PikeOS, VxWorks).
• Beziehungen:
  • Realization (Operating System $\dashrightarrow \triangle$ Single-Process POSIX API): Das Betriebssystem implementiert die Spezifikation der Single-Process POSIX API verbindlich.
  • Usage-Dependency (Operating System Interface ⇢ «use» → Single-Process POSIX API): Der Functional Cluster konsumiert ausschließlich die über die Single-Process POSIX API definierten Systemaufrufe; ein Zugriff auf nicht-standardisierte OS-Kernel-Schnittstellen ist architektonisch untersagt.

3. Dynamisches Verhalten & Sequenzablauf

• Diagrammcharakter: Rein statisches Architekturmodell; kein dynamischer Sequenzablauf spezifiziert.
• Laufzeit-Interaktion:
  • Funktionsaufrufe erfolgen als direkte, synchrone C/POSIX-System- und Bibliotheksaufrufe (z. B. pthread_*, clock_gettime, sigaction) aus dem Prozesskontext des Clusters in das OS.
  • Fehlerbehandlung erfolgt nach POSIX-Standard über Rückgabecodes und errno (bzw. gekapselt in ara::core::Result), nicht über Classic-typische Mechanismen wie DET/DEM.

4. Normative Relevanz & Entwickler-Hinweise

• OS- und BSP-Integratoren:
  • Das eingesetzte RTOS muss die Konformität zum Single-Process-POSIX-Profil (PSE51-Subset gemäß AUTOSAR_SWS_OperatingSystemInterface) garantieren.
  • Multi-Process-Funktionalitäten (z. B. fork(), Inter-Process-Shared-Memory) sind innerhalb dieses Schnittstellenvertrags explizit eingeschränkt oder untersagt.
• Stack- & Applikations-Entwickler:
  • Der Functional Cluster Operating System Interface stellt die Portabilität der Adaptive Platform über unterschiedliche POSIX-kompatible POSIX-OS-Implementierungen sicher.
  • Direkte Aufrufe proprietärer Treiber- oder Kernel-APIs am POSIX-Standard vorbei brechen die Plattformunabhängigkeit und verletzen den AUTOSAR-Adaptive-Konformitätsvertrag.