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);
  Escriba un valor para 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);

El 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 solo para propiedades suscritas.
• oneway onPropertySetError(StatusCode errorCode,int32_t propId,int32_tareaId);
  Devuelve un error de nivel de VHAL global o un error por propiedad. El error global hace que HAL se reinicie, lo que puede provocar el reinicio de otros componentes (incluidas las aplicaciones).

Propiedades del vehículo

Las propiedades pueden ser de solo lectura, solo escritura (utilizadas para pasar información al nivel VHAL) o 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 varios tipos de áreas:

Cada propiedad zonificada debe usar un tipo de área predefinida. 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 identificaciones de área. Cada propiedad zonificada puede admitir una o más identificaciones de área. Un identificador de área se compone de uno o más indicadores de su enumeración respectiva. Por ejemplo, una propiedad que usa VehicleAreaSeat podría usar 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 es equivalente 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 una propiedad zonificada siempre incluye el ID del área en la solicitud. Por lo tanto, solo se devuelve el valor actual para el identificador de área solicitado. Si la propiedad es global, el identificador de área es 0.
• set llamada para la propiedad zonificada siempre incluye la identificación del área en la solicitud. Por lo tanto, solo se cambia el ID de área solicitado.
• la llamada de subscribe genera eventos para todos los identificadores de área de la propiedad.

recibir llamadas

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

Figura 1 . Obtenga la temperatura HVAC (CS = CarService, VHAL = HAL del vehículo)

Establecer llamadas

Una llamada set es una operación asincrónica que implica la notificación de eventos después de que se realiza un cambio solicitado. En una operación típica, una llamada set lleva a realizar una solicitud de cambio a través de la red de vehículos. Algunas llamadas set pueden requerir que los datos iniciales estén listos, pero durante la inicialización, es posible que dichos datos aún no estén disponibles. En tales casos, la llamada set debe devolver -EAGAIN . Algunas propiedades con encendido/apagado por separado deben devolver -ESHUTDOWN cuando la propiedad está apagada y no se puede configurar. Hasta set se haga efectivo, get no necesariamente devuelve el mismo valor que set. Por ejemplo, set HVAC Temperature .

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

Manejo de propiedades personalizadas

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

• El ID de propiedad debe generarse utilizando los siguientes campos:
  • VehiclePropertyGroup:VENDOR
    El grupo VENDOR se usa solo 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 que es suficiente en la mayoría de los casos. El envío frecuente de grandes datos a través de propiedades personalizadas puede ralentizar el acceso a la red de vehículos completos; tenga cuidado al agregar una gran carga útil.
  • Property ID
    Elija un ID de cuatro nibbles para la propiedad personalizada.
• Para evitar la fragmentación del ecosistema, las propiedades personalizadas no deben usarse para replicar propiedades de vehículos que ya existen en el SDK de VehiclePropertyIds .
• Rellene VehiclePropConfig.configString con una breve descripción de la propiedad personalizada. Esto permite que las herramientas de verificación de cordura marquen la replicación accidental de las propiedades existentes del vehículo. Por ejemplo, "estado de luz de peligro".
• Acceso a través de CarPropertyManager (para componentes Java) o a través de la API de Vehicle Network Service (para nativos). No modifique otras API de 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 usar 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). Ejemplos de propiedades definidas incluyen:

Para ver una lista completa de propiedades HVAC, busque VEHICLE_PROPERTY_HVAC_* en types.hal . Cuando la propiedad HVAC usa 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 automóvil 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 fila delantera ( ROW_1_LEFT, ROW_1_RIGHT ), tres asientos en el segundo ( 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 automóvil 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 de 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 de vehículos, como los Sistemas avanzados de asistencia al conductor (ADAS) . Los clientes pueden incluir sistemas de vehículos que interactúen a través de la propiedad VMS en VHAL o aplicaciones Android privilegiadas. Los datos compartidos en VMS están destinados a limitarse a datos de mapas para uso de sistemas de vehículos y aplicaciones de apoyo.

VMS está diseñado para usarse solo 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 entero en la matriz de enteros de propiedad del vehículo y determina cómo se decodifica el resto del mensaje.