Clash Detection em Projetos BIM

Entenda o que é Clash Detection, os tipos de interferência, como configurar testes, controlar issues e por que detectar colisões não substitui a compatibilização.

Confira!

Clash Detection é o processo automatizado ou semiautomatizado de comparar elementos de modelos tridimensionais para identificar colisões, sobreposições, violações de afastamento e outras interferências previamente definidas. Em projetos BIM, ele permite localizar conflitos entre arquitetura, estrutura, instalações, infraestrutura e sistemas antes que esses problemas cheguem à execução.

A detecção, porém, não resolve sozinha a compatibilização. O software aponta ocorrências conforme os modelos, seleções, regras e tolerâncias configuradas; a equipe técnica precisa interpretar cada resultado, eliminar falsos positivos, agrupar ocorrências repetidas, atribuir responsáveis, avaliar impactos e verificar a correção nas revisões seguintes.

Por isso, o valor do Clash Detection não está na quantidade de colisões geradas, mas na capacidade de transformar resultados geométricos em decisões técnicas rastreáveis. Um processo mal configurado pode produzir milhares de registros irrelevantes. Um processo bem governado concentra a análise nas interfaces críticas e reduz retrabalho, improvisações, atrasos e riscos de implantação.

Neste artigo, o termo é tratado no contexto de projetos de engenharia e BIM. O foco não é uma ferramenta específica, mas o método para preparar modelos, configurar testes, classificar interferências, controlar ocorrências e integrar a detecção ao processo mais amplo de compatibilização.

O que é Clash Detection em projetos BIM

Clash Detection, ou detecção de interferências, é a análise computacional da relação espacial entre conjuntos de elementos de um ou mais modelos. A ferramenta verifica se os objetos se intersectam ou descumprem condições geométricas configuradas, como distâncias mínimas, envelopes de manutenção e zonas de segurança.

A análise pode ser executada em um modelo federado, que reúne modelos disciplinares sem retirar a autoria de cada projetista. Arquitetura, estrutura, elétrica, hidráulica, climatização, incêndio, automação, segurança eletrônica, telecomunicações e outras disciplinas permanecem separadas, mas são visualizadas e comparadas em conjunto.

O resultado típico é uma lista de ocorrências associadas a elementos, localização, visualização, teste de origem e status. Dependendo da plataforma, cada ocorrência pode receber comentário, prioridade, responsável, prazo, imagem, viewpoint, classificação e histórico de tratamento.

Hard clash: colisão física

O hard clash ocorre quando duas geometrias ocupam o mesmo espaço. Exemplos incluem:

duto de climatização atravessando uma viga;
eletrocalha cruzando tubulação;
luminária sobreposta a sprinkler;
conduíte atravessando equipamento;
câmera inserida em elemento estrutural;
quadro elétrico ocupando área destinada a porta;
tubulação penetrando shaft fora da abertura prevista.

É o tipo mais evidente, mas nem toda interseção representa erro. Elementos que devem se conectar, penetrar ou sobrepor podem gerar colisões legítimas. Por isso, o teste precisa definir corretamente quais conjuntos serão comparados e quais exceções devem ser consideradas.

Soft clash: afastamento ou folga insuficiente

O soft clash ocorre quando os elementos não se intersectam, mas violam uma distância mínima. A regra pode representar:

espaço de manutenção;
faixa de abertura de portas e painéis;
distância de segurança elétrica;
segregação entre energia e telecomunicações;
afastamento de fontes de calor;
espaço para retirada de filtros, módulos ou baterias;
área de giro ou movimentação de equipamento;
envelope de acesso de equipe e ferramentas.

Esse tipo exige tolerância tecnicamente definida. Uma distância arbitrária produz resultados sem significado. O valor deve vir de requisito, norma, fabricante, procedimento de manutenção, critério do proprietário ou análise de risco.

Clash de duplicidade ou sobreposição interna

Modelos também podem conter objetos duplicados, elementos sobrepostos ou geometrias repetidas. Esses erros podem distorcer quantitativos, exportações, análises e coordenação.

A ocorrência pode surgir dentro da própria disciplina, não apenas entre disciplinas. Por isso, a auditoria deve incluir testes internos quando houver risco de duplicidade, especialmente após cópias, vínculos, importações ou consolidação de modelos.

