Validação · 2026-06-28 · 20 min

Verificador de modelos IFC: o guia completo de validação IFC, qualidade de modelo e IDS

Q: Quais facetas do IDS devo priorizar em uma entrega BIM padrão?

A faceta Property cobre de 70% a 80% dos requisitos de informação (EIR) do mundo real — a maioria dos clientes quer valores específicos de Pset em tipos específicos de elemento. A Classification cobre a maior parte do restante em projetos regidos por Uniclass ou OmniClass. A faceta Entity aparece em quase toda especificação como filtro de aplicabilidade. Comece com Entity + Property e adicione Classification se o seu EIR exigir.

Guia do verificador de modelos IFC: schema, qualidade do modelo (44 regras + Health Score) e IDS são três camadas independentes. Confundi-las causa falhas na entrega. Explicação completa para coordenadores BIM.

Verificador de modelos IFC: o guia completo de validação IFC, qualidade de modelo e IDS — IFC Viewer Online article cover

3 — camadas de validação independentes
44 — regras de qualidade de modelo
6 — facetas do IDS (buildingSMART 1.0)
0 — bytes enviados — só no navegador

Toda conversa sobre entrega de IFC acaba esbarrando na mesma parede. O engenheiro estrutural diz que o arquivo passou no validador. O coordenador BIM vê metade dos conjuntos de propriedades faltando e pergunta qual validador. O EIR (requisitos de informação) do cliente especifica requisitos de IDS que ninguém verificou. O CDE (ambiente comum de dados) rejeita o upload. Três semanas depois, todo mundo está confuso sobre o que “válido” realmente significa.

A confusão é compreensível — a palavra “validação” cobre três operações completamente diferentes que compartilham o mesmo nome. Desembaraçá-las é uma das coisas mais importantes que um coordenador BIM pode fazer por um projeto.

Três problemas de validação completamente diferentes

Pense em um pedido de licença de construção. O fiscal de obras verifica três coisas de forma independente: se os desenhos são legíveis e completos (integridade do arquivo), se o projeto atende às normas de construção (qualidade e conformidade) e se atende ao programa específico do cliente (requisitos do projeto). Um desenho legível pode ignorar completamente as normas de incêndio. Um projeto conforme às normas de incêndio pode não atender em nada à especificação acústica do cliente. São perguntas separadas, com respostas separadas.

Nível 1 — Integridade IFC

O arquivo é um IFC válido segundo a ISO 10303-21 e a ISO 16739-1? Os GlobalIds são únicos e estão no formato correto? A hierarquia espacial é coerente? Verificação binária no nível do schema.

Nível 2 — Qualidade do modelo

Os dados são realmente úteis para a coordenação? Os conjuntos de propriedades estão preenchidos? Os elementos seguem convenções de nomenclatura? Há classificações presentes? É isso que rege as entregas reais — não a conformidade com o schema.

Nível 3 — Validação IDS

O modelo satisfaz os requisitos de informação contratuais deste projeto? Requisitos de EIR e AIR codificados como especificações IDS legíveis por máquina, verificados faceta por faceta em cada elemento.

Essas três camadas são completamente independentes. Um arquivo pode ser válido em termos de schema no Nível 1 e ainda assim ser inútil para a coordenação, porque nenhum conjunto de propriedades foi exportado. Uma verificação de IDS pode aprovar todos os requisitos declarados enquanto o modelo tem 400 GUIDs duplicados. Um Health Score de 91 não diz nada sobre se os requisitos de resistência ao fogo do cliente estão codificados e atendidos. Cada camada responde a uma pergunta diferente — as três são necessárias antes de uma entrega formal.

Nível 1: integridade do arquivo IFC — isso é um IFC válido?

O Nível 1 é a verificação de schema. Ele responde a uma pergunta binária: este arquivo está em conformidade com o schema IFC (ISO 16739-1) e com o formato físico do arquivo (ISO 10303-21 STEP)? A maioria dos parsers de IFC aceita silenciosamente arquivos que falham nas verificações do Nível 1 — eles são permissivos por design, porque uma rejeição rígida quebraria workflows demais. Essa permissividade esconde o dano até que ele apareça mais adiante no processo.

O que a verificação de integridade do Nível 1 cobre

