DEENESPTFRRUARHIKOZHNL
AUTOSAR_CP_TR_VFB FIG-db24469ba7dd76e6 519 × 369 px 1 Release(s)

Figure 7.1: A software component accesses services of the Os

SHA-256 Inhalts-Fingerabdruck: db24469ba7dd76e6ccce5ab9609f0d9f3aae3ffe5721296e601036a53ee52206

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

  • Diagrammtyp: VFB-Komponentendiagramm / Schnittstellenspezifikation (AUTOSAR Virtual Functional Bus Notation).
  • Architektur-Kontext: AUTOSAR Classic Platform (VFB-Spezifikation, Kapitel AUTOSAR Services).
  • Technischer Zweck: Modellierung des standardisierten Zugriffs einer Applikations-Softwarekomponente (SW-C) auf Basisfunktionen des Betriebssystems (AUTOSAR OS) über den RTE-Abstraktionsmechanismus anstelle direkter nativer C-API-Aufrufe.

2. Komponenten, Entitäten & Schnittstellen

  • ApplicationMonitor:
    • Stereotyp/Metaklasse: ApplicationSwComponentType (symbolisiert durch das AUTOSAR-Komponenten-Piktogramm oben rechts).
    • Funktionalität: Überwachungs- bzw. Diagnosekomponente zur Abfrage von System- und Betriebsmodi.
  • Ports an ApplicationMonitor:
    • os (Required Port / RPortPrototype): Dargestellt als Socket-/Halbkreis-Symbol; fordert die Operationen eines Client-Server-Dienstes an.
    • Zweiter Port (Kasten mit abwärts gerichtetem Dreieck): Dargestellt in VFB-Notationskonvention für Empfangs- bzw. Trigger-Schnittstellen (PRPortPrototype / Datenempfang).
  • Schnittstelle OsService:
    • Stereotyp/Metaklasse: <<Interface>> (ClientServerInterface), typisiert den Port os (Assoziation via gestrichelter Typisierungs-/Abhängigkeitslinie).
    • Client-Server-Operationen (ClientServerOperation):
      • GetActiveApplicationMode(OUT AppModeType CurrentMode): Rückgabe des aktuell aktiven OS-Startmodus (AppModeType) über einen Out-Parameter.
      • GetApplicationState(IN ApplicationType Application, OUT ApplicationStateType Value, ERR{E_OS_ID}):
        • Input: Application (ApplicationType) – Identifier der zu prüfenden OS-Application.
        • Output: Value (ApplicationStateType) – Aktueller Zustand der referenzierten OS-Application.
        • Fehlersemantik: Standardisierter ApplicationError E_OS_ID bei ungültiger oder nicht existenter Application-Kennung.

3. Dynamisches Verhalten & Sequenzablauf

  1. Trigger & Aufruf:
    • Ein Runnable Entity innerhalb von ApplicationMonitor initiiert die Abfrage über das generierte RTE-API, z. B. Rte_Call_os_GetApplicationState(appId, &state).
  2. Synchroner Pfad:
    • Der Aufruf wird standardmäßig als blockierender Client-Server-Call durch die RTE dispatcht.
    • Die RTE leitet die Anfrage an den Service-Provider (die OS-Service-Component bzw. das BSW-Modul Os) weiter.
  3. Ergebnis- & Fehlerbehandlung:
    • Validiert das OS den Parameter Application als ungültig, bricht die Operation ab und liefert den im Interface spezifizierten Fehlercode E_OS_ID (RTE-Returnwert: RTE_E_OsService_E_OS_ID).
    • Bei erfolgreicher Ausführung schreibt das OS den aktuellen Status in Value und signalisiert RTE_E_OK.

4. Normative Relevanz & Entwickler-Hinweise

  • Entkopplung & Portabilität: Direkte Aufrufe von OS-System-APIs (wie GetApplicationState() aus Os.h) verletzen das VFB-Paradigma und führen zu statischer Bindung. Durch das OsService-Interface bleibt die Komponente ECU-agnostisch und im VFB-Level testbar/mockbar.
  • RTE- & Service-Konfiguration:
    • Der Port os der SW-C muss im EcuExtract über einen ServiceConnector an die ServiceComponent des AUTOSAR OS angebunden werden.
    • Die Typen AppModeType, ApplicationType und ApplicationStateType sowie der Fehler E_OS_ID müssen im BSW- und Application-Datentypkatalog (Platform_Types.h / Rte_Type.h) konsistent deklariert sein.
  • Laufzeit- & Task-Restriktionen:
    • Da synchrone Rte_Call-Operationen blockierend wirken, muss die aufrufende Task über entsprechende Warte-/Event-Mechanismen verfügen (Extended Task erforderlich bei Blocking Call) oder das Interface asynchron mit Callbacks/Result-Polling konfiguriert werden.
    • OS-Speicherschutzgrenzen (Memory Protection / Trusted vs. Non-Trusted Applications) müssen den lesenden Zugriff auf den Zustand anderer OS-Applications explizit gestatten.

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

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

Keine inhaltlichen Änderungen erkennbar.

Zugeordnete Anforderungen

Diese Angaben zeigt der Versions-Explorer.

Aus dem Dokument extrahierter Text & Kontext

Begleitender Spezifikationstext:

Virtual Functional Bus AUTOSAR CP R25-11 7 AUTOSAR Services 7.1 Introduction This section describes the handling of AUTOSAR services in the VFB view and defines how they can be represented graphically. AUTOSAR services depict a hybrid concept composed of Basic Software Modules as well as of AUTOSAR Software Components. They provide standardized functionality of the particular ECU infrastructure (AUTOSAR BSW) for Application Software Components mapped onto it. For the sake of simplicity sometimes the term "service" is used instead of the full term "AUTOSAR service". However, it has nothing to do with the service part of a clientserver interface. Figure 7.1: A software component accesses services of the Os Figure 7.1 shows an example for requiring a service: the software component type ApplicationMonitor has a port typed with the interface OsService. Since this clientserver interface contains operations like GetActiveApplicationMode or GetApplication State, the software component ApplicationMonitor is able to query the Os about the Os Application states or the Os start mode. Figure 8.4 shows another example: here, the software component has access to the ECU state manager of the ECU Basic Software and its capabilities. 7.2 VFB Representation When it comes to model and configure AUTOSAR services main challenges are: • the selection of appropriate communication paradigm, • the fulfillment of prerequisites defined by RTE (see [6]) • the platform dependent types 89 of 131 Document

Vorkommen in AUTOSAR-Releases (1)

Release Dokument Seite Nr. Bildunterschrift im Dokument
R25-11 AUTOSAR_CP_TR_VFB S. 89 7.1 Figure 7.1: A software component accesses services of the Os