Figure 13.1: Overview of platform entities and their logical relationships

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Abstrahierendes UML-Klassendiagramm mit integrierter Komponentensicht (Metamodell-Ausschnitt nach AUTOSAR AP R21-11, AUTOSAR_EXP_SWArchitecture, Kap. 12.1).
• Technischer Zweck: Darstellung der zentralen Entitäten des Manifest-Modells (Execution-, Machine- und Software-Package-Manifest) sowie deren logische Bindung an die funktionalen Cluster der AUTOSAR Adaptive Platform (Update and Configuration Management, State Management, Execution Management, Platform Health Management).
• Systemische Einordnung: Definiert die statische und dynamische Steuerungsbasis für das Deployment (UCM), das Lifecycle- und Prozess-Management (SM/EM) sowie die funktionale Überwachung (PHM) von POSIX-basierten Adaptive Applications.

2. Komponenten, Entitäten & Schnittstellen

A. Funktionale Plattform-Cluster (UML-Komponenten)

• «aapFunctionalCluster» Update and Configuration Management (daemon-based): Verantwortlich für Installation, Aktualisierung und Deinstallation von Softwarepaketen.
• «aapFunctionalCluster» State Management (daemon-based): Bestimmt und orchestriert die systemweiten Zustände und triggert Transitionen von Funktionsgruppen.
• «aapFunctionalCluster» Execution Management (daemon-based): Verantwortlich für die Prozessinitialisierung, Durchsetzung von Startreihenfolgen, Scheduling-Attributen und Überwachung des Lebenszyklus aktiver Prozesse.
• «aapFunctionalCluster» Platform Health Management (daemon-based): Überwacht das Laufzeitverhalten (Alive-, Deadline- und Logical Supervision) anhand definierter Checkpoints.
• Adaptive Application (AA): Der instanziierte Anwendungscode im User Space, der funktionale Logik ausführt und Checkpoints an PHM meldet.

B. Plattform-Entitäten (Klassen) & Attribute

• Software Package: Signierter Deployment-Container für UCM.
• Software Cluster: Kleinste unabhängig aktualisierbare und versionierbare logische Einheit.
  • Attribute: diagnosticConfig [0..1] (Diagnosekonfiguration), version (Semantische Versionierung; rot hervorgehoben).
• Function Group: Logische Bündelung kohärenter System- oder Applikationszustände.
• Function Group State: Diskreter Betriebszustand einer Funktionsgruppe (z. B. Off, Verify, Running).
• Startup Configuration: Konfigurationssatz für den Start eines Prozesses in einem bestimmten State.
  • Attribute: options (Kommandozeilenparameter, Umgebungsvariablen), schedulingPriority (Echtzeit-/POSIX-Priorität; rot hervorgehoben).
• Process: Konfigurierte Laufzeitinstanz eines Binärartefakts im Betriebssystem.
• Executable: Das unveränderliche, kompilierte Executable-Binärfile (ELF) im Dateisystem.
• PhmSupervision: Überwachungskonfiguration innerhalb von PHM (Regelwerk für Alive/Deadline/Logical Supervision).
• Supervision Checkpoint: Diskreter Meldezeitpunkt/Code-Ort innerhalb des Kontrollflusses einer Applikation.

C. Assoziationen, Kardinalitäten & Abhängigkeiten

• Packaging & Cluster:
  • Software Package → Software Cluster: Gerichtete Assoziation (Kardinalität 1 : 1). Ein Package enthält exakt einen Cluster.
  • Software Cluster → Software Cluster: Reflexive Abhängigkeit +/requiredCluster (0..*), modelliert statische Inter-Cluster-Abhängigkeiten.
  • Software Cluster → Plattform-Entitäten: Aggregiert 0..* Entitäten (Function Group, Process, Executable etc.).
• State & Execution:
  • Function Group ▶ Function Group State: Strikte Komposition (1 : 2..*). Eine Gruppe besitzt mindestens zwei Zustände (z. B. Off und mindestens einen aktiven Zustand).
  • Process ▶ Startup Configuration: Strikte Komposition (1 : 0..*). Ein Prozess kann für unterschiedliche Zustände separate Startkonfigurationen halten.
  • Startup Configuration → Function Group State: Assoziation +state (0..* : 1..*). Weist die Startkonfiguration konkreten Funktionsgruppenzuständen zu.
  • Startup Configuration → Startup Configuration: Reflexive Abhängigkeit +executionDependecy (0..*). Definiert deterministische Startreihenfolgen/Startbarrieren zwischen Prozessen.
  • Process → Executable: Assoziation +executable (0..* : 1). Ein Executable kann mehrfach als eigenständiger Prozess instanziiert werden.