Unicidade do GlobalId: toda entidade IfcRoot precisa ter um GlobalId único de 22 caracteres, usando o alfabeto base-64 do IFC. GlobalIds duplicados são uma violação de schema que os parsers aceitam, mas que corrompem silenciosamente os workflows de BCF, o versionamento no CDE e os registros de ativos de FM.
Conformidade de formato do GlobalId: o primeiro caractere de um GlobalId IFC válido codifica apenas os valores de 0 a 3 (dois bits significativos de um UUID de 128 bits). Scripts que truncam UUIDs de forma ingênua produzem caracteres iniciais fora do intervalo válido — inválido segundo a especificação, tolerado pela maioria dos parsers, rejeitado por validadores rígidos.
Completude da hierarquia espacial: o schema IFC exige IfcProject → IfcSite → IfcBuilding → IfcBuildingStorey. Nós ausentes (um Building diretamente sob o Project, elementos físicos posicionados no IfcSite) são violações de schema com consequências reais mais adiante no processo.
Integridade da cadeia de IfcRelAggregates: as entidades de relacionamento que constroem a árvore espacial precisam referenciar entidades existentes. Referências soltas — quando um relacionamento aponta para uma entidade excluída ou ausente — quebram a navegação na árvore em todas as ferramentas seguintes.
IfcRelContainedInSpatialStructure: elementos físicos precisam estar contidos em um elemento espacial (normalmente um IfcBuildingStorey). Elementos sem relação de contenção são órfãos — invisíveis na navegação espacial da maioria das ferramentas.
Exatamente um IfcProject: todo arquivo IFC válido precisa conter exatamente um IfcProject como raiz da hierarquia. Submodelos que o omitem são processados sem erro, mas não têm âncora espacial.
Campos de cabeçalho FILE_NAME e FILE_DESCRIPTION: o cabeçalho do arquivo STEP carrega metadados de rastreabilidade. A ISO 19650-2 exige que sejam preenchidos — a maioria das ferramentas os deixa como strings vazias.
Validade da geometria: malhas não manifold, faces com área zero, corpos com orientação de normais invertida, representações de contorno autointersectantes que falham ao gerar sólidos válidos nas ferramentas de destino.

O que o Nível 1 NÃO verifica

Se os conjuntos de propriedades estão preenchidos ou corretos — um modelo válido em termos de schema com zero Psets passa no Nível 1.
Se os nomes dos elementos seguem alguma convenção de nomenclatura do projeto.
Se os códigos de classificação estão presentes, corretos ou consistentes.
Se os requisitos de quantidades por LOD (IfcElementQuantity em LOD 300+) estão satisfeitos.
Se o modelo atende a qualquer requisito de informação específico do projeto ou contratual.

O buildingSMART Validation Service para o Nível 1

O buildingSMART IFC Validation Service (validate.buildingsmart.org) é a referência oficial para conformidade de schema no Nível 1 — ele usa o mesmo motor empregado na certificação de softwares IFC. Use-o quando: precisar certificar a saída IFC de um exportador personalizado, estiver investigando um arquivo que os parsers tratam de forma inconsistente, ou quando uma cláusula contratual exigir explicitamente um certificado de schema buildingSMART.

O que ele não faz: verificar a qualidade dos dados, validar convenções de nomenclatura, inspecionar a completude dos conjuntos de propriedades, checar campos de metadados da ISO 19650 ou avaliar se o modelo atende a algum requisito do projeto. É uma ferramenta de schema, não um portão de qualidade para a entrega do projeto.

Inspecione um IFC real e complexo — as três camadas de validação

Um edifício de escritórios de vários pavimentos exportado do Revit. Abra a aba Validação para ver o relatório completo das 44 regras de qualidade e o Health Score. Depois, tente carregar uma especificação IDS para ver a verificação do Nível 3 no mesmo modelo.

IFC4 · 14 MB

Abrir o visualizador IFC interativo

Nível 2: verificação de qualidade do modelo — a camada que realmente rege as entregas

A verificação de qualidade do modelo é a camada que a maioria dos coordenadores BIM tem em mente quando fala em “validação de IFC”, mesmo que raramente a chamem por esse nome. Ela responde a perguntas práticas: os dados estão ali? Estão corretos? Estão consistentes? Alguém mais adiante no processo consegue realmente usar esse modelo para coordenação, planejamento de custos ou FM?

Diferente do Nível 1, a verificação de qualidade não é binária. Um modelo não simplesmente passa ou reprova — ele tem um perfil de qualidade em dezenas de dimensões. O Health Score (0–100) agrega essas dimensões em um único número, que pode ser registrado em um BEP (plano de execução BIM), acompanhado ao longo das revisões e anexado às transmittals como evidência da qualidade da entrega.

O que a verificação de qualidade de 44 regras cobre

Regras estruturais essenciais (18)

GUIDs duplicados, elementos órfãos, contenção incorreta, agregações quebradas, IfcProject ausente, nomes de elemento vazios, posicionamento de pavimento inválido. As regras que mais causam rejeições no CDE na prática.

Espacial + cabeçalho do arquivo (11)

Campos de metadados da ISO 19650 no IfcProject, preenchimento de autor e organização em FILE_NAME, posicionamento do terreno versus coordenadas compartilhadas, associação de elemento ao pavimento, completude dos pavimentos do edifício.

LOD, classificação, MEP (9)

