Kubernetes para o carro: como abrir o acesso do desenvolvedor ao computador de bordo e torná-lo seguro

Esta é uma história em duas partes - sobre uma nova rodada de desenvolvimento automotivo. Esta "série" é dedicada ao próprio desenvolvimento do EPAM, a Plataforma de Veículos Conectados Aos. Alex Agizim , CTO da Automotive & Embedded Systems, explica como ela difere de uma solução em nuvem tradicional e como fornece aos desenvolvedores de software acesso ao carro. Você pode se familiarizar com a primeira parte aqui .



Na primeira parte, falei sobre como nossos desenvolvimentos no XEN Hypervisor isolam a parte de serviço do software automotivo do software necessário para a segurança. Essa é uma das barreiras ao uso generalizado na indústria. Pela primeira vez, um hipervisor de código aberto se tornará um concorrente de pleno direito para soluções comerciais fechadas.

Mas este é apenas o primeiro passo. Para elevar os serviços automotivos a um novo nível, você precisa "deixar" empresas e desenvolvedores de serviços longe de incorporados e automotivos. Isso requer o próximo nível de abstração. Para que um desenvolvedor que use estruturas modernas no desenvolvimento de software possa, sem reaprender, projete seus serviços para carros.

Talvez depois de ler você queira dizer: “Por que essas dificuldades? Por exemplo, comprei um tablet Android para um carro, configurei os serviços necessários e estou muito feliz. ” Esta é uma abordagem de engenharia clássica, com muito apoio. Mas vamos ver mais. A indústria automotiva, do ponto de vista do software, há muito tempo está presa nas abordagens clássicas. Vou lhe contar como vemos o futuro dela e o que fazemos para isso. E no final, vamos passar pelas principais dificuldades.

Então

Por que você precisa deixar o desenvolvedor de serviços entrar no computador de bordo do carro? E o que está errado agora?

O carro está se tornando um dispositivo cada vez mais complexo. Está repleto de sensores para todas as ocasiões, e a sonda invejará o desempenho dos computadores de bordo. Com tudo isso, o carro permanece muito limitado em recursos. O desenvolvimento de software está avançando, mas 90% passam.

Uma analogia próxima são os smartphones. Até 2007-9, escrever um aplicativo que seria executado em diferentes telefones celulares era bastante difícil. Muitos sistemas operacionais e estruturas brigaram no mercado: soluções da Symbian, Motorola, Ericsson, etc. ... O número de pessoas com habilidades de desenvolvimento para eles era pequeno. Se uma empresa queria que um grande número de pessoas usasse seu serviço ou aplicativo, um problema começou com o suporte em diferentes sistemas operacionais e estruturas.

Exatamente a mesma coisa está acontecendo hoje na indústria automotiva. Para que o serviço seja suportado por diferentes fabricantes de carros, você precisa se adaptar a várias estruturas e um conjunto de regras. Para Mercedes separadamente, para Toyota separadamente, etc.

Quando o iOS apareceu em 2007, um ano depois - Android - a indústria móvel imediatamente fez um grande avanço. Em AUTOMOBILE, o conflito de dois paradigmas principais continua.

O primeiro é tradicional. Um computador de bordo é um dispositivo fechado, cujo acesso está disponível apenas para o fabricante . Desenvolvedores de terceiros não têm como aqui: segurança e proteção em primeiro lugar. Confiável, mas não sem falhas. Por um lado, o fabricante fecha tudo consigo mesmo. Não há necessidade de culpar os desenvolvedores de serviços de terceiros. Por outro lado, não se pode estar na vanguarda do progresso. Uma montadora não pode cobrir totalmente a lista de desejos do cliente. O ciclo de desenvolvimento e lançamento no mercado é muito longo, a equipe, mesmo muito animada, ainda é limitada. E o carro autônomo conectado esperado se afasta ainda mais. Como a integração em uma economia compartilhada.

O outro extremo é considerar um carro um dispositivo IoT . Ou seja, basta coletar dados de todos os sensores automotivos, embalar e enviar para a nuvem para processamento. Repita milhares de vezes, se necessário. Portanto, centenas de projetos em nuvem, incluindo Google, Microsoft e Amazon, estão tentando assistir ao carro. Mas isso está um pouco errado.

