Você está na página 1de 254

CERVANTESAYRESFILHO

ACESSOAOMODELOINTEGRADODOEDIFCIO
CURITIBA 2009

CERVANTESAYRESFILHO

ACESSOAOMODELOINTEGRADODOEDIFCIO
Dissertao apresentada como requisito parcialparaaobtenodograudeMestre pelo Programa de PsGraduao em ConstruoCivildoSetordeTecnologiada UniversidadeFederaldoParan. Orientador:ProfessorDr.SergioScheer CURITIBA Fevereiro2009

Sumrio
1 2 3 4 ListadeFiguras ListadeAnexos Resumo Abstract Introduo 1.1 Problemadepesquisa 1.2 Objetivo 1.3 Estruturadadissertao ModelagemdeProduto 2.1 Ainformticaeodesenvolvimentodeprodutos 2.1.1 OprincpiodoCAD 2.1.2 Oprincpiodamodelagemdeproduto 2.2 Evoluodosmodelosdeprodutos 2.2.1 Modelogeomtrico 2.2.2 Modelovariacional 2.2.3 Modelobaseadoemrestries 2.2.4 Modeloparamtrico 2.2.5 Modelobaseadoemcaractersticas(features) 2.3 Modelosdedadosdeprodutos 2.3.1 Bancosdedados 2.3.2 Semntica 2.3.3 Orientaoaobjetos 2.3.4 STEP 2.4 Amodelagemdeprodutoeocontextodasuaimplantao 2.5 Perspectivasparaamodelagemdeproduto ModelagemdeProdutonaIndstriadaConstruo 3.1 Origensdamodelagemdeprodutonaindstriadaconstruo 3.1.1 BIM 3.2 EscopodaBIM 3.2.1 ClassificaodaBIMpornveldeabstrao 3.3 Objetos 3.3.1 Parmetros 3.3.2 Comportamento 3.4 Modelo 3.4.1 Semntica 3.5 Modelagem 3.5.1 Automatizaodadocumentao 3.5.2 Organizaodadocumentao 3.5.3 Consistnciadainformao 3.5.4 Generalizaoeextensibilidade 3.6 Metamodelagem 3.6.1 Interoperabilidade 3.6.2 IFCIndustryFoundationClasses 3.7 PerspectivasparaaBIM AcessoaoModeloIntegradodoEdifcio 4.1 Script:objetosparamtricosrepresentandoparedesdeblocos 4.1.1 Definiodoproblema 4.1.2 Abordagemproposta 4.1.3 Desenvolvimentodoexperimento 4.1.4 Discusso 4.2 Script:EEQuantquantificaodeenergiaembutidaeemissodeCO2 4.2.1 Definiodoproblema iv vi vii viii 1 3 4 4 6 7 8 11 13 13 14 15 15 16 18 19 21 23 24 27 29 31 35 39 40 41 43 44 46 50 52 54 55 56 58 59 60 62 64 70 75 79 79 84 84 90 91 92

ii

5 6

4.2.2 Abordagemproposta 4.2.3 Desenvolvimentodoexperimento 4.2.4 Utilizaodaferramenta 4.2.5 Discusso 4.3 Plugin:aplicaoparaexportaodedadosdoArchiCAD 4.3.1 Definiodoproblema 4.3.2 Abordagemproposta 4.3.3 Desenvolvimentodoexperimento 4.3.4 Discusso 4.4 Acessodemodelosnoformato IFCSPF 4.4.1 Definiodoproblema 4.4.2 Desenvolvimentodoexperimento 4.4.3 Discusso 4.5 Acessodemodelosnoformato ifcXML 4.5.1 ifcXML 4.5.2 Definiodoproblema 4.5.3 Desenvolvimentodoexperimento 4.5.4 Discusso ConsideraesFinais 5.1 Sugestoparatrabalhosfuturos:metacompilaodeentidades Referncias

93 94 101 106 107 107 109 109 113 114 114 115 119 120 120 121 122 132 133 136 140

iii

ListadeFiguras
Fig.3.01 Fig.3.02 Fig.3.03 Fig.3.04 Fig.3.05 Fig.4.01 Fig.4.02 Fig.4.03 Fig.4.04 Fig.4.05 Fig.4.06 Fig.4.07 Fig.4.08 Fig.4.09 Fig.4.10 Fig.4.11 Fig.4.12 Fig.4.13 Fig.4.14 Fig.4.15 Fig.4.16 Fig.4.17 Fig.4.18 Fig.4.19 Fig.4.20 Fig.4.21 Fig.4.22 Fig.4.23 Fig.4.24 Fig.4.25 janeladeconfiguraodosparmetrosderepresentaodeumobjetoparedeno ArchiCAD. atualizao automtica da representao do objeto quando a escala de representaoemplantamodificadade1:20para1:100,noArchiCAD. diferentesrepresentaesgrficasinstanciadasapartirdeummesmoobjetodoor doArchiCAD representaoporprimitivosgeomtricoseapossibilidadedeperdadesignificado apsoperaessobreoselementosindividuais. a representao por objetos paramtricos em um BIM CAD mantm o significado dainformaoapsoperaesdemodificao. esquema dos mtodos de acesso ao modelo integrado do edifcio utilizado neste trabalho. representaoemplantaeperspectivadeduasparedesdeblocosdeconcreto. Representaes das paredes de blocos de concreto usando elementos nativos do ArchiCAD representaodasparedesdeblocoscompadresdelinhas(linetemplates). representao das paredes de blocos com elementos slab configurados para assemelharemseablocosdeconcreto parte do cdigo GDL que gera uma forma prismtica representando um bloco de concreto. janeladeconfiguraodemetaparmetrosdoArchiCAD. Inserodosobjetosparamtricosemplanta. paineldeconfiguraodeparmetrosadicionais. representaesdasparedesdeblocosdeconcretogeradasautomaticamentepelo objetoparamtricocriado. representaesautomticasgeradasdeacordocomocontextodoobjeto modelo de edifcio composto por vrias instncias do objeto paramtrico associadasaobjetosnativosdoArchiCAD. planta de fiada extrada automaticamente a partir dos objetos paramtricos mostradosnafigura4.12. janeladeediodoArchiCADondesocriadasbasesdedadosauxiliares janela de configurao do property object denominado Concrete mostrando as relaesentreoscomponenteseovolumedoelementoconstrutivo. partedoscriptGDLutilizadonopropertyobject MasonryWall,responsvelpela discriminaodosmateriaisnasdiferentescamadasdeparedesdealvenaria. janeladegerenciamentodasregrasdeassociaoautomtica. configuraodocritrioparaassociaoautomticaaoproperty objectConcrete (esquerda)eaopropertyobjectCeramicTiles(External)(direita). associao manual do property object Composites na janela de configurao de umelementoconstrutivonativo(nessecaso,wall). configuraodocontedoaserapresentadoemumalistadequantificaonabase dedadosEEQuant. seleo do material de preenchimento durante a criao de um objeto que ir representarumalaje. janeladeconfiguraodosparmetrosdeumobjetorepresentandoumalaje. listaestendida,mostrandoosndicesdeconsumodeenergiaeemissodeCO2na fabricaodecadaumdosmateriaisutilizados. listaresumida,mostrandoapenasatotalizaodosndices. modelo criado para exemplificar o uso da ferramenta EEQuant, em perspectiva e planta 45 47 47 51 53 77 80 81 82 83 85 86 87 87 88 89 89 90 95 97 98 99 100 100 101 102 103 104 104 105

iv

Fig.4.26 Fig.4.27 Fig.4.28 Fig.4.29

arquivodeentradadedadosdosistemaMestre,apartirdosquaissoconstrudas asrepresentaesdoselementosconstrutivos. diagramademonstrandoaoperaodesegmentaodosobjetoswall. conjunto de paredes criado no ArchiCAD para testar a exportao para o sistema Mestre. arquivodeexportaogeradoapartirdoconjuntodeparedesdafigura4.28.

108 111 112 113

ListadeAnexos
ApndiceA ApndiceB ApndiceC ApndiceD ApndiceE ApndiceF ApndiceG Artigospublicadosduranteosestudos Scriptsdoobjetoparamtricoquerepresentaparedesdeblocosdeconcreto ScriptsEEQuant ListasdeemissesgeradaspelaEEQuant CdigofontedaaplicaoAC10Mestre ArquivoifcXMLwall CdigofontedaaplicaodetestedeacessoifcXML

vi

Resumo

modelagemdeprodutonaconstruo,atualmenteconhecidapelotermoBIM(Building

Information Modeling) uma ferramenta com reconhecido potencial para aumentar

significativamenteaqualidadedosprocessosedosprodutosdaindstriadaconstruocivil.A suaprincipalferramentaomodelodoedifcio,umrepositriodeinformaesacessadopor todos os profissionais envolvidos no desenvolvimento do edifcio, da sua concepo sua construo,manutenoedisposiofinal.Omodelodoedifciorepresentaascaractersticas fsicasefuncionaisdoscomponentesdaedificao,emumambientemultidimensionalonde elas podem ser testadas e aprimoradas antes do incio das obras. Diferentes disciplinas da construo utilizam aplicaes computacionais prprias que acessam o modelo do edifcio, extraemeprocessamosdados,eproduzeminformaesquesoentoagregadasaomodelo, refinandoo incrementalmente. Os mtodos para acessar os dados contidos nos modelos, porm,aindasopoucodocumentadosedisseminadosentreosprofissionaisdeTecnologiade Informao ligados indstria da construo. Nesta pesquisa, primeiramente, foram levantadasasdiversasformasdeacessarosdadosdemodelosdeedifcios,utilizandoseum formato proprietrio (ArchiCAD PLN) e um neutro (IFC). Em seguida foram realizados experimentos com desenvolvimento de pequenos aplicativos para demonstrar a acessibilidade,facilidadeedisponibilidadedeferramentasparaasformasdeacesso.Esperase comotrabalhocontribuirparaadisseminaodeprticasquefacilitemodesenvolvimentode aplicaesparaaindstriadaconstruo,dentrodoambienteBIM. Palavraschave:Modelagemdeprodutonaconstruo,BIM,ModeloIntegradodoEdifcio.

vii

Abstract

he practice of modeling products is largely recognized by its capacity of increasing significantly the quality of industrys processes and products. In AEC Industry, product

modelingisnowadaysbetterknownbythetermBuildingInformationModeling(BIM).BIMs main tool is the Building Model, an information repository that is shared by all enrolled professionals during the design and building activities, all over the buildings life cycle. A BuildingModelholdsallphysicalandfunctionalcharacteristicsofthebuildingscomponents, in a multidimensional environment where they can be tested and improved before the construction itself begins. Different AEC disciplines use different computer applications to access the model, extract and process data, and generate new information, which are then incorporated to the model, thus refining it incrementally. However, methods for accessing model data still are poorly documented and disseminated between AEC Industrys IT professionals. In this work, several ways for accessing BM data were researched, including a proprietary model format (ArchiCAD PLN) and a neutral one (IFC). After these first experiments,othersmallapplicationsweredevelopedtoshowtheaccessibility,easinessand availabilityofprogrammingtoolsforeachaccessmethodandmodelformat.Thepeculiarities of each tested method, as well as the algorithms and the data produced during the experiments are shown. The work intended to contribute for the spreading of practices that facilitatetheapplicationdevelopmentfortheAECIndustrytakingintoaccounttheincreasing adoptionofBIM. Keywords:BuildingProductModeling,BIM,BuildingIntegratedModel

viii

1
Introduo
Assessingtheimpactoftechnologicalrevolutionsespeciallyfastpacedoneslikethoseinducedby informationtechnologyisdifficult,especiallywhenwearestillinthemidst,ifnotatthevery beginningoftherevolutionYehudaKalay,2005.

indstria da construo vem sendo pressionada por mudanas na forma de

produoemdecorrnciadefatoreseconmicosesociaisocorridosnasltimas

dcadas (NASCIMENTO e SANTOS, 2003). crescente o nvel de conscientizao da populao a respeito dos impactos da sociedade, do mercado e do prprio Estado sobre o meio ambiente, e o amadurecimento da sociedade civil (NOVAES, 1996). O reconhecimento dos direitos do consumidor trouxe a necessidade de processos gerenciais que garantam a qualidade dos produtos e servios, bem como a sua conformidade com sistemas de normatizao nacionais e internacionais (PAULA e MELHADO, 2005). Ao mesmo tempo, a popularizao da informtica modificou a relao das pessoas com a tecnologia, e transformou consideravelmente tanto o prprioprocessodeprojetodeedifciosquantossuasdemandas(KOWALTOWSKIet al., 2006). A busca por vantagens competitivas tornase rapidamente assunto de extrema importncia, visto que menores custos e prazos de entrega, servios mais flexveisesoluesdiferenciadasoupersonalizadassocadavezmaisexigidos,alm dabviaqualidadedasoluoprojetual(MELHADOeGRILO,2003). Nafasedeprojetossodefinidasasprincipaisdiretrizesdosempreendimentos naindstriadaconstruo.Elateminflunciadiretanoscustos,prazosemtodosde produo (MELHADO, 1994; TZORTZOPOULOS, 1999; MELHADO e AQUINO, 2001; BERTEZINI,2006).Portanto,umbomprocessodeprojeto,conduzidocomoauxliode ferramentas de tecnologia de informao adequadas, um pilar fundamental para a qualidadedosprocessosdeconstruoedosedifciosresultantes(MOUM,2006).Em 1982,oConstructionIndustryInstitute(CII),dosEstadosUnidos,publicouumrelatrio defendendo os benefcios obtidos pelo investimento na qualidade do projeto, no sentidoderacionalizaraconstruocivil.Norelatriofoiestimadoqueoinvestimento

na melhoria dos projetos pode resultar em uma economia de at vinte vezes o seu valor na fase de execuo das obras. Cinco anos aps, o CII publicou um guia para implementao dos conceitos de construtibilidade a capacidade do projeto em fomentar a economia de recursos, segurana e facilidade de uso durante o ciclo de vidadoedifcio,atendendoperfeitamentesespecificaesdocliente.Dosquatorze tpicos abordados neste guia, seis pertenciam fase de concepo do projeto, sete pertenciam fase de desenvolvimento do projeto e contratao de empreiteiros, e apenas um fase de execuo da obra (LAM et al., 2005). No Brasil, o Programa SetorialdeQualidade(PSQ)definiuamelhoriadosprojetoscomoelementoessencial na obteno de maior qualidade e processos mais racionalizados na indstria da construo(PSQ,1997). Em consequncia da sua relevncia para a totalidade do processo de construo, a fase de projetos, quando mal conduzida, responsvel por boa parte dos problemas ocorridos nas fases subsequentes. Estudos indicam que erros na documentao da construo so responsveis pela maiorparte das falhas ocorridas nasobras.NaEuropa,errosefaltadeinformaonoprojetosocausasde36a49% das falhas nas construes, e no Brasil, pesquisa de 1989 indicava o projeto como origem de 46% destas falhas, contra 22% oriundas da execuo da obra (MELHADO, 1994). Em pesquisa mais recente, foi demonstrado que projetos inadequados eram responsveis por 60% dos defeitos patolgicos apresentados pelas construes estudadas(AMBROZEWICZ,2003).Fabrcioeoutrosautorescitamentreasprincipais deficincias dos projetos a ausncia de informaes necessrias s atividades de produodoedifcio,oumesmoadesconsideraodafasedeproduonassolues adotadaspeloprojeto.Issolevaasequipesdeobraadecidirporsiprpriasarespeito dascaractersticasquenoforamespecificadasnoprojeto(FABRICIOetal.,1998).Por estes motivos, atualmente existe na comunidade da construo a conscincia da relaodiretaentreamelhoriadoprocessodeprojetoeosucessonoestabelecimento de novos critrios de qualidade e competitividade para a indstria da construo, tantonoBrasilcomoemoutrospases(ROMANOetal.,2001). Oprocessodeprojetoessencialmenteumasequnciadeaprimoramentosem um conjunto de informaes a ser transmitido para as fases subsequentes. Mesmo
2

pequenosprojetosnaindstriadaconstruoproduzemumaenormequantidadede informao, e por isso os benefcios do uso de tecnologias da informao (TIs) so bvios. Entretanto, h uma grande distncia entre a pesquisa em tecnologia da informao aplicada construo civil e o os mtodos realmente praticados pela indstria no cotidiano, tanto no Brasil como nos outros pases. A indstria da construo tem um carter eminentemente conservador, o que torna difcil a incorporaodosavanoseamantmtecnologicamenteatrasadaemrelaoaoutros segmentosdaindstria.(NASCIMENTOeSANTOS,2002). Mesmoossistemasdeinformaojexistentes,quejpoderiamserutilizados como apoio ao projeto, so pouco aplicados na prtica profissional. Bertezini (2006), estudando empresas do setor, ressalta que os mtodos de retroalimentao e identificao das informaes necessrias tomada de decises so ineficazes, dificultandoaformaodeumcorpodeconhecimentos.Ainexistnciadeumsistema de informaes na fase de projeto resulta na reincidncia em falhas j apresentadas emoutrassituaesenoaumentodoscustosoperacionais. Aindanohmtodosconsolidadosparaaavaliaodoimpactodautilizao de sistemas de informao no processo de projeto (NASCIMENTO e SANTOS, 2002; LOVEetal.,2005;PEANSUPAPeWALKER,2005).Pormhperspectivaspromissoras emtermosdereduodetempoeaumentodaqualidadedadocumentaoproduzida pela utilizao de modelos tridimensionais integrados e com grande contedo semntico no lugar de desenhos bidimensionais desconectados, num processo conhecido como modelagem de produto na construo (RIVARD, 2000; TSE et al., 2005;BIRX,2006;MIKALDO,2006;HARTMANNeFISCHER,2008).

1.1Problemadepesquisa
A modelagem de produto na construo pode proporcionar um melhor gerenciamento dos fluxos de informaes e das suas transformaes durante as atividadesrealizadasemtodoociclodevidadoedifcio,daconcepoconstruo, utilizaoedemolio.Aprincipalferramentanesteprocessoomodelodoedifcio, um repositrio integrado de informaes acessado por todos os envolvidos no desenvolvimento do edifcio. Durante o processo de projetos, idealmente, as
3

diferentesdisciplinasdaconstruoutilizariamaplicaesespecializadasparaextraire processarosdadosdomodelo,realizandoanliseseproduzindoinformaesqueso entoagregadasaele.Ainformaoacrescentadaporcadaaplicaoseriareutilizada pelos outros envolvidos no projeto, em um processo de refinamento incremental do modelo.Essaabordagemgerariaumambientedeconstruovirtual,noqualtodas ascaractersticasdoedifciopoderiamsertestadaseaprimoradasantesdoinciodas obras.Porm,osmtodospararealizaresteacessoaosdadosdosmodelosaindaso pouco documentados e pouco utilizados, limitando o desenvolvimento de um maior nmerodeaplicaesparaesteambientecooperativo.

1.2Objetivodotrabalho
O objetivo do presente trabalho avaliar, com relao acessibilidade, facilidadeeferramentasdisponveis,asdiferentesformasparaacessarosmodelosde edifcios e extrair dados que podem ento ser processados para a gerao de novas informaes automaticamente. Primeiramente apresentada uma reviso das principais caractersticas da modelagem de produto na construo, e a sua relao com os mtodos de desenvolvimento de projetos atualmente empregados na indstria.Emseguidasorelatadososdesenvolvimentoseosresultadosdeumasrie de experimentos com as vrias formas de acesso aos modelos de edifcios e as ferramentasnecessriasparacadauma.

1.3Estruturadadissertao
Esta dissertao dividida em duas partes principais: a reviso das caractersticas da modelagem de produto (captulos 2 e 3) e o desenvolvimento de experimentos de acesso aos dados dos modelos de edifcios (captulos 4 e 5). O presentecaptulointroduzrapidamenteoleitoraocontextoedesafiosdaindstriada construo.Osdemaiscaptulosdesenvolvemotemanaseguinteordem: Captulo2:soapresentadososprincpiosdamodelagemdeprodutoseasua origemnaindstriadamanufatura; Captulo3:apresentaascaractersticasdaaplicaodamodelagemdeproduto naindstriadaconstruo;

Captulo4:descreveosexperimentosrealizadosparademonstraraviabilidade doacessoaosmodelosdeedifciosegeraodeinformaesapartirdeles; Captulo 5: apresenta as consideraes finais sobre os resultados dos experimentos, e sugestes para o desenvolvimento de trabalhos complementaresaeste; Referncias; Apndices:soapresentadososartigospublicadosduranteodesenvolvimento dadissertao,osalgoritmoseosdadosproduzidosduranteosexperimentos.

2
ModelagemdeProduto
Itisonlyworthwhiletomakedrawingsonthecomputerifyougetsomethingmoreoutofthe drawingthanjustadrawing.IvanSutherland,1963.

odelagemacriaoderepresentaeschamadasmodelosdefenmenos

ousistemas,comointuitodemelhorcompreenderasuanaturezaeprevero

seucomportamento.Modelostraduzemparaumaformasimplificadaumconjuntode entidadescomplexodemaisparaserapreendidoemsuatotalidade(MAHDAVI,2003). Essa abstrao permite transmitir apenas as caractersticas essenciais do sistema representado,protegendoosreceptoresdainformaodedetalhesqueprejudicariam a sua compreenso (TURK, 2001). Na indstria da construo so utilizadas modelagens em vrias etapas do projeto de edifcios, da elaborao de esquemas explicando conceitos e equaes prevendo comportamentos fsicos criao de prottipos para demonstrar a factibilidade das idias. O prprio processo de projeto comoumtodopodeserconsideradoumamodelagem:umrefinamentosucessivode ummodeloconceitual,queoedifcioproposto(TAKEDAetal.,1990). Algunstiposdemodelagemutilizamrepresentaestridimensionaisdigitaisde um sistema, para fornecer uma visualizao realista dos seus elementos e dos seus comportamentos (BEUCKE et al., 2005). Por exemplo, na indstria da construo brasileiranotadamentenafasedeprojetosotermomodelagemestfortemente associadocriaoderepresentaescomputacionaistridimensionaisdasedificaes, tambmchamadasmaqueteseletrnicas(SPERLING,2002).Considerandoadefinio etimolgica,qualquerrepresentaodeumedifcio,independentedocontedoeda ferramentautilizada,podeserchamadaummodelo:esboos,estudosdevolumetria, desenhos tcnicos em papel ou digitais, maquetes fsicas ou eletrnicas, detalhamentos, etc. Neste trabalho, o termo modelo referese ao resultado de uma abordagem de desenvolvimento de produtos industriais, chamada modelagem de produto. Um modelo de produto pode fornecer vrios tipos de representao, entre

elasascitadasanteriormente,comavantagemdeintegrlasemumnicorepositrio, garantindoaconsistnciadosdados. O desenvolvimento de produtos industriais composto por uma srie de operaes complexas que podem ser organizadas em dois grandes grupos: o processamento de informaes e o processamento de materiais. Dos primeiros esboosatoprodutoconcludo,informaodevriostiposgerada,transformadae transmitida entre as diversas fases do desenvolvimento, ao mesmo tempo em que ocorrem vrias transformaes nos materiais. Estes dois grupos de operaes so fortemente relacionados e idealmente devem ser sincronizados. A principal maneira de se obter essa sincronizao representar toda a informao sobre o produto digitalmente,apartirdasprimeirasfasesdodesenvolvimento,naformadeummodelo do produto, que ento utilizado para coordenar as atividades da produo. Essa abordagem denominada modelagem de produto (HOSAKA e KIMURA, 1990). Um modelodeumproduto,portanto,umrepositrionicodedadossobreesteproduto, queorientaasatividadesdesenvolvidasdurantetodooseuciclodevida(KRAUSEet al.,1993).

2.1Ainformticaeodesenvolvimentodeprodutos
A maneira como os produtos eram fabricados sofreu poucas alteraes at o finaldosculoXIX,quandoosavanostecnolgicosaumentaramosrequisitosaserem atendidospelafasedeconcepo,easeparaodotrabalhoporfunesfezsurgira necessidade da padronizao da comunicao entre as etapas do seu projeto. A formalizaodessetipodecomunicaosedeuatravsdousodedesenhostcnicos,e foiconcludanadcadade1930(KRAUSEetal.,1993). Logo aps o fim da Segunda Grande Guerra, o computador foi introduzido comoferramentadeapoiono desenvolvimentodeprodutosindustriais.Desdeasua primeira aplicao, a inteno era integrar os diversos processos envolvidos na fabricao da concepo ao produto acabado transmitindo informaes entre as etapas do desenvolvimento. No comeo da dcada de 1950, o Servomechanisms Laboratory, do Massachusetts Institute of Technology (MIT), desenvolveu a primeira fresadora de trs eixos controlada automaticamente. A informao que controlava a
7

mquina era introduzida na forma de fitas de papel perfuradas, preparadas manualmente por um operador que traduzia o desenho tcnico detalhado para a formanumrica,eentoparaospadresapropriadosdefurosnasfitas.Nodemorou at que o computador fosse envolvido nesse tedioso processo, e no final da mesma dcada foi desenvolvido um sistema para preparar automaticamente essas fitas de controle,apartirdosdesenhostcnicos,aindafeitosempapel(GALLAGEReMITTER, 1990). 2.1.1OprincpiodoCAD Em 1959 foi realizada uma reunio entre membros do Computer Applications Group e do Departamento de Engenharia Mecnica, ambos do MIT, na qual foi discutido o uso do computador de um modo mais direto no desenvolvimento de produtos (COONS, 1963). O sistema esboado nessa reunio seria desenvolvido posteriormente no projeto de pesquisa chamado ComputerAided Design (ROSS, 1961), que acabou emprestando o nome tanto para o novo ramo da tecnologia de desenvolvimento de produtos como para as aplicaes computacionais criadas para ele. Algumas das funcionalidades definidas para este sistema eram a descrio de abstraes (esquemas conceituais e idias), anlises fsicas e matemticas, conexo comcatlogos(normastcnicas,peasemateriais),interconexodevriosprojetistas trabalhando simultaneamente (com atualizaes e propagaes automticas da informao),reutilizaodainformaododesenho,simulaesdofuncionamentodo dispositivo projetado, e at a considerao de diferentes vises sobre a informao, com a organizao da representao dos dados em funo das muitas disciplinas envolvidasnoprojeto. Um dos resultados mais notrios deste projeto de pesquisa foi o sistema Sketchpad, criado por Ivan Sutherland em sua tese de doutoramento no MIT (SUTHERLAND, 1963). At ento, linguagens textuais eram utilizadas para criar representaes grficas no computador, o que Sutherlandconsiderava inadequado e confuso. No sistema Sketchpad, a entrada de dados era realizada por uma interface grfica, auxiliada por um dispositivo de interface humana chamado lightpen. Posteriormente,foiprevistaumaversoqueincluiriaarepresentaotridimensional,

consideradaessencialparaoprojetodepesquisaCAD(JOHNSON,1963).Coonsrelata umarpidaexperinciacomoSketchpad,naqualosistemaoauxiliaaresolvercinco problemas de engenharia no decurso de poucas horas (COONS, 1963). Na sua descrio das funcionalidades que o permitiram resolver os problemas rpida e intuitivamente, perceptvel o delineamento de caractersticas que ainda so vitais para a modelagem no desenvolvimento de produtos industriais. Sutherland, complementarmente,afirmaqueacriaodeprojetosnoSketchpadumasequncia deetapasorientadaspelafuncionalidadedoselementosrepresentados(SUTHERLAND, 1963):
ConstructionofadrawingwithSketchpadisitselfamodelofthedesignprocess.The locationsofthepointsandlinesofthedrawingmodelthevariablesofadesign,and the geometric constraints applied to the points and lines of the drawing model the designconstraintswhichlimitthevaluesofdesignvariables.TheabilityofSketchpad to satisfy the geometric constraints applied to the parts of a drawing models the ability of a good designer to satisfy all the design conditions imposed by the limitationsofhismaterials,cost,etc.Infact,sincedesignersinmanyfieldsproduce nothingthemselvesbutadrawingofapart,designconditionsmaywellbethoughtof asapplyingtothedrawingofapartratherthantothepartitself.Whensuchdesign conditionsareaddedtoSketchpad'svocabularyofconstraints,thecomputerwillbe able to assist a user not only in arriving at a nice looking drawing, but also in arrivingatasounddesign.

Ou seja, em princpio pensavase em CAD como uma ferramenta de desenvolvimento de produtos com rotinas capazes de auxiliar a concepo, produzir representaes, executar anlises, prever comportamentos e gerar instrues para a fasedeproduo,emumambienteintegradodeprojeto.Todasessasfuncionalidades exigiam um modo de entrada de dados gil e intuitivo, e a linguagem dos desenhos tcnicos, j bastante desenvolvida e codificada, foi adotada para essa finalidade. A mudanadosuporteoumdiadosdesenhostcnicosdopapelparaocomputador noeraumobjetivoemsi,eraapenasumaconsequnciadousodaferramentaCAD. Emboracoerente,essaabordagemintegradadedesenvolvimentodeprodutos teve pouca influncia sobre os mtodos de fabricao por vrios anos. A academia continuou a aperfeioar definies e prottipos para sistemas integrados de desenvolvimento de produtos, mas a nascente indstria de softwares passou a se concentrarnoaspectoquepodiasermaisfacilmenteresolvidoacriaodedesenhos

no computador, por meio de primitivos geomtricos (pontos, linhas, arcos). As aplicaes comercialmente disponveis que ofereciam esta funcionalidade logo passaram a ser conhecidas por CAD, mas em relao aos princpios definidos pelo projetodepesquisadeRoss,oseunomepoderiasermelhortraduzidoporComputer AidedDraftingdoqueporDesign,jqueasuainflunciasobreodesenvolvimentode produtoserabasicamenteamesmadaspranchetasdedesenhoqueseesperavaque elesubstitusse. Parte do que conduziu a indstria de softwares para esta direo foi consequncia do baixo poder de processamento dos primeiros computadores. Outro motivofoiaenormecomplexidadedasatividadesenvolvidasnoprojetodeprodutos, entreelasaaltamentecognitivaesubjetivafasedeconcepo.DouglasRoss,lderdo grupo de pesquisa CAD, e Jorge Rodriguez afirmaram que um sistema CAD para uso geral deveria possuir uma poderosa organizao, pois mesmo os mais simples problemas de projeto envolvem o exerccio de muitas disciplinas diferentes e a considerao de muitas atividades relacionadas. Tambm deveria ser um sistema abertoexpansesemodificaes,poisnoseriapossvelprevereprogramartodas as abordagens imaginveis para solucionar um determinado problema de projeto, e ter a capacidade de manipular e armazenar informaes oriundas das mais diversas fontes e em diferentes formatos. Mesmo atualmente no h uma teoria universalmente aceita para a compreenso dos processos de concepo durante o projeto(KOWALTOWSKIetal.,2006). Alm de aplicar complexos processamentos de dados para resolver esses problemas, o sistema CAD ideal deveria disponibilizar ao operador a capacidade de desenvolver as suas habilidades de projeto de modo que lhe fosse completamente natural,semqueelefosseconscientequeassuasaesdeprojetodesencadeiamum grande nmero de operaes computacionais altamente complexas (ROSS e RODRIGUEZ,1963). Anderl e Grabowski, duas dcadas depois dos primeiros trabalhos cientficos sobre o CAD, afirmaram que a utilizao de computadores na produo industrial deveria ser precedida por uma criteriosa anlise de todas as atividades envolvidas,

10

para que fossem definidas as trocas de informaes entre elas. Porm, observaram queamaioriadossistemasCADofereciamapenasapossibilidadededescreverpeas individualmente,domesmomodoqueerafeitocomdesenhostcnicosempapel.Os dados sobre a tecnologia aplicada, como acabamento de superfcies e tolerncias dimensionais, necessrios para o planejamento da produo, eram introduzidos posteriormente,comoauxliodedilogosdeentradaoulinguagensdeprogramao (GRABOWSKIeANDERL,1983). J na dcada de 1990, Hank Pels afirmou que mesmo nas situaes em que representaes mais ricas do que os desenhos feitos em computador eram empregadas, havia o problema da transferncia da informao. Desde a introduo dosprimeirossistemasCAD,modelosdeprodutosvinhamsendodigitalizados,porm com pouco compartilhamento de dados entre diferentes disciplinas e atividades envolvidas no processo de fabricao. Os modelos, segundo ele, no eram transmitidos entre computadores, e sim manuseados por operadores, traduzidos e transformados em outros modelos, da mesma maneira que era praticada com os desenhos tcnicos em papel, mas com a desvantagem doaumento da complexidade da mdia. Uma das possveis causas para isso era o fato de se considerar os dados necessrios para o projeto do produto razoavelmente estveis ou at mesmo estticos,emcomparaocomosdadosfinanceiroselogsticos,porexemplo.Porisso, aindafaziasentidodistribulosempapel,naformadetabelasemanuaistcnicos,e um modelo de produto que integrasse essa informao no era considerado necessrio(PELS,1996). 2.1.2Oprincpiodamodelagemdeproduto Apesar da idia de integrao do processo de produo ter sido a motivao dosprimeirossistemasCAD,foramasmudanaseconmicasocorridasapartirdofinal dadcadade1970quederamnovoimpulsoaotemaeinfluenciaramostrabalhosque propuseram as atuais definies de modelagem de produto. A globalizao dos mercadoseanecessidadedefabricarprodutoscommaiorqualidade,menorcustode produoeemmenostempo,deramorigemanovasestratgiasdedesenvolvimento de produtos. Entre elas, a interconexo dos vrios aspectos tcnicos e gerenciais

11

envolvidosnaproduo,aproduoenxuta,aengenhariasimultneaeoconceitode ciclodevidadoproduto,queestendeuaresponsabilidadedoprojetistaparaocampo dosimpactosambientaiseasadedosusurios. Estas novas estratgias de desenvolvimento tinham focos e abordagens distintos, porm compartilhavam uma necessidade fundamental por tecnologias de informao avanadas, que permitissem integrar e coordenar as diferentes vises sobre o produto durante o projeto, a fabricao e a operao (KRAUSE et al., 1993). Sistemascomputacionaisjhaviamdemonstradooseupotencialnaracionalizaode vrias etapas isoladas do desenvolvimento de produtos, e surgiu a tendncia para a integrao dos diferentes sistemas atravs do fluxo digital de informaes, em substituio manipulao de diferentes modelos. Este fluxo teria o potencial para reduzir os custos de produo atravs da eliminao de atividades de reentrada de dados, da reduo de erros, atividades de controle e procedimentos de teste, e da disponibilizaorpidaecompletadeinformaessobreoprodutoeasuaproduo, o que aumentaria a velocidade do processamento de pedidos e a qualidade do produto(GRABOWSKIeANDERL,1983). AferramentaprincipalnessefluxodeinformaesmencionadoporGrabowski eAnderleraamodelagemdoproduto.EmumretornoaosprincpiosoriginaisdoCAD, eles observaram que a adoo da modelagem permitiria que os projetistas concebessem e validassem os novos constructos, e posteriormente comunicassem corretamenteosdetalhesdeconstruosfasesdeproduo.Duranteaconcepo,o modelo do produto auxilia os usurios a explorar, documentar, compreender e predizer certas propriedades e comportamentos dos elementos representados. A validaoaverificaodaconformidadedoconstructopropostocontraosdiversos requisitosestabelecidosparaasuafabricaoeoperao,easuaimportnciacresce conformeaumentaacomplexidadedosprodutos.Omodelodoprodutopermiteque sejam utilizadas listas de verificao e simulaes computacionais para auxiliar o projetistanestafase.Eletambmproporcionaumacomunicaomaiseficienteentre asfasesdodesenvolvimentodoproduto,umacaractersticanecessriaparaprocessos industriaisquetornamsecadavezmaiscomplexoseenvolvemumnmerocrescente de pessoas e organizaes, muitas vezes distantes geograficamente (PELS, 1996;
12

MAHDAVI, 2003). Por proporcionar a integrao dos diversos sistemas utilizados nos processos de desenvolvimento, a modelagem de produto foi considerada uma tecnologiachavenoaumentodaprodutividadeeparaasobrevivnciacompetitivadas companhias(KIMURAetal.,1984).

2.2Evoluodosmodelosdeproduto
Afuncionalidadeoferecidapelosmodelosdeprodutoevoluiuemconjuntocom aspossibilidadestcnicasdoscomputadores,asnovasconcepesdeestruturaoda informaotrazidaspeloestudodosmodelosdedados,eascrescentesdemandaspor integrao dos sistemas de produo. Essas demandas, porm, no foram homogneas,sejaconsiderandoosprocessosprodutivos ouosdiferentessegmentos daindstria.Aclassificaodostiposdemodelosporidadecoincidecomoaumento dasuacomplexidadeetilparailustraraorigemdasfuncionalidadesdosmodelos maisrecentes,masdizrespeitoapenasaoaspectotcnico,enoadooefetivapela indstria. Mesmo hoje, os primeiros e mais simples tipos de modelos ainda so utilizados como principal meio de transmisso de informaes entre processos produtivosemdeterminadossetores,comonaconstruocivilporexemplo. 2.2.1Modelogeomtrico Osprimeirosmodelostinhamporobjetivoprincipalrepresentargeometriados elementosquecompunhamosprodutos.Emboraaidiaderepresentarinformaes complementares geometria j estivesse presente desde o incio do CAD, a grande dificuldade para equacionar processos complexos utilizando computadores ainda muito simples dirigiu grande parte das pesquisas para a definio de teorias matemticas que permitissem representar a geometria digitalmente. Eastman e Henrionclassificamasprimeirasexperinciascommodelagemnocomputadoremtrs estgios: a abordagem inicial, denominada image modeling, enfocava a produo de desenhos, e sua preocupao maior era representar corretamente objetos tridimensionais em um plano (a tela do monitor) utilizando apenas linhas. O modelo resultanteforneciaainformaonecessriaapenasparaavisualizao,possivelmente incluindo diferentes perspectivas e eliminao de linhas escondidas (hidden line). A segundaabordagem,chamadageometricmodeling,tinhaporobjetivoarepresentao
13

das superfcies dos slidos (ou poliedros), para que fosse possvel discretizar o seu volume interno e identificar conflitos espaciais. A terceira abordagem seria uma evoluo do modelo geomtrico, passando a incluir atributos adicionais ao formato, como material, densidade, funo, cor ou quaisquer outras informaes que fossem relevantesparaaproduoindustrial(EASTMANeHENRION,1979). AsbasesdamodelagemgeomtricaforamlanadaspelotrabalhodeRequicha e Voelcker sobre a geometria construtiva de slidos (constructive solid geometry CSG), que propunha modelos constitudos por estruturas topolgicas e estruturas geomtricas(HOFFMANNeJOANARINYO,2002).Kalaypropsautilizaodebancos de dados relacionais para a representao do modelo CSG como um conjunto de dadosrelacionadosemtrsnveishierrquicos:topologia,geometriaetransformaes espaciais. A topologia um ndice que organiza as relaes entre os elementos (primitivosgeomtricos)queconstituemumslido.Ageometriaonvelresponsvel pela descrio dos primitivos geomtricos atravs de equaes matemticas que possam ser armazenadas digitalmente. O nvel das transformaes espaciais representaas instncias dos objetos, criadasa partir dematrizes de transformaes, comoarotaoouoredimensionamentodoslido(KALAY,1985a).HosakaeKimura fazemcategorizaosemelhantealgunsanosdepois(HOSAKAeKIMURA,1990). 2.2.2Modelovariacional OmodelovariacionalfoiintroduzidoporVoelckeretal.,nofinaldadcadade 1970,eestendeuomodelogeomtricoadicionandoapossibilidadededefiniodos slidos atravs da associao de formas bsicas definidas por uma linguagem procedimental chamada PADL Part and Assembly Description Language (VOELCKER et al., 1978). A PADL era baseada em funes para as quais eram passados os parmetros desejados para os elementos geomtricos, que ento eram construdos duranteaexecuodoprograma.Estesparmetrospodiamsermodificadosdurantea execuo,aocontrriodamaioriadaslinguagensdedefiniodegrficosproduzidas atento,quepermitiamdefinirosvaloresapenasduranteaprogramaodocdigo ou seja, atravs de comandos e no de funes. Vrias linguagens de definio de slidos desenvolvidas durante os anos seguintes seguiam o paradigma estabelecido

14

porVoelckereseuscolegas,comoaGlide,porexemplo(EASTMANeHENRION,1977). Outro exemplo a GDL, (Geometrical Description Language), que ainda um dos mtodosparadefiniodeslidosnosoftwareArchiCAD(GRAPHISOFT,2008b). Uma desvantagem do modelo variacional a dependncia em relao aos scriptsosarquivosdetextocontendoasfunesquegeravamarepresentaodos slidosduranteaexecuodoprograma.Emborapudessemserbastantecomplexose flexveis, projetar por programao sempre menos desejvel do que fornecer ao projetista ferramentas visuais e um ambiente intuitivo para a construo dos elementosdoprojeto(HOFFMANNeJOANARINYO,2002). 2.2.3Modelobaseadoemrestries Omodelobaseadoemrestriesoutravariaodomodelogeomtrico,com a introduo da possibilidade de gerao de instncias de slidos a partir de um conjunto de relaes entre as entidades, que precisavam ser mantidas. Quando as entidades so relacionadas, o programa utilizado na modelagem impede operaes cujo resultado no atenda as condies de restrio. Os tipos de restries foram classificados em grupos: geomtricas ou dimensionais, equacionais, semnticas e topolgicas(HOFFMANNeJOANARINYO,2002). Restries geomtricas ou dimensionais mantm entidades relacionadas por uma condio de concentricidade, perpendicularidade, ngulo, distncia, etc. As restries equacionais mantm entidades relacionadas atravs da avaliao de um atributocalculadoapartirdasuageometriaoudevariveistecnolgicascomotorque, densidade ou resistncia. Restries semnticas mantm o relacionamento entre as entidades apenas se uma determinada condio for atendida. Restries topolgicas avaliamcondiesdeincidncia,conectividadeentreelementos,conjuntosoupartes. 2.2.4Modeloparamtrico O modelo paramtrico estende o modelo geomtrico para alm da soma das representaes topolgicas e geomtricas. Eles contem tambm a metaestrutura a partirdaqualnovasinstnciasdosslidospodemserderivadas.Destemodo,mais apropriado pensar em modelos paramtricos como um conjunto de slidos

15

paramtricos, que so classes de slidos especficos. Uma classe prisma, por exemplo, contm a informao necessria (a metaestrutura) para criar prismas de qualquer dimenso. A gerao de uma instncia de objeto realizada por um algoritmo determinstico, que considera diferentes restries e avalia parmetros definidos na estrutura de informao que compe o slido paramtrico. Antes do desenvolvimento dos slidos paramtricos, a modelagem gerava apenas slidos especficos que, uma vez criados, no podiam ser modificados facilmente. A modelagem paramtrica, ao contrrio, no enfoca a representao final do slido, e simasetapasenvolvidasnasuaconstruo,parametrizandoasepossibilitandoqueo usuriodeterminevriosresultadosparaomesmoobjetoapartirdacombinaodos seusatributos.Aflexibilidaderesultantepodeserexploradademuitasmaneiras,ese constitui em importante avano para a aplicao no desenvolvimento de produtos (HOFFMANN e JOANARINYO, 2002). Os slidos paramtricos so intimamente relacionados tecnologia de orientao a objetos, de onde surge a denominao objetoparamtrico.Umobjetoparamtricopodeserentendidocomoumaunidadede informao (ou classe) que encapsula os dados (os parmetros) e mtodos para processlos(osscripts),resultandoemumainstnciadoobjeto.Outraanalogiaparao modelo paramtrico considerlo uma associao das qualidades do modelo geomtricocomasdomodelovariacional. 2.2.5Modelobaseadoemcaractersticas(features) O modelo baseado em caractersticas uma especializao do modelo paramtrico.Aestruturadeclassesproporcionadapelaorientaoaobjetospermite explorar novas classificaes hierrquicas alm da geometria. Hvam defende que a modelagem de produto diretamente relacionada a dois conceitos: a engenharia simultnea e a modelagem de caractersticas. A engenharia simultnea integra as atividadesapartirdoplanejamentodasfasesdociclodevidadoproduto,reduzindoo tempodeentregaeoscustosdeproduo.Amodelagemdecaractersticasummeio de representar as diferentes vises que as vrias disciplinas envolvidas no desenvolvimentodeumprodutotmsobreeleduranteoseuciclodevida:concepo, topologia, desempenho, tolerncias, produo, montagem, logstica, etc. O modelo baseado em caractersticas armazena o conhecimento tcnico que adicionado ao
16

modelodoprodutoemcadafasedociclodevidapelasvriasdisciplinasenvolvidas,na forma de descries gerais e de instrues especficas para gerao de instncias do modelo (desenhos tcnicos, relatrios quantitativos, sequncias de operaes). Enquanto a descrio geral comum para todas as etapas do desenvolvimento do produto, as instncias dependem de condies especficas de cada fase do ciclo de vida(HVAM,2001). HoffmaneJoanArinyoacrescentamqueousodecaractersticaspassouaser componente padro da modelagem paramtrica, de onde pode se concluir a atual preferncia por denominar de paramtricos modelos que possuem estruturas para descrever tambm as caractersticas do produto. Para os autores, as caractersticas proporcionamumvocabulriodealtonvelparaespecificaodeoperaesdecriao de formas atravs da geometria parametrizada, atributos e restries geomtricas. Durante o projeto, as caractersticas capturam atributos tcnicos explcitos e relacionamentos que auxiliam na definio de produtos, provendo informaes essenciais para vrias atividades e anlises de desempenho. Na fabricao, as caractersticaspodemsercombinadasparafacilitaroplanejamento.Paraseremteis, as caractersticas devem incorporar trs diferentes conceitos: o aspecto geral, o comportamentoeosignificadotcnico.Oaspectogeralarepresentaogeomtrica doobjeto,definidaporfronteiras,rvoresdeoperaesbooleanas(CSGtree)oupor procedimentoscriadoscomlinguagensdedefiniogeomtrica.Ocomportamentoeo significado tcnico so definidos atravs de atributos e regras, que condicionam o objeto em relao a um contexto especfico. Grandes quantidades de especificaes poderiam interferir em processos mais geis, como a concepo de novos produtos. Por isso proposto pelos autores que se desenvolvam ferramentas para o reconhecimentoautomticodecaractersticas.Nesseprocessoummodelogeomtrico previamente construdo seria analisado por algoritmos que identificassem caractersticas automaticamente, a partir de um conjunto de regras ou padres semnticos. Esta abordagem tem recebido crescente ateno por parte da comunidade cientfica, mas vrios desafios ainda precisam ser endereados e resolvidosparaqueseobtenhamalgoritmosconfiveis.Umdosprincipaisdesafioso reconhecimentodecaractersticassobrepostas:quandoasvisesdevriasdisciplinas

17

diferentes so combinadas, a topologia resultante pode mudar consideravelmente, e osalgoritmospodemterdificuldadeparalocalizarascaractersticasadequadas.Outro desafio registrar o conhecimento tcnico adicionado durante as fases do desenvolvimento do produto: armazenar as diferentes vises sobre os dados do produtoquecadadisciplinautilizatoimportantequandoarmazenarosdadosemsi. Aindamais,todasasmodificaesrealizadassobreumadeterminadavisodosdados devem ser propagadas para as outras vises, atualizando todos os profissionais envolvidos(HOFFMANNeJOANARINYO,2002).

2.3Modelosdedadosdeprodutos
Modelos de produtos so gerados a partir de arcabouos formados por constructos lgicos que definem a forma e o significado para os dados que representaro o ciclo de vida de um produto (LACROIX e PIROTTE, 1981). Esses arcabouossocriadosemumprocessodemetamodelagemchamadomodelagemde dadosdoproduto.Yangeoutrosautoressituamamodelagemdedadosdoprodutona faseimediatamenteposterioranlisedaestruturadoprodutoaserfabricadoedo contexto onde ser realizada a produo. Depois de criado, o modelo de dados do produto implementado por vrios programas de computador, dando origem ao modelodoproduto,quepodeserarmazenadoembancosdedadosouemarquivosde formato neutro (YANG et al., 2008). Modelos de produtos so, portanto, sempre instnciasdealgummodelodedadoscriadopreviamente. Antes do advento da modelagem de dados, cada programa definia a sua prpriaformadearmazenarerecuperardados,oqueenvolviaumenormetrabalhode programao e dificultava a adaptao e a evoluo dos sistemas, como pode ser vislumbrado no prottipo de sistema CAD integrado criado por Charles Robinson (ROBINSON, 1966). Haynie (HAYNIE, 1983) relata que nos primeiros sistemas de desenvolvimento de projetos era comum que os dados do produto em desenvolvimento fossem indissociveis dos procedimentos da aplicao CAD. Uma soluomelhor,segundooautor,seriatornarainformaoindependentedaaplicao computacional,oquepermitiriaadefiniodevriasvisualizaessobreummesmo

18

dado, por aplicaes diferentes. Para isso, uma nova ferramenta seria adotada para armazenarosdadosdoprojetoobancodedados. 2.3.1Bancosdedados Bancos de dados no s proporcionaram uma forma muito mais eficiente de armazenarerecuperardados,comotambmforamaprimeiratecnologiaquepermitiu amodelagemdedadosindependentedoprogramaqueiriaprocesslos.Em1975,o American National Standards Institute (ANSI) definiu a abordagem bsica para a construodebancosdedadoschamadaANSISPARC,queficoumaisconhecidacomo arquitetura de trs esquemas (three schema architecture). Os trs esquemas do ANSISPARCeramoconceitualqueespecificaaestruturaeosignificadodosdadose segue as determinaes dos processos do negcio; o esquema externo que especifica a forma de apresentao dos dados e utilizado pelas aplicaes e pelos usurios da informao; e o esquema interno que especifica a estrutura fsica do banco de dados, e segue determinaes impostas pelo hardware e sistemas operacionais utilizados (PELS, 1996). Eastman observa que no incio do uso da tecnologia,aindahaviacertodesentendimentoemrelaoaoconceitodebancosde dados,eodefinecomoumaestruturadeinformao(1980a):
Computers today can easily store large amounts of information. It has become a euphemism that any program incorporating more than a hundred or so words of datacanbeconsideredtohaveadatabase.Whilethisistrueinthecolloquialsense, theterm'database'hasatechnicalmeaningthatisrelatedtoasetofmethodsused for managing large amounts of information. Thus a large amount of data, but not usingthesetechniques,isnotproperlyadatabase,whileasmallamountofdatathat does use them legitimately can be still called a database. Thus the term database appliesmoretothestructureofinformationratherthanitssize.

Aps a introduo dos bancos de dados, grande parte das instrues para a interpretao da informao passou a residir no modelo de dados (o esquema de organizaodobancodedados)enomaisnosprogramasqueiriamacessla.Essa liberdade era essencial para o desenvolvimento de estruturas genricas capazes de armazenar vrios tipos de produtos, ou vrias instncias de um tipo de produto, mantendoosignificadodainformaoepermitindooacessopordiferentesaplicaes duranteasfasesdedesenvolvimentodoproduto.Opotencialdaaplicaodebancos

19

de dados na atividade de projeto de produtos, cuja natureza implica justamente na transmisso de informaes entre aplicaes e disciplinas diferentes, foi extensivamente estudado a partir da dcada de 1980 (EASTMAN, 1980a; KALAY, 1985a;EASTMANeKUTAY,1989). Os primeiros sistemas de gerenciamento de bancos de dados, entretanto, destinavamse a ambientes de negcios, e no contemplavam a complexidade das atividadesdeprojeto,tornandooacessoinformaomuitocomplicado.Bandurskie Jeffersonafirmamqueafiguradoadministradordebancosdedadosseriaessencial tecnologia CAD: ele seria um profissional familiarizado com todos os processos do desenvolvimentodoprodutoecomasestruturasdedadosnecessriasparacadaum, capazdefornecerinterfacesquepermitissemqueousuriovisualizasseosdadosdo modo mais natural possvel, protegido de detalhes desnecessrios das estruturas empregadas no banco de dados (BANDURSKI e JEFFERSON, 1975). Para Lacroix e Pirotte,poroutrolado,astecnologiasutilizadaspelosprimeirosbancosdedadosno teriamcapacidadesuficientepararepresentaradequadamenteacomplexainformao de projetos de desenvolvimento de produtos. Tampouco a integrao de processos produtivos poderia ser alcanada enquanto a interpretao das estruturas de dados fosseexclusividadedeumgruposeletodeespecialistas,comoosadministradoresde bancos de dados. Eles observaram que a prtica da descrio de modelos de dados atravs de convenes mal formuladas, que no eram suficientes para esclarecer a natureza da informao a ser armazenada e distribuda, dificultava o compartilhamentodomodeloentreespecialistasdediferentesdisciplinas:
[...] to avoid the a little information in data structure diagrams and a lot in accompanying unstructured explanations syndrome which in practice is typical of manyapplicationsexpressedinthehierarchicandnetworkdatamodels

Para as aplicaes CAD, os autores propem a utilizao de um modelo semntico de dados, que introduz a distino entre os constructos que compem as estruturasdedadoseovalorqueelespodemvirareceber(LACROIXePIROTTE,1981).

20

2.3.2Semntica Osconstructosdeummodelosemnticodedadossoasentidades,descritas atravs de elementos atmicos (como classes e propriedades) e os relacionamentos entre estas entidades. Para definir as entidades e os seus relacionamentos, foi necessriocriarumnovosistemaparanotaodomodelodedadosalinguagemde definio de dados. As principais caractersticas dessa linguagem so fornecer diferentesabordagensparaadescriodosconstructos(relacionamentos,hierarquias, associaes), permitir que sejam modelados constructos com riqueza e preciso, e finalmente ajustarse s vrias situaes e tipos de objetos que possam demandar modelagem,permitindoqueosespecialistaspossamrealizaressasatividadedemodo quelhespareanatural.LacroixePirottedesenvolveramumalinguagemdedefinio dedadosparaacriaodemodelossemnticosdeplacasdecircuitoeltrico,chamada ADDL (A Data Definition Language). Os modelos semnticos gerados pela ADDL no apenas eram mais facilmente interpretados pelos usurios como garantiam a coernciapelousoderestriesaplicadassentidades(LACROIXePIROTTE,1981).A ADDL adiantou alguns conceitos que seriam aplicados posteriormente na criao de outraslinguagensdedefiniodedados,comoasregrasdeestruturaodedomnio que definiam os valores possveis para os tipos complexos de dados (formados por conjuntos de tipos simples), as regras de restrio de domnio, que atuavam em conjunto com as primeiras para determinar qual combinao de domnios poderia constituir um tipo complexo vlido, e finalmente a denotao de objeto aos tipos complexosquerepresentavamunidadesdeinformaorazoavelmenteautnomasno processodeprojeto. Mark Haynie relacionou algumas das especificidades s quais os bancos de dadosdeveriamadequarseparaseremteisnasaplicaesdeengenharia:mesmoas unidades de informao mais simples utilizadas na engenharia costumam ser representadas por tipos complexos (um ponto no espao, por exemplo, composto por no mnimo trs nmeros reais), o acesso em baixo nvel precisa ser flexvel e a estrutura deve permitir modificaes dinmicas (pois a atividade de projeto mutvel), as operaes de acesso de dados so longas, e o carter iterativo e incremental do projeto exige que seja armazenado o histrico de modificaes nos
21

dados.Umasoluo,segundooautor,eraaadoodobancodedadosrelacional,no qual eram descritos alm dos elementos, os relacionamentos entre eles. Haynie tambmafirmouqueosmodelossemnticosdedadosnoeramumanovatipologia,e sim uma especializao do modelo relacional de dados. Nos bancos de dados relacionais,umrelacionamentodefinidoporumatabelacontendoumnmerofixo de atributos (colunas) e um nmero varivel de matrizes unidimensionais. As vrias matrizes unidimensionais so relacionadas entre si atravs de ponteiros chamados chaves primrias, compostas por uma ou mais das colunas de cada tabela (HAYNIE, 1983). Para Eastman e Kutay, a abstrao de dados proporcionada pelo modelo relacional foi um importante avano, mas ainda era insuficiente para representar inequivocamenteasinformaesdeprojetosdeprodutos.Bancosdedadosdedicados arepresentarprojetos(oubancosdedadosdeprojetos),comoquaisqueroutros,so implementados com o propsito de integrar mltiplas aplicaes em um ambiente comum, garantindo a consistncia e a integridade dos dados durante as operaes. Portanto,acessosconcorrentes(quandovriosusuriosrequisitamosmesmosdados) soocorrnciasnaturais,edevemsercontroladospelosistemacomnaturalidade.Para isso, alm da abstrao de dados, outro tipo de abstrao deveria ser includa no modelo de dados a abstrao de operaes sobre os dados (EASTMAN e KUTAY, 1989). Oconceitodetransaodedadosintimamenterelacionadoaodeabstrao deoperaes:emvezdepermitiroperaesarbitrriassobreobancodedados,so definidascoleesdeoperaesoutransaesquequandoexecutadasmantma integridade do banco de dados. A definio de integridade utilizada nos bancos de dados de aplicaes de negcios tambm no era adequada ao ambiente de desenvolvimentodeprodutos.Seelafosseaplicada,umaestruturargidadedadose atividades teria que ser imposta e, mesmo assim, um banco de dados de projeto passariagrandepartedasuavidaemcondiodeinconsistncia,jqueainformao de um projeto s pode ser considerada completa quando ele est perto da sua concluso. A natureza iterativa do projeto faz com que no apenas os dados, mas tambm a sua estrutura de armazenamento seja modificada durante as fases do
22

desenvolvimentoe,portanto,acondiodeintegridadedeveserrelativaaocontexto. No sistema proposto pelos autores, no haveria uma condio de integridade total, apenasintegridadesrelativas,garantidaspelasprpriastransaesdedados.Durante a execuo das transaes de dados, a integridade poderia ser violada, j que uma transao pode significar a transio entre diferentes fases do projeto. Aps a execuobemsucedidadatransao,umanovacondiodeintegridadedobancode dados emerge e dependendo do resultado, uma srie de outras transaes pode ser requisitadaparapropagaroresultadodaprimeirasobreorestantedobancodedados (EASTMANeKUTAY,1989). 2.3.3Orientaoaobjetos Mais recentemente, uma nova tecnologia foi incorporada na criao de modelosdedadosa orientaoaobjetos.Essatecnologiafoiaplicadainicialmente emlinguagensdeprogramaodecomputadores,comooC++,nofinaldadcadade 1980. O objetivo era auxiliar os programadores a lidarem com a crescente complexidadedosprogramasdecomputadorqueatentoerambaseadosapenasem procedimentos. Como resultado, os programas passaram a ser organizados em conjuntos de objetos e interfaces para acesso aos seus dados. Em linguagens de programao, os objetos so tambm chamados Classes, enquanto as interfaces so chamadas Mtodos. Recentes esforos provaram que a aplicao da orientao a objetosnamodelagemdedadoscapazdedigitalizarainformaosobreoproduto emumaestruturamuitobemdefinida,ondeosdadossomaisfacilmenteacessadose modificados(YANGetal.,2008).Atecnologiadaorientaoaobjetoscompostapor trs princpios: encapsulamento, hereditariedade e polimorfismo (SCHILDT, 2002). O encapsulamento o mecanismo que rene os dados e os procedimentos para manipullos em um mesmo objeto, criando uma unidade de informao razoavelmente autnoma. Em um modelo de dados de produto, o encapsulamento poderia reunir vrios tipos complexos de dados que representam um prisma, por exemplo,juntamentecomasoperaespermitidassobreestesdados(comomodificar umadasdimensesocalcularovolume)emumnicoobjeto.Ahereditariedadea propriedadequepermiteorganizarhierarquicamenteosobjetosereutilizarestruturas dedadospreviamenteconstrudasatravsdasuaespecializao.Nodesenvolvimento
23

deprodutos,essapropriedadepodefacilitaroprocessodederivaodecomponentes especializados a partir de formas bsicas (slidos geomtricos transformados em componentes metlicos, por exemplo). Apesar de terem propriedades extras, os componentes derivados mantm as propriedades herdadas das formas bsicas, para facilitaraediodocomponente.Finalmente,opolimorfismopermitequeumanica interfaceabstrataadapteseadiversassituaes,reduzindoonmerodeobjetosque precisam ser criados. H vrias situaes no desenvolvimento de produto onde essa caractersticatilumsimplesexemplopermitirquemltiplossistemasdemedida (mtrico e imperial, por exemplo) sejam utilizados sem que seja necessrio reprogramar o objeto. O polimorfismo tambm pode ser mais complexo, reconstruindototalmenteaformadeumobjetoquandooseucontextomodificado. 2.3.4STEP Atualmente, uma importante direo para a pesquisa sobre orientao a objetos no desenvolvimento de produtos a apresentao dos dados do produto atravs de um formato padronizado. Um dos maiores avanos nesse sentido a modelagem de dados baseada na norma ISSO 10303, tambm chamada STEP, acrnimo de Standard for the Exchange of Product Model Data (norma para transferncia dos dados do produto). O seu objetivo definir um formato neutro e interpretvel para os dados do produto, durante todo o seu ciclo de vida, independentedesistemasespecficos.ASTEPorganizadaempartes,osApplication Protocols(protocolos deaplicao),ouAPs,quedefinempadresparaestruturasde dados utilizadas por diferentes ramos da indstria. A norma tambm inclui uma linguagem formal para representao precisa e inequvoca dos dados do produto, chamadaEXPRESS(SCRASTEP,2006). As origens da STEP remontam a 1984, quando vrios organismos de normatizaonacionaisreuniramseparadesenvolverumanicanormainternacional derepresentaodemodelosdeprodutos,cujaprimeiraversofoipublicadasomente dezanosdepois.ASTEPfoiumdosavanosmaissignificativosemdireointegrao dos processos produtivos atravs dos modelos de produtos. A sua proposta de padronizar a transferncia de todos os dados relativos ao produto estava muito

24

frente das demais normas de representao de dados, que ainda se concentravam apenas na transmisso da informao geomtrica (KRAUSE et al., 1993). Gielingh observa que a importncia de padronizaes como a STEP, chamadas Product Data Technologies(PDT),residenofatodenoexistiremaplicaesdeprojetoauxiliadopor computador que suportem todo o ciclo de vida de um produto. Ao contrrio, os empreendimentos modernos so consrcios de companhias em colaborao, e o desenvolvimentodeprodutosrealizadoemmuitasaplicaesdiferentes,cadauma atuandoemumescoporeduzido.Dessemodo,apenascomapadronizaodedados possibilitadapelasPDTpodeservivelautilizaodemodelosintegradosdeproduto (GIELINGH,2008). OsmodelosdedadosSTEPsodefinidosutilizandoalinguagemdedescriode metadadoschamadaEXPRESS,apresentadananormaISO1030311:1994.Adefinio dos modelos pode ser realizada textualmente ou graficamente, com a extenso EXPRESSG. A EXPRESS aplica o esquema semntico de representao de dados, baseado em entidades, atributos e relacionamentos, e tambm possibilita criar generalizaeserestriesparaosdados.FowleratentaparaofatodeaExpressser porvezesmalentendida,elembraque(FOWLER,1996): EXPRESS no uma metodologia ela pode ser utilizada em conjunto com vriasmetodologiasdedesenvolvimento; EXPRESS no uma linguagem de modelagem completa tipicamente um modelo de dados consiste na definio em Express complementada por definiesemlinguagemnaturaleemdiagramas; EXPRESS no uma linguagem de programao. No possvel compilar o modelodedadosdescrito,maselepodesermapeadopordiversaslinguagens deprogramao; OsconstructosutilizadosnadefiniodemodelosdedadosemEXPRESSsoo SCHEMA uma subdiviso funcional do modelo que permite a reutilizao de informaes entre modelos diferentes; o TYPE, que descreve tipos primitivos de dados, como inteiro, real, booleano, string, etc.; ENTITY, que representa as unidades bsicas de informao, que compem o schema; SUBTYPE, que estabelece relaes hierrquicas entre entidades diferentes; aggregations (SET, ARRAY, LIST, BAG), que

25

determinam colees de tipos ou entidades; e tambm unidades algortmicas: FUNCTION,PROCEDUREeRULE,quesoutilizadasparaadicionarrestriesadicionais aomodelodedados(FOWLER,1996). ModelosdedadosSTEPsoconsideravelmentemaiseficientesnatransmisso deinformaesdeprojetosdoqueosmodelosdedadosutilizadosnosCADsbaseados em primitivos geomtricos. Bjrk, por exemplo, prope utilizlos para permitir a transferncia de informaes a respeito dos espaos, das fronteiras espaciais e das estruturas de fechamento dos edifcios, que so utilizadas em vrias aplicaes de projeto e simulao (BJRK, 1992). Isso no seria possvelsem um modelo de dados relacional, pois essas informaes se baseiam justamente no relacionamento entre elementos do edifcio. Outro exemplo a proposta de padronizao de Fenves, que utiliza a EXPRESS para definir um ncleo comum de informaes de projeto que viabilizeatrocadedadosentrevriossetoresdaindstria.Asentidadesbsicasdoseu modelo semntico de dados so objetos genricos capazes de descrever a forma e todaainformaocomplementarnecessriaparaconduzirasatividadesdoprojetode produtos(FENVES,2002). Yang e outros autores (2008), por outro lado, afirmam que muitas das pesquisas sobre a aplicao da STEP ainda so limitadas com relao ao principal objetivo da norma o uso do padro em um ambiente integrado. A maioria dos trabalhosapresentaamodelagemdeprodutosapenasemdeterminadosestgiosdo desenvolvimento, enquanto no modo de produo atual, altamente cooperativo, diferentes fbricas necessitam trocar informaes sobre vrios tipos de produtos, descritosemdiferentesmodelosdedados.Emdecorrnciadavariaoexistenteentre os diferentes modelos, trabalho adicional necessrio para a converso de dados, e em muitos casos essa converso no garante a integridade da informao. Dados faltantes ou corrompidos tem grande impacto em empreendimentos de cooperao industrial, motivo pelo qual devem ser adotados modelos genricos, capazes de descrevervriostiposdeprodutos.Osmodelosdeprodutosdesenvolvidosatento dosuporteaalgunsprocessosdafabricao,masnotemhabilidadeparasuportara totalidade do ciclo de vida dos produtos. Por isso, novas pesquisas so necessrias para desenvolver metodologias que permitam integrar efetivamente o
26

desenvolvimento de produtos. A modelagem das caractersticas funcionais dos produtosdeveseintensificar,eissoexigirumaabordagemcadavezmaisabstratae em alto nvel para os modelos de dados. Tambm ser necessrio identificar meios paraqueocontedosemnticodosdadosdoprodutosejaarmazenadoetransmitido corretamente, para dar suporte a sistemas CAD mais inteligentes. Os processos de produo cada vez mais colaborativos e distribudos tambm demandaro pesquisas no campo da utilizao de tecnologias da Web para gerar e distribuir ambientes de desenvolvimento cooperativo de produto, e sobre a implementao da modelagem baseada na STEP para permitir a distribuio dos modelos entre os diferentes envolvidos.

2.4Amodelagemdeprodutoeocontextodasuaimplantao
A implementao da modelagem de produto de maneira efetiva requer o estudodasaplicaescomputacionaisqueseroutilizadasetambmdocontextono qual elas sero introduzidas. Esse contexto formado pela organizao operacional das empresas e pelo fluxo de informaes que ocorre entre as diferentes etapas do desenvolvimento de um produto, e determina os requisitos a serem atendidos pelas ferramentasdeinformaoutilizadas.Aorganizaooperacionaldefineosenvolvidos nasatividadeseassuasresponsabilidadesnageraoenocontroledainformao. essencialqueaferramentadeinformaoempregadaregistreessesdadosparaqueas responsabilidades possam ser constantemente rastreadas. O fluxo de informaes um resultado direto da organizao das operaes de produo: paracada atividade do desenvolvimento de produtos deve ser identificado o conjunto completo de informaes relacionadas semanticamente, que sero necessrias para as atividades subseqentes(GRABOWSKIeANDERL,1983). Krause e outros autores, em uma das mais influentes compilaes sobre a modelagem de produto, definem uma estrutura semelhante, porm com diferentes nomenclaturas: os dois aspectos bsicos a serem considerados pelas ferramentas de informao para a modelagem de produto so o modelo de produto em si, e as cadeiasdeprocessosprodutivosenvolvidasnasuafabricao.Omodelodoproduto um repositrio formado pela acumulao de toda a informao relevante sobre o

27

produto,emumaestruturadedadosqueforneamtodosdeacessoadequados.Para auxiliarefetivamentenosprocessosdeproduo,omodelodoprodutodevesermais do que uma representao esttica do produto acabado. Ele deve conter tanto os resultados ltimos como os intermedirios, para que a seqncia de tomada de decises que produziu a verso final do produto possa ser rastreada e analisada, permitindo que sejam aplicadas melhorias ao processo de produo. A informao armazenada no modelo de produto provm das cadeias de processos produtivos (process chains), que compreendem todas as atividades tcnicas e gerenciais necessriasparatransformarasidiasiniciaisemprodutosfinais,durantetodoociclo devidadoproduto.Umavezquetodaainformaogeradaemdeterminadaetapado ciclo de vida ser utilizada em outra, a sua transmisso eficiente essencial para o gerenciamentodacadeia,equaisquerprocessosdetraduooumudanadeformato deveriam ser evitados, j que eles sempre trazem o risco de perda de parte do significadooumesmoocorrnciadeerros(KRAUSEetal.,1993). Mesmo um gerenciamento adequado de uma cadeia de processos perfeitamente ajustada pode no ser suficiente para garantir a competitividade de algumas empresas. Para as mdias pequenas companhias, por exemplo, empregar recursos externos para alguns dos processos de produo mais econmico e eficientedoquerealizlosinternamente.Odesenvolvimentodistribudodeprodutos cada vez mais empregado nestes casos e, idealmente, a modelagem de produto deveria oferecer no mnimo dois graus de integrao da informao nessa situao: entre as etapas de desenvolvimento realizadas dentro da organizao, e entre os sistemas da organizao e os sistemas utilizados por parceiros de desenvolvimento. Como qualquer ocorrncia de converso de dados na transmisso de informaes nessesdoisnveisdeintegraoindesejvel,omodelodoprodutodeveadaptarsea vriossistemasdiferentes(YANGetal.,2008). Alm de abranger uma vasta rede de interrelacionamentos entre as mais variadas tarefas tcnicas, o desenvolvimento de produtos tambm determinado pelosfatoreshumano,organizacional,asestratgiasdefinidaspelasempresasparaos produtoseastecnologiasqueestodisponveis.Deixardeconsiderarqualquerdestes fatoresduranteaimplementaodamodelagemresultaemuminvestimentoquegera
28

baixoretornoouatprejuzo.Aimplementaoeficientedamodelagemdeproduto depende, por exemplo, da educao dos profissionais envolvidos: direcionar a sua formao e investir em pesquisa bsica essencial, pois somente projetistas que compreendam as reais potencialidades e limitaes da modelagem podero desenvolverprodutosdemaneiraeficiente(KRAUSEetal.,1993).Aquestodofator humano continua sendo importante tema de pesquisa relacionada modelagem de produto,comosepodeverificarnoestudorealizadoporNilssoneFagerstrm(2006), onde ressaltam a importncia da considerao cuidadosa dos diversos envolvidos (stakeholders) e as suas diferentes necessidades por informao durante o desenvolvimentodoproduto. Lars Hvam props uma abordagem para a implementao da modelagem de produtobaseadanateoriadossistemas,ondeosprocessosqueconstituemascadeias produtivas so considerados como as atividades de um sistema, que nesse caso o desenvolvimento do produto. Na primeira etapa so analisadas as diferentes tarefas do sistema, o que servir de base para determinar o grau timo de suporte das tecnologias de informao aplicadas. Essas anlises enfocam trs grupos de informao: a estratgia da companhia, o benefcio econmico que pode ser potencialmenteobtidopelaimplementaodamodelagemdeprodutoemcadauma dasatividades,efinalmenteasquestesderepresentaodedadoseestruturaodo conhecimento sobre o produto. O resultado dessa fase fornece ao sistema de planejamentodosprocessosprodutivostodasasinformaesnecessriasparaquese obtenhaumaproduootimizada.Apsconcludasessasanlises,iniciadaasegunda etapa de implementao da modelagem, na qual so definidos os contedos e a estrutura dos sistemas de informao que daro suporte ao desenvolvimento do produto(HVAM,2001).

2.5Perspectivasparaamodelagemdeproduto
A modelagem de produto no foi adotada em massa por todos os setores e atividadesindustriais,mascontinuasendoumatecnologiachavenodesenvolvimento eficaz de produtos, e essencial para as estratgias de competitividade das corporaes. Documentos em papel continuam a ser substitudos por documentos

29

eletrnicos,eestescontinuamasersubstitudospormodelosdeprodutos.Aindano foram desenvolvidas aplicaes que dem suporte a todo o ciclo de vida de um produto, e provvel que esse nem seja um objetivo atualmente, visto que o desenvolvimento de produtos um processo cada vez mais distribudo entre consrciosdeorganizaesemcooperao.Nestesentido,considerarapossibilidade de transmisso de informaes entre os processos e entre diferentes aplicaes determinante para o desenvolvimento eficiente de produtos (GIELINGH, 2008), e o principalveculoparaatransmissocompletaeinequvocadessainformaoaindao modelodeproduto(YANGetal.,2008).

30

3
ModelagemdeProdutonaIndstriadaConstruo
Severalorganizationsaredevelopingcomputerprogramscapableofdescribingbuildingsatadetail allowingdesignandconstruction.Theseprograms,consistingofalargedatabase,routinesfor manipulation,analysisanddocumentpreparation,havethepotentialofreplacingdrawingsas constructioncontractdocuments.CharlesEastman,1976.

sequnciadeatividadesrealizadasduranteoprojetoeaconstruodeedifcios pode ser considerada um processo de desenvolvimento de produtos. Podem

existir vrios produtos intermedirios durante o processo, na forma de entregas de projetos, mas o que mais interessa modelagem de produto na construo o produtoqueatendeaoclientefinalaedificaoconcluda.Definiraconstruocomo desenvolvimento de produtos permite introduzir na indstria vrias das prticas j desenvolvidasparaaumentaraeficincianaproduodaindstriademanufatura.Os contextos das duas indstrias, porm, divergem largamente, e compreendlos essencial para que essa transferncia seja bem sucedida. Projetos na indstria da construo so geralmente desenvolvidos por equipes fragmentadas, com pouca considerao das necessidades do cliente, e os produtos entregues normalmente estoacimadooramentoedoprazodefinidos.Almdisso,oprojetodeumproduto na indstria da manufatura d origem a vrias unidades indistintas, fabricadas em srie, enquanto na construo o desenvolvimento de produto origina apenas uma unidade(TZORTZOPOULOS,2004). Outra especificidade da indstria da construo a destinao principal dos investimentos. Podese classificar as tipologias produtivas em trs grupos: as que concentraminvestimentosnodesenvolvimentodenovosprodutos,asqueconcentram investimentos no desenvolvimento de melhores processos de produo, e as que concentram investimentos na manuteno de recursos (pessoas ou equipamentos) que o caso da indstria da construo. Por investir pouco em desenvolvimento de produtos e processos de fabricao, a indstria da construo no se beneficia dos avanos nas tcnicas de gesto da produo tanto quanto outros setores industriais, em especial o de manufatura. Alm disso, enquanto outros setores concentram
31

grandes quantidades de investimento antes mesmo de qualquer comercializao, a indstria da construo essencialmente dependente da contratao formal do servio,oqueemgerallimitaacapacidadedeescolhaedeterminaodeestratgias prpriasdasempresas(WORTMANN,1992). A construo demanda ferramentas de informao adequadas ao desenvolvimento oneofakind, no qual situaes diferenciadas e imprevisveis invariavelmente emergem a cada projeto. Os requisitos para as ferramentas so decorrncia da necessidade de fabricao de produtos nicos, atravs de processos nicos, por um grupo de parceiros configurado unicamente para um projeto especfico. Esta situao no favorvel ao desenvolvimento de sistemas de informao,porqueemgeralosdesenvolvedoresprocuramporprocedimentosquese repitam, e estruturam as aplicaes a partir de algoritmos que respondem a eles. Associada a esta condio desfavorvel, existe a resistncia adoo de tecnologias porpartedosatoresdaindstriadaconstruo.SegundoTurk,emprojetostpicosna construo,colaboramparceiroscomdiferentesnveisdeproficinciaemtecnologias de informao, e normalmente o denominador comum nvel menor. A mdia de domniodastecnologiasdeinformaoporequipesnosetordaconstruotambm considerada mais baixa do que em outros setores da indstria. A construo um ambiente ruim para a transferncia de tecnologia, por ser comparativamente mais conservadora,compoucainovaonocorpocentraldeconhecimentostcnicos,eno incentivar a educao continuada como prtica comum. Finalmente, os profissionais da construo particularmente os projetistas e consultores trabalham em vrios projetos simultaneamente, e a introduo de uma nova tecnologia por um determinado projeto gera a necessidade de trabalharem com dois tipos de ferramentasaomesmotempo(TURK,2006). NascimentoeSantosclassificamemquatrogruposasbarreirasparaousoda tecnologia da informao na construo civil. Aspectos profissionais estariam no primeiro grupo: profissionais contratados com menos exigncias, metodologias de trabalho diferentes, gerentes pouco capacitados, modo de trabalho individual e resistnciaamudanas.Nosegundogrupo,barreirasligadasaosprocessosgerenciais: operaesquenoseutilizamdastecnologiasmaisrecentes,faltadepadronizaona
32

comunicao e mtodos de gesto ultrapassados. Um terceiro grupo formado por barreirasligadassempresaseculturacorporativa:baixoinvestimentoemTI,falta de confiana nos resultados obtidos pela TI e falta de treinamento em tecnologias. Finalmente,umquartogrupodebarreiras,diretamenteligadasaosprpriosaspectos tecnolgicos: segurana dos dados contra intruses e violaes, conexes de baixa velocidade, custos de aquisio e manuteno dos equipamentos (NASCIMENTO e SANTOS,2002). Como consequncia das suas caractersticas diferenciadas e da resistncia adoo de tecnologias de informao, a indstria da construo considerada tecnologicamente atrasada em relao aos demais setores, com baixos ndices de produtividade mesmo em pases industrializados (LAM et al., 2005; BDARD, 2006). PesquisasrealizadasporWangeoutrosautoresrevelaramqueoatrasodosprocessos de execuo de obras em decorrncia de falhas na documentao do projeto consideradofatocomumparaaindstriadaconstruobritnica.Umterodasobras daquele pas sofrem atrasos ou excedem os oramentos iniciais em virtude de informaesincorretascontidasnosdesenhosedocumentos(WANGetal.,2006). No Brasil, os mtodos empregados na construo de edificaes mostramse tecnologicamente defasados mesmo em comparao com outros setores da prpria indstria da construo, como a construo de obras de infraestrutura (NOVAES, 1996). A defasagem tecnolgica do processo construtivo resulta em maiores custos, desperdciodemateriais,baixaprodutividadeeprodutosdemqualidade(MELHADO e AQUINO, 2001). Souza, estudando os processos empregados por empresas de construo,constataquedeterminadasfasesdaexecuodaobra,comoasalvenarias devedao,podemapresentarumndicededesperdciodemateriaisdeat40%.O autor defende que projetos com mais qualidade podem racionalizar o consumo de materiais,reduzindoaextraodematriasprimas(SOUZA,2005). Wortmann(1992)observouqueamaioriadosaspectoscobertospelasteorias de gesto da produo aplicavamse somente fabricao em srie de produtos annimos.Segundoele,ossistemasdeinformaoutilizadosnessetipodefabricao geralmenteassumemqueainformaocompletasobreoprodutoumprrequisito

33

para o incio da fase de produo. A gesto da fase de produo, por sua vez, consideradaapenasumaquestodetomardecisesracionaisbaseadasemrelatrios de acompanhamento e totalizao. Na produo de artefatos nicos, entretanto, a informao completa, quando existe, fica disponvel apenas na concluso do empreendimento, e a gesto da produo deve motivar os profissionais envolvidos para que atuemcooperativamente, compensando esta desvantagem.Os sistemas de informao para o desenvolvimento de produtos nicos devem considerar esse aspecto,eproporcionarmeiosparaarpidaatualizaodainformaoentretodosos envolvidos quandoocorremsolicitaesporpartedosclientes.EastmaneKutay,em consideraosobreestruturasdedadosparasistemasCADnaindstriadaconstruo, fazemamesmaobservaosobreocarterinerentementeincompletodainformao doprojetodeedifcios(EASTMANeKUTAY,1989). Outracaractersticadaproduonaindstriadaconstruoacomplexidade do produto. Edificaes so compostas por milhares de partes distintas, que podem ser organizadas em vrias composies, dependendo da funo e dos processos construtivos.Porisso,comumhaverpequenasdiferenasmesmoentreinstnciasde uma parte que utilizada repetidamente. Todas essas partes devem ser modeladas paraqueaintegridadedainformaosejamantida,assimcomoocorreemprodutos de manufatura. Porm um projeto de edificao tipicamente concentrase na integraoentrediferentessistemasecomposies,enquantono desenhoindustrial eleconcentrasenaotimizaodecomponentesindividuaisparaaproduoemsrie. Emboraosconceitoscentraissejamosmesmos,asfuncionalidadeseinterfacesdeum sistema para modelagem de edifcios so muito diferentes dos utilizados na manufatura. Por exemplo, mesmo que a modelagem de slidos possa permitir a definiointuitivaeprecisadaformadeumapeamecnica,nobviocomoessa funcionalidade deveria ser empregada no projeto de edifcios, que envolvem composiesdegrandenmerodepartes.Revisaremodificarummodelocomposto por slidos geomtricos representando partes detalhadas individualmente pode ser uma atividade mais demorada e sujeita a erros do que fazlo usando desenhos em papel(SACKSetal.,2004).Issopodeserilustradopelorecentetrabalhoapresentado por Marcos e outros autores (2007), no qual so avaliadas as condies de

34

acessibilidade em uma habitao utilizando o software CATIA. As funcionalidades de identificao de conflitos espaciais e visualizao tridimensional oferecidas pelo programa foram teis na verificao da adequao do produto e produziram uma anliseadequada,masacriaoeamodificaodomodeloutilizadoparaasimulao foram dificultadas porque o CATIA no oferece funcionalidades necessrias para operaescomunsnoprojetodeedifcios,comomoverjanelaseportasouvisualizaro edifcioemplanta. Como resultado dessas especificidades, surgiu um ramo da informtica especializado na criao de aplicaes para a indstria da construo. Turk (2006b) props a definio formal do corpo de conhecimentos que durante os anos foi conhecidocomoconstructioninformatics,computingincivilengineering,construction information technology ou ainda information and communication technology in construction e outros nomes. O autor define a informtica na construo como um ramocientficocomumanfaseprpriasobreasteoriasdeinformaoecomputao, orientadoparaasoluodosproblemasespecficosoriundosdosprocessosdeprojeto econstruodeedifcios,situadoentreapesquisacientficaeasoluodeproblemas deengenharia.

3.1Origensdamodelagemdeprodutonaindstriadaconstruo
A idia da modelagem de produto na indstria da construo quase to antigaquantoosprimeirossistemasCADdesenvolvidospelogrupodeDouglasRossno MIT,noinciodadcadade1960.Vriosdosconceitosfundamentaisdaaplicaoda modelagemnodesenvolvimentodeprodutosnaconstruoforamapresentadosainda durante a dcada de 1970. Gingerich, em 1973, observou que os programas de necessidades, sistemas e materiais utilizados nos edifcios estavam evoluindo muito rapidamente, e que a coordenao do projeto tornavase cada vez mais complexa. Uma resposta a essa situao seria o uso de abordagens mais eficientes para o computador, que integrassem as tarefas que at ento eram executadas por aplicaes isoladas. Ele apresentou um prottipo de um sistema para a fase de definio da volumetria no projeto arquitetnico, baseado em duas interfaces: uma bidimensional,ondeoselementosdoprojeto eraminseridos,eoutratridimensional,

35

onde poderiam ser visualizados e modificados. As interfaces eram integradas e atualizavamse automaticamente aps as modificaes no projeto. Uma terceira interfacefoiprevistapeloautor,quepermitiriadetalharoprojetoinserindomateriais, acessrios,portas,janelasesistemasestruturais(GINGERICH,1973). A ento nascente tecnologia de bancos de dados foi por muito tempo indispensvel para o desenvolvimento de sistemas de modelagem de edifcios, pois ofereciaapossibilidadedeestruturardadosmaisadequadamente,erecuperlosmais rapidamente do que com a utilizao de arquivos sequenciais. Em 1975, Charles EastmancunhouaexpressoBuildingDescriptionSystem(BDS)paradesignarosCADs que se baseavam no em desenhos, mas sim em estruturas de dados contendo informao geomtrica associada a atributos diversos, capazes de representar mais adequadamenteoselementosdeumprojeto.BDSsforamdefinidospeloautorcomo grandes sistemas de informao, com rotinas para entrada, manuteno de dados, processamento de anlises diversas e gerao automtica de relatrios. Desenhos tcnicos,comoosnecessriosparaaconstruodoedifcio,eramapenasmaisumtipo de relatrio, descrito graficamente. Eastman props que essa forma de representar edificaes poderia tornarse a principal documentao utilizada na indstria da construo(EASTMAN,1976). Osmodelosutilizadosnestessistemasprecisariamsercompletosecoerentes, representando tanto os elementos do edifcio como os seus arranjos. Dada uma completa representao tridimensional do artefato sendo projetado, o projetista poderia ter certeza de que todas as projees bidimensionais geradas a partir dela seriam consistentes. As informaes sobre a forma dos objetos poderiam ser integradascominformaesfuncionaisededesempenho,entoaplicaespoderiam acessar e manipular os dois tipos de dado, sem tradues manuais que so costumeirasquandoseutilizaosdesenhos.Aplicaesutilizandomodelosdeedifcios poderiamfazerverificaesdeconformidade,avaliaroprojetoestrutural,trmicoou de outras propriedades, estimar custos ou adicionar detalhes padronizados. Outras aplicaespoderiamgerarvisualizaes,projetosparaconstruoecontrolenumrico para produo de peas. Muitas outras aplicaes poderiam ser imaginadas para os maisdiferentessegmentosdoprojeto(EASTMANeHENRION,1977).
36

Apesar das vantagens tericas e de apresentaes ocasionais de sistemas prototpicos, a modelagem de produto foi ainda menos adotada na indstria da construo do que fora registrado em outros setores da indstria. Kalay, em 1985, observa que o rpido desenvolvimento tecnolgico havia gerado uma crena na possibilidade de aumento de produtividade e economia de recursos pelo uso do computador. Como a produo de edifcios cada vez mais complexos envolvia uma quantidadecrescentederecursosfsicoseinformaes,imaginousequeosprocessos da indstria da construo deveriam seguir a mesma tendncia de integrao e automao observada na indstria da manufatura. Entretanto, mesmo sendo desenvolvidos havia duas dcadas, os sistemas CAD permaneciam gerando um impacto apenas marginal no processo de projeto de edificaes. Na engenharia eltrica,umdosprincipaiscamposdedesenvolvimentodoCADnosprimeirosanosda tecnologia, a adoo e a influncia fora imediata: permitiu que os projetistas aumentassem a complexidade dos circuitos integrados em vrias vezes, reduzindo significativamente o tempo de desenvolvimento. Para Kalay, a falha do CAD em melhorar as prticas de projeto de edificaes e os seus produtos era resultado principalmentedopapeldadoaoscomputadoresnoprocessodeprojeto:maisde90% dos sistemas instalados ao redor do mundo, at ento, eram utilizados apenas para desenho(drafting).Paraele,digitalizardesenhosnoeranecessariamenteumaetapa essencial no progresso de um produto da concepo produo, mas apenas uma forma de comunicao do resultado esperado para uma etapa. Para que os computadoresfossemempregadosdemaneiramaisefetivanoprocessodeprojetode edificaes, a sua capacidade deveria ser desenvolvida da mera descrio de informaes geomtricas para a simulao de decises de projeto. Era necessrio incluirosignificadotcnicodoselementosdoprojetoeapoiaroprocessodeanlise dasdecisesprojetuaisatravsdeumconjuntoderegraseprocedimentosquefossem capazes de extrair informao relevante do modelo. Deveria ser possvel inferir informaes que no fossem explicitamente modeladas, e tambm selecionar aes quemodificassemomodelodamaneiradesejada(KALAY,1985b). Em uma concisa reviso sobre o desenvolvimento do CAD na indstria da

construo durante a dcada de 1980, Eastman relata queos objetivos originais que

37

justificaram a tecnologia continuavam longe de ser implementados na prtica. A dcada de 1980 observou a popularizao do Personal Computer, o PC, em substituio aos minicomputadores utilizados na dcada anterior para o desenvolvimento de vrios sistemas experimentais e comerciais. Tambm foi nesta dcadaqueomodelodedadosproprietriodaAutodesk,oDXF,tornouseaformato mais utilizado para a troca de informaes na indstria (KALAY, 1985b). Embora em teoriaonveltecnolgicodacomputaojpossibilitasseaimplementaodevrias das propostas iniciais do CAD para projeto de edificaes, o desenvolvimento de edifcios no computador continuava centrado em desenhos. Alm disso, Eastman observa que a maioria dos escritrios que haviam adotado o CAD o fizeram primeiramente por presso dos clientes, que procuravam por empresas que transmitissem uma imagem de modernidade. Mesmo o benefcio da agilizao de tarefas repetitivas proporcionado pela digitalizao dos desenhos era considerado apenas em segundo plano. De modo geral, a grande falha na implementao do computador no processo de desenvolvimento de produtos na construo continuava sendoarestritautilizaodoconceitodemodelagemdeproduto(EASTMAN,1989). CADs comerciais para modelagem de edifcios foram disponibilizados j no inciodadcadade1980.EssafoiamesmapocadosurgimentodosCADscomerciais dedesenho.AlgunstextosrecentessugeremqueasversescomerciaisdosCADsde modelagem, atualmente conhecidos como BIM CADs evoluram a partir dos CADs comerciais de desenho. Tse e outros autores (2005), porm, afirmam o contrrio: a primeiraversodoAllplan,daalemNemetschek,datade1980(NEMETSCHEK,2008) e a empresa hngara Graphisoft lanou em 1984 o Radar CH, que na sua segunda verso (em 1986), passaria a chamarse ArchiCAD (GRAPHISOFT, 2008a). Ambos estavam bastante a frente do seu tempo, considerando que a primeira verso do Autocadde1983eadoMicroStationdatade1984.Nohouve,portanto,relaode evoluo entre os softwares. A representao de edifcios por modelagem e a representao por desenhos foram duas abordagens diferentes adotadas pelas empresas desenvolvedoras desde o incio da disseminao dos CADs comerciais. Porm,apropostadamodelagemdeedifciosestavamuitodistantedacapacidadede hardwaredisponvelnoscomputadoresdapoca,eosCADsbaseadosemprimitivos

38

geomtricosearepresentaodoedifciopormeiodedesenhosacabaramportornar seopadroparaousodocomputadornaindstriadaconstruo(TSEetal.,2005). No incio da dcada de 1990, CADs de modelagem de edifcios j eram

comercialmentedisponveishdezanos.OArchiCAD,porexemplo,estavanaquarta verso e a sua interface de modelagem de edifcios e gerao automtica de documentaojeraperfeitamentereconhecvelparaosusuriosatuais(VRTESI et al.,1991).Amodelagemdeedifciosficoudisponvelparaopblicogeralinicialmente nos sistemas Macintosh, e para o projeto de pequenas construes. Essa situao comeariaamudarcomaexignciapormaiorqualidadeeprocessos maiseficientes naindstriadaconstruo,quefezressurgirointeressepelamodelagemdeproduto. Eastman atentou ento para o fato das idias estarem sendo redescobertas ou at reinventadas,equemuitodoinsucessodaaplicaodatecnologiadesdeadcadade 1970eraresultadodafaltadecompreensodosseusobjetivosepotencialidadespara aindstriadaconstruo(EASTMAN,1992). 3.1.1BIM Atualmente, o novo nome da proposta de modelagem de produto na

construoBIM,acrnimodeBuildingInformationModeling(IBRAHIMetal.,2003). OtermoBIMfoicriadopelaempresaamericanaAutodeskemmeadosdosanos1990 parapromoveroseunovoCAD,oRevit.Aidiaerareuniremumnicoconceito(de marketing, inclusive) o conjunto de funcionalidades integradas oferecidas pelo novo produto. Em essncia, o Revit um CAD de modelagem de edifcios, assim como ArchiCADeAllplanjerammaisdedezanosantes.PormotermoBIMmostrouter umforteapelocomercial,elogofoiadotadopelasdemaisfabricantescomoestratgia de mercado para divulgar os seus prprios CADs de modelagem de edifcios. Definir BIMcomoumtipodesoftware,porm,reduzmuitooseusignificado,quederivado dalongatradiodeutilizaodocomputadorcomosuporteaoprojeto,apresentada nositensanteriores.Nestetrabalho,otermoBIMutilizadonosentidopropostopor Eastmaneoutrosautores(EASTMANetal.,2008),quenaverdadeumacompilao dos princpios da modelagem de produto na construo, desenvolvidos a partir da dcadade1970.

39

Seja a modelagem de produto na construo chamada BIM, prototipao de

edifcio, modelagem de edifcio, construo virtual ou qualquer outro nome, atualmente considerada um catalisador para a adoo das prticas integradas de projeto. A sua utilizao tem demonstrado significativas vantagens sobre processos tradicionais,mesmoemsituaesdeintegraolimitada(porexemplo,apenasentreo projeto arquitetnico e o estrutural). No futuro, esperase que uma integrao mais ampla d origem a novas oportunidades de negcios e melhore a produtividade da indstria da construo, que sabidamente inferior aos outros setores da indstria. Contratantes e profissionais do setor apenas comearam a compreender as novas possibilidadesoferecidas(NIBS,2007).

3.2EscopodaBIM
Na indstria da manufatura, a modelagem de produtos surgiu para integrar a

informaoemtodososprocessos dociclodevidadeumproduto.O seucampode estudo,portanto,abrangetudoqueestrelacionadocomqualqueratividadeentrea concepoeadisposiofinaldoproduto.Domesmomodo,aBIMabarcaumamplo espectro de conceitos, atividades, tcnicas, ferramentas e atores, reunidos em relacionamentoscomplexosedistribudosportodasasatividadesinerentesindstria da construo. Estudos sobre a BIM podem incluir trabalhos com abordagens to diversas quanto a definio fenomenolgica do termo modelo (TURK, 2001) e a estruturaolgicadoseuarmazenamentoemdisco(HANNUS,1991). Noobstanteasuaamplitude,aBIMpodesermaisfacilmentecompreendida se for abordada em diferentes nveis de abstrao, sendo nveis mais altos relacionadoscomocontextodaaplicaodatecnologia,eosmaisbaixosrelacionados com os aspectos mais tcnicos das suas ferramentas. A iniciativa de regulamentao da modelagem de produtos para a indstria de obras de infraestrutura nos Estados Unidos, a National Building Modeling Information Standard (NBIMS), por exemplo, adotaumesquemadeabstraoemtrsnveis:ABIMentendidacomoumproduto, como uma ferramenta e como um processo. Como um produto, a BIM referese ao modelo da edificao, ou seja, uma entrega do processo de projeto baseada em padres abertos e criada por ferramentas de informao. Como ferramenta, a BIM

40

referese s aplicaes que interpretam o modelo da edificao e agregam informaeserepresentaesaele,chamadasBIMauthoringtools.Porfim,aBIM entendida como um processo colaborativo formado por atividades desenvolvidas durantetodoociclodevidadaedificao(NIBS,2007). Interpretar a BIM como processo, ou seja, a partir de um nvel de abstrao maisalto,essencialparaasuaefetivacompreenso,jquequalquermodelagemde produto tem como prrequisito integrar diferentes fases do desenvolvimento de um produto. Para este trabalho, porm, os nveis mais baixos de abstrao tm uma importncia central, pois so cruciais para o acesso aos modelos de edifcios. Alm disso, ajustar os nveis de abstrao para que enfoquem os aspectos mais tcnicos, mesmoquandosorelacionadosaocontextodaaplicaodamodelagem,maistil paraosobjetivosdestadissertao. 3.2.1ClassificaodaBIMpornveldeabstrao Neste trabalho proposta uma classificao original, em quatro nveis de abstrao:metamodelagem,modelagem,modelo,eobjetosaspartesquecompem o modelo. No nvel mais alto, o da metamodelagem, figuram as questes sobre modelos conceituais, interoperabilidade de aplicaes e os impactos da tecnologia sobre a indstria, por exemplo. No nvel da modelagem so abordadas questes relacionadas criao dos modelos, e consequentemente as funcionalidades e interfaces das aplicaes CAD que realizam a modelagem de produto, tambm chamadosBIMCADouBIMbasedCAD(IBRAHIMetal.,2004).Nonveldomodeloso enfocadas as relaes semnticas entre os diferentes objetos que o compem. Finalmente, no nvel mais baixo, o dos objetos, so abordadas as questes sobre a funcionalidade das partes que compem o modelo, como inteligncia contextual, comportamento, atributos necessrios para a descrio de elementos construtivos, entreoutros. Cada nvel de abstrao proposto inclui diversas caractersticas importantes paraatecnologiaBIM,maspossvelpercebernaliteraturasobreotemaqueexistem conceitoscentraisquepodemseratribudosparacadanvel,quandoaBIMenfocada apartirdeumpontodevistamaistcnico.Nametamodelagem,oconceitoprincipal

41

a interoperabilidade entre aplicaes; na modelagem, a consistncia da informao; nomodelo,aestruturaosemntica;enosobjetos,ocomportamento.Ostrabalhos consultados, embora utilizem terminologias diferentes para os conceitos, no atribuemotermomodelagem(ouequivalente)aabordagensdedesenvolvimentode produtos que no apresentem estas quatro qualidades. O esquema abaixo ilustra as relaesentreosdiferentesnveisdeabstraodaBIM:

EsquemaderelaesentreosdiferentesnveisdeabstraodaBIM.

Nas sees seguintes ser apresentada uma rpida reviso das principais caractersticasdatecnologiademodelagemdoedifcio,baseadanaestruturaodos quatro nveis de abstrao proposta. Esta reviso foi baseada em definies e observaessobreotemaapresentadasemtrabalhoscientficosapartirdadcadade 1970. Muitos deles, portanto, ainda no se referiam modelagem de produto pelo termoBIM,masisso noafetaasuarelaocomodesenvolvimentoatualdotema. Nointenodestetrabalhoproduzirumarevisoexaustivanemabsoluta:osartigos citados destacamse por terem exercido influncia considervel sobre o campo de pesquisaverificadapelonmerodetrabalhosqueoscitamcomorefernciaoupor conteremumaabordagemdidticadiferenciada.Paraumarevisomaisaprofundada, sugeresequeoleitorconsulteosdoistrabalhosmaisextensossobremodelagemde produtonaconstruo,osquaiscobremosquatronveisdeabstraomencionados: BuildingProductModels:ComputerEnvironmentsSupportingDesignandConstruction (EASTMAN, 1999) e o mais recente BIM Handbook: A Guide to Building Information Modeling for Owners, Managers, Designers, Engineers and Contractors (EASTMAN et al.,2008).

42

3.3Objetos
O conceito de objeto vital para a modelagem de edifcios, e possvel

perceberoseudelineamentoapartirdadcadade1970,emvriostrabalhoscitados nessa dissertao. Objetos so unidades de informao criadas para representar os diferentes elementos que constituem um projeto de edificao, incluindo as suas caractersticas e relacionamentos com outros objetos (HANNUS, 1991). Eles contm informao suficiente para permitir vrios tipos de anlises e representaes (EASTMAN, 1992; IBRAHIM et al., 2004). Os principais tipos de objetos so os que representamelementosconstrutivos,comoparedes,colunas,vigas,janelas,etc.,mas tambmhobjetosquerepresentamespaos,zonas,mecanismoseatassimbologias utilizadas nos desenhos, como cotas, indicaes, nveis, entre outros (EASTMAN, 1976). Diferentes colees de objetos podem ser desenvolvidas para agilizar o

processodeprojetoourepresentarmaisfielmenteoselementosutilizados.Escritrios podem desenvolver padres ou mdulos contendo informaes utilizadas regularmenteefabricantespodemoferecerobjetosrepresentandoseusprodutos,do mesmomodoquefeitocomblocosnoAutocad,pormcontendomaisinformaes do que simples representaes bidimensionais (EASTMAN, 1976). Ibrahim e Pentilla citam a possibilidade de disponibilizao de catlogos de objetos na Web, ou bibliotecas pblicas de objetos, permitindo que os projetistas insiram rapidamente informaesgeradaspelosfabricantesdemateriais(IBRAHIMetal.,2004;PENTTILA, 2005).Essaoperaopoderiaagregarautomaticamenteaoprojetonosaformaea representaodoselementosconstrutivos,comotambmocusto,prazodeentrega, desempenho, instrues para montagem ou construo, e tambm para operao, manuteno e disposio dos materiais. Essa informao poderia ser extrada posteriormente, por aplicaes de anlise ou planejamento da construo, por exemplo.Emboraalgumasbibliotecasdeobjetosjsejamdisponveisprincipalmente para peas de moblia a informao contida ainda limitada, e comumente disponibilizadaemformatosproprietrios,quenopodemserutilizadosemtodosos BIMCADs.

43

3.3.1Parmetros A informao a respeito do elemento construtivo a ser representado armazenadaemdiferentesparmetrosquepodemsercombinadospelousuriopara produzir diferentes respostas. Ibrahim e outros autores afirmam que h dois tipos bsicosdeparmetros:osquearmazenaminformaosobreaformadoselementos como posio, dimenses ou transformaes geomtricas e parmetros que armazenam caractersticas funcionais dos elementos, como material, especificaes, requisitos legais, procedimento de montagem, preo, fabricante, distribuidor, etc. (IBRAHIMetal.,2003). Parmetros geomtricos e parmetros funcionais podem armazenar todas as informaes disponveis sobre um elemento construtivo, mas eles no determinam necessariamente a forma com que so representados. Eastman afirma que durante algumtempoacreditousequeoperaesdecorterealizadasnosslidosgeomtricos construdos a partir dos parmetros dos objetos seriam suficientes para gerar a documentao para a construo. Plantas, cortes e elevaes eram consideradas apenas uma questo de situar apropriadamente um plano e ento extrair os pontos das superfcies dos slidos que estivessem contidos nele. Porm, apenas o resultado dessa operao no gera informao suficiente para as representaes utilizadas na construodeedifcios,quesoemgrandepartesimblicas.Dessemodo,ascriao dasrepresentaesdeedifciospartemdageometriaresultantedaoperaodecorte, mas devem ser complementadas por caractersticas determinadas pelas convenes de desenho tcnico. Essas convenes incluem, por exemplo, espessuras e tipos diferentesdelinhas,hachuras,indicaestextuaisoupictricas.Produziressetipode informao a partir somente de operaes de corte de slidos geomtricos praticamenteimpossvel,ouexigiriaumtrabalhoadicionalmaiordoqueonecessrio paraproduzirdesenhosemvezdeutilizarmodelos.Umexemplodissosoasportas, cujarepresentaosimblicavariadeacordocomotipodedocumentodesejado,ou indicaesdepontoseltricos,quesorepresentadosemplantacomoumsmbolo,e nocomotomadasemcorte.Paracomportaremseadequadamentenestasituao,os CADs para modelagem de edifcio precisam de um terceiro conjunto de parmetros, relacionados s diferentes representaes possveis para um determinado elemento
44

construtivo.Estesparmetrosindicamcores,linhas,hachuras,caracteres,simbologias padronizadas para a complementao das representaes, a partir da geometria resultantedasoperaesdecorte(EASTMAN,1991).NosBIMCADsessesparmetros soacessadosapartirdajaneladeconfiguraodosobjetos,comomostradonafigura 3.01.

Fig.3.01:janeladeconfiguraodos parmetrosderepresentaodeumobjetoparedeno ArchiCAD.

Em algumas situaes, como detalhamentos em grande escala, pode ser necessriosubstituircompletamenteageometriaresultantedaoperaodecortepor um conjunto arbitrrio de primitivos geomtricos, que representam melhor a informao ou tornam o trabalho de desenho mais fcil (EASTMAN, 1992). Essa substituio depende da inteno da documentao resultante, e da fase em que se

45

encontra o projeto. Por exemplo, no prtico modelar inteiramente os sistemas hidrulicoeltricosdeumedifcioapenasparaqueastubulaesapareamcortadas nos detalhes dos shafts no projeto arquitetnico. Essa informao, embora correta, noagregavalorsuficienteparacompensarocomplicadotrabalhodemodelagem.Por outrolado,otrabalhodemodelagemdoselementosdosdutosdearpodecompensar em projetos complementares, onde pode facilitar a avaliao das diversas solues possveis,permitiraidentificaodeconflitosespaciais,eproduzirautomaticamentea documentaoparaamontagemdossistemas. 3.3.2Comportamento Nohlimitaesparaonmerodeparmetrosquepodemserincludosem um objeto, mas algumas situaes de projeto no podem ser resolvidas apenas com dados,pormaisbemestruturadosquesejam.Sonecessriostambmprocedimentos (EASTMAN, 1992). Procedimentos so algoritmos descritos em linguagens de programaoestruturadasquesoencapsuladosnosobjetosparamtricoseoriginam os seus diferentes comportamentos. Os comportamentos so ento ativados diretamente pelo usurio, ou indiretamente por rotinas do BIM CAD, gerando como resultados informaes que podem ser utilizadas em anlises ou para criar representaes (EASTMAN, 1991). Lee e outros autores afirmam que o comportamento do objeto a capacidade de responder a estmulos externos e internos. Os estmulos externos so gerados por uma situao comum a todos os objetos,comoumamudanadevariveisglobais.Estavarivelentopassadapara todososobjetos,podendosobreporseusparmetrosoriginais.Osestmulosinternos socausadospelamodificaodeatributosdoprprioobjeto(LEEetal.,2006). Porexemplo,oobjetodoordoArchiCADrespondeamodificaodoparmetro largura da porta um estmulo interno atualizando automaticamente a representaoemplantadoobjeto.Oobjetotambmpoderesponderaumestmulo externo, como a redefinio da escala de representao da planta (uma varivel global).Avarivelglobalescalapassadaatodososobjetospresentes(osqueso visveis), o que provoca uma reorganizao e seleo automtica de parmetros de cadaumeaconsequenteatualizaodasrepresentaesresultantes.Oresultadode

46

uma modificao de varivel global em objetos mostrado na figura 3.02: o comportamento dos objetos gera uma representao mais simplificada e ajusta hachuraseosmbolo.

P01

P01

Fig.3.02:atualizaoautomticadarepresentaodoobjetoquandoaescaladerepresentaoem plantamodificadade1:20para1:100,noArchiCAD.

A natureza da vista selecionada pelo usurio (planta, corte, elevao, perspectiva) tambm pode ser considerada uma varivel global, e gerar diferentes vistas um estmulo externo ao objeto. Ao mudar da representao em planta para umcorte,porexemplo,oBIMCADpassaatodososobjetospresentesavarivelglobal quedeterminaotipodevistanoqualdevemserrepresentados.Ocomportamentode cadaobjetoentorespondeprocessandoosparmetrosadequadoseproduzindouma novainstnciaderepresentaoautomaticamente(EASTMANetal.,2004).Nafigura 3.03somostradasquatroinstnciasderepresentaooriginadasporumobjetodoor do ArchiCAD: planta, elevao, corte, e dois tipos de perspectiva uma detalhada, paraserutilizadacomoumamaqueteeletrnicarealista,eumasimplificada,quepode serexportadaparaumsoftwaredeanlisededesempenho.

P01

Fig.3.03:diferentesrepresentaesgrficasinstanciadasapartirdeummesmoobjetodoordo ArchiCAD

47

Embora as diferentes instncias de representao sejam configuradas pelos diferentesparmetrosdefinidospelousurio,ocomportamentodosobjetosqueas insere no local e no momento adequado, automaticamente. Essa caracterstica, tambm conhecida por sensibilidade ao contexto (ou context aware), o que permiteaoBIMCADextrairdiferentesinformaesdosobjetos,combinandoosseus parmetrosdeacordocomsituaesespecficas. Uma importante funcionalidade derivada da sensibilidade ao contexto o ajusteautomticodonveldedetalhedarepresentaodeumobjetodeacordocoma fase do desenvolvimento do edifcio. Durante o projeto, a informao tornase articuladaincrementalmente,enoserianaturalnemconvenienteexigirqueousurio fornecesse todos os atributos do objeto durante a sua primeira insero (EASTMAN, 1976).Almdisso,oprojetodeedifciosumprocessomultidisciplinar,queenvolve participantes, conhecimentos e informaes de vrios domnios. Cada usurio envolvido na modelagem possui uma viso prpria sobre a soluo dos problemas projetuais, decorrente da sua profisso. Portanto, a modelagem requer uma multiplicidadedevises,cadaumaenfatizandoinformaesespecficasdedisciplinas oufasesdoprojeto,emdiferentesnveisderesoluoouabstrao,todasoriginadasa partirdeummesmoobjeto(EASTMAN,1980b;1991;MAHDAVI,2003;IBRAHIMetal., 2004; STOUFFS, 2008). Ibrahim e outros autores consideram que a modelagem paramtricarecursivaarepresentaoresultantedosparmetrosiniciaisdefinidos pelo usurio pode sugerir a necessidade de uma definio complementar. Ou ento objetos so inseridos para que se obtenha uma representao preliminar, que posteriormente ser aperfeioada. Por isso necessrio garantir diferentes comportamentos para o objeto, de acordo com o conjunto de parmetros selecionados, do mnimo ao mximo de definies possveis. Um objeto que tem a capacidadedemantersefuncionalmesmoemcontextosintermediriosdedefinio deparmetrosdenominadopelosautorescomoobjetosemidefinido(IBRAHIMetal., 2003). Agrandequantidadedeparmetrosquepodeserencapsuladaemumobjeto parasimularadequadamenteumelementoconstrutivotrazumgrandepotencialpara a agregao de informaes, mas o comportamento dos objetos que viabiliza a
48

extraodedadoseofereceumafuncionalidaderealparaoprocessodeprojeto.Se umprojetistapretendesseutilizarumCADbaseadoapenasementidadesgeomtricas sem comportamento (um CAD 3D como o 3D Studio, por exemplo) para produzir o resultadomostradonafigura3.03,eleenfrentariaasseguintesdificuldades:primeiro, teria que produzir manualmente uma visualizao em planta, que o resultado da interceptaodetodososelementosdeumpavimentoporumplanoparaleloaopiso. Se houvesse elementos em outros pavimentos, eles teriam que ser ocultados (em layersoudeoutromodo).VriosCADs3Dnooferecemapossibilidadedecriaruma vistaemcorte,ouseja,umainstnciadomodelo,cortadoporumplanodefinidopelo usurio. Nesse caso, o projetista teria que cortar de fato os elementos, criando segmentos de paredes a cada visualizao que precisasse, e ocultando os que estivessementreopontodeobservaoeoplanodecorteimaginrio. Mesmoqueesseenormeecontraproducentedesafiofosseaceitoeconcludo, um simples detalhe corroboraria a afirmao de Eastman sobre a impossibilidade de gerarrepresentaessimblicasapartirdeentidadesgeomtricassimples:portasso convencionalmente representadas abertas em planta, e fechadas em elevao ou corte. Para atender a essa conveno, o projetista teria que rotacionar todos os elementosqueconstituemcadaumadasfolhasdetodasasportas.Jqueaatividade de projeto iterativa por natureza, essa operao provavelmente teria que ser repetida em vrias ocasies. Tudo isso apenas produziria a geometria bsica, resultante das operaes de corte. Uma srie ainda mais complicada de operaes teriaqueserrealizadaparaajustararepresentaosconvenesdedesenhotcnico. Muitos CADs 3D sequer oferecem a opo de definir a espessura das linhas dos elementos, ou ento possuem apenas duas possibilidades: linhas espessas para elementoscortadoseestreitasparaelementosemvista.Comosepodeverpelafigura 3.03,arepresentaodeedifciosrequerumnveldeespecializaomuitomaior. Por se valerem do comportamento dos objetos, os BIM CADs realizam toda essacomplicadaoperaoautomaticamente,demodotransparenteparaousurio.O comportamento permite codificar o conhecimento tcnico a respeito dos elementos construtivos para que seja incorporado ao projeto. A gerao de diferentes representaes o aspecto mais evidente desse conhecimento, mas tambm
49

possvel programar comportamentos que funcionem como prprocessadores, organizando parmetros e passandoos para aplicaes de anlise. Lee e outros autoresdemonstramageraodecomportamentoscodificandoumasriedeobjetos paramtricos representando elementos de concreto prmoldado. Entre os comportamentosestavam,porexemplo,aadequaoautomticadasarmadurasdos consolos dos pilares, de acordo com o tipo de encaixe das vigas ou da carga a ser suportada por elas. Um interessante sistema de notao de comportamentos desejados proposto, para garantir que a transformao das intenes iniciais em algoritmossejarealizadacorretamente(LEEetal.,2006).

3.4Modelo
Otermomodelorefereseaumaestruturadeinformaoquepermitaintegrar diferentes fases do desenvolvimento. Desenhos bidimensionais, embora tambm possamserconsideradosmodelos,namedidaemquerepresentamabstratamente um objeto real, no transmitem informao suficiente para que se obtenha essa integrao.Ibrahimeoutrosautorespropemadistinoentreostermosmodelagem grficaemodelagemdeinformao,paradesignarosmodelosdeacordocomoseu objetivo principal (IBRAHIM et al., 2003). Modelos grficos so construdos para permitir uma melhor visualizao dos conceitos nas fases iniciais ou do resultado pretendidonasfasesfinaisdodesenvolvimentodoproduto,eemgeralnoexercem grande influncia no processo de desenvolvimento como um todo. Um exemplo clssico so as maquetes eletrnicas, que so encomendadas por construtoras para auxiliarnascampanhasdemarketingdoproduto,epoucoinfluenciamoprocessode projeto(SPERLING,2002).Modelos deinformao,comoosmodelosBIM,seguemo paradigma da modelagem de produto: so principalmente veculos para a transfernciaeficientedeinformaoentreasfasesdodesenvolvimento. Transfernciasdeinformaoentreasfasesdedesenvolvimentodosedifcios

sempre ocorreram, independente do veculo utilizado para a comunicao. Atualmente, o veculo mais utilizado so os desenhos criados em sistemas CAD, baseados em primitivos geomtricos. O software Autocad o exemplo mais notrio dessetipodeCAD,eoseuformatoaindaconsideradoaplataformamaislargamente

50

disseminada para produo de documentao na indstria da construo. Uma das principaiscrticasquesefazemrepresentaodeedifciospormeiodedesenhos, que eles so formados por primitivos geomtricos que so incapazes de informar inequivocamente a natureza dos elementos construtivos que representam. Um exemplo clssico a representao de paredes utilizando linhas paralelas: o CAD baseadoemprimitivosgeomtricosarmazenapoucainformaoalmdaposioeda extensodaslinhasquerepresentamparedes.Defato,elesequercapazdeinformar automaticamenteseelassoparalelas,porqueadefiniodoparalelismomantida apenas durante a criao das linhas. Por isso os diferentes elementos que so utilizadospararepresentarparedesemCADsbaseadosemprimitivosgeomtricosno possuem qualquer relao funcional entre si, cabendo ao usurio, treinado para reconhecerpadresconvencionados,interpretloscomoparedes.Afigura3.04ilustra essa situao: o conjunto de elementos que interpretado pelo projetista como paredes,batenteseportaformadoporprimitivosgeomtricossemrelacionamentos funcionais, e operaes acidentais podem desfazer completamente o significado transmitidoporeles.

Fig.3.04:representaoporprimitivosgeomtricoseapossibilidadedeperdadesignificadoaps operaessobreoselementosindividuais.

3.4.1Semntica A qualidade que garante a transmisso eficiente de informaes entre diferentes fases do desenvolvimento de um edifcio, impedindo a ocorrncia de

51

situaescomoesta,asemntica.Essaamaiordistinoentrearepresentaode um edifcio utilizando um modelo em relao representao por desenhos. Os modelosBIMregistramtantooselementosconstrutivoscomoasrelaesfuncionais entre eles, e tambm entre os elementos de representao que os descrevem graficamente. Isso cria um conjunto coerente que pode ser interpretado tanto por usurios como por computadores, e mantm o significado da informao durante as transmisses entre as fases de desenvolvimento (PENTTILA, 2005). Na definio da NBIMS, essa caracterstica foi considerada essencial para a implementao da modelagem na indstria da construo (NIBS, 2007). A importncia de garantir que usurios de diferentes disciplinas em vrias fases do desenvolvimento do edifcio compreendamarepresentaoinequivocamenteevitaerrosereduzanecessidadede comunicaes complementares para esclarecimento de dvidas, aumentando a agilidade dos processos. A importncia de garantir que os computadores compreendam a representao inequivocamente reduz a necessidade de tarefas de reentradadedadoseospossveiserroshumanosquepodemsurgirdessasoperaes. Por exemplo, a representao de paredes em modelos BIM utiliza objetos especializadosemrepresentarparedes,comcomportamentoseparmetrosdefinidos para garantir a coerncia do resultado e a manuteno do seu significado como parede. Por isso, no seria possvel desfazer completamente o significado da representaocomoperaessimilaressapresentadasnafigura3.04.Afigura3.05 ilustraarelaoindissocivelentreoobjetoeoselementosgrficosquecompema suainstnciaderepresentaoemplanta.Aposiodasparedesfoimodificada,masa naturezadosobjetosfoimantida.

52


Fig.3.05:arepresentaoporobjetosparamtricos emumBIMCAD mantmosignificadoda informaoapsoperaesdemodificao.

Almderelaesinternasaoobjetoentreeleoselementosutilizadosparaa suarepresentaopodemserestabelecidasrelaesentrediferentesobjetos:todos oselementosdeumpavimentosomovidoscasoaalturadopavimentoinferiorseja aumentada, por exemplo. Ou ento um objeto representando um lance de escada pode ser subordinado a um determinado pavimento, e quando o pdireito deste pavimento modificado, o objeto recalcula o nmero e a altura dos degraus automaticamente. Essas funcionalidades foram descritas por Eastman h quase 30 anos,duranteodesenvolvimentodosistemaBDS(EASTMAN,1980b;1991). Outra funcionalidade decorrente do relacionamento semntico entre os objetosapossibilidadedeseestabelecerregrasoucondiesaserematendidaspara que os objetos permaneam coerentes. Isso permite, por exemplo, realizar anlises para verificar conflitos espaciais ou mesmo funcionais a partir do modelo: identificando reas internas e reas externas, seria possvel gerar uma regra que determinasse que todas as portas de entrada de um edifcio pblico deveriam abrir para fora, e no para dentro (EASTMAN, 1991; 1992; LEE et al., 2006). Tambm possvelestabelecerrelacionamentossemnticosqueatendamnecessidadesdefases especficas do desenvolvimento do edifcio, como organizar os elementos por custo, data prevista para construo ou equipe designada para a atividade, por exemplo, o queespecialmentetilparaafasedeplanejamentodaconstruo(EASTMANetal., 2004).

53

Dopontododesenvolvimentodeaplicaesparaacessardadosdemodelosde edifcios,aestruturaosemnticaacaractersticaprincipaldatecnologiaBIM.Sem ela, aplicaes com essa finalidade seriam no mximo semiautomatizadas, ou seja, exigiriamdousuriooperaesdecomplementaodainformaoapsacriaodas representaes, como informar ao sistema que tipos de elementos construtivos so representadosporcadagrupodeelementosgeomtricosemumarquivo.Otrabalho de Wang e Messner, por exemplo, aponta essa como uma das dificuldades para a utilizao de CADs 4D, que poderiam ser utilizados mais largamente para simular e controlar as fases da construo de edifcios, mas no so, em parte por exigem do usuriolongasoperaesdetransposiodeinformaes(WANeMESSNER,2007).

3.5Modelagem
Modelagemoprocessodeinserodosobjetosparamtricosemummodelo

doedifcio.Aplicaescomgrandecapacidadedemodelagemdeslidossoessenciais nesse processo, uma vez que grande parte da manipulao da informao na construoseddeformagrfica(EASTMAN,2004;LEEetal.,2006).Essasaplicaes demodelagem,centraisparaodesenvolvimentodosmodelos,tambmsochamadas BIM CADs ou BIMbased CAD (IBRAHIM et al., 2004). O nome BIM CAD pode soar redundante,considerandoqueopropsitoinicialdatecnologiaCADerafornecerum ambientedeprojeto,noapenasdeproduodedesenhos(COONS,1963).Contudo, a massiva adoo de softwares de desenho bidimensional baseados em primitivos grficosduranteasdcadasde1980e90gradualmenteincutiunacomunidadeleiga uma interpretao incorreta do termo, e logo CAD passou a designar mais um segmento de softwares do que a utilizao detodo o potencial do computador para auxiliar o processo de projeto. Nesse sentido, BIM um retorno ao CAD como fora imaginado por seus pioneiros nas instalaes do MIT na dcada de 1960. Porm, na atual fase de transio da representao por desenhos para a modelagem, o significado formado nas duas ltimas dcadas ainda provoca desentendimentos, motivo pelo qual a maioria dos autores citados neste trabalho preferiu qualificar o termoCAD,comoCADdemodelagem,BIMCAD,CADparamtrico,CADintegrado,etc.

54

3.5.1Automatizaodadocumentao A gerao automtica da documentao projetual a partir dos objetos do

modelo BIM a vantagem mais imediata da utilizao de um BIM CAD. Todos os principais sistemas comercialmente disponveis tem rotinas para gerao automtica devriasformasderelatriosapartirdomodelo,sejamelesgrficosoutextuais.Essa automao possibilitada por rotinas especializadas que processam parmetros dos objetosdomodeloeformatamoresultado.Desenhostcnicoscomoplantas,cortese elevaes so considerados um tipo de relatrio, descrito em forma grfica, e, por conseguinte, so gerados automaticamente (EASTMAN, 1976; 1991; SACKS et al., 2004). Como exemplos de relatrios textuais geralmente so citadas listas de elementos ou reas e quantitativos de materiais. Rotinas tambm podem ser programadas para realizar diferentes anlises a partir dos parmetros extrados dos objetos(SACKSeBARAK,2007). BIMCADsproduzemrepresentaesatravsdoinstanciamentodainformao do modelo, e no de cpia dessa informao. Todos os relatrios gerados automaticamente, incluindo plantas, cortes, elevaes e perspectivas, so arranjos temporriosdosobjetosdomodelo,paraproduzirumavisualizaoadequada.Assim que o usurio determinar que no precisa mais da visualizao, esses arranjos so desfeitos, sem prejuzo para a informao original. Essa abordagem traz uma grande vantagemparaamodelagemBIM:amanutenodaconsistnciadainformao.Uma vez que as diferentes visualizaes so instncias, modificaes em seus elementos so de fato modificaes no modelo do edifcio. Quando o sistema detecta que o modelofoimodificado,atualizaainformaodetodasasoutrasinstnciasqueesto ativas naquele momento (EASTMAN, 1991; IBRAHIM et al., 2003; EASTMAN et al., 2004).Porexemplo,quandoseaumentaovodeumaportaoujanelaumaelevao, osparmetrosdoobjetosomodificados,etodasasoutrasinstnciasqueestiverem ativas, sejam elas grficas ou textuais (como uma lista de esquadrias) passam a representaraportacomasnovasdimenses. importante ressaltar, porm, que dificilmente o projetista ser afastado completamentedoprocessodegeraodocumentaesesimulaes.Porisso,pode

55

se pensar nessa funcionalidade mais como automao parcial da documentao, liberando o usurio das funes mais repetitivas, mas ainda dependendo dele para soluo de situaes mais complexas. Kalay afirmou que a figura do projetista permanece insubstituvel, independentemente da evoluo das tecnologias de informao, pois ele exerce sobre o contedo da informao uma ordenao semntica que dificilmente poderia ser transformada em algoritmos (KALAY, 1985b). Augenbroe considera tambm a influncia preponderante da capacitao do prprio usurio na qualidade das informaes produzidas em simulaes dos edifcios, e a forte tendncia para distribuio das simulaes entre especialistas atravs da internet, em vez de inserilas simplificadamente nos sistemas utilizados na documentaodoprojeto(AUGENBROE,2002). 3.5.2Organizaodadocumentao Representaes instanciadas so arranjos temporrios, mas possvel definir para elas estruturas permanentes de organizao e relacionamento. Manusear e visualizar adequadamente as grandes quantidades de informao produzidas em projetosdeedifciospodetornarseumproblemamesmocomautilizaodemodelos ao invs de desenhos. No incio da tecnologia da modelagem, chegou a se imaginar que a distribuio da informao do projeto seria homognea pelos espaos que o constituam,comarepresentaodoprojetosendoformadaapenaspordesenhosem grande escala. Essa alternativa mostrouse invivel, porque a informao de um projeto no distribuda uniformemente. A sua densidade varia de acordo com a necessidade de representao dos sistemas que constituem diferentes partes do edifcio: juntas em estruturas de ao, por exemplo, contm uma considervel quantidade de conhecimento tcnico agregado: como executar a montagem, quais peas so necessrias, em que sequncia devem ser colocadas, que tolerncias so permitidas e qual o desempenho determinado pelas normas vigentes, e assim por diante. Por outro lado, a representao da extenso das vigas de ao possui muito menosconhecimentoagregado,jquesetrataapenasumaextrusocontnuadeuma seopadronizada.Eastmanponderouqueasoluoparaessavariaodedensidade de informao reproduzir no computador o esquema de desenhos em diferentes escalas utilizado no projeto em papel. Desenhos em grande escala representam
56

situaes onde h muita instruo a ser transmitida. Desenhos em pequena representam a distribuio geral dos elementos e servem de ndice para localizar os desenhos em grande escala (EASTMAN, 1980a). Nos BIM CADs, essa situao resolvidacomadefinioderelaesentreasdiferentesinstnciasderepresentao do modelo. Algumas relaes so fixas, determinadas pela interface dos sistemas, comoarepresentaodoedifcioporpavimentos.Tambmexistemferramentasque permitem ao usurio inserir uma indicao de relao a uma instncia de representao sobre outra instncia de representao, alm de possibilitar a configurao das suas propriedades (cdigo, escala, nome, etc). Essa operao cria arranjos permanentes que so registrados no modelo. Por exemplo, existem ferramentas para dispor e configurar cortes, que aparecem em planta como uma simbologia, de acordo com as convenes de desenho tcnico adotadas. O mesmo pode ser feito para inserir indicaes de detalhes nas plantas ou nos cortes. Dessa maneira, instncias de representao mais abrangentes, como a planta, servem de ndiceparaorganizarinstnciasmaisespecficas,comocortesedetalhes.Emgeral,as prprias simbologias da indicao das instncias mais especficas possuem funcionalidadesquepermitemaousurioacessla. OutroimportanteaspectonessesentidofoiapontadoporEastmannoincioda

dcada de 1990: um modelo de edifcio deveria ser idealmente composto por dois conjuntos:umgrupodeobjetosparamtricoseoutrodepranchasdedesenho.Como asvriasinstnciasderepresentaodosobjetossoarranjostemporrios,deveriaser fornecido ao usurio um modo de fixar grupos de representaes, compondo ento pranchas de desenho tcnico para visualizao ou impresso (EASTMAN, 1991). Os BIMCADsatuaisoferecemessafuncionalidade,registrandoemantendoasdiferentes configuraes definidas pelo usurio para pranchas (ou layouts). Pranchas podem conter vrias vistas do modelo, com parmetros de representao diferentes. Como soinstnciaspermanentementeativas,todasasmodificaesnomodeloatualizam nasautomaticamente.

57

3.5.3Consistnciadainformao Ograndeparadigmaasersubstitudonaadoodatecnologiademodelagem deedifciosoprojetocentradonacriaodedesenhospelocentradoemummodelo do edifcio (HIETANEN e DROGEMULLER, 2008). A vantagem da instanciao de representaes nessa substituio fica evidente quando se considera o seu aspecto mais importante: a garantia da consistncia da informao. No processo de projeto baseadoemdesenhos,essaconsistnciaobtidamanualmente,emtarefascomplexas e extremamente sujeitas a erros, caracterstica que foi observada j no incio da tecnologia de modelagem de edifcios (EASTMAN, 1980a). O manuseio de diferentes poresdeinformaodoprojetonoAutocadumexemplotpicodestasituao:no h mecanismos intuitivos para trabalhar com as vrias plantas que compem a representao de um edifcio de mltiplos andares. As diferentes plantas dos pavimentos podem ser separadas por arquivo, por layer, ou ento dispondo os elementosdecadaplantaemregiesdiferentesdomesmoarquivo,comosefossem representadasemumaenormefolhadedesenho.Aorepresentaroedifcioatravsde desenhos, CADs baseados em primitivos geomtricos foram o projetista a transpor manualmenteinformaesentreasdiferentesvistasisoladas.Essatransposiofeita apenas visualmente, comparando os diferentes desenhos, ou ento copiando um conjuntodeelementos(porvezesavistainteira)queservedebaseparaapropagao manualdamodificaoparaasdemaisvistas.Dadaanaturezaiterativadoprojetode edifcios,essastransposiesocorremvriasvezes,emambosossentidos,sempreque interfernciassopercebidasoumodificaessefazemnecessrias(AYRESeSCHEER, 2007). Vrias formas de complementar o contedo da informao e facilitar o seu manuseioeatransmissoforamdesenvolvidas.Adefiniodepadresparalayers um exemplo dessa tentativa de semantizar o contedo desestruturado dos CADs baseados em primitivos geomtricos (HOWARD e BJRK, 2007). No Brasil, a AsBEA, associaodosescritriosdearquitetura,propsapadronizaodanomenclaturados layers e da estrutura de pastas onde os arquivos de diferentes projetos complementares deveriam ser armazenados (CAMBIAGHI, 2000). Para outras situaes,sodesenvolvidasmetodologiaseconvenesprpriasemcadaescritrio,
58

natentativadecompensaraestruturadeinformaesdeficientedosCADsbaseados em primitivos geomtricos. Por mais que possam agilizar o processo e ampliar o contedo de informaes dos desenhos, essas adaptaes so seriamente limitadas pelo modelo de dados simplificado utilizado pelos CADs baseados em primitivos geomtricos. O registro da informao adicional frgil, e pode ser facilmente corrompido. Chastain e outros autores fazem interessante crtica sobre o uso de computadoresnafasedeprojetodeedifcios,afirmandoquecertasimplementaes dessa tecnologia no consideraram adequadamente o seu contexto, e no se ajustaramperfeitamentesdemandas,comoumblocoquadradosendoforadopor umburacoredondo.Emoutroscasos,implementaesdocomputadornaproduo de projetos incorreram no erro cuja analogia a carruagem sem cavalos (o nome peloqualosprimeirosautomveisforamvulgarmentechamados).Ouseja,opotencial da tecnologia no foi plenamente compreendido, e tanto a sua explicao como a implantaoforamrealizadasapartirdeumesquemaconceitualdesenvolvidoparaas tecnologias anteriores, que a nova tecnologia deveria substituir (CHASTAIN et al., 2002). Considerando o potencial de organizao de informaes oferecido pelo computador, produzir projetos em CADs usando exatamente a mesma metodologia que era utilizada com desenhos em papel realmente justifica o termo prancheta eletrnica,queemborasoefuturistadeveserinterpretadocomoumadesvantagem paraoprocessodeprojeto(AYRESeSCHEER,2007).Aoautomatizarcompletamentea manutenodaconsistnciadainformaodomodelo,aBIMaumentaodesempenho doprojetistaereduzapossibilidadedeerros,utilizandoopotencialdocomputadorde maneiramaisadequada(PENTTILA,2005). 3.5.4Generalizaoeextensibilidade Vrios trabalhos observam que sistemas CAD bem sucedidos permitem a

representao de inmeras situaes de projeto, como diferentes sistemas construtivosounveisdedetalhamento.Eastman,porexemplo,atribuiosucessodos CADs baseados em primitivos geomtricos a essa caracterstica de generalizao. No outroextremoestosistemasCADespecializadosemsistemasconstrutivosfechados,

59

paraosquaisainformaocompletasobreoselementosjestdisponvelnoinciodo processo de projeto. Estes sistemas, por mais eficientes que possam ser em seus domnios restritos, nunca se adaptaro condio de incerteza que normalmente envolveasconstruestpicas,queutilizamsistemasconstrutivosabertos(EASTMAN, 1976; 1989; 1992; 2004). Em sistemas de modelagem BIM, um conjunto de objetos atmicos (ou nativos) utilizado para representar os principais elementos construtivos de maneira genrica. Objetos representando paredes, por exemplo, podem ser descritos como prismas simples, sem maiores especificaes. Esta representao suficiente para descrever simplificadamente paredes de qualquer sistemaconstrutivo,porqueseconcentranacaractersticacomumatodasasparedes, quefuncionarcomoumpainelseparandoespaos. Mesmo adotando essa abordagem genrica, no possvel criar um sistema CAD que atenda a todas as situaes que podem surgir no desenvolvimento de projetos. Diferentes tipos de construes, realizadas por diferentes empresas sob os mais variados cdigos de construo devem ser modeladas (SACKS et al., 2004). Por isso,osBIMCADsoferecemapossibilidadedeextensoatravsdacriaodescripts ou aplicaes que complementam as suas funcionalidades. Eastman classificou essa qualidade como fundamental para para os sistemas de modelagem de edifcios (EASTMAN,1976; 1980b; 1989; 1992). Outra forma de extenso a possibilidade de desenvolvimento de novos objetos paramtricos pelo usurio, a partir de objetos paramtricosexistentes.Dessemodo,funesgenricaspodemservirdebaseparaa criao de ferramentas que atendam a necessidades de situaes ou sistemas construtivosespecficos(EASTMAN,1991).

3.6Metamodelagem
Aconstruodeedifciossemprefoiumaatividadeconjuntaquedependeuda

cooperaodevriosprofissionaiscomdiferentesconhecimentostcnicos.Mesmose consideradas as suas diferentes fases isoladamente, a necessidade de trabalho cooperado continua. Dificilmente se imagina o projeto arquitetnico sendo realizado individualmente, por exemplo (KVAN, 2000). As diferentes disciplinas envolvidas no desenvolvimento de edifcios produzem solues que so completas apenas se for

60

considerado o conjunto de tcnicas da disciplina isoladamente. Considerando a informaonecessriaparaarealizaodatotalidadedoprocesso,essassoluesso parciaiseprecisamserintegradas.Nomomentodaintegraopodemsurgirconflitos entre as solues das diferentes disciplinas, e gerenciar a resoluo destes conflitos tornase cada vez mais difcil, porque o conhecimento tcnico cada vez mais complexoeaomesmotemposegmentadoemdiferentesprofisses(KALAY,2005). At hoje, esse tipo de integrao de informaes de diferentes domnios no tem sido prtico, pois as ferramentas de projeto no fornecem funcionalidades adequadasparaavisualizaodegrandesquantidadesdeinformaoouentoexigem extensos processos manuais de reentrada de dados e verificao de conflitos (MAHDAVI, 2003). Idealmente, a informao agregada por diferentes disciplinas deveriafluirsemobstculosentreoprojeto,afabricao,aconstruo,amanuteno, e todas as outras atividades interrelacionadasque constituem o desenvolvimento de um edifcio, ficando disponvel a todos os envolvidos automaticamente. Este o principal objetivo da BIM, que permite que o edifcio seja construdo virtualmente, dentrodocomputador,antesdaconstruorealnocanteiro.Essaabordagemrene todososenvolvidosemumarranjovirtualdeprojetocooperativo,permitindoque o conhecimento agregado por cada profissional seja integrado em uma nica representao o modelo que disponvel a todos os outros profissionais participantes. Um nico modelo integrado do edifcio permite relacionar melhor as informaes e facilita a manuteno da consistncia e da integridade dos dados (EASTMAN, 2004). Desse modo, possvel verificar e solucionar antecipadamente os conflitosentredefiniesdediferentesdisciplinas,reduzindoaocorrnciadeerrose aumentandoaqualidadedoproduto. Desenhos,pormelhorelaboradoseconvencionadosquesejam,cobremapenas fases isoladas e instantneos do processo de desenvolvimento do edifcio (KALAY, 1985b; PENTTILA, 2005). Um modelo de edifcio, por outro lado, multidimensional por natureza, abrangendo toda a informao produzida e utilizada durante todas as atividades do ciclo de vida do edifcio, em um processo gradual de agregao de conhecimento (SACKS et al., 2004; TSE et al., 2005). Da fase de projetos, o modelo passa para todas as subsequentes, como o planejamento da construo e a sua
61

administrao,fabricaodecomponentes,comissionamento,operaodaedificao eassuasmanutenesperidicas(EASTMAN,1992).Aquestodedefinirseessefluxo de informaes seria melhor obtido pelo uso de um nico modelo integrado, ou de vriosmodelosinterconectadosmaisumadecisocontratualdoprojeto,enotem grandesimpactossobreoprincpiodaBIM.Sejaainformaoreunidafisicamenteem umnicolugaroudistribudadeacordocomasresponsabilidadesindividuais,aBIM baseadanapossibilidadedecoletlaeintegrlaautomaticamente(EASTMANetal., 2004). 3.6.1Interoperabilidade BIMumconceitoamploquenopodeserutilizadoparadescreverumtipode software.EsseseriaomesmoerrocometidoduranteadisseminaodoconceitoCAD, que ficou mais relacionado s aplicaes de desenho bidimensional do que ao processodeprojetoauxiliadopelocomputador.Tampoucopodesecontemplarasua totalidade pela utilizao de um nico software, porque no h aplicaes que abranjam todo o ciclo de vida de um edifcio. Sistemas dessa natureza seriam complexosergidosdemaisparaseremteisaoprocessodemodelagem.Aocontrrio, odesenvolvimentoparaaBIMdevecontinuarorientadoparaacriaodeaplicaes especficasparaasvriasdisciplinasenvolvidasnaconstruo(EASTMANetal.,2004). AcriaodemodelosBIMsedemumsistemacompostoporvriostiposde aplicaes,comdiferentesobjetivoseenfatizandodiferentesporesdainformao, colaborandoecompartilhandodados(IBRAHIMetal.,2004).Atrocadeinformaes entre essas vrias aplicaes deve ocorrer sem sobressaltos, garantindo que o significado no seja prejudicado. O termo que define esse requisito interoperabilidade, que pode ser entendida como um mapeamento das estruturas internas de dados das aplicaes envolvidas em relao a um modelo universal, independente de fabricantes (ou neutro). Com isso, novas aplicaes podem ser desenvolvidas partindo desse mapeamento, eliminando a prtica onerosa de criar vrias rotinas de transposio de informao para cada aplicao ou verso utilizada nodesenvolvimentodeedifcios(NIBS,2007).

62

ParaBrunnermeiereMartin,interoperabilidadeahabilidadedecomunicaros dadosdoprodutoatravsdediferentesatividadesdaproduo.Ainteroperabilidade essencial para a produtividade e a competitividade de muitas indstrias, porque projetos e processos de fabricao eficientes requerem a coordenao de muitos participantes e processos diferentes que dependem de representaes digitais do produto.Emseurelatriosobreainadequaodosprocessosdetrocadeinformaes entre as fases do desenvolvimento de automveis na indstria americana, eles estimaramqueocustodainteroperabilidadeinadequada,causadoporerros,atrasose retrabalhos, de no mnimo um bilho de dlares por ano (BRUNNERMEIER e MARTIN, 1999). Porm, a situao na indstria da construo ainda mais crtica. Gallaher e outros autores prepararam relatrio semelhante para a indstria da construoamericana,considerandoapenasasobrasdeinfraestrutura,eestimaram umcustode15.8bilhesdedlaresporano(GALLAHERetal.,2004). Existem ainda vrios desafios relacionados interoperabilidade a serem superados. Muitos deles so decorrentes das atuais prticas projetuais (contratao, responsabilidades, entregas) e responsabilidades legais. A modelagem de produto umarupturasignificativanosmtodostradicionaisdeprojetoevaiexigiraadoode muitas novas abordagens e procedimentos. A contratao de projetos, por exemplo, podepassarasebasearnonveldeaprimoramentodomodelo,enonaquantidade oudetalhamentodosdesenhos(EASTMAN,1991).Outrograndedesafiopreocupante aquestodaproteodainformaoinseridanomodelo,quepodeseracessadapor todos os outros participantes, o que dilui a noo de responsabilidade tcnica. A organizao em torno da BIM vai exigir formas seguras para controlar o uso da informao contida no modelo. Por exemplo, ferramentas precisaro ser desenvolvidas para atribuir nveis de acesso a indivduos, grupos ou arranjos temporrios interdisciplinares; para permitir que se trace a origem, as modificaes graduaiseasdiferentesversesresultantesdainformao;etambmparagerenciare garantir a origem da informao da documentao legal gerada a partir do modelo, como projetos para aprovao, listas de materiais para contratao de servios, ou mesmoquantitativosparalicitaes(NIBS,2007).

63

Outro grupo de desafios relacionado s capacidades atuais das ferramentas demodelagemedasestruturasdedadosdisponveis.Aindanoficousuficientemente claro, por exemplo, como ser garantido o acesso simultneo ao modelo. Apenas pequenasedificaespodemserprojetadasporumnicoindivduoemumperodode tempo praticvel. A modelagem de edifcios maiores exige o acesso simultneo de usurios a grandes pores de informao, para permitir a atualizao constante. Novasformasdecontrolesonecessriasparapermitirqueequipesformadasporum grandenmerodeprojetistastrabalhemeficientemente(EASTMANetal.,2004).Alm disso,propriedadesglobaisdoprojeto,comoobjetivosgerais,prazos,organizaodos participantes,devemserrepresentadasemumnvelacessvelatodososenvolvidose relacionaremse com informaes especficas para cada disciplina ou fase por exemplo,osobjetivosespecficosparaoprojetodasinstalaeshidrulicas(EASTMAN, 1992). 3.6.2IFCIndustryFoundationClasses A idia de integrar dados de diferentes aplicaes especializadas entre as

etapas do desenvolvimento de edifcios permeou toda a histria do uso do computadornaconstruocivil.Gingerich,em1973,comentaaexistnciadediversos programas de computador para auxiliar o desenho na arquitetura. Eles variavam de algoritmos de alocao de espaos a anlises estruturais e computao grfica. Geralmente, estes programas eram independentes, e mesmo que muitos deles utilizassem estruturas de dados similares para representar edifcios, suas partes e sistemas, eles raramente possuam formatos compatveis. Consequentemente, para executarumdeterminadoprograma,ousurioprecisavaredescreveroedifcioesuas partes. Como possvel soluo, o autor sugeriu que empresas, faculdades ou preferencialmenteentidadesdenormatizaoespecificassemumformatodebanco de dados para definio de edifcios, a ser utilizado por todos os programas. Isso economizaria o tempo e o trabalho gastos na transformao manual de dados entre aplicaes. Tal banco de dados deveria ser flexvel o suficiente para lidar com os processos de aquisio, apresentao e modificao, e tambm suficientemente inclusivoparaquefossepossveldefinirtodaequalquerpartedoedifcioatonvel necessrioparaafasedeconstruo(GINGERICH,1973).Naindstriadamanufatura,
64

aidiadepadronizarmodelosdedadosresultounaSTEP.Porminicialmentenenhum dos seus Application Protocols (APs) atendia aos requisitos especiais da indstria da construo. Em agosto de 1994, doze companhias americanas reunidas em torno da

Autodesk juntaram esforos para verificar a possibilidade de fazer diferentes aplicaes trabalharem de modo integrado, com base no ento recente Autocad verso 13. O grupo de trabalho foi chamado inicialmente Industry Alliance for Interoperability, e concluiu que a interoperabilidade poderia trazer benefcios econmicos significativos, desde que pudesse ser demonstrada na prtica. Meses depois, os primeiros resultados foram mostrados e despertaram grande interesse da indstria. Vrias empresas desenvolvedoras de software insistiram em participar da iniciativa,easinscriesparamembrosforamabertasem1995.Oprincipalobjetivo do grupo passou a ser o desenvolvimento de padres independentes de fabricantes parainteroperabilidadedossoftwaresutilizadosnaindstriadaconstruo,utilizando alinguagemdedefiniodedadosEXPRESS,quehaviasidolanadanoanoanterior, nanormaSTEP.Em1997,aorganizaofoireconfiguradaemumaentidadesemfins lucrativos,comoobjetivoprincipaldedesenvolverummodelodedadosneutropara representarociclodevidadosedifcios,eoseunomefoitrocadoparaInternational Alliance for Interoperability, a IAI (EASTMAN, 1999; BSI, 2008). O modelo de dados neutrodaIAIchamadoIndustryFoundationClasses,ouIFC.Asuaprimeiraversofoi lanadaem1997,eaversoatuala2X3,sendoquea2X4alphajestdisponvel paratestesnapginadaIAInainternet(BSI,2008).AsIFCsoatualmenteoprograma de padronizao de modelos de edifcios mais ambicioso da indstria (HOWARD e BJRK,2008). OdesenvolvimentodasIFCabordaamassivaquantidadededadosquepodem

serinseridasemummodelodeedifcioemquatroeixosdeinformao:ciclodevida, disciplina, nvel de detalhe e aplicaes (softwares). A proposta no criar uma representao especfica para cada elemento encontrado na construo, j que isso daria origem a um modelo muito grande e pouco implementvel. Ao invs disso, os elementos so representados por classes genricas, com informao suficiente para descreverassuascaractersticasprincipais.Tambmexisteapossibilidadedeestender
65

umadescrioparaquearepresentaoseadaptemelhoraumprodutoespecfico.A arquitetura do modelo de dados IFC composta por quatro nveis: domain, interoperability,coreeresource.Onveldomainomaisalto,epermiteadescriode informaesespecficasparacadadisciplinaenvolvidanodesenvolvimentodoedifcio. Nonvelinteroperabilitysodescritosmapeamentosdedadosparapermitiratrocade informao entre diferentes domains. No nvel core so descritas as unidades de informao comuns a todos os domnios e mapeamentos, que podem ser especializadas por eles. O nvel mais baixo o resource, que contm a descrio de conceitos bsicos e independentes, que so utilizados pelos nveis mais altos. A primeira verso das IFC tinha cinco tipos de resource: geometry, property, property type,measureeutility.Naverso2Xessasunidadesforamsubdivididaseoutrasforam acrescentadas,resultandoem20tiposderecursos(LIEBICHeWIX,2000). ComodesenvolvidoemEXPRESS,asintaxedomodelodedados(ouesquema) IFC utiliza os constructos mostrados na subseo 2.3.4. As unidades bsicas de informaosoentidades,quepodemrepresentarobjetos,propriedadesdosobjetos, ou relaes entre objetos (ifcObject, ifcPropertyDefinition, ifcRelationship). Objetos podem descrever elementos fsicos, como paredes, espaos, equipamentos, mas tambmabstratoscomotarefas,controles,processos,etc.Elessoderivadosemsete tipos principais: produtos, processos, controles, recursos, atores, projetos e grupos (LIEBICHeWIX,2000).Asextensesdasentidadesbsicasdomodelosocriadascom a propriedade EXPRESS SUBTYPE OF, e em teoria, desde que enquadremse na arquiteturadaIFC,podemserinterpretadasinequivocamenteemqualqueraplicao que consiga ler o modelo. O esquema IFC completo pode ser obtido no site da IAI (LIEBICHetal.,2006). Para que um fluxo contnuo de informaes realmente possa ocorrer, trs

fatores devem ser atendidos: o formato no qual a informao trocada, um entendimento comum a respeito do significado da informao sendo trocada, e a definiodequalinformaotrocarequandorealizaratroca.NavisodaIAIsobrea interoperabilidade, estes trs requisitos so contemplados pelo modelo IFC, que responsvelpeloarmazenamentodigital,peloIDM(InformationDeliveryManual),que d suporte aos processos do desenvolvimento de construes, e pelo IFD
66

(International Framework for Dictionaries), que define a terminologia dos elementos doprojeto.ParaexpandirautilizaodomodeloIFCemelhoraracomunicaoentre as etapas da construo, o desenvolvimento de softwares deve atender aos trs requisitos(KIVINIEMIetal.,2008). IFD IFD determina a terminologia dos elementos do projeto de construes e a

relacionacomasentidadesIFC.Almdonomepeloqualoselementosquecompem os edifcios so chamados variar entre diferentes regies, as partes que compem cadaelementotambmvariam.Umexemplodissosoasportas:podeseconsiderar queoelementoportasejaumaunidadecompleta,comfolha,caixilhoseferragens.Ou entoapenasafolhaeosbatentes,ouentoocaixilhopodeserumquadrocompleto, dispensandoainstalaodasoleira,ousomenteumarco,eassimpordiante.Comoas IFCsoflexveiseextensveis,esteelementopodeserdescritodevriasmaneiras.Um entendimento comum sobre os elementos descritos nos modelos IFC era necessrio, ounomnimoumesquemaquepermitissemapearasdiferenasentreasdescries regionais dos elementos. Esta a proposta do International Framework for Dictionaries, ou IFD, que pretende estabelecer dicionrios ou ontologias para definir semanticamente a natureza dos objetos que descrevem elementos construtivos (IAI, 2008b). IDM IDMs especificam qual informao deve ser trocada em cada cenrio possvel

duranteasatividadesdodesenvolvimentodoedifcio,erelacionaessadefiniocom as entidades IFC. Por exemplo, qual o conjunto necessrio de informaes a ser transmitidodoprojetoarquitetnicoparaoprojetodeinstalaeseltricasparaqueo trabalho possa ser realizado. As definies dos IDMs so implementadas atravs de esquemasMVD(ModelViewDefinition),descritosnaformadetextoASCII,deformaa seremlidostantoporcomputadorescomousurios.AdefinioIDMemconjuntocom oesquemaresultante,MVD,realizasobreomodeloIFCumaespciedeordenamento e seleo das entidades, provendo s diferentes disciplinas envolvidas na construo umavisoprpriasobreosdados(IAI,2008b).

67

DesafiosparaomodeloIFC DezanosapsoinciododesenvolvimentodasIFC,oseuusoaindaselimitava a projetos piloto e testes de conformidade. Kiviniemi fez importante relato sobre a situao da tecnologia e da IAI poca. O autor comenta inicialmente a falta de recursos, e o reduzido nmero de poucas pessoas realmente envolvidas com o desenvolvimentodasIFC.Noaspectodainteroperabilidade,oprocessodecertificao desoftwares,aindamuitosimplificado,nogaranteaqualidadedosmapeamentosde dados durante a importao ou exportao entre diferentes aplicaes. A falta de documentaoedemecanismosmaiseficientesparaatualizaodasinformaespara osinteressadostambmmencionada.ParaKiviniemi,aquestotcnicadadefinio do esquema avanou consideravelmente, j existem softwares robustos para a modelagemdeedifcios,enohmaisrazesparaadiarasuaadoo,mesmoquea interoperabilidade seja limitada no incio. A questo da adoo pelo mercado j provou ter soluo a partir de iniciativas de grandes clientes ou entidades governamentais,easdemandasatualmentesodedesenvolvimentodeferramentase conscientizaodosenvolvidos(KIVINIEMI,2006). Trocasdedadossemperdadesignificadoentrediversasaplicaesaindano

so praticveis, em parte porque os processos de mapeamento de dados entre os modelos internos dos BIM CADs e o modelo IFC ainda so imprecisos. Pazlar e Turk realizaram uma sequncia de testes de exportao e importao de modelos de edifcios para o formato IFC utilizando trs das aplicaes mais conhecidas: Architectural Desktop 2005, Allplan Architecture 2005 e ArchiCAD 9. Os testes permitiram observar srias inconsistncias na representao dos elementos geomtricosapsoprocessodeexportao/importao,principalmentecommodelos mais complexos. Os autores concluem que o ideal da interoperabilidade, embora difundido a mais de dez anos, ainda est bastante distante da aplicao na prtica (PAZLAReTURK,2008). Almdisso,comoexpostonasubseo3.3,importanteparaaconstruoque

se represente o edifcio como um conjunto de objetos tridimensionais, porm as representaesbidimensionais,essencialmentesimblicas,continuamindispensveis.

68

O ideal seria obter essa representao automaticamente, valendose do comportamento dos objetos (ver subseo 3.3.2). Porm a verso atual do esquema IFC no suporta essa viso, e quando o modelo do BIM CAD exportado, toda a informao sobre a representao simblica perdida. O que passa a constituir o arquivo IFC um modelo de slidos geomtricos melhorado, com relaes hierrquicasedescritoresnogeomtricos,pormsemocomportamentodecontexto que representa grande parte da sua utilidade para o projeto. Kim e Seo alertam inclusiveparaofatodesercomumusuriosinseriremelementosbidimensionaissobre oselementostridimensionaisnosBIMCADs,paraquearepresentaoemplantaseja mantida durante a exportao para o formato IFC. Em recente trabalho eles apresentamoandamentodoprojetoXM4,lideradopelocaptulocoreanodaIAI,que pretende estender o modelo para comportar essa capacidade de extrao de documentaoautomaticamente.Almdatopologiaedageometria,sernecessrio incluircomoatributosdasentidades:definiodelayers,delinhas(espessura,tipode trao),anotaes,representaessimblicas,hachurasepadresdepreenchimentoe curvasdeBezier.OutroprojetodeextensodomodeloIFCoXM9,queseconcentra emincluirnomodeloavisodepranchas,vistas,cotasassociativasecapacidadespara representaesmaiscomplexas(KIMeSEO,2008). ArandaMena e Wakefield afirmam que muito do insucesso da disseminao

dasIFCestrelacionadocomelasteremsidoformuladassobreconceitosquejno so universalmente aceitos como as melhores solues para os problemas originais. Umexemploaquestodainformaocentralizada:paraosautores,aspesquisasj apontamparaumasituaodevriosmodelosautoorganizveis,conectadosentresi. Outro exemplo a limitao da EXPRESS com relao representao de relacionamentos semnticos: as ontologias so um campo emergente que permitem descrever a informao em um nvel semntico muito maior. Apesar disso, as IFC obtiveramrelativosucesso,eosfuturosdesenvolvimentosdeformatosdedadospara interoperabilidade na indstria da construo provavelmente no desconsideraro isso.Aocontrrio,elesdeverosercriadosapartirdasIFC,adaptandoasidiasiniciais snovaspossibilidadesdastecnologiasdeinformao(ARANDAMENAeWAKEFIELD, 2006).

69

3.7PerspectivasparaaBIM
As potencialidades e as possveis causas para sua pequena adoo na prtica so temas dos estudos sobre modelagem de produto na indstria da construo h maisdetrintaanos.Aresistnciasmudanaseascondiesespeciaisdaindstriada construoforamconstantesbarreirasaumaadoomaisgeneralizadadatecnologia, adespeitodassuasvantagens,quevemsendoanunciadasdesdeofinaldadcadade 1970. Muito dos temas pesquisados atualmente ainda poderiam ser explicados por artigosdedcadasatrs. Eastman, por exemplo, afirmou que a relutncia da indstria em adotar a modelagemdeprodutotevecomocausasafaltadepesquisademodelossemnticose abertos, que melhor representassem o edifcio e os seus processos de construo e permitissem a troca de dados entre as aplicaes; a falta de ferramentas de modelagemmaisintuitivasqueseaproximassemdomododetrabalhodosprojetistas; os benefcios potenciais limitados causados pela fragmentao da indstria; e as disputas de responsabilidades legais entre as diferentes disciplinas envolvidas nos projetos (EASTMAN, 1989). Uma pesquisa realizada em 2005 junto a empresas de construodeHongKongarespeitodasprincipaisferramentasdeprojetorevelouque entre788projetistasentrevistados,93%afirmaramutilizaroAutocad,85%afirmaram utilizar o 3DStudio Max ou o 3DStudio VIZ e 29% o MicroStation (TSE et al., 2005). Quase um tero dos respondentes j havia testado e adotado a modelagem de produto,masoprocessodeconstruodagrandemaioriadosedifciosemumgrande centro urbano como Hong Kong provavelmente depende da frgil operao de reconstruo da informao a partir de uma grande quantidade de desenhos bidimensionaisisolados.Almdisso,doissoftwaresdemodelagemgrficaeanimao que no oferecem funcionalidades coerentes com as operaes realizadas em um projetodeedificaosointensamenteaplicados. Tambm recorrente a questo da adaptao das ferramentas BIM s fases menos modelveis do processo de projeto, como a concepo arquitetnica ou de estruturas.Nessescasos,apossibilidadedemodelaroedifcioeanalislonogarante necessariamente dar suporte ao desenvolvimento de projetos, que comea com

70

esboos, passa por desenhos esquemticos e termina com a produo da documentao. Fases iniciais do processo de projeto no consistem em posicionar vigas, canos e outras peas de catlogo. Consistem em definir e compor abstraes variadas,quepodemserespaos,estaesdetrabalho,massasdoedifcio,superfcies visuais,entreoutras.Adependnciaporabstraesnasfasesiniciaisdoprojetouma prerrogativadoprojetistanodesenhomanual,etambmdeveriamserdodesenhista no computador. Os primeiros sistemas CAD que pretendiam oferecersuporte a mais de um tipo de atividade de projeto, porm, normalmente fixavam a sequncia de operaes do projetista. A razo para isso que esquemas de verificao da integridade do projeto s funcionavam se a informao fosse inserida em uma determinada ordem. Sistemas CAD deveriam suportar um vasto repertrio de abstraesevriaspossibilidadesdesequenciamentododesenvolvimentodoprojeto. O projetista ento poderia escolher o modo de trabalho que lhe parecesse mais adequado. Poucas pessoas que seriamente consideramse "projetistas" deveriam aceitar uma organizao do projeto (manual ou no computador) que prespecifica rigidamenteasabstraesaseremusadaseasuasequnciadeaplicao(EASTMANe HENRION, 1979; EASTMAN, 1980a). Atualmente, essa continua sendo uma situao mal resolvida. Turk, por exemplo, afirma que a tentativa de criar modelos de concepo, que definem a natureza dos objetos e relaes que representam um edifcio carece de estudos mais aprofundados, e tem comumente sido abordada a partirdaquestotcnicaapenas.Asimplesproposiodegerarprojetosdeedifciosa partirdemodelospareceparaelecontraditria,poisaconcepodeidiasorientada pormodelos,sejamrgidosouno,podeimpediroprojetistadevislumbrarsolues originais que no sejam previstas pela estrutura do modelo (TURK, 2001). Ibrahim e outros autores fazem afirmao semelhante referindose s capacidades oferecidas pelosobjetosparamtricos(IBRAHIMetal.,2003). Com relao integrao dos processos de projeto e simulao, Augenbroe afirma que a disponibilidade de ferramentas por si s no significa que a atividade exercer influncia sobre a evoluo do projeto de edifcios. Para isso, preciso garantir que a simulao seja realizada na hora certa, e pelos motivos certos. Isso requertantoumagarantiadequalidadedasimulaoquantoumacoordenaomais

71

adequada do processo de projeto. Alm disso, modelos de dados para a integrao fcil dessas ferramentas com os sistemas CAD so uma promessa h dcadas, e houvepoucosresultadosprticos(AUGENBROE,2002). Chastain e outros autores afirmam que a subestimao dos potenciais das novas tecnologias de informao sobre o modo de conduzir as atividades da construo resulta na subutilizao do seu potencial revolucionrio e em aplicaes inadequadasaosseuscontextos.Paraeles,tecnologiascomoamodelagemdeproduto s podem ser plenamente realizadas com a reorganizao de grande parte dos processos, que ainda so orientados por um paradigma originado em um contexto anterior informtica (CHASTAIN et al., 2002). Para Kalay, preciso transformar a atual estrutura hierrquica e sequencial do processo de projetos para uma estrutura de atividades paralelas e mais efetivamente relacionadas (o que chamou de interleavedprocess).Ainformao,nessenovoprocesso,seriaumrecursoplenamente acessvelatodososparticipantes,instantaneamente(KALAY,2005). Mahdavi sugere quatro abordagens para compreender a atual utilizao dos modelos de edifcios e as novas possibilidades e desafios para a nova gerao de aplicaes. A primeira abordagem tem recebido mais ateno da comunidade cientfica: a integrao da representao, com a utilizao de repositrios nicos ou interconectadosparareunireorganizartodaainformaosobreoedifcio.Modelos, porm,podemoferecerfuncionalidadesmuitomaissofisticadas,comoainversodo modo tradicional de inferncia sobre os elementos. Habitualmente, pensase no processo de modelagem como definio de objetos paramtricos dos quais posteriormente se extraem dados para anlises diversas. Os resultados das anlises so utilizados ento para redefinir estes objetos. Mahdavi prope como segunda abordagem o projeto orientado pelo desempenho, pelo qual a definio prvia de requisitosorientaautomaticamenteainserodosobjetosparamtricosconfigurados para atender ao desempenho desejado para a edificao. Uma terceira abordagem levaria a modelagem um passo adiante: a considerao do desempenho no de um campo de simulao, mas sim de todos os que o projetista considerar necessrios. Sistemas de modelagem com essa funcionalidade teriam que combinar as diferentes definies para o desempenho da edificao provenientes das suas respectivas
72

simulaeseidentificaromelhorconjuntodeatributosparaosobjetosparamtricos. Por fim, Mahdavi prope uma quarta abordagem, que a extenso do modelo resultantedassimulaesdedesempenhoparaasfasesdeoperaoemanutenodo edifcio(MAHDAVI,2003). Apesar da necessidade de aumentar a quantidade e a profundidade dos estudos sobre a modelagem, a aceitao das suas vantagens para a indstria da construocrescepaulatinamente.OinstitutodepesquisasVTT,daFinlndia,publicou recentemente a verso atualizada do Finnish ICT Barometer, uma pesquisa realizada atravs de emails para empresas do setor naquele pas. Foram contabilizadas 86 respostas vlidas, incluindo todas as especialidades, de arquitetos e engenheiros a proprietrios.93%dasempresasafirmaramutilizarBIMemseusprojetos.Porm,75% dos projetistas afirmaram que a maior parte das documentaes criada em CADs bidimensionais, e 81% dos profissionais no utilizam o modelo BIM compartilhado. Alm disso, a maioria dos projetistas utiliza apenas o aspecto geomtrico da modelagem, sem que a informao flua para os processos de planejamento, contratao ou mesmo marketing. A despeito do aparente uso ainda incipiente, a maioriadosrespondentesafirmouqueatendnciadamodelagemdeveseintensificar, eapontaramamelhoriadacompetitividadeedaqualidadedotrabalhocomoprincipal motivoparainvestirnasferramentasdetecnologiadeinformao(VTT,2007). Em recente evento que reuniu participantes de vrios setores da indstria da

construo, Martin Fischer apontou como resultados comuns a vrios projetos que utilizaram BIM o aumento da produtividade no canteiro de 20 a 30%, a reduo das solicitaesde situaoe pedidos de modificao em dezvezes ou mais, o aumento expressivodoengajamentodosstakeholderseaconsideraodemuitomaisopes deprojetosapartirdemaisperspectivassemaumentodecustosetempodeprojeto. Entretanto, a BIM tem sido utilizada, na maioria dos casos, em fases isoladas do processodeconstruo,eoseumaiordesafioatualmenteaintegraodessasfases. Cada setor da construo representado no evento colaborou com uma perspectiva diferentesobreaBIMeasdemaisbarreirasaseremsuperadas.Aconclusogeralfoi que uma maior adoo da BIM esbarra em dois problemas: a mentalidade individualista dos envolvidos, que tradicionalmente no consideram o benefcio da
73

colaboraoduranteosprojetos,eafaltadeferramentasquetransfiramdadosentre asfasesdodesenvolvimento(HARTMANNeFISCHER,2008). Howard e Bjrk afirmam que pesquisas quantitativas como estas tem demonstrado repetidamente o pouco conhecimento dos respondentes a respeito da modelagemedepadresparaosmodelos.Paraidentificarasbarreiraseperspectivas para a tecnologia, os autores conduziram uma pesquisa qualitativa, junto a especialistas do mercado e da academia. Ao final de 2006, 18 especialistas de sete diferentes nacionalidades haviam respondido os questionrios, entre arquitetos, engenheiros,empreiteiroseespecialistasdeTI.Comrelaopossibilidadedecriao demodelosabrangendotodoociclodevidadoedifcio,amaioriadosrespondentes relatou a falta de padres e definies para os formatos de dados. Padres para os modelos BIM ainda so mal divulgados e incompletos. As ferramentas precisam se adaptar melhor aos processos da indstria e alguns destes, por outro lado, precisam serrevistosemfacesnovaspossibilidadestecnolgicas.Aquestodaeducaodos profissionais,equaisconhecimentosseronecessriosparaatuarcomamodelagem de edifcios deve tornarse cada vez mais preponderante, segundo os especialistas. Apesar das observaes, todos concordaram nos benefcios da tecnologia, sendo o cliente apontado como principal beneficirio na maioria das respostas (HOWARD e BJRK,2008).

74

4
AcessoaoModeloIntegradodoEdifcio

objetivodeacessarosmodelosdeedifcioscriaraplicaesparaprocessaros seusdados,queforampreviamenteestruturadosemumaaplicaoBIMCAD,e

gerar novas informaes a partir deles. Coons, ainda em 1963, observou que grande parte da utilidade dos sistemas CAD residia na sua abrangncia sobre todos os processos de produo, da concepo ao produto acabado. Porm, prever todas as situaespossveisemumprojetoeprogramarrespostasparaelas,mesmoquefosse possvel,resultariaemumsistemaCADcomplexoergidodemaisparasertil.Como alternativa,CoonspropsqueossistemasCADfossemcompostosporumaaplicao responsvelpelasrotinasgenricasnecessriasparaarepresentaobsica,associada a outras que realizariam tarefas mais especializadas (COONS, 1963). Da mesma maneira, Eastman, descrevendo os primeiros sistemas de modelagem, afirma que a melhorabordagemparagarantirasuaflexibilidadeeadaptaoadiferentessistemas construtivos permitir a complementao posterior da aplicao principal por sub rotinas programadas na mesma linguagem (EASTMAN, 1976). Esta abordagem continua sendo defendida, como demonstram o trabalho de Magdy Ibrahim et al. (IBRAHIMetal.,2004)eodeUmitIsikdag(ISIKDAGetal.,2007). Modelosdeedifciossoconstrudossobremodelosdedados,quedefinemas estruturas lgicas onde as informaes so armazenadas. Modelos de dados podem ter formatos proprietrios ou neutros. Formatos proprietrios so desenvolvidos e mantidosporfabricantesdesoftware,eoseuobjetivoprincipalgarantiraeficincia no acesso aos dados pelo aplicativo a que se destinam. Exemplos de formatos proprietrios so o DWG ou o 3DS, que so formatos internos do Autocad e do 3D StudioMax,respectivamente(AUTODESK,2008);ouoPLN,oformatoproprietriodo ArchiCAD, do grupo Nemetschek/Graphisoft (GRAPHISOFT, 2008e). H tambm formatos proprietrios criados com o propsito especfico de exportar informaes

75

entre diferentes aplicaes de um fabricante, ou entre as suas aplicaes e outras criadas para trabalhar em conjunto com elas. Um caso tpico o DXF (Drawing Exchange Format), criado pela Autodesk para promover conexes entre diferentes aplicaes com o Autocad. DXF um modelo simples e de fcil implementao, provveis motivos da sua ampla aceitao e aplicao, em praticamente todos os segmentosindustriais(FOWLER,1996). Formatos neutros so resultado do desenvolvimento em uma PDT, como descritonasubseo2.3,eseuobjetivoprincipalmanteraeficinciadatransmisso deinformaesentrediferentesaplicaes,independentedofabricante.Idealmente, considerando a natureza multidisciplinar do desenvolvimento de produto e o consequenteusodeaplicaesdevriostipos,novasaplicaesdeveriamincorporaro formato neutro por princpio. Do ponto de vista do desenvolvimento de aplicativos, essaabordagemnomnimoexcluiarduatarefadedefiniodeumformatodedados eficienteeflexvel,enomximopoderiaeliminarosprocessosdetraduodedados entrediferentesformatos,quesosemprepropensosaerroseperdasdesignificado da informao. Gielingh, porm, identifica vrios desafios que ainda limitam a disseminao dos modelos neutros, entre eles a prpria definio do que seria um modelo neutro, j que mesmo diferentes Application Protocols da STEP no so interoperveis(GIELINGH,2008).Issosugerequeaadooplenadosmodelosneutros na indstria da construo, caso venha a ocorrer, ser precedida por uma fase de transio na qual os modelos proprietrios permanecero exercendo forte influncia na modelagem de edificaes. Por esse motivo, neste trabalho foram estudados mtodos de acesso aos dois tipos de formato: o formato proprietrio PLN, do ArchiCAD (GRAPHISOFT, 2008e), e o formato neutro IFC, desenvolvido pela InternationalAllianceforInteroperability(BSI,2008). Existemvriasformasdeacessarmodelosdedados,eidentificarasprincipais para os modelos utilizados foi a primeira etapa da preparao para os experimentos neste trabalho. Um esquema organizando os mtodos de acesso identificados foi elaboradoeapresentadonafigura4.01.

76

GDL SCRIPT

GRAPHISOFTAPI PLUGIN FORMATOPROPRIETRIO FORMATOABERTO IFC ifcXML PARSING DOM/SAX BINDING LATE EARLY XMLBEANS APLICATIVO

SERVIDORBD

ARQUIVOSPF

EXPRESSTOOLBOX TNOIFCDLL JSDAIEXPRESSAPI

Fig.4.01:esquemadosmtodosdeacessoaomodelointegradodoedifcio utilizadonestetrabalho.

A informao armazenada em modelos de formato neutro e de formato proprietrio pode ser intercambiada por processos de mapeamento de dados. Neste trabalhofoiutilizadaarotinadeexportaodoArchiCAD,quepossibilitagravareabrir modelos de edifcios em formato IFC. Os trs mtodos para acesso ao modelo proprietrioforamidentificadoscomoscript,plugineaplicativoindependente.Scripts soalgoritmoscriadosparaautomatizarsequnciasdecomandosdeumaaplicaoou gerar novas informaes a partir dos dados inseridos pelo usurio. Para avaliar esse mtodo, duas aplicaes foram desenvolvidas: objetos paramtricos representando paredes de blocos de concreto, e o EEQuant, uma rotina que quantifica energia e dixido de carbono embutidos nos materiais de construo, a partir da associao entre os elementos que constituem o modelo do edifcio e um banco de dados com ndices de consumo. Plugins so pequenas aplicaes criadas para complementar a funcionalidade ou a interface de uma aplicao BIM CAD. Eles funcionam exclusivamente em conjunto com a aplicao principal, da qual compartilham a interface e os procedimentos para manipulao de dados, atravs de bibliotecas de funeschamadasAPIs(ApplicationProgrammingInterface).Asuagrandevantagem em relao aos scripts um escopo de atuao maior, que oferece ao programador maisliberdadeparainterferirnaaplicaoprincipal.Paraavaliaromtododeacesso ao modelo por plugin foi criada uma aplicao para exportar elementos nativos do
77

ArchiCAD para um sistema de anlises fsicas, chamado Mestre. Finalmente, Aplicativospossuemasuaprpriainterfaceepodemserexecutadosemseparadoda aplicao principal. Eles utilizam as APIs apenas para extrair as funes de acesso e manipulao dos dados de um modelo proprietrio da aplicao em questo. Neste trabalhonofoirealizadoexperimentocomestaformadeacesso,emboradoponto de vista da manipulao de dados e gerao de informaes, aplicativos independentes e plugins ofeream as mesmas possibilidades, j que se utilizam do mesmomtododeacesso,aconexoviaAPI. Modelos de edifcios no formato de dados neutro estudado, IFC, podem se apresentarnaformadebancosdedadosgerenciadosporumservidordemodelos ounaformadearquivosASCII(AmericanStandardCodeforInformationInterchange), um padro de troca de informaes por caracteres sem formatao. Neste trabalho noforamavaliadosmtodosdeacessoviaservidordemodelos,porumaquestode falta de tempo hbil. Apesar disso, os dados obtidos a partir do modelo, seja ele apresentado como um banco de dados ou um arquivo ASCII so essencialmente os mesmos.Quandoapresentadosemarquivos,osmodelosIFCpodemterdoisformatos (emboraapenasumaestruturademetadados):podemserdescritosnoformatoSPF (STEPPhysicalFile),ouentonoformatoifcXML,quedescreveamesmainformao dosarquivosSPF,pormatravsdaestruturadensdefinidapelalinguagemdemeta dadosXML(W3C,2008b).ParaavaliaroacessoamodelosdeedifciosemformatoIFC SPFforamutilizadasbibliotecasAPIchamadasEXPRESSToolbox.Oacessoamodelos em formato ifcXML foi feito atravs de ferramentas de parsing (varredura dos ns XML) e data binding (mapeamento e associao das estruturas de dados para uma estruturadeclasses). Paraidentificarasvantagensedesvantagensdosmtodosdeacessomostrados nafigura4.01,foramrealizadosdiferentesexperimentos.Paraviabilizaraexecuode experimentos com o maior nmero possvel de mtodos de acesso identificados, foramdesenvolvidasaplicaesmuitosimples,apenasparailustrarmaisfacilmenteas capacidadesdecadamtodo.Estasaplicaesnoseguiramumametodologiaformal dedesenvolvimentodesoftwaresnohouvemodelagemdeprocessos,porexemplo.

78

O desenvolvimento das aplicaes e os resultados dos experimentos de acesso aos dadosdemodelosdeedifciossodescritosnosprximositens.

4.1Script:objetosparamtricosrepresentandoparedesdeblocos
Neste experimento foram estudadas as possibilidades oferecidas pelo acesso aosdadosdomodelodoedifcioatravsdescriptsparadeterminarocomportamento de objetos paramtricos que representassem paredes de blocos de concreto e automatizassemageraodedocumentaestcnicas. 4.1.1Definiodoproblema Opotencialderacionalizaodaconstruooferecidopelousodaalvenariade blocos de concreto depende de uma representao detalhada, de carter executivo, queincluaaposioeotipodecadaumdosblocosutilizadosnasdiferentesparedes da construo. Uma completa explanao sobre o mtodo construtivo e suas especificidades pode ser encontrada em Wissenbach (1990), Pfeifer et al. (2001), PrudncioJr.etal.(2002),RamalhoeCorra(2003)eemBeall(2003).NoBrasil,este requisitopodeserconsideradoumobstculoparaadisseminaomaisefetivadesse sistema construtivo, j que a documentao projetual no pas, tipicamente, traz poucosdetalhestcnicos(FABRICIOetal.,1999).Quandosoutilizadosdesenhosno projeto de construes de alvenaria de blocos de concreto, a tarefa de produo da documentao detalhada demanda tempo e propensa a erros. Muitas vezes o detalhamento do projeto sequer realizado, ou ento ocorrem modificaes na versojdetalhadaquedemandariammuitotrabalhoparaatualizaodosdesenhos, queficamentodesatualizados(SCHEERetal.,2007). A modelagem do edifcio em um BIM CAD pode, em princpio, resolver parte destasituao,tantopelamelhororganizaodainformaoquantopelaautomao parcialdadocumentaodoprojeto.Entretanto,essesCADsnoseadquambema algunsaspectostcnicoseregionaisdosistemaconstrutivoemquesto.OArchiCAD, por exemplo, possui elementos nativos para representar paredes, mas apenas genericamente, com os elementos constituintes das paredes sendo representados simbolicamente, com hachuras. Para ilustrar os inconvenientes dessa representao

79

genricaparaosistemaconstrutivodaalvenariadeblocosdeconcreto,consideresea representaodeduasparedesdeblocosconstrudascomfiadasdeprumomostradas emplantaeperspectivanafigura4.02.

Fig.4.02:representaoemplantaeperspectivadeduasparedesdeblocosdeconcreto.

Os objetos nativos wall do ArchiCAD so objetos paramtricos que produzem

representaes automticas em planta e perspectiva, com base no ajuste de parmetros.Nafigura4.03amostradaarepresentaoemplantaobtidaapartirda definio do material concrete block para as duas paredes. A definio do material possibilitacalcularautomaticamenteaquantidadeaserutilizadanasduasparedes,a partir da avaliao dos seus parmetros e do ndice de consumo de blocos, por exemplo. A hachura em planta representa, simbolicamente, uma parede constituda de blocos de concreto. Por padro, o ArchiCAD utiliza a conveno alem DIN, mas tambmpossvelcriarhachurasqueatendamasnormaslocais.Afigura4.03bmostra quearepresentaoemplantapodeseraprimoradaparaincluirasduascamadasde reboco de 1 cm cada. O ArchiCAD identifica e corrige automaticamente o encontro entreosdoisobjetoswall,mantendoacoernciadarepresentaodascamadasque compemasparedes.

80

Fig.4.03:RepresentaesdasparedesdeblocosdeconcretousandoelementosnativosdoArchiCAD

Almdeajustararepresentaoemplanta,tambmfoiprecisoselecionaruma hachura para simular as faces dos blocos de concreto nas vistas dos objetos wall. O resultado, mostrado na figura 4.03c, foi uma representao incorreta das faces dos blocos de concreto. Como a hachura meramente simblica, o sistema no julga necessrio alinhar a origem do padro de linhas que representa as faces dos blocos comoencontrodasparedes.Umaoperaoadicionaldealinhamentodahachurana perspectivafoinecessria,resultandonafigura4.03d. Existem vrias situaes de projeto onde a representao simblica obtida atravs das operaes demonstradas acima seria suficiente. Por outro lado, considerandooparadigmadatransmissodomodelodoedifcioedoaprimoramento doseucontedodeinformaoduranteasfasesdoprojeto,emalgummomentouma representao mais precisa e flexvel seria exigida, antes que fosse iniciado o planejamento da construo. Para a alvenaria de blocos de concreto, a visualizao individualizadadosblocosespecialmentetilnosprojetoscomplementareseparao planejamentodaconstruo,queutilizaplantasdasfiadaseelevaesdasparedesde blocos.OselementosnativosdoArchiCADnofornecemainformaonecessriapara ageraodessadocumentao.Scheereoutrosautores,emestudodecasoconduzido em uma empresa de projetos especializada em construes com alvenaria de blocos deconcreto,observaramquemesmoutilizandooArchiCAD,osprojetistasconstroem muitasrepresentaesbidimensionalmente,domesmomodoquefariamemumCAD baseado em primitivos geomtricos, por falta de ferramentas adequadas (SCHEER et al., 2007). Uma rpida leitura nas postagens da maior comunidade de usurios de ArchiCAD no Brasil revela outros exemplos de utilizao de atalhos para solucionar
81

problemas para os quais os objetos nativos no fornecem solues adequadas (ARCHICLUBE,2008). Umdosatalhosadotadospelosusuriosnessassituaesousodesmbolos bidimensionais que representam cada bloco, individualmente, em planta. Considerandoapenasseisplantasdefiadasporpavimentoalgobastantecorriqueiro podese imaginar o vulto da tarefa de manter as diferentes representaes atualizadas no caso de uma modificao no projeto. Outro atalho a criao de um padrodelinha(linetemplate)paradesenharsmbolosdosblocosautomaticamente acompanhandoumpercursodefinidopelooperador,comomostradonafigura4.04a. Porm o sistema no identifica situaes onde blocos de ajuste ou meiosblocos so necessrios,comomostraafigura4.04b.E,piorainda,empercursoscurvososblocos no so discretizados e rotacionados, e sim distorcidos gerando uma representao incorreta,comonafigura4.04c.


Fig.4.04:representaodasparedesdeblocoscompadresdelinhas(linetemplates).

Aprincipalcrticaaessesatalhosquebaseiamseemelementosbidimensionais , porm, com relao ao fato de eles entrarem em conflito direto com princpios bsicosdamodelagemdeproduto:sotarefasqueexigemreentradamanualdedados em vrias vistas diferentes e no resultam em uma representao integrada. Para valerse minimamente das possibilidades oferecidas pelo ArchiCAD, poderia ser adotada a abordagem de modelar blocos individualmente. Blocos modelados dessa maneira podem usar o objeto nativo slab para oferecer uma representao fiel das unidades, como mostrado na figura 4.05. Como so objetos tridimensionais, as representaes para a documentao so geradas automaticamente. possvel

82

inclusive determinar a altura do plano de corte da planta, para gerar as diferentes plantasdefiadas.

Fig.4.05:representaodasparedesdeblocoscomelementosslab configurados paraassemelharem seablocosdeconcreto

Essa tcnica, porm, est longe de ser recomendvel. Modelar blocos individualmente pode ser til para o estudo do encontro entre elementos, ou ento demonstrar didaticamente as etapas da construo, ou ainda criar novas possibilidadesbaseadasnomtodoconstrutivo,maspodeserconsideradaumaprtica invivel em projetos comerciais. Por mais que a representao resultante seja detalhada e correta, o tempo gasto pelos projetistas manipulando cada um dos milharesdeblocosutilizadosmesmoemconstruesdepequenoporterapidamente superariaobenefciodautilizaodeumBIMCAD.Sackseoutrosautoresdescrevem os efeitos negativos da modelagem de produto quando objetos muito pequenos ou demasiadamente detalhados so utilizados durante a definio do projeto, o que chamam de bottomup modeling (SACKS et al., 2004). Em resumo, os problemas da representaoindividualdosblocosdeconcretosorelacionadosa: Obterrepresentaesparciais:osblocosdediferentesfiadasoucomposies teriamqueserorganizadosemlayers(camadasounveis)queprecisariamser ligadosedesligadosparafacilitaramanipulaodosblocos. Efetuar modificaes no projeto: uma vez que os blocos tenham sido dispostos, identificar e reposicionlos pode se tornar uma tarefa ainda mais difcildoqueutilizarelementosbidimensionaispararepresentarasparedes. Representar os componentes no discretizveis: os blocos modelados individualmentepodemterumarepresentaodetalhada,masasuniesentre os diferentes blocos no tem. Adicionar a representao da argamassa de rejuntamento ou revestimento cria um novo conjunto de desafios, para os quaisamesmadiscussofeitaacimaseaplica.

83

4.1.2Abordagemproposta A partir dos parmetros dos objetos utilizados no ArchiCAD possvel criar

scripts para automatizar a representao de paredes de blocos de concreto. Considerandoaexposiodasubseoanterior,ocenrioparadoxalaserenfrentado poressaferramentaoperaremumnvelmaisaltodo queamodelagemindividual dos blocos de concreto, porm gerando automaticamente instncias de nvel mais baixo, utilizadas como representao detalhada. Eastman observa que durante o desenvolvimentodeprojetos,ainformaotornasearticuladaincrementalmente,e inconveniente e pouco natural forar os usurios a especificar todos os atributos de um elemento durante a sua definio inicial (EASTMAN, 1976). Os projetistas manipulam paredes abstraindo vrias de suas caractersticas especficas. Elas so tratadascomopainis,enocomoumconjuntodecomponentesqueasconstituem (independentedequaissejam).Assim,apartirdeparmetrosdimensionaissimples,a documentaodetalhadadeveriasergeradaautomaticamente,deformatransparente paraousurio. Paraverificaressapossibilidadefoiutilizadaalinguageminternadescriptsdo

ArchiCAD,chamadaGeometricalDescriptionLanguageGDLparaconstruirumobjeto paramtricoespecializado.AGDLumalinguagemestruturada,comasintaxesimples ebastantesemelhantedoVisualBasic.HcomandosGDLparaacriaodetodosos primitivosgeomtricosetambmelementosconstrutivosnativosdoprograma.Uma reviso completa sobre a criao de objetos paramtricos no ArchiCAD pode ser encontrada no Introduction to Object making (NICHOLSONCOLE, 2004). A descrio dos comandos da GDL pode ser encontrada no manual tcnico GDL Reference Guide (GRAPHISOFT,2006;2008b)ediretrizesparaacriaodeobjetosparamtricoscoma GDL podem ser encontradas no Graphisoft GDL Technical Standards (GRAPHISOFT, 2008f). 4.1.3Desenvolvimentodoexperimento Aps a definio das caractersticas desejadas para as paredes de blocos,

esboos guiaram o processo de programao. A GDL no requer ferramentas adicionaisalmdoArchiCADocdigocriadoemumajaneladetexto,acessadaa

84

partir do menu principal do programa. O cdigo gerado um algoritmo estruturado (fig.4.06)queguiaosistemanacriaodeprimitivoseslidosgeomtricosdeacordo comosvariveisquecapturamosvaloresdosparmetrosespecificadaspelousurio. Essesparmetrossodimensionais(porexemplo,espessuradaparede,altura,tipode bloco,etc)ederepresentao(espessuradelinhas,hachura,cor,etc).Essasvariveis soprimeiramentedefinidasnocdigo,eentoassociadasametaparmetrosemum painelprprio(fig.4.07).

Fig.4.06:partedocdigoGDLquegeraumaformaprismticarepresentandoumblocodeconcreto.

85


Fig.4.07:janeladeconfiguraodemetaparmetrosdoArchiCAD.

Resumidamente, o script cria uma matriz tridimensional de blocos para representarasparedes,apartirdaavaliaodosparmetrosdimensionais.Ocdigo GDLcompletoencontrasenoApndiceA.Autilizaodoobjetocriadoenvolveduas interfaces: na janela da planta baixa do ArchiCAD feita a insero do objeto e a definio do comprimento (fig. 4.08). O nmero de parmetros acessveis por esta interface foi limitado para facilitar o uso do objeto nas fases iniciais do desenvolvimentodoprojeto.Asegundainterfaceajaneladeconfiguraodoobjeto, onde parmetros adicionais podem ser definidos (fig. 4.09). Esse painel de configuraes parte integrante da interface do ArchiCAD, e pode ser modificado a partir dos metaparmetros definidos anteriormente. A coordenao modular geomtrica essencial para o projeto de construes com alvenaria de blocos de concreto,efoiincludanocomportamentodoobjetocomoumarestrio.Quandoos objetosso dimensionados,ocomprimentoaumentadoemmltiplosdadimenso doblocoutilizado.

86


Fig.4.08:Inserodosobjetosparamtricosemplanta.

Fig.4.09:paineldeconfiguraodeparmetrosadicionais.

87

Parapermitirarepresentaoadequadadasparedesnasvriasvistasgeradas automaticamente(planta,corte,elevao,perspectiva),hparmetrosparacontrolar os elementos geomtricos utilizados. Isso garante que o objeto comportese apropriadamenteemcadasituao.Porexemplo,podeseconfigurarosobjetospara que os blocos interceptados pelo plano de corte sejam hachurados, enquanto os outros so mostrados em vista (figs. 4.10a e 4.10b). Ao contrrio da representao simblica por hachuras, que gera um padro simblico de linhas, a matriz de blocos criada pelo script do objeto possibilita a identificao da real posio de cada bloco. Issopodeserverificadonasfiguras4.10ce4.10d,quemostramumaparededeblocos aparentes,ondeumafiadadedetalhearquitetnicocompostaporblocosmenores.

Fig.4.10:representaesdasparedesdeblocosdeconcretogeradasautomaticamentepeloobjeto paramtricocriado.

Outrafuncionalidadeprogramadafoiocontroledaquantidadedeinformao mostrada nas representaes automticas ou seja, o nvel de detalhamento desejado.Essacaracterstica,chamadasensibilidadeaocontexto,umadasflexveis possibilidadesoferecidaspelodesenhoporobjetosparamtricosemvezdeprimitivos geomtricos. Quando o contexto alterado, todas as representaes so automaticamente atualizadas, evitando a reentrada de dados. Na figura 4.11a so mostradas duas representaes automticas do mesmo objeto, em duas situaes diferentes de escala de representao. A reduo da quantidade de informao apresentada,emescalasmenores,permitequeoprojetistaconcentreseemaspectos maisgenricosdoprojeto.Nafigura4.11bmostradaarepresentaoemplantado mesmo objeto da figura 4.10a, porm em uma situao onde o usurio modificou a

88

altura do plano de corte da planta baixa, fazendoo interceptar uma fiada mais alta. Essafunopodeserutilizadaparagerarplantasdasvriasfiadasautomaticamente.

1:25

1:100

Fig.4.11:representaesautomticasgeradasdeacordocomocontextodoobjeto

Scriptscomplementaresforamcriadosparapermitirqueoobjetoparamtrico representasse outros elementos construtivos baseados em blocos de concreto: peitoris,lintis,parapeitos,paredesdeblocosvazados,colunas,etc.,dandoorigema umafamliadeelementosorganizadoscomoumsistemaconstrutivo.Aassociaodas diferentes instncias do objeto paramtrico especializado com objetos nativos do ArchiCADpermitemarepresentaocompletadoedifcio.Nafigura4.12mostrado umexemplodessaassociao.

Fig.4.12:modelodeedifciocompostoporvriasinstnciasdoobjetoparamtricoassociadasa objetosnativosdoArchiCAD.

Arepresentaogeradaautomaticamenteapartirdosobjetosparamtricos precisaedetalhada.Nafigura4.13mostradaaplantadeumadasfiadasdoedifcio dafigura4.12,extradaautomaticamenteapartirdaconfiguraodaalturadoplano decortedaplanta.Aabordagemutilizadaparacriarosalgoritmosresponsveispelas

89

diferentesrepresentaesdosblocospoderiasergeneralizadaparaincluirelementos textuais, como cdigos de blocos e outras simbologias, completando o conjunto de informaes necessrias para o planejamento da execuo de obras de alvenaria de blocosdeconcreto.

Fig.4.13:plantadefiadaextradaautomaticamenteapartirdosobjetosparamtricosmostradosna figura4.12.

As observaes efetuadas durante o desenvolvimento e o uso do objeto paramtrico apresentado revelaram uma srie de novos desafios impostos para a modelagem de edifcios de alvenaria de blocos de concreto (AYRES, AZUMA et al., 2008; AYRES, SCHEER et al., 2008). Vrias caractersticas inerentes ao sistema construtivo, como a representao de peas estruturais, fiadas desencontradas, inserodeaberturasesistemascomplementaresprecisariamseratendidasporuma verso aprimorada da ferramenta. O artigo no qual essas caractersticas foram relacionadasencontrasenoApndiceB. 4.1.4Discusso Acessar o modelo proprietrio do edifcio via objetos paramtricos e scripts

GDL um procedimento relativamente simples, e h documentao disponvel suficienteguiarodesenvolvedoriniciante.Odesenvolvimentodeobjetosparamtricos

90

facilitadopelautilizaodainterfaceedeprocedimentosjexistentesnoArchiCAD como,porexemplo,ageraoautomticaderepresentaesemdiferentesvistas. Umadesvantagemevidente,compartilhadaportodososmtodosdeacessoa

modelos proprietrios a dependncia da ferramenta criada em relao aplicao principal,oArchiCAD,eaoseumodelodedados.Emboraomodeloresultantepossa ser exportado para o formato IFC, o desenvolvimento estaria condicionado s capacidadesdarotinademapeamentooferecidapelofabricante. Outra desvantagem o escopo limitado oferecido pela GDL. No foram identificadasnosmanuaistcnicosformasderelacionarduasinstnciasdiferentesde um objeto paramtrico, o que poderia ser muito til para definir comportamentos especficos para estas situaes. Por exemplo, vrias das situaes apresentadas no ApndiceB,comoaresoluoautomticadeencontrosentreobjetosrepresentando paredesdiferentesnopoderiaserresolvidapelaGDL.Comoosobjetosparamtricos criados a partir dela no conseguem acessar outros objetos do modelo, o seu uso acabalimitadorepresentaodeobjetosisolados,cujoescopolimitaseaidentificar osparmetrosderepresentaoselecionadospelousurioegerarrespostasnaforma derepresentaesadequadas.

4.2Script:EEQuantquantificaodeenergiaembutidaeemissodeCO2
Nesteexperimentofoiavaliadaapossibilidadedeacessarosdadosdomodelo do edifcio e associlos a dados adicionais sobre o ciclo de vida dos materiais de construomaisutilizadosnoBrasil,reunidosnorecentetrabalhocientficodeTavares (2006). A ferramenta desenvolvida, EEQuant, associa automaticamente esses dados, atravs de scripts e processos de quantificao disponibilizados pelo ArchiCAD. A informao resultante do uso da ferramenta permite avaliar instantaneamente, em fases iniciais do processo de projeto, parte do impacto ambiental causado pela utilizaodediferentesmateriaisdeconstruo.

91

4.2.1Definiodoproblema O aquecimento do planeta um tema com repercusso cada vez maior na

sociedade, e a indstria da construo responsvel por boa parte do consumo de energiaeemissodegasesdeefeitoestufa(ROAFeDAY,2001;ROAF,2004;TAVARES, 2006). O impacto ambiental gerado pela indstria da construo nas economias em desenvolvimentoaindamaiordoquenasdesenvolvidas,poisgrandepartedainfra estruturaaindaestsendoconstruda,eessesetordaindstriageralmenteresponde por uma proporo maior do PIB nacional (PLESSIS, 2001). A anlise do impacto ambiental causado pelo edifcio em todo o seu ciclo de vida tornase cada vez mais importante. Por definio da ISO 14040, a anlise do ciclo de vida considera as matriasprimaserecursosenergticosconsumidosemtodososprocessosenvolvidos naproduo,utilizaoedestinaofinaldeumproduto,bemcomoosseusimpactos ambientaispotenciais(TAVARES,2006). Osaplicativosquesepropemaanalisarociclodevidadosedifcios seguem umprincpiocomum:associamosdadosespecficosdoedifciosbasesdedadosque contm informaes sobre os processos de produo dos materiais utilizados na construo.UmadasbasesdedadosmaisconhecidasaEcoinvent,umlevantamento minucioso realizado atravs de uma iniciativa conjunta de institutos de pesquisa e rgosgovernamentaissuos,querenedadossobreociclodevidademaisde4.000 produtos industriais (SCLCI, 2008). Outro exemplo a base de dados utilizada pelo aplicativoLCADesign,queequivalenteEcoinvent,pormreunindodadosregionais daindstriaaustraliana. Umdosprocessosdeentradadedadosutilizadoporestesaplicativosdeanlise ambiental o que se baseia em planilhas quantitativas. Essas planilhas so preenchidas pelo usurio com os dados extrados manualmente do memorial descritivodoprojetodoedifcioaseranalisado.Dentreosprincipaisaplicativosdeste segmentoestooEcobat(FAVREeCITHERLET,2008)eoSimaPro(PR,2008). Uma desvantagem desse tipo de entrada de dado a tarefa de transposio das informaes entre diferentes aplicativos. Outro modo possvel para a entrada de dados o acesso ao modelo do edifcio, e a extrao automatizada de informaes.

92

Essa abordagem aproveita as informaes geradas em outras fases do processo de projeto,reduzindodrasticamenteouatevitandoareentradadedados,quesempre ummomentopropcioaosurgimentodeerros.Todaaetapadeleituradomemorialde materiaisdoprojetoeainserodasequivalentesquantidadesnoaplicativoespecfico poderia ser evitada, permitindo que o trabalho se concentre no processo de anlise em si. O aplicativo LCADesign, desenvolvido pela Agncia Nacional de Cincia da Austrlia CSIRO em parceria com indstrias do pas, utilizase desta abordagem. Os modelos dos edifcios so importados de outros aplicativos atravs do formato IFC (TUCKERetal.,2003;CSIRO,2008). 4.2.2Abordagemproposta Alm das duas alternativas para entrada de dados descritas na subseo anterior, possvel acessar o conjunto de informaes necessrias para a anlise de parte do ciclo de vida da edificao a partir da prpria interface do BIM CAD, ainda durante as fases iniciais do desenvolvimento do projeto. Desse modo, o arquiteto poderiaavaliarinstantaneamenteoresultadodesuasescolhasemtermosdeimpactos ambientais.Paraisso,foinecessrioacessarosdadosdomodeloapartirdainterface doArchiCADegerardiferentesalgoritmosparaquantificarautomaticamenteovolume decadamaterialutilizadoeassociaressesdadoscominformaessobreaproduo de materiais de construo no Brasil, reunidos em um recente trabalho de Tavares (2006).Emboraabasededadosutilizadasejamuitomenosvolumosadoqueosdois exemplos citados na subseo anterior, ela descreve as matrizes energticas da produodosmateriaisdeconstruomaisutilizadosnopas,eoseucarterregional permiteavaliarcommaisfidelidadeoimpactoambientaldautilizaodosdiferentes materiais. Alm de verificar a possibilidade de acesso aos dados do modelo e sua associao com informaes adicionais, a proposta da ferramenta EEQuant conscientizarprojetistaseestudantesdearquiteturaarespeitodosefeitosambientais das suas escolhas, fornecendo dados que fundamentem a deciso entre as diversas opesdisponveisparaossistemasqueconstituemoedifcio,jnasfasesiniciaisde projeto. Para facilitar a sua aplicao, ficou definido que a ferramenta no deveria

93

gerardisrupturasnoprocessodeprojetocomoqualosprojetistasestohabituados. Nessesentido,oaspectoinovadordaferramentaestnaabordagemadotada,quefoi introduzir parte da capacidade das ferramentas de anlise fsica de edificaes diretamente no aplicativo CAD, com o qual os projetistas tm mais afinidade. Dessa maneira,foipossvelagregardadosquantitativosdoimpactoambientaldaproduo dosmateriaisdeconstruoaomodelodaedificao,commnimasmodificaesno processoprojetual. Naversoapresentadanestetrabalho,aferramentaEEQuantavaliadeforma rpida,emfasesiniciaisdeprojetoarquitetnico,aquantidadedeenergiaconsumida e emisso de gs carbnico (CO2) na fabricao e no transporte dos materiais de construoutilizadosnoedifcioproposto. 4.2.3Desenvolvimentodoexperimento Para criar listas de quantificao de materiais, o ArchiCAD associa os parmetrosdimensionaisdosobjetosquecompemomodelodoedifciobasesde dados auxiliares que descrevem os componentes dos materiais utilizados. Essa associaotornaoclculoautomtico,poisovolumeouaextensodecadaelemento construtivo so obtidos pela combinao dos parmetros dos objetos que os representam. Por exemplo, um objeto paramtrico representando uma laje, cujo parmetro material foi definido pelo projetista como concreto: o processo de quantificao percorrer a base de dados auxiliar e localizar os componentes que esto associados ao material, bem como os seus ndices de consumo (areia, brita, cimento, gua, aditivos, etc.) e calcular os volumes de cada um deles a partir do volume total do elemento construtivo, que obtido a partir dos parmetros dimensionais. O corpo principal da ferramenta EEQuant justamente uma base de dados auxiliar, na qual foram inseridos (como componentes) os dados relativos ao consumodeenergiaeemissodeCO2naproduoenotransportedosmateriaisde construo.EssainseroocorreuemumajaneladeediodoArchiCAD(fig.4.14).Os parmetrosdimensionaisdosobjetosparamtricosdoArchiCADnoincluemopesoe, porisso,osndicessocalculadosapartirdovolumedematerial.Paraforneceropeso

94

totaldecadamaterialutilizado,foraminseridasnabasededadostodasasdensidades correspondentes.

Fig.4.14:janeladeediodoArchiCADondesocriadasbasesdedadosauxiliares

Aabordagemdequantificaopormeiodeassociaesentrebasesdedadose os objetos paramtricos um modo bastante dinmico para se extrair dados do modelo do edifcio. A partir de dados que so especficos de cada objeto (material, volume, posio, etc.), obtmse as quantificaes de quaisquer componentes que estejampresentesnabasededadosou quevenhamaserinseridosposteriormente, semquesejanecessriomodificarosobjetosdomodelo.Semessasassociaes,seria preciso criar ou modificar parmetros em cada um dos objetos que constituem o modelo, a cada vez que se necessitasse relacionar os elementos construtivos a informaesadicionaiscomocusto, horasdetrabalhonecessrias,prazodeentrega, ounocasodaferramentaEEQuant,emissesdeCO2eenergiaconsumida. Almdeflexibilizareagilizaroprocessodeextraodedados,asassociaes entre objetos paramtricos e bases de dados auxiliares tambm facilitam o processo de modelagem em si. Por exemplo, uma parede de blocos de tijolo 9x19x19 com
95

reboco nas duas faces pode ter seus componentes (tijolos, areia, cimento e cal) facilmente calculados a partir de uma associao, atravs de frmulas matemticas simplesqueconsideramosndicesdeconsumoeovolumetotaldoelemento.No preciso modelar cada tijolo e cada camada de argamassa individualmente, o que demandaria um tempo muito longo e dificultaria as alteraes posteriores, como exemplificadonoexperimentoanterior(seo4.1).Dissoresultaotipodemodelagem descritoporSackseoutrosautorescomotopdownmodeling(SACKSetal.,2004),que produzmodelosmaisleves,demandandomenorcapacidadedeprocessamento,eque so facilmente manipulados, podendo ou no passar por uma fase posterior de detalhamento, no qual os elementos construtivos so decompostos em unidades menores. Comabasededadoscompleta,foramgeradasasassociaespararelacionar oselementosconstrutivosnativosaosmateriaisecomponentescriados.NoArchiCAD, estasassociaessogerenciadasporelementosespeciaischamadospropertyobjects (fig.4.15).Afunodesteselementospermitiracombinaodevriositensdeuma oumaisbasesdedadosemumpacotedecaractersticasqueentoassociadoao objetoparamtrico.Porexemplo,umpropertyobject,criadoparaquantificarparedes de alvenaria pode conter itens de uma base de dados de materiais (tijolos, areia, cimento, cal), de uma base de dados de recursos (custo, horas de trabalho, equipamentos envolvidos), e de quaisquer outras bases criadas para acrescentar informaes, como a EEQuant, que fornece as quantidades de energia consumida e emisso de CO2 na fabricao dos materiais utilizados na parede. Sem os property objects, a associao envolveria relacionar individualmente cada item desejado ao objetoparamtrico,umaoperaodemoradaesujeitaaerrosporpartedooperador.

96


Fig.4.15:janeladeconfiguraodopropertyobjectdenominadoconcretemostrandoasrelaes entreoscomponenteseovolumedoelementoconstrutivo.

Em um property object as associaes podem ser diretas, requerendo uma simples seleo do item na base de dados auxiliar, ou indiretas, atravs de programao de scripts GDL. Algumas associaes da ferramenta EEQuant foram resolvidas de forma direta, porque se referiam a materiais simples ou macios, facilmente quantificados por volume (por exemplo, madeira, pedra, gesso, poliestireno).Paraoutrosmateriais,entretanto,aassociaodiretanofoisuficientee foinecessriaacriaodescriptsemGDL.Umexemploocasodosrevestimentos:a associao direta considerava apenas a superfcie total do elemento construtivo, somandotodasassuasfaces,quandoocorretoseriadiscriminarostiposdiferentesde revestimentoaplicadosacadaumadasfaces. Em outras situaes, alm da necessidade de se tratar os dados de maneira maiscomplexa,osscriptsemGDLpossibilitaramacriaodealgoritmoscapazesdese adaptar a diversas situaes, reduzindo o nmero de property objects utilizados e facilitandoousodaferramentaEEQuant.Essasituaoexemplificadapelocasodas paredes compostas por vrias camadas de materiais, como as de alvenaria: alm de discriminarseparadamenteaquantidadedemateriaisemcadacamada,eranecessrio

97

tornar a quantificao flexvel para aceitar novas composies, por exemplo, com diferentes espessuras ou materiais de reboco e diferentes tipos de tijolos ou blocos. Partedeumdessesscriptsmostradanafigura4.16,bemcomoajaneladeediona qual so criados. Os scripts criados para a ferramenta EEQuant encontramse no ApndiceCdestetrabalho.

Fig.4.16:partedoscriptGDLutilizadonopropertyobjectMasonryWall,responsvelpela discriminaodosmateriaisnasdiferentescamadasdeparedesdealvenaria.

A etapa seguinte no desenvolvimento da ferramenta foi a definio das associaes entre os objetos paramtricos nativos e os property objects. O ArchiCAD forneceduaspossibilidadesdeassociao:automticaemanual.Naformaautomtica so criadas regras de associao, que relacionam todos os objetos paramtricos que atenderem um determinado conjunto de critrios a um property object (e, conseqentemente,aositenscorrespondentesnabasededadosauxiliar).Oscritrios a serem atendidos podem ser, por exemplo, o tipo do elemento construtivo representado pelo objeto, o seu layer, cor do contorno, preenchimento, material, nomeoucdigodeidentificao.OArchiCADgerenciaregrasdeassociaoapartirde uma janela de edio, onde so mostrados os critrios e os property objects correspondentes(fig.4.17).

98


Fig.4.17:janeladegerenciamentodasregrasdeassociaoautomtica.

Para associar elementos construtivos aos componentes da base de dados auxiliar,aferramentaEEQuantseutilizadeassociaesautomticascujoscritriosso a correspondncia com o material de preenchimento ou revestimento do objeto paramtrico.Porexemplo,opropertyobjectConcrete,quereneositensdabasede dados auxiliar relativos produo dos materiais que constituem o concreto, associado automaticamente a todos os objetos paramtricos cujo parmetro fill (preenchimento)forEEConcrete,independentedequaisqueroutrosparmetrosdo elemento construtivo (fig. 4.18a). Por sua vez, o property object Ceramic Tiles (External) associado automaticamente a qualquer objeto paramtrico que possuir EE Ceramic Tiles (CTE) como valor para o parmetro material (revestimento) (fig. 4.18b).

99

Fig.4.18:configuraodocritrioparaassociaoautomticaaopropertyobjectConcrete (esquerda)eaopropertyobjectCeramicTiles(External)(direita).

Existem situaes, entretanto, para as quais o ArchiCAD no possibilita fazer associaes automticas. Para flexibilizar a quantificao de materiais compostos, a ferramenta EEQuant disponibiliza um property object que contm um script que quantifica cada material das diferentes camadas, sem que se precise associar cada novacomposioaumpropertyobjectdiferente.Essescriptsemostroubastantetil, principalmenteparafinsdidticos,quandoprecisoverificarqualoefeitoambiental causado,porexemplo,aoseaumentaraespessuradacamadadereboconasparedes de alvenaria. Porm, as regras de associao automtica do ArchiCAD no permitem que se crie um critrio do tipo todos os objetos que possuam material de preenchimentocomposto,sendonecessriaaassociaoindividualdecadamaterial de preenchimento, o que inutilizaria o princpio de flexibilidade do script. Por isso, o property object Composites, que calcula as quantidades de qualquer elemento construtivocompostoporcomposiodemateriais,deveserassociadomanualmente, atravsdajaneladeconfiguraodoelementoconstrutivonativo(fig.4.19).

Fig.4.19:associaomanualdopropertyobjectCompositesnajaneladeconfiguraodeum elementoconstrutivonativo(nessecaso,wall).

100

A ltima etapa do desenvolvimento foi a configurao da sada de dados do processo de quantificao. Para isso foi utilizada a funo List Scheme (esquema de listagem)doArchiCAD,quepermiteconfiguraroformatodalistadequantificao,e tambmcriarcritriosparaainclusoseletivadeelementosconstrutivosnativos.Com esses critrios, podese quantificar apenas os elementos que representem lajes, ou ento que sejam feitos de concreto, ou que estejam situados no andar trreo, etc. Tambmpossvelconfiguraralistaparaquemostreapenasasquantidadesdeitens que faam parte de uma determinada base de dados, nesse caso, a base de dados auxiliardaEEQuant.Ajaneladeconfiguraodocontedodalistadequantificao mostradanafigura4.20.

Fig.4.20:configuraodocontedoaserapresentadoemumalistadequantificaonabasededados EEQuant.

4.2.4Utilizaodaferramenta AutilizaodaferramentaEEQuantapiasenoprocessodetrabalhotpicoda modelagemdoedifcio noArchiCAD,quepor suavezbastantesemelhantecom os principais BIM CADs disponveis. Durante a criao dos elementos construtivos, o projetista deve selecionar os materiais que compem a base de dados da EEQuant, identificados pelas letras EE no incio do nome (fig. 4.21). Como explicado na subseoanterior,elementosquenopossuamessesmateriaisnoseroassociados basededados,e,conseqentemente,noseroincludosnaquantificao.

101


Fig.4.21:seleodomaterialdepreenchimentoduranteacriaodeumobjetoqueirrepresentar umalaje.

Os materiais de preenchimento e revestimento selecionados podem, obviamente,sermodificadosapsoprocessodecriao,permitindoqueoprojetista verifique diferentes possibilidades e os impactos ambientais de cada uma delas. A modificaodosmateriaisfeitanajaneladeconfiguraodeparmetrosdosobjetos do ArchiCAD (fig. 4.22). A substituio dos materiais, desde que seja por outros da base de dados EEQuant, atualiza automaticamente as associaes. Para o caso dos revestimentos, apenas as faces com materiais cadastrados na base de dados sero consideradas. Faces com demais materiais ou com o material EE Do Not Quantify, criadoespecialmenteparaestassituaes,noterosuassuperfciesquantificadas.

102


Fig.4.22:janeladeconfiguraodosparmetrosdeumobjetorepresentandoumalaje.

A etapa seguinte consiste na definio do escopo de elementos a serem quantificados, selecionando os objetos desejados atravs das ferramentas do ArchiCAD.Casonenhumobjetosejaselecionado,seroquantificadostodososobjetos que constituem o modelo do edifcio. Selecionar um nico elemento para fazer a quantificao tambm uma maneira didtica de se verificar parte dos efeitos ambientaiscausadospelomaterialescolhido.Porexemplo,analisandoumalajede100 x100cmumalunodearquiteturapoderiaverificarosnveisdeenergiaconsumidae CO2 emitido na fabricao dos materiais demandados para cada metro quadrado do pavimento do edifcio que utilizar o referido elemento construtivo. Foram desenvolvidosdoismodelosbsicosdelistagem:aestendida,quemostraosndicesde consumodeenergiaeemissodeCO2paracadamaterial(fig.4.23)earesumida,que mostra apenas os totais dos ndices (fig. 4.24). Essas listas so acessveis a partir da interface padro do ArchiCAD, e podem ser copiadas e exportadas para planilhas eletrnicas.

103


Fig.4.23:listaestendida,mostrandoosndicesdeconsumodeenergiaeemissodeCO2nafabricao decadaumdosmateriaisutilizados.

Fig.4.24:listaresumida,mostrandoapenasatotalizaodosndices.

O processo para quantificar objetos paramtricos de um modelo existente por exemplo, criado em outro BIM CAD e importado para o ArchiCAD via IFC basicamente o mesmo. Podese proceder a anlise de um modelo de edifcio j existentedetrsformasbsicas: 1. Substituindo os materiais de preenchimento e revestimento de cada elementoconstrutivopelosmateriaisquecompemabasededadosEEQuant o modo mais recomendado, por ser menos propenso a erros por parte do operador;

104

2. Associando os materiais de preenchimento e revestimento existentes aos propertyobjectsdaEEQuant,criandoassociaesautomticasummodogil, pormquerequermaiorexperinciaporpartedooperador; 3. Associando manualmente cada objeto paramtrico representando elementos construtivos do modelo um modo rpido, que se presta a quantificaes menores, de poucos elementos, mas desaconselhado em modelos completos, porque pode gerar discrepncias caso o operador omita algumdoselementosconstrutivos. Como exemplo da aplicao da ferramenta, foi criado o modelo de uma pequena residncia, mostrado na figura 4.25. Desse modelo foram extradas automaticamente as listas de quantificao de energia consumida e CO2 emitido na fabricaoetransportedosmateriais.Tratasedeumacasatrreade7cmodos,com rea aproximada de 105 m, em um terreno de 12 x 30 m. O sistema construtivo escolhidoomaisutilizadonoBrasil:estruturadeconcretoarmadocomvedaesde blocos de cermica vermelha. As paredes so revestidas com argamassa simples e pintadascomtintaPVAourevestidasdepeascermicas(reasmidas).Ospisosso lastros de concreto, com revestimento cermico ou de madeira. O forro composto por laje prfabricada com elementos de cermica e capeamento de concreto. A estrutura do telhado de caibros e ripas, com pontaletes, e a cobertura de telhas cermicastipofrancesa.

Fig.4.25:modelocriadoparaexemplificarousodaferramentaEEQuant,emperspectivaeplanta

105

A ferramenta demonstrou que mesmo uma casa relativamente simples como esta utiliza um volume de materiais de construo cuja produo consome considerveis quantidades de energia: aproximadamente 328,5 GJ. O impacto ambiental fica mais evidente, entretanto, pela quantidade de CO2 emitido: quase 24 toneladas.Comoilustrao,deacordocomtrabalhodeMartins(2004),queconsidera a absoro mdia de carbono por rvores tpicas da floresta atlntica brasileira, estimasequeserianecessriooplantiode152rvores,apenasparaabsorveroCO2 emitidonafabricaoenotransportedosmateriaisutilizados.Nosoconsideradas nesse clculo as demais fases do ciclo de vida da edificao (construo, utilizao e demolio,porexemplo).AslistascompletasgeradaspeloEEQuantparaomodeloda residnciadoexemplosomostradasnoApndiceD. 4.2.5Discusso O acesso aos dados do modelo digital e a sua associao com informaes complementares mostrouse vivel e produziu interessantes resultados. A automatizao conseguida pode ser generalizada para as mais diversas aplicaes, sendo necessrio apenas definir novos ndices e inclulos em bases de dados auxiliares.Porexemplo,poderiasercriadaumabasededadosauxiliarquecontivesse todaainformaodisponvelnasTabelasdeComposiodePreosparaOramentos (TCPO), que j esto organizados em componentes e ndices de consumo. Atravs dessaassociaotambmpoderiaserestendidooescopodeanlisedociclodevida, j que as TCPO tambm incluem o consumo de energia de cada equipamento envolvido na produo dos elementos construtivos e na sua demolio (PINI, 2003). At anlises fsicas preliminares poderiam ser realizadas atravs desse mtodo de acessoaosdadosdomodelodoedifcio.possvel,porexemplo,definirumarelao entre a massa do edifcio, seus materiais e o volume dos cmodos, para determinar expeditamenteacargadecondicionamentotrmiconecessria. Como esse mtodo de acesso est completamente integrado ao processo natural de projeto do ArchiCAD, foi observada grande agilidade e integrao da ferramenta,quesetornouumaextensodasfuncionalidadesdoCAD.Apossibilidade dequantificaoinstantnea,semquesejanecessrioumprocessodetransporteda

106

informao de um programa para outro, seja este processo manual ou automtico, fornece ao projetista suporte para a tomada de decises durante o projeto, permite queeletestevriasalternativasdeprojeto. As desvantagens apontadas na subseo 4.1.4 tambm aplicamse a este experimento,jqueoacessoaosdadospraticamenteomesmo.Aprincipaldelas que a ferramenta fica limitada estrutura de dados e s interfaces disponibilizadas pela aplicao principal. O volume e a estrutura de dados necessrios para avaliar o impacto dos processos de gesto de obra, por exemplo, extrapolam facilmente o escopodeumCADarquitetnico,quereleutilizemodelagemouno.

4.3Plugin:aplicaoparaexportaodedadosdoArchiCAD
A simulao do desempenho ambiental tem experimentado significativo

desenvolvimento nas ltimas duas dcadas. Diferentes sistemas tm surgido, com diferentes graus de acessibilidade. Os mais acessveis acabam servindo a um pblico maisamplo,eemespecialcomoinstrumentosdidticosnaprticaprojetual.Osistema Mestre foi criado e vem sendo continuamente aprimorado pelo professor Alosio Schmid,eatualmenteexecutaanlisestrmicas,acsticaselumnicas.Foiutilizadoem quatrodiferentesturmasdocursodeArquiteturadaUniversidadeFederaldoParan, como instrumento educativo, para demonstrar aos alunos a relao direta entre as decisesdoprojetoeassuasconsequnciasnodesempenhoambientaldaedificao (SCHMID e AYRES, 2007). Uma descrio detalhada das funcionalidades do sistema MestrepodeserencontradanostrabalhosdeSchmid(SCHMID,2001;2004;2006). Neste experimento foram verificadas as vantagens e desvantagens do acesso

aos dados do modelo do edifcio via plugin. Uma aplicao foi desenvolvida para transformar informaes do modelo do edifcio criado no ArchiCAD para o formato nativodosistemaMestre. 4.3.1Definiodoproblema O objetivo das atividades didticas com as quatro turmas do curso de

Arquitetura da UFPR, utilizando o sistema Mestre como instrumento didtico, foi considerado atingido. Entretanto, o processo de modelagem das edificaes pelos
107

alunos foi considerada uma atividade desgastante. A entrada de dados no sistema MestrefeitaatravsdearquivosdetextoASCII,ondesoinseridosparmetrospara orientar o programa na criao dos slidos que representaro os elementos construtivos.Umexemplodeumarquivodeentradadedadosnosistemamostrado nafigura4.26.Osdiferenteselementosconstrutivossocriadosapartirdaoperao deseparao(tokenization)dasvriasstringsquecompemoarquivoemcomandose atributos.
d 15 7 0 24 3600 -25 50 0 40 -3000 3000 17 26 0 0.25 0.5 0.5 1 1 0.4 CHAO p -5.0 5.0 0.0 0 90 10.0 0.25 10.0 3 2 1 25 cho PAREDES p -5.0 5.0 0.0 0 0 10.0 0.15 3.0 4 2 0 25 norte p 5.0 5.0 0.0 90 0 10.0 0.15 3.0 4 2 0 25 leste p 5.0 -5.0 0.0 180 0 10.0 0.15 3.0 4 2 0 25 sul p -5.0 -5.0 0.0 270 0 10.0 0.15 3.0 4 2 0 25 oeste TETO p -5.0 5.0 3.0 0 90 10.0 0.25 10.0 3 2 0 25 teto fp -10.0 10.0 0.0 0 90 20.0 20.0 6 2 0 25 TERRA e 1.0 1.0 -6378000.0 6378000.0 7 terra m 1.0 700 500 0.1 0.3 0.7 0.0 0.0 0.0 0.15 0.15 0.11 0.10 0.07 0.06 0.07 0 0 0 0.0 22 assoalho m 1.0 700 300 0.1 0.3 0.4 0.0 0.0 0.0 0.04 0.04 0.04 0.15 0.29 0.52 0.59 0 0 0 0.0 2 carpet m 1.0 700 2400 0.3 0.2 0.3 0.0 0.0 0.0 0.01 0.01 0.01 0.02 0.02 0.02 0.03 0 0 0 0.0 8 concreto m 0.7 700 1200 0.1 0.3 0.3 0.0 0.0 0.0 0.01 0.01 0.01 0.02 0.02 0.02 0.02 0 0 0 0.00 4 alvenaria m 1.0 700 2200 0.1 0.1 0.0 0.9 0.9 0.9 0.18 0.18 0.06 0.04 0.03 0.02 0.02 0 0 0 0.01 1 vidros m 1.0 700 100 0.1 0.1 0.0 0.0 0.0 0.0 0.18 0.18 0.06 0.04 0.03 0.02 0.02 0 0 0 0.01 3 gramado m 1.0 700 1000 0.3 0.2 0.1 0.0 0.0 0.0 0.20 0.20 0.10 0.10 0.06 0.05 0.00 0 0 0 0.0 6 planeta Terra z 1000 0 0 0 0 23 23 23 23 0 0 0 0 0 0 0 0 21 1 ar externo z 1000 0 0 0 0 100000 100000 1000000 100000 0 0 0 0 0 0 0 0 21 1 subsolo z 1000 0 0 5000 0 8 8 8 8 0 0 0 0 0 0 0 0 21 1 inferior X ====================================================================================================================== ta 2 18.6 18.4 18.2 18.1 17.9 17.8 18.4 20.1 21.9 23.8 25.4 26.5 27.6 27.7 27.7 27.6 26.2 24.8 22.3 20.8 20.1 19.5 19.1 18.8 ta 6 2.3 1.8 1.3 0.8 0.5 0.2 -0.3 -0.6 0.8 3.5 6.6 9.1 11.1 12.0 13.0 13.3 13.1 11.8 9.4 7.3 6.3 5.1 4.4 4.0 ta 7 2.3 1.8 1.3 0.8 0.5 0.2 -0.3 -0.6 0.8 3.5 6.6 9.1 11.1 12.0 13.0 13.3 13.1 11.8 9.4 7.3 6.3 5.1 4.4 4.0 tma 9 -10 20

Fig.4.26:arquivodeentradadedadosdosistemaMestre,apartirdosquaissoconstrudasas representaesdoselementosconstrutivos.

ComoobservadoporHoffmanneJoanArinyo(2002),criarmodelosapartirde linhasdecomandoumatarefapoucointuitivaparaosprojetistas,edeveserevitada semprequepossvel.Defato,amaioriadosalunosdemonstroudificuldadesnacriao domodelo,jqueamaiorianuncatevequalquercontatolinguagensdeprogramao ou com sistemas computacionais baseados em comandos textuais. Alm disso, completar o arquivo de texto que daria origem ao modelo era apenas o primeiro passo.Comoaintenodaanlisedodesempenhoambientalapontardeficinciase embasarmodificaesnoprojeto,haviasempreanecessidadedemodificaroarquivo inicial, substituindo materiais, criando ou eliminando elementos construtivos. Se por um lado a substituio de materiais era elementar, envolvendo a troca de um nico atributono arquivotexto,aalteraodageometria(comoporexemploacriaoou eliminaodeaberturas)mostrousemorosaefoievitadapelosalunosnamaiorparte dassituaes.Emavaliaonosistemtica,osalunosreconheceramovalordidtico

108

daatividade,pormreivindicarammtodosmaisfceisparaaentradaeamodificao dosdadosqueoriginaroomodelo. 4.3.2Abordagemproposta O sistema Mestre representa elementos construtivos parametricamente, de

maneira muito semelhante ao ArchiCAD. Os vrios parmetros de cada elemento que possibilitam a execuo das anlises (por exemplo, densidade, massa, ndice de reflexo da luz, etc). Essa afinidade de modelos de dados sugeriu que o processo de traduo entre os formatos das diferentes aplicaes seria vivel. Alm disso, a solicitao dos alunos por uma interface mais intuitiva poderia ser respondida transferindose o processo de construo do modelo para o ArchiCAD, e posteriormente exportando essas informaes para o formato nativo do sistema Mestre,queseencarregariadeexecutarasanlises. O mapeamento completo das estruturas de dados que definem os diferentes

objetos nos dois sistemas seria uma tarefa muito extensa, e interferiria no tempo necessrio para a conduo de outros experimentos deste trabalho. Por isso, foi decidido criar uma aplicaopiloto simplificada, inicialmente exportando apenas as paredes criadas no ArchiCAD para o sistema Mestre. Como o modelo de dados do ArchiCAD determina padres que so muito semelhantes para todos os objetos, considerousequeaexperinciacomaexportaodasparedespossasergeneralizada paratodososoutroselementosconstrutivos,deformaqueaaplicaofinalseguiriaa mesmalgicaproposta. 4.3.3Desenvolvimentodoexperimento Paraqueaplicaesespecializadaspossamsercriadaseutilizadasemconjunto

com o ArchiCAD, complementando as suas funcionalidades, a Graphisoft oferece um conjunto de bibliotecas de vnculos para programao em C++, chamada Graphisoft ApplicationProgrammingInterfaceDevelopmentKit,ousimplesmenteGraphisoftAPI (GRAPHISOFT,2008d).AAPIdisponibilizadagratuitamenteparausonocomercial,e um cadastro junto Graphisoft foi necessrio para que um cdigo que habilita o funcionamentodeaplicaescriadascomaAPIfossedisponibilizado.

109

Ao contrrio da criao de scripts, o desenvolvimento de aplicaes com a

GraphisoftAPInoutilizaalinguagemGDL,esimC++,queamesmalinguagemna qualoArchiCADfoidesenvolvido.Issonogarantesumamelhoradaptaodanova aplicao ao sistema principal, mas tambm viabiliza algoritmos muito mais complexos, de escopo mais amplo e processamento mais rpido do que seria conseguido com a melhor programao GDL. Tambm podese criar aplicaes em Java utilizando a API, desde que sejam definidos mtodos nativos para gerenciar a conexo com as funes das bibliotecas DLL. Essa abordagem no encorajada pela Graphisoft, por ser mais propensa a erros de alocao de memria durante a execuo. Os mtodos disponibilizados pela API podem ser utilizados tanto para a criao de plugins como aplicaes independentes. Podese, por exemplo, desenvolver um sistema de anlises fsicas completo em C++, utilizando funes de diversasbibliotecasentreelasasdaGraphisoftAPI.Oresultadoseriaumprograma completamente independente do ArchiCAD, que, no entanto, seria capaz de ler e gravar modelos no formato de dados proprietrio da Graphisoft. As funes disponibilizadaspelaGraphisoftAPIsorazoavelmentesimplesparaprofissionaiscom conhecimento da linguagem C++. Uma referncia completa destas funes pode ser encontradanadocumentaofornecidapelafabricante(GRAPHISOFT,2008c). A abordagem adotada para o algoritmo criado foi percorrer todos os objetos

wall do edifcio em um loop principal, identificando os parmetros dos objetos e gerando uma pilha de strings no formato nativo do sistema Mestre. O formato de dadosdosmodelosdeedifciosnoArchiCADorganizadoemumasriedebasesde dados,umaparacadatipodeelementoconstrutivonativo(wall,slab,column,beam, window,etc).Paraobteracoleodetodososobjetoswallexistentesnomodelo,a base de dados correspondente transferida para uma matriz temporria, que ento pode ser percorrida elemento por elemento. A estrutura de dados do modelo do ArchiCAD orientada a objetos, ento para realizar a converso de dados, basta chamartodososparmetrosdesejadosetransplosparaanovaposionestecaso, dentro das strings que formaro os comandos do sistema Mestre. Alm dos parmetros geomtricos, so processados tambm os parmetros complementares

110

materialefill,quecorrespondemaomaterialderevestimentoeaomaterialdoncleo decadaumadasparedes,respectivamente. O sistema Mestre no possui um comando para a criao de aberturas nas

paredes. Janelas e portas so representadas como paredes mais estreitas, e com o materialprprio(madeiraevidro,porexemplo).Domesmomodo,vergaseparapeitos so representados como segmentos de paredes. Para o ArchiCAD, aberturas nas paredes so representadas pelos objetos window e door. Estes objetos possuem as suas prprias bases de dados, mas mantm um vnculo indissolvel com as paredes nasquaisestoposicionados.Duranteolao(loop)principaldoprograma,umarotina especialchamadaparadiscretizaresegmentarasparedessemprequeumaabertura associada a ele localizada. O resultado um conjunto de paredes cortadas pela extensodaslateraisverticaisdasaberturas,comodemonstradonafigura4.27.

Fig.4.27:diagramademonstrandoaoperaodesegmentao dosobjetoswall.

Foi necessrio tambm criar uma pequena funo de ajuste da preciso dos nmeros reais, que era diferente para os dois sistemas. Outra discrepncia que precisoudetratamentofoionguloderotaodasparedesnoeixovertical:osdois sistemasadotavamorigensdiferentesparaamedida. Novos loops poderiam ser criados para realizar a exportao dos outros elementos construtivos nativos, e parmetros adicionais podem ser extrados por novas rotinas, utilizando a mesma abordagem. Quando a leitura dos objetos wall se

111

completa, so acrescentadas strings para melhorar a visualizao do arquivo texto e facilitareventuaisediesdiretas. A ltima etapa do desenvolvimento foi definir uma complementao para a interface save as (salvar como) do ArchiCAD. Desse modo, a partir da janela de perspectiva,ousurioacessaomenue,entreasopesdeformatodearquivo,surge o formato .obj (Mestre) para exportao. A aplicao de exportao executada peloArchiCADassimqueousurioclicanobotosavedajaneladedilogosaveas.O algoritmocompletodaaplicaoencontrasenoApndiceEdestetrabalho. A instalao da ferramenta feita como qualquer outro plugin do ArchiCAD. Umapastacontendoaaplicao,comaextensoAPXcopiadaparaasubpastaplug ins contida na pasta de instalao do programa. Na figura 4.28 um conjunto de paredes criadas no ArchiCAD para demonstrar o uso da ferramenta mostrado em plantaeperspectiva.Nafigura4.29,oarquivoresultantedoprocessodeexportao mostrado.


Fig.4.28:conjuntodeparedescriadonoArchiCADparatestaraexportaoparaosistemaMestre.

112

//Arquivo exportado do AC10 para o programa Mestre // //Paredes // //x y z azi alt larg esp h mat // p 0.1 0 0 90 0 1 0.1 2 66 p 0 0 0 0 0 1 0.1 2 66 p 1 0 0 45 0 1.41421 0.1 2 66 //Fim do documento exportado

zf 0 0 0

zi 0 0 0

n 25 25 25 Parede 90 Parede 0 Parede 45

Fig.4.29:arquivodeexportaogeradoapartirdoconjuntodeparedesdafigura4.28.

4.3.4Discusso O acesso ao modelo do edifcio via plugin mostrou uma flexibilidade muito

superior ao acesso via script. Um dos problemas apontados na subseo 4.1.4 o escopo reduzido e a consequente impossibilidade de programar uma inteligncia contextual mais refinada nos objetos facilmente resolvido pela possibilidade de acessar a coleo completa de objetos que constituem o modelo, e ento fazer diferentesrelacionamentosentreeles. A programao em C++, ao contrrio da feita em GDL possibilita algoritmos

complexos, que podem conter funes especialmente desenvolvidas para clculos matemticos,anlisesfsicasegeraodeinterfaces,disponveisnaInternet.Atravs da criao de plugins tambm podese acessar e modificar partes da interface do ArchiCAD. possvel criar novos menus, novos conjuntos de botes e ferramentas e atnovasjanelasdedilogocomousurio.Emboraacriaodepluginssejamuito mais complexa do que a criao de scripts GDL, a documentao fornecida pela Graphisoftfacilitoubastanteodesenvolvimentodaaplicaonesteexperimento.Uma outrapossibilidadeinteressanteautilizaodaGraphisoftAPIparapermitirqueuma aplicao independente consiga ler e gravar modelos no formato proprietrio da fabricante.OutrasAPIsdeoutrosfabricantespoderiamserutilizadasemconjuntopara permitiraleituraegravaodeoutrosformatosdemodelosdeedifcios,flexibilizando osistemacriado. AssimcomonacriaodescriptsGDL,agrandedesvantagemdessemodode

acessoaomodeloofatodaaplicaoresultantenoserportvel.Eladependente da aplicao principal, o que limita a escolha por parte dos usurios ou obriga o

113

programadoracriarvriasversesdeummesmoplugin,paraosprincipaisBIMCADs existentes,jqueasferramentassoincompatveisentresi. Outradesvantagemanecessidadedeatualizaesconstantesdaferramenta,

sempre que uma nova verso do ArchiCAD for lanada. Recentemente a fabricante informou, atravs do frum de desenvolvedores de plugins, que um novo e aprimoradoconjuntodeconexesentreoncleodaaplicaoprincipaleosplugins foi desenvolvido para a verso 10 do sistema, tornando as prximas atualizaes de plugins mais fceis, possivelmente necessitando apenas de uma recompilao do cdigoealgunsajustesnosarquivosdecabealhodaaplicao.Entretanto,naverso 12houveumareformulaodomotordeclculosdosistema,paraqueseadaptasse aosnovossistemasoperacionaisde64bits,queutilizammaiseficazmenteopotencial dosprocessadoresdencleoduplo.ComooC++umalinguagemmuitosensvelno que diz respeito ao gerenciamento da memria, muito provvel que boa parte do cdigodospluginsdesenvolvidosparaoArchiCADtenhaquesernovamenterefeita. Essa situao consequncia da possibilidade de acesso em um nvel mais baixo do que o conseguido com os scripts GDL, que podem ser executados em vrias verses posterioresqueforamcriados.

4.4AcessodemodelosnoformatoIFCSPF
Neste experimento foi testado o acesso a dados de modelos no formato SPF

(STEPPhysicalFile),descritosatravsdoesquemaIFC.Foramrealizadastrstentativas utilizando duas ferramentas diferentes, com algoritmos em duas linguagens de programao (C++ e Java). Erros durante a compilao de cdigosfonte fornecidos comasferramentasinviabilizaramacriaodeferramentasparailustrarestemodode acesso.Nositensseguintesasetapasdoexperimentosodescritas. 4.4.1Definiodoproblema Acessar um modelo proprietrio implica na aceitao da limitao do seu escopo e na dependncia de um fabricante especfico, como exposto nos experimentosanteriores.FormatosneutrosdedadoscomoasIFC,poroutrolado,so criados com o propsito de facilitar a transferncia de informaes do modelo do

114

edifciopordiferentesfasesdoseudesenvolvimento.Emsituaesondesepretenda acessar dados em um escopo mais amplo isto , mais fases do ciclo de vida da edificaoounasquesejamaisinteressantemanteraaplicaomaisadaptvelaum contexto de mltiplas aplicaes, acessar dados de modelos neutros tornase mais aconselhvel. 4.4.2Desenvolvimentodoexperimento A forma recomendada para acessar os dados de arquivos IFC em arquivos

fsicos(STEPPhysicalFile)utilizarumaferramentaIFCToolbox.AIAIsugerevriasIFC Toolboxes em sua pgina internacional (IAI, 2008a). Essa ferramentas compilam um arquivo contendo a definio em EXPRESS das IFC e geram uma biblioteca contendo uma estrutura hierrquica de classes em C++, correspondentes s entidades do arquivodedefinio.EssaoperaoregidaporespecificaesdaprprianormaISO 10303, parte 22 Standard Data Access Interface, conhecida como SDAI, que define ummodeloparaacriaodeAPIs(ApplicationProgrammingInterfaces)paraacessoa dadosSTEP(ISIKDAGetal.,2007).Almdeclassesparacadaumadasentidades,so criadas outras que gerenciam o acesso aos arquivos SPF (ou seja, os modelos de edifcios)queserolidos.Porquestesapenasdediferenciao,convencionouseque osarquivosSPFcontendomodelosdescritosdeacordocomasIFCpossuamaextenso .ifc.Oprocessodecriaodessabibliotecadeclassesqueintermediaoacessoaos modelosdedadosconhecidocomobinding. Depois de criada, a biblioteca utilizada pela aplicao em desenvolvimento para acessar os dados dos modelos de edifcios. As funcionalidades oferecidas pela bibliotecacriadadependemdaIFCToolboxutilizada.Toolboxesgenricascriamapenas as classes equivalentes s entidades e tipos correspondentes aos atributos dessas entidades. Associar as diferentes entidades (por exemplo, todas as portas e janelas quefazempartedeumaparede)ougerarrepresentaeseanlisesapartirdelasfica acargodoprogramador,comodemonstradonotrabalhodeTreeckeoutrosautores (2003). Toolboxes de programao em alto nvel, alm das classes e tipos, criam rotinas para associar hierarquicamente as entidades distribudas pelo arquivo SPF, podendoapartirdeentofornecercoleesdeentidades.Essascoleesreduzemo

115

trabalhodeprogramaonecessrioparaseobterinformaesapartirdosmodelos deedifcios.Toolboxesdeprogramaoemaltonvelpodem,inclusive,conterrotinas pararepresentaotridimensionaldasentidadesdomodelo. Neste experimento foram testadas duas Toolboxes. A IFC Engine DLL, do

instituto holands TNO (TNO, 2008c) e a JSDAI EXPRESS API da alem LKSoftWare (LKSOFTWARE, 2008b). A JSDAI no uma IFC Toolbox, em seu sentido estrito. Na verdade o seu propsito permitir a operao de binding a partir de qualquer esquema de dados descrito em EXPRESS. Sendo essa justamente a natureza das IFC, podese supor que a leitura de um modelo IFC a partir de uma EXPRESS toolbox, embora no se oferea algumas funcionalidades especficas includas nas IFC toolboxes,emespecialageraoderepresentaestridimensionais,devaresultarno mesmoconjuntodedadosbsicos(rawdata).Aescolhadessasduasferramentasfoi baseada em critrios de viabilidade e tambm na possibilidade de demonstrar duas formasdiferentesdeacessoaosmodelosSPF.Oquadro4.01mostraumacomparao entreasduasferramentasbinding.
Aspecto IFCEngineDLL JSDAIEXPRESSAPI

Propostaoriginal Pesquisacientfica Comercial Linguagemde C++ Java programao Nvelde Alto(contminclusiverotinaspara Baixo(apenasidentificaas programao modelagemtridimensional) instnciasdasentidadesEXPRESS) Compilaodo QualqueresquemaEXPRESS ApenasversesdasIFC esquema validvel Quadro4.01:diferenasentreIFCEngineDLLeJSDAIEXPRESSAPI

Em comum, ambas as ferramentas tem o fato de serem gratuitas para

propsitosnocomerciais.DuranteapreparaodoexperimentooutrasIFCToolboxes sugeridas pela IAI foram consideradas, mas a maioria possua verses apenas comerciais. Oprocessodedesenvolvimentodeferramentasdeacessoseguiuasinstrues

contidasnasdocumentaesecdigosdeexemplodeambasasferramentas.Nocaso daIFCEngineDLL,foramadotadasduasabordagens:aprimeirafoiaprogramaoem

116

JavautilizandomtodosnativosdeacessosclassesC++,esegundafoiaprogramao apenasemC++.Emambososcasos,optouseporiniciarodesenvolvimentoapartirda operao de leitura de um modelo IFC simplificado, e a partir da construir uma ferramentasimplesparailustraroacessoaomodelo.Osresultadosdosexperimentos comasduasIFCToolboxesutilizadasdescritonositensaseguir. IFCEngineDLL ATNOdisponibilizaexemplosdecdigosfonteparaaoperaodeleiturade modelos a partir de vrias linguagens de programao (TNO, 2008b). No foram acrescentadasmodificaesaestesexemplosnestafasedoexperimento.Oscdigos foram baixados e compilados seguindo as instrues para cada linguagem utilizada (C++ e Java), e a compilao foi bem sucedida nas duas linguagens. A partir da aplicaocompilada,foipossvelacessarosdadosdomodeloqueacompanhaocdigo exemplo,etambmdemodeloscriadosnoArchiCADeexportadosparaoformatoIFC. Entretanto,esseacessoocorreemumnvelmuitobaixo.Comodescritonasubseo 3.6.2,aestruturadedadosdomodeloIFCcompostaporumasriedeentidadesque decompem os elementos construtivos at os seus primitivos geomtricos. Para permitir um acesso em nvel mais alto, a IFC Engine DLL tem rotinas que calculam a superfcie das entidades EXPRESS que representam slidos geomtricos e fornecem comoparmetrosderivadosasdimensesdoselementos(TNO,2008a).Esseprocesso de recomposio do modelo executado pelas classes initializeModelling e initializeModellingInstance. O uso dessas classes, porm, gerou erros de execuo tanto na programao em Java como na em C++. Esses erros aconteceram durante a execuo dos prprios exemplos fornecidos pela TNO, o que sugere que sejamnecessriasconfiguraesadicionaisnacompilao.Adocumentaoexistente nomencionaessasituaoenofoipossvelcontornaroerroemtempohbilparao desenvolvimento de uma ferramenta preliminar. Uma possvel soluo seria utilizar apenasasclassesdeacessoaosdadosembaixonvel,eproduzirumaversoprpria daclasseinitializeModelling.

117

JSDAI EmrelaoIFCEngineDLL,aferramentaJSDAIoferecemaisdocumentao,

inclusive tutoriais em vdeo mostrando a criao de aplicaes passo a passo. A ferramentatambmestdisponvelnaversodeumworkbenchparaoambientede programao Eclipse, inclusive com um mdulo para gerao de esquemas via EXPRESSG, a verso grfica do EXPRESS (LKSOFTWARE, 2008b). Ao contrrio da IFC EngineDLL,porm,aJSDAInofoicriadaobjetivandooacessoaarquivosIFC,esim quaisquerarquivosSPF.Porisso,antesdedesenvolveraaplicaoemsi,necessrio compilar o esquema EXPRESS que dar origem s classes que sero utilizadas no processodebinding.AcompilaodeesquemasEXPRESSemJSDAIfeitanomdulo EXPRESSCompiler,tambmdisponvelnaversoparaEclipse(LKSOFTWARE,2008a). A compilao do esquema IFC 2X3 no EXPRESS Compiler gerou um erro de

validade, e a biblioteca de classes no foi gerada. Logo de incio cogitouse a possibilidadedoerrosercausadopelaJSDAI,enopeloesquemaIFC2X3.Oesquema era a verso estvel mais recente disponibilizada pela IAI, e antes de ser disponibilizadohaviasidocertificadoporvriasferramentasprpriasparaverificao da coerncia de esquemas EXPRESS. Assim como no caso da TNO, a LKSofWare no foram encontradas solues na documentao e nos fruns de usurios da ferramenta. Para identificar o local exato do erro, uma vez que o EXPRESS Compiler informava apenas uma falha de validade no esquema, eliminouse do arquivo do esquema todas as entidades, mantendose apenas o cabealho e as declaraes de tipo (TYPE). Feito isso, a compilao foi realizada sem erros e a biblioteca Java foi gerada,nessecasocontendoapenasfunesdeacessogenricaseadeclaraodos tiposequivalentesaosTYPEdaEXPRESS. Demonstradaapossibilidadedecompilao,procedeuseumametdicatarefa

de adio gradual de grupos de entidades (ENTITY) relacionadas, e compilaes sucessivas.Oerroinicialnoreapareceuatquefosseminseridasnoesquemaasduas declaraes RULE do final do esquema IFC 2X3:

IfcRepresentationContextSameWCS e IfcSingleProjectInstance. Ficou claro que a EXPRESS Compiler da JSDAI no estava aceitando as duas declaraes,

118

embora a documentao da ferramenta afirme que esse tipo de estrutura pode ser interpretada na compilao. Do ponto de vista do desenvolvimento de algoritmos, o experimentopoderiaterprosseguidosemasduasdeclaraesRULE,mas,mesmoque uma aplicao fosse gerada, ela teria partido de um modelo de dados que no representaria fielmenteo esquemaIFC, que era o princpio do experimento. Embora notenhasidoencontradaexplicaoparaoerro,podeseargumentarqueeletenha sido causado pela caracterstica essencialmente genrica da ferramenta SDAI. Nesse mesmosentido,NoureBeuckeobservamquenohlinguagemdeprogramaona qual as estruturas de dados EXPRESS possam ser mapeadas perfeitamente. As definiesRULE,assimcomoosatributosderivadoseinversos,temsidoumproblema constanteparaaspesquisasnotema(NOUReBEUCKE,2008). 4.4.3Discusso imprprio falar de vantagens verificadas por este experimento, pois as trs

abordagens empregadas para acessar o modelo IFC foram mal sucedidas. Isso no refutadeformaalgumaopotencialdeacessaromodelodeedifcioporestemtodo, apenas indica que mais tempo e preparao sero necessrios em experincias futuras.Almdisso,houveaindaoutroexperimentocomoacessoaomodeloIFC,mas no formato ifcXML, que apresentou resultados melhores e descrito na subseo seguinte. Devese salientar que de modo geral a documentao encontrada foi muito

menosexplicativaqueautilizadanosexperimentosdeacessoaomodeloproprietrio. Foi difcil formar um quadro mais amplo do acesso ao modelo apenas com as informaesdisponveisnaspginasdasduasferramentasutilizadas,eapginadaIAI nesse caso ajudou muito pouco. Tambm no possvel generalizar as concluses desse experimento para as ferramentas comerciais que no puderam ser testadas. Nour, em sua tese de doutorado, relata experincias bem sucedidas de acesso a modelos IFC utilizando a toolbox da EPM Technologies (NOUR, 2006). Em trabalho mais recente, o autor aponta uma alternativa para a compilao do esquema IFC usandooJavaCompilerCompilerJCC(NOUReBEUCKE,2008).Esteumcaminho promissorparadesenvolvimentosfuturos.

119

4.5AcessodemodelosnoformatoifcXML
O ltimo dos experimentos realizados neste trabalho seguiu uma sequncia

similar ao anterior, porm com melhores resultados. Apesar da documentao para orientarodesenvolvimentodeaplicaesparaacessararquivosifcXMLserigualmente escassa,atecnologiaXMLnotadamentemaissimples.Almdisso,documentaese ferramentas genricas, que podem ser adaptadas para o esquema ifcXML so amplamentedisponveis.UmmodeloemformatoifcXMLtembasicamenteosmesmos benefcios de um modelo em formato IFC (SPF), porm descrito de uma maneira diferente. Uma rpida introduo sobre o formato apresentada na subseo seguinte. 4.5.1ifcXML Extensible Markup Language, ou XML, uma linguagem de metadados recomendada pelo World Wide Web Consortium (W3C) como padro para troca de informaesnaWeb(W3C,2008b).Tratasedeumalinguagemtextualparadescrio deinformaes,quepermitereuniremumslocaltantoosdadoscomoosignificado semnticoosmetadados.AocontrriodaEXPRESS,quefoicriadacomopropsito de representar modelos de produtos, a XML essencialmente genrica, e pode ser utilizada para descrever qualquer tipo de informao. Este alto nvel de abstrao possibilitou a disseminao da linguagem, mas um obstculo garantia de consistnciadainformao. Comonotemdescritoreseestruturasfixas,aXMLpoderepresentarqualquer informaodeinfinitasmaneiras,equalquerumadelasservlida,desdequesigam umas poucas regras de sintaxe. Por exemplo, elementos construtivos podem ser chamados <segmento_de_parede> ou <parede>, e podem conter descritores diferentespararepresentarseusatributos.Eainda,aposiodeumaparedepodeser descritaemrelaoaumaorigemfixa,ouentoemrelaosoutrasparedes,epode seguir um sistema cartesiano ou polar. Em resumo, h infinitas formas de descrever corretamente um edifcio, o que para humanos tornase uma questo de semntica rapidamenteresolvidamasparacomputadorespodeexigirprecisosmapeamentosde dados.Pararesolversituaescomoesta,foidesenvolvidoXMLSchemaDefinition,ou

120

XSD.XSDemessnciaumalinguagemdemetametadados.Elapermitedescreveras estruturasquedescrevemestruturasdedados(assimcomoaEXPRESS).Umesquema XSD define tanto os descritores que podem ser utilizados em um arquivo, como as relaes possveis e obrigatrias entre eles. Por exemplo, podese definir que um descritor <janela> tenha que ser obrigatoriamente associado a um descritor <wall>. Ao se criar arquivos XML a partir de esquemas XSD, possvel validar o contedo da informao utilizando o esquema como referncia, e determinar a consistnciadainformao. AifcXMLjustamenteumesquemaXSDparaformataodearquivosXMLde acordo com as estruturas das IFC. No processo de criao do esquema XSD, que conduzido pela IAI e segue a metodologia definida na STEP, as entidades e relacionamentos do esquema EXPRESS IFC somapeados e do origem a descritores XML(NISBETeLIEBICH,2007),quesoentoutilizadospararepresentaroselementos dosmodelosdeedifcios.AprimeiraversodaifcXMLfoilanadaem2001,eapartir de ento, para cada verso do esquema IFC, h uma verso ifcXML correspondente, mapeadaautomaticamente. 4.5.2Definiodoproblema O objetivo de usar a ifcXML permitir a criao de aplicaes para acessar modelossemqueseexijadosprogramadoresodomniodeesquemasEXPRESS,jque h pouca documentao e ferramentas para auxiliar a programao. A prpria IAI reconhece que a linguagem XML tem uma insero muito mais ampla do que seria possvel com a EXPRESS, mesmo se considerado apenas o setor da indstria da construo.Porisso,definiuqueautilizaodasduasformasdeIFCcomplementar, sendoaifcXMLmaisrecomendadaparatransferirporesdainformaodomodelo, enquanto os arquivos SPF, mais compactos, so utilizados para transmitir o modelo completo do edifcio (NISBET e LIEBICH, 2007). ArandaMena e Wakefield vo ainda alm, afirmando que a ifcXML, por ser baseada em uma tecnologia da Web e naturalmente associvel aos recentes desenvolvimentos da web semntica, como a linguagem de ontologias OWL, provavelmente dar origem a uma nova gerao de padresparainteroperabilidadenaconstruo(ARANDAMENAeWAKEFIELD,2006).

121

4.5.3Desenvolvimentodoexperimento Arquivos XML podem ser lidos como strings de texto, mas essa abordagem

demanda um grande esforo de programao. Uma maneira mais eficiente utilizar APIs prprias para a leitura do formato XML, que identificam automaticamente os descritores, atributos e valores. Utilizando essas ferramentas, a conexo com um arquivo XML pode ser feita via parsing ou via binding. Neste experimento, as duas alternativasforamtestadas. Parsing O processo de leitura por parsing pode ser descrito como uma varredura

sequencial da estrutura de ns do arquivo XML. A ferramenta percorre os ns, identificando cada descritor, seus atributos e os valores, alm de associlos hierarquicamente. Aplicaes que utilizam parsing podem tanto executar uma varreduracompletadetodososns,armazenandoosemestruturastemporriaspara um acesso mais rpido, ou executar vrias varreduras, sempre que uma informao precisaserlida.Omesmoseaplicaaoprocessodegravaodasinformaes. As ferramentas utilizadas no experimento de parsing foram a Simple API for

XML SAX e a Document Object Model DOM. A SAX foi a primeira API para XML largamenteadotada,inicialmentedesenvolvidaapenasparaJava(SAXPROJECT,2008). A DOM definida pelo W3C como uma interface independente de linguagem e plataformaquepermiteprogramasescriptsacessaremeatualizaramdinamicamente o contedo e a estrutura dos documentos XML (W3C, 2008a). Tanto a SAX como a DOM so disponveis no pacote de programao Java (JDK), que foi a linguagem de programaoutilizada.AmbaspermitemcriaraplicaesparaacessararquivosifcXML com umas poucas linhas de cdigo. As especificidades dos arquivos ifcXML so irrelevantes para testar o acesso inicial, que pde ser realizado com os prprios exemplos contidos nas pginas das duas aplicaes a nas documentaes sobre Java consultadas(DCIO,2000;SCHILDT,2002;VELOSO,2007;JANDL,2008). Detodososmtodosdescritosnestetrabalhoparaacessardadosdosmodelos de edifcios, este foi sem dvida o mais simples. As funcionalidades para validar o

122

contedo, entretanto, so limitadas. A SAX mais aconselhvel para situaes de leitura de pequenas sequncias de dados, como arquivos de configurao de parmetros de interface, ou criao de pginas da Web. Exceto pelos mtodos que permitemleregravaroarquivoXML,queevitamanecessidadedeprogramarrotinas para manusear e separar strings (tokenizers), a SAX no oferece funcionalidades adicionais.Trabalharcomlongaseinterrelacionadassequnciasdens,quesoocaso dosarquivosifcXML,exigeaprogramaoderotinascomplementaresparaestruturar osdadoseverificaraconsistnciadainformao.Arotinadeestruturaodosdados consistiriaemassociarosdescritoresdoarquivoifcXMLatabelasdedadosouclasses que descrevessem as entidades IFC. Os atributos dos descritores seriam ento convertidosemregistrosdastabelasouatributosdasinstnciasdasclasses.Verificara consistncia da informao exigiria uma rotina para comparar os ns e as relaes entre eles com as definies do esquema XSD da ifcXML. Ou uma sequncia de comparaesseriaprogramadadiretamentenocdigooquetornariadifcilatualizar o programa quando fosse lanada uma nova verso da IFC, ou ento uma classe de comparaopoderiasercriada,paraaqualseriampassadasasdefiniesdoarquivo contendo o esquema. Qualquer que fosse a opo escolhida para a rotina de verificaodaconsistncia,exigiriaumrduotrabalhodeprogramao,quepoucose aproveita da estruturao semntica j inserida no esquema XSD da ifcXML. Considerandoisso,oexperimentocomoacessoviaSAXfoiconsideradoconcludo. OpassoseguintefoiintroduziraDOM,queumaAPImaissofisticadadoquea SAX. Aps ler um documento XML, a DOM cria uma estrutura de objetos representando os seus ns, com mtodos get para permitir o acesso aos seus atributos. Uma vez lido o arquivo, o trabalho realizado sobre essa estrutura de objetos, chamada documentElement, eliminando as mltiplas varreduras da SAX. OutravantagemorelacionamentohierrquicocriadopelaDOM:instnciasdosns relacionados so acessadas diretamente, a partir dos mtodos getChildren e getParent.Dessemodo,asentidadesaninhadasdoarquivoifcXMLsoestruturadas automaticamente, dispensando a rotina que teria que ser criada com a SAX. Ainda haveria,porm,anecessidadedecriarumarotinaparaverificaodaconsistnciada informao contida no arquivo, que dependeria do mapeamento entre um

123

documentElement extrado a partir do arquivo XSD e outro documentElement contendoainformaodomodelo. Os mtodos disponibilizados pela SAX e pela DOM so essencialmente abstratos, o que til para acessar pequenos arquivos e para manter o cdigo do programa flexvel para suportar a evoluo dos esquemas IFC. Porm para trabalhar com estruturas mais complexas, muita programao adicional exigida. Para ilustrar essa dificuldade, considerese o arquivo ifcXML representando um modelo criado no ArchiCAD, apresentado no Apndice F. Aps o parsing, a DOM retorna um objeto documentElement contendo a estrutura hierrquica de ns do arquivo ifcXML. O documentElement composto por elements, que representam ns, atributos e valores do arquivo lido. Cada entidade representada por uma estrutura abstrata, ento para identificar o tipo delas, preciso obter o atributo name dos objetos element.Podesetambmobtercoleesdeentidadesdeummesmotipo,passando paraomtodogetElementsByTagName().EntidadesIFCmaissimplespodemento seracessadasfacilmente.Porexemplo,paraseobteronomedoprimeiropavimento domodelo,utilizaseaexpresso:
Stringname= documentElement.getElementsByTagName(IfcBuildingStorey). item(0).getAttribute(Name);

Porm, as principais entidades IFC, que representam elementos construtivos, soestruturasdevriasentidadesaninhadas.Paraobterascoordenadasdeumponto da forma geomtrica que representa um elemento construtivo, a expresso seria a seguinte:
Realx= documentElement.getElementsByTagName(IfcShapeRepresentation). item(0).getAttribute(Items).getElementsByTagName (IfcPolyline).item(0).getAttribute(Points). getElementsByTagName(IfcCartesianPoint).item(0). getAttribute(Coordinates).getElementsByTagName (IfcLengthMeasure).item(0).getNodeValue();

Expresses abstratas e demasiadamente extensas como esta no recomendadas porque dificultam a documentao do programa e praticamente inviabilizam modificaes. Para evitlas, poderiam ser criadas vrias rotinas que

124

simplificassemacriaodeexpresses.Quantomaissequisersimplificaraexpresso, maistrabalhodeprogramaosernecessrio,atquesechegueaalgodotipo:
Realx=model.getEntity(IfcShapeRepresentation,0). getValue(Item,0).getValue(Points,0). getValue(Coordinates,0).getValue();

Notese que os mtodos foram condensados, mas ainda permaneceram abstratos.Abstraonessenvelumproblemaparamodelosdedadosbemdefinidos einteroperveiscomoasIFC.precisogarantirquetodaainformaoprocessadae produzidapelaaplicaosejavalidvelouseja,queestejadeacordocomoesquema ifcXML. Mantendo a abstrao de dados mostrada, nada impediria a gerao de um arquivo ifcXML com uma entidade chamada minha_parede, caso o programador passasseessevalorparaapropriedadenamedeumobjetonodedaDOM.Aprxima etapa,ento,seriacriarclassesconcretaspararefletirasestruturasdasentidadesIFC e limitar a possibilidade de definies imprprias durante a programao. A classe ifcShapeRepresentation()poderiarepresentaraentidadeIFCdemesmonome, evitando que um erro de digitao produzisse uma entidade invlida. Alm disso, ambientes de programao como o Eclipse possuem ferramentas para auxiliar o processo de gerao e manuteno dos cdigos dos programas. Uma estrutura bem definida de classes uma tima maneira de reduzir erros durante a programao e facilitar o entendimento da estrutura de dados para os programadores. Em ltima instncia,cdigoscontendoerrosdedigitaonosnomesdasclassesouchamadasde mtodos em situaes inadequadas sequer seriam compilados e, portanto, no existiriaapossibilidadedegerararquivosifcXMLnovalidveis. Issoexigiriaadefiniodemaisde620classes,umaparacadaentidadeIFC,e milharesdevariveisemtodosdeacessoencapsulados.Mesmoqueessatarefafosse enfrentadaeconcluda,aatualizaodessaestruturasemprequeoesquemaIFCfosse modificado seria algo desanimador. H, porm, ferramentas para automatizar esse processoasAPIsparamapeamentodemodelosdedados,oubinding. Binding ArquivosifcXMLpodemseracessadosporbinding,omesmoprocessoutilizado pelas ferramentas IFC Toolbox da seo 4.4. No lugar de compilar o esquema IFC
125

original,emEXPRESS,compilaseoesquemaXSDderivadodooriginal,fornecidopela IAI. Neste experimento foi utilizada a ferramenta XMLBeans, da Apache (APACHE, 2008). A XMLBeans gratuita e tem uma rica documentao fornecida pelo desenvolvedor,incluindotutoriaispassoapasso. O processo de binding comea com a compilao do esquema XSD da ifcXML atravsdaaplicaoScomp,fornecidacomopacoteXMLBeans.OesquemaifcXML composto por dois arquivos: ex.xsd e IFC2X3.xsd. O primeiro arquivo contm definies padro de tipos simples de dados e relacionamentos entre entidades EXPRESS, segundo a ISO 10303. O segundo arquivo contm as definies dos tipos complexos de dados e entidades IFC, transpostas para o formato XSD. Ambos os arquivospodemserobtidosgratuitamentenositedogrupodemodelagemdaIAI(BSI, 2008).Parafuncionar,aScompnecessitadopacoteJavaDevelopmentKit(JDK),eda configuraodavariveldeambientePATH,doWindows. Como o esquema XSD da ifcXML muito extenso (21.505 linhas), tentar compillo com a configurao padro da Scomp resulta em um erro de memria (Systemisoutofresources).Entonecessrioalocarmaismemriaparaaaplicao, usando o parmetro MX 1024M na linha de comando. Com esse pequeno ajuste o erro resolvido, e a compilao pode ser completada, gerando duas bibliotecas de classesJava:
orgStandard10303Part28Version2XmlschemaCommon.iso org.iaiTech.ifcXML.ifc2X3.xfinal

Cada biblioteca contm as classes e tipos correspondentes s entidades definidas nos dois arquivos do esquema. Ambas precisam ser importadas pela aplicao Java para o acesso a modelos ifcXML. A partir da importao, classes correspondentes s entidades IFC e classes mais genricas para gerenciar a leitura e gravaodearquivosXMLficamdisponveisparautilizaonocdigo.Comoexposto na subseo anterior, a estrutura bem definida de classes e mtodos conduz o programadornoacessoinformaoIFC,eprotegeaaplicaodeerrosdedigitaoe chamadas de mtodos em situaes inadequadas. Se erros forem cometidos, a compilaoinformaasituaoenoexecutaaaplicao.Essasvantagenspodemser

126

ampliadas usando um ambiente de programao, como o Eclipse, que contm ferramentasdeauxlioprogramaosensveisaocontexto.Aoutragrandevantagem apossibilidadedeverificaodaconsistnciadainformaocontidanoarquivoaser lido,ouseja,avalidaodoXMLdeacordocomaestruturadoesquemaXSD,apartir deummtodogeradoautomaticamente. H duas formas de binding: late e early. No late binding, apenas as classes genricasdeacessoaoarquivoeasqueaceitamparmetrosabstratossoutilizadas. Porexemplo,aclassegetEntity()podeserutilizadaparaacessarqualquerentidade do arquivo. Nesse caso, os atributos tornamse tambm abstratos, e precisam ser identificados atravs de constantes literais. Por exemplo, com o mtodo entity.getAttribute(id).Asdesvantagensdessemtodosoessencialmente asmesmasdautilizaodaSAXedaDOM,emboraoprocessodevalidaosejamais simplificado. O Late binding recomendado para situaes onde o esquema dos arquivosaseremlidospelaaplicaonodefinido.Geraraplicaescomalgograu deabstraopodetornlasmaisflexveisaosmodelosdedados,pormotrabalhode modelagem de processos e programao de rotinas muito mais complexo. Alm disso,paraocasodosmodelosdeedifcioshesquemaspreviamentedefinidos,efaz poucosentidocriaraplicaesexcessivamenteabstratas.Dessemodo,oexperimento realizado neste trabalho adotou a abordagem early binding, pela qual identificase a estruturadedadosdiretamentenocdigodaaplicao,demodomaisconcreto.Em vez de getEntity(), utilizase a classe correspondente entidade ifcXML, como getWall()ougetBeam()porexemplo.Osmtodos,emconsequncia,tambmso identificados,comoentity.getID()nolugardoexemplomostradoanteriormente. Umapequenaaplicaofoipreparadaparalermodelosetestarasbibliotecas geradaspelacompilaodoesquema.AaplicaolumarquivoifcXML,informasea operaodeleiturafoibemsucedida,computaeinformaonmerodeentidadesIFC, emostracomoexemplosoacessoaosdadosdescritosemduasentidades:IfcSitee ifcWallStandardCase.OcdigocompletodaaplicaoapresentadonoApndice G.

127

NosprimeirostestesaaplicaonoconseguiuabrirarquivosifcXMLgerados no ArchiCAD 11 e no ArchiCAD 12. A classe responsvel pela leitura, Iso1030328Document,retornavaerrodemformao.Issoindicavaproblemasde formatao ou caracteres incorretos. De fato, foi observado que os arquivos ifcXML gerados pelo ArchiCAD indicavam a codificao Unicode UTF8 no atributo dos seus cabealhos. Por isso, qualquer elemento do modelo que tenha sido nomeado utilizando caracteres considerados internacionais provocava o erro de formao do arquivo ifcXML. Como no foi possvel identificar uma opo para modificar a codificao durante o processo de exportao do ArchiCAD, foi desenvolvida uma pequenarotinaparasubstituiroatributonoarquivoparaISO88591,acodificao quesuportacaracteresdosalfabetoslatinos.Nostestesseguintesaclassequeliaos arquivosconsiderouosbemformados,eoexperimentopodeprosseguir. Algumas divergncias entre os namespaces do esquema XSD e dos arquivos gerados pelo ArchiCAD exigiram uma sequncia adicional de operaes na abertura dos arquivos. Namespaces diferentes dos definidos no esquema no estavam sendo reconhecidos,pormaisquesepassasseopesparaaclassedeleituradosarquivos. Aps uma srie de tentativas infrutferas, decidiuse por simplesmente substituir os atributosdonprincipaldosarquivoslidospelasversesreconhecidaspeloesquema original (NISBET e LIEBICH, 2007), antes da leitura das entidades. Por exemplo, o namespace definido pelo URI urn:oid:1.0.10303.28.2.1.3, do arquivo gerado peloArchiCADfoisubstitudopor
urn:iso.org:standard:10303:part(28):version(2):xmlschema:common

Dessemodo,aleituradosarquivosfoiconcludaepdeseobterasentidades IFC do modelo. Porm, uma reviso minuciosa sobre as causas desses conflitos, que nopodeserrealizadanodecorrerdessetrabalho,deveserconduzidaparaidentificar as causas desse comportamento. Em teoria, namespaces, que so apenas desambiguadores para o caso de entidades de origens diferentes que tenham o mesmo nome, no deveriam produzir um erro de consistncia. Considerando isso, o problemaencontradodeveserabordadocomoumaquestodeajustedasopesda compilaodoesquemanaXMLBeans.

128

Depois que o arquivo lido, uma estrutura semelhante criada pela DOM disponibilizada para o acesso aos dados do modelo. Nesse momento, porm, foi observado que a facilidade para o acesso aos dados por meio de classes e mtodos completos,correspondendosentidadesIFCnoerapossvel.OesquemaIFCagrupa todas as entidades do modelo do edifcio dentro da entidade chamada UOS (Unit of Serialization). Em outros ramos da indstria, essa entidade rene informao suficiente para a produo de uma unidade seriada. Como podem ser produzidos vriostiposdeunidadesemsrie,podehavervriasentidadesUOSnosesquemas.No casodaIFC,considerasequeoprodutoapenasum,eportantorecomendaseouso de uma nica entidade UOS (LIEBICH e WIX, 2000). Ao gerar aestrutura declasses a partir do esquema ifcXML, a XMLBeans agrupa todas as classes de entidades sob a classeUos().Oagrupamentoemsinoumproblema,poispodesepensarnaclasse como se fosse o prprio modelo, a partir da qual toda a informao seria extrada a partir de mtodos get. No entanto, a compilao no integrou mtodos concretos para acessar as diferentes entidades a partir da classe Uos(). No h o mtodo getIfcSite,porexemplo.Paraacessarasentidades,hapenasummtodoabstrato chamadogetEntityArray,quegeraumamatrizdeobjetosentity(umainterface abstrataparaasentidades).Paradiscernirentreasdiferentesentidadesdamatriz,um processo muito semelhante ao mencionado para o acesso via DOM seria necessrio. Cadaumadasentidadesdamatrizpassariaporumasriedecondicionais,atqueo seutipo,obtidopelomtodogetClass()fossedeterminado. Neste experimento, as vantagens do processo binding sobre o parsing comeam a ser percebidas apenas aps a concluso desse processo de identificao dostiposdecadaentidade.Apartirda,asclassescorrespondentessentidadesIFC tornamse extremamente teis. No cdigo da aplicao, mostrado no Apndice G mostrada a identificao da entidade IfcSite, cujo valor atribudo para uma instncia da classe correspondente, IfcSite(), gerada pela XMLBeans. A classe IfcSite()encapsulamtodosparaacessodosseusatributos,entoparaacessaro graudalongitudedopontoderefernciadoterrenodoprojeto,aexpressoseria:
longdegree= site.getRefLatitude().getLongWrapperArray(0).getLongValue();

129

A latitude completa um tipo de dado composto, definido pela classe compoundPlaneAngleMeasure(), que contm uma matriz de trs nmeros long para armazenar grau, minuto e segundo. Ento, para obter os prximos valores, o parmetro passado para o mtodo getLongWrapperArray seria mudado para 1 e depoispara2. Como se pode ver, os nomes dos mtodos refletem a estrutura da entidade, definidanaEXPRESS,convertidaparaesquemaXSD,eposteriormentecompiladapela XMLBeans. No seria possvel acessar ou atribuir ao elemento site, que do tipo IfcSite,nadaquenofossedeterminadopeloesquema,garantindoaconsistncia da informao e facilitando o trabalho de programao. A ltima questo a ser avaliada era a possibilidade de acesso aos dados de entidades aninhadas. No cdigo apresentado no Apndice G foi identificada uma entidade ifcWallStandardCase. No Apndice F mostrado o arquivo ifcXML utilizado no teste, e na pgina seguinte apenas a entidade lida, para ilustrao. A ifcWallStandardCase formada por vrios atributos, entre eles o Representation, que contm outras entidades IFC aninhadas,quesooselementosqueconstituemarepresentaoformaldaparede.
<IfcWallStandardCaseid="i1714"> <GlobalId>1WfU$nJCrCZO_HrHunLtl5</GlobalId> <OwnerHistory> <IfcOwnerHistoryxsi:nil="true"ref="i1568"/> </OwnerHistory> <Name>SW002</Name> <ObjectPlacement> <IfcLocalPlacementxsi:nil="true"ref="i1711"/> </ObjectPlacement> <Representation> <IfcProductDefinitionShapeid="i1793"> <Representationsex:cType="list"> <IfcShapeRepresentationpos="0"xsi:nil="true"ref="i1753"/> <IfcShapeRepresentationpos="1"xsi:nil="true"ref="i1786"/> </Representations> </IfcProductDefinitionShape> </Representation> <Tag>3B09AD2E868F48F9A480F4F953F6B0E1</Tag> </IfcWallStandardCase>

130

Enquantoasentidadesaninhadassodescritassequencialmente,comoocaso da ifcProductDefinitionShape, possvel acesslas como o resultado de um mtodogetdaclassehierarquicamenteacima.Porexemplo,paraacessaraprimeira entidadeifcShapeRepresentationaninhada,aexpressoseria


wall.getRepresentation().getIfcProductRepresentation(). getRepresentations().getIfcRepresentationArray(0);

Entretanto,

objeto

retornado

por

essa

expresso,

uma

IfcShapeRepresentation, no contm nenhum parmetro. Isso porque tratase apenas de uma referncia ao objeto original, que est descrito em outra parte do arquivo ifcXML. Essa propriedade utilizada pelos esquemas IFC para evitar aninhamentos muito complexos, e tambm para permitir que uma mesma entidade sejautilizadaporvriasoutrassemquesejanecessrioreescrevla(BERARDeSHULZ, 2008).Ocdigoi1753doparmetrorefdaentidadeIfcShapeRepresentation chamadoglobalIDeutilizadoparalocalizaraentidadereferenciada.Essaoperao no automatizada pela XMLBeans, e cabe ao programador realizar a busca percorrendo todas as entidades do arquivo em busca da que contenha o global ID desejado.AexpressomostradaanterioracrescidadoparmetrogetRef()retornao GlobalIDaserlocalizado.Nocdigocompletodaaplicaodetestemostradauma operaoparalocalizaroobjetoreferenciado. Depois de localizada a entidade ifcShapeRepresentation contendo o global ID desejado, podese acessar os seus componentes geomtricos a partir do mtodo getItems(), que resulta uma matriz de elementos de representao. No arquivo utilizado no teste, essa matriz continha apenas um elemento, o polgono (ifcPolyline) que no ArchiCAD daria origem parede atravs de um processo de extruso.AifcPolyline,porsuavez,contmpontoscartesianosquesoacessados pelo mtodo getPoints(). Esse processo de identificao dos elementos e acesso dos seus atributos repetese at que toda a informao a respeito do elemento construtivo tenha sido recolhida. A expresso que retornaria a abscissa do segundo pontogeomtricoqueformaapolilinhaquerepresentaabasedaparedeseriaassim:
doublex=polyline.getPoints().getIfcCartesianPointArray(1). getCoordinates().getIfcLengthMeasureArray(0).getDoubleValue();

131

O experimento permitiu concluir que embora a estruturao por classes correspondentes s entidades IFC seja uma poderosa ferramenta para auxiliar o programador, a distribuio das entidades pelo arquivo ifcXML requer rotinas para facilitar a recomposio da informao. Uma classe recursiva para automatizar o processorepetitivodelocalizaodasentidadesedosseusatributosseriadegrande ajuda. 4.5.4Discusso O acesso a modelos em formato ifcXML foi bem sucedido, e o experimento

permitiu identificar vrias possibilidades para o desenvolvimento de aplicaes para umambienteBIM.AgrandepopularidadedomodelodedadosXMLgarantiumuitas opes de suporte tcnico, um grande nmero de aplicaes de apoio, e a fcil localizaodadocumentaonecessria.Aocontrriodoexperimentocomacessovia IFC em formato SPF, os erros encontrados puderam ser resolvidos ou contornados. Embora no tenha sido gerada uma aplicao com funcionalidades mais avanadas, podesegeneralizarasobservaeseconcluses. OusodaSAXedaDOMrecomendadoapenasparaaplicaesmaissimples,

destinadas por exemplo a acessar pores bastante reduzidas dos modelos de edifcios,como,porexemplo,apenasidentificartodososmateriaisutilizados,masno o seu volume. O uso de uma ferramenta de binding como a XMLBeans resultou em uma estrutura de acesso aos dados mais adequada e flexvel, e a abordagem recomendada por este trabalho. Porm, as funcionalidades da ferramenta binding devem ser estudadas previamente, para evitar a necessidade de longas rotinas de identificao dos tipos das entidades, que tornam o cdigo inflexvel e de difcil manuteno.

132

5
Consideraesfinais

omo primeira contribuio deste trabalho devese citar a proposta de classificao do escopo da modelagem de produto na construo em quatro

nveis de abstrao, no sentido de possibilitar uma aproximao facilitada para um tema de implicaes to amplas. Em seguida, os experimentos realizados demonstraram que a criao de aplicaes para acessar os modelos e gerar informaesapartirdelesvivel.ComexceodoacessoaomodelonoformatoIFC SPF, todos os experimentos foram bem sucedidos no acesso e processamento de dados.Aseguirsofeitasconsideraessobrecadamtododeacessoexperimentado. O modelo de formato proprietrio testado possui mtodos de acesso mais fceis,poishumgrandeinteressedafabricantedosoftwareemdisseminarassuas aplicaes e permitir a sua adaptao a contextos especficos, atravs da especializao das suas funcionalidades por plugins ou scripts. A documentao mais acessvel, e as funes de acesso so mais diretas, permitindo a criao de aplicaesmaisrapidamente.Ostrstiposdeacessosoacriaodescripts,acriao depluginsouaplicaesindependentes. Scripts foram utilizados no experimento descrito na seo 4.1 para gerar objetos representando elementos construtivos, com gerao automtica da documentao projetual. Esse tipo de acesso ao modelo mostrouse bastante til principalmente em situaes onde as unidades de informao so razoavelmente autnomas,eoseucomportamentonoprecisaconsideraratotalidadedomodelodo edifcio. No foram identificados na linguagem utilizada (GDL) meios de aumentar o escopo da sensibilidade ao contexto para, por exemplo, permitir que o objeto reconheaoutrosobjetosesuasrelaesapartirdoscriptdecomportamento. Scripts tambm foram utilizados no experimento apresentado na seo 4.2, paraassociarasdimensesdosobjetosparamtricosainformaescomplementares,

133

gerandoprocessosautomticosdequantificao.Asobservaesrealizadasapartirdo experimento podem ser generalizadas para a quantificao de quaisquer caractersticasrelacionadasaoselementosdoprojetoquepossamserconvertidasem ndices de consumo por exemplo, custo por metro cbico, horas de trabalho por metroquadrado,etc.Scriptsdequantificaopodemassociarestesndicesaosobjetos representando elementos construtivos e tambm aos objetos representando elementosabstratos,comoasreasinternasdoscmodos. Omtododeacessoviapluginfoitestadonaseo4.3,comacriaodeuma pequena aplicao para exportar objetos do ArchiCAD para o sistema Mestre de simulaofsica.ApartirdasbibliotecasfornecidaspelaGraphisoft(GraphisoftAPI) possvelcriaraplicaesemC++eutilizarfunesparaacessoaomodelocomoseele fosseumbancodedadosrelacional.Estemtododeacessooferecemaisflexibilidade e controle do acesso e da interface da aplicao do que o mtodo script. A mesma biblioteca pode ser importada por uma aplicao independente, para acessar o modelo proprietrio da Graphisoft a partir de uma interface independente da execuodoArchiCAD. A desvantagem de utilizar modelos proprietrios a dependncia das fabricantes de softwares e a necessidade de constantes atualizaes das aplicaes complementares,semprequeumanovaversodaaplicaooriginallanada. Modelos neutros, como as IFC, tem como objetivo integrar diferentes aplicaesatravsdousodeumnicomodelodedados.Issoeliminaanecessidadede criao de vrios mapeamentos de dados entre aplicaes diferentes. Os mapeamentos so realizados apenas uma vez, entre o modelo de dados e a nova aplicaosendodesenvolvida.Nestetrabalho,foramtestadosdoismtodosdeacesso aomodeloIFC:viaarquivoSPFeviaarquivoifcXML. OexperimentodeacessoaomodeloIFCporarquivoSPF(seo4.4)foionico a no produzir resultados palpveis. H pouca documentao, e os manuais so confusos, com poucos exemplos. As duas ferramentas gratuitas utilizadas, TNO IFC Engine e LKSoftWare JSDAI, no funcionaram de acordo com o esperado, mesmo depois de seguidas as instrues das fabricantes. Novos testes com as configuraes

134

das ferramentas precisam ser realizados para identificar as causas dos problemas ocorridosnoexperimento.Asvriasferramentascomerciaisdisponveisquerealizamo acessoamodelosIFCemformatoSPFnoforamtestadas,etambmsoopespara aquelesquepretenderemrealizarestudoscomplementares. O acesso a modelos em formato ifcXML, apresentado na seo 4.5 foi bem sucedido, e por utilizar de uma tecnologia mais disseminada (XML), h mais documentaesetutoriaisdisponveis.Foramidentificadastrsformasparaacessaro modelo: lendo o arquivo como uma sequncia de strings, o que exige um trabalho enormedeprogramaoenorecomendado;atravsdeparsing,comferramentas como a DOM ou a SAX, o que reduz o esforo de programao mas no auxilia o programadoraidentificarasentidadesIFC;eatravsdebinding,comacompilaodas entidadesdoesquemaifcXMLegeraodeclassesJavaequivalentes.Essafoiaforma deacessoamodelosifcXMLquegeroumelhoresresultadoseexigiumenoresforode programao.aabordagemrecomendadaparaestudossubsequentes. Emresumo,oacessoaomodelofoibemsucedido,eoprocessamentodestes dados demonstrou interessantes possibilidades para a gerao de aplicaes para a indstria da construo. Entretanto, h pouca documentao disponvel, poucos exemplos e poucos fruns onde as dvidas possam ser dirimidas. H poucos profissionais envolvidos tanto no desenvolvimento do modelo IFC em si como de ferramentasparaacessoaele.Tambmnohversesgratuitasparaasferramentas deacessomaiscitadasemtrabalhossobreotema. Do ponto de vista do desenvolvedor de aplicaes, o acesso aos modelos IFC deveriasermuitomaissimples,considerandoquesepretendequeopadrotornesea principal forma de transmisso de informaes na indstria da construo. Uma das causas da baixa adoo do padro pode ser a dificuldade de gerar rapidamente aplicaes especializadas para o ambiente de interoperabilidade defendido pela IAI. Novas ferramentas devem ser desenvolvidas para facilitar e flexibilizar o acesso, fornecendo comunidade de programadores um modo mais simples para realizar o trabalho.

135

5.1Sugestoparatrabalhosfuturos:metacompilaodeentidades
O processo de binding do esquema ifcXML provou ser de grande valia para o desenvolvimentodeaplicaesparaacessarmodelosdeedifcios.Asclassesgeradas pelo XMLBeans facilitam sensivelmente a extrao dos dados, porm ainda mais til para o programador seria uma ferramenta para acesso em um nvel mais alto. Expressesresultantesdousodessaferramentaseriam,porexemplo:
realx=wall.getLength; realvol=wall.getVolume; realmaterial= wall.getVolume*wall.getComponentsByVolume(cement);

Os modelos proprietrios de edifcios possuem esses mtodos, porque tem estruturas de dados de nvel mais alto, criadas para atender apenas as necessidades dos BIM CADs aos quais se destinam. Os modelos neutros, por outro lado, tem estruturas de dados mais abstratas, originando diferentes possibilidades de combinaes dos dados e unidades de informao. Cada unidade de informao decomposta em vrias outras, at que sejam atingidos os tipos primitivos de dados, atmicos(ex.inteiro,string,real,booleano). A estrutura de dados abstrata flexibiliza o acesso e permite a construo de vriosmapeamentosentreomodeloIFCeomodelodedadosinternodasaplicaes em desenvolvimento. Porm lidar com essa abstrao, como demonstrado na seo 4.5.3,podedificultarmuitoodesenvolvimentodeaplicaes.Ocdigotornasemuito complexoededifcilatualizao,propiciandoosurgimentodeerros. Uma abordagem mais adequada seria associar os benefcios das duas propostas: manter a abstrao de dados mas oferecer a possibilidade de gerao de classesmaisrefinadas,paraacessoemnvelmaisalto.Essasclassesdeveriamfornecer mtodosquelocalizassemeassociassemdadosemdiferentespartesdomodeloou seja, diferentes atributos das vrias entidades relacionadas em um modelo neutro. Esses dados seriam ento processados para dar origem informao em nvel mais alto.

136

Uma soluo para isso seria criar manualmente classes com funcionalidades mais finamente sintonizadas com as informaes que so usualmente mais importantes para o desenvolvimento de aplicaes para a indstria da construo. Entretanto,aquestodograndenmerodeentidadeseatributosaseremrevistos,ea dificuldade de atualizao das classes quando o esquema IFC fosse atualizado surge comosriadesvantagem. Uma outra soluo, mais robusta, seria criar essas classes automaticamente, atravsdeumprocessodemetacompilao,comofazoprprioXMLBeans,ouaindao Java Compiler Compiler. Nesse caso, seriam necessrios dois esquemas: o esquema original IFC, que contm as unidades de informao (entidades, atributos e relacionamentos) e um esquema complementar, para fornecer relacionamentos adicionais entre as entidades e atributos, paraa gerao dos mtodos deacessoem nvelmaisalto. Semntica a questo chave para a criao automtica dessas classes. O esquemaoriginalforneceanaturezadoselementosconstrutivoseseuscomponentes, e o esquema complementar fornece o conhecimento sobre como combinar seus elementos para produzir as informaes em alto nvel. Por exemplo, para originar o mtodo de acesso em alto nvel getVolume, para uma classe que represente a entidadeIfcWall,acompilaoassociariaasdefiniesdoesquemaifcXMLoriginal com outro contendo associaes entre os atributos necessrios para calcular o resultado. Idealmente,oprprioprocessodegeraodoesquemacomplementardeveria ser automatizado, a partir de ontologias que definissem o que uma parede, o que compeumaparede,ecomooconhecimentosobreasuaconstruoagregadono modeloifcXML.Porm,desenvolvimentosnessesentidoaindasomuitopreliminares. Antes que as ontologias permitissem a automatizao da gerao do esquema complementar, essa operao poderia ser realizada em um ambiente grfico. O desenvolvedor selecionaria entidades e atributos que pretendesse associar, e os processamentos a serem realizados pelas classes a serem geradas. Essa informao dariaorigemametaclassesdeconhecimento,eestas,porsuavez,seriamtranscritas

137

para o esquema complementar a ser compilado. Posteriormente, com o desenvolvimentodeontologias,essasoperaesseriamautomatizadas.Oesquemade criaodessasclassesdeacessoemaltonvelseguiriaestasequncia: 1. Em uma aplicao com interface grfica, semelhante s utilizadas com EXPRESSG, RDF ou OWL, o usurio selecionaria atributos de entidades do esquemaifcXML; 2. Estesatributosseriamassociadosporobjetosrepresentandooprocessamento necessrioparaoresultadoesperadoparaaclasse(porexemplo,readaseo multiplicadapelaaltura); 3. Diferentes atributos processamentos so encapsulados em metaclasses que representamoconhecimentosobreamanipulaodedadosemaltonvel; 4. AsmetaclassessotranscritasparaumesquemaXSD; 5. Em um metacompilador, como XMLBeans ou Java CC, oesquema XSDgerado pelaaplicaoeoesquemaifcXMLsocompilados,dandoorigemabibliotecas declassesJava; 6. As bibliotecas so importadas pelas aplicaes que acessaro os modelos de edifcioseprocessaroosseusdados. Desse modo, garantese a flexibilidade dos esquemas, e ao mesmo tempo automatizase consideravelmente a gerao de classes. A biblioteca de classes pode obtida ser utilizada em vrias aplicaes, reduzindo o trabalho de programao. De fato, no necessrio que todos os programadores realizem estas etapas. Podese imaginar vrios nveis de acesso metacompilao, e o desenvolvimento de bibliotecasmodulares,queatendamasdiferentesnecessidadesdosdesenvolvedores deaplicaesparaasdiferentesdisciplinasdaconstruo. Por exemplo, pode ser desenvolvida uma biblioteca genrica para acesso a geometria em alto nvel, que pode ser utilizada por aplicaes orientadas para qualquer disciplina da indstria. Ou ento bibliotecas especializadas, para atuar em conjunto com as primeiras e fornecer funcionalidades prprias de cada disciplina. Podeseimaginarumabibliotecadeclassesqueatuassemcomoprprocessadorpara aplicaesdedesempenhofsico,porexemplo. Desenvolvedores poderiam acessar essas bibliotecas em nvel intermedirio,

fazendoajustenasassociaesourefinandoosprocessamentos,dandoorigemauma

138

bibliotecamaisadequadaparaassuasnecessidades.Finalmente,umnmeromaiorde programadoressequerprecisariarealizaratarefademetacompilao,poisumgrande nmerodebibliotecasdeclassesdeacessoemaltonvelpoderiaserdisponibilizado,e asuacombinaoseriasuficienteparaamaioriadosdesenvolvimentosdeaplicativos deacessoaomodelo. Os trabalhos sobre metamodelagem e compilao de esquemas IFC e sobre reconstruogeomtricaapartirmodelosapresentadosnestadissertaosofontes sugeridasparaoinciodosestudos.

139


Referncias

AMBROZEWICZ,P.H.L.QualidadenaPrtica:ConceitoseFerramentas.Curitiba:ServioNacionalde AprendizagemIndustrialDepartamentoRegionaldoParan,2003. APACHE.XMLBeans(pginadainternet).2008.http://xmlbeans.apache.org/,acessadoem12.2008. ARANDAMENA,G.eWAKEFIELD,R.Interoperabilityofbuildinginformation:mythorreality?In: EuropeanConferenceofProductandProcessModelling,2006,Valencia.London:2006 Disponvelemhttp://mams.rmit.edu.au/lrss7jid7nd4.pdf.Acessadoem:12.2008. ARCHICLUBE.ClubeBrasileirodeUsuriosdeArchiCAD(pginadainternet).2008. www.archiclube.com.br,acessadoem12.2008. AUGENBROE,G.Trendsinbuildingsimulation.BuildingandEnvironment,v.37,n.89,2002,p.891902. Disponvelemhttp://www.sciencedirect.com/science/journal/03601323.Acessadoem: 12.2008. AUTODESK.AutodeskDeveloperCenter(pginadainternet).2008. http://usa.autodesk.com/adsk/servlet/index?siteID=123112&id=472012,acessadoem12.2008. AYRES,C.;AZUMA,F.eSCHEER,S.UtilizaodeCADBIMparaprojetodealvenariadeblocosde concreto.In:WorkshopBrasileirodeGestodoProcessodeProjetosnaConstruode Edifcios,8,2008,SoPaulo.Disponvelem http://www.arquitetura.eesc.usp.br/workshop08/secundarias/ANAIS/Artigo_08.pdf.Acessado em:01.2009. AYRES,C.eSCHEER,S.DiferentesabordagensdousodoCADnoprocessodeprojetoarquitetnico.In: WorkshopBrasileirodeGestodoProcessodeProjetosnaConstruodeEdifcios,7,2007, Curitiba.Disponvelemhttp://www.cesec.ufpr.br/workshop2007/Artigo57.pdf.Acessadoem: 12.2008. AYRES,C.;SCHEER,S.;AZUMA,F.eBEBER,M.CADBIMrequirementsformasonrydesignprocessof concreteblocks.In:CIBW78InternationalConferenceonInformationTechnologyon InformationTechnology,25,2008,Santiago.4047.Acessadoem:12.2008. BANDURSKI,A.E.eJEFFERSON,D.K.Datadescriptionforcomputeraideddesign.In:International ConferenceonManagementofData,3,1975,SanJose.NewYork:1975193202.Disponvel em http://portal.acm.org/citation.cfm?id=500080.500107&coll=portal&dl=ACM&CFID=15982252& CFTOKEN=17235559.Acessadoem:12.2008. BEALL,C.MasonryDesignandDetailing.5.ed.NewYork:McGrawHill,2003,640p. BDARD,C.OntheadoptionofcomputingandITbyindustry:thecaseforintegrationinearlybuilding design.In:IntelligentComputinginEngineeringandArchitecture,13,2006,Ascona.Berlin: 20066273.Disponvelemhttp://www.springerlink.com/content/m524h81343w8760l/. Acessadoem:12.2008. BERARD,O.eSHULZ,J.GeometricalcorrectionandconversionofIFC2X3models.Copenhagen,2008, 127p.Dissertao(Mestrado).ITUniversityofCopenhagen. BERTEZINI,A.L.Mtodosdeavaliaodoprocessodeprojetodearquiteturanaconstruode edifciossobaticadagestodaqualidade.SoPaulo,2006,208p.Dissertao(Mestrado). EscolaPolitcnica,UniversidadedeSoPaulo.

140

BEUCKE,K.;BRKLIN,B.;HANFF,J.eSCHAPER,D.Applicationsofvirtualdesignandconstructioninthe buildingindustry.StructuralEngineeringInternational,v.15,n.3,2005,p.129134.Disponvel emhttp://www.ingentaconnect.com/content/iabse/sei.Acessadoem:12.2008. BIRX,G.W.HowBuildingInformationModellingchangesarchitecturalpractice.TheAmericanInstitute ofArchitectsBestPractices,2006.Disponvelemhttp://www.aia.org/bestpractices_index. Acessadoem:22.11.2006. BJRK,B.C.Aconceptualmodelofspaces,spaceboundariesandenclosingstructures.Automationin Construction,v.1,n.3,1992,p.193214.Disponvelem http://www.sciencedirect.com/science/journal/09265805.Acessadoem:12.2008. BRUNNERMEIER,S.B.eMARTIN,S.A.InteroperabilityCostAnalysisoftheUSAutomotiveSupply ChainFinalReport.ResearchTriangleInstitute,1999,93p. BSI.BuildingSmartInternational(pginadainternet).2008.http://www.buildingsmart.com/,acessado em12.2008. CAMBIAGHI,H.DiretrizesGeraisparaaIntercambialidadedeprojetoscomCAD.SoPaulo:Pini,2000, 44p. CHASTAIN,T.;KALAY,Y.E.ePERI,C.Squarepeginaroundholeorhorselesscarriage?Reflectionsonthe useofcomputinginarchitecture.AutomationinConstruction,v.11,n.2,2002,p.237248. Disponvelemhttp://www.sciencedirect.com/science/journal/09265805.Acessadoem: 12.2008. COONS,S.A.Anoutlineoftherequirementsforacomputeraideddesignsystem.In:SpringJoint ComputerConference,1963,Detroit.NewYork:1963299304.Disponvelem http://doi.acm.org/10.1145/1461551.1461588.Acessadoem:11.2008. CSIRO.LCADesign(pginadainternet).2008.http://www.cmmt.csiro.au/brochures/tech/lcadesign/, acessadoem01.2009. DCIO,O.C.XML.SoPaulo:Novatec,2000,96p. EASTMAN,C.M.Generalpurposebuildingdescriptionsystems.ComputerAidedDesign,v.8,n.1,1976, p.1726.Disponvelemhttp://www.sciencedirect.com/science/journal/00104485.Acessado em:11.2008. EASTMAN,C.M.Informationanddatabasesindesign.DesignStudies,v.1,n.3,1980a,p.146152. Disponvelemhttp://www.sciencedirect.com/science/journal/0142694X.Acessadoem: 11.2008. EASTMAN,C.M.Prototypeintegratedbuildingmodel.ComputerAidedDesign,v.12,n.3,1980b, p.115119.Disponvelemhttp://www.sciencedirect.com/science/journal/00104485.Acessado em:11.2008. EASTMAN,C.M.ArchitecturalCAD:atenyearassessmentofthestateoftheart.ComputerAided Design,v.21,n.5,1989,p.289292.Disponvelem http://www.sciencedirect.com/science/journal/00104485.Acessadoem:11.2008. EASTMAN,C.M.TheevolutionofCAD:integratingmultiplerepresentations.BuildingandEnvironment, v.26,n.1,1991,p.1723.Disponvelem http://www.sciencedirect.com/science/journal/03601323.Acessadoem:12.2008. EASTMAN,C.M.Modelingofbuildings:evolutionandconcepts.AutomationinConstruction,v.1,n.2, 1992,p.99109.Disponvelemhttp://www.sciencedirect.com/science/journal/09265805. Acessadoem:12.2008. EASTMAN,C.M.BuildingProductModels:ComputerEnvironmentsSupportingDesignand Construction.BocaRaton:CRCPress,1999,424p. EASTMAN,C.M.eHENRION,M.Glide:alanguagefordesigninformationsystems.In:SIGGRAPH InternationalConferenceonComputerGraphicsandInteractiveTechniques,4,1977,SanJose. NewYork:19772333.Disponvelemhttp://portal.acm.org/citation.cfm?doid=563858.563863. Acessadoem:11.2008.

141

EASTMAN,C.M.eHENRION,M.Geometricmodellingasurvey.ComputerAidedDesign,v.11,n.5, 1979,p.253272.Disponvelemhttp://www.sciencedirect.com/science/journal/00104485. Acessadoem:12.2008. EASTMAN,C.M.eKUTAY,A.Transactionmanagementindesigndatabases.In:MITJSMEWorkshop, 1989,Cambridge.Berlin:1991334351.Disponvelem http://www.springerlink.com/content/75007584l378r29v/fulltext.pdf.Acessadoem:12.2008. EASTMAN,C.M.;SACKS,R.eLEE,G.FunctionalmodelinginparametricCADsystems.In:ACADIA Conference2004,2004,Toronto.Disponvelem http://bim.arch.gatech.edu/data/reference/Functional%20modeling%20in%20parametric%20C AD%20systems_GCAD2004.pdf.Acessadoem:12.2008. EASTMAN,C.M.;TEICHOLZ,P.;SACKS,R.eLISTON,K.BIMHandbook:AGuidetoBuildingInformation ModelingforOwners,Managers,Designers,EngineersandContractors.Hoboken:Wiley, 2008,490p. FABRICIO,M.M.;BAA,J.L.eMELHADO,S.B.Estudodaseqnciadeetapasdoprojetonaconstruo deedifcios:cenrioseperspectivas.In:ENCONTRONACIONALDEENGENHARIADE PRODUO,18,1998,Niteri,RJ.Disponvelem http://www.eesc.sc.usp.br/sap/docentes/fabricio/ENEGEP98ES_Fluxo_Proj.pdf.Acessadoem: 20.11.2006. FABRICIO,M.M.;MELHADO,S.B.eBAA,J.L.BriefReflectiononImprovementofDesignProcess EfficiencyinBrazilianBuildingProjects.In:InternationalGroupforLeanConstruction Conference,8,1999,Berkeley.345356.Disponvelem http://www.iglc.net/conferences/1999/Papers/.Acessadoem:12.2008. FAVRE,D.eCITHERLET,S.EcoBat:Adesigntoolforassessingenvironmentalimpactsofbuildingsand equipmentBuildingSimulation,v.1,n.1,2008,p.8394.Disponvelem http://www.springerlink.com/content/xg23588701l273ql/.Acessadoem:12.2008. FENVES,S.J.ACoreProductModelforRepresentingDesignInformationNISTIR6736.BocaRaton: NISTNationalInstituteofStandardsandTechnology,2002,424p. FOWLER,J.STEPforDataManagementExchangeandSharing.Twickenham:TechnologyAppraisals, 1996,222p. GALLAGER,R.G.eMITTER,S.K.FromServoLoopstoFiberNets.MassachusettsInstituteofTechnology TheLaboratoryforInformationandDecisionSystems,Cambridge:1990. GALLAHER,M.P.;O'CONNOR,A.C.;JR.,J.L.D.eGILDAY,L.T.CostAnalysisofInadequate InteroperabilityintheU.S.CapitalFacilitiesIndustry.ResearchTriangleInstitute,2004,210p. GIELINGH,W.Anassessmentofthecurrentstateofproductdatatechnologies.ComputerAided Design,v.40,n.7,2008,p.750759.Disponvelem http://www.sciencedirect.com/science/journal/00104485.Acessadoem:12.2008. GINGERICH,J.Z.Computergraphicsbuildingdefinitionsystem.In:AnnualACMIEEEDesignAutomation Conference,10,1973,Piscataway:1973Disponvelem http://portal.acm.org/toc.cfm?id=800124&type=proceeding&coll=portal&dl=ACM&CFID=1539 4702&CFTOKEN=69261272.Acessadoem:12.2008. GRABOWSKI,H.eANDERL,R.Integrationofthedesignandmanufactureplanningprocessbasedona CADsystemwithatechnologyorientedvolumemodel.Computers&Graphics,v.7,n.2,1983, p.125141.Disponvelemhttp://www.sciencedirect.com/science/journal/00978493.Acessado em:12.2008. GRAPHISOFT.ArchiCAD10GDLReferenceGuide.Graphisoft,2006,320p. GRAPHISOFT.ArchiCAD(pginadainternet).2008a.http://www.graphisoft.com/products/archicad/, acessadoem12.2008. GRAPHISOFT.ArchiCAD12GDLReferenceGuide.Graphisoft,2008b,336p.

142

GRAPHISOFT.GraphisoftAPIDevelopmentKitDocumentation(pginadainternet).2008c. http://www.graphisoft.com/support/developer/documentation/DocAPIDevKit.html,acessado em01.2009. GRAPHISOFT.GraphisoftApplicationProgrammingInterfaceDeveloperProgram(pginadainternet). 2008d.http://www.graphisoft.com/support/developer/api.html,acessadoem01.2009. GRAPHISOFT.GraphisoftDeveloperCenter(pginadainternet).2008e. http://www.graphisoft.com/support/developer/,acessadoem12.2008. GRAPHISOFT.GraphisoftGDLTechnicalStandardsv2.0(pginadainternet).2008f. http://www.graphisoft.com/ftp/techsupport/documentation/developer_docs/BasicLibraryDoc/ 10/LibDevGuide/TechnicalStandards.html,acessadoem12.2008. HANNUS,M.Implementationofobjectorientedproductmodelapplications.In:CIBW78Workshop: TheComputerIntegratedFuture,1991,Eidenhoven.Disponvelemhttp://itc.scix.net/cgi bin/works/Show?w78199110.Acessadoem:12.2008. HARTMANN,T.eFISCHER,M.ApplicationsofBIMandhurdlesforwidespreadadoptionofBIM2007 AISCACCLeConstructionRoundtableEventReport.Stanford:CIFE/StanfordUniversity,2008, 20p. HAYNIE,M.N.Tutorial:therelationaldatamodelfordesignautomation.In:AnnualACMIEEEDesign AutomationConference,20,1983,MiamiBeach.NewYork:1983599607.Disponvelem http://portal.acm.org/citation.cfm?id=800032.800731&coll=GUIDE&dl=GUIDE&CFID=14803425 &CFTOKEN=31163327.Acessadoem:12.2008. HIETANEN,J.eDROGEMULLER,R.ApproachestouniversitylevelBIMeducation.In:IABSEConference, 2008,Helsinki. HOFFMANN,C.M.eJOANARINYO,R.Parametricmodeling(in:HandbookofComputerAided GeometricDesign).Amsterdam:Elsevier,2002,519541p. HOSAKA,M.eKIMURA,F.AmodelbasedapproachtoCAD/CAMintegration.ComputersinIndustry,v. 14,n.1,1990,p.3542.Disponvelem http://www.sciencedirect.com/science/journal/01663615.Acessadoem:12.2008. HOWARD,R.eBJRK,B.C.UseofstandardsforCADlayersinbuilding.AutomationinConstruction,v. 16,n.3,2007,p.290297Disponvelem http://www.sciencedirect.com/science/journal/09265805.Acessadoem:12.2008. HOWARD,R.eBJRK,B.C.BuildinginformationmodellingExperts'viewsonstandardisationand industrydeployment.AdvancedEngineeringInformatics,v.22,n.2,2008,p.271280. Disponvelemhttp://dx.doi.org/10.1016/j.aei.2007.03.001.Acessadoem:11.2008. HVAM,L.Aprocedurefortheapplicationofproductmodelling.InternationalJournalofProduction Research,v.39,n.5,2001,p.873885.Disponvelem http://www.ingentaconnect.com/content/tandf/tprs/2001/00000039/00000005/art00004. Acessadoem:12.2008. IAI.IFCToolsforDevelopers(pginadainternet).2008a.http://www.iai international.org/software/Tools%20for%20IFC%20developers.html,acessadoem12.2008. IAI.IFDLibraryWhitePaper.IAI,2008b,9p. IBRAHIM,M.;KRAWCZYK,R.eSCHIPPOREIT,G.CADsmartobjects:potentialsandlimitations.In: InternationaleCAADeConference,21,2003,Graz.547551.Disponvelem http://www.iit.edu/~krawczyk/miecad03.pdf.Acessadoem:12.2008. IBRAHIM,M.;KRAWCZYK,R.eSCHIPPOREIT,G.TwoApproachestoBIM:AComparativeStudy.In: eCAADeConference,22,2004,Copenhagen.610616.Disponvelem http://cumincad.scix.net/cgibin/works/Show?2004_610.Acessadoem:12.2008. ISIKDAG,U.;AOUAD,G.;UNDERWOOD,J.eWU,S.Buildinginformationmodels:areviewonstorage andexchangemechanisms.In:CIBW78InternationalConferenceonInformationTechnology

143

onInformationTechnology,24,2007,Maribor.135144.Disponvelem http://itc.scix.net/data/works/att/w782007020068bIsikdag.pdf.Acessadoem:12.2008. JANDL,P.Java6.SoPaulo:Novatec,2008,144p. JOHNSON,T.E.SketchpadIIIacomputerprogramfordrawinginthreedimensions.In:SpringJoint ComputerConference,1963,Detroit.NewYork:1963347353.Disponvelem http://portal.acm.org/citation.cfm?doid=1461551.1461592.Acessadoem:11.2008. KALAY,Y.E.AdatabasemanagementapproachtoCAD/CAMsystemsintegration.In:AnnualACMIEEE DesignAutomationConference,22,1985a,LasVegas.NewYork:1985111116.Disponvelem http://portal.acm.org/citation.cfm?id=317843.Acessadoem:12.2008. KALAY,Y.E.Redefiningtheroleofcomputersinarchitecture:fromdrafting/modellingtoolsto knowledgebaseddesignassistants.ComputerAidedDesign,v.17,n.7,1985b,p.319328. Disponvelemhttp://www.sciencedirect.com/science/journal/00104485.Acessadoem: 12.2008. KALAY,Y.E.Theimpactofinformationtechnologyondesignmethods,productsandpractices.Design Studies,v.27,n.3,2005,p.357380.Disponvelem http://www.sciencedirect.com/science/journal/0142694X.Acessadoem:12.2008. KIM,I.eSEO,J.DevelopmentofIFCmodelingextensionforsupportingdrawinginformationexchangein themodelbasedconstructionenvironment.JournalofComputinginCivilEngineering,v.22,n. 3,2008,p.159169.Disponvelemhttp://cedb.asce.org/cgi/WWWdisplay.cgi?0803518. Acessadoem:12.2008. KIMURA,F.;DAWABE,S.eSATA,T.AstudyonproductmodellingforintegrationofCAD/CAM. ComputersinIndustry,v.5,n.3,1984,p.239252.Disponvelem http://www.sciencedirect.com/science/journal/01663615.Acessadoem:12.2008. KIVINIEMI,A.TenyearsofIFCdevelopmentwhyarewenotyetthere?Espoo:VTT,2006,43p. KIVINIEMI,A.;TARANDI,V.;KARLSHOJ,J.;BELL,H.eKARUD,O.J.Reviewofthedevelopmentand implementationofIFCcompatibleBIM.Erabuild,2008,128p. KOWALTOWSKI,D.C.C.K.;CELANI,M.G.C.;MOREIRA,D.D.C.;PINA,S.A.M.G.;RUSCHEL,R.C.;SILVA, V.G.D.;LABAKI,L.C.ePETRECHE,J.R.D.Reflexosobremetodologiasdeprojeto arquitetnico.AmbienteConstrudo,v.6,n.2,2006,p.0719.Disponvelem http://www.antac.org.br/ambienteconstruido/.Acessadoem:20.11.2006. KRAUSE,F.L.;KIMURA,F.;KJELLBERG,T.eLU,S.C.Productmodelling.CIRPAnnalsManufacturing Technology,v.42,n.2,1993,p.695706.Disponvelem http://www.sciencedirect.com/science/journal/00078506.Acessadoem:12.2008. KVAN,T.Collaborativedesign:whatisit?AutomationinConstruction,v.9,n.4,2000,p.409415 Disponvelemhttp://www.sciencedirect.com/science/journal/09265805.Acessadoem: 12.2008. LACROIX,M.ePIROTTE,A.DatastructuresforCADobjectdescription.In:AnnualACMIEEEDesign AutomationConference,18,1981,Nashville.NewYork:1981653659.Disponvelem http://portal.acm.org/citation.cfm?id=802371.Acessadoem:12.2008. LAM,P.T.I.;WONG,F.W.H.eCHAN,A.P.C.Contributionsofdesignerstoimprovingbuildabilityand constructability.DesignStudies,n.27,2005,p.457479.Disponvelem http://www.elsevier.com/locate/destud.Acessadoem:20.11.2006. LEE,G.;SACKS,R.eEASTMAN,C.M.Specifyingparametricbuildingobjectbehavior(BOB)forabuilding informationmodelingsystem.AutomationinConstruction,v.15,n.6,2006,p.758776 Disponvelemhttp://www.sciencedirect.com/science/journal/09265805.Acessadoem: 12.2008. LIEBICH,T.;ADACHI,Y.;FORESTER,J.;HYVARINEN,J.;KARSTILA,K.eWIX,J.IndustryFoundationClasses IFC2xEdition3.IAI,2006. LIEBICH,T.eWIX,J.IFCTechnicalGuide.IAI,2000,46p.

144

LKSOFTWARE.ExpressCompiler(pginadainternet).2008a.http://www.jsdai.net/eclipse/express compiler,acessadoem12.2008. LKSOFTWARE.JSDAIExpressAPI(pginadainternet).2008b.http://www.jsdai.net/,acessadoem 12.2008. LOVE,P.E.D.;IRANI,Z.eEDWARDS,D.J.Researshingtheinvestmentofinformationtechnologyin construction:anexaminationofevaluationpractices.AutomationinConstruction,n.14,2005, p.569582.Disponvelemhttp://www.elsevier.com/locate/autcon.Acessadoem:09.12.2006. MAHDAVI,A.Computationalbuildingmodels:themeandfourvariations.In:InternationalIBPSA Conference,8,2003,Eindhoven.317.Disponvelem http://www.ibpsa.org/proceedings/BS2003/BS03_0003_18.pdf.Acessadoem:12.2008. MARTINS,O.S.Determinaodopotencialdeseqestrodecarbononarecuperaodematasciliares naregiodeSoCarlos,SP.SoCarlos,2004,161p.Tese(Doutorado).CentrodeCincias BiolgicasedaSade,UniversidadeFederaldeSoCarlos. MELHADO,S.B.Qualidadedoprojetonaconstruodeedifcios:aplicaoaocasodasempresasde incorporaoeconstruo.SoPaulo,1994,310p.Tese(Doutorado).EscolaPolitcnica UniversidadedeSoPaulo. MELHADO,S.B.eAQUINO,J.P.R.D.PerspectivasdautilizaogeneralizadadeProjetospara Produonaconstruodeedifcios.In:GESTODOPROCESSODEPROJETONACONSTRUO DEEDIFCIOS,2001,SoCarlos,SP.Disponvelem http://www.eesc.sc.usp.br/sap/workshop/anais/PERSPECTIVAS_DA_UTILIZACAO_GENERALIZA DA_DE_PROJ_PARA_PRODUCAO.pdf.Acessadoem:20.11.2006. MELHADO,S.B.eGRILO,L.M.Desafioseoportunidadesparaosescritriosdeprojetofrentes tendnciasparaagestodoprocessodeprojetoedoempreendimento.BoletimTcnicoda EscolaPolitcnicadaUSPDepartamentodeEngenhariadeConstruoCivil,n.336,2003. Disponvelem http://alunospos.pcc.usp.br/leonardo.grilo/Boletim_t%25C3%25A9cnico_com_mudan%25C3% 25A7as.pdf.Acessadoem:20.11.2006. MIKALDO,J.Estudocomparativodoprocessodecompatibilizaodeprojetosem2De3Dcomusode TI.Curitiba,2006,150p.Dissertao(Mestrado).ProgramadePsGraduaoemConstruo Civil,UniversidadeFederaldoParan. MOUM,A.AframeworkforexploringtheICTimpactonthearchitecturaldesignprocess.Electronic JournalofInformationTechnologyinConstruction,v.11,2006,p.409425.Disponvelem http://www.itcon.org/data/works/att/2006_30.content.07890.pdf.Acessadoem:12.2008. NASCIMENTO,L.A.eSANTOS,E.T.Barreirasparaousodatecnologiadainformaonaindstriada construocivil.In:WORKSHOPNACIONALGESTODOPROCESSODEPROJETONA CONSTRUODEEDIFCIOS,2,2002,PortoAlegre,RS.Disponvelem http://www.infohab.org.br.Acessadoem:20.11.2006. NASCIMENTO,L.A.D.eSANTOS,E.T.Aindstriadaconstruonaeradainformao.Ambiente Construdo,v.3,n.1,2003,p.6981.Disponvelem http://www.antac.org.br/ambienteconstruido/pdf/revista/artigos/Doc11178.pdf.Acessadoem: 12.2008. NEMETSCHEK.Allplan(pginadainternet).2008.http://www.allplan.com/,acessadoem12.2008. NIBS.NationalBuildingInformationModelingStandard.NationalInstituteofBuildingSciences,2007, 183p. NICHOLSONCOLE,D.IntroductiontoObjectMaking.2.ed.Graphisoft,2004,124p. NILSSON,P.eFAGERSTRM,B.Managingstakeholderrequirementsinaproductmodellingsystem. ComputersinIndustry,v.57,n.2,2006,p.167177.Disponvelem http://www.sciencedirect.com/science/journal/01663615.Acessadoem:12.2008.

145

NISBET,N.eLIEBICH,T.ifcXMLImplementationGuide.2.ed.InternationalAllianceforInteroperability ModelingSupportGroup,2007,50p. NOUR,M.M.AFlexibleModelforIncorporatingConstructionProductDataintoBuildingInformation Models.Weimar,2006,186p.Tese(Doutorado).ConstructionInformatics,Bauhaus. NOUR,M.M.eBEUCKE,K.AnOpenPlatformforProcessingIFCModelVersions.TsinghuaScienceand Technology,v.13,n.S1,2008,p.126131.Disponvelem http://qhxb.lib.tsinghua.edu.cn/myweb/english/2008/2008es1/126131.pdf.Acessadoem: 12.2008. NOVAES,C.C.Diretrizesparagarantiadaqualidadedoprojetonaproduodeedifcioshabitacionais. SoPaulo,1996,280p.Tese(Doutorado).EscolaPolitcnica,UniversidadedeSoPaulo. PAULA,A.T.D.eMELHADO,S.B.Avaliaodoimpactopotencialdaverso2000dasnormasISO9000 nagestoecertificaodaqualidade:ocasodasempresasconstrutoras.BoletimTcnicoda EscolaPolitcnicadaUSPDepartamentodeEngenhariadeConstruoCivil,n.395,2005. Disponvelemhttp://www.infohab.org.br.Acessadoem:03.12.2006. PAZLAR,T.eTURK,Z.Interoperabilityinpractice:geometricdataexchangeusingtheIFCstandard. InternationalJournalofProductionResearch,v.13,2008,p.362380.Disponvelem http://www.itcon.org/data/works/att/2008_24.content.00881.pdf.Acessadoem:12.2008. PEANSUPAP,V.eWALKER,D.H.T.Factorsenablinginformationandcommunicationtechnology diffusionandactualimplementationinconstructionorganisations.ElectronicJournalof InformationTechnologyinConstruction,v.10,n.14,2005,p.193218.Disponvelem http://www.itcon.org/2005/14/.Acessadoem:09.12.2006. PELS,H.J.Productandprocessdatamodelling.ComputersinIndustry,v.31,n.3,1996,p.191194. Disponvelemhttp://www.sciencedirect.com/science/journal/01663615.Acessadoem: 12.2008. PENTTILA,H.ThestateoftheartofFinnishbuildingproductmodellingmethodology.In:Computer AidedArchitecturalDesignFuturesConference,11,2005,Viena.Viena225240.Disponvelem http://cumincad.scix.net/data/works/att/cf2005_2_55_233.content.pdf.Acessadoem: 12.2008. PFEIFER,G.;RAMCKE,R.;ACHTZIGER,J.eZILCH,K.MasonryConstructionManual.Berlin:Birkhauser, 2001,392p. PINI.TCPOTabelasdeComposiodePreosparaOramentos.12.ed.SoPaulo:Pini,2003,441p. PLESSIS,C.D.Agenda21forSustainableConstructioninDevelopingCountries.Pretoria:CSIR,2001,55 p. PR.SimaProLCA(pginadainternet).2008.http://www.pre.nl/simapro/simapro_lca_software.htm, acessadoem12.2008. PRUDNCIO,L.R.;OLIVEIRA,A.L.D.eBEDIN,C.A.AlvenariaEstruturaldeBlocosdeConcreto. Florianpolis:Palotti,2002,208p. PSQ.ProgramaSetorialdaQualidade:SetordeProjetos.SoPaulo:ASBEA/ABECE/ABRASIP/IAB SP/IE/SINAECO/SINDINSTALAO,1997. RAMALHO,M.A.eCORRA,M.R.S.ProjetodeEdifciosdeAlvenariaEstrutural.SoPaulo:Pini,2003, 174p. RIVARD,H.Asurveyontheimpactofinformationtechnologyonthecanadianarchitecture,engineering andconstructionindustry.ElectronicJournalofInformationTechnologyinConstruction,v.5, n.3,2000,p.3756.Disponvelemhttp://itcon.org/2000/3/.Acessadoem:09.12.2006. ROAF,S.ClosingtheLoop:BenchmarksforSustainableBuildings.London:RibaPublications,2004,532 p. ROAF,S.eDAY,C.EcoHouse:Adesignguide.Oxford:ArchitecturalPress,2001.

146

ROBINSON,C.E.Adatastructureforacomputeraideddesignsystem.In:AnnualACMIEEEDesign AutomationConference,3,1966,NewYork.NewYork:196614.114.9.Disponvelem http://portal.acm.org/citation.cfm?id=810786.Acessadoem:12.2008. ROMANO,F.V.;BACK,N.eOLIVEIRA,R.D.Aimportnciadamodelagemdoprocessodeprojetoparao desenvolvimentointegradodeedificaes.In:GESTODOPROCESSODEPROJETONA CONSTRUODEEDIFCIOS,2001,SoCarlos,SC.Disponvelemhttp://www.infohab.org.br. Acessadoem:20.11.2006. ROSS,D.T.Computeraideddesign(researchsummary).CommunicationsoftheACM,v.4,n.5,1961, p.235.Disponvelemhttp://portal.acm.org/citation.cfm?doid=366532.366554.Acessadoem: 11.2008. ROSS,D.T.eRODRIGUEZ,J.E.Theoreticalfoundationsofthecomputeraideddesignsystem.In:Spring JointComputerConference,1963,Detroit.NewYork:1963305322.Disponvelem http://portal.acm.org/citation.cfm?doid=1461551.1461589.Acessadoem:12.2008. SACKS,R.eBARAK,R.Impactofthreedimensionalparametricmodelingofbuildingsonproductivityin structuralengineeringpractice.AutomationinConstruction,v.17,n.4,2007,p.439449 Disponvelemhttp://www.sciencedirect.com/science/journal/09265805.Acessadoem: 12.2008. SACKS,R.;EASTMAN,C.M.eLEE,G.Parametric3Dmodelinginbuildingconstructionwithexamples fromprecastconcreteAutomationinConstruction,v.13,n.3,2004,p.291312.Disponvelem http://www.sciencedirect.com/science/journal/09265805.Acessadoem:12.2008. SAXPROJECT.SAXSimpleAPIforXML(pginadainternet).2008.http://www.saxproject.org/, acessadoem12.2008. SCHEER,S.;ITO,A.;AYRES,C.;AZUMA,F.eBEBER,M.ImpactosdousodosistemaCADgeomtricoe dousodosistemaCADBIMnoprocessodeprojetoemescritriosdearquitetura.In: WorkshopBrasileirodeGestodoProcessodeProjetosnaConstruodeEdifcios,7,2007, Curitiba.Disponvelemhttp://www.cesec.ufpr.br/workshop2007. SCHILDT,H.Java2TheCompleteReference.5.ed.NewYork:McGrawHill,2002,1156p. SCHMID,A.L.Simulaodedesempenhotrmicoemmltiplaszonas:mestre,umsistemabrasileiro nalinguagemJava.In:EncontroNacionaldeConfortonoAmbienteConstrudo,6,2001,So Pedro.Disponvelemhttp://www.infohab.org.br.Acessadoem:01.2009. SCHMID,A.L.Simulaodaluznatural:combinaodosalgoritmosderaytracingeradiosidadee aplicaesnaarquitetura.AmbienteConstrudo,v.4,n.3,2004,p.5159.Disponvelem http://www.antac.org.br/ambienteconstruido/pdf/revista/artigos/Doc117117.pdf.Acessado em:01.2009. SCHMID,A.L.AcsticaarquitetnicaeauralizaonosistemaMestredesimulaodeedifcios.In: EncontroAnualdaSociedadeBrasileiradeAcstica,27,2006,SoPaulo. SCHMID,A.L.eAYRES,C.TestesiniciaisdosistemademodelagemArchiCADcomoprprocessador paraosistemaMestredeanlisetrmica,lumnicaeacsticadeedificaes.In:Encontro NacionaldeConfortonoAmbienteConstrudo,9,2007,OuroPreto.16971702. SCLCI.SwissCentreforLifeCycleInventoriesTheEcoinventDatabase(pginadainternet).2008. http://www.ecoinvent.org/,acessadoem12.2008. SCRASTEP.STEPApplicationHandbookISO10303Version3.NorthCharleston:SCRA,2006,175p. SOUZA,U.E.L.D.Comoreduzirperdasnoscanteiros.SoPaulo:Pini,2005,128p. SPERLING,D.M.Oprojetoarquitetnico,novastecnologiasdeinformaoeomuseuGuggenheinde Bilbao.In:WorkshopNacionalGestodoProcessodeProjetonaConstruodeEdifcios,2, 2002,PortoAlegre.Disponvelemhttp://www.eesc.sc.usp.br/sap/projetar/files/A038.pdf. Acessadoem:12.2008.

147

STOUFFS,R.Constructingdesignrepresentationsusingasortalapproach.AdvancedEngineering Informatics,v.22,n.1,2008,p.7189.Disponvelem http://www.sciencedirect.com/science/journal/14740346.Acessadoem:12.2008. SUTHERLAND,I.E.Sketchpadamanmachinegraphicalcommunicationsystem.In:SpringJoint ComputerConference,1963,Detroit.NewYork:1963329346.Disponvelem http://portal.acm.org/citation.cfm?doid=800265.810742.Acessadoem:12.2008. TAKEDA,H.;VEERKAMP,P.;TOMIYAMA,T.eYOSHIKAWA,H.Modelingdesignprocesses.AIMagazine, v.11,n.4,1990,p.3748.Disponvelem http://www.aaai.org/ojs/index.php/aimagazine/article/view/855/773.Acessadoem:12.2008. TAVARES,S.F.MetodologiadeAnlisedoCiclodeVidaEnergticodeEdificaesResidenciais Brasileiras.Florianpolis,2006,225p.Tese(Doutorado).ProgramadePsGraduaoem EngenhariaCivil,UniversidadeFederaldeSantaCatarina. TNO.IFCEngineDLLAPIReferenceGuide(pginadainternet).2008a. http://www.ifcbrowser.com/downloads/BETA/IFCEngineDLL.API.doc,acessadoem12.2008. TNO.ReadingIFCExample(pginadainternet).2008b. http://www.ifcbrowser.com/ifcenginedllread.html,acessadoem12.2008. TNO.TNOIFCEngineSeries(pginadainternet).2008c.http://www.ifcbrowser.com/,acessadoem 12.2008. TREECK,C.V.;ROMBERG,R.eRANK,E.SimulationbasedontheproductmodelstandardIFC.In: InternationalIBPSAConference,2003,Eindhoven.12931300.Disponvelem http://www.inive.org/members_area/medias/pdf/Inive%5CIBPSA%5CUFSC75.pdf.Acessado em:12.2008. TSE,T.C.K.;WONG,K.D.A.eWONG,K.W.F.TheutilisationofbuildinginformationmodelsinnD modelling:Astudyofdatainterfacingandadoptionbarriers.ElectronicJournalofInformation TechnologyinConstruction,v.10,2005,p.85110.Disponvelem http://www.itcon.org/data/works/att/2005_8.content.05676.pdf.Acessadoem:12.2008. TUCKER,S.;AMBROSE,M.;JOHNSTON,D.;MILTON,P.;SEO,S.eJONES,D.LCADesign:anintegrated approachtoautomaticecoefficiencyassessmentofcommercialbuildings.In:CIBW78 InternationalConferenceonInformationTechnologyonInformationTechnology,20,2003, WaihekeIsland.Disponvelemhttp://itc.scix.net/data/works/att/w782003403.content.pdf. Acessadoem:12.2008. TURK,Z.Phenomenologicalfoundationsofconceptualproductmodellinginarchitecture,engineering andconstruction.ArtificialIntelligenceinEngineering,v.15,n.2,2001,p.8392.Disponvelem http://www.sciencedirect.com/science/journal/09541810.Acessadoem:12.2008. TURK,Z.Constructioninformatics:definitionandontology.AdvancedEngineeringInformatics,v.20,n. 2,2006,p.187199Disponvelemhttp://www.sciencedirect.com/science/journal/14740346. Acessadoem:12.2008. TZORTZOPOULOS,P.Contribuiesparaodesenvolvimentodeummodelodeprocessodeprojetode edificaesemempresasconstrutorasincorporadorasdepequenoporte.PortoAlegre,1999, 163p.Dissertao(Mestrado).DepartamentodePsgraduaoemEngenhariaCivil, UniversidadeFederaldoRioGrandedoSul. TZORTZOPOULOS,P.Thedesignandimplementationofproductdevelopmentprocessmodelsin constructioncompanies.Salford,2004,321p.Tese(Doutorado).SchoolofConstructionand PropertyManagement,UniversityofSalford. VELOSO,R.R.JavaeXML.2.ed.SoPaulo:Novatec,2007,109p. VRTESI,L.;BOJR,G.eHAJAS,T.ArchiCAD4.0ReferenceManual.Graphisoft,1991,163p. VOELCKER,H.B.;REQUICHA,A.A.G.eHARTQUIST,E.ThePADL1.0/2systemfordefininganddisplaying solidobjects.ACMSIGGRAPHComputerGraphics,v.12,n.3,1978,p.257263.Disponvelem http://portal.acm.org/citation.cfm?id=965139.807400.Acessadoem:12.2008.

148

VTT.FinnishICTBarometer.Espoo:TEKES,2007. W3C.DOMDocumentObjectModel(pginadainternet).2008a.http://www.w3.org/DOM/,acessado em12.2008. W3C.ExtensibleMarkupLanguageXML1.0,FifthEdition(pginadainternet).2008b. http://www.w3.org/TR/RECxml/,acessadoem12.2008. WAN,L.eMESSNER,J.I.Virtualconstructionsimulator:a4DCADmodelgenerationprototype.In: ComputinginCivilEngineering,2007,Pittsburgh.Pennsylvania:2007Disponvelem http://scitation.aip.org/getabs/servlet/GetabsServlet?prog=normal&id=ASCECP000261040937 000102000001&idtype=cvips&gifs=yes.Acessadoem:12.2008. WANG,W.C.;LIU,J.J.eLIAO,T.S.Modelingofdesigniterationsthrougsimulation.Automationin Construction,n.15,2006,p.589603.Disponvelemhttp://www.elsevier.com/locate/autcon. Acessadoem:09.12.2006. WISSENBACH,V.ManualTcnicodeAlvenaria.SoPaulo:Projeto,1990,275p. WORTMANN,J.C.Productionmanagementsystemsforoneofakindproducts.ComputersinIndustry, v.19,n.1,1992,p.7988.Disponvelem http://www.sciencedirect.com/science/journal/01663615.Acessadoem:12.2008. YANG,W.Z.;XIE,S.Q.;AI,Q.S.eZHOU,Z.D.Recentdevelopmentonproductmodelling:areview. InternationalJournalofProductionResearch,v.46,n.1,2008,p.60556085.Disponvelem http://www.ingentaconnect.com/content/tandf/tprs/2008/00000046/00000021/art00008. Acessadoem:12.2008.

149

ApndiceA
Artigospublicadosduranteosestudos

VII Workshop Brasileiro de Gesto do Processo de Projetos na Construo de Edifcios - Curitiba - 2007

DIFERENTES ABORDAGENS DO USO DO CAD NO PROCESSO DE PROJETO ARQUITETNICO


Cervantes AYRES F.

Arq., Mestrando no PPGCC/UFPR cervantes.ayres@gmail.com

D.Sc., Professor Adjunto da UFPR scheer@ufpr.br

Sergio SCHEER

RESUMO
As ferramentas computacionais de apoio ao processo de projeto de edificaes (CADs) so tidas atualmente como indispensveis para a indstria da construo. Entretanto, o desconhecimento das vantagens e desvantagens de cada uma delas pode prejudicar o desempenho do processo de projeto, ou impedir que se utilize todo o potencial oferecido pela informtica para a sua melhoria. Nesse artigo, essas ferramentas so consideradas como tecnologias de informao, e no apenas como aplicativos de desenho. Foram revisadas as caractersticas e especificidades dos diferentes tipos de softwares voltados para o projeto de edificaes. Pretende-se expor ao leitor, de maneira introdutria, em que nvel cada tipo de CAD auxilia ou prejudica a gerao, o processamento, a armazenagem e a visualizao das informaes que compem um projeto de edificao.

1. CAD GEOMTRICO: A PRANCHETA ELETRNICA


Os softwares de desenho assistido por computador, chamados CAD - Computer Aided Drawing/Drafting surgiram no incio da dcada de 1980 (IBRAHIM et al., 2004; REFFAT, 2006). Apesar de existirem diferentes tipos de CADs desde o incio, a baixa capacidade dos computadores pessoais da poca favoreceu a opo pelos softwares que demandavam menor quantidade de processamento. O tipo de CAD que melhor se adaptou a essa condio foi o que se concentrava na representao de informaes atravs de primitivos geomtricos (linhas, pontos, arcos, etc.), o chamado CAD geomtrico. Esse tipo de CAD popularizou-se e tornou-se essencial aos projetistas, sendo muito raros os escritrios que atualmente no se utilizam dessa ferramenta (FABRICIO e MELHADO, 2002; TSE et al., 2005). Os CADs geomtricos tambm so chamados de pranchetas eletrnicas, um termo que parece denotar uma modernizao: a substituio dos desenhos tinta nanquim por arquivos digitais e plotagens. Entretanto, a analogia tambm revela o aspecto mais frgil da tecnologia desses CADs: apesar de eliminarem tarefas repetitivas e complicadas (como a normografia) e facilitarem a correo dos desenhos, o suporte que eles oferecem ao processo de projeto vai pouco alm de uma prancheta melhorada. Nascimento e Santos (2006), estudando a aplicao de tecnologias de informao nas empresas da indstria da construo, afirmam que o uso dos CADs geomtricos pelos escritrios de projeto pode ser considerado como uma simples substituio de uma ferramenta por sua equivalente mais nova, sem que haja reformulao do processo de produo. De fato, o suporte da informao passa do papel para a tela do computador, mas o processo de gerao desta informao praticamente no se altera. Grande parte da incapacidade dos CADs geomtricos em proporcionar uma melhora considervel no desempenho do processo de projeto reside nos conceitos que orientaram o seu desenvolvimento. Para Ibrahim et al. (2004), o foco da tecnologia desses CADs esteve sempre direcionado para a soluo do problema da representao digital da geometria, e no necessariamente para a transmisso de informao atravs do desenho. Por isso, embora tenha se tornado padro para a indstria da construo, o CAD geomtrico sempre foi um obstculo para a comunicao eficiente entre os diversos agentes e os processos envolvidos na produo.

VII Workshop Brasileiro de Gesto do Processo de Projetos na Construo de Edifcios - Curitiba - 2007

A sucesso de anlises e decises que constituem o projeto arquitetnico (BOUCHLAGHEM et al., 2005) demanda grandes quantidades de informaes estruturadas e recursivas. Modificaes em determinadas pores da informao dependem das demais pores, mas tambm pode ser necessrio modificar estas ltimas em decorrncia de escolhas efetuadas. Apesar da importncia da estruturao da informao, o CAD geomtrico, por se concentrar primeiramente na representao da geometria, favorece a situao oposta: as informaes so fragmentadas e desestruturadas, dificultando a anlise em conjunto (FU et al., 2006). Tse e outros autores (2005) observam que nesses CADs, embora haja a possibilidade de organizar as informaes do projeto atravs de layers (camadas), cores ou blocos, esta uma tarefa que pode aumentar consideravelmente o tempo de desenho, alm de criar dependncias por convenes que no so suficientemente bvias ou generalizveis. Esses aspectos so ilustrados na figura 1: esquerda, mostrada a planta de um pequeno depsito. Sua representao composta por um conjunto de primitivos geomtricos (vrias linhas e um arco de circunferncia), que contm pouca ou nenhuma significao quando considerados individualmente. O conjunto de primitivos geomtricos s interpretado como uma planta porque os projetistas so treinados para reconhecer a conveno de desenho tcnico utilizada. Como a correta interpretao do conjunto depende mais do observador do que da forma como a informao foi armazenada, uma simples operao de mover alguns dos primitivos geomtricos pode comprometer o significado transmitido pelo conjunto, como se v na parte direita da figura.

Figura 1

Outro exemplo da fragmentao da informao no CAD geomtrico a documentao de projetos de edifcios de mltiplos andares. O conjunto de plantas pode ser armazenado em arquivos separados, cada um contendo a planta de um andar; ou num mesmo arquivo, com as plantas lado a lado; ou ainda sobrepostas no mesmo arquivo, mas em layers ou agrupamentos distintos, cabendo ao usurio ativar ou desativar a visualizao dos elementos de acordo com o pavimento desejado. No h vnculos claramente estabelecidos e seguros entre as diferentes pores de informao (as diversas plantas), cabendo ao usurio interpretar a forma pela qual ela foi dividida ou utilizar uma conveno prpria para recompor a totalidade da informao. Alm disso, mesmo que no ocorram erros nesse processo de recomposio, o processamento das informaes para a gerao de novos desenhos exige que elas sejam transportadas do lugar de armazenamento para o local de processamento: por exemplo, copiar as informaes do arquivo da planta do terceiro andar para o arquivo da planta do segundo andar, para desenhar as projees das lajes. Essas operaes de relocao (ou transposio) fragilizam a informao e reduzem o desempenho do processo, aumentando a possibilidade de ocorrncia de erros. Essas inconvenincias decorrem do fato do CAD geomtrico ter reproduzido no computador o processo de trabalho que era executado em pranchetas, quando a gerao dos desenhos era restrita pelos modos de se operar com as diversas folhas de papel. A persistncia dessa situao em um contexto de crescente complexidade dos projetos e demandas por maior produtividade pode resultar em erros, retrabalhos e atrasos, contribuindo para o baixo desempenho da construo em relao a outros ramos da indstria.

2. CAD 3D: A MAQUETE ELETRNICA


A terceira dimenso acrescentada pelo uso de um CAD 3D aumenta consideravelmente a quantidade de informaes do projeto. Entretanto, os CADs 3D apresentam a mesma caracterstica de fragmentao da informao dos CADs geomtricos, tornando difcil a produo de informaes estruturadas, que normalmente constituem o ncleo da documentao de um

VII Workshop Brasileiro de Gesto do Processo de Projetos na Construo de Edifcios - Curitiba - 2007

projeto (plantas, cortes, elevaes, etc.). Alm disso, os CADs 3D so geralmente softwares cuja proposta bsica auxiliar no processo do desenho industrial, e no no projeto de edificaes. Por isso faltam mecanismos que permitam a seleo e visualizao parcial das informaes, que so essenciais ao projeto arquitetnico. Enquanto num CAD geomtrico a informao pode ser compartimentada em arquivos diferentes, a representao tridimensional de um edifcio s faz sentido se todos os elementos que a constituem estiverem presentes no mesmo arquivo, ocupando as posies relativas s que ocuparo no edifcio construdo. Apesar de ser uma vantagem em relao ao CAD geomtrico, a presena de todos os elementos geomtricos em um mesmo local no garante a estruturao e a possibilidade de extrao de informaes, principalmente na forma de documentao projetual.
15
15

500 470

15

500 470

A: 22,09 m2
0,00

ABRIGO

Fig. 2a

Fig. 2b

Fig. 2c

15

Fig. 2d

A figura 2a mostra um conjunto de elementos geomtricos tridimensionais vistos em perspectiva, dos quais se pretende extrair uma planta. Uma planta um conjunto de informaes que obviamente derivam da geometria dos elementos do projeto, mas que deve atender tambm convenes de desenho tcnico. necessrio que a visualizao dos elementos geomtricos seja parcial e condizente com a representao desejada (por exemplo, as paredes devem ser cortadas a 150cm de altura); que a informao apresentada seja categorizada (graduao de espessuras de linhas, hachuras, projees); e ainda que sejam includas informaes indicativas (dimenses, nveis, descries). A simples visualizao dos elementos geomtricos a partir de um ponto situado acima deles, embora geometricamente correta, no se constitui em uma planta (fig. 2b). Mesmo que o CAD 3D seja capaz de visualizar os elementos na forma de slidos (o chamado modo shade), isso resulta em uma vista de topo, e no em uma planta (fig. 2c). A dificuldade em gerar documentaes reside no fato de os elementos construtivos serem representados nos CADs 3D como slidos geomtricos indistintos, ficando a cargo do usurio interpreta-los. Alm disso, os softwares no fornecem meios ou dificultam muito a organizao das informaes na forma que o setor est familiarizado: assim como nos CADs geomtricos, necessrio que o usurio estabelea grupos de elementos cuja visualizao possa ser ativada ou desativada, de acordo com o tipo de documento que se deseja obter. Gerar uma representao que parea familiar, como a da figura 2d em um CAD 3D uma atividade que demanda muito tempo, e tambm pode gerar erros e dependncias por convenes que so prprias do usurio, ou da empresa, dificultando o acesso dos demais agentes envolvidos no processo de projeto. Essas dificuldades inviabilizam ou restringem muito a utilizao do CAD 3D no desenvolvimento de projetos arquitetnicos. A utilizao passa a ocorrer com mais nfase na gerao de representaes tridimensionais que comuniquem mais facilmente a idia ao cliente, e no durante a fase de concepo, onde poderia auxiliar no processo de anlise e deciso. Como observa Sperling (2002), a confeco dessas representaes, as chamadas maquetes eletrnicas, o uso mais comum dos CADs 3D pelos escritrios, sendo que o processo de projeto que d origem s informaes utilizadas na gerao da maquete eletrnica geralmente se desenvolve de forma bidimensional, em um outro CAD, geomtrico. Pelegrino, citado por Sperling (2002), atribui s maquetes eletrnicas status inferior ao de um objeto 3D, estando estas mais para um objeto 2,5D (duas e meia dimenses), uma vez que tratam-se apenas do espessamento de uma das projees bidimensionais (em geral a planta), sem interaes com as demais representaes. Assim como na analogia da prancheta eletrnica, o termo maquete eletrnica faz parecer que trata-se de uma modernizao do processo de projeto. Porm, o uso do CAD 3D apenas para possibilitar a troca da maquete convencional pela sua verso eletrnica praticamente no modifica

PROJE O DA COBERTURA

VII Workshop Brasileiro de Gesto do Processo de Projetos na Construo de Edifcios - Curitiba - 2007

o modo tradicional de produo dos projetos, resultando em pouca melhora da qualidade da informao gerada e do desempenho do processo como um todo.

3. DOS ELEMENTOS GEOMTRICOS AOS OBJETOS PARAMTRICOS


Como alternativa tecnologia do CAD geomtrico, alguns softwares propem a representao dos elementos construtivos utilizando objetos compostos cuja representao geomtrica associada a um comportamento especfico (LEE et al., 2006). Cada elemento construtivo tem caractersticas e representaes prprias, e o CAD considera essas distines na representao, melhorando a qualidade da informao e facilitando a gerao dos desenhos. Essa distino torna bvio para qualquer usurio o tipo do elemento que est sendo apresentado, e o seu comportamento especfico garante relaes corretas entre os diferentes tipos de elementos, tornando as informaes mais precisas e confiveis. Por exemplo, ao invs de representar paredes atravs de linhas paralelas, que sequer so entendidas pelo computador como paredes, utiliza-se o elemento parede, que alm de ser armazenado e interpretado pelo computador como a representao de uma parede, possui um comportamento especfico que inclui: se estender apenas longitudinalmente (a extenso transversal a espessura), possuir determinada altura, a capacidade de receber aberturas (portas e janelas), se associar corretamente a outros elementos parede (eliminando arestas desnecessrias nos encontros de elementos), etc. Alm disso, o elemento parede possui informaes relativas sua composio e aparncia: material de acabamento, de revestimento, do ncleo; e tambm informaes utilizadas na representao bidimensional do elemento: cor, espessura do trao, hachura, etc. (IBRAHIM et al., 2004). Todas essas caractersticas especficas de cada objeto so chamadas de parmetros, de onde vem o nome da representao virtual do elemento construtivo: objeto paramtrico. A riqueza de informaes proporcionada pelo uso de objetos paramtricos possibilita a extrao automtica de diversos tipos de representaes de determinado elemento construtivo, sem que haja a necessidade de redesenh-lo. Como existem parmetros que determinam a representao em cada situao (planta, corte, elevao e perspectiva, etc.), a visualizao passa a ser funo de uma escolha do usurio, e no da gerao manual de um desenho adicional. A representao , portanto, automtica.

4. CAD BIM: A MODELAGEM DO PRODUTO


Tanto os sistemas CAD que utilizam objetos paramtricos quanto os baseados em primitivos geomtricos surgiram no incio da dcada de 1980. Contudo, a capacidade de processamento necessria para a representao de primitivos geomtricos muito menor, e por isso o CAD geomtrico se adaptou melhor aos equipamentos disponveis na poca, dominando o mercado de softwares de projeto pelas duas dcadas seguintes (TSE et al., 2005). No final da dcada de 1990, presses por maior produtividade e qualidade nos processos projetuais e construtivos, alm da popularizao dos computadores com maior capacidade de processamento, fizeram ressurgir a discusso iniciada nos anos 80 a respeito das duas abordagens empregadas pelos CADs. A abordagem por objetos paramtricos nos CADs agora denominada BIM acrnimo do termo em ingls1 Building Information Modeling (TSE et al., 2005). Enquanto nos CADs geomtricos o objetivo principal a produo de desenhos, o princpio da abordagem BIM auxiliar no processo de criao e gerenciamento de informaes relacionadas construo, de modo integrado, reutilizvel e automatizado, gerando um modelo digital do edifcio ao invs de uma srie de desenhos. (LEE et al., 2006). Uma detalhada representao tridimensional essencial a qualquer sistema CAD BIM (LEE et al., 2006), porm em projetos arquitetnicos, a visualizao no um fim em si mesma ela faz parte de um processo conjunto de modificaes e verificaes sucessivas, que leva ao produto final (BOUCHLAGHEM et al., 2005). Portanto, essencial que o software de projeto oferea recursos que favoream a representao e a visualizao bem como permitam a modificao dos
1 Embora citado em algumas publicaes em portugus como Modelagem Integrada do Edifcio por ex. em Nascimento e Santos (2006) o termo BIM ainda no possui uma verso convencional em nosso idioma, fato pelo qual foi escolhido mant-lo em sua linguagem original neste artigo.

VII Workshop Brasileiro de Gesto do Processo de Projetos na Construo de Edifcios - Curitiba - 2007

elementos de forma direta e intuitiva. As implicaes do uso dos recursos tridimensionais em um CAD BIM vo muito alm da confeco de perspectivas ou maquetes eletrnicas. A gerao de elementos tridimensionais pretende auxiliar a antever o resultado espacial das escolhas de projeto, e eliminar as possveis interferncias entre os elementos construtivos e erros antes do incio da construo. Esse processo de anlise prvia, baseada em modelos ou prottipos virtuais, j prtica comum nas indstrias manufatureira, metal-mecnica e aeroespacial, sendo conhecido como modelagem do produto (HUANG et al., 2007). Nos CADs BIM, a modelagem do produto inclui o conceito de edifcio virtual: um conjunto de objetos paramtricos representando a edificao em ambiente virtual. Desse conjunto de objetos so extradas automaticamente as representaes, documentaes, relatrios quantitativos, especificaes dos materiais, anlises fsicas, etc (Fig. 3). Isso possvel porque os CADs BIM estruturam o modelo como bases de dados contendo as informaes de cada objeto paramtrico, e a partir do acesso centralizado elas realizam-se processamentos complexos e a gerao de documentaes estruturadas automaticamente. A centralizao da informao permite que as atualizaes sejam facilmente registradas, e modificaes em uma parte do projeto (p. ex. em um corte) propagam automaticamente atualizaes em outras (p. ex. nas elevaes). O nvel de informao apresentado pode ser controlado, de acordo com a etapa do processo de projeto: de mais dirigido composio e configurao dos espaos no incio do processo, a detalhamentos construtivos ou anlises de desempenho ao final. Os objetos paramtricos podem tambm ser referncias diretas a produtos desenvolvidos por fabricantes, como janelas, peas pr-fabricadas, acessrios, etc. Estes objetos e suas atualizaes podem ser obtidos diretamente via internet e futuramente ajustarem automaticamente o seu comportamento aos aspectos do projeto. Por exemplo, objetos representando peas estruturais, que se configuram automaticamente de acordo com os vos e tipos de apoios definidos (IBRAHIM et al., 2004).
A

GARAGEM
+6,71 +6,35

JANTAR ESTAR
+5,00

SERVIO

CLOSET

B
DORMITRIO

COZINHA

B
+2,63 DORMITRIO BANHEIRO +2,63

DORMIT. CHURRASQ.

BANHEIRO

0,00

COZINHA

LAVANDERIA

0,00

GARAGEM

Fig. 3a: modelo virtual de edificao, feito em ArchiCAD

Fig. 3b: planta extrada do modelo (gerao simultnea modelagem)

Fig. 3c: corte extrado do modelo (gerao depende da indicao da posio do corte)

Para Birx (2006b), definir CAD BIM apenas como uma nova ferramenta de desenho pode reduzir os impactos positivos dessa inovao. BIM deveria ser considerada uma evoluo do processo de projeto, tendo em vista as novas possibilidades de visualizao e processamento da informao. As vantagens so a melhor coordenao dos elementos construtivos e suas interferncias; reduo das horas de trabalho; aumento da produtividade; desenhos e detalhamentos de melhor qualidade; controle centralizado do contedo e das verses dos documentos do projeto. Os CADs BIM tambm auxiliam no ensino da arquitetura, j que a correta insero dos elementos do projeto requer que o usurio compreenda os parmetros dos elementos construtivos que eles representam, forando os arquitetos a encontrarem solues ainda durante a concepo. Os CADs BIM ainda ocupam uma parcela reduzida do mercado de softwares para projeto. Esta uma das suas principais desvantagens, pois isola o profissional em relao ao restante da cadeia produtiva, que utiliza outros tipos de CAD (BIRX, 2006a). Outros desafios a serem superados pela tecnologia incluem o custo dos equipamentos e treinamento, escassez de profissionais treinados, o estado ainda incipiente de alguns CADs BIM, e a definio de protocolos de interoperabilidade entre os diferentes sistemas. Para Birx (2006b), o perodo de transio da utilizao do CAD geomtrico para os CADs BIM durar ao menos uma dcada. Para Ibrahim et al. (2004), aps a retrao da poro do mercado ocupada pelos CADs geomtricos, surgiro softwares dedicados a diferentes etapas do processo construtivo, onde o CAD BIM arquitetnico se constituir em

VII Workshop Brasileiro de Gesto do Processo de Projetos na Construo de Edifcios - Curitiba - 2007

referncia para as demais aplicaes: estruturas, planejamento da construo, avaliao de custos, anlise do ciclo de vida, etc.

5. CONSIDERAES FINAIS
A crescente demanda por processos mais racionais e de melhor desempenho na indstria da construo amplamente observada pelos estudos cientficos da rea. Observa-se tambm a complexidade cada vez maior dos sistemas construtivos e das exigncias de desempenho no seu funcionamento, visando a economia de recursos e a reduo do impacto ambiental gerado por eles. O volume de informaes necessrio para a gerao de produtos dentro deste contexto aumenta rapidamente, e so demandados novos sistemas ou novas abordagens para o processamento dessas informaes (HKKINEN, 2007). Sendo o CAD BIM, em essncia, um sistema de gesto de informaes, o seu uso pode se tornar em muito pouco tempo uma forma vivel para projetistas se inserirem ou se manterem no mercado, frente a esses novos paradigmas. Embora ainda sejam poucos os estudos quantificando as vantagens obtidas pelo uso dos CADs BIM, as pesquisas na rea de tecnologia de informao concordam em relao sua influncia positiva sobre o desempenho do processo de projeto e a respeito da irreversibilidade da transio do CAD geomtrico para o BIM. Entretanto, no somente a ferramenta utilizada na gerao das documentaes projetuais deve ser modificada: o prprio processo de projeto deve sofrer alteraes, dadas as novas possibilidades oferecidas pela tecnologia.

6. REFERNCIAS BIBLIOGRFICAS
BIRX, Glenn W. BIM creates change and opportunity. The American Institute of Architects - Best Practices, 2006a. Disponvel em http://www.aia.org/bestpractices_index. Acessado em: 22.11.2006. ______. Getting started with Building Information Modeling. The American Institute of Architects - Best Practices, 2006b. Disponvel em http://www.aia.org/bestpractices_index. Acessado em: 22.11.2006. BOUCHLAGHEM, Dino, et al. Visualisation in architecture, engineering and construction (AEC). Automation in Construction, n. 14, 2005, p.287-295. Disponvel em http://www.elsevier.com/locate/autcon. Acessado em: 06.12.2006. FABRICIO, Marcio Minto e MELHADO, Silvio Burratino. Impactos da tecnologia da informao no conhecimento e mtodos projetuais. In: SEMINRIO DE TECNOLOGIA DE INFORMAO E COMUNICAO NA CONSTRUO CIVIL, 1, 2002, Curitiba, PR. Disponvel em http://www.infohab.org.br. Acessado em: 20.11.2006. FU, Changfeng, et al. IFC model viewer to support nD model application. Automation in Construction, n. 15, 2006, p.178185. Disponvel em http://www.elsevier.com/locate/autcon. Acessado em: 20.11.2006. HKKINEN, Tarja M. Sustainable building related new demands for product information and product model based design. ITCON, v. 12, 2007, p.19-37. Disponvel em http://itcon.org/2007/2. Acessado em: 25.06.2007. HUANG, Ting, et al. A virtual prototyping system for simulating construction processes. Automation in Construction, n. 16, 2007, p.576-585. Disponvel em www.elsevier.com/locate/autcon. Acessado em: 22.06.2007. IBRAHIM, Magdy, et al. Two approaches to BIM: A comparative Study. In: ECAADE, 2004, Dinamarca. Disponvel em http://www.iit.edu/~krawczyk/miecad04.pdf. Acessado em: 20.11.2006. LEE, Ghang, et al. Specifying parametric building object behavior (BOB) for a building information modeling system. Automation in Construction, n. 15, 2006, p.758-776. Disponvel em http://www.elsevier.com/locate/autcon. Acessado em: 20.11.2006. NASCIMENTO, Luiz Antonio do e SANTOS, Eduardo Toledo. A indstria da construo na era da informao. Ambiente Construdo, v. 3, n. 1, 2006, p.69-81. Disponvel em http://www.antac.org.br. Acessado em: 21.11.2006. REFFAT, Rabee M. Computing in architectural design: reflections and an approach to new generations of CAAD. Electronic Journal of Information Technology in Construction, v. 11, n. 45, 2006, p.655-668. Disponvel em http://www.itcon.org/2006/45/. Acessado em: 09.12.2006. SPERLING, David Moreno. O projeto arquitetnico, novas tecnologias de informao e o museu Guggenhein de Bilbao. In: WORKSHOP NACIONAL - GESTO DE PROCESSO DE PROJETO NA CONSTRUO DE EDIFCIOS, 2, 2002, Porto Alegre - RS. Disponvel em http://www.infohab.org.br. Acessado em: 20.11.2006. TSE, Tao-chiu Kenny, et al. The utilisation of Building Information Models in nD modelling: a study of data interfacing and adoption barriers. Electronic Journal of Information Technology in Construction, v. 10, n. 8, 2005, p.85-110. Disponvel em http://www.itcon.org/2005/08/. Acessado em: 09.12.2006.

VII Workshop Brasileiro de Gesto do Processo de Projetos na Construo de Edifcios - Curitiba - 2007

IMPACTOS DO USO DO SISTEMA CAD GEOMTRICO E DO USO DO SISTEMA CAD-BIM NO PROCESSO DE PROJETO EM ESCRITRIOS DE ARQUITETURA

Srgio SCHEER
D.Sc / Professor Adjunto do Programa de Ps-Graduao em Construo Civil (UFPR) Correio eletrnico: scheer@ufpr.br

Armando L. Y. ITO
M.Sc./Arquiteto, Professor do curso de Arquitetura e Urbanismo do UnicenP Correio eletrnico: ito@unicenp.edu.br

Cervantes AYRES Filho


Arquiteto / Mestrando do Programa de Ps-Graduao em Construo Civil (UFPR). Correio eletrnico ceayres@gmail.com

Fabola AZUMA
Eng. Civil / Mestranda do Programa de Ps-Graduao em Construo Civil (UFPR).Correio eletrnico fabiolaazuma@yahoo.com.br

Michelle BEBER
Arquiteta / Mestranda do Programa de Ps-Graduao em Construo Civil (UFPR) Correio eletrnico mi_arq@yahoo.com.br

RESUMO
Sistemas CAD-BIM para projetos arquitetnicos trabalham com objetos paramtricos como janelas, paredes, portas, entre outros. Esses tipos de sistemas incorporam o conceito BIM (Building Information Modelling) e possuem a capacidade para armazenar informaes necessrias ao longo do ciclo de vida do projeto, abrangendo aspectos de concepo, operao, manuteno e gerenciamento. Diferentemente dos sistemas CAD geomtricos, que permitem apenas a representao de entidades grficas, como linhas e pontos, os sistemas CAD-BIM conseguem representar a semntica do projeto, facilitando o intercmbio de dados. Dessa maneira, nos escritrios que utilizam o Sistema CAD-BIM, todos os envolvidos do empreendimento participam de modo integrado e simultneo, contribuindo para a anlise dos dados e para a tomada de deciso. Este trabalho tem como objetivo apresentar os impactos de sistemas CAD geomtricos e sistemas CAD-BIM no processo de projeto em escritrios de arquitetura da cidade de Curitiba-PR. Para atingir esse objetivo foram realizados dois estudos de caso. O primeiro estudo aborda sistemas CAD geomtricos e o segundo estudo aborda sistemas CAD-BIM. Como resultado mostrado uma anlise qualitativa do uso de cada tipo de sistema CAD no processo de projeto de edificaes em relao produtividade, a visualizao da informao, ao gerenciamento de informao do projeto e a interoperabilidade de sistemas. Palavras-chave: Building Information Modelling, Sistema CAD, Processo de Projeto.

VII Workshop Brasileiro de Gesto do Processo de Projetos na Construo de Edifcios - Curitiba - 2007

1. INTRODUO
A tecnologia CAD considerada a inovao mais importante de TI das ltimas quatro dcadas. As tecnologias CAD oferecem recursos como ferramentas de automao de desenho e projeto, ferramentas de comunicao e compartilhamento de projeto e banco de dados. Um histrico da evoluo dessas tecnologias revela trs geraes distintas: A primeira gerao composta pelo desenho auxiliado por computador; a segunda pela modelagem geomtrica; e a terceira pelamodelagem de produto (KALE & ARDITI, 2005). A terceira gerao da tecnologia CAD se refere modelagem de produto, que teve o seu incio no final da dcada de 80. O principal objetivo dessa gerao foi a integrao de informaes geomtricas com dados no geomtricos atravs do estabelecimento de relacionamentos associativos e paramtricos. As informaes geomtricas abrangem as caractersticas espaciais do objeto como a forma, a posio, e as dimenses. Dados no geomtricos incluem caractersticas como custo, material, peso, resistncia, entre outras (KALE & ARDITI, 2005). O objetivo desse trabalho fazer um estudo sobre os impactos do uso do sistema CAD geomtrico e do sistema CAD-BIM no processo de projeto.

2. BUILDING INFORMATION MODELLING - BIM


A modelagem de produto no projeto de edificaes conhecida pelo termo BIM (do ingls Building Information Modelling). O impacto mais visvel dessa tecnologia sobre o processo de projeto a forma pela qual ocorre a gerao das informaes. No processo convencional, tanto no uso do CAD bidimensional ou no uso do papel vegetal, criada uma srie de desenhos tcnicos, sem conexes explcitas entre si, cuja leitura em conjunto permite a compreenso da totalidade da informao do projeto. O conjunto de desenhos pode subsequentemente dar origem a uma maquete virtual um modelo tridimensional que permite melhor visualizao das informaes, mas que pouco influncia no processo de projeto em si e na qualidade final do produto (SPERLING, 2002). No processo utilizando a tecnologia BIM, ocorre uma inverso: ao invs de uma srie de desenhos bidimensionais, o projetista constri virtualmente um modelo da edificao, utilizando objetos que simulam em forma e comportamento os elementos construtivos a serem empregados na construo. Os modelos virtuais podem ser entendidos como bases de dados onde so armazenados tanto os dados geomtricos, como os textuais de cada elemento construtivo utilizado no projeto A combinao desses dados permite a extrao automtica de documentos como plantas, cortes, perspectivas ou quantitativos. A ateno do projetista , portanto, destinada primordialmente s solues projetuais, e no aos desenhos tcnicos, que so em boa parte gerados automaticamente pelo computador (BIRX, 2006b). As vantagens do uso da modelagem vo muito alm da criao de maquetes eletrnicas e agilizao do processo de produo de documentaes projetuais. Assim como nas indstrias metal-mecnica, manufatureira e aeroespacial, a visualizao tridimensional do modelo permite verificar as inadequaes e incompatibilidades instantaneamente, auxiliando nos processos de deciso de maneira intuitiva, em todas as etapas do projeto. Outro ponto importante a consolidao das informaes que constituem o projeto. Uma vez que se utiliza uma base de dados unificada para todo o contedo de informao, as modificaes em um determinado documento (por exemplo, uma planta baixa do projeto arquitetnico), propagam-se para os demais documentos envolvidos automaticamente, garantindo assim a agilidade nas atualizaes, modificaes e confiabilidade no acesso s informaes.

3. MTODO DE PESQUISA

VII Workshop Brasileiro de Gesto do Processo de Projetos na Construo de Edifcios - Curitiba - 2007

Foram conduzidos estudos de caso em dois escritrios de arquitetura de Curitiba. A partir da anlise qualitativa dos processos de ambos os escritrios foi possvel identificar os impactos das diferentes tecnologias da informao utilizados. Em ambos os estudos de caso foram analisadas as seguintes caractersticas do processo do projeto: Produtividade: quantidade de informao gerada em um determinado perodo. Visualizao da informao: facilidade gerada pelo sistema CAD em proporcionar um entendimento do projeto a partir dos modos de visualizao disponveis. Gerenciamento da informao do projeto: integridade e disponibilidade nos processos de gerao e modificao da informao. Interoperabilidade: possibilidade de transferncia integral da informao entre os diversos sistemas utilizados durante o processo de projeto, dentro ou fora do escritrio.

4. ESTUDO DE CASO 01 USO DE SISTEMA CAD2D


4.1. Caracterizao do escritrio O escritrio de arquitetura estudado utiliza o software AutoCAD2002, da Autodesk, para desenvolvimento do projeto. O arquiteto trabalha sozinho no escritrio e so elaborados projetos para produo de residncias e indstrias. O arquiteto j chegou a projetar uma edificao com 60.000 m2 de rea. 4.2. Processo de projeto O processo de desenvolvimento de projetos tem incio com o levantamento das necessidades do usurio atravs de uma reunio informal. Em seguida, o arquiteto visita o local da futura edificao e fotografa diversas vistas do terreno. elaborada uma lista de prioridades do cliente para dar origem s noes do espao a ser projetado, e assim tem incio a modelagem mental do terreno, considerando as suas caractersticas espaciais. Este estudo mental realizado exaustivamente e apenas comea-se a riscar o croqui quando tm aproximadamente 90% do projeto resolvido mentalmente, pois o arquiteto acredita que o papel branco inibe o processo criativo. Aps esse estudo mental, tem incio os croquis bsicos, a elaborao da setorizao,da volumetria da edificao e d definio dos espaos internos. O objetivo dessa etapa compreender todo o conjunto da obra, inserindo o edifcio no terreno e compreendendo sua relao com o entorno. O AutoCAD2002 utilizado somente aps a realizao destes esboos. O arquiteto costuma utilizar uma viewport (uma janela de visualizao do Autocad) para planta do projeto, outra viewport para os cortes e uma terceira viewport para o projeto 3D. Os recursos 3D do AutoCAD2002 so utilizados para estudo volumtrico e anlise da volumetria e espao, alm de apresentaes do projeto. Ao final do projeto, o arquiteto gera visualizaes fotorealistas (renderizao) do modelo 3D utilizando o aplicativo 3D Studio MAX, tambm da Autodesk. Em seguida, so elaboradas as apresentaes finais para o cliente utilizando o aplicativo Adobe Photoshop . A apresentao do projeto feita em uma tela de projeo, na qual o arquiteto mostra uma maquete eletrnica da obra com imagens estticas. 4.3. Interoperabilidade de sistemas Todos os parceiros de projeto utilizam o Autocad, e os arquivos so transmitidos via e-mail. O arquiteto atua com centralizador das informaes e faz a compatibilizao com outros projetos como: estrutural, eltrico e hidrulico.

VII Workshop Brasileiro de Gesto do Processo de Projetos na Construo de Edifcios - Curitiba - 2007

4.4. Impactos do sistema CAD2D no processo de projeto O arquiteto relatou que a utilizao do sistema CAD geomtrico no processo de projeto trouxe vrios benefcios. Antes de utilizar o sistema CAD geomtrico, o arquiteto possua uma estrutura organizacional maior, composta de diversos desenhistas. Com a introduo do sistema ele capaz de trabalhar sozinho. O arquiteto est satisfeito com o nvel atual de produtividade, afirmando que no tem problemas em relao ao cumprimento de prazos. No entanto, afirma que no teria restries a novas ferramentas, caso elas proporcionassem uma melhoria no processo de projeto.

5. ESTUDO DE CASO 2 USO DE SISTEMA CAD-BIM


5.1. Caracterizao do escritrio O escritrio de arquitetura utiliza o software ArchiCAD verso 10, da Graphisoft/Nemetschek, para o desenvolvimento dos projetos. A estrutura organizacional formada por quatro pessoas: um arquiteto (diretor), um engenheiro, um arquiteto especializado em interiores e um tecnlogo. So elaborados projetos residenciais unifamiliares e multifamiliares alm de projetos comerciais. A rea projetada anual varia entre 1000 m2 5000 m2. 5.2. Processo de projeto O processo de projeto se inicia com a visita ao local do terreno na companhia do cliente. So tiradas fotos do terreno e solicitado um levantamento topogrfico. Em seguida so levantados os requisitos para o projeto e inicia-se a montagem do organo-fluxograma (esquema bsico de distribuio dos espaos e fluxos internos) utilizando as funes bidimensionais do ArchiCAD10. Nesta etapa so estudas a questo de conforto ambiental, funcionalidade e espaos internos. Inicia-se ento a anlise dos espaos atravs da distribuio do mobilirio, em uma proposta preliminar de planta. Uma vez definida a planta, o estudo parte para a anlise do projeto em 3D com o objetivo de refinar a mesma, levando em considerao sua forma. Depois de finalizado, o projeto apresentado ao cliente e, uma vez aprovado, inicia-se o anteprojeto. O arquiteto responsvel pelo projeto arquitetnico e os projetistas parceiros elaboram os projetos complementares. Em seguida elaborado o projeto executivo e depois o projeto legal. Em todas essas etapas utilizado o ArchiCAD10. Para a elaborao do projeto executivo, o arquiteto utiliza os objetos paramtricos para compor as paredes, portas, janelas e todos os outros componentes construtivos. Ao projetar desta maneira, tanto o modelo 3D, como as vistas e os cortes, j so gerados automaticamente, facilitando o trabalho do projetista. A partir do modelo 3D so retiradas diversas informaes do projeto, como quantitativo de materiais, tipo de componentes, dimenses, volumes de material, resumo de esquadrias contendo material, quantidade, tipo de abertura e dimenses. Para apresentao do projeto ao cliente feita a renderizao no software Atlantis, da Abvent e geradas diversas imagens fotorealistas. 5.3. Interoperabilidade de sistemas Os projetos so transmitidos via e-mail e o estrutural gerado no software TQS e exportado para o formato DXF, sendo facilmente importado no ArchiCAD10. O projeto eltrico e hidrulico enviado ao arquiteto em formato DWG, sendo tambm facilmente reconhecido pelo ArchiCAD10. Essas operaes de importao/exportao de arquivos no acarretam problemas de perdas de dados, de acordo com o entrevistado. 5.4. Impactos do sistema CAD-BIM no processo de projeto

VII Workshop Brasileiro de Gesto do Processo de Projetos na Construo de Edifcios - Curitiba - 2007

Conforme o entrevistado, com o auxlio do software ArchiCAD10 possvel ter ganhos de produtividade, uma vez que as atualizaes e alteraes no projeto so realizadas automaticamente nas diversas vistas, cortes e no modelo3D, alm de recursos de auto-textos para elaborao de carimbos. O entrevistado tambm ressaltou as vantagens de visualizao do projeto apresentado pelo ArchiCAD10 atravs do modelo 3D, sendo possvel identificar com maior preciso os detalhes construtivos e as interferncias projetuais, contribuindo para a reduo de erros de execuo da obra.

6. ANLISE DOS DADOS


Abaixo segue a anlise qualitativa dos parmetros de projeto mencionados no mtodo de pesquisa. 6.1 Produtividade No sistema CAD geomtrico (AutoCAD2002) houve ganhos de produtividade em relao ao processo manual sobre prancheta, pois possvel, alm da maior velocidade no processo de desenho do projeto, maior padronizao e qualidade das informaes grficas. No entanto, com o sistema CAD-BIM (ArchiCAD10), com recursos de modelagem tridimensional, possvel a visualizao automtica de plantas, cortes, elevaes, alm do modelo 3D, assim como a insero de auto-textos em carimbos. 6.2 Visualizao da informao O sistema CAD geomtrico utilizado no escritrio estudado tanto para desenhos bidimensionais quanto tridimensionais. No entanto, esses desenhos tm pouca ou nenhuma correspondncia automtica, exigindo ao projetista maior tempo para alteraes e atualizaes do projeto. De fato, como observado na utilizao de trs viewports no AutoCAD 2002 por parte do projetista, os desenhos eram completamente independentes entre si, apesar de se referirem mesma informao (corte, planta e perspectiva). No sistema CAD-BIM utilizado no segundo escritrio, na gerao da planta soutilizados elementos que posteriormente so visualizados tridimensionalmente. A cada visualizao que o projetista necessita, a informao apenas reorganizada e apresentada de uma nova maneira, ao invs de ser recriada. Alm disso, modificaes realizadas em uma determinada vista, gera atualizaes automticas nas outras. 6.3 Gerenciamento da informao do projeto No sistema CAD geomtrico, o projetista representa as informaes atravs de desenhos tcnicos com pouca ou nenhuma conexo entre si. Desta maneira, para uma leitura da totalidade da informao do projeto, necessrio um gerenciamento manual desses diversos desenhos, que podem estar em arquivos separados ou em locais diferentes da mesma prancha de desenho. Isso requer constantes transposies das informaes de um local para outro, o que demanda tempo, pode comprometer a qualidade da informao e dificultar o controle de atualizaes e verses. No sistema CAD-BIM possvel criar um modelo que centraliza as informaes, que gravado em um arquivo nico. A centralizao tambm permite que um mesmo elemento d origem a diversas vistas. Por exemplo: um segmento de parede pode ser apresentado em planta, corte e perspectiva, de maneira automtica. Isso garante que, independente da visualizao, a integridade e modificaes da informao passe a ser gerenciada pelo software e no pelo usurio.

VII Workshop Brasileiro de Gesto do Processo de Projetos na Construo de Edifcios - Curitiba - 2007

6.4 Interoperabilidade de sistemas O uso do sistema CAD geomtrico pelo primeiro escritrio estudado garante que as informaes geradas sejam facilmente transferidas entre o escritrio e os seus parceiros Uma vez que grande parte das empresas envolvidas utiliza o mesmo sistema CAD. Por esse motivo, no foram citados problemas referentes confiabilidade dos dados recebidos. No segundo escritrio, apesar do formato padro dos arquivos no ser o utilizado pela maioria dos escritrios (DWG/DXF), o entrevistado no relatou problemas de integridade das informaes nos processos de importao e exportao entre o formato nativo do sistema CAD-BIM (nesse caso, .PLN) e o formato utilizado pelas empresas parceiras.

7. CONCLUSO
O confronto entre os relatos dos processos de projeto nos dois escritrios aponta para as vantagens da utilizao do sistema CAD-BIM em relao ao sistema CAD geomtrico. Foi observado que certas peculiaridades no uso do sistema CAD geomtrico no so consideradas desvantagens por parte do entrevistado. Por exemplo, a velocidade com a qual o projetista efetua as vrias transposies de informaes necessrias para a gerao da documentao, foi citada por ele como um indicativo de alta produtividade. Ainda, segundo o entrevistado, a produtividade cai muito com o uso de um sistema CAD-BIM, pois se perde muito tempo configurando parmetros dos objetos. Porm, considerando que em um sistema CAD-BIM tais transposies sequer seriam necessrias (como foi observado no segundo escritrio), pode estar havendo um desentendimento a respeito da noo de produtividade no processo de projeto. No pareceu, por exemplo, que o projetista que utiliza sistema CAD geomtrico tivesse claro o tempo despendido na gerao manual de cada visualizao bidimensional que se faz necessria. Este tempo pode muito bem superar em vrias vezes o tempo necessrio para a configurao dos parmetros do sistema CAD-BIM. A persistncia no uso do sistema CAD geomtrico tambm pode ser resultado da falta de informao no a respeito da potencialidade dos sistemas CAD-BIM, mas sim de que a sua implantao, em geral, demanda modificaes no prprio processo de projeto. Por exemplo, so comuns os relatos a respeito da dificuldade no preenchimento dos parmetros dos elementos tridimensionais, por conta do hbito dos projetistas de postergar decises projetuais, e no por conta da interface do programa. Apesar das distines entre os dois sistemas CAD estudados, percebeu-se que em ambos os escritrios havia uma clara noo a respeito da importncia do gerenciamento da informao para a qualidade tanto da documentao projetual quanto da qualidade da edificao concluda.

8. REFERNCIAS BIBLIOGRFICAS
BIRX, Glenn W. BIM creates change and opportunity. The American Institute of Architects - Best Practices, 2006a. Disponvel em http://www.aia.org/bestpractices_index. Acessado em: 22.11.2006. ______. Getting started with Building Information Modeling. The American Institute of Architects - Best Practices, 2006b. Disponvel em http://www.aia.org/bestpractices_index. Acessado em: 22.11.2006. KALE, S; ARDITI, D. Diffusion of Computer Aided Design Technology in Architectural Design Practice. Jornal of Construction Engineering and Management (ASCE), v. 131, p. 1135-1141, 2005. SPERLING, David Moreno. O projeto arquitetnico, novas tecnologias de informao e o Museu Guggenhein de Bilbao. II Workshop Nacional Gesto do Processo de Projeto na Construo Civil. Porto Alegre. 2002 Disponvel: www.infohab.org.br Acesso: 17/03/2007

TESTES INICIAIS DO SISTEMA DE MODELAGEM ARCHICAD COMO PR-PROCESSADOR PARA O SISTEMA MESTRE DE ANLISE TRMICA, LUMNICA E ACSTICA DE EDIFICAES
Alosio Leoni Schmid (1); Cervantes Ayres Filho (2)
(1) Programa de Ps-Graduao em Construo Civil, Universidade Federal do Paran, Brasil e-mail: iso@ufpr.br (2) Programa de Ps-Graduao em Construo Civil, Universidade Federal do Paran, Brasil e-mail: ceayres@gmail.com

RESUMO
Sistemas que simulam o desempenho de edifcios a partir da modelagem slida, por comportarem um detalhamento varivel do domnio em questo, podem gerar modelos razoavelmente precisos, que so repassados aos mtodos especficos para anlise de cada aspecto do ambiente. O sistema Mestre, desenvolvido para simulao do desempenho trmico, lumnico e acstico surgiu com esta proposta, procurando solucionar problemas referidos a geometrias exatas de edificaes. O sistema foi desenvolvido com base em arquivos de dados do tipo texto, em que os edifcios eram lidos atravs de seus elementos como paredes, pilares ou lajes tratados em pilha de memria. No entanto, tal processo se mostra moroso, em especial quando o sistema utilizado para propsito didtico, como num curso de graduao em Arquitetura e Urbanismo. Apresentam-se aqui os primeiros resultados da utilizao do sistema ArchiCAD de modelagem de edifcios em conjunto com o sistema Mestre. Ressalte-se que o ArchiCAD pouco tem em comum com os sistemas de desenho por computador mais usuais (CADs genricos), pois representa objetos fsicos atravs de elementos tridimensionais aos quais podem ser atribudas caractersticas do objeto real. Em contraste, os CADs genricos representam objetos fsicos de forma mais abstrata, em geral como agrupamentos de linhas. Considerando-se a similaridade de concepo dos objetos tridimensionais representados tanto pelo ArchiCAD, como pelo sistema Mestre, espera-se uma gil transio da etapa de desenho (modelagem) para a de simulao. Palavras-chave: simulao; modelagem tridimensional; modelagem integrada de edifcio (BIM)

ABSTRACT
Building analysis systems which simulate performance on the basis of a solid modelling allow a variable degree of detail of the analysis domain. More accurate models are generated and can thus fit the needs of each kind analysis to be done on the environment. The Mestre system, developed for the simulation of the thermal, acoustical and visual performance of buildings, is based on such an assumption of shape integrity, dealing with the exact geometry of buildings. The system was developed on the basis of texttype data files in which buildings were input element by element, (wall by wall, beam by beam, etc.) in a memory stack fashion. However, such a data input was proved to be too time consuming, particularly when the system is used for educational purposes. This paper presents the first results of the combined use of the ArchiCAD modeling system with the Mestre analysis system. It should be stressed that ArchiCAD does not resemble conventional CAD systems (generic CAD), as it represents physical by means of three-dimensional elements to which some features of the real object can be assigned. In contrast, the generic CAD system represent physical objects in an abstract fashion, by means of points, lines and surfaces. Considering the similarity of 3-D objects as represented by ArchiCAD as well as by the Mestre system, an agile transition from the designing (modeling) phase to the modeling phase can be expected. Keywords: simulation; 3-D modelling; building integrated modelling (BIM)

- 1697 -

1. INTRODUO
A simulao do desempenho ambiental de edifcios tem experimentado significativo desenvolvimento nas ltimas duas dcadas. Produtos comerciais tm surgido, tornados mais ou menos acessveis aos projetistas. No primeiro caso, prestam-se ao uso por especialistas. No segundo, servem ao amplo pblico e, de maneira especial, revelam-se instrumentos didticos ao demonstrar o peso que tm as decises de projeto. Mencione-se como exemplos, para anlise do desempenho trmico dois sistemas desenvolvidos nos EUA, TRNSYS (KLEIN, 2001), VisualDoe (ARCHENERGY 2007) e, no Brasil, o sistema Arquitrop (USP, 2007); para anlise da iluminao natural, o sistema Radiance (RADIANCE, 2007), desenvolvido nos EUA; para anlise da adequao acstica, o sistema dinamarqus Odeon (ODEON,2007), e para anlise de exposio ao rudo o sistema Soundplan (BRAUNSTEIN & BERNDT, 2007). Como iniciativa de abordar todos os problemas citados num nico sistema, mencione-se o britnico Ecotect (ECOTECT, 2007), que vem ganhando popularidade entre projetistas. O presente trabalho trata de um sistema brasileiro, o Sistema Mestre, apresentado por Schmid (2001; 2001 a, 2004; 2006), foi utilizado em quatro diferentes turmas, por dois anos consecutivos,como instrumento educativo no curso de Arquitetura e Urbanismo da UFPR. Objetivo era mostrar aos alunos de segundo e terceiro ano que as decises de projeto tm conseqncias imediatas no desempenho ambiental dos edifcios projetados. Em 2005 foi utilizado o mdulo trmico/energtico (resultando na marcha horria de temperaturas para cada cmodo, em funo da arquitetura e da energia de calefao fornecida). Havia duas turmas: uma de segundo ano, incumbida do projeto de uma residncia, e outra de terceiro ano, incumbida do projeto de uma Escola de Arquitetura. Ambas as tarefas se tratavam da ltima proposta, no ano letivo, pelos professores de projeto integrado. Na ocasio, o professor da disciplina Conforto Ambiental I (segundo ano) e Conforto Ambiental II (terceiro ano) e dois monitores. Em 2006, foi utilizada uma nova verso do Mestre. Como novidade, acrescentou-se a possibilidade de representao de sombras provocadas pelo sol em dado conjunto de data e hora. Acrescentaram-se funes de visualizao de coordenadas e eventual correo da geometria prvia execuo do programa. novamente o mdulo trmico/energtico com uma turma de segundo ano. O projeto em pauta era de uma biblioteca de bairro. Na turma de terceiro ano, o projeto em pauta era de um auditrio com capacidade para 500 pessoas. Foi utilizado o mdulo de anlise de adequao acstica, desenvolvido entre 2005 e 2006, e prprio para clculo do tempo de reverberao, coeficientes de clareza, e ainda um ps-processamento permitindo a auralizao (audio de exemplos musicais, produzidos a partir de gravaes anecicas de msica e sua convoluo com a resposta impulsiva calculada para o projeto). Embora se possa considerar atingido o objetivo, nas quatro turmas pode se considerar que foi uma atividade desgastante. O Sistema Mestre, at ento, utilizava procedimento de entrada de dados em arquivos-texto, contendo parmetros numricos, at formar uma pilha de objetos como paredes, pilares, materiais e zonas. Quando uma equipe de alunos conseguia completar seu modelo, a anlise apontava a necessidade de modificaes. Se a substituio de materiais era elementar, envolvendo a troca de um nico nmero no arquivo-texto, a alterao da geometria (como por exemplo a criao ou eliminao de aberturas) mostrou-se morosa e foi evitada. Os alunos, em avaliao no sistemtica reconheceram um certo valor da atividade; porm, reivindicaram mais facilidade na entrada e modificao dos dados, tendo sugerido que se desenvolvesse uma comunicao entre o AutoCAD e o Mestre. Ora, tal idia foi refutada de incio, pois dificilmente se concebe uma transio de pontos, linhas e superfcies para um objeto ocupando poro definida e no negocivel do espao, e ainda dotado de massa e de outras propriedades fsicas. No entanto, a partir da proposta de um dos autores, usurio do ArchiCAD, surgiu a iniciativa de desenvolver em parceria a interface de comunicao entre os dois sistemas, que o objeto deste trabalho. O ArchiCAD (GRAPHISOFT, 2007) um software de projeto arquitetnico cujo desenvolvimento teve incio em meados da dcada de 1980, pela empresa hngara Graphisoft. Atualmente o software encontra-se na dcima verso, e considerado um dos produtos mais desenvolvidos no segmento que ocupa. Desde a sua criao, sua proposta foi abordar a atividade de projeto da perspectiva do arquiteto,

- 1698 -

e no do desenhista. Dessa forma, para permitir que o projetista concentre seus esforos na concepo formal e nas solues espaciais e tcnicas, e no na produo do desenho, o software se encarrega de gerenciar automaticamente as informaes necessrias documentao do projeto. O problema de pesquisa que se apresenta : como intercambiar um modelo de edifcio entre o sistema ArchiCAD e o Sistema Mestre, evitando com isso o atual processo de entrada dos dados geomtricos atravs de arquivo texto? Sups-se que a construo de uma interface entre o ArchiCAD e o Sistema Mestre seria uma soluo mais rpida que a construo de uma interface prpria (inserida no Sistema Mestre) para a entrada visual e interativa dos dados para a construo dos modelos dos edifcios. Primeiramente, pelo fato de o ArchiCAD j possuir uma interface completa, intuitiva e estvel para a entrada desses dados. Alm disso, a estrutura de software utilizada no ArchiCAD permite a insero de novas funes ao programa bsico, atravs da utilizao de um conjunto de ferramentas de programao disponibilizadas pelo fabricante a desenvolvedores independentes.

2. OBJETIVOS
O objetivo da pesquisa identificar e desenvolver, numa verso inicial, uma combinao de novas rotinas especficas a serem adicionadas ao ArchiCAD, e de adaptaes das rotinas j existentes no Sistema Mestre, para facilitao e agilizao do processo de anlise ambiental dos projetos.

3. METODOLOGIA
Mais que uma discusso de mtodo, relata-se aqui a seqncia das etapas necessrias ao estabelecimento da interface ArchiCAD Mestre. Etapa 1: orientao aos usurios: preparao de uma srie de instrues ao usurio de ArchiCAD para que, nesta etapa, produza os elementos minimamente necessrios para a gerao de modelos para anlise no Mestre, antes de acrescentar detalhes que no seriam aproveitados nas anlises trmica, lumnica ou acstica; Etapa 2: gerao de sada em texto: modificao dos mtodos do ArchiCAD para gerao de sada em formato-texto, na linguagem C, de modo a registrar as variveis comumente utilizados pelo Mestre; Etapa 3: modificao do Mestre de modo abrir arquivos gerados no ArchiCAD e complementar os modelos, incluindo: Etapa 3.1: gerao de dados de conectividade das zonas para a anlise trmica (isto , criao de zonas com definio de inrcia trmica devida a objetos ali contidos e tambm definio de marchas horrias de gerao de calor e taxas de ventilao e climatizao; atribuio de uma zona do lado de dentro, e outra zona do lado de fora de cada parede ou pavimento definido); Etapa 3.2: atribuio de materiais; Etapa 4: definio de condies particulares de cada anlise (antes feitas no arquivo-texto): data e hora, nebulosidade, ngulo de rotao do conjunto, densidade da malha de insolao e escalas dos grficos. Depois destas quatro operaes, continuar existindo o arquivo-texto. Entretanto, ele ser criado e modificado somente durante a utilizao de programas de alto nvel (interface grfica), no mais em editores de texto.

4. RESULTADOS
A etapa 1 correspondeu seleo dos parmetros ArchiCAD teis modelagem no Mestre. Uma simples parede definida produz um conjunto de XXX variveis.

- 1699 -

A etapa 2 foi realizada mediante cuidadoso trabalho de modificao do mtodo do ArchiCAD que produz sada no formato-texto. As figuras abaixo exemplificam a gerao de um segmento de arquivotexto j legvel ao Mestre como parte de uma pilha.

Ilustrao 1 - exemplo de parede no ArchiCAD, em planta

Ilustrao 2 - exemplo de parede no ArchiCAD, em perspectiva //Arquivo exportado do AC10 para o programa Mestre // //Paredes // //p x y z azi alt larg esp h mat zf // p 0.1 0 0 90 0 1 0.1 2 66 0 p 0 0 0 0 0 1 0.1 2 66 0 p 1 0 0 45 0 1.41421 0.1 2 66 0 //Fim do documento exportado

zi 0 0 0

n 25 Parede 90 25 Parede 0 25 Parede 45

Ilustrao 3 - trecho de arquivo de dados para o Mestre, gerado em mtodo acrescentado ao ArchiCAD

Etapa 3.1: gerao de dados de conectividade das zonas para a anlise trmica (isto , criao de zonas com definio de inrcia trmica devida a objetos ali contidos e tambm definio de marchas horrias

- 1700 -

de gerao de calor e taxas de ventilao e climatizao; atribuio de uma zona do lado de dentro, e outra zona do lado de fora de cada parede ou pavimento definido); - aqui, ser implementado um algoritmo de identificao de espaos, a compreender os seguintes passos: - identificam-se pontos de coordenadas ortogonais (X,Y,Z) extremas do domnio em pauta; - gera-se malha de pontos para identificao de zona, com espaamento menor que a menor dimenso das superfcies; - de cada um deste ponto, geram-se NN direes e identifica-se quais as superfcies encontradas por vetores partindo do ponto, em cada direo; - cada zona diferente (isto , cada diferente espao fechado) ganha um nmero ascendente, at percorrida toda a malha; - o usurio recebe solicitao de atribuir variveis bsicas a cada zona identificada, inclusive duas zonas externas (o ar externo e o solo externo); - o usurio recebe solicitao de atribuir um material a cada elemento slido ou presente no modelo; para tanto, o sistema Mestre oferece uma lista de materiais com propriedades fsicas pr-definidas, ou permite ainda criao de novos materiais; - ao solicitar uma nova simulao, o usurio ainda solicitado a definir condies gerais como data e hora no caso de simulao trmica; coordenadas de fonte e ouvinte, no caso de acstica; condies do cu, no caso da simulao lumnica.

Ilustrao 4 - algoritmo de reconhecimento de zonas

Uma ilustrao do procedimento de reconhecimento de zonas apresentada na Ilustrao 4.

5. DISCUSSO
Deve-se considerar que os testes prticos realizados no Mestre foram feitos pelos prprios autores, os quais no tm o distanciamento crtico de um usurio no seu dia-a-dia, de estudante ou de profissional. O Sistema Mestre continua exigindo do usurio a entrada dos mesmos dados que anteriormente, embora de forma diferente. Para efeito didtico ou profissional, a simulao sugere pleno conhecimento do objeto modelado e simulado. No entanto, a criao e as modificaes do modelo geomtrico devem ser enormemente facilitadas.

- 1701 -

Com isso espera-se que o uso do sistema Mestre possa se popularizar como ferramenta auxiliar de projeto. No entanto, este desenvolvimento depende, tambm, da disseminao do ArchiCAD, o qual, por sua vez, demanda do usurio uma abordagem diferenciada durante as etapas do projeto.

6. CONCLUSES
Nesta pesquisa mostrou-se a viabilidade de se associar um sistema de simulao do desempenho fsico de edifcios o Mestre a um sistema de projeto arquitetnico j amadurecido comercialmente o ArchiCAD, - com vantagens j evidentes na gerao de modelos. Uma das grandes vantagens poderia ser maior agilidade na criao e reparao de modelos, permitindo o exame de um nmero maior de alternativas de solues arquitetnicas nas fases de estudo preliminar e anteprojeto. Outra seria um efeito de sinergia: a maior popularizao, principalmente entre estudantes, do ArchiCAD, sistema de projeto por modelagem do tipo building information modelling. Os autores acreditam em expressivo acrscimo de produtividade e qualidade no processo de projeto associado ao uso de tal ferramenta.

7. REFERNCIAS BIBLIOGRFICAS
SCHMID, A. L. . Simulao de desempenho trmico em mltiplas zonas: MESTRE, um sistema brasileiro na linguagem Java In: VI Encontro Nacional e III Encontro Latino-americano sobre Conforto no Ambiente Construdo, ANTAC: S. Pedro (SP), 2001. SCHMID, A. L. . Daylighting and Insolation in High-density Urban Zones: How Simulation Supported a New Law in Curitiba. In: Building Simulation 2001, 2001, Rio de Janeiro. Building Simulation 2001, 2001. v. 1. SCHMID, A. L. . Simulao da luz natural: combinao dos algoritmos de raytracing e radiosidade e suas aplicaes na Arquitetura. Ambiente construdo, Porto Alegre, v. 4, n. 2, p. 51-59, 2004. SCHMID, A. L. . Acstica arquitetnica e auralizao no sistema Mestre de simulao de edifcios. Pster e artigo apresentado nos anais do encontro anual da Sociedade Brasileira de Acstica. SOBRAC: So Paulo, 2006. USP LABAUT. Pginas sobre sistemas computacionais disponveis para download no endereo: http://www.usp.br/fau/pesquisa_sn/laboratorios/labaut/conforto/conforto.html. Acesso em 14/05/ 2007. GRAPHISOFT. GraphiSoft ArchiCAD 10 Reference Guide. Obtido da GraphiSoft Homepage, que est disponvel em http://www.GraphiSoft.com Acesso em 14/05/2007. RADIANCE. Pginas do sistema de anlise Radiance, disponveis em http://www.radiance-online.org. Acesso em 14/05/2007. KLEIN, S.A. et al. TRNSYS 15, A transient simulation program. Solar Energy Laboratory, Universidade de Wisconsin, Madison, Wisconsin, USA, 2001. ARCHENERGY. Pginas a respeito do sistema de anlise Visual Doe 4.0. Disponveis no endereo http://www.archenergy.com/products/visualdoe//, acesso em 14/05/2007 ODEON. Pginas a respeito do sistema de anlise Odeon http://www.dat.dtu.dk/~odeon/about.htm, acesso em 14/05/2007. disponveis no endereo

BRAUNSTEIN & BERNDT. Pginas a respeito do sistema de anlise Soundplan, disponveis no endereo http://www.soundplan.com, acesso em 14/05/2007. ECOTECT. Pginas a respeito do sistema de anlise Ecotect, disponveis no endereo www.ecotect.com, acesso em 14/05/2007.

- 1702 -

IABSE Conference - 2008 - Helsinki, Finland

Parametric objects to represent concrete blocks


Cervantes AYRES Filho Architect, MSc Candidate PPGCC UFPR Curitiba, Brazil
cervantes.ayres@gmail.com

Fabola AZUMA Civil Engineer, MSc Candidate PPGCC UFPR Curitiba, Brazil
fabiolaazuma@yahoo.com.br

Sergio SCHEER DSc, Associate Professor PPGCC UFPR Curitiba, Brazil


scheer@ufpr.br

Summary
In CAD systems based on the concept of BIM (Building Information Modeling) BIM CADs, each construction component is represented by a parametric object that encapsulates information such as space attributes, descriptive attributes and a specific behavior. In one recent project for small public buildings construction in the state of Santa Catarina, Brazil, the designers had opted to use these objects to represent a constructive system based on structural masonry with standardized concrete blocks. Through the use of these objects it was possible to guide the designers during the drawings and consequently avoid errors of conception. Furthermore, the use of these objects allowed generating drawing details and bricklayer position automatically, thus reducing the time consuming in this task. Keywords: BIM; parametric solid modeling; parametric objects; concrete blocks masonry

1. BIM, CAD and parametric modeling


Several authors define BIM (Building Information Modeling) as the process of managing the information involved in the whole building life cycle [1-5]. Among the various computer systems that give support to BIM, Lee et al. [6] emphasize the fundamental role of the new generation of CAD (Computer Aided Design) systems, since the production of accurate and reliable graphical information is essential for the AEC industry. In addition to three-dimensional modeling, feature that is present in other types of CAD, the CAD systems that support the BIM process add semantic to the geometric and spatial information current in the design. In these systems (called deliberately here as BIM CADs), the three-dimensional model of the building is composed of a set of objects that represent not only the appearance but also the behavior of each constructive element, enabling both the operator and the machine to interpret the information significance unequivocally [7]. Because they are semantically rich, the models generated by BIM CADs allow the automation of various design process stages, including the detailing generation and quantities takeoffs. The three-dimensional parametric modeling is the representation of geometric solids through primitives (basic forms as prisms, spheres, cylinders) that are defined by algebraic expressions [8]. From the algebraic expression processing rises a temporary representation of the model. This kind of representation is quickly processed and easily edited: by changing the parameters used in the model construction, the solid is instantly reconstructed by the computer. Another differential of the three-dimensional parametric modeling is the ability to encapsulate different behaviors in the objects, thus, making them sensitive to the

IABSE Conference - 2008 - Helsinki, Finland

context where they are inserted. As it were, it is possible for the objects to interact with others, besides to respond for specific situations with the proper graphical representation [7]. As a result of their ability to add meaning for the geometric elements, the three-dimensional parametric modeling is the basis of the best known BIM CADs, such as: ArchiCAD from Graphisoft, Revit from Autodesk, Bentley CAD systems and AllPlan from Nemetschek.

2. Case study: parametric representation of concrete block walls


2.1 Motivation In 2006, the Santa Catarina State Government, a southern region state in Brazil, promoted an architectural design competition for small public buildings construction. The key concept adopted by the architects for the design presented in this paper was the structural masonry constructive system, composed of concrete blocks units. This constructive system was chosen because it responded well to issues like material availability, quality, durability and economy in the constructive process. For a better understanding of the constructive system employed and the tools developed for this design, the following section shows a brief explanation of concrete block masonry currently used in Brazil. 2.2 Concrete block masonry in Brazil The masonry is the most used constructive system in Brazil, despite of the construction size. It has been present during the entire history of Brazilian cities formation and consequently holds a strong cultural appeal [9]. In general, the typical buildings are associations between fired clay bricks masonry with reinforced concrete frames, and they are produced by constructive processes with low industrialization and high levels of waste. One of the ways to improve the performance of the construction processes without letting away the cultural aspect that associates the masonry with solid and durable buildings is the adoption of structural concrete block masonry. This type of masonry is a rationalized constructive system, able to reduce the construction final costs considerably, if compared with the traditional masonry. Although, Pfeifer et al. [10] stress that such benefits depend on the architectural project to take account some specific issues: Modular coordination: the concrete blocks masonry is composed by basic blocks which are industrialized and standardized. In order to maximize the constructive system performance, the construction measures should be multiple dimensions of these basic blocks. Avoiding adjustments in building sites: the productivity rates potentially obtained by the concrete block masonry rationalization are negatively affected by situations that require cutting or adjustment of the blocks. Besides the time consuming by these operations, there is the risk of waste of materials with high value added. Limiting the number of block types: blocks which length size is multiple of the width size (e.g. 15 x 30 cm or 20 x 40 cm) improve the system performance, because they eliminate the need for special units for adjustment of the modulation difference between the sizes.

IABSE Conference - 2008 - Helsinki, Finland

Concurrent Engineering: some common practices in the conventional masonry construction in Brazil are not admitted in concrete block masonry construction. A typical situation is the horizontal cuts for pipes passage, usually made after the wall completion [11]. In concrete blocks masonry, all technical facilities should be planned, taking into consideration the suitable blocks for each situation. The potential rationalization offered by concrete blocks masonry depends on the detailed representation of the units, including the position and type of each block used. Overall, for a building with this constructive system, it is expected that the design documentation holds an executive character, with drawings that represents faithfully each wall of the building. In Brazil, this requirement can be considered an obstacle to a more effective dissemination of structural concrete blocks masonry, since the typical building design documentation is low-detailed [12]. 2.3 Parametric objects for concrete block masonry design The documentation generation through process based solely on two-dimension drawings is an expensive and time consuming task, besides being human error-prone. Design process based on product modeling, such as BIM, are admittedly more rapid and efficient; both for the way the information are organized and the possibility of automation in various design stages. However, there are some obstacles. In the architectural design analyzed in this paper, the software ArchiCAD 10 (Graphisoft/Nemetschek) [13] was used. ArchiCAD is an object-oriented CAD that had been developed for more than 20 years. Although ArchiCAD holds all the characteristics of information managing related to any BIM CAD (even being older than the expression BIM), it does not meet adequately some specific (and regional) aspects of the constructive system used. Ibrahim et al. [2] describes a similar situation, explaining the possibility of developing distributed BIM systems, with communication between different applications meeting the various skills involved in the design process. In order to allow the specialization and regionalization of the software standard version, the manufacturers offer the possibility of creating custom tools, which add new features to the CAD systems. These tools are created by two basic ways: macros scripts which hold command sequences that automate functions and plug-ins applications added to the original software that may lead to interface modifications, new controls or ways to process information. In ArchiCAD, these two ways of creating custom tools are respectively the GDL (Geometric Description Language) and the API (Application Programming Interface Development Kit). The GDL is a structured programming language relatively simple, accessible from the ArchiCAD standard interface and able to produce any kind of geometric object besides adding specific behavior for each type of graphic representation required. The API is a set of libraries and access rules which allows the creation of more elaborate tools through a compilation of a code in C++ programming language. As the GDL showed faster and easier development, it was chosen for the making of parametric objects able to represent the concrete block masonry walls in ArchiCAD. Modeling each block individually was considered an impracticable task since the beginning of the objects development: although it could generate an accurate representation of the constructive system, it would demand a very long draft time during the design process, in addition to a CPU and storage capacity much powerful than those available.

IABSE Conference - 2008 - Helsinki, Finland

Sacks et al. describe the negative effects on the building modeling process when very small or over-detailed objects are used in the early design stages, which is called bottom-up modeling. In other hand, the ArchiCAD native wall objects are, generally, basic prisms with limited behaviors, and their use does not allow the documentation automation with the detailing level required for the constructive system used. As an alternative, the parametric objects developed combined these two characteristics: they were handled as wall objects (prisms), simplifying the edition in the early stages, but also generating automatically the graphical representation of all concrete blocks arranged. This approach made easier the handling of the design elements besides to ensuring the information richness necessary for the documentation automation. 2.4 Parametric objects development After the architects definition of the desired characteristics of the walls, sketches of the expected result were used to guide the programming process. The GDL programming requires no further tools (excepting the ArchiCAD) and it is made in text edition windows, which are accessible from the software main menu. The GDL syntax is similar to that one of Visual Basic and the commands are relatively simple for people with basic programming skills. The code generated is a structured algorithm (fig. 1), which guides the geometric primitives creation in accordance with specific variables (e.g. wall width or height, block type, etc). These variables are first defined in the code, and then linked to meta-parameters in a specific panel (fig. 2), in which is possible to determine their constraints and metrics. These meta-parameters will originate the parameters that can be edited by the user during the object utilization.

Fig. 1: This part of GDL code generates a prismatic form to represent a single concrete block .

Fig. 2: Object parameters configuration during the programation stage.

2.5 Parametric objects usage The use of parametric objects involves two graphical interfaces. In the ArchiCAD edition window usually in the floor plan view occurs the insertion and definition of the position and length of the object that will represent the blocks wall (fig. 3). It was chosen to limit the number of configurable parameters directly in the floor plan in order to facilitate the use of the object in the initial stages of the design development. The second interface is the options panel, where the complementary parameters are defined (fig. 4). Through this panel it is possible to visualize the combination resulted from the different parameters chosen before returning to the main edition window. This options panel is part of the ArchiCAD graphical interface and it is generated automatically from the meta-parameters defined during the objects development.

IABSE Conference - 2008 - Helsinki, Finland

Fig. 3: Insertion of the parametric object in floor plan and length edition limited by the block basic module.

Fig. 4: Settings panel of a parametric wall object.

The modular coordination is essential to the design with concrete blocks and it was the major constraint applied to the parametric objects meta-parameters. When the objects are dimensioned, the length is increased in multiples of the block size used, since the blocks cutting dramatically reduces the constructive system performance. Following the BIM CADs standard, there are parameters to control the representation of the parametric objects in the four types of visualization: floor plan, section, elevation and perspective. This ensures that the object behaves appropriately in each situation. For example, the walls intercepted by the imaginary cut plan of the selected view are hatched while the others are not (fig. 5 and 6). When viewed in the elevation, the objects represent all blocks automatically (fig. 7). All the views, including the perspective (fig. 8) are automatically generated.

Fig. 5: Floorplan view

Fig. 6: Section view

Fig. 7: Elevation view

Fig. 8: Perspective view

The amount of information to be displayed (i.e. detailing) is controlled by parameters which interpret the ArchiCAD active view global settings. Thus, selecting a representation scale for the active view causes an automatic updating of all objects visualized (fig. 9). Another function that uses the global settings was the generation of the different bricklayers plans automatically. Through the changing of cut plan height in floor plan view, the objects are updated, showing the configuration of the bricklayer intersected by the new height (fig. 10). This functionality was essential to speed up the document generation (bricklayers plans) necessary for the masonry construction, and also reduced dramatically (if not eliminated by complete) the detailing stages.

IABSE Conference - 2008 - Helsinki, Finland

1:25

1:100
Fig. 9: Two automatic representations of the same parametric object, according to the plan scale selected. Fig. 10: Automatic representation of the same object of figure 5, but showing another bricklayer.

Through additional code it is possible to aggregate other functions to parametric objects beyond the basic wall objects: they also could be configured to represent complementary constructive elements, such as window sills, lintels, parapet walls, screen elements and so on. The association of different parametric objects configuration with ArchiCAD native elements (slabs, roofs, furniture) leads to the complete building model (fig. 11).

Fig. 11: Building model perspective view.

The CAD BIM technology key features, improved by the creation of parametric objects, made possible the detailed document information extraction directly from the model. The figure 12 shows a bricklayer plan extracted automatically from the model displayed in figure 11. All masonry graphical representations are automated and it is necessary only to complement the drawings with textual information, which is also made in ArchiCAD.

Fig. 12: Bricklayer plan generated automatically.

IABSE Conference - 2008 - Helsinki, Finland

3. Conclusions
The creation of parametric objects to specialize the BIM CAD capabilities proved to be a viable technique, and it added benefits to the design process such as draft time reduction, possibility of information reuse, better resolution of spatial interferences and better quality of final documentation. Unfortunately, the competition for which the designs were intended was canceled after the election of the new governor of the Santa Catarina State, and thus, the design development were interrupted. The use of parametric objects in the design process also revealed some features to be improved. The main improvement is to increase the objects contextual intelligence. For instance, it would be convenient if the objects could identify the proximity of other parametric objects and thus could configure the mortar joints and parallels automatically. This type of function requires a more complex computer application development, through the API. The use of API would also allow two other improvements considered necessary by the users: Meta-objects: A special interface could be provided allowing the creation of new parametric objects from basic concrete blocks units combination. This approach could include new bricklayer and bonding types (in this design, only the stack bond was used for aesthetic reasons). The purpose of this improvement is the elimination of the GDL programming task, which demands a skill rarely available at architecture offices. Top-down modeling support: the objects should be even more flexible and easily editable in the early design stages [6]. Such improvements could be implemented by following the existing tools approach, which converts simple wall objects (ArchiCAD natives) in a set of objects that represents faithfully the wood or light steel frame panels [14]. Despite the short period of usage, the parametric objects showed to be stable and reliable. Their benefits, allied to the rising demand for specialized applications which support the construction information management, make this approach to be an important issue for future studies.

4. References
[1] TSE, T. K.; WONG, K. A.; WONG, K. F. The utilization of building information models in nD modelling: A study of data interfacing and adoption barriers, ITcon. Vol. 10, 2005, pp. 85110. Available from http://www.itcon.org/data/works/att/2005_8.content.05676.pdf IBRAHIM, M.; KRAWCZYK, R.; SCHIPPOREIT, G. Two Approaches to BIM: A Comparative Study, eCAADe Conference, 2004. Available from http://cumincad.scix.net/data/works/att/2004_610.content.pdf MOUM, A. A framework for exploring the ICT impact on the architectural design process, ITcon. Vol. 11, 2006, pp. 409-425. Available from http://www.itcon.org/data/works/att/2006_30.content.07890.pdf MAO, W.; ZHU, Y.; AHMAD, I. Applying metadata models to unstructured content of construction documents: A view-based approach, Automation in Construction. Vol. 16, No. 2, 2007, pp. 242-252. Available from http://linkinghub.elsevier.com/retrieve/pii/S0926580506000203

[2]

[3]

[4]

IABSE Conference - 2008 - Helsinki, Finland

[5]

CAMPBELL, D. A. Building information modeling: the Web3D application for AEC, Proceedings of the twelfth international conference on 3D web technology, 2007, pp. 173-176. Available from http://portal.acm.org/ft_gateway.cfm?id=1229422&type=pdf&coll=GUIDE&dl= GUIDE&CFID=23642874&CFTOKEN=31571100 LEE, G.; SACKS, R.; EASTMAN, C. M. Specifying parametric building object behavior (BOB) for a building information modeling system, Automation in Construction, Vol. 15, No. 6, 2006, pp. 758-776. Available from http://www.sciencedirect.com/science/journal/09265805 SACKS, R.; EASTMAN, C. M.; LEE, G. Parametric 3D modeling in building construction with examples from precast concrete, Automation in Construction. Vol. 13, No. 3, 2004, pp. 291-312. Available from http://linkinghub.elsevier.com/retrieve/pii/S0926580503000438 MONEDERO, J. Parametric design: a review and some experiences, Automation in Construction. Vol. 9, No. 4, 2000, pp. 369-377. Available from http://linkinghub.elsevier.com/retrieve/pii/S0926580599000205 SILVA, M. M. A. Diretrizes para o projeto de alvenarias de vedao, MSc. Thesis, Escola Politcnica da Universidade de So Paulo, 2004. Available from http://www.teses.usp.br/teses/disponiveis/3/3146/tde-01032004-150128 PFEIFER, G.; RAMCKE, R.; ACHTZIGER, J.; ZILCH, K. Masonry Construction Manual. Birkhuser/Detail, 2001. PRUDENCIO JR, L. R.; OLIVEIRA, A. L.; BEDIN, C. A. Alvenaria estrutural de blocos de concreto. ABCP, 2002. FABRICIO, M. M.; MELHADO, S. B.; BAA, J. L. Brief Reflection on Improvement of Design Process Efficiency in Brazilian Building Projects, Proceedings IGLC. Vol. 7, pp. 345. Available from http://docentes.pcc.usp.br/silviobm/Publica%C3%A7%C3%B5es%20PDF/Fabric io&Melhado&Baia.pdf GRAPHISOFT. ArchiCAD 10 User Guide. Available from http://www.graphisoft.com CADIMAGE. Cadimage Tools - Wall Framing. Available from http://www.cadimagetools.com/tools.aspx?id=4

[6]

[7]

[8]

[9]

[10] [11] [12]

[13] [14]

CAD-BIM REQUERIMENTS FOR MASONRY DESIGN PROCESS OF CONCRETE BLOCKS

AYRES FILHO, CERVANTES MSc candidate of the Civil Construction Postgraduate Program at the Federal University of Paran UFPR. e-mail: ceayres@gmail.com

SCHEER, SRGIO Associate Professor of the Construction Engineering Department at the Federal University of Paran UFPR. Civil Engineering Research Centre, CEP 81.531-980, Cx. Postal 19.011, Curitiba, Paran State, BRASIL. e-mail: scheer@ufpr.br.

AZUMA, FABOLA MSc candidate of the Civil Construction Postgraduate Program at the Federal University of Paran UFPR. e-mail: fabiolaazuma@yahoo.com.br

BEBER, MICHELLE MSc candidate of the Civil Construction Postgraduate Program at the Federal University of Paran - UFPR. e-mail: mi_arq@yahoo.com.br

The masonry constructive technique of concrete blocks is a practice that contributes for a high level of industrialization in construction in addition to achieve the rationalization in this sector. The achievement of these benefits demands some design features such as modular coordination, blocks rows details and well documented and precise specifications. One solution to meet these design features without causing agility reduction during the process is the use of CAD-BIM (Building Information Modeling), which applies modeling and visualization techniques already consolidated in other industry branches. Although the CAD-BIM brings improvements in the design process, it does not provide tools aimed directly to blocks masonry design, what can cause difficulties. The goal of this work is to identify these problems through a case study in a builder office sited in Curitiba, Parana state, Brazil, which is specialized in building design of concrete blocks masonry. Based on the results of data collected in the case study and in the literature available was possible to develop a list of CAD-BIM requirements more suitable for this kind of design. Key-words: CAD, BIM, concrete blocks masonry.

1.

INTRODCTION: THE USE OF INFORMATION TECHNOLOGY IN THE PROCESS DESIGN

The use of communications and information technologies in the building industry is creating new opportunities for collaboration, coordination, and information exchange among organizations that work on a construction project (Caldas e Soibeman, 2003). These aspects contribute for the design accuracy and consequently result on a proper building execution. Moreover, there are also technologies such as presented by Ganah et al. (2005), developed to assist design teams in communicating design details that may be problematic for construction teams. In the design phase, the CAD technology represents one of the most influential information technology innovations of the last four decades and offer resources for drafts and design automation, communication and design and data base exchange (Kale e Arditi, 2005). The new generation of CAD systems is recognized by Building Information Modeling BIM, which can be described as the process of creating and managing building information in an interoperable and reusable way. Thus, BIM is a system that enables users to integrate and reuse building information and domain knowledge through the building lifecycle. Therefore, through a BIM model it is possible to encapsulate building knowledge in such a way that each object represented is able to hold an intelligent behavior in accordance with the context of their application (Lee et al. 2006). Given these characteristics, the BIM approach is considered a proper solution for the development of specialized objects, which is able to represent the relevant characteristics of a masonry design. Thus, the design documentation could be automated in order to facilitate the representation of constructive details and as a consequence, contribute for the adequate construction in the site build. 2. APPROACHES FOR THE DESIGN DOCUMENTATION AUTOMATION

The development of a tool to automate the design documentation could basically follow two directions: an independent application or an associate application, which could be a plug-in to a BIM CAD. The advantages and disadvantages of each approach are described below: Independent application: this approach would demand the development of a tool completely independent of others BIM CADs, although it could be used together. The key element of this approach is the reading of a file which holds the virtual model, preferable in IFC (Industry Foundation Classes) format. In such a way, the building model can be read by the main BIM CAD. The major advantage of this approach is the flexibility offered by the independency of proprietary formats that interact in the BIM process. Among the disadvantages is the enormous effort required to develop function and interfaces already available in BIM CADs: even applications specifically developed to defined process design stages, such as Tekla (Tekla, 2008) or the Ecotect (Square One, 2008) demand basic functions of object creation. Other disadvantage is the instability of IFC model, which still present some conversion problems between different applications. Associate application: in this case, it would be developed a tool which could act from the main interface of the BIM CAD available in the market. This approach uses the basic functions already available in BIM CADs and focus in the automation of the masonry design documentation. The main disadvantage is in lack of flexibility, which would demand a new programming for each BIM CAD and also for each version of BIM CAD.

This article focuses on the second approach and demonstrates the key situations to be faced by a tool regarding to the automation of design documentation for masonry construction. This choice was due to the fact that a complete implementation (first approach) would only demand solutions to interfaces and basic functions, which are already described by the guides of major BIM CADs (Graphisoft, 2008; Autodesk, 2008; Nemetsheck, 2008; Bentley, 2008). One of the BIM CADs principles, regardless of the manufacture, is the automated extraction of information from a model composed of objects that represent constructive elements of the designed building. Therefore, among the functions there are routines responsible for automating much of design documentation such as sections views, elevations, perspectives, layouts and quantities takeoff (Ibrahim et al., 2004; Tse et al., 2005; Moum, 2006; Mao et al., 2007; Campbell, 2007). These routines are important agents for improving de design process, but usually they only correspond to generic situations. In such a way, the specifics characteristics of the constructive system are designed by the project team without the BIM CAD support. This aspect is in part result of the business strategy adopted by the BIM CADs manufactures, which invest primarily in the improvement of basic interfaces and in the more generic features to make the product adaptable to the largest number of consumers in the worldwide. To compensate this lack of detail about the constructive systems or specific regions, the manufactures advice the possibility of improving the basic functions of their applications. Below are described the main ways to do it with the focus in a tool to automate the design documentation for masonry construction. Configuration of native parametric objects: the objects called wall in BIM CADs can be modified to behave as compositions of blocks or bricks. It only demands the configuration of the filling material, to represent blocks or bricks in sections views, and the external textures to represent their faces in the views and perspectives. This configuration is the easiest way to automate the masonry design documentation, and if it were implemented in a suitable way, can support the level of information required for this constructive system. However, this approach demands the management of all designers involved in order to verify the correct representation of the filling material in sections and the block faces textures in views. Moreover, the use of generic textures in the wall faces, although represent visually the course, do not embody intelligence in the object. It is not possible to; for instance, indicate the insertion of special blocks for modular adjustment or for facilities. Templates: packages containing standards of graphic representation and rules for the creation of parametric objects which will represent the constructive elements. These patterns are consistent with the local regulations or with the standard guides of architectural offices and their use may prevent the designer to create elements that were not pre-defined. The templates assume great importance for the masonry design documentation because they hold options for blocks, course and coatings. Special parametric objects: they are more detailed and flexible representation of constructive element created separately from the building model and later inserted. In previous experiences of this research group, parametric objects to represent concrete brick walls shown to be very useful for automation of design documentation.

Scripts and macros: tools that automate processes through algorithms composed of sequence of commands which trigger BIM CAD functions. Like the special parametric objects, they shown great useful in previous experiences, where scripts were created to automate the objects replication of concrete blocks in order to compose a complete wall. The limitation of their functionality is directly related with the scope limitation of the programming language used to generate the algorithms. In the ArchiCAD, for example, the programming language used in the scripts is not able to access all data of the building model, and the contextual intelligence of the object can be compromised. Association with auxiliary data bases: function that allows associating the specific parameters of each parametric object (e. g. wall area) with generic data, inserted in auxiliary data bases (e. g. number of blocks per square meter). The data bases can be created from the BIM CAD or external to it. This is a very flexible approach to the data extraction from the building model because it eliminates the need to create new parameters in the objects each time that new information is required. Although it is a excellent alternative for quantities take-off, this approach do not solve the graphical representation of the composition of masonry wall: it is possible to know the number of blocks based on the area consuming index, but it is not possible to know the position of these blocks in the wall. API (Application programming interface): are packages of functions and access rules to be inserted in new applications, which allow the communication with the application core of BIM CAD and their data structure. The main BIM CADs offer this alternative for software developers to permit the creation of new application that is able to improve the basic processes. The applications developed with the APIs holds unrestricted access to the building model data, which make this approach the most powerful among all presented. 3. FEATURES TO BE CONSIDERED IN THE AUTOMATION OF MASONRY DOCUMENTATION DESIGN The following topics are related to the main features to be offered by a tool specialized in the automation of masonry design documentation through a BIM CAD. Top-down modeling: During the early stages of a building design there is a great number of indeterminations related to the architectural spaces, constructive systems and materials to be used. In theses phases, parametric objects should behave in a generic and abstract way, in order to permit the agile handle and successive updates. As the design process continues, the parametric objects must be able to store more detailed information and to behave in a more specific way (Lee et al., 2006). One disadvantage of using excessively determinants and complex parametric objects in the early stages of building modeling is overloading the designer with information that will be determinate only in the later stages. Cheng (2006) advice for the fact that very complex parametric objects can damage the experimentation process that is inherent in the architectural conception. Behavior of objects: parametric objects are the essential of BIM CADs. They associate the description of constructive elements to behaviors that define, among others possibilities, the way the object must be graphically represented in each design view (floor plan view, elevation, section and perspective). The tool must, therefore, generate behaviors to the parametric objects in order to automate the masonry wall representation in any view selected by the user. This ability would allow

the automatic extraction of masonry course plan, sections views, wall elevation, including the blocks indication, and perspectives that support the understanding of assembling elements. Blocks and Bricks: they are the masonry basic units and vary considerable in accordance with the geographic region. Therefore, the tool must support various unit types and should also be possible to create new ones from the descriptions provided by the user. Different types of block or brick can be used in the same building (e. g. external or internal walls). Hence, this feature should be a parameter of an object that represents the wall. Course: they refer to the basic unit laying and vary considerable in accordance with the local (as the blocks and bricks) and also in accordance with the basic unit selected. Thus it should also be possible to create new course types through the description of its basic rules. Another critical aspect is the correct interpretation of the basic unit, regardless the laying position (e.g. header, stretcher, brick-onedge or soldier courses). Modular coordination and neutral zones support: based on the block and on the course selected, dimension updates in the object would be limited by multiple modules of the basic units. Dimensions that are not suitable for the modulation would be clearly shown to the designer (e.g. through hatches). In such a case, there should be at least two possibilities: insert automatically units or materials for the adjustment, in accordance with the bound rules; or advice the user about the constructive interferences in order to give the option for the user to do the modular adjustment or resize the problematic objects. Wall openings: the tool should make the automatic shifting of the wall openings (or at least suggested it) which is not in accordance with the basic unit modulation. Furthermore, based on user definition, should be included automatically frames, window sill elements and lintels, etc. Wall interfaces: the joint toothed intersection masonry demand elements which extend beyond the geometric limits of the objects. An example is the joints with intercalated courses (in which the blocks of odd and even courses are interposed in a way to transfer strengths between different plans); wire meshes and reinforced steel bar (Pfeifer et al., 2001). The resolution of this situation depends on the object ability to recognize properly the context where it is inserted, adapting itself. Interfaces with other constructive elements: the tool must automatically adjust the parametric object in situations where it meets other elements such as slabs, columns, beams, foundations etc., in a way to insert the necessary components. A typical example would be the automatic insertion of special blocks as channels blocks in the last wall course, if there is a parametric object above them to represent a slab. Gable walls: wall plans sectioned diagonally present a special challenge. Their graphical representation must consider a wall as an irregular polygon (at least one trapeze), and there may be several different angles resulting from the section operations executed in the object. One very useful function would be the recommendation for user about the better section angle which would result in the fewer block waste, considering the setting of the courses selected.

Facilities: an essential function for the tool is the indication of the facilities position (electrical, hydraulic, logic, etc.) in a way to permit, from the rules settled by the user, the automatic identification of special blocks for the passage of tubes. Structural function: defining a wall with structural function opens a new range of situations to be considered by the tool. Therefore, a tool should represent the horizontal reinforcement and columns, conformed by the masonry hollow blocks, and also the steel anchor of these elements. This situation should be addressed by an approach similar to the item facilities: through the identification of elements position by the user. A more advanced tool version should even insert the structural elements automatically, based on the gaps and loads defined by the user. Coatings: in addition to represent the basic units which make up the masonry, a tool should be able to associate multiple layers of coatings, and also to quantify the components used in these layers. The tool should also be able to interpret the design context (design stage, scale, and view) to decide whether the coating should be represented or not. In the architectural design, for instance, visualize the masonry units is unfavorable to the correct data interpretation (unless it refers to a facing brickwork). In the masonry design execution, the visualization of coatings is unfavorable to the information understanding. Quantities take-off: the object created by the tool should include information regarding the components consumption to permit the automatic material quantification, based on their coverage or volume. The tool should offer functions for automatic report extraction, based on the features presented in the major BIM CADs. A more advanced tool version, regarding this function, should also consider the model section (e.g. by stories) and the place for the material delivery. Standard guides: in addition to automate the graphical representation of masonry elements, a tool should also automate the requirement description for construction. From the data insertion in the auxiliary data bases, the BIM CAD is able to automatically associate the descriptions and indications in the drawings and in schedules separately, when a specific object fit in particular criterion previous established. For example, to insert a tag with the text Follow NBR 8798:1985 in all drawings that contain wall composed of hollow blocks structural masonry. 5. SUGGESTION FOR A PROCESSING TOOL MODEL From the associate application approach of a BIM CAD and also from the features to be considered by the tool, a suggestion for a processing model was developed, which should be adopted by a tool addressed to automate the design documentation of masonry construction. Briefly, the processing executed by the tool would implement a set of basic objects to generate specific objects, which would contain necessary representations in order to automate the design documentation. One possible solution to represent constructive detail of masonry wall would be the threedimensional representation of each block that constitutes them. Although it is possible to automate this task, previous experiences of this research group showed that it would demand high processing capacity, besides to generate files which contain dozens of megabytes, even considering simple construction. To create three-dimensional objects to represent facing bricks may be a good option, but in many cases (perhaps most of them), the masonry will be coated and the view of position of

each block is used only in the execution documentation. Alternatively, the presented suggestion would be useful if a tool generated temporary two-dimensional representation, which could result in a more fast processing and suitable to the view required by the user. The main steps of the use of the tool are described below. Reference object creation: the constructive representation of masonry wall detail would be executed automatically by specialized parametric objects, which are created from references extracted from native parametric objects (in this case, the wall object of BIM CAD). Using native objects as a reference, rather than modify them directly, has the advantage of maintaining the speed and facility of handle provided by the simplified characteristics of them. Changes in objects of reference would spread these modifications to the others specialized objects automatically, such as examples of existing tools, like a Wall Framing Tool, which converts native objects of walls in wood frame components (Cadimage, 2008). Facilities and structures definition: from special interfaces, the user could launch information about complementary facilities and structures, as occurs in applications like Constructor (Vico Software, 2008). This information would result in auxiliary objects to represent the facilities. Selection of reference objects: the user would select the native parametric objects which would like to obtain detailed representations, leaving all other walls in charge of the standard representation of BIM CAD. Masonry characteristics selection: Among several options available, the user would choice the brick or block type, the bound rules for laying and the coating types on the walls. These options would be stored in relational data bases of the building model, which would be managed from specific interfaces. Keeping independent data base of the model would result in availability of the settings created for a specific design for all the others. Specialized parametric objects creation: for each native object selected would be made a sweeping, seeking the spatial-geometric characteristics of the wall and the interferences between it and the objects that represent the complementary facilities. For each issue found, the tool would select the suitable block (for example, a special block for electrical box if it meets an outlet point) and would record their characteristics and their position in a data matrix. A specialized parametric object copy is created, containing the data matrix and the set of behaviors necessary to generate the graphical representations. Creation of the specialized parametric objects representation: the processing in charge for the generation of graphical representation of specialized objects would be separated from the processing in charge for the object creation. It would occur because in a BIM CAD the different geometric representations are only objects instances and they are not new objects. For each new visualization required by the user (floor plans, sections, elevations and perspectives), the processing would be in charge to generate a new object view, composed of geometric elements which correspond to the new context. The geometric elements used (e.g. drawing of the block in section, indicative texts, textures) are stored in auxiliary data bases, allowing the automatic updates of the drawings.

Quantitatives take-off and schedules: from the same process of associate data bases, specific functions could generate notes of material list to be used in all derivative objects (obtained from the object data matrix reading). Besides, guidelines for construction carry out and instructions could also be generated automatically, based on the simple criterion association to descriptions inserted in the data bases. The processing tool model data flow can be seen in figure 01 and the graphical instances of specialized objects can be seen in figure 02:
SPECIALIZEDOBJECT CREATION GRAPHIC REPRESENTATION CREATION

BRICKS & BLOCKS

LINES & HATCHES

BONDS NATIVEOBJECT SPECIALIZED OBJECT

PATTERNS GRAPHICINSTANCES

FINISHINGS

DESCRIPTORS

Figure 01: Processing tool model data flow

A10 A10 A10 A10 A10 A10 A10 A10

Figure 02: Graphical instances of specialized objects

4. Conclusion
In previous work conducted by this research group and also in experiences reported by the literature of the area demonstrated that through the parametric modeling capacity, provided by architectural BIM CAD, the automatic extraction of much of design documentation is feasible to be done. The features in charge for this task are those that distinguish this new CAD generation from the previous one: the use of parametric objects, the semantic interpretation of objects relationships which constitute the building model and the storage of this model in a data base format, from which information can be extracted automatically. These experiments showed that is possible to automate the design documentation required to guide masonry construction, with high level of construction detail. A tool addressed to assist this task will demand several routines to analyze the context and to define the suitable behavior for the parametric objects, but much of the programming effort can be eliminated when basic features and interfaces available in BIM CADs are used. The proposed model aims to assist the source code generation necessary to develop such a tool, based on the assumptions which guide the BIM. The automation of design documentation provide great potential for improvements in the quality design, adding value to it, besides to improve the communications among stakeholders. All these aspects contribute for the better quality of final products.

5. REFERENCES Autodesk. Revit Architecture. Available at < www.autodesk.com> , acessado em 03.2008. Bentley Systems, INC. Bentley Architecture. Available at < www.bentley.com> , acessado em 03.2008. Cadimage. Wall Framing Tool. Available at < www.cadimagetools.com> , acessado em 03.2008. Caldas, C. H.; Soilbelman, L. Automating Hierarquical Document Classification for Construction Management Information Systems. Automation in Construction, v. 12, p. 395-406, 2003. Campbell, D. A. Building information modeling: the Web3D application for AEC. Proceedings of the twelfth international conference on 3D web technology, 2007, pp. 173-176. Cheng, R. Questioning the role of BIM in architectural education. AECBytes Viewpoint, No. 26, 2006. Disponvel em www.aecbytes.com, acessado em 03.2008. Ganah, a. a.; Bouchlaghem, n. b.; Anumba, c. j. Viscon: computer visualization support for constructability. Jornal of Information Technology in Construction (ITCON), v. 10, pag. 69-83, 2005. Available at < http://www.itcon.org/cgi-bin/works/Show?2005_7> Graphisoft. ArchiCAD. Disponvel em www.graphisoft.com, acessado em 03.2008. Ibrahim, M.; Krawczyk, R.; Schipporeit, G. Two Approaches to BIM: A Comparative Study. eCAADe Conference, 2004. Available at < http://www.iit.edu/~krawczyk/miecad04.pdf>

Kale, S.; Arditi, D. Diffusion of Computer Aided Design Technology in Architectural Design Process. Jornal of Construction Engineering and Management (ASCE), v. 131, p. 1135-1141, 2005. Lee, G.; Sacks, R.; Eastman, C. M. Specifying parametric building object behavior (BOB) for a building information modeling system. Automation in construction, v. 15, pg, 758-776, 2006. Mao, W.; Zhu, Y.; Ahmad, I. Applying metadata models to unstructured content of construction documents: A view-based approach. Automation in Construction. Vol. 16, No. 2, 2007, pp. 242252. Available at <http://linkinghub.elsevier.com/retrieve/pii/S0926580506000203>. Moum, A. A framework for exploring the ICT impact on the architectural design process. ITcon. Vol. 11, 2006, pp. 409-425. Disponvel em http://www.itcon.org/2006/30. Nemetschek. Allplan. Available at < www.allplan.com> , acessado em 03.2008. Pfeifer, G.; Ramcke, R.; Achtziger, J.; Zilch, K. Masonry Construction Manual. 2001: Birkhauser / Detail. Square One. Ecotect. Available at < www.squ1.com> , acessado em 03.2008. Tekla Corporation. Tekla Structures. Available at < www.tekla.com> , acessado em 03.2008. Tse, T. K.; Wong, K. A.; Wong, K. F. The utilisation of building information models in nDmodelling: A study of data interfacing and adoption barriers. Jornal of Information Technology in Construction (ITCON). Vol. 10, 2005, pp. 85110. Available at <http://itcon.org/cgibin/papers/Show?2005_8>. Vico Software. Constructor. Available at <www.vicosoftware.com> , acessado em 03.2008.

UtilizaodoCADBIMparaprojetodealvenariade blocosdeconcreto
TheuseofCADBIMformasonrydesignofconcreteblocks

CervantesAYRESFilho
ArquitetoeUrbanista,MestrandoemConstruoCivilpelaUniversidadeFederaldoParanUFPRcorreio eletrnico:cervantes.ayres@gmail.com

FabolaAZUMA
EngenheiraCivil,MestreemConstruoCivilpelaUniversidadeFederaldoParanUFPRcorreioeletrnico: fabiolaazuma@yahoo.com.br

SrgioSCHEER
EngenheiroCivil,ProfessorAssociadodaUniversidadeFederaldoParanUFPRcorreioeletrnico:scheer@ufpr.br

RESUMO
Proposta: Apresentar um experimento de especializao de objetos paramtricos nativos. Discutir os requisitos necessrios para uma ferramenta CADBIM direcionada para automatizao da gerao da documentao projetual de alvenaria de blocos de concreto. Abordar forma de implementao de sistemasCADBIMparaestecontextoeapresentarummodelodeprocessamentodedados.Mtodode pesquisa/Abordagens:Baseadoemumapesquisadaliteraturaetesteemprico.Resultados:explorare disseminar no meio acadmico a capacidade da tecnologia CADBIM para automatizao da documentao projetual de alvenaria de blocos de concreto. Contribuies/Originalidade: Apresentaodosresultadosdotesteempricodeobjetosparamtricosespecializados,deumalistade requisitosnecessriosimplementaodeumCADBIMparaalvenariadeblocosdeconcretoedeum modelodeprocessamentodedados. Palavraschave:sistemasCADBIM,Alvenaria,Blocosdeconcreto.

ABSTRACT
Proposal: To present an experiment about parametric native objects specialization. To discuss the requirementsforaCADBIMtooltargetedtoautomatethemasonrydesigndocumentationofconcrete blocks. To show how implement a CADBIM system for this context and present a processing data model.Methods:Basedonliteratureresearchandempiricaltesting.Findings:exploreandspreadin theacademicfieldthepotentialofCADBIMtechnologyfordocumentdesignautomationofmasonryof concreteblocks.Originality/value:Theresultsofanempiricaltestingofspecializedparametricobjects, thepresentationofarequirementlistforCADBIMimplementationfocusonmasonryofconcreteblocks andasuggestionofaprocessingdatamodel. Keywords:CADBIMsystems,Masonry,ConcreteBlocks.

VIIIWorkshopBrasileiro GestodoProcessodeProjetosnaConstruodeEdifcios SoPaulo,3e4denovembro2008

BIM,CADeaModelagemParamtrica

VriosautoresdefinemBIMcomooprocessodegestodainformaoenvolvidaemtodoo ciclo de vida de um edifcio (TSE et al., 2005; CAMPBELL, 2007) Dentre os diversos sistemas computacionais que do suporte BIM, LEE et al., 2006 ressaltam o papel fundamental da nova gerao de CADs (Computer Aided Design), uma vez que a produo de informaes grficasprecisaseconfiveisessencialparaaindstriadaAEC. UmdosprincpiosdosBIMCADs,independentedofabricante,aextraoautomatizadade informaes, a partir de um modelo composto por objetos que representam os elementos construtivosdoedifcioprojetado.Porisso,dentreassuasfunes,estoincludasrotinasque seencarregamdeautomatizarboapartedadocumentaoprojetualcomocortes,elevaes, perspectivas,layouts,almderelatriosdequantificaodemateriais(IBRAHIMetal.,2004; TSE et al., 2005; MOUM, 2006; MAO et al., 2007; CAMPBELL, 2007). Essas rotinas so importantes agentes na melhoria do processo de projeto, porm geralmente respondem apenas s situaes mais genricas, de maior abrangncia na construo, ficando as especificidades(decorrentesdecaractersticasregionaisoudosistemaconstrutivo)acargodo usurio.PartedissodecorredaestratgiacomercialadotadapelosfabricantesdosBIMCADs, queinvestemprioritariamentenamelhoriadasinterfacesbsicasenasfuncionalidadesmais genricasdemodoatornaroprodutoadaptvelaomaiornmeropossveldeconsumidores, emnvelmundial.Paracompensaressacarnciadedetalhamentodesistemasconstrutivosou regiesespecficas,asprpriasfabricantesanunciamapossibilidadedeaprimorarasfunes bsicasdosseusaplicativos.

ObjetivoeMtododePesquisa

Diantedessecontextoapresentado,oobjetivodesseartigoapresentarosresultadosdeum experimento no qual foi customizada uma ferramenta CADBIM de maneira a se adaptar s peculiaridadesdoprocessodeprojetodealvenariadeblocosdeconcreto.Esseexperimento foi realizado baseado no software ArchiCAD. A partir dessa ferramenta customizada, a extrao automtica da documentao projetual foi permitida, aumentando a eficincia do projetista com grande nvel de detalhamento executivo. Essa experincia abordou apenas a especializao do objeto paramtrico para o bloco de concreto, porm permitiu grandes reflexes. Com base nessa experincia adquirida, uma nova lista de funcionalidades para sistemaCADBIMdirecionadaparaprocessodeprojetodealvenariadeblocosdeconcretofoi desenvolvida,eassim,elaboradoummodelodeprocessamentodedadosnessascondies.O trabalhofoiprincipalmentebaseadonapesquisadaliteraturaarespeitodasparticularidades do projeto executivo de alvenaria de blocos de concreto e das formas de aprimorar as funcionalidadesgenricasdaferramentaCADBIM.

ResultadodoexperimentoDesenvolvimentodeobjetosparamtricos

O objeto paramtrico para representar os blocos de concreto foi desenvolvido atravs da programao GDL no prprio software ArchiCAD. Uma vez definido o novo objeto paramtrico, a sua utilizao consistia em duas etapas: primeiro a insero e a definio da posioedocomprimentodoobjetoquerepresentaraparededeblocosocorrenajanelade ediodoArchiCADemgeralaplanta(fig.1).Segundo,osparmetroscomplementaresso
VIIIWorkshopBrasileiro GestodoProcessodeProjetosnaConstruodeEdifcios SoPaulo,3e4denovembro2008

definidos posteriormente, em um painel de opes (fig. 2). Atravs desse painel possvel visualizaroresultadodacombinaodosdiferentesparmetrosescolhidos,antesderetornar janeladeediodoprojeto.

Fig.01:Inserodoobjetoparamtricoemplanta eediodoseucomprimentolimitadopelomdulobsico.

Fig.02:Paineldeconfiguraesdo objetoparede.

SeguindoopadrodosCADsBIM,hparmetrosparacontrolararepresentaodoobjeto paramtrico nos quatro tipos de visualizao: planta, corte, elevao e perspectiva. Isso garante que o objeto desempenhe o comportamento adequado para cada situao. Por exemplo,asparedesinterceptadaspeloplanodecortedavistasohachuradas,enquanto as demais no. Quando visualizados em elevao, os objetos representam automaticamentetodososblocosdaparede.Todasasvistas,incluindoaperspectivaso geradasautomaticamente. Onveldeinformaoaserexibido(i.e.detalhamento)controladoporparmetrosque interpretam as configuraes globais da janela de edio do ArchiCAD. Desse modo, selecionar uma escala de representao para a vista selecionada provoca a atualizao automticadetodososobjetosvizualizados(fig.3).Outrafuncionalidadequeseutilizou dasconfiguraesglobaisfoiaautomatizaodageraodeplantasdasdiferentesfiadas deblocosdeconcreto.Atravsdamodificaodaalturadoplanodecortedaplanta,os objetossoatualizadosautomaticamente,mostrandoaconfiguraodosblocosdafiada cortadapelanovaaltura(fig.4).Essafuncionalidadefoiessencialparaagilizarageraoda documentao(plantasdefiadas)necessriaparaaconstruo,ereduziudrasticamente, quandonoeliminouporcompleta,etapasposterioresdedetalhamento.

1:25

1:100

Fig.04:Representaoautomticadosblocosdefiada.

Fig.03:Representaesautomticasdomesmoobjeto paramtricoconformeescala.

VIIIWorkshopBrasileiro GestodoProcessodeProjetosnaConstruodeEdifcios SoPaulo,3e4denovembro2008

Cdigos adicionais permitiram que o objeto paramtrico assumisse funes alm das paredes simples. Eles tambm podiam ser configurados para representarem elementos construtivoscomplementares:peitoris,arquitraves,pingadeiras,elementosvazados.

4 Funcionalidades para implementar um CADBIM direcionado para alvenariadeblocosdeconcreto


Esse experimento baseado na especializao de objetos nativos do CADBIM permitiu a extrao de documentao detalhada de projeto de alvenaria diretamente do modelo de dados.Apartirdessaexperimentaofoipossvelrefletireexploraropotencialdatecnologia BIM para projeto de alvenaria, considerando suas peculiaridades executivas. Portanto, essa seoapresentaasprincipaisfuncionalidadesparaautomatizarageraodadocumentaode projeto de alvenaria com CADBIM atravs do aprimoramento da inteligncia contextual dos objetos paramtricos especializados. Essas principais caractersticas foram relacionadas em tpicosedescritasaseguir: Topdownmodeling:duranteasfasesiniciaisdodesenvolvimentodoprojetodeedificao,h um grande nmero de indeterminaes com relao aos espaos, sistemas construtivos e materiaisdoedifcio.Nessasfases,osobjetosparamtricosdevemsecomportardemaneira abstrata e genrica, permitindo um manuseio gil e sucessivas modificaes. Conforme prossegue o desenvolvimento, os objetos paramtricos devem ser capazes de armazenar informaesmaisdetalhadas,esecomportardemodomaisespecfico(LEEetal.,2006).Uma desvantagem da utilizao de objetos paramtricos complexos e excessivamente determinantesnosestgiosiniciaisdamodelagemdoedifciosobrecarregaroprojetistacom informaes que sero determinadas apenas em etapas posteriores. CHENG (2006) tambm alertaparaofatodequemodelagens quesebaseiamemsistemasmuitocomplexospodem prejudicaroprocessodeexperimentaoqueinerenteconcepoarquitetnica. Comportamento dos objetos: os objetos paramtricos so as peas fundamentais dos BIM CADs.Elesassociamadescriodoselementosconstrutivosacomportamentosquedefinem, dentreoutraspossibilidades,omodocomooobjetodeveserrepresentadograficamenteem cada forma de visualizao do projeto (planta, elevao, corte, perspectiva). A ferramenta deve,portanto,gerarcomportamentosparaosobjetosparamtricosdemodoaautomatizara representao das paredes de alvenaria em quaisquer vistas selecionadas pelo usurio. Essa capacidade tornaria possvel a extrao automtica de plantas de fiadas, cortes e elevaes dasparedesincluindoaindicaodosblocos,eperspectivasqueauxiliemnacompreensoda montagemdoselementos. BlocoseTijolos:soasunidadesbsicasdaalvenariaevariamconsideravelmentedeacordo comaregiogeogrfica.Porisso,devehaversuporteparavriostiposdeunidades,etambm deve ser possvel a criao de novas, a partir das descries fornecidas pelo operador. Diferentes tipos de blocos ou tijolos podem ser utilizados em uma mesma construo (e. g. paredes externas e internas), de onde se conclui que essa caracterstica deve ser um parmetrodoobjetoquerepresentaraparede. Fiadas:soasregrasdeassentamentodasunidadesbsicas.Podemvariarconsideravelmente de regio para regio (assim como os blocos e tijolos) e tambm de acordo com a unidade bsica selecionada. Por isso, tambm deve ser possvel a criao de novos tipos de fiadas, atravsdadescriodesuasregrasbsicas.Outroaspectocrticoacorretainterpretaoda unidadebsica,independentedaposiodeassentamento(e.g.tijolodeitadoetijoloem p).
VIIIWorkshopBrasileiro GestodoProcessodeProjetosnaConstruodeEdifcios SoPaulo,3e4denovembro2008

Suportecoordenaomodularezonasneutras:combasenoblocoenafiadaselecionados, a modificao das dimenses de um determinado objeto seria limitada por mltiplos do mdulo da unidade bsica. Dimenses que no se encaixassem na modulao seriam demonstradasclaramenteaoprojetista(e.g.atravsdehachuras).Nestescasos,deveriahaver no mnimo duas possibilidades: inserir automaticamente unidades ou materiais para fazer o ajuste,conformeregrasqueafiadadeterminasse; ouinformarousurio,quepoderiaento decidirserealizaoajustemodularouredimensionaosobjetosenvolvidos. Aberturasnasparedes:aferramentadeveefetuarodeslocamentoautomtico(ounomnimo sugerilo)dasaberturasdaparedequenoseenquadraremnamodulaodaunidadebsica. Adicionalmente, com base em definies do usurio, poderiam ser includas de forma automticavergas,contravergas,caixilhosprmoldados,elementosdeparapeitoelintel,etc. Interfaces entre paredes: a amarrao das juntas entre duas paredes requer elementos que extrapolamoslimitesgeomtricosdosobjetosgeomtricos.Exemplosdissosoajuntacom fiadas intercaladas (na qual os blocos das fiadas impares e pares das duas paredes se interpem,demodoatransferirosesforosentreosdiferentesplanos);telasearmadurasde amarrao (PFEIFER et al., 2001). A resoluo dessa situao depende de uma refinada capacidadedoobjetodereconhecercorretamenteocontextoondeestinserido,adaptando se. Interfacescomdemaiselementosconstrutivos:aferramentadeveajustarautomaticamenteo objeto paramtrico em situaes de encontro com lajes, pilares, vigas, baldrames, etc., inserindooselementosnecessrios.Umexemplotpicoseriaainseroautomticadeblocos J (ou canaletas) na ltima fiada das paredes, quando houvesse acima delas um objeto paramtricorepresentandoumalaje. Empenas: planos de parede cortados diagonalmente apresentam um desafio especial. A sua representao grfica deve considerar a parede como um polgono irregular (no mnimo um trapzio),epodehavervriosngulosdecorrentesdevriasoperaesdecorterealizadasno objeto. Uma funo bastante til seria sugerir para o usurio ngulos de corte que permitissemreduziraperdadeblocos,considerandoasconfiguraesdefiadaselecionadas. Instalaes:umafunoessencialparaaferramentaaindicaodaposiodasinstalaes (eltrica, hidrulica, lgica, etc.), de modo a permitir, a partir de regras que podem ser definidas pelo usurio, a identificao automtica de blocos prprios para a passagem dos condutores. Funo estrutural: definir uma parede como portante abre um novo leque de situaes a serem atendidas pela ferramenta. Devese, por exemplo, representar cintas de amarrao e pilaresconformadospelosocosdosblocosdaalvenaria,almdasarmadurasdesteselementos estruturais. Essa situao poderia ser atendida com uma abordagem semelhante ao item instalaes: a identificao da posio dos elementos pelo usurio. Uma verso mais sofisticadadaferramentapoderiainclusiveinseriroselementosestruturaisautomaticamente, combasenosvosecargasdefinidospelousurio. Revestimentos: alm de representar as unidades bsicas que constituem a alvenaria, a ferramenta deve ser capaz de associar mltiplas camadas de revestimento, assim como quantificaroscomponentesutilizadosnessascamadas.Aferramentatambmdevesercapaz de interpretar o contexto projetual (a fase do projeto, a escala, a vista) para decidir se representa ou no o revestimento. No projeto arquitetnico, por exemplo, visualizar as unidadesdaalvenariadesfavorvelcorretainterpretaodainformao(amenosquese
VIIIWorkshopBrasileiro GestodoProcessodeProjetosnaConstruodeEdifcios SoPaulo,3e4denovembro2008

trate de alvenaria aparente). No projeto para execuo da alvenaria, a visualizao do revestimentoquesetornadesfavorvelcompreensodainformao. Quantitativos: os objetos criados pela ferramenta devem incluir informaes a respeito do consumodoscomponentesutilizados,parapermitiraquantificaoautomticadosmateriais com base na sua extenso ou volume. A ferramenta deve fornecer funes para emisso de relatrios automticos, valendose de caractersticas j presentes nos principais BIM CADs disponveis. Uma verso mais sofisticada dessa funo poderia inclusive considerar a diviso do modelo por setores (e. g. por andares) e incluir no quantitativo o local de entrega dos pacotesdemateriaisnecessriosparaaexecuodaalvenaria. Padres e Normas: alm de automatizar a representao grfica dos elementos que constituemasalvenarias,podeseautomatizartambmadescrioderequisitosexigidospara a construo. A partir da insero dessas informaes em bases de dados auxiliares, o CAD BIMpodeassociarautomaticamentedescritoreseindicadoresnosdesenhosouemmemoriais parte, sempre que determinado objeto se enquadrar em critrios previamente estabelecidos. Por exemplo, inserir uma etiqueta com o texto Seguir NBR 8798:1985 em todos os desenhos que contiverem paredes definidas como alvenaria estrutural de blocos vazados. ApartirdaabordagemdoaplicativoassociadoaumCADBIMedasfuncionalidadesaserem oferecidas,foidesenvolvidaumasugestoparaomodelodeprocessamentoadotadoporuma ferramenta que automatize a gerao da documentao projetual para obras de alvenaria. Resumidamente,oprocessamentoexecutadopelaferramentaseutilizariadeumconjuntode objetos bsicos para gerar objetos mais elaborados, que conteriam as representaes necessriasparaautomatizaradocumentaoprojetual. Umapossvelsoluoparaarepresentaodosdetalhesconstrutivosdasparedesdealvenaria seriaarepresentaotridimensionaldecadaumdosblocosqueasconstituem.Pormaisque se possa automatizar esse processo, experincias anteriores deste grupo de pesquisa demonstraram que essa alternativa demanda grande capacidade de processamento, e gera arquivos da ordem de dezenas de megabytes, mesmo para construes simples de pequeno porte.Criarobjetostridimensionaispararepresentartijolosaparentespodeparecerumaboa opo, mas em muitos casos (talvez a maioria deles), a alvenaria ser revestida, e a visualizao da posio de cada bloco se presta apenas fase de documentao executiva. Como alternativa, a sugesto apresentada se valeria de uma ferramenta que criasse representaes bidimensionais temporrias, de processamento mais rpido, que se adequassemaotipodevisualizaosolicitadopelousurio.
OBJETONATIVO CRIODOOBJETO ESPECIALIZADO OBJETO ESPECIALIZADO CRIAODA REPRESENTAO GRFICA REPRESENTAES (INSTNCIAS)

BLOCOS E TIJOLOS

LINHASEHACHURAS

FIADAS

PADRES

ACABAMENTOS

DESCRITORES

Fig.05:Modelodeprocessamentodedados

VIIIWorkshopBrasileiro GestodoProcessodeProjetosnaConstruodeEdifcios SoPaulo,3e4denovembro2008

CONCLUSES

Oexperimentodesenvolvidoporestegrupodepesquisaetambmasexperinciasrelatadas naliteratura dareademonstramqueascapacidadesda modelagem paramtrica,oferecida pelosCADsBIMarquitetnicos,podemtornarvivelageraoautomatizadadeboaparteda documentaoprojetual.Ascaractersticasresponsveisporessapossibilidadesojustamente as que distinguem essa gerao de CADs da anterior: o uso de objetos paramtricos, a interpretaosemnticadasrelaesentreosobjetosqueconstituemomodelodoedifcio,e oarmazenamentodestemodelonaformadeumabasededados,daqualpodemserextradas informaes de modo automtico. Essas experimentaes apontam para a viabilidade da automatizao completa da documentao projetual necessria para orientar obras de alvenaria,comgrandenveldedetalhamentoexecutivo.Umaferramentaqueseproponhaa estatarefanecessitardediversasrotinasparaanalisarocontextoedefinircomportamentos adequados para os objetos paramtricos, porm grande parte do esforo de programao podesereliminadoaoseutilizarasfunesbsicaseinterfacesjdisponveisnosCADsBIM.O modelopropostotemporfunoorientaraproduodoscdigosfontenecessriosparacriar tal ferramenta, partindo dos pressupostos que orientam a BIM. A automatizao da gerao da documentao oferece um grande potencial para a melhoria da qualidade do projeto, agregandolhevaloremelhorandoacomunicaoentreosagentesenvolvidosnaconstruo, nabuscacontnuadamelhoriadaqualidadedosprodutosfinais.

6REFERNCIAS
CAMPBELL,D.A.Buildinginformationmodeling:theWeb3DapplicationforAEC,Proceedings ofthetwelfthinternationalconferenceon3Dwebtechnology,2007,pp.173176.Disponvel em:http://portal.acm.org/ft_gateway.cfm?id=1229422&type=pdf&coll=GUIDE&dl= GUIDE&CFID=23642874&CFTOKEN=31571100>. CHENG,R.QuestioningtheroleofBIMinarchitecturaleducation.AECBytesViewpoint,No. 26,2006.Disponvelemwww.aecbytes.com,acessadoem03.2008. IBRAHIM,M.;KRAWCZYK,R.;SCHIPPOREIT,G.TwoApproachestoBIM:AComparativeStudy. eCAADeConference,2004.Disponvelemhttp://www.iit.edu/~krawczyk/miecad04.pdf. LEE,G.;SACKS,R.;EASTMAN,C.M.Specifyingparametricbuildingobjectbehavior(BOB)fora buildinginformationmodelingsystem,AutomationinConstruction,Vol.15,No.6,2006,pp. 758776.Disponvelem:<http://www.sciencedirect.com/science/journal/09265805>. MAO,W.;ZHU,Y.;AHMAD,I.Applyingmetadatamodelstounstructuredcontentof constructiondocuments:Aviewbasedapproach.AutomationinConstruction.Vol.16,No.2, 2007,pp.242252.Disponvelem: <http://linkinghub.elsevier.com/retrieve/pii/S0926580506000203>. MOUM,A.AframeworkforexploringtheICTimpactonthearchitecturaldesignprocess. ITcon.Vol.11,2006,pp.409425.Disponvelem:<http://www.itcon.org/2006/30>. PFEIFER,G.,RAMCKE,R.,ACHTZIGER,J.,andZILCH,K.,MasonryConstructionManual.2001: Birkhauser/Detail. TSE, T. K.; WONG, K. A.; WONG, K. F. The utilization of building information models in nD modelling: A study of data interfacing and adoption barriers, ITcon. Vol. 10, 2005, pp. 85 110.Disponveem<http://www.itcon.org/data/works/att/2005_8.content.05676.pdf>.
VIIIWorkshopBrasileiro GestodoProcessodeProjetosnaConstruodeEdifcios SoPaulo,3e4denovembro2008

ApndiceB
Scriptsdoobjetoparamtricoquerepresenta paredesdeblocosdeconcreto
MasterScript dimtipo[] dimposx[] dimposy[] dimposz[] dimangz[] dimjuntad[] dimjuntae[] dimjuntaf[] dimjuntap[] dimjuntai[] dimjuntas[] vsimples=0 dimvsposx[] dimvsposy[] dimvsposz[] dimvsdimx[] dimvsdimy[] dimvsdimz[] blocos=0 !! !!segmentodeparede !! iftipocoelemento="Parede20"ortipocoelemento="Parede10"then !! !!determinaodosblocosparede !! fiadas=int(zzyzx/.2) ifa>.2then blocosx=int(a/.4) iftipocoelemento="Parede20"then tip="BL39x19x19" tipfaixa="BL09x19x19" else tip="BL39x09x19" tipfaixa="BL09x09x19" endif else blocosx=1 iftipocoelemento="Parede20"then tip="BL19x19x19" tipfaixa="BL09x19x19" else tip="BL09x19x19" tipfaixa="BL09x09x19" endif endif z=.01 !! !!fiadasabaixodafaixa !! forzz=1tofaixa1 x=0 forxx=1toblocosx blocos=blocos+1 tipo[blocos]=tip posx[blocos]=x posy[blocos]=0 posz[blocos]=z iftip="BL09x19x19"then angz[blocos]=90 juntae[blocos]="Recuada" juntad[blocos]="Recuada" juntas[blocos]=0 juntai[blocos]=1 juntaf[blocos]="Topo" juntap[blocos]="Saliente" ifxx=1thenjuntaf[blocos]=junta_e ifxx=blocosxthenjuntap[blocos]=junta_d else

angz[blocos]=0 juntaf[blocos]="Recuada" juntap[blocos]="Recuada" juntas[blocos]=0 juntai[blocos]=1 juntae[blocos]="Topo" juntad[blocos]="Saliente" ifxx=1thenjuntae[blocos]=junta_e ifxx=blocosxthenjuntad[blocos]=junta_d endif x=x+.4 nextxx z=z+.2 nextzz !! !!fiadadafaixasegmentodeparede !! iffaixa<>0then blocosfaixa=int(a/.1) x=0 forxx=1toblocosfaixa cond1=(xx=1andjunta_e="Recuada") cond2=(xx=blocosfaixaandjunta_d="Recuada") ifnot(cond1)andnot(cond2)then !! !!blocosdomeiodafaixa !! blocos=blocos+1 tipo[blocos]=tipfaixa posx[blocos]=x posy[blocos]=0 posz[blocos]=z angz[blocos]=0 juntaf[blocos]="Recuada" juntap[blocos]="Recuada" juntas[blocos]=0 juntai[blocos]=1 juntae[blocos]="Topo" juntad[blocos]="Saliente" ifxx=1thenjuntae[blocos]=junta_e ifxx=blocosfaixathenjuntad[blocos]=junta_d else ifcond1then !! !!blocosdaextremidadeesquerdadafaixa !! blocos=blocos+1 tipo[blocos]="BL09x09x19" posx[blocos]=x posy[blocos]=0 posz[blocos]=z angz[blocos]=0 juntaf[blocos]="Recuada" iftipocoelemento="Parede20"thenjuntap[blocos]="Saliente"elsejuntap[blocos] ="Recuada" juntas[blocos]=0 juntai[blocos]=1 juntae[blocos]="Recuada" juntad[blocos]="Saliente" iftipocoelemento="Parede20"then blocos=blocos+1 tipo[blocos]="BL09x09x19" posx[blocos]=x posy[blocos]=.1 posz[blocos]=z angz[blocos]=0 juntaf[blocos]="Topo" juntap[blocos]="Recuada" juntas[blocos]=0 juntai[blocos]=1 juntae[blocos]="Recuada" juntad[blocos]="Saliente" endif else !! !!blocosdaextremidadedireitadafaixa !! blocos=blocos+1 tipo[blocos]="BL09x09x19" posx[blocos]=x posy[blocos]=0 posz[blocos]=z angz[blocos]=0 juntaf[blocos]="Recuada" iftipocoelemento="Parede20"thenjuntap[blocos]="Saliente"elsejuntap[blocos] ="Recuada"

juntas[blocos]=0 juntai[blocos]=1 juntae[blocos]="Topo" juntad[blocos]="Recuada" iftipocoelemento="Parede20"then blocos=blocos+1 tipo[blocos]="BL09x09x19" posx[blocos]=x posy[blocos]=.1 posz[blocos]=z angz[blocos]=0 juntaf[blocos]="Topo" juntap[blocos]="Recuada" juntas[blocos]=0 juntai[blocos]=1 juntae[blocos]="Topo" juntad[blocos]="Recuada" endif endif endif x=x+.1 nextxx z=z+.2 endif !! !!fiadasacimadafaixasegmentodeparede !! forzz=faixa+1tofiadas x=0 forxx=1toblocosx blocos=blocos+1 tipo[blocos]=tip posx[blocos]=x posy[blocos]=0 posz[blocos]=z iftip="BL09x19x19"thenangz[blocos]=90elseangz[blocos]=0 iftip="BL09x19x19"then angz[blocos]=90 juntae[blocos]="Recuada" juntad[blocos]="Recuada" juntas[blocos]=0 juntai[blocos]=1 juntaf[blocos]="Topo" juntap[blocos]="Saliente" ifxx=1thenjuntaf[blocos]=junta_e ifxx=blocosxthenjuntap[blocos]=junta_d else angz[blocos]=0 juntaf[blocos]="Recuada" juntap[blocos]="Recuada" juntas[blocos]=0 juntai[blocos]=1 juntae[blocos]="Topo" juntad[blocos]="Saliente" ifxx=1thenjuntae[blocos]=junta_e ifxx=blocosxthenjuntad[blocos]=junta_d endif x=x+.4 nextxx z=z+.2 nextzz !! !!volumessimplificadossegmentodeparede !! ifjunta_e="Saliente"thenxe=0.01elsexe=0 ifjunta_d="Saliente"thenxd=aelsexd=a.01 vsimples=1 vsposx[1]=xe vsposy[1]=0 vsposz[1]=0 vsdimx[1]=xdxe iftipocoelemento="Parede20"thenvsdimy[1]=.19elsevsdimy[1]=.09 vsdimz[1]=zzyzx b=.2 endif !! !!listelo !! iftipocoelemento="Listelo20"ortipocoelemento="Listelo10"then !!

!!determinaodosblocoslistelo !! ifa>.2then blocosx=int(a/.4) blocosp=int(a/.2) iftipocoelemento="Listelo20"thentip="BL39x19x19"elsetip="BL39x09x19" else blocosx=1 blocosp=1 iftipocoelemento="Listelo20"thentip="BL19x19x19"elsetip="BL19x09x19" endif !! !!fiadasdeblocoslistelo !! x=0 forxx=1toblocosx blocos=blocos+1 tipo[blocos]=tip posx[blocos]=x posy[blocos]=0 posz[blocos]=.06 angz[blocos]=0 juntaf[blocos]="Recuada" juntap[blocos]="Recuada" juntas[blocos]=0 juntai[blocos]=1 ifxx=1thenjuntae[blocos]=junta_eelsejuntae[blocos]="Topo" ifxx=blocosxthenjuntad[blocos]=junta_delsejuntad[blocos]="Saliente" x=x+.4 nextxx !! !!fiadadepastilhaslistelo !! x=0 forxx=1toblocosp blocos=blocos+1 iftipocoelemento="Listelo20"thentipo[blocos]="PA19x19x04"elsetipo[blocos]="PA19x09x04" posx[blocos]=x posy[blocos]=0 posz[blocos]=.01 angz[blocos]=0 juntaf[blocos]="Recuada" juntap[blocos]="Recuada" juntas[blocos]=0 juntai[blocos]=1 ifxx=1thenjuntae[blocos]=junta_eelsejuntae[blocos]="Topo" ifxx=blocospthenjuntad[blocos]=junta_delsejuntad[blocos]="Saliente" x=x+.2 nextxx !! !!volumessimplificadoslistelo !! ifjunta_e="Saliente"thenxe=0.01elsexe=0 ifjunta_d="Saliente"thenxd=aelsexd=a.01 vsimples=1 vsposx[1]=xe vsposy[1]=0 vsposz[1]=0 vsdimx[1]=xdxe iftipocoelemento="Listelo20"thenvsdimy[1]=.19elsevsdimy[1]=.09 vsdimz[1]=zzyzx endif !! !!peitorilemnicho !! iftipocoelemento="Peitorilemnicho"then !! !!determinaodosblocospeitorilemnicho !! fiadas=int((zzyzx.05)/.2)1 z=.01 !! !!fiadasabaixodafaixapeitorilemnicho !! forzz=1tofaixa1 x=0 forxx=1to3 blocos=blocos+1 tipo[blocos]="BL39x19x19" posx[blocos]=x

posy[blocos]=0 posz[blocos]=z angz[blocos]=0 juntaf[blocos]="Recuada" juntap[blocos]="Recuada" juntas[blocos]=0 juntai[blocos]=1 juntae[blocos]="Topo" juntad[blocos]="Saliente" ifxx=1thenjuntae[blocos]=junta_e ifxx=3thenjuntad[blocos]=junta_d x=x+.4 nextxx z=z+.2 nextzz !! !!fiadadafaixapeitorilemnicho !! iffaixa<>0then x=0 forxx=1to12 !! !!blocosdafaixapeitorilemnicho !! blocos=blocos+1 tipo[blocos]="BL09x19x19" posx[blocos]=x posy[blocos]=0 posz[blocos]=z angz[blocos]=0 juntaf[blocos]="Recuada" juntap[blocos]="Recuada" iffaixa<>fiadasthenjuntas[blocos]=0elsejuntas[blocos]=1 juntai[blocos]=1 juntae[blocos]="Topo" juntad[blocos]="Saliente" ifxx=1thenjuntae[blocos]=junta_e ifxx=12thenjuntad[blocos]=junta_d x=x+.1 nextxx z=z+.2 endif !! !!fiadasacimadafaixapeitorilemnicho !! forzz=faixa+1tofiadas x=0 forxx=1to3 blocos=blocos+1 tipo[blocos]="BL39x19x19" posx[blocos]=x posy[blocos]=0 posz[blocos]=z angz[blocos]=0 juntaf[blocos]="Recuada" juntap[blocos]="Recuada" ifzz<fiadasthen juntas[blocos]=0 else juntas[blocos]=1 endif juntai[blocos]=1 juntae[blocos]="Topo" juntad[blocos]="Saliente" ifxx=1thenjuntae[blocos]=junta_e ifxx=3thenjuntad[blocos]=junta_d x=x+.4 nextxx z=z+.2 nextzz !! !!fiadadeblocosdopeitoril !! x=0 forxx=1to12 blocos=blocos+1 tipo[blocos]="BL29x09x19" posx[blocos]=x posy[blocos]=.1 posz[blocos]=z angz[blocos]=90 juntae[blocos]="Recuada"

juntad[blocos]="Recuada" juntas[blocos]=1 juntai[blocos]=0 juntaf[blocos]="Saliente" juntap[blocos]="Topo" ifxx=1thenjuntap[blocos]=junta_e ifxx=12thenjuntaf[blocos]=junta_d x=x+.1 nextxx z=z+.2 blocos=blocos+1 tipo[blocos]="PE119x39x04" posx[blocos]=0 posy[blocos]=.15 posz[blocos]=z angz[blocos]=0 juntaf[blocos]="Recuada" juntap[blocos]="Recuada" juntas[blocos]=0 juntai[blocos]=0 juntae[blocos]=junta_e juntad[blocos]=junta_d !! !!volumessimplificadospeitorilemnicho !! ifjunta_e="Saliente"thenxe=0.01elsexe=0 ifjunta_d="Saliente"thenxd=aelsexd=a.01 vsimples=3 vsposx[1]=xe vsposy[1]=0 vsposz[1]=0 vsdimx[1]=xdxe vsdimy[1]=.19 vsdimz[1]=zzyzx.25 vsposx[2]=xe vsposy[2]=.1 vsposz[2]=zzyzx.25 vsdimx[2]=xdxe vsdimy[2]=.29 vsdimz[2]=.2 vsposx[3]=xe vsposy[3]=.15 vsposz[3]=zzyzx.05 vsdimx[3]=xdxe vsdimy[3]=.39 vsdimz[3]=.05 endif !! !!cornijaclassicaoufaixaoutriglifo !! iftipocoelemento="CornijaClassica"ortipocoelemento="CornijaFaixa"ortipocoelemento="CornijaTriglifo"then !! !!determinaodosblocoscornijaclassicaoufaixa !! iftipocoelemento="CornijaClassica"thenfiadas=int((zzyzx.25)/.2) iftipocoelemento="CornijaFaixa"thenfiadas=int((zzyzx.05)/.2) iftipocoelemento="CornijaTriglifo"thenfiadas=int(zzyzx/.2)1 ifa>.2then blocosx=int(a/.4) blocosf=blocosx*4 blocosp=blocosx*2 tip="BL39x19x19" else blocosx=1 blocosf=2 blocosp=1 tip="BL19x19x19" endif iftipocoelemento="CornijaFaixa"thenblocosf=0 iftipocoelemento="CornijaTriglifo"thenblocosp=0 z=.01 !! !!fiadasabaixodacornijaclassicaoufaixa !! forzz=1tofiadas x=0 forxx=1toblocosx blocos=blocos+1 tipo[blocos]=tip posx[blocos]=x

posy[blocos]=0 posz[blocos]=z angz[blocos]=0 juntaf[blocos]="Recuada" juntap[blocos]="Recuada" ifzz=fiadasthenjuntas[blocos]=1elsejuntas[blocos]=0 juntai[blocos]=1 juntae[blocos]="Topo" juntad[blocos]="Saliente" ifxx=1thenjuntae[blocos]=junta_e ifxx=blocosxthenjuntad[blocos]=junta_d x=x+.4 nextxx z=z+.2 nextzz x=0 !! !!pastilhasdaextremidadeesquerdadacornijaclassicaoufaixa !! ifjunta_e="Recuada"andtipocoelemento<>"CornijaTriglifo"then !! !!terminaoesquerda !! blocos=blocos+1 tipo[blocos]="PA19x19x04" posx[blocos]=.05 posy[blocos]=.05 posz[blocos]=z angz[blocos]=0 juntaf[blocos]="Topo" juntap[blocos]="Saliente" iftipocoelemento="CornijaClassica"thenjuntas[blocos]=1elsejuntas[blocos]=0 juntai[blocos]=0 juntae[blocos]="Topo" juntad[blocos]="Saliente" blocos=blocos+1 tipo[blocos]="PA04x19x04" posx[blocos]=.15 posy[blocos]=.05 posz[blocos]=z angz[blocos]=0 juntaf[blocos]="Topo" juntap[blocos]="Saliente" iftipocoelemento="CornijaClassica"thenjuntas[blocos]=1elsejuntas[blocos]=0 juntai[blocos]=0 juntae[blocos]="Topo" juntad[blocos]="Saliente" blocos=blocos+1 tipo[blocos]="PA04x19x04" posx[blocos]=.05 posy[blocos]=.15 posz[blocos]=z angz[blocos]=90 juntae[blocos]="Topo" juntad[blocos]="Topo" iftipocoelemento="CornijaClassica"thenjuntas[blocos]=1elsejuntas[blocos]=0 juntai[blocos]=0 juntap[blocos]="Topo" juntaf[blocos]="Saliente" blocos=blocos+1 tipo[blocos]="PA04x04x04(Cortar)" posx[blocos]=.15 posy[blocos]=.15 posz[blocos]=z angz[blocos]=0 juntap[blocos]="Topo" juntaf[blocos]="Topo" iftipocoelemento="CornijaClassica"thenjuntas[blocos]=1elsejuntas[blocos]=0 juntai[blocos]=0 juntae[blocos]="Topo" juntad[blocos]="Saliente" endif x=x+.2

!! !!pastilhasdomeiodacornijaclassicaoufaixa !! x=0 ifjunta_e="Recuada"then x=.2 blocosp=blocosp1 endif ifjunta_d="Recuada"then blocosp=blocosp1 endif forxx=1toblocosp blocos=blocos+1 tipo[blocos]="PA19x14x04" posx[blocos]=x posy[blocos]=.05 posz[blocos]=z angz[blocos]=0 juntaf[blocos]="Topo" juntap[blocos]="Saliente" iftipocoelemento="CornijaClassica"thenjuntas[blocos]=1elsejuntas[blocos]=0 juntai[blocos]=0 ifxx=1andjunta_e<>"Recuada"thenjuntae[blocos]=junta_eelsejuntae[blocos]="Topo" ifxx=blocospandjunta_d<>"Recuada"thenjuntad[blocos]=junta_delsejuntad[blocos]="Saliente" blocos=blocos+1 tipo[blocos]="PA09x19x04" posx[blocos]=x posy[blocos]=.1 posz[blocos]=z angz[blocos]=90 juntae[blocos]="Topo" juntad[blocos]="Recuada" iftipocoelemento="CornijaClassica"thenjuntas[blocos]=1elsejuntas[blocos]=0 juntai[blocos]=0 ifxx=1andjunta_e<>"Recuada"thenjuntap[blocos]=junta_eelsejuntap[blocos]="Topo" ifxx=blocospandjunta_d<>"Recuada"thenjuntaf[blocos]=junta_delsejuntaf[blocos]="Saliente" x=x+.2 nextxx !! !!pastilhasdaextremidadedireitadacornijaclassicaoufaixa !! ifjunta_d="Recuada"andtipocoelemento<>"CornijaTriglifo"then !! !!terminaodireita !! blocos=blocos+1 tipo[blocos]="PA19x19x04" posx[blocos]=x+.05 posy[blocos]=.05 posz[blocos]=z angz[blocos]=0 juntaf[blocos]="Topo" juntap[blocos]="Saliente" juntas[blocos]=1 iftipocoelemento="CornijaClassica"thenjuntas[blocos]=1elsejuntas[blocos]=0 juntae[blocos]="Topo" juntad[blocos]="Topo" blocos=blocos+1 tipo[blocos]="PA04x19x04" posx[blocos]=x posy[blocos]=.05 posz[blocos]=z angz[blocos]=0 juntaf[blocos]="Topo" juntap[blocos]="Saliente" juntas[blocos]=1 iftipocoelemento="CornijaClassica"thenjuntas[blocos]=1elsejuntas[blocos]=0 juntae[blocos]="Topo" juntad[blocos]="Saliente" blocos=blocos+1 tipo[blocos]="PA04x19x04" posx[blocos]=x+.05 posy[blocos]=.15 posz[blocos]=z angz[blocos]=90

juntae[blocos]="Topo" juntad[blocos]="Topo" juntas[blocos]=1 iftipocoelemento="CornijaClassica"thenjuntas[blocos]=1elsejuntas[blocos]=0 juntap[blocos]="Topo" juntaf[blocos]="Topo" blocos=blocos+1 tipo[blocos]="PA04x04x04(Cortar)" posx[blocos]=x posy[blocos]=.15 posz[blocos]=z angz[blocos]=0 juntap[blocos]="Topo" juntaf[blocos]="Topo" iftipocoelemento="CornijaClassica"thenjuntas[blocos]=1elsejuntas[blocos]=0 juntai[blocos]=0 juntae[blocos]="Topo" juntad[blocos]="Saliente" endif iftipocoelemento<>"CornijaTriglifo"thenz=z+.05 !! !!blocosdaextremidadeesquerdadacornijaclassica !! iftipocoelemento<>"CornijaFaixa"andjunta_e="Recuada"then iftipocoelemento="CornijaClassica"then blocos=blocos+1 tipo[blocos]="BL14x14x19" posx[blocos]=.1 posy[blocos]=.1 posz[blocos]=z angz[blocos]=0 juntaf[blocos]="Recuada" juntap[blocos]="Saliente" juntas[blocos]=0 juntai[blocos]=0 juntae[blocos]="Recuada" juntad[blocos]="Saliente" blocos=blocos+1 tipo[blocos]="BL14x14x19" posx[blocos]=.1 posy[blocos]=.05 posz[blocos]=z angz[blocos]=0 juntaf[blocos]="Topo" juntap[blocos]="Topo" juntas[blocos]=0 juntai[blocos]=0 juntae[blocos]="Recuada" juntad[blocos]="Saliente" blocos=blocos+1 tipo[blocos]="BL14x14x19" posx[blocos]=.05 posy[blocos]=.1 posz[blocos]=z angz[blocos]=0 juntaf[blocos]="Recuada" juntap[blocos]="Saliente" juntas[blocos]=0 juntai[blocos]=0 juntae[blocos]="Topo" juntad[blocos]="Saliente" blocos=blocos+1 tipo[blocos]="BL14x14x19" posx[blocos]=.05 posy[blocos]=.05 posz[blocos]=z angz[blocos]=0 juntaf[blocos]="Topo" juntap[blocos]="Topo" juntas[blocos]=0 juntai[blocos]=0 juntae[blocos]="Topo" juntad[blocos]="Saliente" else blocos=blocos+1

tipo[blocos]="PA04x19x19" posx[blocos]=.05 posy[blocos]=.15 posz[blocos]=z angz[blocos]=90 juntaf[blocos]="Saliente" juntap[blocos]="Recuada" juntas[blocos]=0 juntai[blocos]=0 juntae[blocos]="Topo" juntad[blocos]="Topo" blocos=blocos+1 tipo[blocos]="PA04x19x19" posx[blocos]=.15 posy[blocos]=.05 posz[blocos]=z angz[blocos]=0 juntaf[blocos]="Recuada" juntap[blocos]="Saliente" juntas[blocos]=0 juntai[blocos]=0 juntae[blocos]="Topo" juntad[blocos]="Saliente" blocos=blocos+1 tipo[blocos]="BL19x19x19" posx[blocos]=.05 posy[blocos]=.05 posz[blocos]=z angz[blocos]=0 juntaf[blocos]="Recuada" juntap[blocos]="Saliente" juntas[blocos]=0 juntai[blocos]=0 juntae[blocos]="Recuada" juntad[blocos]="Saliente" blocos=blocos+1 tipo[blocos]="PA04x04x19" posx[blocos]=.15 posy[blocos]=.15 posz[blocos]=z angz[blocos]=0 juntaf[blocos]="Topo" juntap[blocos]="Topo" juntas[blocos]=0 juntai[blocos]=0 juntae[blocos]="Topo" juntad[blocos]="Saliente" endif endif !! !!blocosdomeiodacornijaclassica !! x=0 ifjunta_e="Recuada"then x=.2 blocosf=blocosf2 endif ifjunta_d="Recuada"then blocosf=blocosf2 endif iftipocoelemento="CornijaClassica"then forxx=1toblocosf blocos=blocos+1 tipo[blocos]="BL29x09x19" posx[blocos]=x posy[blocos]=.1 posz[blocos]=z angz[blocos]=90 ifxx=blocosfandjunta_d="Recuada"thenjuntad[blocos]="Topo"elsejuntad[blocos]="Recuada" juntae[blocos]="Recuada" juntas[blocos]=0 juntai[blocos]=0 juntap[blocos]="Topo" juntaf[blocos]="Saliente" ifxx=1andjunta_e<>"Recuada"thenjuntap[blocos]=junta_e ifxx=blocosfandjunta_d<>"Recuada"thenjuntaf[blocos]=junta_d x=x+.1 nextxx else x1=x forxx=1toblocosf blocos=blocos+1

tipo[blocos]="BL09x19x19" posx[blocos]=x posy[blocos]=.05 posz[blocos]=z angz[blocos]=0 juntaf[blocos]="Recuada" juntap[blocos]="Saliente" juntas[blocos]=0 juntai[blocos]=0 juntae[blocos]="Topo" juntad[blocos]="Saliente" ifxx=1andjunta_e<>"Recuada"thenjuntae[blocos]=junta_e ifxx=blocosfandjunta_d<>"Recuada"thenjuntad[blocos]=junta_d x=x+.1 nextxx x=x1 forxx=1toblocosf/2 blocos=blocos+1 tipo[blocos]="PA04x19x19" posx[blocos]=x posy[blocos]=.15 posz[blocos]=z angz[blocos]=90 juntad[blocos]="Recuada" juntae[blocos]="Topo" juntas[blocos]=0 juntai[blocos]=0 juntap[blocos]="Topo" juntaf[blocos]="Saliente" ifxx=1andjunta_e<>"Recuada"thenjuntap[blocos]=junta_e ifxx=blocosf/2andjunta_d<>"Recuada"thenjuntaf[blocos]=junta_d x=x+.2 nextxx endif !! !!blocosdaextremidadedireitadacornija !! iftipocoelemento<>"CornijaFaixa"andjunta_d="Recuada"then iftipocoelemento="CornijaClassica"then blocos=blocos+1 tipo[blocos]="BL14x14x19" posx[blocos]=x posy[blocos]=.1 posz[blocos]=z angz[blocos]=0 juntaf[blocos]="Recuada" juntap[blocos]="Saliente" juntas[blocos]=0 juntai[blocos]=0 juntae[blocos]="Topo" juntad[blocos]="Saliente" blocos=blocos+1 tipo[blocos]="BL14x14x19" posx[blocos]=x posy[blocos]=.05 posz[blocos]=z angz[blocos]=0 juntaf[blocos]="Topo" juntap[blocos]="Topo" juntas[blocos]=0 juntai[blocos]=0 juntae[blocos]="Topo" juntad[blocos]="Saliente" blocos=blocos+1 tipo[blocos]="BL14x14x19" posx[blocos]=x+.15 posy[blocos]=.1 posz[blocos]=z angz[blocos]=0 juntaf[blocos]="Recuada" juntap[blocos]="Saliente" juntas[blocos]=0 juntai[blocos]=0 juntae[blocos]="Topo" juntad[blocos]="Recuada" blocos=blocos+1 tipo[blocos]="BL14x14x19"

posx[blocos]=x+.15 posy[blocos]=.05 posz[blocos]=z angz[blocos]=0 juntaf[blocos]="Topo" juntap[blocos]="Topo" juntas[blocos]=0 juntai[blocos]=0 juntae[blocos]="Topo" juntad[blocos]="Recuada" else blocos=blocos+1 tipo[blocos]="PA04x19x19" posx[blocos]=a.15 posy[blocos]=.15 posz[blocos]=z angz[blocos]=90 juntaf[blocos]="Topo" juntap[blocos]="Topo" juntas[blocos]=0 juntai[blocos]=0 juntae[blocos]="Topo" juntad[blocos]="Topo" blocos=blocos+1 tipo[blocos]="PA04x19x19" posx[blocos]=a.20 posy[blocos]=.05 posz[blocos]=z angz[blocos]=0 juntaf[blocos]="Recuada" juntap[blocos]="Saliente" juntas[blocos]=0 juntai[blocos]=0 juntae[blocos]="Topo" juntad[blocos]="Saliente" blocos=blocos+1 tipo[blocos]="BL19x19x19" posx[blocos]=a.15 posy[blocos]=.05 posz[blocos]=z angz[blocos]=0 juntaf[blocos]="Recuada" juntap[blocos]="Saliente" juntas[blocos]=0 juntai[blocos]=0 juntae[blocos]="Topo" juntad[blocos]="Recuada" blocos=blocos+1 tipo[blocos]="PA04x04x19" posx[blocos]=a.2 posy[blocos]=.15 posz[blocos]=z angz[blocos]=0 juntaf[blocos]="Topo" juntap[blocos]="Topo" juntas[blocos]=0 juntai[blocos]=0 juntae[blocos]="Topo" juntad[blocos]="Saliente" endif endif !! !!volumessimplificadoscornijaclassica,faixaetriglifo !! ifjunta_e="Saliente"thenxe=0.01elsexe=0 ifjunta_d="Saliente"thenxd=aelsexd=a.01 ifjunta_e="Recuada"then xepast=.05 xecorn=.1 else xepast=xe xecorn=xe endif ifjunta_d="Recuada"then xdpast=a+.04 xdcorn=a+.09 else xdpast=xd xdcorn=xd endif iftipocoelemento="CornijaClassica"thenvsimples=3elsevsimples=2

vsposx[1]=xe vsposy[1]=0 vsposz[1]=0 vsdimx[1]=xdxe vsdimy[1]=.19 iftipocoelemento="CornijaClassica"thenvsdimz[1]=zzyzx.25 iftipocoelemento="CornijaFaixa"thenvsdimz[1]=zzyzx.05 iftipocoelemento="CornijaTriglifo"thenvsdimz[1]=zzyzx.2 vsposx[2]=xepast vsposy[2]=.05 iftipocoelemento="CornijaClassica"thenvsposz[2]=zzyzx.25 iftipocoelemento="CornijaFaixa"thenvsposz[2]=zzyzx.05 iftipocoelemento="CornijaTriglifo"thenvsposz[2]=zzyzx.2 vsdimx[2]=xdpastxepast vsdimy[2]=.24 iftipocoelemento="CornijaTriglifo"thenvsdimz[2]=.2elsevsdimz[2]=.05 iftipocoelemento="CornijaClassica"then vsposx[3]=xecorn vsposy[3]=.1 vsposz[3]=zzyzx.2 vsdimx[3]=xdcornxecorn vsdimy[3]=.29 vsdimz[3]=.2 endif endif !! !!cornijafriso !! iftipocoelemento="CornijaFriso"then !! !!determinaodosblocoscornijafriso !! fiadas=int(zzyzx/.2)1 ifa>.2then blocosx=int(a/.4) tipb="BL39x19x19" tipc="CJ39x19x19(B10)" tipf="BL39x09x19" else blocosx=1 tipb="BL19x19x19" tipc="CJ19x19x19(B10)" tipf="BL19x09x19" endif z=.01 !! !!fiadasabaixodofriso !! forzz=1tofiadas x=0 forxx=1toblocosx blocos=blocos+1 tipo[blocos]=tipb posx[blocos]=x posy[blocos]=0 posz[blocos]=z angz[blocos]=0 juntaf[blocos]="Recuada" juntap[blocos]="Recuada" !ifzz=fiadasthenjuntas[blocos]=1elsejuntas[blocos]=0 juntai[blocos]=1 juntas[blocos]=0 juntae[blocos]="Topo" juntad[blocos]="Saliente" ifxx=1thenjuntae[blocos]=junta_e ifxx=blocosxthenjuntad[blocos]=junta_d x=x+.4 nextxx z=z+.2 nextzz !! !!friso(blocoscanaletadeitados) !! xfriso=0 !! !!juntaesquerdarecuada !! ifjunta_e="Recuada"then xfriso=.4 blocosx=blocosx1

blocos=blocos+1 tipo[blocos]="CJ39x19x19(B10Ca)" posx[blocos]=.2 posy[blocos]=.1 posz[blocos]=z angz[blocos]=0 juntaf[blocos]="Topo" juntap[blocos]="Topo" juntas[blocos]=0 juntai[blocos]=1 juntae[blocos]="Recuada" juntad[blocos]="Saliente"

blocos=blocos+1 tipo[blocos]="CJ39x19x19(B10Cb)" posx[blocos]=.1 posy[blocos]=.2 posz[blocos]=z angz[blocos]=90 juntaf[blocos]="Topo" juntap[blocos]="Topo" juntas[blocos]=0 juntai[blocos]=1 juntae[blocos]="Topo" juntad[blocos]="Recuada"

blocos=blocos+1 tipo[blocos]="BL09x09x19" posx[blocos]=.1 posy[blocos]=.1 posz[blocos]=z angz[blocos]=0 juntaf[blocos]="Saliente" juntap[blocos]="Topo" juntas[blocos]=0 juntai[blocos]=1 juntae[blocos]="Saliente" juntad[blocos]="Saliente"

blocos=blocos+1 tipo[blocos]="CJ19x19x19(B10)" posx[blocos]=.2 posy[blocos]=.1 posz[blocos]=z angz[blocos]=0 juntaf[blocos]="Topo" juntap[blocos]="Saliente" juntas[blocos]=0 juntai[blocos]=1 juntae[blocos]="Topo" juntad[blocos]="Saliente"

blocos=blocos+1 tipo[blocos]="BL09x19x19" posx[blocos]=.2 posy[blocos]=.1 posz[blocos]=z angz[blocos]=90 juntaf[blocos]="Saliente" juntap[blocos]="Topo" juntas[blocos]=0 juntai[blocos]=1 endif juntae[blocos]="Topo" juntad[blocos]="Topo"

!! !!juntadireitarecuada !! ifjunta_d="Recuada"then blocosx=blocosx1 blocos=blocos+1 tipo[blocos]="CJ39x19x19(B10Ca)" posx[blocos]=a.1 posy[blocos]=.2 posz[blocos]=z angz[blocos]=90 juntaf[blocos]="Topo" juntap[blocos]="Topo" juntas[blocos]=0 juntai[blocos]=1 juntae[blocos]="Recuada" juntad[blocos]="Topo"

blocos=blocos+1 tipo[blocos]="CJ39x19x19(B10Cb)"

posx[blocos]=a.2 posy[blocos]=.1 posz[blocos]=z angz[blocos]=0 juntaf[blocos]="Topo" juntap[blocos]="Topo" juntas[blocos]=0 juntai[blocos]=1 juntae[blocos]="Topo" juntad[blocos]="Recuada" blocos=blocos+1 tipo[blocos]="BL09x09x19" posx[blocos]=a.2 posy[blocos]=.1 posz[blocos]=z angz[blocos]=0 juntaf[blocos]="Saliente" juntap[blocos]="Topo" juntas[blocos]=0 juntai[blocos]=1 juntae[blocos]="Topo" juntad[blocos]="Saliente" blocos=blocos+1 tipo[blocos]="CJ19x19x19(B10)" posx[blocos]=a.4 posy[blocos]=.1 posz[blocos]=z angz[blocos]=0 juntaf[blocos]="Topo" juntap[blocos]="Saliente" juntas[blocos]=0 juntai[blocos]=1 juntae[blocos]="Topo" juntad[blocos]="Saliente" blocos=blocos+1 tipo[blocos]="BL09x19x19" posx[blocos]=a.4 posy[blocos]=.1 posz[blocos]=z angz[blocos]=90 juntaf[blocos]="Saliente" juntap[blocos]="Topo" juntas[blocos]=0 juntai[blocos]=1 juntae[blocos]="Topo" juntad[blocos]="Topo" endif !! !!blocosdomeiodofriso !! x=xfriso forxx=1toblocosx blocos=blocos+1 tipo[blocos]=tipc posx[blocos]=x posy[blocos]=.1 posz[blocos]=z angz[blocos]=0 juntaf[blocos]="Topo" juntap[blocos]="Saliente" juntas[blocos]=0 juntai[blocos]=1 juntae[blocos]="Topo" juntad[blocos]="Saliente" ifxx=1then ifjunta_e<>"Recuada"thenjuntae[blocos]=junta_eelsejuntae[blocos]="Topo" endif ifxx=blocosxthen ifjunta_d<>"Recuada"thenjuntad[blocos]=junta_delsejuntad[blocos]="Saliente" endif blocos=blocos+1 tipo[blocos]=tipf posx[blocos]=x posy[blocos]=.1 posz[blocos]=z angz[blocos]=0 juntaf[blocos]="Topo" juntap[blocos]="Recuada" juntas[blocos]=0 juntai[blocos]=1

juntae[blocos]="Topo" juntad[blocos]="Saliente" ifxx=1then ifjunta_e<>"Recuada"thenjuntae[blocos]=junta_eelsejuntae[blocos]="Topo" endif ifxx=blocosxthen ifjunta_d<>"Recuada"thenjuntad[blocos]=junta_delsejuntad[blocos]="Saliente" endif x=x+.4 nextxx !! !!Volumessimplificadoscornijafriso !! ifjunta_e="Saliente"thenxe=0.01elsexe=0 ifjunta_d="Saliente"thenxd=aelsexd=a.01 ifjunta_e="Recuada"then xefris=.065 xecorn=.1 else xefris=xe xecorn=xe endif ifjunta_d="Recuada"then xdfris=a.065 xdcorn=a+.1 else xdfris=xd xdcorn=xd endif vsimples=4 vsposx[1]=xe vsposy[1]=0 vsposz[1]=0 vsdimx[1]=xdxe vsdimy[1]=.19 vsdimz[1]=zzyzx.2 vsposx[2]=xe vsposy[2]=0 vsposz[2]=zzyzx.2 vsdimx[2]=xdxe vsdimy[2]=.19 vsdimz[2]=0.035 vsposx[3]=xefris vsposy[3]=.065 vsposz[3]=zzyzx.165 vsdimx[3]=xdfrisxefris vsdimy[3]=.125 vsdimz[3]=.14 vsposx[4]=xecorn vsposy[4]=.1 vsposz[4]=zzyzx.025 vsdimx[4]=xdcornxecorn vsdimy[4]=.29 vsdimz[4]=.025 endif !! !!arquitrave !! iftipocoelemento="Arquitrave40"ortipocoelemento="Arquitrave20"then !! !!blocosdaarquitrave !! x=0 blocosx=int(a/.1) forxx=1toblocosx blocos=blocos+1 tipo[blocos]="PA09x19x04" posx[blocos]=x posy[blocos]=0 posz[blocos]=.01 angz[blocos]=0 iftipocoelemento="Arquitrave40"thenjuntap[blocos]="Saliente"elsejuntap[blocos]=junta_p juntaf[blocos]=junta_f juntas[blocos]=0 ifxx=1orxx=blocosxthen ifa=1.4ora=2.8thenjuntai[blocos]=1elsejuntai[blocos]=0 endif juntae[blocos]="Topo" juntad[blocos]="Saliente" ifxx=1then

ifjunta_e<>"Recuada"thenjuntae[blocos]=junta_eelsejuntae[blocos]="Topo" juntad[blocos]="Topo" endif ifxx=blocosxthen ifjunta_d<>"Recuada"thenjuntad[blocos]=junta_delsejuntad[blocos]="Saliente" juntae[blocos]="Topo" endif ifxx=2thenjuntae[blocos]="Saliente" iftipocoelemento="Arquitrave40"then blocos=blocos+1 tipo[blocos]="PA09x19x04" posx[blocos]=x posy[blocos]=.2 posz[blocos]=.01 angz[blocos]=0 juntap[blocos]=junta_p juntaf[blocos]="Topo" juntas[blocos]=0 ifxx=1orxx=blocosxthen ifa=1.4ora=2.8thenjuntai[blocos]=1elsejuntai[blocos]=0 endif juntae[blocos]="Topo" juntad[blocos]="Saliente" ifxx=1then ifjunta_e<>"Recuada"thenjuntae[blocos]=junta_eelsejuntae[blocos]="Topo" juntad[blocos]="Topo" endif ifxx=blocosxthen ifjunta_d<>"Recuada"thenjuntad[blocos]=junta_delsejuntad[blocos]="Saliente" juntae[blocos]="Topo" endif ifxx=2thenjuntae[blocos]="Saliente" endif x=x+.1 nextxx x=0 forxx=1toblocosx blocos=blocos+1 iftipocoelemento="Arquitrave40"thentipo[blocos]="BL39x09x19"elsetipo[blocos]="BL09x19x 19" posx[blocos]=x posy[blocos]=0 posz[blocos]=.06 iftipocoelemento="Arquitrave40"then angz[blocos]=90 juntad[blocos]=junta_p juntae[blocos]=junta_f juntas[blocos]=0 juntai[blocos]=1 ifxx=1andjunta_e<>"Recuada"thenjuntap[blocos]=junta_eelsejuntap[blocos]="Topo" ifxx=blocosxandjunta_d<>"Recuada"thenjuntaf[blocos]=junta_delsejuntaf[blocos]= "Saliente" else angz[blocos]=0 juntap[blocos]=junta_p juntaf[blocos]=junta_f juntas[blocos]=0 juntai[blocos]=1 ifxx=1andjunta_e<>"Recuada"thenjuntae[blocos]=junta_eelsejuntae[blocos]="Topo" ifxx=blocosxandjunta_d<>"Recuada"thenjuntad[blocos]=junta_delsejuntad[blocos]= "Saliente" endif x=x+.1 nextxx !! !!terminaoesquerda !! ifjunta_e="Recuada"then blocos=blocos+1 tipo[blocos]="PA09x19x04" posx[blocos]=.1 posy[blocos]=0 posz[blocos]=.01 angz[blocos]=0 iftipocoelemento="Arquitrave40"thenjuntap[blocos]="Saliente"elsejuntap[blocos]=junta_p juntaf[blocos]=junta_f juntas[blocos]=0 ifa=1.4ora=2.8thenjuntai[blocos]=1elsejuntai[blocos]=0 juntae[blocos]="Recuada" juntad[blocos]="Saliente" iftipocoelemento="Arquitrave40"then blocos=blocos+1 tipo[blocos]="PA09x19x04" posx[blocos]=.1 posy[blocos]=.2 posz[blocos]=.01 angz[blocos]=0

19" 19"

endif

juntap[blocos]=junta_p juntaf[blocos]="Topo" juntas[blocos]=0 ifa=1.4ora=2.8thenjuntai[blocos]=1elsejuntai[blocos]=0 juntae[blocos]="Recuada" juntad[blocos]="Saliente"

endif

blocos=blocos+1 iftipocoelemento="Arquitrave40"thentipo[blocos]="BL39x09x19"elsetipo[blocos]="BL09x19x posx[blocos]=.1 posy[blocos]=0 posz[blocos]=.06 iftipocoelemento="Arquitrave40"then angz[blocos]=90 juntad[blocos]=junta_p juntae[blocos]=junta_f juntas[blocos]=0 juntai[blocos]=1 juntap[blocos]="Recuada" juntaf[blocos]="Saliente" else angz[blocos]=0 juntaf[blocos]=junta_f juntap[blocos]=junta_p juntas[blocos]=0 juntai[blocos]=1 juntae[blocos]="Recuada" juntad[blocos]="Saliente" endif

!! !!terminaodireita !! ifjunta_d="Recuada"then blocos=blocos+1 tipo[blocos]="PA09x19x04" posx[blocos]=a posy[blocos]=0 posz[blocos]=.01 angz[blocos]=0 iftipocoelemento="Arquitrave40"thenjuntap[blocos]="Saliente"elsejuntap[blocos]=junta_p juntaf[blocos]=junta_f juntas[blocos]=0 ifa=1.4ora=2.8thenjuntai[blocos]=1elsejuntai[blocos]=0 juntae[blocos]="Topo" juntad[blocos]="Recuada"

iftipocoelemento="Arquitrave40"then blocos=blocos+1 tipo[blocos]="PA09x19x04" posx[blocos]=a posy[blocos]=.2 posz[blocos]=.01 angz[blocos]=0 juntap[blocos]=junta_p juntaf[blocos]="Topo" juntas[blocos]=0 ifa=1.4ora=2.8thenjuntai[blocos]=1elsejuntai[blocos]=0 endif juntae[blocos]="Topo" juntad[blocos]="Recuada"

endif

blocos=blocos+1 iftipocoelemento="Arquitrave40"thentipo[blocos]="BL39x09x19"elsetipo[blocos]="BL09x19x posx[blocos]=a posy[blocos]=0 posz[blocos]=.06 iftipocoelemento="Arquitrave40"then angz[blocos]=90 juntad[blocos]=junta_p juntae[blocos]=junta_f juntas[blocos]=0 juntai[blocos]=1 juntap[blocos]="Topo" juntaf[blocos]="Recuada" else angz[blocos]=0 juntap[blocos]=junta_p juntaf[blocos]=junta_f juntas[blocos]=0 juntai[blocos]=1 juntae[blocos]="Topo" juntad[blocos]="Recuada" endif

!! !!volumesimplificadoarquitrave !! ifjunta_e="Recuada"thenxe=.1 ifjunta_e="Saliente"thenxe=.01 ifjunta_e="Topo"thenxe=0 ifjunta_d="Recuada"thenxd=a+.09 ifjunta_d="Saliente"thenxd=a ifjunta_d="Topo"thenxd=a.01 ifjunta_f="Saliente"thenyf=.01elseyf=0 iftipocoelemento="Arquitrave40"then ifjunta_p="Saliente"thenyp=.4elseyp=.39 else ifjunta_p="Saliente"thenyp=.2elseyp=.19 endif vsimples=1 vsposx[1]=xe vsposy[1]=yf vsposz[1]=0 vsdimx[1]=xdxe vsdimy[1]=ypyf vsdimz[1]=.25 endif !! !!ParedeEV(Elementosvazados) !! iftipocoelemento="ParedeEV"then !! !!Elementosvazados !! fiadas=int(zzyzx/.2) blocosx=int(a/.2) z=.01 forzz=1tofiadas x=0 forxx=1toblocosx blocos=blocos+1 tipo[blocos]="EV19x19x19" posx[blocos]=x posy[blocos]=0 posz[blocos]=z angz[blocos]=0 juntaf[blocos]="Recuada" juntap[blocos]="Recuada" juntas[blocos]=0 juntai[blocos]=1 juntae[blocos]="Topo" juntad[blocos]="Saliente" ifxx=1thenjuntae[blocos]=junta_e ifxx=blocosxthenjuntad[blocos]=junta_d x=x+.2 nextxx z=z+.2 nextzz !! !!ParedeEVvolumesimples !! vsimples=1 ifjunta_e="Saliente"thenxe=.01elsexe=0 ifjunta_d="Saliente"thenxd=aelsexd=a.01 vsposx[1]=xe vsposy[1]=0 vsposz[1]=0 vsdimx[1]=xdxe vsdimy[1]=.19 vsdimz[1]=zzyzx endif !! !!Paredebaixa !! iftipocoelemento="Paredebaixa"then !! !!blocosdaparedebaixa !! fiadas=int(zzyzx/.2)1 ifa>.2then

else endif

tipbl="BL39x19x19" tipca="CA39x14x09" blocosx=int(a/.4) blocosp=int(a/.2) tipbl="BL19x19x19" tipca="CA19x14x09" blocosx=1 blocosp=1

z=.01 !! !!blocosabaixodaterminao !! forzz=1tofiadas x=0 forxx=1toblocosx blocos=blocos+1 tipo[blocos]=tipbl posx[blocos]=x posy[blocos]=0 posz[blocos]=z angz[blocos]=0 juntaf[blocos]="Recuada" juntap[blocos]="Recuada" juntas[blocos]=0 juntai[blocos]=1

juntae[blocos]="Topo" juntad[blocos]="Saliente" ifxx=1thenjuntae[blocos]=junta_e ifxx=blocosxthenjuntad[blocos]=junta_d x=x+.4 nextxx z=z+.2 nextzz

!! !!terminao !! x=0 forxx=1toblocosp blocos=blocos+1 tipo[blocos]="PA19x19x04" posx[blocos]=x posy[blocos]=0 posz[blocos]=zzyzx.19 angz[blocos]=0 juntaf[blocos]="Recuada" juntap[blocos]="Recuada" juntas[blocos]=0 juntai[blocos]=1 juntae[blocos]="Topo" juntad[blocos]="Saliente" ifxx=1thenjuntae[blocos]=junta_e ifxx=blocospthenjuntad[blocos]=junta_d

nextxx

blocos=blocos+1 tipo[blocos]="PA19x19x04" posx[blocos]=x posy[blocos]=0 posz[blocos]=zzyzx.04 angz[blocos]=0 juntaf[blocos]="Recuada" juntap[blocos]="Recuada" juntas[blocos]=0 juntai[blocos]=0 juntae[blocos]="Topo" juntad[blocos]="Saliente" ifxx=1thenjuntae[blocos]=junta_e ifxx=blocospthenjuntad[blocos]=junta_d x=x+.2

x=0 forxx=1toblocosx blocos=blocos+1 tipo[blocos]=tipca posx[blocos]=x posy[blocos]=.025 posz[blocos]=zzyzx.14 angz[blocos]=0 juntaf[blocos]="Recuada" juntap[blocos]="Recuada" juntas[blocos]=1 juntai[blocos]=1

juntae[blocos]="Topo" juntad[blocos]="Saliente" ifxx=1thenjuntae[blocos]=junta_e ifxx=blocosxthenjuntad[blocos]=junta_d x=x+.4 nextxx !! !!paredebaixavolumessimples !! vsimples=3 ifjunta_e="Saliente"thenxe=.01elsexe=0 ifjunta_d="Saliente"thenxd=aelsexd=a.01 vsposx[1]=xe vsposy[1]=0 vsposz[1]=0 vsdimx[1]=xdxe vsdimy[1]=.19 vsdimz[1]=zzyzx.15 vsposx[2]=xe vsposy[2]=.025 vsposz[2]=zzyzx.15 vsdimx[2]=xdxe vsdimy[2]=.14 vsdimz[2]=.1 vsposx[3]=xe vsposy[3]=0 vsposz[3]=zzyzx.05 vsdimx[3]=xdxe vsdimy[3]=.19 vsdimz[3]=.05 endif 2DScript !!!determinaodafiadacortada !!! hcorte=glob_cutplanes_info[1]glob_elevation+.01 ifhcorte>zzyzxthen preenchimento=0 hcorte=zzyzx.01 else preenchimento=bl_fill2d endif !!! !!!desenhodosblocos !!! forbloco=1toblocos ifangz[bloco]=0thenvars=split(tipo[bloco],"%s%nx%nx%n",tip,dx,s1,dy,s2,dz) ifangz[bloco]=90orangz[bloco]=90thenvars=split(tipo[bloco],"%s%nx%nx%n",tip,dy,s1,dx,s2,dz) dx=dx/100 dy=dy/100 dz=dz/100 pos=strstr(tipo[bloco],"(") ifpos=0thencomplemento=""elsecomplemento=strsub(tipo[bloco],pos,strlen(tipo[bloco])+1) cond1=(hcorte>=posz[bloco]) cond2=(hcorte<posz[bloco]+dz) ifcond1andcond2then !!identificandoovolume forv=1tovsimples if(posz[bloco]>vsposz[v])and(posz[bloco]+dz<=vsposz[v]+vsdimz[v]+.01)thenvol=v nextv ifvol=0thenvol=vsimples add2posx[bloco],posy[bloco] ifangz[bloco]=90then add2dx,0 endif ifangz[bloco]=90then add20,dy endif rot2angz[bloco] !!eliminarjuntasdesnecessrias blxe=int(posx[bloco]*100) blxd=int(posx[bloco]*100)+int(dx*100) blyf=int(posy[bloco]*100)

blyp=int(posy[bloco]*100)+int(dy*100) voxe=int(vsposx[vol]*100) voxd=int(vsposx[vol]*100)+int(vsdimx[vol]*100) voyf=int(vsposy[vol]*100) voyp=int(vsposy[vol]*100)+int(vsdimy[vol]*100) juntae2d=juntae[bloco] juntad2d=juntad[bloco] juntaf2d=juntaf[bloco] juntap2d=juntap[bloco] ifblyp<voypthen ifangz[bloco]=0then ifblxe>voxethenjuntae2d="Saliente" ifblxd<voxdthenjuntad2d="Saliente" juntap2d="Saliente" endif ifangz[bloco]=90then ifblxe>voxethenjuntap2d="Saliente" ifblxd<voxdthenjuntaf2d="Saliente" juntad2d="Saliente" endif ifangz[bloco]=90then ifblxe>voxethenjuntaf2d="Saliente" ifblxd<voxdthenjuntap2d="Saliente" juntae2d="Saliente" endif else ifblyf>voyfthen ifangz[bloco]=0then ifblxe>voxethenjuntae2d="Saliente" ifblxd<voxdthenjuntad2d="Saliente" juntaf2d="Saliente" endif ifangz[bloco]=90then ifblxe>voxethenjuntap2d="Saliente" ifblxd<voxdthenjuntaf2d="Saliente" juntae2d="Saliente" endif ifangz[bloco]=90then ifblxe>voxethenjuntaf2d="Saliente" ifblxd<voxdthenjuntap2d="Saliente" juntad2d="Saliente" endif endif endif ifcomplemento<>"(B10Ca)"andcomplemento<>"(B10Cb)"thenhps=0elsehps=1 drawindex50 call"Blocosdeconcreto"parameterstipobloco=tipo[bloco], juntae2d, juntaf2d, juntap2d, bloco_fill2d=preenchimento, bloco_contorno2d=bl_contorno2d, bloco_hachura2d=bl_hachura2d, bloco_fundo2d=bl_fundo2d, junta_fill2d=ju_fill2d, junta_contorno2d=ju_contorno2d, junta_hachura2d=ju_hachura2d, junta_fundo2d=ju_fundo2d, "Desligado", rep2d, hps rot2angz[bloco] ifangz[bloco]=90then add2dx,0 endif ifangz[bloco]=90then add20,dy endif ifcomplemento<>"(B10Ca)"andcomplemento<>"(B10Cb)"then hotspot20,0,hp,b,1 hotspot20,dy,hp+1,b,1 hotspot2dx,0,hp+2,b,1 hotspot2dx,dy,hp+3,b,1

junta_e=

junta_d=juntad2d, junta_f= junta_p=

tipo3d= tipo2d= hotspots=

hp=hp+4 endif deltop endif nextbloco !!! !!!hotspots !!! iftipocoelemento="Parede10"ortipocoelemento="Listelo10"thenhsy=.045elsehsy=.095 hotspot20,hsy,hp,a,257 hotspot2a,hsy,hp+1,a,2 3DScript !! !!blocos !! ifrep3d="Detalhado"orrep3d="Padrao"then forbloco=1toblocos vars=split(tipo[bloco],"%s%nx%nx%n%s",tip,dx,s1,dy,s2,dz,complemento) dx=dx/100 dy=dy/100 dz=dz/100 addposx[bloco],posy[bloco],posz[bloco] ifangz[bloco]=90then addxdy endif ifangz[bloco]=90then addydx endif rotzangz[bloco] call"Blocosdeconcreto"parameterstipobloco=tipo[bloco], junta_e= juntae[bloco], junta_d= juntad[bloco], junta_f= juntaf[bloco], junta_p= juntap[bloco], junta_s= juntas[bloco], junta_i= juntai[bloco], bloco_fill2d=bl_fill2d, bloco_contorno2d=bl_contorno2d, bloco_hachura2d=bl_hachura2d, bloco_fundo2d=bl_fundo2d, junta_fill2d=ju_fill2d, junta_contorno2d=ju_contorno2d, junta_hachura2d=ju_hachura2d, junta_fundo2d=ju_fundo2d, bloco_material=bl_material, bloco_contorno3d=bl_contorno3d, junta_material=ju_material, junta_contorno3d=ju_contorno3d, tipo3d= rep3d, tipo2d= rep2d deltop nextbloco else !! !!volumesimplificado !! iftipocoelemento="ParedeEV"thengroup"blocos" forv=1tovsimples sect_fillbl_fill2d,bl_fundo2d,bl_hachura2d,bl_contorno2d penbl_contorno3d

setmaterialbl_material addvsposx[v],vsposy[v],vsposz[v] blockvsdimx[v],vsdimy[v],vsdimz[v] deltop zz=vsposz[1]+.01 forbloco=1toblocos ifangz[bloco]=0then vars=split(tipo[bloco],"%s%nx%nx%n",tip,dx,s1,dy,s2,dz) else vars=split(tipo[bloco],"%s%nx%nx%n",tip,dy,s1,dx,s2,dz) endif dx=dx/100 dy=dy/100 dz=dz/100 pos=strstr(tipo[bloco],"(") ifpos=0thencomplemento=""elsecomplemento=strsub(tipo[bloco],pos, strlen(tipo[bloco])+1) ifcomplemento="(B10)"andv=vsimplesthen ifposx[bloco]>0then lin_posx[bloco],posy[bloco]+.1,posz[bloco].01, posx[bloco],posy[bloco]+.1,posz[bloco]+.025 lin_posx[bloco],posy[bloco]+.165,posz[bloco]+.025, posx[bloco],posy[bloco]+.165,posz[bloco]+.165 lin_posx[bloco],posy[bloco],posz[bloco]+.165, posx[bloco],posy[bloco],posz[bloco]+.19 endif ifposx[bloco]+dx<vsposx[v]+vsdimx[v]then lin_posx[bloco]+dx+.01,posy[bloco]+.1,posz[bloco].01, posx[bloco]+dx+.01,posy[bloco]+.1,posz[bloco]+.025 lin_posx[bloco]+dx+.01,posy[bloco]+.165,posz[bloco]+.025, posx[bloco]+dx+.01,posy[bloco]+.165,posz[bloco]+.165 lin_posx[bloco]+dx+.01,posy[bloco],posz[bloco]+.165, posx[bloco]+dx+.01,posy[bloco],posz[bloco]+.19 endif endif if(posz[bloco]>vsposz[v])and(posz[bloco]+dz<=vsposz[v]+vsdimz[v]+.01)then sect_fillju_fill2d,ju_fundo2d,ju_hachura2d,ju_contorno2d penju_contorno3d !! !!juntashorizontais !! ifposz[bloco]<>zzthen zz=posz[bloco] lin_vsposx[v],vsposy[v],posz[bloco].01, vsposx[v]+vsdimx[v],vsposy[v],posz[bloco].01 lin_vsposx[v],vsposy[v]+vsdimy[v],posz[bloco].01, vsposx[v]+vsdimx[v],vsposy[v]+vsdimy[v],posz[bloco].01 ifjunta_e<>"Saliente"thenlin_vsposx[v],vsposy[v],posz[bloco].01, vsposx[v],vsposy[v]+vsdimy[v],posz[bloco].01 ifjunta_d<>"Saliente"thenlin_vsposx[v]+vsdimx[v],vsposy[v], posz[bloco].01, vsposx[v]+vsdimx[v],vsposy[v]+vsdimy[v],posz[bloco].01 endif !! !!juntasverticais !! ifstr(posy[bloco],8,2)=str(vsposy[v],8,2)andposx[bloco]>vsposx[v]+.01then lin_posx[bloco],posy[bloco],posz[bloco].01, posx[bloco],posy[bloco],posz[bloco]+dz endif ifstr(posy[bloco]+dy,8,2)=str(vsposy[v]+vsdimy[v],8,2)andposx[bloco]> vsposx[v]+.01then lin_posx[bloco],posy[bloco]+dy,posz[bloco].01, posx[bloco],posy[bloco]+dy,posz[bloco]+dz endif ifstr(posx[bloco],8,2)=str(vsposx[v],8,2)andjunta_e<>"Saliente"then ifstr(posy[bloco]+dy+.01,8,2)<>str(vsposy[v]+vsdimy[v],8,2)then lin_posx[bloco],posy[bloco]+dy,posz[bloco].01, posx[bloco],posy[bloco]+dy,posz[bloco]+dz endif endif ifstr(posx[bloco]+dx,8,2)=str(vsposx[v]+vsdimx[v],8,2)andjunta_d<> "Saliente"then ifstr(posy[bloco]+dy+.01,8,2)<>str(vsposy[v]+vsdimy[v],8,2)then lin_posx[bloco]+dx,posy[bloco]+dy,posz[bloco].01, posx[bloco]+dx,posy[bloco]+dy,posz[bloco]+dz endif endif endif

nextbloco nextv iftipocoelemento="ParedeEV"then endgroup group"furos" fiadas=int(zzyzx/.2) blocosx=int(a/.2) addz.03 addx.03 forzz=1tofiadas forxx=1toblocosx block.14,.19,.14 addx.2 nextxx delblocosx addz.2 nextzz endgroup deltop placegroupsubgroup("blocos","furos") killgroup"blocos" killgroup"furos" endif endif ParametersScript values"rep3d""Detalhado","Padrao","Simples" values"rep2d""Detalhado","Padrao","Definidopelaescala" values"tipocoelemento""Parede20", "Parede10", "ParedeEV", "Paredebaixa", "Peitorilemnicho", "Listelo20", "Listelo10", "CornijaClassica", "CornijaFaixa", "CornijaFriso", "CornijaTriglifo", "Arquitrave40", "Arquitrave20" iftipocoelemento="Parede20"ortipocoelemento="Parede10"then values"zzyzx".2,range[.2,4]step.2,.2 values"a"0.2,range[0.4,40000]step0.4,0.4 values"faixa"0,range[1,fiadas] values"junta_e""Topo","Recuada","Saliente" values"junta_d""Topo","Recuada","Saliente" values"junta_f","Recuada" values"junta_p","Recuada" endif iftipocoelemento="Peitorilemnicho"then values"zzyzx".65,.85,1.05,1.25,1.65,2.05 values"a"1.2 values"faixa"0,range[1,fiadas] values"junta_e""Saliente" values"junta_d""Saliente" values"junta_f","Recuada" values"junta_p","Recuada" endif iftipocoelemento="Listelo20"ortipocoelemento="Listelo10"then values"zzyzx".25 values"a"0.2,range[0.4,40000]step0.4,0.4 values"faixa"0 values"junta_d""Topo","Recuada","Saliente" values"junta_e""Topo","Recuada","Saliente" values"junta_f","Recuada" values"junta_p","Recuada" endif iftipocoelemento="CornijaClassica"then values"zzyzx".25,.45,.65,.85,1.05,1.25,1.45 values"a"0.2,range[0.4,40000]step0.4,0.4 values"faixa"0 ifa>.2then values"junta_d""Topo","Recuada","Saliente" values"junta_e""Topo","Recuada","Saliente" else values"junta_d""Topo","Saliente" values"junta_e""Topo","Recuada","Saliente" endif values"junta_f","Recuada" values"junta_p","Recuada" endif

iftipocoelemento="CornijaFriso"ortipocoelemento="CornijaTriglifo"then values"zzyzx".2,.4,.6,.8,1,1.2,1.4 values"a"0.2,range[0.4,40000]step0.4,0.4 values"faixa"0 ifa>.2then values"junta_d""Topo","Recuada","Saliente" values"junta_e""Topo","Recuada","Saliente" else values"junta_d""Topo","Saliente" values"junta_e""Topo","Saliente" endif values"junta_f","Recuada" values"junta_p","Recuada" endif iftipocoelemento="CornijaFaixa"then values"zzyzx".05,.25,.45,.65,.85,1.05,1.25,1.45 values"a"0.2,range[0.4,40000]step0.4,0.4 values"faixa"0 ifa>.2then values"junta_d""Topo","Recuada","Saliente" values"junta_e""Topo","Recuada","Saliente" else values"junta_d""Topo","Saliente" values"junta_e""Topo","Saliente" endif values"junta_f","Recuada" values"junta_p","Recuada" endif iftipocoelemento="Arquitrave40"ortipocoelemento="Arquitrave20"then values"zzyzx".25 values"a"1.2,1.4,2.6,2.8 values"faixa",0 values"junta_d""Topo","Recuada","Saliente" values"junta_e""Topo","Recuada","Saliente" values"junta_f""Topo","Recuada","Saliente" values"junta_p""Topo","Recuada","Saliente" endif iftipocoelemento="ParedeEV"then values"zzyzx".2,range[.2,4]step.2,.2 values"a"range[0.2,40000]step0.2,0.2 values"faixa"0 values"junta_d""Topo","Saliente","Recuada" values"junta_e""Topo","Saliente","Recuada" values"junta_f","Recuada" values"junta_p","Recuada" endif iftipocoelemento="Paredebaixa"then values"zzyzx".4,.6,.8,1,1.15 values"a"0.2,range[0.4,40000]step0.4,0.4 values"faixa"0 values"junta_d""Topo","Saliente","Recuada" values"junta_e""Topo","Saliente","Recuada" values"junta_f","Recuada" values"junta_p","Recuada" endif

ApndiceC
ScriptsEEQuant
CeramicTiles(External) DATABASE_SET"EE" surf=0.0000 type="(CTE)" v=REQUEST("Name_of_material",SLAB_MAT_TOP,mat) v=STRSTR(mat,type) ifv<>0thensurf=surf+SLAB_TOP_SURF v=REQUEST("Name_of_material",SLAB_MAT_BOTT,mat) v=STRSTR(mat,type) ifv<>0thensurf=surf+SLAB_BOT_SURF v=REQUEST("Name_of_material",SLAB_MAT_EDGE,mat) v=STRSTR(mat,type) ifv<>0thensurf=surf+SLAB_EDGE_SURF v=REQUEST("Name_of_material",WALL_MAT_A,mat) v=STRSTR(mat,type) ifv<>0thensurf=surf+WALL_SURFACE_A v=REQUEST("Name_of_material",WALL_MAT_B,mat) v=STRSTR(mat,type) ifv<>0thensurf=surf+WALL_SURFACE_B v=REQUEST("Name_of_material",WALL_MAT_EDGE,mat) v=STRSTR(mat,type) ifv<>0thensurf=surf+WALL_EDGE_SURF v=REQUEST("Name_of_material",BEAM_MAT_RIGHT,mat) v=STRSTR(mat,type) ifv<>0thensurf=surf+BEAM_RIGHT_SURF v=REQUEST("Name_of_material",BEAM_MAT_LEFT,mat) v=STRSTR(mat,type) ifv<>0thensurf=surf+BEAM_LEFT_SURF v=REQUEST("Name_of_material",BEAM_MAT_TOP,mat) v=STRSTR(mat,type) ifv<>0thensurf=surf+BEAM_TOP_SURF v=REQUEST("Name_of_material",BEAM_MAT_BOTTOM,mat) v=STRSTR(mat,type) ifv<>0thensurf=surf+BEAM_BOTTOM_SURF v=REQUEST("Name_of_material",BEAM_MAT_END,mat) v=STRSTR(mat,type) ifv<>0thensurf=surf+BEAM_END_SURF v=REQUEST("Name_of_material",COLU_MAT,mat) v=STRSTR(mat,type) ifv<>0then ifint(COLU_VENEER_WIDTH)=0then surf=surf+COLU_CORE_SURF else surf=surf+COLU_VENEER_SURF endif endif v=REQUEST("Name_of_material",ROOF_MAT_TOP,mat) v=STRSTR(mat,type) ifv<>0thensurf=surf+ROOF_TOP_SURF v=REQUEST("Name_of_material",ROOF_MAT_EDGE,mat) v=STRSTR(mat,type) ifv<>0thensurf=surf+ROOF_EDGE_SURF v=REQUEST("Name_of_material",ROOF_MAT_BOTT,mat) v=STRSTR(mat,type) ifv<>0thensurf=surf+ROOF_BOTTOM_SURF v=REQUEST("Name_of_material",MESH_MAT_TOP,mat) v=STRSTR(mat,type) ifv<>0thensurf=surf+MESH_TOP_SURF v=REQUEST("Name_of_material",MESH_MAT_EDGE,mat) v=STRSTR(mat,type) ifv<>0thensurf=surf+MESH_EDGE_SURF v=REQUEST("Name_of_material",MESH_MAT_BOTT,mat) v=STRSTR(mat,type) ifv<>0thensurf=surf+MESH_BOTTOM_SURF emf=surf*78.4275 etr=surf*1.2454 cmf=surf*4.0559 ctr=surf*0.0994 wgt=surf*15.375 REFCOMPONENT"EMF","CTE",emf REFCOMPONENT"ETR","CTE",etr REFCOMPONENT"CMF","CTE",cmf REFCOMPONENT"CTR","CTE",ctr

CeramicTiles(Internal) DATABASE_SET"EE" surf=0.0000 type="(CTI)" v=REQUEST("Name_of_material",SLAB_MAT_TOP,mat) v=STRSTR(mat,type) ifv<>0thensurf=surf+SLAB_TOP_SURF v=REQUEST("Name_of_material",SLAB_MAT_BOTT,mat) v=STRSTR(mat,type) ifv<>0thensurf=surf+SLAB_BOT_SURF v=REQUEST("Name_of_material",SLAB_MAT_EDGE,mat) v=STRSTR(mat,type) ifv<>0thensurf=surf+SLAB_EDGE_SURF v=REQUEST("Name_of_material",WALL_MAT_A,mat) v=STRSTR(mat,type) ifv<>0thensurf=surf+WALL_SURFACE_A v=REQUEST("Name_of_material",WALL_MAT_B,mat) v=STRSTR(mat,type) ifv<>0thensurf=surf+WALL_SURFACE_B v=REQUEST("Name_of_material",WALL_MAT_EDGE,mat) v=STRSTR(mat,type) ifv<>0thensurf=surf+WALL_EDGE_SURF v=REQUEST("Name_of_material",BEAM_MAT_RIGHT,mat) v=STRSTR(mat,type) ifv<>0thensurf=surf+BEAM_RIGHT_SURF v=REQUEST("Name_of_material",BEAM_MAT_LEFT,mat) v=STRSTR(mat,type) ifv<>0thensurf=surf+BEAM_LEFT_SURF v=REQUEST("Name_of_material",BEAM_MAT_TOP,mat) v=STRSTR(mat,type) ifv<>0thensurf=surf+BEAM_TOP_SURF v=REQUEST("Name_of_material",BEAM_MAT_BOTTOM,mat) v=STRSTR(mat,type) ifv<>0thensurf=surf+BEAM_BOTTOM_SURF v=REQUEST("Name_of_material",BEAM_MAT_END,mat) v=STRSTR(mat,type) ifv<>0thensurf=surf+BEAM_END_SURF v=REQUEST("Name_of_material",COLU_MAT,mat) v=STRSTR(mat,type) ifv<>0then ifint(COLU_VENEER_WIDTH)=0then surf=surf+COLU_CORE_SURF else surf=surf+COLU_VENEER_SURF endif endif v=REQUEST("Name_of_material",ROOF_MAT_TOP,mat) v=STRSTR(mat,type) ifv<>0thensurf=surf+ROOF_TOP_SURF v=REQUEST("Name_of_material",ROOF_MAT_EDGE,mat) v=STRSTR(mat,type) ifv<>0thensurf=surf+ROOF_EDGE_SURF v=REQUEST("Name_of_material",ROOF_MAT_BOTT,mat) v=STRSTR(mat,type) ifv<>0thensurf=surf+ROOF_BOTTOM_SURF v=REQUEST("Name_of_material",MESH_MAT_TOP,mat) v=STRSTR(mat,type) ifv<>0thensurf=surf+MESH_TOP_SURF v=REQUEST("Name_of_material",MESH_MAT_EDGE,mat) v=STRSTR(mat,type) ifv<>0thensurf=surf+MESH_EDGE_SURF v=REQUEST("Name_of_material",MESH_MAT_BOTT,mat) v=STRSTR(mat,type) ifv<>0thensurf=surf+MESH_BOTTOM_SURF emf=surf*26.1425 etr=surf*0.4151 cmf=surf*1.3520 ctr=surf*0.3313 wgt=surf*5.125 REFCOMPONENT"EMF","CTI",emf REFCOMPONENT"ETR","CTI",etr REFCOMPONENT"CMF","CTI",cmf REFCOMPONENT"CTR","CTI",ctr REFCOMPONENT"WGT","CTI",wgt

Composites DATABASE_SET"EE" dimlist[] dimcomp[] channel=OPEN("PROP","EE","'EE_key.txt','EE_comp.txt','EE_desc.txt','EE_unit.txt'") in=INPUT(channel,"KEYLIST","KEYNAME,KEYCODE",list) ifGLOB_ELEM_TYPE=5thenrep=WALL_SKINS_NUMBER ifGLOB_ELEM_TYPE=7thenrep=SLAB_SKINS_NUMBER ifGLOB_ELEM_TYPE=8thenrep=ROOF_SKINS_NUMBER forsk=1torep ifGLOB_ELEM_TYPE=5thenr=REQUEST("Name_of_fill",WALL_SKINS_PARAMS[sk][1],mat) ifGLOB_ELEM_TYPE=7thenr=REQUEST("Name_of_fill",SLAB_SKINS_PARAMS[sk][1],mat) ifGLOB_ELEM_TYPE=8thenr=REQUEST("Name_of_fill",ROOF_SKINS_PARAMS[sk][1],mat) ipos=strstr(mat,"EE")+3 epos=strstr(mat,"(") ifepos=0thenepos=strlen(mat) skinmaterial=strsub(mat,ipos,(eposipos)+1) m=1 continue=true do ifstrstr(list[m],skinmaterial)<>0then in=INPUT(channel,"COMPLIST,"+list[m+1],"CODE,QUANTITY",comp) ifGLOB_ELEM_TYPE=5thenquant=(WALL_SKINS_PARAMS[sk][2]/WALL_THICKNESS)* WALL_VOLUME ifGLOB_ELEM_TYPE=7thenquant=(SLAB_SKINS_PARAMS[sk][2]/SLAB_THICKNESS)* SLAB_VOLUME ifGLOB_ELEM_TYPE=8thenquant=(ROOF_SKINS_PARAMS[sk][2]/ROOF_THICKNESS)* (1/cos(ROOF_ANGLE))*ROOF_VOLUME REFCOMPONENTcomp[1],list[m+1],quant REFCOMPONENTcomp[3],list[m+1],quant REFCOMPONENTcomp[5],list[m+1],quant REFCOMPONENTcomp[7],list[m+1],quant REFCOMPONENTcomp[9],list[m+1],quant continue=false endif m=m+2 whilem<=vardim1(list)andcontinue=true nextsk CLOSE(channel) CeramicTiles DATABASE_SET"EE" r=REQUEST("Name_of_material",ROOF_MAT_TOP,roof_type) ifroof_type="EERoofTiles'Francesa'"then tile_lenght=0.4 tile_weight=2.7 tiles_per_squaremeter=16 batten_height=0.02 batten_width=0.04 clay_volume=(ROOF_TOP_SURF*tiles_per_squaremeter*tile_weight)/1900 battens_per_meter=1/tile_lenght batten_volume=(ROOF_TOP_SURF*battens_per_meter*batten_width*batten_height) REFCOMPONENT"EMF","FCR",clay_volume REFCOMPONENT"ETR","FCR",clay_volume REFCOMPONENT"CMF","FCR",clay_volume REFCOMPONENT"CTR","FCR",clay_volume REFCOMPONENT"WGT","FCR",clay_volume REFCOMPONENT"EMF","WKD",batten_volume REFCOMPONENT"ETR","WKD",batten_volume REFCOMPONENT"CMF","WKD",batten_volume REFCOMPONENT"CTR","WKD",batten_volume REFCOMPONENT"WGT","WKD",batten_volume endif

ReinforcedConcrete DATABASE_SET"EE" total=WALL_VOLUME+SLAB_VOLUME+ROOF_VOLUME+MESH_VOLUME+COLU_VOLUME+BEAM_VOLUME steel_rate=95 steel_density=7850 steel_volume=(steel_rate/steel_density)*total concrete_volume=(1steel_volume)*total REFCOMPONENT"EMF","CON",concrete_volume REFCOMPONENT"ETR","CON",concrete_volume REFCOMPONENT"CMF","CON",concrete_volume REFCOMPONENT"CTR","CON",concrete_volume REFCOMPONENT"WGT","CON",concrete_volume REFCOMPONENT"EMF","STL",steel_volume REFCOMPONENT"ETR","STL",steel_volume REFCOMPONENT"CMF","STL",steel_volume REFCOMPONENT"CTR","STL",steel_volume REFCOMPONENT"WGT","STL",steel_volume PrecastSlab DATABASE_SET"EE" steel_rate=95 steel_density=7850 precast_volume=(SLAB_SKINS_PARAMS[2][2]/SLAB_THICKNESS)*SLAB_VOLUME r=REQUEST("Name_of_fill",SLAB_SKINS_PARAMS[2][1],precast_elements) ifprecast_elements="EESlabClayElements8cm"then clay_elements_volume=0.02828*SLAB_TOP_SURF REFCOMPONENT"EMF","FCB",clay_elements_volume REFCOMPONENT"ETR","FCB",clay_elements_volume REFCOMPONENT"CMF","FCB",clay_elements_volume REFCOMPONENT"CTR","FCB",clay_elements_volume REFCOMPONENT"WGT","FCB",clay_elements_volume precast_concrete_volume=0.049570149*SLAB_TOP_SURF precast_steel_volume=0.000607242*SLAB_TOP_SURF endif cap_volume=(SLAB_SKINS_PARAMS[1][2]/SLAB_THICKNESS)*SLAB_VOLUME steel_volume=((steel_rate/steel_density)*cap_volume)+precast_steel_volume concrete_volume=((1steel_volume)*cap_volume)+precast_concrete_volume REFCOMPONENT"EMF","CON",concrete_volume REFCOMPONENT"ETR","CON",concrete_volume REFCOMPONENT"CMF","CON",concrete_volume REFCOMPONENT"CTR","CON",concrete_volume REFCOMPONENT"WGT","CON",concrete_volume REFCOMPONENT"EMF","STL",steel_volume REFCOMPONENT"ETR","STL",steel_volume REFCOMPONENT"CMF","STL",steel_volume REFCOMPONENT"CTR","STL",steel_volume REFCOMPONENT"WGT","STL",steel_volume

Paint(PVA) DATABASE_SET"EE" surf=0.0000 type="(PPV)" v=REQUEST("Name_of_material",SLAB_MAT_TOP,mat) v=STRSTR(mat,type) ifv<>0thensurf=surf+SLAB_TOP_SURF v=REQUEST("Name_of_material",SLAB_MAT_BOTT,mat) v=STRSTR(mat,type) ifv<>0thensurf=surf+SLAB_BOT_SURF v=REQUEST("Name_of_material",SLAB_MAT_EDGE,mat) v=STRSTR(mat,type) ifv<>0thensurf=surf+SLAB_EDGE_SURF v=REQUEST("Name_of_material",WALL_MAT_A,mat) v=STRSTR(mat,type) ifv<>0thensurf=surf+WALL_SURFACE_A v=REQUEST("Name_of_material",WALL_MAT_B,mat) v=STRSTR(mat,type) ifv<>0thensurf=surf+WALL_SURFACE_B v=REQUEST("Name_of_material",WALL_MAT_EDGE,mat) v=STRSTR(mat,type) ifv<>0thensurf=surf+WALL_EDGE_SURF v=REQUEST("Name_of_material",BEAM_MAT_RIGHT,mat) v=STRSTR(mat,type) ifv<>0thensurf=surf+BEAM_RIGHT_SURF v=REQUEST("Name_of_material",BEAM_MAT_LEFT,mat) v=STRSTR(mat,type) ifv<>0thensurf=surf+BEAM_LEFT_SURF v=REQUEST("Name_of_material",BEAM_MAT_TOP,mat) v=STRSTR(mat,type) ifv<>0thensurf=surf+BEAM_TOP_SURF v=REQUEST("Name_of_material",BEAM_MAT_BOTTOM,mat) v=STRSTR(mat,type) ifv<>0thensurf=surf+BEAM_BOTTOM_SURF v=REQUEST("Name_of_material",BEAM_MAT_END,mat) v=STRSTR(mat,type) ifv<>0thensurf=surf+BEAM_END_SURF v=REQUEST("Name_of_material",COLU_MAT,mat) v=STRSTR(mat,type) ifv<>0then ifint(COLU_VENEER_WIDTH)=0then surf=surf+COLU_CORE_SURF else surf=surf+COLU_VENEER_SURF endif endif v=REQUEST("Name_of_material",ROOF_MAT_TOP,mat) v=STRSTR(mat,type) ifv<>0thensurf=surf+ROOF_TOP_SURF v=REQUEST("Name_of_material",ROOF_MAT_EDGE,mat) v=STRSTR(mat,type) ifv<>0thensurf=surf+ROOF_EDGE_SURF v=REQUEST("Name_of_material",ROOF_MAT_BOTT,mat) v=STRSTR(mat,type) ifv<>0thensurf=surf+ROOF_BOTTOM_SURF v=REQUEST("Name_of_material",MESH_MAT_TOP,mat) v=STRSTR(mat,type) ifv<>0thensurf=surf+MESH_TOP_SURF v=REQUEST("Name_of_material",MESH_MAT_EDGE,mat) v=STRSTR(mat,type) ifv<>0thensurf=surf+MESH_EDGE_SURF v=REQUEST("Name_of_material",MESH_MAT_BOTT,mat) v=STRSTR(mat,type) ifv<>0thensurf=surf+MESH_BOTTOM_SURF emf=surf*15.21 etr=surf*0.0189 cmf=surf*1.1199 ctr=surf*0.0015 wgt=surf*0.2340 REFCOMPONENT"EMF","PPV",emf REFCOMPONENT"ETR","PPV",etr REFCOMPONENT"CMF","PPV",cmf REFCOMPONENT"CTR","PPV",ctr REFCOMPONENT"WGT","PPV",wgt

Paint(Oil) DATABASE_SET"EE" surf=0.0000 type="(POI)" ifGLOB_ELEM_TYPE=3then surf=surf+WIDO_RSIDE_SURF*0.19+WIDO_OPRSIDE_SURF*0.19 surf=surf+2*(WIDO_FRAME_THICKNESS*WIDO_RSIDE_HEIGHT) surf=surf+2*(WIDO_FRAME_THICKNESS*WIDO_RSIDE_WIDTH) endif ifGLOB_ELEM_TYPE=4then surf=surf+WIDO_RSIDE_SURF+WIDO_OPRSIDE_SURF surf=surf+2*(WIDO_FRAME_THICKNESS*WIDO_RSIDE_HEIGHT) surf=surf+WIDO_FRAME_THICKNESS*WIDO_RSIDE_WIDTH endif v=REQUEST("Name_of_material",SLAB_MAT_TOP,mat) v=STRSTR(mat,type) ifv<>0thensurf=surf+SLAB_TOP_SURF v=REQUEST("Name_of_material",SLAB_MAT_BOTT,mat) v=STRSTR(mat,type) ifv<>0thensurf=surf+SLAB_BOT_SURF v=REQUEST("Name_of_material",SLAB_MAT_EDGE,mat) v=STRSTR(mat,type) ifv<>0thensurf=surf+SLAB_EDGE_SURF v=REQUEST("Name_of_material",WALL_MAT_A,mat) v=STRSTR(mat,type) ifv<>0thensurf=surf+WALL_SURFACE_A v=REQUEST("Name_of_material",WALL_MAT_B,mat) v=STRSTR(mat,type) ifv<>0thensurf=surf+WALL_SURFACE_B v=REQUEST("Name_of_material",WALL_MAT_EDGE,mat) v=STRSTR(mat,type) ifv<>0thensurf=surf+WALL_EDGE_SURF v=REQUEST("Name_of_material",BEAM_MAT_RIGHT,mat) v=STRSTR(mat,type) ifv<>0thensurf=surf+BEAM_RIGHT_SURF v=REQUEST("Name_of_material",BEAM_MAT_LEFT,mat) v=STRSTR(mat,type) ifv<>0thensurf=surf+BEAM_LEFT_SURF v=REQUEST("Name_of_material",BEAM_MAT_TOP,mat) v=STRSTR(mat,type) ifv<>0thensurf=surf+BEAM_TOP_SURF v=REQUEST("Name_of_material",BEAM_MAT_BOTTOM,mat) v=STRSTR(mat,type) ifv<>0thensurf=surf+BEAM_BOTTOM_SURF v=REQUEST("Name_of_material",BEAM_MAT_END,mat) v=STRSTR(mat,type) ifv<>0thensurf=surf+BEAM_END_SURF v=REQUEST("Name_of_material",COLU_MAT,mat) v=STRSTR(mat,type) ifv<>0then ifint(COLU_VENEER_WIDTH)=0then surf=surf+COLU_CORE_SURF else surf=surf+COLU_VENEER_SURF endif endif v=REQUEST("Name_of_material",ROOF_MAT_TOP,mat) v=STRSTR(mat,type) ifv<>0thensurf=surf+ROOF_TOP_SURF v=REQUEST("Name_of_material",ROOF_MAT_EDGE,mat) v=STRSTR(mat,type) ifv<>0thensurf=surf+ROOF_EDGE_SURF v=REQUEST("Name_of_material",ROOF_MAT_BOTT,mat) v=STRSTR(mat,type) ifv<>0thensurf=surf+ROOF_BOTTOM_SURF v=REQUEST("Name_of_material",MESH_MAT_TOP,mat) v=STRSTR(mat,type) ifv<>0thensurf=surf+MESH_TOP_SURF v=REQUEST("Name_of_material",MESH_MAT_EDGE,mat) v=STRSTR(mat,type) ifv<>0thensurf=surf+MESH_EDGE_SURF v=REQUEST("Name_of_material",MESH_MAT_BOTT,mat) v=STRSTR(mat,type) ifv<>0thensurf=surf+MESH_BOTTOM_SURF emf=surf*20.4048 etr=surf*0.0168 cmf=surf*1.5024 ctr=surf*0.0013 wgt=surf*0.2080 REFCOMPONENT"EMF","POI",emf REFCOMPONENT"ETR","POI",etr REFCOMPONENT"CMF","POI",cmf REFCOMPONENT"CTR","POI",ctr REFCOMPONENT"WGT","POI",wgt

Paint(Acrylic) DATABASE_SET"EE" surf=0.0000 type="(PAC)" v=REQUEST("Name_of_material",SLAB_MAT_TOP,mat) v=STRSTR(mat,type) ifv<>0thensurf=surf+SLAB_TOP_SURF v=REQUEST("Name_of_material",SLAB_MAT_BOTT,mat) v=STRSTR(mat,type) ifv<>0thensurf=surf+SLAB_BOT_SURF v=REQUEST("Name_of_material",SLAB_MAT_EDGE,mat) v=STRSTR(mat,type) ifv<>0thensurf=surf+SLAB_EDGE_SURF v=REQUEST("Name_of_material",WALL_MAT_A,mat) v=STRSTR(mat,type) ifv<>0thensurf=surf+WALL_SURFACE_A v=REQUEST("Name_of_material",WALL_MAT_B,mat) v=STRSTR(mat,type) ifv<>0thensurf=surf+WALL_SURFACE_B v=REQUEST("Name_of_material",WALL_MAT_EDGE,mat) v=STRSTR(mat,type) ifv<>0thensurf=surf+WALL_EDGE_SURF v=REQUEST("Name_of_material",BEAM_MAT_RIGHT,mat) v=STRSTR(mat,type) ifv<>0thensurf=surf+BEAM_RIGHT_SURF v=REQUEST("Name_of_material",BEAM_MAT_LEFT,mat) v=STRSTR(mat,type) ifv<>0thensurf=surf+BEAM_LEFT_SURF v=REQUEST("Name_of_material",BEAM_MAT_TOP,mat) v=STRSTR(mat,type) ifv<>0thensurf=surf+BEAM_TOP_SURF v=REQUEST("Name_of_material",BEAM_MAT_BOTTOM,mat) v=STRSTR(mat,type) ifv<>0thensurf=surf+BEAM_BOTTOM_SURF v=REQUEST("Name_of_material",BEAM_MAT_END,mat) v=STRSTR(mat,type) ifv<>0thensurf=surf+BEAM_END_SURF v=REQUEST("Name_of_material",COLU_MAT,mat) v=STRSTR(mat,type) ifv<>0then ifint(COLU_VENEER_WIDTH)=0then surf=surf+COLU_CORE_SURF else surf=surf+COLU_VENEER_SURF endif endif v=REQUEST("Name_of_material",ROOF_MAT_TOP,mat) v=STRSTR(mat,type) ifv<>0thensurf=surf+ROOF_TOP_SURF v=REQUEST("Name_of_material",ROOF_MAT_EDGE,mat) v=STRSTR(mat,type) ifv<>0thensurf=surf+ROOF_EDGE_SURF v=REQUEST("Name_of_material",ROOF_MAT_BOTT,mat) v=STRSTR(mat,type) ifv<>0thensurf=surf+ROOF_BOTTOM_SURF v=REQUEST("Name_of_material",MESH_MAT_TOP,mat) v=STRSTR(mat,type) ifv<>0thensurf=surf+MESH_TOP_SURF v=REQUEST("Name_of_material",MESH_MAT_EDGE,mat) v=STRSTR(mat,type) ifv<>0thensurf=surf+MESH_EDGE_SURF v=REQUEST("Name_of_material",MESH_MAT_BOTT,mat) v=STRSTR(mat,type) ifv<>0thensurf=surf+MESH_BOTTOM_SURF emf=surf*12.688 etr=surf*0.0168 cmf=surf*0.9342 ctr=surf*0.0013 wgt=surf*0.2080 REFCOMPONENT"EMF","PAC",emf REFCOMPONENT"ETR","PAC",etr REFCOMPONENT"CMF","PAC",cmf REFCOMPONENT"CTR","PAC",ctr REFCOMPONENT"WGT","PAC",wgt

MasonryWall DATABASE_SET"EE" dimlist[] dimcomp[] channel=OPEN("PROP","EE","'EE_key.txt','EE_comp.txt','EE_desc.txt','EE_unit.txt'") in=INPUT(channel,"KEYLIST","KEYNAME,KEYCODE",list) forsk=1toWALL_SKINS_NUMBER r=REQUEST("Name_of_fill",WALL_SKINS_PARAMS[sk][1],mat) ipos=strstr(mat,"EE")+3 epos=strstr(mat,"(") ifepos=0thenepos=strlen(mat) skinmaterial=strsub(mat,ipos,(eposipos)+1) m=1 continue=true do ifstrstr(list[m],skinmaterial)<>0then in=INPUT(channel,"COMPLIST,"+list[m+1],"CODE,QUANTITY",comp) quant=(WALL_SKINS_PARAMS[sk][2]/WALL_THICKNESS)*WALL_VOLUME REFCOMPONENTcomp[1],list[m+1],quant REFCOMPONENTcomp[3],list[m+1],quant REFCOMPONENTcomp[5],list[m+1],quant REFCOMPONENTcomp[7],list[m+1],quant REFCOMPONENTcomp[9],list[m+1],quant continue=false endif m=m+2 whilem<=vardim1(list)andcontinue=true ifmat="EEFiredClayBrick9x19x19"then tiles_per_squaremeter=25 tile_weight=2.3 clay_volume=(WALL_SURFACE_A*tiles_per_squaremeter*tile_weight)/1400 mortar_volume=WALL_SURFACE_A*0.0120 REFCOMPONENT"EMF","FCB",clay_volume REFCOMPONENT"ETR","FCB",clay_volume REFCOMPONENT"CMF","FCB",clay_volume REFCOMPONENT"CTR","FCB",clay_volume REFCOMPONENT"WGT","FCB",clay_volume REFCOMPONENT"EMF","MTR",mortar_volume REFCOMPONENT"ETR","MTR",mortar_volume REFCOMPONENT"CMF","MTR",mortar_volume REFCOMPONENT"CTR","MTR",mortar_volume REFCOMPONENT"WGT","MTR",mortar_volume endif nextsk CLOSE(channel)

ApndiceD
ListasdeemissesgeradaspelaEEQuant

MaterialComponentQuantity 2CeramicTiles(External)CO2Emission(manufacturing)214,2527Kg 2CeramicTiles(External)CO2Emission(transport)5,2508Kg 2CeramicTiles(External)Energy(manufacturing)4.142,9288MJ 2CeramicTiles(External)Energy(transport)65,7882MJ 2CeramicTiles(External)Weight812,1836Kg 12CeramicTiles(Internal)CO2Emission(manufacturing)97,0464Kg 12CeramicTiles(Internal)CO2Emission(transport)23,7807Kg 12CeramicTiles(Internal)Energy(manufacturing)1.876,5060MJ 12CeramicTiles(Internal)Energy(transport)29,7958MJ 12CeramicTiles(Internal)Weight367,8720Kg 199ConcreteCO2Emission(manufacturing)5.911,9131Kg 199ConcreteCO2Emission(transport)432,6841Kg 199ConcreteEnergy(manufacturing)80.326,0927MJ 199ConcreteEnergy(transport)5.422,0113MJ 199ConcreteWeight66.938,4106Kg 43FiredClayBrickCO2Emission(manufacturing)3.969,0428Kg 43FiredClayBrickCO2Emission(transport)137,9947Kg 43FiredClayBrickEnergy(manufacturing)61.913,8345MJ 43FiredClayBrickEnergy(transport)1.729,3174MJ 43FiredClayBrickWeight21.349,5981Kg 6FiredClayRoofTileCO2Emission(manufacturing)1.954,7627Kg 6FiredClayRoofTileCO2Emission(transport)36,4990Kg 6FiredClayRoofTileEnergy(manufacturing)30.492,6441MJ 6FiredClayRoofTileEnergy(transport)457,3897MJ 6FiredClayRoofTileWeight5.646,7859Kg 17Glass(Float)CO2Emission(manufacturing)99,4642Kg 17Glass(Float)CO2Emission(transport)1,0399Kg 17Glass(Float)Energy(manufacturing)2.976,1875MJ 17Glass(Float)Energy(transport)13,0309MJ 17Glass(Float)Weight160,8750Kg 145MortarCO2Emission(manufacturing)5.477,6873Kg 145MortarCO2Emission(transport)220,0806Kg 145MortarEnergy(manufacturing)71.499,1898MJ 145MortarEnergy(transport)2.757,8259MJ 145MortarWeight34.047,2333Kg 80Paint(Oil)CO2Emission(manufacturing)92,7409Kg 80Paint(Oil)CO2Emission(transport)0,0802Kg 80Paint(Oil)Energy(manufacturing)1.259,5578MJ 80Paint(Oil)Energy(transport)1,0370MJ 80Paint(Oil)Weight12,8395Kg 43Paint(PVA)CO2Emission(manufacturing)606,8387Kg 43Paint(PVA)CO2Emission(transport)0,8128Kg 43Paint(PVA)Energy(manufacturing)8.241,8226MJ 43Paint(PVA)Energy(transport)10,2413MJ 43Paint(PVA)Weight126,7973Kg 9PlywoodCO2Emission(manufacturing)268,5813Kg 9PlywoodCO2Emission(transport)3,3393Kg 9PlywoodEnergy(manufacturing)3.875,0181MJ 9PlywoodEnergy(transport)41,8502MJ 9PlywoodWeight516,6691Kg 148SteelCO2Emission(manufacturing)3.962,4786Kg 148SteelCO2Emission(transport)12,0911Kg 148SteelEnergy(manufacturing)56.118,6068MJ 148SteelEnergy(transport)151,5202MJ 148SteelWeight1.870,6202Kg 22Wood(Kilndried)CO2Emission(manufacturing)213,8003Kg 22Wood(Kilndried)CO2Emission(transport)5,6963Kg 22Wood(Kilndried)Energy(manufacturing)3.084,6541MJ 22Wood(Kilndried)Energy(transport)71,3877MJ 22Wood(Kilndried)Weight881,3297Kg ComponentQuantity(totals) 726CO2Emission(manufacturing)22.868,6091Kg 726CO2Emission(transport)879,3495Kg 726Energy(manufacturing)325.807,0428MJ 726Energy(transport)10.751,1957MJ 726Weight132.731,2143Kg

ApndiceE
CdigofontedaaplicaoAC10Mestre
//***************************************************************************** //Description: SourcecodeforAC10M // // //SGcompatible //***************************************************************************** #include"APIEnvir.h" #define _DATABASE_CONTROL_TRANSL_ #pragmawarning(disable:4996) #include <string.h> #include "GSRoot.hpp" #include "Array.hpp" #include "CH.hpp" #include "IV.hpp" #include "Location.hpp" #include "ACAPinc.h" #include "Resource.h" #include"File.hpp" #include"FileSystem.hpp" #include<math.h> #include"VA.hpp" constGSResIDAddonInfo=32540; constdoublepi=3.14159265358979; voidmbox(doublevar); classcwind{ public: doubleobjloc; doublelower; doublewidth; doubleheight; doubleindex; }; // // // doubleclean(doublevar){ if((var>0.0001)&&(var<0.0001))return0; elsereturnvar; } doubleangle(doublexi,doubleyi,doublexf,doubleyf){ doublelx=clean(xfxi); doublely=clean(yfyi); if(lx==0){ if(yf>yi)return90; elsereturn270; } if(ly==0){ if(xf>xi)return0; elsereturn180; } doubler=ly/lx; doubleangle; angle=(atan(r)/pi)*180; if(xf<xi)returnangle+180; if(yf<yi)returnangle+360; returnangle; } voidmbox(doublevar){ charstring[20]; sprintf(string,"%12g",var); ::MessageBox(NULL,string,NULL,NULL); return; } Write::Write(constAPI_IOParams*ioParams): outputFile(NULL){ API_IOParamsioParameters; ioParameters=*ioParams; try{ outputFile=newIO::File(*ioParameters.fileLoc,IO::File::Create); if(outputFile>GetStatus()!=NoError) throwGS::OutOfMemoryException(); outputFile>Open(IO::File::WriteEmptyMode); if(outputFile>GetStatus()!=NoError) throwGS::OutOfMemoryException();

} catch(...){ throwGS::OutOfMemoryException(); } } Write::~Write(){ if(outputFile!=NULL){ if(outputFile>IsOpen()) outputFile>Close(); deleteoutputFile; } } voidWrite::WriteBuffer(char*buffer){ long size=strlen(buffer); //convert"\n"sto"CharCRCharLF" char buffer2[512]; long i,j; for(i=0,j=0;i<size;i++){ if(buffer[i]!='\n'){ buffer2[j++]=buffer[i]; }else{ buffer2[j++]=CharCR; buffer2[j++]=CharLF; } } buffer2[j]='\0'; outputFile>WriteBin(buffer2,j); } voidWrite::WriteLine(char*buffer){ charb[256]; sprintf(b,"%s\n",buffer); Write::WriteBuffer(b); return; } voidWrite::ExportScene(){ GSErrCodeerr; longnwalls; API_DatabaseInfodb; BNZeroMemory(&db,sizeof(API_DatabaseInfo)); db.typeID=APIWind_FloorPlanID; ACAPI_Database(APIDb_ChangeCurrentDatabaseID,&db,NULL); ACAPI_Element_GetNum(API_WallID,&nwalls); API_Elementwl; BNZeroMemory(&wl,sizeof(API_Element)); Write::WriteLine("//"); Write::WriteLine("//ArquivoexportadodoAC10paraoprogramaMestre"); Write::WriteLine("//"); Write::WriteLine("//"); Write::WriteLine("//Paredes"); Write::WriteLine("//"); Write::WriteLine("//pxyzazimutealtazimcomprimento espessuraalturamaterialzfzitempinicnome"); Write::WriteLine("//"); for(longi=1;i<=nwalls;i++){ if(!ACAPI_Element_Filter(API_WallID,i,0))continue; wl.header.typeID=API_WallID; wl.header.index=i; err=ACAPI_Element_Get(&wl); if((wl.wall.windInd>0)||(wl.wall.doorInd>0)){ intnwind=0; longiwind; DESCawindows; err=VAInit(&awindows,1,sizeof(cwind)); API_Elementwind; BNZeroMemory(&wind,sizeof(API_Element)); iwind=wl.wall.windInd; while(iwind!=0){ nwind++; wind.header.typeID=API_WindowID; wind.header.index=iwind; err=ACAPI_Element_Get(&wind); err=VASpac(&awindows); if(err<0){::MessageBox(NULL,"VASpac",NULL,NULL);break;} ((cwind*)*(awindows.arrhdl))[awindows.lastind].objloc= wind.window.objLoc(wind.window.width/2); ((cwind*)*(awindows.arrhdl))[awindows.lastind].lower= wind.window.lower; ((cwind*)*(awindows.arrhdl))[awindows.lastind].height= wind.window.height; ((cwind*)*(awindows.arrhdl))[awindows.lastind].width= wind.window.width; iwind=wind.window.follInd; } iwind=wl.wall.doorInd; while(iwind!=0){

} cwindtransf; doubleordered=0; while(ordered<awindows.lastind1){ ordered=0; for(intv=1;v<awindows.lastind;v++){ if(((cwind*)*(awindows.arrhdl))[v].objloc<((cwind*) *(awindows.arrhdl))[v+1].objloc) ordered++; } if(ordered==awindows.lastind1)break; for(intv=1;v<awindows.lastind;v++){ if(((cwind*)*(awindows.arrhdl))[v].objloc>((cwind*) *(awindows.arrhdl))[v+1].objloc){ transf=((cwind*)*(awindows.arrhdl))[v]; ((cwind*)*(awindows.arrhdl))[v]=((cwind*) *(awindows.arrhdl))[v+1]; ((cwind*)*(awindows.arrhdl))[v+1]=transf; } } } // //Decomposethewall // doublexwall=clean(wl.wall.begC.x); doubleywall=clean(wl.wall.begC.y); doublezwall=clean(wl.wall.bottom); doublehwall=clean(wl.wall.top); doubleazi=angle(xwall,ywall,clean(wl.wall.endC.x),clean(wl.wall.endC.y)); doublelx=clean(wl.wall.endC.x)xwall; doublely=clean(wl.wall.endC.y)ywall; doublelwall=sqrt((lx*lx)+(ly*ly)); doublee=wl.wall.thickness; doublezd=0;//? doublezi=0;//? doubleti=25; doublemat=wl.wall.refMat; doublealt=0;//? char*n=wl.wall.info; doublex,y,l,z,h; charcoords[256]; if(((cwind*)*(awindows.arrhdl))[1].objloc!=0){ x=xwall; y=ywall; z=zwall; h=hwall; l=((cwind*)*(awindows.arrhdl))[1].objloc; sprintf(coords,"p%12.5g%12.5g%12.5g%12.5g%12.5g%12.5g%12.5g %12.5g%12.5g%12.5g%12.5g%12.5g%s",x,y,z,azi,alt,l, e,h,mat,zd,zi,ti,n); Write::WriteLine(coords); } for(intv=1;v<=awindows.lastind;v++){ x=xwall+clean((((cwind*)*(awindows.arrhdl))[v].objloc* cos((azi*pi)/180))); y=ywall+clean((((cwind*)*(awindows.arrhdl))[v].objloc* sin((azi*pi)/180))); l=((cwind*)*(awindows.arrhdl))[v].width; //Parapet if(((cwind*)*(awindows.arrhdl))[v].lower!=zwall){ z=zwall; h=((cwind*)*(awindows.arrhdl))[v].lower; sprintf(coords,"p%12.5g%12.5g%12.5g%12.5g%12.5g %12.5g%12.5g%12.5g%12.5g%12.5g%12.5g%12.5g%s", x,y,z,azi,alt,l,e,h,mat,zd,zi,ti,n); Write::WriteLine(coords); } //Lintel if(((cwind*)*(awindows.arrhdl))[v].height!=hwall){ z=zwall+((cwind*)*(awindows.arrhdl))[v].lower+((cwind*) *(awindows.arrhdl))[v].height;

nwind++; wind.header.typeID=API_DoorID; wind.header.index=iwind; err=ACAPI_Element_Get(&wind); err=VASpac(&awindows); if(err<0){::MessageBox(NULL,"VASpac",NULL,NULL);break;} ((cwind*)*(awindows.arrhdl))[awindows.lastind].objloc= clean(wind.door.objLoc)(wind.door.width/2); ((cwind*)*(awindows.arrhdl))[awindows.lastind].lower=wind.door.lower; ((cwind*)*(awindows.arrhdl))[awindows.lastind].height= wind.door.height; ((cwind*)*(awindows.arrhdl))[awindows.lastind].width=wind.door.width; ((cwind*)*(awindows.arrhdl))[awindows.lastind].index=awindows.lastind; iwind=wind.door.follInd;

} else{

} VAFree(&awindows);

} //Wallbetweenopenings x=x+clean((((cwind*)*(awindows.arrhdl))[v].width* cos((azi*pi)/180))); y=y+clean((((cwind*)*(awindows.arrhdl))[v].width* sin((azi*pi)/180))); z=zwall; h=hwall; if(v<awindows.lastind) l=((cwind*)*(awindows.arrhdl))[v+1].objloc((cwind*) *(awindows.arrhdl))[v].objloc((cwind*) *(awindows.arrhdl))[v].width; else l=lwall((cwind*)*(awindows.arrhdl))[v].objloc((cwind*) *(awindows.arrhdl))[v].width; sprintf(coords,"p%12.5g%12.5g%12.5g%12.5g%12.5g%12.5g%12.5g %12.5g%12.5g%12.5g%12.5g%12.5g%s",x,y,z,azi,alt,l, e,h,mat,zd,zi,ti,n); Write::WriteLine(coords);

h=hwallz; sprintf(coords,"p%12.5g%12.5g%12.5g%12.5g%12.5g%12.5g %12.5g%12.5g%12.5g%12.5g%12.5g%12.5g%s",x,y,z,azi, alt,l,e,h,mat,zd,zi,ti,n); Write::WriteLine(coords);

} } Write::WriteLine("//"); Write::WriteLine("//Fimdodocumentoexportado"); return; } GSErrCode__ACENV_CALLDoExport(constAPI_IOParams*ioParams){ API_IOParamsioParameters; ioParameters=*ioParams; Writeexp(ioParams); exp.ExportScene(); returnNoError; } //============================================================================= // //Requiredfunctions // //============================================================================= #ifdef__MWERKS__ #pragmamark #endif // //CalledwhentheAddOnisgoingtoberegistered // API_AddonType __ACENV_CALL CheckEnvironment(API_EnvirParams*envirParams) { if(envirParams>serverInfo.serverApplication!=APIAppl_ArchiCADID) returnAPIAddon_DontRegister; //Fillinthenecessaryinformation GSResModulesaveResModule=ACAPI_UseOwnResModule(); ACAPI_Resource_GetLocStr(envirParams>addOnInfo.name,IDR_AddOnDescStrings,IDS_AddOnName); ACAPI_Resource_GetLocStr(envirParams>addOnInfo.description,IDR_AddOnDescStrings,IDS_AddOnDesc); ACAPI_ResetResModule(saveResModule); returnAPIAddon_Normal; }

charcoords[256]; doublex=clean(wl.wall.begC.x); doubley=clean(wl.wall.begC.y); doublez=clean(wl.wall.bottom); doublexf=clean(wl.wall.endC.x); doubleyf=clean(wl.wall.endC.y); doublealt=0;//? doublelx=xfx; doublely=yfy; doublel=sqrt((lx*lx)+(ly*ly)); doubleazi=angle(x,y,xf,yf); doublee=wl.wall.thickness; doubleh=wl.wall.top; doublemat=wl.wall.refMat; doublezd=0;//? doublezi=0;//? doubleti=25; char*n=wl.wall.info; sprintf(coords,"p%12.5g%12.5g%12.5g%12.5g%12.5g%12.5g%12.5g%12.5g%12.5g %12.5g%12.5g%12.5g%s",x,y,z,azi,alt,l,e,h,mat,zd,zi,ti, n); Write::WriteLine(coords);

// //Interfacedefinitions // GSErrCode__ACENV_CALL RegisterInterface(void) { GSErrCode err; err=ACAPI_Register_FileType(1,'Mestre','ArquivoMestre',"obj",0,AddonInfo,0, SaveAs3DSupported); returnerr; } // //Initialize // calledaftertheAddOnhasbeenloadedintomemory // GSErrCode__ACENV_CALL Initialize(void) { GSErrCode err; err=ACAPI_Install_FileTypeHandler(1,DoExport); if(err!=NoError) DBPrintf("ModelAccess_Test::Initialize()ACAPI_Install_FileTypeHandlerfailed\n"); returnerr; } // //CalledwhentheAddOnisgoingtobeunloaded // GSErrCode__ACENV_CALL FreeData(void) { returnNoError; }

ApndiceF
ArquivoifcXMLwall
<?xmlversion="1.0"encoding="utf8"?> <ex:iso_10303_28 xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xsi="http://www.w3.org/2001/XMLSchemainstance" xmlns:ex="urn:iso.org:standard:10303:part(28):version(2):xmlschema:common" xmlns="http://www.iaitech.org/ifcXML/IFC2x3/FINAL" xsi:schemaLocation="http://www.iaitech.org/ifcXML/IFC2x3/FINAL http://www.iaitech.org/ifcXML/IFC2x3/FINAL/IFC2x3.xsd" version="2.0" > <uosid="uos_1"description=""configuration="iifc2x3"edo=""> <IfcOrganizationid="i1556"> <Id>GS</Id> <Name>Graphisoft</Name> <Description>Graphisoft</Description> </IfcOrganization> <IfcApplicationid="i1560"> <ApplicationDeveloper> <IfcOrganizationxsi:nil="true"ref="i1556"/> </ApplicationDeveloper> <Version>11.0</Version> <ApplicationFullName>ArchiCAD11.0</ApplicationFullName> <ApplicationIdentifier>ArchiCAD</ApplicationIdentifier> </IfcApplication> <IfcPersonid="i1561"> <Id></Id> <FamilyName></FamilyName> <GivenName></GivenName> </IfcPerson> <IfcOrganizationid="i1563"> <Id></Id> <Name></Name> <Description></Description> </IfcOrganization> <IfcPersonAndOrganizationid="i1567"> <ThePerson> <IfcPersonxsi:nil="true"ref="i1561"/> </ThePerson> <TheOrganization> <IfcOrganizationxsi:nil="true"ref="i1563"/> </TheOrganization> </IfcPersonAndOrganization> <IfcOwnerHistoryid="i1568"> <OwningUser> <IfcPersonAndOrganizationxsi:nil="true"ref="i1567"/> </OwningUser> <OwningApplication> <IfcApplicationxsi:nil="true"ref="i1560"/> </OwningApplication> <ChangeAction>nochange</ChangeAction> <CreationDate>1220479852</CreationDate> </IfcOwnerHistory> <IfcSIUnitid="i1569"> <UnitType>lengthunit</UnitType> <Prefix>milli</Prefix> <Name>metre</Name> </IfcSIUnit> <IfcSIUnitid="i1570"> <UnitType>areaunit</UnitType> <Name>square_metre</Name> </IfcSIUnit> <IfcSIUnitid="i1571"> <UnitType>volumeunit</UnitType> <Name>cubic_metre</Name> </IfcSIUnit> <IfcSIUnitid="i1572"> <UnitType>planeangleunit</UnitType> <Name>radian</Name> </IfcSIUnit> <IfcMeasureWithUnitid="i1573"> <ValueComponent> <IfcPlaneAngleMeasure>0.01745329252</IfcPlaneAngleMeasure> </ValueComponent>

<UnitComponent> <IfcSIUnitxsi:nil="true"ref="i1572"/> </UnitComponent> </IfcMeasureWithUnit> <IfcDimensionalExponentsid="i1574"> <LengthExponent>0</LengthExponent> <MassExponent>0</MassExponent> <TimeExponent>0</TimeExponent> <ElectricCurrentExponent>0</ElectricCurrentExponent> <ThermodynamicTemperatureExponent>0</ThermodynamicTemperatureExponent> <AmountOfSubstanceExponent>0</AmountOfSubstanceExponent> <LuminousIntensityExponent>0</LuminousIntensityExponent> </IfcDimensionalExponents> <IfcConversionBasedUnitid="i1575"> <Dimensions> <IfcDimensionalExponentsxsi:nil="true"ref="i1574"/> </Dimensions> <UnitType>planeangleunit</UnitType> <Name>DEGREE</Name> <ConversionFactor> <IfcMeasureWithUnitxsi:nil="true"ref="i1573"/> </ConversionFactor> </IfcConversionBasedUnit> <IfcSIUnitid="i1576"> <UnitType>solidangleunit</UnitType> <Name>steradian</Name> </IfcSIUnit> <IfcSIUnitid="i1577"> <UnitType>massunit</UnitType> <Name>gram</Name> </IfcSIUnit> <IfcSIUnitid="i1578"> <UnitType>timeunit</UnitType> <Name>second</Name> </IfcSIUnit> <IfcSIUnitid="i1579"> <UnitType>thermodynamictemperatureunit</UnitType> <Name>degree_celsius</Name> </IfcSIUnit> <IfcSIUnitid="i1580"> <UnitType>luminousintensityunit</UnitType> <Name>lumen</Name> </IfcSIUnit> <IfcUnitAssignmentid="i1581"> <Unitsex:cType="set"> <IfcSIUnitpos="0"xsi:nil="true"ref="i1569"/> <IfcSIUnitpos="1"xsi:nil="true"ref="i1570"/> <IfcSIUnitpos="2"xsi:nil="true"ref="i1571"/> <IfcConversionBasedUnitpos="3"xsi:nil="true"ref="i1575"/> <IfcSIUnitpos="4"xsi:nil="true"ref="i1576"/> <IfcSIUnitpos="5"xsi:nil="true"ref="i1577"/> <IfcSIUnitpos="6"xsi:nil="true"ref="i1578"/> <IfcSIUnitpos="7"xsi:nil="true"ref="i1579"/> <IfcSIUnitpos="8"xsi:nil="true"ref="i1580"/> </Units> </IfcUnitAssignment> <IfcDirectionid="i1583"> <DirectionRatiosex:cType="list"> <ex:doublewrapperpos="0">1.</ex:doublewrapper> <ex:doublewrapperpos="1">0.</ex:doublewrapper> <ex:doublewrapperpos="2">0.</ex:doublewrapper> </DirectionRatios> </IfcDirection> <IfcDirectionid="i1587"> <DirectionRatiosex:cType="list"> <ex:doublewrapperpos="0">0.</ex:doublewrapper> <ex:doublewrapperpos="1">1.</ex:doublewrapper> <ex:doublewrapperpos="2">0.</ex:doublewrapper> </DirectionRatios> </IfcDirection> <IfcDirectionid="i1591"> <DirectionRatiosex:cType="list"> <ex:doublewrapperpos="0">0.</ex:doublewrapper> <ex:doublewrapperpos="1">0.</ex:doublewrapper> <ex:doublewrapperpos="2">1.</ex:doublewrapper> </DirectionRatios> </IfcDirection> <IfcCartesianPointid="i1595"> <Coordinatesex:cType="list"> <IfcLengthMeasurepos="0">0.</IfcLengthMeasure> <IfcLengthMeasurepos="1">0.</IfcLengthMeasure> <IfcLengthMeasurepos="2">0.</IfcLengthMeasure> </Coordinates> </IfcCartesianPoint> <IfcAxis2Placement3Did="i1599">

<Location> <IfcCartesianPointxsi:nil="true"ref="i1595"/> </Location> <Axis> <IfcDirectionxsi:nil="true"ref="i1591"/> </Axis> <RefDirection> <IfcDirectionxsi:nil="true"ref="i1583"/> </RefDirection> </IfcAxis2Placement3D> <IfcDirectionid="i1602"> <DirectionRatiosex:cType="list"> <ex:doublewrapperpos="0">6.123031769E17</ex:doublewrapper> <ex:doublewrapperpos="1">1.</ex:doublewrapper> </DirectionRatios> </IfcDirection> <IfcGeometricRepresentationContextid="i1606"> <ContextIdentifier>Plan</ContextIdentifier> <ContextType>Design</ContextType> <CoordinateSpaceDimension>3</CoordinateSpaceDimension> <Precision>1.000000000E5</Precision> <WorldCoordinateSystem> <IfcAxis2Placement3Dxsi:nil="true"ref="i1599"/> </WorldCoordinateSystem> <TrueNorth> <IfcDirectionxsi:nil="true"ref="i1602"/> </TrueNorth> </IfcGeometricRepresentationContext> <IfcProjectid="i1609"> <GlobalId>2kOmOUbrLEoxqJZg8WyZ5V</GlobalId> <OwnerHistory> <IfcOwnerHistoryxsi:nil="true"ref="i1568"/> </OwnerHistory> <Name>DefaultProject</Name> <RepresentationContextsex:cType="set"> <IfcGeometricRepresentationContextpos="0"xsi:nil="true"ref="i1606"/> <IfcGeometricRepresentationContextpos="1"xsi:nil="true"ref="i1666"/> <IfcGeometricRepresentationContextpos="2"xsi:nil="true"ref="i1749"/> </RepresentationContexts> <UnitsInContext> <IfcUnitAssignmentxsi:nil="true"ref="i1581"/> </UnitsInContext> </IfcProject> <IfcGeometricRepresentationContextid="i1666"> <ContextIdentifier>Plan</ContextIdentifier> <ContextType>Plan</ContextType> <CoordinateSpaceDimension>3</CoordinateSpaceDimension> <Precision>1.000000000E5</Precision> <WorldCoordinateSystem> <IfcAxis2Placement3Dxsi:nil="true"ref="i1599"/> </WorldCoordinateSystem> <TrueNorth> <IfcDirectionid="i1661"> <DirectionRatiosex:cType="list"> <ex:doublewrapperpos="0">6.123031769E17</ex:doublewrapper> <ex:doublewrapperpos="1">1.</ex:doublewrapper> </DirectionRatios> </IfcDirection> </TrueNorth> </IfcGeometricRepresentationContext> <IfcGeometricRepresentationContextid="i1749"> <ContextIdentifier>Plan</ContextIdentifier> <ContextType>Model</ContextType> <CoordinateSpaceDimension>3</CoordinateSpaceDimension> <Precision>1.000000000E5</Precision> <WorldCoordinateSystem> <IfcAxis2Placement3Dxsi:nil="true"ref="i1599"/> </WorldCoordinateSystem> <TrueNorth> <IfcDirectionid="i1745"> <DirectionRatiosex:cType="list"> <ex:doublewrapperpos="0">6.123031769E17</ex:doublewrapper> <ex:doublewrapperpos="1">1.</ex:doublewrapper> </DirectionRatios> </IfcDirection> </TrueNorth> </IfcGeometricRepresentationContext> <IfcLocalPlacementid="i1616"> <RelativePlacement> <IfcAxis2Placement3Dxsi:nil="true"ref="i1599"/> </RelativePlacement> </IfcLocalPlacement> <IfcSiteid="i1619"> <GlobalId>0bPpLFBJj7XQAGYZEA9u0C</GlobalId> <OwnerHistory>

<IfcOwnerHistoryxsi:nil="true"ref="i1568"/> </OwnerHistory> <Name>DefaultSite</Name> <ObjectPlacement> <IfcLocalPlacementxsi:nil="true"ref="i1616"/> </ObjectPlacement> <CompositionType>element</CompositionType> <RefLatitudeex:cType="list"> <ex:longwrapperpos="0">24</ex:longwrapper> <ex:longwrapperpos="1">28</ex:longwrapper> <ex:longwrapperpos="2">0</ex:longwrapper> </RefLatitude> <RefLongitudeex:cType="list"> <ex:longwrapperpos="0">54</ex:longwrapper> <ex:longwrapperpos="1">25</ex:longwrapper> <ex:longwrapperpos="2">0</ex:longwrapper> </RefLongitude> </IfcSite> <IfcLocalPlacementid="i1629"> <PlacementRelTo> <IfcLocalPlacementxsi:nil="true"ref="i1616"/> </PlacementRelTo> <RelativePlacement> <IfcAxis2Placement3Dxsi:nil="true"ref="i1599"/> </RelativePlacement> </IfcLocalPlacement> <IfcBuildingid="i1632"> <GlobalId>3bY3nhUKD0bODJ$BPp04CW</GlobalId> <OwnerHistory> <IfcOwnerHistoryxsi:nil="true"ref="i1568"/> </OwnerHistory> <Name>DefaultBuilding</Name> <ObjectPlacement> <IfcLocalPlacementxsi:nil="true"ref="i1629"/> </ObjectPlacement> <CompositionType>element</CompositionType> </IfcBuilding> <IfcAxis2Placement3Did="i1642"> <Location> <IfcCartesianPointxsi:nil="true"ref="i1595"/> </Location> <Axis> <IfcDirectionxsi:nil="true"ref="i1591"/> </Axis> <RefDirection> <IfcDirectionxsi:nil="true"ref="i1583"/> </RefDirection> </IfcAxis2Placement3D> <IfcLocalPlacementid="i1645"> <PlacementRelTo> <IfcLocalPlacementxsi:nil="true"ref="i1629"/> </PlacementRelTo> <RelativePlacement> <IfcAxis2Placement3Dxsi:nil="true"ref="i1642"/> </RelativePlacement> </IfcLocalPlacement> <IfcBuildingStoreyid="i1648"> <GlobalId>20dOrM_9P3KfaK$em10UZb</GlobalId> <OwnerHistory> <IfcOwnerHistoryxsi:nil="true"ref="i1568"/> </OwnerHistory> <Name>Terreo</Name> <ObjectPlacement> <IfcLocalPlacementxsi:nil="true"ref="i1645"/> </ObjectPlacement> <CompositionType>element</CompositionType> <Elevation>0.5</Elevation> </IfcBuildingStorey> <IfcMaterialid="i1658"> <Name>Gypsum</Name> </IfcMaterial> <IfcGeometricRepresentationSubContextid="i1670"> <ContextIdentifier>Annotation2D</ContextIdentifier> <ContextType>Plan</ContextType> <ParentContext> <IfcGeometricRepresentationContextxsi:nil="true"ref="i1666"/> </ParentContext> <TargetScale>0.01</TargetScale> <TargetView>plan_view</TargetView> </IfcGeometricRepresentationSubContext> <IfcColourRgbid="i1673"> <Red>0.</Red> <Green>0.</Green> <Blue>0.</Blue> </IfcColourRgb>

<IfcCurveStyleFontid="i1674"> <Name></Name> <PatternListex:cType="list"> <IfcCurveStyleFontPatternpos="0"id="i1676"> <VisibleSegmentLength>0.</VisibleSegmentLength> <InvisibleSegmentLength>1.</InvisibleSegmentLength> </IfcCurveStyleFontPattern> </PatternList> </IfcCurveStyleFont> <IfcCurveStyleid="i1677"> <CurveFont> <IfcCurveStyleFontxsi:nil="true"ref="i1674"/> </CurveFont> </IfcCurveStyle> <IfcPresentationStyleAssignmentid="i1678"> <Stylesex:cType="set"> <IfcCurveStylepos="0"xsi:nil="true"ref="i1677"/> </Styles> </IfcPresentationStyleAssignment> <IfcCurveStyleid="i1680"> <Name>1</Name> <CurveFont> <IfcCurveStyleFontxsi:nil="true"ref="i1674"/> </CurveFont> <CurveColour> <IfcColourRgbxsi:nil="true"ref="i1673"/> </CurveColour> </IfcCurveStyle> <IfcCartesianPointid="i1681"> <Coordinatesex:cType="list"> <IfcLengthMeasurepos="0">0.</IfcLengthMeasure> <IfcLengthMeasurepos="1">0.</IfcLengthMeasure> </Coordinates> </IfcCartesianPoint> <IfcFillAreaStyleHatchingid="i1685"> <HatchLineAppearance> <IfcCurveStylexsi:nil="true"ref="i1680"/> </HatchLineAppearance> <StartOfNextHatchLine> <IfcPositiveLengthMeasure>75.</IfcPositiveLengthMeasure> </StartOfNextHatchLine> <PatternStart> <IfcCartesianPointxsi:nil="true"ref="i1681"/> </PatternStart> <HatchLineAngle>0.</HatchLineAngle> </IfcFillAreaStyleHatching> <IfcFillAreaStyleid="i1688"> <FillStylesex:cType="set"> <IfcFillAreaStyleHatchingpos="0"xsi:nil="true"ref="i1685"/> </FillStyles> </IfcFillAreaStyle> <IfcPresentationStyleAssignmentid="i1690"> <Stylesex:cType="set"> <IfcFillAreaStylepos="0"xsi:nil="true"ref="i1688"/> </Styles> </IfcPresentationStyleAssignment> <IfcStyledItemid="i1692"> <Stylesex:cType="set"> <IfcPresentationStyleAssignmentpos="0"xsi:nil="true"ref="i1690"/> </Styles> </IfcStyledItem> <IfcStyledRepresentationid="i1696"> <ContextOfItems> <IfcGeometricRepresentationSubContextxsi:nil="true"ref="i1670"/> </ContextOfItems> <Itemsex:cType="set"> <IfcStyledItempos="0"xsi:nil="true"ref="i1692"/> </Items> </IfcStyledRepresentation> <IfcMaterialDefinitionRepresentationid="i1701"> <Representationsex:cType="list"> <IfcStyledRepresentationpos="0"xsi:nil="true"ref="i1696"/> </Representations> <RepresentedMaterial> <IfcMaterialxsi:nil="true"ref="i1658"/> </RepresentedMaterial> </IfcMaterialDefinitionRepresentation> <IfcMaterialLayerid="i1703"> <Material> <IfcMaterialxsi:nil="true"ref="i1658"/> </Material> <LayerThickness>150.</LayerThickness> <IsVentilated>unknown</IsVentilated> </IfcMaterialLayer> <IfcMaterialLayerSetid="i1705">

<MaterialLayersex:cType="list"> <IfcMaterialLayerpos="0"xsi:nil="true"ref="i1703"/> </MaterialLayers> <LayerSetName>Gypsum</LayerSetName> </IfcMaterialLayerSet> <IfcMaterialLayerSetUsageid="i1707"> <ForLayerSet> <IfcMaterialLayerSetxsi:nil="true"ref="i1705"/> </ForLayerSet> <LayerSetDirection>axis2</LayerSetDirection> <DirectionSense>positive</DirectionSense> <OffsetFromReferenceLine>0.</OffsetFromReferenceLine> </IfcMaterialLayerSetUsage> <IfcAxis2Placement3Did="i1708"> <Location> <IfcCartesianPointxsi:nil="true"ref="i1595"/> </Location> <Axis> <IfcDirectionxsi:nil="true"ref="i1591"/> </Axis> <RefDirection> <IfcDirectionxsi:nil="true"ref="i1583"/> </RefDirection> </IfcAxis2Placement3D> <IfcLocalPlacementid="i1711"> <PlacementRelTo> <IfcLocalPlacementxsi:nil="true"ref="i1645"/> </PlacementRelTo> <RelativePlacement> <IfcAxis2Placement3Dxsi:nil="true"ref="i1708"/> </RelativePlacement> </IfcLocalPlacement> <IfcWallStandardCaseid="i1714"> <GlobalId>1WfU$nJCrCZO_HrHunLtl5</GlobalId> <OwnerHistory> <IfcOwnerHistoryxsi:nil="true"ref="i1568"/> </OwnerHistory> <Name>SW002</Name> <ObjectPlacement> <IfcLocalPlacementxsi:nil="true"ref="i1711"/> </ObjectPlacement> <Representation> <IfcProductDefinitionShapeid="i1793"> <Representationsex:cType="list"> <IfcShapeRepresentationpos="0"xsi:nil="true"ref="i1753"/> <IfcShapeRepresentationpos="1"xsi:nil="true"ref="i1786"/> </Representations> </IfcProductDefinitionShape> </Representation> <Tag>3B09AD2E868F48F9A480F4F953F6B0E1</Tag> </IfcWallStandardCase> <IfcShapeRepresentationid="i1753"> <ContextOfItems> <IfcGeometricRepresentationContextxsi:nil="true"ref="i1749"/> </ContextOfItems> <RepresentationIdentifier>Axis</RepresentationIdentifier> <RepresentationType>Curve2D</RepresentationType> <Itemsex:cType="set"> <IfcPolylinepos="0"id="i1741"> <Pointsex:cType="list"> <IfcCartesianPointpos="0"id="i1733"> <Coordinatesex:cType="list"> <IfcLengthMeasurepos="0">0.</IfcLengthMeasure> <IfcLengthMeasurepos="1">0.</IfcLengthMeasure> </Coordinates> </IfcCartesianPoint> <IfcCartesianPointpos="1"id="i1737"> <Coordinatesex:cType="list"> <IfcLengthMeasurepos="0">1000.</IfcLengthMeasure> <IfcLengthMeasurepos="1">0.</IfcLengthMeasure> </Coordinates> </IfcCartesianPoint> </Points> </IfcPolyline> </Items> </IfcShapeRepresentation> <IfcShapeRepresentationid="i1786"> <ContextOfItems> <IfcGeometricRepresentationContextxsi:nil="true"ref="i1606"/> </ContextOfItems> <RepresentationIdentifier>Body</RepresentationIdentifier> <RepresentationType>SweptSolid</RepresentationType> <Itemsex:cType="set"> <IfcExtrudedAreaSolidpos="0"xsi:nil="true"ref="i1783"/> </Items>

</IfcShapeRepresentation> <IfcExtrudedAreaSolidid="i1783"> <SweptArea> <IfcArbitraryClosedProfileDefid="i1779"> <ProfileType>area</ProfileType> <OuterCurve> <IfcPolylineid="i1775"> <Pointsex:cType="list"> <IfcCartesianPointpos="0"id="i1759"> <Coordinatesex:cType="list"> <IfcLengthMeasurepos="0">0.</IfcLengthMeasure> <IfcLengthMeasurepos="1">0.</IfcLengthMeasure> </Coordinates> </IfcCartesianPoint> <IfcCartesianPointpos="1"id="i1763"> <Coordinatesex:cType="list"> <IfcLengthMeasurepos="0">1000.</IfcLengthMeasure> <IfcLengthMeasurepos="1">0.</IfcLengthMeasure> </Coordinates> </IfcCartesianPoint> <IfcCartesianPointpos="2"id="i1767"> <Coordinatesex:cType="list"> <IfcLengthMeasurepos="0">1000.</IfcLengthMeasure> <IfcLengthMeasurepos="1">150.</IfcLengthMeasure> </Coordinates> </IfcCartesianPoint> <IfcCartesianPointpos="3"id="i1771"> <Coordinatesex:cType="list"> <IfcLengthMeasurepos="0">0.</IfcLengthMeasure> <IfcLengthMeasurepos="1">150.</IfcLengthMeasure> </Coordinates> </IfcCartesianPoint> <IfcCartesianPointpos="4"xsi:nil="true"ref="i1759"/> </Points> </IfcPolyline> </OuterCurve> </IfcArbitraryClosedProfileDef> </SweptArea> <Position> <IfcAxis2Placement3Did="i1780"> <Location> <IfcCartesianPointxsi:nil="true"ref="i1595"/> </Location> <Axis> <IfcDirectionxsi:nil="true"ref="i1591"/> </Axis> <RefDirection> <IfcDirectionxsi:nil="true"ref="i1583"/> </RefDirection> </IfcAxis2Placement3D> </Position> <ExtrudedDirection> <IfcDirectionxsi:nil="true"ref="i1591"/> </ExtrudedDirection> <Depth>2500.</Depth> </IfcExtrudedAreaSolid> <IfcRelAssociatesMaterialid="i1797"> <GlobalId>3S_RJs72D3oBHcdFhXMvpB</GlobalId> <OwnerHistory> <IfcOwnerHistoryxsi:nil="true"ref="i1568"/> </OwnerHistory> <RelatedObjectsex:cType="set"> <IfcWallStandardCasepos="0"xsi:nil="true"ref="i1714"/> </RelatedObjects> <RelatingMaterial> <IfcMaterialLayerSetUsagexsi:nil="true"ref="i1707"/> </RelatingMaterial> </IfcRelAssociatesMaterial> <IfcColourRgbid="i1799"> <Red>0.6745098039</Red> <Green>0.6509803922</Green> <Blue>0.4588235294</Blue> </IfcColourRgb> <IfcSurfaceStyleRenderingid="i1800"> <SurfaceColour> <IfcColourRgbxsi:nil="true"ref="i1799"/> </SurfaceColour> <Transparency>0.</Transparency> <DiffuseColour> <IfcNormalisedRatioMeasure>0.81</IfcNormalisedRatioMeasure> </DiffuseColour> <SpecularColour> <IfcNormalisedRatioMeasure>0.09</IfcNormalisedRatioMeasure> </SpecularColour> <ReflectanceMethod>notdefined</ReflectanceMethod>

</IfcSurfaceStyleRendering> <IfcSurfaceStyleid="i1801"> <Side>both</Side> <Stylesex:cType="set"> <IfcSurfaceStyleRenderingpos="0"xsi:nil="true"ref="i1800"/> </Styles> </IfcSurfaceStyle> <IfcPresentationStyleAssignmentid="i1803"> <Stylesex:cType="set"> <IfcSurfaceStylepos="0"xsi:nil="true"ref="i1801"/> </Styles> </IfcPresentationStyleAssignment> <IfcSurfaceStyleid="i1805"> <Side>both</Side> <Stylesex:cType="set"> <IfcSurfaceStyleRenderingpos="0"xsi:nil="true"ref="i1800"/> </Styles> </IfcSurfaceStyle> <IfcPresentationStyleAssignmentid="i1807"> <Stylesex:cType="set"> <IfcSurfaceStylepos="0"xsi:nil="true"ref="i1805"/> </Styles> </IfcPresentationStyleAssignment> <IfcStyledItemid="i1809"> <Item> <IfcExtrudedAreaSolidxsi:nil="true"ref="i1783"/> </Item> <Stylesex:cType="set"> <IfcPresentationStyleAssignmentpos="0"xsi:nil="true"ref="i1807"/> </Styles> </IfcStyledItem> <IfcPresentationLayerAssignmentid="i1813"> <Name>StructuralBearing</Name> <AssignedItemsex:cType="set"> <IfcShapeRepresentationpos="0"xsi:nil="true"ref="i1753"/> <IfcShapeRepresentationpos="1"xsi:nil="true"ref="i1786"/> </AssignedItems> </IfcPresentationLayerAssignment> <IfcRelContainedInSpatialStructureid="i1815"> <GlobalId>2zENweYd9EMAS8SQ_7R2LP</GlobalId> <OwnerHistory> <IfcOwnerHistoryxsi:nil="true"ref="i1568"/> </OwnerHistory> <Name>BuildingStoreyContainer</Name> <Description>BuildingStoreyContainerforBuildingElements</Description> <RelatedElementsex:cType="set"> <IfcWallStandardCasepos="0"xsi:nil="true"ref="i1714"/> </RelatedElements> <RelatingStructure> <IfcBuildingStoreyxsi:nil="true"ref="i1648"/> </RelatingStructure> </IfcRelContainedInSpatialStructure> <IfcCartesianPointid="i1817"> <Coordinatesex:cType="list"> <IfcLengthMeasurepos="0">0.</IfcLengthMeasure> <IfcLengthMeasurepos="1">0.</IfcLengthMeasure> <IfcLengthMeasurepos="2">3100.</IfcLengthMeasure> </Coordinates> </IfcCartesianPoint> <IfcAxis2Placement3Did="i1821"> <Location> <IfcCartesianPointxsi:nil="true"ref="i1817"/> </Location> <Axis> <IfcDirectionxsi:nil="true"ref="i1591"/> </Axis> <RefDirection> <IfcDirectionxsi:nil="true"ref="i1583"/> </RefDirection> </IfcAxis2Placement3D> <IfcLocalPlacementid="i1824"> <PlacementRelTo> <IfcLocalPlacementxsi:nil="true"ref="i1629"/> </PlacementRelTo> <RelativePlacement> <IfcAxis2Placement3Dxsi:nil="true"ref="i1821"/> </RelativePlacement> </IfcLocalPlacement> <IfcBuildingStoreyid="i1827"> <GlobalId>0KCByAf6f9gPtICZzTBbST</GlobalId> <OwnerHistory> <IfcOwnerHistoryxsi:nil="true"ref="i1568"/> </OwnerHistory> <Name></Name> <ObjectPlacement>

<IfcLocalPlacementxsi:nil="true"ref="i1824"/> </ObjectPlacement> <CompositionType>element</CompositionType> <Elevation>3100.</Elevation> </IfcBuildingStorey> <IfcCartesianPointid="i1837"> <Coordinatesex:cType="list"> <IfcLengthMeasurepos="0">0.</IfcLengthMeasure> <IfcLengthMeasurepos="1">0.</IfcLengthMeasure> <IfcLengthMeasurepos="2">6200.</IfcLengthMeasure> </Coordinates> </IfcCartesianPoint> <IfcAxis2Placement3Did="i1841"> <Location> <IfcCartesianPointxsi:nil="true"ref="i1837"/> </Location> <Axis> <IfcDirectionxsi:nil="true"ref="i1591"/> </Axis> <RefDirection> <IfcDirectionxsi:nil="true"ref="i1583"/> </RefDirection> </IfcAxis2Placement3D> <IfcLocalPlacementid="i1844"> <PlacementRelTo> <IfcLocalPlacementxsi:nil="true"ref="i1629"/> </PlacementRelTo> <RelativePlacement> <IfcAxis2Placement3Dxsi:nil="true"ref="i1841"/> </RelativePlacement> </IfcLocalPlacement> <IfcBuildingStoreyid="i1847"> <GlobalId>339$BawsjBCv_Zu9b7bqae</GlobalId> <OwnerHistory> <IfcOwnerHistoryxsi:nil="true"ref="i1568"/> </OwnerHistory> <Name></Name> <ObjectPlacement> <IfcLocalPlacementxsi:nil="true"ref="i1844"/> </ObjectPlacement> <CompositionType>element</CompositionType> <Elevation>6200.</Elevation> </IfcBuildingStorey> <IfcRelAggregatesid="i1857"> <GlobalId>1awy6srVvEeftYDTIIHHn4</GlobalId> <OwnerHistory> <IfcOwnerHistoryxsi:nil="true"ref="i1568"/> </OwnerHistory> <Name>BuildingContainer</Name> <Description>BuildingContainerforBuildigStories</Description> <RelatingObject> <IfcBuildingxsi:nil="true"ref="i1632"/> </RelatingObject> <RelatedObjectsex:cType="set"> <IfcBuildingStoreypos="0"xsi:nil="true"ref="i1648"/> <IfcBuildingStoreypos="1"xsi:nil="true"ref="i1827"/> <IfcBuildingStoreypos="2"xsi:nil="true"ref="i1847"/> </RelatedObjects> </IfcRelAggregates> <IfcRelAggregatesid="i1861"> <GlobalId>3fMv4wZVv0d8YrdeiRouE8</GlobalId> <OwnerHistory> <IfcOwnerHistoryxsi:nil="true"ref="i1568"/> </OwnerHistory> <Name>SiteContainer</Name> <Description>SiteContainerForBuildings</Description> <RelatingObject> <IfcSitexsi:nil="true"ref="i1619"/> </RelatingObject> <RelatedObjectsex:cType="set"> <IfcBuildingpos="0"xsi:nil="true"ref="i1632"/> </RelatedObjects> </IfcRelAggregates> <IfcRelAggregatesid="i1863"> <GlobalId>2gPVin9wPEN9K38vVer7S2</GlobalId> <OwnerHistory> <IfcOwnerHistoryxsi:nil="true"ref="i1568"/> </OwnerHistory> <Name>ProjectContainer</Name> <Description>ProjectContainerforSites</Description> <RelatingObject> <IfcProjectxsi:nil="true"ref="i1609"/> </RelatingObject> <RelatedObjectsex:cType="set"> <IfcSitepos="0"xsi:nil="true"ref="i1619"/>

</RelatedObjects> </IfcRelAggregates> </uos> </ex:iso_10303_28>

ApndiceG
CdigofontedaaplicaodetestedeacessoifcXML
packageifcXMLmanager; importjava.io.BufferedReader; importjava.io.File; importjava.io.FileInputStream; importjava.io.IOException; importjava.io.InputStreamReader; importjavax.xml.namespace.QName; importorg.apache.xmlbeans.*; importorg.iaiTech.ifcXML.ifc2X3.xfinal.*; importorg.w3c.dom.Node; importorgStandard10303Part28Version2XmlschemaCommon.iso.*; publicclassBinding{ publicstaticvoidmain(String[]args){ IFCModelmodel=newIFCModel(); model.openFile("wall.ifcxml"); } } classIFCModel{ publicvoidopenFile(StringifcXMLFile){ print("Openingfile'"+ifcXMLFile+"'..."); try{ Filefile=newFile(ifcXMLFile); if(!file.exists()){ print("Filenotfoundingivenlocation."); return; } FileInputStreamfileInput=newFileInputStream(file); InputStreamReaderreader=newInputStreamReader(fileInput); BufferedReaderinputBuffer=newBufferedReader(reader); Stringline=""; StringBuilderresult=newStringBuilder(); BooleanencodeWrong=true; while((line=inputBuffer.readLine())!=null){ if(encodeWrong){ if(line.contains("xmlversion=")){ line=line.replace("encoding=\"utf8\"","encoding=\"iso88591\""); encodeWrong=false; } } result.append(line); } fileInput.close(); XmlObjectabstractDoc=XmlObject.Factory.parse(result.toString()); XmlCursorcursor=abstractDoc.newCursor(); cursor.toFirstChild(); if(!cursor.getName().getLocalPart().equals("iso_10303_28")){ print("Invalidfile:<iso_10303_28>elementnotfound."); return; } cursor.setName(newQName("urn:iso.org:standard:10303:part(28):version(2):xmlschema:common", "iso_10303_28","")); cursor.getObject().changeType(orgStandard10303Part28Version2XmlschemaCommon.iso. Iso1030328Document.type); NodeisoNode=cursor.getObject().getDomNode(); orgStandard10303Part28Version2XmlschemaCommon.iso.Iso1030328DocumentisoDoc= orgStandard10303Part28Version2XmlschemaCommon.iso.Iso1030328Document.Factory.parse(isoNode); org.iaiTech.ifcXML.ifc2X3.xfinal.Uosuos= (org.iaiTech.ifcXML.ifc2X3.xfinal.Uos) isoDoc.getIso1030328().getUos().changeType(org.iaiTech.ifcXML.ifc2X3. xfinal.Uos.type); Entity[]entities=uos.getEntityArray(); IfcSitesite=null; IfcWallStandardCasewall=null; print("IFCEntitiesfound:"+entities.length+"."); for(inti=0;i<entities.length;i++){ if(entities[i]instanceofIfcSite){ site=(IfcSite)entities[i]; break; } } for(inti=0;i<entities.length;i++){ if(entities[i]instanceofIfcWallStandardCase){ wall=(IfcWallStandardCase)entities[i]; break;

} } System.out.println("ReferenceLatitudedegree:"+ site.getRefLatitude().getLongWrapperArray(0).getLongValue()); StringglobalID= wall.getRepresentation().getIfcProductRepresentation().getRepresentations(). getIfcRepresentationArray(0).getRef(); IfcShapeRepresentationshape=null; for(inti=0;i<entities.length;i++){ if(entities[i]instanceofIfcShapeRepresentation&entities[i].getId()!=null){ if(entities[i].getId().equals(globalID)){ shape=(IfcShapeRepresentation)entities[i]; } } } IfcPolylinepolyline=(IfcPolyline)shape.getItems().getIfcRepresentationItemArray(0); System.out.println(polyline.getPoints().getIfcCartesianPointArray(1).getCoordinates(). getIfcLengthMeasureArray(0).getDoubleValue()); }catch(XmlExceptione){ print("Parsererror:"); e.printStackTrace(); return; } catch(IOExceptione){ e.printStackTrace(); return; } catch(Exceptione){ e.printStackTrace(); return; } print("Filewascorrectlyopened."); } //Printactions protectedvoidprint(Objectstring){ System.out.println(string); } protectedvoidprint(){ System.out.println(); }