A história do IFC: da geometria à informação conectada

O IFC é resultado de décadas de pesquisa, decisões técnicas e colaboração entre empresas. Sua história ajuda a compreender por que compartilhar um modelo exige mais do que exportar geometria: é preciso preservar o significado dos elementos e organizar as informações que serão utilizadas por outras equipes.

Este artigo é uma síntese editorial em português brasileiro baseada no BIMcert Handbook 2024, seção “The History of IFC (Industry Foundation Classes)”, por Rasso Steinmann — autor convidado. Steinmann relata essa trajetória como participante do desenvolvimento desde 1985. Os episódios históricos e as perspectivas apresentados a seguir são atribuídos a esse relato; as implicações práticas ao final são uma leitura editorial do ARQUITETURA.COM.

As bases: dados de produtos e STEP

As raízes dessa história estão na evolução do processamento de informações e da modelagem de dados nas décadas de 1960 e 1970. Para a construção, o desafio seria representar digitalmente produtos, componentes e suas relações de maneira compreensível por diferentes aplicações.

Um marco foi o desenvolvimento do STEP, iniciado em 1984. A proposta buscava estabelecer padrões para o intercâmbio de dados de produtos. A complexidade levou à divisão do padrão em partes, em vez de concentrar tudo em um único modelo universal.

Três componentes ajudam a entender sua relação com o IFC:

Componente	Função
EXPRESS — ISO 10303-11	Linguagem para descrever a estrutura de um modelo de dados.
STEP Physical File — ISO 10303-21	Formato para intercambiar instâncias desse modelo em arquivos de texto.
ISO 10303-28	Representação dos dados para intercâmbio em XML.

O EXPRESS-G permite visualizar estruturas do esquema de dados por meio de diagramas. A distinção essencial é entre o esquema que define como os dados se organizam e o arquivo que transporta os dados de um modelo específico.

Da geometria aos objetos com significado

As primeiras abordagens de intercâmbio eram fortemente influenciadas pelos sistemas CAD. O foco estava na geometria, à qual se acrescentavam classificações e algumas propriedades.

Segundo Steinmann, projetos de pesquisa europeus mostraram a necessidade de outra abordagem para as edificações: modelos semânticos, nos quais os componentes são objetos com atributos e relações. A geometria continua importante, mas passa a integrar uma estrutura de informação mais ampla.

Uma parede, nessa perspectiva, pode ser reconhecida como elemento de uma edificação, com propriedades e relações com outros objetos. Sua forma é uma parte dessa descrição. Essa mudança ajuda a explicar a passagem do desenho digital para modelos capazes de apoiar diferentes usos da informação.

VEGA e O.P.E.N.: uma arquitetura que podia crescer

No projeto europeu VEGA, uma equipe liderada pelo professor Richard Junge e pelo doutor Thomas Liebich desenvolveu uma abordagem de modelo semântico de produto em cooperação com a Nemetschek.

A abordagem foi levada ao projeto O.P.E.N., na década de 1990. Um de seus recursos era o late binding, ou vinculação tardia: o modelo de dados do servidor podia ser ampliado durante a execução, sem recompilar os programas.

A arquitetura organizava um núcleo de componentes e topologias comuns, com uma camada superior para estruturas específicas de cada domínio. Isso permitia ampliar o modelo gradualmente.

Steinmann descreve o O.P.E.N. como um servidor de modelos para a construção que também podia ser utilizado pela internet. Contudo, o mercado ainda estava muito ligado aos processos analógicos. A tecnologia exigia mudanças de trabalho que uma empresa de software, sozinha, não conseguiria promover. O projeto foi descontinuado, mas sua abordagem de modelagem voltaria a ter importância na evolução do IFC.

A interoperabilidade como necessidade do setor

Nos Estados Unidos, empresas como a HOK perceberam que os sistemas CAD, então utilizados principalmente como ferramentas de desenho, eram insuficientes para trabalhar com componentes e suas informações.