Presença de IfcElementQuantity em LOD 300+, IfcRelAssociatesClassification em elementos estruturais e arquitetônicos, conectividade de sistemas de MEP, uso excessivo de proxy (IfcBuildingElementProxy como % do modelo).

Geometria + integridade de pavimento (6)

Validade da caixa delimitadora dos elementos, ordenação das elevações de pavimento, elementos abaixo do plano do terreno, ausência de laje de piso no pavimento, deslocamento da origem das coordenadas em relação ao WCS, detecção de conflitos (clash detection) (regra opcional, desativada por padrão).

O Health Score: a qualidade do modelo em um único número

O Health Score usa uma ponderação de penalidade logarítmica. Erros de schema têm peso 3 vezes maior que os avisos; os avisos têm peso 3 vezes maior que as verificações informativas. A milésima ocorrência do mesmo problema subtrai muito menos pontos que a décima — isso evita que modelos grandes e densos pareçam arbitrariamente piores do que modelos pequenos e esparsos com a mesma densidade de problemas subjacente. Um modelo com 800 avisos de nomenclatura pode ter nota 83; um modelo com 12 referências espaciais quebradas tem nota 41. É a gravidade que determina a nota, não o volume.

31/100 — Crítico — falhas estruturais, não entregar
58/100 — Ruim — exige correção significativa
74/100 — Razoável — aceitável apenas para revisão interna
87/100 — Bom — pronto para entrega no CDE
96/100 — Excelente — qualidade de marco da ISO 19650

O que a verificação de qualidade do modelo NÃO faz

Verificar requisitos de informação específicos do projeto — isso é o Nível 3 (IDS). As regras de qualidade são verificações genéricas de boas práticas, não o seu EIR.
Corrigir o modelo — a verificação de qualidade produz um relatório. A correção acontece no software de autoria ou, para ajustes de propriedade e GUID, em um editor de propriedades IFC.
Fornecer o certificado de conformidade de schema exigido pelos programas de certificação da buildingSMART — isso é o Nível 1, via buildingSMART Validation Service.
Dizer se o modelo está geometricamente correto — algumas verificações de integridade geométrica estão incluídas, mas um verificador de qualidade não é uma ferramenta de detecção de conflitos (clash detection) nem de autoria BIM.

Nível 3: validação IDS — requisitos de troca de informação como código legível por máquina

O IDS (Information Delivery Specification) é um padrão da buildingSMART para codificar requisitos de informação específicos do projeto em um formato XML legível por máquina. É o elo que faltava entre um EIR — que é um documento do Word — e um motor de validação capaz de verificar sistematicamente um modelo em relação a ele. O IDS 1.0 se tornou um padrão oficial da buildingSMART em 2023.

O que o IDS da buildingSMART realmente é

Um arquivo IDS é um documento XML que contém uma ou mais especificações. Cada especificação tem uma seção de aplicabilidade (a quais elementos ela se aplica?) e uma seção de requisitos (o que esses elementos precisam ter?). O motor verifica cada elemento do modelo que corresponde à aplicabilidade, confirma se ele satisfaz todos os requisitos e reporta aprovação ou reprovação por elemento, por especificação. O resultado é uma trilha de auditoria gerada por máquina da conformidade contratual.

O conjunto de testes de referência da buildingSMART contém 100 casos de teste oficiais que definem o comportamento esperado de qualquer motor IDS em conformidade — eles são a especificação em forma executável. Um motor de IDS que passa nos 100 casos de teste demonstrou que vai interpretar as especificações .ids de forma consistente com o padrão.

As seis facetas do IDS

Entity: restringe a aplicabilidade ou os requisitos por tipo de entidade IFC (IFCWALL, IFCDOOR, IFCBEAM) e, opcionalmente, por tipo predefinido. É o filtro pelo qual a maioria das especificações começa.
Attribute: verifica valores de atributo IFC que ficam diretamente na entidade — Name, Description, ObjectType, Tag, PredefinedType. Atributos são diferentes de conjuntos de propriedades e são verificados de outra forma.
Property: verifica uma propriedade nomeada dentro de um conjunto de propriedades nomeado (Pset_WallCommon.FireRating, Pset_DoorCommon.IsExternal). É a faceta mais usada. Suporta restrições de tipo de dado e correspondência de padrões nos valores.
Classification: verifica se os elementos carregam uma referência de classificação via IfcRelAssociatesClassification — Uniclass 2015, OmniClass, NBS ou um esquema personalizado. Pode restringir o nome do sistema de classificação e o padrão do código.
Material: verifica se os elementos têm um material atribuído via IfcMaterial, IfcMaterialLayerSet ou IfcMaterialConstituentSet. Opcionalmente restringe o nome do material — útil para requisitos de resistência ao fogo ou sustentabilidade.
PartOf: verifica se os elementos participam de uma relação espacial ou lógica exigida — contidos em um pavimento, agregados a um sistema do edifício, hospedados em um edifício específico. É a faceta que garante a conformidade da hierarquia espacial para tipos específicos de elemento.