Clash temporal ou 4D

Quando modelos são associados ao cronograma, a análise pode verificar interferências no tempo. Exemplos incluem:

duas frentes ocupando a mesma área simultaneamente;
equipamento de içamento cruzando zona de trabalho;
montagem prevista antes da liberação do acesso;
estrutura temporária incompatível com instalação definitiva;
rota de transporte bloqueada por atividade concorrente;
manutenção planejada durante indisponibilidade de sistema redundante.

O clash temporal não se limita à geometria final. Ele analisa estados intermediários, métodos, equipamentos temporários e sequência de implantação.

Verificação por regras não é sempre Clash Detection

Nem toda checagem automatizada é uma colisão. Ferramentas podem verificar parâmetros, propriedades, classificação, dimensões, inclinação, acessibilidade, completude de dados ou aderência a requisitos. Essas análises são complementares, mas devem ser identificadas corretamente.

É importante separar:

Verificação	Pergunta principal	Exemplo
Hard clash	dois elementos ocupam o mesmo espaço?	eletrocalha atravessa viga
Soft clash	o afastamento mínimo foi respeitado?	painel sem área de manutenção
Duplicidade	existem objetos repetidos?	dois equipamentos no mesmo ponto
Regra de informação	propriedades e dados estão corretos?	equipamento sem código ou potência
Verificação funcional	o sistema atende ao requisito?	câmera possui cobertura adequada?
Compatibilização	as disciplinas e decisões estão coordenadas?	alimentação, rede, suporte e acesso estão integrados?

Clash Detection não é compatibilização

A Compatibilização de Projetos em BIM utiliza a detecção de interferências como uma de suas ferramentas, mas possui escopo mais amplo. Ela trata interfaces físicas, funcionais, documentais, normativas, construtivas e operacionais.

O Clash Detection pode indicar que uma eletrocalha atravessa um duto. Ele não decide automaticamente:

qual disciplina deve alterar a rota;
qual sistema possui prioridade técnica;
se existe capacidade em outro caminho;
se a mudança afeta carga, queda de tensão ou comprimento;
se o novo trajeto respeita manutenção e segregação;
se a alteração modifica quantitativos, orçamento ou prazo;
quais documentos precisam ser revisados;
quem aprova a solução final.

Essas decisões pertencem à coordenação e à compatibilização. Da mesma forma, o Design Review em Projetos de Engenharia analisa requisitos, cálculos, documentos, riscos e maturidade, indo além da geometria.

Detectar colisões não significa compatibilizar o projeto. O software localiza ocorrências geométricas; a equipe de engenharia precisa decidir prioridades, responsabilidades, impactos e documentos afetados para transformar cada resultado em uma solução coordenada.

Conheça o serviço de Compatibilização e Integração de Projetos

Por que a quantidade bruta de clashes pode enganar

Um modelo federado pode retornar centenas ou milhares de colisões. Esse número, isoladamente, não representa a qualidade do projeto nem a quantidade real de problemas.

Uma única causa pode gerar dezenas de registros. Um duto que atravessa uma sequência de elementos pode aparecer como várias colisões. Objetos compostos podem produzir uma ocorrência para cada componente. Geometrias simplificadas, tolerâncias inadequadas e elementos de referência também ampliam artificialmente a lista.

Falsos positivos

Falsos positivos são resultados que atendem matematicamente à regra, mas não configuram problema técnico. Exemplos:

conexão prevista entre tubo e equipamento;
eletroduto embutido em parede;
suporte associado ao elemento suportado;
isolamento modelado sobre a própria tubulação;
abertura estrutural criada para passagem;
sobreposição proposital em elemento de acabamento;
geometrias de reserva ou construção auxiliares.

A equipe deve estabelecer filtros e critérios de exclusão, sem ocultar problemas reais.

Resultados repetidos

Ocorrências próximas podem representar a mesma causa. Agrupar por ambiente, sistema, elemento principal, disciplina, zona ou decisão reduz ruído e facilita a atribuição.

O agrupamento não deve apagar a rastreabilidade. A ocorrência consolidada precisa preservar quais elementos, locais e resultados foram abrangidos.

