Figure 12.2: Exemplary Software Cluster during application design

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Objekt- bzw. Instanzendiagramm (M1-Ebene des AUTOSAR-Metamodells) mit Schachtelungs-/Containment-Semantik.
• Architektur-Kontext: AUTOSAR Adaptive Platform (Release R20-11), Spezifikation AUTOSAR_EXP_SWArchitecture (Kapitel 12: Software Cluster).
• Technischer Zweck: Darstellung der Entwurfs- und Kapselungsstrukturen von Software-Clustern (SoftwareCluster) während der Anwendungsentwurfsphase (Application Design). Es illustriert, wie funktionale Softwareeinheiten inklusive ihrer Binärdateien (Executable), Prozessdefinitionen (Process), Manifeste (ExecutionManifest) und Zustandssteuerungen (FunctionGroup) in autarke, modular austauschbare Einheiten segmentiert werden – in Abgrenzung zum Basis-System (platform: Software Cluster).

2. Komponenten, Entitäten & Schnittstellen

• Entitäten und Rollen:
  • SoftwareCluster (a, b, platform): Oberste logische Aggregations- und Bereitstellungseinheit (Deployable/Updatable Unit) für das Update and Configuration Management (UCM).
    • a, b: Anwendungs-Cluster (Application Software Clusters).
    • platform: Basisplattform-Cluster (Platform Software Cluster), der die Core-Plattformdienste hostet.
  • Executable (e1, e2): Physische Binärdateien/Kompilate (POSIX-ELF), die auf dem Zielbetriebssystem instanziiert werden.
  • Manifest / ExecutionManifest (executionManifest, :Manifest): Formales ARXML-Beschreibungsartefakt, das die Deployment- und Ausführungsparameter auf dem Zielsystem deklariert.
  • Process (p1, p2, EM): Laufzeitinstanz eines Executable.
    • p1, p2: Anwendungs-Prozesse.
    • EM: Der zentrale Prozess des Execution Management (im platform: Software Cluster).
  • Startup Configuration (cfg1, cfg2, :Startup Configuration): Spezifiziert prozessspezifische Startparameter (Kommandozeilenargumente, Umgebungsvariablen, Resource-Limits, Scheduling-Policies wie SCHED_FIFO/SCHED_OTHER).
  • Function Group (fg1, fg2): Orthogonale Steuerungsdomäne für Zustände innerhalb des Execution Managements.
  • Function Group State: Diskrete Zustände einer Funktionsgruppe:
    • fg1: Zustände off, normal, degraded.
    • fg2: Zustände off, normal.
• Beziehungen und Assoziationen:
  • Process → Executable (Referenzpfeil): Jeder Prozess referenziert exakt ein ausführbares Artefakt (Process.executableRef).
  • Startup Configuration → Function Group State (Abhängigkeitspfeil):
    • cfg1 bindet p1 an den Zustand normal der Gruppe fg1.
    • cfg2 bindet p2 an den Zustand normal der Gruppe fg2.
  • Metamodell-Containment: Während des Application Designs sind die FunctionGroup-Definitionen sowie die ExecutionManifest-Instanzen den jeweiligen SoftwareCluster-Entitäten zugeordnet.

3. Dynamisches Verhalten & Sequenzablauf

Das Diagramm bildet die statische Konfiguration ab, aus der das deterministische Laufzeitverhalten des Execution Managements resultiert:

1. Plattform-Bootstrap: Der Prozess EM: Process wird im platform: Software Cluster durch den OS-Init-Prozess (z. B. init/systemd) gestartet und initialisiert die interne Zustandsverwaltung.
2. State Transition Triggern: Eine Zustandsänderung (z. B. via ara::exec::StateClient::SetState) schaltet eine Funktionsgruppe (z. B. fg1) in den Zielzustand normal.
3. Auswertungs- und Startphase:
   • EM parst das zugehörige ExecutionManifest von p1.
   • Die Übereinstimmung von aktuellem State (fg1.normal) mit der Startup Configuration (cfg1) triggert die Instanziierung von e1 als OS-Prozess p1 via fork()/execve().
4. Zustandsrückmeldung (Execution Client Contract):
   • p1 initialisiert die ARA-Laufzeitumgebung und muss synchron ara::exec::ExecutionClient::ReportExecutionState(ExecutionState::kRunning) an EM melden.
5. Abschaltung / Degradierung:
   • Wechselt fg1 von normal nach off oder degraded (sofern für degraded keine eigene Startup Configuration hinterlegt ist), sendet EM standardmäßig SIGTERM an p1. Nach Ablauf des konfigurierten terminationTimeout erzwingt EM das Beenden via SIGKILL.

4. Normative Relevanz & Entwickler-Hinweise

• Kapselung & Unabhängiges Lifecycle-Management (OTA / UCM):
  • Durch die Separierung in SoftwareCluster können Applikation a und b über UCM (ara::ucm) unabhängig voneinander aktualisiert, paketiert, gestoppt oder deinstalliert werden, ohne den Platform-Cluster oder Nachbarcluster zu modifizieren.
• Gültigkeitsbereich von Funktionsgruppen (Scope of Function Groups):
  • Werden Funktionsgruppen auf Cluster-Ebene modelliert (wie fg1 in Cluster a und fg2 in Cluster b), muss das State Management clusterübergreifend synchronisiert werden, falls globale Abhängigkeiten bestehen. Vermeidung zirkulärer Abhängigkeiten bei Zustandswechseln ist zwingend.
• Konfigurationspflicht im Execution Manifest:
  • Entwickler müssen sicherstellen, dass für jeden geforderten FunctionGroupState eine valide StartupConfiguration vorliegt. Befindet sich eine Funktionsgruppe in einem State, für den ein Prozess keine Zuordnung besitzt, bleibt dieser inaktiv bzw. wird terminiert.
• Plattform-Minimierung:
  • Der platform: Software Cluster bleibt frei von Applikationslogik und enthält ausschließlich Basistreiber, OS-spezifische Konfigurationen sowie Kern-Dienste (EM, UCM, SM, DLT, etc.).