Por que usar tipos (IfcXxxType) no IFC?

Mil instâncias soltas, zero tipo: cada parede reinventada.

O projetista modela vinte paredes de vedação externa, todas com a mesma composição, a mesma resistência ao fogo, o mesmo acabamento. No software nativo, o tipo da família agrupa essas propriedades comuns: muda no tipo, muda em todas as ocorrências. Exporta o IFC. Do outro lado, o gestor da informação abre o arquivo e encontra vinte IfcWall, cada uma carregando seu próprio conjunto de propriedades — e nenhuma apontando para um IfcWallType compartilhado. Não há tipo. Cada instância reinventa a especificação do zero.

No IFC (ISO 16739-1:2024, IFC4x3), a arquitetura de tipos funciona com duas entidades complementares:

• IfcElementType (e suas especializações: IfcWallType, IfcSlabType, IfcDoorType, IfcColumnType, etc.) — define a especificação comum compartilhada. O tipo carrega a lista de Property Sets que valem para todas as ocorrências: materiais, desempenho, classificação, dados de fabricante. É a definição canônica.

• IfcRelDefinesByType — a relação 1-para-N que liga o tipo às suas ocorrências. Um único IfcWallType pode ser referenciado por cem IfcWall via essa relação. Cada ocorrência herda os Property Sets do tipo sem precisar repeti-los.

Quando o modelo não usa tipos, cada instância carrega sua própria cópia das propriedades. O resultado é triplo: o arquivo incha (N cópias do que deveria ser 1), a consistência quebra (a mesma parede com resistência ao fogo diferente entre duas instâncias que deveriam ser iguais) e a manutenção da informação vira pesadelo (corrigir uma propriedade exige localizar e editar cada instância individualmente).

A causa mais frequente é o mapeamento de exportação. Revit, ArchiCAD e Tekla têm conceito de tipo no nativo, mas o preset de exportação IFC pode não traduzir esse tipo para IfcXxxType com IfcRelDefinesByType. O default de fábrica de alguns exportadores simplesmente ignora a estrutura de tipo e joga tudo como instância avulsa. Quando o projetista não configura o export, o IFC sai sem tipos — mesmo que o nativo os tenha.

1. 1

   Nenhum IfcXxxType no viewer · ao navegar pela hierarquia do IFC em viewer neutro, não aparece nenhum IfcWallType, IfcSlabType ou equivalente. Só instâncias.

2. 2

   Propriedades repetidas em cada instância · cada IfcWall carrega seu próprio Pset_WallCommon com os mesmos valores. A informação está lá, mas multiplicada N vezes sem consolidação.

3. 3

   Inconsistência entre instâncias do mesmo tipo lógico · paredes que deveriam ser iguais mostram FireRating diferentes, materiais divergentes ou classificações conflitantes — porque cada uma foi preenchida independentemente.

4. 4

   Arquivo IFC anormalmente grande · N cópias de Property Sets idênticos inflam o arquivo. O que deveria ser uma definição de tipo compartilhada virou N definições individuais.

5. 5

   Alteração de especificação exige edição instância a instância · o projetista precisa mudar a resistência ao fogo de todas as paredes externas. Sem tipo, edita cada uma manualmente — e inevitavelmente esquece alguma.

6. 6

   IDS não consegue verificar por tipo · a regra IDS quer verificar propriedades no tipo (IfcWallType), mas não encontra nenhum. Toda a verificação cai nas instâncias, onde a inconsistência é maior.

1. 1

   Preset de exportação não traduz tipos · o exportador IFC do software usa configuração default que não mapeia o tipo nativo (família do Revit, layer do ArchiCAD) para IfcXxxType com IfcRelDefinesByType.

2. 2

   Template de projeto sem tipos definidos · o projeto começou sem biblioteca de tipos — cada instância foi criada avulsamente, sem família ou definição-mãe no nativo.

3. 3

   Modelador desconhece o conceito de tipo no IFC · o projetista usa tipos no software nativo mas não sabe que eles precisam aparecer como IfcXxxType no IFC. Não confere o resultado da exportação.

4. 4

   Copiar-colar instâncias em vez de instanciar tipos · em vez de criar ocorrências a partir de um tipo definido, o modelador copia instâncias existentes e edita. No nativo parece funcionar; no IFC gera N definições independentes.

5. 5

   Software de autoria com mapeamento incompleto · algumas versões de exportadores não criam IfcRelDefinesByType mesmo quando o tipo nativo existe. Limitação da ferramenta que o projetista não investiga.

6. 6

   EIR silencia sobre uso de tipos · nenhum requisito contratual exige que o modelo entregue em IFC contenha IfcXxxType. Sem exigência, sem verificação, sem tipo.

1. 1

   Inconsistência silenciosa de especificação · sem tipo compartilhado, cada instância pode ter propriedades diferentes para elementos que deveriam ser idênticos. A divergência só aparece quando alguém compara — e ninguém compara N instâncias manualmente.

