Figure 9.20: Interfaces defined by Operating System Interface

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Komponenten- und Schnittstellendiagramm (statisches Strukturmodell).
• Funktionale Einordnung: Verortet das Operating System Interface (OSI) als funktionalen Cluster der AUTOSAR Adaptive Platform (AP) Foundation und definiert dessen Schnittstellenbeziehung zur Adaptive Application (AA).
• Technischer Zweck: Dokumentiert die architektonische Sonderstellung des OSI-Clusters: Im Gegensatz zu übrigen Functional Clusters (z. B. ara::com, ara::exec), die standardisierte C++-Klassen im ara::*-Namespace definieren, exponiert das OSI native Betriebssystem-Schnittstellen («aapNativeInterface»), primär ein definiertes POSIX-Subset (PSE51/POSIX.13 mit Erweiterungen) nebst C/C++-Standardbibliotheks-Laufzeit.

2. Komponenten, Entitäten & Schnittstellen

• Entitäten & Komponenten:
  • Adaptive Application: UML-Komponente (Component), repräsentiert die auf der AP ausgeführte Nutzerapplikation (Instanz eines oder mehrerer POSIX-Prozesse im User Space).
  • «aapFunctionalCluster» Operating System Interface: Plattform-Komponente der AP Foundation; kapselt und standardisiert das zugrundeliegende Host-Betriebssystem (z. B. QNX, Linux/PREEMPT_RT, INTEGRITY, PikeOS).
  • «aapAPI,aapNativeInterface» OperatingSystemInterface: Klassifikator für die Programmierschnittstelle. Die Stereotypenkombination kennzeichnet ein natives, plattformnahes API (POSIX C-APIs, Libc/Libpthread) im Kontrast zu generierten oder objektorientierten ara::-Klassen.
• Beziehungen & Abhängigkeiten:
  • Adaptive Application $\xrightarrow{\text{«use»}}$ OperatingSystemInterface: Nutzungsabhängigkeit (Usage). Die Applikation greift direkt auf die deklarierten OS-Schnittstellen zu.
  • Operating System Interface $\mathbin{-\!\!-\!\vartriangle}$ OperatingSystemInterface: Schnittstellenrealisierung (Realization). Der Functional Cluster stellt die definierten OS-Primitiven zur Verfügung.

3. Dynamisches Verhalten & Sequenzablauf (falls zutreffend)

• Statisches Strukturdiagramm: Kein zeitlicher Ablauf oder Nachrichtenaustausch explizit modelliert.
• Laufzeit-Interaktionsmodell:
  • Direkte, synchrone Bibliotheks- und Systemaufrufe (Syscalls via Trap in den Kernel-Space bzw. POSIX-Wrapper) aus dem Thread-Kontext der Adaptive Application (z. B. clock_gettime, pthread_mutex_lock).
  • Keine Vermittlung über IPC-Sockets oder Middleware-Daemons für Basisfunktionen (Threading, Synchronisation, Clocks).
  • Asynchrone Ereignisse (z. B. POSIX-Timer, Signale) werden betriebssystemseitig direkt an die registrierten Signal-/Event-Handler des Applikationsprozesses zugestellt.

4. Normative Relevanz & Entwickler-Hinweise

• Einschränkung des POSIX-Umfangs: Entwickler dürfen nicht das unbeschränkte API des Host-Kernels nutzen. Verbindlich ist das spezifizierte AUTOSAR-POSIX-Subset (angelehnt an IEEE 1003.13 PSE51). Nicht konforme Aufrufe (z. B. unkontrolliertes fork(), dynamisches Laden via dlopen() im laufenden Betrieb, unvalidierte IPC-Mechanismen) verletzen die Safety-/Determinismus-Garantien.
• Interaktion mit dem Execution Management (EM): Thread-Erzeugung (pthread_create), Scheduling-Attribute (SCHED_FIFO, SCHED_RR), Prioritäten und CPU-Affinitäten müssen den Restriktionen des Execution Manifests entsprechen; das EM überwacht Budgets und Execution States.
• Portabilität & Safety: Die Abstraktion über «aapNativeInterface» entkoppelt die Applikation von proprietären Kernel-Extensions des Tier-1/SoC-Lieferanten und gewährleistet Portabilität über verschiedene ASIL-zertifizierte Microkernel und RTOS-Implementierungen.