Complementos do AutoCAD ofereciam funções específicas, mas seus dados ultrapassavam o escopo convencional do DWG/DXF e não eram compatíveis entre si. A necessidade de interoperabilidade levou a uma colaboração com a Autodesk para desenvolver uma base comum de dados.

Quando ficou claro que essa base deveria contemplar diferentes áreas de aplicação, o projeto foi aberto. Em 1995, foi fundada a IAI — International Alliance for Interoperability, posteriormente renomeada buildingSMART.

O objetivo ganhava outra escala: construir uma linguagem compartilhada que permitisse a colaboração entre participantes com ferramentas distintas.

Os primeiros arquivos IFC

O desenvolvimento inicial incorporou especialistas da comunidade STEP e uma abordagem de modelagem do professor Frits Tolman. Após protótipos e discussões das versões preliminares, o IFC1.5.1 passou a ser suportado por alguns sistemas de software. O intercâmbio foi demonstrado na feira ACS de 1998.

Uma curiosidade registrada por Steinmann é que o primeiro arquivo IFC do mundo foi exportado pelo Allplan. O programa já suportava o STEP AP225, e sua equipe dispunha de experiência com essa tecnologia. Trata-se de um episódio do relato histórico, não de uma comparação de desempenho entre ferramentas atuais.

Outra particularidade é a extensão .ifc. O autor explica que, seguindo estritamente o formato físico STEP, os arquivos usariam a extensão .spf. A identificação própria do IFC acabou sendo aceita pela ISO.

IFC2x: o recomeço necessário

O modelo inicial apresentava uma dificuldade estrutural: sua arquitetura era monolítica. Uma ampliação funcional podia exigir mudanças até o núcleo, tornando difícil manter a compatibilidade entre aplicações com ciclos de lançamento diferentes.

Após o IFC2.0, a arquitetura em camadas desenvolvida no VEGA e no O.P.E.N. foi apresentada como solução. O novo começo foi conduzido com Jeffrey Wix na gestão do projeto, Thomas Liebich à frente do Model Support Group — MSG e Steinmann liderando o Implementer Support Group — ISG.

Segundo o autor, a nova versão poderia ter sido chamada IFC3.0. Por razões diplomáticas, recebeu o nome IFC2x, com o “x” indicando extendable, ou extensível.

A mudança rompeu a compatibilidade com o IFC2.0, mas criou uma base mais adequada à expansão do padrão. A experiência acumulada com STEP ajudou os desenvolvedores na transição.

MVDs e certificação: trocar o que é necessário

Com a ampliação do IFC, ficou evidente que cada aplicação não precisava implementar todo o modelo de dados. Um programa estrutural e um programa de instalações atendem a finalidades diferentes.

Nesse contexto surgiu o conceito de MVD — Model View Definition, ou definição de vista do modelo. Uma MVD especifica um subconjunto do esquema necessário para determinados intercâmbios.

A Coordination View consolidou uma base para a coordenação entre arquitetura, estrutura e instalações em edificações. No panorama apresentado pelo manual de 2024, o IFC2x3-CV2.0 aparece como uma combinação estável e amplamente suportada.

O relato também destaca a distância entre anunciar suporte a IFC e implementá-lo de forma consistente. A insatisfação dos usuários levou à criação de um sistema de certificação, desenvolvido por Steinmann e Liebich para a buildingSMART.

Para o IFC4, a plataforma b-Cert ampliou a automação dos testes e a capacidade de atender diferentes MVDs e versões. A certificação integra essa trajetória de melhoria das interfaces de intercâmbio.

Marcos da evolução

A seleção abaixo resume marcos mencionados no texto de referência. Não constitui uma lista completa de versões ou uma recomendação de formato para projetos atuais.

