Information Delivery Specification (IDS)

Padrão aberto buildingSMART — define, de forma legível por máquina, quais informações são obrigatórias em um modelo IFC, tornando os requisitos do EIR verificáveis automaticamente.

Sumário

1. O que é o IDS
2. Relação com o IFC e o BEP
3. Estrutura do arquivo IDS
4. Facets — os tipos de requisito
5. Applicability vs Requirements
6. Exemplos práticos
7. Fluxo de uso do IDS
8. Ferramentas do ecossistema
9. Glossário
10. Referências

O que é o IDS

O IDS (Information Delivery Specification) é um padrão aberto desenvolvido pela buildingSMART International que define, de forma legível por máquina, quais informações são necessárias em um modelo BIM.¹

O IDS especifica entidades IFC, atributos, propriedades, materiais, classificações e relacionamentos que os elementos do modelo devem conter — permitindo a verificação automática de conformidade por ferramentas de validação.

Relação com o IFC e o BEP

O IDS não substitui o IFC — é complementar a ele. Enquanto o IFC é o formato de dados do modelo, o IDS especifica os requisitos que esse modelo deve atender.²

flowchart LR
    EIR["EIR\nEmployer's Information\nRequirements"]
    BEP["BEP\nBIM Execution Plan"]
    IDS["IDS\nInformation Delivery\nSpecification\n(.ids)"]
    IFC["IFC\nModelo BIM\n(.ifc)"]
    VAL["Ferramenta de\nValidação"]
    REL["Relatório\nPass ✓ / Fail ✗"]

    EIR -->|"fundamenta"| BEP
    EIR -->|"gera"| IDS
    BEP -->|"referencia"| IDS
    IFC -->|"verificado contra"| VAL
    IDS -->|"define requisitos para"| VAL
    VAL -->|"gera"| REL

IDS vs MVD

Estrutura do arquivo IDS

Um arquivo .ids é um documento XML com estrutura hierárquica bem definida.³

graph TD
    A["<ids>\nRaiz do documento"]
    B["<info>\nMetadados"]
    C["<specifications>\nLista de regras"]
    D["<specification>\nRegra individual *"]
    E["<applicability>\nFiltro — a quem se aplica"]
    F["<requirements>\nExigências — o que é obrigado"]
    G["facets de filtro\n(Entity, Attribute,\n Property, Material, \nClassification, PartOf)"]
    H["facets de requisito\n(Entity, Attribute,\n Property, Material, \nClassification, PartOf)"]

    A --> B
    A --> C
    C --> D
    D --> E
    D --> F
    E --> G
    F --> H

    style D fill:#697282,stroke:#f0b429,color:#f0b429
    style G fill:#5b6b82,stroke:#4da6ff,color:#4da6ff
    style H fill:#6a897b,stroke:#34d399,color:#34d399

* Um arquivo IDS pode conter N specifications independentes, cada uma com seu próprio escopo e conjunto de requisitos.

Elementos da estrutura

<ids> — Raiz

Elemento raiz do documento. Contém o namespace buildingSMART e agrupa todas as especificações do projeto ou contrato.

<info> — Metadados

Informações sobre o próprio arquivo IDS: título, versão, autor, data e descrição. Não afeta a lógica de validação, mas é essencial para rastreabilidade e gestão documental.

<specification> — Unidade fundamental

A unidade central do IDS. Cada specification é uma regra independente que combina:

• <applicability> — define quais elementos IFC são alvo da verificação (filtro)
• <requirements> — define o que esses elementos devem conter para passar na validação

Exemplo de arquivo IDS comentado

<!-- Arquivo IDS mínimo — um requisito de exemplo -->
<ids xmlns="http://standards.buildingsmart.org/IDS">

  <info>
    <title>Requisitos BIM — Projeto Executivo</title>
    <version>1.0</version>
    <author>equipe.bim@construtora.com.br</author>
    <date>2025-06-01</date>
  </info>

  <specifications>

    <specification
      name="Paredes devem ter resistência ao fogo"
      ifcVersion="IFC4">

      <!-- A QUEM SE APLICA? (filtro) -->
      <applicability>
        <entity>
          <name><simpleValue>IfcWall</simpleValue></name>
        </entity>
      </applicability>

      <!-- O QUE É EXIGIDO? (requisito) -->
      <requirements>
        <property dataType="IFCLABEL">
          <propertySet>
            <simpleValue>Pset_WallCommon</simpleValue>
          </propertySet>
          <baseName>
            <simpleValue>FireRating</simpleValue>
          </baseName>
        </property>
      </requirements>

    </specification>

  </specifications>
</ids>

Applicability vs Requirements

Em uma specification IDS, <applicability> e <requirements> cumprem papéis diferentes e complementares. O primeiro define a quais elementos IFC a regra se aplica; o segundo define **quais regras os elementos selecionados devem seguir

** para serem considerados conformes.

Em termos práticos, applicability funciona como um filtro de seleção, enquanto requirements funciona como um conjunto de verificações executadas somente sobre os elementos filtrados. Assim, um elemento fora do filtro não falha na regra; ele simplesmente não é avaliado por ela.

