O número de aplicativos para a indústria de AEC explodiu e provavelmente continue aumentando. Precisamos que todos esses aplicativos possam trabalhar juntos para que possam fazer o que precisam fazer – ajudar os profissionais de AEC a projetar, construir e operar edifícios e infraestrutura da maneira mais rápida, eficiente e econômica possível. E, para trabalharem juntos, eles precisam ser capazes de trocar os dados de construção que estão criando e usando uns com os outros livremente, usando um padrão comum, que é o que é o IFC.
Até 2005 a atual BuildingSMART se chamava International Alliance for Interoperability (IAI) e já existia há 10 anos, sendo então “renomeada” para se tornar mais amigável e fácil de lembrar. Desde então, a buildingSMART cresceu e se tornou uma organização global com vários capítulos regionais e, além de continuar a desenvolver o IFC, desenvolveu vários padrões adicionais, incluindo BCF, MVD, IDM e bsDD. O que são esses vários padrões.
IFC (Industry Foundation Classes)
O IFC é, obviamente, o primeiro padrão buildingSMART e aquele que impulsionou toda a iniciativa de padrões para interoperabilidade de tecnologia AEC. É interessante notar que a IFC até mesmo antecedeu o termo “modelagem de informações de construção”.
Para começar, o aspecto mais fundamental do IFC é que ele é um padrão específico da AEC. Para ser mais preciso, tem sido, até agora, um padrão específico de construção (embora isso esteja prestes a mudar, como veremos). O que isso significa é que ele carrega informações sobre os elementos de construção, que são especificamente de três tipos conforme mostrado no gráfico à esquerda na Figura 1: sua geometria (por exemplo, a altura e a espessura de uma parede); suas propriedades (por exemplo, o valor U e a composição do material das camadas da parede); e suas relações entre si (por exemplo, em qual piso a parede está e quais espaços estão em cada lado dela).
Também digno de nota é o fato de que o IFC é estruturado de forma que versões subsequentes possam ser construídas adicionando mais elementos, suas propriedades e seus relacionamentos. Eles não afetam o que já está definido, conforme mostrado no gráfico à direita na Figura 1. Isso torna o IFC compatível com versões anteriores, de modo que os aplicativos que suportam versões mais recentes do IFC também suportam versões mais antigas.
A organização buildingSMART está atualmente trabalhando na expansão do IFC para incluir elementos de infraestrutura, e outras versões podem se expandir para incluir elementos FM e qualquer outra coisa que não possamos prever agora.
Embora o uso do IFC seja bem compreendido devido à sua longa história na indústria de tecnologia de AEC, aqui está uma rápida recapitulação:
- O principal uso do IFC para trocar dados entre diferentes aplicativos que não são integrados diretamente por meio de APIs. Por exemplo, Solibri agora tem integração bidirecional com ARCHICAD (consulte http://www.aecbytes.com/newsletter/2019/issue_100.html ), portanto, não precisa usar o IFC para importar arquivos ARCHICAD.
- As equipes de projeto em uma única disciplina normalmente trabalharão com o mesmo aplicativo BIM disciplinar e não precisam usar o IFC. Eles podem usar o recurso de colaboração / compartilhamento de trabalho em seu aplicativo BIM para trabalhar juntos em um projeto e podem trocar os arquivos nativos do aplicativo entre si.
- Diferentes disciplinas de design que estão trabalhando em diferentes plataformas precisarão da IFC para trocar dados. Eles usarão o IFC para importar outros modelos disciplinares e podem exportar seus próprios projetos no formato IFC para serem usados por outras disciplinas. Nesses casos, eles estão usando o IFC principalmente como uma referência. Quaisquer alterações necessárias a qualquer um dos modelos de design disciplinar terão que ser feitas no aplicativo de autoria original e, em seguida, reimportadas como uma referência. O que é importante observar aqui é que o IFC não é um formato de autoria de modelo, semelhante a como o PDF não é um formato de autoria de documento. Você pode criar um modelo em um aplicativo BIM e salvá-lo no formato IFC, semelhante a como você pode criar um documento em qualquer aplicativo (processador de texto, planilhas, design gráfico, etc.) e salvá-lo no formato PDF.
- Ferramentas de análise, como energia, estrutura, iluminação, etc., são normalmente integradas diretamente com aplicativos BIM usando APIs e, embora possam oferecer suporte a IFC, elas dependem principalmente de sua integração de API com a ferramenta de modelagem para realizar sua análise.
- É uma situação semelhante com as ferramentas de visualização – a maioria delas depende da integração direta com as ferramentas de modelagem, em vez do IFC. Para a visualização em particular, isso faz muito sentido, já que eles só precisam das propriedades da geometria e do material de superfície dos elementos do modelo e não de suas propriedades detalhadas e informações de relacionamento que o IFC contém. (Este uso de informações parciais do IFC está relacionado a outro padrão chamado MVD, que é discutido mais adiante neste artigo.)
- A maioria dos processos posteriores, como coordenação de modelo, programação de construção, retirada de quantidade, custeio, gerenciamento de projeto, etc., dependem do IFC para importar todos os diferentes modelos disciplinares criados em diferentes aplicações. Exemplos disso incluem Solibri (consulte a Figura 2), Navisworks, Bexel Manager , Visicon , Aconex e muitos mais.
- Assim como há muitos visualizadores gratuitos para visualizar arquivos PDF, o número de visualizadores gratuitos para arquivos IFC está aumentando. Um exemplo é mostrado na Figura 3. Além de ser um visualizador gratuito, o que é especialmente interessante neste software denominado usBIM.viewer + é que ele também permite que o arquivo IFC seja editado. Não é uma ferramenta de autoria BIM completa, de forma alguma, mas permite que a geometria dos elementos seja modificada, novas propriedades sejam adicionadas, novos elementos sejam adicionados de um catálogo e elementos existentes sejam excluídos.
- Neste ponto, a maioria dos aplicativos AEC que funcionam com o modelo de construção de alguma forma suportam o formato IFC, seja por ser capaz de importá-lo, exportá-lo ou importá-lo e exportá-lo. O quão bem eles são capazes de fazer isso é onde entra a “certificação”. Todos os aplicativos mencionados até agora, incluindo e muitos mais, foram certificados pelo buildingSMART, indicando que a qualidade de sua importação / exportação IFC atende aos benchmarks do buildingSMART.
A versão oficial atual do IFC é IFC4; no entanto, a certificação e a implementação costumam demorar alguns anos, o que significa que a maioria dos usuários ainda está usando a última versão oficial, IFC2x3, para a qual a maioria dos aplicativos foi certificada. A certificação de aplicativos para IFC4 está começando a aumentar, e sua ampla implementação ocorrerá em breve.
Ao mesmo tempo, a equipe IFC da buildingSMART está trabalhando na próxima versão, IFC5, que irá estendê-la para incluir elementos de infraestrutura, permitindo que aplicativos como Autodesk Civil 3D, Allplan Engineering Civil, Bentley OpenRoads / OpenSite, etc., possam usá-la para interoperabilidade . Também há planos para o IFC6 estendê-lo para operações e FM.
BCF (formato de colaboração BIM)
O formato BCF foi desenvolvido especificamente para coordenar vários modelos de design disciplinar que foram exportados no formato IFC para um aplicativo de coordenação e detecção de conflito. Normalmente, haveria um grande número de problemas detectados ao reunir os diferentes modelos disciplinares, mesmo para um edifício médio, como elementos estruturais em conflito com elementos arquitetônicos, tolerâncias inadequadas para os elementos MEP e assim por diante.
Antes do BCF, os conflitos detectados tinham que ser enviados de volta para os aplicativos de autoria BIM individuais na forma de relatórios que descrevem cada problema e incluindo capturas de tela para maior clareza, e estes teriam que ser cuidadosamente estudados pela equipe de design para descobrir onde e quais eram os problemas com seu modelo de design para que pudessem ser corrigidos.
Dada a importância da coordenação do modelo e detecção de conflito para detectar e resolver quaisquer conflitos de design antes da construção, há um número crescente de aplicativos que executam essa tarefa, muitas vezes em adição a outras tarefas. Assim, por exemplo, Solibri faz verificação de modelo e decolagem de quantidade, além de detecção de conflito (Figura 2), BIMcollab faz validação de modelo, além de gerenciamento de problemas, Visicon tem visualização de dados e recursos de interrogação de modelo, além de coordenação de design, e Bexel Manager tem Recursos 4D, 5D e 6D BIM, além de coordenação e detecção de conflito.
Independentemente do que mais façam, todos esses aplicativos funcionam com o BCF da mesma maneira – os problemas detectados no modelo combinado são compilados e exportados no formato BCF, que pode então ser importado para os aplicativos de autoria BIM para fazer as alterações necessárias aos modelos individuais. Para resolver um problema específico, ele simplesmente precisa ser selecionado na lista BCF que é importada.
Como o formato BCF também captura quais elementos estão envolvidos em um problema, selecioná-lo o levará automaticamente ao local no modelo onde o problema foi detectado. Um exemplo disso é mostrado na Figura 4, onde selecionar um problema trazido para o Navisworks por meio do BCF Manager do BIMcollab leva você diretamente para a visualização do modelo onde o problema foi detectado.
Essencialmente, além do problema, sua localização e os elementos envolvidos, o formato BCF também pode incluir a data em que o problema foi detectado, seu status, a pessoa a quem foi atribuído, comentários, nível de prioridade, a data em que foi resolvido , e qualquer outra informação relevante. Isso permite que todos os problemas sejam gerenciados e rastreados. À medida que os problemas são resolvidos, seu status é atualizado no arquivo BCF. O arquivo BCF atualizado pode então ser devolvido ao aplicativo de coordenação junto com o modelo atualizado no formato IFC para a próxima rodada de coordenação e detecção de conflito.
MVD, IDM e bsDD
Esses são três padrões buildingSMART adicionais que são direcionados principalmente para os desenvolvedores de aplicativos AEC, e não para os usuários finais. Destes, o MVD (Model View Definition) é o mais fácil de entender.
Conforme mostrado no gráfico à esquerda da Figura 5, ele se refere aos diferentes subconjuntos do modelo IFC completo que seriam necessários para tarefas específicas, como análise de energia, análise estrutural, cálculos de iluminação natural e assim por diante. Assim, por exemplo, um aplicativo de análise de energia não precisa saber todos os detalhes de todos os elementos no IFC, apenas aqueles elementos e propriedades que são relevantes para a análise de energia.
Assim, em vez de exportar o modelo IFC completo, você exportaria apenas o MVD para análise de energia. Além de tornar o aplicativo de análise mais rápido – já que não é necessário analisar o arquivo inteiro para descobrir o que é necessário – o arquivo em si pode ter um tamanho consideravelmente menor, o que é sempre útil.
A buildingSMART desenvolveu MVDs para diferentes tarefas, e eles podem ser vistos nas diferentes opções que estão disponíveis quando um modelo está sendo exportado para IFC em um aplicativo BIM (consulte a Figura 5, imagem à direita). Você escolheria o MVD mais relevante para o uso planejado do IFC.
À medida que o IFC continua a desenvolver e adicionar mais elementos, o número de MVDs também continuará a aumentar, permitindo que o IFC seja usado para um número cada vez maior de tarefas especializadas. Por exemplo, o novo formato IFC4 inclui uma nova “Visualização de transferência de projeto” para maior fidelidade – ele preserva os dados da construção para que você possa exportá-los tecnicamente para outro aplicativo e continuar trabalhando com eles.
Assim que tivermos o IFC5, provavelmente teremos um MVD para elementos de infraestrutura específicos, como estradas, trilhos, etc. E olhando ainda mais à frente, poderíamos ter uma exportação IFC especificamente para FM.
Os dois padrões restantes são ainda mais técnicos. O IDM (Information Delivery Manual) foi criado com o objetivo de definir os MVDs para diferentes casos de uso. Ele mapeia um processo e determina quais informações são necessárias para realizar esse processo, que é então usado para criar os MVDs IFC. Além de ser usado pela equipe de desenvolvimento buildingSMART, os IDMs também são frequentemente usados por grandes organizações para definir subconjuntos IFC personalizados para processos internos.
E, finalmente, o bSDD (buildingSMART Data Dictionary) é semelhante a um tradutor para elementos BIM, mapeando a terminologia de diferentes elementos em diferentes linguagens e sistemas de classificação para garantir que um elemento como uma parede ou janela tenha a mesma definição de objeto, informações de propriedade e informações de relacionamento em todos os aplicativos BIM, independentemente do país, localização ou sistema de classificação em uso.
Conclusão
A interoperabilidade é um problema crítico para aplicativos de computador em qualquer domínio, garantindo que todos os sistemas usados para diferentes tarefas e por diferentes usuários dentro desse domínio possam se comunicar entre si.
Não queremos depender de um único fornecedor para desenvolver todos os sistemas, presumindo que isso seja possível. Assim como várias marcas em qualquer área são um sinal de uma indústria vibrante e próspera, o grande número de aplicativos de AEC aponta para uma indústria que está sendo bem servida por tecnologia.
Temos a sorte de ter uma organização independente e neutra como a buildingSMART, que vem desenvolvendo padrões abertos para aplicativos de tecnologia AEC há quase trinta anos. O IFC, em particular, tornou-se sinônimo de abertura e interoperabilidade e, ao fornecer a base para o OpenBIM, garante que soluções de tecnologia inovadoras e úteis para a indústria de AEC possam ser desenvolvidas em larga escala.