Tolerância inadequada

Tolerância zero pode gerar conflitos decorrentes de precisão numérica, superfícies coincidentes ou pequenos desvios sem relevância construtiva. Tolerância excessiva pode ocultar interferências importantes.

A configuração deve considerar:

unidade e precisão do modelo;
fase do projeto;
disciplina;
método construtivo;
tamanho dos elementos;
folgas necessárias;
margem de instalação;
nível de informação disponível.

Modelo imaturo ou inadequado

Clash Detection não corrige modelo incompleto, desatualizado ou mal coordenado. Se elementos críticos não foram modelados, não haverá colisão a detectar. Se a geometria é apenas simbólica, o resultado pode ser enganoso.

Ausências frequentes incluem suportes, acessórios, zonas de acesso, aberturas, isolamento, inclinação, equipamentos temporários, envelopes de manutenção e elementos existentes.

O indicador correto não é apenas “clashes restantes”

Indicadores mais úteis incluem:

ocorrências críticas abertas;
taxa de fechamento por ciclo;
reincidência após correção;
tempo médio de resposta;
ocorrências por disciplina e interface;
percentual de falsos positivos;
conflitos aceitos com justificativa;
problemas descobertos em campo que deveriam ter sido detectados;
estabilidade dos modelos entre ciclos.

Como preparar os modelos para Clash Detection

Executar testes antes da auditoria dos modelos costuma gerar resultados pouco confiáveis. A preparação precisa assegurar que os arquivos podem ser federados, comparados e rastreados.

Definir o escopo da coordenação

O plano deve indicar:

disciplinas participantes;
áreas, pavimentos e zonas;
versões e datas de corte;
formatos de troca;
elementos incluídos e excluídos;
nível de informação necessário;
tolerâncias;
prioridades de sistema;
responsáveis;
ciclos de análise;
critérios de fechamento.

Nem todos os elementos precisam ser comparados com todos. A matriz de testes deve refletir interfaces reais.

Verificar coordenadas e referências

Modelos precisam compartilhar origem, orientação, níveis, pavimentos, unidades e sistema de coordenadas. Pequenos desalinhamentos podem gerar colisões generalizadas ou ocultar conflitos.

A auditoria deve verificar:

ponto-base e origem;
norte e rotação;
cotas e níveis;
unidades;
georreferenciamento, quando aplicável;
posição de vínculos;
transformação de arquivos importados;
coerência entre modelo, levantamento e realidade.

Controlar versões

Uma federação com revisões diferentes produz decisões sobre configurações inexistentes. Cada arquivo deve possuir código, disciplina, revisão, data, status e responsável.

Modelos liberados para coordenação devem ser separados de arquivos de trabalho. O processo precisa impedir que um teste combine arquitetura atualizada com estrutura antiga ou instalações ainda não emitidas.

Verificar integridade e qualidade

Antes dos testes, convém analisar:

elementos duplicados;
geometrias corrompidas;
objetos fora da área do projeto;
categorias incorretas;
propriedades ausentes;
elementos excessivamente detalhados;
vínculos quebrados;
objetos não classificados;
nomes e códigos inconsistentes;
elementos temporários não identificados.

Definir o nível de informação necessário

Modelar tudo com máximo detalhamento não é requisito para boa coordenação. O modelo precisa conter informação suficiente para a decisão da etapa.

No Projeto Conceitual, podem ser suficientes volumes, espaços e rotas principais. No Projeto Básico, devem aparecer equipamentos, shafts, caminhos e interfaces críticas. No Projeto Executivo, espera-se geometria e informação compatíveis com aquisição, fabricação, instalação e manutenção.

Detalhe insuficiente oculta conflitos. Detalhe excessivo aumenta processamento, ruído e custo sem benefício proporcional.

Preparar conjuntos de seleção

Testes robustos devem usar conjuntos baseados em propriedades, classificações e sistemas, evitando seleções manuais frágeis.

Exemplos:

todas as vigas estruturais;
dutos acima de determinada seção;
eletrocalhas de energia;
tubulações de incêndio;
equipamentos que exigem acesso frontal;
portas de painéis;
cabos ou leitos de telecomunicações;
elementos por pavimento ou zona.

