Por que a propriedade não aparece onde o recebedor procura?

Property set inventado é dado que ninguém acha.

O projetista preenche tudo. Resistência ao fogo, classificação acústica, coeficiente térmico, fabricante, modelo, garantia. A informação está no IFC. Mas quando o gestor da informação roda uma consulta pelo Pset canônico da norma — Pset_WallCommon, Pset_DoorCommon, Pset_BeamCommon — o resultado volta vazio. A propriedade existe, mas mora num contêiner que ninguém procura.

No IFC (ISO 16739-1:2024, IFC4x3), a informação alfanumérica é agrupada em IfcPropertySet — um contêiner nomeado que reúne propriedades (IfcPropertySingleValue, IfcPropertyEnumeratedValue, entre outras) e é ligado ao elemento por IfcRelDefinesByProperties. O schema reserva o prefixo Pset_ para Property Sets padronizados: Pset_WallCommon, Pset_SlabCommon, Pset_SpaceCommon e dezenas de outros, cada um com lista de propriedades definida na documentação normativa. Qualquer software, rule engine ou consulta que procure informação canônica sabe onde buscar: no Pset padronizado.

O problema aparece quando a propriedade chega num contêiner inventado. Custom_Pset_ARQ, DADOS_GERAIS, Pset_STR_Fire, Propriedades do Projeto, BIM_Parameters — nomes que fazem sentido para quem criou, mas que nenhum software de análise, nenhum IDS, nenhum sistema de FM sabe procurar. A informação está no modelo; está no lugar errado.

Isso é diferente de a propriedade ter nome divergente — quando o dado se chama TRRF em vez de FireRating mas está no Pset certo. Aqui o problema é o contêiner: a propriedade pode até ter o nome correto, mas está encaixotada num Pset que a norma não reconhece e que nenhuma consulta padronizada alcança.

A causa mais frequente é o software de autoria. Revit, ArchiCAD e Tekla mantêm mapeamentos de exportação que decidem onde cada parâmetro nativo cai no IFC. Quando o projetista cria parâmetros customizados sem configurar o mapeamento, o exportador empacota tudo num Pset genérico inventado. Quando usa templates de família de terceiros com Psets proprietários, o contêiner sai como veio. O resultado é um IFC onde a informação contratada existe, mas não está no Pset que o EIR, o IDS e o recebedor esperam.

1. 1

   Consulta por Pset canônico volta vazia · a query pede Pset_WallCommon.FireRating e não encontra nada, embora a informação esteja no modelo sob outro contêiner.

2. 2

   Psets com nomes inventados no viewer · ao selecionar o elemento, aparecem contêineres como Custom_Pset_ARQ, DADOS_GERAIS ou BIM_Parameters — nenhum reconhecido pela norma.

3. 3

   IDS falha por propriedade ausente · a regra exige propriedade no Pset padronizado; como ela está em Pset customizado, o rule engine reprova mesmo com a informação presente.

4. 4

   Dashboard de qualidade incoerente · a métrica de preenchimento mostra campos vazios no Pset canônico enquanto a informação está duplicada em Pset inventado.

5. 5

   FM e análise não importam a propriedade · o software de facility management ou de simulação procura o Pset padrão, ignora o customizado, e a informação se perde no handover.

6. 6

   Cada disciplina tem seu contêiner · arquitetura usa Custom_Pset_ARQ, estrutura usa Pset_STR, instalações usa MEP_Props — mesma propriedade, três endereços diferentes.

1. 1

   Mapeamento de exportação no default de fábrica · o exportador IFC do software usa a tabela padrão, que não mapeia parâmetros customizados para os Psets canônicos da norma — cria Pset genérico.

2. 2

   Template de família com Pset proprietário · famílias compradas ou criadas por terceiros trazem seus próprios Psets, que o exportador replica sem questionar.

3. 3

   Parâmetro criado fora do padrão institucional · o projetista cria parâmetro ad hoc no software nativo e não configura o mapeamento para Pset IFC correto.

4. 4

   Confusão entre campo do software e Pset IFC · o projetista preenche o campo no Revit, Tekla ou ArchiCAD e assume que o dado já está no Pset certo — sem conferir o IFC resultante.

5. 5

   EIR que não indica o Pset exato · o requisito pede a informação mas não especifica em qual Property Set ela deve estar. Cada disciplina escolhe o contêiner mais conveniente.