Auto não é uma casa inteligente com lâmpadas, termostato e TV. Possui centenas de vezes mais sensores e seu próprio poder de computação. E - o mais importante - o canal entre o carro e o centro é instável. Mesmo que seja condicionalmente estável, é improvável que ele queira executar centenas de megabytes de dados a cada segundo. Caso contrário, não há como essa abordagem - toda a lógica de negócios do serviço funciona na nuvem.

O que criamos em troca?

Nós escolhemos uma ideologia diferente. Um carro não é apenas uma fonte de informação dos sensores. Este é um nó de computação completo no qual o serviço pode executar sua lógica de negócios .

Para isso, o carro precisa de um elemento básico - a Plataforma de Veículos Conectados. Permite abrir o carro como uma plataforma de software. Por outro lado, use as ferramentas adotadas nos serviços em nuvem para participar da implantação e orquestração de serviços que devem funcionar no computador de bordo.

Se nossa previsão for verdadeira, terminaremos com um ecossistema em que o programador pode agir da maneira usual e incorporar parte da lógica de negócios em um computador de automóvel. Da mesma maneira que hoje em serviços em nuvem, ele pressiona um botão, lança o CI / CD, implantação de todos os componentes necessários para todos os nós necessários. No nosso caso, um dos nós para implantação será um carro. E damos uma estrutura que pode fazer isso. Portanto, chamamos nossa plataforma de nuvem de "Kubernetes para carros".

O conceito em nossa visão é dividido em 2 partes:

1. isolar o software de segurança do software de serviços conectados;
2. fornecer o nível de abstração necessário para as empresas que desejam desenvolver ou já estão prestando serviços de veículos conectados. Eles não devem se preocupar com o incorporado, mas desenvolvem serviços com as ferramentas usuais e usam o computador de bordo como um dispositivo de ponta.

Um computador de bordo deve se tornar um computador de ponta para futuros serviços móveis. Economizamos os fabricantes de automóveis de inventar serviços independentemente e abrimos o carro para desenvolvedores. Como isso aconteceu com os smartphones.

Que casos ele pode fechar?

O caso raiz é a falta de conectividade . Na versão clássica da nuvem, o serviço perderá o acesso ao carro. Na variante Connected Vehicle Platform, o desenvolvedor pode prever isso e pré-"flash" a lógica dentro do carro. E para a parte da nuvem - pelo menos, os dados são armazenados em buffer.

A plataforma também ajudará a melhorar significativamente o gerenciamento de frotas, o gerenciamento de frotas e a manutenção preditiva. A comunicação com a nuvem para esses serviços se torna, se não opcional, muito menos popular.

Um exemplo completamente compreensível é o trabalho dos serviços de táxi. Agora eles são implementados em smartphones, funcionam muito bem com cartões e pagamentos, mas não podem levar em consideração o estado do carro. Por exemplo, se você está atrasado para o aeroporto, o Uber chega - e de repente acontece que o motorista tem gasolina suficiente apenas durante parte do caminho. O motorista não conseguiu entender isso com antecedência. Mas se o serviço Uber foi implantado dentro do computador de bordo, na fase do pedido, eu poderia dizer ao back-end que esse carro em particular não é adequado. E a qualidade do serviço seria maior.

No caso da futura economia compartilhada, você precisa ter um conjunto de serviços no carro que ficarão completamente sem uma interface do usuário. Por exemplo, um serviço que monitorará as condições técnicas do carro (o exemplo com Uber e gasolina também é adequado aqui). Ou um serviço que monitora como uma pessoa dirige e fornece esses dados a empresas de seguros ou locadoras.

Ao mesmo tempo, as companhias de seguros ou de aluguel precisam impedir que o passageiro e o motorista os removem ou desconectem. Hoje eles são distorcidos por serviços que funcionam apenas com a ajuda de unidades de telecomunicações adicionais. E esta é a compra, instalação, integração, gravação do próprio serviço. Demora muito tempo e dinheiro.