Conjuntos reutilizáveis facilitam a repetição dos testes em novas revisões.

A qualidade do resultado começa antes da execução do teste. Coordenadas, revisões, classificação, nível de informação e conjuntos de seleção precisam estar consistentes; caso contrário, o software apenas automatiza os problemas dos modelos recebidos.

Aprofunde o processo de Compatibilização de Projetos em BIM

Como montar uma matriz de Clash Detection

A matriz define quais conjuntos serão comparados, por que o teste existe, qual tolerância deve ser usada e quem responde pela interface.

Teste	Conjunto A	Conjunto B	Tipo	Objetivo
CD-01	estrutura	dutos de climatização	hard	evitar passagens não previstas
CD-02	estrutura	eletrocalhas	hard	verificar rotas e aberturas
CD-03	hidráulica	elétrica	hard	eliminar cruzamentos incompatíveis
CD-04	painéis elétricos	envelope frontal	soft	garantir operação e manutenção
CD-05	luminárias	sprinklers	soft	preservar instalação e desempenho
CD-06	portas	equipamentos e mobiliário	soft	verificar abertura e circulação
CD-07	leitos de telecom	potência	soft	verificar segregação definida
CD-08	equipamentos	rotas de retirada	soft	garantir substituição futura
CD-09	modelos disciplinares	elementos duplicados	duplicate	controlar sobreposições
CD-10	frentes de obra	áreas e equipamentos temporários	temporal	evitar conflito de sequência

Priorizar interfaces críticas

A matriz não deve começar com todas as combinações possíveis. Priorize interfaces que possam afetar:

segurança;
estrutura;
continuidade operacional;
sistemas críticos;
espaços de difícil alteração;
equipamentos de longo prazo;
rotas principais;
manutenção;
marcos de procurement;
liberação de frentes.

Definir tolerâncias por finalidade

Uma mesma tolerância não serve para todos os testes. O valor deve considerar dimensão, risco e capacidade de ajuste em campo.

Pode haver:

tolerância geométrica de detecção;
folga mínima de instalação;
envelope de manutenção;
zona de segurança;
distância de segregação;
reserva para expansão;
margem de fabricação e montagem.

A matriz deve registrar a fonte do critério.

Evitar testes sem responsável

Cada teste precisa possuir dono técnico. A responsabilidade pode ser da coordenação, de uma disciplina líder ou do responsável pela interface. Sem responsável, a ocorrência permanece apenas como dado do software.

Processo de Clash Detection passo a passo

1. Definir objetivo e critério de decisão

O ciclo deve começar por uma pergunta concreta. Exemplos:

liberar shafts e salas técnicas;
validar rotas principais;
congelar aberturas estruturais;
liberar modelo para orçamento;
preparar Projeto Executivo;
revisar documentação de fornecedor;
confirmar condição para início da instalação.

A finalidade determina modelos, testes, tolerâncias e severidade.

2. Receber e auditar os modelos

A equipe verifica versões, coordenadas, integridade, classificação, completude e aderência aos requisitos de troca. Arquivos inadequados devem ser devolvidos ou registrados com limitação.

3. Federar os modelos

A federação reúne as disciplinas para análise conjunta. O processo precisa preservar autoria, códigos, revisões e estrutura dos arquivos.

O modelo federado não substitui os modelos de autoria. Ele é um ambiente de coordenação.

4. Configurar e executar os testes

Os testes devem utilizar conjuntos definidos, regras documentadas e tolerâncias justificadas. Convém registrar versão da matriz, data, ferramenta, modelos analisados e responsável pela execução.

5. Fazer triagem técnica

A triagem remove ou classifica:

falsos positivos;
ocorrências aceitas;
duplicidades;
registros da mesma causa;
problemas fora do escopo;
conflitos críticos;
conflitos que dependem de decisão.

Essa etapa não deve ser delegada apenas ao operador da ferramenta. Exige conhecimento das disciplinas e do empreendimento.

6. Agrupar ocorrências

Agrupamentos podem ser feitos por:

ambiente;
pavimento;
shaft;
sistema;
elemento principal;
disciplina responsável;
causa comum;
solução esperada;
frente de execução.

