O desenvolvimento de um modelo de dados de edifícios é 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 ISSO 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, ISSO 10303 11 (2004), na qual a linguagem IFC é definida; um mapeamento, ISSO 10303 21 (2002), para arquivos de texto que representam os modelos segundo o esquema de dados; um mapeamento, StepXML, ISSO 10303 28 (2007), para arquivos no formato Extensible Markup Language (XML ); e um mapeamento para Application Program Interface (API ), ISSO 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 ISSO 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 Release Candidate (RC4), 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 150 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.
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.
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 da linguagem IFC
A linguagem Ifc é muito extensa e complexa, conforme Jim Steel, Drogemuller e Toth (2012). A versão atual, 2×4 RC4, buildingSMART (2012d), 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 da linguagem é 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 da linguagem, os modelos IFC tendem a ter tamanhos de arquivos bastante grandes, o que irá fazer com que a troca entre especialidades exija um servidor de modelos, assunto a ser explicado nos próximos tópicos.
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 360 megabytes de tamanho.
*Leonardo Manzione é o fundador da Coordenar e mestre e doutorando em BIM pela Escola Politécnica da USP. Este artigo foi publicado originalmente no blog da Coordenar.