VSIDL Provider for reflection

VSIDL Provider, लाइब्रेरी और टूल का एक सेट है. इसकी मदद से, सर्विस बंडल, SDV प्लैटफ़ॉर्म एजेंट (डाइग्नोस्टिक्स, टेलीमेट्री, और SOME/IP) को VSIDL-डिक्लेयर्ड मेटाडेटा उपलब्ध करा सकते हैं.

खास तौर पर, VSIDL की सुविधा देने वाली कंपनी, SDV एजेंट को यह मेटाडेटा ढूंढने में मदद करती है:

• VSIDL कैटलॉग में इस्तेमाल किए गए मैसेज और सेवाओं के प्रोटोबफ़ डिस्क्रिप्टर
• SOME/IP मैपिंग
• सेवा बंडलों के लिए, गड़बड़ी की जानकारी देने वाले एलान

सेवा बंडल डेवलपर के लिए VSIDL Provider गाइड

VSIDL Provider लाइब्रेरी ये कार्रवाइयां करती है.

• यह दो खास जगहों पर फ़ाइलें ढूंढता है:
  • sdv_service_bundle_metadata में तय किए गए पाथ में मौजूद Apexes.
  • स्टैटिक पाथ में मौजूद इमेज पर.
• यह एक ही या अलग-अलग वीएम पर मौजूद एजेंटों के लिए, एपीआई से क्वेरी करने के लिए आरपीसी कॉल शुरू करता है.

अगर आपको सेवा का बंडल बनाना है, तो आपको VSIDL Provider लाइब्रेरी के बारे में खास जानकारी जानने की ज़रूरत नहीं है. इन चरणों को फ़ॉलो करें. इससे VSIDL Provider को रनटाइम के दौरान ज़रूरी फ़ाइलें मिल जाएंगी.

कैटलॉग के लिए रनटाइम कॉन्फ़िगरेशन जनरेट करें

तीनों तरह की फ़ाइलें (वीएसआईडीएल स्कीमा, डाइग्नोस्टिक्स डेक्लेरेशन, समआईपी मैपिंग) vsidl_rc_generator टूल से जनरेट होती हैं.

vsidl_rc_generator के लिए इस्तेमाल किए गए पैरामीटर के साथ-साथ, vsidl_rc_generator होस्ट बाइनरी टूल का इस्तेमाल करें. साथ ही, इन अतिरिक्त पैरामीटर का इस्तेमाल करें:vsidlc

• --variant runtime-config-prebuilts
• --filegroup का इस्तेमाल करके, फ़ाइल ग्रुप के उस टारगेट नाम के बारे में बताएं जिसमें कैटलॉग की सभी फ़ाइलें शामिल हैं. इनमें Android.bp भी शामिल है.

रेफ़रंस के लिए, काम के vsidlc पैरामीटर यहां दिए गए हैं:

• --catalog-path का इस्तेमाल कैटलॉग के रूट पाथ के बारे में बताने के लिए किया जाता है.
• --dependency-catalog-path का इस्तेमाल करके, डिपेंडेंट कैटलॉग तय करें.
• -- -path का इस्तेमाल करके यह तय करें कि जनरेट किए गए सभी genrule और prebuilt_etc टारगेट के साथ Android.bp को कहां लिखना है.

जनरेटर, काम के genrule और prebuilt_etc टारगेट के साथ एक Android.bp फ़ाइल बनाएगा. Android.bp में जनरेट किए गए टारगेट ब्लॉक के ऊपर, टिप्पणियां दिखेंगी. इनसे पता चलेगा कि उनके टारगेट का इस्तेमाल किस मकसद से किया गया है.

APEX के Android.bp को अपडेट करें

जनरेट की गई Android.bp फ़ाइल की टिप्पणियों के मुताबिक, यह फ़ाइल:

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

आपको इन टारगेट (Usage टिप्पणियों के नीचे दिए गए) को उस Android.bp में जोड़ना चाहिए जो Apex को तय करता है:

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

}

APEX के sdv_service_bundles_manifest.textproto को अपडेट करें