2. 2

   Arquivo inchado sem ganho de informação · N cópias de Property Sets idênticos inflam o modelo sem adicionar informação. O arquivo pesa mais, abre mais devagar e consome mais recursos de federação.

3. 3

   Manutenção de propriedades inviável · corrigir uma propriedade em todas as ocorrências de um tipo lógico exige localizar cada instância individualmente. A probabilidade de erro cresce linearmente com o número de instâncias.

4. 4

   Verificação de qualidade degradada · IDS e rule engines que verificam propriedades no tipo encontram zero IfcXxxType. A verificação cai para nível de instância, onde inconsistências são mais difíceis de detectar e mais numerosas.

5. 5

   Perda de semântica no handover · FM e sistemas de gestão de ativos esperam tipos para agrupar componentes similares. Sem tipo, cada instância é tratada como componente único — a catalogação de ativos explode em complexidade.

6. 6

   Retrabalho de re-exportação · descobrir o problema tarde obriga reconfigurar o preset de exportação, re-exportar todos os modelos e re-verificar — em cada disciplina afetada.

Curto prazo (30 dias):

1. Diagnosticar o estado atual. Abrir cada IFC do projeto em viewer neutro e levantar quantos IfcXxxType existem por disciplina. Documentar o baseline: se zero, o problema é total.

2. Configurar o preset de exportação. Em cada software de autoria (Revit, ArchiCAD, Tekla), ativar a exportação de tipos e configurar o mapeamento de cada tipo nativo para o IfcXxxType correspondente com IfcRelDefinesByType.

3. Re-exportar modelo piloto e verificar. Escolher uma disciplina, re-exportar com preset corrigido, e conferir no viewer que os IfcXxxType aparecem e que as instâncias estão ligadas por IfcRelDefinesByType.

Médio prazo (60-90 dias):

4. Consolidar propriedades nos tipos. Mover os Property Sets comuns (materiais, desempenho, classificação) das instâncias para os IfcXxxType. Cada instância herda, em vez de copiar.

5. Incluir tipos no EIR e no IDS. O EIR exige IfcXxxType com IfcRelDefinesByType para cada categoria de elemento. A IDS contém regra que verifica presença de tipo e consistência de propriedades compartilhadas.

6. Padronizar biblioteca de tipos. Cada tipo de elemento do projeto nasce como IfcXxxType com propriedades canônicas pré-configuradas. Novos projetistas instanciam a partir de tipos existentes, não criam instâncias avulsas.

1. 1

   Preset de exportação configurado no kickoff · a exportação de tipos é ativada e testada antes da modelagem começar — não na véspera da entrega. Cada tipo nativo tem mapeamento para IfcXxxType confirmado.

2. 2

   Biblioteca de tipos auditada antes de produção · toda família ou template novo passa por conferência de tipo: o nativo tem tipo definido, e a exportação gera IfcXxxType com IfcRelDefinesByType.

3. 3

   Propriedades comuns definidas no tipo, não na instância · materiais, desempenho e classificação vivem no IfcXxxType. A instância herda. Muda no tipo, muda em todas as ocorrências.

4. 4

   Verificação pós-export como rotina · antes de subir ao CDE, o autor confere se os IfcXxxType existem e se as instâncias estão ligadas por IfcRelDefinesByType.

5. 5

   IDS com regra de tipo no repositório do projeto · a IDS verifica presença de IfcXxxType e consistência de propriedades compartilhadas em cada rodada de aceite.

• ISO 16739-1:2024 (IFC4x3)Industry Foundation Classes (IFC). Define IfcElementType como entidade-mãe dos tipos especializados (IfcWallType, IfcSlabType, IfcColumnType, etc.), que carregam a lista de Property Sets comuns compartilhados — a especificação canônica de todas as ocorrências. Define IfcRelDefinesByType como relação 1-para-N que liga tipo às instâncias, permitindo herança de propriedades sem duplicação.
• ABNT NBR ISO 19650-2:2022Fase de entrega. §5.2.1 c) exige critério de aceitação por requisito de informação — inclui verificar que o modelo contém tipos definidos com propriedades compartilhadas, não apenas instâncias avulsas. §5.6.3 exige verificação da garantia da qualidade antes da troca.
• buildingSMART IDS (ISO 29481-3)Information Delivery Specification. Permite criar regras de verificação no nível do tipo (applicability = IfcWallType) e validar que os Property Sets exigidos estão definidos no tipo, não espalhados por instâncias individuais.
• ABNT NBR ISO 19650-1:2022Conceitos e princípios. Exige que a informação trocada seja consistente e não redundante. Tipo compartilhado é o mecanismo IFC que garante consistência (uma definição, N ocorrências) e elimina redundância (propriedade no tipo, não repetida em cada instância).