Resumo Este artigo explora o paradoxo da interoperabilidade na metodologia BIM, onde, apesar de seu potencial colaborativo, a indústria de Arquitetura, Engenharia e Construção (AEC) opera em "silos de informação" devido a ecossistemas de software proprietários, como os da Autodesk (Revit) e Graphisoft (ArchiCAD). Analisa-se o papel do formato IFC¹ (Industry Foundation Classes) como principal mecanismo de troca de dados, destacando suas limitações como um "PDF do BIM", eficiente para preservação de dados, mas problemático em fluxos de trabalho cíclicos, causando perdas de inteligência paramétrica durante os processos de tradução (importação/exportação). Como contraponto, o artigo apresenta a ascensão do ecossistema OpenBIM², exemplificado pelo BlenderBIM. Esta solução de código aberto utiliza o Blender, um software de modelagem 3D, para operar nativamente com arquivos IFC, eliminando a etapa de tradução e, consequentemente, a perda de dados. Ao tratar o IFC como um formato de autoria e não apenas de intercâmbio, o BlenderBIM materializa os princípios do OpenBIM e aponta para um futuro de fluxos de trabalho híbridos e mais eficientes, onde ferramentas abertas atuam como mediadores essenciais para uma colaboração verdadeiramente integrada.

Palavras-chave: Interoperabilidade BIM, OpenBIM, IFC (Industry Foundation Classes), BlenderBIM, Revit, ArchiCAD, Fluxo de Trabalho Colaborativo.

     O BIM³ é uma metodologia desenhada para redefinir a colaboração da indústria de Arquitetura, Engenharia e Construção (AEC)⁴, sendo como ponto central do BIM a utilização de representação digital unificada em torno de um produto e do processo construtivo, facilitando a troca e a interoperabilidade das informações entre as diversas entidades envolvidas no processo construtivo, trocando informações de como os edifícios devem ser projetados, construídos e geridos ao longo do ciclo de vida deste produto, contudo com a crescente adoção de ferramentas BIM por essas entidades envolvidas, a indústria AEC, opera em “silos de informação, criando assim um paradoxo, na qual os dados desse produto que deveriam operar de forma livre, os dados ficam confinados a sistemas “fechados”, sem integrações entre as partes se estiver fora do fluxo desses sistemas, tornando a colaboração entre os envolvidos ineficiente.

Paradigma Proprietário e o Papel do IFC

     A realidade mercadológica que define o desafio da interoperabilidade no mercado BIM, é a incompatibilidade nativa entre os principais softwares concorrentes que a indústria AEC utiliza. Os atores são o software Revit da empresa Autodesk e ArchiCAD da empresa Graphisoft, sendo produtos de concorrência direta, não há mecanismos dentro dos softwares que permitem abrir, editar ou salvar os arquivos em formato padrão para que um possa fazer a leitura do outro. A nomenclatura de arquivos Revit são “.rvt”⁵ e do ArchiCAD “.pln”⁶, essa barreira é proposital, para que haja uma concorrência direta entre as empresas. Esse modelo de negócios foi historicamente o que alavancou essas empresas no ramo de distribuição de softwares e está sendo replicado para a indústria em torno do BIM, criando ecossistemas fechado e incentivando usuários a permanecerem dentro de um pacote de soluções nativos apenas dentro da empresa.

     Com essa incompatibilidade proposital, a única comunicação entre arquivos que foi amplamente aceita no mercado e é amplamente utilizada para diminuir este gargalo de troca de modelos foi através de um formato intermediário, aberto e neutro, o IFC (Industry Foundation Classes). Com esta única solução nesse padrão de troca de informações, o IFC atua como o único tradutor e mediado entre sistemas que não foram projetados para se comunicas.

     O IFC se tornou o padrão de troca de informações entre os softwares BIM, sendo robusto e abrangente e foi formalizada através da norma ISSO 16.739, teve como premissa de projeto fazer o encapsulamento da semântica e geometria de um ativo, independente do software mandatório, no termo leigo para descreve-lo é um “PDF do BIM”, esse termo é interessante pois o IFC é excelente na função de encapsular e preservar o estado atual do ativo, da informação ali contida em um determinado momento, garantindo a fidelidade da geometria e das informações ali contidas. Assim como o PDF funciona, na qual os arquivos são empacotados nesse formato, quando há posteriores edições ele não se torna seguro, as “amarras” que garantem a integridade de um arquivo PDF não são mais válidas quando ocorre uma edição. O IFC não foi concebido para esse fluxo de edição cíclica e reversível que ocorre durante a fase de projeto e posterior na fase do ciclo de vida do ativo. Quando há uma conversão do parâmetro IFC para os softwares de ecossistema fechado, e depois uma exportação para troca em outros softwares ocorre uma perda de informações, principalmente em modelos paramétricos, resultado em perda de inteligência paramétrica e criando restrições nos componentes editáveis desses ativos.

     Essa perda entre transferência de dados de modelos do software Revit e ArchiCAD são previsíveis, recorrentes e conhecidos, não são perdas aleatórias. Dessa forma é possível desenvolver fluxos para mitigá-los parcialmente. A perda mais significante dentro de um processo de desenvolvimento de um ativo é a perda significativa do comportamento paramétrico, cada software possui uma lógica interna, com padrões, fórmulas e parâmetros proprietários que definem e os tornam inteligentes. Essa lógica não é padronizada pelo esquema IFC, ou seja, quando há troca de informação entre os softwares há uma parca de dados, e os elementos são carregados de forma! congelada”, na qual não podem ser mais parametrizadas nos softwares obsequentes dentro de um fluxo de trabalho. Mais dois exemplos de problemas são primeiramente quando uma parede complexa do Revit é exportada para o ArchiCAD, e a parede perde sua função de parametrização que é alongar, diminuir e assim por diante, essa propriedade se perde pois o software não consegue “traduzir” esse item devido não estar parametrizado pelo esquema IFC, o mesmo acontece quando há uma exportação do ArchiCAD para o Revit e muitas das categorias são relacionadas como Modelos Genéricos, sendo assim impossível de filtrar, quantificar e gerencias esses modelos dentro de um fluxo BIM de forma automática.

