BCF BIM: o que é, como funciona e como gerenciar issues na coordenação de projetos

Entenda BCF BIM, arquivo BCF, viewpoints, status, responsáveis e como gerenciar issues entre modelos e equipes na coordenação BIM.

Confira!

BCF BIM — BIM Collaboration Format — é um padrão openBIM mantido pela buildingSMART para comunicar e gerenciar issues relacionadas a modelos de informação entre diferentes aplicações, equipes e disciplinas. Em vez de transportar novamente o modelo completo a cada conflito, comentário ou solicitação de ajuste, o BCF transporta o contexto da ocorrência: assunto, descrição, responsável, status, prioridade, comentários, ponto de vista e referências aos componentes envolvidos.

Na prática, o BCF cria uma camada de comunicação estruturada sobre o modelo. Uma interferência entre uma viga e um duto, uma inconsistência de classificação, uma solicitação de alteração, uma falha de qualidade ou uma decisão pendente pode ser transformada em uma issue rastreável. A equipe responsável abre a ocorrência no seu ambiente de trabalho, localiza o problema, corrige o modelo autoral e devolve a issue ao fluxo de coordenação para nova verificação.

O padrão pode ser utilizado de duas formas principais: por troca de arquivo BCF, normalmente empacotado para transferência entre aplicações, ou por serviço web/API, no qual as plataformas compartilham tópicos, comentários e estados sem depender da circulação manual de arquivos. Em ambos os casos, a finalidade é a mesma: separar a comunicação sobre o problema do transporte do modelo completo.

A distinção mais importante é simples: IFC transporta informação do modelo; BCF transporta informação sobre uma ocorrência relacionada ao modelo. O BCF não substitui IFC, modelo federado, CDE ou ferramenta de autoria. Ele conecta essas camadas ao permitir que uma incompatibilidade detectada em coordenação seja registrada, atribuída, acompanhada e encerrada com rastreabilidade.

Um fluxo bem estruturado segue uma sequência clara: detectar ou identificar a ocorrência → criar a issue → registrar contexto e evidências → classificar e atribuir responsável → corrigir no modelo autoral → emitir nova revisão → atualizar a federação → revalidar → fechar ou reabrir a issue conforme a evidência. O ganho não está apenas em trocar menos arquivos, mas em transformar conversas dispersas em um processo de engenharia verificável.

O que é BCF BIM e qual problema ele resolve

BCF surgiu para resolver um problema recorrente em ambientes BIM multidisciplinares: o modelo pode ser interoperável, mas a comunicação sobre os problemas encontrados nele ainda pode ser desestruturada.

Imagine uma coordenação com arquitetura, estrutura, elétrica, HVAC e hidráulica. O coordenador encontra um conflito entre um duto e uma viga. Sem um processo estruturado, pode tirar um print, escrever um e-mail, anexar uma imagem, explicar o pavimento, indicar aproximadamente a posição e pedir que a equipe de climatização corrija. A resposta pode vir por outro e-mail; a nova revisão do modelo pode ser publicada dias depois; ninguém sabe com segurança se a ocorrência foi realmente verificada após a correção.

O BCF transforma esse diálogo em uma issue vinculada ao contexto do modelo.

Uma ocorrência pode carregar:

• título e descrição;
• tipo ou categoria;
• status;
• prioridade;
• responsável;
• autor e datas de criação/modificação;
• comentários e histórico;
• viewpoint com câmera e orientação da vista;
• snapshot para referência visual;
• referências aos componentes relacionados;
• documentos ou informações complementares, conforme a implementação;
• dados suficientes para que outra aplicação consiga reencontrar o problema no modelo.

Isso permite que a comunicação seja independente da ferramenta de autoria. Uma equipe pode identificar o problema em uma aplicação de coordenação e outra tratá-lo em uma aplicação diferente, desde que ambas suportem o padrão e consigam mapear corretamente os elementos e o contexto.

BCF não é apenas um formato de arquivo

