Segurança da exibição

O Display Safety tem como alvo os controladores de domínio do cockpit e permite que o Android alimente todas as telas do carro, incluindo aquelas com requisitos de segurança e disponibilidade.

Visão geral do cluster

Figura 1. Visão geral do cluster.

Para saber mais sobre o GitHub, consulte Design automotivo para Compose.

Terminologia

plataforma
Uma combinação de hardware, hipervisor, sistema operacional e bibliotecas relacionadas.
monitor de segurança
Um app para monitorar o estado do veículo e validar se as informações visuais correspondentes são mostradas ao usuário conforme o esperado.

Componentes de segurança da tela

O software de segurança da tela tem três componentes principais:

  • DriverUI:um app do sistema Android que renderiza uma tela inteira do cluster de instrumentos, exceto elementos de segurança ou regulamentares renderizados pelo HAR.

  • Renderizador de alta disponibilidade (HAR): um processo de gerenciamento de qualidade que renderiza elementos de exibição que precisam estar presentes rapidamente após uma inicialização a frio e elementos de marcador de posição quando o Android não está disponível. O HAR é portátil e se concentra em informações de direção importantes.

  • Ferramentas de design de segurança:um conjunto de ferramentas para gerar configurações de implementações de monitor de segurança da fonte de design, alcançando as metas de segurança ASIL-B relevantes.

Todos os componentes usam o conjunto de ferramentas de design, Automotive Design for Compose, para verificar se eles foram criados com base na mesma definição de design do OEM.

Componentes de segurança da tela

Figura 2. Componentes de segurança de exibição.

Renderizador de alta disponibilidade

O HAR é escrito em Rust e consiste nestes componentes:

  • Camada de abstração de plataforma (PAL, na sigla em inglês). Abstração para interagir com vários subsistemas, incluindo gráficos, câmera, áudio, entrada do usuário (como controles do volante), dados do veículo (também chamados de sinais ou propriedades), configuração do veículo (por exemplo, gasolina ou elétrico, direção à esquerda ou à direita) e preferências do usuário (por exemplo, km/h e mph).

  • Implementação da PAL para a plataforma segmentada.

  • App de HAR desenvolvido com a PAL.

O Google define a PAL e fornece implementações de referência da PAL e do app HAR. O app HAR de referência fornece todos os blocos de construção e inclui um loop principal de referência. Os OEMs precisam personalizar a implementação da PAL e o app HAR para atender aos requisitos deles. O HAR usa o Impeller para renderização.

Para saber mais, veja:

DriverUI

A interface do cluster geralmente fica atrás do volante em uma tela separada. Os OEMs combinam gradualmente o cluster e o IVI. Essa interface combinada é a DriverUI.

A DriverUI é um app do sistema Android que renderiza uma tela de painel de instrumentos inteira, exceto elementos regulamentares ou relevantes para a segurança renderizados pelo HAR. A DriverUI mostra informações relacionadas à reprodução de mídia, chamadas telefônicas, mapas, navegação e outras coisas, e é implementada usando o Automotive Design para Compose.

O AAOS tem duas APIs para criar painéis de instrumentos. A API Instrument Clusters (também chamada de Cluster 1) está em modo de manutenção, e os OEMs são incentivados a migrar para a API ClusterHomeManager (também chamada de Cluster 2).

O Google oferece implementações de referência das APIs Cluster 1 e Cluster 2.

Para mais informações, consulte DriverUI.

Combinar a saída do HAR e do DriverUI

O HAR e a DriverUI usam telas separadas para renderizar uma interface. As duas saídas são combinadas e mostradas como uma imagem na interface do motorista.

Para isso, o HAR controla a transparência das áreas em que a saída do Android é exibida com base no recebimento de mensagens periódicas de pulsação da DriverUI para indicar que ela está em execução.

Quando a DriverUI não está em execução, o HAR detecta a falta de pulsações e torna as áreas da DriverUI opacas e mostra marcadores de posição. Quando os heartbeats são recebidos, o HAR remove os marcadores de posição e define as áreas da DriverUI como transparentes.

A DriverUI e o HAR se comunicam usando chamadas de procedimento remoto (RPCs). A mensagem de pulsação é um exemplo de dados enviados pelo canal RPC e consiste em um carimbo de data/hora como um dos campos.

O gRPC é usado para RPCs. No SDV, a pilha de comunicações do SDV fornece o cliente de gateway do SDV para descobrir e estabelecer um canal da DriverUI para o HAR.

Composição de HAR e DriverUI

Figura 3. Composição de HAR e DriverUI.

Conjunto de ferramentas de design de segurança

O conjunto de ferramentas de design de segurança é uma série de ferramentas que um OEM usa em sequência para oferecer uma solução de monitor de segurança gerada de um documento de design do Figma.

O compilador de design de segurança produz artefatos de segurança para impulsionar a geração de código subsequente para criar um monitor de segurança. Essa separação entre a compilação de design e a geração de código permite que o gerador de código usado alcance uma classificação ISO-26262 TCL-3.

Fluxo de trabalho da cadeia de ferramentas de design de segurança

Figura 4. Use o conjunto de ferramentas de design de segurança.

Depois que os artefatos do compilador são gerados, a cadeia de ferramentas pode gerar um relatório legível para humanos. Esse relatório é um arquivo que um engenheiro de segurança do OEM pode inspecionar para validar os artefatos gerados pelo design do Figma.

O Google oferece uma implementação de referência do monitor de segurança que não é certificado pela ASIL. Os OEMs precisam personalizar o monitor de segurança para atender aos requisitos e receber a certificação da implementação.

Para saber mais, consulte Conjunto de ferramentas de design de segurança.

Segurança de display no SDV

É possível criar e executar a segurança de display no SDV. O SDV tem todos os recursos e usa duas VMs convidadas para executar um cluster completo de segurança de display.

Veículo definido por software

O veículo definido por software (SDV) do Android Automotive OS (AAOS):

  • Exige duas VMs convidadas para mostrar o cluster completo.
  • Executa HAR na mídia SDV (também conhecida como VM de inicialização rápida) em uma VM convidada.
  • Executa a DriverUI em uma VM convidada separada que executa a VM SDV-IVI.