Um grupo deve representar uma decisão técnica administrável.

7. Criar e atribuir issues

Cada issue precisa conter informação suficiente para ser compreendida sem depender de reunião informal.

Campos recomendados:

Campo	Conteúdo
Identificador	código único
Teste de origem	regra que gerou a ocorrência
Localização	pavimento, ambiente, eixo ou coordenada
Elementos	IDs e disciplinas envolvidas
Viewpoint	visualização reproduzível
Descrição	problema e efeito esperado
Severidade	crítica, alta, média ou baixa
Prioridade	ordem de tratamento
Responsável	autor da correção ou decisão
Prazo	data de resposta e fechamento
Status	novo, ativo, respondido, aprovado, resolvido ou fechado
Evidência	revisão ou documento que comprova a solução

O BIM Collaboration Format pode transportar issues entre ferramentas sem transferir novamente todo o modelo.

8. Analisar a causa e decidir a solução

A resposta não deve ser apenas “mover o elemento”. É necessário avaliar requisitos, hierarquia dos sistemas, capacidade, espaço, acesso, custo, prazo e impacto documental.

Possíveis tratamentos incluem:

alterar rota;
mudar cota;
redimensionar shaft;
criar abertura;
revisar equipamento;
alterar suporte;
coordenar sequência;
aceitar conflito com justificativa;
modificar requisito;
solicitar informação adicional.

9. Atualizar os modelos de autoria

A correção deve ocorrer no modelo responsável. Alterar apenas o modelo federado ou marcar a ocorrência como resolvida sem revisar a fonte quebra a rastreabilidade.

Documentos associados também podem precisar de revisão: desenhos, memoriais, listas, quantitativos, especificações, cálculos e cronogramas.

10. Reexecutar os testes

Na nova revisão, os testes são repetidos. A equipe verifica se:

o conflito desapareceu;
a solução não criou novo problema;
os documentos estão coerentes;
a interface foi efetivamente fechada;
a configuração analisada corresponde à revisão emitida.

11. Fechar com evidência

Uma ocorrência deve ser fechada quando a solução foi incorporada e verificada. Resposta textual sem revisão correspondente não é evidência suficiente.

Clashes aceitos precisam registrar justificativa, autoridade e condição. Um conflito pode ser tecnicamente aceitável, mas não deve simplesmente desaparecer da lista.

Issue respondida não é issue fechada. O fechamento exige revisão incorporada, teste reexecutado e evidência verificada. Quando a solução altera requisitos, contratos, equipamentos ou linha de base, a mudança também precisa ser formalmente controlada.

Veja como o Design Review controla comentários, evidências e decisão de avanço

Como classificar severidade, prioridade e status

Severidade representa o impacto técnico. Prioridade representa a ordem de tratamento. Os conceitos não são idênticos.

Severidade	Caracterização	Efeito típico
Crítica	risco de segurança, inviabilidade, conflito estrutural ou bloqueio de sistema essencial	impede avanço
Alta	alteração relevante de rota, espaço, equipamento ou interface	exige decisão antes do próximo marco
Média	ajuste localizado com impacto controlável	corrigir no ciclo corrente
Baixa	pequena inconsistência sem efeito sistêmico	pode ser tratada em revisão posterior
Observação	melhoria ou dúvida sem conflito confirmado	avaliar e documentar

A prioridade pode aumentar quando existe item de longo prazo, frente prestes a ser liberada, área de difícil acesso ou decisão que afeta várias disciplinas.

Status recomendado

Um fluxo pode utilizar:

novo: identificado no ciclo atual;
ativo: confirmado e aguardando tratamento;
em análise: depende de decisão ou informação;
respondido: responsável apresentou disposição;
aprovado: solução aceita para implementação;
resolvido: teste não encontra mais a interferência;
fechado: evidência e documentos foram verificados;
aceito: conflito permanece com justificativa formal;
reaberto: solução foi insuficiente ou criou nova inconsistência.

A ferramenta pode usar nomenclatura diferente. O importante é definir o significado e os critérios de transição.

BCF, CDE, Engios e rastreabilidade

BCF para comunicação de issues