<?xml version="1.0" encoding="UTF-8"?>
<ids:ids xmlns:ids="http://standards.buildingsmart.org/IDS"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://standards.buildingsmart.org/IDS ids_09.xsd">
  <ids:info>
    <ids:title>Stage 3 Architecture — EIR Data Requirements</ids:title>
    <ids:description>Fire safety and classification requirements.</ids:description>
    <ids:ifcVersion>IFC4</ids:ifcVersion>
  </ids:info>
  <ids:specifications>

    <!-- All walls must carry a fire rating property -->
    <ids:specification name="Wall FireRating required" minOccurs="1">
      <ids:applicability>
        <ids:entity>
          <ids:name><ids:simpleValue>IFCWALL</ids:simpleValue></ids:name>
        </ids:entity>
      </ids:applicability>
      <ids:requirements>
        <ids:property dataType="IFCLABEL">
          <ids:propertySet><ids:simpleValue>Pset_WallCommon</ids:simpleValue></ids:propertySet>
          <ids:baseName><ids:simpleValue>FireRating</ids:simpleValue></ids:baseName>
        </ids:property>
      </ids:requirements>
    </ids:specification>

    <!-- Structural walls must carry a Uniclass 2015 classification -->
    <ids:specification name="Structural wall classification" minOccurs="0">
      <ids:applicability>
        <ids:entity>
          <ids:name><ids:simpleValue>IFCWALL</ids:simpleValue></ids:name>
          <ids:predefinedType><ids:simpleValue>SOLIDWALL</ids:simpleValue></ids:predefinedType>
        </ids:entity>
      </ids:applicability>
      <ids:requirements>
        <ids:classification>
          <ids:system><ids:simpleValue>Uniclass 2015</ids:simpleValue></ids:system>
        </ids:classification>
      </ids:requirements>
    </ids:specification>

  </ids:specifications>
</ids:ids>

EIR → IDS: a etapa de tradução que a maioria das equipes pula

Um EIR especifica quais informações o cliente precisa. Um IDS codifica esses requisitos para que uma máquina consiga verificá-los. A tradução entre os dois é a etapa que quase ninguém faz — porque exige alguém que entenda tanto os requisitos de informação quanto o schema XML do IDS a fundo o suficiente para escrever uma especificação que testa exatamente o que o EIR pede, nem mais nem menos.

A consequência: as equipes ou pulam o IDS por completo e dependem de uma revisão manual informal na entrega, ou usam um arquivo IDS genérico que não reflete o EIR real. Os dois caminhos produzem uma falsa sensação de confiança. Uma verificação de IDS aprovada em uma especificação genérica não diz nada sobre se os requisitos específicos do seu cliente foram atendidos.

IDS baseado em perfis: um ponto de partida prático

Nem toda equipe escreve IDS do zero. Uma abordagem prática é manter uma biblioteca de perfis de IDS reutilizáveis: um para a arquitetura do Stage 3, um para o MEP do Stage 4, um para a entrega estrutural. Cada perfil cobre os requisitos mais comuns daquela fase e disciplina, e é estendido por projeto com adições específicas do cliente. Os perfis de IDS podem ser carregados diretamente no motor de validação e combinados — você pode rodar vários arquivos .ids no mesmo modelo e agregar os resultados.

Como as três camadas funcionam juntas — o pipeline de validação

As três camadas formam um portão de qualidade pelo qual um modelo passa em sequência. Cada nível tem uma cadência diferente: o Nível 1 roda a cada exportação (uma verificação de sanidade), o Nível 2 roda antes de qualquer upload no CDE (o portão de qualidade), o Nível 3 roda antes dos marcos formais de entrega (a verificação contratual). Rodá-los fora de ordem desperdiça tempo — não há valor em rodar o IDS em um arquivo com a hierarquia espacial quebrada.


  ┌──────────────────────────────────────────────────────┐
  │  EXPORT IFC from authoring tool                      │
  │  (Revit, ArchiCAD, Tekla, Allplan, Vectorworks…)     │
  └───────────────────────┬──────────────────────────────┘
                          │
                          ▼
  ┌──────────────────────────────────────────────────────┐
  │  LEVEL 1 — IFC Integrity                             │
  │  • GlobalId uniqueness & format (leading char 0–3)   │
  │  • Spatial hierarchy: Project→Site→Building→Storey   │
  │  • IfcRelAggregates chain integrity                  │
  │  • IfcRelContainedInSpatialStructure (no orphans)    │
  │  • Exactly one IfcProject                            │
  │  • FILE_NAME header traceability fields              │
  └─────────┬────────────────────────────────────────────┘
  Fail ◄────┤  Fix in authoring tool (or IFC property editor)
            │  Pass
            ▼
  ┌──────────────────────────────────────────────────────┐
  │  LEVEL 2 — Model Quality (44 rules)                  │
  │  • Naming conventions / empty element names          │
  │  • Property set completeness (Pset_WallCommon etc.)  │
  │  • ISO 19650 metadata (IfcProject.LongName etc.)     │
  │  • Classification presence and consistency           │
  │  • LOD quantity sets, proxy audit, MEP connectivity  │
  │  → Health Score 0–100                                │
  └─────────┬────────────────────────────────────────────┘
  Score<80 ◄┤  Fix properties / names in IFC editor or authoring tool
            │  Score ≥ 80
            ▼
  ┌──────────────────────────────────────────────────────┐
  │  LEVEL 3 — IDS Validation                            │
  │  • Project-specific EIR / AIR requirements           │
  │  • .ids specification(s) for this milestone          │
  │  • Six facets: entity, attribute, property,          │
  │    classification, material, partOf                  │
  └─────────┬────────────────────────────────────────────┘
  Fail ◄────┤  Fix per IDS issue report → export BCF → remediate
            │  All requirements met
            ▼
  ┌──────────────────────────────────────────────────────┐
  │  DELIVER TO CDE                                      │
  │  Attach: Health Score report + IDS pass certificate  │
  └──────────────────────────────────────────────────────┘