Apex की sdv_service_bundles_manifest.textproto फ़ाइलों के sdv_service_bundle_metadata ब्लॉक में, आपको इन पाथ के बारे में बताना होगा (सिर्फ़ लागू होने वाले पाथ के लिए):

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"
    ...
}

अपने पाथ तय न करें. इसके बजाय, जनरेट की गई Android.bp फ़ाइल की टिप्पणियों में दिखाए गए पाथ कॉपी करें. ये इस तरह दिखते हैं:

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

ऐसा करने से, VSIDL Provider इंस्टेंस, sdv_service_bundle_metadata की अलग-अलग एंट्री में दिए गए पाथ से क्वेरी कर पाता है.

इमेज में टारगेट जोड़ना

जनरेट की गई Android.bp फ़ाइलें, ऐसे टारगेट भी जनरेट करती हैं जिन्हें सीधे तौर पर इमेज पर लोड किया जा सकता है. टिप्पणियों में उन टारगेट के बारे में भी बताया जाता है जिनका इस्तेमाल इस तरह से किया जाना चाहिए. इसके लिए:

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

जनरेट किया गया prebuilt_etc टारगेट, genrule की मदद से जनरेट की गई फ़ाइलों को इमेज पर पहले से तय की गई जगह पर रखेगा. आपको *.mk फ़ाइलों में, prebuilt_etc टारगेट शामिल करने होंगे. जैसे, device/google/sdv/sdv_core_base/sdv_samples_automotive_services.mk.

प्लैटफ़ॉर्म डेवलपर के लिए VSIDL Provider Guide

आम तौर पर, अगर आपको ऐसा SDV एजेंट डेवलप करना है जिसमें रिफ़्लेक्शन की सुविधाएं हों, तो VSIDL प्रोवाइडर लाइब्रेरी का इस्तेमाल किया जा सकता है.

VSIDL Provider library API में ये फ़ंक्शन शामिल हैं:

    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>;

कहां

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

सभी फ़ंक्शन के लिए, source_fqin पैरामीटर का इस्तेमाल करके क्वेरी की जाती है. इससे यह पक्का होता है कि एक ही unit_type या message_name का इस्तेमाल करने वाले अलग-अलग FQIN, सही डेटा दिखाते हैं. यह पैरामीटर, VSIDL की सेवा देने वाली कंपनी की लाइब्रेरी को उस खास APEX पर रीडायरेक्ट करता है जिसमें सबसे सटीक मैसेज स्कीमा मौजूद होता है. ऐसा करना ज़रूरी है, क्योंकि APEX को अलग-अलग अपडेट किया जाता है. साथ ही, वे एक ही प्रोटोबफ़ मैसेज या सेवा के लिए अलग-अलग स्कीमा का इस्तेमाल कर सकते हैं.

get_message_descriptor फ़ंक्शन का इस्तेमाल

यह सिर्फ़ बाहरी क्रेट से pub struct MessageDescriptor को दिखाता है. इसका इस्तेमाल रिफ़्लेक्शन के लिए किया जाता है. MessageDescriptor एक तरह का मेटाडेटा है. यह रिफ़्लेक्शन की सुविधा देता है. इससे रनटाइम के दौरान, प्रोटोबफ़ मैसेज की डाइनैमिक तरीके से जांच की जा सकती है और उनमें बदलाव किया जा सकता है.

get_publication_descriptor फ़ंक्शन का इस्तेमाल

यह फ़ंक्शन PublicationDescriptor दिखाता है, जो यह है:

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

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

size_metadata फ़ील्ड में, पब्लिकेशन के मैसेज के साइज़ और उसकी सीमाओं के बारे में जानकारी होती है. यह मेटाडेटा, VSIDL कॉन्फ़िगरेशन से लिया गया है.

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>,
}

get_rpc_method_descriptor फ़ंक्शन का इस्तेमाल

यह फ़ंक्शन RpcMethodDescriptor दिखाता है, जो यह है:

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

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

इस स्ट्रक्चर में, आरपीसी तरीके के अनुरोध और जवाब, दोनों के लिए MessageDescriptor होता है.

