O avanço das técnicas computacionais vem motivando a indústria automotiva a praticamente reinventar os seus produtos, fazendo com que os carros de hoje em dia sejam, de fato, um aglomerado de sistemas de computação se comunicando e tomando decisões que, em certos casos, chegam a ser superiores às intenções dos motoristas.
Para se ter noção da quantidade de computação presente em um carro nos dias de hoje, considere os seguintes dados: Um jato F-35 contém aproximadamente 6 milhões de linhas de código; um 787 Dreamliner, 7 milhões. Já um Mercedes-Benz classe S, aproximadamente 20 milhões de linhas de código. Em 2009, a Frost & Sullivan estimou que em um futuro não muito distante, os carros chegarão a 300 milhões de linhas de código.
Quais as implicações de tanta computação em um automóvel? Uma das principais, obviamente, é o custo de produçao. O Dr. Manfred Broy, professor de Ciência da Computação da TU Munique, e mentor para assuntos computacionais de uma renomada marca automotiva alemã, estima que o custo com software e eletrônicos em um carro chega a ser responsável por ate 40% do custo de um automóvel. Nos proximos sete anos, essa porcentagem deve chegar a até 80%. Levando em conta que a hora de profissionais de software nao é nem um pouco barata nos dias atuais (Good for us! :-)), espera-se que a contínua necessidade desses profissionais no desenvolvimento de carros eleve ainda mais os preços destes num futuro próximo. No contexto brasileiro, isso implica em carros ainda mais caros. Dai vê-se a necessidade de um ajuste na política de preços no setor automotivo brasileiro.
Diante desse cenário, os grandes nomes da computação têm voltado a atenção para o mercado automotivo: Microsoft firmando acordo com Toyota, a Google e seu Google Car, IBM, e até a Apple sonha sonhou em se aventurar no mercado automotivo com o utópico iCar.
Gostaria de compartilhar algumas experiências pessoais sobre os desafios no dia-a-dia no ambiente de desenvolvimento em algumas indústrias automotivas. Mas isso é assunto para outro post.
Aos interessados, recomendo a leitura do artigo This Car Runs on Code de Rober N. Charette, fonte primária das informações desse post.
Bytes don't Bite! 
Isso me levou a pensar sobre a probabilidade de inserção de bugs nesse tipo de produto durante seu desenvolvimento. Processos mal dimensionados poderiam até inviabilizar esses projetos em função dos rigorosos requisitos de segurança (entre outros) para esses tipos de produtos.
Penso que essa escalabilidade de quantidade de linhas de códigos é, em grande parte, devido a evolução das metodologias de software, muito mais do que questões como velocidade de processamento, quantidade de memória, aumento de disponibilidade e redução de custos de hardware, entre outros.
Bem interessante o artigo, caro amigo.
Jean,
Eu ia tocar nessa questao dos bugs no texto, mas iria ficar muito extenso. Entendo que, por isso, tecnicas rigorosas de Verificacao e Validacao de software devem ser consideradas e seguidas a risca desde o inicio do processo.
Quanto a quantidade de linhas de codigo, eu acredito na seguinte hipotese: a alta probabilidade de erros segerem gerados por falha humana (entenda-se por humano aquele que conduz um meio de transporte) demanda sistemas mais complexos, que possam contornar e/ou corrigir essas possiveis falhas.
Justifico: Um piloto nao ira tentar manobras de risco em altura e velocidade de cruzeiro. Por outro lado, um motorista faz manobras absurdas a 200Km por hora, com um carro lotado de pessoas. As acoes que podem causar uma catastrofe aerea tem um escopo que, ate certo ponto, eh previsto e controlado. No caso de um carro, um motorista pode fazer coisas que podem nao ter passado na cabeca dos engenheiros, e, consequentemente, pode nao haver acoes corretivas implementadas. Por conta disso, as heuristicas implementadas devem ser muito mais complexas, de modo a tentar corrigir acoes impensadas.
Agora eu te pergunto: Como tem sido a aceitacao e implementacao de praticas de engenharia de software no contexto que voce trabalha? Acho que seria interessante saber, pois, de certa maneira, os sistemas que voces produzem nao sao tao safety-critical como os mencionados ate entao aqui.
[]’s,
Pablo
Pablo,
Considere aceitação e implementação como tópicos distintos no meu contexto.
Com o tempo, consegui observar que existe interesse em melhorias nos processos de desenvolvimento interno. Dessa forma, considero que a aceitação dessas práticas tem sido bem tranquilas.
Quanto a implementação, ainda falta um investimento mais concreto no sentido de alocação de profissionais para tratar especificadamente desse assunto. Tenho tentado encabeçar essas iniciativas propondo metodologias, técnicas e ferramentas para gerenciamento de ciclo de vida de aplicações usando os pilares da metodologia ágil (TDD, Integração Contínua e scrum/kanban/lean). Além disso, as pessoas também são sempre barreiras para a implantação desses processos.
Tem funcionado bem. Mas é um processo lento.
Alguns resultados estão aparecendo. Com isso, acredito que teremos mais investimentos em um futuro breve. A ídeia é criar uma infra estrutura de código automatizada, modular e com altos índices de cobertura de código para evitar regressões, dado que se trata de um ambiente portável para várias arquiteturas de hw diferentes.
Ando me divertindo com essas coisas…
abraços,