A tabela comparativa: Nível 1 vs. Nível 2 vs. Nível 3

Dimensão	N1: integridade IFC	N2: qualidade do modelo	N3: validação IDS
Pergunta respondida	O arquivo é um schema IFC válido?	Os dados são úteis para a coordenação?	Atende aos requisitos de informação do projeto?
Padrão	ISO 10303-21 (STEP), ISO 16739-1 (IFC)	Boas práticas de BIM, normas da ISO 19650	buildingSMART IDS 1.0 (schema XML)
Definido por	buildingSMART (schema fixo)	Equipe BIM / EIR (regras acordadas no projeto)	Cliente / contratante (por projeto)
Resultado	Aprovado / reprovado + lista de erros de schema	Health Score 0–100 + lista de problemas priorizada	Aprovado / reprovado por especificação
Pode substituir os outros?	Não	Não	Não — as três são necessárias
Cadência	A cada exportação de IFC	Antes do upload no CDE	Antes do marco de entrega
Passa mas falha em outro nível?	Zero Psets, sem nomes → N1 aprova, N2 reprova	Resistência ao fogo ausente (spec IDS) → N3 reprova	GUIDs duplicados, hierarquia quebrada
Ferramentas de exemplo	bSmart Validator, IFC Viewer Online	IFC Viewer Online, Solibri, IfcOpenShell	IFC Viewer Online (motor de IDS), Solibri

Quando usar o buildingSMART Validation Service — uma avaliação honesta

O buildingSMART IFC Validation Service verifica arquivos em relação ao schema oficial usando um motor com várias partes: sintaxe do arquivo físico STEP, regras EXPRESS do schema IFC, regras de proposição informal derivadas da especificação e regras normativas de restrição do IFC. É a ferramenta de referência para a conformidade de schema no Nível 1.

Use quando

Certificar a exportação de IFC de um exportador personalizado: o verificador da buildingSMART produz o resultado de referência usado na certificação de softwares. Nenhuma outra ferramenta o substitui em contextos de certificação.
Diagnosticar inconsistência entre parsers: quando um arquivo abre sem problemas em uma ferramenta e dá erro em outra, o verificador da buildingSMART estabelece qual comportamento está correto segundo o schema. Isso é valioso para diagnóstico, mesmo que o arquivo seja utilizável de outra forma.
Uma cláusula contratual exige: algumas especificações de contratação citam a conformidade de schema da buildingSMART como requisito de entrega. Nesse caso, o certificado do serviço oficial é o que satisfaz a cláusula.
Validar o próprio arquivo IDS: o validador de schema de IDS da buildingSMART verifica se o seu arquivo .ids é um documento IDS válido — diferente de rodá-lo contra um modelo.

Não use como substituto de

Verificação de qualidade do modelo — o serviço não verifica a completude dos conjuntos de propriedades, convenções de nomenclatura, classificação nem nenhuma regra de qualidade de dados.
Validação específica do projeto — a conformidade com o schema não diz nada sobre se o modelo atende ao EIR do cliente.
Confirmação de entrega antes do CDE — um modelo válido em termos de schema, com Psets vazios e nomes em branco, vai passar no verificador da buildingSMART e falhar em qualquer portão de qualidade que faça sentido.

Validador de IFC em nuvem vs. validador de IFC no navegador

A distinção entre validação em nuvem (arquivo enviado a um servidor remoto) e validação no navegador (arquivo processado localmente via WebAssembly) importa mais do que a maioria das equipes percebe — especialmente em projetos governamentais, de defesa e comerciais sensíveis.

Validação no navegador

