O setor automotivo está migrando 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 permitem novos recursos, como atualizações over the air.
O SDV do AAOS utiliza o sistema e a infraestrutura atuais 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 possibilita novas possibilidades de teste.
Design
Figura 1. Arquitetura principal do SDV.
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, todas as funcionalidades do sistema são desenvolvidas 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 mais trabalho de integração 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 que elas possam se comunicar por uma conexão de rede. Portanto, um aspecto central 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 recursos no carro. Um serviço típico recebe alguns indicadores, os processa e compartilha o resultado com outros serviços. Essa limitação de escopo é intencional, porque permite que o SDV Core execute uma grande variedade de SoCs (sistema em um 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 forma possível. Isso significa que o SDV Core também usa GKI, drivers, HALs e bibliotecas principais do Android e adiciona 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 foi desenvolvido com base na premissa de que será executado em um ambiente virtual. Portanto, fazemos algumas suposições sobre o ambiente host:
O ambiente de host executa um hipervisor compatível com dispositivos Virtio. Além disso, o hipervisor precisa implementar Ethernet ou vsock, estados de energia e dispositivos em bloco. Além disso, o hipervisor precisa ser compatível com a 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).
Android Base
O SDV Core é baseado no Android, mas reduz o sistema às funcionalidades essenciais
e adiciona o ambiente de execução do SDV. Isso significa que o SDV também
usa o GKI, serviços nativos do sistema (por exemplo, adbd e logd) e funcionalidades
do sistema, mas não inclui a JVM, serviços baseados em JVM ou aplicativos
do sistema, nem recursos implementados para a 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 6.1 do Android. A vantagem de usar a 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 de forma centralizada, em vez de em 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 a GKI mesmo quando um novo kernel com correções de segurança é implantado.
O kernel da GKI tem um cronograma fixo. As mudanças do fornecedor que devem fazer parte do próximo kernel da GKI precisam ser enviadas para o kernel do Linux até o final do ano.
Com a GKI, os drivers de dispositivo e os módulos que não são necessários para a inicialização serão compilados como módulos do kernel e estarão contidos em um ramdisk carregado durante a inicialização antecipada. As configurações de dispositivo muito antecipadas que não podem esperar pela interface do módulo do kernel (por exemplo, inicialização aleatória) precisam ser feitas na árvore de dispositivos. Os módulos do kernel não precisam ser upstreamed, mas precisam ser compilados em relação às interfaces da GKI.
Como o SDV Core pressupõe que é criado com base em um hipervisor compatível com Virtio, os drivers são fornecidos como módulos do kernel do Virtio se o recurso for compatível ou como outro padrão aberto (por exemplo, Open Profile para DICE e o driver do 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 em SDVs é mínima, mas algumas ainda são necessárias devido à falta de suporte ao Virtio. Por exemplo, a HAL KeyMint para criptografia com suporte de hardware e a HAL IRemotelyPrivisionedComponent, que é relacionada, para atestação entre VMs de SDV.
Pilha de rede e comunicação
Figura 3. Pilha de rede e comunicação principal do SDV.
Para redes, o SDV Core pressupõe que o vsock ou a Ethernet estejam disponíveis para comunicação entre VMs. A comunicação interna de VMs 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 preferencial para comunicação local entre várias VMs ou host e VM. As VMs precisam usar a comunicação direta de vsock 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 se comunicar 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 isso não é planejado para tráfego de rede de alta frequência.
Ethernet
A Ethernet é usada para comunicação entre vários SoCs, ou seja, para comunicação no veículo. Podem 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. É necessário suporte à VLAN.
Protocolos
TCP e UDP
Dependendo do caso de uso, o sistema requer um protocolo de comunicação confiável ou não confiável, mas rápido. Portanto, TCP e UDP serão compatíveis.
Túnel de dados
O Data Tunnel é um mecanismo de comunicação recém-desenvolvido para SDVs 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 rápidas de mensagens) na VM ou vsock ou Ethernet para se comunicar entre VMs.
RPC (SDV)
A RPC do SDV implementa chamadas de procedimento remoto para o SDV usando o Binder. Ele usa uma API predefinida para chamar um procedimento remoto. Semelhante ao Data Tunnel, ele usa memória compartilhada para comunicação dentro da VM ou vsock ou Ethernet para comunicação entre VMs.
Frameworks
SOMEIP
O SOMEIP é usado para se comunicar com sistemas que não são SDV. Ele é criado com base em TCP e UDP e não requer hardware ou drivers especiais. O Google vai implementar uma referência.
Agente de descoberta de serviços (agente SD)
Ele fornece 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 de SD precisa de acesso ao hardware de segurança e a uma cadeia de confiança em funcionamento.
Middleware
O SDV desenvolve um framework para simplificar o uso de todos esses protocolos diferentes, chamado de middleware. Ele também implementa uma fonte de verdade para todos os indicadores de veículos com uma nova linguagem VSIDL.
Zona neutra
Para isolar partes do sistema e evitar ataques de uma parte menos confiável (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 apenas o tráfego na lista de permissões pode passar por essas bordas.
Gerenciador de conectividade
No Android, é 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 a vida útil do SDV usando 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 virtuais A/B 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 pode reverter para a última versão que funcionou.
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 independentemente das atualizações do sistema.
O SDV Core vai usar contêineres APEX para instalar serviços dinamicamente em uma instância de SDV, mas também para gerenciar a implantação de vários serviços em um único processo: apenas os serviços que estão agrupados no mesmo APEX e 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 usa um código Java para 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 de SDV não são unidades totalmente independentes no carro e precisam de orquestração com outras instâncias de SDV e serviços do carro. Por exemplo, para instalar dependências de serviço ou garantir que as atualizações sejam instaladas apenas em um estado de sistema seguro.
O SDV considera o uso de partições em várias VMs. Isso requer coordenação entre essas VMs, já que elas têm uma dependência de dados entre si: é preciso 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 trabalho conhecido anterior não seja corrompido.
Primeiros passos
Nosso Guia para iniciantes oferece detalhes sobre o código-fonte, a criação e o lançamento com o Cuttlefish.