Home Artigos Aprenda o que é o IFC e qual a sua importância para o BIM

Aprenda o que é o IFC e qual a sua importância para o BIM

O IFC é muito mais que um formato de arquivo

 

A interoperabilidade é crítica para o sucesso do BIM. O desenvolvimento de padrões de dados abertos e o acesso “não-proprietário” para os dados do BIM é uma prioridade urgente para a indústria se quisermos evitar as ineficiências e os problemas recorrentes de reentrada de dados. A interoperabilidade, com o uso do IFC,  permitirá o reuso de dados de projeto já desenvolvidos e assim garantindo consistência entre cada um dos modelos para as diferentes representações do mesmo edifício. Dados consistentes, acurados e acessíveis por toda a equipe de projeto irão contribuir significativamente para mitigar os atrasos e os custos adicionais,  Howell e Batcheler (2004)

Aula sobre a estrutura do IFC

O desenvolvimento de um modelo de dados de edifícios, como o IFC, é relativamente novo, de acordo com Khemlani (2004). A primeira aplicação concebida com esse conceito − pela companhia húngara Graphisoft − foi o ArchiCAD. A mais recente é o Revit, cuja companhia responsável pelo seu desenvolvimento, a Revit Technology Corporation, foi comprada pela Autodesk em 2002.
Existem também outras aplicações, como, por exemplo, Bentley Architecture e Autodesk Architectural Desktop, que desenvolveram seus modelos de dados de Edifícios sobre suas plataformas originais em CAD: MicroStation e Auto CAD, respectivamente.
Todas essas aplicações possuem suas estruturas internas de dados no “formato proprietário”, isto é, elas não podem compartilhar suas informações entre si, a menos que exista um tradutor para isso.
Eastman et al. (2008) explicam que o IFC foi desenvolvido para criar um grande conjunto de dados consistentes para representar um modelo de dados de um edifício, com o objetivo de permitir a troca de informações entre diferentes fabricantes de software na AEC.
O IFC surge nesse contexto como um modelo de dados de tradução, em formato “não proprietário”, disponível livremente para a definição de objetos na AEC. Porém, ele não padroniza as estruturas de dados em aplicações de software, restringindo-se apenas à padronização das informações compartilhadas.
A buildingSMART  define o IFC como um esquema de dados que torna possível conter dados e trocar informações entre diferentes aplicativos para BIM. O esquema IFC é extensível e compreende informações cobrindo as muitas disciplinas que contribuem para um edifício durante seu ciclo de vida: desde a concepção, o projeto, a construção até a reforma ou demolição.
O IFC está registrado pela International Organization for Standardization (ISO) como ISO-PAS-16739 (2005) e encontra-se em processo de se tornar uma norma oficial. Cada implementação de troca em IFC precisa seguir o que se entende por “requisitos de troca” (exchange requirements). Esses requisitos especificam a informação que precisa estar presente em uma troca de dados em determinado estágio de um projeto, prevenindo incertezas.
Por intermédio do IFC é possível também a criação de “vistas de informação”, ou subconjuntos de dados, apenas com os dados necessários para determinado domínio, através do processo de Model View Definitions (MVD).
A General Services Administration (2007) define o IFC como um esquema de especificações que fornece maneiras de definir e conhecer as informações, as relações e as propriedades específicas de objetos de um edifício contidas em um modelo BIM.
De acordo com Jim Steel, Drogemuller e Toth (2012), o IFC foi definido, do ponto de vista técnico, usando as especificações da norma ISO 10303 11 (1994) para modelagem e troca de dados, também conhecida como Standard for the Exchange of Product Data (STEP).
O STEP teve seu desenvolvimento iniciado em 1984 pela ISO, com o objetivo de definir normas para a representação e troca de informações de maneira geral, e é utilizado em vários domínios, como a engenharia mecânica e a indústria de design. As pessoas inicialmente envolvidas no esforço da STEP criaram a IAI para o desenvolvimento de padrões específicos para a AEC. Por essa razão, o IFC utiliza recursos baseados no STEP e usa a mesma linguagem de modelagem, denominada EXPRESS.
O STEP consiste em uma gama de especificações, tendo mais notavelmente uma linguagem para especificação do esquema de dados, STEP/EXPRESS, ISO 10303 11 (2004), na qual a linguagem IFC é definida; um mapeamento, ISO 10303 21 (2002), para arquivos de texto que representam os modelos segundo o esquema de dados; um mapeamento, StepXML, ISO 10303 28 (2007), para arquivos no formato Extensible Markup Language (XML ); e um mapeamento para Application Program Interface (API ), ISO 10303 22 (1998), para acessar os modelos para programação, conhecido como Standard Data Access Interface (SDAI).
De todas essas tecnologias de mapeamento, a mais significativa em termos de interoperabilidade, de acordo com Jim Steel, Drogemuller e Toth (2012), é a ISO 10303 21 (2002), que define efetivamente o formato do arquivo IFC.
O desenvolvimento atual do modelo IFC está sob a responsabilidade do Model Support Group, coordenado pela buildingSMART (2012b). O IFC vem sendo desenvolvido desde 1997, quando foi lançada a versão 1.0, e após sucessivas e regulares atualizações encontra-se hoje na versão 2×4 (IFC4), lançada no princípio de 2012. As versões vão sofrendo modificações e incrementos para poder representar cada vez mais entidades e relações no edifício e no seu ciclo de vida.
Por ser um formato de dados neutro e aberto, ele está disponível para as empresas de software desenvolverem exportações de dados em IFC. Para isso, a aplicação precisa ser “IFC compatível”, um processo de certificação fornecido pela buildingSMART. Atualmente existem aproximadamente 204 softwares certificados como “IFC compatíveis”.


