IDS: transformar requisitos de informação em verificações do modelo

Este subartigo aprofunda openBIM: dos requisitos à modelagem e à verificação. O LOIN ajuda a decidir qual informação é necessária, para quem e quando. A Information Delivery Specification (IDS, especificação de entrega de informação) permite expressar parte desses requisitos de forma que um programa possa conferir os dados de um modelo IFC.

Uma IDS descreve a quais objetos uma exigência se aplica e que dados esses objetos devem apresentar. Ela é especialmente útil para propriedades, quantidades, classificações, materiais, atributos e relações. Seu foco é a informação alfanumérica estruturada, não a qualidade da geometria ou a aprovação técnica do projeto. O manual de 2024 apresenta exemplos do esquema IDS 0.9.6; para criar ou validar arquivos hoje, consulte o padrão final IDS 1.0 e o repositório oficial.

Da exigência escrita à entrega verificável

No fluxo descrito pelo manual, o contratante define os usos BIM e os dados que precisa receber. Esses requisitos são preparados em uma ferramenta de estruturação e exportados como IDS. A equipe responsável pela modelagem usa a especificação durante a autoria e a conferência do modelo. O arquivo IFC resultante pode então ser verificado pelas duas partes contra a mesma IDS.

A possibilidade de importar uma IDS para criar propriedades ou regras automaticamente depende do software e da versão implementada. A vantagem verificável do método é tornar explícito o pedido de informação e permitir testes repetíveis. Antes de adotar o fluxo, faça um piloto com um arquivo IDS e um IFC reais, verificando o resultado em ferramentas da equipe.

Dois exemplos de requisito

O primeiro exemplo pede que os espaços de um modelo tenham uma classificação, as áreas bruta e líquida de piso e um número de ambiente. O mesmo requisito pode ser limitado a espaços de uma categoria, de um pavimento ou com certa propriedade. A IDS precisa deixar claro quais espaços entram no conjunto e quais valores devem existir. Nomes de conjuntos e propriedades do exemplo do manual são ilustrativos; confira a versão IFC e o mapeamento acordado antes de reutilizá-los.

No segundo exemplo, todas as paredes devem informar LoadBearing e FireRating em Pset_WallCommon. Para as paredes em que LoadBearing é verdadeiro, FireRating deve pertencer a uma lista de valores permitidos, como ND, REI 30, REI 60, REI 90 ou REI 120. Assim, a obrigação geral e a condição específica podem ser descritas separadamente. A lista é apenas um exemplo de estruturação de dados; ela não define, por si, a resistência ao fogo exigida para um edifício.

Como uma IDS organiza o pedido

O arquivo IDS usa XML validado por um esquema XSD. Ele possui metadados gerais e uma ou mais especificações. Cada especificação reúne:

Parte	Função
Metadados	Identificar a especificação, a versão IFC e, quando útil, sua finalidade e instruções para pessoas.
Aplicabilidade	Selecionar os objetos aos quais a regra se aplica — por exemplo, todas as paredes ou apenas paredes portantes.
Requisitos	Definir os dados e valores que os objetos selecionados devem conter.

A combinação aplicabilidade + requisitos é central. “Exigir FireRating” não basta se não estiver claro em quais objetos, em qual conjunto de propriedades, com qual tipo de dado e quais valores aceitos. A especificação pode também registrar orientações legíveis por pessoas, pois a produção dos dados ainda exige decisões da equipe.

O manual descreve seis tipos de faceta para selecionar objetos ou declarar requisitos:

Faceta	O que pode descrever
Entity	Classe IFC e, quando pertinente, tipo predefinido.
Attribute	Atributo próprio da entidade, como Name.
Classification	Sistema de classificação e código associado.
Property	Conjunto, nome, tipo e valor de propriedade ou quantidade.
Material	Material associado ao objeto.
PartOf	Relação do objeto com outro, como sua inclusão em um pavimento.

