Keeping the reasoning with the geometry: rules, reactions and checks in production automotive CAD

No mundo da fabricação de carros, existe uma crise silenciosa que acontece muito antes de um veículo sequer chegar a um showroom. Engenheiros passam anos projetando as curvas de um para-choque ou o posicionamento de um sensor, mas a parte mais valiosa desse trabalho — o raciocínio por trás de cada decisão — é frequentemente a primeira coisa a desaparecer. Quando um designer deixa uma empresa, ele leva consigo o "porquê" por trás do "o quê". Os arquivos de computador permanecem, contendo a forma exata do carro, mas a lógica que justificou essas formas desaparece no ar. Isso deixa a próxima equipe com um quebra-cabeça: eles podem ver que o vão entre duas partes é de doze milímetros, mas não têm ideia se deveria ser dez, ou se doze foi um compromisso feito para evitar uma colisão com um fio oculto. Por décadas, a indústria tentou resolver isso mantendo as regras em documentos ou planilhas separadas, esperando que alguém se lembrasse de verificá-las. Mas os documentos se afastam dos designs que deveriam governar, e o raciocínio se perde repetidamente.

Este artigo relata uma abordagem diferente, testada no ambiente de alto risco da produção real de automóveis. Em vez de manter as regras fora do design, o autor as moveu para dentro. Imagine uma peça de carro que, toda vez que é aberta ou alterada, verifica automaticamente a si mesma contra um conjunto de condições rigorosas. Se um design viola uma regra, o próprio modelo sinaliza o erro imediatamente, exibindo um aviso diretamente na tela onde o engenheiro está trabalhando. Este não é um arquivo passivo esperando para ser revisado; é um sistema ativo que observa, atribui valores e reage às mudanças no momento em que elas ocorrem. O estudo acompanhou quatro programas reais de carros e uma rede específica de sensores usada para ajudar motoristas a estacionar, bem como um apoio de braço dobrável construído para testar os limites deste método. O resultado foi um sistema que manteve o raciocínio vivo mesmo quando as pessoas saíam, mas também revelou uma verdade dura: um modelo de computador pode mostrar um erro, mas não pode forçar um humano a corrigi-lo.

O cerne deste trabalho é um método chamado Design Ativado por Conhecimento (Knowledge-Activated Design). Na engenharia tradicional, uma regra pode estar em um manual ou em uma planilha, separada do modelo 3D da peça do carro. Um engenheiro tem que se lembrar de consultar o manual, encontrar a regra e, então, verificar o modelo. Se ele esquecer, ou se o manual estiver desatualizado, o design pode passar com uma falha oculta. Neste novo método, a regra é escrita diretamente no código do modelo. Quando o modelo é reconstruído — talvez porque um designer alterou a forma de um para-choque — a regra é executada automaticamente. Ela verifica a nova forma contra os requisitos antigos. Se a forma estiver errada, o modelo fica vermelho ou exibe uma mensagem de aviso instantaneamente. O engenheiro vê o veredito ali mesmo, diante de si, sem esperar por uma reunião semanal ou um processo de revisão separado.

O autor testou isso em uma rede complexa de sensores para assistência de estacionamento. Esses sensores são complicados porque devem ser posicionados de uma forma que satisfaça cinco grupos diferentes: as pessoas que projetam a aparência do carro, os engenheiros que acomodam a eletrônica, a equipe que constrói o carro, os especialistas em segurança e os gestores de cronograma. Uma mudança na pele externa do carro poderia arruinar o posicionamento de um sensor, exigindo uma longa cadeia de reuniões para corrigir. Ao incorporar as regras para esses sensores diretamente no modelo de computador, o sistema pôde testar cada posição possível instantaneamente. Quando um designer propunha um novo local, o modelo mostrava imediatamente se ele bloqueava a visão de um sensor ou se estava muito próximo de uma parte metálica. O modelo não dizia apenas "sim" ou "não"; ele mostrava as consequências, como um cone de detecção atingindo o chão ou um suporte que não caberia.

Esta abordagem mudou a forma como as equipes trabalhavam. Em um caso, um engenheiro sênior que conhecia todos os detalhes sobre o posicionamento de sensores deixou a empresa no meio de um projeto. No passado, isso teria causado semanas de confusão enquanto a equipe tentava descobrir por que certos locais foram escolhidos. Em vez disso, o engenheiro substituto abriu o mesmo arquivo de computador e encontrou o raciocínio construído diretamente na peça. As verificações, as regras e o histórico de decisões estavam todos lá, visíveis e ativos. O novo engenheiro não precisou adivinhar ou perguntar a ninguém; o modelo disse a ele o que era aceitável e o porquê. Isso provou que o "porquê" poderia ser preservado no próprio design, sobrevivendo à partida das pessoas que o criaram.

No entanto, o estudo também descobriu um limite nítido onde este método deixa de funcionar. O autor construiu um segundo exemplo, um apoio de braço dobrável, para ver até onde as regras poderiam viajar. Neste caso, uma medição fundamental baseava-se em um teste físico realizado fora do computador, em um laboratório. O modelo podia armazenar esse número e verificar contra ele, mas não conseguia descobrir o número por conta própria. Como a regra dependia de um valor fixado por um teste físico, o sistema não conseguia automatizar totalmente a decisão. Isso mostrou que, embora o método seja poderoso, ele não pode substituir a necessidade de julgamento humano ou dados externos. O modelo pode aplicar uma regra, mas não pode criar a regra se a resposta estiver fora de sua própria lógica.

Talvez a descoberta mais reveladora tenha vindo de uma situação em que o sistema funcionou perfeitamente, mas os humanos não. Em um programa de carro, três grupos diferentes fizeram acordos separados que lentamente empurraram uma dimensão crítica além do seu limite seguro. O modelo de computador viu isso acontecendo. Cada vez que o design era atualizado, o modelo emitia um alerta, mostrando que a regra havia sido quebrada. Era claro, inegável e visível para todos. No entanto, os engenheiros responsáveis pelo lançamento do carro decidiram ignorar o aviso e aprovaram o design de qualquer maneira. Eles tinham seus próprios motivos, provavelmente relacionados a custo ou tempo, mas o computador não os impediu. O modelo podia mostrar o erro, mas não podia impor a decisão. Isso destacou um limite crucial: o sistema torna o raciocínio visível, mas não possui autoridade para interromper um projeto. O poder de dizer "sim" ou "não" permanece com as pessoas, não com o software.

O estudo conclui que mover as regras para dentro do modelo é uma forma poderosa de manter o conhecimento de engenharia vivo. Transforma um desenho estático em um documento vivo que se explica. Garante que, quando uma equipe altera uma forma, ela veja imediatamente o impacto na segurança, no empacotamento e na fabricação. Mas não é uma solução mágica que resolve tudo. Requer disciplina para manter as regras atualizadas e não pode sobrepor as complexas negociações que ocorrem em uma empresa real. O maior ganho não é necessariamente velocidade ou dinheiro, mas clareza. O raciocínio por trás da geometria deixa de sair do edifício. Quando um designer abre um arquivo, ele não está apenas olhando para uma forma; ele está olhando para os argumentos que a construíram, preservados de uma forma que ninguém pode deletar acidentalmente.