Portanto, sempre olhamos para o veículo conectado em dois aspectos. Um lado é apenas conectar aos serviços de Internet. O segundo é o automóvel, como parte de uma economia compartilhada. Para fazer isso, todos os elementos básicos devem ser integrados ao carro na fase de sua produção. Portanto, estamos conversando com fabricantes de automóveis ou com fabricantes de computadores para automóveis.

Um dos problemas do setor é que não é possível apresentar casos de usuários porque não há uma abordagem de plataforma suficiente. O mesmo aconteceu com os telefones celulares. Você pode, por exemplo, dizer que existem 2.800 empresas criando soluções para o gerenciamento de frotas. Mas eles são todos muito monolíticos. Se você precisar alterar alguma coisa, precisará alterar os computadores de bordo e de telecomunicações. Afinal, eu quero fazer algo que esta unidade não pode fazer.

Como desligar com segurança um serviço comercial da nuvem para o carro? O que pode impedir isso e como resolvemos isso?

1. Contentores

Desde que partimos das idéias de Kubernetes, sua principal habilidade é implantar contêineres. Mas com um computador de carro é difícil.

Primeiramente, mesmo que em Python escrevamos algumas linhas de código que imprimem "Olá, mundo", o tamanho do contêiner pode chegar a 50 MB. Verter através de um canal celular pode ou não funcionar. Até o 5G místico tem os mesmos problemas que qualquer outra conexão: cobertura, largura de banda, estabilidade. Então você precisa aumentar as chances.

Em segundo lugar, o computador do carro é muito bom em poder de computação, mas ainda é muito mais limitado do que qualquer servidor menor na nuvem. Muitos outros programas rodam nele. Você não pode simplesmente vir e "comer" 200 MB de RAM.

Portanto, em primeiro lugar, descrevemos nosso tipo de contêiner na estrutura do padrão OCI. O problema com o tamanho é resolvido da seguinte forma: todas as coisas básicas que um desenvolvedor precisa para operar um serviço não precisam ser transportadas da nuvem. Eles já estão pré-instalados no computador do carro. Você precisa trazer apenas o próprio código, o que, na pior das hipóteses, leva centenas de kilobytes.

O problema com os recursos do computador de bordo é resolvido através da descrição em nossa especificação de contêiner. Devido a isso, você pode determinar com facilidade as cotas que o computador veicular monitorará. E o serviço instalado nunca pode excedê-los.

2. Segurança

O Kubernetes foi originalmente projetado para implantar e orquestrar serviços no Cloud. Ou seja, em um ambiente controlado, suportado e protegido das mãos erradas. Mas nós temos um carro, e os atacantes têm uma fantasia ilimitada. Eles podem retirar o computador de bordo, quebrá-lo com algum dispositivo, entrar no canal entre o carro e a nuvem. Portanto, a segurança é nossa tarefa constante de prioridade máxima.

Implementamos um modelo avançado de acordo com as recomendações da Agência de Segurança Nacional dos EUA. Ele diz o seguinte: ao projetar seu sistema de segurança, você deve primeiro minimizar o número de locais de ataque em potencial e também criar segurança como uma camada de bolo. Hackeado em algum nível? É necessário perceber isso e fazer todos os esforços para não deixar passar para o próximo.

No nosso modelo, a “torta” é assim:

1. Usamos contêineres como um tipo de isolador no nível do SO Linux. É muito difícil sair do recipiente;
2. Romper com o recipiente? Mas a plataforma Connected Vehiclle é executada em uma máquina virtual separada - para a qual precisamos do XEN. Esta máquina virtual é isolada de todos os periféricos. A comunicação com periféricos pode ocorrer apenas através de algumas APIs fornecidas pelo fabricante do carro;
3. Quebrou o contêiner e a máquina virtual? Temos mais uma barreira - introspecção de máquina virtual: análise de padrões nos quais a máquina virtual trabalha. Por exemplo, de repente, uma máquina virtual tenta agressivamente obter algum tipo de memória, a qual geralmente não toca. Você pode responder: desligue esta máquina virtual, volte para a versão estável etc.

