IFC 4.3 para rodovias no Civil 3D: o guia que faltava

Você recebe um edital que exige a entrega do projeto em IFC. Abre o Civil 3D, procura o botão de exportar... e descobre que o assunto é um território quase sem mapa: pouca documentação, quase nada em português, e um modelo que sai do outro lado como um amontoado de sólidos genéricos sem nome. Se essa cena parece familiar, este guia é para você.

Por que "IFC de rodovia" sempre foi terreno obscuro

O IFC (Industry Foundation Classes) nasceu no mundo das edificações: paredes, portas, lajes, pilares. Durante duas décadas, o schema simplesmente não tinha vocabulário para infraestrutura linear. Uma rodovia exportada em IFC 2x3 ou IFC 4 virava uma coleção de IfcBuildingElementProxy — geometria sem semântica nenhuma. O software do outro lado enxergava sólidos, mas não sabia o que era pista, acostamento, corte ou aterro.

O resultado prático: BIM de infraestrutura rodoviária ficou anos atrás do BIM de edificações, e virou especialidade de pouquíssimos profissionais. No Brasil e em Portugal, então, o assunto é quase folclore — todo mundo já ouviu falar, quase ninguém viu funcionando de ponta a ponta.

O que muda com o IFC 4.3

Em 2024, o IFC 4.3 foi publicado como norma internacional (ISO 16739-1:2024). É a primeira versão do schema com entidades nativas para infraestrutura: rodovias, ferrovias, pontes, portos e o alinhamento geométrico que costura tudo isso. Pela primeira vez, o modelo exportado pode saber o que ele é:

Repare no padrão por trás dessa tabela, porque ele é a chave para ler qualquer modelo de infraestrutura. O IFC 4.3 generalizou o conceito de edifício: IfcBuilding deixou de ser o centro do schema e virou um caso particular de IfcFacility — a obra, seja ela qual for. Ao lado dele estão IfcRoad, IfcBridge, IfcRailway e IfcMarineFacility. E cada um tem a sua parte: IfcRoadPart, IfcBridgePart e companhia são todos IfcFacilityPart.

Daí vem a espinha dorsal de todo modelo de infraestrutura, que não muda de obra para obra:

IfcProject — o projeto: unidades, georreferenciamento, autoria
└─ IfcSite — o terreno
   └─ IfcFacility — a obra   (IfcRoad, IfcBridge, IfcRailway, IfcMarineFacility…)
      └─ IfcFacilityPart — a parte dela   (IfcRoadPart, IfcBridgePart…)
         └─ os objetos   (pavimento, terraplenagem, sinalização…)

Os quatro degraus são amarrados pela mesma relação, IfcRelAggregates — inclusive o primeiro, do projeto para o terreno. Aprendida uma vez, essa espinha serve para a rodovia, para o viaduto e para o pátio ferroviário do mesmo contrato. É por isso que, daqui para a frente, toda árvore deste post começa igual.

Vamos construir o modelo: do IfcSite ao pavimento

A melhor forma de entender o IFC 4.3 é fazer o que fazemos na obra: construir por etapas. Começamos pelo caso mais simples — uma estrutura de pavimento — e vamos subindo a complexidade até chegar ao ponto onde quase todo fluxo IFC quebra.

No IFC, todo objeto físico mora dentro de uma hierarquia espacial — pense nela como o endereço de engenharia do objeto: a obra (IfcSite), a rodovia (IfcRoad) e o trecho (IfcRoadPart). No fim desse endereço ficam os elementos físicos: o pavimento (IfcPavement) e cada camada dele (IfcCourse):

IfcProject — Duplicação da Rodovia Exemplo
└─ IfcSite — Terreno da obra
   └─ IfcRoad — Rodovia Exemplo   (um IfcFacility)
      └─ IfcRoadPart.ROADSEGMENT — Trecho 01   (um IfcFacilityPart)
         └─ IfcRoadPart.CARRIAGEWAY — Pista
            └─ IfcPavement.FLEXIBLE — Pavimento
               ├─ IfcCourse — Revestimento (CBUQ)
               ├─ IfcCourse — Base (brita graduada)
               ├─ IfcCourse — Sub-base
               └─ IfcCourse — Reforço do subleito

Repare no que isso significa: o revestimento deixa de ser "sólido 47" e passa a ser uma camada nomeada, de um pavimento, de uma pista, de um trecho, de uma rodovia. Um software de orçamento consegue somar o volume de CBUQ da Rodovia Exemplo inteira com uma consulta — sem abrir o desenho, sem adivinhar nada pelo nome de camada do CAD.

Subindo um degrau: a terraplenagem

