Figure 9.9: Interfaces for a SMControlApplication

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Komponentendiagramm / Service-Schnittstellendiagramm der AUTOSAR Adaptive Platform (AP).
• Technischer Zweck: Spezifikation der standardisierten Service-Schnittstellen zwischen einer übergeordneten Steuerungsapplikation (SMControlApplication) und dem Functional Cluster State Management (SM) in einer Daemon-basierten Prozessarchitektur.
• Funktionale Einordnung: Dient der Entkopplung von plattforminterner Zustandssteuerung und externer/applikativer Kontrolllogik (z. B. Power-Management, Diagnostics, OTA/UCM-Orchestrierung) über die dienstbasierte Middleware (ara::com) unter strikter IAM-Zugriffskontrolle.

2. Komponenten, Entitäten & Schnittstellen

• Komponenten / Akteure:
  • Adaptive Application (spezifiziert als SMControlApplication): Service Consumer (Client) im unprivilegierten oder teilprivilegierten User-Space.
  • «aapFunctionalCluster» State Management (daemon-based): Service Provider (Server), ausgeführt als autonomer Plattform-Daemon-Prozess.
• Service-Interfaces & Ports:
  • «aapAraComServiceInterface, aapAPI» StateMachineService:
    • Port-Beziehung: Bereitgestellt durch SM («aapProvidedPort»), konsumiert durch SMControlApplication («use» «aapRequiredPort»).
    • Operation: «aapAccessControlled, aapServiceMethod» + RequestState() zur Anforderung von Funktionsgruppen- oder Maschinenzustandsübergängen (Function Group States / Machine States).
  • «aapAraComServiceInterface, aapAPI» UpdateAllowedService:
    • Port-Beziehung: Bereitgestellt durch SM («aapProvidedPort»), konsumiert durch SMControlApplication («use» «aapRequiredPort»).
    • Element: «aapAccessControlled, aapServiceField» + UpdateAllowed zur Signalisierung, Abfrage oder Notifikation, ob Software-Updates (z. B. via UCM) im aktuellen Gesamtsystemzustand sicher durchgeführt werden dürfen.
• Stereotypen-Semantik:
  • «aapAraComServiceInterface, aapAPI»: Abbildung auf C++-Proxy-/Skeleton-Generierung gemäß ara::com-API-Standard.
  • «aapAccessControlled»: Explizite Absicherung der Aufrufe durch das AUTOSAR Identity and Access Management (IAM).
  • «aapServiceMethod»: Remote Procedure Call (RPC) via IPC.
  • «aapServiceField»: Kombinierter Datentyp mit Getter-, Setter- und Notifier-Semantik.

3. Dynamisches Verhalten & Sequenzablauf

• Zustandsanforderung (RequestState):
  1. SMControlApplication initiiert RequestState() asynchron über die generierte Proxy-Instanz.
  2. Middleware/IAM validiert die Aufrufer-Identität (UID/GID/Process Token) gegen hinterlegte Zugriffsregeln.
  3. Bei Autorisierung prüft der SM-Daemon Transition-Guards und interagiert mit dem Execution Management (EM) zur Prozesssteuerung.
  4. Rückmeldung an den Aufrufer erfolgt non-blocking über ara::core::Future / ara::core::Result.
• Update-Berechtigung (UpdateAllowed):
  • Zugriff erfolgt über Field-Mechanismen: Entweder synchron/asynchron per Get() oder ereignisbasiert via Subscription (Subscribe()) auf den Notifier des Felds.
  • SM aktualisiert das Feld in Abhängigkeit von aktiven Operational- oder Diagnostic-Sessions; die SMControlApplication reagiert auf Statusänderungen (z. B. Freigabe von Update-Phasen).

4. Normative Relevanz & Entwickler-Hinweise

• IPC & Deployment: Da SM explizit daemon-based modelliert ist, laufen Interaktionen zwingend über Inter-Process Communication (IPC, z. B. Unix Domain Sockets) und nicht über direkte In-Process C++-Bibliotheksaufrufe. Latenzen und asynchrone Schnittstellenmuster (ara::core::Future) sind im Anwendungsdesign zwingend zu berücksichtigen.
• IAM-Konfiguration (Security): Aufgrund der Stereotype «aapAccessControlled» müssen in den ARXML-Deployment-Manifesten (ExecutionManifest, ServiceInstanceToPortMapping) entsprechende Security-Grants hinterlegt werden. Fehlt die IAM-Policy, schlägt die Proxy-Erzeugung bzw. der Methoden-/Feldaufruf zur Laufzeit fehl (ara::com::ComErrc::kGrantEnforcementError).
• Resilienz & Fehlerbehandlung: Entwickler der SMControlApplication müssen den Lebenszyklus des SM-Daemons behandeln (Warten auf FindService, Re-Subscription bei Daemon-Neustart sowie Timeout-Handling bei hängenden RequestState()-Transitionen).