Por que tratar o IFC como dado, não como PDF 3D?

"Exporta o IFC, manda pro coordenador, segue a vida." Essa frase resume como a maioria das equipes trata o IFC: como um PDF 3D — um arquivo estático que se gera no final, se entrega por obrigação e se visualiza passivamente. O receptor abre, gira, faz um clash detection geométrico e arquiva. Ninguém consulta, ninguém filtra, ninguém extrai, ninguém verifica propriedade nenhuma. O IFC vira figura tridimensional que ninguém lê.

Esse uso desperdiça o que o IFC realmente é: um contêiner de dados estruturado. O esquema IFC (ISO 16739-1:2024, IFC4x3) não foi desenhado para gerar imagens bonitas — foi desenhado para representar um ativo construído como banco de dados semântico: entidades tipadas (IfcWall, IfcSpace, IfcDistributionElement), relações explícitas (composição via IfcRelAggregates, contenção via IfcRelContainedInSpatialStructure, conectividade via IfcRelConnectsElements), propriedades normalizadas em Property Sets padronizados (Pset_WallCommon, Pset_SpaceCommon), classificação embarcada via IfcClassificationReference e quantitativos nativos via IfcElementQuantity. Cada elemento é um registro com geometria, propriedades e relações — não um sólido 3D com textura.

A distinção entre "IFC como PDF 3D" e "IFC como dado" é a fronteira que separa BIM visual de BIM operacional. Quando o IFC é tratado como imagem, o modelo serve para uma coisa: olhar. Quando tratado como dado, o modelo serve para coordenar, quantificar, verificar, auditar e operar. A diferença não é filosófica — é operacional e mensurável.

O conceito de IFC como formato e a distinção entre openBIM e closedBIM são temas das respectivas dores nos fundamentos do BIM. Esta página ataca o mau uso: a equipe até sabe que IFC existe, até exporta — mas trata o arquivo como artefato de visualização, não como contêiner de dados. E com isso perde o valor que justifica todo o ecossistema openBIM.

O IFC como contêiner de dados é peça central da cadeia openBIM buildingSMART: o modelo IFC carrega os dados; o IDS (buildingSMART IDS, ISO 29481-3) verifica se os dados estão conformes; o bSDD (buildingSMART Data Dictionary) fornece vocabulário canônico para propriedades e classificações; o BCF (BIM Collaboration Format) ancora issues de coordenação nos elementos do modelo via GUID. Sem tratar o IFC como dado, nenhum desses padrões funciona — porque todos operam sobre a informação semântica do modelo, não sobre a geometria.

A ABNT NBR ISO 19650-1:2022 define information container (§3.3.12) como "conjunto nomeado e persistente de informação recuperável de dentro de uma hierarquia de armazenamento de arquivos". O IFC é, por definição e por design, um information container. Tratá-lo como PDF 3D é usar um banco de dados como pôster.

1. 1

   IFC aberto apenas para visualização · a equipe abre o IFC no viewer, gira o modelo, tira screenshot e fecha. Ninguém seleciona elemento para consultar propriedade, ninguém filtra por tipo, ninguém extrai quantitativo.

2. 2

   Clash detection puramente geométrico · o modelo federado é usado apenas para detectar colisões visuais entre sólidos. Nenhuma verificação semântica (propriedade, classificação, relação) é feita sobre os dados do IFC.

3. 3

   Propriedades preenchidas que ninguém consulta · o projetista preenche Property Sets no modelo nativo, exporta para IFC, e do outro lado ninguém verifica se a informação chegou nem a utiliza para decisão.

4. 4

   Quantitativo extraído de planilha paralela · a equipe levanta quantitativos no Excel ou no software de orçamentação, não a partir do IfcElementQuantity embarcado no IFC. O modelo e o quantitativo vivem separados.

5. 5

   IFC entregue como obrigação contratual, não como ferramenta · a organização gera IFC porque o contrato exige, arquiva e nunca mais abre. O IFC cumpre cláusula, não cumpre função.

6. 6

   Ninguém sabe o que é IDS, bSDD ou BCF na equipe · o ecossistema openBIM buildingSMART que opera sobre os dados do IFC é desconhecido. A equipe conhece o arquivo mas não conhece os padrões que dão utilidade ao conteúdo.

7. 7

   Modelo entregue para operação sem uso downstream · o as-built IFC chega a facilities e morre em pasta. Nenhum sistema de gestão de ativos consome os dados do modelo — porque ninguém preparou o IFC para ser consumido como dado.

8. 8

   Verificação de qualidade visual, não semântica · a conferência do IFC é feita por inspeção visual: geometria razoável, modelo não explodiu, elementos parecem no lugar. Nenhuma regra automatizada verifica se os Property Sets, classificações e relações estão conformes.

