qualquer carro, hoje, tem software. mesmo os mais simples, por mais incrível que pareça, têm muito software. e não se trata só de software naquele computador de bordo que a gente vê no painel. porque a bordo, em outras partes do carro, há computadores [sim, mais de um] de bordo, escondidos, mas fazendo [ou não, como se sabe] seu trabalho.
os computadores de bordo e seu software fazem de um tudo, de aceleração a frenagem, de controle dos mais diversos parâmetros do motor à verificação da pressão dos pneus e ajuste e controle de tração e suspensão. e parece que isso tudo ainda é pouco; a cada ano, uma parte ainda maior das funcionalidades dos carros é realizada por software, a ponto dos especialistas em aviação concordarem que o setor automobilístico passou o aeronáutico, há tempos, quando o negócio é software “embarcado”, aquele que anda [ou roda, ou voa] dentro dos carros e aviões.
o desafio de escrever software embarcado automotivo e que funciona corretamente pode ser considerado bem maior do que o de fazer sistemas de informação, digamos, para a web: enquanto estes existem e funcionam num mundo quase que puramente virtual, aqueles têm que interagir com coisas reais ao seu redor, como o motorista e passageiro, a estrada [e os buracos] o calor, o frio, o dia e a noite, o claro e o escuro. e os problemas, aqui, são muito mais concretos, até porque o software da web, do meu e do seu laptop não tem nenhuma garantia e o carro tem… e em alguns casos de até cinco anos. e daí?
daí que, já em 2002, a IBM já estimava que 50% dos custos da garantia dos carros estava relacionada a problemas com eletrônica e software. de lá pra cá, o problema só deve ter piorado. meu carro já trocou o software [e a autorizada não soube precisar que parte dele] uma vez, e só tem um ano e meio de uso. isso é uma mudança muito radical em menos de meio século: até os anos 70, software não tinha nada a ver com carro. clique na figura abaixo para ir até o relatório Shifting car makeup shakes up OEM status quo: Software strength is critical e ver a imagem abaixo em tamanho natural; os blobs verdes são funções essenciais [como controle de aceleração] e os amarelos são comodidades [como memória dos bancos].
em this car runs on code [“o combustível deste carro é software”], texto publicado no ieee spectrum de fevereiro de 2009, manfred broy dá o tamanho do problema atual: segundo ele, carros topo de linha podem ter 100 milhões de linhas de código [ou 100MLoC, million lines of code]. para você que não é de software, cada LoC é uma “instrução” entendida e executada pelo hardware, os computadores embarcados no carro, chamados de ECUs, ou “electronic control units”. há veículos que têm 100 ECUs conectadas em rede. pense na complexidade. nos mercedes classe S, segundo broy, somente o software que trata do console de entretenimento e navegação [rádio, cd… GPS] tem cerca de 20MLoC.
em 1983, um engenheiro da GM escreveu que… ”software development will become the single most important consideration in new product development engineering”… ou que …desenvolvimento de software se tornaria o problema mais importante do processo de desenvolvimento de novos automóveis... e não é que ele tinha uma bola de cristal? num carro padrão, o custo da eletrônica saiu de 5% na década de 70 para 15% em 2005, num híbrido, chega a 45%.
do ponto de vista das inovações no setor automobilístico, saímos de 10% derivadas de ou intensivas em eletrônica e software em 1970 para 90% em 2010. em outras palavras, quase tudo de novo que há no meu e no seu carro, hoje, é software. clique na imagem abaixo uma discussão detalhada deste tema em um relatório da mcKinsey.
em alguns anos, um carro básico terá 50% de todo seu custo associado à eletrônica e software e tal proporção deverá chegar a 80% num híbrido. e todos estes sistemas embarcados, como nós estamos acostumados a saber por experiência própria com o software que usamos em casa e no trabalho, têm problemas, e não poucos, e difíceis de serem identificados à primeira vista, mesmo pelos engenheiros que os desenharam e implementaram. quer ver parte das consequências?…
lá em 2005, a Toyota fez um recall voluntário de 160.000 prius modelos 2004 e 2005, pra resolver um problema de software que fazia o carro morrer de repente. o custo do “reparo” foi estimado em 240.000 homens hora. na época, a empresa dizia ter “consertado” um dos problemas relatados pelos motoristas mas que, para um segundo problema… "due to the limited amount of information surrounding the incidents"… estava tendo dificuldades para determinar a causa exata… e consequentemente em produzir uma novar versão do software que desse conta do defeito. tratava-se, muito provavelmente, de um defeito intermitente, oriundo da interação de vários sistemas de hardware e software e seus sensores e atuadores.
na atual leva de recalls da companhia, a toyota está trocando uma parte mecânica do acelerador em nada menos que oito milhões de veículos, além de um recall de 400 mil prius de última geração por um problema nos freios, atribuído pela própria toyta a um defeito de software. a operação toda deve custar mais de dois bilhões de dólares aos cofres da montadora japonesa. isso se ficar por aí: tem gente que teve a tal parte mecânica do acelerador trocada e, depois, sofreu um acidente por não ter conseguido desacelerar o carro, o que aponta para mais problemas de software.
segundo quem está por dentro do assunto, pode haver um erro sistêmico nos carros envolvidos, nenhum deles vendido no brasil, só em mercados “mais sofisticados”. aparentemente, o sinal de frenagem teria prioridade mais baixa do que o de aceleração. como assim, você diria? ora, pois: nos tais mercados “mais sofisticados”, os carros do recall da toyota são driven-by-wire, totalmente controlados por computadores e software, e isso faz com que não seja sua força física, no pé, que faz o carro freiar. quando você pisa no freio, o pedal captura sua intenção e um conjunto de sistemas tenta realizá-la usando os sensores e atuadores do veículo. se tudo der certo, o carro para. senão…
e isso nos leva à conclusão deste já muito longo texto: o mundo está em modo beta, como já dissemos aqui várias vezes [e que você pode ver em vídeo aqui].
já faz algum tempo que estamos fazendo tudo na base da execução imperfeita do desconhecido, o que leva quase tudo a não ficar pronto nunca. de mais de uma forma, estamos prontos, vamos dizer assim, pra aceitar tal característica [a dos sistemas se tornarem incrementalmente melhores com o tempo] no nosso emeio, site do banco e da empresa.
mas, considerando que só nos últimos seis meses a indústria automobilística mundial fez recalls de quase vinte milhões de veículos, será que não deveríamos pensar e trabalhar um pouco –ou muito- mais antes de botar na rua automóveis que parecem ter seu software em modo beta e às vezes, pelo que parece, muito beta demais?…