O BCF permite registrar localização, elementos, visualização, comentários e dados de uma ocorrência vinculada ao modelo. Ele reduz dependência de capturas soltas e planilhas desconectadas.

O formato não substitui o processo de governança. A equipe ainda precisa definir classificação, responsáveis, prazos, status, aprovações e regras de fechamento.

Ambiente Comum de Dados

O CDE organiza publicação, compartilhamento, revisão, aprovação e histórico dos contêineres de informação. Ele deve distinguir arquivos de trabalho, compartilhados, publicados e arquivados conforme o processo adotado.

A federação deve utilizar modelos autorizados para coordenação. A presença de um arquivo no repositório não significa que ele está liberado.

Engios como camada de governança

O Engios pode controlar documentos, revisões, emissões, responsáveis, comentários, aprovações, entregáveis, evidências e indicadores. Em um fluxo integrado, as ocorrências do modelo podem ser associadas a documentos, decisões, contratos e marcos do projeto.

Essa camada é especialmente útil quando o problema não termina no modelo. Uma interferência pode exigir revisão de memorial, aprovação do proprietário, mudança contratual, aquisição diferente ou atualização do As-Built.

NetBox como contexto da infraestrutura

Em projetos de redes e Data Centers, o NetBox pode fornecer dados de sites, racks, dispositivos, interfaces, circuitos, cabos, energia e endereçamento. Ele não executa Clash Detection, mas ajuda a validar se a solução coordenada é coerente com a infraestrutura lógica e física existente.

Uma rota geometricamente livre pode estar associada a rack sem capacidade, porta inexistente, circuito indisponível ou topologia incompatível. A integração entre modelo e fonte de verdade amplia a qualidade da decisão.

O modelo não deve ser a única fonte de decisão. BCF e CDE organizam a comunicação, o Engios controla documentos e aprovações, e o NetBox acrescenta o contexto da infraestrutura instalada. A integração reduz decisões baseadas em arquivos isolados.

Conheça o Engios para governança técnica de projetos e documentos

Exemplos de Clash Detection em sistemas de engenharia

Instalações elétricas

Testes podem comparar eletrocalhas, leitos, barramentos, conduítes, quadros, luminárias e equipamentos com estrutura, arquitetura, hidráulica e climatização.

Além de hard clashes, devem ser modelados ou verificados envelopes para abertura de portas, retirada de disjuntores, ventilação, acesso frontal e lateral e segregação de circuitos.

Cabeamento estruturado e telecomunicações

Rotas de telecom podem conflitar com potência, climatização, tubulações, forros, estrutura e sistemas de incêndio. A detecção ajuda a verificar caminhos, travessias e ocupação espacial.

Ela não confirma sozinha distância máxima do enlace, capacidade do rack, raio de curvatura, desempenho, certificação ou topologia. Esses aspectos exigem Design Review e análise específica.

CFTV

A geometria pode identificar câmera inserida em estrutura, suporte incompatível ou rota de infraestrutura conflitante.

Não detecta automaticamente cobertura, densidade de pixels, iluminação, contraluz, oclusão dinâmica, retenção, banda ou cibersegurança. Uma câmera sem colisão pode estar tecnicamente mal posicionada.

Controle de acesso

Podem ser avaliados leitores, fechaduras, controladoras, caixas, eletrodutos, portas e envelopes de abertura.

A compatibilização precisa incluir ferragens, emergência, incêndio, rota de fuga, alimentação, lógica e integração com outros sistemas.

SPDA e aterramento

Captores, condutores, descidas, eletrodos e conexões podem ser coordenados com arquitetura, estrutura, cobertura, elétrica e equipamentos.

A ausência de clash não comprova análise de risco, distância de separação, equipotencialização, continuidade ou seleção de DPS.

Data Centers

Clash Detection é relevante para eletrocalhas, busways, dutos, tubulações, racks, contenções, equipamentos, pisos, forros e rotas de manutenção.

Em ambientes críticos, devem ser considerados redundância, separação entre caminhos, manutenção concorrente, expansão e substituição. Duas rotas podem não colidir e ainda compartilhar o mesmo risco físico.

Retrofit e instalações existentes

