Entenda o que é arquivo IFC no BIM, como o padrão estrutura geometria, propriedades e relações, como funciona a troca entre softwares e como validar a interoperabilidade.
Confira!
Um arquivo IFC pode abrir perfeitamente em um visualizador, mostrar toda a geometria do empreendimento e ainda assim ser inadequado para o uso pretendido. Um quadro elétrico pode aparecer na posição correta, com volume e aparência coerentes, mas chegar sem classificação, propriedades técnicas, identificação ou relação espacial necessárias para coordenação, quantitativos ou operação. Nesse caso, houve transferência de geometria, mas não necessariamente uma troca de informação confiável.
Esse é o ponto central do IFC — Industry Foundation Classes no BIM. O IFC não deve ser entendido apenas como uma extensão de arquivo .ifc ou como um “PDF 3D” do modelo. Ele é um padrão aberto para representar e trocar informações estruturadas do ambiente construído entre diferentes aplicações, preservando, conforme o escopo da troca, identidade, semântica, propriedades, relações, estrutura espacial e geometria.
A tese deste artigo é simples: interoperabilidade não significa conseguir abrir um arquivo; significa conseguir transferir informação adequada ao uso, com significado, estrutura e qualidade suficientes para que outra equipe ou aplicação possa utilizá-la de forma confiável. O IFC é uma das principais bases técnicas para isso no ecossistema BIM.
O que é um arquivo IFC e por que ele existe
No processo BIM, cada disciplina pode desenvolver seu trabalho em uma aplicação autoral diferente. Arquitetura, estrutura, instalações elétricas, HVAC, hidráulica e outras especialidades não precisam necessariamente usar o mesmo software. Essa liberdade é importante, mas cria um problema: como coordenar, revisar e reutilizar informações se cada sistema armazena os dados em uma estrutura proprietária própria?
O IFC foi desenvolvido justamente para criar uma representação aberta e neutra da informação do ativo construído. Em vez de obrigar todos os participantes a trabalhar no mesmo ecossistema tecnológico, torna possível estabelecer uma camada comum de troca entre aplicações compatíveis.
Considere um empreendimento em que arquitetura é produzida em uma plataforma, estrutura em outra e instalações em uma terceira. Se a coordenação depender exclusivamente dos arquivos nativos, o coordenador fica condicionado às licenças, versões e formatos de cada fornecedor. Com IFC, cada equipe pode manter seu modelo autoral e publicar uma representação estruturada para os usos acordados de coordenação, revisão, análise ou entrega.
Isso não significa que o arquivo IFC substitui necessariamente o modelo autoral. São produtos diferentes, com responsabilidades diferentes. O modelo nativo costuma preservar recursos específicos da ferramenta, histórico de autoria, famílias, relações paramétricas e mecanismos de edição que podem não ser necessários — ou não ser transferíveis da mesma forma — em uma troca aberta. O IFC serve ao intercâmbio estruturado da informação conforme o propósito definido.
IFC não é um desenho 3D neutro
A simplificação mais perigosa é pensar que IFC é apenas um formato geométrico universal. Uma parede em IFC não deveria ser somente um conjunto de superfícies. Ela pode ser representada como um objeto reconhecível por máquina, associado a propriedades, materiais, relações espaciais, classificações e outros dados pertinentes.
O mesmo raciocínio vale para um equipamento. Um QGBT não é útil apenas porque aparece como um volume retangular no lugar correto. Para determinados usos, pode ser necessário saber que aquele objeto é um quadro elétrico, qual é seu identificador, a que pavimento ou espaço pertence, quais propriedades foram exigidas, como ele se relaciona com o sistema e qual informação deve seguir para fases posteriores.
Por isso, a pergunta correta não é apenas “o IFC abriu?”. A pergunta é: a informação necessária chegou com significado suficiente para o uso previsto?
IFC não é um “PDF 3D” do modelo.
O valor da troca está em preservar informação estruturada — identidade, semântica, propriedades, relações e geometria — conforme o uso definido para o projeto.
Arquivo nativo, IFC e modelo federado têm funções diferentes
No modelo autoral, a disciplina desenvolve e documenta sua solução. Na troca IFC, publica-se uma representação estruturada para outro participante ou processo. No modelo federado, diferentes modelos são reunidos para fornecer uma visão integrada sem que cada disciplina perca necessariamente a autoria de seu próprio conteúdo.
Essa distinção é importante para a Coordenação de Projetos de Engenharia. Federação não significa transformar todos os projetos em um único arquivo editável. Significa organizar modelos com origem, responsabilidade, referência espacial, versão e finalidade conhecidas para que possam ser analisados em conjunto.
Quando essa lógica é bem definida no BEP BIM, o IFC deixa de ser uma exportação improvisada ao final da etapa e passa a integrar um fluxo planejado de produção e troca da informação.
Como a informação é estruturada dentro do IFC
Para compreender por que duas exportações IFC do mesmo modelo podem produzir resultados muito diferentes, é necessário separar geometria de estrutura informacional.
O IFC utiliza um schema, isto é, um modelo de dados que define classes, atributos, relacionamentos e formas de representar entidades do ambiente construído. Isso cria uma linguagem comum que aplicações distintas podem interpretar.
De maneira simplificada, um modelo pode representar relações como:
empreendimento → edifício → pavimento → espaço → sistema → componente.
Essa sequência não precisa ser vista como uma árvore rígida de todos os casos, mas ajuda a entender que os objetos não existem isoladamente. Eles fazem parte de uma estrutura espacial e funcional que pode ser relevante para diversas análises.
Identidade, semântica, propriedades e relações
Um objeto BIM pode carregar diferentes camadas de informação. A geometria responde onde ele está e como é representado espacialmente. A identidade diferencia aquele objeto dos demais. A semântica ajuda a indicar o que ele é. Propriedades descrevem suas características. Relações conectam o objeto ao contexto do modelo.
Imagine novamente o QGBT-01. Uma troca robusta pode precisar preservar:
| Camada | Exemplo aplicado ao QGBT-01 |
| Identidade | código ou identificador do equipamento |
| Semântica | objeto reconhecido como equipamento/quadro dentro da estrutura prevista |
| Localização | edifício, pavimento, sala técnica ou zona |
| Geometria | posição, dimensões e representação necessária |
| Propriedades | tensão, corrente nominal, fabricante, modelo ou dados requeridos |
| Classificação | código segundo a estrutura de classificação adotada |
| Relações | vínculo com sistema, espaço, documentação ou outros elementos quando aplicável |
Se o arquivo preservar apenas a geometria, o objeto continua visível, mas perde parte importante de sua utilidade informacional.
Isso conecta diretamente IFC ao artigo sobre Classificação da Informação em BIM e NBR 15965. Classificar corretamente ajuda a organizar e reconhecer informação, enquanto o schema IFC fornece uma estrutura aberta para representá-la e trocá-la. São funções diferentes, porém complementares.
Classe IFC não é nome de família do software
Outro erro comum é confundir o nome usado no software autoral com a classe de informação utilizada na troca. Uma família pode chamar-se “Painel Geral”, “QGBT”, “Main Switchboard” ou qualquer outra convenção interna. Isso não garante, por si só, que a exportação tenha produzido a classe, as propriedades ou a estrutura informacional esperadas.
Por isso o mapeamento entre o modelo autoral e o IFC precisa ser tratado como uma decisão técnica. O nome amigável para o projetista não substitui a estrutura necessária para a interoperabilidade.
Property Sets e Quantity Sets
O IFC também prevê conjuntos padronizados de propriedades e quantidades. Na prática, isso permite que certas informações sejam organizadas de forma reconhecível por aplicações que entendam aquela estrutura.
Mas o fato de o padrão permitir propriedades não significa que qualquer informação criada no modelo autoral será automaticamente transferida da maneira correta. Propriedades customizadas, parâmetros internos, unidades, classificações e mapeamentos podem exigir configuração específica.
Esse é um dos motivos pelos quais a validação deve fazer parte do processo. Um campo existente no software de origem pode chegar com outro nome, ser omitido, ser publicado em estrutura inadequada ou simplesmente não ser reconhecido pela aplicação de destino.
MVD: nem toda troca precisa carregar todo o schema
Uma troca de informação não precisa necessariamente usar toda a amplitude do IFC. Diferentes finalidades podem exigir subconjuntos e regras específicas. É nesse contexto que aparecem as Model View Definitions — MVDs, associadas a determinados usos e requisitos de troca.
O princípio é importante mesmo para quem não precisa aprofundar a especificação técnica: o arquivo deve ser preparado para um propósito. Um IFC destinado à coordenação geométrica pode ter necessidades diferentes de um IFC destinado a quantitativos, análise, entrega ou operação.
Isso nos leva a uma consequência prática: pedir apenas “entregar em IFC” é uma especificação incompleta. É preciso definir para qual uso, com quais informações, em qual marco e segundo quais critérios de aceitação.
“Entregar em IFC” não é um requisito de informação completo.
O projeto precisa definir finalidade, conteúdo esperado, marco de entrega e critérios de aceite. Sem isso, duas equipes podem entregar IFCs tecnicamente diferentes e ambas acreditar que atenderam ao contrato.
Como funciona a troca IFC entre aplicações BIM
Uma troca IFC tecnicamente controlada começa antes da exportação. Ela começa na definição do requisito.
O fluxo básico pode ser entendido assim:
requisito de informação → preparação do modelo autoral → mapeamento → exportação IFC → validação → publicação → leitura/federação → uso da informação → retorno de questões.
Cada etapa pode introduzir perdas ou inconsistências se não houver regras claras.
1. Definir o propósito da troca
Antes de configurar exportadores, a equipe precisa saber por que o arquivo será produzido. Coordenação, Clash Detection, orçamento, revisão do contratante, análise de requisitos e As-Built não exigem necessariamente as mesmas informações.
Suponha que o contratante queira usar o IFC para conferência de equipamentos elétricos. A geometria deve ser suficiente para localização e coordenação, mas também será necessário definir quais identificadores e propriedades devem estar presentes. Se esse requisito não for formalizado, o projetista pode entregar um arquivo visualmente correto que não atende ao objetivo.
A Gestão da Informação em BIM segundo a ISO 19650 ajuda a colocar essa troca dentro de uma lógica maior de requisitos, entregas, revisão e aceite.
2. Preparar o modelo autoral
Um bom IFC não corrige automaticamente um modelo autoral mal organizado. Antes da exportação, devem estar controlados aspectos como coordenadas, unidades, objetos, classificações, propriedades, duplicidades e informações que não devem ser publicadas naquele marco.
Se dois projetistas usam referências espaciais diferentes, exportar ambos para IFC não fará com que os modelos se alinhem magicamente. Se um objeto foi modelado com categoria inadequada ou parâmetros improvisados, a troca pode apenas transportar o problema para outra ferramenta.
3. Mapear informação para o schema IFC
A etapa de mapeamento traduz estruturas internas da ferramenta autoral para a representação prevista no IFC. Dependendo da aplicação e do fluxo, isso pode envolver classes, propriedades, conjuntos de propriedades, classificações e regras de exportação.
É aqui que surge a diferença entre ter a informação no modelo e conseguir entregá-la corretamente no IFC.
| Situação no modelo autoral | Resultado possível no IFC |
| propriedade existe e está corretamente mapeada | informação chega utilizável |
| propriedade existe, mas não está mapeada | informação pode desaparecer |
| objeto está em categoria inadequada | classe IFC pode ficar incorreta |
| coordenadas foram ajustadas manualmente | modelo pode chegar deslocado |
| unidade ou tipo de dado é inconsistente | aplicação receptora pode interpretar de forma inadequada |
4. Exportar e validar
A exportação não encerra a tarefa. O arquivo precisa ser aberto em ambiente independente ou ferramenta de verificação e comparado aos requisitos definidos.
Visualmente, a primeira verificação costuma identificar problemas óbvios: elementos ausentes, deslocamentos, geometrias quebradas ou duplicidades. Depois devem ser verificadas as informações estruturadas pertinentes ao uso: classes, propriedades, classificações, relações e outros requisitos acordados.
Essa etapa é semelhante a qualquer controle de qualidade de engenharia: não se presume que a conversão foi correta só porque o software concluiu o processo sem emitir erro.
Exportar não é validar.
Uma troca IFC só deve ser considerada concluída depois que geometria, classes, propriedades, referências e demais requisitos relevantes forem verificados no fluxo de destino.
Conheça a solução de Gestão de Requisitos, Evidências e Critérios de Aceite
5. Publicar no CDE e controlar a versão
Depois de validado, o IFC precisa entrar no fluxo de gestão da informação com identificação, revisão, status e finalidade conhecidos. Um arquivo denominado apenas Projeto_Final.ifc não oferece governança suficiente para uma equipe multidisciplinar.
A solução de Ambiente Comum de Dados e Gestão da Informação BIM é o elo natural entre a produção técnica e o controle das trocas. O valor do CDE não está em armazenar o IFC, mas em controlar qual informação está em trabalho, compartilhada, publicada ou arquivada e com qual revisão e responsabilidade.
6. Federar, revisar e devolver questões
Na coordenação, os IFCs das disciplinas podem ser federados para análise integrada. O coordenador consegue verificar interfaces sem necessariamente editar os modelos autorais.
Quando surge uma interferência, o problema não deve ser “corrigido no IFC central” e desaparecer da autoria da disciplina. A questão precisa retornar ao responsável pelo modelo autoral, ser tratada na origem e reaparecer na próxima troca controlada.
É aqui que formatos de comunicação como BCF complementam o IFC. O IFC transporta o modelo e sua informação; o BCF pode transportar questões, pontos de vista, comentários, responsabilidades e acompanhamento de issues sem exigir o envio completo do modelo a cada interação.
Essa lógica se conecta ao artigo de Clash Detection em Projetos BIM: detectar uma interferência é apenas uma etapa. Governar quem deve resolvê-la, em qual modelo e em qual revisão é trabalho de coordenação.
IFC, Open BIM e interoperabilidade em projetos de engenharia
IFC e Open BIM estão relacionados, mas não são sinônimos.
IFC é um padrão aberto de representação e troca de informação. Open BIM é uma abordagem mais ampla de colaboração baseada em padrões abertos, interoperabilidade e neutralidade tecnológica. IFC é uma das principais estruturas que tornam essa abordagem possível, ao lado de outros padrões e serviços usados para requisitos, comunicação, terminologia e integração.
O valor do Open BIM aparece quando diferentes organizações podem escolher as ferramentas mais adequadas ao seu trabalho sem transformar a escolha tecnológica de uma empresa em obrigação para todas as demais.
Open BIM não significa ausência de regras.
A liberdade de escolha tecnológica só funciona quando as equipes compartilham padrões, requisitos e critérios de troca suficientemente claros para manter a informação interoperável.
Interoperabilidade não é independência total de software
Mesmo em um fluxo aberto, a implementação dos padrões continua sendo feita por aplicações reais, com versões, exportadores, importadores e níveis de suporte diferentes. Portanto, Open BIM não elimina a necessidade de testar ferramentas e fluxos.
Duas aplicações podem declarar suporte a IFC e ainda produzir resultados diferentes para determinado uso. Por isso, a decisão de projeto não deve ser baseada apenas na frase “ambos exportam IFC”. É necessário testar a troca real que será utilizada.
Esse teste pode ser simples: selecionar alguns elementos representativos — parede, viga, duto, equipamento elétrico, espaço, sistema — e verificar geometria, identificação, propriedades e classificação após exportação e importação. Esse pequeno piloto, feito na mobilização, pode evitar retrabalho em centenas ou milhares de objetos.
Modelo federado não exige uma única plataforma autoral
Uma das aplicações mais importantes do IFC está na federação multidisciplinar. Cada disciplina mantém seu modelo e publica uma versão de coordenação segundo regras acordadas.
Isso oferece uma separação saudável entre autoria e integração. O engenheiro elétrico continua responsável pelo modelo elétrico; o estrutural pelo modelo estrutural; a arquitetura pelo seu conteúdo. A coordenação integra e verifica, mas não dissolve a responsabilidade técnica de cada disciplina.
Essa arquitetura também reduz dependência de um único fornecedor de software e facilita a entrada de consultores especializados, fabricantes e contratados que utilizam ferramentas distintas.
IFC, BCF, IDS e bSDD cumprem funções diferentes
No ecossistema Open BIM, diferentes padrões resolvem problemas diferentes. É útil evitar a tentativa de fazer o IFC cumprir todas as funções.
| Recurso | Função predominante |
| IFC | representar e trocar informação estruturada do ativo/modelo |
| BCF | comunicar issues, pontos de vista, comentários e responsabilidades de coordenação |
| IDS | definir e verificar requisitos de informação de forma interpretável por máquina |
| bSDD | apoiar terminologia e definições padronizadas |
Para o projeto, isso significa que um fluxo maduro pode combinar esses recursos. O contratante define requisitos; a equipe publica modelos IFC; a coordenação registra questões em BCF; verificações podem confirmar se informações exigidas estão presentes.
Essa visão é mais robusta do que reduzir Open BIM a “exportar IFC no final”.
IFC e As-Built BIM
A troca aberta também ganha valor na transição para o As-Built e operação. Um modelo final só é útil se representar de forma confiável aquilo que foi entregue e se as informações necessárias ao uso futuro estiverem estruturadas.
Isso não significa que todo As-Built precisa ser entregue em IFC ou que o IFC substitui toda a documentação. Significa que, quando modelos BIM fazem parte da entrega, a estratégia de interoperabilidade deve considerar o futuro da informação.
O artigo sobre As-Built em Engenharia mostra que documentação final não é apenas fechamento administrativo. Ela deve representar o executado e servir de base para operação, manutenção, auditoria e futuras intervenções.
Como validar um arquivo IFC e evitar perdas de informação
A qualidade de um arquivo IFC deve ser avaliada em relação ao uso pretendido. Não existe um critério único capaz de dizer que todo IFC está “correto” para qualquer finalidade.
Um arquivo pode ser adequado para visualização e insuficiente para quantitativos. Pode servir à coordenação geométrica e não conter as propriedades exigidas para entrega ao cliente. Pode conter propriedades completas, porém estar espacialmente deslocado e ser inviável para federação.
Por isso, a validação precisa combinar diferentes dimensões.
Geometria: o modelo está completo e espacialmente correto?
A primeira camada verifica se os elementos esperados estão presentes, se a representação está coerente e se não existem distorções, elementos ausentes, duplicidades ou geometrias inválidas para o uso.
Coordenadas merecem atenção especial. Em projetos multidisciplinares, um modelo deslocado alguns metros pode inviabilizar a coordenação mesmo quando todos os seus elementos internos estão corretos.
Semântica: os objetos continuam sendo o que deveriam ser?
Um equipamento deve chegar com uma representação semântica compatível com o que foi acordado. Objetos exportados em classes genéricas podem abrir normalmente e parecer corretos, mas reduzir significativamente a capacidade de filtragem, verificação, automação e integração.
Esse problema é particularmente relevante quando o modelo autoral usa categorias ou objetos customizados sem mapeamento adequado.
Propriedades: os dados exigidos foram preservados?
Aqui deve existir uma verificação objetiva contra os requisitos. Se o cliente exige identificação, classificação, potência, fabricante ou outro conjunto de propriedades, não basta inspecionar alguns objetos visualmente.
A checagem deve responder se os campos estão presentes, preenchidos, no formato esperado e associados aos objetos corretos.
Um QGBT pode chegar em situações muito diferentes:
| Situação | Arquivo abre? | Troca foi bem-sucedida? |
| geometria e propriedades corretas | sim | sim |
| geometria correta, propriedades ausentes | sim | parcialmente ou não |
| objeto na posição correta, classe inadequada | sim | parcialmente |
| propriedades presentes, mas com nomes/estrutura incompatíveis | sim | depende do uso |
| modelo deslocado por referência espacial incorreta | sim | não para coordenação |
| informação validada contra requisito definido | sim | sim para aquele uso |
A tabela mostra por que “abrir o IFC” é um teste muito fraco.
Geometria correta não garante informação correta.
Um IFC pode parecer perfeito visualmente e ainda falhar no uso porque perdeu classificação, propriedades, relações ou referências necessárias para coordenação, quantitativos ou operação.
Veja como a classificação sustenta informação consistente em BIM
Classificação e identificação: a informação pode ser encontrada e organizada?
Identificadores inconsistentes dificultam comparação entre revisões, rastreamento de issues e integração com outras bases. Classificações mal aplicadas prejudicam filtros, quantitativos, automações e entendimento comum entre equipes.
Por isso, os temas IFC e NBR 15965 se reforçam. O padrão de troca não substitui a necessidade de classificar e organizar a informação de maneira consistente.
Relações e estrutura espacial: o contexto do objeto foi preservado?
Um objeto isolado pode parecer correto, mas perder vínculos relevantes com pavimento, espaço, sistema ou composição. Dependendo do uso, essas relações são tão importantes quanto a geometria.
Em manutenção, por exemplo, saber que um equipamento pertence a determinada sala técnica e sistema pode ser mais útil do que simplesmente visualizar sua posição tridimensional.
Critérios de aceite devem existir antes da primeira entrega
O maior erro de governança é descobrir como validar o IFC somente quando o arquivo chega.
Os critérios precisam ser combinados antes: versão ou especificação aplicável, propósito da troca, objetos obrigatórios, propriedades requeridas, classificação, coordenadas, unidades, formato de identificação, regras de federação e processo de correção.
No Plano de Execução BIM, essas decisões podem ser conectadas à estratégia de produção, softwares, responsabilidades, marcos e testes de mobilização.
Uma matriz de aceite pode ser extremamente prática:
| Critério | Pergunta de validação | Evidência |
| completude | todos os modelos/objetos esperados foram entregues? | comparação com escopo e matriz de entregáveis |
| posição | referências e coordenadas permitem federação? | teste de sobreposição/modelo federado |
| semântica | classes e tipos estão coerentes? | verificação de entidades/objetos |
| propriedades | campos obrigatórios estão presentes e corretos? | checagem de propriedades |
| classificação | códigos requeridos foram aplicados? | regra de classificação |
| versão | arquivo corresponde ao marco e revisão corretos? | CDE e metadados |
| usabilidade | o arquivo atende ao uso para o qual foi solicitado? | teste no fluxo de destino |
O IFC deve ser testado como processo, não apenas como produto final
Projetos complexos não deveriam esperar a primeira grande entrega para descobrir se a interoperabilidade funciona. A abordagem mais segura é executar trocas piloto durante a mobilização.
Seleciona-se um conjunto pequeno, porém representativo, de objetos e informações. Cada disciplina exporta. A coordenação importa ou federa. Verificam-se classes, propriedades, coordenadas, unidades e comportamento. Os problemas são corrigidos antes de escalar a produção.
Esse processo reduz um risco comum: milhares de objetos modelados durante meses segundo uma configuração que só no final se descobre inadequada para a troca exigida.
A interoperabilidade deve, portanto, ser tratada como requisito de engenharia da informação, com método, responsabilidade, verificação e aceite — e não como uma característica presumida do software.
Conclusão
O arquivo IFC é muito mais do que uma extensão usada para abrir modelos BIM em diferentes programas. Ele é uma representação estruturada e aberta da informação do ambiente construído, capaz de apoiar trocas entre aplicações, organizações e fases do ciclo de vida quando utilizado com requisitos e critérios definidos.
Seu valor aparece quando geometria, identidade, semântica, propriedades, classificação e relações são preservadas de acordo com o uso pretendido. Por isso, uma exportação que “abre sem erro” ainda pode ser inadequada para coordenação, quantitativos, validação ou operação.
Em projetos de engenharia, a boa prática é definir antecipadamente o propósito da troca, preparar o modelo autoral, mapear a informação, exportar, validar em ambiente independente, publicar a revisão correta no CDE e devolver issues aos responsáveis pelos modelos de origem. Esse fluxo conecta IFC ao BEP, à gestão da informação, à coordenação, ao Clash Detection, à classificação e ao As-Built.
A ideia central permanece: interoperabilidade não é transportar um arquivo entre softwares. É preservar informação suficiente, com significado e qualidade, para que outro participante consiga utilizá-la de forma confiável. É nesse ponto que IFC se torna infraestrutura de informação para o BIM — e não apenas formato de exportação.
Referências técnicas
Perguntas frequentes
IFC é um padrão aberto para representar e trocar informações BIM entre diferentes aplicações. O arquivo pode conter geometria, identidade, propriedades, relações, estrutura espacial e outros dados conforme o escopo da troca.
Não. BIM é uma metodologia e um processo de produção e gestão da informação do ativo. IFC é um padrão aberto usado para representar e trocar parte dessa informação entre aplicações.
Não necessariamente. O modelo autoral preserva recursos próprios da ferramenta e continua sob responsabilidade da disciplina. O IFC é normalmente usado como representação de troca, coordenação, revisão ou entrega conforme os requisitos do projeto.
IFC é um padrão aberto de informação. Open BIM é uma abordagem mais ampla de colaboração e interoperabilidade baseada em padrões abertos e neutralidade tecnológica. IFC é uma das principais bases técnicas do ecossistema Open BIM.
Não. O arquivo pode abrir e mostrar a geometria, mas ter perdido propriedades, classificação, relações, identificação ou referências espaciais necessárias ao uso pretendido.
A validação deve considerar o uso previsto e pode incluir completude, geometria, coordenadas, classes, propriedades, classificação, relações, unidades, identificação, revisão e aderência aos requisitos de informação.
É parte da estrutura semântica do schema IFC usada para representar tipos de entidades do ambiente construído. Ela não deve ser confundida automaticamente com o nome de uma família ou categoria dentro do software autoral.
MVD significa Model View Definition. É uma definição voltada a determinados casos de uso e requisitos de troca, especificando como um subconjunto ou conjunto de regras do IFC deve ser aplicado para determinada finalidade.
IFC é usado para representar e trocar o modelo e seus dados. BCF é voltado à comunicação e ao gerenciamento de issues, comentários, pontos de vista e responsabilidades de coordenação, complementando o fluxo de trabalho.
Sim, quando o modelo BIM faz parte da entrega final e os requisitos de informação foram definidos. O IFC pode integrar a estratégia de As-Built, mas não substitui automaticamente toda a documentação técnica, validação de campo ou demais entregáveis.
Materiais técnicos complementares
Soluções
- Ambiente Comum de Dados e Gestão da Informação BIM
- Gestão de Requisitos, Evidências e Critérios de Aceite
- Governança de Projetos
Serviços
Guias técnicos
- Guia Completo de BIM e Compatibilização de Projetos
- Guia Completo de Compatibilização de Projetos
- Gerenciamento de Projetos
Whitepapers
Artigos técnicos
- Gestão da Informação em BIM: como aplicar a ISO 19650
- Classificação da Informação em BIM: como aplicar a NBR 15965
- BEP BIM: Plano de Execução BIM
- Coordenação de Projetos de Engenharia
- Clash Detection em Projetos BIM
- As-Built em Engenharia
eBook
