Por que o IFC chega sem código de classificação?

Elemento sem classificação atravessa a entrega mudo.

O projetista modela no software nativo, atribui categoria, preenche parâmetros, até vincula um código de classificação no campo que o template oferece. Exporta o IFC. Do outro lado, o gestor da informação abre o arquivo no viewer, seleciona um elemento qualquer e procura a classificação embarcada. Não há IfcClassificationReference. O código que existia no nativo morreu na exportação — ou nunca foi mapeado para o schema IFC.

A consequência é silenciosa e devastadora: o elemento chega ao modelo federado sem identidade classificatória. Não diz a que sistema pertence, não carrega código NBR 15965, não aponta para SINAPI, não referencia Uniclass nem OmniClass. Para o IFC, aquele elemento é uma parede — mas não é uma parede de vedação externa com código 2E.20.10.10 da NBR 15965. É uma parede genérica, sem vocabulário, sem rastreabilidade, sem interoperabilidade com nenhum sistema downstream — nem orçamento, nem medição, nem operação.

A entidade canônica que resolve esse problema é a IfcClassificationReference (ISO 16739-1:2024, IFC4x3): referência para um sistema ou fonte de classificação para uma chave específica. Três atributos definem a âncora:

• Identification — a chave do código no sistema de classificação (ex.: 2E.20.10.10).
• Name — designação legível (ex.: "Parede de vedação externa").
• Location — URI que aponta para a fonte canônica do código (ex.: URI bSDD ou URL do sistema).

Cada IfcClassificationReference aponta para uma IfcClassification — o sistema de classificação propriamente dito (NBR 15965, SINAPI, Uniclass, OmniClass). IfcClassification declara o nome do sistema, a edição, a data de publicação e, quando disponível, o URI de referência. A relação é direta: IfcClassificationReference.ReferencedSource aponta para a IfcClassification do projeto.

A dor não é "o modelo não tem classificação". É que a exportação IFC não embarcou a classificação que existia no nativo — ou que o nativo nunca a teve em formato mapeável. A ausência de classificação no orçamento como documento de custo é tema da dor sobre orçamento sem classificação no 5D. Aqui a dor está na camada anterior: o container IFC que deveria carregar a classificação do elemento até o orçamento, até a medição, até a operação — chega vazio. Sem IfcClassificationReference no IFC, nenhum uso downstream consegue rastrear o elemento ao seu código de classificação. A informação morre na fronteira da exportação.

1. 1

   Elemento sem IfcClassificationReference no viewer · o gestor seleciona o elemento no viewer IFC e não encontra nenhuma referência de classificação embarcada — o campo simplesmente não existe.

2. 2

   Código de classificação vive em planilha paralela · a amarração elemento-código existe, mas fora do IFC — em Excel, em banco de dados do software de orçamentação, na cabeça do orçamentista.

3. 3

   Extração de quantitativo sem classificação · o software de 5D importa o IFC e pede classificação para agrupar; como não há IfcClassificationReference, o agrupamento é manual ou impossível.

4. 4

   Dashboard de conformidade mostra classificação em 0% · a regra IDS exige Classification facet e 100% dos elementos falham — nenhum carrega IfcClassificationReference.

5. 5

   Classificação no nativo mas ausente no IFC · o projetista jura que atribuiu classificação no Revit/ArchiCAD/Tekla. Abre o nativo, está lá. Abre o IFC, sumiu. O mapeamento de exportação não cobriu.

6. 6

   BEP silencia sobre sistema de classificação canônico · o BEP não declara qual sistema de classificação é obrigatório (NBR 15965, SINAPI, Uniclass). Cada disciplina decide por conta — ou não classifica.

7. 7

   Operação não consegue vincular custo de manutenção ao elemento original · facilities precisa rastrear o componente ao código de custo. Sem IfcClassificationReference, o handover entrega geometria sem identidade.

8. 8

   Modelo federado com disciplinas usando classificações diferentes · arquitetura usa Uniclass, estrutura não classifica, MEP usa código interno proprietário. Nenhuma consulta cross-disciplina funciona.

1. 1

   EIR não exige classificação embarcada no IFC · a a ABNT NBR ISO 19650-2:2022 exige declarar formas de estruturação e classificação da informação no padrão de informação do projeto. Se o EIR silencia sobre IfcClassificationReference, ninguém embarca.

