IFC2x3, IFC4 ou IFC4x3: qual usar?

Exportar na versão errada quebra a conversa antes de começar.

O IFC não é um formato único — é uma família de schemas publicada como norma ISO. A versão vigente é a ISO 16739-1:2024 (IFC4x3). Antes dela vieram IFC4 (2013, revisada em 2016) e IFC2x3 (2006), que ainda domina a maioria dos projetos em produção no Brasil e no mundo. Cada versão amplia o schema: novas entidades, novos Property Sets, novas representações geométricas, novos domínios (infraestrutura, por exemplo, só existe a partir do IFC4x3). As versões não são plenamente compatíveis entre si — um arquivo IFC4x3 não abre sem perdas em software que só lê IFC2x3, e um arquivo IFC2x3 não carrega entidades que só existem no IFC4x3.

O problema aparece quando disciplinas diferentes de um mesmo projeto exportam em versões diferentes do schema. Arquitetura manda IFC2x3 porque o template é antigo. Estrutura manda IFC4 porque o software atualizou. MEP manda IFC4x3 porque o coordenador pediu. O federador recebe três arquivos que, embora todos tenham extensão .ifc, falam dialetos diferentes do mesmo idioma. O viewer pode abrir todos, mas a coordenação semântica — filtro por entidade, verificação por IDS, extração de propriedade — falha silenciosamente porque as entidades e propriedades não se correspondem entre versões.

A confusão de mercado agrava: muitos profissionais tratam IFC2x3, IFC4 e IFC4x3 como se fossem a mesma coisa com nome diferente. Não são. IFC2x3 é legado amplamente usado, IFC4 é intermediário com adoções pontuais, e IFC4x3 é a versão vigente na norma ISO — a única que cobre edificação e infraestrutura sob o mesmo schema. Escolher a versão não é detalhe de configuração; é decisão contratual que deve estar no BEP antes de qualquer exportação.

1. 1

   Viewer rejeita ou abre com avisos · o software de visualização reporta "schema não suportado", "entidade desconhecida" ou abre o arquivo com elementos faltando — sinal de que a versão exportada não é compatível com o leitor.

2. 2

   Propriedade que deveria existir não aparece · o IFC4x3 tem Property Sets e entidades que não existem no IFC2x3. Se o receptor espera dados de IFC4x3 e recebe IFC2x3, campos ficam vazios ou ausentes.

3. 3

   Verificação IDS falha sem motivo aparente · a regra IDS foi escrita para entidades do IFC4x3, mas o arquivo entregue é IFC2x3 — as entidades referenciadas não existem no schema antigo.

4. 4

   Entidades de infraestrutura ausentes · projeto de infraestrutura exportado em IFC2x3 não carrega IfcRoad, IfcBridge, IfcAlignment — entidades que só existem a partir do IFC4x3.

5. 5

   Cada disciplina informa versão diferente · ao inspecionar o cabeçalho FILE_SCHEMA dos IFCs do projeto, cada arquivo declara schema diferente (IFC2X3, IFC4, IFC4X3).

6. 6

   Conversão manual entre versões · a equipe recorre a ferramentas de conversão para "traduzir" IFC2x3 em IFC4, perdendo propriedades e degradando geometria no processo.

1. 1

   BEP não define versão do schema · o plano de execução BIM não declara qual versão do IFC será usada no projeto. Cada disciplina exporta na versão default do seu software.

2. 2

   Software de autoria com default diferente · Revit pode exportar IFC2x3 por padrão, enquanto ArchiCAD exporta IFC4 e Tekla oferece IFC4x3. Sem acordo, cada disciplina segue o default.

3. 3

   Template herdado de projeto anterior · a equipe reutiliza preset de exportação de um projeto antigo que usava IFC2x3, sem verificar se a versão ainda atende ao contrato atual.

4. 4

   Confusão entre versão do IFC e MVD · o projetista confunde a versão do schema (IFC2x3, IFC4, IFC4x3) com a Model View Definition (Coordination View, Reference View) e acha que selecionar a MVD correta basta.

5. 5

   Contrato sem exigência de versão · o EIR não especifica a versão do schema IFC, e o BEP repete a omissão. A versão vira decisão individual de cada projetista.

6. 6

   Desconhecimento das diferenças entre versões · a equipe trata IFC2x3, IFC4 e IFC4x3 como sinônimos. Não sabe que entidades, Property Sets e domínios diferem entre elas.

1. 1

   Federação com schemas incompatíveis · o viewer abre todos os arquivos, mas a coordenação semântica falha — filtros por entidade retornam resultados parciais porque as entidades diferem entre versões.

