Propiedades del vehículo

La interfaz de la capa de abstracción de hardware del vehículo (VHAL) define las propiedades que los OEM pueden implementar y contiene metadatos de propiedad (por ejemplo, si la propiedad es un int y qué modos de cambio están permitidos). La interfaz VHAL se basa en acceder (leer, escribir, suscribirse) a una propiedad, que es una abstracción para una función específica.

Interfaces HAL

El VHAL utiliza las siguientes interfaces:

• getAllPropConfigs() genera (vec<VehiclePropConfig>propConfigs)
  Enumere la configuración de todas las propiedades admitidas por VHAL. CarService utiliza únicamente propiedades admitidas.
• getPropConfigs(vec<int32_t> props) genera (StatusCode status,vec<VehiclePropConfig> propConfigs);
  Devuelve la configuración de las propiedades seleccionadas.
• set(VehiclePropValue propValue) genera (StatusCodestatus);
  Escribe un valor a la propiedad. El resultado de la escritura se define por propiedad.
• subscribe(IVehicleCallback callback, vec<SubscribeOptions> options) genera (StatusCode status);
  Comience a monitorear un cambio de valor de propiedad. Para la propiedad zonificada, unsubscribe(IVehicleCallback callback, int32_t propId) genera (StatusCode status);

VHAL utiliza las siguientes interfaces de devolución de llamada:

• oneway onPropertyEvent(vec<VehiclePropValue>propValues);
  Notifica el cambio de valor de la propiedad del vehículo. Debe hacerse sólo para propiedades suscritas.
• oneway onPropertySetError(StatusCode errorCode,int32_t propId,int32_tareaId);
  Devuelve un error de nivel VHAL global o un error por propiedad. El error global hace que HAL se reinicie, lo que puede provocar que se reinicien otros componentes (incluidas las aplicaciones).

Propiedades del vehículo

Las propiedades pueden ser de solo lectura, de solo escritura (se usan para pasar información al nivel VHAL) o de lectura y escritura (la compatibilidad con la mayoría de las propiedades es opcional). Cada propiedad se identifica de forma única mediante una clave int32 y tiene un tipo predefinido ( value_type ):

• BYTES
• BOOLEAN
• EPOCH_TIME
• FLOAT
• FLOAT[]
• INT32
• INT32[]
• INT64
• INT64[]
• STRING
• MIXED

Una propiedad zonificada puede tener más de un valor, según la cantidad de zonas admitidas por la propiedad.

Tipos de área

El VHAL define múltiples tipos de áreas:

Cada propiedad zonificada debe utilizar un tipo de área predefinido. Cada tipo de área tiene un conjunto de indicadores de bits definidos en una enumeración para el tipo de área. Por ejemplo, el área SEAT define las enumeraciones VehicleAreaSeat :

• ROW_1_LEFT = 0x0001
• ROW_1_CENTER = 0x0002
• ROW_1_RIGHT = 0x0004
• ROW_2_LEFT = 0x0010
• ROW_2_CENTER = 0x0020
• ROW_2_RIGHT = 0x0040
• ROW_3_LEFT = 0x0100
• ...

ID de área

Las propiedades zonificadas se abordan a través de ID de área. Cada propiedad zonificada puede admitir una o más ID de área. Un ID de área se compone de uno o más indicadores de su enumeración respectiva. Por ejemplo, una propiedad que utiliza VehicleAreaSeat podría utilizar los siguientes ID de área:

Estado de la propiedad

Cada valor de propiedad viene con un valor VehiclePropertyStatus . Esto indica el estado actual de la propiedad:

Configurar una propiedad

Utilice VehiclePropConfig para proporcionar información de configuración para cada propiedad. La información incluye:

Propiedades de la zona de manipulación

Una propiedad zonificada equivale a una colección de múltiples propiedades donde se puede acceder a cada subpropiedad con el valor de ID de área especificado.

