DEENESPTFRRUARHIKOZHNL
AUTOSAR_AP_EXP_SWArchitecture FIG-633db34ec244396b 607 × 543 px 1 Release(s)

Figure 8.11: Variant 1 - Skeleton Approach

SHA-256 Inhalts-Fingerabdruck: 633db34ec244396b0548e5b402e6da8faf84b1e39acf16fdaf2e2a11e09fbddc

Im Versions-Explorer öffnen

Kanonischer Bildausschnitt (144 DPI WebP, gerendert aus Original-Vektorgrafik) · nicht öffentlich, nur mit Anmeldung und Freigabe
✦ KI-generierte Bildanalyse & technische Beschreibung Modell: gemini-3.8-flash (via agy) · Rezept figure-series@1 · erstellt am 2026-10-08

1. Diagrammtyp & Architektur-Kontext

  • Klassifikation: UML-Sequenzdiagramm mit Subsystem-/Prozessgrenze (Application) und Interaktions-Rahmen (loop).
  • Architektur-Kontext: AUTOSAR Adaptive Platform (ara::com Communication Management / Platform Architecture, AUTOSAR_AP_EXP_SWArchitecture, Release R24-11).
  • Technischer Zweck: Spezifikation des Lebenszyklus und Nachrichtenaustauschs beim Service-Provider nach dem Skeleton-Ansatz (Variant 1). Das Diagramm modelliert das Zusammenspiel zwischen Applikationslogik, generiertem Service-Skeleton (ServiceImpl) und der zugrundeliegenden Plattform-Infrastruktur (Functional Cluster, z. B. Communication Management Daemon / Service Discovery / IPC-Router).

2. Komponenten, Entitäten & Schnittstellen

  • Entitäten & Lifelines:
    • Application (äußere Prozessgrenze / Packaging-Boundary): Gekapselter Linux/POSIX-Prozessraum der Adaptive Application.
    • Application (Lifeline): Applikative Kontrolllogik (User Code), welche den Lebenszyklus des Service steuert.
    • Service: ServiceImpl (Lifeline): Konkrete Instanz des generierten Skeletons (ara::com::Skeleton), die das typisierte Service-Interface implementiert.
    • Functional Cluster (Lifeline): Plattform-Infrastrukturkomponente außerhalb des Anwendungsprozesses (typischerweise der ara::com-Plattform-Daemon für SOME/IP- bzw. IPC-Binding).
  • Stereotypen:
    • «aapInformative»: Kennzeichnet nicht-normative, herstellerspezifische Interaktionen zwischen dem Skeleton-Framework und dem Functional Cluster. Diese Aufrufe sind Implementierungsdetails der Middleware und nicht Teil der normativen C++-Applikationsschnittstelle.

3. Dynamisches Verhalten & Sequenzablauf

  1. Service Announcement (Offer):
    • Die Application ruft synchron Offer(): Result auf ServiceImpl auf (entspricht normativ OfferService()).
    • ServiceImpl signalisiert via notify about offer() («aapInformative») dem Functional Cluster die Service-Verfügbarkeit (Trigger für SOME/IP Service Discovery bzw. lokales IPC-Publishing).
    • Nach Bestätigung durch den Cluster aktiviert das Skeleton lokal die Annahme von Anfragen via enableServiceRequests() («aapInformative»).
    • Result signalisiert der Applikation die erfolgreiche Bereitstellung.
  2. Service Operation Execution (loop-Block):
    • Wiederkehrend bei eingehenden Client-Aufrufen leitet der Functional Cluster die Anfrage via request service() («aapInformative») an ServiceImpl weiter.
    • ServiceImpl führt intern die anwendungsspezifische Methode ServiceOperation() aus (Dispatching in den applikativen Servant-Code).
    • Das Ausführungsergebnis wird synchron/asynchron über den Return-Pfad von request service() an den Functional Cluster zur Weiterleitung an den Client übergeben.
  3. Service Revocation (StopOffer):
    • Die Application stößt den Shutdown via StopOffer() auf ServiceImpl an (entspricht normativ StopOfferService()).
    • ServiceImpl deaktiviert unverzüglich die Annahme neuer Anfragen über disableServiceRequests() («aapInformative»).
    • Das Skeleton sendet notify about stopoffer() («aapInformative») an den Functional Cluster (Trigger für SOME/IP StopOfferService-Nachricht bzw. IPC-Deregistrierung).
    • Der Aufruf kehrt zur Application zurück; der Service ist offline.

