One of the challenges in developing an infotainment system in automotive is being able to verify that the system behaves as expected when interacting with the rest of the car. By connecting the infotainment module to a virtual car, with the ability to playback signals from recorded drives and respond to inputs as a real car, you unlock a powerful capability to validate the system very early in development.

[nfobox]

• RemotiveTopology: A tool that very easily allows you to define, run and test software-defined vehicles long before you have access to hardware.
• Android Cuttlefish: A highly configurable virtual Android device that behaves like it runs on hardware.

[/nfobox]

This blog post demonstrates how you can leverage RemotiveTopology to spin up a software-defined vehicle that includes an Android Automotive Cuttlefish device on a developer laptop and run tests to verify the communication between Android and the other components.

To demonstrate how easy it is to integrate Cuttlefish with RemotiveTopology, there exists a prepared containerized reference Cuttlefish build (Trout Android 15).

Note that running Cuttlefish locally requires support for Linux KVM virtualization. The example can easily be adjusted to use an external Cuttlefish instance, for example, in a cluster where multiple Cuttlefish instances run in parallel.

Preparing the vehicle platform for Android

This example uses the Cuttlefish variation of the Android example, which adds a Cuttlefish Docker container to an example platform. It demonstrates how to feed location signals from a recorded drive cycle into the Cuttlefish instance, how to interact with the temperature settings within Android, and view the resulting signals on the CAN bus, as well as how to integrate these components into a test that can run in a CI environment.

Before you run the example yourself, you will need to install the RemotiveTopology tool, as well as create a free trial account on RemotiveCloud. Follow the documentation to get started.

To prepare for running the vehicle platform involves using the platform files, which describe how the vehicle platform is structured, which components exist in it, and which communication channels are used, together with an instance file that specifies how to instantiate this platform. 

RemotiveTopology is used to process these files and generate a runnable instance. This comes in the result of a Docker compose file and the necessary configurations.

remotive-topology generate \
  -f remotive_car/instances/android/main.instance.yaml \                               
  -f remotive_car/instances/android/cuttlefish.instance.yaml \           
  -f remotive_car/instances/can_over_udp.instance.yaml \
  remotive_car/build

Note the use of a separate file to specify the details of how to instantiate Cuttlefish. The same pattern could be used to manage multiple ways of running Cuttlefish, allowing you to easily reconfigure how you run the topology by including a different instance file.

The included Cuttlefish reference build does not include any navigation app, which you will likely want to verify location. To install one, download an APK, e.g. Organic Maps, and place it in the folder "remotive_car/instances/android/cuttlefish/apks/" and it will be installed when Cuttlefish starts.

Launching the vehicle topology with Android containerized (Cuttlefish instance) 

Once the topology is generated, running the complete example is as simple as running a Docker compose up command. This will spin up containers for all the components included in the topology, including the Cuttlefish instance.

export CLOUD_URL=$(./remotive_car/instances/android/run.sh my-demo 9459066702917749000)
CLOUD_AUTH=$(remotive cloud auth print-access-token) \
docker compose -f remotive_car/build/remotive_car_android/docker-compose.yml \
  -f remotive_car/instances/android/cuttlefish.compose.yaml \
  --profile jupyter \
  --profile ui \
  --profile cloudfeeder \
  up --build

Once started you should see that the Cuttlefish instance is ready in the logs and be able to access the Cuttlefish UI on https://localhost:1443. The initial screen will be a bit empty due to the lack of a navigation app but when opening the maps app that was installed you should be able to see the location. This location is being streamed from a recording to the TCU component. From there it passes through a CAN bus and a SOMEIP network before it reaches the Cuttlefish GNSS proxy.

If you make changes to the temperature settings in the Cuttlefish UI, it will send out signals of the updated temperature over a SOMEIP network and a CAN bus until it reaches the HVAC component. You can observe this by using the signal viewer in the RemotiveStudio application which is started as part of the topology and located at http://localhost:8080.

Validating Android-to-Vehicle communication

In the folder "remotive_car/tests/pytest/android/" there are two sample tests that demonstrate how you can test the integration between Android and the other vehicle systems.

The tests use ADB commands to instrument the Cuttlefish instance to open activities, click on buttons and to extract data points. It uses the RemotiveTopology APIs to inject or read signals from the ECUs in the topology. By combining these you can inject signals in one end and verify that they have correctly transmitted and processed within the entire platform.

The example below tests taps on the temperature buttons within Cuttlefish and verifies that the HVAC ECU will receive the updated temperature signal.

async def test_update_hvac_left_temperature(broker_client: BrokerClient, adb_device: AdbDevice):
    # Click the decrease temperature button on the left side of the UI
    adb_device.shell("input tap 280 750")

    # Wait until updated signal is received on CAN bus
    sub = await broker_client.subscribe(("HVAC-BodyCan0", ["HVACControl.LeftTemperature"]))
    await await_at_most(seconds=5).until(
        partial(take_values, sub),
        equal_to({"HVACControl.LeftTemperature": 16.5}),
    )

This unlocks the developer to test the integration between Android and the car before having access to hardware. To further speed up development you can start the topology, run the tests and shut it down again, all with a single docker compose command.

docker compose \
  -f remotive_car/build/remotive_car_android/docker-compose.yml \
  -f remotive_car/instances/android/cuttlefish.compose.yaml \
  --profile tester \
  up --build \
  --exit-code-from=tester \
  --abort-on-container-exit

This makes it very easy to integrate this test into a CI environment. Simply generate the topology and run it with the tester profile within your standard CI pipelines.

‍