Visão geral da arquitetura do IFC
Para o entendimento do IFC como um todo utilizaremos o esquema conceitual da Figura 1. Para a descrição simplificada dessa estrutura foram revistos e resumidos os conceitos de Eastman et al. (2008), Khemlani (2004) e o site de referência do IFC da buildingSMART .

Figura 1: Visão geral do esquema IFC, versão 2×4

ifc
Fonte: Adaptado de buildingSMART

Nessa estrutura estão representadas quatro camadas que serão descritas em uma leitura na sequência de baixo para cima: Camada dos Recursos > Camada do Núcleo > Camada de Interoperabilidade: Elementos Compartilhados > Camada dos Domínios.
Camada dos recursos
Essa camada é a base composta por entidades comumente utilizadas nos objetos da AEC, como geometria, topologia, materiais, medidas, agentes responsáveis, representação, custos, etc. De acordo com Eastman et al. (2008), como os dados em IFC são extensíveis, essas entidades que estão na base podem ser especializadas e serem criadas novas subentidades.
Camada do núcleo
Todas as entidades dessa camada derivam da raiz do IFC e contêm entidades abstratas que são referenciadas pelas camadas mais altas da hierarquia.
A camada do núcleo é subdivida e em quatro subcamadas de extensão: Controle, Produto, Processo e Núcleo .
A subcamada núcleo (representada por um triângulo amarelo) fornece a estrutura de base, que são as relações e os conceitos fundamentais comuns para todas as especializações adicionais em modelos específicos e nos quais são definidos conceitos fundamentais como grupo, processo, produto, relacionamentos.
O esquema de extensão do produto (representado por um retângulo de cor laranja no centro) define componentes de construção abstratos, como espaço, local, construção, elemento.
O esquema de extensão de processo (representado por um retângulo de cor laranja do lado direito) capta ideias sobre o mapeamento de processos em uma sequência lógica do planejamento e programação de trabalho e das tarefas necessárias para a sua conclusão.
O esquema de extensão de controle (representado por um retângulo de cor laranja do lado esquerdo) trabalha com os conceitos relacionados ao controle do processo.
Camada de elementos compartilhados ou de interoperabilidade
Essa camada compreende as categorias de entidades que representam os elementos físicos de um edifício. É utilizada para compartilhamento de especialidades e de aplicações de manutenção e contém os elementos físicos de um edifício.
Ela possui definições de entidades como vigas, colunas, paredes, portas e outros elementos físicos de um edifício, assim como propriedades para controle de fluxos, fluidos, propriedades acústicas, entre outras.
Camada dos domínios
Essa é a camada de nível mais alto e lida com entidades de disciplinas específicas, como Arquitetura, Estrutura, Instalações, entre outras.

Como as entidades são definidas?
Para a demonstração desse conceito será utilizado um exemplo apresentado em um artigo de Khemlani (2004). Nesse exemplo serão utilizadas duas entidades básicas, uma “parede” e um “espaço”, e será visto como cada uma delas é representada individualmente e como a relação entre ambas é representada, conforme a Figura 2.
Na Figura 2, os retângulos representam as definições das entidades, mostrando alguns de seus atributos: os círculos pequenos representam as instâncias das entidades “parede” e “espaço”, e os losangos representam o relacionamento entre as entidades.