Agora vamos ampliar o modelo para o item de maior volume — e maior custo — de qualquer rodovia. O IFC 4.3 trata a terraplenagem com entidades dedicadas: o corte é IfcEarthworksCut, e o aterro é IfcEarthworksFill, com o tipo EMBANKMENT para o corpo do aterro:

IfcProject — Duplicação da Rodovia Exemplo
└─ IfcSite — Terreno da obra
   └─ IfcRoad — Rodovia Exemplo
      └─ IfcRoadPart.ROADSEGMENT — Trecho 02
         ├─ IfcEarthworksFill.EMBANKMENT — Corpo do aterro
         ├─ IfcEarthworksFill.SLOPEFILL — Talude de aterro
         ├─ IfcGeographicElement.VEGETATION — Revestimento vegetal do talude de corte
         ├─ IfcGeographicElement.VEGETATION — Revestimento vegetal do talude de aterro
         └─ IfcGeotechnicalStratum — Terreno natural
            ╌╌╌ IfcEarthworksCut.CUT — Corte   (não é filho: vaza o terreno, IfcRelVoidsElement)

Clique em qualquer imagem para ampliar.

Repare no talude de aterro: ele não é "mais um sólido de aterro" — é um IfcEarthworksFill do tipo SLOPEFILL, que o schema define como o aterro de saia: a cunha lateral, encostada ao corpo da estrada. Cuidado com a geometria, porque a confusão é fácil: SLOPEFILL não é uma camada assentada sobre o aterro — é a porção lateral do próprio maciço, executada com material ou compactação diferentes do núcleo.

E cuidado com uma confusão comum aqui: SLOPEFILL não é material — é função.

O IFC guarda em quatro camadas independentes aquilo que na obra a gente costuma dizer numa palavra só. Separá-las resolve a maior parte das dúvidas de classificação:

As quatro variam sozinhas. Um mesmo SLOPEFILL pode ser de solo selecionado numa obra e de rachão em outra, sem que a classificação mude — trocar o material nunca deve virar uma entidade nova. É o erro mais caro que se comete aqui, porque ele multiplica classes no modelo e quebra a soma de quantitativos.

Daí vem a pergunta que decide se o talude merece existir na árvore: ele foi construído como uma massa distinta do corpo do aterro? Se a saia é executada em solo selecionado, com compactação ou material próprios, sim — é um elemento com quantitativo próprio. Se o aterro é homogêneo, o corpo inteiro é um único EMBANKMENT e o "talude" é apenas a face geométrica dele; criar um sólido separado ali seria inventar material que não existe — o mesmo teste de honestidade do talude de corte.

Já o revestimento vegetal é uma pegadinha clássica: a tentação é usar IfcCourse, mas o schema define course como camada de material granular processado (brita, areia, asfalto) — serve para um enrocamento (IfcCourse.PROTECTION ou ARMOUR), não para grama. Para a cobertura vegetal, a classificação correta é IfcGeographicElement.VEGETATION, cuja definição — "plant life or plant cover" — inclui expressamente gramíneas. Classificado assim, a área de hidrossemeadura vira um quantitativo consultável no modelo, em vez de uma conta feita à parte na planilha.

E o talude de corte? A resposta não é uma convenção nossa: está no próprio schema. Este é o modelo inteiro de um trecho de terraplenagem em IFC 4.3 — do projeto até os recursos, com as relações que amarram tudo:

O trecho é o pivô: tudo que é matéria pendura nele por IfcRelContainedInSpatialStructure. O corte, não — ele é um vazio, e vazio o schema proíbe de entrar na estrutura espacial. Repare também que há uma só caixa de IfcEarthworksFill com dois papeis: é o papel que muda, nunca a classe.

← arraste o esquema para o lado →

E o talude de corte? Aqui o IFC captura uma assimetria que todo engenheiro de terraplenagem conhece: no aterro, o talude é um maciço que você constrói — por isso ele existe como sólido próprio (SLOPEFILL). No corte, não há sólido novo: a face do talude é o solo existente que ficou exposto pela escavação — e a escavação em si é o IfcEarthworksCut do tipo CUT, que o schema prevê para o corte de rodovias e ferrovias.

E não vale a tentação simétrica de reaproveitar o SLOPEFILL aqui: fill, por definição do schema, é material acrescentado — "criado por atividades de terraplenagem para construir o subleito ou elevar o nível do terreno". A face do talude de corte não foi acrescentada, foi descoberta. (O "back slope fill" que aparece na definição do SLOPEFILL é aterro colocado junto ao talude — uma berma, por exemplo —, não a face escavada.) Se você precisa do talude de corte com quantitativo próprio, ele continua sendo escavação: um segundo IfcEarthworksCut, e não um fill.

O que entra de novo no modelo é apenas o revestimento vegetal aplicado sobre essa face — de novo um IfcGeographicElement.VEGETATION.