• get llamada para propiedad zonificada siempre incluye el ID del área en la solicitud. Por lo tanto, solo se devuelve el valor actual del ID de área solicitado. Si la propiedad es global, entonces el ID de área es 0.
• La llamada set para propiedad zonificada siempre incluye el ID del área en la solicitud. Por lo tanto, sólo se cambia el ID de área solicitado.
• la llamada subscribe genera eventos para todos los ID de área de la propiedad.

recibir llamadas

Durante la inicialización, es posible que el valor de la propiedad aún no esté disponible porque aún no se ha recibido el mensaje de la red del vehículo coincidente. En tales casos, la llamada get debería devolver -EAGAIN . Algunas propiedades (como HVAC) tienen propiedades de encendido/apagado separadas. Llamar a get para dicha propiedad (cuando está apagado) debería devolver un estado UNAVAILABLE en lugar de devolver un error. Por ejemplo, obtenga temperatura HVAC

Figura 1 . Obtener la temperatura de HVAC (CS = CarService, VHAL = Vehicle HAL)

Establecer llamadas

En una operación típica, una llamada set conduce a realizar una solicitud de cambio a través de la red del vehículo. Idealmente, una llamada set es una operación asincrónica que regresa lo antes posible, pero también puede ser sincrónica. Algunas llamadas set pueden requerir que los datos iniciales estén listos, pero durante la inicialización, es posible que dichos datos no estén disponibles todavía. En tales casos, la llamada set debería devolver StatusCode#TRY_AGAIN . Algunas propiedades con encendido y apagado separados deben devolver StatusCode#NOT_AVAILABLE o StatusCode#NOT_AVAILABLE_DISABLED cuando la propiedad está apagada y no se puede set . Hasta que set entre en vigor, get no necesariamente devuelve el mismo valor que el set. Por ejemplo, set HVAC Temperature .

Figura 2 . Establecer la temperatura de HVAC (CS = CarService, VHAL = Vehículo HAL)

Manejo de propiedades personalizadas

Para satisfacer las necesidades específicas de los socios, VHAL permite propiedades personalizadas que están restringidas a aplicaciones del sistema. Utilice las siguientes pautas cuando trabaje con propiedades personalizadas:

• El ID de propiedad debe generarse utilizando los siguientes campos:
  • VehiclePropertyGroup:VENDOR
    El grupo VENDOR se utiliza sólo para propiedades personalizadas.
  • VehicleArea
    Seleccione un tipo de área apropiado.
  • VehiclePropertyType
    Seleccione el tipo de datos adecuado. El tipo BYTES permite el paso de datos sin procesar, lo cual es suficiente en la mayoría de los casos. El envío frecuente de big data a través de propiedades personalizadas puede ralentizar el acceso a toda la red de vehículos; tenga cuidado al agregar una carga útil grande.
  • Property ID
    Elija una ID de cuatro nibbles para la propiedad personalizada.
• Para evitar la fragmentación del ecosistema, no se deben utilizar propiedades personalizadas para replicar propiedades de vehículos que ya existen en el ( VehiclePropertyIds SDK).
• Complete VehiclePropConfig.configString con una breve descripción de la propiedad personalizada. Esto permite que las herramientas de control de idoneidad detecten la replicación accidental de propiedades de vehículos existentes. Por ejemplo, "estado de luz de emergencia".
• Acceso a través de CarPropertyManager (para componentes Java) o mediante la API de Vehicle Network Service (para nativos). No modifique las API de otros automóviles, ya que hacerlo puede generar problemas de compatibilidad en el futuro.
• Después de implementar las propiedades del proveedor, seleccione solo la lista de permisos en la enumeración VehicleVendorPermission para las propiedades del proveedor. La asignación de permisos de proveedores a las propiedades del sistema interrumpirá el CTS y el VTS.

Manejo de propiedades HVAC

