bSDD no BIM: classes, propriedades, IFC, IDS e governança

Entenda em profundidade como o bSDD estrutura classes, propriedades e relações, como se integra a IFC e IDS e como governar semântica, versões e requisitos em fluxos openBIM.

Confira!

bSDD — buildingSMART Data Dictionary — é o serviço da buildingSMART International para distribuir, relacionar e tornar reutilizáveis definições de dados do ambiente construído. Em termos práticos, ele funciona como uma camada de semântica governada entre requisitos, modelos, classificações, propriedades e sistemas digitais.

O problema que essa camada resolve é mais profundo do que padronizar nomes. Em projetos BIM, duas equipes podem trocar um arquivo tecnicamente válido e ainda interpretar de forma diferente o significado de uma propriedade. Um software pode chamar um atributo de FireRating; outro pode usar “Resistência ao fogo”; uma biblioteca corporativa pode empregar um terceiro nome. Mesmo quando os rótulos parecem equivalentes, ainda restam perguntas essenciais: qual é a definição formal? qual unidade se aplica? quais valores são aceitos? a propriedade pertence a qual contexto? qual versão do conceito foi utilizada? quem é responsável por sua governança?

Quando essas respostas ficam implícitas, a interoperabilidade é apenas sintática: os sistemas conseguem transferir dados, mas não necessariamente entendem o mesmo conceito. O bSDD atua justamente nessa fronteira. Ele fornece identificadores persistentes, definições, classes, propriedades, relações, valores permitidos e metadados que podem ser consumidos por ferramentas e referenciados em workflows openBIM.

Isso não significa que bSDD substitua IFC, IDS, NBR 15965, Uniclass, ETIM ou qualquer outro sistema. Cada componente resolve um problema diferente. IFC estrutura e transporta dados; IDS expressa requisitos verificáveis; classificações organizam conceitos segundo uma lógica própria; bSDD permite distribuir e referenciar esses conceitos de maneira semanticamente consistente.

Para organizações que pretendem automatizar requisitos de informação, model checking, bibliotecas corporativas, integração com ativos ou handover digital, essa distinção é decisiva. Sem uma camada semântica estável, cada projeto tende a recriar propriedades, nomenclaturas e regras de mapeamento. Com uma estratégia bem governada, requisitos, modelos e sistemas passam a apontar para os mesmos conceitos por identidade — e não apenas por texto.

O problema real: interoperabilidade de arquivo não é interoperabilidade de significado

Grande parte dos problemas de informação em BIM não ocorre porque o arquivo não abre. O arquivo abre, os objetos aparecem e as propriedades são visíveis. A falha acontece porque o mesmo dado pode ser interpretado de maneiras diferentes ao longo da cadeia.

Considere uma porta corta-fogo. Em um fluxo pouco governado, um projetista pode registrar uma propriedade chamada “RF”, outro “FireRating”, um terceiro “Resistência ao fogo” e um fornecedor “Classe RF”. Algumas propriedades podem trazer valores em minutos; outras, códigos textuais; outras ainda podem misturar classificação do produto com desempenho exigido pelo projeto. Para um leitor humano, talvez seja possível inferir o significado. Para uma rotina de validação, um CDE, um sistema de ativos ou uma API, essa inferência é frágil.

O problema pode ser resumido em quatro níveis:

Nível	Pergunta	Falha típica quando não há governança
rótulo	como o dado é chamado?	nomes, idiomas e abreviações divergentes
significado	o que o dado representa?	termos parecidos usados com sentidos diferentes
estrutura	como o dado deve ser representado?	tipo de dado, unidade ou enumeração incompatível
identidade	como os sistemas reconhecem que é o mesmo conceito?	comparação por texto, mapeamentos manuais e duplicidade

O bSDD atua principalmente no quarto nível e reforça os demais. Em vez de depender apenas do texto apresentado ao usuário, o workflow pode utilizar um URI identificador associado ao conceito. O rótulo pode ser traduzido ou apresentado de forma diferente pelo software, mas a identidade semântica continua a mesma.

Essa abordagem é especialmente importante em ambientes nos quais a informação atravessa várias fronteiras: ferramenta de autoria → IFC → CDE → verificação IDS → orçamento → procurement → execução → comissionamento → AIM/CMMS. Se cada etapa reconstruir o significado a partir de nomes livres, a perda de consistência é praticamente inevitável.