Essas facetas podem ser combinadas. Para valores, o manual mostra valor simples, lista de valores permitidos, padrão de texto, intervalo numérico e comprimento mínimo, máximo ou exato. Uma convenção de nome, por exemplo, pode ser expressa por um padrão; uma propriedade numérica pode receber limites. Os trechos XML impressos nas páginas 125–133 pertencem à versão 0.9.6 e não devem ser copiados sem revisão para uma IDS 1.0.

IFC dá a estrutura; bSDD esclarece o significado

A IDS foi concebida para trabalhar de perto com o IFC. Quando uma especificação seleciona IfcWall e pede Pset_WallCommon.FireRating, ela se apoia em classes, conjuntos e relações do modelo. A verificação pode então localizar os objetos e ler seus dados de maneira consistente. Isso complementa as definições de intercâmbio e de geometria tratadas no subartigo sobre MVD.

A IDS também pode incluir um URI para uma classe, classificação ou propriedade disponível no buildingSMART Data Dictionary (bSDD). Esse identificador leva à definição do termo, suas relações e outros metadados. A IDS diz o que exigir e verificar; o dicionário ajuda as pessoas e aplicações a interpretar o que o termo significa. O URI deve apontar para o conceito e a versão pretendidos, sobretudo quando o requisito será usado contratualmente.

O que a IDS verifica — e o que fica fora

O manual compara IDS com planilhas, modelos de dados de produtos, LOIN, EIR, mvdXML e outras formas de especificar informações. A comparação publicada pela buildingSMART conclui que os métodos têm alcances diferentes. A IDS é uma boa escolha para requisitos alfanuméricos de modelos IFC, mas não substitui os documentos que definem finalidade, responsabilidades e decisões de projeto.

Uma IDS pode exigir que cada janela tenha uma propriedade que identifique o tipo de vidro. Ela não resolve sozinha se a janela de um determinado banheiro precisa de vidro opaco. Essa segunda pergunta requer localizar o ambiente, interpretar a regra aplicável e avaliar o projeto. Da mesma forma, a presença de uma propriedade não prova que o valor declarado está correto em campo. A verificação automática da entrega de dados deve ser acompanhada da análise técnica apropriada.

Ao escolher aplicações, consulte a lista de implementações IDS da buildingSMART como ponto de partida, mas teste as funções necessárias: criação, leitura, validação da IDS e conferência do IFC. As entradas da lista são informadas pelos próprios fornecedores e não equivalem a certificação. As ocorrências encontradas na verificação podem ser comunicadas pelo BCF, mantendo sua ligação com os objetos do modelo.

Uma especificação, várias formas de leitura

O mesmo requisito pode aparecer como XML, como tabela ou em um visualizador preparado para apresentar frases legíveis. Nas imagens do manual, a exigência para espaços aparece primeiro como estrutura de campos e depois como uma lista de verificações. A interface muda; a interpretação precisa continuar fiel à especificação.

Para um piloto, escolha um conjunto pequeno de objetos, traduza o requisito escrito para uma IDS, valide o arquivo, verifique um IFC de teste e compare o relatório com a intenção original. Se duas ferramentas interpretarem a mesma condição de forma diferente, resolva a divergência antes de usar o resultado como critério de aceitação.

Links diretos e fonte

As referências externas indicadas no trecho do manual foram substituídas por links: página oficial do IDS, repositório técnico com esquema e exemplos, implementações de software e comparação de métodos de requisitos de informação.

Tradução e adaptação editorial das páginas 123–134 de BIMcert Handbook: Basic Knowledge openBIM (2024), seção de Léon van Berlo e Simon Fischer. As cinco figuras dessa seção foram fornecidas pelo usuário. A sexta, sobre a ligação IFC–bSDD, vem da seção seguinte e foi incluída apenas para ilustrar uma relação mencionada na página 128. As quatro cópias idênticas dessa figura foram tratadas como uma única imagem. Todas aparecem sem a numeração impressa e têm versões separadas para os temas claro e escuro.