É comum reduzir BCF a “um arquivo .bcf”. Essa leitura é incompleta.

A buildingSMART mantém tanto a implementação baseada em arquivo quanto a abordagem por serviço web. Na troca baseada em arquivo, os tópicos e viewpoints podem ser empacotados e transferidos entre participantes. No fluxo por API, um servidor ou plataforma de colaboração centraliza as issues e diferentes aplicações consultam e atualizam os mesmos registros.

O segundo modelo reduz um dos principais riscos do round-trip manual: múltiplas cópias paralelas do mesmo arquivo BCF, cada uma com comentários ou estados diferentes.

Issue não é sinônimo de clash

Clash detection é um dos usos mais conhecidos, mas BCF não está restrito a colisões geométricas.

Uma issue pode representar:

• conflito físico entre elementos;
• invasão de zona de manutenção;
• informação ausente ou inconsistente;
• elemento classificado incorretamente;
• problema de acessibilidade;
• solicitação de alteração;
• dúvida de projeto;
• design proposal;
• falha de qualidade;
• pendência de aprovação;
• incompatibilidade funcional ou construtiva;
• necessidade de revisão técnica.

Essa amplitude é importante porque uma boa Coordenação de Projetos de Engenharia não se limita ao que uma regra automática consegue detectar.

Microcenário: o duto foi corrigido, mas a issue ainda não está resolvida

Considere uma viga estrutural interferindo com um duto de climatização. A coordenação gera uma issue com a vista do problema, componentes relacionados, responsável e prioridade alta.

A equipe de HVAC desloca o duto e publica uma nova revisão. O conflito físico desaparece.

Ainda assim, o coordenador precisa verificar se a nova rota:

1. mantém o pé-direito necessário; 2. não invade a zona de manutenção de outro equipamento; 3. respeita o espaço para isolamento; 4. continua compatível com elétrica e hidráulica; 5. não cria nova interferência alguns metros adiante; 6. corresponde à revisão efetivamente compartilhada para coordenação.

Fechar a issue não é registrar que alguém alterou o modelo; é confirmar que a condição que originou a ocorrência foi resolvida de forma aceitável.

O que um arquivo BCF registra sobre uma issue

Uma issue BCF funciona como um pacote de contexto. O objetivo não é duplicar o modelo, mas permitir que uma equipe encontre, compreenda e acompanhe uma ocorrência sem depender de descrições vagas como “problema no shaft do segundo pavimento”.

Tópico: a identidade da ocorrência

O tópico representa a issue propriamente dita. Ele concentra os dados que permitem organizar e gerenciar a pendência.

Em uma governança madura, os campos não devem ser preenchidos de forma livre e inconsistente. Tipo, status, prioridade, responsável e etapa precisam seguir convenções definidas para o empreendimento.

Uma estrutura simples pode ser:

Campo	Exemplo	Função
título	HVAC × EST — duto interfere na viga V-214	identificação rápida
tipo	Clash / Interface	classificação da ocorrência
status	Open / In Progress / Resolved / Closed	estágio do tratamento
prioridade	Alta	criticidade operacional
responsável	Equipe HVAC	ação requerida
disciplina origem	Coordenação BIM	quem registrou
marco	Executivo R02	contexto da entrega
prazo	15/08/2026	compromisso de resolução

Os nomes exatos dependem da implementação e da taxonomia acordada, mas o princípio deve permanecer: a issue precisa ser pesquisável, filtrável e gerenciável.

Viewpoint: reencontrar exatamente o problema

O viewpoint é um dos elementos mais valiosos do BCF. Ele pode registrar o ponto de vista da câmera, projeção, orientação, elementos selecionados, visibilidade e outras informações necessárias para reconstruir a cena na aplicação que recebe a ocorrência.

Isso reduz a dependência de frases como “olhe perto do quadro do corredor”.

Quando o software consegue reconstruir a vista, o responsável abre a issue e é levado diretamente ao contexto relevante.

