ISO 19650 na prática: como organizar famílias e metadados BIM

Uma família pode parecer correta na tela e ainda assim quebrar o fluxo de informação do projeto. Nome ambíguo, parâmetro duplicado, unidade inconsistente, classificação ausente ou valor preenchido no lugar errado dificultam busca, quantitativos, exportação, orçamento e entrega.

A ISO 19650 ajuda a tratar esse problema porque coloca a gestão da informação no centro do BIM. Ela não fornece uma lista universal de nomes para famílias Revit. Em vez disso, estabelece princípios para definir requisitos, responsabilidades, estados, revisão, versionamento, troca e disponibilidade da informação ao longo do ciclo de vida do ativo.

Última verificação editorial: 23 de setembro de 2026. A ISO 19650-1:2018 segue publicada e foi confirmada em 2024, embora uma revisão internacional esteja em desenvolvimento. Este artigo resume aplicações práticas e não reproduz o texto integral da norma.

O que a ISO 19650 muda na prática

O ponto de partida deixa de ser “quais parâmetros conseguimos colocar?” e passa a ser “qual informação é necessária, para qual finalidade, em qual momento, por quem e como será verificada?”. Essa inversão evita modelos carregados de dados sem uso e, ao mesmo tempo, reduz a falta de propriedades essenciais na entrega.

Para uma biblioteca de famílias, a aplicação prática envolve quatro decisões:

• Requisito: quais propriedades são necessárias para projeto, coordenação, orçamento, operação ou outro uso definido.

• Estrutura: como nomes, tipos, parâmetros, unidades, classificações e identificadores serão organizados.

• Processo: quem cria, verifica, aprova, publica, atualiza e retira uma família.

• Evidência: como a equipe comprova que o objeto entregue atende ao requisito e pode ser usado no estado informado.

ISO 19650 não é um padrão de nome pronto

A série ISO 19650 recomenda organizar e nomear contêineres de informação conforme uma convenção acordada, mas não determina que toda empresa use a mesma sequência de campos ou abreviações. A convenção deve ser definida no padrão de produção de informação do projeto ou da organização.

Isso significa que uma regra pode ser adequada em uma biblioteca e inadequada em outra. O importante é que seja documentada, compreensível, consistente, proporcional à complexidade do trabalho e capaz de permanecer estável durante as trocas.

Uma nomenclatura útil para famílias Revit

O nome deve ajudar uma pessoa a localizar o conteúdo sem tentar concentrar todos os metadados em uma linha. Uma estrutura simples pode combinar categoria, objeto, característica diferenciadora e origem quando ela for relevante:

Exemplo: Mobiliário_MesaReunião_Retangular_Fabricante

O exemplo não é uma regra universal. Antes de adotá-lo, defina vocabulário, ordem, separador, idioma, uso de acentos, abreviações autorizadas e tratamento de fabricantes. Informações que mudam entre tipos, como largura ou acabamento, normalmente devem permanecer em parâmetros ou nomes de tipo, e não ser repetidas no nome da família.

• evite códigos sem significado documentado;

• não use “final”, “novo”, “revisado” ou números de versão soltos no nome;

• não inclua a extensão .rfa no campo de nome interno;

• diferencie família, tipo e instância;

• reserve fabricante para objetos realmente associados a uma marca;

• mantenha um identificador estável quando o nome editorial puder mudar.

Metadados: menos campos, mais coerência

Um conjunto de parâmetros só é útil se houver definição, unidade, escopo e regra de preenchimento. Para cada propriedade, registre:

• nome legível e identificador estável;

• definição sem ambiguidades;

• tipo de dado e unidade;

• se o valor pertence à família, ao tipo ou à instância;

• origem e responsável pela informação;

• momento em que o valor se torna obrigatório;

• lista de valores permitidos ou regra de validação;

• destino na exportação ou integração;

• tratamento para desconhecido, não aplicável e não informado.

Usar texto livre para tudo parece flexível, mas produz variações como “sim”, “Sim”, “S”, “true” e “1”. Quando o dado alimenta filtro, tabela, verificação ou sistema externo, um tipo adequado e uma lista controlada são mais seguros.

Parâmetro de tipo ou de instância?

A escolha deve refletir o comportamento real da informação. Uma propriedade de tipo é compartilhada por todas as ocorrências daquele tipo, como um código de produto ou uma dimensão padronizada. Uma propriedade de instância pode variar em cada elemento colocado, como identificador patrimonial, localização ou marca de inventário.

Configurar como instância um dado que deveria ser de tipo aumenta divergências. Configurar como tipo um dado que varia por ocorrência impede representar a realidade. A governança começa nessa decisão aparentemente pequena.

Estado, revisão e publicação

Uma pasta compartilhada não é, por si só, um ambiente comum de dados. A equipe precisa distinguir conteúdo em desenvolvimento, conteúdo compartilhado para coordenação, conteúdo publicado para uso autorizado e conteúdo arquivado. Cada transição deve ter critérios e responsáveis.

