Figure 4.1: Example: VSS Signal Vehicle Speed

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: Datenmodell-Deklaration / Datenpunkt-Definition im YAML-Format (Spezifikationsauszug).
• Architektur-Kontext: AUTOSAR Adaptive Platform (AP), Dokument AUTOSAR_AP_EXP_AutomotiveAPI. Das Schaubild definiert ein exemplarisches Datenelement der Vehicle Signal Specification (VSS, COVESA-Standard).
• Funktionale Einordnung: Die Automotive API abstrahiert heterogene fahrzeuginterne Bus-Signale (CAN, LIN, FlexRay, SOME/IP) in eine standardisierte, domänenzentrierte Baumstruktur. Sie stellt Adaptive Applications über standardisierte Service-Schnittstellen semantisch eindeutige Fahrzeugzustandsdaten bereit.

2. Komponenten, Entitäten & Schnittstellen

• Entität / Knoten: Speed – repräsentiert einen Blattknoten (Leaf Node) im hierarchischen VSS-Baum (vollständiger Pfad i. d. R. Vehicle.Speed).
• Metadaten-Attribute:
  • datatype: float: Primitiver Datentyp nach IEEE 754 (Single-Precision Floating-Point, im AP-Kontext ara::core::Float bzw. float32).
  • type: sensor: VSS-Knotenkategorie. Kennzeichnet die Entität als reinen Messwert / Zustand der Fahrzeugsensorik mit Read-Only-Semantik (Abgrenzung zu actuator oder attribute).
  • unit: km/h: Physikalische Referenzeinheit (Kilometer pro Stunde).
  • description: Vehicle speed.: Semantische Spezifikation für Dokumentations- und Tooling-Zwecke.
• Beziehungen & Kardinalitäten: 1:1-Zuordnung der Metadaten zum Signal Speed. Der Knoten ist hierarchisch dem Wurzelobjekt Vehicle untergeordnet.

3. Dynamisches Verhalten & Sequenzablauf

• Interaktionsmuster: Asynchrones Publish/Subscribe sowie synchrones/asynchrones Request/Response (Get-Semantik) über die Automotive API-Laufzeitumgebung.
• Zugriffssteuerung:
  • Read-Zugriff (Get / Subscribe): Zulässig. Benachrichtigung bei Wertänderung (OnChange) oder zyklisch über konfigurierbare Abtastintervalle.
  • Write-Zugriff (Set): Nicht zulässig. Aufgrund der Klassifizierung type: sensor muss jeder schreibende Zugriff vom Automotive-API-Stack mit einem Fehler (z. B. kReadOnly / kPermissionDenied) quittiert werden.
• Fehlerpfade: Ungültige oder nicht verfügbare Sensorsignale (SNA / Signal Not Available auf Busebene) werden stack-intern in definierte Qualitäts- bzw. Fehlerzustände übersetzt.

4. Normative Relevanz & Entwickler-Hinweise

• Applikations-Entwickler (Adaptive Application):
  • Datentypabbildung auf C++-Ebene erfordert float (32-Bit). Keine Konvertierung von Rohdaten/Skalierungsfaktoren in der Applikationslogik erforderlich; der Wert liegt bereits physikalisch in km/h vor.
  • Nur Lese- und Beobachter-Mechanismen implementieren; keine Stellbefehle an Vehicle.Speed absetzen.
• Stack- & Integrations-Entwickler (Automotive API Provider / Gateway):
  • Signalkonvertierung: Rohsignale aus PDUs (z. B. Festkommawerte mit Skalierung und Offset wie uint16_t mit LSB = 0,01) müssen durch den Provider linear in einen IEEE 754 float-Wert in km/h transformiert werden.
  • Signalqualität & Fehlerbehandlung: Bus-spezifische Fehlerwerte (z. B. 0xFFFF bei Signal-Timeout oder Ausfall des Raddrehzahlsensors) dürfen nicht unplausibel als Fließkommazahl durchgereicht werden, sondern müssen zu entsprechenden AP-spezifischen Fehlerzuständen (ara::core::Result<float>) führen.
  • Filterung & Lastkontrolle: Da Speed hochfrequent aktualisiert wird, sind im API-Stack Schwellwertfilter (Hysterese) oder Rate-Limiting vorzusehen, um ein Überfluten des IPC-Kanals zu verhindern.