2. 2

   Mapeamento de exportação não cobre classificação · o tradutor IFC do software (Revit, ArchiCAD, Tekla) tem configuração de mapeamento para classificação, mas o default de fábrica frequentemente não exporta IfcClassificationReference — precisa de configuração explícita.

3. 3

   Parâmetro de classificação no nativo sem vínculo IFC · o projetista preenche um campo chamado "Classificação" ou "Código SINAPI" no nativo, mas esse campo é parâmetro de texto livre, não mapeado para IfcClassificationReference no export.

4. 4

   Confusão entre classificação e descrição · o projetista descreve o elemento ("parede de vedação externa em bloco cerâmico") e acredita que isso é classificação. Não é. Classificação é código estruturado num sistema normativo — NBR 15965, Uniclass, OmniClass — com IfcClassification declarada.

5. 5

   Ausência de IfcClassification no projeto IFC · mesmo quando o projetista tenta exportar classificação, se nenhuma IfcClassification foi declarada no projeto IFC (sistema, edição, data, URI), as IfcClassificationReference ficam órfãs — sem ReferencedSource.

6. 6

   Cultura de "classificação é problema do orçamentista" · a organização trata classificação como atividade de custo, não como atributo do modelo. O modelador não classifica porque "isso é responsabilidade de quem orça".

1. 1

   Rastreabilidade modelo-orçamento quebrada · sem IfcClassificationReference, o software de 5D não consegue vincular elemento a composição de custo automaticamente. A amarração vira manual, frágil e não replicável.

2. 2

   Medição mensal sem rastreio ao modelo · o boletim de medição deveria rastrear ao elemento do IFC via código de classificação. Sem código embarcado, a conciliação depende de planilha paralela — divergência vira disputa.

3. 3

   Auditoria IDS reprova 100% dos elementos · se o EIR exige classificação e o IDS tem Classification facet, todo elemento sem IfcClassificationReference falha. Entrega recusada.

4. 4

   Handover sem identidade classificatória · o modelo que chega à operação não carrega código para vincular ao CMMS/CAFM. Facilities recebe geometria sem rastreabilidade — o dado de custo e manutenção morre no handover.

5. 5

   Benchmarking corporativo impossível · sem classificação consistente entre projetos, a organização não consegue comparar custo unitário, produtividade nem performance entre obras.

6. 6

   Obra pública com fiscalização rejeita entrega · fiscalização exige rastreabilidade do quantitativo ao modelo com código SINAPI auditável. Sem IfcClassificationReference, a rastreabilidade não se demonstra.

Gravidade 3-4. Ausência de classificação embarcada é problema silencioso: o IFC abre, a geometria aparece, o clash detection roda, o viewer renderiza. O dano aparece quando alguém precisa usar a informação classificatória — agrupar para orçamento, filtrar para medição, rastrear para operação — e descobre que o elemento não diz a que sistema pertence. Gravidade 3 quando o projeto está no início e há tempo para configurar o mapeamento de exportação. Gravidade 4 quando centenas de elementos já foram entregues sem classificação e a re-exportação retroativa é cara, propensa a erro e politicamente difícil.

Todos os testes podem ser executados pelo gestor da informação, pelo BIM Manager ou pelo orçamentista. Baseiam-se na ISO 16739-1:2024 (IfcClassificationReference), na ABNT NBR ISO 19650-2:2022 e na buildingSMART IDS (ISO 29481-3).

O problema é considerado resolvido quando todos os itens abaixo forem verdadeiros, em aderência à ISO 16739-1:2024, ABNT NBR ISO 19650-2:2022 e buildingSMART IDS (ISO 29481-3):

Curto prazo (30-45 dias — embarcar classificação no IFC atual):

1. Declarar o sistema de classificação canônico do projeto. NBR 15965 como sistema estrutural, com cross-reference a SINAPI/TCPO para composições de preço. Formalizar no BEP, conforme os padrões de informação do projeto da ABNT NBR ISO 19650-2:2022.

2. Configurar o mapeamento de exportação. Em cada software de autoria (Revit, ArchiCAD, Tekla, Allplan), configurar o tradutor IFC para que o parâmetro de classificação do nativo exporte como IfcClassificationReference — com IfcClassification declarada no projeto (Name, Edition, Location).