O arquivo IFC nunca sai do dispositivo
Compatível com o GDPR por design — sem transferência de dados
Funciona offline: visitas à obra, redes restritas
Sem cota de upload nem restrição de tamanho de arquivo
Retorno instantâneo — sem latência de ida e volta pela rede
Desempenho consistente, independente da carga do servidor
Não exige conta, chave de API nem assinatura
Funciona em ambientes de rede restritos do governo

Validação em nuvem

Arquivo enviado a um servidor remoto para processamento
Exige um acordo de tratamento de dados (DPA) para o GDPR
Adequado para pipelines automatizados de validação em CI/CD
Registro de auditoria central entre projetos e equipes
Integração via API e webhook para automatizar entregas
Escala horizontalmente para processar modelos em lote
Pode rodar headless, sem sessão de navegador
Resultados consultáveis entre execuções históricas

Quando a validação em nuvem faz sentido

Pipelines automatizados de CI/CD: quando a validação deve ser disparada automaticamente toda vez que um modelo é commitado ou enviado — de forma parecida com equipes de software rodando testes automatizados a cada push de código. APIs em nuvem com webhooks são a arquitetura certa aqui.
Auditoria em toda a organização: quando um gerente BIM precisa de um registro central das execuções de validação em vários projetos e equipes. Serviços em nuvem conseguem agregar dados e ver tendências entre execuções de um jeito que ferramentas locais não conseguem.
Processamento em lote: auditar uma biblioteca de modelos existentes — todos os arquivos IFC entregues a um CDE nos últimos dois anos — é viável em modo de lote na nuvem e inviável de fazer manualmente no navegador.
Modelos não sensíveis: em projetos cujos requisitos de tratamento de dados não proíbem o upload em nuvem, os validadores em nuvem oferecem integração com CI/CD que as ferramentas de navegador não alcançam.

Quando a validação no navegador é a melhor escolha

Projetos governamentais e de defesa: modelos de infraestrutura pública, instalações de defesa e ativos sigilosos costumam ter restrições de tratamento de dados que proíbem o upload para serviços de terceiros. A validação no navegador é a única opção compatível.
Empreendimentos residenciais e comerciais sensíveis: modelos BIM costumam conter informações de ocupantes, endereços de proprietários e metadados de ativos que se qualificam como dados pessoais segundo o Artigo 4 do GDPR. Processá-los em um servidor de terceiros sem um DPA válido e uma base legal é não conformidade.
Uso em obra e em campo: um arquivo IFC de 200 MB em uma conexão 4G sobe devagar e de forma pouco confiável. A validação no navegador processa o arquivo localmente em segundos, sem depender da banda de upload.
Pré-validação antes do upload em nuvem: mesmo quando uma equipe usa um validador em nuvem como portão formal, rodar antes uma verificação no navegador já pega os problemas óbvios sem precisar do upload — reduzindo os custos de uso da nuvem e a frequência de uploads.

Seis erros de validação que as equipes de BIM cometem — e o que eles realmente significam

Erro 1: “O IDS passou — o modelo está bom”

O IDS valida apenas o que a especificação .ids declara. Se o seu arquivo exige FireRating nas paredes, mas o seu EIR também exige IsExternal nas portas, códigos Uniclass nos elementos estruturais e conjuntos de quantidades nas lajes — e isso não foi escrito na especificação —, o motor reporta que todos os requisitos foram atendidos enquanto metade do seu EIR fica sem verificação. Uma aprovação no IDS é uma confirmação contratual em relação a uma especificação específica. Não é um certificado geral de qualidade.

Erro 2: “O verificador da buildingSMART disse que está válido”

A validade de schema é o piso, não o teto. Um arquivo em que todo elemento tem Name='' e zero conjuntos de propriedades é perfeitamente válido em termos de schema. Um modelo sem IfcElementQuantity, sem classificação e com todo elemento físico posicionado diretamente no IfcSite em vez de em um pavimento é perfeitamente válido em termos de schema. Passar no verificador da buildingSMART significa que o arquivo STEP está formatado corretamente — não diz nada sobre se os dados são úteis.

Erro 3: “Eu consigo abrir em um visualizador, então está tudo bem”

Os visualizadores de IFC são permissivos por design — são feitos para exibir geometria independentemente da qualidade dos dados. Um visualizador que se recusasse a abrir arquivos inválidos em termos de schema ou pobres em dados seria inutilizável. A geometria renderizar corretamente não diz nada sobre a completude dos conjuntos de propriedades, as convenções de nomenclatura, a estabilidade dos GUIDs, a classificação ou qualquer uma das 44 dimensões de qualidade. Visualizar um arquivo é categoricamente diferente de validá-lo.

Erro 4: verificar só a geometria, ignorando os dados de propriedade

