'Fire rating', 'resistência ao fogo', 'TRRF' — mesma propriedade com três nomes

O gestor da informação abre o modelo federado no fim da fase de projeto básico e quer rodar uma consulta simples: liste todas as vedações verticais externas cuja resistência ao fogo seja maior ou igual a 60 minutos. Uma pergunta que qualquer cliente vai fazer — pra dimensionar laudo de acessibilidade, pra cálculo de seguro contra incêndio, pra compatibilização com a NBR 14432 do corpo de bombeiros.

A consulta volta praticamente vazia. Não porque as paredes não têm a propriedade — elas têm. O problema é outro:

• A arquitetura botou a propriedade no Pset_WallCommon.FireRating, como texto livre ("60 min", "60min", "60 minutos", "60'").
• A estrutura botou no Pset customizado Pset_STR_Fire, como propriedade chamada Resistência ao fogo, tipo IfcText, com valores como "TRRF 60", "TRRF-60", "60 min".
• O projeto de vedações e fachada botou como TRRF (só a sigla), em Pset_Custom_Facade, tipo IfcLabel, com valores "60", "60min", "60 minutes".

Três disciplinas, três Property Sets, três nomes de propriedade, três tipos de dado, três convenções de valor. A mesma exigência técnica expressa de três formas incompatíveis dentro do mesmo modelo federado. Nenhuma consulta cross-disciplina roda. Nenhum dashboard fecha. Nenhum laudo automatizado é possível. O cliente pergunta e o BIM Manager responde "peraí, deixa eu ver com cada disciplina".

Isso não é problema de descuido individual. É problema de ausência de vocabulário controlado no processo de contratação. O EIR pediu a informação, mas não determinou o nome exato da propriedade, o Property Set, o tipo de dado, nem o dicionário de referência. Cada disciplina adotou o padrão default do software (Revit sugere FireRating, Tekla sugere outro, ARCHICAD sugere outro) e ninguém combinou.

A resposta canônica pra esse problema tem duas camadas complementares, ambas publicadas como padrão buildingSMART:

• IDS Property facet — específica formalmente o Property Set exato (propertySet), o nome exato da propriedade (name), o tipo de dado (dataType) e o valor esperado (value). Qualquer objeto que use outro Pset ou outro nome falha na verificação. Não há espaço pra "achei que era a mesma coisa".
• buildingSMART Data Dictionary (bSDD) — serviço público (bsdd.buildingsmart.org) que hospeda dicionários de classificações e propriedades com URI persistente. IDS Property facet pode referenciar diretamente o URI bSDD como fonte canônica do nome, do tipo de dado e dos valores permitidos. TRRF, FireRating e Resistência ao fogo deixam de ser preferência local — passam a ser aliases resolvidos contra um dicionário compartilhado e versionado.

O modelo federado não precisa que todo mundo escreva a propriedade com o mesmo nome no software de modelagem — precisa que na entrega em IFC a propriedade esteja sob o Pset canônico com o nome canônico. IDS + bSDD viabilizam esse controle.

1. 1

   Cliente pede uma consulta simples ('mostre todas as portas corta-fogo com resistência ≥ 60 min') e o resultado vem incompleto ou vazio

2. 2

   Dashboard de qualidade do modelo mostra propriedade 'preenchida' em 30% dos objetos mesmo quando cada disciplina jura que preencheu tudo

3. 3

   Cada disciplina tem seu 'jeito de fazer' — arquitetura no Pset_WallCommon, estrutura em Pset custom, fachada em outro Pset custom

4. 4

   Time gasta horas em reunião pra 'harmonizar propriedades' antes de cada entrega — porque ninguém combinou o nome antes

5. 5

   BIM Manager mantém planilha Excel de 'de/para' de propriedades ('quando arquitetura escreve X, é o que estrutura chama de Y')

6. 6

   Templates de família por disciplina/software geram Psets com nomes divergentes por default — e ninguém padroniza antes de modelar

7. 7

   EIR menciona propriedades exigidas ('a parede deve ter resistência ao fogo') mas sem indicar Pset, nome exato, tipo de dado ou dicionário

8. 8

   Consulta federada no Solibri/BIMcollab/ACC produz report de qualidade sofrível porque cada objeto tem valores em campos diferentes

9. 9

   Quando o cliente exporta o IFC pra o software de FM (facility management), metade das propriedades some ou vem duplicada porque não bate com o data template esperado

Causa 1 · EIR sem obrigação de Pset + name + dataType exatos. Requisitos escritos em prosa contratual não bastam. "A parede deve ter resistência ao fogo" precisa virar "Property facet · Pset_WallCommon · name=FireRating · dataType=IfcTimeMeasure em minutos · required" antes de sair do EIR. Se o requisito não chega no projetista com essa precisão, o projetista adota o default do software dele. Cada software tem um default diferente. O modelo federado paga a conta.