O que é o bSDD — e o que ele não é

A buildingSMART define o bSDD como um serviço de distribuição de dicionários de dados publicados por organizações independentes. Isso produz uma consequência importante: a buildingSMART governa a plataforma, mas não se torna autora de todo o conteúdo hospedado nela.

Um dicionário pode representar uma classificação internacional, um padrão nacional, um vocabulário setorial, uma ontologia de domínio ou um conjunto corporativo de definições. Cada publicador permanece responsável pela qualidade, manutenção, versão e finalidade de seu conteúdo.

bSDD é um serviço, não uma classificação universal

Não existe uma única taxonomia “bSDD” que todos os projetos devam adotar. O serviço pode conter múltiplos dicionários, inclusive com estruturas e objetivos diferentes. A utilidade está em permitir que esses conceitos sejam descobertos, referenciados e relacionados de forma consistente.

Isso evita dois extremos ruins. O primeiro é obrigar toda a cadeia a abandonar classificações consolidadas para usar uma única estrutura universal. O segundo é permitir que cada projeto crie termos isolados sem qualquer possibilidade de equivalência. O bSDD cria uma camada intermediária: sistemas diferentes podem continuar existindo, mas passam a ter mecanismos para relacionar conceitos e identificá-los de forma não ambígua.

bSDD não substitui a fonte normativa ou institucional

Se uma organização utiliza NBR 15965, Uniclass, ETIM ou outro sistema, o requisito contratual continua dependendo da fonte oficial e da versão aplicável. O fato de determinado conteúdo estar disponível no bSDD não transforma automaticamente esse conteúdo em norma, obrigação contratual ou especificação de projeto.

A decisão de adotar um conceito precisa considerar autoria, status, versão, território, finalidade e aplicabilidade. Em contratos de engenharia, o dicionário deve ser tratado como fonte de referência de dados, não como substituto de requisitos técnicos.

bSDD não valida mérito técnico

Uma propriedade semanticamente bem definida ainda pode possuir um valor tecnicamente incorreto. O bSDD ajuda a esclarecer “qual propriedade é esta” e “como ela é estruturada”; não decide se o valor informado é adequado para a solução de engenharia.

Por exemplo, um workflow pode reconhecer de forma inequívoca a propriedade de tensão nominal de um equipamento. Ainda assim, é a engenharia que precisa decidir se a tensão especificada atende ao sistema, à seletividade, ao fabricante, às condições de operação e ao projeto elétrico.

Estrutura do bSDD: Dictionary, Class, Property e relações

A estrutura técnica do bSDD é deliberadamente orientada a conceitos reutilizáveis. Entre os elementos centrais estão Dictionary, Class, Property, ClassProperty, ClassRelation, AllowedValue e PropertyRelation.

Dictionary: o contexto de governança

Um Dictionary é o contêiner lógico de um conjunto de definições publicado por uma organização. Ele estabelece contexto, autoria e versão. A mesma palavra pode aparecer em dicionários diferentes com significados ou estruturas distintas; por isso, o dicionário faz parte da identidade do conceito.

Na prática, não basta saber que uma classe se chama “Pump”. É necessário saber de qual dicionário, organização e versão ela vem. Isso é o que permite distinguir um conceito internacional, um vocabulário de fabricante, uma classificação nacional ou uma taxonomia corporativa.

Class: o conceito de objeto, categoria ou entidade de domínio

Uma Class representa um conceito categorizável no dicionário. Dependendo do conteúdo publicado, pode representar elemento construtivo, sistema, espaço, material, equipamento ou outra categoria relevante.

Classes podem possuir relações hierárquicas ou semânticas com outras classes. Essas relações são particularmente úteis quando duas taxonomias não têm a mesma estrutura, mas precisam ser correlacionadas.

Property: a característica reutilizável

Uma Property representa uma característica que pode ser aplicada a classes. O valor real está nos metadados: definição, tipo de dado, unidade, valores permitidos e demais restrições. A propriedade deixa de ser apenas um campo de texto e passa a possuir uma identidade que software e integrações podem reconhecer.

ClassProperty: contexto importa