Referência aos componentes

No workflow openBIM clássico, BCF pode referenciar componentes do modelo por identificadores persistentes, especialmente GUIDs associados aos objetos IFC.

Esse vínculo permite que a issue não seja apenas “uma imagem”. O sistema pode saber que a ocorrência envolve, por exemplo, a viga 3tX... e o duto 1aP....

Isso também explica por que estabilidade de identificação é importante. Se um fluxo de exportação recria GUIDs sem necessidade, o software pode perder a capacidade de relacionar uma issue existente ao objeto atualizado.

Snapshot não substitui o viewpoint

A imagem ajuda a interpretação humana, mas é apenas uma representação visual daquele momento.

Um snapshot não contém sozinho a lógica necessária para reencontrar os componentes, controlar a vista ou navegar pelo modelo. Por isso, processos que exportam apenas capturas de tela para PDF ou planilha perdem parte importante do valor da comunicação model-based.

Comentários constroem o histórico da decisão

Uma issue pode receber comentários ao longo do ciclo:

• coordenação registra o problema;
• projetista solicita esclarecimento;
• responsável propõe solução;
• coordenador pede ajuste adicional;
• nova revisão é emitida;
• condição é revalidada;
• issue é encerrada.

Esse histórico é muito mais útil do que uma sequência de mensagens espalhadas entre e-mail, chat, reunião e relatório.

O ganho aumenta quando o workflow BCF está conectado a um Ambiente Comum de Dados e Gestão da Informação BIM, porque revisão de modelo, estado da informação, emissão e issue deixam de ser tratados como eventos independentes.

Como funciona o fluxo BCF na coordenação de projetos

BCF ganha valor quando faz parte de um processo repetível. Criar tópicos sem definir responsabilidade, estados e critérios de fechamento apenas troca um problema de comunicação informal por uma lista digital de pendências.

1. A ocorrência é identificada

A origem pode ser clash detection, rule checking, design review, coordenação manual, verificação de requisitos, revisão documental ou observação de campo.

Um software pode detectar automaticamente a interseção entre dois elementos. Já uma incompatibilidade funcional pode depender de análise humana.

A Compatibilização de Projetos precisa combinar essas duas dimensões: automação para encontrar padrões verificáveis e engenharia para decidir o que realmente representa risco, incompatibilidade ou necessidade de ajuste.

2. A issue é criada com contexto suficiente

Antes de atribuir a ocorrência, o coordenador registra o problema de forma que outra pessoa consiga entendê-lo sem reconstruir toda a investigação.

Uma boa issue responde:

• o que está errado ou precisa ser decidido?
• onde ocorre?
• quais elementos estão envolvidos?
• qual impacto potencial?
• qual disciplina deve agir?
• qual marco ou revisão está sendo analisado?
• qual evidência demonstra o problema?

Issues como Clash 2456 ou Corrigir duto são pobres. O identificador automático pode existir, mas a descrição precisa expressar o contexto de engenharia.

3. A ocorrência é classificada e atribuída

Nem toda pendência precisa da mesma urgência.

Um conflito que impede concretagem de um elemento estrutural possui natureza diferente de uma inconsistência de nomenclatura sem impacto imediato na execução. Da mesma forma, uma issue de segurança, operação ou manutenção pode ter alta prioridade mesmo sem colisão geométrica.

A matriz de criticidade pode considerar:

Critério	Pergunta
segurança	a condição cria risco para pessoas ou ativo?
execução	impede ou altera sequência construtiva?
custo	pode gerar retrabalho ou mudança relevante?
prazo	ameaça marco de entrega ou liberação?
operação	reduz acesso, manutenção ou disponibilidade?
informação	impede validação ou aceite do modelo?

A responsabilidade também precisa ser objetiva. Uma issue atribuída simultaneamente a cinco equipes tende a não ter dono.

4. A correção ocorre no modelo autoral

O ambiente de coordenação identifica e comunica. A correção técnica deve ocorrer no contêiner controlado pela equipe responsável.

