Voltar ao blog de BIM e IFC
Validação · 2026-10-01 · 12 min
IDS explicado: como verificar um modelo IFC com uma Information Delivery Specification
O IDS transforma "o modelo deve conter a resistência ao fogo" de uma frase num PDF em um arquivo que uma máquina consegue verificar. O que as seis facetas realmente testam, onde a maioria dos arquivos IDS erra e como executar um contra o seu IFC no navegador.
IDS explicado: como verificar um modelo IFC com uma Information Delivery Specification — IFC Viewer Online article cover
Todo EIR já escrito contém uma frase como "todas as portas deverão indicar sua resistência ao fogo". E em todo projeto essa frase é verificada do mesmo jeito: alguém abre o modelo, clica em algumas portas e decide que provavelmente está tudo bem. O requisito é preciso. A verificação é uma impressão.
O IDS — a Information Delivery Specification — existe para fechar essa lacuna. É um formato XML pequeno, padronizado pela buildingSMART como IDS 1.0, que expressa requisitos de informação de um jeito que uma máquina consegue testar. Escreva o requisito uma vez, entregue o arquivo .ids a cada fornecedor, e "provavelmente está bem" vira "412 de 418 portas passam; estas são as seis que não".
O essencial
- O IDS verifica informação, não geometria: classes, atributos, propriedades, classificações, materiais e relações.
- Cada especificação tem duas metades — a quais elementos se aplica e o que esses elementos precisam ter. A maioria dos arquivos IDS quebrados erra na primeira metade.
- Um IDS é um documento contratual. Fica ao lado do BEP, versionado, e é enviado aos fornecedores antes de a modelagem começar, não depois da primeira rejeição.
Anatomia de uma especificação
Uma especificação IDS se lê como uma frase: para cada elemento que corresponda à aplicabilidade, exija os requisitos.
Um arquivo IDS é uma lista de especificações. Cada uma se lê como uma frase com sujeito e predicado: "para cada elemento que corresponda a isto, exija aquilo". O sujeito é a aplicabilidade; o predicado, os requisitos.
<specification name="Doors carry a fire rating" ifcVersion="IFC4">
<applicability minOccurs="1">
<entity><name><simpleValue>IFCDOOR</simpleValue></name></entity>
</applicability>
<requirements>
<property dataType="IFCLABEL">
<propertySet><simpleValue>Pset_DoorCommon</simpleValue></propertySet>
<baseName><simpleValue>FireRating</simpleValue></baseName>
</property>
</requirements>
</specification>
Leia em voz alta e é exatamente a frase do EIR: todo IfcDoor deve ter um FireRating em Pset_DoorCommon, armazenado como label. O minOccurs="1" na aplicabilidade acrescenta uma segunda afirmação fácil de ignorar: o modelo deve conter pelo menos uma porta. Sem ele, um modelo sem nenhuma porta passa, o que raramente é o que alguém quis dizer.
As seis facetas e o que cada uma testa de verdade
| Faceta | Testa | Requisito típico | Armadilha comum |
|---|
| Entity | Classe IFC e tipo predefinido | Paredes são IfcWall, não IfcBuildingElementProxy | Esquecer os subtipos: IfcWallStandardCase é um IfcWall no IFC2x3 |
| Attribute | Atributos IFC diretos (Name, Description, Tag…) | Todo espaço tem Name e LongName | Uma string vazia está presente mas é inválida, não ausente |
| Property | Uma propriedade num property set, com tipo de dado e valor | Pset_WallCommon.IsExternal é TRUE ou FALSE | Valor certo, tipo de dado errado (um label onde se pedia um booleano) |
| Classification | Uma referência de classificação e seu código | Todo elemento tem um código Uniclass Ss | Verificar o código mas não o sistema a que pertence |
| Material | Um nome ou categoria de material associado | Pilares estruturais declaram um material | Materiais no tipo, não na ocorrência |
| PartOf | Uma relação com um elemento pai | Todo elemento está contido num pavimento | Confundir agregação com contenção espacial |
Cada faceta pode aparecer na aplicabilidade (para selecionar elementos) ou nos requisitos (para exigir algo deles).Duas dessas armadilhas merecem um olhar mais demorado, porque respondem pela maioria das falsas falhas que as pessoas relatam ao executar um IDS pela primeira vez.
Tipo versus ocorrência
As propriedades podem estar no tipo, não na ocorrência. Um verificador IDS precisa seguir o tipo ou reprova elementos corretos.
Revit, ArchiCAD e Tekla costumam gravar propriedades e materiais no objeto de tipo (IfcWallType) em vez de em cada parede. A semântica do IDS é clara: a informação herdada do tipo vale para a ocorrência. Um verificador que olha só a ocorrência reprova todas as paredes de um modelo perfeitamente bom. Se um IDS diz que 100% dos seus elementos não têm uma propriedade que você vê no painel de propriedades, quase sempre é por isso — e a culpa é do verificador, não sua.
Tipos predefinidos USERDEFINED
Quando um tipo predefinido é USERDEFINED, o tipo real fica em ObjectType (nas ocorrências) ou em ElementType (nos tipos). Uma faceta entity que peça IFCWALL com tipo predefinido PARAPET deve corresponder a uma parede cujo PredefinedType seja USERDEFINED e cujo ObjectType seja PARAPET. Verificadores que comparam o enum bruto deixam passar todas elas.
Cinco erros que tornam um IDS inútil
- Aplicabilidade ampla demais. "Todos os elementos devem ter código Uniclass" arrasta aberturas, anotações e elementos espaciais que ninguém classifica. Restrinja cada especificação às classes de que o requisito realmente trata.
- Valores sem tipo de dado. Um requisito FireRating = "EI 60" não diz nada sobre como deve ser armazenado; o mesmo texto guardado como descrição em outro pset continua falhando. Diga o que você quer dizer, incluindo o tipo de dado.
- Valores exatos onde se queria um padrão. Dados reais trazem "EI60", "EI 60" e "EI-60". Use um xs:pattern ou uma enumeração e acorde a forma canônica no BEP.
- Uma especificação gigante. Quarenta requisitos numa especificação produzem um único aprovado ou reprovado por elemento e um relatório com o qual ninguém consegue agir. Um requisito por especificação, com nome em linguagem clara, é o que torna o resultado legível.
- Escrever o IDS depois do modelo. Um IDS enviado com a primeira rejeição é um requisito novo. Um IDS enviado com a contratação é um requisito. Só o segundo é exigível.
O lado contratual desse último ponto — quais cláusulas tornam um IDS vinculante e o que acontece quando uma entrega não o cumpre — está em cláusulas do BEP que realmente evitam entregas IFC ruins e em critérios de aceitação IFC.
Executando um IDS contra o seu modelo, passo a passo
- Abra o IFC Arraste o modelo para o visualizador. Ele é processado no seu navegador; nada é enviado.
- Carregue o arquivo .ids Abra o painel IDS e escolha seu arquivo — ou comece por uma das especificações de exemplo incluídas se quiser ver o formato primeiro.
- Execute a verificação Cada especificação é avaliada com as seis facetas. Modelos grandes mostram o progresso por fase e podem ser cancelados a qualquer momento.
- Leia o resultado por especificação, elemento ou classe Agrupe as falhas do jeito que você pretende corrigi-las. Cada falha traz o motivo em palavras claras: propriedade ausente, valor errado, tipo de dado errado, classe errada.
- Veja em 3D Destacar colore no modelo os elementos que falham; Isolar esconde todo o resto. Os dois estão a um clique, e é assim que uma lista de GlobalIds vira uma conversa com quem modela.
IDS entre revisões
Uma execução de IDS é uma fotografia. O que um coordenador precisa de verdade é a tendência: a revisão 7 corrigiu as falhas levantadas na revisão 6? Introduziu novas? Como o resultado é indexado por GlobalId, a mesma especificação pode ser comparada entre duas versões de um modelo — o que só funciona se seus GlobalIds forem estáveis entre exportações. Se não forem, corrija isso primeiro: por que os GUIDs do IFC mudam a cada exportação. A comparação em si está em como comparar duas versões de um modelo IFC.
Onde o IDS para
O IDS não verifica geometria. Não vai dizer que dois dutos colidem, que uma porta é estreita demais para uma cadeira de rodas nem que o modelo está a dois quilômetros do seu ponto de levantamento. Também não verifica se um IFC é estruturalmente saudável — um arquivo com GlobalIds duplicados ou posicionamentos quebrados pode passar num IDS com perfeição.
Isso não é uma fraqueza; é escopo. Use o IDS para requisitos de informação, um model checker para estrutura e geometria, e entregue os dois relatórios lado a lado. O fluxo completo está em como validar um arquivo IFC.
IDS explicado: como verificar um modelo IFC com uma Information Delivery Specification