Carros autônomos em código aberto

(Artigo da Forbes em 2019)


Brad Templeton com uma versão inicial do Stanford Robocar.

Sobre o autor: Brad Templeton é engenheiro de software, evangelista de carros robóticos desde 2007, trabalhou no Google nos primeiros anos. Fundador da ClariNet , presidente honorário da Electronic Frontier Foundation e diretor do Foresight Institute , fundador do corpo docente da Singularity University .

É difícil seguir as regras do desenvolvimento aberto ou invenções amadoras quando você cria um robô de 1,3 toneladas e o envia para andar pelas ruas entre pedestres. No entanto, inovadores amadores são muito importantes para qualquer tecnologia em desenvolvimento. Como resolver a contradição?

Recentemente, houve vários anúncios interessantes no campo do desenvolvimento de código aberto.

• Cruise abriu o código fonte do Worldview, um visualizador de robôs . Este é um conjunto de ferramentas que facilita a criação de representações gráficas de sensores, áreas sensoriais e outros dados para entender o que sua máquina vê e faz.
• A Uber também lançou seu kit de ferramentas AVS para visualização semelhante.
• O Baidu lançou há algum tempo o projeto Apollo , que inclui um conjunto completo de ferramentas e um simulador.

Pacotes de código aberto da UDacity, EB Robinos, Autoware, Nvidia e comma.ai também foram lançados. E apesar de não estarmos no nível em que você pode baixar um conjunto de ferramentas e criar um carro amador, desta vez chegará.

Eu tenho um longo histórico de trabalho com ferramentas de código aberto e lancei vários pacotes de software de código aberto sob licenças gratuitas. Como presidente da Electronic Frontier Foundation, defendi com frequência os direitos desse software.

Essas ferramentas ajudarão os desenvolvedores a trabalhar mais rápido e a se unirem para criar os melhores carros autônomos. Isso vale especialmente para as ferramentas usadas para criar software para máquinas robóticas, pois há um forte incentivo à colaboração nessa área. As equipes integrarão componentes úteis de código aberto em suas máquinas, se as licenças permitirem. Algumas equipes poderão criar veículos completamente usando o código aberto. Existem exemplos de projetos de código aberto que superam em muito as iniciativas de negócios mais caras. Além disso, há boas razões para argumentar que as ferramentas de código aberto podem ser mais seguras, pois cada parte está sob o escrutínio de todo o mundo. Obviamente, os invasores veem a fonte e isso pode ajudá-los a encontrar vulnerabilidades, mas há muito mais gente boa que também vê esse código e trabalha para protegê-lo.

Tudo isso é esperado, mas também há um problema para uma pessoa que é uma estrela dos métodos de desenvolvimento de código aberto - mestres únicos. As pessoas que aprimoram os sistemas fazem isso simplesmente porque os usam e desejam torná-los ainda melhores e compartilhar seus sucessos. Essas pessoas são as principais responsáveis ​​pela maioria das ferramentas abertas que usamos, embora alguns projetos importantes e grandes, é claro, tenham sido criados por grandes equipes com financiamento profissional.

Você pode pegar um conjunto de software de código aberto, baixá-lo em sua máquina e fazê-lo funcionar sozinho enquanto assiste TV? Você pode fazê-la trabalhar sem motorista para que ela possa buscá-lo? Você pode fazer alterações ao seu gosto ou baixar outras modificações e seguir em frente com elas? Essa é uma pergunta muito mais complicada.

As pessoas fazem essas coisas o tempo todo em outras áreas da programação. No entanto, o telefone é muito diferente do carro. Uma falha de segurança no telefone pode permitir que os atacantes acessem seus dados pessoais, até mesmo informações de cobrança, e isso é sério. Mas a vulnerabilidade em um carro pode custar a você ou a outras pessoas na estrada.

Autocertificação

Atualmente, os reguladores têm uma política de não intervenção. E, embora estejam adiantados e criem regras para tecnologias que ainda não existem, eles se concentram principalmente nas condições de autocertificação para máquinas produzidas pelos principais players do mercado.

A autocertificação significa que a empresa está testando a máquina e declara que realmente atende às metas e requisitos de segurança estabelecidos nas regras, e terceiros ou o estado não verificam nada disso. Em vez disso, se a empresa cometer um erro ou, pior ainda, mentir sobre o cumprimento dos requisitos, eles serão torturados no tribunal. Idealmente, esse deveria ser um tormento que motivará as empresas a realizar testes ainda melhores do que qualquer terceiro ou estado.

Não é tão difícil assim. A verdade é que ninguém sabe como criar um centro de testes independente, pois não está claro o que verificará ou como funcionará. Nem mesmo o próprio governo tem uma pista. Para carros comuns, existem testes que são bem compreendidos, por exemplo, testes de colisão. Além disso, o número de aspectos que são verificados por organizações externas é muito diferente de país para país. Mas na maioria dos casos, as pessoas que criam carros ou componentes sabem muito mais sobre verificações e confirmações de segurança do que qualquer outra pessoa, e motivar os fabricantes a serem honestos é uma técnica eficaz.

No caso de máquinas robóticas, esses testes só podem ser realizados através de um estudo aprofundado do software e de sua operação. Você deve entender completamente isso para fazer isso. Existem vários testes universais que podem ser realizados por laboratórios independentes e que serão realmente úteis. Com o tempo, mais testes e mais laboratórios aparecerão para eles, mas os desenvolvedores criarão novas abordagens que não se encaixam nos testes antigos. Padrões e regras podem definir técnicas geralmente aceitas e relevantes a curto prazo, não sendo muito úteis em um campo em rápida mudança em que novas abordagens são inventadas regularmente.

Valor