Causa 2 · Ausência de vocabulário canônico consultado antes de modelar. buildingSMART Data Dictionary (bSDD) existe desde 2019, hospeda Uniclass, IFC standard, ETIM, Minnd e dezenas de outros dicionários com URI persistente. Consultar o bSDD antes de decidir o nome de uma propriedade custaria dois minutos por família. Mas essa etapa não está no fluxo padrão da maioria das operações BIM brasileiras. Cada projetista inventa o nome no dia que precisa e canoniza pra si mesmo — sem base compartilhada.

Causa 3 · Templates de família importados com Psets default de software. Revit gera Psets nativos que não são os IFC canônicos. Tekla gera outros. ARCHICAD outros. Bibliotecas de família compradas de terceiros vêm com seus próprios Psets. A operação BIM raramente audita e padroniza esses templates antes de liberar pra produção — o que garante que cada projetista, no dia da entrega, exporte IFC com Pset "similar mas não igual" ao do vizinho.

Causa 4 · Confusão entre 'campo do software' e 'propriedade IFC'. No Revit, a propriedade aparece como "Fire Rating" na interface. No Tekla como "Fire resistance". No ARCHICAD como "TRRF" (customizado por template BR). O projetista pensa que está preenchendo "a mesma propriedade" — mas cada software mapeia esse campo pra Pset IFC diferente no export. Sem IDS Property facet obrigatório na entrega, essa divergência só é descoberta pelo gestor da informação depois.

Causa 5 · Falta de auditoria semântica no CDE. CDE recebe o IFC, arquiva, marca como "Shared". Ninguém roda verificação sistemática de coerência de Pset/name entre disciplinas. Ferramentas existem — Ifctester (BlenderBIM), IDS-Audit-tool, ACCA usBIM.IDS, Solibri — mas só entram no fluxo quando alguém explicitamente pede. Não é rotina.

• Análises técnicas viciadas. Simulação térmica, laudo de segurança contra incêndio, análise de acessibilidade, cálculo de orçamento — todas dependem de propriedades preenchidas com nome exato em Pset esperado. Modelo com propriedade "quase certa" produz análise "quase certa" — que perito rejeita e obra atrasa.
• Modelo federado inutilizável para FM. Cliente que assume o ativo precisa importar propriedades no CMMS/CAFM. Se cada disciplina usa Pset diferente pra mesma propriedade, o mapeamento CAFM quebra — perde-se anos de dado durante o handover.
• Impossibilidade de dashboard institucional. Empresa que quer BI cross-projeto (portfolio de obras, comparação de custos, análise histórica de performance) depende de vocabulário controlado. Sem isso, cada projeto vira ilha.
• Custo escondido de tradução manual. Toda vez que uma pergunta cross-disciplina aparece, o BIM Manager gasta horas fazendo a tradução manual. Esse custo não aparece na planilha do projeto, mas está lá — em salário do gestor e em atraso de decisão.
• Perda de confiança contratual. Cliente que audita descobre que metade das propriedades exigidas no EIR não está sob o nome esperado. A leitura contratual é: "não entregou" — mesmo que a informação esteja no modelo com outro nome.

Gravidade 3-4. Nome divergente é problema silencioso: o modelo funciona, o clash detection roda, o federated view abre. O dano aparece quando alguém precisa consultar semanticamente o modelo — e aí descobre que a informação está lá mas sob nomes diferentes. Gravidade 3 quando o projeto ainda está em conceito e há tempo pra padronização. Gravidade 4 quando o projeto está avançado, disciplinas divergiram e cada uma tem centenas de objetos preenchidos com convenção própria — migração retroativa é cara e propensa a erro.

O modelo entregue está em conformidade semântica quando:

• Toda propriedade que aparece no EIR está expressa em pelo menos uma IDS Property facet com propertySet, name e dataType declarados explicitamente. Cardinalidade required para exigências contratuais, optional para desejáveis, prohibited para o que o modelo não pode carregar (útil quando há legado a evitar).
• Vocabulário de referência é bSDD — cada Property facet e cada Classification facet resolve nome, tipo de dado e valores permitidos via URI persistente. Padrão canônico Coordenar: em projetos onde bSDD não tem dicionário público, criar dicionário institucional interno hospedado em bSDD privado (o serviço aceita dicionários proprietários com governança da própria empresa).
• Consulta cross-disciplina no modelo federado retorna resultado consistente — mesma pergunta, mesma resposta, independentemente de qual disciplina originou o objeto. Se a consulta retorna resultados distintos por disciplina, a specification IDS está incompleta ou o modelo está fora de conformidade.
• Meta de conformidade em regra buildingSMART: zero divergências semânticas entre disciplinas para propriedades exigidas no EIR. Não se aceita "95% harmonizado" — o critério é binário. Regra formal ISO ou buildingSMART não admite tolerância estatística.
• Referência a dicionário externo (Uniclass, ETIM, IfcClassification, data template ISO 23387) via URI bSDD, não via string livre. String livre é fonte silenciosa de divergência: qualquer letra maiúscula ou espaço extra quebra a resolução.

