Diferenças entre edições de "Industry Foundation Classes"

Da wiki WIQI GEQUALTEC
Ir para: navegação, pesquisa
 
(Há 36 revisões intermédias de 3 utilizadores que não estão a ser apresentadas)
Linha 1: Linha 1:
−
'''Industry Foundation Classes (IFC)''' designa um formato universal para representação dos produtos da construção e troca de dados entre sistemas. Não sendo ainda um formato de interoperabilidade standard (a última versão, IFC 2x4, está em processo de aguardar certificação total da International Organization for Standardization), é já habitual a utilização das especificações IFC nas aplicações BIM mais correntes.
+
'''Industry Foundation Classes (IFC)''' designa um formato universal para representação dos produtos da construção e troca de dados entre sistemas. Não sendo ainda um formato de [[interoperabilidade]] standard (a última versão, IFC 2x4, está em processo de aguardar certificação total da International Organization for Standardization), é já habitual a utilização das especificações IFC nas aplicações [[BIM]] mais correntes.
 +
 
 +
----
 +
 
 +
'''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 =
 +
 +
[[Ficheiro:Modelo IFC.jpg|thumb|right|400px|Estrutura da base de dados do modelo IFC, versão 2x4 <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="IAI" />.]]
  
 
O modelo IFC tem uma origem próxima da iniciativa ISO-STEP. A origem do STEP (Standard for the Exchange of Product model data) remonta para a década de 80. Numa iniciativa ISO (International Organization for Standardization) foram criados vários comités para o desenvolvimento de um standard universal para a representação do ciclo de vida de vários produtos industriais.
 
O modelo IFC tem uma origem próxima da iniciativa ISO-STEP. A origem do STEP (Standard for the Exchange of Product model data) remonta para a década de 80. Numa iniciativa ISO (International Organization for Standardization) foram criados vários comités para o desenvolvimento de um standard universal para a representação do ciclo de vida de vários produtos industriais.
Linha 7: Linha 13:
 
Este standard deveria obedecer a uma série de especificações próprias de um modelo de dados para representação de produtos. Para o efeito, foi desenvolvida uma linguagem de programação que permitisse a estruturação desmaterializada do modelo, de modo a permitir a incorporação sucessiva de novos elementos e especificações. Deste modo, pretendia-se obter um potente mecanismo para modelação e integração de informação, consistente com os princípios de troca de dados entre sistemas. Era assim criada a linguagem de programação EXPRESS e EXPRESS-G (componente gráfica) <ref name="Eastman">Eastman, C.M., Building Product Models: Computer Environments Supporting Design and Construction. 1999.</ref>.
 
Este standard deveria obedecer a uma série de especificações próprias de um modelo de dados para representação de produtos. Para o efeito, foi desenvolvida uma linguagem de programação que permitisse a estruturação desmaterializada do modelo, de modo a permitir a incorporação sucessiva de novos elementos e especificações. Deste modo, pretendia-se obter um potente mecanismo para modelação e integração de informação, consistente com os princípios de troca de dados entre sistemas. Era assim criada a linguagem de programação EXPRESS e EXPRESS-G (componente gráfica) <ref name="Eastman">Eastman, C.M., Building Product Models: Computer Environments Supporting Design and Construction. 1999.</ref>.
  
−
As especificações STEP apresentam um âmbito bastante alargado. Com uma abordagem marcadamente estruturalista, são várias as indústrias abrangidas pelo standard. A indústria automóvel, a indústria aeronáutica e espacial, e a indústria electrónica são as mais conhecidas. A indústria da construção encontrava-se incluída numa fase inicial do projecto, no entanto, a sua evolução a nível deste standard foi perdendo fulgor, sendo actualmente visto como mal sucedida <ref>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.</ref>.
+
As especificações STEP apresentam um âmbito bastante alargado. Com uma abordagem marcadamente estruturalista, são várias as indústrias abrangidas pelo standard. A indústria automóvel, a indústria aeronáutica e espacial, e a indústria electrónica são as mais conhecidas. A indústria da construção encontrava-se incluída numa fase inicial do projecto, no entanto, a sua evolução a nível deste standard foi perdendo fulgor, sendo actualmente visto como mal sucedida <ref name="Monteiro" />.
  
 
O modelo IFC surge na década de 90 como uma iniciativa da IAI (International Alliance
 
O modelo IFC surge na década de 90 como uma iniciativa da IAI (International Alliance
 
for Interoperability) com vista à criação de um standard de representação para a construção. A herança deixada pelo projecto ISO-STEP reflecte-se na utilização da mesma linguagem de programação: EXPRESS e EXPRESS-G. A IAI é hoje conhecida como buildingSMART Alliance.
 
for Interoperability) com vista à criação de um standard de representação para a construção. A herança deixada pelo projecto ISO-STEP reflecte-se na utilização da mesma linguagem de programação: EXPRESS e EXPRESS-G. A IAI é hoje conhecida como buildingSMART Alliance.
  
−
A cronologia de desenvolvimento do modelo IFC revela uma primeira fase, até 2002, onde se procurou sobretudo desenvolver os primeiros protótipos e produzir as primeiras aplicações estáveis. Em 2002, uma parte significativa do modelo obteve certificação ISO. Entretanto, registou-se um crescimento significativo do modelo. Foram surgindo iniciativas para implementação do modelo IFC, das quais se destaca a aplicação ao licenciamento automático de projectos, ao mesmo tempo que o modelo começava a aparecer num cada vez maior número de aplicações BIM <ref>Maló, Pedro - Casos de Estudo BIM. UNINOVA, (2006).</ref>.
+
A cronologia de desenvolvimento do modelo IFC revela uma primeira fase, até 2002, onde se procurou sobretudo desenvolver os primeiros protótipos e produzir as primeiras aplicações estáveis. Em 2002, uma parte significativa do modelo obteve certificação ISO. Entretanto, registou-se um crescimento significativo do modelo. Foram surgindo iniciativas para implementação do modelo IFC, das quais se destaca a aplicação ao licenciamento automático de projectos, ao mesmo tempo que o modelo começava a aparecer num cada vez maior número de aplicações [[BIM]] <ref>Maló, Pedro - Casos de Estudo BIM. UNINOVA, (2006).</ref>.
 +
 
 +
O desenvolvimento das especificações do modelo IFC encontra-se ao cargo do MSG (Model Support Group), que conta actualmente com oito pessoas a trabalharem a tempo parcial <ref name="IAI">IAI, buildingSMART International Limited - Industry Foundation Classes; IFC2x Edition 4.(2010). Disponível em http://www.iai-tech.org/</ref>.
 +
 
 +
Em 2010, a versão IFC 2x4 foi submetida para total certificação ISO. São esperados resultados para 2011. A obtenção de certificação ISO completa significa um grande passo no sentido de implementar o modelo IFC como um standard [[BIM]] universal.
 +
 
 +
= Cobertura =
 +
 
 +
A passagem de dados referentes a objectos definidos em modelos proprietários para um modelo estrutural IFC, procede-se através da desmaterialização dos objectos nas suas componentes mais básicas: geometria, relações e propriedades. Os recursos IFC associados a estas três componentes têm sido sucessivamente actualizados de modo a cobrir a generalidade das necessidades de representação.
 +
 
 +
As '''geometrias''' simples são asseguradas pelo modelo, ao contrário de formas complexas constituídas por várias linhas curvas que podem ser transmitidas com buracos ou outros erros.
 +
 
 +
Em relação às '''relações''' entre objectos, não são conhecidas omissões, pelo que a extensa gama de entidades de representação de relações incluída no modelo, parece englobar todas as necessidades actuais, seja a atribuir relações, composição e decomposição de partes, associação de informação a objectos, definição de relações genéricas ou conectividade topológica entre elementos <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>.
 +
 
 +
O carácter generalista do modelo IFC obriga à inclusão de um conjunto muito heterogéneo de '''propriedades''' na sua base de dados. Existe um leque demasiado alargado de propriedades de produtos reais para conseguir agrupar totalmente num modelo de representação. Deste modo, existem efectivamente várias omissões no que toca à representação de propriedades. Para gerir esta situação, foram introduzidos no modelo vários conjuntos de propriedades (Property Sets) referentes às necessidades mais comuns (ex: paredes, janelas, vigas propriedades mecânicas e térmicas, custos, tempo, espaços, etc.). As propriedades mais específicas são depois introduzidas pelo utilizador como dependências das propriedades mais genéricas. O modelo apresenta assim entidades para formação de novos property sets e entidades para relacioná-los com as propriedades e elementos existentes <ref name="Monteiro">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.</ref>.
 +
 
 +
O modelo IFC contém ainda um quarto conjunto de recursos de representação, as '''meta propriedades''', directamente associadas aos princípios de gestão da informação ao longo do tempo, pelo que o modelo apresenta alguma robustez na capacidade de representação de domínios, identificação, gestão, monitorização e controlo de materiais, consentimentos, objectivos e restrições, entre outros <ref name="Eastman08" />.
 +
 
 +
= Arquitectura =
 +
 
 +
[[Ficheiro:Estrutura IFC.jpg|thumb|right|350px|Relações entre camadas do 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="IAI" />.|right]]
 +
 
 +
Um modelo completo de tão elevada dimensão requer um grande esforço de desenvolvimento apenas possível com trabalho de equipa, assente na distribuição de responsabilidades por várias frentes.
 +
 
 +
De modo a satisfazer todos os requisitos de modelação, a estrutura do modelo IFC  permite diversificar os recursos de representação por diferentes módulos para abordar as várias especialidades do sector da construção, e ao mesmo tempo, centralizar os recursos para harmonizar e integrar os diferentes módulos numa única base de dados consistente. A dificuldade está em encontrar o equilíbrio certo entre flexibilidade para assegurar a dispersão do trabalho por módulos e a rigidez estrutural do modelo, mantendo a consistência da base de dados após a integração dos diferentes módulos <ref name="IAIIFC">IAI, International Alliance of Interoperability - IFC Object Model Architecture Guide. (1999) Disponível em http://www.iai-tech.org/</ref>.
 +
 
 +
A análise de anteriores iniciativas referentes a modelos de informação estruturalistas, permitiu identificar uma série de conceitos que se encontravam de acordo com o pretendido para o modelo IFC. Com efeito, importou-se o conceito de estruturação de modelos por diferentes níveis de abstracção. Esta arquitectura de organização por camada era vista como uma das melhores soluções para especificação de modelos de informação de âmbito alargado.
 +
 
 +
A arquitectura do modelo IFC assenta numa estrutura modular para o desenvolvimento dos componentes do modelo, dividida em quatro camadas conceptuais que funcionam segundo uma hierarquia de referências em escada. Quer isto dizer que os módulos genéricos presentes nas camadas inferiores apenas podem referenciar módulos do mesmo nível de abstracção, enquanto os módulos nas camadas superiores de âmbito mais especializado podem referenciar todos os outros módulos <ref name="Monteiro" />.
 +
 
 +
A camada mais genérica da estrutura do modelo IFC contém as classes que definem os recursos de representação. A camada que se segue define o núcleo estrutural do modelo IFC, contendo o módulo Kernel e um módulo com extensões para o Kernel. Segue-se a camada de elementos partilhados ou camada de [[interoperabilidade]], com uma gama de módulos que definem objectos ou classes de objectos comuns a várias áreas da construção. A última camada contém os módulos que definem as várias especialidades da construção. Nesta camada encontram-se ainda módulos de adaptadores para alguns domínios de aplicações não IFC.
 +
 
 +
A estrutura do modelo IFC dividida por camadas assegura o agrupamento dos módulos conceptuais por relevância em termos de nível de abstracção. Com efeito, entidades presentes no módulo Kernel terão um nível de abstracção superior a qualquer uma das entidades dos módulos dos domínios. Interessa, pois, conhecer os vários módulos presentes na base de dados do modelo IFC, pelo que se justifica uma análise por camadas.
 +
 
 +
=== Camada de recursos ===
 +
 
 +
A camada de recursos contém esquemas de dados para suporte das estruturas de dados do modelo. As entidades presentes nesta camada representam as entidades mais genéricas, podendo ser referenciadas por todas as outras entidades do modelo, inclusive as entidades Kernel. Deste modo, as entidades dos recursos não podem existir independentemente já que a sua função passa por suportar as restantes entidades do modelo.
 +
 
 +
Os módulos presentes nesta camada representam diferentes actividades necessárias à representação de produtos da construção. Por exemplo, toda a informação relacionada com custos é absorvida pelo módulo “IfcCostResource”. Qualquer classe presente nas camadas superiores que envolva uma actividade de custos irá forçosamente referenciar este módulo.
 +
A camada de recursos, na versão mais actual IFC 2x4, é constituída por vinte e dois módulos:
 +
 
 +
*Agentes
 +
*Aparência
 +
*Apresentação
 +
*Aprovação
 +
*Carga Estrutural
 +
*Constrangimentos
 +
*Custo
 +
*Data e Tempo
 +
*Definição
 +
*Geometria
 +
*Materiais
 +
*Medidas
 +
*Modelo Geométrico
 +
*Organização
 +
*Perfil
 +
*Propriedades
 +
*Quantidades
 +
*Referências Externas
 +
*Representação
 +
*Restrições Geométricas
 +
*Topologia
 +
*Utilidade
 +
 
 +
=== Camada Nuclear ===
 +
 
 +
Os esquemas estruturais nucleares definem a camada mais genérica da arquitectura do modelo IFC. As entidades definidas nesta camada podem ser referenciadas e especializadas por todas as entidades dos módulos de elementos partilhados e dos módulos dos domínios. A camada nuclear fornece a estrutura básica, as relações fundamentais e os conceitos comuns para todas as eventuais especializações de aspectos específicos em modelos, definindo desta forma a maioria dos conceitos abstractos.
 +
 
 +
Todas as entidades definidas na camada nuclear derivam da entidade “IfcRoot” e possuem identificação, nome, descrição e informação de controlo únicas. A organização de todas as entidades do modelo IFC como derivações da entidade “IfcRoot” foi pensada de modo a criar uma super-estrutura estável que permita a harmonização das novas entidades que vão sendo incluídas no modelo.
 +
 
 +
A camada nuclear define os seus esquemas de dados a dois níveis distintos de generalização: Kernel e Extensões.
 +
 
 +
Kernel ou núcleo ou cerne é um módulo conceptual encontrado num grande número de modelos de dados. Habitualmente, o Kernel define a ponte entre o hardware e o software, definindo quais os recursos de hardware mobilizados para cada software.
 +
 
 +
No modelo IFC o esquema Kernel define a parte mais abstracta da arquitectura do modelo. Neste módulo, são capturadas as características conceptuais de determinado elemento, de modo a conhecer qual o significado semântico na óptica de um modelo de informação, ou seja, distinguir entre objecto, propriedade ou relação. Estes três tipos de entidades formam o primeiro nível de especialização na hierarquia do modelo IFC.
 +
 
 +
De modo a estabelecer os pontos de transição entre o módulo Kernel e o módulo de Extensões, o elemento é sujeito a um segundo nível de especialização semântica pela distinção entre produto, processo, controlo ou recurso.
 +
 
 +
=== Camada dos elementos partilhados ===
 +
 
 +
Os esquemas estruturais para elementos partilhados contêm entidades que definem especializações intermédias. Por outras palavras, as entidades definidas nesta camada são referenciadas por dois ou mais módulos distintos da camada dos domínios, fornecendo objectos e relações especializadas a múltiplos domínios.
 +
 
 +
A organização desta camada permite uma estruturação individualizada das várias especializações por domínios diferentes, ao mesmo tempo que possibilita a [[interoperabilidade]] entre os mesmos. Este é um aspecto importante nas abordagens estruturalistas dos modelos de informação na medida em que possibilita uma arquitectura tipo “Plug-In”, ou seja, actualizar o modelo pela adição contínua de extensões ao núcleo da base de dados. Por outro lado, permite “subcontratar” o desenvolvimento de domínios e aplicações para fora do Model Support Group.
 +
 
 +
A versão IFC 2x4 inclui cinco diferentes módulos de elementos partilhados:
 +
 
 +
*Serviços em edifícios
 +
*Componentes
 +
*Elementos de edifícios
 +
*Elementos de gestão
 +
*Elementos de mobiliário e equipamentos
 +
 
 +
Esta camada conta ainda com uma segunda função conceptual, o adaptador de [[interoperabilidade]], que, ainda que não apareça directamente sob a forma de um módulo, encontra-se presente como um resultado da própria organização da arquitectura do modelo IFC. O adaptador de [[interoperabilidade]] tem como objectivo constituir uma forma de aceder a vários módulos dos domínios, inclusivamente por modelos fora da IAI.
 +
 
 +
Os adaptadores representam requisitos para facilitar os seguintes aspectos<ref name="IAI" />:
 +
 
 +
*Introdução directa de módulos de especialidades, permitindo a introdução das classes de especialidades ao núcleo do modelo IFC, intermediados pelas classes de [[interoperabilidade]] existentes na respectiva camada.
 +
 
 +
*Ligação de módulos de especialidades não harmonizados e não produzidos pela IAI, segundo um adaptador que fornece um mapeamento do mecanismo até ao núcleo, passando pela camada de [[interoperabilidade]]. A configuração da interface do adaptador é da responsabilidade do produtor do módulo de especialidade e integra-se na respectiva camada do modelo IFC.
 +
 
 +
*Ligação entre módulos de especialidades, segundo um mecanismo que permita a [[interoperabilidade]] entre domínios de aplicação. Este mecanismo deve possuir um repositório para armazenar a informação, pois os adaptadores são da responsabilidade de quem produz os módulos de especialidades e como tal, é necessário guardar a informação das ligações entre os vários domínios.
 +
 
 +
Os adaptadores são baseados nas configurações das extensões do núcleo e a sua acção resulta numa melhoria contínua do modelo IFC. Estas melhorias são resultado da adição de novos conceitos comuns a todos os domínios de aplicação, logo, os adaptadores podem mesmo resultar numa melhoria dos próprios módulos de especialidades já que lhes podem estar a introduzir novas funções, de modo a torná-los compatíveis.
 +
 
 +
As extensões referentes a domínios já cobertos pelo modelo IFC, tais como arquitectura ou AVAC, não necessitam de um mapeamento até às configurações do núcleo, pelo que, para estes casos, não será necessário um adaptador específico. Por outras palavras, também é possível trabalhar exclusivamente na melhoria dos módulos já existentes, tornando-os completos.
 +
 
 +
Todo o trabalho externo à IAI tem de ser submetido ao Model Support Group para revisão, aprovação e introdução no modelo IFC.
 +
 
 +
=== Camada dos domínios ===
 +
 
 +
Os esquemas estruturais da camada dos domínios contêm entidades com especializações finais de acordo com os requisitos definidos para os modelos de informação da construção. A organização das entidades por módulos obedece à divisão de especialidades estabelecida pela indústria da construção.
 +
 
 +
As entidades definidas nesta camada são totalmente independentes e não podem ser referenciadas por qualquer outra camada.
 +
 
 +
Parte das definições dos domínios representa a definição do mapeamento dos modelos de domínios de especialidades. Modelos totalmente harmonizados com as especificações IFC são ligados directamente ao núcleo. As restantes devem fornecer mapas com a definição dos adaptadores. Para o caso de ser necessário referenciar classes de [[interoperabilidade]], devem ser fornecidos os mapas com as definições dos adaptadores para a respectiva camada.
 +
 
 +
A versão IFC 2x4 incluí oito diferentes módulos na camada dos domínios:
 +
 
 +
*Análise Estrutural
 +
*Arquitectura
 +
*AVAC
 +
*Canalização e Segurança Contra Incêndios
 +
*Controlos
 +
*Estruturas
 +
*Gestão da Construção
 +
*Rede Elétrica
 +
 
 +
= Property Sets =
 +
 
 +
[[File:IfcPropertyDefinition.jpg|thumb|right|200px|Especificações EXPRESS-G da entidade ''IfcPropertyDefinition'' - adaptado de <ref name="IAI" />.]]
 +
 
 +
O modelo IFC foi desenvolvido com base num pressuposto de interactividade com o utilizador. O âmbito do modelo é demasiado abrangente para incluir todas as especificações existentes a nível mundial na indústria da construção, logo, o modelo foi estruturado de forma a possibilitar a entrada de informação de forma expedita. A alteração de entidades nucleares do modelo só pode ser feita segundo um rigoroso processo de avaliação e certificação, no entanto, a adição de propriedades pode ser realizada por cada utilizador sem precisar de submeter as especificações à buildingSMART, visto que todo o processo se desenvolve ao nível das aplicações de modelação. A este processo designa-se a adição de ''property sets''.
  
−
O desenvolvimento das especificações do modelo IFC encontra-se ao cargo do MSG (Model Support Group), que conta actualmente com oito pessoas a trabalharem a tempo parcial <ref>IAI, buildingSMART International Limited - Industry Foundation Classes; IFC2x Edition 4.(2010). Disponível em http://www.iai-tech.org/</ref>.
+
Nas especificações do modelo IFC <ref name="IAI" />, os ''property sets'' são definidos da seguinte forma: ''IfcPropertySet define todas as propriedades dinamicamente extensíveis. Um property set é uma "classe contentor" para todas as propriedades dentro de uma árvore de propriedades. As propriedades são interpretadas com base no nome do atributo.''
  
−
Em 2010, a versão IFC 2x4 foi submetida para total certificação ISO. São esperados resultados para 2011. A obtenção de certificação ISO completa significa um grande passo no sentido de implementar o modelo IFC como um standard BIM universal.
+
= Iniciativas =
  
−
[[File:Modelo IFC.jpg]]
+
[[Ficheiro:CORENET.jpg|thumb|right|280px|Sistematização da plataforma de verificação de conformidade regulamentar, baseada na internet, desenvolvida pela CORENET <ref name="SIGABIM" /> - traduzido de <ref name="CORENET">Teo Ai Lin, E. (2006) Building Smart - A Strategy for Implementing BIM Solution in Singapure.</ref>.]]
  
−
= Fundamentos =
+
Actualmente, as aplicações [[BIM]] mais correntes já incluem o formato IFC nas suas especificações de importação e exportação de ficheiros, o que permite que o formato seja uma ferramenta de apoio em [[Interoperabilidade BIM#Fluxo IFC|fluxos de trabalho]] baseados em [[BIM]].
  
 +
A iniciativa “Construction and Real Estate Network” ('''CORENET'''), com origem em 1995, em Singapura, é um dos mais bem sucedidos exemplos da implementação do modelo IFC num fluxo de trabalho, neste caso a nível do licenciamento automático de projectos. Trata-se de uma aplicação avançada, desenvolvida numa estrutura servidor – cliente, que permite a projectistas submeterem o seu trabalho para verificação regulamentar. A internet funciona como plataforma da aplicação. A interacção entre o sistema de verificação e o projecto processa-se com a submissão do ficheiro IFC numa plataforma com um modelo de licenciamento que realiza a verificação do cumprimento dos parâmetros e disposições regulamentares <ref name="CORENET" />.
  
 +
Estudos sobre esta plataforma <ref name="CORENET" />, <ref>Solihin, W., Lessons learned from experience of code-checking implementation in Singapore, Success, Challenges, and Future Outlook. 2004.</ref>, vêm reforçar a importância de serem resolvidas certas questões relacionadas com a [[interoperabilidade]] entre sistemas por via do modelo IFC, de modo a poder passar a uma fase seguinte de desenvolvimento e consolidação de processos. Será, pois, necessário sistematizar e aplicar o conhecimento em práticas que favoreçam a implementação destas tecnologias numa perspectiva mais global. Por outro lado, é salientado o papel decisivo dos governos, dos grandes clientes e das grandes empresas, em reforçar os esforços com vista à evolução do papel dos modelos de informação na construção.
  
 +
Na Noruega, as entidades responsáveis pelas obras públicas procuraram aplicar os princípios explorados na iniciativa CORENET ao seu sistema de licenciamento de projectos de modo a aumentar a transparência dos serviços públicos e agilizar procedimentos. Surge assim o projecto ByggSøk que visa desenvolver um sistema público de serviços electrónicos para as áreas do planeamento e ordenamento do território e da construção <ref>Rooth, Ø. (2008) BIM case study - Norway.</ref>, assente numa série de metodologias que vêem sendo desenvolvidas de forma contínua.
  
 +
Com esta iniciativa, pretende-se aumentar a eficiência e competitividade do sector público da construção através da standardização dos processos de troca de informação entre entidades do sector. Num sistema em tudo parecido com o projecto CORENET, apoiado no modelo IFC, pretende-se criar uma plataforma de processamento electrónico das propostas de projectos de planeamento e construção, com vista ao licenciamento e registo electrónico público dos projectos submetidos para as várias instâncias de licenciamento.
  
 +
A componente do planeamento e ordenamento do território assume maior importância do que em Singapura, pelo que a [[interoperabilidade]] entre sistemas [[BIM]], modelo IFC e sistemas GIS representa uma prioridade. O formato IFG surge da necessidade em armazenar de forma consistente a informação geográfica em conjunto com a informação dos edifícios numa única base de dados, e de suportar o desenvolvimento de sistemas de licenciamento automático de projectos de planeamento do território, correspondendo a uma iniciativa das autoridades norueguesas para integrar os projectos GIS (“Geographic Information System”) nas especificações do modelo IFC.
  
 +
O desenvolvimento do formato IFG visa suportar os processos de submissão dos documentos para licenciamento de projectos de acordo com as directivas de ordenamento do território local. Por outro lado, permite retirar a informação geográfica da base de dados local e incorporá-la directamente nas primeiras fases do projecto.
  
 +
= Viewers =
  
 +
Encontram-se disponíveis na internet diversas aplicações gratuitas (freeware) para abrir ficheiros IFC, tornando possível a visualização de modelos [[BIM]] em formato IFC sem ter de usar software comercial de modelação como o ArchiCAD ou o Revit.
  
 +
De entre as mais utilizadas contam-se as seguintes:
  
 +
*[http://www.ifcbrowser.com/ IFC Engine Viewer]
 +
*[http://www.constructivity.com/products.htm Constructivity Model Viewer]
 +
*[http://www.dds-cad.net/132x2x0.xhtml DDS CAD Viewer]
 +
*[http://g-e-m-team-solutions-ifc-quick-browser.software.informer.com/ IFC Quick Browser]
 +
*[http://www.iai.fzk.de/www-extern/index.php?id=1134&L=1 IFC Object Counter]
 +
*[http://serviceplus.nemetschek.de/de/aktionen.nsf/link/collaboration_ifc_e.html Nemetcheck IFC  Viewer]
 +
*[http://www.solibri.com/solibri-ifc-optimizer.html Solibri IFC Optimizer]
 +
*[http://www.solibri.com/solibri-model-viewer.html Solibri Model Viewer]
 +
*[http://www.teklabimsight.com/ Tekla BIMsight]
  
 +
Cada uma das aplicações apresenta formas distintas de visualizar o ficheiro IFC, bem como diferentes ferramentas para tratamento da informação. As funcionalidades dos viewers incluem <ref>Amor, R. and J. Dimyadi, An open repository of IFC data models and analyses to support interoperability deployment. CIB W78 2010: International Conference - Cairo, Egypt, 2010.</ref>:
  
 +
*Geração de estatísticas resumidas sobre o número de objectos encontrados em cada ficheiro;
 +
*Navegação da base de dados do modelo, através da listagem de objectos do ficheiro;
 +
*Análise de conformidade macro dos objectos com a respectiva especificação IFC;
 +
*Optimização do ficheiro IFC através da remoção de informação redundante, com vista à redução do tamanho do ficheiro e do tempo de processamento;
 +
*Visualização e navegação do modelo tridimensional;
 +
*Navegação geométrica através da hierarquia de objectos;
 +
*Funcionalidades rudimentares de verificação e validação do modelo de dados;
 +
*Comparação entre dois ficheiros IFC para determinar as diferenças entre ambos.
 +
 +
= Ligações internas =
 +
 +
Ver também:
 +
 +
* [[BIM|Building Information Modeling]]
 +
* [[interoperabilidade|Interoperabilidade BIM]]
 +
* [[Codificação usando entidades 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:IFC]]
 +
[[Categoria:Gestão da Informação]]

Edição atual desde as 12h48min de 23 de outubro de 2013

Industry Foundation Classes (IFC) designa um formato universal para representação dos produtos da construção e troca de dados entre sistemas. Não sendo ainda um formato de interoperabilidade standard (a última versão, IFC 2x4, está em processo de aguardar certificação total da International Organization for Standardization), é já habitual a utilização das especificações IFC nas aplicações BIM mais correntes.

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].

Retrospectiva

Estrutura da base de dados do modelo IFC, versão 2x4 [1] - traduzido de [2].

O modelo IFC tem uma origem próxima da iniciativa ISO-STEP. A origem do STEP (Standard for the Exchange of Product model data) remonta para a década de 80. Numa iniciativa ISO (International Organization for Standardization) foram criados vários comités para o desenvolvimento de um standard universal para a representação do ciclo de vida de vários produtos industriais.

Este standard deveria obedecer a uma série de especificações próprias de um modelo de dados para representação de produtos. Para o efeito, foi desenvolvida uma linguagem de programação que permitisse a estruturação desmaterializada do modelo, de modo a permitir a incorporação sucessiva de novos elementos e especificações. Deste modo, pretendia-se obter um potente mecanismo para modelação e integração de informação, consistente com os princípios de troca de dados entre sistemas. Era assim criada a linguagem de programação EXPRESS e EXPRESS-G (componente gráfica) [3].

As especificações STEP apresentam um âmbito bastante alargado. Com uma abordagem marcadamente estruturalista, são várias as indústrias abrangidas pelo standard. A indústria automóvel, a indústria aeronáutica e espacial, e a indústria electrónica são as mais conhecidas. A indústria da construção encontrava-se incluída numa fase inicial do projecto, no entanto, a sua evolução a nível deste standard foi perdendo fulgor, sendo actualmente visto como mal sucedida [4].

O modelo IFC surge na década de 90 como uma iniciativa da IAI (International Alliance for Interoperability) com vista à criação de um standard de representação para a construção. A herança deixada pelo projecto ISO-STEP reflecte-se na utilização da mesma linguagem de programação: EXPRESS e EXPRESS-G. A IAI é hoje conhecida como buildingSMART Alliance.

A cronologia de desenvolvimento do modelo IFC revela uma primeira fase, até 2002, onde se procurou sobretudo desenvolver os primeiros protótipos e produzir as primeiras aplicações estáveis. Em 2002, uma parte significativa do modelo obteve certificação ISO. Entretanto, registou-se um crescimento significativo do modelo. Foram surgindo iniciativas para implementação do modelo IFC, das quais se destaca a aplicação ao licenciamento automático de projectos, ao mesmo tempo que o modelo começava a aparecer num cada vez maior número de aplicações BIM [5].

O desenvolvimento das especificações do modelo IFC encontra-se ao cargo do MSG (Model Support Group), que conta actualmente com oito pessoas a trabalharem a tempo parcial [2].

Em 2010, a versão IFC 2x4 foi submetida para total certificação ISO. São esperados resultados para 2011. A obtenção de certificação ISO completa significa um grande passo no sentido de implementar o modelo IFC como um standard BIM universal.

Cobertura

A passagem de dados referentes a objectos definidos em modelos proprietários para um modelo estrutural IFC, procede-se através da desmaterialização dos objectos nas suas componentes mais básicas: geometria, relações e propriedades. Os recursos IFC associados a estas três componentes têm sido sucessivamente actualizados de modo a cobrir a generalidade das necessidades de representação.

As geometrias simples são asseguradas pelo modelo, ao contrário de formas complexas constituídas por várias linhas curvas que podem ser transmitidas com buracos ou outros erros.

Em relação às relações entre objectos, não são conhecidas omissões, pelo que a extensa gama de entidades de representação de relações incluída no modelo, parece englobar todas as necessidades actuais, seja a atribuir relações, composição e decomposição de partes, associação de informação a objectos, definição de relações genéricas ou conectividade topológica entre elementos [6].

O carácter generalista do modelo IFC obriga à inclusão de um conjunto muito heterogéneo de propriedades na sua base de dados. Existe um leque demasiado alargado de propriedades de produtos reais para conseguir agrupar totalmente num modelo de representação. Deste modo, existem efectivamente várias omissões no que toca à representação de propriedades. Para gerir esta situação, foram introduzidos no modelo vários conjuntos de propriedades (Property Sets) referentes às necessidades mais comuns (ex: paredes, janelas, vigas propriedades mecânicas e térmicas, custos, tempo, espaços, etc.). As propriedades mais específicas são depois introduzidas pelo utilizador como dependências das propriedades mais genéricas. O modelo apresenta assim entidades para formação de novos property sets e entidades para relacioná-los com as propriedades e elementos existentes [4].

O modelo IFC contém ainda um quarto conjunto de recursos de representação, as meta propriedades, directamente associadas aos princípios de gestão da informação ao longo do tempo, pelo que o modelo apresenta alguma robustez na capacidade de representação de domínios, identificação, gestão, monitorização e controlo de materiais, consentimentos, objectivos e restrições, entre outros [6].

Arquitectura

Relações entre camadas do modelo IFC [1] - traduzido de [2].

Um modelo completo de tão elevada dimensão requer um grande esforço de desenvolvimento apenas possível com trabalho de equipa, assente na distribuição de responsabilidades por várias frentes.

De modo a satisfazer todos os requisitos de modelação, a estrutura do modelo IFC permite diversificar os recursos de representação por diferentes módulos para abordar as várias especialidades do sector da construção, e ao mesmo tempo, centralizar os recursos para harmonizar e integrar os diferentes módulos numa única base de dados consistente. A dificuldade está em encontrar o equilíbrio certo entre flexibilidade para assegurar a dispersão do trabalho por módulos e a rigidez estrutural do modelo, mantendo a consistência da base de dados após a integração dos diferentes módulos [7].

A análise de anteriores iniciativas referentes a modelos de informação estruturalistas, permitiu identificar uma série de conceitos que se encontravam de acordo com o pretendido para o modelo IFC. Com efeito, importou-se o conceito de estruturação de modelos por diferentes níveis de abstracção. Esta arquitectura de organização por camada era vista como uma das melhores soluções para especificação de modelos de informação de âmbito alargado.

A arquitectura do modelo IFC assenta numa estrutura modular para o desenvolvimento dos componentes do modelo, dividida em quatro camadas conceptuais que funcionam segundo uma hierarquia de referências em escada. Quer isto dizer que os módulos genéricos presentes nas camadas inferiores apenas podem referenciar módulos do mesmo nível de abstracção, enquanto os módulos nas camadas superiores de âmbito mais especializado podem referenciar todos os outros módulos [4].

A camada mais genérica da estrutura do modelo IFC contém as classes que definem os recursos de representação. A camada que se segue define o núcleo estrutural do modelo IFC, contendo o módulo Kernel e um módulo com extensões para o Kernel. Segue-se a camada de elementos partilhados ou camada de interoperabilidade, com uma gama de módulos que definem objectos ou classes de objectos comuns a várias áreas da construção. A última camada contém os módulos que definem as várias especialidades da construção. Nesta camada encontram-se ainda módulos de adaptadores para alguns domínios de aplicações não IFC.

A estrutura do modelo IFC dividida por camadas assegura o agrupamento dos módulos conceptuais por relevância em termos de nível de abstracção. Com efeito, entidades presentes no módulo Kernel terão um nível de abstracção superior a qualquer uma das entidades dos módulos dos domínios. Interessa, pois, conhecer os vários módulos presentes na base de dados do modelo IFC, pelo que se justifica uma análise por camadas.

Camada de recursos

A camada de recursos contém esquemas de dados para suporte das estruturas de dados do modelo. As entidades presentes nesta camada representam as entidades mais genéricas, podendo ser referenciadas por todas as outras entidades do modelo, inclusive as entidades Kernel. Deste modo, as entidades dos recursos não podem existir independentemente já que a sua função passa por suportar as restantes entidades do modelo.

Os módulos presentes nesta camada representam diferentes actividades necessárias à representação de produtos da construção. Por exemplo, toda a informação relacionada com custos é absorvida pelo módulo “IfcCostResource”. Qualquer classe presente nas camadas superiores que envolva uma actividade de custos irá forçosamente referenciar este módulo. A camada de recursos, na versão mais actual IFC 2x4, é constituída por vinte e dois módulos:

  • Agentes
  • Aparência
  • Apresentação
  • Aprovação
  • Carga Estrutural
  • Constrangimentos
  • Custo
  • Data e Tempo
  • Definição
  • Geometria
  • Materiais
  • Medidas
  • Modelo Geométrico
  • Organização
  • Perfil
  • Propriedades
  • Quantidades
  • Referências Externas
  • Representação
  • Restrições Geométricas
  • Topologia
  • Utilidade

Camada Nuclear

Os esquemas estruturais nucleares definem a camada mais genérica da arquitectura do modelo IFC. As entidades definidas nesta camada podem ser referenciadas e especializadas por todas as entidades dos módulos de elementos partilhados e dos módulos dos domínios. A camada nuclear fornece a estrutura básica, as relações fundamentais e os conceitos comuns para todas as eventuais especializações de aspectos específicos em modelos, definindo desta forma a maioria dos conceitos abstractos.

Todas as entidades definidas na camada nuclear derivam da entidade “IfcRoot” e possuem identificação, nome, descrição e informação de controlo únicas. A organização de todas as entidades do modelo IFC como derivações da entidade “IfcRoot” foi pensada de modo a criar uma super-estrutura estável que permita a harmonização das novas entidades que vão sendo incluídas no modelo.

A camada nuclear define os seus esquemas de dados a dois níveis distintos de generalização: Kernel e Extensões.

Kernel ou núcleo ou cerne é um módulo conceptual encontrado num grande número de modelos de dados. Habitualmente, o Kernel define a ponte entre o hardware e o software, definindo quais os recursos de hardware mobilizados para cada software.

No modelo IFC o esquema Kernel define a parte mais abstracta da arquitectura do modelo. Neste módulo, são capturadas as características conceptuais de determinado elemento, de modo a conhecer qual o significado semântico na óptica de um modelo de informação, ou seja, distinguir entre objecto, propriedade ou relação. Estes três tipos de entidades formam o primeiro nível de especialização na hierarquia do modelo IFC.

De modo a estabelecer os pontos de transição entre o módulo Kernel e o módulo de Extensões, o elemento é sujeito a um segundo nível de especialização semântica pela distinção entre produto, processo, controlo ou recurso.

Camada dos elementos partilhados

Os esquemas estruturais para elementos partilhados contêm entidades que definem especializações intermédias. Por outras palavras, as entidades definidas nesta camada são referenciadas por dois ou mais módulos distintos da camada dos domínios, fornecendo objectos e relações especializadas a múltiplos domínios.

A organização desta camada permite uma estruturação individualizada das várias especializações por domínios diferentes, ao mesmo tempo que possibilita a interoperabilidade entre os mesmos. Este é um aspecto importante nas abordagens estruturalistas dos modelos de informação na medida em que possibilita uma arquitectura tipo “Plug-In”, ou seja, actualizar o modelo pela adição contínua de extensões ao núcleo da base de dados. Por outro lado, permite “subcontratar” o desenvolvimento de domínios e aplicações para fora do Model Support Group.

A versão IFC 2x4 inclui cinco diferentes módulos de elementos partilhados:

  • Serviços em edifícios
  • Componentes
  • Elementos de edifícios
  • Elementos de gestão
  • Elementos de mobiliário e equipamentos

Esta camada conta ainda com uma segunda função conceptual, o adaptador de interoperabilidade, que, ainda que não apareça directamente sob a forma de um módulo, encontra-se presente como um resultado da própria organização da arquitectura do modelo IFC. O adaptador de interoperabilidade tem como objectivo constituir uma forma de aceder a vários módulos dos domínios, inclusivamente por modelos fora da IAI.

Os adaptadores representam requisitos para facilitar os seguintes aspectos[2]:

  • Introdução directa de módulos de especialidades, permitindo a introdução das classes de especialidades ao núcleo do modelo IFC, intermediados pelas classes de interoperabilidade existentes na respectiva camada.
  • Ligação de módulos de especialidades não harmonizados e não produzidos pela IAI, segundo um adaptador que fornece um mapeamento do mecanismo até ao núcleo, passando pela camada de interoperabilidade. A configuração da interface do adaptador é da responsabilidade do produtor do módulo de especialidade e integra-se na respectiva camada do modelo IFC.
  • Ligação entre módulos de especialidades, segundo um mecanismo que permita a interoperabilidade entre domínios de aplicação. Este mecanismo deve possuir um repositório para armazenar a informação, pois os adaptadores são da responsabilidade de quem produz os módulos de especialidades e como tal, é necessário guardar a informação das ligações entre os vários domínios.

Os adaptadores são baseados nas configurações das extensões do núcleo e a sua acção resulta numa melhoria contínua do modelo IFC. Estas melhorias são resultado da adição de novos conceitos comuns a todos os domínios de aplicação, logo, os adaptadores podem mesmo resultar numa melhoria dos próprios módulos de especialidades já que lhes podem estar a introduzir novas funções, de modo a torná-los compatíveis.

As extensões referentes a domínios já cobertos pelo modelo IFC, tais como arquitectura ou AVAC, não necessitam de um mapeamento até às configurações do núcleo, pelo que, para estes casos, não será necessário um adaptador específico. Por outras palavras, também é possível trabalhar exclusivamente na melhoria dos módulos já existentes, tornando-os completos.

Todo o trabalho externo à IAI tem de ser submetido ao Model Support Group para revisão, aprovação e introdução no modelo IFC.

Camada dos domínios

Os esquemas estruturais da camada dos domínios contêm entidades com especializações finais de acordo com os requisitos definidos para os modelos de informação da construção. A organização das entidades por módulos obedece à divisão de especialidades estabelecida pela indústria da construção.

As entidades definidas nesta camada são totalmente independentes e não podem ser referenciadas por qualquer outra camada.

Parte das definições dos domínios representa a definição do mapeamento dos modelos de domínios de especialidades. Modelos totalmente harmonizados com as especificações IFC são ligados directamente ao núcleo. As restantes devem fornecer mapas com a definição dos adaptadores. Para o caso de ser necessário referenciar classes de interoperabilidade, devem ser fornecidos os mapas com as definições dos adaptadores para a respectiva camada.

A versão IFC 2x4 incluí oito diferentes módulos na camada dos domínios:

  • Análise Estrutural
  • Arquitectura
  • AVAC
  • Canalização e Segurança Contra Incêndios
  • Controlos
  • Estruturas
  • Gestão da Construção
  • Rede Elétrica

Property Sets

Especificações EXPRESS-G da entidade IfcPropertyDefinition - adaptado de [2].

O modelo IFC foi desenvolvido com base num pressuposto de interactividade com o utilizador. O âmbito do modelo é demasiado abrangente para incluir todas as especificações existentes a nível mundial na indústria da construção, logo, o modelo foi estruturado de forma a possibilitar a entrada de informação de forma expedita. A alteração de entidades nucleares do modelo só pode ser feita segundo um rigoroso processo de avaliação e certificação, no entanto, a adição de propriedades pode ser realizada por cada utilizador sem precisar de submeter as especificações à buildingSMART, visto que todo o processo se desenvolve ao nível das aplicações de modelação. A este processo designa-se a adição de property sets.

Nas especificações do modelo IFC [2], os property sets são definidos da seguinte forma: IfcPropertySet define todas as propriedades dinamicamente extensíveis. Um property set é uma "classe contentor" para todas as propriedades dentro de uma árvore de propriedades. As propriedades são interpretadas com base no nome do atributo.

Iniciativas

Sistematização da plataforma de verificação de conformidade regulamentar, baseada na internet, desenvolvida pela CORENET [1] - traduzido de [8].

Actualmente, as aplicações BIM mais correntes já incluem o formato IFC nas suas especificações de importação e exportação de ficheiros, o que permite que o formato seja uma ferramenta de apoio em fluxos de trabalho baseados em BIM.

A iniciativa “Construction and Real Estate Network” (CORENET), com origem em 1995, em Singapura, é um dos mais bem sucedidos exemplos da implementação do modelo IFC num fluxo de trabalho, neste caso a nível do licenciamento automático de projectos. Trata-se de uma aplicação avançada, desenvolvida numa estrutura servidor – cliente, que permite a projectistas submeterem o seu trabalho para verificação regulamentar. A internet funciona como plataforma da aplicação. A interacção entre o sistema de verificação e o projecto processa-se com a submissão do ficheiro IFC numa plataforma com um modelo de licenciamento que realiza a verificação do cumprimento dos parâmetros e disposições regulamentares [8].

Estudos sobre esta plataforma [8], [9], vêm reforçar a importância de serem resolvidas certas questões relacionadas com a interoperabilidade entre sistemas por via do modelo IFC, de modo a poder passar a uma fase seguinte de desenvolvimento e consolidação de processos. Será, pois, necessário sistematizar e aplicar o conhecimento em práticas que favoreçam a implementação destas tecnologias numa perspectiva mais global. Por outro lado, é salientado o papel decisivo dos governos, dos grandes clientes e das grandes empresas, em reforçar os esforços com vista à evolução do papel dos modelos de informação na construção.

Na Noruega, as entidades responsáveis pelas obras públicas procuraram aplicar os princípios explorados na iniciativa CORENET ao seu sistema de licenciamento de projectos de modo a aumentar a transparência dos serviços públicos e agilizar procedimentos. Surge assim o projecto ByggSøk que visa desenvolver um sistema público de serviços electrónicos para as áreas do planeamento e ordenamento do território e da construção [10], assente numa série de metodologias que vêem sendo desenvolvidas de forma contínua.

Com esta iniciativa, pretende-se aumentar a eficiência e competitividade do sector público da construção através da standardização dos processos de troca de informação entre entidades do sector. Num sistema em tudo parecido com o projecto CORENET, apoiado no modelo IFC, pretende-se criar uma plataforma de processamento electrónico das propostas de projectos de planeamento e construção, com vista ao licenciamento e registo electrónico público dos projectos submetidos para as várias instâncias de licenciamento.

A componente do planeamento e ordenamento do território assume maior importância do que em Singapura, pelo que a interoperabilidade entre sistemas BIM, modelo IFC e sistemas GIS representa uma prioridade. O formato IFG surge da necessidade em armazenar de forma consistente a informação geográfica em conjunto com a informação dos edifícios numa única base de dados, e de suportar o desenvolvimento de sistemas de licenciamento automático de projectos de planeamento do território, correspondendo a uma iniciativa das autoridades norueguesas para integrar os projectos GIS (“Geographic Information System”) nas especificações do modelo IFC.

O desenvolvimento do formato IFG visa suportar os processos de submissão dos documentos para licenciamento de projectos de acordo com as directivas de ordenamento do território local. Por outro lado, permite retirar a informação geográfica da base de dados local e incorporá-la directamente nas primeiras fases do projecto.

Viewers

Encontram-se disponíveis na internet diversas aplicações gratuitas (freeware) para abrir ficheiros IFC, tornando possível a visualização de modelos BIM em formato IFC sem ter de usar software comercial de modelação como o ArchiCAD ou o Revit.

De entre as mais utilizadas contam-se as seguintes:

Cada uma das aplicações apresenta formas distintas de visualizar o ficheiro IFC, bem como diferentes ferramentas para tratamento da informação. As funcionalidades dos viewers incluem [11]:

  • Geração de estatísticas resumidas sobre o número de objectos encontrados em cada ficheiro;
  • Navegação da base de dados do modelo, através da listagem de objectos do ficheiro;
  • Análise de conformidade macro dos objectos com a respectiva especificação IFC;
  • Optimização do ficheiro IFC através da remoção de informação redundante, com vista à redução do tamanho do ficheiro e do tempo de processamento;
  • Visualização e navegação do modelo tridimensional;
  • Navegação geométrica através da hierarquia de objectos;
  • Funcionalidades rudimentares de verificação e validação do modelo de dados;
  • Comparação entre dois ficheiros IFC para determinar as diferenças entre ambos.

Ligações internas

Ver também:

Referências Bibliográficas

  1. ↑ 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 Erro de citação: Código <ref> inválido; o nome "SIGABIM" é definido mais de uma vez com conteúdos diferentes
  2. ↑ 2,0 2,1 2,2 2,3 2,4 2,5 IAI, buildingSMART International Limited - Industry Foundation Classes; IFC2x Edition 4.(2010). Disponível em http://www.iai-tech.org/
  3. ↑ Eastman, C.M., Building Product Models: Computer Environments Supporting Design and Construction. 1999.
  4. ↑ 4,0 4,1 4,2 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.
  5. ↑ Maló, Pedro - Casos de Estudo BIM. UNINOVA, (2006).
  6. ↑ 6,0 6,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.
  7. ↑ IAI, International Alliance of Interoperability - IFC Object Model Architecture Guide. (1999) Disponível em http://www.iai-tech.org/
  8. ↑ 8,0 8,1 8,2 Teo Ai Lin, E. (2006) Building Smart - A Strategy for Implementing BIM Solution in Singapure.
  9. ↑ Solihin, W., Lessons learned from experience of code-checking implementation in Singapore, Success, Challenges, and Future Outlook. 2004.
  10. ↑ Rooth, Ø. (2008) BIM case study - Norway.
  11. ↑ Amor, R. and J. Dimyadi, An open repository of IFC data models and analyses to support interoperability deployment. CIB W78 2010: International Conference - Cairo, Egypt, 2010.
Obtida de "https://fe.up.pt/gequaltec/w/index.php?title=Industry_Foundation_Classes&oldid=1861"