Se a issue indica que uma eletrocalha invade uma viga, a coordenação não deveria mover a eletrocalha apenas para “limpar o clash” no modelo federado. A disciplina elétrica avalia alternativas, corrige seu modelo, executa sua verificação interna e publica nova revisão conforme o processo definido.

Essa lógica preserva autoria e responsabilidade técnica, exatamente como ocorre no Modelo Federado BIM.

5. A nova revisão volta ao processo

A issue e a revisão do modelo são objetos diferentes.

Uma nova versão do modelo pode resolver a ocorrência ou criar outra. Por isso, não é suficiente anexar a frase “corrigido na R08”. A coordenação precisa carregar ou acessar a revisão correta, atualizar a federação e repetir a verificação pertinente.

Esse ponto conecta BCF diretamente ao CDE BIM: a equipe precisa saber qual revisão foi compartilhada, qual estado possui e para qual uso está autorizada.

6. A issue é revalidada antes de fechar

O status Resolved pode significar “a equipe responsável informou que corrigiu”. O status Closed deveria representar que a condição foi verificada conforme o processo adotado.

Separar esses estados evita que a mesma pessoa que executa a correção encerre unilateralmente uma ocorrência que exige verificação independente.

Para problemas críticos, o fechamento pode exigir evidência adicional: nova captura, regra executada novamente, comentário do coordenador, aprovação de disciplina afetada ou validação de requisito.

7. A issue pode ser reaberta

Mudanças posteriores podem reintroduzir um problema aparentemente resolvido.

Se a arquitetura move uma parede, a rota de elétrica é alterada e uma interferência previamente encerrada reaparece, o histórico anterior não deve ser perdido. Reabrir ou relacionar a nova ocorrência preserva a cadeia de decisão.

A recorrência também é um indicador importante de qualidade. Se o mesmo tipo de issue reaparece dezenas de vezes, o problema pode estar no padrão de modelagem, na matriz de responsabilidades ou no próprio processo de coordenação.

BCF, IFC, modelo federado e CDE: qual o papel de cada um

A melhor forma de compreender BCF é colocá-lo ao lado das outras peças do fluxo BIM.

Camada	Função principal	Pergunta que responde
modelo autoral	produzir informação da disciplina	quem cria e responde pelo conteúdo?
IFC	estruturar/trocar informação do modelo	como compartilhar o conteúdo entre aplicações?
modelo federado	agregar modelos para análise conjunta	como enxergar e verificar interfaces?
BCF	comunicar e gerenciar issues	como registrar, atribuir e acompanhar o problema?
CDE	governar contêineres, estados e revisões	qual informação é válida e para qual uso?
compatibilização	verificar coerência entre soluções	as interfaces estão tecnicamente resolvidas?

BCF e IFC são complementares

O Arquivo IFC no BIM carrega classes, propriedades, relações, geometria e estrutura do modelo conforme o escopo da troca. BCF pode referenciar objetos e posições relacionados a esse modelo sem reenviar todo o conteúdo a cada comentário.

Um modo simples de visualizar:

IFC: “este é o modelo que estamos coordenando.”

BCF: “este é o problema encontrado nesse contexto, estes objetos estão envolvidos, esta equipe precisa agir e este é o estado da resolução.”

BCF e modelo federado

A federação cria o contexto conjunto onde muitas ocorrências são encontradas. O BCF transforma os achados em unidades de trabalho controláveis.

Sem gestão de issues, uma sessão de clash detection pode produzir centenas de conflitos, relatórios e prints sem um mecanismo consistente para distribuir responsabilidade e verificar resolução.

Sem federação confiável, por outro lado, o BCF pode apenas registrar problemas produzidos por modelos errados, revisões inadequadas ou referências espaciais inconsistentes.

BCF e CDE

BCF não substitui o CDE.