Um reflexo comum é abrir o IFC, inspecionar o modelo 3D e, se o edifício parece correto, dar o arquivo como pronto. A geometria responde por cerca de 30% do que torna um arquivo IFC útil. Conjuntos de propriedades, classificações, nomes de elementos, atribuições de tipo e conjuntos de quantidades são o que os sistemas de FM, os gerentes de custo e os registros de ativos do CDE realmente consomem. Um arquivo geometricamente correto com conjuntos de propriedades vazios falha na entrega.

Erro 5: validar uma única vez, no prazo final de entrega

Tratar a validação como a última etapa antes de um envio ao CDE significa corrigir problemas sob pressão, sem margem. Um modelo com 800 problemas de validação descobertos na véspera do prazo será entregue com problemas conhecidos ou vai perder o prazo. A cadência correta: Nível 1 depois de cada exportação, Nível 2 antes de cada revisão interna (no mínimo semanal), Nível 3 duas semanas antes de cada marco formal.

Erro 6: ignorar a estabilidade do GUID entre reexportações

GUIDs duplicados dentro de um arquivo são um problema de Nível 1 e são detectáveis por qualquer validador. Mas a instabilidade do GUID entre reexportações — quando o mesmo elemento recebe um GlobalId diferente cada vez que o modelo é exportado — é invisível para a validação de um único arquivo. Quando os GlobalIds mudam entre revisões, todo comentário de BCF, referência de elemento no CDE e etiqueta de ativo de FM silenciosamente vira uma referência solta. Isso exige comparar duas revisões e verificar as configurações de exportação, não apenas validar um único arquivo.

Um workflow de validação prático para coordenadores BIM

Depois de cada exportação de IFC: rode uma verificação de Nível 1. Leva menos de 30 segundos em qualquer validador no navegador. Corrija GlobalIds duplicados, elementos órfãos e quebras na hierarquia espacial antes que se acumulem entre revisões.
Antes de cada revisão interna (semanal ou por sprint): rode uma verificação completa de Nível 2. Analise a tendência do Health Score. Uma nota caindo entre revisões significa que novos problemas estão sendo introduzidos — encontre a origem antes que vire um padrão.
Ao receber qualquer modelo de disciplina de terceiros: rode o Nível 1 e o Nível 2 antes de federar. Um modelo que você recebe pode carregar problemas que você herda para o modelo de coordenação — detecte-os imediatamente, não três semanas depois de coordenar em cima de uma federação quebrada.
Duas semanas antes de qualquer entrega de marco formal: rode as três camadas. Mire em Health Score ≥ 80 antes do IDS. Duas semanas dão tempo para corrigir sem pressão. Sinalize cedo — não consuma a margem.
Antes de enviar ao CDE: rode o Nível 2 e o Nível 3. Anexe o certificado de Health Score e o relatório de aprovação do IDS à transmittal. Isso cria uma trilha de auditoria documentada e dá ao gestor de informação tudo o que ele precisa para aceitar a entrega.
Depois de qualquer atualização de versão do software de autoria ou mudança nas configurações de exportação: reestabeleça a linha de base de estabilidade do GUID comparando duas exportações consecutivas. Uma atualização do Revit ou uma mudança na configuração de exportação pode alterar silenciosamente o comportamento de geração do GlobalId.

Dicas de especialista

Triagem por penalidade, não por quantidade

Não corrija os problemas na ordem do volume — corrija na ordem do impacto no Health Score. Três campos de metadados ausentes no IfcProject podem custar 15 pontos. Oitocentos avisos de nomenclatura podem custar 8 pontos no total. Use a distribuição por gravidade para priorizar pelo impacto.

Trave as configurações de exportação em um template

Toda vez que as configurações de exportação são reconfiguradas manualmente, existe o risco de derivar para uma configuração diferente. Crie uma configuração de exportação de IFC nomeada no seu software de autoria, incorpore-a ao template do projeto e documente as configurações exigidas no BEP. A deriva de configuração é a causa raiz da maioria dos problemas de exportação do tipo “funcionou da última vez”.

Traduza o EIR para IDS no início do projeto

Traduza as cláusulas mais críticas do EIR em uma especificação IDS nas primeiras duas semanas do projeto. Mesmo um arquivo .ids parcial — cinco ou seis especificações — é melhor do que uma revisão manual completa do EIR na hora da entrega, e pega lacunas sistemáticas nos dados cedo, quando ainda são baratas de corrigir.

Valide cada modelo de disciplina antes de federar

Problemas de um modelo de disciplina podem mascarar ou interagir com problemas de outro dentro de uma federação. Valide entradas limpas, federe limpo. Rodar a validação só no modelo de coordenação, depois da federação, dificulta atribuir os problemas ao autor correto.

Perguntas frequentes

Passar no Nível 1 significa que posso pular o Nível 2?