3. Escala

O tempo de atualização é crítico nos smartphones dos usuários para serviços bancários móveis condicionais? Não especialmente. Se ao menos nada quebrasse no caminho. Para serviços em nuvem, a questão do dimensionamento não é grande coisa.

Não com um carro. Digamos que você alugou um carro e deseja usar seu serviço, o que lhe dá uma boa apólice de seguro, porque você dirige bem. Mas, para isso, é necessário que um serviço seja instalado no carro e entregue seus dados à companhia de seguros.

Você entrou no carro, inseriu a chave na fechadura, vira e após 3 segundos você está pronto para ir. É lógico que, nesses 3 segundos, o carro aceite todos os serviços necessários para a viagem. Mas se não houver uma dessas máquinas, mas 10.000? Um sistema que implanta serviços em um carro deve ser capaz de fazer isso rapidamente. O tempo de instalação deve ser constante, independentemente do número de veículos a serem instalados.

Resolvemos esse problema com a ajuda do complemento que desenvolvemos acima do RabbitMQ. Isso facilita o dimensionamento dos sistemas, dependendo de quantos nós você precisa usar.

4. Canais de comunicação

Quando ocorre a implantação da nuvem no carro, o canal de comunicação deve ser criptografado. Usamos TLS mútuo para autenticação. Ele funciona em duas direções: o carro efetua login na nuvem e a nuvem efetua login no carro. Tudo isso é baseado em certificados. Se os certificados não se ajustarem ou alguém tentar substituí-los, a autorização não ocorrerá e o acesso ao computador de bordo não será obtido.

Além disso, cada canal pelo qual os contêineres são despachados da nuvem para o carro é criptografado com seu próprio conjunto de chaves. Suponha que alguém tenha roubado uma chave, um certificado e tenha conseguido acessar o canal de transferência de contêineres. Mas ele só pode chegar ao canal desse carro em particular. Qual será a indicação. Você pode renovar os certificados, a nova criptografia TLS mútua começará a trabalhar neles - e todos os esforços de craqueamento não deram em nada. Isso evita o problema das redes IoT, quando um certificado hackeado pode comprometer todos os dispositivos.

5. Multitenancy

Imagine uma rede IoT doméstica inteligente comum. Possui fabricantes de dispositivos e operadores de rede. Como regra, as dependências entre dispositivos e operadores são estáticas. O ciclo de vida também é bastante estável: se você começar a trocar uma lâmpada inteligente por outra, não será em breve e você fará isso com pouca frequência.

No caso do carro e da economia compartilhada, essas dependências são muito dinâmicas. Existe um fabricante de automóveis . Existe um comprador / proprietário - digamos que esta é uma empresa de compartilhamento de carros. Existe um operador de serviço. E há um usuário final.

Proprietário, operador e usuário podem mudar o tempo todo. Na segunda-feira de manhã, o carro pertence a um determinado banco, o operador é a empresa A. Após o almoço, ele já é operado pela empresa B. Usuários de diferentes operadores também podem ser diferentes. Mas, ao mesmo tempo, os serviços que pertencem a eles devem migrar para carros diferentes.

Isso se chama Multitenancy aqui e é suportado pelo design em nosso sistema de gerenciamento de implantação de serviços. As funções do provedor de serviços e do provedor de serviços já foram definidas; nenhuma lógica adicional é necessária. Você pode atribuir serviços diferentes a um carro. Suponha que um carro seja transferido para outro proprietário. Os serviços do anterior serão removidos automaticamente e os serviços do novo serão entregues automaticamente. As redes IoT de hoje e os mesmos Kubernetes não são adequados - eles simplesmente não encontraram esse caso.

6. Monitorando a operação dos serviços

Para se comunicar com o serviço de carro, existe uma API padronizada chamada VIS - Vehicle Information Services. É padronizado pelo W3C. Essa API em nosso conceito é implementada e controlada pelo fabricante do carro. O serviço de veículo conectado está sob controle total.