Uma das distinções técnicas mais relevantes é que a propriedade pode existir de forma independente e adquirir regras adicionais quando associada a uma classe. O relacionamento ClassProperty permite contextualizar como aquela propriedade deve ser usada em determinado conceito.

Isso resolve uma situação comum em engenharia: a mesma característica pode existir em várias classes, mas com restrições diferentes. Uma propriedade “Tipo de alimentação”, por exemplo, pode ser reutilizada em múltiplos equipamentos, enquanto valores permitidos ou requisitos de preenchimento podem variar conforme a classe.

AllowedValue e vocabulário controlado

Quando uma propriedade admite um conjunto fechado de valores, AllowedValue reduz variações de escrita e interpretação. Em vez de permitir “Sim”, “S”, “Yes”, “Y”, “Verdadeiro” ou campos livres, o dicionário pode estabelecer valores controlados.

Isso melhora filtros, validação e integração, mas exige cuidado. Um conjunto de valores só deve ser fechado quando o domínio realmente puder ser representado dessa forma. Enumerações mal projetadas tornam-se uma nova fonte de incompatibilidade.

Relações conectam conceitos sem apagar suas origens

ClassRelation e PropertyRelation permitem conectar conceitos. O ponto não é “fundir” classificações diferentes, mas declarar relações que possam ser interpretadas por ferramentas e mantidas sob governança.

Esse recurso é central para ambientes multinacionais ou multissetoriais. Uma organização pode manter sua estrutura corporativa e, ao mesmo tempo, relacionar determinados conceitos a classes de um sistema externo. A equivalência pode ser total, parcial, hierárquica ou apenas associativa — e precisa ser tratada com precisão.

Elemento	Função principal	Pergunta de governança
Dictionary	agrupar definições sob uma organização e versão	quem publica e mantém?
Class	representar um conceito/categoria	o que exatamente este conceito significa?
Property	representar uma característica reutilizável	qual dado está sendo descrito?
ClassProperty	contextualizar a propriedade na classe	como essa propriedade se aplica aqui?
AllowedValue	controlar domínio de valores	quais valores são permitidos?
Relations	conectar conceitos e propriedades	como este conceito se relaciona a outro?

URI: a peça que transforma rótulo em identidade semântica

Para workflows computacionais, o recurso mais importante do bSDD não é o nome exibido na tela, mas o URI que identifica o conceito.

A documentação técnica da buildingSMART mostra que referências bSDD podem ser transportadas para IFC e IDS por meio de URIs. O URI funciona como uma chave estável para que ferramentas saibam qual classe ou propriedade está sendo invocada, independentemente do idioma ou do rótulo apresentado ao usuário.

Isso muda a lógica de integração. Sem URI, uma aplicação tenta responder: “a propriedade que recebi se chama igual à propriedade que eu esperava?”. Com URI, a pergunta passa a ser: “esta propriedade aponta para o mesmo conceito que o requisito especificou?”.

Código, nome e URI não são a mesma coisa

Elemento	Função
nome	apresentação humana, podendo ser traduzida
código	identificador legível usado no próprio dicionário ou dataset
URI	identidade global para referência e integração

Essa separação permite que o mesmo conceito seja apresentado em português, inglês ou outro idioma sem perder sua identidade. É especialmente útil em projetos internacionais e em organizações que precisam oferecer interfaces localizadas sem multiplicar propriedades equivalentes.

Por que copiar apenas o texto destrói rastreabilidade

Um erro comum é consultar um dicionário, copiar o nome da propriedade para uma planilha ou template e descartar o identificador. Isso mantém aparência de padronização, mas rompe o vínculo com a fonte.

Depois de alguns meses, ninguém consegue responder com segurança de qual dicionário veio a definição, qual versão era aplicável ou se houve mudança. A organização volta a depender de interpretação manual — exatamente o problema que a semântica estruturada deveria evitar.

Semântica não é apenas nomenclatura. Dois campos com nomes iguais podem representar conceitos diferentes; dois rótulos distintos podem apontar para o mesmo conceito. Preservar o URI permite controlar a identidade sem depender apenas do texto.

bSDD, IFC, IDS e classificação: como as peças realmente se encaixam

Essas tecnologias são frequentemente citadas juntas, mas seu papel precisa ser separado para evitar arquiteturas confusas.

