Entenda IDS BIM, Information Delivery Specification, applicability, requirements e como verificar requisitos de informação em modelos IFC.
Confira!
IDS BIM — Information Delivery Specification — é o padrão openBIM da buildingSMART para definir requisitos de informação em uma forma legível por pessoas e interpretável por computadores. Seu uso permite transformar exigências que normalmente ficam dispersas em planilhas, documentos de requisitos e memoriais em especificações estruturadas que podem ser confrontadas automaticamente com modelos IFC.
O princípio é direto: primeiro se define quais objetos devem atender a determinado requisito e quais informações precisam existir ou assumir valores aceitáveis; depois, um software compatível compara o modelo IFC com essa especificação e informa quais objetos atendem ou não atendem ao que foi exigido. O IDS não corrige o modelo e não substitui a decisão de engenharia. Ele torna verificável uma parte dos requisitos de informação.
Um requisito como “todos os equipamentos de climatização destinados à manutenção preventiva devem possuir identificação única, fabricante, modelo e código do ativo” pode ser escrito em linguagem contratual, mas também pode ser convertido em uma especificação IDS. O verificador identifica os objetos aplicáveis, procura as propriedades exigidas e devolve resultados de conformidade de forma repetível. Isso reduz verificações manuais, melhora a rastreabilidade e permite detectar lacunas de informação antes que elas cheguem ao aceite, ao As-Built ou ao modelo de informação do ativo.
A relação com IFC é essencial. IFC transporta os objetos, propriedades, classificações, materiais e relações do modelo; IDS descreve quais dessas informações precisam estar presentes, como devem ser estruturadas e, quando aplicável, quais valores são aceitos. Por isso, IDS é particularmente útil em fluxos Open BIM nos quais o contratante precisa verificar entregas produzidas em diferentes ferramentas de autoria.
IDS também não é sinônimo de regra de projeto. Ele pode verificar, por exemplo, se uma porta possui a propriedade requerida e se o valor informado pertence a uma faixa ou conjunto permitido. Isso é diferente de concluir se a solução arquitetônica ou de engenharia é adequada. A automação verifica conformidade da informação; a engenharia continua responsável por interpretar requisitos técnicos, interfaces, riscos, desempenho, construtibilidade e operação.
O que é IDS BIM e qual problema ele resolve
A produção BIM gera grande quantidade de informação, mas quantidade não garante utilidade. Um modelo pode estar geometricamente detalhado e ainda falhar em uma entrega porque faltam classificações, códigos de ativos, propriedades, materiais ou valores necessários para orçamento, coordenação, operação ou manutenção.
O problema se torna mais crítico quando os requisitos estão apenas em documentos destinados à leitura humana. Um EIR pode determinar que equipamentos críticos tenham identificação, fabricante, modelo, potência, localização e classe de manutenção. Uma planilha pode indicar parâmetros obrigatórios. Um memorial pode definir nomenclatura. O AIR pode estabelecer os dados necessários para operação. Se essas exigências não forem convertidas em regras verificáveis, alguém precisará conferir manualmente milhares de objetos ou confiar que cada equipe interpretou os documentos da mesma forma.
IDS cria uma camada intermediária entre requisito e verificação.
A parte requerente ou a equipe responsável pela gestão da informação pode definir uma especificação que identifique quais elementos são aplicáveis e quais dados devem ser entregues. O arquivo IDS pode então ser utilizado em ferramentas compatíveis para verificar modelos IFC de forma automatizada.
Isso melhora quatro aspectos do processo:
| Dimensão | Sem requisito verificável | Com IDS bem estruturado |
| interpretação | depende da leitura individual de documentos | requisitos são explicitados em estrutura computável |
| verificação | amostral ou manual | repetível e automatizável |
| rastreabilidade | difícil relacionar falha ao requisito | cada não conformidade pode ser associada à especificação |
| aceite | discussão ocorre no fim | problemas podem ser detectados antes da entrega formal |
Um exemplo simples: equipamentos sem dados mínimos
Considere um modelo IFC com 127 equipamentos de climatização que deverão integrar a estratégia de manutenção do ativo.
O requisito estabelece quatro informações obrigatórias: Tag do equipamento, Fabricante, Modelo e Código do Ativo.
Um verificador IDS pode retornar algo como:
| Resultado | Quantidade |
| equipamentos avaliados | 127 |
| conformes | 119 |
| sem fabricante | 5 |
| sem modelo | 2 |
| sem código do ativo | 1 |
O resultado não diz se o equipamento foi corretamente dimensionado, se sua localização é adequada ou se a estratégia de manutenção está correta. Ele diz que determinadas informações exigidas não foram entregues da forma especificada.
Essa distinção é decisiva. Um processo BIM maduro separa a verificação de requisitos informacionais da análise de mérito técnico.
IDS não substitui coordenação, Design Review ou compatibilização
Uma especificação pode verificar se um QGBT possui identificação, fabricante, tensão nominal, grau de proteção e classificação definida. Ela não conclui, por si só, se há espaço seguro de operação, acesso para manutenção, coordenação com arquitetura ou coerência com a distribuição elétrica.
Essas questões dependem de engenharia. A Compatibilização de Projetos trata interfaces entre disciplinas, enquanto a revisão técnica pode avaliar desempenho, manutenção, construtibilidade e maturidade da solução.
Automatizar um requisito mal definido apenas acelera a produção de não conformidades. A Gestão BIM e Informação de Engenharia da A3A Engenharia estrutura necessidades, responsabilidades, entregas e critérios de verificação antes que requisitos sejam convertidos em IDS.
Como o IDS transforma requisitos de informação em especificações verificáveis
Uma especificação IDS precisa responder duas perguntas fundamentais:
1. A quais objetos o requisito se aplica?
2. O que esses objetos precisam possuir ou atender?
Essa lógica costuma ser descrita pela separação entre applicability e requirements.
Applicability: definir o conjunto de objetos que será verificado
A applicability funciona como o recorte do modelo. Em vez de dizer genericamente “verifique todo o IFC”, a especificação define quais elementos pertencem ao universo daquele requisito.
O filtro pode considerar, conforme o caso, entidade IFC, classificação, atributos, propriedades, materiais ou relações com outros objetos.
Exemplo conceitual:
> Aplicar aos objetos IfcAirTerminal classificados como difusores de insuflação pertencentes ao sistema de climatização do pavimento.
A qualidade desse recorte é tão importante quanto a qualidade do requisito. Se a applicability estiver ampla demais, objetos que não deveriam ser verificados podem gerar falsas não conformidades. Se estiver restritiva demais, elementos relevantes podem escapar da análise.
Requirements: definir o que precisa ser entregue
Depois de selecionar os objetos aplicáveis, o IDS define quais condições precisam ser atendidas.
Um requisito pode exigir, por exemplo, existência de determinada classificação; presença de uma propriedade específica; valor pertencente a um conjunto permitido; preenchimento de atributo; associação a determinado material; relação com outro objeto do modelo; ou uso de entidade IFC adequada.
O ponto central é que o requisito deixa de ser apenas uma frase e passa a ter estrutura suficiente para ser processado por software.
Facets: as peças usadas para construir a especificação
Na prática, IDS utiliza diferentes tipos de facetas para descrever applicability e requirements. Entre as mais relevantes estão entidade, atributo, classificação, propriedade, material e relações do tipo partOf.
Isso permite construir exigências como:
> Todos os IfcWall aplicáveis devem possuir FireRating em Pset_WallCommon, com valor pertencente ao conjunto definido pelo projeto.
ou:
> Todo equipamento incluído no escopo de operação deve possuir uma classificação válida e uma propriedade de identificação preenchida.
A especificação pode combinar múltiplas condições, mas complexidade excessiva reduz legibilidade e aumenta o risco de interpretações diferentes entre ferramentas.
Restrição de valores
Nem todo requisito é simplesmente “a propriedade existe”. Frequentemente é necessário controlar também o valor.
| Tipo de controle | Exemplo |
| valor único | Status = Operacional |
| conjunto permitido | FireRating = REI30, REI60 ou REI90 |
| padrão de texto | código seguindo convenção de identificação |
| faixa | valor dentro de intervalo definido |
| tipo de dado | propriedade compatível com o datatype esperado |
A automação só funciona bem quando a exigência foi definida com clareza. Expressões vagas como “preencher adequadamente”, “informar quando necessário” ou “usar classificação correta” precisam ser transformadas em critérios objetivos antes de serem convertidas em IDS.
Requisito obrigatório não significa que toda informação possível deve ser exigida
Um dos erros mais comuns em processos BIM é transformar qualquer dado potencialmente útil em informação obrigatória.
Quanto mais propriedades exigidas sem uso definido, maior o custo de modelagem, maior a quantidade de falhas e menor a qualidade média do preenchimento. O requisito deve nascer de uma finalidade: decisão, coordenação, quantitativo, contratação, operação, manutenção, rastreabilidade ou aceite.
Por isso, a relação entre IDS e LOD/LOIN é importante. A necessidade de informação deve ser definida antes de automatizar sua verificação.
O ponto de partida não é o arquivo IDS, mas a necessidade de informação. Quando PIR, AIR, EIR e LOIN ainda estão incompletos, a Gestão BIM e Informação de Engenharia da A3A Engenharia pode organizar requisitos e marcos antes da automação, evitando exigir dados sem finalidade ou aceitar entregas que não respondem às decisões do empreendimento.
Como funciona a verificação IDS de um modelo IFC
O fluxo de verificação não começa quando o arquivo IFC está pronto. Ele começa quando os requisitos de informação são definidos.
Uma sequência robusta pode seguir sete etapas.
1. Definir o uso da informação
A primeira pergunta é: para qual decisão ou processo esse dado será utilizado?
Se a informação será usada para operação, o AIR pode definir o conjunto necessário. Se sustenta uma entrega de projeto, o requisito pode nascer do PIR ou EIR. Se serve a quantitativos, classificação e propriedades precisam estar alinhadas com esse uso.
2. Converter o requisito em regra verificável
O requisito humano precisa ser transformado em especificação objetiva.
Em vez de:
> “Equipamentos devem possuir informações suficientes para manutenção.”
é preferível estabelecer:
> “Todo equipamento incluído no escopo de manutenção deve possuir Tag, Fabricante, Modelo, Código do Ativo e Classe de Manutenção.”
A partir daí, cada informação pode ser mapeada para uma propriedade ou classificação verificável.
3. Definir applicability e requirements
A especificação precisa distinguir o conjunto de objetos alvo das condições que esses objetos devem satisfazer.
Esse passo exige cuidado para evitar duas falhas opostas: exigir dados de elementos aos quais o requisito não deveria se aplicar; ou deixar de incluir objetos que deveriam ter sido verificados.
4. Produzir e exportar o IFC conforme o fluxo definido
A equipe autora desenvolve o modelo e realiza a exportação IFC conforme as regras do empreendimento. A qualidade do resultado depende de mapeamento de classes, propriedades, classificações, coordenadas, versões e configurações de exportação.
O Arquivo IFC no BIM continua sendo o contêiner da informação que será verificada. IDS não substitui a necessidade de testar a interoperabilidade da exportação.
5. Executar a checagem
A ferramenta compatível lê o IDS e o IFC, identifica os objetos aplicáveis e avalia os requisitos.
O resultado pode ser apresentado por especificação, objeto, propriedade, disciplina ou outro agrupamento oferecido pela aplicação.
Uma saída útil não deveria se limitar a “modelo reprovado”. Ela precisa permitir localizar a causa:
| Objeto | Requisito | Resultado | Motivo |
| AHU-01 | Fabricante | falha | propriedade ausente |
| AHU-02 | Modelo | falha | valor vazio |
| AHU-03 | Código do Ativo | falha | padrão inválido |
| AHU-04 | Classe de manutenção | conforme | valor aceito |
6. Corrigir a informação na origem
A não conformidade deve voltar para a equipe responsável pelo modelo autoral ou pela origem do dado.
Não é boa prática editar o IFC apenas para “passar no teste” se o modelo de autoria permanecer incorreto. A correção precisa preservar autoria, responsabilidade e rastreabilidade.
Quando a não conformidade precisa ser comunicada e acompanhada entre equipes, BCF BIM pode estruturar a issue, o responsável, o comentário, a evidência e o estado da resolução.
7. Revalidar e registrar evidência de aceite
Depois da correção, uma nova revisão do modelo deve ser verificada.
A automação permite repetir o mesmo conjunto de regras sem depender de conferência manual diferente a cada ciclo. Isso cria comparabilidade entre revisões e pode gerar evidência objetiva para liberação.
Quando o aceite depende de requisitos formais, a solução de Gestão de Requisitos, Evidências e Critérios de Aceite pode relacionar requisito, verificação, não conformidade, evidência e decisão de forma rastreável.
Passar na checagem não é, por si só, obter aceite. A solução de Gestão de Requisitos, Evidências e Critérios de Aceite da A3A Engenharia conecta cada exigência à evidência, à revisão verificada, às não conformidades e à decisão formal de liberação.
IDS, IFC, LOIN, EIR e CDE: qual o papel de cada camada
IDS ganha clareza quando colocado dentro da arquitetura completa de gestão da informação.
| Camada | Função principal | Pergunta que responde |
| OIR/AIR/PIR | definir necessidades organizacionais, do ativo e do projeto | que informação é necessária e por quê? |
| EIR | estruturar requisitos para trocas e entregas | o que deve ser entregue em cada troca? |
| LOIN | qualificar a necessidade de informação | quanto e qual informação é necessária para o uso? |
| IDS | formalizar requisitos verificáveis por computador | como verificar automaticamente parte dessas exigências? |
| IFC | transportar a informação do modelo | onde estão os objetos e dados que serão verificados? |
| CDE | controlar estados, revisões e autorizações | qual informação é válida e para qual uso? |
| BCF | comunicar não conformidades e issues | quem precisa agir e qual é o estado da resolução? |
| Design Review / Compatibilização | avaliar mérito técnico e interfaces | a solução está tecnicamente adequada? |
IDS e EIR não são a mesma coisa
O EIR é mais amplo. Ele pode incluir formatos, nomenclatura, CDE, responsabilidades, prazos, métodos de produção, requisitos de coordenação e condições contratuais que não cabem em IDS.
IDS pode ser um mecanismo para tornar parte dos requisitos de informação formalmente verificável. Portanto, não é adequado substituir um EIR completo por um arquivo IDS.
IDS e LOIN
LOIN orienta quais informações são necessárias para determinado propósito e marco. IDS pode expressar de maneira computável parte dessas exigências, especialmente requisitos alfanuméricos ligados ao IFC.
Automatizar sem definir a necessidade de informação produz apenas uma fiscalização mais rápida de requisitos mal concebidos.
IDS e IFC
A ligação é direta porque o IDS foi concebido para verificar entregas baseadas em IFC.
Se o requisito exige uma propriedade que a exportação não inclui, a checagem falhará mesmo que o dado exista no software de autoria. Essa falha pode indicar problema de modelagem, mapeamento, exportação, versão de esquema ou definição do próprio requisito.
Por isso, a validação deve separar ausência real da informação de perda durante a troca.
IDS e CDE
O CDE BIM controla estados, revisões, metadados e autorizações dos contêineres. IDS controla uma verificação específica sobre o conteúdo da informação.
Uma revisão pode passar no IDS e ainda não estar autorizada para uso. Da mesma forma, um arquivo pode estar formalmente compartilhado no CDE e falhar em requisitos de informação.
As duas camadas precisam ser coordenadas.
IDS e NBR 15965
Quando a entrega exige classificação consistente, a NBR 15965 aplicada ao BIM pode orientar a estrutura classificatória utilizada pelo empreendimento. O IDS pode então verificar se os objetos aplicáveis receberam as classificações exigidas.
Isso reduz um problema comum: modelos visualmente corretos, mas semanticamente incompatíveis porque cada disciplina classifica objetos de forma diferente.
O resultado da verificação só é confiável quando se sabe exatamente qual IDS foi aplicado a qual revisão do modelo. A solução de Ambiente Comum de Dados e Gestão da Informação BIM da A3A Engenharia organiza revisões, estados, autorizações e evidências para que a checagem faça parte do fluxo controlado da informação.
Como estruturar requisitos verificáveis e critérios de aceite
A qualidade do IDS depende mais da qualidade do requisito do que da ferramenta usada para escrever o arquivo.
Comece pela finalidade, não pela propriedade
A pergunta inadequada é: “Quais propriedades conseguimos exigir?”
A pergunta correta é: “Quais informações são necessárias para tomar esta decisão, executar este processo ou aceitar esta entrega?”
Só depois disso deve ocorrer o mapeamento para entidades, classificações, propriedades e valores.
A Gestão BIM e Informação de Engenharia da A3A Engenharia pode estruturar requisitos, responsabilidades, BEP, CDE, estratégia de troca e critérios de verificação antes que a automação seja implantada.
Escreva requisitos testáveis
Compare:
Ambíguo: “Os equipamentos devem estar corretamente identificados.”
Verificável: “Todo equipamento do escopo de manutenção deve possuir Tag única preenchida conforme convenção de identificação do empreendimento.”
Ambíguo: “As paredes precisam ter classificação de resistência ao fogo.”
Verificável: “As paredes pertencentes aos compartimentos definidos no escopo devem possuir a propriedade FireRating com valor pertencente ao conjunto autorizado para o projeto.”
Quanto mais objetiva for a especificação humana, menor a chance de criar um IDS que apenas formaliza ambiguidades.
Defina o responsável pelo requisito
Cada requisito precisa ter origem e autoridade.
Pode vir do contratante, da operação, de norma aplicável, do projeto, de concessionária, de segurança, de manutenção ou de uma necessidade de integração com sistemas corporativos.
Sem origem identificada, mudanças no requisito se tornam difíceis de governar.
Controle versões do próprio IDS
O IDS também é informação controlada. Se o requisito muda entre uma entrega e outra, a equipe precisa saber qual versão da especificação foi aplicada em cada verificação.
Um processo maduro registra:
1. versão da especificação IDS; 2. versão do esquema IFC aplicável; 3. revisão do modelo verificado; 4. data e ferramenta de checagem; 5. resultado; 6. responsáveis pela análise; 7. decisão de aceite ou retorno para correção.
Essa rastreabilidade pode ser integrada ao Ambiente Comum de Dados e Gestão da Informação BIM.
Não confunda conformidade de dados com qualidade integral do projeto
Um modelo pode passar em 100% dos requisitos IDS e ainda conter problemas graves de engenharia.
O QGBT pode possuir todos os atributos requeridos e estar mal localizado. Uma bomba pode ter fabricante, modelo, potência e classificação corretos, mas não possuir espaço para retirada. Uma rota redundante pode estar perfeitamente classificada e ainda compartilhar o mesmo risco físico.
Por isso, o resultado IDS deve alimentar — e não substituir — Design Review, coordenação e compatibilização.
Em ativos existentes, a verificação depende da confiabilidade da condição de base
Em retrofit e brownfield, pode haver um problema anterior à própria especificação: o modelo não representa o que está instalado.
Se o AIR exige identificação e atributos de equipamentos existentes, mas o cadastro está desatualizado, o primeiro passo pode ser verificar fisicamente o ativo.
A A3A Engenharia pode estruturar essa condição de base por meio de Site Survey, Levantamento Cadastral e Due Diligence Técnica de Engenharia, conforme a abrangência necessária.
A sequência evita criar requisitos sofisticados sobre uma base cadastral que já nasce incorreta.
Em retrofit e brownfield, não existe validação digital confiável sem uma condição de base confiável. A A3A Engenharia pode preceder a modelagem e a verificação com Site Survey, Levantamento Cadastral e Due Diligence Técnica, criando uma base coerente para projeto, compatibilização, aceite e As-Built.
IDS pode antecipar problemas que normalmente aparecem apenas no As-Built
Quando requisitos de operação são definidos somente no final da obra, a equipe descobre tarde que faltam tags, classificações, fabricantes, modelos, códigos ou atributos necessários para o ativo.
Se o AIR e os critérios de informação forem definidos desde o projeto, IDS pode verificar progressivamente essas exigências ao longo das entregas. O As-Built de Engenharia deixa de ser uma tentativa de reconstruir dados no encerramento e passa a consolidar informação produzida e validada de forma progressiva.
Essa abordagem reduz retrabalho e melhora a transição do modelo de informação do projeto para a informação útil à operação.
Conclusão
IDS BIM transforma requisitos de informação em uma linguagem que pode ser utilizada para especificar e verificar automaticamente parte do conteúdo de modelos IFC. Seu valor está menos no arquivo em si e mais na capacidade de conectar necessidade, especificação, entrega, verificação, não conformidade e aceite.
A automação funciona quando os requisitos foram previamente definidos com precisão. É necessário saber quais objetos estão no escopo, quais informações são necessárias, qual estrutura deve ser utilizada, quais valores são aceitáveis e em qual marco a exigência deve ser atendida.
IDS não substitui EIR, LOIN, IFC, CDE, BCF, coordenação ou análise técnica. Cada instrumento resolve uma parte diferente do problema. O requisito define a necessidade; IDS formaliza a verificação; IFC transporta os dados; CDE controla a informação válida; BCF organiza a não conformidade; e a engenharia decide se a solução é aceitável.
Em projetos complexos, essa integração permite deixar de conferir grandes volumes de informação apenas no fim. Requisitos podem ser testados ao longo das revisões, problemas podem retornar à origem antes do aceite e evidências podem ser preservadas para auditoria, contratação, compatibilização, entrega e As-Built.
O objetivo final não é obter um relatório com todos os itens em verde. É garantir que a informação necessária para cada decisão esteja disponível, estruturada, verificável e vinculada ao processo de engenharia que lhe dá significado.
Referências técnicas
[1] BUILDINGSMART INTERNATIONAL. Information Delivery Specification (IDS). buildingSMART Standards and Services. Disponível em: buildingSMART — Information Delivery Specification. Acesso em: 8 ago. 2026.
[2] BUILDINGSMART INTERNATIONAL. Information Delivery Specification (IDS) v1.0 is Approved as a Final Standard. 4 jun. 2024. Disponível em: buildingSMART — IDS v1.0 Final Standard. Acesso em: 8 ago. 2026.
[3] ABNT. ABNT NBR ISO 19650-4:2025 — Organização e digitização da informação sobre edifícios e obras de engenharia civil, incluindo BIM — Gestão da informação usando BIM — Parte 4: Troca de informação.
[4] BIM FÓRUM BRASIL; CAU/BR. Coletânea de Gerenciamento e Coordenação de Projetos em BIM — Guia Coordenação de Projetos de Edificações em BIM. São Paulo, 2026.
Perguntas frequentes
IDS BIM, ou Information Delivery Specification, é um padrão openBIM da buildingSMART para definir requisitos de informação de forma interpretável por computador e verificar automaticamente a conformidade de modelos IFC.
Serve para registrar especificações de informação verificáveis, definindo quais objetos são aplicáveis e quais entidades, classificações, propriedades, materiais, relações ou valores precisam ser entregues em um modelo IFC.
Não. IFC transporta os objetos e dados do modelo; IDS descreve requisitos que podem ser usados para verificar se determinadas informações foram entregues corretamente nesse IFC.
EIR é um instrumento mais amplo de requisitos de troca e pode tratar formatos, responsabilidades, CDE, prazos e procedimentos. IDS torna uma parte dos requisitos de informação computacionalmente verificável.
LOIN define a necessidade de informação para determinado uso e marco. IDS pode formalizar parte dessa necessidade em uma especificação verificável por software.
IDS é voltado principalmente à verificação estruturada de requisitos de informação vinculados ao IFC. Ele não substitui análises de engenharia, compatibilização, Design Review ou rule checking de desempenho e geometria.
Applicability define quais objetos do modelo pertencem ao escopo da especificação. Requirements define quais condições esses objetos precisam atender.
Sim. O padrão permite especificar requisitos envolvendo entidades, classificações, propriedades, materiais, valores e outras estruturas suportadas pelo IDS e pelo esquema IFC.
Quando requisitos de operação e manutenção são definidos antecipadamente, IDS pode verificar progressivamente se tags, classificações, fabricantes, modelos e outros dados necessários estão sendo entregues, reduzindo a reconstrução de informação no encerramento.
Em ativos existentes, retrofit ou brownfield, quando o modelo e a documentação não representam com confiabilidade a condição instalada. Primeiro é necessário consolidar uma base de campo correta; depois os requisitos podem ser verificados digitalmente.
Materiais técnicos complementares
Soluções
- Gestão de Requisitos, Evidências e Critérios de Aceite
- Ambiente Comum de Dados e Gestão da Informação BIM
- Gestão Eletrônica de Documentos Técnicos e Controle de Revisões
Serviços
- Gestão BIM e Informação de Engenharia
- Compatibilização de Projetos
- Site Survey
- Levantamento Cadastral de Edificações, Instalações e Infraestruturas
- Due Diligence Técnica de Engenharia
Guias técnicos
Whitepapers
Artigos técnicos