Figura 2: Entidade “parede” e entidade “‘espaço” no modelo IFC e suas relações

IFC

Fonte: Adaptado de Khemlani (2004)

Um entidade “parede” e outras entidades físicas, como lajes, vigas, pilares, etc., são definidas por uma hierarquia de entidades. Na prática, isso significa que a entidade “parede” (IfcWall) é definida como um subtipo da entidade “elementos do edifício” (ifcBuildingElement), que por sua vez é um subtipo da entidade “elemento” (ifcElement) e assim por diante, até a entidade “raiz” (ifcRoot).
Os atributos são associados com cada tipo de entidade e a entidade “parede” herda os atributos de todas as entidades acima, ou “entidades pai”, conhecidas como “supertipos”. Todas as entidades no nível superior nesse caso são abstratas, o que significa não ser possível criar uma instância de uma entidade desse tipo, motivo pelo qual essas entidades estão localizadas na camada do núcleo.
A entidade “parede”, no entanto, não é abstrata, significando que ela pode ser instanciada para criar os objetos “parede” que existem no modelo do edifício. Os atributos de uma parede, como seu tipo, forma, localização, quantidade, conexões, aberturas, etc., são, em sua maioria, primariamente definidos pelos seus “supertipos”.
Passando para a definição da entidade “espaço” (ifcSpace), definida como um subtipo de “elemento de estrutura espacial” (ifcSpatialStructureElement), esta, por sua vez, é um subtipo da entidade “produto” (ifcProduct), que também existe na hierarquia da entidade “parede”.
No caso da entidade “espaço”, todas as suas entidades supertipos são abstratas, e a entidade “espaço” herda todas as propriedades dos seus supertipos. Entretanto, da mesma forma que a entidade “parede” a entidade “espaço” não é abstrata e pode ser instanciada para criar os diferentes espaços do edifício.
Diferentes tipos de relações podem ser associadas às entidades usadas nesse exemplo. Uma relação de “agregação” pode ser aplicada para as instâncias da entidade “espaço”, para agrupá-las em um pavimento do edifício, e uma relação de “encapsulamento” pode ser aplicada para uma entidade “mobília”, para localizá-la dentro de um determinado espaço.
Se a entidade “parede” precisar ser associada à entidade “espaço”, uma relação de encapsulamento (ifcRelContainedInSpatialStructure) será aplicada. Como mostrado na Figura 2, o relacionamento ocorre nos níveis de ifcElement e ifcSpatialStructureElement, o que significa que qualquer outro elemento – parede, viga, coluna, porta, etc. – pode ser associado a uma estrutura espacial – um terreno, um edifício, um pavimento, um espaço.
Enquanto o formato IFC permite criar todos esses tipos de relacionamento, a responsabilidade de garantir que essas relações sejam feitas de maneira adequada é do autor do aplicativo, que deverá exportar o modelo no formato IFC.
Pelo fato de o IFC ser flexível e não impor uma única forma de associação, uma parede deve ser associada a um espaço, mas pode também ser associada a um pavimento.
Ao mesmo tempo, uma aplicação que necessite encontrar uma parede que esteja associada a um espaço, se essa associação não tiver sido feita de maneira explícita, a aplicação provavelmente não a encontrará. Assim, é muito importante a forma como um arquivo IFC é criado para exportação por um aplicativo, constituindo um fator crítico do sucesso da interoperabilidade entre aplicações usando o IFC.


Complexidade do padrão IFC
O padrão IFC é muito extenso e complexo, conforme Jim Steel, Drogemuller e Toth (2012). A versão atual, IFC4, inclui 126 tipos definidos, 206 tipos de enumeração, 59 tipos para seleção, 764 definições de entidades, 43 funções, 408 conjuntos de propriedades, 91 conjunto de quantidades e 1.691 propriedades individuais.
A complexidade do padrão é exacerbada pela possibilidade de existirem formas alternativas de modelagem para um mesmo objeto: por exemplo, um bloco estrutural pode ser tanto modelado por uma representação limitada por quatro planos quanto pela extrusão de uma superfície e um vetor. Cada um desses objetos tem diferentes significados semânticos e, embora possam ter a mesma aparência na vista em 3D, eles terão tratamentos diferentes na ferramenta de análise estrutural.
Para casos em que o IFC não tem um objeto em particular, a linguagem inclui um mecanismo de modelagem denominado IfcProxy , que serve como mecanismo para sua extensão. Além da complexidade do padrão, os modelos IFC tendem a ter tamanhos de arquivos bastante grandes.
A Figura 3  mostra o exemplo de um edifício com os modelos separados das especialidades de Arquitetura, Estrutura e Instalações e o modelo combinando as especialidades. Segundo os autores Jim Steel, Drogemuller e Toth (2012), a Figura 3 representa um piso de um edifício de 19 pavimentos, cujo modelo completo tem aproximadamente 120 megabytes de tamanho.