get_someip_mappings फ़ंक्शन का इस्तेमाल

यह फ़ंक्शन, आस-पास की SOME/IP सेवाओं की मैपिंग को वापस पाने के लिए है. इन्हें core_services/vsidl/protos/sdv/someip/v1/someip.proto में तय किया गया है.

get_diagnostics_declaration फ़ंक्शन का इस्तेमाल

यह गड़बड़ी की जानकारी से जुड़े एलान पाने का फ़ंक्शन है. ये एलान, core_services/vsidl/protos/sdv/diagnostics/v1/diagnostics_syntax.proto में तय किए जाते हैं

subscribe_availability_change_by_vm फ़ंक्शन का इस्तेमाल

यह फ़ंक्शन, किसी वर्चुअल मशीन के लिए उपलब्धता स्ट्रीम दिखाता है. यह एक ज़रूरी फ़ॉलबैक मेकेनिज़्म के तौर पर काम करता है. इसका इस्तेमाल तब करें, जब स्टैंडर्ड VSIDL Provider API कॉल में SdvStatusCode::Unavailable गड़बड़ी हो. इससे सिस्टम, VSIDL provider interface के फिर से ऑनलाइन होने का इंतज़ार कर पाएगा.

इस फ़ंक्शन के मुख्य व्यवहारों में ये शामिल हैं:

• तुरंत सूचना: सदस्यता लेने पर, स्ट्रीम टारगेट वर्चुअल मशीन के उपलब्ध होने की मौजूदा स्थिति की सूचना देती है.
• व्यवहार में समानता: स्ट्रीम का नतीजा, ServiceDiscoveryManager के इस्तेमाल किए गए subscribe_service_unit_change_by_name फ़ंक्शन के जैसा ही होता है.

VSIDL Provider Agent

हर वीएम, अपना VSIDL Provider एजेंट चला रहा है. यह एक आरपीसी सर्वर है, जो VSIDL Provider API (एजेंट में मौजूद लाइब्रेरी के लोकल इंस्टेंस का) पर अनुरोध फ़ॉरवर्ड करता है. इस एजेंट का इस्तेमाल, किसी दूसरी वीएम पर मौजूद VSIDL प्रोवाइडर से क्वेरी करने के लिए किया जाता है. इसका मतलब है कि एक वीएम पर मौजूद कोई सेवा, इस एजेंट का इस्तेमाल करके किसी दूसरी वीएम से VSIDL मेटाडेटा के बारे में क्वेरी कर सकती है.

कोडबेस में एपीआई का इस्तेमाल

SOMEIP:

• get_publication_descriptor (सभी स्ट्रक्चर फ़ील्ड इस्तेमाल किए जाते हैं)
• get_rpc_method_descriptor (सभी स्ट्रक्चर फ़ील्ड इस्तेमाल किए जाते हैं)
• get_someip_mappings

टेलिमेट्री:

• get_publication_descriptor (सिर्फ़ message_descriptor फ़ील्ड का इस्तेमाल किया जाता है)
• get_rpc_method_descriptor (सभी स्ट्रक्चर फ़ील्ड इस्तेमाल किए जाते हैं)

गड़बड़ी की जानकारी:

• get_message_descriptor
• get_diagnostics_declaration

अलग-अलग डेटा सोर्स और सोर्स की प्राथमिकता के हिसाब से अलग-अलग फ़्लेवर, core_services/vsidl/provider/src/vsidl_provider.rs में देखे जा सकते हैं.

vsidl_provider क्रेट, अलग-अलग एसडीवी एजेंट के लिए, प्रोवाइडर इंस्टेंस बनाने के लिए कई सार्वजनिक फ़ंक्शन उपलब्ध कराता है. हर कॉन्फ़िगरेशन में, VSIDL से जुड़े डेटा को हल करने के लिए, डेटा सोर्स की एक यूनीक चेन होती है. इस टेबल में, हर कंस्ट्रक्टर फ़ंक्शन के व्यवहार के बारे में बताया गया है:

टेबल के डेटा सोर्स, पहली इमेज में दिए गए कॉल से जुड़े हैं.