VSIDL-Anbieter für die Reflektion

Der VSIDL-Anbieter ist eine Reihe von Bibliotheken und Tools, mit denen Dienstpakete den SDV-Plattform-Agents (Diagnose, Telemetrie und SOME/IP) VSIDL-deklarierte Metadaten zur Verfügung stellen können.

Insbesondere ermöglicht der VSIDL-Anbieter SDV-Agents, die folgenden Metadaten zu ermitteln:

• Protobuf-Deskriptoren von Nachrichten und Diensten, die im VSIDL-Katalog verwendet werden
• SOME/IP-Zuordnungen
• Diagnosedeklarationen von Dienstpaketen

Anleitung zum VSIDL-Anbieter für Entwickler von Dienstpaketen

Die VSIDL-Anbieterbibliothek führt die folgenden Vorgänge aus.

• Sucht Dateien an zwei bestimmten Speicherorten:
  • In Apexes in Pfaden, die in sdv_service_bundle_metadata definiert sind.
  • Im Image in statischen Pfaden.
• Leitet RPC-Aufrufe ein, um die API auf Agents abzufragen, die sich auf derselben oder auf verschiedenen VMs befinden.

Wenn Sie ein Dienstpaket entwickeln, müssen Sie die Details der VSIDL-Anbieterbibliothek nicht kennen. Folgen Sie einfach dieser Anleitung, damit der VSIDL-Anbieter die benötigten Dateien zur Laufzeit finden kann.

Laufzeitkonfigurationen für den Katalog generieren

Alle drei Dateitypen (VSIDL-Schemas, Diagnosedeklarationen, SOME/IP-Zuordnungen) werden mit dem Tool vsidl_rc_generator generiert.

Verwenden Sie das binäre Hosttool vsidl_rc_generator mit denselben Parametern wie für vsidlc und den folgenden zusätzlichen Parametern:

• --variant runtime-config-prebuilts
• --filegroup , um den Zielnamen der Dateigruppe anzugeben, die alle Dateien des Katalogs enthält (einschließlich Android.bp).

Zur Referenz sind die relevanten vsidlc-Parameter die folgenden:

• --catalog-path, um den Stammpfad des Katalogs anzugeben.
• --dependency-catalog-path, um abhängige Kataloge anzugeben.
• -- -path , um anzugeben, wo die Datei Android.bp mit allen generierten genrule- und prebuilt_etc-Zielen geschrieben werden soll.

Der Generator erstellt eine Android.bp-Datei mit relevanten genrule- und prebuilt_etc-Zielen. Über den generierten Zielblöcken in Android.bp befinden sich Kommentare, die die beabsichtigte Verwendung der jeweiligen Ziele angeben.

Android.bp von APEX aktualisieren

Wie in den Kommentaren der generierten Android.bp-Datei angegeben:

// Usage: add the following line to ... declaration

Sie sollten diese Ziele (unter den angegebenen Usage-Kommentaren) der Android.bp-Datei hinzufügen, die den Apex definiert:

apex {
    name: "some_apex_name",
    ...
    prebuilts: [
      // ADD THE prebuilt_etc TARGETS HERE
    ],
    ...

}

sdv_service_bundles_manifest.textproto von APEX aktualisieren

In den sdv_service_bundle_metadata-Blöcken der sdv_service_bundles_manifest.textproto-Dateien des Apex müssen Sie Folgendes definieren (nur für anwendbare Pfade):

sdv_service_bundle_metadata {
    ...
    vsidl_schemas_path: "etc/vsidl_provider/SomeFile-vsidl-config.binpb"
    diagnostics_config_path: "etc/vsidl_provider/SomeFile-diag-config.binpb"
    external_protocol_mapping_path: "etc/vsidl_provider/someip-config.binpb"
    ...
}

Definieren Sie keine eigenen Pfade. Kopieren Sie stattdessen die Pfade, die in den Kommentaren der generierten Android.bp-Datei angezeigt werden, und zwar so:

// + vsidl_schemas_path:
// + diagnostics_config_path:
// + external_protocol_mapping_path:

Dadurch kann die VSIDL-Anbieterinstanz Abfragen aus den Pfaden ausführen, die in den jeweiligen sdv_service_bundle_metadata-Einträgen angegeben sind.

Ziele zum Image hinzufügen

Die generierten Android.bp-Dateien generieren auch Ziele, die direkt in das Image geladen werden können. In den Kommentaren werden auch die Ziele angegeben, die auf diese Weise verwendet werden sollen, und zwar so:

// Usage: add this target to the VM image.

Das generierte prebuilt_etc-Ziel platziert Dateien, die mit den genrule-Regeln generiert wurden, an einem vordefinierten Speicherort im Image. Sie müssen die prebuilt_etc-Ziele in die entsprechenden *.mk-Dateien einfügen (z. B. device/google/sdv/sdv_core_base/sdv_samples_automotive_services.mk).

Anleitung zum VSIDL-Anbieter für Plattformentwickler

Wenn Sie einen SDV-Agent entwickeln, der Reflexionsfunktionen benötigt, können Sie die VSIDL-Anbieterbibliothek verwenden.

Die VSIDL-Anbieterbibliothek-API enthält die folgenden Funktionen:

    async fn get_publication_descriptor(
        &self,
        source_fqin: &ServiceFqin,
        unit_type: &UnitType,
    ) -> SdvResult<PublicationDescriptor>;

    async fn get_rpc_method_descriptor(
        &self,
        source_fqin: &ServiceFqin,
        unit_type: &UnitType,
        method_name: &str,
    ) -> SdvResult<RpcMethodDescriptor>;

    async fn get_message_descriptor(
        &self,
        source_fqin: &ServiceFqin,
        message_name: &str,
    ) -> SdvResult<MessageDescriptor>;

    async fn get_someip_mappings(&self, source_fqin: &ServiceFqin)
        -> SdvResult<Vec<SomeIpMapping>>;

    async fn get_diagnostics_declaration(
        &self,
        fqin: &ServiceFqin,
    ) -> SdvResult<DiagnosticsDeclaration>;

    async fn subscribe_availability_change_by_vm(
        &self,
        vm_name: &str,
    ) -> SdvResult<AvailabilityStream>;

wo

pub type AvailabilityStream = Pin<Box<dyn Stream<Item = AvailabilityChangeEvent> + Send>>;

Alle Funktionen werden mit einem source_fqin-Parameter abgefragt. Dadurch wird sichergestellt, dass verschiedene FQINs, die denselben unit_type oder message_name verwenden, die richtigen Daten zurückgeben. Der Parameter verweist die VSIDL-Anbieterbibliothek auf den spezifischen APEX, der das genaueste Nachrichtenschema enthält. Das ist erforderlich, da APEXes unabhängig aktualisiert werden und möglicherweise unterschiedliche Schemas für dieselbe Protobuf-Nachricht oder denselben Dienst verwenden.

Verwendung der Funktion get_message_descriptor

Diese Funktion gibt nur die pub struct MessageDescriptor aus der externen Crate zurück, die für die Reflexion verwendet wird. Ein MessageDescriptor ist ein Metadatenelement, das die Reflexion ermöglicht und die dynamische Überprüfung und Bearbeitung von Protobuf-Nachrichten zur Laufzeit ermöglicht.

Verwendung der Funktion get_publication_descriptor

Diese Funktion gibt einen PublicationDescriptor zurück, der Folgendes ist:

pub struct PublicationDescriptor {
    /// Message descriptor for publication.
    pub message_descriptor: MessageDescriptor,

    /// Information about the size of the publication message.
    pub size_metadata: SizeMetadata,
}

Das Feld size_metadata enthält Informationen zur Größe und zu den Einschränkungen der Nachricht einer Veröffentlichung. Diese Metadaten werden aus der VSIDL-Konfiguration abgeleitet.

pub struct SizeMetadata {
    /// Message size in bytes.
    pub message_size: u32,

    /// Message count.
    pub message_count: u32,

