Propriedades do veículo

A interface Vehicle Hardware Abstraction Layer (VHAL) define as propriedades que os OEMs podem implementar e contém metadados de propriedade (por exemplo, se a propriedade é um int e quais modos de alteração são permitidos). A interface VHAL é baseada no acesso (leitura, gravação, assinatura) de uma propriedade, que é uma abstração para uma função específica.

Interfaces HAL

O VHAL usa as seguintes interfaces:

• getAllPropConfigs() gera (vec<VehiclePropConfig>propConfigs)
  Liste a configuração de todas as propriedades suportadas pelo VHAL. CarService usa apenas propriedades suportadas.
• getPropConfigs(vec<int32_t> props) gera (StatusCode status,vec<VehiclePropConfig> propConfigs);
  Retorne a configuração das propriedades selecionadas.
• set(VehiclePropValue propValue) gera (StatusCodestatus);
  Escreva um valor para a propriedade. O resultado da gravação é definido por propriedade.
• subscribe(IVehicleCallback callback, vec<SubscribeOptions> options) gera (StatusCode status);
  Comece a monitorar uma alteração no valor de uma propriedade. Para propriedade zoneada, unsubscribe(IVehicleCallback callback, int32_t propId) gera (StatusCode status);

O VHAL usa as seguintes interfaces de retorno de chamada:

• oneway onPropertyEvent(vec<VehiclePropValue>propValues);
  Notifica a alteração do valor da propriedade do veículo. Deve ser feito apenas para imóveis inscritos.
• oneway onPropertySetError(StatusCode errorCode,int32_t propId,int32_tareaId);
  Retorna erro de nível VHAL global ou erro por propriedade. O erro global faz com que o HAL seja reiniciado, o que pode levar à reinicialização de outros componentes (incluindo aplicativos).

Propriedades do veículo

As propriedades podem ser somente leitura, somente gravação (usadas para passar informações para o nível VHAL) ou leitura e gravação (o suporte da maioria das propriedades é opcional). Cada propriedade é identificada exclusivamente por uma chave int32 e possui um tipo predefinido ( value_type ):

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

Uma propriedade zoneada pode ter mais de um valor, com base no número de zonas suportadas pela propriedade.

Tipos de área

O VHAL define vários tipos de área:

Cada propriedade zoneada deve usar um tipo de área predefinido. Cada tipo de área possui um conjunto de sinalizadores de bits definidos em uma enumeração para o tipo de área. Por exemplo, a área SEAT define enums 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
• ...

IDs de área

As propriedades zoneadas são endereçadas por meio de IDs de área. Cada propriedade zoneada pode suportar um ou mais IDs de área. Um ID de área é composto por um ou mais sinalizadores de seu respectivo enum. Por exemplo, uma propriedade que usa VehicleAreaSeat pode usar os seguintes IDs de área:

Situação da propriedade

Cada valor de propriedade vem com um valor VehiclePropertyStatus . Isso indica o status atual da propriedade:

Configurando uma propriedade

Use VehiclePropConfig para fornecer informações de configuração para cada propriedade. As informações incluem:

Tratamento de propriedades de zona

Uma propriedade zoneada é equivalente a uma coleção de diversas propriedades onde cada subpropriedade pode ser acessada com o valor de ID de área especificado.

• get call para propriedade zoneada sempre inclui o ID da área na solicitação. Portanto, somente o valor atual do ID de área solicitado é retornado. Se a propriedade for global, o ID da área será 0.
• set call for zoned property sempre inclui o ID da área na solicitação. Portanto, apenas o ID de área solicitado é alterado.
• A chamada subscribe gera eventos para todos os IDs de área da propriedade.

Receber chamadas

Durante a inicialização, o valor da propriedade pode ainda não estar disponível, pois a mensagem de rede do veículo correspondente ainda não foi recebida. Nesses casos, a chamada get deve retornar -EAGAIN . Algumas propriedades (como HVAC) possuem propriedade de energia liga/desliga separada. Chamar get para tal propriedade (quando desligado) deve retornar um status UNAVAILABLE em vez de retornar um erro. Por exemplo, obtenha temperatura HVAC

Figura 1 . Obtenha a temperatura HVAC (CS = CarService, VHAL = Veículo HAL)

Definir chamadas

Em uma operação típica, uma chamada set leva à realização de uma solicitação de alteração na rede do veículo. Uma chamada set é idealmente uma operação assíncrona que retorna o mais rápido possível, mas também pode ser síncrona. Algumas chamadas set podem exigir que os dados iniciais estejam prontos, mas durante a inicialização, esses dados podem ainda não estar disponíveis. Nesses casos, a chamada set deve retornar StatusCode#TRY_AGAIN . Algumas propriedades com ligação e desligamento separados devem retornar StatusCode#NOT_AVAILABLE ou StatusCode#NOT_AVAILABLE_DISABLED quando a propriedade está desligada e set não pode ser feita. Até que set seja efetivado, get não retorna necessariamente o mesmo valor que foi definido. Por exemplo, set HVAC Temperature .

Figura 2 . Definir temperatura HVAC (CS = CarService, VHAL = Veículo HAL)

Tratamento de propriedades customizadas

