Introduction: Beyond OBD-II with AAOS

In the rapidly evolving landscape of connected vehicles, traditional On-Board Diagnostics II (OBD-II) protocols, while foundational, present significant limitations for truly advanced telematics. OBD-II offers a standardized, albeit restricted, set of diagnostic trouble codes (DTCs) and parameters (PIDs) primarily for emissions-related diagnostics and basic engine data. It’s often too slow, too generic, and too limited in scope to satisfy the demands of modern automotive applications requiring granular, real-time, and custom vehicle data for predictive maintenance, usage-based insurance, advanced diagnostics, or bespoke in-car services.

Android Automotive OS (AAOS) emerges as a powerful platform to transcend these limitations. By directly integrating with the vehicle’s underlying hardware abstraction layers, AAOS allows developers to tap into a much richer and more diverse set of vehicle data. This article will guide you through the process of designing and implementing custom diagnostic data streams within AAOS, moving beyond the constraints of OBD-II to unlock the full potential of vehicle telematics.

The AAOS Telematics Ecosystem: Core Components

Understanding the key architectural components of AAOS is crucial for crafting custom data streams:

• Vehicle Hardware Abstraction Layer (VHAL): The bedrock of vehicle interaction in AAOS. VHAL abstracts away the specifics of the underlying vehicle ECUs and provides a standardized interface for Android services and applications to read from and write to vehicle properties. It supports various data types, change modes (static, on-change, continuous), and access levels.
• CarService: The central Android framework service that acts as an intermediary between Android applications and the VHAL. Applications interact with CarService managers (e.g., CarPropertyManager) to access vehicle properties without directly touching the VHAL.
• Android Interface Definition Language (AIDL): Used for inter-process communication (IPC) between different components, especially when defining custom interfaces between Android services and your custom HAL implementations.
• Custom HALs: While VHAL covers many standard vehicle properties, specific or proprietary vehicle data might require extending VHAL or implementing a custom HAL to expose unique data points.

Step 1: Defining Custom Vehicle Properties in VHAL

The first step involves defining your custom vehicle properties within the VHAL framework. This requires modifying the VHAL interface definition, specifically the types.hal file, which enumerates all available vehicle properties. For this example, let’s imagine we want to monitor individual battery cell voltages in an electric vehicle, a data point not typically available via standard OBD-II.

You would add your custom property ID to the VehicleProperty enum. Property IDs typically start with 0x2 for vendor-specific properties to avoid conflicts with standard properties.

// In hardware/interfaces/automotive/vehicle/2.0/types.hal or a custom vendor extension .hal file

enum VehicleProperty: int32 {    // ... existing standard properties    // Custom Vendor Properties (start at 0x2000 for vendor space)    CUSTOM_BATTERY_CELL_VOLTAGE = 0x2112; // Example: Individual battery cell voltage    CUSTOM_MOTOR_TORQUE_COMMAND = 0x2113; // Example: Commanded motor torque}

When defining your property, consider its:

• Data Type: (e.g., float, int32, string, complex struct)
• Access Mode: READ, WRITE, or READ_WRITE
• Change Mode:STATIC (value doesn’t change), ON_CHANGE (value changes only when triggered by hardware), or CONTINUOUS (value changes frequently, reported at a specific rate). For a sensor reading like battery voltage, ON_CHANGE or CONTINUOUS is appropriate.
• Area: GLOBAL or tied to specific vehicle areas (e.g., SEAT, WINDOW).

Step 2: Implementing the Custom Property in Your VHAL

After defining the property, you need to implement its behavior within your VHAL. This typically involves modifying an existing VHAL implementation (e.g., the reference DefaultVehicleHal.cpp or your OEM-specific HAL). You will need to:

1. Declare the property’s configuration: Provide metadata about your custom property.
2. Handle read requests (`onGetProperty`): When an application requests the property’s value, your HAL must fetch it from the underlying hardware or simulate it.
3. Publish value changes (`sendPropertyEvent`): For ON_CHANGE or CONTINUOUS properties, your HAL must actively monitor the physical sensor and notify CarService when the value changes.

// Snippet from a VHAL implementation (e.g., DefaultVehicleHal.cpp or custom HAL)// Add to kVehicleProperties or similar configuration listconst std::vector<VehiclePropertyStore::ConfigInfo> kCustomVehicleProperties = {    {        .property = VehicleProperty::CUSTOM_BATTERY_CELL_VOLTAGE,        .access = VehiclePropertyAccess::READ,        .changeMode = VehiclePropertyChangeMode::ON_CHANGE,        .area = VehiclePropertyArea::GLOBAL,        .minSampleRate = 0.5, // Report at least every 2 seconds if changed        .maxSampleRate = 5.0, // Report up to 5 times per second if changed    },    // ... other custom properties};

// In your VehicleHal::getProperty implementation (simplified)    if (property == VehicleProperty::CUSTOM_BATTERY_CELL_VOLTAGE) {        // In a real scenario, this would read from a CAN bus, LIN bus, or specific ECU driver        // For simulation:        float simulatedVoltage = getSimulatedBatteryCellVoltage(); // A function to get or simulate the value        outValue->floatValues.push_back(simulatedVoltage);        return true;    }

// In a separate thread or hardware interrupt handler for 'ON_CHANGE' propertiesvoid sendBatteryVoltageUpdates(IVehicleCallback* callback) {    float previousVoltage = -1.0f;    while (true) {        float currentVoltage = getActualBatteryCellVoltage(); // Read from hardware        if (currentVoltage != previousVoltage) {            VehiclePropValue eventValue;            eventValue.prop = static_cast(VehicleProperty::CUSTOM_BATTERY_CELL_VOLTAGE);            eventValue.timestamp = elapsedRealtimeNano();            eventValue.value.floatValues.push_back(currentVoltage);            callback->onPropertyEvent({eventValue}); // Notify CarService            previousVoltage = currentVoltage;        }        std::this_thread::sleep_for(std::chrono::milliseconds(200)); // Sample every 200ms    }}

Step 3: Integrating with CarService and Android Applications

With the custom property defined and implemented in the VHAL, Android applications can now access it via CarService. The CarPropertyManager class is the primary interface for applications to interact with vehicle properties.

// Android application (Java/Kotlin)import android.car.Car;import android.car.VehiclePropertyIds; // For standard properties, but not custom onesimport android.car.hardware.CarPropertyConfig;import android.car.hardware.CarPropertyEvent;import android.car.hardware.CarPropertyManager;import android.util.Log;public class TelematicsClient {    private static final String TAG =

        
        
        

            

                
            
            

                
Android Mobile Specs & Compare Directory
                
Are you researching mobile hardware properties, processor SoCs, GPU chipsets, or RAM configurations? Access our complete specs catalog to compare up to 5 devices side-by-side!
                Compare Devices Specs →