Uma plataforma de issues pode saber que o tópico 438 está In Progress, mas isso não significa que a revisão R08 do modelo elétrico esteja autorizada para coordenação. O CDE controla o estado dos contêineres de informação; o workflow BCF controla o ciclo das ocorrências.

Quando as duas camadas estão integradas, a equipe consegue relacionar melhor:

• issue;
• modelo/revisão analisada;
• responsável;
• decisão;
• nova emissão;
• revalidação;
• aceite.

A solução de Gestão de Requisitos, Evidências e Critérios de Aceite é aderente a essa lógica quando o empreendimento precisa transformar pendências, requisitos e comprovações em condições objetivas de liberação.

BCF e Open BIM

O BCF faz parte do ecossistema de padrões abertos da buildingSMART. Isso permite que comunicação de issues não fique necessariamente presa à plataforma que detectou o problema.

Em uma estratégia Open BIM, esse desacoplamento é importante: uma equipe pode coordenar em uma ferramenta, outra modelar em outra e ambas compartilhar informação de problemas por um protocolo comum.

Mas interoperabilidade não é automática. É necessário testar se as aplicações preservam corretamente viewpoints, objetos referenciados, status, comentários e demais dados importantes para o processo.

Como estruturar uma gestão de issues BIM confiável

A tecnologia resolve apenas parte do problema. Uma lista BCF com 4.000 tópicos sem convenções, filtros, responsáveis e critérios de fechamento pode ser tão difícil de gerenciar quanto uma planilha mal estruturada.

Defina a taxonomia antes de gerar issues em escala

O projeto precisa decidir quais valores serão permitidos para tipo, status, prioridade, disciplina, etapa e demais campos relevantes.

Uma estrutura possível:

Tipos: Clash, Informação, Interface, Construtibilidade, Operação, Segurança, Documentação, Mudança.

Status: Open, In Progress, Resolved, Closed, Rejected.

Prioridade: Crítica, Alta, Média, Baixa.

Etapa: Conceitual, Básico, Executivo, Construção, As-Built.

O objetivo não é criar burocracia. É impedir que uma equipe registre alta, outra urgente, outra P1 e outra resolver logo, tornando filtros e indicadores inúteis.

Separe status de prioridade

Status responde onde a issue está no fluxo. Prioridade responde quão importante é tratá-la.

Uma issue pode estar Open e ser baixa prioridade. Outra pode estar In Progress e ser crítica. Misturar as duas dimensões prejudica planejamento e análise de risco.

Defina quem pode criar, atribuir, resolver e fechar

Em projetos pequenos, todos podem fazer tudo. Em empreendimentos complexos, isso gera inconsistência.

Um workflow mais robusto pode separar:

• quem registra a ocorrência;
• quem valida se a issue é real;
• quem atribui responsabilidade;
• quem corrige o modelo;
• quem informa resolução;
• quem revalida;
• quem encerra.

A Gestão BIM e Informação de Engenharia pode estruturar essa governança junto com BEP, matriz de responsabilidades, CDE, estratégia de federação e regras de coordenação.

Evite uma issue para cada alerta bruto

Uma execução de clash detection pode retornar centenas ou milhares de colisões que pertencem ao mesmo problema de projeto.

Se dez segmentos do mesmo duto atravessam a mesma viga por causa de uma única decisão de rota, criar dez issues independentes aumenta o ruído sem melhorar a engenharia.

Antes de publicar os tópicos, é útil:

1. eliminar falsos positivos; 2. agrupar ocorrências equivalentes; 3. separar problemas sistêmicos de casos isolados; 4. priorizar por impacto; 5. atribuir ao responsável correto; 6. relacionar issues quando houver dependência.

Essa curadoria é uma das diferenças entre relatório automático e Clash Detection em Projetos BIM orientado a decisão.

Trate issues que não aparecem como clash

Em projetos críticos, parte das ocorrências mais relevantes é funcional.