6. 6

   Sem verificação pós-export · ninguém abre o IFC gerado para conferir se as propriedades estão nos Psets esperados antes de subir ao CDE.

1. 1

   Informação presente mas inacessível · o dado foi preenchido, o modelo pesa mais por causa dele, mas nenhuma consulta padronizada o encontra. Esforço desperdiçado.

2. 2

   IDS que reprova modelo correto · a regra exige propriedade no Pset canônico; como está em contêiner inventado, o modelo reprova — e o projetista não entende por quê.

3. 3

   Handover para FM fracassa · sistemas de gestão de ativos (Archibus, TRIRIGA, FM:Systems) importam Psets padronizados. Contêiner customizado é ignorado na importação.

4. 4

   Consulta cross-disciplina impossível · cada disciplina empacotou a mesma propriedade em Pset diferente. Nenhuma query federada reúne os dados sem mapeamento manual.

5. 5

   Retrabalho de remapeamento · descobrir o problema tarde obriga reconfigurar o export, re-gerar o IFC, re-verificar — em todas as disciplinas afetadas.

6. 6

   Perda de confiança contratual · auditoria externa encontra propriedade fora do Pset contratado. A leitura é entrega incompleta — mesmo que a informação esteja no modelo.

Curto prazo (30 dias):

1. Levantar os Psets inventados. Abrir o IFC no viewer, listar todos os Property Sets presentes, e identificar quais carregam propriedades que deveriam estar em Psets canônicos da norma.

2. Mapear de-para. Para cada propriedade deslocada, identificar o Pset padronizado correto e documentar a correspondência.

3. Corrigir o preset de exportação. No software de autoria de cada disciplina, configurar o mapeamento de cada parâmetro customizado para o Pset canônico. Re-exportar e verificar.

Médio prazo (60-90 dias):

4. Auditar templates de família. Conferir bibliotecas de terceiros e internas — cada Pset proprietário que tenha equivalente canônico precisa ser remapeado antes de entrar em produção.

5. Incluir Pset no EIR e no IDS. Cada propriedade exigida no EIR nasce com o Property Set indicado. No IDS, a Property facet aponta para o Pset canônico com cardinalidade required.

6. Instituir verificação de Pset no CDE. A transição de WIP para Shared exige que a verificação de mapeamento de Property Sets esteja aprovada, com relatório arquivado.

1. 1

   Mapeamento de export configurado no kickoff · o preset de exportação IFC é ajustado antes da modelagem começar, com cada parâmetro customizado mapeado para o Pset canônico.

2. 2

   Bibliotecas auditadas antes de produção · toda família de terceiro ou template novo passa por conferência de Psets — contêiner proprietário é remapeado antes de entrar no projeto.

3. 3

   EIR com Pset declarado · cada propriedade exigida no EIR nasce com indicação do Property Set onde deve residir, eliminando ambiguidade.

4. 4

   Verificação pós-export como rotina · antes de subir ao CDE, o autor confere se as propriedades estão nos Psets esperados, não em contêineres inventados pelo exportador.

5. 5

   Psets customizados só com governança · quando não há Pset canônico, o contêiner customizado é criado com nome institucional, documentado no BEP e versionado.

• ISO 16739-1:2024 (IFC4x3)Industry Foundation Classes (IFC). Define IfcPropertySet como contêiner nomeado de propriedades, atribuído ao elemento por IfcRelDefinesByProperties. O prefixo Pset_ é reservado para Property Sets padronizados na norma (Pset_WallCommon, Pset_DoorCommon, Pset_SlabCommon, entre outros), cada um com lista de propriedades documentada. Contêiner fora do padrão é legítimo apenas para propriedades sem equivalente canônico.
• ABNT NBR ISO 19650-2:2022Fase de entrega. §5.6.3 exige verificação da garantia da qualidade antes da troca — inclui conferir que cada propriedade está no Property Set esperado pelo EIR, não em contêiner inventado.
• buildingSMART IDS (ISO 29481-3)Information Delivery Specification. A Property facet especifica formalmente o propertySet, o name e o dataType esperados. Propriedade no Pset errado falha na verificação mesmo que o valor esteja correto.
• ABNT NBR ISO 19650-1:2022Conceitos e princípios. Exige que a informação trocada seja localizável e verificável — propriedade em contêiner inventado compromete a localizabilidade e a interoperabilidade da troca.