Figure 7.9: Agent - FunctionGroup relation

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Konzeptionelles Struktur- und Gültigkeitsgrenzen-Diagramm (UML-Objekt-/Komponenten-Abstraktion mit Stereotypen).
• Technischer Zweck: Spezifiziert die Scoping- und Zugriffsgrenzen von State-Management-Agenten (StateMachine) auf Funktionsgruppen (FunctionGroup, FG) in einer Multi-Software-Cluster-Umgebung (SoftwareCluster, SWCL) gemäß AUTOSAR Adaptive Platform (AUTOSAR_AP_SWS_StateManagement, R23-11).
• Architektur-Kontext: Zur Laufzeit teilt die Adaptive Platform Prozesse und Ressourcen in modular aktualisierbare Software Cluster (SWCLs) auf. Das Diagramm definiert den Architektur-Constraint: Eine Zustandsmaschine bzw. ein SM-Agent darf ausschließlich diejenigen Funktionsgruppen steuern (<<manage>>), die dem eigenen Software Cluster explizit über Claimed FGs zugeordnet sind. Cross-Cluster-Direktsteuerung von fremden Funktionsgruppen ist architektonisch untersagt.

2. Komponenten, Entitäten & Schnittstellen

• Software Cluster (<<SWCL1>>, <<SWCL2>>):
  • Unabhängig deploybare, startbare und via UCM (Update and Configuration Management) aktualisierbare Software-Einheiten.
  • Kapseln jeweils ein Set exklusiv beanspruchter Funktionsgruppen (Claimed FGs).
• Funktionsgruppen (FG_1 bis FG_5):
  • Instanzen von FunctionGroup, die Prozesslebenszyklen und Ausführungszustände (z. B. Running, Terminated, Off) über das Execution Management (ara::exec) steuern.
  • Zuordnungs-Kardinalitäten:
    • SWCL1 beansprucht: FG_1, FG_3 (1:n-Komposition/Exklusivanspruch).
    • SWCL2 beansprucht: FG_2, FG_4, FG_5 (1:n-Komposition/Exklusivanspruch).
    • Eine FunctionGroup ist disjunkt genau einem SoftwareCluster zugeordnet.
• State-Management-Agent (<<StateMachine A>>):
  • Ausführende Zustandslogik innerhalb von SWCL1.
• Schnittstellen & Steuerungsbeziehungen:
  • <<manage>> (Solide Pfeile von StateMachine A auf FG_1 und FG_3): Zulässige Kontrollpfade. Der Agent besitzt die Autorisierung, Zustandstransitionen für FGs innerhalb des eigenen Cluster-Scopes anzufordern.
  • <<manage>> (Rot gestrichelter Pfeil mit rotem Sperrkreuz auf FG_5): Unzulässiger Kontrollpfad. Ein direkter Zugriff einer StateMachine auf cluster-fremde Funktionsgruppen verletzt die Cluster-Isolierung.

3. Dynamisches Verhalten & Sequenzablauf

• Zulässiger Transitionspfad (StateMachine A → FG_1 / FG_3):
  1. Trigger (z. B. Feldbus-Signal via ara::com, interner Timer, Diagnose-Event).
  2. StateMachine A evaluiert Transitionsbedingungen gemäß internem Zustandsmodell.
  3. StateMachine A setzt Zustandsanforderung via State Management an Execution Management ab (ara::exec::FunctionGroupState::TransitionTo()).
  4. EM verifiziert die Gültigkeit und führt Prozessstarts/-stopps für FG_1/FG_3 aus.
  5. Asynchrones Feedback (ara::core::Future) über Transitionserfolg an StateMachine A.
• Verhinderter Pfad (StateMachine A → FG_5):
  • Direkte Aufrufe von StateMachine A auf den Funktionsgruppen-Zustand von FG_5 existieren im API-Vertrag nicht bzw. werden durch Modell-Validierung und Zugriffsfilter zur Laufzeit unterbunden.
• Inter-Cluster-Koordination (Architektur-Muster bei Abhängigkeiten):
  • Benötigt SWCL1 eine Zustandsänderung in SWCL2 (z. B. Aktivierung von FG_5), darf dies nicht via manage, sondern ausschließlich über lose gekoppelte Inter-Cluster-Kommunikation erfolgen (z. B. Senden eines Requests via ara::com-Service-Interface an einen dedizierten Agenten/StateMachine in SWCL2, der dann FG_5 lokal steuert).

4. Normative Relevanz & Entwickler-Hinweise

• Manifest-Modellierung (ARXML):
  • Im StateManagementManifest bzw. ExecutionManifest müssen alle durch eine StateManagementPort- / StateMachine-Konfiguration gesteuerten FunctionGroup-Instanzen als strikte Teilmenge der im Metamodell definierten claimedFunctionGroup-Referenzen des übergeordneten SoftwareCluster deklariert sein.
  • ARXML-Generatoren und Validierungswerkzeuge müssen Schemata-Verletzungen (Cross-Cluster FG Reference) bereits zur Compile-/Generierungszeit als harter Fehler abfangen.
• UCM & Lifecycle-Entkopplung:
  • Die strikte Begrenzung verhindert Deadlocks und Inkonsistenzen bei partiellen OTA-Updates: Wird SWCL2 über UCM gestoppt, aktualisiert oder entfernt, bleibt StateMachine A in SWCL1 voll lauffähig und blockiert nicht auf ungültigen FG-Handles fremder Cluster.
• API-Implementierung (ara::exec / ara::sm):
  • Applikationsentwickler dürfen keine Instanzen von ara::exec::FunctionGroup oder Transition-Handles für cluster-externe FGs anfordern.
  • Fehlerbehandlung: Ein ungültiger oder cluster-fremder Zugriff wird von der Plattform mit Fehlern wie ExecErrc::kInvalidArguments oder durch Verweigerung der Namespace-Auflösung quittiert.

Die Analyse zu Figure 7.14 (Agent - FunctionGroup relation) aus AUTOSAR_AP_SWS_StateManagement liegt vollständig vor. Falls Sie weitergehende Einordnungen zu spezifischen SWS-Anforderungen (z. B. Interaktionsmuster mit dem Execution Management oder Details zum StateManagement-Manifest) wünschen, stehe ich gern zur Verfügung.