Modelos podem ser comparados com nuvens de pontos ou levantamento cadastral. Isso ajuda a detectar incompatibilidades entre projeto e condição real.

A confiabilidade depende da qualidade do levantamento, do registro de áreas ocultas e da atualização das alterações realizadas em campo.

O que Clash Detection não consegue garantir

A ferramenta não garante, por si só:

atendimento a requisitos funcionais;
conformidade normativa completa;
cálculo correto;
capacidade do sistema;
desempenho;
seletividade ou proteção elétrica;
cobertura de CFTV;
lógica de automação;
cibersegurança;
acessibilidade;
construtibilidade completa;
sequência de implantação;
operação e manutenção;
compatibilidade contratual;
atualização de todos os documentos;
aceite do proprietário.

Esses temas precisam ser integrados ao Design Review, à análise de Construtibilidade, à Engenharia de Valor e à governança de mudanças.

Clash Detection nas etapas do projeto

Projeto Conceitual

A análise pode utilizar volumes, zonas e rotas principais para evitar arquiteturas inviáveis. O objetivo não é encontrar detalhes, mas proteger espaços e interfaces críticas.

Projeto Básico e FEED

Devem ser coordenados arranjos, shafts, salas, equipamentos principais, rotas, aberturas, acessos e requisitos de manutenção. Interferências estruturais e decisões de grande impacto precisam ser resolvidas antes do detalhamento.

Projeto Executivo

Os testes tornam-se mais específicos. Modelos devem refletir equipamentos, acessórios, conexões, suportes, folgas, aberturas, níveis e interfaces necessárias à execução.

O modelo sem clashes não deve ser automaticamente considerado “liberado para construção”. A liberação depende também de documentos, cálculos, aprovações, procurement e critérios contratuais.

Procurement e documentos de fornecedores

Modelos e desenhos de fornecedores podem alterar dimensões, pesos, acessos, pontos de conexão e requisitos. A coordenação precisa incorporar esses dados antes da fabricação ou instalação.

Execução e comissionamento

Mudanças de campo devem retornar ao processo. Caso contrário, o modelo coordenado deixa de representar a instalação real.

A atualização final precisa alimentar documentação As-Built, operação, manutenção e gestão de ativos.

Modelo sem clashes não equivale a projeto liberado. A decisão de avançar precisa considerar cálculos, documentos, requisitos, procurement, construtibilidade, riscos e condicionantes, além da situação das interferências geométricas.

Entenda como o Owner’s Engineering apoia revisão, coordenação e aceite

Entregáveis de um processo de Clash Detection

O escopo pode incluir:

plano de coordenação;
requisitos de informação;
lista de modelos e revisões;
relatório de auditoria dos modelos;
modelo federado;
matriz de testes;
regras e tolerâncias;
registro de ocorrências;
arquivos BCF;
viewpoints e imagens;
relatórios por disciplina, área e severidade;
atas de coordenação;
matriz de responsabilidades;
dashboard de pendências;
relatório de fechamento por ciclo;
lista de conflitos aceitos;
parecer de prontidão para o próximo marco.

O entregável não deve ser apenas uma planilha com milhares de linhas. Ele precisa apoiar decisões e demonstrar o que foi analisado, corrigido, aceito e ainda permanece aberto.

Indicadores para acompanhar a coordenação

Indicadores possíveis:

Indicador	Finalidade
ocorrências novas por ciclo	medir estabilidade dos modelos
ocorrências críticas abertas	controlar risco de avanço
taxa de fechamento	acompanhar resposta das disciplinas
tempo médio de resolução	identificar gargalos
reincidência	avaliar qualidade das correções
falsos positivos	revisar configuração dos testes
issues sem responsável	verificar governança
conflitos aceitos	controlar exceções
ocorrências por interface	localizar áreas de maior risco
problemas descobertos em campo	avaliar eficácia do processo

Metas puramente quantitativas podem incentivar fechamento indevido. A qualidade da solução deve prevalecer sobre a redução artificial do número de registros.

Erros frequentes