Um QGBT pode não colidir com nenhum elemento e ainda estar sem área segura de acesso. Uma válvula pode caber no shaft e ser impossível de operar. Duas rotas redundantes podem estar separadas geometricamente, mas atravessar o mesmo compartimento de risco. Um equipamento pode estar perfeitamente modelado e sem identificação necessária para operação.

Essas ocorrências surgem por análise crítica, não apenas por interseção geométrica.

O serviço de Revisão e Validação Técnica de Projetos — Design Review complementa a coordenação BIM quando as decisões precisam considerar desempenho, operação, manutenção, construtibilidade, riscos e maturidade do projeto.

Base de campo ruim não se resolve com issue management

Em retrofit, brownfield e ativos existentes, a equipe pode começar a registrar issues contra um modelo que não representa a condição real.

Se uma eletrocalha instalada não aparece no cadastro, nenhuma gestão BCF compensará essa ausência. O problema precisa ser resolvido na fonte de informação.

Quando a documentação existente é incompleta ou divergente, a A3A Engenharia pode estruturar a condição de base por meio de Site Survey e Levantamento Cadastral de Edificações, Instalações e Infraestruturas. Em avaliações mais amplas de condição, conformidade e risco do ativo, a Due Diligence Técnica de Engenharia pode preceder o projeto e a coordenação.

Essa sequência evita uma falsa precisão digital: issues extremamente bem documentadas sobre uma base que está errada.

Meça qualidade do processo, não apenas quantidade de issues

O número bruto de tópicos diz pouco sobre maturidade.

Indicadores mais úteis podem incluir:

Indicador	O que revela
issues abertas por marco	carga de pendências
idade média das issues	velocidade de tratamento
issues vencidas	aderência a prazos
taxa de reabertura	qualidade da resolução
recorrência por tipo	falhas sistêmicas
issues por disciplina/interface	concentração de problemas
tempo até atribuição	eficiência de triagem
tempo entre resolved e closed	velocidade de revalidação
issues críticas abertas	risco residual

Uma queda repentina no número de issues não significa necessariamente melhora. A equipe pode simplesmente ter reduzido a detecção ou passado a fechar tópicos sem revalidar.

Fechamento precisa ter critério de aceite

A maior maturidade aparece quando o estado final é baseado em evidência.

Para uma incompatibilidade geométrica, o critério pode ser a repetição da verificação no modelo federado atualizado.

Para uma questão funcional, pode ser necessário revisar acesso, manutenção, documentação ou requisito específico.

Para uma inconsistência informacional, pode ser necessário validar propriedade, classificação, identificação ou completude.

A gestão de issues deixa então de ser uma lista de tarefas e passa a funcionar como parte do sistema de assurance do projeto.

Conclusão

BCF BIM transforma problemas encontrados em modelos e processos de coordenação em issues estruturadas, rastreáveis e interoperáveis. O padrão permite comunicar uma ocorrência com contexto de modelo, responsável, status, comentários e viewpoint, sem exigir a retransmissão do modelo completo a cada interação.

Seu valor aparece principalmente quando a issue permanece conectada ao processo de engenharia. O problema é identificado em um modelo ou revisão conhecida, recebe classificação e responsável, volta à equipe autora para correção, retorna ao ambiente de coordenação em nova revisão, é revalidado e só então encerrado.

BCF não substitui IFC, modelo federado, CDE, compatibilização ou análise crítica. Cada camada responde a uma parte diferente do processo: o modelo contém a solução; IFC permite a troca estruturada; a federação cria o contexto multidisciplinar; BCF organiza as ocorrências; o CDE governa a informação válida; e a engenharia decide se a interface realmente está resolvida.

Em projetos novos, essa governança precisa nascer junto com os requisitos, BEP, CDE, matriz de responsabilidades e estratégia de coordenação. Em ativos existentes, a confiabilidade pode depender ainda antes de levantamentos de campo e consolidação cadastral. Quanto melhor a base, menor o risco de usar uma excelente ferramenta de issue management para administrar problemas produzidos por informação incorreta.

