Diferenças entre edições de "Interoperabilidade BIM"
| (Há 18 revisões intermédias de outro utilizador que não estão a ser apresentadas) | |||
| Linha 3: | Linha 3: | ||
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. | 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. | + | 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. |
| + | |||
| + | ---- | ||
| + | |||
| + | '''Nota''': os conteúdos aqui presentes fazem parte de relatórios e artigos desenvolvidos pela parte integrante da FEUP no projecto de investigação [[SIGABIM]], devendo por isso, quando citados, incluir a devida referência <ref name ="SIGABIM">Projecto SIGABIM. Hipólito de Sousa, João Poças Martins, André Monteiro. Secção de Construções Civis, Departamento de Engenharia Civil, Faculdade de Engenharia da Universidade do Porto (2011).</ref>. | ||
= Retrospectiva = | = Retrospectiva = | ||
| Linha 15: | Linha 19: | ||
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. | 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 <ref name="Lipman" />. 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 <ref name="Monteiro" />. | + | 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 <ref name="Lipman" />. 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 [[Industry Foundation Classes#Iniciativas|Singapura]] assente numa plataforma electrónica onde os projectos são submetidos em formato [[IFC]] <ref name="Monteiro" />. |
| + | |||
| + | = Tipos de formatos = | ||
| + | |||
| + | === Ligações proprietárias e directas entre ferramentas BIM específicas === | ||
| + | |||
| + | As ligações directas fornecem uma conexão integrada entre duas aplicações específicas, através de uma interface especificamente criada para os respectivos softwares. Interfaces deste tipo são binárias e apenas disponibilizam partes do modelo para criação, exportação, modificação ou eliminação, com a sua estrutura em binário a ser ocultada. As empresas de software preferem as ligações directas para trocas de dados. Porque as funcionalidades ficam directamente ao critério das empresas interessadas, por serem mais fáceis de suportar e por evitar o acesso de empresas concorrentes às suas aplicações. | ||
| + | |||
| + | A existência de um formato proprietário do tipo ligação directa restringe a possibilidade da participação da comunidade de utilizadores no seu desenvolvimento. Para além disso, tende a reflectir-se na adopção generalizada de um conjunto limitado de aplicações comerciais padrão em função da atribuição ou não de licenças de utilização do formato a outras empresas de software <ref name="JPPM">Poças Martins, J.P.d.S., Modelação do Fluxo de Informação no Processo de Construção, Aplicação ao Licenciamento Automático de Projectos. 2009, Faculdade de Engenharia da Universidade do Porto: Porto.</ref>. | ||
| + | |||
| + | === Formatos proprietários para troca de dados === | ||
| + | |||
| + | Os “proprietary file exchange formats” são desenvolvidos por uma empresa de software de modo a funcionarem como uma interface com aplicações de diferente âmbito. Os proprietary exchange format são implementados em formatos de texto, logo, podem ser lidos sem recurso a computadores e como tal, utilizados por outras empresas que não a responsável pelo desenvolvimento do formato. Por detrás de cada formato proprietário estão objectivos específicos, logo, cada formato apresenta um conjunto de funcionalidades específicas. Os formatos proprietários são desenvolvidos num formato de visualização aberto para que uma aplicação com uma dada função, possa ser funcionalmente viável na medida em que é permitida a troca de informação com outras aplicações diferentes por via deste formato <ref name="Eastman08" />. | ||
| + | |||
| + | Um dos formatos proprietários mais conhecidos na área da construção é o DXF (Data eXchange Format) desenvolvido pela Autodesk. | ||
| + | |||
| + | Formatos deste tipo começam a aparecer mais frequentemente. A possibilidade de ultrapassar o âmbito das funcionalidades disponibilizadas por cada software em particular poderá ser decisivo, especialmente tratando-se de grandes projectos que envolvem equipas numerosas, pelo facto de permitir a cada uma trabalhar com o seu software sem esbarrar em problemas de interoperabilidade. | ||
| − | = Formatos = | + | === Formatos públicos para troca de dados === |
| − | = | + | Os formatos públicos são normalmente desenvolvidos por entidades não lucrativas. Não são formatos para serem comercializados. Antes, pretende-se que representem a base para o desenvolvimento das aplicações comerciais. |
| + | |||
| + | Formatos públicos implicam a utilização de standards para troca de dados entre diferentes modelos. O modelo [[IFC]] (Industry Foundation Classes) e o CIS/2 para estruturas metálicas, representam, actualmente, as opções mais bem sucedidas a este nível, sendo os únicos standards públicos reconhecidos internacionalmente, ainda que não de forma oficial. Espera-se que o modelo [[IFC]] o venha a ser, dada a sua elevada capacidade para representar a maioria dos produtos da construção (ainda que de forma genérica) <ref name ="SIGABIM" />. | ||
| + | |||
| + | Este tipo de soluções baseia-se em formatos que definem não só objectos e propriedades, mas também as relações entre elementos. | ||
| + | |||
| + | === Formatos para troca de dados baseados em XML === | ||
| + | |||
| + | XML (eXtensible Markup Language) representa uma extensão do formato HTML (HyperText Markup Language), a linguagem base da internet. O XML permite a definição de estruturas de base de dados (chamados “schemas” - esquemas) e significados dos vários elementos. Os diferentes esquemas estruturais XML suportam trocas de vários tipos de dados entre aplicações. XML é especialmente adequado para trocas de informação de gestão. | ||
| + | |||
| + | A aplicação de esquemas XML na área da construção conta já com alguns resultados concretos, sendo os mais relevantes <ref>Behrman, W., Best Practices for the Development and Use of XML Data Interchange Standards. CIFE Technical report TR131. 2002: Stanford University.</ref>: | ||
| + | |||
| + | *'''OGC''' (Open Geospatial Consortium): descrição, gestão, renderização e manipulação geométrica e geográfica de objectos. | ||
| + | *'''gbXML''' (Green Building XML): transferência de informação necessária a análises energéticas preliminares de edifícios, zonas e equipamentos. | ||
| + | *'''aecXML''': definição não só de partes físicas de edifícios mas também de variáveis abstractas habituais típicas dos processos de gestão na construção, tais como, RFP (Request for Proposal), RFI (Request for Information), etc. Serve também para representação de calendarizações, manifestos, contratos, etc. | ||
| + | *'''IFCXML''': esquema de mapeamento do modelo [[IFC]] para formato XML. Actualmente incompleto em relação ao formato IFC EXPRESS (linguagem de programação do modelo [[IFC]]). | ||
| + | *'''BLIS-XML''': adição ao modelo [[IFC]] baseado nos esquemas BLIS com o intuito de tornar o modelo mais prático e produtivo. | ||
| + | *'''agcXML''' (Associated General Contractors XML): esquema XML para os processos de gestão e negócios na construção. | ||
| − | + | Apesar de se basearem no mesmo formato, os vários esquemas XML utilizam e definem as suas próprias entidades, atributos e relações, pelo que não são compatíveis entre si. | |
| − | + | A grande utilidade em utilizar este tipo de esquemas está na possibilidade (facilidade) em aplicar nas actividades de uma empresa e desenvolver novas funcionalidades à volta do esquema original. | |
| − | + | = Fluxo IFC = | |
| − | + | [[File:Processo IFC.jpg|thumb|right|350px|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>.]] | |
| − | + | 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]]. Por exemplo, 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 <ref name="SIGABIM" />: | ||
| + | *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]]. | ||
| + | = Ligações internas = | ||
| + | Ver também: | ||
| + | * [[BIM|Building Information Modeling]] | ||
| + | * [[Industry Foundation Classes|Modelo IFC]] | ||
| + | * [[Metodologias Lean]] | ||
| + | * [[Linha de Balanço]] | ||
| + | * [[Código dos Contratos Públicos]] | ||
= Referências Bibliográficas = | = Referências Bibliográficas = | ||
<references/> | <references/> | ||
| + | |||
| + | [[Categoria:BIM]] | ||
| + | [[Categoria:Gestão da Informação]] | ||
Edição atual desde as 23h52min de 3 de novembro 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.
Nota: os conteúdos aqui presentes fazem parte de relatórios e artigos desenvolvidos pela parte integrante da FEUP no projecto de investigação SIGABIM, devendo por isso, quando citados, incluir a devida referência [1].
Índice
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 [2]. 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 [3].
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 [4].
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 [5].
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 [2]. 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 [5].
Tipos de formatos
Ligações proprietárias e directas entre ferramentas BIM específicas
As ligações directas fornecem uma conexão integrada entre duas aplicações específicas, através de uma interface especificamente criada para os respectivos softwares. Interfaces deste tipo são binárias e apenas disponibilizam partes do modelo para criação, exportação, modificação ou eliminação, com a sua estrutura em binário a ser ocultada. As empresas de software preferem as ligações directas para trocas de dados. Porque as funcionalidades ficam directamente ao critério das empresas interessadas, por serem mais fáceis de suportar e por evitar o acesso de empresas concorrentes às suas aplicações.
A existência de um formato proprietário do tipo ligação directa restringe a possibilidade da participação da comunidade de utilizadores no seu desenvolvimento. Para além disso, tende a reflectir-se na adopção generalizada de um conjunto limitado de aplicações comerciais padrão em função da atribuição ou não de licenças de utilização do formato a outras empresas de software [6].
Formatos proprietários para troca de dados
Os “proprietary file exchange formats” são desenvolvidos por uma empresa de software de modo a funcionarem como uma interface com aplicações de diferente âmbito. Os proprietary exchange format são implementados em formatos de texto, logo, podem ser lidos sem recurso a computadores e como tal, utilizados por outras empresas que não a responsável pelo desenvolvimento do formato. Por detrás de cada formato proprietário estão objectivos específicos, logo, cada formato apresenta um conjunto de funcionalidades específicas. Os formatos proprietários são desenvolvidos num formato de visualização aberto para que uma aplicação com uma dada função, possa ser funcionalmente viável na medida em que é permitida a troca de informação com outras aplicações diferentes por via deste formato [7].
Um dos formatos proprietários mais conhecidos na área da construção é o DXF (Data eXchange Format) desenvolvido pela Autodesk.
Formatos deste tipo começam a aparecer mais frequentemente. A possibilidade de ultrapassar o âmbito das funcionalidades disponibilizadas por cada software em particular poderá ser decisivo, especialmente tratando-se de grandes projectos que envolvem equipas numerosas, pelo facto de permitir a cada uma trabalhar com o seu software sem esbarrar em problemas de interoperabilidade.
Formatos públicos para troca de dados
Os formatos públicos são normalmente desenvolvidos por entidades não lucrativas. Não são formatos para serem comercializados. Antes, pretende-se que representem a base para o desenvolvimento das aplicações comerciais.
Formatos públicos implicam a utilização de standards para troca de dados entre diferentes modelos. O modelo IFC (Industry Foundation Classes) e o CIS/2 para estruturas metálicas, representam, actualmente, as opções mais bem sucedidas a este nível, sendo os únicos standards públicos reconhecidos internacionalmente, ainda que não de forma oficial. Espera-se que o modelo IFC o venha a ser, dada a sua elevada capacidade para representar a maioria dos produtos da construção (ainda que de forma genérica) [1].
Este tipo de soluções baseia-se em formatos que definem não só objectos e propriedades, mas também as relações entre elementos.
Formatos para troca de dados baseados em XML
XML (eXtensible Markup Language) representa uma extensão do formato HTML (HyperText Markup Language), a linguagem base da internet. O XML permite a definição de estruturas de base de dados (chamados “schemas” - esquemas) e significados dos vários elementos. Os diferentes esquemas estruturais XML suportam trocas de vários tipos de dados entre aplicações. XML é especialmente adequado para trocas de informação de gestão.
A aplicação de esquemas XML na área da construção conta já com alguns resultados concretos, sendo os mais relevantes [8]:
- OGC (Open Geospatial Consortium): descrição, gestão, renderização e manipulação geométrica e geográfica de objectos.
- gbXML (Green Building XML): transferência de informação necessária a análises energéticas preliminares de edifícios, zonas e equipamentos.
- aecXML: definição não só de partes físicas de edifícios mas também de variáveis abstractas habituais típicas dos processos de gestão na construção, tais como, RFP (Request for Proposal), RFI (Request for Information), etc. Serve também para representação de calendarizações, manifestos, contratos, etc.
- IFCXML: esquema de mapeamento do modelo IFC para formato XML. Actualmente incompleto em relação ao formato IFC EXPRESS (linguagem de programação do modelo IFC).
- BLIS-XML: adição ao modelo IFC baseado nos esquemas BLIS com o intuito de tornar o modelo mais prático e produtivo.
- agcXML (Associated General Contractors XML): esquema XML para os processos de gestão e negócios na construção.
Apesar de se basearem no mesmo formato, os vários esquemas XML utilizam e definem as suas próprias entidades, atributos e relações, pelo que não são compatíveis entre si.
A grande utilidade em utilizar este tipo de esquemas está na possibilidade (facilidade) em aplicar nas actividades de uma empresa e desenvolver novas funcionalidades à volta do esquema original.
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. Por exemplo, 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 [1]:
- 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.
Ligações internas
Ver também:
- Building Information Modeling
- Modelo IFC
- Metodologias Lean
- Linha de Balanço
- Código dos Contratos Públicos
Referências Bibliográficas
- ↑ 1,0 1,1 1,2 1,3 Projecto SIGABIM. Hipólito de Sousa, João Poças Martins, André Monteiro. Secção de Construções Civis, Departamento de Engenharia Civil, Faculdade de Engenharia da Universidade do Porto (2011). Erro de citação: Código
<ref>inválido; o nome "SIGABIM" é definido mais de uma vez com conteúdos diferentes - ↑ 2,0 2,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.
- ↑ 5,0 5,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.
- ↑ Poças Martins, J.P.d.S., Modelação do Fluxo de Informação no Processo de Construção, Aplicação ao Licenciamento Automático de Projectos. 2009, Faculdade de Engenharia da Universidade do Porto: Porto.
- ↑ 7,0 7,1 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.
- ↑ Behrman, W., Best Practices for the Development and Use of XML Data Interchange Standards. CIFE Technical report TR131. 2002: Stanford University.
