Diferenças entre edições de "Interoperabilidade BIM"
(→Fluxo IFC) |
|||
| Linha 21: | Linha 21: | ||
= Fluxo IFC = | = Fluxo IFC = | ||
| − | + | [[File:Processo IFC.jpg|frame|caption|Processo de troca de dados entre aplicações utilizando o modelo IFC<ref name="SIGABIM">SIGABIM, et al., Relatório SIGABIM - Estado da Arte: Building Information Modeling, Line of Balance e Código dos Contratos Públicos. Seccção de Construções Civis, Departamento de Engenharia Civil, Faculdade de Engenharia da Universidade do Porto, 2011.</ref> - traduzido de <ref name="Eastman08">Eastman, C., BIM handbook a guide to building information modeling for owners, managers, designers, engineers and contractors. 2008, New Jersey: John Wiley and Sons Ltd. XIV, 490.</ref>.|right]] | |
| + | |||
| + | Num 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: | 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: | ||
| Linha 30: | Linha 32: | ||
*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. | *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. | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
= Referências Bibliográficas = | = Referências Bibliográficas = | ||
<references/> | <references/> | ||
Revisão das 18h21min de 24 de março de 2011
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 [1]. 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 [2].
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 [3].
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 [4].
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 [1]. 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 [4].
Formatos
Fluxo IFC
Num 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.
Referências Bibliográficas
- ↑ 1,0 1,1 Lipman, R., M. Palmer, and S. Palacios, Assessment of conformance and interoperability testing methods used for construction industry product models. 2010, Automation in Construction.
- ↑ Gallaher, M.P.O.C., A. C.; Dettbarn, J. L., Jr.; Gilday, L. T. , Cost Analysis of Inadequate Interoperability in the U.S. Capital Facilities Industry. 2004, National Institute of Standards and Technology, U.S. Department of Commerce Technology Administration: Gaithersburg, Maryland, EUA.
- ↑ Jeong, Y.-S., et al., Part B - Data Interoperability Benchmark Test Between Architect and Precast Fabricator. Georgia Tech, 2007.
- ↑ 4,0 4,1 Monteiro, A., Avaliação da aplicabilidade do modelo IFC no licenciamento automático de projectos de redes de distribuição predial de água. Dissertação no âmbito do Mestrado Integrado em Engenharia Civil da Faculade de Engenharia da Universidade do Porto, 2010.
- ↑ SIGABIM, et al., Relatório SIGABIM - Estado da Arte: Building Information Modeling, Line of Balance e Código dos Contratos Públicos. Seccção de Construções Civis, Departamento de Engenharia Civil, Faculdade de Engenharia da Universidade do Porto, 2011.
- ↑ Eastman, C., BIM handbook a guide to building information modeling for owners, managers, designers, engineers and contractors. 2008, New Jersey: John Wiley and Sons Ltd. XIV, 490.
