DEENESPTFRRUARHIKOZHNL
AUTOSAR_EXP_ARAComAPI FIG-e70ca96b702dde73 1191 × 672 px 1 Release(s)

Figure 7.6: meta-model to Implementation

SHA-256 Inhalts-Fingerabdruck: e70ca96b702dde73a4975e1509152035595a87f941c56ff288a14b4057ceaed3

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-description@2 · erstellt am 2026-10-07

1. Diagrammtyp & Architektur-Kontext

  • Klassifikation: Abstraktions- und Transformationsmodell (Mapping-Diagramm zwischen AUTOSAR-Metamodell-Ebene und C++-Implementierungsebene).
  • Technischer Zweck: Visualisierung des modellgetriebenen Entwicklungsflusses (MDD) in der AUTOSAR Adaptive Platform (ara::com). Es überführt formale Manifest-Modellelemente (SoftwareComponentType, PortPrototype, ServiceInterface) in konkrete C++14/17-Artefakte (Proxy-/Skeleton-Architekturmuster) und deren Laufzeitinstanziierung.

2. Komponenten, Entitäten & Schnittstellen

Metamodell-Ebene (meta model level / ARXML-Manifeste)
  • ServiceInterface (RadarService): Kontrakt-Definition von Methoden, Events und Feldern (Serviceschnittstelle).
  • SoftwareComponentType A: Konsumierende Software-Komponente (konkretisiert als AdaptiveApplicationSwComponentType).
    • R-Port (Name: radarservice): RPortPrototype, typisiert über Beziehung is of type auf das ServiceInterface RadarService. Signalisiert Service-Bedarf (Required).
  • SoftwareComponentType B: Bereitstellende Software-Komponente.
    • P-Port (Name: Radar): PPortPrototype, typisiert über Beziehung is of type auf das ServiceInterface RadarService. Signalisiert Service-Bereitstellung (Provided).
Implementierungs-Ebene (Implementation level / C++-Code)
  • Generierte C++-Klassen (Codegenerator-Output basierend auf Service-Manifest):
    • RadarService Proxy Class: Client-seitige Abstraktion (ara::com-Proxy), abgeleitet via generated from aus dem RadarService für Konsumenten.
    • RadarService Skeleton Class: Server-seitige Basisklasse (ara::com-Skeleton), abgeleitet via generated from aus dem RadarService für Provider.
  • Laufzeit-Instanzen (Applikations-Prozessraum):
    • Implementation of SoftwareComponentType A: Applikations-Code des Service-Konsumenten. Instanziiert die RadarService Proxy instance, parametrisiert mit InstanceId: radarservice (abgebildet aus dem zugehörigen R-Port).
    • Implementation of SoftwareComponentType B: Applikations-Code des Service-Providers. Instanziiert die RadarService Skeleton instance, parametrisiert mit InstanceId: Radar (abgebildet aus dem zugehörigen P-Port).

3. Dynamisches Verhalten & Sequenzablauf

Statische Zuordnungsansicht ohne temporale Sequenzachse. Der daraus resultierende Laufzeit- und Instanziierungsablauf gliedert sich wie folgt:

  1. Design-/Generierungszeit: Der AUTOSAR-Codegenerator parst das ServiceInterface (RadarService) und erzeugt typsichere C++-Klassen-Header/Sources (RadarServiceProxy bzw. RadarServiceSkeleton).
  2. Initialisierung Provider (SoftwareComponentType B):
    • Applikation B erzeugt eine Instanz der RadarService Skeleton Class unter Angabe des Instanzbezeichners (InstanceId: Radar bzw. ara::com::InstanceIdentifier).
    • Aufruf von OfferService() am Skeleton publiziert den Service via Middleware-Binding (z. B. SOME/IP, IPC).
  3. Initialisierung & Discovery Consumer (SoftwareComponentType A):
    • Applikation A startet die Dienstsuche via RadarServiceProxy::StartFindService() / FindService().
    • Nach erfolgreichem Matching bindet die RadarService Proxy instance an die gefundene Instanz (InstanceId: radarservice) zur Methoden-/Event-Kommunikation.

4. Normative Relevanz & Entwickler-Hinweise

  • Generierungsvertrag: Änderungen am ARXML-ServiceInterface erfordern stets die Neuerzeugung von Proxy und Skeleton. Die Schnittstellen-Signatur im C++-Code ist unveränderlicher Bestandteil des API-Vertrags (ara::com).
  • Port-zu-Instanz-Mapping: Port-Namen aus dem Manifest (Name: radarservice, Name: Radar) determinieren die Konfiguration der InstanceIdentifier bzw. die Bindung im Execution- und Service-Instance-Manifest (ServiceInstanceToPortPrototypeMapping).
  • Skeleton-Implementierung: Applikationsentwickler von Component B müssen vom generierten Skeleton erben und die rein virtuellen Methoden des Interfaces implementieren.
  • Thread-Safety & Lebenszyklus: Instanzen von Proxy und Skeleton unterliegen RAII. Die Zerstörung des Skeletons muss zwingend mit StopOfferService() synchronisiert sein, um Deadlocks oder Invocations auf freigegebenem Speicher zu unterbinden.

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

R18-03_R1.4.0 → R18-10-1 keine inhaltliche Änderung Nachfolger: FIG-02ba3900e9f20d06

Keine inhaltlichen Änderungen erkennbar.

Zugeordnete Anforderungen

Diese Angaben zeigt der Versions-Explorer.

Aus dem Dokument extrahierter Text & Kontext

Beschriftungen im Schaubild:

Implementation of SoftwareComponentType A | RadarService Proxy instance | Implementation of SoftwareComponentType B | RadarService Skeleton instance | InstanceId: Radar InstanceId: radarservice | RadarService | Proxy Class | RadarService Skeleton Class | SoftwareComponentType A | R-Port | SoftwareComponentType B | P-Port | Service Interface | RadarService | is of type is of type | Name: Radar | generated from | Name: radarservice | generated from | meta model level Implementation level

Begleitender Spezifikationstext:

Explanation of ara::com API AUTOSAR AP Release 18-03 7.4.2 Software Component With software components, the AUTOSAR methodology defines a higher order element than just interfaces. The idea of a software component is to describe a reusable part of software with well defined interfaces. For this the AUTOSAR manifest specification defines a model element SoftwareComponentType, which is an abstract element with several concrete subtypes, of which the subtype AdaptiveApplicationSwComponentType is the most important one for Adaptive Application software developers. A SoftwareComponentType model element is realized by C++ code. Which service interfaces such a component "provides to" or "requires from" the outside is expressed by ports. Ports are typed by ServiceInterfaces. P-ports express that the ServiceInterface, which types the port, is provided, while R-ports express, that the ServiceInterface, which types the port, is required by the SoftwareComponentType. The figure Figure 7.6 gives a coarse idea, how the model view relates to the code implementation. Implementation of SoftwareComponentType A RadarService Proxy instance Implementation of SoftwareComponentType B RadarService Skeleton instance InstanceId: Radar InstanceId: radarservice RadarService Proxy Class RadarService Skeleton Class SoftwareComponentType A R-Port SoftwareComponentType B P-Port Service Interface RadarService is of type is of type Name: Radar generated from Name: radarservice generated from meta model level

Vorkommen in AUTOSAR-Releases (1)

Release Dokument Seite Nr. Bildunterschrift im Dokument
R18-03_R1.4.0 AUTOSAR_EXP_ARAComAPI S. 85 7.6 Figure 7.6: meta-model to Implementation