3. Classificar os elementos-chave. Começar pelos que representam maior fração do custo ou maior criticidade operacional. Atribuir código NBR 15965 (ou SINAPI quando pertinente) no nativo, verificar que exporta como IfcClassificationReference no IFC.

4. Rodar IDS com Classification facet. Verificar taxa de conformidade. Documentar baseline. Comunicar às disciplinas que a partir do próximo marco, classificação embarcada é requisito de aceite.

Médio prazo (60-120 dias — institucionalizar):

5. Expandir classificação para todos os elementos. Cobrir 100% dos elementos exigidos pelo EIR. Priorizar por disciplina e por tipologia.

6. Padronizar biblioteca corporativa com classificação embarcada. Famílias-padrão já vêm com código NBR 15965 e SINAPI pré-configurados. Modelador novo usa família calibrada — não reinventa.

7. Integrar classificação ao fluxo operacional. Na transição para operação, o código de classificação acompanha o ativo via IfcClassificationReference — facilities rastreia custo de manutenção ao item orçado original.

1. 1

   EIR exige IfcClassificationReference como requisito de entrega · todo EIR inclui o padrão de informação do projeto operacionalizado: sistema de classificação canônico declarado, IfcClassificationReference exigida em cada elemento, IfcClassification com Name/Edition/Location obrigatória no projeto IFC.

2. 2

   Mapeamento de exportação configurado no kickoff · o preset de exportação IFC de cada disciplina é configurado e testado para classificação antes da modelagem avançar — não na véspera da entrega.

3. 3

   IDS com Classification facet no repositório do projeto · a IDS do projeto contém Classification facet que verifica IfcClassificationReference em cada rodada de aceite. Elemento sem classificação falha automaticamente.

4. 4

   Biblioteca corporativa pré-classificada · famílias-padrão da organização vêm com código NBR 15965 e SINAPI pré-configurados e mapeados para IfcClassificationReference. Investimento único, retorno multiplicativo.

5. 5

   Classificação embarcada desde a modelagem · cada elemento do modelo nasce com código de classificação. Não é adicionado retroativamente — é requisito da família, verificado a cada export.

6. 6

   Cross-reference com orçamento via código compartilhado · o código de classificação embarcado no IFC é o mesmo que aparece no orçamento e na medição. A ponte modelo-custo é o IfcClassificationReference, não a planilha paralela.

• ISO 16739-1:2024 (IFC4x3)Industry Foundation Classes (IFC). Define IfcClassificationReference (referência para um sistema de classificação com Identification, Name e Location) e IfcClassification (o sistema propriamente dito com Name, Edition, Location). A ponte técnica entre o sistema de classificação normativo e o container BIM.
• ABNT NBR ISO 19650-2:2022Fase de entrega. Os padrões de informação do projeto exigem declarar formas de estruturação e classificação da informação. A §5.6.3 exige verificação da garantia da qualidade antes da troca — inclui conferir que o IFC carrega a classificação contratual.
• buildingSMART IDS (ISO 29481-3)Information Delivery Specification — regras verificáveis sobre o IFC. A Classification facet exige IfcClassificationReference com sistema e código declarados. Permite auditoria automatizada de classificação embarcada.
• ABNT NBR 15965-1:2011Sistema de classificação da informação da construção — Parte 1: Terminologia e estrutura. Norma canônica brasileira de classificação. Define código estruturado (Tabela.Nivel1...Nivel6) que deve embarcar como Identification no IfcClassificationReference.
• ABNT NBR ISO 12006-2:2018Framework para classificação. Base normativa internacional sobre a qual a NBR 15965 é estruturada. Referenciada pela §5.1.7 da ABNT NBR ISO 19650-2:2022.
• buildingSMART bSDDServiço público (bsdd.buildingsmart.org) que hospeda classificações com URI persistente. IfcClassificationReference.Location pode apontar para URI bSDD, garantindo vocabulário canônico cross-projeto e rastreabilidade por referência.
• ABNT NBR ISO 19650-1:2022Conceitos e princípios. Estabelece Employer Information Requirements (EIR) e o Common Data Environment (CDE) como base contratual e ambiente de gestão da informação ao longo do ciclo de vida.