1. O autor cria ou atualiza a família com base em requisito documentado.

2. Uma verificação técnica avalia geometria, parâmetros, desempenho e comportamento no projeto.

3. Uma verificação de informação confere nomes, classificação, unidades, valores e exportação.

4. O responsável autoriza o conteúdo para um uso definido.

5. A versão publicada recebe registro de data, autoria, revisão e escopo de uso.

6. Versões substituídas permanecem rastreáveis, mas deixam de ser oferecidas como opção corrente.

Publicar sem declarar o uso permitido cria falsa confiança. Uma família pode estar aprovada para estudo e documentação, mas não conter dados suficientes para orçamento, fabricação ou operação.

Onde o IDS entra

O Information Delivery Specification, ou IDS, é um padrão da buildingSMART para expressar requisitos de informação de forma legível por pessoas e interpretável por computadores. A versão 1.0 tornou-se padrão final em 2024. Com IDS, é possível definir que determinados objetos IFC devem possuir classificação, material, propriedade ou valor e depois executar uma verificação automática.

O IDS não organiza sozinho um arquivo RFA e não substitui a revisão visual ou funcional da família. Seu uso mais direto está na validação de conjuntos de dados IFC. Mesmo assim, ele influencia positivamente a biblioteca: se a entrega exige uma propriedade específica no IFC, a equipe precisa mapear de onde esse dado virá no software de autoria e testar a exportação.

Exemplo de requisito verificável

Em vez de escrever apenas “paredes devem conter resistência ao fogo”, um requisito computável precisa indicar quais paredes são alcançadas, qual propriedade deve existir, em qual conjunto ela aparece e quais valores ou formatos são aceitos. A buildingSMART usa um exemplo semelhante para demonstrar como o IDS transforma intenção em regra verificável.

Essa precisão reduz discussões no fim da entrega. Também mostra por que nomenclatura, classificação e metadados não são trabalho cosmético: eles permitem que uma necessidade seja testada de maneira repetível.

Erros pequenos que quebram a governança

• duas propriedades com o mesmo significado e nomes diferentes;

• o mesmo parâmetro preenchido em milímetros em uma família e metros em outra;

• valores de exemplo mantidos como se fossem dados confirmados;

• nome do tipo alterado sem preservar código ou identificador;

• classificação aplicada à categoria errada;

• parâmetro compartilhado recriado com identificador diferente;

• família publicada sem teste em projeto e sem teste de exportação;

• campos técnicos sobrescritos por ajustes editoriais;

• ausência de estado que diferencie rascunho, revisão e conteúdo aprovado.

Como implantar sem paralisar o escritório

1. Escolha um uso prioritário, como quantitativos ou entrega IFC; não tente resolver todo o ciclo de vida de uma vez.

2. Liste as informações mínimas necessárias para esse uso e elimine campos sem finalidade clara.

3. Defina convenção de nomes, dicionário de propriedades e responsabilidades.

4. Aplique o padrão a um lote pequeno e representativo de famílias.

5. Teste carregamento, tabelas, filtros, desempenho e exportação.

6. Registre erros encontrados e ajuste o padrão antes de ampliar o lote.

7. Automatize verificações objetivas; mantenha revisão humana para comportamento, adequação e qualidade técnica.

8. Publique somente o conteúdo aprovado e preserve o histórico das versões.

Checklist de uma família governada

• nome conforme a convenção vigente;

• categoria e subcategoria corretas;

• tipos necessários, sem duplicações;

• parâmetros com definição, unidade e escopo corretos;

• classificação e identificadores preenchidos quando exigidos;

• valores técnicos provenientes de fonte confirmada;

• geometria proporcional ao uso e ao desempenho esperado;

• comportamento testado em projeto;

• exportação validada quando houver entrega aberta;

• estado, revisão, autoria e data rastreáveis;

• uso autorizado claramente informado.

Conclusão

Aplicar a ISO 19650 às famílias não é adicionar um prefixo ao nome do arquivo. É criar um sistema em que requisitos, estrutura, responsabilidades, estados e verificações tornam a informação confiável para o uso pretendido.

Nomenclatura coerente ajuda a encontrar; metadados bem definidos ajudam a interpretar; IDS e outras validações ajudam a comprovar. Quando esses elementos trabalham juntos, a biblioteca deixa de ser uma coleção de arquivos e passa a funcionar como infraestrutura de informação para o projeto e para o ativo.

Comece por uma biblioteca organizada

Explore famílias Revit e use os requisitos do seu projeto para selecionar, revisar e padronizar os dados antes da publicação interna.

Acessar biblioteca

Fontes oficiais consultadas

• ISO — ISO 19650-1:2018, conceitos e princípios

• ISO — Better building with new International Standards for BIM

• ISO — ISO 19650-3 e a fase operacional dos ativos

• buildingSMART International — Information Delivery Specification (IDS)

• buildingSMART International — IDS 1.0 aprovado como padrão final

Imagem de capa: Marina Zvada / Pexels. Licença verificada em 23 de setembro de 2026.