Interoperabilidade BIM

Interoperabilidade define-se como a capacidade de dois ou mais sistemas trocarem dados entre si. O termo é frequentemente utilizado no contexto das tecnologias de informação, embora também possa ser aplicado a diferentes sistemas, nomeadamente levando em conta factores sociais, políticos e organizacionais.

Em termos de software, o termo interoperabilidade é utilizado para descrever a capacidade de diferentes programas trocarem informação entre si. A falta de interoperabilidade pode ficar a dever-se a à diferença nos formatos, diferença nos protocolos, diferenças nas rotinas e ainda diferença a nível de linguagem de programação.

Num fluxo BIM, a partilha de informação entre colaboradores está dependente da interoperabilidade dos seus sistemas. O acesso a uma metodologia colaborativa avançada, materializada na centralização e compatibilização de todas as especialidades num só modelo aumenta as exigências a nível dos requisitos de interoperabilidade.

Retrospectiva

A evolução tecnológica na indústria da construção tem-se vindo a acentuar de forma notória nas últimas quatro décadas. Um dos sintomas desta evolução na construção é a adopção de ferramentas CAD ("Computer Aided Design" - Desenho Assistido por Computador) para a representação dos seus produtos . Por ser uma actividade abrangente e transversal, a construção inclui, durante o seu ciclo de vida, diversas especialidades. Deste modo, o recurso ao CAD estende-se à Arquitectura, às Engenharias e à Construção (AEC). Um processo tão extenso e ramificado pressupõe que haja um meio adequado para trocar informação, sob a pena de se corromper a integridade dos dados. A capacidade de trocar dados entre sistemas representa um dos factores que mais contribui para a falta de produtividade e para o não cumprimento dos planos de trabalhos e dos orçamentos, com os custos de (não) interoperabilidade a poderem atingir valores superiores aos 15 biliões de dólares anuais de acordo com um estudo .

Perante estas grandes condicionantes, percebeu-se que seria necessário criar uma forma de garantir a correcta troca de dados entre sistemas, surgindo assim formatos "abertos" como o DXF, o SAT ou o IGES. Apesar de cumprirem o seu papel de transmissão de dados geométricos, verificou-se, ainda assim, que era algo frequente a perda ou a corrupção de dados o que levava à necessidade de ajustes manuais .

A existência de vários formatos públicos não é necessariamente positiva para a interoperabilidade entre sistemas. Assim, a partir da Organização Internacional para a Standardização (ISO) surge uma iniciativa para a criação de um formato standard de interoperabilidade para produtos industriais, o ISO-STEP (Standard for the Exchange of Product Model Data). Incluindo vários domínios distintos, como a indústria automóvel, a indústria da construção, a indústria naval e a indústria eléctrica entre outras, o desenvolvimento do formato foi perdendo fulgor à medida em que se percebia que a abrangência do âmbito era tal que os esforços de desenvolvimento não eram sustentáveis .

Apontados como a nova geração de ferramentas de modelação, os BIM surgem como uma solução para centralizar e integrar a informação do edifício num modelo virtual tridimensional. Representando uma significativa evolução em relação às ferramentas CAD, já não era suficiente transmitir apenas informação geométrica. Também era necessário incluir informação espacial , ligações paramétricas e atributos, pelo que os formatos referidos já não eram suficientes.

Para colmatar esta lacuna, surgiram algumas iniciativas na indústria da construção para criar um standard para a representação e organização de produtos da construção, das quais se destacam como as mais importantes o CIS/2 ("CIMSteel Integration Standards") e o IFC (Industry Foundation Classes), ambas criadas com base no trabalho já desenvolvido no formato STEP . O formato CIS/2 especializou-se mais em estruturas metálicas, deixando o IFC como o único formato verdadeiramente abrangente e representativo de todos os produtos da construção. Este título não oficial foi-se reforçando naturalmente com o tempo à medida que o modelo era desenvolvido e ganhava robustez. Actualmente já existem mesmo protocolos apoiados no modelo IFC, destacando-se o processo de licenciamento automático de projectos implementado em Singapura assente numa plataforma electrónica onde os projectos são submetidos em formato IFC .

Fluxo IFC

Os dados são extraídos da base de dados da fonte e atribuídos às respectivas instâncias IFC presentes no conversor e guardadas num formato neutro. O conversor da base de dados do receptor capta os dados em IFC e associa-os aos respectivos dados do modelo receptor.

Os problemas associados a este processo não estão tão associados à sua mecânica ou à qualidade dos conversores, mas antes às restrições impostas pelas diferentes dimensões das bases de dados dos modelos proprietários e do modelo IFC. Concretizando, num cenário onde a fonte e o receptor pertencessem ao mesmo modelo, no fim do processo, os dados representados no receptor iriam conter omissões em relação aos dados representados na fonte, pois a transição “fonte – conversor” representa logo à partida uma transição incompleta. Esta situação justifica-se pelos seguintes aspectos:

• A estrutura do modelo IFC reflecte uma grande preocupação com os resultados finais de representação, mas não com a forma de estruturação numa base de dados, pelo que estruturas incompatíveis e/ou desconhecidas podem resultar em omissões e/ou conflitos. Esta situação poderia ser contornada, mas não sem que os donos dos modelos/aplicações proprietárias corressem o risco de expor informação privada que não pretendem revelar.

• O modelo IFC não representa tipos de dados característicos e exclusivos dos modelos proprietários que suportam as respectivas aplicações.

• Ao contrário de objectos padrão simples como paredes, vigas ou portas standard, formas mais complexas como paredes cortina, escadas, ou portas com grandes pormenores, não são suportadas porque tanto o modelo IFC como os diversos modelos proprietários, representam-nas estruturalmente de diferentes formas. Para contornar este problema, seria necessário um esforço colectivo entre as várias entidades, produtores de software e Model Support Group, para que o modelo IFC pudesse suportar todas as possíveis representações. Tal cenário implicaria um tremendo esforço logístico por um lado, e por outro, considerando a quantidade de elementos a representar, multiplicados pelo número de diferentes representações do mesmo elemento para os vários modelos proprietários, iria com certeza significar uma sobrecarga do modelo IFC.