O setor automotivo está passando de uma arquitetura de muitas unidades de computação descentralizadas para uma arquitetura que combina várias funcionalidades em poucas unidades de computação centralizadas que ativam novos recursos, como atualizações over-the-air.
O SDV do AAOS usa o sistema e a infraestrutura do Android para oferecer uma solução. Além disso, os OEMs estão procurando soluções que também possam ser executadas na nuvem, já que isso facilita o desenvolvimento inicial e permite novas possibilidades de teste.
Design
Figura 1. Arquitetura do SDV Core.
O AAOS para SDV Core (SDV Core) é um sistema operacional baseado no Android. Devido à natureza incorporada, ele não implementa a pilha da JVM do Android. Em vez disso, toda a funcionalidade do sistema é desenvolvida de forma nativa.
O SDV Core é desenvolvido principalmente para um ambiente virtualizado, e algumas decisões de design pressupõem essa integração. No entanto, é possível executar o SDV Core de forma nativa, mas isso exige um trabalho de integração maior em comparação com outras versões do Android.
O SDV Core foi projetado para um sistema distribuído local. Por exemplo, ele pressupõe que várias instâncias do SDV Core (ou derivados) sejam executadas lado a lado no mesmo chip ou em vários sistemas e possam se comunicar por uma conexão de rede. Portanto, um aspecto essencial da arquitetura do sistema é a implementação da funcionalidade como serviços que podem ser hospedados em qualquer uma das instâncias.
O SDV Core é o conjunto mínimo de funcionalidades para desenvolver funcionalidades no carro. Um serviço típico receberia alguns indicadores, os processaria e compartilharia o resultado com outros serviços. Essa limitação de escopo é proposital, já que permite que o SDV Core execute uma grande variedade de SoCs (System-on-a-chip) que podem não conter mecanismos avançados e economizar custos.
Design detalhado
Figura 2. Arquitetura detalhada do SDV Core.
O SDV Core é derivado do Android e, portanto, a arquitetura dele tenta se alinhar ao Android da melhor maneira possível. Essencialmente, isso significa que o SDV Core também usa GKI, drivers, HALs e bibliotecas principais do Android, além de adicionar componentes necessários para a arquitetura de serviço.
As seções a seguir abordam os componentes do sistema em detalhes.
Ambiente do host e virtualização
O SDV Core é desenvolvido com a suposição de que será executado em um ambiente virtual e, portanto, fazemos algumas suposições sobre o ambiente do host:
O ambiente do host executa um hipervisor que oferece suporte a dispositivos Virtio. Além disso, o hipervisor precisa implementar Ethernet ou vsock, estados de energia e dispositivos de bloco. Além disso, o hipervisor precisa oferecer suporte à execução do Android/Linux.
Em relação ao hardware, o SDV Core pressupõe uma CPU e uma MMU que tenham suporte à virtualização de hardware e que o sistema esteja conectado por Ethernet. O sistema não precisa ter uma GPU, IPU, CSI, mecanismos de mídia, tela ou outros barramentos de comunicação automotiva (por exemplo, CAN, LIN).
Base do Android
O SDV Core é baseado no Android, mas reduz o sistema à funcionalidade essencial e adiciona o ambiente de execução do SDV. Isso significa que o SDV também usa GKI, serviços nativos do sistema (por exemplo, adbd e logd) e funcionalidades do sistema, mas não inclui JVM e serviços ou aplicativos do sistema baseados em JVM, nem recursos implementados para JVM.
Isso também significa que o SDV vai adaptar a estratégia de atualização e o layout de partição do Android. Ele tem requisitos de segurança semelhantes, mas não tem uma GUI.
GKI, drivers e HAL
O SDV Core usa o kernel GKI do Android com o kernel do Android 6.1. A vantagem de usar o GKI é que as mudanças que chegam ao upstream acabam chegando ao Android. Além disso, o Android usa um kernel em toda a frota. Por exemplo, os patches são aplicados centralmente em vez de vários kernels de fornecedores.
Isso também permite que o SDV tenha uma interface de kernel estável. Por exemplo, é possível compilar drivers como módulos que funcionam com o GKI, mesmo quando um novo kernel com correções de segurança é implantado.
O kernel GKI tem um cronograma fixo. As mudanças do fornecedor que precisam fazer parte do próximo kernel GKI precisam ser enviadas ao kernel do Linux até o final do ano.
Com o GKI, os drivers de dispositivo e os módulos não necessários para a inicialização serão compilados como módulos de kernel e contidos em um ramdisk carregado durante a inicialização antecipada. As configurações de dispositivo muito iniciais que não podem esperar pela interface do módulo de kernel (por exemplo, inicialização aleatória) precisam ser feitas na árvore de dispositivos. Os módulos de kernel não precisam ser enviados ao upstream, mas precisam ser compilados nas interfaces GKI.
Como o SDV Core pressupõe que ele é criado com base em um hipervisor compatível com Virtio, os drivers são entregues como módulos de kernel Virtio se o recurso for compatível ou como outro padrão aberto (por exemplo, Open Profile for DICE e o driver de kernel open-dice para confiança).
Essa combinação de Virtio (e padrões abertos) e um hipervisor leva à abstração de hardware. Portanto, a necessidade de HALs no SDV é mínima, mas alguns ainda são necessários devido à falta de suporte ao Virtio. Por exemplo, o HAL KeyMint para criptografia com suporte de hardware e o HAL IRemotelyPrivisionedComponent intimamente relacionado para atestado entre VMs do SDV.
Pilha de rede e comunicação
Figura 3. Pilha de rede e comunicação do SDV Core.
Para redes, o SDV Core pressupõe que vsock ou Ethernet estejam disponíveis para comunicação entre VMs. A comunicação interna da VM também pode usar mecanismos de IPC, como o binder.
O SDV oferece suporte à comunicação serial apenas para fins de depuração.
Figura 4. Suporte serial do SDV Core para depuração.
Em um único convidado, o SDV oferece várias opções que dependem do modelo de comunicação e dos requisitos de desempenho.
Vsock
O Vsock é o canal preferido para comunicação local entre várias VMs ou host e VM. As VMs precisam usar a comunicação vsock direta entre si para permitir que a implementação otimize o número de cópias.
Memória compartilhada
A memória compartilhada é usada apenas para comunicação com uma VM para IPC (comunicação entre processos), mas não é oferecida como um canal normal para comunicação entre várias VMs. O host pode usar a memória compartilhada para compartilhar informações com o convidado, mas ela não é planejada para tráfego de rede de alta frequência.
Ethernet
A Ethernet será usada para comunicação entre vários SoCs, ou seja, para comunicação no veículo. Isso pode ser sistemas virtualizados, mas também sistemas nativos ou ECUs legadas.
A rede do veículo é pequena o suficiente para que o espaço de endereço IPv4 seja suficiente para identificar todos os sistemas disponíveis. No entanto, para garantir que o sistema seja compatível com possíveis uplinks e desenvolvimento futuro, o IPv4 e o IPv6 precisam ser compatíveis.
VLAN
A VLAN é um mecanismo para criar arquiteturas de rede virtual que permitem isolar diferentes sub-redes e formar redes locais. Isso pode ser usado para criar diferentes zonas de segurança e é usado para essa finalidade em carros. O suporte à VLAN é obrigatório.
Protocolos
TCP e UDP
Dependendo do caso de uso, o sistema exige um protocolo de comunicação confiável ou não confiável, mas rápido. Portanto, o TCP e o UDP serão compatíveis.
Túnel de dados
O túnel de dados é um mecanismo de comunicação recém-desenvolvido para SDV que oferece um canal de comunicação rápido seguindo o modelo pubsub. Por exemplo, um aplicativo publica um tópico enquanto um ou mais aplicativos podem ouvi-lo. Internamente, ele usa memória compartilhada e FMQ (filas de mensagens rápidas) na VM ou vsock ou Ethernet para comunicação entre VMs.
RPC (SDV)
O RPC do SDV implementa chamadas de procedimento remoto para SDV usando o binder. Ele usa uma API predefinida para chamar um procedimento remoto. Semelhante ao túnel de dados, ele usa memória compartilhada para comunicação na VM ou vsock ou Ethernet para comunicação entre VMs.
Frameworks
SOMEIP
O SOMEIP é usado para se comunicar com sistemas não SDV. Ele é criado com base em TCP e UDP e não exige hardware ou drivers especiais. O Google vai implementar uma referência.
Agente de descoberta de serviços (agente SD)
Ele oferece descoberta de serviços, autenticação e autorização para SDV. Para comunicação, ele pode usar qualquer um dos métodos mencionados anteriormente. Para autenticação e autorização, o agente SD precisa de acesso ao hardware de segurança e uma cadeia de confiança funcional.
Middleware
O SDV desenvolve um framework para simplificar o uso de todos esses protocolos diferentes chamados de middleware. Ele também implementa uma fonte de verdade para todos os indicadores do veículo com uma nova linguagem VSIDL.
Zona neutra
Para isolar partes do sistema e evitar ataques de uma parte menos confiável do sistema (por exemplo, IVI com apps instalados personalizados), a rede pode introduzir diferentes zonas, incluindo zonas desmilitarizadas. Na prática, isso significa que as sub-redes são separadas física ou logicamente e permitem apenas o tráfego da lista de permissões.
Gerenciador de conectividade
No Android, é uma prática comum limitar o número de aplicativos e serviços que podem abrir conexões de soquete. Em vez disso, uma instância central é responsável por abrir e gerenciar conexões. Como o Android implementa essa funcionalidade em um serviço Java, o SDV vai criar o próprio gerenciador de conectividade.
Capacidade de atualização
Um dos principais recursos do SDV é a capacidade de atualização. Novos recursos podem ser instalados durante todo o ciclo de vida do SDV por meio de atualizações do sistema Android e pacotes APEX.
Atualizações do sistema Android
O Android já oferece um mecanismo para instalar atualizações. Ele usa atualizações A/B e A/B virtuais em versões recentes, e o SDV Core vai aproveitar esse mecanismo. As atualizações A/B criam cada partição duas vezes, o que oferece duas vantagens: o sistema pode ser atualizado em segundo plano e, se a atualização falhar, o sistema poderá reverter para a última versão conhecida para funcionar.
Pacotes APEX
Além de dividir o sistema em várias partições e torná-las atualizáveis, o Android também oferece pacotes APEX, um mecanismo para colocar aplicativos e bibliotecas em pequenos pacotes que podem ser instalados e atualizados de forma independente das atualizações do sistema.
O SDV Core vai usar contêineres APEX para instalar serviços dinamicamente em uma instância do SDV, mas também para gerenciar a implantação de vários serviços em um único processo: apenas os serviços agrupados no mesmo APEX e que usam o mesmo certificado podem ser implantados no mesmo binário para reduzir os riscos de segurança.
O mecanismo do Android para instalar pacotes APEX aproveita alguns códigos Java para o gerenciamento de APKs para verificar pacotes. O SDV Core precisará implementar uma alternativa nativa para permitir a instalação dinâmica de pacotes APEX.
Gerenciamento de atualizações
As instâncias do SDV não são unidades totalmente independentes no carro e precisam de orquestração com outras instâncias do SDV e serviços de carro. Por exemplo, para instalar dependências de serviço ou garantir que as atualizações sejam instaladas apenas em um estado seguro do sistema.
O SDV considera o uso de partições em várias VMs. Isso exige coordenação entre essas VMs, já que elas têm uma dependência de dados umas das outras: precisa haver uma VM principal para atualizar essas partições e um mecanismo para notificar as outras VMs sobre a partição atualizada e a sincronização para atualizar todas as VMs ao mesmo tempo para garantir que o estado de funcionamento conhecido anterior não seja interrompido.
Primeiros passos
Nosso guia de primeiros passos oferece detalhes sobre o código-fonte, a criação e a inicialização com o Cuttlefish.