Puede utilizar VHAL para controlar HVAC configurando propiedades relacionadas con HVAC. La mayoría de las propiedades HVAC son propiedades zonificadas, aunque varias son propiedades no zonificadas (globales). Las propiedades definidas de ejemplo incluyen:

Para ver una lista completa de propiedades de HVAC, busque VEHICLE_PROPERTY_HVAC_* en types.hal . Cuando la propiedad HVAC utiliza VehicleAreaSeat , se aplican reglas adicionales para asignar una propiedad HVAC zonificada a ID de área. Cada asiento disponible en el automóvil debe ser parte de un ID de área en la matriz de ID de área.

Ejemplo uno. Un automóvil tiene dos asientos delanteros ( ROW_1_LEFT, ROW_1_RIGHT ) y tres asientos traseros ( ROW_2_LEFT, ROW_2_CENTER, ROW_2_RIGHT ). El coche tiene dos unidades de control de temperatura: el lado del conductor y el lado del pasajero.

• Un conjunto de mapeo válido de ID de área para HVAC_TEMPERATURE SET es:
  • ROW_1_LEFT | ROW_2_LEFT
  • ROW_1_RIGHT | ROW_2_CENTER | ROW_2_RIGHT
• Una asignación alternativa para la misma configuración de hardware es:
  • ROW_1_LEFT | ROW_2_LEFT | ROW_2_CENTER
  • ROW_1_RIGHT | ROW_2_RIGHT

Ejemplo dos. Un automóvil tiene tres filas de asientos con dos asientos en la primera fila ( ROW_1_LEFT, ROW_1_RIGHT ), tres asientos en la segunda ( ROW_2_LEFT, ROW_2_CENTER, ROW_2_RIGHT ) y tres en la tercera fila ( ROW_3_LEFT, ROW_3_CENTER, ROW_3_RIGHT ). El coche tiene tres unidades de control de temperatura: lado del conductor, lado del pasajero y parte trasera. Una forma razonable de asignar HVAC_TEMPERATURE_SET a ID de área es como una matriz de tres elementos:

• ROW_1_LEFT
• ROW_1_RIGHT
• ROW_2_LEFT | ROW_2_CENTER | ROW_2_RIGHT | ROW_3_LEFT | ROW_3_CENTER | ROW_3_RIGHT

Manejo de las propiedades del sensor

Las propiedades del sensor VHAL representan datos reales del sensor o información de políticas, como el estado de conducción. Cualquier aplicación puede acceder a cierta información del sensor (como el estado de conducción y el modo día/noche) sin restricciones, ya que los datos son obligatorios para crear una aplicación de vehículo segura. Otra información del sensor (como la velocidad del vehículo) es más sensible y requiere permisos específicos que los usuarios pueden administrar.

Consulte las propiedades del sensor admitidas (en types.hal ).

Servicio de mapas de vehículos

El Servicio de mapas de vehículos (VMS) proporciona un mecanismo para intercambiar datos de mapas entre clientes a través de una interfaz pub/sub para admitir funciones comunes del vehículo, como los sistemas avanzados de asistencia al conductor (ADAS) . Los clientes pueden incluir sistemas de vehículos que interactúan a través de la propiedad VMS en VHAL o aplicaciones privilegiadas de Android. Los datos compartidos en VMS están destinados a limitarse a datos de mapas para uso de sistemas de vehículos y aplicaciones de soporte.

VMS está diseñado para usarse únicamente en implementaciones de Android Automotive; AOSP no contiene clientes predeterminados que publiquen o se suscriban a VMS. Para la propiedad VMS en VHAL, los tipos de mensajes y las estructuras de datos se describen en VHAL 2.0 en la enumeración VmsMessageType , que enumera los tipos de mensajes VMS admitidos. Esta enumeración se utiliza como el primer número entero en la matriz de enteros de propiedad del vehículo y determina cómo se decodifica el resto del mensaje.