Figura 3: Images do projeto Mango Hill / North Lakes Police Station

IFC

Fonte: Extraído de Jim Steel, Drogemuller e Toth (2012)


Download do IFC4

Clique aqui para fazer o download do IFC4.html

Instruções de uso do arquivo:

O arquivo está no formato HTML. Ele está compactado. Crie uma pasta chamada IFC na sua área de trabalho. Copie e descomprima o arquivo para ela. Você terá uma vista parecida com a figura abaixo. Clique em “index”:

click

Ao clicar em “index” o seu navegador abrirá automaticamente e você verá a seguinte página:

home

Pronto! Comece a navegar para conhecer o conteúdo!

Referências

IFC2x4 release summary. Disponível em:< http://buildingsmart-tech.org/specifications/ifc-releases/ifc2x4-release >. Acesso em: 11 março 2012.

buildingSmart. Especificações técnicas. Disponível em:< http://www.buildingsmart-tech.org/specifications >. Acesso em: 3/12/2012.

EASTMAN, C ., et al. The BIM handbook. 1a. edição. Wiley&Sons, 2008, 504 p.

GENERAL SERVICES ADMINISTRATION. BIM Guides Serie 1. 2007, 49 p.

ISO PAS 16739: Industry Foundation Classes, Release 2x, Platform Specification (IFC2x Platform). 2005. 42 p.

INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO-10303-11: Industrial automation systems and integration – product data representation and exchange – Overview and fundamental principles. 1994. 20 p.

ISO 10303 21: Industrial automation systems and integration – product data representation and exchange – Implementation methods:Clear text encoding of the exchange structure. 2002. 25 p.

ISO 10303 28: Industrial automation systems and integration- product data representation and exchange- Implementation methods: Xml representations of express schemas and data, using xml schemas. 2007. 28 p.

ISO 10303 22: Industrial automation systems and integration – product data representation and exchange – Implementation methods: Standard data access interface. 1998. 19 p.

JIM STEEL; DROGEMULLER, R.; TOTH, B. Model interoperability in building information modelling. Software & Systems Modeling, v.11, n.1, p.99-109, 2012.

KHEMLANI, L. The IFC building model: a look under the hood. Disponível em:< http://www.aecbytes.com/feature/2004/IFCmodel.html >. Acesso em: 20/11/12.

MANZIONE, Leonardo. Proposição de uma estrutura conceitual de gestão do processo de projeto colaborativo com o uso do BIM. 2013. Tese (Doutorado em Engenharia de Construção Civil e Urbana) – Escola Politécnica, University of São Paulo, São Paulo, 2013. doi:10.11606/T.3.2013.tde-08072014-124306. Acesso em: 2016-09-10.

 

Termos de uso

Todos os materiais publicados neste site, incluindo texto e gráficos são de propriedade de MAKEBIM e Leonardo Manzione e são protegidos pelo Brasil e pelas e leis internacionais de copyright. Você não pode reproduzir, modificar, distribuir ou republicar os materiais contidos neste site (diretamente ou por meio da vinculação) sem nossa permissão prévia por escrito e citação da fonte através de um link para esse post. Você não pode alterar ou remover qualquer marca comercial, direitos autorais ou outro aviso de cópias do conteúdo. Você pode, no entanto, baixar material do site (cópia legível de uma máquina e uma cópia de impressão por página) para seu uso pessoal, não comercial. Reservamos todos os direitos e título para todo o material baixado assim.

Carregar mais artigos relacionados
Load More In Artigos
Comments are closed.

Leia também

O BIM Manager é realmente necessário?

Quais são as funções do BIM Manager? Os requisitos de implantação e gestão do BIM vêm dema…