A Fronteira do OpenBIM: O Ecossistema BlenderBIM

     Um ator inesperado para uma solução parcial desse problema de interoperabilidade entre os softwares está em um software que para muitos na indústria ARC, se remete apenas a animações 3D, efeitos visuais e desenvolvimento de jogos, e o Blender, um software de desenvolvimento de código aberto, gratuito, multiplataforma e equipado cum uma interface de API⁷ (Programa de Aplicações) em Python⁸, sendo muito bem documentada e robusta. Essa interface de API que permite que um software dedicado a modelagem de objetos 3D seja utilizando como um ambiente modelador de desenvolvimento flexível, permitindo que a comunidade cri plugins complexos estendendo a função do software e criando soluções com o BlenderBIM para tentar mitigar esse problema.

     Por ser um software gratuito e aberto, a não existe barreiras financeiras de licenciamento, essa acessibilidade combinado com a API, torna o software propicio para desenvolvimento de soluções fora do escopo principal do software.      A solução desenvolvida não é apenas a importação e exportação de arquivos IFC, mas sim na arquitetura com que foi desenvolvida, sendo uma ferramenta de autoria BIM completa, operando de forma direta e nativamente o formato de arquivo IFC, criando uma mudança no fluxo de trabalho tradicional.

O fluxo do processo de intercâmbio comum em softwares proprietários seguem o seguinte, sendo dividido em três etapas:

1 – Criação de dados em um formato nativo fechado (por exemplo arquivo .rvt ou .pln) 2 – Tradução dos dados para o formato IFC (arquivo exportado) 3 – Tradução do formato IFC que foi exportado para o formato nativo da outra plataforma (importação).

    É durante essa fase de tradução que a ocorrência de perda de dados entre os softwares fechados.      O BlenderBIM elimina essa fase de tradução pois quando o usuário “abre” um arquivo no formato IFC, não há conversão do formato para o .blend do software BIM que é proprietário, há uma leitura de toda a estrutura de dados IFC diretamente na memória sem a etapa de tradução. Essa etapa também acontece no momento de salvar o arquivo, aplicando as modificações diretamente no formato IFC, esse fluxo é conhecido como “autoria IFC nativa”, sem processos de importação e exportação, sem perdas por tradução do formato.

Análise Comparativa de Fluxos de Trabalho

    É possível transformar dessa forma o software Blender, e uma plataforma de concepção BIM completa na qual o usuário inicia um projeto e todos os elementos criados são nativamente entidades IFC com marcação correta da semântica (IfcWall, IfcDoor), com atributos e propriedades padrão.

     A filosofia por trás dessa ferramenta técnica é a materialização do OpenBIM, os princípios se alinham de um ecossistema de construção aberto e colaborativos sendo os principais pontos ser de Código Aberto, Transparecia Total e Controle e Propriedade dos Dados. A inovação nesse pequeno passo não está em replicar as funcionalidades de um software completo para o BIM como o Revit e o ArchiCAD, mas em tratar o IFC não como um formato de intercâmbio apenas para tradução, mas em um formato nativo, contornando assim a raiz do problema de perda de dados, a tradução, é uma plataforma centrada em dados.

     Essa análise aprofunda os fluxos de trabalhando de interoperabilidade BIM de forma híbrida em um futuro colaborativo a busca por uma troca de dados direta e perfeita entre concorrentes direta é um problema que não vai ser solucionado pelas empresas líderes de mercado, e solução de arquitetura de softwares como o Blender podem vir a abrir caminhos para outras soluções em um meio termo. Este relatório demostrou o que seria uma chave para uma verdadeira colaboração, mas ao invés de tentar solucionar um problema por meio de mudanças de direção em softwares líderes de mercado, mostrar alternativas para resolver o problema de perda de dados durante a interoperabilidade. A doção de um ecossistema híbrido, na qual ferramentas de código aberto atuam com mediadores essenciais na troca de informações.