Sei sulla pagina 1di 155

O MODELO IFC COMO AGENTE DE

INTEROPERABILIDADE
Aplicao ao domnio das estruturas



SRGIO MIGUEL FERREIRA DE PINHO



Dissertao submetida para satisfao parcial dos requisitos do grau de
MESTRE EM ENGENHARIA CIVIL ESPECIALIZAO EM CONSTRUES


Orientador: Professor Doutor Joo Pedro da Silva Poas Martins


Co-Orientador: Professor Doutor Joo Filipe Meneses Espinheira Rio


Co-Orientador: Professor Doutor Miguel ngelo Carvalho Ferraz



JUNHO DE 2013
MESTRADO INTEGRADO EM ENGENHARIA CIVIL 2012/2013
DEPARTAMENTO DE ENGENHARIA CIVIL
Tel. +351-22-508 1901
Fax +351-22-508 1446
miec@fe.up.pt


Editado por
FACULDADE DE ENGENHARIA DA UNIVERSIDADE DO PORTO
Rua Dr. Roberto Frias
4200-465 PORTO
Portugal
Tel. +351-22-508 1400
Fax +351-22-508 1440
feup@fe.up.pt
http://www.fe.up.pt


Reprodues parciais deste documento sero autorizadas na condio que seja
mencionado o Autor e feita referncia a Mestrado Integrado em Engenharia Civil -
2012/2013 - Departamento de Engenharia Civil, Faculdade de Engenharia da Universidade
do Porto, Porto, Portugal, 2013.

As opinies e informaes includas neste documento representam unicamente o ponto de vista do
respetivo Autor, no podendo o Editor aceitar qualquer responsabilidade legal ou outra em relao a
erros ou omisses que possam existir.

Este documento foi produzido a partir de verso eletrnica fornecida pelo respetivo Autor.

O Modelo IFC como Agente de Interoperabilidade






















Aos meus Pais e Irmo,
minha namorada.










"Nobody said it was easy, no one ever said it would be this hard."
- Chris Martin, The Scientist, 2002





O Modelo IFC como Agente de Interoperabilidade



i

AGRADECIMENTOS
Para a realizao da presente dissertao contei com o apoio directo e indirecto de inmeras pessoas s
quais devo muito. Quero deixar expressos os meus agradecimentos, ainda que correndo o risco de
injustamente no mencionar algum, quero deixar claro que recordo sem excepo todos aqueles que
contriburam para que eu pudesse dar mais um passo nesta caminhada.
Agradeo ao meu orientador Doutor Professor Joo Pedro Poas Martins pela orientao prestada mas
sobretudo pelo entusiasmo e interesse contagiante pelas matrias estudadas e pela liberdade e
confiana que me foi depositada na realizao deste trabalho. A sua atitude exemplar, domnio de
conhecimentos e profissionalismo unidos sua boa disposio so para mim um modelo a seguir.
Ao meu co-orientador Doutor Professor Joo Filipe Meneses Espinheira Rio, pela sua disponibilidade
constante, pelo seu incentivo e igualmente pelo seu apoio e ajuda na elaborao deste trabalho. A sua
indiscutvel amizade, boa disposio e compreenso em momentos de consternao permitiram
sempre fazer ressurgir em mim toda a motivao e autoconfiana necessria para ir um pouco mais
alm.
Agradeo tambm ao Doutor Professor Miguel ngelo Carvalho Ferraz pelo acompanhamento
prestado, pelas demonstraes mais tcnicas, e pela disponibilidade e ajuda na construo do rumo que
a dissertao tomou. As inmeras conversas permitiram-me limar arestas e perceber quais as melhores
direces a seguir.
Quero aproveitar a ocasio para agradecer a toda a minha famlia pelo apoio incondicional, em
particular aos meus pais, Srgio Pinho e Jacinta Pinho, e irmo, Adrito Pinho, no s pelo apoio que
sempre me deram ao longo deste curso de Engenharia Civil, mas tambm por todo o carinho e afecto
que estiveram sempre presente durante toda a minha vida. Os seus testemunhos de vida foram para
mim verdadeira fonte de motivao, aos quais respondi na medida do possvel, com esforo e
dedicao.
minha namorada, Ana Catarina Azevedo, por ter caminhado a meu lado durante todo este percurso
universitrio, pela sua pacincia e compreenso durante a elaborao da presente dissertao, a quem
peo desculpa pelos dias sacrificados em prol da realizao deste trabalho. Agradeo o seu amor e
amizade e as suas palavras de motivao e confiana.
Deixo tambm uma palavra de apreo aos meus amigos de infncia com os quais passei momentos
nicos, sou obrigado a nomear os meus melhores amigos, Jos Nunes (Kiki) e Ricardo Pinheiro
(Costa), para quem envio um agradecimento em especial.
Enfim, quero demonstrar o meu agradecimento, a todos aqueles que, de um modo ou de outro me
acompanharam durante a fase do curso e tornaram possvel a realizao deste trabalho.

A todos o meu sincero e profundo muito obrigado.


O Modelo IFC como Agente de Interoperabilidade



iii

RESUMO
A filosofia envolta no conceito BIM (Building Information Modeling) possibilita a juno de
diferentes mbitos do projecto num nico modelo virtual, o que traz uma crescente necessidade de
constante troca de informao entre os intervenientes nos projectos de edifcios. Maiores nveis de
interoperabilidade significam maiores nveis de envolvimento entre os participantes na elaborao de
um projecto de engenharia civil e por isso permite um maior acompanhamento do fluxo de trabalho,
maior automatizao de processos e maior controlo de erros e falhas imputveis no s aquando da
realizao do projecto mas tambm ao longo do ciclo de vida da obra. Assim, a aplicao de
metodologias BIM permite um aumento significativo da velocidade dos processos de projecto e
construo.
O standard IFC enquanto agente de interoperabilidade j implementado h mais de uma dcada e
meia. Presentemente exponnciada pelo surgimento do novo esquema IFC4 suportado por
normalizao ISO, o que representa um grande avano da especificao IFC.
Atendendo a isto, o objectivo deste estudo passa por comear a investigar entidades IFC que permitam
a definio estrutural de elementos pela sua definio analtica, funo que agora suportada pelo
IFC4. Com a grande celeridade dos avanos tecnolgicos torna-se necessrio estar sempre um passo
frente em tudo o que diz respeito a sistemas informticos. Portanto, no domnio IFC, a presente
dissertao incidiu especialmente sobre elementos simples de estruturas de beto (pilares, prticos,
estruturas porticadas) cuja multiplicao permite a composio de estruturas de edifcios regulares.
Para alm da identificao das classes necessrias para a definio dos elementos estruturais que
compem uma edificao regular, fez-se tambm um estudo dos nveis de interoperabilidade actuais
para a transferncia desses dados e demonstra-se uma possibilidade de aplicao futura do modelo
IFC. Essa aplicao prtica das classes IFC demonstra o grande potencial da especificao, na troca de
informaes entre os programas de modelao e os programas de clculo e anlise estrutural. Para
alm de constituir um agente de interoperabilidade, pode tambm ser encarado como uma ferramenta
BIM deste ponto de vista. Contudo tem sido alvo de criticas por parte de diversos autores no que toca
sua aplicabilidade no domnio das estruturas.

PALAVRAS-CHAVE: BIM, IFC, Interoperabilidade, Gesto de informao, Estruturas.

O Modelo IFC como Agente de Interoperabilidade



v

ABSTRACT
The philosophy around the BIM (Building Information Modeling) concept enables the joining of
different project scopes in a single virtual model, which brings a growing need for constant
information exchange between stakeholders in construction projects. A higher level of interoperability
means higher levels of engagement among participants in the building project and therefore allows
greater monitoring workflow, greater automation of processes and greater control of errors and failures
throughout the life-cycle of the building. Thus, the implementation of BIM enables a significant
increase of speed in project and building processes.
The IFC standard as an interoperability agent has been now implemented for over one and a half. This
additional pressure now comes with the realization of the new IFC4 scheme as an ISO standardization,
which represents a major breakthrough of the IFC specification.
Hereby, the aim of this study subject begin by investigate IFC entities that allow the structural
definition of building elements defining their analytical functions, which is now supported by IFC4.
The fast technological advances require us to be always one step ahead in all that concerns
informatical sistems. Therefore, in the IFC field, this thesis focused especially on simple concrete
structural elements (like footings, columns, beams and slabs) whose multiplication allows the
composition of regular building structures. Beyond identifying the classes needed to define the
structural elements that make up a regular building, was also made a study of the current levels of
interoperability for the transfer of such data and it is also shown a possibility of future application of
the IFC model. This practical application of IFC classes demonstrates the great potential within the
IFC specification, in what concerns the exchange of information between modeling programs and
programs for calculation and structural analysis, in addition to being an agent for interoperability can
also be seen as a BIM tool by this point of view, however, has been the target of criticism by various
authors in regard to its applicability in the field of structures

KEYWORDS: BIM, IFC, Interoperability, Information management, Structures.

O Modelo IFC como Agente de Interoperabilidade



vii

NDICE GERAL

AGRADECIMENTOS ................................................................................................................................ i
RESUMO ................................................................................................................................................. iii
ABSTRACT .............................................................................................................................................. v
NDICE DE FIGURAS ............................................................................................................................. xi
NDICE DE QUADROS .......................................................................................................................... xv
TERMOS E DEFINIES .................................................................................................................... xvii
ABREVIATURAS E SIMBOLOS ........................................................................................................... xix

1 INTRODUO ............................................................................................................. 1
1.1. CONSIDERAES INICIAIS ................................................................................................................... 1
1.2. MBITO E OBJECTIVOS ....................................................................................................................... 2
1.3. ORGANIZAO DA DISSERTAO ........................................................................................................ 3

2 ESTADO DA ARTE ................................................................................................. 5
2.1. GESTO DA INFORMAO ................................................................................................................... 5
2.1.1. ASPECTOS GERAIS .......................................................................................................................... 5
2.1.2. DOCUMENTAO DE PROJECTO ........................................................................................................ 5
2.1.3. GESTO DE PROJECTO (PROJECT MANAGEMENT) ............................................................................. 6
2.2. BIM BUILDING INFORMATION MODELING ........................................................................................... 8
2.2.1. CONCEITO ....................................................................................................................................... 8
2.2.2. VANTAGENS E DESVANTAGENS ....................................................................................................... 11
2.2.3. FERRAMENTAS BIM ....................................................................................................................... 13
2.3. INTEROPERABILIDADE ....................................................................................................................... 14
2.4. IFC INDUSTRY FOUNDATION CLASSES ............................................................................................ 17
2.4.1. CONTEXTO HISTRICO ................................................................................................................... 17
2.4.2. CONCEITO ..................................................................................................................................... 17
2.4.3. NORMAS ........................................................................................................................................ 18
2.4.4. ESTRUTURA DO IFC ....................................................................................................................... 20
2.4.5. O IFC NA INDSTRIA AEC .............................................................................................................. 24


O Modelo IFC como Agente de Interoperabilidade



viii

3 ESTUDO EMPIRICO DE INTEROPERABILIDADE ................ 25
3.1. INTRODUO .................................................................................................................................... 25
3.2. APLICAO REALIDADE DE 2013.................................................................................................... 25
3.3. DEFINIO DA ESTRATGIA DE AVALIAO ....................................................................................... 26
3.4. FUNCIONAMENTO INTERNO DOS SOFTWARES NO DOMNIO DA INTEROPERABILIDADE ............................ 28
3.4.1. REVIT ............................................................................................................................................ 30
3.4.2. ROBOT .......................................................................................................................................... 34
3.4.3. ARCHICAD...................................................................................................................................... 35
3.4.4. TRICALC ........................................................................................................................................ 36
3.4.5. NIST IFC FILE ANALYSER .............................................................................................................. 36
3.5. TESTES DE INTEROPERABILIDADE ...................................................................................................... 37
3.5.1. CASO A REVIT ARCHITECTURE PARA ROBOT ................................................................................ 37
3.5.2. CASO B REVIT STRUCTURES PARA ROBOT ................................................................................... 39
3.5.3. CASO C ROBOT PARA REVIT ARCHITECTURE ................................................................................ 41
3.5.4. CASO D ROBOT PARA REVIT STRUCTURES ................................................................................... 42
3.5.5. CASO E REVIT STRUCTURES PARA REVIT STRUCTURES ................................................................ 42
3.5.6. CASO F ARCHICAD PARA TRICALC ................................................................................................ 43
3.5.7. CASO G TRICALC PARA ARCHICAD/REVIT/ROBOT ......................................................................... 44
3.5.8. CASO H TRICALC PARA TRICALC .................................................................................................. 44
3.5.9. CASO I IFC4 PARA REVIT/ROBOT/ARCHICAD/TRICALC .................................................................. 44
3.6. QUADRO RESUMO ............................................................................................................................. 45

4 MODELAO EM IFC (CASO DE ESTUDO) .............................. 47
4.1. DESCRIO SEMNTICA .................................................................................................................... 47
4.1.1. OBJECTIVOS .................................................................................................................................. 47
4.1.2. PERSPECTIVAS FUTURAS ............................................................................................................... 48
4.1.3. IMPLEMENTAO DO IFC4 .............................................................................................................. 48
4.2. CASO DE APLICAO ........................................................................................................................ 50
4.2.1. PROPOSTA..................................................................................................................................... 50
4.2.2. ELABORAO DO MODELO IFC ....................................................................................................... 51
4.3. ESTRUTURA INTERNA DE FICHEIROS IFC ........................................................................................... 53
4.3.1. CONCEITOS BASE .......................................................................................................................... 53
4.3.2. SIMBOLOGIA USADA ....................................................................................................................... 57
O Modelo IFC como Agente de Interoperabilidade



ix

4.3.3. ANLISE E EXPOSIO DA CRIAO DE UM FICHEIRO IFC ................................................................ 58
4.4. CONSIDERAES COMPLEMENTARES ................................................................................................ 78

5 PROPOSTA DE IMPLEMENTAO DE CLASSES IFC
NA CRIAO DE SOFTWARES ......................................................................... 79
5.1. ENUNCIADO DO PROBLEMA E OBJECTIVOS ........................................................................................ 79
5.2. ESTRATGIA DE ABORDAGEM ........................................................................................................... 80
5.2.1. DETALHAR ..................................................................................................................................... 81
5.2.2. AGRUPAR ...................................................................................................................................... 82
5.2.3. DUPLICAR ...................................................................................................................................... 83
5.3. PROPOSTAS DE IMPLEMENTAO ...................................................................................................... 84
5.3.1. EXPANSO DA APLICAO EVOLUTION BIM PAVILION ................................................................... 84
5.3.2. DESENVOLVIMENTO DE APLICAO PARA A RESTITUIO DE DADOS AO FICHEIRO IFC ..................... 86
5.4. DESENVOLVIMENTOS FUTUROS ......................................................................................................... 89

6 CONCLUSES .......................................................................................................... 91
6.1. DISCUSSO ...................................................................................................................................... 91
6.2. PRINCIPAIS DIFICULDADES ................................................................................................................ 92
6.3. CONSIDERAES FINAIS ................................................................................................................... 93

REFERNCIAS ..................................................................................................................................... 97


O Modelo IFC como Agente de Interoperabilidade



xi

NDICE DE FIGURAS
Figura 1.1 Modelo BIM com a incluso de vrias disciplinas. Adoptado de (Autodesk 2013). ........... 2
Figura 2.1 Os mbitos dos BIM e suas inter-relaes. Adoptado de SCIA Scientific Software. ......... 6
Figura 2.2 O BIM no ciclo de vida de um edifcio. (Autodesk 2013) .................................................... 9
Figura 2.3 Exemplo de modelao de estrutura 3D a partir uma base CAD ..................................... 10
Figura 2.4 Extraco de informao diversa do modelo 3D (Graphisoft 2013) ................................. 12
Figura 2.5 Correspondncia entre o modelo BIM e a situao real (Lillja 2012). .............................. 13
Figura 2.6 Fragmentao do processo construtivo e suas consequncias. (Hiplito Sousa 2006). . 15
Figura 2.7 Cronologia do padro IFC. (Liebich 2013) ........................................................................ 17
Figura 2.8 Diagrama com as normas implementadas pela BuildingSMART. (BuildingSMART 2013).
............................................................................................................................................................... 19
Figura 2.9 Funcionamento do conceito de camadas na arquitectura do IFC. Adoptado de (IAI 1999).
............................................................................................................................................................... 21
Figura 2.10 Estrutura da base de dados da especificao IFC4. Adaptado de (BuildingSMART
2013). .................................................................................................................................................... 23
Figura 2.11 O formato IFC enquanto agente activo de interoperabilidade no openBIM ................... 24
Figura 3.1 O formato IFC como mtodo genrico para transferia de dados entre dois aplicativos
BIM. ....................................................................................................................................................... 27
Figura 3.2 Diagrama de procedimento para realizao de testes de interoperabilidade .................. 28
Figura 3.3 Ficheiro IFC exportado pelo Revit e visualizado com o Solibri Model Viewer.................. 29
Figura 3.4 Ficheiro IFC exportado pelo Revit e importado pelo Archicad. ........................................ 29
Figura 3.5 Definies das condies de fronteira antes da introduo das famlias respectivas. .... 30
Figura 3.6 Definies das condies de fronteira depois da introduo das famlias respectivas. ... 30
Figura 3.7 Janela do Revit para a integrao de modelos do Revit no Robot e vice-versa. ............. 31
Figura 3.8 Opes de exportao de modelos do Revit para o Robot de forma directa. .................. 32
Figura 3.9 Tabela de correspondncia entre as categorias do Revit e as classes IFC sustentada
pelo ficheiro exportlayers-ifc-IAI.txt. ...................................................................................................... 33
Figura 3.10 Tabela de correspondncia entre as classes IFC e as categorias do Revit e sustentada
pelo ficheiro exportlayers-dwg-ISO13567.txt. ....................................................................................... 34
Figura 3.11 Opes de importao de modelos do Robot para o Revit de forma directa. ................ 35
Figura 3.12 Lista de classes IFC exportadas pelo Archicad .............................................................. 35
Figura 3.13 Exemplo de PropertySets aplicveis no Archicad. ......................................................... 36
Figura 3.14 Janela de aviso apresentada pelo Revit Architecture. .................................................... 38
Figura 3.15 Desconexo entre apoio, pilar e laje............................................................................... 38
Figura 3.16 Janela de verificao apresentada pelo Revit Architecture. ........................................... 40
O Modelo IFC como Agente de Interoperabilidade



xii

Figura 3.17 Ligao entre elementos. ................................................................................................ 40
Figura 3.18 Exemplo de pilares unidos estruturalmente ao eixo analtico da viga atravs de Rigid
Links (representados a verde). (Autodesk 2013) .................................................................................. 41
Figura 3.19 Opes de traduo do modelo IFC usando o Archicad. ............................................... 43
Figura 3.20 Ferramenta de ajuste de ns dos modelos importados para o Tricalc via IFC. ............. 44
Figura 4.1 Sequncia de palavras-chave relacionadas com o IFC .................................................... 49
Figura 4.2 Dimenses de implantao da estrutura porticada. .......................................................... 50
Figura 4.3 Visualizao do modelo IFC analtico atravs do Constructivity Model Viewer ............... 52
Figura 4.4 Visualizao do modelo IFC analtico atravs do Solibri Model Viewer ........................... 52
Figura 4.5 Estrutura tipo de um ficheiro STEP (Nour 2008)............................................................... 53
Figura 4.6 Organizao de uma entidade. Adaptado (Nour 2008) ........................................................... 55
Figura 4.7 Exemplo de uma entidade. ................................................................................................ 55
Figura 4.8 Codificao base de 64 caracteres para a formulao de um IFC-GUID. (BuildingSMART
2013) ...................................................................................................................................................... 56
Figura 4.9 Correspondncia entre o GUID no ficheiro IFC e no visualizador Solibri ......................... 56
Figura 4.10 Modelo IFC - Seco HEADER do modelo IFC criado. .................................................. 59
Figura 4.11 Aplicao - Seco HEADER do modelo IFC criado. ..................................................... 59
Figura 4.12 Modelo IFC - Dados do usurio, da organizao e da aplicao ................................... 59
Figura 4.13 Aplicao - Dados do usurio, da organizao e da aplicao ...................................... 60
Figura 4.14 Modelo IFC Pontos cartesianos e direces. ............................................................... 61
Figura 4.15 Aplicao - Pontos cartesianos e direces. .................................................................. 61
Figura 4.16 Modelo IFC - Unidades ................................................................................................... 62
Figura 4.17 Aplicao - Unidades ...................................................................................................... 62
Figura 4.18 Exemplo Converso de unidades. ............................................................................... 63
Figura 4.19 Exemplo Unidade derivada .......................................................................................... 63
Figura 4.20 Modelo IFC O projecto ................................................................................................. 64
Figura 4.21 Aplicao O projecto .................................................................................................... 64
Figura 4.22 Modelo IFC O projecto ................................................................................................. 64
Figura 4.23 Aplicao O projecto .................................................................................................... 65
Figura 4.24 Composio do Edifcio (BuildingSMART 2013)............................................................. 66
Figura 4.25 Modelo IFC Representao Geomtrica ...................................................................... 67
Figura 4.26 Aplicao Representao Geomtrica ......................................................................... 67
Figura 4.27 Modelo IFC Ns de ligao do Pilar 1 .......................................................................... 68
Figura 4.28 Aplicao Ns de ligao do Pilar 1 ............................................................................. 68
O Modelo IFC como Agente de Interoperabilidade



xiii

Figura 4.29 Modelo IFC Membro estrutural do Pilar 1 .................................................................... 69
Figura 4.30 Modelo IFC Membro estrutural da Viga 1 .................................................................... 69
Figura 4.31 Aplicao Membro estrutural do Pilar 1 e/ou Viga 1 .................................................... 69
Figura 4.32 Modelo IFC Membro estrutural da Laje 1 .................................................................... 70
Figura 4.33 Aplicao Membro estrutural da Laje 1 ....................................................................... 70
Figura 4.34 Modelo IFC Atribuio dos ns e membros estruturais ao modelo de anlise
estrutural ................................................................................................................................................ 70
Figura 4.35 Aplicao Atribuio dos ns e membros estruturais ao modelo de anlise estrutural
............................................................................................................................................................... 71
Figura 4.36 Modelo IFC Definio da arquitectura dos pilares e algumas definies .................... 72
Figura 4.37 Aplicao Definio da arquitectura dos pilares e algumas definies ....................... 72
Figura 4.38 Relao para a conteno espacial de elementos (BuildingSMART 2013) ................... 73
Figura 4.39 Modelo IFC Propriedades atribudas ao Pilar 1 ........................................................... 74
Figura 4.40 Aplicao Propriedades atribudas ao Pilar 1 .............................................................. 75
Figura 4.41 Modelo IFC Modelo de Anlise Estrutural ................................................................... 75
Figura 4.42 Aplicao Modelo de Anlise Estrutural ...................................................................... 75
Figura 4.43 Modelo IFC Cargas estruturais .................................................................................... 77
Figura 4.44 Aplicao Cargas estruturais ....................................................................................... 77
Figura 5.1 Processo para a definio de elementos compostos. ...................................................... 80
Figura 5.2 Decomposio de um pilar em classes IFC. .................................................................... 81
Figura 5.3 Relaes de atribuio inversa a um pilar. Adaptado de (BuildingSMART 2013). .......... 83
Figura 5.4 Exemplo da partilha de uma seco por duas sapatas. ................................................... 83
Figura 5.5 Aplicao Evolution BIM Pavilion. ..................................................................................... 84
Figura 5.6 Pavilho originado pela aplicao Evolution BIM Pavilion. .............................................. 85
Figura 5.7 Aplicao Evolution BIM Buildings .................................................................................... 84
Figura 5.8 Estrutura originada pela aplicao Evolution BIM Buildings. ........................................... 85
Figura 5.9 Processo de transferncia de informao entre duas aplicaes usando o modelo IFC e
uma aplicao de suporte. .................................................................................................................... 87
Figura 5.10 Fluxograma de acrscimo de valor ao ficheiro IFC exportado pela adio de
informaes. .......................................................................................................................................... 88
Figura 5.11 Relao entre trs vertentes BIM (BuildingSMART 2013) ............................................. 89
Figura 6.1 Diagrama de maturidade BIM (Bew and Richards 2008). ................................................ 93



O Modelo IFC como Agente de Interoperabilidade



xv

NDICE DE QUADROS
Quadro 1 Interoperabilidade entre diferentes softwares .................................................................... 46




O Modelo IFC como Agente de Interoperabilidade



xvii

TERMOS E DEFINIES
Atributo Unidade de informao dentro da entidade, definido por um tipo particular ou referenciado
a uma entidade particular. Existem trs espcies de atributos, os directos, os inversos e os derivados.

Atributo directo Varivel indexada na seco das definies de atributos de uma entidade.
Semelhante ao termo campo em linguagem de programao comum.

Atributo inverso Unidade de informao na seco de atributos de uma entidade que se define
fazendo o relacionamento com uma entidade externa. Essa relao feita colocando o identificador
nico dessa entidade externa (#nnnnnnnnn) num campo de atributo apropriado da entidade em causa.

Atributo derivado Unidade de informao calculada a partir de outros atributos, usando expresses
definidas no esquema. So definidos fora do ficheiro IFC e representados por um asterisco (*).

Classe Abstracta Supertipo (Abstract Supertype) Classe abstracta que regula um subconjunto de
entidades que lhe esto indexadas, cujas definies so vocacionadas para uma determinada rea.

Classe Supertipo (Supertype) Classe que regula um subconjunto de entidades que lhe esto
indexadas, cujas definies so vocacionadas para uma determinada rea.

Classe Subtipo (Subtype) Classe que faz parte de um subconjunto de entidades, administrada por
uma classe supertipo.

Controlo Aplica os conceitos de verificao, reviso e restrio. Pode ser visto como um guia que de
implementao que pretende regulamentar e especificar uma exigncia que deve ser aplicada a um
objecto.

Entidade (ou classe) Classe de informao definida por atributos e restries.

Grupo Coleco arbitrria de objectos.

Instncia Ocorrncia de uma entidade.

Intervenientes Agentes humanos que esto envolvidos em parte ou na totalidade de um ciclo de vida
de um projecto.

O Modelo IFC como Agente de Interoperabilidade



xviii

Processo Aco que ocorre num projecto e que tem o intuito de adquirir, construir ou manter
objectos. Um processo enquadra-se numa sequncia temporria.

Produto um objecto fsico, fabricado, fornecido ou criado para incorporar o projecto. Pode ser
definido atravs de uma representao geomtrica e ter uma dada localizao no espao.

Recursos Conceitos que descrevem a utilizao de um objecto, essencialmente dentro de um
processo.

String Sequncia ordenada de caracteres (smbolos) escolhidos a partir de um conjunto pr-
determinado.

Template Modelo sem contedos mas com definies pr-definidas e instrues sobre onde e qual o
tipo de contedo a incluir no ficheiro.

O Modelo IFC como Agente de Interoperabilidade



xix

ABREVIATURAS E SIMBOLOS
ABREVIATURAS
AEC Arquitectura, Engenharia e Construo
ASCII American Standard Code for Information Interchange
AVAC Aquecimento, Ventilao e Ar Condicionado
BIM Building Information Modeling
BREP Boundary REPresentation
CAD Computer-Aided Design
CAM Computer-Aided Machining
CIS/2 CIMsteel Integration Standards
CSG Constructive Solid Geometry
GUID Globally Unique IDentifier
HTML Hyper Text Markup Language
IAI International Alliance for Interoperability
IDM Information Delivery Manuals
IFC Industry Foundation Classes
IFD International Framework for Dictionaries
ISO - International Standardization Organization
MEP Mechanical, Electrical, Plumbing
MSG Model Support Group
MVD Model View Definitions
REBAP Regulamento de Estruturas de Beto Armado e Pr-esforado
RSA Regulamento de Segurana e Aces
SEM Semantic Exchange Modules
STEP STandard for the Exchange of Product data
XML eXtensible Markup Language

SMBOLOS
Coeficiente de dilatao linear
E Youngs Modulus
Poisons Ratio
G Shear Modulus
Density
Dumping Ratio
O Modelo IFC como Agente de Interoperabilidade



1





1
1 INTRODUO


1.1. CONSIDERAES INICIAIS
Ao longo da histria, sabemos pelos monumentos megalticos, templos faranicos e pelos grandes
imprios que a construo milenar era j vista como um sinal de evoluo, que foi escrevendo a
histria da presena humana ao longo dos sculos. Com a revoluo industrial e o fascnio do homem
pelos inovadores sistemas mecnicos, esta viso sobre a construo foi-se deteriorando e foi ainda
mais agravada com o surgimento da era tecnolgica que agora vivemos. Definitivamente a construo
tinha passado para um segundo plano, os seus processos de execuo e tecnologias mantiveram-se
quase que inalterados ao longo das ltimas dcadas, chegando mesmo a ser considerada como uma
indstria de processos rudimentares onde predominava a mo-de-obra pouco qualificada.
Os tempos que correm so j vistos como um ponto de viragem. A indstria da construo apercebeu-
se que por si s j no era auto-sustentvel em termos de inovao e por isso comeou a procurar
meios impulsionadores que permitissem de certa forma a recuperao do tempo perdido. Aliando-se s
ferramentas e sistemas mecnicos e aos dispositivos e inovaes tecnolgicos, a indstria da
construo encontrou os meios necessrios para aprimorar as suas solues construtivas, facilitar o
processo de construo, aperfeioar o desempenho dos edifcios e melhorar significativamente os
nveis de qualidade de vida do Homem. Estava ento estabelecida uma relao de mtuo benefcio
pela interligao das vrias indstrias.
O conceito de Building Information Modeling (BIM) surge ento como um dos avanos mais
promissores na indstria de Arquitectura, Engenharia e Construo (AEC). Este conceito parte de uma
filosofia associada Lean Construction que se baseia na minimizao de gastos suprfluos atravs
da maximizao do aproveitamento de recursos. Melhor traduzindo, o conceito BIM fornece uma srie
de ferramentas que possibilitam a diminuio de tempo e custos de projecto pela globalizao de um
modelo virtual tridimensional partilhado, melhorando assim a relao de comunicao entre os
intervenientes e envolvendo-os mais activamente no projecto reduzindo os tempos de produo. Esse
modelo poder ser usado ao longo do ciclo de vida do edifcio, permitindo um maior controlo em
todas as fases de construo contribuindo tambm para a reduo de tempos de execuo, custos de
no qualidade e deteco de no conformidades, promovendo um maior aproveitamento dos recursos
j que o planeamento de tarefas facilitado.
Atravs das diversas fases do ciclo de vida de um empreendimento muitas so as ferramentas
utilizadas e intervenientes envolvidos. A globalizao do modelo virtual BIM e a sua partilha entre os
diversos intervenientes, garantida pela interoperabilidade entre sistemas que permite a troca de dados
e informaes. O IFC (Industry Foundation Classes) o principal formato de troca de dados
O Modelo IFC como Agente de Interoperabilidade



2

responsvel pela interoperabilidade entre os diferentes sistemas BIM. Permite o reaproveitamento de
modelos j criados evitando a repetio do trabalho de modelao do edifcio sempre que se muda de
disciplina do projecto, trazendo ainda o benefcio de aproximar todos os intervenientes em fase de
projecto. Esta aproximao em detrimento da individualizao dos processos de trabalho estabelece
uma relao colaborativa que trs grande benefcio e acrscimo de valor ao projecto (Figura 1.1).
Figura 1.1 Modelo BIM com a incluso de vrias disciplinas. Adoptado de (Autodesk 2013).

1.2. MBITO E OBJECTIVOS
O presente trabalho foi elaborado no mbito da disciplina Dissertao em Construes no ramo de
especializao de Construes do curso de Mestrado Integrado em Engenharia Civil da FEUP.
Apesar de constituir uma preciosa ajuda na transmisso de dados entre diferentes softwares que de
outra forma no seria possvel, de conhecimento geral que o IFC est ainda longe de ter uma
operabilidade perfeita. Desde a sua criao que vm sido feitos grandes esforos para que a
especificao IFC se consiga impor e entranhar num mercado moldado pelas grandes empresas lder.
Enquanto formato aberto e com uma filosofia openBIM, o IFC apenas se pode limitar a procurar a
aceitao por parte dos distribuidores de software, a quem compete libertar as funcionalidades de
modo a que possam ser passveis de utilizao pelo modelo IFC. Esta problemtica conduziu a um
primeiro objectivo que consiste em identificar os principais problemas de interoperabilidade e
limitaes que o formato IFC apresenta na troca de informaes pela realizao de testes de
interoperabilidade, aqui com especial nfase para a vertente dos elementos estruturais. As concluses
extradas serviro principalmente como alerta para as dificuldades na realizao de trocas entre
programas vocacionados para a modelao e programas vocacionados para a anlise estrutural, dando
tambm a conhecer um pouco do modo de funcionamento desses programas que sero avaliados.
Esses testes de interoperabilidade usando ficheiros IFC alertaram para um facto, a dificuldade que h
em compreender o prprio esquema IFC uma barreira que se ope interoperabilidade. Tendo isto
em conta pretendeu-se colmatar algumas lacunas existentes, como a falta de guias para iniciados no
estudo do IFC e a falta de exposio de casos prticos. Portanto, outro dos objectivos desta dissertao
foi a compilao de um conjunto de informaes sobre BIM e sobre o funcionamento da linguagem
IFC que facilitasse o primeiro contacto com estas matrias, visto serem assuntos ainda pouco
enraizados no s na comunidade de estudantes mas mesmo at na comunidade de profissionais de
engenharia e outras reas. Houve ento uma preocupao adicional em fazer-se uma abordagem a
esses assuntos vocacionada especialmente para quem inicia o estudo nestas reas pela primeira vez.
O Modelo IFC como Agente de Interoperabilidade



3

Este objectivo da exposio do funcionamento da linguagem IFC traz consigo outro propsito.
Sabendo-se que h um interesse crescente em mecanizar determinados processos para facilitar
actividades, surge o objectivo de pesquisa de conhecimentos adicionais para integrar essa exposio,
que depois podero ser utilizados para o desenvolvimento de ferramentas de gerao de dados. De
facto, se abstrados alguns processos do contexto em que se inserem, damos conta que no
representam propriamente actos de engenharia, mas apenas actos repetitivos cuja execuo
necessria mas que poderia ser feita por um outro individuo com menos qualificaes ou at de forma
automtica. Foi neste domnio que se procurou implementar os objectos estudados, para que de
alguma forma se conseguisse diminuir trabalhos de modelao com caracter mais repetitivo,
mostrando tambm assim a aplicabilidade da especificao IFC enquanto ferramenta que proporciona
a mecanizao de processos, atravs da criao de uma ferramenta informtica que possibilite a
modelao de estruturas porticadas pela introduo de informaes genricas (como por exemplo o
nmero de prticos e distncia entre eles, nmero de pisos, seces, materiais, cargas aplicadas, etc.).

Interoperability will become more of an issue as we continue to push for the use of new technology,
whether it be BIM or any other technology that gets us closer to an integrated project delivery system.
Our goal is to be able to develop within the project [build] team an attitude that improves the process
by having teams that are fully integrated and cooperative with each other. You need to be able to take
advantage of technology that allows the free flow of information from the submittal stage to the
operations and maintenance phase. We see interoperability as a challenge to achieving that.
Ricardo Aparicio, Manager, General Electric President, Construction Users Roundtable

1.3. ORGANIZAO DA DISSERTAO
No incio da presente dissertao, ainda com os objectivos finais pouco definidos, o ttulo O Modelo
IFC como Agente de Interoperabilidade Aplicao ao domnio das estruturas sugeria numa
primeira fase a investigao e identificao de problemas no uso do IFC na interoperabilidade entre
programas e numa segunda fase a elaborao de propostas de aplicao com uma vertente voltada para
o domnio das estruturas. Estando este caminho delineado, tornava-se necessrio aprofundar o
conhecimento, no domnio dos BIM e do IFC. nesse sentido que surge o Captulo 2 Estado da
Arte, provm da necessidade de reunir uma srie de informao que possibilite reter os
conhecimentos necessrios para o estudo aprofundado destas matrias.
Com esses conhecimentos de base torna-se possvel a compreenso do modo de funcionamento do
modelo IFC e da sua estrutura de troca e surgem as primeiras impresses acerca da interoperabilidade
desse modelo entre os diversos programas de software, resultando no Captulo 3 Estudo Emprico
de Interoperabilidade que contempla casos de estudo especficos de transferncia de informao
entre programas, quer de forma indirecta usando o IFC como intermedirio para permitir essa troca de
informao, quer por via directa se possvel. Com este Captulo 3, fez-se a identificao e classificao
da performance geral do IFC enquanto agente de interoperabilidade, o que responde primeira fase
sugerida pelo ttulo da dissertao. Para alm disso, o Captulo 3 veio alterar o modo de encarar a
problemtica da questo, neste momento a investigao e preocupao principal j no eram os
problemas ligados interoperabilidade propriamente dita, pois percebeu-se que o maior problema
residia na origem, na prpria implementao do modelo IFC. Uma correcta implementao do IFC
depende em muito da aceitao desse modelo por parte dos principais desenvolvedores de software na
indstria AEC (Arquitectura, Engenharia e Construo), mas no basta que haja uma aceitao formal,
preciso que esses programas criados sejam capazes de suportar o modelo IFC na sua totalidade. Para
O Modelo IFC como Agente de Interoperabilidade



4

isso necessrio que os distribuidores destes softwares estejam dispostos a liberar a informao que
gerada pelos seus sistemas informticos para a estrutura de troca do IFC, para que possa ser usada por
outros programas que podem ou no pertencer ao mesmo distribuidor. Colocando o cerne da questo
nestes termos, compreende-se a dificuldade e inrcia que existe em implementar esta filosofia do IFC,
mas nesse sentido que vo todos os esforos feitos pela buildingSMART. Este o verdadeiro
objectivo do formato IFC, ser um formato aberto, um verdadeiro openBIM, que tenta por isso fazer a
ligao entre todos os programas BIM, no demonstrando especial empatia por nenhum programa
especfico.
Foi visto que na actual situao, tanto a exportao como a importao de entidades entre programas
sofria uma espcie de triagem e seleco da informao, j que se verificou que na generalidade a
nica informao que circulava entre os programas era apenas informao geomtrica. A constatao
deste problema conduziu segunda fase da dissertao, que consistia na elaborao de propostas de
aplicao com uma vertente voltada para o domnio das estruturas, de uma perspectiva que procurasse
explorar as entidades que definissem os elementos da construo, mas desta feita indo mais alm do
que a definio arquitectnica, aprofundando a definio de forma estrutural. Para esta especial
vertente estrutural o esquema IFC2x3 revelou-se insuficiente para uma completa definio dos
elementos pretendidos e como o timing do incio da dissertao coincidiu com o da realizao do
novo esquema IFC4 que contempla uma rea de entidades mais abrangente, tomou-se este esquema
como o esquema que daria a base ao estudo das entidades, exposto no Captulo 4 Modelao em
IFC (Caso de Estudo) . Este captulo constitui um guia para aqueles que pretendem iniciar o estudo
na rea das classes IFC, dando indicaes do modo de funcionamento do cdigo e linguagem usados
pelo IFC, sempre com a preocupao em fazer a exposio da informao de um modo que facilite a
compreenso e apreenso dos principais conceitos.
O Captulo 4 serve tambm de elo de ligao entre a problemtica levantada no Captulo 3 e a
aplicao prtica demonstrada no Captulo 5 Proposta de Implementao de Classes IFC na
Criao de Softwares. O captulo 5 representa o culminar de todo o conhecimento apreendido na
realizao da dissertao, sugerindo aplicaes de software que contribuiro para um aumento dos
nveis de interoperabilidade. Pretende-se que o desenvolvimento dessas ferramentas seja feito de
forma parcelar, onde dos avanos no estudo das classes IFC sejam retirados os conhecimentos sobre as
entidades estudadas de modo que seja possvel incrementar funcionalidades nesses softwares. Ento,
ter-se- uma implementao baseada no conceito de melhoria contnua, cujo objectivo ser a
incrementao e a procura por solues que contornem os actuais problemas de interoperabilidade.
Por ltimo surge o Captulo 6 Concluses que como o prprio ttulo indica, vem tecer as
consideraes finais com base no estudo elaborado ao longo da dissertao, expor algumas das
principais dificuldades sentidas ao longo desse estudo e dar tambm um ponto de vista mais pessoal
acerca da situao actual no que se refere interoperabilidade entre ferramentas BIM.


O Modelo IFC como Agente de Interoperabilidade



5






2
2 ESTADO DA ARTE


2.1. GESTO DA INFORMAO
2.1.1. ASPECTOS GERAIS
Uma boa base para a comunicao reside numa gesto de informao apropriada, sendo que os BIM
(Building Information Modeling) surgem como a ferramenta que possibilita a integrao de toda a
informao referente a um dado projecto e de todos os intervenientes envolvidos, constituindo assim
um dos desenvolvimentos mais promissores na rea da arquitectura, engenharia e indstria da
construo (Eastman et al. 2011).
O recurso s ferramentas BIM constitui um contributo valioso no alcance dos objectivos do projecto,
tornando todo o processo de gesto mais transparente. O modelo tridimensional demonstra
rapidamente quais os pontos que requerem especial ateno, quais os objectivos cumpridos em
determinada rea, quais as situaes que futuramente so susceptveis de evidenciar problemas, etc.,
resumidamente, apenas pela visualizao do modelo 3D possvel traar cenrios expectveis e
definir medidas concretas de correco. Percebesse ento claramente quais os benefcios que a
implementao destas ferramentas trs para todas as reas do projecto, j que permitem uma melhoria
dos conceitos bsicos da aco e interaco humana (colaborao, comunicao, compreenso e
visualizao). Contudo, por si s a indstria da construo no se altera apenas com a implementao
de novas ferramentas tecnolgicas, fundamental que haja um contributo e um trabalho realizado em
equipa por parte dos colaboradores do projecto para que se alcancem os resultados desejados.
(Kymmell 2008).

2.1.2. DOCUMENTAO DE PROJECTO
Nos dias que correm a indstria da construo regula-se por desenhos na sua maioria bidimensionais
(peas desenhadas) e instrues escritas (peas escritas), que permitem assim a transposio de ideias
para o papel, de modo a que essas informaes sejam perceptveis por toda a comunidade da
construo. Nas ltimas dcadas, inmeras normas vm acompanhando a evoluo e desenvolvimento
dos desenhos de construo e restante documentao de projecto, mas apesar destas normas e
especificaes tcnicas estarem uniformizadas, o uso de instrues bidimensionais num mundo
tridimensional pode conduzir a concluses ambguas. Este um problema recorrente na indstria da
construo, os baixos nveis de formao de quem executa associado dificuldade de interpretao
das peas de projecto e transposio visual de informao bidimensional para tridimensional, conduz
O Modelo IFC como Agente de Interoperabilidade



6

muitas vezes a uma distoro da ideia conceptual pensada pelo projectista, o que geralmente resulta
em erros de execuo. Devido dificuldade que existe em compreender se a informao foi
correctamente percepcionada, muitas vezes estes erros de comunicao e interpretao mantm-se
ocultos at que seja demasiado tarde para abord-los de forma eficaz.
A organizao das peas de projecto pode demonstrar ser bastante complexa, pequenas alteraes
como por exemplo a modificao da localizao de uma porta ou janela implicam a necessidade de
alterao de vrias peas desenhadas e escritas. Deve ser assegurado que todos os documentos que
contm informaes relativas referida porta ou janela so devidamente alterados, porque uma pea
no alterada ir levantar conflitos entre verses. Mesmo procedendo a uma correcta alterao de todas
as peas existe ainda a dificuldade em fazer chegar essa nova informao a todos os envolvidos na
construo. Estes pequenos exemplos servem para salientar a importncia da comunicao e realam
as potencialidades dos BIM (Figura 2.1).

Figura 2.1 Os mbitos dos BIM e suas inter-relaes. Adoptado de SCIA Scientific Software.

A natureza repetitiva da informao contida nos desenhos tambm uma das causas para a ocorrncia
de erros. Esse um dos aspectos para o qual a ascenso da era informtica trouxe bastantes benefcios,
a automatizao dos processos veio acelerar a elaborao dos projectos e diminuir significativamente
os erros associados a esta problemtica (Kymmell 2008).

2.1.3. GESTO DE PROJECTO (PROJECT MANAGEMENT)
Os objectivos do projecto derivam directamente dos desejos e das necessidades do Dono de Obra e
tambm dos membros da equipa de projecto. Para que se alcancem os objectivos e se obtenham os
resultados desejados necessrio transpor as barreiras que se opem ao desenvolvimento do projecto.
Para isso, devem-se conhecer as fraquezas existentes no processo de construo, deve ser incentivada
a reduo dos riscos, a colaborao entre intervenientes, a antecipao dos problemas e o aumento da
segurana mas tambm nunca esquecendo o controlo de custos e tempo.
O Modelo IFC como Agente de Interoperabilidade



7

O maior problema no planeamento e construo de projectos de edifcios a incorrecta visualizao
da informao de projecto. Certo que no possvel representar e definir um projecto do qual no
se tem uma plena compreenso dos seus requisitos e objectivos. Um projecto deve ser visualizado,
compreendido e comunicado de forma completa desde o seu incio para que se limite ao mximo a
ocorrncia de erros a priori.
As principais causas geradoras de fraquezas no planeamento, concepo e processo construtivo so:
Dificuldades de Comunicao A complexidade dos projectos de construo e os inmeros
recursos humanos envolvidos so sempre um problema de difcil gesto. Fazer chegar a informao da
origem at ao destino de forma intacta por vezes uma tarefa que exige determinados cuidados, pois
muitas vezes a informao difundida por meios volteis que distorcem as informaes. Para alm
desses problemas tambm podero existir problemas no entendimento das tarefas ou at mesmo
problemas de comunicao por incompatibilidade entre o carcter de indivduos.
Competio entre membros de uma equipa Por vezes indivduos membros de uma equipa
colocam os seus interesses pessoais frente dos interesses da equipa, o que resulta numa competio
entre indivduos com interesses pessoais, quando deveriam estar todos procura das solues que
melhor respondessem ao interesse da equipa e do projecto.
Transferncia de risco Na maioria dos casos os vrios modelos contratuais apenas
transferem o risco de uma equipa para a outra, e por isso no final o Dono de Obra quem acaba por
suportar os custos de ineficincia e dos problemas associados ao projecto. A maioria dos projectos no
incentiva a colaborao.
Litigao Devido enorme complexidade existente em todo o processo de construo, so
criadas demasiadas situaes susceptveis de gerar desentendimento (podendo-se originar
problemticas relacionadas com a resoluo de conflitos, erros e omisses, etc.). A litigao d-se
devido falta de comunicao, compreenso e colaborao entre os membros da equipa de projecto,
portanto quase todas as diferenas conseguem ser trabalhadas atravs de dilogo e comunicao
construtiva. do interesse da equipa minimizar e evitar estas situaes pois apenas terceiros tero
benefcios com os gastos causados por este tipo de episdios.
Para combater estes aspectos negativos torna-se necessria a implementao de uma srie de medidas
correctivas antes do problema ocorrer. Para isso, necessrio antes de mais compreender as fraquezas
que esto associadas construo para que se faa um planeamento e monitorizao eficaz desses
problemas, que responda s necessidades, seja eficaz e que v de encontro com metodologias de
melhoria continua, dessa forma os objectivos sero mais facilmente alcanados.
Estas so algumas das medidas para preveno da ocorrncia de falhas e tambm de gesto de
conflitos:
Reduo do risco por melhoria da comunicao Uma comunicao deficiente um factor
crtico para a criao de risco na construo. A complexidade da construo constitui um ambiente
propcio ao aparecimento de oportunidades onde a comunicao poder ser feita de forma deficiente e
por isso ser mal percebida ou no entendida por completo. Cada membro de uma equipa de projecto
deve ter a responsabilidade de assegurar que a comunicao feita por moldes que garantem a
correcta transmisso da informao e que esta feita de maneira clara e perceptvel pelos restantes
indivduos envolvidos num processo de construo.
Reduo do risco por aumento da colaborao O facto de colaborao entre equipas
tambm um factor de reduo de risco. Geralmente os membros de uma equipa preferem trabalhar de
O Modelo IFC como Agente de Interoperabilidade



8

forma individual, pois desse modo no tero que partilhar quer o seu sucesso quer o seu insucesso com
os outros membros. Ora, esta filosofia de pensamento torna o trabalho mais individualista e ao invs
de haver uma equipa que procura um objectivo comum, tem-se vrios indivduos com objectivos
pessoais que podem no corresponder aos objectivos do projecto, o que faz com que haja disperso
dos trabalhos e um isolamento na comunicao.
Antecipao dos problemas A antecipao dos problemas (quase que) uma das regras de
ouro que se procura seguir na construo, mas nem sempre fcil prever as situaes que podero ser
fonte de risco e/ou problemas. Isto implica que haja uma certa capacidade de previso dos problemas,
capacidade essa que pode ser melhorada pelo conhecimento dos factores de risco associados s
diversas tarefas e compreenso profunda dos detalhes e processos construtivos de modo a que esses
riscos sejam contabilizados e as aces de controlo implementadas ainda na fase de projecto.
Melhoria da segurana A segurana deve ser a prioridade em qualquer projecto de
construo. Um bom plano de segurana e sade uma boa base para garantir a segurana em obra,
mas devem ter-se em conta outras aces de preveno. Os indivduos envolvidos num projecto
devem estar ocorrentes dos perigos e factores de risco, deve existir sinalizao abundante em obra,
devem ser feitas aces de formao, etc.
Reduo de custos A reduo de custos deve ser feita pelo estudo de mercados paralelos e
pela aplicao de filosofias lean construction que incentivam a eficincia na construo. Os
processos de gesto da construo usam ainda pouca tecnologia quando comparados com outras
indstrias que tm cada fase do processo completamente monitorizada (Kymmell 2008).
Posto isto, as ferramentas BIM so no fundo uma inovao nos processos tecnolgicos do sector da
construo que demonstra ter o potencial necessrio para ser capaz de mudar no s o modo como a
gesto da projecto feita mas tambm o modo como feita a gesto da construo ao longo das fases
construtivas e ciclos de vida do edifcio. O acompanhamento faseado que o BIM permite fazer,
associado ao conhecimento das fraquezas na gesto da construo e medidas preventivas que devem
ser tomadas, permitir revolucionar a indstria da AEC e o modo como o projecto encarado.

2.2. BIM BUILDING INFORMATION MODELING
2.2.1. CONCEITO
Um Building Information Model um modelo estrutural de informao digital, tridimensional, onde
constam os vrios objectos que compem o edifcio, capturando a sua forma, comportamento e
relaes das vrias partes do edifcio, sendo possvel indexar todo um conjunto de dados a um
determinado elemento. Permitem a elaborao de modelos digitais com informao completa de todos
os diferentes domnios do projecto, contendo a geomtrica e a informao relevante necessria para
dar suporte construo e gesto das actividades necessrias para a elaborao do edifcio (Eastman et
al. 2011).
A automatizao de processos e integrao da informao um dos princpios que est associado ao
BIM e uma das suas maiores vantagens. Este conceito de extrema importncia j que permite a
implementao de dados externos, como por exemplo, dados provenientes da monitorizao de
elementos estruturais (Hiplito de Sousa et al. 2011).
Estas primeiras impresses deixam claro que a grande inovao trazida pelo conceito BIM reside em
mais do que uma mudana tecnolgica, j que representa uma mudana de processos. Ao permitir a
representao de edifcios atravs de elementos inteligentes, capazes de conter informao e relaes
O Modelo IFC como Agente de Interoperabilidade



9

entre si, as ferramentas BIM no s mudam o modo como os desenhos de edifcios e respectivas
visualizaes so criadas, como tambm mudam todos os processos de elaborao e construo de um
edifcio, sendo que a maximizao das potencialidades das ferramentas BIM d-se quando se expande
a sua utilizao a todas as fases de construo do edifcio (Figura 2.2) (Eastman et al. 2011).

Figura 2.2 O BIM no ciclo de vida de um edifcio. (Autodesk 2013)

Um Building Information Model simula o projecto de construo num ambiente virtual. A simulao
tem a vantagem de ser feita em computador em formato digital usando um software informtico, o que
permite experimentar as prticas da construo e fazer os devidos ajustamentos antes da produo do
documento final. Erros virtuais geralmente no produzem consequncias graves se estes forem
correctamente identificados e monitorizados para que no sejam transmitidos para o projecto real. O
uso das simulaes computacionais era j uma realidade para muitas indstrias mas uma inovao
revolucionria no ramo da construo. Quando um projecto planeado virtualmente possvel
visualizar os aspectos mais importantes e fazer a deteco dos erros mais relevantes que podem ser
detectados informaticamente antes de se darem quaisquer instrues para o projecto, como por
exemplo, a deteco da sobreposio de elementos em fase de estudo usando ferramentas BIM permite
uma correco rpida e eficaz, ainda na fase de concepo de projecto.
Os modelos virtuais geralmente so distinguidos entre duas categorias, modelos de superfcie e
modelos slidos. Como o nome indica, os modelos de superfcie so apenas representados de forma
superficial apenas para efeitos de visualizao, atravs de componentes que contm apenas informao
respeitante a dimenses, forma, localizao, etc., ou seja, so modelos ocos que facilitam o estudo de
parmetros visuais do projecto e so usados sobretudo para design esttico, planeamento e marketing.
J os modelos slidos, que permitem conter mais informao que os modelos estticos, so muitas
O Modelo IFC como Agente de Interoperabilidade



10

vezes denominados de modelos inteligentes porque possibilitam a simulao em diversos mbitos da
construo, muito para alm de apenas simulao grfica. Um modelo slido tem ainda a vantagem de
permitir produzir modelos bidimensionais como plantas, cortes ou alados segundo as convenes da
documentao da construo (ver Figura 2.3). Isto significa que um modelo slido pode ser usado
numa primeira instncia para fazer o desenvolvimento e detalhamento do projecto conceptual e
posteriormente esses desenhos podero ser usados como parte integrante do processo construtivo. Em
teoria a elaborao dos modelos BIM j no requer a existncia de modelos bidimensionais pois toda a
informao pode ser consultada ou retirada do modelo tridimensional, mas na realidade ainda
necessrio um progresso destas ferramentas BIM e tambm uma mudana de mentalidades at que as
ferramentas bidimensionais caiam em desuso. (Kymmell 2008)
Figura 2.3 Exemplo de modelao de estrutura 3D a partir uma base CAD

Apesar desse uso ainda no poder ser descartvel, comea-se a verificar que est a ser feita a transio
do j clssico formato CAD para os modernos formatos BIM e espera-se que num futuro prximos
estes modelos sejam usados em 4D (3D + factor tempo) e tambm em 5D (3D + factor tempo + factor
custos). A possibilidade de utilizao de plantas, cortes e/ou alados em formato CAD para utilizao
de base na construo de modelos tridimensionais BIM constitui muitas vezes uma preciosa ajuda na
elaborao destes modelos porque aumentam a facilidade e rapidez de elaborao.
No fundo, os BIM so uma variedade de modelos produzidos por diferentes pessoas, com a
possibilidade de diferentes nveis de detalhe e onde est envolto um enorme leque de diferentes
softwares em formatos distintos. Podero existir modelos detalhados do terreno (rea de implantao
do edifcio ou infra-estrutura), modelos arquitectnico (o modelo mais usado nos dias de hoje que
corresponde informao geomtrica), modelo estrutural (modelo analtico cujo fim ser a anlise
estrutural do edifcio), modelos MEP (mecnica, electricidade e canalizaes), modelos proteco
contrafogo e outros modelos especficos de equipamentos, acabamentos, construo temporria, etc.
O Modelo IFC como Agente de Interoperabilidade



11

Dada a grande variedade de modelos e de utilizadores que podero estar envolvidos num projecto, a
existncia de um formato de ficheiros que estabelea a ligao entre todos esses modelos e utilizadores
uma exigncia que se impe j que ser necessrio combinar toda a informao num software
particular, em suma, a interoperabilidade um ponto fulcral.
Este modelo global do projecto permitir a realizao de anlises qualitativas, quantitativa e continua.
A anlise qualitativa muitas vezes feita de forma totalmente independente das quantidades, tem
essencialmente em considerao a natureza dos problemas. Alguns dos casos so a comunicao,
marketing, ilustraes e vdeos, que dizem respeito ao contedo visual que elaborado para dar uma
impresso acerca do projecto a individualidades externas a este, a anlise de construtibilidade, que se
refere s metodologias de construo, a coordenao de sistemas e deteco de conflitos, que uma
das aplicaes mais populares dos modelos BIM e por fim a anlise energtica do edifcio, que trata da
anlise qualitativa das solues construtivas quanto aos ganhos e perdas de energia.
A anlise sequencial contempla os estudos nos quais o tempo um dos factores, tanto em termos de
durao como sequncia. Esta anlise requer um estudo bastante visual mas tambm inclui muita
informao quantitativa. Alguns dos casos so a sequncia de montagem e instalao de componentes,
que requer uma interpretao visual do modo de execuo das tarefas e tecnologias construtivas
necessrias e a programao de tarefas da construo que tem de ter em conta a mo-de-obra,
equipamentos, meios necessrios e todo um conjunto de factores que influncia a durao das tarefas.
Por ltimo a anlise quantitativa envolve a medio de quantidades de determinado elemento do
projecto que muitas vezes tambm combinada com outra informao. Alguns dos casos so as
quantidades de materiais, que so extradas do modelo slido BIM pela anlise da informao
interpretativa, os custos de construo estimados, que resultam da multiplicao das quantidades de
materiais pelos preos de execuo respectivos e anlise de custos associados manuteno no ciclo
de vida da construo, que contempla os custos de controlo, manuteno e energia.

2.2.2. VANTAGENS E DESVANTAGENS
2.2.2.1. Vantagens
Para maximizao das suas potencialidades, os BIM podem ser utilizados para demonstrar todo o ciclo
de vida da construo, para uso presente ou futuro, incluindo os processos construtivos e fases de
instalao, podendo melhorar significativamente as prticas comerciais (Eastman et al. 2011). As
informaes contidas no modelo podem ser utilizadas para os mais variados fins, para a gerao de
documentos de produo e documentos quantitativos, anlises de desempenho de sistemas, anlises de
incompatibilidades entre outros.
Uma das grandes vantagens apontadas que constitui um dos principais critrios pela escolha de
ferramentas BIM a habilidade de produzir documentos finais de construo (Figura 2.4), sem ser
necessrio o recurso a outras ferramentas complementares. Segundo Khemlani (2007), as questes
relacionadas integrao, ao 4D e ao IFC so ainda consideradas como pouco expressivas. Neste
momento, os principais critrios para a escolha de um software BIM so a capacidade de uma
produo completa de documentos do edifcio, objectos inteligentes que possibilitam uma relao de
associao a outros objectos e a disponibilidade das variadas e inmeras bibliotecas de objectos. A
realizao de tarefas colaborativas e nomeadamente a capacidade de exportar e importar ficheiros em
formatos universais ainda no so critrios significativos para a escolha de ferramentas BIM
(Khemlani 2007).
O Modelo IFC como Agente de Interoperabilidade



12

Figura 2.4 Extraco de informao diversa do modelo 3D (Graphisoft 2013)

Outra das vantagens dos BIM a possibilidade de trabalho em simultneo de mltiplas e distintas
reas do projecto, podendo o modelo virtual ser construdo por partes, j que os elementos que
constituem o modelo esto ligados atravs de relaes paramtricas, possibilitando a introduo da
informao de forma estruturada, fazendo com que as alteraes se difundam em tempo real em todo o
modelo, evitando a propagao de erros e dinamizando os processos de actualizao (Eastman et al.
2011). Uma vez que possibilita a avaliao da compatibilizao das diferentes peas do projecto
significa que h uma maior facilidade na deteco de problemas relacionados com a compatibilizao
entre os diferentes projectos, permitindo reduzir significativamente a quantidade de erros e omisses
de projecto, dando a oportunidade de actuar a priori, ainda em fase de projecto, onde as alteraes e
correces so relativamente fceis de aplicar, evitando possveis atrasos e gastos em obra, associados
a esses factores.
As vantagens de se ter uma equipa de projecto a produzir todo o Building Information Model so
imensas, porque a resoluo de inmeros problemas facilitada pela interaco entre indivduos.
Desta forma possvel uma reviso contnua do modelo porque todo a troca de informao feita
numa comunicao constante, resultando num produto final da construo com uma correspondncia
mais precisa com o que foi inicialmente projectado (Figura 2.5).
O modelo final poder tambm permitir a visualizao de combinaes entre os modelos parcelares,
por exemplo, algumas das vistas podero permitir a visualizao do modelo analtico e outra
informao relacionada com esses componentes. Existem tambm outro grupo de ferramentas que
permitem a anlise quantitativa do projecto, quer a nvel de estimativa de prazos, quer a nvel de
estimativa de custos.
O Modelo IFC como Agente de Interoperabilidade



13

Figura 2.5 Correspondncia entre o modelo BIM e a situao real (Lillja 2012).

2.2.2.2. Desvantagens
Contudo, a utilizao das ferramentas BIM ainda so utilizadas por um pequeno nmero de tcnicos,
sendo muitas vezes ignoradas as capacidades destas ferramentas j que a maioria apenas as usa para
representao tridimensional do modelo do projecto, esquecendo todas as restantes potencialidades
ligadas ao conceito (Gequaltec 2011). Os custos de implementao e formao de profissionais so
outra desvantagem que dificulta a tomada de deciso pelo seguimento dos BIM.
Muitos aspectos legais relacionados com a implementao das ferramentas BIM tm estado sob
discusso e so uma rea qual os arquitectos, engenheiros, empreiteiros e subempreiteiros esto
atentos. Existem vrios obstculos adopo do modelo BIM, como so exemplo as questes
relacionadas com a propriedade do modelo e suporte dos custos que lhe so inerentes e funes de
encargo pelo rigor e exactido do modelo. Salvo raras excepes, os contractos correntes no definem
concretamente muitos destes aspectos ligados implementao dos processos BIM e ao no
abordarem concretamente os benefcios e riscos associados introduo destas ferramentas no
possvel tirar o mximo partido do seu uso. Contudo e apesar do risco assumido por quem decide
implementar o mtodo BIM, esta implementao resulta geralmente numa poupana significativa,
razo pela qual o nmero de empresas que recorrem s ferramentas BIM tem aumentado. Seria
vantajoso desenvolver um mtodo de contrato onde os participantes na equipa de projecto pudessem
beneficiar das melhorias trazidas pelas tcnicas de gesto BIM, promovendo a colaborao e a reduo
de risco (Kymmell 2008).

2.2.3. FERRAMENTAS BIM
Nas ltimas dcadas, temos assistido a uma fase de transio em que os desenhos e projectos em
suporte papel se tm transposto para o formato digital. A rpida evoluo destes instrumentos digitais
tem proporcionado inmeras novas possibilidades ligadas gesto da informao na indstria da
construo (Eastman 1999).
Tudo comea em 1957 quando Patrick J. Hanratty desenvolve o primeiro software comercial CAM
(Computer-Aided Machining). Cinco anos depois, Douglas C. Englebart d uma viso daquilo que
sero as ferramentas arquitectnicas futuras no artigo Augmenting Human Intellect. Em 1963, surge
a primeira ferramenta CAD (Computer-Aided Design) desenvolvido por Ivan Sutherland nos
laboratrios MIT Lincoln, usando uma interface grfica conhecida como Sketchpad. Os dois
O Modelo IFC como Agente de Interoperabilidade



14

principais mtodos de representao de formas, Constructive Solid Geometry (CSG) e boundary
representation (BREP), aparecem entre os anos 70 e os anos 80. Anos mais tarde, uma empresa
Hngara, a Graphisoft fundada em 1982, lana o Archicad em 1984 que seria o primeiro software BIM
no mundo e continua ainda a ser usado mais de 30 anos depois. (Silva 2011).
Desde ento muitas outras ferramentas surgiram, que vm incrementar valor indstria da construo
atravs da inovao e melhoria contnua. Hoje em dia o uso das ferramentas BIM permitem gerar
edificaes a partir de maquetes virtuais, onde se pode facilmente e rapidamente extrair um amplo
domnio de informaes. Permite gerar vistas tridimensionais mas tambm plantas, cortes, alados,
pormenores entre outras peas de projecto, tudo isto falando apenas no mbito de geometria mas muito
mais pode ser feito. possvel simular detalhes estruturais e fazer verificaes segundo normas que
validam o modelo analtico e a sua funo estrutural e tambm fazer clculos de eficincia energtica
entre outras utilidades que dessa forma fazem uma associao global dos elementos que constituem o
modelo. Para alm de tudo isto o recurso s ferramentas permite gerar uma quantificao automtica
com rigor e detalhe que pode ser usada para fins de execuo oramental, controlo de projecto e
aprovisionamento de materiais, minimizando a ocorrncia de erros nestas reas pela facilitao de
processos.
Nos sistemas BIM, ao modificar-se o projecto tridimensional, todo os restantes conjuntos de
informaes mencionados so imediatamente alterados e actualizados, no dando espao precurso
de erros resultantes de alteraes efectuada em fase de projecto. Esta outra das vantagens que vem
impulsionando a implementao do BIM.

2.3. INTEROPERABILIDADE
No mbito das TIC (tecnologias da informao e comunicao) entende-se por interoperabilidade
entenda-se a capacidade de gerir, trocar e comunicar produtos e informao electrnica por via
computacional, podendo, por exemplo, tratar-se de troca de informaes referentes a dados de projecto
entre empresas ou profissionais. Por esta razo a interoperabilidade tambm vista como um meio que
permite a integrao na execuo do projecto pois constitui uma implementao para administrar
relaes colaborativas entre os membros dos vrios domnios da construo.
Tal como em muitas outras indstrias, na indstria AEC (Arquitectura, Engenharia e Construo) h
uma enorme necessidade de comunicao e consequente troca de dados e informao entre
arquitectos, engenheiros, consultores, empreiteiros, subempreiteiros, fornecedores e proprietrios, pois
o processo de projecto envolve muitos participantes nas diferentes fases. partida esta comunicao
s se conseguiria se todos os intervenientes usassem os mesmos softwares. Como seria expectvel,
cada interveniente usa o software que melhor se enquadra com os seus objectivos profissionais. Isto
implica que para haver uma correcta permuta de informaes, devem antes de mais existir garantias de
interoperabilidade entre softwares, para que os sistemas possam trabalhar em conjunto e todos os
intervenientes falem numa mesma linguagem, transpondo as barreiras que se opem comunicao
(AIA 2009).
No processo de concepo tradicional de edifcios existe uma perda de valor na passagem de
informao entre as fases do processo construtivo (retratada na Figura 2.6) e de forma semelhante h
tambm uma perda de valor na troca de informao entre especialidades do projecto, pois nos moldes
clssicos quando um membro conclui a sua fase de trabalho e outro membro inicia a fase de trabalho
seguinte, este membro ir fazer uma verificao prvia do trabalho do primeiro e por isso ter de
voltar a fazer ou verificar um trabalho que partida seria desnecessrio e por isso tem-se uma perda de
O Modelo IFC como Agente de Interoperabilidade



15

valor do trabalho do primeiro membro. Nos moldes actuais as ferramentas BIM j possibilitam a
realizao de um projecto a partir de um modelo de base comum a todos os membros envolvidos no
projecto de um edifcio, o que proporcionado em boa parte pela interoperabilidade. Desse modo a
filosofia BIM contribuir significativamente para a reduo dessas perdas de valor, quer pela
facilidade de troca de informaes, quer pelo aumento da comunicao entre intervenientes e dessa
forma o decorrer das fases da construo aproximam-se da situao ideal. Com os elementos de uma
equipa a trabalharem com elevada proximidade durante as fases de projecto estes tero uma maior
facilidade em identificar erros nas diferentes vertentes do projecto numa fase onde a correco desses
erros ainda de relativa facilidade e com isso evitam-se os impactos negativos que esses erros teriam
se se propagassem at fase de construo (resultaria no s em custos acrescidos, mas tambm em
perdas de tempo e potencialmente de segurana e outros).
Figura 2.6 Fragmentao do processo construtivo e suas consequncias. (Hiplito Sousa 2006).

Portanto conclui-se rapidamente que todos os softwares envolvidos na indstria AEC devem ter um
mesmo objectivo comum, o de facilitar as vrias fases e ciclo de vida de um determinado
empreendimento. Para isso, estes softwares devem suportar os formatos standard, de modo a permitir a
livre circulao de informaes e compartilha de dados entre si. Se todos os membros de uma equipa
de projecto forem capazes de trocar impresses e informao livremente ento podero fazer uma
melhor integrao no projecto, resultando num maior rigor e rapidez de processos que aumenta
significativamente a eficincia da concretizao do projecto a todos os nveis. (Bernstein, Jr., and
Jones 2007).
Uma interoperabilidade deficiente tem impactos directos nos custos globais dos projectos de
construo e chega a ser apontada como uma das principais causas de desperdcio de tempo na partilha
e traduo dos dados. Um estudo realizado em 2004 pela National Institute of Standards and
Technology aponta a deficiente troca de informaes e dados como uma das principais causas dos
custos excedentes, estimando uma perda anual associada a este problema na ordem dos 15,8 mil
milhes de dlares (USD). Tambm o relatrio sobre interoperabilidade de 2007 da McGraw Hill
SmartMarket afirma que, em mdia, 3,1% do custo de cada projecto desperdcio devido falta de
O Modelo IFC como Agente de Interoperabilidade



16

interoperabilidade. Estes dados transmitem a problemtica associada deficiente comunicao e a
importncia de implementao de metodologias mais eficientes para as diferentes reas (AIA 2009).
As razes que fomentam esta problemtica esto relacionadas com a dificuldade associada
transferncia de dados entre programas, quer pela vasta quantidade e variedade de informao que um
nico projecto pode conter quer pela ausncia de linguagem comum, que se deve em parte ao interesse
que as empresas distribuidoras de software tm, em ocultar determinada codificao prpria e privada,
de modo que essa informao no seja acessvel a empresas da concorrncia.
Nos ltimos anos, tem existido um esforo que vai no sentido de criar uma linguagem comum para a
construo, que visa dar resposta a problemas concretos da construo, relacionados com as
organizaes, os regulamentos, e as prticas de trabalho actuais. Infelizmente, no s nestes campos
em que h uma falta de uniformizao da linguagem. Entre os prprios softwares, denota-se uma
ausncia de linguagem comum, o que implica a necessidade de reintroduo de dados. A padronizao
da informao um desafio a nvel tcnico e organizacional a ser superado e assim sendo, com o
objectivo de suprimir esta lacuna, surgiu como resposta o conceito de interoperabilidade, que retracta a
necessidade de transferir informaes entre aplicaes, permitindo que mltiplos programas possam
contribuir para um mesmo trabalho (Eastman et al. 2011).
Neste momento os dois principais modelos de informao de produtos da construo standard, que
possibilitam a permuta de informao entre diferentes aplicaes BIM so o modelo IFC (Industry
Foundation Classes) usado para o planeamento da construo, projecto, construo e operao, e o
modelo CIS/2 (CIM steel Integration Standard Version 2) usado para a engenharia e fabricao de
estruturas metlicas. Ambos usam a representao geomtrica, relaes entre processos e materiais,
performance, fabricao e outras propriedades necessrias para o projecto e produo, usando a
linguagem EXPRESS tambm usada em STEP (Standard for the Exchange of Product Model Data)
(Eastman et al. 2011).
O objectivo do STEP baseia-se em fornecer o mecanismo necessrio para se descrever definies de
produtos de uma forma completa e clara ao longo do seu ciclo de vida. Esses dados devem por isso ser
elaborados de forma independente do sistema computacional, isto , as definies descritas devem
permitir que a representao da informao dos produtos seja passvel de troca entre diferentes
sistemas (Laakso and Kiviniemi 2012). O STEP encontra-se organizado numa srie de partes em que
cada uma se encontra publicada separadamente. Essas partes dividem-se essencialmente em seis
grupos que so eles a descrio metodolgica, recursos integrados, protocolos de aplicaes, testes
abstractos, mtodos de implementao e testes de conformidade (Schevers and Drogemuller 2006).
Como j foi referido o STEP usa formalmente a linguagem EXPRESS para especificar e representar
informao de produtos de forma precisa e consistente que facilita a sua implementao. A linguagem
EXPRESS inclui tipos, entidades declaradas, contantes declaradas, restries especificadas e
descries algortmicas. uma linguagem de modelao mas no de programao e tornou-se no
mecanismo central de suporte para os produtos de modelao abrangendo um vasto conjunto de
indstrias, o que s possvel graas ao enorme nmero de bibliotecas de recursos geomtricos,
classificaes, medies entre outros. A linguagem EXPRESS de grande utilidade computacional,
porm torna-se algo complicada em ser humanamente interpretvel e por isso ter sido desenvolvido
uma verso mais grfica conhecida como EXPRESS-G sendo toda essa informao ISO-STEP
disponibilizada em domnio pblico (SCRA 2006).

O Modelo IFC como Agente de Interoperabilidade



17

2.4. IFC INDUSTRY FOUNDATION CLASSES
2.4.1. CONTEXTO HISTRICO
A BuildingSMART Alliance surge em 2006, anteriormente denominada International Alliance for
Interoperability (IAI), uma organizao que nasce da aliana de organizaes da indstria AEC cuja
misso contribuir para um ambiente construdo sustentvel, atravs de informao mais inteligente
partilha e comunicao. Fundada em 1995, visa desde ento criar um padro que permita a
interoperabilidade de dados entre programas na rea dos BIM numa indstria da construo que vista
como distribuda e fragmentada dada as vrias especialidades que a compem (como so exemplo as
especialidades de arquitectura, estruturas, procurement, construo, manuteno e operao). Esse
padro IFC surge com o objectivo de facilitar a transferncia de dados representativos de partes de
edifcios e suas relaes. (Bentley Systems 2008). Desde ento tm surgido vrias implementaes
especificao IFC original. Os principais lanamentos foram o IFC1.5.1, IFC2.0, IFC2x, IFC2x2,
IFC2x3 e agora o IFC4. O lanamento do IFC2x em 2000 foi um marco histrico na medida em que a
partir desse momento o ncleo da especificao IFC permanece inalterado e cada lanamento adiciona
capacidades especificao anterior.
A Figura 2.7 faz a representao cronolgica dos principais avanos do padro IFC.
Figura 2.7 Cronologia do padro IFC. (Liebich 2013)

2.4.2. CONCEITO
O principal objectivo desta iniciativa foi o de melhorar a comunicao, produtividade, tempo de
entrega, custos e qualidade durante todo o ciclo de vida do edifcio, atravs da possibilidade de
permuta de informao entre os intervenientes no projecto independentemente dos programas usados
por cada um. Estas so as razes pela qual este padro desenvolvido j considerado um pr-requisito
para melhorar os fluxos de trabalho na construo usando as metodologias BIM, contribuindo
significativamente para eliminar desperdcios gerados por uma interoperabilidade inadequada.
O formato de ficheiros independente, IFC (Industry Foundation Classes), um formato aberto que
actua de forma neutra, permitindo capturar no s a geometria mas tambm todas as outras
propriedades associadas aos objectos e tambm as suas relaes dentro de um modelo BIM, para
permitir e facilitar o processo de troca de informaes que de outro modo no seria possvel realizar
(Thein 2011).
O Modelo IFC como Agente de Interoperabilidade



18

O IFC uma base de dados de informao dos objectos que permite a partilha e troca de dados entre
softwares, em que cada verso do protocolo IFC permite uma especificao segundo o protocolo
ifcXML ou segundo o protocolo EXPRESS (Martins 2012). Usa um arquivo de texto simples, j que
este formato o nico formato de dados digital verdadeiramente universal, dando origem a ficheiros
com a extenso *.txt, *.ifc ou *.ifcXML. Note-se que um ficheiro com a extenso *.ifcXML
tem um tamanho no disco entre 300% a 400% superior a um ficheiro do tipo *.ifc. Usando um
algoritmo de compresso PKzip 2.04g tambm possvel gerar um ficheiro com a extenso
*.ifcZIP, que ocupar entre 60% a 80% do ficheiro original comprimindo ficheiros *.ifc ou 90% a
95% comprimindo ficheiro *.ifcXML (Bentley Systems 2008).
As aplicaes compatveis podem abrir ou importar arquivos IFC, isto , podem reutilizar dados
gerados em outros programas, adicionar, eliminar ou alterar informao e voltar a exportar novamente
para IFC o modelo modificado, permitindo uma sucessiva reutilizao desse modelo em outras
aplicaes que lhe podero acrescentar dados da mesma ou de outras especialidades. Os sistemas BIM
modernos so ento capazes de gerar representaes ricas em componentes de construo, onde o IFC
permite acrescentar uma linguagem comum para a transferncia de informaes e deste modo as
vantagens da explorao dos BIM so maximizadas (AIA 2009). Isto reduz a necessidade de
remodelar o edifcio na utilizao de diferentes aplicaes, facto que incontornvel pois o uso
produtivo dos BIM requer troca de dados entre as diferentes disciplinas. Cada implementao para a
troca de dados usando o IFC deve seguir as exigncias de troca. Estas exigncias especificam as
informaes que so necessrias para a troca e partilha de informao numa determinada fase do
projecto, sendo esta especificidade de grande importncia para prevenir incertezas e certificar e
averiguar se a informao em causa foi salvaguardada (BuildingSMART 2013).

The ability of an owner to reuse data instead of paying to continually recreate or reformat
information for new uses during the facility lifecycle is one of most compelling reasons for owners to
advocate for true interoperability: a common international data exchange standard that enables data
to be imported and exported by any software system, at any time.
- Renee Tietjen, Senior Architect, U.S. Department of Veterans Affairs

2.4.3. NORMAS
O formato IFC era j registado pela ISO como ISO/PAS 16739:2005 e agora com a chegada do novo
esquema IFC4, tambm ele aceite como norma ISO, vem trazer a esta norma o estatuto de Norma
Internacional, constituindo um importante marco histrico no percurso que vem sido feito para tornar
o IFC num verdadeiro padro aberto de BIM. Esta nova norma ISO 16739:2013 vem especificar um
esquema conceptual de dados e um formato de ficheiros para a realizao de troca de dados entre
aplicaes BIM, esquema esse que definido atravs de uma linguagem EXPRESS, tambm ela
estando normalizada pela ISO 10303-11:2004 e j que faz parte de um formato ASCII (American
Standard Code for Information Interchange) usa como suporte uma codificao em texto como j
havia sido referido. (ISO 2013)
Importa novamente referir que a linguagem EXPRESS usada em IFC a mesma linguagem de
definio de dados que usada, por exemplo, em STEP ou CIS/2. Tem a vantagem de ser bem
adaptada e compacta para incluir regras de validao de dados dentro da especificao desses dados. A
estrutura de troca de dados do IFC chamada de formato ficheiro fsico STEP e como tal, tambm
definida pela ISO 10303-21:2002. Desde a realizao do IFC2x que a especificao ifcXML faz parte
O Modelo IFC como Agente de Interoperabilidade



19

do IFC-EXPRESS, onde essa especificao fornecida como um esquema XML 1.0, como definido
pelo W3C. O esquema XML criado automaticamente a partir da fonte IFC-EXPRESS usando a
representao XML para esquemas e dados EXPRESS, como definido na norma ISO 10303-28:2007,
o que garante a possibilidade de converso de arquivos .ifc para .ifcXML e vice-versa, dando
consistncia relao entre o IFC-EXPRESS e o ifcXML j que ambos podem trabalhar os mesmos
dados (BuildingSMART 2013).
A Figura 2.8 apresenta um diagrama com as normas implementadas pela BuildingSMART para
servirem de suporte ao formato IFC.
Figura 2.8 Diagrama com as normas implementadas pela BuildingSMART. (BuildingSMART 2013).

Em 2007 foi introduzido o conceito de Information Delivery Manuals (IDM) com a norma ISO 12006-
3, como uma especificao que constitui elemento oficial da normalizao IFC, foi um dos resultados
de uma viso minimalista que conduziu a uma aproximao da normalizao da especificao IFC. O
IDM tinha duas componentes, uma a de servir as necessidades de implementao a nvel tcnico para
os desenvolvedores de software e a outra componente era fornecer os processos que permitissem um
fluxo de trabalho entre os utilizadores finais. Um IDM no fundo uma referncia para a integrao de
dados e processos requeridos pelos BIM e por isso deve especificar o enquadramentos desses dados e
processos, porque so relevantes, quem so os envolvidos no processo de criao, qual o tipo de
informao em causa, os benefcios da informao e porque que estas informaes devem ser
suportadas pelas aplicaes. Assim as partes que compem um IDM so as definies de caracter
tcnico como o processo de mapeamento, requisitos de troca, partes funcionais e conceitos. (Kiviniemi
et al. 2008).
Outra aproximao minimalista para a normalizao foi a introduo do formato Model View
Definition (MVD) do IFC. O seu propsito foi estabelecer um equilbrio entre as necessidades dos
utilizadores enquanto clientes e as possibilidades ao alcance dos desenvolvedores de software, atravs
de documentao que expe o modo como a troca de dados entre diferentes aplicaes deve ser feita,
descrevendo os benefcios directos da implementao do modelo IFC.
O Modelo IFC como Agente de Interoperabilidade



20

Os conceitos IDM e MVD pretendem facilitar a implementao da interoperabilidade e relacionam-se
num contexto que tem como base o IFC. As aplicaes implementam um MVD especfico que se
sustenta depois na documentao fornecida pelo IDM que serve como guia pra o conhecimento dos
fluxos de informao permitidos usando a especificao IFC.
Em 2008, a BuildingSMART apresenta formalmente o conceito de International Framework for
Dictionaries (IFD) que vem alargar o mbito da normalizao do IFC. Este conceito IFD referido
como o terceiro pilar para a troca de dados baseado no formato IFC e procura descrever o que
passvel de troca facultando os mecanismos que permitem a criao de dicionrios para cruzar os
modelos IFC com informao existentes em bases de dados. (Laakso and Kiviniemi 2012).

2.4.4. ESTRUTURA DO IFC
A especificao IFC ento constituda por definies semnticas informaticamente legveis e
tambm informao humanamente interpretveis. Um esquema IFC nomeia relaes entre conjuntos
de tipos de informao segundo s definies semnticas, podendo esses dados serem verificados em
conformidade com um determinado esquema, de modo a garantir que essa representao dos dados
est sintacticamente correcta. Tal como outros modelos de dados escritos em EXPRESS, o esquema
IFC poder ser escrito em forma longa ou curta, mas se no for especificada nenhuma forma em
concreto significa que o esquema se refere forma longa. A forma longa comporta todos os tipos de
dados num nico esquema e a forma curta usada para fins de documentao e desenvolvimento de
esquemas.
A organizao do IFC suportada por uma base de definies EXPRESS que so genricas para todos
os tipos de produtos e definem uma base de construo reutilizvel como por exemplo geometria,
materiais, propriedades, topologias, medies, intervenientes, cenrios e apresentaes, que por sua
vez so compostos para definir objectos que so usados frequentemente na indstria AEC (Eastman et
al. 2011). Os principais objectivos do desenvolvimento do esquema IFC segundo uma arquitectura so
fornecer uma estrutura para o funcionamento do modelo, promover um ambiente de partilha e troca de
informaes entre as vertentes distintas da indstria da construo, facilitar a manuteno da
especificao, possibilitar a reutilizao de um modelo, permitir a reutilizao de componentes de
modelao por parte de distribuidores de software e facilitar a compatibilidade entre diferentes
sistemas. Essa arquitectura opera com base num princpio de escada (Figura 2.9), possibilitando que
uma classe refira uma outra na mesma camada ou numa camada inferior, mas nunca numa camada
superior. Ento as classes de Recursos podem apenas referenciar outras classes de Recursos, as classes
de Ncleo podem referenciar classes de Recursos e as Extenses do Ncleo podem referenciar
tambm o Kernel (mas o inverso j no permitido pelo principio de escada), as classes de Elementos
Partilhados podem referenciar classes no Ncleo ou na camada de Recursos e por fim as classes na
camada de Domnios podem referenciar quaisquer classes.
O Modelo IFC como Agente de Interoperabilidade



21

Figura 2.9 Funcionamento do conceito de camadas na arquitectura do IFC. Adoptado de (IAI 1999).

A constituio de um dado esquema IFC feita por camadas (sub-esquemas) e segue uma estrutura
que est identificada na Figura 2.10. As camadas de Recursos (Resources) e do Ncleo (Core)
dispem de entidades que possibilitam a definio de modelos especificados nas camadas de
Elementos Partilhados (Shared Elements) e Domnios (Domains).
A camada de Domnios a camada mais geral que identifica o mbito de uma especificao IFC.
Divide a indstria AEC por grupos de especialidades, dando total independncia s entidades
pertencentes a esta camada que no pode ser referenciada por uma outra. Um modelo IFC
harmonizado directamente ligado ao ncleo da especificao, j os modelos que no estejam
totalmente harmonizados necessitam de definies prprias que garantam o funcionamento atravs de
adaptadores.
A camada de Elementos Partilhados a seo que diz respeito s questes ligadas com a
interoperabilidade entre sistemas. Este nvel compreende as entidades que so mencionadas em
mltiplos mdulos da camada de Domnios. O conceito de mdulos comuns permite estabelecer
ligaes de interoperabilidade entre diferentes domnios e aplicaes de modelos. (IAI 1999).
O Ncleo a camada mais geral dentro de um esquema IFC. Comporta as funes de sustentao do
modelo IFC e proporciona a sua estrutura bsica, bem como relaes fundamentais e conceitos
O Modelo IFC como Agente de Interoperabilidade



22

comuns para especializao em modelos especficos. O IfcKernel define a parte central do esquema,
capturando a construo em geral e especificando os atributos e relaes bsicas, como so exemplo a
localizao de produtos no espao, a sequncia de processos e o agrupamento geral de mecanismos.
Todas as entidades fora da camada de Recursos, definidas quer na camada de Ncleo ou acima desta,
derivam da classe IfcRoot. O IfcRoot a classe mais abstracta e raiz de todas as definies de
entidades, ou seja, o supertipo comum a todas as entidades IFC alm das definidas na camada de
Recursos. Todas as entidades subtipo do IfcRoot podem ser usadas de forma independente enquanto as
entidades do esquema de Recursos no so definidas de forma independente. Portanto, estas
definies, relaes e propriedades de objectos baseadas no formato EXPRESS dividem as entidades
em classes de raiz e classes sem raiz, isto , as classes que derivam directamente do IfcRoot so
constitudas por um Globally Unique Identifier (GUID) que identifica o objecto independentemente da
aplicao que est a usar o modelo, um nome, uma descrio e definio de utilizador, em oposio as
classes que no derivam da raiz no tm por isso identidade, ou seja, s so definidas se referidas por
atributo directo, inverso ou derivado requerido por uma entidade raiz. A decomposio da raiz IfcRoot
em tipos de objectos de geometria, relaes e propriedades feita por trs tipos fundamentais de
entidades fundamentais, IfcObjectDefinition, IfcRelationship e IfcPropertyDefinition, que formam o
primeiro nvel de especializao dentro da hierarquia. As definies de objectos so a generalizao de
qualquer item tratado semanticamente dentro o modelo IFC, representando todos os elementos
tangveis fisicamente (como o caso de sapatas, pilares, vigas, lajes, etc.), items que existem
fisicamente (como por exemplo espaos, grelhas, limites virtuais, anotaes, linhas de chamada, etc.) e
comportando tambm processos (tarefas, controlo de custos, controlo de recursos, intervenientes, etc.).
As relaes fazem a generalizao do relacionamento entre objectos e diferentes entidades que permite
assim especificar relaes entre objectos e propriedades directas e desagregar relaes semnticas
feitas pelos atributos dos objectos. As propriedades definem a generalizao da atribuio de
caractersticas aos objectos que especificam informaes particulares e atributos individuais mas que
podem tambm ser partilhadas por mltiplas entidades. Cada um destes trs tipos de entidades
fundamentais ramificam-se em subtipos de entidades que melhor especificam cada uma das categorias
e que constituem o segundo nvel de especializao da hierarquia. As definies de objectos
decompem-se em produtos, processos, controlos, recursos, intervenientes e grupos. As relaes
decompem-se em atribuies, associao, decomposio, definies, conectividade e declarao.
Quanto s propriedades so distinguidas entre conjunto de propriedades de modelo que definem os
tipos de sintaxe e dados para conjuntos de propriedades e propriedades individuais e conjunto de
propriedades de ocorrncia que definem as propriedades partilhveis e extensveis que podem ser
atribudas aos objectos e ocorrncias. (BuildingSMART 2013)
Por ltimo tem-se a camada de Recursos que a camada onde se encontram as disposies de
entidades que suportam as estruturas de dados do modelo. a camada mais baixa na arquitectura da
especificao IFC. Aqui so definidas todas as entidades genricas que permitem a formulao de um
conjunto de dados e informaes que possibilitam a construo de modelos, sendo referenciadas pelas
entidades raiz de um determinado modelo. Os recursos podem ser caracterizados como sendo um
conjunto de entidades que completam todas as outras classes. (Eastman et al. 2011).
O Modelo IFC como Agente de Interoperabilidade



23

Figura 2.10 Estrutura da base de dados da especificao IFC4. Adaptado de (BuildingSMART 2013).

Como a especificao IFC de carcter expansivo, as entidades base podem ser especializadas pela
introduo de subtipos de entidades para usos particulares. Esta estrutura hierarquizada de entidades
supertipo e entidades subtipo feita de forma indentada numa rvore hierrquica de relaes. Quando
um modelo num dado software traduzido para o modelo IFC usando a relao entre categorias de
objectos e entidades respectivas, o modelo em questo decomposto em tipos de objectos de
geometria, relaes e propriedades que so dados identificveis genericamente, para que dessa forma
possa ser transposto do formato inicial para o formato IFC. Alm destes tipos de objectos a
especificao IFC inclui tambm processos para a representao de actividades usadas na construo
de edifcios, na anlise geomtrica, e anlise de dados introduzidos e resultados.
No fundo o IFC consiste numa biblioteca de definies e propriedades que podem ser usadas para
representar um projecto de um edifcio. Traduzindo o esquema IFC4 em nmeros pode dizer-se que
constitudo por 766 entidades, 126 tipos definidos, 206 enumeraes, 59 tipos de seleces, 42
funes, 408 property sets, 91 quantity sets e 1691 propriedades individuais. Estes nmeros
O Modelo IFC como Agente de Interoperabilidade



24

representam a vasta dimenso semntica do IFC e demonstram a complexidade desta especificao
que procura cada vez mais possibilitar a traduo de uma rea mais alargada de dados e informaes
respeitantes a edifcios e seus sistemas. Estas listagens organizadas alfabeticamente onde constam
todas as informaes necessrias para a elaborao de modelos IFC so fornecidas pela
BuildingSMART em formato HTML A hierarquizao em rvore dessas listagens permite uma
navegao e visualizao de todos os subtipos de entidades.

2.4.5. O IFC NA INDSTRIA AEC
Em suma, o modelo de informao IFC visto como uma das chaves que permite transpor barreiras e
ineficincias que se opem ao desenvolvimento das tecnologias na indstria AEC (Thein 2011).
Consiste numa biblioteca de objectos e propriedades que podem ser usados para representar projectos
de edifcios e informao de suporte para um caso particular (Eastman et al. 2011).
Esta realidade s foi possvel pela colaborao conjunta de arquitectos, engenheiros, empreiteiros,
proprietrios de edifcios, tcnicos de instalaes, gerentes, fabricantes, fornecedores de software,
agncias governamentais, laboratrios de pesquisa, universidades entre outras entidades (Figura 2.11)
que agora contribuem e fazem parte da BuildingSMART (AIA 2009).
A BuildingSMART Internacional organizada por alianas regionais que representam um pas ou
grupo de pases. As alianas actuais servem a Austrlia, Benelux, China, Itlia, Japo, Coreia, Oriente
Mdio, Amrica do Norte, Singapura, Reino Unido, Irlanda, os pases nrdicos (Dinamarca, Finlndia,
Noruega e Sucia), os pases de lngua alem (Alemanha, ustria e Sua), os pases de lngua
francesa e os pases ibricos (Portugal e Espanha). (Thein 2011).
Figura 2.11 O formato IFC enquanto agente activo de interoperabilidade no openBIM

O Modelo IFC como Agente de Interoperabilidade



25





3
3 ESTUDO EMPIRICO DE
INTEROPERABILIDADE


3.1. INTRODUO
Com o intuito de se diagnosticar a eficincia e nveis de interoperabilidade dos principais aplicativos
comerciais BIM, o presente captulo representa um esforo feito no sentido de identificar as principais
no conformidades pela troca de informaes de modelos genricos. Sero elaborados casos de estudo
de transferncia de dados entre esses softwares usando trs modelos simples de estruturas (por ordem
crescente de complexidade: pilar, prtico e estrutura porticada). Estes exemplos permitem fazer uma
rpida anlise de interoperabilidade dos programas em causa (ou at de outros programas visto que se
trata de uma metodologia) nos domnios das informaes analtica, geomtrica e mecnica, que
correspondem s reas nas quais a presente dissertao se insere.
Esta anlise de grande importncia j que a troca de informaes entre softwares cada vez mais
uma necessidade no acto de engenharia e desenvolvimento de projecto.
Neste capitulo ser feita uma anlise com base nas ocorrncias observadas, posteriormente o Captulo
4 poder contribuir com conhecimentos que permitam um melhor entendimento de algumas
problemticas na transferncia de informaes usando o modelo IFC, ao nvel do seu funcionamento
interno.

Were starting to work with architects and engineering teams who can appreciate the value of
interoperability. Well produce case studies, measure metrics and be open about it. This industry is
more driven by fear of losing a competitive advantage than being transformative or innovative.
- John Tocci, President, Tocci Building Companies

3.2. APLICAO REALIDADE DE 2013
A realizao destes testes de interoperabilidade tem como principal objectivo detectar os principais
problemas decorrentes da passagem de informao entre os softwares Revit 2013, Robot 2013,
Archicad 16 e Tricalc 7.4, sendo usado para esse efeito ficheiros de troca do esquema IFC2X3 e
tambm se possvel passagem directa de dados entre programas.
Neste estudo de interoperabilidade foi dada uma especial enfase aos programas Revit e Robot
ambos da Autodesk. O programa Revit um software vocacionado principalmente para a modelao
O Modelo IFC como Agente de Interoperabilidade



26

de edifcios mas possui tambm uma componente que permite a aplicao de cargas estruturais,
atribuio de materiais e permite tambm j fazer algumas verificaes ao nvel das ligaes
estruturais. A criao de ficheiros feita a partir de quatro tipos de templates que so: modelo base
arquitectnico, estrutural, mecnico ou de construo.
J o programa Robot um software vocacionado essencialmente para a anlise estrutural. As suas
representaes tridimensionais apenas procuram apresentar os elementos de forma simples e
inteligvel, no procuram permitir a renderizao do modelo para apresentaes formais do edifcio.
Ainda assim este modelo 3D gerado no Robot (ou transferido directamente do Revit ou indirectamente
de outros programas usando a especificao IFC) permite a elaborao de cortes estruturais e outras
peas de projecto de estruturas, constituindo uma mais-valia na aplicao prtica destes softwares. O
Revit tambm permite a elaborao dessas peas, mas uma vez que no permite fazer a sua verificao
enquanto elemento de resistncia estrutural considera-se que h uma maior vantagem em realizar-se
esse tipo de trabalho directamente do Robot.
O Archicad da Graphisoft, j bem conhecido no mercado e assumido como sendo o primeiro programa
BIM, um software de modelao que permite sobretudo a criao de modelos arquitectnicos de
edifcios, interiores e reas urbanas e desenvolvimento de peas do projecto, competindo directamente
com o Revit.
Quanto ao Tricalc difundido pela Arktec, um programa de clculo de estruturas metlicas, de beto,
de madeira e de outros materiais, com possibilidade de escolha entre os Eurocdigos Estruturais ou os
regulamentos nacionais como o RSA e o REBAP, ou at mesmo regulamentos de outros pases como
a Espanha, Brasil, Mxico, Argentina e Estados Unidos da Amrica. Umas das suas fortes vantagens
so a possibilidade de pr-dimensionamento automtico, clculo automtico de seces e peritagem
detalhada. Existe uma afinidade especial entre o Tricalc e o Archicad, fomentada pela parceria entre a
Arktec e a Graphisoft. Ao Tricalc pode ser associado o T-Connect para o clculo de ligaes de
estruturas metlicas.
O esquema IFC2X3 foi o formato IFC que constituiu o principal elo que possibilitou a ligao e troca
de informao entre todos estes programas, mas muitos outros poderiam ter sido usados. A
buildingSMART disponibiliza a lista dos programas compatveis com a especificao IFC. Como
situao extra, foi tambm usado o esquema IFC4 enquanto formato que tambm permite a criao de
modelos atravs da sua linguagem de cdigo.
As concluses retiradas da observao e experimentao prtica so vlidas para a realidade de 2013.

If I was a software vendor I would make sure my technology was the most interoperable in the
industry as my competitive advantage.
- Hector Camps, Educator and President PHI Cubed, Inc.

3.3. DEFINIO DA ESTRATGIA DE AVALIAO
Para a simulao de testes de interoperabilidade foi usado um mtodo de experimentao de troca de
dados com suporte base no formato IFC, sendo os casos estudados sempre apenas entre dois softwares
de cada vez onde um identificado como sendo o programa origem e o outro o programa destino,
havendo a possibilidade de inverso dos papeis. A transferncia de dados de forma directa apenas foi
possvel nos casos de estudo entre o Revit e o Robot (e vice-versa) usando uma ferramenta includa no
O Modelo IFC como Agente de Interoperabilidade



27

Revit que permite a exportao e importao directa de dados para o Robot. De referir que a
comunicao directa de dados s possvel dentro de famlias de software, isto , aplicaes
pertencentes a um mesmo distribuidor.
Qualquer caso de estudo deve identificar o mbito a explorar, o propsito da sua explorao e os
critrios pelos quais se far a avaliao desse estudo (YIN 1993). O mbito e o propsito do estudo j
foram definidos anteriormente ficando em falta a definio dos critrios de avaliao. Para se poder
fazer uma anlise de transferncia de informaes definiu-se um conjunto de modelos com as
principais variveis a testar. Estas variveis identificam as principais propriedades usadas num modelo
estrutural que permitiro avaliar e classificar os nveis de interoperabilidade, isto , ser possvel
determinar quais os domnios de dados que so transferidos ou no. Os tipos de informao a
introduzir no modelo de teste diferenciam-se pela aplicabilidade de cada ferramenta BIM, e por isso
foram divididos de forma prtica em variveis de geometria, materiais, ligaes, apoios, cargas e
nveis. A varivel geometria um aspecto no domnio da arquitectura, tem caracter mais geral e
normalmente o aspecto mais saliente e mais facilmente visvel. As variveis de materiais,
ligaes, apoios e cargas enquadram-se no domnio da engenharia. A varivel nveis um
aspecto com carcter misto. Esto ento agora tambm definidos tambm os critrios de avaliao do
estudo.
Na definio estratgica de anlise representada na Figura 3.1 est subentendido o conceito de
pesquisa sistemtica que ser baseada na descrio, classificao e quantificao dos resultados
observados na execuo dos testes de interoperabilidade, tentando-se encontrar possveis causas para
uma determinada falha e verificao da plausibilidade das concluses retiradas.
Figura 3.1 O formato IFC como mtodo genrico para transferia de dados entre dois aplicativos BIM.

As variveis j descritas constituem um agrupamento de informaes, estas sero caracterizadas por
particularidades que possibilitem identificar rapidamente se os dados na troca em questo manter-se-
o ou no inalterados na realizao da transferncia de um programa origem para um programa
destino.
Suscintamente o diagrama da Figura 3.2 representa o processo usado para a realizao de testes de
interoperabilidade entre programas.
O Modelo IFC como Agente de Interoperabilidade



28

Figura 3.2 Diagrama de procedimento para realizao de testes de interoperabilidade

Portanto, este estudo emprico de interoperabilidade resulta no fundo da aplicao de um mtodo de
avaliao com um fluxo sequencial de testes entre dois programas, onde so avaliadas um conjunto de
variveis a testar. Este mtodo permitiu tambm avaliar o que sucede no programa destino (BIM 2)
quando alterada alguma informao no programa origem (BIM 1), retirando-se desse modo uma srie
de evidncias que derivaram da anlise do seguimento lgico. Na anlise realizada no ponto 3.5 ser
apresentado um exame detalhado com os problemas detectados na transferncia dos elementos.
Este tipo de anlise deixa em aberto algumas hipteses de resultado da transferncia de dados. A
situao desejvel uma transferncia completa dos dados sem se verificar qualquer tipo de alterao
na informao original. Porm, ainda difcil de alcanar na situao actual. As situaes mais
verificadas so as situaes onde o modelo gerado transferido e aberto possibilitando a transferncia
das informaes bsicas como geometrias simples e algumas propriedades, evitando a remodelao
total do edifcio, todavia o nvel de detalhamento ainda bastante limitado, o que neste momento torna
a especificao IFC de certa forma insuficiente. Infelizmente este no o pior cenrio, muitas vezes os
modelos so transferidos e h uma grande perda de informao que obriga a reintroduo da maioria
dos dados, contendo simplesmente informao geomtrica de baixa complexidade (elementos rectos) e
sem informaes agregadas podendo ainda, na pior das hipteses, no ser possvel abrir o ficheiro de
troca no programa destino ou ser aberto e no conter quaisquer dados.

3.4. FUNCIONAMENTO INTERNO DOS SOFTWARES NO DOMNIO DA INTEROPERABILIDADE
A converso de um modelo a partir de um software para um ficheiro IFC faz-se pela identificao dos
elementos simples que constituem esse modelo (dados geomtricos, propriedades e relaes). Depois
pela discriminao de categorias numa tabela interna do programa, este faz a correspondncia entre as
suas categorias que suporta e a classe IFC respectiva que reproduz o mesmo tipo de informao.
Devido limitao que existe na quantidade de categorias da tabela de correspondncia, muita
informao perdida logo partida numa transferncia de informao para o formato IFC. As
I
d
e
n
t
i
f
i
c
a
r

Selecionar tipos
de informao a
testar:
Geometria;
Materiais;
Ligaes;
Apoios;
Cargas;
Nveis;

C
r
i
a
r

Escolher o sistema
de software base.
Criar modelos de
teste contendo a
informao que se
pretende testar
usando o software
origem.
Procurar criar
exemplos simples
onde toda a
informao seja
facilmente visivel e
identificvel.
Salvar os modelos
com o nome do
programa usado na
origem e verso do
modelo para futura
referncia.
E
x
p
o
r
t
a
r

Exportar o
ficheiro
diretamente se
possivel.
Exportar atravs
da especificao
IFC criando-se
um ficheiro IFC
(*.ifc).
Ter em ateno
algumas opes
de exportao que
so especificas
em alguns
softwares.
I
m
p
o
r
t
a
r

/

V
e
r
i
f
i
c
a
r

Importar os
ficheiros para o
programa destino.
Verificar os tipos
de informao que
foram ou no
correctamente
transferidos.
Identificar
possveis causas e
formas de
contornar o
problema.
Salvar os modelos
com o nome do
programa usado no
destino e verso do
modelo para futura
referncia.
O Modelo IFC como Agente de Interoperabilidade



29

geometrias de baixa complexidade so um dos poucos tipos de dados que geralmente so transferidos
sem que se relatem quaisquer tipos de problemas de interoperabilidade. Para o caso dos restantes tipos
de informaes como relaes entre objectos, propriedades e at mesmo geometrias mais complexas
(por exemplo elementos curvilneos) so necessrios determinados cuidados pois infelizmente ser
provvel que ocorram problemas na passagem desse tipo de informaes ditas mais complexas
(Gequaltec 2011). A Figura 3.3 constitui um exemplo que retracta os problemas de interoperabilidade
de que se falam. As geometrias simples das vigas lajes e pilares so transferidas sem nenhum
problema visvel enquanto as geometrias mais complexas do veculo geraram conflitos, originando
uma visualizao bastante distorcida e com perda de informao.
Figura 3.3 Ficheiro IFC exportado pelo Revit e visualizado com o Solibri Model Viewer.

Dado que existe grande ocorrncia deste tipo de problema, de modo a que fosse possvel contorna-lo
em parte, surgiram as propriedades conhecidas como Property Sets. O modelo IFC faz a
diferenciao entre atributos e propriedades. Os atributos esto directamente ligados ao objecto atravs
da definio de um valor na seco de atributos de uma entidade e as propriedades so definidas
individualmente formando-se depois um grupo de caractersticas e s depois ento que se faz a
atribuio desse grupo a um determinado objecto atravs de um relacionamento entre entidades. Este
tipo de propriedades tem evoludo ao longo do tempo e algumas delas podem agora ser especficas de
um determinado projecto, regio ou pas. O esquema IFC faz a transio destas propriedades em
conjuntos com nomes pr-definidos que identificam e agrupam as propriedades de um determinado
tipo. O Archicad um dos programas que recorre frequentemente ao uso das Property Sets para a
exportao e importao de informao. Como se pode verificar pela Figura 3.4, h uma melhoria
significativa na transferncia de informao entre o Revit e o Archicad. Apesar de se continuarem a
perder algumas informaes relativas s diversas partes do veculo e materiais, observa-se que pelo
menos toda a geometria permaneceu intacta.

Figura 3.4 Ficheiro IFC exportado pelo Revit e importado pelo Archicad.

O Modelo IFC como Agente de Interoperabilidade



30

3.4.1. REVIT
Para se aprofundarem os conhecimentos no Revit, devem ser feitas algumas ressalvas que so vlidas
para todos os casos que envolvam troca de informao com este programa. Na verso Revit 2013 as
quatros vertentes (Arquitectura, Estruturas, Construo e Mecnica) fazem agora parte de um nico
programa do Revit, sendo organizadas por templates (modelos). Com o Revit surge o conceito de
famlias que apresenta algumas semelhanas com o conceito de blocos das ferramentas CAD. As
famlias so componentes usados na construo do modelo virtual como por exemplo os pilares,
paredes, lajes, janelas, etc. Cada famlia poder ser constituda por mltiplos tipos de informao com
diferentes dimenses, materiais e outros parmetros variveis. As famlias podem ser criadas, editadas
e importadas do exterior, cada alterao feita num dado tipo nesse modelo aplicado a todos os
elementos semelhantes de todo o projecto. Para importao de famlias que no existam por
predefinio no Revit, entre outras pode ser usada a biblioteca de famlias da Autodesk. No caso dos
seguintes exemplos que sero alvo de estudo foi necessrio descarregar as famlias que representam as
condies de fronteira e que no vm previamente definidas no Revit e posteriormente introduzidas
nas definies das condies de fronteira em cada um dos templates (Figura 3.5 e Figura 3.6).
Figura 3.5 Definies das condies de fronteira antes da introduo das famlias respectivas.

Figura 3.6 Definies das condies de fronteira depois da introduo das famlias respectivas.

O Modelo IFC como Agente de Interoperabilidade



31

Conhecidas j as informaes constantes nos passos de Identificao e Criao do procedimento de
avaliao necessrio Exportar os modelos do programa origem para o programa destino. Tendo-se o
Revit como programa origem so necessrios alguns cuidados que podero melhorar as condies de
transferncia (opo Send options da Figura 3.7).
Figura 3.7 Janela do Revit para a integrao de modelos do Revit no Robot e vice-versa.

No caso de se tratar de uma transferncia de forma directa do modelo do Revit para o Robot (opo
Send model) ou vice-versa (opo Update model), devem ser seleccionadas algumas opes de
exportao, como a opo de ignorar o peso prprio para que desta forma se consiga melhor
identificar se a informao relativa s cargas aplicadas estrutura transferida ou no para o Robot.
Ao no ser ignorado o peso prprio da estrutura poderiam ser tomadas consideraes erradas, uma vez
que se fosse efectuado o clculo da estrutura recm-chegada ao Robot seriam obtidos resultados, o que
poderia fundamentar erradamente que a troca de informao relativa s cargas teria sido realizada
correctamente quando na verdade a nica aco que poderia ter sido transferida havia sido a aco do
peso prprio. Ainda relativamente s opes de exportao da estrutura do Revit para o Robot deve
haver o cuidado de se fazer algumas alteraes nas configuraes das opes bsicas e avanadas.
Deve ser seleccionada a opo Execute model correction in Robot para que sejam efectuadas as
correces necessrias para garantir uma melhor representao em termos estruturais, seleccionar
tambm quanto s propriedades das barras a opo Do not use Revit settings pois as ligaes do
Revit so mais susceptveis de erros estruturais do que as definies de ligaes do Robot e ainda nas
opes avanadas seleccionar Select material of the best matching parameters para que haja um
maior rigor na troca de dados dos materiais como mostrado na Figura 3.8
O Modelo IFC como Agente de Interoperabilidade



32

Figura 3.8 Opes de exportao de modelos do Revit para o Robot de forma directa.

No caso de se tratar de uma transferncia de dados usando ficheiros IFC importa referir a existncia de
uma tabela de relaes entre as classes locais e as classes IFC para exportao e outra tabela para
importao. Esse dicionrio de correlaes das categorias Revit com as classes IFC, para exportao
de ficheiros, que vem instalado por defeito bastante limitado pois esto em falta muitas categorias e
dentro das categorias identificadas muitas no tm classe IFC correlacionada e por isso essa
informao no poder ser transferida para um ficheiro IFC. Este dicionrio representado sob o
formato de ficheiros *.txt com o nome exportlayers-ifc-IAI.txt no vem completo, no entanto
possvel alterar e acrescentar novas correlaes de classes e at existe a hiptese de importar um
ficheiro mais completo que o substitua, contudo sem que haja qualquer tipo de instruo existe uma
grande dificuldade em se determinar a correcta correlao de qual a classe IFC que corresponde a uma
determinada categoria do Revit que no esteja especificada. A Figura 3.9 apresenta a referida tabela
que faz a correspondncia entre as categorias e as classes IFC. Como se pode apurar a maioria das
categorias mencionadas nas opes do IFC Export Classes no tm classe IFC respectiva (atribudo
Not Exported), para alm de que as diferentes entidades IFC mencionadas em toda a tabela so
apenas cerca de meia centena, quando existem j mais de 750 entidades IFC (IFC4). D-se conta da
ausncia de categorias fundamentais de definio analtica de estruturas e cargas estruturais como por
exemplo o IfcVertex, IfcMember, IfcStructuralLoad, IfcRelConnectsStructuralMember,
IfcBoundaryNodeCondition, IfcSstructuralLoadCase entre muitas outras, entidades sem as quais no
possvel exportar dados relativos a ns, cargas, ligaes entre elementos estruturais e condies de
apoio. Posto isto, percebe-se que o Revit apenas exporta cerca de 7% das classes existentes, ento,
quanto mais complexo e detalhado for o projecto a exportar, maior e mais notvel ser a perda de
dados quando efectuada a exportao para o IFC. possvel melhorar ligeiramente esta percentagem
de eficincia na exportao, definindo manualmente as classes que correspondem s caractersticas
atribudas como Not Exported e completar assim a tabela, mas isso implica que haja o conhecimento
de qual a classe correcta a atribuir para cada categoria.
O Modelo IFC como Agente de Interoperabilidade



33


Figura 3.9 Tabela de correspondncia entre as categorias do Revit e as classes IFC sustentada pelo ficheiro
exportlayers-ifc-IAI.txt.

A tabela de importao de ficheiros IFC para o Revit semelhante de exportao, mas desta feita
temos como input a classe IFC e output a categoria do Revit. Mais uma vez a lista apresenta-se
bastante incompleta, com pouco mais de uma centena de entidades IFC identificadas para importao,
comportando ainda assim apenas cerca de 14% das entidades existentes e novamente a sua maioria das
classes IFC no tem categoria especifica correspondente (atribudo Generic Models). A origem da
informao contida na tabela de importao feita nos mesmos moldes que na tabela de exportao
O Modelo IFC como Agente de Interoperabilidade



34

para IFC, ou seja, tambm feita a partir de um ficheiro de texto *.txt mas desta vez denominado
exportlayers-dwg-ISO13567.txt. Pelo processo esse j explicado anteriormente podero ser
especificadas categorias para as classes IFC identificadas, mas desta feita existe uma dificuldade ainda
maior em determinar as categorias existentes do Revit que correspondam s classes IFC, conforme
exposto na Figura 3.10.
Figura 3.10 Tabela de correspondncia entre as classes IFC e as categorias do Revit e sustentada pelo ficheiro
exportlayers-dwg-ISO13567.txt.

3.4.2. ROBOT
O programa Robot no permite a exportao de ficheiros para o formato IFC o que limita desde logo
muitas potencialidades deste software, contudo permite uma importao mas tambm ela limitada.
Como alternativa para exportao no Robot tem-se o formato CIS/2 alternativo ao IFC mas vlido
apenas para estruturas metlicas.
A transferncia de informaes provenientes do Robot usando a ferramenta de integrao includa no
Revit acima descrita faz-se de forma semelhante mas desta vez seleccionando-se a opo Update
model da janela mostrada na Figura 3.11. Nas opes de envio possvel seleccionar se a
transferncia se realizar a nvel de todo o modelo ou apenas a nvel da parte estrutural.
Opcionalmente ainda permitido importar os resultados como reaces e foras internas, ligaes
metlicas e reforos necessrios em elementos o que por exemplo permite a substituio de um
elemento que no verificou as condies da segurana no Robot e cuja seco ser alterada de modo a
que se verifiquem essas condies.
O Modelo IFC como Agente de Interoperabilidade



35

Figura 3.11 Opes de importao de modelos do Robot para o Revit de forma directa.

3.4.3. ARCHICAD
O Archicad no possibilita a troca directa de informao com nenhum programa, o seu funcionamento
em termos de transferncia de dados baseia-se apenas no modelo IFC e opera de forma semelhante ao
observado no Revit. Existe uma lista (Figura 3.12), tambm ela limitada, de classes IFC que so
susceptveis de ser exportadas, mas aqui no mostrada ao utilizador a relao interna que h entre as
categorias do Archicad e as classes do IFC.
Figura 3.12 Lista de classes IFC exportadas pelo Archicad

Em termos de transferncia de dados para o modelo IFC, uma das grandes vantagens do Archicad em
relao ao Revit oferecer a possibilidade de manuseamento das Property Sets especificas para cada
elemento (Figura 3.13). Desta forma possvel assegurar que determinada propriedade especfica que
se pretende atribuir a um dado elemento transferida aquando da criao do ficheiro de troca IFC,
controlando-se de certa forma a informao que passada para esse ficheiro. A Figura 3.13 mostra um
exemplo de PropertySets aplicveis a um pilar
O Modelo IFC como Agente de Interoperabilidade



36

Figura 3.13 Exemplo de PropertySets aplicveis no Archicad.

3.4.4. TRICALC
No Tricalc no so disponibilizados quaisquer quadros informativos identificando as classes IFC que
so admitidas para exportao e importao, por isso, esta questo poder apenas ser avaliada
aplicando o procedimento para realizao de testes de interoperabilidade definido no ponto 3.3 que
permitir registar os problemas ocorridos na transferncia dos modelos criados.

3.4.5. NIST IFC FILE ANALYSER
O programa IFC File Analyser do NIST constituiu um auxlio na anlise dos ficheiros IFC gerados
em todos os processos de troca via IFC. Revelou ser uma utilidade que constitui uma mais-valia na
anlise dos ficheiros exportados, permitindo contabilizar o nmero de entidades IFC exportadas e mais
do que isso permitindo saber quais os tipos de entidades que foram exportados, suas relaes e
principais atributos atravs da criao de um ficheiro do tipo *.xlsx agrupando os tipos de
informao. Dessa forma, perante a observao de um problema possvel confirmar rapidamente se a
origem desse problema se devia ou no ausncia de uma entidade.

O Modelo IFC como Agente de Interoperabilidade



37

3.5. TESTES DE INTEROPERABILIDADE
Dando-se incio execuo prtica de testes de interoperabilidade, com um estudo num domnio mais
voltado para a definio estrutural, sero elaborados alguns casos de estudo envolvendo os programas
descritos e testando os trs modelos simples j mencionados. Foi ento modelado um pilar [1], um
prtico [2] e uma estrutura porticada [3] para avaliar o fluxo de processos e respectivo mapeamento
que possibilita determinar as capacidades e nveis de interoperabilidade. Procurou-se definir um
material semelhante para todas os elementos estruturais para se verificar se mantida a coerncia de
propriedades, neste caso os materiais foram definidos como sendo de beto. Em anexo apresentam-se
representaes do pilar nos diversos casos para dar uma ideia visual das diferentes situaes.
1) A geometria do pilar criado caracteriza-se por uma seco rectangular 0.20x0.30m e 3 metros
de altura. Sempre que possvel sero aplicadas duas cargas, uma pontual central seco no topo do
pilar (F1= -2,54 kN) e outra linear transversalmente ao pilar ao longo de toda a sua extenso (F2= -
1,64 kN/m). Houve o cuidado de atribuir uma determinada peculiaridade aos valores das foras para
que estas sejam mais fceis de procurar e identificar em futuras trocas de dados, podendo-se assim
rapidamente verificar se essa informao foi ou no transferida correctamente. As foras foram
tambm definidas como sendo diferentes casos de carga, a fora F1 diz respeito a uma carga
permanente enquanto a fora F2 diz respeito a uma aco do vento. Por fim, no domnio das aces,
ter-se- em conta um caso de carga para o estado limite ltimo, denominado Caso de Carga 1, do
tipo Combinao, em que a frmula de clculo ser 1,35 x F1 + 1,50x F2. As caractersticas do
beto a atribuir aos elementos sero aplicadas escolhendo um material pr-definido do programa de
origem que estiver em causa.
2) O prtico tem como funo adicional verificar se a ligao dos elementos pilares e viga
continua a verificar-se depois do modelo ser transferido do software BIM 1 para o software BIM 2.
constitudo por dois pilares de igual seco (0.20x0.30m) cujo os eixos distam 5.5 metros entre si e
uma viga com uma seco 0.20x0.40m que une o topo dos dois pilares. Foi tambm definida uma
carga trapezoidal transversal viga e com sentido vertical descendente, com -5 kN no ponto inicial e -
2 kN no ponto final da viga.
3) Por ltimo a estrutura porticada introduz como informao adicional aos testes de
interoperabilidade anteriores uma laje com 0.22m de espessura e uma carga uniformemente distribuda
nessa laje com sentido vertical descendente e um valor de -4 kN/m. Este modelo tem como principal
funo verificar a ligao entre elementos na troca de dados entre programas, especialmente as
ligaes entre a laje (elementos planos) e os pilares e vigas (elementos lineares) que correspondem s
ligaes mas susceptveis da ocorrncia de erros.

3.5.1. CASO A REVIT ARCHITECTURE PARA ROBOT
3.5.1.1. Via Directa
Conforme pretendido modelou-se as trs estruturas respeitando as seces e dimenses pretendidas,
atribuindo a todas um material pr-definido do Revit, denominado Concrete, Cast-in-Place, Gray
[Propriedades Trmicas (=1x10
-6
/C); Propriedades Mecnicas (=29250.0 MPa; =0.17; G=9964.0
Mpa; =2407.31 kg/m; =0.15); Propriedades Beto (Compresso=24.1 MPa; Shear Strength
Modification=1.0; Yield Strength=2.4 MPa; Tensile Strength=2.4 MPa)].
O Modelo IFC como Agente de Interoperabilidade



38

Usando o modelo de arquitectura do Revit revelada uma incapacidade em adicionar condies de
fronteira, j que os ns no so gerados neste template. O prprio Revit faz uma chamada de ateno
para o facto de que os elementos no se encontram suportados (Figura 3.14).
Figura 3.14 Janela de aviso apresentada pelo Revit Architecture.

Existe a possibilidade de criar cargas e combinaes de cargas, mas estas s estaro relacionadas com
a estrutura se aplicadas no eixo baricntrico da seco rectangular. Esta afirmao resulta do caso
testado experimentalmente, apenas a fora F1 (DL1) aparece representada depois de se fazer a
transferncia para o Robot, a fora F2 (WIND1) perde-se no processo de troca, contudo, mencionada
na combinao que havia sido definida. No teste com o prtico [2] aplicou-se a carga vertical
descendente ao eixo baricntrico da viga, e como esperado a carga foi transferida sem problemas a
relatar.
Para se comprovar melhor este facto, foi colocada uma terceira fora pontual, F3, centrada no topo do
pilar [1], no mesmo ponto de aplicao da fora F1. Ao se exportar o modelo para o Robot as foras
F1 e F3 so identificadas se aplicadas no centro da pea, mas se atribuirmos uma excentricidade
fora F3 em relao ao eixo baricntrico da seco rectangular, esta j no identificada pelo Robot,
sendo contabilizada apenas para efeitos de clculo de combinaes (j definidas no Revit). Por razes
do domnio da programao que no fazem parte do mbito da Engenharia Civil, no possvel apurar
as causas.
Quanto a conexo entre elementos, para se garantir uma correcta passagem da informao por via
directa os elementos devem ser unidos nos pontos centrais, por exemplo, uma viga deve unir o ponto
central de dois pilares. Caso no se proceda desta forma ao transferir o modelo para o Robot os
elementos no aparecero unidos num mesmo n, situao apresentada na Figura 3.15.
Figura 3.15 Desconexo entre apoio, pilar e laje.

O Modelo IFC como Agente de Interoperabilidade



39

3.5.1.2. Via IFC
Posteriormente as estruturas foram exportadas para ficheiros IFC, originando-se ficheiros com
extenso*.ifc que tambm podem ser abertos com a extenso *.txt, apenas para se ter uma noo
da dimenso do ficheiro de texto criado, a definio do pilar [1] pelo Revit gerou 373 instncias IFC.
Ao abrir o ficheiro IFC do pilar no Robot, denota-se que o Robot identifica o pilar e representa-o
genericamente atravs de um eixo onde define ns em ambas as extremidades do elemento, havendo
tambm a possibilidade de visualizar a seco e geometria do pilar. A informao do membro
estrutural foi acrescentada pelo Robot, j que no h indicao especfica de ns nem no ficheiro
inicial criado no Revit, nem no ficheiro IFC em questo.
Quanto s restantes informaes pode dizer-se que apenas a informao geomtrica permanece intacta,
as restantes informaes so suprimidas ou alteradas. Deixam de existir quaisquer informaes acerca
de cargas e grelhas e apenas identificado o nvel onde o pilar est aplicado.
Quanto informao relativa ao material um ponto que merece estudo mais aprofundado, pois no
ficheiro IFC exportado pelo Revit, aparece mencionado no IfcMaterial o material Concrete Cast-in-
Place Concrete mas abrindo esse ficheiro no Robot o material atribudo BETO. Observou-se
tambm que no so definidas nenhumas propriedades fsicas das j referidas que faziam parte das
caractersticas do material. Para se conseguir averiguar qual a fonte que assegura a informao dos
materiais dos elementos ao Robot, investigaram-se as classes que esto directamente relacionadas com
materiais existentes no ficheiro IFC criado, como o caso do IfcMaterial, IfcRelAssociatesMaterial e
IfcMaterialDefinitionRepresentation, excluram-se essas classes e voltou-se a abrir o ficheiro IFC
modificado. Novamente o material que est definido para o pilar o material BETO. Eliminando
as classes onde mencionada a palavra concreto, como o caso das classes IfcCurveStyle,
IfcCurveFont, IfcCurveFontPattern e IfcSurfaceStyle tambm no altera os dados do material e
voltando a abrir no Robot o ficheiro IFC j modificado pela segunda vez, volta-se a verificar que o
material associado ao pilar novamente BETO. Por fim, eliminaram-se todas as classes, excepto
as estritamente necessrias para gerar a representao de um pilar e mais uma vez o material obtido ao
abrir o ficheiro IFC no Robot foi BETO. Apenas para que todas as dvidas fossem dissipadas,
definiu-se o pilar como sendo de madeira, exportou-se para IFC e mais uma vez abriu-se o ficheiro
IFC no Robot, e como j seria de esperar o material definido no era madeira mas sim BETO.
Assim sendo, podemos concluir que o ficheiro IFC gerado pelo Revit, no contm informao acerca
das propriedades fsicas dos materiais e que o Robot atribui aos elementos o material BETO, por
predefinio.

3.5.2. CASO B REVIT STRUCTURES PARA ROBOT
3.5.2.1. Via Directa
Modelando a partir do modelo estrutural do Revit, foram seguidos os mesmo passos que no Caso A
e atribudas as mesmas caractersticas aos elementos estruturais. Destaca-se que agora j possvel
adicionar condies de fronteira e portanto, foram adicionados encastramentos nas bases dos pilares
das trs situaes. Verifica-se que ao transferir o modelo para o Robot a informao acerca dos apoios
correctamente transferida, assim sendo, ao contrrio do ocorrido no Caso A, desta feita a estrutura
no ter problemas de suporte (Figura 3.16).
O Modelo IFC como Agente de Interoperabilidade



40

Figura 3.16 Janela de verificao apresentada pelo Revit Architecture.

Outra das vantagens do modelo Revit Structures a identificao dos elementos tambm atravs da
sua definio analtica, o que por exemplo facilita na visualizao das conexes entre elementos. Desta
forma garante-se uma melhor funcionalidade das ligaes entre os diferentes tipos de elementos, sendo
at possvel atribuir uma certa excentricidade em relao ao eixo baricntrico mantendo-se a ligao.
Como se pode verificar pela Figura 3.17, onde esquerda apresenta-se a ligao com as vigas unidas
directamente ao centro do pilar e na ligao direita uma das vigas apresenta uma pequena
excentricidade nessa ligao mas a sua definio analtica permanece inalterada.
Figura 3.17 Ligao entre elementos.

Outra situao recorrente que gera alguns problemas na ligao entre elementos uma situao que se
origina na criao de uma viga que faz o alinhamento entre mais do que dois pilares. Se para a criao
dessa viga apenas for indicado o pilar que corresponde ao apoio inicial da viga e o pilar que
corresponde ao apoio final da viga, podero no ser estabelecidas ligaes entre os pilares intermdios
e a referida viga. Este problema pode resultar de questes relacionadas com a preciso do modelo.
Pequenas imprecises podero implicar que as barras dos diferentes elementos no se intersectam e
assim no so produzidas as ligaes. A ttulo de exemplo, se tivermos 3 pilares implantados em trs
pontos diferentes, o primeiro implantado no ponto A (0;0), o segundo implantado no ponto B
(0;4,9999999) e o terceiro implantado no ponto C (0;10) e for definida uma viga pela indicao do seu
ponto inicial (A) e ponto final (C), ento o ponto B no ficar conectado com a viga porque h uma
ligeira impreciso que o coloca fora do alinhamento, apesar de formalmente o programa poder at
indicar que o as coordenadas do ponto B so (0;5,0) por uma questo de arredondamentos, induzindo o
utilizador em erro. Por essa razo recomendada a criao de vigas atravs da sucessiva piquetagem
dos pilares onde esta apoia.
O Modelo IFC como Agente de Interoperabilidade



41

A criao de Rigid Links (Figura 3.18) so outra hiptese que soluciona este tipo de problemas. Um
Rigid Link (ou ligao rgida) uma propriedade usada para estabelecer ligaes analticas entre
pilares e vigas, restringindo o movimento relativo entre eles. Em aplicaes de anlise definido
como sendo um elemento infinitamente rgido sem peso. Pelo recurso ao uso de elementos rgidos
soluciona-se este tipo de problemas com relativa facilidade, mas requer que o utilizador esteja sensvel
para estas questes. Quanto s restantes informaes repete-se o sucedido no Caso A.
Figura 3.18 Exemplo de pilares unidos estruturalmente ao eixo analtico da viga atravs de Rigid Links
(representados a verde). (Autodesk 2013)

3.5.2.2. Via IFC
O processo realizado foi idntico ao descrito no Caso A via IFC, com a diferena de que desta vez o
ficheiro IFC gerado contm 373 classes. Contudo nesta verso foram suprimidas as classes
IfcAnnotation e o IfcDraughtingPreDefinedCurveFont. Apesar disso a informao transferida e a
informao perdida foi a mesma que a no Caso A via IFC.

3.5.3. CASO C ROBOT PARA REVIT ARCHITECTURE
3.5.3.1. Via Directa
Uma vez que foram detectados alguns problemas de interoperabilidade na troca de dados criados no
Revit e enviados para o Robot, decidiu-se fazer o processo inverso para se averiguar se desse modo
existe ou no perda de informao. Ao se fazer a troca da informao do Robot para o Revit
Architecture, verifica-se que deixam de existir cargas aplicadas estrutura, bem como as ligaes e os
apoios. Contudo, os dados geomtricos e dos materiais permanecem intactos. Conclui-se portanto que
a possibilidade de definio de cargas no Revit serve apenas para envio para o Robot ou at mesmo
exclusivamente para representao de foras no Revit ou anotao de informaes adicionais mas sem
vista a um clculo no Revit.

3.5.3.2. Via IFC
Verificou-se que atravs do Robot no possvel exportar ficheiros para o IFC, contudo possvel
importar. De um ponto de vista pessoal, esta situao leva a presumir que a Autodesk pretende que a
informao gerada pelo Robot seja de acessibilidade reduzida por outros softwares. Talvez pela grande
presena e influncia que a Autodesk exerce no mercado actual, esta considere que no h necessidade
de assegurar uma boa comunicao com programas concorrentes, optando assim por atribuir aos seus
programas um elevado nvel de inacessibilidade tornando-os bastante isolados ou de comunicao
bastante limitada.

O Modelo IFC como Agente de Interoperabilidade



42

3.5.4. CASO D ROBOT PARA REVIT STRUCTURES
3.5.4.1. Via Directa
Este caso bastante semelhante ao caso anterior, mas apresenta-se como uma variante. Desta feita a
troca de informao foi efectuada entre o Robot e o Revit Structures. Curiosamente verificou-se que
ao contrrio do que se passou no Revit Architecture, aqui perdeu-se a informao relativa ao material.
Uma possvel justificao plausvel para a situao constatada pode residir no facto de que o modelo
de arquitectura do Revit faz a definio do material atravs de uma indicao criada pelo programa
origem do tipo Ifclabel fazendo corresponder um material do mesmo nome, se existente na sua
biblioteca. O modelo de estruturas do Revit no se contenta apenas com a informao do nome do
material, este procura uma definio mais profunda das caractersticas fsicas do material visto ter um
caracter mais voltado para o clculo estrutural, no encontrando nenhum desse tipo de informao no
atribui ou cria qualquer material.
Por outro lado, foram transferidos dados correctamente que no tinham sido possveis de transferir no
Revit Architecture, como foi o caso das ligaes e dos apoios, que neste caso apareceram
correctamente definidos tal como no modelo original do Robot. Quanto s cargas, casos de carga e
combinaes de carga, mais uma vez essa informao foi perdida no processo de troca.

3.5.4.2. Via IFC
As concluses retiradas para o Caso C via IFC so tambm aplicveis para o Caso D via IFC.

3.5.5. CASO E REVIT STRUCTURES PARA REVIT STRUCTURES/ARCHICAD
A melhor forma de se detectar quais os dados que se perdem ao exportar e importar ficheiros IFC para
o Revit criar uma determinada estrutura, export-la para o IFC e abrir esse ficheiro IFC exportado
novamente com o Revit. Deste modo possvel avaliar a quantidade de informao que se perde no
processo. Ao executar este procedimento constata-se que apenas a informao geomtrica
salvaguardada, toda a restante informao deixa de existir ou fica bastante incompleta, como o caso
dos nveis, no ficheiro inicial existiam vrios nveis enquanto agora apenas existe o nvel onde as
estruturas esto implantadas.
A informao referente ao material dos elementos mais uma vez aquela que requer mais ateno. O
material aparece definido e pode-se verificar que se trata do material originalmente atribudo, mas
apenas porque o Revit identifica o nome sugerido na classe IfcSurfaceStyle e procura um material na
sua base de dados que tenha o mesmo nome. Caso encontre um material com o mesmo nome atribui
ao pilar as caractersticas desse material, caso no encontre cria um novo material com o nome
definido nessa classe IFC, mas sem caractersticas e propriedades fsicas definidas. Posto isto fcil
compreender os problemas que esta situao pode comportar, percebe-se que o ficheiro IFC no
contm em si informao sobre as caractersticas fsicas dos materiais, apenas a indicao de qual o
material que deve ser usado pelo programa destino, pelo que deve-se assegurar que o material
mencionado no ficheiro IFC original consta na base de dados de materiais do programa no qual esse
ficheiro ir ser executado e que esse material corresponde ao pretendido.
Para se tentar perceber melhor o mecanismo de interoperabilidade entre o IFC e o Revit no mbito da
definio dos materiais, eliminou-se a classe IfcSurfaceStyle para verificar se deixaria de existir um
material associado aos elementos. Observa-se que na ausncia desta classe o Revit vai buscar a
O Modelo IFC como Agente de Interoperabilidade



43

informao do material ao IfcMaterial, concluso essa que se pode tirar dando diferentes nomes ao
material na classe IfcSurfaceStyle e IfcMaterial, depois constatando o nome escolhido pelo Revit
conclui-se que a classe que d a primeira indicao de qual o material a definir pelo Revit a classe
IfcSurfaceStyle. Na ausncia desta classe a informao dada pelo IfcMaterial. Eliminando tambm o
IfcMaterial consta-se que nenhum material definido para os elementos.
Quanto transferncia de dados entre o Revit Structures e o Archicad, as ocorrncias verificadas
foram semelhantes ao sucedido na transferncia de dados do Revit Structures novamente para o Revit
Structures.

3.5.6. CASO F ARCHICAD PARA TRICALC
Usando-se o Archicad como programa de origem da informao denotam-se algumas limitaes na
introduo de dados, no possvel introduzir condies de apoio, nem aplicar cargas s estruturas,
logo partida no podero ser classificados os nveis de interoperabilidade para estes tipos de dados.
As ligaes entre vigas e pilares so asseguradas pela representao de uma linha que serve de guia na
verificao da correcta posio da ligao pretendida.
Enquanto programa de origem o Archicad tem o benefcio de facilitar a incluso de informaes pela
atribuio de Property Sets aos elementos, o que s por si j revela uma preocupao acrescida em
relao aos outros softwares, de qualquer forma continua a ser insuficiente e nem sempre possibilita
comunicar as informaes pretendidas.
Uma das situaes curiosas do Archicad a possibilidade oferecida de exportao do modelo IFC
consoante o programa destino (Figura 3.19). Visto que o IFC um formato aberto que no estabelece
nenhuma relao de afinidade especfica com nenhum programa, no se compreende o porqu da
diferenciao proposta pelos diferentes tradutores. Nos testes efectuados foi usado o tradutor genrico,
seria necessrio um estudo mais aprofundado para se averiguar quais as diferenas entre os diversos
tradutores.
Figura 3.19 Opes de traduo do modelo IFC usando o Archicad.

Depois de exportados os modelos pelo Archicad, ao se abrir esses modelos com o Tricalc surgem
opes de importao que admitem a escolha de apenas algumas entidades IFC para facilitar a anlise
da estrutura eliminando-se a informao que no necessria para esta etapa. Como se pretende
O Modelo IFC como Agente de Interoperabilidade



44

estudar os nveis de interoperabilidade no se excluiu nenhuma entidade. As trocas efectuadas
concluram que as informaes geomtricas e ligaes foram bem transferidas, os restantes dados
perderam-se no processo de troca.

3.5.7. CASO G TRICALC PARA ARCHICAD/REVIT/ROBOT
Nos testes realizados onde o Tricalc o programa de origem, verificou-se que na importao tanto
com o Archicad, com o Revit ou com o Robot, apenas a informao geomtrica mantida intacta,
todas as outras informaes so transferidas parcialmente ou modificadas. Os materiais mantm o
nome na importao com o Archicad, mas so desprovidos de caractersticas fsicas.

3.5.8. CASO H TRICALC PARA TRICALC
Neste caso, para alm dos trs casos genricos estudados, foram elaboradas duas estruturas, uma
criada recorrendo ferramenta Rede" e outra recorrendo ferramenta Nave, ambas do separador
Geometria" no Tricalc. Depois de exportadas para o IFC, verifica-se que em termos de cdigo e
linguagem IFC a estrutura criada a partir da ferramenta Rede bastante semelhante estrutura
criada usando a ferramenta Nave, mas esta ltima contempla a classe IfcMember. O ficheiro da
estrutura criada usando a ferramenta Rede no comtempla essa classe, mas ainda assim ao voltar-se
a abrir esse ficheiro no Tricalc, os elementos aparecem definidos e representados por um eixo que
define o membro estrutural desses elementos. Esta ocorrncia conduz concluso de que esses
membros so gerados automaticamente pelo Tricalc quando este identifica elementos estruturais,
supe-se que o Tricalc filtre essa informao ao identificar classes que definem a funo dos
elementos, como por exemplo o IfcColumn, IfcBeam, IfcSlab, entre outras.
A troca de informaes com estas estruturas ligeiramente mais complexas que j criam algumas
situaes onde os elementos se desconectam. O Tricalc tem uma ferramenta que permite corrigir este
tipo de situaes (Figura 3.20), mas no possvel afirmar que possibilita a resoluo de todos os
problemas de ligaes porque a complexidade no era ainda muito elevada.
Figura 3.20 Ferramenta de ajuste de ns dos modelos importados para o Tricalc via IFC.

3.5.9. CASO I IFC4 PARA REVIT/ROBOT/ARCHICAD/TRICALC
Neste caso as estruturas modeladas foram criadas directamente a partir de um modelo de texto com
base no esquema IFC4. Nenhum dos programas permitiu a visualizao das estruturas criadas com
este esquema dado ser um esquema ainda bastante recente. Apenas foi possvel visualizar o modelo
usando o programa Constructivity. No Capitulo 4 ser exposta a construo do modelo da estrutura
porticada com algumas alteraes.
O Modelo IFC como Agente de Interoperabilidade



45


3.6. QUADRO RESUMO
Para concluir apresenta-se o quadro resumo de interoperabilidade (Quadro 1), que faz a descrio
sucinta das principais ocorrncias. Note-se que a geometria dos modelos foi sempre correctamente
transferida. A correcta transferncia de dados geomtricos por si s trs j grandes benefcios,
suprimindo a necessidade de remodelao da estrutura. Tratando-se apenas de uma parte da
informao que um modelo BIM pode conter, consegue-se imaginar o potencial que os modelos
teriam se fosse j possvel transferir correctamente entre programas todas as informaes pretendidas.

O Modelo IFC como Agente de Interoperabilidade



46

Quadro 1 Interoperabilidade entre diferentes softwares

Casos Origem Destino
Informao na
Origem
Informao no Destino
Via Directa Via IFC2X3
A
Revit
Architecture
(imagem)
Robot Geometria
Materiais
Ligaes
Apoios
Cargas
Nveis
Geometria
Materiais
Ligaes
Apoios
Cargas
Nveis
T
T
S
S
P
T
Geometria
Materiais
Ligaes
Apoios
Cargas
Nveis
T
P
S
S
N
P
B
Revit
Structures
Robot Geometria
Materiais
Ligaes
Apoios
Cargas
Nveis
Geometria
Materiais
Ligaes
Apoios
Cargas
Nveis
T
T
T
T
P
T
Geometria
Materiais
Ligaes
Apoios
Cargas
Nveis
T
P
T*
N
N
P
C
Robot Revit
Architecture
Geometria
Materiais
Ligaes
Apoios
Cargas
Nveis
Geometria
Materiais
Ligaes
Apoios
Cargas
Nveis
T
T
N
T
N
T
X
X
D
Robot Revit
Structures
Geometria
Materiais
Ligaes
Apoios
Cargas
Nveis
Geometria
Materiais
Ligaes
Apoios
Cargas
Nveis
T
N
T
T
N
T
X
X
E
Revit
Structures
Revit
Structures
Archicad
Geometria
Materiais
Ligaes
Apoios
Cargas
Nveis
-
Geometria
Materiais
Ligaes
Apoios
Cargas
Nveis
T
P
N
N
N
P
F
Archicad Tricalc

Geometria
Materiais
Ligaes
Apoios
Cargas
Nveis
-
Geometria
Materiais
Ligaes
Apoios
Cargas
Nveis
T
P
T*
S
S
P
G
Tricalc Archicad
Revit
Robot

Geometria
Materiais
Ligaes
Apoios
Cargas
Nveis
-
Geometria
Materiais
Ligaes
Apoios
Cargas
Nveis
T
P
N
N
N
P
H
Tricalc Tricalc Geometria
Materiais
Ligaes
Apoios
Cargas
Nveis
-
Geometria
Materiais
Ligaes
Apoios
Cargas
Nveis
T
P
P
N
N
T
I
IFC4 Revit
Robot
Archicad
Tricalc
Geometria
Materiais
Ligaes
Apoios
Cargas
Nveis
X
X -
Informao na Origem: - Introduzida; - No Introduzida
Classificao dos nveis de interoperabilidade da informao: T Transferida; P Parcialmente transferida ou
modificada; N No transferida; S Sem aplicao prtica; X Incompatibilidade;
/ No aplicvel; * Informao adicionada pelo programa destino.
O Modelo IFC como Agente de Interoperabilidade



47





4
4 MODELAO EM IFC
(CASO DE ESTUDO)


4.1. DESCRIO SEMNTICA
Uma linguagem definida usando um conjunto de expresses formadas de acordo com um conjunto
de regras, o que define a gramtica. Conhecendo-se os requisitos gramaticais, o conjunto de regras
inesgotvel, permitindo que a partir do conceito terico uma linguagem tenha a sua prpria
composio e definio estrutural pelo arranjo dos seus componentes, formando uma sequncia de
informao inteligvel. No domnio da linguagem de programao, a descrio de como a linguagem
composta e quais so os seus constituintes definida pela sua sintaxe e semntica, isto , pelas regras
de construo de frases e seu significado, que devem ser especificadas com preciso. A sintaxe vista
como uma compilao livre de contexto, sendo a semntica incumbida de optimizar o cdigo e fazer a
verificao dos tipos. A semntica de uma linguagem de programao e o seu mapeamento
compilada pelo Homem, criando o que se designa muitas vezes por linguagem de cdigo (ou apenas
cdigo), cuja finalidade a execuo computacional, com especial vocao para a repetio e
sistematizao de aces. (Gunter 1992).
No caso da linguagem utilizada pelo padro IFC, o desenvolvimento e manuteno fica a cargo do
Model Support Group (MSG), grupo implementado pela BuildingSMART. Para que uma linguagem
permita a comunicao entre o emissor e o receptor, ambos devem comunicar da mesma forma, na
medida em que o receptor seja capaz de reproduzir com exactido as informaes que lhe foram
emitidas. Aplicando estes conceitos ao caso de estudo em causa, poder-se- dizer que quando o
emissor e o receptor no comunicam na mesma linguagem, o IFC funciona como tradutor, permitindo
um entendimento entre a fonte e o destino. Esta a finalidade que fomenta o IFC, a possibilidade de
troca de informao por meio de uma linguagem comum (Pazlar and Turk 2008).

4.1.1. OBJECTIVOS
O objectivo principal deste captulo descrever a construo das estruturas que foram modeladas a
partir de arquivos de textos simples para criao dos ficheiros IFC (que tambm foram usados nos
testes de interoperabilidade do Capitulo 3), isto , mostrar o encadeamento da linguagem IFC quando
este o prprio emissor. So dadas breves explicaes sobre as definies e termos usados, para
facilitar a compreenso e relaes entre as classes IFC. Uma vez que o estudo do IFC extremamente
vasto, pretende-se com este captulo demonstrar a elaborao de um arquivo IFC que poder
futuramente ser exportado e usado em softwares diversos. Este captulo pretende ento representar um
O Modelo IFC como Agente de Interoperabilidade



48

guia passo-a-passo que facilite e permita a continuao do estudo iniciado, por parte de investigaes
futuras.

4.1.2. PERSPECTIVAS FUTURAS
Nos dias que correm, as tecnologias de informao (TIC) evoluem com elevada celeridade e os
caminhos que seguem esto constantemente associados mudana e incerteza, tornando difcil
determinar com exactido o que se tornar corrente e o que cair no domnio do obsoleto pelo que,
necessrio acompanhar o evoluir das ferramentas e dos processos tecnolgicos o mais prximo
possvel. Seguindo esta filosofia, de entre os vrios esquemas IFC escolheu-se o ltimo esquema IFC4
como esquema de base para a modelao das estruturas elaboradas. Este esquema ainda muito
recente (lanamento oficial em Maro de 2013) e por isso existem ainda muitos entraves sua plena
utilizao, pois a maioria dos softwares, incluindo os mais usados no mercado, ainda no reconhecem
este novo esquema, pelo que de momento ainda no passvel de utilizao nessas ferramentas.
Contudo e apesar das vrias limitaes e barreiras que existem actualmente na aplicao do esquema
IFC4, entendeu-se que na conjuntura da presente dissertao o uso de um esquema IFC2x3 no
permitiria um grande acrscimo de conhecimento para alm do que j existe documentado em outras
dissertaes. A normalizao deste novo esquema IFC4 segundo uma norma ISO (nomeadamente a
ISO 16739:2013) e a sua especial vocao para o ramo estrutural, so pontos fortes seu a favor que
justificam a sua utilizao e que constituem tambm indicadores de que num futuro prximo este
esquema possa ultrapassar a maioria das limitaes dos esquemas anteriores. Estas limitaes referidas
esto na sua maioria relacionadas com o facto de que na situao actual a informao que enviada
para o STEP-file (vulgarmente chamado ficheiro IFC) gerado pelos programas sofre uma espcie de
seleco e triagem da informao, perdendo-se informaes durante o processo de troca, anulando
grande parte do potencial associado ao IFC.
A confirmarem-se estas previses, ter-se- uma entidade externa a todos os programas que ser
verdadeiramente interopervel e de grande viabilidade, tornando o IFC num caminho quase
incontornvel. Entende-se por isso que o IFC4 ser um estmulo para o uso desta linguagem e uma
mais-valia para toda a indstria AEC (Arquitectura, Engenharia e Construo).

4.1.3. IMPLEMENTAO DO IFC4
O surgimento do novo esquema IFC4, formalmente conhecido como IFC2x4, abrange ainda uma
maior rea de trabalho com uma srie de novos recursos que contribuem activamente para uma
melhoria da especificao IFC. O objectivo geral aumentar a coerncia em todo o esquema IFC,
aplicando determinadas mudanas que resultaram da aprendizagem continua e do uso actual,
tornando-o mais consistente e reduzindo o nmero de instncias necessrias para a definio de
determinado tipo de objecto. Como descrito pela BuildingSMART, o IFC4 foi desenvolvido como
sendo a prxima base para o IFC que permitir a interoperabilidade dos Building Information Models
e um standard para o openBIM e foi reforado atravs da norma ISO 16739:2013 que faz a definio
do formato e estrutura de troca BIM que necessria durante o ciclo de vida e fases de construo de
um edifcio, bem como os requisitos das vrias disciplinas envolvidas. A norma inclui informaes
sobre a estrutura do projecto, componentes fsicos, componentes espaciais, itens de anlise, processos,
recursos, controlos, intervenientes e definio do contexto.
Foi implementado um novo conceito de biblioteca onde so definidos todos os tipos de objectos,
famlias ou estilos, e seus atributos que possibilitam a definio de modelos de propriedades a serem
O Modelo IFC como Agente de Interoperabilidade



49

includos num mesmo conjunto de dados do projecto. Os tipos de produtos podem agora ser
decompostos em partes declaradas, que podem ser usadas para a comunicao entre as partes de uma
ocorrncia decomposta, sendo tambm suportado o conceito de cpia de um determinado tipo de
produto para implementao numa estrutura de partes decompostas. Agora a rvore hierrquica das
entidades, que faz a definio das ocorrncias e dos tipos de objectos, para alm de estar sincronizada
com os seus conceitos e definies est tambm sincronizada com tipos de enumeraes pr-definidos
que fazem uma maior especificao das propriedades, nas entidades em que este conceito aplicvel.
Esta rvore hierrquica das entidades pode classificar-se como um catlogo de objectos IFC, que faz o
encadeamento de uma listagem de entidades e suas relaes com sub listagens de definies,
permitindo deste modo fazer um mapeamento externo completo. Na implementao do IFC4 as
definies de componentes de servios e sistemas (do qual o estrutural faz parte), sofreram uma
melhoria significativa que consistiu na extenso do mbito e adopo de uma metodologia de
implementao de entidades de forma mais sistemtica. As melhorias implementadas abrangeram os
elementos de construo, elementos espaciais, construo de sistemas e servios, clculos de energia,
elementos AVAC, sistemas elctricos, modelao estrutural e detalhamento de elementos, anlise
estrutural de elementos, definio de novas propriedades, representao geomtrica, sistemas de
coordenadas, processos, custos, recursos de construo, restries e aprovaes, data e tempo,
materiais, classificaes e especificaes de uso geral. Assim, este catlogo faz parte activa da
indstria AEC (Figura 4.1), permitindo a definio de estruturas de troca que podem suportar e
auxiliar as diferentes vocaes.
Figura 4.1 Sequncia de palavras-chave relacionadas com o IFC

Dado o vasto domnio do IFC, a presente dissertao incidiu sobretudo sobre as reas de modelao
estrutural, anlise estrutural e representao geomtrica. A maioria dos subtipos dos elementos da
construo (tais como sapatas, pilares, vigas, lajes, portas, janelas, etc.) foram separados numa
definio geral e especializao especfica para representao dos casos standard, possibilitando a
troca de dados de forma, materiais e do elemento base que resulta na j mencionada metodologia de
implementao sistematizada. As grandezas de base padronizadas esto agora adicionados
especificao IFC e vlidas para toda a construo. Foram tambm implementados novos Property
Sets para capturar o ambiente atravs de indicadores e foram adicionados valores para os elementos e
tipos de elementos. Dadas as alteraes nesses elementos de construo, a definio de lajes, vigas e
pilares e elementos similares tem sido reforada. A seco geomtrica e informao dos materiais
agora associada aos elementos de construo. As definies da seco esto agora contempladas num
nvel mais alto que a representao geomtrica, podendo tambm ser adicionadas referncia a normas
ou bibliotecas e tambm uma srie de detalhes. No domnio do modelo de anlise estrutural as
O Modelo IFC como Agente de Interoperabilidade



50

alteraes e melhorias efectuadas foram no sentido de fazer a simplificao dos processos. O uso da
representao topolgica e sistema de coordenadas clarificado, bem como uma associao de materiais
e seces atribudas pelos elementos de construo, tornam o modelo mais flexvel e verstil. Para
alm da aplicao de cargas tambm agora possvel a atribuio das foras resultantes e condies de
fronteira (BuildingSMART 2013). Poder-se- encontrar no site da BuildingSMART uma tabela com
informao e lista detalhada das entidades que sofreram alteraes na transio do esquema IFC2x3
para o esquema IFC4.

4.2. CASO DE APLICAO
4.2.1. PROPOSTA
O modelo proposto para modelao a partir da linguagem de cdigo do IFC um modelo que constitui
na sua essncia, informao de definio analtica de pilares, vigas e lajes estruturais e informao de
definio geomtrica de sapatas, pilares, vigas e lajes. Para alm disso contempla tambm informao
mecnica referente definio de algumas propriedades fsicas dos materiais e casos de aplicao de
diversos tipos de cargas estrutura modelada.
Procurou-se ento elaborar um modelo de uma estrutura (Figura 4.2) que de forma simplista fosse
capaz de captar todas estas caractersticas, para dessa forma ser facilmente interpretvel e de fcil
exposio. A estrutura porticada elaborada assemelha-se a um anexo ou uma garagem simples, com
uma definio geomtrica puramente acadmica no tendo sido realizados nenhum tipo de pr-
dimensionamento. A estrutura composta por quatro pilares de seco 0,20x0,30m e 3m de altura
implantados numa malha quadrada cujos vrtices distam entre si 5,50 metros e apoiados sobre sapatas
1,50x2,00x0,75m. As vigas em ambas as direces tm uma seco de 0,20x0,40m, tendo o par de
vigas na direco X uma extenso face a face de 5,20 metros e na direco Y uma extenso de 5,30
metros. Esta diferena de extenses deve-se diferena entre as dimenses das faces dos pilares (j
que estes so rectangulares). A laje tem uma espessura de 0,22m e as suas dimenses correspondem ao
permetro interior formado pelos pilares e pelas vigas, logo 5,30x5,40m.

Figura 4.2 Dimenses de implantao da estrutura porticada.
O Modelo IFC como Agente de Interoperabilidade



51


A definio analtica representada por ns e barras e por isso feita basicamente pela colocao de
vrtices na mesma malha quadrada (5,50x5,50x3,00m) e pela unio desses vrtices por barras que
representam os pilares e vigas da estrutura. possvel associar seces a esses modelos analticos ou
at mesmo elementos geomtricos.
Quanto ao material atribudo aos elementos foi o beto C20/25, do qual se definiram algumas
caractersticas como classe estrutural, classe de exposio, classe de resistncia, recobrimento, etc. e
propriedades fsicas como a densidade, mdulo de cisalhamento e mdulo de elasticidade. Outras
particularidades poderiam ter sido atribudas, mas no era o objectivo principal uma definio
exaustiva dos materiais.
Relativamente s cargas aplicadas estrutura foram definidos diferentes tipos de foras para
demonstrao de alguns casos de carga. Foi ento aplicada uma carga pontual, uma carga linear
uniformemente distribuda, uma carga linear com distribuio trapezoidal e uma carga superficial
uniformemente distribuda.

4.2.2. ELABORAO DO MODELO IFC
A elaborao do modelo criado foi dividido essencialmente em duas partes, uma que define a estrutura
enquanto modelo analtico e outra que define a estrutura do modelo geomtrico. Infelizmente com a
limitao de acesso ao software Constructivity no permite a visualizao do modelo geomtrico e
sendo que este foi o nico programa capaz de abrir o esquema IFC4 a construo do modelo teve
tambm de ser dividida nestas duas partes referidas. A parte que dizia respeito ao modelo analtico foi
elaborada no esquema IFC4 e a verificao visual feita no programa Constructivity Model Viewer
(Figura 4.3), a parte que dizia respeito ao modelo geomtrico foi feita no esquema IFC2x3 e a
verificao visual feita no programa Solibri Model Viewer (Figura 4.4) e s depois ento que se
fez a transposio desse modelo geomtrico criado para o mesmo ficheiro IFC4 onde estava o modelo
analtico (com as devidas ressalvas devido s alteraes que foram feitas em algumas entidades na
transio do esquema IFC2x3 para o IFC4, tambm j mencionadas anteriormente). O cdigo
completo da linguagem usada no modelo IFC poder ser encontrado em anexo.
Faz-se aqui uma chamada de ateno relativamente definio analtica da laje estrutural pois no est
correctamente definida, como se pode ver pela Figura 4.3 a laje aparece representada cota zero ao
invs de estar representada cota trs metros como pretendido. A representao da carga estrutural da
laje tambm definida cota zero pois est associada ao elemento estrutural da laje, apenas no se
tornou essa visualizao activa para que se pudesse identificar a laje no terreno e para no complicar a
visualizao das restantes cargas. A definio analtica revelou-se bastante complexa e o motivo desta
definio incorrecta resulta da limitao do tempo que houve para o estudo destas matrias, no
permitindo aprofundar os conhecimentos em todos os elementos.
O Modelo IFC como Agente de Interoperabilidade



52

Figura 4.3 Visualizao do modelo IFC analtico atravs do Constructivity Model Viewer

Figura 4.4 Visualizao do modelo IFC analtico atravs do Solibri Model Viewer

O Modelo IFC como Agente de Interoperabilidade



53

4.3. ESTRUTURA INTERNA DE FICHEIROS IFC
Para alm de validada pela experimentao prtica, a exposio e demonstrao de aplicao que ser
feita, teve como suporte base a ISO 10303-21:2002 e o site da BuildingSMART.

4.3.1. CONCEITOS BASE
Antes de se abordar a construo dos modelos no formato IFC, deve haver um conhecimento mnimo
sobre os termos e definies que lhe esto associados. Uma vez que j foram oportunamente expostos
no Capitulo 1 alguns conceitos associados ao IFC, importa agora introduzir o modo de funcionamento
de um ficheiro IFC.
A primeira linha e ltima linha de todos os arquivos IFC devem identificar a norma ISO 10303 cujo
objectivo estabelecer procedimentos e linguagem padro para representao, interpretao e troca de
informao, sendo que a primeira linha deve conter a referncia ISO-10303-21 e a ltima a
referncia END-ISO-10303-21. Esta referncia evidncia o formato de um arquivo STEP
definido segundo a ISO 10303-21:2002, onde o formato de troca de dados STEP mais utilizado o
STEP-File, que devido sua estrutura ASCII fcil de ler com tipicamente uma instncia por linha.
Denote-se ainda que a ISO 10303-21 define o mecanismo de codificao na forma de representar os
dados de acordo com um determinado esquema EXPRESS, padro de linguagem para modelao de
dados, baseando-se no EXPRESS mas constituindo uma variante. (ISO 2002).
O corpo de um arquivo que segue esta norma dividido em duas seces, a seco HEADER e a
seco DATA. Para se dar como concluda cada uma destas seces usada uma string com o
comando ENDSEC;. A Figura 4.5 demonstra a forma de elaborao genrica de uma estrutura de
troca de informao de um ficheiro STEP, como foi supracitado.
Figura 4.5 Estrutura tipo de um ficheiro STEP (Nour 2008)

A seco HEADER tem uma estrutura fixa, podendo ser constituda por 6 grupos, sendo que todas as
estruturas de troca devem conter os grupos FILE_DESCRIPTION, FILE_NAME,
FILE_SCHEMA e devem aparecer na ordem pela qual sero abaixo descritos. Instncias dos grupos
FILE_POPULATION, SECTION_LANGUAGE e SECTION_CONTEXT podem aparecer depois
do FILE_SCHEMA apenas em arquivos de segunda edio. Nesta seco todos os campos podem
incluir strings vazias, excepto o grupo FILE_SCHEMA e os dados no campo time_stamp que
est includo no grupo "FILE_NAME (ISO 2002).
FILE_DESCRIPTION - atribui informao acerca da definio de visualizao base e
tambm o nvel de implementao, que identifica a especificao com a qual a codificao na estrutura
ISO-10303-21;
HEADER;

ENDSEC;
DATA;

ENDSEC;
END-ISO-10303-21;
O Modelo IFC como Agente de Interoperabilidade



54

de troca conforma (correntemente 2,1 para todos os ficheiros IFC, para mais informaes
recomenda-se a consulta da ISO 10303-21).
FILE_NAME - regista o nome do ficheiro IFC (podendo corresponder ao nome do arquivo
num sistema de arquivos ou retractar os dados nesse arquivo), a data de criao do ficheiro (o tempo
definido no formato internacional segundo a ISO 8601), o nome do autor e organizao a que
pertence, a aplicao na qual o ficheiro foi criado e autorizao (nome e endereo da pessoa que
autorizou o arquivo).
FILE_SCHEMA Especifica um esquema EXPRESS ou vrios no caso de arquivos de
segunda edio. Um esquema um modelo de dados legvel por um sistema informtico, que descreve
conjuntos de tipos de dados e suas relaes.
FILE_POPULATION Indica uma populao vlida (conjunto de instncias de entidade) em
conformidade com o esquema EXPRESS. Isto feito atravs de recolha de dados a partir de vrias
seces de dados.
SECTION_LANGUAGE Identifica a linguagem predefinida para os valores das strings na
seco dos dados. O nome da linguagem deve aparecer codificado segundo a norma ISO 639, no
campo de atributo default_language. Isto necessrio para os esquemas EXPRESS que no possuem a
capacidade de especificar em que lngua esto definidas as entidades e os seus atributos.
SECTION_CONTEXT Identifica informaes que descrevem os contextos nos quais so
aplicveis as instncias codificadas na estrutura de troca.

A seco DATA contm dados de aplicativos de acordo com um esquema EXPRESS especfico,
nesta seco que as entidades so atribudas ao ficheiro IFC. Quando se trabalha directamente com o
esquema EXPRESS numa ferramenta de edio de texto, inevitvel falar-se em entidades (ou
classes), pois no domnio IFC, so as entidades que definem os comandos e aces capazes de criar
informao.
Uma entidade tem uma estrutura bastante prpria, mostrada na Figura 4.6 e exemplificada na Figura
4.7. reconhecida no ficheiro IFC pelo seu identificador nico que deve ser um nmero inteiro
positivo (> 0), na forma #nmero. A finalidade e funo dessa entidade identificada pelo seu
nome, que representado por letras maisculas no cdigo IFC. Repare-se que o nome dessa entidade
apenas vlido dentro desse ficheiro IFC, pois se o contedo deste for exportado para um novo sistema,
mesmo que no se efectuem quaisquer alteraes, ao voltar-se a exportar o ficheiro para o IFC a partir
desse sistema, verifica-se que o cdigo do ficheiro alterado, ou seja, h uma alterao e modificao
das entidades para as mesmas instncias. O nome da instncia usado tambm para referenciar outras
entidades atravs de valores atribudos ou membros agregados (atributo inverso), sendo que a instncia
referenciada poder ser definida antes ou depois da instncia onde referida. Por fim as definies de
atributos atribuem caractersticas entidade IFC em causa. Os valores e definies desses atributos
variam de entidade para entidade, pois definem parmetros prprios para cada uma das diferentes
entidades. Como j foi referido, esses parmetros so definidos a priori pelo MSG (Model Support
Group). Uma lista completa das entidades existentes, com links individuais que fazem a respectiva
ligao pgina que especifica a funo, construo e relaes de cada entidade pode ser encontrada
em:
http://www.buildingsmart-tech.org/ifc/IFC4/final/html/annex/annex-b/alphabeticalorder_entities.htm

O Modelo IFC como Agente de Interoperabilidade



55

Figura 4.6 Organizao de uma entidade. Adaptado de (Nour 2008)

#224= IFCSTRUCTURALPOINTCONNECTION ('2GClK7cwT80xzpZuaAlGXp',#5,'Point
Connection 1',$,$,$,#223,#225,$)
Figura 4.7 Exemplo de uma entidade.

A sequncia pela qual as entidades aparecem descriminadas na construo de um dado texto em
cdigo no corresponde obrigatoriamente ordem pela qual sero identificadas pelo programa destino,
isto significa que, em duas linhas de cdigo consecutivas, a segunda string no tem necessariamente
que depender ou ter alguma relao com a primeira. O IFC um sistema de digitao solto que
fornece mltiplos caminhos para introduo de objectos e no segue uma orientao especfica,
permitindo a criao de vrios encadeamentos lgicos, dando assim grande flexibilidade e suporte a
mltiplas representaes (ISO 2002).
A ttulo de exemplo, um conjunto de pilares no tm necessariamente que estar definidos por alguma
ordem em concreto, isto permite grande versatilidade na introduo ou remoo de entidades
consoante as necessidades do utilizador, para alm disso, os pilares podem partilhar a mesma seco,
material ou outras caractersticas que possam ter em comum, possibilitando assim uma eficincia na
utilizao e organizao de entidades que resulta numa diminuio do tamanho do ficheiro IFC.
Ento, na construo de um cdigo IFC no existe um nico caminho ou uma sequncia obrigatria,
os caminhos de leitura das entidades so definidos pela sua indexao e hierarquizao dentro de uma
camada e pelas suas relaes de atributos. Portanto o IFC dividido em camadas, alis como j foi
apresentado no Capitulo 2 (Domnios Elementos Partilhados Nuclear Recursos) e dentro da
camada de recursos que se encontram os esquemas de dados que suportam as estruturas de dados do
modelo. As entidades mais genricas encontram-se dentro dessa camada, mas podem ser referenciadas
por todas as entidades do modelo. Como o IFC define relaes entre as entidades baseado no formato
EXPRESS, as centenas de entidades so organizadas numa cadeia hierrquica baseada nos objectos.
As entidades so separadas genericamente em dois tipos, as que derivam directamente do IfcRoot
(identificadas pelo GUID e com possibilidade de atribuio de IfcOwnerHistory, nome e descrio) e
as que existem se forem associadas directa ou indirectamente s primeiras (no so identificadas
atravs do GUID).
Para que um objecto possa ser identificado quer pelo operador quer por um sistema de processamento
automtico, necessita de um identificador. A especificao IFC usa um identificador nico para
instncias de objectos denominado Globally Unique Identifier (GUID) que segue o Universal Unique
Identifier Standard (UUID) como definido na ISO/IEC 11578:1996. O GUID gerado para uma
instncia do ficheiro de troca comprimido segundo uma frmula de compresso que tem como base
#nnnnnnnnn= IFCxxxxx (atributo1,atributo2,,atributoN);
Identificador nico
(mximo 9 digitos)
Nome da
entidade IFC no
esquema
EXPRESS
Valores dos atributos da entidade. Em determinadas
situaes, um atributo pode mais do que um valor.
O Modelo IFC como Agente de Interoperabilidade



56

uma codificao de 64 caracteres (Figura 4.8) e que resulta num identificador de 22 caracteres,
podendo a sua introduo ser automtica ou manual. Permite fazer a identificao de um objecto
independentemente da aplicao que est a ser usada, sendo desse modo possvel a sincronizao entre
programas que potencialmente oferece a possibilidade de alterao dos aspectos dos objectos por parte
de outros utilizadores, ou seja, desse modo possvel coordenar os diferentes nveis de objectos em
diferentes sistemas. (Eastman et al. 2011).

Figura 4.8 Codificao base de 64 caracteres para a formulao de um IFC-GUID. (BuildingSMART 2013)

Resumidamente, para evitar possveis confuses entre as funes de um GUID e de um Identificador
nico, o GUID permite a identificao de objectos nas relaes de interoperabilidade entre sistemas,
mantendo-se inalterado na realizao dessas trocas e permitindo dessa forma a identificao de
elementos na estrutura da linguagem IFC, como demonstrado na Figura 4.9. O identificador nico de
uma entidade apenas reconhecido dentro dessa estrutura de cdigo de um dado ficheiro IFC, sendo
usado para fazer nomear entidades e fazer relaes por atributos (Firmenich et al. 2006).
Figura 4.9 Correspondncia entre o GUID no ficheiro IFC e no visualizador Solibri

O IfcRoot a classe mais abstracta e a raiz de todas as definies das entidades IFC, sendo o supertipo
de forma directa do IfcObjectDefinition, IfcPropertyDefinition e IfcRelationship (so denominadas
classes subtipo do IfcRoot), entidades que por sua vez tambm constituem o supertipo de outras
entidades e assim sucessivamente. Resumidamente atravs desta identificao e relao entre as
entidades supertipo e subtipo e pela classificao dos atributos (directo, inverso e derivado) que se
O Modelo IFC como Agente de Interoperabilidade



57

definem as cadeias de classes e o seu seguimento lgico, possibilitando a leitura do cdigo pelo
programa destino (BuildingSMART 2013).
Tem-se ento um modelo IFC que segue uma filosofia baseada nos Semantic Exchange Modules
(SEM), que se apresenta como um modelo de desenvolvimento por mdulos destinado a facilitar a
visualizao do modelo e tambm a reutilizao das entidades. Um SEM um subconjunto modular
estruturado de objectos e relaes necessrias para definir cada um dos mltiplos modelos de troca
BIM. O seu objectivo permitir que as empresas de software na rea dos BIM consigam importar e
exportar informao de cdigo atravs de mdulos, para que uma dada informao ao ser exportada ou
importada possa ser testada e certificada uma vez e depois possa ser reutilizada em mltiplos ficheiros
de troca sem que haja necessidade de modificao. Um SEM pode ser visto como uma ligao a um
conjunto de entidades IFC, seus atributos, relaes e funes. O mbito do SEM deve ser determinado
conjuntamente com a equipa que desenvolve o software, visto que devem fazer atribuies no s ao
modelo de troca, mas tambm aos objectos internos do esquema da ferramenta. A semntica nas reas
de engenharia e design particular no sentido que define uma mistura entre especificaes parciais da
realidade, comportamentos e funcionamento expectveis dessa realidade e os seus prprios sistemas
fsicos. A semntica tambm necessria para fazer a distino entre definies e objectos dentro de
um domnio. O IFC oferece um esquema que faculta instncias de especificaes quer dos projectos de
edifcios, quer dos edifcios reais. Os edifcios so constitudos por distintos sistemas de diferentes
vocaes cuja definio obriga existncia das suas prprias entidades, bem como entidades
partilhadas. Isto implica e significa que h mais do que uma forma de representar determinada
informao num ficheiro de troca. Vrias relaes tm como domnio o IfcRoot, que bastante amplo
e no restringe o uso das relaes. J vasto o conjunto de entidades que fazem parte do IFC, mas
existem reas de trabalho que ainda no foram identificadas no IFC em forma de classes, tendo esse
trabalho sido deixado para esquemas IFC futuros. Para se ultrapassar esta situao necessrio
amplificar o uso do IFC e nesse sentido que surge a normalizao do IFC4, com o intuito de tornar o
IFC ainda mais aplicvel e num mbito mais alargado. (Venugopal 2011).

4.3.2. SIMBOLOGIA USADA
Existem alguns caracteres especiais usados na construo de ficheiros IFC, aos quais so atribudas
funes especficas (Lehrenfeld, Mueller, and Wiechers 1993), os principais usados so:
# Usado antes de um nmero inteiro para que esse nmero seja definido como o
identificador nico de uma entidade.
$ Valor indefinido.
* Atributo omisso.
, A vrgula faz a separao entre os diferentes atributos de uma dada entidade. Para
representao de nmeros decimais no se usa a vrgula , mas sim o ponto . .
'' O contedo definido entre dois apstrofos geralmente texto alfanumrico, normalmente
elaborado para ser facilmente interpretado.
Exemplo: #202= IFCGEOMETRICREPRESENTATIONCONTEXT ('3D','Model',3,
0.00001,#200,$);
. . Um atributo definido entre dois pontos representa um atributo do tipo enumerao e
deve ser escrito em letras maisculas. Se atribudo, deve corresponder obrigatoriamente a uma
O Modelo IFC como Agente de Interoperabilidade



58

enumerao pr-definida. As enumeraes respectivas a uma entidade (no caso desta necessitar de
alguma) podem ser encontradas em http://www.buildingsmart-tech.org.
Exemplo: #5= IFCOWNERHISTORY (#4,#2,.READWRITE.,.NOCHANGE.,$,$,$,
1320677205);
http://www.buildingsmart-
tech.org/ifc/IFC4/final/html/schema/ifcutilityresource/lexical/ifcstateenum.h
tm

( ) Os parntesis delimitam os atributos de uma dada entidade. Se reutilizados dentro da
prpria seco de atributos, possibilitam a colocao de um ou mais valores num nico atributo de
uma entidade.
Exemplo: #190= IFCPROJECT ('0QjBRF7yLCTh4HRF3GOF1t',#6,'Project',$,$,
$,$, (#202,#203),#160);
/* */ - Permite a adio de comentrios, observaes ou anotaes ao texto em linguagem
IFC. As informaes contidas entre /* exemplo */, no tm significado para o cdigo e por isso
no so lidas pelos programas de destino.
Exemplo: /* Dados do usurio, organizao e da aplicao */

4.3.3. ANLISE E EXPOSIO DA CRIAO DE UM FICHEIRO IFC
Depois de introduzidas as consideraes iniciais que devem estar presentes quando se trabalha com a
linguagem IFC, feita agora a anlise da criao de um ficheiro IFC, cuja exposio ser feita
modularmente. Note-se que a organizao que foi atribuda s entidades que constituem o ficheiro IFC
em nada influncia ou altera a sua leitura por parte dos softwares, como j foi mencionado a
organizao do ficheiro IFC feita pela hierarquizao das entidades, no pela sua ordem no texto de
cdigo. Este arranjo na organizao do cdigo do ficheiro IFC apenas serve para tornar a linguagem
humanamente mais legvel, facilitando a leitura ao utilizador. Mais uma vez se refere que a modelao
em linguagem IFC teve como base principal o grupo de suporte e implementao do modelo IFC da
BuildingSMART que inclui uma biblioteca de entidades e suas relaes, tornando assim possvel
encontrar todas as informaes necessrias para modelar os elementos estruturais que sero
apresentados. Essa biblioteca de entidades est publicada no formato HTML, com listas de todos os
tipos definidos, enumeraes e tipos de entidades, listadas por ordem alfabtica, compiladas num
documento de navegao, com uma organizao em rvore segundo que constitui uma lista
hierrquica entre supertipos e subtipos.
Refere-se novamente que a investigao e pesquisa das entidades para a definio da estrutura
porticada que ser exposta, foi usado o programa Constructivity com o qual se foi abrindo
periodicamente o ficheiro IFC do modelo que se estava a criar, para se ter a certificao de que o
cdigo estava a ser correctamente implementado. A verso do programa que foi utilizada foi uma
verso de licena temporria com inmeras funcionalidades indisponveis, sendo que foi apenas
utilizado como visualizador do modelo analtico da estrutura. Para fazer a visualizao do modelo
arquitectnico criou-se um modelo IFC2x3 em paralelo ao original, contendo apenas as classes
arquitectnicas que deste modo poderia ser visualizado com o programa Solibri Model Viewer e
fazer-se assim a verificao de todo o modelo.
O Modelo IFC como Agente de Interoperabilidade



59

O exemplo que se segue diz respeito a uma estrutura porticada. A preocupao central foi a definio
estrutural dos elementos, mas tambm foi definido o modelo arquitectnico da estrutura, sendo depois
feito o relacionamento entre classes estruturais e classes arquitectnicas.

4.3.3.1. HEADER
Como em todos os ficheiros IFC, o primeiro passo a tomar construir ou preencher a seco
HEADER, com informao geral acerca do ficheiro e do criador, ou seja, informao relevante para
todo o ficheiro global, que deve ser atribuda segundo as indicaes que foram j supracitadas. Serve
de exemplo a Figura 4.10 e a Figura 4.11 que mostra a seco HEADER que faz parte do modelo IFC
criado.
HEADER;
FILE_DESCRIPTION (('ViewDefinition [CoordinationView]'),'2;1');
FILE_NAME ('ModeloIFC.ifc','2013-04-03T10:54:01','Srgio Pinho','FEUP',
'BIM','Notepad++',$);
FILE_SCHEMA (('IFC4'));
ENDSEC;
Figura 4.10 Modelo IFC - Seco HEADER do modelo IFC criado.

HEADER;
FILE_DESCRIPTION (("Descrio"),"Nvel de implementao");
FILE_NAME ("Nome","Data","Autor","Organizao","Sistema","Aplicao",
"Autorizao");
FILE_SCHEMA (("Esquema EXPRESS"));
ENDSEC;
Figura 4.11 Aplicao - Seco HEADER do modelo IFC criado.

4.3.3.2. DATA Dados do utilizador e da aplicao
Concluda a seco HEADER segue-se a seco DATA, seco onde se dispe a linguagem de cdigo
propriamente dita. Por uma questo de metodologia, facilidade de trabalho e encadeamento lgico, as
entidades discriminadas na seco DATA esto organizadas por mdulos (grupos), pelo agrupamento
de informao de natureza semelhante ou que contribui para uma mesma finalidade. O primeiro grupo
introduzido no ficheiro IFC em questo contem as instncias que introduzem as informaes
relacionadas com o usurio, dados da aplicao e tambm da organizao (Figura 4.12 e Figura 4.13).
Novamente refere-se que a seco DATA tem obrigatoriamente que iniciar-se com a string DATA;.
DATA;

/* Dados do usurio, da organizao e da aplicao */
#1= IFCORGANIZATION ($,'Sergio-PC','FEUP',$,$);
#2= IFCAPPLICATION (#1,'1.0','IFC4','Made via Notepad++');
#3= IFCPERSON ($,$,'Sergio',$,$,$,$,$);
#4= IFCPERSONANDORGANIZATION (#3,#1,$);
#5= IFCOWNERHISTORY (#4,#2,.READWRITE.,.NOCHANGE.,$,$,$,1320677205);
Figura 4.12 Modelo IFC - Dados do usurio, da organizao e da aplicao

#n= IFCORGANIZATION ("Identificao","Nome","Descrio","Cargo","Morada");
#n= IFCAPPLICATION ("Distribuidor da Aplicao","Verso","Nome da
Aplicao","Idenficador da Aplicao");
O Modelo IFC como Agente de Interoperabilidade



60

#n= IFCPERSON ("Identificao","Nome de familia","Nome prprio","Nome
central","Ttulo prefixo","Ttulo sufixo","Cargo","Morada");
#n= IFCPERSONANDORGANIZATION ("Pessoa","Organizao","Cargo");
#n= IFCOWNERHISTORY ("Utilizador proprietrio","Proprietrio da aplicao",
"Estado","Tipo de Modificaes","Data da ltima
modificao","Utilizador na ltima modificao",
"Aplicao usada na ltima modificao","Data de criao");
Figura 4.13 Aplicao - Dados do usurio, da organizao e da aplicao

A Figura 4.13 fornece os dados necessrios para uma definio completa das entidades usadas na
Figura 4.12. Para facilitar a compreenso da exposio das entidades foram adoptadas algumas regras
que sero usadas em todo o capitulo. As entidades com um maior avano na linha so entidades que
tm como atributo inverso uma outra entidade que est mais recuada, este princpio serve apenas para
melhor demonstrar o encadeamento entre as classes num grupo. Os atributos marcados a sublinhado
so atributos cuja atribuio opcional, podero ou no ser definidos (um atributo opcional
representado por um $, valor indefinido). Tambm foi adoptado um esquema de cores que
permitisse uma fcil e rpida identificao dos tipos de atributos mais usados. Os atributos do tipo
IfcText contm informao alfanumrica legvel para o ser Humano com a funo meramente
informativa. J os atributos do tipo IfcLabel so usados para definir o termo de algo a que se referem e
representam tambm linguagem humanamente interpretvel. O IfcIdentifier tem a funo de identificar
elementos ou objectos atravs de informao alfanumrica normalmente gerada pelo sistema
informtico e legvel apenas para este, em contraste com o IfcLabel e o IfcText.
Tomando a classe #2 = IfcApplication como exemplo, nela podem ser encontrados atributos directos
e um atributo inverso. Como atributo directo tem-se por exemplo a informao Made via
Notepad++ e como atributo indirecto tem-se #1. Como se pode ver pela Figura 4.12 quando o
nmero identificador de uma entidade colocado dentro da seco de atributos de uma outra, feita
uma ligao entre entidades que funciona como uma espcie de link. Uma das entidades mais
importantes deste grupo a IfcOwnerHistory, que especifica informao relacionada com a
identificao e historial da aplicao. Para tornar o seu acesso rpido, esta entidade poder estar
directamente indexada em todos os objectos independentes, relaes e propriedades.

4.3.3.3. DATA Pontos cartesianos e direces
Recomenda-se que entre os vrios grupos da seco DATA haja uma quebra numrica na numerao
das entidades, desse modo no caso de surgir a necessidade de fazer a implementao manual de novas
classes num determinado grupo possvel manter o ficheiro IFC arrumado.
O prximo passo foi colocar os pontos cartesianos que correspondem ao ponto de origem, em
referenciais bidimensionais e tridimensionais, para futura colocao de eixos cartesianos na definio
de objectos (Figura 4.14 e Figura 4.15). Tambm foram colocadas direces que permitiram atribuir
orientao a objectos segundo um determinado eixo, quer bidimensionalmente para orientao de
planos, ou tradicionalmente para orientao de elementos.

/* Pontos cartesianos e direces */
#7= IFCCARTESIANPOINT ((0.,0.,0.));
O Modelo IFC como Agente de Interoperabilidade



61

#8= IFCCARTESIANPOINT ((0.,0.));
#9= IFCDIRECTION ((1.,0.,0.));
#10= IFCDIRECTION ((-1.,0.,0.));
#11= IFCDIRECTION ((0.,1.,0.));
#12= IFCDIRECTION ((0.,-1.,0.));
#13= IFCDIRECTION ((0.,0.,1.));
#14= IFCDIRECTION ((0.,0.,-1.));
#15= IFCDIRECTION ((1.,0.));
#16= IFCDIRECTION ((-1.,0.));
#17= IFCDIRECTION ((0.,1.));
#18= IFCDIRECTION ((0.,-1.));
Figura 4.14 Modelo IFC Pontos cartesianos e direces.

#n= IFCCARTESIANPOINT (("Coordenada X"," Coordenada Y"," Coordenada Z"));
#n= IFCCARTESIANPOINT (("Coordenada X "," Coordenada Y"));
#n= IFCDIRECTION (("Direo X","Direo Y","Direo Z"));
#n= IFCDIRECTION (("Direo X","Direo Y"));
Figura 4.15 Aplicao - Pontos cartesianos e direces.

4.3.3.4. DATA Unidades
Identificados os dados do usurio e da aplicao e os pontos na origem e direces principais segundo
os eixos coordenados, procede-se definio das unidades que sero ou podero ser usadas no ficheiro
IFC (Figura 4.16 e Figura 4.17). A lista de unidades aplica-se a todos os valores de medida dentro do
arquivo ( definida globalmente), por exemplo, a unidade de comprimento usada na geometria ser o
metro (#28), os ngulos sero medidos em graus (#43), o peso em quilogramas (#36), etc. As unidades
podem ser classificadas como grandezas fundamentais (primitivas) ou derivadas. As grandezas
fundamentais que no dependem de outras para serem definidas so sete e so elas o comprimento,
massa, tempo, intensidade de corrente elctrica, intensidade luminosa, temperatura termodinmica e
quantidade de matria. As grandezas derivadas so definidas por relao entre grandezas
fundamentais.
/* Unidades */
#20= IFCSIUNIT (*,.AREAUNIT.,$,.SQUARE_METRE.);
#21= IFCSIUNIT (*,.FORCEUNIT.,$,.NEWTON.);
#28= IFCSIUNIT (*,.LENGTHUNIT.,$,.METRE.);
#36= IFCSIUNIT (*,.MASSUNIT.,.KILO.,.GRAM.);
#40= IFCSIUNIT (*,.PLANEANGLEUNIT.,$,.RADIAN.);
#41= IFCMEASUREWITHUNIT (IFCPLANEANGLEMEASURE(0.0174532925199433),#40);
#42= IFCDIMENSIONALEXPONENTS (0,0,0,0,0,0,0);
#43= IFCCONVERSIONBASEDUNIT (#42,.PLANEANGLEUNIT.,'DEGREE',#41);
#45= IFCSIUNIT (*,.PRESSUREUNIT.,$,.PASCAL.);
#56= IFCSIUNIT (*,.VOLUMEUNIT.,$,.CUBIC_METRE.);
#57= IFCSIUNIT (*,.TIMEUNIT.,$,.SECOND.);
#58= IFCSIUNIT (*,.THERMODYNAMICTEMPERATUREUNIT.,$,.DEGREE_CELSIUS.);
#59= IFCSIUNIT (*,.LUMINOUSINTENSITYUNIT.,$,.LUMEN.);
#96= IFCDERIVEDUNITELEMENT (#21,1);
#97= IFCDERIVEDUNITELEMENT (#28,-1);
#98= IFCDERIVEDUNIT ((#96,#97),.LINEARFORCEUNIT.,$);
#99= IFCDERIVEDUNITELEMENT (#21,1);
#100= IFCDERIVEDUNITELEMENT (#28,1);
#101= IFCDERIVEDUNITELEMENT (#28,-1);
#102= IFCDERIVEDUNIT ((#99,#100,#101),.LINEARMOMENTUNIT.,$);
#103= IFCDERIVEDUNITELEMENT (#21,1);
#104= IFCDERIVEDUNITELEMENT (#28,-1);
#105= IFCDERIVEDUNIT ((#103,#104),.LINEARSTIFFNESSUNIT.,$);
#112= IFCDERIVEDUNITELEMENT (#36,1);
O Modelo IFC como Agente de Interoperabilidade



62

#113= IFCDERIVEDUNITELEMENT (#56,-1);
#114= IFCDERIVEDUNIT ((#112,#113),.MASSDENSITYUNIT.,$);
#118= IFCDERIVEDUNITELEMENT (#36,1);
#119= IFCDERIVEDUNITELEMENT (#28,-1);
#120= IFCDERIVEDUNIT ((#118,#119),.MASSPERLENGTHUNIT.,$);
#121= IFCDERIVEDUNITELEMENT (#45,1);
#122= IFCDERIVEDUNIT ((#121),.MODULUSOFELASTICITYUNIT.,$);
#140= IFCDERIVEDUNITELEMENT (#28,4);
#141= IFCDERIVEDUNIT ((#140),.MOMENTOFINERTIAUNIT.,$);
#142= IFCDERIVEDUNITELEMENT (#21,1);
#143= IFCDERIVEDUNITELEMENT (#20,-1);
#144= IFCDERIVEDUNIT ((#142,#143),.PLANARFORCEUNIT.,$);
#147= IFCDERIVEDUNITELEMENT (#36,1);
#148= IFCDERIVEDUNITELEMENT (#20,-1);
#149= IFCDERIVEDUNIT ((#147,#148),.ROTATIONALMASSUNIT.,$);
#150= IFCDERIVEDUNITELEMENT (#21,1);
#151= IFCDERIVEDUNITELEMENT (#28,1);
#152= IFCDERIVEDUNITELEMENT (#43,-1);
#153= IFCDERIVEDUNIT ((#150,#151,#152),.ROTATIONALSTIFFNESSUNIT.,$);
#154= IFCDERIVEDUNITELEMENT (#28,5);
#155= IFCDERIVEDUNIT ((#154),.SECTIONAREAINTEGRALUNIT.,$);
#156= IFCDERIVEDUNITELEMENT (#28,3);
#157= IFCDERIVEDUNIT ((#156),.SECTIONMODULUSUNIT.,$);
#158= IFCDERIVEDUNITELEMENT (#45,1);
#159= IFCDERIVEDUNIT ((#158),.SHEARMODULUSUNIT.,$);
#160= IFCUNITASSIGNMENT ((#20,#21,#28,#36,#43,#45,#56,#98,#102,
#105,#114,#120,#122,#141,#144,#149,
#153,#155,#157,#159));
Figura 4.16 Modelo IFC - Unidades

#n = IFCSIUNIT ("Tipo de unidade","Prefixo","Nome");
#n = IFCMEASUREWITHUNIT ("Valor fsico expresso em unidades especificas",
"Unidades em que o valor fsico expresso");
#n = IFCDIMENSIONALEXPONENTS ("Exponente de comprimento"," Exponente de massa"
,"Exponente de tempo"," Exponente de corrente
eltrica"," Exponente de temperatura
termodinmica","Exponente de matria","Exponente
de intensidade luminosa");
#n = IFCCONVERSIONBASEDUNIT ("Exponentes dimensionais","Tipo de unidade",
"Nome","Factor de Converso");
#n = IFCDERIVEDUNITELEMENT ("Unidade","Exponente");
#n = IFCDERIVEDUNIT ("Grupo de unidades que define a unidade derivada","Tipo
de unidade","Tipo definido pelo utilizador");
#n = IFCUNITASSIGNMENT ("Unidades");
Figura 4.17 Aplicao - Unidades

Para se definir uma unidade que no faa parte do sistema SI, necessrio fazer a respectiva
converso atravs do IfcConversionBaseUnit. Tomando como exemplo a converso de radianos para
graus apresentada na Figura 4.18, primeiro faz-se a identificao da unidade a converter com a
entidade IfcSIUnit (radianos), depois identifica-se a quantidade dessa unidade que corresponde ao
valor unitrio da unidade para a qual se pretende fazer a converso (graus), especificando o tipo de
medio que necessrio efectuar com a classe IfcMeasureWithUnit (medio angular 0.01745329
rad 1). De seguida definem-se os exponentes dimensionais com o IfcDimensionalExponents onde
neste caso todos os exponentes so nulos pois o grau uma medida adimensional. Por fim juntam-se
todas as propriedades no IfcConversionBasedUnit, que faz a converso das unidades com informao
calculada a partir de outros atributos, usando expresses definidas.
O Modelo IFC como Agente de Interoperabilidade



63

#40= IFCSIUNIT (*,.PLANEANGLEUNIT.,$,.RADIAN.);
#41= IFCMEASUREWITHUNIT (IFCPLANEANGLEMEASURE(0.0174532925199433),#40);
#42= IFCDIMENSIONALEXPONENTS (0,0,0,0,0,0,0);
#43= IFCCONVERSIONBASEDUNIT (#42,.PLANEANGLEUNIT.,'DEGREE',#41);
Figura 4.18 Exemplo Converso de unidades.

As unidades de grandezas fundamentais ficam a cargo da entidade IfcSIUnit, quanto s unidades de
grandezas derivadas necessitam de pelo menos duas entidades para fazer a sua definio, uma ou mais
entidades IfcDerivedUnitElement e uma IfcDerivedUnit que define a relao entre as unidades
fundamentais e o tipo de unidade derivada em que resulta essa relao, como demonstrado na
Figura 4.19.
O Pascal [Pa] exemplo de uma unidade de grandeza derivada. uma unidade padro de presso e
tenso no sistema internacional de unidades (SI). Equivale fora de 1 Newton [N] aplicada
uniformemente sobre uma superfcie de 1 m, logo Pa = [N/m]. Para se definir esta unidade derivada
atravs do uso de entidades, primeiro identificam-se quais as instncias que possuem as unidades
fundamentais necessrias (#20 m; #21 N) e seus exponentes no IfcDerivedUnitElement. O sinal
positivo num exponente define a unidade em numerador (1 N) e o sinal negativo no exponente
define a unidade em denominador (-1 m). Para concluir a construo da unidade derivada
utiliza-se o IfcDerivedUnit que faz a juno das unidades fundamentais, multiplicando as unidades que
esto em denominador e multiplicando as unidades que esto em denominador.
#20= IFCSIUNIT (*,.AREAUNIT.,$,.SQUARE_METRE.);
#21= IFCSIUNIT (*,.FORCEUNIT.,$,.NEWTON.);
#142= IFCDERIVEDUNITELEMENT (#21,1);
#143= IFCDERIVEDUNITELEMENT (#20,-1);
#144= IFCDERIVEDUNIT ((#142,#143),.PLANARFORCEUNIT.,$);
Figura 4.19 Exemplo Unidade derivada

A entidade que ser atribuda ao IfcProject e que desse modo far a atribuio das unidades a todo o
ficheiro a IfcUnitAssignment, nela que se deve fazer o agrupamento das entidades de unidades.
Portanto devem ser agrupadas nessa classe as unidades fundamentais no sistema SI (IfcSIUnit), as
unidades convertidas (IfcConversionBasedUnit) e as unidades derivadas (IfcDerivedUnit). No caso das
unidades convertidas no se faz a atribuio da unidade base, pois resultaria num conflito de unidades,
por exemplo, apenas se atribui a instncia #43 que define os graus, a instncia #40 que define os
radianos no atribuda.

4.3.3.5. DATA Projecto
O IfcProject uma das entidades fundamentais que deve sempre fazer parte de um qualquer ficheiro
IFC, tem de ser includo exactamente uma vez, servindo como raiz dos elementos num ficheiro de
troca IFC para a visualizao coordenada. O projecto estabelece o contexto para troca e partilha de
informaes e pode representar um projecto de construo, mas no necessariamente. Poder indicar a
realizao de um projecto de engenharia, construo, design ou manuteno de actividades que
conduzem a um produto. O projecto fornece um directrio de tipos de objectos e modelos de
propriedades contidos por meio de relaes de declarao. Em suma, o propsito fundamental do
IfcProject fornecer a instncia raiz e o contexto para todos os outros itens includos no ficheiro de
troca, como demonstrado na Figura 4.20 e na Figura 4.21.
O Modelo IFC como Agente de Interoperabilidade



64

/* Projecto */
#180= IFCPROJECT ('GUID',#5,'Project',$,$,$,$,(#202,#203),#160);
Figura 4.20 Modelo IFC O projecto

#n= IFCPROJECT ("GUID","Historial do usurio","Nome","Descrio","Tipo do
Objecto","Nome completo","Fase","Contexto de representao",
"Unidades em contexto");
Figura 4.21 Aplicao O projecto

Para facilitar a leitura dos exemplos expostos, os Globally Unique Identifiers do arquivo IFC, como
por exemplo 0QjBRF7yLCTh4HRF3GOF1t, aparecem representados apenas pela inscrio
GUID. No demais referir que num ficheiro IFC o GUID deve ser necessariamente uma string de
22 caracteres, no podendo existir dois GUIDs iguais no mesmo cdigo, a existncia de um GUID
que no siga estas regras poder implicar na no definio do objecto que contempla esse GUID. Um
IfcProject tem um GUID como muitos elementos IFC, um link para o IfcOwnerHistory, referncias
para as unidades a usar no ficheiro e contexto da representao geomtrica que permite a
representao de formas e figuras nesse ficheiro.

4.3.3.6. DATA Localizao do Projecto
A localizao do projecto feita pela definio de um sistema de eixos global, que lhe ser atribudo
atravs do contexto de representao geomtrica e desse modo essa sistema de eixos tornar-se- vlido
para todo o modelo IFC (Figura 4.22 e Figura 4.23). Para alm desse sistema de eixos global podem
ainda coexistir outros sistemas de coordenadas locais, que por exemplo, podero servir de auxlio para
uma definio de elementos a nvel local.
/* Localizao do Projecto */
#190= IFCAXIS2PLACEMENT2D (#8,#15);
#191= IFCAXIS2PLACEMENT3D (#7,$,$);
#192= IFCLOCALPLACEMENT ($,#191);
#193= IFCBUILDING ('GUID',#5,$,$,$,#192,$,$,.ELEMENT.,$,$,#194);
#194= IFCPOSTALADDRESS (.HOME.,$,$,'Ares','Rua da Aldeia','n93','Vale de
Cambra','Aveiro','3730-001','Portugal');
#195= IFCBUILDINGSTOREY ('GUID',#5,'Ground',$,$,#192,$,'Rs-do-Cho',
.COMPLEX.,0.);
#196= IFCBUILDINGSTOREY ('GUID',#5,'Floor',$,$,#192,$,'1Piso',
.COMPLEX.,3.);
#197= IFCSITE ('GUID',#5,'Site',$,$,#192,$,$,.ELEMENT.,(40,47,57),(8,17,54)
634.,$,$);
#198= IFCRELAGGREGATES ('GUID',#5,$,$,#197,#193);
#199= IFCRELAGGREGATES ('GUID',#5,$,$,#193,(#195,#196));
Figura 4.22 Modelo IFC O projecto

#n= IFCAXIS2PLACEMENT2D ("Localizao","Direo de referncia");
#n= IFCAXIS2PLACEMENT3D ("Localizao","Eixos","Direo de Referncia");
#n= IFCLOCALPLACEMENT ("Posicionamento relacionado","Posicionamento
relativo");
#n= IFCBUILDING ("GUID","Historial do usurio","Nome","Descrio","Tipo do
objecto","Colocao do Objecto","Representao","Nome
completo","Tipo de composio","Elevao da altura de
referncia","Elevao do terreno","Morada do Edifcio");
O Modelo IFC como Agente de Interoperabilidade



65

#n= IFCBUILDINGSTOREY ("GUID","Historial do usurio","Nome","Descrio","Tipo
do objecto","Colocao do Objecto","Representao",
"Nome completo","Tipo de composio","Elevao");
#n= IFCPOSTALADDRESS ("Propsito","Descrio","Propsito definido pelo
utilizador","Localizao interna","Morada","Caixa postal"
,"Cidade","Regio","Cdigo Postal","Pas");
#n= IFCSITE (("GUID","Historial do usurio","Nome","Descrio","Tipo do
objecto","Colocao do Objecto","Representao","Nome completo",
"Tipo de composio","Latitude de referncia","Longitude de
referncia","Elevao de referncia","Designao do local no
sistema regional","Morada do local");
#n= IFCRELAGGREGATES ("GUID","Historial do usurio","Nome","Descrio",
"Objectos a relacionar","Objectos relacionados");
Figura 4.23 Aplicao O projecto

O IfcAxis2Placement2D fornece a localizao e orientao para que seja possvel colocar objectos
num espao bidimensional, enquanto o IfcAxis2Placement3D faz essa colocao num espao
tridimensional. No caso do atributo direco de referncia no ser atribudo, so dadas direces de
referncia automaticamente, segundo o eixo x [1.,0.] e segundo o eixo y [0.,1.] para o caso
bidimensional e segundo o eixo x [1.,0.,0.], y [0.,1.,0.] e z [0.,0.,1.] para o caso tridimensional. Como
os eixos so colocados segundo um principio de perpendicularidade e a direco pode ser gerada por
referncia, tem-se ento um conjunto de eixos cuja definio depende principalmente do ponto de
aplicao. O sistema de eixos global definido neste grupo pela entidade IfcAxis2Placement3D ser um
atributo inverso do IfcGeometricRepresentationContext que por sua vez ser um atributo inverso do
IfcProject, desta forma que o sistema de eixos definido ficar associado ao projecto.
Tal como o IfcGridPlacement, o IfcLocalPlacement um subtipo do IfcObjectPlacement. O
posicionamento de um produto no espao pode ser relativamente ao sistema de coordenadas global,
relativo ao posicionamento de um objecto ou produto, ou relativo aos eixos cartesianos. O
IfcLocalPlacement permite fazer o posicionamento relativo de um produto em relao a um outro
produto ou um posicionamento absoluto de um produto no contexto de representao geomtrica do
projecto.
O IfcBuilding pode conter informao espacial de elementos ou anotaes e grelhas que lhe estejam
directamente associados e pode tambm conter informaes acerca da localizao do edifcio se for
usado o IfcPostalAdress como atributo inverso. No caso dos elementos da construo, estes so
associados ao IfcBuilding usando o IfcRelContainedInSpatialStructure. Se for pretendida uma
atribuio dos elementos a um determinado nvel especfico, a associao deve ser feita com o mesmo
seguimento lgico, mas desta vez associando os elementos ao IfcBuildingStorey. O IfcSite a
definio de uma rea de terreno (stio) onde se dar lugar construo de um edifcio. Um stio
identificado deste modo pode incluir pode incluir uma definio de ponto de referncia geogrfica
(posio global usando o WGS84 com longitude, latitude e elevao), no caso do exemplo sabe-se que
o edifcio est localizado a 40 47 57 N e 8 17 54 O a uma altitude de 634 metros. Para permitir a
composio e relaes de agregao entre classes, tem-se o IfcRelAggregates que neste caso a
entidade responsvel por estabelecer o contexto das ligaes entre as diversas entidades de conteno
espacial de elementos. O IfcBuildingStorey deve ser colocado em relao ao posicionamento do
IfcBuilding e este por sua vez deve ser colocado em relao ao posicionamento do IfcSite.
A Figura 4.24 demonstra o encadeamento e relao que deve ser feito entre as entidades mencionadas,
de modo a fazer um correcto arranjo espacial dos elementos.
O Modelo IFC como Agente de Interoperabilidade



66


Figura 4.24 Composio do Edifcio (BuildingSMART 2013)

Em suma, o IfcSite permite conter elementos que estejam colocados no terreno, isto , fora do edifcio.
O IfcBuildingStorey permite a definio espacial dos elementos por nveis e o IfcBuilding uma
entidade mais geral que por predefinio contm os elementos no espao, mas em nenhum nvel
especfico.

4.3.3.7. DATA Representao Geomtrica
O contexto em que se aplicam as vrias representaes de forma dos produtos dentro de um projecto
dado pela entidade IfcGeometricRepresentationContext e portanto, todos os ficheiros IFC que
contenham geometria devem definir um contexto de representao geomtrica (Figura 4.25 e Figura
4.26). Para alm da forma, o IfcGeometricRepresentationContext pode tambm definir a preciso
numrica aplicvel aos elementos e a representao geomtrica definida nesse contexto. As
representaes geomtricas devem ser atribudas ao IfcProject por atributo inverso. ainda atravs
desta instncia que se definem os sistemas de coordenadas e de eixos global, o principal contexto de
representao pode tambm fornecer a direco do Norte verdadeiro. A linha da direco Norte dada
pela unio de dois pontos, o ponto origem do referencial e um outro ponto definido pelo utilizador de
modo a formar um ngulo com o eixo dos ys que corresponde direco e sentido pr-definido.
Existem alguns identificadores para representao de formas que incluem valores pr-definidos,
podendo ser encontrados no site da BuildingSMART, mais especificamente em:
http://www.buildingsmart-
tech.org/ifc/IFC4/final/html/schema/ifcrepresentationresource/lexical/ifcshaperepresentation.htm

/* Representao geomtrica */
#202= IFCGEOMETRICREPRESENTATIONCONTEXT ('3D','Model',3,0.00001,#191,$);
#203= IFCGEOMETRICREPRESENTATIONCONTEXT ('2D','Plan',2,0.00001,#191,$);
#204= IFCGEOMETRICREPRESENTATIONSUBCONTEXT ('Body','Model',#202,$,
.MODEL_VIEW.,$);
O Modelo IFC como Agente de Interoperabilidade



67

#205= IFCGEOMETRICREPRESENTATIONSUBCONTEXT ('Annotation','Plan',#203,$,
.PLAN_VIEW.,$);
Figura 4.25 Modelo IFC Representao Geomtrica

#n= IFCGEOMETRICREPRESENTATIONCONTEXT ("Identificador de contexto","Tipo de
contexto","Dimenso espacial","Preciso"
,"Sistema coordenadas global","Direco
Norte");
#n= IFCGEOMETRICREPRESENTATIONSUBCONTEXT ("Identificador de contexto","Tipo de
contexto","Contexto anlogo",
"Escala","Visualizao","Visualizao
definida pelo utilizador");
Figura 4.26 Aplicao Representao Geomtrica

obrigatrio o uso de uma instncia do IfcGeometricRepresentationContext para a representao
espacial do modelo (3D), porm, o uso de uma instncia deste tipo para a representao plana (2D)
de carcter opcional. Esses so os principais contextos de representao geomtrica, podendo ainda ser
mais refinados usando subcontextos de informao geomtrica recorrendo ao
IfcGeometricRepresentationSubContext. Esta entidade usada para definir tipos de representao
semanticamente distintos para diferentes contedos de informao, dependendo da vista da
representao e da escala de destino. Pode ser usado para controlar o nvel de detalhe da representao
da forma que assim mais aplicvel a este contexto de representao.

4.3.3.8. DATA Elementos Estruturais
At este ponto foram definidas as classes com carcter mais geral, que podem fazer parte integrante da
maioria dos ficheiros IFC. As classes expostas na Figura 4.27 e Figura 4.28 so as que permitem a
construo dos elementos propriamente ditos. Na linha de raciocnio usada o primeiro passo foi definir
uma malha de pontos (ns) e respectivas condies de fronteira (deslocamentos e restries de
mobilidade), onde posteriormente ser feita a conexo dos membros estruturais (barras) dos pilares e
vigas e tambm das lajes. Os ns foram identificados como inferior e superior para distinguir os
diferentes nveis e tambm foram numerados para tornar mais perceptvel a ligao dos pilares, vigas e
laje nos pontos respectivos.
/* Pilar 1 - N inferior */
#220= IFCCARTESIANPOINT ((0.,0.,0.));
#221= IFCVERTEXPOINT (#220);
#222= IFCTOPOLOGYREPRESENTATION (#202,'Reference','Vertex',(#221));
#223= IFCPRODUCTDEFINITIONSHAPE ($,$,(#222));
#224= IFCSTRUCTURALPOINTCONNECTION ('GUID',#5,'Point Connection
1',$,$,$,#223,#225,$);

/* Pilar 1 - Restries n inferior Fixo */
#225= IFCBOUNDARYNODECONDITION ('Fixed',IFCBOOLEAN(.T.),IFCBOOLEAN(.T.),
IFCBOOLEAN(.T.),IFCBOOLEAN(.T.),
IFCBOOLEAN(.T.),IFCBOOLEAN(.T.));

/* Pilar 1 - N superior */
#226= IFCCARTESIANPOINT ((0.,0.,3.));
#227= IFCVERTEXPOINT (#226);
#228= IFCTOPOLOGYREPRESENTATION (#202,'Reference','Vertex',(#227));
#229= IFCPRODUCTDEFINITIONSHAPE ($,$,(#228));
O Modelo IFC como Agente de Interoperabilidade



68

#230= IFCSTRUCTURALPOINTCONNECTION ('GUID',#5,'Point Connection
2',$,$,$,#229,#231,$);

/* Pilar 1 - Restries n superior - Livre */
#231= IFCBOUNDARYNODECONDITION ('Free',IFCBOOLEAN(.F.),IFCBOOLEAN(.F.),
IFCBOOLEAN(.F.),IFCBOOLEAN(.F.),
IFCBOOLEAN(.F.),IFCBOOLEAN(.F.));
Figura 4.27 Modelo IFC Ns de ligao do Pilar 1

#n= IFCVERTEXPOINT ("Vrtice");
#n= IFCTOPOLOGYREPRESENTATION ("Contexto dos itens","Identificador de
representao","Tipo de representao","Itens");
#n= IFCPRODUCTDEFINITIONSHAPE ("Nome","Descrio","Representao");
#n= IFCSTRUCTURALPOINTCONNECTION ("GUID","Historial do usurio","Nome",
"Descrio","Tipo do objecto","Posicionamento
do objecto","Representao","Condies
aplicadas","Sistema de coordenadas");

#n= IFCBOUNDARYNODECONDITION ("Nome","Rigidez translacional em X","Rigidez
translacional em Y","Rigidez translacional em Z",
"Rigidez rotacional em X","Rigidez rotacional em Y"
,"Rigidez rotacional em Z");
Figura 4.28 Aplicao Ns de ligao do Pilar 1

A definio de um n feita atravs do IfcVertexPoint que aplica esse n ao ponto cartesiano que lhe
est inversamente atribudo. A definio de n estrutural ou ponto de suporte dada pelo
IfcStructuralPointConnection. Para que se possa fazer uma confirmao visual da correcta definio
do n, deve-se atribuir uma representao topolgica ao elemento estrutural recorrendo entidade
IfcTopologyRepresentation cuja representao ser feita atravs do IfcProductDefinitionShape. As
referncias topolgicas variam consoante o tipo de elemento. Para a definio de um n devem ser
usados o identificador e tipo de representao Reference e Vertex, para a definio de uma barra
Reference e Edge e para a definio de um plano Reference e Face.
O IfcBoundaryNodeCondition descreve as condies de apoio e conexes, permitindo restringir o
movimento numa dada direco atravs de valores booleanos de verdadeiro ou falso. No exemplo
dado (Figura 4.29, Figura 4.30 e Figura 4.31) o n inferior encastrado e por isso todos os booleanos
so identificados como verdadeiros, isto , o movimento restringido em todas as direces. Note-se
que o encastramento do n inferior faz neste caso a representao analtica de uma sapata. Na
definio das condies de fronteira dos ns superiores no seria necessrio definir o
IfcBoundaryNodeCondition, pois neste caso esta instncia no vem atribuir nenhuma limitao j que
todos os valores booleanos so identificados como falso, no definindo assim nenhum tipo de restrio
ao movimento (livre). Neste caso particular esta referncia foi feita por uma questo de coerncia
metodolgica.
/* Pilar 1 - Membro estrutural (Objecto) */
#300= IFCDIRECTION ((1.,0.,0.));
#301= IFCSTRUCTURALCURVEMEMBER ('GUID',#5,'Curve Member 1A',$,$,$,#306,
.RIGID_JOINED_MEMBER.,#300);
#302= IFCRELCONNECTSSTRUCTURALMEMBER ('GUID',#5,$,$,#301,#224,$,$,
$,$);
#303= IFCRELCONNECTSSTRUCTURALMEMBER ('GUID',#5,$,$,#301,#230,$,$,
$,$);

/* Pilar 1 - Membro estrutural (Representao) */
O Modelo IFC como Agente de Interoperabilidade



69

#304= IFCEDGE (#221,#227);
#305= IFCTOPOLOGYREPRESENTATION (#202,'Reference','Edge',(#304));
#306= IFCPRODUCTDEFINITIONSHAPE ($,$,(#305));
Figura 4.29 Modelo IFC Membro estrutural do Pilar 1

/* Viga 1 - Membro estrutural (Objecto) */
#350= IFCDIRECTION ((0.,0.,1.));
#351= IFCSTRUCTURALCURVEMEMBER ('GUID',#5,'Curve Member 1B',$,$,$,#356,
.RIGID_JOINED_MEMBER.,#350);
#352= IFCRELCONNECTSSTRUCTURALMEMBER ('GUID',#5,$,$,#351,#230,$,$,
$,$);
#353= IFCRELCONNECTSSTRUCTURALMEMBER ('GUID',#5,$,$,#351,#250,$,$,
$,$);

/* Viga 1 - Membro estrutural (Representao) */
#354= IFCEDGE (#227,#247);
#355= IFCTOPOLOGYREPRESENTATION (#202,'Reference','Edge',(#354));
#356= IFCPRODUCTDEFINITIONSHAPE ($,$,(#355));
Figura 4.30 Modelo IFC Membro estrutural da Viga 1

#n= IFCSTRUCTURALCURVEMEMBER ("GUID","Historial do usurio","Nome","Descrio"
,"Tipo do objecto","Posicionamento objecto",
"Representao","Tipo pr-definido","Eixos");
#n= IFCRELCONNECTSSTRUCTURALMEMBER ("GUID","Historial do usurio","Nome",
"Descrio","Membro estrutural relativo",
"Conexo estrutural relacionada","Condies
aplicadas","Condies adicionais",
"Comprimento apoiado","Sistema de
coordenadas");
#n= IFCEDGE ("Inicio do trao","Fim do trao");
Figura 4.31 Aplicao Membro estrutural do Pilar 1 e/ou Viga 1

A definio estrutural dos pilares e vigas feita da mesma forma e com uma metodologia semelhante
definio dos ns. Agora, em vez de usada a entidade IfcVertexPoint utilizada a entidade IfcEdge
que juntamente com o IfcStructuralCurveMember faz a definio estrutural de uma barra e no lugar do
IfcStructuralPointConnection usado o IfcRelConnectsStructuralMember. Note-se que o uso desta
entidade foi feita em duplicado porque se pretende que as barras estejam unidas por dois pontos.
Estruturalmente a diferena entre pilares e vigas est apenas na orientao da pea, uma viga tem o seu
eixo baricntrico contido num plano horizontal e um pilar tem o seu eixo baricntrico num plano
vertical. Tanto para a situao dos pilares como para a situao das vigas poderia ter sido utilizadas as
classes IfcDirection definidas inicialmente, apenas se voltou a redefinir estas classes para facilitar a
mudana de direco de um dos pilares ou vigas, caso de se revelar necessrio.
De seguida, a Figura 4.32 e a Figura 4.33 procuram fazer a demontrao da definio estrutural de
uma laje.
/* Laje 1 - Membro estrutural (Objecto) */
#390= IFCSTRUCTURALSURFACEMEMBER ('GUID',#5,'Surface Member
1C',$,$,$,#400,.BENDING_ELEMENT.,0.22);
#391= IFCSTRUCTURALSURFACECONNECTION ('GUID',#5,'Surface Connection 1',$,$
,$,#400,$,$);
#392= IFCRELCONNECTSSTRUCTURALMEMBER ('GUID',#5,$,$,#390,#230,$,$,$,$);
#393= IFCRELCONNECTSSTRUCTURALMEMBER ('GUID',#5,$,$,#390,#250,$,$,$,$);
#394= IFCRELCONNECTSSTRUCTURALMEMBER ('GUID',#5,$,$,#390,#270,$,$,$,$);
#395= IFCRELCONNECTSSTRUCTURALMEMBER ('GUID',#5,$,$,#390,#290,$,$,$,$);
O Modelo IFC como Agente de Interoperabilidade



70


/* Laje 1 - Membro estrutural (Representao) */
#396= IFCPOLYLOOP ((#226,#246,#286,#266));
#397= IFCFACEOUTERBOUND (#396,.T.);
#398= IFCFACESURFACE ((#397),$,.T.);
#399= IFCTOPOLOGYREPRESENTATION (#202,'Reference','Face',(#398));
#400= IFCPRODUCTDEFINITIONSHAPE ($,$,(#399));
Figura 4.32 Modelo IFC Membro estrutural da Laje 1

#n= IFCSTRUCTURALSURFACEMEMBER ("GUID","Historial do usurio","Nome",
"Descrio","Tipo do objecto","Posicionamento
do objecto","Representao","Tipo pr-definido"
,"Espessura");
#n= IFCSTRUCTURALSURFACECONNECTION ("GUID","Historial do usurio","Nome",
"Descrio","Tipo do objecto",
"Posicionamento do objecto","Representao"
,"Condies aplicadas");

#n= IFCPOLYLOOP ("Poligono");
#n= IFCFACEOUTERBOUND ("Limites","Orientao");
#n= IFCFACESURFACE ("Limites","Superfcie","Sentido da normal");
Figura 4.33 Aplicao Membro estrutural da Laje 1

Alerta-se para a existncia de erros na definio da laje do exemplo dado na Figura 4.32. Infelizmente,
apesar de ter sido feito um longo estudo desta ocorrncia em particular e das inmeras alteraes feitas
num processo do tipo tentativa-erro a fim de se tornar a laje perfeitamente funcional, a concretizao
no foi alcanada. Infelizmente, devido ao escasso tempo disponvel para esta investigao, software
inexistente para o esquema IFC4 e inmeras dificuldades sentidas, no foi possvel identificar com
exactido qual o correcto modo de definio de uma laje estrutural. O melhor resultado alcanado foi a
obteno da representao da laje, o que significa que a definio estrutural da laje foi conseguida,
mas cota 0 metros e no cota 3 metros como se pretendia. Foram definidos vrios conjuntos de
eixos na tentativa de resoluo deste problema mas que acabaram sempre sem sucesso. Ao abrir com o
programa Constructivity o modelo IFC4 criado, no mostrada nenhuma janela com indicaes e
alertas de erros, o que leva a acreditar que o problema da no definio da laje possa estar na falta de
alguma instncia que no foi contemplada. Possivelmente para se resolver este problema ser
necessrio um estudo de novas instncias de entidades que possam contornar a questo e faam a
definio dos elementos de outra forma. Espera-se que com estas indicaes permitam que futuras
investigaes consigam alcanar os resultados pretendidos. Os inmeros testes que foram realizados
na tentativa de solucionar o problema no so expostos de forma propositada, pois no se pretende que
sejam descartadas hipteses numa futura anlise do problema.
Para finalizar a determinao dos elementos estruturais necessrio estabelecer uma relao entre os
vrios elementos e o IfcStructuralAnalysisModel (classe que ser exposta mais frente em momento
oportuno), relao essa que feita atravs do IfcRelAssignToGroup que faz a atribuio de definies
de objectos a um determinado grupo (Figura 4.34 e Figura 4.35).
/* Atribuio dos ns e membros estruturais ao modelo de anlise estrutural */
#401= IFCRELASSIGNSTOGROUP ('GUID',#5,$,$,(#224,#230,#301,#244,#250,#311,
#264,#270,#321,#284,#290,#331,#351,#361,#371,
#381,#390),.PRODUCT.,#875);
Figura 4.34 Modelo IFC Atribuio dos ns e membros estruturais ao modelo de anlise estrutural

O Modelo IFC como Agente de Interoperabilidade



71

#n= IFCRELASSIGNSTOGROUP ("GUID","Historial do usurio","Nome","Descrio",
"Objectos relacionados","Tipo dos objectos
relacionados","Grupo relativo");
Figura 4.35 Aplicao Atribuio dos ns e membros estruturais ao modelo de anlise estrutural

4.3.3.9. DATA Elementos Arquitectnicos
Definidos os elementos de forma estrutural passa-se agora para a definio dos elementos mas de
forma arquitectnica (Figura 4.36 e Figura 4.37). Esta definio arquitectnica est mais ligada ao
conceito de geometria e das informaes que se podem retirar a partir da, por isso, foram ainda
definidas, a ttulo de exemplo, algumas propriedades da seco.
/* Pilares - Seco e caractersticas */
#425= IFCRECTANGLEPROFILEDEF (.AREA.,'20x30',$,0.20,0.30);
#426= IFCEXTRUDEDAREASOLID(#425,#191,#13,3.0);
#427= IFCSHAPEREPRESENTATION(#202,'Body','SweptSolid',(#426));
#428= IFCPRESENTATIONLAYERASSIGNMENT('Columns Profile','No
description',(#427),$);
#429= IFCPRODUCTDEFINITIONSHAPE($,$,(#427));
#430= IFCPROPERTYSINGLEVALUE ('MassPerLength',$,IFCMASSPERLENGTHMEASURE(25)
,$);
#431= IFCPROPERTYSINGLEVALUE ('CrossSectionArea',$,IFCAREAMEASURE(0.06),$);
#432= IFCPROPERTYSINGLEVALUE ('MomentOfInertiaY',$,
IFCMOMENTOFINERTIAMEASURE(0.0002),$);
#433= IFCPROPERTYSINGLEVALUE ('MomentOfInertiaZ',$,
IFCMOMENTOFINERTIAMEASURE(0.00045),$);
#434= IFCPROPERTYSINGLEVALUE ('TorsionalSectionModulus',$,
IFCSECTIONMODULUSMEASURE(0.622),$);
#435= IFCPROFILEPROPERTIES ('Pset_ProfileMechanical',$,(#430,#431,#432,
#433,#434),#425);
#436= IFCCARTESIANPOINT ((0.0,0.0,0.0));
#437= IFCAXIS2PLACEMENT3D (#436,#13,#9);
#438= IFCLOCALPLACEMENT (#192,#437);
#439= IFCCOLUMN ('GUID',#5,'Column 1',$,$,#438,#429,$,
.COLUMN.);
#440= IFCRELCONNECTSSTRUCTURALELEMENT ('GUID',#5,$,$,(#301),
#439);
#441= IFCCARTESIANPOINT ((5.5,0.,0.));
#442= IFCAXIS2PLACEMENT3D (#441,#13,#9);
#443= IFCLOCALPLACEMENT (#192,#442);
#444= IFCCOLUMN ('GUID',#5,'Column 2',$,$,#443,#429,$,
.COLUMN.);
#445= IFCRELCONNECTSSTRUCTURALELEMENT ('GUID',#5,$,$,(#311),
#444);
#446= IFCCARTESIANPOINT ((0.,5.5,0.));
#447= IFCAXIS2PLACEMENT3D (#446,#13,#9);
#448= IFCLOCALPLACEMENT (#192,#447);
#449= IFCCOLUMN ('GUID',#5,'Column 3',$,$,#448,#429,$,
.COLUMN.);
#450= IFCRELCONNECTSSTRUCTURALELEMENT ('GUID',#5,$,$,(#321),
#449);
#451= IFCCARTESIANPOINT ((5.5,5.5,0.));
#452= IFCAXIS2PLACEMENT3D (#451,#13,#9);
#453= IFCLOCALPLACEMENT (#192,#452);
#454= IFCCOLUMN ('GUID',#5,'Column 4',$,$,#453,#429,$,
.COLUMN.);
#455= IFCRELCONNECTSSTRUCTURALELEMENT ('GUID',#5,$,$,(#331),
#454);

O Modelo IFC como Agente de Interoperabilidade



72

#456= IFCRELCONTAINEDINSPATIALSTRUCTURE ('GUID',#5,$,$,(#439
,#444,#449,#454),
#196);
Figura 4.36 Modelo IFC Definio da arquitectura dos pilares e algumas definies

#n= IFCRECTANGLEPROFILEDEF ("Tipo de perfil","Nome do perfil","Posio",
"Dimenso X","Dimenso Y");
#n= IFCEXTRUDEDAREASOLID ("Swept rea","Posio","Direo da extruso",
"Profundidade");
#n= IFCSHAPEREPRESENTATION ("Contexto dos Itens","Identificador de
representao","Tipo de representao","Itens");
#n= IFCPRESENTATIONLAYERASSIGNMENT ("Nome","Descrio","Itens atribudos",
"Identificao");
#n= IFCPRODUCTDEFINITIONSHAPE ("Nome","Descrio","Representao");

#n= IFCPROPERTYSINGLEVALUE ("Nome","Descrio","Valor nominal","Unidades");
#n= IFCPROFILEPROPERTIES ("Nome","Descrio","Propriedades","Definio da
seco");

#n= IFCFOOTING ("GUID","Historial do usurio","Nome","Descrio","Tipo do
objecto","Posicionamento do objecto","Representao","Etiqueta"
,"Tipo pr-definido");
#n= IFCCOLUMN ("GUID","Historial do usurio","Nome","Descrio","Tipo do
objecto","Posicionamento do objecto","Representao","Etiqueta"
,"Tipo pr-definido");
#n= IFCBEAM ("GUID","Historial do usurio","Nome","Descrio","Tipo do
objecto","Posicionamento do objecto","Representao","Etiqueta",
"Tipo pr-definido");
#n= IFCSLAB ("GUID","Historial do usurio","Nome","Descrio","Tipo do
objecto","Posicionamento do objecto","Representao","Etiqueta",
"Tipo pr-definido");
#n= IFCRELCONNECTSSTRUCTURALELEMENT ("GUID","Historial do usurio","Nome",
"Descrio","Conexo geomtrica",
"Elementos a relacionar","Elementos
relacionados");
#n= IFCRELCONTAINEDINSPATIALSTRUCTURE ("GUID","Historial do usurio","Nome",
"Descrio","Elementos relacionados",
"Espao a relacionar");
Figura 4.37 Aplicao Definio da arquitectura dos pilares e algumas definies

Como se pode ver pelos exemplos de aplicao, a metodologia de construo do cdigo IFC dos
elementos de construo como sapatas, pilares, vigas e laje bastante semelhante. J que todos tm
seco rectangular todos foram criados a partir da extruso de uma seco rectangular usando o
IfcExtrudedAreaSolid com a entidade IfcRectangleProfileDef inversamente relacionada, mas repare-se
que poderiam ser usadas outras seces de entidades subtipo da IfcProfileDef ou at mesmo a criao
de seces irregulares pela definio do seu contorno atravs do IfcPolyLoop. Depois, de modo a fazer
a definio do tipo de elementos estrutural que dado objecto representa (se se trata de um pilar, viga,
laje, etc.) usa-se uma instncia IFC respectiva para esse efeito (IfcColumn, IfcBeam, IfcSlab, etc.).
A entidade IfcRelConnectsStructuralElement faz uma associao de conectividade entre elementos
numa relao de um para um. O conceito de dois elementos serem associados fisicamente ou
logicamente descrito de forma independente pela conectividade entre elementos. Essa ligao pode
ser feita em termos de representao da seco, definio dos objectos ou atribuio de geometria.
O Modelo IFC como Agente de Interoperabilidade



73

O IfcRelContainedInSpatialStructure usado para fazer a atribuio de elementos a um determinado
nvel espacial da estrutura do projecto, sendo que cada objecto apenas pode ser aplicado uma nica
vez a um dado nvel dessa estrutura.
A figura 4.38 ilustra o funcionamento da hierarquia para a agregao dos elementos estruturais ao
IfcBuilding. Como se pode observar existem elementos (paredes no exemplo) que podem ser
directamente atribudos a um determinado nvel, mas existem tambm elementos que podero no
pertencer a um determinado nvel especfico (escadas no exemplo) e por isso a atribuio no feita a
um nvel ou piso, mas sim ao prprio edifcio.

Figura 4.38 Relao para a conteno espacial de elementos (BuildingSMART 2013)

Por ltimo importa ainda distinguir os elementos superficiais de elementos slidos. Os elementos
superficiais baseiam-se na modelao de faces que possibilita a criao de formas livres e objectos
com formatos complexos que tambm podem ser usados nas ferramentas BIM para a construo de
objectos geomtricos com faces planas ou multifacetadas. Os elementos tridimensionais so criados
O Modelo IFC como Agente de Interoperabilidade



74

pela definio dos limites fechados que compreendem um determinado volume. Esta tcnica
preocupa-se sobretudo com a representao geomtrica e no tanto com as propriedades fsicas do
elemento, sendo este tipo de informaes frequentemente denominados de dummy data. Os
elementos slidos so mais adequados para os modelos BIM pois permitem a indexao de
informaes aos objectos (smart objects). As duas tcnicas de representao mais conhecidas usadas
na modelao de elementos so a CSG e a BREP, a primeira faz a representao de slidos a partir da
extruso de uma seco ou regio numa dada direco e a segunda faz a representao de um slido
atravs da conexo de vrtices e arestas que representam os limites desse slido. (Dimyadi,
Spearpoint, and Amor 2007)

4.3.3.10. DATA Materiais e Propriedades
Agora que os elementos j se encontram analiticamente e geometricamente definidos possvel
completar essa definio pela atribuio de propriedades fsicas a esses mesmos elementos
(Figura 4.39 e Figura 4.40). Na alnea anterior j foram atribudos algumas propriedades relacionadas
com a seco do objecto, agora as propriedades definidas esto relacionadas com o material que ser
atribudo aos elementos estruturais. Pretende-se que os elementos sejam em Beto C20/25 e para isso
definiram-se algumas propriedades desse material, mas poderiam ter sido definidas ainda mais
propriedades do material usando o mesmo mtodo que foi usado no exemplo dado.
/* Pilares - Propriedades do material */
#700= IFCMATERIAL ('C20/25',$,'Concrete');
#701= IFCPROPERTYSINGLEVALUE ('MassDensity',$,
IFCMASSDENSITYMEASURE(2407.31),$);
#702= IFCMATERIALPROPERTIES ('Pset_MaterialCommon',$,(#701),#700);
#703= IFCPROPERTYSINGLEVALUE ('YoungModulus',$,
IFCMODULUSOFELASTICITYMEASURE(23250000000),$);
#704= IFCPROPERTYSINGLEVALUE ('ShearModulus',$,
IFCMODULUSOFELASTICITYMEASURE(9964000000),$);
#705= IFCMATERIALPROPERTIES ('Pset_MaterialMechanical',$,(#703,#704),
#700);
#706= IFCPROPERTYSINGLEVALUE ('ConstructionMethod',$,'In-Situ',$);
#707= IFCPROPERTYSINGLEVALUE ('StructuralClass',$,'S1',$);
#708= IFCPROPERTYSINGLEVALUE ('StrengthClass',$,'C20/25',$);
#709= IFCPROPERTYSINGLEVALUE ('ExposureClass',$,'XC4',$);
#710= IFCPROPERTYSINGLEVALUE ('ReinforcementVolumeRatio',$,
IFCMASSDENSITYMEASURE(280),$);
#711= IFCPROPERTYSINGLEVALUE ('ConstructionToleranceClass',$,'cm',$);
#712= IFCPROPERTYSINGLEVALUE ('ConcreteCover',$,
IFCPOSITIVELENGHTMEASURE(0.025),$);
#713= IFCPROPERTYSINGLEVALUE ('ReinforcementStrengthClass',$,'S500',$);
#714= IFCPROPERTYSET ('GUID',#5,'Pset_ConcreteElementGeneral',$,(#706,
#707,#708,#709,#710,#711,#712,#713));
#715= IFCRELDEFINESBYPROPERTIES ('GUID',#5,$,$,(#301,#311,#321,#331,
#439,#444,#449,#454),#714);
#716= IFCMATERIALPROFILE ($,$,#700,#425,$,$);
#717= IFCMATERIALPROFILESET ($,$,(#716),$);
#718= IFCMATERIALPROFILESETUSAGE (#717,$,$);
#719= IFCRELASSOCIATESMATERIAL ('GUID',#5,$,$,(#301,#311,#321,
#331,#439,#444,#449,#454),#718);
Figura 4.39 Modelo IFC Propriedades atribudas ao Pilar 1

#n= IFCMATERIAL ("Nome","Descrio","Categoria");
#n= IFCPROPERTYSINGLEVALUE ("Nome","Descrio","Valor nominal","Unidades");
#n= IFCMATERIALPROPERTIES ("Nome","Descrio","Propriedades","Material");
#n= IFCPROPERTYSET ("GUID","Historial do usurio","Nome","Descrio","Tipo
definido","Definido por","Ocorrncia definida");
O Modelo IFC como Agente de Interoperabilidade



75

#n= IFCRELDEFINESBYPROPERTIES ("GUID","Historial do usurio","Nome",
"Descrio","Objectos relacionados","Definies
de propriedades a relacionar");
#n= IFCMATERIALPROFILE ("Nome","Descrio","Material","Seco","Prioridade",
"Categoria");
#n= IFCMATERIALPROFILESET ("Nome","Descrio","Seco do material","Seco
composta");
#n= IFCMATERIALPROFILESETUSAGE ("Definies da seco","Ponto de referncia",
"Extenso da referncia");
#n= IFCRELASSOCIATESMATERIAL ("GUID","Historial do usurio","Nome",
"Descrio","Objectos a relacionar","Material
relacionado");
Figura 4.40 Aplicao Propriedades atribudas ao Pilar 1

A definio das vrias caractersticas do material ento feita usando o IfcPropertySingleValue, que
define uma propriedade por instncia. As propriedades de natureza semelhante so depois englobadas
no IfcMaterialProperties que faz a definio dessas propriedades singulares segundo uma determinada
PropertySet pr-definida e por atributo inverso faz se a atribuio dessas propriedades ao material
representado globalmente pelo IfcMaterial. S assim se garante que o material mencionado nesta
entidade contm de facto caractersticas fsicas e no apenas o nome de um material que poderia ou
no ser reconhecido pelo programa destino. A notao Pset_MaterialMechanical indica que as
propriedades do conjunto de definies identificado faz parte da especificao IFC, devendo ser
associada ao perfil do material com a entidade IfcMaterialProfile, que pode ser atribudo a uma seco
de um dado objecto ou conjunto de objectos utilizando-se o IfcRelAssociatesMaterial.
Para alm das propriedades das seces e materiais poderiam ser definidas muitas outras propriedades
do tipo quantitativo ou alfanumrico, num encadeamento semelhante ao anterior, mas agora usando o
IfcPropertySet para agrupar as vrias entidades IfcPropertySingleValue e o IfcRelDefinesByProperties
para fazer a associao dessas propriedades directamente a um objecto ou grupo de objectos.

4.3.3.11. DATA Modelo de Anlise Estrutural
Concluda toda a definio dos elementos estruturais podem agora ser definidas um conjunto de
aces. Para que isso seja possvel preciso criar um modelo de anlise estrutural atravs do
IfcStructuralAnalysisModel como exemplificado na Figura 4.41 e na Figura 4.42. Assim sendo, o
IfcStructuralAnalysisModel a entidade que rene os vrios casos de carga aplicados estrutura e as
posiciona segundo um referencial que corresponde ao sistema de eixos global.
/* Modelo de anlise estrutural */
#875= IFCSTRUCTURALANALYSISMODEL ('GUID',#5,'Structural Analysis 1',$,$,
.NOTDEFINED.,#191,(#900,#910,#920,#930),$,
#192);
#876= IFCRELDECLARES ('GUID',#5,'GROUP',$,#180,(#875));
Figura 4.41 Modelo IFC Modelo de Anlise Estrutural

#n= IFCSTRUCTURALANALYSISMODEL ("GUID","Historial do usurio","Nome",
"Descrio","Tipo do objecto","Tipo pr-
definido","Orientao do plano","Casos de
carga","Resultados","Posicionamento
partilhado");
#n= IFCRELDECLARES ("GUID","Historial do usurio","Nome","Descrio","Contexto
relacionado","Definies");
Figura 4.42 Aplicao Modelo de Anlise Estrutural

O Modelo IFC como Agente de Interoperabilidade



76

Pelo IfcRelDeclares feita a declarao dos objectos ou propriedades ao IfcProject, neste caso
fazendo tambm o seu agrupamento atravs do atributo de enumerao .GROUP.. Ao ser feita esta
relao e agrupamento das classes que definem objectos, torna-se possvel a atribuio de
caractersticas a todas as classes que fazem parte desse grupo, bastando agora apenas ser mencionado
o grupo por atributo inverso em vez de relacionar individualmente cada uma das entidades.

4.3.3.12. DATA Cargas Estruturais
Neste ltimo conjunto de entidades so definidas as cargas a aplicar ao modelo de anlise estrutural
(Figura 4.43 e Figura 4.44). As foras definidas neste modelo IFC so apenas casos de carga usados
para fazer uma explicao prtica do modo de aplicao dos diferentes casos de carga usando
entidades IFC, no contemplando nenhum tipo de combinao. O exemplo dado contempla cargas
pontuais, lineares e uniformemente distribudas num plano.
/* Pilar 1 - Carga linear */
#900= IFCSTRUCTURALLOADCASE ('GUID',#5,'Structural Load Case 1',$,$,
.LOAD_CASE.,.NOTDEFINED.,.NOTDEFINED.,1.,$,
(0.,0.,0.));
#901= IFCSTRUCTURALLOADLINEARFORCE ('Nominal',$,$,-1.64,$,$,$);
#902= IFCSTRUCTURALLOADLINEARFORCE ('Nominal',$,$,-1.64,$,$,$);
#903= IFCSTRUCTURALLOADCONFIGURATION ($,(#901,#902),((0.),(3.)));
#904= IFCSTRUCTURALCURVEACTION ('GUID',#5,'Structural Curve Action 1'
,$,$,$,$,#903,.GLOBAL_COORDS.,.F.,$,
.LINEAR.);
#905= IFCRELCONNECTSSTRUCTURALACTIVITY ('GUID',#5,$,$,#301,#904);
#906= IFCRELASSIGNSTOGROUP ('GUID',#5,$,$,(#904),.PRODUCT.,#900);

/* Pilar 3 - Carga pontual */
#910= IFCSTRUCTURALLOADCASE ('GUID',#5,'Structural Load Case 2',$,$,
.LOAD_CASE.,.NOTDEFINED.,.NOTDEFINED.,1.,$,
(0.,0.,0.));
#911= IFCSTRUCTURALLOADSINGLEFORCE ('Fora 1',$,$,-2.54,$,$,$);
#912= IFCSTRUCTURALLOADCONFIGURATION ($,(#911),((3.)));
#913= IFCSTRUCTURALPOINTACTION ('GUID',#5,'Structural Point Action 1'
,$,$,$,$,#912,.GLOBAL_COORDS.,.F.);
#914= IFCRELCONNECTSSTRUCTURALACTIVITY ('GUID',#5,$,$,#321,#913);
#915= IFCRELASSIGNSTOGROUP ('GUID',#5,$,$,(#913),.PRODUCT.,#910);

/* Viga 1 - Carga trapezoidal */
#920= IFCSTRUCTURALLOADCASE ('GUID',#5,'Structural Load Case 3',$,$,
.LOAD_CASE.,.NOTDEFINED.,.NOTDEFINED.,1.,$,
(0.,0.,0.));
#921= IFCSTRUCTURALLOADLINEARFORCE ('Nominal',5,$,$,$,$,$);
#922= IFCSTRUCTURALLOADLINEARFORCE ('Nominal',2,$,$,$,$,$);
#923= IFCSTRUCTURALLOADCONFIGURATION ($,(#921,#922),((0.),(5.5)));
#924= IFCSTRUCTURALCURVEACTION ('GUID',#5,'Structural Curve Action 2'
,$,$,$,$,#923,.GLOBAL_COORDS.,.F.,$,
.LINEAR.);
#925= IFCRELCONNECTSSTRUCTURALACTIVITY ('GUID',#5,$,$,#351,#924);
#926= IFCRELASSIGNSTOGROUP ('GUID',#5,$,$,(#924),.PRODUCT.,#920);

/* Laje 1 - Carga uniformemente distribuida */
#930= IFCSTRUCTURALLOADCASE ('GUID',#5,'Structural Load Case 4',$,$,
.LOAD_CASE.,.NOTDEFINED.,.NOTDEFINED.,1.,$,
(0.,0.,0.));
#931= IFCSTRUCTURALLOADPLANARFORCE ('Nominal',$,$,-4);
#932= IFCSTRUCTURALLOADCONFIGURATION ($,(#931),((0.)));
#933= IFCSTRUCTURALPLANARACTION ('GUID',#5,'Structural Planar Action
1',$,$,$,$,#932,.GLOBAL_COORDS.,
.F.,$,.CONST.);
O Modelo IFC como Agente de Interoperabilidade



77

#934= IFCRELCONNECTSSTRUCTURALACTIVITY ('GUID',#5,$,$,#390,#933);
#935= IFCRELASSIGNSTOGROUP ('GUID',#5,$,$,(#933),.PRODUCT.,#930);

ENDSEC;

END-ISO-10303-21;
Figura 4.43 Modelo IFC Cargas estruturais

#n= IFCSTRUCTURALLOADCASE ("GUID","Historial do usurio","Nome","Descrio",
"Tipo do objecto","Tipo pr-definido","Tipo da
aco","Origem da aco","Coeficiente","Propsito",
"Coeficiente de peso prprio");
#n= IFCSTRUCTURALLOADLINEARFORCE ("Nome","Fora linear em X","Fora linear em
Y","Fora linear em Z","Momento linear em X",
"Momento linear em Y","Momento linear em Z");
#n= IFCSTRUCTURALLOADCONFIGURATION ("Nome","Valores","Localizao");
#n= IFCSTRUCTURALCURVEACTION ("GUID","Historial do usurio","Nome","Descrio"
,"Tipo do objecto","Posicionamento do objecto",
"Representao","Carga aplicada","Referncial",
"Projeco da carga","Tipo pr-definido");
#n= IFCRELCONNECTSSTRUCTURALACTIVITY ("GUID","Historial do usurio","Nome",
"Descrio","Elementos a relacionar",
"Actividade estrutural relacionada");

#n= IFCSTRUCTURALLOADSINGLEFORCE ("Fora em X","Fora em Y","Fora em Z",
"Momento em X","Momento em Y","Momento em Z");
#n= IFCSTRUCTURALPOINTACTION ("GUID","Historial do usurio","Nome","Descrio"
,"Tipo do objecto","Posicionamento do objecto",
"Representao","Carga aplicada","Referncial",
"Carga destabilizadora");

#n= IFCSTRUCTURALLOADPLANARFORCE ("Nome","Fora plana em X","Fora plana em
Y","Fora plana em Z");
#n= IFCSTRUCTURALPLANARACTION ("GUID","Historial do usurio","Nome",
"Descrio","Tipo do objecto","Posicionamento
do objecto","Representao","Carga aplicada",
"Referncial","Projeco da carga","Tipo pr-
definido");
Figura 4.44 Aplicao Cargas estruturais

Na definio dos diferentes tipos de carga usa-se tambm uma metodologia que bastante semelhante
nos vrios casos, todos so definidos com a entidade IfcStructuralLoadCase, mas existem alguns
pormenores fundamentais sem os quais a definio no ficaria completa e por isso no seria funcional.
A aco de uma carga pontual feita identificando as direces que compem essa carga e respectivos
valores com instncias da entidade IfcStructuralLoadSingleForce. Para caracterizar a aco pontual
como uma aco que actua num ponto usa-se o IfcStructuralPointAction. Posto isso, faz-se a seleco
da barra ou ponto de aplicao da aco por atributo inverso na entidade
IfcRelConnectsStructuralActivity, que faz a relao entre uma determinada carga estrutural e o
elemento, membro estrutural ou ligao estrutural onde essa carga est aplicada. No caso de a fora
estar aplicada numa barra, o referencial usado no IfcStructuralLoadConfiguration um referencial
local, quer isto dizer que, por exemplo, o valor (3.) do atributo Localizao desta entidade refere-
se ao ponto de extremidade de uma barra com 3 metros. Para reforar esta demonstrao suponhamos
que o valor do atributo Localizao era (1,5), isto significaria que a carga estava aplicada na barra
a meio vo. Posto isto, a definio de uma carga linear feita nos mesmos moldes, apenas variam as
O Modelo IFC como Agente de Interoperabilidade



78

classes que define o tipo e aplicao da carga. No caso do tipo de uma carga linear a classe a usar a
IfcStructuralCurveAction, classe supertipo da IfcStructuralLinearAction e no caso da aplicao a
classe a usar agora a IfcLoadLinearForce. A aplicao da carga linear s barras tambm feita num
referencial local, mas desta feita necessrio definir os dois pontos de aplicao que definem a carga
linear (inicial e final) e os valores inicial e final da carga linear, desse modo possvel definir cargas
lineares uniformemente distribudas (se os valores das foras inicial e final foram iguais), cargas
lineares de distribuio triangular (se um dos valor da fora inicial ou final for nulo) e tambm cargas
lineares trapezoidais (se os valores das foras inicial e final foram diferentes). Para a aplicao de
cargas uniformemente distribudas em lajes ou num plano, as entidades que diferem das utilizadas nos
mtodos anteriores so a IfcStructuralLoadPlanarForce e a IfcStructuralPlanarAction, todo o restante
processo semelhante.
Por fim, para se conclui a seco DATA introduz-se a string ENDSEC; e para dar como terminada
toda a estrutura de troca IFC introduz-se a string END-ISO-10303-21;.

4.4. CONSIDERAES COMPLEMENTARES
importante reter que um qualquer ficheiro IFC sempre definido segundo um determinado esquema,
quer esteja sobre a forma STEP-file ou representao XML. O esquema faz a atribuio de significado
aos nomes e relaes das entidades dentre de um ficheiro IFC, sendo esttico para todos os ficheiros
IFC4 e publicado pela BuildingSMART segundo o esquema EXPRESS e tambm em formato XML
de forma alternativa.
Os Model View Definitions (MVD) aparecem no topo do esquema como a parte do esquema que
descrita dentro de um determinado ficheiro IFC, que posteriormente descreve cada instncia de um
determinado componente de construo contido nesse ficheiro.
As instncias contm dados semnticos como o nome, a descrio, a geometria, o tipo, as relaes
entre outras instncias, o posicionamento e relao espacial e as propriedades. Dentro da seco de
atributos de entidades que definem tipos de elementos estruturais (por exemplo IfcColumn) agora
possvel no esquema IFC4 definir tipos pr-definidos como um dos atributos (e atravs de
enumeraes), que do indicaes do uso e funo desses elementos. As informaes no geomtricas
podem ser anexadas s instncias e tambm aos tipos, podendo vrias instncias referir o mesmo tipo.
O posicionamento dos objectivos pode ser absoluto ou relativo ao posicionamento de outro objecto.
As instncias que definem geometria visvel podem ser reutilizadas e atribudas a outras entidades.
Salienta-se que nem toda a geometria definida ser necessariamente visvel. Cada instncia pode ainda
ter mais do que uma representao geomtrica e uma representao tridimensional ter mais do que
uma cor atribuda.
Por ltimo chama-se a ateno para o facto do esquema IFC4 ser repleto de relaes, onde muitas
delas so relaes inversas definidas pelo prprio esquema e por isso no so directamente visveis no
texto de cdigo (BuildingSMART 2013).

O Modelo IFC como Agente de Interoperabilidade



79





5
5 PROPOSTA DE IMPLEMENTAO
DE CLASSES IFC NA CRIAO DE
SOFTWARES


5.1. ENUNCIADO DO PROBLEMA E OBJECTIVOS
Apesar das melhorias significativas das ferramentas BIM em termos de modelao paramtrica na
comunicao com a especificao IFC, ainda existem muitas deficincias tcnicas sem resoluo que
impedem uma utilizao isenta de erros no que respeita s configuraes atribudas no modelo inicial.
Para alm dos recursos internos, a qualidade da informao contida num modelo depende tambm da
qualidade do fluxo de dados entre programas e entre disciplinas. A interoperabilidade entre sistemas
atravs do modelo IFC fornece a possibilidade de troca de informaes sem que os utilizadores
necessitem de conhecimentos aprofundados nesse domnio, contudo, a melhoria da comunicao entre
diferentes ferramentas s possvel atravs do aprofundamento dos conhecimentos nessas matrias. A
implementao de dados neutros que aproximam e estimulam a colaborao no projecto, na execuo
e na operao s se verificar verdadeiramente quando os problemas de interoperabilidade forem
suprimidos. Nesse sentido tm sido feitos esforos por parte da BuildingSMART e outras entidades
que vo ao encontro destes objectivos, sendo concebidas normas (exemplo da ISO 16739:2013) com
vista sua implementao, de modo a facilitar a interoperabilidade entre softwares vocacionados para
diferentes actividades durante o ciclo de vida de um edifcio.
Na prtica corrente de engenharia cada ferramenta pode ter diferentes requisitos para o modo como as
representaes geomtricas so feitas e as informaes so indexadas a essas representaes ou
incorporam o prprio modelo. As capacidades associadas especificao IFC na compreenso de
produtos, relaes e recursos da construo, em juno com o seu caracter expansivo tornaram este
formato na soluo de interoperabilidade de eleio na indstria AEC. Apesar de todas as vantagens
trazidas pelo IFC e todos os esforos que vm sido feitos para que a sua integrao seja melhor
absorvida pela indstria AEC, ainda existem muitas dificuldades que devem ser ultrapassadas para que
se atinjam aceitveis nveis de satisfao dos utilizadores. (Aram, Eastman, and Sacks 2013). Vrios
testes e estudos realizados, incluindo o estudo efectuado no Captulo 3 da presente dissertao,
apontam para inmeros casos onde a informao transferida deturpada ou at mesmo perdida,
diminuindo drasticamente os nveis de confiana no formato IFC
Como principal objectivo este captulo pretende fornecer indicaes e metodologias que possibilitaro
a automao de sistemas usando como suporte as classes IFC estudadas.

O Modelo IFC como Agente de Interoperabilidade



80

5.2. ESTRATGIA DE ABORDAGEM
Na prtica actual as ferramentas de suporte interoperabilidade so apenas usadas ocasionalmente
devido s perdas de informao que se verificam no processo de troca entre softwares. Apesar dos
elevados custos associados reintroduo de dados, a impossibilidade de uma correcta transferncia
de informao para diversas reas e fases do projecto conduz por vezes a um abandono desses
mtodos de transferncia de dados, agravando o fluxo da comunicao. Estas perdas de informao
devem-se em parte ao no comprometimento dos desenvolvedores de programas informticos para
garantir uma correcta transferncia de dados e falta de preocupao para com as questes ligadas
interoperabilidade de sistemas (Bazjanac and Crawley 1998). Na inexistncia de um modelo de dados
comum, as ferramentas BIM na indstria de construo poderiam apenas comunicar de forma directa
entre interfaces que fazem a traduo entre esses formatos, necessitando de mltiplas aplicaes que
acarretariam custos elevados para o utilizador.
Acreditando nas potencialidades da especificao IFC e no sentido de prestar contributo para um
aumento dos nveis de interoperabilidade pelo acrscimo da qualidade de transferncia de dados, so
sugeridas duas propostas de aplicao que tm como base a implementao das entidades IFC. Uma
aplicao pretender ser um ponto de partida para a criao semiautomtica de modelos de informao
e a outra pretender ser um meio que possibilita a correco e manipulao da informao para
melhoria da interoperabilidade. Para isso foi necessrio um estudo aprofundado no domnio da
linguagem e codificao da especificao IFC, investigando as entidades que permitem decompor
produtos, estabelecer relaes e descrever propriedades e materiais, elementos que podero constituir
um modelo gerado por uma qualquer ferramenta BIM.
O processo base adoptado em ambas baseou-se numa abordagem metodolgica, onde primeiro se
identificaram individualmente quais os elementos a serem estudados e s depois se procuraram as
instncias IFC que possibilitam a traduo desses elementos para um ficheiro de troca, com um estudo
que foi voltado para a definio estrutural dos elementos e outros dados que se detectaram no ser
exportados para o modelo IFC. Atravs desse detalhamento dos elementos individuais ser possvel
fazer o seu agrupamento e indexao de mais informaes, depois a multiplicao desses dados
permitir a elaborao de estruturas de edifcios, processo mostrado na Figura 5.1.

Figura 5.1 Processo para a definio de elementos compostos.

A informao que atravessa as vrias fazes deste processo poder tambm ser usada na correco de
algumas lacunas existentes na actualidade e possibilitar a melhoria de processos de troca de
informao. Com essas informaes podero ser reproduzidas determinadas sequncia de dados,
O Modelo IFC como Agente de Interoperabilidade



81

mantendo a informao mais genrica para uma determinada situao e alterando algumas variveis,
resultando numa multiplicao de definies de objectos, produtos e propriedades. Torna-se por isso
necessrio ultrapassar a inrcia existente em compreender o funcionamento de um ficheiro IFC, pois
s atravs da sua forma de expresso que possvel usar as entidades IFC para manipular e trabalhar a
informao de forma proveitosa para a correco de erros ou mesmo at a criao de novos dados,
tirando-se partido dos conhecimentos apreendidos.

5.2.1. DETALHAR
Esta aco que consiste em detalhar os elementos foi j elaborada e descrita no Captulo 4. A
compreenso de um objecto pela fragmentao dos seus elementos possibilita uma melhor
interpretao do verdadeiro sentido e funo desse objecto. O conhecimento desses pequenos pedaos
de informao permitiro agrupar e duplicar os dados de variadas formas, resultando em inmeras
combinaes possveis para o rearranjo de informaes traduzindo os elementos compostos desejados.
Atravs da Figura 5.2 possvel avaliar a quantidade de fragmentos de informao que so necessrios
para a definio de um simples pilar atravs de entidades IFC e ainda assim no nos podemos esquecer
que se trata de uma definio parcial, ainda possvel adicionar muitas outras informaes que no
foram objecto de estudo.

Figura 5.2 Decomposio de um pilar em classes IFC.

As cores representam as entidades que estabelecem as aces principais para a definio do elemento e
as entidades identificadas a cinza identificam algumas entidades que fazem suporte directo
respectiva entidade que define a aco principal. Feita a identificao das entidades necessrias para a
definio de um dado objecto, para a elaborao de outros objectos semelhantes mas com outras
O Modelo IFC como Agente de Interoperabilidade



82

configuraes apenas ser necessrio alterar as variveis fundamentais, como as dimenses, tipo de
elemento, materiais e propriedades a atribuir, condies de fronteira, entre outros.

5.2.2. AGRUPAR
O agrupamento das informaes a fase que transforma os fragmentos de informao em dados
utilizveis, munindo-os de significado, isto , depois de agrupados os diferentes elementos passam a
desempenhar um papel especfico nesse modelo. Esse agrupamento de classes feita atravs da
identificao das suas relaes. Para alm das relaes atravs de atributos a generalizao de relao
mais abstracta feita pela entidade IfcRelationship que estabelece todas as relaes entre objectos
dentro do modelo IFC, que podero ser estabelecidas de um para um ou de um para vrios. Desta
forma possvel manter propriedades especficas imputadas a um determinado relacionamento,
podendo-se mais tarde especificar um comportamento. Os comportamentos so diferenciados pelas
diferentes entidades subtipo da IfcRelationship e so os seguintes:
IfcRelAssigns Uma relao de atribuio estabelece uma relao atravs de um link pelo
meio do qual um objecto pode navegar para outros objectos, atravs de uma relao
bidireccional.
IfcRelAssociates O relacionamento de associao faz referncia s fontes da informao,
podendo esta residir internamente ou externamente ao ficheiro de dados, visto no haver
dependncia implcita nesta associao.
IfcRelConnects A relao de conectividade faz a conexo dos elementos permitindo
estabelecer alguns critrios adicionais, como por exemplo determinadas restries e condies
de fronteira.
IfcRelDeclares Este tipo de relacionamento permite a declarao da relao entre objectos
ou propriedades com um projecto.
IfcRelDecomposes A composio ou decomposio dos elementos feita atravs do
conceito geral definido por este tipo de relacionamento. Deste modo obtm-se a habilidade de
partir de um todo para as partes e das partes para um todo.
IfcRelDefines Por ltimo tem-se uma definio mais genrica e abstracta que serve
essencialmente para atribuir um tipo de objecto a uma determinada ocorrncia, atribuir
propriedades a uma instncia ou ainda atribuir um modelo de propriedades a um tipo de
propriedade.
Para alm do conceito de relacionamento, agrupar tambm inclui o conceito de agregar. Para alm da
informao necessria para definir um elemento podem-se atribuir ou agregar informaes externas a
esse elemento, como acontece por exemplo, na atribuio de cargas a um pilar. Essa carga pode ser
construda de forma independente ao elemento a que aplicada, definindo-se algumas das suas
variveis que seriam o ponto de aplicao, direco, sentido e intensidade e s depois agregar essa
carga ao elemento.
Para concluir e voltando ao exemplo do pilar, a Figura 5.3 retirada do site da BuildingSMART
demonstra algumas das relaes que possvel estabelecer inversamente a um pilar e objectos ou
elementos..
O Modelo IFC como Agente de Interoperabilidade



83


Figura 5.3 Relaes de atribuio inversa a um pilar. Adaptado de (BuildingSMART 2013).

5.2.3. DUPLICAR
Uma vez detalhadas as informaes fragmentadas e conhecidas as condies para se estabelecerem as
relaes esto criadas as bibliotecas de dados que permitem a construo de elementos compostos,
neste caso estruturas, pela reproduo e combinao desses dados. A presente dissertao inicia uma
biblioteca de entidades IFC com as informaes disponibilizadas no Captulo 4. medida que se vo
aprofundando os conhecimentos no domnio do IFC podero ser adicionadas outras entidades que
ainda no constam dessa biblioteca, expandindo dessa forma os ramos de aplicabilidade desses
conhecimentos.
Como se vem referindo, uma estrutura no fundo a composio de mltiplos elementos simples
inter-relacionados. A duplicao de um elemento no significa obrigatoriamente a necessidade de
duplicao de relaes ou atributos. A ttulo de exemplo mostra-se a Figura 5.4 onde duas sapatas
partilham uma mesma seco.
#404= IFCRECTANGLEPROFILEDEF (.AREA.,'150x200',#190,1.5,2.0);
#405= IFCEXTRUDEDAREASOLID (#404,#191,#13,0.75);
#406= IFCSHAPEREPRESENTATION (#202,'Body','SweptSolid',(#405));
#407= IFCPRODUCTDEFINITIONSHAPE ($,$,(#406));
#408= IFCPRESENTATIONLAYERASSIGNMENT ('Footing_Profile_A','No
description',(#406),$);
#409= IFCCARTESIANPOINT ((0.0,0.0,-0.75));
#410= IFCAXIS2PLACEMENT3D (#409,$,$);
#411= IFCLOCALPLACEMENT (#192,#410);
#412= IFCFOOTING ('1we2ARoE50netW0RKs4eva',#5,'Sapata 1',
$,$,#411,#407,$,.PAD_FOOTING.);
#413= IFCCARTESIANPOINT ((5.5,0.0,-0.75));
#414= IFCAXIS2PLACEMENT3D (#413,$,$);
#415= IFCLOCALPLACEMENT (#192,#414);
#416= IFCFOOTING ('2we2ARoE50netQ4FGs4drw',#5,'Sapata 2',
$,$,#415,#407,$,.PAD_FOOTING.);
Figura 5.4 Exemplo da partilha de uma seco por duas sapatas.
O Modelo IFC como Agente de Interoperabilidade



84

A possibilidade de partilha de relaes e atributos uma vantagem de grande utilidade pois permite
alterar simultaneamente as informaes contidas em todos os elementos de um mesmo tipo pela
alterao das variveis numa nica instncia e permite tambm uma economia e eficincia na
utilizao da linguagem de cdigo.

5.3. PROPOSTAS DE IMPLEMENTAO
5.3.1. EXPANSO DA APLICAO EVOLUTION BIM PAVILION
Uma das componentes que incentivou o estudo da linguagem IFC foi a procura de entidades que
viabilizassem a expanso de uma aplicao informtica que tem como suporte base a codificao IFC
para o desenvolvimento de estruturas. A aplicao em causa denominada Evolution BIM Pavilion
e foi inicialmente desenvolvida pelo Prof. Dr. Miguel ngelo Carvalho Ferraz. Esta ferramenta
permite a modelao automtica de estruturas apenas pela introduo das variveis em caixas de
introduo de dados (Input Box), Algumas dos separadores de informao que fazem parte da interface
do programa so apresentadas na Figura 5.5.

Figura 5.5 Aplicao Evolution BIM Pavilion.

Depois de introduzida a informao respectiva aos elementos que iro compor a estrutura pretendida a
aplicao gera um modelo IFC que depois poder ser aberto por uma qualquer ferramenta BIM que j
integre o modelo IFC. A verso inicial desse software permitia a elaborao de estruturas de pavilhes
de um ponto de vista geomtrico com a indicao dos materiais mas apenas atravs de etiquetas, sem
nenhuma materializao de propriedades fsicas ou outras caractersticas. Os pavilhes gerados pela
aplicao na verso disponvel no momento so constitudos essencialmente por vigas delta, vigas
auxiliares e pilares, existindo a possibilidade de incluir sapatas, paredes e telhados. A Figura 5.6
demonstra a visualizao do pavilho gerado com os dados introduzidos na Figura 5.5. Pretende-se
agora vocacionar esta aplicao para a elaborao de estruturas porticadas, construdas pela
composio de sapatas, pilares vigas e lajes. Para alm disso pretende-se tambm possibilitar a
atribuio de cargas pontuais, lineares e uniformemente distribudas a um determinado elemento da
estrutura, bem como fazer uma atribuio dos materiais definindo propriedades fsicas.
O Modelo IFC como Agente de Interoperabilidade



85


Figura 5.6 Pavilho originado pela aplicao Evolution BIM Pavilion.

Utilizando como guia alguma da informao originada pela aplicao na criao de modelos, foi
possvel redefinir algumas entidades geomtricas para a elaborao de estruturas porticadas, s quais
foram adicionadas informaes analticas e mecnicas para reforar e melhorar a definio dos
elementos usados. Este estudo que foi j concretizado no Captulo 4 constitui a proposta para a
implementao de novas entidades para dotar o programa de novas capacidades. A Figura 5.7
apresenta a interface da nova aplicao que resultou da implementao de entidades referida, que
agora possibilita a elaborao de estruturas de edifcios regulares.

Figura 5.7 Aplicao Evolution BIM Buildings.

Para alm de produtos e propriedades tambm indispensvel a definio de relaes. A juno das
diferentes vertentes geomtricas, analtica e mecnica num s modelo feita pela atribuio de
relaes e por isso podem ser gerados modelos compostos apenas por um tipo de informao ou pela
combinao e juno de vrios tipos de informao. A possibilidade de seleccionar a informao que
incorpora o modelo IFC gerado, permite optar pela criao de um modelo com um mbito mais
alargado ou criao de um modelo apenas com a informao estritamente necessria. O primeiro tem a
vantagem de fazer uma definio mais completa dos elementos e o segundo tem como vantagem evitar
O Modelo IFC como Agente de Interoperabilidade



86

que o ficheiro criado contenha um excesso de informaes que podem no interessar ao destinatrio e
at dificultar a sua percepo, pois normalmente este tem uma vocao diferente do emissor. Portanto,
como mostrado na Figura 5.7, a nova aplicao remodelada possibilita pela validao da check box
Create analytical model a criao ou no do modelo analtico da estrutura. A definio analtica
permite estabelecer o relacionamento entre os elementos que compem o edifcio e auxilia o programa
destino a compreender o funcionamento dessa estrutura.
A Figura 5.8 apresenta a estrutura originada com os dados introduzidos na Figura 5.7, mostrando
esquerda o modelo com a sua definio arquitectnica (visualizado com o programa Solibri Model
Viewer) e direita o modelo analtico onde se aplicou uma carga linear de 5 kN/m s vigas na
direco X (visualizado com o programa Constructivity Model Viewer).

Figura 5.8 Estrutura originada pela aplicao Evolution BIM Buildings.

5.3.2. DESENVOLVIMENTO DE APLICAO PARA A RESTITUIO DE DADOS AO FICHEIRO IFC
Os relatos apresentados no Captulo 3 deram conta de que na realizao de troca de dados usando o
modelo IFC so perdidas informaes valiosas. Como tambm j foi constatado nos casos expostos
nesse captulo, uma dada aplicao destino ao importar um ficheiro IFC faz a verificao das
informaes que so recebidas como etiquetas (labels). Ao serem enviados identificadores atravs de
etiquetas do tipo IfcIdentifier, IfcText ou IfcLabel contido nas entidades IFC possvel recuperar
informao perdida, pois sabe-se qual a informao que foi perdida e qual a informao original
correspondente que deveria ter sido enviada pelo programa origem. Atravs desses fragmentos de
informao torna-se possvel fazer a re-caracterizao dos dados iniciais ou at mesmo fazer um
acrscimo de informaes complementares. Para a identificao destas etiquetas e de outras entidades
IFC relevantes que podero ser indicadores de pontos onde necessrio o reforo de informao
poder ser usado o programa IFC File Analyser do NIST que faz a leitura de ficheiros IFC e constri
um ficheiro Excel com as entidades presentes nesse ficheiro IFC, reconhecendo as principais relaes
e atributos dessas instncias
O Modelo IFC como Agente de Interoperabilidade



87

Tomemos o exemplo dos materiais para melhor se compreender o processo de identificao destas
labels. Se numa entidade IfcMaterial estiver contida a informao Concrete C20/25 que
identificada internamente como informao do tipo IfcLabel, o programa destino entende como sendo
uma solicitao para atribuir um material com essa designao e procura na sua base de dados um
material que corresponda ao solicitado para fazer a requerida atribuio. A partir da resultam duas
situaes, ou encontrado o material correspondente e feita a respectiva atribuio, ou no
encontrado o material correspondente e criado um novo material sem propriedades (no caso de no
estarem quaisquer Property Sets associadas ao material). A primeira situao a situao desejvel
mas poucas vezes verificada porque normalmente a forma como os nomes dos materiais so escritos
ou apresentados variam de programa para programa. Na segunda situao onde no h
correspondncia entre o nome contido numa etiqueta do ficheiro IFC e o nome de um material da base
de dados do programa destino sendo gerado um novo material uma situao recorrente. Por forma a
contornar este e outros problemas idnticos prope-se a metodologia de resoluo apresentada na
Figura 5.9.


Figura 5.9 Processo de transferncia de informao entre duas aplicaes usando o modelo IFC e uma
aplicao de suporte.

O Modelo IFC como Agente de Interoperabilidade



88

Esta soluo que se apresenta passa pela realizao de uma aplicao que opere em paralelo com o
modelo IFC logo depois deste ser criado. Como no possvel modificar ou fazer qualquer tipo de
alteraes na traduo que feita nas aplicaes origem e destino, a nica fase onde possvel intervir
nessa fase compreendida entre a exportao e a importao quando se obtm o modelo IFC gerado
pela aplicao BIM 1.
A Figura 5.10 expe um fluxograma que traduz o funcionamento da aplicao. No caso da informao
acerca dos materiais (mas tambm outros tipos de informaes) a primeira condio imposta garantir
que o nome da etiqueta do material se mantm intacto. Depois o programa deve identificar o programa
origem (input) e o programa destino (output), bem como todos os materiais contidos nesses
programas. Com uma base de dados robusta das propriedades usadas nesses programas que foram
utilizados na troca de ficheiros deve-se fazer corresponder os materiais que so equivalentes nos
diferentes programas, por exemplo, o Material X na aplicao BIM 1 corresponde ao Material Y na
aplicao BIM 2. Ao executar estas informaes o que o programa ir fazer simplesmente trocar o
nome contido na etiqueta do IfcMaterial por um nome que o programa destino conhea. No caso de
no existir um material no programa BIM 2 que corresponda ao material exportado pelo programa
BIM 1, a aplicao de suporte poder criar um novo Material Z que faa a correspondncia ao
Material X, pela adio das propriedades desse material atravs de instncias IFC e PropertySets.

Figura 5.10 Fluxograma de acrscimo de valor ao ficheiro IFC exportado pela adio de informaes.
O Modelo IFC como Agente de Interoperabilidade



89


Da mesma forma que se procedeu a restituio dos materiais poder-se- fazer a restituio de outras
informaes. A definio dos componentes estruturais atravs da sua definio analtica outro dos
objectivos desta aplicao. As vantagens associadas atribuio de representaes de modelos
analticos est relacionada com a definio desses objectos por elementos infinitamente rgidos, por
forma a garantir que elementos que concordam num mesmo n permanecem conectados aps a
importao do ficheiro IFC. Enquanto que na situao dos materiais necessrio identificar uma
etiqueta para fazer a atribuio do material pretendido, no caso das definies analticas dos
elementos, estas podero ser inseridas pela aplicao de suporte independentemente de terem sido ou
no um dos dados constantes no ficheiro original, isto porque a definio analtica da estrutura ser
feita pelo reconhecimento das seces dos elementos, informao que geralmente consta no ficheiro
IFC exportado, mesmo quando os nveis de interoperabilidade so considerados baixos. Apesar desta
definio analtica ter uma implementao mais trabalhosa, percebem-se as vantagens que da advm,
j que contribui activamente para um aumento dos nveis de interoperabilidade com programas
vocacionados para o clculo estrutural.
Desde que se consigam enviar para o IFC informaes elementares atravs de entidades genricas ou
at mesmo Labels, a aplicao ser capaz de reconstruir a informao original, vencendo algumas das
dificuldades de interoperabilidade entre programas. O factor chave para o sucesso desta aplicao
reside numa base de dados de entidades a mais completa quanto possvel e uma boa base de dados dos
elementos usados pelos programas e um entendimento da forma como eles operam.

5.4. DESENVOLVIMENTOS FUTUROS
O estudo semntico e sintctico do IFC exposto no captulo anterior permitiu a extraco de
informao valiosa para a definio de modelos estruturais e aplicao das entidades IFC estudadas.
As entidades expostas apenas correspondem s entidades cujo estudo foi feito de forma completa,
outras entidades surgiram mas o tempo de investigao limitado no permitiu um estudo completo e
por isso no foi possvel a sua aplicao ou demonstrao de exemplos. O ficheiro IFC elaborado (em
anexo) procurou abranger as reas da arquitectura, estruturas e mecnica, mas devido abrangncia da
especificao IFC continua a ser necessrio um grande aprofundamento destas matrias.
recomendado que na elaborao de modelos a partir da linguagem IFC se tenham sempre presentes as
diferenas entre estes trs ramos do BIM e tambm as suas relaes (Figura 5.11).

Figura 5.11 Relao entre trs vertentes BIM (BuildingSMART 2013)
O Modelo IFC como Agente de Interoperabilidade



90


Sugerem-se ento uma lista com algumas entidades que podero permitir a continuidade e
aprofundamento deste estudo. So entidades que podero permitir a incluso de outros tipos de
componentes da construo, aberturas em elementos (por exemplo a abertura numa laje para colocao
das escadas ou abertura numa parede para colocao de portas e janelas), definio de outros tipos de
seces, definio de sistemas construtivos, ligao de elementos com excentricidade, entre outras.
IfcWall; IfcStair; IfcDoor; IfcWindow
IfcRelVoidsElements; IfcOpeningElement
IfcParameterizedProfileDef;
IfcStyledItem
IfcElement; IfcBuildingElement
IfcMaterialLayer; IfcMaterialLayerSet; IfcMaterialLayerSetUsage
IfcVertexLoop
IfcStructuralLoadTemperature
IfcBuildingSystem;
IfcRelServicesBuildings
IfcRelConnects; IfcRelConnectsWithRealizingElements
IfcConnectionPointEccentricity; IfcRelConnectsWithEccentricity

O Modelo IFC como Agente de Interoperabilidade



91





6
6 CONCLUSES


6.1. DISCUSSO
Uma das principais concluses que este trabalho permite retirar que para aumentar os nveis de
eficincia da indstria AEC necessrio aumentar os nveis de interoperabilidade. Foram mostrados
problemas gerados por uma interoperabilidade deficiente que cada vez mais se revela insuficiente face
s exigncias actuais, foram estudadas entidades IFC para aprofundar os conhecimentos neste domnio
que permitem perceber o seu modo de funcionamento e foi exposta uma sugesto de aplicao da
especificao IFC que se pretende que tenha aplicabilidade num futuro prximo. Espera-se que com a
implementao da norma ISO 16739:2013, que fomenta e potencializa o IFC enquanto formato aberto
para a interoperabilidade entre ferramentas BIM, se venha a verificar uma melhoria quer na quantidade
de informao que possvel transferir entre programas, quer na qualidade dos moldes em que essa
transferncia feita.
Apesar dos esforos feitos pela BuildingSMART, se os distribuidores de softwares continuarem a
desperdiar a maioria das potencialidades do IFC e usarem apenas este formato para a troca de
informaes bsicas e de baixa complexidade, significa que no h uma aceitao do formato IFC por
parte destes, o que poder conduzir o IFC para uma queda no domnio do obsoleto. Se essa realidade
se verificar ento significa que dificilmente se chegar a um entendimento onde se concretize a
aceitao de um formato de troca de dados aberto, o que representaria uma enorme perda de todo o
potencial e vantagens que esse formato traria e j trouxe para a indstria AEC. Nesta situao
hipottica, existiriam poucas solues para os problemas de interoperabilidade que se sentem na
actualidade e a resoluo desses problemas seria s exequvel se no fosse necessrio realizar trocas
de informao entre diferentes sistemas informticos. Isto apenas ser concretizvel quando existir um
avano suficientemente grande das TIC e das ferramentas BIM para que seja possvel criar um sistema
informtico que inclua todos os mbitos dos BIM num nico software, deste modo todos os
intervenientes num projecto e no ciclo de vida de um edifcio utilizariam a mesma ferramenta e as
questes de troca de informao estariam ultrapassadas pois essa troca j no seria necessria, contudo
e ainda assim, isto s seria verdade se todos os envolvidos usassem o mesmo software de um dado
distribuidor. Conclui-se portanto que se um documento no for passvel de troca ento este tem valor
limitado (Jernigan 2008).
A noo de Building Information Modeling assenta neste conceito de universalidade. Mas o BIM no
est completo, para que se torne verdadeiramente universal no basta que permita a incluso de varias
vertentes do projecto num nico modelo virtual, necessrio que o seu mbito seja ainda mais
alargado abrangendo recursos, processos e fundamentalmente pessoas durante todo o ciclo de vida da
construo admitindo um fluxo de informao continuo. Devem ento ser tomadas aces que vo ao
O Modelo IFC como Agente de Interoperabilidade



92

encontro de uma melhor compreenso dos objectivos dos BIM e que resultem numa melhor integrao
prtica dessas ferramentas. Para isso necessrio promover a aliana entre empresas desenvolvedoras
de softwares que tm no fundo os mesmos objectivos, facilitando a explorao de novos caminhos de
evoluo tecnolgica, usando-se a inovao para a gesto de informao. tambm necessrio educar
e informar, apostando-se na divulgao dos BIM para que os seus objectivos sejam percebidos por
toda a comunidade da indstria AEC e no apenas por uma pequena parte dessa indstria. Desta forma
ser possvel aplicar as competncias certas, no momento certo pelo elemento indicado, o que por si s
resultar num grande aumento da eficincia e produtividade.

6.2. PRINCIPAIS DIFICULDADES
A elaborao da presente dissertao caracterizou-se pelas grandes dificuldades iniciais em
compreender o funcionamento lingustico da especificao IFC. Por essa razo o estudo realizado foi
fortemente encaminhado com o propsito de minimizar o impacto provocado pelo primeiro contacto
com estas matrias, constituindo um guia introdutrio que pretende tambm ser resposta para a
escassez de demonstrao prtica e introduo de conceitos IFC. O prprio conceito BIM comea s
agora a ser mais divulgado e por isso ainda so poucos os que possuem conhecimentos de
programao em cdigo IFC. Neste estudo valeram todas as preciosas indicaes dadas pelos
orientadores, como a indicao de onde procurar informao e sobretudo como procurar,
possibilitando um aprofundamento do conhecimento das matrias tratadas.
Uma das primeiras dificuldades foi a dificuldade de acesso s principais normas. Os elevados preos
associados tornaram a sua aquisio formalmente impraticvel. Ainda assim foi possvel encontrar
contedo parcial das principais normas usadas ou at mesmo normas completas mas noutras lnguas
que no o portugus ou o ingls, sendo necessrio um trabalho acrescido na traduo desses
documentos.
Outra limitao com a qual se conviveu foi a restrio de acesso aos softwares. Muitos desses
problemas foram resolvidos pela requisio de licenas de estudante, no entanto o acesso a
determinados softwares que poderiam potencializar esta investigao no so acessveis pela
comunidade estudante ou so apenas parcialmente acessveis em verses temporrias com inmeras
funcionalidades bloqueadas, como exemplo o programa Constructivity.
Os problemas encontrados na exportao e importao de modelos IFC nos programas testados
tambm foram uma barreira ao prprio estudo da linguagem IFC. A triagem das informaes enviadas
para um ficheiro IFC e a desorganizao dessa informao gerada dificultaram a aprendizagem do
cdigo IFC, pois para alm da escassez da demonstrao de casos de aplicao, os prprios casos
prticos no constituam exemplos completamente fidedignos. Se os programas fizessem uma
exportao que traduzisse o modelo virtual por completo sob a forma de linguagem IFC, esses
modelos gerados constituiriam bons exemplos de aplicao e permitiriam retirar o know-how pela
observao, compreenso e anlise do encadeamento de entidades.
No que toca a linguagens de programao necessria uma ateno redobrada para os pormenores. A
troca de um ponto por uma vrgula, a confuso entre uma letra I e um nmero 1, a repetio da
numerao do identificador nico (#n) em entidades provocando conflitos na leitura, a colocao de
atributos num campo errado, a atribuio inversa de uma entidade que no a pressuposta, a criao de
um GUID com mais de 22 caracteres impossibilitando o funcionamento da instncia, so apenas
alguns dos erros frequentes que podem originar grandes contratempos.

O Modelo IFC como Agente de Interoperabilidade



93

6.3. CONSIDERAES FINAIS
A existncia de ferramentas e programas de software BIM, ainda pouco explorada. A partir da
Figura 6.1 podemos identificar os vrios nveis de evoluo das ferramentas de auxilio ao projecto,
desde os desenhos em formato papel at um previso daquilo que sero as ferramentas BIM no futuro.
Apesar do diagrama de maturidade BIM no conseguir identificar com exactido que rumo ir o BIM
tomar no futuro, esse tambm no um aspecto importante. O importante seguir o caminho da
implementao, com uma mente aberta inovao e s possiveis mudanas que podem surgir na
evoluo dos processos. Os BIM so j uma realidade que aos poucos vai marcando presena na
industria AEC. No nvel 0 de maturidade encontram-se as ferramentas CAD que usam processos
informatizados de desenho simples como linhas, formas e texto cujo conceito no difere dos
tradicionais desenhos em formato papel. No nvel 1 de maturidade verificam-se j manipulao de
informao e interpretao de processos que auxilia na execuo de desenhos bidimensionais mas
tambm tridimensionais. Na maturidade nvel 2 encontram-se os conceitos associados ao BIM, sistema
que possibilita a realizao de desenhos mas que no se representam atravs de linhas e formas
bsicas, mas sim atravs de dados que possibilitam descrever objectos virtualmente pela definio das
suas caracteristicas e propriedades fsicas que podem ser operadas e interpretadas por pessoas ou at
mesmo por sistemas robotizados. A interoperabilidade apresenta-se como o factor principal que
possibilita a passagem para o nvel 3 de maturidade, onde a comunicao entre profissionais e
integrao de modelos ao longo do ciclo de vida da construo ser uma constante. (Sinclair 2012).

Figura 6.1 Diagrama de maturidade BIM (Bew and Richards 2008).

O Modelo IFC como Agente de Interoperabilidade



94

No presente, os profissionais desta indstria ainda no tiram o mximo partido destas ferramentas e
por isso o seu potencial ainda no maximizado, ainda so poucos os que beneficiam das dimenses
4D (controlo de prazos) e 5D (controlo de custos) oferecidas por estas ferramentas. Conclui-se
portanto que na prtica quotidiana nos encontramos situados esquerda da linha vermelha.
necessrio formar os profissionais da indstria da construo para que saibam usufruir das capacidades
dos BIM e as apliquem prtica construtiva atravs de mtodos inovadores (BIM Management for
value 2011).
A plena implementao do conceito BIM trar os seguintes benefcios:
Reduz erros e omisses nos documentos de construo;
Reduz situaes de conflito;
Reduz a necessidade de refazer trabalhos;
Reduz o tempo de execuo de projecto e de tarefas;
Permite melhor compreender a construo;
Permite a inovao de processos;
Motiva o trabalho colaborativo;
Menos desperdcio de recursos;
Oferece novos servios e novas vantagens para os clientes;
Aumenta a qualidade geral do projecto.

BIM is not just a 3D visual model. It's possible to have a model without any geometric information
but with lots of other data, and it will still be a Building Information Model.
- Arto Kiviniemi, Professor of Digital Architecture Design School of the Built Environment,
University of Salford

Uma das concluses fundamentais a importncia crescente e necessidade em garantir a
interoperabilidade de sistemas, pois se estes no possurem uma interoperabilidade com uma base
slida, a actividade de colaborao e cooperao tornar-se- ainda mais dificultada ou at mesmo
impraticvel.
Estes so alguns dos benefcios da interoperabilidade numa situao ideal:
Elimina a necessidade de reintroduo de dados j construdos.
Elimina a necessidade de troca de informaes em formato papel.
Permite que todos os membros de uma equipa trabalhem sobre um mesmo ficheiro e desse
modo evita-se a duplicao de ficheiros e melhora-se a preciso do modelo j que todos os
elementos da equipa trabalham sobre a mesma base.
Aumenta a rapidez da elaborao do projecto.
Reduz a propagao de erros e falhas.
Permite a reutilizao da informao ao longo do ciclo de vida do projecto.
O Modelo IFC como Agente de Interoperabilidade



95

Alarga a viso que as empresas tm dos mercados.
Diminui os custos de comunicao.

O uso das ferramentas BIM apenas para modelao tridimensional tem apesar de tudo a vantagem de
indirectamente comear a promover aos seus utilizadores o uso e a importncia das outras
competncias desses utenslios. Mesmo os indivduos que no estavam a par das potencialidades que
esses mesmos instrumentos poderiam ter, esto agora mais sensveis para a verdadeira filosofia BIM e
assim sendo comea-se j a verificar uma maior abertura de mentalidades e um despertar crescente de
interesses por estas matrias. A generalidade dos profissionais comea agora a olhar para as
ferramentas BIM como inevitveis sucessoras das actuais ferramentas CAD e outras ferramentas
complementares. certo que BIM far parte do futuro, apenas continua a existir a dvida de como
ser utilizado e implementado, sabe-se apenas que deve integrar as necessidades dos utilizadores e
todo o processo construtivo.
As solues tecnolgicas podero passar pela implementao dos formatos abertos normalizados que
devem ser adoptados universalmente por toda a indstria de softwares da construo. Admite-se que
assim as empresas distribuidoras de software perderiam vantagens comerciais no que toca
salvaguarda de informaes de caracter privado, mas desse modo toda a indstria AEC ficaria a
ganhar no s em qualidade de troca e partilha de informao mas tambm em inovao tcnica e
metodolgica. Como vimos, esforos esto a ser feitos nesse sentido, inclusive atravs da
normalizao ISO, para que atravs da especificao IFC se consiga estar um passo mais perto dessa
realidade, contudo o caminho da interoperabilidade poder no depender apenas de uma norma mas de
vrias. O certo que depois de uma dcada e meia de implementao o formato IFC continua a no ser
to eficaz como os utilizadores esperavam que fosse e por isso ainda no atingiu um nvel satisfatrio.
Os utilizadores continuam a deparar-se com novos pontos onde so necessrias correces para o uso
prtico. Conclui-se portanto que os responsveis pelo desenvolvimento de softwares devem primeiro
focar-se no melhoramento da qualidade das informaes que j so transferidas e s depois alargar as
extenses do modelo passiveis de exportao.
Enumeram-se algumas barreiras que impedem uma melhor implementao e progresso da
implementao da especificao IFC:
Os softwares fornecem poucas funcionalidades para a troca de informao usando ficheiros de
troca IFC. A maioria dos programas que admitem a especificao IFC apenas fornecem uma
compatibilidade parcial com este formato de troca, no oferecendo muitas possibilidades de controlo
da informao que transferida.
Os softwares no fornecem especificamente o contexto de decomposio em que se inserem
os diferentes tipos de relaes de produtos e objectos. Seria vantajoso se um dado programa identifica-
se todas as entidades IFC que foram necessrias para traduzir um dado elemento.
Os softwares contm ainda bastantes erros e problemas na exportao e importao de
ficheiros IFC. Esta situao s poder ser resolvida se houver um esforo e vontade conjunta dos
desenvolvedores de sistemas informticos, associando-se BuildingSMART para ultrapassarem estas
barreiras
O IFC no permite identificar que representaes ou alteraes que foram feitas entre dois
modelos, o que torna necessrio o uso de um programa que permita analisar o ficheiro IFC permitindo
comparar as modificaes mais significativas (como por exemplo o IFC File analyser do NIST).
O Modelo IFC como Agente de Interoperabilidade



96

Apesar de ter j um mbito bastante abrangente, ainda existem elementos e funcionalidades
que no so suportadas pelo formato IFC, consequncia do amplo domnio da construo.
A indstria da construo ainda no est suficientemente preparada.

Na situao actual, no que toca a ferramentas BIM, os lderes de mercado moldam a indstria e por
isso a nica forma de mudar essa filosofia passa pela considerao dos nveis de interoperabilidade por
parte dos membros da equipa de projecto aquando da escolha de um dado software. Esse deveria ser
um dos primeiros factores de deciso de escolha dada a importncia que a interoperabilidade ter no
decorrer de todo o projecto e as vantagens que trar, pois mesmo que os benefcios no sejam sentidos
logo numa fase inicial, sero sentidos em fases posteriores.
Um aumento dos nveis de competio no mercado tecnolgico tambm poderia fomentar a
necessidade de tornar os softwares mais interoperveis. Uma maior competio produz mais presso
nas empresas distribuidoras de softwares o que dessa forma poder resultar numa evoluo do
mercado.

The biggest innovations in construction industry are more driven by clients than industry itself.
- Paul Morrell, former UK Governments first Chief Construction Adviser

O Modelo IFC como Agente de Interoperabilidade



97





REFERNCIAS

O Modelo IFC como Agente de Interoperabilidade



99


REFERNCIAS BIBLIOGRFICAS

AIA. 2009. Interoperability Position Statement.
http://www.aia.org/aiaucmp/groups/aia/documents/pdf/aiab082297.pdf.

Aram, Shiva, Charles Eastman, and Rafael Sacks. 2013. Automation in Construction. Requirements
for BIM platforms in the concrete reinforcement supply chain: 17, www.elsevier.com/locate/autcon.

Autodesk. Autodesk 2013 [cited 22-04-2013. Available from http://www.autodesk.com/.

Bazjanac, Vladimir, and Drury B. Crawley. 1998. "The implementation of Industry Foundation
Classes in simulation tools for the building industry."

Bentley Systems, Incorporated 2008. IFC Position Paper 5,
http://ftp2.bentley.com/dist/collateral/whitepaper/Building_IFC_Position_Paper_whitepaper_eng.pdf.

Bernstein, Harvey M., Norbert W. Young Jr., and Stephen A. Jones. 2007. "Interoperability in
Construction Industry." McGraw Hill Construction:36.

Bew, Mark, and Mervyn Richards. 2008. "Building Information Modelling Maturity Levels."

BIM Management for value, cost & carbon improvement. 2011. A report for the Government
Construction Client Group. In Building Information Modelling (BIM) Working Party Strategy Paper.

BuildingSMART. International home of openBIM 2013. Available from
http://www.buildingsmart.org/.

Dimyadi, Johannes A. W., Michael Spearpoint, and Robert Amor. 2007. Generating fire dynamics
simulator geometrical input using IFC-based Building Information Model. 16.

Eastman, Charles M. 1999. Building Product Models: Computer Environments Supporting Design and
Construction: CRC Press, Inc.

Eastman, Chuck, Paul Teicholz, Rafael Sacks, and Kathleen Liston. 2011. BIM Handbook: A Guide to
Building Information Modeling for Owners, Managers, Designers, Engineers and Contractors.
Second Edition ed: Wiley Publishing.
O Modelo IFC como Agente de Interoperabilidade



100

Firmenich, Berthold, Mohamed Nour;, Torsten Richter;, and Christian Koch. 2006. A versioned IFC
database for multidisciplinary synchronous cooperation. In Joint International Conference on
Computing and Decision Making in Civil and Building Engineering. Montral, Canada.

Gequaltec. 2013. Wiki da Construo. FEUP 2011 [cited 13-03-2013 2013]. Available from
http://paginas.fe.up.pt/~gequaltec/w/index.php?title=P%C3%A1gina_principal.

Graphisoft. Graphisoft 2013 [cited 01-06-2013. Available from
http://www.graphisoft.com/images/documentation/documentation-virtual_building.jpg.

Gunter, C.A. 1992. Semantics of programming languages: structures and techniques: London.

Hiplito de Sousa et al., Joo Poas Martins, Andr Monteiro. 2011. Projecto SIGABIM. In
GEQUALTEC, edited by Departamento de Engenharia Civil Seco de Construes Civis, Faculdade
de Engenharia da Universidade do Porto (FEUP).

IAI. 1999. Industry Foundation Classes - Realese 2.0. In IFC Object Model Architecture Guide, edited
by Thomas Liebich.

ISO. 2002. ISO 10303-21:2002. In Part 21: Implementation methods: Clear text encodind of the
exchange structure.

ISO. International Organization for Standardization 2013. Available from http://www.iso.org/.

Jernigan, F.E. 2008. Big BIM, Little Bim: The Practical Approach to Building Information Modeling :
Integrated Practice Done the Right Way! Second Edition ed: 4Site Press.

Khemlani, Lachmi. Top Criteria for BIM Solutions: AECbytes Survey Results. AECbytes, 10 de
Outubro de 2007 2007 [cited 31-05.2013. Available from
http://www.aecbytes.com/feature/2007/BIMSurveyReport.html.

Kiviniemi, Arto, Vino Tarandi;, Jan Karlshj;, Hvard Bell;, and Ole Jrgen Karud;. 2008. "Review
of the Development and Implementation of IFC compatible BIM." Erabuild.

Kymmell, W. 2008. Building Information Modeling: Planning and Managing Construction Projects
with 4D CAD and Simulations: McGraw-Hill Professional Publishing.
O Modelo IFC como Agente de Interoperabilidade



101

Laakso, Mikael, and Arto Kiviniemi. 2012. "The IFC Standard - A Review of History, Development
and Standardization." ITcon - Jornal of Information Technology in Construction:28.

Lehrenfeld, Georg, Wolfgang Mueller, and Norbert Wiechers. 1993. Conformance tests of very large
STEP files. edited by Paderborn University. Warburger Str. 100, D-33098 Paderborn, Germany.
Liebich, Thomas. 2013. IFC4 the new buildingSMART Standard.

Lillja, Christopher M. How Building Information Modeling (BIM) Improves the Design and
Construction Process 2012. Available from http://news.princeton.edu.

Martins, Maria Peixoto; Joo Poas. 2012. Pesquisa estruturada e manipulao de informao no
modelo IFC. Requisitos e solues. In Congresso Construo 2012. Coimbra, Portugal.

Nour, M. 2008. Construction Product Data and Building Information Models: VDM Publishing.

Pazlar, Tomaz, and Ziga Turk. 2008. "Interoperability in practice: Geometric data exchange using the
IFC standard." Electronic Journal of Information Technology in Construction no. 13:362-380.

Schevers, Hans, and Robin Drogemuller. 2006. Converting the Industry Foundation Classes to the
Web Ontology Language. edited by CSIRO Manufacturing & Information Technology. 37 Graham
Road, Highett, Victoria 3190, Australia: IEEE Computer Society.

SCRA. 2006. STEP Application Handbook. ISO 10303 Version 3: 181.

Silva, Victor. 2011. BIM - The summary of a long history.

Sinclair, Dale. 2012. BIM Overlay to the RIBA Outline Plan Work. In Royal Institute of British
Architects: RIBA Publishing.

Thein, Volker. 2011. BIM Interoperability Through a Vendor-Independent File Format. Industry
Foundation Classes (IFC): 8.

Venugopal, Manu. 2011. Formal Specification of Industry Foundation Class Concepts Using
Engineering Ontologies, Georgia Institute of Technology.

YIN, Robert K. 1993. Applications of case study research. Thousand Oaks, California: Sage
Publications.
O Modelo IFC como Agente de Interoperabilidade



102

NORMAS

ISO 639 Codes for the representation of names of languages.

ISO 8601 Representation of dates and times.

ISO 10303 Automation Systems and Integration.

ISO 10303-11:2004 Industrial automation systems and integration Product data representation
and exchange Part 11: Description methods: The EXPRESS language reference manual.

ISO 10303-21:2002 Industrial automation systems and integration Product data representation
and exchange Part 21: Implementation methods: Clear text encoding of the exchange structure.

ISO 10303-28:2007 Industrial automation systems and integration Product data representation
and exchange Part 28: Implementation methods: XML representations of EXPRESS schemas and
data, using XML schemas.

ISO 12006-3:2007 Building construction Organization of information about construction works
Part 3: Framework for object-oriented information.

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

ISO 16739:2013 Industry Foundation Classes (IFC) for data sharing in the construction and facility
management industries.

ISO/IEC 11578:1996 Information technology Open Systems Interconnection Remote Procedure
Call (RPC).

ISO 29481-2:2012 Building information models Information delivery manual Part 2: Interaction
framework.


O Modelo IFC como Agente de Interoperabilidade



103





ANEXOS


O Modelo IFC como Agente de Interoperabilidade



105






A1
REPRESENTAO DE UM PILAR
NOS VRIOS CASOS DE
INTEROPERABILIDADE

O Modelo IFC como Agente de Interoperabilidade



107


Caso 1A
Revit
Architecture
(Informao na
Origem)


Robot
(Via Directa)



O Modelo IFC como Agente de Interoperabilidade



108



Caso 1B
Revit Structures
(Informao na
Origem)


Robot
(Via IFC)


O Modelo IFC como Agente de Interoperabilidade



109

Robot
(Via Directa)



Robot
(Via IFC)






O Modelo IFC como Agente de Interoperabilidade



110

Caso 1C e 1D
Robot
(Informao na
Origem)


Revit
Architecture
(Via Directa)


O Modelo IFC como Agente de Interoperabilidade



111

Revit Structures
(Via Directa)




Caso 1E
Revit Structures
(Informao na
Origem)


O Modelo IFC como Agente de Interoperabilidade



112

Revit Structures
(Via IFC)





Caso 1F
ArchiCad
(Informao na
Origem)


O Modelo IFC como Agente de Interoperabilidade



113

Tricalc
(Via IFC)

No Tricalc as propriedades podem ser
consultadas atravs de listagens e
relatrios completos gerados em
ficheiro do tipo *.docx.


Caso 1G
Tricalc
(Informao na
Origem)

No Tricalc as propriedades podem ser
consultadas atravs de listagens e
relatrios completos gerados em
ficheiro do tipo *.docx.
O Modelo IFC como Agente de Interoperabilidade



114

Archicad
(Via IFC)


Revit
Structures
(Via IFC)


O Modelo IFC como Agente de Interoperabilidade



115

Robot
(Via IFC)




Caso 1H
Tricalc
(Informao na
Origem)

No Tricalc as propriedades podem ser
consultadas atravs de listagens e
relatrios completos gerados em
ficheiro do tipo *.docx.
O Modelo IFC como Agente de Interoperabilidade



116

Tricalc
(Via IFC)

No Tricalc as propriedades podem ser
consultadas atravs de listagens e
relatrios completos gerados em
ficheiro do tipo *.docx.


Caso 1I
IFC
(Visualizado
com o software
Constructivity)
(Informao na
Origem)



O Modelo IFC como Agente de Interoperabilidade



117






A2
TEXTO DE CDIGO DO MODELO
USADO NA ANLISE E EXPOSIO
DE UM FICHEIRO IFC
O Modelo IFC como Agente de Interoperabilidade



119

ISO-10303-21;
HEADER;
FILE_DESCRIPTION (('ViewDefinition [CoordinationView]'),'2;1');
FILE_NAME ('ModeloIFC.ifc','2013-04-03T10:54:01','Srgio
Pinho','FEUP','BIM','Notepad++',$);
FILE_SCHEMA (('IFC4'));
ENDSEC;

DATA;
/* Dados do usurio, organizao e da aplicao */
#1= IFCORGANIZATION ($,'Sergio-PC','FEUP',$,$);
#2= IFCAPPLICATION (#1,'1.0','IFC4','Made via Notepad++');
#3= IFCPERSON ($,$,'Sergio',$,$,$,$,$);
#4= IFCPERSONANDORGANIZATION (#3,#1,$);
#5= IFCOWNERHISTORY (#4,#2,.READWRITE.,.NOCHANGE.,$,$,$,1320677205);


/* Pontos cartesianos e direces */
#7= IFCCARTESIANPOINT ((0.,0.,0.));
#8= IFCCARTESIANPOINT ((0.,0.));
#9= IFCDIRECTION ((1.,0.,0.));
#10= IFCDIRECTION ((-1.,0.,0.));
#11= IFCDIRECTION ((0.,1.,0.));
#12= IFCDIRECTION ((0.,-1.,0.));
#13= IFCDIRECTION ((0.,0.,1.));
#14= IFCDIRECTION ((0.,0.,-1.));
#15= IFCDIRECTION ((1.,0.));
#16= IFCDIRECTION ((-1.,0.));
#17= IFCDIRECTION ((0.,1.));
#18= IFCDIRECTION ((0.,-1.));


/* Unidades */
#20= IFCSIUNIT (*,.AREAUNIT.,$,.SQUARE_METRE.);
#21= IFCSIUNIT (*,.FORCEUNIT.,$,.NEWTON.);
#28= IFCSIUNIT (*,.LENGTHUNIT.,$,.METRE.);
#36= IFCSIUNIT (*,.MASSUNIT.,.KILO.,.GRAM.);
#40= IFCSIUNIT (*,.PLANEANGLEUNIT.,$,.RADIAN.);
#41= IFCMEASUREWITHUNIT (IFCPLANEANGLEMEASURE(0.0174532925199433),#40);
#42= IFCDIMENSIONALEXPONENTS (0,0,0,0,0,0,0);
#43= IFCCONVERSIONBASEDUNIT (#42,.PLANEANGLEUNIT.,'DEGREE',#41);
#45= IFCSIUNIT (*,.PRESSUREUNIT.,$,.PASCAL.);
#56= IFCSIUNIT (*,.VOLUMEUNIT.,$,.CUBIC_METRE.);
#57= IFCSIUNIT (*,.TIMEUNIT.,$,.SECOND.);
#58= IFCSIUNIT (*,.THERMODYNAMICTEMPERATUREUNIT.,$,.DEGREE_CELSIUS.);
#59= IFCSIUNIT (*,.LUMINOUSINTENSITYUNIT.,$,.LUMEN.);
#96= IFCDERIVEDUNITELEMENT (#21,1);
#97= IFCDERIVEDUNITELEMENT (#28,-1);
#98= IFCDERIVEDUNIT ((#96,#97),.LINEARFORCEUNIT.,$);
#99= IFCDERIVEDUNITELEMENT (#21,1);
#100= IFCDERIVEDUNITELEMENT (#28,1);
#101= IFCDERIVEDUNITELEMENT (#28,-1);
#102= IFCDERIVEDUNIT ((#99,#100,#101),.LINEARMOMENTUNIT.,$);
#103= IFCDERIVEDUNITELEMENT (#21,1);
#104= IFCDERIVEDUNITELEMENT (#28,-1);
#105= IFCDERIVEDUNIT ((#103,#104),.LINEARSTIFFNESSUNIT.,$);
#112= IFCDERIVEDUNITELEMENT (#36,1);
#113= IFCDERIVEDUNITELEMENT (#56,-1);
#114= IFCDERIVEDUNIT ((#112,#113),.MASSDENSITYUNIT.,$);
#118= IFCDERIVEDUNITELEMENT (#36,1);
#119= IFCDERIVEDUNITELEMENT (#28,-1);
#120= IFCDERIVEDUNIT ((#118,#119),.MASSPERLENGTHUNIT.,$);
#121= IFCDERIVEDUNITELEMENT (#45,1);
#122= IFCDERIVEDUNIT ((#121),.MODULUSOFELASTICITYUNIT.,$);
#140= IFCDERIVEDUNITELEMENT (#28,4);
O Modelo IFC como Agente de Interoperabilidade



120

#141= IFCDERIVEDUNIT ((#140),.MOMENTOFINERTIAUNIT.,$);
#142= IFCDERIVEDUNITELEMENT (#21,1);
#143= IFCDERIVEDUNITELEMENT (#20,-1);
#144= IFCDERIVEDUNIT ((#142,#143),.PLANARFORCEUNIT.,$);
#147= IFCDERIVEDUNITELEMENT (#36,1);
#148= IFCDERIVEDUNITELEMENT (#20,-1);
#149= IFCDERIVEDUNIT ((#147,#148),.ROTATIONALMASSUNIT.,$);
#150= IFCDERIVEDUNITELEMENT (#21,1);
#151= IFCDERIVEDUNITELEMENT (#28,1);
#152= IFCDERIVEDUNITELEMENT (#43,-1);
#153= IFCDERIVEDUNIT ((#150,#151,#152),.ROTATIONALSTIFFNESSUNIT.,$);
#154= IFCDERIVEDUNITELEMENT (#28,5);
#155= IFCDERIVEDUNIT ((#154),.SECTIONAREAINTEGRALUNIT.,$);
#156= IFCDERIVEDUNITELEMENT (#28,3);
#157= IFCDERIVEDUNIT ((#156),.SECTIONMODULUSUNIT.,$);
#158= IFCDERIVEDUNITELEMENT (#45,1);
#159= IFCDERIVEDUNIT ((#158),.SHEARMODULUSUNIT.,$);
#160= IFCUNITASSIGNMENT
((#20,#21,#28,#36,#43,#45,#56,#98,#102,#105,#114,#120,#122,#141,#144,#149,#153,#155
,#157,#159));


/* Projecto */
#180= IFCPROJECT ('0QjBRF7yLCTh4HRF3GOF1t',#5,'Project',$,$,$,$,(#202,#203),#160);


/* Localizao do Projecto */
#190= IFCAXIS2PLACEMENT2D (#8,#15);
#191= IFCAXIS2PLACEMENT3D (#7,$,$);
#192= IFCLOCALPLACEMENT ($,#191);
#193= IFCBUILDING ('2QhGKmE2bDmA5FWgSPSo81',#5,$,$,$,#192,$,$,.ELEMENT.,$,$,#194);
#194= IFCPOSTALADDRESS (.HOME.,$,$,'Ares','Rua da Aldeia','n93','Vale de
Cambra','Aveiro','3730-001','Portugal');
#195= IFCBUILDINGSTOREY ('1QhGKmE2bDmA5FWgVcZDp7',#5,'Ground',$,$,#192,$,'Rs-do-
Cho',.COMPLEX.,0.);
#196= IFCBUILDINGSTOREY
('2QhGKmE2bDmA5FWgVcZDp7',#5,'Floor',$,$,#192,$,'1Piso',.COMPLEX.,3.);
#197= IFCSITE
('2EfWEdX2bDmQ3GVgSPSo82',#5,'Site',$,$,#192,$,$,.ELEMENT.,(40,47,57),(8,17,54),634
.,$,$);
#198= IFCRELAGGREGATES ('8DrHRdX5lONR8JKpYUIp75',#5,$,$,#197,#193);
#199= IFCRELAGGREGATES ('9SpBQdB63LOK4FGpDPAp32',#5,$,$,#193,(#195,#196));

/* Representao geomtrica */
#202= IFCGEOMETRICREPRESENTATIONCONTEXT ('3D','Model',3,0.00001,#191,$);
#203= IFCGEOMETRICREPRESENTATIONCONTEXT ('2D','Plan',2,0.00001,#191,$);
#204= IFCGEOMETRICREPRESENTATIONSUBCONTEXT ('Body','Model',#202,$,.MODEL_VIEW.,$);
#205= IFCGEOMETRICREPRESENTATIONSUBCONTEXT
('Annotation','Plan',#203,$,.PLAN_VIEW.,$);

/* ----------------------------------------------------------------------------- */


/* Pilar 1 - N inferior */
#220= IFCCARTESIANPOINT ((0.,0.,0.));
#221= IFCVERTEXPOINT (#220);
#222= IFCTOPOLOGYREPRESENTATION (#202,'Reference','Vertex',(#221));
#223= IFCPRODUCTDEFINITIONSHAPE ($,$,(#222));
#224= IFCSTRUCTURALPOINTCONNECTION ('1539fAVu96i8mFr0cgUqeI',#5,'Point Connection
1',$,$,$,#223,#225,$);

/* Pilar 1 - Restries n inferior - Fixo */
#225= IFCBOUNDARYNODECONDITION
('Fixed',IFCBOOLEAN(.T.),IFCBOOLEAN(.T.),IFCBOOLEAN(.T.),IFCBOOLEAN(.T.),IFCBOOLEAN
(.T.),IFCBOOLEAN(.T.));
O Modelo IFC como Agente de Interoperabilidade



121


/* Pilar 1 - N superior */
#226= IFCCARTESIANPOINT ((0.,0.,3.));
#227= IFCVERTEXPOINT (#226);
#228= IFCTOPOLOGYREPRESENTATION (#202,'Reference','Vertex',(#227));
#229= IFCPRODUCTDEFINITIONSHAPE ($,$,(#228));
#230= IFCSTRUCTURALPOINTCONNECTION ('1mc6ibF258HPIpTmqg6DSl',#5,'Point Connection
2',$,$,$,#229,#231,$);

/* Pilar 1 - Restries n superior - Livre */
#231= IFCBOUNDARYNODECONDITION
('Free',IFCBOOLEAN(.F.),IFCBOOLEAN(.F.),IFCBOOLEAN(.F.),IFCBOOLEAN(.F.),IFCBOOLEAN(
.F.),IFCBOOLEAN(.F.));

/* Pilar 2 - N inferior */
#240= IFCCARTESIANPOINT ((5.5,0.,0.));
#241= IFCVERTEXPOINT (#240);
#242= IFCTOPOLOGYREPRESENTATION (#202,'Reference','Vertex',(#241));
#243= IFCPRODUCTDEFINITIONSHAPE ($,$,(#242));
#244= IFCSTRUCTURALPOINTCONNECTION ('2539fAVu96i8mFr0cgUqeI',#5,'Point Connection
4',$,$,$,#243,#245,$);


/* Pilar 2 - Restries n inferior - Fixo */
#245= IFCBOUNDARYNODECONDITION
('Fixed',IFCBOOLEAN(.T.),IFCBOOLEAN(.T.),IFCBOOLEAN(.T.),IFCBOOLEAN(.T.),IFCBOOLEAN
(.T.),IFCBOOLEAN(.T.));

/* Pilar 2 - N superior */
#246= IFCCARTESIANPOINT ((5.5,0.,3.));
#247= IFCVERTEXPOINT (#246);
#248= IFCTOPOLOGYREPRESENTATION (#202,'Reference','Vertex',(#247));
#249= IFCPRODUCTDEFINITIONSHAPE ($,$,(#248));
#250= IFCSTRUCTURALPOINTCONNECTION ('2mc6ibF258HPIpTmqg6DSl',#5,'Point Connection
3',$,$,$,#249,#251,$);

/* Pilar 2 - Restries n superior - Livre */
#251= IFCBOUNDARYNODECONDITION
('Free',IFCBOOLEAN(.F.),IFCBOOLEAN(.F.),IFCBOOLEAN(.F.),IFCBOOLEAN(.F.),IFCBOOLEAN(
.F.),IFCBOOLEAN(.F.));

/* Pilar 3 - N Inferior */
#260= IFCCARTESIANPOINT ((0.,5.5,0.));
#261= IFCVERTEXPOINT (#260);
#262= IFCTOPOLOGYREPRESENTATION (#202,'Reference','Vertex',(#261));
#263= IFCPRODUCTDEFINITIONSHAPE ($,$,(#262));
#264= IFCSTRUCTURALPOINTCONNECTION ('3339fAVu96i8mFr0cgUqeI',#5,'Point Connection
5',$,$,$,#263,#265,$);

/* Pilar 3 - Restries n inferior - Fixo */
#265= IFCBOUNDARYNODECONDITION
('Fixed',IFCBOOLEAN(.T.),IFCBOOLEAN(.T.),IFCBOOLEAN(.T.),IFCBOOLEAN(.T.),IFCBOOLEAN
(.T.),IFCBOOLEAN(.T.));

/* Pilar 3 - N superior */
#266= IFCCARTESIANPOINT ((0.,5.5,3.));
#267= IFCVERTEXPOINT (#266);
#268= IFCTOPOLOGYREPRESENTATION (#202,'Reference','Vertex',(#267));
#269= IFCPRODUCTDEFINITIONSHAPE ($,$,(#268));
#270= IFCSTRUCTURALPOINTCONNECTION ('3mc6ibF258HPIpTmqg6DSl',#5,'Point Connection
6',$,$,$,#269,#271,$);

/* Pilar 3 - Restries n superior - Livre */
O Modelo IFC como Agente de Interoperabilidade



122

#271= IFCBOUNDARYNODECONDITION
('Free',IFCBOOLEAN(.F.),IFCBOOLEAN(.F.),IFCBOOLEAN(.F.),IFCBOOLEAN(.F.),IFCBOOLEAN(
.F.),IFCBOOLEAN(.F.));


/* Pilar 4 - N inferior */
#280= IFCCARTESIANPOINT ((5.5,5.5,0.));
#281= IFCVERTEXPOINT (#280);
#282= IFCTOPOLOGYREPRESENTATION (#202,'Reference','Vertex',(#281));
#283= IFCPRODUCTDEFINITIONSHAPE ($,$,(#282));
#284= IFCSTRUCTURALPOINTCONNECTION ('4539fAVu96i8mFr0cgUqeI',#5,'Point Connection
8',$,$,$,#283,#285,$);

/* Pilar 4 - Restries n inferior - Fixo */
#285= IFCBOUNDARYNODECONDITION
('Fixed',IFCBOOLEAN(.T.),IFCBOOLEAN(.T.),IFCBOOLEAN(.T.),IFCBOOLEAN(.T.),IFCBOOLEAN
(.T.),IFCBOOLEAN(.T.));

/* Pilar 4 - N superior */
#286= IFCCARTESIANPOINT ((5.5,5.5,3.));
#287= IFCVERTEXPOINT (#286);
#288= IFCTOPOLOGYREPRESENTATION (#202,'Reference','Vertex',(#287));
#289= IFCPRODUCTDEFINITIONSHAPE ($,$,(#288));
#290= IFCSTRUCTURALPOINTCONNECTION ('4mc6ibF258HPIpTmqg6DSl',#5,'Point Connection
7',$,$,$,#289,#291,$);

/* Pilar 4 - Restries n superior - Livre */
#291= IFCBOUNDARYNODECONDITION
('Free',IFCBOOLEAN(.F.),IFCBOOLEAN(.F.),IFCBOOLEAN(.F.),IFCBOOLEAN(.F.),IFCBOOLEAN(
.F.),IFCBOOLEAN(.F.));


/* Pilar 1 - Membro estrutural (Objecto) */
#300= IFCDIRECTION ((1.,0.,0.));
#301= IFCSTRUCTURALCURVEMEMBER ('3eXlZ8csrAvfIIXVwC_gVP',#5,'Curve Member
1A',$,$,$,#306,.RIGID_JOINED_MEMBER.,#300);
#302= IFCRELCONNECTSSTRUCTURALMEMBER
('1Z9w70JcDEUx6TnggLE2wU',#5,$,$,#301,#224,$,$,$,$);
#303= IFCRELCONNECTSSTRUCTURALMEMBER
('1GClK7cwT80xzpZuaAlGXp',#5,$,$,#301,#230,$,$,$,$);

/* Pilar 1 - Membro estrutural (Representao) */
#304= IFCEDGE (#221,#227);
#305= IFCTOPOLOGYREPRESENTATION (#202,'Reference','Edge',(#304));
#306= IFCPRODUCTDEFINITIONSHAPE ($,$,(#305));


/* Pilar 2 - Membro estrutural (Objecto) */
#310= IFCDIRECTION ((1.,0.,0.));
#311= IFCSTRUCTURALCURVEMEMBER ('3eXlZ8csrAvfIIXVwC_gVP',#5,'Curve Member
2A',$,$,$,#316,.RIGID_JOINED_MEMBER.,#310);
#312= IFCRELCONNECTSSTRUCTURALMEMBER
('2Z9w70JcDEUx6TnggLE2wU',#5,$,$,#311,#244,$,$,$,$);
#313= IFCRELCONNECTSSTRUCTURALMEMBER
('2GClK7cwT80xzpZuaAlGXp',#5,$,$,#311,#250,$,$,$,$);

/* Pilar 2 - Membro estrutural (Representao) */
#314= IFCEDGE (#241,#247);
#315= IFCTOPOLOGYREPRESENTATION (#202,'Reference','Edge',(#314));
#316= IFCPRODUCTDEFINITIONSHAPE ($,$,(#315));


/* Pilar 3 - Membro estrutural (Objecto) */
#320= IFCDIRECTION ((1.,0.,0.));
O Modelo IFC como Agente de Interoperabilidade



123

#321= IFCSTRUCTURALCURVEMEMBER ('3eXlZ8csrAvfIIXVwC_gVP',#5,'Curve Member
3A',$,$,$,#326,.RIGID_JOINED_MEMBER.,#320);
#322= IFCRELCONNECTSSTRUCTURALMEMBER
('3Z9w70JcDEUx6TnggLE2wU',#5,$,$,#321,#264,$,$,$,$);
#323= IFCRELCONNECTSSTRUCTURALMEMBER
('3GClK7cwT80xzpZuaAlGXp',#5,$,$,#321,#270,$,$,$,$);

/* Pilar 3 - Membro estrutural (Representao) */
#324= IFCEDGE (#261,#267);
#325= IFCTOPOLOGYREPRESENTATION (#202,'Reference','Edge',(#324));
#326= IFCPRODUCTDEFINITIONSHAPE ($,$,(#325));


/* Pilar 4 - Membro estrutural (Objecto) */
#330= IFCDIRECTION ((1.,0.,0.));
#331= IFCSTRUCTURALCURVEMEMBER ('3eXlZ8csrAvfIIXVwC_gVP',#5,'Curve Member
4A',$,$,$,#336,.RIGID_JOINED_MEMBER.,#330);
#332= IFCRELCONNECTSSTRUCTURALMEMBER
('4Z9w70JcDEUx6TnggLE2wU',#5,$,$,#331,#284,$,$,$,$);
#333= IFCRELCONNECTSSTRUCTURALMEMBER
('4GClK7cwT80xzpZuaAlGXp',#5,$,$,#331,#290,$,$,$,$);

/* Pilar 4 - Membro estrutural (Representao) */
#334= IFCEDGE (#281,#287);
#335= IFCTOPOLOGYREPRESENTATION (#202,'Reference','Edge',(#334));
#336= IFCPRODUCTDEFINITIONSHAPE ($,$,(#335));


/* Viga 1 - Membro estrutural (Objecto) */
#350= IFCDIRECTION ((0.,0.,1.));
#351= IFCSTRUCTURALCURVEMEMBER ('25vEW7EzrBTvz5cbNWzhP$',#5,'Curve Member
1B',$,$,$,#356,.RIGID_JOINED_MEMBER.,#350);
#352= IFCRELCONNECTSSTRUCTURALMEMBER
('1ZUyJTZMHEev9njAeNDQUT',#5,$,$,#351,#230,$,$,$,$);
#353= IFCRELCONNECTSSTRUCTURALMEMBER
('1Y3WZZzV16XQ$1zEZLWjJX',#5,$,$,#351,#250,$,$,$,$);

/* Viga 1 - Membro estrutural (Representao) */
#354= IFCEDGE (#227,#247);
#355= IFCTOPOLOGYREPRESENTATION (#202,'Reference','Edge',(#354));
#356= IFCPRODUCTDEFINITIONSHAPE ($,$,(#355));


/* Viga 2 - Membro estrutural (Objecto) */
#360= IFCDIRECTION ((0.,0.,1.));
#361= IFCSTRUCTURALCURVEMEMBER ('25vEW7EzrBTvz5cbNWzhP$',#5,'Curve Member
2B',$,$,$,#366,.RIGID_JOINED_MEMBER.,#360);
#362= IFCRELCONNECTSSTRUCTURALMEMBER
('2ZUyJTZMHEev9njAeNDQUT',#5,$,$,#361,#270,$,$,$,$);
#363= IFCRELCONNECTSSTRUCTURALMEMBER
('2Y3WZZzV16XQ$1wEZLWjJX',#5,$,$,#361,#290,$,$,$,$);

/* Viga 2 - Membro estrutural (Representao) */
#364= IFCEDGE (#267,#287);
#365= IFCTOPOLOGYREPRESENTATION (#202,'Reference','Edge',(#364));
#366= IFCPRODUCTDEFINITIONSHAPE ($,$,(#365));


/* Viga 3 - Membro estrutural (Objecto) */
#370= IFCDIRECTION ((1.,0.,0.));
#371= IFCSTRUCTURALCURVEMEMBER ('25vEW7EzrBTvz5cbNWzhP$',#5,'Curve Member
3B',$,$,$,#376,.RIGID_JOINED_MEMBER.,#370);
#372= IFCRELCONNECTSSTRUCTURALMEMBER
('3ZUyJTZMHEev9njAeNDQUT',#5,$,$,#371,#230,$,$,$,$);
O Modelo IFC como Agente de Interoperabilidade



124

#373= IFCRELCONNECTSSTRUCTURALMEMBER
('3Y3WZZzV16XQ$1wEZLWjJX',#5,$,$,#371,#270,$,$,$,$);

/* Viga 3 - Membro estrutural (Representao) */
#374= IFCEDGE (#227,#267);
#375= IFCTOPOLOGYREPRESENTATION (#202,'Reference','Edge',(#374));
#376= IFCPRODUCTDEFINITIONSHAPE ($,$,(#375));


/* Viga 4 - Membro estrutural (Objecto) */
#380= IFCDIRECTION ((1.,0.,0.));
#381= IFCSTRUCTURALCURVEMEMBER ('25vEW7EzrBTvz5cbNWzhP$',#5,'Curve Member
4B',$,$,$,#386,.RIGID_JOINED_MEMBER.,#380);
#382= IFCRELCONNECTSSTRUCTURALMEMBER
('4ZUyJTZMHEev9njAeNDQUT',#5,$,$,#381,#250,$,$,$,$);
#383= IFCRELCONNECTSSTRUCTURALMEMBER
('4Y3WZZzV16XQ$1wEZLWjJX',#5,$,$,#381,#290,$,$,$,$);

/* Viga 4 - Membro estrutural (Representao) */
#384= IFCEDGE (#247,#287);
#385= IFCTOPOLOGYREPRESENTATION (#202,'Reference','Edge',(#384));
#386= IFCPRODUCTDEFINITIONSHAPE ($,$,(#385));


/* Laje 1 - Membro estrutural (Objecto) */
#390= IFCSTRUCTURALSURFACEMEMBER ('50xQG7EzrTYvz5cbDFzhP$',#5,'Surface Member
1C',$,$,$,#400,.BENDING_ELEMENT.,0.22);
#391= IFCSTRUCTURALSURFACECONNECTION ('0mc6ibF258HPIpTmqg6DSl',#5,'Surface
Connection 1',$,$,$,#400,$,$);
#392= IFCRELCONNECTSSTRUCTURALMEMBER
('1ZUyJTZMHEev9njAeNDQUT',#5,$,$,#390,#230,$,$,$,$);
#393= IFCRELCONNECTSSTRUCTURALMEMBER
('2Y3WZZzV16XQ$1wEZLWjJX',#5,$,$,#390,#250,$,$,$,$);
#394= IFCRELCONNECTSSTRUCTURALMEMBER
('3ZUyJTZMHEev9njAeNDQUT',#5,$,$,#390,#270,$,$,$,$);
#395= IFCRELCONNECTSSTRUCTURALMEMBER
('4Y3WZZzV16XQ$1wEZLWjJX',#5,$,$,#390,#290,$,$,$,$);

/* Laje 1 - Membro estrutural (Representao) */
#396= IFCPOLYLOOP ((#226,#246,#286,#266));
#397= IFCFACEOUTERBOUND (#396,.T.);
#398= IFCFACESURFACE ((#397),$,.T.);
#399= IFCTOPOLOGYREPRESENTATION (#202,'Reference','Face',(#398));
#400= IFCPRODUCTDEFINITIONSHAPE ($,$,(#399));


/* Atribuio das ns e membros estruturais ao modelo de anlise estrutural */
#401= IFCRELASSIGNSTOGROUP
('3mDDAcu390$A5orhhUv4qv',#5,$,$,(#224,#230,#301,#244,#250,#311,#264,#270,#321,#284
,#290,#331,#351,#361,#371,#381,#390),.PRODUCT.,#875);

/* ----------------------------------------------------------------------------- */


/* Sapatas - Seco */
#404= IFCRECTANGLEPROFILEDEF (.AREA.,'150x200',#190,1.5,2.0);
#405= IFCEXTRUDEDAREASOLID (#404,#191,#13,0.75);
#406= IFCSHAPEREPRESENTATION (#202,'Body','SweptSolid',(#405));
#407= IFCPRODUCTDEFINITIONSHAPE ($,$,(#406));
#408= IFCPRESENTATIONLAYERASSIGNMENT ('Footing_Profile_A','No
description',(#406),$);
#409= IFCCARTESIANPOINT ((0.0,0.0,-0.75));
#410= IFCAXIS2PLACEMENT3D (#409,$,$);
#411= IFCLOCALPLACEMENT (#192,#410);
O Modelo IFC como Agente de Interoperabilidade



125

#412= IFCFOOTING ('1we2ARoE50netW0RKs4eva',#5,'Sapata
1',$,$,#411,#407,$,.PAD_FOOTING.);
#413= IFCCARTESIANPOINT ((5.5,0.0,-0.75));
#414= IFCAXIS2PLACEMENT3D (#413,$,$);
#415= IFCLOCALPLACEMENT (#192,#414);
#416= IFCFOOTING ('2we2ARoE50netQ4FGs4drw',#5,'Sapata
2',$,$,#415,#407,$,.PAD_FOOTING.);
#417= IFCCARTESIANPOINT ((0.0,5.5,-0.75));
#418= IFCAXIS2PLACEMENT3D (#417,$,$);
#419= IFCLOCALPLACEMENT (#192,#418);
#420= IFCFOOTING ('3we2ARoE50netZ5KPs4ako',#5,'Sapata
3',$,$,#419,#407,$,.PAD_FOOTING.);
#421= IFCCARTESIANPOINT ((5.5,5.5,-0.75));
#422= IFCAXIS2PLACEMENT3D (#421,$,$);
#423= IFCLOCALPLACEMENT (#192,#422);
#424= IFCFOOTING ('4we2ARoE50netX9RTs4thg',#5,'Sapata
4',$,$,#423,#407,$,.PAD_FOOTING.);

/* Pilares - Seco e caractersticas */
#425= IFCRECTANGLEPROFILEDEF (.AREA.,'20x30',$,0.20,0.30);
#426= IFCEXTRUDEDAREASOLID (#425,#191,#13,3.0);
#427= IFCSHAPEREPRESENTATION (#202,'Body','SweptSolid',(#426));
#428= IFCPRESENTATIONLAYERASSIGNMENT ('Columns Profile','No description',(#427),$);
#429= IFCPRODUCTDEFINITIONSHAPE ($,$,(#427));
#430= IFCPROPERTYSINGLEVALUE ('MassPerLength',$,IFCMASSPERLENGTHMEASURE(25),$);
#431= IFCPROPERTYSINGLEVALUE ('CrossSectionArea',$,IFCAREAMEASURE(0.06),$);
#432= IFCPROPERTYSINGLEVALUE
('MomentOfInertiaY',$,IFCMOMENTOFINERTIAMEASURE(0.0002),$);
#433= IFCPROPERTYSINGLEVALUE
('MomentOfInertiaZ',$,IFCMOMENTOFINERTIAMEASURE(0.00045),$);
#434= IFCPROPERTYSINGLEVALUE
('TorsionalSectionModulus',$,IFCSECTIONMODULUSMEASURE(0.622),$);
#435= IFCPROFILEPROPERTIES
('Pset_ProfileMechanical',$,(#430,#431,#432,#433,#434),#425);
#436= IFCCARTESIANPOINT ((0.0,0.0,0.0));
#437= IFCAXIS2PLACEMENT3D (#436,#13,#9);
#438= IFCLOCALPLACEMENT (#192,#437);
#439= IFCCOLUMN ('1fv4DZfY55exwX8QDy8xmw',#5,'Column 1',$,$,#438,#429,$,.COLUMN.);
#440= IFCRELCONNECTSSTRUCTURALELEMENT
('1pDDAft390$A5guwnUv4ac',#5,$,$,(#301),#439);
#441= IFCCARTESIANPOINT ((5.5,0.,0.));
#442= IFCAXIS2PLACEMENT3D (#441,#13,#9);
#443= IFCLOCALPLACEMENT (#192,#442);
#444= IFCCOLUMN ('2ui4PZfD35egqW2RSy4fvw',#5,'Column 2',$,$,#443,#429,$,.COLUMN.);
#445= IFCRELCONNECTSSTRUCTURALELEMENT
('2pDDAft390$A5guwnUv4ac',#5,$,$,(#311),#444);
#446= IFCCARTESIANPOINT ((0.,5.5,0.));
#447= IFCAXIS2PLACEMENT3D (#446,#13,#9);
#448= IFCLOCALPLACEMENT (#192,#447);
#449= IFCCOLUMN ('3ui4PZfD35egqW2RSy4fvw',#5,'Column 3',$,$,#448,#429,$,.COLUMN.);
#450= IFCRELCONNECTSSTRUCTURALELEMENT
('3pDDAft390$A5guwnUv4ac',#5,$,$,(#321),#449);
#451= IFCCARTESIANPOINT ((5.5,5.5,0.));
#452= IFCAXIS2PLACEMENT3D (#451,#13,#9);
#453= IFCLOCALPLACEMENT (#192,#452);
#454= IFCCOLUMN ('4ui4PZfD35egqW2RSy4fvw',#5,'Column 4',$,$,#453,#429,$,.COLUMN.);
#455= IFCRELCONNECTSSTRUCTURALELEMENT
('4pDDAft390$A5guwnUv4ac',#5,$,$,(#331),#454);
#456= IFCRELCONTAINEDINSPATIALSTRUCTURE
('15kVXT9hb7C80NqRflZZF6',#5,$,$,(#439,#444,#449,#454),#196);

/* Vigas - Seco e caractersticas - Direco X */
#476= IFCRECTANGLEPROFILEDEF (.AREA.,'20x40',#190,0.2,0.4);
#477= IFCPROPERTYSINGLEVALUE ('MassPerLength',$,IFCMASSPERLENGTHMEASURE(25),$);
#478= IFCPROPERTYSINGLEVALUE ('CrossSectionArea',$,IFCAREAMEASURE(0.08),$);
O Modelo IFC como Agente de Interoperabilidade



126

#479= IFCPROPERTYSINGLEVALUE
('MomentOfInertiaY',$,IFCMOMENTOFINERTIAMEASURE(0.00027),$);
#480= IFCPROPERTYSINGLEVALUE
('MomentOfInertiaZ',$,IFCMOMENTOFINERTIAMEASURE(0.00107),$);
#481= IFCPROPERTYSINGLEVALUE
('TorsionalSectionModulus',$,IFCSECTIONMODULUSMEASURE(0.622),$);
#482= IFCPROFILEPROPERTIES
('Pset_ProfileMechanical',$,(#477,#478,#479,#480,#481),#476);
#483= IFCEXTRUDEDAREASOLID (#476,#191,#13,5.2);
#484= IFCSHAPEREPRESENTATION (#202,'Body','SweptSolid',(#483));
#485= IFCPRESENTATIONLAYERASSIGNMENT ('Beam Profile','No description',(#484),$);
#486= IFCPRODUCTDEFINITIONSHAPE ($,$,(#484));
#487= IFCCARTESIANPOINT ((0.0,0.15,2.8));
#488= IFCAXIS2PLACEMENT3D (#487,#11,#9);
#489= IFCLOCALPLACEMENT (#192,#488);
#490= IFCBEAM ('1zt8DTaE82lkeQ8FPj5gye',#5,'Beam 1',$,$,#489,#486,$,.BEAM.);
#491= IFCRELCONNECTSSTRUCTURALELEMENT
('1aDDAft390$A5guwnUv4xc',#5,$,$,(#351),#490);
#492= IFCCARTESIANPOINT ((5.5,0.15,2.8));
#493= IFCAXIS2PLACEMENT3D (#492,#11,#9);
#494= IFCLOCALPLACEMENT (#192,#493);
#495= IFCBEAM ('2zt8DTaE82lkeQ8FPj5gye',#5,'Beam 2',$,$,#494,#486,$,.BEAM.);
#496= IFCRELCONNECTSSTRUCTURALELEMENT
('2aDDAft390$A5guwnUv4xc',#5,$,$,(#361),#495);
#497= IFCRELCONTAINEDINSPATIALSTRUCTURE
('25kVXT9hb7C80NqRflZZF6',#5,$,$,(#490,#495),#196);

/* Vigas - Seco e caractersticas - Direco Y */
#526= IFCRECTANGLEPROFILEDEF (.AREA.,'20x30',#190,0.2,0.4);
#527= IFCPROPERTYSINGLEVALUE ('MassPerLength',$,IFCMASSPERLENGTHMEASURE(25),$);
#528= IFCPROPERTYSINGLEVALUE ('CrossSectionArea',$,IFCAREAMEASURE(0.06),$);
#529= IFCPROPERTYSINGLEVALUE
('MomentOfInertiaY',$,IFCMOMENTOFINERTIAMEASURE(0.00027),$);
#530= IFCPROPERTYSINGLEVALUE
('MomentOfInertiaZ',$,IFCMOMENTOFINERTIAMEASURE(0.00107),$);
#531= IFCPROPERTYSINGLEVALUE
('TorsionalSectionModulus',$,IFCSECTIONMODULUSMEASURE(0.622),$);
#532= IFCPROFILEPROPERTIES
('Pset_ProfileMechanical',$,(#527,#528,#529,#530,#531),#526);
#533= IFCEXTRUDEDAREASOLID (#526,#191,#13,5.3);
#534= IFCSHAPEREPRESENTATION (#202,'Body','SweptSolid',(#533));
#535= IFCPRESENTATIONLAYERASSIGNMENT ('Beam Profile','No description',(#534),$);
#536= IFCPRODUCTDEFINITIONSHAPE ($,$,(#534));
#537= IFCCARTESIANPOINT ((0.1,-0.05,2.8));
#538= IFCAXIS2PLACEMENT3D (#537,#9,#11);
#539= IFCLOCALPLACEMENT (#192,#538);
#540= IFCBEAM ('3zt8DTaE82lkeQ8FPj5gye',#5,'Beam 3',$,$,#539,#536,$,.BEAM.);
#541= IFCRELCONNECTSSTRUCTURALELEMENT
('3aDDAft390$A5guwnUv4xc',#5,$,$,(#371),#540);
#545= IFCCARTESIANPOINT ((0.1,5.55,2.8));
#546= IFCAXIS2PLACEMENT3D (#545,#9,#11);
#547= IFCLOCALPLACEMENT (#192,#546);
#548= IFCBEAM ('4zt8DTaE82lkeQ8FPj5gye',#5,'Beam 4',$,$,#547,#536,$,.BEAM.);
#549= IFCRELCONNECTSSTRUCTURALELEMENT
('4aDDAft390$A5guwnUv4xc',#5,$,$,(#381),#548);
#550= IFCRELCONTAINEDINSPATIALSTRUCTURE
('35kVXT9hb7C80NqRflZZF6',#5,$,$,(#540,#548),#196);

/* Laje - Seco e caractersticas */
#600= IFCRECTANGLEPROFILEDEF (.AREA.,$,$,5.3,5.4);
#601= IFCEXTRUDEDAREASOLID(#600,#191,#13,0.22);
#602= IFCSHAPEREPRESENTATION(#202,'Body','SweptSolid',(#601));
#603= IFCPRESENTATIONLAYERASSIGNMENT('Columns Profile','No description',(#602),$);
#604= IFCPRODUCTDEFINITIONSHAPE($,$,(#602));
#605= IFCPROPERTYSINGLEVALUE ('MassPerLength',$,IFCMASSPERLENGTHMEASURE(25),$);
O Modelo IFC como Agente de Interoperabilidade



127

#606= IFCPROPERTYSINGLEVALUE ('CrossSectionArea',$,IFCAREAMEASURE(1.21),$);
#607= IFCPROPERTYSINGLEVALUE
('MomentOfInertiaY',$,IFCMOMENTOFINERTIAMEASURE(3.05),$);
#608= IFCPROPERTYSINGLEVALUE
('MomentOfInertiaZ',$,IFCMOMENTOFINERTIAMEASURE(0.00488),$);
#609= IFCPROPERTYSINGLEVALUE
('TorsionalSectionModulus',$,IFCSECTIONMODULUSMEASURE(0.622),$);
#610= IFCPROFILEPROPERTIES
('Pset_ProfileMechanical',$,(#605,#606,#607,#608,#609),#600);
#611= IFCCARTESIANPOINT ((2.75,2.75,2.78));
#612= IFCAXIS2PLACEMENT3D (#611,#13,#9);
#613= IFCLOCALPLACEMENT (#192,#612);
#614= IFCSLAB ('1srmDN46zBVupUF9xps7Ev',#5,'Laje 1',$,$,#613,#604,$,.FLOOR.);
#615= IFCRELCONNECTSSTRUCTURALELEMENT
('9aDDAft390$A5gnwnUv1xc',#5,$,$,(#390),#614);
#616= IFCRELCONTAINEDINSPATIALSTRUCTURE
('45kVXT9hb7C80NqRflZZF6',#5,$,$,#614,#196);

/* ----------------------------------------------------------------------------- */


/* Material e propriedades */
/* Pilares - Propriedades do material */
#700= IFCMATERIAL ('C20/25',$,'Concrete');
#701= IFCPROPERTYSINGLEVALUE ('MassDensity',$,IFCMASSDENSITYMEASURE(2407.31),$);
#702= IFCMATERIALPROPERTIES ('Pset_MaterialCommon',$,(#701),#700);
#703= IFCPROPERTYSINGLEVALUE
('YoungModulus',$,IFCMODULUSOFELASTICITYMEASURE(23250000000),$);
#704= IFCPROPERTYSINGLEVALUE
('ShearModulus',$,IFCMODULUSOFELASTICITYMEASURE(9964000000),$);
#705= IFCMATERIALPROPERTIES ('Pset_MaterialMechanical',$,(#703,#704),#700);
#706= IFCPROPERTYSINGLEVALUE ('ConstructionMethod',$,'In-Situ',$);
#707= IFCPROPERTYSINGLEVALUE ('StructuralClass',$,'S1',$);
#708= IFCPROPERTYSINGLEVALUE ('StrengthClass',$,'C20/25',$);
#709= IFCPROPERTYSINGLEVALUE ('ExposureClass',$,'XC4',$);
#710= IFCPROPERTYSINGLEVALUE
('ReinforcementVolumeRatio',$,IFCMASSDENSITYMEASURE(280),$);
#711= IFCPROPERTYSINGLEVALUE ('ConstructionToleranceClass',$,'cm',$);
#712= IFCPROPERTYSINGLEVALUE ('ConcreteCover',$,IFCPOSITIVELENGHTMEASURE(0.025),$);
#713= IFCPROPERTYSINGLEVALUE ('ReinforcementStrengthClass',$,'S500',$);
#714= IFCPROPERTYSET
('75Mvg9UeH5Y9J2VB46x085',#5,'Pset_ConcreteElementGeneral',$,(#706,#707,#708,#709,#
710,#711,#712,#713));
#715= IFCRELDEFINESBYPROPERTIES
('1vnzm4QtjFRRfqpE2lddL5',#5,$,$,(#301,#311,#321,#331,#439,#444,#449,#454),#714);
#716= IFCMATERIALPROFILE ($,$,#700,#425,$,$);
#717= IFCMATERIALPROFILESET ($,$,(#716),$);
#718= IFCMATERIALPROFILESETUSAGE (#717,$,$);
#719= IFCRELASSOCIATESMATERIAL
('01kVXT9hb7C80NqRflZZF9',#5,$,$,(#301,#311,#321,#331,#439,#444,#449,#454),#718);

/* Vigas - Propriedades do material */
#750= IFCMATERIAL ('C20/25',$,'Concrete');
#751= IFCPROPERTYSINGLEVALUE ('MassDensity',$,IFCMASSDENSITYMEASURE(2407.31),$);
#752= IFCMATERIALPROPERTIES ('Pset_MaterialCommon',$,(#751),#750);
#753= IFCPROPERTYSINGLEVALUE
('YoungModulus',$,IFCMODULUSOFELASTICITYMEASURE(23250000000),$);
#754= IFCPROPERTYSINGLEVALUE
('ShearModulus',$,IFCMODULUSOFELASTICITYMEASURE(9964000000),$);
#755= IFCMATERIALPROPERTIES ('Pset_MaterialMechanical',$,(#753,#754),#750);
#756= IFCPROPERTYSINGLEVALUE ('ConstructionMethod',$,'In-Situ',$);
#757= IFCPROPERTYSINGLEVALUE ('StructuralClass',$,'S1',$);
#758= IFCPROPERTYSINGLEVALUE ('StrengthClass',$,'C20/25',$);
#759= IFCPROPERTYSINGLEVALUE ('ExposureClass',$,'XC4',$);
O Modelo IFC como Agente de Interoperabilidade



128

#760= IFCPROPERTYSINGLEVALUE
('ReinforcementVolumeRatio',$,IFCMASSDENSITYMEASURE(280),$);
#761= IFCPROPERTYSINGLEVALUE ('ConstructionToleranceClass',$,'cm',$);
#762= IFCPROPERTYSINGLEVALUE ('ConcreteCover',$,IFCPOSITIVELENGHTMEASURE(0.025),$);
#763= IFCPROPERTYSINGLEVALUE ('ReinforcementStrengthClass',$,'S500',$);
#764= IFCPROPERTYSET
('08Mvg9UeH5Y9J2VB46x085',#5,'Pset_ConcreteElementGeneral',$,(#756,#757,#758,#759,#
760,#761,#762,#763));
#765= IFCRELDEFINESBYPROPERTIES
('2vnzm4QtjFRRuupE2lddL3',#5,$,$,(#351,#361,#371,#381,#490,#495,#540,#548),#764);
#766= IFCMATERIALPROFILE ($,$,#750,#476,$,$);
#767= IFCMATERIALPROFILESET ($,$,(#766),$);
#768= IFCMATERIALPROFILESETUSAGE (#767,$,$);
#769= IFCRELASSOCIATESMATERIAL
('21kVXT9hb7C80NqRflZZF4',#5,$,$,(#351,#361,#371,#381,#490,#495,#540,#548),#768);


/* Lajes - Propriedades do material */
#806= IFCMATERIAL ('C20/25',$,'Concrete');
#807= IFCPROPERTYSINGLEVALUE ('MassDensity',$,IFCMASSDENSITYMEASURE(2407.31),$);
#808= IFCMATERIALPROPERTIES ('Pset_MaterialCommon',$,(#807),#806);
#809= IFCPROPERTYSINGLEVALUE
('YoungModulus',$,IFCMODULUSOFELASTICITYMEASURE(23250000000),$);
#810= IFCPROPERTYSINGLEVALUE
('ShearModulus',$,IFCMODULUSOFELASTICITYMEASURE(9964000000),$);
#811= IFCMATERIALPROPERTIES ('Pset_MaterialMechanical',$,(#809,#810),#806);
#812= IFCPROPERTYSINGLEVALUE ('ConstructionMethod',$,'In-Situ',$);
#813= IFCPROPERTYSINGLEVALUE ('StructuralClass',$,'S1',$);
#814= IFCPROPERTYSINGLEVALUE ('StrengthClass',$,'C20/25',$);
#815= IFCPROPERTYSINGLEVALUE ('ExposureClass',$,'XC4',$);
#816= IFCPROPERTYSINGLEVALUE
('ReinforcementVolumeRatio',$,IFCMASSDENSITYMEASURE(280),$);
#817= IFCPROPERTYSINGLEVALUE ('ConstructionToleranceClass',$,'cm',$);
#818= IFCPROPERTYSINGLEVALUE ('ConcreteCover',$,IFCPOSITIVELENGHTMEASURE(0.025),$);
#819= IFCPROPERTYSINGLEVALUE ('ReinforcementStrengthClass',$,'S500',$);
#820= IFCPROPERTYSET
('42Mvg9UeH5Y9J2VB46x085',#5,'Pset_ConcreteElementGeneral',$,(#812,#813,#814,#815,#
816,#817,#818,#819));
#821= IFCRELDEFINESBYPROPERTIES ('3vnzm4QtjFRRfqpE2lddL5',#5,$,$,(#390,#614),#820);
#822= IFCMATERIALPROFILE ($,$,#806,#600,$,$);
#823= IFCMATERIALPROFILESET ($,$,(#822),$);
#824= IFCMATERIALPROFILESETUSAGE (#823,$,$);
#825= IFCRELASSOCIATESMATERIAL ('31kVXT9hb7C80NqRflZZF6',#5,$,$,(#390,#614),#824);

/* Pilares - Identificao de Propriedades - Dimenses */
#850= IFCPROPERTYSINGLEVALUE ('a',$,IFCLENGTHMEASURE(0.2),$);
#851= IFCPROPERTYSINGLEVALUE ('b',$,IFCLENGTHMEASURE(0.3),$);
#852= IFCPROPERTYSET ('08Mvg9UeH5Y9J2VB46x085',#5,'Dimensions',$,(#850,#851));
#853= IFCRELDEFINESBYPROPERTIES
('2vnzm4QtjFRRuupE2lddL3',#5,$,$,(#439,#444,#449,#454),#852);

/* ----------------------------------------------------------------------------- */


/* Modelo de anlise estrutural */
#875= IFCSTRUCTURALANALYSISMODEL ('0VYesmxUHFNez26MoJx5F3',#5,'Structural Analysis
1',$,$,.NOTDEFINED.,#191,(#900,#910,#920,#930),$,#192);
#876= IFCRELDECLARES ('1Frhk31Z12CR9mBbodz9XE',#5,'GROUP',$,#180,(#875));


/* Caso de carga 1 */
#900= IFCSTRUCTURALLOADCASE ('1fv4DZfY55exwX8QDy8dmw',#5,'Structural Load Case
1',$,$,.LOAD_CASE.,.NOTDEFINED.,.NOTDEFINED.,1.,$,(0.,0.,0.));

/* Pilar 1 - Carga linear */
O Modelo IFC como Agente de Interoperabilidade



129

#901= IFCSTRUCTURALLOADLINEARFORCE ('Nominal',$,$,-1.64,$,$,$);
#902= IFCSTRUCTURALLOADLINEARFORCE ('Nominal',$,$,-1.64,$,$,$);
#903= IFCSTRUCTURALLOADCONFIGURATION ($,(#901,#902),((0.),(3.)));
#904= IFCSTRUCTURALCURVEACTION ('1WSwGyLsrFNA9TLOq_ifyd',#5,'Structural Curve
Action 1',$,$,$,$,#903,.GLOBAL_COORDS.,.F.,$,.LINEAR.);
#905= IFCRELCONNECTSSTRUCTURALACTIVITY ('0XvroPpOb4FPsGBZQ$pgtA',#5,$,$,#301,#904);
#906= IFCRELASSIGNSTOGROUP ('1OygXKIkL35eDtUalQjese',#5,$,$,(#904),.PRODUCT.,#900);


/* Caso de carga 2 */
#910= IFCSTRUCTURALLOADCASE ('2fv4DZfY55exwX8QDy8dmw',#5,'Structural Load Case
2',$,$,.LOAD_CASE.,.NOTDEFINED.,.NOTDEFINED.,1.,$,(0.,0.,0.));

/* Pilar 1 - Carga pontual */
#911= IFCSTRUCTURALLOADSINGLEFORCE ('Fora 1',$,$,-2.54,$,$,$);
#912= IFCSTRUCTURALLOADCONFIGURATION ($,(#911),((3.)));
#913= IFCSTRUCTURALPOINTACTION ('2WSwGyLsrFNA9TLOq_ifyd',#5,'Structural Point
Action 1',$,$,$,$,#912,.GLOBAL_COORDS.,.F.);
#914= IFCRELCONNECTSSTRUCTURALACTIVITY ('1XvroPpOb4FPsGBZQ$pgtA',#5,$,$,#321,#913);
#915= IFCRELASSIGNSTOGROUP ('2OygXKIkL35eDtUalQjese',#5,$,$,(#913),.PRODUCT.,#910);


/* Caso de carga 3 */
#920= IFCSTRUCTURALLOADCASE ('3fv4DZfY55exwX8QDy8dmw',#5,'Structural Load Case
3',$,$,.LOAD_CASE.,.NOTDEFINED.,.NOTDEFINED.,1.,$,(0.,0.,0.));

/* Viga 1 - Carga trapezoidal */
#921= IFCSTRUCTURALLOADLINEARFORCE ('Nominal',5,$,$,$,$,$);
#922= IFCSTRUCTURALLOADLINEARFORCE ('Nominal',2,$,$,$,$,$);
#923= IFCSTRUCTURALLOADCONFIGURATION ($,(#921,#922),((0.),(5.5)));
#924= IFCSTRUCTURALCURVEACTION ('3WSwGyLsrFNA9TLOq_ifyd',#5,'Structural Curve
Action 2',$,$,$,$,#923,.GLOBAL_COORDS.,.F.,$,.LINEAR.);
#925= IFCRELCONNECTSSTRUCTURALACTIVITY ('6XvroPpOb4FPsGBZQ$pgtA',#5,$,$,#351,#924);
#926= IFCRELASSIGNSTOGROUP ('3OygXKIkL35eDtUalQjese',#5,$,$,(#924),.PRODUCT.,#920);


/* Caso de carga 4 */
#930= IFCSTRUCTURALLOADCASE ('4fv4DZfY55exwX8QDy8dmw',#5,'Structural Load Case
4',$,$,.LOAD_CASE.,.NOTDEFINED.,.NOTDEFINED.,1.,$,(0.,0.,0.));

/* Laje 1 - Carga uniformemente distribuida */
#931= IFCSTRUCTURALLOADPLANARFORCE ('Nominal',$,$,-4);
#932= IFCSTRUCTURALLOADCONFIGURATION ($,(#931),((0.)));
#933= IFCSTRUCTURALPLANARACTION ('4WSwGyLsrFNA9TLOq_ifyd',#5,'Structural Planar
Action 1',$,$,$,$,#932,.GLOBAL_COORDS.,.F.,$,.CONST.);
#934= IFCRELCONNECTSSTRUCTURALACTIVITY ('0XvroPpOb4FPsGBZQ$pgtA',#5,$,$,#390,#933);
#935= IFCRELASSIGNSTOGROUP ('4OygXKIkL35eDtUalQjese',#5,$,$,(#933),.PRODUCT.,#930);


ENDSEC;

END-ISO-10303-21;

Potrebbero piacerti anche