Diferentes fabricantes estão começando a dar suporte a essa API. E o desenvolvedor não se importa com o fabricante do serviço.

Obviamente, todo fabricante de carros pode fazer algumas exceções. Como os smartphones: o Galaxy S9 e o S10 têm a mesma API básica, mas cada um tem coisas justas para um modelo específico. Em um carro, informações básicas também podem ser obtidas independentemente do seu tipo. E para coisas específicas, suas próprias nuances. Isso permite que os fabricantes criem coisas únicas e diferenciadas com valor agregado.

Quais são os componentes da plataforma escritos? E sobre o que será possível escrever serviços para carros?

A plataforma em si é escrita em Python. O gerenciamento de nível superior do sistema de implantação é escrito em Python. Toda a peça incorporada é escrita em C.

Quanto aos serviços, o primeiro suporte a Python, acrescentou JavaScript. A pedido de vários fabricantes de automóveis, o .NET foi adicionado. Fala-se de Java.

Em geral, esta é uma questão tática. Não há programadores JavaScript - há programadores. Penso que, com o desenvolvimento do setor automotivo, aparecerão programadores envolvidos em serviços de veículos conectados especificamente. Uma lâmpada “o que fazer se não houver conectividade?” Sempre piscará na cabeça Independentemente do que temos no ar - 5G ou 10G. A conexão sem fio não funciona 100% do tempo.

Como os fabricantes de automóveis reagem à plataforma?

Atualmente, qualquer montadora de automóveis possui uma divisão interna que desenvolve serviços conectados. Essas pessoas são capazes de trabalhar rapidamente. Mas eles são prejudicados por seus próprios departamentos de hardware e software interno.

Nós nos concentramos nisso. Trazemos uma ferramenta com a ajuda da qual seus próprios departamentos de desenvolvimento podem trabalhar com mais rapidez e flexibilidade. E os integrantes da embarcação, que agora estão mudando uma linha de código por 2 anos, poderão fazer isso uma vez com a plataforma - então o sistema permitirá que eles sejam independentes deles.

Em geral, os fabricantes olham para Aos com bastante atenção. Mas com interesse - porque abre novas oportunidades para eles. Por exemplo, eles podem criar um modelo de negócios como Amazon, Google, Microsoft: atribuir uma taxa de serviço pelo uso do computador de bordo, API etc. Além disso, acho que um dia eles chegarão a um modelo de mercado. Ou seja, os desenvolvedores de software e serviços conectados pagarão uma comissão pelo usuário que instala seu serviço.

Na indústria móvel, isso aconteceu rapidamente. Mas entendemos: as pessoas não trocam de carro todos os anos. O ciclo de desenvolvimento de software automotivo leva 4-6 anos. Portanto, o que estamos falando com as montadoras hoje começará a aparecer na forma de algum tipo de piloto pouco antes de 2022.

Estamos tentando copiar ou competir com a Tesla?

Não, e até vice-versa. A Tesla, diferente de outras, pode atualizar por via aérea qualquer software executado em qualquer computador no carro. Para que eles possam introduzir constantemente novos recursos. Mas o computador deles não é uma plataforma para o desenvolvimento de serviços de compartilhamento de carros. Você não pode comprar 10 carros, contratar 2 programadores e escrever um serviço interessante de compartilhamento de carros. Portanto, a Tesla também é um de nossos clientes em potencial. E do mais avançado.

Com a nossa plataforma, nem a Tesla nem outros fabricantes terão que gastar tempo inventando uma bicicleta. Afinal, ninguém nos aplicativos em nuvem já está desenvolvendo seus Kubernetes. Nossa visão é que isso aconteça com a plataforma de veículos conectados.

Se falamos sobre competição em geral, até agora não vimos um único concorrente que ao menos falasse sobre o que estamos falando. Como se viu, a indústria automotiva ainda está muito fechada. E muitas coisas na plataforma - o mesmo suporte para FOTA e SOTA - não apenas porque são necessárias agora, mas antes do previsto.

No entanto, não acho que, no futuro, haverá uma plataforma para todos os carros. , 2-3 . , . — . , .