    /// VSIDL-declared size constraints for the message fields.
    pub field_size_constraints: HashMap<String, FieldSizeConstraint>,
}

pub struct FieldSizeConstraint {
    /// Max number of repeated fields allowed for the field.
    pub repeated_max_count: Option<u32>,

    /// Max size of variable sized types (string, bytes) in bytes.
    pub variable_type_max_size: Option<u32>,
}

Verwendung der Funktion get_rpc_method_descriptor

Diese Funktion gibt einen RpcMethodDescriptor zurück, der Folgendes ist:

pub struct RpcMethodDescriptor {
    /// Message descriptor for RPC request.
    pub request_message: Option<MessageDescriptor>,

    /// Message descriptor for RPC response.
    pub response_message: Option<MessageDescriptor>,
}

Dieser Struct enthält den MessageDescriptor für die Anfrage- und Antwortnachrichten der RPC-Methode.

Verwendung der Funktion get_someip_mappings

Dies ist eine Funktion zum Abrufen lokaler SOME/IP-Dienstzuordnungen, die in core_services/vsidl/protos/sdv/someip/v1/someip.proto definiert sind.

Verwendung der Funktion get_diagnostics_declaration

Dies ist eine Funktion zum Abrufen von Diagnosedeklarationen, die in core_services/vsidl/protos/sdv/diagnostics/v1/diagnostics_syntax.proto definiert sind.

Verwendung der Funktion subscribe_availability_change_by_vm

Diese Funktion gibt einen Verfügbarkeitsstream für eine bestimmte VM zurück, der als wichtiger Fallback-Mechanismus dient. Verwenden Sie sie, wenn Standard-VSIDL-Anbieter-API-Aufrufe mit dem Fehler SdvStatusCode::Unavailable fehlschlagen. So kann das System effizient warten, bis die VSIDL-Anbieterschnittstelle wieder online ist.

Zu den wichtigsten Verhaltensweisen dieser Funktion gehören:

• Sofortige Ausgabe:Nach dem Abonnieren gibt der Stream den aktuellen Verfügbarkeitsstatus der Ziel-VM aus.
• Verhaltensparität:Der resultierende Stream verhält sich identisch mit der Funktion subscribe_service_unit_change_by_name, die vom ServiceDiscoveryManager verwendet wird.

VSIDL-Anbieter-Agent

Auf jeder VM wird ein eigener VSIDL-Anbieter-Agent ausgeführt. Dabei handelt es sich im Wesentlichen um einen RPC-Server, der Anfragen an die VSIDL-Anbieter-API (einer lokalen Instanz der Bibliothek im Agent) weiterleitet. Der Agent wird verwendet, um den VSIDL-Anbieter auf einer anderen VM abzufragen. Das heißt, ein Dienst auf einer VM kann mit diesem Agent VSIDL-Metadaten von einer anderen VM abfragen.

Verwendung der API in der Codebasis

SOMEIP :

• get_publication_descriptor (alle Struct-Felder werden verwendet)
• get_rpc_method_descriptor (alle Struct-Felder werden verwendet)
• get_someip_mappings

Telemetrie :

• get_publication_descriptor (nur das Feld message_descriptor wird verwendet)
• get_rpc_method_descriptor (alle Struct-Felder werden verwendet)

Diagnose :

• get_message_descriptor
• get_diagnostics_declaration

Die verschiedenen Varianten mit den verschiedenen Datenquellen und Quellprioritäten finden Sie unter core_services/vsidl/provider/src/vsidl_provider.rs.

Die vsidl_provider-Crate bietet mehrere öffentliche Funktionen zum Erstellen von Anbieterinstanzen, die auf verschiedene SDV-Agents zugeschnitten sind. Jede Konfiguration gibt eine eindeutige Kette von Datenquellen an, um VSIDL-bezogene Daten aufzulösen. In der Tabelle wird das Verhalten der einzelnen Konstruktorfunktionen beschrieben:

Die Datenquellen der Tabelle beziehen sich auf Aufrufe in Abbildung 1.