1. 1

   Formação em software, não em schema · os cursos comerciais ensinam Revit, ArchiCAD, Tekla — ensinam a modelar e apertar o botão de exportar IFC. Não ensinam o esquema semântico (ISO 16739-1) nem os padrões que operam sobre ele (IDS, bSDD, BCF). O profissional sabe gerar o arquivo mas não sabe o que o arquivo carrega.

2. 2

   Viewer usado como ferramenta final · o viewer BIM (Solibri, BIMcollab ZOOM, Navisworks) é tratado como ponto de chegada: abrir e olhar. Deveria ser ponto de partida: abrir, consultar, filtrar, verificar, extrair. A ferramenta suporta os dois usos — a cultura só pratica o primeiro.

3. 3

   Ausência de EIR que exija uso dos dados · o contrato pede IFC mas não especifica quais dados devem estar embarcados, em quais Property Sets, com qual classificação, para qual uso downstream. Sem requisito de dado, o IFC nasce como geometria empacotada.

4. 4

   Ecossistema openBIM buildingSMART desconhecido · IDS, bSDD e BCF são padrões maduros e operacionais — mas desconhecidos pela maioria das equipes. Sem conhecer os padrões que consomem os dados do IFC, não há motivo percebido para embarcar dados no IFC.

5. 5

   Cultura de coordenação visual · coordenação BIM praticada como atividade visual: abrir modelo federado, rodar clash detection geométrico, registrar colisões em screenshot. A coordenação semântica (verificar dados, auditar propriedades, checar classificação) não é sequer cogitada.

6. 6

   Formato nativo como fonte, IFC como subproduto · o modelo nativo (.rvt, .pln, .ifc nativo) é tratado como a fonte verdadeira; o IFC exportado é tratado como cópia descartável. Consequência: ninguém investe em qualidade de exportação porque o IFC não é o dado de referência.

1. 1

   Investimento em modelagem sem retorno downstream · a equipe preenche propriedades, classifica elementos, modela relações — e tudo morre no IFC que ninguém lê. O custo de modelagem detalhada não se converte em valor para coordenação, orçamento nem operação.

2. 2

   Verificação automatizada impossível · sem dados embarcados ou com dados não estruturados, não há como rodar IDS de verificação. A conformidade depende de conferência visual — cara, lenta e falível.

3. 3

   Handover para operação fracassa · o modelo as-built chega a facilities como geometria 3D sem dados exploráveis. Nenhum sistema CMMS/CAFM consegue importar informação útil do IFC — o handover digital vira handover de imagem.

4. 4

   Quantitativo não rastreável ao modelo · se o quantitativo não vem do IfcElementQuantity embarcado no IFC, a rastreabilidade modelo-orçamento depende de planilha paralela. Divergência gera disputa contratual sem evidência auditável.

5. 5

   Coordenação limitada a geometria · tratar o IFC como PDF 3D limita a coordenação a clash detection geométrico. Verificação de dados (propriedade preenchida, classificação correta, relação coerente) fica fora do processo.

6. 6

   Dependência de formato proprietário perpetuada · quando o IFC é tratado como subproduto descartável, o dado real fica no formato nativo proprietário. A organização mantém dependência de vendor sem perceber — exatamente o oposto do que o openBIM promete.

Gravidade 2-3. Tratar o IFC como PDF 3D não gera erro visível imediato — o modelo abre, a geometria aparece, o clash detection roda. O dano é silencioso: toda a informação semântica embarcada fica inacessível, e o retorno do investimento em modelagem detalhada se perde. Gravidade 2 quando a organização está no início da jornada BIM e ainda não tem usos downstream que dependam dos dados do IFC. Gravidade 3 quando já contratou coordenação BIM, exige conformidade com EIR, opera handover para facilities ou precisa de rastreabilidade modelo-orçamento — e mesmo assim trata o IFC como imagem.

Todos os testes podem ser executados pelo gestor da informação, pelo BIM Manager ou pelo coordenador BIM sobre um IFC real de projeto ativo.

O problema é considerado resolvido quando todos os itens abaixo forem verdadeiros, em aderência à ISO 16739-1:2024, ABNT NBR ISO 19650 e ecossistema openBIM buildingSMART:

Curto prazo (30-45 dias — mudar a postura de uso):

1. Demonstrar o IFC como dado ao vivo. Sessão de 2 horas com a equipe usando um IFC real do projeto: selecionar elementos, consultar Property Sets, filtrar por classificação, extrair quantitativos, rodar uma IDS mínima. Mostrar que o arquivo que a equipe trata como imagem é um banco de dados consultável.

2. Rodar a primeira IDS do projeto. Criar uma IDS mínima (buildingSMART IDS, ISO 29481-3) com 3-5 regras de Property facet sobre os elementos mais críticos. Executar contra o IFC atual. O resultado quantifica o que falta para o IFC ser dado, não imagem.

3. Substituir uma planilha paralela por extração do IFC. Escolher um levantamento de quantitativos que hoje vem de planilha. Extrair o mesmo dado do IfcElementQuantity do IFC. Comparar. O exercício demonstra concretamente o valor do IFC como dado — ou expõe que o IFC não carrega o quantitativo, motivando correção na exportação.