Embora a autocertificação pareça ser o único sistema que funciona para um único mestre, infelizmente, os princípios no núcleo deste sistema exigem que o certificador tenha peso suficiente para confirmar suas reivindicações. Uma pessoa, em regra, não tem meios para evitar o tormento da falta de certificação adequada. Grupos de pessoas podem evitar tais situações, mas é difícil até para elas. Os testes também serão caros se certificados por terceiros. Tudo isso significa que essa é uma prática pouco frequente que pode ser realizada racionalmente apenas para softwares que executam milhares de carros.

Mesmo se houver um pacote de software certificado como seguro, e se você fizer alterações relevantes para partes importantes do código que afetam a segurança? Você pode dirigir um carro assim na estrada com muitos obstáculos? Essa ainda é uma pergunta complicada.

Soluções

Uma solução possível seria comprar um seguro. Infelizmente, isso também tem suas dificuldades. Muito provavelmente, o risco será maior do que o coberto pelo seguro moderno típico. Além disso, as companhias de seguros não possuem métodos para determinar o quão bom você é um programador e quão seguras são suas modificações.

Você deve poder fazer suas modificações e dirigir na estrada no modo de direção segura com pelo menos uma pessoa e provavelmente dois testadores, que estão monitorando o novo software e prontos para assumir o controle em caso de problemas. É assim que os carros são testados hoje; assim foi com o piloto automático da Tesla. Isso funciona, mas apenas para desenvolvedores sérios que estão dispostos a investir muito tempo e recursos, e não funciona para amadores que querem apenas fazer alterações no software de seus carros.

Pode haver uma situação em que o programador, após uma pequena verificação de direção segura, possa enviar suas edições para uma organização maior que possa integrar essas edições em seus testes. Eles podem testar centenas de modificações (independentes) de diferentes desenvolvedores ao mesmo tempo. Esses programadores poderão compartilhar o custo disso e não apenas testar juntos para trazer seu código ao nível em que a certificação é possível. No entanto, ainda é caro.

"Mentor"

Também é possível criar um tipo de "mentor" de software. Pode ser um programa certificado simples, que é um driver seguro e automatizado. De fato, esse programa pode ser retirado do núcleo de um sistema reconhecido e altamente confiável que possui todos os certificados de segurança. Sua máquina funcionará em seu próprio sistema modificado, mas, ao mesmo tempo, o "mentor" monitorará constantemente seu trabalho. Se o seu sistema fizer algo que o mentor não gosta, ele assumirá o controle e conduzirá o carro para um local seguro ou em casa.

O mentor irá dirigir com cuidado. Isso significa que, usando essa técnica, você não pode criar nada mais agressivo que ela. Se o mentor diz que você precisa parar e seu programa diz que precisa ir, então o programa está desativado. O gerenciamento humano pode ter uma prioridade mais alta que um mentor. Funções que exigem mais permissões do que o mentor pode dar não são viáveis ​​para desenvolvimento e teste nas estradas por mestres únicos, embora ainda possam trabalhar neles em simuladores.

De fato, os simuladores são a salvação de engenheiros amadores, especialmente considerando que os simuladores estão ficando cada vez melhores. Eles existem para encontrar rapidamente problemas e soluções malsucedidas em novos patches, além de garantir que antes de dirigir na estrada, o carro treine em uma milhagem virtual de muitas milhas.

Provavelmente, o mentor deve se basear em uma versão certificada do mesmo conjunto de software de código aberto que é modificado por um engenheiro amador. E, de fato, se o programador descobrir que a ação que o mentor se recusou a executar é realmente segura, ele poderá enviar uma mensagem de erro (e até mesmo uma correção) e, finalmente (embora não imediatamente), o mentor poderá ser treinado melhor mais comportamentos nos programas em teste.

A segurança é uma preocupação particular. O software modificado pode ter falhas de segurança que permitem que um invasor assuma o controle de um mentor. Precisamos que o mentor trabalhe com eficiência, mas outro nível de qualidade é a capacidade do mentor de reconhecer um programa malicioso que está tentando enganá-lo. Qualquer vulnerabilidade de um mentor que possa levá-lo a permitir alguma ação insegura pode ser um problema.

A necessidade de artesãos

Precisamos daqueles que são chamados de artesãos no mundo automotivo ou, como os chamamos no mundo dos computadores, de hackers (o uso da palavra "hacker" no sentido de um criminoso de computador é usado principalmente fora da comunidade de desenvolvedores de software. o mesmo significado que o “mestre de artesãos” e o especialista em crimes de computador ou hackers é outro tipo de hacker). Todas as grandes empresas automobilísticas começaram sua jornada como artesanato. Muitos estados têm leis que fazem exceções especiais às regras usuais de segurança de veículos para veículos exclusivos criados por artesãos, desde que cumpram as regras básicas de segurança de transporte. E funciona, especialmente porque esses veículos sempre têm um motorista e, como regra, esse é o criador deles. No mundo do software, hackers (em um sentido não criminal) contribuíram com uma grande parte da inovação.

Queremos até apoiar a ideia de uma pequena empresa de automóveis que possa distribuir ou vender sistemas modificados para máquinas robóticas com um mentor integrado aos clientes interessados. Ao contrário de clientes em outras áreas, eles colocam outras pessoas em risco, e não apenas elas mesmas, mas a inovação também requer pequenas empresas.

Um mentor como o que foi descrito ainda não existe. Mas deveria estar em nossos planos, já que o mundo de veículos não tripulados, sem inovações de artesãos e hackers, será menos desenvolvido e seguro do que um mundo em que apenas grandes empresas possam contribuir.

---

Leia artigos mais úteis:

• McKinsey: Repensando a arquitetura de software e eletrônica no setor automotivo
• Outra guerra do SO já está sob o capô dos carros
• Código do programa no carro
• Em um carro moderno, há mais linhas de código do que ...