• Health Monitoring:
  • PhmSupervision → Supervision Checkpoint: Assoziation +/checkpoints (1 : 1..*). Eine Überwachung erfordert mindestens einen Checkpoint.
  • Supervision Checkpoint → Process: Assoziation +process (1..* : 1). Jeder Checkpoint ist exakt einem Prozess zugeordnet.
• Cluster-Steuerungsbeziehungen (gestrichelt/Aktionspfade):
  • UCM steuert Software Package und Software Cluster.
  • SM steuert Function Group und fordert Zielzustände bei Function Group State an.
  • EM liest Function Group State, wertet Startup Configuration aus und instanziiert/terminiert Process.
  • PHM bindet an PhmSupervision und empfängt Meldungen der Supervision Checkpoints.
  • Adaptive Application bindet an den OS-Process und meldet Aktivität an Supervision Checkpoint.

3. Dynamisches Verhalten & Sequenzablauf

1. Bereitstellung (UCM-Pipeline):
   • UCM verifiziert die Signatur des Software Package, validiert deklarierte +/requiredCluster-Abhängigkeiten gegen installierte Versionen und deployt das Software Cluster mit seinen Executable-Dateien und Manifesten.
2. State-Transition (SM → EM):
   • SM bestimmt aufgrund interner Logik oder Fahrzeugzuständen einen Zustandswechsel und übermittelt den Ziel-Function Group State an EM.
3. Prozess-Aktivierung / -Terminierung (EM → OS):
   • EM ermittelt alle dem Zielzustand zugeordneten Startup Configuration-Einträge.
   • EM löst eventuelle +executionDependecy-Bedingungen auf und startet die zugehörigen Process-Instanzen unter Anwendung der konfigurierten schedulingPriority und options via POSIX-Aufrufe (fork, execve, pthread_setschedparam).
   • Prozesse, die im neuen Zustand nicht mehr deklariert sind, werden via SIGTERM/SIGKILL geregelt beendet.
4. Laufzeitmeldung & Überwachung (AA → PHM):
   • Der Prozess meldet via Execution Management Client seinen Betriebszustand (kRunning).
   • Während der Ausführung ruft die Applikation die synchrone PHM-Schnittstelle auf (ReportCheckpoint(checkpointId)).
   • PHM validiert Checkpoint-Timing und -Sequenz gegen PhmSupervision. Bei Verletzung meldet PHM an SM/EM zur Einleitung von Recovery-Maßnahmen (Watchdog-Reset, Prozess-Neustart oder Notlaufzustand).

4. Normative Relevanz & Entwickler-Hinweise

• ARXML-Modellierung (Manifest-Konsistenz):
  • Entwickler müssen im Execution Manifest zwingend die Kette Executable ← Process → StartupConfiguration → FunctionGroupState vollständig konfigurieren.
  • Startabhängigkeiten zwischen Applikationen dürfen nicht über proprietäre IPC/Sockets gelöst werden, sondern müssen normativ über executionDependency der Startup Configuration deklariert werden.
• Multi-Instanziierung:
  • Ein Executable kann durch unterschiedliche Process-Deklarationen mehrfach parallel betrieben werden. Jede Instanz benötigt ein eigenes Prozess-Manifest mit isolierten Ports, eigener UID/GID und eigener Startup Configuration.
• POSIX-Betriebssystem-Konformität:
  • Die Parameter in Startup Configuration binden direkt an OS-Privilegien. Die Zuweisung von schedulingPriority (z. B. SCHED_FIFO, SCHED_RR) setzt voraus, dass das Zielsystem entsprechende POSIX-Capabilities (CAP_SYS_NICE) und OS-Budgets (Cgroups) für den Prozess freigibt.
• Safety & Determinismus (ISO 26262):
  • Checkpoints (Supervision Checkpoint) müssen zwingend reentranz- und blockierungsfrei implementiert sein. Eine fehlerhafte Checkpoint-Reihenfolge oder verpasste Deadlines lösen unmittelbare Plattform-Reaktionen (Safe State über SM) aus.
• Modularität & Granularität (Software Cluster):
  • Da Software Cluster die atomare Einheit für Over-the-Air-Updates (OTA) darstellt, müssen Schnittstellen und requiredCluster-Beziehungen streng rückwärtskompatibel gepflegt werden, um Update-Abbrüche im Feld durch UCM zu verhindern.