executar testes antes de auditar os modelos;
usar coordenadas inconsistentes;
comparar revisões diferentes;
configurar todas as disciplinas contra todas;
aplicar uma única tolerância;
considerar todo resultado um problema real;
apagar falsos positivos sem registrar regra de exclusão;
não agrupar ocorrências repetidas;
atribuir issues sem explicar a decisão necessária;
tratar clash como responsabilidade exclusiva do BIM Manager;
fechar ocorrência com resposta textual;
corrigir apenas no modelo federado;
não revisar desenhos e memoriais associados;
ignorar envelopes de manutenção;
limitar a análise a hard clashes;
considerar modelo sem clashes como projeto aprovado;
não incorporar dados de fornecedores;
não atualizar o As-Built.

Checklist para liberar um ciclo de Clash Detection

[ ] objetivo e marco de decisão estão definidos;
[ ] modelos e revisões foram identificados;
[ ] coordenadas, unidades e níveis foram auditados;
[ ] nível de informação é adequado à etapa;
[ ] matriz de testes foi aprovada;
[ ] tolerâncias possuem justificativa;
[ ] conjuntos de seleção são reproduzíveis;
[ ] falsos positivos foram tratados por regra;
[ ] ocorrências repetidas foram agrupadas;
[ ] issues possuem responsável e prazo;
[ ] conflitos críticos foram resolvidos ou condicionados;
[ ] correções foram incorporadas aos modelos de autoria;
[ ] documentos afetados foram atualizados;
[ ] testes foram reexecutados;
[ ] evidências foram verificadas;
[ ] conflitos aceitos possuem justificativa;
[ ] relatório de fechamento foi emitido;
[ ] modelos liberados correspondem às revisões analisadas.

Clash Detection é uma ferramenta poderosa para antecipar interferências, mas seu resultado depende da qualidade dos modelos, da configuração dos testes e da governança aplicada às ocorrências. Quando integrado à compatibilização, ao Design Review, à construtibilidade e ao controle de mudanças, ele deixa de ser uma simples contagem de colisões e passa a apoiar decisões técnicas confiáveis ao longo do projeto.

Referências técnicas

[1] AUTODESK. Visão geral da ferramenta Clash Detective. Autodesk Help.

[2] BUILDINGSMART INTERNATIONAL. BIM Collaboration Format (BCF).

[3] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 19650-1:2018 — Information management using building information modelling — Concepts and principles.

[4] ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. ABNT NBR ISO 19650 — Organização e digitalização de informações sobre edificações e obras de engenharia, incluindo modelagem da informação da construção.

[5] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 7817-1:2024 — Building information modelling — Level of information need — Part 1: Concepts and principles.

Perguntas frequentes

O que é Clash Detection?

É a análise automatizada ou semiautomatizada de modelos tridimensionais para identificar colisões, sobreposições, violações de afastamento e outras interferências definidas por regras.

Clash Detection é o mesmo que compatibilização de projetos?

Não. O Clash Detection identifica ocorrências geométricas conforme regras configuradas. A compatibilização interpreta os resultados, coordena disciplinas, resolve interfaces e atualiza documentos e decisões.

Quais são os principais tipos de clash?

Os principais são hard clash, quando geometrias se intersectam; soft clash, quando uma folga mínima é violada; duplicidades; e clashes temporais associados à sequência de implantação.

Um modelo sem clashes está aprovado para execução?

Não. A ausência de colisões não comprova requisitos, cálculos, desempenho, conformidade normativa, construtibilidade, documentação ou aceite do proprietário.

O que é falso positivo em Clash Detection?

É uma ocorrência que atende matematicamente à regra, mas não representa um problema técnico, como uma conexão prevista, elemento embutido ou sobreposição intencional.

Como definir a tolerância de um teste?

A tolerância deve considerar finalidade, etapa, disciplina, método construtivo, precisão do modelo, folgas de instalação, manutenção, segurança e requisitos aplicáveis.

Para que serve o BCF?

O BCF permite trocar issues vinculadas ao modelo, incluindo elementos, localização, viewpoints, comentários, responsáveis e status, sem transferir novamente todo o modelo BIM.

Quem deve resolver os clashes?

A coordenação administra o processo, mas a solução depende dos projetistas e responsáveis pelas disciplinas e interfaces. O BIM Manager ou operador da ferramenta não deve decidir sozinho alterações técnicas.