Componente	Resolve principalmente	Exemplo
IFC	estrutura e intercâmbio do modelo	objeto, propriedade, relação, classificação
IDS	requisito de informação verificável	equipamento deve ter TAG e fabricante
bSDD	identidade e definição semântica	qual conceito corresponde à propriedade “fabricante”
classificação	organização do universo de conceitos	código de sistema, elemento ou produto
CDE	gestão de estado, versão e fluxo da informação	WIP, shared, published, archived

IFC: onde a informação viaja

IFC possui entidades para representar objetos, propriedades, classificações e relações. A documentação da buildingSMART define mecanismos para associar referências externas utilizando estruturas como IfcClassification, IfcClassificationReference e IfcRelAssociatesClassification.

Quando o bSDD participa desse processo, o arquivo IFC deixa de transportar apenas um rótulo e pode preservar uma referência ao conceito externo. Para propriedades, a integração também permite associar o identificador semântico à informação representada no dataset.

O ganho não é cosmético. A referência pode ser utilizada posteriormente por ferramentas de validação, classificação, busca ou integração para reconhecer a origem do conceito.

IDS: onde o requisito se torna computável

IDS responde a outra pergunta: qual informação precisa existir para determinado conjunto de objetos?

Uma especificação IDS pode selecionar objetos por entidade, classificação ou outras facetas e exigir propriedades, atributos, materiais ou relações. Quando a propriedade exigida possui URI bSDD, a especificação deixa de depender exclusivamente do nome textual.

Exemplo conceitual:

o requisito aplica-se a equipamentos de climatização destinados ao handover;
cada equipamento deve possuir TAG, fabricante, modelo e código do ativo;
as propriedades podem ser referenciadas por conceitos governados;
o modelo IFC transporta os valores;
o verificador IDS compara a entrega com a especificação;
a evidência de conformidade alimenta o processo de aceite.

A automação é mais confiável porque requisito e modelo compartilham uma identidade semântica explícita.

Classificação: onde os conceitos são organizados

Um sistema de classificação estabelece estrutura, códigos e regras de organização. O bSDD pode distribuir ou relacionar classificações, mas não substitui o sistema nem sua governança.

Para uma organização brasileira, isso é particularmente importante ao lidar com a classificação da informação em BIM e a NBR 15965, além de outras referências aplicáveis. O projeto deve declarar qual sistema e versão são adotados. O bSDD pode apoiar a camada digital de referência e mapeamento, mas a especificação contratual precisa continuar clara sobre a fonte normativa ou institucional escolhida.

IFC, IDS e bSDD cumprem funções diferentes. IFC transporta a informação, IDS formaliza requisitos verificáveis e bSDD fornece identidade e definição semântica para conceitos que atravessam esses fluxos. A interoperabilidade melhora quando essas funções são conectadas sem serem confundidas.

Um exemplo ponta a ponta: equipamento de climatização do requisito ao AIM

A melhor forma de entender o bSDD é observar a trajetória de uma informação ao longo do empreendimento.

Considere uma unidade de tratamento de ar que precisa chegar ao sistema de gestão de ativos com dados mínimos para manutenção. O contratante exige TAG, fabricante, modelo, número de série, vazão nominal e código do ativo.

1. O requisito nasce na necessidade de operação

O AIR ou outro requisito de informação define quais dados são necessários para operar e manter o equipamento. Nesse estágio, a organização precisa decidir não apenas quais campos existem, mas como cada campo será semanticamente identificado.

Se “Fabricante” for apenas texto em uma planilha, cada fornecedor pode reinterpretar o campo. Se ele estiver vinculado a um conceito governado, há uma referência única para a propriedade.

2. O requisito é transformado em especificação verificável

O IDS pode representar quais equipamentos são aplicáveis e quais propriedades devem existir. Para campos estruturados, os URIs dos conceitos podem ser incorporados como referência semântica.

3. A equipe de autoria recebe um template governado

A biblioteca BIM, o template ou plugin de autoria pode oferecer as propriedades corretas já associadas aos conceitos adotados. O modelador não precisa criar manualmente um parâmetro chamado “Fabricante_2” porque “Fabricante” já estava ocupado por outra família.

4. O IFC preserva a informação e suas referências

Na exportação, as propriedades precisam ser mapeadas corretamente para IFC. O objetivo não é apenas visualizar valores, mas preservar a estrutura que permitirá ao receptor reconhecer o conceito.

