Figure 4.5: Applications

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: Konzeptionelle Klassifikationsmatrix (2 × 2-Taxonomie-Portfolio).
• Architektur-Kontext: AUTOSAR Adaptive Platform (AP), System- und Prozessmodell gemäß AUTOSAR_AP_EXP_PlatformDesign (Kapitel 4.1 Application launch and shutdown).
• Funktionale Einordnung: Das Diagramm systematisiert das Spektrum aller ausführbaren Entitäten („Applications“) auf einem AP-Knoten. Aus Sicht des Execution Management (EM) ist jede dieser Entitäten – sowohl anwenderspezifische Applikationen als auch plattforminterne Functional Clusters (FCs) – ein eigenständiger Betriebssystem-Prozess mit einheitlichem Lifecycle-Management (mit Ausnahme des EM selbst als Init-/Bootstrap-Prozess). Die Matrix definiert die architektonischen Grenzen hinsichtlich Abstraktionsebene (Y-Achse) und Portabilität bzw. Schnittstellenkonformität (X-Achse).

2. Komponenten, Entitäten & Schnittstellen

Achsendefinition

• Vertikale Achse (Funktionale Domäne / Ebene):
  • user level: Oberhalb der Plattform angesiedelte Applikationslogik (OEM-/Tier-1-Funktionen).
  • platform/machine: Infrastruktur-, Plattform- und Systemdienste der AUTOSAR Adaptive Platform.
• Horizontale Achse (Implementierungs- & Schnittstellengrad):
  • OS/hardware specific implementation: Direkte Abhängigkeit von nativen Betriebssystem-APIs (POSIX PSE51, Linux/QNX System Calls), Kernel-Modulen, Treibern oder Zielhardware.
  • fully AUTOSAR compliant: Ausschließliche Nutzung standardisierter ARA-Schnittstellen (ara::*) und C++ Standard Library.

Quadranten und Entitäten

1. Portable Adaptive Application (Oben-Rechts, grün hervorgehoben):
   • Klassifikation: user level $\land$ fully AUTOSAR compliant.
   • Architekturrolle: Standardkonforme Adaptive Application (AA). Vollständig portabel zwischen verschiedenen AP-Stack-Implementierungen und Hardware-Targets.
   • Schnittstellen: Verwendet ausschließlich definierte ARA-APIs (z. B. ara::com, ara::per, ara::exec, ara::log) sowie portable C++ Standard Library Mechanismen.
2. Non-portable User Application (Oben-Links):
   • Klassifikation: user level $\land$ OS/hardware specific implementation.
   • Architekturrolle: Anwendungslogik mit harter Hardware- oder OS-Bindung (z. B. direkte Nutzung von GPU-/NPU-Beschleunigern, V4L2-Videostreams, proprietären IPCs oder Linux-Sockets).
   • Schnittstellen: Native OS-Calls, Umgehung oder partielle Nicht-Nutzung von ARA.
3. Typical Functional Cluster Application (Unten-Links):
   • Klassifikation: platform/machine $\land$ OS/hardware specific implementation.
   • Architekturrolle: Plattformdienste der Adaptive Foundation, die systemspezifische Ressourcen kapseln müssen (z. B. OS-spezifische Teile des Execution Management, Persistency-Dateisystemtreiber, Hardware-Watchdog-Anbindungen).
   • Schnittstellen: POSIX-Kernelschnittstellen, BSP-Treiber, hardwarenahe OS-APIs.
4. Reusable Platform Application (Unten-Rechts):
   • Klassifikation: platform/machine $\land$ fully AUTOSAR compliant.
   • Architekturrolle: Plattformdienste, die ohne hardware-/OS-spezifischen Code auskommen und rein auf der ARA-Abstraktionsschicht aufbauen (z. B. State Management (SM), Teile des Diagnostics Management (DM) oder Update & Configuration Management (UCM)).
   • Schnittstellen: Ausschließlich standardisierte ARA-Schnittstellen zur Gewährleistung der Stack-Portabilität.

3. Dynamisches Verhalten & Sequenzablauf

Das Diagramm selbst ist statisch, definiert jedoch die Zielobjekte der zentralen AP-Lebenszyklusmechanismen:

• Zustandssteuerung via State Management (SM):
  • Das SM (idealerweise ein Typ des Quadranten Reusable Platform Application) trifft Entscheidungen über das Starten und Stoppen von Prozessen anhand von Maschinen- und Funktionsgruppenzuständen (Function Group States).
  • Das SM sendet Zustandsanforderungen über standardisierte Schnittstellen an das Execution Management (ara::exec).
• Prozess-Instanziierung durch Execution Management (EM):
  • Das EM liest die Execution Manifests aller vier Anwendungstypen aus.
  • Das Laden, Forken/Executen und Überwachen erfolgt unabhängig vom Quadranten einheitlich über OS-Primitive.
  • Prozesse melden ihren internen Zustand (kRunning, kTerminating) über den ara::exec::ApplicationClient aktiv an das EM zurück.
• Synchronisation vs. Abhängigkeiten:
  • FCs der unteren Quadranten werden in frühen Initialisierungsphasen (Startup Phase / MachineState: Startup) gestartet, um Basisdienste bereitzustellen.
  • User-Level-AAs (obere Quadranten) werden erst nach Erreichen der entsprechenden Anwendungs-Funktionsgruppenzustände hochgefahren.

4. Normative Relevanz & Entwickler-Hinweise

• Vorgaben für Applikationsentwickler (AA-Entwickler):
  • Um Herstellerunabhängigkeit, SIL-Konformität und Update-Fähigkeit (OTA) zu gewährleisten, ist architektonisch zwingend der grüne Quadrant (Portable Adaptive Application) einzuhalten.
  • Direkte POSIX-Aufrufe (z. B. pthread_setschedparam für Echtzeit-Scheduling, open/write statt ara::per, Sockets statt ara::com) führen zum Verlust der Portabilität (Verschiebung in den oberen linken Quadranten) und brechen den Plattformvertrag.
• Vorgaben für Plattform- & Integrationsentwickler:
  • Das State Management (SM) muss gemäß AUTOSAR-Vorgabe zwingend als Reusable Platform Application entworfen werden (keine nativen OS-Calls), damit OEMs das SM über verschiedene AP-Stack-Zulieferer hinweg identisch wiederverwenden können.
  • Alle OS-/Hardware-spezifischen Implementierungen (unterer linker Quadrant) müssen strikt über Hardware-Abstraktionen gekapselt werden, um Seiteneffekte auf das restliche System zu minimieren.
• Manifest- und Deployment-Konsequenzen:
  • Jeder Prozess – gleich welchen Quadranten – benötigt ein formales ExecutionManifest zur Spezifikation von Ressourcenbudgets (CPU-Affinität, POSIX-Scheduling-Policies, Speichergrenzen), Funktionsgruppen-Zuordnungen und Prozess-Startparametern.