Integrate the scalable service-oriented middleware over IP (SOME/IP) with software defined vehicle (SDV) by deploying and configuring several components. Each broker instance requires a corresponding local stack implementation. This document describes how to:
- Configure a single broker deployment
- Deploy the SOME/IP broker as a single or as multiple instances
- Deploy the vehicle services interactive data language (VSIDL) agent
- Use Soong with
vsidl_rc_generator
Example configuration
The SDV examples, such as those for Cuttlefish virtual Android devices
sdv_core_cf and hardware sdv_core_arm64, demonstrate a flexible deployment
schema. The broker and stack each start based on a boot time system property,
ro.boot.sdv.someip.enable.
You can achieve a single broker deployment schema by setting
androidboot.sdv.someip.enable=true on only one of the SDV instances running on
the system.
# device/google/sdv/sdv_core_base/sdv.agents.rc
# Declare and start the SDV SOME/IP broker agent.
service sdv_someip_broker_agent /system_ext/bin/sdv_someip_broker_agent_comms
class core
disabled
user system_ext_sdv_someip
group system
on property:ro.sdv.orchestrator.state.ready=true && property:ro.boot.sdv.someip.enable=true
start sdv_someip_broker_agent
Another example:
#device/google/sdv/sdv_core_cf/init.sdv_core_cf.rc
# Declare and start the sample SDV SOME/IP stack agent.
service sdv_someip_stack_agent /vendor/bin/sdv_someip_stack_agent
class core
disabled
user system
group system
setenv VSOMEIP_CONFIGURATION /vendor/etc/someip/vsomeip_config.json
setenv VSOMEIP_BASE_PATH /data/vendor/vsomeip/
on property:dev.bootcomplete=1 && property:ro.boot.sdv.someip.enable=true
start sdv_someip_stack_agent
Broker deployment
You can deploy the SOME/IP broker as a single or as multiple instances in SDV. You can split SOME/IP domains (or subnets) into different independent instances. You can do this to balance load or to improve isolation for security purposes.
Each instance must process a disjointed set of SOME/IP and SDV endpoints. You can't use special routing or cross-agent synchronization. An improper configuration can lead to duplicate publications or inconsistent service discovery results.
Vehicle services interactive data language provider
SOME/IP gets metadata required for translations from the VSIDL agent. You must deploy the VSIDL agent to the same VM as the SOME/IP broker.
When used with the runtime-config-prebuilts variant option, the VSIDL agent
can generate an Android.bp file. This file contains prebuilt rules that build
and deploy the relevant runtime configuration.
Soong
To run vsidl_rc_generator provided by SDV:
vsidl_rc_generator [OPTIONS] --catalog-path <CATALOG_PATH> --output-path <OUTPUT_PATH>
You must supply these arguments:
--vsidl-path <VSIDL_PATH>--catalog-path <CATALOG_PATH>--output-path <OUTPUT_PATH>
You can also provide these optional arguments:
Optional:
--dependency-catalog-path <DEPENDENCY_CATALOG_PATH>...Specifies the directories of the dependent protos outside the
catalog_path. To generate the Rust API for the dependent protos, each directory must contain anAndroid.bpfile. This file must include arust_protobufbuild target.Optional:
--variant <VARIANT>Defaults to
RuntimeConfigand specifies the mode in which the runtime config generator must run.RuntimeConfiggenerates runtime config files for SOME/IP and diagnostics.RuntimeConfigPrebuiltsgenerates build files. These files contain prebuilt modules. You can use these modules to include files generated by theRuntimeConfigvariant in other modules or in the VM image.Optional:
--service-bundle-name <SERVICE_BUNDLE_NAME>Argument to specify the service bundle on which to apply the runtime config generator.
Optional:
--package-name <PACKAGE_NAME>In addition to the service bundle name argument, use this argument to specify the service bundle package name on which to apply the runtime config generator.
Optional:
--filegroup <FILEGROUP>Must be defined when using the
RuntimeConfigPrebuiltsmode.