5. O model checking mede conformidade

O verificador IDS compara o modelo com a especificação. A ausência de fabricante, TAG ou código do ativo aparece como não conformidade objetiva.

6. O aceite verifica utilidade, não apenas presença

A conformidade informacional não substitui engenharia. Ainda é necessário confirmar se os dados estão corretos, se o equipamento instalado corresponde ao modelo e se a informação está em condição de uso operacional.

7. O AIM recebe dados com origem rastreável

Na transição para operação, o dado pode ser levado ao AIM, CMMS, EAM ou outra plataforma. O benefício do bSDD aparece quando a integração não precisa redescobrir o que cada coluna significa. A identidade do conceito pode acompanhar a informação.

Esse encadeamento cria uma linha de rastreabilidade:

necessidade operacional → requisito → conceito semântico → propriedade no modelo → IFC → verificação IDS → aceite → AIM.

Sem essa cadeia, handover digital tende a se transformar em saneamento manual de planilhas no final do projeto.

Versionamento, status e uso contratual

Semântica só é confiável quando existe controle de mudança. A buildingSMART trata os dicionários com ciclo de vida e estados. Conteúdo pode ser publicado inicialmente para revisão e, quando estabilizado, assumir um estado ativo. Versões posteriores podem coexistir sem apagar o histórico.

Esse modelo é importante para contratos de engenharia porque uma propriedade pode manter o mesmo nome enquanto sua definição ou estrutura muda em uma nova versão.

Baseline semântica do projeto

Controle	Exemplo de evidência
dicionário	código/nome da fonte adotada
organização publicadora	responsável pela definição
versão	versão congelada para o contrato ou fase
status	preview, active ou condição aplicável
URI	identificador dos conceitos usados
data de adoção	marco da baseline
regra de mudança	quem pode aprovar migração de versão

A decisão entre “fixar versão” e “sempre usar a versão mais recente” precisa ser explícita. Para uma biblioteca experimental, acompanhar atualizações pode ser aceitável. Para um requisito contratual, mudar silenciosamente de dicionário durante a execução pode alterar o objeto da entrega.

Versionamento semântico também precisa de baseline. Quando um dicionário participa de requisitos contratuais, a versão adotada deve permanecer rastreável; mudanças posteriores precisam de avaliação de impacto sobre IDS, templates, IFC e critérios de aceite.

Rebaseline semântico precisa de Engineering Change Management

Se uma nova versão modifica definição, unidade, enumeração ou relação de um conceito usado no projeto, a mudança deve ser tratada como alteração controlada. O impacto pode atingir IDS, templates, famílias, regras de exportação, modelos já produzidos, integrações e critérios de aceite.

A governança precisa identificar o que mudou, quais requisitos e modelos usam o conceito, se a migração é necessária, quais entregas devem ser revalidadas e qual evidência registra a decisão. Essa lógica se conecta diretamente ao Engineering Change Management (ECM): a semântica deixa de ser convenção informal de modelagem e passa a ser um ativo de informação controlado.

Qualidade dos dicionários: publicar não significa automaticamente estar apto ao seu projeto

A buildingSMART mantém regras de estrutura e mecanismos de verificação de conteúdo, mas os dicionários são governados por seus publicadores. Portanto, a organização usuária precisa fazer sua própria avaliação antes de adotar uma fonte como baseline.

Critérios técnicos para selecionar um dicionário

Critério	Questão a verificar
autoridade	quem é o publicador e qual sua legitimidade no domínio?
escopo	cobre os objetos e propriedades do caso de uso?
definição	os conceitos são claros e não circulares?
tipo de dado	a estrutura é compatível com o uso pretendido?
unidades	estão normalizadas e coerentes com o projeto?
valores permitidos	são completos e tecnicamente válidos?
versão/status	a fonte está suficientemente estável?
idioma	há rótulos adequados sem perder identidade?
mapeamento	existem relações úteis com IFC ou outros sistemas?
manutenção	há evidência de governança contínua?

A presença de um selo de verificação ou estado estável aumenta confiança, mas não elimina a necessidade de conferir aplicabilidade ao território, disciplina e contrato.

Dicionário corporativo não deve virar catálogo de exceções do projeto