E onde entra o revestimento aplicado no talude depois da escavação — dentro do corte? Não, e aqui o próprio schema encerra a discussão: no IFC 4.3, IfcEarthworksCut não é um sólido, é um feature element de subtração, definido literalmente como "o vazio resultante da remoção de material". Um vazio não hospeda elemento físico nenhum — não existe "dentro do corte". O revestimento, esse sim, é um produto real, executado sobre a face exposta depois que a escavação terminou: ele vive por conta própria na estrutura espacial, no trecho, como irmão dos sólidos de terraplenagem.

O mesmo raciocínio vale para o talude de aterro. Ali existe sólido — mas o revestimento é aplicado sobre ele, não é camada constituinte do maciço, e aninhar significaria declarar composição: grama não compõe aterro. Em ambos os casos, a amarração "este revestimento cobre aquele talude" é registrada em propriedades e relações próprias do IFC, não na hierarquia espacial.

O conceito é o mesmo do pavimento — o que muda é a escala do problema. Num corredor real, cada material gera os seus próprios sólidos, trecho a trecho: corte, aterro, remoção de solo mole, camada vegetal... São centenas de objetos para classificar num único projeto. Guarde essa dor: é ela que separa quem "já tentou exportar IFC" de quem entrega.

O calcanhar de Aquiles: objetos compostos

Até aqui, cada objeto do modelo era uma coisa só — uma camada, um sólido de corte. Mas a estrada está cheia de objetos que são conjuntos: uma placa de sinalização é chapa + poste + fundação. Um pórtico, um semáforo, uma defensa com terminais — a mesma história.

E aqui mora o problema mais profundo do fluxo IFC no Civil 3D: para a exportação nativa, um bloco é um único objeto IFC. A placa inteira sai agrupada como um só elemento genérico. Adeus quantitativo de postes, adeus fundações no modelo, adeus verificação de interferência da sapata com a drenagem.

O IFC 4.3 tem a resposta certa para isso: o IfcElementAssembly do tipo SIGNALASSEMBLY — o conjunto como um nó, e cada peça como um elemento próprio dentro dele. Uma placa R-24a bem exportada aparece no viewer exatamente assim:

IfcProject — Duplicação da Rodovia Exemplo
└─ IfcSite — Terreno da obra
   └─ IfcRoad — Rodovia Exemplo
      └─ IfcRoadPart.ROADSIDE — Faixa lateral do Trecho 01
         └─ IfcElementAssembly.SIGNALASSEMBLY — R-24aESQ_3
            ├─ IfcSign — L-PLACA (a chapa)
            ├─ IfcMember — L-POSTE (o suporte)
            └─ IfcFooting — L-SAPATA (a fundação)

Cada peça selecionável e quantificável individualmente, com sua cor e seu estilo preservados, e o conjunto inteiro aninhado no trecho correto da rodovia. É o tipo de granularidade que um coordenador BIM nota na primeira auditoria do modelo.

E como se faz isso no Civil 3D?

Você acabou de ver o que um modelo IFC 4.3 bem-feito precisa ter. A Autodesk disponibiliza uma extensão oficial (IFC 4.3 Extension for Civil 3D, instalada à parte) que faz a exportação — mas o problema não é exportar, é classificar. Os caminhos nativos para dizer "este sólido é um IfcCourse" são, digamos, espartanos:

• Objeto a objeto: criar em cada objeto um Property Set com o nome exato IfcObject Properties e a propriedade IFC::IfcExportAs com o valor da entidade (ex.: IfcRoadPart.ROADSEGMENT). Um caractere errado e a classificação é ignorada — silenciosamente.
• Por arquivo de configuração: editar na mão um IfcInfraExportMapping.json com expressões regulares, sem interface gráfica e com documentação mínima.

Multiplique isso pelas centenas de sólidos do capítulo da terraplenagem — e lembre que a decomposição de conjuntos simplesmente não existe no caminho nativo. É por isso que tanta gente desiste no meio.

Como resolvemos isso no SCENG Tools

Foi exatamente essa dor, dentro dos nossos próprios projetos, que deu origem ao IFC 4.3 Manager do módulo SCENG Manager. A ideia: você define regras de engenharia, e o plugin cuida da burocracia do schema.

Regras em vez de digitação

Classifique por camada, estilo ou nome do objeto, com curingas — uma regra L-PLACA* pega todas as placas do projeto de uma vez. Enquanto você edita a regra, um contador ao vivo mostra quantos objetos do desenho casam com ela, antes de aplicar qualquer coisa.

Hierarquia espacial de verdade

O export monta a árvore Site → IfcRoad → IfcRoadPart → objetos, e os nomes vêm dos Property Sets do próprio projeto: a rodovia sai do outro lado nomeada "Rodovia Exemplo — Pista Principal", não "Corridor (1)". E a mesma lógica vale para outros domínios — um viaduto classificado como IfcBridge aninha como ponte, não como rodovia.

