Novidades do IFC 4x3 para Infraestrutura

#0056: Recém-publicado em sua versão final, o schema de dados IFC 4x3 é uma atualização focada para projetos de infraestrutura e revisão de algumas entidades com impactos maiores ou menores dependendo de qual área você esteja na construção civil.

Propósitos (1/7)

Esta semana depois de algumas idas e vindas mais alguns anos de desenvolvimento finalmente a BuildingSMART disse o que todo o mercado de infraestrutura que trabalha com BIM esperava há muito tempo:

Após um processo de desenvolvimento robusto, a bSI publicou o IFC 4.3 como um padrão de produção da bSI. Isso significa que está pronto para os usuários usarem, para os fornecedores implementarem e foi enviado à ISO para votação.”

Lendo alguns reports da BuildingSMART sobre o tema da para perceber que o trabalho de criar um adendo ao schema que possa contemplar Infra não é simples, foram ao menos 10 partes interessadas para criar a estrutura de ferrovias e mais 23 partes interessadas para criar as estruturas de pontes, rodovias, portos e hidrovias (cadê os aeroportos?).

Obviamente o trabalho continua, pois o que foi criado é o mundo do schema como um todo, agora entrará o trabalho de determinar MVDs e destrinchar mais a questão de tuneis. Acompanhando os trabalhos e apresentações da BuildingSMART da para perceber que não é algo simples e que é algo feito com muita seriedade, veja por exemplo o fluxo de aprovação de um candidato a schema:

O grupo de trabalho basicamente teve que entender cenários de uso e como funciona um diagrama de processos de desenvolvimento de projetos de praticamente todo tipo de obra de infraestrutura, entender a taxonomia de cada obra, fazer uma primeira proposição, estressar as possibilidades, fazer relatórios de análise, fazer o rascunho das propriedades novas e pensar em como suportar e disseminar o nome schema.

Para mim o mais complicado é ver dentre tantas possibilidades de infraestrutura, entender o que é comum entre todos os domínios e o que é especifico de cada domínio:

Parabéns para o pessoal que trabalhou nisso, pois no final do dia estamos falando de um adendo ao schema existente do seguinte tipo:

• 62 novas entidades;

• 24 propostas para elementos comuns entre projetos de infraestrutura;

• 22 entidades para ferrovias;

• 7 entidades para rodovias;

• 9 entidades para portos e hidrovias;

• 294 novas predefinições sendo 68 para elementos comuns de infraestrutura, 121 voltadas para ferrovias, 38 para rodovias e 66 para portos e hidrovias;

• 40 itens foram modificados e 24 entidades foram descontinuadas com a chegada das novas entidades;

Logo é bastante novidade, vamos destrinchar um pouco o cenário.

Shared Infrastructure Domain (2/7)

O schema IfcSharedInfrastructureElements define os elementos compartilhados ou comuns (subtipos de IfcElement) aplicáveis ao setor de infraestrutura.

Neste schema foram adicionados elementos de sinalização, movimentação de terra, ocorrência de obras acima do solo e conceitos de geotecnia.

Para quem desenvolve projetos de infraestrutura é importante se atentar que foram adicionados os seguintes elementos: IfcBorehole, IfcCourse, IfcCourseType, IfcEarthworksCut, IfcEarthworksElement , IfcEarthworksFill, IfcGeomodel, fcGeoslice, IfcGeotechnicalAssembly, IfcGeotechnicalElement, fcGeotechnicalStratum, IfcPavement, IfcPavementType, IfcReinforcedSoil, IfcSign, fcSignType, IfcSignal e IfcSignalType.

Eu até traduzi grande parte dos elementos acima, mas preferi não publicar pois a definição semântica da BuildingSMART muitas vezes mais atrapalha do que ajuda, logo, antes de divulgar uma lista do que não tenho 100% de certeza do que é de fato cada entidade é melhor deixar somente a lista divulgada.

Algumas coisas estão fáceis como a diferença entre o IfcSign e o IfcSignal em que o Sign é uma placa comum e o Signal seria uma sinalização ativa dessas que vemos em estradas com mensagens em tempo real.

Por isso eu penso que quanto antes estudarem esses elementos e classificações, melhor vai ser o projeto e definição de quem precisa do IFC para infraestrutura.

IfcRail (3/7)

Analisando por cima à primeira vista a ferrovia no IFC parece ser algo até tranquilo de entender por ter basicamente 6 entidades a nível de elemento, até aí ok.

A complexidade aqui está no que envolve construir uma ferrovia, pois mesmo que tenhamos 6 entidades de elementos, temos outras 16 entidades que podem ter relação com essas primeiras 6 entidades de elementos.