Uma organização pode desejar publicar ou manter conceitos próprios. O risco é transformar o dicionário em repositório de nomes específicos de projeto, produtos, fornecedores ou decisões temporárias.

Um bom conceito corporativo precisa ser reutilizável. Se só faz sentido em um único contrato, talvez deva permanecer como dado do projeto, não como conceito corporativo permanente.

bSDD em EIR, BEP, TIDP/MIDP e critérios de aceite

O maior valor aparece quando a semântica deixa de ser assunto apenas da equipe BIM e passa a fazer parte do sistema de gestão da informação.

EIR: declarar a fonte dos conceitos

Os requisitos de informação BIM, especialmente o EIR, podem definir quais classificações, propriedades, dicionários e versões devem ser usados para determinados usos. Em vez de exigir genericamente “padronização de parâmetros”, o requisito pode apontar para fontes e regras de referência claras.

BEP: explicar como a equipe implementará a semântica

O BEP BIM deve responder como os conceitos serão incorporados à autoria, IFC, IDS, validação e controle de mudanças. Isso inclui templates, plugins, mapeamentos, responsabilidade por novos conceitos e processo de correção de inconsistências.

TIDP e MIDP: planejar entregas que dependem de dicionários

Se uma entrega depende de propriedades governadas, o plano precisa considerar quando o dicionário e a versão estarão estabilizados. O MIDP/TIDP não deveria prever validação IDS em um marco se a taxonomia ainda estiver mudando sem baseline.

A dependência pode ser tratada como parte da rede de informação: dicionário aprovado → template configurado → modelo produzido → IFC exportado → IDS verificado → entrega aceita.

Critérios de aceite: separar estrutura, semântica e mérito técnico

Um processo maduro pode organizar os critérios de aceite em engenharia em cinco camadas: estrutura, semântica, completude, validade e mérito técnico. As quatro primeiras podem ser parcialmente automatizadas. A última continua dependendo de análise de engenharia.

Integração por API: quando bSDD sai da planilha e entra no ecossistema digital

O bSDD foi concebido para consumo por software. Isso permite que ferramentas consultem classes e propriedades, recuperem definições, apresentem rótulos localizados e utilizem os identificadores em processos automatizados.

A API transforma o dicionário em um serviço de referência corporativo. Em vez de copiar periodicamente listas de parâmetros para planilhas, uma aplicação pode buscar os conceitos diretamente da fonte governada. Quando essa camada precisa conversar com CDE, portais, data lakes ou sistemas de ativos, a integração de sistemas, APIs e conectores passa a fazer parte da própria arquitetura de informação.

Arquitetura de integração típica

Uma organização pode montar uma arquitetura em que o portal de requisitos consulta conceitos bSDD; o gerador de IDS utiliza os mesmos URIs; plugins de autoria oferecem propriedades controladas; o exportador IFC preserva o mapeamento; o model checker usa as referências para validar entregas; e o data lake ou plataforma de ativos mantém o URI como chave semântica.

O resultado é uma referência única de significado atravessando várias aplicações.

Cache e disponibilidade

Consumir uma API externa em tempo real para toda operação também exige arquitetura. Sistemas críticos podem precisar de cache local, sincronização de versões e comportamento definido para indisponibilidade do serviço.

O ponto importante é não transformar o cache em nova fonte de verdade sem controle. A cópia local deve preservar URI, versão, origem e data de sincronização.

Automação sobre dados ruins continua sendo automação ruim

O fato de existir uma API não significa que todos os conceitos devam ser importados indiscriminadamente. A organização precisa selecionar dicionários aprovados, limitar escopo e estabelecer governança. Caso contrário, o usuário recebe milhares de propriedades semanticamente corretas, mas irrelevantes ao seu processo.

Estratégia de implantação: do piloto à governança corporativa

A adoção mais eficaz começa por um fluxo em que a inconsistência semântica já produz custo mensurável.

Um bom piloto pode ser a entrega de dados de ativos de climatização, painéis elétricos, equipamentos de segurança eletrônica ou outro conjunto com propriedades bem definidas e necessidade real de integração.

1. Escolher um caso de uso que termine em decisão ou sistema

Evite começar com o objetivo abstrato de “implementar bSDD”. Escolha um problema: reduzir retrabalho no handover, automatizar checking de propriedades, padronizar bibliotecas corporativas ou integrar dados com CMMS.