Conjuntos decompostos automaticamente

A árvore da placa R-24a que você viu acima saiu do Civil 3D exatamente daquele jeito. Uma regra no bloco define o conjunto (IfcElementAssembly.SIGNALASSEMBLY) e regras-filhas, pelas camadas internas do bloco, definem as peças: chapa, poste, sapata. O plugin decompõe, classifica, exporta e limpa tudo sozinho — sem explodir o seu desenho.

Não precisa acreditar na palavra: este é o IFC exportado pelo plugin, aberto aqui no seu navegador. Abra a árvore até R-24aESQ_3: a placa vem decomposta em L-PLACA, L-POSTE e L-SAPATA. Abrir em tela cheia →

Exceções? Edição manual com undo

Para os casos que fogem à regra, uma grade de edição manual objeto a objeto, com desfazer/refazer, sincronizada com as regras gerais.

Projetos IFC reutilizáveis

Regras, hierarquia, responsável pelo modelo e ponto base georreferenciado ficam salvos como um Projeto IFC — um arquivo que você reaproveita no próximo desenho da mesma obra ou compartilha com a equipe. Configurou uma vez, exportou a obra inteira.

O fluxo na prática

1. Instale a IFC 4.3 Extension da Autodesk e o SCENG Tools;
2. Na aba Manager do ribbon SCENG, abra o IFC 4.3 Manager;
3. Carregue os objetos do desenho (ou herde a seleção do PSet Manager);
4. Aplique um modelo de regras pronto ou crie as suas, acompanhando o preview;
5. Preencha uma vez os dados do projeto (nome da obra, responsável, ponto base);
6. Clique em Exportar IFC — a exportação usa a extensão oficial da Autodesk por baixo, com o modelo já classificado e hierarquizado.

Brasil e Portugal: por que agora

No Brasil, a segunda fase do Decreto 10.306/2020 está em vigor desde 2024, exigindo BIM em projetos e obras públicas federais — e DNIT e DERs estaduais já publicam editais com requisitos BIM explícitos. Em Portugal, a normalização avança com a CT 197, e a diretiva europeia de contratação pública permite ao dono de obra exigir BIM nos concursos.

A consequência é simples: a exigência de IFC em infraestrutura vai crescer mais rápido do que a oferta de gente que sabe entregá-lo. Dominar esse fluxo hoje é um diferencial competitivo raro — amanhã será pré-requisito.

O esquema completo, em uma página

Juntando os três degraus, é assim que a obra inteira fica no modelo — do reforço do subleito à sapata da placa:

IfcProject — Duplicação da Rodovia Exemplo
└─ IfcSite — Terreno da obra
   └─ IfcRoad — Rodovia Exemplo   (um IfcFacility)
      ├─ IfcAlignment — Eixo principal
      ├─ IfcRoadPart.ROADSEGMENT — Trecho 01
      │  └─ IfcRoadPart.CARRIAGEWAY — Pista
      │     └─ IfcPavement.FLEXIBLE — Pavimento
      │        ├─ IfcCourse — Revestimento (CBUQ)
      │        ├─ IfcCourse — Base (brita graduada)
      │        ├─ IfcCourse — Sub-base
      │        └─ IfcCourse — Reforço do subleito
      ├─ IfcRoadPart.ROADSEGMENT — Trecho 02
      │  ├─ IfcEarthworksFill.EMBANKMENT — Corpo do aterro
      │  ├─ IfcEarthworksFill.SLOPEFILL — Talude de aterro
      │  ├─ IfcGeographicElement.VEGETATION — Revestimento vegetal do talude de corte
      │  ├─ IfcGeographicElement.VEGETATION — Revestimento vegetal do talude de aterro
      │  └─ IfcGeotechnicalStratum — Terreno natural
      │     ╌╌╌ IfcEarthworksCut.CUT — Corte   (vaza o terreno, não é filho)
      └─ IfcRoadPart.ROADSIDE — Faixa lateral
         └─ IfcElementAssembly.SIGNALASSEMBLY — R-24aESQ_3
            ├─ IfcSign — L-PLACA
            ├─ IfcMember — L-POSTE
            └─ IfcFooting — L-SAPATA

Um modelo que responde bem a essas cinco perguntas já está à frente da imensa maioria dos IFC de infraestrutura que circulam por aí.

Checklist antes de entregar o IFC

Comece hoje

O IFC 4.3 Manager faz parte do módulo SCENG Manager (PSet / IFC 4.3), incluído também no SCENG Full. Se o seu Civil 3D está na versão 2026.2.2 ou superior, veja antes qual versão do plugin usar.

Equipe SCENG — sempre inovando para facilitar o seu trabalho no Civil 3D.