Figure 7.1: Types of Applications

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: Konzeptionelle 2×2-Klassifikationsmatrix (Taxonomie-/Architektur-Quadrantendiagramm).
• Funktionale Einordnung: AUTOSAR Adaptive Platform (AP), Execution Management (EM) & Operating System Interface (OSI). Das Diagramm systematisiert alle auf einer AP-Machine instanziierten Prozesse anhand zweier orthogonaler architektonischer Dimensionen:
  • Vertikale Achse (Privilegien- & Abstraktionsebene): platform/machine vs. user level.
  • Horizontale Achse (Standardisierungs- & Portabilitätsgrad): OS/hardware specific implementation vs. fully AUTOSAR compliant.
• Technischer Zweck: Definition des Begriffs Adaptive Application (AA) im engeren normativen Sinn (oberer rechter Quadrant) gegenüber Plattform-Diensten, Functional Clusters und hardware-/OS-spezifischen Prozessen zur Festlegung von API-Verträgen (ARA vs. OS/POSIX/HW-APIs) und Portabilitätsgarantien.

2. Komponenten, Entitäten & Schnittstellen

Die Matrix unterteilt den generischen Prozessraum (Application) in vier distinkte Kategorien:

1. Portable Adaptive Application (AA – Quadrant oben rechts, grün hervorgehoben):
   • Charakteristik: user level + fully AUTOSAR compliant.
   • Schnittstellen: Verwendet ausschließlich das AUTOSAR Runtime for Adaptive Applications (ARA) API (z. B. ara::com, ara::exec, ara::log, ara::per) sowie das strikt definierte POSIX-Subset (PSE51/Minimal POSIX gemäß SWS_OSI_01300).
   • Portabilität: Vollständig quellcode- und verhaltensportabel über konforme Adaptive Platforms und POSIX-OS-Implementierungen hinweg.
2. Non-portable / Hardware-dependent User Application (Quadrant oben links):
   • Charakteristik: user level + OS/hardware specific implementation.
   • Schnittstellen: Läuft im Userspace, greift jedoch an ARA vorbei direkt auf OS-spezifische Syscalls, herstellerspezifische Gerätetreiber (/dev/*), Beschleuniger-APIs (z. B. proprietäres GPU/NPU-Runtime) oder Kernel-Module zu.
   • Portabilität: Nicht portabel; gebunden an konkretes OS, BSP und Ziel-Hardware.
3. Reusable Platform Application (Quadrant unten rechts):
   • Charakteristik: platform/machine + fully AUTOSAR compliant.
   • Schnittstellen: Prozess mit Plattform-/Systemprivilegien, der standardisierte AUTOSAR-Schnittstellen implementiert oder konsumiert, ohne direkte Abhängigkeit von HW-/OS-Interna (z. B. standardisierte Plattform-Zusatzdienste oder über ARA gekapselte Systemdienste).
   • Portabilität: Über verschiedene Machine-Architekturen hinweg wiederverwendbar, sofern die Plattform-Privilegien und ARA-Schnittstellen bereitstehen.
4. Typical Functional Cluster Application (Quadrant unten links):
   • Charakteristik: platform/machine + OS/hardware specific implementation.
   • Schnittstellen: Kernbestandteil der Adaptive Platform Foundation (z. B. Execution Management, Teile des Operating System, Machine State Management, HW-nahe Daemons/Treiber-Manager).
   • Portabilität: System- und plattformspezifisch; implementiert die funktionale AUTOSAR-Spezifikation unter direkter Nutzung nativer OS-Primitive (POSIX-Erweiterungen, IPC, Cgroups, Scheduling-Policies, HW-Timer).

3. Dynamisches Verhalten & Sequenzablauf (falls zutreffend)

Als statische Klassifikationsmatrix besitzt das Schaubild keinen Sequenzablauf; das dynamische Prozessverhalten unterliegt den EM-Lifecycle-Regeln:

• Instanziierung & Überwachung: Das Execution Management (unten links) startet, terminiert und überwacht sämtliche Prozesse aller vier Quadranten deterministisch basierend auf dem Manifest (Machine Manifest, Execution Manifest).
• Zustandsübergänge: EM überführt Applikationen anhand von Function Groups und States (Running, Terminating) und verarbeitet State-Reports via ara::exec::ApplicationClient::ReportExecutionState().
• Execution Environment: Prozesse im rechten Bereich unterliegen strikten Sandbox-/Constraint-Vorgaben; Prozesse im linken Bereich besitzen erweiterte Zugriffsrechte (z. B. Zugriff auf /dev, POSIX Real-Time Signals, Raw Sockets).

4. Normative Relevanz & Entwickler-Hinweise

• Normative Einschränkung für Adaptive Applications (SWS_OSI_01300):
  • Eine vollwertige Adaptive Application darf ausschließlich Schnittstellen nutzen, die durch AUTOSAR AP standardisiert sind (ARA-Interfaces und spezifiziertes POSIX-Subset gemäß PSE51).
  • Direkte Aufrufe von glibc/OS-spezifischen Funktionen, die das PSE51-Profil überschreiten (z. B. ungekapselte Thread-Affinitäten, Forking, proprietäre Shared-Memory-IPC), degradieren eine AA unmittelbar in die Kategorie Non-portable user Application.
• Auswirkungen auf Applikations-Entwickler:
  • Fokus auf den grünen Quadranten: Vermeidung jeglicher direkter OS-/Syscall-Abhängigkeiten zur Gewährleistung von CI/CD-Host-Simulation, SIL-Testbarkeit und Prozessor-Architektur-Unabhängigkeit (z. B. x86_64 vs. AArch64).
  • Hardware-Zugriffe (z. B. Sensor-/Aktor-Direktanbindung) müssen über dedizierte Treiber-Services oder Plattform-Adapter isoliert werden.
• Auswirkungen auf Stack-/BSP-Entwickler (Functional Clusters):
  • Entwickler von AP-Stacks (EM, SM, NM, etc.) agieren primär im unteren linken Quadranten und müssen das Mapping standardisierter Spezifikationsanforderungen auf das konkrete RTOS (z. B. Linux mit PREEMPT_RT, QNX Neutrino, PikeOS) gewährleisten.