2. Mapear o vocabulário existente

Inventarie propriedades, classificações, planilhas, templates e dicionários já usados. O objetivo é identificar duplicidades e ambiguidades, não substituir tudo imediatamente.

3. Selecionar conceitos e fontes

Pesquise dicionários existentes antes de criar novos termos. Avalie autoridade, versão, status e adequação ao caso de uso.

4. Construir uma matriz de mapeamento

Campo legado	Conceito adotado	URI	IFC/Pset	IDS	Sistema destino
Fabricante	conceito governado	URI	propriedade mapeada	obrigatório	CMMS
Modelo	conceito governado	URI	propriedade mapeada	obrigatório	CMMS
TAG	conceito governado	URI	propriedade mapeada	obrigatório	AIM
Vazão nominal	conceito governado	URI	propriedade mapeada	faixa/unidade	operação

Essa matriz se torna uma ponte entre engenharia, BIM, TI e operação.

5. Configurar autoria, IFC e IDS

A implementação precisa ser testada ponta a ponta. Não basta ver a propriedade dentro da ferramenta de autoria; é necessário confirmar como ela chega ao IFC e como o verificador IDS a interpreta.

6. Estabelecer indicadores

O piloto deve medir resultado. Indicadores podem incluir propriedades duplicadas eliminadas, não conformidades detectadas antes do handover, percentual de objetos mapeados semanticamente e redução de ajustes manuais na importação do sistema de ativos.

7. Formalizar governança antes de escalar

A expansão só deve ocorrer depois de definir responsabilidade pelo catálogo, critérios para novos conceitos, fontes autorizadas, política de versionamento, processo de change request, testes de interoperabilidade, depreciação e rastreabilidade até requisitos e templates.

Anti-padrões: como usar bSDD sem obter interoperabilidade real

Criar um dicionário novo para tudo. Se já existe uma definição adequada e governada, duplicá-la cria manutenção e mapeamento desnecessários.

Usar apenas nomes e ignorar URIs. Isso elimina a principal vantagem da identidade semântica e devolve o workflow à comparação textual.

Atualizar para a versão mais recente sem avaliar impacto. Mudanças podem alterar requisitos e mappings; contratos precisam de baseline.

Colocar termos de produto ou projeto em um dicionário corporativo. Conceitos específicos demais perdem reutilização e transformam o dicionário em catálogo de exceções.

Confundir propriedade bem definida com requisito bem definido. O bSDD pode esclarecer o significado de “fabricante”, mas não define sozinho quais objetos devem fornecer a informação, em qual marco ou com qual obrigatoriedade. Essa função pertence ao sistema de requisitos, podendo ser formalizada por IDS.

Automatizar sem testar exportação IFC. Uma propriedade correta na autoria pode ser perdida, renomeada ou mapeada incorretamente no intercâmbio. O teste precisa ocorrer no arquivo efetivamente contratado.

bSDD como parte da arquitetura de informação, e não apenas do BIM

Embora nasça no ecossistema openBIM, o valor do bSDD se amplia quando a organização pensa em arquitetura de dados.

Engenharia, procurement, obra, comissionamento e operação frequentemente utilizam vocabulários diferentes para o mesmo ativo. A mesma bomba pode possuir um código no modelo, outro no ERP, outro no fornecedor e outro no CMMS. O problema não será resolvido apenas acrescentando mais colunas.

Uma arquitetura semântica permite declarar que diferentes identificadores operacionais se referem ao mesmo conceito de classe e que determinadas propriedades possuem identidade estável. Isso facilita integração sem exigir que todos os sistemas usem o mesmo banco de dados ou a mesma aplicação.

O bSDD, portanto, pode atuar como uma camada de referência semântica dentro de uma estratégia maior de gestão da informação. Ele não substitui master data management, catálogo de ativos, CDE ou integração de sistemas, mas fornece um mecanismo de definição compartilhada que reduz ambiguidades entre essas camadas.

Essa visão é particularmente relevante para organizações que desejam avançar de BIM como produção de modelos para BIM como infraestrutura de informação. O modelo deixa de ser o fim e passa a ser um dos sistemas que consomem e produzem dados governados.