Curto prazo (semanas 1-4):

• Mapeamento das 10 propriedades mais críticas do EIR atual em formato IDS Property facet — Pset canônico, name exato, dataType, valores permitidos ou URI bSDD.
• Auditoria semântica do IFC atual: rodar Ifctester (BlenderBIM) ou IDS-Audit-tool com o IDS mínimo. Relatório baseline documenta a divergência inicial por disciplina.
• Publicar no CDE do projeto uma tabela de vocabulário canônico (Pset + name + dataType + URI bSDD) e comunicar às disciplinas: a partir do próximo marco, é essa a convenção da entrega.

Médio prazo (meses 2-4):

• Expandir o IDS Property facet pra cobrir 80% das propriedades exigidas no EIR. Priorizar propriedades com maior impacto (segurança contra incêndio, acessibilidade, propriedades estruturais críticas, eficiência energética).
• Consultar bSDD público e incorporar URIs canônicos quando existem. Onde não há dicionário público adequado, criar dicionário institucional interno em bSDD (o serviço aceita dicionários privados com governança da própria organização).
• Auditar bibliotecas de família (Revit, ARCHICAD, Tekla) e padronizar Psets de export em template institucional. Cada projetista puxa o template atualizado; ninguém exporta com convenção própria.
• Treinar equipe de projetistas em ler IDS Property facet e usar como guia de modelagem, não como surpresa de entrega.

Vocabulário divergente é problema recorrente quando não há disciplina institucional. Prevenção estrutural:

• Autoria de EIR sempre com mapeamento pra IDS Property facet. Cada propriedade escrita no EIR nasce com nota técnica indicando Pset, name, dataType, URI bSDD (quando existe). Advogado escreve linguagem contratual, BIM Manager escreve linguagem verificável em paralelo.
• Biblioteca institucional de IDS por tipologia + biblioteca institucional de Psets padronizados — versionadas em Git, distribuídas via template obrigatório. Cada novo projeto puxa a versão vigente. Convenções não são renegociadas por projetista individual.
• Auditoria semântica no CDE como estado formal — transição de "WIP" para "Shared" só é aceita após relatório IDS anexado com divergência semântica declarada. Governança faz parte do fluxo, não é etapa extra.
• Governança bSDD interna quando necessário. Empresa com portfólio significativo cria seu próprio dicionário institucional em bSDD privado, hospeda propriedades específicas do domínio dela (por exemplo: standards internos de hospitalidade, requisitos particulares de infraestrutura viária), e obriga uso interno via IDS. O dicionário passa a ser ativo institucional versionado.

• IDS Property facetDocumenta formalmente Pset, name, dataType e valor esperado. Estrutura XSD normativa: elemento `<property>` dentro de `<requirements>` ou `<applicability>`, com atributos `dataType`, `cardinality` e sub-elementos `<propertySet>`, `<baseName>` (ou `<name>`), `<value>`. Repositório: github.com/buildingSMART/IDS.
• buildingSMART bSDDServiço público (bsdd.buildingsmart.org) que hospeda dicionários com URI persistente. Aceita dicionários públicos (Uniclass, ETIM, IfcClassification) e privados institucionais com governança da própria organização. API REST para consulta programática. IDS Property/Classification facet pode referenciar diretamente URI bSDD como fonte canônica de nome, tipo e valores permitidos.
• ISO 23387:2022Data templates for construction objects used in the life cycle of built assets — General concepts and principles. Framework para estruturação de propriedades de objetos com hierarquia de tipos, categorias e valores permitidos. Base conceitual do vocabulário compartilhado que bSDD hospeda.
• ABNT NBR ISO 12006-3:2022Building construction — Organization of information about construction works — Part 3: Framework for object-oriented information. Define framework para dicionário de dados terminológico usado como base do bSDD.
• ABNT NBR ISO 19650-1:2022Estabelece Employer Information Requirements (EIR) — o documento contratual que define o que precisa ser entregue. IDS + bSDD são a camada executável desses requirements.
• IDS Classification facetFaceta que verifica classificação atribuída a objetos IFC — sistema (`system`) e valor (`value`) opcionais, com preferência canônica pela referência via URI bSDD para garantir vocabulário compartilhado cross-projeto.