2. 2

   Verificação IDS que não funciona · regras IDS escritas para IFC4x3 não encontram as entidades em arquivos IFC2x3. A auditoria ou reprova tudo ou não avalia nada — ambas inúteis.

3. 3

   Perda de informação na conversão · converter IFC2x3 para IFC4 (ou vice-versa) via ferramentas automáticas degrada propriedades, geometria e relações. O que era lossless vira lossy.

4. 4

   Entrega contratual recusada · se o contrato ou o BEP exige IFC4x3 e a disciplina entrega IFC2x3, a entrega pode ser formalmente rejeitada — com impacto em prazo e medição.

5. 5

   Incapacidade de cobrir infraestrutura · projetos de infraestrutura que exportam em IFC2x3 simplesmente não conseguem representar alinhamentos, estradas e pontes — o schema não tem essas entidades.

6. 6

   Retrabalho de re-exportação · descobrir a incompatibilidade de versão na coordenação obriga re-export de todas as disciplinas afetadas, com novo ciclo de upload e verificação.

Curto prazo (30 dias):

1. Definir a versão contratual no BEP. Registrar qual versão do schema IFC será usada por todas as disciplinas do projeto. Justificar a escolha: IFC2x3 se todos os softwares e ferramentas do projeto só suportam essa versão; IFC4x3 se o escopo inclui infraestrutura ou se o contrato exige conformidade com a ISO 16739-1:2024.

2. Auditar os IFCs já entregues. Verificar o FILE_SCHEMA de cada arquivo no CDE. Sinalizar os que divergem da versão contratual e solicitar re-exportação.

3. Configurar o exportador de cada disciplina. Ajustar o software de autoria para exportar na versão definida. Testar com modelo piloto e confirmar que o FILE_SCHEMA bate.

Medio prazo (60-90 dias):

4. Alinhar IDS e verificação à versão. Revisar todas as regras IDS do projeto para que referenciem entidades e Property Sets da versão contratual — não de versão diferente.

5. Documentar procedimento de migração. Se houver necessidade justificada de converter entre versões, documentar o processo, as ferramentas usadas e o procedimento de verificação pós-conversão (checklist de perdas aceitáveis e inaceitáveis).

6. Incluir verificação de versão no aceite do CDE. Toda publicação de IFC no estado Shared passa por conferência automática de FILE_SCHEMA antes de avançar para Published.

1. 1

   Versão do schema no BEP antes de modelar · a escolha entre IFC2x3, IFC4 e IFC4x3 entra no kickoff, junto com a justificativa. Nenhuma disciplina exporta antes do acordo.

2. 2

   EIR com exigência explícita de versão · o documento de requisitos de informação declara a versão do schema e a MVD esperada, eliminando ambiguidade na contratação.

3. 3

   Preset de exportação versionado por schema · o preset de cada disciplina é configurado para a versão contratual, com mapeamento de categorias e propriedades testado para aquele schema.

4. 4

   IDS alinhado à versão · regras de verificação são escritas para a versão do schema em uso — entidades e Property Sets referenciam o que existe naquela versão.

5. 5

   Verificação de FILE_SCHEMA no CDE · o fluxo de aceite inclui checagem automática do cabeçalho antes de aceitar o upload — arquivo com schema errado é bloqueado.

6. 6

   Capacitação sobre diferenças entre versões · a equipe conhece as diferenças entre IFC2x3, IFC4 e IFC4x3 — sabe que não são sinônimos e que a escolha impacta entidades, propriedades e domínios disponíveis.

• ISO 16739-1:2024 (IFC4x3)Industry Foundation Classes (IFC) — versão vigente da norma ISO. Define o schema completo incluindo entidades de edificação e infraestrutura. As versões anteriores (IFC2x3 de 2006, IFC4 de 2013/2016) cobrem subconjuntos menores do domínio.
• ABNT NBR ISO 19650-2:2022Fase de entrega. §5.6.3 exige verificação da garantia da qualidade antes da troca de informação — inclui conferir que o IFC foi exportado na versão do schema acordada no BEP.
• buildingSMART IDS (ISO 29481-3)Information Delivery Specification. Regras verificáveis sobre o IFC que devem referenciar entidades e Property Sets da versão do schema em uso, sob risco de falha silenciosa.
• ABNT NBR ISO 19650-1:2022Conceitos e princípios. A definição do formato e da versão de troca é parte do acordo de informação entre as partes — versão errada compromete a interoperabilidade acordada.
• buildingSMART · MVD (Model View Definition)Subconjunto do schema IFC para um propósito de troca. A MVD deve ser compatível com a versão do schema: Coordination View serve IFC2x3, Reference View serve IFC4 e IFC4x3.