Reynaldo Cosati Medeiros
reynaldo@prodec.com
O padrão IFC, criado e mantido pela buildingSMART International é considerado padrão da Indústria da Construção para o intercâmbio de informações digitais entre os diversos players do processo construtivo como projetistas, fornecedores, empreiteiros, supervisores, gerenciadoras, seguradoras e clientes.
Este padrão, que faz parte do mundo openBIM, segue os fundamentos da tecnologia BIM que foi construida sob os pilares da Colaboração, Informação, Geometria, Ciclo de Vida e Interoperabilidade. Para que isso ocorra de forma eficiente em um Modelo IFC, devemos priorizar todos os itens realmente importantes para a construção, onde destacamos:
Representação Espacial (3D) dos objetos que serão construídos (ou desconstruídos) contendo as suas características e relacionamentos com outros objetos;
Hierarquia Espacial dos objetos visando facilitar a organização, visualização e planejamento da obra;
Quantidades de produtos, mão de obra, materiais e serviços que serão demandados para executar o que se representa;
Organização do Tempo necessário para que a obra ocorra (planejamento da obra e elaboração de cronograma)
Com todas essas informações, é possível estimar o Orçamento da Obra, fundamental no processo de Tomada de Decisão de qualquer empreendimento de engenharia.
Na versão IFC 4.3.2 publicada em abril de 2024, foram introduzidos conceitos que permitiram modelar infraestruturas lineares como rodovias, ferrovias, dutovias, canais, linhas de transmissão e outras obras lineares que antes não se encaixavam no padrão.
Como o esquema do IFC (IFC_SCHEMA) é extremamente abrangente, a própria metodologia propõe serem criados o que ela chama de MVD (Model View Definition), que seria um subconjunto das entidades, tipos, propriedades, funções e regras contidos no IFC_SCHEMA para atender a um específico nicho da engenharia. A MVD retira tudo o que não é necessário para o nicho estudado e simplifica a estrutura do modelo.
IFC_SCHEMA 4.3.2 Completo
MVD é um subconjunto do IFC_SCHEMA acima.
A principal vantagem de se adotar uma MVD em projetos BIM é alcançar a padronização. Sem um padrão, o mesmo projeto pode ser modelado de diferentes formas usando o IFC, que é bastante abrangente e tolerante, permitindo diferentes interpretações semânticas dependendo do software BIM utilizado.
A padronização garante de que todos os players estão falando a mesma linguagem.
No desenvolvimento do RODOBIM concluímos ser fundamental seguir um padrão de modelagem BIM que cobrisse todos os aspectos de uma obra rodoviária. Procuramos informações sobre o estado da arte do BIM rodoviário no Brasil e no mundo e verificamos que o BIM, no setor rodoviário, começou forte pelas Obras de Arte Especiais, cuja disciplina é a que mais se assemelha a uma Construção Civil, berço da tecnologia BIM. Não conseguimos encontrar nenhuma informação consolidada sobre o restante das disciplinas que envolvem uma obra rodoviária como terraplenagem, drenagem viária ou pavimentação, apesar do padrão IFC já dar suporte a todas essas áreas.
Na falta de um padrão consolidado, estudamos a possibilidade de desenvolver um que atendesse as normas brasileiras e fosse eficiente em uma obra rodoviária.
A tarefa de desenvolver um modelo IFC rodoviário completo é extremamente ambiciosa, pois o modelo deve suportar diferentes Níveis de Desenvolvimento (LOD).
No caso específico de rodovias (e ferrovias), o modelo deve nascer no Estudo de Viabilidade (LOD 100), crescer com um Plano Funcional ou Anteprojeto (LOD 200), amadurecer no Projeto Básico (LOD 300), consolidar no Projeto Executivo (LOD 400) para então ser utilizado na obra e depois, através do As Built (LOD 500), continuar a ser utilizado na operação da rodovia. São diversos Níveis de Desenvolvimento envolvendo diferentes aplicações BIM neste processo.
Não temos a pretensão, neste momento, de desenvolver todo esse trabalho, mas sim de construir um padrão de modelagem IFC para o segmento rodoviário brasileiro focado na obra e no As Built (LOD 500), a partir das entregas do projeto executivo (LOD 400) e seguindo o padrão IFC 4.3.2 e os conceitos consolidados nos principais manuais de projeto e de custos rodoviários utilizados no Brasil.
Acreditamos na importância da padronização e neste documento propomos uma convenção no uso das novas entidades apresentadas no IFC 4.3.2 em uma obra rodoviária.
Iremos contemplar nesse documento as seguintes disciplinas de uma obra rodoviária e que já podem ser modeladas no padrão IFC 4.3.2:
Não contemplaremos nesse momento:
Meio Ambiente (merece uma MVD específica, pois os assuntos são muito diversos e ligados a organismos ambientais como IBAMA e ICMBIO, assuntos variam entre passivos ambientais, medidas compensatórias, APAs e áreas onde habitam espécies protegidas);
Túneis (a entidade IfcTunnel está prevista para ser incluída no IFC 4.4);
Obras de Arte Especiais;
Obras Complementares;
Contenções
O padrão IFC é descrito na linguagem EXPRESS que é fácil de entender, mas difícil de codificar. Normalmente ninguém escreve diretamente em EXPRESS, mas em alguma das linguagens com suporte a IFC como C++, Python ou JavaScript. Todas permitem criar o arquivo IFC na linguagem EXPRESS.
Optamos por escrever esse documento na forma de manual técnico, porque provavelmente será utilizado por engenheiros e desenvolvedores cujo principal intuito será a construção de um modelo IFC Rodoviário para o seu projeto.
Em cada disciplina, iremos demonstrar a sua modelagem também com um trecho de código em EXPRESS para exemplificação.
O objetivo final deste trabalho é estabelecer uma MVD para o segmento rodoviário com base no estado da arte do padrão IFC 4.3.2 para ser utilizada em aplicativos que a suportam, como BlenderBIM (Bonsai), usBIM, RodoBIM, NavisWorks e muitos outros. Esta MVD deve ser atualizada sempre que houver uma alteração relevante no padrão IFC.
Iniciaremos com o nivelamento de alguns conceitos que devem ser compreendidos para a modelagem correta de uma obra rodoviária usando IFC. É importante entender que num único arquivo IFC está contido todo o projeto com as suas quantidades e especificações, toda a geometria espacial, todos os serviços a serem executados e a sua ordenação (cronograma) e também todos os custos envolvidos. Muita informação que deve ser codificada corretamente para que os aplicativos BIM possam interpretar.
Também é importante compreender que cada elemento a ser construído na obra possuirá uma identificação única e uma classificação semântica no modelo que também guarda todas as suas propriedades.
Os elementos ficam inseridos em duas estruturas hierárquicas distintas, uma semântica e outra espacial. Eles também possuem uma representação geométrica independente para ser exibida em aplicativos BIM. A informação de “como construir” fica armazenada através do relacionamento entre os serviços e as entidades a serem construídas. Os serviços guardam o prazo e o orçamento previstos. O modelo, da forma como propomos, estará otimizado para o acompanhamento de obra rodoviária, permitindo a criação de índices de desempenho e otimização de processos.
Existem diversas entidades propostas no IFC.
Algumas representam objetos físicos como rodovias (IfcRoad), cortes (IfcEarthworksCut) ou pavimentos (IfcPavement), outras representam objetos não visíveis como alinhamentos (IfcAlignment) ou conjunto de propriedades de objetos (IfcPropertySet) e tem outras que representam os relacionamentos entre os objetos criados. Estes relacionamentos podem ser de diferentes tipos, onde destacamos:
As entidades relacionadas ao orçamento e cronograma de execução da obra são importantes e devem estar compreendidas para serem aplicadas corretamente. São as entidades de tempo e custo (BIM 4D e 5D), que são:
Existem outros tipos de relacionamentos e entidades com outros significados, mas não iremos escrever aqui um curso de modelagem IFC e assumimos que o leitor esteja familiarizado com esses conceitos básicos.
Existem várias fontes e cursos, em português, de modelagem IFC na Internet, como o curso do Prof. Carlos Dias.
Com esses conceitos básicos assimilados podemos seguir com a modelagem digital da obra rodoviária.
Na nossa proposta o modelo começa com a criação de 3 entidades que se relacionam hierarquicamente:
IfcProject - Conterá Nome, Descrição e Ficha Técnica com todas as propriedades comuns da obra como a velocidade diretriz, tipo de obra (Implantação, Melhoria ou Recuperação), tabela de encargos (SICRO, DER-PR, DER-SP, GOINFRA, …), Datum utilizados e outros parâmetros de projeto. Será a base hierárquica para todas as entidades não edificáveis da obra;
IfcSite - Localização física da obra. Conterá a unidade da federação, rodovia, trecho, subtrecho, estaca inicial e final. Será a base hierárquica de todas as entidades edificáveis compreendidas em seu trecho como Terraplenagem ou Pavimentação. Um IfcProject pode conter vários IfcSite;
IfcRoad- Entidade que representa uma rodovia que será construída, melhorada ou restaurada. Um IfcSite pode conter diversas entidades IfcRoad.
A definição do sistema de coordenadas é uma livre escolha do projetista e normalmente fica entre LTM, UTM e Geográfica. Independente do sistema adotado é importante que o modelo contenha essa informação para que a geometria seja desenhada no local apropriado. Se o sistema de coordenadas for UTM, necessitará relacionar duas entidades com o IfcProject para atender aos aplicativos BIM:
IfcProjectedCRS - Define o Datum utilizado (EPSG: 4326, WGS 84, …)
IfcMapConversion - Transforma coordenadas de UTM para GEO
ISO-10303-21;
HEADER;
FILE_DESCRIPTION(('ViewDefinition [CoordinationView]'),'2;1');
FILE_NAME('','2025-07-14T11:34:08',(''),(''),'IfcOpenShell 0.8.0','IfcOpenShell 0.8.0','');
FILE_SCHEMA(('IFC4X3_ADD2'));
ENDSEC;
DATA;
#1=IFCPROJECT('2bQrYqm2z0cRNOakWx2bfW',$,'Proposta para uma MVD de Rodovias',$,$,$,$,(#5),$);
#2=IFCCARTESIANPOINT((0.,0.,0.));
#3=IFCAXIS2PLACEMENT3D(#2,$,$);
#4=IFCDIRECTION((0.,1.));
#5=IFCGEOMETRICREPRESENTATIONCONTEXT('Plan','Model',3,1.E-05,#3,#4);
#6=IFCGEOMETRICREPRESENTATIONSUBCONTEXT('Body','Model',*,*,*,*,#5,1.,.MODEL_VIEW.,$);
#7=IFCSITE('2cFWpD5Uv6_Q1NZT6xPlbq',$,'Aqui se descreve o local da Obra',$,$,$,$,$,$,$,$,$,$,$);
#8=IFCROAD('03acRANUf389E0CnNr4bK9',$,'BR-101',$,$,$,$,$,$,$);
#9=IFCPROJECTEDCRS('EPSG:31982','SIRGAS 2000 / UTM zone 22S','EPSG:31982',$,$,$,$);
#10=IFCMAPCONVERSION(#5,#9,500000.,7200000.,0.,1.,0.,1.);
#11=IFCRELAGGREGATES('1VK8eKdcL48fGQQl7JCLGy',$,$,$,#1,(#7));
#12=IFCRELAGGREGATES('3BASd6pyjDGB_YmXLJawHK',$,$,$,#7,(#8));
ENDSEC;
END-ISO-10303-21;
Para definir o sistema métrico como padrão no seu modelo trabalhe com a entidade IfcSIUnit
ISO-10303-21;
HEADER;
FILE_DESCRIPTION(('ViewDefinition [CoordinationView]'),'2;1');
FILE_NAME('','2025-07-29T06:07:08',(''),(''),'IfcOpenShell 0.8.0','IfcOpenShell 0.8.0','');
FILE_SCHEMA(('IFC4X3_ADD2'));
ENDSEC;
DATA;
#1=IFCPROJECT('1iFDQagkP7NRr23gHFSUwF',$,'Proposta para uma MVD de Rodovias',$,$,$,$,(#5),#20);
#2=IFCCARTESIANPOINT((0.,0.,0.));
#3=IFCAXIS2PLACEMENT3D(#2,$,$);
#4=IFCDIRECTION((0.,1.));
#5=IFCGEOMETRICREPRESENTATIONCONTEXT('Plan','Model',3,1.E-05,#3,#4);
#6=IFCGEOMETRICREPRESENTATIONSUBCONTEXT('Body','Model',*,*,*,*,#5,1.,.MODEL_VIEW.,$);
#7=IFCSITE('13zH3$$gbCaBNckgwpoDb6',$,'Aqui se descreve o local da Obra',$,$,$,$,$,$,$,$,$,$,$);
#8=IFCROAD('1w9z12AaL5ZgJTLjYRMM9t',$,'BR-101',$,$,$,$,$,$,$);
#9=IFCPROJECTEDCRS('EPSG:31982','SIRGAS 2000 / UTM zone 22S','EPSG:31982',$,$,$,$);
#10=IFCMAPCONVERSION(#5,#9,500000.,7200000.,0.,1.,0.,1.);
#11=IFCRELAGGREGATES('0RDuaq12jBWfuhaQJMphhU',$,$,$,#1,(#7));
#12=IFCRELAGGREGATES('3nrgT6myz9886BThUGYyZ1',$,$,$,#7,(#8));
#13=IFCALIGNMENT('3X$NjD7un1bft3$LdfFO4k',$,'Eixo Principal',$,$,$,$,$);
#14=IFCRELAGGREGATES('2_JSZQUiPB3O8VX__3E$L3',$,$,$,#1,(#13));
#15=IFCSIUNIT(*,.LENGTHUNIT.,$,.METRE.);
#16=IFCSIUNIT(*,.AREAUNIT.,$,.SQUARE_METRE.);
#17=IFCSIUNIT(*,.VOLUMEUNIT.,$,.CUBIC_METRE.);
#18=IFCSIUNIT(*,.MASSUNIT.,$,.GRAM.);
#19=IFCSIUNIT(*,.TIMEUNIT.,$,.SECOND.);
#20=IFCUNITASSIGNMENT((#15,#16,#17,#18,#19));
ENDSEC;
END-ISO-10303-21;
Num projeto de rodovia podem acontecer situações em que seja necessário discretizar o eixo em trechos, seja por semelhança de características técnicas ou por interesse do cliente em dividir o projeto em diversos lotes de obra. Seja qual for o motivo, a forma de modelar trechos distintos de obra de um projeto rodoviário em IFC é através da entidade IfcRoadPart utilizando o atributo PredefinedType → ROADSEGMENT, usageType → LONGITUDINAL e ligada hierarquicamente a IfcRoad.
Importante verificar se todos os trechos da rodovia estão contíguos dentro do modelo e aplicativos BIM podem fazer essa verificação de forma automática. Para a definição do início e fim de cada trecho devemos aplicar IfcLinearPlacement ao alinhamento principal do projeto. Detalharemos o conceito de alinhamento mais adiante.
O terreno e as suas camadas devem fazer parte do Modelo da Construção para compor a geometria 3D, pois sem ela, a obra seria um corredor no meio de um vazio. As camadas do subsolo são importantes para orientar a execução da terraplenagem.
Este é um elemento visual do IFC e necessitará de um descendente de IfcGeometricRepresentationItem para ser visualizado em um aplicativo BIM. A forma mais usual de representar uma superfície em IFC é com o IfcTriangulatedFaceSet que exibe uma malha espacial triangular.
O IfcAlignment foi provavelmente a principal entidade introduzida no IFC 4.x que permitiu a modelagem de rodovias. Ela representa o projeto geométrico de uma rodovia, ou seja, sua espinha dorsal. Qualquer alteração na sua forma gera reflexos diretos na terraplenagem, drenagem e pavimentação. No modelo IFC de uma rodovia, alinhamentos são referência para diversas outras entidades que serão construídas ao longo do eixo principal. Alinhamentos armazenam tanto o projeto horizontal (IfcAlignmentHorizontal) como o projeto vertical (IfcAlignmentVertical) e são utilizados no modelo somente como referência para posicionar outros objetos linearmente, uma vez que o eixo geométrico não é um objeto edificável da obra.
Por esse motivo os alinhamentos do projeto devem estar ligados hierarquicamente ao IfcProject e não ao IfcRoad.
O padrão IFC permite a modelagem do alinhamento da maneira tradicional, ou seja, projeto horizontal em 2D e projeto vertical em 2D, duas vistas planas do mesmo objeto tridimensional.
Tanto o alinhamento horizontal quanto o vertical são compostos por uma lista ordenada de retas e curvas. Sendo que as curvas são uma combinação de circulares e espirais no projeto horizontal e normalmente parabólicas no projeto vertical.
O projeto horizontal pode conter curvas complexas, mas que quase sempre podem ser decompostas em segmentos circulares ou espirais com parâmetros conhecidos. Os tipos de curva pré-definidos aceitos no padrão IFC que interessam ao setor rodoviário são LINE, CIRCULARARC, CLOTHOID e CUBIC.
Para os segmentos verticais o IFC suporta os seguintes tipos LINE, ARC, PARABOLICARC e CLOTHOID. Definidos em IfcAlignmentVerticalSegmentTypeEnum
Um projeto pode conter diversos alinhamentos (IfcAlignment).
Na prática, para cada segmento horizontal num alinhamento devemos:
Com a lista criada, devemos instanciar IfcAlignmentHorizontal e associar a lista usando IfcRelNests.
Devemos repetir o procedimento para o projeto vertical.
Para cada segmento vertical num alinhamento devemos:
Com a lista criada, devemos instanciar IfcAlignmentVertical e o associar a lista usando IfcRelNests.
Por último devemos criar uma instância de IfcAlignment que se relacionará com as instâncias criadas de IfcAlignmentHorizontale IfcAlignmentVertical também por um IfcRelNests.
Esse procedimento deve ser repetido para cada alinhamento existente no projeto.
Um conceito importante derivado direto do alinhamento é o “corredor de projeto” e deve ser incluído no modelo de construção em entidades IfcGeographicElement hierarquicamente ligados ao IfcSite. A geração ou amostragem dos dados normalmente é feita em seções tranversais ao alinhamento, por isso devemos utilizar como representação geométrica a entidade IfcSectionedSurface para cada uma das superfícies que se deseja modelar, com destaque para as superfícies do terreno, das camadas do subsolo, da terraplenagem e das camadas individuais de pavimentação (sub-base, base e revestimento).
Apesar de não ser absolutamente necessário, acreditamos ser uma boa prática materializar o eixo geométrico de cada alinhamento no modelo 3D com todas as estacas criadas no projeto, incluindo pontos notáveis e dispositivos de drenagem. Essas estacas devem ficar na elevação do terreno. Sugerimos utilizar entidades IfcReferent em conjunto com a dupla IfcLinearPositioningElement e IfcLinearPlacement para o posicionamento e como elemento visual, um hexaedro de 0,20 x 0,20 m de base com 1,0 metro de altura.
A terraplenagem será a primeira disciplina a ser incluída no modelo que terá quantidades, serviços, cronograma e orçamento.
Devemos começar criando uma instância de IfcEarthworksElement ligada hierarquicamente a localização da obra (IfcSite) com o intuito de agrupar toda a informação da terraplenagem neste objeto. Cada elemento (corte ou aterro) da terraplenagem deverá ser ligado hierarquicamente a este IfcEarthworksElement que, por sua vez, fará referência a um alinhamento (IfcAlignment) para o correto posicionamento dos elementos da terraplenagem, que podem ser:
Precisaremos modelar todo o projeto de terraplenagem, compreendendo:
Para identificar os materiais devemos usar uma instância de IfcMaterial para cada material existente na obra
IfcMaterial, Name="Solo - 1ª Categoria",
IfcMaterial, Name="Solo - 2ª Categoria"
IfcMaterial, Name="Solo - 3ª Categoria"
Todas as características geotécnicas conhecidas dos materiais estudados devem ser inseridas no modelo.
Cada corte deve ser identificado com uma instância de IfcEarthworksCut com a propriedade Name única e uma IfcPropertySet associada com as propriedades:
Cada aterro deve ser modelado de forma análoga, contudo utilizando a entidade IfcEarthworksFill.
Os cortes e aterros devem estar ligado hierarquicamente ao IfcEarthworksElement da obra com IfcRelAggregates e contidos espacialmente no IfcSite usando IfcRelContainedInSpatialStructure.
A Representação Geométrica dos volumes de corte e aterro no modelo 3D devem ser poliedros formados pela diferença das superfícies de projeto e da topografia.
Caixas de Empréstimo e Jazidas devem ser tratadas como sendo um Corte usando o IfcEarthworksCut com as mesmas propriedades e lembrando que o nome deve ser único para cada Corte, Caixa ou Jazida.
Bota-Fora é uma área geográfica (IfcGeographicElement) para descarte de material durante a obra para posterior tratamento de passivo ambiental. Para cada bota-fora deve ser instanciado um IfcGeographicElement com nome “Bota-Fora xx” ou algo semelhante que o descreva e nele associado a quantidade de material esperado. Cada Bota-Fora deve estar ligado hierarquicamente ao IfcEarthworksElement da obra com IfcRelAggregates e contido espacialmente no IfcSite global da obra com IfcRelContainedInSpatialStructure.
Os principais serviços de terraplenagem associados são:
O serviço de Limpeza do Terreno compreende normalmente a remoção da camada vegetal dividida entre árvores com diâmetro maior ou menor que 15cm ou 20cm e a carga e o transporte do entulho. A remoção é medida em m² (área), a carga é medida em m³ (volume) e o transporte é medido em m³ x km (volume transportado). Para modelar este serviço iremos criar uma instância de IfcTask para cada um dos serviços relacionados com Limpeza do Terreno e associar um IfcPropertySet com as propriedades:
Alguns serviços de Limpeza esperados são:
IfcTask, Name="Remoção de árvores com diâmetro menor que 15 cm"
IfcTask, Name="Remoção de árvores com diâmetro maior que 15 cm"
IfcTask, Name="Carga de Entulhos"
IfcTask, Name="Transporte de Entulhos"
O padrão IFC permite modelar os serviços de Escavação, Carga e Transporte individualmente, mas todos esses serviços, no Brasil, são executados sequencialmente pelo empreiteiro e cobrados em um único item do orçamento, portanto iremos modelar os três serviços como se fosse um único (IfcTask) e associar um IfcPropertySet com as propriedades:
Para modelar o serviço de compactação de aterros iremos criar uma instância de IfcTask para cada aterro a ser compactado e associar um IfcPropertySet com as propriedades:
Para cada IfcTask criado na terraplenagem:
Ao final, avalie a estabilidade do modelo verificando se a soma de toda a movimentação de terra confere com a quantidade de empréstimos, cortes, aterros e bota-foras.
O serviço de recomposição de aterros é normalmente medido em área (m²). Para modelar este serviço instanciaremos um IfcTask, com a propriedade Name = “Recomposição do Aterro XX” ou “Recomposição do Bota-Fora XX” e um IfcPropertySet igual ao de Compactação de Aterros.
Para modelar corretamente a drenagem de uma obra devemos usar as entidades criadas no IFC para cada um dos elementos existentes no projeto. Abaixo relacionamos os dispositivos de drenagem mais comuns encontrados em rodovias e as suas entidades correlatas no padrão IFC.
Existem elementos de drenagem pontuais como caixas coletoras ou entradas e saídas d'água que tem a sua posição referenciada ao eixo da rodovia.
Existem elementos lineares como meio-fios, canaletas e sarjetas que são longitudinais ao eixo e, portanto, tem a sua posição inicial e final referenciadas ao eixo.
Independente se o elemento for pontual ou linear, ele estará sempre referenciado ao eixo da rodovia e no seu posicionamento devemos utilizar a dupla IfcLinearPositioningElement e IfcLinearPlacement
Os bueiros são elementos lineares e quase sempre cruzam o eixo da rodovia. O seu posicionamento acontece na estaca onde o bueiro intercepta o eixo geométrico e a sua geometria é definida a partir do diâmetro, da esconsidade e comprimento a montante e a jusante como estipulado no projeto. Em cada extremidade, uma boca de saída padrão será construída conforme especificação de projeto.
Sugerimos iniciar a modelagem da drenagem criando um elemento IfcSystem com o nome “Sistema de Drenagem”. Analogamente ao que foi feito na Terraplenagem, esse objeto deverá ser ligado ao IfcSite usando IfcRelAggregates e será o ancestral de todos os dispositivos de drenagem que serão construídos na obra.
Cada dispositivo de drenagem do projeto (IfcKerb, IfcPipeSegment, …), com as suas quantidades e parâmetros de desenho deverá ser instanciado e ligado hierarquicamente ao IfcSystem criado.
Quando todos os elementos de drenagem estiverem semanticamente definidos na árvore de elementos da obra e as suas representações geométricas associadas, deve-se instanciar IfcTask para todos os serviços demandados na construção de cada elemento de drenagem e o associar ao conhecido IfcPropertySet
O projeto de pavimentação entrega informações importantes para a execução da obra, entre elas:
A modelagem da pavimentação rodoviária deve se iniciar com a criação de uma instância de IfcPavement ligada a IfcSite com IfcRelAggregates e definindo o atributo PredefinedType em FLEXIBLE ou RIGID.
Um modelo deve conter apenas uma única instância de IfcPavement por tipo de pavimento.
Podem existir projetos que utilizam pavimento rígido e flexível em trechos distintos, mas são raros.
Todos os segmentos homogêneos (IfcMaterialLayerSet) devem estar ligados a instância de IfcPavement correspondente com IfcRelAssociatesMaterial.
Cada material utilizado no pavimento (subbase, base e revestimento) deve estar definido com uma instância de IfcMaterial com todos os parâmetros de projeto (CBR, granulometria, …) associados em uma IfcPropertySet.
As Jazidas de pavimentação podem ser modeladas como IfcGeographicElement relacionado com IfcPavement usando IfcRelAggregates. A jazida deve se relacionar com a camada de pavimento (IfcMaterialLayer) onde será utilizada usando IfcRelAssociatesMaterial, caso o projetista queira determinar quais trechos que determinada jazida irá prover. de onde de devem ter o seu atributo Name caracterizando a jazida de forma clara e uma IfcPropertySet associada com as propriedades:
Cada segmento homogêneo deve ser modelado usando uma instância de IfcMaterialLayerSet que, por sua vez, armazena um conjunto de IfcMaterialLayer que representam as camadas individuais do pavimento, normalmente subbase, base e revestimento. Cada IfcMaterialLayer instanciada deve ter o seu atributo Name definido como, por exemplo, “Camada de Base”.
Também devem ser definidos os atributos Material e LayerThickness que representam, respectivamente, o material e a espessura da camada na unidade definida em IfcSIUnit.
Em cada segmento homogêneo (IfcMaterialLayerSet) deve ser associado um IfcPropertySet com propriedades que definam a sua localização (estaca inicial e final)
Em cada segmento homogêneo também devem ser modelados todos os serviços de pavimentação definidos no projeto. Para isso deve ser instanciado um IfcTask para cada serviço demandado e o associar ao IfcPropertySet
Para modelar a sinalização rodoviária devemos seguir o mesmo ritual utilizado nas disciplinas anteriores.
Para cada elemento da sinalização vertical deve ser instanciado uma entidade IfcSign para o painel da placa com o atributo Name contendo o código da placa (ex.: R-1, A-4, etc.)
Estruturas de suporte (poste ou pórtico) devem ser modeladas como IfcElementAssembly (PredefinedType → SIGNALASSEMBLY) agregando IfcMember (poste), IfcBeam/IfcColumn (pórtico), IfcFooting (fundação) e IfcSign para cada painel de placa.
Para cada elemento da Sinalização horizontal (pinturas e símbolos) devemos criar uma instância de IfcSurfaceFeature com PredefinedType específico:
Aplique Pset_RoadMarkingCommon (cor, espessura, material, método de aplicação). Relacione ao pavimento com IfcRelAdheresToElement.
Para posicionar os elementos da sinalização que são pontuais devemos usar a dupla IfcLinearPositioningElement e IfcLinearPlacement e para as faixas horizontais devemos definir estaca inicial (IfcReferent) e estaca final (IfcReferent) em cada elemento.
Todos os elementos da sinalização rodoviária seja vertical (IfcSign) ou horizontal (IfcSurfaceFeature) deverão estar ligados ao IfcSite usando IfcRelAggregates.
Cada propriedade a ser desapropriada na construção da rodovia deve ser modelada como um IfcSpatialZone com PredefinedType → OCCUPANCY e hierarquicamente ligado ao IfcSite principal do projeto usando IfcRelAggregates.
Anexe o Pset_LandRegistration ao IfcSpatialZone da parcela para guardar a Matrícula/Transcrição/RGI/Rural (LandTitleID), Matrícula cadastral (LandID) e se ela é definitiva (IsPermanentID).
Quantifique a área da parcela com Qto_SiteBaseQuantities.GrossArea (e perímetro com GrossPerimeter).
Para a representação geométrica, crie um polígono 2D para a área sobrepondo as parcelas e o transforme num sólido usando a entidade IfcExtrudedAreaSolid com o atributo Depth → 3.0 metros
Contenha a área no IfcSite do projeto com IfcRelContainedInSpatialStructure.
Atores, documentos, aprovações e custos
Proprietários e poder público → crie IfcActor (pessoa física e jurídica) e associe a parcela via IfcRelAssignsToActor com o papel OWNER (proprietário) e ACQUIRER (adquirente).
Documentos legais (Declaração de Utilidade Pública, laudos, termo de imissão, registros cartorários)
Instancie IfcDocumentReference/IfcDocumentInformation ligados à parcela e/ou zona por IfcRelAssociatesDocument.
Indenização/valoração
Crie um IfcCostItem com os valores (base de avaliação, data, correções) e ligue à parcela/zona via IfcRelAssignsToControl
É comum que, num projeto rodoviário, a sua diretriz cruze, em algum momento, uma adutora de água, uma tubulação de óleo/gás ou outro desafio que a desapropriação não pode resolver. Quando estas situações acontecem, os engenheiros utilizam ferramentas de geometria espacial para projetar uma solução que pode ser desde um simples ByPass até uma OAE. Seja qual for a interferência, o importante é modelar a área onde ela ocorre e a solução (conjunto de serviços) que foi adotada para lidar com ela. Softwares BIM de acompanhamento de obra sempre vão alertar, com antecedência, os locais aonde existem interferências, para que os serviços adequados possam ser ativados e evitar com que uma máquina pesada provoque um acidente numa tubulação.
Modelagem das interferências
Para cada área onde ocorrer uma interferência no projeto devemos instanciar uma entidade IfcSpatialZone com o PredefinedType → INTERFERENCE, que estará ligada hierarquicamente ao IfcSite usando IfcRelAggregates. Utilize a dupla IfcLinearPositioningElement e IfcLinearPlacement para o posicionamento e para a representação geométrica, crie um polígono 2D englobando toda a área afetada pela interferência e o transforme num sólido transparente de cor vermelha (para destacar no modelo) usando a entidade IfcExtrudedAreaSolid com o atributo Depth → 3.0 metros
Para cada serviço ligado a interferência, devemos instanciar um IfcTask e associar o IfcPropertySet:
Dessa forma os aplicativos BIM saberão localizar corretamente essas áreas e alertar antes que as máquinas possam atingir uma interferência.
A modelagem do projeto de Iluminação de uma rodovia começa com a criação de uma entidade IfcDistributionSystem (PredefinedType → ELECTRICAL) que estará ligada a IfcSite usando IfcRelAggregates e será o ancestral de todos os elementos de iluminação do projeto, que podem ser:
Sistema de iluminação: agrupe todos os elementos num IfcDistributionSystem com PredefinedType → LIGHTING. Isso representa o subsistema “Iluminação Pública/Viária” (útil para medições e manutenção).
Posicionamento dos elementos (estaqueamento e offset)
Para cada poste/armário/luminária, use IfcLinearPlacement referenciando a curva do eixo (idealmente um IfcAlignment). Defina DistanceAlong (km/estaca), OffsetLateral (ex.: 7,50 m) e OffsetVertical (coroamento/soleira).
O ponto é descrito por IfcPointByDistanceExpression.
Para cada área de paisagismo a ser modelada deve ser criada uma instância de IfcGeographicElement com PredefinedType → VEGETATION, que deverá estar ligada hierarquicamente ao IfcSite do projeto usando IfcRelAggregates.
Aqui encerramos a nossa sugestão de padronização do uso das entidades existentes no esquema IFC 4+ no âmbito do segmento rodoviário brasileiro, ou simplesmente, Guia de Modelagem de Obras Rodoviárias no Padrão IFC 4.3.2. A cada atualização do esquema IFC, este documento será revisto e publicada uma atualização, se necessário. Qualquer crítica construtiva ou sugestão de alternativa de modelagem será sempre benvinda através do e-mail do autor na primeira página. Esperamos que as sugestões propostas neste documento possam contribuir, de alguma forma, para o avanço do uso do BIM no setor rodoviário do nosso país.
O aplicativo RODOBIM, hospedado em rodobim.com.br permite a criação do arquivo IFC seguindo a MVD acima. Nós desenvolvemos plugins que permitem importar os dados de projeto dos softwares de projeto e de planilhas.