Não. O Nível 1 e o Nível 2 medem propriedades completamente diferentes de um arquivo. Um arquivo válido em termos de schema (Nível 1) pode ter zero conjuntos de propriedades, nomes de elemento vazios, nenhuma classificação e nenhum metadado da ISO 19650 — e obter nota 20 em uma verificação de qualidade (Nível 2). Você sempre precisa dos dois. Pense no Nível 1 como “o arquivo está corretamente empacotado” e no Nível 2 como “o conteúdo do pacote é o que foi pedido”.

O IDS substitui o buildingSMART Validation Service?

Não. O IDS verifica os requisitos de informação específicos do projeto (Nível 3). O buildingSMART Validation Service verifica a conformidade com o schema (Nível 1). Eles operam em níveis completamente diferentes e respondem a perguntas diferentes. Um modelo aprovado no IDS que falha na validação de schema seria uma contradição lógica — a integridade do Nível 1 é pré-requisito para que a verificação do Nível 3 faça sentido.

Quais facetas do IDS devo priorizar em uma entrega BIM padrão?

A faceta Property cobre de 70% a 80% dos requisitos reais de EIR — a maioria dos clientes quer valores específicos de conjuntos de propriedades preenchidos em tipos específicos de elemento. A Classification cobre a maior parte do restante em projetos regidos por Uniclass ou OmniClass. A faceta Entity aparece em quase toda especificação como filtro de aplicabilidade. Material e PartOf tratam de requisitos contratuais específicos. Comece com Entity + Property, adicione Classification se o seu EIR exigir, e expanda a partir daí.

Posso validar um IFC sem fazer upload dele em lugar nenhum?

Sim. Validadores baseados em navegador processam o arquivo inteiramente no seu navegador usando WebAssembly. Os bytes do IFC nunca saem do seu dispositivo — as 44 regras de qualidade, o cálculo do Health Score e todo o motor de IDS rodam no lado do cliente. Para modelos com restrições de tratamento de dados — ativos governamentais, dados residenciais sensíveis, infraestrutura de defesa —, essa costuma ser a única opção compatível.

Que limite de Health Score devo especificar no BEP?

≥ 80 é o limite padrão para entrega no CDE e coordenação de projeto. ≥ 90 para entregas de desenvolvimento de projeto em LOD 300+ e submissões de marcos formais da ISO 19650. ≥ 70 é aceitável para revisões internas em fase de concepção. Abaixo de 60, o modelo tem problemas estruturais de qualidade e não deve ser entregue a nenhuma parte externa, em nenhuma circunstância.

Uma única ferramenta pode cobrir as três camadas de validação?

Algumas ferramentas cobrem. O IFC Viewer Online cobre o Nível 1 (regras de integridade, incluindo verificações de GUID, hierarquia e cabeçalho do arquivo), o Nível 2 (verificação de qualidade com 44 regras e Health Score) e o Nível 3 (motor de IDS 1.0 validado em relação aos 100 casos de teste oficiais da bSI). O Solibri cobre o Nível 2 e o Nível 3, com um motor de regras mais sofisticado, mas sem processamento no navegador. O buildingSMART Validation Service cobre só o Nível 1. O IfcOpenShell pode ser programado por script para o Nível 1 e o Nível 2.

Resumo

Válido em termos de schema não é válido para o projeto. Válido para o projeto não é compatível com o EIR. As três camadas de validação são necessárias — e confundi-las é a causa raiz da maioria das falhas em entregas formais.
IFC Viewer Blog

Nível 1: rode a cada exportação

Integridade de schema, unicidade e formato do GlobalId, hierarquia espacial. Leva 30 segundos. Pega as falhas estruturais que corrompem silenciosamente o BCF, o versionamento no CDE e os registros de ativos de FM mais adiante.

Nível 2: portão de toda entrega no CDE

44 regras de qualidade, Health Score, convenções de nomenclatura, completude dos conjuntos de propriedades, metadados da ISO 19650. Exija ≥ 80 no seu BEP e EIR. É essa camada que torna um modelo útil — não apenas processável.

Nível 3: verifique antes de cada marco

Especificações IDS que codificam o seu EIR e AIR em forma legível por máquina. Traduza as cláusulas críticas no início do projeto, não na semana anterior à entrega. Uma aprovação no IDS é uma trilha de auditoria contratual documentada.

Rode uma verificação de qualidade completa no seu modelo atual — em menos de 30 segundos, em qualquer navegador, sem nada enviado. Depois, leia o guia do Health Score do IFC para entender como a nota é calculada e qual limite definir no seu BEP. Se valores de propriedade ou GUIDs precisarem de correção em um arquivo recebido, o guia do editor de IFC online gratuito cobre a edição não destrutiva de propriedades sem precisar voltar ao software de autoria. E para as falhas estruturais mais comuns que causam rejeições no Nível 1, veja os 7 erros de validação de IFC mais comuns.

Verificador de modelos IFC: o guia completo de validação IFC, qualidade de modelo e IDS