Esta é uma história em duas partes - sobre uma nova rodada de desenvolvimento automotivo. No primeiro,
Alex Agizim, CTO Automotive & Embedded Systems da EPAM , fala sobre virtualização em um computador de automóvel. E também como e por que o hipervisor XEN de código aberto pode se tornar um concorrente completo de soluções comerciais para a indústria automotiva.
Devo avisá-lo imediatamente - não jogarei trechos de código e detalhes de engenharia no leitor. Aqui falaremos sobre coisas globais que acreditamos que mudarão a indústria automotiva nos próximos 2-4 anos. Assim como há 12 anos, os telefones celulares mudaram para sempre com o advento do Android e da Apple iOS.
Na EPAM Automotive, nos concentramos em dois grandes blocos: virtualização e uma plataforma em nuvem para implantar serviços diretamente no carro. Esta história é sobre o primeiro.
Duas abordagens
Se você seguir o tema automotivo, provavelmente notou o quão ativamente o Google desenvolve o tema do infotainment com seu Android Auto OS. Desde o final do ano passado, a empresa firmou várias parcerias estratégicas com montadoras para integrar o Android Auto OS no carro.
Mas os fabricantes ainda têm preocupações. O principal motivo é a segurança. Nos carros modernos e futuros, o Cluster de Infotainment e o Cluster Instrumental, que contêm dispositivos e indicadores "vitais", tornam-se um e usam os mesmos recursos. Flechas e indicadores físicos deram lugar aos pintados. No entanto, o motorista deve ver leituras de velocidade reais, nível de combustível, condição do sistema de freio, motor, não importa o quê. É inaceitável se, em algum momento, as telas congelarem repentinamente e exigirem uma reinicialização. E com a experiência dos smartphones Android, sabemos que isso é totalmente possível.
Os fabricantes de automóveis resolvem esse problema de frente: eles colocam
dois ou mais computadores. Por exemplo, o primeiro está envolvido na renderização e manutenção de todo o painel. No segundo, o Android Auto OS roda e mostra navegação, música, aplicativos etc.
Esta opção tem várias desvantagens. Em primeiro lugar, vários computadores ainda são mais caros que um. Em segundo lugar, a implementação é complicada: você precisa garantir a troca de informações entre a parte Android e o cluster institucional, consistência e muitos outros aspectos.
Outra opção é
usar a virtualização usando um hipervisor, seguindo o exemplo da nuvem. O poder e as capacidades dos modernos microprocessadores em computadores automotivos são suficientes. No mínimo duas telas estão conectadas ao computador. Um para Android é o infotainment. O outro é para manutenção do painel. Dois sistemas operacionais são executados em máquinas virtuais isoladas. Mesmo se o Android "ficar cansado" e travar, apenas a máquina virtual em que é executado será reiniciada.
Com essa consolidação, podemos trabalhar em um computador e facilitar a integração. Mas há nuances aqui.
Hipervisor de automóveis
No datacenter, o hipervisor lida apenas com fatias do processador, memória e armazenamento entre diferentes máquinas virtuais. Ele também garante que as "garotas virtuais" não subam no espaço uma da outra. Além disso, todos eles têm o mesmo conjunto de serviços que recebem da plataforma do servidor.
No computador automóvel, além da CPU, RAM e armazenamento, existem diferentes coprocessadores para tarefas específicas. Por exemplo, a mesma GPU que o Android e o painel precisam. Isso significa que a tarefa do hypervisor é fornecer uma oportunidade para os dois sistemas operacionais usarem coprocessadores. Além disso, verifique se o Android não conecta o coprocessador com algum comando ilegal ou erro de software.
Esse é um requisito de segurança funcional - o Cluster Instrumental deve funcionar sem levar em consideração as danças do Android. Portanto, o hipervisor deve ser suficientemente avançado e ter mecanismos especiais pelos quais é garantido o isolamento completo.
O isolamento de hardware já é fornecido pelos processadores modernos. Nós cuidamos da parte do software. Ou seja, estamos modificando o
XEN Hypervisor de código aberto para que ele possa funcionar no carro, levando em consideração todas as nuances do ambiente. Nele, fornecemos os seguintes blocos.
1. Isolamento completo de máquinas virtuais executando infotainment e painel
Primeiro, o computador possui muitos periféricos, botões, uma rede de tela sensível ao toque, etc. A virtualização de periféricos já é suportada por um conjunto de drivers.
Em segundo lugar, virtualizamos GPUs e coprocessadores. Se uma das máquinas virtuais fizer algo com qualquer um dos coprocessadores do sistema, isso não afetará a operação da outra máquina virtual.
Em terceiro lugar, a virtualização de suporte TEE é implementada - ambiente de execução confiável. Essa é uma zona especial protegida por hardware do processador, envolvida na execução de vários procedimentos de segurança. Mas como há mais de um sistema operacional, as solicitações deles para o TEE também são divididas.
Abaixo você pode ver o status dos componentes e se é interessante ver o código
2. Nutrição e desempenho
Qualquer sistema operacional gerencia energia e desempenho e pode colocar o computador no modo de baixa energia, de acordo com as tarefas e o carregamento atuais. O Android Car também pode querer fazer o mesmo: se não houver tarefas atuais, ele decide enviar o processador para o modo de economia de energia. Mas o sistema operacional que lida com dispositivos deve continuar funcionando. Resolvemos esse conflito com uma extensão especial do hypervisor. Ele monitora o estado de todo o sistema e gerencia energia e desempenho.
O próximo momento é em tempo real. O sistema deve funcionar com um cronograma garantido. Também estamos fazendo isso como parte do XEN Real-Time Scheduler.
3. Segurança funcional
Por último, mas o primeiro bloco de importância para a futura indústria automobilística. Atualmente, os fabricantes de automóveis percebem que uma abordagem de virtualização os ajudará a criar sistemas de serviços de cockpit digital significativamente mais flexíveis e poderosos. Isso requer um hipervisor de nível automotivo.
Existem 3-4 soluções comerciais de hipervisor de nível automotivo no mercado. Mas todos os produtos comerciais têm desvantagens:
- alto custo de uma licença;
- falta de capacidade de alterar facilmente qualquer coisa no software de acordo com suas necessidades
- o fabricante para isso quebra a verificação e os prazos;
- bloqueio de fornecedor.
Todos esses problemas são eliminados pelo hypervisor de código aberto. Inicial grátis. Há acesso à fonte, você pode fazer alterações. Para fazer isso, você pode organizar sua equipe ou entrar em contato com as empresas de serviços. Existe total liberdade, porque quando você muda de fornecedor, o código fonte permanece com o fabricante.
O que resta para decidir
A última barreira, porém essencial, permanece no caminho do código aberto. Um hipervisor de carro aberto deve ser compatível com segurança funcional. Até recentemente, todos acreditavam que isso era impossível. Agora há turnos.
Recentemente, trabalhamos ativamente com a comunidade de código aberto XEN Hypervisor. O desafio é adaptar o processo de desenvolvimento para que o XEN possa ser certificado por segurança.
No final de março, foi realizada uma cúpula em Cambridge, onde todas as pessoas interessadas se reuniram. Em primeiro lugar, todas as principais empresas que desenvolvem o XEN: Citrix, ARM, Xilinx, Renesas, EPAM. Em segundo lugar, as empresas envolvidas na certificação, e as empresas que fornecem ferramentas para análise automática de sistemas e identificação de áreas problemáticas.
Como resultado da cúpula, desenvolvemos um plano segundo o qual é absolutamente possível tornar um hipervisor de código aberto compatível com a segurança funcional. Até o final deste ano, planejamos obter um conjunto específico de artefatos necessários para que, quando o XEN for integrado aos computadores automotivos, eles possam ser certificados quanto à segurança.
O XEN se torna um concorrente de pleno direito para soluções comerciais na indústria automotiva e retira seu último argumento sobre a falta de certificação de segurança.
Desde o passado - em meados de julho passou o
Xen Developer Summit . Função Segurança foi um dos principais tópicos. Apresentamos a
abordagem da solução de segurança funcional (via link em PDF).
Por que xen
Provavelmente, essa questão surgiu desde alguns desde o início.
O projeto XEN existe desde 2003 e, comparado a outras soluções de código aberto, possui uma implantação muito ampla em data centers. Ele já se tornou bastante maduro. Desde 2012, o XEN tem suporte nativo para a arquitetura ARM. E os processadores dessa arquitetura específica são usados principalmente na indústria automotiva.
Além disso, fizemos muito trabalho, analisamos várias soluções e alcançamos indicadores de desempenho muito bons. Por exemplo, se o desempenho de um sistema operacional executado em um processador sem virtualização for igual a X, em uma máquina virtual será 0,96-0,97X. E nos hipervisores comerciais, uma queda no desempenho pode chegar a 30%. A diferença é uma ordem de magnitude convincente.
Portanto, o XEN nos parece uma solução básica adequada. Portanto, o EPAM está conduzindo este projeto. Já existem vários fabricantes de automóveis europeus que estão avaliando a solução baseada em XEN para futuros carros com cockpit digital, Android interno e outras coisas que mencionei acima.
Paralelamente a essa grande história, estamos desenvolvendo nossa própria plataforma de veículos conectados Aos. Sua principal idéia é que, por um lado, damos aos desenvolvedores de serviços conectados a oportunidade de implantá-los diretamente em um computador veicular e, por outro lado, os isolamos de funções críticas, garantindo a segurança. Vou falar sobre isso na próxima parte.