Marco	Importância na trajetória
1984 — início do STEP	Desenvolvimento de padrões para intercâmbio de dados de produtos.
1995 — fundação da IAI	Organização da colaboração internacional pela interoperabilidade.
1996 — IFC1.0	Primeira versão publicada do IFC.
1998 — IFC1.5.1	Suporte por alguns sistemas e demonstração de intercâmbio.
1999 — IFC2.0	Etapa anterior à reformulação da arquitetura.
IFC2x	Reorganização do modelo com uma arquitetura extensível em camadas.
2006 — IFC2x3	Base da posterior consolidação do IFC2x3-CV2.0.
2013 — IFC4	Nova geração com mudanças nas estruturas básicas.
2017 — IFC4 Add2 TC1	Conjunto de melhorias e correções, associado no manual à Reference View.
2023/2024 — IFC4.3 Add2	Versão com ampliação para infraestrutura e padronização ISO em 2024.

O manual relaciona o IFC4 Add2 TC1 à ISO 16739-1:2018 e registra a padronização ISO do IFC4.3 Add2 em 2024. Essas referências descrevem o contexto da edição utilizada.

O futuro visto em 2024: grafos e gêmeos digitais

Na discussão sobre IFC5 apresentada no manual, Steinmann considera a possibilidade de utilizar bases técnicas mais acessíveis a novos desenvolvedores. Ao mesmo tempo, lembra que a grande quantidade de arquivos STEP existentes exige continuidade de leitura e intercâmbio.

Seu argumento é que melhorias internas, quando pouco perceptíveis para o usuário, oferecem incentivo limitado à migração. Uma empresa precisa investir na nova implementação e continuar suportando arquivos antigos, sem necessariamente gerar um benefício imediato para o cliente.

O autor também discute grafos, estruturas que representam dados por elementos conectados e suas relações. Para um gêmeo digital, isso pode facilitar a ligação entre modelos e informações produzidos para finalidades distintas, em vez de tentar concentrar tudo em um único esquema.

Na visão apresentada, dados IFC poderiam ser aproveitados em bancos de dados de grafos por meio da conversão dos modelos STEP. Essa perspectiva aponta para continuidade e conexão entre informações existentes e futuras.

Essas são reflexões publicadas em 2024, e não uma declaração sobre o estágio atual de desenvolvimento ou a disponibilidade de IFC5.

O que essa história ensina à prática

Como leitura editorial para arquitetos e coordenadores, a trajetória do IFC sugere três cuidados:

1. Defina o uso da informação antes da exportação. O conteúdo necessário para coordenação pode ser diferente daquele destinado a outros usos do modelo.
2. Acorde a versão e a vista de intercâmbio. Dizer apenas “entregar em IFC” deixa indefinidas escolhas que influenciam a compatibilidade e o conteúdo da entrega.
3. Verifique uma troca real entre as ferramentas da equipe. A existência de um padrão comum precisa ser acompanhada da conferência dos dados efetivamente recebidos.

A contribuição histórica do IFC está na construção de uma base aberta para comunicar objetos, propriedades e relações. Sua evolução mostra que a interoperabilidade envolve tanto a estrutura dos dados quanto as condições de implementação e os processos das equipes.

Fonte e leitura complementar

Fonte principal: BIMcert Handbook: Basic Knowledge openBIM, edição 2024, seção 1.2, “The History of IFC (Industry Foundation Classes)”, por Rasso Steinmann — autor convidado, páginas 23–28 do PDF consultado. Autores do manual: Christoph Carl Eichler, Christian Schranz, Tina Krischmann, Harald Urban, Markus Hopferwieser e Simon Fischer.

Adaptação e síntese editorial em português brasileiro: ARQUITETURA.COM, publicada em 4 de outubro de 2026. O artigo preserva a atribuição do relato e distingue as perspectivas de 2024 das implicações práticas propostas pela redação.

Continue com Fundamentos do openBIM e openBIM na prática: padrões comuns, processos sob medida. Outros conteúdos estão na seção openBIM.