flowchart LR
    subgraph AP["<applicability> — FILTRO"]
        direction TB
        A1["Quais elementos IFC\nsão alvo desta regra?"]
        A2["Condição AND:\ntodos os facets devem\nser verdadeiros"]
        A3["Elementos que não\nsatisfazem o filtro\nsão IGNORADOS pela regra"]
        A1 --> A2 --> A3
    end

    subgraph RQ["<requirements> — EXIGÊNCIAS"]
        direction TB
        R1["O que os elementos\nfiltrados devem conter?"]
        R2["Cada requisito é verificado\nindividualmente"]
        R3["Falha em qualquer requisito\ngera resultado FAIL\npara aquele elemento"]
        R1 --> R2 --> R3
    end

    AP -->|"elementos selecionados"| RQ

Facets — os tipos de requisito

Facets são os blocos de construção do IDS.³ Cada facet representa um aspecto diferente de um elemento IFC que pode ser usado tanto em <applicability> (para filtrar) quanto em <requirements> (para exigir).

O IDS 1.0 define 6 facets:

Tabela de facets

Restrições de valor

Cada facet pode usar diferentes formas de restrição para o valor esperado:

Atributo cardinality

O elemento <requirements> suporta o atributo cardinality para definir a natureza de cada requisito:

Exemplos práticos

Exemplo 1 — Espaços com programa de necessidades

Todo IfcSpace deve ter nome longo e área bruta preenchidos.⁴

<specification name="Espaços com uso definido" ifcVersion="IFC4">

  <applicability>
    <entity>
      <name><simpleValue>IfcSpace</simpleValue></name>
    </entity>
  </applicability>

  <requirements>

    <!-- Exige nome do espaço (LongName) -->
    <attribute>
      <name><simpleValue>LongName</simpleValue></name>
    </attribute>

    <!-- Exige área bruta no Quantity Set -->
    <property dataType="IFCAREAMEASURE">
      <propertySet>
        <simpleValue>Qto_SpaceBaseQuantities</simpleValue>
      </propertySet>
      <baseName>
        <simpleValue>GrossFloorArea</simpleValue>
      </baseName>
    </property>

  </requirements>
</specification>

Exemplo 2 — Portas com código de classificação Uniclass 2015

Toda IfcDoor deve ter um código Uniclass 2015 iniciado em Pr_25 (padrão regex).⁴

<specification name="Classificação obrigatória em portas" ifcVersion="IFC4">

  <applicability>
    <entity>
      <name><simpleValue>IfcDoor</simpleValue></name>
    </entity>
  </applicability>

  <requirements>
    <classification>
      <system>
        <simpleValue>Uniclass2015</simpleValue>
      </system>
      <!-- Aceita qualquer código que comece com Pr_25 -->
      <value>
        <xs:restriction base="xs:string">
          <xs:pattern value="Pr_25.*"/>
        </xs:restriction>
      </value>
    </classification>
  </requirements>

</specification>

Exemplo 3 — Vigas de concreto com resistência ao fogo por enumeração

IfcBeam com material Concreto deve ter FireRating igual a EI30, EI60 ou EI90.⁴

<specification name="FireRating em vigas estruturais de concreto">

  <!-- FILTRO: apenas vigas de concreto -->
  <applicability>
    <entity>
      <name><simpleValue>IfcBeam</simpleValue></name>
    </entity>
    <material>
      <value><simpleValue>Concreto</simpleValue></value>
    </material>
  </applicability>

  <!-- REQUISITO: FireRating com valor controlado -->
  <requirements>
    <property dataType="IFCLABEL">
      <propertySet>
        <simpleValue>Pset_BeamCommon</simpleValue>
      </propertySet>
      <baseName>
        <simpleValue>FireRating</simpleValue>
      </baseName>
      <!-- Lista de valores aceitos -->
      <value>
        <xs:restriction base="xs:string">
          <xs:enumeration value="EI30"/>
          <xs:enumeration value="EI60"/>
          <xs:enumeration value="EI90"/>
        </xs:restriction>
      </value>
    </property>
  </requirements>

</specification>

Fluxo de uso do IDS

flowchart TD
    S1["📋 1. Mapear requisitos de \n informação Contratante identifica dados \nnecessários\npor elemento, fase e finalidade"]
    S2["🛠️ 2. Criar o arquivo IDS\nUsando editor visual ou XML\nDefine specifications, applicability e requirements"]
    S3["📤 3. Distribuir o IDS\nPublicado no CDE e referenciado\nno BEP como requisito contratual"]
    S4["🏗️ 4. Modelar conforme o IDS\nEquipes inserem os dados exigidos\nnos modelos IFC durante o projeto"]
    S5{"5. Validar modelo\nFerramenta processa IFC contra IDS\nPor elemento e por specification"}
    S6["✅ PASS\nElemento atende todos\nos requisitos da specification"]
    S7["❌ FAIL\nElemento identificado no relatório\ncom o requisito específico não atendido"]
    S8["🔄 6. Corrigir e re-validar\nEquipe corrige o modelo\ne valida novamente"]
    S9["📊 Entrega aprovada\nConformidade total\nregistrada no CDE"]

    S1 --> S2 --> S3 --> S4 --> S5
    S5 -->|"elemento conforme"| S6
    S5 -->|"elemento não conforme"| S7
    S7 --> S8 --> S4
    S6 --> S9

Quando usar o IDS no ciclo de vida BIM

Ferramentas do ecossistema

Criação e edição de arquivos IDS

Validação de modelos IFC contra IDS

Recursos e referências oficiais

Glossário

Referências