4. Incluir consulta de dados no workflow de recebimento. Ao receber IFC de uma disciplina, o receptor não apenas visualiza — verifica amostragem de Property Sets, classificação e quantitativos. Checklist de 5 minutos que transforma o recebimento passivo em recebimento ativo.

Médio prazo (60-120 dias — institucionalizar o uso como dado):

5. Reescrever o EIR com requisitos de dados. Substituir "entregar em IFC" por especificação de conteúdo: quais Property Sets devem estar preenchidos, qual sistema de classificação embarcado, quais quantitativos calculados, qual IDS de verificação. Conforme os padrões de informação do projeto da ABNT NBR ISO 19650-2:2022.

6. Integrar IDS ao ciclo de aceite do CDE. A transição de WIP para Shared (ABNT NBR ISO 19650-1:2022, Seção 12) passa a exigir aprovação de IDS automatizada — modelo com dados faltantes não transita de estado. Verificação semântica vira gate, não sugestão.

7. Capacitar a equipe nos padrões openBIM buildingSMART. Workshop que cobre: IDS (verificação de dados), bSDD (vocabulário canônico de propriedades e classificações), BCF (coordenação ancorada em dados do modelo). A equipe passa a operar o ecossistema que dá utilidade aos dados do IFC.

8. Preparar o IFC para uso downstream. Para projetos com handover para operação: configurar a exportação para que o IFC carregue todos os dados que o CMMS/CAFM precisa importar. Testar a importação antes do as-built — não depois.

1. 1

   Formação em schema antes de formação em botão · todo profissional que exporta IFC entende as entidades semanticas (IfcProduct, IfcPropertySet, IfcClassificationReference, IfcElementQuantity) antes de aprender o menu de exportação do software.

2. 2

   EIR com requisito de conteudo · todo EIR especifica quais dados devem estar embarcados no IFC (Property Sets, classificação, quantitativos), com IDS de verificação anexa. Requisito de formato sem requisito de conteúdo é convite ao IFC vazio.

3. 3

   IDS como gate no CDE · nenhum IFC transita de WIP para Shared sem passar por IDS automatizada. Verificação semântica é pre-condição de aceite, não atividade opcional.

4. 4

   Ecossistema openBIM operacional · a equipe opera com IDS (verificação), bSDD (vocabulário) e BCF (coordenação) sobre os dados do IFC. O IFC é peça central de um ecossistema, não arquivo isolado.

5. 5

   Quantitativos extraídos do modelo · o IfcElementQuantity embarcado no IFC é a fonte preferencial de quantitativos. Planilha paralela existe como conferência, não como fonte.

6. 6

   Recebimento ativo de IFC · ao receber IFC, o receptor consulta dados (propriedades, classificação, quantitativos) antes de aceitar. Receber IFC sem verificar dados é aceitar embalagem sem conferir conteúdo.

• ISO 16739-1:2024 (IFC4x3)Industry Foundation Classes (IFC). Define o esquema semântico completo: entidades tipadas (IfcWall, IfcSpace, IfcDistributionElement), relações (IfcRelAggregates, IfcRelContainedInSpatialStructure, IfcRelConnectsElements), Property Sets padronizados (Pset_WallCommon, Pset_SpaceCommon), classificação (IfcClassificationReference) e quantitativos (IfcElementQuantity). O IFC foi desenhado como contêiner de dados semântico, não como formato de visualização.
• ABNT NBR ISO 19650-1:2022Conceitos e princípios. §3.3.12 define information container como conjunto nomeado e persistente de informação. Seção 12 define o CDE e seus estados (WIP/Shared/Published/Archived). O IFC como information container deve ser tratado com a disciplina que a norma exige — dado gerido, não arquivo descartável.
• ABNT NBR ISO 19650-2:2022Fase de entrega. §5.1.4 exige que o EIR declare padrões de informação — inclui especificar quais dados o IFC deve carregar. §5.6.3 exige verificação da garantia da qualidade — inclui checar dados embarcados, não só geometria.
• buildingSMART IDS (ISO 29481-3)Information Delivery Specification. Regras verificáveis por rule engine sobre o conteúdo do IFC: Property facet, Classification facet, Material facet. A ferramenta que transforma o IFC de arquivo visual em contêiner auditável.
• buildingSMART bSDDbuildingSMART Data Dictionary (bsdd.buildingsmart.org). Vocabulário canônico de propriedades e classificações com URI persistente. Garante que os dados embarcados no IFC usem terminologia interoperável entre projetos, organizações e países.
• buildingSMART BCFBIM Collaboration Format. Padrão de coordenação que ancora issues de revisão nos elementos do modelo IFC via IfcGuid. Opera sobre os dados do IFC — sem dados embarcados, o BCF vira apontador de geometria sem contexto semântico.