Conclusão: o ganho do bSDD é transformar significado em dado controlável

O valor do bSDD não está em criar mais uma sigla no processo BIM. Ele está em resolver um problema estrutural: permitir que classes e propriedades sejam reconhecidas por identidade, definição, versão e relações, e não apenas por nomes digitados em diferentes ferramentas.

Quando essa camada é integrada a IFC e IDS, a cadeia de informação ganha rastreabilidade. Requisitos podem apontar para conceitos governados; ferramentas de autoria podem reutilizar as mesmas definições; o IFC preserva referências; verificadores podem avaliar conformidade; e sistemas de operação podem receber dados com menor necessidade de remapeamento manual.

Mas o benefício só aparece com governança. Dicionários precisam de autoria e versão claras; conceitos corporativos devem ser reutilizáveis; mudanças precisam ser controladas; mappings devem ser testados no intercâmbio real; e o aceite deve distinguir conformidade informacional de mérito técnico.

Em uma estratégia openBIM madura, bSDD não substitui IFC, IDS, CDE, classificação ou engenharia. Ele conecta semanticamente essas peças e ajuda a transformar o modelo em parte de uma arquitetura de informação consistente, verificável e reutilizável ao longo do ciclo de vida do ativo.

Referências técnicas

[1] BUILDINGSMART INTERNATIONAL. buildingSMART Data Dictionary (bSDD): service for sharing definitions for the built environment. Disponível em: buildingSMART International.

[2] BUILDINGSMART INTERNATIONAL. Data structure of bSDD: Dictionary, Class, Property, relations and allowed values. Disponível em: buildingSMART Technical.

[3] BUILDINGSMART INTERNATIONAL. Referencing bSDD in IDS and IFC. Disponível em: buildingSMART Technical.

Perguntas frequentes

O que é bSDD no BIM?

bSDD é o buildingSMART Data Dictionary, serviço da buildingSMART para distribuir e relacionar dicionários de dados com classes, propriedades, definições, identificadores e relações reutilizáveis em workflows openBIM.

bSDD é um padrão ou uma classificação?

Não. bSDD é um serviço. Ele pode hospedar e relacionar classificações, ontologias e dicionários publicados por organizações independentes, mas não substitui a fonte normativa ou institucional de cada sistema.

Qual a diferença entre bSDD e IFC?

IFC estrutura e transporta dados do modelo. bSDD fornece identidade e definição semântica para classes e propriedades que podem ser referenciadas nesses dados.

Qual a diferença entre bSDD e IDS?

IDS especifica quais informações determinados objetos precisam entregar e permite verificá-las. bSDD fornece conceitos governados e URIs que podem ser usados para tornar esses requisitos menos dependentes de nomes livres.

Por que o URI é importante no bSDD?

Porque o URI identifica o conceito de forma estável. O nome pode variar por idioma ou interface, mas ferramentas podem reconhecer que requisito e modelo se referem ao mesmo conceito pelo identificador.

bSDD substitui a NBR 15965?

Não. A NBR 15965 possui finalidade, estrutura e governança próprias. bSDD pode apoiar a distribuição ou o relacionamento digital de conceitos, mas não substitui a norma nem sua versão contratualmente aplicável.

Como bSDD ajuda no model checking?

Ao permitir que requisitos e modelos referenciem conceitos identificáveis, reduz ambiguidade na seleção de propriedades e melhora a previsibilidade de verificações automatizadas, especialmente em conjunto com IFC e IDS.

Uma empresa pode criar um dicionário corporativo no bSDD?

Sim, desde que o conteúdo seja governado e adequado à finalidade do serviço. Conceitos corporativos devem ser reutilizáveis; termos específicos demais de um único produto ou projeto tendem a ser inadequados como vocabulário permanente.

Como controlar versões de bSDD em um contrato?

Registre dicionário, organização publicadora, versão, status e URIs adotados como baseline. Mudanças posteriores devem ter avaliação de impacto e aprovação, principalmente quando afetam IDS, templates, IFC ou critérios de aceite.

Por onde começar a implantar bSDD?

Comece por um caso de uso em que inconsistência de propriedades já gere retrabalho, como handover de ativos ou validação IDS. Mapeie o vocabulário atual, selecione conceitos, teste autoria→IFC→checking e só depois amplie o escopo.