4. Normative Relevanz & Entwickler-Hinweise

  • API-Schnittstellenvertrag:
    • Normativ: Ausschließlich OfferService(), StopOfferService() und die Implementierung der Schnittstellen-Operationen (ServiceOperation()) innerhalb der von der generierten Skeleton-Basisklasse abgeleiteten Klasse ServiceImpl.
    • Nicht-normativ: Sämtliche «aapInformative»-Pfade. Entwickler dürfen sich nicht auf konkrete IPC-Mechanismen, Middleware-Daemons oder Signalwege zum Functional Cluster stützen; diese variieren je nach Vendor-Stack (z. B. Shared Memory vs. UNIX Domain Sockets).
  • Concurrency & Thread-Modell:
    • ServiceOperation() wird im Kontext des Worker-Thread-Pools der ara::com-Middleware ausgeführt. Entwickler müssen ServiceImpl threadsicher und reentrant implementieren (bzw. entsprechende Serialisierungsmechanismen vorsehen).
  • State-Invariante:
    • Der interne Status enableServiceRequests() vs. disableServiceRequests() garantiert, dass keine Requests an die Applikation zugestellt werden, bevor Offer() vollständig durchlaufen ist bzw. nachdem StopOffer() initiiert wurde. Dies verhindert Race Conditions beim Anwendungsstart und geordneten Herunterfahren über das Execution Management (ara::exec).

Versionsvergleich KI-generiert · gemini-3.8-flash (via agy)

R24-11 → R25-11 keine inhaltliche Änderung Vorgänger: FIG-fabcd9ce1130345d

Keine inhaltlichen Änderungen erkennbar.

Zugeordnete Anforderungen

Diese Angaben zeigt der Versions-Explorer.

Aus dem Dokument extrahierter Text & Kontext

Beschriftungen im Schaubild:

Application | Application Functional Cluster Service: ServiceImpl | loop | «aapInformative» disableServiceRequests() | ServiceOperation() | «aapInformative» enableServiceRequests() | notify about offer() | «aapInformative» | notify about stopoffer() | «aapInformative» | request service() | «aapInformative» | StopOffer() | Offer(): Result

Begleitender Spezifikationstext:

Explanation of Adaptive Platform Software Architecture AUTOSAR AP R25-11 8.5.6.3.3 Participants • Variant 1 - Skeleton Approach: – ServiceSkeleton: An abstract class providing the functionality to enable/disable the invocation of the callback(s) (Offer and StopOffer). It also defines at least one pure virtual function at defines the signature for the callback (ServiceOperation). The ServiceSkeleton is defined as part of the Adaptive Platform API. – ServiceImpl: Inherits from the ServiceSkeleton and implements the callbacks. The ServiceImpl class is part of the application. • Variant 2 - std::function: – Service: Provides functionality to register one or more callbacks (RegisterCallback, but could also be done in a constructor if the callback is mandatory) and functionality to enable/disable the invocation of the callback(s) (Offer and StopOffer). 8.5.6.4 Behavior Figure 8.11 shows the registration, the usage, and the de-registration of a callback for Variant 1 - Skeleton Approach. Application Application Functional Cluster Service: ServiceImpl loop «aapInformative» disableServiceRequests() ServiceOperation() «aapInformative» enableServiceRequests() notify about offer() «aapInformative» notify about stopoffer() «aapInformative» request service() «aapInformative» StopOffer() Offer(): Result Figure 8.11: Variant 1 - Skeleton Approach Figure 8.12 shows the registration, the usage, and the de-registration of a callback for Variant 2 - std::function. 41 of 269 Document ID 982: AUTO

Vorkommen in AUTOSAR-Releases (1)

Release Dokument Seite Nr. Bildunterschrift im Dokument
R25-11 AUTOSAR_AP_EXP_SWArchitecture S. 41 8.11 Figure 8.11: Variant 1 - Skeleton Approach