Para atender às necessidades específicas do parceiro, o VHAL permite propriedades personalizadas restritas aos aplicativos do sistema. Use as seguintes diretrizes ao trabalhar com propriedades customizadas:

• O ID da propriedade deve ser gerado usando os seguintes campos:
  • VehiclePropertyGroup:VENDOR
    O grupo VENDOR é usado somente para propriedades customizadas.
  • VehicleArea
    Selecione um tipo de área apropriado.
  • VehiclePropertyType
    Selecione o tipo de dados adequado. O tipo BYTES permite a passagem de dados brutos, o que é suficiente na maioria dos casos. O envio frequente de big data por meio de propriedades personalizadas pode retardar o acesso à rede de todo o veículo. Tenha cuidado ao adicionar uma grande carga útil.
  • Property ID
    Escolha um ID de quatro nibbles para a propriedade customizada.
• Para evitar a fragmentação do ecossistema, as propriedades personalizadas não devem ser usadas para replicar propriedades de veículos que já existem no ( VehiclePropertyIds SDK).
• Preencha VehiclePropConfig.configString com uma breve descrição da propriedade customizada. Isso permite que ferramentas de verificação de integridade sinalizem a replicação acidental de propriedades de veículos existentes. Por exemplo, "estado de luz de perigo".
• Acesso através CarPropertyManager (para componentes Java) ou através da API Vehicle Network Service (para nativos). Não modifique APIs de outros carros, pois isso pode levar a problemas de compatibilidade futuros.
• Depois de implementar as propriedades do fornecedor, selecione apenas a lista de permissões na enumeração VehicleVendorPermission para propriedades do fornecedor. Mapear as permissões do fornecedor para as propriedades do sistema quebrará o CTS e o VTS.

Lidando com propriedades HVAC

Você pode usar o VHAL para controlar o HVAC definindo propriedades relacionadas ao HVAC. A maioria das propriedades HVAC são propriedades zoneadas, embora várias sejam propriedades não zoneadas (globais). As propriedades definidas por exemplo incluem:

Para ver uma lista completa de propriedades HVAC, pesquise VEHICLE_PROPERTY_HVAC_* em types.hal . Quando a propriedade HVAC usa VehicleAreaSeat , aplicam-se regras adicionais para mapear uma propriedade HVAC zoneada para IDs de área. Cada assento disponível no carro deve fazer parte de um Area ID na matriz Area ID.

Exemplo Um. Um carro tem dois assentos dianteiros ( ROW_1_LEFT, ROW_1_RIGHT ) e três assentos traseiros ( ROW_2_LEFT, ROW_2_CENTER, ROW_2_RIGHT ). O carro possui duas unidades de controle de temperatura: lado do motorista e lado do passageiro.

• Um conjunto de mapeamento válido de IDs de área para HVAC_TEMPERATURE SET é:
  • ROW_1_LEFT | ROW_2_LEFT
  • ROW_1_RIGHT | ROW_2_CENTER | ROW_2_RIGHT
• Um mapeamento alternativo para a mesma configuração de hardware é:
  • ROW_1_LEFT | ROW_2_LEFT | ROW_2_CENTER
  • ROW_1_RIGHT | ROW_2_RIGHT

Exemplo dois. Um carro tem três filas de assentos com dois assentos na primeira fila ( ROW_1_LEFT, ROW_1_RIGHT ), três assentos na segunda ( ROW_2_LEFT, ROW_2_CENTER, ROW_2_RIGHT ) e três na terceira fila ( ROW_3_LEFT, ROW_3_CENTER, ROW_3_RIGHT ). O carro possui três unidades de controle de temperatura: lado do motorista, lado do passageiro e traseira. Uma maneira razoável de mapear HVAC_TEMPERATURE_SET para IDs de área é como uma matriz de três 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

Manipulando propriedades do sensor

As propriedades do sensor VHAL representam dados reais do sensor ou informações de política, como status de direção. Algumas informações do sensor (como status de direção e modo dia/noite) podem ser acessadas por qualquer aplicativo sem restrições, pois os dados são obrigatórios para construir um aplicativo de veículo seguro. Outras informações do sensor (como a velocidade do veículo) são mais confidenciais e requerem permissões específicas que os usuários podem gerenciar.

Veja as propriedades do sensor suportadas (em types.hal ).

Serviço de mapas de veículos

O Vehicle Map Service (VMS) fornece um mecanismo para trocar dados de mapas entre clientes por meio de uma interface pub/sub para oferecer suporte a recursos comuns de veículos, como Sistemas Avançados de Assistência ao Motorista (ADAS) . Os clientes podem incluir sistemas de veículos fazendo interface por meio da propriedade VMS no VHAL ou em aplicativos Android privilegiados. Os dados compartilhados no VMS destinam-se a ser limitados a dados de mapas para uso por sistemas de veículos e aplicativos de suporte.

O VMS destina-se ao uso somente em implementações do Android Automotive; O AOSP não contém clientes padrão que publicam ou assinam VMS. Para a propriedade VMS no VHAL, os tipos de mensagens e estruturas de dados são descritos no VHAL 2.0 no enum VmsMessageType , que lista os tipos de mensagens VMS suportadas. Este enum é usado como o primeiro inteiro na matriz de inteiros da propriedade do veículo e determina como o restante da mensagem é decodificado.