O resultado esperado não é uma plataforma cheia de tópicos fechados. É um projeto no qual cada ocorrência relevante possui contexto, dono, decisão, evidência e rastreabilidade até a resolução.

Referências técnicas

[1] BUILDINGSMART INTERNATIONAL. BIM Collaboration Format (BCF). Standard communication protocol for issue management and coordination on BIM projects.

[2] BUILDINGSMART INTERNATIONAL. BIM Collaboration Format (BCF) — An Introduction. buildingSMART Technical.

[3] ABNT. ABNT NBR ISO 19650-2:2022 — Organização e digitização da informação sobre edifícios e obras de engenharia civil, incluindo BIM — Gestão da informação usando BIM — Parte 2: Fase de entrega de ativos.

[4] BIM FÓRUM BRASIL. Coletânea de Gerenciamento e Coordenação de Projetos em BIM — Guia Coordenação de Projetos de Edificações em BIM. São Paulo, 2026.

Perguntas frequentes

O que é BCF BIM?

BCF BIM, ou BIM Collaboration Format, é um padrão openBIM para comunicar e gerenciar issues relacionadas a modelos entre diferentes aplicações e equipes, registrando contexto, responsável, status, comentários, viewpoints e referências aos elementos envolvidos.

Qual a diferença entre BCF e IFC?

IFC transporta a informação estruturada do modelo, como geometria, classes, propriedades e relações. BCF transporta o contexto de uma issue relacionada ao modelo, como problema, responsável, status, comentários e viewpoint.

O que é um arquivo BCF?

É uma forma de serializar e trocar tópicos BCF entre aplicações. O padrão também pode operar por serviços web/API, sem depender da circulação manual de arquivos.

BCF serve apenas para clash detection?

Não. BCF pode registrar clashes, problemas de informação, solicitações de alteração, questões de qualidade, incompatibilidades funcionais, design proposals, pendências de aprovação e outras issues relacionadas ao processo BIM.

O BCF contém o modelo BIM completo?

Não. O BCF transporta dados da ocorrência e referências ao contexto do modelo. O modelo permanece em seus formatos e ambientes próprios.

O que é um viewpoint no BCF?

É a informação que permite reconstruir a vista associada à issue, incluindo câmera, orientação, componentes selecionados ou visíveis e outros dados necessários para localizar o problema no modelo.

Quem deve corrigir uma issue BCF?

A correção técnica deve ocorrer no modelo autoral da equipe responsável pela disciplina. A issue comunica e acompanha o problema; não transfere a autoria do modelo para a equipe de coordenação.

Quando uma issue BCF pode ser fechada?

Quando a condição que originou a ocorrência foi revalidada conforme o critério definido. Informar que o modelo foi alterado não é suficiente quando o processo exige verificação independente.

BCF substitui o CDE?

Não. BCF controla o ciclo das issues; o CDE governa contêineres de informação, revisões, estados, permissões e condições de uso. As duas camadas podem ser integradas.

Quando levantamento técnico deve preceder a gestão de issues BIM?

Em retrofit, brownfield e ativos existentes, quando plantas, modelos ou cadastros não representam com confiabilidade a condição instalada. Site Survey e Levantamento Cadastral podem ser necessários antes da modelagem, federação e coordenação.

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
• Gestão Eletrônica de Documentos Técnicos e Controle de Revisões

Serviços

• Gestão BIM e Informação de Engenharia
• Site Survey
• Levantamento Cadastral de Edificações, Instalações e Infraestruturas
• Due Diligence Técnica de Engenharia
• Compatibilização de Projetos

Guias técnicos

• Guia Completo de BIM e Compatibilização de Projetos
• Guia Completo de Compatibilização de Projetos

Whitepapers

• Compatibilização de Projetos BIM: framework técnico para coordenação, interoperabilidade, governança e aceite

Artigos técnicos

• Modelo Federado BIM
• Clash Detection em Projetos BIM
• CDE BIM
• Arquivo IFC no BIM
• Open BIM