Para definição da estrutura espacial temos o IfcRailway que vem a ser o que vai agrupar os elementos em um container espacial (um trecho da ferrovia, por exemplo). Disto temos novas formas de criação de geometria como o IfcDirectrixCurveSweptAreaSolid, IfcDirectrixDistanceSweptAreaSolid e o IfcInclinedReferenceSweptAreaSolid.

Vamos dizer que o pessoal de desenvolvimento de software vai ter que voltar para as aulas de geometria e aprender os conceitos de criação de objetos a partir de curvas e tangentes para conseguir gerar os modelos da forma correta.

Há ainda entidades para ocorrências de elementos de distribuição ao longo da via como painéis de distribuição, elementos de telecomunicação e controle de distribuição de energia.

IfcRoads (4/7)

Assim como nas ferrovias, as rodovias também ganharam o seu contêiner espacial chamado IfcRoad, mas aqui tem algo interessante que além do contêiner espacial também foi criado algo bem comum em softwares de modelagem de rodovias: perfis bidimensionais chamados de IfcOpenCrossProfileDef:

Um dos conceitos mais importantes aqui é entender o IfcRelAssociatesProfileDef que associa objetos a um perfil e assim pode ser usado para indicar qual superelevação ou superlargura e seu ângulo de inclinação, inclusive qual deve ser o tipo de transição entre dois eventos.

Vai ser interessante ver como os desenvolvedores vão aplicar esses conceitos para criação dos modelos IFC, uma vez que atualmente há uma saciedade em ter a geometria como ela é e ignorando outros fatores do projeto.

IfcPortsAndWaterwaysDomain (5/7)

Em termos de diversidade de tipos de projetos cobertos por um domínio de infraestrutura com certeza este domínio de portos e hidrovias é o que cobre mais possibilidades: portos de carga (contêiner, granéis sólidos, granéis líquidos, roll-on roll-off), terminais de passageiros (cruzeiro, balsa e tráfego pedonal), marinas e terminais de lazer, estaleiros de construção de navios e barcos, manutenção marinha e aquática, base de apoio/construção offshore, complexos/redes de canais, regulagem do canal e controle da água e complexos de bloqueio de navios.

Além disso o schema cobre os elementos quebra-mar, revestimentos, comportas, vertedouros e comportas de controle, elevadores de navios, elevadores hidráulicos, postos de descanso, docas secas, docas flutuantes, cais, eclusas de navios, ancoragens, canais/áreas de navegação, áreas de armazenamento/trabalho e pátios/áreas intermodais.

E ainda cobrem carga e veículos, guindastes, coca marítima/portões de bloqueio, auxílios à navegação (bóias, luzes, marcadores etc.), balizas, sistemas e dispositivos de amarração.

O seu contêiner espacial está lá bonitinho e reservado como sendo o IfcMarineFacility e é até pelo número de coisas que esta cobrindo é o domínio especifico que possui mais PredefinedTypes em suas entidades.

Próximos adendos (6/7)

É bem noticiado pela BuildingSMART que tudo que envolve túneis deve ser apresentado na próxima versão do schema, mas o que mais me chamou a atenção é que os aeroportos ficaram de fora.

Um dos poucos documentos que encontrei sobre um possivel IfcAirport domain diz que existe um Room aberto na BuildingSMART para aeroportos que foi lançado em 2016 e quem lideraria a iniciativa é quem cuida da manutenção do aeroporto de Schiphol na Holanda.

Cavando mais informações em novembro de 2020 o pessoal do Schiphol fez uma apresentação em que relatavam estar levantando quais seriam as entidades, tipos, propriedades e quantidades para definir classes para aeroportos.

Não sei qual a estratégia para este tipo de projeto, mas é curioso o fato de não mencionarem nada sobre o assunto nos releases assim como fizeram com túneis.

Tempo (7/7)

É muito bom que tenham desenvolvido e liberado esta atualização do IFC voltado para o publico de infraestrutura que agora pode parar de usar BuildingElementProxy para quase que a totalidade dos elementos que são projetados.

Para quem é da área é interessante ir se familiarizando com o tema e aprendendo as novas entidades, afinal, agora que é oficial não duvido nada que os governos em todas as suas instancias comecem a pedir isto sem nem mesmo saber como classificar as coisas.

É um tema longo e complexo, logo, peço desculpas em muitas vezes o texto tenha ficado pesado para ler, mas tentamos nosso melhor para explicar as coisas aqui.

Neste meio tempo siga o canal e compartilhe o conteúdo 😉

Obrigado,

Abs.

Tiago Ricotta

Publicado em 13 de Julho de 2022 às 20:04